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

(утв. и введен в действие Приказом Ростехрегулирования от 15.12.2009 № 848-ст)

Утвержден и введен в действие Приказом Федерального агентства

ОКС 33.200

Предисловие

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

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

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

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 15 декабря 2009 г. № 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 был определен как независимый от базовых систем связи. Специфические отображения сервиса связи <1> (SCSM) описаны в МЭК 61850-8-1, МЭК 61850-9-1 и МЭК 61850-9-2.

<1> Интерфейс 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 внешнее оборудование <1> (external equipment): Объект, выполняющий функции передачи энергии; сопряжен с системой автоматизации либо автономен от нее.

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

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

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

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

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

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

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

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

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

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

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

4 Сокращения

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

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

• спецификацию базовой модели для определения специальных информационных моделей подстанции, рассмотренных в МЭК 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 являются частью сервера.

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

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

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

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

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

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

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

1. Name — имя;

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

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

Примечание 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

Базовые типы

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 Тип EntryID (идентификатор точки входа)

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

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

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

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

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 выражения bi2** — (i + 1) секунд при i = 0...23).*

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

Примечание 2 — Разрешение временной метки может равняться 1/21 (= 0,5 с), если используется только первый бит; или же оно может быть равно 1/22 (= 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).

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

Таблица 10

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

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

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

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

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

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

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

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

Таблица 11

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 (сервер публикаций) поддерживает многоадресную прикладную ассоциацию.

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

6.2.1 Общее описание сервисов 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 (класс объекта)

6.2.2.3 Параметр 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.

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

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

У двух пользователей A и B имеются различные виртуальные представления доступа к серверу (представление 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 Определение класса TPAA

7.4.1.1 Синтаксис класса TPAA

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

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

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

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

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

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

Таблица 12

Дополнительные сервисы, которые используют прикладную ассоциацию двух абонентов TPAA, должны соответствовать таблице A.3 раздела A.4 (в колонке Asso, обозначенной «TP»).

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

7.4.1.2.1 Атрибут AssociationId

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

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

7.4.1.2.2 Атрибут AuthenticationParameter

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

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

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

7.4.2.1 Обзор

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

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+

Параметр AssociationId

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

Примечание — Параметр AssociationId может быть использован в сообщении 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 Параметр AssociationId

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

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

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

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

7.4.2.3.3.1 Параметр AssociationId

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

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 Параметр AssociationId

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

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 Определение класса MCAA

7.5.1.1 Синтаксис класса MCAA

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

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

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

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

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

Таблица 13

Определение класса MCAA

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

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

Атрибут 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).

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

Таблица 14

Определение класса LD

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 — объектная ссылка логического узла

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 должен определять блок управления небуферизованным отчетом 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 Общее описание

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 Параметр ACSIClass

Параметр ACSIClass должен содержать модель выбранного класса 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 Сервис GetAllDataValues

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

Клиент должен использовать сервис GetAllDataValues для поиска всех значений атрибута данных 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.

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

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

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

На рисунке 11 изображена часть экземпляра DATA (содержащегося в логическом узле MMXU1). Экземпляр логического узла с именем MMXU1 (инстанцированный из MMXU) состоит из экземпляра данных DATA фазного напряжения с именем PhV (инстанцированного из 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 должен являться уникальным именем пути 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] — примитивный компонент

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

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

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

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

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

D ^a

CB ^b

ST

Информация о состоянии

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

Исходное значение DataAttribute должно быть взято из процесса

X

MX

Измеряемые величины (аналоговые значения)

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

Исходное значение DataAttribute должно быть взято из процесса

X

CO

Управление

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

Не применимо

X

SP

Уставка

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

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

X

X

SV

Подстановка

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

Если значение DataAttribute является энергозависимым, то исходное значение должно быть логическим нулем (FALSE), кроме того, это значение должно являться набором или быть сконфигурированным

X

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

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

X

DC

Описание

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

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

X

SG

Группа настроек

Логические устройства, реализующие класс SGCB, поддерживают множественные сгруппированные значения всех экземпляров атрибутов DataAttributes с функциональной связью SG. В каждой группе содержится одно значение для каждого атрибута данных с функциональной связью SG, которое должно быть текущим активным значением (подробнее см. в разделе 13). Значения DataAttributes с FC=SG не должны быть перезаписываемыми

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

X

Атрибут DataAttribute должен представлять информацию по расширению, обеспечивающую ссылку на пространство имен. Расширения использованы вместе с расширенными определениями логических узлов LN, данных DATA и атрибутов данных DataAttributes (МЭК 61850-7-3 и МЭК 61850-7-4). Значения DataAttributes с FC=EX не должны быть перезаписываемыми

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

X

BR

Буферизованный отчет ^c

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

Исходное значение Attribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания

X

RP

Небуферизованный отчет ^c

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

Исходное значение Attribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания

X

LG

Регистрация в журнале ^c

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

Исходное значение Attribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания

X

GO

GOOSE-управление ^c

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

Исходное значение Attribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания

X

GS

GSSE-управление ^c

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

Исходное значение Attribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания

MS

Многоадресное управление выборочными значениями ^c

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

Исходное значение Attribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания

X

US

Одноадресное управление выборочными значениями ^c

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

Исходное значение Attribute должно быть таким, какое задано при конфигурировании; значение должно сохраняться при выключении электропитания

X

XX

Представление всех атрибутов данных DataAttributes в качестве параметра сервиса

Сервис должен представлять все атрибуты данных (DataAttributes) данных DATA (любой функциональной связи FC), к которым нужен доступ, например, которые надо записать и считать. Значение FC «XX» должно использоваться только в функционально связанных данных (FCD); значение «XX» нельзя использовать как значение FC в атрибуте данных DataAttribute

«XX» должно использоваться в качестве группового символа (wildcard) только в сервисах

Примечание — Возможность записи Attribute или DataAttribute может дополнительно ограничиваться представлением или реализацией.

^a В графе D указано использование функциональной связи FC в определении класса данных DATA (т.е. классов общих данных DATA, описанных в МЭК 61850-7-3).

^b В графе CB указано использование функциональной связи FC в определении блоков управления, приведенном в настоящем стандарте.

^c Зарезервировано для классов управления, описанных в настоящем стандарте.

Пример — Атрибут общих данных для класса общих данных 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.

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

Данные 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.

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

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

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

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

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

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

Атрибут DataName

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

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

Атрибут 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.

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

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

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

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

Рисунок 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, или

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.

Примечание — Синтаксис атрибута DataAttributeValue определяется в 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, а также имеющиеся функциональные связи каждого атрибута данных 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, и они должны быть неудаляемыми.

Рисунок 15 — Динамическое создание экземпляров набора данных

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

Непостоянный набор данных DATA-SET может быть доступен через сервисы GetDataSetValues, SetDataSetValues и GetDataSetDirectory и на него должны ссылаться только URCB и USVCB.

Примечание 2 — Локальное изменение конфигурации элементов набора данных DATA-SET может привести к критическим нарушениям в работе. Для предотвращения непреднамеренного изменения конфигурации набора данных DATA-SET система должна предпринять специальные меры (описание этих мер не относится к объекту стандартизации настоящего стандарта).

11.2 Определение класса DATA-SET

11.2.1 Синтаксис класса DATA-SET

Набор данных DATA-SET должен иметь структуру, определенную в таблице 21.

Таблица 21

Определение класса DATA-SET (DS)

11.2.2 Атрибуты класса DATA-SET

11.2.2.1 Атрибут DSName

Атрибут DSName должен однозначно определять набор данных DATA-SET в пределах логического узла LN или в рамках прикладной ассоциации двух абонентов.

11.2.2.2 Атрибут DSRef

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

Объектная ссылка DSRef должна представлять собой один из двух приведенных ниже вариантов:

11.2.2.3 Атрибут DSMemberRef [1..n] — ссылка элемента набора данных

Атрибут DSMemberRef должен определять функционально связанные данные (FCD) или атрибут функционально связанных данных (FCDA) данных DATA.

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

Примечание — Набор данных DATA-SET не включает данные DATA. Набор данных DATA-SET содержит ссылки, функционально связанные данные (FCD) или атрибут функционально связанных данных (FCDA). Набор данных DATA-SET может содержать ссылки на функционально связанные данные (FCD) или атрибут функционально связанных данных (FCDA), содержащиеся в различных логических узлах LN.

