E-Navigation Architecture Overview and Functional Connection Analysis Pregled arhitekture e-navigacije i analiza njezine funkcionalne

Although International Association of Marine Aids to Navigation and Lighthouse Authorities (IALA) and International Maritime Organization (IMO) have published a large number of manuals, reports, guidelines and recommendations concerning the e-Navigation architecture concept, additional clarifi cation and the improvement regarding functional connections can still be achieved if the architecture is observed in the context of new Information and Communication Technology (ICT). This paper synthesizes the previous research and offi cial relevant documents related to the e-Navigation architecture. By combining the existing scientifi c literature and various offi cial documents published by organizations such as IMO, IALA, and International Hydrographic Organization (IHO), the paper provides an analysis of the existing e-Navigation architecture, as well as the concepts for future e-Navigation architecture regarding the ICT technologies. Special attention is given to the functional connections and data/information fl ow within the e-Navigation architecture. In the context of emerging ICT technologies, certain recommendations regarding e-Navigation architecture are provided.


INTRODUCTION / Uvod
In maritime technology there is a tendency to take advantage of the latest technological achievements in the fi eld of automation, electronics, telecommunications, information technology, telematics, geomatics, global navigation systems, and enhancements in storage, processing, analysis, transfer and visualization of data [1].Using the latest technologies is a key part of e-Navigation concept.E-Navigation is the leading and currently most popular concept of the IMO, and it is based on harmonization of marine navigation systems and supporting shore-based services with user needs which are the main driver of the development of this concept [2].E-Navigation is defi ned as "harmonized 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" [3].In other words, the main goal of e-Navigation is to increase the safety of navigation while reducing the burden of seafarers by increasing the compliance of all systems involved in navigation process.E-Navigation is currently a rather abstract concept since it is still diffi cult to determine the full range of changes that need to be made in order to achieve the main goal of e-Navigation.Some of the interesting statements are: -The Committee on the Marine Transportation System (CMTS) noted that the focus of e-Navigation is neither technical equipment nor technical systems, but integration of information [4].-E-Navigation has the mission to properly use and integrate the existing and new technologies to enhance navigation safety with commercial effi ciency [5].Developing a strategy that would enable this integration represents a real challenge for the industry.The cleverly designed strategy is in fact a prerequisite for the development of specifi c systems that would meet the needs of e-Navigation.One of the key and indispensable elements for the development of this strategy is the e-Navigation architecture.IMO recognized the need to design and maintain the general conceptual, functional and technical architecture of e-Navigation in 2008, particularly in terms of description of the process, structure information, information systems, and communication technologies and regulations related to e-Navigation [3].The goal of this paper is to explain and give insight into the existing state of the e-Navigation architecture, as well as to highlight the architecture course of development and to propose certain recommendations regarding future e-Navigation architecture.

E-NAVIGATION ARCHITECTURE / Arhitektura e-navigacije
The importance of e-Navigation architecture is also refl ected through the adopted e-Navigation implementation strategic process in which it takes a signifi cant place [3].The document [3] identifi es the following: the defi nition of integrated e-Navigation architecture and the concept of operations should be based on overarching and unifi ed customer needs while simultaneously taking into account all economic dimensions.It is also emphasized that architecture should include hardware, data, information, communications, and needed software in order to meet the user needs.Architecture is a guide in the e-Navigation development process, and it can be improved over time.E-Navigation architecture is considered to have two basic purposes [6]: 1. Ensure a generally accepted understanding and interpretation of the e-Navigation concept.Although the general defi nition of e-Navigation is specifi ed in documents [3] and [6], there is a need for a more detailed defi nition.
The defi nition should be sustainable, i.e. stable for as long as possible, and independent of technology, technical components and systems (which can be changed over time).Such a defi nition should further clarify: -The e-Navigation context, i.e. the main aspects, scope and environment of e-Navigation, and the obligations and responsibilities that must be executed by stakeholders.-Logical description of e-Navigation with functions that enable stakeholders to perform their duties and responsibilities, and the information to be exchanged between those functions.Obligations and responsibilities, as well as the functions and streams of information between them should all be combined in a process that is related to the specifi c situation and condition of the ship during navigation.2. Another purpose of architecture is to support the implementation of the e-Navigation concept.The architecture should provide insights into the implementation requirements with reference to logical specifi cations, e.g.how to realize the fl ow of information between the two systems participating in e-Navigation.It is necessary to defi ne current technologies, standards and solutions that will be used in e-Navigation.
It should be emphasized that the architecture (which is still quite abstract at this stage) is needed to achieve primarily the conceptual specifi cation of e-Navigation, and then to select those technical solutions that best suit that conceptual specifi cation.Theoretically, it can mean that more time is needed before signifi cant implementation of the e-Navigation concept takes place if present technical solutions and standards are not able to meet the conceptual specifi cation of e-Navigation.

