Страница 10: ДСТУ IEC 61850-8-1:2014. Комунікаційні мережі та системи для автоматизації електроенергетичних підприємств. Частина 8-1. Визначене відображення комунікаційних сервісів. Відображення відповідно до специфікації виробничих повідомлень (62075)

Біт 0 має бути найсуттєвішим бітом октету 7. Біт 7 має бути найменш суттєвим бітом октету 7.

Формат октету має бути таким (використовуючи познаку bstring ASN.1):

‘ssssssssssssssssssssssssssssssssffffffffffffffffffffffffqqqqqqqq’B.

Entry Time має відображатися за DataType MMS BINARY-TIME. Розмір значення BINARY-TIME має бути шість октет.

Епоха TimeOfDay MMS розпочалася в 0 годин 1 січня 1984 р. (MJD 40 587). Виміряний час по­значено в цьому стандарті як мілісекунди TimeOfDay за Гринвічем та дні TimeOfDay за Гринвічем та є відхиленням від періоду. Треба зазначити, що трапляються винятки з цього відображення. Одним із прикладів цього є атрибут TimeOfEntry повідомлення BRCB (Блок керування буферизованими звітами) (див. таблицю 61).

Значення Triggerconditions, кодовані як PACKED_LIST, проте Bit(O) зберігається. Тому відо­браження Triggerconditions за MMS є BITSTRING змінної довжини. Мінімальний розмір BITSTRING має дорівнювати шести бітам. Додаткові біти зберігаються для подальших версій стандарту. Біти позначають так:

Біт 0 — резервний (зарезервований для забезпечення повної сумісності з UCA 2.0);

Біт 1 — зміна даних;

Біт 2 — зміна якості;

Біт 3 — поновлення даних;

Біт 4 — цілісність;

Біт 5 — загальне запитання.

Примітка. Майбутнє розширення Triggerconditions має враховувати визначення біта 6, зарезервованого для певного вирівнювання між типом Triggerconditions і типом ReasonCode.

Значення для ReasonCode кодуються як PACKED LIST, проте зберігається Bit(O). Тому відоб­раження ReasonCode за MMS є BITSTRING змінної довжини. Мінімальний розмір BITSTRING має дорівнювати семи бітам. Додаткові біти зберігаються для майбутніх версій стандарту. Біти позна­чають так:

Біт 0 — резервний (зарезервований для забезпечення повної сумісності з UCA 2.0);

Біт 1 — зміна даних;

Біт 2 — зміна якості;

Біт 3 — поновлення даних;

Біт 4 — цілісність;

Біт 5 — загальне запитання;

Біт 6 — тригер програми.

8.2 Відображення якісного загального типу атрибута даних, зазначеного в ІЕС 61850-7-3 Визначення, наведене в ІЕС 61850-7-3 для атрибута якісних загальних даних, дає комбінацію значень PACKED LIST, CODED ENUM та BOOLEAN. Відображення атрибута даних має бути таким, як наведено в цьому розділі.

Значення ІЕС 61850-7-3 якості типу має представлятися DataType MMS BIT-STRING. BIT­STRING має кодуватися як бітовий рядок змінної довжини. Біти, що не передаються, розглядають як такі, що мають значення DEFAULT, як описано в цьому підрозділі.

Значення бітів бітового рядка мають бути такими, як наведено в таблиці 33. У подальших версіях стандарту можуть додаватися додаткові біти. Максимальним дозволеним числом бітів має бути 15.

Таблиця 33 — Кодування якості ІЕС 61850-7-3

9. МОДЕЛЬ КЛАСУ СЕРВЕРА

   1. Відображення сервера

Сервер ACSI, визначений в ІЕС 61850-7-2, має відображатися за принаймні одним VMD MMS.

Є 5 ServiceAccessPoint (наприклад, комунікаційні інтерфейси), що можуть підтримуватися реалізацією ІЕС 61850-8-1. Точки доступу/комунікаційні інтерфейси, що мають підтримуватися, визначають підтримкою сервісу, заявленою реалізацією:

1. Клієнтський/серверний профіль

Реалізації, що підтримують клієнтський/серверний профіль, мають підтримувати принаймні одну представницьку адресу, в якій використовується T-Profile TCP/IP. Може підтримуватися більше ніж одна PresentationAddress;

2. Керування GSE

Реалізації, що підтримують профіль керування GSE, мають підтримувати принаймні одну ServiceAccessPoint для сервісів керування GSE. Точка доступу має визначатися як L-Address. L-Address має бути комбінацією фізичної адреси МАС, ETHERTYPE та APPID, визначених про­філем для керування GSE (див. 6.3.3).

ServiceAccessPoint призначення має бути інша L-Address, що визначає такий самий ETHERTYPE;

3. Сервіси GOOSE

Реалізації, що підтримують профіль керування GOOSE, мають підтримувати принаймні одну ServiceAccessPoint для передавання сервісів GOOSE. Точка доступу має визначатися як L-Address. L-Address має бути комбінацією фізичної адреси МАС, ETHERTYPE та APPID, визначених профі­лем для GOOSE (див. 6.3.3).

ServiceAccessPoint призначення має бути інша L-Address, що визначає той самий ETHER­TYPE. Адресою МАС-призначення має бути адреса, що має багатонаправлений набір бітів.

