Moderne systemen, zoals transiënte bewakingssystemen (SMPR), evenals relaisbeveiliging en -automatisering (RPA) met behulp van een procesbus, vereisen een hoge binnen 1 µs. Deze vereisten zijn strenger dan die van andere ond(1-2 ms). Tegelijkertijd worden tegenwoordig in het kader van automatiseringssystemen voor stroomvoorzieningen veel Ethernet-netwerken gebruikt, waarmee informatie wordt uitgewisseld tussen SCADA-systemen en relaisbeveiligingsapparaten, evenals tussen individuele relaisbeveiligingsapparaten. Het Precision Time Protocol (PTP) is een tijdsynchronisatieprotocol dat via een Ethernet-netwerk werkt zonder speciale communicatielijnen te gebruiken en de vereiste kan bieden voor relaisbeveiligingsapparaten, transiënte recorders, procesbuskoppelingen en andere apparaten die een hoge nauwkeurigheid vereisen. tijd synchronisatie.

Problemen met bestaande tijdsynchronisatieprotocollen

Bij energiecentrales wordt al een aantal jaren tijdsynchronisatie van apparaten uitgevoerd. Het is met name noodzakelijk om ervoor te zorgen dat gebeurtenissen die door verschillende apparaten zijn geregistreerd, kunnen worden gecorreleerd. Tegelijkertijd biedt het grootste aantal tijdsynchronisatiemethoden een nauwkeurigheid binnen 1 ms. Met het begin van de introductie van SMPR- en RPA-systemen die de procesbus gebruiken, wordt het noodzakelijk om een ​​hogere nauwkeurigheid van apparaatsynchronisatie in de tijd te garanderen - binnen 1 μs.

Er zijn twee benaderingen voor het uitvoeren van tijdsynchronisatie van secundaire apparaten:

• Een onafhankelijk systeem gebruiken dat speciale informatietransmissiekanalen en repeaters omvat.
• Gebruik van het Ethernet-netwerk, waarmee ook toepassingsinformatie wordt uitgewisseld tussen de apparaten van de energievoorziening.

In de volgende paragrafen worden de meest gebruikte methoden voor tijdsynchronisatie en hun voor- en nadelen besproken.

Onafhankelijke tijdsynchronisatiesystemen gebruiken

Historisch gezien vertrouwden tijdsynchronisatiesystemen bij stroomvoorzieningen op het gebruik van speciale communicatielijnen (coaxiale, twisted pair, glasvezelcommunicatielijnen (FOCL)). Hiervoor werden twee protocollen gebruikt:

• IRIG-B levert tijd- en datuminformatie samen met klokpulsen.
• 1-PPS levert een nauwkeurige tijdsynchronisatiepuls zonder tijd- en datuminformatie.

Bij gebruik van deze protocollen heeft gegevensuitwisseling tussen RPA-apparaten en het SCADA-systeem, evenals tussen individuele RPA-apparaten, geen invloed op de nauwkeurigheid van de synchronisatie. Er moet echter worden opgemerkt dat onafhankelijke systemen duur zijn om te implementeren vanwege de noodzaak om extra kabelproducten, klemmenblokken, repeaters, enz. te gebruiken. Het vereist ook de ontwikkeling van een set relevante technische documentatie. De kosten kunnen aanzienlijk zijn, vooral bij het implementeren van tijdsynchronisatiesystemen bij hoogspanningsinstallaties.

Rijst. 1 illustreert het gebruik van het IRIG-B-protocol voor tijdsynchronisatie van apparaten en het Ethernet-netwerk voor het organiseren van informatie-uitwisseling tussen apparaten. In plaats van een Ethernet-netwerk kan het gebruik van RS-485-communicatielijnen worden voorzien, wat typerend is voor oudere stroomvoorzieningen.

Rijst. 1. Illustratie van de scheiding van tijdsynchronisatie- en gegevensuitwisselingssystemen binnen eenem.

ProtocolIRIG– B

Het meest gebruikelijke tijdsynchronisatieprotocol dat wordt gebruikt in energievoorzieningen is het IRIG-B-protocol. Bij het implementeren van synchronisatiesystemen op basis van dit protocol is het gebruik van speciale communicatielijnen vereist. Het protocol kan in een van de volgende formaten werken: met de overdracht van informatie in de vorm van pulsen over elektrische verbindingen (coaxkabel of twisted pair) of glasvezellijnen, of met de overdracht van een gemoduleerd signaal met een draaggolffrequentie van 1 kHz over een coaxkabel. In de loop van de tijd is het IRIG-B-protocol uitgebreid, voornamelijk als gevolg van de opkomst van IEEE-standaarden met betrekking tot de implementatie van de SMRM (IEEE Std 1344-1995, IEEE Std C37.118-2005 en IEEE Std C37.118.1-2011) . Deze extensies bieden de mogelijkheid om informatie over het jaar, tijdverschil met Coordinated Universal Time (UTC), zomertijd en informatiekwaliteit over te brengen. Al deze informatie wordt gebruikt door apparaten vanmen. Het ongemoduleerde IRIG-B-signaal bereikt timingnauwkeurigheid in het bereik van microseconden, maar de meeste client-apparaten kunnen vanwege hun technische kenmerken niet meer dan 1-2 ms nauwkeurigheid bieden.

IRIG-B beschrijft verschillende opties voor formaten voor informatieoverdracht. De kenmerken van tijdsynchronisatie-interfaces van RPA-apparaten van verschillende fabrikanten verschillen echter, waardoor het niet mogelijk is om slechts één IRIG-B-tijdcodetransmissieformaat op de tijdserver te gebruiken. Een van de meest voorkomende verschillen is het gebruik van een gemoduleerd/ongemoduleerd signaal, het gebruik van lokale of universeel gecoördineerde tijd (UTC) als referentie, enz.

Verschillende implementaties van het IRIG-B-protocol worden geïdentificeerd door een tijdcode. Bijvoorbeeld:

• B003: ongemoduleerd, geen IEEE-verlengingen/jaarverlengingen.
• B004: ongemoduleerd, met IEEE-extensies/jaarverlengingen.
• B124: AM gemoduleerd met jaarverlengingen/IEEE-verlengingen.

Rijst. 2 toont een vergelijking van ongemoduleerde en gemoduleerde signalen die worden gebruikt door tijdcodeformaten (volgens de IRIG-standaard 200-04).

Rijst. 2. De vorm van het gemoduleerde en ongemoduleerde IRIG-B-signaal.

De instellingen van client-apparaten, zoals RPA-apparaten, moeten consistent zijn met de instellingen van de hoofdklok: in termen van universeel gecoördineerde tijd (UTC) / lokale tijd, tijdzone, enz. De flexibiliteit van het instellen van RPA-apparaten varieert aanzienlijk - zelfs bij gebruik van apparaten van dezelfde fabrikant. Sommige van de RPA-apparaten kunnen worden geconfigureerd om bijna alle IRIG-B-tijdcodeformaten te accepteren, vele hebben vrij sterke beperkingen in termen van parametrering.

Andere problemen die het IRIG-B-protocol met zich meebrengt, zijn onder meer: ​​​​de noodzaak om rekening te houden met de belasting van hetwerk, het bieden van bescherming tegen elektromagnetische interferentie, galvanische isolatie van circuits en de noodzaak om communicatielijnen te onderhouden. De toegestane belasting van de hoofdklok varieert in het bereik van 18 tot 150 mA, terwijl relaisbeveiligings- en automatiseringsapparaten van verschillende fabrikanten een verschillend verbruik hebben (van 5 mA tot 10 mA). Dit bemoeilijkt het ontwerp van tijdsynchronisatiesystemen voor een groot aantal relaisbeveiligingsapparaten - bijvoorbeeld op distributiestations (6,6 - 33 kV).

1- PPS(één puls per seconde)

1-PPS (één puls per seconde) kan worden gebruikt voor een redelijk nauwkeurige tijdsynchronisatie, maar geeft geen astronomische tijdinformatie. Tegenwoordig is dit voldoende om relaisbeveiligingssystemen te implementeren met behulp van een procesbus, maar in de toekomst zal waarschijnlijk tijdinformatie nodig zijn voor tijdstempels van gebeurtenissen of cryptografische berichtauthenticatie.

Het gebruik van deze tijdsynchronisatiemethode wordt voorzien door de norm IEC 60044-8 en wordt ook geïntroduceerd in de specificatie voor de implementatie van de digitale interface voor instrumenttransformatoren (bekend als IEC 61850-9-2LE). De IEC 61869-9-standaard die momenteel in ontwikkeling is, maakt deze methode van tijdsynchronisatie van apparaten ook mogelijk via een speciale glasvezelverbinding.

Rijst. 3 illustreert de 1PPS-pulsvereisten. Tijd om signaal te veranderen van 10% naar 90% vermogen (en vice versa) ( tf) signaal mag niet hoger zijn dan 200 ns. De levensduur van het signaal op een niveau van meer dan 50% van het vermogen ( th) moet tussen 10 µs en 500 ms liggen.

Rijst. 3. Grafische weergave van het 1-PPS-signaal.

1-PPS vereist een speciaal netwerk voor signaaldistributie. Ofwel een elektrische communicatielijn (coaxiaal/twisted pair) of FOCL (multi-mode/single-mode) kan worden gebruikt als het fysieke medium voor gegevensoverdracht.

synchronisatie vertraging

Voortplanting van IRIG-B- en 1-PPS-signalen is veel gemakkelijker via elektrische verbindingen dan via FOCL, aangezien er meerpuntsverbindingen kunnen worden geleverd, rekening houdend met de toegestane belasting van de hoofdklok, maar dit kan leiden tot een toename van het potentieel tussen kasten. Het gebruik van FOCL zorgt voor galvanische isolatie en elimineert de invloed van interferentie, maar in dit geval is het gebruik van speciale repeaters vereist om het signaal naar elk van de RPA-apparaten van de energievoorziening te verspreiden. Met name IEC 61850-9-2LE vereist het gebruik van FOCL voor 1-PPS-signaaloverdracht. Dit vereist op zijn beurt het gebruik van een klok met meerdere uitgangen of een splitter om meer dan één procesbuskoppeling te signaleren.

De signaalvoortplantingsvertraging over elektrische verbindingen en glasvezellijnen is ongeveer 5 ns per meter. De resulterende waarde kan behoorlijk groot zijn voor lange links en kan op zijn beurt latentiecompensatie op clientapparaten vereisen. IEC 61850-9-2LE stelt een waarde van 2 µs in als limiet voor voortplantingsvertraging - compensatie is vereist als deze waarde wordt overschreden. Zo'n vertraging resulteert in een aansluiting van ongeveer 400 m, en in veel hoogspanningsstations zijn dergelijke afstanden niet de limiet. Compensatie is een handmatig afstemmingsproces, waarbij nauwkeurig rekening moet worden gehouden met de signaalvoortplantingsvertraging, niet alleen langs de communicatielijn, maar ook via de gebruikte repeaters. Een meer gedetailleerde studie van de voortplantingsvertragingen van synchronisatiesignalen over de 1-PPS-, IRIG-B- en PTP-protocollen wordt gegeven in.

Netwerktijdsynchronisatieethernet

Ethernet-netwerken, die nu steeds vaker worden gebruikt inmen, kunnen ook worden gebruikt om tijdsynchronisatiesignalen te verzenden. Het bovenstaande maakt het mogelijk om de noodzaak voor het leggen van speciale communicatielijnen te elimineren, maar het vereist relaisbeveiligingsapparaten, elektriciteitsmeters en andere secundaire apparaten om speciale protocollen te ondersteunen.

De twee meest gebruikte protocollen voor tijdsynchronisatie zijn Network Time Protocol (NTP) en Precision Time Protocol (PTP). Beide protocollen werken, wanneer ze in onderstations worden gebruikt, door berichten uit te wisselen via een Ethernet-netwerk. De NTP- en PTP-protocollen bieden compensatie voor tijdvertragingen bij de verzending van synchronisatieberichten door tweerichtingsinformatie-uitwisseling. Het NTP-protocol is een meer gebruikelijke oplossing dan het PTP-protocol, maar door het gebruik van speciale hardware wordt een hogere nauwkeurigheid gegarandeerd bij het gebruik van het laatste. Op afb. 4 illustreert een netwerktopologie waarbinnen zowel het NTP-terugvalprotocol als het PTP-terugvalprotocol kan worden gebruikt.

Het werkingsmechanisme van beide protocollen maakt de aanwezigheid van meerdere hoofdklokken mogelijk, wat de betrouwbaarheid van de werking van het tijdsynchronisatiesysteem bij de energievoorziening verhoogt. Bovendien maakt de aanwezigheid van meerdere hoofdklokken het onderhoud van een ervan mogelijk zonder het hele systeem buiten werking te stellen.

ProtocolNTP

In de afgelopen jaren is het NTP-protocol veel gebruikt in energievoorzieningen. Bij gebruik van op de markt verkrijgbare tijdservers en clients (bijvoorbeeld RPA-apparaten) die dit communicatieprotocol ondersteunen, is een in het bereik van 1 tot 4 ms haalbaar. Een van de voorwaarden om een ​​dergelijke nauwkeurigheid te waarborgen, is echter de ontwikkeling van de juiste topologie van het lokale netwerk Ethernet, die de overeenstemming en constantheid van de voortplantingstijden van tijdsynchronisatieberichten van de client naar de master en vice versa garandeert.

Een belangrijk voordeel van NTP ten opzichte van IRIG-B is dat de tijd wordt verzonden in UTC. Dit voldoet aan de vereisten van standaarden zoals IEC 61850 en IEEE 1815 (DNP), die de verzending van gebeurtenistijdstempels in UTC vereisen. Als het nodig is om de lokale tijd op het display van het RPA-apparaat weer te geven, is handmatige instelling van de tijdzone vereist, rekening houdend met de bijbehorende overgang naar zomertijd. Met het NTP-protocol kunnen meerdere tijdservers tegelijkertijd door dezelfde client worden gebruikt voor een nauwkeurigere en betrouwbaardere tijdsynchronisatie. Dit protocol biedt echter niet de timingnauwkeurigheid van microseconden die wordt vereist door SMPR's en IEC 61850-9-2 procesbuskoppelingen.

PTP-protocol

IEEE Std 1588-2008 definieert een tweede versie van het PTP-protocol dat bekend staat als PTPv2 of 1588v2. Dit protocol biedt een hoge nauwkeurigheid van tijdsynchronisatie, die wordt bereikt door de tijdstempels van PTP-synchronisatieberichten op Ethernet-interfaces op hardwareniveau vast te leggen. Het gebruik van deze gegevens maakt het mogelijk om rekening te houden met de voortplantingstijden van synchronisatieberichten over het netwerk en de verwerking ervan door tijdservers en clients. De tijdstempelprocedure op hardwareniveau heeft geen invloed op de werking van andere communicatieprotocollen die in het beschouwde Ethernet-netwerk bestaan, daarom kan dezelfde poort worden gebruikt voor gegevensoverdracht volgens de IEC 61850, DNP3, IEC 60870-5-104, Modbus / IP en andere communicatieprotocollen. De mogelijkheid om op hardwareniveau een tijdstempel te gebruiken, leidt tot een aanzienlijke stijging van de kosten van Ethernet-switches. Wat betreft de ondersteuning van het PTP-protocol in RPA-apparaten, ondersteunen alleen de nieuwste aanpassingen van de apparaten van sommige fabrikanten dit protocol, soms is het alleen beschikbaar als optie.

Dankzij het PTP-protocol kunnen meerdere apparaten op het netwerk fungeren als tijdservers; er wordt aangenomen dat ze allemaal deelnemen aan het onderling stemmen om het meest nauwkeurige horloge te kiezen - grootmeester. Als een grootmeester-horloge plotseling uitvalt of zijn prestaties verslechteren, kan de rol van een grootmeester-horloge worden overgenomen door andere horloges die deze rol claimen. De hoeveelheid tijd die deze procedure in beslag neemt, varieert, maar als het PTP-protocol (ook wel profiel genoemd) is geoptimaliseerd voor gebruik in de energiesector, duurt het niet langer dan 5 seconden.

