ГОСТ Р МЭК 61850-7-2-2009 Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 2. Абстрактный интерфейс услуг связи (ACSI).

     ГОСТ Р МЭК 61850-7-2-2009

Группа П77

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

 СЕТИ И СИСТЕМЫ СВЯЗИ НА ПОДСТАНЦИЯХ

 Часть 7

 Базовая структура связи для подстанций и линейного оборудования

 Раздел 2

 Абстрактный интерфейс услуг связи (ACSI)

 Communication networks and systems in substations. Part 7. Basic communication structure for substation and feeder equipment. Section 2. Abstract communication service interface (ACSI)

ОКС 33.200

ОКП 42 3200

Дата введения 2011-01-01

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 "Стандартизация в Российской Федерации. Основные положения"

Сведения о стандарте

1 ПОДГОТОВЛЕН ОАО "Научно-технический центр электроэнергетики" на основе аутентичного перевода на русский язык указанного в пункте 4 стандарта, который выполнен ООО "ЭКСПЕРТЭНЕРГО"

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 396 "Автоматика и телемеханика"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 15 декабря 2009 г. N 848-ст

4 Настоящий стандарт идентичен международному стандарту МЭК 61850-7-2:2003* "Сети и системы связи на подстанциях. Часть 7-2. Базовая структура связи для подстанций и линейного оборудования. Абстрактный интерфейс услуг связи (ACSI) (IEC 61850-7-2:2003 "Communication networks and systems in substations - Part 7-2: Basic communication structure for substation and feeder equipment - Abstract communication service interface (ACSI)")

Наименование национального стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2004 (пункт 3.5)

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в справочном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ

6 Некоторые из элементов настоящего стандарта могут быть предметом патентных прав. МЭК не несет ответственности за идентификацию любого или всех таких патентных прав.

Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе "Национальные стандарты", а текст изменений и поправок - в ежемесячно издаваемых информационных указателях "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет

 Введение

Серия стандартов МЭК 61850 состоит из следующих частей, объединенных общим названием "Сети и системы связи на подстанциях":

часть 1. Введение и краткий обзор;

часть 2. Словарь терминов;

часть 3. Общие требования;

часть 4. Управление системой и проектом;

часть 5. Требования к связи для функций и моделей устройств;

часть 6. Язык описания конфигурации для связи между интеллектуальными электронными устройствами на электрических подстанциях;

часть 7-1. Базовая структура связи для подстанций и линейного оборудования - Принципы и модели;

часть 7-2. Базовая структура связи для подстанций и линейного оборудования - Абстрактный интерфейс услуг связи (ACSI);

часть 7-3. Базовая структура связи для подстанций и линейного оборудования - Классы общих данных;

часть 7-4. Базовая структура связи для подстанций и линейного оборудования - Совместимые классы логических узлов и классы данных;

часть 8-1. Специфическое отображение сервиса связи (SCSM) - Схемы отображения на MMS (ИСО 9506-1 и ИСО 9506-2) и на ИСО/МЭК 8802-3;

часть 9-1. Специфическое отображение сервиса связи (SCSM) - Выборочные значения в пределах последовательного однонаправленного многоточечного канала связи типа "точка-точка";

часть 9-2. Специфическое отображение сервиса связи (SCSM) - Выборочные значения в соответствии с ИСО/МЭК 8802-3;

часть 10. Проверка соответствия.

Настоящий стандарт является частью набора спецификаций, который определяет многоуровневую архитектуру связи подстанции. Эта архитектура была выбрана для обеспечения абстрактных определений классов и сервисов таким образом, чтобы эти спецификации были независимы от конкретных стеков протоколов, реализаций и операционных систем.

Целью серии стандартов МЭК 61850 является обеспечение взаимодействия между различными устройствами, входящими в систему управления подстанцией. Передача информации между этими устройствами возможна благодаря определению иерархической модели класса (например, логическое устройство, логический узел, данные, набор данных, управление выдачей отчетов или регистрация в журнале) и сервисов, предоставляемых этими классами (например, получить, задать, выдать отчет, определить, удалить), в различных стандартах серии МЭК 61850-7.

В настоящем стандарте определен абстрактный интерфейс услуг связи (ACSI) для использования на подстанции предприятия электроэнергетики, что требует взаимодействия в реальном времени между интеллектуальными электронными устройствами. Интерфейс ACSI был определен как независимый от базовых систем связи. Специфические отображения сервиса связи

(SCSM) описаны в МЭК 61850-8-1, МЭК 61850-9-1 и МЭК 61850-9-2.

_______________

Интерфейс ACSI не зависит от конкретного отображения. Возможно отображение в стандартных прикладных уровнях или технологиях межплатформенного программного обеспечения.

Настоящий стандарт определяет абстрактный интерфейс услуг связи в терминах:

- иерархической модели класса всей информации, которая может быть получена по сети связи;

- сервисов, которые работают в этих классах;

- параметров, связанных с каждым сервисом.

Методика описания ACSI абстрагирована от всего разнообразия подходов к реализации взаимодействия различных устройств.

Примечание 1 - Абстрагирование в ACSI имеет два значения. Первое - смоделированы только те аспекты реального устройства (например, выключателя) или реальной функции, которые видны и доступны из сети связи. Это абстрагирование позволяет создать иерархические модели класса и их режимы, описанные в настоящем стандарте, МЭК 61850-7-3 и МЭК 61850-7-4. Второе - интерфейс ACSI абстрагирован от ряда аспектов конкретных определений (например, каким образом происходит обмен информацией между устройствами). Определено только концептуальное взаимодействие. Конкретный обмен информацией определен в SCSM.

Примечание 2 - Настоящий стандарт не содержит полного руководства по обучению. Рекомендуется ознакомиться с МЭК 61850-5, МЭК 61850-7-1 и МЭК 61850-7-3.

Примечание 3 - В примерах использованы имена классов (например, XCBR для класса логического узла), определенные в МЭК 61850-7-3 и МЭК 61850-7-4. Нормативные имена определены только в МЭК 61850-7-3 и МЭК 61850-7-4.

      1 Область применения

Настоящий стандарт распространяется на связь через интерфейс ACSI для приложений, связанных с оборудованием подстанций и линий. ACSI обеспечивает следующие абстрактные интерфейсы:

a) Абстрактный интерфейс, описывающий связи между клиентом и удаленным сервером для:

- доступа к данным и поиска данных в реальном времени;

- управления устройством;

- составления отчетов по событию и регистрации события;

- взаимодействия сервера публикации/подписчика;

- самоописания устройств (словарь данных устройства);

- печати данных и определения типов данных;

- передачи файлов.

b) Абстрактный интерфейс для быстрого и надежного распределения событий по всей системе между каким-либо приложением в одном устройстве и множеством удаленных приложений в различных устройствах (сервер публикации/подписчик) и для передачи выборочных измеренных значений (сервер публикации/подписчик).

Настоящий стандарт также может быть использован для описания моделей и функций устройств для дополнительных действий, таких как обмен информацией:

- между подстанциями;

- между подстанцией и центром управления;

- между электростанцией и центром управления;

- для распределенной генерации;

- для целей учета электроэнергии.

      2 Нормативные ссылки

Приведенные ниже нормативные документы обязательны при применении настоящего стандарта. Для датированных ссылок применяется только редакция, на которую имеется ссылка. Для недатированных ссылок применяется последнее издание указанного нормативного документа (включая все поправки).

МЭК 61850-2:2003 Сети и системы связи на подстанциях. Часть 2. Словарь терминов

IEC 61850-2 Communication networks and systems in substations - Part 2: Glossary

МЭК 61850-5:2003 Сети и системы связи на подстанциях. Часть 5. Требования к связи для функций и моделей устройств

IEC 61850-5 Communication networks and systems in substations - Part 5: Communication requirements for functions and devices models

МЭК 61850-7-1:2003 Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 1. Принципы и модели

IEC 61850-7-1 Communication networks and systems in substations - Part 7-1: Basic communication structure for substation and feeder equipment - Principles and models

МЭК 61850-7-3:2003 Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанции и линейного оборудования - Раздел 3. Классы общих данных

IEC 61850-7-3 Communication networks and systems in substations - Part 7-3: Basic communication structure for substation and feeder equipment - Common data classes

МЭК 61850-7-4:2003 Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования - Раздел 4. Совместимые классы логических узлов и классы данных

IEC 61850-7-4 Communication networks and systems in substations - Part 7-4: Basic communication structure for substation and feeder equipment - Compatible logical node classes and data classes

МЭК 61850-8-1:2004 Сети и системы связи на подстанциях. Часть 8. Специфическое отображение сервиса связи (SCSM) - Раздел 1. Схемы отображения на MMS (ИСО/МЭК 9506-1 и ИСО/МЭК 9506-2) и на ИСО/МЭК 8802-3

IEC 61850-8-1 Communication networks and systems in substations - Part 8-1: Specific communication service mapping (SCSM) - Mappings to MMS (ISO/IEC 9506-1 and ISO/IEC 9506-2) and to ISO/IEC 8802-3

      3 Термины и определения

В настоящем стандарте использованы термины и определения, приведенные в МЭК 61850-2, а также следующие термины с соответствующими определениями:

3.1 класс (class): Описание совокупности объектов, имеющих одинаковые атрибуты, сервисы, взаимосвязи и семантику.

3.2 клиент (client): Объект, запрашивающий сервис у сервера и получающий от сервера незатребованные сообщения.

3.3 устройство (device): Объект, выполняющий функции управления и обмена информацией и соединяющийся с другими подобными объектами в рамках системы автоматизации.

Примечание - Устройства не выполняют функции передачи энергии.

3.4 внешнее оборудование

(external equipment): Объект, выполняющий функции передачи энергии; сопряжен с системой автоматизации либо автономен от нее.

_______________

Первичное оборудование.

Пример - Трансформатор, выключатель, линия.

Примечание 1 - Оборудование может включать в себя устройства.

Примечание 2 - Оборудование не может иметь прямого соединения с сетью связи - только устройства могут быть напрямую соединены с сетью связи.

3.5

экземпляр (класса)

[instance (of a class)]: Объект, имеющий однозначную идентичность, к которому может быть применен набор сервисов и который имеет состояние, сохраняющее действия сервисов

.

_______________

Инстанцирование (англ. Instantiation) - создание экземпляра определенного класса [МЭК 61850-2 (2.58)].

Примечание - Экземпляр является синонимом термина объект.

3.6 логическое устройство (logical device): Объект, представляющий набор типичных функций подстанции.

3.7 логический узел (logical node): Объект, представляющий типичную функцию подстанции.

3.8 физическое устройство (physical device): Объект, представляющий физическую часть устройства (аппаратные средства, операционная система и т.д.).

Примечание - Физические устройства содержат логические устройства.

      4 Сокращения

