scispace - formally typeset

Proceedings ArticleDOI

A generic and modular architecture for maritime autonomous vehicles

01 Nov 2018-

TL;DR: This paper describes the Robot System Onboard Architecture (RSOA) software developed in the SWARMs project for the achievement of offshore maritime operations and implements high level capabilities in a semiautonomous or autonomous manner, and is deployed at a lower level on a heterogeneous swarm of vehicles.

AbstractAutonomous systems face the challenge of managing disruptive events such as internal alterations, mission updates and environmental perturbations that always occur in an operational context. Autonomous vehicles must embed the capabilities to supervise their behaviour and to detect and react to such events. The complexity increases with the heterogeneity of vehicles in the team and the communication constraints. This paper describes the Robot System Onboard Architecture (RSOA) software developed in the SWARMs project for the achievement of offshore maritime operations. This generic and modular architecture implements high level capabilities in a semiautonomous or autonomous manner, and is deployed at a lower level on a heterogeneous swarm of vehicles. Target vehicles include autonomous and teleoperated underwater vehicles, and surface vehicles. Simulation and experimentations achieved on the Black Sea in Romania (July 2017) then in the Trondheim fjord in Norway (June 2018) highlighted the good performance of the RSOA.

Summary (3 min read)

Introduction

  • Keywords – Autonomous robots, Maritime scenarios, Software architecture, Mission online adaptation.
  • The extended use of uninhabited underwater and surface vehicles in offshore maritime operations is a solution to increase the safety of tasks previously assigned to divers and reduce operational costs.
  • This paper deals with the third item and more precisely with the development of a generic and modular software architecture decentralized in the vehicles that allows the team of robots to react autonomously and in real time to disruptive events such as partial or total sensor failure, loss of propulsion, or high currents.
  • This architecture named RSOA (Robot System Onboard Architecture) is based on the ROS middleware (Robot Operating System) and is connected on the one hand to the MMT by RF/Wi-Fi (vehicles on the surface) or acoustic (vehicles under the water) communications and on the other hand to the robot platforms of each vehicle (AUV, USV, ROV).
  • Because of the complexity and the relevant risks of creating real events during a mission, some functionalities were only evaluated by simulation.

II. THE ROBOT SYSTEM ONBOARD ARCHITECTURE

  • In all cases, the architecture must allow the supervision of the achievement of the actions and their monitoring.
  • USVs can also embed the RSOA even if communications with the MMT are less constrained.
  • The Robot Supervisor module is central in the RSOA and based on a model of the expected behaviour of vehicles in nominal situation and when disruptive events occur.
  • It receives a set of tasks or actions from the MMT; when tasks are received, the supervisor interacts with the Robot Planner function to obtain the set of actions to be executed.

D. Planner function

  • The Robot Planner module can produce an individual plan of actions for each high level task.
  • This function is not called when actions are directly sent by the MMT, and in this case there is no recomputation of plan at the vehicle level: the disturbing events are globally treated at the MMT level.
  • These tasks are SURFACE, REFERENCING, RECOVER and SETMODE.
  • For some tasks there are several possible planners.

E. Monitor function

  • The Robot Monitor module produces high level health and performance indicators: it monitors the different activities going on at vehicle level and generates events or alarms when unexpected behaviour is detected.
  • The monitor integrates both numeric and qualitative reasoning to provide diagnosis (now) and prognostic for each generic vehicle action.
  • It is therefore directly connected on the one hand to the Robot Generic Interface module and on the other hand to the Robot Supervisor module.
  • When abnormal values are detected repeatedly, they are escalated into more severe alarms according to a model expressed with temporal logic.
  • This architecture has been implemented in several SWARMs vehicles (mentioned later on in the paper).

III. ROMANIA DEMONSTRATION – JULY 2017

  • After early trials in Gran Canaria Island on the Atlantic Ocean in September 2016, the first SWARMs project demonstration took place in Mangalia in July 2017, on the Black Sea.
  • Its whole capabilities were mainly evaluated by simulation.
  • The area has then been divided in 8 subareas (Fig. 2).
  • There was no connection with the MMT for these tests and a specific mission management system sent the high level survey tasks to vehicles.
  • Several runs highlighted the nominal and reconfiguration capabilities of the architecture: Nominal execution of the mission (Fig. 4): basic planning, execution and supervision of actions (including activation and deactivation of payload), storing of robot position, robot status, environment data and robot alarm; .

