45
1 E‐NAVIGATION:CURRENTSTATUSAND
PLANNEDPROGRESS
“e‐Navigation is about getting ships safely, securely
and efficiently from berth to berth in an
environmentally friendly way, using globally
enhancedsystemsfornavigation,communicationand
relatedservices–withthehumanelement in focus.”
(NAV58/INF.4, 2012)Based on this description,
theseexpectationsare:
on boa
rd – harmonization of navigation systems,
thereby actively engaging the mariner in the
process of navigation to carry out his duties in a
most efficient manner, while preventing
distractionandoverburdening;
communications – providing an infrastructure
which allows seamless information transfer on
board ship, between ship and shore aut
horities
andotherpartieswithmanyrelatedbenefits;and
ashore – management of Vessel Traffic Service
(VTS) and related services, such as search and
rescue, port and MSI services, through better
provision, coordination, and exchange of
comprehensive data in formats that will be more
easilyunderstoodandut
ilizedinsupportofvessel
safetyandefficiency.
A principal assumption of the e‐Navigation
process is to design any element in a user driven
approach. In order to identify fitting e‐Navigation
solutions, a thorough gap analysis was undertaken. In
it,aspecialtool‐theHumanElementAnalyzingProcess
(HEAP)‐
wasapplied. HEAPisessentiallyachecklist
for issues to consider, in particular relating to the
human element, organizational and training issues.
The HEAP will also be used in the next step, a risk
analysis. In this step so‐called Risk Control Options
(RCOs)willidentifythat willbesubjected to Formal
IMO e-Navigation Implementation Strategy –
Challenge for Data Modeling
M.Jonas
FederalMaritimeandHydrographicAgency,Germany
J
.‐H.Oltmann
FederalWaterwaysandShippingAdministration,Germany
ABSTRACT:Thetopicofe‐NavigationenteredthestageofIMOin2008already.Afteryearlongdebates,the
member states now agree about a consolidated interpretation of e‐Navigation (NAV58/6, 2012). One of the
principal decisions made already, is to develop the overarching consistent e‐Navigation data model on all
asp
ectsrelatedtotheshippingandmaritimedomainatlarge.Thisso‐calledCommonMaritimeDataStructure
shouldbebuiltonthebasisoftheS‐100FrameworkofIHO(S‐100,2010).Thebasisofdatamodelingwithinthe
S‐100 framework is the so called “IHO Geospa
tial Information Registry” (Registry, 2013). Although S‐100 is
designed to support a wider range of hydrographic data beyond ENCs, their creators originally had no
intentiontoexpandthismodeltothewiderscopeof shipping. This paperproposesatransformation and an
enhancement of the existent infrastructure towa
rds a universal “Marine Information Registry” to host data
modeling of all aspects of shipping and the maritime domain, including the modeling of non‐spatial
information.
http://www.transnav.eu
the International Journal
on Marine Navigation
and Safety of Sea Transportation
Volume 7
Number 1
March 2013
DOI:10.12716/1001.07.01.05
46
Safety Assessment (FSA) for risk and cost‐benefit
analysisofe‐Navigationelements.Theoutcomeofthe
analysis will be reflected in a so‐called e‐Navigation
StrategyImplementationPlan.Thus,clearandtraceable
connections between user needs and e‐Navigation
solutionsareestablished.
The following six steps are
relevant to identify
e‐NavigationRCOs:
1 identify user needs that are relevant to the
e‐Navigationobjectives;
2 proposerelevante‐Navigationsolutionsthathave
clearoriginsinuserneeds,andthatcontributesto
eithersafetyorpollutionprevention;
3 combineorredefinesolutions that coincide or are
similar–
upholdtraceabilitytosolutionorigin;
4 develop solutions further to include
infrastructural, usability and regulatory
requirements;
5 evaluate the feasibility of the suggested solutions
with regards to regulatory and infrastructural
requirements;and
6 evaluate suggested solutions or RCOs regarding
their risk reduction effectiveness – disqualify
solutionswithloweffectiveness.
The
followingexamplesmayexplainwhatkindof
e‐NavigationsolutionswillbesubjecttoRCO:
Ergonomicallyimproved,harmonizedandstandardized
shipboardequipment,including,amongstothers,
extended use of standardized and unified
symbologyforrelevantbridgeequipment,
standardizeddigitalfamiliarizationmaterialfor
relevantequipment,
standard default settings, save/recall
settings,
and S‐mode functionalities on relevant
equipment;
integration and presentation of available
information in nautical graphical displays
includingMSI,AIS,charts, radar, etc.received
viacommunicationequipment;
improvedreliability,resilience,andintegrityof
bridgeequipment;
consistent and user‐friendly information
management;
Means for standardized and
automated reporting
ship/shore;
Improved reliability, resilience, and integrity of
navigationinformation
bothforshipboardandshore‐basedusers;
Improved VTS Service Portfolios and their
communicationtoshipping;
Improvedandharmonizedshore‐basedsystemservices;
and
ImprovedaccesstorelevantinformationforSearchand
Rescue.
Arguably,those
tools andprocedures are applied
on a relativelyabstract level,but for that are HEAP,
ROC and FSA finally good for and what will
e‐Navigationexactlydoforthemariner?
2 DATAMODELINGASTHECOREELEMENTOF
E‐NAVIGATION
One of the principal decisions made already, is to
developtheoverarchingconsistente‐Navigationdata
model on all navigation aspects related to the
shippingandmaritimedomainatlarge.Thisso‐called
Common Maritime Data Structure (CMDS) is
considered by some the seventh of the so‐called
“seven pillars of e‐Navigation”. The CMDS may be
eventhemost
importantonebecausethedatamodel
provides the “cement” to the other pillars which are
asfollows:
1 the overarching architecture of e‐Navigation and
generalities,
2 shipboardequipmentfitfore‐Navigation,
3 MaritimeServicePortfolios(MSPs),
4 Communicationtechnologies,
5 ResilientPNT,and
6 Shore‐basedInfrastructure.
It
wasalsoalready agreed thatthe CMDSshould
bebuiltonthebasisoftheS‐100FrameworkofIHO.
S‐100isaflexiblestandardwhichhasbeendeveloped
toaddressthelimitationsoftheIHOS‐57standardfor
ENCsinitsfirstinstance.S‐100providesthetools
to
create product specifications, which in turn define
datacontent. S‐100alsoprovides a registrythat uses
dynamic catalogues, which supports harmonization
and enables the updating and delivery of data
products.
Originallyintendedtocovergeospatialdata only,
itappearsthattheS‐100conceptcouldbeenhancedto
all aspects of shipping and the maritime domain at
large, including the modeling of non‐spatial
informatione.g.pilotrequests,regulatoryinformation
and user requirements (Norway, 2011). It is hereby
proposed that the present registry concept, based on
S‐100 and its existent infrastructure be enhanced to
and transformed into a
universal “Marine
InformationRegistry”,stillbeing basedontheS‐100
framework.
Forthefirsttime,itisproposedbythispaperthat
the following categories should be used within the
MarineInformationRegistry:
Feature(ObjectsclassesandAttributes)
Exchange(dataexchange)
Portrayal (Visualization)
Interaction(Human
Element)
Metadata(Dataaboutdata)
Thesecategorieseachexhibita distinctontological
quality,i.e.astatement/definitionregardingafeature
has a different ontological quality than a
statement/definitionregardingdataexchange,andso
forth.Fromthislistofcategories,allareneededtobe
combinedtoarriveatafunctioning,meaningful,
and
complete (data) product specification, eventually.
These qualities may be grouped together by calling
themaBasicRegister.
An additional Product Specification category
would reference the above categories to that end. In
the beginning of a (data) product development, the
focus of attention may be assigned to feature,
exchange,and
portrayal,e.g.
Toreflectthe derivationchainfromuserneedsto
user requirements, an additional category, named
Requirements,maybeintroduced.
All of the above categories would be a so‐called
Registereachwithinthe MarineInformationRegistry
based on the S‐100 Framework. Hence, the Marine
Information Registry will
comprise the following
Registers:
47
Feature,
Exchange,
Portrayal,
Interaction,
Metadata,
ProductSpecification,and
Requirements.
The Common Maritime Data Structure (CMDS)
wouldin turnhave the Marine Information Registry
anditssupportinginfrastructureasacore.
The widened scope to all aspects of e‐Navigation
requires further substructures within the different
categories,whicharecalledtop‐lev
eldomains.Eachof
the above categories, except Metadata, should
therefore be subdivided into the following top‐level
domains:
Environment
Infrastructure
Units
Operation
Carriage
Itisassumed,thatthosefivetop‐leveldomainsdo
principally cover all topics and themes related to
ma
rine activities. However, each of those top‐level
domainshastobefurtherdetailedintoentitieswhich
aresubjecttostructuringbymeansofregistryentries
according to the S‐100 notation. The following listed
entities of domains are examples for first entries,
however due to the principa
l design of a register;
these lists shall expand if the scope of modeling
expandsstepbystep:
Environment
Hydrography,Oceanography,Meteorology…
Infrastructure
waterways, harbor facilities, WWRNS, AIS, LRIT,
communication systems (all relevant frequency
bands),…
Units
Vessel, floating unit, group of units, offshore
installation,aircraft,…
Operation
Voyage, Crew, ISM, Pilot
age, Security, VTS, MIS,
SAR,…
Carriage
Cargo,Passenger,Fuel,Waste,…
Thelistedentitiesaresplitupfurtherinelements:
Vessel
Navigation,Voyage,Engine,Facilities,Spareparts,
…
Figure1.Exampleforpartofthestructureoftheproposedfuture“MarineInformationRegistry”onthebasisofS‐100
The granularity and the resulting level of
ramifications of the final domain entities are
essentially dependent from the specific intentions of
themodeling.Inoverlappingareasharmonizationof
entities should happen under the authority of a
recognized body nominated to maintain specific
themes within the Marine Information Registry. A
good example would be the “Hydrography” which
wouldmostlikelybemaint
ainbyIHO;anotherone–
“Oceanography” shall be under IOC. Aids to
BasicRegister
Feature
Portrayal…
Environment
Operation
Infrastructure
Units
Carriage
Vessel
Offshoreinst.
Floatingunit
Groupofunits
aircraft
…
Navigation
Facilities
Voyage
Engine
Spareparts
…
Environment
Operation
Infrastructure
Units[Objects]
Carriage
48
Navigation and VTS services would most likely be
maintainedbyIALA.Andsoforth.IMOhasasserted
governanceofthee‐Navigationprocess at large, and
thereforewouldneedtoco‐ordinatetheassignmentof
those themes to relevant organizations.
4
The entities
mostlyaddressed,like “vessel”, mightalso be under
central auspices of IMO. Image No 1 explains the
structure of the future “Maritime Information
Registry”onthebasisofS‐100givinganexamplefor
thedetailingoftheentity“Vessel”.
2.1 BasicRegisterElement:Metadata
The Metadata element
does not have a specific
domain structure. Instead, this element of the Basic
Register hosts a structured catalogue of metadata
entries (similar to INSPIRE) which can be combined
with the particular entries under the different
domainswithintheBasicRegister.
2.2 ProductRegister
TheProductRegister hosts Product Specifications.In
contrast
totheexistingarrangementswithintheIHO
GIRegistrytheterm“Product”isofenlargedscope–
“Product” in the new context is not limited to data
exchangeformatsbutisnowcoveringmorecomplex
modelsforservicesandphysicaldevices.Theremight
beaneedofasub‐structure
accordingtothedomain
structure but along the mentioned characteristics of
theproducts:
Services
Devices
The former objects hosted under Product
Specifications, i.e. the IHO S‐10x data exchange
format family will move to “Exchange” of the Basic
Register and become entities of domain “Basic
Register/Exchange/Environment/Hydrography”.
2.3 Identifier
In
viewoftheambitiontoprovideastructurewhich
potentially allows absorbing any element of the
marinedomain,itbecomesevidentthatunambiguity
and addressability of each of those elements is
essential. It is therefore proposed to introduce a
system of unique identifiers on all levels of the
Marine Information
Registry which are ideally both
human and machine readable. There is probably no
need for a consistent system of identifiers across all
domains. In order to adopt existing registers
including their individual identifier arrangements,
the following variable options could be applied as
convenienttotheparticulardomain/entity:
alphanumerical,notmeaningful
alphanumerical,meaningful
verbal(Camel‐Case)
4
Itshouldbenoted,thatIMOhasalreadydefinedandapproveda
dedicated group, the so called IMO/IHO Harmonization Group
onDataModeling(HGDM),toperformthistask,amongstothers.
TheHGDMneedstobeactivatedsoon.
2.4 Interaction
Image No 2 explains the interaction between the
different elements of the future Marine Information
Registry as seen from the user’s perspective. The
connecting arrows symbolize the hierarchical
relations. There is multitude of relations and
references between entities and elements within the
particularbasicregisterswhicharenotdepicted
here.
Figure2. Interaction between the different elements of the
futureMarineInformationRegistry
3 “OWNERSHIP”VS.“STEWARDSHIP”
With the above structure of registers and domains
implemented, the present S‐99/S‐100 concepts of
“ownership”shouldbekept in principlebutapplied
to individual entities and elements within the above
domains. This would make “ownership”
consequently a meta‐data or meta‐attribute of the
individual
entity or element definition. It would
principally serve the same purpose as the present
conceptof“domainownership”butbemoreflexible,
namelyifsomeorganizationorsomeindividual(viaa
submitting organization) resumes responsibility for
specific register entries. The concept of domains is
thus also simplified by de‐coupling
the domain
concept from “ownership”. This modification will
release the domain concept from (full) domain‐
ownership and lowers the barriers of maritime
stakeholders to associate their themes to the future
Marine Information Registry. With the same
intention,“ownership”undertheabovemodifica tion
should be renamed to “stewardship” for individual
entities or
elements,whereas “ownership”shouldbe
reservedfortheregistryoperatorsitselftoexposethe
special role of the organization operating the
appropriateITinfrastructure.
Requirements-Register [future enhancement]
Product Register
Basic Register
Interaction Register
Portrayal Register
Exchange Register
Feature Register
Metadata Register
49
4 CONCLUSION
Theultimategoalofe‐Navigationistointegrateship
borneand landbased technology ona sofar unseen
level.Thebridgebetweenthosetwodomainswillbe
broadbandcommunicationtechnologywhichisabout
to arrive in regular commercia l shipping within the
next years to come. The
constituting element of this
integration, however, is a common maritime data
model. The existing concept of the Geospatial
InformationRegistrycanbeadaptedtotheenhanced
scope of a future Marine Information Registry
coveringadditional maritimedomains byexpansion,
amendment and moderate rearrangement. Though
the basic philosophy of the S‐
100 Registry prevails,
virtualbarriersformaritimestakeholderstoassociate
with the Registry concept must be lowered by all
means. This includes options to adopt existing
register‐like structures including identifier systems
and stewardship for selected areas and elements of
additional maritime domains in contrast to the
possiblydauntingoverallthird
partyownershipfora
widescientificfieldbypotentialcontributors.Besides
therecognizedinternationalorganizations like,IMO,
IHO and IALA who are currently discussing the
furtherstepsine‐Navigation,agrassrootmovement
may take place with several stakeholders involved
populating the Marine Information Registry. Such a
grass root
movement would truly demonstrate that
e‐Navigation has been understood and accepted. To
allow for the orderly development of that stage of
e‐Navigation in accordance with the IMO defined
goals and aspirations of e‐Navigation, it would be
requiredtoactivatetheappropriateIMOinstruments
already in place, namely the
HGDM, to define the
fundamental principles and structure of the Marine
Information Registry, to assign roles and
responsibilities amongst international organizations
and stakeholders, and thereby facilitate the seventh
pillar of e‐Navigation, its “cement”, namely the
CommonMaritimeDataStructure(CDMS).
REFERENCES
NAV58/6,I.(2012).Integrationandpresentationofavailable
information in nautical graphical displays (including
MSI, AIS, charts, radar, etc. received via com‐
munication equipment, Report of the e‐Navigation
correspondencegroup,March2012.London:IMONAV.
NAV58/INF.4, I. (2012). Outcomes of a workshop held to
demonstrate the use of the S
‐100 framework data
standard and consider potential synergies between
e‐Navigation and the Marine Electronic Highway
project.London:IMO.
Norway.(2011).FeasibilityStudyintoUsingS‐100forNon
Hydrographic Marine Applications. Monaco: IHO
HSSC3.
Registry,I.(January2013).http:\\www.iho.int.calledat22.
January 2013 from http:\\registry.iho.int:
http://registry.iho.int/s100_gi_registry/home.php
S‐100,
IHO (January 2010). IHO Universal Hydrographic
DataModel.Monaco.
S‐99, IHO (January 2011). Operational Procedures for the
Organization and Management of the S‐100 Geospatial
InformationRegistry.
TC211, ISO (18. January 2013). http://www.isotc211.org/.
calledat22.January2013fromhttp://www.isotc211.org/.