АА	APPLICATION-ASSOCIATION		прикладная ассоциация
ACSI	abstract communication service interface		абстрактный интерфейс услуг связи
BRCB	BUFFERED-REPORT-CONTROL-BLOCK		блок управления буферизованным отчетом
CDC	common DATA class		класс общих данных (по МЭК 61850-7-3)
СТ	current transformer		трансформатор тока
DA	data attribute		атрибут данных
DataRef	data reference		ссылка на данные
DAType	data attribute type		тип атрибута данных
dchg	data change trigger option		опция пуска при изменении данных
DS	DATA-SET		набор данных
dupd:	data-update trigger option		опция пуска при обновлении данных
FC	functional constraint		функциональная связь
FCD	functionally constrained DATA		функционально связанные данные
FCDA	functionally constrained DataAttribute		атрибут функционально связанных данных
Gl	general interrogation		общий опрос
GoCB	GOOSE-CONTROL-BLOCK		блок управления GOOSE
GOOSE	generic object oriented substation events		общие объектно-ориентированные события на подстанции
GsCB	GSSE-CONTROL-BLOCK		блок управления GSSE
GSE	generic substation event		общее событие на подстанции
GSSE	generic substation status event		общее событие состояния на подстанции
IED	intelligent electronic device		интеллектуальное электронное устройство
IntgPd	integrity period		период сохранности
LCB	LOG-CONTROL-BLOCK		блок управления журналом
LD	LOGICAL-DEVICE		логическое устройство
LN	LOCAL-NODE		логический узел
MC	multicast		многоадресный
MCAA	multicast application association		многоадресная прикладная ассоциация
MMS	manufacturing message specification		спецификация производственных сообщений
MSVCB	MULTICAST-SAMPLED-VALUE-CONTROL-BLOCK		блок управления многоадресным выборочным значением
PDU	protocol data unit		протокольная единица обмена (протокольный блок данных)
PICS	protocol implementation conformance statement		свидетельство о соответствии реализации протокола
PIXIT	protocol Implementation extra information		дополнительная информация о реализации протокола
qchg	quality change trigger option		опция пуска при изменении качества
SBO	select before operate		выбрать, затем управлять
SCL	substation configuration language		язык конфигурации подстанции (по МЭК 61850-6)
SCSM	specific communication service mapping		специфическое отображение сервиса связи (определено в МЭК 61850-8-1, МЭК 61850-9-1 и МЭК 61850-9-2)
SG	setting group		группа настроек
SGCB	SETTING-GROUP-CONTROL-BLOCK		блок управления группой настроек
SoE	sequence-of-events		последовательность событий
SV	sampled value		выборочное (мгновенное) значение
SVC	sampled value control		управление выборочными значениями
TP	TWO-PARTY		два абонента
TPAA	TWO-PARTY-APPLICATION-ASSOCIATION		прикладная ассоциация двух абонентов
TrgOp	trigger option		опция пуска
UCA	Utility Communication Architecture		коммуникационная архитектура предприятий электроэнергетики
URCB	UNBUFFERED-REPORT-CONTROL-BLOCK		блок управления небуферизованным отчетом
UTC	coordinated universal time		универсальное координированное время
USVCB	UNICAST-SAMPLED-VALUE-CONTROL-BLOCK		блок управления одноадресным выборочным значением
VT	voltage transformer		трансформатор напряжения

      5 Обзор и основные концепции абстрактного интерфейса услуг связи (ACSI)

      5.1 Общие сведения

Модели ACSI обеспечивают:

- спецификацию базовой модели для определения специальных информационных моделей подстанции, рассмотренных в МЭК 61850-7-3 (общие классы данных DATA) и МЭК 61850-7-4 (совместимые классы логических узлов LOGICAL-NODE и совместимые классы данных DATA);

- спецификацию моделей сервиса информационного обмена.

Информационные модели и сервисы информационного обмена тесно переплетены. С описательной точки зрения эти два аспекта до некоторой степени разделены (см. фрагмент, показанный на рисунке 1). Общие модели (например, классы логических узлов LOGICAL-NODE и классы данных DATA, включающие их сервисы) применены в МЭК 61850-7-3 и МЭК 61850-7-4 для определения многих специализированных информационных моделей - моделей автоматизации подстанции.

Рисунок 1 - Часть концептуальной модели

В настоящем стандарте также определены другие модели сервиса, необходимые для систем автоматизации подстанции (например, набор данных DATA-SET и выдача отчетов обеспечивают сервисы обмена специфической информацией); эти модели привязаны к логическим узлам (LOGICAL-NODE) и данным (DATA). Сервисы обмена информацией полностью определены в ACSI. Информационные модели, описанные в МЭК 61850-7-4, имеют ссылки на сервисы, определенные в различных моделях ACSI.

      5.2 Общее описание базовых информационных моделей

Концептуальными моделями для построения информационных моделей, специфических для определенной области, являются:

a) SERVER - представляет внешне видимое поведение устройства. Все остальные модели ACSI являются частью сервера.

Примечание 1 - Сервер играет две роли: связь с клиентом (большинство моделей сервисов, описанных в стандартах МЭК 61850 (все части), обеспечивают связь с устройствами клиента) и посылка информации одноранговым устройствам (например, для выборочных значений);

b) LOGICAL-DEVICE (LD) (логическое устройство) - содержит информацию, которую производит и использует группа функций приложения, специфических для определенной области; функции определяют как логические узлы (LOGICAL-NODE);

c) LOGICAL-NODE (LN) (логический узел) - содержит информацию, которую производит и использует функция приложения, специфическая для определенной области, например защита от перенапряжений или выключатель;

d) DATA (данные) - предоставляют средства определения типизированной информации, содержащейся в логических узлах, например положение переключателя с информацией о качестве и временной меткой.

Каждая из этих информационных моделей определяется как класс. Эти классы включают атрибуты и сервисы. Концептуальная схема классов ACSI изображена на рисунке 2.

Примечание 2 - Классы - основные компоновочные блоки, обеспечивающие структуру для моделей устройств автоматизации подстанции. Дополнительные подробности по моделированию и связям между МЭК 61850-7-3, МЭК 61850-7-4 и настоящим стандартом можно найти в МЭК 61850-7-1.

Примечание 3 - Цифры указывают соответствующие разделы в настоящем стандарте.

Рисунок 2 - Базовая концептуальная модель класса ACSI

Класс Name (имя) наследуется классами LOGICAL-DEVICE (логическое устройство), LOGICAL-NODE (логический узел), DATA (данные) и DataAttribute (атрибут данных).

Пример - При реализации каждое логическое устройство, логический узел, данные и атрибут данных имеют имя объекта (имя экземпляра), которое является уникальным именем среди классов того контейнера, которому они принадлежат. Кроме того, каждый из четырех классов имеет объектную ссылку ObjectReference (имя пути), которая является конкатенацией всех имен объекта из каждого контейнера. Четыре имени объекта могут быть соединены (по одному на графу).

      5.3 Обзор других моделей сервисов

В дополнение к моделям, описанным выше, в ACSI входят следующие модели, предоставляющие сервисы, работающие на данных, атрибутах данных и наборах данных:

a) DATA-SET (набор данных) - разрешает группирование данных и атрибутов данных. Используется для прямого доступа, а также для составления отчетов и регистрации;

b) Substitution (замещение) - поддерживает замещение технологического значения другим значением;

c) SETTING-GROUP-CONTROL-BLOCK (блок управления группой настроек) - определяет, как выполнять переключение с одного набора заданных значений на другой и как редактировать группы настроек;

d) REPORT-CONTROL-BLOCK (блок управления отчетом) и LOG-CONTROL-BLOCK (блок управления журналом) - описывают условия создания отчетов и журналов на основании параметров, заданных клиентом. Выдача отчетов может быть запущена при изменении значений технологических данных (например, изменение состояния или выход из зоны нечувствительности) или при изменении качества. Возможны запросы для последующего поиска журналов. Рассылка отчетов может быть выполнена немедленно или может быть отсрочена. Отчеты обеспечивают обмен информацией по изменению состояния и по последовательности событий;

e) control blocks for generic substation event (GSE) (блок управления общим событием на подстанции) - поддерживает быстрое и надежное распределение данных во всей системе; одноранговый обмен информацией о двоичном состоянии IED-устройств, например сигнал об отключении;

f) control blocks for transmission of sampled values (блок управления передачей выборочных значений) - быстрая и циклическая передача выборочных значений, например от измерительных трансформаторов;

g) control (управление) - описывает сервисы для управления, например устройствами;

h) time and time synchronization (время и временная синхронизация) - обеспечивает базу времени для устройства и системы;

i) file transfer (передача файла) - определяет обмен крупными блоками данных, например программами. На рисунке 3 показано общее представление концептуальной модели сервиса ACSI.

Примечание 1 - Цифры указывают соответствующие разделы настоящего стандарта.

Примечание 2 - Диаграммы классов являются концептуальными. Подробное описание приведено в соответствующих разделах. Диаграммы в полном объеме представлены в МЭК 61850-7-1. Класс данных DATA может быть определен рекурсивно. Операции по подстановке и управлению ограничены нижним уровнем в классе данных DATA. Атрибуты данных DataAttributes могут также быть определены рекурсивно.

Рисунок 3 - Концептуальная модель сервиса ACSI

Логический узел является одним из основных компоновочных блоков, имеющих ассоциации с большинством остальных моделей информационного обмена, например с управлением генерацией отчетов, управлением регистрацией и управлением настройками.

Любая другая модель сервиса обмена информацией, например управление генерацией отчетов, управление регистрацией и управление настройками, должна наследовать имя объекта (ObjectName) и ссылку объекта (ObjectReference), как это показано на рисунке 2.

Примечание 3 - Модели классов и сервисы определяют с использованием объектно-ориентированного подхода, позволяющего выполнять отображение моделей классов и сервисов на различные решения уровня приложения и межплатформенного программного обеспечения (ПО).

      5.4 Обзор сервисов ACSI

В таблице 1 приведен полный список классов ACSI и их сервисов.

Таблица 1 - Классы ACSI

      5.5 Определения типов

5.5.1 Типы атрибутов данных

Настоящий стандарт и МЭК 61850-7-3 используют типы, определенные в следующих подразделах, для определения специальных данных для моделей приложений, описанных в МЭК 61850-7-4, и блоков управления, описанных в настоящем стандарте (например, блоков управления генерацией отчетов).

Концепция типа атрибута данных представлена на рисунке 4. Тип атрибута данных DAType является классом, который имеет три элемента:

1) Name - имя;

2) Presence - указание того, является ли этот атрибут обязательным (атрибут имеется) или опциональным (наличие атрибута не обязательно);

3) BasicTypes - основные типы.

Примечание - Атрибут Presence в данных примерах не показан

Рисунок 4 - Концепция типа атрибута данных

Примечание 1 - Класс DAType является абстрактным классом, т.е. дополнительным средством создания примитивных и составных компонентов.

Примечание 2 - Формализованное описание класса DAType и использование DATypes для описания типов атрибутов данных представлены в разделе 10. Диаграмма класса включена в текст данного подраздела для описания контекста, в котором использованы базовые типы.

Примечание 3 - Подробный пример приведен в МЭК 61850-7-1.

Базовые типы BasicTypes (например, BOOLEAN и INT8) используют для построения примитивных компонентов (PrimitiveComponents) и составных компонентов (CompositeComponents). Примитивные компоненты должны иметь имя (Name), указание (Presence) и основной тип (BasicType) (например, Name=i, Presence= Обязательный и BasicType=INT32). Составной компонент состоит из одного или более примитивных компонентов базового типа (например, Name = mag типа AnalogueValue, включая два компонента PrimitiveComponents i (тип INT32) и f (тип FLOAT32)).

