Подробности за внедряването на протокола за синхронизиране на времето PTPv2

въведение

Концепцията за изграждане на „Цифрова подстанция” в електроенергетиката изисква синхронизация с точност от 1 μs. Финансовите транзакции също изискват микросекунда точност. В тези приложения точността на 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 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 описва няколко типа устройства. Всички те са показани в таблицата.

Устройствата комуникират помежду си през LAN чрез PTP.

PTP устройствата се наричат ​​часовници. Всички часовници вземат точния час от главния часовник.

Има 5 вида часовници:

Велосипеден часовник

Основният източник на точно време. Често оборудван с интерфейс за свързване на GPS.

Обикновен часовник

Устройство с един порт, което може да бъде главен (главен часовник) или подчинен (подчинен часовник)

Главен часовник (главен)

Те са източникът на точното време, с което се синхронизират другите часовници

Робски часовник

Крайно устройство, което се синхронизира от главния часовник

Граничен часовник

Устройство с множество портове, което може да бъде главен или подчинен.

Това означава, че тези часовници могат да се синхронизират от висшия главен часовник и да синхронизират по-ниските подчинени часовници.

Прозрачен часовник от край до край

Устройство с множество портове, което не е нито главен часовник, нито подчинен. Той предава PTP данни между два часовника.

При предаване на данни прозрачният часовник коригира всички PTP съобщения.

Корекцията се извършва чрез добавяне на времето на забавяне на това устройство към полето за корекция в заглавката на предаденото съобщение.

Peer-to-Peer прозрачен часовник

Устройство с множество портове, което не е нито главен часовник, нито подчинен.
Той предава PTP данни между два часовника.

При предаване на данни прозрачният часовник коригира всички PTP съобщения Sync и Follow_Up (повече за тях по-долу).

Корекцията се постига чрез добавяне към корекционното поле на предавания пакет на закъснението на предавателното устройство и закъснението на канала за предаване на данни.

Възел за управление

Устройство, което конфигурира и диагностицира други часовници

Главният и подчинените часовници се синхронизират с помощта на времеви клейма в PTP съобщения. Има два типа съобщения в PTP протокола:

• Съобщенията за събития са синхронизирани съобщения, които включват генериране на клеймо за време в момента на изпращане на съобщението и в момента на получаване.
• Общи съобщения - Тези съобщения не изискват клеймо за време, но могат да съдържат клеймо за свързани съобщения

Съобщения за събития

Общи съобщения

Синхронизирайте
Delay_Req
Pотлагане_Req
Pзакъснение_Resp

Обявете
Последващи действия
Delay_Resp
Pdelay_Resp_Follow_Up
управление
сигнализация

Всички видове съобщения ще бъдат разгледани по-подробно по-долу.

Основни проблеми със синхронизацията

Когато пакет за синхронизиране се предава през локална мрежа, той се забавя в комутатора и във връзката за данни. Всяко превключване ще доведе до забавяне от около 10 микросекунди, което е неприемливо за PTPv2. В крайна сметка трябва да постигнем точност от 1 μs на крайното устройство. (Това е, ако говорим за енергия. Други приложения може да изискват по-голяма точност.)

IEEE 1588v2 описва няколко работни алгоритми, които ви позволяват да записвате времезакъснението и да го коригирате.

Работен алгоритъм
При нормална работа протоколът работи на две фази.

• Фаза 1 - установяване на йерархията „Главен часовник – Подчинен часовник“.
• Фаза 2 - синхронизиране на часовника чрез механизъм End-to-End или Peer-to-Peer.

Фаза 1 - Установяване на йерархията Господар-Поробен

Всеки порт на обикновен или периферен часовник има определен брой състояния (подчинен часовник и главен часовник). Стандартът описва алгоритъма за преход между тези състояния. В програмирането такъв алгоритъм се нарича краен автомат или автомат (повече подробности в Wiki).

Тази държавна машина използва алгоритъма за най-добър главен часовник (BMCA), за да зададе главния при свързване на два часовника.

Този алгоритъм позволява на часовника да поеме отговорностите на главния часовник, когато главният часовник нагоре по веригата загуби GPS сигнал, излезе офлайн и т.н.

Преходите на състоянията според BMCA са обобщени в следната диаграма:


Информацията за часовника в другия край на „кабела“ се изпраща в специално съобщение (съобщение за обявяване). След като тази информация бъде получена, алгоритъмът на крайната машина се изпълнява и се прави сравнение, за да се види кой часовник е по-добър. Портът на най-добрия часовник става главен часовник.

Една проста йерархия е показана на диаграмата по-долу. Пътища 1, 2, 3, 4, 5 може да съдържат прозрачен часовник, но те не участват в установяването на йерархията Главен часовник - Подчинен часовник.

Фаза 2 - Синхронизиране на обикновени и периферни часовници

Веднага след установяване на йерархията „Главен часовник – Подчинен часовник“ започва фазата на синхронизиране на обикновените и граничните часовници.

За да се синхронизира, главният часовник изпраща съобщение, съдържащо клеймо за време до подчинените часовници.

Главният часовник може да бъде:

• едностепенен;
• двустепенен.

Едностепенните часовници изпращат едно съобщение за синхронизиране за синхронизиране.

Двустепенният часовник използва две съобщения за синхронизация - Sync и Follow_Up.

За фазата на синхронизация могат да се използват два механизма:

• Механизъм за забавяне на заявка-отговор.
• Механизъм за измерване на закъснението на партньора.

Първо, нека разгледаме тези механизми в най-простия случай - когато не се използват прозрачни часовници.

Механизъм за забавяне на заявка-отговор

Механизмът включва две стъпки:

1. Измерване на закъснението при предаване на съобщение между главния часовник и подчинения часовник. Извършва се чрез механизъм за забавяне на заявка-отговор.
2. Извършва се корекция на точното времеизместване.

Измерване на латентност


t1 – Време на изпращане на Sync съобщение от главния часовник; t2 – Време на получаване на Sync съобщението от подчинения часовник; t3 – Време на изпращане на заявката за забавяне (Delay_Req) ​​от подчинения часовник; t4 – Delay_Req време за приемане от главния часовник.

Когато подчиненият часовник знае времената t1, t2, t3 и t4, той може да изчисли средното закъснение при предаване на съобщението за синхронизиране (tmpd). Изчислява се, както следва:

При предаване на съобщение Sync and Follow_Up се изчислява времезакъснението от master към slave - t-ms.

При предаване на съобщения Delay_Req и Delay_Resp се изчислява времезакъснението от slave към master - t-sm.

Ако възникне някаква асиметрия между тези две стойности, тогава се появява грешка при коригиране на отклонението на точното време. Грешката се дължи на факта, че изчисленото закъснение е средната стойност на закъсненията t-ms и t-sm. Ако закъсненията не са равни едно на друго, тогава няма да коригираме точно времето.

Корекция на изместването на времето

След като закъснението между главния часовник и подчинения часовник е известно, подчиненият часовник извършва корекция на времето.

Подчинените часовници използват съобщението за синхронизиране и незадължително съобщение Follow_Up, за да изчислят точното отместване на времето при предаване на пакет от главния към подчинените часовници. Промяната се изчислява по следната формула:

Механизъм за измерване на закъснението на партньора

Този механизъм също използва две стъпки за синхронизация:

1. Устройствата измерват забавянето на времето към всички съседи през всички портове. За да направят това, те използват механизъм за забавяне на равнопоставени потребители.
2. Корекция на точното изместване на времето.

Измерване на латентност между устройства, които поддържат режим Peer-to-Peer

Закъснението между портовете, поддържащи механизма peer-to-peer, се измерва с помощта на следните съобщения:

Когато порт 1 знае времената t1, t2, t3 и t4, той може да изчисли средното забавяне (tmld). Изчислява се по следната формула:

След това портът използва тази стойност, когато изчислява полето за корекция за всяко съобщение за синхронизиране или незадължително съобщение Follow_Up, което преминава през устройството.

Общото забавяне ще бъде равно на сумата от забавянето по време на предаване през това устройство, средното забавяне по време на предаване през канала за данни и забавянето, което вече се съдържа в това съобщение, активирано на устройства нагоре по веригата.

Съобщенията Pdelay_Req, Pdelay_Resp и по избор Pdelay_Resp_Follow_Up ви позволяват да получите забавянето от главен към подчинен и от подчинен към главен (кръгов).

Всяка асиметрия между тези две стойности ще доведе до грешка при корекция на отместването на времето.

Регулиране на точното изместване на времето

