Tekst: Per André Horpen
I artikkelen om eksterne tidsservere konkluderte vi med at de beste løsningene gjerne koster mer enn de enkle.
Tøffere synkroniseringskrav
Nå skal vi se nærmere på hva man kan gjøre for å øke sikkerheten ytterligere på nettene. Hvordan man kan ta høyde for redundans, og også øke nøyaktigheten på klokkekildene.
For den som bare trenger å få synkronisert klokken på sin hjemme-pc, er ikke nanosekund-nøyaktighet noe tema. Men driver man med elektronisk handel, eller lagrer data som skal kunne brukes i en rettssak, kan mangel på sporbarhet og nøyaktighet være et problem.
For industrielle anlegg er et par sekunders nøyaktighet i mange tilfeller heller ikke godt nok. Det kan gi usikkerhet ved sporing av produksjonsdata, gjennomgang av feillogger eller når det kommer til å finne rotårsaken til for eksempel en automatisk nedstenging
Les også: Slik perfeksjonerer du påliteligheten i industrielle nettverk
Vanskelig å dokumentere
Når man benytter seg av eksterne klokkekilder, har man ingen kontroll på omgivelsene, synkroniseringsnøyaktighet eller påliteligheten til selve serveren. Dette betyr at serveren gir deg klokketid innenfor en gitt grad av nøyaktighet. Du kan derimot aldri dokumentere eller vite om serveren din faktisk går riktig. Den kan, enten den er hentet fra internett eller den blir routet videre fra en annen systemleverandør sitt intranett, ha vært offline fra GPS-en i en god stund.
Synk av flere anlegg
Jeg anbefaler å vurdere interne klokkekilder dersom man skal synkronisere flere lokasjoner. . Som nevnt tidligere har tid over internett sine fordeler og ulemper, og det å skulle sende klokke fra en lokasjon til en annen, eller å ha to lokasjoner som synkroniserer mot en NTP-pool-server, fører til unøyaktighet.
Det å ha en offline NTP-server stående på hver sin lokasjon er heller ikke tilrådelig. En offline server vil drifte, noe som igjen vil føre til unøyaktighet mellom de forskjellige lokasjonene.
Les også: Slik øker du påliteligheten i industrielle nettverk med funksjonaliteten i switchene
Presisjon med PTP
Det trengs bare et ørlite krav til nøyaktighet eller pålitelighet som grunn for å skaffe seg en klokkeserver. Dette er også veien å gå for å dokumentere at klokkekilden og klientene har absolutt tid.
PTP (IEEE1588) står for Precision Time Protocol. Når det kommer til nettverksbasert tid, lever den opp til navnet sitt. Men som sagt tidligere, nøyaktighet koster ofte litt ekstra.
Klokkemester
NTP-klienter bruker en algoritme for å lage et snitt av alle tilgjengelige servere, dette for å estimere korrekt tid. PTP, på den annen side, har mer avanserte algoritmer for å beregne seg frem til det som kalles Best Master Clock (BMC) hvis en klient har flere tilgjengelige kilder.
I tillegg har PTP bedre måter når det gjelder å beregne offset mer nøyaktig enn hva NTP-klientene har.
Les også: Slik kontrollerer du industrielle nettverk med virtuelle løsninger og multicast-teknologi
Beregner forsinkelsen
PTPv2, som er siste versjon av PTP protokollen, avhenger veldig av infrastrukturen mellom PTP grandmasteren (serveren) og PTP slaven.
Kort sagt kan man si at nettverket mellom master og slave hjelper til med å beregne reisetiden (offset). I PTPv2 er det flere måter å synkronisere slavene og å beregne forsinkelsene, men hovedkonseptet er at nettverket har egen hardware som står for tidsstempling (timestamping) av PTP-pakkene.
Tar transittiden
I en PTPv2-pakke som blir sendt fra grandmasteren, ligger det et korreksjonsfelt i headeren. Ved hardware tidsstempling på alle porter måler en switch hvor lenge en pakke er i transitt.
Det siste switchen gjør før den sender pakken videre, er å oppdatere korreksjonsfeltet med tiden som pakken har vært i switchen. Switchene gjør ingenting med selve klokkeslettet som ligger i pakken. Dette kalles Transparent Clock (TC) i PTPv2. Alle switchene som PTP-pakken passerer, fra master til slave, oppdaterer korreksjonsfeltet. Dette gir slaven et veldig nøyaktig tall, som beskriver reisetiden. Dermed vet slaven sin offset i forhold til masteren, og den kan stille sin klokke deretter, med høy presisjon.
For at dette skal virke, er det viktig at både master, slave, og alt i mellom, støtter denne standarden.
På slutten
Nå er vi kommet til det punktet at både PTP-grandmaster og alle switchene i nettverket støtter PTP. Både master og switcher støtter hardware-tidsstempling. Det er dedikert hardware som gjør tidsstempling, kalkulasjoner og oppdatering av korreksjonsfeltet for å ha høy grad av nøyaktighet hele veien fra master og frem til slaven.
For å klare å holde den høye tidsnøyaktigheten over målstreken, er det viktig at også slavene støtter PPv2. Her er det noen forskjeller mellom PTP-slaver og en pc med PTP-støtte.
En PTP-slave, i form av en egen enhet, er dedikert til PTP, og er ofte presis. Bruker man en pc eller server som har et «PTP Ready»-nettverkskort (Network Interface Card, NIC), vil man her få en forsinkelse som ikke står i stil til resten av nettverket.
Les også: Slik synkroniserer du tiden i industrielle nettverk
Potensielt tidsavvik
Et NIC som er «PTP Ready» klarer å lese og bruke korreksjonsfeltet på riktig måte, men slike nettverkskort har ikke egen hardware som støtter forsinkelsesberegninger. Slike kort vil lese og prosessere pakken, sende den videre til CPU-en, og her får man en forsinkelse som ikke blir beregnet inn i korreksjonsfeltet. Dette vil føre til et avvik.
Konklusjonen er derfor at det er vitalt å ha en slave eller nettverkskort (NIC) som støtter hardware tidsstempling for å holde nøyaktigheten fra A til Å i nettverket. Flere kort eller moduler (VME, PCI osv.) støtter hardware tidsstempling, og skriver også korrekt tid rett inn i registeret (registry), for å unngå forsinkelse som ikke blir kalkulert inn.
Pass på antennen
Om en har sin egen tidsserver, og uansett hvilken metode som velges for tidssynkronisering, er det et par ting man bør ha i bakhodet.
Det viktigste er antennen. Uavhengig om man har én eller ti tidsservere, så vil antennen alltid være den mest utsatte delen, grunnet klima og risikoen for lynnedslag. Noen leverandører har GPS-mottakeren bygget inn i antennen. Det gjør utskiftning mer kostbart, og når (ikke om, men når) antennen ryker, er du uten tidsserver frem til en ny er på plass.
Unngå to tidsservere
Når man ser på kostnadsbildet og stabiliteten på tidsserverne er det anbefalt å ha to antenner. Det bør også være passive enheter, det vil si standard antenner, slik at ikke selve tidsserveren blir påvirket av lynnedslag eller bortfall av antenner.
Hvordan NTP og PTP fungerer når det gjelder dette med flere servere, skrev vi om i forrige utgave. Dette er en av tingene man må se nærmere på når man legger opp topologien på tidsserverne.
En god tommelfingerregel er at man enten har kun én server, eller flere enn to. Har man bare to servere, og en av dem mister GPS-kontakten, har man to servere som kommer til å drifte, noe som gjør det vanskelig for NTP-klienten å vite hvem server man skal følge.
Vurdér to klokkereferanser
Har man tre servere og én faller bort, har NTP-klientene to servere som går likt og en som drifter. Dermed er det lett for klientene å vite hvilke servere de skal forholde seg til.
Det er én ting som ikke tidligere har blitt nevnt når det gjelder redundans, nemlig kilder for serverne. Selvsagt er sjansen for at hele GPS-systemet faller bort ganske små, men skal man ha seg et idiotsikkert system, bør man tenke på å ha klokkeservere som også er synkronisert mot en annen, ekstern kilde, for eksempel DCF77.
Les også: Slik synkroniserer du industrielle nettverk med interne eller offline tidsservere
