e-navigation architecture the present status and work ahead
DESCRIPTION
e-Navigation Architecture The present status and work ahead. Nordic Institute of Navigation Bergen 2009-03-05. Rolf Zetterberg. Maritime Safety Inspectorate Civil AviationAuthority. Swedish Transport Agency. Rail Traffic InspectiorateRoad Trafffic Inspectorate. - PowerPoint PPT PresentationTRANSCRIPT
04/21/23
1
e-Navigation Architecture
The present status and work ahead
Nordic Institute of NavigationBergen
2009-03-05
Rolf Zetterberg
Maritime Safety Inspectorate Civil AviationAuthority
Rail Traffic Inspectiorate Road Trafffic Inspectorate
SwedishTransport 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 2009.
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, exchangeonboard and ashore
Background
GPS ECDIS
RADAR
Galileo
AIS
VTS
Ports
Pilots
AIS
MRCCLRIT
RADAR
AlarmsMSI
GMDSS
Met/hyd
Background
GPS ECDIS
RADAR
GalileoAIS
VTS
Ports Pilots
AIS
MRCCLRIT RADAR
AlarmsMSI
GMDSS
Met/hyd
Integration and exchange of information
onboard ashore
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
ArchitectureThe 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 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.
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
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
ComputerComputer
Domäne
“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´ssensors
ShipboardApplications
Tranceiverstation
INSIBS
e-Navservices
Communication
service
Physical Communication
Link
Ship Shore
Other ships
Application 1
Application2
Application3
Application 4
World Wide Radionavigation System
e-Nav Architecture
Ship´ssensors
ShipboardApplications
Tranceiverstation
INSIBS
e-Navservices
Communication
service
Physical Communication
Link
Ship Shore
Other ships
Application 1
Application2
Application3
Application 4
World Wide Radionavigation System
Application to Application ( peer-to-peer)
Shore-based e-Navigation system
User InteractionService
LinkVHF Communi-cation Service
Ship-boardTrans-ceiver
ShipborneSensors
Shipboardapplication
Other sensor services
Added-ValueData ProcessingServices
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 competentauthority
e.g. VTS Center
Third party users
Functional connection shipboard sensors shore-based operator
Shore-based e-Navigation system
User InteractionService
Link AIS Service
Ship-boardTrans-ceiver
ShipborneSensors
Shipboardapplication
Other sensor services
Added-ValueData ProcessingServices
Peer-to-peer functional connection(e.g. AIS monitoring)
Physical path
Other sensor services
Gateway Service
Deployed and operated by shore-based competentauthority
e.g. VTS Center
Third party users
Functional connection shipboard application shore-based application
Shore-based e-Navigation system
User InteractionService
Link AIS Service
Ship-boardTrans-ceiver
ShipborneSensors
Shipboardapplication
Other sensor services
Added-ValueData ProcessingServices
Peer-to-peer functional connection(e.g. AIS application specific messages)
Physical path
Other sensor services
Gateway Service
Deployed and operated by shore-based competentauthority
e.g. VTS Center
Third party users
Other shore-basede-Navigation system(s)
Shore-basede-Navigation system
„External“ system(s): Position, Velocity, Timing (PNT); World Wide Radio Navigation System (WWRNS)
Shipborne Rx/Tx station
Datasources
Datasinks
INS
Shore-based eNavservices
PhysicalLink (e.g. radio link)
otherships
otherships
Link technology proper
E-NavAppli-cation
E-NavAppli-cation
E-NavAppli-cation
E-NavAppli-cation
E-NavAppli-cation
E-NavAppli-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 InteractionService
Link AIS Service
Ship-boardTrans-ceiver
ShipborneSensors
Shipboardapplication
Other sensor services
Added-ValueData ProcessingServices
Physical pathRadar Service
Gateway Service
Deployed and operated by shore-based competentauthority
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
Value-addedData
ProcessingServices
User Interaction
Service
Gateway Service
DataCollectionand DataTransferServices
Maritime Traffic Technology System
Traffic objects,including
ships
Primaryusers
Shore based„third party“ users
f(x)
shore based e-Navigation system
Deployed and operated by shore-based competentauthority
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 ModelStandard 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
International (GLOBAL)
Regional (1)
Regional(2)
Regional(3)
Regional(N)
Natio-nal (1)
Natio-nal
Natio-nal
Natio-nal
Natio-nal
Natio-nal
Local Other
Deployed andoperated byown 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
