Detajet e zbatimit të protokollit të sinkronizimit të kohës PTPv2

Paraqitje

Koncepti i ndërtimit të një “Nënstacioni Dixhital” në industrinë e energjisë elektrike kërkon sinkronizim me një saktësi prej 1 μs. Transaksionet financiare kërkojnë gjithashtu saktësi në mikrosekondë. Në këto aplikacione, saktësia e kohës NTP nuk është më e mjaftueshme.

Protokolli i sinkronizimit PTPv2, i përshkruar nga standardi IEEE 1588v2, lejon saktësinë e sinkronizimit prej disa dhjetëra nanosekonda. PTPv2 ju lejon të dërgoni paketa sinkronizimi përmes rrjeteve L2 dhe L3.

Fushat kryesore ku përdoret PTPv2 janë:

• energji;
• pajisjet e kontrollit dhe matjes;
• kompleksi ushtarako-industrial;
• telekomit;
• sektori financiar.

Ky postim shpjegon se si funksionon protokolli i sinkronizimit PTPv2.

Ne kemi më shumë përvojë në industri dhe shpesh e shohim këtë protokoll në aplikimet e energjisë. Prandaj, ne do ta bëjmë rishikimin me kujdes për energjinë.

Pse është e nevojshme?

Për momentin, STO 34.01-21-004-2019 i PJSC Rosseti dhe STO 56947007-29.240.10.302-2020 i PJSC FGC UES përmbajnë kërkesa për organizimin e një autobusi procesi me sinkronizimin e kohës nëpërmjet PTPv2.

Kjo për faktin se terminalet e mbrojtjes rele dhe pajisjet matëse janë të lidhura me autobusin e procesit, të cilët transmetojnë vlera të menjëhershme të rrymës dhe tensionit përmes autobusit të procesit, duke përdorur të ashtuquajturat rryma SV (rryma multicast).

Terminalet e mbrojtjes rele përdorin këto vlera për të zbatuar mbrojtjen e gjirit. Nëse saktësia e matjeve të kohës është e vogël, atëherë disa mbrojtje mund të funksionojnë gabimisht.

Për shembull, mbrojtja e selektivitetit absolut mund të bëhet viktimë e sinkronizimit "të dobët" të kohës. Shpesh logjika e mbrojtjeve të tilla bazohet në një krahasim të dy sasive. Nëse vlerat ndryshojnë me një vlerë mjaft të madhe, atëherë aktivizohet mbrojtja. Nëse këto vlera maten me një saktësi kohore prej 1 ms, atëherë mund të merrni një ndryshim të madh ku vlerat janë në të vërtetë normale nëse maten me një saktësi prej 1 μs.

Versionet PTP

Protokolli PTP fillimisht u përshkrua në 2002 në standardin IEEE 1588-2002 dhe u quajt "Standard për një Protokoll Sinkronizimi të Orës Precize për Sistemet e Rrjetit të Matjes dhe Kontrollit". Në vitin 2008, u lëshua standardi i përditësuar IEEE 1588-2008, i cili përshkruan PTP Version 2. Ky version i protokollit përmirësoi saktësinë dhe stabilitetin, por nuk ruajti përputhshmërinë e prapambetur me versionin e parë të protokollit. Gjithashtu, në vitin 2019, u lëshua një version i standardit IEEE 1588-2019, duke përshkruar PTP v2.1. Ky version shton përmirësime të vogla në PTPv2 dhe është i pajtueshëm me PTPv2.

Me fjalë të tjera, ne kemi foton e mëposhtme me versione:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

-
E papajtueshme

E papajtueshme

PTPv2 (IEEE 1588-2008)

E papajtueshme

-
E përputhshme

PTPv2.1 (IEEE 1588-2019)

E papajtueshme

E përputhshme

-

Por, si gjithmonë, ka nuanca.

Papajtueshmëria midis PTPv1 dhe PTPv2 do të thotë që një pajisje e aktivizuar me PTPv1 nuk do të jetë në gjendje të sinkronizohet me një orë të saktë që funksionon në PTPv2. Ata përdorin formate të ndryshme mesazhesh për t'u sinkronizuar.

