Цифрова Підстанція – це тренд у енергетиці. Якщо Ви близькі до теми, то, напевно, чули, що великий обсяг даних передається у вигляді multicast-потоків. Але чи знаєте Ви, як цими multicast-потоками керувати? Які інструменти керування потоками застосовуються? Що рекомендує нормативна документація?
Усім, кому цікаво розібратися у цій темі, – welcome під кат!
Як дані передаються в мережі та навіщо управляти multicast-потоками?
Перш ніж переходити безпосередньо до Цифрової Підстанції та нюансів побудови ЛОМ, пропоную короткий лікнеп за типами передачі даних та протоколами передачі даних для роботи з multicast-потоками. Лікнеп ми сховали під спойлер.
Типи передачі
Типи трафіку в ЛОМ
Існує чотири типи передачі даних:
- Broadcast – широкомовне розсилання.
- Unicast – обмін повідомленнями між двома пристроями.
- Multicast – розсилання повідомлень на певну групу пристроїв.
- Unknown Unicast – широкомовне розсилання з метою знайти один пристрій.
Щоб не заплутати карти, давайте перш ніж переходити до multicast, коротко проговоримо про інші три типи передачі даних.
Перш за все, давайте згадаємо, що всередині ЛОМ адресація між пристроями виконується на основі MAC-адрес. У будь-якому повідомленні, що передається, є поля SRC MAC і DST MAC.
SRC MAC – source MAC – MAC-адреса відправника.
DST MAC – destination MAC – MAC-адреса одержувача.
Комутатор виходячи з цих полів передає повідомлення. Він дивиться DST MAC, знаходить його у таблиці MAC-адрес і відправляє повідомлення той порт, який вказаний у таблиці. Також він дивиться і SRC MAC. Якщо такої MAC-адреси в таблиці немає, то додається нова пара MAC-адреса - порт.
Тепер поговоримо докладніше про типи передачі.
Одноадресний
Unicast – це адресна передача повідомлень між двома пристроями. Власне, це передача даних точка-точка. Іншими словами, два пристрої для спілкування один з одним завжди використовують Unicast.
Передача Unicast-трафіку
Віщати
Broadcast – це широкомовне розсилання. Тобто. розсилка, коли один пристрій надсилає повідомлення всім іншим пристроям у мережі.
Щоб надіслати широкомовне повідомлення, відправник як DST MAC вказує адресу FF:FF:FF:FF:FF:FF.
Передача Broadcast-трафіку
Unknown Unicast
Unknown Unicast, на перший погляд, дуже схожий на Broadcast. Але різниця між ними — повідомлення надсилається всім учасникам мережі, але призначене лише одному пристрою. Це як повідомлення у торговому центрі із проханням перепаркувати авто. Почують це повідомлення всі, але відгукнеться лише один.
Коли комутатор приймає кадр і не може знайти Destination MAC з нього в таблиці MAC-адрес, він просто розсилає це повідомлення у всі порти, крім того, з якого прийняв його. На подібну розсилку відповість лише один пристрій.
Передача Unknown Unicast-трафіку
Multicast
Multicast – це розсилка повідомлення на групу пристроїв, які хочуть отримувати ці дані. Це дуже схоже на вебінар. Він транслюється на весь Інтернет, але підключаються до нього ті люди, яким дана тематика цікава.
Така модель передачі даних називається "Видавець - Передплатник". Є один Видавець, який надсилає дані та Передплатники, які ці дані хочуть отримувати – підписуються на них.
Під час розсилки multicast повідомлення надсилається з реального пристрою. Як Source MAC у кадрі вказується MAC відправника. А ось як Destination MAC — віртуальна адреса.
Пристрій повинен підключитися до групи, щоб отримати дані з неї. Комутатор перенаправляє інформаційні потоки між пристроями – він запам'ятовує, з яких портів дані передаються, і знає, які порти ці дані потрібно відправляти.
Передача Multicast-трафіку
Важливий момент, що як віртуальні групи частіше використовуються IP-адреси, але т.к. у розрізі цієї статті йдеться про енергетику, то ми говоритимемо про MAC-адреси. У протоколах сімейства МЕК 61850, що використовуються для Цифрової Підстанції, поділ на групи здійснюється на основі MAC-адрес
Короткий лікнеп про MAC-адресу
MAC-адреса – це 48-бітове значення, яке унікально ідентифікує пристрій. Він розбитий на 6 жовтня. Перші три октети містять інформацію про виробника. 4, 5 та 6 октети призначаються виробником і є номером пристрою.
Структура MAC-адреси
У першому октеті восьмий біт відповідає за те, чи це повідомлення є unicast або multicast. Якщо восьмий біт дорівнює 0, то MAC-адреса - це адреса реального фізичного пристрою.
А якщо восьмий біт дорівнює 1, то ця MAC-адреса віртуальна. Тобто, ця MAC-адреса належить не реальному фізичному устрою, а віртуальній групі.
Віртуальну групу можна порівняти з вежею радіомовлення. Радіокомпанія транслює на цю вежу якусь музику, а ті, кому хочеться її послухати, налаштовують приймачі на потрібну частоту.
Також, наприклад, IP-відеокамера відправляє дані до віртуальної групи, а ті пристрої, які хочуть ці дані отримувати, підключаються до цієї групи.
Восьмий біт першого октету MAC-адреси
Якщо на комутаторі не включена підтримка multicast, то він multicast-потік сприйматиме як широкомовну розсилку. Відповідно, якщо таких потоків буде багато, то ми дуже швидко заб'ємо мережу «сміттєвим» трафіком.
У чому полягає суть multicast?
Основна ідея multicast – з пристрою надсилається лише одна копія трафіку. Комутатор визначає, на яких портах знаходяться передплатники, та передає на них дані від відправника. Тим самим multicast дозволяє значно скоротити дані, що передаються через мережу.
Як це працює у реальній ЛОМ?
Зрозуміло, що недостатньо просто надсилати одну копію трафіку на якусь MAC-адресу, восьму біт першого октету якої дорівнює 1. Передплатники повинні вміти підключатися до цієї групи. А комутатори повинні розуміти, з яких портів дані приходять, і які порти їх необхідно передавати. Тільки тоді multicast дозволить оптимізувати мережі та керувати потоками.
Для реалізації цього функціоналу є multicast-протоколи. Найбільш поширені:
- IGMP.
- PIM.
У рамках цієї статті ми по дотичній розповімо про загальний принцип дії цих протоколів.
IGMP
Комутатор з підтримкою IGMP запам'ятовує, який порт приходить multicast-поток. Передплатники повинні надіслати IMGP Join повідомлення для підключення до групи. Комутатор додає порт, з якого прийшов IGMP Join, до списку низхідних інтерфейсів і починає передавати потік multicast туди. Комутатор постійно посилає повідомлення IGMP Query на низхідні порти, щоб перевірити, чи потрібно продовжувати передавати дані. Якщо з порту надійшло повідомлення IGMP Leave або не було відповіді повідомлення IGMP Query, то мовлення на нього припиняється.
PIM
У протоколу PIM є дві реалізації:
- PIM DM.
- PIM SM.
Протокол PIM DM діє від зворотного, проти IGMP. Комутатор спочатку розсилає multicast-потік як широкомовний - на всі порти, крім того, з якого його було отримано. Потім відключає потік на портах, звідки прийшли повідомлення про те, що він не потрібен.
PIM SM за принципом роботи близький до IGMP.
Якщо дуже грубо узагальнити загальний принцип роботи multicast – Видавець відправляє multicast-потік на певну MAC-групу, передплатники надсилають запити на підключення до цієї групи, комутатори керують даними потоками.
Чому ми настільки поверхово пройшлися multicast? Давайте поговоримо про специфіку ЛОМ Цифрової Підстанції, щоб зрозуміти це.
Що таке Цифрова Підстанція та навіщо там потрібен multicast?
Перш ніж заговорити про ЛОМ Цифрової Підстанції, потрібно розібратися, що таке Цифрова Підстанція. Потім відповісти на запитання:
- Хто бере участь у передачі даних?
- Які дані передаються ЛВС?
- Яка типова архітектура ЛОМ?
І вже після цього обговорюватимуть multicast…
Що таке Цифрова Підстанція?
Цифрова Підстанція – це підстанція, усі системи якої мають дуже високий рівень автоматизації. Все вторинне та первинне обладнання такої підстанції орієнтоване на цифрову передачу даних. Обмін даними вибудовується відповідно до протоколів передачі, описаних у стандарті МЕК 61850.
Відповідно, у цифровому вигляді тут передаються всі дані:
- Вимірювання.
- Діагностична інформація.
- Команди керування.
Цей тренд отримав дуже великий розвиток у російській енергетиці і зараз повсюдно впроваджується. У 2019 та 2020 роках з'явилося дуже багато нормативних документів, що регулюють створення Цифрової Підстанції на всіх етапах розробки. Наприклад, СТО 34.01-21-004-2019 ПАТ «Россеті» визначає таке визначення та критерії ЦПС:
визначення:
Цифрова підстанція — автоматизована підстанція, оснащена цифровими інформаційними та керуючими системами, що взаємодіють в режимі єдиного часу і функціонує без присутності постійного чергового персоналу.
критерії:
- дистанційна спостереження параметрів та режимів роботи обладнання та систем, необхідних для нормального функціонування без постійної присутності чергового та обслуговуючого експлуатаційного персоналу;
- забезпечення телеуправління обладнанням та системами для експлуатації ПС без постійної присутності чергового та обслуговуючого експлуатаційного персоналу;
- високий рівень автоматизації управління обладнанням та системами із застосуванням інтелектуальних систем управління режимами роботи обладнання та систем;
- дистанційна керованість усіма технологічними процесами як єдиного часу;
- цифровий обмін даними між усіма технологічними системами у єдиному форматі;
- інтегрованість у систему управління електричною мережею та підприємством, а також забезпечення цифрової взаємодії з відповідними інфраструктурними організаціями (з суміжними об'єктами);
- функціональна та інформаційна безпека при цифровізації технологічних процесів;
- безперервний моніторинг стану основного технологічного обладнання та систем у режимі онлайн з передачею необхідного обсягу цифрових даних, контрольованих параметрів та сигналів.
Хто бере участь у передачі даних?
У складі Цифрової Підстанції є такі системи:
- Системи релейного захисту. Релейний захист - це практично "серце" Цифрової Підстанції. Термінали релейного захисту із систем вимірювання беруть значення струму та напруги. На основі цих даних термінали відпрацьовують внутрішню логіку захисту. Термінали спілкуються між собою, щоб передавати інформацію про спрацьовані захисти, положення комутаційних апаратів і т.д. Також термінали відправляють інформацію про події, що відбулися, на сервер АСУ ТП. Отже, можна виділити кілька типів зв'язку:
▸Горизонтальний зв'язок - Спілкування терміналів між собою.
▸Вертикальний зв'язок - Спілкування з сервером АСУ ТП.
▸вимірювання - Спілкування з вимірювальними пристроями.
- Системи комерційного обліку електроенергіїСистеми комерційного обліку спілкуються лише з вимірювальними пристроями.
- Системи диспетчерського керування.З сервера АСУ ТП та з сервера комерційного обліку дані частково мають надсилатися до диспетчерського пункту.
Це дуже спрощений перелік систем, що обмінюються даними у складі Цифрової Підстанції. Якщо Вам цікаво заглибитись у цю тему глибше – пишіть у коментарі.
Розкажемо про це окремо 😉
Які дані передаються ЛВС?
Щоб об'єднати описані системи між собою та організувати горизонтальний та вертикальний зв'язок, а також передачу вимірювань організуються шини. Поки давайте домовимося, що кожна шина – це окрема ЛВС на промислових Ethernet-коммутаторах.
Структурна схема електроенергетичного об'єкта відповідно до МЕК 61850
На структурній схемі зображені шини:
- Моніторинг/Управління.
- Передача сигналів РЗА.
- Передача миттєвих значень напруги та струмів.
Термінали релейного захисту беруть участь і в горизонтальному і вертикальному зв'язку, а також використовують вимірювання, тому вони підключаються до всіх шин.
Через шину "Передача сигналів РЗА" термінали передають інформацію між собою. Тобто. тут реалізовано горизонтальний зв'язок.
Через шину «Передача миттєвих значень напруги та струмів» реалізована передача вимірювань. До цієї шині підключаються пристрої вимірювання – трансформатори струму та напруги, а також термінали релейного захисту.
Також до шини «Передача миттєвих значень напруги та струмів» підключається сервер АСКОЕ, який також забирає до себе вимірювання для обліку.
А шина "Моніторинг / Управління" служить для вертикального зв'язку. Тобто. через неї термінали відправляють на сервер АСУ ТП різні події, і навіть сервер посилає управляючі команди термінали.
З сервера АСУ ТП дані надсилаються до диспетчерського пункту.
Яка типова архітектура ЛОМ?
Перейдемо від абстрактної та досить умовної структурної схеми до більш приземлених та реальних речей.
На схемі нижче зображено досить стандартну архітектуру ЛОМ для Цифрової Підстанції.
Архітектура Цифрової Підстанції
На підстанціях 6 кВ або 35 кВ мережа буде простіша, але якщо ми говоримо про підстанції 110 кВ, 220 кВ і вище, а також про ЛОМ електричних станцій, то архітектура відповідатиме зображеній.
Архітектура розбита на три рівні:
- Рівень станції/підстанції.
- Рівень приєднання.
- Рівень процесу.
Рівень станції/підстанції включає в себе АРМи та сервери.
Рівень приєднання включає все технологічне обладнання.
Рівень процесу включає вимірювальне обладнання.
Також є дві шини для поєднання рівнів:
- Шина станції/підстанції.
- Шина процесу.
Шина станції/підстанції поєднує функції шини «Моніторинг/Управління» і шини «Передача сигналів РЗА». А шина процесу виконує функції шини "Передача миттєвих значень напруги та струму".
Особливості передачі Multicast у Цифровій Підстанції
Які дані передаються через multicast?
Горизонтальний зв'язок та передача вимірювань у рамках Цифрової Підстанції виконується за допомогою архітектури «Видавець-підписчик». Тобто. термінали релейного захисту використовують multicast-потоки для обміну повідомленнями між собою, а також виміри передаються за допомогою multicast.
До цифрової підстанції в енергетиці горизонтальна зв'язок реалізовувалася з допомогою зв'язку точка-точка між терміналами. Як інтерфейс використовувався або мідний або оптичний кабель. Дані передавалися за пропрієтарними протоколами.
До цього ставилися дуже високі вимоги, т.к. цими каналами передавали сигнали спрацьовування захистів, положення комутаційних апаратів і т.д. Від цієї інформації залежав алгоритм оперативного блокування терміналів.
Якщо дані будуть передавати повільно або негарантовано, велика ймовірність, що якийсь із терміналів не отримає актуальної інформації щодо поточної ситуації і може подати сигнал на відключення або включення комутаційного апарату, коли на ньому, наприклад, будуть проводитись якісь роботи. Або УРВ не відпрацює вчасно і КЗ пошириться на решту електричної схеми. Все це загрожує великими грошовими втратами та загрозою людському життю.
Тому дані мали передаватися:
- Надійно.
- Гарантовано.
- Швидко.
Тепер замість зв'язку точка-крапка використовується шина станції/підстанції, тобто. ЛОМ. А дані передаються за допомогою протоколу GOOSE, який описаний стандартом МЕК 61850 (у МЕК 61850-8-1, якщо бути точніше).
GOOSE розшифровується як General Object Oriented Substation Event, але це розшифровка вже не дуже актуальна і смислового навантаження не несе.
В рамках цього протоколу термінали релейного захисту обмінюються GOOSE-повідомленнями між собою.
Перехід від зв'язку крапка до ЛВС підходу не змінив. Дані, як і раніше, необхідно передавати надійно, гарантовано і швидко. Тому для GOOSE-повідомлень використовується дещо незвичний механізм передачі. Про нього трохи згодом.
Вимірювання, як ми вже обговорили, передаються також за допомогою multicast-потоків. У термінології ЦПС ці потоки називаються SV-потоками (Sampled Value).
SV-потоки – це повідомлення, що містять певний набір даних і які передаються безперервно з певним періодом. Кожне повідомлення містить вимір у певний момент часу. Вимірювання беруться із певною частотою – частотою дискретизації.
Частота дискретизації — частота взяття відліків безперервного за часом сигналу за його дискретизації.
Частота дискретизації 80 вибірок за секунду
Склад SV-потоків описаний МЕК61850-9-2 LE.
SV потоки передаються через шину процесу.
Шина процесу - комунікаційна мережа, що забезпечує обмін даними між вимірювальними пристроями та пристроями рівня приєднання. Правила обміну даними (миттєвими значеннями струму та напруги) описані у стандарті МЕК 61850-9-2 (на даний момент використовується профіль МЕК 61850-9-2 LE).
SV-потоки, як і GOOSE-повідомлення, повинні передаватися швидко. Якщо вимірювання будуть передаватися повільно, то термінали можуть вчасно не отримати значення струму або напруги, необхідне для спрацьовування захисту, і тоді коротке замикання пошириться на більшу частину електричної мережі та завдасть великої шкоди.
Навіщо потрібний multicast?
Як згадувалося вище, для закриття вимог щодо передачі даних для горизонтального зв'язку, GOOSE передаються дещо незвично.
По-перше, вони передаються на канальному рівні та мають свій Ethertype – 0x88b8. Це забезпечує високу швидкість передачі.
Тепер необхідно закрити вимоги гарантованості та надійності.
Очевидно, що для гарантованості необхідно розуміти, чи доставлено повідомлення, але ми не можемо організувати надсилання підтверджень отримання, як, наприклад, це робиться в TCP. Це значно знизить швидкість передачі.
Тому для передачі GOOSE використовується архітектура «Видавець-передплатник».
Архітектура «Видавець – Передплатник»
Пристрій надсилає GOOSE-повідомлення на шину, і передплатники отримують це повідомлення. Причому повідомлення надсилається з постійним часом T0. Якщо трапляється якась подія, то генерується нове повідомлення, незалежно від того, чи закінчився попередній період Т0 чи ні. Наступне повідомлення з новими даними генерується через дуже короткий проміжок часу, потім через трохи більший і так далі. Через війну час збільшується до Т0.
Принцип передачі GOOSE-повідомлень
Передплатник знає, від кого він отримує повідомлення, і якщо від когось не отримав повідомлення через час T0, він генерує повідомлення про помилку.
SV-потоки також передаються на канальному рівні, мають свій Ethertype – 0x88BA та передаються за моделлю «Видавець – Передплатник».
Нюанси multicast-передачі в цифровій підстанції
Але в «енергетичному» multicast' є свої нюанси.
Нюанс 1. Для GOOSE та SV визначено свої multicast-групи
Для енергетичного multicast використовуються свої групи для розсилки.
У телекомі для multicast-розсилки використовується діапазон 224.0.0.0/4 (за рідкісними винятками є адреси, що зарезервовані). Але сам стандарт МЕК 61850 та корпоративний профіль МЕК 61850 від ПАТ "ФСК" визначає власні діапазони multicast-розсилки.
Для SV-потоків: від 01-0C-CD-04-00-00 до 01-0C-CD-04-FF-FF.
Для GOOSE-повідомлень: від 01-0C-CD-04-00-00 до 01-0C-CD-04-FF-FF.
Нюанс 2. Термінали не використовують протоколи multicast
Другий нюанс набагато значніший — термінали релейного захисту не підтримують IGMP чи PIM. Тоді як вони працюють з multicast? Вони просто чекають, коли на порт буде надіслано потрібну інформацію. Тобто. якщо вони знають, що підписані на певну MAC-адресу, то приймають всі кадри, що приходять, але обробляють тільки необхідні. Інші просто відкидають.
Інакше кажучи – вся надія доручається комутатори. Але як працюватиме IGMP або PIM, якщо термінали не надсилатимуть Join-повідомлення? Відповідь проста – ніяк.
А SV-потоки це досить важкі дані. Один потік важить близько 5 Мбіт/с. І якщо все залишити як є, то вийде, що кожен потік передаватиметься широкомовно. Іншими словами, ми потягнемо всього 20 потоків на одну 100 Мбіт/с ЛОМ. Кількість SV-потоків на великій підстанції вимірюється сотнями.
Який тоді вихід?
Простий – використовувати старі перевірені VLAN.
Більше того, IGMP у ЛВС Цифрової Підстанції може зіграти злий жарт, і навпаки нічого не працюватиме. Адже комутатори без запиту не почнуть передавати потоки.
Тому можна виділити просте правило пусконалагодження – «Мережа не працює? – Disable IGMP!»
Нормативна база
Але може бути все-таки можна якось організувати ЛОМ Цифрової Підстанції на основі multicast? Давайте спробуємо звернутися тепер до нормативної документації з ЛОМ. Зокрема я наводитиму витримки з наступних СТО:
- СТО 34.01-21-004-2019 — ЦИФРОВИЙ ЖИВЧИЙ ЦЕНТР. ВИМОГИ ДО ТЕХНОЛОГІЧНОГО ПРОЕКТУВАННЯ ЦИФРОВИХ ПІДСТАНЦІЙ НАПРУЖУВАННЯМ 110-220 кВ І ВУЗЛОВИХ ЦИФРОВИХ ПІДСТАНЦІЙ НАПРУГОЮ 35 кВ.
- СТО 34.01-6-005-2019 - КОМУТАТОРИ ЕНЕРГООБ'ЄКТІВ. Загальні вимоги.
- СТО 56947007-29.240.10.302-2020 - Типові технічні вимоги до організації та продуктивності технологічних ЛОМ в АСУ ТП ПС ЄНЕС.
Давайте спочатку подивимося, що можна знайти у цих СТО про multicast? Згадка є лише у свіжому СТО від ПАТ «ФСК ЄЕС». СТО просить при приймально-здавальних випробуваннях ЛОМ перевірити, чи коректно налаштовані VLAN, і перевірити відсутність multicast-трафіку в непрописаних у робочій документації портах комутаторів.
Ну і ще СТО прописує, що персонал повинен знати, що таке multicast.
На цьому все про multicast.
Тепер давайте подивимося, що можна знайти у цих СТО про VLAN.
Тут уже всі три СТО сходяться на тому, що комутатори повинні підтримувати VLAN на основі IEEE 802.1Q.
СТО 34.01-21-004-2019 говорить про те, що VLAN'и повинні використовуватися для управління потоками, і за допомогою VLAN трафік повинен розділятися на РЗА, АСУТП, АІІС КУЕ, відеоспостереження, зв'язок та ін.
СТО 56947007-29.240.10.302-2020, крім цього, ще вимагає під час проектування підготувати карту розподілу за VLAN. При цьому СТО пропонує свої діапазони IP-адрес та VLAN для обладнання ЦПС.
Також СТО наводить таблицю пріоритетів, що рекомендуються, для різних VLAN.
Таблиця рекомендованих пріоритетів VLAN із СТО 56947007-29.240.10.302-2020
З погляду управління потоками – це все. Хоча у цих СТО є ще багато чого поговорити – починаючи з різноманітних архітектур і закінчуючи налаштуваннями L3 – ми це обов'язково зробимо, але наступного разу.
А зараз давайте підіб'ємо підсумок з управління потоками в ЛОМ Цифрової Підстанції.
Висновок
У Цифровій Підстанції, незважаючи на те, що передається дуже багато multicast-потоків, за фактом не застосовуються стандартні механізми управління multicast-трафіком (IGMP, PIM). Це пов'язано з тим, що кінцеві пристрої не підтримують будь-які multicast-протоколи.
Для керування потоками використовуються старі добрі VLAN. При цьому використання VLAN регламентоване нормативною документацією, яка пропонує досить опрацьовані рекомендації.
Корисні посилання:
.
Джерело: habr.com