B. Experimentation

  • The RSOA has been adapted to 3 experimental vehicles: Desistek Robotics SAGA and Autonomous Systems ATN50 ROVs: integration of part of the RSOA in their Command and Control Stations; Leonardo Static USV: integration of part of the RSOA in the vehicle.
  • The GPS position was well received and the RSOA managed the three onboard payloads.

IV. NORWAY DEMONSTRATION, JUNE 2018

  • The second and final SWARMs project demonstration took place in the Trondheim fjord end of June 2018.
  • The plume was detected by monitoring the water salinity that decreased in the presence of unsalted pollutant.
  • The added capabilities of the RSOA required the enhancement of all modules and the adaptation of functions to the new scenario.
  • The full version of RSOA was integrated in 3 AUVs: Fridtjof LAUV from NTNU and 2 Noptilus LAUVs from Porto University UPTEC.
  • The UUV Simulator was enhanced with the objective to simulate the new experimental scenario and especially to model of the Trondheim environment and the vehicles that participated to the experimentation.

A. Norway scenario

  • While the Romania simulation scenario was especially built for the evaluation of the RSOA, the Norway simulation scenario (Fig. 8) replicated the complete experimental scenario.
  • In order to detect the plume, the research area was covered by the 3 AUVs moving at different depths.
  • The recovery points were the initial points for each vehicle; the recovery procedure was for each vehicle to join them first at the safety survey depth before going to the surface outside the survey area.
  • The salinity information was sent from the plume emulator to the CAF taking into account the real AUVs positions into account and the AUVs followed their initial planning.

C. Simulation

  • This was performed thanks to a three-step behaviour coded in the Supervision function and individually followed by each AUV: The planner computed a boustrophedon-shaped trajectory in the survey area.
  • Fig. 10 zooms on the beginning of the simulation of the mission for one AUV; the distance between two following rows is about 50 meters.
  • A significant decrease, followed by a certain increase of the salinity measurement monitored was interpreted as the the AUV entering then leaving the plume.
  • The ongoing row was then stopped and a U-turn was planned so as to recover the next planned row.
  • This was performed until the end of the initial survey.

V. CONCLUSIONS AND PERSPECTIVES

  • A generic and modular architecture for maritime autonomous vehicles, named RSOA, has been developed and tested both by simulation and at sea during the SWARMs H2020 project.
  • Its development was incremental and applied in two different scenarios: sonar survey of an area and detection and tracking of a plume of pollutant.
  • The robustness of the monitoring function has not been tested.
  • Perspectives concern also the direct cooperation in the team of robots.
  • Indeed, all cooperation between vehicles in the SWARMs project was through the centralized MMT: either the reaction was local at the vehicle level or the reaction was global at the MMT level.

Did you find this useful? Give us your feedback

...read more

Content maybe subject to copyright    Report

HAL Id: hal-01983412
https://hal.archives-ouvertes.fr/hal-01983412
Submitted on 16 Jan 2019
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entic research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diusion de documents
scientiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
A generic and modular architecture for maritime
autonomous vehicles
Magali Barbier, Eric Bensana, Xavier Pucel
To cite this version:
Magali Barbier, Eric Bensana, Xavier Pucel. A generic and modular architecture for maritime au-
tonomous vehicles. 2018 IEEE OES Autonomous Underwater Vehicle Symposium AUV2018, Nov
2018, PORTO, Portugal. �hal-01983412�

