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

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

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

ЧАСТЬ 7

Предисловие

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

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

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

Введение

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

• Часть 1. Введение и краткий обзор;
• Часть 2. Словарь терминов;

• Часть 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. Проверка соответствия.

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

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

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

В настоящем стандарте описана связь между различными частями серии стандартов МЭК 61850. Приведено описание того, как может быть достигнуто взаимодействие.

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

Таблица 1

Руководство для пользователей

Настоящий стандарт предназначен для всех, кто заинтересован в стандартизированной связи и стандартизированных системах в электроэнергетике. В настоящем стандарте представлены обзор и введение в МЭК 61850-7-4, МЭК 61850-7-2, МЭК 61850-6 [1] и МЭК 61850-8-1 [2].

В таблице 1 различным заинтересованным сторонам в упрощенном виде даны рекомендации относительно необходимости ознакомления с частями серии стандартов МЭК 61850. Представлены четыре группы: предприятие электротехнической промышленности, поставщик, различные консультационные и другие организации.

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

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

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

3.3 модель (model): Отображение некоторых составляющих реальности.

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

4 Сокращения

LN — логический узел;

LLN0 — нуль логического узла (0);

LPHD — физическое устройство логического узла;

MMS — спецификация производственных сообщений;

PHD — физическое устройство;

PICOM — единица передаваемой информации;

SCSM — специфическое отображение сервиса связи;

SoE — последовательность событий;

UML — универсальный язык моделирования;

VMD — виртуальное производственное устройство (Virtual Manufacturing Device);

VT — трансформатор напряжения;

XML — расширенный язык разметки.

5 Обзор концепции серии стандартов МЭК 61850

5.1 Цель

Стандарты МЭК 61850-7-4, МЭК 61850-7-3, МЭК 61850-7-2, МЭК 61850-6 [1] и МЭК 61850-8-1 [2] тесно связаны между собой. В настоящем подразделе приведен обзор указанных частей, а также описано, каким образом они пересекаются.

В каждой части определен конкретный аспект IED-устройств подстанции:

• В МЭК 61850-7-4 описаны конкретные информационные модели функций автоматизации подстанции (например, выключатель с состоянием положения выключателя, уставки функции защиты и т.д.) — то, что смоделировано и могло бы быть передано.
• В МЭК 61850-7-3 приведен перечень широко используемой информации (например, двухэлементные команды управления, значение трехфазной измеряемой величины и т.д.) — то, что представляет собой общую базовую информацию.
• В МЭК 61850-7-2 описаны сервисы обмена информацией для функций различных типов, например control (управление), report (выдача отчета), get (получение), set (настройка) и т.д.
• В МЭК 61850-6 [1] приведено формальное описание конфигурации IED-устройства подстанции, включая описание его взаимосвязи с другими IED-устройствами и с работой первичного оборудования (однолинейная схема) — как описывать данную конфигурацию.
• В МЭК 61850-8-1 [2] описаны конкретные средства передачи информации между IED-устройствами (например, прикладной уровень, кодирование и т.д.) — как упорядочивать информацию при обмене.

5.2 Топология и функции связи систем автоматизации подстанций

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

• получения значений выборок от трансформаторов тока CT и трансформаторов напряжения VT (1);
• скоростного обмена входными/выходными данными по защите и управлению (2);
• передачи сигналов управления и отключения (3);
• проектирования, разработки и конфигурирования (4);
• контроля и надзора (5);
• связи с центром управления (6);
• временной синхронизации;

- и т.д.

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

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

Рисунок 1 — Пример топологии автоматизации подстанции

5.3 Информационные модели систем автоматизации подстанций

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

Примечание 1 — Термин «общая информация» применительно к серии стандартов МЭК 61850 означает, что стороны, имеющие отношение к системам автоматизации подстанций (пользователи и производители), согласились с тем, что данная информация, описанная в серии стандартов МЭК 61850, общепринята и необходима для открытого обмена информацией между любыми типами IED-устройств подстанций.

Рисунок 2 — Модельный подход (концептуальное представление)

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

Как описано в МЭК 61850-5, подход, принятый в настоящем стандарте, заключается в разложении прикладных функций на наименьшие сущности, используемые для обмена информацией. Степень детализации зависит от обоснованного распределения размещения этих сущностей в выделенных устройствах (IED-устройствах). Эти сущности называются логическим узлами (например, виртуальное представление класса «выключатель» со стандартизованным именем класса XCBR). Моделирование и описание логических узлов осуществляются исходя из концептуальной прикладной точки зрения, изложенной в МЭК 61850-5. Несколько логических узлов составляют логическое устройство (например, представление элемента присоединения). Логическое устройство всегда реализуется в одном IED-устройстве; следовательно, логические устройства не являются распределенными.

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

Примечание 2 — Логические узлы в этом примере могут быть реализованы в одном или нескольких IED-устройствах в зависимости от того, что именно необходимо. Если эти логические узлы реализованы в различных IED-устройствах, они должны обмениваться информацией по сети. Обмен информацией внутри логического узла выходит за рамки областей применения серии стандартов МЭК 61850.

В зависимости от функциональных возможностей логический узел содержит перечень данных (например, положение) с соответствующими атрибутами данных. Эти данные имеют некую структуру и четко определенную семантику (значение в контексте систем автоматизации подстанций). Информация, представленная этими данными и их атрибутами, обменивается с помощью сервисов в соответствии с четко определенными правилами и требуемыми рабочими характеристиками, как описано в МЭК 61850-5. Эти сервисы реализуются специальными и конкретными средствами обмена информацией (SCSM с использованием, например, MMS, TCP/IP и Ethernet).

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

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

5.4 Приложения, моделируемые логическими узлами, описанными в МЭК 61850-7-4

Таблица 2 содержит перечень всех групп логических узлов, описанных в МЭК 61850-7-4. Приведены определения более 90 логических узлов, представляющих наиболее распространенные задачи оборудования подстанции и фидеров. Основное внимание сконцентрировано на определении информационных моделей для задач защиты, а также задач, связанных с защитой (38 логических узлов из 88). Эти две группы включают в себя почти половину всех логических узлов. Данное представление — это результат наиболее узкоспециализированного исторически сложившегося определения функций защиты вследствие высокой важности защиты для безопасной и надежной работы энергосистемы.

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

Таблица 2

Группы логических узлов LN

Важность функций контроля возрастает.

В серии стандартов МЭК 61850 приведены четко определенные правила описания дополнительных логических узлов и данных, например для дополнительных функций в пределах подстанций или для других областей применения, таких как ветровые электростанции. Более подробно правила расширения представлены в разделе 14 настоящего стандарта и в приложении А МЭК 61850-7-4.

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

• защита от понижения напряжения;
• направленная защита от перегрузки;
• вольтгерцовое реле;

- перемежающееся замыкание на землю;

- направленный элемент;

- ограничение гармоник;

• схема защиты;
• защита от нулевой или пониженной частоты вращения;
• ...;
• измерение;
• учет электроэнергии;

• ...;
• управление переключениями;
• выключатель;
• прерыватель цепи;
• ...

Большинство логических узлов предоставляют информацию, которая может быть подразделена на категории, как это изображено на рисунке 3. Семантика логического узла представляется данными и атрибутами данных. Логические узлы могут предоставлять от нескольких до 30 данных. Данные могут содержать от нескольких до 20 (или даже более) атрибутов данных. Логические узлы могут содержать более 100 отдельных объектов информации (точек), организованных в иерархическую структуру.

Рисунок 3 — Категории информации логического узла, лист 1

Рисунок 3, лист 2

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

Рисунок 4 — Принцип построения устройств, лист 1

5.5 Семантика, привязанная к данным

Среднее число конкретных данных, обеспеченных логическими узлами, которые описаны в МЭК 61850-7-4, приблизительно равно 20. Каждое из этих данных (например, положение выключателя) включает в себя несколько более детальных определений (атрибуты данных). Положение выключателя (именуемое Pos) описано в логическом узле XCBR (рисунок 5). Это положение описано как данные. Категория положения в логическом узле — это «объект управления» — положением можно управлять через сервис управления.

Рисунок 5, лист 2

Положение Pos — это более чем «точка» в значении простых протоколов RTU. Оно состоит из нескольких атрибутов данных. Эти атрибуты данных распределяются по категориям следующим образом:

• управление (состояние, значения измерений/учета или настройки);
• подстановка;
• конфигурация, описание и расширение.

