1. CETMEF-2008 - Common Shore-Based e-Navigation Architecture
Dipl.-Ing. Jan-Hendrik Oltmann
Deputy Head of Traffic Technologies and Telematics Division German Federal Waterways and Shipping Administration + Chair, Architecture Technical Working Group of IALA e-Navigation Committee

2. Presentation Overview
What is e-Navigation?
The full picture: The overarching e-Navigation architecture
Zoom-In: Developing a common shore-based e-Navigation system architecture
Zoom-Out: Embedding the common shore-based e-Navigation system architecture in national, regional, and global topologies
IALA‘s role
Summary and concluding remarks

3. IMO‘s e-Navigation Definition
„E-Navigation is the
harmonized 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.”

4. The harmonization effect of IMO‘s e-Navigation concept
Maritime Fields
e-Navigation
 Global harmonization
„common global language“
defined levels of functionality
defined levels of service quality
quality improve- ment by error avoidance
look-ahead: auditing, certification, (V)IMSAS ????
Vessel Traffic Management (VTM) ???
Ship operation + navigation proper
Classical Aids-to-Navigation
Vessel Traffic Services (VTS)
Search and Rescue / GMDSS
Pilotage
Security / ISPS
Port operations
Maritime hazard abatement
Complete List: Compare e.g. Annex 2 of Annex 12 of report IMO-NAV54

5. The overarching
e-Navigation
architecture

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

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

8. Peer-to-peer functional connection (e.g. voice communications)
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
Shipboard application
Ship-
board Trans-
ceiver
VHF Communi- cation Service
User Interaction Service
Added-Value Data
Processing Services
I would now like to venture into some generic peer-to-peer applications involving the ship and the shore side. The diagram shows you a simplified architectural setup for in particular the shore side.
On shore, there are depicted two kind of users: the primary user who is directly supported by the shore-based components of that competent authority under consideration;
and the secondary user who receives data via a gateway.
The virtual connections which really are the e-Nav peer-to-peer applications are highlighted as well as the physical path the data needs to take.
In this slide there is a peer-to-peer connection between the mariner and the shore based operator. This is the verbal or written communication application between a ship and a VTS center. The data exchange could be voice and/or , for example.
Other sensor services
Shipborne Sensors
Gateway Service
Other sensor services
Deployed and operated by shore-based competent authority
Third party users
Physical path

9. Peer-to-peer functional connection (e.g. AIS monitoring)
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
Shipboard application
Ship-
board Trans-
ceiver
AIS Service
Added-Value Data
Processing Services
User Interaction Service
This slide shows you an e-Nav peer-to-peer application where data is transferred from a shipboard sensor to a shore-based operator.
The shore-based operator sees the data by means of a Human-Machine-Interface provided.
The data flow appears to be automated: The mariner is not involved in it.
As an example of this kind of peer-to-peer application think of the AIS traffic monitoring, where position and other data are constantly and autonomously being transfered from the appropriate shipboard sensors to the shore-based VTS centers.
Other sensor services
Shipborne Sensors
Gateway Service
Other sensor services
Deployed and operated by shore-based competent authority
Third party users

10. 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
Shipboard application
Ship-
board Trans-
ceiver
AIS Service
Added-Value Data
Processing Services
User Interaction Service
This e-Nav peer-to-peer application shows the automated and maybe autonomous data exchange between e.g. a shipboard computer and a shore-based data base.
This peer-to-peer application may be using the application specific messages of the AIS to exchange the data.
The data may e. g. be hydrological data from a shore based data base. This in turn is fed by the appropriate sensors.
Obviously, no human interaction is needed to transfer this kind of data.
Other sensor services
Shipborne Sensors
Gateway Service
Other sensor services
Deployed and operated by shore-based competent authority
Third party users

