Pagpapakilala
Ang konsepto ng pagbuo ng isang "Digital Substation" sa industriya ng kuryente ay nangangailangan ng pag-synchronize na may katumpakan na 1 ΞΌs. Ang mga transaksyon sa pananalapi ay nangangailangan din ng katumpakan ng microsecond. Sa mga application na ito, hindi na sapat ang katumpakan ng oras ng NTP.
Ang protocol ng pag-synchronize ng PTPv2, na inilarawan ng pamantayang IEEE 1588v2, ay nagbibigay-daan para sa katumpakan ng pag-synchronize ng ilang sampu ng nanosecond. Binibigyang-daan ka ng PTPv2 na magpadala ng mga packet ng synchronization sa mga L2 at L3 network.
Ang mga pangunahing lugar kung saan ginagamit ang PTPv2 ay:
- enerhiya;
- kagamitan sa pagkontrol at pagsukat;
- military-industrial complex;
- telecom;
- sektor ng pananalapi.
Ipinapaliwanag ng post na ito kung paano gumagana ang protocol ng pag-synchronize ng PTPv2.
Mas marami kaming karanasan sa industriya at madalas naming nakikita ang protocol na ito sa mga application ng enerhiya. Alinsunod dito, gagawin namin ang pagsusuri nang may pag-iingat .
Bakit kailangan?
Sa ngayon, STO 34.01-21-004-2019 ng PJSC Rosseti at STO 56947007-29.240.10.302-2020 ng PJSC FGC UES ay naglalaman ng mga kinakailangan para sa pag-aayos ng process bus na may time synchronization sa pamamagitan ng PTPv2.
Ito ay dahil sa ang katunayan na ang mga terminal ng proteksyon ng relay at mga aparato sa pagsukat ay konektado sa proseso ng bus, na nagpapadala ng agarang kasalukuyang at mga halaga ng boltahe sa pamamagitan ng proseso ng bus, gamit ang tinatawag na SV stream (multicast stream).
Ginagamit ng mga terminal ng proteksyon ng relay ang mga halagang ito upang ipatupad ang proteksyon sa bay. Kung ang katumpakan ng mga sukat ng oras ay maliit, kung gayon ang ilang mga proteksyon ay maaaring gumana nang mali.
Halimbawa, ang mga depensa ng absolute selectivity ay maaaring maging biktima ng "mahina" na pag-synchronize ng oras. Kadalasan ang lohika ng naturang mga depensa ay batay sa paghahambing ng dalawang dami. Kung ang mga halaga ay nag-iiba sa isang sapat na malaking halaga, kung gayon ang proteksyon ay na-trigger. Kung ang mga halagang ito ay sinusukat na may katumpakan ng oras na 1 ms, maaari kang makakuha ng malaking pagkakaiba kung saan ang mga halaga ay talagang normal kung sinusukat nang may katumpakan na 1 ΞΌs.
Mga bersyon ng PTP
Ang PTP protocol ay orihinal na inilarawan noong 2002 sa IEEE 1588-2002 standard at tinawag na "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems." Noong 2008, ang na-update na pamantayan ng IEEE 1588-2008 ay inilabas, na naglalarawan ng PTP Bersyon 2. Ang bersyon na ito ng protocol ay nagpabuti ng katumpakan at katatagan, ngunit hindi nagpapanatili ng pabalik na pagkakatugma sa unang bersyon ng protocol. Gayundin, noong 2019, isang bersyon ng pamantayang IEEE 1588-2019 ang inilabas, na naglalarawan sa PTP v2.1. Ang bersyon na ito ay nagdaragdag ng maliliit na pagpapabuti sa PTPv2 at pabalik na tugma sa PTPv2.
Sa madaling salita, mayroon kaming sumusunod na larawan na may mga bersyon:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
-
Hindi kaayon
Hindi kaayon
PTPv2 (IEEE 1588-2008)
Hindi kaayon
-
Mga katugmang
PTPv2.1 (IEEE 1588-2019)
Hindi kaayon
Mga katugmang
-
Ngunit, gaya ng dati, may mga nuances.
Ang hindi pagkakatugma sa pagitan ng PTPv1 at PTPv2 ay nangangahulugan na ang isang PTPv1-enabled na device ay hindi makakapag-synchronize sa isang tumpak na orasan na tumatakbo sa PTPv2. Gumagamit sila ng iba't ibang format ng mensahe para i-synchronize.
Ngunit posible pa ring pagsamahin ang mga device na may PTPv1 at mga device na may PTPv2 sa parehong network. Upang makamit ito, pinapayagan ka ng ilang mga tagagawa na piliin ang bersyon ng protocol sa mga port ng edge clock. Iyon ay, maaaring mag-synchronize ang isang boundary clock gamit ang PTPv2 at i-synchronize pa rin ang iba pang mga orasan na konektado dito gamit ang parehong PTPv1 at PTPv2.
Mga aparatong PTP. Ano ang mga ito at paano sila naiiba?
Ang pamantayang IEEE 1588v2 ay naglalarawan ng ilang uri ng mga device. Ang lahat ng mga ito ay ipinapakita sa talahanayan.
Ang mga device ay nakikipag-usap sa isa't isa sa isang LAN gamit ang PTP.
Ang mga aparatong PTP ay tinatawag na mga orasan. Ang lahat ng mga relo ay tumatagal ng eksaktong oras mula sa grandmaster na relo.
Mayroong 5 uri ng mga relo:
Grandmaster na orasan
Ang pangunahing pinagmumulan ng tumpak na oras. Madalas na nilagyan ng interface para sa pagkonekta ng GPS.
Ordinaryong Orasan
Isang solong port device na maaaring maging master (master clock) o slave (slave clock)
Master na orasan (master)
Ang mga ito ang pinagmulan ng eksaktong oras kung saan ang iba pang mga orasan ay naka-synchronize
Oras ng alipin
End device na naka-synchronize mula sa master clock
Boundary Clock
Isang device na may maraming port na maaaring master o slave.
Iyon ay, ang mga orasan na ito ay maaaring mag-synchronize mula sa superior master clock at i-synchronize ang mas mababang alipin na orasan.
End-to-end na Transparent na Orasan
Isang device na may maraming port na hindi master clock o slave. Nagpapadala ito ng data ng PTP sa pagitan ng dalawang relo.
Kapag nagpapadala ng data, itinutuwid ng transparent na orasan ang lahat ng mensahe ng PTP.
Nagaganap ang pagwawasto sa pamamagitan ng pagdaragdag ng oras ng pagkaantala sa device na ito sa field ng pagwawasto sa header ng ipinadalang mensahe.
Peer-to-Peer Transparent na Orasan
Isang device na may maraming port na hindi master clock o slave.
Nagpapadala ito ng data ng PTP sa pagitan ng dalawang relo.
Kapag nagpapadala ng data, itinatama ng transparent na orasan ang lahat ng PTP na mensaheng Sync at Follow_Up (higit pa tungkol sa mga ito sa ibaba).
Ang pagwawasto ay nakakamit sa pamamagitan ng pagdaragdag sa field ng pagwawasto ng ipinadalang packet ng pagkaantala sa transmitting device at ang pagkaantala sa channel ng paghahatid ng data.
Pamamahala ng Node
Isang device na nagko-configure at nag-diagnose ng iba pang mga relo
Ang mga master at slave na orasan ay naka-synchronize gamit ang mga timestamp sa mga PTP na mensahe. Mayroong dalawang uri ng mga mensahe sa PTP protocol:
- Ang Mga Mensahe sa Kaganapan ay mga naka-synchronize na mensahe na kinabibilangan ng pagbuo ng timestamp sa oras na ipinadala ang mensahe at sa oras na natanggap ito.
- Mga Pangkalahatang Mensahe - Ang mga mensaheng ito ay hindi nangangailangan ng mga timestamp, ngunit maaaring naglalaman ng mga timestamp para sa mga nauugnay na mensahe
Mga Mensahe sa Kaganapan
Mga Pangkalahatang Mensahe
I-sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Anunsyo
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
pamamahala
Signaling
Lahat ng uri ng mga mensahe ay tatalakayin nang mas detalyado sa ibaba.
Mga pangunahing problema sa pag-synchronize
Kapag ang isang synchronization packet ay ipinadala sa isang lokal na network, ito ay naaantala sa switch at sa data link. Ang anumang switch ay magdudulot ng pagkaantala ng humigit-kumulang 10 microseconds, na hindi katanggap-tanggap para sa PTPv2. Pagkatapos ng lahat, kailangan nating makamit ang katumpakan ng 1 ΞΌs sa panghuling device. (Ito ay kung tungkol sa enerhiya ang pinag-uusapan. Maaaring mangailangan ng higit na katumpakan ang ibang mga application.)
Inilalarawan ng IEEE 1588v2 ang ilang operating algorithm na nagbibigay-daan sa iyong itala ang pagkaantala ng oras at itama ito.
Algorithm ng trabaho
Sa normal na operasyon, ang protocol ay gumagana sa dalawang yugto.
- Phase 1 - pagtatatag ng hierarchy ng "Master Clock - Slave Clock".
- Phase 2 - pag-synchronize ng orasan gamit ang isang End-to-End o Peer-to-Peer na mekanismo.
Phase 1 - Pagtatatag ng Master-Slave Hierarchy
Ang bawat port ng isang regular o edge na orasan ay may tiyak na bilang ng mga estado (slave clock at master clock). Inilalarawan ng pamantayan ang algorithm ng paglipat sa pagitan ng mga estadong ito. Sa programming, ang naturang algorithm ay tinatawag na finite state machine o state machine (higit pang mga detalye sa Wiki).
Ginagamit ng state machine na ito ang Best Master Clock Algorithm (BMCA) upang itakda ang master kapag kumukonekta ng dalawang orasan.
Ang algorithm na ito ay nagbibigay-daan sa relo na kunin ang mga responsibilidad ng grandmaster watch kapag ang upstream grandmaster watch ay nawalan ng signal ng GPS, nag-offline, atbp.
Ang mga transition ng estado ayon sa BMCA ay ibinubuod sa sumusunod na diagram:
Ang impormasyon tungkol sa relo sa kabilang dulo ng "wire" ay ipinadala sa isang espesyal na mensahe (I-anunsyo ang mensahe). Kapag natanggap na ang impormasyong ito, tatakbo ang state machine algorithm at gagawin ang paghahambing para makita kung aling orasan ang mas mahusay. Ang port sa pinakamahusay na relo ay nagiging master watch.
Ang isang simpleng hierarchy ay ipinapakita sa diagram sa ibaba. Ang Path 1, 2, 3, 4, 5 ay maaaring maglaman ng Transparent na orasan, ngunit hindi sila nakikilahok sa pagtatatag ng Master Clock - Slave Clock hierarchy.
Phase 2 - I-synchronize ang mga regular at edge na orasan
Kaagad pagkatapos itatag ang hierarchy ng "Master Clock - Slave Clock", ang yugto ng pag-synchronize ng regular at boundary na orasan ay magsisimula.
Upang mag-synchronize, nagpapadala ang master clock ng mensahe na naglalaman ng timestamp sa mga slave clock.
Ang master clock ay maaaring:
- solong yugto;
- dalawang yugto.
Nagpapadala ng isang Sync message ang mga single-stage na orasan upang i-synchronize.
Gumagamit ang dalawang yugto ng orasan ng dalawang mensahe para sa pag-synchronize - Sync at Follow_Up.
Dalawang mekanismo ang maaaring gamitin para sa yugto ng pag-synchronize:
- Mekanismo ng pagkaantala sa kahilingan-tugon.
- Mekanismo ng pagsukat ng pagkaantala ng peer.
Una, tingnan natin ang mga mekanismong ito sa pinakasimpleng kaso - kapag hindi ginagamit ang mga transparent na relo.
Mekanismo ng pagkaantala sa kahilingan-tugon
Ang mekanismo ay nagsasangkot ng dalawang hakbang:
- Pagsukat ng pagkaantala sa pagpapadala ng mensahe sa pagitan ng master clock at ng slave clock. Ginawa gamit ang mekanismo ng pag-delay ng kahilingan-tugon.
- Isinasagawa ang pagwawasto ng eksaktong paglilipat ng oras.
Pagsusukat ng latency
t1 β Oras ng pagpapadala ng Sync message ng master clock; t2 β Oras ng pagtanggap ng Sync message ng slave clock; t3 - Oras ng pagpapadala ng kahilingan sa pagkaantala (Delay_Req) ββββsa pamamagitan ng orasan ng alipin; t4 β Delay_Req reception time ng master clock.
Kapag alam ng slave clock ang mga oras na t1, t2, t3, at t4, maaari nitong kalkulahin ang average na pagkaantala kapag nagpapadala ng mensahe ng pag-synchronize (tmpd). Ito ay kinakalkula tulad ng sumusunod:
Kapag nagpapadala ng isang Sync at Follow_Up na mensahe, ang pagkaantala ng oras mula sa master hanggang sa alipin ay kinakalkula - t-ms.
Kapag nagpapadala ng mga mensahe ng Delay_Req at Delay_Resp, ang pagkaantala ng oras mula sa alipin hanggang sa master ay kinakalkula - t-sm.
Kung may ilang kawalaan ng simetrya sa pagitan ng dalawang halagang ito, lilitaw ang isang error sa pagwawasto sa paglihis ng eksaktong oras. Ang error ay sanhi ng katotohanan na ang kinakalkula na pagkaantala ay ang average ng mga t-ms at t-sm na pagkaantala. Kung ang mga pagkaantala ay hindi pantay sa isa't isa, hindi namin aayusin ang oras nang tumpak.
Pagwawasto ng time shift
Kapag nalaman na ang pagkaantala sa pagitan ng master clock at ng slave clock, ang slave clock ay nagsasagawa ng time correction.
Ginagamit ng mga Slave clock ang Sync message at isang opsyonal na Follow_Up na mensahe upang kalkulahin ang eksaktong oras ng offset kapag nagpapadala ng packet mula sa master patungo sa mga slave clock. Kinakalkula ang shift gamit ang sumusunod na formula:
Mekanismo ng pagsukat ng pagkaantala ng peer
Gumagamit din ang mekanismong ito ng dalawang hakbang para sa pag-synchronize:
- Sinusukat ng mga device ang pagkaantala ng oras sa lahat ng kapitbahay sa lahat ng port. Upang gawin ito, gumagamit sila ng mekanismo ng pagkaantala ng peer.
- Pagwawasto ng eksaktong paglilipat ng oras.
Pagsukat ng latency sa pagitan ng mga device na sumusuporta sa Peer-to-Peer mode
Ang latency sa pagitan ng mga port na sumusuporta sa mekanismo ng peer-to-peer ay sinusukat gamit ang mga sumusunod na mensahe:
Kapag alam ng port 1 ang mga oras na t1, t2, t3 at t4, maaari nitong kalkulahin ang average na pagkaantala (tmld). Kinakalkula ito gamit ang sumusunod na formula:
Pagkatapos ay ginagamit ng port ang halagang ito kapag kinakalkula ang field ng pagsasaayos para sa bawat mensahe ng Sync o opsyonal na Follow_Up na mensahe na dumadaan sa device.
Ang kabuuang pagkaantala ay magiging katumbas ng kabuuan ng pagkaantala sa panahon ng paghahatid sa pamamagitan ng device na ito, ang average na pagkaantala sa panahon ng paghahatid sa pamamagitan ng data channel at ang pagkaantala na nakapaloob na sa mensaheng ito, na pinagana sa mga upstream na device.
Nagbibigay-daan sa iyo ang Mga Mensahe na Pdelay_Req, Pdelay_Resp at opsyonal na Pdelay_Resp_Follow_Up na makuha ang pagkaantala mula sa master hanggang sa alipin at mula sa alipin hanggang sa master (circular).
Ang anumang kawalaan ng simetrya sa pagitan ng dalawang halagang ito ay magpapakita ng error sa pagwawasto ng time offset.
Pagsasaayos ng eksaktong paglilipat ng oras
Gumagamit ang mga Slave clock ng isang Sync message at isang opsyonal na Follow_Up na mensahe upang kalkulahin ang eksaktong oras ng offset kapag nagpapadala ng packet mula sa master patungo sa mga slave clock. Kinakalkula ang shift gamit ang sumusunod na formula:
Mga kalamangan sa pagsasaayos ng mekanismo ng peer-to-peer - ang pagkaantala ng oras ng bawat mensahe ng Sync o Follow_Up ay kinakalkula habang ipinapadala ito sa network. Dahil dito, ang pagbabago sa daanan ng paghahatid ay hindi makakaapekto sa katumpakan ng pagsasaayos.
Kapag ginagamit ang mekanismong ito, ang pag-synchronize ng oras ay hindi nangangailangan ng pagkalkula ng pagkaantala ng oras sa landas na dinadaanan ng packet ng pag-synchronise, tulad ng ginagawa sa pangunahing palitan. Yung. Ang mga mensahe ng Delay_Req at Delay_Resp ay hindi ipinadala. Sa paraang ito, ang pagkaantala sa pagitan ng master at slave na mga orasan ay ibinubuod lamang sa adjustment field ng bawat Sync o Follow_Up na mensahe.
Ang isa pang bentahe ay ang master clock ay hinalinhan sa pangangailangang iproseso ang mga mensahe ng Delay_Req.
Mga mode ng pagpapatakbo ng mga transparent na orasan
Alinsunod dito, ito ay mga simpleng halimbawa. Ngayon ipagpalagay na lumilitaw ang mga switch sa path ng pag-synchronize.
Kung gagamit ka ng mga switch na walang suporta sa PTPv2, maaantala ang packet ng synchronization sa switch ng humigit-kumulang 10 ΞΌs.
Ang mga switch na sumusuporta sa PTPv2 ay tinatawag na Transparent na orasan sa terminolohiya ng IEEE 1588v2. Ang mga transparent na orasan ay hindi naka-synchronize mula sa master clock at hindi nakikilahok sa "Master Clock - Slave Clock" hierarchy, ngunit kapag nagpapadala ng mga mensahe ng pag-synchronize naaalala nila kung gaano katagal ang mensahe ay naantala ng mga ito. Nagbibigay-daan ito sa iyo na ayusin ang pagkaantala ng oras.
Maaaring gumana ang mga transparent na orasan sa dalawang mode:
- End-to-End.
- Peer to peer.
End-to-End (E2E)
Ang E2E na transparent na orasan ay nagbo-broadcast ng mga Sync na mensahe at kasamang Follow_Up na mga mensahe sa lahat ng port. Kahit na ang mga na-block ng ilang mga protocol (halimbawa, RSTP).
Naaalala ng switch ang timestamp kapag natanggap ang isang Sync packet (Follow_Up) sa port at kapag ipinadala ito mula sa port. Batay sa dalawang timestamp na ito, kinakalkula ang oras na aabutin para maproseso ng switch ang mensahe. Sa pamantayan, ang oras na ito ay tinatawag na oras ng paninirahan.
Ang oras ng pagproseso ay idinaragdag sa field ng correctionField ng Sync (one-step clock) o Follow_Up (two-step clock) na mensahe.
Ang E2E transparent na orasan ay sumusukat sa oras ng pagproseso para sa Sync at Delay_Req na mga mensahe na dumadaan sa switch. Ngunit mahalagang maunawaan na ang pagkaantala ng oras sa pagitan ng master clock at ng slave clock ay kinakalkula gamit ang delay request-response mechanism. Kung magbabago ang master clock o magbago ang path mula sa master clock patungo sa slave clock, susukatin muli ang pagkaantala. Pinatataas nito ang oras ng paglipat sa kaso ng mga pagbabago sa network.
Ang P2P na transparent na orasan, bilang karagdagan sa pagsukat sa oras na kinakailangan para sa isang switch upang maproseso ang isang mensahe, ay sinusukat ang pagkaantala sa link ng data sa pinakamalapit na kapitbahay nito gamit ang isang mekanismo ng latency ng kapitbahay.
Ang latency ay sinusukat sa bawat link sa parehong direksyon, kabilang ang mga link na hinarangan ng ilang protocol (gaya ng RSTP). Binibigyang-daan ka nitong agad na kalkulahin ang bagong pagkaantala sa landas ng pag-synchronize kung magbabago ang grandmaster clock o topology ng network.
Ang oras ng pagpoproseso ng mensahe sa pamamagitan ng mga switch at latency ay naipon kapag nagpapadala ng mga Sync o Follow_Up na mensahe.
Mga uri ng suporta ng PTPv2 sa pamamagitan ng mga switch
Maaaring suportahan ng mga switch ang PTPv2:
- sa pamamagitan ng programming;
- hardware.
Kapag ipinapatupad ang protocol ng PTPv2 sa software, humihiling ang switch ng timestamp mula sa firmware. Ang problema ay ang firmware ay gumagana nang paikot, at kailangan mong maghintay hanggang matapos ang kasalukuyang cycle, kunin ang kahilingan para sa pagproseso at mag-isyu ng timestamp pagkatapos ng susunod na cycle. Magtatagal din ito, at magkakaroon tayo ng pagkaantala, bagama't hindi kasinghalaga ng walang suporta sa software para sa PTPv2.
Tanging ang suporta sa hardware para sa PTPv2 ang nagpapahintulot sa iyo na mapanatili ang kinakailangang katumpakan. Sa kasong ito, ang time stamp ay ibinibigay ng isang espesyal na ASIC, na naka-install sa port.
Format ng Mensahe
Ang lahat ng mga mensahe ng PTP ay binubuo ng mga sumusunod na field:
- Header β 34 byte.
- Katawan β depende ang laki sa uri ng mensahe.
- Ang suffix ay opsyonal.
Ulo
Ang field ng Header ay pareho para sa lahat ng PTP na mensahe. Ang laki nito ay 34 bytes.
Format ng field ng header:
uri ng mensahe β naglalaman ng uri ng mensaheng ipinapadala, halimbawa Sync, Delay_Req, PDelay_Req, atbp.
Haba ng mensahe β naglalaman ng buong laki ng mensahe ng PTP, kabilang ang header, body at suffix (ngunit hindi kasama ang padding byte).
domainNumber β tinutukoy kung saang PTP domain kabilang ang mensahe.
ΠΠΎΠΌΠ΅Π½ - ito ay ilang magkakaibang orasan na nakolekta sa isang lohikal na pangkat at naka-synchronize mula sa isang master clock, ngunit hindi kinakailangang naka-synchronize sa mga orasan na kabilang sa ibang domain.
flag β Ang field na ito ay naglalaman ng iba't ibang mga flag upang matukoy ang katayuan ng mensahe.
correctionField β naglalaman ng oras ng pagkaantala sa nanosecond. Kasama sa oras ng pagkaantala ang pagkaantala kapag nagpapadala sa pamamagitan ng transparent na orasan, pati na rin ang pagkaantala kapag nagpapadala sa pamamagitan ng channel kapag gumagamit ng Peer-to-Peer mode.
sourcePortIdentity β ang field na ito ay naglalaman ng impormasyon tungkol sa kung aling port ang orihinal na ipinadala ng mensaheng ito.
sequenceID β naglalaman ng numero ng pagkakakilanlan para sa mga indibidwal na mensahe.
controlField β artifact field =) Ito ay nananatili mula sa unang bersyon ng pamantayan at naglalaman ng impormasyon tungkol sa uri ng mensaheng ito. Talagang kapareho ng messageType, ngunit may mas kaunting mga pagpipilian.
logMessageInterval β ang field na ito ay tinutukoy ng uri ng mensahe.
katawan
Tulad ng tinalakay sa itaas, mayroong ilang uri ng mga mensahe. Ang mga uri na ito ay inilalarawan sa ibaba:
Mensahe ng anunsyo
Ang mensahe ng Anunsyo ay ginagamit upang "sabihin" sa iba pang mga orasan sa loob ng parehong domain ang tungkol sa mga parameter nito. Binibigyang-daan ka ng mensaheng ito na mag-set up ng Master Clock - Slave Clock hierarchy.
I-sync ang mensahe
Ang Sync message ay ipinadala ng master clock at naglalaman ng oras ng master clock sa oras na nabuo ang Sync message. Kung ang master clock ay dalawang yugto, ang timestamp sa Sync message ay itatakda sa 0, at ang kasalukuyang timestamp ay ipapadala sa nauugnay na Follow_Up message. Ang Sync message ay ginagamit para sa parehong latency measurement mechanism.
Ang mensahe ay ipinadala gamit ang Multicast. Opsyonal na maaari mong gamitin ang Unicast.
Delay_Req message
Ang format ng mensahe ng Delay_Req ay kapareho ng mensahe ng Sync. Ang orasan ng alipin ay nagpapadala ng Delay_Req. Naglalaman ito ng oras na ipinadala ng slave clock ang Delay_Req. Ang mensaheng ito ay ginagamit lamang para sa mekanismo ng pagkaantala sa kahilingan-tugon.
Ang mensahe ay ipinadala gamit ang Multicast. Opsyonal na maaari mong gamitin ang Unicast.
Follow_Up ng Mensahe
Ang Follow_Up na mensahe ay opsyonal na ipinadala ng master clock at naglalaman ng oras ng pagpapadala I-sync ang mga mensahe master. Dalawang-yugtong master clock lang ang nagpapadala ng Follow_Up message.
Ang Follow_Up na mensahe ay ginagamit para sa parehong mga mekanismo ng pagsukat ng latency.
Ang mensahe ay ipinadala gamit ang Multicast. Opsyonal na maaari mong gamitin ang Unicast.
Delay_Resp na mensahe
Ang Delay_Resp na mensahe ay ipinadala ng master clock. Naglalaman ito ng oras kung kailan natanggap ng master clock ang Delay_Req. Ang mensaheng ito ay ginagamit lamang para sa mekanismo ng pagkaantala sa kahilingan-tugon.
Ang mensahe ay ipinadala gamit ang Multicast. Opsyonal na maaari mong gamitin ang Unicast.
Mensahe ng Pdelay_Req
Ang mensahe ng Pdelay_Req ay ipinadala ng isang device na humihiling ng pagkaantala. Naglalaman ito ng oras na ipinadala ang mensahe mula sa port ng device na ito. Ginagamit lang ang Pdelay_Req para sa mekanismo ng pagsukat ng pagkaantala ng kapitbahay.
Pdelay_Resp na mensahe
Ang mensaheng Pdelay_Resp ay ipinadala ng isang device na nakatanggap ng kahilingan sa pagkaantala. Naglalaman ito ng oras na natanggap ng device na ito ang mensahe ng Pdelay_Req. Ang mensaheng Pdelay_Resp ay ginagamit lamang para sa mekanismo ng pagsukat ng pagkaantala ng kapitbahay.
Mensahe Pdelay_Resp_Follow_Up
Ang Pdelay_Resp_Follow_Up na mensahe ay opsyonal na ipinadala ng device na nakatanggap ng kahilingan sa pagkaantala. Naglalaman ito ng oras na natanggap ng device na ito ang mensahe ng Pdelay_Req. Ang Pdelay_Resp_Follow_Up na mensahe ay ipinapadala lamang ng dalawang yugto ng master clocks.
Magagamit din ang mensaheng ito para sa oras ng pagpapatupad sa halip na isang timestamp. Ang oras ng pagpapatupad ay ang oras mula sa sandaling matanggap ang Pdelay-Req hanggang ipadala ang Pdelay_Resp.
Ginagamit lang ang Pdelay_Resp_Follow_Up para sa mekanismo ng pagsukat ng pagkaantala ng kapitbahay.
Mga Mensahe sa Pamamahala
Ang mga mensahe ng kontrol ng PTP ay kinakailangan upang maglipat ng impormasyon sa pagitan ng isa o higit pang mga orasan at ng control node.
Ilipat sa LV
Ang isang mensahe ng PTP ay maaaring ipadala sa dalawang antas:
- Network β bilang bahagi ng data ng IP.
- Channel β bilang bahagi ng isang Ethernet frame.
Pagpapadala ng mensahe ng PTP sa UDP sa IP sa Ethernet
PTP sa UDP sa Ethernet
Mga Profile
Ang PTP ay may napakaraming flexible na parameter na kailangang i-configure. Halimbawa:
- Mga Pagpipilian sa BMCA.
- Mekanismo ng pagsukat ng latency.
- Mga agwat at paunang halaga ng lahat ng mga parameter na maaaring i-configure, atbp.
At sa kabila ng katotohanan na dati naming sinabi na ang mga aparatong PTPv2 ay magkatugma sa isa't isa, hindi ito totoo. Ang mga device ay dapat magkaroon ng parehong mga setting upang makipag-usap.
Kaya naman may mga tinatawag na PTPv2 profiles. Ang mga profile ay mga pangkat ng mga naka-configure na setting at tinukoy na mga paghihigpit sa protocol upang maipatupad ang pag-synchronize ng oras para sa isang partikular na application.
Ang pamantayang IEEE 1588v2 mismo ay naglalarawan lamang ng isang profile - "Default na Profile". Ang lahat ng iba pang mga profile ay nilikha at inilarawan ng iba't ibang mga organisasyon at asosasyon.
Halimbawa, ang Power Profile, o PTPv2 Power Profile, ay nilikha ng Power Systems Relaying Committee at ng Substation Committee ng IEEE Power and Energy Society. Ang profile mismo ay tinatawag na IEEE C37.238-2011.
Inilalarawan ng profile na maaaring ilipat ang PTP:
- Sa pamamagitan lamang ng mga L2 network (ie Ethernet, HSR, PRP, non-IP).
- Ang mga mensahe ay ipinapadala lamang sa pamamagitan ng Multicast broadcast.
- Ang mekanismo ng pagsukat ng pagkaantala ng peer ay ginagamit bilang mekanismo ng pagsukat ng pagkaantala.
Ang default na domain ay 0, ang inirerekomendang domain ay 93.
Ang pilosopiya ng disenyo ng C37.238-2011 ay upang bawasan ang bilang ng mga opsyonal na feature at panatilihin lamang ang mga kinakailangang function para sa maaasahang pakikipag-ugnayan sa pagitan ng mga device at pinataas na katatagan ng system.
Gayundin, ang dalas ng paghahatid ng mensahe ay tinutukoy:
Sa katunayan, isang parameter lamang ang magagamit para sa pagpili - ang uri ng master clock (single-stage o two-stage).
Ang katumpakan ay dapat na hindi hihigit sa 1 ΞΌs. Sa madaling salita, ang isang path ng pag-synchronize ay maaaring maglaman ng maximum na 15 transparent na orasan o tatlong boundary na orasan.
Pinagmulan: www.habr.com