جزئیات پیاده سازی پروتکل همگام سازی زمان PTPv2

معرفی

مفهوم ساخت "پست دیجیتال" در صنعت برق نیاز به همگام سازی با دقت 1 میکرو ثانیه دارد. تراکنش های مالی نیز به دقت میکروثانیه ای نیاز دارند. در این برنامه ها، دقت زمان NTP دیگر کافی نیست.

پروتکل همگام سازی PTPv2 که توسط استاندارد IEEE 1588v2 توصیف شده است، امکان دقت همزمان سازی چند ده نانوثانیه را فراهم می کند. PTPv2 به شما امکان می دهد بسته های همگام سازی را از طریق شبکه های L2 و L3 ارسال کنید.

مناطق اصلی که در آن PTPv2 استفاده می شود عبارتند از:

• انرژی؛
• تجهیزات کنترل و اندازه گیری؛
• مجتمع نظامی-صنعتی؛
• مخابرات
• بخش مالی.

این پست نحوه عملکرد پروتکل همگام سازی PTPv2 را توضیح می دهد.

ما تجربه بیشتری در صنعت داریم و اغلب این پروتکل را در کاربردهای انرژی می بینیم. بر این اساس، بررسی را با احتیاط انجام خواهیم داد برای انرژی.

چرا لازم است؟

در حال حاضر، STO 34.01-21-004-2019 PJSC Rosseti و STO 56947007-29.240.10.302-2020 PJSC FGC UES شامل الزاماتی برای سازماندهی یک گذرگاه فرآیند با همگام سازی زمان از طریق PTPv2 است.

این به این دلیل است که پایانه‌های حفاظت رله و دستگاه‌های اندازه‌گیری به گذرگاه فرآیند متصل هستند که مقادیر جریان و ولتاژ لحظه‌ای را از طریق گذرگاه پردازش با استفاده از جریان‌های به اصطلاح SV (جریان‌های چندپخشی) منتقل می‌کنند.

ترمینال های حفاظتی رله از این مقادیر برای اجرای حفاظت خلیج استفاده می کنند. اگر دقت اندازه‌گیری‌های زمان کم باشد، ممکن است برخی از حفاظت‌ها به اشتباه عمل کنند.

برای مثال، دفاع از گزینش پذیری مطلق ممکن است قربانی همگام سازی زمانی «ضعیف» شود. غالباً منطق چنین دفاعی مبتنی بر مقایسه دو کمیت است. اگر مقادیر به اندازه کافی بزرگ واگرا شوند، حفاظت فعال می شود. اگر این مقادیر با دقت زمانی 1 میلی‌ثانیه اندازه‌گیری شوند، می‌توانید اختلاف زیادی را دریافت کنید که در آن مقادیر در واقع طبیعی هستند، اگر با دقت 1 میکروثانیه اندازه‌گیری شوند.

نسخه های PTP

پروتکل PTP در ابتدا در سال 2002 در استاندارد IEEE 1588-2002 شرح داده شد و "استاندارد برای یک پروتکل هماهنگ سازی دقیق ساعت برای سیستم های اندازه گیری و کنترل شبکه" نامیده شد. در سال 2008، استاندارد به روز شده IEEE 1588-2008 منتشر شد که نسخه 2 PTP را توصیف می کند. این نسخه از پروتکل دقت و پایداری را بهبود بخشید، اما سازگاری با نسخه اول پروتکل را حفظ نکرد. همچنین در سال 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)

ناسازگار است

سازگار

-

اما، مانند همیشه، تفاوت های ظریف وجود دارد.

ناسازگاری بین PTPv1 و PTPv2 به این معنی است که دستگاه دارای PTPv1 قادر به همگام سازی با ساعت دقیقی که روی PTPv2 اجرا می شود، نخواهد بود. آنها از فرمت های مختلف پیام برای همگام سازی استفاده می کنند.

اما همچنان می‌توان دستگاه‌ها را با PTPv1 و دستگاه‌هایی با PTPv2 در یک شبکه ترکیب کرد. برای رسیدن به این هدف، برخی از سازندگان به شما اجازه می دهند نسخه پروتکل را در پورت های ساعت لبه انتخاب کنید. یعنی یک ساعت مرزی می‌تواند با استفاده از PTPv2 همگام‌سازی کند و همچنان ساعت‌های دیگر متصل به آن را با استفاده از PTPv1 و PTPv2 همگام‌سازی کند.