Por është ende e mundur të kombinohen pajisjet me PTPv1 dhe pajisjet me PTPv2 në të njëjtin rrjet. Për ta arritur këtë, disa prodhues ju lejojnë të zgjidhni versionin e protokollit në portat e orës së skajit. Kjo do të thotë, një orë kufitare mund të sinkronizohet duke përdorur PTPv2 dhe ende të sinkronizojë orët e tjera të lidhura me të duke përdorur si PTPv1 ashtu edhe PTPv2.

Pajisjet PTP. Cilat janë ato dhe si ndryshojnë?

Standardi IEEE 1588v2 përshkruan disa lloje pajisjesh. Të gjitha ato janë paraqitur në tabelë.

Pajisjet komunikojnë me njëra-tjetrën përmes një LAN duke përdorur PTP.

Pajisjet PTP quhen orë. Të gjitha orët marrin kohën e saktë nga ora e mjeshtrit.

Ekzistojnë 5 lloje të orëve:

Ora mjeshtër i madh

Burimi kryesor i kohës së saktë. Shpesh i pajisur me një ndërfaqe për lidhjen e GPS.

Ora e zakonshme

Një pajisje me portë të vetme që mund të jetë një master (ora kryesore) ose skllav (ora skllav)

Ora kryesore (master)

Ato janë burimi i kohës së saktë me të cilën sinkronizohen orët e tjera

Ora skllav

Fundi i pajisjes që sinkronizohet nga ora kryesore

Ora kufitare

Një pajisje me porte të shumta që mund të jetë një master ose një skllav.

Kjo do të thotë, këto orë mund të sinkronizohen nga ora kryesore kryesore dhe të sinkronizojnë orët skllav inferiore.

Orë transparente nga fundi në fund

Një pajisje me porte të shumta që nuk është as një orë kryesore dhe as një skllav. Ai transmeton të dhëna PTP midis dy orëve.

Kur transmetoni të dhëna, ora transparente korrigjon të gjitha mesazhet PTP.

Korrigjimi ndodh duke shtuar kohën e vonesës në këtë pajisje në fushën e korrigjimit në kokën e mesazhit të transmetuar.

Orë transparente nga kolegët

Një pajisje me porte të shumta që nuk është as një orë kryesore dhe as një skllav.
Ai transmeton të dhëna PTP midis dy orëve.

Kur transmeton të dhëna, ora transparente korrigjon të gjitha mesazhet PTP Sync dhe Follow_Up (më shumë rreth tyre më poshtë).

Korrigjimi arrihet duke shtuar në fushën e korrigjimit të paketës së transmetuar vonesën në pajisjen transmetuese dhe vonesën në kanalin e transmetimit të të dhënave.

Nyja e menaxhimit

Një pajisje që konfiguron dhe diagnostikon orët e tjera

Orët kryesore dhe skllav sinkronizohen duke përdorur vulat kohore në mesazhet PTP. Ekzistojnë dy lloje mesazhesh në protokollin PTP:

• Mesazhet e ngjarjeve janë mesazhe të sinkronizuara që përfshijnë gjenerimin e një vule kohore në kohën kur mesazhi dërgohet dhe në momentin kur ai merret.
• Mesazhet e Përgjithshme - Këto mesazhe nuk kërkojnë vula kohore, por mund të përmbajnë vula kohore për mesazhet përkatëse

Mesazhet e ngjarjeve

Mesazhe të Përgjithshme

Sync
Vonesa_Kërkesa
Pdelay_Req
Pdelay_Resp

shpall
Ndiqe
Vonesa_Resp
Pdelay_Resp_Follow_Up
drejtuesit
sinjalizuar

Të gjitha llojet e mesazheve do të diskutohen më në detaje më poshtë.

Problemet bazë të sinkronizimit

Kur një paketë sinkronizimi transmetohet përmes një rrjeti lokal, ajo vonohet në ndërprerës dhe në lidhjen e të dhënave. Çdo ndërprerës do të prodhojë një vonesë prej rreth 10 mikrosekonda, e cila është e papranueshme për PTPv2. Në fund të fundit, duhet të arrijmë një saktësi prej 1 μs në pajisjen përfundimtare. (Kjo është nëse po flasim për energjinë. Aplikacionet e tjera mund të kërkojnë saktësi më të madhe.)