11. Peer-to-peer functional connection (e.g. Visual Aids-to-Navigation)
Functional connection shore-based installation  mariner
Peer-to-peer functional connection (e.g. Visual Aids-to-Navigation)
e.g. VTS Center
Physical path
Link
Shore-based e-Navigation system
Shipboard application
Ship-
board Trans-
ceiver
Visual Aids-to- Navigation Service
User Interaction Service
Added-Value Data
Processing Services
But also classical peer-to-peer applications can be modelled using the overarching e-Nav architecture. The example shows the virtual „connection“ between a mariner and a visual Aids-to-Navigation, which is supported by a visual, physical link.
This kind of peer-to-peer application looks and sounds simple, but nowadays there is a great deal of sophistication, i. e. electronics, hidden within or behind the actual visual Aid.
Other sensor services
Shipborne Sensors
Gateway Service
Other sensor services
Deployed and operated by shore-based competent authority
Third party users

12. Functional connection between shore-based applications
e.g. VTS Center
Link
Shore-based e-Navigation system
Shipboard application
Ship-
board Trans-
ceiver
AIS Service
Added-Value Data
Processing Services
User Interaction Service
Last but not least, there are those peer-to-peer applications which support secondary shore based users and their own application computers via gateways.
Note, that these computers and Human-Machine-Interfaces connected to the gateway belong to other competent authorities. Hence, the gateways both connect and separate different electronic environments of different competent authorities.
Radar Service
Physical path
Shipborne Sensors
Gateway Service
Other sensor services
Deployed and operated by shore-based competent authority
Third party users
Peer-to-peer functional connection (e.g. data exchange between authorities)

13. Aids-to-Navigation Applications
The complete picture refined – user-requirement driven design
Operational Requirement – Fulfillment by provision of Human Machine Interface
Aids-to-Navigation Applications
Including VTS
Engineering modeling of shore-based e-Nav system (architecture + technologies + interfacing + life-cycle-management)

14. Zoom-In: Developing a common shore-based e-Navigation system architecture

15. Physical Link (e.g. radio link) „signal-in-air“ specifications
Master complexity! - How?
E-Nav Appli-
cation
Physical Link (e.g. radio link)
Encapsulation of
complexity for
shore-based
e-Navigation
applications
Shore- based e-Nav
service
E-Nav
Appli-
cation
We arrive now at a critical point regarding the definition of the shore-based architecture:
How do we as a competent authority master the complexity involved?
How do we do this in a cost-efficient manner?
The answer:
Encapsulate complexity in shore-based eNAV services
The term „service“ should be used to designate a set of shore based functionality participating in the peer-to-peer virtual connection to encapsulate their complexities.
For every link technology there is defined a specific e-Nav service, and also for similar specific tasks within the shore-based system.
Examples of such shore based e-Nav services are: the AIS Service, the Radar Service, the Floating Visual Aids Service, but also the Gateway Service and certain Value-Added Services within the core of the shore-based system architecture.
And: define open and standardised interfaces between the e-Nav services.
E-Nav Appli-
cation
Standardised
interfaces
Point of view
from ashore
Standardised
„signal-in-air“ specifications

16. f(x) Fundamental design principles /1
shore based e-Navigation system
f(x)
In order to arrive at a consistend shore-based e-Nav system architecture that covers all aspects certain fundamental design principles need to be adhered to:
First: Think in terms of functionality (What?) instead of technology means (how?)
The only permissible technologies to think about at this stage would be the technologies of the physical links.
Note: This example shows data flow from shore to ship only. The principle holds true for the other direction as well.
Deployed and operated by shore-based competent authority
Thinking in user-requirement driven functionality (not technology) – What?! – instead of How?!

17. Fundamental design principles /2
Deployed and operated by shore-based competent authority
Second:
Derive functionality in a top-down user requirement analysis using e. g. the use case methodology.
User-requirement driven design - employing the object orientation and top-down functionality analysis

18. Fundamental design principles /3
shore based e-Navigation system
Third:
Consider the shore-based e-Nav architecture as a client-server-architecture where different specific e-Nav services perform certain tasks, supporting each other:
Data Collection and Data Transfer services
Value-added data processing services
Gateway Service
User Interaction Service
This model could serve as a holistic architecture model for the competent authorities, i. e. is of common relevance.
One holistic, common, service-oriented, and client-server shore-based e-Navigation system architecture
Deployed and operated by shore-based
Competent authority

