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

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

Группа П77

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

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

Часть 7

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

Раздел 1

Принципы и модели

Communication networks and systems in substations. Part 7. Basic communication structure for substation and feeder equipment. Section 1. Principles and models

ОКС 33.200
ОКП 42 3200

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

Предисловие

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

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

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

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

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

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

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

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

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

6 ВВЕДЕН ВПЕРВЫЕ

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1 - Руководство для пользователей


Пользователь	МЭК 61850-1 (Вве- дение и краткий обзор)	МЭК 61850-5 (Тре- бова- ния)	МЭК 61850-7-1 (Прин- ципы)	МЭК 61850-7-4 (Логи- ческие узлы и классы дан- ных)	МЭК 61850-7-3 (Клас- сы общих данных)	МЭК 61850-7-2 (Инфор- мацион- ный обмен)	МЭК 61850-6 [1] (Язык конфи- гурации)	МЭК 61850-8-1 [2] МЭК 61850-9-1 [3], МЭК 61850-9-2 [4] (Кон- кретный стек связи)
Пред- прия- тие	Руководитель	X	-	Раздел 5	-	-	-	-	-
	Инженер	X	X	X	X	X	Фрагменты	X	-
Пос- тав- щик	Специалист по прикладной области	X	X	X	X	X	Фрагменты	X	Фрагменты
	Специалист по связи	X	X	X	-	-	X	-	X
	Менеджер по продукции	X	X	X	X	Фрагменты	Фрагменты	Фрагменты	-
	Специалист по маркетингу	X	X	Раздел 5	Фрагменты	Фрагменты	Фрагменты	Фрагменты	-
Кон- суль- тант	Специалист по прикладной области	X	X	X	X	X	-	X	-
	Специалист по связи	X	-	X	-	-	X	X	X
Другое	X	X	X	-	-	-	-	-
Символ "X" означает, что с содержанием настоящего стандарта следует ознакомиться. "Фрагменты" означает, что для понимания применяемого концептуального подхода следует ознакомиться с фрагментами настоящего стандарта. Прочерк (-) означает, что ознакомление с настоящим стандартом факультативно.

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

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

- информационных моделей подстанций для систем автоматизации подстанций;

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

- систем связи для обеспечения взаимодействия в пределах подстанций.

Кроме того, в настоящем стандарте приведены объяснения и изложены подробные требования в отношении связи между МЭК 61850-7-4, МЭК 61850-7-3, МЭК 61850-7-2 и МЭК 61850-5. Объяснено так же, как абстрактные сервисы и модели серии стандартов МЭК 61850-7 отображаются в конкретных протоколах связи в соответствии с описанием, приведенным в МЭК 61850-8-1 [2].

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

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

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

- обмена информацией для распределительной автоматики;

- обмена информацией по измерениям;

- контроля состояния и диагностики;

- обмена информацией с техническими системами для конфигурирования устройств.

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

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

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

Примечание 4 - В настоящем стандарте не рассмотрены вопросы реализации.

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

В настоящем стандарте использованы нормативные ссылки на следующие международные стандарты*:
_______________
* Таблицу соответствия национальных стандартов международным см. по ссылке. - .

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

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

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

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

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

IEC 61850-7-2 Communication networks and systems in substations - Part 7-2: Basic communication structure for substation and feeder equipment - Abstract communication service interface (ACSI)

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

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

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

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

ИСО/МЭК 8825 (все части). Информационные технологии. Правила кодирования ASN.1

ISO/IEC 8825 (all parts), Information technology - ASN.1 encoding rules

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

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

3.1 информация (information): Знания об объектах, таких как факты, события, предметы, процессы, идеи, включая понятия, имеющие конкретное значение в определенном контексте.

3.2 информационная модель (information model): Модель, представляющая знания о функциях и устройствах подстанции, в которых реализованы данные функции.

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

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

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

4 Сокращения


	ACSI	- абстрактный интерфейс услуг связи;
	ASN.1	- абстрактная синтаксическая нотация версии 1;
	API	- интерфейс прикладной программы;
	CDC	- класс общих данных;
	DO	- объект данных;
	СТ	- трансформатор тока;
	IED	- интеллектуальное электронное устройство;
	LD	- логическое устройство;
	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 заключена в поддержке функций автоматизации подстанции посредством обеспечения (номера в скобках соответствуют номерам на рисунке):

- получения значений выборок от трансформаторов тока СТ и трансформаторов напряжения VT (1);

- скоростного обмена входными/выходными данными по защите и управлению (2);

- передачи сигналов управления и отключения (3);

- проектирования, разработки и конфигурирования (4);

- контроля и надзора (5);

- связи с центром управления (6);

- временной синхронизации;

- и т.д.

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

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

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

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


Группы логических узлов	Число логических узлов
Системные логические узлы	3
Функции защиты	28
Функции, связанные с защитой	10
Диспетчерское управление	5
Общие ссылки	3
Интерфейсы и архивирование	4
Автоматические средства управления	4
Учет электроэнергии и измерения	8
Датчики и мониторинг	4
Коммутационная аппаратура	2
Измерительный трансформатор	2
Силовой трансформатор	4
Другое оборудование энергосистемы	15
Общее количество логических узлов	92

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

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

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

- дистанционная защита;

- дифференциальная защита;

- максимальная токовая защита;

- защита от понижения напряжения;

- направленная защита от перегрузки;

- вольтгерцовое реле;

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

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

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

- схема защиты;

- защита от нулевой или пониженной частоты вращения;

- ...;

- измерение;

- учет электроэнергии;

- последовательность и дисбаланс;

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

- дифференциальные измерения;

- ...;

- управление переключениями;

- выключатель;

- прерыватель цепи;

- ...

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

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

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

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

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

Рисунок 4 - Принцип построения устройств

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

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

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

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

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

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

Рисунок 5 - Информация о положении, изображенная в виде дерева (концептуальное представление)

Рисунок 5 - Информация о положении, изображенная в виде дерева (концептуальное представление), лист 1

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

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

- управление (состояние, значения измерений/учета или настройки);

- подстановка;

- конфигурация, описание и расширение.

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

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

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

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

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

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


Имя атрибута	Тип атрибута	FC	TrgOp	Значение/диапазон значения	М/О/С
ctlVal	BOOLEAN	CO		выкл. (FALSE) \| вкл. (TRUE)	АС_СО_М
stVal	CODED ENUM	ST	dchg	промежуточное состояние \| выкл. \| вкл. \| неисправен	М

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

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

- по условиям инициирования выдачи отчета: TrgOp=dchg означает, что выдача отчета начинается при изменении значения данного атрибута;

- по значению или диапазону значения;

- по индикации, если атрибут опциональный (О), обязательный (М), условно обязательный (Х_Х_М) или условно опциональный (Х_Х_О). Эти условия - результат того, что не все атрибуты независимы друг от друга.

Имена атрибутов данных - это стандартизованные (т.е. зарезервированные) имена, имеющие специфическую семантику применительно к серии стандартов МЭК 61850. Семантика всех имен атрибутов данных определена в таблице 48 (раздел 8) МЭК 61850-7-3, например:


Имя атрибута данных	Семантика
ctlVal	Определяет управляющее действие
stVal	Значение состояния данных

Имена данных и атрибутов данных несут основную семантику IED-устройства подстанции.

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

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

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

- информация о состоянии;

- информация об измеряемом значении;

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

- информация об управляемом аналоговом значении;

- настройки состояния;

- настройки аналогового значения;

- описательная информация.

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

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

Рисунок 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].

Рисунок 7 - Пример отображения связи

Рисунок 7 - Пример отображения связи, лист 1

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

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

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

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

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

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

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

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

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

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

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

5.9 Заключение

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

- информационные модели системы автоматизации подстанции,

- методы обмена информацией,

- отображение на конкретные протоколы связи,

- конфигурацию IED-устройства подстанции.

Рисунок 8 - Резюмирующая информация

Указанные четыре компоновочных блока в большой степени независимы друг от друга. Данные информационные модели легко могут быть расширены путем определения новых логических узлов и новых данных в соответствии с особыми гибкими правилами - как это требуется в другой области применения. Таким же образом стеки связи могут обмениваться в соответствии с современными достижениями в технологии связи. Но для сохранения простоты взаимодействия в данный момент времени должен быть выбран только один стек. Описание такого выбора приведено в МЭК 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 - Процесс декомпозиции и композиции (концептуальное представление)

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

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

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

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

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

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


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

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

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

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

На рисунке 11 показаны примеры различных логических узлов, объединенных в IED-устройства. Задействованные логические узлы - это РТОС (максимальная токовая защита с выдержкой времени), PDIS (дистанционная защита), PTRC (формирование сигнала на отключение) и XCBR (выключатель). Вариант 1 показывает устройство защиты с двумя функциями, которое соединено с выключателем проводами. Вариант 2 показывает устройство защиты с двумя функциями, причем сигнал на отключение передается через сообщение об отключении по сети к LN выключателя. В варианте 3 эти две функции защиты находятся в выделенных устройствах, которые могут в случае отказа работать вместе, а сигналы на отключение передаются по сети независимо друг от друга как сообщения об отключении на LN выключателя (XCBR).

Рисунок 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 - Модель входа и выхода

Рисунок 12 - Модель входа и выхода, лист 1

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

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

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

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

