Pengenalan
Konsep membina "Pencawang Digital" dalam industri kuasa elektrik memerlukan penyegerakan dengan ketepatan 1 ΞΌs. Urus niaga kewangan juga memerlukan ketepatan mikrosaat. Dalam aplikasi ini, ketepatan masa NTP tidak lagi mencukupi.
Protokol penyegerakan PTPv2, yang diterangkan oleh standard IEEE 1588v2, membolehkan ketepatan penyegerakan beberapa puluh nanosaat. PTPv2 membolehkan anda menghantar paket penyegerakan melalui rangkaian L2 dan L3.
Kawasan utama di mana PTPv2 digunakan ialah:
- tenaga;
- peralatan kawalan dan pengukur;
- kompleks perindustrian tentera;
- telekom;
- sektor kewangan.
Siaran ini menerangkan cara protokol penyegerakan PTPv2 berfungsi.
Kami mempunyai lebih banyak pengalaman dalam industri dan sering melihat protokol ini dalam aplikasi tenaga. Sehubungan itu, kami akan melakukan semakan dengan berhati-hati .
Kenapa perlu?
Pada masa ini, STO 34.01-21-004-2019 PJSC Rosseti dan STO 56947007-29.240.10.302-2020 PJSC FGC UES mengandungi keperluan untuk mengatur bas proses dengan penyegerakan masa melalui PTPv2.
Ini disebabkan oleh fakta bahawa terminal perlindungan geganti dan peranti pengukur disambungkan ke bas proses, yang menghantar nilai arus dan voltan serta-merta melalui bas proses, menggunakan aliran SV yang dipanggil (aliran berbilang hantaran).
Terminal perlindungan geganti menggunakan nilai ini untuk melaksanakan perlindungan teluk. Jika ketepatan ukuran masa adalah kecil, maka sesetengah perlindungan mungkin beroperasi secara palsu.
Sebagai contoh, pertahanan selektiviti mutlak mungkin menjadi mangsa penyegerakan masa "lemah". Selalunya logik pertahanan sedemikian adalah berdasarkan perbandingan dua kuantiti. Jika nilai menyimpang dengan nilai yang cukup besar, maka perlindungan akan dicetuskan. Jika nilai ini diukur dengan ketepatan masa 1 ms, maka anda boleh mendapat perbezaan yang besar di mana nilai sebenarnya adalah normal jika diukur dengan ketepatan 1 ΞΌs.
versi PTP
Protokol PTP pada asalnya diterangkan pada tahun 2002 dalam piawaian IEEE 1588-2002 dan dipanggil "Standard untuk Protokol Penyegerakan Jam Ketepatan untuk Pengukuran dan Sistem Kawalan Rangkaian." Pada tahun 2008, standard IEEE 1588-2008 yang dikemas kini telah dikeluarkan, yang menerangkan PTP Versi 2. Versi protokol ini meningkatkan ketepatan dan kestabilan, tetapi tidak mengekalkan keserasian ke belakang dengan versi pertama protokol. Selain itu, pada tahun 2019, versi standard IEEE 1588-2019 telah dikeluarkan, menerangkan PTP v2.1. Versi ini menambah peningkatan kecil pada PTPv2 dan serasi ke belakang dengan PTPv2.
Dengan kata lain, kami mempunyai gambar berikut dengan versi:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
-
Tidak serasi
Tidak serasi
PTPv2 (IEEE 1588-2008)
Tidak serasi
-
Serasi
PTPv2.1 (IEEE 1588-2019)
Tidak serasi
Serasi
-
Tetapi, seperti biasa, terdapat nuansa.
Ketidakserasian antara PTPv1 dan PTPv2 bermakna peranti yang didayakan PTPv1 tidak akan dapat menyegerakkan dengan jam yang tepat yang berjalan pada PTPv2. Mereka menggunakan format mesej yang berbeza untuk disegerakkan.
Tetapi masih mungkin untuk menggabungkan peranti dengan PTPv1 dan peranti dengan PTPv2 pada rangkaian yang sama. Untuk mencapai matlamat ini, sesetengah pengeluar membenarkan anda memilih versi protokol pada port jam tepi. Iaitu, jam sempadan boleh menyegerakkan menggunakan PTPv2 dan masih menyegerakkan jam lain yang disambungkan kepadanya menggunakan kedua-dua PTPv1 dan PTPv2.
peranti PTP. Apakah mereka dan bagaimana mereka berbeza?
Piawaian IEEE 1588v2 menerangkan beberapa jenis peranti. Kesemuanya ditunjukkan dalam jadual.
Peranti berkomunikasi antara satu sama lain melalui LAN menggunakan PTP.
Peranti PTP dipanggil jam. Semua jam tangan mengambil masa yang tepat dari jam tangan grandmaster.
Terdapat 5 jenis jam tangan:
Jam grandmaster
Sumber utama masa yang tepat. Selalunya dilengkapi dengan antara muka untuk menyambungkan GPS.
Jam Biasa
Peranti port tunggal yang boleh menjadi induk (jam induk) atau hamba (jam hamba)
Jam induk (tuan)
Mereka adalah sumber masa yang tepat di mana jam lain disegerakkan
Jam budak
Peranti tamat yang disegerakkan daripada jam induk
Jam Sempadan
Peranti dengan berbilang port yang boleh menjadi tuan atau hamba.
Iaitu, jam ini boleh menyegerakkan dari jam induk unggul dan menyegerakkan jam hamba yang lebih rendah.
Jam Lutsinar hujung ke hujung
Peranti dengan berbilang port yang bukan jam induk mahupun hamba. Ia menghantar data PTP antara dua jam tangan.
Semasa menghantar data, jam lutsinar membetulkan semua mesej PTP.
Pembetulan berlaku dengan menambahkan masa tunda pada peranti ini pada medan pembetulan dalam pengepala mesej yang dihantar.
Jam Telus Peer-to-Peer
Peranti dengan berbilang port yang bukan jam induk mahupun hamba.
Ia menghantar data PTP antara dua jam tangan.
Semasa menghantar data, jam lutsinar membetulkan semua mesej PTP Sync dan Follow_Up (lebih lanjut mengenainya di bawah).
Pembetulan dicapai dengan menambah pada medan pembetulan paket yang dihantar kelewatan pada peranti pemancar dan kelewatan pada saluran penghantaran data.
Nod Pengurusan
Peranti yang mengkonfigurasi dan mendiagnosis jam tangan lain
Jam induk dan hamba disegerakkan menggunakan cap masa dalam mesej PTP. Terdapat dua jenis mesej dalam protokol PTP:
- Mesej Peristiwa ialah mesej yang disegerakkan yang melibatkan penjanaan cap masa pada masa mesej dihantar dan pada masa ia diterima.
- Mesej Umum - Mesej ini tidak memerlukan cap masa, tetapi mungkin mengandungi cap masa untuk mesej yang berkaitan
Mesej Peristiwa
Mesej Umum
Segerakkan
Delay_Req
Pdelay_Req
Pdelay_Resp
Mengumumkan
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
pengurusan
Isyarat
Semua jenis mesej akan dibincangkan dengan lebih terperinci di bawah.
Masalah penyegerakan asas
Apabila paket penyegerakan dihantar melalui rangkaian tempatan, ia ditangguhkan pada suis dan dalam pautan data. Mana-mana suis akan menghasilkan kelewatan kira-kira 10 mikrosaat, yang tidak boleh diterima untuk PTPv2. Lagipun, kita perlu mencapai ketepatan 1 ΞΌs pada peranti akhir. (Ini jika kita bercakap tentang tenaga. Aplikasi lain mungkin memerlukan ketepatan yang lebih tinggi.)
IEEE 1588v2 menerangkan beberapa algoritma pengendalian yang membolehkan anda merekodkan kelewatan masa dan membetulkannya.
Algoritma kerja
Semasa operasi biasa, protokol beroperasi dalam dua fasa.
- Fasa 1 - mewujudkan hierarki "Jam Induk - Jam Hamba".
- Fasa 2 - penyegerakan jam menggunakan mekanisme End-to-End atau Peer-to-Peer.
Fasa 1 - Mewujudkan Hierarki Tuan-Hamba
Setiap port jam biasa atau tepi mempunyai bilangan keadaan tertentu (jam hamba dan jam induk). Piawaian menerangkan algoritma peralihan antara keadaan ini. Dalam pengaturcaraan, algoritma sedemikian dipanggil mesin keadaan terhingga atau mesin keadaan (lebih terperinci dalam Wiki).
Mesin keadaan ini menggunakan Algoritma Jam Induk Terbaik (BMCA) untuk menetapkan induk apabila menyambungkan dua jam.
Algoritma ini membolehkan jam tangan mengambil alih tanggungjawab jam tangan grandmaster apabila jam tangan grandmaster hulu kehilangan isyarat GPS, pergi ke luar talian, dsb.
Peralihan negeri mengikut BMCA diringkaskan dalam rajah berikut:
Maklumat tentang jam tangan di hujung "wayar" yang lain dihantar dalam mesej khas (Announce message). Setelah maklumat ini diterima, algoritma mesin keadaan berjalan dan perbandingan dibuat untuk melihat jam yang lebih baik. Pelabuhan pada jam tangan terbaik menjadi jam tangan induk.
Hierarki mudah ditunjukkan dalam rajah di bawah. Laluan 1, 2, 3, 4, 5 mungkin mengandungi jam Telus, tetapi mereka tidak mengambil bahagian dalam mewujudkan hierarki Jam Induk - Jam Hamba.
Fasa 2 - Segerakkan jam biasa dan tepi
Sejurus selepas menubuhkan hierarki "Jam Induk - Jam Hamba", fasa penyegerakan jam biasa dan sempadan bermula.
Untuk menyegerakkan, jam induk menghantar mesej yang mengandungi cap waktu kepada jam hamba.
Jam induk boleh menjadi:
- peringkat tunggal;
- dua peringkat.
Jam satu peringkat menghantar satu mesej Sync untuk disegerakkan.
Jam dua peringkat menggunakan dua mesej untuk penyegerakan - Sync dan Follow_Up.
Dua mekanisme boleh digunakan untuk fasa penyegerakan:
- Kelewatan mekanisme permintaan-tindak balas.
- Mekanisme pengukuran kelewatan rakan sebaya.
Mula-mula, mari kita lihat mekanisme ini dalam kes paling mudah - apabila jam tangan lutsinar tidak digunakan.
Kelewatan mekanisme permintaan-tindak balas
Mekanisme ini melibatkan dua langkah:
- Mengukur kelewatan dalam menghantar mesej antara jam induk dan jam hamba. Dilakukan menggunakan mekanisme permintaan-tindak balas kelewatan.
- Pembetulan anjakan masa yang tepat dilakukan.
Pengukuran latensi
t1 β Masa menghantar mesej Sync oleh jam induk; t2 β Masa penerimaan mesej Penyegerakan oleh jam hamba; t3 - Masa menghantar permintaan kelewatan (Delay_Req) ββββoleh jam hamba; t4 β Delay_Req masa penerimaan oleh jam induk.
Apabila jam hamba mengetahui masa t1, t2, t3 dan t4, ia boleh mengira kelewatan purata apabila menghantar mesej penyegerakan (tmpd). Ia dikira seperti berikut:
Apabila menghantar mesej Sync dan Follow_Up, kelewatan masa daripada tuan kepada hamba dikira - t-ms.
Apabila menghantar mesej Delay_Req dan Delay_Resp, kelewatan masa daripada hamba kepada tuan dikira - t-sm.
Jika beberapa asimetri berlaku antara kedua-dua nilai ini, maka ralat dalam membetulkan sisihan masa yang tepat muncul. Ralat disebabkan oleh fakta bahawa kelewatan yang dikira adalah purata kelewatan t-ms dan t-sm. Jika kelewatan tidak sama antara satu sama lain, maka kami tidak akan menyesuaikan masa dengan tepat.
Pembetulan anjakan masa
Setelah kelewatan antara jam induk dan jam hamba diketahui, jam hamba melakukan pembetulan masa.
Jam hamba menggunakan mesej Sync dan mesej Follow_Up pilihan untuk mengira masa yang tepat mengimbangi apabila menghantar paket daripada induk kepada jam hamba. Peralihan dikira menggunakan formula berikut:
Mekanisme pengukuran kelewatan rakan sebaya
Mekanisme ini juga menggunakan dua langkah untuk penyegerakan:
- Peranti mengukur kelewatan masa kepada semua jiran melalui semua port. Untuk melakukan ini, mereka menggunakan mekanisme kelewatan rakan sebaya.
- Pembetulan anjakan masa yang tepat.
Mengukur kependaman antara peranti yang menyokong mod Peer-to-Peer
Kependaman antara port yang menyokong mekanisme peer-to-peer diukur menggunakan mesej berikut:
Apabila port 1 mengetahui masa t1, t2, t3 dan t4, ia boleh mengira kelewatan purata (tmld). Ia dikira menggunakan formula berikut:
Port kemudian menggunakan nilai ini apabila mengira medan pelarasan untuk setiap mesej Sync atau mesej Follow_Up pilihan yang melalui peranti.
Jumlah kelewatan akan sama dengan jumlah kelewatan semasa penghantaran melalui peranti ini, purata kelewatan semasa penghantaran melalui saluran data dan kelewatan yang telah terkandung dalam mesej ini, yang didayakan pada peranti huluan.
Mesej Pdelay_Req, Pdelay_Resp dan Pdelay_Resp_Follow_Up pilihan membolehkan anda mendapatkan kelewatan daripada tuan kepada hamba dan daripada hamba kepada tuan (pekeliling).
Sebarang asimetri antara kedua-dua nilai ini akan memperkenalkan ralat pembetulan mengimbangi masa.
Melaraskan peralihan masa yang tepat
Jam hamba menggunakan mesej Sync dan mesej Follow_Up pilihan untuk mengira masa yang tepat mengimbangi apabila menghantar paket daripada induk kepada jam hamba. Peralihan dikira menggunakan formula berikut:
Kelebihan pelarasan mekanisme peer-to-peer - kelewatan masa setiap mesej Sync atau Follow_Up dikira semasa ia dihantar dalam rangkaian. Akibatnya, menukar laluan penghantaran tidak akan menjejaskan ketepatan pelarasan.
Apabila menggunakan mekanisme ini, penyegerakan masa tidak memerlukan pengiraan kelewatan masa di sepanjang laluan yang dilalui oleh paket penyegerakan, seperti yang dilakukan dalam pertukaran asas. Itu. Mesej Delay_Req dan Delay_Resp tidak dihantar. Dalam kaedah ini, kelewatan antara jam induk dan hamba hanya dijumlahkan dalam medan pelarasan setiap mesej Sync atau Follow_Up.
Kelebihan lain ialah jam induk dibebaskan daripada keperluan untuk memproses mesej Delay_Req.
Mod pengendalian jam telus
Oleh itu, ini adalah contoh mudah. Sekarang anggap suis muncul pada laluan penyegerakan.
Jika anda menggunakan suis tanpa sokongan PTPv2, paket penyegerakan akan ditangguhkan pada suis lebih kurang 10 ΞΌs.
Suis yang menyokong PTPv2 dipanggil jam Lutsinar dalam terminologi IEEE 1588v2. Jam telus tidak disegerakkan daripada jam induk dan tidak mengambil bahagian dalam hierarki "Jam Induk - Jam Hamba", tetapi apabila menghantar mesej penyegerakan mereka ingat berapa lama mesej itu ditangguhkan oleh mereka. Ini membolehkan anda melaraskan kelewatan masa.
Jam lutsinar boleh beroperasi dalam dua mod:
- Hujung ke hujung.
- Rakan Sebaya.
Hujung ke Hujung (E2E)
Jam lutsinar E2E menyiarkan mesej Sync dan mesej Follow_Up yang disertakan pada semua port. Malah yang disekat oleh beberapa protokol (contohnya, RSTP).
Suis mengingati cap masa apabila paket Penyegerakan (Follow_Up) diterima pada port dan apabila ia dihantar dari port. Berdasarkan dua cap masa ini, masa yang diperlukan untuk suis memproses mesej dikira. Dalam standard, masa ini dipanggil masa kediaman.
Masa pemprosesan ditambahkan pada medan correctionField bagi mesej Segerak (jam satu langkah) atau Follow_Up (jam dua langkah).
Jam lutsinar E2E mengukur masa pemprosesan untuk mesej Sync dan Delay_Req yang melalui suis. Tetapi adalah penting untuk memahami bahawa kelewatan masa antara jam induk dan jam hamba dikira menggunakan mekanisme permintaan-tindak balas kelewatan. Jika jam induk berubah atau laluan dari jam induk ke jam hamba berubah, kelewatan diukur sekali lagi. Ini meningkatkan masa peralihan sekiranya berlaku perubahan rangkaian.
Jam lutsinar P2P, selain mengukur masa yang diperlukan untuk suis memproses mesej, mengukur kelewatan pada pautan data ke jiran terdekatnya menggunakan mekanisme kependaman jiran.
Latensi diukur pada setiap pautan dalam kedua-dua arah, termasuk pautan yang disekat oleh beberapa protokol (seperti RSTP). Ini membolehkan anda mengira dengan segera kelewatan baharu dalam laluan penyegerakan jika jam grandmaster atau topologi rangkaian berubah.
Masa pemprosesan mesej melalui suis dan kependaman terkumpul apabila menghantar mesej Sync atau Follow_Up.
Jenis sokongan PTPv2 oleh suis
Suis boleh menyokong PTPv2:
- secara pemrograman;
- perkakasan.
Apabila melaksanakan protokol PTPv2 dalam perisian, suis meminta cap masa daripada perisian tegar. Masalahnya ialah perisian tegar berfungsi secara kitaran, dan anda perlu menunggu sehingga ia menamatkan kitaran semasa, mengambil permintaan untuk pemprosesan dan mengeluarkan cap masa selepas kitaran seterusnya. Ini juga akan mengambil masa, dan kami akan mendapat kelewatan, walaupun tidak sepenting tanpa sokongan perisian untuk PTPv2.
Hanya sokongan perkakasan untuk PTPv2 membolehkan anda mengekalkan ketepatan yang diperlukan. Dalam kes ini, setem masa dikeluarkan oleh ASIC khas, yang dipasang pada port.
Format Mesej
Semua mesej PTP terdiri daripada medan berikut:
- Pengepala β 34 bait.
- Badan β saiz bergantung pada jenis mesej.
- Akhiran adalah pilihan.
Header
Medan Pengepala adalah sama untuk semua mesej PTP. Saiznya ialah 34 bait.
Format medan pengepala:
jenis mesej β mengandungi jenis mesej yang dihantar, contohnya Sync, Delay_Req, PDelay_Req, dsb.
panjang mesej β mengandungi saiz penuh mesej PTP, termasuk pengepala, badan dan akhiran (tetapi tidak termasuk bait padding).
domainNumber β menentukan domain PTP yang mana mesej itu dimiliki.
ΠΠΎΠΌΠ΅Π½ - ini ialah beberapa jam berbeza yang dikumpul dalam satu kumpulan logik dan disegerakkan daripada satu jam induk, tetapi tidak semestinya disegerakkan dengan jam milik domain yang berbeza.
bendera β Medan ini mengandungi pelbagai bendera untuk mengenal pasti status mesej.
correctionField β mengandungi masa tunda dalam nanosaat. Masa tunda termasuk kelewatan semasa menghantar melalui jam lutsinar, serta kelewatan apabila menghantar melalui saluran apabila menggunakan mod Peer-to-Peer.
sourcePortIdentity β medan ini mengandungi maklumat tentang port mana mesej ini asalnya dihantar.
sequenceID β mengandungi nombor pengenalan untuk mesej individu.
ControlField β medan artifak =) Ia kekal daripada versi pertama standard dan mengandungi maklumat tentang jenis mesej ini. Pada asasnya sama seperti messageType, tetapi dengan pilihan yang lebih sedikit.
logMessageInterval β medan ini ditentukan oleh jenis mesej.
Badan
Seperti yang dibincangkan di atas, terdapat beberapa jenis mesej. Jenis-jenis ini diterangkan di bawah:
Mesej pengumuman
Mesej Announce digunakan untuk "memberitahu" jam lain dalam domain yang sama tentang parameternya. Mesej ini membolehkan anda menyediakan hierarki Jam Induk - Jam Hamba.
Segerakkan mesej
Mesej Penyegerakan dihantar oleh jam induk dan mengandungi masa jam induk pada masa mesej Penyegerakan dijana. Jika jam induk adalah dua peringkat, maka cap masa dalam mesej Sync akan ditetapkan kepada 0 dan cap masa semasa akan dihantar dalam mesej Follow_Up yang berkaitan. Mesej Penyegerakan digunakan untuk kedua-dua mekanisme pengukuran kependaman.
Mesej dihantar menggunakan Multicast. Secara pilihan anda boleh menggunakan Unicast.
Mesej Delay_Req
Format mesej Delay_Req adalah sama dengan mesej Sync. Jam hamba menghantar Delay_Req. Ia mengandungi masa Delay_Req dihantar oleh jam hamba. Mesej ini hanya digunakan untuk mekanisme permintaan-tindak balas kelewatan.
Mesej dihantar menggunakan Multicast. Secara pilihan anda boleh menggunakan Unicast.
Mesej Follow_Up
Mesej Follow_Up secara pilihan dihantar oleh jam induk dan mengandungi masa penghantaran Segerakkan mesej tuan. Hanya jam induk dua peringkat menghantar mesej Follow_Up.
Mesej Follow_Up digunakan untuk kedua-dua mekanisme pengukuran kependaman.
Mesej dihantar menggunakan Multicast. Secara pilihan anda boleh menggunakan Unicast.
Mesej Delay_Resp
Mesej Delay_Resp dihantar oleh jam induk. Ia mengandungi masa apabila Delay_Req diterima oleh jam induk. Mesej ini hanya digunakan untuk mekanisme permintaan-tindak balas kelewatan.
Mesej dihantar menggunakan Multicast. Secara pilihan anda boleh menggunakan Unicast.
Mesej Pdelay_Req
Mesej Pdelay_Req dihantar oleh peranti yang meminta penangguhan. Ia mengandungi masa mesej dihantar dari port peranti ini. Pdelay_Req hanya digunakan untuk mekanisme pengukuran kelewatan jiran.
Mesej Pdelay_Resp
Mesej Pdelay_Resp dihantar oleh peranti yang telah menerima permintaan penangguhan. Ia mengandungi masa mesej Pdelay_Req diterima oleh peranti ini. Mesej Pdelay_Resp hanya digunakan untuk mekanisme pengukuran kelewatan jiran.
Mesej Pdelay_Resp_Follow_Up
Mesej Pdelay_Resp_Follow_Up dihantar secara pilihan oleh peranti yang telah menerima permintaan penangguhan. Ia mengandungi masa mesej Pdelay_Req diterima oleh peranti ini. Mesej Pdelay_Resp_Follow_Up dihantar hanya oleh jam induk dua peringkat.
Mesej ini juga boleh digunakan untuk masa pelaksanaan dan bukannya cap waktu. Masa pelaksanaan ialah masa dari saat Pdelay-Req diterima sehingga Pdelay_Resp dihantar.
Pdelay_Resp_Follow_Up digunakan hanya untuk mekanisme pengukuran kelewatan jiran.
Mesej Pengurusan
Mesej kawalan PTP diperlukan untuk memindahkan maklumat antara satu atau lebih jam dan nod kawalan.
Pindah ke LV
Mesej PTP boleh dihantar pada dua peringkat:
- Rangkaian β sebagai sebahagian daripada data IP.
- Saluran β sebagai sebahagian daripada bingkai Ethernet.
Penghantaran mesej PTP melalui UDP melalui IP melalui Ethernet
PTP melalui UDP melalui Ethernet
Profil
PTP mempunyai banyak parameter fleksibel yang perlu dikonfigurasikan. Sebagai contoh:
- Pilihan BMCA.
- Mekanisme pengukuran latensi.
- Selang dan nilai awal semua parameter boleh dikonfigurasikan, dsb.
Dan walaupun fakta bahawa kami sebelum ini mengatakan bahawa peranti PTPv2 serasi antara satu sama lain, ini tidak benar. Peranti mesti mempunyai tetapan yang sama untuk berkomunikasi.
Itulah sebabnya terdapat apa yang dipanggil profil PTPv2. Profil ialah kumpulan tetapan yang dikonfigurasikan dan sekatan protokol yang ditentukan supaya penyegerakan masa boleh dilaksanakan untuk aplikasi tertentu.
Piawaian IEEE 1588v2 sendiri menerangkan hanya satu profil - "Profil Lalai". Semua profil lain dicipta dan diterangkan oleh pelbagai organisasi dan persatuan.
Contohnya, Profil Kuasa, atau Profil Kuasa PTPv2, telah dicipta oleh Jawatankuasa Penyampaian Sistem Kuasa dan Jawatankuasa Pencawang Persatuan Tenaga dan Tenaga IEEE. Profil itu sendiri dipanggil IEEE C37.238-2011.
Profil tersebut menerangkan bahawa PTP boleh dipindahkan:
- Hanya melalui rangkaian L2 (iaitu Ethernet, HSR, PRP, bukan IP).
- Mesej dihantar hanya melalui siaran Multicast.
- Mekanisme pengukuran kelewatan rakan sebaya digunakan sebagai mekanisme pengukuran kelewatan.
Domain lalai ialah 0, domain yang disyorkan ialah 93.
Falsafah reka bentuk C37.238-2011 adalah untuk mengurangkan bilangan ciri pilihan dan mengekalkan hanya fungsi yang diperlukan untuk interaksi yang boleh dipercayai antara peranti dan peningkatan kestabilan sistem.
Juga, kekerapan penghantaran mesej ditentukan:
Malah, hanya satu parameter tersedia untuk pemilihan - jenis jam induk (peringkat tunggal atau dua peringkat).
Ketepatan hendaklah tidak lebih daripada 1 ΞΌs. Dalam erti kata lain, satu laluan penyegerakan boleh mengandungi maksimum 15 jam lutsinar atau tiga jam sempadan.
Sumber: www.habr.com