Общие составные компоненты и примитивные компоненты определены в различных классах общих данных DATA в МЭК 61850-7-3.

5.5.2 Базовые типы BasicTypes

Базовые типы (BasicTypes) должны соответствовать приведенным в таблице 2.

Таблица 2 - Базовые типы

Имя	Диапазон значения	Примечание	Использован в стандарте
BOOLEAN			МЭК 61850-7-2   МЭК 61850-7-3
INT8	От -28 до 127		МЭК 61850-7-2   МЭК 61850-7-3
INT16	От -32768 до 32767		МЭК 61850-7-2   МЭК 61850-7-3
INT24	От -8388608 до 8388607	Для типа TimeStamp	МЭК 61850-7-2
INT32	От -2147483648 до 2147483647		МЭК 61850-7-2   МЭК 61850-7-3
INT128	От -2**127 до (2**127)-1	Требуется для счетчиков	МЭК 61850-7-3
INT8U	Целочисленный тип без знака от 0 до 255		МЭК 61850-7-2   МЭК 61850-7-3
INT16U	Целочисленный тип без знака от 0 до 65535		МЭК 61850-7-2   МЭК 61850-7-3
INT24U	Целочисленный тип без знака от 0 до 16777215		МЭК 61850-7-2
INT32U	Целочисленный тип без знака от 0 до 4294967295		МЭК 61850-7-2   МЭК 61850-7-3
FLOAT32	Диапазон значений и точность согласно плавающей точке с одинарной точностью в соответствии с IEEE 754		МЭК 61850-7-3
FLOAT64	Диапазон значений и точность согласно плавающей точке с двойной точностью в соответствии с IEEE 754		МЭК 61850-7-3
ENUMERATED	Упорядоченный набор значений; определяется местом использования типа	Разрешаются пользовательские расширения	МЭК 61850-7-2   МЭК 61850-7-3
CODED ENUM	Упорядоченный набор значений; определяется местом использования типа	Пользовательские расширения запрещены. Тип должен отображаться в эффективном кодировании в SCSM	МЭК 61850-7-2   МЭК 61850-7-3
OCTET STRING	Максимальная длина должна определяться местом использования типа		МЭК 61850-7-2   МЭК 61850-7-3
VISIBLE STRING	Максимальная длина должна определяться местом использования типа		МЭК 61850-7-2   МЭК 61850-7-3
UNICODE STRING	Максимальная длина должна определяться местом использования типа		МЭК 61850-7-3
Суффикс длины должен иметь формат "...STRINGnn", где "nn" - это длина (количество символов).

5.5.3 Общие типы ACSI

5.5.3.1 Общие сведения

Общие типы ACSI необходимо использовать для определений атрибутов классов (например, блоков управления генерированием отчетов), определенных в настоящем стандарте. Общие типы ACSI также могут быть использованы в моделях приложений, определенных в МЭК 61850-7-3 и МЭК 61850-7-4.

5.5.3.2 Тип ObjectName (имя объекта)

Тип ObjectName (имя объекта) должен описывать уникальное имя экземпляра среди экземпляров класса, принадлежащего тому же самому порождающему классу, с типом согласно таблице 3.

Таблица 3 - Тип ObjectName (имя объекта)

5.5.3.3 Тип ObjectReference (ссылка объекта)

Экземпляры классов иерархической информационной модели (иерархия классов ACSI для логического устройства, логического узла, данных, атрибутов данных) создаются методом конкатенации всех имен экземпляра, включающих имя всего пути экземпляра класса, которое однозначно определяет данный экземпляр. Тип ObjectReference (ссылка объекта) должен быть таким, как определено в таблице 4.

Таблица 4 - Тип ObjectReference (ссылка объекта)

Синтаксис ObjectReference (объектная ссылка) должен быть следующим:

Наименование экземпляра логического устройства (LDName) должно быть отделено от имени экземпляра логического узла (LNName) значком дроби "/". Точка "." должна отделять последующие имена в иерархии. Знак "[ ]" (пробел) должен обозначать опцию. Внутренние квадратные скобки "[. ...]" должны указывать дальнейшие имена рекурсивно вложенных определений.

Примечание 1 - Во всех случаях, когда из контекста понятно, что речь идет об экземпляре класса, термин "экземпляр" не используют.

Примечание 2 - В разделе 19 описаны ограничения по использованию типа ObjectReference (ссылка объекта).

5.5.3.4 Тип ServiceError (ошибка сервиса)

Код ошибки сервиса для негативных ответов сервиса (созданный в пределах сервера) должен соответствовать описанию таблицы 5.

Таблица 5 - Тип ServiceError (ошибка сервиса)

Дополнительные значения ServiceError (ошибка сервиса) для отрицательных ответов сервиса (созданных в приложении, например выявление дополнительных причин для сервисов, относящихся к управлению) указаны в соответствующих моделях сервиса.

Примечание - Тип ServiceError (ошибка сервиса) может быть расширен специфическим отображением сервиса связи (SCSM), а также на уровне приложения, на которое ссылается SCSM.

5.5.3.5 Тип EntrylD (идентификатор точки входа)

Тип EntrylD (идентификатор точки входа) представляет произвольную строку символов OCTET STRING, используемую для определения точки входа в последовательность событий, например в журнал или буферизированный отчет, как это описано в SCSМ.

Примечание 1 - Тип EntrylD (как средство оперирования) позволяет клиенту провести ресинхронизацию, например, с последовательностью событий, сохраненных в IED-устройстве. Синтаксис и семантика EntrylD не описаны в настоящем стандарте.

Примечание 2 - Тип EntrylD использован в настоящем стандарте.

5.5.3.6 Тип PACKED LIST (сжатый список)

Тип PACKED LIST (сжатый список) должен соответствовать таблице 6.

Таблица 6 - Тип PACKED-LIST (сжатый список)

5.5.3.7 Тип TimeStamp (временная метка)

5.5.3.7.1 Общие положения

В разделе 18 описано отношение между значением временной метки, синхронизацией внутреннего времени с внешним источником времени (например, универсального координированного времени UTC), а также дана другая информация, связанная с временной моделью.

Примечание 1 - Тип TimeStamp (временная метка) основывается на требованиях, описанных в разделе 18. Этот раздел необходимо прочитать в первую очередь. Представление типа TimeStamp определено в специфических отображениях сервиса связи (SCSM).

Примечание 2 - Тип TimeStamp использован в настоящем стандарте и в МЭК 61850-7-3.

5.5.3.7.2 Синтаксис TimeStamp

Тип TimeStamp представляет время UTC с началом отсчета в полночь (00:00:00) 1970-01-01, как указано в таблице 7.

Таблица 7 - Тип TimeStamp (временная метка)

Имя атрибута	Тип атрибута	Значение/диапазон значения/пояснение	М/О
SecondSinceEpoch	INT32	(0..MAX)	М
FractionOfSecond	INT24U	Value (Значение) = SUM выражения *2**-(i+1)   при от 0 до 23   Order (Порядок) = , , , , ...	М
TimeQuality	TimeQuality		М

5.5.3.7.3 Атрибуты TimeStamp

5.5.3.7.3.1 Атрибут SecondSinceEpoch

Атрибут SecondSinceEpoch представляет собой интервал в секундах, отсчитываемых непрерывно с начала отсчета 1970-01-01 00:00:00 UTC.

Примечание - Атрибут SecondSinceEpoch соответствует началу отсчета в Unix.

5.5.3.7.3.2 Атрибут FractionOfSecond

Атрибут

FractionOfSecond

является той долей текущей секунды, во время которой было определено значение

TimeStamp

. Эта доля секунды должна быть рассчитана как (SUM выражения

*2**-(i+1) секунд при

0...23).

Примечание 1 - Разрешение определяется наименьшим разрядом обновления временной метки. 24-битовое целое число в качестве наименьшей единицы обеспечивает 1 из 16777216 импульсов счета; рассчитывается как 1/2**24, что приблизительно равняется 60 нc.

Примечание 2 - Разрешение временной метки может равняться 1/2**1 (=0,5 с), если используется только первый бит; или же оно может быть равно 1/2**2 (=0,25 с), если использовано два первых бита. Если использованы все 24 бита, оно может равняться 60 нс. Разрешение, обеспечиваемое IED-устройством, не описано в настоящем стандарте.

5.5.3.7.3.3 Атрибут TimeQuality

Атрибут TimeQuality обеспечивает информацию об источнике времени передающего IED-устройства, что отражено в таблице 8.

Таблица 8 - Определение TimeQuality

LeapSecondsKnown

Значение TRUE (логическая единица) атрибута LeapSecondsKnown означает, что в значении SecondSinceEpoch учтены все имевшие место коррекции секунды. Если это значение FALSE (логический нуль), то в данном значении не учтены те коррекции секунды, которые имели место до инициализации источника времени данного устройства.

ClockFailure

Атрибут ClockFailure означает, что источник времени передающего устройства ненадежный. Значение TimeStamp должно быть проигнорировано.

ClockNotSynchronized

Атрибут ClockNotSynchronized означает, что источник времени передающего устройства не синхронизирован с внешним временем UTC.

TimeAccuracy

Атрибут TimeAccuracy представляет класс точности времени источника времени передающего устройства по отношению к внешнему времени UTC. Классы timeAccuracy представляют количество значимых битов в FractionOfSecond.

Эти значения должны соответствовать перечисленным в таблице 9.

Примечание 1 - Атрибут TimeAccuracy удовлетворяет требованиям для выборочных значений n, указанным в МЭК 61850-5.     

Таблица 9 - Атрибут TimeAccuracy

5.5.3.8 Тип EntryTime (время ввода)

Тип EntryTime (время ввода) представляет время и дату при внутреннем использовании для передачи информации, генерирования отчетов и регистрации и для подсистем, как указано в SCSM.

Примечание 1 - Тип TimeStamp используют для общих классов данных DATA в МЭК 61850-7-3 и определения совместимых классов данных DATA в МЭК-61850-7-4. Тип EntryTime использован для всех определений классов в настоящем стандарте. Тип EntryTime может отличаться или быть таким же, как TimeStamp в SCSM.

Примечание 2 - Тип EntryTime использован в настоящем стандарте.

5.5.3.9 Тип TriggerConditions (условия пуска)

Тип TriggerConditions (условия пуска) представляет условия пуска для запуска обработки отчетов и журналов (см. таблицу 10).

Таблица 10 - Тип TriggerConditions (условия пуска)

Примечание 1 - Тип TriggerConditions использован в настоящем стандарте и в МЭК 61850-7-3.

Сервис TriggerOption (TrgOp) использован в спецификации атрибутов данных DataAttributes для указания того, по какому изменению/обновлению данное значение экземпляра DataAttribute может быть включено в отчет или зарегистрировано в журнале.

Примечание 2 - Подробнее об использовании типа TriggerConditions см. в 10.2.2.4.3 и разделе 14.

      6 Модель класса SERVER (сервер)

      6.1 Определение класса SERVER