دستگاه های PTP چه هستند و چه تفاوتی با هم دارند؟

استاندارد IEEE 1588v2 انواع مختلفی از دستگاه ها را توصیف می کند. همه آنها در جدول نشان داده شده است.

دستگاه ها از طریق یک LAN با استفاده از PTP با یکدیگر ارتباط برقرار می کنند.

دستگاه های PTP ساعت نامیده می شوند. همه ساعت ها زمان دقیق را از ساعت استاد بزرگ می گیرند.

5 نوع ساعت وجود دارد:

ساعت استاد بزرگ

منبع اصلی زمان دقیق اغلب مجهز به یک رابط برای اتصال GPS است.

ساعت معمولی

یک دستگاه تک پورت که می تواند Master (ساعت اصلی) یا Slave (ساعت برده) باشد.

ساعت اصلی (استاد)

آنها منبع زمان دقیقی هستند که ساعت های دیگر با آن هماهنگ می شوند

ساعت برده

دستگاه پایانی که از ساعت اصلی همگام شده است

ساعت مرزی

دستگاهی با چندین پورت که می تواند Master یا Slave باشد.

یعنی این ساعت‌ها می‌توانند از ساعت اصلی برتر همگام شوند و ساعت‌های برده پایین‌تر را همگام کنند.

ساعت شفاف انتها به انتها

دستگاهی با چندین پورت که نه یک ساعت اصلی است و نه یک Slave. داده های PTP را بین دو ساعت انتقال می دهد.

هنگام انتقال داده ها، ساعت شفاف تمام پیام های PTP را تصحیح می کند.

اصلاح با اضافه کردن زمان تاخیر در این دستگاه به فیلد تصحیح در هدر پیام ارسال شده انجام می شود.

ساعت شفاف همتا به همتا

دستگاهی با چندین پورت که نه یک ساعت اصلی است و نه یک Slave.
داده های PTP را بین دو ساعت انتقال می دهد.

هنگام انتقال داده ها، ساعت شفاف تمام پیام های PTP Sync و Follow_Up را تصحیح می کند (اطلاعات بیشتر در مورد آنها در زیر).

تصحیح با افزودن تاخیر در دستگاه فرستنده و تاخیر در کانال انتقال داده به میدان تصحیح بسته ارسالی حاصل می شود.

گره مدیریت

دستگاهی که ساعت های دیگر را پیکربندی و تشخیص می دهد

ساعتهای اصلی و slave با استفاده از مهرهای زمانی در پیامهای PTP همگام می شوند. دو نوع پیام در پروتکل PTP وجود دارد:

• پیام‌های رویداد، پیام‌های همگام‌سازی شده‌ای هستند که شامل ایجاد یک مهر زمانی در زمان ارسال پیام و در زمان دریافت آن می‌شوند.
• پیام‌های عمومی - این پیام‌ها به مهر زمانی نیاز ندارند، اما ممکن است دارای مهر زمانی برای پیام‌های مرتبط باشند

پیام های رویداد

پیام های عمومی

همگام سازی
Delay_Req
Pdelay_Req
Pdelay_Resp

اعلام
پیگیری
Delay_Resp
Pdelay_Resp_Follow_Up
مدیریت
سیگنالینگ

همه انواع پیام ها با جزئیات بیشتر در زیر مورد بحث قرار خواهند گرفت.

مشکلات اصلی همگام سازی

هنگامی که یک بسته همگام سازی از طریق یک شبکه محلی منتقل می شود، در سوئیچ و در پیوند داده با تأخیر مواجه می شود. هر سوئیچ تاخیری در حدود 10 میکروثانیه ایجاد می کند که برای PTPv2 غیرقابل قبول است. پس از همه، ما باید به دقت 1 میکرو ثانیه در دستگاه نهایی دست یابیم. (این در صورتی است که ما در مورد انرژی صحبت می کنیم. سایر برنامه ها ممکن است به دقت بیشتری نیاز داشته باشند.)

IEEE 1588v2 چندین الگوریتم عملیاتی را توصیف می کند که به شما امکان می دهد تاخیر زمانی را ثبت کرده و آن را تصحیح کنید.

الگوریتم کار
در طول عملیات عادی، پروتکل در دو فاز عمل می کند.

• فاز 1 - ایجاد سلسله مراتب "ساعت اصلی - ساعت برده".
• فاز 2 - همگام سازی ساعت با استفاده از مکانیزم End-to-End یا Peer-to-Peer.

