Moderne systemer, som transientovervåkingssystemer (TSM), samt relébeskyttelse og automasjonssystemer (RPA) som bruker en prosessbuss, krever høypresisjonstidssynkronisering innen 1 μs. Disse kravene er strengere enn for andre automasjonssystemer for transformatorstasjoner (1-2 ms). Samtidig, i dag, innenfor rammen av automasjonssystemer for kraftanlegg, blir Ethernet-nettverk utbredt, gjennom hvilke informasjonsutveksling utføres mellom SCADA-systemer og relébeskyttelsesenheter, samt mellom individuelle relébeskyttelsesenheter. Precision Time Protocol (PTP) er en tidssynkroniseringsprotokoll som opererer over et Ethernet-nettverk uten bruk av dedikerte kommunikasjonslinjer og kan gi nødvendig presisjonstidssynkronisering for relébeskyttelsesenheter, transientopptakere, prosessbusskoplere og andre enheter som krever høy presisjon tidssynkronisering.

Problemer med eksisterende tidssynkroniseringsprotokoller

Ved kraftanlegg har det vært utført tidssynkronisering av enheter i mange år. Spesielt er det nødvendig å sikre muligheten for å korrelere hendelser registrert av forskjellige enheter. Samtidig gir det største antallet tidssynkroniseringsmetoder nøyaktighet innen 1 ms. Med begynnelsen av introduksjonen av SMPR og relébeskyttelsessystemer som bruker en prosessbuss, er det behov for å sikre høyere nøyaktighet av enhetstidssynkronisering - innen 1 μs.

Det er to tilnærminger til å utføre tidssynkronisering av sekundære enheter:

• Bruke et uavhengig system som inkluderer dedikerte informasjonsoverføringskanaler og repeatere.
• Ved hjelp av et Ethernet-nettverk, gjennom hvilket applikasjonsinformasjon også utveksles mellom strømanleggsenheter.

De følgende avsnittene diskuterer de mest brukte metodene for tidssynkronisering, og fremhever fordeler og ulemper.

Bruk av uavhengige tidssynkroniseringssystemer

Historisk sett var tidssynkroniseringssystemer ved kraftanlegg avhengig av bruken av dedikerte kommunikasjonslinjer (koaksiale, tvunnet par, fiberoptiske kommunikasjonslinjer (FOCL)). To protokoller ble brukt:

• IRIG-B, som gir informasjon om klokkeslett og dato sammen med tidspulser.
• 1-PPS, gir presis tidssynkroniseringspuls uten klokkeslett og datoinformasjon.

Når du bruker disse protokollene, påvirker ikke datautveksling mellom relébeskyttelsesenheter og SCADA-systemet, samt mellom individuelle relébeskyttelsesenheter, synkroniseringsnøyaktigheten. Det er imidlertid verdt å merke seg at uavhengige systemer krever høye implementeringskostnader på grunn av behovet for å bruke ekstra kabelprodukter, rekkeklemmer, repeatere, etc. Det kreves også utvikling av et sett med passende teknisk dokumentasjon. Kostnadene kan være betydelige, spesielt ved implementering av tidssynkroniseringssystemer i høyspentanlegg.

Ris. 1 illustrerer bruken av IRIG-B-protokollen for synkronisering av enheter over tid og Ethernet-nettverket for å organisere informasjonsutveksling mellom enheter. I stedet for et Ethernet-nettverk kan det gis bruk av RS-485 kommunikasjonslinjer, som er typisk for eldre kraftanlegg.

Ris. 1. Illustrasjon av separasjonen av tidssynkroniserings- og datautvekslingssystemer i etm.

ProtokollIRIG– B

Den vanligste tidssynkroniseringsprotokollen som brukes ved kraftanlegg er IRIG-B-protokollen. Når du implementerer synkroniseringssystemer basert på denne protokollen, kreves bruk av dedikerte kommunikasjonslinjer. Protokollen kan fungere i ett av følgende formater: med overføring av informasjon i form av pulser over elektriske forbindelser (koaksialkabel eller tvunnet par) eller fiberoptiske lenker, eller med overføring av et modulert signal med en bærefrekvens på 1 kHz over en koaksialkabel. Over tid har IRIG-B-protokollen utvidet seg, hovedsakelig på grunn av bruken av IEEE-standarder knyttet til implementeringen av SMPR (IEEE Std 1344-1995, IEEE Std C37.118-2005 og IEEE Std C37.118.1-2011). Disse utvidelsene gir muligheten til å formidle informasjon om året, tidsforskyvning fra Coordinated Universal Time (UTC), sommertid og informasjonskvalitet. All denne informasjonen brukes avemenheter. Det umodulerte IRIG-B-signalet gjør at tidssynkroniseringsnøyaktighet kan oppnås i mikrosekundområdet, men de fleste klientenheter kan ikke gi nøyaktighet på mer enn 1-2 ms på grunn av deres tekniske egenskaper.

IRIG-B beskriver flere alternativer for informasjonsoverføringsformater. Imidlertid er egenskapene til ttil relébeskyttelse og automatiseringsenheter fra forskjellige produsenter forskjellige, noe som ikke tillater tidsserveren å bruke bare ett IRIG-B-tidskodeoverføringsformat. Blant de vanligste forskjellene er bruk av et modulert/umodulert signal, bruk av lokal eller universelt koordinert tid (UTC) som referanse osv.

Ulike implementeringer av IRIG-B-protokollen identifiseres med en tidskode. For eksempel:

• B003: Umodulert, ingen årsutvidelser/utvidelser i henhold til IEEE-standarder.
• B004: Umodulert, med årsutvidelser/utvidelser i henhold til IEEE-standarder.
• B124: med amplitudemodulasjon, med utvidelser for å overføre årsinformasjon / med utvidelser i henhold til IEEE-standarden.

Ris. 2 viser en sammenligning av umodulerte og modulerte signaler brukt av tidskodeformater (i henhold til IRIG Standard 200-04).

Ris. 2. IRIG-B modulert og umodulert signalform.

Innstillingene til klientenheter, for eksempel relébeskyttelsesenheter, må samsvare med innstillingene til masterklokken: når det gjelder universelt koordinert tid (UTC)/lokal tid, tidssone osv. Fleksibiliteten ved å sette opp relébeskyttelsesenheter varierer betydelig - selv når du bruker enheter fra samme produsent. Noen av relébeskyttelsesenhetene kan konfigureres til å akseptere nesten alle IRIG-B tidskodeformater, mange har ganske sterke begrensninger når det gjelder parameterisering.

Andre utfordringer som IRIG-B-protokollen innebærer inkludererstning, EMI-beskyttelse, elektrisk isolasjon og vedlikehold av kommunikasjonslinjer. Den tillatte belastningen på masterklokken varierer i området fra 18 til 150 mA, mens relébeskyttelsesenheter fra forskjellige produsenter har forskjellig forbruk (fra 5 mA til 10 mA). Dette kompliserer utformingen av tidssynkroniseringssystemer for et stort antall relébeskyttelsesenheter - for eksempel ved distribusjonsstasjoner (6,6 - 33 kV).

1- P.P.S.(en puls per sekund)

1-PPS (én puls per sekund) kan brukes for å gi ganske nøyaktig tidssynkronisering, men gir ikke astronomisk tidsinformasjon. I dag er dette tilstrekkelig til å implementere relébeskyttelsessystemer som bruker en prosessbuss, men tidsinformasjon vil sannsynligvis være nødvendig i fremtiden for tidsstemplingshendelser eller kryptografisk meldingsautentisering.

Bruken av denne metoden for tidssynkronisering er spesifisert i IEC 60044-8-standarden og er også introdusert i spesifikasjonen for implementering av et digitalt grensesnitt for instrumenttransformatorer (kjent som IEC 61850-9-2LE). IEC 61869-9-standarden, som for tiden utvikles, åpner også for muligheten for å bruke denne metoden for å synkronisere enheter i tid over en dedikert fiberoptisk kommunikasjonslinje.

Ris. 3 illustrerer 1PPS-pulskravene. Tiden det tar før signalet endres fra et 10 % effektnivå til et 90 % effektnivå (og omvendt) ( tf) signal bør ikke overstige 200 ns. Levetiden til signalet ved et nivå på mer enn 50 % effekt ( th) må være i området fra 10 µs til 500 ms.

Ris. 3. Grafisk representasjon av 1-PPS-signalet.

1-PPS krever et dedikert nettverk for signaldistribusjon. Enten en elektrisk kommunikasjonslinje (koaksial/twisted pair) eller en fiberoptisk linje (multi-mode/single-mode) kan brukes som et fysisk dataoverføringsmedium.

Synkroniseringsforsinkelse

Utbredelse av IRIG-B- og 1-PPS-signaler er mye lettere å organisere gjennom elektriske koblinger enn gjennom fiberoptiske koblinger, siden flerpunktsforbindelser kan gis under hensyntagen til tillatt belastning på masterklokken, men dette kan føre til en økning i potensialet mellom skap. Bruken av fiberoptiske linjer sikrer galvanisk isolasjon og eliminerer påvirkningen av interferens, men i dette tilfellet er det nødvendig med bruk av spesielle repeatere for å distribuere signalet til hver av relébeskyttelsesenhetene til kraftanlegget. Spesielt krever IEC 61850-9-2LE bruk av fiberoptiske lenker for å overføre 1-PPS-signalet. Dette krever i sin tur bruk av enten en klokke med flere utganger eller en splitter for å overføre signalet til mer enn én prosessbusskopler.

Signalutbredelsesforsinkelsen gjennom elektriske forbindelser og fiberoptiske koblinger er omtrent 5 ns per meter. Den resulterende verdien kan være ganske stor over lange avstander og kan i sin tur kreve latenskompensasjon på klientenheter. IEC 61850-9-2LE setter signtil 2 µs - hvis denne verdien overskrides, kreves kompensasjon. En tilkobling på ca 400 m vil gi en slik forsinkelse, og i mange høyspentstasjoner er ikke slike avstander grensen. Kompensasjon er en manuell konfigurasjonsprosess, der det er nødvendig å nøyaktig ta hensyn til signalutbredelsesforsinkelsen, ikke bare langs kommunikasjonslinjen, men også gjennom repeaterne som brukes. En mer detaljert studie av utbredelsesforsinkelsene til synkroniseringssignaler over 1-PPS, IRIG-B og PTP-protokollene er gitt i.

Tidssynkronisering over nettverketEthernet

Ethernet-nettverk, som i økende grad brukes i dag innenemer, kan også brukes til å overføre tidssynkroniseringssignaler. Dette eliminerer behovet for å legge dedikerte kommunikasjonslinjer, men krever relébeskyttelse og automatiseringsenheter, strømmålerenheter og andre sekundære enheter for å støtte spesielle protokoller.

De to mest brukte tidssynkroniseringsprotokollene er Network Time Protocol (NTP) og Precision Time Protocol (PTP). Begge protokollene, når de brukes i understasjoner, fungerer ved å utveksle meldinger over et Ethernet-nettverk. NTP- og PTP-protokollene gir kompensasjon for tidsforsinkelser i overføringen av synkroniseringsmeldinger gjennom toveis informasjonsutveksling. NTP-protokollen er en mer vanlig løsning enn PTP-protokollen, men høyere nøyaktighet sikres ved bruk av sistnevnte gjennom bruk av spesiell maskinvare. I fig. Figur 4 illustrerer en nettverkstopologi der både NTP-reservasjonsprotokollen og PTP-reservasjonsprotokollen kan brukes.

Den fungerende mekanismen til begge protokollene tillater tilstedeværelsen av flere masterklokker, noe som øker påliteligheten til tidssynkroniseringssystemet på et strømanlegg. I tillegg tillater tilstedeværelsen av flere masterklokker service på en av dem uten å ta hele systemet ut av drift.

ProtokollNTP

I løpet av de siste årene har NTP-protokollen vært mye brukt innen energianlegg. Ved bruk av kommersielt tilgjengelige tidsservere og klienter (for eksempel relébeskyttelsesenheter) som støtter denne kommunikasjonsprotokollen, er tidssynkroniseringsnøyaktighet i området fra 1 til 4 ms oppnåelig. En av betingelsene for å sikre slik nøyaktighet er imidlertid utviklingen av riktig topologi til Ethernet-lokalnettverket, som sikrer konsistens og konsistens i tidspunktene for forplantning av tidssynkroniseringsmeldinger fra klienten til masteren og i motsatt retning.

En betydelig fordel med NTP-protokollen fremfor IRIG-B er at tiden sendes i UTC-format. Dette tilfredsstiller standarder som IEC 61850 og IEEE 1815 (DNP), som krever overføring av hendelsestidsstempler i UTC-format. Hvis det er nødvendig å vise lokal tid på displayet til relébeskyttelsesenheten, kreves manuell innstilling av tidssonen, tatt i betraktning den tilsvarende overgangen til sommertid. NTP-protokollen lar flere tidsservere brukes samtidig av samme klient for mer nøyaktig og pålitelig tidssynkronisering. Denne protokollen gir imidlertid ikke mikrosekunders synkroniseringsnøyaktighet, noe som kreves for SMPR og grensesnittenheter med IEC 61850-9-2 prosessbussen.

PTP-protokoll

IEEE Std 1588-2008 definerer en andre versjon av PTP-protokollen, kjent som PTPv2 eller 1588v2. Denne protokollen gir svært nøyaktig tidssynkronisering, som oppnås ved å fikse tidsstemplene til PTP-synkroniseringsmeldinger på Ethernet-grensesnitt på maskinvarenivå. Ved å bruke disse dataene kan du ta hensyn til tidspunktene da synkroniseringsmeldinger distribueres over nettverket og behandles av tidsservere og klienter. Prosedyren for å sette tidsstempler på maskinvarenivå påvirker ikke funksjonen til andre kommunikasjonsprotokoller som finnes i det aktuelle Ethernet-nettverket, derfor kan den samme porten brukes til å overføre data i samsvar med protokollene til IEC 61850, DNP3, IEC 60870 -5-104, Modbus/IP og andre kommunikasjonsprotokoller. Evnen til å tidsstemple på maskinvarenivå fører til en betydelig økning i kostnadene for Ethernet-svitsjer. Når det gjelder støtte for PTP-protokollen i relébeskyttelsesenheter, er det bare de siste modifikasjonene av enheter fra noen produsenter som støtter denne protokollen, noen ganger er den bare tilgjengelig som et alternativ.

PTP-protokollen gjør det mulig å ha flere enheter på nettverket som kan fungere som tidsservere; i dette tilfellet antas det at de alle deltar i å stemme seg imellom for å velge den mest nøyaktige klokken - stormesterklokken. Hvis en stormesterklokke plutselig svikter eller ytelsen forringes, kan rollen som stormesterklokke overtas av andre klokker som krever denne rollen. Hvor lang tid denne prosedyren tar kan variere, men hvis PTP-protokollinnstillingene (også kalt en profil) er optimalisert for bruk i kraftproduksjonsanlegg, tar det ikke mer enn 5 sekunder.

Introduksjon til PTP

