Loic Salmon
email: loic.salmon@isen-ouest.yncrea.fr

Pierre-Yves Pillain
email: pierre-yves.pillain@univ-brest.fr

Goulven Guillou
email: goulven.guillou@univ-brest.fr

Jean-Philippe Babau
email: babau@univ-brest.fr

CARES, a framework for CPS simulation : application to autonomous underwater vehicle navigation function

Keywords: component-based design, simulation, modeldriven engineering, cyber-physical system

One key objective of Cyber-Physical System (CPS) simulation is to evaluate different CPS configurations regarding a certain user objective. First, simulation of CPS necessitates frameworks to handle heterogeneity of CPS components (the software and hardware system control, the behavior of the CPS itself and its physical environment). Then, to build simulators, designers use paradigms like FMI (Functional Mock-Up Interface) that proposes a data-driven generic interface facilitating the integration of heterogeneous models. However, in order to facilitate simulation configuration, an approach is required to drive modeling of parametric features and operational conditions. In this paper, we present CARES, a component-based and modeldriven approach to facilitate CPS simulation. CARES is applied to evaluate an Autonomous Underwater Vehicle (AUV) navigation function by simulation. The proposed models integrate both the principles of a generic simulation (integration of Component Based Software Engineering CBSE concepts and FMI paradigm) and domain specific aspects through a component-based architecture style. From a design model, a code generator builds the structural (Java or C++) code of the simulator. The generated code relies on a given run-time library for its execution and its structure facilitates integration of domain-specific code. The experiments show the effectiveness of the approach to build simulators for evaluation of different AUV configurations.

I. INTRODUCTION

In recent years, AUV usage in the hydrographic field is a more and more recurring point. Indeed, AUVs offer many benefits in terms of bathymetry resolution, mission planning and coverage rate. However, there are some uncertainties concerning the estimation of the position of the AUV underwater due to GPS signal loss whereas engineers need to predict, before the mission, that their robot will not be in a forbidden area or lost [START_REF] Kinsey | A survey of underwater vehicle navigation: recent advances and new challenges[END_REF]. Considering those uncertainties and the cost involved for such a system, simulation has become a key issue to predict the AUV position, computed by the navigation function of the AUV [START_REF] Gade | NavLab, a generic simulation and post-processing tool for navigation[END_REF].

CPS simulation faces four challenges. The first challenge concerns simulation performance. This aspect is addressed by optimizing the domain specific code and by using parallel infrastructure [START_REF]IEEE Standard for Modeling and Simulation (M-S) High Level Architecture (HLA)-Framework and Rules[END_REF]. The second challenge concerns precision of results which relies on the quality of the domain specific code. The third challenge concerns CPS modeling [START_REF] Derler | Modeling cyberphysical systems[END_REF]:

• Preventing misconnected model components. Indeed, not only because of the type of the components, one issue is the unit and referential of data that can be different from one component to another one. Standardization of the referential and the unit of data is a key element to prevent errors. • Modeling sensor behaviors and time disparities. The precision and the frequency of the sensors can be different. Different sensors are used to monitor the behavior of the CPS and each of them can be noised or disturbed by the environment. • System heterogeneity. Integration of heterogeneous domain specific aspects requires the separation of concerns related to modeling system and simulation. Due to different data sources, different models and algorithms, different simulation configurations are to be considered.

For integration and orchestration of heterogeneous models, the FMI [START_REF] Blochwitz | The functional mockup interface for tool independent exchange of simulation models[END_REF] standard is widely used. Even if some points (discrete events, timing semantic, distribution [START_REF] Tripakis | Bridging the semantic gap between heterogeneous modeling formalisms and FMI[END_REF]- [START_REF] Centomo | Generation of Functional Mockup Units for Transactional Cyber-Physical Virtual Platforms, chapter of Languages, Design Methods[END_REF]) may be discussed, the basic concepts proposed by FMI 2.0 for cosimulation (communication between simulation modules and orchestration) are sufficient for our simulation problem. Finally, the last challenge is the need of easy-to-use environment to design simulators. Classically, complexity of Cyber Physical System (CPS) encourages developers to change the development process by using modeling approaches [START_REF] Derler | Modeling cyberphysical systems[END_REF] and more specifically a Component-Based Software Engineering (CBSE) approach [START_REF] Crnkovic | On the use of component-based principles and practices for architecting cyberphysical systems[END_REF]. Recently, high-level modeling languages and standards have been proposed to facilitate the description of simulator structures and simulator runs [START_REF] Cremona | FIDE: An FMI Integrated Development Environment[END_REF]- [START_REF]The SSP Standard: Project Status and Roadmap, Modelica Projects User Meeting[END_REF]. But from our knowledge, there is no approach proposing a high-level modeling language integrating richness of CBSE and parametrization to build a flexible simulation environment for dedicated CPS, here AUV navigation function.

In this paper, we propose first a framework, called CARES, dedicated to CPS simulation. The framework is a tool-978-1-5386-5541-2/18/$31.00 ©2018 European Union independent high-level modeling language (based on concepts defined by CBSE and FMI 2.0 for co-simulation). From models, a code generator and a runtime library allow to build a simulator for a given scenario. Then, to integrate the domain specific aspects of the AUV navigation function, we propose an architectural style, called Navidro. Navidro provides modeldriven design rules and templates to facilitate domain specific simulator development. It proposes generic API and adapters to facilitate integration of different AUV behaviors, sensor configurations and navigation functions.

