Рисунок 1.2 – Механізм передачі даних клієнт-сервер
Збір даних шляхом періодичного опитування сервера клієнтом.
На першому етапі між пристроями «клієнт» і «сервер» встановлюється з'єднання. Установку з'єднання ініціює клієнт, звертаючись до сервера за його IP-адресою.
На наступному етапі клієнт запитує певні дані у сервера і отримує від нього відповідь із запитаними даними. Наприклад, після установки з'єднання клієнт може запросити у сервера його інформаційну модель з використанням сервісів GetServerDirectory, GetLogicalDeviceDirectory, GetLogicalNodeDirectory. Запити при цьому будуть здійснюватися послідовно:
- після запиту GetServerDirectory сервер поверне перелік доступних логічних пристроїв;
- після окремого запиту GetLogicalDeviceDirectory для кожного логічного пристрою сервер поверне перелік логічних вузлів в кожному з логічних пристроїв;
- запит GetLogicalNodeDirectory для кожного окремого логічного вузла поверне його об'єкти і атрибути даних.
В результаті клієнт розраховує і відтворює у себе повну інформаційну модель пристрою-сервера. При цьому фактичні значення атрибутів лічені ще не будуть, тобто лічене «дерево» буде містити лише імена логічних пристроїв, логічних вузлів, об'єктів даних і атрибутів, але без їх значень.
На третьому етапі може бути здійснено зчитування фактичних значень всіх атрибутів даних. При цьому можуть бути лічені або всі атрибути з використанням сервісу GetAllDataValues, або лише окремі атрибути з використанням сервісу GetDataValues.
По завершенні третього етапу клієнт повністю відтворить у себе інформаційну модель сервера з усіма значеннями атрибутів даних.
Слід зазначити, що зазначена процедура передбачає обмін досить значними обсягами інформації з великою кількістю логічних вузлів і числа об'єктів даних, що залежать від кількості логічних пристроїв, реалізованих сервером, кількістю запитів і відповідей. Це також веде до досить високому навантаженню на апаратну частину пристрою. Ці етапи можуть здійснюватися на етапі налагодження SCADA-системи, для того щоб клієнт, прочитавши інформаційну модель, міг звертатися до даних на сервері. Однак при подальшій експлуатації системи регулярне зчитування інформаційної моделі не потрібна. Так само як недоцільно постійно зчитувати значення атрибутів методом регулярного опитування. Замість цього може використовуватися сервіс передачі звітів Report.
МЕК 61850 визначає два види звітів – буферизовані і небуферизовані. Основна їх відмінність полягає в тому, що при використанні першого формована інформація буде доставлена до клієнта навіть в тому випадку, якщо на момент готовності видачі звіту сервером зв'язок між ним і клієнтом відсутній (наприклад, був порушений відповідний канал зв'язку). Вся формована інформація накопичується в пам'яті пристрою, і її передача буде виконана, як тільки зв'язок між двома пристроями відновиться. Єдине обмеження – обсяг пам'яті сервера, виділений для зберігання звітів: якщо за той проміжок часу, коли зв'язок був відсутній, відбулося досить багато подій, що викликали формування великої кількості звітів, сумарний обсяг яких перевищив допустимий обсяг пам'яті сервера – деяка інформація все ж може бути втрачена і нові звіти, що формуються «витіснять» з буфера раніше сформовані дані (проте в цьому випадку сервер, за допомогою спеціального атрибута керуючого блоку просигналізує клієнту про те, що трапилося переповнення буфера і можлива втрата даних).
Якщо ж зв'язок між клієнтом і сервером присутній, то при використанні буферизованого або небуферизованого звіту передача даних на адресу клієнта може бути негайною за фактом виникнення певних подій в системі.
Важливо відзначити, що коли мова йде про звіти, мається на увазі контроль не всіх об'єктів і атрибутів даних інформаційної моделі сервера, а лише тих, які нас цікавлять, об'єднаних в так звані «набори даних».
Ще один важливий момент: можна налаштувати сервер не тільки на передачу всього контрольованого набору даних, але і на передачу тільки тих об'єктів/атрибутів даних, з якими відбуваються певного роду події за визначений користувачем часовий інтервал.
Для цього в структурі керуючого блоку передачею буферизованих/небуферизованих звітів передбачена можливість завдання категорій подій, виникнення яких необхідно контролювати і за фактом яких буде проводитися включення в звіт тільки тих об'єктів/атрибутів даних, яких торкнулися ці події.
Розрізняють такі категорії подій:
- зміна даних (dchg). При завданні цього параметра в звіт будуть включатися тільки ті атрибути даних, значення яких змінилися, або тільки ті об'єкти даних, значення атрибутів яких змінилися;
- зміна атрибута якості (qchg). При завданні цього параметра в звіт будуть включатися тільки ті атрибути якості, значення яких змінилися, або тільки ті об'єкти даних, атрибути якості яких змінилися;
- оновлення даних (dupd). При завданні цього параметра в звіт будуть включатися тільки ті атрибути або об'єкти даних, значення яких були оновлені. Під оновленням розуміється, наприклад, періодичне обчислення тієї чи іншої гармонійної складової і запис до відповідного атрибуту даних її нового значення. Однак навіть в тому випадку, якщо значення за результатами обчислень в новому періоді не змінилося, об'єкт даних або відповідний атрибут даних включаються в звіт.
Як вже було зазначено вище, можна також налаштувати звіт на передачу всього контрольованого набору даних. Така передача може бути виконана або з ініціативи сервера (умова integrity), або за ініціативою клієнта (general-interrogation). Якщо введено формування даних за умовою integrity, то користувачеві також необхідно вказати період формування даних сервером. Якщо введено формування даних за умовою general-interrogation, сервер буде формувати звіт з усіма елементами набору даних за фактом отримання відповідної команди від клієнта.
Розглянувши варіанти передачі даних шляхом періодичних опитувань і у вигляді звітів, підведемо підсумок у вигляді порівняльного аналізу.
Механізм передачі звітів володіє важливими перевагами перед методом періодичного опитування:
- істотно скорочується навантаження на інформаційну мережу;
- скорочується навантаження на процесор сервера і процесор клієнта;
- забезпечується швидка доставка повідомлень про виникаючі в системі події.
Однак важливо відзначити, що всі переваги використання буферизованих і небуферизованих звітів можна оцінити тільки при правильному їх налаштуванні, що в свою чергу вимагає від персоналу, що виконує наладку обладнання, досить високої кваліфікації і великого досвіду проектування.
1.4 Протокол передачі даних GOOSE
GOOSE (Generic Object Oriented Substation Event – стандарт МЕК 61850-8-1) – протокол передачі даних про події на підстанції. Фактично даний протокол служить для заміни мідних кабельних зв'язків, призначених для передачі дискретних сигналів між пристроями, він є одним з найбільш широко відомих протоколів, призначених для обміну сигналами між РЗА в цифровому вигляді.
Набори даних використовуються для групування даних, які будуть відправлятися пристроєм з використанням механізму GOOSE-повідомлення. Надалі, в блоці управління відправкою GOOSE вказується посилання на створений набір даних, в такому випадку пристрій знає, які саме дані відправляти. Слід зазначити, що в рамках одного GOOSE-повідомлення може відправлятися як одне значення (наприклад, сигнал пуску МТЗ), так і одночасно декілька значень (наприклад, сигнал пуску і сигнал спрацювання МТЗ і т.д.). Пристрій-одержувач, при цьому, може витягти з пакета лише ті дані, які йому необхідні.
В теорії мереж передачі даних прийнято сегментувати сервіси передачі даних відповідно до рівнів моделі OSI, як правило, спускаючись від «прикладного», тобто рівня прикладного представлення даних, до «фізичного», тобто рівню фізичної взаємодії пристроїв. Рівні функції представлені в табл. 1.1. Для зменшення часу затримок кількість перетворень повинно бути зведено до мінімуму. Саме тому дані по протоколу GOOSE (прикладного рівня) призначаються безпосередньо на канальний рівень – Ethernet, минаючи інші рівні.
Таблиця 1.1 – Рівні моделі OSI
| Рівні | Тип даних | Функції |
| 7 | Прикладний | Доступ до мереживих служб |
| 6 | Представницький | Управління сеансами зв’язку |
| 5 | Сеансовий | Представлення і шифрування даних |
| 4 | Транспортний | Прямий зв’язок між кінцевими пунктами |
| 3 | Мережевий | Визначення маршруту і логічна адресація |
| 2 | Канальний | Фізична адресація |
| 1 | Фізичний | Робота з середою передачі сигналів і двійковими даними |
Використання такого методу дозволяє значно підвищити пріоритет даних, переданих по протоколу GOOSE, в порівнянні з іншими даними, переданими по тій же мережі з використанням інших протоколів, тим самим, зводячи до мінімуму затримки як при обробці даних усередині пристроїв джерел і приймачів даних, так і при обробці їх мережевими комутаторами.
Гарантована доставка повідомлень і контроль стану каналу.
Передача повідомлень декільком адресатам в режимі Multicast, а також вимоги до високої швидкості передачі даних не дозволяють реалізувати при передачі GOOSE-повідомлень отримання підтверджень про доставку від одержувачів. Процедура відправки даних, формування отримуючим пристроєм підтвердження, прийом і обробка його пристроєм відправником і подальша повторна відправка в разі невдалої спроби зайняли б занадто багато часу, що могло б призвести до надмірно великих затримок при передачі критичних сигналів. Замість цього для GOOSE-повідомлень був реалізований спеціальний механізм, що забезпечує високу ймовірність доставки даних, який показаний на рисунку 1.3.
По-перше, в умовах відсутності змін в переданих атрибутах даних, пакети з GOOSE-повідомленнями передаються циклічно через встановлений користувачем інтервал (циклічна передача GOOSE повідомлень дозволяє постійно діагностувати інформаційну мережу). Пристрій, налаштований на прийом повідомлення, очікує його приходу через задані інтервали часу. У разі, якщо повідомлення не прийшло, впродовж часу очікування, приймаючий пристрій може сформувати сигнал про несправності в інформаційній мережі, сповіщаючи таким чином диспетчера про виниклі неполадки.
По-друге, при зміні одного з атрибутів переданого набору даних, незалежно від того, скільки часу пройшло з моменту відправки попереднього повідомлення, формується новий пакет, який містить оновлені дані. Після чого відправка цього пакета повторюється кілька разів з мінімальною витримкою часу, потім інтервал між повідомленнями (в разі відсутності змін в переданих даних) знову збільшується до максимального.
По-третє, важливо також відзначити, що в посилці GOOSE, крім самого значення дискретного сигналу, може також міститися ознака його якості, який ідентифікує певну апаратну відмову пристрою-джерела інформації, знаходження пристрою-джерела інформації в режимі тестування і ряд інших позаштатних режимів. Таким чином, пристрій-приймач, перш ніж обробити отримані дані згідно з передбаченими алгоритмами, може виконати перевірку цієї ознаки якості. Вказане може попередити невірну роботу пристроїв-приймачів інформації (наприклад, їх помилкову роботу).
Слід мати на увазі, що деякі із закладених механізмів забезпечення надійності передачі даних при їх неправильному використанні можуть призводити до негативного ефекту. Так, в разі вибору занадто короткого максимального інтервалу між повідомленнями, навантаження на мережу збільшується, хоча, з точки зору готовності каналу зв'язку, ефект від зменшення інтервалу передачі буде вкрай незначним. При зміні атрибутів даних, передача пакетів з мінімальною витримкою часу викликає підвищене навантаження на мережу (режим «інформаційного шторму»), яке теоретично може призводити до виникнення затримок при передачі даних. Такий режим є найбільш складним і повинен прийматися за розрахунковий при проектуванні інформаційної мережі.
Рисунок 1.3 – Механізм доставки даних
1.5 Протокол передачі даних SV
SV (Sampled Values – стандарт МЕК 61850-9-2) – протокол передачі оцифрованих миттєвих значень від вимірювальних трансформаторів струму і напруги (ТА і ТV). Даний протокол дозволяє замінити ланцюги змінного струму, що з'єднують пристрої РЗА з ТА і ТV.
Передача даних здійснюється циклічно з можливістю завдання декількох типів тимчасових інтервалів:
- кількість вибірок за період промислової частоти (SmpPerPeriod);
- кількість вибірок за секунду (SmpPerSec);
- кількість секунд за вибірку (SecPerSmp).
Використання даного протоколу нерозривно пов'язане з терміном «шина процесу». Шиною процесу по МЕК 61850-1 називається комунікаційна шина даних, до якої підключені пристрої нижнього рівня підстанції (комутаційні апарати, вимірювальні трансформатори). В даному випадку слово «шина» не слід розуміти буквально, мова йде про цілу систему передачі даних між пристроями. Таким чином, в загальному випадку до шини процесу можуть бути підключені не тільки вимірювальні перетворювачі, але також вимикачі, роз'єднувачі та інше обладнання. Однак саме передача миттєвих значень від вимірювальних трансформаторів виробляє найбільше навантаження на інформаційну мережу «шини процесу».
У традиційній схемі підключення пристроїв РЗА ланцюга від вимірювальних трансформаторів струму і напруги, що знаходяться на ВРП або в КРПЕ, прокладаються до терміналів РЗА, розміщених в загальнопідстанційному пункті управління (ЗПУ).
Використання концепції шини процесу передбачає, що всі сигнали, включаючи миттєві значення струмів і напруг, оцифровуються безпосередньо в апараті і передаються пристроям захисту і автоматики в вигляді цифрового потоку даних з інформаційної мережі.
Схема підключення РЗА до шини процесу представлена на рисунку 1.4.
Рисунок 1.4 – Схема підключення РЗА до шини процесу
Є різні вимоги до частоти передачі даних. Для РЗА може знадобитися передавати миттєві значення з частотою 80 точок на період, для цілей контролю якості електричної енергії буде потрібно більш висока частота – 256 точок на період. З іншого боку, в зазначених випадках, пред'являються різні вимоги до швидкодії. У разі передачі даних пристрою релейного захисту потрібно передати значення струму і напруги в темпі реального часу з мінімальною затримкою. Тоді як для цілей комерційного обліку і аналізу якості допустимо введення затримок за умови точної прив'язки даних до єдиного часу.
МЕК 61850 – це найсучасніший стандарт зв'язку для автоматизації підстанцій, який визначає інтеграцію пристроїв, що використовуються в автоматизації підстанції.
1.6 Основні рішення побудови РЗА на підстанціях нового покоління
З огляду на всі напрямки по створенню сучасних систем РЗА, ПА, АСУ ТП і зв'язку в даний момент пропонуються наступні рішення різних варіантів виконання систем РЗА і взаємодії їх з АСУ ТП. Зробимо порівняльний аналіз і приймемо рішення по оптимальному складу пристроїв РЗА інтегрованих в систему автоматизації.
На рисунку 1.5 представлений типовий варіант побудови РЗА на ПС, який використовується в даний час. Функції передачі необхідних параметрів здійснюється за рахунок використання аналогових зв'язків. Кожний захист діє автономно і не залежить від стану інших пристроїв. Всі пристрої підключені на окремі обмотки трансформаторів струму і окремі ланцюга оперативного струму. З терміналів пристроїв релейного захисту параметри через шину станції надходять в АРМ і сервер, де здійснюється контроль і управління. Дана схема повністю задовольняє вимогам, що пред'являються до РЗА і нормативно-технічним вимогам.
Рисунок 1.5 – Типове схемне рішення
Тепер розглянемо сучасні тенденції побудови РЗА.
Перший варіант. Установка МП терміналів релейного захисту та реалізація в них функцій РЗА відповідно до «типовими» проектними рішеннями.
На рисунку 1.6 бачимо, що на кожному приєднанні додалися два нові елементи ПЗО (пристрої зв'язку з об'єктом). Друге ПЗО в нормальному режимі буде виведено, воно необхідне для резервування першого пристрою. По суті ПЗО – це АЦП (аналого - цифровий перетворювач). Аналоговий сигнал з трансформаторів струму і трансформаторів напруги надходить в ПЗО, де оцифровується і по волоконно-оптичних ліній зв'язку значення потрапляють в пристрої релейного захисту та автоматики в вигляді цифрового потоку даних, що називається шиною процесу.
Рисунок 1.6 – Варіант перший
Другий варіант. Установка двох однакових взаєморезервуючих МП терміналів РЗА на кожен елемент, що захищається. Дане схемне рішення представлено на рисунку 1.7. Резервні захисти приєднань об'єднані з основними.
1 2 3