The Korean Society of Marine Engineering
[ Original Paper ]
Journal of the Korean Society of Marine Engineering - Vol. 39, No. 10, pp.1049-1053
ISSN: 2234-7925 (Print) 2234-8352 (Online)
Print publication date Dec 2015
Received 19 Nov 2015 Revised 14 Dec 2015 Accepted 21 Dec 2015
DOI: https://doi.org/10.5916/jkosme.2015.39.10.1049

Justification on engine information in maritime service portfolio for effective implementation of e-Navigation

Young-Chan Lee1 ; Myeong-Bo Sim2 ; Woo-Ram Hong3 ; Jae-Yeong Lee4 ; Byung-Gun Jung
1Division of Marine Information Technology, Korea Maritime and Ocean University, Tel: 051-410-4661 yclee@kmou.ac.kr
2Department of Marine System Engineering, Graduate School, Korea Maritime and Ocean University simsabuwin@empal.com
3Department of Marine System Engineering, Korea Maritime and Ocean University dnfka2rk@naver
4Department of Marine System Engineering, Korea Maritime and Ocean University su789456@naver.com

Correspondence to: Division of Marine System Engineering, Korea Maritime and Ocean University, 727, Taejong-ro, Yeongdo-gu, Busan, 49112, Korea, E-mail: bgjung@kmou.ac.kr, Tel: 051-410-4269

Copyright © The Korean Society of Marine Engineering
This is an Open Access article distributed under the terms of the Creative Commons Attribution Non-Commercial License (http://creativecommons.org/licenses/by-nc/3.0), which permits unrestricted non-commercial use, distribution, and reproduction in any medium, provided the original work is properly cited

Abstract

This paper proposes to include engine information in Maritime Service Portfolio (MSP) for effective implementation of e-Navigation. Even though engine information is one of most important element to e-Navigation, MSP consists of mainly about navigation and communication information not included engine information. Furthermore, in reality, engine information sent from ship side such as mainly noon report and Planned Maintenance System (PMS) is too limited to make e-Navigation possibly. Therefore, Remote diagnostic structure receiving and sending data of engine information must be included in MSP for implementation of e -Navigation. Also, it has to be designed, and developed by Software Quality Assurance (SQA).

Keywords:

e-Navigation, Maritime service portfolio, Engine information, Software quality assurance

1. Introduction

The e-Navigation has been approved at MSC 81 as new work program by Japan, Marshall islands, Netherlands, Norway, Singapore, United Kingdom, United State of America, etc after proposal about necessity of instituting e-Navigation by minister of transport in United Kingdom in November 2005, to complete SIP until 2014 and announced e-Navigation strategic implementation plan as shown in Figure 1[1][2].

Figure 1:

Strategic Implementation Plan [1][2]

In accordance with e-Navigation implementation plan, IMO already has finished analysis about needs of users in 2009, gap analysis and solutions in 2012, risk control option in 2013, and completed implementation plans in 2014 and accepted by MSC [2]. IMO defines that e-Navigation is the harmonized collection, integration, exchange 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.

In July 2014, at the first NCSR sub-committee in London, IMO has discussed about e-Navigation implementation plan report, and Strategic Implementation Plan (SIP) has been on the table and accepted by MSC 94 in December 2014. The e-Navigation SIP has been accepted at MSC 94, defined 5 solutions and 18 tasks [3][4].

·Solution 1 : Improved, harmonized and user-friendly bridge des sign;
·Solution 2 : Means for standardized and automated reporting;
·Solution 3 : Improved reliability, resilience and integrity of bridge equipment and navigation information;
·Solution 4 : Integration and presentation of available information in graphical displays received via communication equipment; and
·Solution 9 : Improved communication of VTS Service Portfolio

At MSC 94, 4 guidelines (Human centered design, Usability testing, Software quality assurance, Test beds) have been approved. And there were proposals to integrate 3 guidelines except test beds, therefore it has decided to make communication working group to proceed integration procedure [5][6] as shown in Figure 2.

Figure 2:

Concept of e-Navigation [4]

Recently at 16th IALA’s e-NAV committee in April 2015, there was definition of common shore-based system having been carrying out mainly by Germany. Common Maritime Data Structure (CMDS) has basic function and structure of common shore-based system as given in Figure 3[7]. And each factor’s function of common shore-based system is shown as following,

Figure 3:

Concept of common shore-based system [7]

· Gathering and transferring of information service: Through physical links, providing electrical system of ship, traffic objects including ships, interspace between lane & natural environment and shore-based system
· Information handling service for added value service: Through handling, combination, comparing of source data, it makes the value of data up and gives it when other services want
· Intercommunication of users service: Giving interspace between people and machine to main user of common shore-based system
· Gateway service: Providing exchange of data between different system of shore services

2. Remote Diagnostic System and Software Quality Assurance

The remote diagnostics system (RDS) is built with so-called ‘diagnostics objects’ that are engineered to monitor certain physical assets in the power and propulsion chain. And these diagnostics objects are designed to record all needed information related to provide the best fault-tracing, trouble shooting and condition-related information to the operator on board and at the RDS center. By applying this system at ship , RDS can achieve more safe, secure, and efficient voyage of ship. There are 4 kinds of RDS in these days. RDS4Marine by ABB, Predix by GE, VALMarine by Wartsila, Primeserv by MAN Diesel & Turbo. And followings are benefits from RDS as shown in Figure 4.

Figure 4:

Overview of Remote Diagnostics System [8]

· RDS reduces the repair time of installations, hence improving the availability and safety of operations
· Reduced need for on-site visit by providing remote access to the installed base and control system
· Advanced diagnostic functionality simplifies the fault-finding process and reduces the time to identify and fix the problem
· It seems like Engine maker’s service engineer is always on board
· Enabling preventive maintenance, which detects potential issues before they escalate, degrade performance or cause system failure
· Rectifying single components failures as quick as possible
· Providing immediate assistance in critical situations from 24/7 global technical center

And RDS will be needed to design and develop in accordance with Software Quality Assurance (SQA) guideline. SQA is a set of processes that ensures software meets and complies with required quality specifications as given in Figure 5[9].

Figure 5:

Concept of SQA [9]

To make e-Navigation possible, there must need ‘Maritime Cloud’. Maritime cloud is proposed as one of most important thing for communicating infrastructure by Republic of Korea, Sweden, and Denmark. And it has these 3 basic components and its functions as followings [10].

Figure 6:

Structure of Maritime Cloud [10]

· Maritime Identity Registry : Certificates in a public key-infrastructure that enable secure data communication with other maritime stakeholder over any communication channel
· Maritime Service Portfolio Registry : It is a centralized registry that contains service specifications according to an envisioned service specification standard and provisioned service instances implemented according to a service specification. The service registry aims at improving the visibility and accessibility of available maritime information and services. This enables service providers, consumers, and regulatory authorities to share a common view on service standards and provisioned services
· Maritime Messaging Server : The maritime messaging service within the maritime cloud are intended to ensure seamless information transfer across different communication links in a carrier agnostic manner

3. Observation

Until now, only limited part of engine information was transferred to shore by reporting noon report everyday and PMS per several weeks. But to make RDS possible, there must be sufficient engine information. Without sufficient engine information, experts at shore side could not diagnose the condition of the engine or other machinery. To avoid serious accident like main engine shut down, slow down, etc all kinds of engine information must be needed to deal with these accidents can occur problem of safe, secure and efficient voyage.

Figure 7:

Insufficient engine information by noon report and PMS [11]

Figure 7-1:

Insufficient engine information by noon report and PMS [11]


4. Conclusion

Engine information must have to be included to MSP that is standardized and common structure to provide seamless data transfer [12].

Even though, MSP is one of most important thing in e-Navigation, there is no engine information in MSP. To prevent emergency accident, and solve as soon as possible, sufficient engine information must be needed. In order to fulfill SIP 2 (Means for standardized and automated reporting), RDS is the best way to collect of internal- ship for operating including static and dynamic position [13]. At least, engine safety information is really important and necessary to deal with main engine slow down or shut down, following are causes of slow down and shut down.

● Causes of shut down
- Engine over speed
- Main and thrust bearing too low oil pressure
- Thrust bearing high temperature
● Causes of slow down
- High temperature of
a) Lube oil inlet
b) Piston cooling oil
c) Main and thrust bearing
d) Cooling water inlet
e) Scavenge air
f) Exhaust gas
- Low pressure of
a) Piston cooling oil
b) Main and thrust bearing oil
- High oil mist