The remainder of the paper is structured as follows. Section II presents the application domain of AUV and more specifically the navigation function. Section III introduces the generic aspects of the model-driven and component-based framework, called CARES. Section IV presents the Navidro architectural style proposed to design the model for an AUV navigation function. In Section V, the simulation results are discussed. Section VI presents related works before a conclusion in Section VII.

II. THE AUV NAVIGATION FUNCTION

An AUV is used mainly to observe and collect data in a specific area. To fulfill its mission, it requires an evaluation of its position. This is the role of the navigation function. This section describes the different concepts and elements required to simulate the navigation function of an AUV.

The first element to consider is the trajectory of the AUV. This trajectory is the reference to evaluate the precision of the navigation function. For simulation, the trajectory can be extracted from a given log file (replay of a previous mission) or computed from a trajectory model. For the latter, the trajectory is usually specified by a list of way-points. Indeed, the trajectory cannot follow exactly the succession of waypoints through segment lines due to physical constraints: the drone cannot turn directly and the motor control implies some uncertainties in the trajectory. To simulate a realistic trajectory, different trajectory models can be used as for instance splines [START_REF] Sampaio | Planning 3D well trajectories using spline-in-tension functions[END_REF]. For testing purpose, a simple trajectory may be computed as set of consecutive segments and semi-circles (cf. Figure 1). The trajectory is impacted by the environment and meteorological conditions. In our case, the AUV evolves in an environment where current and depth play an important role, disturbing the intended trajectory of the AUV. To maintain its direction, reacting to the current, the AUV adopts crab steering mode. Moreover, the AUV may have to respect a given altitude from the seabed. Then, to simulate a realistic trajectory, current and depth are a part of the model for drone navigation estimation. The environment behavior may be extracted from a log file (replay of a previous mission), given by a forecast file of computed from an environment model.

For sensors, the following Figure 2 illustrates the different elements that can be present in an AUV. Indeed, each AUV is equipped with different sensors, in our case those different sensors are considered :

• the GPS provides an estimation of the position of the drone while it is on the surface. • the accelerometer is a part of Inertial Measurement Unit (IMU): it provides an estimation of the linear accelerations.

• the gyroscope is part of IMU: it provides an estimation of the angular speeds. • the DVL (Doppler Velocity Log): it provides an estimation of the linear speeds.

• the barometer provides an estimation of the depth. Each sensor is characterized by a level of quality (precision) and runs at a given frequency (in Hertz). The technical specification of a sensor characterizes its quality through a model of error (white noise, bias, scale factor, time drift, ...) [START_REF] Woodman | An introduction to inertial navigation[END_REF]. Moreover, each data provided by the sensors are given in the frame and orientation related to itself.

Finally, different navigation functions can be used. Some of them use only a few sensors data (GPS on the surface, gyroscope and DVL integration, gyroscope and accelerometer double integration) [START_REF] Kok | Using inertial sensors for position and orientation estimation[END_REF], while others use hybrid process merging all data received by the different sources (i.e. Kalman Filter). A Kalman Filter necessitates parameters' tuning to provide a correct estimation of the AUV position [START_REF] Benet | State-ofthe-art of standalone accurate AUV positioning -Application to high resolution bathymetric surveys[END_REF].

In conclusion, the simulation of the navigation function depends of the AUV trajectory, the environmental conditions, the quality of the sensors and the chosen algorithm. To evaluate one algorithm, one can deal with real data logs (replay of a given mission) or with models of the different components (evaluation for a specific AUV architecture).

III. CARES FRAMEWORK

This section presents CARES2 (Component framework for Adaptative Real-Time Embedded Systems) framework we propose for simulation of CPS. CARES provides model editors and Java tools to develop and run model-driven and component-based simulators.

The model-driven framework CARES proposes to prevent inherent problems of code-centric approaches by describing a CPS through a set of communicating components, each component simulating one part of the CPS. At execution stage, CARES follows a time-driven orchestration (such as FMI).

A. Main concepts

In the following section, we briefly present the main concepts of CARES.

Structure. CARES derives from a component-based approach. Basically, a component is either a leaf component or a composite component. A leaf component executes a specific task, while a composite component can be composed of leaf or composite components. The composite components are only proposed for structural purpose. It facilitates navigation in the system description. From FMI perspective, a leaf component corresponds can be viewed as a Functional Mock-up Unit (FMU). It is a co-simulation unit in charge of simulating one part of the system.

Communication. Communication between components is based on data exchange through input and output ports. The communication protocol is implemented by following the Ravenscar profile [START_REF] Burns | The Ravenscar tasking profile for high integrity real-time programs[END_REF]: a data producer overwrites data, so a module always considers the last produced data. The algorithm of communication orchestration is then generic and then not described in the model. We just represent datalinks that rely output ports to input ports (one to many relationship).

For our problem, the data exchange protocol is not sufficient. Classical functional services provide facilities to exchange complex data, to configure component behaviors and to program different simulation scenarios. For these needs, we add functional required and provided interfaces to components.

Components behavior. As with FMI, at execution, each leaf component executes a doStep() function following a Run-To-Completion paradigm. The doStep() function is executed considering data inputs at the beginning and producing data outputs at the end. Each component is initialized with an initialize() function and stopped with an end() function. To implement different modes during simulation, each component may be activated or not for a given scenario.

