453
1 INTRODUCTION
A necessity to keep time precisely has been
accompanying the humanity since ages, but precise
measurementoftimebecameavailabletopeoplesince
1946, when the atomic clock was invented. This
inventionmadeitpossibletodefinetheinternational
standardtimecalledInternationalAtomicTime(TAI
fr.Temps
AtomiqueInternational).Theatomicclocks
allowedtointroduceacommonforthewholeworld
time reference‐UTC (Universal Time Coordinated).
Precise and unified time keeping has become
especially important since the development of
computer systems and networks (Łukasik &
Nowakowski2017).
Technicalsystemsofashipi.e.:routeplanning
and
monitoring system, anti‐collision and detecting
system, radio communication system, voyage data
recording system, automation and alarm system,
steering control system, etc. commonly use
information and communications technology (ICT).
Timesynchronizationinallthesesubsystemsisvery
important, which results mostly from the need to
provide a unified time, among
others, when
exchangingdataorduringtheirarchiving.Oneofthe
most popular time references are GNSS (Global
Navigation Satellite System), which are commonly
usedtodetermine geographicalposition ofanobject
(Binetal.2015,Kolaretal.2012,Moussaetal.2010).
Becausepreciseobjectlocationrequiresaccurate
time
measurement,preciseatomicclocksbasedoncaesium
andrubidium standards are located on the satellites
(Jiang & Arias 2013). Data exchange with GNSS
receivers is usually carried out using the NMEA
protocol (National Marine Electronics Association)
and allows to obtain, among others, such data as
location,speedandtime(Shoab
etal.2013,Ciszewski
&Chrzan2011).Timesynchronizationinthenetwork
isperformedusingtheNTP(NetworkTimeProtocol)
Time Server Based on NMEA and SNTP Protocols
Z.Łukasik,W.Nowakowski&T.Ciszewski
KazimierzPulaskiUniversityofTechnologyandHumanitiesinRadom,Radom,Poland
ABSTRACT:Moderntechnicalshipsystemsveryoftenuseinformationandcommunicationtechnologies.One
ofthebasicrequirementsofthesesystemsisensuringtimesynchronizationthataimistocoordinateclocksof
alldevicesworkinginacomputernetwork.Thisrequirement
resultsfrom,amongothers,thenecessitytolog
eventswithaunifiedtimestamp.Toachievethisgoal,mostfrequentlyexpensivetimeserversareused.This
articlepresentsaneasymethodoftimesynchronization,whichcanserveasareserveoralternativesolutionto
themethodscurrentlyused.Thatiswhy
aproprietarysoftwarehasbeendeveloped,allowingtoexpandthe
functionalityofaPCsothatitcanoperateasatimeserver.Atimereferenceinproposedsolutionwouldbe
provided by a GPS receiver. The developed application allows, with the use of the NMEA protocol, to
synchronizethecurrent
timewiththeGPSreceiverandthen,withthehelpoftheSNTPprotocol,todistributeit
toallnetworkdevicesoperatingontheship.
http://www.transnav.eu
the International Journal
on Marine Navigation
and Safety of Sea Transportation
Volume 14
Number 2
June 2020
DOI:10.12716/1001.14.02.24
454
or SNTP (Simple Network Time Protocol) (Jie et al.
2017,Rybaczyk2005).
2 NMEAPROTOCOL
TheNationalMarineElectronicsAssociation(NMEA)
has developed a specification defining the interface
between marine electronic equipment.
Communication with GNSS receivers is defined
withinthisspecification.TwoversionsoftheNMEA
protocol are currently in
use, i.e.: NMEA 0183 and
NMEA 2000 (IEC 61162‐3). NMEA 2000 can be
consideredasthesuccessortoNMEA0183although
thesearenotcompatibleprotocols.Amongothersthe
differencesconcernsuchelementsas:
NMEA 2000 uses binary messages, unlike the
ASCIIserialcommunicationusedinNMEA0183,
NMEA2000allowsmulti‐talkerandmulti‐listener
configuration, whereas NMEA 0183 allows only
single‐talkerandmulti‐listenerconfiguration,
NMEA 2000 uses faster data transfer (250kbps),
whereasNMEA0183allowsonly38400bps.
Regardlesstheabovelimitations,theNMEA0183
protocol is still very popular (Coleman 2008). Its
current version is 4.11 and is dated on November
2018. It takes into consideration a dynamic
development of the GNSS systems, including: GPS,
GLONASS, GALILEO, BDS, QZSS and NAVIC
(Petrovetal.2016).Theproposedbytheauthorstime
synchronizationmethodisbasedontheNMEA0183
protocolwhich,
inthearticle,willbecalledNMEA.
TheNMEA protocoluses aplain text encoded in
ASCII.AllNMEAsentences(messages)startwiththe
character “$” or “!”, then there is a GP prefix
(indicating a GPS receiver) along with the message
ID, then data fields ended with a pair of
control
characters <CR><LF> occur. Optionally, characters
<CR><LF> could be prefixed by a checksum, which
allows to check for communication errors or
invalidatethereceiveddata.Sentencedatafieldsare
separated by commas and the checksum is prefixed
by anasterisk (ʺ*ʺ). The number of characters in
asingle
NMEA message, including beginning and
end delimiters, should not exceed 82. In the NMEA
standardthereisarulethatifaGPSreceiverdataare
unavailable the corresponding field remains blank,
howeverthedelimitingcommasarelefttospecifythe
field boundaries. NMEA supports many possible
messageIDs,whereonly
afewofthemareusedfor
time synchronization (Novick et al. 2018). A time
server application recognizes and interprets the
followingIDs:
GGA‐GlobalPositioningSystemFixedData
Table 1 contains the values for the following
example:
$GPGGA,135415.000,5115.6372,N,02107.9350,E,1,8,0.99
,203.6,M,40.6,M,,*5D
Table1.GGADataFormat
_______________________________________________
NameExampleUnit Description
_______________________________________________
MessageID$GPGGAGGAprotocolheader
UTCTime 135415.000hhmmss.sss
hhmmss.sss 5115.6372ddmm.mmmm
N/SIndicator NN=northorS=south
Longitude 02107.9350dddmm.mmmm
E/WIndicatorEE=eastorW=west
PositionFix 10‐Fixnotavailableor
Indicatorinvalid
1‐GPSSPSMode,fix
valid
2‐DifferentialGPS,
SPSMode,
fixvalid
3‐5‐Notsupported
6‐DeadReckoning
Mode,fixvalid
SatellitesUsed 8Range0to12
HDOP0.99HorizontalDilutionof
Precision
MSLAltitude 203.6 meters
UnitsMmeters
Geoid40.6 meters Geoid‐to‐ellipsoid
SeparationSeparation.
Ellipsoidaltitude=
MSLAltitude+Geoid
Separation.
UnitsMmeters
AgeofDiff.secNullfieldswhenDGPS
Corr.isnotused
Diff.Ref.
StationID
Checksum *5D
<CR><LF>Endofmessage
termination
_______________________________________________
An example of an Object Pascal function for
decodingaGGAmessageisshownbelow:
function DecodeGGA(GPS: PNmeaGPS; A: TStringList):
Boolean;
begin
Result := False;
GPS^.fError := False;
try
GPS^.fValid := (StrToInt(A[6]) <> 0);
if not GPS^.fValid then
exit;
GPS^.fSatCount := StrToInt(A[7]);
if GPS^.fSatCount > GPS^.fMaxSatCount then
GPS^.fMaxSatCount := GPS^.fSatCount;
except
GPS^.fError := True;
Result := False;
end;
end;
RMC‐Recommended Minimum Specific GNSS
Data
Table 2 contains the values for the following
example:
$GPRMC,135415.000,A,5115.6372,N,02107.9350,E,0.65,
192.12,231218,,,A*63
455
Table2.RMCDataFormat
_______________________________________________
NameExampleUnit Description
_______________________________________________
MessageID$GPRMCRMCprotocol
header
UTCTime 135415.000hhmmss.sss
StatusAA=datavalidor
V=datanotvalid
Latitude5115.6372ddmm.mmmm
N/SIndicator NN=northorS=south
Longitude 02107.9350dddmm.mmmm
E/WIndicatorEE=eastorW=west
SpeedOver 0.65knots
Ground
CourseOver 192.12 degreesTrue
Ground
Date231218ddmmyy
MagneticdegreesE=eastorW=west
Variation
East/WestE=east
Indicator
ModeAA=Autonomous,
D=DGPS,E=DR
Checksum *63
<CR><LF>Endofmessage
termination
_______________________________________________
An example of an Object Pascal function for
decodingaRMCsentenceisshownbelow:
function DecodeRMC(GPS: PNmeaGPS; A: TStringList):
Boolean;
begin
Result := True;
try
GPS^.fValid := (A[2] = 'A');
if not GPS^.fValid then
exit;
GPS^.fUTCTime := DateTimeNMEA(A[9], A[1]);
if Length(A[3]) = 11 then
begin
GPS^.fLatitude := Copy(A[3],1,2) + '° '
+ Copy(A[3],3,7) + ' ' + A[4];
end
else
GPS^.fLatitude := A[3] + ' ' + A[4];
if Length(A[5]) = 12 then
begin
GPS^.fLongitude := Copy(A[5],1,3) + '° '
+ Copy(A[5],4,7) + ' ' + A[6];
end
else
GPS^.fLongitude := A[5] + ' ' + A[6];
except
GPS^.fError := True;
Result := False;
end;
end;
Result := False;
end;
end;
3 NTPANDSNTPPROTOCOLS
WhendefiningtheNTPprotocolitwasassumedthat
itwouldbedesignedforprecisetimesynchronization
for a big amount of electronic devices working in a
network. Additionally, it was assumed that clock
frequency will be adjusted to reduce the time offset
gradually, without time
shifts or the necessity to
change the clock, and the whole procedure will not
overload the network and will be fully automated.
TheNTPprotocol also offers mechanisms protecting
fromanexternalinterferenceofcomputerclock’stime
change.Allthesehavecontributedtoabigpopularity
of the NTP protocol
among time synchronization
techniques. The protocol is not only used in typical
computer and network systems, but also in many
researchareasandcommunicationdevicesonboards
ofships,planesandevenspaceships.
The concept of time synchronization using NTP
protocol is based on the tree structure that includes
acertain
number of devices. Some of them are
referencetimesources,othersareresponsiblefortime
distribution,whileremainingareNTPclients(which
synchronizing their own clocks). Particular levels of
the NTP hierarchy are called Stratum. They indicate
on a distance between a given device and the
referenceclock.InStratum
0therearetimereferences,
i.e.: caesium atomic clocks, clocks with built‐in
rubidium generators or a GNSS systems. These
referenceclocksourcesareveryaccurateandreliable.
Devicesincluded in the next layer, calledStratum 1,
take time directly from reference clocks included in
Stratum 0 and are used for
time synchronization of
elementsinthelevelbelow.Similarly,elementsinthe
Stratum2playaroleofreferenceclockforcomputers
and local area net‐works in next layer, Stratum 3.
Therefore Stratum N components constitute the
reference clock for Stratum N+1 components. The
numberoflayersislimited
to16(Stratum0‐15),and
the number of devices in each layer is unlimited
(Rybaczyk2005).
Apart from the hierarchical structure, the NTP
protocolhasothercrucialattributes.Timestamps are
sentand received usingtheUser Datagram Protocol
(UDP)onportnumber123inpacketsofsize72bytes.
The
protocoliscapabletoadjustclock’stimeforeach
client, on the basis of calculating time differences in
relation to the reference clock. NTP is designed to
produce 3 results: clock offset, roundtrip delay and
dispersion.Clockoffsetrepresentsadifferenceoftime
value indicated by a local clock in
relation to the
reference clock. Roundtrip delay provides the
capability to launch a message to arrive at the
referenceclockataspecifiedtime.Dispersion,onthe
otherhand,representsamaximumerrorofthelocal
clock relative to the reference clock (Novick et al.
2018).TheNTPprotocolcanoperate
inafewmodes,
among others: symmetric active, symmetric passive,
client, server, broadcast. A detailed description of the
NTP protocol is included, among others, in book
(Mills2016)andspecification(Millsetal.2010).
A simplified version of the NTP protocol is the
SNTP (Simple Network Time Protocol)
protocol.
Adetailed specification of the SNTP protocol is
describedinthewidelyavailableRFC4330document
(Mills 2006). The principle of the SNTP protocol
operation is based on procedures found in the NTP
protocol (Jv & Gao 2008). SNTP operate in client‐
server model and uses the connectionless user
datagramprotocol(UDP)todistributereferenceclock
obtained from time servers to the SNTP clients. The
finalproductoftheSNTPprotocol,similarlyasinthe
caseofNTP,arethreevalues:clockoffset,roundtrip
delayanddispersion.ThearchitectureofSNTPisthe
same as in NTP, however, due to
a simplified
operation mode, there are differences between these
twoprotocols.AnexampleisanSNTPpacketheader,
whichdoesnothaveadditionalextensionfieldsused
formessageauthorization.Devicesthatdistributethe
456
reference time using the SNTP protocol should be
locatedintheStratum1ofthesubnet.Serversusing
SNTP technology can support a large number of
clients,buteachclientcanonlyconnecttooneserver.
It is recommended to place the clients in the higher
stratasothattheir
locationisattheendpositioninthe
hierarchyofaparticularsubnetIfoneofthedevicesis
synchronized with the use of the SNTP protocol all
theothers,operatinginthesamesubnet,shouldalso
besynchronizedwiththisprotocol.
The SNTP client can operate in three modes:
unicast, broadcast or manycast. In the unicast mode it
sends requests to a specific server for
synchronization. In the broadcast configuration, the
client acquires its time synchronization from data
broadcast by any SNTP server to the network
broadcast address. In the last, manycast , mode, the
client sends requests to
a designated broadcast
addressandwaitsforaresponsefromanyserverwith
an active manycast mode. Having received the first
response, the client connects only to the server that
hassentthemessage.Messagesfromotherserversare
then ignored, which means that next operations are
handledintheunicast
mode.Theclientrequestsinthe
unicast and manycast mode are sent in time gaps
depending on the client’s clock frequency
configurationandrequiredprecision.
4 TIMESERVER
Time server is an application that allows time
synchronization of devices working in a computer
network, in accordance to the reference clock
retrieved from the GNSS receiver. In the main
window the application shows the current,
synchronized time on two panels: one displays the
currenttimeinthehh‐mm‐ssformat,theothershows
thecurrentdateintheyyyy‐mm‐ddformat(Fig.1).
Figure1.“TimeServer”application’smainwindow.
During the first start of the application there is
aneedofinitialconfiguration.Amongtheothersthe
followingparametersshouldbeconfigured(Fig.2):
maximum time difference between GPS and PC
clock(0‐1000ms),
correctionofGPStime(‐2000ms/+2000ms),
serial port settings, which allow
proper
communicationbetweentheGPSreceiverandthe
computer(port,baud‐rate,flow‐control).
These parameters are set in the “General” tab in
“TimeServer”application.Additionally,ifwerequire
the time server functionality, theʺStart the SNTP
server automaticallyʺ option located in the “Server”
tab(Fig.3)shouldbe
enabled.
Ifthenecessaryconfigurationhasbeenmade,itis
possible to select theʺStartʺ button in the main
window. (Fig.1), which activates the reading of
NMEAmessagesfromtheGPSreceiver(Fig.4).
Figure2.Anexamplesettingofmain parametersin“Time
Server”.
Figure3.AnexampleconfigurationoftheSNTPserver.
The “Time Server” application recognizes and
interprets messages tagged with GGA and RMC
identifiers,including:
numberofvisiblesatellites,
UTCtime,
geographiccoordinates(latitudeandlongitude).
457
Figure4. Reading of NMEA messages from the GPS
receiver.
Additionally, the application creates logs
concerning particular actions, such as: starting and
stopping synchronization and error occurrences. All
messagesarepresentedinaseparatewindowthatcan
be activated with the “History” button in the main
window of the application. “Time Server” also has
advanced functionality in the field of self
‐diagnosis.
Forexample,it can check the activity oftime clients
which, according to the unicast mode, should send
requeststoserversatspecifiedtimeintervals(Fig.5).
Figure5.SNTPclientsactivitycontrol.
“TimeServer”alsocheckscommunicationwiththe
GPSreceiverandcontrolscorrectnessoftheantenna’s
settings. All errors in the server operation are
indicated to the operator in the form of displayed
messages and SNMP traps sent to the network
manager (Fig.6). This functionality is available after
correctconfigurationof
OIDMIBidentifiersandafter
settingtheIPaddressoftheSNMPmanager.
Figure6.SNMPtrapsconfiguration.
5 CONCLUSIONS
Time synchronization in all electronic subsystems of
the ship is very important, which results, among
others,fromtheneedtoregistereventswithaunified
timestamp.The paperpresentsaproposalofatime
synchronization method in accordance to the
referenceclock,whichcanbeatimeserver
equipped
withaGPSreceiver.Suchasolutioncanbeusedasan
alternativeformethodsbasedonexpensivehardware
servers. The proposed in this paper proprietary
software“TimeServer”allowsretrievingtimefroma
GPSreceiverandthensynchronizeittoothernetwork
devices of the ship that are
SNTP clients. “Time
Server”application,inordertoensurehighreliability,
has advanced functions of self‐diagnosis. The
monitoring involves the status of the GPS receiver
andcorrectnessofNMEAcommunication,aswellas
theactivityofselectedSNTPclients.Inaddition,itis
the possibility to cooperate with the SNMP
network
managerinmonitoringtheseparameters.
REFERENCES
Bin,L.,Guo,S.&Ma,S.2015.Designandimplementation
of time synchronization system based on GPS signal,
Advancesin IntelligentSystemsResearch, Volume124,
pp.2186‐2191
Ciszewski, T. & Chrzan, M. 2011. Wykorzystanie
technologii satelitarnej do precyzyjnego wyznaczania
położenia wad w szynach kolei dużych pr
ędkości,
Logistykanr6/2011,str.457‐464
Coleman,R.2008.Aself‐healingplug‐inparserforNMEA
streams,Proceedingsofthe5thInternationalConference
onInformationTechnology:NewGenerations,pp.1023‐
1027
Jiang, Z. & Arias, E.F. 2013. Use of the Global Navigation
Satellite Systems for the Construction
of the
International Time Reference UTC, Lecture Notes in
ElectricalEngineering,Volume245,pp.457‐466
Jie,X.,Liang,X.,Lian,D.,etal.2017.Researchonnetwork
timingsystembased onNTP,Proceedingsof201713th
IEEE International Conference on Electronic
Measurement & Instruments (ICEMI), Volume 1, pp.
356‐360
458
Jv,H.&Gao,X.2008.ApplicationofTimeSynchronization
System Based on SNTP in Digital Substation, China
International Conference on Electricity Distribution,
Volume1and2,pp.531‐534
Kolar, V., Thao, P. T. & Hrbac, R. 2012. Precise Time
Synchronization with GPS, International Scientific
ConferenceonElectricPowerEngineering,
pp.329‐331
Łukasik,Z.&Nowakowski,W.2017.Synchronizacjaczasu
w systemach sterowania ruchem kolejowym, TTS
TechnikaTransportuSzynowego,nr12/2017,str.254‐257
Mills,D.L.2016.ComputerNetworkTimeSynchronization:
TheNetworkTimeProtocolonEarthandinSpace,CRC
Press
Mills, D. L. 2006. Simple Network
Time Protocol (SNTP)
Version4forIPv4,IPv6andOSI,RFC4330
Mills,D. L.,Delaware D. &Martin J. 2010. Network Time
Protocol Version 4: Protocol and Algorithms
Specification,RFC5905
Moussa, A., Ali, A.S. & El‐Sheimy, N. 2010. The Effect of
TimeSynchronization onReal Time Implementation
of
Integrated GPS/INS Systems, Proceedings of the 2010
International Technical Meeting of the Institute of
Navigation‐ITM2010,pp.43‐48
Novick, A.N., Lombardi, M.A. & Franzen, K. 2018.
Improving packet synchronization in an NTP server,
Proceedingsofthe49thAnnualPreciseTimeandTime
IntervalSystemsandApplicationsMeeting,pp.
256‐260
Petrov, D., Melnik, S. & Hamalainen, T. 2016. Distributed
GNSS‐Based Time Synchronization and Applications,
International Conference on Ultra Modern
Telecommunications and Control Systems and
Workshops,pp.130‐134
Rybaczyk, P. 2005. Expert Network Time Protocol: An
ExperienceinTimewithNTP,Apress
Shoab,M.,Jain,K., Anulhaq,
M.,etal. 2013.Development
andImplementationofNMEAInterpreterforRealTime
GPS Data Logging, Proceedings of the 2013 3rd IEEE
International Advance Computing Conference (IACC),
pp.143‐14