A generic and modular architecture for maritime
autonomous vehicles
Magali BARBIER, Eric BENSANA, Xavier PUCEL
ONERA The French Aerospace Lab, FRANCE
{Firstname.Lastname}@onera.fr
Abstract - Autonomous systems face the challenge of
managing disruptive events such as internal alterations, mission
updates and environmental perturbations that always occur in an
operational context. Autonomous vehicles must embed the
capabilities to supervise their behaviour and to detect and react
to such events. The complexity increases with the heterogeneity of
vehicles in the team and the communication constraints. This
paper describes the Robot System Onboard Architecture (RSOA)
software developed in the SWARMs project for the achievement
of offshore maritime operations. This generic and modular
architecture implements high level capabilities in a semi-
autonomous or autonomous manner, and is deployed at a lower
level on a heterogeneous swarm of vehicles. Target vehicles
include autonomous and teleoperated underwater vehicles, and
surface vehicles. Simulation and experimentations achieved on
the Black Sea in Romania (July 2017) then in the Trondheim
fjord in Norway (June 2018) highlighted the good performance of
the RSOA.
Keywords – Autonomous robots, Maritime scenarios, Software
architecture, Mission online adaptation.
I.INTRODUCTION
The extended use of uninhabited underwater and surface
vehicles in offshore maritime operations is a solution to
increase the safety of tasks previously assigned to divers and
reduce operational costs.
The objective of the SWARMs H2020 project (2015-2018)
is to allow the cooperation in these offshore missions of
autonomous uninhabited vehicles having complementary
capabilities: measurements by submarine vehicles (AUV
Autonomous Underwater Vehicle), surveillance, relay and
measurements by surface vehicles (USV Uninhabited Surface
Vehicle) and intervention by underwater teleoperated vehicles
(ROV Remotely Operated Vehicle).
The project approach is to design and develop an integrated
platform that allows these heterogeneous vehicles to achieve
the different phases of a mission. The SWARMs system is
then composed of three components:
A centralized Mission Management Tool (MMT)
located inside the Command and Control Station for the
generation of missions, the assignment of tasks to robot
systems and the supervision of missions;
A distributed MiddleWare system (MW) to ensure the
information exchange between the MMT and vehicles
through the Wi-Fi and acoustic communication
channels, as well as information processing such as
recording data in the data base, managing the embedded
ontology etc.
Several robot systems with their sensors for the
achievement of the tasks.
This paper deals with the third item and more precisely
with the development of a generic and modular software
architecture decentralized in the vehicles that allows the team
of robots to react autonomously and in real time to disruptive
events such as partial or total sensor failure, loss of propulsion,
or high currents.
This architecture named RSOA (Robot System Onboard
Architecture) is based on the ROS middleware (Robot
Operating System) and is connected on the one hand to the
MMT by RF/Wi-Fi (vehicles on the surface) or acoustic
(vehicles under the water) communications and on the other
hand to the robot platforms of each vehicle (AUV, USV,
ROV). The communications between vehicles and the mission
control use the DDS protocol (Data Distribution Service),
OpenSplice DDS Community being used in vehicles and
TwinOaks CoreDX DDS solutions being used in the MW.
This architecture has been implemented on several robots
of the project, validated by simulation, then simulation with
hardware in the loop, and finally by experimentations at sea.
Because of the complexity and the relevant risks of creating
real events during a mission, some functionalities were only
evaluated by simulation.
Section II presents the RSOA architecture. Sections III and
IV respectively describe experimentations and simulations
tests performed during the first demonstration event in
Mangalia (Romania) in July 2017 then during the second and
final demonstration planned in Trondheim (Norway) in June
2018. Section V concludes this work.
II. T
HE ROBOT SYSTEM ONBOARD ARCHITECTURE
A. Integration in the SWARMs System
The SWARMs offshore scenarios discussed with end users
allowed the definition of generic high level tasks: transit to a
given point or area, survey of a given area, inspection of an
object or a structure and pick up of an object. These tasks are
then decomposed in a set of motion, perception, manipulation
and communication generic actions: go to a waypoint, follow a
row, follow a structure, inspect an area, acquire sensor data...
In the MMT, the mission defined by the human operator is
planned and the tasks are assigned to available vehicles so as
to minimize the time or cost for executing the mission. MMT
planners are also capable of mapping high level tasks into