PTP-protokollen er ekstremt fleksibel og kan brukes i en rekke applikasjoner der tidssynkronisering er nødvendig, noe som gir nøyaktighet ned til 10 ns.

Høyere nøyaktighet ble oppnåelig med bruken av den andre versjonen av protokollen, som introduserte konseptet med gjennomsiktige klokker, hvis rolle utføres av Ethernet-svitsjer. Transparente klokker måler tiden det tar for synkroniseringsmeldinger å passere gjennom brytere, som kan variere avhengig av nettverkets trafikkbelastning. Informasjon om den målte tiden overføres til andre enheter langs banen til synkroniseringsmeldingen. Denne mekanismen lar deg oppnå høy nøyaktighet av tidssynkronisering innenfor et lokalt Ethernet-nettverk. Bruken av transparente klokker betyr at PTP-sikke trenger å prioriteres i forhold til annen trafikk på nettverket, noe som forenkler nettverksdesignprosessen og konfigurerer nettverksutstyr.

Terminologi

IEEE Std 1588-2008 definerer flere termer som gjelder for systemer som opererer under PTP-protokollen. Hovedvilkårene er:

• Stormesterklokke– en klokke som er hovedkilden til tidsdata ved synkronisering i henhold til PTP-protokollen, som som regel er utstyrt med en innebygd GPS (eller annet system) signalmottaker.
• Mesterklokke– en klokke som er en kilde til tidsdata som andre klokker i nettverket synkroniseres med.
• Slave klokke– sluttenhet som synkroniserer ved hjelp av PTP-protokollen; dette kan være en relébeskyttelsesenhet med innebygd støtte for PTP-protokollen eller en omformer som på den ene siden mottar informasjon i PTP-protokollformatet, og på den andre genererer data i IRIG-B- eller 1-PPS-protokollformatet .
• Gjennomsiktig klokke– en Ethernet-svitsj som måler tiden det tar før en synkroniseringsmelding passerer gjennom seg selv og gir den målte verdien til klokken som mottar synkroniseringsmeldingen neste gang.
• Grensetimer– en klokke som er utstyrt med flere PTP-porter og kan fungere som en masterklokke; for eksempel kan de være slaver i forhold til kilder på høyere nivå av tidssignaler og fungere som master i forhold til enheter på lavere nivå.

Nettverket må ha minst én stormesterklokke og én slaveklokke. Men i mange tilfeller, gitt behovet for å kombinere mange enheter i ett nettverk, vil det være nødvendig å bruke brytere, som i det enkleste tilfellet vil fungere som en gjennomsiktig klokke. De kan også fungere som grenseklokker, som i noen tilfeller gir mulighet for høyere presisjon tidssynkronisering (om dette er sant eller ikke avhenger av den spesifikke produsenten). Ris. 5 illustrerer et kompleks hvor tidssynkronisering implementeres i henhold til PTP-protokollen. I dette eksemplet er stormesterklokken i stand til å motta informasjon om nøyaktig tid, ikke bare fra det globale posisjoneringssystemet, men også fra det eksterne nettverket via PTP-protokollen. Den spesifiserte løsningen er implementert for å sikkerhetskopiere feilen til tidssignalmottakeren eller de tilsvarende eksterne koblingskretsene. Ved en overgang til bruk av presise tidssignaler fra et eksternt nettverk slutter klokken å være en stormesterklokke og inntar rollen som grenseklokke. Det avbildede komplekset bruker også to typer slaveklokker: relébeskyttelsesenheter med innebygd PTP-støtte og omformere til IRIG-B- og 1-PPS-formater, som gir informasjon om nøyaktig tidspunkt for sluttenheter som ikke støtter PTP-protokollen.

Drift i ett- og to-trinns modus

Driftsprinsippet til PTP-protokollen er basert på det faktum at overføringstiden for en synkroniseringsmelding av typen Sync er nøyaktig kjent (det er denne meldingen som formidler tidsinformasjon) og tidspunktet for mottak av denne meldingen på Ethernet-grensesnittet til slaveklokken. Det nøyaktige tidspunktet for overføring av en gitt melding er ikke kjent før etter at den er sendt. PTP-aktiverte Ethernet-grensesnitt gir tidsstempling av meldinger på maskinvarenivå, og overfører deretter denne informasjonen til stormesterklokkens sentrale prosessor. Etter dette genereres en oppfølgingsmelding, som overfører dette eksakte tidsstemplet for synkroniseringsmeldingen til alle slaveenheter. I dette tilfellet supplerer den transparente klokken denne meldingen med informasjon om forsinkelsen i overføringen av denne meldingen over nettverket (summen av kanalforsinkelsen og tidspunktet for meldingsomdirigering). Bruken av en kombinasjon av synkroniserings- og oppfølgingsmeldinger kalles PTP-protokollens totrinnsmodus.

Den andre versjonen av PTP-protokollen (PTPv2) introduserte muligheten til å endre innholdet i en PTP-melding under overføring på maskinvarenivå. Når denne metoden implementeres, elimineres behovet for oppfølgingsmeldinger. Denne driftsmodusen til PTP-protokollen kalles enkelttrinn. Grandmaster-klokker med støtte for denne modusen sender meldinger av synkroniseringstype med informasjon om det nøyaktige tidspunktet for dannelsen, transparente klokker estimerer forsinkelsene i overføringen av meldinger av denne typen (over nettverket og gjennom seg selv) og inkluderer data om målte forsinkelser i samme synkroniseringstype meldinger i stedet for å inkludere disse dataene i oppfølgingsmeldinger. Denne driftsmodusen forutsetter en lavere informasjonsbelastning på nettverket, men krever bruk av mer komplekse og kostbare enheter.

Komplekser som opererer under vilkårene i PTP-protokollen kan inkludere stormesterklokker som er i stand til å operere i ett- og totrinnsmodus. I slike komplekser må slaveklokkene være i stand til å ta hensyn til informasjon om de resulterende forsinkelsene i overføringen av synkroniseringsmeldinger direkte fra disse meldingene generert av enkelt-trinns transparente klokker, samt fra oppfølgingsmeldinger generert av to-trinns transparente klokker.

ProfilPTP for elkraftindustrien (Makt Profil)

PTP-protokollstandarden involverer flere av dens modifikasjoner, som er gjensidig utelukkende. Den andre versjonen av PTP-protokollen (PTPv2) introduserer konseptet med profiler, som begrenser verdiene til en rekke parametere og krever bruk av spesifikke aspekter av protokollen for forskjellige applikasjoner.

Strømprofilen er beskrevet i IEEE Std C37.238-2011, som definerer en rekke parametere for å sikre tidssynkroniseringsnøyaktighet innenfor 1 μs for topologier som er mest vanlige iemer. Denne profilen definerer også Management Information Base (MIB) for SNMP-protokollen, som gir muligheten til å overvåke nøkkelenhetsparametere ved bruk av standard overvåkingsprogrammer. Takket være dette blir det mulig å overvåke funksjonen til tidssynkroniseringssystemet i sanntid med dannelse av alarmer i tilfelle nødsituasjoner.

Effektprofilen krever at feilene introdusert av hver enkelt transparent klokke ikke skal overstige 50 ns. Dette er nødvendig for å sikre synkroniseringsnøyaktighet på ikke mer enn 1 µs når du organiserer en lokal nettverkstopologi som inkluderer 16 Ethernet-svitsjer (for eksempel som en del av en ringtopologi). I dette tilfellet er den tillatte feilen for GPS-klokker satt til 200 ns.

PTP-profilen krever bruk av en gjennomsiktig klokke som støtter en peer-to-peer-mekanisme for å bestemme koblingsforsinkelser, og at alle PTP-meldinger sendes på koblingslaget i multicast-modus. En peer-to-peer-latensmekanisme betyr at hver PTP-aktivert enhet utveksler meldinger med tilstøtende enheter for å måle koblingsforsinkelsene for meldingsoverføring mellom dem. Den totale tidsforsinkelsen i overføringen av synkroniseringsmeldinger er definert som summen av kanalforsinkelser og forsinkelser i behandling av meldinger av transparente klokker som oppstår langs meldingsforplantningsruten fra stormesteren til slaveklokkene. Denne driftsmodusen har to fordeler:

1. Nettverkstrafikken som sees av Grandmaster Clock øker ikke ettersom nettverket utvides. Stormesterklokken utveksler meldinger kun med den tilstøtende Ethernet-svitsjen (transparent eller kantklokke).
2. Forsinkelser i meldingsoverføring kompenseres automatisk hvis hovedkommunikasjonsruten svikter og en reserverute er aktivert. Kanalforsinkelser måles på hver kommunikasjonslinje, inkludert de som kan blokkeres av protokoller fra STP-familien.

Ikke alle produsenter av PTP-aktivert utstyr støtter strømforsyningsprofilen, men det er verdt å merke seg at standardprofilen beskrevet i vedlegg J.4 til standarden eller IEEE Std 1588-2008 kan gi den nødvendige nøyaktigheten hvis systemet er riktig konfigurert. Når du bruker en annen profil enn strømforsyningsprofilen, er det ingen garanti for at informasjon som kreves for enheter for nettstasjonsautomatisering, som tidsfeil og gjeldende tidssone, kan gjøres tilgjengelig for kundene. Overholdelse av de påkrevde ytelsesegenskapene til protokollen er heller ikke garantert (vedlegg J.4 spesifiserer ikke ytelseskrav).

Grenseklokker kan brukes til å konvertere mellom ulike profiler. For eksempel kan grenseklokken gi konvertering mellom telekommunikasjonsprofilen (ITU-T Rec. G.82651.1 Telecommunications Profile) og strømprofilen (IEEE Std C37.238 Power Profile). Å motta informasjon om nøyaktig klokkeslett fra et eksternt nettverk via en telekommunikasjonsprofil kan gi backup for feilen i GPS-signalmottakeren på stormesterklokken. I dette tilfellet, som nevnt tidligere, vil de ta på seg rollen som en grenseklokke.

ProtokollmeldingstyperPTP

PTP-protokollprofilen for elkraftindustrien sørger for bruk av 4 meldingsklasser:

1. Meldinger somSynkroniser . Meldingsdataene inkluderer tidsinformasjon overført fra hovedklokken i antall sekunder og nanosekundersformater siden midnatt 1. januar 1970.
2. Meldinger somLikemann Forsinkelse. Disse meldingene utveksles mellom tilstøtende enheter for å estimere forplantningsforsinkelsen til synkroniseringsmeldinger langs kommunikasjonsforbindelsen mellom dem. To eller tre forskjellige meldingstyper brukes til å måle latens, avhengig av om ett- eller to-trinns drift brukes.
3. Meldinger somFølg Opp. Meldingsdataene inkluderer det eksakte tidsstempelet for den forrige synkroniseringsmeldingen som ble sendt, samt en justeringsverdi. Korreksjonsverdien er summen av meldingsbehandlingstidene av den transparente klokken og kanalforsinkelsene langs veien for meldingsforplantning mellom stormesterklokken og et gitt nettverkspunkt. Representert i formatet nanosekunder og brøkdeler av nanosekunder.
4. Meldinger somKunngjøre. Overføringen av disse meldingene utføres av stormesterklokken, som gir data om feilen i driften av kilden (for eksempel en GPS-mottaker) og annen tjenesteinformasjon for PTP-protokollen.

Ris. Figurene 6-8 illustrerer hvordan meldinger utveksles på et lite nettverk ved hjelp av en klokke som opererer i totrinnsmodus (siden de fleste enheter ikke støtter ett-trinns drift). Synkroniseringsmeldinger overføres uendret av den gjennomsiktige klokken. ten– tidsangivelse på stormesterklokken. Kunngjøringsmeldinger overføres også på samme måte.

Meldingstype Likemann Forsinkelse (Likemann Forsinkelse Be om, Likemann Forsinkelse Respons og Likemann Forsinkelse Følg Opp) utføres kun mellom enheter i nærheten.

Ris. 7. Peer Delay-meldinger utveksles kun mellom naboenheter.

Hver transparent klokke bestemmer kanalforsinkelsen for meldingsoverføring mellom seg selv og tilstøtende enheter. Når synkroniseringsmeldinger passerer gjennom gjennomsiktige klokker, beregner de en lokal korreksjonsverdi ved å summere kanalforsinkelsen langs ruten for meldingens ankomst og tiden det tar for synkroniseringsmeldingen å passere gjennom dem. Denne lokalt beregnede korreksjonsverdien legges så til korreksjonsverdien til den tilsvarende innkommende oppfølgingsmeldingen. Når en oppfølgingsmelding kommer til slaveklokken for å korrigere verdien, blir kanalforsinkelsesverdien bestemt av dem lagt til. Den resulterende korreksjonsverdien vil være den totale tiden det tok før en synkroniseringsmelding ble sendt over nettverket fra masteren til slaveenheten.

Siden hvert nettverkselement langs forplantningsveien til en melding av Sync-type bidrar til denne totale tiden, sikrer node-til-node-mekanismen for måling av kanalforsinkelser for strømprofilen, beskrevet ovenfor, riktig funksjon av protokollen under forhold med endre nettverkstopologi.

Det er viktig å merke seg at selv om oppfølgingsmeldinger kan se identiske ut, vil de være forskjellige på hvert punkt på nettverket. Den gjennomsiktige klokken endrer innholdet i disse meldingene, og holder adressen til stormesterklokken uendret.

I fig. 8 tb– det faktiske tidspunktet for dannelsen av synkroniseringsmeldingen av stormesterklokken, som er nær i verdi, men ikke identisk med tiden ten. Hver slaveklokke registrerer øyeblikket for mottak av synkroniseringsmeldinger, og ved å registrere tidspunktet for overføring av meldinger gjennom den transparente klokken og kanalforsinkelser, hvor summen er en korreksjonsverdi, kan den ta hensyn til variable forsinkelser i overføringen av synkroniseringsmeldinger .

Ris. 8. Oppfølgingsmeldinger inneholder en korreksjonsverdi som oppdateres med hver transparente klokke langs forplantningsbanen.

Fordeler og ulemper ved å bruke en PTP-profil for kraftbransjen

Å bruke PTP Power Profile gir en rekke fordeler:

• Nøyaktigheten av tidssynkronisering avhenger ikke av volumet av nettverkstrafikk. Når nettverksutstyr er overbelastet, går ikke PTP-meldinger tapt. Dette lar deg bruke den samme lokale nettverksinfrastrukturen når du implementerer SMPR- og relébeskyttelsessystemer både ved bruk av prosessbussen i henhold til IEC 61850-9-2, og bruk av stasjonsbussen i henhold til IEC 61850-8-1 (med GOOSE-trafikk og/eller MMS), samt komplekser som opererer på grunnlag av andre kommunikasjonsprotokoller (DNP3, etc.).
• PTP-meldingshastigheten er optimalisert for å gi mikrosekunders timing-nøyaktighet uten å overbelaste nettverket eller kreve komplekse slaveklokker.
• Både optiske og elektriske (twisted pair) kommunikasjonslinjer kan brukes som et fysisk dataoverføringsmedium - alt avhenger av konfigurasjonen av de valgte bryterne.
• Et enkelttidsreferansesystem brukes, så det er ingen problemer med å stille inn enhetene til Coordinated Universal Time (UTC)/lokal tid. Alle enheter som støtter Electrical Utilities-profilen bruker International Atomic Time (TAI), som ikke har problemer med hoppsekunder og sommertid.
• Strømprofilen gir overføring av lokal tidsforskyvning, så det er ikke nødvendig å konfigurere lokal tid på relébeskyttelsesenheter. I tillegg kan eventuelle endringer angående overgang til sommertid gjøres på stormesterklokken uten å endre innstillingene til relébeskyttelsesanordningene. Denne mekanismen er definert av IEEE 1588-standarden, så den er også kompatibel med enheter som ikke støtter PTP-profilen for strømforsyninger.
• Det kan være mulig å bruke reservestormesterklokker med automatisk veksling til dem ved brudd i kommunikasjonen med eksisterende stormesterklokke eller hvis ytelsen blir dårligere.
• For å øke påliteligheten til informasjonsutveksling mellom enheter som støtter PTP-protokollen, kan protokoller som Rapid Spanning Tree Protocol (RSTP), Parallel Redundancy Protocol (PRP) og High-availability Seamless Ring (HSR) brukes.
• Nettverk kan skaleres uten ekstra belastning på stormesterklokken.
• Forsinkelser i utbredelsen av tidssynkroniseringsmeldinger over lange kommunikasjonslinjer blir automatisk kompensert for, og eliminerer behovet for å justere prosessbussgrensesnittenheter og transientopptakere.

Mer detaljert informasjon om testing av hastigheten for å bytte til bruk av en reservestormesterklokke er gitt i. Materialet tar for seg scenarier som tap av et Ethernet-nettverkssegment med en gyldig stormesterklokke og tap av et GPS-signal.

PTP-protokollen er en ganske kompleks protokoll, og for å sikre nødvendig tidssynkroniseringsnøyaktighet må det tas hensyn til en rekke punkter. I tillegg oppstår nye risikoer innenfor automatiseringssystemet til et kraftanlegg. Følgende aspekter ved bruk av PTP-protokollen bør bemerkes:

• Ethernet-svitsjer må støtte verktøyets PTP-profil med evnen til å signalisere uakseptable ytelsesfeil. Ikke alle transparente klokker med PTP-støtte (og spesielt de med peer-to-peer-støtte for kanalforsinkelsesdeteksjon) er i stand til å gi en feil på mindre enn 50 ns. Dessuten er ikke alle gjennomsiktige klokker i stand til å vurdere de resulterende feilene.
• Det er et begrenset antall relébeskyttelsesenheter på markedet som støtter PTP-profilen for kraftindustrien, men situasjonen er i bedring. En rekke produsenter har produsert relébeskyttelsesenheter med PTP-støtte siden 2013, men protokollstøtte kan være valgfri, og behovet for det bestemmes ved bestilling.
• Ikke alle master- eller slaveklokker (inkludert omformere til andre tidssynkroniseringsprotokoller) er designet for bruk i høyspenttransformatorstasjoner, selv om de kan støtte PTP-profilen. Utstyr må testes for immunitet mot elektromagnetisk interferens i henhold til spesifiserte alvorlighetsnivåer.
• Tidssynkronisering er av stor betydning for SMPR og IEC 61850-9-2 prosessbussen. Det er viktig at kun spesialtrent personell har mulighet til å endre konfigurasjonen av PTP-aktiverte enheter (enten ved hjelp av spesielle konfiguratorer, eller ved hjelp av en webserver, eller via SNMP-protokollen). Hvis PTP-aktiverte enheter tillater frontpanelkonfigurasjon, må tilgangen være passordbegrenset.
• Det finnes ulike PTP-protokollprofiler, hver optimalisert for spesifikke applikasjoner. PTP-profilen for elkraftindustrien (Power Profile) tilfredsstiller til fulle kravene til automasjonssystemer for kraftanlegg, men Standardprofilen kan også brukes. Det er imidlertid ikke garantert at tilstrekkelig nøyaktighet for tidssynkronisering vil bli gitt for alle systemer. Andre spesifikke profiler, for eksempel telekommunikasjonsprofilen eller profilen for lyd- og videoapplikasjoner (IEEE 802.1AS), vil sannsynligvis ikke gi den nødvendige ytelsen.

Eksempler på bruk av PTP-protokollen ved kraftanlegg

Denne delen diskuterer to eksempler på bruk av PTP-protokollen innenfor høyspente elektriskeingssystemer. Det første eksemplet beskriver bruken av PTP-protokollen i automatiseringssystemet til en ny konstruksjonsstasjon, det andre - ved oppgradering av en eksisterende understasjon. Eksemplene diskuterer også strukturen til Ethernet-informasjonsnettverket. Det antas at nettverksdesignet ikke bare støtter PTP-protokollen, men også tilfredsstiller kravet om å opprettholde funksjonalitet under en enkelt feil (utstyr eller kommunikasjonslinje).

Anvendelse av protokollenPTP ved nybygg energianlegg

Mange relébeskyttelsesenheter har transientopptaksmuligheter i samsvar med IEEE C37.118.1 (eller tidligere standarder). Den praktiske implementeringen av denne funksjonaliteten krever å sikre tidssynkronisering av enheter med mikrosekunders nøyaktighet. Historisk sett ble IRIG-B tidssynkronisering brukt fordi NTP ikke oppfylte krav til nøyaktighet. I dag tilbyr en rekke produsenter løsninger som støtter PTP-protokollen for å møte nøyaktighetskrav. Samtidig kan NTP-protokollen også brukes til å synkronisere andre relébeskyttelsesenheter i kraftanlegget som utfører funksjonene for å registrere nødhendelser.

Dette eksemplet tar for seg en mellomstor 330/132 kV understasjon for å demonstrere brukervennligheten til PTP-protokollen. I dette tilfellet vurderes implementering av transiente registreringsfunksjoner, selv om PTP-protokollen også kan brukes til å synkronisere grensesnittenheter med prosessbussen innenfor samme strømanlegg. Et enkeltlinjediagram av objektet er vist i fig. 9.

Ris. 9. Enkeltlinjeskjema for en 330/132 kV transformatorstasjon med halvannet diagram av et 330 kV koblingsanlegg og et enkelt seksjonert bussystem av et 132 kV koblingsanlegg.

Vanligvis aksepterer elektriske nettselskaper ett av to alternativer for utstyrsplassering: relébeskyttelse og automatiseringsenheter er plassert i et enkelt rom eller i flere modulbygg (svært prefabrikkerte), som er plassert i lokalene. Tilnærmingen som brukes bestemmer topologien til det lokale Ethernet-nettverket og det nødvendige nivået av pålitelighet. I dette eksemplet er nettverkstopologien utviklet basert på det faktum at relébeskyttelsesenheter for 330 kV og 132 kV elementer er installert i separate bygninger. For enkelhets skyld, i fig. 10 viser bare noen av enhetene. Redundante tilkoblinger brukes ikke, og bare ett sett med beskyttelser vises.

General Electric UR-seriens enheter ble valgt for bruk på stedet, og funksjonaliteten deres inkluderer en transient opptaksfunksjon. Samtidig støtter relébeskyttelsesenheter PTP-protokollen (i stedet for det mest brukte IRIG-B-grensesnittet). Anlegget sørger også for bruk av en ABB REV615-serie kondensatorbankrelébeskyttelse, som støtter PTP-protokollen.

Hovedkilden til tid er en stormesterklokke utstyrt med en satellittsignalmottaker. Det anbefales at Grandmaster PTP også er en NTP-masterklokke, siden NTP kan brukes av kommunikasjonskontrollere, gatewayer, strømmålere og relébeskyttelsesenheter som krever millisekunders presisjonstidssynkronisering.

Ethernet-svitsjer brukes til å distribuere PTP-meldinger sammen med annen trafikk som IEC 61850, DNP3, HTTP, SNMP osv. Volumet av PTP-trafikk er ekstremt lite, ca. 420 byte/s, og har ingen innvirkning på nettverket. Ris. Figur 11 illustrerer PTP-trafikk generert av en Tekron Grandmaster Watch. Figuren viser at stormesterklokken genererer meldinger som Sync (rød), Follow Up (bringebær), Announce (blå) og Peer Delay Request (grønn) én gang per sekund, og genererer også svar som Peer Delay Response (gul) og Peer Delay Svaroppfølging (brun). Den illustrerte to-trinnsmodusen genererer mest trafikk – dette er det verste tilfellet.

Ris. 11. PTP-trafikk generert av en to-trinns stormesterklokke.

Rotsvitsjen er plassert i midten av strømanleggets lokale Ethernet-nettverkstopologi. En kommunikasjonsserver og en dispatcher arbeidsstasjon er koblet til denne svitsjen. Diagrammet ovenfor sørger også for bruk av to andre brytere: en i 330 kV kontrollsenter, den andre i 132 kV kontrollsenter. Denne løsningen lar deg redusere mengden kabel som kreves for å koble til relébeskyttelse og automatiseringsenheter. Brytere installert i hver kontrollsentral gir mulighet for informasjonsutveksling mellom relébeskyttelsesenheter (for eksempel GOOSE-meldinger med signaler for startbryterfeil, forbud mot automatisk gjenlukking osv.). Dette sikrer funksjonaliteten til distribuerte funksjoner ved svikt i kommunikasjonen med sentralbryteren.

Antall brytere som brukes bestemmes av balansen mellom følgende aspekter:

• Fleksibel: Flere brytere betyr flere porter.
• Pålitelighet: jo flere brytere det er i systemet, jo større er sannsynligheten for feil på en enkelt bryter.
• Driftssikkerhet: Hvis en bryter svikter, hvor mange elementer vil du miste kontrollen over?

Bruk av PTP passer godt inn i tradisjonelle løsninger for bruk av lokale nett til kraftnettselskaper. PTP-profilen for den elektriske kraftindustrien (Power Profile) tillater drift under forhold med tilstedeværelse av redundante kommunikasjonskanaler ved bruk av RSTP-protokollens redundansprotokoll, siden vurderingen av kanalforsinkelser utføres, inkludert på logisk blokkerte kommunikasjonslinjer. Når PTP-meldinger spres langs alternative nettverksruter, vil justeringsverdien i PTP-oppfølgingsmeldingene bestemme forsinkelsen langs den nye ruten.

En av avgjørelsene som må tas når man oppretter et tidssynkroniseringssystem, er om brytere skal fungere i transparent eller kantklokkemodus. Den enkleste modusen er gjennomsiktig klokke. Når du bruker denne modusen, er det mye enklere å feilsøke nettverksfeil ved hjelp av trafikkanalysatorer (for eksempel Wireshark-applikasjonen). Fordelen med å bruke grenseklokker er at de skiller den opererende stormesterklokken fra slaveklokken. Dette oppnås ved å holde grenseklokken oppdatert i stedet for bare å estimere synkroniseringsmeldingstider.

La oss vurdere scenariet med feil på kommunikasjonslinjen mellom rotbryteren og bryteren installert i 132 kV-kontrollsenteret, som fungerer som en gjennomsiktig klokke. I dette tilfellet vil det være et avvik i avlesningene til hver slaveklokke (relébeskyttelsesenheter) fra den sanne tiden og fra hverandre på grunn av forskjellen i egenskapene til de innebygde oscillasjonsgeneratorene. Hastigheten som avviket øker med vil avhenge av flere faktorer, inkludert kvaliteten på oscillatoren og temperaturendringer. Hvis kommunikasjonsavbruddet fortsetter lenge nok, kan forskjellen i tidsavlesningene til relébeskyttelsen og automatiseringsenhetene til 132 kV spenningsnivåelementene bli betydelig. Denne situasjonen er identisk med situasjonen når kommunikasjonslinjen som gir IRIG-B-synkronisering med en tradisjonell løsning blir avbrutt.

Hvis bryteren i 132 kV kontrollsentralen fungerer som en grenseklokke, vil slaveenhetene bli synkronisert med grenseklokken. Under normal drift vil grenseklokken være synkronisert med stormesterklokken. Hvis forbindelsen med stormesterklokken brytes, forblir relébeskyttelsesenhetene synkronisert med grenseklokken. Den lokale tiden på grenseklokken vil sakte avvike fra tiden til stormesterklokken - dette vil også skje på slaveklokken, i samme takt. I dette tilfellet vil alle relébeskyttelsesenheter synkroniseres med hverandre. I denne situasjonen spiller kvaliteten på den interne klokken i relébeskyttelsesenheter ingen rolle.

Bytte ut tidssynkroniseringssystemet:IRIG– B påPTP

Det kan oppstå situasjoner når det er nødvendig å erstatte et eksisterende tidssynkroniseringssystem, for eksempel ved innføring av komplekser med ny funksjonalitet på et kraftanlegg. Det gitte eksemplet tar for seg et utvidelsesscenario for transformatorstasjon hvor det oppstår krav om bygging av en egen kontrollsentral. På den eksisterende understasjonen brukes Ethernet-nettverket til å implementere datautveksling mellom relébeskyttelsesenheter, og IRIG-B-protokollen brukes til å synkronisere enheter i tid. Fiberoptiske kommunikasjonslinjer brukes som dataoverføringsmedium for både Ethernet LAN og tidssynkroniseringssystemet, siden dette mediet gir høy støyimmunitet og galvanisk isolasjon. Repeatere brukes til å konvertere IRIG-B-signaler som sendes over en optisk kommunikasjonslinje til elektriske IRIG-B-signaler, som leveres direkte til grensesnittene til relébeskyttelsesenheter.

Ris. 12 illustrerer et enlinjediagram av en 330/132 kV transformatorstasjon, eksisterende kontrollrombygninger og kommunikasjonsforbindelser mellom bygninger før utvidelse.

Ris. 12. Enkeltlinjediagram av en 330/132 kV transformatorstasjon som viser antall kontrollsentralbygninger, forbindelser mellom dem og strukturen til tidssynkroniseringssystemet.

Elnettselskapet gjennomfører et prosjekt for å utvide 330 kV-koblingsanlegget med installasjon av ytterligere en 330/132 kV krafttransformator. Det er planlagt å bygge enda et kontrollrombygg hvor det skal installeres relébeskyttelse og automasjonsutstyr og annet utstyr. Til tross for at det ser ut til å være mulig å rute et IRIG-B-signal fra 132 kV-sentralen, vil dette være ledsaget av ytterligere tidssynkroniseringsfeil på grunn av den store lengden på kommunikasjonslinjen. Denne transformatorstasjonen gir en god mulighet til å få erfaring med bruk av PTP-protokollen.

