ລາຍລະອຽດການຈັດຕັ້ງປະຕິບັດຂອງໂປຣໂຕຄໍການຊິ້ງຂໍ້ມູນເວລາ PTPv2

ການນໍາສະເຫນີ

ແນວຄວາມຄິດຂອງການກໍ່ສ້າງ "ສະຖານີຍ່ອຍດິຈິຕອນ" ໃນອຸດສາຫະກໍາພະລັງງານໄຟຟ້າຮຽກຮ້ອງໃຫ້ມີການ synchronization ກັບຄວາມຖືກຕ້ອງຂອງ 1 μs. ການເຮັດທຸລະກໍາທາງດ້ານການເງິນຍັງຕ້ອງການຄວາມຖືກຕ້ອງຂອງ microsecond. ໃນແອັບພລິເຄຊັນເຫຼົ່ານີ້, ຄວາມຖືກຕ້ອງຂອງເວລາ NTP ແມ່ນບໍ່ພຽງພໍອີກຕໍ່ໄປ.

ອະນຸສັນຍາການຊິ້ງຂໍ້ມູນ PTPv2, ອະທິບາຍໂດຍມາດຕະຖານ IEEE 1588v2, ອະນຸຍາດໃຫ້ມີຄວາມຖືກຕ້ອງຂອງການ synchronization ຫຼາຍສິບ nanoseconds. PTPv2 ອະນຸຍາດໃຫ້ທ່ານສົ່ງແພັກເກັດ synchronization ຜ່ານເຄືອຂ່າຍ L2 ແລະ L3.

ພື້ນທີ່ຕົ້ນຕໍທີ່ PTPv2 ຖືກນໍາໃຊ້ແມ່ນ:

• ພະລັງງານ;
• ອຸປະກອນຄວບຄຸມແລະວັດແທກ;
• ສະລັບສັບຊ້ອນການທະຫານ - ອຸດສາຫະກໍາ;
• ໂທລະຄົມ;
• ຂະ​ແໜງ​ການ​ເງິນ.

ໂພສນີ້ອະທິບາຍວ່າໂປຣໂຕຄໍການຊິ້ງຂໍ້ມູນ PTPv2 ເຮັດວຽກແນວໃດ.

ພວກເຮົາມີປະສົບການຫຼາຍຂຶ້ນໃນອຸດສາຫະກໍາແລະມັກຈະເຫັນໂປໂຕຄອນນີ້ໃນການນໍາໃຊ້ພະລັງງານ. ຕາມນັ້ນແລ້ວ, ພວກເຮົາຈະດໍາເນີນການກວດກາດ້ວຍຄວາມລະມັດລະວັງ ສໍາລັບພະລັງງານ.

ເປັນຫຍັງມັນຈຶ່ງຈໍາເປັນ?

ໃນປັດຈຸບັນ, STO 34.01-21-004-2019 ຂອງ PJSC Rosseti ແລະ STO 56947007-29.240.10.302-2020 ຂອງ PJSC FGC UES ປະກອບມີຂໍ້ກໍານົດສໍາລັບການຈັດຕັ້ງລົດເມຂະບວນການທີ່ມີເວລາ synchronization ຜ່ານ PTPv2.

ນີ້ແມ່ນເນື່ອງມາຈາກຄວາມຈິງທີ່ວ່າ terminals ປ້ອງກັນ relay ແລະອຸປະກອນການວັດແທກແມ່ນເຊື່ອມຕໍ່ກັບລົດເມຂະບວນການ, ເຊິ່ງສົ່ງຄ່າກະແສໄຟຟ້າທັນທີແລະແຮງດັນໂດຍຜ່ານລົດເມຂະບວນການ, ການນໍາໃຊ້ອັນທີ່ເອີ້ນວ່າ SV streams (multicast streams).

terminals ການປົກປ້ອງ Relay ໃຊ້ຄ່າເຫຼົ່ານີ້ເພື່ອປະຕິບັດການປົກປ້ອງ bay. ຖ້າຄວາມຖືກຕ້ອງຂອງການວັດແທກເວລາມີຂະຫນາດນ້ອຍ, ການປ້ອງກັນບາງຢ່າງອາດຈະດໍາເນີນການທີ່ບໍ່ຖືກຕ້ອງ.

ຕົວຢ່າງ, ການປ້ອງກັນການຄັດເລືອກຢ່າງແທ້ຈິງອາດຈະຕົກເປັນເຫຍື່ອຂອງການ synchronization ເວລາ "ອ່ອນແອ". ປົກກະຕິແລ້ວເຫດຜົນຂອງການປ້ອງກັນດັ່ງກ່າວແມ່ນອີງໃສ່ການປຽບທຽບສອງປະລິມານ. ຖ້າຄ່າຕ່າງໆ diverge ໂດຍມູນຄ່າຂະຫນາດໃຫຍ່ພຽງພໍ, ຫຼັງຈາກນັ້ນ, ການປົກປ້ອງຈະຖືກກະຕຸ້ນ. ຖ້າຄ່າເຫຼົ່ານີ້ຖືກວັດແທກດ້ວຍຄວາມຖືກຕ້ອງຂອງເວລາ 1 ms, ຫຼັງຈາກນັ້ນທ່ານສາມາດໄດ້ຮັບຄວາມແຕກຕ່າງທີ່ໃຫຍ່ຫຼວງທີ່ຄ່າຕົວຈິງແມ່ນປົກກະຕິຖ້າຖືກວັດແທກດ້ວຍຄວາມຖືກຕ້ອງຂອງ 1 μs.

ລຸ້ນ PTP

ພິທີການ PTP ໄດ້ຖືກອະທິບາຍໃນເບື້ອງຕົ້ນໃນປີ 2002 ໃນມາດຕະຖານ IEEE 1588-2002 ແລະຖືກເອີ້ນວ່າ "ມາດຕະຖານສໍາລັບພິທີການຊິງໂຄຣໄນໂມງທີ່ມີຄວາມຊັດເຈນສໍາລັບລະບົບການວັດແທກ ແລະການຄວບຄຸມເຄືອຂ່າຍ." ໃນປີ 2008, ມາດຕະຖານ IEEE 1588-2008 ສະບັບປັບປຸງໄດ້ຖືກປ່ອຍອອກມາ, ເຊິ່ງອະທິບາຍເຖິງ PTP ເວີຊັ່ນ 2. ໂປຣໂຕຄໍລຸ້ນນີ້ປັບປຸງຄວາມຖືກຕ້ອງ ແລະຄວາມໝັ້ນຄົງ, ແຕ່ບໍ່ໄດ້ຮັກສາຄວາມເຂົ້າກັນໄດ້ກັບລຸ້ນທຳອິດຂອງໂປຣໂຕຄໍ. ນອກຈາກນີ້, ໃນປີ 2019, ສະບັບຂອງມາດຕະຖານ IEEE 1588-2019 ໄດ້ຖືກປ່ອຍອອກມາ, ອະທິບາຍ PTP v2.1. ລຸ້ນນີ້ເພີ່ມການປັບປຸງເລັກນ້ອຍໃຫ້ກັບ PTPv2 ແລະເປັນແບບກັບຫຼັງເຂົ້າກັນໄດ້ກັບ PTPv2.

ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ພວກເຮົາມີຮູບພາບຕໍ່ໄປນີ້ກັບສະບັບ:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