IEEE 1588v2 përshkruan disa algoritme funksionimi që ju lejojnë të regjistroni vonesën kohore dhe ta korrigjoni atë.

Algoritmi i punës
Gjatë funksionimit normal, protokolli funksionon në dy faza.

• Faza 1 - krijimi i hierarkisë “Ora kryesore – Ora Slave”.
• Faza 2 - sinkronizimi i orës duke përdorur një mekanizëm End-to-End ose Peer-to-Peer.

Faza 1 - Krijimi i Hierarkisë Master-Skllav

Çdo port i një ore të rregullt ose të skajshme ka një numër të caktuar gjendjesh (ora skllav dhe ora master). Standardi përshkruan algoritmin e tranzicionit ndërmjet këtyre gjendjeve. Në programim, një algoritëm i tillë quhet makinë me gjendje të fundme ose makinë gjendjeje (më shumë detaje në Wiki).

Kjo makinë e gjendjes përdor Algoritmin e Orës më të Mirë Master (BMCA) për të vendosur masterin kur lidh dy orë.

Ky algoritëm lejon që ora të marrë përsipër përgjegjësitë e orës së mjeshtrit të madh kur ora e mjeshtrit në rrjedhën e sipërme humbet sinjalin GPS, del jashtë linje, etj.

Tranzicionet e gjendjes sipas BMCA janë përmbledhur në diagramin e mëposhtëm:


Informacioni rreth orës në skajin tjetër të "telit" dërgohet në një mesazh të veçantë (Njoftoni mesazhin). Pasi të merret ky informacion, funksionon algoritmi i makinës së gjendjes dhe bëhet një krahasim për të parë se cila orë është më e mirë. Porta në orën më të mirë bëhet ora kryesore.

Një hierarki e thjeshtë është paraqitur në diagramin më poshtë. Shtigjet 1, 2, 3, 4, 5 mund të përmbajnë një orë transparente, por ato nuk marrin pjesë në vendosjen e hierarkisë së Orës kryesore - Orës Slave.

Faza 2 - Sinkronizoni orët e rregullta dhe ato të skajshme

Menjëherë pas vendosjes së hierarkisë “Master Clock – Ora Slave”, fillon faza e sinkronizimit të orëve të rregullta dhe kufitare.

Për të sinkronizuar, ora kryesore dërgon një mesazh që përmban një vulë kohore në orët skllave.

Ora kryesore mund të jetë:

• një fazë;
• me dy faza.

Orët me një fazë dërgojnë një mesazh Sync për t'u sinkronizuar.

Një orë me dy faza përdor dy mesazhe për sinkronizim - Sync dhe Follow_Up.

Dy mekanizma mund të përdoren për fazën e sinkronizimit:

• Mekanizmi i vonesës së kërkesë-përgjigjes.
• Mekanizmi i matjes së vonesës së kolegëve.

Së pari, le t'i shohim këto mekanizma në rastin më të thjeshtë - kur nuk përdoren orët transparente.

Mekanizmi i vonesës së kërkesë-përgjigjes

Mekanizmi përfshin dy hapa:

1. Matja e vonesës në transmetimin e një mesazhi midis orës kryesore dhe orës skllav. Kryhet duke përdorur një mekanizëm të vonesës së kërkesë-përgjigjes.
2. Është kryer korrigjimi i zhvendosjes së saktë kohore.

Matja e vonesës


t1 – Koha e dërgimit të mesazhit Sync nga ora kryesore; t2 – Koha e marrjes së mesazhit Sync nga ora skllav; t3 – Koha e dërgimit të kërkesës për vonesë (Delay_Req) ​​nga ora skllav; t4 – Koha e pritjes së vonesës_Req nga ora kryesore.

Kur ora skllav njeh kohët t1, t2, t3 dhe t4, mund të llogarisë vonesën mesatare kur transmeton mesazhin e sinkronizimit (tmpd). Ajo llogaritet si më poshtë:

Kur transmetoni një mesazh Sync and Follow_Up, llogaritet vonesa kohore nga master në skllave - t-ms.

Gjatë transmetimit të mesazheve Delay_Req dhe Delay_Resp, llogaritet vonesa kohore nga slave në master - t-sm.

Nëse ndodh ndonjë asimetri midis këtyre dy vlerave, atëherë shfaqet një gabim në korrigjimin e devijimit të kohës së saktë. Gabimi shkaktohet nga fakti se vonesa e llogaritur është mesatarja e vonesave t-ms dhe t-sm. Nëse vonesat nuk janë të barabarta me njëra-tjetrën, atëherë nuk do ta rregullojmë saktë kohën.

Korrigjimi i ndërrimit të kohës

Pasi të dihet vonesa midis orës kryesore dhe orës skllav, ora skllav kryen korrigjimin e kohës.

Orët skllave përdorin mesazhin Sync dhe një mesazh opsional Follow_Up për të llogaritur zhvendosjen e saktë të kohës kur transmetohet një paketë nga orët kryesore në orët skllave. Zhvendosja llogaritet duke përdorur formulën e mëposhtme:

Mekanizmi i matjes së vonesës së kolegëve

Ky mekanizëm përdor gjithashtu dy hapa për sinkronizim:

1. Pajisjet matin vonesën kohore për të gjithë fqinjët përmes të gjitha porteve. Për ta bërë këtë ata përdorin një mekanizëm të vonesës së kolegëve.
2. Korrigjimi i zhvendosjes së saktë kohore.

Matja e vonesës midis pajisjeve që mbështesin modalitetin Peer-to-Peer

Vonesa midis porteve që mbështesin mekanizmin peer-to-peer matet duke përdorur mesazhet e mëposhtme:

Kur porti 1 njeh kohët t1, t2, t3 dhe t4, mund të llogarisë vonesën mesatare (tmld). Ajo llogaritet duke përdorur formulën e mëposhtme:

Porta më pas e përdor këtë vlerë kur llogarit fushën e rregullimit për çdo mesazh Sync ose mesazh opsional Follow_Up që kalon përmes pajisjes.

Vonesa totale do të jetë e barabartë me shumën e vonesës gjatë transmetimit përmes kësaj pajisjeje, me vonesën mesatare gjatë transmetimit përmes kanalit të të dhënave dhe me vonesën e përfshirë tashmë në këtë mesazh, të aktivizuar në pajisjet në rrjedhën e sipërme.

Mesazhet Pdelay_Req, Pdelay_Resp dhe opsionale Pdelay_Resp_Follow_Up ju lejojnë të merrni vonesën nga master në slave dhe nga slave në master (rrethore).

Çdo asimetri midis këtyre dy vlerave do të sjellë një gabim korrigjimi të kompensimit të kohës.

Rregullimi i zhvendosjes së saktë të kohës

Orët skllave përdorin një mesazh Sync dhe një mesazh opsional Follow_Up për të llogaritur kompensimin e saktë të kohës kur transmeton një paketë nga orët kryesore në orët skllave. Zhvendosja llogaritet duke përdorur formulën e mëposhtme:

Përparësitë e rregullimit të mekanizmit peer-to-peer - vonesa kohore e çdo mesazhi Sync ose Follow_Up llogaritet ndërsa transmetohet në rrjet. Rrjedhimisht, ndryshimi i rrugës së transmetimit nuk do të ndikojë në asnjë mënyrë në saktësinë e rregullimit.

Kur përdorni këtë mekanizëm, sinkronizimi i kohës nuk kërkon llogaritjen e vonesës kohore përgjatë shtegut të përshkuar nga paketa e sinkronizimit, siç bëhet në shkëmbimin bazë. Ato. Mesazhet Delay_Req dhe Delay_Resp nuk dërgohen. Në këtë metodë, vonesa midis orëve master dhe slave thjesht përmblidhet në fushën e rregullimit të çdo mesazhi Sync ose Follow_Up.

Një avantazh tjetër është se ora master lirohet nga nevoja për të përpunuar mesazhet Delay_Req.

Mënyrat e funksionimit të orëve transparente

