Rincian implementasine protokol sinkronisasi wektu PTPv2

Pambuka

Konsep mbangun "Guru Digital" ing industri tenaga listrik mbutuhake sinkronisasi kanthi akurasi 1 μs. Transaksi finansial uga mbutuhake akurasi mikrodetik. Ing aplikasi kasebut, akurasi wektu NTP ora cukup maneh.

Protokol sinkronisasi PTPv2, sing diterangake dening standar IEEE 1588v2, ngidini akurasi sinkronisasi sawetara puluhan nanodetik. PTPv2 ngidini sampeyan ngirim paket sinkronisasi liwat jaringan L2 lan L3.

Wilayah utama sing digunakake PTPv2 yaiku:

• tenogo;
• peralatan kontrol lan pangukuran;
• kompleks militèr-industri;
• telekomunikasi;
• sektor keuangan.

Kiriman iki nerangake cara kerja protokol sinkronisasi PTPv2.

Kita duwe pengalaman luwih akeh ing industri lan asring ndeleng protokol iki ing aplikasi energi. Mulane, kita bakal nindakake review kanthi ati-ati kanggo energi.

Kenapa perlu?

Saiki, STO 34.01-21-004-2019 saka PJSC Rosseti lan STO 56947007-29.240.10.302-2020 saka PJSC FGC UES ngemot syarat kanggo ngatur bis proses kanthi sinkronisasi wektu liwat PTPv2.

Iki amarga kasunyatan manawa terminal proteksi relay lan piranti ukur disambungake menyang bus proses, sing ngirimake nilai saiki lan voltase langsung liwat bus proses, nggunakake aliran SV sing disebut (streams multicast).

Terminal proteksi relay nggunakake nilai kasebut kanggo ngetrapake proteksi teluk. Yen akurasi pangukuran wektu cilik, sawetara proteksi bisa uga salah.

Contone, pertahanan selektivitas mutlak bisa dadi korban sinkronisasi wektu "lemah". Asring logika pertahanan kasebut adhedhasar perbandingan rong jumlah. Yen nilai-nilai kasebut beda-beda kanthi nilai sing cukup gedhe, mula proteksi kasebut dipicu. Yen nilai-nilai kasebut diukur kanthi akurasi wektu 1 ms, mula sampeyan bisa entuk beda gedhe ing ngendi nilai kasebut pancen normal yen diukur kanthi akurasi 1 μs.

versi PTP

Protokol PTP wiwitane diterangake ing taun 2002 ing standar IEEE 1588-2002 lan diarani "Standar Protokol Sinkronisasi Jam Presisi kanggo Sistem Pengukuran lan Kontrol Jaringan." Ing 2008, standar IEEE 1588-2008 sing dianyari dirilis, sing nggambarake PTP Versi 2. Versi protokol iki nambah akurasi lan stabilitas, nanging ora njaga kompatibilitas mundur karo versi protokol pisanan. Uga, ing 2019, versi standar IEEE 1588-2019 dirilis, nggambarake PTP v2.1. Versi iki nambah dandan cilik menyang PTPv2 lan kompatibel karo PTPv2.

Ing tembung liyane, kita duwe gambar ing ngisor iki kanthi versi:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

-
ora cocog

ora cocog

PTPv2 (IEEE 1588-2008)

ora cocog

-
Kompatibel

PTPv2.1 (IEEE 1588-2019)

ora cocog

Kompatibel

-

Nanging, kaya biasane, ana nuansa.

Ora kompatibel antarane PTPv1 lan PTPv2 tegese piranti sing aktif PTPv1 ora bakal bisa nyinkronake karo jam akurat sing mlaku ing PTPv2. Dheweke nggunakake macem-macem format pesen kanggo nyinkronake.

Nanging isih bisa nggabungake piranti karo PTPv1 lan piranti karo PTPv2 ing jaringan sing padha. Kanggo entuk iki, sawetara manufaktur ngidini sampeyan milih versi protokol ing port jam pinggir. Yaiku, jam wates bisa nyinkronake nggunakake PTPv2 lan isih nyinkronake jam liyane sing disambungake nganggo PTPv1 lan PTPv2.

piranti PTP. Apa dheweke lan kepiye bedane?