-
ບໍ່ເຂົ້າກັນໄດ້

ບໍ່ເຂົ້າກັນໄດ້

PTPv2 (IEEE 1588-2008)

ບໍ່ເຂົ້າກັນໄດ້

-
ເຂົ້າກັນໄດ້

PTPv2.1 (IEEE 1588-2019)

ບໍ່ເຂົ້າກັນໄດ້

ເຂົ້າກັນໄດ້

-

ແຕ່, ຕາມສະເຫມີ, ມີ nuances.

ຄວາມບໍ່ເຂົ້າກັນລະຫວ່າງ PTPv1 ແລະ PTPv2 ຫມາຍຄວາມວ່າອຸປະກອນທີ່ເປີດໃຊ້ PTPv1 ຈະບໍ່ສາມາດ synchronize ກັບໂມງທີ່ຖືກຕ້ອງທີ່ແລ່ນຢູ່ໃນ PTPv2. ພວກເຂົາໃຊ້ຮູບແບບຂໍ້ຄວາມທີ່ແຕກຕ່າງກັນເພື່ອ synchronize.

ແຕ່ມັນຍັງສາມາດສົມທົບອຸປະກອນກັບ PTPv1 ແລະອຸປະກອນທີ່ມີ PTPv2 ໃນເຄືອຂ່າຍດຽວກັນ. ເພື່ອບັນລຸສິ່ງດັ່ງກ່າວ, ຜູ້ຜະລິດບາງຄົນອະນຸຍາດໃຫ້ທ່ານເລືອກສະບັບຂອງໂປໂຕຄອນໃນພອດໂມງຂອບ. ນັ້ນແມ່ນ, ໂມງເຂດແດນສາມາດ synchronize ໂດຍໃຊ້ PTPv2 ແລະຍັງ synchronize ໂມງອື່ນໆທີ່ເຊື່ອມຕໍ່ກັບມັນໂດຍໃຊ້ທັງ PTPv1 ແລະ PTPv2.

ອຸປະກອນ PTP. ພວກເຂົາແມ່ນຫຍັງແລະພວກເຂົາແຕກຕ່າງກັນແນວໃດ?

ມາດຕະຖານ IEEE 1588v2 ອະທິບາຍອຸປະກອນຫຼາຍປະເພດ. ທັງຫມົດຂອງພວກເຂົາແມ່ນສະແດງຢູ່ໃນຕາຕະລາງ.

ອຸປະກອນຕິດຕໍ່ສື່ສານເຊິ່ງກັນແລະກັນຜ່ານ LAN ໂດຍໃຊ້ PTP.

ອຸປະກອນ PTP ເອີ້ນວ່າໂມງ. ໂມງທັງຫມົດໃຊ້ເວລາທີ່ແນ່ນອນຈາກໂມງ grandmaster.

ໂມງມີ ​​5 ປະເພດຄື:

ໂມງໃຫຍ່

ແຫຼ່ງຕົ້ນຕໍຂອງເວລາທີ່ຖືກຕ້ອງ. ມັກຈະມີການໂຕ້ຕອບສໍາລັບການເຊື່ອມຕໍ່ GPS.

ໂມງທຳມະດາ

ອຸ​ປະ​ກອນ​ພອດ​ດຽວ​ທີ່​ສາ​ມາດ​ເປັນ​ແມ່​ບົດ (ໂມງ​ຕົ້ນ​ສະ​ບັບ​) ຫຼື slave (ໂມງ​ສໍາ​ລອງ​)

ໂມງແມ່ບົດ (ແມ່ບົດ)

ພວກມັນເປັນທີ່ມາຂອງເວລາທີ່ແນ່ນອນທີ່ໂມງອື່ນໆຖືກ synchronized

ໂມງສໍາລອງ

ອຸປະກອນສິ້ນສຸດທີ່ synchronized ຈາກໂມງຕົ້ນສະບັບ

ໂມງເຂດແດນ

ອຸ​ປະ​ກອນ​ທີ່​ມີ​ພອດ​ຫຼາຍ​ທີ່​ສາ​ມາດ​ເປັນ​ແມ່​ບົດ​ຫຼື​ສໍາ​ລອງ​ໄດ້​.

ນັ້ນແມ່ນ, ໂມງເຫຼົ່ານີ້ສາມາດ synchronize ຈາກໂມງແມ່ບົດຊັ້ນສູງແລະ synchronize ໂມງສໍາລອງ inferior.

ໂມງໂປ່ງໃສຈາກຈຸດຈົບ

ອຸ​ປະ​ກອນ​ທີ່​ມີ​ພອດ​ຫຼາຍ​ທີ່​ບໍ່​ແມ່ນ​ໂມງ​ຕົ້ນ​ສະ​ບັບ​ຫຼື​ສໍາ​ລັບ​ການ​. ມັນສົ່ງຂໍ້ມູນ PTP ລະຫວ່າງສອງໂມງ.

ເມື່ອສົ່ງຂໍ້ມູນ, ໂມງໂປ່ງໃສຈະແກ້ໄຂຂໍ້ຄວາມ PTP ທັງໝົດ.

ການ​ແກ້​ໄຂ​ເກີດ​ຂຶ້ນ​ໂດຍ​ການ​ເພີ່ມ​ເວ​ລາ​ການ​ຊັກ​ຊ້າ​ໃນ​ອຸ​ປະ​ກອນ​ນີ້​ກັບ​ພາກ​ສະ​ຫນາມ​ການ​ແກ້​ໄຂ​ຢູ່​ໃນ​ສ່ວນ​ຫົວ​ຂອງ​ຂໍ້​ຄວາມ​ທີ່​ສົ່ງ​ອອກ​.

ໂມງໂປ່ງໃສ Peer-to-Peer

ອຸ​ປະ​ກອນ​ທີ່​ມີ​ພອດ​ຫຼາຍ​ທີ່​ບໍ່​ແມ່ນ​ໂມງ​ຕົ້ນ​ສະ​ບັບ​ຫຼື​ສໍາ​ລັບ​ການ​.
ມັນສົ່ງຂໍ້ມູນ PTP ລະຫວ່າງສອງໂມງ.

ເມື່ອສົ່ງຂໍ້ມູນ, ໂມງໂປ່ງໃສຈະແກ້ໄຂຂໍ້ຄວາມ PTP ທັງໝົດ Sync ແລະ Follow_Up (ເພີ່ມເຕີມກ່ຽວກັບພວກມັນຂ້າງລຸ່ມນີ້).

ການແກ້ໄຂແມ່ນບັນລຸໄດ້ໂດຍການເພີ່ມໃສ່ຊ່ອງຂໍ້ມູນການແກ້ໄຂຂອງແພັກເກັດທີ່ສົ່ງຕໍ່ຄວາມລ່າຊ້າໃນອຸປະກອນການສົ່ງຂໍ້ມູນແລະຄວາມລ່າຊ້າໃນຊ່ອງທາງການສົ່ງຂໍ້ມູນ.

Node ການຈັດການ

ອຸປະກອນທີ່ກຳນົດຄ່າ ແລະວິນິດໄສໂມງອື່ນໆ

