e-Navigation Architecture The present status and work ahead Nordic Institute of Navigation Bergen Rolf Zetterberg

Maritime Safety Inspectorate Civil AviationAuthority Rail Traffic InspectiorateRoad Trafffic Inspectorate Swedish Transport Agency

New transport agency in Sweden The Swedish Transport Agency is working to achieve good accessibility, high quality, secure and environmentally aware rail, air, sea and road transport. We have overall responsibility for drawing up regulations and ensuring that authorities, companies, organisations and citizens abide by them. The Swedish Transport Agency was established on the 1st of January Mandate

E-Navigation Architecture Background Decisions by IMO The work of IALA Future work Summary Presentation content

Background The definition of e-Navigation “ e-Navigation is the harmonised collection, integration, exchange, presentation and analysis of maritime information onboard 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 ” Integration, exchange onboard and ashore

Background GPS ECDIS RADAR Galileo AIS VTS Ports Pilots AIS MRCC LRIT RADAR Alarms MSI GMDSS Met/hyd

Background GPSECDIS RADAR GalileoAIS VTS PortsPilots AIS MRCCLRITRADAR AlarmsMSI GMDSS Met/hyd Integration and exchange of information onboardashore

IMO Decisions MSC 85 adopted a ”Strategy for the development and implementation of e- Navigation” (MSC 85 Annex 20) Common Maritime Information/Data structure - Information for mariners should be accessible from a single integrated system. - Information for shore based users should be available in an internationally agreed common data structure

IMO Decisions – e-Nav strategy e-Navigation systems should be resilent and take into account issues of data validity, plausibility and integrity for the systems to be robust, reliable and dependable. e-Navigation should as far as possible be compatible forwards and backwards and support integration with equipment and systems made mandatory under international and national carriage requirements….

IMO Decisions - e-Nav strategy Key Strategy elements Architecture The overall conceptual, functional and technical architecture will need to be developed and maintained, particularly in terms of process description, data structures, information processes, communications tecknology and regulations.

IMO Decisions - e-Nav strategy Strategy implementation plan Architecture and analysis Definition of the integrated e-navigation system architecture and concepts of operation should be based on consolidation of the user needs across the entire range of users, taking into account all possible economies of scale. The architecture should include hardware, data, information, communications and software needed to meet the user requirements.

The work of IALA IALA – International Association of Marine Aids to Navigation and Lighthouse Authorities – is invited by IMO to participate in the work on e-navigation IALA created an e-Navigation Committe in 2006 and an e-Navigation Architecture WG in 2007

The work of IALA Three interacting parts of an e-Navigation Architecture - Shipboard integration of data processing devices - Application to application data exchange ship/shore - Shore based integration of a variety of different systems

The three sides of the coin “harmonized collection, integration, exchange, presentation and analysis of maritime information onboard ” “harmonized collection, integration, exchange, presentation and analysis of maritime information ashore ” “exchange” = virtual/ physical link(s)

e-Nav Architecture Ship´s sensors Shipboard Applications Tranceiver station INS IBS e-Nav services Communication service Physical Communication Link ShipShore Other ships Application 1 Application 2 Application 3 Application 4 World Wide Radionavigation System

e-Nav Architecture Ship´s sensors Shipboard Applications Tranceiver station INS IBS e-Nav services Communication service Physical Communication Link ShipShore Other ships Application 1 Application 2 Application 3 Application 4 World Wide Radionavigation System Application to Application ( peer-to-peer)

Shore-based e-Navigation system User Interaction Service Link VHF Communi- cation Service Ship- board Trans- ceiver Shipborne Sensors Shipboard application Other sensor services Added-Value Data Processing Services Peer-to-peer functional connection shore-based operator  mariner Peer-to-peer functional connection (e.g. voice communications) Physical path Other sensor services Gateway Service Deployed and operated by shore- based competent authority e.g. VTS Center Third party users

Functional connection shipboard sensors  shore-based operator Shore-based e-Navigation system User Interaction Service Link AIS Service Ship- board Trans- ceiver Shipborne Sensors Shipboard application Other sensor services Added-Value Data Processing Services Peer-to-peer functional connection (e.g. AIS monitoring) Physical path Other sensor services Gateway Service Deployed and operated by shore- based competent authority e.g. VTS Center Third party users

Functional connection shipboard application  shore-based application Shore-based e-Navigation system User Interaction Service Link AIS Service Ship- board Trans- ceiver Shipborne Sensors Shipboard application Other sensor services Added-Value Data Processing Services Peer-to-peer functional connection (e.g. AIS application specific messages) Physical path Other sensor services Gateway Service Deployed and operated by shore- based competent authority e.g. VTS Center Third party users

Other shore-based e-Navigation system(s) Shore-based e-Navigation system „External“ system(s): Position, Velocity, Timing (PNT); World Wide Radio Navigation System (WWRNS) Shipborne Rx/Tx station Data sources Data sinks INS Shore- based eNav services Physical Link (e.g. radio link) other ships other ships Link technology proper E-Nav Appli- cation E-Nav Appli- cation E-Nav Appli- cation E-Nav Appli- cation E-Nav Appli- cation Application-to-application (peer-to-peer) functional connection A closer look e.g. VTS Center

Functional connection between shore-based applications Shore-based e-Navigation system User Interaction Service Link AIS Service Ship- board Trans- ceiver Shipborne Sensors Shipboard application Other sensor services Added-Value Data Processing Services Physical path Radar Service Gateway Service Deployed and operated by shore- based competent authority e.g. VTS Center Third party users Peer-to-peer functional connection (e.g. data exchange between authorities)

Developing the e-Nav Architecture Keep the co-operative nature of e-navigation in mind! - Service Oriented Architecture - Object-oriented Engineering Process - Agreed Maritime Data Model - Generic service setup

f(x) shore based e-Navigation system Deployed and operated by shore-based competent authority Thinking in user- requirement driven functionality (not technology) – What?! – instead of How?! Fundamental design principles

Service Oriented Architecture SOA separates functions into distinct units, or services, which developers make accessible over a network in order that users can combine and reuse them A service oriented architecture is a collection of services. These services communicate with each other.

The Maritime Data Model Universal Maritime Data Model Standard Data Format - Tree structure - Branches - Leafs - Maritime Information Objects - Flexible and scalable

Universal Maritime Data Model The UMDM is proposed as a common data structure Requires the involvment of many concerned parties; IMO, IHO, IALA, IEC, RTCM, etc Identify the user-required information/data objects and describe how they are collected, integrated, exchanged, presented and analyzed (= e-Nav proper in the future)

Backward compatibillity IMO request backward compatibility Backward compatibillity facilitate the implementation Backward compatibillity may prevent a needed technology shift Where is the right balance?

Embedded in national, regional, and global topologies Deployed and operated by own authority e.g. HELCOMe.g. EU-SSN e.g. LRIT or IALA-NET

Future work - IMO MSC 85 adopted a strategy for the development and implementation of e-Navigation

Future work - IMO

Future work Architecture and Analysis - Architecture definition - Definition of concept of operations - Cost/benefit and risk analysis - Training needs analysis - Institutional and regulatory analysis

Future work – IMO MSC 85 Chairmen and secretaries of Sub-Committee on Radiocommunications and Search and Rescue Sub-Committee on Standards of Training and Watchkeeping Sub-Committee on Safety of Navigation should jointly develop a coordinated approach to implement the proposed e-Navigation strategy

Summary Still on a conceptual level IMO has the final say – but IALA will coordinate and perform much of the work It will take time – it´s a huge task e-Navigation Architecture

Questions? Rolf Zetterberg

Thank You for your attention! Rolf Zetterberg