Inleiding tot PTP

Het PTP-protocol is uiterst flexibel en kan worden gebruikt in een groot aantal toepassingen waarbij tijdsynchronisatie vereist is, met een nauwkeurigheid tot 10 ns.

Hogere nauwkeurigheid werd haalbaar met de komst van de tweede versie van het protocol, die het concept van een transparante klok introduceerde, waarvan de rol wordt gespeeld door Ethernet-switches. De transparante klok meet de tijd die synchronisatieberichten nodig hebben om door de schakelaars te gaan, wat kan variëren afhankelijk van de verkeersbelasting van het netwerk. Informatie over de gemeten tijd wordt langs het pad van het synchronisatiebericht naar andere apparaten verzonden. Dit mechanisme maakt het mogelijk om een ​​hoge nauwkeurigheid van tijdsynchronisatie binnen het lokale Ethernet-netwerk te bereiken. Het gebruik van een transparante klok betekent dat PTP-synchronisatieprotocolberichten geen prioriteit hoeven te krijgen boven ander verkeer op het netwerk, wat het proces van netwerkontwerp en configuratie van netwerkapparatuur vereenvoudigt.

Terminologie

IEEE Std 1588-2008 definieert verschillende termen die van toepassing zijn op systemen die werken onder het PTP-protocol. De belangrijkste termen zijn:

• Grootmeester horloge– een horloge dat de primaire tijdbron is voor PTP-synchronisatie en meestal een ingebouwde GPS-signaalontvanger (of een ander systeem) heeft.
• Toonaangevende klok– een klok die de bron is van tijdgegevens waarmee andere klokken in het netwerk worden gesynchroniseerd.
• slaaf klok– het eindapparaat dat wordt gesynchroniseerd met behulp van het PTP-protocol; het kan een relay-beveiligingsapparaat zijn met native ondersteuning voor het PTP-protocol of een converter die enerzijds informatie ontvangt in het PTP-protocolformaat en anderzijds gegevens genereert in de IRIG-B of 1-PPS protocol formaat.
• transparant horloge- een Ethernet-switch die de tijd meet die een synchronisatiebericht nodig heeft om door zichzelf te reizen en de gemeten waarde doorgeeft aan de klok die vervolgens het synchronisatiebericht ontvangt.
• Grens klok– klokken die zijn uitgerust met meerdere PTP-poorten en kunnen fungeren als hoofdklokken; ze kunnen bijvoorbeeld slaven zijn van stroomopwaartse tijdbronnen en fungeren als meesters van stroomafwaartse apparaten.

Er moet minimaal één grootmeester en één slaafklok op het netwerk zijn. Gezien de noodzaak om veel apparaten in één netwerk te combineren, zal het echter in veel gevallen nodig zijn om schakelaars te gebruiken, die in het eenvoudigste geval zullen werken als transparante klokken. Ze kunnen ook fungeren als een grensklok, waardoor u in sommige gevallen een hogere nauwkeurigheid van tijdsynchronisatie kunt bereiken (ongeacht of dit afhankelijk is van de specifieke fabrikant). Rijst. 5 illustreert een complex waarin tijdsynchronisatie is geïmplementeerd volgens het PTP-protocol. In dit voorbeeld kan de grootmeesterklok informatie over de exacte tijd ontvangen, niet alleen van het Global Positioning System, maar ook van een extern netwerk met behulp van het PTP-protocol. De gespecificeerde oplossing is geïmplementeerd om het falen van de ontvanger van signalen van exacte tijd of de overeenkomstige externe verbindingscircuits te reserveren. In het geval dat wordt overgeschakeld op het gebruik van exacte tijdsignalen van een extern netwerk, is de klok niet langer grootmeester en neemt hij de rol aan van grensklok. Het afgebeelde complex maakt ook gebruik van twee soorten slaafklokken: RPA-apparaten met native PTP-ondersteuning en converters naar de IRIG-B- en 1-PPS-formaten die informatie geven over de exacte tijd voor eindapparaten die het PTP-protocol niet ondersteunen.

Werking in een- en tweetrapsmodus

Het werkingsprincipe van het PTP-protocol is gebaseerd op het feit dat het tijdstip van verzending van een synchronisatiebericht van het Sync-type (alleen dit bericht geeft tijdinformatie door) en het tijdstip van ontvangst van dit bericht op de Ethernet-interface van de slave-klok zijn precies bekend. Het exacte tijdstip van verzending van dit bericht is pas bekend nadat het is verzonden. PTP-compatibele Ethernet-interfaces bieden tijdstempels van berichten op hardwareniveau, en vervolgens wordt deze informatie verzonden naar de centrale processor van de grootmeesterklok. Daarna wordt een follow-upbericht gegenereerd, dat dit exacte tijdstempel van de verzending van een synchronisatiebericht naar alle slave-apparaten verzendt. Tegelijkertijd vult de transparante klok dit bericht aan met informatie over de vertraging in de verzending van dit bericht over het netwerk (de som van de kanaalvertraging en de berichtomleidingstijd). Het gebruik van een combinatie van berichten zoals Sync en Follow Up wordt de tweetrapsmodus van het PTP-protocol genoemd.

De tweede versie van het PTP-protocol (PTPv2) introduceerde de mogelijkheid om de inhoud van een PTP-bericht tijdens de verzending op hardwareniveau te wijzigen. Bij het implementeren van deze methode vervalt de behoefte aan berichten van het type Follow Up; deze werkingsmodus van het PTP-protocol wordt single-stage genoemd. Grandmaster-klokken die deze modus ondersteunen, verzenden berichten van het Sync-type met informatie over het exacte tijdstip van hun vorming, een transparante klok evalueert de vertragingen in de verzending van berichten van dit type (via het netwerk en via zichzelf) en bevat gegevens over de gemeten vertragingen in dezelfde berichten van het type Sync in plaats van deze gegevens op te nemen in Opvolgberichten. Deze manier van werken impliceert een lagere informatiebelasting op het netwerk, maar vereist het gebruik van complexere en duurdere apparaten.

Complexen die werken onder de voorwaarden van het PTP-protocol kunnen grootmeesterklokken bevatten die in een- en tweetrapsmodi kunnen werken. In dergelijke complexen moeten de slaafklokken in staat zijn om rekening te houden met informatie over de vertragingen in de verzending van synchronisatieberichten, rechtstreeks afkomstig van deze berichten die worden gegenereerd door transparante klokken met één trap, evenals van vervolgberichten die worden gegenereerd door transparante klokken met twee trappen. .

ProfielPTP voor de elektriciteitsindustrie (stroom Profiel)

De standaard voor het PTP-protocol omvat verschillende wijzigingen die elkaar wederzijds uitsluiten. De tweede versie van het PTP-protocol (PTPv2) introduceert het concept van profielen, die de waarden van een aantal parameters beperken en het gebruik van bepaalde aspecten van het protocol voor verschillende toepassingen vereisen.

Het vermogensprofiel wordt beschreven in IEEE Std C37.238-2011, waarin een reeks parameters is vastgelegd om de nauwkeurigheid van de tijdsynchronisatie binnen 1 µs te garanderen voor de topologieën die het meest voorkomen in automatiseringssystemen voor onderstations. Dit profiel definieert ook de Management Information Base (MIB) voor het SNMP-protocol, dat de mogelijkheid biedt om belangrijke apparaatparameters te beheren bij gebruik van standaard monitoringprogramma's. Hierdoor wordt het mogelijk om de werking van het tijdsynchronisatiesysteem in realtime te bewaken met alarmvorming in geval van noodsituaties.

Het profiel van het energiebedrijf vereist dat de fouten die door elke afzonderlijke transparante klok worden geïntroduceerd, niet groter zijn dan 50 ns. Dit is vereist om een ​​synchronisatienauwkeurigheid van niet meer dan 1 µs te garanderen bij het organiseren van een lokale netwerktopologie die 16 Ethernet-switches omvat (bijvoorbeeld als onderdeel van een ringtopologie). In dit geval is de toegestane fout voor de GPS-klok ingesteld op 200 ns.

Het PTP-profiel vereist het gebruik van een transparante klok die een peer-to-peer-mechanisme ondersteunt voor het bepalen van kanaalvertragingen, en dat alle PTP-protocolberichten worden verzonden op de linklaag in multicast-modus. Het peer-to-peer vertragingsmechanisme betekent dat elk PTP-apparaat berichten uitwisselt met aangrenzende apparaten om de verbindingsvertragingen van berichten daartussen te meten. De totale tijdvertraging voor de verzending van synchronisatieberichten wordt gedefinieerd als de som van de kanaalvertragingen en de vertragingen van berichtverwerking door de transparante klok die optreden langs de berichtvoortplantingsroute van de grootmeester naar de slaafklokken. Deze manier van werken heeft twee voordelen:

1. Het netwerkverkeer dat door de grootmeesterklok wordt gezien, neemt niet toe naarmate het netwerk uitbreidt. De grootmeesterklok communiceert alleen met de aangrenzende Ethernet-switch (transparante of grensklok).
2. Automatische compensatie voor vertragingen bij het verzenden van berichten wordt uitgevoerd als de hoofdcommunicatieroute uitvalt en de back-up is ingeschakeld. De meting van kanaalvertragingen wordt uitgevoerd op elke communicatielijn, inclusief degene die kunnen worden geblokkeerd door protocollen van de STP-familie.

Niet alle fabrikanten van apparatuur die het PTP-protocol ondersteunen, ondersteunen het profiel voor de energiesector, maar het is vermeldenswaard dat het standaardprofiel beschreven in appendix J.4 van de standaard of in IEEE Std 1588-2008 de vereiste nauwkeurigheid kan bieden met de juiste systeemconfiguratie. Bij gebruik van een ander profiel dan het nutsprofiel, kan niet worden gegarandeerd dat informatie die nodig is vooremapparaten, zoals tijdfout en toepasselijke tijdzone, beschikbaar kan worden gesteld aan klanten. Het garandeert ook niet dat wordt voldaan aan de vereiste kenmerken in termen van de prestaties van de protocolwerking (bijlage J.4 definieert geen prestatie-eisen).

Boundary clocks kunnen worden gebruikt om tussen verschillende profielen te converteren. De grensklok kan bijvoorbeeld een conversie bieden tussen een telecommunicatieprofiel (ITU-T Rec. G.82651.1 Telecommunications Profile) en een profiel voor de energiesector (IEEE Std C37.238 Power Profile). Het verkrijgen van nauwkeurige tijdinformatie van een extern netwerk via een telecommunicatieprofiel kan redundantie bieden voor een uitval van een GPS-ontvanger op een grootmeesterklok. In dit geval zullen ze, zoals eerder vermeld, de rol van grensklok op zich nemen.

Typen protocolberichtenPTP

Het PTP-protocolprofiel voor de elektriciteitssector voorziet in het gebruik van 4 berichtklassen:

1. Typ berichtenSynchroniseren . Deze berichten bevatten tijdinformatie die vanaf de hoofdklok in seconden en nanoseconden is verzonden sinds middernacht op 1 januari 1970.
2. Typ berichtengelijke Vertraging. Deze berichten worden uitgewisseld tussen aangrenzende apparaten om de voortplantingsvertraging van synchronisatieberichten over de communicatielijn daartussen te schatten. Er worden twee of drie verschillende soorten berichten gebruikt om de vertraging te meten, afhankelijk van het feit of er een- of tweetrapswerking wordt gebruikt.
3. Typ berichtenVolgen Omhoog. De berichtgegevens omvatten het exacte tijdstempel van het vorige verzonden Sync-bericht, evenals een correctiewaarde. De correctiewaarde is de som van berichtverwerkingstijden door transparante klokken en kanaalvertragingen op de manier waarop berichten worden verspreid tussen de grootmeesterklok en het gegeven netwerkpunt. Vertegenwoordigd in nanoseconde en fractionele nanoseconde formaat.
4. Typ berichtenAankondigen. De verzending van deze berichten wordt uitgevoerd door een grootmeesterklok, die gegevens levert over de fout in de werking van de bron (bijvoorbeeld een GPS-ontvanger) en andere service-informatie van het PTP-protocol.

Rijst. 6-8 illustreren hoe berichten worden uitgewisseld in een klein netwerk met behulp van een klok die in tweetrapsmodus loopt (omdat de meeste apparaten geen enkeltrapswerking ondersteunen). Berichten van het type Sync worden onveranderd verzonden door transparante klokken. ta- tijdsaanduiding op de grootmeesterklok. Op dezelfde manier worden berichten van het type Aankondiging verzonden.

Type bericht gelijke Vertraging (gelijke Vertraging Verzoek indienen, gelijke Vertraging Antwoord en gelijke Vertraging Volgen Omhoog) wordt alleen uitgevoerd tussen naburige apparaten.

Rijst. 7. Berichten van het type Peer Delay worden alleen uitgewisseld tussen naburige apparaten.

Elke transparante klok definieert een kanaalvertraging in de verzending van berichten tussen zichzelf en aangrenzende apparaten. Terwijl Sync-berichten door transparante klokken gaan, berekenen ze een lokale correctiewaarde door de kanaalvertraging langs het aankomstpad van het bericht op te tellen en de tijd die een Sync-bericht nodig heeft om er doorheen te gaan. Deze lokaal berekende correctiewaarde wordt dan opgeteld bij de correctiewaarde van het corresponderende inkomende Opvolgbericht. Wanneer een follow-upbericht arriveert bij de slave-klok, wordt de door hen gedefinieerde kanaalvertragingswaarde opgeteld bij de correctiewaarde. De resulterende correctiewaarde is de totale tijd die een Sync-bericht nodig heeft om over het netwerk van de master naar de slave te gaan.

Aangezien elk element van het netwerk bijdraagt ​​aan deze totale tijd langs het verspreidingspad van een bericht van het type Sync, zorgt het hierboven beschreven peer-to-peer-mechanisme voor het meten van de kanaalvertragingen van het Power Profile-profiel voor de correcte werking van het protocol in omstandigheden van veranderende netwerktopologie.

Het is belangrijk op te merken dat hoewel vervolgberichten er identiek kunnen uitzien, ze op elk punt in het netwerk anders zullen zijn. De transparante klok verandert de inhoud van deze berichten, waardoor het adres van de grootmeesterklok ongewijzigd blijft.

Op afb. acht tb- de werkelijke tijd van het genereren van het synchronisatiebericht door de grootmeesterklok, die qua waarde dichtbij is, maar niet identiek aan de tijd ta. Elke slaafklok legt het moment vast waarop berichten van het type Sync worden ontvangen en door de tijd vast te leggen die berichten nodig hebben om door de transparante klok te gaan en de kanaalvertragingen, waarvan de som een ​​aanpassingswaarde is, kan rekening worden gehouden met de variabele transmissievertragingen van het Sync-bericht.

Rijst. 8. Vervolgberichten bevatten een aanpassingswaarde die elke transparante klok langs zijn voortplantingspad wordt bijgewerkt.

Voor- en nadelen van het gebruik van het PTP-profiel voor de elektriciteitssector

Het gebruik van het PTP-profiel voor de energiesector (Power Profile) biedt een aantal voordelen:

• De nauwkeurigheid van tijdsynchronisatie is niet afhankelijk van de hoeveelheid netwerkverkeer. Wanneer netwerkapparatuur overbelast raakt, gaan PTP-berichten niet verloren. Hierdoor kunt u dezelfde lokale netwerkinfrastructuur gebruiken bij het implementeren van SMPR- en RPA-complexen, zowel met behulp van de procesbus in overeenstemming met IEC 61850-9-2, als met gebruik van de stationsbus in overeenstemming met IEC 61850-8-1 (met GOOSE-verkeer en /of MMS), evenals complexen die werken op basis van andere communicatieprotocollen (DNP3, enz.).
• De PTP-rapportagesnelheid is geoptimaliseerd om timingnauwkeurigheid van microseconden te bieden zonder onnodige netwerkoverhead en zonder de noodzaak van complexe slave-klokken.
• Zowel optische als elektrische (twisted pair) communicatielijnen kunnen worden gebruikt als fysiek medium voor gegevensoverdracht - het hangt allemaal af van de configuratie van de geselecteerde schakelaars.
• Het maakt gebruik van een enkelvoudig tijdreferentiesysteem, dus het instellen van apparaten ten opzichte van Coordinated Universal Time (UTC)/lokale tijd is niet ingewikkeld. Alle apparaten die het Utilities-profiel ondersteunen, gebruiken International Atomic Time (TAI), die niet onderhevig is aan schrikkelseconden of zomertijd.
• Het nutsprofiel biedt verzending met lokale tijdverschuiving, dus het is niet nodig om de lokale tijd op relaisbeveiligingsapparaten in te stellen. Daarnaast volstaat het om eventuele wijzigingen met betrekking tot de overgang naar zomertijd op de grootmeesterklok door te voeren zonder de instellingen van de RPA-apparaten te wijzigen. Dit mechanisme wordt gedefinieerd door de IEEE 1588-standaard en is dus ook compatibel met apparaten die het Power PTP-profiel niet ondersteunen.
• Het kan mogelijk zijn om reserve-grootmeesterklokken te gebruiken die er automatisch naar overschakelen in het geval van een communicatiefout met de huidige grootmeesterklok of in het geval van verslechtering van hun prestaties.
• Protocollen zoals Rapid Spanning Tree Protocol (RSTP), Parallel Redundancy Protocol (PRP) en High-availability Seamless Ring (HSR) kunnen worden gebruikt om de betrouwbaarheid van de informatie-uitwisseling tussen PTP-apparaten te vergroten.
• Netwerken kunnen worden geschaald zonder extra belasting van de grootmeesterklok.
• Vertragingen in de verspreiding van tijdsynchronisatieberichten over uitgebreide communicatielijnen worden automatisch gecompenseerd, waardoor het niet meer nodig is om procesbuskoppelingen en tijdelijke recorders aan te passen.

Voor meer informatie over prestatiecontroles voor het overschakelen naar de back-up grootmeesterklok, zie . Het materiaal beschouwt scenario's als het verlies van een Ethernet-segment met een geldige grootmeesterklok en het verlies van het GPS-signaal daardoor.

Het PTP-protocol is een vrij complex protocol en om de vereiste nauwkeurigheid van tijdsynchronisatie te bieden, moet met een aantal punten rekening worden gehouden. Daarnaast ontstaan ​​er nieuwe risico's binnen het automatiseringssysteem van een energievoorziening. De volgende aspecten van het gebruik van het PTP-protocol moeten worden opgemerkt:

• Ethernet-switches moeten het PTP-profiel voor het elektriciteitsbedrijf ondersteunen en een onaanvaardbare prestatiefout kunnen signaleren. Niet alle transparante klokken met PTP-ondersteuning (en in het bijzonder die met ondersteuning voor het peer-to-peer-mechanisme voor het bepalen van kanaalvertragingen) kunnen een fout van minder dan 50 ns leveren. Ook zijn niet alle transparante klokken in staat om de resulterende fouten te evalueren.
• Er is een beperkt aantal RPA-apparaten op de markt die het PTP-profiel voor de elektriciteitssector ondersteunen, maar de situatie verbetert. Een aantal fabrikanten produceert sinds 2013 RPA-apparaten met PTP-ondersteuning, maar protocolondersteuning kan optioneel zijn en de behoefte eraan wordt bepaald bij de bestelling.
• Niet elke grandmaster- of slave-klok (inclusief converters naar andere tijdsynchronisatieprotocollen) is ontworpen voor gebruik in hoogspanningsonderstations, hoewel ze mogelijk het PTP-profiel van het hulpprogramma ondersteunen. De apparatuur moet worden getest op immuniteit voor elektromagnetische interferentie in overeenstemming met bepaalde gradaties van ernst.
• Tijdsynchronisatie is van groot belang voor de SMPR en de IEC 61850-9-2 procesbus. Het is belangrijk dat alleen speciaal opgeleid personeel de mogelijkheid heeft om de configuratie van PTP-compatibele apparaten te wijzigen (met behulp van speciale configurators, of met behulp van een webserver, of via het SNMP-protocol). Als PTP-apparaten configuratie op het voorpaneel toestaan, moet de toegang met een wachtwoord worden beperkt.
• Er zijn verschillende PTP-protocolprofielen, elk geoptimaliseerd voor specifieke toepassingen. Het PTP-profiel voor de elektriciteitsindustrie (Power Profile) voldoet het meest aan de eisen van automatiseringssystemen van energievoorzieningen, maar het standaardprofiel (Default Profile) kan ook worden gebruikt. Voldoende is echter niet gegarandeerd voor alle systemen. Andere specifieke profielen, zoals het telecommunicatieprofiel of het profiel voor audio-videotoepassingen (IEEE 802.1AS), zullen waarschijnlijk niet de vereiste prestaties leveren.

Voorbeelden van het gebruik van het PTP-protocol bij elektriciteitsvoorzieningen

In deze paragraaf worden twee voorbeelden besproken van het gebruik van het PTP-protocol binnen automatiseringssystemen van elektrische hoogspanningsstations. Het eerste voorbeeld beschrijft de toepassing van het PTP-protocol binnen het automatiseringssysteem van een nieuwbouw onderstation, het tweede - bij het upgraden van een bestaand onderstation. De voorbeelden gaan ook in op de structuur van het Ethernet-informatienetwerk. Aangenomen wordt dat de netwerkstructuur niet alleen de mogelijkheid biedt om het PTP-protocol te gebruiken, maar ook voldoet aan de eis om functies te behouden bij een enkele storing (apparatuur of communicatielijn).

Protocollaire toepassingPTP bij stroomvoorzieningen van nieuwbouw

Veel RPA-apparaten hebben een transiënte detectiefunctie in overeenstemming met IEEE C37.118.1 (of eerdere standaarden). De praktische implementatie van deze functionaliteit vereist de levering van tijdsynchronisatie van apparaten met een nauwkeurigheid van microseconden. Historisch gezien werd IRIG-B-tijdsynchronisatie gebruikt omdat het NTP-protocol niet voldeed aan de vereisten voor nauwkeurigheid. Tegenwoordig bieden een aantal fabrikanten PTP-compatibele oplossingen om aan nauwkeurigheidseisen te voldoen. Tegelijkertijd kan het NTP-protocol ook worden gebruikt om andere relaisbeveiligingsapparaten van de energievoorziening te synchroniseren die de functies uitvoeren van het registreren van noodgebeurtenissen.

In dit voorbeeld wordt uitgegaan van een middelgroot 330/132 kV-station om het gebruiksgemak van het PTP-protocol aan te tonen. Dit betreft de implementatie van de transient logging-functionaliteit, hoewel PTP ook kan worden gebruikt om interfaces met de procesbus binnen dezelfde faciliteit te synchroniseren. Het enkellijnige diagram van het object wordt getoond in Fig. negen.

Rijst. 9. Eenlijnsschema van het 330/132 kV-onderstation met anderhalf 330 kV-schakelbord en een enkelvoudig 132 kV-schakelrailsysteem.

Doorgaans accepteren elektriciteitsnetwerkbedrijven een van de volgende twee opties voor het plaatsen van apparatuur: relaisbeveiligingsapparaten bevinden zich in een enkele ruimte of in meerdere modulaire gebouwen (hoge prefabricage) die zich op de locatie bevinden. De gebruikte benadering bepaalt de topologie van het Ethernet Local Area Network en het vereiste betrouwbaarheidsniveau. In dit voorbeeld is de netwerktopologie ontwikkeld op basis van het feit dat de RPA-apparaten van 330 kV- en 132 kV-elementen in afzonderlijke gebouwen zijn geïnstalleerd. Voor de eenvoud, in afb. 10 toont slechts enkele van de apparaten. Er worden geen redundante verbindingen gebruikt en er wordt slechts één set beveiligingen weergegeven.

De apparaten uit de UR-serie van General Electric zijn geselecteerd voor gebruik op locatie en omvatten tijdelijke opname. Tegelijkertijd ondersteunen RPA-apparaten het PTP-protocol (in plaats van de meest gebruikte IRIG-B-interface). De faciliteit voorziet ook in het gebruik van een ABB condensatvan de REV615-serie, dat het PTP-protocol ondersteunt.

De belangrijkste bron van tijd is een grootmeesterhorloge dat is uitgerust met een satellietsignaalontvanger. Het wordt aanbevolen dat de Grand Master PTP ook de NTP-masterklok is, aangezien het NTP-protocol kan worden gebruikt door communicatiecontrollers, gateways, vermogensmeters en relaisbeveiligingsapparaten die een nauwkeurigheid van milliseconde tijdsynchronisatie vereisen.

Ethernet-switches worden gebruikt om PTP-berichten te verspreiden samen met ander verkeer zoals IEC 61850, DNP3, HTTP, SNMP, enz. De hoeveelheid PTP-verkeer is extreem klein, ongeveer 420 bytes/s, en heeft geen invloed op de werking van het netwerk. Rijst. 11 illustreert het PTP-verkeer dat wordt gegenereerd door een Tekron Grandmaster-horloge. De afbeelding laat zien dat de grootmeesterklok eenmaal per seconde berichten genereert zoals Sync (rood), Follow Up (magenta), Announce (blauw) en Peer Delay Request (groen), en ook reacties genereert zoals Peer Delay Response (geel) en Peer Delay Follow-up respons (bruin). De geïllustreerde tweetrapsbedrijfsmodus genereert het meeste verkeer - dit is het slechtste geval.

Rijst. 11. PTP-verkeer gegenereerd door tweetraps grootmeesterklok.

De root-switch bevindt zich in het midden van de Ethernet LAN-topologie van de energiecentrale. Op deze switch zijn de communicatieserver en het dispatcherwerkstation aangesloten. Het bovenstaande schema voorziet ook in het gebruik van twee andere schakelaars: één in de 330 kV OPU, de tweede in de 132 kV OPU. Deze oplossing maakt het mogelijk om de hoeveelheid kabel die nodig is om relaisbeveiligingsapparaten aan te sluiten, te verminderen. De commutators die in elk van de besturingseenheden zijn geïnstalleerd, bieden de mogelijkheid van informatie-uitwisseling tussen RPA-apparaten (bijvoorbeeld GOOSE-berichten met signalen om de CBF te starten, de AR te verbieden, enz.). Het gespecificeerde zorgt voor de bruikbaarheid van gedistribueerde functies in het geval van een storing in de communicatie met de centrale schakelaar.

Het aantal gebruikte schakelaars is te danken aan een balans tussen de volgende aspecten:

• Flexibiliteit: meer switches betekent meer poorten.
• Betrouwbaarheid: hoe meer schakelaars in het systeem, hoe groter de kans op uitval van een enkele schakelaar.
• Onderhoudsgemak: als de schakelaar uitvalt, over hoeveel elementen verliest u dan de controle?

Het gebruik van PTP sluit goed aan bij traditionele LAN-oplossingen voor elektriciteitsbedrijven. Het PTP-profiel voor de elektriciteitsindustrie (Power Profile) maakt werking mogelijk in de aanwezigheid van redundante communicatiekanalen bij gebruik van het redundantieprotocol van het RSTP-protocol, aangezien kanaalvertragingen worden geschat, ook op logisch geblokkeerde communicatielijnen. Bij het doorgeven van PTP-berichten langs alternatieve netwerkroutes, zal een aanpassingswaarde in Follow-up PTP-berichten de vertraging langs de nieuwe route bepalen.

Een van de beslissingen die moet worden genomen bij het ontwerpen van een tijdsynchronisatiesysteem, is of de schakelaars in transparante of grensklokmodus moeten werken. De eenvoudigste modus is transparante uren. Wanneer u deze modus gebruikt, is het veel eenvoudiger om problemen met het netwerk op te lossen bij het gebruik van verkeersanalyzers (bijvoorbeeld de Wireshark-toepassing). Het voordeel van het gebruik van grensklokken is dat ze de eigenlijke grootmeesterklok scheiden van de slaafklok. Dit wordt bereikt door de grensklok up-to-date te houden in plaats van eenvoudig timingberichten te schatten.

Laten we eens kijken naar het scenario van uitval van de communicatielijn tussen de root-switch en de switch die is geïnstalleerd in de 132 kV OPU, die fungeert als een transparante klok. In dit geval zal er een afwijking zijn van de aflezingen van elke slaafklok (RPA-apparaten) van de ware tijd en van elkaar vanwege het verschil in de kenmerken van de ingebouwde oscillatiegeneratoren. De snelheid waarmee de meetwaarden toenemen, is afhankelijk van verschillende factoren, waaronder de kwaliteit van de oscillator en temperatuurveranderingen. Als de communicatiestoring lange tijd aanhoudt, kan het verschil in de tijdmetingen van de RPA-apparaten van de elementen van het spanningsniveau van 132 kV aanzienlijk worden. Deze situatie is identiek aan de situatie wanneer de communicatielijn verbroken is, en zorgt voor synchronisatie via IRIG-B in de traditionele oplossing.

Als de schakelaar in de 132 kV OPU als grensklok fungeert, worden de slave-apparaten gesynchroniseerd met de grensklok. Bij normaal gebruik wordt de grensklok gesynchroniseerd met de grootmeesterklok. Als de verbinding met de grootmeesterklok wordt verbroken, blijven de RPA-apparaten gesynchroniseerd met de grensklok. De lokale tijd op de grensklok zal langzaam afwijken van de tijd van de grootmeesterklok - dit zal ook gebeuren met de slaafklok, in hetzelfde tempo. In dit geval worden alle RPA-apparaten met elkaar gesynchroniseerd. In deze situatie doet de kwaliteit van de interne klok in RPA-apparaten er niet toe.

Tijdsynchronisatiesysteem vervangen:IRIG– B AanPTP

Er kunnen situaties zijn waarin het nodig is om het bestaande tijdsynchronisatiesysteem te vervangen, bijvoorbeeld bij de introductie van complexen met nieuwe functionaliteit bij een energievoorziening. Het gegeven voorbeeld gaat uit van een uitbreidingsscenario van een onderstation waarbij er een vereiste is om een ​​afzonderlijk onderstation te bouwen. Op het bestaande onderstation wordt het Ethernet-netwerk gebruikt om gegevensuitwisseling tussen relaisbeveiligings- en automatiseringsapparaten te implementeren, en wordt het IRIG-B-protocol gebruikt om apparaten in de tijd te synchroniseren. Glasvezelcommunicatielijnen worden gebruikt als datatransmissiemedium voor zowel het Ethernet LAN als het tijdsynchronisatiesysteem, aangezien dit medium een ​​hoge ruisimmuniteit en galvanische isolatie biedt. Repeaters worden gebruikt om IRIG-B-signalen die via een optische communicatielijn worden verzonden om te zetten in IRIG-B elektrische signalen, die rechtstreeks naar de interfaces van RPA-apparaten worden geleid.

Rijst. 12 illustreert een eenlijnig diagram van het 330/132 kV-onderstation, de bestaande OPU-gebouwen en communicatieverbindingen tussen gebouwen vóór de uitbreiding.

Rijst. 12. Eenlijnsschema van het 330/132 kV-station met daarin het aantal OPU-gebouwen, onderlinge verbindingen en de opbouw van het tijdsynchronisatiesysteem.

Het elektriciteitsnetbedrijf implementeert een uitbreidingsproject voor 330 kV-schakelapparatuur met de installatie van nog een 330/132 kV-vermogenstransformator. Het is de bedoeling om nog een OPU-gebouw te bouwen, waar relaisbeveiligingsapparaten en andere apparatuur zullen worden geïnstalleerd. Hoewel het mogelijk is om het IRIG-B-signaal van de 132 kV OPA te geleiden, zal dit vanwege de lange communicatielijn gepaard gaan met extra tijdsynchronisatiefouten. Deze onderstationuitbreiding biedt een goede gelegenheid om ervaring op te doen met het PTP-protocol.