Сервисы модели выхода могут воздействовать только на внутренний процесс, могут выдавать выходной сигнал в процесс через технологический интерфейс или могут изменять значение состояния атрибута данных, инициирующего выдачу отчета. Если технологический интерфейс является 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 - Модель выхода (этап 1) (концептуальное представление)

Рисунок 13 - Модель выхода (этап 1) (концептуальное представление), лист 1

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

Таблица 4 - Выборка настроек целочисленного состояния


Класс ING
Имя атрибута	Тип атрибута	FC	TrgOp	Значение/диапазон значения	M/O/C
...	...
Data Attribute
Настройка
setVal	INT32	SP			AC NSG M
setVal	INT32	SG, SE			AC_SG_M
Конфигурация, описание и расширение
minVal	INT32	CF			О
maxVal	INT32	CF			О
stepSize	INT32U	CF		1 ... (maxVal - minVal)	О
d	VISIBLE STRING255	DC		Текст	О
...	...	...			...

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

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

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

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

Концепция сбора входных аналоговых сигналов изображена на рисунке 17. Как правило, необработанный сигнал может преобразовываться формирователем сигнала. Для настоящей модели аналоговый входной сигнал не существует в виде данных, пока он не преобразован из аналоговой формы в цифровую. Частота опроса (атрибут данных smpRate конфигурируемых данных) определяет, с какой периодичностью следует проводить выборку этого значения. Условия, которые должны быть выполнены до того, как значение может быть передано (моделируемые как атрибут данных instMag этих данных, например, значение напряжения определенной фазы - рисунок 18), могут включать в себя значения следующих атрибутов:

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

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

- блокируемый или не блокируемый оператором "коммутатор".

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

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

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

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

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

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

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

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

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

Рисунок 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). Эта информация группируется с использованием набора данных. Набор данных является базисом содержимого для составления отчетов и регистрации. В наборе данных содержатся ссылки на значения данных и атрибутов данных.

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

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

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

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

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

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

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

- небуферизованные блоки управления;

- буферизованные блоки управления.

Модель журнала включает в себя журнал и блок управления журналом.

Принципиальные характеристики методов доступа к данным, обеспечиваемых МЭК 61850-7-2, представлены в таблице 5.

Таблица 5 - Сравнение методов доступа к данным


Метод поиска	Срочный обмен инфор- мацией	Возможность потери изменений (последова- тельности)	Возможность получения информации несколькими клиентами	Последнее изменение данных сохраняется на...	Типовой клиент (но не единственный)
Поллинг (GetDataValues)	НЕТ	ДА	ДА	-	Браузер
Небуферизованный отчет	ДА	ДА	НЕТ	-	GUI в реальном времени
Буферизованный отчет	ДА	НЕТ	НЕТ	Сервер	Концентратор данных

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

Группа П77

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

ОКС 33.200
ОКП 42 3200

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

Предисловие

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

Введение


Пользователь	МЭК 61850-1 (Вве- дение и краткий обзор)	МЭК 61850-5 (Тре- бова- ния)	МЭК 61850-7-1 (Прин- ципы)	МЭК 61850-7-4 (Логи- ческие узлы и классы дан- ных)	МЭК 61850-7-3 (Клас- сы общих данных)	МЭК 61850-7-2 (Инфор- мацион- ный обмен)	МЭК 61850-6 [1] (Язык конфи- гурации)	МЭК 61850-8-1 [2] МЭК 61850-9-1 [3], МЭК 61850-9-2 [4] (Кон- кретный стек связи)
Пред- прия- тие	Руководитель	X	-	Раздел 5	-	-	-	-	-
	Инженер	X	X	X	X	X	Фрагменты	X	-
Пос- тав- щик	Специалист по прикладной области	X	X	X	X	X	Фрагменты	X	Фрагменты
	Специалист по связи	X	X	X	-	-	X	-	X
	Менеджер по продукции	X	X	X	X	Фрагменты	Фрагменты	Фрагменты	-
	Специалист по маркетингу	X	X	Раздел 5	Фрагменты	Фрагменты	Фрагменты	Фрагменты	-
Кон- суль- тант	Специалист по прикладной области	X	X	X	X	X	-	X	-
	Специалист по связи	X	-	X	-	-	X	X	X
Другое	X	X	X	-	-	-	-	-
Символ "X" означает, что с содержанием настоящего стандарта следует ознакомиться. "Фрагменты" означает, что для понимания применяемого концептуального подхода следует ознакомиться с фрагментами настоящего стандарта. Прочерк (-) означает, что ознакомление с настоящим стандартом факультативно.

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

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

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

4 Сокращения


	ACSI	- абстрактный интерфейс услуг связи;
	ASN.1	- абстрактная синтаксическая нотация версии 1;
	API	- интерфейс прикладной программы;
	CDC	- класс общих данных;
	DO	- объект данных;
	СТ	- трансформатор тока;
	IED	- интеллектуальное электронное устройство;
	LD	- логическое устройство;
	LN	- логический узел;
	LLN0	- нуль логического узла (0);
	LPHD	- физическое устройство логического узла;
	MMS	- спецификация производственных сообщений;
	PHD	- физическое устройство;
	PICOM	- единица передаваемой информации;
	SCSM	- специфическое отображение сервиса связи;
	SoE	- последовательность событий;
	UML	- универсальный язык моделирования;
	VMD	- виртуальное производственное устройство (Virtual Manufacturing Device);
	VT	- трансформатор напряжения;
	XML	- расширенный язык разметки.

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

5.1 Цель

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

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

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

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

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


Группы логических узлов	Число логических узлов
Системные логические узлы	3
Функции защиты	28
Функции, связанные с защитой	10
Диспетчерское управление	5
Общие ссылки	3
Интерфейсы и архивирование	4
Автоматические средства управления	4
Учет электроэнергии и измерения	8
Датчики и мониторинг	4
Коммутационная аппаратура	2
Измерительный трансформатор	2
Силовой трансформатор	4
Другое оборудование энергосистемы	15
Общее количество логических узлов	92

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

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

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

Рисунок 4 - Принцип построения устройств

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

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

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

Рисунок 5 - Информация о положении, изображенная в виде дерева (концептуальное представление)

Рисунок 5 - Информация о положении, изображенная в виде дерева (концептуальное представление), лист 1

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


Имя атрибута	Тип атрибута	FC	TrgOp	Значение/диапазон значения	М/О/С
ctlVal	BOOLEAN	CO		выкл. (FALSE) \| вкл. (TRUE)	АС_СО_М
stVal	CODED ENUM	ST	dchg	промежуточное состояние \| выкл. \| вкл. \| неисправен	М


Имя атрибута данных	Семантика
ctlVal	Определяет управляющее действие
stVal	Значение состояния данных

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

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

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

Рисунок 7 - Пример отображения связи

Рисунок 7 - Пример отображения связи, лист 1

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

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

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

5.9 Заключение

Рисунок 8 - Резюмирующая информация

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

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

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

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

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

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

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


Общая информация логического узла	Общая информация логического узла
Режим	Состояние внешнего оборудования
Режим работы	Паспортная табличка внешнего оборудования
Состояние (исправность)	Объекты управления
Паспортная табличка	Положение переключателя (подробнее см. ниже)
Опциональная информация логического узла	Блокировка отключения
Логическая операция	Блокировка включения
Состояние внешнего оборудования	Двигатель устройства завода пружин в действии
Паспортная табличка внешнего оборудования	Измеренные значения
Счетчик операций (со сбросом)	Суммарное значение скоммутированных токов (со сбросом)
Счетчик операций	Информация о состоянии
Время срабатывания	Рабочие характеристики выключателя
Локальная операция ("локальная" означает без связи с автоматикой подстанции, прямое проводное управление)	Возможность определения фазы точки переключения
Счетчик операций	Рабочие характеристики выключателя при полном заводе (пружин, грузов)

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


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

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

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

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

Рисунок 12 - Модель входа и выхода

Рисунок 12 - Модель входа и выхода, лист 1

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

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

Рисунок 13 - Модель выхода (этап 1) (концептуальное представление)

Рисунок 13 - Модель выхода (этап 1) (концептуальное представление), лист 1

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

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

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

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


Класс ING
Имя атрибута	Тип атрибута	FC	TrgOp	Значение/диапазон значения	M/O/C
...	...
Data Attribute
Настройка
setVal	INT32	SP			AC NSG M
setVal	INT32	SG, SE			AC_SG_M
Конфигурация, описание и расширение
minVal	INT32	CF			О
maxVal	INT32	CF			О
stepSize	INT32U	CF		1 ... (maxVal - minVal)	О
d	VISIBLE STRING255	DC		Текст	О
...	...	...			...

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

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

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

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

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

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

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

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

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

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

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

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


Метод поиска	Срочный обмен инфор- мацией	Возможность потери изменений (последова- тельности)	Возможность получения информации несколькими клиентами	Последнее изменение данных сохраняется на...	Типовой клиент (но не единственный)
Поллинг (GetDataValues)	НЕТ	ДА	ДА	-	Браузер
Небуферизованный отчет	ДА	ДА	НЕТ	-	GUI в реальном времени
Буферизованный отчет	ДА	НЕТ	НЕТ	Сервер	Концентратор данных

Журнал (используется для SoE регистрации)

НЕТ

ДА

Клиент

Рабочие станции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- временная метка отчета для информирования клиента о времени выдачи отчета;

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