6.1.1 Синтаксис класса SERVER

Класс SERVER представляет внешне видимое поведение устройства. Класс SERVER представляет собой сочетание, определенное в таблице 11.

Таблица 11 - Определение класса SERVER

Примечание 1 - Для простых устройств сервер может включать только одно логическое устройство с моделью управления GOOSE без каких-либо других сервисов.

6.1.2 Атрибуты класса SERVER

6.1.2.1 Атрибут ServiceAccessPoint

Атрибут ServiceAccessPoint идентифицирует SERVER в пределах системы.

Примечание - Атрибут ServiceAccessPoint является абстракцией адреса, используемого для идентификации сервера в нижележащем SCSM. Этот тип зависит от SCSM и должен определяться там. Большинство сервисов для адресации сервера требуют наличия специального атрибута ServiceAccessPoint. Тем не менее он не был явным образом включен в таблицы параметров сервиса в настоящем стандарте.

6.1.2.2 Атрибут LogicalDevice [1..n]

Атрибут LogicalDevice определяет логическое устройство LD, которое содержится в сервере SERVER.

6.1.2.3 Атрибут File [0..n]

Атрибут File определяет файл, содержащийся в сервере SERVER.

6.1.2.4 Атрибут TPAppAssociation [0..n] - прикладная ассоциация двух абонентов

Атрибут TPAppAssociation определяет клиента, с которым SERVER поддерживает прикладную ассоциацию двух абонентов.

Примечание - Более подробная информация представлена в разделе 7.

6.1.2.5 Атрибут MCAppAssociation [0..n] - многоадресная прикладная ассоциация

Атрибут MCAppAssociation определяет подписчика, с которым SERVER (сервер публикаций) поддерживает многоадресную прикладную ассоциацию.

Примечание - Более подробная информация представлена в разделе 7.

      6.2 Сервисы класса SERVER

6.2.1 Общее описание сервисов GetDefinition и директории

Для поддержки самоописания устройства в настоящем стандарте описаны несколько сервисов GetXXDirectory и GetXXDefinition, показанных на рисунке 5.

Рисунок 5 - Общее описание сервисов GetDirectory и GetDefinition

Клиент должен использовать эти сервисы для поиска определения полной иерархии, а также для определения всей доступной информации и всех экземпляров всех базовых классов в данном сервере.

6.2.2 Сервис GetServerDirectory

6.2.2.1 Таблица параметров сервиса GetServerDirectory

Клиент должен использовать сервис GetServerDirectory для поиска списка имен всех логических устройств LD или файлов Files, ставших видимыми и, следовательно, доступными для запрашивающего клиента через адресуемый сервер SERVER.

Примечание - Видимые экземпляры - это экземпляры, определяемые в рамках данного представления (более подробная информация о концепции представления приведена в разделе 7).

6.2.2.2 Параметр Request (запрос)

6.2.2.2.1 Параметр ObjectClass (класс объекта)

Параметр ObjectClass должен содержать выбранный класс. Клиент должен выбрать один из следующих классов:

- LOGICAL-DEVICE;

- FILE.

6.2.2.3 Параметр Response+ (Ответ+)

Параметр Response+ указывает, что запрос сервиса завершился успешно. Вместе с успешным результатом должен поступить следующий параметр.

6.2.2.3.1 Параметр Reference [0..n] (Ссылка [0..n])

Параметр Reference содержит объектную ссылку логического устройства LD или имени файла (FileName).

Примечание - Тип FileName (имя файла) - это видимая строка VISIBLE STRING255.

6.2.2.4 Параметр Response- (Ответ-)

Параметр Response- указывает, что запрос сервиса завершился неуспешно. Должно вернуться сообщение об ошибке ServiceError.

      7 Прикладная модель ассоциации

      7.1 Введение

Прикладная модель ассоциации включает условия обеспечения связи между различными типами устройств. В модель входят:

- определения классов ассоциаций (двухабонентская или многоадресная);

- концепции управления доступом (как ограничивать доступ к экземплярам на сервере).

Требования безопасности для ограничения доступа к данным на сервере определены в МЭК 61850-5.

Примечание - Требования безопасности реализуются через специфические отображения сервиса связи (SCSM).

      7.2 Концепция прикладных ассоциаций

Модель прикладной ассоциации определяет:

- сервисы для управления ассоциациями между клиентом и сервером (прикладная ассоциация двух абонентов);

- сервисы для управления ассоциациями для многоадресной рассылки сообщений (например, GOOSE и передача выборочных значений).

Класс прикладная ассоциация двух абонентов должен передавать запросы и ответы сервиса (тем самым передавая сервисы с подтверждением и без подтверждения). Класс многоадресная прикладная ассоциация должен иметь возможность передавать сервисы без подтверждения (только в одном направлении).

Прикладные ассоциации обеспечивают механизм управления доступом к экземплярам устройства (управление доступом).

Примечание - Подробнее модель прикладной ассоциации описана в SCSM. Приведенные ниже описания представляют концептуальную модель прикладных ассоциаций между устройствами.

      7.3 Управление доступом

Модель управления доступом обеспечивает возможность ограничения доступа отдельного клиента к экземплярам класса, атрибутам экземпляра класса и сервисам ACSI, работающим с экземплярами класса отдельного сервера. Сервер ACSI содержит набор, например, логических устройств LD, логических узлов LN, данных DATA или элементов управления генерацией отчетов. Набор экземпляров, видимых (и, следовательно, доступных) для клиента, ограничен на основании идентификации клиента и спецификации управления доступом данного сервера. Такой ограниченный набор называется виртуальным представлением доступа. Виртуальное представление доступа может ограничивать видимость не только экземпляров или атрибутов, но также поддерживаемого сервиса. Концепция виртуального представления доступа проиллюстрирована на рисунке 6.

Рисунок 6 - Представления доступа к серверу

Примечание 1 - Виртуальное представление доступа - это представление аутентификации модели данных IED-устройств.

У двух пользователей А и В имеются различные виртуальные представления доступа к серверу (представление 1 и представление 2). Представление 1 позволяет обеспечить дистанционный доступ только к одним данным DATA (XCBR.OperCnt). Представление 2 позволяет получить доступ ко всем данным DATA.

Целью стандартов серии МЭК 61850 является создание для устройства виртуального представления доступа к серверу. Тем самым обеспечивается ограничение доступа для любого пользователя, пытающегося получить доступ к определенным экземплярам. Независимо от реализации в данном устройстве может быть введено дополнительное ограничение доступа на стороне пользователя, например локальный пароль или просто какая-либо клавиша на клавиатуре.

Если какое-либо представление скрывает обязательный экземпляр атрибута данных DATA, то тогда этот скрытый атрибут должен быть реализован так, как это требуется этими данными DATA.

Примечание 2 - Представление ограничивает видимость только для некоторых пользователей.

Клиент (или подписчик в случае многоадресной прикладной ассоциации) должен идентифицироваться параметрами аутентификации, переданными на сервер при установлении ассоциации с этим сервером (прикладная ассоциация двух абонентов) или при отправке информации через многоадресные прикладные ассоциации.

Примечание 3 - Механизмы на стороне клиента не рассматриваются в настоящем стандарте. Пользователь также может воспользоваться копией представления доступа для ограничения доступа на стороне клиента.

Примечание 4 - Управление доступом, включая структуру и содержимое параметра аутентификации, подробно описано в специфических отображениях сервиса связи (SCSM).

      7.4 Модель класса TWO-PARTY-APPLICATION-ASSOCIATION (TPAA)

7.4.1 Определение класса ТРАА

7.4.1.1 Синтаксис класса ТРАА

Тип прикладной ассоциации двух абонентов должен обеспечивать двунаправленный обмен информацией с установлением логического соединения. Прикладные ассоциации должны быть надежными, также должен быть обеспечен полный контроль над потоком информации от точки до точки. Надежность означает, что соединение, на котором основана данная прикладная ассоциация, обеспечивает мероприятия по уведомлению о причинах недоставки информации в должный промежуток времени. Непрерывное управление потоком от точки до точки означает, что источники информации посылают информацию в объеме, не превышающем объем буфера целевого устройства.

На рисунке 7 изображены сервисы установления ассоциации, обмена данными и прерывания ассоциации класса прикладной ассоциации двух абонентов.

Рисунок 7 - Нормальный режим работы

Сервис прерывания для класса прикладной ассоциации двух абонентов изображен на рисунке 8.

Рисунок 8 - Прерывание соединения

Класс TWO-PARTY-APPLICATION-ASSOCIATION (TPAA) должен быть определен согласно таблице 12.

Таблица 12 - Определение класса ТРАА

7.4.1.2 Атрибуты класса ТРАА

7.4.1.2.1 Атрибут AssociationId

Атрибут AssociationId определяет идентификацию, используемую для определения прикладных ассоциаций.

Примечание - Тип атрибута Associationld определяется в специфических отображениях сервиса связи (SCSM). Он может быть заменен в SCSM или может быть использован только локально.

7.4.1.2.2 Атрибут AuthenticationParameter

Атрибут AuthenticationParameter представляет информацию, необходимую для получения разрешения на доступ к экземплярам специфического представления доступа к серверу.

Примечание - Минимальный набор параметров - это идентификация пользователя, представление и пароль. Подробности определены в специфических отображениях сервиса связи (SCSM).

7.4.2 Сервисы прикладной ассоциации двух абонентов ТРАА

7.4.2.1 Обзор

Для класса ТРАА определены следующие сервисы.

7.4.2.2 Сервис Associate

7.4.2.2.1 Параметры сервиса Associate

Для установления прикладной ассоциации двустороннего типа с определенным сервером клиент должен использовать сервис Associate.

7.4.2.2.2 Параметр Request (запрос)

7.4.2.2.2.1 Параметр ServerAccessPointReference (ссылка на точку доступа к серверу)

Параметр ServerAccessPointReference определяет сервер, с которым должна быть установлена прикладная ассоциация.

7.4.2.2.2.2 Параметр AuthenticationParameter

Параметр AuthenticationParameter определяет параметр идентификации для прикладной ассоциации, которая должна быть открыта. В случае несоответствия параметра AuthenticationParameter корректному параметру запрос сервиса должен быть отклонен с указанием в ответном сообщении соответствующей причины.

Примечание - Тип AuthenticationParameter определяется в SCSM.

7.4.2.2.3 Параметр Response+

Параметр Associationld

Параметр Associationld может быть использован для того, чтобы различать прикладные ассоциации.

Примечание - Параметр Associationld может быть использован в сообщении Response+ (Ответ+) SCSM или может быть использован только локально.

7.4.2.2.4 Параметр Result (Результат)

Параметр Result показывает, было ли установление прикладной ассоциации успешным или нет.

7.4.2.2.5 Параметр Response- (Ответ-)

Параметр Response- указывает, что запрос сервиса завершился неуспешно. Должно вернуться сообщение об ошибке ServiceError.

7.4.2.3 Сервис Abort (прерывание)

7.4.2.3.1 Параметр Abort (прерывание)