ໂມງແມ່ບົດ ແລະໂມງທາດຖືກຊິງໂຄຣໄນໂດຍໃຊ້ສະແຕມເວລາໃນຂໍ້ຄວາມ PTP. ມີສອງປະເພດຂອງຂໍ້ຄວາມຢູ່ໃນໂປໂຕຄອນ PTP:

• ຂໍ້ຄວາມເຫດການແມ່ນຂໍ້ຄວາມທີ່ synchronized ທີ່ກ່ຽວຂ້ອງກັບການສ້າງເວລາໃນເວລາທີ່ຂໍ້ຄວາມຖືກສົ່ງແລະໃນເວລາທີ່ໄດ້ຮັບ.
• ຂໍ້ຄວາມທົ່ວໄປ - ຂໍ້ຄວາມເຫຼົ່ານີ້ບໍ່ຮຽກຮ້ອງໃຫ້ມີການປະທັບຕາເວລາ, ແຕ່ອາດຈະມີການສະແຕມເວລາສໍາລັບຂໍ້ຄວາມທີ່ກ່ຽວຂ້ອງ

ຂໍ້ຄວາມເຫດການ

ຂໍ້ຄວາມທົ່ວໄປ

Sync
Delay_Req
Pdelay_Req
Pdelay_Resp

ປະກາດ
ຕິດຕາມ
Delay_Resp
Pdelay_Resp_Follow_Up
ການຈັດການ
ສັນຍານ

ທຸກປະເພດຂອງຂໍ້ຄວາມຈະຖືກສົນທະນາໃນລາຍລະອຽດເພີ່ມເຕີມຂ້າງລຸ່ມນີ້.

ບັນຫາພື້ນຖານ synchronization

ເມື່ອແພັກເກັດ synchronization ຖືກສົ່ງຜ່ານເຄືອຂ່າຍທ້ອງຖິ່ນ, ມັນຖືກຊັກຊ້າຢູ່ທີ່ສະວິດແລະໃນການເຊື່ອມຕໍ່ຂໍ້ມູນ. ສະວິດໃດນຶ່ງຈະເຮັດໃຫ້ເກີດຄວາມລ່າຊ້າປະມານ 10 ໄມໂຄວິນາທີ, ເຊິ່ງບໍ່ສາມາດຍອມຮັບໄດ້ສຳລັບ PTPv2. ຫຼັງຈາກທີ່ທັງຫມົດ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ບັນລຸຄວາມຖືກຕ້ອງຂອງ 1 μsໃນອຸປະກອນສຸດທ້າຍ. (ນີ້​ແມ່ນ​ຖ້າ​ຫາກ​ວ່າ​ພວກ​ເຮົາ​ກໍາ​ລັງ​ເວົ້າ​ກ່ຽວ​ກັບ​ພະ​ລັງ​ງານ. ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ອື່ນໆ​ອາດ​ຈະ​ຕ້ອງ​ການ​ຄວາມ​ຖືກ​ຕ້ອງ​ຫຼາຍ​ກວ່າ​.)

IEEE 1588v2 ອະທິບາຍວິທີການປະຕິບັດການຫຼາຍຢ່າງທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດບັນທຶກການຊັກຊ້າເວລາແລະແກ້ໄຂມັນ.

ສູດການເຮັດວຽກ
ໃນ​ລະ​ຫວ່າງ​ການ​ດໍາ​ເນີນ​ງານ​ປົກ​ກະ​ຕິ​, ອະ​ນຸ​ສັນ​ຍາ​ດໍາ​ເນີນ​ການ​ໃນ​ສອງ​ໄລ​ຍະ​.

• ໄລຍະທີ 1 - ການສ້າງຕັ້ງ "ໂມງແມ່ບົດ - ໂມງຂ້າທາດ".
• ໄລຍະທີ 2 - ການປະສານໂມງໂດຍໃຊ້ກົນໄກ End-to-End ຫຼື Peer-to-Peer.

ໄລຍະທີ 1 - ການຈັດຕັ້ງຂັ້ນນາຍ-ລັດຖະກອນ

ແຕ່ລະພອດຂອງໂມງປົກກະຕິຫຼືຂອບມີຈໍານວນລັດທີ່ແນ່ນອນ (ໂມງສໍາລອງແລະໂມງແມ່ບົດ). ມາດຕະຖານອະທິບາຍຂັ້ນຕອນການປ່ຽນລະຫວ່າງລັດເຫຼົ່ານີ້. ໃນການຂຽນໂປລແກລມ, ສູດການຄິດໄລ່ດັ່ງກ່າວຖືກເອີ້ນວ່າເຄື່ອງລັດ finite state machine ຫຼື state machine (ລາຍລະອຽດເພີ່ມເຕີມໃນ Wiki).

ເຄື່ອງຂອງລັດນີ້ໃຊ້ລະບົບໂມງແມ່ແບບທີ່ດີທີ່ສຸດ (BMCA) ເພື່ອຕັ້ງແມ່ແບບເມື່ອເຊື່ອມຕໍ່ສອງໂມງ.

ສູດການຄິດໄລ່ນີ້ເຮັດໃຫ້ໂມງຮັບໜ້າທີ່ຮັບຜິດຊອບຂອງໂມງ grandmaster ເມື່ອໂມງ grandmaster ເທິງກະແສສູນເສຍສັນຍານ GPS, ໄປແບບອອບລາຍ, ແລະອື່ນໆ.

ການຫັນປ່ຽນຂອງລັດຕາມ BMCA ແມ່ນສະຫຼຸບໃນແຜນວາດຕໍ່ໄປນີ້:


ຂໍ້​ມູນ​ກ່ຽວ​ກັບ​ໂມງ​ຢູ່​ສົ້ນ​ອື່ນໆ​ຂອງ “ສາຍ” ຈະ​ຖືກ​ສົ່ງ​ໄປ​ໃນ​ຂໍ້​ຄວາມ​ພິ​ເສດ (ປະ​ກາດ​ຂໍ້​ຄວາມ). ເມື່ອຂໍ້ມູນນີ້ໄດ້ຮັບ, ເຄື່ອງຈັກຂອງລັດຈະດໍາເນີນການແລະການປຽບທຽບເພື່ອເບິ່ງວ່າໂມງໃດດີກວ່າ. ພອດຢູ່ໃນໂມງທີ່ດີທີ່ສຸດກາຍເປັນໂມງຕົ້ນສະບັບ.

ການຈັດລໍາດັບແບບງ່າຍໆແມ່ນສະແດງຢູ່ໃນແຜນວາດຂ້າງລຸ່ມນີ້. ເສັ້ນທາງ 1, 2, 3, 4, 5 ອາດຈະປະກອບດ້ວຍໂມງໂປ່ງໃສ, ແຕ່ພວກມັນບໍ່ໄດ້ເຂົ້າຮ່ວມໃນການສ້າງຕັ້ງໂມງແມ່ແບບ - ລໍາດັບຊັ້ນຂອງໂມງສໍາລອງ.

ໄລຍະທີ 2 - synchronize ໂມງປົກກະຕິແລະຂອບ

ທັນທີຫຼັງຈາກການສ້າງຕັ້ງ "ໂມງຕົ້ນສະບັບ - ໂມງສໍາລອງ", ໄລຍະ synchronization ຂອງໂມງປົກກະຕິແລະຂອບເຂດເລີ່ມຕົ້ນ.