Подчинените часовници използват съобщение за синхронизиране и незадължително съобщение Follow_Up, за да изчислят точното отместване на времето при предаване на пакет от главния към подчинените часовници. Промяната се изчислява по следната формула:

Предимства настройка на механизма peer-to-peer - забавянето във времето на всяко Sync или Follow_Up съобщение се изчислява, докато се предава в мрежата. Следователно промяната на пътя на предаване по никакъв начин няма да повлияе на точността на настройката.

Когато се използва този механизъм, синхронизирането на времето не изисква изчисляване на забавянето във времето по пътя, изминат от пакета за синхронизиране, както се прави при основния обмен. Тези. Съобщенията Delay_Req и Delay_Resp не се изпращат. При този метод закъснението между главния и подчинения часовник просто се сумира в полето за настройка на всяко съобщение Sync или Follow_Up.

Друго предимство е, че главният часовник е освободен от необходимостта да обработва съобщенията Delay_Req.

Режими на работа на прозрачни часовници

Съответно това бяха прости примери. Сега да предположим, че превключвателите се появяват на пътя за синхронизиране.

Ако използвате превключватели без поддръжка на PTPv2, пакетът за синхронизиране ще бъде забавен на превключвателя с приблизително 10 µs.

Превключватели, които поддържат PTPv2, се наричат ​​прозрачни часовници в терминологията на IEEE 1588v2. Прозрачните часовници не се синхронизират от главния часовник и не участват в йерархията „Главен часовник - Подчинен часовник“, но при предаване на съобщения за синхронизиране те запомнят колко време е било забавено съобщението от тях. Това ви позволява да регулирате забавянето на времето.

Прозрачните часовници могат да работят в два режима:

• От край до край.
• Партньорски.

От край до край (E2E)

Прозрачният часовник E2E излъчва съобщения за синхронизиране и придружаващи съобщения Follow_Up на всички портове. Дори тези, които са блокирани от някои протоколи (например RSTP).

Превключвателят запомня клеймото за време, когато пакетът за синхронизиране (Follow_Up) е получен на порта и кога е изпратен от порта. Въз основа на тези два времеви отпечатъка се изчислява времето, необходимо на комутатора да обработи съобщението. В стандарта това време се нарича време на престой.

Времето за обработка се добавя към полето correctionField на съобщението Sync (часовник с една стъпка) или Follow_Up (часовник с две стъпки).

Прозрачният часовник E2E измерва времето за обработка на съобщенията Sync и Delay_Req, преминаващи през комутатора. Но е важно да се разбере, че закъснението между главния часовник и подчинения часовник се изчислява с помощта на механизма заявка-отговор за забавяне. Ако главният часовник се промени или пътят от главния часовник до подчинения часовник се промени, закъснението се измерва отново. Това увеличава времето за преход в случай на промени в мрежата.

P2P прозрачният часовник, в допълнение към измерването на времето, необходимо на превключвателя за обработка на съобщение, измерва забавянето на връзката за данни към най-близкия съсед, използвайки механизъм за забавяне на съседа.

Закъснението се измерва на всяка връзка в двете посоки, включително връзки, които са блокирани от някакъв протокол (като RSTP). Това ви позволява незабавно да изчислите новото забавяне в пътя на синхронизиране, ако главният часовник или мрежовата топология се променят.

Времето за обработка на съобщения чрез превключватели и закъснението се натрупват при изпращане на съобщения за синхронизиране или последващи действия.

Типове поддръжка на PTPv2 от превключватели

Превключвателите могат да поддържат PTPv2:

• програмно;
• хардуер.

Когато внедрява протокола PTPv2 в софтуера, превключвателят изисква клеймо за време от фърмуера. Проблемът е, че фърмуерът работи циклично и ще трябва да изчакате, докато завърши текущия цикъл, вземе заявката за обработка и издаде клеймо за време след следващия цикъл. Това също ще отнеме време и ще получим забавяне, макар и не толкова значително, колкото без софтуерна поддръжка за PTPv2.

Само хардуерната поддръжка за PTPv2 ви позволява да поддържате необходимата точност. В този случай клеймото за време се издава от специален ASIC, който е инсталиран на порта.

Формат на съобщението

Всички PTP съобщения се състоят от следните полета:

• Хедър – 34 байта.
• Тяло – размерът зависи от вида на съобщението.
• Суфиксът не е задължителен.

Header