Tegelijkertijd is de hoeveelheid apparatuur die moet worden vervangen vrij klein. Als de masterklok die op de GPS is aangesloten het PTP-protocol niet ondersteunt, moet deze worden vervangen. In dit project werd gekozen voor Tekron-apparatuur - model TCG 01-G, dat zowel het PTP-protocol als het NTP-protocol ondersteunt. Als de root Ethernet-switch het Power Profile PTP-profiel niet ondersteunt, moet deze worden vervangen door een switch die deze ondersteuning implementeert (in dit project is een GE Multilink ML3000-switch vervangen). In dit geval moet de configuratie van de oude switch in termen van VLAN's, multicast-filtering, poortconfiguratie en SNMP-protocol worden gedocumenteerd om ze op de nieuwe switch te repliceren.

In de laatste fase is het de bedoeling om in het kader van de nieuwe ODA een converter te gebruiken van het PTP-protocolformaat naar het IRIG-B-formaat. De gespecificeerde converter biedt de mogelijkheid om RPA-apparaten met een IRIG-B-interface aan te sluiten. Alle Ethernet-switches die in de nieuwe STC worden geïnstalleerd, moeten de transparante rol of de grensklokrol ondersteunen, volgens het PTP-profiel van het hulpprogramma. Rijst. 13 illustreert de lay-out van het onderstation na uitbreiding. Bij het uitbreiden van het object is het ook de moeite waard om na te gaan of de te installeren RPA-apparaten het PTP-protocol kunnen ondersteunen. Zo ja, dan kan dit de noodzaak van converters wegnemen en extra ervaring opdoen met het PTP-protocol in eindapparaten.

Rijst. 13. Schema onderstation na uitbreiding (plaatsing extra vermogenstransformator, uitbreiding 330 kV-schakelbord en bouw nieuwe meldkamer).

In de voorgestelde architectuur voor het bouwen van een tijdsynchronisatiesysteem is het niet vereist om de voortplantingstijd van synchronisatiesignalen te compenseren voor apparaten die zich in het nieuwe besturingssysteem bevinden, aangezien dit wordt geleverd door een peer-to-peer-mechanisme voor het bepalen van de tijdvertragingen van het PTP-profiel voor de elektriciteitssector (Power Profile). Dit vereenvoudigt de taak van het opzetten van SMPR en andere systemen die microseconde nauwkeurigheid van tijdsynchronisatie vereisen.

Wat het ontwerp van de kast betreft, kan er slechts één wijziging plaatsvinden, in verband met de noodzaak om PTP-converters te installeren (één voor elke kast), met als doel de noodzaak te elimineren om speciale communicatielijnen aan te leggen voor het verzenden van IRIG-B-signalen. Nu al stappen veel elektriciteitsnetwerkbedrijven af ​​van het gebruik van koperen kabelverbindingen tussen RPA-kasten, waarbij kastapparaten worden gecombineerd tot één enkel Ethernet-netwerk. In een dergelijke situatie kan een ander voordeel van deze aanpak worden gebruikt: het gebruik van het PTP-protocol, waarvan de berichten via hetzelfde Ethernet-netwerk worden verzonden als de signalen van de relaisbeveiligingsapparaten.

Rijst. 14 illustreert een conventioneel tijdsynchronisatiesysteem dat gebruik maakt van IRIG-B (gesimuleerd/ongemoduleerd signaal). Alle RPA-apparaten zijn aangesloten op het APCS-systeem via Ethernet-interfaces, maar bij oudere stroomvoorzieningen kunnen apparaten ook worden aangesloten via de RS-485-interface (met DNP3- of IEC 60870-5-101-protocollen).

Rijst. 14. Traditioneel tijdsynchronisatiesysteem en communicatieverbindingen tussen apparaten.

Bij gebruik van het PTP-protocol is het raadzaam om de communicatie tussen kasten te organiseren via glasvezelcommunicatielijnen. Een PTP-slaveklok, zoals een PTP-converter, wordt gebruikt om te converteren naar een van de standa(IRIG-B in het voorbeeld). Vorming van IRIG-B-signalen door deze converters in elke afzonderlijke kast maakt het mogelijk om een ​​ander tijdformaat en verschillende tijdzones te hebben in vergelijking met het gebruik van een enkele tijdserver die gegevens uitzendt in het IRIG-B-protocolformaat. Rijst. 15 illustreert een voorbeeld van hoe het PTP-protocol kan worden gebruikt voor tijdsynchronisatie van bestaande RPA-apparaten met behulp van een omzetter van het PTP-formaat naar het formaat van een van de standaardprotocollen en gelijktijdige tijdsynchronisatie van moderne PTP-compatibele RPA-apparaten.

Het gebruik van het PTP-protocol bij het uitbreiden en upgraden van bestaande energievoorzieningen biedt elektriciteitsnetwerkbedrijven en integratoren de mogelijkheid om ervaring op te doen met het gebruik van het PTP-protocol. In de toekomst kan ook ervaring worden opgedaan met het gebruik van relaisbeveiliging en automatiseringsapparaten met native ondersteuning voor het PTP-protocol.

Als het elektriciteitsnetbedrijf alleen overgaat op de implementatie van communicatie via het lokale Ethernet-netwerk tussen relaisbeveiliging en automatiseringsapparaten, moet u letten op de mogelijkheid om het PTP-protocol te ondersteunen door de gebruikte schakelaars. U moet ervoor zorgen dat de switches het protocol op hardwareniveau ondersteunen - ondersteuning voor individuele PTP-profielen kan in een later stadium worden geïmplementeerd door de onderliggende software van de Ethernet-switches te wijzigen.

Het bouwen van redundante netwerken met behulp van het PTP-protocol

Hierboven zijn de aspecten van het gebruik van PTP in het kader van een nieuwe elektriciteitsvoorziening behandeld. In dit gedeelte worden de basisprincipes besproken van het gebruik van het PTP-protocol in redundante Ethernet-netwerken. Hier zijn de fundamentele principes die moeten worden opgemerkt:

• Het uitvallen van een netwerkapparaat of communicatielijn mag niet leiden tot het uitvallen van de beveiligings- en besturingsfunctie van meer dan één schakelinstallatieverbinding.
• Er worden primaire en back-up RPA-kits gebruikt, die vaak worden aangeduid als primaire bescherming #1/primaire bescherming #2, A/B- of X/Y-kits.
• De besturingsacties op de schakelapparatuur worden rechtstreeks vanuit de RPA-apparaten gevormd, waarbij de controllers/besturingsapparaten worden omzeild.

U kunt op een van de volgende manieren redundantie voorzien, die elk hun eigen voor- en nadelen hebben:

• Rapid Spanning Tree Protocol (RSTP), waarmee ringnetwerken kunnen worden gemaakt. Dit protocol wordt ondersteund door veel, zo niet alle, Ethernet-switches. De tijd die nodig is om de communicatie tussen apparaten te herstellen is niet constant en hangt af van een aantal factoren.
• Parallel Redundantie Protocol (PRP). Bij gebruik van dit protocol is de continuïteit van de informatie-uitwisseling gewaarborgd in het geval van een storing van een aparte communicatielijn of een aparte schakelaar. Vereist speciale ondersteuning voor dit protocol of het gebruik van redundante apparaten, evenals duplicatie van de Ethernet-netwerkinfrastructuur.
• Zeer betrouwbaar naadloos redundantieprotocol (HSR). De continuïteit van de informatie-uitwisseling is gewaarborgd in het geval van een storing van een afzonderlijke communicatielijn of een afzonderlijke schakelaar. Het vereist geen extra schakelaars. De reikwijdte van het protocol is beperkt tot Ethernet-ringtopologieën en speciale ondersteuning voor het protocol door aangesloten apparaten (bijvoorbeeld PTP-klokken of relaisbeveiligingsapparaten) of hun verbinding wordt uitgevoerd via speciale redundantieapparaten.

Het voorbeeld in dit gedeelte is gebaseerd op het gebruik van het PRP-protocol en elimineert de noodzaak van een afzonderlijke schakelaar per vak of anderhalve schakelkastdiameter, die vaak worden gebruikt om bescherming en besturingscapaciteit te behouden na een enkele storing in de communicatie apparatuur. In sommige scenario's kan het gebruik van het PRP-protocol het aantal gebruikte Ethernet-switches verminderen in vergelijking met het gebruik van het RSTP-protocol.

Bescherming X (of hoofdbescherming nr. 1) wordt geïmplementeerd met behulp van General Electric UR-serie RPA-apparaten, aangezien dit apparaat de PTP- en PRP-protocollen ondersteunt. Protection X biedt controle- en transiënte opnamefuncties naast de relaisbeveiligingsfuncties. Beveiliging Y (of hoofdbeveiliging nr. 2) wordt geïmplementeerd met behulp van relaisbeveiligingsapparaten van andere fabrikanten die het PTP- of NTP-protocol voor tijdsynchronisatie ondersteunen.

Rijst. 16 illustreert de topologie van een Ethernet-netwerk. Er worden twee lokale netwerken geïmplementeerd, aangeduid als A en B, die beide tegelijkertijd actief zijn. Het RSTP-protocol werkt zo dat het redundante links blokkeert, die in de figuur met stippellijnen zijn weergegeven. Dit is met name de verbinding tussen Root Switch #2 en Switch Y. Sommige mediaservers werken in een modus waarin hun tweede Ethernet-poort is uitgeschakeld totdat de primaire link uitvalt. De verbindingsgegevens worden ook weergegeven in stippellijnen.

Rijst. 16. Lokaal Ethernet-netwerk geïmplementeerd met behulp van het PRP-protocol.

Naar verwachting zullen in de nabije toekomst ICS-communicatieservers met native PRP-ondersteuning beschikbaar komen, waardoor twee communicatielijnen tegelijk actief kunnen blijven. Schakelaar Y kan de functionaliteit bieden van een redundant apparaat voor relaisbeveiligingsapparaten Y, waardoor de verwerking van dubbele berichten wordt gegarandeerd.

Ethernet-switches zijn nu verkrijgbaar met een groot aantal poorten, waardoor er geen schakelaars meer in elke kast nodig zijn om RPA-apparaten aan te sluiten. In kleine onderstations is het gebruik van X1-, X2- en Y-schakelaars om RPA-apparaten aan te sluiten mogelijk niet nodig en omgekeerd kan het in hoogspanningsonderstations aangewezen zijn om X1-, X2- en Y-schakelaars voor elk spanningsniveau te gebruiken. Ongeacht de topologie van het Ethernet-netwerk, zorgt het gebruik van een Ethernet-switch met ondersteuning voor de rol van een transparante of grensklok ervoor dat clients overal in het netwerk verbinding kunnen maken.

bevindingen

Het gebruik van tijdsynchronisatieprotocollen die via een Ethernet-netwerk werken, verlaagt de kosten van systeemontwerp, implementatie en onderhoud. Het PTP-protocol, namelijk het profiel van dit protocol voor de elektriciteitsindustrie (Power Profile), lost een aantal problemen op die verband houden met tijdsynchronisatiesystemen voormen, en het gebruik ervan past optimaal in de ideologie van het uitwisselen van gebouwgegevens tussen secundaire apparaten van een energievoorziening via een Ethernet-netwerk.

Bibliografie

1. DME Ingram, P. Schaub, DA Campbell & RR Taylor, "Evaluatie van nauwkeurige tijdsynchronisatiemethoden voor onderstationtoepassingen", 2012 International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication (ISPCS 2012), San Francisco, VS, 23-28 september 2012. Beschikbaar via http://eprints.qut.edu.au/53218/ .
2. DME Ingram, P. Schaub, DA Campbell & RR Taylor, "Kwantitatieve beoordeling van fouttolerante precisietiming voor elektriciteitsonderstations", IEEE-transacties op instrumentatie en meting, oktober 2013. Volume 62, nummer 10, pp 2694-2703. Beschikbaar van

Waarom heb je precieze tijd nodig?

En wie heeft deze exacte tijd eigenlijk nodig? Natuurlijk hebben wij, gebruikers, het nodig zodat we minder te laat zijn. Stel je een moderne luchthaven voor waar honderden piloten en verkeersleiders een foutloze klok moeten gebruiken om het draaiende te houden. Magazijnregistratiesystemen, ziekenhuizen, treinkaartjes en vele andere instellingen vereisen dat de tijd in alle objecten van het systeem min of meer hetzelfde is. Vooral computers. Ze voeren veel services en programma's uit, voor de normale werking waarvan de exacte tijd nodig is, en in de regel nauwkeuriger dan wat we gewoonlijk nodig hebben, mensen. Systeemservices, beveiligingscomponenten en eenvoudige applicatieprogramma's kunnen erg cruciaal zijn voor de nauwkeurigheid van de klok. Het meest opvallende voorbeeld van dergelijke services is het Kerberos-authenticatieprotocol. Om het te laten werken, is het dus noodzakelijk dat op computers die via dit protocol worden benaderd, de systeemtijd niet meer dan 5 minuten verschilt. Bovendien vergemakkelijkt de exacte tijd op alle computers de analyse van beveiligingslogboeken aanzienlijk bij het onderzoeken van incidenten op een lokaal netwerk.

NTP-protocol

NTP (Network Time Protocol) is een protocol dat is ontworpen om de tijd op een netwerk te synchroniseren. Het is een reeks vrij complexe algoritmen die zijn ontworpen om een ​​hoge nauwkeurigheid (tot enkele microseconden) en fouttolerantie van het tijdsynchronisatiesysteem te bieden. Het protocol gaat dus uit van gelijktijdige synchronisatie met meerdere servers.

Er zijn verschillende versies van dit protocol met enkele verschillen. De derde versie van dit protocol werd in 1992 gestandaardiseerd als RFC 1305. De vierde (momenteel laatste) versie brengt enkele verbeteringen (automatische configuratie en authenticatie, verbeterde synchronisatie-algoritmen) ten opzichte van de derde, maar is nog niet gestandaardiseerd in RFC.

Daarnaast is er naast het NTP-protocol het SNTP-protocol (Simple Network Time Protocol). Op pakketniveau zijn deze twee protocollen volledig compatibel. Het belangrijkste verschil tussen de twee is dat SNTP niet beschikt over de complexe filter- en meerstapsfoutcorrectiesystemen die in NTP voorkomen. SNTP is dus een vereenvoudigde en gemakkelijker te implementeren versie van NTP. Het is bedoeld voor gebruik op netwerken waar zeer hoge tijdsnauwkeurigheid niet vereist is, en in de Microsoft-implementatie is het binnen 20 seconden nauwkeurig binnen een onderneming en niet meer dan 2 seconden binnen een enkele locatie. Het SNTP-protocol is gestandaardiseerd als RFC 1769 (versie 3) en RFC 2030 (versie 4).

Het NTP-synchronisatiemodel gaat uit van een hiërarchische structuur. Op het eerste niveau van de hiërarchie bevinden zich de zogenaamde "primaire" tijdservers (eerste laag). Ze bevinden zich op verschillende plaatsen in de wereld en hebben de meest nauwkeurige tijd. Er zijn relatief weinig van dergelijke servers, omdat de exacte tijd erop wordt bijgehouden met behulp van dure gespecialiseerde apparatuur (radiokanaal, satellietkanaal). Servers van het tweede niveau (tweede stratum) worden gesynchroniseerd met servers van het eerste niveau met behulp van het NTP-protocol. Er zijn er al veel meer, maar ze zijn al enigszins niet synchroon (van 1 tot 20 milliseconden) ten opzichte van de "primaire" servers. Vervolgens kunnen servers van het derde, vierde en volgende niveau zijn:

Met de overgang naar elk niveau neemt de fout ten opzichte van de primaire server iets toe, maar het totale aantal servers neemt toe en bijgevolg neemt hun belasting af. Daarom wordt, als externe synchronisatiebron, aanbevolen om in plaats van primaire servers te gebruiken die de meest nauwkeurige tijd hebben, secundaire servers te gebruiken als minder belaste servers.