فاز 1 - ایجاد سلسله مراتب Master-Slave

هر پورت یک ساعت معمولی یا لبه ای دارای تعداد معینی حالت است (ساعت برده و ساعت اصلی). استاندارد الگوریتم انتقال بین این حالت ها را توصیف می کند. در برنامه نویسی، چنین الگوریتمی ماشین حالت محدود یا ماشین حالت نامیده می شود (جزئیات بیشتر در ویکی).

این ماشین حالت از بهترین الگوریتم ساعت اصلی (BMCA) برای تنظیم Master هنگام اتصال دو ساعت استفاده می کند.

این الگوریتم به ساعت اجازه می‌دهد تا زمانی که ساعت استاد بزرگ سیگنال GPS را از دست می‌دهد، آفلاین می‌شود و غیره، مسئولیت‌های ساعت استاد بزرگ را بر عهده بگیرد.

انتقال حالت بر اساس BMCA در نمودار زیر خلاصه شده است:


اطلاعات مربوط به ساعت در انتهای دیگر "سیم" در یک پیام ویژه (اعلام پیام) ارسال می شود. پس از دریافت این اطلاعات، الگوریتم ماشین حالت اجرا می شود و مقایسه ای انجام می شود تا ببینیم کدام ساعت بهتر است. پورت بهترین ساعت به ساعت اصلی تبدیل می شود.

یک سلسله مراتب ساده در نمودار زیر نشان داده شده است. مسیرهای 1، 2، 3، 4، 5 ممکن است حاوی یک ساعت شفاف باشند، اما در ایجاد سلسله مراتب ساعت اصلی - ساعت Slave شرکت نمی کنند.

فاز 2 - همگام سازی ساعت های معمولی و لبه

بلافاصله پس از ایجاد سلسله مراتب "ساعت اصلی - ساعت برده"، مرحله همگام سازی ساعت های معمولی و مرزی آغاز می شود.

برای همگام سازی، ساعت اصلی پیامی حاوی مهر زمانی به ساعت های برده ارسال می کند.

ساعت اصلی می تواند:

• تک مرحله؛
• دو مرحله ای

ساعت های تک مرحله ای یک پیام همگام سازی را برای همگام سازی ارسال می کنند.

یک ساعت دو مرحله ای از دو پیام برای همگام سازی استفاده می کند - Sync و Follow_Up.

برای مرحله همگام سازی می توان از دو مکانیسم استفاده کرد:

• مکانیسم تاخیر درخواست-پاسخ
• مکانیسم اندازه گیری تاخیر همتایان

ابتدا، بیایید به این مکانیسم ها در ساده ترین حالت نگاه کنیم - زمانی که از ساعت های شفاف استفاده نمی شود.

مکانیسم تاخیر درخواست-پاسخ

مکانیسم شامل دو مرحله است:

1. اندازه گیری تاخیر در ارسال پیام بین ساعت اصلی و ساعت slave. با استفاده از مکانیزم تاخیر درخواست-پاسخ انجام می شود.
2. تصحیح شیفت زمانی دقیق انجام می شود.

اندازه گیری تاخیر


t1 – زمان ارسال پیام Sync توسط ساعت اصلی. t2 - زمان دریافت پیام Sync توسط ساعت برده. t3 – زمان ارسال درخواست تاخیر (Delay_Req) ​​توسط ساعت برده. t4 – زمان دریافت Delay_Req توسط ساعت اصلی.

زمانی که ساعت برده زمان‌های t1، t2، t3 و t4 را بداند، می‌تواند میانگین تاخیر را هنگام ارسال پیام همگام‌سازی (tmpd) ​​محاسبه کند. به صورت زیر محاسبه می شود:

هنگام ارسال پیام Sync و Follow_Up، تاخیر زمانی از master تا slave محاسبه می شود - t-ms.

هنگام انتقال پیام های Delay_Req و Delay_Resp، تاخیر زمانی از Slave به Master محاسبه می شود - t-sm.

اگر مقداری عدم تقارن بین این دو مقدار رخ دهد، خطا در تصحیح انحراف زمان دقیق ظاهر می شود. خطا ناشی از این واقعیت است که تاخیر محاسبه شده میانگین تاخیر t-ms و t-sm است. اگر تاخیرها با هم برابر نباشند، زمان را به طور دقیق تنظیم نمی کنیم.

اصلاح شیفت زمانی