INITIAL OVERARCHING E-NAVIGATION ARCHITECTURE / Početna sveobuhvatna arhitektura e-navigacije
The IMO document "Initial Technical e-Navigation Architecture" [7] is the fi rst offi cial document which presents the initial overarching e-Navigation architecture.The document is the fi rst contribution of the IALA [8], i.e. the e-Navigation committee approved by IALA Council to the IMO responsible group for e-Navigation.The document describes: -Overarching e-Navigation architecture.
-Its dependence on external systems and infrastructures.
-Main elements of the UMDM data model.
To achieve the e-Navigation concept, architecture is a necessary step [9]: in order to realize the strategic implementation plan it is necessary to take several steps, such as the collection of evolving user requirements, architecture development, defi ciencies analysis, cost and benefi t analysis, and risk evaluation.These elements are the basis for the development of a detailed strategic implementation plan.The IMO has also made a clear standpoint on the functions and components of any technical e-Navigation architecture [9]: The general conceptual, functional and technical architecture of e-Navigation needs to be developed and maintained, particularly with regard to process descriptions, data structures, information systems, communication technologies and regulations.The architecture should include hardware, data, information, communications, and software needed to meet user needs [3].Architecture should be based on a modular and scalable concept (in other words, easy to upgrade with new components without much need for changing the existing components).Hardware and software systems in e-Navigation should be based on open architecture to enable scalability of functions due to various user needs and to support further development and improvement.An abstract overview of the initial overarching e-Navigation architecture is shown in Figure 1.
Here is an architecture explanation: Figure 1 represents an abstract representation of the environment of e-Navigation.In the foreground, Figure 1 shows ship entities, shore-based entities, physical connections and functional connections between the entities.The architecture also shows a UMDM data model as a standard for data exchange between the mentioned entities, and World Wide Radio Navigation Systems (WWRNS) that serves as a support for ship and shore-based entities.
The ship's environment is shown on the left.From the perspective of e-Navigation, relevant devices from the ship's environment include the transceiver station, sensors and applications connected to the transceiver station, Integrated Navigation System (INS), and Integrated Bridge System (IBS).
The architecture shows just one transceiver station, but in reality there can be more than one.The transceiver station is connected with the corresponding e-Navigation technical services at the shore by physical link.Part of the technical services on the shore is in charge of connecting with the ship.Shore-based technical services are actually a link for the interaction between shorebased user applications and the physical link.All technical services on the shore encapsulate (hail) technology and thus reduce complexity (Figure 2) [10].
The term encapsulation refers to the term from objectoriented programming languages, and in that context relates to hiding data within an object from external access.In other words, a strictly controlled approach to the object and its data is enabled through public methods.Theoretically speaking, any entity from the maritime domain can be an object in e-Navigation (an object is a software abstraction of a real marine entity that is relevant to e-Navigation).Encapsulation can be achieved through the development of UMDM data model (gray ellipse from the Figure 1) that can be considered as an abstract representation of entity-related data and links between those entities within the marine domain relevant to e-Navigation.
Shore-based operating personnel (e.g.VTS operators, MRCC operators, VTMIS operators, etc.) need user applications to perform their tasks in conjunction with ship applications.From the perspective of shore-based operating personnel and shipboard personnel, neither the physical link nor the shore-based technical e-Navigation services are essential (it is the reason they are encapsulated at the fi rst place), but the functional connection between user applications on ship and user applications on the shore (dotted black arrow in Figure 1) is considered to be essential.The same analogy can be applied on ship to ship, and shore to shore interactions.The mentioned functional connection refers to data exchange between shorebased applications and ship applications, i.e. the functional connection defi nes the way data are exchanged between the applications.The functional connection is an abstract concept and depends on specifi c requirements for data exchange between two or more applications.The physical connection for data exchange refers to physical data transmission media that can theoretically be anything (e.g.radio waves, light, wire, etc.).WWRNS are shown as part of the architecture, and are responsible for position and time information.In this context, Global Navigation Satellite Systems (GNSS), such as Global Positioning System (GPS), are key components.