Standar IEEE 1588v2 nggambarake sawetara jinis piranti. Kabeh mau ditampilake ing tabel.

Piranti kasebut komunikasi karo siji liyane liwat LAN nggunakake PTP.

Piranti PTP diarani jam. Kabeh jam tangan njupuk wektu sing tepat saka jam tangan grandmaster.

Ana 5 jinis jam tangan:

Jam Grandmaster

Sumber utama wektu akurat. Asring dilengkapi antarmuka kanggo nyambungake GPS.

Jam Biasa

Piranti port siji sing bisa dadi master (master clock) utawa slave (slave clock)

Jam utama (master)

Iki minangka sumber wektu sing tepat nalika jam liyane disinkronake

Jam budak

Piranti pungkasan sing disinkronake saka jam master

Jam Wates

Piranti kanthi macem-macem port sing bisa dadi master utawa budak.

Sing, jam iki bisa nyinkronake saka jam master unggul lan nyinkronake jam budak inferior.

Jam Transparan End-to-end

Piranti kanthi pirang-pirang port sing dudu jam master utawa budak. Iki ngirim data PTP antarane rong jam tangan.

Nalika ngirim data, jam transparan mbenerake kabeh pesen PTP.

Koreksi dumadi kanthi nambahake wektu tundha ing piranti iki menyang kolom koreksi ing header pesen sing dikirim.

Jam Transparan Peer-to-Peer

Piranti kanthi pirang-pirang port sing dudu jam master utawa budak.
Iki ngirim data PTP antarane rong jam tangan.

Nalika ngirim data, jam transparan mbenerake kabeh pesen PTP Sync lan Follow_Up (liyane babagan ing ngisor iki).

Koreksi digayuh kanthi nambahake menyang kolom koreksi paket sing ditularake wektu tundha ing piranti transmisi lan wektu tundha ing saluran transmisi data.

Node Manajemen

Piranti sing ngatur lan diagnosa jam tangan liyane

Jam master lan slave disinkronake nggunakake cap wektu ing pesen PTP. Ana rong jinis pesen ing protokol PTP:

• Pesen Acara minangka pesen sing disinkronake sing kalebu nggawe stempel wektu nalika pesen dikirim lan nalika ditampa.
• Pesen Umum - Pesen iki ora mbutuhake cap wektu, nanging bisa uga ngemot cap wektu kanggo pesen sing gegandhengan

Pesen Acara

Pesen Umum

Sync
Tundha_Req
Pdelay_Req
Pdelay_Resp

Ngumumake
Follow_Up
Tundha_Resp
Pdelay_Resp_Follow_Up
Manajemen
Tandha

Kabeh jinis pesen bakal dibahas luwih rinci ing ngisor iki.

Masalah sinkronisasi dhasar

Nalika paket sinkronisasi ditularaké liwat jaringan lokal, iku telat ing switch lan ing link data. Saklar apa wae bakal ngasilake wektu tundha udakara 10 mikrodetik, sing ora bisa ditampa kanggo PTPv2. Sawise kabeh, kita kudu entuk akurasi 1 μs ing piranti pungkasan. (Iki yen kita ngomong babagan energi. Aplikasi liyane mbutuhake akurasi sing luwih gedhe.)

IEEE 1588v2 nggambarake sawetara algoritma operasi sing ngidini sampeyan ngrekam wektu tundha lan mbenerake.

Algoritma kerja
Sajrone operasi normal, protokol beroperasi ing rong fase.

• Tahap 1 - netepake hirarki "Master Clock - Slave Clock".
• Fase 2 - sinkronisasi jam nggunakake mekanisme End-to-End utawa Peer-to-Peer.

Tahap 1 - Nggawe Hirarki Master-Slave

Saben port jam biasa utawa pinggiran duwe sawetara negara (jam budak lan jam master). Standar kasebut nggambarake algoritma transisi antarane negara kasebut. Ing pemrograman, algoritma kasebut diarani mesin negara utawa mesin negara (luwih rinci ing Wiki).

Mesin negara iki nggunakake Algoritma Jam Master Best (BMCA) kanggo nyetel master nalika nyambungake rong jam.

Algoritma iki ngidini jam tangan njupuk tanggung jawab jam tangan grandmaster nalika jam tangan grandmaster hulu kelangan sinyal GPS, dadi offline, lsp.