ເພື່ອ synchronize, ໂມງແມ່ບົດສົ່ງຂໍ້ຄວາມທີ່ມີເວລາໃຫ້ໂມງສໍາລອງ.

ໂມງຫຼັກສາມາດເປັນ:

• ຂັ້ນຕອນດຽວ;
• ສອງຂັ້ນຕອນ.

ໂມງຂັ້ນຕອນດຽວສົ່ງຂໍ້ຄວາມ Sync ຫນຶ່ງເພື່ອ synchronize.

ໂມງສອງຂັ້ນຕອນໃຊ້ສອງຂໍ້ຄວາມສໍາລັບການ synchronization - Sync ແລະ Follow_Up.

ສອງກົນໄກສາມາດນໍາໃຊ້ສໍາລັບໄລຍະ synchronization:

• ຊັກ​ຊ້າ​ກົນ​ໄກ​ການ​ຕອບ​ສະ​ຫນອງ​ການ​ຮ້ອງ​ຂໍ​.
• ກົນໄກການວັດແທກຄວາມລ່າຊ້າຂອງເພື່ອນມິດ.

ທໍາອິດ, ໃຫ້ເບິ່ງກົນໄກເຫຼົ່ານີ້ໃນກໍລະນີທີ່ງ່າຍດາຍທີ່ສຸດ - ເມື່ອໂມງທີ່ມີຄວາມໂປ່ງໃສບໍ່ໄດ້ຖືກນໍາໃຊ້.

ຊັກ​ຊ້າ​ກົນ​ໄກ​ການ​ຕອບ​ສະ​ຫນອງ​ການ​ຮ້ອງ​ຂໍ​

ກົນ​ໄກ​ປະ​ກອບ​ມີ​ສອງ​ຂັ້ນ​ຕອນ​:

1. ການວັດແທກຄວາມລ່າຊ້າໃນການສົ່ງຂໍ້ຄວາມລະຫວ່າງໂມງແມ່ແບບແລະໂມງສໍາລອງ. ປະຕິບັດໂດຍກົນໄກການຕອບຄໍາຮ້ອງຂໍການຊັກຊ້າ.
2. ການແກ້ໄຂການປ່ຽນແປງເວລາທີ່ແນ່ນອນແມ່ນປະຕິບັດ.

ການວັດແທກການຕອບສະໜອງ


t1 – ເວລາສົ່ງຂໍ້ຄວາມ Sync ໂດຍໂມງແມ່ບົດ; t2 – ເວລາຮັບຂໍ້ຄວາມ Sync ໂດຍໂມງທາດ; t3 – ເວລາຂອງການສົ່ງຄໍາຮ້ອງຂໍການຊັກຊ້າ (Delay_Req) ​​​​ໂດຍໂມງສໍາລອງ; t4 – Delay_Req ເວລາຮັບໂດຍໂມງແມ່ບົດ.

ເມື່ອໂມງສໍາລອງຮູ້ເວລາ t1, t2, t3, ແລະ t4, ມັນສາມາດຄິດໄລ່ຄວາມລ່າຊ້າໂດຍສະເລ່ຍໃນເວລາທີ່ສົ່ງຂໍ້ຄວາມ synchronization (tmpd). ມັນ​ໄດ້​ຖືກ​ຄິດ​ໄລ່​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

ເມື່ອສົ່ງຂໍ້ຄວາມ Sync ແລະ Follow_Up, ການຊັກຊ້າເວລາຈາກແມ່ແບບໄປຫາສໍາລອງແມ່ນຄິດໄລ່ - t-ms .

ເມື່ອສົ່ງຂໍ້ຄວາມ Delay_Req ແລະ Delay_Resp, ການຊັກຊ້າເວລາຈາກ slave ກັບແມ່ບົດແມ່ນຄິດໄລ່ - t-sm .

ຖ້າຄວາມບໍ່ສົມດຸນບາງຢ່າງເກີດຂື້ນລະຫວ່າງສອງຄ່ານີ້, ຂໍ້ຜິດພາດໃນການແກ້ໄຂຄວາມບ່ຽງເບນຂອງເວລາທີ່ແນ່ນອນຈະປາກົດຂຶ້ນ. ຄວາມຜິດພາດແມ່ນເກີດມາຈາກຄວາມຈິງທີ່ວ່າຄວາມລ່າຊ້າທີ່ຄິດໄລ່ແມ່ນສະເລ່ຍຂອງການຊັກຊ້າ t-ms ແລະ t-sm. ຖ້າຄວາມລ່າຊ້າບໍ່ເທົ່າກັບກັນແລະກັນ, ພວກເຮົາຈະບໍ່ປັບເວລາຢ່າງຖືກຕ້ອງ.

ການແກ້ໄຂການປ່ຽນແປງເວລາ

ເມື່ອຄວາມລ່າຊ້າລະຫວ່າງໂມງແມ່ບົດແລະໂມງສໍາລອງຮູ້, ໂມງສໍາລອງຈະດໍາເນີນການແກ້ໄຂເວລາ.

ໂມງສໍາລອງໃຊ້ຂໍ້ຄວາມ Sync ແລະຂໍ້ຄວາມ Follow_Up ທາງເລືອກເພື່ອຄິດໄລ່ເວລາຊົດເຊີຍທີ່ແນ່ນອນເມື່ອສົ່ງແພັກເກັດຈາກແມ່ແບບໄປຫາໂມງສໍາລອງ. ການປ່ຽນແປງແມ່ນຄິດໄລ່ໂດຍໃຊ້ສູດຕໍ່ໄປນີ້:

ກົນໄກການວັດແທກຄວາມລ່າຊ້າຂອງເພື່ອນມິດ

ກົນໄກນີ້ຍັງໃຊ້ສອງຂັ້ນຕອນສໍາລັບການ synchronization:

1. ອຸປະກອນວັດແທກຄວາມລ່າຊ້າເວລາໃຫ້ກັບເພື່ອນບ້ານທັງຫມົດຜ່ານພອດທັງຫມົດ. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຂົາໃຊ້ກົນໄກການຊັກຊ້າ.
2. ການແກ້ໄຂການປ່ຽນແປງເວລາທີ່ແນ່ນອນ.

ການວັດແທກການຕອບສະໜອງລະຫວ່າງອຸປະກອນທີ່ຮອງຮັບໂໝດ Peer-to-Peer

latency ລະຫວ່າງພອດທີ່ສະຫນັບສະຫນູນກົນໄກ peer-to-peer ແມ່ນວັດແທກໂດຍໃຊ້ຂໍ້ຄວາມຕໍ່ໄປນີ້:

ເມື່ອພອດ 1 ຮູ້ເວລາ t1, t2, t3 ແລະ t4, ມັນສາມາດຄິດໄລ່ຄວາມລ່າຊ້າສະເລ່ຍ (tmld). ມັນຖືກຄິດໄລ່ໂດຍໃຊ້ສູດຕໍ່ໄປນີ້:

ພອດຫຼັງຈາກນັ້ນຈະໃຊ້ຄ່ານີ້ເມື່ອຄິດໄລ່ຊ່ອງປັບສໍາລັບແຕ່ລະຂໍ້ຄວາມ Sync ຫຼືຂໍ້ຄວາມຕິດຕາມທາງເລືອກທີ່ຜ່ານອຸປະກອນ.