11.3 Сервисы класса DATA-SET

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

11.3.2 Сервис GetDataSetValues

11.3.2.1 Таблица параметров сервиса GetDataSetValues

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

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

11.3.2.2 Параметр Request

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

Параметр DataSetReference должен определять объектную ссылку набора данных DATA-SET. Объектная ссылка DataSetReference должна представлять собой один из двух приведенных ниже вариантов:

11.3.2.3 Параметр Response+

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

Параметр DataAttributeValue должен содержать значения элементов набора данных DATA-SET. Значение DataAttributes данных DATA может быть простым или сложным в зависимости от определения данных DATA. Для сложных типов DataAttrTypes должны быть возвращены значения всех атрибутов данных DataAttributes всех уровней вложенности.

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

11.3.2.4 Параметр Response-

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

11.3.3 Сервис SetDataSetValues

11.3.3.1 Таблица параметров сервиса SetDataSetValues

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

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

11.3.3.2 Параметр Request

11.3.3.2.1 Параметр DataSetReference — объектная ссылка набора данных

Параметр DataSetReference должен определять объектную ссылку набора данных DATA-SET. Объектная ссылка DataSetReference должна представлять собой один из двух приведенных ниже вариантов:

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

Параметр DataAttributeValue должен содержать значения элементов набора данных DATA-SET. Значение DataAttributes данных DATA может быть простым или сложным в зависимости от определения данных DATA. Для сложных типов DataAttrTypes должны быть включены значения всех DataAttributes всех уровней вложенности.

11.3.3.3 Response+

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

Примечание — Действия, выполняемые приложением, получающим значения для устанавливаемых экземпляров атрибутов данных DataAttributes, не относятся к объекту стандартизации настоящего стандарта.

Вместе с успешным результатом должен поступить параметр Result.

Параметр Result должен вернуть перечень, определенный в порядке ссылки на объект ObjectReferences данных DATA, на которые ссылается набор данных DATA-SET. Этот список должен показывать для каждого данного DATA либо подтверждение того, что сервис SetDataSetValue ссылочного экземпляра выполнен успешно, либо причину, почему сервис SetDataSetValue для ссылочных данных DATA не был выполнен.

11.3.3.4 Параметр Response-

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

11.3.4 Сервис CreateDataSet

11.3.4.1 Таблица параметров сервиса CreateDataSet

Клиент должен использовать сервис CreateDataSet для запроса сервера о создании набора данных DATA-SET со списком элементов, определяемых функционально связанными данными (FCD) или атрибутами функционально связанных данных (FCDA), ставших видимыми и, следовательно, доступными для запрашивающего клиента.

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

11.3.4.2 Параметр Request

11.3.4.2.1 Параметр DataSetReference — объектная ссылка набора данных

Параметр DataSetReference должен определять объектную ссылку набора данных DATA-SET, который должен быть создан. Объектная ссылка DataSetReference должна представлять собой один из двух приведенных ниже вариантов:

11.3.4.2.2 Параметр DSMemberRef [1..n] — объектная ссылка элемента набора данных

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

11.3.4.3 Параметр Response+

Параметр Response+ должен указывать, что запрос сервиса завершился успешно. Если одно из ссылочных функционально связанных данных (FCD) недоступно для этого клиента, сервис не должен быть выполнен.

11.3.4.4 Параметр Response-

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

11.3.5 Сервис DeleteDataSet

11.3.5.1 Таблица параметров сервиса DeleteDataSet

Клиент должен использовать сервис DeleteDataSet для запроса сервера об удалении набора данных DATA-SET, ставшего видимым и, следовательно, доступным для запрашивающего клиента.

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

11.3.5.2 Параметр Request

11.3.5.2.1 Параметр DataSetReference — объектная ссылка набора данных

Параметр DataSetReference должен определять объектную ссылку набора данных DATA-SET, который должен быть удален. Объектная ссылка DataSetReference должна представлять собой один из двух приведенных ниже вариантов:

11.3.5.3 Параметр Response+

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

11.3.5.4 Параметр Response-

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

11.3.6 Сервис GetDataSetDirectory

11.3.6.1 Таблица параметров сервиса GetDataSetDirectory

Клиент должен использовать сервис GetDataSetDirectory для поиска списка объектных ссылок всех элементов набора данных, имеющих ссылки в наборе данных DATA-SET, ставшем видимым и, следовательно, доступным для запрашивающего клиента.

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

11.3.6.2 Параметр Request

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

Параметр DataSetReference должен определять объектную ссылку набора данных DATA-SET. Объектная ссылка DataSetReference должна представлять собой один из двух приведенных ниже вариантов:

11.3.6.3 Параметр Response+

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

Параметр DSMemberRef [1..n] — объектная ссылка элемента набора данных

Параметр DSMemberRef должен содержать объектные ссылки элементов набора данных DATA-SET.

Примечание — Синтаксис параметра DSMemberRef определяется в SCSM.

11.3.6.4 Параметр Response-

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

12 Модель подстановки

Модель подстановки обеспечивает подстановку значений атрибутов данных DataAttributes, чьи функциональные связи равны MX (для аналоговых значений) или ST (для значений статуса). В основном подстановка применима к атрибутам данных DataAttributes с функциональной связью FC (= MX и ST) и к связанному атрибуту качества. Если подстановка разрешена для конкретного атрибута данных DataAttribute, то данные DATA должны представлять клиентам эти подставленные значения, а не технологическое значение.

Примечание 1 — Подставляемые значения являются частью нормальной работы подстанции и не имеют ничего общего с испытаниями системы или устройств. Испытания выполняют путем настройки логического устройства на режим испытания или настройки сервисных параметров (=Test) сервиса управления на логическую единицу TRUE.

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

Модель подстановки основана на четырех специальных атрибутах данных DataAttributes, описанных в МЭК 61850-7-3:

• subEna (активировать подстановку): Текущее значение процесса должно быть заменено значением, предоставленным атрибутом данных subVal;
• subVal, subMag и subCMag (значения для подстановки значений процесса): Текущее технологическое значение должно быть заменено значением, предоставленным атрибутом данных subVal, subMag и subCMag соответственно;
• subQ (значение для подстановки значения качества): Текущее значение процесса должно быть заменено значением, предоставленным атрибутом данных subQ;
• subID (значение для указания инициатора подстановки).

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

Рисунок 16 — Принципы подстановки

Концепция подстановки показана на рисунке 16. Обычно входные данные из процесса или результат расчетов по функциям обеспечивают значение атрибута данных DataAttribute (в этом случае источник называется «процесс»). В случае подстановки значение атрибута данных DataAttribute может быть предоставлено оператором, использующим данные клиента. Этот выбор источника значения (значение подстановки или значение процесса) должен управляться сервисом SetDataValues («xy.subEna» ) для подстановки или SetDataValues («xy.subEna» ) для отказа от подстановки. Сервис SetDataValues («xy.subVal» <значение для подстановки>) следует использовать для задания подставленного значения. Это может происходить в тех случаях, когда локальная автоматическая функция отключает подстановку, например, если блокировка обмена информацией отключена или связь больше не прерывается.

Клиент должен задать сначала те значения, которые будут заменены (xy.subVal, xy.subQ, xy.subID), а затем разрешить подстановку установкой атрибута xy.subEna в значение TRUE.

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

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

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

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

13 Модель класса SETTING-GROUP-CONTROL-BLOCK (блок управления группой настроек)

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

Экземпляр DATA обычно имеет одно значение. Модель блока управления группой настроек SETTING-GROUP-CONTROL-BLOCK (SGCB) позволяет для одного экземпляра иметь несколько значений, которые можно использовать по одному за один раз. Модель SGCB обеспечивает механизмы для переключения между несколькими значениями одного или более данных DATA. Связанные между собой значения составляют группу настроек (SG).

Примечание — Нулевой логический узел (LLN0) может иметь один блок SETTING-GROUP-CONTROL-BLOCK. В МЭК 61850-7-4 определено множество настроек данных DATA.

Модель SGCB обеспечивает сервисы для обработки различных значений для одного или более данных DATA. Группа настроек SG, значения которой в настоящее время использованы данными DATA логического узла LOGICAL-NODE, должна находиться в состоянии active (активна). Группа настроек SG, которая может редактироваться, должна находиться в состоянии edit (редактировать).

Рисунок 17 — Базовая модель модели настроек