4. Передавання сервісів відібраних значень

Має бути таким, як наведено в ІЕС 61850-9-1 та ІЕС 61850-9-2.

Логічні прилади відображаються за об’єктами домену MMS. Для кожного екземпляра логічного приладу існує єдиний домен MMS. Іменем домену має бути ім’я екземпляра логічного приладу. Див. докладнішу інформацію про відображення логічних приладів у розділі 11.

Файли відображаються за об’єктами файлів MMS. Див. докладнішу інформацію про відобра­ження файлів у розділі 23.

Див. розділ 10.

Сервіс GetServerDirectory має відображатися на основі класу ACSI, що відображається в ServerDirectory. Є 2 дозволені класи ACSI: LOGICAL-DEVICE (логічний прилад) та FILE (файл).

Клас LOGICAL-DEVICE

Запит ACSI відображає на запит GetNameList MMS, як наведено в таблиці 34. Клас об’єкта GetNameList повинен мати значення домену. Сервіс GetNameList MMS, у разі обмеження розміром mmsPDU, що передається, може сегментувати процес, видаючи підмножину імен файлів й ознаку (moreFollows), що означає необхідність запитувати наступну підмножину. У такому разі клієнт має зробити ще один запит, цього разу зазначаючи позицію в переліку, в якій сервер має продовжувати пошук імен. Через це обмеження відображення сервісу ACSI є насправді послідовністю сервісів GetNameList (доки не буде moreFollows=FALSE).

ServiceError ACSI описано у 8.1.3.4.2.4.

Таблиця 34 — Відображення GetServerDirectory (ЛОГІЧНИЙ ПРИЛАД) ACSI за MMS

Клас FILE

Запит ACSI відображає на запит FileDirectory MMS, як наведено в таблиці 34. Сервіс FileDirectory MMS, у разі обмеження розміром mmsPDU, що передається, може сегментувати про­цес, видаючи підмножину імен файлів й ознаку (moreFollows), що означає необхідність запитувати наступну підмножину. У такому разі клієнт має зробити ще один запит, цього разу зазначаючи по­зицію в переліку, в якій сервер має продовжувати пошук імен. Через це обмеження відображення сервісу ACSI є насправді послідовністю сервісів FileDirectory (доки не буде moreFollows=FALSE).

ServiceError ACSI має відображати за класом помилка/кодом помилка чи кодом відмова, як зазначено у 8.1.3.4.6.1. ServiceError ACSI відображається або за ServiceError MMS, або за причи­нами Reject MMS. Значення ServiceError ACSI, що не з’являються в таблиці, не відображаються.

Якщо Filename (наприклад, FileSpecification MMS) не присутнє у FileDirectory.request або якщо використовується груповий символ сервер-відповідач має видавати, щонайменше, Filenames, наявні в кореневому каталозі (додаткові файли також можуть видаватися). Груповий символ має компонуватися в рядку не як груповий символ для розширення імені, а завжди як одиничний символ, і тому він є рівнозначним FileDirectory.request, де ім’я файла чи порожнє, чи 7’, чи 'V.

Для серверів, що мають логічні прилади, 23.1 визначає кореневий каталог. Надані імена фай­лів мають бути іменами файлів, наявних у каталозі LD. Для серверів, що не мають логічних при­ладів (наприклад, це може бути файловий сервер), кореневий каталог буде локальним питанням.

Див. відображення GetServerDirectory(FILE) ACSI за MMS у таблиці 35.

Таблиця 35 — Відображення GetServerDirectory (ФАЙ Л) ACSI за MMS

9. МОДЕЛЬ ЗВ’ЯЗКУ

   1. Відношення зв’язку до комунікаційних профілів

Є два види зв’язку програми, визначені в ІЕС 61850-7-2:

• двобічні зв’язки;

• багатоадресні зв’язки.

Є кілька комунікаційних профілів, визначених у документі. Відповідність будь-якому з цих про­філів має реалізовувати модель зв’язку, необхідну для цього профілю, як визначено в таблиці 36.

Таблиця 36 — Модель зв'язку порівняно з комунікаційними профілями

Клієнтський/серверний профіль має відображати модель двобічного зв’язування ACSI за се­редовищем MMS, як наведено в ISO 9506-1.

Примітка 1. Середовище MMS, за визначенням з ISO 9506-1, виникає через встановлення єдиного зв’язку програма-програ­ма, що створюється та підтримується через комунікаційний профіль, орієнтований на встановлення зв'язку. Див. відповідні адреси й процедури в ISO 9506-1. Проте середовище MMS додатково складається за узгодженості через обмін сервісу ініціювання MMS.

Associations

AssociationlD має бути локальним питанням. Проте між AssociationlD та середовищем MMS, охоплюючи параметр, що передається, має бути взаємно-однозначна відповідність.

Примітка 2. Безпека, аутентифікація — це вже майбутня сфера діяльності, що очікує розроблення загального механізму безпеки Технічного комітету 57 ІЕС. Цей механізм може обмежувати видимість об’єктів у середовищі MMS. Цю роботу наразі виконують у Робочій групі 15 Технічного комітету 57 ІЕС.

Сервіс запиту на зв'язування ACSI має відображати безпосередньо за сервісом запиту на ініціювання MMS, як наведено в таблиці 37.