- имя набора данных для указания, из какого набора данных были сгенерированы значения;

- ссылка на данные для включения объектных ссылок для значений;

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

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

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

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

GI - (общий опрос): инициированная клиентом выдача отчетов по всем значениям;

PurgeBuf - установленный на TRUE, указывает на удаление всех еще не посланных событий.

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

Рисунок 24 - Буферное время

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

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

Рисунок 25 - Элементы набора данных и включение битовой строки

Рисунок 25 - Элементы набора данных и включение битовой строки, лист 1

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

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

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

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

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

Рисунок 26 - Блок управления журналом (концептуальное представление)

Рисунок 26 - Блок управления журналом (концептуальное представление), лист 1

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

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

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

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

Рисунок 27 - Одноранговая модель публикации значений данных (концептуальное представление)

Модель 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", другой может выбрать "СВK-2". МЭК 61850-7-4, основанный на подходе, описанном в МЭК 61850-5, стандартизует множество сокращенных наименований функций подстанции и связанного с ней оборудования. Стандартизованное наименование для выключателя - XCBR. Это наименование может сопровождаться суффиксом и префиксом: Q1XCBR1 [соглашения в отношении присваивания имен см. в 13.4, А.2, А.3 (приложение А) и МЭК 61850-7-2].

Приложениям в компьютере (c левой стороны рисунка 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]).

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

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

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

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

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

Рисунок 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), "Максимальная токовая защита с выдержкой времени" (РТОС), а также с функцией "Формирование сигнала на отключение" (PTRC). Связанные с этим технологические данные, основные функции и другие важные составляющие элемента присоединения моделируются как данные в древовидной структуре. Каждый элемент этого дерева является данными: данными на верхнем уровне является Bay Unit ("Элемент присоединения"), включающий в себя Distance protection ("Дистанционную защиту"), Time Overcurrent ("Максимальную токовую защиту с выдержкой времени") и Trip conditioning ("Формирование сигнала на отключение"). Distance protection содержит, например, данные Start ("Старт", Str) с различными атрибутами, такими как general (общий) и "Фаза A" (phsA).

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

Рисунок 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. Группирование логических узлов в логические устройства основано на общих характеристиках этих логических узлов. Например, включение и выключение режимов этих узлов должны быть, как правило, совместными или тестовыми.

Рисунок 34 - Компоновочный блок логического устройства

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

Рисунок 34 - Компоновочный блок логического устройства

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

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

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

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

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

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

Рисунок 36 - Логические устройства в посреднических устройствах или шлюзах

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

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

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

LD0 может содержать специфические логические узлы данного домена.

Системы связи рассмотрены в основном в прикладном и аппаратном представлениях. С другой стороны, система связи, устройства и приложение тесно взаимосвязаны. В разделе 9 показаны модели связи, после чего рассмотрены взаимоотношения между этими представлениями.

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

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

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

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

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

Таблица 6 - Модели и сервисы ACSI


Модель сервиса	Описание	Сервисы
Сервер	Представляет внешний видимый режим работы устройства. Все остальные модели ACSI являются частью сервера	ServerDirectory
Прикладная ассоциация	Условие соединения двух или более устройств. Обеспечивает различные представления устройства: ограниченный доступ к информации и функциям сервера	Associate Abort Release
Логическое устройство	Представляет группу функций, каждая функция определяется в виде логического узла	LogicalDeviceDirectory GetAIIDataValues
Логический узел	Представляет специфическую функцию системы подстанции, например защита от перенапряжений	LogicalNodeDirectory
Данные	Предоставляет средства определения печатной информации, например положение переключателя с информацией о качестве, и временную метку	GetDataValues SetDataValues GetDataDefinition GetDataDirectory
Набор данных	Позволяет группировать вместе различные данные	GetDataSetValue SetDataSetValue CreateDataSet DeleteDataSet GetDataSetDirectory
Подстановка	Клиент может запросить сервер заменить технологическое значение значением, заданным клиентом, например в случае неправильного значения измерений	SetDataValues
Управление группой настроек	Определяет, как выполнять переключение с одного набора заданных значений на другой и как редактировать группы настроек	SelectActiveSG SelectEditSG SetSGValues ConfirmEditSGValues GetSGValues GetSGCBValues
Отчеты и регистрация	Описывает условия создания отчетов и журналов на основании параметров, заданных клиентом. Выдача отчетов может запускаться изменениями в значениях технологических данных (например, изменение состояния или зона нечувствительности) или при изменении качества. Возможны запросы для последующего поиска журналов. Рассылка отчетов может быть выполнена немедленно или отсрочена (отложена). Отчеты обеспечивают обмен информацией по изменению состояния и по последовательности событий	Блок управления буферизованным отчетом: Report GetBRCBValues SetBRCBValues Блок управления небуферизованным отчетом: Report GetURCBValues SetURCBValues Блок управления (СВ) журналом: GetLCBValues SetLCBValues Журнал: QueryLogByTime QueryLogAfter GetLogStatusValues
Общее событие на подстанции (GSE)	Обеспечивает быстрое и надежное распределение данных во всей системе; одноранговый обмен информацией о двоичном состоянии IED-устройства. GOOSE означает объектно-ориентированное событие на станции и поддерживает обмен широким диапазоном возможных общих данных, организованных в DATA-SET (набор данных). GSSE означает общее событие состояния на подстанции и обеспечивает передачу информации об изменении состояния (бит-пары)	GOOSE СВ: SendGOOSEMessage GetGoReference GetGOOSEEIementNumber GetGoCBValues SetGoCBValues GSSE CB: SendGSSEMessage GetGsReference GetGSSEEIementNumber GetGsCBValues SetGsCBValues
Передача выборочных значений	Быстрая и циклическая передача выборочных значений, например измерительных трансфоматоров	Multicast SVC: SendMSVMessage GetMSVCBValues SetMSVCBValues Unicast SVC: SendUSVMessage GetUSVCBValues SetUSVCBValues
Управление	Описывает сервисы для управления, например, устройствами или группами настроек параметров	Select SelectWithValue Cancel Operate CommandTermination TimeActivatedOperate
Время и временная синхронизация	Обеспечивает временную ось для устройства и системы	Сервисы в SCSM
Передача файлов	Определяет обмен крупными блоками данных, такими как программы	GetFile SetFile DeleteFile GetFileAttributeValues

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) был сконфигурирован на получение сообщения на отключение. После дополнительной обработки коммутационная аппаратура отключает выключатель.

3) Информация о состоянии "нуля выключателя" (XCBR0.Pos.stVal) изменяется с ON (ВКЛ.) на OFF (ВЫКЛ.). Информация об этом новом состоянии немедленно отправляется сообщением GOOSE с указанием: <новое положение переключателя = выключен>. Кроме того, модель выдачи отчетов может послать отчет о данном изменении.

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

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

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

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

9.4.1 Сервер

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

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

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

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

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

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

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

Рисунок 44 - Пример сервиса

Рисунок 44 - Пример сервиса, лист 1

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

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

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

Рисунок 45 - Клиент - сервер и логические узлы

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

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

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

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

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

Рисунок 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 - Интерфейсы внутри и между устройствами

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

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

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

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

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

Рисунок 49 - Иерархия компонентов в различных представлениях (выдержка)

Рисунок 49 - Иерархия компонентов в различных представлениях (выдержка), лист 1

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

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

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

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

c) SCSM отображает представление серии стандартов МЭК 61850 на видимые объекты сети связи;

d) сервер, SCSM и прикладное функциональное представление отображаются на ресурс физического устройства.

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

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

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

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

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

Классы общих данных основаны на классах DATA. В средней части рисунка показан пример класса общих данных INS (целочисленное состояние) как уточнение класса DATA. INS уточняет DataAttributes, которые не были заполнены в МЭК 61850-7-2. Определены четыре атрибута: stVal (значение состояния), q (качество), t (временная метка) и d (описание). Это общее определение используется во многих определениях данных в МЭК 61850-7-4.

Пока экземпляр класса DATA не дает достаточного представления о его использовании или о семантике атрибутов данных, производных от INS. Класс, изображенный справа на рисунке 50 (взятом из МЭК 61850-7-4), определяет именно это "использование". Класс Health определяет имя Health. Данное имя будет использовано во всех экземплярах, производных от этого класса. Кроме того, значение состояния stVal определено как имеющее три значения: Ok (=1), Warning (=2) и Alarm (=3).

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

Окончательное определение того, что в действительности означают имена Ok, Warning и Alarm, зависит от контекста, в котором данный класс используется. В выключателе это значение может несколько отличаться от значения в измерительном устройстве.

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

В таблице 7 показан пример перечня классов DATA для выключателя. Имя класса выключателя - XCBR. Классы DATA, которые составляют выключатель, сгруппированы в три категории (основная информация LN, управляемые данные и информация о состоянии). В каждую категорию входят некоторые классы DATA, например Mode и Switch position. К этим классам DATA возможно обращение по их DataName: Mode и Pos. Кроме того, каждый класс DATA имеет класс общих данных, определяющий подробную информацию, т.е. ATTRIBUTES класса DATA. В последней колонке показано, относится ли этот класс к обязательному (М) или опциональному (О).

Таблица 7 - Логический узел "Выключатель"


