Въведение
Концепцията за изграждане на "Цифрова подстанция" в електрическите мрежи изисква синхронизация с точност от 1 микросекунда. За провеждане на финансови транзакции също се изисква точност в микросекунди. В тези приложения точността на времето на NTP вече не е достатъчна.
Протоколът за синхронизация PTPv2, описан в стандарта IEEE 1588v2, позволява постигане на точност на синхронизация в рамките на няколко десетки наносекунди. PTPv2 позволява изпращането на синхронизиращи пакети през L2 и L3 мрежи.
Основните области, в които се прилага PTPv2, са:
- електрическите мрежи;
- контролно-измервателно оборудване;
- оборонно-промишления комплекс;
- телеком;
- финансовият сектор.
В този пост се разглежда как работи протоколът за синхронизация PTPv2.
Имаме повече опит в индустрията и често срещаме този протокол в приложения за електрическите мрежи. Следователно, и прегледът ще бъде с акцент .
Защо е необходим?
Към момента в СТО 34.01-21-004-2019 на ПАО "Россети" и в СТО 56947007-29.240.10.302-2020 на ПАО "ФСК ЕЭС" съдържат изисквания за организация на процесната шина с осигуряване на синхронизация на времето чрез PTPv2.
Това е свързано с факта, че към процесната шина са свързани терминали за релейна защита и измервателни устройства, които чрез процесната шина, с помощта на т. нар. SV-поток (multicast потоци), предават моментни стойности на ток и напрежение.
Терминалите за релейна защита използват тези стойности за реализиране на защити на присъединенията. Ако точността на измерванията по време е малка, то някои защити могат да сработят фалшиво.
Например, жертва на "слаба" синхронизация на времето могат да станат защитите с абсолютна селективност. Често логиката на подобни зашити се изгражда на сравнение на две величини. Ако величините се различават значително, защитата сработва. Ако тези величини бъдат измерени с точност на времето от 1 мс, може да се получи голямо разминаване там, където стойностите в действителност са в нормата, ако ги измерим с точност 1 мкс.
Версии на 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 часовник (Ordinary Clock)
Устройство с един порт, което може да бъде мастър (водещи часовници) или слейв (ведомите часовници)
Водещи часовници (мастър)
Са източник на точно време, по който се синхронизират другите часовници
Ведомите часовници (слейв)
Крайните устройства, които се синхронизират от водещите часовници
Гранични часовници (Boundary Clock)
Устройство с няколко порта, което може да бъде мастър или слейв.
Тоест, тези часовници могат да се синхронизират от по-горните водещи часовници и да синхронизират по-долните ведомите часовници.
Прозрачни часовници с край до край (End-to-end Transparent Clock)
Устройство с многопортова конфигурация, което не е нито водещ, нито следящ часовник. То предава PTP данни между два часовника.
По време на предаване на данни, прозрачните часовници коригират всички PTP съобщения.
Корекцията става чрез добавяне на времево забавяне на устройството в полето за корекция в заглавката на предаваното съобщение.
Прозрачни часовници Peer-to-Peer (Peer-to-Peer Transparent Clock)
Устройство с многопортова конфигурация, което не е нито водещ, нито следящ часовник.
То предава PTP данни между два часовника.
По време на предаване на данни, прозрачните часовници коригират всички PTP съобщения Sync и Follow_Up (по-подробно за тях по-долу).
Корекцията се постига чрез добавяне на забавяне в полето за корекция на предаването, което е на предаващото устройство, и на забавяне в канала за предаване на данни.
Управляващ възел (Management Node)
Устройство, което конфигурира и диагностицира други часовници.
Водещите и следящите часовници се синхронизират с помощта на времеви маркировки в PTP съобщенията. Има два типа съобщения в PTP протокола:
- Съобщения за събития (Event Messages) – това са синхронизирани съобщения, които предвиждат генериране на времева маркировка в момента на изпращане на съобщението и в момента на получаване.
- Общи съобщения (General Messages) – тези съобщения не изискват времеви маркировки, но могат да съдържат времеви маркировки за свързани съобщения.
Съобщения за събития
Общи съобщения
Sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Обявление (Announce)
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Управление (Management)
Сигнализиране (Signaling)
Следва да разгледаме всички типове съобщения по-подробно.
Основни проблеми при синхронизация
При предаване на пакет за синхронизация през локална мрежа, той се забавя на комутатора и в канала за предаване на данни. Всеки комутатор ще предизвика забавяне около 10 мкс, което е неприемливо за PTPv2. На крайното устройство се изисква точност от 1 мкс. (Това е важно за енергийния сектор. Други приложения могат да изискват и по-голяма точност.)
В IEEE 1588v2 са описани няколко алгоритма, които позволяват фиксиране на времево забавяне и неговото коригиране.
Алгоритъм на работа
При нормална работа протоколът функционира в две фази.
- Фаза 1 — установяване на иерархия «Водещи часовници – Следящи часовници».
- Фаза 2 — синхронизиране на часовниците с механизма край до край или 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 мкс.
Комутаторите с поддръжка на 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 съобщението, включително заглавката, тялото и суфикса (но без запълващите байтове).
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 са необходими за прехвърляне на информация между един или повече часовници и управляващия възел.
Предаване в LV
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 мкс. С други думи, в един път за синхронизация могат да бъдат включени максимум 15 прозрачни часовника или три крайни часовника.
Източник: habr.com
