Final Report Summary - SPACENAV (Space-based maritime navigation)
Executive Summary:
The overall strategy of the SpaceNav project was to assess all types of real-time information capable of improving operational vessel routing; to further develop a new generation of sail plan models that include real-time local and remote observations; to enhance the reliability of metocean forecasts and thereby fuel consumption and emission reduction models; to develop and implement these capabilities in an On-shore Repository Centre (ORC) and in a decision making aid onboard vessels; to install, run and optimize this SpaceNav system on end-user vessels; and to conduct sensitivity and performance analysis in real operations and ask the end-users to evaluate the usefulness, quality and performance of the service. The project management focused on dissemination and exploitation of the results including the correlation with certification and approval strategies under International Maritime Organisation (IMO).
In this report a summary is given on the work achieved within the project. In the Publishable Summary Report a description is provided per work package on the achievements compared to the objectives. Further, the potential impact is described, including the dissemination activities and exploitable results. At the end, the contact details are provided.
In general it can be concluded that the objectives of the project as defined in the proposal and description of work are mostly achieved.
Project Context and Objectives:
Project context
The maritime industry is seeking solutions to reduce fuel consumption (energy efficiency) and air emissions due to economic pressure and environmental regulations. Shipping is by far the biggest transport polluter globally. A recent survey by DNV GL found that weather routing and voyage optimisation are key measures to implement to increase energy efficiency. A ship can consume up to 16 tons of fuel per hour or with a fuel price of USD 657/ton (the average fuel price in 2014) spend over $200,000 /day. Ships over 100 Gross Tonnage (GT) (90,000 vessels) burn approximately 370 million tons of fuel per year, emitting 800 million tons of CO2, 20 million tons of sulphur oxides (SOx) and large amount of Particular Matters (PMs). Calculations performed by DNV GL and BW Gas in predecessor EU FP7 projects (and subsequently experimentally verified) demonstrate that the SpaceNav sail plan routing service can provide approximately 7% fuel and emission reductions for a ship. That will be generating a global saving of 56 million tons of CO2, 1.4 million tons of SOx, and over 5 million USD per year for a ship over 100 GT. The SpaceNav concept initially secured funding in 2008 (as a FP7 project), with several private/public initiatives (of over €10 M) further refining user needs and service functionality.
Strict energy performance and air emission regulations are coming in to force. The MRV (Monitoring, Reporting and Verification) regulation will quantify and reduce CO2 emissions from shipping. MRV is designed to progressively integrate maritime emissions into the EU’s policy for reducing domestic greenhouse gas emissions (EU regulation 2015/757). MRV requires ship owners and operators to annually monitor, report and verify CO2 emissions for vessels equal to or larger than 5,000 GT and which call at any EU port. Entered into force on 1 July 2015, the regulation will become fully effective on 1 January 2018, which means that shipping companies will need to prepare a monitoring plan by 31 August 2017 at the latest for each of their ships that falls under the jurisdiction of the regulation. They must monitor and report the verified amount of CO2 emitted by their vessels on voyages to, from and between EU ports and will also be required to provide information on energy efficiency parameters. Data collection will start on a per-voyage basis from 1 January 2018. SpaceNav fully facilitates these regulations.
Main objectives
The proposed system helps sea masters make better decisions in their sail planning process. It allows the operation of a vessel to become more cost efficient and environmental friendly.
The SpaceNav system mimics the well-proven procedure of own observations and experience. It uses real-time local observations in a very similar way, by combining them with more traditional metocean forecast and satellite observations. The experience factor is 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 is realized that increases the "experience" and performance of the system over time.
Prior to SpaceNav action the developing team of our sail plan system managed to accomplish several objectives in previous projects. The starting point of the previous projects 8-years ago was to prioritize functional needs of a sail plan system. These were derived and assessed by end-users, translated to technical and system requirements of the RTD partners, culminated in the design and implementation, and recently tested and validated. Experimentation to validate the concepts has been essential for the successful design of the system. The achievements underlined the need for further addition of (first of all) satellite observations and - importantly – the development of a sound business and commercialization plan that acknowledge the significant contributions of the leading SMEs.
The first objective of the addition of satellite oceanographic observations was one important component of an all-encompassing multi-platform, multi-sensor sail planning system improvement. Experimentation with additional complementary satellite sensors allows for their extended use but also allows a better understanding of the qualities of these comprehensive observations for sail planning. Therefore, the extended value of satellite multi-sensor experimentation enables better insight in the unique qualities of these observations, that nowadays have become the core observations for the sail planning service. These qualities have been precisely identified, as they are the core and essential part of the commercialization rollout.
The sail plan architecture is such that the modular system can incorporate a diverse set of observational sensors so that new types of functionality can be added incrementally. Particularly, the addition of satellite ocean current observations is a great improvement to the unprecise charts used elsewhere today.
Of particular interest was to tie various weather forecast model output (that is used today in the sail planning market) to the actual satellite observed conditions, in order to ‘correct’ the forecast based on actual satellite observations. In other words, the forecast error is ‘restricted’ by the satellite observations, and thereby enable the current sail plan sensitivity to forecast errors to be reduced. This ‘tie-point’ process is continuously calculated as new observations and forecasts are pulled-inn by a Onshore Repository Centre (ORC). (Note that the intention of this project was not to interfere/modify/improve or provide any type of feedback to the developers of weather/metocean forecast models). Combined the general metocean forecast models (including its inherent errors) and satellite observations thereby provides a qualified input to sail planning, and thereby consequently enable a better qualified calculation of waypoints along the route of a vessel. Note that this activity is not only feasible in the initialization of a voyage but continuously along the voyage as satellites continuously observes and met ocean forecast models are continuously producing outputs.
Furthermore, a specific objective is to validate (with the help of the ‘feedback-loop’ of the MPMA module) how the various algorithms applied to satellite observations are able to correctly extract the sough-for geophysical observations (primarily ocean currents, waves, wind and sea ice concentration and motion). This can be validated since the ships are observing these geophysical parameters and thereby produce ‘validation’ data. This ‘a posterior’ experience in turn can help select the geophysical satellite algorithms producing the better results (as a function of several variables like metocean conditions, geographical locations, etc.). Thus these ‘validation results’ are taken into account in the MPMA module to statistically be able to select the observation data set with the most qualified observation platform, sensor, and geophysical extraction algorithm under prevailing metocean conditions to be used. This is of great help for the developers of such algorithms.
Note that the previous ‘a posterior’ method of checking the correctness of satellite input observations has been further improved. An earlier version of our sail plan model was not self-aware of degraded input observations, i.e. there was no automatic mechanism to avoid degraded observations to be entered in the sail plan calculations (other than a data (structure) quality check). In other words, the sail plan model was providing sail plan output to the ships independently of the quality and quantity of input observation, i.e. the methods described so far herein are all checking qualities after the sail plan actually have been produced and followed. Therefore the specific objective was to improve the self-awareness module ‘a priori’ to monitor the correctness of satellite input observations (observation level) as well as its own performance and system health (system level), as well as how good (in terms of accuracy and availability) the system is performing as a function of the incoming satellite observational data. These calculations reflects upon the type of satellite data ingested into the system and consequently their value for the sail planning outcome. This can be utilized by using a set of normal monitoring and control data of each of the satellite observations to check the nominal status of the sensor or system. It may use a reference (that can either be specified in a model-based way or can be self-learned during calibration sessions) to monitor the output, or use redundant analytical relations between the various parameters to signal abnormalities. No additional sensors are used to implement this functionality. Thus the goal was to estimate the physical and operational condition of the satellite observational data input to provide an indicator of its condition. By interpreting the data coming from various satellite sources. This module is able to accomplish the following objective of (1) providing an estimate for the uncertainty of the observations presented to the sail plan model, and (2) providing an analysis of the nominal status of the ‘system’ of satellite observation ingestion module (i.e. if the observation data is transferred correctly to the sail plan server).
The culmination of the previous objectives (in terms of deriving more correct input observations based on satellite observations) helps deriving a quality flag that can indicate to the end-user/client and the system the anticipated quality of the provided sail plan (that will be a function of the derived quality of the input satellite observations). In other words, it adds-value to the end-user in its decision making by indicating to what extent the sea master can ‘trust’ the provided sail plan calculations.
Another objective was for the certification partner (DNV GL) (that initially has derived an approval procedure for the innovative system) to certify the satellite observation upgrade as to allow installation onboard commercial vessels as well as to derive a technical qualification process for this sail planning service.
A final objective was to establish agreements with additional satellite providers (i.e. in addition to ESA, ASI, MDA, NOAA, NSIDC) and EO data feed providers (i.e. in addition to MyOcean, EMSA, NOAA NCEP, AVISO, PO.DAAC EUMETSAT OSI SAF, NSIDC, University of Bremen) to (1) enhance observational input data volume and (2) avoid being ‘black-listed’ from providers due to ‘heavy-usage’ (i.e. this has been a challenge in the past). This included reassessing the available satellite sensor observations and their data providers (including eventual re- configuration/post-processing of data to fit into the model architecture’s reference system) to greatly enhance the amount and reliability of earth observation (EO) input data feeds to the system.
Objective 1: WP1 - Assessment of sail plan system performance characterization.
As the system is applied in safety-critical applications, a complete system performance characterization (i.e. complete for all sea states and environmental conditions) is an essential part of the information. The objective was to re-define how the performance (in terms of performance indicators) can be measured and assessed so that the end-users will have sufficient confidence in the system. Characteristics such as the probability of sail plan correctness and the quality of sail plan output under various sea state conditions were established for the system with and without the satellite sensor observations.
Tangible objective: Identified list of performance parameters reflecting end-user priorities
Objective 2: WP2 – Selection and integration of satellite EO
Several candidate missions and sensors are obvious for integration but a reassessment of available observations, and what type of observations are expected to be readily available, is essential to ensure that all possible EO data are included in the system. All these new feeds were incorporated in the sail planning service.
Tangible objective: Positive evaluation and preliminary validation of use of EO satellite data and algorithms
Objective 3: WP3 – Integration of the satellite geophysical observations
Including satellite EO to the system requires tested and readably available EO data feeds that can be used routinely, including redesign of modules, models and sub-models, including the crucial MPMA. Consequent changes were applied to the model based on the outcome of the previous objective. Data agreements were established with data providers and end-users/clients and third parties utilizing the service.
Tangible objective: Positive integration of EO satellite data and algorithms, plus contractual framework for data providers and clients
Objective 4: WP4 – Actual satellite EO operational verification
The objective was to control and verify that the EO data is correctly ingested in the system and that the models cope with the additional observations in an accurate and consistent manner without any type of degradation of input observations. The definition of “what and how” that needs to be measured (Objective 1) were tested in a ‘laboratory’ way as an ‘experimental’ basis for the actual selection of EO sensors and their performance characterization. There were extended series of experimentations to cover a large number of metocean conditions and geographical areas. The actual feedback loop of the MPMA module was logged to check various processes and calculations in the performance characterisation work, especially to qualify and quantify the value of the various satellite EO based observations.
Tangible objective: Positive experimental verification of use of EO satellite data algorithms for minimum 8 sea states
Objective 5: WP5 – Regulatory framework and certification
Based on the experimentation and exchange of system components, the final ‘frozen’ system were prepared for certification according to the certification strategy of partner DNV-GL. There were also established a technical qualification process to ensure that the service is fulfilling its anticipated technical objectives. Certification is necessary for a successful market introduction.
Tangible objective: Certification of the sail plan system
Objective 6: WP6 – Installation and integration of the system
The work herein pre-required that the new End-User Group vessels were integrated in the system as to be able to do the necessary ‘real-life’ testing and validation. Even though this activity only required a ‘light’ and relatively simple installation and integration (i.e. the experiences from previous installations/integrations could be utilized) assessment of the installation (in terms of performance optimisation) and the system’s interfaces to the various ship systems were need to be assessed. It was need to be clarified which functionality improvements would be achieved by introducing satellite observations (for example if extraction of satellite data should be used to justify sail plans for the sea master).
Tangible objective: Installation and interfacing guideline
Objective 7: WP7/WP11 – Total system performance and system evaluation vs. requirements
Sub sequential and systematic testing of complimentary satellite sensors and geophysical algorithms under various metocean conditions allowed the sail plan performance gain to be identified, assessed, and improved. Similarly, introduction of various ‘known’ errors in the system during those various testing and experimental activities allowed assessing the quality and importance of the system for identifying situations and scenarios where the sail plan model could underperform. By logging the actual geophysical conditions onboard a vessels (e.g. ocean currents from the 3D Doppler profiler, ocean wave height from navigational radar extractor, etc.) the correctness of the geophysical satellite observations could be verified according to observed local ship-based environmental, sea state and geographical situations (i.e. a very comprehensive volume of ‘ground-truth’ data were logged in the ORC). Discoveries resulted in selection of data sets and algorithms dependent of metocean/geographical situations, and required algorithms to be somewhat modified accordingly.
Tangible objective: Functional performance achieved according to initial requirements.
Objective 8: WP8 – IPR and patent protection
The SpaceNav project utilized a draft patent but the experimentations provided further insight into system qualities that now have become protected and included in a comprehensive patent filing. Thus a reassessment of the patent, modifications and extensions were emphasised carefully and thoroughly. Our legal council assessed the real protection that this patent now gives the SMEs in light of the continuous competitor study conducted by the SMEs. Obviously, a rock-solid patent is one of the success factors of this type of venture.
Tangible objective: Filed patent submitted
Objective 9: WP9 – Analysis of requirements for commercialisation ramp-up
The final performance characterisation were summarized for all the requirements that were first identified, assessed and prioritized at the beginning, cf. ‘targeted impacts’ chap 1.2). Cost assessments of operating the system (including costs of acquiring EO data) formed the baseline for an offering on a non-exclusive basis to the shipping industry based on a market study and business plan
Tangible objective: Expression of interest from two independent shipping companies for purchasing licenses for the system
Project Results:
WP1
All the tasks related to the WP have been completed. We specified the end-user needs for performance characterization of the sail plan under various conditions concerning weather and sea state. The project partners also performed the procedure to select the optimal satellite and EO data feed configuration for the various maritime observations. The consortium discussed how the space-based observations can best be utilized and tested. The earth observations are a crucial part of the system. The partners elaborated on the installation, integration, test, evaluation and validation of the system. Plans were compiled to ensure that the end-user feedback is taken into full consideration for the final implementation.
Most of the work has been described in deliverable D1.1 which was the only deliverable due in the first period of the project. The project partners have assessed and agreed on the main user scenarios of added value for the end users; then the end-user’s user needs; and then their user requirements have been established jointly with scientists and end-users. Based on these user requirements technical and system considerations could precede, including the ICD (Interface Control Document), the ADD (Architectural Design Document), and so forth. Furthermore, the selection of candidate vessels was discussed with end-users as well as important aspects of the installation of the system’s main components.
The preliminary analysis of the proposed system should be able to fulfil most (and over time all) of the user requirements, and thereby the market expectations of the system. The most critical aspect has been the ability to retrieve sufficient amount of EO data (as to be able to obtain as high temporal sampling of key observational parameters in the area of the vessel as possible).
There was 1 deliverable to be submitted under this WP:
• D1.1 Functional, system, sensitivity and validation requirements, including test plan for system characterisation
It has been submitted on time.
WP2
This work package dealt with all Earth observation (EO) data that are relevant as input to the SpaceNav sail plan system. During the first 12 months of the project, an assessment of algorithms and sensors for retrieval of wind, sea surface currents, waves, sea surface temperature, sea ice concentration, sea ice drift and a few secondary parameters was done and recommendations on which ones to use for SpaceNav were given. Programs were developed to download and read data from several of the recommended data feeds. These data feeds included information from EO sensors, numerical models and in situ observations. During the final project months, additional downloaders and readers were added so that a large total number of data feeds were accessible at the end of the project.
Significant improvements were also made on the “data selection algorithm” that is used to merge all information from the data feeds. The data selection algorithm is a core component of the sail plan system with the task to provide the best possible meteorological and oceanographic input to the models that estimate the fuel consumption and suggest optimised routes for each vessel. The data selection algorithm is configured to learn from previous routes and thereby gradually improve its accuracy.
The primary objectives of all WP2 tasks were fulfilled and all three deliverables were submitted and approved during the first reporting period.
There were 3 deliverables to be submitted under this WP:
• D3.1 Assessment of usefulness of available and upcoming EO sensors
• D3.2 Assessment of usefulness of available and upcoming EO products
• D3.3 Recommendation and implementation of EO algorithms and EO data processing
All have been submitted on time.
WP3
This Work Package has provided a report D3.1 (month 15) describing project’s data access and agreements with external providers, ownership structure of the project’s data and distribution of the project data (including license agreements) for the SpaceNav system. Moreover, it delivered D3.2 presenting a description of sail plan model integration and adaptation.
There exist a large number of providers of metocean information, but only some of them are suitable for inclusion in the SpaceNav system. The project consortium assessed and selected the most valuable for the SpaceNav project. The SpaceNav consortium decided to use access to the metocean data granted by providers such as MyOcean, KNIM, AVISO, HBM Baltic Ocean, OSCAR, UK Metoffice, ECMWF, NCEP, and many more. The data and products were successfully licensed and agreements are now in place. The consortium looked for additional data feeds over the course of the whole project until the last month and subsequently included those into the system.
The data ingestion module of the sail plan has been adapted to incorporate the new additional observations.
Note that this WP also contained preparation for the integration of algorithms needed for extracting geophysical parameters from the EO data; a strategy and implementation plan for this have been established.
The observation module was modified to cope with both weather forecast data and satellite observations (in addition to local observations). Some modifications were needed since data format support etc. was not able to cope with these new types of data. Even thought the module itself was cynical to what ‘type’ of data that was pulled inn, it still needed to be upgraded to accommodate new formats, data rates, encryption, etc.
Once the EO data are within the sail plan server it gets distributed to the various sub-modules and sub-models. The internal communication in between the modules is now standardized; thus the initial EO data now are converted into this format for further utilization.
Inclusion of EO data furthermore required a redesign of modules, models and sub-models, including the crucial MPMA (i.e. feedback loop). The MPMA module was the most difficult to develop within the span of SpaceNav, therefore this specific module will be further developed in a follow up project (with already secured funding). The observation module of the sail plan system has been modified to cope with both weather forecast data and satellite observations, as well as loads of other in-situ observations.
Once the entire adaptation process was completed the full system was tested to check the anticipated functionality plus any reliability issues. A brief test plan was generated and followed where we introduced various errors in the incoming EO to check how redundancy procedures were executed. There were also performed tests in respect to heavy EO data loads of different formats and geographical projections, etc. ingested simultaneously.
There were 2 deliverables submitted under this WP:
• D3.1 Summary of project data access and agreements
• D3.2 Sail plan model integration and adaptation
All have been submitted on time.
WP4
The main purpose of this WP was to describe the data exchanged in SpaceNav, with a specific attention to the interactions between the ships and the sub-systems Onshore Repository Center (ORC), Offshore Integration Platform (OIP), Graphical User Interface (GUI), including a description of the data interfaces between the SpaceNav processors (algorithms) and the relevant data products and product providers for Earth Observation (EO) data. The Interface Control Document (ICD) supported the development of a conceptual layer, decoupling the ORC and OIP from the EO algorithms and the data feeds ingestion procedures. The main objective was to create a simplified production environment (informally known as a Small Scale ORC) that supported the development of the entire SpaceNav processing chain, including data ingestion, so that each module could be developed (and tested) independently by different teams, in different companies. The idea was to exploit this small scale system to develop a complete suite of algorithms before the actual integration in the ORC system.
Data is vital to the algorithms in order to produce the optimized sail plan/route. In order to properly execute the algorithms the system expects key parameters to be produced by the ship. Other data is gathered by a number of providers, e.g. metocean data. The ship itself is considered by the ingestion procedures in the SpaceNav ORC in a way similar to the internet-based web feed sites providing EO data. From the point of view of the ORC the ship is capturing and producing data on-board, keeping them in a repository on the ship local network. The data is synchronized between the ship and the offshore infrastructure when needed, at regular intervals, and when the communication infrastructure is available and supports the necessary bandwidth. SpaceNav developed the ICD for modules and EO data feeds which generated a working document used during the project to describe the actual interfaces. The prototypes of GUI OIP and ORC were developed with this very clear separation between interfaces.
The Researcher Production Environment (RPE) was developed for SpaceNav. The RPE is a simplified production environment running on generic machines (with lower performances) based on a Virtual Machine approach to simulate the critical parts of the high-performance ORC. As the RPE can run on a modern-spec’d laptop, it can be deployed at the algorithms designers’ premises, to simplify the remote integration activities having a common shared environment to develop, test and debug the code integrated in the ORC. These development platforms allowed the researchers to start the development and the integration of their algorithms early in the project. As the processing chain is quite complex, e.g. including a Route Optimiser, a Data Selection Algorithm which needs many different remote data ingestion modules, and the correspondent file format conversion modules, the number of separate elements to individually test and maintain is a large number of modules, so the investment of developing such a platform is justified, as the process of upgrading the ORC with continuously improved (and debugged) versions of the algorithms is simplified. In previous projects a number of physical hands-on workshops were required, often with engineers working on the same machine, in SpaceNav most of the integration activities are based on sharing data and modules which can run on the common RPE, and the meetings can be based on teleconferences, email exchanges, greatly reducing the number of travels necessary to have face to face meetings, and also reducing the number of iteration between partners for the actual algorithm integrations, especially avoiding moving around large test data.
The EO products are provided to SpaceNav as input data for the route optimization algorithms. In can be classified in two categories: primary parameters and secondary parameters. The primary parameters are considered to be of primary importance for optimizing the sail plan of a vessel while the secondary products may be used (but not necessarily critical) in the sail planning process. The prototypes for all the Data Feeds ingestion procedures including downloaders and file format converters have been developed and updated a number of times. Also the prototype of the Small-Scale processing chain was completed, including the Data Selection Algorithm, the Route Optimiser, run in the inexpensive Researcher Production Environment virtual machine (Ubuntu 14.04) tested with simulated or archived data to support experimental and operational verification.
There were 4 deliverables submitted under this WP:
• D4.1 SpaceNav interface control document
• D4.2 Research production environment prototype
• D4.3 Data feed ingestion procedures prototype
• D4.4 Small-scale processing chain prototype
All have been submitted on time.
WP5
Implementing new technology introduces uncertainties that imply risk for its developers, manufacturers, vendors, operators and end-users. Concepts with well-known and proven technology are often preferred to solutions with non-proven technology, even if the latter provides significant operational improvement or cost-efficiency. Qualifying new technology can enable its implementation, thereby helping to create new business opportunities and improve profitability.
The goal of WP5 was to develop a technology process for guiding the consortium in its development of the SpaceNav Technology qualification (TQ) is the process of providing evidence that the technology will function within specified limits with an acceptable level of confidence. Its purpose is to enable industry to cost effectively put technology into safe use.
The TQ process was conducted in accordance with a recommended practice / qualification procedures for new technology. This recognized industry standard provides a systematic approach to the technology qualification process and is thus a tool to guide the development of the SpaceNav technology so that it will function reliably within the specified limits.
We established the minimum performance criteria for a routing decision support system (RDSS) that integrates space-based remote sensing observations into sail planning tools with the objective of achieving significant improvements in sail plan accuracy, reliability and optimization. The result was the Technology Qualification Basis, to be used for assessing the SpaceNav Routing Decision Support System. The performance criteria developed form the basis for the technology qualification. That is, they are the benchmark against which the success of the technology’s performance will be measured. The TQ Basis were developed using relevant requirements in regulations, standards and industry practices, as well as requirements of relevant stakeholders, including potential end-users. The results of several scenarios conducted with end-users were analysed to define critical information and presentation standards for effective decision-making. The performance criteria include hardware and software aspects and also the minimum requirements for integration in the ship bridge equipment (e.g. usability, accuracy, integrity, compatibility, reliability, etc.).
The objective was also to establish a framework for developing the technology qualification plan (TQP) for assessing the SpaceNav System functionality. The TQP, published outlines:
• Which aspects of the SpaceNav technology need to be qualified and which do not;
• The performance criteria that the relevant aspects of the Spacenav technology must meet; and
• The methods and activities that must be undertaken and the evidence that must be collected to determine that the technology meets the relevant performance criteria within the specified reliability limits.
• Lists responsible partners collecting evidence on system performance
The framework for supporting the development of the TQP developed forms the guideline for developing detailed test plans for the SpaceNav product. In later stages this framework was used by the responsible partners for forming detailed test plans and collecting evidence that the system either functioned as anticipated or where further refinements were needed.
By using the TQ process, the consortium members could determine if/when the technology is ready to be subjected to a formal product certification process against a suitable industry standard. When this had been completed to the consortium’s satisfaction, it recommends considering the submission of the product for type approval against type approval certification standards.
Type approval certification was not part of the SpaceNav deliverable, but is a useful process for the product commercialization once a commercial product is ready.
There were 2 deliverables to be submitted under this WP:
• D5.1 DSS assessment, recommendation and presentation of SpaceNav system
• D5.2 SpaceNav system approval standards and procedures
Both have been submitted on time.
WP6
System installation and integration WP tasks were planned to start on the 7th month of the project and should have been finished month 24. However, the installation process lasted till month 35. The main tasks, which have been performed during the project:
• System installation and integration
• System initial validation
• System evaluation versus requirements
The partners have been working on the plan for the installation and integration of the system on-board of our test ship Color Magic. The installation and integration plan has been in place. The project participants focused on the installation and proceeded. The installation process took much longer than anticipated. The delay was caused mainly due to the various issues we had with the ship data providers and communication with the ship crewmembers. We had to negotiate installation activities with 3 data providers onboard: Sperry, Valmarin, NAPA, where each of the providers required at least 4 weeks period for their service delivery. Installation was successful and finalised during month 35.
The next step was to initially validate the performance of the system. After the system was integrated, calibration and validation exercises were conducted to check that all system parts/components operate nominally. The first tests were conducted jointly with the end-users and the development partners. This is different from the further testing activities of WP 7 and 9 that was performed to basically check the ‘real-life’ sail plan performance; the checks here was simply to validate the IT installation.
There were 3 deliverables for the period:
• D6.1: Installation and integration plan to prepare for the ship installation of the SpaceNav system on vessels (already delivered at Month 18).
• D6.2: Installation and integration of the system on a vessel.
• D6.3: Calibration and validation exercise to check that all system parts/components operate nominally; evaluation of integrated system versus requirements.
All deliverables were submitted on time.
WP7/WP11
The main objective has been the development of the prototypes and technical infrastructure to support the operational SpaceNav system. Main technical output for the SpaceNav activities were the definition, the design and the development of the SpaceNav prototype, which can support the SpaceNav concepts in an operational environment.
The Key SpaceNav infrastructures (developed in WP7) are
• The Onshore Repository Centre (ORC) a scalable multi-processor server architecture, 300Mb/s hub for data integration, long-term and rolling archive and processing centre for the project, derived from Sentinel PDGS, exploited by EMSA traffic monitoring service (operationally supporting +2400 transactions/sec)
• The Offshore Integration Platform (OIP) a system to remotely acquire ship data in realtime - installed on-board ships
• The Graphical User Interface (GUI) designed in collaboration with the consortium, maritime expert and actual end-users.
The ORC System is a fully functional system currently used as semi-operational platform for SpaceNav, hosting the sail plan models and processing the SpaceNav algorithms, ingesting a large number of global coverage data (e.g. weather data) and a significant number of ship-own parameters needed by the various processing modules.
The Offshore Integration Platform is basically a computer installed on-board running a series of custom-developed programs which are responsible for capturing static and real-time information from the various Data Provides on board - e.g. VDR, NAPA, loading computers, e-logs (so-called Data Hubs), and communicate these ship parameters to the ORC on-shore, where the SpaceNav Algorithm Suite (downloaders and route optimizers) process the data.
When the upload conditions are met (e.g. when the minimum required amount of data is captured; and the connection is available; and a pre-defined interval of time has passed) the OIP produces a small footprint Ship Sync Data Packet to be sent to the ORC, normally via a custom configured VPN. Additional data is normally coming from the GUI, capturing the user selection for the sail plan to be optimized or other GUI interactions/settings.
The OIP also provides live ship parameters in real-time to the GUI for visualization (e.g. ship position as reference in the cartography layer; numeric data to be presented to the user, etc.).
The internal OIP data format is normally the format of the source data (e.g. NMEA ASCII Strings, Modbus, etc.) but can be changed to an intermediate or custom SpaceNav format, according to the software requirements.
Activities around the OIP data management included the acquisition of the real-time ship parameters (which is a separate specification for each ship), the ship Virtual Private Network configuration, the configuration of a shared storage on the ship network, the configuration of a FTP Sync between local ship storage and the ORC, and the collection of a selection of data explicitly for the visualization of ship parameters in the GUI (i.e. real-time data not sent to the ORC, but directly sent to the GUI to be visualized on-board).
Making the key parameters available over the test-bed ship local network has been a complex activity, which included solving many external technical problems (e.g. understanding firewall issues and ship network topology) as well as establishing strategic relationships with third party data producers. In general, it concerned understanding what is available over the ship serial network, and how the SpaceNav systems could obtain access to the data. Also the consortium faced issues in interfacing OIP with serial hub ports, incorrect connects, incomplete installations, missing network sockets and many other installation issues, which increased complexity to already complex activities in this work packages.)
To support the development of the data interfaces, the main question was how to extract all the data vital to the algorithms from the existing devices on-board. These activities included also how to move the data from third-party data providers (Data Hubs) to the SpaceNav OIP on-board repository through the ship network, which has peculiar characteristics that make the solution different from the generic infrastructure network of, for example, an office building.
In order to extract the data the OIP supports four main approaches:
• Data Hub has custom procedures that move selected data from local storage to a OIP shared storage
• The OIP can directly read selected data from Data HUB shared storage
• The OIP reads selected data from network socket communication, establishing a real-time bi-directional data exchange
• The OIP reads data from serial ports, when they are available, which normally add to the complexity of a local serial cabling for each device, a necessity when the device requires one way passive data capture (i.e. for safety reason)
During the project development, for each ship, the missing vital data (to the algorithms) from the interfaces had to be clearly highlighted and assessed, more than once during the project lifetime. Other kind of data can be “nice to have” data which could be unavailable without impacting the processing of optimized ship route. Specific programming effort was spent to deal with these cases. In particular the algorithms implement error/warning reporting and error management, specifically around missing vital data from the ship or the web services. This information is kept into the ORC DBMS, and in the OIP in a log file. A selection of this warnings/errors can be displayed on the GUI.
The GUI itself is one of the main consumers of data produced by the ORC. In particular the improved sail plan is sent periodically to the ship, along with key statistics for each waypoints. A low-resolution version of the metocean data used for the processing on-shore can be also sent to the ship if the ship bandwidth supports this type of data.
Particular effort was put into testing the Custom Ingestion Procedures that is offline data and real-time data readers for the last version of models and algorithms. A set of ingestion procedures was tested for relevant satellite EO data, with a clear defined maintenance scheme. Sail plan models and Route Optimisers were integrated including their technical documentation.
The work further related to system evaluation of the SpaceNav system. The main results of the validation of products (models and Earth Observation data) were for three primary parameters (waves, wind and sea surface current) and showed that EO data is essential in order to be able to derive an accurate sail planning system as forecast models have inherent errors and ambiguities that degrade the overall sail planning output.
WP7 and WP11 are successfully completed, with all development and design activities completed in time.
There were 4 deliverables in the WP 7 and 1 in WP11:
• D7.1: ORC System prototype
• D7.2: OIP System prototype
• D7.3: GUI System prototype
• D7.4 Custom Ingestion Procedures for SpaceNav data feeds
• D11.1 Report on the results from the iterative evolutionary evaluation lab runs and potential shortfalls of the tests
All deliverables were submitted on time.
WP8
The system and end-user requirements have generated the industrial designs of the various system modules. These have been integrated and validated against the initial requirements. These industrial designs together with the integrated system and validation reports were the core of the Intellectual Property (IP) developed in the project. Since these modules have been advanced beyond technologies used elsewhere (for other applications) as well as further researched and developed it was important to consider all elements that could forme one or several patent application(s), which in essence is the remaining value of the leading SMEs (and their protection against being replicated by potential competitors). The task was therefore to perform these assessments in order to allocate a pool of IPR (in a separate entity named Offshore Navigation Ltd) that could be utilized as to write and issue well-considered patent application(s). The consortium updated a dedicated IPR register monthly. At the end of the project the IPR register listed all the potential inventions, which were created in the project.
Based on the pool of IPR generated in the previous task, an extended patent search has been performed to clarify the content of a patent application of the project. The consortium drafted one patent application. It has been issued for examination in order to be granted a ‘Space-based maritime navigation and sail plan system’ patent. We collaborated with our patent lawyers for assistance in the patent process. Please note that the patent protection process is expected to continue after the project.
The consortium also has been assessing strategic plans to maximise the investment in the project on regular basis. Risks were listed in form of a risk register document and updated monthly. The risks were being mitigated and resolved on a regular basis.
In the beginning of the project a project’s website was created: ww.spacenav.eu. Moreover a documentation archive based on a cloud solution was created and made available for all partners.
Moreover, a video clip was created presenting the SpaceNav system’s functionality and instructs how to use the current SpaceNav user interface. A workshop had various industry participants to join presentations and discussions of the system in addition to an onboard ship demonstration. The invited entities could see the results of SpaceNav project’s work. Finally the final plan for the use and dissemination of knowledge was prepared and delivered.
There were 6 deliverables submitted:
• D8.1 Draft patent application
• D8.2 Project website for management, communication & dissemination purposes
• D8.3 A short video clip
• D8.4 Final plan for the use and dissemination of knowledge, including conditions for access to background
• D8.5 Workshop on safety sensors for Maritime Purposes; present results at project end
• D8.6 Interim plan for the use and dissemination of knowledge, including conditions for access to background
All have been submitted on time.
WP9
After the development and testing of the SpaceNav sail plan service prototype we needed to consider the roll-out of a commercial sail plan service where the system should be functional at any time with (unlimited) number of vessels. Due to limited time within the project we started the process however it will be continued in a follow up activity (funds are already secured).
After demonstration carried out onboard a vessel the consortium was able to check the system’s performance characterization. Quantities and qualities of the system were confirmed. The operational evidence of fuel, emission and fatigue benefits were listed and included in the prospect for commercial clients.
We were able to collect end-user generated feedback on simple forms of commercial interest that the end-users have been asked to fill-inn at the end of the project. Moreover, for every ship visit (for integration, upgrades or maintenance) the project members had a list with questions that needed to be asked to the end-users during their visits. In other words, there were several means available to receive an honest opinion about the actual end-user perceived pros and cons of the sail planning system. These questions all addressed the end-user perceived operational effectiveness of the integrated system and thereby provided client (market) traction that have been exploited in a commercial context as to define the business case.
A business plan has been generated where we included a market analysis primarily focusing on the high value shipping market (i.e. passenger and energy (gas/oil/chemical tank) transport) and secondarily on the high-end of the secondary shipping market (i.e. container, specialized cargo, RoRo). The business plan also clearly identifies the potential risks of operating the service. For each of these risks the remedial actions have been identified. The business plan contains the need for continuous future R&D in order to continuously improve the performance of the system (e.g. extended sets of validation checks), and in this way keep ahead of the competition. Finally, it contains an assessment of the acceptable unit price for the SpaceNav service. This price is a function of the cost for acquiring satellite and other platform observations in (near) real time. Obviously these costs would be comparably smaller if divided by extended number of customers.
There were 3 deliverables submitted:
• D9.1 Sail plan performance summary
• D9.2 End-user quality statement summary
• D9.3 Business Plan of SpaceNav
All have been submitted on time.
WP10
The main task was to control the various aspects of management of the project, including the maintenance of the consortium agreement and the overall legal, ethical, financial and administrative management.
All the obligations were fulfilled.
There were 4 deliverables submitted:
• D10.1 Report on Gender Aspects
• D10.2 Management summaries based upon progress status sheets provided by the WP and task leaders
• D10.3 12 monthly management and activity reports in conformity with Commission’s guidelines for periodic reporting
• D10.4 Final technical activity report and publishable report
All have been submitted on time.
Potential Impact:
Potential impact
Targeted impacts of the sail plan model are
• 90 % accuracy in ETA (Estimated Time of Arrival)
• 7% savings on fuel consumption (10.5 tons/day for a 4545 TEU container ship)
• 7% savings of CO2, SOx and PM emissions from ships
• 15 % extension of the service life of ships, i.e. from 30 to 34.5 years
• 20% savings with respect to maintenance and inspection costs
Impact on end users and the European Commission
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.
Fuel reduction
Fuel prices for maritime transport are now from 20% up to 60% of total operational vessel costs in yearly averages, but with very significant and unpredictable variations that can cause severe financial impacts to the industry. SpaceNav is achieving a significant fuel reduction in the operation of a ship due to the improved and accurate sail plans that are updated in real time. In effect, a virtual ship-specific IT centre continuously calculates the optimal sail heading and speed for each ship, based on the most up-to-date Earth observation data and numerous numerical models.
Impact: 7% savings on fuel consumption (10.5 tons/day for a 4545 TEU container ship)
Emission reduction
Similarly, the emission of CO2 and other pollutants (such as sulphur dioxides, nitrogen oxides and fine particulate matter) can be reduced, resulting in less pollution along major trade routes and coastal areas. In particular, it allows the ship operator to become aware of the actual ship pollution and thereby provides means to comply with environmental regulations at any given geographical location.
Impact: 7% savings of CO2, SOx and PM emissions from ships
Optimization of ship maintained schedules and asset preservation
The life expectancy 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. Commercial ships are designed for a life expectancy 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. On the other hand, with the appropriate observational data and 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 extend the life expectancy of the ship asset.
Impact: 20% savings with respect to maintenance and inspection costs
Impact: 15 % extension of the service life of ships, i.e. from 30 to 34.5 years
Optimization of sail plan
SpaceNav makes it possible to optimize the sail plan according to operational requirements, such as port slot times, channel passing slots (Suez or Panama channel) and tide schedules (for instance, a VLCC needs 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 their destination due to various risks, in particular uncertainty in the weather forecasts and sea state conditions. This causes large overheads as typically the ship operates at comparably very low speed during the last hours of a journey. With a more accurate sail plan based on real-time weather and sea state observations, time margins can be greatly reduced.
Impact: 90 % accuracy in ETA (Estimated Time of Arrival)
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’s shipping fleet . SpaceNav proposes to strengthen the competitiveness of this significant European shipping trade by:
• Improving operational efficiency with respect to functionality, 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).
Expected environmental savings
The example of the container carrier (cf. Ch 4.1.2) with respect to the potential CO2 emission savings, SpaceNav is expected to achieve savings of 8,353t CO2 per year. When the IPCC scenario becomes reality, this reduction would compare to an $816,667 saving per ship p.a (using the IPCC reference numbers for the calculations).
Partners revenue
The partners will have the potential to gain revenues after the project from two main revenue streams:
1. The monthly subscription fees from its core optimization services such as
a. Fuel Optimizer
b. Emission Optimizer
c. Asset preservation/Passenger Comfort Optimization
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 to collect valuable journey data as to continuously improving the quality of the service, the Fuel Optimizer will be marketed as a free service during the 1st year of a subscription service.
Main dissemination activities
Website
At the start of the project a public website was setup and maintained during the project as the communication channel towards the general public and targeted public, cf. www.spacenav.eu. The web-site www.OffshoreNavigation.com will be used for further commercialisation activities.
Publications
A total of 10 publications were done, including oral presentations at several conferences.
Conferences/Workshops/Demonstrations
Dedicated workshops were organized, mainly with the project partners and several external technical persons.
At the end, there was a dedicated demonstration organized for end-users. This was held onboard of Color Magic during an Oslo-Kiel-Oslo voyage.
Main exploitable results
ONL
All exploitable results are owned by the project’s spin-off company Offshore Navigation Limited (ONL), please see www.OffshoreNavigation.com
List of Websites:
Website
The project public website has been set up for the general public and can be found at the web address: www.spacenav.eu The website provides general information on the project objectives and the work performed as well as details of the project partners, and contact details for the project coordinator. The website will be accessible for some years after the project is closed.
Contact persons
The Coordinator
Offshore Monitoring Ltd
26 Nikou Pattichi, 3071 Limassol, Cyprus
Contact person:
Dr. Sverre Dokken
Telephone: +357 250 30 500
Email: info@offshoremonitoring.com
The overall strategy of the SpaceNav project was to assess all types of real-time information capable of improving operational vessel routing; to further develop a new generation of sail plan models that include real-time local and remote observations; to enhance the reliability of metocean forecasts and thereby fuel consumption and emission reduction models; to develop and implement these capabilities in an On-shore Repository Centre (ORC) and in a decision making aid onboard vessels; to install, run and optimize this SpaceNav system on end-user vessels; and to conduct sensitivity and performance analysis in real operations and ask the end-users to evaluate the usefulness, quality and performance of the service. The project management focused on dissemination and exploitation of the results including the correlation with certification and approval strategies under International Maritime Organisation (IMO).
In this report a summary is given on the work achieved within the project. In the Publishable Summary Report a description is provided per work package on the achievements compared to the objectives. Further, the potential impact is described, including the dissemination activities and exploitable results. At the end, the contact details are provided.
In general it can be concluded that the objectives of the project as defined in the proposal and description of work are mostly achieved.
Project Context and Objectives:
Project context
The maritime industry is seeking solutions to reduce fuel consumption (energy efficiency) and air emissions due to economic pressure and environmental regulations. Shipping is by far the biggest transport polluter globally. A recent survey by DNV GL found that weather routing and voyage optimisation are key measures to implement to increase energy efficiency. A ship can consume up to 16 tons of fuel per hour or with a fuel price of USD 657/ton (the average fuel price in 2014) spend over $200,000 /day. Ships over 100 Gross Tonnage (GT) (90,000 vessels) burn approximately 370 million tons of fuel per year, emitting 800 million tons of CO2, 20 million tons of sulphur oxides (SOx) and large amount of Particular Matters (PMs). Calculations performed by DNV GL and BW Gas in predecessor EU FP7 projects (and subsequently experimentally verified) demonstrate that the SpaceNav sail plan routing service can provide approximately 7% fuel and emission reductions for a ship. That will be generating a global saving of 56 million tons of CO2, 1.4 million tons of SOx, and over 5 million USD per year for a ship over 100 GT. The SpaceNav concept initially secured funding in 2008 (as a FP7 project), with several private/public initiatives (of over €10 M) further refining user needs and service functionality.
Strict energy performance and air emission regulations are coming in to force. The MRV (Monitoring, Reporting and Verification) regulation will quantify and reduce CO2 emissions from shipping. MRV is designed to progressively integrate maritime emissions into the EU’s policy for reducing domestic greenhouse gas emissions (EU regulation 2015/757). MRV requires ship owners and operators to annually monitor, report and verify CO2 emissions for vessels equal to or larger than 5,000 GT and which call at any EU port. Entered into force on 1 July 2015, the regulation will become fully effective on 1 January 2018, which means that shipping companies will need to prepare a monitoring plan by 31 August 2017 at the latest for each of their ships that falls under the jurisdiction of the regulation. They must monitor and report the verified amount of CO2 emitted by their vessels on voyages to, from and between EU ports and will also be required to provide information on energy efficiency parameters. Data collection will start on a per-voyage basis from 1 January 2018. SpaceNav fully facilitates these regulations.
Main objectives
The proposed system helps sea masters make better decisions in their sail planning process. It allows the operation of a vessel to become more cost efficient and environmental friendly.
The SpaceNav system mimics the well-proven procedure of own observations and experience. It uses real-time local observations in a very similar way, by combining them with more traditional metocean forecast and satellite observations. The experience factor is 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 is realized that increases the "experience" and performance of the system over time.
Prior to SpaceNav action the developing team of our sail plan system managed to accomplish several objectives in previous projects. The starting point of the previous projects 8-years ago was to prioritize functional needs of a sail plan system. These were derived and assessed by end-users, translated to technical and system requirements of the RTD partners, culminated in the design and implementation, and recently tested and validated. Experimentation to validate the concepts has been essential for the successful design of the system. The achievements underlined the need for further addition of (first of all) satellite observations and - importantly – the development of a sound business and commercialization plan that acknowledge the significant contributions of the leading SMEs.
The first objective of the addition of satellite oceanographic observations was one important component of an all-encompassing multi-platform, multi-sensor sail planning system improvement. Experimentation with additional complementary satellite sensors allows for their extended use but also allows a better understanding of the qualities of these comprehensive observations for sail planning. Therefore, the extended value of satellite multi-sensor experimentation enables better insight in the unique qualities of these observations, that nowadays have become the core observations for the sail planning service. These qualities have been precisely identified, as they are the core and essential part of the commercialization rollout.
The sail plan architecture is such that the modular system can incorporate a diverse set of observational sensors so that new types of functionality can be added incrementally. Particularly, the addition of satellite ocean current observations is a great improvement to the unprecise charts used elsewhere today.
Of particular interest was to tie various weather forecast model output (that is used today in the sail planning market) to the actual satellite observed conditions, in order to ‘correct’ the forecast based on actual satellite observations. In other words, the forecast error is ‘restricted’ by the satellite observations, and thereby enable the current sail plan sensitivity to forecast errors to be reduced. This ‘tie-point’ process is continuously calculated as new observations and forecasts are pulled-inn by a Onshore Repository Centre (ORC). (Note that the intention of this project was not to interfere/modify/improve or provide any type of feedback to the developers of weather/metocean forecast models). Combined the general metocean forecast models (including its inherent errors) and satellite observations thereby provides a qualified input to sail planning, and thereby consequently enable a better qualified calculation of waypoints along the route of a vessel. Note that this activity is not only feasible in the initialization of a voyage but continuously along the voyage as satellites continuously observes and met ocean forecast models are continuously producing outputs.
Furthermore, a specific objective is to validate (with the help of the ‘feedback-loop’ of the MPMA module) how the various algorithms applied to satellite observations are able to correctly extract the sough-for geophysical observations (primarily ocean currents, waves, wind and sea ice concentration and motion). This can be validated since the ships are observing these geophysical parameters and thereby produce ‘validation’ data. This ‘a posterior’ experience in turn can help select the geophysical satellite algorithms producing the better results (as a function of several variables like metocean conditions, geographical locations, etc.). Thus these ‘validation results’ are taken into account in the MPMA module to statistically be able to select the observation data set with the most qualified observation platform, sensor, and geophysical extraction algorithm under prevailing metocean conditions to be used. This is of great help for the developers of such algorithms.
Note that the previous ‘a posterior’ method of checking the correctness of satellite input observations has been further improved. An earlier version of our sail plan model was not self-aware of degraded input observations, i.e. there was no automatic mechanism to avoid degraded observations to be entered in the sail plan calculations (other than a data (structure) quality check). In other words, the sail plan model was providing sail plan output to the ships independently of the quality and quantity of input observation, i.e. the methods described so far herein are all checking qualities after the sail plan actually have been produced and followed. Therefore the specific objective was to improve the self-awareness module ‘a priori’ to monitor the correctness of satellite input observations (observation level) as well as its own performance and system health (system level), as well as how good (in terms of accuracy and availability) the system is performing as a function of the incoming satellite observational data. These calculations reflects upon the type of satellite data ingested into the system and consequently their value for the sail planning outcome. This can be utilized by using a set of normal monitoring and control data of each of the satellite observations to check the nominal status of the sensor or system. It may use a reference (that can either be specified in a model-based way or can be self-learned during calibration sessions) to monitor the output, or use redundant analytical relations between the various parameters to signal abnormalities. No additional sensors are used to implement this functionality. Thus the goal was to estimate the physical and operational condition of the satellite observational data input to provide an indicator of its condition. By interpreting the data coming from various satellite sources. This module is able to accomplish the following objective of (1) providing an estimate for the uncertainty of the observations presented to the sail plan model, and (2) providing an analysis of the nominal status of the ‘system’ of satellite observation ingestion module (i.e. if the observation data is transferred correctly to the sail plan server).
The culmination of the previous objectives (in terms of deriving more correct input observations based on satellite observations) helps deriving a quality flag that can indicate to the end-user/client and the system the anticipated quality of the provided sail plan (that will be a function of the derived quality of the input satellite observations). In other words, it adds-value to the end-user in its decision making by indicating to what extent the sea master can ‘trust’ the provided sail plan calculations.
Another objective was for the certification partner (DNV GL) (that initially has derived an approval procedure for the innovative system) to certify the satellite observation upgrade as to allow installation onboard commercial vessels as well as to derive a technical qualification process for this sail planning service.
A final objective was to establish agreements with additional satellite providers (i.e. in addition to ESA, ASI, MDA, NOAA, NSIDC) and EO data feed providers (i.e. in addition to MyOcean, EMSA, NOAA NCEP, AVISO, PO.DAAC EUMETSAT OSI SAF, NSIDC, University of Bremen) to (1) enhance observational input data volume and (2) avoid being ‘black-listed’ from providers due to ‘heavy-usage’ (i.e. this has been a challenge in the past). This included reassessing the available satellite sensor observations and their data providers (including eventual re- configuration/post-processing of data to fit into the model architecture’s reference system) to greatly enhance the amount and reliability of earth observation (EO) input data feeds to the system.
Objective 1: WP1 - Assessment of sail plan system performance characterization.
As the system is applied in safety-critical applications, a complete system performance characterization (i.e. complete for all sea states and environmental conditions) is an essential part of the information. The objective was to re-define how the performance (in terms of performance indicators) can be measured and assessed so that the end-users will have sufficient confidence in the system. Characteristics such as the probability of sail plan correctness and the quality of sail plan output under various sea state conditions were established for the system with and without the satellite sensor observations.
Tangible objective: Identified list of performance parameters reflecting end-user priorities
Objective 2: WP2 – Selection and integration of satellite EO
Several candidate missions and sensors are obvious for integration but a reassessment of available observations, and what type of observations are expected to be readily available, is essential to ensure that all possible EO data are included in the system. All these new feeds were incorporated in the sail planning service.
Tangible objective: Positive evaluation and preliminary validation of use of EO satellite data and algorithms
Objective 3: WP3 – Integration of the satellite geophysical observations
Including satellite EO to the system requires tested and readably available EO data feeds that can be used routinely, including redesign of modules, models and sub-models, including the crucial MPMA. Consequent changes were applied to the model based on the outcome of the previous objective. Data agreements were established with data providers and end-users/clients and third parties utilizing the service.
Tangible objective: Positive integration of EO satellite data and algorithms, plus contractual framework for data providers and clients
Objective 4: WP4 – Actual satellite EO operational verification
The objective was to control and verify that the EO data is correctly ingested in the system and that the models cope with the additional observations in an accurate and consistent manner without any type of degradation of input observations. The definition of “what and how” that needs to be measured (Objective 1) were tested in a ‘laboratory’ way as an ‘experimental’ basis for the actual selection of EO sensors and their performance characterization. There were extended series of experimentations to cover a large number of metocean conditions and geographical areas. The actual feedback loop of the MPMA module was logged to check various processes and calculations in the performance characterisation work, especially to qualify and quantify the value of the various satellite EO based observations.
Tangible objective: Positive experimental verification of use of EO satellite data algorithms for minimum 8 sea states
Objective 5: WP5 – Regulatory framework and certification
Based on the experimentation and exchange of system components, the final ‘frozen’ system were prepared for certification according to the certification strategy of partner DNV-GL. There were also established a technical qualification process to ensure that the service is fulfilling its anticipated technical objectives. Certification is necessary for a successful market introduction.
Tangible objective: Certification of the sail plan system
Objective 6: WP6 – Installation and integration of the system
The work herein pre-required that the new End-User Group vessels were integrated in the system as to be able to do the necessary ‘real-life’ testing and validation. Even though this activity only required a ‘light’ and relatively simple installation and integration (i.e. the experiences from previous installations/integrations could be utilized) assessment of the installation (in terms of performance optimisation) and the system’s interfaces to the various ship systems were need to be assessed. It was need to be clarified which functionality improvements would be achieved by introducing satellite observations (for example if extraction of satellite data should be used to justify sail plans for the sea master).
Tangible objective: Installation and interfacing guideline
Objective 7: WP7/WP11 – Total system performance and system evaluation vs. requirements
Sub sequential and systematic testing of complimentary satellite sensors and geophysical algorithms under various metocean conditions allowed the sail plan performance gain to be identified, assessed, and improved. Similarly, introduction of various ‘known’ errors in the system during those various testing and experimental activities allowed assessing the quality and importance of the system for identifying situations and scenarios where the sail plan model could underperform. By logging the actual geophysical conditions onboard a vessels (e.g. ocean currents from the 3D Doppler profiler, ocean wave height from navigational radar extractor, etc.) the correctness of the geophysical satellite observations could be verified according to observed local ship-based environmental, sea state and geographical situations (i.e. a very comprehensive volume of ‘ground-truth’ data were logged in the ORC). Discoveries resulted in selection of data sets and algorithms dependent of metocean/geographical situations, and required algorithms to be somewhat modified accordingly.
Tangible objective: Functional performance achieved according to initial requirements.
Objective 8: WP8 – IPR and patent protection
The SpaceNav project utilized a draft patent but the experimentations provided further insight into system qualities that now have become protected and included in a comprehensive patent filing. Thus a reassessment of the patent, modifications and extensions were emphasised carefully and thoroughly. Our legal council assessed the real protection that this patent now gives the SMEs in light of the continuous competitor study conducted by the SMEs. Obviously, a rock-solid patent is one of the success factors of this type of venture.
Tangible objective: Filed patent submitted
Objective 9: WP9 – Analysis of requirements for commercialisation ramp-up
The final performance characterisation were summarized for all the requirements that were first identified, assessed and prioritized at the beginning, cf. ‘targeted impacts’ chap 1.2). Cost assessments of operating the system (including costs of acquiring EO data) formed the baseline for an offering on a non-exclusive basis to the shipping industry based on a market study and business plan
Tangible objective: Expression of interest from two independent shipping companies for purchasing licenses for the system
Project Results:
WP1
All the tasks related to the WP have been completed. We specified the end-user needs for performance characterization of the sail plan under various conditions concerning weather and sea state. The project partners also performed the procedure to select the optimal satellite and EO data feed configuration for the various maritime observations. The consortium discussed how the space-based observations can best be utilized and tested. The earth observations are a crucial part of the system. The partners elaborated on the installation, integration, test, evaluation and validation of the system. Plans were compiled to ensure that the end-user feedback is taken into full consideration for the final implementation.
Most of the work has been described in deliverable D1.1 which was the only deliverable due in the first period of the project. The project partners have assessed and agreed on the main user scenarios of added value for the end users; then the end-user’s user needs; and then their user requirements have been established jointly with scientists and end-users. Based on these user requirements technical and system considerations could precede, including the ICD (Interface Control Document), the ADD (Architectural Design Document), and so forth. Furthermore, the selection of candidate vessels was discussed with end-users as well as important aspects of the installation of the system’s main components.
The preliminary analysis of the proposed system should be able to fulfil most (and over time all) of the user requirements, and thereby the market expectations of the system. The most critical aspect has been the ability to retrieve sufficient amount of EO data (as to be able to obtain as high temporal sampling of key observational parameters in the area of the vessel as possible).
There was 1 deliverable to be submitted under this WP:
• D1.1 Functional, system, sensitivity and validation requirements, including test plan for system characterisation
It has been submitted on time.
WP2
This work package dealt with all Earth observation (EO) data that are relevant as input to the SpaceNav sail plan system. During the first 12 months of the project, an assessment of algorithms and sensors for retrieval of wind, sea surface currents, waves, sea surface temperature, sea ice concentration, sea ice drift and a few secondary parameters was done and recommendations on which ones to use for SpaceNav were given. Programs were developed to download and read data from several of the recommended data feeds. These data feeds included information from EO sensors, numerical models and in situ observations. During the final project months, additional downloaders and readers were added so that a large total number of data feeds were accessible at the end of the project.
Significant improvements were also made on the “data selection algorithm” that is used to merge all information from the data feeds. The data selection algorithm is a core component of the sail plan system with the task to provide the best possible meteorological and oceanographic input to the models that estimate the fuel consumption and suggest optimised routes for each vessel. The data selection algorithm is configured to learn from previous routes and thereby gradually improve its accuracy.
The primary objectives of all WP2 tasks were fulfilled and all three deliverables were submitted and approved during the first reporting period.
There were 3 deliverables to be submitted under this WP:
• D3.1 Assessment of usefulness of available and upcoming EO sensors
• D3.2 Assessment of usefulness of available and upcoming EO products
• D3.3 Recommendation and implementation of EO algorithms and EO data processing
All have been submitted on time.
WP3
This Work Package has provided a report D3.1 (month 15) describing project’s data access and agreements with external providers, ownership structure of the project’s data and distribution of the project data (including license agreements) for the SpaceNav system. Moreover, it delivered D3.2 presenting a description of sail plan model integration and adaptation.
There exist a large number of providers of metocean information, but only some of them are suitable for inclusion in the SpaceNav system. The project consortium assessed and selected the most valuable for the SpaceNav project. The SpaceNav consortium decided to use access to the metocean data granted by providers such as MyOcean, KNIM, AVISO, HBM Baltic Ocean, OSCAR, UK Metoffice, ECMWF, NCEP, and many more. The data and products were successfully licensed and agreements are now in place. The consortium looked for additional data feeds over the course of the whole project until the last month and subsequently included those into the system.
The data ingestion module of the sail plan has been adapted to incorporate the new additional observations.
Note that this WP also contained preparation for the integration of algorithms needed for extracting geophysical parameters from the EO data; a strategy and implementation plan for this have been established.
The observation module was modified to cope with both weather forecast data and satellite observations (in addition to local observations). Some modifications were needed since data format support etc. was not able to cope with these new types of data. Even thought the module itself was cynical to what ‘type’ of data that was pulled inn, it still needed to be upgraded to accommodate new formats, data rates, encryption, etc.
Once the EO data are within the sail plan server it gets distributed to the various sub-modules and sub-models. The internal communication in between the modules is now standardized; thus the initial EO data now are converted into this format for further utilization.
Inclusion of EO data furthermore required a redesign of modules, models and sub-models, including the crucial MPMA (i.e. feedback loop). The MPMA module was the most difficult to develop within the span of SpaceNav, therefore this specific module will be further developed in a follow up project (with already secured funding). The observation module of the sail plan system has been modified to cope with both weather forecast data and satellite observations, as well as loads of other in-situ observations.
Once the entire adaptation process was completed the full system was tested to check the anticipated functionality plus any reliability issues. A brief test plan was generated and followed where we introduced various errors in the incoming EO to check how redundancy procedures were executed. There were also performed tests in respect to heavy EO data loads of different formats and geographical projections, etc. ingested simultaneously.
There were 2 deliverables submitted under this WP:
• D3.1 Summary of project data access and agreements
• D3.2 Sail plan model integration and adaptation
All have been submitted on time.
WP4
The main purpose of this WP was to describe the data exchanged in SpaceNav, with a specific attention to the interactions between the ships and the sub-systems Onshore Repository Center (ORC), Offshore Integration Platform (OIP), Graphical User Interface (GUI), including a description of the data interfaces between the SpaceNav processors (algorithms) and the relevant data products and product providers for Earth Observation (EO) data. The Interface Control Document (ICD) supported the development of a conceptual layer, decoupling the ORC and OIP from the EO algorithms and the data feeds ingestion procedures. The main objective was to create a simplified production environment (informally known as a Small Scale ORC) that supported the development of the entire SpaceNav processing chain, including data ingestion, so that each module could be developed (and tested) independently by different teams, in different companies. The idea was to exploit this small scale system to develop a complete suite of algorithms before the actual integration in the ORC system.
Data is vital to the algorithms in order to produce the optimized sail plan/route. In order to properly execute the algorithms the system expects key parameters to be produced by the ship. Other data is gathered by a number of providers, e.g. metocean data. The ship itself is considered by the ingestion procedures in the SpaceNav ORC in a way similar to the internet-based web feed sites providing EO data. From the point of view of the ORC the ship is capturing and producing data on-board, keeping them in a repository on the ship local network. The data is synchronized between the ship and the offshore infrastructure when needed, at regular intervals, and when the communication infrastructure is available and supports the necessary bandwidth. SpaceNav developed the ICD for modules and EO data feeds which generated a working document used during the project to describe the actual interfaces. The prototypes of GUI OIP and ORC were developed with this very clear separation between interfaces.
The Researcher Production Environment (RPE) was developed for SpaceNav. The RPE is a simplified production environment running on generic machines (with lower performances) based on a Virtual Machine approach to simulate the critical parts of the high-performance ORC. As the RPE can run on a modern-spec’d laptop, it can be deployed at the algorithms designers’ premises, to simplify the remote integration activities having a common shared environment to develop, test and debug the code integrated in the ORC. These development platforms allowed the researchers to start the development and the integration of their algorithms early in the project. As the processing chain is quite complex, e.g. including a Route Optimiser, a Data Selection Algorithm which needs many different remote data ingestion modules, and the correspondent file format conversion modules, the number of separate elements to individually test and maintain is a large number of modules, so the investment of developing such a platform is justified, as the process of upgrading the ORC with continuously improved (and debugged) versions of the algorithms is simplified. In previous projects a number of physical hands-on workshops were required, often with engineers working on the same machine, in SpaceNav most of the integration activities are based on sharing data and modules which can run on the common RPE, and the meetings can be based on teleconferences, email exchanges, greatly reducing the number of travels necessary to have face to face meetings, and also reducing the number of iteration between partners for the actual algorithm integrations, especially avoiding moving around large test data.
The EO products are provided to SpaceNav as input data for the route optimization algorithms. In can be classified in two categories: primary parameters and secondary parameters. The primary parameters are considered to be of primary importance for optimizing the sail plan of a vessel while the secondary products may be used (but not necessarily critical) in the sail planning process. The prototypes for all the Data Feeds ingestion procedures including downloaders and file format converters have been developed and updated a number of times. Also the prototype of the Small-Scale processing chain was completed, including the Data Selection Algorithm, the Route Optimiser, run in the inexpensive Researcher Production Environment virtual machine (Ubuntu 14.04) tested with simulated or archived data to support experimental and operational verification.
There were 4 deliverables submitted under this WP:
• D4.1 SpaceNav interface control document
• D4.2 Research production environment prototype
• D4.3 Data feed ingestion procedures prototype
• D4.4 Small-scale processing chain prototype
All have been submitted on time.
WP5
Implementing new technology introduces uncertainties that imply risk for its developers, manufacturers, vendors, operators and end-users. Concepts with well-known and proven technology are often preferred to solutions with non-proven technology, even if the latter provides significant operational improvement or cost-efficiency. Qualifying new technology can enable its implementation, thereby helping to create new business opportunities and improve profitability.
The goal of WP5 was to develop a technology process for guiding the consortium in its development of the SpaceNav Technology qualification (TQ) is the process of providing evidence that the technology will function within specified limits with an acceptable level of confidence. Its purpose is to enable industry to cost effectively put technology into safe use.
The TQ process was conducted in accordance with a recommended practice / qualification procedures for new technology. This recognized industry standard provides a systematic approach to the technology qualification process and is thus a tool to guide the development of the SpaceNav technology so that it will function reliably within the specified limits.
We established the minimum performance criteria for a routing decision support system (RDSS) that integrates space-based remote sensing observations into sail planning tools with the objective of achieving significant improvements in sail plan accuracy, reliability and optimization. The result was the Technology Qualification Basis, to be used for assessing the SpaceNav Routing Decision Support System. The performance criteria developed form the basis for the technology qualification. That is, they are the benchmark against which the success of the technology’s performance will be measured. The TQ Basis were developed using relevant requirements in regulations, standards and industry practices, as well as requirements of relevant stakeholders, including potential end-users. The results of several scenarios conducted with end-users were analysed to define critical information and presentation standards for effective decision-making. The performance criteria include hardware and software aspects and also the minimum requirements for integration in the ship bridge equipment (e.g. usability, accuracy, integrity, compatibility, reliability, etc.).
The objective was also to establish a framework for developing the technology qualification plan (TQP) for assessing the SpaceNav System functionality. The TQP, published outlines:
• Which aspects of the SpaceNav technology need to be qualified and which do not;
• The performance criteria that the relevant aspects of the Spacenav technology must meet; and
• The methods and activities that must be undertaken and the evidence that must be collected to determine that the technology meets the relevant performance criteria within the specified reliability limits.
• Lists responsible partners collecting evidence on system performance
The framework for supporting the development of the TQP developed forms the guideline for developing detailed test plans for the SpaceNav product. In later stages this framework was used by the responsible partners for forming detailed test plans and collecting evidence that the system either functioned as anticipated or where further refinements were needed.
By using the TQ process, the consortium members could determine if/when the technology is ready to be subjected to a formal product certification process against a suitable industry standard. When this had been completed to the consortium’s satisfaction, it recommends considering the submission of the product for type approval against type approval certification standards.
Type approval certification was not part of the SpaceNav deliverable, but is a useful process for the product commercialization once a commercial product is ready.
There were 2 deliverables to be submitted under this WP:
• D5.1 DSS assessment, recommendation and presentation of SpaceNav system
• D5.2 SpaceNav system approval standards and procedures
Both have been submitted on time.
WP6
System installation and integration WP tasks were planned to start on the 7th month of the project and should have been finished month 24. However, the installation process lasted till month 35. The main tasks, which have been performed during the project:
• System installation and integration
• System initial validation
• System evaluation versus requirements
The partners have been working on the plan for the installation and integration of the system on-board of our test ship Color Magic. The installation and integration plan has been in place. The project participants focused on the installation and proceeded. The installation process took much longer than anticipated. The delay was caused mainly due to the various issues we had with the ship data providers and communication with the ship crewmembers. We had to negotiate installation activities with 3 data providers onboard: Sperry, Valmarin, NAPA, where each of the providers required at least 4 weeks period for their service delivery. Installation was successful and finalised during month 35.
The next step was to initially validate the performance of the system. After the system was integrated, calibration and validation exercises were conducted to check that all system parts/components operate nominally. The first tests were conducted jointly with the end-users and the development partners. This is different from the further testing activities of WP 7 and 9 that was performed to basically check the ‘real-life’ sail plan performance; the checks here was simply to validate the IT installation.
There were 3 deliverables for the period:
• D6.1: Installation and integration plan to prepare for the ship installation of the SpaceNav system on vessels (already delivered at Month 18).
• D6.2: Installation and integration of the system on a vessel.
• D6.3: Calibration and validation exercise to check that all system parts/components operate nominally; evaluation of integrated system versus requirements.
All deliverables were submitted on time.
WP7/WP11
The main objective has been the development of the prototypes and technical infrastructure to support the operational SpaceNav system. Main technical output for the SpaceNav activities were the definition, the design and the development of the SpaceNav prototype, which can support the SpaceNav concepts in an operational environment.
The Key SpaceNav infrastructures (developed in WP7) are
• The Onshore Repository Centre (ORC) a scalable multi-processor server architecture, 300Mb/s hub for data integration, long-term and rolling archive and processing centre for the project, derived from Sentinel PDGS, exploited by EMSA traffic monitoring service (operationally supporting +2400 transactions/sec)
• The Offshore Integration Platform (OIP) a system to remotely acquire ship data in realtime - installed on-board ships
• The Graphical User Interface (GUI) designed in collaboration with the consortium, maritime expert and actual end-users.
The ORC System is a fully functional system currently used as semi-operational platform for SpaceNav, hosting the sail plan models and processing the SpaceNav algorithms, ingesting a large number of global coverage data (e.g. weather data) and a significant number of ship-own parameters needed by the various processing modules.
The Offshore Integration Platform is basically a computer installed on-board running a series of custom-developed programs which are responsible for capturing static and real-time information from the various Data Provides on board - e.g. VDR, NAPA, loading computers, e-logs (so-called Data Hubs), and communicate these ship parameters to the ORC on-shore, where the SpaceNav Algorithm Suite (downloaders and route optimizers) process the data.
When the upload conditions are met (e.g. when the minimum required amount of data is captured; and the connection is available; and a pre-defined interval of time has passed) the OIP produces a small footprint Ship Sync Data Packet to be sent to the ORC, normally via a custom configured VPN. Additional data is normally coming from the GUI, capturing the user selection for the sail plan to be optimized or other GUI interactions/settings.
The OIP also provides live ship parameters in real-time to the GUI for visualization (e.g. ship position as reference in the cartography layer; numeric data to be presented to the user, etc.).
The internal OIP data format is normally the format of the source data (e.g. NMEA ASCII Strings, Modbus, etc.) but can be changed to an intermediate or custom SpaceNav format, according to the software requirements.
Activities around the OIP data management included the acquisition of the real-time ship parameters (which is a separate specification for each ship), the ship Virtual Private Network configuration, the configuration of a shared storage on the ship network, the configuration of a FTP Sync between local ship storage and the ORC, and the collection of a selection of data explicitly for the visualization of ship parameters in the GUI (i.e. real-time data not sent to the ORC, but directly sent to the GUI to be visualized on-board).
Making the key parameters available over the test-bed ship local network has been a complex activity, which included solving many external technical problems (e.g. understanding firewall issues and ship network topology) as well as establishing strategic relationships with third party data producers. In general, it concerned understanding what is available over the ship serial network, and how the SpaceNav systems could obtain access to the data. Also the consortium faced issues in interfacing OIP with serial hub ports, incorrect connects, incomplete installations, missing network sockets and many other installation issues, which increased complexity to already complex activities in this work packages.)
To support the development of the data interfaces, the main question was how to extract all the data vital to the algorithms from the existing devices on-board. These activities included also how to move the data from third-party data providers (Data Hubs) to the SpaceNav OIP on-board repository through the ship network, which has peculiar characteristics that make the solution different from the generic infrastructure network of, for example, an office building.
In order to extract the data the OIP supports four main approaches:
• Data Hub has custom procedures that move selected data from local storage to a OIP shared storage
• The OIP can directly read selected data from Data HUB shared storage
• The OIP reads selected data from network socket communication, establishing a real-time bi-directional data exchange
• The OIP reads data from serial ports, when they are available, which normally add to the complexity of a local serial cabling for each device, a necessity when the device requires one way passive data capture (i.e. for safety reason)
During the project development, for each ship, the missing vital data (to the algorithms) from the interfaces had to be clearly highlighted and assessed, more than once during the project lifetime. Other kind of data can be “nice to have” data which could be unavailable without impacting the processing of optimized ship route. Specific programming effort was spent to deal with these cases. In particular the algorithms implement error/warning reporting and error management, specifically around missing vital data from the ship or the web services. This information is kept into the ORC DBMS, and in the OIP in a log file. A selection of this warnings/errors can be displayed on the GUI.
The GUI itself is one of the main consumers of data produced by the ORC. In particular the improved sail plan is sent periodically to the ship, along with key statistics for each waypoints. A low-resolution version of the metocean data used for the processing on-shore can be also sent to the ship if the ship bandwidth supports this type of data.
Particular effort was put into testing the Custom Ingestion Procedures that is offline data and real-time data readers for the last version of models and algorithms. A set of ingestion procedures was tested for relevant satellite EO data, with a clear defined maintenance scheme. Sail plan models and Route Optimisers were integrated including their technical documentation.
The work further related to system evaluation of the SpaceNav system. The main results of the validation of products (models and Earth Observation data) were for three primary parameters (waves, wind and sea surface current) and showed that EO data is essential in order to be able to derive an accurate sail planning system as forecast models have inherent errors and ambiguities that degrade the overall sail planning output.
WP7 and WP11 are successfully completed, with all development and design activities completed in time.
There were 4 deliverables in the WP 7 and 1 in WP11:
• D7.1: ORC System prototype
• D7.2: OIP System prototype
• D7.3: GUI System prototype
• D7.4 Custom Ingestion Procedures for SpaceNav data feeds
• D11.1 Report on the results from the iterative evolutionary evaluation lab runs and potential shortfalls of the tests
All deliverables were submitted on time.
WP8
The system and end-user requirements have generated the industrial designs of the various system modules. These have been integrated and validated against the initial requirements. These industrial designs together with the integrated system and validation reports were the core of the Intellectual Property (IP) developed in the project. Since these modules have been advanced beyond technologies used elsewhere (for other applications) as well as further researched and developed it was important to consider all elements that could forme one or several patent application(s), which in essence is the remaining value of the leading SMEs (and their protection against being replicated by potential competitors). The task was therefore to perform these assessments in order to allocate a pool of IPR (in a separate entity named Offshore Navigation Ltd) that could be utilized as to write and issue well-considered patent application(s). The consortium updated a dedicated IPR register monthly. At the end of the project the IPR register listed all the potential inventions, which were created in the project.
Based on the pool of IPR generated in the previous task, an extended patent search has been performed to clarify the content of a patent application of the project. The consortium drafted one patent application. It has been issued for examination in order to be granted a ‘Space-based maritime navigation and sail plan system’ patent. We collaborated with our patent lawyers for assistance in the patent process. Please note that the patent protection process is expected to continue after the project.
The consortium also has been assessing strategic plans to maximise the investment in the project on regular basis. Risks were listed in form of a risk register document and updated monthly. The risks were being mitigated and resolved on a regular basis.
In the beginning of the project a project’s website was created: ww.spacenav.eu. Moreover a documentation archive based on a cloud solution was created and made available for all partners.
Moreover, a video clip was created presenting the SpaceNav system’s functionality and instructs how to use the current SpaceNav user interface. A workshop had various industry participants to join presentations and discussions of the system in addition to an onboard ship demonstration. The invited entities could see the results of SpaceNav project’s work. Finally the final plan for the use and dissemination of knowledge was prepared and delivered.
There were 6 deliverables submitted:
• D8.1 Draft patent application
• D8.2 Project website for management, communication & dissemination purposes
• D8.3 A short video clip
• D8.4 Final plan for the use and dissemination of knowledge, including conditions for access to background
• D8.5 Workshop on safety sensors for Maritime Purposes; present results at project end
• D8.6 Interim plan for the use and dissemination of knowledge, including conditions for access to background
All have been submitted on time.
WP9
After the development and testing of the SpaceNav sail plan service prototype we needed to consider the roll-out of a commercial sail plan service where the system should be functional at any time with (unlimited) number of vessels. Due to limited time within the project we started the process however it will be continued in a follow up activity (funds are already secured).
After demonstration carried out onboard a vessel the consortium was able to check the system’s performance characterization. Quantities and qualities of the system were confirmed. The operational evidence of fuel, emission and fatigue benefits were listed and included in the prospect for commercial clients.
We were able to collect end-user generated feedback on simple forms of commercial interest that the end-users have been asked to fill-inn at the end of the project. Moreover, for every ship visit (for integration, upgrades or maintenance) the project members had a list with questions that needed to be asked to the end-users during their visits. In other words, there were several means available to receive an honest opinion about the actual end-user perceived pros and cons of the sail planning system. These questions all addressed the end-user perceived operational effectiveness of the integrated system and thereby provided client (market) traction that have been exploited in a commercial context as to define the business case.
A business plan has been generated where we included a market analysis primarily focusing on the high value shipping market (i.e. passenger and energy (gas/oil/chemical tank) transport) and secondarily on the high-end of the secondary shipping market (i.e. container, specialized cargo, RoRo). The business plan also clearly identifies the potential risks of operating the service. For each of these risks the remedial actions have been identified. The business plan contains the need for continuous future R&D in order to continuously improve the performance of the system (e.g. extended sets of validation checks), and in this way keep ahead of the competition. Finally, it contains an assessment of the acceptable unit price for the SpaceNav service. This price is a function of the cost for acquiring satellite and other platform observations in (near) real time. Obviously these costs would be comparably smaller if divided by extended number of customers.
There were 3 deliverables submitted:
• D9.1 Sail plan performance summary
• D9.2 End-user quality statement summary
• D9.3 Business Plan of SpaceNav
All have been submitted on time.
WP10
The main task was to control the various aspects of management of the project, including the maintenance of the consortium agreement and the overall legal, ethical, financial and administrative management.
All the obligations were fulfilled.
There were 4 deliverables submitted:
• D10.1 Report on Gender Aspects
• D10.2 Management summaries based upon progress status sheets provided by the WP and task leaders
• D10.3 12 monthly management and activity reports in conformity with Commission’s guidelines for periodic reporting
• D10.4 Final technical activity report and publishable report
All have been submitted on time.
Potential Impact:
Potential impact
Targeted impacts of the sail plan model are
• 90 % accuracy in ETA (Estimated Time of Arrival)
• 7% savings on fuel consumption (10.5 tons/day for a 4545 TEU container ship)
• 7% savings of CO2, SOx and PM emissions from ships
• 15 % extension of the service life of ships, i.e. from 30 to 34.5 years
• 20% savings with respect to maintenance and inspection costs
Impact on end users and the European Commission
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.
Fuel reduction
Fuel prices for maritime transport are now from 20% up to 60% of total operational vessel costs in yearly averages, but with very significant and unpredictable variations that can cause severe financial impacts to the industry. SpaceNav is achieving a significant fuel reduction in the operation of a ship due to the improved and accurate sail plans that are updated in real time. In effect, a virtual ship-specific IT centre continuously calculates the optimal sail heading and speed for each ship, based on the most up-to-date Earth observation data and numerous numerical models.
Impact: 7% savings on fuel consumption (10.5 tons/day for a 4545 TEU container ship)
Emission reduction
Similarly, the emission of CO2 and other pollutants (such as sulphur dioxides, nitrogen oxides and fine particulate matter) can be reduced, resulting in less pollution along major trade routes and coastal areas. In particular, it allows the ship operator to become aware of the actual ship pollution and thereby provides means to comply with environmental regulations at any given geographical location.
Impact: 7% savings of CO2, SOx and PM emissions from ships
Optimization of ship maintained schedules and asset preservation
The life expectancy 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. Commercial ships are designed for a life expectancy 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. On the other hand, with the appropriate observational data and 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 extend the life expectancy of the ship asset.
Impact: 20% savings with respect to maintenance and inspection costs
Impact: 15 % extension of the service life of ships, i.e. from 30 to 34.5 years
Optimization of sail plan
SpaceNav makes it possible to optimize the sail plan according to operational requirements, such as port slot times, channel passing slots (Suez or Panama channel) and tide schedules (for instance, a VLCC needs 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 their destination due to various risks, in particular uncertainty in the weather forecasts and sea state conditions. This causes large overheads as typically the ship operates at comparably very low speed during the last hours of a journey. With a more accurate sail plan based on real-time weather and sea state observations, time margins can be greatly reduced.
Impact: 90 % accuracy in ETA (Estimated Time of Arrival)
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’s shipping fleet . SpaceNav proposes to strengthen the competitiveness of this significant European shipping trade by:
• Improving operational efficiency with respect to functionality, 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).
Expected environmental savings
The example of the container carrier (cf. Ch 4.1.2) with respect to the potential CO2 emission savings, SpaceNav is expected to achieve savings of 8,353t CO2 per year. When the IPCC scenario becomes reality, this reduction would compare to an $816,667 saving per ship p.a (using the IPCC reference numbers for the calculations).
Partners revenue
The partners will have the potential to gain revenues after the project from two main revenue streams:
1. The monthly subscription fees from its core optimization services such as
a. Fuel Optimizer
b. Emission Optimizer
c. Asset preservation/Passenger Comfort Optimization
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 to collect valuable journey data as to continuously improving the quality of the service, the Fuel Optimizer will be marketed as a free service during the 1st year of a subscription service.
Main dissemination activities
Website
At the start of the project a public website was setup and maintained during the project as the communication channel towards the general public and targeted public, cf. www.spacenav.eu. The web-site www.OffshoreNavigation.com will be used for further commercialisation activities.
Publications
A total of 10 publications were done, including oral presentations at several conferences.
Conferences/Workshops/Demonstrations
Dedicated workshops were organized, mainly with the project partners and several external technical persons.
At the end, there was a dedicated demonstration organized for end-users. This was held onboard of Color Magic during an Oslo-Kiel-Oslo voyage.
Main exploitable results
ONL
All exploitable results are owned by the project’s spin-off company Offshore Navigation Limited (ONL), please see www.OffshoreNavigation.com
List of Websites:
Website
The project public website has been set up for the general public and can be found at the web address: www.spacenav.eu The website provides general information on the project objectives and the work performed as well as details of the project partners, and contact details for the project coordinator. The website will be accessible for some years after the project is closed.
Contact persons
The Coordinator
Offshore Monitoring Ltd
26 Nikou Pattichi, 3071 Limassol, Cyprus
Contact person:
Dr. Sverre Dokken
Telephone: +357 250 30 500
Email: info@offshoremonitoring.com