ຄວາມລ່າຊ້າທັງໝົດຈະເທົ່າກັບຜົນລວມຂອງຄວາມລ່າຊ້າໃນລະຫວ່າງການສົ່ງຜ່ານອຸປະກອນນີ້, ຄວາມລ່າຊ້າສະເລ່ຍໃນລະຫວ່າງການສົ່ງຜ່ານຊ່ອງຂໍ້ມູນ ແລະຄວາມລ່າຊ້າທີ່ມີຢູ່ໃນຂໍ້ຄວາມນີ້, ເປີດໃຊ້ໃນອຸປະກອນຕົ້ນທາງ.

ຂໍ້ຄວາມ Pdelay_Req, Pdelay_Resp ແລະທາງເລືອກ Pdelay_Resp_Follow_Up ອະນຸຍາດໃຫ້ທ່ານໄດ້ຮັບການຊັກຊ້າຈາກແມ່ບົດໄປຫາສໍາລອງແລະຈາກ slave ກັບຕົ້ນສະບັບ (ວົງ).

asymmetry ໃດລະຫວ່າງສອງຄ່ານີ້ຈະແນະນໍາການແກ້ໄຂການຊົດເຊີຍເວລາ.

ການປັບປ່ຽນເວລາທີ່ແນ່ນອນ

ໂມງສໍາລອງໃຊ້ຂໍ້ຄວາມ Sync ແລະຂໍ້ຄວາມ Follow_Up ທາງເລືອກເພື່ອຄິດໄລ່ເວລາຊົດເຊີຍທີ່ແນ່ນອນເມື່ອສົ່ງແພັກເກັດຈາກແມ່ແບບໄປຫາໂມງສໍາລອງ. ການປ່ຽນແປງແມ່ນຄິດໄລ່ໂດຍໃຊ້ສູດຕໍ່ໄປນີ້:

ຂໍ້ໄດ້ປຽບຂອງການປັບຕົວຂອງກົນໄກ peer-to-peer - ຄວາມລ່າຊ້າຂອງແຕ່ລະຂໍ້ຄວາມ Sync ຫຼື Follow_Up ຖືກຄິດໄລ່ຍ້ອນວ່າມັນຖືກສົ່ງຜ່ານເຄືອຂ່າຍ. ດັ່ງນັ້ນ, ການປ່ຽນແປງເສັ້ນທາງສາຍສົ່ງຈະບໍ່ມີຜົນກະທົບໃດໆຕໍ່ຄວາມຖືກຕ້ອງຂອງການປັບ.

ໃນເວລາທີ່ການນໍາໃຊ້ກົນໄກນີ້, synchronization ທີ່ໃຊ້ເວລາບໍ່ຮຽກຮ້ອງໃຫ້ມີການຄິດໄລ່ການຊັກຊ້າທີ່ໃຊ້ເວລາຕາມເສັ້ນທາງທີ່ traversed ໂດຍ synchronization packet, ດັ່ງທີ່ເຮັດໃນການແລກປ່ຽນພື້ນຖານ. ເຫຼົ່ານັ້ນ. ຂໍ້ຄວາມ Delay_Req ແລະ Delay_Resp ບໍ່ໄດ້ຖືກສົ່ງ. ໃນວິທີການນີ້, ຄວາມລ່າຊ້າລະຫວ່າງແມ່ບົດແລະໂມງສໍາລອງແມ່ນສະຫຼຸບພຽງແຕ່ໃນພາກສະຫນາມການປັບຕົວຂອງແຕ່ລະຂໍ້ຄວາມ Sync ຫຼື Follow_Up.

ປະໂຫຍດອີກອັນຫນຶ່ງແມ່ນວ່າໂມງຕົ້ນສະບັບແມ່ນຜ່ອນຄາຍຈາກຄວາມຕ້ອງການທີ່ຈະປະມວນຜົນຂໍ້ຄວາມ Delay_Req.

ຮູບແບບການເຮັດວຽກຂອງໂມງໂປ່ງໃສ

ດັ່ງນັ້ນ, ເຫຼົ່ານີ້ແມ່ນຕົວຢ່າງທີ່ງ່າຍດາຍ. ຕອນນີ້ສົມມຸດວ່າສະວິດຈະປາກົດຢູ່ໃນເສັ້ນທາງ synchronization.

ຖ້າທ່ານໃຊ້ສະວິດໂດຍບໍ່ມີການສະຫນັບສະຫນູນ PTPv2, ຊຸດ synchronization ຈະຖືກຊັກຊ້າໃນສະວິດໂດຍປະມານ 10 μs.

ສະວິດທີ່ຮອງຮັບ PTPv2 ເອີ້ນວ່າໂມງໂປ່ງໃສໃນຄໍາສັບ IEEE 1588v2. ໂມງໂປ່ງໃສບໍ່ໄດ້ຖືກ synchronized ຈາກໂມງຕົ້ນສະບັບແລະບໍ່ໄດ້ເຂົ້າຮ່ວມໃນລໍາດັບ "ໂມງແມ່ບົດ - ໂມງສໍາລອງ", ແຕ່ເມື່ອສົ່ງຂໍ້ຄວາມ synchronization ພວກເຂົາຈື່ຈໍາວ່າຂໍ້ຄວາມຖືກຊັກຊ້າດົນປານໃດ. ນີ້ອະນຸຍາດໃຫ້ທ່ານປັບການຊັກຊ້າທີ່ໃຊ້ເວລາ.

ໂມງໂປ່ງໃສສາມາດເຮັດວຽກໄດ້ໃນສອງໂໝດ:

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

End-to-End (E2E)

ໂມງໂປ່ງໃສ E2E ກະຈາຍຂໍ້ຄວາມ Sync ແລະຕິດຕາມຂໍ້ຄວາມ Follow_Up ໃນທຸກຜອດ. ເຖິງແມ່ນວ່າຜູ້ທີ່ຖືກບລັອກໂດຍບາງໂປໂຕຄອນ (ຕົວຢ່າງເຊັ່ນ RSTP).

ສະວິດຈື່ຈໍາເວລາເວລາທີ່ແພັກເກັດ Sync (Follow_Up) ໄດ້ຮັບຢູ່ໃນຜອດ ແລະເມື່ອມັນຖືກສົ່ງມາຈາກພອດ. ອີງຕາມການສະແຕມສອງຄັ້ງເຫຼົ່ານີ້, ເວລາທີ່ມັນໃຊ້ສໍາລັບການສະຫຼັບເພື່ອປະມວນຜົນຂໍ້ຄວາມຈະຖືກຄິດໄລ່. ໃນມາດຕະຖານ, ເວລານີ້ເອີ້ນວ່າເວລາທີ່ຢູ່ອາໄສ.

ເວລາປະມວນຜົນຈະຖືກເພີ່ມໃສ່ໃນຊ່ອງ correctionField ຂອງ Sync (ໂມງຂັ້ນຕອນດຽວ) ຫຼື Follow_Up (ໂມງສອງຂັ້ນຕອນ).