detailed actions for vehicles that do not have onboard planners.
For the other vehicles, a mission made of a sequence of high
level tasks is directly sent by acoustic communication to each
vehicle, and the onboard planner produces a detailed plan of
actions from these tasks. In all cases, the architecture must
allow the supervision of the achievement of the actions and
their monitoring. When a disruptive event occurs, either the
problem is treated at the vehicle level (computation of a new
local plan) or the information is sent to the MMT for global
treatment at the team level.
In general, AUVs need to achieve a good level of
autonomy because of the communication constraints under
water: this is the primary purpose of embedding the RSOA in
them. USVs can also embed the RSOA even if
communications with the MMT are less constrained. ROVs are
not here only as a mechanical extension of the human operator:
modern ROVs can be thought of as semi-autonomous devices
receiving high level tasks from the MMT. In the SWARMs
project, a specific version of the RSOA is embedded in the
local control station of the ROV; either a human operator or a
filtering process is in the loop.
The robot system sends to the MMT real time information
on the achievement of the tasks/actions (completed, aborted, or
failed), on data relevant to the mission (i.e. sensor data such as
salinity, depth)… This allows the MMT to react in a
centralized way and at team level if required. When the RSOA
can manage the adaptation of the robot in its mission, the
reaction will be local if possible.
The bidirectional connection described in the two previous
paragraphs is achieved through the MW thanks to a specific
RSOA module named ROS-DDS Proxy.
B. Connection with the existing robots
Robot capabilities (limits of the operational domain, tasks
and actions that the robot can perform, reactions to specific
events…) are described in a Robot Configuration file. This file
is read when the RSOA starts and configuration file is stored
in the ROS parameters in a structured way, making it available
for each module of the RSOA.
To keep the genericity of tasks and actions and to take into
account the various SWARMs vehicles, the connection with
existing software of one robotic platform has been
implemented through two modules:
The Robot Generic Interface module (RGI) translates
the generic actions into generic commands and stores
situation, status and environmental data received from
the Robot Specific Interface;
The Robot Specific Interface module (RSI) is connected
in a bidirectional way with the Robot Generic Interface.
It translates generic commands into robot specific
commands and collects data, events and faults of the
robot; this module was developed by vehicle providers
with the help of RSOA developers.
C. Supervisor function
The Robot Supervisor module is central in the RSOA and
based on a model of the expected behaviour of vehicles in
nominal situation and when disruptive events occur. It receives
a set of tasks or actions from the MMT; when tasks are
received, the supervisor interacts with the Robot Planner
function to obtain the set of actions to be executed.
In nominal situation, the supervisor executes the actions
and monitor their execution; it then interacts with the Robot
Generic Interface for actions dispatching and status reporting.
When an event invalidates the current plan (alarm coming
from the platform or elaborated by the Robot Monitor
function), the supervisor manages the reaction to this event. In
some cases it can call the Robot Planner to generate a new
plan or repair or adapt the current one, based on the updated
current situation of the vehicle.
The Supervisor has full authority to manage the generation
and execution of plans ofactions; it may request for a plan
generation, start, suspend, resume or abort the execution of a
plan.
D. Planner function
The Robot Planner module can produce an individual plan
of actions for each high level task. Three types of planners are
available onboard:
Area coverage: covering a given area with a given
sensor;
Motion planning: finding the best path(s) from a
location to another;
Resource management (battery, sensors switched on and
off...)
This function is not called when actions are directly sent by
the MMT, and in this case there is no recomputation of plan at
the vehicle level: the disturbing events are globally treated at
the MMT level.
Planners in the RSOA correspond to the different tasks
identified in underwater operations for the SWARMs project:
TRANSIT, INSPECT, SURVEY, PICK_UP. The planner can
also be used to build reaction plans to cope with some events.
These tasks are SURFACE, REFERENCING, RECOVER and
SETMODE. For instance when a loss of positioning precision
is detected by the platform vehicle an event is generated and
the Supervisor trigger a reaction by asking to the planner to
build a SURFACE plan to get a GPS positioning before
resuming the ongoing mission plan.
For each of these possible tasks the Robot Planner is able
to deliver a plan of actions. For some tasks there are several
possible planners. At the moment the choice of the planner to
use is specified in the task specification part of the vehicle
configuration file.
E. Monitor function
The Robot Monitor module produces high level health and
performance indicators: it monitors the different activities
going on at vehicle level and generates events or alarms when
unexpected behaviour is detected. The monitor integrates both
numeric and qualitative reasoning to provide diagnosis (now)
and prognostic (future) for each generic vehicle action. It is
therefore directly connected on the one hand to the Robot