Сервис Abort (прерывание) используется для резкого разъединения определенной прикладной ассоциации между клиентом и сервером. Резкое разъединение означает, что все выданные запросы сервиса должны быть отвергнуты и никакие дальнейшие сервисы не должны обрабатываться.

7.4.2.3.2 Параметр Request (запрос)

7.4.2.3.2.1 Параметр Associationld

Параметр Associationld определяет ассоциацию, подлежащую прерыванию. Указание может быть выдано по нижележащему уровню (локально или дистанционно) или оно может быть прислано удаленным пользователем ассоциации.

7.4.2.3.2.2 Параметр Reason (причина)

Параметр Reason определяет причину прерывания ассоциации. Причина может быть представлена по базовому уровню (локально или дистанционно) или она может быть прислана удаленным пользователем ассоциации.

7.4.2.3.3 Параметр Indication (индикация)

7.4.2.3.3.1 Параметр AssociationId

Параметр Associationld определяет ассоциацию, подлежащую прерыванию.

7.4.2.3.3.2 Параметр Reason (причина)

Параметр Reason определяет причину резкого прекращения прикладной ассоциации.

7.4.2.4 Сервис Release (отключение)

7.4.2.4.1 Параметр Release

Сервис Release (отключение) используется для штатного разъединения определенной прикладной ассоциации между клиентом и сервером. Штатное разъединение означает, что все запросы сервисов должны быть выполнены до конца до прекращения ассоциации. Новые запросы не должны выдаваться после начала разъединения.

7.4.2.4.2 Параметр Request (запрос)

7.4.2.4.3 Параметр Associationld

Параметр Associationld определяет ассоциацию, подлежащую прекращению.

7.4.2.4.4 Параметр Response+ (Ответ+)

7.4.2.4.5 Параметр Result (Результат)

Параметр Result показывает, было ли прекращение прикладной ассоциации успешным или нет.

7.4.2.4.6 Параметр Response- (Ответ-)

Параметр Response- указывает, что запрос сервиса завершился неуспешно. Должно вернуться сообщение об ошибке ServiceError.

      7.5 Класс MULTICAST-APPLICATION-ASSOCIATION (MCAA)

7.5.1 Определение класса МСАА

7.5.1.1 Синтаксис класса МСАА

Тип многоадресной прикладной ассоциации обеспечивает однонаправленный информационный обмен. Многоадресный информационный обмен обеспечивается между одним источником (издатель) и одним или множеством адресатов (подписчик). Однонаправленный информационный обмен должен обеспечивать достаточную информацию для получателей, чтобы однозначно интерпретировать контекст, в котором данный обмен должен обрабатываться.

Подписчик должен иметь возможность обнаруживать потерю и повтор полученной информации. Получатель должен отправить уведомление о потере информации ее пользователю и должен отвергнуть повторно присланную информацию.

Примечание - Возможные ограничения для многоадресных сообщений, обмениваемых в отдельной подсети или посылаемых через маршрутизаторы, должны быть описаны в рамках SCSM.

Класс многоадресной прикладной ассоциации изображен на рисунке 9.

Рисунок 9 - Принцип многоадресной прикладной ассоциации

Класс MULTICAST-APPLICATION-ASSOCIATION (MCAA) должен соответствовать определению, приведенному в таблице 13.

Таблица 13 - Определение класса МСАА

7.5.1.2 Атрибуты класса МСАА

7.5.1.2.1 Атрибут AuthenticationParameter (параметр аутентификации)

Атрибут AuthenticationParameter должен представлять информацию, необходимую для получения клиентом разрешения на доступ к экземплярам специфического представления доступа.

Каждый многоадресный сервис должен предоставить параметр сервиса, который определяет параметр AuthenticationParameter для данного обмена информацией. В случае некорректности параметра AuthenticationParameter запрос сервиса должен быть отклонен принимающим устройством.

Примечание 1 - Тип AuthenticationParameter определяется в SCSM.

Примечание 2 - Каждый обмен информацией с использованием многоадресных сервисов может считаться сообщением по установлению ассоциации (associate message), несущим в себе параметры ассоциации и данные. Прикладная ассоциация (application association) прекращается после завершения обработки сервиса.

      8 Модель класса LOGICAL-DEVICE (логическое устройство)

      8.1 Определение класса LOGICAL-DEVICE

8.1.1 Синтаксис класса LOGICAL-DEVICE

Как определено в таблице 14, логическое устройство LOGICAL-DEVICE (LD) должно представлять собой композицию логического узла LOGICAL-NODE (LN).

Таблица 14 - Определение класса LD

Примечание - Логическое устройство LD может быть использовано просто как контейнер для группы логических узлов LN или как устройство, функционирующее как шлюз или посредническое устройство. Более подробная информация об использовании логических устройств представлена в МЭК 61850-7-1.

8.1.2 Атрибуты класса LOGICAL-DEVICE

8.1.2.1 Атрибут LDName - имя логического устройства

Атрибут LDName должен однозначно определять логическое устройство в пределах системы.

8.1.2.2 Атрибут LDRef - объектная ссылка логического устройства

Атрибут LDRef должен быть уникальным именем пути логического устройства:

Примечание - Класс LOGICAL-DEVICE является корнем дерева. Следовательно, атрибуты LDName и LDRef идентичны. Из концептуальных соображений они оба включены в таблицу 14.

8.1.2.3 Атрибут LogicalNode [3..n]

Атрибут LogicalNode должен определять логический узел LN, содержащийся в логическом устройстве LD.

Каждое логическое устройство LD должно иметь один и только один нулевой логический узел LOGICAL-NODE-ZERO (LLN0), один и только один логический узел LOGICAL-NODE-PHYSICAL-DEVICE (LPHD) и по меньшей мере еще один логический узел LN.

Примечание - Логические узлы LLN0, LPHD, относящиеся к автоматизации подстанции, и другие логические узлы определены в МЭК 61850-7-4.

      8.2 Сервисы класса LOGICAL-DEVICE

8.2.1 Сервис GetLogicalDeviceDirectory

8.2.1.1 Таблица параметров сервиса GetLogicalDeviceDirectory

Клиент должен использовать сервис GetLogicalDeviceDirectory для поиска списка объектных ссылок (ObjectReferences) всех логических узлов LN, ставших видимыми и, следовательно, доступными для запрашивающего клиента через ссылочное логическое устройство LD.

Примечание - Видимые экземпляры - это экземпляры, определяемые в рамках данного представления (более подробная информация о концепции представления приведена в разделе 7).

8.2.1.2 Параметр Request

8.2.1.2.1 Параметр LDReference - объектная ссылка логического устройства

Параметр LDReference должен содержать объектную ссылку LDRef логического устройства LD.

8.2.1.3 Параметр Response+

Параметр Response+ должен указывать, что запрос сервиса завершился успешно. Вместе с успешным результатом должен поступить следующий параметр.

8.2.1.3.1 Параметр LNReference [3..n] - объектная ссылка логического узла

Параметр LNReference должен содержать объектную ссылку LNRef логического узла LN от ссылочного логического устройства LD.

8.2.1.4 Параметр Response-

Параметр Response- должен указывать, что запрос сервиса завершился неуспешно. Должно вернуться сообщение об ошибке ServiceError.

      9 Модель класса LOGICAL-NODE (логический узел)

      9.1 Определение класса LOGICAL-NODE

9.1.1 Синтаксис класса LOGICAL-NODE

Логический узел LN должен представлять собой композицию данных DATA, DATA-SET, BRCB, URCB, LCB, LOG, SGCB, GoCB, GsCB, MSVCB и USVCB, как это определено в таблице 15.

Таблица 15 - Определение класса LOGICAL-NODE

Определение логических узлов LN для области приложений подстанции уточнено определением специальных данных DATA в МЭК 61850-7-4. Чтобы получить полное представление о логических узлах LN, специфических для области подстанции, необходимо принять во внимание определения по МЭК 61850-7-4 (и МЭК 61850-7-3 для классов общих DATA).

Примечание 2 - В МЭК 61850-7-4 определены дополнительные атрибуты для логических узлов LN. Например, определены режимы работы для специфического для подстанции логического узла LN- ON (включен), BLOCKED (блокирован), TEST (испытание) и др. Модель состояний логического узла смоделирована как специальные данные DATA (обозначенные Mod).

9.1.2 Атрибуты класса LOGICAL-NODE

9.1.2.1 Атрибут LNName - имя логического узла

Атрибут LNName должен однозначно определять логический узел в пределах логического устройства.

9.1.2.2 Атрибут LNRef - объектная ссылка логического узла

Атрибут LNRef должен быть уникальным именем пути логического узла LN.

Объектная ссылка ObjectReference должна иметь следующий вид:

9.1.2.3 Атрибут Data [1..n]

Атрибут Data должен определять данные DATA (см. раздел 10), содержащиеся в данном логическом устройстве.

Примечание - В МЭК 61850-7-4 определены стандартизованные данные, называемые классами совместимых данных DATA.

9.1.2.4 Атрибут DataSet [0..n]

Атрибут DataSet должен определять набор данных DATA-SET (см. раздел 11), содержащийся в данном логическом узле LN.

9.1.2.5 Атрибут BufferedReportControlBlock[0..n]

Атрибут BufferedReportControlBlock должен определять блок управления буферизованным отчетом BRCB (см. 14.2), содержащийся в данном логическом узле LN.

9.1.2.6 Атрибут UnbufferedReportControlBlock [0..n]

Атрибут UnbufferedReportControlBlock дoлжeн определять блок управления небуферизованным отчетом URCB (см. 14.2), содержащийся в данном логическом узле LN.

9.1.2.7 Атрибут LogControlBlock [0..n]

Атрибут LogControlBlock должен определять блок управления журналом LCB (см. 14.3), содержащийся в данном логическом узле LN.

9.1.2.8 Атрибут SettingGroupControlBlock [0..1]

Атрибут SettingGroupControlBlock должен определять блок управления группой настроек SGCB (см. раздел 13), содержащийся в логическом узле LLN0.

9.1.2.9 Атрибут Log [0..1]

Атрибут Log должен определять журнал LOG (см. 14.3.3), содержащийся в логическом узле LLN0.

9.1.2.10 Атрибут GOOSEControlBlock [0..n]

Атрибут GOOSEControlBlock должен определять блок управления GOOSE GoCB (см. 15.2), содержащийся в логическом узле LLN0.

9.1.2.11 Атрибут GSSEControlBlock [0..n]

Атрибут GSSEControl должен определять блок управления GSSE GsCB (см. 15.3), содержащийся в логическом узле LLN0.

9.1.2.12 Атрибут MulticastSampledValueControlBlock [0..n]

Атрибут MulticastSampledValueControlBlock должен определять блок управления MSV (многоадресные выборочные значения) MSVCB (см. 16.2), содержащийся в логическом узле LLN0.

9.1.2.13 Атрибут UnicastSampledValueControlBlock [0..n]

Атрибут UnicastSampledValueControlBlock должен определять блок управления USV (одноадресные выборочные значения) USVCB (см. 16.3), содержащийся в логическом узле LLN0.

      9.2 Сервисы класса LOGICAL-NODE

9.2.1 Общее описание

Для класса LOGICAL-NODE (логический узел) определены следующие сервисы:

9.2.2 Сервис GetLogicalNodeDirectory

9.2.2.1 Таблица параметров сервиса GetLogicalNodeDirectory

Клиент должен использовать сервис GetLogicalNodeDirectory для поиска списка объектных ссылок всех экземпляров запрашиваемого класса, ставших видимыми и, следовательно, доступными для запрашивающего клиента через ссылочный логический узел LN.

Примечание - Видимые экземпляры - это экземпляры, определяемые в рамках данного представления (более подробная информация о концепции представления приведена в разделе 7).

9.2.2.2 Параметр Request (запрос)

9.2.2.2.1 Параметр LNReference

Параметр LNReference должен содержать объектную ссылку LNRef логического узла LN.

9.2.2.2.2 Параметр ACSICIass

Параметр ACSICIass должен содержать модель выбранного класса ACSI, которому должны быть направлены объектные ссылки всех моделей класса ACSI.

Клиент должен выбрать одну из следующих моделей класса ACSI:

DATA, DATA-SET, BRCB, URCB, LCB, LOG, SGCB, GoCB, GsCB, MSVCB, USVCB.

9.2.2.3 Параметр Response+

Параметр Response+ должен указывать, что запрос сервиса завершился успешно. Вместе с успешным результатом должен поступить параметр InstanceName [0..n].

Параметр InstanceName должен содержать имя объекта ObjectName одной запрашиваемой модели класса ACSI. В том случае, если ссылочный логический узел LN не содержит запрашиваемый класс ACSI, сервер должен указать, что в данном логическом узле модель класса ACSI не существует.

9.2.2.4 Параметр Response-

Параметр Response- должен указывать, что запрос сервиса завершился неуспешно. Должно вернуться сообщение об ошибке ServiceError.

9.2.3 Сервис GetAIIDataValues

9.2.3.1 Таблица параметров сервиса GetAIIDataValues

Клиент должен использовать сервис GetAIIDataValues для поиска всех значений атрибута данных DataAttribute (имеющих одинаковую функциональную связь FunctionalConstraint) всех данных DATA, ставших видимыми и, следовательно, доступными для запрашивающего клиента через ссылочный логический узел LN.

Примечание - Видимые экземпляры - это экземпляры, определяемые в рамках данного представления (более подробная информация о концепции представления приведена в разделе 7).

9.2.3.2 Параметр Request (запрос)

9.2.3.2.1 Параметр LNReference

Параметр LNReference должен содержать объектную ссылку LNRef логического узла LN.

9.2.3.2.2 Параметр FunctionalConstraint [0..1]

Параметр FunctionalConstraint должен содержать параметр функциональной связи (FC) для фильтрации соответствующих атрибутов данных DataAttributes всех данных DATA, содержащихся в данном логическом узле LN. Параметр FC должен соответствовать определению в 10.2.2.4.2.

9.2.3.3 Параметр Response+

Параметр Response+ должен указывать, что запрос сервиса завершился успешно. Вместе с успешным результатом должны поступить следующие параметры.

9.2.3.3.1 Параметр DataAttributeReference [1..n]

Параметр DataAttributeReference должен содержать объектную ссылку атрибута данных DataAttribute, содержащегося в логическом узле LN, которая должна быть направлена обратно согласно тому значению параметра FunctionalConstraint, которое было получено в запросе.

Примечание - Объектная ссылка DataAttributeReference определена в 10.2.2.4.

9.2.3.3.2 Параметр DataAttributeValue [1..n]

Параметр DataAttributeValue должен содержать значение атрибута данных (DataAttribute) данных DATA, содержащихся в ссылочном логическом узле LN. Обратно должны быть направлены только значения тех атрибутов данных, которые имеют функциональную связь, равную значению параметра FunctionalConstraint в запросе сервиса.

9.2.3.4 Параметр Response-

Параметр Response- должен указывать, что запрос сервиса завершился неуспешно. Должно вернуться сообщение об ошибке ServiceError.

      10 Модель класса DATA (данные)

      10.1 Общие сведения

Классы данных DATA предоставляют значащую информацию приложений, размещенных в устройствах автоматизации. Значения экземпляров DATA могут, например, быть записаны (SetDataValues) и считаны (GetDataValues). В МЭК 61850-7-4 определен список общих и специальных для домена подстанции (простых и комплексных) данных DATA, например Pos для положения, OilFil для фильтрации масла. Композиция данных DATA в МЭК 61850-7-4 основана на общих шаблонах (общие классы данных DATA, CDC), описанных в МЭК 61850-7-3. Концепция классов DATA вводится в данном разделе. Любой набор экземпляров DATA (или частей DATA) может быть сгруппирован для построения экземпляров набора данных DATA-SET путем использования сервиса CreateDataSet. Экземпляры DATA-SET могут, например, быть записаны (SetDataSetValues) или считаны (GetDataSetValues).

Примечание 1 - Результаты назначения значений экземплярам данных DATA не рассматриваются в настоящем стандарте. В МЭК 61850-7-3 и МЭК 61850-7-4 описано множество классов DATA, специфических для домена подстанции. Эти определения предоставляют информацию по тем действиям, которые должны быть предприняты принимающим приложением, например изменение режима DATA Mode с режима ON (включено) в режим TEST (испытание) изменяет состояние соответствующего экземпляра в тестовый режим, как это определено в МЭК 61850-7-4.

Примечание 2 - Клиент запрашивает значения DATA (DATA-SET) у сервера с помощью сервиса GetDataValues (GetDataSetValues). Сервисы для незатребованной/самопроизвольной передачи значений DATA от сервера клиенту (иногда называемые информационный отчет, системные прерывания или самопроизвольная передача) требуют особого внимания при разработке. Неуправляемая самопроизвольная передача может привести к перегрузке сети. Сервисы управляемой выдачи отчетов описаны в разделе 14.

      10.2 Определение класса DATA

10.2.1 Синтаксис класса DATA

Класс DATA является ключевым элементом в серии стандартов МЭК 61850. Рисунок 10 дает формальное описание класса DATA.

Примечание 1 - В примере на рисунке 10 использованы определения WYE (соединение "звезда"), CMV (complex measured value - комплексное измеренное значение), Vector и AnalogueValue классов общих DATA, взятые из МЭК 61850-7-3. Полное введение в моделирование DATA можно найти в МЭК 61850-7-1.

Класс DATA имеет три элемента: 1) DataName - имя; 2) Presence - указание того, являются ли данные DATA обязательными или опциональными; 3) DataAttributes - атрибуты данных.

Примечание 2 - Класс DATA является абстрактным классом, т.е. дополнительным средством создания примитивных и составных классов общих данных.

Примечание 3 - Следующие примеры, используемые в тексте, относятся к рисунку 11.

Рисунок 10 - Диаграмма классов DATA и DataAttributeType

Примечание 4 - Пример, представленный на рисунке 11, служит для объяснения класса DATA. В данном примере использованы некоторые определения из МЭК 61850-7-3. Там же приведено полное определение совместимых классов.

Рисунок 11 - Пример данных DATA

Атрибуты данных DataAttributes (например, cVal - комплексное значение) использованы для построения классов SimpleCDC (простого класса общих данных) и CompositeCDC (составного класса общих данных). Класс SimpleCDC должен иметь имя (DataName), указание (Presence) и атрибуты данных DataAttributes (например, DataName = phsA, Presence = обязательный и DataAttribute = cVal). Класс CompositeCDC состоит из одного или более классов SimpleCDC и/или атрибутов данных DataAttributes (например, CDC WYE, включающий SimpleCDC, CMV и т.п.).

Объяснение для типа DAType cм. в 5.5.1.

На рисунке 11 изображена часть экземпляра DATA (содержащегося в логическом узле MMXU1). Экземпляр логического узла с именем MMXU1 (инстанцированный из MMXU) состоит из экземпляра данных DATA фазного напряжения с именем РhV (инстанцированного из WYE). Фазное напряжение PhV состоит из напряжения фазы A phsA (инстанцированного из CMV), которое в свою очередь основано на комплексном значении cVal (типа Vector - вектор), составленном из величины напряжения mag (типа AnalogueValue - аналоговое значение), состоящего из значения с плавающей точкой f (типа FLOAT32). Атрибут данных DataAttribute дополнительно имеет функциональную связь FC = MX (измеряемое значение) и опцию пуска TrgOp = dchg (изменение данных).

Ссылки для различных уровней перечислены в нижней части рисунка. Данные DATA должны иметь структуру, определенную в таблице 16.

Таблица 16 - Определение класса DATA

Наследование и отношения между классами DATA, CompositeCDC, SimpleCDC и DAType должны соответствовать показанным на рисунке 10.

Наследование сложно представить в табличной форме. Поэтому диаграмму класса DATA на рисунке 10 следует считать нормативной. Таблицы и диаграммы класса необходимо использовать совместно.

Экземпляр класса DATA может содержать ноль или более экземпляров CompositeCDC, SimpleCDC или DataAttribute. Однако их не может не быть совсем, то есть, как минимум, один из этих элементов должен присутствовать.

Примечание 5 - Структура класса DATA рекурсивна, т.к. класс CompositeCDC также относится к типу класса DATA. Уровень рекурсии может быть ограничен отображением SCSM, так что количество уровней рекурсии составных классов общих данных CompositeCDC обычно не превышает 1.

Примечание 6 - Данные DATA или часть данных DATA могут иметь ссылки в наборе данных DATA-SET. Предполагается, что DATA будут постоянно в наличии до тех пор, пока они имеют ссылки как элементы набора данных DATA-SET. В системе должны быть предприняты специальные мероприятия по обеспечению их наличия.

10.2.2 Атрибуты класса DATA

10.2.2.1 Атрибут DataName

Атрибут DataName должен однозначно определять данные Data в пределах логического узла LN.

10.2.2.2 Атрибут DataRef - объектная ссылка данных

Атрибут DataRef должен быть уникальным именем пути данных DATA.

Объектная ссылка (ObjectReference) DataRef должна иметь следующий вид:

Примечание - Вложенность зависит от конкретного определения класса DATA.

10.2.2.3 Атрибут Presence

Атрибут Presence типа BOOLEAN должен определять, являются ли данные DATA, находящиеся в классе CompositeCDC или логическом узле, обязательными (Presence = TRUE) или опциональными (Presence = FALSE).

10.2.2.4 Атрибут DataAttribute

10.2.2.4.1 DataAttributeType - Тип DataAttribute

10.2.2.4.1.1 Общие положения

Атрибут DataAttributeType типа DAType должен описывать атрибут данных.

10.2.2.4.1.2 Синтаксис DAType

DAType должен соответствовать определению таблицы 17.

Таблица 17 - Определение DAType

Атрибут DATName - имя типа атрибута данных.

Атрибут DATName должен однозначно определять экземпляр DAType в пределах атрибута данных DataAttribute или вложенного атрибута данных DataAttribute.

Атрибут DATName (если атрибут данных не является вложенным) или DATName первого уровня (если атрибут данных является вложенным) называется DataAttributeName.

Для второго и более глубоких уровней вложенности атрибут DATName называется DAComponentName.