Windows 2000/XP/2003 gebruikt het SNTP-protocol om de tijd te synchroniseren. Dit protocol wordt ondersteund door de Windows Time-systeemservice die deel uitmaakt van het besturingssysteem MS Windows 2000/XP/2003. Een onderscheidend kenmerk van deze implementatie is dat de Windows Time-service domeinauthenticatie ondersteunt bij toegang tot de referentietijdserver, wat belangrijk is vanuit beveiligingsoogpunt.

Er zijn verschillende opties voor het uitvoeren van de SNTP-service die bij Windows wordt geleverd:

• Hiërarchisch (NT5DS). Wordt standaard gebruikt voor alle computers die lid zijn van een domein. Tijdsynchronisatie op werkstations en domeinservers wordt hiërarchisch uitgevoerd. Werkstations en lidservers worden dus gesynchroniseerd met de domeincontroller die de aanmelding heeft geverifieerd, terwijl domeincontrollers synchroniseren met de PDC-emulator-operationmaster, die op zijn beurt synchroniseert met de domeincontroller op een hoger niveau in de hiërarchie. Opgemerkt moet worden dat deze synchronisatievolgorde "standaard" wordt gebruikt en handmatig of met behulp van groepsbeleid kan worden overschreven. Hoe u dit doet, wordt hieronder besproken.
• Forceer synchronisatie met de geselecteerde NTP-server (NTP). In dit geval wordt de referentietijdbron voor de Windows Time-service handmatig of via groepsbeleid ingesteld.
• Schakel synchronisatie uit (NoSync). Deze modus is vereist voor een gemengd tijdregistratieschema dat een product van derden gebruikt om te synchroniseren met een externe bron en Windows Time gebruikt om de tijd binnen een domein bij te houden.

Dus in het geval van een werkgroep zal de tijdsynchronisatie nog steeds handmatig moeten worden geconfigureerd. Een van de computers kan bijvoorbeeld worden geconfigureerd om te synchroniseren met een externe server met behulp van het SNTP-protocol, en de rest kan worden geconfigureerd om daarmee te synchroniseren. De stappen die hiervoor nodig zijn, worden hieronder beschreven.

Voor een domein wordt aanbevolen om hiërarchische SNTP-synchronisatie te gebruiken. In de meeste gevallen biedt het acceptabele systeemtijdnauwkeurigheid binnen het domeinforest. Bovendien zorgt het automatisch voor de beveiliging van het bijwerken van de tijd door Active Directory-authenticatie te ondersteunen. Om de "juiste" tijd in het domein te behouden, moet u de domeincontroller op het hoogste niveau die eigenaar is van de rol "PDC-emulator" synchroniseren met een externe NTP-server. In ons voorbeeld is deze server een Linux-machine waarop de ntpd-daemon draait.

SNTP instellen op Windows

Er worden twee hulpprogramma's gebruikt om de Windows Time-service te configureren:

• netto tijd
• W32tm

Nettotijd wordt voornamelijk gebruikt om de tijdservice te configureren, terwijl w32tm wordt gebruikt om de werking te bewaken en te diagnosticeren. In Windows XP/2003 heeft het hulpprogramma w32tm echter aanzienlijke wijzigingen ondergaan en kan het worden gebruikt om de tijdservice te configureren. De NTP-setup wordt verder uitgevoerd op het voorbeeld van Windows XP/2003.

Dus om de synchronisatiebron "handmatig" te specificeren met behulp van netto tijd, volstaat het om op de opdrachtregel te schrijven:

et time /setsntp:list_of_time_servers_separated by_space

Om informatie te krijgen over de huidige tijdserver:

nettime /querysntp

U kunt de tijd op de domeincontroller als volgt achterhalen:

net tijd /domein:domeinnaam

En synchroniseer de tijd met de domeincontroller als volgt:

Netto tijd /domein:domeinnaam /set

Het w32tm-systeemhulpprogramma kan hetzelfde en zelfs meer:

• w32tm /resync - Met deze opdracht kunt u een lokale of externe computer dwingen zijn systeemklok te synchroniseren met de tijdserver die hij gebruikt.
• w32tm /config - Deze opdracht wordt gebruikt om de Windows Time-service te configureren. Met zijn hulp kunt u de lijst met gebruikte tijdservers en het type synchronisatie specificeren (hiërarchisch of door de server geselecteerd).

Om bijvoorbeeld de standaardwaarden te overschrijven en tijdsynchronisatie met een externe bron in te stellen, kunt u de opdracht gebruiken:

w32tm /config /syncfromflags:manual /manualpeerlist:PeerList

En om ervoor te zorgen dat Windows Time de nieuwe instellingen toepast, kunt u in plaats van de service opnieuw te starten de volgende opdracht gebruiken:

w32tm /config /update

Daarnaast biedt w32tm de volgende opties met betrekking tot tijdbewaking op computers:

• w32tm /monitor - met deze optie kunt u zien hoeveel de systeemtijd van deze computer verschilt van de tijd op de domeincontroller of andere computers.
• w32tm /stripchart - toont grafisch het tijdsverschil tussen de huidige en externe computer.
• w32tm /register - Registreert de Windows Time-service als een service op deze computer. Deze optie kan handig zijn op computers die geen lid zijn van een domein, omdat de tijdservice daar standaard wordt gestopt.

Meer gedetailleerde informatie over de parameters van de hulpprogramma's net time en w32tm kan worden verkregen met behulp van de /? of door het juiste gedeelte van het helpsysteem "Help and Support Center" MS Windows XP/2003 te openen.

Het is niet moeilijk te raden dat de Windows Time-service-instellingen zijn opgeslagen in het Windows-register onder HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\.

De sectiehoofdmap definieert de werkingsparameters van de service zelf, de subsleutel Config bevat instellingen die verband houden met de werking van het SNTP-protocol zelf, de synchronisatiemodus wordt bepaald in de subsleutel Parameters. De SNTP-client- en serverinstellingen bevinden zich respectievelijk in de subsleutels TimeProviders\NtpClient en TimeProviders\NtpServer. Overweeg de belangrijkste waarden die de NTP-client- en serverinstellingen bepalen:

• Type - bepaalt de werkingsmodus van de NTP-client (NTDS5 - hiërarchisch, NTP - "handmatig", NoSync - niet synchroniseren, AllSync - alle soorten synchronisatie zijn beschikbaar);
• Ingeschakeld - bepaalt of de gegeven component (client of server) is ingeschakeld;
• CrossSiteSyncFlags - bepaalt of tijd kan worden gesynchroniseerd met een bron buiten het domein als hiërarchische synchronisatie wordt gebruikt (0 - niet mogelijk, 1 - alleen met de PDC-emulator, 2 - met alle);
• EventLogFlags - bepaalt of berichten van Windows Time worden gelogd of niet (een erg handige functie bij het debuggen).

Een andere optie voor het configureren van de Windows Time-service is het gebruik van Groepsbeleid. De instellingen worden gedefinieerd in de GPO op het volgende adres: "Computerconfiguratie -> Beheersjablonen -> Systeem -> Windows Time Service".

Als u Windows 2000 Server hebt geïnstalleerd en u hebt een dergelijke instelling niet gevonden, wanhoop dan niet, u hoeft alleen de beheersjablonen bij te werken. Kopieer hiervoor alle .adm-bestanden uit de system32\GroupPolicy\Adm-systeemmap van een computer waarop Windows XP is geïnstalleerd naar een server die een domeincontroller is. Klik vervolgens bij het definiëren van het GPO met de rechtermuisknop op "Administratieve sjablonen" en selecteer "Sjablonen toevoegen/verwijderen...". Verwijder de daar vermelde sjablonen en voeg de gekopieerde sjablonen toe. Nadat u op de knop OK hebt geklikt, worden de sjablonen bijgewerkt en kunt u de tijdservice configureren met behulp van groepsbeleid:

Het is gemakkelijk te zien dat hier voornamelijk al die instellingen worden vermeld die in het register kunnen worden gewijzigd. Dit is niet verrassend, want zo werken de meeste groepspolissen.

Windows XP introduceerde een andere manier om een ​​tijdserver in te stellen, wat erg handig kan zijn voor het instellen van synchronisatie op een thuiscomputer of een computer die deel uitmaakt van een werkgroep:

NTP-server onder Linux - externe synchronisatie voor Windows-domein

Zoals hierboven vermeld, is het NTP-protocol beter bestand tegen fouten, dus het is beter om een ​​NTP-server te gebruiken als referentietijdbron voor externe synchronisatie. Bovendien heeft de domeincontroller op het hoogste niveau niet altijd toegang tot internet op UDP-poort 123, die wordt gebruikt voor NTP. De toegang kan om veiligheidsredenen worden geweigerd, wat gebruikelijk is in grote organisaties. Om dit probleem op te lossen, kunt u in dergelijke gevallen uw eigen tijdserver in de DMZ installeren, geconfigureerd om te synchroniseren met een externe bron, en deze gebruiken als referentietijdbron voor synchronisatie van de domeincontroller op het hoogste niveau. Elke, niet noodzakelijkerwijs moderne machine met een *nix-achtig besturingssysteem, bijvoorbeeld Linux, geïnstalleerd in een minimale configuratie, zonder een X-server en andere potentieel kwetsbare dingen, is best geschikt als zo'n computer.

Er zijn veel programma's voor tijdsynchronisatie voor Linux OS. De bekendste zijn Xntpd (NTP versie 3), ntpd (NTP versie 4), Crony en ClockSpeed. In ons voorbeeld gebruiken we de ntpd ntp-server die wordt meegeleverd met Redhat 9, geleverd in het ntp-4.1.2-0.rc1.2.i386.rpm-pakket.

Het pakket bevat verschillende programma's die zijn ontworpen om met NTP te werken.

Dit zijn de belangrijkste:

• Ntpd is een ntp-daemon die de juiste tijd op de achtergrond bijhoudt;
• Ntpq is een hulpprogramma dat is ontworpen om NTP-servers te pollen die het standaard pollingprotocol NTP mode 6 ondersteunen.Het kan worden gebruikt om de huidige status van de server te achterhalen en te wijzigen, als de instellingen dit toestaan;
• Ntptdc - een hulpprogramma waarmee u de ntpd-daemon kunt peilen en statistieken kunt opvragen over de werking ervan;
• Ntpdate is een programma voor het instellen van de huidige systeemtijd met behulp van het NTP-protocol.

Een standaardfunctie van het NTP-protocol is de mogelijkheid om authenticatie uit te voeren. In dit geval kunnen zowel symmetrische algoritmen (DES), die verschenen in de tweede versie van het protocol, als asymmetrische algoritmen met een openbare sleutel, die een innovatie zijn van de vierde versie, worden gebruikt.

In het geval van het gebruik van een symmetrisch authenticatieschema, kiezen de client en de server een willekeurige identifier en een van de 65534 sleutels die door de standaard zijn gedefinieerd. Bij het gebruik van asymmetrische algoritmen wordt het zogenaamde Autokey-schema gebruikt, een onderscheidend kenmerk hiervan is de afwezigheid van de noodzaak om de openbare sleutels van de servers vooraf te distribueren.

Er zijn ntp-genkeys, ntpq en ntpdc hulpprogramma's om authenticatie in ntpd in te stellen.

Alle NTP-tijdwaarnemingsfunctionaliteit is geïmplementeerd in de ntpd-daemon. De configuratie gebeurt op de gebruikelijke manier voor UNIX - door het configuratiebestand ntp.conf te bewerken, dat zich in de map /etc bevindt.

Stel de volgende opties in voor de NTP-server.

Eerst specificeren we de servers waarmee tijdsynchronisatie zal worden uitgevoerd:

server ntp.nasa.gov # Een stratum 1-server op nasa.org
server ntp1.demos.net # Een stratum 2 server op demo's.net

beperk ntp.research.gov masker 255.255.255.255 nomodify notrap noquery

Hier wordt het masker 255.255.255.255 gebruikt om de toegang tot onze server vanaf de ntp.nasa.gov-server te beperken. Laten we nu een lijst met hosts op ons lokale netwerk definiëren die we toegang willen geven tot onze NTP-server om de tijd te krijgen:

beperken 192.168.1.0 maskeren 255.255.255.0 niet vertrouwen nomodificeren niet trap

We hebben ook de Linux-machine nodig om volledige toegang te hebben tot de serverbronnen:

beperken 127.0.0.1

En nu het allerbelangrijkste: we moeten ervoor zorgen dat het standaardverbod, dat een hogere prioriteit heeft, wordt becommentarieerd:

#restrict standaard negeren

Na het opslaan van het bestand ntp.conf kan de configuratie als voltooid worden beschouwd, maar het kan gebeuren dat na het starten van de daemon de tijd nog steeds niet gesynchroniseerd is. Feit is dat het NTP-protocol oorspronkelijk is ontwikkeld als protocol voor het bijhouden van tijd, en niet voor het instellen ervan. Als het verschil tussen de klokaflezingen groot genoeg is (meer dan een paar minuten), wordt er dus geen synchronisatie uitgevoerd. In dit geval is het zinvol om de tijd in eerste instantie handmatig in te stellen met de opdracht ntpdate (u kunt ook de opdracht ntpdate toevoegen aan de opstartscripts van de machine):

# ntpdate klok.vsu.ru
17 februari 23:44:54 ntpdate: stap tijd server 198.123.30.132 offset 25.307598 sec

17 februari 23:45:05 ntpdate: tijdserver aanpassen 198.123.30.132 offset 0.002181 sec
# ntpdate klok.vsu.ru

De ntp-daemon wordt gestart via initialisatiescripts. Als het programma is geïnstalleerd vanuit een rpm-pakket, zijn waarschijnlijk alle problemen met betrekking tot de automatische lancering al opgelost. Om dit te verifiëren, kunt u de opdracht gebruiken:

# chkconfig -lijst ntpd
ntpd 0:aan 1:uit 2:uit 3:aan 4:uit 5:aan 6:uit

Als u deze regel niet ziet, betekent dit dat ntpd niet is geconfigureerd om automatisch te starten. Typ het volgende om dit op te lossen:

# chkconfig --level 035 ntpd aan

Voor het beheer van NTP (start, start, restart, status) wordt een standaard initialisatiescript gebruikt:

# /etc/init.d/ntpd start

Om te bekijken, kunt u de volgende opdracht gebruiken:

#ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*vink.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
+tijdwaarnemer.isi. .GPS. 1 en 13 64 377 245,30 3,454 15,08
+nieuws-nul.demo's ntp0.usno.navy. 2 u 16 64 377 37,51 -3,239 11,14
LOKAAL(0) LOKAAL(0) 10 l - 64 377 0,00 0,000 10,01

NTP-server/client-bedrijfsmodi

Client server

Deze modus wordt verreweg het meest gebruikt op internet. Het werkschema is klassiek. De client stuurt een verzoek, waarop de server enige tijd een antwoord stuurt. De client wordt geconfigureerd met behulp van de serverrichtlijn in het configuratiebestand, dat de DNS-naam van de tijdserver specificeert.

Symmetrische actieve/passieve modus

Deze modus wordt gebruikt als tijdsynchronisatie wordt uitgevoerd tussen een groot aantal peermachines. Naast het feit dat elke machine synchroniseert met een externe bron, synchroniseert het ook met zijn collega's en fungeert het als client en tijdserver voor hen. Daarom, zelfs als de machine de externe bron "verliest", kan hij nog steeds de exacte tijd van zijn buren krijgen. Buren kunnen op twee manieren werken: actief en passief. Wanneer de machine in de actieve modus werkt, draagt ​​de machine zelf zijn tijd over aan alle naburige machines die worden vermeld in de peers-sectie van het ntp.conf-configuratiebestand. Als er in deze sectie geen buren worden gespecificeerd, wordt de machine geacht in passieve modus te staan. Verificatie moet worden gebruikt om te voorkomen dat een aanvaller andere machines compromittert door zich voor te doen als een actieve bron.

Uitzendmodus