Samtidig er mengden utstyr som må skiftes ganske liten. Hvis masterklokken koblet til GPS-en ikke støtter PTP, må den byttes ut. I dette prosjektet ble Tekron-utstyr valgt – modell TCG 01-G, som støtter både PTP- og NTP-protokollene. Hvis root Ethernet-svitsjen ikke støtter PTP-profilen for elektrisk kraft (Power Profle), må den erstattes med en som implementerer denne støtten (i dette prosjektet ble det gjort en erstatning med en GE Multilink ML3000-svitsj). I dette tilfellet må konfigurasjonen av den forrige svitsjen dokumenteres i form av VLAN, multicast-filtrering, portkonfigurasjon og SNMP-protokoll for å replikere dem på den nye svitsjen.

På det siste stadiet er det tenkt å bruke en omformer fra PTP-protokollformatet til IRIG-B-formatet innenfor den nye OPU. Den spesifiserte omformeren gir muligheten til å koble relébeskyttelsesenheter med IRIG-B-grensesnittet. Eventuelle Ethernet-svitsjer som skal installeres i den nye GPUen må støtte enten den transparente klokkerollen eller grenseklokkerollen i samsvar med Power Utilities PTP-profilen. Ris. 13 viser et diagram av transformatorstasjonen etter utvidelse. Ved utvidelse av anlegget er det også verdt å finne ut om de installerte relébeskyttelsesenhetene kan støtte PTP-protokollen. I så fall kan dette eliminere behovet for omformere og også gi ekstra erfaring med bruk av PTP i sluttenheter.

Ris. 13. Diagram over transformatorstasjonen etter utvidelse (installasjon av ekstra krafttransformator, utvidelse av 330 kV-koblingsanlegget og bygging av nytt kontrollsenter).

I den foreslåtte arkitekturen for å konstruere et tidssynkroniseringssystem er det ikke nødvendig å kompensere for forplantningstiden til synkroniseringssignaler for enheter som er plassert i det nye kontrollsenteret, siden dette leveres av peer-to-peer-mekanismen for å bestemme tidsforsinkelsene av PTP-profilen for elkraftindustrien (Power Profile). Dette forenkler oppgaven med å sette opp kontrollsystemer og andre systemer som krever mikrosekunders presisjon av tidssynkronisering.

Når det gjelder skapdesign, kan det kun være en endring knyttet til behovet for å installere PTP-omformere (en for hvert skap), som har som formål å eliminere behovet for å legge dedikerte kommunikasjonslinjer for overføring av IRIG-B-signaler. Allerede i dag går mange strømnettselskaper bort fra å bruke kobberkabelforbindelser mellom relébeskyttelse og automatiseringsskap, og kombinerer kabinettenheter til ett enkelt Ethernet-nettverk. I en slik situasjon kan en annen fordel med denne tilnærmingen brukes - bruken av PTP-protokollen, hvis meldinger overføres over det samme Ethernet-nettverket som signalene til relébeskyttelsesenhetene.

Ris. 14 illustrerer et konvensjonelt tidssynkroniseringssystem som bruker IRIG-B (modulert/basisbånd). Alle relébeskyttelsesenheter er koblet til det automatiserte prosesskontrollsystemet via Ethernet-grensesnitt, men ved eldre strømanlegg kan enheter også kobles til via RS-485-grensesnittet (ved hjelp av DNP3- eller IEC 60870-5-101-protokoller).

Ris. 14. Tradisjonelt tidssynkroniseringssystem og kommunikasjonsforbindelser mellom enheter.

Ved bruk av PTP-protokollen er det tilrådelig å organisere kommunikasjon mellom skap via fiberoptiske kommunikasjonslinjer. En PTP-slaveklokke, for eksempel en PTP-omformer, brukes til å konvertere til en av standard tidssynkroniseringsprotokoller (IRIG-B i eksemplet vist). Genereringen av IRIG-B-signaler av disse omformerne i hvert enkelt kabinett gjør det mulig å ha et annet tidsformat og forskjellige tidssoner sammenlignet med scenariet med å bruke en enkelt tidsserver som kringkaster data i IRIG-B-protokollformatet. Ris. 15 illustrerer et eksempel på hvordan PTP-protokollen kan brukes til å tidssynkronisere eksisterende relébeskyttelsesenheter ved bruk av en omformer fra PTP-formatet til formatet til en av standardprotokollene og samtidig synkronisere tiden til moderne relébeskyttelsesenheter med PTP-støtte.

Bruk av PTP-protokollen ved utvidelse og modernisering av eksisterende kraftanlegg gir mulighet for kraftnettselskaper og integratorer til å få erfaring med bruk av PTP-protokollen. I fremtiden kan det også høstes erfaring med bruk av relébeskyttelsesenheter med innebygd støtte for PTP-protokollen.

Hvis et elektrisk nettverksselskap bare går videre til å implementere kommunikasjon via et lokalt Ethernet-nettverk mellom relébeskyttelse og automatiseringsenheter, bør du være oppmerksom på muligheten for at bryterne som brukes kan støtte PTP-protokollen. Det er nødvendig å sikre at svitsjene støtter protokollen på maskinvarenivå - støtte for individuelle PTP-profiler kan implementeres på et senere tidspunkt ved å endre den underliggende programvaren til Ethernet-svitsjene.

Bygge redundante nettverk ved å bruke PTP-protokollen

Aspekter ved bruk av PTP i et nytt kraftanlegg ble diskutert ovenfor. Denne delen diskuterer de grunnleggende prinsippene for bruk av PTP i redundante Ethernet-nettverk. Det er viktig å merke seg følgende grunnleggende prinsipper:

• Svikt i nettverks- eller kommunikasjonslinjeanordninger skal ikke resultere i svikt i beskyttelses- og kontrollfunksjonen til mer enn én kopling av bryteranlegget.
• Det benyttes hoved- og reserverelébeskyttelsessett, som ofte kalles hovedvern nr. 1/hovedvern nr. 2, sett A/B eller X/Y.
• Styringspåvirkninger på koblingsutstyr genereres direkte fra relévern og automatiseringsenheter, forbipasserende kontrollere/kontrollenheter.

Du kan gi reservasjoner på en av følgende måter, som hver har sine egne fordeler og ulemper:

• Rapid Spanning Tree Protocol (RSTP), som gir muligheten til å lage ringnettverk. Denne protokollen støttes av mange, om ikke alle, Ethernet-svitsjer. Tiden det tar å gjenopprette kommunikasjonen mellom enheter er ikke konstant og avhenger av en rekke faktorer.
• Parallell Redundancy Protocol (PRP). Ved bruk av denne protokollen sikres kontinuiteten i informasjonsutvekslingen ved feil på enten en separat kommunikasjonslinje eller en separat svitsj. Krever spesiell støtte for denne protokollen eller bruk av redundansenheter, samt duplisering av Ethernet-nettverksinfrastrukturen.
• Høy pålitelig Seamless Redundancy (HSR) protokoll. Kontinuitet i informasjonsutvekslingen er sikret ved feil på enten en separat kommunikasjonslinje eller en separat bryter. Dette krever ikke bruk av ekstra brytere. Omfanget av protokollen er begrenset til ring-Ethernet-nettverkstopologier, og spesiell støtte for protokollen av tilkoblede enheter (for eksempel PTP-klokker eller relébeskyttelsesenheter) eller tilkoblingen deres utføres gjennom spesielle redundansenheter.

Eksemplet gitt i denne delen er avhengig av bruken av PRP og eliminerer behovet for en separat bryter per brønn eller per bryterdiameter, som ofte brukes med det formål å opprettholde beskyttelses- og kontrollevne etter en enkelt feil i kommunikasjonsutstyr. I noen scenarier kan bruk av PRP redusere antallet Ethernet-svitsjer som brukes sammenlignet med bruk av RSTP.

Beskyttelse X (eller hovedbeskyttelse nr. 1) implementeres ved bruk av General Electric UR-seriens relébeskyttelsesenheter, siden denne enheten støtter PTP- og PRP-protokollene. Protection X gir kontroll- og transientopptaksfunksjoner i tillegg til relébeskyttelsesfunksjoner. Beskyttelse Y (eller hovedbeskyttelse nr. 2) implementeres ved bruk av relébeskyttelsesenheter fra en annen produsent som støtter PTP- eller NTP-protokollen for tidssynkronisering.

Ris. 16 illustrerer en Ethernet-nettverkstopologi. To lokale nettverk, betegnet A og B, er implementert, som begge er aktive på samme tidspunkt. RSTP-protokollen fungerer på en slik måte at den blokkerer redundante kommunikasjonskoblinger, som vises som stiplede linjer i figuren. Nærmere bestemt er dette koblingen mellom Root Switch #2 og Switch Y. Noen medieservere opererer med sin andre Ethernet-port deaktivert til hovedkoblingen svikter. Tilkoblingsdataene vises også med stiplede linjer.

Ris. 16. Ethernet lokalt nettverk implementert ved hjelp av PRP-protokollen.

Det forventes at ICS-kommunikasjonsservere med innebygd PRP-støtte vil bli tilgjengelig i nær fremtid, noe som gjør at to kommunikasjonslinjer kan holdes aktive samtidig. Bryter Y kan gi redundansfunksjonalitet for relébeskyttelsesenheter Y, som gir behandling av dupliserte meldinger.

Ethernet-svitsjer er nå tilgjengelig med et stort antall porter, noe som eliminerer behovet for å bruke brytere i hvert skap for å koble til relébeskyttelsesenheter. På små transformatorstasjoner kan det hende at det ikke er nødvendig å bruke brytere X1, X2 og Y for tilkobling av relébeskyttelsesenheter, og omvendt kan det på høyspentstasjoner være tilrådelig å bruke brytere X1, X2 og Y for hvert spenningsnivå. Uavhengig av Ethernet-nettverkstopologien, vil bruk av en Ethernet-svitsj som støtter rollen som transparente eller grenseklokker gi muligheten til å koble til klienter hvor som helst i nettverket.

konklusjoner

Bruken av tidssynkroniseringsprotokoller som opererer over et Ethernet-nettverk reduserer kostnadene for systemdesign, implementering og vedlikehold. PTP-protokollen, nemlig profilen til denne protokollen for den elektriske kraftindustrien (Power Profile), løser en rekke problemer knyttet til tidssynkroniseringssystemer foringssystemer, og bruken av den passer optimalt inn i ideologien med å bygge datautveksling mellom sekundære enheter av et strømanlegg over et Ethernet-nettverk.

Bibliografi

1. D.M.E. Ingram, P. Schaub, D.A. Campbell og R.R. Taylor, "Evaluering av presfor stoffapplikasjoner," 2012 Internasjonalt IEEE-symposium om presisjonsklokkesynkronisering for måling, kontroll og kommunikasjon (ISPCS 2012), San Francisco, USA, 23.–28. september 2012. Tilgjengelig fra http://eprints.qut.edu.au/53218/.
2. D.M.E. Ingram, P. Schaub, D.A. Campbell og R.R. Taylor, "Kvantitativ vurdering av feiltolerant presisjonstiming for elektrisitetsstoffer," IEEE-transaksjoner på instrumentering og måling, oktober 2013. Bind 62, utgave 10, s. 2694-2703. Tilgjengelig fra

Hvorfor trenger du nøyaktig tid?

Hvem trenger akkurat denne tiden? Selvfølgelig trenger vi brukere det slik at vi kommer mindre for sent. La oss forestille oss en moderne flyplass - for driften av den må hundrevis av piloter og ekspeditører bruke en feilfritt løpende klokke. Systemet for registrering av varer i varehus, sykehus, jernbanebillettkontorer og mange andre institusjoner krever at tiden ved alle objekter i systemet er lik i en eller annen grad. Spesielt datamaskiner. De kjører mange tjenester og programmer, hvis normale drift krever presis tid, og som regel mer presis tid enn vi mennesker vanligvis trenger. Systemtjenester, sikkerhetssystemkomponenter og ganske enkelt applikasjonsprogrammer kan være svært avgjørende for nøyaktigheten til klokken. Det mest fremtredende eksemplet på slike tjenester er Kerberos-autentiseringsprotokollen. Så for at det skal fungere, er det nødvendig at på datamaskiner som brukes ved hjelp av denne protokollen, avviker systemtiden med ikke mer enn 5 minutter. I tillegg letter nøyaktig tid på alle datamaskiner i stor grad analysen av sikkerhetslogger når man undersøker hendelser på det lokale nettverket.

NTP-protokoll

NTP (Network Time Protocol) er en protokoll utviklet for å synkronisere tid på et nettverk. Det er et sett med ganske komplekse algoritmer designet for å sikre høy nøyaktighet (opptil flere mikrosekunder) og feiltoleranse for tidssynkroniseringssystemet. Dermed innebærer protokollen samtidig synkronisering med flere servere.

Det finnes flere versjoner av denne protokollen, med noen forskjeller. Den tredje versjonen av denne protokollen ble standardisert som RFC 1305 i 1992. Den fjerde (for øyeblikket nyeste) versjonen gir noen forbedringer (automatisk konfigurasjon og autentisering, forbedrede synkroniseringsalgoritmer) sammenlignet med den tredje, men den er ennå ikke standardisert i RFC.

I tillegg, i tillegg til NTP-protokollen, er det SNTP (Simple Network Time Protocol). På pakkenivå er de to protokollene fullstendig kompatible. Hovedforskjellen mellom dem er at SNTP ikke har de komplekse filtreringssystemene og flertrinns feilretting som finnes i NTP. Dermed er SNTP en forenklet og enklere å implementere versjon av NTP. Den er beregnet for bruk i nettverk der svært høy tidsnøyaktighet ikke er nødvendig, og i Microsofts implementering gir den nøyaktighet innen 20 sekunder innenfor en bedrift og ikke mer enn 2 sekunder innenfor et enkelt nettsted. SNTP-protokollen er standardisert som RFC 1769 (versjon 3) og RFC 2030 (versjon 4).

NTP-synkroniseringsmodellen antar en hierarkisk struktur. På det første nivået i hierarkiet er det såkalte "primære" tidsservere (Første stratum). De er plassert på forskjellige steder rundt om i verden og har den mest nøyaktige tiden. Det er relativt få slike servere, siden den nøyaktige tiden på dem opprettholdes ved hjelp av dyrt spesialutstyr (radiokanal, satellittkanal). Andrenivåservere (andre stratum) synkroniseres med førstenivåservere ved hjelp av NTP-protokollen. Det er allerede betydelig flere av dem, men de er allerede noe ute av synkronisering (fra 1 til 20 millisekunder) i forhold til de "primære" serverne. Neste kan være servere på tredje, fjerde og påfølgende nivå:

Med overgangen til hvert nivå øker feilen i forhold til primærserveren litt, men det totale antallet servere øker, og følgelig reduseres belastningen deres. Derfor, som en ekstern kilde til synkronisering, i stedet for å bruke primærservere som har den mest nøyaktige tiden, anbefales det å bruke sekundære servere da de er mindre belastet.

For å synkronisere tid i Windows 2000/XP/2003, brukes SNTP-protokollen. Støtte for denne protokollen er implementert i form av Windows Time-systemtjenesten, som er en del av operativsystemet MS Windows 2000/XP/2003. Et særtrekk ved denne implementeringen er at Windows Time-tjenesten støtter domeneautentisering ved tilgang til referansetidsserveren, noe som er viktig fra et sikkerhetssynspunkt.