Transisi negara miturut BMCA diringkes ing diagram ing ngisor iki:


Informasi babagan jam tangan ing ujung liyane "kabel" dikirim ing pesen khusus (Pesen ngumumake). Sawise informasi iki ditampa, algoritma mesin negara mlaku lan perbandingan digawe kanggo ndeleng jam sing luwih apik. Port ing watch paling apik dadi master watch.

Hierarki prasaja ditampilake ing diagram ing ngisor iki. Paths 1, 2, 3, 4, 5 bisa ngemot jam Transparan, nanging ora melu netepake hirarki Master Clock - Slave Clock.

Tahap 2 - Sinkronake jam biasa lan pinggir

Sanalika sawise netepake hirarki "Master Clock - Slave Clock", fase sinkronisasi jam reguler lan wates diwiwiti.

Kanggo nyinkronake, jam master ngirim pesen sing ngemot stempel wektu menyang jam budak.

Jam master bisa dadi:

• tataran siji;
• rong tataran.

Jam siji-tataran ngirim pesen Sync kanggo nyinkronake.

Jam rong tahap nggunakake rong pesen kanggo sinkronisasi - Sync lan Follow_Up.

Loro mekanisme bisa digunakake kanggo fase sinkronisasi:

• Tundha mekanisme panjalukan-respon.
• Mekanisme pangukuran tundha peer.

Pisanan, ayo goleki mekanisme kasebut ing kasus sing paling gampang - nalika jam tangan transparan ora digunakake.

Tundha mekanisme panjalukan-respon

Mekanisme kasebut kalebu rong langkah:

1. Ngukur wektu tundha ngirim pesen antarane jam master lan jam budak. Dileksanakake nggunakake mekanisme tundha request-respon.
2. Koreksi shift wektu sing tepat ditindakake.

Pangukuran latensi


t1 - Wektu ngirim pesen Sync dening jam master; t2 - Wektu nampa pesen Sync dening jam budak; t3 - Wektu ngirim panyuwunan wektu tundha (Delay_Req) ​​dening jam budak; t4 - Delay_Req reception wektu dening jam master.

Nalika jam budak ngerti kaping t1, t2, t3, lan t4, bisa ngetung wektu tundha rata-rata nalika ngirim pesen sinkronisasi (tmpd). Iki diitung kaya ing ngisor iki:

Nalika ngirim pesen Sync lan Follow_Up, wektu tundha saka master menyang abdi diwilang - t-ms.

Nalika ngirim pesen Delay_Req lan Delay_Resp, wektu tundha saka budak menyang master diitung - t-sm.

Yen ana sawetara asimetri ing antarane rong nilai kasebut, banjur ana kesalahan kanggo mbenerake panyimpangan wektu sing tepat. Kesalahan kasebut disebabake amarga wektu tundha sing diwilang yaiku rata-rata tundha t-ms lan t-sm. Yen telat ora padha karo saben liyane, mula kita ora bakal nyetel wektu kanthi akurat.

Koreksi shift wektu

Sawise wektu tundha antarane jam master lan jam budak dikenal, jam budak nindakake koreksi wektu.

Jam budak nggunakake pesen Sync lan pesen Follow_Up opsional kanggo ngetung wektu sing pas nalika ngirim paket saka master menyang jam budak. Shift diwilang nggunakake rumus ing ngisor iki:

Mekanisme pangukuran tundha peer

Mekanisme iki uga nggunakake rong langkah kanggo sinkronisasi:

1. Piranti ngukur wektu tundha kanggo kabeh tanggi liwat kabeh bandar. Kanggo nindakake iki, padha nggunakake mekanisme tundha peer.
2. Koreksi shift wektu sing tepat.

Ngukur latensi ing antarane piranti sing ndhukung mode Peer-to-Peer

Latensi antarane port sing ndhukung mekanisme peer-to-peer diukur nggunakake pesen ing ngisor iki:

Nalika port 1 ngerti kaping t1, t2, t3 lan t4, bisa ngetung wektu tundha rata-rata (tmld). Iki diitung nganggo rumus ing ngisor iki:

Port banjur nggunakake nilai iki nalika ngetung kolom pangaturan kanggo saben pesen Sync utawa pesen Follow_Up opsional sing liwat piranti.