Экземпляр данных Pos имеет примерно 20 атрибутов данных. Атрибут данных Pos.ctlVal представляет управляемую информацию [она может быть задана в состояниях ON (ВКЛ.) или OFF (ВЫКЛ.)]. Атрибут данных Pos.stVal представляет положение реального выключателя (он может находиться в промежуточном состоянии, быть выключен, включен или неисправен).

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

Текущие значения для stVal, показатель качества и временная метка (связанные с stVal) могут быть считаны, записаны в отчет или зарегистрированы в журнале в буфере IED-устройства.

Значения stVal и показатель качества могут быть подставлены дистанционно. Подставленные значения вступают в силу немедленно после выполнения подстановки.

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

Атрибуты данных описываются в первую очередь именем атрибута и типом атрибута:

Дополнительная информация содержит дополнительные подробности (содержит метаданные):

• по разрешенным сервисам: функциональной связи FC = CO означает, что могут быть применены только конкретные сервисы (например, CO относится только к сервису управления);
• по условиям инициирования выдачи отчета: TrgOp = dchg означает, что выдача отчета начинается при изменении значения данного атрибута;

Информация о положении Pos, как показано на рисунке 5, имеет много атрибутов данных, которые могут быть найдены во многих других приложениях, связанных с переключениями. Первая характеристика положения — это атрибут элемента данных stVal (значение состояния), который представляет четыре состояния: промежуточное состояние | выкл. | вкл. | неисправен. Эти четыре состояния (как правило, представляемые двумя битами) общеизвестны как «двухэлементная» информация. Полный набор всех атрибутов данных, определенный для данных Pos (положение), называется «класс общих данных» (CDC). Имя класса общих данных двухэлементной информации — DPC (управляемая двухэлементная).

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

МЭК 61850-7-3 определяет классы общих данных для широкого диапазона хорошо известных приложений. Основные классы общих данных подразделены на следующие группы:

• информация об управляемом аналоговом значении;
• настройки состояния;
• настройки аналогового значения;
• описательная информация.

5.6 Сервисы обмена информацией

Логические узлы, данные и атрибуты данных в основном должны быть определены для того, чтобы установить, какая информация требуется для выполнения задачи, а также для обмена информацией между IED-устройствами. Обмен информацией определяется посредством сервисов. На рисунке 6 приведена выборка сервисов.

NOTE — The circles with the numbers to refer to the bulleted list below.

Примечание — Номера в кружочках (от до ) относятся к нижеприведенному списку.

Рисунок 6 — Выборка сервисов

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

Категории сервисов (описанные в МЭК 61850-7-2) следующие:

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

Многие сервисы работают непосредственно с использованием атрибутов информационной модели (т.е. с использованием атрибутов данных, содержащихся в логических узлах). Конфигурация импульса атрибута данных Pos отдельного выключателя может быть настроена на новое значение непосредственно клиентом. «Непосредственно» означает, что данный сервис работает по запросу клиента без особых ограничений IED-устройства.

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

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

5.7 Сервисы, отображаемые в конкретных информационных протоколах

Сервисы, описанные в МЭК 61850-7-2, называются абстрактными сервисами. «Абстрактный» означает, что в МЭК 61850-7-2 представлены только те свойства, которые требуются для описания необходимых действий на стороне приема запроса на обслуживание. Они основываются на функциональных требованиях МЭК 61850-5. В МЭК 61850-7-2 определена семантика моделей сервиса с их атрибутами и семантика тех сервисов, которые работают с использованием этих атрибутов (включая те параметры, которые несут запросы и ответные реакции).

Специфический синтаксис (формат) и, в особенности, кодирование сообщений, которые несут сервисные параметры какого-либо сервиса, и то, как они проходят через сеть, определяются в специфическом отображении сервиса связи (SCSM). Один вид отображения SCSM — МЭК 61850-8-1 [2] - это отображение сервисов на MMS (ИСО 9506 [6], [7]) и другие виды передачи, такие как TCP/IP и Ethernet (см. рисунок 7); другие виды отображения — МЭК 61850-9-1 [3] и МЭК 61850-9-2 [4].

5.8 Конфигурация подстанции

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

В МЭК 61850-6 [1] определен язык описания конфигураций IED-устройств электрических подстанций. Этот язык называется языком описания конфигурации подстанции (Substation Configuration Description Language, SCL-язык).

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

• заранее конфигурированных IED-устройств с фиксированным числом логических узлов, основанных на библиотеке функций, но не привязанных ни к какому отдельному процессу;
• заранее конфигурированных IED-устройств с заранее конфигурированной семантикой для части процесса определенной структуры, например линий, присоединенных к двойной системе шин элегазового распределительного устройства (РУ);
• при полном конфигурировании процесса со всеми IED-устройствами, привязанными к индивидуальным функциям процесса и к основному оборудованию, которое расширено определениями доступа к объектам управления (разрешения доступа) для всех возможных партнеров по связи;
• готовых к работе IED-устройств совместно со всеми каналами связи, готовыми к работе. Это необходимо в том случае, если IED-устройство не может динамически открывать соединения.

Язык конфигурации создан на базе XML-языка.

5.9 Заключение

На рисунке 8 представлена резюмирующая информация по разделу 5. Четыре основных компоновочных блока включают в себя:

Указанные четыре компоновочных блока в большой степени независимы друг от друга. Данные информационные модели легко могут быть расширены путем определения новых логических узлов и новых данных в соответствии с особыми гибкими правилами — как это требуется в другой области применения. Таким же образом стеки связи могут обмениваться в соответствии с современными достижениями в технологии связи. Но для сохранения простоты взаимодействия в данный момент времени должен быть выбран только один стек. Описание такого выбора приведено в МЭК 61950-8-1 [2], МЭК 61850-9-1 [3] и МЭК 60850-9-2 [4].

Информация должна быть отделена от представления и от сервисов обмена информацией.

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

В разделе 6 приведен более подробный обзор всех четырех компоновочных блоков.

6 Подход к моделированию в серии стандартов МЭК 61850

6.1 Декомпозиция прикладных функций и информации

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

В зависимости от своих функциональных возможностей эти логические узлы содержат данные с назначенными атрибутами данных. Информация, представленная данными и атрибутами данных, обменивается назначенными сервисами в соответствии с четко определенными правилами и рабочими характеристиками, запрашиваемыми, как это требуется в МЭК 61850-5.

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

Рисунок 9 — Процесс декомпозиции и композиции (концептуальное представление), лист 1

Рисунок 9, лист 2

Небольшая часть функции (выборка модели выключателя) была выбрана в качестве примера для пояснения процесса декомпозиции. Выключатель обладает, помимо многих других атрибутов, при необходимости управляемым и контролируемым положением, а также возможностью предотвратить отключение выключателя (например, в целях блокировки, запрета размыкания). Данные «положение» включают в себя некоторую информацию, которая представляет значение состояния (вкл., выкл., промежуточное, неисправность), качество значения (хорошо и т.д.) и метку времени последнего изменения положения. Положение предоставляет также возможность управления выключателем: управляющее значение (вкл., выкл.). С целью отследить, кто выполнил управление выключателем, источник сообщения сохраняет информацию о той сущности, которая выдала последнюю команду управления. Контрольный номер сохраняет порядковый номер последней команды управления.

Информация, сгруппированная в данных «положение» (состояние, управление и т.д.), представляет очень широко распространенную группу с четырьмя значениями, которая может быть использована многократно. Подобно этому Block to open («Блокировка отключения») группирует информацию с двумя значениями. Эти группы называются классами общих данных (CDC):

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

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

В МЭК 61850-3 описаны приблизительно 30 классов общих данных для состояния, измеряемых величин, управляемого состояния, управляемого аналога, установки состояния и установки аналогового значения.

6.2 Создание информационных моделей методом ступенчатой композиции

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

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

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

На следующем этапе классы общих данных используются для определения классов данных, характерных для описания подстанции (см. нижнюю половину рисунка 9). Эти классы данных (определенные в МЭК 61850-7-4) относятся к специализированным классам общих данных, например, класс данных Pos (специализация DPC) наследует все атрибуты данных соответствующего класса общих данных DPC, т.е. ctlVal, origin, ctlNum и т.д. Семантика класса Pos определена в МЭК 61850-7-4.

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

В МЭК 61850-7-4 определяются приблизительно 90 логических узлов, использующих около 450 классов данных. Логический узел XCBR включает в себя приблизительно 20 классов данных. Краткое описание логического узла XCBR приведено в таблице 3.