Time aspects and scheduling. Following the FMI paradigm for co-simulation, time and scheduling are managed by a centralized scheduler. The scheduler launches periodically the (doStep(timeInterval)) operation for each leaf component. The period is based on a frequency expressed in hertz. The time interval is modelled through a delay associated to the component. It corresponds to the time used by the real system to produce data. The output of the component are then updated after this time interval. For scheduling, the execution order is defined by the partial order given by the dataflow. If a cycle exists, a priority associated to each leaf component is used to define the execution order between components.

Scenario. The scenario modeling step corresponds to a timed sequence diagram modeling. A scenario defines:

• start and end time for the simulation;

• the time step size;

• at the beginning of a scenario: a sequence of parameter initializations; a list of components to stop (a not-used component may be deactivated); the binding of required and provided interfaces (if necessary); a list of operation calls on specific components for configuring them; • a sequence of timed events and for each timed event a sequence of parameter initializations or operation calls; • at the end of a scenario: a sequence of operation calls on specific components for configuring them; • when a simulation contains random data, a scenario may be played many times. In this case, some operations may be performed at the beginning and the end of each scenario.

A scenario definition provides a high-level description of a given simulation run. Using language facilities, it is then easy to adapt simulation to test a given configuration (parameter valuation or component structure).

B. Modeling

The CARES concepts are implemented through three metamodels:

• ComponentType metamodel: this metamodel contains the required elements to describe data types, functional interfaces and types of leaf components (list of required and provided interfaces, data inputs and outputs, attributes). Instances of types are described through a textual editor based on Xtext3 . • ComponentSystem metamodel: this metamodel contains the required elements to describe a configuration of components (leaf and composite components, data and interface links). The Figure 3 exhibits an excerpt of this metamodel. A graphical editor based on Sirius 4 allows to instantiate a model of components and links between them. • Scenario metamodel. This metamodel contains the required elements to describe a simulation scenario. A scenario contains initialization steps and timed events (component initialization, attribute modification, function call). A scenario is described through a declarative language, based on a Xtext textual editor.

The three metamodels are implemented using Ecore5 .

Component System Metamodel

C. Code generation

From instantiated models, a code generator implemented using Acceleo 6 generates Java code by analyzing the whole model (checking typing constraints). The generated code contains all the declarations and the glue code for all the components.

For integration of domain specific code, we impose that the code is "FMU-Compliant" by providing only the three init(), doStep() and end() functions. Then, for each leaf component, a corresponding Java class is generated inheriting from a Leaf-Component generic classes defining initialize(), doStep() and end() functions. The domain-specific code is then integrated by implementing the delegator pattern [START_REF] Gamma | Design patterns: abstraction and reuse of object-oriented design[END_REF] in the generated class.

Once the domain specific code is added, the simulator is ready to run by using the provided runtime library that implements the Master module. A scheduler launches each leaf component, viewed as a FMU, considering its frequency. Data communication is directly handled by the components without the need of the Master module to coordinate read/write operations.

At the end, from a given scenario, a class is generated to declare all the timed events considered by the main class to drive the simulation.

The code is now ready to perform a simulation.

IV. NAVIDRO ARCHITECTURAL STYLE

In the following part, model and architectural elements related to the simulation of an AUV navigation function are presented according to the Cares framework described previously.

A. Global architecture

This subsection describes the global architecture style of Navidro (see Figure 4). The Environment component is used to model and represent the environment in which the AUV evolves. The environment of the drone is composed of components generating current and level of the seabed at a given position. Both of those elements may be either simulated or extracted from log files.

The Drone component is responsible for the generation of the drone trajectory. This component is based either on a mission log reader (replay) or a trajectory model (a list of way-points defined by the Mission component). For the latter, the simulated trajectory can be computed simply with lines and arcs or more realistically with splines.

The Sensors component contains all the components simulating each sensor such as gyroscope, accelerometer, barometer or GPS. Data produced by a sensor can be computed considering a given error model or extracted from a log file. In the case of simulated data, data are produced by adding error to data obtained by analysing the simulated reference trajectory.

The Navigation component is responsible for the navigation function used to estimate the position of the drone. Different navigation functions can be plugged to build the trajectory from the initial point with information provided from the sensors. For instance, a basic navigation function integrating the speed (DVL output) considering the direction by integrating the rotation speed (gyroscope output) has been implemented. This component corresponds to the software part of the system.

The Analysis component compares the position given by the Drone component with the estimated position computed by the Navigation component. Its role is to compute the position incertitude.

As discussed in introduction, to prevent misconnected components, a standardization of units as well as referential frames is necessary. The global architecture style Navidro defines a list of referential frames and units fixed to avoid misconnected components. For instance, the speed, is given in m/s for the current and the measure of the DVL sensor. The position of the AUV is given according to the NED (North/East/Down) frame.

B. Heterogeneity integration

Designing Navidro simulators, issues have been identified such as adaptation of heterogeneous frames and units, specific component selection for a given simulation and integration of domain specific code in any language.

1) Units and referential adaptation: As previously noticed, data provided by each sensor is given in the frame and orientation related to itself. To adapt to the defined standard, we propose to provide a library of adapter components that make conversion and referential changes for classical data. Those components allow to standardize domain-specific processes.