Det er flere alternativer for å betjene SNTP-tjenesten inkludert i Windows:

• Hierarkisk (NT5DS). Brukes som standard for alle datamaskiner som er koblet til et domene. Tidssynkronisering på arbeidsstasjoner og domeneservere utføres i et hierarki. Dermed er arbeidsstasjoner og medlemsservere synkronisert med domenekontrolleren som autentiserte påloggingen, domenekontrollere synkroniseres med masteren til "PDC-emulator"-operasjonen, som igjen er synkronisert med domenekontrolleren som ligger på et høyere nivå i hierarkiet. Det skal bemerkes at denne synkroniseringsrekkefølgen brukes "som standard" og kan overstyres manuelt eller ved hjelp av gruppepolicyer. Hvordan du gjør dette vil bli diskutert nedenfor.
• Tving synkronisering med den valgte NTP-serveren (NTP). I dette tilfellet settes referansetidskilden for Windows Time-tjenesten enten manuelt eller ved hjelp av gruppepolicyer.
• Deaktiver synkronisering (NoSync). Denne modusen er nødvendig for et blandet tidsstyringsskjema, der et tredjepartsprodukt brukes til å synkronisere med en ekstern kilde, og Windows Time brukes til å opprettholde tid innenfor domenet.

Når det gjelder en arbeidsgruppe, vil altså tidssynkronisering fortsatt måtte konfigureres manuelt. For eksempel kan en av datamaskinene konfigureres til å synkronisere med en ekstern server ved hjelp av SNTP-protokollen, og resten kan konfigureres til å synkronisere med den. Trinnene som kreves for dette vil bli beskrevet nedenfor.

For et domene anbefales det å bruke hierarkisk synkronisering ved hjelp av SNTP-protokollen. I de fleste tilfeller gir det akseptabel systemtidsnøyaktighet innenfor domenets skog. I tillegg sikrer den automatisk tidsoppdateringssikkerhet ved å støtte Active Directory-autentisering. For å opprettholde "riktig" tid i domenet, er det nødvendig å synkronisere toppnivådomenekontrolleren, som eier rollen "PDC-emulator", med en ekstern NTP-server. I vårt eksempel vil rollen til en slik server være en Linux-maskin med ntpd-demonen kjørende.

Sette opp SNTP på Windows

For å konfigurere Windows Time-tjenesten brukes to verktøy:

• Netto tid
• W32tm

Nettotid brukes primært til å konfigurere tidstjenesten, og w32tm brukes til overvåking og diagnostisering av drift. I Windows XP/2003 har imidlertid w32tm-verktøyet gjennomgått betydelige endringer og kan brukes til å konfigurere tidstjenesten. NTP-konfigurasjon vil bli utført videre med Windows XP/2003 som eksempel.

Så, for å "manuelt" spesifisere synkroniseringskilden ved bruk av nettotid, skriv bare på kommandolinjen:

et tid /setsntp:liste_over_tidstjenere_separert av_mellomrom

For å få informasjon om gjeldende tidsserver:

netto tid /querysntp

Du kan finne ut tiden på en domenekontroller som dette:

nettid /domene:domenenavn

Og synkroniser tid med en domenekontroller som dette:

Nettotid /domene:domenenavn /sett

Systemverktøyet w32tm kan gjøre det samme og enda mer:

• w32tm /resync - Ved å bruke denne kommandoen kan du tvinge en lokal eller ekstern datamaskin til å synkronisere systemklokken med tidsserveren den bruker.
• w32tm /config – Denne kommandoen brukes til å konfigurere Windows Time-tjenesten. Med dens hjelp kan du spesifisere listen over tidsservere som brukes og typen synkronisering (hierarkisk eller valgt av servere).

For eksempel, for å overstyre standardverdiene og sette opp tidssynkronisering med en ekstern kilde, kan du bruke kommandoen:

w32tm /config /syncfromflags:manual /manualpeerlist:PeerList

Og for at Windows Time skal bruke de nye innstillingene, i stedet for å starte tjenesten på nytt, kan du bruke kommandoen:

w32tm /config /oppdatering

I tillegg gir w32tm følgende alternativer knyttet til tidsovervåking på datamaskiner:

• w32tm /monitor - ved å bruke dette alternativet kan du finne ut hvordan systemtiden til denne datamaskinen er forskjellig fra tiden på domenekontrolleren eller andre datamaskiner.
• w32tm /stripchart – viser grafisk tidsforskjellen mellom gjeldende og ekstern datamaskin.
• w32tm /register – Registrerer Windows Time-tjenesten som en tjeneste på denne datamaskinen. Dette alternativet kan være nyttig på datamaskiner som ikke er en del av et domene, siden tidstjenesten som standard stoppes på dem.

Mer detaljert informasjon om parametrene for netttids- og w32tm-verktøyene kan fås ved å bruke /? eller ved å åpne den aktuelle delen av hjelpe- og støttesenteret MS Windows XP/2003 hjelpesystem.

Det er ikke vanskelig å gjette at innstillingene for Windows Time-tjenesten er lagret i Windows-registeret i delen HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\.

I roten av seksjonen er driftsparametrene til selve tjenesten definert, i undernøkkelen Config – innstillinger relatert til driften av selve SNTP-protokollen, er synkroniseringsmodus definert i undernøkkelen Parametere. SNTP-klienten og serverinnstillingene er plassert i henholdsvis TimeProviders\NtpClient- og TimeProviders\NtpServer-tilkoblingene. La oss se på hovedverdiene som bestemmer NTP-klienten og serverinnstillingene:

• Type – bestemmer driftsmodusen til NTP-klienten (NTDS5 – hierarkisk, NTP – “manuell”, NoSync – ikke synkroniser, AllSync – alle typer synkronisering er tilgjengelige);
• Aktivert – bestemmer om denne komponenten (klient eller server) er aktivert;
• CrossSiteSyncFlags – bestemmer om det er mulig å synkronisere tid med en kilde som ligger utenfor domenet hvis hierarkisk synkronisering brukes (0 – ikke mulig, 1 – bare med PDC-emulatoren, 2 – med alle);
• EventLogFlags – bestemmer om meldinger fra Windows Time skal logges eller ikke (en svært nyttig funksjon ved feilsøking).

Et annet alternativ for å konfigurere Windows Time-tjenesten er å bruke gruppepolicyer. Innstillingene er definert i gruppepolicyobjektet på følgende adresse: "Datamaskinkonfigurasjon -> Administrative maler -> System -> Windows Time Service".

Hvis du har Windows 2000 Server installert og du ikke har funnet en slik innstilling, fortvil ikke, du trenger bare å oppdatere "Administrative maler". For å gjøre dette, kopier alle .adm-filer fra system32\GroupPolicy\Adm-systemmappen på en hvilken som helst maskin med Windows XP installert til serveren som er en domenekontroller. Deretter, mens du definerer GPO, høyreklikker du på "Administrative maler" og velger "Legg til/fjern maler..." Fjern malene som er oppført der og legg til de kopierte. Etter å ha klikket på "OK"-knappen, vil malene bli oppdatert og du kan konfigurere tidstjenesten ved å bruke gruppepolicyer:

Det er lett å se at dette hovedsakelig viser alle innstillingene som kan endres i registeret. Det er ikke noe overraskende i dette, for det er akkurat slik de fleste gruppepolitikker fungerer.

I Windows XP har det dukket opp en annen måte å angi en tidsserver på, som kan være veldig praktisk for å sette opp synkronisering på en hjemmedatamaskin eller en datamaskin som er en del av en arbeidsgruppe:

NTP-server for Linux – ekstern synkronisering for Windows-domene

Som nevnt ovenfor er NTP-protokollen mer feilbestandig, så det er bedre å bruke en NTP-server som kilde til referansetid for ekstern synkronisering. I tillegg har toppnivådomenekontrolleren ikke alltid tilgang til Internett via UDP-port 123, som brukes til NTP-drift. Tilgang kan godt nektes av sikkerhetsgrunner, noe som er vanlig praksis for store organisasjoner. I slike tilfeller, for å løse dette problemet, kan du installere din egen tidsserver i DMZ, konfigurert til å synkronisere med en ekstern kilde, og bruke den som en referansetidskilde for synkronisering av toppnivådomenekontrolleren. Enhver datamaskin, ikke nødvendigvis en moderne, med et *nix-lignende OS, for eksempel Linux, installert i en minimal konfigurasjon, uten en X-server og andre potensielt sårbare ting, er ganske egnet som en slik datamaskin.

Det er mange tidssynkroniseringsprogrammer for Linux OS. De mest kjente er Xntpd (NTP versjon 3), ntpd (NTP versjon 4), Crony og ClockSpeed. I vårt eksempel vil vi bruke ntpd ntp-serveren inkludert i Redhat 9, levert i pakken ntp-4.1.2-0.rc1.2.i386.rpm.

Pakken inneholder flere programmer designet for å fungere med NTP.

Her er de viktigste:

• Ntpd – ntp-demon som opprettholder nøyaktig tid i bakgrunnen;
• Ntpq er et verktøy utviklet for å polle NTP-servere som støtter standard pollingprotokoll NTP-modus 6. Med hjelpen kan du finne ut og endre serverens gjeldende tilstand, hvis innstillingene tillater det;
• Ntptdc – et verktøy som du kan forhøre deg med ntpd-demonen og få statistikk om driften av;
• Ntpdate er et program for å stille inn gjeldende systemtid ved hjelp av NTP-protokollen.

En standardfunksjon i NTP-protokollen er muligheten til å utføre autentisering. I dette tilfellet kan både symmetriske algoritmer (DES), som dukket opp i den andre versjonen av protokollen, og asymmetriske algoritmer med en offentlig nøkkel, som er en innovasjon i den fjerde versjonen, brukes.

Ved bruk av et symmetrisk autentiseringsskjema velger klienten og serveren en vilkårlig identifikator og en av 65534 nøkler definert av standarden. Ved bruk av asymmetriske algoritmer brukes det såkalte Autokey-skjemaet, hvis særtrekk er at det ikke er behov for å forhåndsdistribuere offentlige servernøkler.

For å konfigurere autentisering i ntpd finnes det verktøy ntp-genkeys, ntpq og ntpdc.

All NTP-funksjonalitet relatert til nøyaktig tidsstøtte er implementert i ntpd-demonen. Den konfigureres på vanlig UNIX-måte - ved å redigere ntp.conf-konfigurasjonsfilen som ligger i /etc-mappen.

La oss angi følgende alternativer for NTP-serveren.

Først, la oss indikere serverne som tidssynkronisering skal utføres med:

server ntp.nasa.gov # En stratum 1-server på nasa.org
server ntp1.demos.net # En stratum 2-server på demos.net

begrense ntp.research.gov mask 255.255.255.255 nomodify notrap noquery

Her brukes masken 255.255.255.255 for å begrense tilgangen til serveren vår fra ntp.nasa.gov-serveren. La oss nå definere en liste over verter på vårt lokale nettverk som vi vil gi tilgang til NTP-serveren vår for å få tiden:

limit 192.168.1.0 mask 255.255.255.0 nottrust nomodify notrap

Vi krever også at Linux-maskinen har full tilgang til serverressursene:

begrense 127.0.0.1

Og nå det viktigste: vi må sørge for at standardavvisningen, som har høyere prioritet, blir kommentert ut:

#restrict standard ignorer

Etter å ha lagret ntp.conf-filen, kan konfigurasjonen anses som fullført, men det kan skje at etter at demonen er startet, vil tiden fortsatt ikke bli synkronisert. Faktum er at NTP-protokollen opprinnelig ble utviklet som en protokoll for å opprettholde tid, ikke for å sette den. Derfor, hvis forskjellen mellom klokkeavlesningene er stor nok (mer enn noen få minutter), vil synkronisering ikke forekomme. I dette tilfellet er det fornuftig å angi tiden manuelt ved å bruke ntpdate-kommandoen (du kan også legge til ntpdate-kommandoen til maskinens oppstartsskript):

# ntpdate clock.vsu.ru
17 feb 23:44:54 ntpdate: trinntidsserver 198.123.30.132 offset 25.307598 sek.

17 feb 23:45:05 ntpdate: juster tidsserver 198.123.30.132 offset 0,002181 sek
# ntpdate clock.vsu.ru

ntp-demonen lanseres gjennom initialiseringsskript. Hvis programmet ble installert fra en rpm-pakke, er sannsynligvis alle problemer knyttet til den automatiske lanseringen allerede løst. For å bekrefte dette kan du bruke kommandoen:

# chkconfig -list ntpd
ntpd 0:på 1:av 2:av 3:på 4:av 5:på 6:av

Hvis du ikke ser denne linjen, betyr det at ntpd ikke er konfigurert til å starte automatisk. For å fikse dette, skriv inn:

# chkconfig –nivå 035 ntpd på

For å administrere NTP (start, lansering, omstart, status), brukes et standard initialiseringsskript:

# /etc/init.d/ntpd start

For å se serversynkroniseringsstatistikk kan du bruke følgende kommando:

# ntpq -p
remote refid st t når poll nå forsinkelse offset jitter
==============================================================================
*tick.usnogps.na .USNO. 1 u 38 64 377 220,00 0,149 7,08
-navobs1.wustl.e.PSC. 1 u 55 64 377 193,47 6,857 4,81
-ntp-nasa.arc.na .GPS. 1 u 43 64 377 254,88 7,471 9,58
-ntp0.NL.net.GPS. 1 u 144 512 377 122,54 12,515 13,75
-ntp2.ien.it .IEN. 1 u 558 1024 377 133,94 14 594 41,99
+tidtaker.isi. .GPS. 1 u 13 64 377 245,30 3,454 15,08
+news-zero.demos ntp0.usno.navy. 2 u 16 64 377 37,51 -3,239 11,14
LOCAL(0) LOCAL(0) 10 l - 64 377 0,00 0,000 10,01

Driftsmoduser for NTP-server/klient

Klient server

Denne modusen er den desidert mest brukte på Internett. Arbeidsopplegget er klassisk. Klienten sender en forespørsel, som serveren sender et svar til innen en viss tid. Klienten konfigureres ved hjelp av serverdirektivet i konfigurasjonsfilen, hvor DNS-navnet til tidsserveren er spesifisert.

Symmetrisk aktiv/passiv modus

Denne modusen brukes hvis tidssynkronisering utføres mellom et stort antall peer-maskiner. I tillegg til at hver maskin synkroniserer med en ekstern kilde, synkroniserer den også med sine naboer (peers), og fungerer som klient og tidsserver for dem. Så selv om en maskin "mister" en ekstern kilde, vil den fortsatt kunne få nøyaktig tid fra sine naboer. Naboer kan jobbe i to moduser - aktiv og passiv. Arbeider i aktiv modus, sender maskinen selv tiden sin til alle nabomaskiner som er oppført i peers-delen av ntp.conf-konfigurasjonsfilen. Hvis naboer ikke er angitt i denne delen, anses maskinen for å fungere i passiv modus. For å forhindre at en angriper kompromitterer andre maskiner ved å utgi seg for å være en aktiv kilde, må autentisering brukes.

