Въведение
Концепцията за изграждане на "Цифрова подстанция" в електроенергетиката изисква синхронизация с точност 1 µs. За извършване на финансови транзакции също е необходима точност в микро секунди. При тези приложения точността на времето на NTP вече не е достатъчна.
Протоколът за синхронизация PTPv2, описан в стандарта IEEE 1588v2, позволява постигане на точност на синхронизация в десетки наносекунди. PTPv2 позволява изпращане на пакети за синхронизация през L2 и L3 мрежи.
Основните области, в които се прилага PTPv2, са:
- електроенергетика;
- контролно-измервателно оборудване;
- военно-промишлен комплекс;
- телеком;
- финансов сектор.
В този пост се разглежда как работи протоколът за синхронизация PTPv2.
Ние имаме повече опит в индустрията и често се сблъскваме с този протокол в електроенергийни приложения. Съответно, и прегледът ще бъде фокусиран .
Защо е необходим?
В момента в СТО 34.01-21-004-2019 на ПАО „Ростети“ и в СТО 56947007-29.240.10.302-2020 на ПАО „ФСК ЕЭС“ са посочени изисквания за организация на шината на процеса с осигуряване на времевата синхронизация чрез PTPv2.
Това е свързано с факта, че към шината на процеса са свързани терминали за релейна защита и измервателни устройства, които чрез шината на процеса, с помощта на така наречените SV потоци (multicast потоци), предават моментни стойности на ток и напрежение.
Терминалите за релейна защита използват тези стойности за реализация на защитите на присъединенията. Ако точността на измерванията по време е малка, то някои защити могат да сработят фалшиво.
Например, жертва на "слабата" синхронизация на времето могат да станат защитите на абсолютната селективност. Често логиката на подобни защити се основава на сравнение на две величини. Ако величините се разминават с достатъчно голямо значение, защитата сработва. Ако тези величини се измерят с точност на времето 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)
Несъвместими
Съвместими
—
Но, както винаги, има нюанси.
Несъвместимостта между PTPv1 и PTPv2 предполага, че устройство с поддръжка на PTPv1 не може да се синхронизира от точни часовници, работещи с PTPv2. За синхронизация те използват различни формати на съобщения.
Но е все пак възможно да комбинирате устройства с PTPv1 и PTPv2 в една и съща мрежа. За целта някои производители позволяват на портовете на граничните часовници да избират версия на протокола. Тоест граничните часовници могат да се синхронизират с PTPv2 и в същото време да синхронизират други свързани часовници и с PTPv1, и с PTPv2.
PTP устройства. Какви видове съществуват и с какво се различават?
Стандартът IEEE 1588v2 описва няколко типа устройства. Всички те са представени в таблицата.
Устройствата взаимодействат помежду си през локалната мрежа, използвайки PTP.
PTP устройствата се наричат часовници. Всички часовници получават точно време от гроссмейстерски часовници.
Съществуват 5 типа часовници:
Grandmaster clock (Гроссмейстерски часовник)
Основен източник на точно време. Често са оборудвани с интерфейс за свързване на GPS.
Ordinary Clock (Обричайни часовник)
Устройство с един порт, което може да бъде мастер (водещи часовници) или слейв (ведоми часовници)
Водещи часовници (мастър)
Служат като източник на точно време, по който се синхронизират другите часовници
Ведомите часовници (слейв)
Крайните устройства, които се синхронизират с водещите часовници
Boundary Clock (Гранични часовници)
Устройство с няколко порта, което може да бъде или мастер, или слейв.
Тоест, тези часовници могат да се синхронизират от надзорни водещи часовници и да синхронизират подчинени ведомите часовници.
Прозрачни часовници с End-to-End работа
Устройство с множество портове, което не е нито водещи, нито следващи часовници. То предава PTP данни между два часовника.
При предаване на данни, прозрачните часовници коригират всички PTP съобщения.
Корекцията се случва чрез добавяне на времеви закъснение на това устройство в полето за корекция в заглавката на предавано съобщение.
Прозрачни часовници с Peer-to-Peer работа
Устройство с множество портове, което не е нито водещи, нито следващи часовници.
То предава PTP данни между два часовника.
При предаване на данни, прозрачните часовници коригират всички PTP съобщения Sync и Follow_Up (за тях ще говорим по-подробно по-долу).
Корекцията се постига чрез добавяне към полето за корекция на предавания пакет закъснение на предаващото устройство и закъснение на канала за предаване на данни.
Управляващ узел
Устройство, което конфигурира и диагностицира други часовници
Водещи и следващи часовници се синхронизират чрез времеви маркери в PTP съобщения. Има два типа съобщения в PTP протокола:
- Съобщения за събития – това са синхронизирани съобщения, които предвиждат генерирането на времеви маркер в момента на изпращане на съобщението и в момента на неговото получаване
- Общи съобщения – тези съобщения не изискват времеви маркери, но могат да съдържат времеви маркери за свързани съобщения
Съобщения за събития
Общи съобщения
Sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Announce
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Управление
Сигнализация
Накрая ще разгледаме всички типове съобщения по-подробно.
Основни проблеми със синхронизацията
При предаване на пакета за синхронизация през локална мрежа, той се забавя на суич и в канала за предаване на данни. Всеки суич предизвиква забавяне от около 10 µs, което е неприемливо за PTPv2. Важно е на крайното устройство да получим точност от 1 µs. (Това е важно за енергетиката. Други приложения може да изискват и по-голяма точност.)
В IEEE 1588v2 са описани няколко алгоритма, които позволяват фиксирането на времевото закъснение и неговата корекция.
Алгоритъм на работа
При нормална работа протоколът функционира в две фази.
- Фаза 1 – установяване на йерархията „Водещи часовници – Следващи часовници“.
- Фаза 2 – синхронизация на часовниците чрез механизма End-to-End или Peer-to-Peer.
Фаза 1 — Установка на слоевата „Майстор-Роб“
Всеки порт на обикновените или гранични часовници има определен брой състояния (подчинени и водещи часовници). Стандартът описва алгоритъм за преход между тези състояния. В програмирането такъв алгоритъм се нарича краен автомат или машина на състояния (повече в Wiki).
Този краен автомат използва алгоритъма Best Master Clock Algorithm (BMCA) за избор на майстора при свързването на два часовника.
Този алгоритъм позволява на часовниците да поемат задълженията на гросмайсторските часовници, когато горните гросмайсторски часовници загубят сигнал от GPS, бъдат изключени от мрежата и т.н.
Преходите между състоянията според BMCA са кратко показани на следната схема:
Информацията за часовниците в другия край на „вярата“ се изпраща в специално съобщение (Announce message). Когато тази информация бъде получена, алгоритъмът на машината на състоянията обработва и сравнява кои часовници са по-добри. Портът на най-добрите часовници става водещ.
Простата йерархия е показана на схемата по-долу. Пътища 1, 2, 3, 4, 5 могат да съдържат прозрачни часовници (Transparent clock), но те не участват в установяването на йерархията „Водещи часовници – Подчинени часовници“.
Фаза 2 — Синхронизация на обикновените и гранични часовници
Незабавно след установяването на йерархията „Водещи часовници – Подчинени часовници“ започва фазата на синхронизация на обикновените и гранични часовници.
За синхронизация водещите часовници изпращат на подчинените часовници съобщение, съдържащо времеви маркер.
Водещите часовници могат да бъдат:
- едностепенни;
- двустепенни.
Едностепенните часовници за синхронизация изпращат едно съобщение Sync.
Двустепенните часовници за синхронизация използват две съобщения – Sync и Follow_Up.
За фазата на синхронизация могат да се използват два механизма:
- Механизмът за забавяне на заявката-отговор (Delay request-response mechanism).
- Механизмът за измерване на забавянето на съседен възел (Peer delay measurement mechanism).
Първо ще разгледаме тези механизми в най-простия случай – когато не се използват прозрачни часовници.
Механизмът за забавяне на заявката-отговор (Delay request-response mechanism)
Механизмът предполага две стъпки:
- Измерване на забавяне при предаване на съобщение между водещите и подчинените часовници. Извършва се с помощта на механизма за заявка-отговор за забавяне.
- Извършва се корекция на изместването на точното време.
Измерване на забавянето
t1 – Час на изпращане на съобщение Sync от водещите часовници; t2 – Час на прием на съобщение Sync от следващите часовници; t3 – Час на изпращане на искане за забавяне (Delay_Req) от следващите часовници; t4 – Час на приемане на Delay_Req от водещите часовници.
Когато следващите часовници знаят времето t1, t2, t3 и t4, те могат да изчислят средната забавяне при предаване на съобщение за синхронизация (tmpd). То се изчислява по следния начин:
При предаване на съобщения Sync и Follow_Up се изчислява времевата забавяне от водещия часовник към следващия – t-ms.
При предаване на съобщения Delay_Req и Delay_Resp се изчислява времевата забавяне от следващия часовник към водещия – t-sm.
Ако между тези две стойности настъпи асиметрия, възниква грешка в корекцията на точния час. Грешката се обуславя от факта, че изчислената забавяне е средно от забавянията t-ms и t-sm. Ако забавянията не са равни, то ще коригираме времето неточно.
Корекция на изместването на точния час
След като забавянето между водещите и следващите часовници е известно, следващите часовници извършват корекция на времето.
Следващите часовници използват съобщение Sync и опционално съобщение Follow_Up за изчисляване на изместването на точния час по време на предаване на пакета от водещите към следващите часовници. Изместването се изчислява по следната формула:
Механизъм за измерване на забавянето на съседен елемент (Peer delay measurement mechanism)
Този механизъм също използва два етапа за синхронизация:
- Устройствата измерват времевото забавяне до всички съседи през всичките порти. За това те използват механизма за забавяне на съседите.
- Корекция на изместването на точния час.
Измерване на забавянето между устройствата, поддържащи режим Peer-to-Peer
Забавлението между портовете, поддържащи механизма peer-to-peer, се измерва с помощта на следните съобщения:
Когато на порт 1 е известно времето t1, t2, t3 и t4, той може да изчисли средното забавяне (tmld). То се изчислява по следната формула:
След това портът използва това значение при изчисляването на полето за корекция за всяко съобщение Sync или опционално съобщение Follow_Up, които минават през това устройство.
Крайната забавяне ще бъде равна на сумата от забавянето при предаване през това устройство, средното забавяне при предаване през канал за данни и вече съществуващото забавяне в това съобщение, включено на надлежните устройства.
Съобщенията Pdelay_Req, Pdelay_Resp и опционалното Pdelay_Resp_Follow_Up позволяват получаване на закъснение от майстора към слейва и от слейва към майстора (кръгово).
Всяка асиметрия между тези две стойности ще доведе до грешка в корекцията на точността на времето.
Корекция на точността на времето
Ведомите часовници използват Sync-съобщение и опционално Follow_Up съобщение за изчисляване на корекцията на точността на времето при предаване на пакета от водещите часовници към ведомите. Корекцията се изчислява по следната формула:
Предимствата на механизма с корекция peer-to-peer – закъснението на всяко Sync или Follow_Up съобщение се изчислява по време на предаването му в мрежата. Следователно, промяната на пътя на предаване не влияе по никакъв начин на точността на корекцията.
При използване на този механизъм синхронизацията на времето не изисква изчисление на закъснението на пътя, по който е преминал пакета за синхронизация, както се прави при основния обмен. Т.е. съобщенията Delay_Req и Delay_Resp не се изпращат. В този метод закъснението между водещите и ведомите часовници просто се сумира в полето за корекция на всяко Sync или Follow_Up съобщение.
Още едно предимство – водещите часовници са освободени от необходимостта да обработват съобщенията Delay_Req.
Режими на работа на прозрачните часовници
Съответно, бяха разгледани прости примери. А сега да предположим, че по пътя на синхронизацията се появяват суичове.
Ако се използват суичове без поддръжка на PTPv2, пакетът за синхронизация ще бъде задържан на суича за около 10 μs.
Суичовете с поддръжка на PTPv2 в терминологията на IEEE 1588v2 се наричат прозрачни часовници (Transparent clock). Прозрачните часовници не се синхронизират от водещите часовници и не участват в иерархията „Водещи часовници – Ведомите часовници“, но при предаване на съобщенията за синхронизация запомнят за колко време съобщението е било задържано на тях. Това позволява корекция на закъснението на времето.
Прозрачните часовници могат да работят в два режима:
- End-to-End.
- Peer-to-Peer.
End-to-End (E2E)
Прозрачните часовници E2E предават съобщенията Sync и съпътстващите съобщения Follow_Up на всички портове. Дори на тези, които са блокирани от определени протоколи (например, RSTP).
Комутатор запомня времевата метка, когато пакет Sync (Follow_Up) е приет на порта и когато е изпратен от порта. На базата на тези две времеви метки се изчислява времето за обработка на съобщенията от комутатора. В стандарта това време се нарича residence time.
Времето за обработка се добавя в полето correctionField на съобщението Sync (едностепенни часовници) или Follow_Up (двустепенни часовници).
Прозрачните часовници E2E измерват времето за обработка на съобщенията Sync и Delay_Req, преминаващи през комутатора. Но е важно да се разбере, че забавянето на времето между основните часовници и ведомите часовници се изчислява с помощта на механизма за запитване-отговор за забавяне. Ако основните часовници се променят или се промени пътят от основните часовници до ведомите, забавянето се измерва отново. Това увеличава времето на преходното състояние в случай на промени в мрежата.
Прозрачните часовници P2P, освен че измерват времето за обработка на съобщението от комутатора, измерват забавянето в канала за предаване на данни до най-близкия съсед, използвайки механизма за измерване на забавянето на съседния възел.
Забавянето се измерва на всеки канал в двете посоки, включително канали, които са блокирани от някакъв протокол (например, RSTP). Това позволява веднага да се изчисли новото забавяне на пътя за синхронизация, ако основните часовници или топологията на мрежата са се променили.
Времето за обработка на съобщенията от комутаторите и времето за забавяне се акумулират при предаване на съобщения Sync или Follow_Up.
Типове поддръжка на PTPv2 от комутаторите
Комутаторите могат да поддържат PTPv2:
- софтварно;
- хардуерно.
При софтуерна реализация на протокола PTPv2 комутаторът запитва времева метка от фърмуера. Проблемът е, че фърмуерът работи циклично, и ще трябва да изчакаме, докато завърши текущия цикъл, обработи запитването и при изтичането на следващия цикъл издаде времева метка. За това също ще отнеме време и ще получим забавяне, макар и не толкова съществено, колкото без софтуерна поддръжка на PTPv2.
Необходимата прецизност може да бъде спазена само с хардуерна поддръжка на PTPv2. В този случай издаването на времевата метка се извършва от специален ASIC, който е инсталиран на порта.
Формат на съобщението
Всички съобщения PTP се състоят от следните полета:
- Header – 34 байта.
- Body – размерът зависи от типа съобщение.
- Suffix – опционално.
Header
Заглавието на Header е едно и също за всички PTP съобщения. Размерът му е 34 байта.
Формат на полето Header:
messageType – съдържа типа на предаваното съобщение, например Sync, Delay_Req, PDelay_Req и т.н.
messageLength – съдържа общия размер на PTP съобщението, включително header, body и suffix (но без запълващите байтове).
domainNumber – определя принадлежността на съобщението към конкретен домейн PTP домейн.
Домейн – това е няколко различни часовника, събрани в една логическа група и синхронизирани от един водещ часовник, но не непременно синхронизирани с часовниците, принадлежащи на друг домейн.
flags – това поле съдържа различни флагове за идентифициране на състоянието на съобщението.
correctionField – съдържа забавяне в наносекунди. Забавянето включва забавянето при предаване през прозрачни часовници, а също така и забавянето при предаване през канала при използване на режим Peer-to-Peer.
sourcePortIdentity – това поле съдържа информация за порта, от който първоначално е изпратено даденото съобщение.
sequenceID – съдържа идентификационен номер за отделни съобщения.
controlField – поле-артефакт=) То е останало от първата версия на стандарта и съдържа информация за типа на това съобщение. По същество, същото, което е и messageType, но с по-малко опции.
logMessageInterval – това поле се определя от типа на съобщението.
Body
Както бе обсъдено по-горе, съществуват няколко типа съобщения. Тези типове са описани по-долу:
Съобщение Announce
Съобщението Announce се използва, за да "разкаже" на другите часовници в един домейн за свои параметри. Това съобщение позволява установяването на йерархията "Водещ часовник – Ведом часовник".
Съобщение 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 се изпраща опционално от водещите часовници и съдържа времето на изпращане съобщения Sync от майстора. Съобщение 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 се използва само за механизма за измерване на закъснението на съседния възел.
Управляващи съобщения (Съобщение Management)
Управляващите съобщения PTP са необходими за предаване на информация между един или няколко часовника и управляващия възел.
Предаване в ЛВ
PTP-съобщение може да се предава на два нива:
- Мрежово – в състава на IP-данни.
- Канално – в състава на Ethernet-рамка.
Предаване на съобщение PTP чрез UDP през IP чрез Ethernet
PTP през UDP през Ethernet
Профили
PTP има достатъчно много „гъвкави“ параметри, които трябва да се настроят. Например:
- Опции BMCA.
- Механизъм за измерване на закъснението.
- Интервали и начални стойности на всички конфигурируеми параметри и т.н.
И въпреки че по-рано казахме, че устройствата PTPv2 са съвместими помежду си, всъщност не е така. Устройствата трябва да имат еднакви настройки, за да взаимодействат.
Затова съществуват така наречените PTPv2 профили. Профилите представляват групи от конфигурирани настройки и специфични ограничения на протокола, за да може да се реализира синхронизация на времето за конкретно приложение.
Самият стандарт IEEE 1588v2 описва само един профил – 'Default Profile'. Всички останали профили са създадени и описани от различни организации и асоциации.
Например, профилът за електрическите мрежи или PTPv2 Power Profile е създаден от комитета Power Systems Relaying Committee и комитета Substation Committee на института IEEE Power and Energy Society. Самият профил носи името IEEE C37.238-2011.
Профилът описва как PTP може да бъде предаван:
- Само през L2 мрежи (т.е. Ethernet, HSR, PRP, не IP).
- Съобщенията се предават само чрез Multicast разпространение.
- Като механизъм за измерване на закъсненията се използва механизъм за измерване на забавяне между връстници.
Домейн по подразбиране – 0, препоръчителен домейн – 93.
В философията на създаването на C37.238-2011 бе заложено желанието да се намали броят на опционалните характеристики и да се оставят само необходимите функции за надеждна взаимовръзка между устройствата и повишаване на стабилността на системата.
Освен това е определена честота на предаване на съобщенията:
Всъщност за избора е наличен само един параметър – типът на водещите часовници (едностепенни или двустепенни).
Точността не трябва да бъде по-голяма от 1 μs. С други думи, в един път на синхронизация могат да бъдат включени максимум 15 прозрачни часовници или три гранични часовника.
Източник: habr.com