ໂມງໂປ່ງໃສ E2E ວັດແທກເວລາປະມວນຜົນສໍາລັບຂໍ້ຄວາມ Sync ແລະ Delay_Req ທີ່ຜ່ານສະວິດ. ແຕ່ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະເຂົ້າໃຈວ່າການຊັກຊ້າເວລາລະຫວ່າງໂມງແມ່ບົດແລະໂມງສໍາລອງຖືກຄິດໄລ່ໂດຍໃຊ້ກົນໄກການຕອບຄໍາຮ້ອງຂໍການຊັກຊ້າ. ຖ້າໂມງຫຼັກປ່ຽນ ຫຼືເສັ້ນທາງຈາກໂມງຫຼັກໄປຫາໂມງທາດປ່ຽນ, ຄວາມລ່າຊ້າຈະຖືກວັດແທກອີກຄັ້ງ. ນີ້ຈະເພີ່ມເວລາການປ່ຽນແປງໃນກໍລະນີຂອງການປ່ຽນແປງເຄືອຂ່າຍ.

ໂມງໂປ່ງໃສ P2P, ນອກເຫນືອຈາກການວັດແທກເວລາທີ່ມັນໃຊ້ສໍາລັບການສະຫຼັບເພື່ອປະມວນຜົນຂໍ້ຄວາມ, ວັດແທກຄວາມລ່າຊ້າຂອງການເຊື່ອມຕໍ່ຂໍ້ມູນກັບເພື່ອນບ້ານທີ່ໃກ້ທີ່ສຸດໂດຍໃຊ້ກົນໄກການ latency ຂອງເພື່ອນບ້ານ.

Latency ແມ່ນຖືກວັດແທກຢູ່ໃນທຸກເຊື່ອມຕໍ່ໃນທັງສອງທິດທາງ, ລວມທັງການເຊື່ອມຕໍ່ທີ່ຖືກບລັອກໂດຍບາງໂປໂຕຄອນ (ເຊັ່ນ RSTP). ນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດຄິດໄລ່ຄວາມລ່າຊ້າໃຫມ່ໃນເສັ້ນທາງ synchronization ທັນທີຖ້າໂມງ grandmaster ຫຼືເຄືອຂ່າຍ topology ປ່ຽນແປງ.

ເວລາປະມວນຜົນຂໍ້ຄວາມໂດຍປຸ່ມສະວິດ ແລະ latency ແມ່ນສະສົມເມື່ອສົ່ງຂໍ້ຄວາມ Sync ຫຼື Follow_Up.

ປະເພດຂອງການສະຫນັບສະຫນູນ PTPv2 ໂດຍສະຫຼັບ

ສະວິດສາມາດຮອງຮັບ PTPv2:

• ໂປຣແກຣມ;
• ຮາດແວ.

ເມື່ອປະຕິບັດໂປຣໂຕຄໍ PTPv2 ໃນຊອບແວ, ສະວິດຈະຮ້ອງຂໍການສະແຕມເວລາຈາກເຟີມແວ. ບັນຫາແມ່ນວ່າເຟີມແວເຮັດວຽກເປັນວົງຈອນ, ແລະທ່ານຈະຕ້ອງລໍຖ້າຈົນກ່ວາມັນສໍາເລັດວົງຈອນປະຈຸບັນ, ໃຊ້ເວລາການຮ້ອງຂໍສໍາລັບການປະມວນຜົນແລະອອກສະແຕມເວລາຫຼັງຈາກວົງຈອນຕໍ່ໄປ. ນີ້ຍັງຈະຕ້ອງໃຊ້ເວລາ, ແລະພວກເຮົາຈະໄດ້ຮັບການຊັກຊ້າ, ເຖິງແມ່ນວ່າບໍ່ສໍາຄັນເທົ່າທີ່ບໍ່ມີການສະຫນັບສະຫນູນຊອບແວສໍາລັບ PTPv2.

ພຽງແຕ່ການສະຫນັບສະຫນູນຮາດແວສໍາລັບ PTPv2 ຊ່ວຍໃຫ້ທ່ານສາມາດຮັກສາຄວາມຖືກຕ້ອງທີ່ຕ້ອງການ. ໃນກໍລະນີນີ້, ການປະທັບຕາເວລາແມ່ນອອກໂດຍ ASIC ພິເສດ, ເຊິ່ງຕິດຕັ້ງຢູ່ໃນທ່າເຮືອ.

ຮູບແບບຂໍ້ຄວາມ

ຂໍ້ຄວາມ PTP ທັງໝົດປະກອບດ້ວຍຊ່ອງຂໍ້ມູນຕໍ່ໄປນີ້:

• ສ່ວນຫົວ – 34 bytes.
• ຮ່າງກາຍ - ຂະຫນາດຂຶ້ນກັບປະເພດຂອງຂໍ້ຄວາມ.
• Suffix ແມ່ນທາງເລືອກ.

Header

ພາກສະຫນາມ Header ແມ່ນຄືກັນສໍາລັບຂໍ້ຄວາມ PTP ທັງຫມົດ. ຂະຫນາດຂອງມັນແມ່ນ 34 bytes.

ຮູບແບບຊ່ອງໃສ່ຫົວ:

ປະເພດຂໍ້ຄວາມ – ປະ​ກອບ​ດ້ວຍ​ປະ​ເພດ​ຂອງ​ຂໍ້​ຄວາມ​ທີ່​ຖືກ​ສົ່ງ​, ສໍາ​ລັບ​ການ​ຍົກ​ຕົວ​ຢ່າງ Sync​, Delay_Req​, PDelay_Req​, ແລະ​ອື່ນໆ​.

ຄວາມຍາວຂໍ້ຄວາມ – ມີຂະໜາດເຕັມຂອງຂໍ້ຄວາມ PTP, ລວມທັງ header, body ແລະ suffix (ແຕ່ບໍ່ລວມ padding bytes).

domainNumber – ກຳນົດວ່າໂດເມນ PTP ໃດທີ່ຂໍ້ຄວາມເປັນຂອງ.

ເພີ່ມເຕີມ - ເຫຼົ່ານີ້ແມ່ນໂມງທີ່ແຕກຕ່າງກັນຫຼາຍທີ່ເກັບກໍາຢູ່ໃນກຸ່ມທີ່ມີເຫດຜົນແລະ synchronized ຈາກຫນຶ່ງໂມງຕົ້ນສະບັບ, ແຕ່ບໍ່ຈໍາເປັນຕ້ອງ synchronized ກັບໂມງເປັນຂອງໂດເມນທີ່ແຕກຕ່າງກັນ.

ທົງ – ພາກສະຫນາມນີ້ມີທຸງຕ່າງໆເພື່ອກໍານົດສະຖານະຂອງຂໍ້ຄວາມ.

ພາກສະຫນາມການແກ້ໄຂ - ມີເວລາຊັກຊ້າເປັນ nanoseconds. ເວລາຊັກຊ້າລວມເຖິງຄວາມລ່າຊ້າໃນເວລາສົ່ງຜ່ານໂມງໂປ່ງໃສ, ເຊັ່ນດຽວກັນກັບຄວາມລ່າຊ້າໃນເວລາທີ່ສົ່ງຜ່ານຊ່ອງໃນເວລາໃຊ້ໂໝດ Peer-to-Peer.

ແຫຼ່ງ PortIdentity – ຊ່ອງຂໍ້ມູນນີ້ມີຂໍ້ມູນກ່ຽວກັບພອດໃດທີ່ຂໍ້ຄວາມນີ້ຖືກສົ່ງມາຈາກຕົ້ນສະບັບ.

