Ynlieding
It konsept fan it bouwen fan in "Digital Substation" yn 'e elektryske enerzjysektor fereasket syngronisaasje mei in krektens fan 1 μs. Finansjele transaksjes fereaskje ek mikrosekonden krektens. Yn dizze applikaasjes is NTP-tiidnauwkeurigens net mear genôch.
It PTPv2-syngronisaasjeprotokol, beskreaun troch de IEEE 1588v2-standert, soarget foar syngronisaasjekrektens fan ferskate tsientallen nanosekonden. PTPv2 lit jo syngronisaasjepakketten ferstjoere oer L2- en L3-netwurken.
De wichtichste gebieten dêr't PTPv2 wurdt brûkt binne:
- enerzjy;
- kontrôle- en mjitapparatuer;
- militêr-yndustriële kompleks;
- telecom;
- finansjele sektor.
Dizze post ferklearret hoe't it PTPv2-syngronisaasjeprotokol wurket.
Wy hawwe mear ûnderfining yn 'e yndustry en sjogge dit protokol faak yn enerzjyapplikaasjes. Dêrom sille wy de resinsje mei foarsichtigens dwaan .
Wêrom is it nedich?
Op it stuit befetsje STO 34.01-21-004-2019 fan PJSC Rosseti en STO 56947007-29.240.10.302-2020 fan PJSC FGC UES easken foar it organisearjen fan in prosesbus mei tiidsyngronisaasje fia PTPv2.
Dit komt troch it feit dat relaisbeskermingsterminals en mjitapparaten ferbûn binne mei de prosesbus, dy't instantane stroom- en spanningswearden troch de prosesbus ferstjoere, mei saneamde SV-streamen (multicaststreams).
Relaisbeskermingsterminals brûke dizze wearden om baaibeskerming út te fieren. As de krektens fan tiidmjittingen lyts is, dan kinne guon beskermingen falsk wurkje.
Bygelyks, ferdigeningswurken fan absolute selektiviteit kinne it slachtoffer wurde fan "swakke" tiidsyngronisaasje. Faak is de logika fan sokke ferdigeningswurken basearre op in ferliking fan twa hoemannichten. As de wearden ôfwike troch in foldwaande grutte wearde, dan wurdt de beskerming ynskeakele. As dizze wearden wurde mjitten mei in tiidkrektens fan 1 ms, dan kinne jo in grut ferskil krije wêr't de wearden eins normaal binne as mjitten mei in krektens fan 1 μs.
PTP ferzjes
It PTP-protokol waard oarspronklik beskreaun yn 2002 yn 'e IEEE 1588-2002 standert en waard neamd "Standert foar in Precision Clock Synchronization Protocol foar Networked Measurement and Control Systems." Yn 2008, de bywurke IEEE 1588-2008 standert waard útbrocht, dy't beskriuwt PTP Version 2. Dizze ferzje fan it protokol ferbettere krektens en stabiliteit, mar net behâlden efterút komptabiliteit mei de earste ferzje fan it protokol. Ek yn 2019 waard in ferzje fan 'e IEEE 1588-2019-standert frijlitten, dy't PTP v2.1 beskriuwt. Dizze ferzje foeget lytse ferbetterings ta oan PTPv2 en is efterút kompatibel mei PTPv2.
Mei oare wurden, wy hawwe de folgjende ôfbylding mei ferzjes:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
-
Ynkompatibel
Ynkompatibel
PTPv2 (IEEE 1588-2008)
Ynkompatibel
-
Kompatibel
PTPv2.1 (IEEE 1588-2019)
Ynkompatibel
Kompatibel
-
Mar, lykas altyd, binne d'r nuânses.
Inkompatibiliteit tusken PTPv1 en PTPv2 betsjut dat in PTPv1-ynskeakele apparaat net by steat is om te syngronisearjen mei in krekte klok dy't rint op PTPv2. Se brûke ferskate berjochtformaten om te syngronisearjen.
Mar it is noch altyd mooglik om apparaten te kombinearjen mei PTPv1 en apparaten mei PTPv2 op itselde netwurk. Om dit te berikken kinne guon fabrikanten jo de protokolferzje selektearje op 'e râneklokpoarten. Dat is, in grinsklok kin syngronisearje mei PTPv2 en noch oare klokken dy't dêrmei ferbûn binne syngronisearje mei sawol PTPv1 as PTPv2.
PTP apparaten. Wat binne se en hoe binne se oars?
De IEEE 1588v2-standert beskriuwt ferskate soarten apparaten. Allegear binne werjûn yn 'e tabel.
De apparaten kommunisearje mei elkoar oer in LAN mei PTP.
PTP-apparaten wurde klokken neamd. Alle horloazjes nimme de krekte tiid fan it gruttemasterhorloazje.
D'r binne 5 soarten horloazjes:
Grootmeestersklok
De wichtichste boarne fan krekte tiid. Faak foarsjoen fan in ynterface foar it ferbinen fan GPS.
Gewoane klok
In ienpoarte-apparaat dat in master (masterklok) of slave (slaveklok) kin wêze
Masterklok (master)
Se binne de boarne fan 'e krekte tiid wêrmei oare klokken wurde syngronisearre
Slave klok
Ein apparaat dat wurdt syngronisearre út de master klok
Grins Klok
In apparaat mei meardere havens dat kin in master as in slaaf.
Dat is, dizze klokken kinne syngronisearje fan 'e superieure masterklok en de ynferior slaveklokken syngronisearje.
End-to-end Transparante klok
In apparaat mei meardere havens dat is noch in master klok noch in slaaf. It stjoert PTP-gegevens oer tusken twa horloazjes.
By it ferstjoeren fan gegevens korrigearret de transparante klok alle PTP-berjochten.
De korreksje bart troch it tafoegjen fan de fertragingstiid op dit apparaat oan it korreksjefjild yn 'e koptekst fan it ferstjoerde berjocht.
Peer-to-Peer Transparante klok
In apparaat mei meardere havens dat is noch in master klok noch in slaaf.
It stjoert PTP-gegevens oer tusken twa horloazjes.
By it ferstjoeren fan gegevens korrigearret de transparante klok alle PTP-berjochten Sync en Follow_Up (mear oer har hjirûnder).
De korreksje wurdt berikt troch tafoeging oan it korreksjefjild fan it útstjoerde pakket de fertraging op it útstjoerapparaat en de fertraging op it gegevensoerdrachtkanaal.
Management Node
In apparaat dat oare horloazjes konfigurearret en diagnoaze
Master- en slaveklokken wurde syngronisearre mei tiidstempels yn PTP-berjochten. D'r binne twa soarten berjochten yn it PTP-protokol:
- Eventberjochten binne syngronisearre berjochten dy't it generearjen fan in tiidstempel belûke op it momint dat it berjocht ferstjoerd wurdt en op it momint dat it wurdt ûntfongen.
- Algemiene berjochten - Dizze berjochten hawwe gjin tiidstempels nedich, mar kinne tiidstempels befetsje foar besibbe berjochten
Event Berjochten
Algemiene berjochten
Sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Meidielje
Ferfolch
Delay_Resp
Pdelay_Resp_Follow_Up
Behear
Sinjaal
Alle soarten berjochten sille hjirûnder yn mear detail besprutsen wurde.
Basic syngronisaasje problemen
As in syngronisaasjepakket wurdt oerbrocht oer in lokaal netwurk, wurdt it fertrage by de skeakel en yn 'e gegevenskeppeling. Elke skeakel sil in fertraging fan sawat 10 mikrosekonden produsearje, wat net akseptabel is foar PTPv2. Ommers, wy moatte berikke in krektens fan 1 μs op it definitive apparaat. (Dit is as wy it oer enerzjy hawwe. Oare applikaasjes kinne in gruttere krektens fereaskje.)
IEEE 1588v2 beskriuwt ferskate operearjende algoritmen wêrmei jo de tiidfertraging opnimme en korrizjearje.
Wurkalgoritme
Under normale operaasje wurket it protokol yn twa fazen.
- Fase 1 - it oprjochtsjen fan de "Master Clock - Slave Clock" hierargy.
- Fase 2 - kloksyngronisaasje mei in End-to-End of Peer-to-Peer-meganisme.
Fase 1 - Oprjochting fan de Master-Slave-hierargy
Elke haven fan in reguliere of râne klok hat in bepaald oantal steaten (slave klok en master klok). De standert beskriuwt it oergongsalgoritme tusken dizze steaten. By programmearring wurdt sa'n algoritme in finite state masine of steatmasine neamd (mear details yn Wiki).
Dizze steatmasine brûkt it Best Master Clock Algorithm (BMCA) om de master yn te stellen by it ferbinen fan twa klokken.
Dit algoritme lit it horloazje de ferantwurdlikheden fan 'e grandmaster-horloazje oernimme as it upstream-grandmasterhorloazje GPS-sinjaal ferliest, offline giet, ensfh.
Steattransysjes neffens de BMCA wurde gearfette yn it folgjende diagram:
Ynformaasje oer it horloazje oan 'e oare ein fan' e "draad" wurdt ferstjoerd yn in spesjaal berjocht (berjocht oankundigje). Sadree't dizze ynformaasje is ûntfongen, rint de steat masine algoritme en in ferliking wurdt makke om te sjen hokker klok is better. De haven op it bêste horloazje wurdt it masterhorloazje.
In ienfâldige hierargy wurdt werjûn yn it diagram hjirûnder. Paden 1, 2, 3, 4, 5 meie befetsje in Transparante klok, mar se dogge net mei oan it fêststellen fan de Master Clock - Slave Clock hierargy.
Fase 2 - Syngronisearje reguliere en râne klokken
Fuort nei it fêststellen fan de "Master Clock - Slave Clock" hiërargy, begjint de syngronisaasje faze fan reguliere en grins klokken.
Om te syngronisearjen stjoert de masterklok in berjocht mei in tiidstempel nei de slaveklokken.
De masterklok kin wêze:
- ien poadium;
- twa-poadium.
Single-stage klokken stjoere ien Sync-berjocht om te syngronisearjen.
In klok mei twa etappe brûkt twa berjochten foar syngronisaasje - Sync en Follow_Up.
Twa meganismen kinne brûkt wurde foar de syngronisaasjefaze:
- Fertraging fersyk-antwurd meganisme.
- Peer fertraging mjitting meganisme.
Litte wy earst nei dizze meganismen sjen yn it ienfâldichste gefal - as transparante horloazjes net wurde brûkt.
Fertraging fersyk-antwurd meganisme
It meganisme omfettet twa stappen:
- It mjitten fan de fertraging by it ferstjoeren fan in berjocht tusken de masterklok en de slaveklok. Utfierd mei help fan in fertraging fersyk-antwurd meganisme.
- Korreksje fan 'e krekte tiidferskowing wurdt útfierd.
Wachttiid mjitting
t1 - Tiid fan it ferstjoeren fan it Sync-berjocht troch de masterklok; t2 - Tiid fan ûntfangst fan it Sync-berjocht troch de slaveklok; t3 - Tiid fan it ferstjoeren fan it fertragingsfersyk (Delay_Req) troch de slaveklok; t4 - Delay_Req ûntfangsttiid troch de masterklok.
As de slaveklok de tiden t1, t2, t3 en t4 ken, kin it de gemiddelde fertraging berekkenje by it ferstjoeren fan it syngronisaasjeberjocht (tmpd). It wurdt as folget berekkene:
By it ferstjoeren fan in Sync- en Follow_Up-berjocht wurdt de tiidfertraging fan 'e master nei de slaaf berekkene - t-ms.
By it ferstjoeren fan Delay_Req- en Delay_Resp-berjochten wurdt de tiidfertraging fan 'e slaaf nei de master berekkene - t-sm.
As der asymmetry optreedt tusken dizze twa wearden, dan ferskynt in flater by it korrigearjen fan de ôfwiking fan 'e krekte tiid. De flater wurdt feroarsake troch it feit dat de berekkene fertraging it gemiddelde is fan de t-ms en t-sm fertragingen. As de fertragingen net lyk oan elkoar binne, dan sille wy de tiid net krekt oanpasse.
Korreksje fan tiidferskowing
Sadree't de fertraging tusken de masterklok en de slaveklok bekend is, fiert de slaveklok tiidkorreksje út.
Slaveklokken brûke it Sync-berjocht en in opsjoneel Follow_Up-berjocht om de krekte tiidôfset te berekkenjen by it ferstjoeren fan in pakket fan 'e master nei de slaveklokken. De ferskowing wurdt berekkene mei de folgjende formule:
Peer fertraging mjitting meganisme
Dit meganisme brûkt ek twa stappen foar syngronisaasje:
- De apparaten mjitte de tiidfertraging nei alle buorlju troch alle havens. Om dit te dwaan brûke se in peer-fertragingsmeganisme.
- Korreksje fan de krekte tiid shift.
Wachttiid mjitten tusken apparaten dy't Peer-to-Peer-modus stypje
De latency tusken havens dy't it peer-to-peer-meganisme stypje, wurdt mjitten mei de folgjende berjochten:
As poarte 1 de tiden t1, t2, t3 en t4 ken, kin it de gemiddelde fertraging (tmld) berekkenje. It wurdt berekkene mei de folgjende formule:
De haven brûkt dan dizze wearde by it berekkenjen fan it oanpassingsfjild foar elk Sync-berjocht of opsjoneel Follow_Up-berjocht dat troch it apparaat giet.
De totale fertraging sil gelyk wêze oan de som fan 'e fertraging by it oerdracht fia dit apparaat, de gemiddelde fertraging by it oerdracht fia it gegevenskanaal en de fertraging al befette yn dit berjocht, ynskeakele op streamop apparaten.
Berjochten Pdelay_Req, Pdelay_Resp en opsjoneel Pdelay_Resp_Follow_Up tastean jo te krijen de fertraging fan master nei slaaf en fan slaaf nei master (sirkulêr).
Elke asymmetry tusken dizze twa wearden sil in flater foar korreksje fan tiidoffset ynfiere.
It oanpassen fan de krekte tiid ferskowing
Slaveklokken brûke in Sync-berjocht en in opsjoneel Follow_Up-berjocht om de krekte tiidferdieling te berekkenjen by it ferstjoeren fan in pakket fan 'e master nei de slaveklokken. De ferskowing wurdt berekkene mei de folgjende formule:
Foardielen oanpassing fan de peer-to-peer meganisme - de tiid fertraging fan elk Sync of Follow_Up berjocht wurdt berekkene as it wurdt oerdroegen yn it netwurk. Dêrtroch sil it feroarjen fan it oerdrachtpaad op gjin inkelde manier ynfloed hawwe op de krektens fan 'e oanpassing.
As jo dit meganisme brûke, fereasket tiidsyngronisaasje gjin berekkening fan 'e tiidfertraging lâns it paad troch it syngronisaasjepakket, lykas dien wurdt yn' e basisútwikseling. Dy. Delay_Req en Delay_Resp berjochten wurde net ferstjoerd. Yn dizze metoade wurdt de fertraging tusken de master- en slaveklokken gewoan gearfette yn it oanpassingsfjild fan elk Sync- of Follow_Up-berjocht.
In oar foardiel is dat de masterklok befrijd wurdt fan 'e needsaak om Delay_Req-berjochten te ferwurkjen.
Bedriuwsmodi fan transparante klokken
Dêrtroch wiene dit ienfâldige foarbylden. Stel no dat skeakels ferskine op it syngronisaasjepaad.
As jo skeakels brûke sûnder PTPv2-stipe, sil it syngronisaasjepakket op 'e skeakel mei sawat 10 µs fertrage wurde.
Switches dy't stypje PTPv2 wurde neamd Transparante klokken yn IEEE 1588v2 terminology. Transparante klokken wurde net syngronisearre fan 'e masterklok en dogge net mei oan' e hierargy "Master Clock - Slave Clock", mar by it ferstjoeren fan syngronisaasjeberjochten ûnthâlde se hoe lang it berjocht troch har fertrage waard. Hjirmei kinne jo de tiidfertraging oanpasse.
Transparante klokken kinne operearje yn twa modi:
- Ein-oan-ein.
- Peer-to-Peer.
Ein-oan-ein (E2E)
De transparante klok E2E stjoert Sync-berjochten út en byhearrende Follow_Up-berjochten op alle havens. Sels dyjingen dy't blokkearre binne troch guon protokollen (bygelyks RSTP).
De switch ûnthâldt it tiidstempel doe't in Sync pakket (Follow_Up) waard ûntfongen op 'e haven en as it waard stjoerd út de haven. Op grûn fan dizze twa tiidstempels wurdt de tiid berekkene dy't it nimt foar de skeakel om it berjocht te ferwurkjen. Yn de standert wurdt dizze tiid ferbliuwstiid neamd.
De ferwurkingstiid wurdt tafoege oan it korreksjefjild fan it Sync (ienstap klok) of Follow_Up (twa-stap klok) berjocht.
De E2E transparante klok mjit de ferwurkingstiid foar Sync- en Delay_Req-berjochten dy't troch de skeakel passe. Mar it is wichtich om te begripen dat de tiidfertraging tusken de masterklok en de slaveklok wurdt berekkene mei it fertragingsfersyk-antwurdmeganisme. As de masterklok feroaret of it paad fan 'e masterklok nei de slaveklok feroaret, wurdt de fertraging wer metten. Dit fergruttet de oergongstiid yn gefal fan netwurkferoarings.
De transparante klok P2P, neist it mjitten fan 'e tiid dy't it nimt foar in skeakel foar it ferwurkjen fan in berjocht, mjit de fertraging op' e gegevensferbining nei syn neiste buorman mei in buorlatensmeganisme.
Wachttiid wurdt mjitten op elke keppeling yn beide rjochtingen, ynklusyf keppelings dy't wurde blokkearre troch wat protokol (lykas RSTP). Hjirmei kinne jo de nije fertraging yn it syngronisaasjepaad fuortendaliks berekkenje as de gruttemasterklok of netwurktopology feroaret.
Berjochtferwurkingstiid troch skeakels en latency wurde sammele by it ferstjoeren fan Sync- of Follow_Up-berjochten.
Soarten PTPv2-stipe troch skakelaars
Switches kinne PTPv2 stypje:
- programmatysk;
- hardware.
By it ymplementearjen fan it PTPv2-protokol yn software freget de skeakel in tiidstempel fan 'e firmware. It probleem is dat de firmware syklisk wurket, en jo moatte wachtsje oant it de aktuele syklus beëiniget, it fersyk nimt foar ferwurking en jout in tiidstempel nei de folgjende syklus. Dit sil ek tiid nimme, en wy sille in fertraging krije, hoewol net sa wichtich as sûnder softwarestipe foar PTPv2.
Allinich hardwarestipe foar PTPv2 lit jo de fereaske krektens behâlde. Yn dit gefal, de tiid stimpel wurdt útjûn troch in spesjale ASIC, dat is ynstallearre op de haven.
Berjochtformaat
Alle PTP-berjochten besteane út de folgjende fjilden:
- Koptekst - 34 bytes.
- Body - grutte hinget ôf fan it type berjocht.
- Suffix is opsjoneel.
Header
It koptekstfjild is itselde foar alle PTP-berjochten. Syn grutte is 34 bytes.
Koptekstfjildformaat:
messageType - befettet it type berjocht dat wurdt ferstjoerd, bygelyks Sync, Delay_Req, PDelay_Req, ensfh.
messageLength - befettet de folsleine grutte fan it PTP-berjocht, ynklusyf koptekst, lichem en efterheaksel (mar útsein padding-bytes).
domeinNumber - bepaalt by hokker PTP-domein it berjocht heart.
Domein - dit binne ferskate ferskillende klokken sammele yn ien logyske groep en syngronisearre fan ien masterklok, mar net needsaaklik syngronisearre mei klokken dy't ta in oar domein hearre.
flaggen - Dit fjild befettet ferskate flaggen om de status fan it berjocht te identifisearjen.
korreksjefjild - befettet de fertragingstiid yn nanosekonden. De fertragingstiid omfettet de fertraging by it útstjoeren troch de transparante klok, lykas ek de fertraging by it útstjoeren troch it kanaal by it brûken fan Peer-to-Peer-modus.
sourcePortIdentity – dit fjild befettet ynformaasje oer hokker poarte dit berjocht oarspronklik ferstjoerd is.
sequenceID - befettet in identifikaasjenûmer foar yndividuele berjochten.
controlField - artefaktfjild =) It bliuwt fan 'e earste ferzje fan' e standert en befettet ynformaasje oer it type fan dit berjocht. Yn wêzen itselde as messageType, mar mei minder opsjes.
logMessageInterval - dit fjild wurdt bepaald troch it berjochttype.
Body
Lykas hjirboppe besprutsen, binne d'r ferskate soarten berjochten. Dizze soarten wurde hjirûnder beskreaun:
Oankundiging berjocht
It berjocht oankundigje wurdt brûkt om oare klokken binnen itselde domein te "ferteljen" oer de parameters. Dit berjocht lit jo in Master Clock - Slave Clock hierargy ynstelle.
Berjocht syngronisearje
It Sync-berjocht wurdt ferstjoerd troch de masterklok en befettet de tiid fan 'e masterklok op it momint dat it Sync-berjocht waard oanmakke. As de masterklok twa-poadium is, dan sil it tiidstempel yn it Sync-berjocht op 0 ynsteld wurde, en it hjoeddeistige tiidstempel wurdt stjoerd yn it assosjearre Follow_Up-berjocht. It Sync-berjocht wurdt brûkt foar beide latency-mjittingsmeganismen.
It berjocht wurdt ferstjoerd mei Multicast. Opsjoneel kinne jo Unicast brûke.
Delay_Req berjocht
It formaat fan it Delay_Req-berjocht is identyk oan it Sync-berjocht. De slaveklok stjoert Delay_Req. It befettet de tiid dat de Delay_Req waard stjoerd troch de slaveklok. Dit berjocht wurdt allinnich brûkt foar it fertraging fersyk-antwurd meganisme.
It berjocht wurdt ferstjoerd mei Multicast. Opsjoneel kinne jo Unicast brûke.
Follow_Up berjocht
It Follow_Up-berjocht wurdt opsjoneel ferstjoerd troch de masterklok en befettet de tiid fan ferstjoeren Syngronisearje berjochten master. Allinich twa-poadium masterklokken stjoere it Follow_Up-berjocht.
It Follow_Up-berjocht wurdt brûkt foar beide latency-mjittingsmeganismen.
It berjocht wurdt ferstjoerd mei Multicast. Opsjoneel kinne jo Unicast brûke.
Delay_Resp berjocht
It Delay_Resp-berjocht wurdt ferstjoerd troch de masterklok. It befettet de tiid doe't de Delay_Req waard ûntfongen troch de masterklok. Dit berjocht wurdt allinnich brûkt foar it fertraging fersyk-antwurd meganisme.
It berjocht wurdt ferstjoerd mei Multicast. Opsjoneel kinne jo Unicast brûke.
Pdelay_Req berjocht
It berjocht Pdelay_Req wurdt ferstjoerd troch in apparaat dat in fertraging freget. It befettet de tiid dat it berjocht ferstjoerd is fan 'e haven fan dit apparaat. Pdelay_Req wurdt allinnich brûkt foar it mjittingsmeganisme foar buorfertraging.
Pdelay_Resp berjocht
It Pdelay_Resp-berjocht wurdt ferstjoerd troch in apparaat dat in fertragingsfersyk ûntfongen hat. It befettet de tiid dat it Pdelay_Req-berjocht troch dit apparaat ûntfongen is. It berjocht Pdelay_Resp wurdt allinich brûkt foar it mjittingsmeganisme foar buorfertraging.
Berjocht Pdelay_Resp_Follow_Up
It berjocht Pdelay_Resp_Follow_Up wurdt opsjoneel stjoerd troch it apparaat dat it fertragingsfersyk ûntfongen hat. It befettet de tiid dat it Pdelay_Req-berjocht troch dit apparaat ûntfongen is. It berjocht Pdelay_Resp_Follow_Up wurdt allinich ferstjoerd troch twa-poadium masterklokken.
Dit berjocht kin ek brûkt wurde foar útfieringstiid ynstee fan in tiidstempel. Utfiertiid is de tiid fanôf it momint dat Pdelay-Req ûntfongen is oant Pdelay_Resp wurdt ferstjoerd.
Pdelay_Resp_Follow_Up wurde allinich brûkt foar it mjittingsmeganisme foar buorfertraging.
Management Berjochten
PTP-kontrôleberjochten binne ferplicht om ynformaasje oer te bringen tusken ien of mear klokken en it kontrôleknooppunt.
Werom nei LV
In PTP-berjocht kin op twa nivo's ferstjoerd wurde:
- Netwurk - as ûnderdiel fan IP-gegevens.
- Kanaal - as ûnderdiel fan in Ethernet frame.
PTP-berjocht oerdracht oer UDP oer IP oer Ethernet
PTP oer UDP oer Ethernet
Profilen
PTP hat nochal in protte fleksibele parameters dy't moatte wurde konfigureare. Bygelyks:
- BMCA opsjes.
- Latency mjitting meganisme.
- Yntervallen en begjinwearden fan alle ynstelbere parameters, ensfh.
En nettsjinsteande it feit dat wy earder sein hawwe dat PTPv2-apparaten kompatibel binne mei elkoar, dit is net wier. Apparaten moatte deselde ynstellings hawwe om te kommunisearjen.
Dêrom binne der saneamde PTPv2-profilen. Profilen binne groepen fan ynstelde ynstellings en definieare protokolbeperkingen sadat tiidsyngronisaasje kin wurde ymplementearre foar in spesifike applikaasje.
De IEEE 1588v2 standert sels beskriuwt mar ien profyl - "Standert profyl". Alle oare profilen wurde makke en beskreaun troch ferskate organisaasjes en ferienings.
Bygelyks, it Power Profile, of PTPv2 Power Profile, waard makke troch de Power Systems Relaying Committee en de Substation Committee fan de IEEE Power and Energy Society. It profyl sels hjit IEEE C37.238-2011.
It profyl beskriuwt dat PTP kin wurde oerdroegen:
- Allinnich fia L2 netwurken (d.w.s. Ethernet, HSR, PRP, non-IP).
- Berjochten wurde allinich ferstjoerd troch Multicast-útstjoering.
- Peer-fertragingsmjittingsmeganisme wurdt brûkt as in fertragingsmjittingsmeganisme.
Standert domein is 0, oanrikkemandearre domein is 93.
De ûntwerpfilosofy fan C37.238-2011 wie om it oantal opsjonele funksjes te ferminderjen en allinich de nedige funksjes te behâlden foar betroubere ynteraksje tusken apparaten en ferhege systeemstabiliteit.
Ek wurdt de frekwinsje fan berjochtoerdracht bepaald:
Eins is mar ien parameter beskikber foar seleksje - it type masterklok (single-stage of two-stage).
De krektens moat net mear wêze as 1 μs. Mei oare wurden, ien syngronisaasje paad kin befetsje maksimaal 15 transparante klokken of trije grins klokken.
Boarne: www.habr.com