Таблица 3

Класс логического узла XCBR (концептуальное представление)

Примечание — В МЭК 61850-7-4 определены стандартизованные имена для каждого элемента, такие как Pos для положения переключателя. Также в таблицах для логических узлов приведен класс общих данных, используемый для соответствующего класса данных. Наконец, в этих таблицах определено, относится ли класс данных в таблице к обязательному или опциональному. Подробнее этот вопрос разъяснен ниже в настоящем стандарте.

Содержимое выделенного «положения переключателя» (имя = Pos) приведено на рисунке 10.

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

Рисунок 10 — Информация XCBR1 в виде дерева

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

Экземпляр XCBR1 (первый экземпляр XCBR) представляет собой корень на уровне логических узлов. Объектная ссылка XCBR1 относится ко всему нижнему дереву. XCBR1 содержит данные, например Pos и Mode. Данные Pos (положение) четко определены в МЭК 61850-7-4 (см. выдержку описания).

Описание данных

Содержимое положения Pos — это список, состоящий приблизительно из 20 атрибутов данных. Эти атрибуты являются производными класса общих данных DPC (двухэлементное управление). Атрибуты данных, определенные в DPC, частично обязательные, остальные — опциональные. Объектом данных наследуются только те атрибуты данных, которые необходимы для некоего конкретного приложения. Например, если для данных «положение» необходимость в поддержке подстановки отсутствует, то в объекте данных Pos атрибуты данных subEna, subVal, subQ и subID не требуются.

Сервисы обмена информацией, которые имеют доступ к атрибутам данных, используют иерархическое дерево. Управляемый атрибут данных определяется с помощью XCBR1.Pos.ctlVal. Сервис управления работает именно с использованием этого управляемого атрибута данных выключателя. Информация состояния может быть упомянута как член (XCBR1.Pos.stVal) набора данных, называемый AlarmXCBR. На этот набор данных может ссылаться блок управления отчетами с именем Alarm. Блок управления отчетами может быть конфигурирован для посылки отчета на определенный компьютер при каждом изменении состояния выключателя (с отключенного на включенное или с включенного на отключенное).

6.3 Пример создания IED-устройства

Рисунок 11 — Пример композиции IED-устройства

В вариантах 2 и 3 IED-устройство, которое служит хостом для LN-узлов XCBR, может быть интегрировано в реальное устройство — выключатель или соединено с ним проводами, как в варианте 1, но это уже выходит за область применения серии стандартов МЭК 61850. Физический выключатель для системы автоматизации подстанции представлен, в соответствии с серией стандартов МЭК 61850, LN-узлами XCBR.

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

6.4 Модели обмена информацией

6.4.1 Введение

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

• модель выхода;

• модель для оперативного управления и самоописания.

Для каждой модели определено несколько сервисов. Эти сервисы работают с данными, атрибутами данных и другими атрибутами, как правило, содержащимися в логических узлах. Номера в кружках на рисунке 12 соответствуют номерам в 6.4.2 и на рисунках 13, 14, 15, 17, 19 и 21, где приведено их описание.

Примечание 1 — В реальности сервисы работают с экземплярами данных. Для удобства пользователей термин «экземпляр» в настоящем стандарте в большинстве случаев опущен.

Примечание — Номера в кружках на данном рисунке соответствуют номерам в 6.4.2 и на рисунках 13, 14, 15, 17, 19 и 21, как ссылки на описание.

Рисунок 12, лист 2

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

Примечание 2 — Термины «вход» и «выход» относятся к направлению от IED-устройства в процесс (выход) и из процесса в IED-устройство (вход).

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

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

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

6.4.2 Модель выхода

6.4.2.1 Концепция модели управления

Концепция модели управления изображена на рисунке 13. Она показана на примере логического узла выключателя (XCBR) с атрибутом данных XCBR.Pos.ctlVal (показанным на рисунке 14). Перед тем как запрос сервиса управления изменит положение реального устройства, должны быть выполнены некоторые условия, например выходной сигнал может быть выдан только в том случае, если переключатель «локальное/удаленное управление» находится в положении remote («удаленное»), а узел блокировки (CILO) разрешил данную операцию. Условия, которые должны быть выполнены, могут включать в себя:

- положение переключателя «локальное/удаленное управление» выключателя XCBR.Loc;

• информацию о режиме выключателя XCBR.Mod;
• проверку устройства;
• другие атрибуты управляемых данных, например блокировка, конфигурирование импульса, модель управления, класс sbo, тайм-аут sbo, как это определено в классе общих данных DPC (двухэлементное управление в МЭК 61850-7-3).

Рисунок 13, лист 2

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

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

Рисунок 14 — Модель выхода (этап 2) (концептуальное представление)

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

6.4.2.2 Концепция модели GSE

Общее событие на подстанции (GSE — GOOSE и GSSE) обеспечивает одноранговый обмен информацией между значениями данных входа одного IED-устройства с данными выхода многих других IED-устройств (многоадресный обмен). GOOSE и GSSE сообщения, полученные IED-устройством, могут быть использованы также, чтобы рассчитать данные для внутренних целей. Например, для внутренних целей полученные значения положения переключателя позволяют рассчитать локально условия блокировки.

Примечание 1 — Значения данных GOOSE и GSSE определены в модели входа, описанной в 6.4.3.

Рисунок 15 — Модель выхода GSE (концептуальное представление)

Перед тем как использовать какие-либо значения в качестве сигналов выхода, таких как блокировка, должны быть выполнены условия и проведены проверки, частично описанные в серии стандартов МЭК 61850, а частично определяемые локальным приложением, выходящим за область применения серии стандартов МЭК 61850.

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

6.4.2.3 Атрибуты данных и блоков управления

Многие атрибуты данных иерархической модели информации могут быть заданы сервисом настройки (Set-service), например SetDataValues и SetDataSetValues. Настройка значений атрибутов данных, как правило, ограничивается только приложением.

Различные блоки управления, например блок управления группой настроек (SGCB), блок управления отложенным отчетом (BRCB) и блок управления журналом (LCB), имеют такие атрибуты блока управления, которые, как правило, могут быть настроены на определенное значение. В МЭК 61850-7-2 определены сервисы для настройки этих атрибутов вместе с блоками управления. Настройка значений атрибутов блоков управления ограничивается конечным автоматом соответствующего блока управления.

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

Все атрибуты блока управления могут быть считаны другим IED-устройством.

6.4.2.4 Данные настроек и блок управления группой настроек

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

Рисунок 16 — Данные настроек (концептуальное представление)

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

Значения определенной группы настроек, содержащиеся в данных настроек, могут быть заданы, только если эта группа находится в состоянии EDIT («Редактирование») (что обозначают как FC = SE; редактирование данных настройки). После того как заданы все значения этой группы, значения этой группы могут быть подтверждены как содержащие совместимый набор значений. Этот вновь подтвержденный набор значений затем может быть выбран для использования приложением (группа настроек в активном состоянии: FC = SG; активные данные настроек).

Значение setVal группы FC = SP означает «простые» данные настроек (уставку), применяющиеся в том случае, когда модель управления группой настроек не поддерживается. Это значение может быть задано как обыкновенный атрибут данных.

6.4.3 Модель входа

6.4.3.1 Сбор входных аналоговых сигналов

• «коммутатор» данных подставлять/не подставлять (моделируется как атрибут данных subMag этих данных, например, напряжение определенной фазы);
• блокируемый или не блокируемый оператором «коммутатор».

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

6.4.3.2 Обработка, контроль значения атрибута данных и обнаружение события

«Промежуточное значение» используется для различных целей, в первую очередь для представления в качестве мгновенного значения атрибута данных (величины) определенных данных. Этот атрибут данных называется instMag с функциональной связью FC = MX (являющейся значением измеряемой величины). Мгновенное значение ни с какой опцией пуска не связано.

Второй вариант использования — это расчет значения зоны нечувствительности значения mag. Значение зоны нечувствительности должно быть основано на расчете зоны нечувствительности из instMag, как показано на рисунке 18. Значение mag должно обновляться по текущему значению instMag при изменении этого значения в соответствии со значением параметра конфигурации db этих данных.

Рисунок 18 — Значение зоны нечувствительности (концептуальное представление)

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

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

Как только изменяется значение mag, сразу же возникает внутреннее событие. Значение зоны нечувствительности mag и событие (изменение данных — в соответствии с опцией пуска TrgOp = dchg) доступны для дальнейших действий, например составления отчетов или регистрации в журнале.