Functional connection between applications and data fl ow in e-Navigation architecture / Funkcionalna povezanost aplikacija i tijeka podataka u arhitekturi e-navigacije
Since the core of e-Navigation concept refers to data exchange and data fl ow between applications (i.e.information provided through these data), the following several examples [10] contribute to better understanding of the functional connections between applications and understanding of the concept and architecture of e-Navigation in general.For example, the functional connection between the seafarer and the operator on shore is illustrated by example in Figure 3.
Figure 3 on the right shows a simplifi ed architectural overview of the shore part of the e-Navigation architecture that is essential for understanding the data fl ow.Services that are pointed out on the simplifi ed view of shore part of e-Navigation systems (Figure 3) can be categorized as follows [7]: -Services for data collection and data transfer.Data may be diff erent, such as traffi c data (e.g.AIS, radar), meteorological data, hydrological data and various other data.Such services are a layer between a physical link and other services located on the shore part of e-Navigation systems.For example, the VHF communication service in Figure 3 may be characterized as such a service.-Services for processing value-added data.These services use information received from other services to generate context-specifi c information such as, for example, the detection of traffi c hazards (e.g.service receives the AIS data from various ships, and on the basis of these data sends hazard information to certain ships).-Services for interaction with users.These services are responsible for forwarding information to users via Human Machine Interfaces (HMI).They also collect information from users.-External communication services (Gateway services) that are responsible for data exchange with external systems.Figure 3 shows that there are two types of users: the primary users, i.e. the inevitable users of the e-Navigation system (e.g.VTS operators), and secondary users who can exchange data with the shore part of e-Navigation systems via external communication services (Gateway services).The functional connection (an interrupted large arrow) between the seafarer on board and the VTS operator refers to voice communication, but also to written communication (e.g.e-mail).There is also a clearly marked physical path (smaller uninterrupted arrows) for data fl ow.The physical path (smaller uninterrupted arrows) connects those components that are inevitably involved in data transfer for this particular case shown in Figure 3.Primary users (e.g.VTS operators) use certain applications to interact with the services (e.g. computer for sending e-mail messages), and such applications are actually HMI's.It should be emphasized that the third-party user concept is not limited and may also include other services, e.g. a weather web service that sends weather data to e-Navigation service upon request.The term "service" is a generic term, and apart from the web service it may relate to any system that provides a particular service.The term "application" is also a generic term, and is not limited to computer software only.
Figure 3 Functional connection between the operator on shore and the seafarer on ship [10,11] Slika 3. Funkcionalna povezanost operatera na kopnu i pomorca na brodu [10,11] The example in Figure 4 shows the functional connection between ship sensors and the shore operator.
Figure 4 shows the functional connection of marine sensors and the shore operator, and it is clear that, in this case, the data transfer is one-way.The data fl ow is automated, and it is not necessary for the seafarer on a ship to be involved in the process (smaller dotted arrows indicate components that can be omitted in the particular situation).An example of such a functional connection is AIS traffi c monitoring where the position along with other vessel data is continuously and autonomously sent from the corresponding ship sensors to the VTS centers.
Furthermore, the example in Figure 5 shows the functional connection between the shore-based application and the ship application.
Figure 5 shows an automatic, and possibly autonomous, data exchange between a ship and shore-based applications, e.g. a computer on a ship and a database on a server on the shore.Special messages from AIS applications are listed as an example of data being exchanged, which may be, e.g.hydrologic data saved in a database on the shore.In this situation, ship sensors are an indispensable component.Smaller dotted arrows in Figure 6 indicate that interaction with the personnel in this case is not necessary.
The example in Figure 6 shows the functional connection between the shore physical installation and the seafarer on the ship.
Figure 6 shows probably the best example of how even classic applications such as lighthouses and various other visual aids in navigation fi t perfectly into the concept and architecture of e-Navigation.The diagram shows the functional connection of seafarers on board ships and some visual aids in navigation (e.g.lighthouse, buoy).The functional connection in this case depends on what the seafarer sees.This example uses a visual physical link, i.e. the transmission medium is light that propagates through the air and reaches the seafarer's eye on the ship.Smaller dotted arrows in Figure 6 show that aids to navigation today have sophisticated electronic equipment that are linked to other systems that can potentially be included in the process described in the diagram.The example in Figure 7 shows the functional connection between shore-based applications.More precisely, this diagram shows the functional connection between shorebased applications (primary user applications) which are an indispensable part of e-Navigation systems and shore-based applications that are not an indispensable part of e-Navigation systems (secondary user applications or third-party user applications).
Figure 7 shows that diff erent shore-based applications can exchange data.Many diff erent shore-based applications can exchange data with each other, meaning that many diff erent functional connections can exist.The physical link, i.e. the data transfer medium, needs to exist just as when transmitting data between ship and shore-based applications.In this case (Figure 7) it is apparent that the data exchange of the secondary user applications (third party) and the primary user applications has to be done through the external communication services (Gateway services) and value-added data processing services.In the process of data exchange it is not necessary for the data to reach other components of the e-Navigation system (smaller dotted arrows).