Модель SGCB изображена в примере на рисунке 17. Логический узел LN PVOC (максимальной токовой защиты с регулированием/зависимостью по напряжению в соответствии с МЭК 61850-7-4) включает восемь данных DATA для настроек (LN PDIF имеет одно данное DATA для настроек) — MinOpTmms, ..., RstrMode. Модель SGCB SG Control обеспечивает три группы настроек SG (N 1, № 2 и № 3) — каждая с независимыми значениями для девяти данных DATA. Каждая группа настроек SG содержит девять значений — по одному на каждое данное из группы: MinOpTmms, ..., RstrMode. К элементам активной группы настроек SG можно обращаться по их объектным ссылкам данных DATA с функциональной связью SG. К элементам активной группы настроек SG в буфере редактирования (edit buffer) можно обращаться по их объектным ссылкам данных DATA с функциональной связью SE.

Значения данных DATA логического узла LN PVOC — производные от значений одной из групп настроек SG. Это выполняется мультиплексором, изображенным слева. Сервис SelectActiveSG определяет, какие значения (из групп настроек SG № 1, № 2 или № 3) должны быть скопированы в активный буфер (active buffer) и будут использоваться максимальной токовой защитой с регулированием по напряжению PVOC. В данном примере на состояние активности была настроена группа настроек SG № 1.

В группе настроек SG содержатся значения для данных DATA, расположенных в нескольких логических узлах LN. Группы настроек SG в данном примере обеспечивают значения для данных DATA в двух логических узлах LN (PDIF и PVOC).

Значения группы настроек SG № 3 могут редактироваться (сервис SelectEditSG переключил правый мультиплексор на № 3). Значения этой группы настроек SG (теперь в буфере редактирования) могут быть заданы и получены через сервисы SetSGValues и GetSGValues. После того как в буфере редактирования были заданы значения (значения группы настроек SG № 3), клиент должен подтвердить, что эти новые значения (сохраненные в буфере редактирования) будут приняты выбранной группой настроек SG (SG № 3).

Атрибуты SGCB могут быть найдены через сервис GetSGCBValues.

Данные DATA, содержащиеся в группе настроек SG, могут быть доступны непосредственно через сервис GetSGValues.

13.2 Определение класса SGCB

13.2.1 Синтаксис класса SGCB

Класс SGCB должен иметь структуру, определенную в таблице 22.

Таблица 22

Клиенты должны по наличию блока управления группой настроек SGCB определить, содержит ли логическое устройство LD группы настроек SG.

Значения атрибутов экземпляров SGCB должны конфигурироваться. Работа группы настроек показана на рисунке 18.

Рисунок 18 — Конечный автомат группы настроек

Получаемые изменения состояния определяются соответствующими атрибутами класса SGCB и соответствующими сервисами класса SGCB.

13.2.2 Атрибуты класса SGCB

13.2.2.1 Атрибут SGCBName — имя блока управления группой настроек

Атрибут SGCBName должен быть представлен как SGCB в пределах LLN0.

13.2.2.2 Атрибут SGCBRef — объектная ссылка блока управления группой настроек

Атрибут SGCBRef должен быть уникальным именем пути SGCB.

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

Примечание — SGCB — это стандартизованное имя экземпляра блока SGCB.

13.2.2.3 Атрибут NumOfSG — количество групп настроек

Атрибут NumOfSG должен определять общее количество групп настроек SG, доступных в логическом устройстве LD (LOGICAL-DEVICE).

Если в логическом устройстве LD имеются какие-либо атрибуты данных DataAttributes с функциональной связью SG, то в данном логическом устройстве должен присутствовать единственный блок управления группой настроек SGCB.

Атрибут NumOfSG не задается. Значение NumOfSG определяется локально (на месте).

13.2.2.4 Атрибут ActSG — активная группа настроек

Атрибут ActSG должен идентифицировать значения SG, которые находятся в активном буфере. Атрибут ActSG должен определять группу настроек SG, значения которой должны быть использованы соответствующим логическим узлом LN для выполнения его функции. Значения DataAttribute активной SG могут быть найдены с помощью сервиса GetSGValues.

13.2.2.5 Атрибут EditSG — редактирование группы настроек

Атрибут EditSG должен идентифицировать значения SG в буфере редактирования. Значения буфера редактирования могут быть заданы и найдены с использованием сервисов SetSGValues и GetSGValues. Первоначальные значения в группе настроек SG должны быть неизменными до тех пор, пока клиент не подтвердит запись вместо этих значений тех значений, которые хранились в буфере редактирования (атрибут ConfirmEditSGValues).

Если значение EditSG равно нулю (= 0), то использование сервисов SetSGValues (при FC=SE) и GetSGValues должно приводить к выдаче сообщения Response-.

13.2.2.6 Атрибут CnfEdit — подтвердить редактирование

Атрибут CnfEdit должен быть использован для подтверждения процесса редактирования.

13.2.2.7 Атрибут LActTm — время последней активации

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

13.3 Сервисы класса SGCB

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

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

13.3.2 Сервис SelectActiveSG

13.3.2.1 Таблица параметров сервиса SelectActiveSG

Клиент должен использовать сервис SelectActiveSG для загрузки значений заданной группы настроек SG в активный буфер.

13.3.2.2 Параметр Request

13.3.2.2.1 Параметр SGCBReference

Параметр SGCBReference должен содержать ObjectReference (объектную ссылку) LDName/LLN0.SGCB.

13.3.2.2.2 Параметр SettingGroupNumber

Параметр SettingGroupNumber должен указывать номер активной группы настроек ActSG (между 1 и NumOfSG), которая должна быть использована для определения новых значений DATA соответствующих логических узлов LN.

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

13.3.2.3 Параметр Response+

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

13.3.2.4 Параметр Response-

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

13.3.3 Сервис SelectEditSG

13.3.3.1 Таблица параметров сервиса SelectEditSG

Клиент должен использовать сервис SetEditSG для задания значения EditSG ссылочного блока SGCB, ставшего видимым и, следовательно, доступным для запрашивающего клиента через ссылочный логический узел LLN0.

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

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

13.3.3.2 Параметр Request

13.3.3.2.1 Параметр SGCBReference

Параметр SGCBReference должен содержать объектную ссылку блока управления группой настроек SGCB.

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

13.3.3.2.2 Параметр SettingGroupNumber

Параметр SettingGroupNumber должен указывать номер активной группы настроек ActSG (между 1 и NumOfSG), которая должна быть использована для задания значений (SetSGValues), подтверждения значений (ConfirmEditSGValues) и поиска значений (GetSGValues) заданной группы настроек SG.

13.3.3.3 Параметр Response+

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

13.3.3.4 Параметр Response-

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

13.3.4 Сервис SetSGValues

13.3.4.1 Таблица параметров сервиса SetSGValues

Клиент должен использовать сервис SetSGValues для задания значения DATA группы настроек SG, определяемой значением атрибута EditSG блока управления группой настроек SGCB, ставшего видимым и, следовательно, доступным для запрашивающего клиента через ссылочный логический узел LLN0.

Задание новых значений должно входить в силу только после того, как клиент подтвердил данные значения, запустив сервис ConfirmEditSGValues.

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

13.3.4.2 Параметр Request

13.3.4.2.1 Параметр Reference

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

Значение FunctionalConstraint функционально связанных данных FCD или атрибута функционально связанных данных FCDA должно быть SE.

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

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

• значения всех атрибутов данных DataAttributes данных DATA, на которые ссылается FCD, или
• значения атрибута данных DataAttribute, на который ссылается FCDA группы настроек SG, определяемой значением атрибута EditSG блока управления группой настроек SGCB.

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

13.3.4.3 Параметр Response+

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

13.3.4.4 Параметр Response-

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

13.3.5 Сервис ConfirmEditSGValues

13.3.5.1 Таблица параметров сервиса ConfirmEditSGValues

Клиент должен использовать сервис ConfirmEditSGValues для подтверждения того, что значения SG (определяемые атрибутом EditSG), заданные с использованием сервиса SetSGValues, должны быть записаны вместо старых значений SG блока управления группой настроек SGCB, ставшего видимым и, следовательно, доступным для запрашивающего клиента через ссылочный логический узел LLN0.

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

13.3.5.2 Параметр Request

Параметр SGCBReference (Ссылка на SGCB)