Generic Interface module and on the other hand to the Robot
Supervisor module.
The module monitors position, depth, heading and
measurements as well as the current action performed and
raises alarms when detecting abnormal values. When abnormal
values are detected repeatedly, they are escalated into more
severe alarms according to a model expressed with temporal
logic. The uncertainty about the cause of abnormal values is
resolved via a model expressed with conditional preferences.
More information is given in [1].
F. Implementation
All modules of RSOA have been implemented using the
Robot Operating System (ROS) framework. Fig. 1 shows the
final architecture. This architecture has been implemented in
several SWARMs vehicles (mentioned later on in the paper).
Fig. 1. Modules of the Robot Software Onboard Architecture RSOA.
III. ROMANIA DEMONSTRATION JULY 2017
After early trials in Gran Canaria Island (Spanish) on the
Atlantic Ocean in September 2016, the first SWARMs project
demonstration took place in Mangalia (Romania) in July 2017,
on the Black Sea.
A part of RSOA was implemented in the control station of
2 ROVs and onboard 1 USV. Its whole capabilities were
mainly evaluated by simulation.
An Underwater Unmanned Vehicle (UUV) simulator [2]
has been developed during the project. It is based on the 3D
open source robotics simulator Gazebo and allows the
simulation of environment and vehicle dynamics. Simulations
allowed to check the progress of work early in the project, are
free from experimental constraints and allow going beyond the
experimental capabilities in terms of mission scenario, number
of vehicles, type of payload…
Many figures in this paper are representation of the mission
using the rviz ROS visualisation tool.
A. Simulation
The simulated use case was a sonar survey mission
performed by a swarm of 8 vehicles (6 AUVs and 2 ROVs) on
a 200m x 200m area, each vehicle implementing one RSOA.
Fig. 2. Simulation mission area in Romania.
The area has then been divided in 8 subareas (Fig. 2). Each
vehicle has been assigned by hand to one subarea and several
recovery points were available (Fig. 3). There was no
connection with the MMT for these tests and a specific
mission management system sent the high level survey tasks to
vehicles. Once received, the mission started. Each local survey
was computed by the Robot Planner; the survey task, sonar
scanning along a boustrophedon-shaped trajectory, was
translated into a list of “follow row” and “go to waypoint”
actions.
Fig. 3. Simulation mission in Romania.
Several runs highlighted the nominal and reconfiguration
capabilities of the architecture:
Nominal execution of the mission (Fig. 4): basic
planning, execution and supervision of actions
(including activation and deactivation of payload),
storing of robot position, robot status, environment data
and robot alarm;
On line and autonomous adaptation to disruptive events
(plan repair): deviation due to a loss of propulsion
efficiency under strong currents (Fig. 5), breakdown of
one side scan sonar (Fig. 6);
Recovery operation (Fig. 7): aborting of mission,
selection in real time of one recovery area, recovery
achievement.

Fig. 4. Simulation of the Romania nominal execution (the 2 ROVs on the left
below subareas have a relative lower speed).
Fig. 5. Reactions to the detection of a strong deviation (auv22 ends its
mission by making a kind of hippodrome; the global reaction to send another
vehicle to replace it was not done because the MMT was not in the loop).
Fig. 6. Reactions to the breakdown of one side of the side scan sonar (the
strategy was to continue the same planned rows until the end of the planned
survey then to turn back and to follow the same rows in the other sense so as
to complete the cover).
Fig. 7. Recovery operation towards areas indicated with a red arrow and
selected on line by the RSOA.
B. Experimentation
The RSOA has been adapted to 3 experimental vehicles:
Desistek Robotics SAGA and Autonomous Systems
ATN50 ROVs: integration of part of the RSOA in their
Command and Control Stations;
Leonardo Static USV: integration of part of the RSOA
in the vehicle. The GPS position was well received and
the RSOA managed the three onboard payloads.
IV. N
ORWAY DEMONSTRATION, JUNE 2018
The second and final SWARMs project demonstration took
place in the Trondheim fjord (Norway) end of June 2018. The
use case was to detect and track a plume of traversable
pollutant so as to be able to find and act on the leak. The
plume was detected by monitoring the water salinity that
decreased in the presence of unsalted pollutant. The added
capabilities of the RSOA required the enhancement of all
modules and the adaptation of functions to the new scenario.
The full version of RSOA was integrated in 3 AUVs: Fridtjof
LAUV from NTNU and 2 Noptilus LAUVs from Porto
University UPTEC. The RSOA was also implemented onboard
the Telemetron USV from Maritime Robotics.
The UUV Simulator was enhanced with the objective to
simulate the new experimental scenario and especially to
model of the Trondheim environment and the vehicles that
participated to the experimentation.
A. Norway scenario
While the Romania simulation scenario was especially
built for the evaluation of the RSOA, the Norway simulation
scenario (Fig. 8) replicated the complete experimental scenario.
In order to detect the plume, the research area was covered
by the 3 AUVs moving at different depths. The size of the
whole search area was 400m x 400m. All AUVs were
deployed far from each edge of the area at a sufficient distance
to dive and ascend in safety conditions. The plan computed at
the beginning of the mission was computed for each AUV to
perform a survey while acquiring salinity data. The USV was
used to relay the communication between AUVs and the MMT;
it was making circles in the North-East outside the research
area to avoid a possible collision as the AUVs could surface
anytime. A ROV could then investigate the seabed and act on
the leak once its location is known enough. The recovery
points were the initial points for each vehicle; the recovery
procedure was for each vehicle to join them first at the safety
survey depth before going to the surface outside the survey
area.
The plume was emulated both in the global simulation and
experimentally; the virtual leak was in the North-East of the
area and was pushed towards the South and the surface
because of diffusion, buoyancy, and a simulated current.