Логический узел: "Выключатель"	Имя: XCBR
Класс данных	DataName	Класс общих данных (CDC)	М/О
Основная информация логического узла
Режим	Mod	INC - управляемое целочисленное состояние	М
Режим работы	Beh	INS - целочисленное состояние	М
Состояние	Health	INS - целочисленное состояние	М
Паспортная табличка	NamPIt	LPL - паспортная табличка логического узла	М
Локальная операция ("локальная" означает без связи с автоматикой подстанции, прямое проводное управление)	Loc	SPS - состояние одноэлементного управления
Состояние внешнего оборудования	EEHealth	INS - целочисленное состояние
Паспортная табличка внешнего оборудования	EEName	DPL - паспортная табличка устройства
Счетчик операции	OpCnt	INS - целочисленное состояние
Управляемые данные
Положение переключателя	Pos	DPC - двухэлементное управление	М
Открытие блока	BlkOpn	SPC - одноэлементное управление	М
Закрытие блока	BlkCIs	SPC - одноэлементное управление	М
Двигатель устройства взвода включен	ChMotEna	SPC - одноэлементное управление	О
Измеренные значения
Суммарное значение коммутируемого тока, восстанавливаемое	SumSwARs	BCR - показания двоичного счетчика	О
Информация о состоянии
Рабочие характеристики выключателя	CBOpCap	INS - целочисленное состояние	М
Возможность определения фазы точки переключения	POWCap	INS - целочисленное состояние	О
Рабочие характеристики выключателя при полном взводе	MaxOpCap	INS - целочисленное состояние	О

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

Таблица 8 - Двухэлементное управление (DPC)


DPC класс
Имя атрибута	Тип атрибута	FC	TrgOp	Значение/диапазон значения	М/О/С
DataName	Наследуемый из класса данных (см. МЭК 61850-7-2)
DataAttribute
Управление и состояние
ctlVal	BOOLEAN	CO		выкл. (FALSE) \| вкл. (TRUE)	АС_СО_М
operTim	TimeStamp	CO			АС_СО_О
origin	Источник сообщения	CO, ST			АС_СО_О
ctlNum	INT8U	CO, ST		0..255	АС_СО_О
stVal	CODED ENUM	ST	dchg	промежуточное состояние \| выкл. \| вкл. \| неисправен	М
q	Качество	ST	qchg		М
t	TimeStamp	ST			М
stSeld	BOOLEAN	ST	dchg		АС_СО_О
Подстановка
subEna	BOOLEAN	SV			PICS_SUBST
subVal	CODED ENUM	SV		промежуточное состояние \| выкл. \| вкл. \| неисправен	PICS_SUBST
subQ	Качество	SV			PICS_SUBST
subID	VISIBLE STRING255	SV			PICS_SUBST
Конфигурация, описание и расширение
pulseConfig	PulseConfig	CF			AC_CO_О
ctlModel	CtlModels	CF			M
sboTimeout	INT32U	CF			AC_CO_О
sboClass	SboClasses	CF			AC_CO_О
d	VISIBLE STRING255	DC			О
cdcNs	VISIBLE STRING255	EX		Текст	AC_DLNDA_M
cdcName	VISIBLE STRING255	EX			AC_DLNDA_M
dataNs	VISIBLE STRING255	EX			AC_DLN_M
Сервисы
...

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

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

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

Рисунок 51 - Экземпляры класса DATA (концептуальное представление)

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

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


Сокращение	Условие
М	Атрибут обязательный
О	Атрибут опциональный
PICS SUBST	Атрибут является обязательным, если поддерживается подстановка (подстановка описана в МЭК 61850-7-2)
AC_DLN_M	Применительно к dataNs во всех CDC, dataNs должны присутствовать, если пространство имен DATA является производным от пространства имен, определенного в IdNs/lnNs.
AC_DLNDA_M	Этот атрибут должен присутствовать, если пространство имен CDC является производным или от пространства имен, определенного в IdNs/lnNs, или от пространства имен, определенного в dataNs, или в них обоих
АС_СО_М	Этот атрибут является обязательным, если класс управляемого состояния поддерживает управление
АС_СО_О	Этот атрибут является опциональным, если класс управляемого состояния поддерживает управление
...	...

Все 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 - Взаимосвязь между частями стандартов МЭК серии 61850

Рисунок 52 - Взаимосвязь между частями стандартов МЭК серии 61850, лист 1

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

Класс общих данных DPC включает в себя рассчитанный на многократное использование перечень атрибутов, таких как управляемое значение (значение, которое может быть изменено в результате управления со), значение состояния, качественная или временная метка (значения, которые могут быть включены в отчет 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 Введение

На рисунке 53 отображено взаимодействие ACSI с базовым уровнем приложения. ACSI не определяет конкретных ACSI сообщений. Сервисы ACSI отображены в последовательность одного или более сообщения нижележащего прикладного уровня (AL PDU - блок данных протокола).

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

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-7-4, МЭК 61850-7-3 и МЭК 61850-7-2 определяют абстрактную информацию и модели сервисов для подстанции. При этом серия стандартов МЭК 61850, в общем, позволяет отдельным устройствам работать с использованием одних и тех же данных и сервисов. Для обеспечения этого указанные устройства должны быть согласованы по конкретной форме сервисов и данных, которые будут участвовать в обмене.

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

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

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

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

Стандартизованные отображения абстрактных сервисов на различные стеки связи определены в МЭК 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).

Рисунок 55 - Отображение ACSI на стеки связи/профили

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

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

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).

Рисунок 56 - Отображение на MMS (концептуальное представление)

Рисунок 56 - Отображение на MMS (концептуальное представление), лист 1

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

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

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


Что должно отображаться?	Отображается на
Логическое устройство (содержит логические узлы); МЭК 61850-7-2	Домен MMS
Логические узлы (содержат данные); МЭК 61850-7-4	Поименованную переменную MMS
Данные; МЭК 61850-7-4	Поименованную переменную MMS (и структурированные компоненты поименованной переменной, представляющие "данные логического узла")
Атрибут данных; МЭК 61850-7-3	Поименованную переменную MMS (и структурированные компоненты поименованной переменной, представляющие эти "данные")
Набор данных: МЭК 61850-7-2	Список поименованных переменных MMS
Блоки управления (атрибуты); МЭК 61850-7-2	Поименованную переменную MMS
Блоки управления (режим работы); МЭК 61850-7-2	Необходимо программировать, как определено в МЭК 61850-7-2
Журнал; МЭК 61850-7-2	Журнал MMS

Сообщения, несущие информацию, отображаются на MMS сообщения, за исключением сообщений GOOSE, GSSE и SV.

Рисунок 57 - Подход к отображению

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

Рисунок 57 - Подход к отображению

Подробнее отображение в поименованную переменную MMS схематически показано на рисунке 58.

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

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

Рисунок 59 - Пример поименованной переменной MMS (технологические значения)

Технологические значения (о положении) нескольких контроллеров переключателя Q0CSWI$Pos, Q1CSWI$Pos и Q2CSWI$Pos отображаются в поименованных переменных MMS (см. правый нижний угол рисунка 60). Информация о положении группируется по списку поименованных переменных (набору данных) с именем K03/LLN0$AIIRpts. Атрибуты блока управления небуферизованного отчета отображаются в поименованной переменной MMS K03/LLN0$RP$AIIRpts. Компоненты этой поименованной переменной могут быть записаны (конфигурированы). Блок управления ссылается на набор данных.

Рисунок 60 - Использование поименованных переменных MMS и списка поименованных переменных

Изменение в одном из членов набора данных (например, во втором члене) приводит к отправке отчета с состоянием положения Q2CSWI. Сообщение с отчетом генерируется с использованием другого списка поименованных переменных MMS (левый нижний угол рисунка 60). Отчет будет послан немедленно.

Отчет отображается в информационном отчете MMS (см. рисунок 61). На рисунке показано конкретное кодирование согласно ASN.1 BER (основные правила кодирования для абстрактной синтаксической нотации версии 1 - ИСО 8825).

Рисунок 61 - Информационное сообщение с отчетом по MMS

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

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

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

На рисунке 62 показана выдержка из модели XCBR1, представляющая физическое устройство. Полная иерархическая модель может быть отображена, например, на MMS с использованием SCSM в соответствии с МЭК 61850-8-1 [2]. В результате многие поименованные переменные MMS должны быть реализованы в реальном сервере. Сервисы ACSI отображаются на сервисы MMS.

Рисунок 62 - Пример отображения

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

Примечание 2 - Это множественное отображение не требует множественного сохранения одного значения (например, для ctlVal). Дерево со всеми компонентами и подкомпонентами реализуется однократно. Поименованная переменная XCBR1$Pos$ctlVal - только "адрес" листа этого дерева.

Сервисы MMS поддерживают чтение в одном запросе многих "полных" или частичных "деревьев". Частичное дерево должно быть описано в сообщении запроса с чередованием доступа MMS.

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

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

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

Таблица 9 - Определение класса ACSI


Класс ABC
Имя атрибута	Тип атрибута	Значение/диапазон значения/пояснение
Attribute1 [1..n]	Туре1
Attribute2 [0..n]	Туре2
Сервисы Service1 Service2

Имя класса в эти таблицы следует вписывать ЗАГЛАВНЫМИ буквами шрифтом Tahoma. Атрибуты класса должны иметь имя атрибута и тип атрибута. Атрибуты должны иметь следующую кратность:

[0..n] - атрибут может появляться ноль - n раз;