sequenceID – ມີ​ຕົວ​ເລກ​ປະ​ຈໍາ​ຕົວ​ສໍາ​ລັບ​ຂໍ້​ຄວາມ​ສ່ວນ​ບຸກ​ຄົນ​.

ພາກສະຫນາມຄວບຄຸມ – artifact field =) ມັນຍັງຄົງມາຈາກສະບັບທໍາອິດຂອງມາດຕະຖານແລະມີຂໍ້ມູນກ່ຽວກັບປະເພດຂອງຂໍ້ຄວາມນີ້. ໂດຍພື້ນຖານແລ້ວແມ່ນຄືກັນກັບປະເພດຂໍ້ຄວາມ, ແຕ່ມີທາງເລືອກຫນ້ອຍລົງ.

logMessageInterval – ພາກສະຫນາມນີ້ຖືກກໍານົດໂດຍປະເພດຂໍ້ຄວາມ.

ຮ່າງກາຍ

ດັ່ງທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, ມີຫຼາຍປະເພດຂອງຂໍ້ຄວາມ. ປະເພດເຫຼົ່ານີ້ແມ່ນໄດ້ອະທິບາຍຂ້າງລຸ່ມນີ້:

ຂໍ້ຄວາມປະກາດ
ຂໍ້ຄວາມປະກາດໃຊ້ເພື່ອ "ບອກ" ໂມງອື່ນໆພາຍໃນໂດເມນດຽວກັນກ່ຽວກັບພາລາມິເຕີຂອງມັນ. ຂໍ້ຄວາມນີ້ອະນຸຍາດໃຫ້ທ່ານຕັ້ງຄ່າໂມງແມ່ບົດ - ລໍາດັບຊັ້ນຂອງໂມງສໍາລອງ.


Message Sync
ຂໍ້ຄວາມ Sync ຖືກສົ່ງໂດຍໂມງແມ່ແບບແລະປະກອບດ້ວຍເວລາຂອງໂມງແມ່ແບບໃນເວລາທີ່ຂໍ້ຄວາມ Sync ຖືກສ້າງຂຶ້ນ. ຖ້າໂມງຫຼັກເປັນສອງຂັ້ນຕອນ, ເວລາໃນຂໍ້ຄວາມ Sync ຈະຖືກຕັ້ງເປັນ 0, ແລະເວລາປະຈຸບັນຈະຖືກສົ່ງໃນຂໍ້ຄວາມ Follow_Up ທີ່ກ່ຽວຂ້ອງ. ຂໍ້ຄວາມ Sync ແມ່ນໃຊ້ສໍາລັບທັງສອງກົນໄກການວັດແທກການຕອບສະໜອງ.

ຂໍ້ຄວາມຖືກຖ່າຍທອດໂດຍໃຊ້ Multicast. ທາງເລືອກອື່ນທ່ານສາມາດນໍາໃຊ້ Unicast.

ຂໍ້ຄວາມ Delay_Req

ຮູບແບບຂອງຂໍ້ຄວາມ Delay_Req ແມ່ນຄືກັນກັບຂໍ້ຄວາມ Sync. ໂມງສໍາລອງສົ່ງ Delay_Req. ມັນປະກອບມີເວລາທີ່ Delay_Req ຖືກສົ່ງໂດຍໂມງທາດ. ຂໍ້ຄວາມນີ້ຖືກນໍາໃຊ້ພຽງແຕ່ສໍາລັບກົນໄກການຮ້ອງຂໍການຕອບໂຕ້ຊັກຊ້າ.

ຂໍ້ຄວາມຖືກຖ່າຍທອດໂດຍໃຊ້ Multicast. ທາງເລືອກອື່ນທ່ານສາມາດນໍາໃຊ້ Unicast.

ຕິດຕາມຂໍ້ຄວາມ

ຂໍ້ຄວາມ Follow_Up ແມ່ນຖືກສົ່ງເປັນທາງເລືອກໂດຍໂມງແມ່ແບບ ແລະມີເວລາສົ່ງ ຊິ້ງຂໍ້ມູນຂໍ້ຄວາມ ແມ່ບົດ. ພຽງແຕ່ໂມງແມ່ບົດສອງຂັ້ນຕອນສົ່ງຂໍ້ຄວາມ Follow_Up.

ຂໍ້ຄວາມ Follow_Up ຖືກນໍາໃຊ້ສໍາລັບທັງສອງກົນໄກການວັດແທກການຕອບສະໜອງ.

ຂໍ້ຄວາມຖືກຖ່າຍທອດໂດຍໃຊ້ Multicast. ທາງເລືອກອື່ນທ່ານສາມາດນໍາໃຊ້ Unicast.

Delay_Resp ຂໍ້ຄວາມ

ຂໍ້ຄວາມ Delay_Resp ຖືກສົ່ງໂດຍໂມງແມ່ບົດ. ມັນປະກອບດ້ວຍເວລາທີ່ Delay_Req ໄດ້ຮັບໂດຍໂມງຕົ້ນສະບັບ. ຂໍ້ຄວາມນີ້ຖືກໃຊ້ພຽງແຕ່ສໍາລັບກົນໄກການຕອບຄໍາຮ້ອງຂໍການຊັກຊ້າ.

ຂໍ້ຄວາມຖືກຖ່າຍທອດໂດຍໃຊ້ Multicast. ທາງເລືອກອື່ນທ່ານສາມາດນໍາໃຊ້ Unicast.

ຂໍ້ຄວາມ Pdelay_Req

ຂໍ້ຄວາມ Pdelay_Req ຖືກສົ່ງໂດຍອຸປະກອນທີ່ຮ້ອງຂໍການຊັກຊ້າ. ມັນປະກອບດ້ວຍເວລາທີ່ຂໍ້ຄວາມຖືກສົ່ງຈາກພອດຂອງອຸປະກອນນີ້. Pdelay_Req ຖືກນໍາໃຊ້ສໍາລັບກົນໄກການວັດແທກຄວາມລ່າຊ້າຂອງເພື່ອນບ້ານເທົ່ານັ້ນ.

ຂໍ້ຄວາມ Pdelay_Resp

ຂໍ້ຄວາມ Pdelay_Resp ຖືກສົ່ງໂດຍອຸປະກອນທີ່ໄດ້ຮັບການຮ້ອງຂໍການຊັກຊ້າ. ມັນປະກອບດ້ວຍເວລາທີ່ຂໍ້ຄວາມ Pdelay_Req ໄດ້ຮັບໂດຍອຸປະກອນນີ້. ຂໍ້ຄວາມ Pdelay_Resp ຖືກນໍາໃຊ້ສໍາລັບກົນໄກການວັດແທກການຊັກຊ້າຂອງເພື່ອນບ້ານເທົ່ານັ້ນ.

ສົ່ງຂໍ້ຄວາມ Pdelay_Resp_Follow_Up

