VISIR: Technological infrastructure of an operational service for safe and efficient navigation in the Mediterranean Sea

VISIR (discoVerIng Safe and effIcient Routes) is an operational Decision Support System (DSS) for 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 both a web interface (www.visir-nav.com) and mobile applications for both iOS and An5 droid devices. This paper focuses on the technological infrastructure developed for operating VISIR as a DSS. Its main components are described, the major challenges faced by the operational system are highlighted, and its potential for interoperability is outlined.


Introduction
Situational sea awareness through the operational distribution of oceanographic and meteorological 10 information is a key enabler of technological applications for maritime safety and efficient transportation. In fact, the use of marine weather forecasts for route recommendations has been since long recognized (Bowditch, 2002).
However, due to the limited spatial resolution of the oceanographic forecast products, so far applications have mainly dealt with large ocean-going motor vessels or racing and leisure sailboats, 15 mainly in a regime of open-sea navigation. In recent years, the operational availability of coastal observatories and high resolution ocean forecast products opened the way to applications even in enclosed seas and coastal waters (Proctor and Howarth, 2008). A list of both institutional and commercial ship routing systems is provided by Lu et al. (2015), and some major commercial softwares 1 Nat. Hazards Earth Syst. Sci. Discuss., doi:10.5194/nhess-2016-32, 2016 Manuscript under review for journal Nat. Hazards Earth Syst. Sci. Published: 10 February 2016 c Author(s) 2016. CC-BY 3.0 License. are compared in Walther et al. (2014). A few other systems are here reviewed with an emphasis on 20 their operational functioning.
In Montes (2005) it is reported about a model for automatizing the Optimum Track Ship Routing (OTSR) service provided by the U.S. Navy to own ships. It is a least-time routing system based on wave forecasts, whereby the safety of navigation is accounted for through speed penalty functions related to the sea state. Interestingly, model outputs are validated versus historical records of route 25 diversions by the U.S. war ships in the western Pacific Ocean. However, the operational system is not publicly accessible.
The Finnish transport agency developed ENSI 1 , a system for providing ships navigating in the Gulf of Finland with a shore-based support. The route is first planned onboard using an ECDIS, then it is broadcast to a Vessel Traffic Centre, where is validated against topological and marine weather 30 information, and finally is broadcast back to the ship. Warning items are issued if the shore-based centre detects that the onboard planned route is either to cross a traffic separation scheme or to sail over shallow water.
A new concept of Sea Traffic Management (STM) has been developed during the MONALISAseries European projects 2 and is going to be implemented in the coming years, starting with the STM 35 Validation project 3 . In the current definition of STM, the marine voyage is the central object of analysis and development (Siwe et al., 2015). A common format and architecture for a seamless exchange of route information and voyage plans was designed and standardized during the MONALISA 2.0 project 4 . In the STM framework, voyage management services will provide support to individual ships in both the planning process and during the voyage, also making use of route optimization 40 services.
To the best of our knowledge, an open access, operational ship routing system, using state-ofthe-art sea state and marine weather forecast for the route optimization, was still missing before we, in the frame of an Italian national project aimed at technological transfer (TESSA), developed VISIR ([vi'zi:r], discoVerIng Safe and effIcient Routes) 5 . VISIR is meant to provide an open (not 45 necessarily free) access, user-oriented, cross-channel system for on-demand computation of optimal routes for various kind of both motor-and sailboats navigating in the Mediterranean Sea. In VISIR-I, the first version of the system, optimization regards the total time of navigation, keeping into account safety of navigation.
In this paper we mainly report about the technological infrastructure developed for operating 50 VISIR as a Decision Support System (DSS). However, we deem useful to first provide a compact introduction to the VISIR ship routing model in Sect.2. A detailed presentation of the operational system follows in Sect.3, and examples of functioning in Sect.4. The conclusions given in Sect.5 1 https://www.ensi.fi/portal/ 2 http://monalisaproject.eu/ 3 http://stmmasterplan.com/ 4 IEC 61174, edition 4: https://webstore.iec.ch/publication/23128 5 http://www.visir-nav.com/ summarize the authors' experience gained while realizing VISIR, and discuss the more general perspectives for this kind of technological infrastructure.

55
2 The ship routing model 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 .
The model is presently coded in Matlab.
VISIR-I, the first version of the model, employs meteo-oceanographic forecast products to the end 60 of optimizing nautical routes. The optimization objective is the total sailing time, to be kept at an absolute minimum, while treating safety of navigation as a constraint. Safety includes consideration of minimum Under Keel Clearance (UKC, for both motor-and sailboats) and dynamical stability checks (just for motorboats). VISIR-I consists of three main components, as reported in the following subsections: the environmental forecasts, the optimization algorithm, and the vessel model.

Environmental forecasts
In VISIR-I both sea-state (waves) and wind forecasts are employed: the wave information is used for motorboat and the wind information for sailboat routing.
Small and middle sized motorboats are considered by VISIR-I. In  it is discussed what the most relevant environmental couplings for this class of vessels are, concluding 70 that waves are likely to be the most impacting phenomena. Thus, VISIR-I employs wave forecast fields from an operational implementation of Wave Watch III (WW3) model in the Mediterranean Sea (Tolman, 2009). The employed fields are significant wave height, peak wave period and wave direction. They are provided with hourly resolution on a 1/16 degree (i.e., 3.75 miles in the meridional direction) mesh. The forecasts originating from the 12:00 UTC analysis are employed.

75
For sailboats, 10 meter height wind forecasts from IFS model operated by the European Centre for Medium-Range Weather Forecasts (ECMWF 6 ) are employed. The model outputs are available with 3-hourly resolution for the first 3 days after the analysis, the horizontal resolution is 1/8 degree (7.5 miles in the meridional direction), and the forecasts refer to the 12:00 UTC analysis.

80
VISIR-I's optimization is based on a graph-search algorithm. Dijkstra's algorithm (Dijkstra, 1959) is chosen, for its ease of implementation and the fact that, not depending on any heuristics, it is guaranteed to find an optimal solution. Furthermore, since the environmental forecasts are represented by time-dependent fields, the algorithm is modified along the guidelines by Orda and Rom (1990) for ingesting such a dynamic information. Furthermore, VISIR's algorithm allows for voluntary ship 85 speed reduction. This option enables the ship not to change course for ensuring the vessel stability constraints, resulting in additional savings of navigational time. All the mathematical details, the algorithm's validation, and its pseudocode are provided in . The target grid for the optimization is a 1/60 degree (1 mile in the meridional direction) regular mesh and the connectivity of the graph is such that angles of about 27 degree can be resolved. Furthermore, VISIR is 90 capable of avoiding the landmass even in topologic complex areas, such as peninsulas, islands, and archipelagic seas.

Vessel model
Two quite different approaches are adopted for modelling the dynamical response of either motoror sailboats to the environmental conditions, as shortly summarized in the following.

95
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 various kind of resistances 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 100 dynamics, see  for more details. The six parameters to be provided by the end-user are listed in Tab.1. Furthermore, vessel stability in a seaway is considered (IMO, 2007). In particular, the dynamical conditions for the activation of three stability loss mechanisms are checked for: parametric roll, pure loss of stability, and surfriding/broaching-to (Belenky et al., 2011). Graph edges leading, for a specific time step, to stability loss are removed from the graph previously to the 105 run of the optimization algorithm. This way, it is ensured that optimal route does not result in an exposure to dynamical hazards.
Sailboat are described in terms of their "polar plots". These are response function expressing sailboat speed in terms of wind speed and direction. They stem from either measured sailboat performance or so called "Velocity Prediction Programs" (de Jong et al., 2008). In VISIR-I, polar plots for 110 a given and fixed sail are considered. Each polar plot contains a no-go-zone, accounting for the fact that direct navigation into the wind is not possible. More on this subject can be found in (Mannarini et al., accepted, 2015).

The operational system
In order to make the ship routing system of Sect.2 operational, a hardware and software infrastructure 115 has been built in the frame of the TESSA project. In addition to VISIR, TESSA also supported the development of several other DSSs using the outputs of meteo-oceanographic models: for instance an oil spill management DSS 7 and a DSS for supporting marine search and rescue operations 8 were 7 http://www.witoil.com/ 8 http://www.ocean-sar.com/ 4 Nat. Hazards Earth Syst. Sci. Discuss., doi:10.5194/nhess-2016-32, 2016 Manuscript under review for journal Nat. Hazards Earth Syst. Sci. Published: 10 February 2016 c Author(s) 2016. CC-BY 3.0 License. also developed. All the input meteo-oceanographic model outputs can be accessed from the Sea-Conditions 9 portal. VISIR as an operational system inherits the infrastructural approach by TESSA, 120 which is a web-based architecture, exposing multichannel functionality and decoupling the service front-and backend.
Being multichannel implies that the service is made available across different web and mobile platforms (desktop computers, tablets, smartphones). Furthermore, the services are developed having in mind the the "3C" paradigm (Levin, 2014). That is, the user is granted a Consistent, Continuous, 125 and Complementary experience, through an ecosystem of platforms where the same service is made available. This is realized through the decoupling between service front-and backend, enabling a thin client to drive complex data analysis on a supercomputing facility.
From a structural viewpoint, the TESSA architecture is a "matrix" of tiers and vertical appli- 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.
Having in mind the block diagram of Fig.2, the functioning of application stack, SSA-platform, and CDAM is further detailed in the next three subsections, while the execution logic of the system 140 is documented in Sect.3.4. The section ends with a subsection describing the end-user interaction with the system, Sect.3.5.

The application stack
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. As seen from Fig.1, the application stack consists of compo-145 nents based on both the client tier and the SSA-platform. It is structured as a multi-layer architecture, which maps the system infrastructure to the physical layer on which the application is deployed and executed. In particular, the following three layers characterize the application stack: the presentation layer, the business logic layer, and the data layer.
The presentation layer is in charge of the visualization through the client rendering engine. This 150 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 (www.visir-nav.com) is a single-page application, providing universal, full-featured, cross-9 http://www.sea-conditions.com/ 5 Nat. Hazards Earth Syst. Sci. Discuss., doi:10.5194/nhess-2016-32, 2016 Manuscript under review for journal Nat. Hazards Earth Syst. Sci. Published: 10 February 2016 c Author(s) 2016. CC-BY 3.0 License. platform access to VISIR. It is coded in Javascript and Java. The mobile applications have been implemented natively for each platform, i.e. in Objective C for iOS, and in Java for Android. The ra-155 tionale of creating native applications is to exploit at best the hardware resources (definitively GPS, and possibly other device sensors), optimizing visual performance, and enhancing platform-specific user experience. For instance, a platform-specific type of Map Service is adopted: either MapKit Framework 10 for Apple devices, or Google Maps 11 for the web application and the Android devices.
Examples of the presentation layer are provided in Sect.4. The mobile applications have been made 160 available on the App Store and GooglePlay.
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 (Fielding, 2000) 12 services have been developed in order to manage these requests, and to forward the required information to the other components of the infrastructure. The business logic layer is also responsible 165 for exchanging information with the data layer.
The data layer is associated to the database engine and is responsible for the data persistence (within and across sessions 13 ) and their querying. It receives and fulfils the database read/write requests coming from the business logic layer. In particular, by means of this layer, all the parameters related to the ship route computation and all the results produced by the VISIR model are stored into 170 the database of the SSA-platform.
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
The SSA-platform provides the infrastructure for processing the environmental forecast data and 175 making the services available to public users across different channels, spanning from smartphones and web clients to (potentially) third-party Geographic Information Systems (GIS). The SSA-platform architecture can be divided into several components: a Web Portal, a Map Service, and a Message Broker, cp.  The Web Portal is a customized web container hosting the applications, their web APIs, and providing basic shared services like authentication and user management. The VISIR-portlet (providing a universal user interface for any 16 web browser) is hosted here. The DSS-portlet is a high level software component that provides the client tier with authentication and authorization policies and 10 https://developer.apple.com/library/ios/documentation/MapKit/Reference/MapKit_Framework_Reference 11 https://developers.google.com/maps/documentation/android-api/reference 12 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm 13 A session is here defined as the user activity comprised between authentication and quitting from the DSS. 14 http://www.w3.org/Protocols/ 15 http://www.json.org/ 16 Optimized for: Firefox, Chrome, Safari. Furthermore, the dynamic maps service also provides an experimental WMTS service for improved interoperability with external GIS software. A RESTful API is provided to the clients for querying the available maps and accessing the data browsing functions (Sect.2.1). The batch rendering system 200 periodically fetches environmental data from the Environmental Data Storage (EDS) of the CDAM into a (SSA-platform) local EDS and triggers their initial ingestion within the system, Fig.2. The process also includes basic integrity checks and partial rendering of maps. That is, in order to save resources, the batch rendering system pre-renders just a limited set of map tiles, allowing a rapid response for most frequently used maps. For the remaining tiles, an on-the-fly rendering is triggered, 205 queueing the task to the computing cluster.
The Message Broker is an intermediate component between the clients and the CDAM dispatching (DSS specific) job requests on behalf of the clients (either web or mobile) to the heavy-duty computing backend, see Sect.3.3. 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 210 use this system in order to notify users about the results of their requests and perform additional actions (e.g., store the results into an 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 215 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). From a technological viewpoint, a two-layer logical architecture has been implemented (see Fig.2lower tier). The first layer, the CDAM-Gateway, has been designed to be the entry point for job submissions; it is responsible for managing the incoming requests and for interfacing with the target infrastructure for the algorithm execution. The second layer, the CDAM-Launcher, has the responsi-235 bility to perform the submission and to correctly manage the job execution.
Delving into more detail of the CDAM-Gateway, it consists of two modules: the RESTful web interface and the CDAM-Scheduler. The former provides the SSA-platform with an uniform REST interface for accepting and managing the job execution requests provided in a JSON format. The latter sets the VISIR execution environment and forwards the correct input parameters to the CDAM-

Execution logic
For the description of the logical execution of VISIR, we hereafter refer to the numbered steps in the sequence diagram of Fig.3.
The access to VISIR is open after authentication (1). At the moment, however, also a valid sub-255 scription is 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). Once it is forwarded through the DSS-portlet (3') to the Message Broker, a correlation-ID is provided back to the DSSportlet (4a). At the same time, the Message Broker forwards the request to the CDAM (4b). While 260 the VISIR model is run on the supercomputing facility controlled by the CDAM (5b), a polling activity starts at the client (5a) and is forwarded down to the level of the Message Broker (5a'). Such a querying is iterated till the Message Broker has received the model results from the CDAM (6).
They are immediately propagated up to the level of the DSS-portlet (7) and, finally, to the client (8).
The different logical functions played by the clients, the DSS-portlet, the Message Broker, and 265 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.

Use of the system
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 linechart 21 . Upon authentication, the 270 submission of a route computation can be completed by a minimum of three clicks. The left menu offers three modality to enter the two locations between which the route has to be computed: i) by typing their lat/lon coordinates; ii) by clicking/tapping on their positions on the map; iii) by typing the name of a land-based location. The latter option exploits, depending on the platform, a Google or MapKit Framework API for georeferencing toponyms (e.g. "Otranto" is mapped to (40.14390 N, 275 18.49117 E) ).
A crucial point is subsetting the domain used by the algorithm for computing the optimal route. By default, this domain corresponds to a box whereby two opposite vertexes 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 280 the default bounding box. Thus, we designed all the interfaces in a way that the bounding box can be interactively resized. 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. Three pre-defined sets of motorboat parameters (a displacement hull cabin cruiser, a fishing vessel, and a small ferryboat) can be selected and edited. waiting time. This is why it is provided by the VISIR dialog window together with an uncertainty, 295 whose value is identified by means of empirical tests, like those provided in Fig.4. From a comparison between the waiting time found by a VISIR end-user and the bare algorithm running time, it is apparent that, for short routes (below 100 NM), the waiting time approaches an offset of a few seconds, while the time spent in the optimization algorithm scales down with a power law. Thus, the offset time is attributed to model pre-processing tasks and the bi-directional communications among 300 the system components (steps 1.-3. and 6.-8. in Fig.3). For longer routes instead, both the waiting time and the algorithm performance increase with a power law of the route length. Fitted coefficients of such trends are reported in Tab.3.
If the route computation fails, a diagnostic message appears, with a hint to what should be changed in order to get a successful result. We list a few of such diagnostic messages in Tab.2. If the route 305 computation succeeds, both a geodetic and an optimal route are displayed on the map. 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 the end of computing vessel kinematics and, just for motorboats, also for avoiding the dynamical hazards of navigation (see

Examples
In order to demonstrate the operational functioning of VISIR, we report in this section about two execution scenarios, one for motor-and the other one for sailboat.

315
In Fig.5 a fishing vessel route in the Aegean Sea is displayed. The geodetic route connects departure and arrival location while skipping the islands in between. The optimal route, besides avoiding the shoreline, contains a significant eastbound diversion (Fig.5a). This is instrumental in avoiding the 10 Nat. Hazards Earth Syst. Sci. Discuss., doi:10.5194/nhess-2016-32, 2016 Manuscript under review for journal Nat. Hazards Earth Syst. Sci. Published: 10 February 2016 c Author(s) 2016. CC-BY 3.0 License. rough seas experienced along the geodetic route. The resulting optimal route, though 24 miles longer, is nearly 1 hour faster than the geodetic one.

320
The VISIR web application allows displaying on the geographic map various combination of forecast fields. In Fig.5a the peak wave period and wave direction fields are shown. Furthermore, the linechart below the map can display various kinematical and environmental fields along the routes (Fig.5b,c). Each waypoint on the map is bijectively linked to the corresponding waypoint on the linechart (note highlighted waypoints in Fig.5a,b), enabling an immediate georeferencing of 325 linechart information, or, inversely, temporal localization of a waypoint. Furthermore, upon querying a waypoint (either from the map or from the linechart), the map of the forecast field at that specific time step is displayed, highlighting the time-dependent information processed by the VISIR model. In Fig.5b the vessel Speed Over Ground (SOG) for both routes is compared to the top speed of the vessel in calm weather conditions. It is seen that the optimal route, sailing in calmer seas, 330 enables the vessel's propulsion system to sustain a larger SOG. The route performance information are summarised in the route register in the left menu. As another option, the safety indexes for vessel stability discussed in  can be displayed in the linechart.
In Fig.5 the same route on top of the significant wave height and wave direction fields is shown, as it is visualized on an iPad (d) and an iPhone (e) screen. In fact, the MapKit Framework cartography 335 and the possibility to rotate the geographical Nord of the map can be noted.

Sailboat route
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 (Mannarini et al., accepted, 340 2015). For this reason, it is even less likely that the geodetic route -the spatially shortest path between the endpoints-is feasible. Thus, in VISIR-I the sailboat geodetic route is provided just as a topological information, without any reference to its kinematical aspects. Furthermore, the end-user is informed about the possible difficulty in computing the route by an info box including an hint to check the polar plot parameters (Fig.6a').

345
In Fig.6, a First 36.7 (a 11 meter long boat) route around the island of Crete is displayed. In the actual case shown, it is seen that the geodetic and the optimal route sail on opposite sides of the island (Fig.6a,d,e). This is suggested by the algorithm in order to avoid the dead calm areas in the lee of the high (> 2000 meter a.s.l.) mountains of Crete. The linecharts selected for this case study show the Speed Over Ground (SOG) and the True Wind Angle (TWA) with respect to cumulative time and 350 date/time since departure, respectively. The SOG linechart (Fig.6b) also includes the Velocity Made good to Course (VMC) information, demonstrating that the initial eastbound diversion of the optimal route locally implies departing from the target (VMC < 0). The TWA linechart (Fig.6c) shows that the algorithm suggests the boat to sail at a TWA close to the minimum possible for the actual polar 11 Nat. Hazards Earth Syst. Sci. Discuss., doi:10.5194/nhess-2016-32, 2016 Manuscript under review for journal Nat. Hazards Earth Syst. Sci. The sailboat routing is at the moment available, besides on the web application, just on a development version of the Android mobile application, whose screenshots for tablet (Fig.6d) and smartphone (Fig.6e) are anticipated in this paper.

360
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 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 represent the dynamical information used for the minimization of the route duration and 365 for checking vessel stability. The operational system is cross-channel available, and client applications for the web browser and iOS an 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

375
Numerous developments of the VISIR ship routing model are envisioned and some of them were already discussed in . As next development possibilities for the operational infrastructure, we foresee the realization of a "VISIR web API" for granting interoperability with third party softwares. Also, a route caching system or a desktop application could be a viable solution for using the system in the absence of internet connectivity. Interoperability along the lines of the