Рисунок 19 — Модель входа для аналоговых значений (этап 2) (концептуальное представление), лист 1

Рисунок 19, лист 2

Третий вариант использования — это контроль «промежуточного значения» для определения текущего диапазона данного значения. Диапазон может быть таким, какой показан на рисунке 20.

Рисунок 20 — Значения диапазона

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

В дополнение к различным значениям эти два атрибута quality и t (временная метка) доступны в любое время. Временная метка определяется в момент определения изменения значения атрибутов данных mag и range. Изменение в атрибуте quality также может быть использовано для формирования внутреннего события.

События, концептуально представленные на правой стороне рисунка 19, определены в МЭК 61850-7-4 и МЭК 61850-7-3. На этом рисунке слева и на рисунке 21 показаны (концептуально) определения, представленные в МЭК 61850-7-2.

Рисунок 21 — Модель выдачи отчетов и регистрации (концептуальное представление)

6.4.3.3 Выдача отчетов и регистрация данных

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

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

NOTE — All data attributes are functionally constrained by FC = ST.

Примечание - Все атрибуты данных функционально связаны FC = ST/

Рисунок 22 — Элементы набора данных и выдача отчетов

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

Каждый из этих четырех методов поиска имеет свои особенности. Нет ни одного метода, который удовлетворял бы всем требованиям приложений. При проектировании системы разработчик должен проанализировать эти требования и сверить их с (внедренными!) методами, обеспечиваемыми устройством, которое соответствует требованиям серии стандартов МЭК 61850.

Базовый механизм буферизованной выдачи отчетов показан на рисунке 23. Буферизованная и небуферизованная выдача отчетов начинается с конфигурирования блоков управления отчетами. Выдача отчетов начинается с установки атрибута разрешения буфера на TRUE; установка на FALSE запрещает выдачу отчетов.

Рисунок 23 — Блок управления буферизованным отчетом (концептуальное представление), лист 1

Рисунок 23, лист 2

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

Блок управления небуферизованным отчетом не поддерживает SoE в случае потери связи.

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

RpdID управление — обеспечивается клиентом для идентификации блока управления буферизованным отчетом;

RptEna — для дистанционного разрешения/запрещения процесса выдачи отчетов;

DatSet — обеспечивает ссылки на тот набор данных, значения которого должны быть включены в отчет;

ConfRev — содержит версию конфигурации для обозначения удаления элемента набора данных или переупорядочения элементов;

OptFIds — указывает опциональные поля, которые должны быть включены в отчет:

• имя набора данных для указания, из какого набора данных были сгенерированы значения;
• ссылка на данные для включения объектных ссылок для значений;

BufTm — указывает время ожидания после того, как в некотором наборе данных произошло первое событие (см. рисунок 24);

SeqNum — текущий порядковый номер отчетов;

TrgOps — (опции пуска) указывает причины, которые привели к выдаче блоком управления значения в отчет. Такими причинами могут быть изменение данных dchg, обновление данных dupd или изменение качества qchg атрибута данных в логическом узле;

IntgPd — (период сохранности): выдача отчетов по всем значениям, инициированная сервером в этот период;

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

Если, во-первых, в отчет вместе со значениями не включены никакие объектные ссылки и, во-вторых, если в отчет должны быть включены только значения для подмножества элементов набора данных, то создается условие для определения, каким именно элементам принадлежат включенные в отчет значения. Отображение SCSM, описанное в МЭК 61850-8-1 [2], определяет включение битовой строки для указания элемента набора данных. Порядок элементов набора данных должен быть установлен согласно их определению в наборе данных. На рисунке 25 приведен такой пример.

В наборе данных содержатся два элемента в указанном порядке. В отчете с включенной битовой строкой есть два бита, значения которых указывают, производными каких элементов являются данные значения. Первый бит — логическая единица (TRUE); следовательно, значения в фигурных скобках — это значения элемента MyLd/XCBR1.Pos. Для второго элемента в отчет не включены никакие значения (второй бит является логическим нулем, FALSE). Отчет с включенной битовой строкой позволяет оптимизировать длину сообщения с отчетом.

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

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

На рисунке 26 показан пример журнала и трех блоков управления журналом. Первый этап состоит в конфигурировании и активировании блоков управления журналом. После активирования ассоциация с данным сервером может быть закрыта. Записи сохраняются в журнале по мере их поступления для включения в журнал. Журналы сохраняются по времени следования. Это позволяет получать перечень последовательности событий (SoE).

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

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

• RptEna для дистанционного разрешения/запрещения процесса регистрации;
• DatSet обеспечивает ссылки на тот набор данных, значения которого должны быть зарегистрированы;
• TrgOps указывает причины, по которым блок управления должен сохранить запись в журнале. Причины, по которым какая-либо запись должна быть сохранена в журнале, могут быть следующими: изменение данных dchg, обновление данных dupd или изменение качества qchg атрибута данных в логическом узле;
• период сохранности IntgPd: регистрация всех значений, инициированная сервером на основании заданного периода;
• LogRef указывает, в каком журнале должны быть сохранены записи.

6.4.3.4 Одноранговая публикация значения данных

Одноранговая связь обеспечивает сервисы для обмена общими событиями на подстанции (GOOSE и GSSE; на основании многоадресного обмена) и для обмена выборочных значений (на основании многоадресного или одноадресного обмена). Прием сообщения GOOSE и GSSE объяснен в модели входа в 6.4.2.2.

На рисунке 27 показаны модели GOOSE и выборочных значений.

Примечание — Модель GSSE (обратно совместимая с IEEE TR 1550 [8] - UCA — GOOSE) подобна модели GOOSE (МЭК). GSSE лишь поддерживает фиксированную структуру данных состояния, которые должны быть опубликованы. Данные для сообщения GOOSE конфигурируются наложением наборов данных, включающих в себя любые данные.

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

В модели GOOSE есть несколько атрибутов, которые контролируют процесс публикации, например:

• GoEna для дистанционного разрешения/запрещения публикации;
• AppID рассылает сообщение, которое должно быть использовано как руководство для принимающего приложения;
• DatSet обеспечивает ссылки на тот набор данных, значения которого должны быть опубликованы;
• ConfRev содержит версию конфигурации для обозначения удаления элемента набора данных, или переупорядочения элементов, или замену ссылки DatSet;
• NdsCom указывает в сообщении, что требуется некоторый ввод в действие.

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

6.4.3.5 Публикация выборочного значения

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

• SvEna для дистанционного разрешения/запрещения публикации;
• MsvID рассылает сообщение, которое должно быть использовано как руководство для принимающего приложения;
• DatSet обеспечивает ссылки на тот набор данных, значения которого должны быть опубликованы;
• ConfRev содержит версию конфигурации для обозначения удаления элемента набора данных или переупорядочения элементов либо замену ссылки DatSet;
• SmpRate определяет выборочные значения на элемент.

7 Прикладной подход

7.1 Введение

В качестве примера использования (рисунок 28) показано переключение выключателя. Оператор на удаленном HMI-интерфейсе предполагает дистанционно переключить выключатель. HMI-компьютер и выключатель должны работать совместно (взаимодействовать). Во-первых, компьютеру необходимо знать, какую информацию он должен передать IED-устройству, представляющему выключатель (как правило, называемому «технологическим интерфейсом»). Во-вторых, ему также необходимо знать имя этого IED-устройства (например, «Circuitbreaker1»), а также какой у него адрес. И HMI-компьютер (на рисунке слева), и IED-устройство «circuitbreaker1» (на рисунке справа) подсоединены к общей коммуникационной сети. HMI-интерфейс посылает управляющую команду на «Circuitbreaker1» на переключение положения выключателя (включить выключатель). После завершения процесса переключения интерфейс IED может (если это задано в конфигурации) послать на HMI-компьютер отчет, показывающий, что положение выключателя изменилось.

Рисунок 28 — Физические устройства

Разные пользователи могут по-разному называть выключатель; один может использовать имя «Circuitbreaker1», другой может выбрать «СВК-2». МЭК 61850-7-4, основанный на подходе, описанном в МЭК 61850-5, стандартизует множество сокращенных наименований функций подстанции и связанного с ней оборудования. Стандартизованное наименование для выключателя — XCBR. Это наименование может сопровождаться суффиксом и префиксом: Q1XCBR1 [соглашения в отношении присваивания имен см. в 13.4, A.2, A.3 (приложение A) и МЭК 61850-7-2].