The Figure 5 illustrates the utilization of such adapter component. The picture corresponds to the composite component DVL, a part of the Sensor composite component. This component is responsible to produce DVL data. Data may be either simulated by a model error (ErrorDVL component) or real data (readDVL component). The latter produces data by reading a log file, whereas the first one simulates classical measurement errors. For this component, adaptations are necessary for inputs and outputs. Firstly, it is necessary to adapt data provided by the Drone component to the body frame of the sensor since data is computed in the body frame of the drone. This is the role of the myBodyToDVL component. Furthermore because the frame and units of log data are based on technical sensor choice, an adapter is also necessary (readerDVL). Reciprocally, DVL data necessitates to be converted in the body frame of the drone to be processed by the navigation function. This is the role of the myDVL component (see Figure 6 of the composite Navigation component) modeling the DVL driver of the system.

DVL is an example of the pattern used for each sensor: local adaptation of the frame, error modeling, standardized log reader and output adaptation to drone frame. Indeed, several reference frame adaptations are proposed by the framework such as ECEF (Earth-Centered, Earth-Fixed), NED, body frame of the drone or of the sensors. The proposed pattern allows to easily integrate heterogeneous sources of data.

2) Data Source Selection: For a given simulation, the user has to select specific sources of data in a transparent • the first idea is to link at design stage the chosen data source component to the corresponding input: this solution requires that the source respects the input standard (respect of the architectural style); • the second idea is to plug all possible sources to a switch component: the switch component acts as a selector configured by the scenario; • the third approach has been addressed in [START_REF] Yin | Mode switch timing analysis for componentbased multi-mode systems[END_REF] where the authors propose a Model System Logic (MSL) to switch the components during the execution according to a mode defined by the user.

The first solution is simple and efficient at execution stage. But this solution implies that the user has to modify the design view. This point is not easy to users who only want to configure a simulator, without having a knowledge of how it is built. The third solution requires a more complex runtime library for dynamic adaptations. This is not necessary in our case: the configuration of the data sources is fixed for the whole simulation. We propose then to follow the second approach as illustrated in Figure 5 with the component mySourceDVLSwitch. This solution implies that all data source components are embedded in the simulator. To optimize execution, this solution requires to do not execute un-selected data source components. So the not used components are deactivated for performance purposes. Another illustration of the switch component is the selection of the simulated trajectory as depicted by the Figure 7. In this figure, the MissionInterpreter component considers splines while the SimpleMission component considers lines and semi circles (see results on Figure 1). The latter is useful for testing purposes while the spline allows to model a more realistic trajectory.

Excerpt of the Drone composite component

The two examples show the facility of the approach to integrate different sources of data. The switch component has the advantage to impose an API, standardizing frame and units to prevent computation errors.

3) Integration of legacy code: To integrate domain-specific code, we impose that the code respects a given Java interface composed of three functions (init(), doStep() and end()). To integrate legacy codes developed in several languages, a first solution is to use the FMI facilities. FMI proposes a Java API to consider heterogeneity of languages for FMU execution. This solution requires to use the corresponding FMI tool licences. In our experiments, we develop a simple adaptor to integrate C++ code. The original C++ code (a Kalman filter for the navigation function) has been first extended to implement the init(), doStep() and end() functions. Then a language adaptor has been implemented by using JNI facilities.

C. Scenario definition

An example of scenario AuvSimulation for Navidro is presented in Figure 8. It implements a simulation for 100 seconds. The MissionInterpreter component is used to provide the trajectory, so the SimpleMission component is stopped. To evaluate the impact of random errors on sensors, the scenario is played 10 times. For each scenario execution, the initial speed and direction is set to 5.0 and 1.0 respectively. After 20 seconds, resp. 50 seconds, the speed, resp. the direction, is modified. During simulation, the estimated positions are stored each ms in a csv log file.

V. EVALUATION

In order to evaluate the ability of our approach to simulate an AUV navigation function, simulations are performed on realistic configurations.

First, simulations are performed to qualify the performance and the quality of the simulator itself. We consider here a drone following a straight line during 20 km with a constant speed of 5 m/s (duration of 4000 seconds, a little bit more than 1 hour). We simulate ideal sensors (no error) acting at a frequency of 1000 hz. The drone and the navigation function are also simulated at the same frequency. With a PC i7 of 3.6 GHz CPU speed with 8GB RAM, the simulation takes less than 47 seconds and the position error is under 5 mm. Considering this ideal configuration, the simulator performance and precision is quite acceptable. Then we consider some classical scenarios.

Considering the mission contained in a csv file specifying a list of way-points characterized by their position, altitude and desired speed, a drone trajectory is simulated with splines. After applying a model error, to qualify the quality of the navigation function, we draw the two trajectories produced by the Drone component and by the Navigation component. The following Figure 9 depicts the results obtained for a specific mission with a DVL misalignement (the DVL has a different orientation from the drone and the navigation function does not considered it), the yellow trajectory corresponds to the estimated one while the green one represents the trajectory of the drone.

The following example (Figure 10) is obtained with real data logs and a navigation function based on the integration of the DVL speed, taking into account orientation through the gyroscope data. The simulation shrinks in 20 seconds a duration of thirty minutes. For this scenario, the maximal error is about 13.5 m.

VI. RELATED WORK