These are only just part of main engine, and there are more engine information related to generator, auxiliary boiler, system of fuel oil, lubricating oil, cooling water, and other machinery.

The RDS receiving and sending data of engine information must be included in MSP for implementation of e-Navigation. Also, it has to be designed, and developed by Software Quality Assurance [14].

The Ship Ad-hoc NETwork (SANET) is a new possibility to realize remote diagnostic system in near future. In addition, the SANET can be utilized as a common communication infrastructure of various maritime services which provides ships with facilitation and security as well [15].

Figure 8:

Concept of SANET [15]

One research institute in Korea have been developing the SANET in order to enhance the efficiency of maritime logistics by consistently keeping track of them. To do this, the service charging of current satellite communication system like Inmarsat is so high to frequently check the status of maritime logistics. After interviewing the experts in shipping companies, we found that there are enough ships to make an ad-hoc ship by ship communication link; this is the motivation of the SANET. So, using the device can be more frequently checked the status of maritime logistics under its infrastructure with low cost as much as domestic Internet service charging.

References

Figure 1:

Figure 1:
Strategic Implementation Plan [1][2]

Figure 2:

Figure 2:
Concept of e-Navigation [4]

Figure 3:

Figure 3:
Concept of common shore-based system [7]

Figure 4:

Figure 4:
Overview of Remote Diagnostics System [8]

Figure 5:

Figure 5:
Concept of SQA [9]

Figure 6:

Figure 6:
Structure of Maritime Cloud [10]

Figure 7:

Figure 7:
Insufficient engine information by noon report and PMS [11]

Figure 7-1:

Figure 7-1:
Insufficient engine information by noon report and PMS [11]

Figure 8:

Figure 8:
Concept of SANET [15]