Приложениям в компьютере (с левой стороны рисунка 28) может также потребоваться информация:

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

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

Все эти и многие другие функции, поддерживаемые контроллером, имеют три главных составляющих, которые установлены серией стандартов МЭК 61850:

• какие функции и какая информация могут быть доступны в сети, как они поименованы и описаны (МЭК 61850-7-4, МЭК 61850-7-3 и МЭК 61850-7-2);
• как может быть получен доступ к функциям и как (в целом) может происходить обмен информацией (МЭК 61850-7-2);
• каким образом устройства могут быть подключены к сетям связи (МЭК 61850-8-1 [2], МЭК 60850-9-1 [3] и МЭК 60850-9-2 [4]).

Динамический режим работы реального устройства устанавливается через конфигурируемые атрибуты реализованной информационной модели и путем изменений ее значений. Следствия любого изменения значения в информационной модели определены в настоящем стандарте. Результатом управления «Circuitbreaker1» является размыкание или замыкание реального контура. Контроллер может немедленно послать отчет (значение, показатель качества и временную метку) инициатору, а также может дополнительно записать это событие в журнал устройства для дальнейшего поиска информации. Различные динамические режимы работы контроллера могут быть предварительно конфигурированы с помощью инструментальных средств. Режим работы может быть изменен конфигурированием контроллера с использованием специальных сервисов дистанционного конфигурирования (настройки); например, возможно дистанционно разрешить или запретить выдачу отчета о значениях.

7.2 Первый этап моделирования — логические узлы и данные

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

Рисунок 29 — Логические узлы и данные (МЭК 61850-7-2)

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

Например, значение «блокирован», в соответствии с МЭК 61850-7-4, указывает на то, что:

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

Эти данные составляют основу большинства информационных обменов через сеть. Большинство взаимодействий с устройством происходит через данные в логических узлах и сервисы. Какой тип прикладной информации представляют отдельные данные, определено в МЭК 61850-7-3 (класс общих данных), например двухэлементная информация о положении или измеренное значение. Каждый класс общих данных имеет назначенные для него сервисы, которые определяют возможные сервисы, разрешенные к выполнению с этими данными. Какая-то информация может быть доступна для записи и чтения, другая — только для чтения. Так называемая функциональная связь (Functional Constraint — FC) определяет эту характеристику для каждой информации отдельного класса данных. Информация о данных определяется как обязательная или дополнительная (опциональная). Все сервисы (например, GetDataValues, Operate) определены в МЭК 61850-7-2.

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

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

В настоящем стандарте используется иерархическая организация данных. На рисунке 30 показан пример физического устройства «BayUnit» с функциями защиты, такими как «Дистанционная защита» (PDIS), «Максимальная токовая защита с выдержкой времени» (PTOC), а также с функцией «Формирование сигнала на отключение» (PTRC). Связанные с этим технологические данные, основные функции и другие важные составляющие элемента присоединения моделируются как данные в древовидной структуре. Каждый элемент этого дерева является данными: данными на верхнем уровне является Bay Unit («Элемент присоединения»), включающий в себя Distance protection («Дистанционную защиту»), Time Overcurrent («Максимальную токовую защиту с выдержкой времени») и Trip conditioning («Формирование сигнала на отключение»). Distance protection содержит, например, данные Start («Старт», Str) с различными атрибутами, такими как general (общий) и «Фаза A» (phsA).

Рисунок 30 — Простой пример моделирования, лист 1

Рисунок 30, лист 2

Элементы логического узла показаны на рисунке 31. Наличие сервиса управления указывает на возможность управлять чем-либо в устройстве. Это моделируется в виде данных. Например, для выключения всех светодиодов в устройстве достаточно установить значение данных LEDRs на True. Данные могут быть сгруппированы в наборы данных и отправлены в виде отчета немедленно или зарегистрированы для более позднего запроса.

Рисунок 31 — Основные компоновочные блоки

Управление и выдача отчетов формируют одну часть интерфейса логического узла. Другие сервисы, оперирующие данными: подстановка для замены значений данных на фиксированную величину; получение и настройка для чтения и записи значений данных и наборов данных; Dir и Definition (директория и определение) (GetDataDirectory, GetDataDefinition) для поиска информации каталога экземпляра данных и определения экземпляра данных. С абстрактной точки зрения, интерфейсы логического узла могут быть суммированы, как это показано на рисунке 32. Под сервисами понимают также перенос информации, определенной как PICOM данные (единицы передаваемой информации), как это представлено в МЭК 61850-5.

Рисунок 32 — Логические узлы и PICOM

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

Рисунок 33 — Связанные логические узлы (внешний вид в соответствии с серией стандартов МЭК 61850-7)

С этой точки зрения, информационный поток абстрагирован от любой информации, имеющей отношение к связи, например нотация запрос/ответ.

Дальнейшее объяснение по компоновочным блокам и их сервисам приведено в разделе 8.

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

8 Аппаратное представление

8.1 Введение

Физические устройства включают в себя в основном следующее:

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

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

8.2 Второй этап моделирования — модель логического устройства

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

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

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

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

В примере на рисунке 35 логическое устройство LD1 включает в себя три логических узла. Логический узел нуль (LLN0) представляет общие данные логического устройства, а физическое устройство логического узла (LPHD) — общие данные физического устройства, размещающего данное логическое устройство. LLN0 и LPHD должны быть определены в любом логическом устройстве. С правой стороны на рисунке для примера приведена информация паспортной таблички об основном оборудовании в виде данных логического узла, который представляет основное оборудование.

Рисунок 35 — Логические устройства и LLN0/LPHD

LPHD в PHD«A».LD1 дает точно такую же информацию, как LPHD в PHD«A».LD2, тогда как LLN0 в PHD«A».LD1 и LLN0 в PHD«A».LD2 передают разную информацию.

На рисунке 36 показано, как многочисленные физические устройства могут быть отображены в посредническом устройстве или шлюзе. Логическое устройство LD1 «копируется» в посредническое устройство или шлюз. LPHD логического устройства LD1 или шлюза представляет физическое устройство PHD «A».

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

Логические устройства, которые не отражают логические устройства других физических устройств, должны обеспечивать LPHD, представляющий физическое устройство, где они резидентно расположены (например, LD7). В этих логических устройствах данные LPHD.Proxy.stVal логического узла LPHD должны быть установлены на FALSE.

Логические устройства, которые отражают логические устройства других физических устройств, должны обеспечивать LPHD, представляющий удаленное физическое устройство, где резидентно расположено исходное LD (например, LD1). В этих логических устройствах данные LPHD.Proxy.stVal логического узла LPHD должны быть установлены на TRUE.

9 Представление с точки зрения связи

9.1 Модели сервисов серии стандартов МЭК 61850

Для определения сервисов используется технология объектного моделирования. В интерфейсе данного сервиса используется метод абстрактного моделирования. «Абстрактного» — значит, это определение ориентируется на описание того, что предоставляют данные сервисы. Настоящий стандарт конкретные сообщения (и их кодирование), которые участвуют в обмене между устройствами (как построены сервисы), не рассматривает. Эти конкретные сообщения описаны в специфическом отображении сервиса связи (SCSM в МЭК 61850-8-1 [2], МЭК 61850-9-1 [3] и МЭК 61850-9-2 [4]).

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

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

Рисунок 37 — Методы связи ACSI, лист 1

Рисунок 37, лист 2

Физически клиенты и серверы могут соединяться с использованием различных систем связи. Средства связи могут иметь географические и пользовательские ограничения, такие как ограничение скорости битов, уровни собственнических каналов передачи данных, ограничение времени использования, а также задержки при использовании спутниковой связи. Системы могут быть иерархическими, с несколькими центральными пунктами, разрешающими и управляющими взаимодействиями с большим числом «полевых» площадок, либо это может быть сетевая организация с одноранговыми взаимодействиями. Средства связи могут иметь различные конфигурации, такие как точка — множество точек, моноканал, ячеистая, иерархическая, WAN-LAN, промежуточные узлы в роли маршрутизаторов, шлюзов или баз данных концентратора данных и т.д.

В таблице 6 приведен перечень моделей сервисов и сервисов ACSI.

Таблица 6

Модели и сервисы ACSI

9.2 Виртуализация