Citations
More filters

Proceedings ArticleDOI
01 Jun 2020
TL;DR: The main advantages of the proposed solution are the increase of the mission management system reliability level and the reduction of costs, thanks to the adoption of same "core" section for different kinds of transport platforms and the employment of Micro Electro-Mechanical System devices.
Abstract: This paper presents the design study developed to realize an innovative mission management system that can be installed onboard different unmanned vehicles. The main aim of the project is the standardization of system processes by employing a modular architecture, that can be adopted for several mission profiles. The activity focus is set on the system components design in order to assess specific processing applications. So, after the identification of common processes among platforms, traditional onboard functions can be implemented, such as Guidance, Navigation and Control (GN&C). This innovative system architecture is characterized by a "core" section, that includes the processing units, and a "custom" section, that involves specific vehicle devices, such as sensors, antennas, and actuators. Considering the modular approach, the optimized design must be selected for each of these units, allowing easier onboard installation and systems exchange. Assessing the specific inputs and combining the "core" processes it is possible to realize synthetic functions that reconstruct the traditional functions outputs. The main advantages of the proposed solution are the increase of the mission management system reliability level and the reduction of costs, thanks to the adoption of same "core" section for different kinds of transport platforms and the employment of Micro Electro-Mechanical System devices.

4 citations


Cites background from "A generic and modular architecture ..."

  • ...Modularity intent carries a challenging employment of the already developed technologies, but there are several studies about the adoption of embedded systems to obtain modular architectures and open systems, as reported in [10] [11] [12] for UAS design, and in [13] [14] for maritime applications....

    [...]


Proceedings ArticleDOI
09 Nov 2020
TL;DR: An algorithm that translates the segmented mask of bollard output from masked R-CNN along with bounding box and associated class probability to its corresponding edge coordinate and finally to the single reference point for efficient detection and classification of bollsard towards autonomous mooring is presented.
Abstract: Bollard is a vital component of mooring system. It is the anchor point for mooring ropes to be fixed in order to secure the vessel or ship. An algorithm that translates the segmented mask of bollard output from masked R-CNN along with bounding box and associated class probability to its corresponding edge coordinate and finally to the single reference point for efficient detection and classification of bollard towards autonomous mooring is presented. At first stage, Mask R-CNN framework is trained with custom built bollard. The model obtained from the training is inferred with real data resulting in instance segment of bollard. The segmented mask obtained contains relatively large amount of the data points representing the whole area of bollard, which typically is not desirable. In order to precisely localize the bollard with one reference co-ordinate, the proposed algorithm is applied to segmented mask. Firstly, it translates the segmented mask to only four co-ordinate points, where each point correspond to the edge of bollard. Further, from the edges, the reference point is estimated. This causes significant reduction in point of interest (POI) and has potential to reduce the error encountered during pose estimation of the bollard in 3D thus making the autonomous mooring more precise and accurate.

3 citations


Cites background from "A generic and modular architecture ..."

  • ...Magali [2] developed generic and modular architecture for maritime autonomous vehicle Robot System Onboard Architecture (RSOA)....

    [...]