ຂໍ້ຄວາມ Pdelay_Resp_Follow_Up ຖືກສົ່ງເປັນທາງເລືອກໂດຍອຸປະກອນທີ່ໄດ້ຮັບການຮ້ອງຂໍການຊັກຊ້າ. ມັນປະກອບດ້ວຍເວລາທີ່ຂໍ້ຄວາມ Pdelay_Req ໄດ້ຮັບໂດຍອຸປະກອນນີ້. ຂໍ້ຄວາມ Pdelay_Resp_Follow_Up ຖືກສົ່ງໂດຍໂມງແມ່ແບບສອງຂັ້ນຕອນເທົ່ານັ້ນ.

ຂໍ້ຄວາມນີ້ຍັງສາມາດຖືກນໍາໃຊ້ສໍາລັບເວລາປະຕິບັດແທນທີ່ຈະເປັນເວລາ. ເວລາປະຕິບັດແມ່ນເວລາຈາກເວລາທີ່ Pdelay-Req ໄດ້ຮັບຈົນກ່ວາ Pdelay_Resp ຖືກສົ່ງ.

Pdelay_Resp_Follow_Up ແມ່ນໃຊ້ສະເພາະກັບກົນໄກການວັດແທກຄວາມລ່າຊ້າຂອງເພື່ອນບ້ານເທົ່ານັ້ນ.

ຂໍ້​ຄວາມ​ການ​ຄຸ້ມ​ຄອງ​

ຂໍ້ຄວາມຄວບຄຸມ PTP ແມ່ນຈໍາເປັນເພື່ອໂອນຂໍ້ມູນລະຫວ່າງຫນຶ່ງຫຼືຫຼາຍໂມງແລະ node ຄວບຄຸມ.

ໂອນໃຫ້ LV

ຂໍ້ຄວາມ PTP ສາມາດຖືກສົ່ງຜ່ານສອງລະດັບ:

• ເຄືອຂ່າຍ – ເປັນສ່ວນຫນຶ່ງຂອງຂໍ້ມູນ IP.
• ຊ່ອງ - ເປັນສ່ວນຫນຶ່ງຂອງກອບອີເທີເນັດ.

ການສົ່ງຂໍ້ຄວາມ PTP ຜ່ານ UDP ຜ່ານ IP ຜ່ານອີເທີເນັດ

PTP ຜ່ານ UDP ຜ່ານອີເທີເນັດ

ໂປຣໄຟລ໌

PTP ມີຕົວກໍານົດການທີ່ມີຄວາມຍືດຫຍຸ່ນຫຼາຍທີ່ຕ້ອງໄດ້ຮັບການຕັ້ງຄ່າ. ຍົກ​ຕົວ​ຢ່າງ:

• BMCA ທາງເລືອກ.
• ກົນໄກການວັດແທກຄວາມແຝງ.
• ໄລຍະຫ່າງແລະຄ່າເບື້ອງຕົ້ນຂອງພາລາມິເຕີທີ່ສາມາດກໍານົດໄດ້ທັງຫມົດ, ແລະອື່ນໆ.

ແລະເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າໃນເມື່ອກ່ອນພວກເຮົາເວົ້າວ່າອຸປະກອນ PTPv2 ແມ່ນເຂົ້າກັນໄດ້ກັບກັນແລະກັນ, ນີ້ບໍ່ແມ່ນຄວາມຈິງ. ອຸປະກອນຕ້ອງມີການຕັ້ງຄ່າດຽວກັນເພື່ອຕິດຕໍ່ສື່ສານ.

ດັ່ງນັ້ນຈຶ່ງມີອັນທີ່ເອີ້ນວ່າໂປຣໄຟລ໌ PTPv2. ໂປຣໄຟລ໌ແມ່ນກຸ່ມຂອງການຕັ້ງຄ່າທີ່ກຳນົດໄວ້ ແລະຂໍ້ຈຳກັດຂອງໂປຣໂຕຄໍທີ່ກຳນົດໄວ້ເພື່ອໃຫ້ການຊິ້ງຂໍ້ມູນເວລາສາມາດປະຕິບັດໄດ້ສຳລັບແອັບພລິເຄຊັນສະເພາະ.

ມາດຕະຖານ IEEE 1588v2 ຕົວຂອງມັນເອງອະທິບາຍພຽງແຕ່ໂປຣໄຟລ໌ດຽວ – “ໂປຣໄຟລ໌ເລີ່ມຕົ້ນ”. ໂປຣໄຟລ໌ອື່ນໆທັງໝົດແມ່ນສ້າງ ແລະອະທິບາຍໂດຍອົງການຈັດຕັ້ງ ແລະສະມາຄົມຕ່າງໆ.

ຕົວຢ່າງ, ໂປຣໄຟລ໌ພະລັງງານ, ຫຼືໂປຣໄຟລ໌ PTPv2, ໄດ້ຖືກສ້າງຂື້ນໂດຍຄະນະກໍາມະການສົ່ງຕໍ່ລະບົບພະລັງງານ ແລະຄະນະກໍາມະການຍ່ອຍຂອງສະມາຄົມພະລັງງານ ແລະພະລັງງານຂອງ IEEE. ໂປຣໄຟລ໌ຕົວມັນເອງເອີ້ນວ່າ IEEE C37.238-2011.

ໂປຣໄຟລ໌ອະທິບາຍວ່າ PTP ສາມາດໂອນໄດ້:

• ພຽງແຕ່ຜ່ານເຄືອຂ່າຍ L2 (i.e. Ethernet, HSR, PRP, ບໍ່ແມ່ນ IP).
• ຂໍ້ຄວາມຖືກສົ່ງໂດຍການກະຈາຍສຽງແບບ Multicast ເທົ່ານັ້ນ.
• ກົນໄກການວັດແທກຄວາມລ່າຊ້າຂອງໝູ່ແມ່ນໃຊ້ເປັນກົນໄກການວັດແທກຄວາມລ່າຊ້າ.

ໂດເມນເລີ່ມຕົ້ນແມ່ນ 0, ໂດເມນທີ່ແນະນໍາແມ່ນ 93.

ປັດຊະຍາຂອງການອອກແບບທີ່ຢູ່ເບື້ອງຫຼັງ C37.238-2011 ແມ່ນເພື່ອຫຼຸດຜ່ອນຈໍານວນຂອງຄຸນສົມບັດທາງເລືອກແລະຮັກສາພຽງແຕ່ຫນ້າທີ່ທີ່ຈໍາເປັນສໍາລັບການໂຕ້ຕອບທີ່ເຊື່ອຖືໄດ້ລະຫວ່າງອຸປະກອນແລະຄວາມຫມັ້ນຄົງຂອງລະບົບທີ່ເພີ່ມຂຶ້ນ.

ນອກຈາກນີ້, ຄວາມຖີ່ຂອງການສົ່ງຂໍ້ຄວາມແມ່ນຖືກກໍານົດ:

ໃນຄວາມເປັນຈິງ, ພຽງແຕ່ຫນຶ່ງຕົວກໍານົດການສາມາດໃຊ້ໄດ້ສໍາລັບການເລືອກ - ປະເພດຂອງໂມງແມ່ບົດ (ຂັ້ນຕອນດຽວຫຼືສອງຂັ້ນຕອນ).

ຄວາມຖືກຕ້ອງຄວນຈະບໍ່ເກີນ 1 μs. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ເສັ້ນທາງ synchronization ຫນຶ່ງສາມາດບັນຈຸສູງສຸດຂອງ 15 ໂມງໂປ່ງໃສຫຼືສາມໂມງຊາຍແດນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com