Total wektu tundha bakal padha karo jumlah wektu tundha sajrone transmisi liwat piranti iki, wektu tundha rata-rata sajrone transmisi liwat saluran data lan wektu tundha sing wis ana ing pesen iki, diaktifake ing piranti hulu.

Pesen Pdelay_Req, Pdelay_Resp lan Pdelay_Resp_Follow_Up opsional ngidini sampeyan entuk wektu tundha saka master menyang budak lan saka budak menyang master (bunder).

Sembarang asimetri ing antarane rong nilai kasebut bakal ngenalake kesalahan koreksi wektu.

Nyetel shift wektu sing tepat

Jam budak nggunakake pesen Sync lan pesen Follow_Up opsional kanggo ngetung wektu sing pas nalika ngirim paket saka master menyang jam budak. Shift diwilang nggunakake rumus ing ngisor iki:

Advantages imbuhan saka mekanisme peer-to-peer - wektu tundha saben pesen Sync utawa Follow_Up wis diwilang minangka ditularaké ing jaringan. Akibate, ngganti jalur transmisi ora bakal mengaruhi akurasi pangaturan.

Nalika nggunakake mekanisme iki, sinkronisasi wektu ora mbutuhake ngetung wektu tundha ing sadawane dalan sing dilewati dening paket sinkronisasi, kaya sing ditindakake ing ijol-ijolan dhasar. Sing. Pesen Delay_Req lan Delay_Resp ora dikirim. Ing metode iki, wektu tundha antarane jam master lan budak mung diringkes ing kolom pangaturan saben pesen Sync utawa Follow_Up.

Kauntungan liyane yaiku jam master ora mbutuhake proses pesen Delay_Req.

Mode operasi jam transparan

Mulane, iki minangka conto sing prasaja. Saiki umpamane ngalih katon ing jalur sinkronisasi.

Yen sampeyan nggunakake switch tanpa dhukungan PTPv2, paket sinkronisasi bakal ditundha ing switch kira-kira 10 µs.

Ngalih sing ndhukung PTPv2 diarani jam Transparan ing terminologi IEEE 1588v2. Jam transparan ora disinkronake saka jam master lan ora melu ing hirarki "Master Clock - Slave Clock", nanging nalika ngirim pesen sinkronisasi, dheweke ngelingi suwene pesen kasebut ditundha. Iki ngidini sampeyan nyetel wektu tundha.

Jam transparan bisa digunakake ing rong mode:

• End-to-End.
• Peer-to-Peer.

End-to-End (E2E)

Jam transparan E2E nyiarake pesen Sync lan pesen Follow_Up ing kabeh port. Malah sing diblokir dening sawetara protokol (contone, RSTP).

Ngalih ngelingi timestamp nalika paket Sync (Follow_Up) ditampa ing port lan nalika dikirim saka port. Adhedhasar rong cap wektu iki, wektu sing dibutuhake kanggo ngalih kanggo ngolah pesen diwilang. Ing standar, wektu iki diarani wektu panggonan.

Wektu pangolahan ditambahake menyang kolom correctionField pesen Sync (jam siji-langkah) utawa Follow_Up (jam loro-langkah).

Jam transparan E2E ngukur wektu pangolahan kanggo pesen Sync lan Delay_Req sing liwat switch. Nanging iku penting kanggo ngerti yen wektu tundha antarane jam master lan jam budak diwilang nggunakake mekanisme tundha request-respon. Yen jam master diganti utawa path saka jam master menyang jam abdi diganti, wektu tundha diukur maneh. Iki nambah wektu transisi yen ana owah-owahan jaringan.

Jam transparan P2P, saliyane kanggo ngukur wektu sing dibutuhake kanggo ngalih kanggo proses pesen, ngukur wektu tundha ing link data menyang pepadhamu sing paling cedhak nggunakake mekanisme latensi pepadhamu.

Latensi diukur ing saben pranala ing loro arah, kalebu pranala sing diblokir dening sawetara protokol (kayata RSTP). Iki ngidini sampeyan langsung ngetung wektu tundha anyar ing path sinkronisasi yen jam grandmaster utawa topologi jaringan diganti.

Wektu pangolahan pesen kanthi switch lan latensi dikumpulake nalika ngirim pesen Sync utawa Follow_Up.