Prandaj, këta ishin shembuj të thjeshtë. Tani supozoni se çelsat shfaqen në rrugën e sinkronizimit.

Nëse përdorni ndërprerës pa mbështetje PTPv2, paketa e sinkronizimit do të vonohet në çelës me afërsisht 10 μs.

Ndërprerësit që mbështesin PTPv2 quhen orë transparente në terminologjinë IEEE 1588v2. Orët transparente nuk sinkronizohen nga ora kryesore dhe nuk marrin pjesë në hierarkinë "Ora kryesore - Ora Slave", por kur transmetojnë mesazhe sinkronizimi ata kujtojnë se sa kohë u vonua mesazhi prej tyre. Kjo ju lejon të rregulloni vonesën kohore.

Orët transparente mund të funksionojnë në dy mënyra:

• Nga fundi në fund.
• Peer to peer.

Nga fundi në fund (E2E)

Ora transparente E2E transmeton mesazhe Sync dhe mesazhe shoqëruese Follow_Up në të gjitha portet. Edhe ato që janë të bllokuara nga disa protokolle (për shembull, RSTP).

Çelësi kujton vulën kohore kur një paketë Sync (Follow_Up) u mor në port dhe kur u dërgua nga porti. Bazuar në këto dy stampa kohore, llogaritet koha që i duhet çelësit për të përpunuar mesazhin. Në standard, kjo kohë quhet koha e qëndrimit.

Koha e përpunimit shtohet në fushën e korrigjimit të mesazhit Sync (ora me një hap) ose Follow_Up (ora me dy hapa).

Ora transparente E2E mat kohën e përpunimit për mesazhet Sync dhe Delay_Req që kalojnë përmes çelësit. Por është e rëndësishme të kuptohet se vonesa kohore midis orës kryesore dhe orës skllav llogaritet duke përdorur mekanizmin e kërkesë-përgjigje të vonesës. Nëse ndryshon ora kryesore ose ndryshon rruga nga ora kryesore në orën skllav, vonesa matet përsëri. Kjo rrit kohën e tranzicionit në rast të ndryshimeve të rrjetit.

Ora transparente P2P, përveç matjes së kohës që i duhet një ndërprerës për të përpunuar një mesazh, mat vonesën në lidhjen e të dhënave me fqinjin e saj më të afërt duke përdorur një mekanizëm latente fqinje.

Vonesa matet në çdo lidhje në të dy drejtimet, duke përfshirë lidhjet që janë të bllokuara nga ndonjë protokoll (siç është RSTP). Kjo ju lejon të llogarisni menjëherë vonesën e re në rrugën e sinkronizimit nëse ndryshon ora e mjeshtrit ose topologjia e rrjetit.

Koha e përpunimit të mesazheve nga çelësat dhe vonesa grumbullohen kur dërgoni mesazhe Sync ose Follow_Up.

Llojet e mbështetjes PTPv2 me ndërprerës

Ndërprerësit mund të mbështesin PTPv2:

• në mënyrë programore;
• hardware.

Kur zbatoni protokollin PTPv2 në softuer, ndërprerësi kërkon një vulë kohore nga firmware. Problemi është se firmware-i funksionon në mënyrë ciklike dhe do të duhet të prisni derisa të përfundojë ciklin aktual, të marrë kërkesën për përpunim dhe të lëshojë një vulë kohore pas ciklit tjetër. Kjo gjithashtu do të marrë kohë dhe do të kemi një vonesë, megjithëse jo aq domethënëse sa pa mbështetjen e softuerit për PTPv2.

Vetëm mbështetja e harduerit për PTPv2 ju lejon të ruani saktësinë e kërkuar. Në këtë rast, vula kohore lëshohet nga një ASIC special, i cili është i instaluar në port.

Formati i mesazhit

Të gjitha mesazhet PTP përbëhen nga fushat e mëposhtme:

• Koka - 34 bajt.
• Trupi - madhësia varet nga lloji i mesazhit.
• Prapashtesa është opsionale.

Arkitra

Fusha Header është e njëjtë për të gjitha mesazhet PTP. Madhësia e saj është 34 byte.

Formati i fushës së kokës:

Lloji i mesazhit – përmban llojin e mesazhit që transmetohet, për shembull Sync, Delay_Req, PDelay_Req, etj.

Gjatësia e mesazhit – përmban madhësinë e plotë të mesazhit PTP, duke përfshirë kokën, trupin dhe prapashtesën (por duke përjashtuar bajtet e mbushjes).

Numri i domenit – përcakton se cilit domen PTP i përket mesazhi.

Домен - këto janë disa orë të ndryshme të mbledhura në një grup logjik dhe të sinkronizuara nga një orë kryesore, por jo domosdoshmërisht të sinkronizuara me orë që i përkasin një domeni tjetër.

flamuj – Kjo fushë përmban flamuj të ndryshëm për të identifikuar statusin e mesazhit.

korrigjimFusha – përmban kohën e vonesës në nanosekonda. Koha e vonesës përfshin vonesën kur transmetohet përmes orës transparente, si dhe vonesën kur transmetohet përmes kanalit kur përdoret modaliteti Peer-to-Peer.

burimPortIdentiteti – kjo fushë përmban informacione se nga cila port është dërguar fillimisht ky mesazh.

sekuenca ID – përmban një numër identifikimi për mesazhe individuale.

Fusha e kontrollit – fushë artifakti =) Mbetet nga versioni i parë i standardit dhe përmban informacione për llojin e këtij mesazhi. Në thelb i njëjtë me mesazhin tip, por me më pak opsione.

logMessageInterval – kjo fushë përcaktohet nga lloji i mesazhit.

trup

Siç u diskutua më lart, ekzistojnë disa lloje mesazhesh. Këto lloje janë përshkruar më poshtë:

Mesazh njoftimi
Mesazhi Njoftoni përdoret për të "treguar" orë të tjera brenda të njëjtit domen rreth parametrave të tij. Ky mesazh ju lejon të konfiguroni një hierarki Ora Master - Ora Slave.


Sinkronizoni mesazhin
Mesazhi "Sinkronizimi" dërgohet nga ora kryesore dhe përmban kohën e orës kryesore në kohën kur u krijua mesazhi "Sinkronizimi". Nëse ora kryesore është me dy faza, atëherë vula kohore në mesazhin Sync do të vendoset në 0 dhe vula kohore aktuale do të dërgohet në mesazhin shoqërues Follow_Up. Mesazhi Sync përdoret për të dy mekanizmat e matjes së vonesës.

Mesazhi transmetohet duke përdorur Multicast. Opsionale mund të përdorni Unicast.

Mesazhi Delay_Req

Formati i mesazhit Delay_Req është identik me mesazhin Sync. Ora skllav dërgon Delay_Req. Ai përmban kohën e dërgimit të Delay_Req nga ora skllav. Ky mesazh përdoret vetëm për mekanizmin e vonesës së kërkesë-përgjigjes.

Mesazhi transmetohet duke përdorur Multicast. Opsionale mund të përdorni Unicast.

Mesazh Follow_Up

Mesazhi Follow_Up dërgohet opsionalisht nga ora kryesore dhe përmban kohën e dërgimit Sinkronizoni mesazhet mjeshtër. Vetëm orët kryesore me dy faza dërgojnë mesazhin Follow_Up.

Mesazhi Follow_Up përdoret për të dy mekanizmat e matjes së vonesës.

Mesazhi transmetohet duke përdorur Multicast. Opsionale mund të përdorni Unicast.

Mesazhi Delay_Resp

Mesazhi Delay_Resp dërgohet nga ora kryesore. Ai përmban kohën kur Delay_Req është marrë nga ora kryesore. Ky mesazh përdoret vetëm për mekanizmin e vonesës së kërkesë-përgjigjes.

Mesazhi transmetohet duke përdorur Multicast. Opsionale mund të përdorni Unicast.

Mesazhi Pdelay_Req

Mesazhi Pdelay_Req dërgohet nga një pajisje që kërkon një vonesë. Ai përmban kohën kur është dërguar mesazhi nga porti i kësaj pajisjeje. Pdelay_Req përdoret vetëm për mekanizmin e matjes së vonesës fqinje.