ACSI обеспечивает доступ к реальным данным и физическим устройствам через виртуальное изображение, как это показано на рисунке 38. Благодаря сервисам ACSI виртуальное изображение, которое представляет реальные данные устройств, становится видимым и доступным. Компьютер может запрашивать сервисы, например получать значения данных, либо может получать значения, спорадически включаемые контроллером в отчеты.

Рисунок 38 — Виртуализация

Виртуальное представление может быть использовано (как показано на рисунке 39) для описания и представления всего режима работы устройства. Любое другое устройство, другой контроллер или даже SCADA-система, система обслуживания или проектно-конструкторская система может использовать сервисы ACSI для взаимодействия с этим устройством. Полученный запрос сервиса независим по отношению к устройству, которое запросило этот сервис.

Рисунок 39 — Виртуализация и использование

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

9.3 Основные механизмы обмена информацией

Модель ACSI в основном обеспечивает методы обмена информацией между устройствами, как это показано на рисунке 40.

Рисунок 40 — Информационный поток и моделирование

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

Рисунок 41 — Применение модели GSE

В данном примере использовано пять логических узлов. Порядок действий и сообщений GOOSE следующий.

1. Логический узел «схема защиты» (PDIS) обнаруживает отказ, это выражается в принятии решения о выдаче сигнала на отключение.

2. Логический узел «формирование сигнала на отключение» (PTRC) выдает сообщение на отключение (с помощью сообщения GOOSE), «нуль выключателя» (XCBR0) был сконфигурирован на получение сообщения на отключение. После дополнительной обработки коммутационная аппаратура отключает выключатель.

4. Логический узел «автоматическое повторное включение» (RREC) получает сообщение GOOSE от XCBR0 со значением <выключен>. Согласно сконфигурированному режиму работы RREC решает снова включить выключатель и посылает сообщение GOOSE со значением <повторное включение>.

5. «Нуль выключателя» (XCBR0) получает сообщение GOOSE со значением <повторное включение>. После дополнительной обработки коммутационная аппаратура включает выключатель. XCBR инициирует отправку еще одного сообщения GOOSE <новое положение переключателя = включен>.

Данная последовательность приведена только в качестве примера. В серии стандартов МЭК 61850 показаны основные механизмы обмена сообщениями GOOSE в условиях реального времени. Использование сообщений GOOSE может быть столь же простым, как это описано в данном примере. Однако возможно образование и более сложных схем. Сигнал на отключение может быть повторен еще раз в самом начале для того, чтобы увеличить вероятность получения его всеми принимающими IED-устройствами. Все эти схемы выходят за область применения серии стандартов МЭК 61850.

9.4 Компоновочные блоки клиент — сервер

9.4.1 Сервер

Рисунок 42 — Компоновочные блоки сервера

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

9.4.2 Клиент — сервер

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

Рисунок 43 — Взаимодействие между прикладным процессом и прикладным уровнем (клиент — сервер)

На рисунке 44 показан пример сервиса get, который разрешает клиенту поиск значений данных в сервере.

Рисунок 44, лист 2

9.4.3 Роли клиента и сервера

Из рисунка 45 видно, что один сервер «обслуживает» различные логические узлы и различных клиентов.

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

Примечание - Клиенты и их внутренняя структура и функции в настоящем стандарте не определены.

Как показано на рисунке 46, устройства могут выполнять как роль клиента, так и роль сервера.

Рисунок 46 — Роли клиента и сервера

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

Представление в виде логических узлов и представление с точки зрения связи — это два разных варианта представления одного и того же реального субъекта.

9.5 Интерфейсы внутри и между устройствами

В реальных системах подстанций есть много интерфейсов — интерфейсов для различных целей. В серии стандартов МЭК 61850-7, в МЭК 61850-8-1 [2], а также МЭК 61850-9-1 [3] и МЭК 61850-9-2 [4] определены интерфейсы между устройствами (между двумя устройствами, состоящими в отношении клиент — сервер, и между несколькими устройствами в одноранговых отношениях). В серии стандартов МЭК 61850-7 определены абстрактные интерфейсы, тогда как в МЭК 61850-8-1 [2], МЭК 61850-9-1 [3] и МЭК 61850-9-2 [4] определены конкретные интерфейсы.

Рисунок 48 — Интерфейсы внутри и между устройствами, лист 1

Рисунок 48, лист 2

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

10 Взаимодействие физических устройств, прикладных моделей и сервисов связи

Физические устройства расположены в центре иерархии компонентов, как это показано на рисунке 49. Все представления «встречаются» в сервере. Каждое представление внутри физического устройства связано с другими видами представления. Различные представления показаны здесь с целью продемонстрировать, что при реализации физических устройств в дополнение к серии стандартов МЭК 61850 (которые описывают только одно представление реальной системы автоматизации) необходимо учитывать множество других факторов.

Рисунок 49, лист 2

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

a) сервер отображает моделированное представление данных приложения (серия стандартов МЭК 61850) в остальную сеть;

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

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

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

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

11 Взаимосвязь между МЭК 61850-7-2, МЭК 61850-7-3 и МЭК 61850-7-4

11.1 Уточнения определений классов

Одним из основных компоновочных блоков является класс DATA, определенный в МЭК 61850-7-2. Класс DATA используется в определении почти всей информации, определяемой в логических узлах. Класс DATA, как определено в МЭК 61850-7-2, — это класс, показанный слева на рисунке 50. Класс DATA определяет три атрибута данных и четыре сервиса. Эти сервисы определены в МЭК 61850-7-2. Содержимое атрибутов данных не определено в МЭК 61850-7-2. Следовательно, класс DATA очень общий. Если он должен быть использован в какой-либо прикладной области, он должен быть более конкретным. Это может потребовать определения всех экземпляров класса DATA, необходимых для моделирования специальных функций подстанции внутри логических узлов. Общепринят анализ прикладной области для выявления общих свойств и условий, применимых к нескольким классам данных. Эти общие определения обеспечиваются классами общих данных (CDC), описанными в МЭК 61850-7-3.

Рисунок 50 — Уточнение класса DATA

11.2 Пример 1 — логический узел и класс данных

Таблица 7

Так как несколько классов DATA используют одни и те же детальные определения (ATTRIBUTES), эти детальные определения должны быть собраны для повторного использования в классах общих данных (общие для многих классов DATA). Классы общих данных определены в МЭК 61850-7-3. В качестве примера в таблице 8 показан класс общих данных DPC (двухэлементное управление) для Pos.

Таблица 8

Двухэлементное управление (DPC)

Класс общих данных DPC состоит из перечня 20 атрибутов данных. У каждого атрибута есть имя, тип, функциональная связь, опция пуска, значение/диапазон значения и указание, является этот атрибут обязательным или опциональным.

Как минимум, все обязательные атрибуты всех обязательных классов DATA логического узла XCBR в таблице 7 входят в состав атрибутов XCBR. Опциональные классы DATA (например, возможность определения фазы точки переключения — POWCap) и опциональные атрибуты данных (например, origin — источник сообщения) должны быть использованы, если это требуется приложением.

Все (возможные) атрибуты DATA Pos, производные от класса общих данных DPC, показаны в левой части рисунка 51. Экземпляр, содержащий все атрибуты данных, изображен в середине. Класс DATA Pos содержится в логическом устройстве MyLD и в логическом узле XCBR1. Во втором экземпляре содержатся только пять обязательных атрибутов данных.

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

Эти условия представлены в последней колонке класса DATA Pos (выдержка из МЭК 61850-7-3) и включают в себя следующее:

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

11.3 Пример 2 — взаимосвязь между МЭК 61850-7-2, МЭК 61850-7-3 и МЭК 61850-7-4

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

На рисунке 52 изображен пример взаимосвязи между МЭК 61850-7-2, МЭК 61850-7-3 и МЭК 61850-7-4. На уровне МЭК 61850-7-4 доступны два класса логических узлов XCBR и XDIS. В каждом логическом узле имеется класс данных, представляющий «положение двухэлементного управления» (класс общих данных: DPC). В МЭК 61850-7-3 определен перечень приблизительно из 20 классов общих данных, которые могут быть использованы для описания функциональных возможностей данных. Один экземпляр логического узла XCBR1 показан в нижней части рисунка 52. Этот экземпляр доступен для сервисов.

Рисунок 52, лист 2