هنگامی که تاخیر بین ساعت اصلی و ساعت برده مشخص شد، ساعت برده تصحیح زمان را انجام می دهد.

ساعتهای Slave از پیام Sync و پیام اختیاری Follow_Up برای محاسبه افست زمان دقیق هنگام ارسال یک بسته از master به ساعتهای برده استفاده می کنند. شیفت با استفاده از فرمول زیر محاسبه می شود:

مکانیسم اندازه گیری تاخیر همتایان

این مکانیسم همچنین از دو مرحله برای همگام سازی استفاده می کند:

1. دستگاه ها تاخیر زمانی را برای همه همسایگان از طریق همه پورت ها اندازه گیری می کنند. برای این کار از مکانیزم تاخیر همتا استفاده می کنند.
2. تصحیح شیفت زمانی دقیق

اندازه گیری تاخیر بین دستگاه هایی که از حالت Peer-to-Peer پشتیبانی می کنند

تأخیر بین پورت هایی که از مکانیزم همتا به همتا پشتیبانی می کنند با استفاده از پیام های زیر اندازه گیری می شود:

وقتی پورت 1 زمان های t1، t2، t3 و t4 را بداند، می تواند میانگین تاخیر (tmld) را محاسبه کند. با استفاده از فرمول زیر محاسبه می شود:

سپس درگاه هنگام محاسبه فیلد تنظیم برای هر پیام Sync یا پیام اختیاری Follow_Up که از دستگاه عبور می کند از این مقدار استفاده می کند.

کل تأخیر برابر است با مجموع تأخیر در حین ارسال از طریق این دستگاه، متوسط ​​تأخیر در هنگام ارسال از طریق کانال داده و تأخیر موجود در این پیام، که در دستگاه های بالادست فعال شده است.

پیام‌های Pdelay_Req، Pdelay_Resp و Pdelay_Resp_Follow_Up اختیاری به شما امکان می‌دهند تا تاخیر را از master به slave و از slave به master دریافت کنید (دایره‌ای).

هر گونه عدم تقارن بین این دو مقدار یک خطای تصحیح جبران زمان ایجاد می کند.

تنظیم تغییر زمان دقیق

ساعتهای Slave از یک پیام Sync و یک پیام Follow_Up اختیاری برای محاسبه افست زمان دقیق هنگام ارسال یک بسته از Master به ساعتهای Slave استفاده می کنند. شیفت با استفاده از فرمول زیر محاسبه می شود:

مزایا تنظیم مکانیزم همتا به همتا - تاخیر زمانی هر پیام Sync یا Follow_Up با ارسال آن در شبکه محاسبه می شود. در نتیجه تغییر مسیر انتقال به هیچ وجه بر دقت تنظیم تاثیری نخواهد داشت.

هنگام استفاده از این مکانیسم، همگام سازی زمانی نیازی به محاسبه تاخیر زمانی در طول مسیری که بسته همگام سازی طی می کند، ندارد، همانطور که در مبادله اصلی انجام می شود. آن ها پیام های Delay_Req و Delay_Resp ارسال نمی شوند. در این روش، تأخیر بین ساعت‌های master و slave به سادگی در فیلد تنظیم هر پیام Sync یا Follow_Up خلاصه می‌شود.

مزیت دیگر این است که ساعت اصلی نیاز به پردازش پیام های Delay_Req را ندارد.

حالت های عملکرد ساعت های شفاف

بر این اساس، اینها نمونه های ساده ای بودند. حال فرض کنید سوئیچ ها در مسیر همگام سازی ظاهر شوند.

اگر از سوئیچ‌هایی بدون پشتیبانی PTPv2 استفاده می‌کنید، بسته همگام‌سازی روی سوئیچ تقریباً 10 میکروثانیه به تأخیر می‌افتد.

سوئیچ هایی که از PTPv2 پشتیبانی می کنند در اصطلاح IEEE 1588v2 ساعت شفاف نامیده می شوند. ساعت‌های شفاف از ساعت اصلی همگام‌سازی نمی‌شوند و در سلسله‌مراتب «ساعت اصلی - ساعت برده» شرکت نمی‌کنند، اما هنگام انتقال پیام‌های همگام‌سازی، به یاد می‌آورند که چقدر پیام توسط آنها به تأخیر افتاده است. این به شما امکان می دهد تا تاخیر زمانی را تنظیم کنید.

ساعت های شفاف می توانند در دو حالت کار کنند:

• انتها به انتها.
• نظیر به نظیر.