Объектная ссылка с верхнего уровня (LD) вниз до DataAttributeName должна называться DataAttributeReference.

Пример - Как показано на рисунке 11, cVal (производное от типа атрибута общих данных - Vector) является атрибутом данных DataAttribute. Атрибут mag (также являющийся производным от типа атрибута общих данных - AnalogueValue) является компонентом атрибута данных DataAttributeComponent.

Атрибут DATRef - объектная ссылка типа атрибута данных

Атрибут DATRef должен являться уникальным именем пути DAType. Объектная ссылка атрибута DATRef должна иметь следующий вид:

Объектная ссылка DataAttributeReference должна иметь следующий вид:

Примечание 3 - Вложенность зависит от конкретного определения класса DATA и класса DAType.

Примечание 4 - В каждом пути в пределах класса DATA имеется один и только один атрибут DataAttribute (уровень).

Атрибут Presence

Атрибут Presence типа BOOLEAN должен описывать, является ли DataAttribute обязательным (Presence = TRUE) или опциональнным (Presence = FALSE).

Атрибут CompositeComponent [0..n] - составной компонент

Атрибут CompositeComponent должен быть специализацией класса DAType.

Атрибут PrimitiveComponent [0..n] - примитивный компонент

Атрибут PrimitiveComponent должен быть специализацией класса DAType.

10.2.2.4.2 FC [0..1] - функциональная связь

С прикладной точки зрения атрибуты данных DataAttributes классифицируются в соответствии с их конкретным использованием; например, некоторые атрибуты использованы для целей управления, другие атрибуты использованы для создания отчетов и регистрации в журнале, конфигурирования, некоторые обозначают измерения или группы настроек, а некоторые определяют описание конкретного атрибута данных DataAttribute.

Функциональная связь (FC) должна быть свойством атрибута данных DataAttribute, характеризующим конкретное использование DataAttribute. Функциональная связь (FC) использована в определении данных DATA (содержащихся в логических узлах LN) и в различных блоках управления (например, BRCB). Большинству атрибутов блоков управления присуще свойство функциональной связи.

Примечание - Функциональная связь может считаться фильтром атрибутов данных DataAttributes. Классы общих данных, описанные в МЭК 61850-7-3, используют значения функциональной связи, определенные в данном подразделе.

Функциональная связь, используемая в различных определениях в настоящем стандарте, должна указывать те сервисы, с которыми разрешено работать на определенном атрибуте данных DataAttribute. Функциональные связи должны быть такими, как определено в таблице 18.

Таблица 18 - Функциональные связи (Functional constraints)

	Семантика	Разрешенные сервисы	Исходные значения/ хранение/пояснение	D	СВ
ST	Информация о состоянии	Атрибут данных DataAttribute должен представлять информацию о состоянии в значениях, которые могут быть считаны, подставлены, включены в отчет и зарегистрированы в журнале, но не могут быть записаны	Исходное значение DataAttribute должно быть взято из процесса	X
MX	Измеряемые величины (аналоговые значения)	Атрибут данных DataAttribute должен представлять информацию об измеряемой величине, значение которой может быть считано, подставлено, включено в отчет и зарегистрировано в журнале, но не может быть записано	Исходное значение DataAttribute должно быть взято из процесса	X
СО	Управление	Атрибут данных DataAttribute должен представлять информацию управления, значением которой можно оперировать (модель управления) и которое можно считывать	Не применимо	X
SP	Уставка	Атрибут данных DataAttribute должен представлять информацию уставки, значением которой можно управлять (модель управления) и которое можно считывать. Управляемые значения должны быть готовы к использованию немедленно	Исходное значение DataAttribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания	X	X
SV	Подстановка	Атрибут данных DataAttribute должен представлять информацию подстановки, значение которой можно записывать для подстановки атрибута значения и можно считывать	Если значение DataAttribute является энергозависимым, то исходное значение должно быть логическим нулем (FALSE), кроме того, это значение должно являться набором или быть сконфигурированным	X
CF	Конфигурация	Атрибут данных DataAttribute должен представлять информацию конфигурации, значение которой можно записывать и считывать. Записанные значения могут быть готовы к использованию немедленно или могут быть отсрочены по внешним причинам	Исходное значение DataAttribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания	X
DC	Описание	Атрибут данных DataAttribute должен представлять информацию описания, значение которой можно записывать и считывать	Исходное значение DataAttribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания	X
SG	Группа настроек	Логические устройства, реализующие класс SGCB, поддерживают множественные сгруппированные значения всех экземпляров атрибутов DataAttributes с функциональной связью SG. В каждой группе содержится одно значение для каждого атрибута данных с функциональной связью SG, которое должно быть текущим активным значением (подробнее см. в разделе 13). Значения DataAttributes с FC=SG не должны быть перезаписываемыми	Исходное значение DataAttribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания	X
SE	Редактируемая группа настроек	Атрибут данных DataAttribute, который может быть изменен сервисами SGCB	Значение DataAttribute должно быть доступным после выполнения сервиса SelectEditSG	X
EX	Расширенное определение	Атрибут DataAttribute должен представлять информацию по расширению, обеспечивающую ссылку на пространство имен. Расширения использованы вместе с расширенными определениями логических узлов LN, данных DATA и атрибутов данных DataAttributes (МЭК 61850-7-3 и МЭК 61850-7-4). Значения DataAttributes с FC=EX не должны быть перезаписываемыми	Значение DataAttribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания	X
BR	Буферизованный отчет	Атрибут должен представлять информацию по управлению отчетом BRCB, значение которой можно записывать и считывать	Исходное значение Attribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания		X
RP	Небуферизованный отчет	Атрибут должен представлять информацию по управлению отчетом URCB, значение которой можно записывать и считывать	Исходное значение Attribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания		X
LG	Регистрация в журнале	Атрибут должен представлять информацию по управлению журналом LCB, значение которой можно записывать и считывать	Исходное значение Attribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания		X
GO	GOOSE-управление	Атрибут должен представлять информацию по управлению GOOSE-событием GoCB, значение которой можно записывать и считывать	Исходное значение Attribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания		X
GS	GSSE-управление	Атрибут должен представлять информацию по управлению GSSE-событием GsCB, значение которой можно записывать и считывать	Исходное значение Attribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания		X
MS	Многоадресное управление выборочными значениями	Атрибут должен представлять информацию по управлению выборочным значением MSVCB, значение которой можно записывать и считывать	Исходное значение Attribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания		X
US	Одноадресное управление выборочными значениями	Атрибут должен представлять информацию по управлению выборочным значением UNICAST-SVC, значение которой можно записывать и считывать	Исходное значение Attribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания		X
XX	Представление всех атрибутов данных DataAttributes в качестве параметра сервиса	Сервис должен представлять все атрибуты данных (DataAttributes) данных DATA (любой функциональной связи FC), к которым нужен доступ, например, которые надо записать и считать. Значение FC "XX" должно использоваться только в функционально связанных данных (FCD); значение "XX" нельзя использовать как значение FC в атрибуте данных DataAttribute	"XX" должно использоваться в качестве группового символа (wildcard) только в сервисах
Примечание - Возможность записи Attribute или DataAttribute может дополнительно ограничиваться представлением или реализацией.
В графе D указано использование функциональной связи FC в определении класса данных DATA (т.е. классов общих данных DATA , описанных в МЭК 61850-7-3).   В графе СВ указано использование функциональной связи FC в определении блоков управления, приведенном в настоящем стандарте.   Зарезервировано для классов управления, описанных в настоящем стандарте.

Пример - Атрибут общих данных для класса общих данных single-point status (SPS) в соответствии с МЭК 61850-7-3 имеет следующие атрибуты данных (DataAttributes): stVal (значение состояния), q (метка качества), t (временная метка) с функциональной связью ST (информация о состоянии).

10.2.2.4.3 Атрибут TrgOp [0..n] - опция пуска

Атрибут TrgOp типа TriggerConditions (см. таблицу 10) должен определять условия пуска (связанные с атрибутом данных DataAttribute данных DATA), которые могут инициировать отправку отчета или сохранение регистрационной записи в журнале (модель отчета см. в разделе 14). Сервисы, связанные с условиями TriggerConditions, должны соответствовать таблице 19.

Таблица 19 - Опция пуска

Как показано на рисунке 12, значение атрибута данных DataAttribute, который обеспечивает специфическую опцию TrgOp (опцию пуска), должно контролироваться для выдачи отчетов и регистрации, если блок управления выдачей отчетов активизировал специфическую опцию пуска (TrgOps). В примере на верхней части рисунка 12 опция TrgOps является опцией dchg, опция TrgOp атрибута данных DataAttributes является опцией dchg для первого, опцией dupd для второго и опцией qchg для последнего атрибута данных DataAttribute. Отчеты посылаются только при изменениях данных, т.к. только опция dchg разрешена в блоке управления выдачей отчетов. Во втором примере в отчетах будет сообщаться обо всех изменениях. Кроме того, отчет будет посылаться по окончании периода сохранности.

Рисунок 12 - Взаимосвязь опций TrgOp и Reporting

Данные DATA, чьи атрибуты данных должны контролироваться для обнаружения их изменения, должны иметь ссылки в наборе данных DATA-SET.

Пример - Атрибуты общих данных, описанные в МЭК 61850-7-3, обеспечивают определенные опции пуска. Например, stVal (значение состояния) обеспечивает опцию пуска dchg; атрибут общих данных q (качество) обеспечивает опцию пуска qchg.

Примечание - Атрибуты данных набора данных DATA-SET, которые будут включены в отчет или зарегистрированы в журнале после того, как было обнаружено изменение, зависят от того, какое определение набора данных используется для выдачи отчета. Более подробная информация приведена в разделе 11.

10.2.2.4.4 Функционально связанные данные (FCD)

Ссылка упорядоченной совокупности атрибутов DataAttributes данных DATA, имеющих одинаковое значение функциональной связи (FC), называется функционально связанными данными (FCD). Построение совокупности FCD должно выполняться в порядке, соответствующем порядку появления атрибутов DataAttributes в данных DATA. Функционально связанные данные определяют как ссылку данных DataRef, сопровождаемую значением функциональной связи (FC).

Примечание - Все измеренные значения данных DATA (FC = MX) имеют ссылки в данных FCD для измерений. Функционально связанные данные использованы, например, для описания и удаленного создания наборов данных DATA-SET. Синтаксическая нотация для FCD определяется в SCSM.

Пример - На рисунке 11 данные [MX] FCD показаны во второй строке.

10.2.2.4.5 Атрибут функционально связанных данных (FCDA).

Ссылку единичного атрибута DataAttribute данных DATA, имеющих определенное значение функциональной связи (FC), называют атрибутом функционально связанных данных (FCDA).

Атрибут функционально связанных данных должен определяться как ссылка атрибута данных DataAttributeReference, дополненная определенным значением функциональной связи (FC).

Примечание - Данные FCDA ссылаются на единичное измеренное значение данных DATA (FC = MX). Атрибут функционально связанных данных используют, например, для описания и удаленного создания наборов данных DATA-SET. Синтаксическая нотация для данных FCDA определена в SCSM.