Mesazhi Pdelay_Resp

Mesazhi Pdelay_Resp dërgohet nga një pajisje që ka marrë një kërkesë për vonesë. Ai përmban kohën kur është marrë mesazhi Pdelay_Req nga kjo pajisje. Mesazhi Pdelay_Resp përdoret vetëm për mekanizmin e matjes së vonesës fqinje.

Mesazh Pdelay_Resp_Follow_Up

Mesazhi Pdelay_Resp_Follow_Up dërgohet opsionalisht nga pajisja që ka marrë kërkesën për vonesë. Ai përmban kohën kur është marrë mesazhi Pdelay_Req nga kjo pajisje. Mesazhi Pdelay_Resp_Follow_Up dërgohet vetëm nga orët kryesore me dy faza.

Ky mesazh mund të përdoret gjithashtu për kohën e ekzekutimit në vend të një vule kohore. Koha e ekzekutimit është koha nga momenti i marrjes së Pdelay-Req deri në dërgimin e Pdelay_Resp.

Pdelay_Resp_Follow_Up përdoren vetëm për mekanizmin e matjes së vonesës fqinje.

Mesazhet e menaxhimit

Mesazhet e kontrollit PTP kërkohen për të transferuar informacion midis një ose më shumë orëve dhe nyjes së kontrollit.

Transferimi në LV

Një mesazh PTP mund të transmetohet në dy nivele:

• Rrjeti – si pjesë e të dhënave IP.
• Kanali – si pjesë e një kornize Ethernet.

Transmetimi i mesazhit PTP përmes UDP mbi IP përmes Ethernetit

PTP mbi UDP mbi Ethernet

Profilet

PTP ka mjaft parametra fleksibël që duhet të konfigurohen. Për shembull:

• Opsionet BMCA.
• Mekanizmi i matjes së vonesës.
• Intervalet dhe vlerat fillestare të të gjithë parametrave të konfigurueshëm, etj.

Dhe përkundër faktit që kemi thënë më parë se pajisjet PTPv2 janë të pajtueshme me njëra-tjetrën, kjo nuk është e vërtetë. Pajisjet duhet të kenë të njëjtat cilësime për të komunikuar.

Kjo është arsyeja pse ekzistojnë të ashtuquajturat profile PTPv2. Profilet janë grupe cilësimesh të konfiguruara dhe kufizime të përcaktuara të protokollit në mënyrë që sinkronizimi i kohës të mund të zbatohet për një aplikacion specifik.

Vetë standardi IEEE 1588v2 përshkruan vetëm një profil - "Profili i parazgjedhur". Të gjitha profilet e tjera krijohen dhe përshkruhen nga organizata dhe shoqata të ndryshme.

Për shembull, Profili i Energjisë, ose Profili i Energjisë PTPv2, u krijua nga Komiteti i Transmetimit të Sistemeve të Energjisë dhe Komiteti i Nënstacionit të Shoqërisë së Energjisë dhe Energjisë IEEE. Vetë profili quhet IEEE C37.238-2011.

Profili përshkruan se PTP mund të transferohet:

• Vetëm përmes rrjeteve L2 (p.sh. Ethernet, HSR, PRP, jo-IP).
• Mesazhet transmetohen vetëm me transmetim Multicast.
• Mekanizmi i matjes së vonesës së kolegëve përdoret si mekanizëm i matjes së vonesës.

Domeni i parazgjedhur është 0, domeni i rekomanduar është 93.

Filozofia e projektimit të C37.238-2011 ishte të zvogëlonte numrin e veçorive opsionale dhe të ruante vetëm funksionet e nevojshme për ndërveprim të besueshëm midis pajisjeve dhe rritjen e stabilitetit të sistemit.

Gjithashtu, frekuenca e transmetimit të mesazhit përcaktohet:

Në fakt, vetëm një parametër është i disponueshëm për zgjedhje - lloji i orës kryesore (me një ose dy faza).

Saktësia nuk duhet të jetë më shumë se 1 μs. Me fjalë të tjera, një rrugë sinkronizimi mund të përmbajë maksimumi 15 orë transparente ose tre orë kufitare.

Burimi: www.habr.com