Jinis support PTPv2 dening ngalih

Switch bisa ndhukung PTPv2:

• kanthi terprogram;
• hardware.

Nalika ngleksanakake protokol PTPv2 ing piranti lunak, switch njaluk timestamp saka perangkat kukuh. Masalah iku perangkat kukuh dianggo cyclically, lan sampeyan kudu ngenteni nganti rampung siklus saiki, njupuk panjalukan kanggo Processing lan masalah timestamp sawise siklus sabanjuré. Iki uga mbutuhake wektu, lan kita bakal entuk wektu tundha, sanajan ora pati penting kaya tanpa dhukungan piranti lunak kanggo PTPv2.

Mung dhukungan hardware kanggo PTPv2 ngidini sampeyan njaga akurasi sing dibutuhake. Ing kasus iki, prangko wektu ditanggepi dening ASIC khusus, kang diinstal ing port.

Format Pesen

Kabeh pesen PTP kalebu kolom ing ngisor iki:

• Header - 34 bita.
• Ukuran awak gumantung saka jinis pesen.
• Sufiks iku opsional.

Header

Kolom Header padha kanggo kabeh pesen PTP. Ukurane 34 bita.

Format kolom header:

jinis pesen - ngemot jinis pesen sing dikirim, contone Sync, Delay_Req, PDelay_Req, lsp.

pesenLength – ngemot ukuran lengkap pesen PTP, kalebu header, awak lan seselan (nanging ora kalebu padding byte).

domainNumber – nemtokake domain PTP pesen kasebut.

Домен - iki sawetara jam beda diklumpukake ing siji klompok logis lan diselarasake saka siji jam master, nanging ora kudu diselarasake karo jam gadhahanipun domain beda.

bendera – Lapangan iki ngemot macem-macem gendera kanggo ngenali status pesen.

koreksiField - ngemot wektu tundha ing nanodetik. Wektu tundha kalebu wektu tundha nalika ngirim liwat jam transparan, uga wektu tundha nalika ngirim liwat saluran nalika nggunakake mode Peer-to-Peer.

sumberPortIdentity – lapangan iki ngemot informasi bab port ngendi pesen iki Originally dikirim.

sequenceID - ngemot nomer identifikasi kanggo pesen individu.

lapangan kontrol – kolom artefak =) Iku tetep saka versi pisanan saka standar lan ngemot informasi bab jinis pesen iki. Ateges padha karo messageType, nanging kanthi pilihan sing luwih sithik.

logMessageInterval – lapangan iki ditemtokake dening jinis pesen.

Body

Kaya sing wis dibahas ing ndhuwur, ana sawetara jinis pesen. Jinis-jinis kasebut diterangake ing ngisor iki:

Pesen pengumuman
Pesen Announce digunakake kanggo "marang" jam liyane ing domain sing padha babagan paramèter. Pesen iki ngidini sampeyan nyetel hierarki Jam Master - Jam Budak.


pesen sinkronisasi
Pesen Sync dikirim dening jam master lan ngemot wektu jam master nalika pesen Sync digawe. Yen jam master ana rong tahap, banjur stempel wektu ing pesen Sync bakal disetel dadi 0, lan timestamp saiki bakal dikirim ing pesen Follow_Up sing gegandhengan. Pesen Sync digunakake kanggo loro mekanisme pangukuran latensi.

Pesen dikirim nggunakake Multicast. Opsional sampeyan bisa nggunakake Unicast.

Delay_Req pesen

Format pesen Delay_Req padha karo pesen Sync. Jam budak ngirim Delay_Req. Isine wektu Delay_Req dikirim dening jam budak. Pesen iki mung digunakake kanggo mekanisme panjalukan-respon tundha.

Pesen dikirim nggunakake Multicast. Opsional sampeyan bisa nggunakake Unicast.

Pesen Follow_Up

Pesen Follow_Up opsional dikirim dening jam master lan ngemot wektu ngirim Nyelarasake pesen master. Mung jam master rong tahap ngirim pesen Follow_Up.

Pesen Follow_Up digunakake kanggo loro mekanisme pangukuran latensi.

Pesen dikirim nggunakake Multicast. Opsional sampeyan bisa nggunakake Unicast.