The literature proposes a lot of works on usage of CBSE paradigm for architecting CPS. [START_REF] Crnkovic | On the use of component-based principles and practices for architecting cyberphysical systems[END_REF] shows that the main concerns handled by CPS component models are those of integration, performance, and maintainability. The instruments to satisfy those concerns, while architecting CPS, are ad-hoc software/system architecture, model-based approaches, architectural and component languages, and design. Our approach concerns model-based ad-hoc architecture for integration purpose. The main difference from the literature is that we are interested in simulation while most focus on design and verification as some works about CPS and robot control ( [START_REF] Volpe | the CLARAty architecture for robotic autonomy[END_REF], [START_REF] Guillou | ImocaGen : A model-based code generator for embedded systems tuning[END_REF], [START_REF] Gobillot | A modeling framework for software architecture specification and validation[END_REF], [START_REF] Haber | Montiarcarchitectural modeling of interactive distributed and cyber-physical systems[END_REF], [START_REF] Becker | The MECHATRONICUML design method -process and language for platform-independent modeling[END_REF]).

Concerning architectures for simulation, some generic solutions have been proposed like FMI [START_REF] Blochwitz | The functional mockup interface for tool independent exchange of simulation models[END_REF]. FMI is an independent standard for modeling and co-simulation . The aim of FMI is to associate several simulation tools into one co-simulation environment orchestrated by the Master module (data exchange and scheduling). FMI constitutes a generic proposal while our approach addresses domain specific concerns. In another way, DirectSim [23] proposes a framework to develop agent-based simulators. It provides a run-time library, configuration and observation facilities, a set of bricks to model different kinds of vehicle, to model errors and 2D and 3D monitors. It is an open-source project but it does not propose a guide on how to build a simulator of an AUV navigation function.

CoSim20 proposes a modeling language to define a correct coordination of different executable models for co-simulation, which can be distributed at execution stage [START_REF] Liboni | CoSim20: An Integrated Development Environment for Accurate and Efficient Distributed Co-Simulations[END_REF]. In our approach, due to the simulation domain, distribution is not necessary and coordination is simplified because of the timedriven simulation.

FIDE is an Integrated Design Environment (IDE) for FMI [START_REF] Cremona | FIDE: An FMI Integrated Development Environment[END_REF]. It allows the modeling and design of co-simulation by integrating FMUs and considering discrete events. It proposes to implement a deterministic FMI Master Algorithm. The SSP standard proposes a tool-independent XML-based format for the description, packaging and exchange of system structures and their parameterization [START_REF]The SSP Standard: Project Status and Roadmap, Modelica Projects User Meeting[END_REF]. The standard integrates notions of units, valuation and mapping between parameters and components. SSP may be used to describe a system parametrization precisely. In the same idea, CARES proposes parameter definition, but directly into the co-simulation graph. Moreover, the parameter valuation is used to drive cosimulation runs through a high-level declarative language. Some simulators exist for drones like the open source OpenAUV testbed [START_REF] Schmittle | OpenUAV: A UAV Testbed for the CPS and Robotics Community[END_REF]. The simulator is proposed because extensive physical testing can be expensive and time consuming because of short flight times due to battery constraints and safety precautions. This approach remains code-centric and is dedicated to Multirotor Unmanned Aerial Vehicles. In the same domain, Aerostack [START_REF] Sanchez-Lopez | A multi-layered component-based approach for the development of aerial robotic systems : the aerostack framework[END_REF] proposes a layered architectural style to design and simulate controllers of Unmanned Aerial Systems. Even if this work addresses a different domain, we share with this work the idea of defining a component-based architecture style, the development of domain-specific library and the idea of designing a system by configuring existing blocks.

The literature proposes also specific simulators for AUV. UWSIM [START_REF] Prats | An open source tool for simulation and supervision of underwater intervention missions[END_REF] integrates a mechanical model of a submarine drone for simulation of its movements. Different sensors can be simulated as well as the sea state. However, this work focuses on visualization rather than simulating the sensors and the environment. Navlab [START_REF] Gade | NavLab, a generic simulation and post-processing tool for navigation[END_REF] proposes a software with the same objective as in the paper: the simulation of navigation function of AUV. It has been developed with MATLAB. Like in our it is based on three layers (trajectory simulation, sensors and navigation function). In addition simulated sensors (integrating noise) or real data may be considered. However, this project is not open-source, it is developed as a black-box with no information on its architecture.

VII. CONCLUSION

In this paper, the CARES framework for the design of simulators of CPS has been proposed. This model-based approach combines classical CBSE concepts and FMI paradigm. To use it in the specific domain of AUV navigation function, the Navidro architectural style has been proposed. It helps to standardize units and deals with heterogeneity of data source. The approach has been tested for different AUV configurations considering simulated or real trajectory and measurement errors.

Future works concern performance improvements by adding parallelism at execution stage. For instance, each sensor component may be executed in parallel. In addition, because of the iterative aspect of simulation, each iteration may be also parallelized. Another idea is to split the simulator in two parts, one for the trajectory creation and another one for sensors and navigation function analysis.

CARES has been defined to integrate FMUs following the FMI 2.0 Co-Simulation standard. The FMI 3.0 Co-Simulation standard offers new facilities to consider initialization, configuration, internal and external events [START_REF]Functional Mock-up Interface Specification, Version 3.0[END_REF]. CARES has to be extended to facilitate the driving of simulations integrating FMU following the FMI 3.0 Co-Simulation standard.