E-Navigation architecture and functional connections in the context of emerging ICT technologies / Arhitektura e-navigacije i funkcionalna povezanost u kontekstu razvoja ICT tehnologije
The concept of e-Navigation and its architecture are open to new technologies by their defi nitions [12].In recent years, the development of ICT has been making impact on shipbuilding and shipping industry in terms of digitization and automation.State of the art ICT technologies and concepts (also called intelligence information technology) like IoT (Internet of Things), Cloud Computing, Big Data and AI (Artifi cial intelligence) are of particular interest because they go side by side with the concept of Unmanned Autonomous Ships which are undoubtedly becoming a reality [13,14].On the other hand, it should be noted that although autonomous ships are currently beyond the e-Navigation scope, they are not in collision with e-Navigation goals, and are even able to fi ll in detected e-Navigation gaps [13,15].Some of these new ICT technologies and concepts were already analyzed within the scope of e-Navigation, and e-Navigation architecture was already presented in the context of IoT concept [16,17].In short, this concept means that all devices, systems and ultimately ships would be connected on the internet in order to create new value.In accordance with the above it is necessary to further explain the ship-ship concept of architecture and exchange of information that has not been discussed suffi ciently so far [6,7].It should be stated that the analogy observed from ship-shore functional connections can also be applied to ship-ship functional connections.On the other hand, with regard to the integration of new ICT technologies and unmanned autonomous ships, certain recommendations considering e-Navigation architecture should be highlighted: -Human factor is the leading cause of accidents in maritime transport.Due to this fact, M2M (Machine to Machine) communications and actions that can potentially be performed by machines need more attention.After all, new ICT technologies and concepts (IoT, AI, Cloud Computing, etc.) imply M2M communication, and are greatly dependable on it.M2M communication should be standardized.-It is necessary to clearly identify and analyze all the actions that machines undoubtedly perform faster and better than humans.Example 1: the acquired historical regular movement vessel pattern of the incoming vessel in the observed area can be analyzed using "Big Data" concept and compared with the current real time vessel track data streams.If any irregularities are found, crew on the ship could be alarmed as a decision support measure.Additionally, neighboring ships could also be alerted due to the existence of IoT technology.It should be noted that the "vessel track data streams" is explained in detail in "ACCSEAS -Implementing e-Navigation in the North Sea Region" project, which contains one of the most detailed descriptions of the current e-Navigation architecture [18].Example 2: the usage of ships as a source of meteorological and hydrological data could prove to be benefi cial and should also exclude humans.Owing to the existence of IoT, ships could exchange such data automatically with each other or with the shore, and those data would provide weather and hydrological information in a so far unseen detailed level.-Crucial safety navigational actions should be based on redundancy.In the above mentioned Example 1, redundancy can be achieved if the real time vessel track data streams of incoming vessel are analyzed and compared at multiple places (e.g. on the ship itself, and in the VTS center).
Other types of redundancy could be achieved by e.g. using a collision or grounding avoidance system that maneuvers the ship if crew reaction upon alert is late.-In accordance with the use of emerging ICT technologies, it is recommended that the ship part of e-Navigation also includes services for processing value-added data, as well as other services if necessary.Integration of new ICT technologies would be simplifi ed in that case.Regardless of the new ICT technology, it should be noted that the existing generic e-Navigation architecture is not compromised by the use of these technologies.In the context of technologies like IoT, Big Data, AI, Cloud, etc. term application and service on the ship part of e-Navigation would probably refer mainly to the software.The following hypothetical example in Figure 8 shows the functional connection of ship-based applications that exchange meteorological and hydrological data in the presence of IoT concept.
Figure 8 shows data exchange between ship applications with the purpose of meteorological and hydrological data exchange.Satellite communication could be used to exchange such data.In the IoT concept existence, such communication and automatic data exchange between ships within the network of ships could exist independently of shore-based e-Navigation systems.The diagram shows that meteorological and hydrological data collected from the ship sensors are sent "raw" without previous value-added data processing services Figure 8 Functional connection between ship-based applications Slika 8. Funkcionalna povezanost između aplikacija na brodu involvement.The ship that receives those data process them with value-added data processing services, after which certain ship applications can use those data (e.g.display them to a crew in an augmented reality manner, or alert the crew in a danger situation).

