Enkonduko
La koncepto konstrui "Ciferecan Substacion" en la elektra energiindustrio postulas sinkronigon kun precizeco de 1 μs. Financaj transakcioj ankaŭ postulas mikrosekundan precizecon. En ĉi tiuj aplikoj, NTP-tempa precizeco ne plu sufiĉas.
La PTPv2-sinkroniga protokolo, priskribita per la IEEE 1588v2 normo, permesas sinkronigan precizecon de pluraj dekoj da nanosekundoj. PTPv2 permesas vin sendi sinkronigajn pakaĵojn tra L2 kaj L3-retoj.
La ĉefaj areoj kie PTPv2 estas uzata estas:
- energio;
- ekipaĵo de kontrolo kaj mezurado;
- milit-industria komplekso;
- telekomunikado;
- financa sektoro.
Ĉi tiu afiŝo klarigas kiel funkcias la sinkroniga protokolo PTPv2.
Ni havas pli da sperto en industrio kaj ofte vidas ĉi tiun protokolon en energiaj aplikoj. Sekve, ni faros la revizion singarde .
Kial ĝi estas necesa?
Nuntempe, STO 34.01-21-004-2019 de PJSC Rosseti kaj STO 56947007-29.240.10.302-2020 de PJSC FGC UES enhavas postulojn por organizi procezan buson kun tempa sinkronigo per PTPv2.
Ĉi tio estas pro la fakto, ke relajsaj protektaj terminaloj kaj mezuraj aparatoj estas konektitaj al la proceza buso, kiuj transdonas tujajn kurentajn kaj tensiajn valorojn per la proceza buso, uzante tiel nomatajn SV-riveretojn (multicast-riveretoj).
Relajsaj protektoterminaloj uzas ĉi tiujn valorojn por efektivigi golfan protekton. Se la precizeco de tempomezuradoj estas malgranda, tiam iuj protektoj povas funkcii malvere.
Ekzemple, defendoj de absoluta selektiveco povas iĝi viktimo de "malforta" temposinkronigado. Ofte la logiko de tiaj defendoj baziĝas sur komparo de du kvantoj. Se la valoroj diverĝas je sufiĉe granda valoro, la protekto estas ekigita. Se ĉi tiuj valoroj estas mezuritaj kun tempoprecizeco de 1 ms, tiam vi povas akiri grandan diferencon kie la valoroj estas fakte normalaj se mezuritaj kun precizeco de 1 μs.
PTP-versioj
La PTP-protokolo estis origine priskribita en 2002 en la normo IEEE 1588-2002 kaj estis nomita "Normo por Preciza Horloĝa Sinkroniga Protokolo por Interreta Mezurado kaj Kontrolaj Sistemoj." En 2008, la ĝisdatigita IEEE 1588-2008 normo estis publikigita, kiu priskribas PTP Version 2. Tiu versio de la protokolo plibonigis precizecon kaj stabilecon, sed ne konservis malantaŭan kongruecon kun la unua versio de la protokolo. Ankaŭ, en 2019, versio de la IEEE 1588-2019 normo estis publikigita, priskribante PTP v2.1. Ĉi tiu versio aldonas negravajn plibonigojn al PTPv2 kaj estas malantaŭen kongrua kun PTPv2.
Alivorte, ni havas la sekvan bildon kun versioj:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
-
Nekongrua
Nekongrua
PTPv2 (IEEE 1588-2008)
Nekongrua
-
Kongrua
PTPv2.1 (IEEE 1588-2019)
Nekongrua
Kongrua
-
Sed, kiel ĉiam, estas nuancoj.
Nekongruo inter PTPv1 kaj PTPv2 signifas ke PTPv1-ebligita aparato ne povos sinkronigi kun preciza horloĝo funkcianta sur PTPv2. Ili uzas malsamajn mesaĝformatojn por sinkronigi.
Sed ankoraŭ eblas kombini aparatojn kun PTPv1 kaj aparatojn kun PTPv2 en la sama reto. Por atingi ĉi tion, iuj fabrikantoj permesas elekti la protokolan version sur la randaj horloĝaj havenoj. Tio estas, limhorloĝo povas sinkronigi uzante PTPv2 kaj daŭre sinkronigi aliajn horloĝojn ligitajn al ĝi uzante kaj PTPv1 kaj PTPv2.
PTP-aparatoj. Kio ili estas kaj kiel ili estas malsamaj?
La IEEE 1588v2 normo priskribas plurajn specojn de aparatoj. Ĉiuj ili estas montritaj en la tabelo.
La aparatoj komunikas inter si per LAN uzante PTP.
PTP-aparatoj nomiĝas horloĝoj. Ĉiuj horloĝoj prenas la ĝustan tempon de la grandmajstra horloĝo.
Estas 5 specoj de horloĝoj:
Grandmajstra horloĝo
La ĉefa fonto de preciza tempo. Ofte ekipita per interfaco por konekti GPS.
Ordinara Horloĝo
Ununura havena aparato kiu povas esti majstro (majstra horloĝo) aŭ sklavo (sklava horloĝo)
Majstra horloĝo (majstro)
Ili estas la fonto de la preciza tempo de kiu aliaj horloĝoj estas sinkronigitaj
Sklava horloĝo
Fina aparato, kiu estas sinkronigita de la majstra horloĝo
Lima Horloĝo
Aparato kun pluraj havenoj, kiuj povas esti majstro aŭ sklavo.
Tio estas, tiuj horloĝoj povas sinkronigi de la supera majstra horloĝo kaj sinkronigi la malsuperajn sklavhorloĝojn.
Fin-al-fina Travidebla Horloĝo
Aparato kun pluraj havenoj, kiu estas nek majstra horloĝo nek sklavo. Ĝi transdonas PTP-datumojn inter du horloĝoj.
Dum transdono de datumoj, la travidebla horloĝo korektas ĉiujn PTP-mesaĝojn.
La korekto okazas aldonante la prokrastan tempon sur ĉi tiu aparato al la korekta kampo en la kaplinio de la elsendita mesaĝo.
Peer-to-Peer Travidebla Horloĝo
Aparato kun pluraj havenoj, kiu estas nek majstra horloĝo nek sklavo.
Ĝi transdonas PTP-datumojn inter du horloĝoj.
Dum transdono de datumoj, la travidebla horloĝo korektas ĉiujn PTP-mesaĝojn Sync kaj Follow_Up (pli pri ili sube).
La korekto estas atingita aldonante al la korekta kampo de la elsendita pakaĵeto la malfruon sur la elsenda aparato kaj la malfruon sur la datumtransdona kanalo.
Administra Nodo
Aparato kiu agordas kaj diagnozas aliajn horloĝojn
Majstraj kaj sklavaj horloĝoj estas sinkronigitaj per tempomarkoj en PTP-mesaĝoj. Estas du specoj de mesaĝoj en la PTP-protokolo:
- Okazaĵaj Mesaĝoj estas sinkronigitaj mesaĝoj kiuj implikas generi tempomarkon en la tempo kiam la mesaĝo estas sendita kaj en la tempo kiam ĝi estas ricevita.
- Ĝeneralaj Mesaĝoj - Ĉi tiuj mesaĝoj ne postulas tempomarkojn, sed povas enhavi tempomarkojn por rilataj mesaĝoj
Eventaj Mesaĝoj
Ĝeneralaj Mesaĝoj
sync
Malfruo_Peto
Pdelay_Req
Pdelay_Resp
Anoncu
Sekvu
Malfruo_Resp
Pdelay_Resp_Follow_Up
demarŝo
Signaligo
Ĉiuj specoj de mesaĝoj estos diskutitaj pli detale sube.
Bazaj problemoj de sinkronigado
Kiam sinkroniga pakaĵeto estas elsendita tra loka reto, ĝi estas prokrastita ĉe la ŝaltilo kaj en la datenligo. Ajna ŝaltilo produktos prokraston de ĉirkaŭ 10 mikrosekundoj, kio estas neakceptebla por PTPv2. Post ĉio, ni devas atingi precizecon de 1 μs sur la fina aparato. (Ĉi tio estas se ni parolas pri energio. Aliaj aplikoj povas postuli pli grandan precizecon.)
IEEE 1588v2 priskribas plurajn funkciajn algoritmojn, kiuj permesas vin registri la tempoprokraston kaj korekti ĝin.
Algoritmo de laboro
Dum normala operacio, la protokolo funkcias en du fazoj.
- Fazo 1 - establante la "Majstra Horloĝo - Sklava Horloĝo" hierarkion.
- Fazo 2 - horloĝsinkronigado uzanta Fin-al-finon aŭ Peer-to-Peer-mekanismon.
Fazo 1 - Establado de la Majstro-Sklavo-Hierarkio
Ĉiu haveno de regula aŭ randhorloĝo havas certan nombron da ŝtatoj (sklava horloĝo kaj majstra horloĝo). La normo priskribas la transiralgoritmon inter ĉi tiuj statoj. En programado, tia algoritmo estas nomita finhava ŝtatmaŝino aŭ ŝtatmaŝino (pli da detaloj en Vikio).
Ĉi tiu ŝtata maŝino uzas la Plej Bonan Majstran Horloĝan Algoritmon (BMCA) por agordi la majstron kiam li konektas du horloĝojn.
Ĉi tiu algoritmo permesas al la horloĝo transpreni la respondecojn de la grandmajstra horloĝo kiam la kontraŭflua grandmajstra horloĝo perdas GPS-signalon, malkonektas ktp.
Ŝtataj transiroj laŭ la BMCA estas resumitaj en la sekva diagramo:
Informoj pri la horloĝo ĉe la alia fino de la "drato" estas senditaj en speciala mesaĝo (Anoncu mesaĝon). Post kiam ĉi tiuj informoj estas ricevitaj, la ŝtatmaŝino-algoritmo funkcias kaj komparo estas farita por vidi kiu horloĝo estas pli bona. La haveno sur la plej bona horloĝo fariĝas la majstra horloĝo.
Simpla hierarkio estas montrita en la diagramo malsupre. Padoj 1, 2, 3, 4, 5 povas enhavi Travideblan horloĝon, sed ili ne partoprenas en establado de la Master Clock - Slave Clock-hierarkio.
Fazo 2 - Sinkronigi regulajn kaj randajn horloĝojn
Tuj post establado de la "Mastra Horloĝo - Sklava Horloĝo" hierarkio, komenciĝas la sinkroniga fazo de regulaj kaj limhorloĝoj.
Por sinkronigi, la majstra horloĝo sendas mesaĝon enhavantan tempomarkon al la sklavhorloĝoj.
La majstra horloĝo povas esti:
- ununura etapo;
- duetapa.
Unuetapaj horloĝoj sendas unu Sync-mesaĝon por sinkronigi.
Duetapa horloĝo uzas du mesaĝojn por sinkronigado - Sync kaj Follow_Up.
Du mekanismoj povas esti uzitaj por la sinkronigfazo:
- Prokrasta peto-responda mekanismo.
- Peer prokrasta mezurmekanismo.
Unue, ni rigardu ĉi tiujn mekanismojn en la plej simpla kazo - kiam travideblaj horloĝoj ne estas uzataj.
Prokrasta peto-responda mekanismo
La mekanismo implikas du paŝojn:
- Mezuri la prokraston en elsendado de mesaĝo inter la majstra horloĝo kaj la sklava horloĝo. Farita per prokrasta peto-responda mekanismo.
- Korekto de la ĝusta tempoŝanĝo estas farita.
Mezurado de latencia
t1 - Tempo sendi la Sync-mesaĝon per la majstra horloĝo; t2 – Tempo de ricevo de la Sync-mesaĝo per la sklava horloĝo; t3 - Tempo de sendado de la prokrasta peto (Delay_Req) per la sklava horloĝo; t4 - Delay_Req ricevtempo de la majstra horloĝo.
Kiam la sklava horloĝo konas la tempojn t1, t2, t3 kaj t4, ĝi povas kalkuli la averaĝan prokraston dum elsendado de la sinkroniga mesaĝo (tmpd). Ĝi estas kalkulita jene:
Kiam oni transdonas mesaĝon Sync kaj Follow_Up, la tempoprokrasto de la majstro ĝis la sklavo estas kalkulita - t-ms.
Kiam oni transdonas mesaĝojn Delay_Req kaj Delay_Resp, la tempoprokrasto de la sklavo ĝis la majstro estas kalkulita - t-sm.
Se iu malsimetrio okazas inter ĉi tiuj du valoroj, tiam aperas eraro en korektado de la devio de la ĝusta tempo. La eraro estas kaŭzita de la fakto, ke la kalkulita prokrasto estas la mezumo de la t-ms kaj t-sm prokrastoj. Se la prokrastoj ne egalas unu al la alia, tiam ni ne ĝustigos la tempon precize.
Korekto de tempoŝanĝo
Post kiam la prokrasto inter la majstra horloĝo kaj la sklavhorloĝo estas konata, la sklavhorloĝo elfaras tempoĝustigon.
Sklavaj horloĝoj uzas la Sync-mesaĝon kaj laŭvolan Follow_Up-mesaĝon por kalkuli la precizan tempan ofseton dum elsendado de pakaĵeto de la majstro al la sklavaj horloĝoj. La movo estas kalkulita per la sekva formulo:
Peer prokrasta mezurmekanismo
Ĉi tiu mekanismo ankaŭ uzas du ŝtupojn por sinkronigado:
- La aparatoj mezuras la tempoprokraston al ĉiuj najbaroj tra ĉiuj havenoj. Por fari tion ili uzas kunulan prokrastan mekanismon.
- Korekto de la ĝusta tempoŝanĝo.
Mezuri latentecon inter aparatoj, kiuj subtenas kunulan reĝimon
La latenteco inter havenoj subtenantaj la kunul-al-kunulan mekanismon estas mezurita uzante la sekvajn mesaĝojn:
Kiam haveno 1 konas la tempojn t1, t2, t3 kaj t4, ĝi povas kalkuli la averaĝan prokraston (tmld). Ĝi estas kalkulita per la sekva formulo:
La haveno tiam uzas ĉi tiun valoron kiam kalkulas la alĝustigkampon por ĉiu Sync-mesaĝo aŭ laŭvola Follow_Up-mesaĝo kiu pasas tra la aparato.
La totala prokrasto estos egala al la sumo de la prokrasto dum transsendo per ĉi tiu aparato, la averaĝa prokrasto dum transsendo tra la datumkanalo kaj la prokrasto jam enhavita en ĉi tiu mesaĝo, ebligita sur kontraŭfluaj aparatoj.
Mesaĝoj Pdelay_Req, Pdelay_Resp kaj laŭvola Pdelay_Resp_Follow_Up permesas ricevi la prokraston de majstro al sklavo kaj de sklavo al majstro (cirkla).
Ajna malsimetrio inter ĉi tiuj du valoroj enkondukos eraron pri korekta eraro de tempo-offset.
Ĝustigante la ĝustan tempoŝanĝon
Sklavaj horloĝoj uzas Sync-mesaĝon kaj laŭvolan Follow_Up-mesaĝon por kalkuli la precizan tempan ofseton dum elsendado de pakaĵeto de la majstro ĝis la sklavaj horloĝoj. La movo estas kalkulita per la sekva formulo:
Avantaĝoj alĝustigo de la samulo-al-kunula mekanismo - la tempoprokrasto de ĉiu Sync aŭ Follow_Up-mesaĝo estas kalkulita kiel ĝi estas elsendita en la reto. Sekve, ŝanĝi la dissendvojon neniel influos la precizecon de la alĝustigo.
Dum uzado de tiu mekanismo, temposinkronigado ne postulas kalkuli la tempoprokraston laŭ la pado krucita per la sinkroniga pakaĵeto, kiel estas farita en la baza interŝanĝo. Tiuj. Delay_Req kaj Delay_Resp mesaĝoj ne estas senditaj. En ĉi tiu metodo, la prokrasto inter la majstraj kaj sklavaj horloĝoj estas simple sumigita en la alĝustigkampo de ĉiu Sync aŭ Follow_Up-mesaĝo.
Alia avantaĝo estas ke la majstra horloĝo estas malŝarĝita de la bezono prilabori Delay_Req mesaĝojn.
Funkciaj reĝimoj de travideblaj horloĝoj
Sekve, ĉi tiuj estis simplaj ekzemploj. Nun supozu, ke ŝaltiloj aperas sur la sinkroniga vojo.
Se vi uzas ŝaltilojn sen subteno de PTPv2, la sinkroniga pako estos prokrastita sur la ŝaltilo je proksimume 10 μs.
Ŝaltiloj kiuj subtenas PTPv2 estas nomitaj Travideblaj horloĝoj en IEEE 1588v2 terminologio. Travideblaj horloĝoj ne estas sinkronigitaj de la majstra horloĝo kaj ne partoprenas en la "Mastra Horloĝo - Sklava Horloĝo" hierarkio, sed dum transdonado de sinkronigaj mesaĝoj ili memoras kiom longe la mesaĝo estis prokrastita de ili. Ĉi tio ebligas al vi ĝustigi la tempoprokraston.
Travideblaj horloĝoj povas funkcii en du reĝimoj:
- Fin-al-Fino.
- Samtavola.
Fin-al-fino (E2E)
La travidebla horloĝo E2E elsendas Sync-mesaĝojn kaj akompanajn Follow_Up-mesaĝojn en ĉiuj havenoj. Eĉ tiuj, kiuj estas blokitaj de iuj protokoloj (ekzemple, RSTP).
La ŝaltilo memoras la tempomarkon kiam Sync-pako (Follow_Up) estis ricevita sur la haveno kaj kiam ĝi estis sendita de la haveno. Surbaze de ĉi tiuj du tempomarkoj, la tempo necesa por la ŝaltilo por procesi la mesaĝon estas kalkulita. En la normo, ĉi tiu tempo estas nomita loĝtempo.
La pretigtempo estas aldonita al la korekta kampo de la mesaĝo Sync (unupaŝa horloĝo) aŭ Follow_Up (dupaŝa horloĝo).
La travidebla horloĝo E2E mezuras la pretigtempon por Sync kaj Delay_Req mesaĝoj pasantaj tra la ŝaltilo. Sed gravas kompreni, ke la tempoprokrasto inter la majstra horloĝo kaj la sklava horloĝo estas kalkulita per la prokrasta peto-responda mekanismo. Se la majstra horloĝo ŝanĝiĝas aŭ la vojo de la majstra horloĝo al la sklava horloĝo ŝanĝiĝas, la prokrasto estas mezurita denove. Ĉi tio pliigas la transiran tempon en kazo de retaj ŝanĝoj.
La travidebla horloĝo P2P, krom mezuri la tempon necesan por ŝaltilo por prilabori mesaĝon, mezuras la prokraston sur la datumligo al sia plej proksima najbaro uzante najbaran latentmekanismon.
Latenteco estas mezurita sur ĉiu ligo en ambaŭ direktoj, inkluzive de ligiloj kiuj estas blokitaj per iu protokolo (kiel ekzemple RSTP). Ĉi tio ebligas al vi tuj kalkuli la novan prokraston en la sinkroniga vojo se la grandmajstra horloĝo aŭ retotopologio ŝanĝiĝas.
Tempo de traktado de mesaĝoj per ŝaltiloj kaj latenteco akumuliĝas dum sendado de mesaĝoj de Sync aŭ Follow_Up.
Tipoj de PTPv2-subteno per ŝaltiloj
Ŝaltiloj povas subteni PTPv2:
- programe;
- aparataro.
Dum efektivigado de la PTPv2 protokolo en programaro, la ŝaltilo petas tempomarkon de la firmvaro. La problemo estas, ke la firmvaro funkcias cikle, kaj vi devos atendi ĝis ĝi finos la nunan ciklon, prenas la peton por prilaborado kaj eldonas tempomarkon post la sekva ciklo. Ĉi tio ankaŭ prenos tempon, kaj ni ricevos prokraston, kvankam ne tiel signifa kiel sen programara subteno por PTPv2.
Nur aparatara subteno por PTPv2 permesas vin konservi la bezonatan precizecon. En ĉi tiu kazo, la tempomarko estas eldonita de speciala ASIC, kiu estas instalita sur la haveno.
Mesaĝa Formato
Ĉiuj PTP-mesaĝoj konsistas el la sekvaj kampoj:
- Kapo - 34 bajtoj.
- Korpo - grandeco dependas de la speco de mesaĝo.
- Sufikso estas laŭvola.
Kaplinio
La Kapokampo estas la sama por ĉiuj PTP-mesaĝoj. Ĝia grandeco estas 34 bajtoj.
Formato de kaplinio:
mesaĝoTipo – enhavas la specon de mesaĝo estanta elsendita, ekzemple Sync, Delay_Req, PDelay_Req, ktp.
mesaĝlongo – enhavas la plenan grandecon de la PTP-mesaĝo, inkluzive de kaplinio, korpo kaj sufikso (sed ekskludante remburajn bajtojn).
domajnoNumero – determinas al kiu PTP-domajno apartenas la mesaĝo.
Demando - ĉi tiuj estas pluraj malsamaj horloĝoj kolektitaj en unu logika grupo kaj sinkronigitaj de unu majstra horloĝo, sed ne nepre sinkronigitaj kun horloĝoj apartenantaj al malsama domajno.
flagoj – Ĉi tiu kampo enhavas diversajn flagojn por identigi la staton de la mesaĝo.
korekta kampo – enhavas la prokrastan tempon en nanosekundoj. La prokrastotempo inkluzivas la prokraston kiam oni transdonas tra la travidebla horloĝo, same kiel la prokraston kiam oni transdonas tra la kanalo kiam oni uzas Peer-to-Peer-reĝimon.
sourcePortIdentity – ĉi tiu kampo enhavas informojn pri kiu haveno ĉi tiu mesaĝo estis origine sendita.
sekvencoID – enhavas identigan numeron por individuaj mesaĝoj.
controlField – artefakto kampo =) Ĝi restas de la unua versio de la normo kaj enhavas informojn pri la tipo de ĉi tiu mesaĝo. Esence sama kiel messageType, sed kun malpli da ebloj.
logMessageInterval – ĉi tiu kampo estas determinita de la mesaĝo-tipo.
korpo
Kiel diskutite supre, ekzistas pluraj specoj de mesaĝoj. Ĉi tiuj tipoj estas priskribitaj malsupre:
Anonca mesaĝo
La Anoncu-mesaĝo estas uzata por "rakonti" aliajn horloĝojn ene de la sama domajno pri ĝiaj parametroj. Ĉi tiu mesaĝo ebligas al vi agordi hierarkion de Majstra Horloĝo - Sklava Horloĝo.
Mesaĝo Sinkronigi
La Sync-mesaĝo estas sendita de la majstra horloĝo kaj enhavas la tempon de la majstra horloĝo en la tempo kiam la Sync-mesaĝo estis generita. Se la majstra horloĝo estas duetapa, tiam la tempomarko en la Sync-mesaĝo estos agordita al 0, kaj la nuna tempomarko estos sendita en la rilata Follow_Up-mesaĝo. La Sync-mesaĝo estas uzata por ambaŭ lattempaj mezurmekanismoj.
La mesaĝo estas elsendita uzante Multicast. Laŭvole vi povas uzi Unicast.
Delay_Req-mesaĝo
La formato de la Delay_Req-mesaĝo estas identa al la Sync-mesaĝo. La sklava horloĝo sendas Delay_Req. Ĝi enhavas la tempon kiam la Delay_Req estis sendita de la sklavhorloĝo. Ĉi tiu mesaĝo estas uzata nur por la mekanismo de prokrasta peto-respondo.
La mesaĝo estas elsendita uzante Multicast. Laŭvole vi povas uzi Unicast.
Mesaĝo Follow_Up
La mesaĝo Follow_Up estas laŭvole sendata de la majstra horloĝo kaj enhavas la tempon de sendo Sinkronigi mesaĝojn majstro. Nur duetapaj majstraj horloĝoj sendas la mesaĝon Follow_Up.
La mesaĝo Follow_Up estas uzata por ambaŭ lattempaj mezurmekanismoj.
La mesaĝo estas elsendita uzante Multicast. Laŭvole vi povas uzi Unicast.
Delay_Resp-mesaĝo
La Delay_Resp-mesaĝo estas sendita de la ĉefa horloĝo. Ĝi enhavas la tempon kiam la Delay_Req estis ricevita de la majstra horloĝo. Ĉi tiu mesaĝo estas uzata nur por la mekanismo de prokrasta peto-respondo.
La mesaĝo estas elsendita uzante Multicast. Laŭvole vi povas uzi Unicast.
Pdelay_Req-mesaĝo
La mesaĝo Pdelay_Req estas sendita de aparato, kiu petas prokraston. Ĝi enhavas la tempon, kiam la mesaĝo estis sendita de la haveno de ĉi tiu aparato. Pdelay_Req estas uzata nur por la najbara prokrasta mezurmekanismo.
Pdelay_Resp-mesaĝo
La mesaĝo Pdelay_Resp estas sendita de aparato, kiu ricevis prokrastan peton. Ĝi enhavas la tempon, kiam la mesaĝo Pdelay_Req estis ricevita de ĉi tiu aparato. La Pdelay_Resp-mesaĝo estas uzata nur por la najbara prokrasta mezurmekanismo.
Mesaĝo Pdelay_Resp_Follow_Up
La mesaĝo Pdelay_Resp_Follow_Up estas laŭvole sendita de la aparato, kiu ricevis la prokrastan peton. Ĝi enhavas la tempon, kiam la mesaĝo Pdelay_Req estis ricevita de ĉi tiu aparato. La mesaĝo Pdelay_Resp_Follow_Up estas sendita nur per duetapaj majstraj horloĝoj.
Ĉi tiu mesaĝo ankaŭ povas esti uzata por ekzekuttempo anstataŭ tempomarko. Ekzekuta tempo estas la tempo ekde la momento kiam Pdelay-Req estas ricevita ĝis Pdelay_Resp estas sendita.
Pdelay_Resp_Follow_Up estas uzataj nur por la najbara prokrasta mezurmekanismo.
Administraj Mesaĝoj
PTP-kontrolmesaĝoj estas postulataj por transdoni informojn inter unu aŭ pluraj horloĝoj kaj la kontrolnodo.
Translokiĝu al LV
PTP-mesaĝo povas esti elsendita sur du niveloj:
- Reto - kiel parto de IP-datumoj.
- Kanalo - kiel parto de Ethernet-kadro.
Transdono de mesaĝoj PTP per UDP per IP per Eterreto
PTP super UDP super Ethernet
Profiloj
PTP havas sufiĉe multajn flekseblajn parametrojn, kiujn oni devas agordi. Ekzemple:
- BMCA-Ebloj.
- Mekanismo de mezurado de latenteco.
- Intervaloj kaj komencaj valoroj de ĉiuj agordeblaj parametroj ktp.
Kaj malgraŭ tio, ke ni antaŭe diris, ke PTPv2-aparatoj estas kongruaj unu kun la alia, tio ne estas vera. Aparatoj devas havi la samajn agordojn por komuniki.
Tial ekzistas tiel nomataj PTPv2-profiloj. Profiloj estas grupoj de agorditaj agordoj kaj difinitaj protokollimigoj tiel ke temposinkronigado povas esti efektivigita por specifa aplikaĵo.
La normo IEEE 1588v2 mem priskribas nur unu profilon - "Defaŭlta Profilo". Ĉiuj aliaj profiloj estas kreitaj kaj priskribitaj de diversaj organizoj kaj asocioj.
Ekzemple, la Potenco-Profilo, aŭ PTPv2 Potenco-Profilo, estis kreita fare de la Potenco-Sistemoj Relajada Komitato kaj la Substacia Komitato de la IEEE Potenco kaj Energio-Socio. La profilo mem nomiĝas IEEE C37.238-2011.
La profilo priskribas, ke PTP povas esti translokigita:
- Nur per L2-retoj (t.e. Eterreto, HSR, PRP, ne-IP).
- Mesaĝoj estas elsenditaj nur per Multicast-elsendo.
- Sama prokrasta mezurmekanismo estas utiligita kiel prokrasta mezurmekanismo.
Defaŭlta domajno estas 0, rekomendita domajno estas 93.
La dezajna filozofio de C37.238-2011 estis redukti la nombron da laŭvolaj funkcioj kaj konservi nur la necesajn funkciojn por fidinda interago inter aparatoj kaj pliigita sistema stabileco.
Ankaŭ, la ofteco de mesaĝtranssendo estas determinita:
Fakte, nur unu parametro disponeblas por elekto - la tipo de majstra horloĝo (unu-ŝtupa aŭ du-ŝtupa).
La precizeco devus esti ne pli ol 1 μs. Alivorte, unu sinkroniga vojo povas enhavi maksimume 15 travideblajn horloĝojn aŭ tri limhorloĝojn.
fonto: www.habr.com