Параметр SGCBReference должен содержать ObjectReference (объектную ссылку) LDName/LLN0.SGCB.

13.3.5.3 Параметр Response+

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

13.3.5.4 Параметр Response-

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

13.3.6 Сервис GetSGValues

13.3.6.1 Таблица параметров сервиса GetSGValues

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

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

13.3.6.2 Параметр Request

Параметр Reference

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

Значение FC функционально связанных данных FCD или атрибута функционально связанных данных FCDA должно быть:

• SE — для поиска значений SG в буфере редактирования;
• SG — для поиска значений активной группы настроек SG.

13.3.6.3 Параметр Response+

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

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

• значения всех атрибутов данных DataAttributes данных DATA, имеющих ссылки в FCD, или
• значение атрибута данных DataAttribute, имеющего ссылку в FCDA.

Значение FC для FCD или FCDA должно быть SE или SG соответственно.

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

13.3.6.4 Параметр Response-

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

13.3.7 Сервис GetSGCBValues

13.3.7.1 Таблица параметров сервиса GetSGCBValues

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

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

13.3.7.2 Параметр Request

13.3.7.2.1 Параметр SGCBReference

Параметр SGCBReference должен содержать объектную ссылку LDName/LLN0.SGCB.

13.3.7.2.2 Параметр FunctionalConstraint

Параметр FunctionalConstraint должен содержать значение параметра функциональной связи для определения функциональной связи соответствующего атрибута блока SGCB, содержащегося в логическом узле LLN0. Это значение должно быть SP.

13.3.7.3 Параметр Response+

13.3.7.3.1 Параметр NumberOfSettingGroup — количество групп настроек

Параметр NumberOfSettingGroup должен описывать общее количество групп настроек SG атрибута NumOfSG ссылочного блока SGCB.

13.3.7.3.2 Параметр ActiveSettingGroup — активная группа настроек

Параметр ActiveSettingGroup должен определять количество групп настроек SG атрибута ActiveSG, из которых должны быть выбраны текущие активные значения SG.

13.3.7.3.3 Параметр EditSettingGroup — редактирование группы настроек

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

13.3.7.3.4 Параметр LastActivateTime — время последнего активирования группы настроек

Параметр LastActivateTime должен определять время последней активации атрибута LActTm.

13.3.7.4 Параметр Response-

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

14 Модели классов REPORT-CONTROL-BLOCK (блок управления небуферизованным отчетом) и LOG-CONTROL-BLOCK (блок управления журналом)

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

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

В противоположность устройствам широкополосного и требующего времени высокоскоростного чтения (опроса — polling) для экстраординарных случаев выдача отчетов обеспечивает немедленную передачу событий. Выдача отчетов управляется ограничениями.

Выдача отчетов и регистрация обладают следующими основными характеристиками:

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

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

Выдача отчетов и регистрация так же, как и базовые сервисы модели данных, обеспечивают гибкие схемы извлечения данных, например:

• уведомление клиентов об изменении состояния (немедленные отчеты);
• последовательность событий (поддержание последовательности отчетов или сохранение и запрос последовательностей записей журнала);
• опрос данных в любое время через сервисы GetDataValues и GetDataSetValues.

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

Примечание 2 — В разделе 16 описаны специальные сервисы для передачи измеренных значений, например от трансформатора напряжения (ТН) и трансформатора тока (ТТ), при жестких временных ограничениях.

Основные компоновочные блоки и сервисы для выдачи отчетов и регистрации представлены на рисунке 19.

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

Примечание 3 — Обработчик и монитор введены здесь только из соображений концептуальности.

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

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

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

Примечание 4 — Используя этот механизм, клиенты могут синхронизировать их базы данных с текущим состоянием логического узла.

Сервис QueryLog обеспечивает поиск набора выборочных записей журнала. Критерием выбора является определенный отрезок времени или диапазон идентификаторов записей entryIDs.

14.2 Модель класса REPORT-CONTROL-BLOCK

14.2.1 Базовые концепции

Блок управления отчетами REPORT-CONTROL-BLOCK должен управлять теми процедурами, которые требуются для выдачи отчетов со значениями данных DATA из одного или более логических узлов LN одному клиенту. Экземпляры управления отчетами должны быть сконфигурированы на сервере во время конфигурирования.

Сервер должен ограничивать доступ к какому-либо экземпляру управления отчетами, предоставляя его единовременно для одного клиента. Этот клиент должен быть исключительным владельцем этого экземпляра и должен получать отчеты от этого экземпляра управления отчетами.

Определено два класса управления отчетами с небольшим отличием в режимах работы:

• BUFFERED-REPORT-CONTROL-BLOCK (BRCB) (блок управления буферизованным отчетом) — внутренние события (вызванные опциями пуска data-change (изменение данных), quality-change (изменение качества) и data-update (обновление данных)) приводят к немедленной отправке отчетов или буферизации этих событий (до определенного целесообразного предела) для передачи таким образом, чтобы эти значения данных DATA не были утрачены из-за ограничений в управлении потоком передачи или разрыва соединения. Блок BRCB обеспечивает функциональные возможности последовательности событий (SOE);
• UNBUFFERED-REPORT-CONTROL-BLOCK (URCB) (блок управления небуферизованным отчетом) — внутренние события (вызванные опциями пуска data-change (изменение данных) quality-change (изменение качества) и data-update (обновление данных)) приводят к немедленной отправке отчетов по принципу максимальных усилий (best efforts). Если нет никакой ассоциации или поток передачи данных имеет недостаточную скорость для ее поддержки, события могут быть утрачены.

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

Для управления небуферизованным отчетом это достигается следующим образом:

a) сервер создает множественные экземпляры класса управления отчетами и обеспечивает их доступность со всеми экземплярами и видимость для всех клиентов. Имя каждого экземпляра должно быть уникальным благодаря добавленному технологическому индексу (1..n). Устройства клиентов могут быть сконфигурированы для непосредственного использования определенного экземпляра или могут просматривать экземпляры в поиске того, который не находится в работе в настоящее время и поэтому доступен для использования. Если блок UNBUFFERED-REPORT-CONTROL-BLOCK зарезервирован каким-либо клиентом, то остальные клиенты не могут задать доступ к его параметрам;

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

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

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

Средства управления буферизованным отчетом должны быть сконфигурированы. Средства управления отчетом обычно предназначены для использования клиентом, реализующим четко определенный набор функциональных возможностей, например, главным устройством SCADA-системы. Клиент может узнать объектную ссылку блока BRCB, используя конфигурацию или соглашение о присваивании имен. Видимость этих экземпляров может быть объектом управления доступом. Когда блок BRCB активирован, остальные клиенты не имеют права доступа для установки его параметров. Блок BRCB должен отключаться по явно выраженному запросу клиента.

14.2.2 Определение класса BUFFERED-REPORT-CONTROL-BLOCK (BRCB)

14.2.2.1 Синтаксис класса BRCB

Класс SGCB должен иметь структуру, определенную в таблице 23.

Таблица 23

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

14.2.2.2 Атрибут BRCBName — имя блока буферизованного управления отчетом

Атрибут BRCBName — имя BRCB, которое однозначно определяет блок BRCB в пределах логического узла LN.

14.2.2.3 Атрибут BRCBRef — объектная ссылка буферизованного управления отчетом

Атрибут BRCBRef должен являться уникальным именем пути блока BRCB.

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

14.2.2.4 Атрибут RptID — идентификатор отчета

Атрибут RptID должен быть задаваемым клиентом идентификатором отчета того блока BRCB, который вызвал выдачу отчета. Если значением идентификатора отчета BRCB является NULL, то тогда имя экземпляра (полное имя пути) BRCB должно включаться в отчет как идентификатор отчета.

Примечание — Поле идентификатора отчета может быть использовано клиентами для распознавания отчетов от различных блоков BRCB. Это значение отражается сервером.

14.2.2.5 Атрибут RptEna — разрешение выдачи отчета

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

Рисунок 20 — Конечный автомат BRCB

Отключено (disabled): BRCB доступен. Выдача отчетов выполняться не должна.

Блок BRCB должен контролировать значения атрибута данных DataAttribute, имеющего ссылку в наборе данных DATA-SET. Внутренние события, являющиеся результатом выполнения условий пуска, — изменение данных (dchg), изменение качества (qchg) и обновление данных (dupd) — должны быть буферизованы (до определенного целесообразного предела).