[1..n] - атрибут может появляться один - n раз;

[0..1] - атрибут может появляться ноль - 1 раз.

Примечание - Кратность параметра сервиса (в таблицах сервиса) использует тот же синтаксис.

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

В тексте все имена классов должны быть введены полужирным шрифтом Tahoma ЗАГЛАВНЫМИ буквами (например, LOGICAL-NODE) для того, чтобы различать "обычный" текст и стандартизованные (зарезервированные) имена. Кроме того, другие ключевые слова, такие как имена атрибутов и т.п., должны быть выделены полужирным шрифтом Tahoma (например, LNRef).

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

13.2.1 Обзор

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

На рисунке 63 изображена модель класса серии стандартов МЭК 61850-7. Использованы обозначения из унифицированного языка моделирования UML. В качестве основного элемента использовано "объединение" (черный ромб), показывающее, что, например, класс сервера состоит из (от 1 до n) классов логических устройств. Классы логических устройств включают в себя множество классов логических узлов (*). Логические узлы являются специализациями класса логических узлов, расположенного слева (показано незакрашенной стрелкой), например PDIS или XCBR, как определено в МЭК 61850-7-4. Классы логических узлов включают в себя множество классов данных. Классы данных являются специализациями класса DATA, например: MDD - специализированный класс SPS, POS - специализированный класс DPC. Наконец, классы общих данных, например DPC, состоят из (от 1 до n) атрибутов данных.

Рисунок 63 - Пример модели абстрактных данных для МЭК 61850-7

Рисунок 63 - Пример модели абстрактных данных для МЭК 61850-7, лист 1

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

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

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

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

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

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

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

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


Класс SPS
Имя атрибута	Тип атрибута	FC	TrgOp	Значение/диапазон значения	M/O/C
DataName	Наследуется из класса данных (см. МЭК 61850-7-2)
DataAttribute
Состояние
stVal	BOOLEAN	ST	dchg	TRUE \| FALSE	M
q	Качество	ST	qchg		M
t	TimeStamp	ST			M
Подстановка
subEna	BOOLEAN	SV			PICS_SUBST
subVal	BOOLEAN	SV		TRUE \| FALSE	PICS_SUBST
subQ	Качество	SV			PICS_SUBST
subID	VISIBLE STRING255	SV			PICS_SUBST
Конфигурация, описание и расширение
d	VISIBLE STRING255	DC		Текст	О
cdcNs	VISIBLE STRING255	EX			AC_DLNDA_M
cdcName	VISIBLE STRING255	EX			AC_DLNDA_M
dataNs	VISIBLE STRING255	EX			AC_DLN_M
Сервисы
Как определено в таблице 12

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

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

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

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


Определение типа Quality
Имя атрибута	Тип атрибута	Значение/диапазон значения	M/O/C
		PACKED LIST
	validity	CODED ENUM	good \| invalid \| reserved \| questionable	M
	detailQual	PACKED LIST		M
		overflow	BOOLEAN		M
		outOfRange	BOOLEAN		M
		badReference	BOOLEAN		M
		oscillatory	BOOLEAN		M
		failure	BOOLEAN		M
		oldData	BOOLEAN		M
		inconsistent	BOOLEAN		M
		inaccurate	BOOLEAN		M
	source	CODED ENUM	process \| substituted DEFAULT process	M
	test	BOOLEAN	DEFAULT FALSE	M
	operatorBlocked	BOOLEAN	DEFAULT FALSE	M

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

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


Базовый шаблон информации о состоянии
Сервисы (см. МЭК 61850-7-2)
Следующие сервисы наследуются из МЭК 61850-7-2. Они специализированы через ограничение сервиса для атрибутов с функциональной связью, как описано ниже.
Модель сервиса МЭК 61850-7-2	Сервис	Сервис применим к атрибутам с FC	Примечание
Модель данных	SetDataValues	DC, CF, SV
	GetDataValues	ALL
	GetDataDefinition	ALL
Модель набора данных	GetDataSetValues	ALL
	SetDataSetValues	DC, CF, SV
Модель выдачи отчетов	Report	ALL	Как описано в наборе данных, который используется для определения содержимого отчета

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

GetDataValues;

GetDataDefinition;

GetDataSetValues;

Report.

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

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

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


TrgOp	Семантика	Разрешенные сервисы
dchg	Изменение данных	Отчет или запись в журнале должна быть создана вследствие изменения значения атрибута данных
qchg	Изменение качества	Отчет или запись в журнале должна быть создана вследствие изменения значения атрибута качества
dupd	Обновление значения данных	Отчет или запись в журнале должна быть создана вследствие фиксирования значения фиксируемого атрибута или обновления значения любого другого атрибута. Обновленное значение может совпадать с предыдущим
Пустое поле	Если поле пустое, то приложение может использовать опцию dchg или dupd для запуска отчетов или регистраций	См. для dchg или dupd соответственно

Как изображено на рисунке 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)


Класс LOGICAL-NODE
Имя атрибута	Тип атрибута	Пояснение
LNName	ObjectName	Имя экземпляра, принадлежащее экземпляру класса LOGICAL-NODE
LNRef	ObjectReference	Имя пути, принадлежащее экземпляру класса LOGICAL-NODE
Data [1 to n]	DATA
DataSet [0 to n]	DATA-SET
BufferedReportControlBlock [0 to n]	BRCB
UnbufferedReportControlBlock [0 to n]	URCB
LogControlBlock [0 to n]	LCB
Если совместимый класс LN, определенный в МЭК 61850-7-4, равен LLN0
SettingGroupControlBlock [0 to 1]	SGCB
Log [0 to 1]	LOG
GOOSEControlBlock [0 to n]	GoCB
GSSEControlBlock [0 to n]	GsCB
MulticastSampledValueControlBlock [0 to n]	MSVCB
UnicastSampledValueControlBlock [0 to n]	USVCB
Сервисы GetLogicalNodeDirectory GetAIIDataValues

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

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

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

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

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

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

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

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

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

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

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

Имя параметра

Запрос

Параметр 1...

Параметр n

Ответ +

Параметр 1...

Параметр n

Ответ -

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

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

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

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

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

Рисунок 66 - Ссылки

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

Имя логического узла 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.


<Substation Ref="AB">
	<VoltageLevelRef="E1">
		<Bay Ref="Q1">
			<Device Ref="QA1" Type="CBR">
				<Connection TNodeRef="L17> <LNode Ref="XCBR1" LNCIass="XCBR7>
			</Device> <Device Ref="QB1"Type="DIS">
				<Connection TNodeRef="L17> <LNode Ref="XSWI2" LNCIass="XSWI7>
			</Device>
		</Bay>
	</VoltageLevel>
</Substation>

Ссылка логического узла может быть выражена в виде: 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 - Имена объекта и ссылка объекта

Рисунок 68 - Имена объекта и ссылка объекта, лист 1

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

Все остальные примеры относятся только к экземплярам.

Имя LD E1.QA5 и его структура выходят за область применения серии стандартов МЭК 61850. Функциональная связь (FC) в объектной ссылке не показана. Информация FC может отображаться в объектную ссылку в SCSM. МЭК 61850-8-1 [2] отображает FC между именем логического узла и именем данных (XCBR.CO.Pos).

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, показан в правой части рисунка 71. Пример дополнительного пространства имен показан в левой части.

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

Рисунок 72 - Все экземпляры, полученные из классов в единственном пространстве имен

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

Рисунок 73 - Экземпляры, полученные из нескольких пространств имен

Рисунок 73 - Экземпляры, полученные из нескольких пространств имен, лист 1

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

Логический узел в нижней части рисунка получен из другой спецификации. Это необходимо указать, используя вместе со значением явно выраженное пространство имен логического узла InNs, например "Другая спецификация: год публикации". Экземпляры, изображенные под этим логическим узлом, определяют в пространстве имен. Экземпляры данных имеют неявно выраженное то же самое пространство имен. Третье используемое пространство имен - это частное пространство имен: LnNs со значением "Производитель ABC".

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

Рисунок 74 - Наследованные пространства имен

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

14.3 Спецификация пространств имен

14.3.1 Общее

Следующие три пространства имен необходимо определить для того, чтобы получить достаточную информацию для возможности однозначной интерпретации экземпляров классов LOGICAL-NODE, DATA, DATA-SET и различных блоков управления, например BRCB:

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

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

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

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

имя нового пространства имен > имя базового пространства имен > ...> ...

Символ ">" будет зарезервированным символом, обозначающим специализацию.

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

14.3.2 Определение пространства имен логического узла

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

В случае серии стандартов МЭК 61850 пространство имен логического узла содержит следующие спецификации:

МЭК 61850-7-4 (LOGICAL-NODE, например, MMXU, и DATA, например, PhV, A, W, PF);

МЭК 61850-7-3 (общие DATA классы, например, WYE для PhV) через ссылку;

МЭК 61850-7-2 (все классы) через ссылку,

включая год издания.

Пример пространств имен логического узла и данных показан на рисунке 75.

Рисунок 75 - Пример пространств имен логического узла и данных

Рисунок 75 - Пример пространств имен логического узла и данных, лист 1

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

Пространство имен логического узла должно содержать имя LOGICAL-NODE и DATA, которые являются частью LOGICAL-NODE.

14.3.3 Определение пространства имен данных

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

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

