VISIR
(discoVerIng Safe and effIcient Routes) is an operational decision support
system (DSS) for optimal ship routing designed and implemented in the frame
of the TESSA (TEchnology for Situational Sea Awareness) project. The system
is aimed to increase safety and efficiency of navigation through the use of
forecast environmental fields and route optimization. VISIR can be accessed
through a web interface (
Targeted services based on operational outputs from geophysical models
represent a new paradigm of knowledge. In fact, for enabling operational use
even by decision makers with a limited knowledge of the underlying natural
processes, these services require technological tools of increasing
complexity and robustness
In the framework of maritime safety and efficient transportation, situational
sea awareness through the operational distribution of oceanographic and
meteorological information is a key enabler of technological applications. In
fact, the use of marine weather forecasts for route recommendations has been
since long recognized
However, due to the limited spatial and temporal resolution of the
oceanographic forecast products, so far applications have dealt mainly with
large ocean-going motor vessels or racing and leisure sailboats, mainly in a
regime of open-sea navigation. In recent years, the operational availability
of coastal observatories and high-resolution ocean forecast products have paved
the way for applications to be used even in enclosed seas and coastal waters
A list of both institutional and commercial ship routing systems is provided
by
A new concept of Sea Traffic Management (STM) has been developed during the
MONALISA series IEC 61174, edition 4:
The Finnish transport agency developed
ENSI
Promising work has been performed at NTNU for short-sea routing of vessels
supplying offshore installations
To the best of our knowledge, an open-access, operational ship routing system
using state-of-the-art meteo-oceanographic forecasts for route
optimization had been missing before we, in the frame of an Italian national
project aimed at technological transfer (TESSA: TEchnology for Situational
Sea Awareness), developed VISIR ([vi'zi:r], discoVerIng Safe and effIcient
Routes)
In this paper we mainly report on the technological infrastructure developed
for operating VISIR as a decision support system (DSS). However, we deem it
useful to first provide a compact introduction to the VISIR ship routing
model in Sect.
The model behind the VISIR operational system has been developed from scratch
in the frame of the TESSA project. Its numerical structure is described in
highest detail in
VISIR-I, the first version of the model, employs meteo-oceanographic forecast
products to optimize nautical routes. The optimization objective is to keep
the total sailing time at an absolute minimum while treating safety of
navigation as a constraint. Safety includes, for both motor- and sailboats,
consideration of minimum under-keel clearance (UKC) and, just for motorboats,
dynamical stability checks too. At each VISIR-I run, both a geodetic and an
optimal route are computed. The geodetic route is a least-time route not
taking into account the dynamic environmental conditions but still complying
with the static safety constraints related to the bathymetry and the
shoreline. The optimal route takes into account the dynamic environmental
conditions both to compute vessel kinematics and, just for motorboats, to
avoid the dynamical hazards of navigation. VISIR-I as a model consists, as
reported in the following subsections, of three main components: the
environmental forecasts, the optimization algorithm, and the vessel model.
The MATLAB source code of VISIR-I is made free and open access under a GPL
licence
In VISIR-I both sea-state (waves) and wind forecasts are employed: the sea-state information is used for motorboat routing and the wind information for sailboat routing.
Small- and middle-sized motorboats are considered by VISIR-I.
Peak period was used instead of mean wave period until 13
June 2016.
For sailboats, 10 m height wind forecasts from IFS
model
VISIR-I's optimization is based on a graph-search algorithm. Dijkstra's
algorithm
Two quite different approaches are adopted for modelling the dynamical response of either motor- or sailboats to the environmental conditions, as shortly summarized in the following.
Parameters of the motorboat model and their
values for the case study of Fig.
For motorboats, just displacement vessels (fishing vessels, service boats,
displacement hull yachts, and small ferry boats) are considered in VISIR-I.
Sustained vessel speed is obtained from a balance between the thrust provided
by the propeller and the total resistance applied to the moving hull in any
given sea state. In order to reduce the number of parameters to be set by the
end-user, the motorboat vessel model is kept simple, neglecting several
mechanical effects affecting vessel dynamics; see
Sailboats are described in terms of their “polar plots”. These are response
functions expressing sailboat speed in terms of wind speed and direction. They
stem from either measured sailboat performance or so-called velocity
prediction programmes
In order to make the ship routing system of Sect.
Being multichannel implies that the service is made available across
different web and mobile platforms (desktop computers, tablets, smartphones).
Furthermore, the services are developed keeping in mind the “3C”
paradigm. That is, the user is granted a
consistent, continuous, and complementary experience, through an ecosystem of
platforms where the same service is made available
From a structural viewpoint, the TESSA architecture is a “matrix” of tiers
and vertical applications. The tiers are the clients, the “Situational
Sea-Awareness (SSA) platform”, and the “Complex Data Analysis Module”
(CDAM). The vertical applications correspond instead to the various DSSs (see
Fig.
“TESSA matrix”: the three horizontal tiers and the vertical applications or DSSs. The red shaded area is the VISIR application stack.
Functional structure of the TESSA system. Red boxes refer to VISIR-specific components hosted on the TESSA infrastructure (blue). Cylinders represent databases; boxes are services; icosagons are computational nodes.
The client tier allows the end-user to send commands to and receive results from the SSA platform. The SSA platform bridges a bidirectional communication between the clients and the CDAM and provides maps of environmental fields to the client tier. The CDAM manages the incoming computation requests, runs the model (e.g. the one for ship routing), and returns the results. Furthermore, an application stack distributed between the client tier and the SSA platform provides the end-user with the tools required for interacting with the system.
Keeping in mind the block diagram of Fig.
The VISIR application stack is a system component needed to receive the
end-user's requests and deliver the ship routes to his/her device (see Sect.
The presentation layer is in charge of the visualization through the client
rendering engine. This layer corresponds to the graphical user interface
generally employed by desktop applications. The VISIR presentation layer is
declined into a web application and two mobile applications. The web
application (
The business logic layer is the core part of the application stack and
implements its logic. Its task is to receive, process and meet the incoming
requests from the client. Several RESTful
The data layer is associated with the database engine and is responsible for
the data persistence (within and across sessions A session is here
defined as the user activity comprised between authentication and quitting
from the DSS.
While the presentation layer is platform-specific, the business logic layer and the data layer serve both the channels of the web application and the mobile applications.
The SSA platform provides the infrastructure for processing the environmental
forecast data and making the services available to public users across
different channels, spanning from smartphones and web clients to
(potentially) third-party geographic information systems (GISs)
The web portal is a customized web container hosting the applications and
their web APIs and providing basic shared services like authentication and
user management. Both the VISIR and the DSS portlet are hosted
here. The VISIR portlet provides a universal user interface for
any Optimized for Firefox, Chrome, and Safari.
The map service is a cross-application component (used also by the other
TESSA DSSs) designed to provide both static and dynamic maps and related
functions (like data querying) to external services and applications. The map
service is made up of a web service providing the maps, a batch rendering
system updating the forecast maps on a daily basis, and a computing cluster
performing the actual rendering work. The map service allows distribution of
very large maps by delivering tiles of the environmental field at different
scale as a set of 256-pixel-wide images (“tiles”), greatly improving
efficiency in bandwidth and client resource usage. The indexing of these
images has been defined in the past by different vendors, like Google and
Microsoft
The MB is an intermediate component between the clients and the CDAM dispatching (DSS-specific) job requests to the heavy-duty computing back end, on behalf of the clients (either web or mobile). A call-back mechanism is provided as a hook to the CDAM in order to notify job completion, either successful or not, including the data payload. DSS components use this system in order to notify users about the results of their requests and perform additional actions (e.g. store the results into a historical archive for later retrieval). This software component acts as a store-and-forward queue, as it receives and stores requests, forwards them to the computing engine, and awaits a response. Clients may then retrieve the results by polling for their availability, checking the payload, and extracting the information they require for their work. Additionally, in order to avoid an excessive load, a data retention policy can be enforced (e.g. by setting a limited time before expiration of pending requests or removing old ones).
The Complex Data Analysis Module (CDAM) enables advanced data processing on
the datasets produced by the meteorological and oceanographic models used
within the TESSA project. Specifically, it represents a back-end connector
between the client-oriented services, deployed on the SSA platform, and the
model execution related to a specific DSS
In this perspective, the CDAM was designed and developed in order to hide the
internal complexity of the underlying DSS model and ease the
submission of the execution and the retrieval of the results by the upper
layers of the operational chain. Moreover, a high modularity implements the
separation of concerns, while the adoption of standard interfaces and
existing technologies, such as JSON format and REST web services, ensures
flexibility and interoperability of the software components. Finally, in
order to guarantee a high security level, the incoming requests rely on the
HTTPS
From a technological viewpoint, a two-layer logical architecture has been
implemented (see Fig.
Data flux diagram. The downward-oriented
vertical coordinate is the time elapsed since the user started
interacting with VISIR, while the horizontal coordinate goes from high-level
to low-level operations. Orange shading indicates simultaneously occurring
operations. The dotted lines indicate replicas of steps (5a) and (5a
Correspondence between steps within the data flux diagram (Fig.
Delving into more detail on the CDAM-Gateway, it consists of two modules: the RESTful web interface and the CDAM-Scheduler. The former provides the SSA platform with a uniform REST interface for accepting and managing the job execution requests provided in a JSON format. The latter sets the DSS execution environment and forwards the correct input parameters to the CDAM-Launcher.
Parameters and scores for the least-square fits shown in Fig.
The CDAM-Launcher is hosted on the target computing infrastructure and is
responsible for properly managing the job submission. It relies on the
workload manager SLURM
Following the same approach taken for the job request, the sent-back results are first of all embedded into a JSON object compliant with the specific JSON schema defined for the CDAM.
Following the more structural information from
Sect.
For the description of the logical execution of VISIR, we hereafter refer to
the numbered steps in the sequence diagram of
Fig.
Graph structure of the TESSA system for
running DSSs like VISIR. The nodes refer to points of time measurements: the
user interface (
The access to VISIR is open after authentication (1). At the moment, however,
also a valid subscription is also required in order to run the route
computation service. The authentication is then granted by the DSS portlet
hosted on the SSA platform (2). At this point, after departure and arrival
location for the route have been set, a route computation request can be
submitted (3) in the form of a string of parameters (see Sect. 7). Once it is forwarded through the DSS portlet (3
The different logical functions played by the clients, the DSS portlet, the MB, and the CDAM, enable a physical separation of the assets of the system. This is indeed the case, since the TESSA architecture mirrors the organizational structure of the TESSA consortium.
As outlined in the previous subsections, the TESSA architecture consists of various connected components acting asynchronously.
In order to assess its performance, it is convenient to consider it as a
network whose nodes are linked in a directional way, as in
Fig.
The experimental activity was carried out ensuring that the computational
cluster was nearly idle. Computations of routes up to 500 M length were
requested from the UI. For each given route length, the same departure and
arrival were employed in up to 10 routing jobs during test sessions occurring
on three different calendar dates. The experimental protocol also included
recording timestamps at the various nodes of the network of
Fig.
In Fig.
For longer routes,
For shorter routes however, it is apparent that the values of
Performance of VISIR operational system,
distinguishing between motorboat
Starting from the CDAM
For the SSA
Moving to the UI
In order to understand the results about the
Concerning the slope found in Fig.
The experimental findings above and their analysis enable us to assess the ultimate performance limit of the VISIR technological infrastructure.
There are limiting factors of two types: on the one hand, there are
parameters (such as the computational cost for generating the ship routes the internet-based communication among asynchronous system components.
In particular, (i) dominates the UI waiting time for long routes while
(ii) is the limiting factor for the shorter routes. Fixing item
(i) corresponds to a situation where dedicated computational resources are
available and the performance of the computing algorithm has significantly
improved. It can be simulated by subtracting the duration
If further also item (ii) were fixed by a fast link (optical fiber or so),
the ultimate limit for the VISIR user waiting time would be given by
The end-user experience of VISIR entirely occurs within the presentation
layer of the application stack. Its main elements are a menu, a geographic
map, and a line chart At present, the line chart is just available for
the web application (v.4.2). It is planned that this feature will be made available
for the mobile apps, too.
A crucial point is subsetting the domain (“bounding box”) used by the algorithm for computing the optimal route. In fact, the computational cost of the route computation heavily depends on the bounding box extent. By our choice, it initially corresponds to a box whereby two opposite vertices are the route endpoints. However, due to specific domain topology (peninsular or archipelagic regions) and environmental conditions (leading to unsafe navigation), a suboptimal route or no route at all may result from using the default bounding box. Thus, we designed all the interfaces in a way that the bounding box can be interactively resized. Leaving it to the end-user to decide whether and how to resize the bounding box certainly introduces a degree of subjectivity in the final results of the route computation. However, it is our experience that, after a few trials, the user easily learns how to do it in a conservative and still effective way. In fact, it is sufficient to obtain a result and then submit a new route with a larger bounding box; if there is no change in the results, convergence has been achieved.
Furthermore, if a land-based endpoint is selected (such as “Lecce”), the
next sea position within the bounding box and with positive UKC (i.e. sea
depth larger than vessel draught) is automatically retrieved by the model. It
is also possible to set a minimum offshore distance
Routes with minimum offshore distance
A motorboat route computed by VISIR. A
displacement vessel with parameters as in Table
A sailboat route computed by VISIR. The
shaded field in the maps is the 10 m height wind intensity and its
direction. A “First 36.7” sailboat is employed for the computations. Panels
Three pre-defined sets of motorboat parameters (a displacement hull cabin
cruiser, a fishing vessel, and a small ferryboat) can be selected and edited.
Alternatively, a sailboat type can be picked up from a database of boats with
lengths between 7 and 19 m (Fig.
Upon route submission, a progress bar with an estimate of the waiting time
appears. Due to features of the algorithm,
Sect.
If the route computation fails, a diagnostic message appears with a hint to what should be changed in order to get a successful result. If the route computation succeeds, both a geodetic (black) and an optimal route (red) are displayed on the map.
In order to demonstrate the operational functioning of VISIR, we report in this section about two execution scenarios, one for motorboat and the other one for sailboat.
In Fig.
The VISIR web application displays various combinations of forecast fields on
the geographic map. In Fig.
In Fig.
First of all, we should stress the fact that, due to the limited capability
of producing thrust through wind, a sailboat route between given endpoints is
not always feasible. In particular, there are limitations for upwind motion
and for too weak or too strong wind intensities
In Fig.
The sailboat routing is at the moment available, besides on the web
application, just on a development version of the Android mobile application.
A few previews of the tablet (Fig.
Starting from the VISIR model, a DSS for on-demand computation of optimal ship routes in the Mediterranean Sea has been put into operations. It addresses small displacement hull motorboats and sailboats of various sizes. Shoreline and bathymetry are the static databases used for checking the minimal requirements for the safety of navigation. Forecasts of sea state and wind from third-party providers are the dynamical information used for checking vessel stability and for the minimization of the route duration. The operational system is available cross-channel. Client applications for the web browser and iOS and Android devices have been developed.
The infrastructure developed for running VISIR in an operational way is to a
large extent general, and it was successfully employed as a template for
other DSSs developed within the TESSA project
(
One of the most significant authors' experience is that the realization of the VISIR operational system (2013–2015) also had a positive feedback on the initial phase (2012–2014) of development of the VISIR ship routing model. This was due to the fact that the operational service required the model to reach a level of robustness far beyond the case study testing. Exceptional and challenging environmental conditions highlighted issues and bugs of the model, and the demanding computational requirements of a multiuser system pushed for a more and more efficient model code.
It is important to stress that the technological infrastructure developed for
running VISIR in operational mode allows an end-user to drive the execution
of a state-of-the-art research model, customizing his/her route needs, vessel
features, and level of safety. The fact that the scientific and computational
issues behind the UI are made transparent to the UI end-user is one of the
main achievements of the architecture. Furthermore, it allows for avoiding
heavy computations on the device used to access the system while minimizing
the amount of data transferred to it from the computational facility. The
performance of the TESSA architecture VISIR runs within has been assessed
through extensive experimental tests. They indicate that, upon removal of the
major bottlenecks, the ultimate limit for the VISIR end-user waiting time
could be a few seconds (Sect.
Numerous developments of the VISIR ship routing model are envisioned, and some
of them were already discussed in
Both the input and the output data relative to the case studies displayed in
Figs.
In the input data directory we provide:
The submission string generated upon user request of a route computation (Sect. The namelists ( The
In the output data directory we provide:
A log of the input namelist ( The detailed voyage plans relative to both the geodetic
( A report of the main results from the VISIR job (
Funding through TESSA (PON01_02823/2) project is gratefully acknowledged. Yogesh Kumkar and Andrea Villani are thanked for their initial contribution to the development of the operational infrastructure and the VISIR mobile application for Android, respectively. Roberto Bonarelli provided appreciated feedback on the sailboat interface. Charlotte P. Martinkus contributed to the experimental activity to assess the system performance. Edited by: A. Olita Reviewed by: C. Granell and one anonymous referee