انتها به انتها (E2E)

ساعت شفاف E2E پیام های Sync و پیام های Follow_Up همراه را در همه پورت ها پخش می کند. حتی آنهایی که توسط برخی از پروتکل ها مسدود شده اند (مثلاً RSTP).

سوئیچ مهر زمانی دریافت بسته Sync (Follow_Up) روی پورت و ارسال آن از پورت را به خاطر می آورد. بر اساس این دو مهر زمانی، مدت زمانی که سوئیچ برای پردازش پیام نیاز دارد محاسبه می شود. در استاندارد به این زمان زمان اقامت گفته می شود.

زمان پردازش به فیلد correctionField پیام Sync (ساعت یک مرحله ای) یا Follow_Up (ساعت دو مرحله ای) اضافه می شود.

ساعت شفاف E2E زمان پردازش پیام های Sync و Delay_Req را که از سوییچ عبور می کنند اندازه گیری می کند. اما درک این نکته مهم است که تاخیر زمانی بین ساعت اصلی و ساعت slave با استفاده از مکانیزم تاخیر درخواست-پاسخ محاسبه می شود. اگر ساعت اصلی تغییر کند یا مسیر از ساعت اصلی به ساعت slave تغییر کند، تاخیر دوباره اندازه گیری می شود. این باعث افزایش زمان انتقال در صورت تغییر شبکه می شود.

ساعت شفاف P2P، علاوه بر اندازه‌گیری زمان لازم برای پردازش یک پیام توسط سوییچ، با استفاده از مکانیزم تأخیر همسایه، تأخیر پیوند داده به نزدیک‌ترین همسایه را اندازه‌گیری می‌کند.

تأخیر در هر پیوند در هر دو جهت اندازه گیری می شود، از جمله پیوندهایی که توسط برخی پروتکل ها مسدود شده اند (مانند RSTP). این به شما امکان می دهد تا در صورت تغییر ساعت استاد بزرگ یا توپولوژی شبکه، فوراً تاخیر جدید در مسیر همگام سازی را محاسبه کنید.

زمان پردازش پیام توسط سوئیچ ها و تأخیر هنگام ارسال پیام های Sync یا Follow_Up جمع می شود.

انواع پشتیبانی PTPv2 توسط سوئیچ ها

سوئیچ ها می توانند از PTPv2 پشتیبانی کنند:

• به صورت برنامه ای؛
• سخت افزار

هنگام پیاده سازی پروتکل PTPv2 در نرم افزار، سوئیچ یک مهر زمانی از میان افزار درخواست می کند. مشکل این است که سفت‌افزار به صورت چرخه‌ای کار می‌کند و باید منتظر بمانید تا چرخه فعلی تمام شود، درخواست پردازش را دریافت کند و بعد از چرخه بعدی یک برچسب زمانی صادر کند. این نیز به زمان نیاز دارد و ما با تأخیر مواجه خواهیم شد، اگرچه نه به اندازه پشتیبانی نرم افزاری PTPv2.

فقط پشتیبانی سخت افزاری PTPv2 به شما امکان می دهد دقت لازم را حفظ کنید. در این حالت مهر زمانی توسط ASIC مخصوصی که روی پورت نصب می شود صادر می شود.

فرمت پیام

تمام پیام های PTP شامل فیلدهای زیر است:

• هدر - 34 بایت.
• متن - اندازه به نوع پیام بستگی دارد.
• پسوند اختیاری است.

سربرگ

فیلد Header برای همه پیام های PTP یکسان است. حجم آن 34 بایت است.

قالب فیلد سرصفحه:

نوع پیام – شامل نوع پیام در حال انتقال است، به عنوان مثال Sync، Delay_Req، PDelay_Req و غیره.

طول پیام - شامل اندازه کامل پیام PTP، از جمله سرصفحه، بدنه و پسوند (اما به استثنای بایت های padding).

شماره دامنه - تعیین می کند که پیام به کدام دامنه PTP تعلق دارد.

Домен - اینها چندین ساعت مختلف هستند که در یک گروه منطقی جمع آوری شده و از یک ساعت اصلی هماهنگ شده اند، اما لزوما با ساعت های متعلق به دامنه متفاوتی همگام نیستند.

پرچم ها – این فیلد حاوی پرچم های مختلفی برای شناسایی وضعیت پیام است.