UMDM data model / UMSM podatkovni model
Figure 1 clearly shows that the Universal Maritime Data model (UMDM) is a key part of the e-Navigation architecture.The latter need to be perceived through the fl ow of data/information, interaction of diff erent applications, and user interfaces in the way described further in this chapter.User requirements should be observed through the information required to perform a certain task [19].Necessary information is provided via HMI of the user applications with the help of the shore-based e-Navigation system as a fulfi llment of these requirements.The information is transmitted, stored and processed as so-called data objects (terminology related to object-oriented programming) with the help of a shorebased e-Navigation system.Therefore, there is a need for the development of a consistent and unique data model (UMDM) which is a common view of all data objects and links between them within the maritime domain.Development of the UMDM is an evolving process and it will involve the common eff orts of many sides from the maritime domain.All parties should participate in the design of the model with their special expertise, and the Universal Maritime Data model should become a generally accepted standard data model in e-Navigation.This is the fi rst step towards developing a common data structure.The UMDM model is only a part of the data structure that may include other data models.In the following chapter, the above mentioned data structure is termed Common Maritime Data Structure (CMDS) and is described in more detail.The data model S-100 of the IHO was suggested as an example that could be useful in the process of realization of the UMDM model [20].In 2010, IHO introduced a new data model known as S-100 -Universal Hydrographic Data Model (UHDM) [21].IHO has been developing this standard for a decade in agreement with a wide range of stakeholders, including the key producers of Electronic Chart Display and Information System (ECDIS) systems and other navigation equipment.The purpose of the S-100 is to guide architecture development for the modern exchange standard of hydrographic and other related data from the maritime domain.The S-100 is not limited to hydrographic data and hydrographic applications, but has been developed to allow the widest possible range of hydrographic data users as well as other relevant information from the maritime domain.Like traditional applications, such as nautical charts and publications, applications based on the S-100 standard are also developed by interest groups that are not related to IHO interest groups [20].These are applications that include various hydrographic, meteorological and oceanographic parameters that go beyond traditional navigation and hydrographic products provided by IHO.