Finally, a simulation could launch several simulations with different parameter values in order to compare the impacts of some parameters on the performance of the navigation function. The idea is to develop an architecture exploration tool for the navigation function.

Fig. 1 .

 1 Fig. 1. Two different simulated trajectories built at the right with lines and semi-circles and at the left with splines.

Fig. 2 .

 2 Fig. 2. The Kongsberg Munin 1500 AUV and its components

Fig. 4 .

 4 Fig. 4. Global architecture defined by Navidro

Fig. 5 .

 5 Fig. 5. DVL composite component

Fig. 6 .

 6 Fig. 6. Navigation composite component

Fig. 8 .Fig. 9 .

 89 Fig. 8. A simulation scenario for

https://framagit.org/jpbabau/cares

https://www.eclipse.org/Xtext/

https://www.eclipse.org/sirius/

https://www.eclipse.org/ecoretools/

https://www.eclipse.org/acceleo/


Loïc Salmon
email: loic.salmon@isen-ouest.yncrea.fr

Pedro Merino Laso

Christophe Claramunt
email: chistophe.claramunt@ecole-navale.fr

Dominique Follut
email: dominique.follut@supmaritime.fr

Nicolas Pelissero
email: nicolas.pelissero@ecole-navale.fr

Data fusion challenges for AIS anti-piracy measures 1 st

Keywords: Anti-piracy, maritime security, AIS, data fusion

Cruise operators offer a big amount on services in high quality onboard amenities. Cruise vessels has became a target for pirates because its potential value. These attackers use more and more sophisticated tools and strategies to perform successful attacks. In consequence, detection systems need to evolve to take in account these new threats. No system are able to cover all detection requirements, so proposed solution will operate with complementary sub-systems as AIS, radar and cameras.

The aim of this position paper is to introduce current threats and challenges specifically related to Automatic Identification System (AIS) anti-piracy measures and how it can be useful in fusion detection methods. We also introduce ISOLA system as a complete detection and decision aid support against, among other threats, piracy attacks.

I. INTRODUCTION

Cruise operators are challenged to develop competitive cruise packages for potential clients through developing new itineraries, high-quality onboard amenities, as well as shorebased excursions giving access to various cultural sites and activities in the countries where the ships dock. Despite the large numbers of people on board, crime reporting on cruise ships is so far relatively low. While the ship itself faces security threats, activities on board and on shore nowadays provide many opportunities for targets and security flaws to be exploited by individuals or groups with motivation to do so. For instance one of the main issues concerns organized groups that intentionally plan to attack vessels at sea, usually piracy or terrorism acts [START_REF] Møller | Piracy, maritime terrorism and naval strategy[END_REF]. Therefore, cruise companies take security threats more and more seriously, with the objective of designing and implementing the most appropriate strategies and solutions to provide passengers the best security policies and ensure the cruise and its activities are not endangered by any security threats.

The research leading to these results is part of the ISOLA project that has received funding from the European Union's Horizon 2020 Research and Innovation Programme, under Grant Agreement No 883302.

Nowadays, piracy detection is mainly carried out from the collected information by navigation systems as AIS and radar. This works is executed manually by the crew assisted by ECDIS tools. Threat detection need to evolve to make automatic identification and alerts. Also, its important that the system will provide pertinent information to improve Security Situational Awareness.

This paper introduces current threats and challenges specifically related to Automatic Identification System (AIS) antipiracy measures. The rest of the paper is organised as follows. We will first survey current existing protocol and solutions closely associated to AIS anti-piracy measures, as well as the range of suspicious activities, hijacks, boarding events and full-blown attacks that provide many different threats on board. In Section III, works concerning combining multiple data sources are discussed and a generic framework is proposed. Afterwards, in Section IV, we present a realistic scenario where proposed ISOLA solution is used to attack detection. Finally, we present and discuss our conclusions in Section V.

This work is part of the European project ISOLA (Innovative and Integrated Security System on Board Covering the Life Cycle of a Passenger Ships Voyage) developed as par to the Horizon2020 program.

II. AIS LIMITATIONS AND CHALLENGES FOR ANTI-PIRACY

MEASURES

While maritime monitoring capabilities have been largely extended over the past few years, AIS malicious actions are still possible and range from falsification of transmitted data to disappearance of AIS tracks [START_REF] Ray | Deais project: Detection of ais spoofing and resulting risks[END_REF].

The detection of deliberate piracy actions clearly requires the implementation of a vessel monitoring system whose objective will be to identify anomalies and abnormal behaviours potentially. In [START_REF] Claramunt | Maritime data integration and analysis: recent progress and research challenges[END_REF], the authors addressed and discussed computational issues associated to the integration of large maritime data flows in order to identify and visualize some phenomena of interest such as regular and abnormal behaviours. Within the scope of the Datacron project [START_REF] Vouros | Big Data Analytics for Time-Critical Mobility Forecasting, From Raw Data to Trajectory-Oriented Mobility Analytics in the Aviation and Maritime Domains[END_REF], and in order to realtime monitor maritime data, ontologies provide appropriate mechanisms to generate data summaries and further eventbased analysis [START_REF] Salmon | Design principles of a stream-based framework for mobility analysis[END_REF].

