A new web-based and mobile decision support system (DSS) for
search-and-rescue (SAR) at sea is presented, and its performance is evaluated
using real case scenarios. The system, named OCEAN-SAR, is accessible via the
website
The Mediterranean Sea faces thousands of accidents and consequent search-and-rescue (SAR) operations. Accidents are related to tourism and recreational
activities along the Mediterranean coastlines, maritime commercial,
transport and fishery operations and to the immigrations from Africa and
south-eastern Mediterranean countries. The Italian Coast Guards and Italian
Navy intervened in thousands of SAR operations in national Italian and
international waters (e.g. 2649 standard SAR operations which led to the
rescue of 5885 persons and 938 SAR operations related to immigrants fluxes
which led to the rescue of 154 018 persons in 2015 Source of
information: “Annual report of the operational activities of Italian Coast
guard for 2015”.
The aim of OCEAN-SAR is to provide support to maritime authorities and operational centres (i.e. the Coast Guards) to optimise the strategy of search by reducing the extent of search area extension and increasing the probability of success of a rescue operation in case of a sea accident. In addition to maritime authorities, private users are also interested in getting support from SAR activities.
Two main categories of users can be identified: (1) the public authorities responsible at different levels for SAR emergency management, such as the Coast Guard; (2) private users (i.e. maritime transport companies, yachters) that would like to start the search and rescue of an object or person lost at sea from their boat. Private users might even be interested in searching for objects that the public authorities would not be responsible to find.
The SAR modelling tools are based on Lagrangian modelling (Breivik and Allen, 2008) forced by wind and currents environmental fields.
Advances in high-resolution ocean operational forecasts (Pinardi et al., 2003; Oddo et al., 2009; Tonani et al. 2008) for the Mediterranean Sea, nowadays delivered by the Copernicus Marine Environmental Monitoring Service (CMEMS) Mediterranean Monitoring and Forecasting Centre (MED-MFC), are available to provide accurate hourly frequency forecasts each day for the next 5 days and every week an analysis of the last week. Analyses are produced thanks to the data assimilation system (Dobricic et al., 2007; Dobricic and Pinardi, 2008), which corrects the model results with observations (e.g. sea level anomaly, temperature and salinity profiles). The MED-MFC analysis and forecasts can be used to force SAR models.
The leeway model (Breivik and Allen, 2008) uses an ensemble of drifting
particles to model the movement of an object due to surface currents and
wind. The motion of a particle For a small number of
classes the crosswind coefficients have an additional dependency on the
left/right of downwind orientation
The values of the object class parameters have been determined experimentally (Allen and Plourde, 1999; Allen, 2005) for various types of objects, ranging from persons in various conditions to life rafts and medium-sized ships. The current implementation of the model defines a total of 64 classes and sub-classes.
Uncertainties on the wind and the ocean currents can be incorporated into
the simulation by introducing an additional perturbation to the forcing
fields. The uncertainty on the current forcing field is considered to be
negligible compared to the uncertainty on the wind forcing. This is
warranted by the fact that the ocean data have a higher spatial and temporal
resolution. Moreover, the uncertainty on the effect of the wind forcing is
further amplified by the uncertainty on the leeway itself. Therefore only
the perturbation for the wind is taken into account:
The model is initialised by creating an ensemble of
To obtain the particle trajectories and the final distribution, Eq. (1) is
integrated from the initial to the final time using the midpoint method with
a fixed-size timestep of 360 s. The possibility of particles changing their
orientation, the so-called jibing, is taken into account by randomly
changing the sign of
The leeway model in OCEAN-SAR system is forced by ocean currents data CMEMS MED-MFC and atmospheric wind data from ECMWF: these datasets are used for the calculation of the particles trajectories.
OCEAN-SAR high-level architecture describing the main components of OCEAN-SAR (UIs on client devices, SSA platform, CDAM, leeway model).
The OCEAN-SAR uses the ocean currents analysis and forecast from the CMEMS
MED-MFC operational implementation of the NEMO model in the Mediterranean
Sea (Tonani et al., 2008, 2009; Oddo et al., 2009). The
fields used are currents in meridional and zonal direction at multiple depth
level. The name of the CMEMS MED-MFC product used is MEDSEA_ANALYSIS_FORECAST_PHY_006_001.
Currents are provided with hourly resolution on a
1/16 the 10-day forecasts produced every day originating from the 12:00 UTC
analysis/simulation; the 1-week analysis produced every Tuesday from the 12:00 UTC analysis, including data assimilation (Dobricic and Pinardi, 2008; Dobricic et
al., 2007); the 1-day simulations produced every day (except Tuesday) from the 12:00 UTC
analysis/simulation, which do not include data assimilation.
The wind forcing at 10 m height is provided by the IFS model operated
by the ECMWF. The model outputs are available with 3-hourly resolution for
the first 3 days after the analysis, the horizontal resolution is 1/8
The core of OCEAN-SAR runs on the CMCC super-computer. The OCEAN-SAR system is running in operational mode since June 2014. The system is available as a web and mobile application and has been configured so that registered users can submit the jobs. The service is freely available on the web and free of charge.
Message broker main functionalities are presented consisting of the exchange of messages between the SSA platform and the CDAM.
The OCEAN-SAR logical architecture is shown in Fig. 1 and consists of the
following components:
user interfaces (UIs) for the web and mobile client devices; sea situational awareness (SSA) platform (web portal, map service and
message broker); the Complex Data Analysis Module (CDAM) in the computing centre.
Only the relevant components of the system will be described in this paper;
for a comprehensive description of the SSA platform, CDAM and their
components, see Mannarini et al. (2016b).
All the relevant information provided by the users through the UIs (e.g. LKN, duration of the simulation) is transferred through a stream of data using the JavaScript Object Notation (JSON). This stream of data is first passed to the SSA platform through the message broker and then to the CDAM again through the message broker.
All the messages are exchanged by the components using the JSON format. Communication and data exchange between the client devices and the SSA platform via the Representational State Transfer (REST) web services are established by means of the message broker component that receives and forwards the requests to the CDAM hosted on the computational cluster at CMCC (Fig. 2). The message broker is capable of storing, in a database (grey cylinder in Fig. 2), the number of requests per user in order to avoid simultaneous submissions by the same user.
The OCEAN-SAR pre-processing shell script parses the input JSON string in order to obtain the values of parameters required by the model to run the simulation. The parameters names and default values are listed in Table A1. The CDAM, before running the simulation, checks the data availability for the defined domain and simulation period. The wind data are used only if the “depth” argument is 1; for the sub-surface simulations no wind is used. According to the “simulation time” argument the current and wind data are selected. The NetCDF files are extracted into a specific location of the file system where a folder is created for each simulation. The depth slab at a required depth is made by using NetCDF Operators (NCO) utilities. The data concatenation is performed across the time variable. The wind and current data at sea are extrapolated the ocean data towards the coast using a procedure called SeaOverLand (De Dominicis et al., 2013; Mannarini et al., 2016a), which performs an extrapolation of the original data considering for each cell grid point an average of the eight nearest values and then doing different iterations. This procedure optimally fills, for the currents, the gaps that remain between the ocean model domain and the high-resolution coastline. Moreover also the wind data over the ocean model domain are extrapolated over the land point to ensure that the simulation is performed with data of wind over the ocean and is not affected by wind over land. Then a high-resolution mask is applied to remove the part of the extrapolated ocean data on land.
The initial positions are randomly generated for LKP in a circle which radius is set up by the user before passing to the drift trajectory module of OCEAN-SAR. For every step an error management procedure is implemented that may cause the processing to stop, killing the job, and will post an error message with details to the UI. After the leeway model runs successfully, the output data are coded in plain text ASCII format and written in the output directory corresponding to the number of the simulation user request. The CDAM checks for the size of the output data and subsequently, if it is not empty, stores the output in JSON format as a new file.
The communication via REST web services is established through the message broker, a component of the SSA platform that receives the requests and forwards them to the CDAM hosted on the computational cluster. The model is executed on the server and returns the results to the user via the message broker.
The message broker is a unique component hosted by the SSA platform. As illustrated in Fig. 1 it is responsible for the communication both among client devices and the SSA platform and between CDAM and the SSA platform. The CDAM receives input data from the SSA platform through the message broker and sends back the results produced by the model to the SSA platform through the message broker.
All the user requests as well as the results of the simulations are stored in a database by a component of the SSA platform, which ensure data persistency (Fig. 3). This component is used by the OCEAN-SAR, for instance, to store and retrieve previously done simulations.
SSA component responsible for data persistence and for the exchange of information between the UI and the message broker.
Thanks to this component, each user can visualise at any time the results of previously performed simulations and view the parameters used to run the simulation.
The data flow in Fig. 4 shows how the messages are exchanged in JSON format among the different components via REST web services.
Data flow among OCEAN-SAR components.
The parameters of simulation displayed on the UI are available on the left side of the UI. The boxes on the left side of the figure describe the different parameters.
Each parameter simulation in the UI show a question mark which consists of the help option of that parameter. By clicking on the question mark the user will obtain a pop-up box (yellow box) with explanation on the meaning of the selected parameter.
Display of the simulation results with environmental fields (left panel) and without environmental fields (right panel).
On the server the model is executed using Simple Linux Utility for Resource
Management (SLURM) and the output are produced in ASCII format. The CDAM
(output preparation component) converts the ASCII output data into JSON
format in order to send them back to the SSA platform (see Fig. 2). The CDAM then sends the output
to the
message broker. In the meantime, client applications retrieve the results
by polling for their availability, checking the content and extracting the
information required for the visualisation. After completion of the loop the
results are provided to the user via graphically displayed fields; in
particular, the particles and their trajectory are presented on the map,
respectively, as yellow and black circles, making use of Google
shapes
The web and mobile applications (iOS and Android) provide the access for the user through their user interfaces. The web application has been adapted for use on mobile devices (tablet and mobile phone) and apps are available on the Apple and Android stores for free.
The UI allows setting the parameters of the simulation,
submitting requests and displaying the results of simulations on a map. The
version of the UI presented in this paper is referenced as OCEAN-SAR version 1.1
and dated May 2016. The configurable parameters are shown in Fig. 5. The
parameters can be grouped as follows:
general parameters (simulation name, object category); last known position (start position and start date); simulation duration; forecasting system (wind and currents models); display settings (environmental fields on/–off).
The meaning of each set of parameters is explained (see Fig. 6) through a yellow
box that appears on the UI after a click of the mouse.
Real case scenarios reconstruction information. All times are UTC.
Detailed visualisation of the output of the model.
Photos of the dummy (Calabria#1) and raft (Calabria#2) used by Italian Coast Guard in the Calabria exercise.
Results of the “Calabria1” simulation done using OCEAN-SAR showing
the positions (yellow points) of the particles at the end of the simulation
11:00 UTC of 14 November 2014. The red place marker indicates the position in
which the raft was collected. The green place marker represent the position in
which the raft was launched at sea and started drifting. The black line shows
the mean trajectory of the simulated particles. During the exercise the wind
speed ranged from approximately 3 to 10 m s
Results of the “Calabria2” simulation done using OCEAN-SAR showing
the positions (yellow points) of the particles at the end of the simulation
10:40 UTC of 14 November 2014. The red place marker indicates the position in
which the raft was collected. The green place marker represent the position in
which the dummy was launch at sea and start drifting. The black line shows the
mean trajectory of the launched particles. During the exercise the wind speed
ranged from approximately 3 to 10 m s
Results of the “migrantship2” simulation done using OCEAN-SAR showing
the positions (yellow points) of the particles
Results of the “small boat” simulation done using OCEAN-SAR showing the positions (yellow points) of the particles at the end of the simulation 09:05 UTC on 13 December 2014. The red place marker indicates the position at which the boat was rescued. The green place marker represents the last known position. The black line shows the mean trajectory of the simulated particles.
The results of a simulation can be displayed in the UI in two ways: with or without the magnitude of environmental fields (Fig. 7).
The UI (Fig. 8) visualises the following output and results of the model:
drifters final positions (yellow or red markers); mean trajectory drift (black curve); drifters stranded along the coast line (red markers); red contour line around the drifters, a convex hull that identified the
search area.
OCEAN-SAR has been validated by reconstructing real case scenarios (accidents and field exercises) using information provided by the Italian Coast Guard. A selection of these real case scenarios is presented in this section. Environmental fields used in the validations exercises have been the surface currents analysis provided by CMEMS MED-MFC and the wind analysis provided by ECMWF, both described in Sect. 3.1.
The Italian Coast Guard provided the information of five past events (Table 1) with different characteristics presented in the next subsections (Sects. 5.1 to 5.5). Section 5.6 provides a discussion on each validation case.
The field exercise in Reggio Calabria waters involved two different types of objects:
raft (here called Calabria#1) search-and-rescue dummy (here called Calabria#2).
The raft and the dummy used in the exercise are presented in Fig. 9.
For the raft used in this field exercise there was not an exact correspondent type of object in the IAMSAR manual (IMO, 2016) and therefore, following the indications by the Italian Coast Guard, a “shallow ballast with no drogue” raft was used for the simulation. For the dummy, the type of object called “person in the water, unknown state (mean value)” was used. The time and positions recorded for the objects are reported in Table 1 (Calabria#1 for the raft and Calabria#2 for the dummy).
In this case the commercial fishing vessel with many migrants on board was simulated using the “commercial fishing vessel (14–30 m) troller”, which was the correspondent object in the IAMSAR manual. The boat was found by the Italian Coast Guard at 00:40 UTC on 1 December 2013 (Table 1). The sea state was rough (more than 6 m of waves height) and the boat was drifting with failed engine; there was no possibility of immediate rescue and the ship was reached 1 day later when the sea state was better and allowed the transhipping of the migrants. The transshipment started at 12:05 UTC on 2 December 2013 at after 36 h of drift in the new position where the vessel was found (Table 1). The time and positions recorded for the ship are reported in Table 1 (Migrantship#1).
A 60 m long ship was transporting immigrants, who were rescued and transhipped. After the immigrant transshipment it was not possible to tow the ship; therefore it was left drifting. The position was recorded through successive sightings and these data are used for the validation of OCEAN-SAR. There is no specific corresponding type of object in the IAMSAR manual. The most similar ship type is the coastal freighter, which is used in the simulation of this paper. The time and positions recorded for the ship are reported in Table 1 (Migrantship#2).
Results of the “ferry” simulation done using OCEAN-SAR showing the positions (yellow points) of the particles at the end of the simulation 10:30 UTC on 7 December 2012. The red place marker indicates the position at which the person was found at sea after 14 h from the last time he was seen on board of the ferry. The green segments represent the route of the ferry along which the particles have been simulated.
Results of the real case scenario called MONOPOLI; the simulation was done using OCEAN-SAR showing the positions (yellow points and red points on the coast) of the particles at the end of the simulation 14:45 UTC on 6 August 2014. The large red place marker indicates the position in which the person was found at sea after 4 h. The green point represents the last known position at which the diver was lost at 10:45 UTC of 6 August 2014.
On 11 December 2014 at 18:00 UTC a person on board a small boat started drifting along the Italian coast of Apulia region (position given in Table 1). The location and time have been reconstructed based on the information provided by the person on board and are expected to be quite accurate (error estimated to be less than 1 nm and less than 2 h). After 2 days, at 09:05 UTC on 13 December 2014, the person was found alive on his boat in the position reported in Table 1. The type of object in the IAMSAR manual that best fit the real boat is “skiff V” with a hull smaller than 6 m. The time and positions recorded for the boat are reported in Table 1 (small boat).
A person fell overboard from a ferry between 20:30 UTC on the 11 July 2013 and the 23:30 UTC. The body of the person was found at 10:30 UTC of 12 July 2013 at the position reported in Table 1. In this case the last known position used in the simulation performed with OCEAN-SAR follows the automatic identification system (AIS) path corresponding to the positions of the ship at the time the person might have fallen overboard. The time and positions recorded for the ferry are reported in Table 1 (ferry).
In the reconstruction of the Calabria1 (Fig. 10) case the final position of the simulated drifters shows a partial agreement with the observation: the raft drifted south-west and its final position after 13 h at sea is contained in the area identified by the OCEAN-SAR system, but the simulation shows an area more shifted eastward.
In the reconstruction of the Calabria2 (Fig. 11) case the final position of the simulated drifters shows a partial agreement with the observation: the dummy drifted westward and its final position after 13 h at sea is just outside the area identified by OCEAN-SAR system, while the simulation shows an area shifted more eastward. OCEAN-SAR system does not show appreciable differences between the SAR raft simulated in Calabria1 and the dummy simulated in Calabria2. In reality the dummy moved westward faster than the raft.
In the reconstruction of the migrantship1 case (Fig. 12a and b) the final position of the simulated drifters is in good agreement with the observations: the ship drifted northward and its final position after approximately 12 h is inside the area identified by the OCEAN-SAR system. Figure 12b presents the fields of wind and currents and the mean velocity of for each of the particles.
In the reconstruction of the migrantship2 (Fig. 13) case the area identified by the simulated drifters does not include the final position of the ship, which drifted for almost 3 days (66 h). The simulated drifters are moving towards the east, while the ship is faster and moves further north-westward.
In the reconstruction of the small boat case (Fig. 14) the final position of the simulated drifters is not in agreement with the observation: the small boat drifted more south-west and its final position after 15 h at sea is outside the area identified by OCEAN-SAR system. OCEAN-SAR system predicted correctly a southward movement of the boat, but in reality the boat moved faster further westward. The westward position of the boat can also be explained by the fact that the person on the boat was paddling towards land; the coast guard explained that this resulted in a westward movement of the boat.
In the reconstruction of the “ferry” case (Fig. 15) the final position of the simulated drifters is in partial agreement with the observed location of the body found at sea after 13 h of drifting. The real position is few hundred metres westward of the OCEAN-SAR area.
OCEAN-SAR was used already several times by the Italian Coast Guard in real emergency situations related to SAR. In this paper we present the case of a diver lost in Monopoli, whose body was found a few hours later (Fig. 16). The OCEAN-SAR simulation results are in good agreement with the real drift of the body.
OCEAN-SAR is an operational decision support system (DSS), based on the leeway model and implemented as a complete system for on-demand simulation of drifting objects at sea. It uses as input ocean currents and wind data forecasts from third-party providers that are dynamically prepared. The DSS is freely available on the web and for mobile devices.
The interaction with the users and the participation of authors from the Italian Coast Guard to the co-design and testing of the OCEAN-SAR allowed the customisation of the service towards the users' needs and requirements.
The experience of OCEAN-SAR highlights that research and development activities, in the our case ocean and Lagrangian modelling, should as much as possible aim to converge towards operational applications so that their results and finding are tested in operational mode and in real case scenarios by the users, often situations in which weak components of the systems and bugs are highlighted. The operational testing also helps to demonstrate the effectiveness and importance of research results for supporting societal challenges and in our case the benefit for maritime safety and for saving lives at sea.
As possible future improvements to OCEAN-SAR we foresee the use of the high-resolution sub-regional and coastal operational models for currents and wind forecasts, especially in coastal areas, and the implementation of an application program interface (API) layer which will allow users to interface their own software tools with OCEAN-SAR, the further testing by users and the integration with users' software already existing and in use for the managing of SAR emergency at sea. Validation of SAR trajectory model using actual SAR cases as done in this paper is important, especially from the user's point of view, but has some limitations: (1) in some cases there is large uncertainty on the LKP; (2) in some cases we cannot be sure that the correct or most appropriate search object are selected and used; (3) since there would not be any measurement of currents and wind at the time and location of the event, modelers need to consider that there might be large uncertainties in the winds and currents estimated by the model.
Ocean currents data used in this paper and used by the operational service
(
To start the leeway simulation a string of input arguments from the CDAM is created that contains the full set of user-defined parameters introduced via the web UI. The set of parameters is listed in Table A1.
Description of user-defined parameters. The data are sorted according to name of parameter as written in the input string, description, value type and units.
This work was performed in the framework of the TESSA Project PON01_02823 supported by PON Ricerca & Competitività 2007–2013 cofunded by UE (Fondo Europeo di sviluppo regionale), MIUR (Ministero Italiano dell'Università e della Ricerca) and MSE (Ministero dello Sviluppo Economico). We thank Copernicus Marine Environment Monitoring Service – CMEMS MED-MFC for the provision of the ocean forecasting products, Servizio Meteorologico Aeronautica Militare Italiano for the provision of the wind products and Italian Coast Guard, in particular C. F. Sirio Faè, for the kind cooperation, important suggestions and providing the data related to the real case scenarios used for testing OCEAN-SAR in this paper. Edited by: A. Olita Reviewed by: K.-F. Dagestad and A. Allen