e-Navigation Architecture The present status and work ahead

1. e-Navigation Architecture The present status and work ahead Nordic Institute of Navigation Bergen 2009-03-05 Rolf Zetterberg

2. Maritime Safety Inspectorate Civil AviationAuthority Swedish Transport Agency Rail Traffic Inspectiorate Road Trafffic Inspectorate

3. 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 2009. Mandate

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

5. 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, exchangeonboard and ashore

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

7. Background Integration and exchange of information GPS LRIT ECDIS RADAR MRCC MSI RADAR Alarms VTS AIS Met/hyd AIS Galileo GMDSS Ports Pilots onboard ashore

8. 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

9. 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….

10. IMO Decisions - e-Nav strategy • Key Strategy elementsArchitectureThe 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.

11. IMO Decisions - e-Nav strategy • Strategy implementation planArchitecture and analysisDefinition 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.

12. 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 2006and ane-Navigation Architecture WG in 2007

13. 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

14. 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)

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

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

17. Peer-to-peer functional connection shore-based operator  mariner Peer-to-peer functional connection(e.g. voice communications) e.g. VTS Center Link Shore-based e-Navigation system Shipboardapplication Ship- boardTrans- ceiver User InteractionService VHF Communi-cation Service Added-ValueData ProcessingServices Other sensor services ShipborneSensors Gateway Service Other sensor services Deployed and operated by shore-based competentauthority Third party users Physical path

18. Functional connection shipboard sensors  shore-based operator Peer-to-peer functional connection(e.g. AIS monitoring) e.g. VTS Center Physical path Link Shore-based e-Navigation system Shipboardapplication Ship- boardTrans- ceiver AIS Service Added-ValueData ProcessingServices User InteractionService Other sensor services ShipborneSensors Gateway Service Other sensor services Deployed and operated by shore-based competentauthority Third party users

19. Functional connection shipboard application  shore-based application Peer-to-peer functional connection(e.g. AIS application specific messages) e.g. VTS Center Physical path Link Shore-based e-Navigation system Shipboardapplication Ship- boardTrans- ceiver AIS Service Added-ValueData ProcessingServices User InteractionService Other sensor services ShipborneSensors Gateway Service Other sensor services Deployed and operated by shore-based competentauthority Third party users

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

21. Functional connection between shore-based applications e.g. VTS Center Link Shore-based e-Navigation system Shipboardapplication Ship- boardTrans- ceiver AIS Service Added-ValueData ProcessingServices User InteractionService Radar Service Physical path ShipborneSensors Gateway Service Other sensor services Deployed and operated by shore-based competentauthority Third party users Peer-to-peer functional connection(e.g. data exchange between authorities)

22. 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

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

24. 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.

25. The Maritime Data Model • Universal Maritime Data ModelStandard Data Format- Tree structure - Branches - Leafs- Maritime Information Objects- Flexible and scalable

26. 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)

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

28. Embedded in national, regional, and global topologies e.g. LRIT or IALA-NET e.g. EU-SSN e.g. HELCOM Deployed andoperated byown authority

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

30. Future work - IMO

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

32. 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 Navigationshould jointly develop a coordinated approach to implement the proposed e-Navigation strategy

33. Summary e-Navigation Architecture • 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

34. Questions? Rolf Zetterberg rolf.zetterberg@transportstyrelsen.se

35. Thank You for your attention! Rolf Zetterberg rolf.zetterberg@transportstyrelsen.se