However, there is still a need to develop and implement some specific real-time algorithms for tracking and categorize the large extent of vessel trajectories anomalies [START_REF] Riveiro | Maritime anomaly detection: A review[END_REF] as depicted in Figure 1 and those that can reveal some piracy threats.

Amongst the potential behaviours that can denote some anomalies and then potential piracy acts that happen at sea let us mention change of position, usurpation of identity (or AIS Spoofing) [START_REF] Ray | Deais project: Detection of ais spoofing and resulting risks[END_REF] [8], boats that no longer transmit their positions during a given time intentionally (or Going Dark) and necessitate some specific detection algorithms [START_REF] Kontopoulos | Real-time maritime anomaly detection: detecting intentional AIS switch-off[END_REF] [START_REF] Salmon | Continuous detection of black holes for moving objects at sea[END_REF].

In order to address all these issues in a timely manner, not only a sound analysis of AIS data should be provided as most of the above approaches do, but also integration of additional sensor-based capabilities provided by Unmanned Aerial Vehicle (UAVs), semi-autonomous or more conventional systems (radars, human observations etc.).

III. TOWARDS MARITIME DATA FUSION

Considering AIS limitations, different heterogeneous data integration solutions have been so far developed for a sound monitoring of vessel trajectories. For instance, in [START_REF] Zhang | Detection of ais closing behavior and mmsi spoofing behavior of ships based on spatiotemporal data[END_REF] authors use radar-based data and AIS signals to detect MMSI spoofing. Other approaches as Hidden Markov models have been applied to radar-based data and AIS signals to detect suspicious activities [START_REF] Andersson | Multiple sensor fusion for effective abnormal behaviour detection in counter-piracy operations[END_REF] Novel operational systems are appearing in maritime as USVs (Unmanned Surface Vehicles) and AUVs (Aerial Unmanned Vehicle). These systems can be used separately or combined in different manners: sharing information or being deployed together [START_REF] Shao | A novel cooperative platform design for coupled usv-uav systems[END_REF]. Some platforms as Sea4M proposes a complete solution of attack detection thanks to the fusion of radar and AIS data and verifying and responding thanks to heterogeneous USVs [START_REF] Laso | Monitor and control humancomputer interface for unmanned surface vehicle fleets[END_REF]. Others suggest to combine AUV videos with AIS data [START_REF] Zhou | Verification of ais data by using video images taken by a uav[END_REF], [START_REF] Xiu | A multi-feature and multi-level matching algorithm using aerial image and ais for vessel identification[END_REF].

Despite the interest of these approaches the main limitation is that they mainly combined two specific sources of data and cannot cover for example the large range of sensors potentially available, this being specifically the case for large vessels such as cruising ships or very large cargos.

Under the scope of the H2020 ISOLA funded project, the system to be implemented should integrate a series of stateof-the-art technological achievements from multidisciplinary fields, namely sensors, Internet of Things as well as additional processing mechanisms such as semantic reasoning, high-level analytics, decision support systems, crisis management and situational awareness focusing on passenger's ship security sector and beyond. Figure 2 depicts the objective of the ISOLA monitoring system composed by legacy system of the boat (AIS/GPS and Radar) completed by a fleet of unmanned UxVs, IoT and cameras streams as part of an interoperable modalities to detect, assess, evaluate and locate threat actions within existing ships.

The interest of the ISOLA approach is that it allows to fuse data from different sources, this providing a sound approach to detect abnormal situations. For instance when a vessel changes its MMSI or switch off intentionally its signal, this could be detected by comparing AIS data with other data sources such as UAVs videos or radar.

IV. USE CASE

In this section, we introduce a realistic scenario where a group of pirates attacks a cruise vessel with limited but not negligible means. The attack is performed with a mother ship that can deploy multiple skiffs. The attackers will take advantage of weather conditions to hide their position and goals to the last moment.

A. Description

A cruise vessel is sailing in high seas within a High Risk Area in the Mediterranean Sea (Greece -Cyprus -Israel) and 200 nm close to recent piracy hot spots, as per latest security intelligence report. Five hours ago sea state gradually changed from level 6 to 2 of Douglas Sea Scale. Additionally, visibility decreased from 12 to 6 nm. This conditions are favorable for pirates because they can navigate safely with little skiffs while they can hide their position.

Initially cruise vessels radar detects a low speed target at a distance of 16 nm. The target continuously closing distance towards the cruise vessel starboard side. An experienced bridge officer categorizes the track as "suspicious target".

What happens in real is that the pirates mother ship launched two skiffs in close distance (less than 5nm) to cruise vessel almost undetectable due to low visibility and the high detection range scale in ship's radar. Despite the deter verbal and other visual warnings the skiffs entered vessel's security perimeter (3nm). Now the skiffs are upgraded to "attackers" since the three persons on each one of them are obvious equipped with weapons and climbing means.