Delay_Resp pesen

Pesen Delay_Resp dikirim dening jam master. Isine wektu nalika Delay_Req ditampa dening jam master. Pesen iki mung digunakake kanggo mekanisme panjalukan-respon tundha.

Pesen dikirim nggunakake Multicast. Opsional sampeyan bisa nggunakake Unicast.

Pdelay_Req pesen

Pesen Pdelay_Req dikirim dening piranti sing njaluk wektu tundha. Isine wektu pesen dikirim saka port piranti iki. Pdelay_Req mung digunakake kanggo mekanisme pangukuran tundha pepadhamu.

Pdelay_Resp pesen

Pesen Pdelay_Resp dikirim dening piranti sing wis nampa panjalukan wektu tundha. Isine wektu pesen Pdelay_Req ditampa dening piranti iki. Pesen Pdelay_Resp mung digunakake kanggo mekanisme pangukuran tundha pepadhamu.

Pesen Pdelay_Resp_Follow_Up

Pesen Pdelay_Resp_Follow_Up opsional dikirim dening piranti sing wis nampa panjalukan wektu tundha. Isine wektu pesen Pdelay_Req ditampa dening piranti iki. Pesen Pdelay_Resp_Follow_Up mung dikirim dening jam master rong tahap.

Pesen iki uga bisa digunakake kanggo wektu eksekusi tinimbang stempel wektu. Wektu eksekusi yaiku wektu wiwit Pdelay-Req ditampa nganti Pdelay_Resp dikirim.

Pdelay_Resp_Follow_Up digunakake mung kanggo mekanisme pangukuran tundha pepadhamu.

Pesen Manajemen

Pesen kontrol PTP dibutuhake kanggo nransfer informasi antarane siji utawa luwih jam lan simpul kontrol.

Transfer menyang LV

Pesen PTP bisa dikirim ing rong tingkat:

• Jaringan - minangka bagéan saka data IP.
• Saluran - minangka bagéan saka pigura Ethernet.

transmisi pesen PTP liwat UDP liwat IP liwat Ethernet

PTP liwat UDP liwat Ethernet

Profil

PTP nduweni cukup akeh paramèter fleksibel sing kudu dikonfigurasi. Tuladhane:

• Pilihan BMCA.
• Mekanisme pangukuran latensi.
• Interval lan nilai awal kabeh parameter sing bisa dikonfigurasi, lsp.

Lan senadyan kasunyatan sing sadurunge kita ngomong yen piranti PTPv2 kompatibel karo saben liyane, iki ora bener. Piranti kudu duwe setelan sing padha supaya bisa komunikasi.

Mulane ana sing disebut profil PTPv2. Profil minangka klompok setelan sing dikonfigurasi lan watesan protokol sing ditetepake supaya sinkronisasi wektu bisa ditindakake kanggo aplikasi tartamtu.

Standar IEEE 1588v2 dhewe mung nggambarake siji profil - "Profil Default". Kabeh profil liyane digawe lan diterangake dening macem-macem organisasi lan asosiasi.

Contone, Power Profile, utawa PTPv2 Power Profile, digawe dening Power Systems Relaying Committee lan Substation Committee of IEEE Power and Energy Society. Profil kasebut diarani IEEE C37.238-2011.

Profil kasebut nggambarake manawa PTP bisa ditransfer:

• Mung liwat jaringan L2 (yaiku Ethernet, HSR, PRP, non-IP).
• Pesen dikirim mung dening siaran Multicast.
• Mekanisme pangukuran tundha peer digunakake minangka mekanisme pangukuran tundha.

Domain standar yaiku 0, domain sing disaranake yaiku 93.

Filosofi desain C37.238-2011 yaiku nyuda jumlah fitur opsional lan mung nahan fungsi sing dibutuhake kanggo interaksi sing dipercaya ing antarane piranti lan nambah stabilitas sistem.

Uga, frekuensi transmisi pesen ditemtokake:

Nyatane, mung siji parameter sing kasedhiya kanggo dipilih - jinis jam master (tataran siji utawa rong tahap).

Akurasi ngirim ora luwih saka 1 μs. Ing tembung liyane, siji path sinkronisasi bisa ngemot maksimal 15 jam transparan utawa telung jam wates.

Source: www.habr.com