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

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

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

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

The overarching e-Navigation architecture

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”

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)

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 e-Mail, 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

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

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

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

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)

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)

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

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

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?!

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

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

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

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

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

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

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

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

„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

Summary and concluding remarks

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)

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

Thank you for your attention! Questions?