Пример - На рисунке 11 атрибут [MX] FCDA показан в пятой строке.

10.2.2.5 Атрибут CompositeCDC [0..n]

Атрибут CompositeCDC должен быть специализацией данных DATA.

10.2.2.6 Атрибут SimpleCDC [0..n]

10.2.2.6.1 Синтаксис SimpleCDC - Общие положения

Атрибут SimpleCDC должен быть специализацией данных DATA.

10.2.2.6.2 Синтаксис класса COMMON-DATA

Класс COMMON-DATA (общие данные) должен соответствовать определению таблицы 20.

Таблица 20 - Определение класса COMMON-DATA

Атрибут DataName

Атрибут DataName должен идентифицировать данные DATA в пределах логического узла LN или вложенных данных DATA.

Атрибут DataRef - Объектная ссылка данных

Атрибут DataRef должен быть уникальным именем пути данных DATA.

Объектная ссылка атрибута DataRef должна иметь следующий вид:

Примечание - Вложенность зависит от конкретного определения класса данных DATA.

Атрибут Presence

Атрибут Presence типа BOOLEAN должен описывать, являются ли данные DATA обязательными (Presence = TRUE) или опциональными (Presence = FALSE).

Атрибут DataAttribute

Атрибут DataAttribute должен соответствовать определению в 10.2.2.4.

      10.3 Отношения классов данных DATA, классов общих данных DATA и классов совместимых данных DATA

В МЭК 61850-7-3 подробно описан класс данных DATA, на основе которого определяется класс общих данных DATA. В МЭК 61850-7-4 подробно описан класс общих данных DATA, на основе которого определяется класс совместимых данных DATA. Отношения между этими стандартами представлены на рисунке 13.

Примечание - Класс общих данных DATA, описанный в МЭК 61850-7-3, вводит общие структуры (атрибуты данных DataAttributes) в класс данных DATA. Класс совместимых данных DATA, описанный в МЭК 61850-7-4, вводит специфическую семантику в специализированный класс общих данных DATA.

Рисунок 13 - Взаимосвязь классов DATA

Пример - Класс совместимых данных DATA с именем Pos представляет положение переключателя. Pos - это специализация класса общих данных DPC (двухэлементное управление). Данные DATA Pos могут быть использованы в одном или нескольких логических узлах LN.

      10.4 Сервисы класса данных DATA

10.4.1 Общие определения и описание

Для класса DATA определены следующие сервисы:

Использование этих четырех сервисов показано на рисунке 14.

Рисунок 14 - Использование сервисов класса данных

Сервисы GetDataValues и SetDataValues позволяют получить доступ ко всем данным DATA или любой их части.

10.4.2 Сервис GetDataValues

10.4.2.1 Таблица параметров сервиса GetDataValues

Клиент должен использовать сервис GetDataValues для поиска значений DataAttributes всех данных DATA, ставших видимыми и, следовательно, доступными для запрашивающего клиента через ссылочный логический узел LN.

Примечание - Видимые экземпляры - это экземпляры, определяемые в рамках данного представления (более подробная информация о концепции представления приведена в разделе 7).

10.4.2.2 Параметр Request

10.4.2.2.1 Параметр Reference

Параметр Reference должен определять функционально связанные данные (FCD) или атрибуты функционально связанных данных (FCDA) данных DATA, для которых должны быть найдены значения DataAttribute. Параметр Reference должен быть представлен в виде FCD или FCDA.

Примечание - Сервис SCSM может обеспечить доступ к ряду элементов массива ARRAY или к единичному элементу массива ARRAY.

10.4.2.3 Параметр Response+

Параметр Response+ должен указывать, что запрос сервиса завершился успешно. В случае успешного результата должен поступить следующий параметр.

10.4.2.3.1 Параметр DataAttributeValue [1..n]

Параметр DataAttributeValue должен содержать:

- значения всех атрибутов данных DataAttributes данных DATA, на которые ссылается FCD, или

- значение атрибута данных DataAttribute, на который ссылается FCDA.

Примечание - Синтаксис атрибута DataAtributeValue определяется в SCSM.

10.4.2.4 Параметр Response-

Параметр Response- должен указывать, что запрос сервиса завершился неуспешно. Должно вернуться сообщение об ошибке ServiceError.

10.4.3 Сервис SetDataValues

10.4.3.1 Таблица параметров сервиса SetDataValues

Клиент должен использовать сервис SetDataValues для задания значений атрибутов данных DataAttributes ссылочных данных DATA, ставших видимыми и, следовательно, доступными для запрашивающего клиента через ссылочный логический узел LN.

Примечание - Видимые экземпляры - это экземпляры, определяемые в рамках данного представления (более подробная информация о концепции представления приведена в разделе 7).

10.4.3.2 Параметр Request

10.4.3.2.1 Параметр Reference

Параметр Reference должен определять функционально связанные данные (FCD) или атрибуты функционально связанных данных (FCDA) данных DATA, для которых должны быть найдены значения атрибута данных DataAttribute. Параметр Reference должен быть представлен в виде FCD или FCDA.

Примечание - Сервис SCSM может обеспечить доступ к ряду элементов массива ARRAY или к единичному элементу массива ARRAY.

10.4.3.2.2 Параметр DataAttributeValue [1..n]

Параметр DataAttributeValue должен содержать:

- значения всех атрибутов данных DataAttributes данных DATA, на которые ссылается FCD, или

- значение атрибута данных DataAttribute, на который ссылается FCDA.

Примечание - Синтаксис атрибута DataAtributeValue определяется в SCSM.

10.4.3.3 Параметр Response+

Параметр Response+ должен указывать, что запрос сервиса завершился успешно.

Примечание 1 - Для сервиса SetDataValues успешный результат означает, что запрос сервиса завершился на сервере успешно и что сервер предпринял попытку переслать значение каждого атрибута данных DataAttribute данных DATA, запрошенных сервисом для соответствующего приложения.

Примечание 2 - Настоящий стандарт не описывает действия, предпринимаемые приложением, получающим значение запрошенных данных DATA.

10.4.3.4 Параметр Response-

Параметр Response- должен указывать, что запрос сервиса завершился неуспешно. Должно вернуться соответствующее сообщение об ошибке ServiceError.

10.4.4 Сервис GetDataDirectory

10.4.4.1 Таблица параметров сервиса GetDataDirectory

Клиент должен использовать сервис GetDataDirectory для поиска списка всех имен атрибута данных DataAttributeNames ссылочных данных DATA, ставших видимыми и, следовательно, доступными для запрашивающего клиента через ссылочный логический узел LN.

Примечание - Видимые экземпляры - это экземпляры, определяемые в рамках данного представления (более подробная информация о концепции представления приведена в разделе 7).

10.4.4.2 Параметр Request

Параметр DataReference - ссылка на данные

Параметр DataReference должен содержать объектную ссылку ObjectReference данных DATA. Объектная ссылка должна иметь следующий вид: DataRef.

10.4.4.3 Параметр Response+

Параметр Response+ должен указывать, что запрос сервиса завершился успешно. В случае успешного результата должен поступить следующий параметр.

Параметр DataAttributeName [1..n]

Параметр DataAttributeName должен содержать имя атрибута данных DataAttrName наивысшего уровня атрибута данных DataAttribute данных DATA.

10.4.4.4 Параметр Response-

Параметр Response- должен указывать, что запрос сервиса завершился неуспешно. Должно вернуться сообщение об ошибке ServiceError.

10.4.5 Сервис GetDataDefinition

10.4.5.1 Таблица параметров сервиса GetDataDefinition

Клиент должен использовать сервис GetDataDefinition для поиска полного списка всех определений атрибута данных DataAttribute ссылочных данных DATA, ставших видимыми и, следовательно, доступными для запрашивающего клиента через ссылочный логический узел LN.

Примечание 1 - Полный список означает, что должна быть найдена вся структура (дерево со всеми его ветвями и листьями) каждого атрибута данных DataAttribute, т.е. все вложенные атрибуты данных DataAttribute.

Примечание 2 - Видимые экземпляры - это экземпляры, определяемые в рамках данного представления (более подробная информация о концепции представления приведена в разделе 7).

10.4.5.2 Параметр Request

Параметр DataReference - объектная ссылка данных

Параметр DataReference должен содержать объектную ссылку данных DATA. Объектная ссылка должна иметь следующий вид: DataRef.

Примечание - SCSM может включать пакет из нескольких параметров объектной ссылки DataReference в одно сообщение.

10.4.5.3 Параметр Response+

Параметр DataAttributeDefinition

Параметр DataAttributeDefinition должен содержать имя атрибута данных DataAttrName и тип атрибута данных DataAttrType первого уровня и всех вложенных уровней ниже ссылочных данных DATA, a также имеющиеся функциональные связи каждого атрибута данных DataAttribute.

10.4.5.4 Параметр Response-

Параметр Response- должен указывать, что запрос сервиса завершился неуспешно. Должно вернуться сообщение об ошибке ServiceError.

      11 Модель класса DATA-SET (набор данных)

      11.1 Общие сведения

Набор данных DATA-SET - это упорядоченная группа объектных ссылок ObjectReferences данных DATA или атрибутов данных DataAttributes (называемых элементами набора данных), организованных как отдельный комплект для удобства клиента. Принадлежность и упорядоченность объектных ссылок ObjectReferences в наборе данных DATA-SET должны быть известны двум сторонам - клиенту и серверу, чтобы передавать нужно было только имя набора данных DATA-SET и текущие значения ссылочных данных DATA или атрибутов данных DataAttributes. Таким образом, эта возможность позволяет более эффективно использовать пропускную способность средств связи.

Примечание 1 - Принадлежность и упорядоченность данных DATA или атрибута данных DataAttribute в наборе данных DATA-SET могут быть найдены с помощью сервиса GetDataSetDirectory. Данные DATA и атрибут данных DataAttribute присутствуют всегда, если они указаны как элементы набора данных DATA-SET. Система должна обеспечивать их наличие специальными средствами.

Наборы данных DATA-SET также важны для моделей управления, например, выдачи отчетов, регистрации, GOOSE-модели. Наборы данных DATA-SET используют, например, для определения значений данных DATA или атрибутов данных DataAttributes, которые должны передаваться в случае изменения значения одного из элементов.

Наборы данных DATA-SET могут быть сконфигурированы или созданы с использованием сервиса CreateDataSet.

На любые данные DATA или атрибуты данных DataAttributes в сервере SERVER может ссылаться один или более наборов данных DATA-SET.

Набор данных DATA-SET может быть создан с помощью сервиса CreateDataSet как постоянный или непостоянный экземпляр набора данных DATA-SET (см. рисунок 15). Постоянный экземпляр набора данных DATA-SET должен быть видимым для клиентов любой прикладной ассоциации двух абонентов TWO-PARTY-APPLICATION-ASSOCIATION. Непостоянные экземпляры должны быть видимыми только клиенту, который создал данный экземпляр. Предопределенные (сконфигурированные) экземпляры набора данных DATA-SET должны быть видимы клиентам любой прикладной ассоциации двух абонентов TWO-PARTY-APPLICATION-ASSOCIATION, и они должны быть неудаляемыми.