437
1 THECLASSIC“MONOLITHIC”EQUIPMENT
PARADIGM
The existing regulatory paradigm for bridge
equipment is a driving factor for the development
andimplementationofsystemsusedonthebridgesof
ships sailing under those regulations. The current
regimerequiresfullcertificationofthesystemsbythe
manufacturers. Those type approved systems need
furt
hercertificationpriortooperationaluse.Figure1
illustratestheconcept.
IMO Convention SOLAS VI and V requires that
Equipment
mustbe“typeapprovedbytheadministration”
IMO Performance Standards are the minimum
required
IEC provide harmonised tests for these
PerformanceStandards
The Concept of “Apps” as a Tool to Improve
Innovation in e-Navigation
M.Bergmann
J
eppesen,aBoeingCompany
ABSTRACT:Thecurrentsystemssupportingnavigationonboardofshipsarebuiltontheclassicconceptfor
equipment:Thesystemisdeveloped,tested,typeapproved,installedandfromthattimeonusedwithnoor
little modifications. Looking at other industries a regime of software and system maintenance has been
est
ablishedwhichallowsmorerapidupdates.ThedevelopmentintheITarenamovesmoretowardsmodular
approached,encapsulatingindividualcomponentsforeasierimplementationanddeliverywithlimitedsystem
wideimpact.Thiskeyconceptislatelyoftenreferredtoasthe“appconcept”.Thee‐Navigationdevelopment
asks for exactly tha
t: a way to improve innovation while ensuring system stability for the navigational
componentsusedbythenavigatoronthebridge.
Akeyaspectofthesuccessofnewsystemswillbetheabilitytoconvertdataintoasinformationasneededin
anygivensituation,creatingknowledgeforint
elligentdecisionsincreasingthecompetenceofanavigator.
Thepaperwillfocusonthefollowingtopics:
– Theclassic“monolithic”Equipmentparadigm
– ModernSystemArchitectureusingcomponentsand“apps”‐concept
– Advantagesofanapproachusingsituationaldriventoolenhancements
– The“app”‐conceptsupportingthesituationalcentricinformationpresentation
http://www.transnav.eu
the International Journal
on Marine Navigation
and Safety of Sea Transportation
Volume 9
Number 3
September 2015
DOI:10.12716/1001.09.03.17
438
Figure1. Current Type Approval Process – Michael
Bergmann,2015
For further clarification IMO has published the
IMOMSCCirc1221wheretheyspecifytheminimum
stepsrequired:
1 engineeringevaluation;
2 witnessing the manufacturing and testing
processes;
3 evaluatingthemanufacturingarrangements;and
4 issuing of a Type Approval Certificate generally
valid for not more than 5 years which may
be
subjecttoannualinspectionsorverificationofthe
manufacturer’s process after all the above‐
mentioned procedures have been satisfactorily
completed.
This certification process not only supports but
rather requires long development cycles of new
equipment which further leads to a reduction of
developmentspeed.Bringingnew innovation onthe
bridge to help improvenavigational safety and ship
operationalefficiencyisnotinthefocusatall.Assuch
the current bridge systems installed are often based
onanagedarchitecture.Thisbecomesevenclearerfor
those knowledgeable of Marine bridge equipment
lookatotherindustries,wheretheuseofstate
ofthe
artsystemsiscommon.Figure2and3showbuild‐in
systemsaswellastheuseofatabletdeviceinmodern
airlineaircraftcockpits.
Figure2.Integrated“ElectronicFlightBag”–Jeppesen,2012
Figure3.Tabletuseinaviation–Jeppesen,2013
Due to these circumstances current systems used
on bridges, especially if they are already installed
years ago without substantial updates, are often
based on the classic monolithic system architecture
whichwasstandardarchitectureadecadeortwoago.
Thesystemsarebuiltofindividualunits,whichmay
or may not be
integrated in a “bridge frame”. The
integrationof thosesystems is often justa matter of
exchanging of data streams, but do not really
integratethedifferentcomponents.
Duringthelastyearsthedevelopmentistakinga
change towards more integrated systems. In new
Integrated Navigation Systems (INS) you will
find
displayswithdifferentdisplaymodes,whereyoucan
switchfor example fromaradar display toaECDIS
displayorothers.Buteventhereduetotheregulatory
constraints mention above, you may find different
systems just sharing the display rather than really
integratedsystems.
2 MODERNSYSTEMARCHITECTUREUSING
COMPONENTSAND“APPS”‐CONCEPT
Inthelasttentofifteenyearsthe electronicindustry
hasmigratedfromthedescribedmonolithicapproach
to a component and application centric approach.
Computer hardware is used to run various
applications simultaneously. The systems use
multitasking to allow seamlessly switch between
applicationsand exchange. Sharing
ofdata layers or
utilization of same underlying database, even
exchangeofparametersiscommonpraxis.
Systems are built in kind of“layer concept”: The
hardware is the base component. Within this
“hardware layer”, the system software creates the
foundation. This software layer defines
communication protocols based on common
standards, which
allows applications, to interface
witheachotherandassuchbuildanadditionlayer,
which is using standardized “Application
ProgrammingInterfaces”(API)toexchangedataand
otherrelevantinformation.
This concept allows the development of different
“building blocks”, which can be group together to
performtherequestedfunctions.Italso
allowsamore
rapidupdating of systems,thedifferent components
can be updated and exchanged without interfering
439
withothercomponentsaslongasthecommunication
externaltotheupdatedfunctionstaysthesame.
But not only updating is easier to archive. Also
addingothercomponentsandfunctionsareeasierto
accomplish as additional building blocks can be
addedaslongastheystaywithintheirlayerand
are
compliantwiththestandardsandAPIstructureofthe
overallsystem.
Withinan integratedsystem therecanbe various
levels of encapsulation. Both adding new hardware
components as well as integrating new software
functions are possible if the component based
architectureisbuiltaccordingly.
This concept is not new
and is already used in
quiteafewexistingbridgesystems.Buttheconceptof
encapsulation and its use for component based type
approvalisnotnecessarilyenabled.
More recently the electronic industry moved
towardsan“App”architectureconceptinappropriate
areas.Everyoneknowstheappconceptin consumer
productslike
tablets,smartphonesorsimilardevices.
This is the logical next step of the component based
architecture. Towards the beginning of our decade
“ApplicationSoftware”wasintroduced.Theconcept
behind it is to develop software components, which
are executing certain functions within a shell
application.They cannotrunby themselves, but
run
within the parent software. Prominent examples in
thePCworldareMSWorldorMSExcel,whichrun
withinMS Office. The“parentapplication”provides
commonly used functions, like “safe todisk”, “copy
toclipboard”orcertainUIfunctionalitytoonlyname
three examples. At the beginning of our decade
the
abbreviation “App” was starting to get used,
especiallyinthemobilecomputingworld.
Thekeysuccessfactorinthisnewdevelopmentis
that the underlying parent application – the layer
around the Apps – are encapsulating the different
appsandassuchpreventoneappnegativelyaffecting
other apps.
If correctly implemented, mainly if the
parent application has a robust encapsulation
method,newappscaneasilybeingaddedorchanged
withoutaffectingtheuseofexistingsystems.
As a large number of functionality is already
handled by the parent application, for example
general user interface or touch screen functionality,
the
app development can focus on the specific
functionality. This concept highly increased the
innovationspeedinthiskindofarchitecture.
In industries like aviation this concept is
meanwhile well established. Since years a growing
number of airplanes are equipped with so call
“Electronic Flight Bags”. These systems are using
“App”
architecture to allow inclusion of additional
functionalitieswithreducedtypeapprovalneeds.
Figure4.TheElectronicFlightBag–Jeppesen,2012
With a focus on Human Centered Design this
systems seamlessly allow both switching between
apps as well as interchanging information between
those.
The implementation of the “App”‐concept
drastically increase the speed of innovation as
explainedabove. Continuouslynewmobile apps are
launchedwhich can be easily been downloadedand
immediately
beenused.
Eveninverystrictenvironments,liketheaviation
industry, the speed of innovation is very much
growing with the use of mobile devises and app
drivensystems.
Agoodstartingpointforthistypeofapproachin
the maritime domain is the current INS concept as
well as
the already established concept of multi‐
functionaldisplay.Herethemarineralreadyseespart
oftheproposedconceptasdifferentdisplaymodesor
betterdifferentapplicationscanbeswitched.Butthe
underlying concept is still build on different,
independentapplications.
Forgoodreasonse‐NavigationisbuildingonINS.
The proposed
app concept will ease the addition of
new functionalities while keeping user experience
similar to what an INS or multi‐functional display
useralreadyexperiencestoday.
In order to be able to gain benefit of the “App”‐
concept in the maritime environment the type
approvalconceptwillneedtobe
revisited.Asstated
above the current concept is limited the ability to
introduce new systems. As stated it is focused to
support the monolithic system architecture. Looking
into possibilities to certify hardware and parent
applications, ensuring necessary encapsulation
routines, may allow a new level of type approval
focused on certain apps
rather than always on full
systems.
If that is implemented in e‐Navigation the
maritime world can benefit from a large increase in
innovationspeed.Thissituationhasbeenrecognized
by those groups working on e‐Navigation, like the
IMOe‐NavigationCorrespondenceGroup,theIALA
eNavCommitteeorthe
CIRMe‐NavigationWorking
Group.
440
3 ADVANTAGESOFANAPPROACHUSING
SITUATIONALDRIVENTOOL
ENHANCEMENTS
Another development in recent years is the
integration of sensor and real‐time data to increase
awarenessofthesituationaroundthepersonutilizing
electronictools.Let’slookatthedilemmaweareinin
themaritimeworld:
We are
faced with growing complexity by ever
growingvesselsizesaswellastrafficdensity.
Whiletheshipsaregettinglargerandmoreships
are sailing around the world, the available
navigational space, especially in coastal areas, is
shrinking. Offshore Wind Parks are prohibiting
navigationincertainareas.Otherseaareas
areclosed
for navigation to protect endangered species or
environmentalsensibleareas.
Besidesthistheeconomicpressureinthemaritime
industryisrequiringanincreasedefficiencyofthesea
transport while the increasing utilization “just‐in‐
time”logisticsisputtingpressureonthemarinerfor
increasedETAaccuracy.
Theseareonly
someofthepressuresamarinerat
seaisfacedwith.Inordertocopewiththissituation,
sensors are installed on the ships and data is
deliveredtothebridge.Alsoexternalreal‐timeissend
to the bridges, for example AIS data. On‐shore data
service providers are
consolidating other useful real
time data and providing this to the mariners
frequentlybysendingsemirealtimedatastreams.
As the complexity grows the digesting of this
additionaldatagetmoreandmorechallenging.
Butthisisnotamaritimeonlyphenomenon.Same
istrueinaviationorincar
navigation.
The industry has started to develop tools to help
manage this situation. Most car navigation systems
nowadayshavefunctions,whichanalyzesensordata
and react automatically to provide the driver with
information as needed. The navigational system
automaticallyzoomsinoroutdependingonspeedif
thatfunctionis
enabled.Thesystemprovidescertain
informationinadvancedependingonspeed:
It notes the nextturn two kilometers aheadif on
highspeedorjusthundredmetersorlessbeforethe
turnonverylowspeed.
Inthetrainindustryautomaticbrakesactivationis
commonly used already for a long time
if a train is
passing a stopssign oris drivingtoo fast. The train
driverwillbeoverruledbysituationaldriventools.
Even more situational centric focus is used in
aviation,especiallyinmilitarycombatsystemswhere
decisions have to be made in factions of seconds
withoutachance
forthepilottocorrectlyanalyzeall
incomingdata.
Whilenavigationofashipisverymuchdifferent
thandrivingacaroratrainorflyinganaircraft,the
task is not necessarily easier. As such the lessons
learnedinotherindustrieshavealreadyinspiredthe
maritimemanufacturerstodevelop
situationalcentric
tools.
Thediscussiononcertainaspectsof e‐Navigation
contextismovinginthisdirectionaswell.The close
collaboration of active seafarer with engineers
knowing about the situations centric paradigm and
using the experience of other industries can create
tools, which breaks the vicious circle. Situational
centric
tools can provide the mariner with the
necessary information just as he or she needs it
without endangering decision making through data
overload.
Whileitisimportantforamarinertostayontop
of the decisions, situational centric tools will be of
essenceinfuturetoenablethemarinerdigesting
the
necessary data. Only then he will receive the
informationneededtomaketherightdecisions.
For further reference please see the article
“Integrated Data as backbone of 2‐Navigation” in
TransNav,Volumn7,Number3(seereferencelist)
4 THE“APP”‐CONCEPTSUPPORTINGTHE
SITUATIONALCENTRICINFORMATION
PRESENTATION
One
successfactorofthe “App”‐Concept,whichhas
helped that modern multi‐functional mobile devices
arealmostallutilizingthisconcept,isthefactthatthe
usersareeasilyabletousewellknowstaticdatabut
also situational centric information. Depending on
individual needs different apps can be used to
supportthespecificdesiresoftheuser.
Thefact that theusercan switchfromsituational
centric to situational agnostic apps seamlessly can
help the familiarizationwith increasingly situational
centricapps.
Figure 5 shows different apps in the aviation
“Electronic Flight Bag”. The pilot is in a position to
switch
rapidly between different situational centric
displays to better support the necessary speed in
decision making, but easily switch back to a static
displayifseenbenefitial.
Figure5. Aviation Apps and situational centric display –
Jeppesen,2013
Looking at the specific situation on a bridge as
described above there are benefits if tools are
available to the mariner which are providing
situationalcentricinformation.At the same time the
441
speed of navigation allows in certain situation the
mariner to reviewing data more closely than an
aircraftpilotcoulddothat.
The“App”‐conceptallowsforseamlesstransition
from one specific app to another. The parent
application for navigational can integrate both
situationalcentricappsfornavigationaswellas
apps
fordetailanalysis.Thiswillallowthemarinertouse
situational centric apps for routine work and switch
todetailappsifindoubt.
At the same time certain general functions could
be developed to reduce data density and increase
clarityofdisplayincriticalsituationssothenavigator
can focus on the most important task on hand by
receivingnecessaryadvice.
Underlying apps could also, automatically or
manualtriggered,exchangeshipdatawithshortside
services to allow “Vessel Traffic Centers” (VTS) to
provideeducatedguidance.
Besides apps on a single device, the usage of
different devices for different
usage is also common
and shows advantages in certain cases. In the
monolithic ship environment we have currently the
useofspecificdevicesareverycommon,actuallyhad
beenthere from the start. In theapp and situational
centric concept the devices could communicate with
eachotherbutalsoallow
simultaneoususetomonitor
different aspects of the current situation. In figure 6
anaviationhandheldnavigationaldeviceaswellasa
smart phone used to manage fatigue prevention is
shown.Whileuninterruptedviewofthenavigational
relevantinformationispossible,aquickcheckofthe
fatigue situation improve cockpit resource
managementiseasilypossible.
Figure6. Navigational and Fatigue prevention apps –
Jeppesen,2014
5 CONCLUSION
Maritime transportation is an increasingly complex
industry. For mariners the growing challenge is to
navigate safely and efficiently with larger ships in
areas with a growing number of ships, especially
largeships.
To be able to manage this challenges a growing
number of data streams from ship sensors, but
also
fromothershipsandfromshorearemadeavailableto
the bridge teams. e‐Navigation is intended to help
manage this flood of data. In addition the maritime
industryischangingatapacenotseenbeforeandthe
speedofchangeisdrasticallyincreasing.
Itisessentialthat
modernsystemsonthebridges
areaddressingbothconcerns.Theyneedtobeableto
handle and integrate a large number of data into
meaningful information. They also need to present
this information in a way so the mariner can easily
digest it and make meaningful decisions. Another
emergingrequirementis
thattheyneedtobeflexible
enoughtokeepupwiththegrowingspeedofchange
andinnovation.
But as this is not only a phenomenon of marine
transport, the electronic industry already developed
concepts to support rapid decision making.
Electronics have moved away from monolithic
architecture to component based
architecture and
towards an appstructure. Through encapsulation of
apps this enables easy integration of new functions
and features without interruption of the existing
runningsystems.
Thedevelopmentinelectronictoolsalsoismoving
towardsapplications,whichreactandadjustbasedon
the situation essential for any decision on hand.
Situational
centric system functionality can filter
incomingdataandintegratethemintoinformationas
neededintime.
e‐Navigation will benefit from this concepts and
certain test beds are already looking at this topic.
Besides the development of marine specific systems
takingfulladvantageoftheseconcepts,theregulatory
framework,mainly
performancestandards,updating
regimes and type approval concepts need to be
reviewedfornecessaryadaptionstosupportthis.
REFERENCES
IMO,2009,SOLAS(ConsolidatedEdition)
IMO,2008,MSC85/26Annex20
IMOCircularMSCCirc1221
IMONCSR1/9“DEVELOPMENTOFANE‐NAVIGATION
STRATEGYIMPLEMENTATIONPLAN”
IEC60945,FouthEdition2002‐08
IEC61023,Edition3.02007‐06
IEC61174ed3.0(2008‐09)
IEC61924‐2ed1.0(2012‐12)
IEC
62288ed2.0(2014‐07)
Bergmann M. (2013). Integrated Data as backbone of e‐
Navigationin: Weintrit, A. (2013). TransnavVolumn7,
Number3,September2013,ISSN2083‐6473
Ceruzzi, Paul E. (2000). A History of Modern Computing.
Cambridge,Mass.:MITPress.ISBN0‐262‐03255‐4.
Campbell‐Kelly,Martin;Aspray,
William(1996).Computer:
AHistoryoftheInformationMachine.NewYork:Basic
Books.ISBN0‐465‐02990‐6.
Frechette, Casey (2013‐04‐11).ʺWhat journalists need to
know about the difference between Web apps and
nativeappsʺ.Poynter.Retrieved2014‐12‐4