МЭК 61850-7-4 (DATA, например, PhV, A, W, PF);

МЭК 61850-7-3 (общие классы DATA, например, WYE для PhV) через ссылку;

МЭК 61850-7-2 (все классы) через ссылку, включая год издания.

Пространство имен данных содержит имя DATA и класс общих данных, который должен быть использован для создания DataAttributes экземпляра DATA.

14.3.4 Определение пространства имен класса общих данных

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

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

МЭК 61850-7-3 (общие DATA классы, например, WYE с DataAttributes, например, ctlVal, q, PhsA) через ссылку;

МЭК 61850-7-2 (все классы) через ссылку, включая год издания.

Пример пространств имен класса общих данных показан на рисунке 76.

Рисунок 76 - Пример пространств имен класса общих данных

Пространство имен класса общих данных должно содержать имена класса общих данных и DataAttributes, например ctlVal, q и PhsA, которые будут использованы для создания DataAttributes экземпляра DATA.

14.4 Атрибуты для ссылок на пространства имен

14.4.1 Общее

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

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

2) Атрибут пространства имен логического узла (InNs) будет содержать ссылку на пространство имен логического узла единичного экземпляра LOGICAL-NODE.

3) Атрибут пространства имен данных (dataNs) будет содержать ссылку на пространство имен данных единичного экземпляра DATA.

4) Атрибут пространства имен класса общих данных (cdcNs) будет содержать ссылку на пространство имен CDC для CDC, используемые для определения единичного экземпляра DATA.

Классы общих данных содержат DataAttributes IdNs и InNs, как показано в таблице 15.

Примечание 1 - Условия в последней колонке таблицы 15 определены в МЭК 61850-7-3.

Таблица 15 - Выдержка из класса общих данных паспортной таблички логического узла (LPL)


Класс LPL
Имя атрибута	Тип атрибута	FC	TrgOp	Значение/диапазон значения	М/О/С
DataName	Наследуется из класса данных (см. МЭК 61850-7-2)
DataAttribute
Конфигурация, описание и расширение
...	...	...	...	...
IdNs	VISIBLE STRING255	EX		Должен быть включен только в LLN0, например, МЭК 61850-7-4:2003	AC_LN0_M
InNs	VISIBLE STRING255	EX			AC_DLD_M

Классы общих данных содержат DataAttributes cdcNs и dataNs, как показано в таблице 16.

Таблица 16 - Выдержка из класса общих данных


Применяется всеми классами общих данных
Имя атрибута	Тип атрибута	FC	TrgOp	Значение/диапазон значения	М/О/С
DataName	Наследуется из класса данных (см. МЭК 61850-7-2)
DataAttribute
...	...	...	...	...
Конфигурация, описание и расширение
cdcNs	VISIBLE STRING255	EX			AC_DLNDA_M
dataNs	VISIBLE STRING255	EX			AC_DLN_M

Примечание 2 - Условия в последней колонке таблицы 16 определены в МЭК 61850-7-3.

14.4.2 Атрибут для пространства имен логического устройства (IdNs)

В серии стандартов МЭК 61850 не определены типовые логические устройства, т.е. не приведено никакого имени логического устройства. Для указания того, какая техническая спецификация была использована в качестве первичного пространства имен для всего логического устройства, необходимо использовать DataAttribute пространства имен логического устройства IdNs. Если пространства имен базового логического узла идентичны пространству имен, заключенному в IdNs, то нет необходимости заключать пространство имен логического узла в отдельные логические узлы.

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

Атрибут IdNs должен быть DataAttribute паспортной таблички NamPIt LOGICAL-NODE-ZERO (LLN0). Атрибут IdNs должен быть таким, как это определено в общем классе DATA паспортной таблички логического узла LPL в МЭК 61850-7-3.

При использовании первого издания серии стандартов МЭК 61850-7 в качестве первичного пространства имен это значение следует определять как МЭК 61850-7-4:2003.

Атрибут IdNs должен быть доступен в каждом LOGICAL-NODE-ZERO (LLN0).

ObjectReference (объектная ссылка) для DataAttribute IdNs должна быть следующей:

LDName/LLN0.NamPlt.ldNs

14.4.3 Атрибут для пространства имен логического узла (InNs)

Для указания того, какая техническая спецификация была использована в качестве пространства имен для конкретного логического узла, необходимо использовать DataAttribute пространства имен логического узла InNs. Этот атрибут должен быть доступен только в том случае, если пространство имен логического узла отличается от пространства имен, на которое имеется ссылка в атрибуте IdNs LLN0.

Атрибут InNs должен быть DataAttribute паспортной таблички NamPIt логического узла. Атрибут InNs должен быть таким, как это определено в общем классе DATA паспортной таблички логического узла LPL в МЭК 61850-7-3.

При использовании первого издания МЭК 61850-7-4 в качестве пространства имен логического узла это значение следует определять как МЭК 61850-7-4:2003.

ObjectReference для DataAttribute InNs должна быть следующей:

LDName/LNName.NamPlt.lnNs

14.4.4 Атрибут для пространства имен данных (dataNs)

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

Атрибут dataNs должен быть DataAttribute этих данных. Атрибут dataNs должен быть таким, как определено в общих DATA классах МЭК 61850-7-3.

При использовании первого издания МЭК 61850-7-4 в качестве пространства имен данных это значение следует определять как МЭК 61850-7-4:2003.

ObjectReference для DataAttribute dataNs должна быть следующей:

LDName/LNName. DataName [.DataName[. ...]].dataNs

14.4.5 Атрибут для пространства имен класса общих данных (cdcNs)

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

Атрибут cdcNs должен быть DataAttribute этих данных. Атрибут cdcNs должен быть таким, как определено в общих классах DATA МЭК 61850-7-3.

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

ObjectReference для DataAttribute cdcNs должна быть следующей:

LDName/LNName.DataName [.DataName[. ...]].cdcNs

14.5 Общие правила для расширений пространств имен

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

Рисунок 77 - Расширения пространств имен (концептуальное представление)

________________
New DATA based on existing or new CDC.

Рисунок 77 - Расширения пространств имен (концептуальное представление)

Создание LOGICAL-DEVICE - это процесс, включающий в себя следующие этапы:

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

b) Выбрать LOGICAL-NODE из существующих (может быть стандартизованных) LOGICAL-NODEs, если этот LOGICAL-NODE соответствует требованию.

c) Выбрать LOGICAL-NODE из существующих (может быть стандартизованных) LOGICAL-NODEs и добавить новые DATA, если этот LOGICAL-NODE соответствует основным требованиям.

d) Определить новый LOGICAL-NODE, если LOGICAL-NODE, определяемый перечислениями b) и с), не соответствует требованиям:

- этот новый LOGICAL-NODE может содержать DATA, которые уже определены в других LOGICAL-NODE, или

- эти новые DATA могут быть определены с использованием существующих или новых общих DATA классов (CDC).

e) Если необходимо, назначить специально для этого приложения LN-префикс и LN-instance-ID экземпляру LOGICAL-NODE.

f) Повторить этапы от b) до е) для других функций.

д) Сконфигурировать LOGICAL-NODEs.

Использование стандартизованного пространства имен (МЭК 61850-7-4) и расширенных данных, а также пространства имен класса общих данных (АВВ_2273) показано на рисунке 78.

Рисунок 78 - Использование расширенного пространства имен (концептуальное представление)

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

Пространство имен класса общих данных, использованное для этих данных, не нуждается в отметках в экземпляре этих данных, так как это неявно обозначено в определении пространства имен АВВ_2773.

Для однозначной интерпретации семантики логического устройства требуются только две отметки: IdNs (МЭК 61850-7-4:2003) и dataNs (АВВ_2773) для расширенного определения.

15 Подходы к определению новой семантики

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

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

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

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

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

15.2 Семантика для нового определения

Цель нового определения (используемого для объяснения различных подходов) - определение статистических экземпляров класса DATA для средней наружной температуры подстанции. Класс DATA должен содержать средние значения за 1 ч и за 10 мин. Для простоты примера логический узел, содержащий эти экземпляры класса DATA, не показан, но он будет влиять на семантику DATA. Примерами могут служить существующие MSTAT, связанные со статистикой измерений или новым LN, таким как MENV (измерение параметров окружающей среды).

15.3 Подход 1 (фиксированная семантика)

Имена измеряемого значения DATA определены как TmpMean60 и TmpMean10.


Логический узел WXYZ
Данные	Класс общих данных
TmpMean60	MV
TmpMean10	MV

Тип измеряемого значения DATA (тип общих данных) определен как MV (измеренное значение).

Семантика для TmpMean60: среднее значение за полный час (00:00, 01:00 и т.д.).

Семантика для TmpMean10: среднее значение за полный час и n10 мин по истечении этого часа (00:00, 00:10, 00:20 и т.п.).

15.4 Подход 2 (гибкая семантика)

Имена измеряемых значений DATA определены как TmpMean1 и TmpMean2.

Тип измеряемых значений DATA (тип общих данных) определен как MV.

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

Имена конфигурационных данных DATA определены как ITmpMean1, STmpMean1 и ITmpMean2, STmpMean2.

Тип конфигурационных данных DATA (тип общих данных) определен как ASG (настройка аналогового сигнала).


Логический узел: WXYZ
Данные	Класс общих данных
TmpMean1	MV
TmpMean2	MV
ITmpMean1	ASG
STmpMean1	ASG
ITmpMean2	ASG
STmpMean2	ASG

