Final Report Summary - NAVTRONIC (Navigational system for efficient maritime transport)
The overall strategy of the NAVTRONIC project was to assess all types of real-time information capable of improving the sail plan operation (WP1), to develop a new generation of sail plan models that include real-time local and remote observations and a sophisticated way to improve the reliability of metocean and fuel consumption, emission reduction models (WP2), to develop and implement this capability in an OnShore Control Centre (OSCC) and in a decision making aid (WP3), to install, run and tune this Navtronic system on each of the end-user partners' vessels (WP4), to conduct sensitivity and performance analysis in real operations and ask the end-users to evaluate the usefulness, quality and performance of the system (WP5). The last work package focused on project management, and dissemination and exploitation of the results (WP6) including the correlation with certification and approval strategies under International Maritime Organisation (IMO), particularly under Navigation and Safety at sea.
In this report a summary is given on the work achieved within the project, this is done on the main level. In the Publishable Summary Report a description is provided per work package on the achievements compared to the objectives. Further, the potential Impact will be described, including the dissemination activities and Exploitable results. At the end, the contact details of the technical coordinator is provided and a list of the project participants.
In general it can be concluded that the objectives of the project as set in the proposal, are achieved. Although the route to the final results was different from the initial plan, which resulted in an updated project plan after 2 years, including an extension of the project duration.
Project Context and Objectives:
2.1 Project Context
Societal need and political background
Shipping is probably the most important mode of transport for the European Union, with over 90% of its external trade and some 43% of its internal trade going by sea. The maritime sector is also important from an economic point of view. Maritime companies belonging to European Union nationals control one third of the 50.000 counting world fleet and some 40% of EU trade is carried on vessels controlled by EU interests .
The environmental record of maritime transport is mixed. Emissions of greenhouse gases per amount of transport unit are low compared to other modes but in absolute terms significant. According to the Clean Air for Europe Program, shipping is estimated to emit as high as 4.5% of total global CO2 emissions and forecasted to emit more than all land sources combined by 2020 .
Moreover the cost picture of the shipping trade has been radically transformed as oil prices have surpassed the US$100 mark per barrel. The price of bunkers has in fact grown from less than US$150/ton in 2004 to almost US$520/ton in 2008. The proportion accounted for by bunkers of total vessel cost in the shipping segment now exceeds 35%, up from 20% ten years ago.
It is apparent that all stakeholders have a strong interest in combining their forces to persuade towards a more efficient shipping trade, particularly in terms of fuel savings and greenhouse gas emission reductions.
The concept of the NAVTRONIC project is to take a holistic approach to the minimization of operation, environmental, maintenance, and inspection costs of maritime transport by fusing ship specific parameters such as yaw, pitch, roll, sailing speed, GPS position, structural stress, engine parameters, drift, loading condition, wetness, etc. with real-time weather and sea state data such as waves, winds currents and sea ice concentration/drift, both locally, from ship borne 3D radars and from other sensors and remotely, from earth observation platforms (e.g. EO satellites, coastal stations, etc.) and coastal radars.
All these observations, parameters and boundary conditions are integrated to generate an optimal sailplan that advises/assists the captain in selecting/taking the optimal route and speed pattern to the next port.
For these reasons the larger shipping companies in two of the main European maritime infrastructures provides their vessels as platforms for testing, calibration/validation and exploitation activities.
Communication lines between the onshore information and control centre and onboard remote sensing systems on ships. All observations from the area of a ship are communicated in real-time to the OnShore Information and Control Centre. This centre is the online hub for exchanging and modelling all navigation, safety and security relevant information to/from infrastructures and third parties (i.e. coast guard, port authorities, etc.).
2.2 Main Objectives
The proposed system will help sea masters make better decisions in their sail planning process. It should allow the operation of a vessel to become more cost efficient and environmental friendly.
The NAVTRONIC system will mimic the well proven procedure of own observations and experience. It will use real-time local observations in a very similar way, by combining them with more traditional metocean forecast and satellite observations. The experience factor will be simulated by continuously monitoring ship performance and learning from the "errors", the measured differences between prediction and realization. A state of the art adaptive process will be realized that will increase the "experience" and performance of the system over time. The specifity of the approach is:
• To constantly monitor actual ship performance and assimilate this information in the sail plan optimization process. The access and systematic exploitation of ground truth information provides the unique capability of building "system experience", constantly improving the performance of the different models used in the sail plan optimizer.
• To provide more information, and more accurate than what is currently available on conventional systems, in the sail plan optimization process. This includes wave, currents, wind and ice characteristics provided by (near-) real-time remote sensing observations from space borne sensors and real-time observations provided by coastal/offshore/ship sensors. The unique feature is a reduced sensitivity to forecast errors by using local observations.
• To benefit from the large number of vessels that will automatically report observations to the onshore centre. It will considerably increase the amount of metocean information, which, in turn, will be a major factor of improvement in the sail planning process.
• To calculate and transmit an optimized sail plan back to the ship, and display the plan and all associated underlying information and performance data in a simple, non-intrusive, graphical user interface (GUI).
The overall strategy of the work plan is to assess all types of real-time information capable of improving the sail plan operation (WP1), to develop a new generation of sail plan models that include real-time local and remote observations and a sophisticated way to improve the reliability of metocean and fuel consumption, emission reduction models (WP2), to develop and implement this capability in an OnShore Control Centre (OSCC) and in a decision making aid (WP3), to install, run and tune this Navtronic system on each of the end-user partners' vessels (WP4), to conduct sensitivity and performance analysis in real operations and ask the end-users to evaluate the usefulness, quality and performance of the system (WP5). The last work package will focus on project management, and dissemination and exploitation of the results (WP6) including the correlation with certification and approval strategies under International Maritime Organisation (IMO), particularly under Navigation and Safety at sea.
The objectives for each work package are:
2.2.1 WP1 – Observations & sub-models [Month 1-12]
Primarily this WP will address the end-user sail-plan requirements, which will help selecting various state-of-the-art candidate (sub) models and observational data that are needed for optimizing a sail plan according to one or several end-user primary criteria (fuel saving, time saving, minimization of emissions) and/or secondary criteria (minimizing structural fatigue, components diagnostics and diagnostics, passenger comfort, etc.).
2.2.2 WP 2 – Sail plan model [Month 9-21]
This activity will address the definition of a sail plan model to be implemented in the OSCC that can be optimizing parameters according to end-user criteria. Initially, the end-user primary criteria will be focused on fuel savings, emission reduction and sailing time minimization. Secondary criteria will be structural fatigue minimization, diagnostics, etc. A number of modules will be implemented within a neural network or statistical analysis scheme. The two most innovative modules will be a ‘model performance monitoring and analysis module’ that will allow in-situ observations and ship actual performance to qualitatively/quantitatively assess the sub-models performance (i.e. feedback processes) in order to optimize sail plan performance. A route optimizer module will integrate real-time observations in between sail-plan way-points in order to determine the most efficient voyage. The WP will additionally focus on how to take into account and adapt / optimize the value of local observations in relation to model output (‘abstract model assimilation’). The outcome of the sail plan is effectively where/when the series of way-point should be located/reached in time for the most efficient sailing according to the end-user criteria.
2.2.3 WP 3 – Architecture & implementation [Month 13-38]
Ship borne sensors, assessed in work package 1, will provide local real-time observations and navigational data to the Onshore Control centre (OSCC) which will also receive remote sensing information. The OSCC will run the various models and send optimized sail plan back to the vessels. Local observations and navigational data are collected and transmitted to the OSCC, which will also collect remote observations and will send results from the sail plan model back to the vessels.
This work package will develop the OSCC architecture capable to support data collection, storage, processing and communications and will implement the models in the OSCC.
2.2.4 WP 4 – Testing, calibration & validation [Month 12-46]
All sub-systems, developed and implemented in the OSCC, as described in previous work packages will have been tested in realistic but not operational conditions. The system will now be installed on a number of operational vessels from each of the partner end-user companies and extensively tested and evaluated. This WP covers the design, installation and calibration of the NAVTRONIC system on the operational ships and the training of the end-users. A methodology, metrics and criteria for assessing the system performance will also be developed.
2.2.5 WP 5 – System performance & sensitivity assessment [13-46]
The main goal of this work package is to identify the benefits of using a real-time updated sail plan computed centrally at the onshore control centre for each individual vessel. The assessment includes both subjective and objective evaluation and recommendations on how the NAVTRONIC system might be improved.
2.2.6 WP 6 – Management, dissemination & exploitation [1-46]
Manage the work program and detailed budgeting on a sub-task/partner level
Monitoring compliance by beneficiaries with their obligations
Task 6.2 will address the need to be in-line with the regulatory and certification frameworks in order to be allowed to provide the sail plan service to the larger maritime infrastructure players in Europe.
The main objective is:
• To be in-line with current regulatory frameworks and certification policies
• Strategy for fulfilment of rules and standards (Report) Month 6 DRAFT report
The main objectives of task 6.3 are to:
• Create effective communication with parties outside the consortium
• Safeguard the exploitation and dissemination of results.
3 Main Science & Technological results and Foreground
In this section a short summary is given on the work performed, this is done on the main level. In the attachment Core Part of the Report a detailed description is provided per work package on a task / partner level.
3.1 WP 1 – Observations & sub-models [Month 1-12]
WP 1 has managed to achieve its critical objectives, such as the identification of the main end-users sail plan requirements and their interpretation into requirements and parameters for the various models and algorithms of the NAVTRONIC system. Concurrently, several types and sources of observational data were investigated, including sensors and measurements. Availability and accuracy issues were addressed in order to interact with the selection of the various sub-models and formulate NAVTRONIC’s requirements for observational data. Based on these and on a thorough literature review, several candidates for the necessary sub-models of the route optimizer were identified and selected for implementation in WP 2. Finally, work has been done on identifying collecting, hosting, implementation requirements and necessary modifications of both observational data and sub-models on the Onshore Control Centre (OSCC).
3.2 WP 2 – Sail plan model [Month 9-38]
In WP2 the model architecture for the route optimizer has been defined and all necessary modules have been developed.
The work progressed significantly in the course of Period 2, and all deliverables have been completed. The architecture of the NAVTRONIC system has been finalized and all essential sub-models have been developed. A number of sub-models have been deemed optional, since they do not affect the project’s results, and their implementation can take place at a later stage. The software development of the route optimizer has been completed.
The MPMA has been clarified conceptually and its integration and implementation is finished.
Finally, the software integration of the whole system has been completed. The system can be tailored to match the end user’s ship’s characteristics adequately and become supported from measurements.
High Level Model Architecture
The NavTronic system was designed to consist of three main elements:
• The Offshore Integration Platform (OIP)
• The OnShore Control Centre (OSCC)
• Onboard Sensors
The OIP is located onboard the ship and is able to access the ship VDR in order to access data from the ship sensors, and consist of processors, databases and a user terminal. The OSCC for the has been physically established in the ACS facilities in Rome. Connectivity with the OIP can be achieved either via the internet or via the shipping company router, as required by company regulations. The OSCC receives information from the onboard sensors and integrates them with Numerical Weather Prediction data. Onboard sensors can report measurements of waves, wind, current, fuel consumption and other parameters, either through the ships Voyage Data Recorder (VDR), or by a point to point data link with the sensor. More information on the architecture and implementation of the OIP and OSCC are provided in WP3 description.
Development of Route Optimizer Modules
The Route Optimization process includes a Sail Planning Module coupled with an Evolutionary Algorithm (EA) software. The EA generates a number of candidate solutions (Sail Plans) that are evaluated and the best ones are recombined to produce new candidate solutions for further evaluations. This process is repeated several times, until converging to a family of solutions (recommended routes) that can be provided to the ship master.
High-level architecture of the route optimization process
The Sail Planner evaluates each candidate solution, containing a sail path, relevant MetOcean data, and seakeeping and propulsion calculations. The result of each evaluation is the Estimated Time of Arrival and the expected Fuel Consumption. Areas which are dangerous due to shallow water, presence of ice or forecast winds or waves can be flagged by the Sail Planner as “no go”. In cases when the selected speed cannot be matched by the engine’s operating envelope, the solution is discarded.
The sub-modules that had to be developed for the Sail Planner are:
• Shortest Path: This module determines the shortest path(s) between points in the ocean, avoiding land and explicitly taking into account the curvature of the Earth’s surface. Land is represented by simply connected polygons whose boundaries represent the coastlines. An admissible path between two points may touch the boundaries of these polygons, but not their interior.
• Metocean: The purpose of this module is to augment the output from the shortest_path module with interpolated values of metocean parameters from forecast data, as well as static environmental data.
• Hydrodynamic: The hydrodynamic module predicts hull performance under the forecast METOC conditions for the passage. The predictions are unique to the ship type and loading condition. Information on wave height and direction, currents, and wind speed and direction can also be taken into account if available, in order to calculate the ship resistance. The algorithms underpinning the hydrodynamic module can be optimized as the system gains expertise, by post voyage analysis of predicted fuel usage and actual fuel usage as recorded on the ships sensors.
• Propulsion: The Propulsion module includes the Propeller and Engine models. The required torque and propeller speed are calculated based on the ship resistance and the selected speed, as estimated by the hydrodynamic sub-module. Subsequently, the engine operating characteristics and fuel consumption are determined, provided that the engine can cover the requirements for the selected speed under the corresponding weather conditions. As in the previous module, this calculation is unique to each ship and can be optimized as the system gains expertise by post-voyage analysis of predicted fuel usage and actual fuel usage as recorded on the ships sensors.
A number of sub-models, such as fatigue, slamming, passenger comfort, have been deemed optional, since they do not affect the project’s results, and have not been implemented. This decision was taken in order to focus on the primary objectives of the project, which were the optimization of time of arrival and fuel consumption.
Sail Plan Model Integration and Evaluation
The individual modules developed for the NavTronic system have been integrated with the optimization software EASY (Evolutionary Algorithm System). EASY is a general purpose optimization platform developed by the National Technical University of Athens. It offers a variety of optimization tools and it is enabled for cluster- and grid-computing. The standard prerequisite for solving any optimization problem with EASY is the availability of an analysis software, evaluating the candidate solutions and quantifying their merit functions or constraint values. The analysis software in this work consists of the modules of the NavTronic system..
First evaluation of the system was performed in a route crossing the Atlantic, and also in various shorter routes in the Atlantic (e.g. Lisbon to Las Palmas). An example of this evaluation is provided, where three different routes are compared, and presented on a combined plot with weather information (wind and currents), as well as with details related to vessel speed and fuel consumption.
An example of an optimization study is presented, where a number of solutions different from the shortest path have been derived for the same route. Depending on the flexibility with respect to time of arrival, significant savings can be achieved. Some interesting results are:
• The same time of arrival can be achieved with a reduction of 3% in fuel consumption
• A 5% increase in travel time yields a 9% reduction in fuel consumption.
The above solutions are indicative of the range of solutions that can be achieved and they are within NavTronic’s target for 7% reduction in fuel consumption with a ±10% change in travel time.
3.3 WP 3 Architecture and Implementation [Month 12-38]
During WP3 the Navtronic consortium developed the entire operative infrastructures to support the live capture of a large number of ships parameters, including the ingestion of meteo data, ship-land communication, multi-thread algorithm processing, OSCC storage and archive. ACS activities in this WP include all system development activities, system design, HW system selection and purchasing, software architecture, development, C++, Bash, Matlab and Python implementation, deployment, integration, installation, system debug and implementation of end-user feedback, and part of the system documentation to support the development. Some of the software development activities have been affected by the delays in the previous WPs, in particular the integration activities related to the algorithms in the OSCC processing chain, and the configuration of the automatic ingestion mechanisms for the remote data feeds. However an effective solution has been designed (and fully implemented) to separate the implementation of the infrastructure from the integration of the mathematical modules.
Most of the deliverables in WP3 are Prototypes (systems servers and software applications) consisting in the distributed technical infrastructure of the Navtronic System. The prototypes have been presented and demonstrated in real-time to the EC at the Review Meeting in Sep 2012.
As specified in the previous report, some actions (not foreseen in the original DoW) have been implemented in WP3, in order to minimise the impact of the delays of the previous work packages. In particular:
- A new experimental OIP (WP3.1) with a minimum set of data requirement has been developed to be installed on-board in order to test on the field the land-sea communication and network performance, and to begin the acquisition of some specific data from the Voyage Data Recorder that are useful to validate with real data some the algorithms in development and to aid the installation new version of the OIP software, without moving people to follow the ship voyages. The OIP system software and application suite can be customised remotely as soon as the data requirements for the algorithm becomes more defined.
- An expandable modular infrastructure for the Route Optimisation Processor and Models Processors (WP3.3) has been developed in the OSCC to host the algorithms with a easy to maintain, plug-in approach, to easily integrate models in the processing chain as soon as they are developed.
- For the GUI prototypes (WP3.4) the design has followed an approach based on the development of reusable components of in-house technologies, based on two different technologies (standalone app vs webGL). This approach has given the consortium the possibility to assess the new contemporary trends in webGL GUIs and the important chance to refine GUI prototypes more quickly and to increase the number of evolutions, considering the heavily compressed development cycles. A traditional C++ OpenGL development was chosen as development system to be installed on the ships.
An additional important development has been the agreement with Carnival to exploit the data from the AIDA proprietary Fleet Management system, which was previously unavailable outside AIDA Cruises. To include the Fleet management into the project ACS designed and developed together with AIDA a custom ingestion sub-system to acquire the UDP data flow in real-time. During the last review meeting it was agreed with the Project Officer and the external expert, that is was very important to proceed in this direction. The acquisition system has been also conceptually presented during the Project Review in Sep 2012. The Consortium believe that the acquisition of entire fleet of ship data directly from a internet web-service will have a significant impact in the design of similar future projects, and will have also a paramount impact on the way these kind of products will be utilised in the long term by the shipping industry. In fact the Consortium strongly believe that having a specialised operator in a control room, on land, at the AIDA HQ, relieved from the stress of the daily activities on-board, with the specific task to provide an optimisation strategy for the entire fleet at the company-level (fuel, emission, etc), exploiting a GUI like the Navtronic system to communicate the reasons why the ship officer should follow a certain route, will be the most effective way in which these kind of systems will work in the future.
Development of OSCC infrastructure (WP 3.1) is completed. Today, integration of new version of any algorithm can be completed quickly every time a new version of the executable modules is released by the scientists working on the mathematical models. As Specified in the P1 Report the integration of new set of algorithms (or data sources) now does not require anymore to recompile a new version of the OSCC.
The consortium also invested in the development of a simpler experimental Off-shore Integration platform (s-OIP), installed on the Carnival/HAL ship MS Rotterdam, to test the intermediate developments, with particular focus on realising a Virtual Private Network between the OSCC facilities in ACS, Italy, and the Holland American Line network infrastructure up to the ship internal network, to get access to the on-board data flow remotely, and to get a sort of remote presence on-board.
This experimentation around the prototypal Off-shore integration platform generated a fully working OIP system which is now installed on multiple ships. The OIP implements solutions to deal with the significant amount of data available on-board contemporary modern ships, a situation which was not foreseen in the original DoW written a number of years ago. On most of the ships today there is no need to install a custom suite of sensors because the data needed by Navtronic is available from pre-existing devices, often installed in the last three-five years.
This situation on-board created new challenges to the development, in particular:
- The OIP sub-system was originally designed to ingest specific pre-defined set of sensor data in pre-defined formats, according to the specs of the sensors to be acquired. In reality the OIP had to be more flexible to realise the acquisition and integration of the various sensor data formats and dialects found in pre-installed ship local information hubs, often proprietary NMEA strings from different brands, using completely different data formats. This architecture was significant more complex than to deal with a single set of acquired pre-defined sensor specs (which is the same for all ships).
- Significant effort was also spent in the development of an automatic translator of the many NMEA sensors dialect into high a single high level data format to be used by the OSCC algorithms, to simplify the development of the algorithms.
The Off-Shore Integration Platform OIP development (WP 3.3) is complete, and currently fully operative on Navtronic test-bed ships. The OIP platform had to be custom developed for the project (and not re-used from Sectronic, as stated in original DoW) because the test-bed ships were already equipped with the sensors generating needed parameters. ACS had to work together with the data-hubs integrators to integrate each custom data format, and to define the most convenient network communication on-board, including direct serial communication, FTP, UDP data streaming, shared network configuration for data on multiple OS. These network activities on operative ships required deep understanding of the ship network topology and the configuration of special rules in the firewalls that had to be carefully designed together with the end-users HQ (HAL AIDA CMRE) in order to avoid security problems on their networks. Most of the networks are managed by Network Administrators based on-land, often in different time zones (e.g. HAL HQ in Seattle). The OIP also implements an Abstraction Data Layer for data captured on-board, so that the algorithms only see the data, and not the local ship NMEA dialects.
OIP on MS Rotterdam 1
The GUI development (WP 3.4) is complete and the prototype is running installed on the HAL MS Rotterdam - a demo of the GUI with data recorded at sea was shown at the Project Review Meeting, 11 Sept 2012. To support the decision process the GUI can visualise all the algo products, 3-10 alternatives of optimised routes, time, emissions, fuel, metoc data along the route (such as salinity, water temperature, currents, wave data, pressure, etc), weather prediction visualised on the GUI plot. The user can subscribe to a selected optimised voyage to receive data updates (including updated routes) periodically when sailing. A number of versions of the GUI have been developed, together with the end-users and gathering feedback from specific end-users workshops in DNV Oslo. The GUI was also continuously updated on a weekly basis following an evolutionary development scheme incorporating feedback during the sea trials, addressing bugs and providing new features.
A prototypal small scale OSCC (designed to run on a researcher laptop) has been deployed to DNV and CMRE to support the development and the independent integration of new versions of the modules composing the sail-plan optimisation processing pipeline. When a module is integrated in the “small-scale OSCC” the subsequent integration in the real OSCC in Rome is greatly simplified. Performance and integration issues can be assessed in advance
The ESA GRID facility has been used to assess the performance of a subset of the algorithms for a large number of ships (fleet performance simulation). The ESA GRID is also used to assess the performance of the specific part of the processing pipeline which is responsible to compute the route optimisation around highest-resolution coastlines (the processing against the highest-resolution coastlines is often taking a number of days even on 8-cores systems)
3.4 WP 4 – Testing, calibration & validation [Month 12-46]
During this WP NAVTRONIC was installed and tuned for the specific vessel, a training package was developed and delivered to end users and the system used in operations. Following initial evaluation by end-users the NAVTRONIC installations were fine tuned for Cruise ship operations and for Research Vessel operations and end user feedback collected via interview and questionnaires.
WP 4 concerns the installation of NAVTRONIC on a number of end-user ships. The first installation was completed in May 2012. This installation established that modern ships already have the majority of the sensors required to feed NAVTRONIC with data and this greatly simplified some aspects of the installation. However, because the systems onboard are proprietary it was necessary to work closely with the installed equipment and sensor providers.
The installation completed the NAVTRONIC system to provide the connectivity between the Offshore Integration Platform (OIP) and Graphical User Interface (GUI) on the ship and the On Shore Control Centre (OSCC). The ship was ready in May 2012 to commence receiving optimised routes and to evaluate the system during the anticipated 10 month project extension to July 2013.
Rather than install the second system on a second Carnival ship, it was decided to adjust the installation plan to leverage state of the art developments in data transfer which were underway in the Operations Centre which already receives the data required by NAVTRONIC from all of its modern ships. This offers a major advantage to NAVTRONIC in that the system can receive data from more ships than the one that was originally envisaged; this will enable the NAVTRONIC algorithms to ‘learn’ faster as they will receive more data to train them.
These installations provide all of the parameters required by NAVTRONIC with the exceptions of measured current and wave data. Instead a numerical current analysis and forecast model is used to provide currents and waves are observed and reported by the Deck Officers. However without measure data it would not be possible to determine the sensitivity of the NAVTRONIC system to these data and a Research Vessel was provided by the NATO Centre for Maritime Research and Experimentation. The Research Vessel has specialist sensors and no operational scheduling constraints and so will be able to measure these parameters accurately.
Training needs analysis Interviews were conducted with end-users and the following needs were established:
• Understand the principles of the NAVTRONIC system
• Ability to operate NAVTRONIC
• Understand how to use the NAVTRONIC recommendations
• Understand the limitations of the NAVTRONIC system
• NAVTRONIC evaluation and reporting requirements
The mode of training had to take into account the following operational constraints:
• Rotation of ship staff (staff only spend 2-4 months in post)
• Workload – training must be minimal and practical
• Training material must be available on-board at all times
• All required information to operate the system should be available on a card next to the NAVTRONIC Graphical User Interface (GUI).
In order to meet these training needs and operational constraints User Driven Menus and Wizards were created in the NAVTRONIC GUI. These take users through the key tasks. To accompany these task driven instructions, training material was created in conjunction with end-users and designed to supplement the wizards. A training video was produced which takes end-users through the basic tasks.
End-User training was completed and a system put in place to train further Deck Officers as they rotate.
The NAVTRONIC system was then tuned for operations on-board cruise vessels and Research vessels and lessons learned from the installations used to generate improvements to the system. The following points were noted:
The early results of NAVTRONIC have provided strong evidence that the algorithms are effective without additional sensors to the standard ship fit as was originally envisaged. Indeed the data from cruise ships suggests that NAVTRONIC might be able to achieve savings using only the parameters reported on the ship’s Voyage Data Recorder (VDR). This would represent a major result as it would avoid integration with proprietary systems such as the stability computer and engine management system.
Analysis of vessel performance by the Centre for Maritime Research and Experimentation using the NAVTRONIC Model Performance Monitoring and Analysis indicates that the power required to achieve 22 kts is double that required to achieve 17 kts. The ship’s programme requires her to achieve an average speed of 19-20 kts between destinations. If this were reduced to 15-17 kts then a significant (@50%) reduction in fuel costs could be achieved.
This will clearly require trade-offs within the broader business which are beyond the scope of NAVTRONIC however matching itineraries to the most efficient operating speeds of individual ships is worthy of consideration.
A power vs. speed plot from data from a cruise ship clearly indicates the exponential nature of the power law. The weather and currents can have a positive or negative impact on the actual speed of the vessel over the ground. In order to maintain the scheduled itinerary some high speed sailing is required along the path. A rule of thumb was developed such that one should sail at the higher speed while under the most favourable sailing conditions, and at the lower speed while under the least favourable sailing conditions.
The nature of some of the cruises results in communications drop out. This was apparent when the ship was operating in the Norwegian fjords. The steep sides prevented reliable satellite communications between the NAVTRONIC Offshore Integration Platform and the On Shore Control Centre. This did not impact the trial which was at an early stage but will constrain the submission of new sail plans. In practice this is not expected to impact system utility or effectiveness.
A communications solution that was not reliant on satellite communications had to be developed for the Research Vessel as military security constraints prevent communications between the vessel and the OSCC via satellite communications. As a result data from the OIP is sent via a 3G router. This only works when the ship is in range of a 3G network. The data are therefore stored on the OIP and uploaded to the OSCC FTP server whenever the router can connect to the 3G network. This does not affect the primary purpose of this installation as analysis can be done post-event rather than in real time as on an operational platform. A batch script is scheduled and is continuously running on the OIP in order to send collected data to the OSCC via FTP. The data on the FTP server is consumed and stored in to the OSCC system (the OSCC modules will use them) in a directory structure organized by date. A parser checks the downloaded raw data and parses it. The parsed data are then stored in a directory structure organized by date, with 24 files per day, one for each hour. A SQLite database has been created during the data parsing for statistics (e.g. how many NMEA strings of a specific type were captured hour by hour). Remote control of the OIP computer is achieved via the 3G connection.
• Observations of Waves and Currents
The weights allocated to different variables by the NAVTRONIC system include the impact of waves and currents. Ideally these would have been measured from the vessel receiving the NAVTRONIC routes. However, a dedicated radar is required, accompanied by specialist processing and it was not possible to fit this equipment to operational cruise ships. Therefore the Officer of the Watch includes wave and swell observations in his hourly weather report. These observations can be matched with the numerical weather forecast wave and current data. The research vessel provides the opportunity to measure waves and currents directly using the Wave and Surface Current Monitoring System (WAMOS) and a dedicated X band radar which has been installed on ALLIANCE on a new mast above the bridge. The data is processed by the WAMOS system and the processed data transferred to the OIP as 2D wave number spatially and temporally averaged measurement wave spectra. This data will be used to assess the sensitivity of the NAVTRONIC system to the accuracy of the wave and current data.
Numerous meetings were held with ship staff onboard the trial vessels and a dedicated workshop was held with end-users to identify how the GUI could be improved. As a result a large number of enhancements were made to the GUI appearance and procedures. New GUI software was uploaded and installed remotely on the NAVTRONIC systems without impact on system operability.
Once the NAVTRONIC system was ready for use the end-users were asked to provide structured feedback on the quality, usefulness and capability of the NAVTRONIC system against the prioritised parameters (i.e. time, fuel consumption, and emissions) and/or secondary parameters (e.g. structural fatigue, passenger comfort, etc.).
Structured interviews were conducted with 56 Deck Officers ranging in seniority from Third Officer to Senior Captain and their responses were captured using a questionnaire. The responses were grouped in two categories; requirements and performance. The results in each category were analysed using a modified Wilcoxon signed-rank test where the responses are ranked and weighted. The requirement weightings were then applied to the weighted performance responses to create an index of NAVTRONIC’s performance. The end-user responses are sumamrised in the following paragraphs:
• On Time Arrival
On Time Arrival was the most important end-user consideration before the start of NAVTRONIC. From the End-User feedback, over 80% of End-Users considered this to be essential and over 70% agreed or strongly agreed that NAVTRONIC would assist in achieving On Time Arrivals. Comments included that the ship: “Will use less fuel to achieve OTA”.
• Decision Support Aid
The requirement to support to decision making was not explicitly captured previously but has emerged as the most important factor from the end-user feedback. The need arises from the view of navigation as an art rather than a science that often prevails. Navigators and Masters currently select routes based on their experience and standard routes from the BP Distance Tables and similar. They have no tools to assist in calculating the costs and benefits of alternative routes and the need for a Decision Support Aid scored the highest Weighted Performance Index score. End-Users commented that NAVTRONIC is “an excellent idea so far” and “will be an excellent tool to support decision making."
• Accuracy and Skill
The Weighted Performance Index for Accuracy and Skill was in the low cluster along with; Weather, Ease of Use and GUI. Many end-users felt that they needed more experience of using the system before being able to make a judgement however they commented that NAVTRONIC: “Appears to combine various sources to give best route.”
• Weather availability
This question referred to the availability of weather observations and forecasts onboard. The requirement for Real Time Weather Observations and Port Weather forecasts was positively viewed. These are not currently available in NAVTRONIC and consideration will be given to adding these. The requirements for weather forecasts and satellilte imagery were not as strongly supported so that the Weighted Performance Index is relatively low. Users commented that their “Current [Weather] system already does [this] and so [NAVTRONIC] would need to provide more.”
• Ease of Use
This was the requirement that was most strongly supported by End-Users who commented: “Simple, Simple, Simple. Officers have a lot of varying information to take in and adding to their workload will only have adverse effects on the entire operation.”
• Graphical User Interface
The End-Users were very positive about some aspects of the GUI and negative about others, particularly the Google Earth type view and the addition of navigation charts. On the positive side the comments were very encouraging and confirm that the approach is correct: “I like the choice of routes, the optimum routes appear to be good.”
System performance is viewed as important by End-Users who comment that “A quick, accurate response is vital.”
• Weather Avoidance
The avoidance of weather to preserve ship safety was viewed as essential, and nearly 90% of End-Users agreed or strongly agreed that NAVTRONIC would achieve this. However End-Users are already generally happy that their current providers achieve this.
• Improvements over state of the art
One of the aims of NAVTRONIC is to make a major advance over current state of the art systems. End-Users responded positively to this question and made comments such as:
“It is far more advanced than our current systems.”
• Passenger Comfort
The comfort of passengers and crew originally took priority over fuel consumption for cruise ships whereas fuel was more important for transport vessels. End-Users felt that whilst NAVTRONIC was not focussed on increasing passenger comfort and that the: “Focus appears to be on reducing fuel burn.” This is more presentational than a NAVTRONIC system design issue but should nevertheless be addressed.
• Reduce Fuel Consumption
Fuel Consumption was originally ranked 3rd in importance by End-Users in the cruise ship sector after passenger comfort and these positions remained unchanged in the End-User feedback. In terms of performance End-Users felt that NAVTRONIC would reduce fuel consumption and the overall Weighted Performance Index was second only to Decision Support. Comments included: “Compares routes based on fuel consumption therefore the optimised route is chosen.”
• Reduce Ship Fatigue
In the initial workshops, end-users classified reducing fatigue/structural stress as a very low priority for cruise ships and it remains a secondary consideration for End-Users who note: “More favourable weather routes can be used meaning less damage to the ship.”
This WP was completed on time and to cost.
3.5 WP 5 – System performance & sensitivity assessment [13-46]
The main goal of this work package is to identify the real benefits of using a real-time updated sail plan computed centrally (with real-time local and remote observations) at the onshore control centre for each individual vessel.
End-user criteria for relaying on a sail-plan
The initial task was to identify the factors underlying the Master's decision regarding the acceptance of a Sail Plan. This was done by questionnaire which was designed in collaboration with the end-users and used to gather information from senior officers about the decisions made by the End-Users (e.g. a captain, sea master) in order to recognize and list the factors underlying the master's judgment.
The work focussed on what is required by a successful sail plan including identification of:
• The factors underlying the master's decision for using a sail-plan.
• Other factors that could be helped in the future by adding/modifying the current sail plan scheme.
NAVTRONIC only plays a part in the passage planning process. The current version is a ‘stand-alone’ demonstrator which is not type certified and cannot be connected to the safety critical ship’s navigation systems including the ECDIS, it is therefore somewhat constrained in utility. This is inevitable when a research project involves operational ships and is not a criticism of NAVTRONIC. This lack of connectivity to ECDIS impacts the utility of NAVTRONIC in 2 ways. Firstly the NAVTRONIC demonstrator must contain some functions that an operational system would receive from other systems e.g. navigation charts, overlays and port information. Secondly, the NAVTRONIC demonstrator’s utility is limited because it is outside the current navigation systems and an adjunct to the operational passage planning process.
Within these constraints NAVTRONIC complements the bridge culture very well and the route options provided by NAVTRONIC can be used to initiate discussion by the bridge team. As part of the passage planning process, safety of life, the ship and the environment remain the primary concern for the Master at all times. However, with the growth in technology and improving safety of ships, Masters may come under increasing pressure to promote efficiency over safety. Whilst no competent and responsible Master should ever bow to this pressure, it is becoming increasingly important to provide the Master with efficiency decision support tools to ensure that the voyage is optimised for both safety and efficiency.
Optimisation requires the balance of speed and fuel consumption whilst ensuring safety at all times. The NAVTRONIC system supports this optimization process. Without the use of NAVTRONIC, the cost / benefit trade-offs which are implicit in the passage planning process are not exposed and it is therefore very difficult to optimise a route and to know post voyage if an optimum route was sailed. However the Master (and the system) must remain sensitive to operational constraints.
NAVTRONIC provides substantial utility that is not provided by other systems which complements the production of the Ship Energy Efficiency Management Plan (SEEMP). NAVTRONIC optimises routes through balancing speed and fuel consumption for the prevailing and forecast meteorological and oceanographic conditions whilst ensuring safety at all times. This is unique and without NAVTRONIC, the cost / benefit trade-offs which are implicit in the passage planning process are not exposed. It is therefore very difficult to optimise a route and to know post voyage if an optimum route was sailed.
However although substantial savings are theoretically possible from optimised routeing it is evident that only limited savings can be expected in practice due to operational constraints on arrival and departure times and the narrow band of optimal speeds that are available which necessitates ‘fast’, ‘medium or ‘slow’ speed.
End-user quality assessments and suggested improvements to the architecture and observations
A questionnaire was developed with end-users in Task 5.4.1 to capture the perception of NAVTRONIC (users (e.g. sea masters, captains, navigation officers, staff captains, etc). This was completed during several meetings with End-users with discussions covering:
• End-User expectations of NAVTRONIC
• End-User quality assessments of the NAVTRONIC system
• End-User Recommendations
In parallel with this subjective analysis a numerical analysis was completed using the methodology, metrics and criteria developed in Task 4.1.3 and the data that will be collected during normal operations and factors beyond those currently addressed in NAVTRONIC were investigated. This included a sensitivity analysis of the NAVTRONIC system to the input observations and model parameterizations were investigated and recommendations made on how to improve the NAVTRONIC system through focussing data collection effort on the most sensitive areas. Recommendations were made as to how the system might be improved.
End-User expectations of NAVTRONIC
NAVTRONIC was favourably compared to other routeing systems by End-Users. The last few years have seen rapid growth in technology within the field of route optimisation. There have been a variety of different companies (small and large) developing products in this area from different angles. Most are developing the capability as a logical evolution of their current core business capability. The different stakeholders engaged in developing a route optimisation service are:
• Weather forecasters
• Trim optimisation software suppliers expanding their core offering
• Stability software suppliers expanding their core offering
• Independent technology firms with no maritime background
• Suppliers of marine energy efficiency solutions expanding their core offering
• Providers of Bridge equipment expanding their core offering from route planning tools to route optimisation tools.
So far, several suppliers have developed products which are undergoing field testing. However, so far, none of these solutions have been able to prove significant savings through route optimisation. Furthermore, attempts to benchmark the savings from these products has been very difficult because no post voyage analysis is undertaken to demonstrate how much is actually being saved. There have also been several difficulties with integrating technical solutions with existing Bridge equipment which has limited the accuracy of results.
NAVTRONIC does not seek to compete with the core competencies of any of these existing solution providers but uniquely focuses on addressing the issue of route optimisation. NAVTRONIC was considered to represent a clear opportunity to progress beyond the state of the art because:
• Routes can be easily benchmarked;
• The system is ‘self-learning’ and adapts to the ship over time;
• The system both transmits and receives real time weather information which will provide real time routeing updates whilst on passage.
End-User quality assessments of the NAVTRONIC system
One of the aims of this report is to collect comments which may be used to help to convince other ship operators to participate in NAVTRONIC; as the NAVTRONIC performance will improve as more real time weather parameters are streamed to the On Shore Control Centre.
This Chapter contains comments from Deck Officers; and Chapter 4 contains their suggestions for improvements to NAVTRONIC.
Senior Officers’ Overview:
• NAVTRONIC is “an excellent idea so far” and “will be an excellent tool to support decision making.”
• “It is far more advanced than our current systems.”
• “NAVTRONIC covers a greater range of aspects.”
• “We don't have a system that carries out what NAVTRONIC is offering.”
• “NAVTRONIC takes more information into account.”
• “More advanced with more functions.”
• “Route Options provides focus for discussion by bridge team - facilitates horizontal bridge team structure.”
Comments on specific aspects of NAVTRONIC performance:
• On Time Arrival: The ship “Will use less fuel to achieve OTA”.
• Accuracy and Skill: “Appears to combine various sources to give best route.”
• Weather availability: “Can be used to track severe weather and make decision concerning what action to take.”
• Passenger Comfort: “Focus appears to be on reducing fuel burn.”
• Reduce Fuel Consumption: “Compares routes based on fuel consumption therefore the optimised route is chosen.”
• Reduce Ship Fatigue: “More favourable weather routes can be used meaning less damage to the ship.”
NAVTRONIC is not yet an operational system and it either requires further development of the navigational databases and type approval to become an operational stand-alone system; or to be linked to an ECDIS or Bridge Systems or to be embedded within weather routeing software.
The NAVTRONIC approach to make the logic underpinning routeing recommendations available to End-Users, so that they can drill down through successively more detailed layers of information is very powerful. Leading shipping companies have established horizontal bridge teams so that all officers, irrespective of rank, are encouraged to participate in decision making and to raise safety concerns. NAVTRONIC clearly facilitates the discussions regarding routeing options.
The availability on the VDR of the data parameters required by NAVTRONIC rather than by additional on-board instrumentation and the move towards streaming data to shore side HQs which is underway by some ship operators indicates that there is a commercial opportunity for NAVTRONIC.
It is appreciated that NAVTRONIC assumes that the Master knows his ship and will trim and assume a machinery configuration that is optimised for the prevailing/expected conditions.
It is apparent that only limited savings can be expected from routeing due to operational constraints on arrival and departure times and the narrow band of optimal speeds that are available which necessitates ‘fast’, ‘medium or ‘slow’ speed.
NAVTRONIC highlights the vessel programming as an area where large savings are possible through operating in the ship’s most efficient speed band. For a typical cruise ship the power required to achieve 22 kts is double that required to achieve 17 kts. The ship’s programme requires her to achieve an average speed of 19-20 kts between destinations. If this were reduced to 15-17 kts then a significant (@50%) reduction in fuel costs could be achieved.
The system is expected to be reliable. It is envisioned that the system should be remotely accessible from shore side in order to enable remote software updates for maintenance and upgrade purposes. The concept of remote access was demonstrated as part of the project with the system being placed onto the vessel’s Local Area Network (LAN) and provided with access via the host ship’s Virtual Private Network (VPN).
An unexpected finding was the impact that a good route optimisation system could have real benefits on the vessel’s Ship Energy Efficiency Maintenance Plan (SEEMP) plan. NAVTRONIC does not address the entirety of energy consumption required by the (SEEMP) but could provide the core module to which others can be added and would be able to document and verify a process of improving efficiency over time as fuel savings through route optimisation could be demonstrated. Furthermore, it is possible to utilise NAVTRONIC to support the ship to demonstrate that they are operating the ship efficiently as part of an audit process.
This WP was completed on time and to cost.
3.6 WP 6 – Management, dissemination and exploitation
WP 6.1 - Management, monitoring and controlling [M1-M36]
WP 6, task 6.1 is on schedule as the Management activities will last for the whole project duration.
WP 6.2 - Safety assessment, regulatory framework, certification and approval planning [M1-M46]
The status of the systems and equipment currently required onboard ships are reviewed first, along with the rules related to these systems. The strategy to be considered first is a strategy which will allow the voluntary installation of the NAVTRONIC system as an add-on system with limited integration with existing systems. This is probably the case for the development phase of NAVTRONIC during the course of this project. An investigation of basic minimum requirements relevant for such voluntary add-on systems has identified the following regulations and standards.
This report is finalized at the end of the project by listing a set of final conclusions.
WP 6.3 - Dissemination and exploitation [M1-M46]
Setup of the public website www.NAVTRONIC-project.eu and partner only portal has been done. The public website, partner only portal and all templates used for the project are described in Deliverable D6.3.1.
General presentation is created and used in several occasions.
Furthermore, as dissemination action, DNV is able to post blogs on DNV Research blog site regularly following the progress: http://blogs.dnv.com/research/
WP 6.4 - Dissemination workshop [M37-M46]
A final Dissemination workshop was held in Almere to a specific group of (potential) users, as part of a CARNIVAL Captain Training Course.
4.1 Potential Impact
4.1.1 Impact on end-users and the European Community
Calculations of the expected implementation benefits for the end-users show that the numbers presented herein (i.e. 7% savings on fuel consumption, 7% savings of CO2, SOx and PM emissions, etc.) are in the expected and foreseen range, see in the contex of e.g. , .
4.1.2 Fuel reduction
The cost picture of maritime transport industries has been radically transformed as bunker prices have increased from less than US$150/ton in 2004 to almost US$520/ton in 2008 . The proportion accounted for by bunkers of total vessel cost in the shipping segment now exceeds 35%, up from 20% ten years ago . Industry profits in the first half of 2007 has therefore dropped to only US$40/FEU.
Navtronic is expecting to achieve a 7% fuel reduction in the operation of a ship. The number is conservatively justified from thoroughly considerations of a number of sea masters, ship operators and advisors. They have all been calculating a likely average saving in the range of 5 – 15%. For example;
Capt. Maalen (former fleet captain of Crystal Cruises):
“A sail plan prepared for a general cargo ship sailing from Bremerhaven to Halifax in January present 2 main options: a northern route, north of Scotland, for a total distance of 2970 nautical miles and a southern route, in the English channel, for a total distance of 2790 miles, or a difference of 180 miles in favor of the latter. The presence of head winds and currents over most of the path in the southern option leads to a total voyage duration of 9 days and 7 hours to be compared to 8 days and 6 hours in the northern option, or an increase of 12.6% in sailing time. However, due to the lack of reliable information along the northern route, the southern route will be most often chosen by sea masters. This example is not unique. Even in 2008, with modern navigation systems and sail plans, a 24 hour increase in a transoceanic sailing time is common. “
Initial studies conducted by DNV, independently confirmed by Capt. Maalen indicate that a more accurate and reliable information and planning would reduce sailing time or fuel consumption by 7% - 10%. In this project a conservative factor of 7% will be considered.
This is achieved by using local sensors (3D radar, lidar and standard ship sensors) which will continuously report high accuracy measurements of sea (and ice-) states (waves, winds, surface, current, ice concentration and drift). This data, representing the ground truth in the vicinity of a ship, is sent to the OSCC that assimilates these and other data provided by near real-time space-based observations into meteorological and oceanographic models. This assimilation/tie-point is a key factor in this project as currently available sail planning systems fail because (inter alia) they are utilizing inaccurate weather observations. The continuous assimilation of real-time local and remote observations in the models will greatly improve the accuracy and reliability of oceanographic and meteorological forecast models, which ultimately will cause the proposed fuel reduction. Moreover, the proposed Navtronic system feeds back observations enabling evaluation of the model performance, which is utilized in the proceeding model runs.
4.1.3 Emission reduction
A recent study by UN's Intergovernmental Panel on Climate Change (IPCC) suggests that annual emissions from the world's merchant fleet have reached 1.12bn tones of CO2, or nearly 4.5% of all global CO2 emissions. By comparison, the aviation industry, which has been under profound pressure, is responsible for about 650m tones of CO2 emissions per year, just half that of shipping. In addition to greenhouse gases, shipping has also been under scrutiny for other pollutants that it produces, particularly sulphur oxides (SOx), nitrogen oxides (NOx), and fine particulate matter (PM). The latter is a known carcinogen and contributes to premature death as a result of cancer and respiratory disease.
University of Delaware scientists estimate that shipping-related PM emissions are responsible for approximately 60,000 cardiopulmonary and lung cancer deaths annually, with impacts concentrated in coastal regions and along major trade routes .
PM pollution overlaid on the world's major shipping routes
According to IPCC, the politically acknowledged cost emission reduction scenario is 450 ppm CO2/ 2 deg global heating, which corresponds to that of implementing all emission reduction measures that cost less than 100$ / tones CO2 emission averted. This number is therefore commonly used as an environmental CO2 cost.
4.1.4 Optimization of ship maintenance schedules and asset preservation
The life expectation of a commercial ship depends to a large extent on the stress the ship (and especially the hull of the ship) is experiencing at sea. The problem of hull fatigue is well known, particularly after the oil tanker Erika broke in pieces and the container carrier MSC Napoli beached off the coast of Devon (UK) due to a three meter wide crack in its hull. Commercial ships are designed for a life expectation of around 30 years. This can only be achieved with extensive maintenance of the hull according to the stress it encounters. Due to the fact that it is unknown today what the actual encountered stress of the ship is, maintenance cycles are based on regular intervals disregarding the actual need for maintenance. This can lead to serious safety issues as experienced with these examples. On the other hand, with observational data provided by local sensors to fatigue models maintenance cycles can be significantly optimized to an ‘as needed basis’.
Furthermore, an explicit reduction of the exposure to heavy sea can significantly expand the life expectancy of the ship asset. Out of experience, the participating end-users suggest a life expectancy increase of up to 15% is feasible with the proposed system.
4.1.5 Optimization of sail time
Navtronic enables the end-user to optimize the sail plan according to the operational requirements, e. g. port slot times, channel passing slots (Suez or Panama channel), tide schedules (e.g. a Very Large Crude Carriers (VLCC)s need high tide to enter and leave the port of Rotterdam). Traditionally, sea masters give a 10% time margin over the journey to ensure a timely arrival at destination due to operational risks, relatively large uncertainty in the weather forecasts, etc. This causes large overheads. In normal operational conditions the ship will operate at very low speed during the last hours of a port call or arrive early at the destination and anchor outside. This is a loss of money and potential income for the ship owner/operator.
According to the experience of the end-users involved in this project at least 80% of the delays are caused by unexpected sea-state conditions. Consequently end-users believe that with a better sail planning system based on sea-state information, a 5% sail time margin is sufficient. The Navtronic is utilizing sea ice information for the increasing volume of polar sailings and oil/gas exploration activities.
4.1.6 Improve competitiveness of European shipping and ship yards
The European maritime transport sector employs around 2.5 M and controls one third of the world shipping fleet . Navtronic proposes to strengthen the competitiveness of this significant European shipping trade by:
• Improving operational efficiency with respect to punctionality, environmental friendliness, and real time information exchange.
• Improving the price attractiveness (i.e. fuel reductions, time savings, emissions reductions, etc.)
• Enhancing the competitive advantage of the most efficient cruise ship designs delivered by European ship yards, e.g. by validation of models with ground truth data (e.g. the hydro dynamical models).
4.1.7 Expected Environmental Savings
The example of the container carrier (cf. Table 3.1.6) with respect to the potential CO2 emission savings, Navtronic is expected to achieve savings of 8,353t CO2 per year (cf. IPCC reference number). When the IPCC scenario becomes reality, this reduction would compare to an $816,667 saving per ship p.a.
The partners will have potential to gain revenues after the project from two main revenue streams:
1. The monthly subscription fees from its four core optimization services as
a. Fuel Optimizer
b. Emission Optimizer
c. Asset Preservation/Passenger Comfort Optimizer
d. Sail Time Optimizer
2. Sales of its “experience” data for validation, improvement and consultancy for metocean, hydrodynamic and fatigue models.
To guarantee a strong market penetration and receive the valuable journey data for continuously improving the quality of the service, the Fuel Optimizer will be marketed for free in the 1st year. In exchange Navtronic will receive journey data including local observations from its end-users, which will strengthen its product and long term market position. At the beginning of the 2nd year, with Navtronic well established in the market and sufficient data collected, the partners will establish a more beneficial price scheme.
The subscription fee includes installation of hardware (GUI, PC, COM).
4.2 Main dissemination activities
At the start of the project a public website was setup and maintained during the project as communication channel towards the general public and targeted public. www.navtronci-project.eu
In total one peer reviewed publication was achieved in the project, by NATO STO - NAVTRONIC: Navigation System for Efficient Maritime Transport.
Further, a total of 10 publications were done, including oral presentations at several conferences. Next to 5 flyers or news releases from the project.
At Mid-term two dedicated workshops were organized, mainly with the project partners and several external technical persons. At the end there was a dedicated workshop organized for the end-users, this was including a training module. This was held in Almere, The Netherlands were an intensive training course was organised for Carnival Captains.
4.3 Main exploitable results
MARSS has played a central role in the development of the NAVTRONIC concept and in the design and trial of the demonstration system at sea providing the interface with the End-Users. In the process MARSS has identified key system design features which will enable the production of a commercial NAVTRONIC system. NAVTRONIC has been a tremendous success as a proof of concept demonstration and MARSS will seek partners in relevant sectors as identified in WP 5 to leverage this knowledge into ECDIS and other bridge systems.
NAVTRONIC has pulled through knowledge gained in a previous FP7 funded project, SECTRONIC, which has facilitated the streaming of data from ships to shore. This technology will be re-used in a new FP7 project to provide ‘Protection Measures for Merchant ships’ (PROMERC).
ACS has developed (in WP3) the main technical infrastructures for the Navtronic project, updating and refining (in WP4 and WP5) the main components OIP, OSCC and GUI. The continuous update has followed an evolutionary approach to include end-user inputs and comments from experts both inside and outside the Consortium. This mature technology will be reused as the starting point of several new projects both commercial and research, to keep it at the state of the art and to exploit its potential in other applications in the maritime domain, such as Security, Safety, Monitoring and Control, and again to support in navigation and sail plan optimization. One of the first application will be targeted to optimise maritime sail planning for fuel, emission and fatigue combining space-based remote sensing observations with local maritime ship observations (PF7 SPACENAV).
List of Websites:
The project public website has been set up for the general public and can be found at the web address: www.navtronic-project.eu. The website provides general information on the project objectives and the work to be performed as well as details of the project partners, and contact details for the project coordinator. It includes a password protected section with access restricted to partners only. The website will be accessible for some years after the project is closed. Public deliverable reports and other open project documentation will be available via the website to the public during this period. Confidential reports will remain available to partners via the restricted part.
5.2 Contact persons
ACS - Advanced Computer Systems
Via della Bufalotta 378
00139 Roma - Italia
Mr. Gianluca Palumbo
Telephone +39 06 87090303
Fax +39 06 87201502