19. Holistic Life-cycle management
Fundamental design principles /4
Fourth:
When describing the individual e-Nav services consider all aspects relevant to the setup of such a system and to ist cost-efficient operation over a long life-cycle.
Life-cycle management considerations should be employed from the beginning.
Deployed and operated by shore-based competent autority
Holistic Life-cycle management

20. Zoom Out: Embedding the common shore-based e-Navigation system architecture in national, regional, and global topologies

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

22. IALA‘s role
(IALA = International Association of Marine Aids-to-Navigation and Lighthouse Authorities)

23. IALA Contributions to IMO documents
Development of common shore-based e-Navigation system architecture /1
IMO‘s invitation to IALA for participation in the implementation of e-Navigation
Long standing mandate of IALA for mutual support of Aids-to-Navigation/VTS authorities (IALA national membership)
IALA Contributions to IMO documents
(future) IALA Recommendations, IALA Guidelines + IALA Manuals on e-Navigation for IALA National Members
IALA activities for e-Navigation

24. Development of common shore-based e-Navigation system architecture /2
IALA‘s goals regarding e-Navigation:
To co-ordinate the implementation of e-Navigation for international, shore-based stake-holders, globally.
2. Prepare IALA itself for the implementation of e-Navigation => „Thinking in e-Navigation on a global scale“
3. Prepare IALA (national) members for the pending implementation of e-Navigation => Recommendations, Guidelines, Manuals for IALA membership on e-Navigation

25. „Draft IALA Recommendation e-NAV 101 on the e-Navigation Architecture
Development of common shore-based e-Navigation system architecture /3
„Draft IALA Recommendation e-NAV 101
on the e-Navigation Architecture
– the Shore Perspective“
Content overview:
- the double mandate of IALA
- driving forces
- fundamental principles: overarching and shore-based system architecture
impact of e-Navigation on IALA as an organization, and its documentation
dependencies: GNSS/WWRNS, infrastructure

26. Summary and
concluding remarks

27. Fundamental statements applied to the „three sides of the coin“
Internationally agreed, precise and open link descriptions („signal-in-air“)
Internationally agreed, holistic, flexible, and common shore-based e-Navigation system architecture
Conclusion = requirements for the shore-based e-NAV System architecture
One holistic and flexible system architecture for shore side of eNAV-Concept should be agreed to:
= employ state-of-the-art modeling techniques, such as OOP, Open System philosophy ...
= consist of individual eNAV services to
a) reduce complexity by one common eNAV service model
b) allow optimum allocation of expert resources: treat each eNAV service independently, while adhering to common eNAV service rule base
c) cater for distributed responsibilities of participating organisations
= includes full life-cycle analysis from start => maintenance is the major cost driver!
focus on applications (Information flow peer-to-peer
= from ultimate information source
to ultimate information sink)

28. User requirements / peer-to-peer applications – not so much new under the sun!?“
existing definitions needs to be inter-
nationally documen-ted and harmonised
existing, well-known
user requirements + applications:
VTS, Aids-to-Navigation,
AIS integration, radio navigation,
shore data exchange
Need to
be created, evaluated and internatio-nally defined
I stated earlier that all user requirements should be collected and harmonized in a top-down approach. This is a huge task.
However, although the term „e-Nav“ as such is new, the concept has been there for quite a time:
In particular the advent of the AIS constituted a major trigger event to start thinking in architectural terms on the shore side already years ago.
Hence, there are a lot of existing, well-known user requirements and applications which need to be brought together in a harmonized way.
That is the new task. And huge it is as well.
And also there are some genuinely new e-Nav applications, which need to be described from scratch.
genuinely new e-Nav user-requirements + e-Nav applications

29. Thank you for your attention! Questions?