24.3 Твердження PICS
Загальні положення
У цьому підрозділі описано проформу твердження відповідності введення в дію протоколу (PICS). Кожен реалізатор має заповнювати весь PICS. Див. основне твердження відповідності ACSI ІЕС 61850-7-2. PICS у наведених нижче підпунктах також має заповнюватися.
Логічний прилад
Наступний PICs представляє вимоги до відповідності, якщо в основному твердженні відповідності ACSI заявлено за підтримання моделі логічного приладу.
Сервіси GOOSE
Таблиця 131 має визначати відповідність сервісу GOOSE.
Таблиця 131 —Твердження відповідності GOOSE
|
|
Користувач |
Сервер публікацій |
Значення/зауваження |
|
Сервіси GOOSE |
с1 |
с1 |
|
|
Send GOOS EMessage |
m |
m |
|
|
GetGoReference |
0 |
сЗ |
|
|
GetGOOSEEIementNumber |
0 |
с4 |
|
|
GetGoCBValues |
0 |
0 |
|
|
SetGoCBValues |
0 |
0 |
|
|
GSENotSupported |
с2 |
с5 |
|
|
Блок керування GOOSE (GoCB) |
0 |
0 |
|
|
c1 — має бути ‘т', якщо в основному твердженні відповідності ACSI заявлено підтримання. с2 — має бути ‘т’, якщо заявлено підтримання основної відповідності ACSI для GetGoReference або GetGOOSEEIementNumber. сЗ — має бути 'т', якщо заявлено підтримання для основної відповідності ACSI GetGoReference. с4 — має бути 'т', якщо заявлено підтримання для основної відповідності ACSI GetGOOSEEIementNumber. с5 — має бути ‘т', якщо не заявлено підтримання для основної відповідності ACSI GetGOOSEEIementNumber. |
|||
Мова опису конфігурації підстанції
Реалізації, що задовольняють вимоги, мають підтримувати мову опису конфігурації підсистеми згідно з ІЕС 61850-6 для виконання обміну між технічними засобами. Реалізаторам, охочим надавати онлайн доступ і керування для конфігурації SCL, треба звертатися за правилами до інформативного додатка D.
25 МОВА ОПИСУ КОНФІГУРАЦІЇ ПІДСТАНЦІЇ (SCL)
Файл SCLTa розширення SCL
Загальні положення
У цьому розділі визначено та наведено розширення мови SCL для задоволення вимоги SCSM. Додаток G ілюструє використання SCL та її розширень SCSM.
Визначення елементів конкретної адреси SCSM
Клієнтська/серверна адреса — елемент «адреса»
Для потреб цього SCSM елемент ConnectedAP SCL має розширюватися. Має використовуватися визначення Схеми XML частини 6. Таблиця 132 визначає P-Types, дозволені для xs: елемента «адреса».
Таблиця 132 — Дозволені визначення P-Туре для клієнтських/серверних адрес
|
P-Туре познака |
Опис |
т/о |
Обмеження/примітка |
|
IP |
Десятковий із розділювальними крапками |
d |
|
|
IP-SUBNET |
Маска для підмережі для профілів TCP/IP. Має бути десятковим із розділювальними крапками |
с2 |
|
|
IP-GATEWAY |
Адреса IP-шлюзу першого мережевого сегмента для профілів TCP/IP. Має бути десятковою з розділювальними крапками |
с2 |
|
|
OSI-NSAP |
Адреса мережі OSI |
d |
Має бути обмеженим не більше ніж 40 видимими символами. Значення має містити парне число видимих символів. Символи мають бути обмеженими від 0 до 9 та від А до F |
|
OSI-TSEL |
Селектор транспортування OSI |
т |
Має бути обмеженим не більше ніж вісьмома символами. Значення має містити парне число видимих символів. Символи мають бути обмеженими від 0 до 9 та від А до F |
|
OSI-SSEL |
Селектор сеансу OSI |
т |
Має бути обмеженим не більше ніж 16 символами. Значення має містити парне число видимих символів. Символи мають бути обмеженими від 0 до 9 та від А до F |
|
OSI-PSEL |
Селектор представлення OSI |
т |
Має бути обмеженим не більше ніж 16 видимими символами. Значення має містити парне число видимих символів. Символи мають бути обмеженими від 0 до 9 та від А до F |
|
OSI-AP-Title |
Значення назви АР (точка доступу) ACSE OSI |
0 |
Значення має цитуватися та відповідати визначеному формату для ідентифікаторів об'єктів OSI. Набір символів має бути обмеженим від 0 до 9 та комою(,) |
|
OSI-AP-lnvoke |
ID виклику АР (точка доступу) ACSE OSI |
0 |
Має бути обмеженим не більше ніж п'ятьма символами. Символи мають бути обмеженими від 0 до 9 |
Кінець таблиці 132
|
P-Туре познака |
Опис |
т/о |
Обмеження/примітка |
|
OSI-AE-Qualifier |
Класифікатор АЕ (виконання програми) ACSE OSI |
о |
Має бути обмеженим не більше ніж п'ятьма символами. Символи мають бути обмеженими від 0 до 9 |
|
OSI-AE-lnvoke |
ID виклику АЕ (виконання програми) ACSE OSI |
0 |
Має бути обмеженим не більше ніж п'ятьма символами. Символи мають бути обмеженими від 0 до 9 |
|
IP-UDP-PORT |
Ідентифікатор UDP-порту |
0 |
Значення має містити не більше 5 символів, обмежених від 0 до 9 |
|
IP-TCP-PORT |
Ідентифікатор ТСР-порту |
0 |
Значення має містити не більше 5 символів, обмежених від 0 до 9 |
|
с1 — один або інший має бути наявним для віддаленої адреси. Обидва мають бути наявними для локальної адреси. с2 — має бути наявним, якщо визначено IP. |
|||
Приклади використання адрес наведено в додатку G.
Адреса GOOSE
Цей підрозділ визначає типи хэ:рядків, дозволених для адрес GOOSE GSE, як параметри типів елемента Р елемента адреси. Значення й обмеження символів визначено в таблиці 133.
Таблиця 133 — Визначення для SCL GSE
|
P-Туре позначення |
Опис |
m/o |
Обмеження/зауваження |
|
MAC-Address |
Значення адреси доступу до середовища |
m |
Має бути 6 груп із двох видимих символів, розділених дефісами (-). Символи мають бути обмеженими від 0 до 9 та від А до F |
|
APPID |
Ідентифікатор програми |
О |
Має бути 4 символи. Символи мають бути обмеженими від 0 до 9 та від А ДО F |
|
VLAN-PRIORITY |
Пріоритет користувача VLAN |
с1 |
Має бути один символ. Символи мають бути обмеженими від 0 до 9 та від А ДО F |
|
VLAN-ID |
VLAN-ID |
О |
Має бути 3 символи. Символи мають бути обмеженими від 0 до 9 та від А до F |
|
с1 — має бути наявним, лише якщо також наявна VLAN. |
|||
Приклад використання GSE наведено в додатку G.
Визначення GSSE
Якщо блок керування GSE має бути для протоколу GSSE, P-Types хэ:елемента “адреса” мають бути такими, як у таблиці 132.
Тип протоколу підмережі
Тип протоколу для цього стандарту має бути 8-MMS. Це значення можна використовувати як значення атрибута типу підмережі для підмереж, де IED передаються відповідно до відображення, визначеного в цьому стандарті.
Приклад використання типу протоколу підмережі наведено в додатку G.
NameSpace SCSM
NameSpace SCSM введено для описування спеціальних об'єктів SCSM. Спеціальні об'єкти SCSM — це об’єкти, які необхідно додавати до каталогу об’єктів для задоволення вимог SCSM. Описи спеціальних об'єктів використовують елемент SCL ProtNs, простір імені протоколу, так:
<ProtNs type=”8-MMS”>IEC 61850-8-1:2003</ProtNs>
Один із цих спеціальних об'єктів SCSM є відображенням параметрів сервісу керування, як визначено в розділі 20.
Приклад використання ProtNs наведено в додатку G. Повне визначення ProtNs див. в ІЕС 61850-6.
ДОДАТОК А
(обов'язковий)
СПЕЦИФІКАЦІЯ ПРОТОКОЛУ ПРОГРАМИ
ДЛЯ КЕРУВАННЯ GOOSE ТА GSE
А.1 ASN.1 визначення
Примітка. Згідно 3ASN.1 для параметрів, де визначення розміщено на одній лінії, ім'я параметра починається з маленької літери. Тому відповідність цих ASN.1 параметрів параметрам у таблиці сервісів позначено написанням великої першої літери.
ІЕС61850 DEFINITIONS ::= BEGIN
IMPORTS Data FROM ISO-IEC-9506-2 IEC 61850-8-1 Specific Protocol ::= CHOICE { gseMngtPdu [APPLICATION 0] IMPLICIT GSEMngtPdu,
goosePdu [APPLICATION 1] IMPLICIT lECGoosePdu,
GSEMngtPdu ::= SEQUENCE { StatelD [0] IMPLICIT INTEGER, Security [3] ANY OPTIONAL, — зарезервовано для майбутнього визначення CHOICE { requests [1] IMPLICIT GSEMngtRequests, responses [2] IMPLICIT GSEMngtResponses, } }
GSEMngtRequests ::= CHOICE { getGoReference [1] IMPLICIT GetReferenceRequestPdu
getGOOSEEIementNumber [2] IMPLICIT GetElementRequestPdu,
getGsReference [3] IMPLICIT GetReferenceRequestPdu,
getGSSEDataOffset [4] IMPLICIT GetElementRequestPdu,
}
GSEMngtResponses ::= CHOICE { gseMngtNotSupported [0] IMPLICIT NULL,
getGoReference [1] IMPLICIT GSEMngtResponsePdu,
getGOOSEEIementNumber [2] IMPLICIT GSEMngtResponsePdu,
getGsReference [3] IMPLICIT GSEMngtResponsePdu,
getGSSEDataOffset [4] IMPLICIT GSEMngtResponsePdu,
}
GetReferenceRequestPdu ::= SEQUENCE { ident [0] IMPLICIT VISIBLE-STRING,
розмір має підтримувати до 129 октет offset [1] IMPLICIT SEQUENCE OF INTEGER,
}
GetElementRequestPdu ::= SEQUENCE { ident [0] IMPLICIT VISIBLE-STRING,
розмір має підтримувати до 129 октет references [1] IMPLICIT SEQUENCE OF INTEGER,
}
GSEMngtRequestPdu ::= SEQUENCE { ident [0] IMPLICIT VISIBLE-STRING,
відбиває значення запиту confRev [1] IMPLICIT INTEGER OPTIONAL,
CHOICE {
responsepositive [2] IMPLICIT SEQUENCE {
datSet [0] IMPLICIT VISIBLE_STRING OPTIONAL, result [1] IMPLICIT SEQUENCE OF RequestResults },
responseNegative [3] IMPLICIT GlbErrors },
}
RequestResults::= CHOICE { offset [0] IMPLICIT INTEGER, reference [1] IMPLICIT IA5STRING, error [2] IMPLICIT ErrorReason }
GlbErrors ::= INTEGER {
other(O),
unknownControlBlock(l), responseToolLarge(2), controlBlockConfigurationError (3),
}
ErrorReason ::= INTEGER { other (0), notFound (1),
|
} lECGoosePdu ::= |
SEQUENCE{ |
|
|
gocbRef |
[0] |
IMPLICIT VISIBLE-STRING, |
|
timeAllowedtoLive |
[1] IMPLICIT INTEGER, |
|
|
datSet |
[2] |
IMPLICIT VISIBLE-STRING, |
|
golD |
[3] |
IMPLICIT VISIBLE-STRING OPTIONAL, |
|
T |
[4] |
IMPLICIT UtcTime, |
|
stNum |
|
[5] IMPLICIT INTEGER, |
|
sqNum |
|
[6] IMPLICIT INTEGER, |
|
simulation |
[7] |
IMPLICIT BOOLEAN DEFAULT FALSE, |
|
confRev |
[8] |
IMPLICIT INTEGER, |
|
ndsCom |
[9] |
IMPLICIT BOOLEAN DEFAULT FALSE, |
|
numDatSetEntries [10] |
IMPLICIT INTEGER, |
|
|
allData } |
|
[11] IMPLICIT SEQUENCE OF Data, |
|
UtcTime ::= OCTETSTRING — |
формат і розмір визначено у 8.1.3.6. |
|
|
END |
|
|
A.2 Правила кодування BER
Базові правила кодування ASN.1 (за визначенням в ISO/IEC 8825-1) використовують для кодування та декодування телеграм GOOSE. Нижче наведено загальний огляд головних принципів кодування.
Синтаксис передавання BER має формат триплету TLV (Туре (Тип), Length (Довжина), Value (Значення)) або (Tag (Ter), Length (Довжина), Value (Значення)), як зображено на рисунку А.1. Усі поля (Т, L, V) є рядками октет. Значення V може бути самим триплетом TLV, якщо він будується. Синтаксис передавання ґрунтується на октетах і «big endian» (зворотному порядку байтів). Поле довжини L визначає довжину кожного триплету TLV.
І
Триплет TLV
Рисунок А.1 — Формат базових правил кодування
ЄС 824/11Октети тегу відповідають кодуванню тегу типу значення. На рисунку А.2 зображено два формати октетів тегу Т.
О
Біт 7 Біт 6 Біт 5
Біт 0
ІЕС 825/11
ктет тегуРисунок А.2 — Формат октетів тегів
Кодування BER ґрунтується на кодуванні триплетів. Використання поля довжини ASN.1 надає змогу кодувальнику оптимізувати число бітів, необхідне для передавання даного значення. Наприклад, ціле число з 32 бітів може бути закодованим вісьмома бітами, оскільки його значення менше ніж 127.
А.З Кодоване повідомлення GOOSE фіксованої довжини
Для оптимізації процесу кодування/декодування телеграми GOOSE узгоджено відхилення від правил кодування BER. Правила кодування BER ведуть до телеграм GOOSE, поля яких не є доступними на час зсуву.
Властивість «Фіксована довжина» для телеграми GOOSE означає, що сервер публікацій буде завжди використовувати фіксовані зсуви для кожного окремого поля в телеграмі, і це звично для цієї конфігурації. Єдиною частиною, що змінюється в телеграмі, є вміст даних, а не їхнє кодування. Тому ця стратегія є відхиленням від основних правил кодування ASN.1 (за визначенням з ISO/IEC 8825-1). Конфігурація властивості «Фіксована довжина» наявна для кожного блока керування GOOSE з використанням атрибута SCL fixedOffs у структурі tGSEControl (додаткову інформацію про конфігурацію див. в ІЕС 61850-6).Проте властивість «Фіксована довжина» для GOOSE є повністю сумісною з попередніми версіями, оскільки реалізація абонента не перевіряє дотримання стратегії найкоротшої довжини в кодуванні BER телеграми.