Deze modus wordt aanbevolen wanneer een klein aantal servers een groot aantal clients bedient. In deze modus zendt de server periodiek pakketten uit met behulp van het uitzendadres van het subnet. Een client die is geconfigureerd om op deze manier te synchroniseren, ontvangt het broadcastpakket van de server en synchroniseert met de server. Een kenmerk van deze modus is dat de tijd wordt afgeleverd binnen hetzelfde subnet (beperking van broadcast-pakketten). Bovendien moet authenticatie worden gebruikt om te beschermen tegen indringers.

Multicast-modus

Deze modus lijkt in veel opzichten op uitzenden. Het verschil ligt in het feit dat multicast-adressen van klasse D-netwerken van de IP-adresruimte worden gebruikt om pakketten af ​​te leveren. Clients en servers krijgen het adres van de multicast-groep die ze gebruiken voor tijdsynchronisatie. Dit maakt het mogelijk om groepen machines die zich op verschillende subnetten bevinden te synchroniseren, op voorwaarde dat de routers die ze verbinden het IGMP-protocol ondersteunen en zijn geconfigureerd om multicast-verkeer te verzenden.

Manycast-modus

Deze modus is nieuw in de vierde versie van het NTP-protocol. Het houdt in dat de client zoekt naar manycast-servers onder zijn netwerkburen, tijdmonsters ontvangt van elk van hen (met behulp van cryptografie) en op basis van deze gegevens de drie "beste" manycast-servers selecteert waarmee de client zal synchroniseren. Als een van de servers uitvalt, werkt de client automatisch zijn lijst bij.

Om tijdmonsters te verzenden, gebruiken clients en servers die in manycast-modus werken adressen van multicast-groepen (klasse D-netwerken). Clients en servers die hetzelfde adres gebruiken, vormen dezelfde associatie. Het aantal associaties wordt bepaald door het aantal gebruikte multicast-adressen.

FAQ

Waarom wordt de tijd niet gesynchroniseerd na het commando net time /setsntp:server?

Zorg ervoor dat de w32time-service is ingesteld op Startup Type Automatic.
Zorg ervoor dat de UDP-poort 123 van de NTP-server die u gebruikt, beschikbaar is.
Zorg ervoor dat de tijd tussen de client en de server niet te veel verschilt.

Kan een SNTP-client synchroniseren met een NTP-server?

Ja, dat kan, want SNTP is een subset van NTP en is er volledig compatibel mee.

Kan ik een NTP-server van derden gebruiken op Windows 2000/XP/2003?

Ja, u kunt elke server gebruiken, betaald of gratis. U moet eerst de juiste componenten (client of server) van de Windows Time-service uitschakelen.

Waarom werkt de NTP-client niet op een computer waarop MS SQL Server is geïnstalleerd?

Hoogstwaarschijnlijk is het probleem dat SQL Server op de een of andere manier UDP-poort 123 bezet. Als oplossing kunnen we voorstellen om een ​​NTP-client naar MS SQL Server te draaien.

De ntpd-daemon draait 10-20 minuten na het opstarten, waarna hij stopt. Wat zou het probleem kunnen zijn?

Zorg ervoor dat de client- en servertijden niet te veel verschillen (niet meer dan 5 minuten). Forceer anders een synchronisatie met ntpdate.

Is het mogelijk om de tijd te synchroniseren in OS Windows NT4, 95, 98, Me?

U kunt met behulp van programma's van derden, bijvoorbeeld NetTime, Automacahron, World Time5, ntpd Windows NT-poort.

Bij het inloggen op een Windows-domein verschijnt de melding dat de tijd tussen de domeincontroller en het werkstation te veel afwijkt, ook al is de synchronisatie gefinetuned.

Hoogstwaarschijnlijk is het probleem dat de tijd erg verkeerd is gegaan (CMOS-reset, hacker-sabotage) en de service niet kan worden geverifieerd met behulp van het Kerberos-protocol. Om dit probleem op te lossen, moet u de tijd handmatig aanpassen of dit type authenticatie niet gebruiken bij het bijwerken van de tijd.

Er zijn veel artikelen geschreven over het bekende Network Time Protocol (NTP), sommige vermelden het Precision Time Protocol, dat zogenaamd een nauwkeurigheid van nanoseconde tijdsynchronisatie mogelijk maakt (bijvoorbeeld en). Laten we eens kijken wat dit protocol is en hoe een dergelijke nauwkeurigheid wordt bereikt. En laten we ook eens kijken naar de resultaten van mijn werk met dit protocol.

Invoering

Het "Precise Time Protocol" wordt beschreven door de IEEE 1588-standaard. Er zijn 2 versies van de standaard. De eerste versie werd uitgebracht in 2002, daarna werd de standaard herzien in 2008 en was het PTPv2-protocol geboren. Achterwaartse compatibiliteit is niet bewaard gebleven.
Ik werk met de tweede versie van het protocol, het heeft veel verbeteringen ten opzichte van de eerste (nauwkeurigheid, stabiliteit, zoals de wiki ons vertelt). Ik zal geen vergelijkingen maken met NTP, de loutere vermelding van synchronisatienauwkeurigheid, en de nauwkeurigheid van PTP bereikt echt tientallen nanoseconden met "ijzeren" ondersteuning, spreekt van een voordeel ten opzichte van NTP.
"Iron"-protocolondersteuning in verschillende apparaten kan op verschillende manieren worden geïmplementeerd. In feite is het minimum dat nodig is voor de implementatie van PTP de mogelijkheid van het stuk hardware om het tijdstempel vast te leggen van het moment waarop een bericht op de poort wordt ontvangen. De ingevoerde tijd wordt gebruikt om de fout te berekenen.

Waarom is de klok van streek?

Fouten kunnen overal vandaan komen. Laten we beginnen met het feit dat de frequentiegeneratoren in de apparaten verschillend zijn en het zeer onwaarschijnlijk is dat twee verschillende apparaten klok voor klok perfect zullen werken. U kunt ook de voortdurend veranderende omgevingsomstandigheden toeschrijven die van invloed zijn op de gegenereerde frequentie.

Waar streven we naar?

Laten we zeggen dat we een apparaat hebben dat onder ideale omstandigheden werkt, een soort atoomklok die helemaal niet verkocht zal worden tot het einde van de wereld (natuurlijk aan de echte, en niet bestemd door de Maya-kalender) en we krijgen de taak om minstens ongeveer (met een nauwkeurigheid van 10 -9 sec) dezelfde uren te krijgen. We moeten deze klokken synchroniseren. Om dit te doen, kunt u het PTP-protocol implementeren.

Het verschil tussen een puur software implementatie en een implementatie met "iron support"

Een puur softwarematige implementatie zal de beloofde nauwkeurigheid niet halen. De tijd die is verstreken vanaf het moment dat het bericht werd ontvangen (meer precies, het signaal werd ontvangen om het bericht in het apparaat te ontvangen) tot de overgang naar het onderbrekings- of terugbelingangspunt kan niet strikt worden gedefinieerd. "Slimme hardware" met PTP-ondersteuning kan deze tijdstempels zelf neerzetten (bijvoorbeeld chips van Micrel, ik schrijf een driver speciaal voor KSZ8463MLI).
Naast tijdstempels omvat hardwareondersteuning ook de mogelijkheid om een ​​kristaloscillator af te stemmen (om de frequentie gelijk te maken met de master), of de mogelijkheid om de klok aan te passen (verhoog de klokwaarde met X ns elke cyclus). Hieronder meer daarover.

Laten we verder gaan met de IEEE 1588-standaard

De standaard is al beschreven op 289 pagina's. Overweeg wat minimaal nodig is om het protocol te implementeren. PTP is een client-server synchronisatieprotocol, d.w.z. er zijn minimaal 2 apparaten nodig om het protocol te implementeren. Het Master-apparaat is dus een atoomklok en het Slave-apparaat is een klok die nauwkeurig moet werken.

Wissel taal uit

Kondig bericht aan– aankondigingsbericht, bevat informatie die door de master naar alle slave-apparaten is verzonden. Slave-apparaten die dit bericht gebruiken, kunnen de beste master kiezen (hiervoor is een BMC-algoritme (Best Master Clock)). BMC is niet zo interessant. Dit algoritme is eenvoudig terug te vinden in de standaard. De keuze is gebaseerd op berichtvelden als nauwkeurigheid, variantie, klasse, prioriteit, etc. Laten we verder gaan met andere berichten.

Sync/Follow-up, DelayResp, PDelayResp/PDelayFollowUp- verzonden door de meester, hieronder zullen we ze in meer detail bekijken.

DelayReq, PDelayReq– aanvragen voor Slave-apparaten.

Zoals u kunt zien, is het Slave-apparaat niet uitgebreid, de Master geeft bijna alle informatie zelf. Het verzenden gebeurt op Multicast-adressen (indien gewenst kunt u de Unicast-modus gebruiken) adressen die strikt zijn gedefinieerd in de standaard. Voor PVertraging berichten hebben een apart adres (01-80-C2-00-00-0E voor Ethernet en 224.0.0.107 voor UDP). De overige berichten worden verzonden naar 01-1B-19-00-00-00 of 224.0.1.129. Pakketten verschillen in velden KlokIdentiteit(horloge-ID) en SequenceId(pakket-ID).

Werk sessie

Laten we zeggen dat de master is geselecteerd met behulp van het BMC-algoritme, of de enige master op het netwerk. De afbeelding toont de procedure voor communicatie tussen het hoofdapparaat en het gesynchroniseerde apparaat.

1. Het begint allemaal met de Meester die een bericht stuurt Synchroniseren en registreert tegelijkertijd de verzendtijd t1. Er zijn een- en tweetraps werkingsmodi. Het is heel gemakkelijk om ze te onderscheiden: als er een bericht is opvolgen- dan hebben we te maken met een implementatie in twee fasen, de gestippelde pijl toont optionele berichten
2. opvolgen bericht wordt daarna verzonden Synchroniseren en bevat tijd t1. Als de overdracht in één fase wordt uitgevoerd, dan Synchroniseren bevat t1 in de berichttekst. In ieder geval wordt t1 door ons apparaat ontvangen. Op het moment van ontvangst van het bericht Synchroniseren tijdstempel t2 wordt gegenereerd op de Slave. Zo krijgen we t1, t2
3. Slave genereert een bericht Vertragingsverzoek gelijktijdig met het genereren van t3
4. Meester ontvangt Vertragingsverzoek bericht, waarbij tegelijkertijd t4 wordt gegenereerd
5. t4 wordt verzonden naar het Salve-apparaat op VertragingResp bericht

Online berichten

Met zo'n uitwisselingssessie, zoals hierboven getoond, kan men alleen slagen als het kwarts idealiter dezelfde frequenties genereert voor de gesynchroniseerde apparaten. Het blijkt zelfs dat de klokfrequentie anders is, d.w.z. op het ene apparaat wordt de klokwaarde in 1 seconde met 1 seconde verhoogd en op het andere apparaat bijvoorbeeld met 1,000001 seconden. Hier komt het klokverschil vandaan.
De norm beschrijft een voorbeeld van het berekenen van de verhouding van de tijd die is verstreken op de Master en op de Slave voor een bepaald interval. Deze verhouding is de coëfficiënt voor de frequentie van het Slave-apparaat. Maar tegelijkertijd is er een indicatie dat de aanpassing op verschillende manieren kan worden uitgevoerd. Laten we er twee bekijken:

1. Wijzig de klokfrequentie van het Slave-apparaat (voorbeeld in de standaard)
2. Verander de klokfrequentie niet, maar voor elke cyclus van duur T zal de klokwaarde niet toenemen met T, maar met T + ∆t (gebruikt in mijn implementatie)

Bij beide methoden zal het nodig zijn om het verschil in tijdwaarden op het Master-apparaat voor een bepaald interval te berekenen, evenals het tijdsverschil voor hetzelfde interval op het Slave-apparaat. Coëfficiënt in de eerste methode:

De tweede methode vereist de berekening van ∆t. ∆t is de waarde die elk bepaald interval bij de tijdwaarde wordt opgeteld. In de afbeelding kunt u zien dat terwijl 22 - 15 = 7 seconden verstreken op de master, 75 + (87-75) / 2 - (30 + (37-30) / 2) = 47,5 seconden verstreken op de slave

Frequentie - processorfrequentie, bijvoorbeeld 25MHz - processorcyclus duurt 1/(25*10 6) = 40ns.
Afhankelijk van de mogelijkheden van het apparaat wordt de meest geschikte methode gekozen.
Om verder te gaan naar de volgende sectie, laten we de offset een beetje anders uitdrukken:

PTP-bedrijfsmodi

Als u naar de standaard kijkt, kunt u niet de enige manier vinden om de levertijd te berekenen. Er zijn 2 werkingsmodi voor PTPv2. Deze E2E (eind tot eind), hierboven werd overwogen, wordt de modus ook beschreven P2P (peer-to-peer). Laten we eens kijken waar welke methode moet worden toegepast en wat hun verschil is.
In principe kunt u alle modi naar believen gebruiken, maar ze kunnen niet op hetzelfde netwerk worden gecombineerd.

• In modus E2E de bezorgtijd wordt berekend op basis van berichten die zijn ontvangen via meerdere apparaten, die allemaal in het berichtcorrectieveld worden geplaatst Synchroniseren of Opvolgen(bij verzending in twee fasen) de tijd waarvoor het pakket op dit apparaat is vertraagd (als de apparaten rechtstreeks zijn aangesloten, wordt de correctie niet vermeld, dus we zullen ze niet in detail bekijken). Gebruikte berichten: Sync/FollowUp, DelayReq/DelayResp
• In modus P2P in het correctieveld wordt niet alleen de tijd dat het pakket vertraging heeft opgelopen, er wordt (t2-t1) aan toegevoegd (in de standaard af te lezen). Er wordt gebruik gemaakt van berichten Sync/FollowUp, PDelayReq/PDelayResp/PDelayRespFollowUp

Volgens de norm worden de uren genoemd die PTP-berichten passeren met een wijziging in het correctieveld Transparante klok (TC). Laten we in de figuren kijken hoe berichten in deze twee modi worden verzonden. Berichten zijn gemarkeerd met blauwe pijlen. Synchroniseren en opvolgen.


End-to-end-modus


Peer-to-peer-modus
We zien dat er enkele rode pijlen zijn verschenen in de P2P-modus. Dit zijn de overige berichten die we niet hebben overwogen, namelijk PDelayReq, PDelayResp en PDelayFollowUp. Hier is de uitwisselingssessie van deze berichten:

Levertijd fout

De standaard beschrijft de implementatie van het protocol in verschillende soorten netwerken. Ik gebruikte een ethernetnetwerk en ik ontving berichten op de ethernetlaag. In dergelijke netwerken verandert de bezorgtijd van pakketten voortdurend (vooral merkbaar bij het werken met nanoseconde precisie). Er worden verschillende filters toegepast om deze waarden te filteren.

Wat moet er gefilterd worden:

1. Tijd van levering
2. Vooroordeel

Mijn driver gebruikt ongeveer hetzelfde filtersysteem als de Linux-daemon. PTPd, waarvan de bron te vinden is, is er nog wat informatie. Ik zal je gewoon een schema geven:

LP IIR-filter (Infinite Impulse Response low-pass).(Filter met oneindige impulsrespons) beschreven door de formule:

, waar s is een coëfficiënt waarmee u de filterafsnijding kunt aanpassen.

Aanpassing berekening

Laten we verder gaan met afstemmen, naar de delta die bij de waarde van de seconde moet worden opgeteld. Berekeningsschema gebruikt op mijn systeem:

Ik heb een Kalman-filter gebruikt om de sterke tuning-jitter als gevolg van netwerkruis weg te filteren, ik vond het erg leuk. Over het algemeen kunt u elk gewenst filter gebruiken, het belangrijkste is om de grafiek glad te strijken. BIJ PTPd filteren is bijvoorbeeld eenvoudiger - het gemiddelde van de huidige en vorige waarden wordt berekend. Op de grafiek zie je de resultaten van het Kalman-filter in mijn driver (afstemmingsfout wordt weergegeven, uitgedrukt in subnanoseconden op een 25 MHz-chip):