Клиент должен конфигурировать блок BRCB и затем установить этот атрибут в состояние активировано (enable) (см. позицию (1) на рисунке 20).

Активировано (enabled): BRCB должен выдавать отчеты для буферизованных событий и новых событий согласно тому, как задано в блоке BRCB.

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

Примечание — Сохраненные отчеты должен получать тот клиент, который активировал блок BRCB. Ограничение видимости блока BRCB только одним клиентом гарантирует, что сохраненные в буфере отчеты будут получены только одним этим клиентом.

Для того чтобы освободить блок BRCB, клиент должен установить данный атрибут в состояние отключено.

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

Для клиентов всех других ассоциаций атрибуты BRCB в состоянии активирования будут доступны только для чтения.

14.2.2.6 Атрибут DatSet — ссылка набора данных

Атрибут DatSet должен описывать объектную ссылку контролируемого набора данных DATA-SET, значения элементов которого (одного, подмножества или всех) должны включаться в отчет.

Набор данных DatSet должен быть включен в отчет, если имя набора данных в OptFlds блока управления буферизованным отчетом BRCB установлено на логическую единицу TRUE. В противном случае он не должен быть включен в отчет.

Изменение значения атрибута DatSet должно иметь такие же результаты, как и установка purgeBuf на логическую единицу TRUE.

14.2.2.7 Атрибут ConfRev — ревизия конфигурации

Атрибут ConfRev должен представлять собой подсчет количества раз, когда конфигурация набора данных DATA-SET, имеющего ссылки в DatSet, была изменена. Учитываются следующие изменения:

• любое удаление элемента DATA-SET;
• переупорядочение элементов набора данных DATA-SET.

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

Исходное значение для ConfRev не входит в предмет описания настоящего стандарта.

Значение 0 должно быть зарезервировано. При перезапуске IED-устройства это значение не должно сбрасываться.

Примечание — Изменения конфигурации наборов данных DATA-SETs при обработке сервисов не разрешены (см. модель набора данных DATA-SET). Для ConfRev во внимание принимают те изменения, которые выполняются локальными средствами, такими как конфигурация системы.

14.2.2.8 Атрибут OptFlds — опциональные поля, включаемые в отчет

Атрибут OptFlds назначает опциональные поля, специфические для клиента, которые должны включаться в отчет, выданный данным блоком BRCB. Этот атрибут определяет подмножество опциональных полей заголовка отчета (см. 14.2.3.2.2.1), которые должны быть включены в данный отчет:

• порядковый номер (если в отчете будет указано TRUE SqNum);
• временную метку отчета (если в отчете будет указано TRUE TimeOfEntry);
• причину для включения (если в отчете будет указано TRUE ReasonCode);
• имя набора данных (если в отчете будет указано TRUE DatSet);
• ссылку на данные (если в отчете будет указано TRUE DataRef или DataAttributeReference);
• переполнение буфера (если в отчете будет указано TRUE BufOvfl);
• идентификатор записи (если в отчете будет указано TRUE EntryID);
• версию конфигурации (если в отчете будет указано TRUE ConfRev).

Если блок BRCB не поддерживает одну из приведенных выше дополнительных возможностей, то при попытке установить соответствующий бит на логическую единицу (TRUE) должен прийти отрицательный ответ сервиса SetBRCBValues.

14.2.2.9 Атрибут BufTm — буферное время

Рисунок 21 — Буферное время

Атрибут BufTm (см. рисунок 21) должен определять интервал времени в миллисекундах для буферизации внутренних уведомлений, вызванных изменением данных (dchg), изменением качества (qchg), обновлением данных (dupd) блоком управления буферизованным отчетом BRCB для включения в один отчет.

По получении первого уведомления о внутреннем событии ссылочного набора данных DATA-SET блок управления BRCB должен запустить таймер длительности буферного времени. По сигналу таймера блок управления BRCB соберет в один отчет все внутренние события, которые были получены в течение этого периода времени. Следующее внутреннее событие, происшедшее после завершения периода работы таймера, должно стать сигналом для нового запуска этого таймера. Значение, по умолчанию равное 0, должно быть зарезервировано для указания того, что этот атрибут буферного времени не должен использоваться блоком управления BRCB. Каждое внутреннее событие должно приводить к выдаче одного отчета блоком управления BRCB. Значение устанавливается с приращением 1 мс и должно допускать передачу до 1 часа буферного времени.

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

В том случае, когда до истечения буферного времени BufTm было получено второе внутреннее уведомление по тому же элементу набора данных DATA-SET, блок управления буферизованным отчетом BRCB:

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

Примечание 2 — Изменения одного и того же элемента передаются в последовательных отчетах. При буферизации в блоке BRCB никакие отчеты не будут утрачены.

Если BRCB не поддерживает буферное время, то попытка установить атрибут BufTm на значение больше нуля должна приводить к выдаче отрицательного ответа сервиса SetReportControlValues.

14.2.2.10 Атрибут SqNum — порядковый номер

Атрибут SqNum должен определять порядковый номер для каждого блока управления буферизованным отчетом BRCB, в котором атрибут разрешения выдачи отчета установлен на логическую единицу TRUE. Блок управления буферизованным отчетом BRCB должен увеличивать этот номер на единицу для каждого выданного и посланного отчета. Увеличение номера происходит после того, как блок BRCB отформатировал отчет и поставил его в очередь в протокол уровня N-1. Первый отчет, следующий за установкой атрибута разрешения отчета на логическую единицу TRUE, должен содержать порядковый номер, равный 0.

14.2.2.11 Атрибут TrgOp — опции пуска

Атрибут TrgOp описывает условия пуска, которые будут контролироваться этим блоком BRCB. Определяются следующие значения:

• изменение данных (dchg);
• изменение качества (qchg);
• обновление данных (dupd);
• сохранность;
• общий опрос.

Условия пуска dchg, qchg и dupd относятся к опции пуска атрибута TrgOp атрибута данных DataAttribute классов общих данных DATA, описанных в МЭК 61850-7-3. Опции пуска сохранность и общий опрос должны быть условиями пуска, определяемыми атрибутами IntgPd и GI блока управления BRCB соответственно.

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

Если BRCB не поддерживает одну или более опций пуска, попытка установить атрибут TrgOp на логическую единицу (TRUE) для одного из этих неподдерживаемых значений должна привести к выдаче отрицательного ответа сервиса SetReportControlValues.

14.2.2.12 Атрибут IntgPd — период сохранности

Если TrgOp установлен на сохранность, атрибут IntgPd должен указывать период в миллисекундах, используемый для выдачи отчета о сохранности. Отчет о сохранности должен включать значения всех элементов соответствующего набора данных DATA-SET. Атрибут BufTm не должен действовать, если это изменение приводит к отправке отчета.

Если блок BRCB не поддерживает период сохранности, то попытка установить атрибут IntgPd на значение больше 0 должна привести к выдаче отрицательного ответа сервиса SetReportControlValues.

Значение, равное 0, должно указывать на то, что отчеты о сохранности не выдаются.

Примечание — При сканировании сохранности можно передавать те же значения, что и при общем опросе. Сканирование сохранности запускается с сервера. Общий опрос запускается клиентом.

14.2.2.13 Атрибут GI — общий опрос

Атрибут GI должен означать запрос на запуск процесса общего опроса. После установки на логическую единицу (TRUE) BRCB должен запускать процесс общего опроса. После инициации общего опроса этот атрибут должен быть автоматически установлен на логический ноль (FALSE) блоком управления буферизованным отчетом BRCB.

Если BRCB не поддерживает общий опрос (general-interrogation), то попытка установить атрибут GI на логическую единицу (TRUE) должна привести к выдаче отрицательного ответа сервиса SetReportControlValues.

14.2.2.14 PurgeBuf — очистка буфера

Атрибут PurgeBuf должен означать запрос сброса буферизованных событий. После установки на логическую единицу (TRUE) блок управления BRCB должен сбрасывать все буферизованные события, которые еще не были посланы клиенту. После сброса буферизованных событий этот атрибут должен быть автоматически установлен на логический ноль (FALSE) блоком управления буферизованным отчетом BRCB.

14.2.2.15 Атрибут EntryID — идентификатор записи

Атрибут EntryID должен представлять произвольную строку OCTET STRING, используемую для идентификации записи в последовательности событий буферизованного отчета. Значение EntryID должно быть использовано блоком управления BRCB для начала отправки следующего отчета, соответствующего этому значению EntryID, установленному в блоке BRCB.

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