Семантика для TmpMean1: среднее значение согласно значениям уставки.

Семантика для TmpMean2: среднее значение согласно значениям уставки.

15.5 Подход 3 (гибкая семантика многократного использования)

Имена измеряемого значения DATA определены как TmpMean1 и TmpMean2.

Тип измеряемого значения DATA (тип общих данных) определен как MVStat.


Логический узел: WXYZ
Данные	Класс общих данных
TmpMean1	MVStat
TmpMean2	MVStat

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


Класс общих данных: MVStat
Атрибут данных	Тип атрибута
statVal	AV
Int	INT32
strtTm	TimeStamp

Приложение А (справочное). Обзор серии стандартов МЭК 61850-7, стандартов МЭК 61850-8-1, МЭК 61850-9-1 и МЭК 60850-9-2

Приложение А
(справочное)

Обзор серии стандартов МЭК 61850-7, стандартов МЭК 61850-8-1 [2], МЭК 61850-9-1 [3] и МЭК 60850-9-2 [4]

А.1 Введение

Методы моделирования и реализации, примененные в различных частях МЭК 61850, и их соотношение показаны на рисунке А.1. Как показано слева на рисунке А.1, в МЭК 61850-7-1 определены основные принципы и методы моделирования.

Рисунок А.1 - Общая архитектура системы связи

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

Примечание - Поскольку эти классы определены для подстанций и линейного оборудования, могут быть другие классы объектов, определенные для других различных областей приложений в сфере или за пределами сферы действия Технического комитета 57 МЭК. Они значимы для рисунка А.1, только если сформированы в соответствии с подходом серии стандартов МЭК 61850.

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

- МЭК 61850-7-4 Совместимые классы логических узлов и классы данных (несколько сотен терминов и уникальных имен);

- МЭК 61850-7-3 Классы общих данных (общие детали содержания терминов, определенных в МЭК 61850-7-4);

- МЭК 61850-7-2 Абстрактный интерфейс услуг связи (ACSI) (общие модели класса сервисов с сервисами и параметрами для связи с экземплярами классов МЭК 61850-7-4 и МЭК 61850-7-3);

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

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

- МЭК 61850-9-2 [4] Специфическое отображение сервиса связи (SCSM). Выборочные значения в пределах ИСО/МЭК 8802-3 (кодирование данных, сервисы и параметры сервиса);

- МЭК 61850-6 [1] Язык конфигурации системы автоматизации подстанции (представление всех опциональных данных из МЭК 61850-7-4 и МЭК 61850-7-3).

А.2 Совместимые классы логических узлов и классы данных (МЭК 61850-7-4)

А.2.1 Список групп LN (МЭК 61850-7-4)

Список всех групп логических узлов представлен в таблице 2 МЭК 61850-7-4.

А.2.2 Классы LN (МЭК 61850-7-4)

Выборка групп логических узлов представлена в таблице 5.4 МЭК 61850-7-4.

А.2.3 Классы данных (МЭК 61850-7-4)

Общее количество (приблизительно 500 классов данных) определено в МЭК 61850-7-4. В таблице А.1 показана выборка нескольких классов DATA с их именами и семантическими определениями.

Таблица А.1 - Выборка классов данных для измеряемых значений


Наименование данных	Семантика
AcsCtlFail	Число зафиксированных отказов управления доступом
AcuPaDsch	Акустический уровень частичного разряда в децибелах
AgeRat	Оценка старения, например трансформатора
Alm	Общий единичный аварийный сигнал
AlmLstOv	TRUE = индикация переполнения списка аварийных сигналов
AlmThm	Аварийный сигнал о перегреве
AlmVal	Аварийный уровень, выход за который вызывает сигнал аварии
Amp	Ток цепи (кроме трехфазных)
Ang	Фазовый угол между напряжением и током
AngCor	Фазовая корректировка вектора (используется, например, для измерительных трансформаторов)
Anglnd	Эти данные показывают результат проверки разности между углами напряжения сборных шин и линии. FALSE указывает на то, что разность углов ниже требуемого предела. Критерии рассогласования углов для синхронизации удовлетворены. TRUE указывает на превышение предельного значения рассогласования углов. Включение линейного выключателя запрещено

Имена данных составлены с использованием стандартизованных сокращений, перечисленных в разделе 4 МЭК 61850-7-4 (определены около 260 сокращений), например:


Термин	Описание
А	Ток
Acs	Доступ
Acu	Акустический
Age	Старение
Alm	Сигнализация
Amp	Ток (безотносительно к фазе)
An	Аналоговый
Ang	Угол
...

Эти сокращения должны быть использованы при создании новых имен данных.

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

А.3 Спецификации класса общих данных (МЭК 61850-7-3)

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

Таблица А.2 - Перечень классов общих данных

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

Одноэлементное состояние (SPS)

Двухэлементное состояние (DPS)

Целочисленное состояние (INS)

Группа индикации состояния (SIG)

Целочисленное состояние (ISI)

Информация об активации защиты (ACT)

Информация об активации направленной защиты (ACD)

Подсчет нарушений режима безопасности (SEC)

Показания двоичного счетчика (BCR)

Спецификации класса общих данных для информации об измеряемых значениях

Измеренное значение (MV)

Комплексное измеренное значение (CMV)

Выборочное значение (SAV)

Соединение звездой (WYE)

Соединение треугольником (DEL)

Последовательность (SEQ)

Уровень гармоник для соединения звездой (HWYE)

Уровень гармоник для соединения треугольником (HDEL)

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

Одноэлементное управление (SPC)

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

Управляемое целочисленное состояние (INC)

Двоичная информация об управляемом пошаговом положении (BSC)

Целочисленная информация об управляемом пошаговом положении (ISC)

Спецификации класса общих данных для управляемой аналоговой информации

Управляемая аналоговая информация об уставке (АРС)

Спецификации класса общих данных для настроек состояния

Настройка одноэлементного управления (SPG)

Настройка целочисленного состояния (ING)

Спецификации класса общих данных для аналоговых настроек

Аналоговая настройка (ASG)

Кривая настройки (CURVE)

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

Паспортная табличка устройства (DPL)

Паспортная табличка логического узла (LPL)

Описание формы кривой (CSD)

Приложение В (справочное). Привязка данных к логическим узлам

Приложение В
(справочное)

На рисунке В.1 показан пример привязки данных к логическим узлам.

Рисунок В.1 - Пример LN управления и защиты, объединенных в одном физическом устройстве

Рисунок В.1 - Пример LN управления и защиты, объединенных в одном физическом устройстве, лист 1

Рисунок В.1, лист 2

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

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

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

- данные, состоящие из напряжения и пошагового положения, привязаны к логическому узлу "контроллер РПН". То же самое относится и к командам РПН;

- данные, состоящие из сопротивления до места короткого замыкания Z, привязаны к логическому узлу "дистанционная защита". То же самое применимо к сигналу защиты на отключение.

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

Второй прикладной пример показан на рисунке В.2. Соединительный модуль получает значения тока и напряжения непосредственно от измерительных трансформаторов. Это устройство может быть интегрировано в каждый измерительный трансформатор. Такие варианты реализации выходят за область применения настоящего стандарта. Источниками выборочных значений всегда являются экземпляры классов LN TVTR и TCTR. В данном примере с соединительным модулем выборочные значения во всех трех фазах и нейтрали должны быть собраны и отосланы как многоадресные сообщения. Эти выборочные значения получают несколько приложений.

Рисунок В.2 - Соединительный модуль и обмен выборочными значениями (топология)

Соединительный модуль смоделирован как единичное логическое устройство, называемое MergingUnit (рисунок В.3).

Рисунок В.3 - Соединительный модуль и обмен выборочными значениями

Рисунок В.3 - Соединительный модуль и обмен выборочными значениями (данные)

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

- трансформатор тока - класс TCTR в МЭК 61850-7-4 представлен экземплярами для трех фаз и нейтрали: PhsATCTR, PhsBTCTR, PhsCTCTR, NeutTCTR;

- трансформатор напряжения - класс TVTR в МЭК 61850-7-4 представлен экземплярами для трех фаз, нейтрали и сборной шины: PhsATVTR, PhsBTVTR, PhsCTVTR, NeutTVTR, BusBTVTR.

В данном примере использованы выборочные значения (Amp и Vol) и соответствующие номинальные значения. Эти данные имеют ссылки из набора данных DS1.

Два экземпляра блоков управления выборочными значениями (SVControl1 и SVControl2) определены для управления обменом выборочными значениями. Эти два блока управления поддерживают две разные частоты опроса (8 и 16 выборочных значений за номинальный период - 400/800 выборочных значений в секунду при частоте в системе 50 Гц).

Приложение С (справочное). Использование языка конфигурации подстанции (SCL)

Приложение С
(справочное)

С.1 Введение

В настоящем приложении объяснено только применение SCL для описания использования опциональных определений, содержащихся в определениях классов в МЭК 61850-7-4 и МЭК 61850-7-3.

С.2 SCL и опциональные возможности в логических узлах

На рисунке С.1 показан класс XCBR логического узла так, как он определен в МЭК 61850-7-4. Есть несколько элементов данных, определенных как обязательные (М), остальные данные определены как опциональные (О).

Рисунок С.1 - Использование SCL для LN (концептуальное представление)

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