We gaan over tot de afstelling van de afstelling, de afstelling moet naar een constante neigen, er wordt een PI-regelaar gebruikt. BIJ PTPd de klokoffset wordt aangepast (instelling gaat door offset), maar ik gebruik het om de trim aan te passen (een kenmerk van de KSZ8463MLI). We zien dat de controller niet perfect is afgesteld, maar in mijn geval volstaat deze aanpassing:

Het resultaat van het werk

Het resultaat wordt weergegeven in de grafiek. Klokoffset binnen -50ns tot 50ns. Bijgevolg bereikte ik de nauwkeurigheid die in tal van artikelen wordt genoemd. Natuurlijk bleven veel kleine kenmerken van de implementatie achter de schermen, maar het noodzakelijke minimum werd gedemonstreerd.

Stuur uw goede werk in de kennisbank is eenvoudig. Gebruik onderstaand formulier

Studenten, afstudeerders, jonge wetenschappers die de kennisbasis gebruiken in hun studie en werk zullen je zeer dankbaar zijn.

Gehost op http://www.allbest.ru/

Ministerie van Onderwijs en Wetenschappen van de Russische Federatie

Autonome onderwijsinstelling van de federale staat

Hoger beroepsonderwijs

"Nationale Onderzoek Nucleaire Universiteit "MEPhI"

Trekhgorny Technologisch Instituut - tak van NRNU MEPhI

Computer afdeling

in de discipline "Internettechnologieën"

over het onderwerp: “RSYNC-protocol. Tijd synchronisatie. NTP-protocol. SNTP-protocol"

Ingevuld door: leerling van groep 5VT-58

Koltsov DA

Gecontroleerd: st. docent Dolgopolova M.O.

Trekhgorny 2012

RSYNC-PROTOCOL

TIJD SYNCHRONISATIE

NTP-PROTOCOL

PROTOCOL SNTP

LIJST MET GEBRUIKTE INTERNETBRONNEN

APPS

RSYNC-PROTOCOL

Rsynchroniseren(eng. Remote Synchronization) is een programma voor UNIX-achtige systemen dat bestanden en mappen op twee plaatsen synchroniseert met minimaal verkeer, waarbij indien nodig gegevenscodering wordt gebruikt. Een belangrijk verschil tussen rsync en veel andere programma's/protocollen is dat mirroring wordt gedaan door één thread in elke richting (in plaats van één of meer threads per bestand). Rsync kan de inhoud van een map kopiëren of in kaart brengen en bestanden kopiëren, eventueel met behulp van compressie en recursie.

Ontwikkelaar- Wayne Davison;

operatiekamersysteem- Platformonafhankelijke software.

Uitgegeven onder de GNU GPL, rsync is gratis software.

Cross-platform(cross-platform)softwareveiligheid-- software die draait op meer dan één hardwareplatform en/of besturingssysteem. Een typisch voorbeeld is software die is ontworpen om tegelijkertijd op Linux- en Windows-besturingssystemen te draaien.

Er is een implementatie van rsync voor Winows, of beter gezegd geen directe implementatie, maar een assembly van rsync en cygwin genaamd cwRsync.

Algoritme

Nutsvoorziening rsync gebruikt een algoritme dat is ontwikkeld door de Australische programmeur Andrew Tridgell (bijlage C) om structuren (zoals bestanden) efficiënt over te dragen via communicatieverbindingen wanneer de ontvangende computer al een andere versie van die structuur heeft.

De ontvangende computer verdeelt zijn kopie van het bestand in niet-overlappende stukken van een vaste grootte S, en berekent een controlesom voor elk stuk: een MD4-hash (bijlage A) en een zwakkere rollende controlesom (bijlage B), en stuurt deze naar de server waarmee het synchroniseert.

De server waarmee ze zijn gesynchroniseerd, berekent controlesommen voor elk stuk van maat S in zijn versie van het bestand, inclusief overlappende stukken. Dit kan efficiënt worden berekend vanwege de speciale eigenschap van rollende controlesom: als de rollende controlesom van bytes van n tot n+S-1 R is, dan kan de rollende controlesom van bytes van n+1 tot n+S worden berekend uit R , byte n en byte n +S zonder rekening te hoeven houden met de bytes die binnen dit interval liggen. Dus als de rollende controlesombytes 1-25 al zijn berekend, worden de vorige controlesom en de bytes 1 en 26 gebruikt om de rollende controlesombytes 2-26 te berekenen.

Voornaamst Voordelen

Snelheid: In eerste instantie repliceert rsync alle inhoud tussen de bron en de bestemming (bestemming). Vervolgens draagt ​​rsync alleen de gewijzigde blokken of bits over naar de bestemming, waardoor de synchronisatie erg snel gaat;

Veiligheid: rsync omvat versleuteling van gegevens tijdens verzending met behulp van het SSH-protocol;

rsync maakt gebruik van blok-voor-blok datacompressie en -decompressie aan respectievelijk de verzendende en ontvangende kant. De door rsync gebruikte bandbreedte is dus lager in vergelijking met andere protocollen voor bestandsoverdracht.

Syntaxis

$ rsync-opties bronbestemming, waarbij Bron (bron) en Bestemming (bestemming) zowel lokaal als op afstand kunnen zijn. Specificeert bij gebruik met externe objecten de login, servernaam en het pad.

Enkele belangrijke opties:

1) -a,--archief archiefmodus;

2) -r,--recursief mappen doorlopen (recursie);

3) -R,--familielid relatieve paden;

4) -H,--harde koppelingen harde links opslaan (hardlink);

5) -S,--schaars efficiënt omgaan met schaarse bestanden;

6) -x--één-bestandssysteem overschrijdt de grenzen van het bestandssysteem niet;

7) -uitsluiten=PATROON bestanden van een bepaald voorbeeld uitsluiten;

8) -verwijderen-tijdens de ontvanger wordt verwijderd TIJDENS HET ZENDEN;

9) -verwijderen-na de ontvanger wordt verwijderd NA ZENDING.

TIJD SYNCHRONISATIE

Tijd in het tijdperk van informatietechnologie is van bijzonder belang geworden voor de moderne mens. Ieder van ons kijkt minstens meerdere keren per dag naar de klok. Veel mensen synchroniseren hun tijdwaarnemingsapparaten regelmatig via verschillende bronnen, waaronder internet. Nauwkeurige tijd speelt soms een doorslaggevende rol in gevallen waarin niet eens minuten, maar seconden belangrijk zijn. Handelen op de beurzen kan bijvoorbeeld uitlopen op een crash voor een speler wiens klok de verkeerde tijd aangaf.

Technologie synchronisatie tijd

Geheel het proces van tijdsynchronisatie wordt uitgevoerd via een speciaal netwerkprotocol genaamd NTP(NetwerkTijdprotocol). Dit protocol is een set van verschillende regels en wiskundige algoritmen, waardoor de tijd op uw computer nauwkeurig wordt afgesteld met een verschil van enkele honderdsten van een seconde. Er is ook een protocol voor systemen die niet zo'n precieze timing vereisen, genaamd SNTP. Het tijdsverschil tussen de bron en de ontvanger van het apparaat kan oplopen tot 1 seconde.

De technologie voor het verzenden van exacte tijdparameters is een meerlaagse structuur, waarbij elke onderliggende laag van elektronische apparaten wordt gesynchroniseerd met de bovenliggende laag. Hoe lager de technologielaag, hoe onnauwkeuriger de tijd die ervan wordt afgeleid. Maar dit is in theorie, in de praktijk hangt het allemaal af van de vele parameters die betrokken zijn bij het synchronisatiesysteem en kunt u bijvoorbeeld een nauwkeurigere tijd krijgen van de vierde laag apparaten dan van de derde.

Op het nulniveau van deze transmissieketen bevinden zich altijd, grof gezegd, klokken. Deze klokken zijn apparaten voor het tellen van moleculaire, atomaire of kwantumtijd en worden referentieklokken genoemd. Dergelijke apparaten verzenden tijdparameters niet rechtstreeks naar internet, ze zijn meestal met minimale vertragingen verbonden met de primaire computer via een snelle interface. Het zijn deze computers die de eerste laag in de technologische keten vormen. De tweede laag bevat machines die tijd ontvangen van de eerste laag apparaten via een netwerkverbinding, meestal via internet. Alle volgende lagen ontvangen informatie over de exacte tijd met behulp van dezelfde netwerkprotocollen van de hogere lagen.

Systemen synchronisatie tijd

BIJ in overeenstemming met de federale wet "Over communicatie" nr. 126 van 7 juli 2003, artikel 49 - "Boekhoud- en rapportagetijd op het gebied van communicatie", in de technologische processen van het verzenden en ontvangen van telecommunicatie- en postberichten, hun verwerking binnen het grondgebied van de Russische Federatie door telecommunicatie-exploitanten en postbedrijven moeten één enkele boekhoud- en rapportagetijd gebruiken - Moskou. Om dit te doen, is het noodzakelijk om een ​​exact tijdsysteem te organiseren op het digitale netwerk van de telecommunicatie-operator.

Een exact tijdsysteem is een reeks technische middelen die zorgen voor periodieke verzending van digitale informatie over de waarde van de huidige tijd van een referentiebron naar alle netwerkelementen om hun interne klokken te synchroniseren. Dit geldt voor digitale apparatuur van telecommunicatienetwerken, die verschillende gegevens in realtime verwerkt en moet zorgen voor de gelijktijdige uitvoering van bepaalde interne technologische processen.

De relevantie van het oplossen van het probleem van het organiseren van een systeem voor het synchroniseren van een enkele exacte tijd, of met andere woorden, het organiseren van tijdsynchronisatie, in telecommunicatienetwerken is onlosmakelijk verbonden met de ontwikkeling van factureringssystemen, controlesystemen voor verschillende doeleinden, netwerkbeveiliging, systemen, evenals het verbeteren van de methoden voor het bedienen van digitale telecommunicatieapparatuur en metrologische ondersteuning.

De afnemers van enkelvoudige exacte tijdsignalen zijn: computersystemen en computerservers (besturings- en bewakingssystemen voor netwerkapparatuur), apparatuur voor transportnetwerken SDH, ATM, IP en schakelnetwerken, facturatie- en databaseservers; apparatuur voor gegevensoverdracht en pakketschakeling (routers, schakelaars), enz.

Het gebruik van tijdsynchronisatie stelt u in staat om de start- en eindtijden van elk proces in het netwerk van een of meerdere telecommunicatie-operators te synchroniseren, bijvoorbeeld bij het lokaliseren van een ongeval met behulp van interne diagnose van apparatuur en het maken van een logboekinvoer over een gebeurtenis op een server in een controlesysteem, een gesprek van abonnees verbinden, informatieverkeer factureren in overeenstemming met het tijdstip van de dag en de locatie van de abonnee in het servicegebied van een bepaald netwerk, en tot slot het uitvoeren van procedures met betrekking tot het bevestigen van de ontvangst / verzending van een elektronische handtekening, het doen van transacties, enz.

Werk aan het creëren van een nauwkeurig tijdsysteem omvat:

* keuze van signaalbron van de exacte tijd;

* bepaling van de methode voor het verzenden van signalen van de exacte tijd via het communicatienetwerk;

* keuze uit netwerkprotocollen en signalen van exacte tijd;

* definitie van apparatuur die tijdsynchronisatie vereist;

* keuze van oplossing om diverse soorten apparatuur te voorzien van nauwkeurige tijdseinen.

Onder de zeer nauwkeurige en meest betaalbare manieren om tijdsignalen uit te zenden waarvoor geen huur van bestaande of de aanleg van extra communicatielijnen nodig is, kunnen met recht wereldwijde navigatiesatellietsystemen (GNSS) worden opgenomen: Russisch GLONASS en Amerikaans GPS. De globaliteit van de systemen wordt verzekerd door het functioneren in banen van een reeks satellieten die vanaf elk punt op aarde zichtbaar zijn en continu zeer nauwkeurige signalen uitzenden die kunnen worden gebruikt in een nauwkeurig tijdsysteem.

Op dit moment bijvoorbeeld het satellietsysteem GPS kan worden gebruikt om de apparatuur van telecommunicatienetwerken van Russische telecommunicatie-exploitanten alleen als tweede prioriteit te synchroniseren, daarom is het noodzakelijk om een ​​satellietsysteem te gebruiken als de belangrijkste bron van nauwkeurige tijdsignalen GLONASS.

Om een ​​tijdschaal van satellietsystemen te verkrijgen, is het noodzakelijk om speciale apparatuur te gebruiken die signaalontvangers bevat. GLONASS en GPS. Dergelijke gespecialiseerde apparatuur wordt een tijdserver genoemd ( Tijdserver). Bij het verzenden van tijdsignalen van de server naar externe netwerkclients worden speciale internetprotocollen gebruikt. NTP(NetwerkTijdprotocol) en PTP(PrecisieTijdProtocol- IEEE1588). Op basis van netwerkprotocollen is het aan te raden om een ​​nauwkeurig tijdsysteem op te bouwen volgens het principe van hiërarchie.

NTP-PROTOCOL

Het NTP-protocol (Network Time Protocol) wordt gebruikt door NTP-servers om informatie tussen netwerkabonnees te verspreiden met een nauwkeurige referentietijd. Het wordt ook door internet gebruikt om computers en processen gesynchroniseerd te houden.

NTP wordt al meer dan 25 jaar als internetprotocol gebruikt. Dit protocol is het langst gebruikte internetprotocol. Het werd geboren vanwege de noodzaak om tijd en processen op internet te synchroniseren. Het NTP-protocol werd voor het eerst gebruikt op LINUX- en UNIX-platforms, waaronder FreeBSD (een niet-commerciële versie van UNIX voor de pc), maar werd later gebruikt op het Windows-besturingssysteem. Dedicated NTP-systemen gebruiken voornamelijk het LINUX-besturingssysteem.

Daarnaast is er naast het NTP-protocol het SNTP-protocol (Simple Network Time Protocol). Op pakketniveau zijn deze twee protocollen volledig compatibel. Het belangrijkste verschil tussen de twee is dat SNTP niet beschikt over de complexe filter- en meerstapsfoutcorrectiesystemen die in NTP voorkomen. SNTP is dus een vereenvoudigde en gemakkelijker te implementeren versie van NTP. Het is bedoeld voor gebruik op netwerken waar zeer hoge tijdsnauwkeurigheid niet vereist is, en in de Microsoft-implementatie is het binnen 20 seconden nauwkeurig binnen een onderneming en niet meer dan 2 seconden binnen een enkele locatie. Het SNTP-protocol is gestandaardiseerd als RFC 1769 (versie 3) en RFC 2030 (versie 4).

Voornaamst principes protocol NTP

Protocol NTP is gemaakt om netwerkgebruikers drie opties te bieden:

1) het instellen van het falen van de tijdstandaard;

2) instellen van een volledige cyclus van tijdvertraging;

3) instellen van de spreiding van parameters ten opzichte van de gespecialiseerde referentieklok.

Het falen van de tijdstandaard is het tijdsverschil tussen de lokale klok en de referentieklok. Een volledige vertragingscyclus is de hoeveelheid tijd die het protocol nodig heeft om een ​​reactie van de server te ontvangen. De spreiding van parameters is de maximale fout van de lokale tijdklok ten opzichte van de norm.

Berichten protocol NTP

Protocol NTP gebruikt UDP (User Datagram Protocol) Een NTP-bericht bestaat uit verschillende velden:

1) Sprongindicator;

2) Versienummer;

6) Nauwkeurigheid;

7) Defect in het wortelstelsel;

8) Verstrooiing van parameters;

9) Identificatie van de standaard;

10) Aanmaakdatum;

11) Ontvangsttijdstempel;

12) Verzendtijdstempel;

13) Codeherkenning;

14) Berichtoverzicht.

De piekindicator waarschuwt voor een dreigende piek in optelling of verwijdering.

Het versienummer geeft het versienummer weer van NTP dat wordt gebruikt.

De modus helpt bij het instellen van de modus van het huidige NTP-bericht.