Journal ArticleDOI
TL;DR: A contract-based verification framework is presented that includes automatable and formally analyzable behavioral descriptors in form of assumption-guarantee contracts for all phases of the software lifecycle to provide static and dynamic verification capabilities alongside a dynamically changing system composition.
Abstract: Modern control systems in the maritime domain are increasingly controlled by software systems and become subject to updates and configuration changes during operation. Moreover, with the shift to autonomous vessels and cars, these software-based systems are taking on more and more safety-critical tasks, so the risks associated with system failures are increasing. Unlike before, it becomes necessary to verify the continuously adapting modules of a vehicle not only before deployment, but to establish continuous verification capabilities during all phases of the product lifecycle, from the design to the system in operation. Hence, in case of an update, deviations from the expected behavior can be automatically detected and relevant measures can be initiated. In this work, a contract-based verification framework is presented that includes automatable and formally analyzable behavioral descriptors in form of assumption-guarantee contracts for all phases of the software lifecycle to provide static and dynamic verification capabilities alongside a dynamically changing system composition. By utilizing contractually defined behavior descriptions, classic test procedures, such as simulations, are supplemented by a formally testable level that is applied to all phases of the update process. A conceptual-deductive methodology was chosen, building on the identified requirements to develop an overarching update framework that adds contractual descriptions to the traditional development case. Based on the presented framework, the verifiable modification of a safety-critical software system is demonstrated. The approach is evaluated using a maritime collision-avoidance system and the verification steps are evaluated along the update process. The framework offers a novel approach to complement existing test procedures by enabling formal impact analysis and incremental verification of updates.

1 citations


Proceedings ArticleDOI
01 Apr 2019
TL;DR: This paper presents an application of a new plan repair algorithm proposed recently, the 15-puzzle algorithm with potential with potential to the concrete context of underwater autonomous vehicles mission planning.
Abstract: Plan repair is a field of AI planning which is related to plan execution since it requires the monitoring of the actions to be executed. This paper presents an application of a new plan repair algorithm we proposed recently, the 15-puzzle algorithm with potential [18]–[20] to the concrete context of underwater autonomous vehicles mission planning. In a multi-drone mission in underwater environment, one must repair a plan when a vehicle breaks down. We propose a model for the plan repair problem and show results obtained with our algorithm.

Cites background from "A generic and modular architecture ..."

  • ...will provide some theoretical aspects of a plan repair problem starting from a concrete scenario of the underwater application [1]....

    [...]


References
More filters

Proceedings ArticleDOI
01 Sep 2016
TL;DR: The Unmanned Underwater Vehicle Simulator is described, an extension of the open-source robotics simulator Gazebo to underwater scenarios, that can simulate multiple underwater robots and intervention tasks using robotic manipulators.
Abstract: This paper describes the Unmanned Underwater Vehicle (UUV) Simulator, an extension of the open-source robotics simulator Gazebo to underwater scenarios, that can simulate multiple underwater robots and intervention tasks using robotic manipulators. This is achieved mainly through a set of newly implemented plugins that model underwater hydrostatic and hydrodynamic effects, thrusters, sensors, and external disturbances. In contrast to existing solutions, it reuses and extends a general-purpose robotics simulation platform to underwater environments.

103 citations


"A generic and modular architecture ..." refers background in this paper

  • ...An Underwater Unmanned Vehicle (UUV) simulator [2] has been developed during the project....

    [...]


Proceedings ArticleDOI
12 Nov 2015
TL;DR: This work proposes a plan repair algorithm designed to be used in a real-life setting for a team of autonomous robots and shows that using this knowledge can help the reparation, even when some half-executed abstract actions are present in the plan.
Abstract: In this work we propose a plan repair algorithm designed to be used in a real-life setting for a team of autonomous robots. This algorithm is built on top of a hybrid planner. This planner mixes partial order planning and hierarchical planning. This allows the creation of a plan with temporal flexibility while using human knowledge to improve the search process. Simulation shows that repairing increases the number of solved problems or at least reduces the number of plans explored. The algorithm uses the same hierarchical knowledge as the underlying planner, thus needing no more human modelling to properly run. We show that using this knowledge can help the reparation, even when some half-executed abstract actions are present in the plan.

7 citations


Additional excerpts

  • ...Global strategies could be developed like those ones evaluated for the survey of an area by a team of aerial and terrestrial vehicles in the ACTION project [3]....

    [...]


Proceedings ArticleDOI
06 Jan 2018
TL;DR: An estimation approach based on constrained optimization using conditional preference theories is proposed, and it is shown that in some cases, the estimator can fail to find an estimation for the system.
Abstract: We address the problem of intermittent fault diagnosis as an instance of discrete signal estimation, in the context of fault management in autonomous systems and autonomous vehicles. We propose an estimation approach based on constrained optimization using conditional preference theories. We show that in some cases, our estimator can fail to find an estimation for the system. We provide a way to detect and eliminate these cases at design time.

4 citations