Полето Header е едно и също за всички PTP съобщения. Размерът му е 34 байта.

Формат на полето за заглавка:

messageType – съдържа вида на предаваното съобщение, например Sync, Delay_Req, PDelay_Req и др.

messageLength – съдържа пълния размер на PTP съобщението, включително заглавка, тяло и суфикс (но без байтове за допълване).

номер на домейн – определя към кой PTP домейн принадлежи съобщението.

Име на домейна - това са няколко различни часовника, събрани в една логическа група и синхронизирани от един главен часовник, но не непременно синхронизирани с часовници, принадлежащи към различен домейн.

знамена – Това поле съдържа различни флагове за идентифициране на състоянието на съобщението.

correctionField – съдържа времето на забавяне в наносекунди. Времето на забавяне включва забавянето при предаване през прозрачния часовник, както и забавянето при предаване през канала при използване на режим Peer-to-Peer.

sourcePortIdentity – това поле съдържа информация от кой порт първоначално е изпратено това съобщение.

последователностID – съдържа идентификационен номер за отделни съобщения.

controlField – артефактно поле =) Остава от първата версия на стандарта и съдържа информация за вида на това съобщение. По същество същото като messageType, но с по-малко опции.

logMessageInterval – това поле се определя от типа на съобщението.

Body

Както беше обсъдено по-горе, има няколко вида съобщения. Тези видове са описани по-долу:

Съобщение за съобщение
Съобщението Announce се използва, за да „каже“ на други часовници в рамките на същия домейн за неговите параметри. Това съобщение ви позволява да настроите йерархия Master Clock - Slave Clock.


Синхронизиране на съобщение
Съобщението за синхронизиране се изпраща от главния часовник и съдържа часа на главния часовник към момента на генериране на съобщението за синхронизиране. Ако главният часовник е двустепенен, тогава клеймото за време в съобщението за синхронизиране ще бъде зададено на 0 и текущото клеймо за време ще бъде изпратено в свързаното съобщение Follow_Up. Съобщението за синхронизиране се използва и за двата механизма за измерване на латентността.

Съобщението се предава чрез Multicast. По желание можете да използвате Unicast.

Съобщение Delay_Req

Форматът на съобщението Delay_Req е идентичен на съобщението за синхронизиране. Подчиненият часовник изпраща 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 данни.
• Канал – като част от Ethernet рамка.

Предаване на PTP съобщение през UDP през IP през Ethernet

PTP през UDP през Ethernet

Профил

PTP има доста гъвкави параметри, които трябва да бъдат конфигурирани. Например:

• Опции на BMCA.
• Механизъм за измерване на латентността.
• Интервали и начални стойности на всички конфигурируеми параметри и др.

И въпреки факта, че по-рано казахме, че PTPv2 устройствата са съвместими едно с друго, това не е вярно. Устройствата трябва да имат еднакви настройки, за да комуникират.

Ето защо има така наречените PTPv2 профили. Профилите са групи от конфигурирани настройки и дефинирани протоколни ограничения, така че синхронизирането на времето да може да бъде приложено за конкретно приложение.

Самият стандарт IEEE 1588v2 описва само един профил – „Профил по подразбиране“. Всички останали профили са създадени и описани от различни организации и асоциации.

Например Power Profile или PTPv2 Power Profile е създаден от Комитета за препредаване на енергийни системи и Комитета по подстанции на IEEE Power and Energy Society. Самият профил се нарича IEEE C37.238-2011.

Профилът описва, че PTP може да се предава:

• Само през L2 мрежи (т.е. Ethernet, HSR, PRP, не-IP).
• Съобщенията се предават само чрез Multicast излъчване.
• Като механизъм за измерване на забавяне се използва механизъм за измерване на равностойно забавяне.

Домейнът по подразбиране е 0, препоръчителният домейн е 93.

Философията на дизайна на C37.238-2011 беше да се намали броят на опционалните функции и да се запазят само необходимите функции за надеждно взаимодействие между устройствата и повишена стабилност на системата.

Също така се определя честотата на предаване на съобщения:

Всъщност само един параметър е достъпен за избор - типът на главния часовник (едностепенен или двустепенен).

Точността трябва да бъде не повече от 1 μs. С други думи, един път за синхронизация може да съдържа максимум 15 прозрачни часовника или три гранични часовника.

Източник: www.habr.com