Класс общих данных DPC включает в себя рассчитанный на многократное использование перечень атрибутов, таких как управляемое значение (значение, которое может быть изменено в результате управления co), значение состояния, качественная или временная метка (значения, которые могут быть включены в отчет st) и модель управления (значение, которое может быть сконфигурировано cf). Атрибуты классов общих данных имеют стандартизованные имена атрибутов данных, например ctlVal, stVal или q. Эти имена используются для связи (независимо от SCSM) и в языке конфигурации подстанции в соответствии с МЭК 61850-6 [1].

Значение состояния stVal несет дополнительную информацию о том, когда начать выдачу отчета (dchg — запуск выдачи отчета при изменении значения состояния). Также выдача отчетов может быть начата при изменениях качества q атрибута qchg.

Использование класса логического узла и класса данных (МЭК 61850-7-4), класса общих данных (МЭК 61850-7-3) и общего логического узла, класса данных и сервисов (МЭК 61850-7-2) в реальной системе показано в нижней части рисунка 52. Сервис (Operate XCBR1.Pos = on) включает выключатель. Сервис (Report XCBR.Pos) информирует получателя об изменении текущего положения с временной меткой и информацией о качестве. После успешного процесса переключения атрибут данных stVal получает новую информацию о состоянии.

12 Отображение ACSI на реальные системы связи

12.1 Введение

PDU: Protocol Data Unit (encoded message containing the service parameter, etc.).

Рисунок 53 — Отображение ACSI на уровень приложения

Отображение сервисов ACSI на сообщения определенного прикладного уровня выходит за область применения МЭК 61850-7-2; это отображение описано в специфическом отображении сервиса связи (SCSM) в МЭК 61850-8-1 [2], МЭК 61850-9-1 [3] и МЭК 61850-9-2 [4].

Примечание 1 — Это отображение позволяет применять ACSI с различными прикладными уровнями. Поскольку эти прикладные уровни обеспечивают различные возможности, отображение в рамках SCSM может быть простым или комплексным, а также более или менее эффективным.

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

Стандартизованные отображения абстрактных сервисов на различные стеки связи определены в МЭК 61850-8-1 [2], МЭК 61850-9-1 [3] и МЭК 61850-9-2 [4]. Выполнение общих функций предприятий электроэнергетики будет единообразным на всех устройствах полевого уровня вне зависимости от нижележащих систем связи. На рисунке 54 приведены отображения, определяемые в МЭК 61850-8-1 [2], МЭК 61850-9-1 [3] и МЭК 61850-9-2 [4].

Рисунок 54 — Отображения ACSI (концептуальное представление)

Все виды передачи, кроме GOOSE и передачи выборочных значений, отображаются на MMS, TCP/IP и ИСО/МЭК 8802-3 [5]. Передача GOOSE отображается непосредственно на ИСО/МЭК 8802-3 [5]. Передача выборочных значений отображается на МЭК 61850-9-1 [3] и МЭК 61850-9-2 [4].

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

Примечание 2 — Концепция SCSM была введена для того, чтобы обеспечить независимость от стеков связи, включая прикладные протоколы. Одна из целей МЭК 61850 — взаимодействие устройств. Для этого необходимо, чтобы все связывающиеся устройства использовали один и тот же стек связи. Таким образом, цель такой независимости заключается не в наличии множества параллельных отображений, а в возможности отслеживания уровня техники в коммуникационных технологиях.

В соответствии с рисунком 55 SCSM отображает абстрактные сервисы связи, объекты и параметры на специфические прикладные уровни. Эти прикладные уровни обеспечивают конкретное кодирование. В зависимости от технологии сети связи эти отображения могут иметь различные сложности, а некоторые сервисы ACSI могут не поддерживаться непосредственно во всех отображениях, но эквивалентные сервисы будут обеспечены (см. пример ниже). Прикладной уровень может использовать один или более стек (уровни 1 — 6).

Пример - Сервис ACSI GetDataSetValues может иметь различные отображения для различных прикладных уровней (AL). Например, определенный AL может поддерживать этот сервис непосредственно, тогда как другой AL обеспечивает получение только одноэлементных данных (Get of single data). В последнем случае отображение должно выдать несколько одноэлементных данных.

12.2 Пример отображения (МЭК 61850-8-1 [2])

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

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

Абстрактные модели этих трех стандартов — МЭК 61850-7-4, МЭК 61850-7-3 и МЭК 61850-7-2 — должны быть отображены на прикладном уровне (см. рисунок 56).

В данном примере информационная модель и различные блоки управления отображаются на спецификацию производственных сообщений (MMS), т.е. на модели VMD (Virtual Manufacturing Device), домена, поименованной переменной, списка поименованных переменных, журнала и управления файлами. Сервисы отображаются на соответствующие сервисы классов MMS.

На рисунке 57 отображение показано более подробно. Абстрактные информационные модели, определенные в МЭК 61850-7-4, МЭК 61850-7-3 и МЭК 61850-7-2, отображаются следующим образом.

<*> GOOSE/GSSE/SMV messages map directly to ISO/IEC 8802-3

Рисунок 58 — Подробное описание отображения в поименованную переменную MMS

Домен MMS (с именем K03) содержит поименованные переменные. Поименованная переменная, показанная на рисунке 59, носит имя Q0CSWI. Компоненты этой поименованной переменной созданы путем выбора всех атрибутов данных с одинаковой функциональной связью (FC), например значение FC = ST (все атрибуты данных состояния). Первый компонент поименованной переменной носит имя компонента ST. Экземпляры класса DATA (например, Pos) помещены на следующий уровень вложения. Атрибуты данных (например, stVal, q, t и т.д.) находятся на следующем, еще более низком уровне. Точки «.» в иерархическом имени были заменены символом «$» в отображении MMS.

13 Метод формализованного описания

13.1 Нотация классов ACSI

В МЭК 61850-7-2 следует использовать нотацию класса, как показано в таблице 9.

13.2 Моделирование классов

13.2.1 Обзор

Экземпляры, показанные для примера, находятся с правой стороны рисунка. Например, myXCBRI:XCBR означает, что myXCBR1 — экземпляр, производный от класса логического узла XCBR.

Экземпляры примера на рисунке 63 показывают, какие имена имеют экземпляры: сервер называется «abc» класса сервера и т.д. Значение состояния stVal имеет имя xyz/myXCBR1.pos1.stVal.

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

В следующих пунктах рассмотрены примеры структуры классов, определяемых в серии стандартов МЭК 61850.

13.2.2 Класс общих данных

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

Класс общих данных состояния одноэлементного управления (SPS)

В первой колонке представлено имя атрибута, во второй — тип атрибута. Атрибут, который состоит из нескольких компонентов, должен быть определен так, как показано в примере в таблице 11 (выдержка типа Quality МЭК 61850-7-3).

Таблица 11

Определение атрибутов компонентов Quality

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

Компоненты Quality (например, validity или detailQual) являются компонентами атрибута данных. Типы атрибутов компонентов атрибута данных (например, PACKED LIST или CODED ENUM) определены в МЭК 61850-7-2.

В таблице 12 показано, какие сервисы разрешены для информации о состоянии.

Таблица 12

Базовый шаблон информации о состоянии (выдержка)

Применимые сервисы перечислены в третьей колонке. Для всех данных, которые наследуют атрибуты из класса общих данных SPS (см. таблицу 12), атрибуты с FC = ST могут быть доступны с использованием следующих сервисов (указывают ключевым словом ALL):

GetDataValues;

GetDataDefinition;

GetDataSetValues;

Report.

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

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

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

Рисунок 64 — Взаимосвязь TrgOp и выдачи отчетов

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

13.2.3 Класс логического узла

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

Таблица 14

Определение класса логического узла (LN)

Колонки таблицы класса — это имя атрибута, тип атрибута и пояснение. Строки представляют собой атрибуты логического узла.

Каждый класс логического узла имеет имя логического узла (LNName). В МЭК 61850-7-4 определено множество имен логического класса, например XCBR для логического узла «выключатель».

Ссылка логического узла (LNRef) используется для ссылки на экземпляр логического узла. Примером может быть MyLD/XCBR1. Это указывает на наличие экземпляра с именем XCBR1 класса XCBR, который содержится в логическом устройстве MyLD.

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

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

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

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

Сервисы, работающие в логическом узле, — это те два сервиса, которые указаны в конце таблицы (GetLogicalNodeDirectory и GetAllDataValues), и ВСЕ сервисы, которые указаны с классами, перечисленными в колонке «Тип атрибута». Все классы, которые используются как типы, имеют свои собственные сервисы. У класса DATA есть несколько сервисов, например GetDataValues и SetDataValues.

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