После того как какая-либо ассоциация (которая была потеряна) была возобновлена клиентом, этот клиент должен присвоить EntryID значению, полученному последним. Блок управления буферизованным отчетом BRCB должен продолжить отправку отчетов со следующим значением EntryID, после того как блоку BRCB была дана возможность получить буферизованные отчеты.

Если клиент не присвоил EntryID определенному значению при активированном блоке BRCB, то блок BRCB должен использовать первое доступное значение.

14.2.2.16 Атрибут TimeOfEntry — время записи

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

14.2.3 Сервисы класса BRCB

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

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

14.2.3.2 Сервис Report

14.2.3.2.1 Таблица параметров сервиса Report

Сервис Report должен быть использован блоком управления BRCB для отправки отчетов от сервера клиенту.

Примечание — Сервис Report является сервисом без подтверждения. Он состоит только из сервисного примитива запроса. Значения DATA-SET посылаются от сервера клиенту. В SCSM этот сервис может быть подтвержден, например, на транспортном уровне.

14.2.3.2.2 Параметр Request

14.2.3.2.2.1 Синтаксис ReportFormat

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

Таблица 24

14.2.3.2.2.2 Параметр RptID — идентификатор отчета

Параметр RptID должен быть производным соответствующего атрибута в блоке BRCB.

14.2.3.2.2.3 Параметр OptFlds — опциональные поля, включаемые в отчет

Параметр OptFlds должен определять, какие из опциональных полей (sequence-number, report-time-stamp, reason-for-inclusion, data-set-name, data-reference, buffer-overflow, entryID) включаются в данный отчет.

Параметр OptFlds должен быть производным атрибута OptFlds соответствующего BRCB.

14.2.3.2.2.4 Параметр SqNum — порядковый номер

Блок управления буферизованным отчетом BRCB, атрибут разрешения отчета которого (report enable) установлен на TRUE, должен поддерживать параметр SqNum. Этот номер должен увеличиваться блоком управления BRCB для каждого отчета, выданного и посланного на базе BRCB. Это ступенчатое приращение должно выполняться сразу после того, как BRCB отформатировал отчет для передачи. Первый отчет, посылаемый после установки атрибута разрешения отчета на логическую единицу (TRUE), должен иметь порядковый номер 0. Порядковый номер должен возвращаться на 0 при достижении максимального значения.

Порядковый номер должен включаться в отчет, если опциональные поля, включенные в атрибут отчета (OptFlds) блока управления BRCB, включают порядковый номер (=TRUE); в противном случае он должен быть опущен. На рисунке 22 приведен пример выдачи отчета и порядкового номера.

Рисунок 22 — Пример отчета с использованием

14.2.3.2.2.5 Параметр SubSqNum — номер подпоследовательности

Для длинных отчетов, которые не входят в одно сообщение, один отчет должен быть разделен на подотчеты. Каждый сегмент отчета должен быть нумерован тем же порядковым номером и уникальным SubSqNum.

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

Номер подпоследовательности должен включаться в отчет, если опциональные поля для включения в атрибут отчета (OptFlds) блока управления BRCB включают порядковый номер sequence-number (=TRUE); в противном случае он должен быть опущен.

Если блок BRCB не поддерживает нумерацию подпоследовательности, то попытка установить sequence-number атрибута OptFlds на логическую единицу (TRUE) должна привести к выдаче отрицательного ответа сервиса SetBRCBValues.

14.2.3.2.2.6 Параметр MoreSegmentsFollow — наличие последующих сегментов отчета

Параметр MoreSegmentsFollow означает, что еще имеются последующие сегменты отчета с тем же порядковым номером.

14.2.3.2.2.7 Параметр DatSet — ссылка набора данных

Параметр DatSet должен быть производным соответствующего атрибута в BRCB.

14.2.3.2.2.8 Параметр BufOvl — произошло переполнение буфера

Параметр BufOvl — сигнал для клиента, что произошло переполнение буфера. Блок управления буферизованным отчетом BRCB должен включать данное поле в первый отчет, посылаемый с событиями, которые произошли после этого переполнения.

14.2.3.2.2.9 Параметр Entry

TimeOfEntry — временная метка отчета

Параметр TimeOfEntry должен определять время выдачи отчета. TimeOfEntry должен быть включен в отчет, если опциональные поля для включения атрибута (OptFlds) блока управления BRCB включают report-time-stamp (=TRUE); в противном случае он должен быть опущен.

Если блок BRCB не поддерживает параметр TimeOfEntry, то попытка установить report-time-stamp атрибута OptFlds на логическую единицу (TRUE) должна привести к выдаче отрицательного ответа сервиса SetBRCBValues.

В отчетах с одинаковым порядковым номером, но разными номерами подпоследовательности, должны быть использованы одинаковые TimeOfEntry.

EntryID — идентификатор записи

Параметр EntryID должен представлять произвольную OCTET STRING, используемую для идентификации записи в последовательности событий BRCB.

EntryData [1..n]

Параметр EntryData должен содержать ссылку данных, значение и код reasonCode каждого элемента набора данных DATA-SET, включаемого в данный отчет. Значение должно включать значение всех атрибутов данных элемента набора данных DATA-SET.

DataRef

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

Value

Параметр Value должен содержать значения DataAttribute, включенные в данный отчет.

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

BufTm = 0

При BufTm = 0 в отчет должно быть включено только значение того элемента набора данных DATA-SET, который вызвал внутреннее событие.

Пример — Атрибут данных stVal данных MyLD/XCBR1.Pos (Положение) на рисунке 23 указывается в двух различных наборах данных. На этом рисунке изображены два различных экземпляра наборов данных, которые ссылаются на атрибуты данных положения. В случае слева DATA-SET ссылается на девять отдельных элементов набора данных DATA-SET (все с функциональной связью ST): Pos.stVal — это один из девяти элементов. В случае если элемент stVal запускает изменение, в отчет должно быть включено значение именно для этого элемента. В DATA-SET в примере справа имеются только два элемента. Данное Pos (которое имеет шесть атрибутов данных: stVal, q, t, и т.п.) является одним из двух элементов. При запуске изменения в элементе Pos (например, посредством изменения в DataAttribute stVal) должно произойти включение значений всех атрибутов данных элемента Pos набора данных (т.е. полный элемент, включающий все шесть атрибутов данных stVal, q, t, и т.п.).

BufTm > 0

При (BufTm > 0) в отчет должны быть включены значения всех элементов набора данных DATA-SET, которые вызвали внутреннее событие в течение буферного времени. Имеются дополнительные ограничения; дополнительная информация по BufTm приведена в 14.2.2.9.

ReasonCode — причина включения

Причина включения должна входить в отчет, если опциональные поля, которые включаются в атрибут отчета (OptFlds) блока управления BRCB, устанавливают для причины включения значения TRUE; в противном случае она должна быть опущена. Значение для причины включения должно быть задано в соответствии с функцией TrgOp, которая привела к созданию отчета. Диапазон значений для причин включения:

• data-change (вызвано TrgOp = dchg в экземпляре данных DATA);
• quality-change (вызвано TrgOp = qchg в экземпляре данных DATA);
• data-update (вызвано TrgOp = dupd в экземпляре данных DATA);
• integrity (вызвано атрибутом IntgPd в BRCB);
• general-interrogation (вызвано установкой клиентом атрибута GI блока управления BRCB на значение TRUE).

14.2.3.2.3 Процедуры выдачи отчета

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

Рисунок 24 — Пример отчета

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

Примечание — На рисунке 24 показаны не все атрибуты и не все детали.

Предварительное условие

Блок BRCB должен быть сконфигурирован и активирован для выдачи отчетов и должен иметь установленную ассоциацию с клиентом, которому данная информация должна быть передана в виде отчета.

14.2.3.2.3.2 Data-change, quality-change и data-update (изменение данных, изменение качества и обновление данных)

Эти три опции пуска поддерживают выдачу отчетов на базе изменения или обновления в значении DataAttribute элемента набора данных DATA-SET.

data-change

Опция пуска data-change (TrgOp = dchg) относится к изменению значения DataAttribute, представляющего значение данных, относящееся к процессу. Если функция TrgOp (= dchg) установлена на логический ноль (FALSE), то при изменении данных data-change в значении этого атрибута данных DataAttribute не должен выдаваться никакой отчет.