Kringkastingsmodus

Denne modusen anbefales for bruk i tilfeller der et lite antall servere betjener et stort antall klienter. Når du opererer i denne modusen, sender serveren med jevne mellomrom pakker ved å bruke subnettets kringkastingsadresse. En klient konfigurert til å synkronisere på denne måten mottar serverens kringkastingspakke og synkroniserer med serveren. En funksjon i denne modusen er at tiden leveres innenfor ett undernett (begrenser kringkastingspakker). I tillegg må autentisering brukes for å beskytte mot angripere.

Multicast-modus

Denne modusen ligner på mange måter kringkasting. Forskjellen er at multicast-adresser til klasse D-nettverk i IP-adresserommet brukes til å levere pakker. For klienter og servere er adressen til multicast-gruppen spesifisert, som de bruker for tidssynkronisering. Dette gjør det mulig å synkronisere grupper av maskiner plassert på forskjellige undernett, forutsatt at ruterne som kobler dem til støtter IGMP-protokollen og er konfigurert til å overføre multicast-trafikk.

Manycast-modus

Denne modusen er en nyvinning i den fjerde versjonen av NTP-protokollen. Det innebærer at klienten søker etter Manycast-servere blant nettverksnaboene, mottar tidsprøver fra hver av dem (ved hjelp av kryptografi) og, basert på disse dataene, velger de tre "beste" Manycast-serverne som klienten vil synkronisere med. Hvis en av serverne svikter, oppdaterer klienten automatisk listen.

For å overføre tidsprøver bruker klienter og servere som opererer i multicast-modus multicast-gruppeadresser (klasse D-nettverk). Klienter og servere som bruker samme adresse danner samme tilknytning. Antall assosiasjoner bestemmes av antall multicast-adresser som brukes.

Ofte stilte spørsmål

Hvorfor er ikke tiden synkronisert etter kommandoen net time /setsntp:server?

Sørg for at w32time-tjenestens oppstartstype er satt til Automatisk.
Sørg for at UDP-port 123 til NTP-serveren du bruker er tilgjengelig.
Pass på at tiden mellom klient og server ikke varierer for mye.

Kan en SNTP-klient synkronisere med en NTP-server?

Ja, det kan det, siden SNTP-protokollen er en undergruppe av NTP og er fullstendig kompatibel med den.

Kan jeg bruke en tredjeparts NTP-server på Windows 2000/XP/2003?

Ja, du kan bruke hvilken som helst server, betalt eller gratis. Du må først deaktivere de riktige komponentene (klient eller server) til Windows Time-tjenestene.

Hvorfor fungerer ikke NTP-klienten på en datamaskin med MS SQL Server installert?

Mest sannsynlig er problemet at SQL Server på en eller annen måte opptar UDP-port 123. En løsning kan være å kjøre NTP-klienten før MS SQL Server.

ntpd-demonen, etter oppstart, fungerer i 10-20 minutter, hvoretter den stopper. Hva kan være problemet?

Pass på at klient- og servertidene ikke avviker for mye (ikke mer enn 5 minutter). Ellers tving synkronisering ved hjelp av ntpdate.

Er det mulig å synkronisere tid i OS Windows NT4, 95, 98, Me?

Det er mulig å bruke tredjepartsprogrammer, for eksempel NetTime, Automacahron, World Time5, ntpd Windows NT-port.

Når du prøver å logge på et Windows-domene, vises en melding om at tiden mellom domenekontrolleren og arbeidsstasjonen er for mye forskjellig, til tross for at synkroniseringen er nøyaktig konfigurert.

Mest sannsynlig er problemet at tiden har gått veldig galt (CMOS-tilbakestilling, hackersabotasje) og tjenesten er ikke i stand til å autentisere ved hjelp av Kerberos-protokollen. For å løse dette problemet må du enten stille inn klokkeslettet manuelt eller ikke bruke denne typen autentisering når du oppdaterer klokkeslettet.

Det er skrevet mange artikler om den velkjente Network Time Protocol (NTP), noen av dem nevner Precision Time Protocol, som visstnok gjør det mulig å oppnå tidssynkroniseringsnøyaktighet i størrelsesorden nanosekunder (for eksempel og ). La oss finne ut hva denne protokollen er og hvordan en slik nøyaktighet oppnås. Vi vil også se resultatene av arbeidet mitt med denne protokollen.

Introduksjon

"Precision Time Protocol" er beskrevet av IEEE 1588-standarden. Det er 2 versjoner av standarden. Den første versjonen ble utgitt i 2002, deretter ble standarden revidert i 2008 og PTPv2-protokollen ble utgitt. Bakoverkompatibilitet er ikke opprettholdt.
Jeg jobber med den andre versjonen av protokollen, den har mange forbedringer i forhold til den første (nøyaktighet, stabilitet, som wikien forteller oss). Jeg vil ikke gjøre sammenligninger med NTP, bare omtalen av synkroniseringsnøyaktighet, og nøyaktigheten til PTP når faktisk titalls nanosekunder med "maskinvare"-støtte, indikerer en fordel fremfor NTP.
Maskinvarestøtte for protokollen kan implementeres forskjellig i forskjellige enheter. Faktisk er minimum som kreves for å implementere PTP maskinvarens evne til å sette et tidsstempel på øyeblikket meldingen ble mottatt på porten. Den angitte tiden vil bli brukt til å beregne feilen.

Hvorfor blir klokken opprørt?

Feil kan komme fra hvor som helst. La oss starte med at frekvensgeneratorene i enhetene er forskjellige og det er svært lav sannsynlighet for at to ulike enheter vil fungere perfekt over tid. Dette kan også tilskrives stadig skiftende miljøforhold som påvirker den genererte frekvensen.

Hva prøver vi å oppnå?

La oss si at vi har en enhet som fungerer under ideelle forhold, en slags atomklokke som ikke vil bevege seg i det hele tatt før verdens ende (selvfølgelig før den virkelige, og ikke den som er spådd av Maya-kalenderen) og vi får i oppgave å oppnå minst omtrentlig (med en nøyaktighet på 10 -9 sek) samme timer. Vi må synkronisere disse klokkene. For å gjøre dette kan du implementere PTP-protokollen.

Forskjellen mellom en ren programvareimplementering og en implementering med "maskinvarestøtte"

En ren programvareimplementering vil ikke oppnå den lovede nøyaktigheten. Tiden som gikk fra øyeblikket du mottar en melding (mer presist, mottak av et signal for å motta en melding i enheten) til overgangen til avbruddsinngangspunktet eller tilbakeringing kan ikke defineres strengt. "Smart hardware" med PTP-støtte kan sette disse tidsstemplene uavhengig (for eksempel brikker fra Micrel, jeg skriver en driver for KSZ8463MLI).
I tillegg til tidsstempler inkluderer "maskinvare"-støtte også muligheten til å stille inn en kvartsoscillator (for å justere frekvensen med masteren), eller muligheten til å justere klokken (øk klokkeverdien med X ns hver klokkesyklus). Mer om dette nedenfor.

La oss gå videre til IEEE 1588-standarden

Standarden er beskrevet på hele 289 sider. La oss vurdere minimumskravet for å implementere protokollen. PTP er en klient-server synkroniseringsprotokoll, dvs. Det kreves minst 2 enheter for å implementere protokollen. Så, Master-enheten er en atomklokke, og Slave-enheten er en klokke som må fås til å fungere nøyaktig.

Utveksle språk

Kunngjør melding– kunngjøringsmelding, inneholder informasjon sendt av masteren til alle slaveenheter. Slaveenheten kan bruke denne meldingen til å velge den beste masteren (det finnes en BMC (Best Master Clock)-algoritme for dette). BMC er ikke så interessant. Denne algoritmen kan enkelt finnes i standarden. Utvalget er basert på meldingsfelt som nøyaktighet, varians, klasse, prioritet osv. La oss gå videre til andre meldinger.

Sync/Opfølging, DelayResp, PDelayResp/PDelayFollowUp– sendes av mesteren nedenfor vil vi se på dem mer detaljert.

DelayReq, PDelayReq– Forespørsler om slaveenheter.

Som du kan se, er ikke Slave-enheten omfattende. Mesteren gir nesten all informasjonen selv. Sending utføres til Multicast (om ønskelig kan du bruke Unicast-modus) adresser strengt definert i standarden. Til PForsinkelse meldinger har en egen adresse (01-80-C2-00-00-0E for Ethernet og 224.0.0.107 for UDP). Andre meldinger sendes til 01-1B-19-00-00-00 eller 224.0.1.129. Pakker varierer etter felt ClockIdentity(klokke-ID) og Sekvens-ID(pakkeidentifikator).

Arbeidsøkt

La oss si at masteren ble valgt ved hjelp av BMC-algoritmen, eller at masteren er den eneste på nettverket. Bildet viser fremgangsmåten for kommunikasjon mellom hovedenheten og den synkroniserte.

1. Det hele starter med at Master sender en melding Synkroniser og registrerer samtidig sendetiden t1. Det er ett- og to-trinns driftsmodus. Det er veldig enkelt å skille dem: hvis det er en melding Følge opp– da har vi å gjøre med en to-trinns implementering, den stiplede pilen viser valgfrie meldinger
2. Følge opp meldingen sendes etter Synkroniser og inneholder tid t1. Hvis overføringen utføres i ett trinn, da Synkroniser inneholder t1 i meldingens brødtekst. Uansett vil t1 bli mottatt av enheten vår. På tidspunktet for mottak av meldingen Synkroniser tidsstempel t2 genereres på slave. Dermed får vi t1, t2
3. Slaven genererer en melding ForsinkelseRekv samtidig med t3 generasjon
4. Mester mottar ForsinkelseRekv melding mens du genererer t4
5. t4 sendes til Salve-enheten inn ForsinkelseResp beskjed

Online meldinger

En utvekslingsøkt som den som er vist ovenfor kan bare bli vellykket hvis kvartsen genererer helt like frekvenser for enhetene som synkroniseres. Faktisk viser det seg at klokkefrekvensen er forskjellig, d.v.s. På en enhet vil klokkeverdien øke med 1 sekund på 1 sekund, og på en annen, for eksempel med 1,000001 sekund. Det er her klokkedivergensen vises.
Standarden beskriver et eksempel på beregning av forholdet mellom tiden som har gått på masteren og på slaven for et visst intervall. Dette forholdet vil være koeffisienten for frekvensen til Slave-enheten. Men det er en indikasjon på at justering kan utføres på ulike måter. La oss se på to av dem:

1. Endre klokkefrekvensen til Slave-enheten (eksempel i standarden)
2. Ikke endre klokkefrekvensen, men for hvert kryss av varighet T vil klokkeverdien øke ikke med T, men med T+∆t (brukt i min implementering)

I begge metodene må du beregne forskjellen i tidsverdier på Master-enheten over et visst intervall, samt forskjellen i tid over samme intervall på Slave-enheten. Koeffisient i den første metoden:

Den andre metoden krever beregning av ∆t. ∆t er en verdi som legges til tidsverdien for hvert bestemt intervall. På figuren kan du se at mens 22 – 15 = 7 sekunder gikk på masteren, 75+(87-75)/2 –(30+ (37-30)/2) = 47,5 gått på slaven

Frekvens – prosessorfrekvens, for eksempel 25 MHz – en prosessorsyklus varer 1/(25*10 6) = 40ns.
Avhengig av egenskapene til enheten, velges den mest passende metoden.
For å gå videre til neste seksjon, la oss uttrykke offset litt annerledes:

PTP-driftsmoduser

Ser du på standarden, kan du finne at det ikke bare er én måte å beregne leveringstid på. Det er 2 driftsmoduser for PTPv2. Dette E2E (ende-til-ende), ble det diskutert ovenfor, modusen er også beskrevet P2P (Peer-to-Peer). La oss finne ut hvor vi skal bruke hvilken metode og hva som er forskjellen deres.
I prinsippet kan du bruke hvilken som helst av modusene etter ønske, men de kan ikke kombineres på samme nettverk.

• I modus E2E leveringstid beregnes fra meldinger som kommer gjennom mange enheter, som hver går inn i meldingskorrigeringsfeltet Synkroniser eller Følge opp(hvis to-trinns overføring) tiden som pakken ble forsinket på denne enheten (hvis enhetene er koblet direkte, blir det ikke gjort noen korreksjon, så vi vil ikke vurdere dem i detalj). Meldinger brukt: Sync/Opfølging, DelayReq/DelayResp
• I modus P2P I korrigeringsfeltet legges ikke bare inn tiden pakken ble forsinket for, (t2-t1) legges til den (du kan lese den i standarden). Meldinger brukt Sync/FollowUp, PDelayReq/PDelayResp/PDelayRespFollowUp

I henhold til standarden kalles klokken som PTP-meldinger passerer med en endring i korreksjonsfeltet Gjennomsiktig klokke (TC). La oss se på bildene for å se hvordan meldinger overføres i disse to modusene. Blå piler indikerer meldinger Synkroniser Og Følge opp.


End-to-end-modus


Node-til-node-modus
Vi ser at noen røde piler har dukket opp i P2P-modus. Dette er de resterende meldingene som vi ikke har adressert, nemlig PDelayReq, PDelayResp Og PDelayFollowUp. Her er utvekslingen av disse meldingene:

Leveringstidsfeil

Standarden beskriver implementeringen av protokollen i ulike typer nettverk. Jeg brukte et Ethernet-nettverk og mottok meldinger på Ethernet-nivå. I slike nettverk er pakkeleveringstiden i stadig endring (spesielt merkbart når du jobber med nanosekundspresisjon). Ulike filtre brukes til å filtrere disse verdiene.

Hva må filtreres:

1. Leveringstid
2. Partiskhet

Driveren min bruker omtrent samme filtreringssystem som Linux-demonen PTPd, hvis kilder kan finnes, og det er også noe informasjon. Jeg skal bare gi deg et diagram:

LP IIR (Infinite Impulse Response low-pass) filter(Infinite Impulse Response Filter) beskrevet av formelen:

, Hvor s– koeffisient som lar deg justere filteravskjæringen.

Justeringsberegning

La oss gå videre til justeringen, til deltaet som må legges til den andre verdien. Beregningsskjemaet brukt i systemet mitt:

Jeg brukte et Kalman-filter for å filtrere ut den sterke justeringsjitteren på grunn av nettverksinterferens, jeg likte det veldig godt. Generelt kan du bruke hvilket som helst filter du vil, så lenge det jevner ut grafen. I PTPd, for eksempel er filtrering enklere - gjennomsnittet av gjeldende og tidligere verdier beregnes. På grafen kan du se resultatene av Kalman-filteret i driveren min (justeringsfeilen vises, uttrykt i subnanosekunder på en 25 MHz-brikke):

