1. INTRODUCTION
Maritime accidents bring enormous life and economic losses; therefore, determining how to effectively avoid them and create a good maritime navigation environment is of international interest. According to statistics (Acejo et al., Reference Acejo, Sampson, Turgo, Ellis and Tang2018), the most common kind of accident was identified as collision, close quarters and contact (35·8%). This was followed by grounding, which constituted 17% of the cases. The most common causes of accidents were found to be the maintenance of inadequate lookout, communication failure, ineffective/inappropriate use of technology and weather/other environmental factors. Humans, technology and the environment are the three main factors that cause accidents. In other words, if mariners have enough time to observe their surroundings rather than performing other jobs (such as correcting charts or publications) and are informed of the dynamic marine environment in a timely way through effective and appropriate technology, the accident rate could be decreased.
Generally, navigators obtain maritime traffic information in two main ways. The first is by using shipborne equipment to obtain information about a ship's surroundings (Zhang et al., Reference Zhang and Feng2017). The second way is through paper-based and digital nautical publications and maritime safety information (MSI) broadcast by maritime offices. The ability of ships to obtain information through these ways represents a great improvement compared with the era of having to rely solely on paper-based nautical materials. However, with the rapid development of the global marine economy, maritime traffic has become increasingly busy, and the requirements for maritime traffic information have gradually changed: information must be digital, multi-source, dynamic, real-time, standardised, integrated and on-demand. However, as in the case of the core navigation equipment on the ship used to process and display navigation information, most electronic chart display and information systems (ECDISs) still deal only with electronic navigational chart (ENC) data (Hecht, Reference Hecht2006) and cannot therefore meet the aforementioned requirements. Maritime offices also need to improve traditional service methods to provide more types of information.
International organisations related to navigation security are the main research force in this field. As ENCs cannot fully realise the potential of ECDIS to provide a wide variety of nautical information, marine information overlay (MIO) was put forward by the International Hydrographic Organization (IHO) (Alexander et al., Reference Alexander, Brown, Greenslade and Greenslade2007) as a way to describe chart and navigation-related information to supplement the minimum information contained in the IHO S-57 ENC product specification (IHO, 2007). MIO is not a part of the ENC;it is additional information that overlays the ENC. MIOs can be divided into two categories: static and dynamic. A static MIO is relatively fixed or constant information that is not subject to frequent or continual change, which includes information on marine habitats, seafloor characteristics, or regulated marine protected areas. Dynamic MIOs are more temporal and deal with real-time data that have instantaneous value or are constantly changing. Examples of dynamic MIOs include tide/water levels, current flow, and weather information that are continually being updated. However, these two categories are not mutually exclusive, and there can be a combination of predicted, forecast and so-called nowcast information (i.e. a forecast that is continually being updated). MIOs can be broadcast as Automatic Identification System (AIS) Application Specific Messages (ASMs) or provided via the Internet (Alexander and McLeay, Reference Alexander and McLeay2015).
While several demonstration projects have shown that providing additional information as MIOs is technically feasible, MIO has not been promoted in practical applications. The main reason is that although MIO solves the problem of the comprehensive display of static and dynamic navigation-related information in ECDIS, it fails to establish an effective operational infrastructure. The standard (S-57) used to model and produce ENC and MIO is not an internationally recognised Geographic Information System (GIS) standard; it has certain limitations, such as not supporting gridded bathymetry or time-varying information, and is regarded as a limited standard focused exclusively on the production and exchange of ENC data (Astle and Schwarzberg, Reference Astle and Schwarzberg2013).
To break through the limitations of S-57 and provide a unified theoretical and applied framework for modelling, encoding, visualising and exchanging marine geographical information, the IHO issued the Universal Hydrographic Data Model (S-100) in 2010, which was updated to the 4th edition in 2018 (IHO, 2018a, 2018b, 2018c). The primary goal for S-100 is to support a greater variety of navigation-related digital data sources, products and customers. This includes matrix and raster data, 3-D and time-varying data (x, y, z, and time), and new applications that go beyond the scope of traditional hydrography (e.g. high-density bathymetry, seafloor classification, and marine GIS). It also enables the use of web-based services for acquiring, processing, analysing, accessing and presenting data. S-100 is an entirely new standard that includes both additional content and support for new data exchange formats (Alexander and Huet, Reference Alexander and Huet2007. p. 82).
Given its compatibility with ISO/TC 211 geographic information standard, S-100 can be used to produce different kinds of GIS-type navigational products; it is similar to MIO in terms of function but stronger and more standardised. These products are called S-100 data products and include S-101 ENC, S-102 Bathymetric Surface, S-103 Sub-Surface Navigation, S-104 Water Level Information for Surface Navigation and S-111 Surface Currents. With the support of S-100, ENC and related-navigation information become dynamic, and all the products can overlay on the ENC in a unified manner in ECDIS by conforming to the IHO S-98 standard (IHO, 2018a, 2018b, 2018c). The S-100 data product specifications are currently under development and testing and are anticipated to be in official use as early as 2020 (IHO, 2015).
In addition to data standards, system architecture is an important aspect of information exchange. The idea of developing the e-navigation strategy was put forward in 2006 by the International Maritime Organization (IMO) and was defined as ‘the harmonised collection, integration, exchange, presentation and analysis of marine information on board and ashore by electronic means to enhance berth to berth navigation and related services for safety and security at sea and protection of the marine environment.’ E-navigation is intended to meet user needs through the harmonisation of marine navigation systems and supporting shore services (Tsimplis and Papadas, Reference Tsimplis and Papadas2019). The IMO designed a common technical architecture for e-navigation, which links the ships, maritime authorities, environment, humans, standards and technology together (IMO, 2009) and provides an operational infrastructure for information exchange between ships and shore.
The International Association of Marine Aids to Navigation and Lighthouse Authorities (IALA) is in charge of the technical aspect of e-navigation. Most of the new technologies and system functions in e-navigation are proposed by the testbeds registered in IALA. Because the testbeds are not limited or restricted by the current architecture, data structures or procedures (IALA, 2019), any ideas are encouraged for testing, and some of these ideas have been applied.
Service is one of the pillars of e-navigation. The IMO defines 16 types of services that shore may provide to users, called Maritime Service Portfolios (MSPs) (IMO, 2009). In addition, IALA proposes the Maritime Cloud (MC) to establish a service registration mechanism. As long as it conforms to the technical service specifications (IALA, 2017), every user in the MC can provide technical services. MSPs and technical services are two different levels: the former is the framework, and the latter is the specific service.
All information exchanged in e-navigation is structured by a common maritime data structure (CMDS). As the IMO has adopted the S-100 as the basis of the CMDS and with the online communication exchange part added to S-100, S-100 can be used as the specification to model, encode and exchange MSPs. S-100 data products can be provided via MSPs in the form of a service.
The works above have greatly improved the level of navigation; however, there is still room for improvement. From the perspective of GIS, maritime navigational information is GIS-type data. It is therefore feasible to use mature GIS technology in maritime navigation to supplement existing navigational methods and enrich navigational information. In this paper, we present a testbed developed under e-navigation technical architecture, which consists of a service operational architecture, multiple subsystems, service specifications and data collection methods. The primary goal is to propose a reusable application model of geographic information services (GI services) (Liu, Reference Liu2004) in e-navigation to enrich the content of navigational services and facilitate the delivery of digital navigational information to improve the safety and efficiency of navigation.
2. E-NAVIGATION GI SERVICES TESTBED CONSTRUCTION
2.1. GI services operational architecture
We first designed an operational architecture for maritime GI services under e-navigation technical architecture. The architecture consists of six parts: a shore-based GI services publishing platform, GI services, terminal systems, communication networks, portal, and data collection methods, as Figure 1 shows.
Figure 1. Maritime GI Services Operational Architecture.
The shore-based GI services publishing platform is the core of this testbed. The platform is responsible for the following:
(1) Manage and maintain the databases (DBs).
(2) Maintain the service specifications.
(3) Respond to service requests and publish the subscribed service.
(4) Maintain the external application programming interface (API).
(5) Monitor the location of the registered ships and the navigation environment on the planned route to give advice or warnings to ships in a timely manner.
The GI services consist of six major categories (see Section 2.3). These services cover most of the information ships may need during navigation.
The terminal systems are composed of the shipboard ECDIS, and mobile and personal computer (PC) devices. ECDIS can request and subscribe to the service from a shore-based platform through communication networks (3G, 4G, WIFI, AIS ASM) and display the service information in a single window. The mobile device has the basic functions of ECDIS and can use its own positioning and navigation module to navigate autonomously. PCs provide users with the ability to simulate the GI services and monitor interested ships in real time using WebGIS technology.
The portal is a website system where users can log in and maintain personal information; it also provides service specifications and an introduction to the testbed and administrator entries. Moreover, the portal is used for subscription services, API maintenance and WebGIS connections.
Data collection methods are used to gather the necessary data and generate GI services. The methods include surveying and mapping, observation, GIS spatial analysis, third-party APIs (e.g. meteorological bureau and port authority APIs), AIS stations, volunteer geographic information (VGI) and notices to mariners (NtM) issued by maritime agencies. VGI data in particular, (Li and Qian, Reference Li and Qian2010) come directly from navigators. As navigators encounter the latest maritime traffic conditions and natural and human-made emergencies during navigation they can upload the information through ECDIS or a mobile platform. This process is similar to the road condition reporting function in land navigation software.
2.2. Database design
The testbed mainly covers four types of DBs, namely, the register DB, time-varying DB, knowledge DB and service DB. The register DB stores the data that users register on the portal, including information about the user, authorisation and ship. The authorisation information is used to identify the user's licence when they request services. The time-varying DB stores the data obtained from observation (hydrological and weather observation), facility APIs, VGI and AIS stations. These data are dynamic, in raw format and need to be converted to the standard encoding format before being delivered to users via a service. The knowledge DB is a spatial database that is used to support decision making in navigation. Knowledge data include predefined ship routes, COLREGS (International Regulations for Preventing Collisions at Sea) and traffic rules. The service DB is the container of all the service data.
2.3. Service classification
We classified the services into six elements: MSI service, intelligent route service, anti-collision warning service, ship information service, traffic rules service and digital publication service. To improve the accuracy and pertinency of these services, more subtypes were identified, as shown in Table 1.
Table 1. Geo-information services and the data sources.
2.4. Service implementation
2.4.1. Service specifications
GI service is a data service that requires specifications to define the usage, data structure, data exchange protocol and encoding format. In this study, the specification of each service was based on the IALA technical service specification and S-100. These specifications are the languages that allow shore-based platform and service terminal systems to recognise each other's information. Service specifications are developed before the platform and terminal systems so that the platform and terminal systems can simultaneously realise their respective functions without having to wait for the completion of the platform before starting development of the terminal systems. Because the terminal systems know what will be sent to them by the platform, much development time is saved.
Whether a navigator, a developer or a third-party user, people area able understand the purpose and use of each service. A logical data structure is defined by using Unified Modelling Language class diagrams and explanatory tables, and the encoding formats are defined by JSON and XML. REST (Representational State Transfer) and MQTT (Message Queuing Telemetry Transport) are used for the GI service network exchange protocol to support the service broadcast, request/response and subscribe/publish. The three methods allow the platform to deliver services based on navigator demand, which may avoid unnecessary/redundant information (namely spam) (Crawford et al., Reference Crawford, Bate and Cherbakov2010).
2.4.2. Algorithm for the intelligent route service
The intelligent route service in this testbed is a typical GIS issue for searching the optimal path (Tang et al., Reference Tang, Tang and Cui2015). In this study, we used the preprocessed A* algorithm to calculate and generate the recommended route. The A* algorithm, a heuristic search method, is one of the most effective means of searching the shortest path (Qian et al., Reference Qian, Ge and Zhong2014). The basic principle of the heuristic search method is as follows. For each new node encountered in the search process, calculate its estimated cost value according to the heuristic function first. Then select the node with the smallest estimated value at that time, and continue to search from this state. The heuristic function is expressed as shown in Equation (1).
$$f(n)=g(n)+h(n)$$where f(n) is the estimated cost from the initial state via state n to the target state, g(n) is the actual cost in the state space from the initial state to state n, and h(n) is the estimated cost of the best path from state n to the target state.
Prior to the implementation of the A* algorithm, we used GIS tools to draw as many routes as possible for the testing area and established a route library together with the AIS historical track data (stored in the knowledge DB). This helps reduce the calculation time and improve the accuracy (Yang, Reference Yang2015). We subsequently formulated the following rules for the algorithm:
(1) multiple static and dynamic parameters are considered first, including the ship conditions (length, width, maximum draft, right-side safety distance, height clearance, ship type or cargo type), port handling capacity, NtM, MSI information (meteorological, oceanographic and hydrological parameters) and the rules of the road;
(2) if there are predefined routes between the start berth and end berth, the routes are preferred and then adjusted by the above parameters;
(3) if there are no predefined routes, the A* algorithm is used to find the shortest route and adjust the route by the parameters;
(4) obstructions (reef, wreck, obstacles, etc.), shallow water areas (insufficient draught) in the ENC and information that may threaten the safety of the ship are considered to be ‘walls’ in the route, requiring a detour;
(5) when a ship needs to turn (angle greater than 10°), sheer off or arrives at the destination, the track point should be automatically generated on the recommended route, and the estimated arrival time should be calculated based on the speed and marked below the track point;
(6) the recommended route should comply with the navigation rules of the ports and channels, such as the circular traffic zone, one-way channel, or two-way channel; and
(7) each recommended route generated is recorded in the knowledge DB so that when the ship conditions and parameters match the record, the route can be used directly with little adjustment.
2.5. Improved ECDIS
2.5.1. Additional functions
To address the service data, additional functions were added to the existing ECDIS, including the following:
(1) fully in compliance with the service specifications;
(2) a service operation user interface to request and subscribe services;
(3) additional rules and symbols for displaying the service information;
(4) AIS ASM, 3G, 4G and WIFI network modules that are integrated to exchange information in real time; and
(5) integration of the Beidou Navigation System module to better obtain positioning, navigation and timing information in China (Zhu et al., Reference Zhu, Feng, Jia, Zhang and Ruan2015).
According to the IMO (IMO, 1995) and IEC (IEC, 2015) standards for ECDIS, other navigational information (in addition to the ENC) may be added to the ECDIS display. However, the information must not degrade the displayed SENC (System ENC) information, and it must be clearly distinguishable from the SENC information. This rule is the basic guideline for the process and display of GI service information. To achieve this, the functions of transparency setting for service data symbols and switching on/off for display are added to the ECDIS.
2.5.2. Security measure
When users request or subscribe to services, the platform will first verify the user's identity and the authorisation message. We propose an easy way to achieve this, in which an API key is automatically generated and sent as a parameter to the platform when users request or subscribe to the services.
The API key is a character string, which is calculated based on the Advanced Encryption Standard (AES) 128-bit algorithm. To generate the API key, the terminal type (WebGIS: 1, App: 2, ECDIS: 3, PC: 4), user name and password are encrypted with the secret key. Users do not need to fill in these parameters, and ECDIS can extract the information automatically. For example,
The parameters:
{‘username’:‘superadmin’,‘password’:‘12345678’,‘usertype’:‘2’} with
The secret key:
{enavpre123456789} will generate
The 128-bit API key:
{2142364550fdcc1519ab0cdf31495f3d9b7336c38ed4ecfc42454ab3d10fd59 bfcc06ea7ee7a37f5db527274e5b06f47cfe3ce4f78717132d53d766a9d71f595}
The platform will then verify the API key and query the user's authorisation information. If the verification is successful, then the service data will return to the client.
2.5.3. Operational procedures of service delivery
Service broadcast, request/response and subscribe/publish are three methods to deliver a service. For broadcasts, any information that is considered a threat to ships, such as MSI information and anti-collision warnings, will be sent to terminal systems. The working mechanism is the same as that of NAVTEX, but the system delivers the information in a digital manner and displays it graphically based on the location in ECDIS. The workflow is shown in Figure 2.
Figure 2. The workflow of the broadcast-type service.
For request/response, navigators can ask for help whenever needed, for example, to request route plans and digital publication services. Request/response-type services use the REST protocol to exchange information. The workflow is shown in Figure 3. To request a service, the parameters need to be filled in first. While some of the parameters, such as ship type, MMSI (Maritime Mobile Service Identify) and location, are automatically obtained from the database, others that cannot be automatically generated may be manually filled out in the interface by users. The API key is a mandatory parameter when requesting a service. When the platform receives the request and confirms the user's identity, it will respond to the request with a state code (200: success, 208: fail, 355: interface closed, 400: bad request, 401: unauthorised, 404: service not found, 500: server error) and provide the service data in the predefined format (XML or JSON).
Figure 3. The workflow of the request/response-type service.
For subscribe/publish, navigators can decide which services to subscribe to, based on the route plans or ship conditions, such as MSI information and traffic rules. Subscribe/publish-type services use the MQTT protocol to establish a long-term connection between the ECDIS and the platform. The platform monitors the ship location/route plan and the surrounding environment in real time; when the conditions are triggered, the subscribed service will be sent to the users. The workflow is shown in Figure 4.
Figure 4. The workflow of the subscribe/publish-type service.
3. EXPERIMENTS AND RESULTS
We conducted experiments in the Pearl River Estuary area of the South China Sea. This experiment mainly focused on the ship-shore service information exchange and the display effect.
Figure 5 shows the experimental result of the MSI service. We moored our ship in the area (an anchor symbol in the figure) and then followed the left channel through the upper bridge (grey parallel line) to the destination. When the trip began, we received NtM information, which was prompted by ECDIS. A red area marked as MSI displayed in ECDIS, as Figure 5(a) shows, and the information indicated that there was a trial with a new ship in the area, as shown in Figure 5(b). When passing through this area, ships should open AIS and VHF 16 channels to listen to the related information and pay attention to lookout and avoidance warnings.
Figure 5. MSI service experimental result: (a) MSI area indication and (b) MSI description.
Figure 6 shows the simulation test results for the recommended route plan service. The starting point is in Dachan waterway (coordinate: E113°45′2′′, N22°41′10′′) and the destination is Xiaochenpai (coordinate: E113°48′47′′, N22°36′36′′). We requested the recommended route plan service from the platform through ECDIS. The ship parameters were set as follows:
maximum draft: 1 m,
clearance height: 8 m,
left-side safety distance: 2 m, and
right-side safety distance: 2 m.
Figure 6. Recommended route plan service experimental result.
The platform responded to the request; the returned recommended route plan is shown in Figure 6. The solid lines in the figure represent the safety distances on the left and right sides of the ship, and the dotted line represents the actual route, where WP_X denotes the track points of the route. The estimated arrival time (ETA) at a track point is updated every 20 s based on the ship speed.
Figure 7 shows the experimental results of the route check service. First, we made a route plan on ECDIS. Then, we sent the route plan (a collection of track points) to the platform through the route check service. Fifteen seconds later, the platform returned the result. The ellipse represents MSI information, and the red cross within the ellipse in Figure 7 represents a problem with the route plan. By clicking the MSI symbol to query the information, we learned that shipwreck salvaging and clearing operations were being performed there and that other ships had to avoid the area. Because the route crosses this area, a problem arose.
Figure 7. Route check service experimental result.
Figure 8 shows the experimental result of the traffic rules service. The experiment was performed based on simulations to rapidly locate the ship in the test area and obtain the display effect of multiple rules at one time. As Figure 8 shows, the ship was in the denoted circular traffic zone. The red-filled zone is the restricted access area, and the green zones represent the permitted access areas. When the ship was within 0·5 nautical miles of the restricted access area, ECDIS prompted a warning message, informing us that the front channel was the route that should be used to access Guangzhou Port. Additionally, we needed to ensure that we met the requirements to enter the port.
Figure 8. Traffic rules service test result.
4. CONCLUSION
Failure to obtain ever-changing maritime environmental information in a timely manner may lead to maritime accidents. Because ENC, PNC and nautical publications cannot supply the latest maritime information and must be corrected manually, we proposed the application of GI service technology in maritime navigation to provide navigators with dynamic maritime information in real time. This work presents a reusable applied model of GIS with an e-navigation technical architecture. The specific content of this paper can be summarised as follows:
(1) design and implement the SOA GI service operational architecture;
(2) improve the software aspect of ECDIS under the premise of complying with IMO and IEC ECDIS standards;
(3) develop multiple service specifications based on S-100 to support the simultaneous development of on-board and ashore systems;
(4) develop a shore-based GI service publishing platform and the corresponding terminal subsystems;
(5) diversify the service data collection methods; and
(6) design and use the preprocessed A* algorithm to automatically generate a route plan in which multiple static and dynamic parameters are taken into consideration.
Based on the proposed architecture and systems, ships are connected to land-based systems. Thus, when ships request navigational services or trigger service publication conditions, services can be sent to and appropriately displayed in ECDIS. In this way, mariners can detect potential risks earlier than by using radar or other equipment. All the information exchanged is digital and up to date, which helps to simplify the mariners' work and provides more decision references to avoid risks.
This involved an e-navigation testbed. The main idea was to apply GIS theory and technology to maritime navigation and provide navigational information based on location in real time. However, maritime navigation is an international issue, and many standards and conventions must be considered. Although the work was conducted on the basis of compliance with international standards as much as possible, limitations still exist. Because S-100 product specifications and ECDIS performance standards must be revised and tested, the requirements for ECDIS and ship-shore interactive mode are uncertain. Additionally, simple security measures cannot thoroughly solve the cyber security problem, and spoofing and jamming may arise in the data exchange process. Furthermore, the algorithm to generate the recommended route does not take all factors into account and still has defects. Future research will focus on improving the identification, data collection, cyber security, algorithm and data standardisation methods, as well as the ECDIS platform.
ACKNOWLEDGMENTS
The research was financially supported by the China Maritime Safety Administration Navigation Guarantee Special Project Plan (Grant Nos. 2016-10, 2016-27 and 2018-22).