quality-change (изменение качества)

Опция пуска quality-change (TrgOp = qchg) относится к изменению значения качества атрибута данных DataAttribute. Если функция TrgOp (= qchg) установлена на логический ноль (FALSE), то при изменении данных data-change в значении этого атрибута данных DataAttribute не должен выдаваться никакой отчет.

data-update

Опция пуска data-update (TrgOp = dupd) относится к фиксированному событию в значении DataAttribute, представляющему фиксированное значение данных (например, фиксированные счетчики), или к событию, запускаемому при обновлении значения атрибута данных DataAttribute. Если функция TrgOp (= dupd) установлена на логический ноль (FALSE), то при изменении данных data-change в значении этого DataAttribute не должен выдаваться никакой отчет.

Примечание 1 — Условие пуска по обновлению данных (data-update) может быть использовано для запуска выдачи отчета или сохранения регистрационной записи в журнале при обновлении значения DataAttribute. Обновление может означать, что это значение изменилось или было переписано, но осталось тем же. Условие пуска dupd может быть использовано в качестве триггера статистических значений, которые могут периодически рассчитываться и обновляться. Независимо от того, изменялось статистическое значение или нет, это значение должно быть включено в отчет или записано в журнале.

Примечание 2 — В описании классов общих данных, приведенном в МЭК 61850-7-3, дается определение опций пуска, относящихся к определенным атрибутам данных DataAttribute.

Если на блок BRCB поступает сообщение от внутреннего события о событии data-change, quality-change или data-update элемента ссылочного набора данных DATA-SET, значения которого должны включаться в отчет, блок BRCB должен включить это значение в отчет в соответствии с 14.2.3.2.2.9. Значение, включаемое в отчет, должно быть тем значением, которое было действительно на момент возникновения события.

Примечание 3 — В случае наличия изменений, удовлетворяющих более чем одному критерию TrgOp (например, data-change и quality-change), предпочтительно послать только один отчет.

14.2.3.2.3.3 Integrity

Опция пуска integrity поддерживает выдачу отчета о сохранности. Дополнительно для того чтобы активизировать эту опцию пуска (установить TrgOp integrity на логическую единицу (TRUE)), клиент должен задать период сохранности (IntgPd), значение которого должно быть больше 0. Если разрешена выдача отчетов о сохранности, блок BRCB должен уведомляться каждый раз при истечении заданного в опции IntgPd периода времени. При этом блок BRCB должен составить отчет со значениями всех элементов ссылочного набора данных DATA-SET. Если опция TrgOp (= integrity) установлена на логический ноль (FALSE), то никакого отчета о сохранности выдаваться не должно.

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

Новое внутреннее событие, вызванное data-change, quality-change или data-update (во время выполнения передачи отчета о сохранности), должно использовать новый порядковый номер (номер подпоследовательности должен быть начат с 0) и может пропустить оставшиеся передаваемые сегменты отчета о сохранности.

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

Новый запрос общего опроса general-interrogation (во время передачи отчета о сохранности) должен быть отсрочен до завершения выполняющейся передачи отчета о сохранности. Должен быть выдан и послан новый отчет по общему опросу с новым порядковым номером (и номером подпоследовательности, равным 0).

14.2.3.2.3.4 Общий опрос (GI)

Атрибут general interrogation (GI) должен быть использован для обозначения запроса общего опроса. После установки атрибута GI на логическую единицу (TRUE) блок управления BRCB должен начать процесс опроса и создать отчет, включающий все значения атрибута данных DataAttribute ссылочного набора данных DATA-SET. После запуска процесса опроса блок BRCB должен автоматически установить значение GI на логический ноль (FALSE). Если опция TrgOp (=general-interrogation) установлена на логический ноль (FALSE), то никакого отчета о сохранности выдаваться не должно.

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

Новый запрос общего опроса general-interrogation (во время выполнения передачи отчета по general-interrogation) должен остановить отправку оставшихся сегментов передаваемого отчета по general-interrogation. Должен быть выдан и послан новый отчет по общему опросу с новым порядковым номером (и номером подпоследовательности, начинающимся с 0).

Новое событие, вызванное временем сохранности (во время передачи отчета по general-interrogation), должно быть отсрочено до завершения выполняющейся передачи отчета по general-interrogation.

Примечание — Общий опрос запускается клиентом. Отчет о сохранности, который также передает все значения набора данных, инициируется блоком BRCB.

14.2.3.2.3.5 Порядок времени следования отчетов

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

Отчеты, выданные в результате действия опций пуска integrity или general-interrogation, содержат фиксированные копии значений всех элементов набора данных DATA-SET. Передача этих отчетов должна начинаться со следующего порядкового номера. Если все значения ссылочного набора данных не входят в один отчет, необходимо посылать несколько подотчетов с последовательной нумерацией подпоследовательности (начиная нумерацию подпоследовательности с нуля) до тех пор, пока не будут посланы все значения. Если при отправке этих отчетов или подотчетов соответственно возникнет необходимость отправки значений DATA, вызванных data-change, quality-change или data-update, это можно сделать, послав новый отчет между передачей отчетов (подотчетов) о сохранности или по общему опросу соответственно с использованием нового порядкового номера. В этом случае порядок времени следования не выполняется, но для обозначения более новых значений клиент может использовать больший порядковый номер.

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

14.2.3.2.3.6 Буферизация событий

При потере ассоциации блок BRCB должен сохранять в буфере события, основанные на опциях пуска data-change, quality-change, data-update и integrity.

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

14.2.3.3 Сервис GetBRCBValues

14.2.3.3.1 Таблица параметров сервиса GetBRCBValues

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

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

14.2.3.3.2 Параметр Request

14.2.3.3.2.1 Параметр BRCBReference

Параметр BRCBReference должен описывать объектную ссылку блока управления буферизованным отчетом BRCB.

Параметр сервиса BRCBReference должен быть BRCBRef.

14.2.3.3.2.2 Параметр FunctionalConstraint

Параметр FunctionalConstraint должен содержать значение параметра функциональной связи для фильтрации соответствующих экземпляров атрибутов BRCB.

Параметр сервиса FunctionalConstraint должен быть BR.

14.2.3.3.3 Параметр Response+

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

14.2.3.3.3.1 Параметр ReportIdentifier

Параметр ReportIdentifier должен содержать значение соответствующего атрибута RptID ссылочного блока BRCB.

14.2.3.3.3.2 Параметр ReportEnable

Параметр ReportEnable должен содержать значение соответствующего атрибута RptEna ссылочного блока BRCB.

14.2.3.3.3.3 Параметр DataSetReference

Параметр DataSetReference должен содержать значение соответствующего атрибута DatSet ссылочного блока BRCB.

14.2.3.3.3.4 Параметр ConfigurationRevision

Параметр ConfigurationRevision должен содержать значение соответствующего атрибута ConfRev ссылочного блока BRCB.

14.2.3.3.3.5 Параметр OptionalFields

Параметр OptionalFields должен содержать значение соответствующего атрибута OptFlds ссылочного блока BRCB.

14.2.3.3.3.6 Параметр BufferTime

Параметр BufferTime содержит значение соответствующего атрибута BufTm ссылочного блока BRCB.

14.2.3.3.3.7 Параметр SequenceNumber

Параметр SequenceNumber содержит значение соответствующего атрибута SqNum ссылочного блока BRCB.

14.2.3.3.3.8 Параметр TriggerOptionsEnabled

Параметр TriggerOptionsEnabled содержит значение соответствующего атрибута TrgOp ссылочного блока BRCB.

14.2.3.3.3.9 Параметр IntegrityPeriod

Параметр IntegrityPeriod содержит значение соответствующего атрибута IntgPd ссылочного блока BRCB.

14.2.3.3.3.10 GeneralInterrogation

Параметр GeneralInterrogation содержит значение соответствующего атрибута GI ссылочного блока BRCB.

14.2.3.3.3.11 Параметр EntryIdentifier

Параметр EntryIdentifier содержит значение соответствующего атрибута EntryID ссылочного блока BRCB.

14.2.3.3.4 Параметр Response-

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

14.2.3.4 Сервис SetBRCBValues

14.2.3.4.1 Таблица параметров сервиса BRCBValues

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

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

14.2.3.4.2 Параметр Request