De decomposer is een 8-bits systeem dat het hiërarchische niveau van de referentieklok identificeert.

Poll definieert het maximale interval tussen berichten.

Nauwkeurigheid bepaalt de nauwkeurigheid van de lokale klok.

De fout in het rootsysteem geeft de nominale tijdreferentiefout aan.

Doel-ID is een ASCII-code van 4 tekens die de bron van het doel identificeert, bijvoorbeeld: GPS, DCF, MSF. Het veld Code-identificatie wordt gebruikt wanneer het nodig is om de geldigheid van een code vast te stellen.

De aanmaakdatum van de sjabloon bepaalt het tijdstip waarop het NTP-verzoek van de gebruiker naar de NTP-server is verzonden.

De ontvangen tijdstempel geeft het tijdstip aan waarop de aanvraag door de NTP-server is ontvangen.

Het verzendtijdstempel geeft het tijdstip aan waarop het antwoordbericht van de NTP-server naar de gebruiker is verzonden.

Het samenvattingsveld slaat de Message Authentication Code (MAC) berichtauthenticatiecode op.

modi het werk NTP servers

NTP De server kan in drie modi werken:

In de eerste twee modi stuurt de gebruiker een NTP-verzoek naar de server. De server reageert met een bericht dat de gebruiker gebruikt om de NTP-tijd te synchroniseren. In multicast-modus worden NTP-berichten periodiek verzonden met gespecificeerde tijdsintervallen.

referentie klok

Er kunnen verschillende externe tijdbronnen worden gebruikt om de tijd van NTP-servers te synchroniseren. GPS wordt vaak gebruikt om tijdnauwkeurigheid te garanderen. Daarnaast zijn er diverse publieke bronnen van referentietijd, zoals omroep. Veel radiostations zenden niet alleen uit op het grondgebied van hun land, maar ook in het buitenland, dus u kunt er gemakkelijk de tijd mee instellen.

SNTP-PROTOCOL

synchronisatiebestand voor protocolprogramma's

SNTP(Eng. Simple Network Time Protocol) - een protocol voor het synchroniseren van tijd via een computernetwerk. Het is een vereenvoudigde implementatie van het NTP-protocol. Het wordt gebruikt in ingebedde systemen en apparaten die geen hoge nauwkeurigheid vereisen, evenals in aangepaste tijdprogramma's. Het SNTP-protocol gebruikt hetzelfde tijdformaat als het NTP-protocol: een 64-bits getal bestaande uit een 32-bits secondenteller en een 32-bits fractionele secondenteller. Een tijdtellerwaarde van nul komt overeen met nul uur op 1 januari 1900, 18:28:16 uur, 7 februari 2036, enz. Om het protocol succesvol te laten werken, is het noodzakelijk dat de cliënt zijn tijd weet binnen ±34 jaar na de servertijd.

Formaat berichten

Afbeelding 1 - Berichtformaat

Beschrijving van de SNTP-berichtindelingsvelden weergegeven in figuur 1:

Correctie-indicator (IR) toont een waarschuwing over een toekomstige toevoeging of verwijdering van een seconde in de laatste minuut van de dag;

Versienummer (HB) -- huidige waarde 4;

Het polling-interval is een geheel getal zonder teken waarvan de binaire exponent het maximale interval tussen opeenvolgende berichten in seconden aangeeft. Alleen gedefinieerd voor serverberichten, geldige waarden zijn 4 (16s) tot 17 (ongeveer 36h);

Precisie is een geheel getal met teken waarvan de binaire exponent de nauwkeurigheid van de systeemklok aangeeft. Alleen gedefinieerd voor serverberichten, typische waarden zijn?6 tot?20;

Vertraging is een ondertekend vast puntnummer tussen 15 en 16 cijfers dat de totale heen-en terugreistijd aangeeft voor het signaal om de tijdserverklokbron te bereiken. Alleen gedefinieerd voor serverberichten;

De variantie is een niet-ondertekend getal met een vast punt tussen 15 en 16 cijfers, dat de maximale fout als gevolg van klokinstabiliteit weergeeft. Alleen gedefinieerd voor serverberichten;

Bron-ID -- serversynchronisatiebron, tekenreeks voor stratum 0 en 1, IP-adres voor secundaire servers. Alleen gedefinieerd voor serverberichten;

Updatetijd - De tijd waarop de systeemklok voor het laatst is ingesteld of aangepast;

Identificatiesleutel, berichtsamenvatting -- optionele velden die worden gebruikt voor authenticatie.

Operaties servers SNTP

Server SNTP kan werken in unicast-, anycast- of multicast-modi, of een combinatie van deze modi. In de unicast- en anycast-modus ontvangt de server verzoeken (modus 3), wijzigt bepaalde velden in de NTP-header en stuurt een antwoord (modus 4), waarbij mogelijk dezelfde berichtenbuffer wordt gebruikt als bij een verzoek. In de anycast-modus luistert de server op een specifiek IANA-gedefinieerd broadcast- of multicast-adres, maar gebruikt zijn eigen unicast-adres in het afzenderadresveld van het antwoord. Met uitzondering van de adresselectie in het antwoord, is de werking van de server in anycast- en unicast-modus identiek. Multicast-berichten worden doorgaans verzonden met intervallen van 64 tot 1024 seconden, afhankelijk van de stabiliteit van de klok van de klant en de vereiste nauwkeurigheid.

In de modi anycast en unicast worden de velden VN en Poll van het verzoek ongewijzigd naar het antwoord gekopieerd. Als het verzoekmodusveld de code 3 (client) bevat, wordt deze in het antwoord op 4 (server) gezet; anders wordt dit veld geschreven als 2 (symmetrisch passief) om te voldoen aan de NTP-specificatie. Hierdoor kunnen clients die zijn geconfigureerd voor symmetrische actieve modus (modus 1) succesvol werken, zelfs als de configuratie niet optimaal is. In multicast-modus in het veld VN code 4 wordt ingevoerd, in het modusveld code 5 (broadcast) en in het registratieveld het gehele deel van de logaritmewaarde in grondtal 2 van de duur van de aanvraagverzendperiode.

In de unicast- en anycast-modus reageert de server al dan niet op verzoeken, maar het beste gedrag is om toch een antwoord te sturen, omdat dit ervoor zorgt dat de server bereikbaar is.

De belangrijkste indicator van een serverstoring is het LI-veld, waar code 3 aangeeft dat deze niet synchroon loopt. Wanneer precies deze waarde wordt ontvangen, MOET de client het bericht van de server negeren, ongeacht de inhoud van andere velden.

Configuratie en controle

Voorletter SNTP-servers en -clients kunnen worden geconfigureerd vanuit een configuratiebestand, als een dergelijk bestand bestaat, of via een seriële poort. Verwacht wordt dat SNTP-servers en -clients weinig tot geen hostspecifieke configuratie vereisen (behalve een IP-adres, subnetmasker of OSI NSAP-adres).

Unicast-clients moeten worden voorzien van de servernaam of het adres. Als een servernaam wordt gebruikt, zijn een of meer DNS-serveradressen in de buurt vereist.

Multicast-servers en anycast-clients moeten worden voorzien van een TTL-waarde en een lokaal broadcast- of multicast-multicastadres. Anycast-servers en multicast-clients kunnen worden geconfigureerd met behulp van lijsten met adres-maskerparen. Dit biedt toegangscontrole zodat bewerkingen alleen worden uitgevoerd op bekende clients of servers. Deze servers en clients moeten IGMP ondersteunen en moeten het lokale broadcast- of multicast-adres kennen.

LIJST MET GEBRUIKTE INTERNETBRONNEN

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.

APPS

bijlage A

MD4(Message Digest 4) is een hash-functie ontwikkeld door Ronald Rivest, professor aan de Universiteit van Massachusetts in 1990 en voor het eerst beschreven in RFC 1186. Gegeven een willekeurig invoerbericht, genereert de functie een 128-bits hash-waarde die de message digest wordt genoemd. Dit algoritme wordt gebruikt in het MS-CHAP-authenticatieprotocol dat door Microsoft is ontwikkeld om authenticatieprocedures uit te voeren voor externe Windows-werkstations. Het is de voorloper van MD5.

Afbeelding A - Bediening van de MD4

Eén MD4-operatie (figuur A). MD4-hashing bestaat uit 48 van dergelijke bewerkingen, gegroepeerd in 3 ronden van 16 bewerkingen. F -- niet-lineaire functie; in elke ronde verandert de functie. Mi betekent een 32-bits blok van het invoerbericht, en Ki is een 32-bits constante, verschillend voor elke bewerking.

Bijlage B

Rollende controlesom

Ringvormighasj(eng. rolling hash) -- een hash-functie die de invoer binnen een bepaald venster verwerkt. Het verkrijgen van de hash-waarde voor het verschoven venster (venster) in dergelijke functies is een goedkope operatie. Om een ​​waarde opnieuw te berekenen, hoeft u alleen de vorige hash-waarde te kennen; de waarde van de invoergegevens die buiten het venster zijn gebleven; en de waarde van de gegevens die het venster zijn binnengekomen. Het proces is vergelijkbaar met het berekenen van een voortschrijdend gemiddelde.

Het wordt gebruikt in het Rabin-Karp substring-zoekalgoritme, evenals in het rsync-programma voor het vergelijken van binaire bestanden (de adler-32 ringversie wordt gebruikt).

Bijlage C

Andrew Tridgell

Andreas"Tridge"Trigel(28 februari 1967) is een Australische programmeur, bekend als de auteur en medewerker van het Samba-project en mede-uitvinder van het rsync-algoritme. Hij staat ook bekend om zijn werk aan de analyse van complexe propriëtaire protocollen en algoritmen, waardoor compatibele gratis implementaties konden worden gemaakt. Winnaar Vrije Software Award 2005.

VrijSoftwarePrijs is een jaarlijkse FSF-onderscheiding voor bijdragen aan vrije software die in 1998 is opgericht.

Afbeelding C - Andrew Tridgell

Gehost op Allbest.ru

Vergelijkbare documenten

Analyse van de belangrijkste aanvallen op het TLS-protocol en identificatie van methoden om deze aanvallen tegen te gaan. Ontwikkeling van een methode voor het onderscheppen en decoderen van verkeer dat via het HTTPS-protocol wordt verzonden. Decodering van verzonden gegevens in een modus die bijna realtime is.

artikel, toegevoegd 21-09-2017


De creatie van het UNIX-besturingssysteem. Geschiedenis van creatie en ontwikkeling van protocollen in ТСР/ІР. Transport protocol. Een logisch communicatiekanaal tussen een dzherelom en een otrimuvaem-gegevens zonder een tot stand gebrachte link. Interactieprotocol met de domeinnaamserver.

test, toegevoegd 18-05-2009


Soorten gevallen van systeemblokken. Basisnetwerktopologieën: bus, ring, ster, boom. FTP is een protocol voor het overbrengen van bestanden via computernetwerken. Softwareclassificatie. Systemen voor het ophalen van informatie en hun classificatie.

test, toegevoegd 24-12-2010


Definitie van een IP-protocol dat pakketten tussen netwerken overdraagt ​​zonder verbindingen tot stand te brengen. Headerstructuur van IP-pakketten. Initialisatie van TCP-verbinding, de fasen. Implementatie van IP op de router. TCP Reliable Message Delivery Protocol, zijn segmenten.

controlewerk, toegevoegd 09-11-2014


Het concept van het Secure Sockets Layer-protocol. "Beveiligd kanaal", basiseigenschappen. Het gebruik van het protocol, de nadelen ervan. EtherSnoop-interface. Fasen van het dialoogprotocol. Openbare sleutels, distributiefuncties. Uitwisseling van internetgegevens.

samenvatting, toegevoegd 31/10/2013


Algemene informatie over het FTP-protocol voor gegevensoverdracht. Technische processen voor het maken van een verbinding met behulp van het FTP-protocol. FTP-verbindingssoftware. Enkele problemen van FTP-servers. FTP-protocolopdrachten.

samenvatting, toegevoegd 07-11-2008


Beschrijving en doel van het DNS-protocol. De bestandshost gebruiken. Kenmerken en beschrijving van aanvalsmethoden op DNS: nep-DNS-server, eenvoudige DNS-overstroming, phishing, aanval door gereflecteerde DNS-verzoeken. Het beschermen en tegengaan van aanvallen op het DNS-protocol.

samenvatting, toegevoegd 15/12/2014


Ontwikkeling van een serverprogramma waarmee je op afstand een computer met Linux kunt monitoren. Voorwaarden die nodig zijn om dit probleem op te lossen: gebruikte protocollen voor gegevensoverdracht, softwaretools, dynamische bibliotheken.

scriptie, toegevoegd 18-06-2009


Beschrijving van de belangrijkste typen HDLC-protocolstations. Normale, asynchrone en gebalanceerde bedrijfsmodi van het station in de staat van informatieoverdracht. Controlemethoden voor gegevensstromen. Formaat en inhoud van de informatie- en controlevelden van het HDLC-protocol.

laboratoriumwerk, toegevoegd 02.10.2013


De functie van het protocol en de pakketstructuur van het protocol dat wordt ontwikkeld. De lengte van de kopvelden. Berekening van de lengte van de buffer bij de ontvangst, afhankelijk van de lengte van het pakket en de toegestane vertraging. Algoritmen voor gegevensverwerking voor ontvangen en verzenden. Software-implementatie van het protocol.

65 nanometer is het volgende doel van de Zelenograd Angstrem-T-fabriek, die 300-350 miljoen euro gaat kosten. De onderneming heeft al een aanvraag ingediend voor een zachte lening voor de modernisering van productietechnologieën bij Vnesheconombank (VEB), meldde Vedomosti deze week, daarbij verwijzend naar Leonid Reiman, voorzitter van de raad van bestuur van de fabriek. Nu bereidt Angstrem-T zich voor op de lancering van een lijn voor de productie van chips met een 90nm-topologie. Medio 2017 starten de aflossingen op de vorige VEB-lening, waarvoor deze is aangekocht.

Peking stortte Wall Street in

Belangrijke Amerikaanse indices markeerden de eerste dagen van het nieuwe jaar met een recorddaling, miljardair George Soros waarschuwde al dat de wereld wacht op een herhaling van de crisis van 2008.

De eerste Russische consumentenprocessor Baikal-T1 tegen een prijs van $ 60 wordt gelanceerd in massaproductie

Het bedrijf Baikal Electronics belooft begin 2016 de Russische Baikal-T1-processor ter waarde van ongeveer $ 60 in industriële productie te lanceren. Er zal vraag naar apparaten zijn als deze vraag door de staat wordt gecreëerd, zeggen marktpartijen.

MTS en Ericsson gaan gezamenlijk 5G ontwikkelen en implementeren in Rusland

PJSC "Mobile TeleSystems" en Ericsson hebben overeenkomsten getekend over samenwerking bij de ontwikkeling en implementatie van 5G-technologie in Rusland. In pilotprojecten, onder meer tijdens het WK 2018, wil MTS de ontwikkelingen van de Zweedse leverancier testen. Begin volgend jaar start de operator een dialoog met het ministerie van Telecom en Massacommunicatie over de totstandkoming van technische eisen voor de vijfde generatie mobiele communicatie.

Sergey Chemezov: Rostec is al een van de tien grootste ingenieursbureaus ter wereld

In een interview met RBC beantwoordde het hoofd van Rostec, Sergey Chemezov, brandende vragen: over het Platon-systeem, de problemen en vooruitzichten van AVTOVAZ, de belangen van de State Corporation in de farmaceutische industrie, sprak over internationale samenwerking onder sanctiedruk, import vervanging, reorganisatie, ontwikkelingsstrategieën en nieuwe kansen in moeilijke tijden.

Rostec is "beschermd" en grijpt op de lauweren van Samsung en General Electric

De Raad van Toezicht van Rostec keurde de "Ontwikkelingsstrategie tot 2025" goed. De belangrijkste taken zijn het vergroten van het aandeel van hightech civiele producten en het inhalen van General Electric en Samsung op belangrijke financiële indicatoren.