В SCL требуется, чтобы все данные, которые будут использованы в модели устройства, были представлены списком. В данном примере выбраны три опциональных элемента данных (EEHealth, EEName и ChaMotEna).

В SCL также необходимо, чтобы все атрибуты опциональных данных любых данных были представлены списком. Отмеченные данные Pos подробно описаны в С.3.

С.3 SCL и опциональные возможности в данных

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

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

Рисунок С.2 - Использование SCL для данных (концептуальное представление)

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

Приложение D (справочное). Применение концепции LN к опциям для будущих расширений

Приложение D
(справочное)

D.1 Введение - архитектура прямой связи телеуправления

Прямая ("бесшовная") связь, как она изображена на рисунке D.1, позволяет моделировать представление центра управления подстанции (СС представление) и связь между подстанциями и центрами управления.

Рисунок D.1 - Прямая связь (упрощенное представление)

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

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

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

3 В качестве альтернативного решения могут быть определены новые классы логических узлов и классы данных для использования в шлюзе/посредническом устройстве, которые обеспечивают представление центра управления подстанции (в примере, приведенном выше, инстанциированные в логическом устройстве CC-View2).

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

Это обеспечивает три варианта доступа к данным подстанции:

Опция 1 наиболее полезна с точки зрения обслуживания.

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

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

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

Пример необходимости создания новых логических узлов:

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

Пример приведен на рисунке D.2.

Рисунок D.2 - Пример новых логических узлов

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

ПРИМЕР

Логический узел группы "присоединение":

BDBB двойная система шин

ВНСВ полуторная схема коммутации

Логические устройства, определенные, например, на уровне напряжения:

SSAtlanta_110

SSAtlanta_380

Некоторые объекты данных:

SSAtlanta_1 10/BDBB1.Q0Pos

SSAtlanta_1 10/BDBB1.Q1 Pos

SSAtlanta_1 10/BDBB1.V

SSAtlanta_1 10/BDBB2.Q0Pos

SSAtlanta_1 10/BDBB2.Q1 Pos

SSAtlanta_1 10/BDBB2.V

SSAtlanta_380/BHCB1.QAPos

SSAtlanta_380/BHCB1.QBPos

SSAtlanta_380/BHCB1.QCPos

По существу, LN Bxxx - это другое виртуальное представление того же реального объекта. Как LN Вххх получает информацию - это вопрос реализации. Он может, например, быть подписан на рассылку отчетов от LN Q0CSWI или может напрямую посылать команду управления на Q0CSWI.

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

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

Пример приведен на рисунке D.3. Представление подстанции может быть отображено на одно или более представление центра управления. В примере логическое устройство SSAtlanta_110 может быть представлением центра управления А, а логическое устройство SSAtlanta_380 - представлением центра управления В.

Рисунок D.3 - Пример представления центра управления и отображения в представление подстанции

Рисунок D.3 - Пример представления центра управления и отображения в представление подстанции, лист 1

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

D.2 Телезащита

D.2.1 Дистанционная защита

В случае селективного отключения поврежденной линии дистанционная защита (логический узел PDIS) изменяет сигналы на release ("отключить") или block ("блокировать"). Эти сигналы должны быть такими же, что и используемые в пределах подстанции. Логический узел LN PSCH (схема защиты линии) уже является частью стандарта. Модель данных должна быть такой же, т.е. соответствовать стандартам МЭК серии 61850, равно как отображение и выбор стека. Что касается специальных требований к связи, здесь может быть применено отображение с различными уровнями 1 и 2 эталонной модели ISO/OSI.

D.2.2 Дифференциальная защита

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

D.2.3 Расширенные функциональные возможности

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

Приложение Е (справочное). Соответствие между логическими узлами и PICOM данными

Приложение Е
(справочное)

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

Рисунок Е.1 - Данные, обмениваемые между подстанциями (логические узлы)

В модели клиент - сервер определяются сервисы, которые описывают семантику и синтаксис обмениваемых данных. В этом смысле обмениваемые данные называются блоком данных протокола (PDU), который определяет "биты в линии". Содержимое и семантика этих обмениваемых данных определяются объектами внутри сервера. В данной модели такими объектами являются логические узлы. Их подкомпоненты - объекты данных - включают в себя всю информацию процесса, которая связана с содержимым PICOM данных, см. рисунок Е.2.

Рисунок Е.2 - Соответствие между PICOM данными и моделью клиент-сервер

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

Один PDU может включать в себя содержимое нескольких данных, а следовательно, - содержимое нескольких PICOM данных.

Приложение F (справочное). Соответствие между серией стандартов МЭК 61850-7 (МЭК 61850-8-1) и UCA

Приложение F
(справочное)

Соответствие между серией стандартов МЭК 61850-7 (МЭК 61850-8-1 [2]) и UCA

На рисунке F.1 изображено общее соответствие между различными частями серии стандартов МЭК 61850 и UCA.

Рисунок F.1 - Соответствие между серией стандартов МЭК 61850 и UCA

Примечание - UCA является зарегистрированной торговой маркой EPRI, Palo Alto (США).

Рисунок F.1 - Соответствие между серией стандартов МЭК 61850 и UCA

Приложение ДА (справочное). Сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации

Приложение ДА
(справочное)

Таблица ДА.1


Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
МЭК 61850-2	-	*
МЭК 61850-5	-	*
МЭК 61850-7-2	IDT	ГОСТ Р МЭК 61850-7-2-2009 "Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 2. Абстрактный интерфейс услуг связи (ACSI)"
МЭК 61850-7-3	IDT	ГОСТ Р МЭК 61850-7-3-2009 "Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 3. Классы общих данных"
МЭК 61850-7-4	-	*
ИСО/МЭК 8825 (все части)	IDT	ГОСТ Р ИСО/МЭК 8825-1-2003 "Информационная технология. Правила кодирования АСН.1. Часть 1. Спецификация базовых (BER), канонических (CER) и отличительных (DER) правил кодирования"
	IDT	ГОСТ Р ИСО/МЭК 8825-2-2003 "Информационная технология. Правила кодирования АСН.1. Часть 2. Спецификация правил уплотненного кодирования (PER)"
	IDT	ГОСТ Р ИСО/МЭК 8825-4-2006* "Информационная технология. Правила кодирования АСН.1. Часть 4. Правила XML кодирования (XER)"
_______________ * На территории Российской Федерации документ не действует. Действует ГОСТ Р ИСО/МЭК 8825-4-2009. - .
* Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Перевод данного международного стандарта находится в ОАО "Научно-технический центр электроэнергетики" (E-mail: vulis@vniie.ru, vulis@nts-power.ru). Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов: IDT - идентичный стандарт.

Библиография


[1]	IEC 61850-6 (МЭК 61850-6)	Communication networks and systems in substations - Part 6: Configuration description language for communication in electrical substations related to lEDs (Сети и системы связи на подстанциях. Часть 6. Язык описания конфигурации для связи между интеллектуальными электронными устройствами на электрических подстанциях)
[2]	IEC 61850-8-1 (МЭК 61850-8-1)	Communication networks and systems in substations - Part 8-1: Specific Communication Service Mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO 9506-2 ) and to ISO/IEC 8802-3 (Сети и системы связи на подстанциях. Часть 8-1. Специфическое отображение сервиса связи (SCSM). Схемы распределения по MMS (ИСО 9506-1 и ИСО 9506-2) и по ИСО/МЭК 8802-3)
[3]	IEC 61850-9-1 (МЭК 61850-9-1)	Communication networks and systems in substations - Part 9-1: Specific Communication Service Mapping (SCSM) - Sampled values over serial unidirectional multi drop point to point link (Сети и системы связи на подстанциях. Часть 9-1. Специфическое отображение сервиса связи (SCSM). Выборочные значения в пределах последовательного однонаправленного многоточечного канала связи типа "точка-точка")
[4]	IEC 61850-9-2 (МЭК 61850-9-2)	Communication networks and systems in substations - Part 9-2: Specific Communication Service Mapping (SCSM) - Sampled values over ISO/IEC 8802-3 (Сети и системы связи на подстанциях. Часть 9-2. Специфическое отображение сервиса связи (SCSM). Выборочные значения в соответствии с ИСО/МЭК 8802-3)
[5]	ISO/IEC 8802-3:2000 (ИСО/МЭК 8802-3:2000)	Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications (Информационная технология. Телекоммуникация и информационный обмен между системами. Локальные и региональные вычислительные сети. Специальные требования. Часть 3. Метод доступа. Множественный доступ с контролем передачи и обнаружением коллизий (CSMA/CD) и спецификации физического уровня)
[6]	ISO 9506-1:2003 (ИСО 9506-1:2003)	Industrial automation systems - Manufacturing Message Specification - Part 1: Service definition (Системы автоматизации производства. Спецификация производственных сообщений. Часть 1. Определение услуг)
[7]	ISO 9506-2:2003 (ИСО 9506-2:2003)	Industrial automation systems - Manufacturing Message Specification - Part 2: Protocol specification (Системы автоматизации производства. Спецификация производственных сообщений. Часть 2. Спецификация протокола).
[8]	IEEE-SA TR 1550-1999	Utility Communications Architecture (UCA) Version 2 (Коммуникационная архитектура предприятий электроэнергетики (UCA) версия 2)

Электронный текст документа
и сверен по:
официальное издание
М.: Стандартинформ, 2011