14.2.3.4.2.1 Параметр BRCBReference

Параметр BRCBReference описывает объектную ссылку блока управления буферизованным отчетом BRCB.

Параметр сервиса BRCBReference должен быть BRCBRef.

14.2.3.4.2.2 Параметр FunctionalConstraint

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

Параметр сервиса FunctionalConstraint должен быть BR.

14.2.3.4.2.3 Параметр ReportIdentifier [0..1]

Параметр ReportIdentifier содержит значение для соответствующего атрибута RptID ссылочного блока BRCB.

14.2.3.4.2.4 Параметр ReportEnable [0..1]

Параметр ReportEnable должен содержать значение для соответствующего атрибута RptEna ссылочного блока BRCB.

14.2.3.4.2.5 Параметр DataSetReference [0..1]

Параметр DataSetReference содержит значение для соответствующего атрибута DatSet ссылочного блока BRCB.

14.2.3.4.2.6 Параметр OptionalFields [0..1]

Параметр OptionalFields содержит значение для соответствующего атрибута OptFlds ссылочного блока BRCB.

14.2.3.4.2.7 Параметр BufferTime [0..1]

Параметр BufferTime содержит значение соответствующего атрибута BufTm ссылочного блока BRCB.

14.2.3.4.2.8 Параметр TriggerOptionsEnabled [0..1]

Параметр TriggerOptions содержит значение соответствующего атрибута TrgOp ссылочного блока BRCB.

14.2.3.4.2.9 Параметр IntegrityPeriod [0..1]

Параметр IntegrityPeriod содержит значение соответствующего атрибута IntgPd ссылочного блока BRCB.

14.2.3.4.2.10 Параметр GeneralInterrogation [0..1]

Параметр GeneralInterrogation содержит значение для соответствующего атрибута GI ссылочного блока BRCB.

14.2.3.4.2.11 Параметр PurgeBuffer [0..1]

Параметр PurgeBuffer содержит значение соответствующего атрибута PurgeBuf ссылочного блока BRCB.

14.2.3.4.2.12 Параметр EntryIdentifier

Параметр EntryIdentifier содержит значение соответствующего атрибута EntryID ссылочного блока BRCB.

14.2.3.4.3 Параметр Response+

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

14.2.3.4.4 Параметр Response-

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

Данный сервис должен прислать ответное сообщение об ошибке, если сервис был вызван для любого атрибута блока BRCB, кроме установки RptEna на логический ноль (FALSE) при активированном блоке BRCB.

14.2.4 Определение класса UNBUFFERED-REPORT-CONTROL-BLOCK (URCB)

14.2.4.1 Синтаксис класса URCB

Класс URCB должен иметь структуру, определенную в таблице 25.

Таблица 25

Все атрибуты, кроме URCBName, URCBRef, RptEna и Resv, должны соответствовать определениям, приведенным для блока BRCB в 14.2.2.

14.2.4.2 Атрибут URCBName — имя управления небуферизованным отчетом

Атрибут URCBName должен быть именем URCB, которое однозначно определяет URCB в пределах логического узла LOGICAL-NODE.

14.2.4.3 Атрибут URCBRef — объектная ссылка управления небуферизованным отчетом

Атрибут URCBRef является уникальным именем пути блока URCB.

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

14.2.4.4 Атрибут RptEna — разрешение выдачи отчета

Атрибут RptEna (если он установлен на логическую единицу (TRUE)) должен указывать на то, что блок URCB в настоящее время активирован на выдачу отчетов со значениями набора данных DATA-SET. Если он установлен на логическую единицу (TRUE), то блок управления небуферизованным отчетом URCB должен контролировать эталонное значение набора данных DATA-SET и выдавать отчеты, как определено в блоке URCB. Если он установлен на логический ноль (FALSE), блок URCB должен прекратить выдачу отчетов.

В то время, когда атрибут установлен на значение TRUE (выдача отчетов разрешена), не разрешается вносить никакие изменения в значения атрибутов блока URCB, кроме отключения и активирования опций пуска общего опроса.

Если прикладная ассоциация двух абонентов TPAA с клиентом, через которую был активирован блок URCB, утрачена, сервер должен установить атрибут RptEna на логический ноль (FALSE).

14.2.4.5 Атрибут Resv — резервирование блока URCB

Атрибут Resv (если он установлен на TRUE) указывает, что блок URCB в настоящее время зарезервирован исключительно для того клиента, который установил значение на логическую единицу (TRUE). Другим клиентам должно быть запрещено задавать какие-либо атрибуты этого блока URCB.

Если атрибут Resv не установлен на TRUE, то установка атрибута RptEna на логическую единицу (TRUE) подразумевает, что данный экземпляр резервируется.

Примечание — Атрибут Resv выполняет функцию семафора для конфигурации, активируя и отключая блок управления небуферизованным отчетом URCB.

14.2.5 Сервисы класса URCB

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

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

14.2.5.2 Сервис Report

Сервис Report должен соответствовать описанию, приведенному для блока BRCB в 14.2.3.2, за исключением того, что не должен быть доступен параметр BufOvfl формата отчета.

14.2.5.3 Сервис GetURCBValues

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

Этот сервис должен соответствовать описанию в 14.2.3.3, за исключением того, что параметр BRCBReference должен называться URCBReference, параметр PurgeBuffer должен быть недоступен, а параметр functional constraint должен иметь значение RP.

14.2.5.4 Сервис SetURCBValues

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

Этот сервис должен соответствовать описанию в 14.2.3.4, за исключением того, что параметр BRCBReference должен называться URCBReference, параметр PurgeBuffer должен быть недоступен, а параметр functional constraint должен иметь значение RP.

14.3 Модель класса LOG-CONTROL-BLOCK (блок управления журналом)

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

14.3.1.1 Базовые концепции

Требование о наличии внутреннего запоминающего устройства хранения значений ретроспективных данных и поиска в системах связи относится ко многим IED-устройствам. Эти значения данных подпадают под две общие категории: периодические регистрационные данные (как правило, называемые в измерительных задачах профилями) и инициированные событием данные или «последовательность событий» (SOE). Для того чтобы отличать требования по регистрации ретроспективных данных от передачи отчетной информации, используют несколько критериев.

• Регистрация данных должна быть независимой от внешних прикладных ассоциаций или других коммуникационных транзакций. Даже при потере связи ретроспективные события будут происходить и должны регистрироваться.
• Процесс сохранения ретроспективных записей является полностью асинхронным с поиском в системах связи.
• Скорость создания ретроспективных записей может в некоторых случаях быть намного выше, чем возможности коммуникационных процессов по выдаче отчетов со значениями во внешнюю базу данных.
• Поиск записей должен позволить внешним приложениям запрашивать подмножества всей базы ретроспективных данных в целях сохранения внешней полной по времени или по последовательности событий ретроспективной записи.
• Источник данных может быть внешним по отношению к устройству. Таким образом, хранилище ретроспективных данных может быть просто центральным пунктом памяти.
• Записи имеют относительную важность по времени или упорядочению и могут требовать присвоения порядкового номера.

На рисунке 25 дано общее описание классов LOG и LCB. Один журнал LOG может управляться несколькими блоками управления журналом LCB.

14.3.1.2 Концепция буфера журнала

С точки зрения реализации журнал LOG может рассматриваться как кольцевой буфер, который перезаписывает самые старшие значения в журнал LOG. Однако клиент этого не видит. С точки зрения клиента, журнал LOG — это линейный буфер, в котором записи в журнале LOG идентифицируются по:

• EntryID (уникальному идентификатору записи журнала LOG entry);
• TimeOfEntry (моменту времени, когда данная запись LOG entry была добавлена в журнал LOG).

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

Клиент может запрашивать журнал LOG по атрибуту EntryID или по атрибуту TimeOfEntry.

14.3.2 Определение класса LCB

14.3.2.1 Синтаксис класса LCB

Блок LCB управляет процедурами, требующимися для сохранения значений атрибута данных DA (записи журнала) в журнале LOG. Каждый активированный блок LCB должен ассоциировать набор данных DATA-SET с журналом LOG. Изменения в значении элемента DATA-SET будут сохраняться как запись журнала (LOG entry). Несколько блоков управления LCB позволяют использовать несколько наборов данных DATA-SET для заполнения журнала LOG.

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

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

Блок LCB должен иметь структуру, показанную в таблице 26.

Таблица 26