Подробиці реалізації протоколу синхронізації часу PTPv2

Запровадження

Концепція побудови "Цифрової підстанції" в електроенергетиці потребує синхронізації з точністю 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 і мав назву "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". У 2008 році було випущено оновлений стандарт IEEE 1588-2008, який описує PTP Version 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 Transparent Clock (Прозорий годинник, що працює в режимі End-to-End)

Пристрій з кількома портами, який не є ні ведучим годинником, ні веденим. Воно передає дані PTP між двома годинами.

При передачі даних прозорий годинник коригує всі PTP-повідомлення.

Коригування відбувається за рахунок додавання часу затримки на цьому пристрої в полі корекції в заголовку повідомлення, що передається.

Peer-to-Peer Transparent Clock (Прозорий годинник, що працює в режимі Peer-to-Peer)

Пристрій з кількома портами, який не є ні ведучим годинником, ні веденим.
Воно передає дані PTP між двома годинами.

При передачі даних прозорий годинник коригує всі PTP-повідомлення Sync і Follow_Up (про них докладніше розказано нижче).

Коригування досягається за рахунок додавання до поля коригування переданого пакета затримки на передавальному пристрої та затримки на каналі передачі даних.

Management Node (Керуючий вузол)

Пристрій, який конфігурує та діагностує інший годинник

Провідний та керований годинник синхронізується за допомогою позначок часу в PTP-повідомленнях. Є два типи повідомлень у PTP-протоколі:

• Event Messages – це синхронізовані повідомлення, які передбачають генерацію мітки часу в момент відправлення повідомлення та в момент його прийому
• General Messages – ці повідомлення не потребують позначок часу, але можуть містити позначки часу для пов'язаних повідомлень

Повідомлення про події

Загальні повідомлення

Синхронізація
Delay_Req
Pdelay_Req
Pdelay_Resp

Оголосити
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
управління
Сигналізація

Далі будуть розглянуті всі типи повідомлень докладніше.

Основні проблеми синхронізації

При передачі пакета синхронізації через локальну мережу він затримується на комутаторі та каналі передачі. Будь-який комутатор даватиме затримку близько 10 мкс, що неприпустимо для PTPv2. Адже нам на кінцевому пристрої потрібно отримати точність 1 мкс. (Це якщо йдеться про енергетику. Інші програми можуть вимагати і більшої точності.)

У 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)

Механізм передбачає два кроки:

1. Вимірювання затримки при передачі повідомлення між ведучим годинником і веденим. Виконується за допомогою механізму запиту-відповіді затримки.
2. Корекція зсуву точного часу.

Вимірювання затримки


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)

Цей механізм також використовує два кроки для синхронізації:

1. Пристрої вимірюють затримку часу всіх сусідів через всі порти. Для цього вони використовують peer delay mechanism.
2. Коригування зсуву точного часу.

Вимірювання затримки між пристроями, які підтримують режим 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.
• Одноранговий.

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 належить повідомлення.

домен – це кілька різних годинників, зібраних в одну логічну групу та синхронізованих від одного провідного годинника, але не обов'язково синхронізованих з годинником, що належить до іншого домену.

прапори – це поле містить різні прапори для визначення статусу повідомлення.

correctionField - Містить час затримки в наносекундах. Час затримки включає затримку при передачі через прозорий годинник, а також затримку при передачі через канал при використанні режиму Peer-to-Peer.

sourcePortIdentity - Це поле містить інформацію про те, з якого порту було спочатку надіслано це повідомлення.

sequenceID – містить ідентифікаційний номер індивідуальних повідомлень.

controlField – поле-артефакт=) Воно залишилося від першої версії стандарту і містить інформацію про тип даного повідомлення. По суті, те саме, що і messageType, але з меншою кількістю опцій.

logMessageInterval - Це поле визначається типом повідомлення.

тіло

Як було зазначено вище, існує кілька типів повідомлень. Ці типи описані нижче:

Повідомлення 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-розсилкою.
• Як механізм вимірювання затримки використовується Peer delay measurement mechanism.

Домен за замовчуванням – 0, рекомендований домен – 93.

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

Також визначено частоту передачі повідомлень:

По суті для вибору доступний лише один параметр – тип ведучих годинників (одноступінчастий або двоступінчастий).

Точність має бути не більше 1 мкс. Іншими словами в одному шляху синхронізації може міститися максимально 15 прозорих годинників або три граничних годинника.

Джерело: habr.com