La oss gå videre til å regulere justeringen, justeringen skal ha en tendens til en konstant, en PI-kontroller brukes. I PTPd Klokkeforskyvningen er justert (justeringen er basert på forskyvningen), men jeg bruker den til å regulere justeringen (en funksjon i KSZ8463MLI). Vi ser at kontrolleren ikke er perfekt konfigurert, men i mitt tilfelle er denne justeringen tilstrekkelig:

Resultat av arbeid

Resultatet er vist i grafen. Klokkeforskyvning varierer fra -50 ns til 50 ns. Følgelig oppnådde jeg nøyaktigheten som er nevnt i en rekke artikler. Selvfølgelig forble mange små funksjoner ved implementeringen bak kulissene, men det nødvendige minimum ble demonstrert.

Send ditt gode arbeid i kunnskapsbasen er enkelt. Bruk skjemaet nedenfor

Studenter, hovedfagsstudenter, unge forskere som bruker kunnskapsbasen i studiene og arbeidet vil være deg veldig takknemlig.

Lagt ut på http://www.allbest.ru/

Utdannings- og vitenskapsdepartementet i Den russiske føderasjonen

Federal State autonome utdanningsinstitusjon

Høyere profesjonsutdanning

"National Research Nuclear University "MEPhI"

Trekhgorny Technological Institute - gren av National Research Nuclear University MEPhI

Dataavdelingen

i faget "Internet Technologies"

om emnet: "RSYNC-protokoll. Tidssynkronisering. NTP-protokoll. SNTP-protokoll"

Fullført av: elev av gruppe 5VT-58

Koltsov D.A.

Sjekket: Art. Rev. Dolgopolova M. O.

Trekhgorny 2012

RSYNC PROTOKOLL

TIDSSYNKRONISERING

NTP-PROTOKOLL

PROTOKOLL SNTP

LISTE OVER INTERNETSKILDER BRUKT

APPLIKASJONER

RSYNC PROTOKOLL

Rsynkronisere(eng. Remote Synchronization) er et program for UNIX-lignende systemer som synkroniserer filer og kataloger på to steder samtidig som trafikken minimeres, ved bruk av datakoding om nødvendig. En viktig forskjell mellom rsync og mange andre programmer/protokoller er at speiling utføres av én tråd i hver retning (i stedet for én eller flere tråder per fil). Rsync kan kopiere eller vise innholdet i en katalog og kopiere filer, eventuelt ved å bruke komprimering og rekursjon.

Utvikler- Wayne Davison;

Operasjonssalsystem- Programvare på tvers av plattformer.

Utgitt under GNU GPL-lisensen, er rsync fri programvare.

Kryssplattform(kryssplattform)programvaresikkerhet-- programvare som kjører på mer enn én maskinvareplattform og/eller operativsystem. Et typisk eksempel er programvare utviklet for å kjøre på Linux- og Windows-operativsystemer samtidig.

Det er en implementering av rsync for Winows, eller rettere sagt ikke en direkte implementering, men en sammenstilling av rsync og cygwin, kalt cwRsync.

Algoritme

Nytte rsync bruker en algoritme utviklet av den australske programmereren Andrew Tridgell (vedlegg C) for å effektivt overføre strukturer (som filer) på tvers av kommunikasjonsforbindelser når mottakerdatamaskinen allerede har en annen versjon av den strukturen.

Den mottakende datamaskinen deler sin kopi av filen i ikke-overlappende biter med en fast størrelse S, og beregner en kontrollsum for hver del: en MD4-hash (vedlegg A) og en svakere rullende sjekksum (vedlegg B), og sender dem til server som den er synkronisert med.

Serveren som synkroniseres med, beregner kontrollsummer for hver del av størrelse S i sin versjon av filen, inkludert overlappende biter. Dette kan beregnes effektivt på grunn av den spesielle egenskapen til rullende sjekksum: hvis rullende sjekksumbyte n til n+S-1 er lik R, kan rullende sjekksumbyte n+1 til n+S beregnes fra R, byte n og byte n +S uten å måtte ta hensyn til bytene som ligger innenfor dette intervallet. Således, hvis de rullende sjekksumbytene 1-25 allerede er beregnet, blir den forrige sjekksummen og bytene 1 og 26 brukt for å beregne de rullende sjekksumbytene 2-26.

Grunnleggende fordeler

Hastighet: Til å begynne med replikerer rsync alt innhold mellom kilden og destinasjonen (sink). Deretter overfører rsync bare de endrede blokkene eller bitene til destinasjonen, noe som gjør synkronisering veldig rask;

Sikkerhet: rsync inkluderer kryptering av data under overføring ved hjelp av SSH-protokollen;

rsync komprimerer og dekomprimerer data blokk for blokk på henholdsvis sender- og mottakersiden. Dermed er båndbredden som brukes av rsync lavere sammenlignet med andre filoverføringsprotokoller.

Syntaks

$ rsync options kildedestinasjon, der Kilde og Destinasjon kan være enten lokal eller ekstern. Når den brukes med eksterne objekter, spesifiserer påloggingen, servernavnet og banen.

Noen viktige alternativer:

1) -en,--arkiv arkivmodus;

2) -r,--tilbakevendende traversere kataloger (rekursjon);

3) -R,--slektning relative stier;

4) -H,--harde lenker lagre harde lenker;

5) -S,--sparsom håndtere sparsomme filer effektivt;

6) -x,--ett-filsystem ikke kryss filsystemgrenser;

7) -ekskludere=MØNSTER ekskluder filer av en gitt prøve;

8) -slett-i løpet av mottakeren fjernes VED SENDING;

9) -slett-etter mottakeren fjernes ETTER SENDING.

TIDSSYNKRONISERING

Tiden i informasjonsteknologiens tid har fått spesiell betydning for det moderne mennesket. Hver av oss ser på klokkene våre minst flere ganger om dagen. Mange mennesker synkroniserer regelmessig tidsrapporteringsenhetene sine gjennom ulike kilder, inkludert Internett. Nøyaktig tid spiller noen ganger en avgjørende rolle i saker der ikke engang minutter, men sekunder er viktige. For eksempel kan handel på børser resultere i ruin for en spiller hvis klokke viser feil tid.

Teknologi synkronisering tid

Alle tidssynkroniseringsprosessen utføres gjennom en spesiell nettverksprotokoll kalt NTP(NettverkTidprotokoll). Denne protokollen er et sett med forskjellige regler og matematiske algoritmer, takket være hvilke tiden på datamaskinen din er nøyaktig justert med en forskjell på noen få hundredeler av ett sekund. Det finnes også en protokoll for systemer som ikke krever så nøyaktig synkronisering, kalt SNTP. Forskjellen mellom kilden og mottakerenheten kan være opptil 1 sekund.

Teknologien for overføring av nøyaktige tidsparametere er en flerlagsstruktur, der hvert underliggende lag av elektroniske enheter er synkronisert med det underliggende. Jo lavere det teknologiske laget er, jo mindre nøyaktig vil tiden oppnådd fra det være. Men dette er i teorien, i praksis avhenger alt av mange parametere som er involvert i synkroniseringssystemet, og mer nøyaktig tid kan oppnås, for eksempel fra det fjerde laget av enheter enn fra det tredje.

På nullnivået i denne overføringskjeden er det alltid tidsrapporteringsenheter, grovt sett klokker. Disse klokkene er molekylære, atomære eller kvantetidsholdende enheter og kalles referanseklokker. Slike enheter overfører ikke tidsparametere direkte til Internett, de er vanligvis koblet til den primære datamaskinen via et høyhastighetsgrensesnitt med minimale forsinkelser. Det er disse datamaskinene som utgjør det første laget i den teknologiske kjeden. På det andre laget vil det være maskiner som mottar tid fra det første laget med enheter via en nettverkstilkobling, oftest via Internett. Alle påfølgende lag vil motta informasjon om nøyaktig tid ved å bruke de samme nettverksprotokollene fra de overliggende lagene.

Systemer synkronisering tid

I i samsvar med den føderale loven "On Communications" nr. 126 av 7. juli 2003, artikkel 49 - "Regnskaps- og rapporteringstid innen kommunikasjon", i de teknologiske prosessene for overføring og mottak av telekommunikasjons- og postmeldinger, deres behandling innen territoriet til den russiske føderasjonen av telekommunikasjonsoperatører og postoperatører bør bruke en enkelt regnskaps- og rapporteringstid - Moskva." For å gjøre dette er det nødvendig å organisere et nøyaktig tidssystem på det digitale nettverket til telekommunikasjonsoperatøren.

Et nøyaktig tidssystem er et sett med tekniske midler som gir periodisk overføring av digital informasjon om verdien av gjeldende tid fra en referansekilde til alle nettverkselementer for å synkronisere deres interne klokker. Dette gjelder digitalt utstyr i telenett, hvor ulike data behandles i sanntid og samtidig utførelse av enkelte interne teknologiske prosesser må sikres.

Relevansen av å løse problemet med å organisere et synkroniseringssystem for en enkelt nøyaktig tid, eller, med andre ord, organisere tidssynkronisering, i telekommunikasjonsnettverk er uløselig knyttet til utviklingen av faktureringssystemer, kontrollsystemer for ulike formål, nettverkssikkerhet, datamaskin systemer, samt forbedring av metodene for drift av digitalt telekommunikasjonsutstyr og metrologisk støtte .

Forbrukere av ensartede presise tidssignaler er: datasystemer og dataservere (nettverksutstyrsadministrasjon og overvåkingssystemer), utstyr for SDH, ATM, IP-transportnettverk og byttenettverk, fakturerings- og databaseservere; dataoverføring og pakkesvitsjutstyr (rutere, svitsjer) etc.

Bruken av tidssynkronisering lar deg synkronisere start- og sluttid for enhver prosess i nettverket til en eller forskjellige telekommunikasjonsoperatører, for eksempel når du lokaliserer en ulykke ved hjelp av intern utstyrsdiagnostikk og oppretter en loggoppføring om hendelsen som skjedde på server i kontrollsystemet, tilkobling av abonnentens samtaler, tariffering av informasjonstrafikk i henhold til klokkeslett og plassering av abonnenten i tjenesteområdet til et bestemt nettverk, og til slutt, utførelse av prosedyrer knyttet til bekreftelse av mottak/ overføring av elektronisk signatur, utføre transaksjoner mv.

Arbeidet med å lage et nøyaktig tidssystem inkluderer:

* valg av eksakt tidssignalkilde;

* bestemmelse av metoden for å overføre presise tidssignaler over et kommunikasjonsnettverk;

* utvalg av nettverksprotokoller og presise tidssignaler;

* identifikasjon av utstyr som krever tidssynkronisering;

* utvalg av løsningsalternativer for å gi ulike typer utstyr presise tidssignaler.

Blant de høypresisjons- og rimeligste midlene for å overføre tidssignaler som ikke krever leie av eksisterende eller bygging av ytterligere kommunikasjonslinjer, kan man med rette inkludere globale navigasjonssatellittsystemer (GNSS): russisk GLONASS og amerikansk GPS. Systemenes globalitet sikres ved drift i bane av et sett med satellitter som er synlige fra hvor som helst på jorden, som kontinuerlig sender høypresisjonssignaler som kan brukes i et nøyaktig tidssystem.

Foreløpig er for eksempel satellittsystemet GPS kan brukes til å synkronisere utstyr til telekommunikasjonsnettverk til russiske telekommunikasjonsoperatører bare som en andre prioritet, derfor er det nødvendig å bruke et satellittsystem som hovedkilden til presise tidssignaler GLONASS.

For å få en tidsskala fra satellittsystemer, er det nødvendig å bruke spesialutstyr som inneholder signalmottakere GLONASS Og GPS. Dette spesialiserte utstyret kalles en tidsserver ( TidServer). Ved overføring av tidssignaler fra serveren til eksterne nettverksklienter, brukes spesielle Internett-protokoller NTP(NettverkTidprotokoll) Og PTP(PresisjonTidProtokoll- IEEE1588). Basert på nettverksprotokoller er det tilrådelig å bygge et nøyaktig tidssystem i henhold til hierarkiprinsippet.

NTP-PROTOKOLL

NTP-protokollen (Network Time Protocol) brukes av NTP-servere for å distribuere informasjon om en nøyaktig referansetid mellom nettverksabonnenter. Det brukes også av Internett-verktøy for å sikre synkronisering av datamaskiner og prosesser.

NTP har vært brukt som internettprotokoll i over 25 år. Denne protokollen er den lengst brukte Internett-protokollen. Det ble født ut av behovet for å synkronisere tid og prosesser på Internett. NTP-protokollen ble først brukt på LINUX- og UNIX-plattformer inkludert FreeBSD (en ikke-kommersiell versjon av UNIX for PC-er), men kom senere til å bli brukt på Windows-operativsystemet. Spesielle NTP-systemer bruker hovedsakelig LINUX-operativsystemet.

I tillegg, i tillegg til NTP-protokollen, er det SNTP (Simple Network Time Protocol). På pakkenivå er de to protokollene fullstendig kompatible. Hovedforskjellen mellom dem er at SNTP ikke har de komplekse filtreringssystemene og flertrinns feilretting som finnes i NTP. Dermed er SNTP en forenklet og enklere å implementere versjon av NTP. Den er beregnet for bruk i nettverk der svært høy tidsnøyaktighet ikke er nødvendig, og i Microsofts implementering gir den nøyaktighet innen 20 sekunder innenfor en bedrift og ikke mer enn 2 sekunder innenfor et enkelt nettsted. SNTP-protokollen er standardisert som RFC 1769 (versjon 3) og RFC 2030 (versjon 4).

Grunnleggende prinsipper protokoll NTP

Protokoll NTP ble opprettet for å gi nettverksbrukere tre parametere:

1) innstilling av en tidsstandardfeil;

2) innstilling av en full syklus av tidsforsinkelse;

3) innstilling av spredningen av parametere i forhold til spesialiserte referanseklokker.

Tidsreferansefeil er tidsforskjellen mellom den lokale klokken og referanseklokken. En full syklus med latens er hvor lang tid det tar for protokollen å motta et svar fra serveren. Spredningen av parametere er den maksimale feilen til den lokale tidsklokken i forhold til standarden.

Meldinger protokoll NTP

Protokoll NTP bruker UDP (User Datagram Protocol) En NTP-melding består av flere felt:

1) Hoppindikator;

2) Versjonsnummer;

6) Nøyaktighet;

7) Feil i rotsystemet;

8) Variasjon av parametere;

9) Standard ID;

10) Dato for opprettelse;

11) Tidsstempel for mottak;

12) Overføringstidsstempel;

13) Kodegjenkjenning;

14) Meldingssammendrag.

Hoppindikatoren varsler om et forestående summerings- eller slettehopp.

Versjonsnummeret viser NTP-versjonsnummeret som brukes.

Modus hjelper deg med å angi modusen for gjeldende NTP-melding.

Decomposer er et 8-bits system som identifiserer det hierarkiske nivået til referanseklokken.

Avstemning definerer maksimalt intervall mellom meldinger.

Nøyaktighet etablerer troverdigheten til den lokale klokken.

Rotfeilen indikerer den nominelle tidsreferansefeilen.