اصلاح فیلد - دارای زمان تاخیر بر حسب نانوثانیه است. زمان تأخیر شامل تأخیر هنگام ارسال از طریق ساعت شفاف و همچنین تأخیر هنگام ارسال از طریق کانال هنگام استفاده از حالت Peer-to-Peer است.

sourcePortIdentity – این فیلد حاوی اطلاعاتی است که این پیام از کدام پورت در ابتدا ارسال شده است.

شناسه ترتیبی - حاوی یک شماره شناسایی برای پیام های فردی است.

کنترل فیلد – فیلد مصنوع =) از نسخه اول استاندارد باقی مانده و حاوی اطلاعاتی در مورد نوع این پیام است. اساساً همان messageType است، اما با گزینه های کمتر.

logMessageInterval - این فیلد با نوع پیام تعیین می شود.

بدن

همانطور که در بالا توضیح داده شد، انواع مختلفی از پیام ها وجود دارد. این انواع در زیر توضیح داده شده است:

پیام اطلاعیه
پیام Announce برای "گفتن" ساعت های دیگر در همان دامنه در مورد پارامترهای آن استفاده می شود. این پیام به شما امکان می دهد یک سلسله مراتب ساعت اصلی - ساعت برده را تنظیم کنید.


همگام سازی پیام
پیام همگام‌سازی توسط ساعت اصلی ارسال می‌شود و حاوی زمان ساعت اصلی در زمان تولید پیام همگام‌سازی است. اگر ساعت اصلی دو مرحله‌ای باشد، مهر زمانی در پیام همگام‌سازی روی 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 برای انتقال اطلاعات بین یک یا چند ساعت و گره کنترل مورد نیاز است.

انتقال به LV

یک پیام PTP در دو سطح قابل انتقال است:

• شبکه – به عنوان بخشی از داده های IP.
• کانال - به عنوان بخشی از یک فریم اترنت.

انتقال پیام PTP از طریق UDP از طریق IP از طریق اترنت

PTP روی UDP از طریق اترنت

پروفایل ها

PTP دارای پارامترهای انعطاف پذیر بسیار زیادی است که باید پیکربندی شوند. مثلا:

• گزینه های BMCA
• مکانیسم اندازه گیری تاخیر
• فواصل و مقادیر اولیه همه پارامترهای قابل تنظیم و غیره

و علیرغم اینکه قبلاً گفته بودیم دستگاه های PTPv2 با یکدیگر سازگار هستند، این درست نیست. برای برقراری ارتباط، دستگاه ها باید تنظیمات یکسانی داشته باشند.

به همین دلیل است که به اصطلاح پروفایل های PTPv2 وجود دارد. نمایه‌ها گروه‌هایی از تنظیمات پیکربندی شده و محدودیت‌های پروتکل تعریف‌شده هستند تا بتوان همگام‌سازی زمانی را برای یک برنامه خاص پیاده‌سازی کرد.

استاندارد IEEE 1588v2 خود تنها یک نمایه را توصیف می کند - "نمایه پیش فرض". تمام پروفایل های دیگر توسط سازمان ها و انجمن های مختلف ایجاد و توصیف می شوند.

به عنوان مثال، Power Profile یا PTPv2 Power Profile توسط کمیته رله سیستم های قدرت و کمیته پست انجمن انرژی و انرژی IEEE ایجاد شد. خود پروفایل IEEE C37.238-2011 نام دارد.

نمایه توضیح می دهد که PTP می تواند منتقل شود:

• فقط از طریق شبکه های L2 (به عنوان مثال اترنت، HSR، PRP، غیر IP).
• پیام ها فقط با پخش چندپخشی منتقل می شوند.
• مکانیسم اندازه گیری تاخیر همتا به عنوان مکانیزم اندازه گیری تاخیر استفاده می شود.

دامنه پیش فرض 0، دامنه پیشنهادی 93 است.

فلسفه طراحی C37.238-2011 کاهش تعداد ویژگی های اختیاری و حفظ عملکردهای لازم برای تعامل مطمئن بین دستگاه ها و افزایش پایداری سیستم بود.

همچنین فرکانس ارسال پیام تعیین می شود:

در واقع، تنها یک پارامتر برای انتخاب در دسترس است - نوع ساعت اصلی (تک مرحله ای یا دو مرحله ای).

دقت نباید بیش از 1 میکرو ثانیه باشد. به عبارت دیگر، یک مسیر همگام سازی می تواند حداکثر شامل 15 ساعت شفاف یا سه ساعت مرزی باشد.

منبع: www.habr.com