EXPANDED OVERARCHING E-NAVIGATION ARCHITECTURE / Proširena sveobuhvatna arhitektura e-navigacije
The overarching e-Navigation Architecture from Figure 1 has its expanded variant, which was developed as a result of observing architecture through data/information fl ow, application interactions and user interfaces.Therefore, the e-Navigation architecture can be illustrated with an emphasis on data/ information fl ow (Figure 9) [22].
The architecture concept from the Figure 9 extends the concept shown in Figure 1 (but there is no confl ict between the two).When observed horizontally, there are many links between ship and shore-based e-Navigation systems that are also hierarchically positioned (operational services, functional connections and physical links used by technical services).When observed vertically, it is apparent that there is a distinction between data and information domain.HMI's are connecting these two domains while providing information and data to human users in a convenient format [23].The architecture from Figure 9 extends the architecture from Figure 1 in the following way [24]: This extended architecture from Figure 9 separates the concept of services into technical and operational ones.It should be noted that operational services are hierarchically superior to technical services, i.e. technical services are used by operational services.For example, a VTS operator gives a report to a certain ship about current weather/meteorological conditions on its course (operational services) after the VTS operator received that very information from a meteorological web service (a technical service that supports the operational service).
According to source [18], the operational services can be explained in the following way: there is a whole range of operational services that take place between the ship and the shore, both the existing ones and the new ones that will appear in future.The term "operational services" encapsulates the connections and interdependencies of these services, and in a picturesque manner, it describes the user on the ship and the user on the shore as the end points between which the operating services operate.According to the same source, technical services are explained in the following way: there is a whole range of technical services that serve, i.e. support operational services, both the existing ones and the new ones that will appear in future.Their connections and interdependencies are also encapsulated in the term "technical services", and the architectural diff erence between the functional connection and the physical link is recognized.
The extended architecture also introduces the MSP concept that defi nes and describes a set of operational and technical services as well as the level of their service provided by a stakeholder for a specifi c maritime area, waterway or port [22,18].
Moreover, for the fi rst time, the extended architecture represents a common data structure related to the maritime domain, and is therefore called Common Maritime Data Structure (CMDS).CMDS is the key to achieve harmony between the various technical systems on board ships and on the shore.The main characteristics of the CMDS structure are as follows [24]: -CMDS can represent any entity in the maritime domain, it is available to any stakeholder, and it can be expanded by adding new entities.-CMDS is an abstract representation of parts of the maritime domain, representing its entities and their relationships.-CMDS does not contain details about the physical representation of its entities, but serves as a guide for development of the required databases and interfaces.-CMDS is fl exible and expandable in terms of accepting future user requirements, and new entities can be added to CMDS through the registration process.
Figure 10 shows the relationship between CMDS and other architectural components when developing hardware and software that will be used in e-Navigation.
CMDS is designed to contain data models such as UMDM developed by IALA, UHDM developed by IHO, but also models of other international stakeholders.CMDS is a very important asset that enables e-Navigation to modernize the operating environment of the maritime industry [25].

CONCLUSION / Zaključak
Review and insight into the current state of e-Navigation architecture is provided within the paper along with the certain functional connection perspective and recommendations regarding future e-Navigation architecture.E-Navigation is a broad concept aimed at increasing the safety of navigation and increasing the safety and protection of the marine environment through harmonized collection, integration, exchange, display and analysis of maritime information on board the ship and the shore.On the other hand, the main goal of e-Navigation architecture is to become the cornerstone of the development and implementation of the e-Navigation concept while promoting the international harmonization and standardization.The e-Navigation architecture at this time still includes large level of abstraction.The initial and extended overarching architecture is analyzed with an emphasis on the data fl ow and functional connections within the architecture, as well as the UMDM data model and CMDS data structure as the basis of the architecture.Special attention is drawn to the functional connections within the architecture, and explanations are exemplifi ed.Given that technologies, Figure 10 Scope and impact of CMDS [24] Slika 10.Opseg i utjecaj CMDS [24] information, political and commercial goals change over time, e-Navigation should be observed as an evolving concept.This is why it is necessary to have a stable and elaborated architecture that will play the role of e-Navigation development guide.It should be emphasized that the architecture needs to be tailored to various requirements and easily upgraded, and the hardware and software used should be based on open architectures to facilitate continuous development and customization of functionality according to the needs of a variety of users.In the context of new ICT technologies, introduced recommendations refer to promotion and more detailed elaboration of the M2M communication concept within the architecture, as well as to a more dominant engagement of machines in those actions that they can undoubtedly perform better than humans.The redundancy concept should be improved within the actions that are crucial for the safety of navigation, and value -added data processing services (software context) implemented within the ship part of e-Navigation system.