13.3 Таблицы сервисов

В МЭК 61850-7-2 определены сервисы с подтверждением и без подтверждения. Отображение сервисов с подтверждением требует, чтобы используемый прикладной уровень обеспечивал метод, служащий для идентификации запроса и соответствующего ответа в пределах ассоциации. Таблицы сервисов включают в себя те параметры, которые требуются для обработки конкретного сервиса:

Примечание - Таблицы сервисов, определенных в МЭК 61850-7-2, не показывают всех параметров, необходимых в конкретных реализациях интерфейсов; например, параметры «ассоциация» или «время передачи» не показаны в таблицах абстрактных сервисов. Эти таблицы носят абстрактный характер — локальные вопросы и вопросы конкретных протоколов не показаны. Для понимания семантики и характера работы сервиса эти специфические вопросы не важны.

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

Рисунок 65 — Диаграмма последовательностей

13.4 Экземпляры ссылок

В настоящем стандарте проведено различие между именами объекта и ссылками объекта. Имена объекта (рисунок 66) определяют экземпляр класса на одном иерархическом уровне (например, Mod на уровне Data или Q0XCBR1 на уровне логического узла). Q0 является префиксом, а 1 — суффиксом имени XCBR. Конкатенация всех имен объекта формирует ссылку объекта (например, MyLD/Q0XCBR1.Mode.stVal).

Ссылка атрибута данных определяет конкретный атрибут данных экземпляра данных. Ссылка данных определяет полный экземпляр данных со всеми его атрибутами данных.

Имя логического узла XCBR может быть дополнено префиксом (например, Q0) и суффиксом (например, 1) для создания имени логического узла (Q0XCBR1). Стандартизация префиксов и суффиксов выходит за область применения настоящего стандарта. Для экземпляров все имена данных и имена атрибутов данных используются в неизменном виде; никаких префиксов или суффиксов, отличных от тех, что определены в МЭК 61850-7-4, использовать для имен данных и атрибутов данных не допускается.

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

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

Концептуальное использование FCD и FCDA показано на рисунке 67 (с использованием нотации MMS с символом $ и функциональной связью (FC) между LNName и DataName).

Рисунок 67 — Использование FCD и FCDA

Имена логического устройства настоящий стандарт не определяет.

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

В приведенном ниже примере выдержка XML (в соответствии с МЭК 61850-6 [1]) включает в себя секцию подстанции с одним присоединением E1Q1, в которое входят выключатель QA1 и разъединитель QB1, электрически соединенные друг с другом в узле L1.

        <Device Ref = "QA1" Type = "CBR">
            <Connection TNodeRef = "L17>
            <LNode Ref = "XCBR1" LNClass = "XCBR7>
        </Device>
        <Device Ref = "QB1" Type = "DIS">
            <Connection TNodeRef = "L17>
            <LNode Ref = "XSWI2" LNClass = "XSWI7>
        </Device>

    </Bay><br>
</VoltageLevel><br>

Ссылка логического узла может быть выражена в виде: AB.E1.Q1.QA1/XCBR1 с AB.E1.Q1.QA1 в качестве имени логического устройства.

Почти все сервисы МЭК 61850-7-2 используют объектные ссылки как параметр сервиса. Эти объектные ссылки не должны изменяться при отображении SCSM. Они могут отображаться в SCSM в уникальные номера.

На рисунке 68 показаны примеры имен объектов и ссылок объектов. Пример вверху (на первых пяти строках) может быть только пятью определениями классов (еще не определенных как экземпляры) или пятью экземплярами классов E1.QA5/XCBR.Pos.ctlVal, ...stVal, ...q, ...t, ...ctlMode. В данном случае объектные ссылки не показывают, относятся объектные ссылки к классам или к экземплярам. Что конкретно имеется в виду (класс или экземпляр), должно быть понятно из контекста, в котором данные ссылки использованы.

Рисунок 68, лист 2

14 Пространства имен

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

Каждый класс, определенный в МЭК 61850-7-4 (например, выключатель LOGICAL-NODE, XCBR), МЭК 61850-7-3 (например, двухэлементный сигнал DPS) и МЭК 61850-7-2 (например, блок управления буферизованным отчетом, BRCB), имеет имя класса и особое значение, связанное с этим классом. Почти все классы состоят из других классов. Иерархическая модель классов серии стандартов МЭК 61850-7 обеспечивает иерархию присвоения имен. Каждое имя в этой иерархии имеет определенную семантику в том контексте, в котором данное имя используется.

На рисунке 69 показан пример определения имен и их семантики применительно к подстанции. Прикладной задачей, которая должна быть смоделирована и определена в стандартах МЭК серии 61850, может быть выключатель, схематически изображенный в центре вверху. Типовой выключатель моделируется как LOGICAL-NODE со специфическим именем класса XCBR. Этот выключатель является частью LOGICAL-DEVICE с именем SUBST2. Среди других атрибутов выключатель имеет информацию (смоделированную как класс DATA), которая представляет положение, поименованное как Pos. Среди прочей информации положение имеет состояние (смоделированное как DATA-ATTRIBUTE) с именем stVal. Значение состояния stVal имеет четыре значения, которые представляют возможные состояния физического выключателя.

Рисунок 69 — Определение имен и семантик

Если для построения LOGICAL-DEVICE используются только классы, определенные в серии стандартов МЭК 61850-7, то семантика будет такая, как определено в серии стандартов МЭК 61850-7.

Для тех приложений, которым необходимы дополнительные LOGICAL-NODE, должны быть установлены правила для DATA или DATA-ATTRIBUTE в целях однозначной интерпретации имен, т.е. для понимания содержимого и значения экземпляра класса в определенном контексте. В частности, в том случае, когда было определено одно и тоже имя, например Pos, имеющее различные значения, в настоящем стандарте требуется предотвратить конфликт из-за имени, имеющего несколько определений. Два значения имени элемента DATA показаны на рисунке 70. Имя экземпляра Pos элемента DATA используется в выключателе и в гондоле ветровой турбины (LOGICAL-NODE с именем WNAC). Применительно к ветровой турбине положение определяется как угол поворота гондолы. Это значение измеряют как аналоговую величину в градусах.

Рисунок 70 — Одно имя с двумя значениями

Имя Pos используется в двух различных контекстах: подстанции (серия стандартов МЭК 61850) и ветровой турбины (частная или типовая спецификация).

Использование ссылки на определенный контекст данных, т.е. концепция пространства имен, обеспечивает средства для уникального определения полной семантики экземпляра LOGICAL-DEVICE, т.е. семантики всех его LOGICAL-NODE, DATA, DATA-ATTRIBUTE и всех других экземпляров в контексте его использования.

Концепция пространства имен позволяет различать классы, определенные различными группами, — настолько, насколько пространства имен имеют уникальные идентификаторы.

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

14.2 Пространства имен, определенные в серии стандартов МЭК 61850-7

МЭК 61850-7-4 и МЭК 61850-7-3 определяют пространства имен для классов конкретных приложений. В МЭК 61850-7-2 определено пространство имен для относящихся к связи классов (сервиса), таких как BUFFERED-REPORT-CONTROL-BLOCK, LOG-CONTROL-BLOCK, LOGICAL-NODE, DATA, DATA-SET.

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

Рисунок 71 — Пространство имен как репозиторий классов

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

IdNS = МЭК 61850-7-4:2003

В данном примере пространство имен МЭК 61850-7-4:2003 указывает на то, что ВСЕ экземпляры в пределах данного логического устройства взяты из публикаций МЭК 61850-7-4, МЭК 61850-7-3 и МЭК 61850-7-2 2003 года издания. Пространство имен логического устройства допускается понимать как первичное пространство имен, даже если имеется только одно имя. Атрибут IdNs — это атрибут, включенный в паспортную табличку нулевого логического узла (LLN0).

Поскольку все эти три документа (МЭК 61850-7-4, МЭК 61850-7-3 и МЭК 61850-7-2) относятся к одному изданию, ссылки только на МЭК 61850-7-4 будет вполне достаточно. В МЭК 61850-7-4 включены ссылки на нормативную документацию, которые применимы и к двум другим документам. Основные экземпляры LOGICAL-NODE, DATA и DATA-ATTRIBUTE имеют подразумеваемое пространство имен (т.е. МЭК 61850-7-4, МЭК 61850-7-3 и МЭК 61850-7-2), которое получено из ссылок на нормативную документацию в МЭК 61850-7-4.

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