Skiffs separated from each other at a distance of 1nm and both dared an attack starboard side and port side simultaneously. Pirates of one skiff appeared determined and one of the pirates managed to board, however, fell down wounded on main deck. Other pirates deterred and sailed away. One Crew Member of the Bridge Element accidentally wounded and fell down in the Bridge (didn't manage to reach the safe room). The aforementioned case was scripted based on real piracy attacks that took place across several years.

B. Limitations of existing detection solutions

As we can appreciate with this scenario, no system could be able to detect skiffs before they were too close, less than 1nm. Furthermore, there were no way to identify the suspicious mother ship that were detected in the firs time.

Attackers usually disconnect AIS transmitter to hide their position or they spoof their identity. Because of this, AIS data are often not interesting to detect piracy attacks. Nevertheless, this system can be useful to detect anomalies as when a ship "goes dark" or to verify is shared information is coherent with other information sources i.e. cameras or radar.

Radar system is useful for detect medium-size vessels but it is not appropriate for detecting skiffs, boats that rarely measures more than 20 feet (about 6 meters) and usually used by pirates. Skiffs are also not detected because their height are comparable with swell and waves. Also, the scale used by the radar is usually adapted to navigation and not for piracy detection.

On-board cameras are useful to detect near targets These cameras can improve the visibility of the crew thanks to UHD (Ultra High Definition) sensors and zoom capabilities. Nevertheless, they are limited to visibility distance that can be significantly decreased by the weather. Because of this, pirates can take advantage easily of this limitation. Same way, IR cameras are useful for night scenarios but their action are also limited to a limited distance.

C. ISOLA's proposed solution

ISOLA is a complex system that take advantage of each subsystem in particular conditions. It embarks multiple subsystems, as shown in Figure 2. Collected data is presented to the watch personnel. In parallel, data is fused, processed and analyzed by adapted algorithms. Some of them make good use of Artificial Intelligence tools. These algorithms are able to improve Security Awareness Level thanks to automation and decision-aid capabilities.

In case the cruise ship of the presented scenario was equipped with ISOLA, a tethered drone carrying as payload a Smart Cameras System (one day/night HD fish-eye and one day/night UHD Zoom camera) and AI (Artificial intelligence) algorithms for skiffs distant detection and distinction from the sea waves noise would have been be deployed above the main mast of the vessel to maximize the covered area. This subsystem would have been covering on a permanent basis an estimated surrounding distance of more than 6nm in favorable weather conditions. AI algorithms for targets' horizontal distance measurement, localization and specific behaviour detection provides the security watch with a relevant alarm and the supportive information for preparing the response. The timely and accurate situation evaluation, the early threat recognition supports, the gradual application of Deter Measures against the attack and consequently the RUF (Rules for the Use of Force) are facilitated. In specific the main elements as suspicious activity criteria and threat estimation, compliance with SOP (Standard Operating Procedures) Counter Piracy Reaction Table, RUF, safety precautions to be taken, compliance with lines of authority and command, communication flow chart, decision making etc. were in place early enough to avoid any delay that could lead to a pirates embarkation if not close up.

ISOLA would also provide suggestions for announcements, messaging and reporting asking for help but also guidance to the crew by the PCASP (Privately Contracted Armed Security Personnel) and level of cooperation among them. Tethered drone's use, provided adequate data that fused verified and validated with other tracks in the surrounding area data, acquired by vessel's existing systems (ECDIS/ARPA, AIS, GPS and other) enhancing the human cognitive and raising early enough the Situational Awareness. As an option, AI algorithms could provide an automated "distress mode" service operation as an option for flawless unmanned operation.

V. CONCLUSION AND FUTURE DIRECTIONS

This paper has presented different challenges for piracy attack detection due mainly to AIS limitations as well as meteorological conditions. Some works have been initiated to use one another source to correlate the position given by AIS, however merging of multiple sensors has not been addressed yet. In this paper, we have defined the main principles of a system for multiple sensor data fusion developed in the context of ISOLA project for safety of cruising ships. A lot of different data sources as drone images, AIS data or radar are available and necessitate mechanisms for data fusion. The main idea is the formalization and the development of an ontology for piracy attack detection. However, there is still a large range of issues from the development of appropriate sensing architectures at large, to data fusion algorithms for piracy detection and threats classification at sea, as well as visualization interfaces still to be developed for both maritime authorities and crew members.

ISOLA will contribute to the Enforcement of PMSC's SOPs and RUF, Captain's standing orders and Company's policies and regulations aboard the ship. It will deliver the required warning signals and suggestions to the ship's key personnel and the Private Contracted Armed or Unarmed Security Personnel Team Leader (the initial evaluator and first responder) regarding the gradual implementation of pirates preventive actions, in terms of effective early warning, detection, situation evaluation, decision making and emergency responding, not al-lowing the situation escalation and preserving the security and safety of people on-board and vessel's operations continuity.

Fig. 1 .

 1 Fig. 1. Statistics concerning AIS frauds realised by Windward [7].

Fig. 2 .

 2 Fig. 2. ISOLA piracy detection process.

ACKNOWLEDGMENT

The authors would like to thank to the other participants of the ISOLA project for their work and dedication.


Fate

  of emerging and priority micropollutants during the sewage sludge treatment -Part 2: Mass balances of organic contaminants on sludge treatments are challenging Dominique Patureau, Romain Mailler, Nadine Delgenes, Alice Danel, Emmanuelle Vulliet, S. Deshayes, R. Moilleron, V. Rocher, Johnny Gasperi To cite this version: Dominique Patureau, Romain Mailler, Nadine Delgenes, Alice Danel, Emmanuelle Vulliet, et al.. Fate of emerging and priority micropollutants during the sewage sludge treatment -Part 2: Mass balances of organic contaminants on sludge treatments are challenging. Waste Management, 2021, 125, pp.122-131. 10.1016/j.wasman.2021.02.034. hal-03161576