pengenalan
Konsep pembangunan “Gardu Digital” pada industri tenaga listrik memerlukan sinkronisasi dengan akurasi 1 μs. Transaksi keuangan juga memerlukan akurasi mikrodetik. Dalam aplikasi ini, akurasi waktu NTP tidak lagi mencukupi.
Protokol sinkronisasi PTPv2, yang dijelaskan oleh standar IEEE 1588v2, memungkinkan akurasi sinkronisasi beberapa puluh nanodetik. PTPv2 memungkinkan Anda mengirim paket sinkronisasi melalui jaringan L2 dan L3.
Area utama di mana PTPv2 digunakan adalah:
- energi;
- peralatan kontrol dan pengukuran;
- kompleks industri militer;
- telekomunikasi;
- sektor keuangan.
Posting ini menjelaskan cara kerja protokol sinkronisasi PTPv2.
Kami memiliki lebih banyak pengalaman di industri dan sering melihat protokol ini dalam aplikasi energi. Oleh karena itu, kami akan melakukan peninjauan dengan hati-hati .
Mengapa ini perlu?
Saat ini, STO 34.01-21-004-2019 dari PJSC Rosseti dan STO 56947007-29.240.10.302-2020 dari PJSC FGC UES memuat persyaratan untuk mengatur bus proses dengan sinkronisasi waktu melalui PTPv2.
Hal ini disebabkan oleh fakta bahwa terminal proteksi relai dan alat pengukur dihubungkan ke bus proses, yang mentransmisikan nilai arus dan tegangan sesaat melalui bus proses, menggunakan apa yang disebut aliran SV (aliran multicast).
Terminal proteksi relai menggunakan nilai-nilai ini untuk menerapkan proteksi teluk. Jika keakuratan pengukuran waktu kecil, maka beberapa proteksi mungkin beroperasi secara salah.
Misalnya, pertahanan selektivitas absolut mungkin menjadi korban sinkronisasi waktu yang “lemah”. Seringkali logika pertahanan tersebut didasarkan pada perbandingan dua kuantitas. Jika nilainya berbeda dengan nilai yang cukup besar, maka perlindungan akan terpicu. Jika nilai-nilai tersebut diukur dengan ketelitian waktu 1 ms, maka diperoleh perbedaan yang besar dimana nilai-nilai tersebut sebenarnya normal jika diukur dengan ketelitian 1 s.
Versi PTP
Protokol PTP awalnya dijelaskan pada tahun 2002 dalam standar IEEE 1588-2002 dan disebut “Standar untuk Protokol Sinkronisasi Jam Presisi untuk Sistem Pengukuran dan Kontrol Jaringan.” Pada tahun 2008, standar IEEE 1588-2008 yang diperbarui dirilis, yang menjelaskan PTP Versi 2. Versi protokol ini meningkatkan akurasi dan stabilitas, tetapi tidak mempertahankan kompatibilitas dengan versi protokol pertama. Selain itu, pada tahun 2019, versi standar IEEE 1588-2019 dirilis, menjelaskan PTP v2.1. Versi ini menambahkan sedikit perbaikan pada PTPv2 dan kompatibel dengan PTPv2.
Dengan kata lain, kami memiliki gambar berikut dengan versinya:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
-
Tidak kompatibel
Tidak kompatibel
PTPv2 (IEEE 1588-2008)
Tidak kompatibel
-
Kompatibel
PTPv2.1 (IEEE 1588-2019)
Tidak kompatibel
Kompatibel
-
Tapi, seperti biasa, ada perbedaannya.
Ketidakcocokan antara PTPv1 dan PTPv2 berarti perangkat yang mendukung PTPv1 tidak akan dapat melakukan sinkronisasi dengan jam akurat yang berjalan di PTPv2. Mereka menggunakan format pesan yang berbeda untuk melakukan sinkronisasi.
Namun masih dimungkinkan untuk menggabungkan perangkat dengan PTPv1 dan perangkat dengan PTPv2 di jaringan yang sama. Untuk mencapai hal ini, beberapa produsen mengizinkan Anda memilih versi protokol pada port jam edge. Artinya, jam batas dapat melakukan sinkronisasi menggunakan PTPv2 dan tetap menyinkronkan jam lain yang terhubung dengannya menggunakan PTPv1 dan PTPv2.
Perangkat PTP. Apa itu dan apa perbedaannya?
Standar IEEE 1588v2 menjelaskan beberapa jenis perangkat. Semuanya ditampilkan dalam tabel.
Perangkat berkomunikasi satu sama lain melalui LAN menggunakan PTP.
Perangkat PTP disebut jam. Semua jam tangan mengambil waktu yang tepat dari jam tangan grandmaster.
Ada 5 jenis jam tangan:
Jam guru besar
Sumber utama waktu yang akurat. Seringkali dilengkapi dengan antarmuka untuk menghubungkan GPS.
Jam Biasa
Perangkat port tunggal yang dapat menjadi master (master clock) atau slave (slave clock)
Jam utama (master)
Mereka adalah sumber waktu yang tepat dimana jam-jam lain disinkronkan
Jam budak
Perangkat akhir yang disinkronkan dari jam master
Jam Batas
Perangkat dengan banyak port yang dapat menjadi master atau slave.
Artinya, jam ini dapat melakukan sinkronisasi dari jam master superior dan menyinkronkan jam budak inferior.
Jam Transparan ujung ke ujung
Perangkat dengan banyak port yang bukan merupakan jam master atau jam budak. Ini mentransmisikan data PTP antara dua jam tangan.
Saat mengirimkan data, jam transparan mengoreksi semua pesan PTP.
Koreksi terjadi dengan menambahkan waktu tunda pada perangkat ini ke bidang koreksi di header pesan yang dikirimkan.
Jam Transparan Peer-to-Peer
Perangkat dengan banyak port yang bukan merupakan jam master atau jam budak.
Ini mentransmisikan data PTP antara dua jam tangan.
Saat mengirimkan data, jam transparan mengoreksi semua pesan PTP Sinkronisasi dan Tindak Lanjut (lebih lanjut tentangnya di bawah).
Koreksi dicapai dengan menambahkan ke bidang koreksi paket yang dikirimkan penundaan pada perangkat transmisi dan penundaan pada saluran transmisi data.
Node Manajemen
Perangkat yang mengonfigurasi dan mendiagnosis jam tangan lain
Jam master dan slave disinkronkan menggunakan stempel waktu dalam pesan PTP. Ada dua jenis pesan dalam protokol PTP:
- Pesan Peristiwa adalah pesan tersinkronisasi yang melibatkan pembuatan stempel waktu pada saat pesan dikirim dan pada saat pesan diterima.
- Pesan Umum - Pesan-pesan ini tidak memerlukan stempel waktu, namun mungkin berisi stempel waktu untuk pesan terkait
Pesan Acara
Pesan Umum
Sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Mengumumkan
Menindaklanjuti
Penundaan_Resp
Pdelay_Resp_Follow_Up
Pengelolaan
Pemberian sinyal
Semua jenis pesan akan dibahas lebih detail di bawah ini.
Masalah sinkronisasi dasar
Ketika paket sinkronisasi ditransmisikan melalui jaringan lokal, paket tersebut tertunda pada switch dan pada link data. Peralihan apa pun akan menghasilkan penundaan sekitar 10 mikrodetik, yang tidak dapat diterima untuk PTPv2. Bagaimanapun, kita perlu mencapai akurasi 1 μs pada perangkat akhir. (Ini jika kita berbicara tentang energi. Penerapan lain mungkin memerlukan akurasi yang lebih tinggi.)
IEEE 1588v2 menjelaskan beberapa algoritma operasi yang memungkinkan Anda mencatat waktu tunda dan memperbaikinya.
Algoritma kerja
Selama operasi normal, protokol beroperasi dalam dua fase.
- Fase 1 - menetapkan hierarki “Jam Utama – Jam Budak”.
- Fase 2 - sinkronisasi jam menggunakan mekanisme End-to-End atau Peer-to-Peer.
Fase 1 - Membangun Hirarki Tuan-Budak
Setiap port pada jam biasa atau jam tepi memiliki sejumlah status tertentu (jam budak dan jam master). Standar tersebut menjelaskan algoritma transisi antara keadaan-keadaan ini. Dalam pemrograman, algoritma seperti itu disebut mesin keadaan terbatas atau state machine (lebih jelasnya di Wiki).
Mesin negara ini menggunakan Algoritma Jam Master Terbaik (BMCA) untuk mengatur master saat menghubungkan dua jam.
Algoritme ini memungkinkan jam tangan mengambil alih tanggung jawab jam tangan grandmaster ketika jam tangan grandmaster upstream kehilangan sinyal GPS, offline, dll.
Transisi keadaan menurut BMCA dirangkum dalam diagram berikut:
Informasi tentang jam tangan di ujung lain “kabel” dikirim dalam pesan khusus (Umumkan pesan). Setelah informasi ini diterima, algoritma mesin negara dijalankan dan perbandingan dibuat untuk melihat jam mana yang lebih baik. Port pada jam tangan terbaik menjadi jam tangan master.
Hierarki sederhana ditunjukkan pada diagram di bawah ini. Jalur 1, 2, 3, 4, 5 mungkin berisi jam Transparan, tetapi tidak berpartisipasi dalam menetapkan hierarki Jam Master - Jam Budak.
Fase 2 - Sinkronisasi jam reguler dan edge
Segera setelah menetapkan hierarki “Jam Utama – Jam Budak”, fase sinkronisasi jam biasa dan jam batas dimulai.
Untuk melakukan sinkronisasi, jam master mengirimkan pesan yang berisi stempel waktu ke jam budak.
Jam utama dapat berupa:
- satu tahap;
- dua tahap.
Jam satu tahap mengirim satu pesan Sinkronisasi untuk disinkronkan.
Jam dua tahap menggunakan dua pesan untuk sinkronisasi - Sinkronisasi dan Follow_Up.
Dua mekanisme dapat digunakan untuk fase sinkronisasi:
- Menunda mekanisme permintaan-respons.
- Mekanisme pengukuran penundaan rekan.
Pertama, mari kita lihat mekanisme ini dalam kasus paling sederhana - ketika jam tangan transparan tidak digunakan.
Menunda mekanisme permintaan-respons
Mekanismenya melibatkan dua langkah:
- Mengukur penundaan transmisi pesan antara jam master dan jam budak. Dilakukan dengan menggunakan mekanisme penundaan permintaan-respons.
- Koreksi pergeseran waktu yang tepat dilakukan.
Pengukuran latensi
t1 – Waktu pengiriman pesan Sinkronisasi berdasarkan jam master; t2 – Waktu penerimaan pesan Sinkronisasi oleh jam pendukung; t3 – Waktu pengiriman permintaan penundaan (Delay_Req) oleh jam budak; t4 – Waktu penerimaan Delay_Req berdasarkan jam master.
Ketika jam budak mengetahui waktu t1, t2, t3, dan t4, jam tersebut dapat menghitung penundaan rata-rata saat mentransmisikan pesan sinkronisasi (tmpd). Ini dihitung sebagai berikut:
Saat mengirimkan pesan Sync dan Follow_Up, waktu tunda dari master ke slave dihitung - t-ms.
Saat mengirimkan pesan Delay_Req dan Delay_Resp, waktu tunda dari slave ke master dihitung - t-sm.
Jika terjadi asimetri antara kedua nilai ini, maka akan muncul kesalahan dalam mengoreksi penyimpangan waktu yang tepat. Kesalahan tersebut disebabkan karena tundaan yang dihitung merupakan rata-rata tundaan t-ms dan t-sm. Jika penundaannya tidak sama satu sama lain, maka kami tidak akan menyesuaikan waktu secara akurat.
Koreksi pergeseran waktu
Setelah penundaan antara jam master dan jam budak diketahui, jam budak melakukan koreksi waktu.
Jam budak menggunakan pesan Sinkronisasi dan pesan Follow_Up opsional untuk menghitung offset waktu yang tepat saat mentransmisikan paket dari jam master ke jam budak. Pergeseran dihitung menggunakan rumus berikut:
Mekanisme pengukuran penundaan rekan
Mekanisme ini juga menggunakan dua langkah untuk sinkronisasi:
- Perangkat mengukur waktu tunda ke semua tetangga melalui semua port. Untuk melakukan hal ini mereka menggunakan mekanisme penundaan rekan.
- Koreksi pergeseran waktu yang tepat.
Mengukur latensi antar perangkat yang mendukung mode Peer-to-Peer
Latensi antar port yang mendukung mekanisme peer-to-peer diukur menggunakan pesan berikut:
Ketika port 1 mengetahui waktu t1, t2, t3 dan t4, port tersebut dapat menghitung penundaan rata-rata (tmld). Itu dihitung menggunakan rumus berikut:
Port kemudian menggunakan nilai ini saat menghitung bidang penyesuaian untuk setiap pesan Sinkronisasi atau pesan Follow_Up opsional yang melewati perangkat.
Penundaan total akan sama dengan jumlah penundaan selama transmisi melalui perangkat ini, penundaan rata-rata selama transmisi melalui saluran data, dan penundaan yang sudah terdapat dalam pesan ini, yang diaktifkan pada perangkat upstream.
Pesan Pdelay_Req, Pdelay_Resp dan opsional Pdelay_Resp_Follow_Up memungkinkan Anda mendapatkan penundaan dari master ke slave dan dari slave ke master (melingkar).
Setiap asimetri antara kedua nilai ini akan menimbulkan kesalahan koreksi offset waktu.
Menyesuaikan pergeseran waktu yang tepat
Jam budak menggunakan pesan Sinkronisasi dan pesan Follow_Up opsional untuk menghitung offset waktu yang tepat saat mentransmisikan paket dari jam master ke jam budak. Pergeseran dihitung menggunakan rumus berikut:
Keuntungan penyesuaian mekanisme peer-to-peer - waktu tunda setiap pesan Sync atau Follow_Up dihitung saat dikirimkan dalam jaringan. Oleh karena itu, mengubah jalur transmisi tidak akan mempengaruhi keakuratan penyesuaian.
Saat menggunakan mekanisme ini, sinkronisasi waktu tidak memerlukan penghitungan waktu tunda sepanjang jalur yang dilalui oleh paket sinkronisasi, seperti yang dilakukan pada pertukaran dasar. Itu. Pesan Delay_Req dan Delay_Resp tidak terkirim. Dalam metode ini, penundaan antara jam master dan jam cadangan hanya dijumlahkan dalam bidang penyesuaian setiap pesan Sync atau Follow_Up.
Keuntungan lainnya adalah jam master tidak perlu lagi memproses pesan Delay_Req.
Mode pengoperasian jam transparan
Oleh karena itu, ini adalah contoh sederhana. Sekarang anggaplah saklar muncul di jalur sinkronisasi.
Jika Anda menggunakan sakelar tanpa dukungan PTPv2, paket sinkronisasi akan tertunda pada sakelar sekitar 10 s.
Switch yang mendukung PTPv2 disebut jam Transparan dalam terminologi IEEE 1588v2. Jam transparan tidak disinkronkan dari jam master dan tidak berpartisipasi dalam hierarki "Jam Master - Jam Budak", tetapi saat mengirimkan pesan sinkronisasi, jam tersebut mengingat berapa lama pesan tersebut ditunda. Ini memungkinkan Anda untuk menyesuaikan waktu tunda.
Jam transparan dapat beroperasi dalam dua mode:
- Ujung ke ujung.
- Rekan-ke-Rekan.
Ujung-ke-Ujung (E2E)
Jam transparan E2E menyiarkan pesan Sinkronisasi dan pesan Follow_Up yang menyertainya di semua port. Bahkan yang diblokir oleh protokol tertentu (misalnya RSTP).
Switch mengingat stempel waktu saat paket Sinkronisasi (Follow_Up) diterima di port dan saat dikirim dari port. Berdasarkan dua stempel waktu ini, waktu yang diperlukan switch untuk memproses pesan dihitung. Dalam standar waktu ini disebut waktu tinggal.
Waktu pemrosesan ditambahkan ke bidang koreksiField pada pesan Sinkronisasi (jam satu langkah) atau Follow_Up (jam dua langkah).
Jam transparan E2E mengukur waktu pemrosesan untuk pesan Sync dan Delay_Req yang melewati sakelar. Namun penting untuk dipahami bahwa waktu tunda antara jam master dan jam budak dihitung menggunakan mekanisme penundaan permintaan-respons. Jika jam master berubah atau jalur dari jam master ke jam budak berubah, penundaan diukur kembali. Hal ini meningkatkan waktu transisi jika terjadi perubahan jaringan.
Jam transparan P2P, selain mengukur waktu yang dibutuhkan switch untuk memproses pesan, juga mengukur penundaan pada link data ke tetangga terdekatnya menggunakan mekanisme latensi tetangga.
Latensi diukur pada setiap link di kedua arah, termasuk link yang diblokir oleh beberapa protokol (seperti RSTP). Hal ini memungkinkan Anda untuk segera menghitung penundaan baru di jalur sinkronisasi jika jam grandmaster atau topologi jaringan berubah.
Waktu pemrosesan pesan berdasarkan sakelar dan latensi diakumulasikan saat mengirim pesan Sinkronisasi atau Tindak Lanjut.
Jenis dukungan PTPv2 berdasarkan sakelar
Switch dapat mendukung PTPv2:
- secara terprogram;
- perangkat keras.
Saat menerapkan protokol PTPv2 dalam perangkat lunak, sakelar meminta stempel waktu dari firmware. Masalahnya adalah firmware bekerja secara siklis, dan Anda harus menunggu hingga siklus saat ini selesai, menerima permintaan pemrosesan, dan mengeluarkan stempel waktu setelah siklus berikutnya. Ini juga akan memakan waktu, dan kita akan mendapatkan penundaan, meskipun tidak sebesar tanpa dukungan perangkat lunak untuk PTPv2.
Hanya dukungan perangkat keras untuk PTPv2 yang memungkinkan Anda mempertahankan akurasi yang diperlukan. Dalam hal ini, cap waktu dikeluarkan oleh ASIC khusus, yang dipasang di port.
Format Pesan
Semua pesan PTP terdiri dari bidang berikut:
- Tajuk – 34 byte.
- Isi – ukuran tergantung pada jenis pesan.
- Akhiran adalah opsional.
Header
Bidang Header sama untuk semua pesan PTP. Ukurannya 34 byte.
Format bidang tajuk:
jenis pesan – berisi jenis pesan yang dikirimkan, misalnya Sync, Delay_Req, PDelay_Req, dll.
Panjang pesan – berisi ukuran penuh pesan PTP, termasuk header, body, dan suffix (tetapi tidak termasuk padding byte).
nomor domain – menentukan di domain PTP mana pesan tersebut berada.
Домен - ini adalah beberapa jam berbeda yang dikumpulkan dalam satu grup logis dan disinkronkan dari satu jam master, tetapi tidak harus disinkronkan dengan jam milik domain berbeda.
bendera – Bidang ini berisi berbagai tanda untuk mengidentifikasi status pesan.
bidang koreksi – berisi waktu tunda dalam nanodetik. Waktu tunda mencakup penundaan saat transmisi melalui jam transparan, serta penundaan saat transmisi melalui saluran saat menggunakan mode Peer-to-Peer.
sourcePortIdentity – bidang ini berisi informasi tentang port mana pesan ini awalnya dikirim.
sequenceID – berisi nomor identifikasi untuk pesan individual.
bidang kontrol – bidang artefak =) Tetap dari standar versi pertama dan berisi informasi tentang jenis pesan ini. Pada dasarnya sama dengan messageType, tetapi dengan opsi yang lebih sedikit.
logMessageInterval – bidang ini ditentukan oleh jenis pesan.
Tubuh
Seperti dibahas di atas, ada beberapa jenis pesan. Jenis-jenis ini dijelaskan di bawah ini:
Pesan pengumuman
Pesan Pengumuman digunakan untuk “memberi tahu” jam lain dalam domain yang sama tentang parameternya. Pesan ini memungkinkan Anda untuk mengatur hierarki Jam Master - Jam Budak.
Sinkronkan pesan
Pesan Sinkronisasi dikirim oleh jam master dan berisi waktu jam master pada saat pesan Sinkronisasi dibuat. Jika jam master adalah dua tahap, maka stempel waktu dalam pesan Sinkronisasi akan diatur ke 0, dan stempel waktu saat ini akan dikirim dalam pesan Follow_Up terkait. Pesan Sinkronisasi digunakan untuk kedua mekanisme pengukuran latensi.
Pesan ditransmisikan menggunakan Multicast. Secara opsional, Anda dapat menggunakan Unicast.
Pesan Delay_Req
Format pesan Delay_Req identik dengan pesan Sync. Jam budak mengirimkan Delay_Req. Ini berisi waktu Delay_Req dikirim oleh jam budak. Pesan ini hanya digunakan untuk mekanisme penundaan permintaan-respons.
Pesan ditransmisikan menggunakan Multicast. Secara opsional, Anda dapat menggunakan Unicast.
Pesan Tindak Lanjut
Pesan Follow_Up secara opsional dikirim oleh jam master dan berisi waktu pengiriman Sinkronkan pesan menguasai. Hanya jam master dua tahap yang mengirimkan pesan Follow_Up.
Pesan Follow_Up digunakan untuk kedua mekanisme pengukuran latensi.
Pesan ditransmisikan menggunakan Multicast. Secara opsional, Anda dapat menggunakan Unicast.
Pesan Delay_Resp
Pesan Delay_Resp dikirim oleh jam master. Ini berisi waktu ketika Delay_Req diterima oleh jam master. Pesan ini hanya digunakan untuk mekanisme penundaan permintaan-respons.
Pesan ditransmisikan menggunakan Multicast. Secara opsional, Anda dapat menggunakan Unicast.
Pesan Pdelay_Req
Pesan Pdelay_Req dikirim oleh perangkat yang meminta penundaan. Ini berisi waktu pengiriman pesan dari port perangkat ini. Pdelay_Req hanya digunakan untuk mekanisme pengukuran penundaan tetangga.
Pesan Pdelay_Resp
Pesan Pdelay_Resp dikirim oleh perangkat yang telah menerima permintaan penundaan. Ini berisi waktu pesan Pdelay_Req diterima oleh perangkat ini. Pesan Pdelay_Resp hanya digunakan untuk mekanisme pengukuran penundaan tetangga.
Pesan Pdelay_Resp_Follow_Up
Pesan Pdelay_Resp_Follow_Up secara opsional dikirim oleh perangkat yang telah menerima permintaan penundaan. Ini berisi waktu pesan Pdelay_Req diterima oleh perangkat ini. Pesan Pdelay_Resp_Follow_Up hanya dikirim oleh jam master dua tahap.
Pesan ini juga dapat digunakan untuk waktu eksekusi, bukan stempel waktu. Waktu eksekusi adalah waktu sejak Pdelay-Req diterima hingga Pdelay_Resp dikirimkan.
Pdelay_Resp_Follow_Up hanya digunakan untuk mekanisme pengukuran penundaan tetangga.
Pesan Manajemen
Pesan kontrol PTP diperlukan untuk mentransfer informasi antara satu atau lebih jam dan node kontrol.
Pindah ke LV
Pesan PTP dapat ditransmisikan pada dua tingkat:
- Jaringan – sebagai bagian dari data IP.
- Saluran – sebagai bagian dari bingkai Ethernet.
Transmisi pesan PTP melalui UDP melalui IP melalui Ethernet
PTP melalui UDP melalui Ethernet
Profil
PTP memiliki cukup banyak parameter fleksibel yang perlu dikonfigurasi. Misalnya:
- Opsi BMCA.
- Mekanisme pengukuran latensi.
- Interval dan nilai awal dari semua parameter yang dapat dikonfigurasi, dll.
Dan meskipun sebelumnya kami mengatakan bahwa perangkat PTPv2 kompatibel satu sama lain, hal ini tidak benar. Perangkat harus memiliki pengaturan yang sama agar dapat berkomunikasi.
Itu sebabnya ada yang disebut profil PTPv2. Profil adalah grup pengaturan yang dikonfigurasi dan batasan protokol yang ditentukan sehingga sinkronisasi waktu dapat diterapkan untuk aplikasi tertentu.
Standar IEEE 1588v2 sendiri hanya menjelaskan satu profil – “Profil Default”. Semua profil lainnya dibuat dan dijelaskan oleh berbagai organisasi dan asosiasi.
Misalnya, Profil Daya, atau Profil Daya PTPv2, dibuat oleh Komite Relai Sistem Tenaga dan Komite Gardu Induk dari IEEE Power and Energy Society. Profilnya sendiri disebut IEEE C37.238-2011.
Profil tersebut menjelaskan bahwa PTP dapat ditransfer:
- Hanya melalui jaringan L2 (yaitu Ethernet, HSR, PRP, non-IP).
- Pesan hanya dikirimkan melalui siaran Multicast.
- Mekanisme pengukuran peer delay digunakan sebagai mekanisme pengukuran penundaan.
Domain default adalah 0, domain yang direkomendasikan adalah 93.
Filosofi desain C37.238-2011 adalah mengurangi jumlah fitur opsional dan hanya mempertahankan fungsi yang diperlukan untuk interaksi yang andal antar perangkat dan meningkatkan stabilitas sistem.
Frekuensi pengiriman pesan juga ditentukan:
Faktanya, hanya satu parameter yang tersedia untuk dipilih - jenis jam master (satu tahap atau dua tahap).
Akurasinya tidak boleh lebih dari 1 s. Dengan kata lain, satu jalur sinkronisasi dapat memuat maksimal 15 jam transparan atau tiga jam batas.
Sumber: www.habr.com