Standardidentifikatoren er en 4-tegns ASCII-kode som identifiserer kilden til standarden, for eksempel: GPS, DCF, MSF. Kodeidentifikator-feltet brukes når det er nødvendig å fastslå gyldigheten av koden.

Mønsteropprettelsesdatoen angir tidspunktet når brukerens NTP-forespørsel ble sendt til NTP-serveren.

Det mottatte tidsstemplet angir tidspunktet forespørselen ble mottatt av NTP-serveren.

Overføringstidsstemplet angir tidspunktet da NTP-serverens svarmelding ble overført til brukeren.

Sammendragsfeltet lagrer meldingsautentiseringskoden MAC (Message Authentication Code).

Modi arbeid NTP servere

NTP serveren kan operere i tre moduser:

I de to første modusene sender brukeren en NTP-forespørsel til serveren. Serveren svarer med en melding som brukeren bruker til å synkronisere NTP-tid. I multicast-modus sendes NTP-meldinger med jevne mellomrom med angitte tidsintervaller.

Referanseklokke

For å synkronisere tiden til NTP-servere, kan ulike eksterne kilder til nøyaktig tid brukes. GPS brukes veldig ofte for å sikre tidsnøyaktighet. Det finnes også ulike offentlige kilder til referansetid, for eksempel radiokringkasting. Mange radiostasjoner sender ikke bare på territoriet til statene deres, men også i utlandet, slik at du enkelt kan stille inn tiden ved å bruke dem.

SNTP-PROTOKOLL

protokollprogramsynkroniseringsfil

SNTP(engelsk: Simple Network Time Protocol) - tidssynkroniseringsprotokoll over et datanettverk. Det er en forenklet implementering av NTP-protokollen. Brukes i innebygde systemer og enheter som ikke krever høy presisjon, samt i tilpassede tidsprogrammer. SNTP-protokollen bruker samme tidsformat som NTP-protokollen – et 64-bits tall som består av en 32-bits sekundteller og en 32-bits brøksekunderteller. En nullverdi på tidstelleren tilsvarer null timer 1. januar 1900, 6 timer 28 minutter 16 fra 7. februar 2036 osv. For at protokollen skal fungere vellykket, er det nødvendig at klienten kjenner sin tid innen ±34 år i forhold til servertiden.

Format meldinger

Figur 1 - Meldingsformat

Beskrivelse av feltene i SNTP-meldingsformatet vist i figur 1:

Korreksjonsindikatoren (IC) viser en advarsel om fremtidig innsetting eller sletting av et sekund i dagens siste minutt;

Versjonsnummer (NV) -- gjeldende verdi er 4;

Polling Interval er et heltall uten fortegn hvis binære eksponent representerer det maksimale intervallet mellom påfølgende meldinger i sekunder. Definert kun for servermeldinger, gyldige verdier fra 4 (16 s) til 17 (ca. 36 timer);

Presisjon er et fortegnet heltall hvis binære eksponent representerer presisjonen til systemklokken. Definert kun for servermeldinger, er typiske verdier ?6 til ?20;

Latency er et signert tall med et fast punkt, plassert mellom 15 og 16 sifre, som viser den totale tiden det tar for signalet å forplante seg frem og tilbake til tidsserversynkroniseringskilden. Definert kun for servermeldinger;

Varians er et usignert fastpunktnummer mellom 15 og 16 sifre som indikerer maksimal feil på grunn av klokkeustabilitet. Definert kun for servermeldinger;

Kilde-ID -- serversynkroniseringskilde, streng for stratum 0 og 1, IP-adresse for sekundære servere. Definert kun for servermeldinger;

Oppdateringstid -- tid da systemklokken sist ble stilt eller justert;

Identifikasjonsnøkkel, meldingssammendrag - valgfrie felt som brukes for autentisering.

Drift servere SNTP

Server SNTP kan operere i unicast-, onecast- eller multicast-modus, og kan også implementere en hvilken som helst kombinasjon av disse modusene. I unicast- og anycast-modus mottar serveren forespørsler (modus 3), modifiserer visse felt i NTP-headeren og sender et svar (modus 4), muligens ved å bruke samme meldingsbuffer som forespørselen. I unicast-modus lytter serveren til en spesifikk IANA-definert kringkastings- eller multicast-adresse, men bruker sin egen unicast-adresse i svarets kildeadressefelt. Med unntak av valg av adresse i svaret, er driften av serveren i unicast- og unicast-modus identisk. Multicast-meldinger sendes vanligvis med intervaller på 64 til 1024 sekunder, avhengig av stabiliteten til klientens klokke og den nødvendige nøyaktigheten.

I anycast- og unicast-modus kopieres VN- og registreringsfeltene (Poll) for forespørselen uten endringer i svaret. Hvis forespørselsmodusfeltet inneholder kode 3 (klient), settes det til 4 (server) i svaret; ellers skrives dette feltet til 2 (symmetrisk passiv) for å sikre samsvar med NTP-spesifikasjonen. Dette lar klienter som er konfigurert for symmetrisk aktiv modus (modus 1) fungere vellykket selv om konfigurasjonen ikke er optimal. I multicast-modus i felten VN kode 4 legges inn, i modusfeltet kode 5 (kringkasting) og i registreringsfeltet er heltallsdelen verdien av base 2-logaritmen for varigheten av forespørselssendingsperioden.

I unicast- og anycast-modus kan serveren svare eller ignorere forespørsler, men den foretrukne oppførselen er uansett å sende et svar, siden det lar deg bekrefte at serveren er tilgjengelig.

Den viktigste indikatoren på serverfeil er LI-feltet, der en kode på 3 indikerer mangel på synkronisering. Når denne spesielle verdien mottas, MÅ klienten ignorere serverens melding, uavhengig av innholdet i de andre feltene.

Konfigurasjon Og kontroll

Opprinnelig SNTP-servere og klienter kan konfigureres basert på en konfigurasjonsfil, hvis en slik fil finnes, eller via den serielle porten. Det antas at SNTP-servere og -klienter krever liten eller ingen vertsspesifikk konfigurasjon (utover en IP-adresse, subnettmaske eller OSI NSAP-adresse).

Unike klienter må gis servernavnet eller adressen. Hvis et servernavn brukes, trengs en eller flere adresser til de nærmeste DNS-serverne.

Multicast-servere og anycast-klienter må være utstyrt med en TTL-verdi, samt en lokal kringkastings- eller multicast-multicastadresse. Anycast-servere og multicast-klienter kan konfigureres ved hjelp av lister over adresse-maske-par. Dette gir tilgangskontroll slik at transaksjoner kun vil skje med kjente klienter eller servere. Disse serverne og klientene må støtte IGMP-protokollen og også kjenne den lokale kringkastings- eller multicast-adressen.

LISTE OVER INTERNETSKILDER BRUKT

1) https://ru.wikipedia.org/wiki/Rsync;

2) http://greendail.ru/node/487;

3) http://inetedu.ru/articles/19-services/70-synchronization-time.html;

4) http://www.ptime.ru/exec_time.htm;

5) http://www.tenderlib.ru/articles/56;

6) http://docstore.mik.ua/manuals/ru/inet_book/4/44/sntp4416.html;

7) http://www.ixbt.com/mobile/review/billing.shtml.

APPLIKASJONER

Vedlegg A

MD4(Message Digest 4) er en hash-funksjon utviklet av University of Massachusetts professor Ronald Rivest i 1990, og først beskrevet i RFC 1186. Gitt en vilkårlig inngangsmelding, genererer funksjonen en 128-bits hash-verdi kalt en meldingssammendrag. Denne algoritmen brukes i MS-CHAP-autentiseringsprotokollen, som ble utviklet av Microsoft for å utføre autentiseringsprosedyrer på eksterne Windows-arbeidsstasjoner. Det er forgjengeren til MD5.

Figur A - MD4-drift

Én MD4-operasjon (Figur A). MD4 hashing består av 48 slike operasjoner, gruppert i 3 runder med 16 operasjoner. F -- ikke-lineær funksjon; i hver runde endres funksjonen. Mi betyr 32-bits inngangsmeldingsblokk, og Ki er en 32-bits konstant, forskjellig for hver operasjon.

Vedlegg B

Rullende sjekksum

Ringformethasj rullende hash - en hash-funksjon som behandler inndata innenfor et bestemt vindu. Å skaffe hashverdien for det forskjøvede vinduet i slike funksjoner er en billig operasjon. For å beregne verdien på nytt trenger du bare å kjenne den forrige hashverdien; verdien av inndataene som forble utenfor vinduet; og betydningen av dataene som kom inn i vinduet. Prosessen ligner på å beregne glidende gjennomsnitt.

Brukes i Rabin-Karps understrengsøkealgoritme, samt i rsync-programmet for å sammenligne binære filer (ringversjonen av adler-32 brukes).

Vedlegg C

Andrew Tridgell

Andrew"Tridge"Tridgell(28. februar 1967) -- Australsk programmerer, kjent som forfatter og bidragsyter til Samba-prosjektet og medskaper av rsync-algoritmen. Han er også kjent for sitt arbeid med å analysere komplekse proprietære protokoller og algoritmer, noe som fører til etableringen av interoperable gratis implementeringer. Vinner av Free Software Award for 2005.

GratisProgramvareTildele-- FSFs årlige pris for bidrag til fri programvare, grunnlagt i 1998.

Figur C - Andrew Tridgell

Skrevet på Allbest.ru

Lignende dokumenter

Analyse av hovedangrepene på TLS-protokollen og identifisering av metoder for å motvirke disse angrepene. Utvikling av en metode for å avskjære og dekryptere trafikk overført via HTTPS-protokollen. Dekryptering av overførte data i nesten sanntid.

artikkel, lagt til 21.09.2017


Opprettelse av UNIX-operativsystemet. Historie om opprettelse og utvikling av TCP/IP-protokoller. Transportprotokoll. En logisk kommunikasjonskanal mellom enheten og utdataene uten å etablere en kobling. Protokoll for interaksjon med en domenenavnserver.

test, lagt til 18.05.2009


Typer systemenhetstilfeller. Grunnleggende nettverkstopologier: buss, ring, stjerne, tre. FTP er en protokoll utviklet for å overføre filer over datanettverk. Programvareklassifisering. Systemer for gjenfinning av informasjon og deres klassifisering.

test, lagt til 24.12.2010


Definisjon av en IP-protokoll som overfører pakker mellom nettverk uten å etablere tilkoblinger. IP-pakkehodestruktur. Initialisering av en TCP-tilkobling, dens stadier. Implementering av IP på ruteren. Protokoll for pålitelig levering av TCP-meldinger, dets segmenter.

test, lagt til 11.09.2014


Konseptet med Secure Sockets Layer-protokollen. "Sikker kanal", grunnleggende egenskaper. Bruk av protokollen, dens ulemper. EtherSnoop programgrensesnitt. Dialogprotokollfaser. Offentlige nøkler, distribusjonsfunksjoner. Utveksling av data på Internett.

sammendrag, lagt til 31.10.2013


Generell informasjon om FTP-dataoverføringsprotokollen. Tekniske prosesser for å opprette en tilkobling ved hjelp av FTP-protokollen. Programvare for å opprette tilkoblinger ved hjelp av FTP-protokollen. Noen problemer med FTP-servere. FTP-protokollkommandoer.

sammendrag, lagt til 11.07.2008


Beskrivelse og formål med DNS-protokollen. Bruker vertsfilen Funksjoner og beskrivelse av metoder for angrep på DNS: falsk DNS-server, enkel DNS-flom, phishing, angrep gjennom reflekterte DNS-forespørsler. Beskyttelse og motarbeid mot angrep på DNS-protokollen.

abstrakt, lagt til 15.12.2014


Utvikling av et serverprogram som lar deg fjernovervåke en datamaskin som kjører Linux. Betingelser som er nødvendige for å løse dette problemet: brukte dataoverføringsprotokoller, programvare, dynamiske biblioteker.

kursarbeid, lagt til 18.06.2009


Beskrivelse av hovedtyper av HDLC-protokollstasjoner. Normale, asynkrone og balanserte driftsmoduser for stasjonen i tilstanden for informasjonsoverføring. Metoder for kontroll av dataflyt. Format og innhold av informasjon og kontrollfelt for HDLC-protokollen.

laboratoriearbeid, lagt til 10.02.2013


Funksjonen til protokollen og pakkestrukturen til protokollen som utvikles. Lengde på overskriftsfelt. Beregning av mottaksbufferlengden avhengig av pakkelengden og akseptabel forsinkelse. Algoritmer for databehandling ved mottak og overføring. Programvareimplementering av protokollen.

65 nanometer er neste mål for Zelenograd-anlegget Angstrem-T, som vil koste 300-350 millioner euro. Selskapet har allerede sendt inn en søknad om et fortrinnsrettslån for modernisering av produksjonsteknologier til Vnesheconombank (VEB), rapporterte Vedomosti denne uken med henvisning til styreleder for anlegget, Leonid Reiman. Nå forbereder Angstrem-T å lansere en produksjonslinje for mikrokretser med en 90nm topologi. Betalinger på det forrige VEB-lånet, som det ble kjøpt for, starter i midten av 2017.

Beijing krasjer Wall Street

Viktige amerikanske indekser markerte de første dagene av det nye året med et rekordfall milliardæren George Soros har allerede advart om at verden står overfor en gjentakelse av 2008-krisen.

Den første russiske forbrukerprosessoren Baikal-T1, priset til $60, lanseres i masseproduksjon

Baikal Electronics-selskapet lover å lansere den russiske Baikal-T1-prosessoren til industriell produksjon som koster rundt $60 i begynnelsen av 2016. Enhetene vil være etterspurt hvis regjeringen skaper denne etterspørselen, sier markedsaktørene.

MTS og Ericsson skal i fellesskap utvikle og implementere 5G i Russland

Mobile TeleSystems PJSC og Ericsson har inngått samarbeidsavtaler om utvikling og implementering av 5G-teknologi i Russland. I pilotprosjekter, inkludert under verdensmesterskapet i 2018, har MTS til hensikt å teste utviklingen til den svenske leverandøren. I begynnelsen av neste år vil operatøren innlede en dialog med Tele- og om utformingen av tekniske krav til femte generasjon mobilkommunikasjon.

Sergey Chemezov: Rostec er allerede et av de ti største ingeniørbedriftene i verden

Sjefen for Rostec, Sergei Chemezov, svarte i et intervju med RBC på presserende spørsmål: om Platon-systemet, problemene og utsiktene til AVTOVAZ, interessene til State Corporation i farmasøytisk virksomhet, snakket om internasjonalt samarbeid under forhold med sanksjonspress , importsubstitusjon, omorganisering, utviklingsstrategi og nye muligheter i vanskelige tider.

Rostec «gjerder seg selv» og griper inn på laurbærene til Samsung og General Electric

Representantskapet i Rostec godkjente "Utviklingsstrategien frem til 2025". Hovedmålene er å øke andelen høyteknologiske sivile produkter og ta igjen General Electric og Samsung når det gjelder økonomiske nøkkelindikatorer.