ГОСТ Р МЭК 61850-6-2009. Национальный стандарт Российской Федерации. Сети и системы связи на подстанциях. Часть 6. Язык описания конфигурации для связи между интеллектуальными электронными устройствами на электрических подстанциях

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

Утвержден и введен в действие

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

Дата введения 1 января 2011 года

Предисловие

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

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

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

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

4 Настоящий стандарт идентичен международному стандарту МЭК 61850-6:2004 «Сети и системы связи на подстанциях. Часть 6. Язык описания конфигурации для связи между интеллектуальными электронными устройствами на электрических подстанциях (IEC 61850-6:2004 „Communication networks and systems in substations — Part 6: Configuration description language for communication in electrical substations related to IEDs“)»

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

Часть 8-1. Специфическое отображение сервиса связи (SCSM) — Схемы отображения на MMS (ISO 9506-1 и ISO 9506-2) и на ISO/IEC 8802-3

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

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

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

В настоящем стандарте рассматривается язык описания конфигурации IED-устройств на электрических подстанциях. Этот язык называется Substation Configuration description Language (SCL) — язык описания конфигурации подстанции. Он служит для описания конфигурации IED-устройств и систем связи согласно МЭК 61850-5 и серии стандартов МЭК 61850-7. Этот язык позволяет выполнить формальное описание отношений между системой автоматизации подстанции (SAS-системой — Substation Automation System) и подстанцией (распределительным устройством). На уровне приложения могут быть описаны сама топология распределительного устройства и отношение его структуры к функциям SA-системы (логическим узлам), сконфигурированным на IED-устройствах.

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

В МЭК 61850-8-1, МЭК 61850-9-1 и МЭК 61850-9-2 рассматривается отображение серии стандартов МЭК 61850-7 в специальных стеках связи. Они могут, исходя из внутренней необходимости, расширить эти определения за счет дополнительных частей либо за счет простого ограничения возможных способов использования значений объектов.

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

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

Определяемый язык называется языком описания конфигурации подстанции (SCL). IED-устройства и модель системы связи на языке SCL соответствуют МЭК 61850-5 и серии стандартов МЭК 61850-7. В соответствующих частях серии стандартов МЭК 61850 могут потребоваться определяемые на уровне SCSM расширения или правила использования.

Язык конфигурирования создан на основе расширенного языка разметки XML версии 1.0.

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

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

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

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

МЭК 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

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

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

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

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

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

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

4 Сокращения

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

BDA	Basic Data Attribute, that is not structured	Атрибут основных данных, не структурирован
CIM	Common Information Model for energy management applications	Общая информационная модель для прикладных решений в области управления энергией
DAI	Instantiated Data Attribute	Атрибут инстанцируемых данных
DO	DATA in IEC 61850-7-2, data object type or instance, depending on the context	DATA по МЭК 61850-7-2, в зависимости от контекста — тип или экземпляр объекта данных
DOI	Instantiated Data Object (DATA)	Объект инстанцируемых данных (DATA)
DTD	Document Type Definition for an XML document	Определение типа документа для документа на языке XML
FCD	Functionally Constrained Data	Функционально связанные данные
FCDA	Functionally Constrained Data Attribute	Атрибут функционально связанных данных
ID	Identifier	Идентификатор
IED	Intelligent Electronic Device	Интеллектуальное электронное устройство
LD	Logical Device	Логическое устройство
LDInst	Instantiated Logical Device	Инстанцируемое логическое устройство
LNInst	Instantiated Logical Node	Инстанцируемый логический узел
LPHD	Logical Node PHysical Device	Физическое устройство логического узла
MSV	Multicast Sampled Value	Многоадресные выборочные значения
MsvID	ID for MSV (Multicast Sampled Value)	Идентификатор ID для MSV
RCB	Report Control Block	Блок управления отчетами
SCL	Substation Configuration description Language	Язык описания конфигурации подстанции
SCSM	Specific Communication Service Mapping	Специфическое отображение сервиса связи
SDI	Instantiated Sub DATA; middle name part of a structured DATA name	Инстанцируемый подмодуль DATA; средняя именная часть в структурированном имени модуля DATA
UML	Unified Modelling Language according to http://www.omg.org/uml	Универсальный язык моделирования в соответствии с http://www.omg.org/uml
URI	Universal Resource Identifier	Универсальный идентификатор ресурсов
USV	Unicast Sampled Value	Одноадресные выборочные значения
UsvID	ID for USV	Идентификатор ID для USV
XML	Extensible Markup Language	Расширенный язык разметки

5 Предполагаемый процесс разработки и проектирования с использованием языка SCL

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

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

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

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

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

e) дополнительно к описанию d) - описания конфигурирования процесса со всеми предопределенными ассоциациями и соединениями «клиент — сервер» между LN на уровне данных. Это необходимо в тех случаях, когда IED-устройство не способно создать динамические ассоциации или соединения для генерации отчетов (как на стороне клиента, так и на стороне сервера).

Описание e) является законченным. Описания d) и e) являются результатом разработки и проектирования SA-системы. Описание a) является входом функциональной спецификации в разработку и проектирование SA-системы, а описания b) и c) - возможными результатами, полученными после предварительной разработки и проектирования IED-устройств.

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

1. функциональная спецификация SA-системы [описание a)];

2. описание возможностей IED-устройства [описания b) и c)];

3. описание SA-системы [описания d) и e)].

Целью применения языка SCL является стандартизация системного проектирования, систем связи и описания спроектированных систем связи для средств конфигурирования устройств.

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

Рисунок 1 показывает, как происходит обмен данными на языке SCL в вышеупомянутом процессе проектирования и разработки. Затененные текстовые поля над пунктирной линией показывают, где используются файлы языка SCL. Текстовое окно IED capabilities (возможности IED-устройств) соответствует упомянутым описаниям b) и c), текстовое окно System specification (системная спецификация) - описанию a), текстовое окно Associations - описанию d) или e).

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

IED-устройство может рассматриваться как совместимое с требованиями стандарта из серии стандартов МЭК 61850 только в том случае, если:

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

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

Часть рисунка 1 под пунктирной линией показывает, каким образом данные IED-конфигурации, сгенерированные конфигуратором устройства, могут быть перенесены в IED-устройство. Перенос осуществляется:

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

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

6 Объектная модель SCL

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

Язык SCL в полном объеме описывает следующую модель:

• структура основной (энергетической) системы — используемые функции основного оборудования и его соединения. Это позволяет обозначить все рассматриваемое коммутационное оборудование как функции автоматизации подстанции, структурированные согласно МЭК 61346-1;
• система связи — способы подключения IED-устройств к подсетям и сетям и точки их доступа к среде передачи (порты связи);
• связь на уровне приложения — способы формирования наборов данных для отправки, способы инициации отправок IED-устройствами, выбор сервиса и необходимые входные данные от других IED-устройств;
• на уровне отдельного IED-устройства — логические устройства, сконфигурированные на IED-устройстве; LN, имеющие класс и тип и принадлежащие каждому логическому устройству; отчеты и содержимое их данных; доступные (заранее сконфигурированные) ассоциации; данные, подлежащие регистрации;
• определения типов инстанцируемых LN. Согласно серии стандартов МЭК 61850-7 LN имеют обязательные, дополнительные и определенные пользователем данные DATA (в настоящем стандарте применено сокращение DO), а также дополнительные сервисы. Поэтому LN не являются инстанцируемыми. В настоящем стандарте инстанцируемые LNTypes и DOTypes определены как шаблоны, которые содержат действительно реализованные данные DO и сервисы;
• отношения между инстанцируемыми LN и IED-устройствами, в которых они содержатся, с одной стороны, и (функциональными) компонентами распределительного устройства — с другой.

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

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

На рисунке 2 показана объектная модель UML. Необходимо обратить внимание на то, что с точки зрения моделирования она не закончена, то есть на ней не показаны родительские классы, из которых могли появиться потомки классов, отсутствуют атрибуты и т.д. Если речь идет о компоненте подстанции, модель ограничивается теми типами конкретных объектов, которые используются в экземпляре файла SCL, и использует их в основном в целях функционального обозначения. Кроме того, ниже уровня DATA (DO) у нее нет структурно определенных в МЭК 61850-7-2 уровней, описание которых на языке SCL приведено в разделе DataTypeTemplates.

Рисунок 2 — Объектная модель языка SCL

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

2 Продукт (Product): под продуктом понимаются все объекты, относящиеся к продуктам SA-системы, например IED-устройства и реализации LN.

3 Связь (Communication): в этой части находятся типы объектов, относящиеся к связи (такие, как подсети и точки доступа к среде передачи), и приведено описание коммуникационных соединений между IED-устройствами в качестве основы для трактов связи между LN как клиентами и серверами.

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

Более подробная информация о модели, содержащаяся в языке SCL, например структура в пределах LN, приведена в серии стандартов МЭК 61850-7.

Части модели Substation и Product образуют иерархии, которые используются при присвоении имен и согласно серии стандартов МЭК 61346 могут быть отображены на функциональную структуру и структуру продукта. Часть модели Communication содержит реализуемые маршрутизаторами на IED-устройстве коммуникационные соединения IED-устройств с подсетями и между подсетями, а также размещение в подсетях главных часов для синхронизации точного времени. Моделирование шлюзов здесь специально не рассматривается. Шлюз, который является сервером (по МЭК 61850), должен моделироваться как любое другое IED-устройство, совместимое с требованиями серии стандартов МЭК 61850. Промежуточный объект данных (Proxy DO) в LN физического устройства позволяет определить, является ли размещенное в физическом устройстве LPHD логическое устройство (LD) образом другого IED-устройства или оно принадлежит данному IED-устройству. Шлюз, как клиент, соответствующий требованиям серии стандартов МЭК 61850, должен содержать LN телемеханического интерфейса ITCI.

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

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

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

• имя используется как технический ключ (или его иерархическая часть) для обозначения объекта. Каждый объект в иерархии имеет атрибут name (имя), который однозначно идентифицирует его на данном уровне иерархии. Технические ключи используют в технической документации для построения и обслуживания системы или для автоматической обработки информации, связанной с процессом проектирования и разработки. Язык SCL также использует это обозначение для описания связей между различными объектами модели. В данном случае атрибут, содержащий ссылку, если это возможно, получает имя в виде Name, например daName для ссылки на атрибут DATA. Это имя в большей степени идентично тому, что называется именем в МЭК 61850-7-2;
• пояснительную часть используют как идентификацию объекта (или ее иерархическая часть) и ее определяет оператор или пользователь. Объект на уровне иерархии имеет атрибут desc, который в пределах иерархической структуры содержит текстовое описание. Текстовая идентификация используется, например, в интерфейсах операторов и руководствах по эксплуатации.

Примечание - Атрибут desc в языке SCL используется в процессе проектирования и разработки и определяет функциональный объект на его иерархическом уровне. Для описания данных согласно серии стандартов МЭК 61850 используется атрибут d объекта DATA, который может быть также считан в режиме онлайн. Содержимое атрибутов desc может использоваться для генерации специфичного для данного проекта (SCD) d-текста из шаблона d-текста (ICD). Однако это не является объектом стандартизации.

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

В следующих разделах приводятся описание различных частей модели, их назначение и соответствующее использование. Атрибуты объекта упоминаются, только если это необходимо для понимания модели. Описание дополнительных атрибутов объекта приведено далее при определении языка SCL. Дальнейшая информация по модели серии стандартов МЭК 61850-7 детально представлена в МЭК 61850-7-1 и МЭК 61850-7-2 и поэтому в настоящем стандарте не приведена. Однако модель функциональности первичного оборудования приведена только в настоящем стандарте, и поэтому она описана в объеме, необходимом для использования в пределах настоящего стандарта.

На рисунке 3 показан экземпляр данной модели: простой пример SA-системы распределительного устройства. Имена присвоены в соответствии с серией стандартов МЭК 61346. Распределительное устройство на напряжение 110 кВ с присоединением типа E1 представляет собой двойную систему шин с двумя присоединениями линий =E1Q1 и =E1Q3 и шиносоединительным выключателем =E1Q2. IED-устройства уже ассоциированы с функциональностью первичного оборудования (например, контроллер присоединения E1Q1SB1 как продукт сопоставлен с присоединением =E1Q1, а его LN CSWI1 управляет автоматическим выключателем =E1Q1QA1 через LN XCBR1 на IED-устройстве E1Q1QA1B1). Следует обратить внимание на то, что согласно терминам МЭК 61346-1 присоединение является переходным объектом. Это значит, что оно имеет функцию (знак = (равно) на уровне распределительного устройства) и в качестве продукта рассматривается как компонент распределительного устройства. Этот переход виден в описании языка SCL только в структуре имен IED-устройства. Явным образом моделируется только переход на LN. На рисунке 3 знаком — (минус) отмечены обозначения, относящиеся к продукту. Функциональное имя не повторяется. Подсеть связи на уровне станции называется W1. На уровне процесса имеются три дополнительные подсети (технологические шины) — W2, W3, W4. На рисунке можно видеть точки доступа, но их обозначения не показаны. На рисунке также не показаны LD и серверы. В основном это означает, что не показаны динамические соединения, например ассоциации.

Рисунок 3 — Пример конфигурации

6.2 Модель подстанции

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

Примечание 1 — В CIM-модели выводам основных устройств назначаются измеряемые значения. Однако это является топологическим размещением, тогда как размещение на языке SCL в первую очередь служит функциональному присвоению имен. В то же время, если однолинейная топология полностью смоделирована через трансформаторы напряжения VTR и тока CTR и относящиеся к ним узлы сбора данных (TVTR, TCTR), в топологии может быть также найден терминал некоего первичного устройства, которому в соответствии с CIM-моделью принадлежат измеряемые значения.

Назначение модели подстанции:

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

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

Substation (подстанция) — Объект, идентифицирующий подстанцию в целом.

VoltageLevel (уровень напряжения) — Идентифицируемая, электрически соединенная часть подстанции, имеющая одинаковый уровень напряжения.

Bay (присоединение) — Идентифицируемый компонент или подфункция распределительного устройства (подстанции) в пределах одного уровня напряжения.

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

SubEquipment (подразряд оборудования) — Компонент оборудования, например, к нему можно отнести одну фазу трехфазного оборудования.

ConnectivityNode (узел связи) — Объект узла связи (электрической), соединяющий различные основные устройства. Типичными примерами узла связи могут быть соединительные узлы в пределах присоединения; сборные шины, соединяющие несколько присоединений на одном уровне напряжения; присоединения, соединяющие электрические линии в различных подстанциях. Также см. выше определение Equipment (оборудование).

Terminal (вывод) — Точка электрического соединения основных аппаратных устройств на уровне однолинейной схемы. Вывод может быть соединен с узлом ConnectivityNode. Язык SCL может использовать как явные, так и неявные имена выводов.

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

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

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

6.3 Модель продукта (IED-устройство)

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

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

Server (Сервер) — Связующий объект в IED-устройстве согласно серии стандартов МЭК 61850-7. Через систему связи и ее единственную точку доступа он обеспечивает доступ к данным LD и LN, содержащихся в сервере.

LDevice (логическое устройство) — LD согласно МЭК 61850-7-2, которое находится в сервере IED-устройства.

LNode (логический узел) — Реализация LN согласно МЭК 61850-5 и МЭК 61850-7-2, которая осуществлена в LD IED-устройства. LN содержит данные (DO), которые запрашивают другие LN, и для выполнения своих функций сам может нуждаться в DO, которые содержат другие LN. Предлагаемые DO (возможности сервера) описаны на языке SCL. Необходимые DO (LN на стороне клиента) определяются посредством реализации функции LN и поэтому сконфигурированы с помощью соответствующего средства конфигурации IED-устройств инженером, который планирует систему. Язык SCL позволяет также выполнить их описание, что позволяет на уровне данных моделировать поток данных, передаваемых между LN.

DO — Данные, содержащиеся в LN, согласно серии стандартов МЭК 61850-7.

Примечание — На рисунке 2 показан объект LN со своим классом LNode. Ссылки или представление экземпляров LN могут выполняться в языке SCL двумя способами. Элемент LNode резидентно находится в структуре подстанции, а элемент LN — в структуре IED-устройства.

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

• функция маршрутизатора на IED-устройстве. Это функция сети связи, поэтому она описана в 6.4;
• функция часов для указания на размещение в подсети главных часов.

6.4 Модель системы связи

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

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

Subnetwork (подсеть) — Соединительный узел для прямой (на уровне канала) связи между точками доступа. Он может содержать функцию фильтрации телеграмм на уровне моста, но не имеет функции маршрутизации на уровне сети. Все точки доступа, подключенные к подсети, могут связываться со всеми другими точками в той же подсети с тем же протоколом. На уровне SCSM могут быть заданы соответствующие ограничения, например, если стек реализует метод доступа к шине с конфигурацией master — slave (ведущий — ведомый). Подсеть в данном контексте является логическим понятием. Несколько логических подсетей с различными протоколами верхнего уровня могут, например, использоваться на одной и той же физической шине, что позволяет смешивать протоколы верхнего уровня на одном физическом (более низком) уровне.

Access point (точка доступа) — Коммуникационная точка доступа логического устройства (устройств) IED к подсети. На данном уровне логического моделирования имеется в лучшем случае одно соединение между LD и подсетью. Точка доступа может, однако, обслуживать несколько LD, a LN, размещенные в LD, могут использовать несколько точек доступа как клиенты для соединения с различными подсетями. Как правило, LN контроллера выключателя может получать данные с технологической шины (МЭК 61850-9-1, МЭК 61850-9-2) как клиент и предоставлять данные на шину обмена между присоединениями (МЭК 61850-8-1) как сервер. По терминологии серии стандартов МЭК 61850-7 точка доступа может использоваться сервером, клиентом или тем и другим. Кроме того, одна и та же (логическая) точка доступа может поддерживать различные физические порты доступа, например соединение Ethernet и последовательное соединение на основе PPP (Point-to-Point Protocol) с точкой доступа на том же верхнем уровне (TCP/IP) и с тем же сервером.

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

Clock (часы) — Главные часы в данной подсети, которые служат для синхронизации внутренних часов всех IED-устройств, присоединенных к этой подсети.

Маршрутизаторы и часы присоединены к подсети через соответствующие точки доступа.

6.5 Моделирование резервирования

Для повышения безопасности или готовности системы на разных ее уровнях может быть введено резервирование.

• Внутреннее резервирование IED-устройства. Этот вопрос выходит за рамки серии стандартов МЭК 61850 и, следовательно, не описывается на языке SCL. Резервирование скрыто в аппаратно-программной (HW/SW) части IED-устройства и внешне проявляется только при возникновении сообщения об ошибке в случае какой-либо неисправности. Для индикации этих ошибок может потребоваться введение данных, специфичных для IED-устройства.
• Резервирование на уровне системы связи. Оно лежит ниже уровня, описанного в основном языке SCL. Даже если система связи дублируется, но находится ниже уровня адресации, предоставляемой для логической точки доступа, этот случай выходит за пределы области применения языка SCL. Если вопрос резервирования возникает при отображении стека, должны быть указаны дополнительные параметры, специфичные для уровня SCSM. При их отсутствии (если необходимо) может быть введен набор частных параметров P, например, в точках доступа. Из-за частной природы параметров резервирование на их основе может оказаться неуспешным для IED-устройств разных изготовителей. Типичным примером является сеть Ethernet с кольцевой топологией на основе коммутаторов. Она обеспечивает резервирование при отказе одного коммутатора в кольце, однако ее не видно в файле SCD.
• Резервирование на уровне приложения. Оно моделируется на языке SCL. Типичным примером является основное и резервное IED-устройство релейной защиты (названные условно защита магистрального провода 1 и магистрального провода 2). Каждый экземпляр IED, обеспечивающий резервирование приложения, явным образом смоделирован и имеет собственное имя. В файле SCD также моделируются любые дополнительные подсети связи, представленные явным образом. Любую координацию резервных функций выполняют LN, которые реализуют эти функции.

7 Типы файлов описания на языке SCL

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

Примечание - Версия идентифицирует версии файла SCL, а не версии моделей данных, применяемые со средством программирования. Версии моделей данных определяются средствами программирования.

Различают следующие типы файлов SCL:

Файл *.ICD для описания возможностей IED-устройства (IED Capability Description)

Передача данных из средств управления конфигурацией IED-устройства в средства управления конфигурированием системы (соответствует перечислениям b) и c) в разделе 5). Этот файл описывает возможности IED-устройства. Он должен содержать ровно одну IED-секцию (раздел) для того IED-устройства, возможности которого описываются. Имя IED должно представлять собой шаблон (TEMPLATE). Кроме того, файл должен содержать необходимые шаблоны типов данных, включая определения типов LN, и может содержать дополнительную секцию Substation, где имя подстанции должно представлять собой шаблон. Если задан шаблон подстанции, привязка экземпляров LN к основному оборудованию указывает на предопределенную функциональность. Любая подстанция, в которой используется это IED-устройство, должна согласовываться с соответствующей топологической частью подстанции (например: LN CSWI, привязанному к оборудованию типа CBR, разрешено только управление выключателем; CILO, привязанный к разъединителю, реализует соответствующую логику блокировки). Может существовать дополнительная секция Communication, определяющая по умолчанию возможные адреса для IED-устройства.

Файл *.SSD для описания системной спецификации (System Specification Description)

Передача данных из утилиты системной спецификации в средства конфигурирования системы. Этот файл описывает однолинейную схему подстанции и необходимые LN. Он должен содержать секцию описания подстанции, необходимые шаблоны типа данных и определения типов LN. Если LN, размещенные в секции Substation, еще не размещены в IED-устройстве, ссылка на IED-имя (значение атрибута iedName для элемента LNode) должна быть None (отсутствует). Если LN в секции Substation не привязан к IED-устройству, а также не имеет заданного типа, то в соответствии с МЭК 61850-7-4 определяется только обязательная часть этого LN. Если часть SA-системы уже известна, она может дополнительно размещаться в секциях IED и Communication.

Файл *.SCD для описания конфигурации подстанции (Substation Configuration Description)

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

Файл *.CID для описания сконфигурированного IED-устройства (Configured IED Description)

Передача данных из средств управления конфигурацией IED-устройства в IED-устройство. Описывает инстанцируемые IED-устройства в рамках проекта. Секция Communication содержит текущий адрес IED-устройства. Может существовать секция Substation, относящаяся к данному IED-устройству, тогда значения ее имени должны быть назначены в соответствии с именами, специфичными для проекта. Это файл SCD, который может быть разобран до уровня, известного рассматриваемому IED-устройству. Если применяется сжатие, предпочтение должно быть отдано методам, соответствующим RFC 1952.

Более формальное определение большинства ограничений для данных частей приводится в синтаксисе XML schema в приложении F. Следует обратить внимание на то, что в схеме могут быть описаны не все ограничения в отношении имен IED-устройств и подстанции, упомянутые выше. Чтобы понять элементы, из которых состоит схема, необходимо обратиться к разделам 8 и 9 настоящего стандарта. Вместе с тем следует обратить внимание на то, что это формальное определение дается исключительно в информационных целях и не относится к нормативному определению языка SCL. Кроме того, в схеме могут быть описаны не все упомянутые выше ограничения в отношении имен IED-устройства и подстанции.

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

8 Язык SCL

8.1 Метод спецификации

Язык SCL создан на основе языка XML (см. [10] - [14]).

Определение его синтаксиса описано как W3C XML schema. В остальных разделах приведено определение соответствующей XML schema для языка SCL и объяснено ее использование в тексте с иллюстрированием подходящими (неполными) примерами использования объявленных специальных возможностей. Также предъявлены дополнительные письменные требования, ограничения и отношения к объектной модели, которая должна использоваться или проверяться путем считывания приложения или построения файла SCL. Полное нормативное определение XML schema приведено в приложении A. В приложении A также приведено формальное определение тех ограничений, которые легко формулируются в XML schema. Ограничения в отношении объектной модели, которые отсутствуют или не могут быть легко сформулированы в XML schema, дополнительно описаны в соответствующих разделах.

Чтобы сохранить синтаксис сжатым и расширяемым, по необходимости применяют типовые средства XML schema, тем самым вводится структура наследования элементов схемы. Структура наследования основных элементов языка SCL показана на рисунке 4 в виде схемы UML. Схемы UML могут также показывать отношения включения между элементами языка SCL. Следует иметь в виду, что эти отношения являются отношениями между элементами языка SCL, а не между объектами, представленными элементами и показанными на рисунке 2. Тем не менее была сделана попытка сохранить отношения элементов XML настолько близкими к отношениям объекта, насколько это возможно.

Рисунок 4 — Общее представление о схеме SCL в виде схемы UML

В схеме используются следующие соглашения в отношении присваивания имен:

• имена типов схемы начинаются со строчной буквы t (например, tSubstation);
• определения группы атрибутов начинаются с акронима ag (например, agAuthorization);
• имена атрибутов начинаются со строчной буквы (нижний регистр клавиатуры) (например, name);

- имена элементов начинаются с прописной буквы (верхний регистр клавиатуры) (например, Substation).

Почти все элементы языка SCL являются производными от базового типа tBaseElement (см., например, рисунок 4), что позволяет добавлять к элементу пояснительный текст Text и секции Private частный. Он также позволяет добавлять дополнительные подразряды элементов и атрибуты из других пространств имен (иных, чем целевое пространство имен http://www.iec.ch/61850/2003/SCL) — такие элементы, однако, должны сначала появиться среди всех подразрядов элементов. Это позволяет легко выполнить расширения модели, в том числе частные.

Имеется следующий уровень типов элементов, базирующихся на tBaseElement:

• tUnNaming добавляет дополнительный атрибут описания desc;
• tNaming добавляет дополнительный атрибут описания desc и обязательный атрибут имени name;
• tIDNaming добавляет атрибут описания desc и обязательный атрибут идентификатора id.

Во всех предыдущих типах desc является нормализованной строкой XML (XML normalizedString), то есть строкой, не содержащей управляющих символов возврата каретки, перевода строки или символа табуляции. Его значением по умолчанию является пустая строка. Атрибуты name и id относятся к типу tName, то есть являются также строками, не содержащими управляющих символов возврата каретки, перевода строки или символа табуляции, но они не могут оставаться пустыми.

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

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

Файлы, входящие в определение XML schema языка SCL

Имя файла	Описание
SCL_Enums.xsd	Перечислимые типы, применяемые в XML schema
SCL_BaseSimpleTypes.xsd	Простые базовые типы, применяемые другими компонентами
SCL_BaseTypes.xsd	Определения составных базовых типов, применяемых другими компонентами
SCL_Substation.xsd	Определение синтаксиса в отношении подстанции
SCL_Communication.xsd	Определение синтаксиса в отношении связи
SCL_IED.xsd	Определение синтаксиса в отношении IED-устройства
SCL_DataTypeTemplates.xsd	Определение синтаксиса в отношении шаблона типа данных
SCL.xsd	Определение синтаксиса основной схемы SCL, которое определяет корневой элемент каждого файла SCL

В дальнейших разделах, содержащих определение схемы, предполагается, что файл определения схемы SCL начинается следующим образом:

<xs:schema targetNamespace=«http://www.iec.ch/61850/2003/SCL» xmlns:scl=«http://www.iec.ch/61850/2003/SCL» xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:xs=«http://www.w3.org/2001/XMLSchema» elementFormDefault=«qualified» attributeFormDefault=«unqualified» finalDefault=«extension» version=«n.n»>

Здесь n.n указывает версию языка SCL. Для настоящего стандарта это 1.0.

Схема заканчивается тегом

</xs:schema>

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

UML-схема, приведенная на рисунке 4, дает общее представление о структуре схемы SCL.

Базовый элемент языка SCL является производным от типа схемы tBaseElement, который позволяет, например, содержать определения Private и Text. Кроме того, элемент языка SCL должен содержать один элемент Header (заголовок) типа tHeader и может содержать элементы Substation типа tSubstation, секцию Communication типа tCommunication, элементы IED-устройства типа tIED и секцию DataTypeTemplates типа tDataTypeTemplates. Все типы этих элементов рассмотрены в следующих разделах.

Для некоторых случаев важен используемый значениями формат данных. Во всех случаях, когда это возможно, схема определяет тип данных и, следовательно, их кодировку (лексическое представление). Но даже в тех случаях, когда это невозможно, должно быть использовано кодирование типа данных в соответствии с XML schema. Все значения элементов являются строками XML schema, если иное не выражено явным образом; все значения атрибутов являются нормализованной строкой типа XML schema (XML normalizedString), то есть в них не допускаются символы табуляции и управляющие символы возврата каретки и перевода строки. Дальнейшие ограничения сформулированы в настоящем стандарте, а также в серии стандартов МЭК 61850 (в основном в серии стандартов МЭК 61850-7, МЭК 61850-8-1, МЭК 61850-9-1 и МЭК 61850-9-2). Ссылка на любые типы данных XML schema оформляется префиксом xs:. Например, xs:decimal для кодирования десятичных чисел. Для удобства в таблице 42 приведены общие сведения о кодировании большинства типов, применяемых с языком SCL.

8.2 Расширения языка SCL

8.2.1 Общая часть

Базовый язык SCL, как определено в настоящем стандарте, предназначен для специальных целей, описанных в разделе 5. Однако для выполнения дополнительных задач проектирования и разработки он может быть использован с бульшими или меньшими расширениями — например, дополнительными атрибутами. Кроме того, для уровня SCSM он оставляет несколько определений, зависимых от стека связи. Возможности расширения языка SCL рассмотрены в 8.2.2 - 8.2.7.

8.2.2 Расширения модели данных

Расширения модели данных за счет использования семантически новых LN и DO подчиняются правилам, установленным в серии стандартов МЭК 61850-7 для расширений, и определяются применением языка SCL как метаязыка модели данных, то есть идентификация элементов модели данных не появляется в самом синтаксисе языка. Область имен классов LN, атрибуты DATA и CDC описываются на языке SCL путем заявления соответствующих значений пространств имен в соответствующих атрибутах DATA. Если необходимы дополнительные базовые типы данных, они должны быть определены как расширение схемы.

8.2.3 Дополнительная семантика для существующих элементов синтаксиса

Некоторые языковые элементы SCL, такие, как desc и Text, имеют слабо выраженную семантику, которая может быть расширена за счет некоторых приложений. Некоторые элементы, такие, как элемент параметра P, были специально оставлены открытыми. Семантика (дополнительная семантика) этих элементов должна быть определена на уровне SCSM. Это выполняется путем определения значения type (тип) для параметра P с собственной семантикой.

8.2.4 Ограничения типов данных

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

8.2.5 Пространства имен XML

Всем элементам тегов могут быть добавлены теги (подтеги) и атрибуты. При этом они должны принадлежать заданному пространству имен XML с семантикой, заданной для всех этих элементов. Использованные пространства имен должны быть определены в главном теге (SCL). Это пространство имен не должно быть таким же, как и целевое пространство имен схемы SCL. Для частных пространств имен применяется аббревиатура внутреннего пространства имен, которая начинается со знака e. Пример стандартного расширения для компоновки однолинейной схемы или схемы связи приведен в приложении C. Пространством имени URI данной версии базового языка SCL, которое по умолчанию будет использоваться как пространство имени во всех файлах SCL, является:

xmlns:scl=«http://www.iec.ch/61850/2003/SCL»

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

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

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

8.2.6 Части Private

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

Сущности данных Private появляются на нескольких уровнях SCL. Содержимое этих XML-элементов, как видно из SCL, — прозрачный текст. Если часть Private содержит XML-данные, то она должна использовать явным образом пространство имен, которое не может быть пространством имен SCL. Элемент Private позволяет также делать ссылки на другие файлы через URL на своем атрибуте source (источник).

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

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

Элементы Private имеют тип схемы tPrivate, который определяется следующим образом:

<xs:complexType name=«tPrivate» mixed=«true»> xs:annotation <xs:documentation xml:lang=«en»> Allows an unrestricted mixture of character content, element content and attributes from any namespace other than the target namespace, along with an optional Type attribute <1>. </xs:documentation> </xs:annotation> <xs:complexContent mixed=«true»> <xs:extension base=«tAnyContentFromOtherNamespace»> <xs:attribute name=«type» type=«xs:normalizedString» use=«optional»/> <xs:attribute name=«source» type=«xs:anyURI» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType>

---

<1> Допускается неограниченное смешивание содержания символа, содержания элемента и атрибутов любого пространства имен, кроме целевого пространства имен, наряду с дополнительным атрибутом типа.

Атрибуты элемента Private определены в таблице 2.

Таблица 2

Атрибуты элемента Private

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

8.2.7 Другой синтаксис XML

Для другого XML-файла в целях расширения модели данных SCL дополнительными объектами или атрибутами может применяться совершенно новый стандартизированный или частный синтаксис на основе языка XML. В этом случае в таком новом XML-файле будут определены ссылки на объект, которые содержатся в модели SCL, и при идентификации объектов должна соблюдаться философия присвоения имен, изложенная в настоящем стандарте. Для связи с такими дополнительными XML-файлами может быть использован атрибут source элемента Private.

8.2.8 Краткое заключение: применимость настоящего стандарта для управления расширениями

Инструментальное средство (утилита), заявленное как соответствующее настоящему стандарту, должно, как минимум, управлять расширениями следующим образом:

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

8.2.9 Пример расширения

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

<SCL xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:xsi=«http://www.w3.org/2001/XMLSchema-instance» xsi:schemaLocation=«http://www.iec.ch/61850/2003/SCL SCL.xsd» xmlns:ext=«http://www.private.org»> ext:MyElementThis is my extension element</ext:MyElement> This is my private element ext:dummywith sub-elements</ext:dummy> and a privately defined attribute

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

8.3 Общая структура

Документ SCL — XML начинается с XML-элемента prolog (пролог), затем следуют определенные ниже элементы. Prolog содержит идентификацию версии XML и применяемую кодировку символов. Предпочтительной является кодировка формата UTF-8. В элементе SCL содержится часть полного определения SCL:

<SCL xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:xsi=«http://www.w3.org/2001/XMLSchema-instance» xsi:schemaLocation=«http://www.iec.ch/61850/2003/SCLSCL.xsd»>

где SCL.xsd — конкретный файл, содержащий определение схемы SCL.

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

Элемент SCL должен содержать секцию Header и по меньшей мере одну из следующих секций: Substation, Communication, IED, DataTypeTemplates, — для которых ниже приведено пояснение. Секции Substation и IED могут появиться несколько раз. Рисунок 4 дает общее представление в виде UML-схемы. Корректное определение XML schema приводится далее.

<xs:element name=«SCL»> xs:complexType xs:complexContent <xs:extension base=«tBaseElement»> xs:sequence <xs:element name=«Header» type=«tHeader»> <xs:unique name=«uniqueHitem»> <xs:selector xpath=»./scl:History/scl:Hitem«/> <xs:field xpath=»@version«/> <xs:field xpath=»@revision«/> </xs:unique> </xs:element> <xs:element ref=»Substation» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element ref=«Communication» minOccurs=«0»/> <xs:element ref=«IED» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element ref=«DataTypeTemplates» minOccurs=«0»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

Все элементы являются производными типа tBaseElement и поэтому наследуют возможность содержания элементов Text и Private, а также могут содержать элементы и атрибуты из других пространств имен. Элементы, являющиеся производными подтипов tUnNaming, tNaming и tIDNaming, дополнительно наследуют атрибут desc.

8.4 Обозначение объекта и сигнала

Модель SCL допускает два вида обозначения объекта:

1. технический ключ, который используется в технических чертежах и для идентификации сигнала. Он содержится в атрибуте name как идентификация каждого объекта. Если это значение используется как ссылка на объект, оно содержится в имени атрибута, которое начинается со строки, обозначающей тип ссылки на целевой объект, и заканчивается строкой «Name». Технический ключ используется с языком SCL для ссылок на другие объекты. Следует обратить внимание на то, что в иерархии объектов имя является относительной идентификацией;

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

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

8.4.1 Обозначения объектов в иерархии объектов

Для иерархически структурированных объектов структуры подстанции и структуры продукта атрибуты name и desc каждого объекта содержат только ту часть, которая определяет объект на данном уровне иерархии. Полной объектной ссылкой является имя пути, она состоит из конкатенации всех частей имени верхних уровней иерархии, вплоть до данного уровня. Уникальность ссылок после конкатенации должна обеспечиваться в процессе конфигурирования. Эта цель достигается за счет использования соглашения о синтаксисе, как указано в МЭК 61346-1. Главным образом это значит, что имена всех уровней могут быть напрямую каскадно сцеплены с именем пути, если имя верхнего уровня заканчивается числом, а имя нижнего начинается с текстового символа. В противном случае между ними должен быть поставлен промежуточный знак — как правило, это точка (.). Если имя в пределах уровня — пустая строка, никакой разграничивающий знак на этом уровне не нужен. Для отображения имени на уровне SCSMs или по МЭК 61346-1 могут быть указаны другие разделительные знаки. Кроме обязательного использования МЭК 61346-1 для синтаксиса имен настоятельно рекомендуется использовать всю серию МЭК 61346 для выведения функционального имени и имени IED-продукта в качестве технических ключей. В этом случае следует иметь в виду, что особые разделительные знаки МЭК 61346 типа =, +, — не употребляются с именами SCL. Если имена субструктурированы, разрешено использовать только точку (.).

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

8.4.2 Идентификация сигналов, применяемых в системе связи

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

a) определенная пользователем часть, идентифицирующая LD в процессе (LDName);

b) функционально зависимая часть для различения нескольких LN одного и того же класса в пределах одного и того же IED-устройства/LD (LN-Prefix);

c) имя класса стандартизированного LN и номер экземпляра LN, по которому в пределах одного и того же IED-устройства/LD различаются несколько LN одного и того же класса, имеющих одинаковый префикс;

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

Рисунок 5 — Элементы идентификации сигнала согласно определению МЭК 61850-7-2

Части имени 2 и 3 на рисунке 5 образуют вместе имя LN и служат для различения разных экземпляров LN в пределах одного и того же LD в IED-устройстве. Обе части могут быть использованы свободно. Функционально зависимый префикс LN используется в основном во время функционального проектирования или для связывания инстанцируемого LN на IED-устройстве с некоторой семантикой процесса. Номер экземпляра LN части имени 3 служит для различения инстанцируемых LN, которые еще не привязаны к семантике процесса (например, CSWI, не привязанный к некоторому конкретному типу выключателя, имеет префикс=«») или имеют одинаковый непустой префикс.

Отображение этих частей имени сигнала на фактические имена сигнала зависит от стека и отображения и поэтому содержится в МЭК 61850-8-1, МЭК 61850-9-1 и МЭК 61850-9-2. С точки зрения языка SCL этого достаточно для определения содержания этих частей для конкретной SA-системы. Однако в МЭК 61850-8-1, МЭК 61850-9-1 и МЭК 61850-9-2 содержатся дальнейшие ограничения по длине и содержанию частей имени.

Секция определения DataTypeTemplates языка SCL и стандартизированные имена в соответствии с МЭК 61850-7-3 и МЭК 61850-7-4 устанавливают возможные значения частей имени 3 и 4, приведенные на рисунке 5. Номер экземпляра LN и префикс определены в секции IED-устройства языка SCL.

Для частей имени 1 и 2 на рисунке 5 имеются две опции (см. также рисунки 6 и 7). Для обеих опций на рисунке 5 в данном IED-устройстве используется разделение части имени 1 на IEDName (имя IED-устройства) и LDInst (имя экземпляра LD):

1. функционально зависимое присвоение имен: часть имени 1 на рисунке 5 - это имя объекта секции Substation с присоединенным LN. Если это PrimaryDevice, следует использовать части имени из имени подстанции как части 1 для имени присоединения, а также использовать имя PrimaryDevice как часть 2 (возможно, с последующим именем подразряда оборудования). Необходимо выполнить каскадное сцепление экземпляров LD IED-устройств (IED LD Inst) с частью 1. Если LN прикрепляются к уровням выше уровня присоединения, часть 1 должна быть соответственно сокращена, а часть 2 на рисунке 5 остается пустой или может быть использована для уровня, к которому прикреплен LN;

2. продукт-зависимое присвоение имен: часть 1 на рисунке 6 - это имя IED-устройства в секции IED-устройства (продукт), на котором сконфигурирован LN, каскадно сцепленный с номером экземпляра LD. Часть 2 остается, как предопределено в IED-устройстве (см. рисунок 7).

Рисунок 6 — Элементы имени сигнала при функциональном присвоении имен

Рисунок 7 — Элементы имени сигнала при продукт-зависимом присвоении имени

Модель языка SCL оставляет обе опции открытыми, но дает части Header возможность определения: использовать во время связи при присвоении имен сигналам опцию 1 (функциональное присвоение имен) или опцию 2 [продукт-зависимое присвоение имен см. перечисление 2)]. Рекомендуется использовать номер экземпляра LN таким образом, чтобы класс LN и номер экземпляра LN вместе всегда были уникальны. Это позволяет позднее изменить способ присвоения имен (наличие/отсутствие префикса) и даже заменить предконфигурированные префиксы префиксами, относящимися к функциональной структуре. Использование этих опций может, однако, быть ограничено в тех случаях, когда IED-устройство имеет фиксированный префикс и номер экземпляра LN, то есть для определенного экземпляра LN это исключает возможность его последующего изменения. В этом случае может быть выбрано только продукт-зависимое присвоение имен.

8.4.3 Пример присвоения имен

На рисунке 8 показан пример IED-устройства с LN, которые управляют работой выключателя QA1 присоединения Q1 на уровне напряжения E1. Присвоение имени выполняют в соответствии с серией стандартов МЭК 61346. В данном примере IED-устройство как продукт имеет ту же часть обозначения продукта верхнего уровня соответственно присоединению (-E1Q1), которую управляемый выключатель QA1 имеет в своем функциональном обозначении (=E1Q1QA1). На рисунке 8 показаны результирующие ссылки в различных структурах и результирующая ссылка LN для связи.

Рисунок 8 — Имена в различных структурах объектной модели

Если теперь данным DATA в логическом узле LN2 класса логического узла CSWI в логическом устройстве LD2 присвоить имена из структуры функции, тогда ссылка на LN согласно МЭК 61850-7-2 будет E1Q1LD2/QA1CSWI2. Если бы ссылка была взята из структуры продукта, она бы выглядела как E1Q1SB1LD2/CSWI2. Следует обратить внимание на то, что полное имя в каждом случае должно быть уникально в пределах системы, как показано на примере обоих вышеупомянутых имен. Однако в случае функционального присвоения имени ссылка E1Q1LD2 логического устройства LD сама по себе не обязательно должна быть уникальна в пределах системы (только в пределах IED-устройства), потому что может быть другое IED-устройство в пределах присоединения E1Q1 с логическим устройством LD2. Только отношение E1Q1QA1CSWI2 к IED-устройству E1Q1SB1 в ссылке из структуры Substation на IED-устройства позволяет найти правильное IED-устройство для данного LD, и тогда E1Q1LD2 является уникальным идентификатором LD в данном IED-устройстве.

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

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

9 Элементы синтаксиса языка SCL

9.1 Заголовок

Заголовок служит для идентификации файла конфигурации языка SCL и его версии, а также для специфицирования опций для отображения имен на сигналы. UML-схема, приведенная на рисунке 9, дает общее представление о его структуре.

Рисунок 9 — UML-схема секции Header

Далее приводится часть определения XML schema.

<xs:complexType name=«tHeader»> xs:sequence <xs:element name=«Text» type=«tText» minOccurs=«0»/> <xs:element name=«History» minOccurs=«0»> xs:complexType xs:sequence <xs:element name=«Hitem» type=«tHitem» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name=«id» type=«xs:normalizedString» use=«required»/> <xs:attribute name=«version» type=«xs:normalizedString»/> <xs:attribute name=«revision» type=«xs:normalizedString» default=«»/> <xs:attribute name=«toolID» type=«xs:normalizedString»/> <xs:attribute name=«nameStructure» use=«required»> xs:simpleType <xs:restriction base=«xs:Name»> <xs:enumeration value=«FuncName»/> <xs:enumeration value=«IEDName»/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType>

Таблица 3

Атрибут	Описание
id (идентификатор)	Строка, идентифицирующая данный файл на языке SCL, обязательна (может быть пустой)
version (версия)	Версия этого файла конфигурации на языке SCL (может быть пустой)
revision (модификация)	Модификация данного файла конфигурации на языке SCL, по умолчанию пустая строка, означающая исходное состояние перед любой модификацией
toolID (идентификация средства программирования)	Заданная изготовителем идентификация инструментального средства, которая была использована для создания файла на языке SCL
nameStructure (структура имени)	Элемент, который показывает, строятся имена сигналов системы связи из структуры функций подстанции (FuncName) или из структуры IED-продукта (IEDName)

<xs:complexType name=«tText» mixed=«true»> xs:annotation <xs:documentation xml:lang=«en»>Allows an unrestricted mixture of character content and element content and attributes from any namespace other than the target namespace. <2> </xs:documentation> </xs:annotation> <xs:complexContent mixed=«true»> <xs:extension base=«tAnyContentFromOtherNamespace»> <xs:attribute name=«source» type=«xs:anyURI» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType>

---

<2> Допускается неограниченное смешивание содержания символа, содержания элемента и атрибутов любого пространства имен, кроме целевого пространства имен.

Вместо размещения текста в этом элементе может быть также сделана ссылка на другой файл как URI в атрибуте source (источник).

Примечание — Элемент синтаксиса Text для пояснительного текста используется несколько раз, главным образом во всех элементах, производных от tBaseElement (см. 8.1 и A.1, приложение A).

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

<xs:complexType name=«tHitem» mixed=«true»> xs:annotation <xs:documentation xml:lang=«en»> Allows an unrestricted mixture of character content and element content and attributes from any namespace other than the target namespace, along with the 6 following attributes: Version, Revision, When, Who, What, and Why <3> </xs:documentation> </xs:annotation> <xs:complexContent mixed=«true»> <xs:extension base=«tAnyContentFromOtherNamespace»> <xs:attribute name=«version» type=«xs:normalizedString» use=«required»/> <xs:attribute name=«revision» type=«xs:normalizedString» use=«required»/> <xs:attribute name=«when» type=«xs:normalizedString» use=«required»/> <xs:attribute name=«who» type=«xs:normalizedString»/> <xs:attribute name=«what» type=«xs:normalizedString»/> <xs:attribute name=«why» type=«xs:normalizedString»/> </xs:extension> </xs:complexContent> </xs:complexType>

---

<3> Допускается неограниченное смешивание содержания символа, содержания элемента и атрибутов любого пространства имен кроме целевого пространства имен, наряду с со следующими атрибутами: Version, Revision, When, Who, What, Why.

История модификаций содержит несколько элементов записей. Каждый элемент идентифицирует ранее согласованную версию данного файла SCL. Текст внутри элементов может служить для изложения дальнейших пояснений к данной версии.

Таблица 4

Атрибуты элемента History (Hitem)

Атрибут	Описание
version	Версия данной записи в историю
revision	Модификация данной записи в историю
when	Когда была выпущена версия/модификация
who	Кто составил/согласовал данную версию/модификацию
what	Что изменилось со времени последнего согласования
why	Почему было внесено изменение

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

<Header id=«1KHL1000546» version=«1» revision=» « toolId=»mySystemTool V1.2» nameStructure=«FuncName»>My SA Project </Header

9.2 Описание подстанции

Секция Substation служит для описания функциональной структуры подстанции и идентификации основных устройств и их электрических соединений. Для производственного процесса или для описания всех электрических сетей можно получить несколько секций подстанции — по одной на каждую подстанцию, обслуживаемую SA-системой. Посредством LN, присоединенных к элементам основной системы, данная секция дополнительно определяет функциональность SA-системы (например, в файле SSD) или, если LN уже назначены IED-устройствам (файл SCD), отношение IED-функций к энергосистеме.

Следует обратить внимание, что атрибут name является обязательным при всех условиях и не может быть пустой строкой. Если секция Substation используется как шаблон в файле ICD, то имя должно быть TEMPLATE. Значение имени является также глобальной идентификацией подстанции, потому что оно должно быть уникальным для всех подстанций, содержащихся в файле SCL.

Если отсутствует атрибут desc, его значением по умолчанию является пустая строка.

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

Токопроводящее оборудование (ConductingEquipment) может подключаться только на уровне присоединения. Экземпляры LN на одном и том же уровне должны иметь различную идентификацию.

UML-схема, приведенная на рисунке 10, дает общее представление о секции Substation.

Соответствующая часть схемы выглядит следующим образом:

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

<xs:include schemaLocation=«SCL_BaseTypes.xsd»/> <xs:attributeGroup name=«agVirtual»> <xs:attribute name=«virtual» type=«xs:boolean» use=«optional» default=«false»/> </xs:attributeGroup> <xs:complexType name=«tLNodeContainer» abstract=«true»> xs:complexContent <xs:extension base=«tNaming»> xs:sequence <xs:element name=«LNode» type=«tLNode» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tPowerSystemResource» abstract=«true»> xs:complexContent <xs:extension base=«tLNodeContainer»/> </xs:complexContent> </xs:complexType> <xs:complexType name=«tEquipmentContainer» abstract=«true»> xs:complexContent <xs:extension base=«tPowerSystemResource»> xs:sequence <xs:element name=«PowerTransformer» type=«tPowerTransformer» minOccurs=«0» maxOccurs=«unbounded»> <xs:unique name=«uniqueWindingInPowerTransformer»> <xs:selector xpath=»./scl:TransformerWinding«/> <xs:field xpath=»@name«/> </xs:unique> </xs:element> <xs:element name=»GeneralEquipment» type=«tGeneralEquipment» minOccurs=«0» maxOccurs=«unbounded»/>

</xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tEquipment» abstract=«true»> xs:complexContent <xs:extension base=«tPowerSystemResource»> <xs:attributeGroup ref=«agVirtual»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tAbstractConductingEquipment» abstract=«true»> xs:complexContent <xs:extension base=«tEquipment»> xs:sequence <xs:element name=«Terminal» type=«tTerminal» minOccurs=«0» maxOccurs=«2»/> <xs:element name=«SubEquipment» type=«tSubEquipment» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tConductingEquipment»> xs:complexContent <xs:extension base=«tAbstractConductingEquipment»> <xs:attribute name=«type» type=«tCommonConductingEquipmentEnum» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tSubEquipment»> xs:complexContent <xs:extension base=«tPowerSystemResource»> <xs:attribute name=«phase» type=«tPhaseEnum» use=«optional» default=«none»/> <xs:attributeGroup ref=«agVirtual»/> </xs:extension> </xs:complexContent> </xs:complexType>

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

<xs:complexType name=«tSubstation»> xs:complexContent <xs:extension base=«tEquipmentContainer»> xs:sequence <xs:element name=«VoltageLevel» type=«tVoltageLevel» maxOccurs=«unbounded»> <xs:unique name=«uniqueBayInVoltageLevel»> <xs:selector xpath=»./scl:Bay«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniquePowerTransformerInVoltageLevel«> <xs:selector xpath=»./scl:PowerTransformer«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueGeneralEquipmentInVoltageLevel«> <xs:selector xpath=»./scl:GeneralEquipment«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueChildNameInVoltageLevel«> <xs:selector xpath=»./*«/> <xs:field xpath=»@name«/> </xs:unique> </xs:element> <xs:element name=»Function» type=«tFunction» minOccurs=«0» maxOccurs=«unbounded»> <xs:unique name=«uniqueSubFunctionInFunction»> <xs:selector xpath=»./scl:SubFunction«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueGeneralEquipmentInFunction«> <xs:selector xpath=»./scl:GeneralEquipment«/> <xs:field xpath=»@name«/> </xs:unique> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>»

Элемент Substation принадлежит к типу tSubstation, как показано выше. Это tEquipmentContainer, то есть наряду с PowerTransformer он может содержать LNode. Кроме того, он содержит по меньшей мере один уровень напряжения и дополнительно несколько элементов Function. Системные функции или оборудование, не принадлежащие энергосистеме, могут быть описаны с помощью элемента Function.

Общий элемент Substation (тип tSubstation), к которому обращается элемент SCL, дополнительно содержит несколько ограничений идентичности:

• в пределах Substation не может быть двух элементов VoltageLevel (уровень напряжения) с одинаковым именем;
• в пределах Substation не может быть двух элементов PowerTransformer с одинаковым именем;
• в пределах Substation не может быть двух элементов Function с одинаковым именем;
• в пределах Substation не может быть двух элементов LNode с одинаковым сочетанием InInst, InClass, iedName, IdInst и префиксом;
• кроме того, во избежание любых неясностей в пределах Substation не может быть двух прямых дочерних элементов с одинаковым именем.

Ограничения:

• имя подстанции должно быть уникальным в пределах SCL-файла;
• для шаблона основной системы в пределах ICD-файла имя подстанции должно быть TEMPLATE. В одном SCL-файле может быть максимум один шаблон подстанции;
• в пределах Substation атрибут pathName (имя пути) узла связи ConnectivityNode действует как ключ (ConnectivityNode может появится на уровне присоединения ниже Substation). Это подразумевает отсутствие двух элементов ConnectivityNode с одинаковым pathName, то есть атрибут ConnectivityNode каждого вывода Terminal в данной подстанции должен обращаться к одному из этих ключей.

9.2.1 Уровень напряжения

Как показано ниже, элемент VoltageLevel относится к типу tVoltageLevel. Он имеет дополнительный элемент Voltage (напряжение) типа tVoltage, который может использоваться для констатации напряжения на данном уровне напряжения. Кроме того, будучи tEquipmentContainer, он может содержать логические узлы LNode, общее оборудование GeneralEquipment и силовые трансформаторы PowerTransformer. Он содержит также одно или несколько присоединений, реализуемых через элемент Bay.

<xs:complexType name=«tVoltageLevel»> xs:complexContent <xs:extension base=«tEquipmentContainer»> xs:sequence <xs:element name=«Voltage» type=«tVoltage» minOccurs=«0»/> <xs:element name=«Bay» type=«tBay» maxOccurs=«unbounded»> <xs:unique name=«uniquePowerTransformerInBay»> <xs:selector xpath=»./scl:PowerTransformer«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueConductingEquipmentInBay«> <xs:selector xpath=»./scl:ConductingEquipment«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueGeneralEquipmentInBay«> <xs:selector xpath=»./scl:GeneralEquipment«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueChildNameInBay«> <xs:selector xpath=»./*«/> <xs:field xpath=»@name«/> </xs:unique> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>»

Определено несколько ограничений идентичности (фактически они определены выше для типа tSubstation):

• в пределах VoltageLevel не может быть двух элементов Bay с одинаковым именем;
• в пределах VoltageLevel не может быть двух прямых дочерних элементов PowerTransformer с одинаковым именем;
• в пределах VoltageLevel не может быть двух прямых дочерних элементов GeneralEquipment с одинаковым именем;
• кроме того, во избежание любых неясностей в пределах уровня напряжения VoltageLevel не может быть двух прямых дочерних элементов с одинаковым именем.

Ограничения:

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

9.2.2 Уровень присоединения

Элемент Bay относится к типу tBay. Как контейнер оборудования, он может содержать силовые трансформаторы, общее оборудование и логические узлы. Кроме того, он может размещать токопроводящее оборудование ConductingEquipment и узлы связи ConnectivityNode, которые служат для определения топологических соединений между оборудованием в пределах однолинейной схемы.

<xs:complexType name=«tBay»> xs:complexContent <xs:extension base=«tEquipmentContainer»> xs:sequence <xs:element name=«ConductingEquipment» type=«tConductingEquipment» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«ConnectivityNode» type=«tConnectivityNode» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

Элемент ConnectivityNode позволяет явным образом описывать узлы связи в пределах данного присоединения; к нему, как к tLNodeContainer, могут быть присоединены логические узлы LNode. Его подэлемент Text может служить для содержания некоторых свободно используемых описаний. Его атрибут name определяет экземпляр ConnectivityNode в пределах присоединения; его pathname является абсолютной ссылкой в пределах SCL-файла. Имя пути строится путем каскадного сцепления всех ссылок верхнего уровня, вплоть до имени узлов связи через знак дроби. Например, если узел связи L1 находится в пределах присоединения Q2 уровня напряжения E1 подстанции Baden, тогда имя пути будет Baden/E1/Q2/L1.

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

<xs:complexType name=«tConnectivityNode»> xs:complexContent <xs:extension base=«tLNodeContainer»> <xs:attribute name=«pathName» type=«tRef» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType>

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

Определено несколько ограничений идентичности (фактически они определены для типа tVoltageLevel — см. код в 9.2.1):

• в пределах Bay не может быть двух прямых дочерних элементов PowerTransformer с одинаковым именем;
• в пределах Bay не может быть двух прямых дочерних элементов ConductingEquipment с одинаковым именем;
• в пределах Bay не может быть двух прямых дочерних элементов GeneralEquipment с одинаковым именем;
• кроме того, во избежание любых неясностей в пределах Bay не может быть двух прямых дочерних элементов с одинаковым именем.

Пример секции подстанции можно найти в 9.2.7.

9.2.3 Силовое (первичное) оборудование

Силовое оборудование подразделяют на силовой трансформатор PowerTransformer и токопроводящее оборудование ConductingEquipment. PowerTransformer может появиться в каждом контейнере оборудования. Он содержит обмотки трансформатора как специальный вид ConductingEquipment. Для каждой обмотки трансформатора может быть назначен регулятор РПН. Все остальное оборудование ConductingEquipment может появиться только в присоединениях. Все оборудование является производным базового типа tEquipment, а ConductingEquipment является производным типа tAbstractConductingEquipment.

UML-схема, приведенная на рисунке 11, дает общее представление об иерархических отношениях между единицами оборудования.

Рисунок 11 — UML-схема. Наследование типов оборудования и отношения

Соответствующая часть схемы выглядит следующим образом:

<xs:complexType name=«tEquipment» abstract=«true»> xs:complexContent <xs:extension base=«tPowerSystemResource»> <xs:attributeGroup ref=«agVirtual»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tAbstractConductingEquipment» abstract=«true»> xs:complexContent <xs:extension base=«tEquipment»> xs:sequence <xs:element name=«Terminal» type=«tTerminal» minOccurs=«0» maxOccurs=«2»/> <xs:element name=«SubEquipment» type=«tSubEquipment» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tConductingEquipment»> xs:complexContent <xs:extension base=«tAbstractConductingEquipment»> <xs:attribute name=«type» type=«tCommonConductingEquipmentEnum» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tSubEquipment»> xs:complexContent <xs:extension base=«tPowerSystemResource»> <xs:attribute name=«phase» type=«tPhaseEnum» use=«optional» default=«none»/> <xs:attributeGroup ref=«agVirtual»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tPowerTransformer»>

xs:complexContent <xs:extension base=«tEquipment»> xs:sequence <xs:element name=«TransformerWinding» type=«tTransformerWinding» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«type» type=«tPowerTransformerEnum» use=«required» fixed=«PTR»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tTransformerWinding»> xs:complexContent <xs:extension base=«tAbstractConductingEquipment»> xs:sequence <xs:element name=«TapChanger» type=«tTapChanger» minOccurs=«0»/> </xs:sequence> <xs:attribute name=«type» type=«tTransformerWindingEnum» use=«required» fixed=«PTW»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tTapChanger»> xs:complexContent <xs:extension base=«tPowerSystemResource»> <xs:attribute name=«type» type=«xs:Name» use=«required» fixed=«LTC»/> <xs:attributeGroup ref=«agVirtual»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tGeneralEquipment»> xs:complexContent <xs:extension base=«tEquipment»> <xs:attribute name=«type» type=«tGeneralEquipmentEnum» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType>

Следует обратить внимание, что все оборудование типа tEquipment и все подразряды оборудования типа tSubEquipment, а также переключатель обмоток (РПН) tTapChanger под нормальными атрибутами name и desc имеют также дополнительный виртуальный атрибут agVirtual. Если секция Substation используется просто для функционально зависимого присвоения имен, она не используется на самом деле. Однако есть такие приложения, в которых функции (LN) вычисляют значения, принадлежащие некоторому виртуальному оборудованию, например, фазный ток рассчитывается из измеренных числовых значений двух других фаз. В этом случае важно знать, что трехфазный трансформатор тока CT присутствует только виртуально, а не в действительности. Это можно указать путем установки атрибута virtual на true (истина). Значение по умолчанию будет false (ложь).

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

Таблица 5

Коды типов первичных аппаратных устройств

Код типа	Значение	Количество выводов (соединения с различными узлами связи)
CBR	Выключатель	2
DIS	Разъединитель или заземляющий разъединитель	2
VTR	Трансформатор напряжения	1
CTR	Трансформатор тока	2
PTW	Обмотка силового трансформатора	1
PTR	Силовой трансформатор	Неявно через обмотки
LTC	РПН	Часть обмоток
GEN	Генератор	1
CAP	Конденсаторная батарея	1/2
REA	Реактор	1/2
CON	Преобразователь	1/2
MOT	Двигатель	1
EFN	Катушка-компенсатор емкостного тока при замыкании на землю (дугогасящий реактор)	1
PSH	Силовой шунт	2
AXN	Вспомогательная сеть	Отсутствует
BAT	Аккумуляторная батарея	1
BSH	Высоковольтный ввод	2
CAB	Силовой кабель	2
GIL	Линия с элегазовой изоляцией	2
LIN	Воздушная линия электроснабжения или участок линии: участки линии, соединенные узлами связи, образуют линию электропередачи. Участок линии в пределах подстанции может быть использован для присоединения, например, специальных LN или физической линии. Для участка линии элегазового распредустройства в качестве альтернативы может быть использована линия с элегазовой изоляцией GIL	2
RRC	Вращающийся реактивный элемент	1
SAR	Разрядник для защиты от перенапряжений	1
TCF	Тиристорный преобразователь частоты	2
TCR	Тиристорный реактивный элемент	2
IFL	Питающая линия; объект, ограничивающий подстанцию; моделирует возможную питающую линию энергосети за пределами подстанции на границе однолинейной схемы	1

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

Определение вывода (Terminal) содержит ссылку на узел связи, к которому подключено оборудование (ConnectivityNode в модели на рисунке 2), и дополнительно — имя вывода оборудования, которое соединяет с этим узлом связи. В качестве ссылки на ConnectivityNode используют имя пути, а также список атрибутов (таблица 6). Оба являются обязательными. Ссылка на имя пути позволяет проверить совместимость соединения уже на уровне языка XML schema, тогда как список атрибутов легче интерпретировать большинству программных средств.

<xs:complexType name=«tTerminal»> xs:complexContent <xs:extension base=«tUnNaming»> <xs:attribute name=«name» type=«tAnyName» use=«optional»/> <xs:attribute name=«connectivityNode» type=«tRef» use=«required»/> <xs:attribute name=«substationName» type=«tName» use=«required»/> <xs:attribute name=«voltageLevelName» type=«tName» use=«required»/> <xs:attribute name=«bayName» type=«tName» use=«required»/> <xs:attribute name=«cNodeName» type=«tName» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType>

Атрибуты элемента Terminal (вывод)

Атрибут	Описание
Name	Дополнительное относительное имя вывода на этом оборудовании (Equipment). Значением по умолчанию является пустая строка; это означает, что имя ConnectivityNode является также идентификацией вывода
Desc	Пояснительный текст для вывода
ConnectivityNode	Имя пути узла связи, к которому подключен данный вывод. Если элемент Equipment не будет подключен, элемент Terminal полностью удаляется
SubstationName	Имя подстанции, содержащее ConnectivityNode
VoltageLevelName	Имя уровня напряжения, содержащее ConnectivityNode
BayName	Имя присоединения, содержащее ConnectivityNode
CnodeName	Имя (относительное имя) ConnectivityNode в пределах подключения

Идентификация вывода оборудования в целом нужна, только если устройство поляризует поток мощности, то есть соединения не являются взаимозаменяемыми. Если атрибут имени вывода оставлен пустым и при этом требуется обозначение вывода, значением по умолчанию будет идентификация оборудования (substationName, voltageLevelName, bayName, equipmentName) вместе с идентификацией узла связи ConnectivityNode.

Имеется один предопределенный узел связи с именем grounded (заземленный). Он используется для моделирования потенциала земли. Таким образом, заземляющий разъединитель представляет собой изолятор (тип оборудования DIS), который присоединен с одной стороны к узлу связи grounded. Утилита генерации по своему усмотрению путем генерации соответствующих pathNames принимает решение о заземлении одного-единственного узла для всей подстанции или каждого отдельного узла в точке присоединения либо принимает какое-то среднее решение — например, о заземлении одного узла на присоединение или на уровень напряжения.

9.2.4 Уровень SubEquipment (подразряд оборудования)

SubEquipment — это компонент силового оборудования. Например, насос — это компонент выключателя, а фаза выключателя — это компонент целого выключателя. Он в основном позволяет специфицировать отношения фаз LN. Поэтому язык SCL позволяет использование SubEquipment только для Conducting Equipment.

<xs:complexType name=«tSubEquipment»> xs:complexContent <xs:extension base=«tPowerSystemResource»> <xs:attribute name=«phase» type=«tPhaseEnum» use=«optional» default=«none»/> <xs:attributeGroup ref=«agVirtual»/> </xs:extension> </xs:complexContent> </xs:complexType>

Атрибуты элемента SubEquipment

Атрибут	Описание
Name	Идентификация подразряда оборудования по отношению к обозначению оборудования (например, L1 по отношению к фазе A)
Desc	Текстовое пояснение к подустройству по отношению к устройству
Phase	Фаза, к которой относится подустройство. Допустимы следующие значения фаз: A, B, C, N (нейтраль, все (что означает все три фазы) и ни одной (по умолчанию, что означает фазонезависимый)
Virtual	Если просто вычисляются значения подразряда оборудования (например, фазного трансформатора тока), которого не существует в действительности, устанавливается логическая единица (true). Дополнительно значение по умолчанию есть логический нуль (false)

9.2.5 Логические узлы и функции подстанции

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

<xs:complexType name=«tLNode»> xs:complexContent <xs:extension base=«tUnNaming»> <xs:attribute name=«InInst» type=«tAnyName» use=«optional» default=«»/> <xs:attribute name=«InClass» type=«tLNClassEnum» use=«required»/> <xs:attribute name=«iedName» type=«tName» use=«optional» default=«None»/> <xs:attribute name=«IdInst» type=«tAnyName» use=«optional» default=«»/> <xs:attribute name=«prefix» type=«tAnyName» use=«optional» default=«»/> <xs:attribute name=«InType» type=«tName» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType>

LN и его функция определяются атрибутами элемента. Элемент LNode может быть использован в пределах SSD для функциональной спецификации, без назначения IED-устройству. В этом случае имя устройства iedName должно быть None. Для более детальной спецификации InType может обращаться к определению типа LN (0), а оно далее также определяет дополнительные данные DATA, которые должны существовать в этом конкретном случае, либо некоторые числовые значения, которые должны иметь некоторые параметры (конфигурации). Если логический узел размещен в IED-устройстве в пределах SCD позднее, то значение атрибута InType может игнорироваться или применяться для проверки соответствия требованиям типа LN, используемого на IED-устройстве.

Атрибуты элемента LNode

Атрибут	Описание
InInst	Идентификация экземпляра LN. Может отсутствовать только для InClass=LLN0, здесь значением является пустая строка
InClass	Класс LN по определению согласно серии стандартов МЭК 61850-7
iedName	Имя IED-устройства, содержащего LN; none (отсутствует), если используется для спецификации (по умолчанию, если атрибут не задан)
IdInst	Экземпляр LD на IED-устройстве, содержащем LN. Пустой относительно нерелевантен, если используется для спецификации
prefix	Префикс LN, используемого в IED-устройстве (при необходимости; если не задан — по умолчанию пустая строка)
InType	Определение типа LN, содержащее более детальную функциональную спецификацию. Может быть пустым, если LN назначен IED-устройству
Примечание — Для LLN0 значение inst — пустая строка. Во всех остальных случаях значение — целое число без знака.

Имя устройства iedName идентифицирует IED-устройство, где резидентно находится LN, и IdInst логического устройства LD в пределах данного IED-устройства, к которому принадлежит LN. Затем атрибуты prefix, InClass и inst (означающие идентификацию экземпляра LN согласно серии стандартов МЭК 61850-7) идентифицируют логический узел в пределах данного LD. Таким образом, устанавливается связь между функцией подстанции и SA-системой.

9.2.6 Несиловое оборудование

Для того чтобы смоделировать соединение находящихся в IED-устройстве LN с другими функциями, не связанными с энергосистемой (такими, как противопожарное оборудование или контроль доступа), в секции Substation содержится элемент Function, который, в свою очередь, содержит произвольное число элементов SubFunction. Оба элемента являются контейнерами LN и могут, если необходимо, содержать также GeneralEquipment. Функция Function и подфункция Subfunction, как и сама Substation, имеют атрибуты name и desc и могут также содержать элементы Text и Private. Однако соединения между единицами оборудования не определяются.

<xs:complexType name=«tFunction»> xs:complexContent <xs:extension base=«tPowerSystemResource»> xs:sequence <xs:element name=«SubFunction» type=«tSubFunction» minOccurs=«0» maxOccurs=«unbounded»> <xs:unique name=«uniqueGeneralEquipmentInSubFunction»> <xs:selector xpath=»./scl:GeneralEquipment«/> <xs:field xpath=»@name«/> </xs:unique> </xs:element> <xs:element name=»GeneralEquipment» type=«tGeneralEquipment» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tSubFunction»> xs:complexContent <xs:extension base=«tPowerSystemResource»> xs:sequence <xs:element name=«GeneralEquipment» type=«tGeneralEquipment» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

Тип оборудования, допустимый в пределах Function и Subfunction, называется GeneralEquipment.

<xs:complexType name=«tGeneralEquipment»> xs:complexContent <xs:extension base=«tEquipment»> <xs:attribute name=«type» type=«tGeneralEquipmentEnum» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType>

В списке типов оборудования (см. таблицу 5) это позиции AXN, BAT, MOT. Кроме того, могут быть использованы все частные коды (содержащие только прописные буквы, начинающиеся с E).

9.2.7 Пример секции подстанции

Приводимый ниже пример языка SCL для системной спецификации SSD содержит секцию Substation для подстанции baden220_132 с одним трансформатором T1 на уровнях напряжения между D1 и E1 и присоединением E1Q1.

Трансформатор T1 имеет две обмотки — W1 и W2. Обмотка W1 подключена на напряжении 220 кВ к присоединению типа Q1 на уровне напряжения D1, узел связи L1. Обмотка W2 подключена на напряжении 110 кВ к присоединению типа Q2 на уровне напряжения E1. Из присоединения логических узлов в файле SSD можно видеть, что на уровне transformer трансформатор тока выполняет измерение и на этом же уровне выполняется дифференциальная защита. Со стороны 220 кВ (присоединение D1Q1) имеется дистанционная защита.

Присоединение E1Q2 на напряжении 132 кВ содержит автоматический выключатель QA1 и шинный разъединитель QB1 (оба подключены с помощью электрического соединения к узлу связи L0), а также трансформатор напряжения U1, подключенный к узлу связи L2, и трансформатор тока 11, подключенный между узлами связи L1 и L2. Узел связи в пределах одного присоединения задан явным образом. Логический узел типа CSWI управляет всеми выключателями, а логический узел CILO управляет блокировками. Ассоциации для IED-устройств не заданы, так как это только функциональная спецификация, поэтому имя устройства iedName по умолчанию будет None. Кроме того, здесь не используется возможность более детального определения с помощью ссылок InType.

<SCL xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:xsi=«http://www.w3.org/2001/XMLSchema-instance» xsi:schemaLocation=«http://www.iec.ch/61850/2003/SCL SCL.xsd»> 220
132

9.3 Описание IED-устройства

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

Секция IED-устройства описывает конфигурацию (предконфигурацию) IED-устройства: его точки доступа, LD и LN, инстанцированные на нем. Кроме того, она определяет возможности IED-устройства в терминах предлагаемых услуг связи, а также инстанцированные данные DO с их типом LNType и значениями по умолчанию или по конфигурации. Каждому IED-устройству должна соответствовать одна IED-секция. IED-имя (атрибут name) в пределах файла должно быть уникальным. Если в файле размещаются только описания предконфигурированных IED-устройств, имя должно быть TEMPLATE и должно указывать на отсутствие привязки IED-устройства к определенному месту в проекте. Средства управления конфигурацией системы должны управлять им как IED-типом, то есть типом предконфигурированного продукта, из которого может быть создано произвольное количество экземпляров продукта (аппаратных средств).

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

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

• сообщения о синхронизации точного времени;
• GSE-сообщения;
• выборочные измеренные значения.

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

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

Точка доступа может принадлежать серверу с логическими устройствами, которые содержат LN. В этом случае сервер точки доступа предоставляет доступ к LD и LN. В то же время LN как клиенты могут использовать все точки доступа IED-устройства (а не только точки доступа сервера) для доступа к данным (на LN на серверах) на других IED-устройствах. Если контроль IED-устройства должен осуществляться дистанционно, точка доступа всегда требует сервера, потому что для управления и контроля IED-устройства используются LN0 и LPHD логического устройства сервера. Лишь в том случае, когда все LN на IED-устройстве используют точку доступа только как клиенты и не выполняется контроль IED-устройства, IED-устройство может быть использовано без сервера.

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

Рисунок 12 — Структура IED-устройства и точки доступа

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

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

Более подробно о коротких адресах см. в 9.5.4.3.

Рисунки 13 - 15 дают общее представление об IED-зависимой части схемы, представленной в виде UML-схем.

Рисунок 13 — UML-описание части схемы, относящейся к IED-устройству, — база

Рисунок 14 — UML-описание части схемы, относящейся к IED-устройству, — блоки управления

Рисунок 15 — UML-описание части схемы, относящейся к IED-устройству, — определение LN

9.3.2 IED-устройство, сервисы и точка доступа

Синтаксис SCL-языка для описания IED-устройства выглядит следующим образом:

<xs:complexType name=«tIED»> xs:complexContent <xs:extension base=«tNaming»> xs:sequence <xs:element name=«Services» type=«tServices» minOccurs=«0»/> <xs:element name=«AccessPoint» type=«tAccessPoint» maxOccurs=«unbounded»> <xs:unique name=«uniqueLNInAccessPoint»> <xs:selector xpath=».//scl:LN«/> <xs:field xpath=»@inst«/> <xs:field xpath=»@InClass«/> <xs:field xpath=»@prefix«/> </xs:unique> </xs:element> </xs:sequence> <xs:attribute name=»type» type=«xs:normalizedString» use=«optional»/> <xs:attribute name=«manufacturer» type=«xs:normalizedString» use=«optional»/> <xs:attribute name=«configVersion» type=«xs:normalizedString» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType>

Атрибуты элемента IED-устройства определены в таблице 9.

Атрибуты элемента IED-устройства

Атрибут	Описание
name	Идентификация IED-устройства. В пределах ICD-файла, описывающего тип устройства, имя должно быть TEMPLATE. IED-имя не может быть пустой строкой и должно быть уникальным в пределах SCL-файла
desc	Пояснительный текст
type	Тип IED-продукта (определяется изготовителем)
manufacturer	Имя изготовителя
configVersion	Версия базовой конфигурации данного IED-устройства

Вышеприведенный атрибут ConfigVersion IED-устройства определяет только базовую конфигурацию IED-устройства (то есть те возможности устройства, которые заданы/поставлены изготовителем), а не его индивидуальную конфигурацию после воплощения в проект. Это параметр IED-устройства или его LN. Он должен размещаться в файле SCL как значение атрибута LN0.NamPlt.configRev. IED-устройство содержит список возможностей сервиса (Service) и определение точек доступа.

Ограничения:

• имя IED-устройства (IED Name) должно быть уникально в пределах IED-секции файла SCL;

Общий элемент IED (тип tIED), к которому обращается элемент SCL, дополнительно содержит несколько ограничений идентичности:

• в пределах IED-устройства не может быть двух элементов AccessPoint (точка доступа) с одинаковым именем;
• в пределах IED-устройства не может быть двух элементов LDevice с одинаковым атрибутом inst. Кроме того, атрибут inst, относящийся к LDevice, действует как ключ в пределах IED-устройства. Атрибут logName каждого LogControl (косвенный подразряд IED-устройства) обращается к одному из таких ключей.

<xs:complexType name=«tServices»> xs:all <xs:element name=«DynAssociation» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«SettingGroups» minOccurs=«0»> xs:complexType xs:all <xs:element name=«SGEdit» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«ConfSG» type=«tServiceYesNo» minOccurs=«0»/> </xs:all> </xs:complexType> </xs:element> <xs:element name=«GetDirectory» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«GetDataObjectDefinition» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«DataObjectDirectory» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«GetDataSetValue» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«SetDataSetValue» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«DataSetDirectory» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«ConfDataSet» type=«tServiceWithMaxAndMaxAttributes» minOccurs=«0»/> <xs:element name=«DynDataSet» type=«tServiceWithMaxAndMaxAttributes» minOccurs=«0»/> <xs:element name=«ReadWrite» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«TimerActivatedControl» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«ConfReportControl» type=«tServiceWithMax» minOccurs=«0»/> <xs:element name=«GetCBValues» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«ConfLogControl» type=«tServiceWithMax» minOccurs=«0»/> <xs:element name=«ReportSettings» type=«tReportSettings» minOccurs=«0»/> <xs:element name=«LogSettings» type=«tLogSettings» minOccurs=«0»/> <xs:element name=«GSESettings» type=«tGSESettings» minOccurs=«0»/>

<xs:element name=«SMVSettings» type=«tSMVSettings» minOccurs=«0»/> <xs:element name=«GSEDir» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«GOOSE» type=«tServiceWithMax» minOccurs=«0»/> <xs:element name=«GSSE» type=«tServiceWithMax» minOccurs=«0»/> <xs:element name=«FileHandling» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«ConfLNs» type=«tConfLNs» minOccurs=«0»/> </xs:all> </xs:complexType>

Классы сервисов могут появляться в произвольном порядке. Отсутствие сервисов говорит о том, что они недоступны на IED-устройстве. Неоднократное появление одного и того же имени сервиса не имеет значения. О смысловом значении сервисов см. МЭК 61850-7-2.

Список возможностей сервиса, элементы настройки и атрибуты определены в таблице 10.

Список возможностей сервиса, элементы настройки и атрибуты

Возможности сервиса	Описание
DynAssociation	Все сервисы для динамического построения ассоциаций. Эти возможности не имеют атрибутов
SettingGroups: SGEdit ConfSG	Сервисы группы настроек принадлежат блоку управления группой настроек. Если данный блок управления доступен, также доступен будет сервис группы настроек SelectActiveSG для активации группы настроек. Возможность оперативного редактирования онлайн (сервисы МЭК 61850-7-2 SelectEditSG, ConfirmEditSGValues, SetSGValues) определяет элемент SGEdit. Также может существовать возможность конфигурирования ряда групп настроек средствами языка SCL (ConfSG). Эти возможности не имеют атрибутов
GetDirectory	Сервис для чтения содержимого сервера, то есть каталогов LN и LD (всех LD, LN и данных DATA логических узлов). Эта возможность не имеет атрибутов. Содержит сервисы МЭК 61850-7-2 GetServerDirectory, GetLogicalDeviceDirectory, GetLogicalNodeDirectory
GetDataObjectDefinition	Сервис для поиска полного списка всех определений DA для справочных данных, которые видимы и, следовательно, доступны запрашивающему клиенту через ссылочный LN. Этот сервис не имеет атрибутов. Обращается к сервису GetDataDefinition в МЭК 61850-7-2
DataObjectDirectory	Сервис для получения данных DATA, определенных в LN. Этот сервис не имеет атрибутов. Обращается к сервису GetDataDirectory в МЭК 61850-7-2
GetDataSetValue	Сервис для поиска всех значений данных, к которым обращаются элементы набора данных. Этот сервис не имеет атрибутов. Обращается к сервису GetDataSetValues в МЭК 61850-7-2
SetDataSetValue	Сервис для записи всех значений данных, к которым обращаются элементы набора данных. Этот сервис не имеет атрибутов. Обращается к сервису SetDataSetValues в МЭК 61850-7-2
DataSetDirectory	Сервис для поиска функционально связанных данных FCD/FCDA всех элементов, запрашиваемых в наборе данных. Этот сервис не имеет атрибутов. Обращается к сервису GetDataSetDirectory в МЭК 61850-7-2
ConfDataSet	Если сервис ConfDataSet не задан, значение по умолчанию его атрибута max равно числу предконфигурированных наборов данных, и они могут быть модифицированы. Если сервис задан, можно конфигурировать новые наборы данных до заданного значения max или модифицировать имеющиеся наборы во время конфигурирования через язык SCL. Смысловое значение атрибута: - max — максимальное число наборов данных; - maxAttributes — максимальное число атрибутов, допустимых в наборе данных (FCDA может содержать несколько атрибутов); - modify — логическая единица (true) означает возможность модифицировать предконфигурированные наборы данных
DynDataSet	Сервисы для динамического создания и удаления наборов данных. Смысловое значение атрибута: - max — максимальное число динамически создаваемых наборов данных (включая в конечном итоге предопределенные наборы данных); - maxAttributes — максимальное число атрибутов, допустимых в наборе данных (FCDA может содержать несколько атрибутов)
ReadWrite	Возможность считывания и записи основных данных. Содержит сервисы МЭК 61850-7-2 GetData, SetData и сервис Operate, если имеются соответствующие данные. Эта функция не имеет атрибутов
TimerActivatedControl	Данный элемент указывает на поддержку сервисов управления активированным таймером. Все другие сервисы, относящиеся к области управления, указаны непосредственно в DO с атрибутом ctlModel. Этот сервис не имеет атрибутов
ConfReportControl	Возможность статического (путем конфигурирования через язык SCL) создания блоков управления генерацией отчетов. Смысловое значение атрибута: max — максимальное число инстанцируемых блоков управления генерацией отчетов
GetCBValues	Считывание значений блоков управления. Этот сервис не имеет атрибутов
ConfLogControl	Возможность статического (путем конфигурирования через язык SCL) создания блоков управления журналом. Смысловое значение атрибута: max — максимальное число инстанцируемых блоков управления журналом
ReportSettings	Атрибуты блока управления генерацией отчетов, для которых возможна оперативная настройка с помощью сервисов SetURCBValues соответственно SetBRCBValues. Смысловое значение атрибута: - cbName — имя блока управления; - datSet — ссылка на набор данных; - rptID — идентификатор отчетов; - optFields — дополнительные поля для включения в отчет; - bufTime — буферное время; - trgOps — разрешение опции пуска; - intgPd — период сохранности
LogSettings	Атрибуты блока управления журналом, для которых возможна оперативная настройка с помощью сервисов SetBRCBValues. Смысловое значение атрибута: - cbName — имя блока управления; - datSet — ссылка на набор данных; - logEna — разрешение журнала; - trgOps — опции пуска; - intgPd — период сохранности
GSESettings	Атрибуты блока управления GSE-сообщениями, для которых возможна оперативная настройка с помощью сервисов SetGsCBValues соответственно SetGoCBValues. Смысловое значение атрибута: - cbName — имя блока управления; - datSet — ссылка на набор данных; - appID — идентификатор приложения; dataLabel — значение для ссылки объекта при отправке соответствующего элемента (применимо только к блокам управления GSSE-сообщениями)
SMVSettings	Атрибуты блока управления SMV, для которых возможна оперативная настройка с помощью сервисов SetMSVCBValues соответственно SetUSVCBValues. Смысловое значение атрибута: - cbName — имя блока управления; - datSet — ссылка на набор данных; - svID — идентификатор выборочного значения; - optFields — дополнительные поля для включения в сообщение о выборочных значениях; - smpRate — скорость выборки
ConfLNs	Описывает, что может быть сконфигурировано для LN, определенных в ICD-файле. Смысловое значение атрибута: - fixPrefix — если логический нуль (false), префиксы могут быть заданы/изменены; - fixLnInst — если логический нуль, может быть изменено количество экземпляров LN
GSEDir	Сервисы каталога GSE-событий в соответствии с МЭК 61850-7-2. Эта возможность не имеет атрибутов
GOOSE	Данный элемент показывает, что IED-устройство может быть GOOSE-сервером и (или) клиентом согласно МЭК 61850-7-2. Смысловое значение атрибута: max — максимальное число блоков управления GOOSE-событиями, которые способны конфигурироваться для издания (max=0 означает, что устройство является только GOOSE-клиентом)
GSSE	Данный элемент показывает, что IED-устройство может быть GSSE-сервером бинарных данных и/или клиентом согласно МЭК 61850-7-2. Смысловое значение атрибута: max — максимальное число блоков управления GOOSE-событиями, которые способны конфигурироваться
FileHandling	Все сервисы по обработке файлов; без атрибутов
Примечание — В рамках описания возможностей IED-устройства вышеуказанные максимальные числа должны быть гарантированным максимумом, то есть данное число элементов должно иметь возможность инстанцировать соответствующее использование в любых обстоятельствах, например, даже если некоторое динамическое распределение памяти позволяет порой иметь больше (чем максимум) элементов одного типа за счет элементов другого типа (всегда по меньшей мере максимум).

Элемент Access point IED-устройства определяет имеющиеся коммуникационные точки доступа.

<xs:complexType name=«tAccessPoint»> xs:complexContent <xs:extension base=«tNaming»> <xs:choice minOccurs=«0»> <xs:element name=«Server» type=«tServer»> <xs:unique name=«uniqueAssociationInServer»> <xs:selector xpath=»./scl:Association«/> <xs:field xpath=»@associationID«/> </xs:unique> </xs:element> <xs:element ref=»LN» maxOccurs=«unbounded»/> </xs:choice> <xs:attribute name=«router» type=«xs:boolean» use=«optional» default=«false»> </xs:attribute> <xs:attribute name=«clock» type=«xs:boolean» use=«optional» default=«false»> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType>

Access point определена одним из элементов: Server или список LN.

Атрибуты элемента Access point определены в таблице 11.

Атрибуты элемента Access point

Атрибут	Описание
name	Ссылка, определяющая данную точку доступа в пределах IED-устройства
desc	Пояснительный текст
router	Наличие и настройка на логическую единицу (true) определяет наличие у данного IED-устройства функции маршрутизатора. По умолчанию его значение — логический нуль, false (функция маршрутизатора отсутствует)
clock	Наличие и настройка на логическую единицу (true) определяет данное IED-устройство как главные часы на данной шине. По умолчанию его значение — логический нуль, false (часы отсутствуют)

Атрибут name точки доступа вместе с именем IED-устройства образуют уникальную ссылку на точку доступа в пределах SA-системы.

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

Зависимые от проекта атрибуты точек доступа (например, адрес в пределах системы связи) размещаются в секции Communication SCL-языка.

Ограничения:

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

Следует обратить внимание, что:

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

9.3.3 Сервер IED-устройства

Сервер связи IED-устройства описан следующим образом:

<xs:complexType name=«tServer»> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«Authentication»> xs:complexType <xs:attributeGroup ref=«agAuthentication»/> </xs:complexType> </xs:element> <xs:element name=«LDevice» type=«tLDevice» maxOccurs=«unbounded»/> <xs:element name=«Association» type=«tAssociation» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«timeout» type=«xs:unsignedInt» use=«optional» default=«30»/> </xs:extension> </xs:complexContent> </xs:complexType>

IED-server (сервер IED-устройства) содержит элементы Authentication (аутентификация), LDevice (логическое устройство) и Association (ассоциация). Атрибуты определены, как показано в таблице 12.

Атрибуты элемента IED-server

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

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

Обязательный элемент Authentication определяет возможности аутентификации в случае описания устройства и метод(ы), используемый(ые) для аутентификации, — в случае устройства, инстанцированного в оборудование. Если элемент отсутствует, значение по умолчанию — none (то есть аутентификация отсутствует; это означает, что значение атрибута none есть логическая единица, true). Точное смысловое значение других методов — особенно weak (слабый) и strong (сильный) — определено в отображениях стека (на уровне SCSM).

<xs:attributeGroup name=«agAuthentication»> <xs:attribute name=«none» type=«xs:boolean» use=«optional» default=«true»/> <xs:attribute name=«password» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«weak» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«strong» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«certificate» type=«xs:boolean» use=«optional» default=«false»/> </xs:attributeGroup>

Атрибуты элемента Authentication определены в таблице 13.

Атрибуты элемента Authentication

Атрибут	Описание
none	Аутентификация отсутствует
password	Определен в отображениях стека (на уровне SCSMs)
weak
strong
certificate

9.3.4 Логическое устройство

Элемент LDevice определяет логическое устройство IED-устройства, доступное через точку доступа. Оно должно содержать по меньшей мере один LN и логический узел LN0, а также может содержать предконфигурированный отчет, определения GSE-сообщения и SMV.

<xs:complexType name=«tLDevice»> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element ref=«LN0»/> <xs:element ref=«LN» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«AccessControl» type=«tAccessControl» minOccurs=«0»/> </xs:sequence> <xs:attribute name=«inst» type=«tName» use=«required»> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType>

Атрибуты элемента LDevice определены в таблице 14.

Атрибуты элемента LDevice

Атрибут	Описание
inst	Идентификация LDevice в пределах IED-устройства. Полное имя LD согласно серии стандартов МЭК 61850-7 содержит дополнительную часть перед указанным значением inst (см. также 8.4). Значение не может быть пустой строкой
desc	Пояснительный текст

Ограничения:

• атрибут inst LD должен быть уникальным в пределах IED-устройства;
• имя LD, построенное из inst и других частей, которые описаны в 8.4, должно быть уникальным в пределах каждого SCL-файла;
• длина атрибута inst должна составлять по меньшей мере один символ.

9.3.5 LN0 и другие логические узлы

<xs:complexType name=«tLN0»> xs:complexContent <xs:extension base=«tAnyLN»> xs:sequence <xs:element name=«GSEControl» type=«tGSEControl» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«SampledValueControl» type=«tSampledValueControl» minOccurs=«0» maxOccurs=«'unbounded»/> <xs:element name=«SettingControl» type=«tSettingControl» minOccurs=«0»/> <xs:element name=«SCLControl» type=«tSCLControl» minOccurs=«0»/> <xs:element name=«Log» type=«tLog» minOccurs=«0»/> </xs:sequence> <xs:attribute name=«InClass» type=«tLNClassEnum» use=«required» fixed=«LLN0»/> <xs:attribute name=«inst» type=«xs:normalizedString» use=«required» fixed=«»/> </xs:extension> </xs:complexContent> </xs:complexType>

LN0 содержит следующие элементы: GSEControl (управление GSE-сообщениями) (9.3.10), SampledValueControl (управление выборочными значениями) (9.3.11), SettingControl (управление уставками) (9.3.12), SCLControl (управление SCL) и Log (журнал). Кроме того, он наследует ReportControl (управление генерацией отчетов) и LogControl (управление журналом) из базового типа tAnyLN, а также DOI и элемент Inputs. Атрибуты элемента LN0 определены в таблице 15.

Атрибуты элемента LN0

Атрибут	Описание
InClass	Класс LN согласно серии стандартов МЭК 61850-7, определенный также в tAnyLN, здесь жестко приписан к LLN0, то есть недопустимы никакие другие значения
InType	Определение инстанцируемого типа этого LN, ссылка на определение типа логического узла LNodeType
inst	Номер экземпляра LN, определяющего данный LN. Для LLN0 значение равно пустой строке (никакие другие значения недопустимы)
desc	Пояснительный текст

Ограничение: класс логического узла LN0 всегда LLN0, поэтому атрибут inst не нужен (по умолчанию — пустая строка). Для ссылки связи на LN0 InInst должен быть пустой строкой, а InClass должен быть LLN0.

LN (тип tLN) описывается следующим образом:

<xs:complexType name=«tLN»> xs:complexContent <xs:extension base=«tAnyLN»> <xs:attribute name=«InClass» type=«tLNClassEnum» use=«required»/> <xs:attribute name=«inst» type=«xs:unsignedInt» use=«required»/> <xs:attribute name=«prefix» type=«tAnyName» use=«optional» default=«»/> </xs:extension> </xs:complexContent> </xs:complexType>

tAnyLN (супертип tLN0 и tLN) определен следующим образом:

<xs:complexType name=«tAnyLN» abstract=«true»> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«DataSet» type=«tDataSet» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«ReportControl» type=«tReportControl» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«LogControl» type=«tLogControl» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«DOI» type=«tDOI» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«Inputs» type=«tInputs» minOccurs=«0»/> </xs:sequence> <xs:attribute name=«InType» type=«tName» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType>

LN содержит следующие элементы: DataSet (набор данных) (9.3.7), ReportControl (управление генерацией отчетов) (9.3.8), LogControl (управление журналом) (9.3.9), DOI (9.3.6) и Inputs (9.3.13).

Атрибуты LN определены, как показано в таблице 16.

Атрибуты элемента LN

Атрибут	Описание
desc	Пояснительный текст к LN
InType	Определение инстанцируемого типа этого LN, ссылка на определение LNodeType
InClass	Класс LN по определению серии стандартов МЭК 61850-7
inst	Номер экземпляра LN, определяющего данный LN, — целочисленный тип без знака
prefix	Часть префикса LN

Дополнительные элементы DOI в определении LN могут быть использованы для определения специальных значений данных DATA, связанных с экземпляром, и их атрибутов. Это происходит за счет использования элементов SDI для данных DATA или частей структуры атрибута (если необходимо) и элементов DAI через терминальный атрибут (см. определение DOI в 9.3.6). Однако данные DATA и атрибуты, на которые здесь сделаны ссылки, уже определены при определении LNodeType того LN, к которому обращается атрибут LNType логического узла LN. Элементы DOI в данном месте для данного экземпляра не определяют новых DO или новых атрибутов, которые не содержатся в LNodeType. Например, такой параметр конфигурации, как длина импульса DPC CDC, для которого в LNodeType указано значение 100 мс, здесь заменен значением 300 мс для специальных данных DO.

Ограничение: имя LN, состоящее из prefix, InClass и inst, должно быть уникальным в пределах логического устройства при заданном сервере, в противном случае — в пределах IED-устройства.

9.3.6 Определение DATA (DOI)

<xs:complexType name=«tDOI»> xs:complexContent <xs:extension base=«tUnNaming»> <xs:choice minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«SDI» type=«tSDI»/> <xs:element name=«DAI» type=«tDAI»/> </xs:choice> <xs:attribute name=«name» type=«tRestrName1stU» use=«required»/> <xs:attribute name=«ix» type=«xs:unsignedInt» use=«optional»/> <xs:attribute name=«accessControl» type=«xs:normalizedString» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType>

DOI определен одним из элементов: SDI или DAI.

Атрибуты DOI определены, как показано в таблице 17.

Атрибуты элемента DOI

Атрибут	Описание
desc	Пояснительный текст к данным
name	Стандартизированное имя DO, например, из МЭК 61850-7-4
ix	Индекс элемента данных в случае индексируемого типа
accessControl	Определение управления доступом к этим данным. Пустая строка (по умолчанию) означает, что применяется определение управления доступом верхнего уровня. Возможные значения являются зависимыми на уровне SCSM

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

<xs:complexType name=«tDAI» xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«Val» type=«tVal» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«name» type=«tRestrName1stL» use=«required»/> <xs:attribute name=«sAddr» type=«xs:normalizedString» use=«optional»/> <xs:attribute name=«valKind» type=«tValKindEnum» use=«optional» default=«Set»/> <xs:attribute name=«ix» type=«xs:unsignedInt» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType>

Атрибут DAI позволяет описание значений экземпляра IED-устройства. На этапе разработки и проектирования это может применяться другими IED-устройствами/LN, которым необходимо знать зависимые от конфигурации значения — в тех случаях, когда, например, у них нет сервиса для чтения значений или когда IED-устройство не поддерживает их считывание. Также это может использоваться самим IED-устройством для задачи этих значений либо для предложения их через протокол связи или (по меньшей мере) для учета их в своих внутренних функциях.

Атрибуты элемента DAI определены, как показано в таблице 18.

Атрибуты элемента DAI

Атрибут	Описание
desc	Пояснительный текст к элементу DAI
name	Имя атрибута Data с заданным значением
sAddr	Короткий адрес этого атрибута Data
valKind	Если задано любое имя, то его смысловое значение задается на этапе разработки и проектирования
ix	Индекс элемента DAI в случае индексируемого типа

Элемент DAI содержит подмножество атрибутов DA. Он должен использоваться в пределах DOI-спецификации IED-устройства, если заданы некоторые значения атрибутов, зависящие от экземпляра, или заменены типичные значения атрибутов.

Подмножество данных или атрибуты данных описаны следующим образом:

<xs:complexType name=«tSDI»> xs:complexContent <xs:extension base=«tUnNaming»> <xs:choice minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«SDI» type=«tSDI»/> <xs:element name=«DAI» type=«tDAI»/> </xs:choice> <xs:attribute name=«name» type=«tRestrName1stL» use=«required»/> <xs:attribute name=«ix» type=«xs:unsignedInt» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType>

Элемент SDI обозначает часть имени подструктуры из DO (соответствует SDO в LNodeType) или из имени подструктуры DA, за исключением имени терминального атрибута (лист). Элемент SDI содержит либо элементы SDI для дальнейшей части имени структуры, либо DAI для элемента терминального атрибута, имеющего значение(я).

Атрибуты элемента SDI определены, как показано в таблице 19.

Атрибуты элемента SDI

Атрибут	Описание
desc	Пояснительный текст к части SDI
name	Имя SDI (часть структуры)
ix	Индекс элемента SDI в случае индексируемого типа

Пример

Следующий пример описывает значение структурированного DO как DOI.

0 200

9.3.7 Определение Data set (набор данных)

<xs:complexType name=«tDataSet»> xs:complexContent <xs:extension base=«tNaming»> xs:sequence <xs:element name=«FCDA» type=«tFCDA» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

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

Определение набора данных LN имеет атрибуты, определенные в таблице 20.

Таблица 20

Атрибуты элемента DataSet

Атрибут	Описание
name	Имя, определяющее этот набор данных в заданном LN
desc	Пояснительный текст к набору данных

<xs:complexType name=«tFCDA»> <xs:attribute name=«IdInst» type=«tName» use=«optional»/> <xs:attribute name=«prefix» type=«tAnyName» use=«optional»/> <xs:attribute name=«InClass» type=«tLNClassEnum» use=«optional»/> <xs:attribute name=«InInst» type=«tName» use=«optional»/> <xs:attribute name=«doName» type=«tName» use=«optional»/> <xs:attribute name=«daName» type=«tName» use=«optional»/> <xs:attribute name=«fc» type=«tFCEnum» use=«required»/> </xs:complexType>

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

Атрибуты элемента FCDA

Атрибут	Описание
IdInst	LD, в котором резидентно размещены DO
prefix	Префикс, определяющий вместе с InInst и InClass логический узел LN, в котором резидентно размещены DO
InClass	Класс LN логического узла LN, где резидентно размещены DO; задается всегда, за исключением тех случаев, когда GSSE DataLabel — пустая строка
InInst	Номер экземпляра LN, где резидентно размещены DO; задается всегда, кроме LLN0
doName	Имя, идентифицирующее DO (в пределах LN). Имя, стандартизированное в МЭК 61850-7-4. Если doName пусто, тогда fc может содержать значение, выбирающее категорию атрибута всех DO определенного LN. Элементы или части типов структурированных данных DATA содержат все части имени, разделенные точками (.)
daName	Имя атрибута — если пустое, выбираются все атрибуты с функциональными характеристиками, заданными fc. Элементы или части структурированных типов данных содержат все части имени, разделенные точками (.)
fc	Выбираются все атрибуты этой функциональной связи. Возможные значения связи см. в МЭК 61850-7-2 или в определении функциональной связи fc в таблице 43

Если оба атрибута — daName и fc содержат непустые значения, тогда значение fc должно быть действительным для атрибута (то есть должно быть идентично определено в соответствующем определении LNodeType). В противном случае обработка SCL-файла будет прервана сообщением об ошибке. Если все атрибуты FCDA (за исключением fc) отсутствуют или пусты, в определении GSSE DataLabel это соответствует пустой строке (значение fc должно быть ST). Во всех других наборах данных это недопустимо.

Все блоки управления, которые обращаются к набору данных, должны содержаться в том же LN, что и определение набора данных. Следовательно, ссылка на набор данных во всех блоках управления содержит только относящееся к LN имя набора данных (атрибут Name в элементе DataSet), а не его полное имя (которое согласно МЭК 61850-7-2 содержит также имя LD и имя LN).

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

9.3.8 Блок управления генерацией отчетов

Определение блока управления генерацией отчетов LN следующее:

<xs:complexType name=«tReportControl»> xs:complexContent <xs:extension base=«tControlWithTriggerOpt»> xs:sequence <xs:element name=«OptFields»> xs:complexType <xs:attributeGroup ref=«agOptFields»/> </xs:complexType> </xs:element> <xs:element name=«RptEnabled» type=«tRptEnabled» minOccurs=«0»/> </xs:sequence> <xs:attribute name=«rptID» type=«tName» use=«required»/> <xs:attribute name=«confRev» type=«xs:unsignedInt» use=«required»/> <xs:attribute name=«buffered» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«bufTime» type=«xs:unsignedInt» use=«optional» default=«0»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tControlWithTriggerOpt» abstract=«true»> xs:complexContent <xs:extension base=«tControl»> xs:sequence <xs:element name=«TrgOps» type=«tTrgOps» minOccurs=«0»/> </xs:sequence> <xs:attribute name=«intgPd» type=«xs:unsignedInt» use=«optional» default=«0»/> </xs:extension> </xs:complexContent> </xs:complexType>

Блок управления генерацией отчетов (RCB) содержит следующие элементы: TrgOps, OptFields и RptEnabled.

Используют атрибуты, приведенные в таблице 22.

Таблица 22

Атрибуты элемента блока управления генерацией отчетов

Атрибут	Описание
name	Имя блока управления генерацией отчетов. Это имя относится к LN, размещающему блок управления генерацией отчетов RCB, и должно быть уникальным в пределах LN
desc	Пояснительный текст
datSet	Имя набора данных, направляемого блоком управления генерацией отчетов; в пределах ICD-файла datSet может быть только пустым
intgPd	Период сохранности в миллисекундах — см. МЭК 61850-7-2. Имеет смысл, только если опция периода пуска установлена на логическую единицу (true)
rptID	Идентификатор блока управления генерацией отчетов
confRev	Номер ревизии конфигурации данного блока управления генерацией отчетов
buffered	Указывает, отложены или не отложены отчеты — см. МЭК 61850-7-2
bufTime	Буферное время — см. МЭК 61850-7-2

Атрибуты элемента TrgOps определены следующим образом:

<xs:complexType name=«tTrgOps»> <xs:attribute name=«dchg» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«qchg» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«dupd» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«period» type=«xs:boolean» use=«optional» default=«false»/> </xs:complexType>

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

Элемент OptFields определен следующим образом:

<xs:element name=«OptFields»> xs:complexType <xs:attributeGroup ref=«agOptFields»/> </xs:complexType> </xs:element> <xs:attributeGroup name=«agOptFields»> <xs:attribute name=«seqNum» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«timeStamp» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«dataSet» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«reasonCode» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«dataRef» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«bufOvfl» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«entryID» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«configRef» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«segmentation» type=«xs:boolean» use=«optional» default=«false»/> </xs:attributeGroup>

Настройка атрибута на логическую единицу (true) означает включение в отчет соответствующих данных (см. МЭК 61850-7-2).

Элемент RptEnabled определен следующим образом:

<xs:complexType name=«tRptEnabled»> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«ClientLN» type=«tClientLN» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«max» type=«xs:unsignedInt» use=«optional» default=«1»/> </xs:extension> </xs:complexContent> </xs:complexType>

Элемент RptEnabled содержит список LN клиента, для которых должен быть разрешен этот отчет (например, при запуске IED-устройства на предустановленных ассоциациях).

Используют атрибуты, приведенные в таблице 23.

Атрибуты элемента RptEnabled

Атрибут	Описание
desc	Пояснительный текст
max	Определяет максимальное число блоков управления генерацией отчетов данного типа, которые инстанцируются во время конфигурирования в LN (и затем используются в онлайновом режиме)

Согласно МЭК 61850-7-2 блок управления генерацией отчетов предназначен для одновременной работы только с одним клиентом. Это значит, что если задается Max > 1 для RptEnabled, на IED-устройстве должно быть инстанцировано более одного блока управления генерацией отчетов (RCB) данного типа. Следует обратить внимание, что для всех отложенных блоков управления LN ClientLN должен быть предконфигурирован, то есть Max должен быть тождествен заданному числу ClientLN. Если ClientLN предконфигурированы для небуферизованных блоков управления RCB, то дополнительно к атрибуту RptEna (Report Enable описан в МЭК 61850-7-2) в IED-устройстве должен быть установлен на значение true атрибут Resv (URCB Reservation описан в МЭК 61850-7-2) блока управления RCB. Имена URCName или BRCName блока управления согласно МЭК 61850-7-2 построены из упомянутого атрибута RCName с последующим двузначным числом между 01 и Max. Если заданы ClientLN, индекс (положение) ClientLN в списке, размещенном в элементе RptEnabled, используется как данный номер для данного клиента (первый имеет индекс 1). Это значит, что определение блока управления генерацией отчетов на языке SCL должно рассматриваться не как экземпляр, а как тип, который может иметь 99 экземпляров для 99 клиентов.

Элемент ClientLN определяет имя LN в системе, которая является клиентом для данного типа блока управления генерацией отчетов.

<xs:complexType name=«tClientLN»>

<xs:attributeGroup ref=«agLNRef»/>

</xs:complexType> <xs:attributeGroup name=«agLNRef»>

<xs:attribute name=«InInst» type=«xs:normalizedString» use=«required»/>

</xs:attributeGroup>

Используют атрибуты, приведенные в таблице 24.

Атрибуты элемента ClientLN

Атрибут	Описание
iedName	Имя IED-устройства, где резидентно находится LN
IdInst	Идентификация экземпляра LD, где резидентно находится LN
prefix	Префикс LN
InClass	Класс LN по определению в МЭК 61850-7-4
InInst	Идентификатор id экземпляра данного экземпляра LN нижележащего класса LN в IED-устройстве

Ограничения:

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

Пример

Часть RptEnabled определяет, что тип блока управления генерацией отчетов действителен для пяти (небуферизованных) блоков управления RCB, имеющих имена от PosReport01 до PosReport05. Первый блок PosReport01 уже зарезервирован для клиента A1KA1LD1/IHMI1. Все отчеты запускаются с помощью dchg и qchg, а буферное время равно 0. Поля OptFields не задаются, то есть в отчет включена только обязательная информация.

9.3.9 Блок управления журналом

Блок управления журналом определен следующим элементом:

<xs:complexType name=«tLogControl»> xs:complexContent <xs:extension base=«tControlWithTriggerOpt»> <xs:attribute name=«logName» type=«tName» use=«required»/> <xs:attribute name=«logEna» type=«xs:boolean» use=«optional» default=«true»/> <xs:attribute name=«reasonCode» type=«xs:boolean» use=«optional» default=«true»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tControlWithTriggerOpt» abstract=«true»> xs:complexContent <xs:extension base=«tControl»> xs:sequence <xs:element name=«TrgOps» type=«tTrgOps» minOccurs=«0»/> </xs:sequence> <xs:attribute name=«intgPd» type=«xs:unsignedInt» use=«optional» default=«0»/> </xs:extension> </xs:complexContent> </xs:complexType>

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

Атрибуты элемента блока управления журналом определены в таблице 25.

Таблица 25

Атрибуты элемента блока управления журналом

Атрибут	Описание
name	Имя блока управления журналом
desc	Пояснительный текст
datSet	Имя набора данных, значения которых регистрируются; datSet может быть пуст только в пределах ICD-файла
intgPd	Период сканирования сохранности в миллисекундах — см. МЭК 61850-7-2
logName	Ссылка на LD, являющееся владельцем журнала
logEna	TRUE разрешает немедленную регистрацию; FALSE запрещает регистрацию до разрешения в онлайновом режиме
reasonCode	Код причины — см. МЭК 61850-7-2

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

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

9.3.10 Блок управления GSE-сообщениями

В логическом узле LLN0 разрешается только следующий элемент управления GSE-сообщениями:

<xs:complexType name=«tGSEControl»> xs:complexContent <xs:extension base=«tControlWithIEDName»> <xs:attribute name=«type» type=«tGSEControlTypeEnum» use=«optional» default=«GOOSE»/> <xs:attribute name=«appID» type=«xs:normalizedString» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tControlWithIEDName»> xs:complexContent <xs:extension base=«tControl»> xs:sequence <xs:element name=«IEDName» type=«tName» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«confRev» type=«xs:unsignedInt» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType>

Блок управления GSE-сообщениями может дополнительно содержать IED-имена для тех IED-устройств, которые должны быть подписаны на GSE-данные.

Используют атрибуты, приведенные в таблице 26.

Атрибуты элемента блока управления GSE-сообщениями

Атрибут	Описание
Name	Имя, идентифицирующее данный блок управления GOOSE-событиями
desc	Пояснительный текст
datSet	Имя набора данных, направляемых на блок управления GSE-событиями. Для type=GSSE определения FCDA в этом наборе данных должны интерпретироваться как DataLabels согласно МЭК 61850-7-2. Атрибут datSet в пределах ICD-файла может быть только пустым
confRev	Номер ревизии конфигурации данного блока управления
type	Если type — GSSE, то разрешены только типы данных с единичной индикацией, а с двойной индикацией разрешены для элементов данных, к которым обращаются в наборе данных; в противном случае допустимы все типы данных. Следует обратить внимание, что каждый тип может быть различным образом отображен на форматы сообщений. Значение типа по умолчанию — GOOSE
appID	Уникальная идентификация приложений в рамках системы, к которым принадлежит GOOSE-сообщение

Ограничения:

• имя блока управления GSE-сообщениями должно быть уникальным в пределах LLN0, то есть логического устройства;
• различные приложения в пределах станции должны иметь уникальные значения appId. Решение о характере приложения принимает инженер проекта/системы.

Следующий фрагмент языка SCL содержит пример определения блока управления GOOSE-сообщениями.

Его относительное имя в пределах данного LN0 — ItlPositions; содержимое его сообщений определено через Positions в наборе данных и должно использоваться в приложении Itl.

9.3.11 Блок управления выборочными значениями

В логическом узле LLN0 разрешается только следующий элемент блока управления выборочными значениями:

<xs:complexType name=«tSampledValueControl»> xs:complexContent <xs:extension base=«tControlWithIEDName»> xs:sequence <xs:element name=«SmvOpts»> xs:complexType <xs:attributeGroup ref=«agSmvOpts»/> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name=«smvID» type=«xs:normalizedString» use=«required»/> <xs:attribute name=«multicast» type=«xs:boolean» default=«true»/> <xs:attribute name=«smpRate» type=«xs:unsignedInt» use=«required»/> <xs:attribute name=«nofASDU» type=«xs:unsignedInt» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType>

Блок управления выборочными значениями содержит элемент SmvOpts и дополнительно, как расширение типа схемы tControlWithIEDName, несколько IED-имен IED-устройств, которые должны получать сообщения.

Используют атрибуты, приведенные в таблице 27.

Атрибуты элемента блока управления выборочными значениями

Атрибут	Описание
name	Имя, идентифицирующее данный блок управления SMV
desc	Пояснительный текст
datSet	Имя набора данных, значения которых направляются; datSet может быть пуст только в пределах ICD-файла
confRev	Номер ревизии конфигурации данного блока управления
smvID	Блок управления многоадресными сообщениями: MsvID для определения выборочных значений по МЭК 61850-7-2. Блок управления одноадресными сообщениями: UsvID, как определено в МЭК 61850-7-2
multicast	Логический нуль (false) указывает на то, что сервисы Unicast SMV имеют единственное значение smvID = UsvID
smpRate	Частота опроса, как определено в МЭК 61850-7-2
nofASDU	Номер ASDU (блок данных прикладных услуг) — см. МЭК 61850-9-2

Если Multicast есть логический нуль (false), то есть это блок управления Unicast, определение должно рассматриваться как тип. В этом случае следует, что:

• для каждого IED-имени целевого IED-устройства, указанного в определении, должен быть создан экземпляр блока управления;
• имя UsvCBName, определенное в МЭК 61850-7-2, должно быть установлено на это IED-имя, каскадно сцепленное с упомянутым именем (которое в этом случае должно быть пустым);
• атрибут Resv блока управления CB должен быть установлен на логическую единицу (true).

Если значение Multicast есть логическая единица (true), то имя соответствует непосредственно имени MsvCBName.

<xs:attributeGroup name=«agSmvOpts»> <xs:attribute name=«refreshTime» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«sampleSynchronized» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«sampleRate» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«security» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«dataRef» type=«xs:boolean» use=«optional» default=«false»/> </xs:attributeGroup>

Атрибуты элемента Smv Options

Атрибут	Описание
refreshTime	Смысловое значение опций раскрывается в МЭК 61850-7-2. Если один из атрибутов установлен на логическую единицу (true), соответствующие значения должны быть включены в телеграмму SMV
sampleSynchronized
sampleRate
security	См. описание в МЭК 61850-9-2
dataRef	При установке на логическую единицу ссылка на набор данных включается в сообщение SV

Ограничение: имя блока управления SV должно быть уникальным в пределах LLN0, то есть в пределах LDevice.

Следующий фрагмент языка SCL приводит определение блока управления SV, которое относится к smv набора данных. Этот набор данных определяет содержимое данных сообщения SV:

9.3.12 Блок управления настройками

Ниже приведено определение блока управления настройками SGC. Следует обратить внимание, что имя SGC, то есть его именная часть в пределах LN0 в соответствии с МЭК 61850-7-2 есть SGCB. Следовательно, допускается иметь только один SGC на LN0.

<xs:complexType name=«tSettingControl»> xs:complexContent <xs:extension base=«tUnNaming»> <xs:attribute name=«numOfSGs» type=«xs:unsignedInt» use=«required»/> <xs:attribute name=«actSG» type=«xs:unsignedInt» use=«optional» default=«1»/> </xs:extension> </xs:complexContent> </xs:complexType>

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

Атрибуты элемента блока управления настройками определены в таблице 29.

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

Атрибут	Описание
desc	Пояснительный текст
numOfSGs	Число имеющихся групп настроек
actSG	Число групп настроек для вызова при загрузке конфигурации. Значение по умолчанию равно 1

9.3.13 Привязка к внешним сигналам

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

<xs:complexType name=«tInputs»> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«ExtRef» type=«tExtRef» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

Каждый элемент ExtRef ссылается на одну внешнюю позицию, на уровне DO или DA. Если необходим IntAdr, он должен использоваться соответственно данному уровню. Это значит, что при использовании на уровне DO он может содержать отображение нескольких атрибутов.

<xs:complexType name=«tExtRef»>

<xs:attributeGroup ref=«agDORef»/>

<xs:attribute name=«daName» type=«tName» use=«optional»/>

<xs:attribute name=«intAddr» type=«xs:normalizedString» use=«optional»/>

</xs:complexType>

Используют атрибуты, приведенные в таблице 30.

Атрибуты элемента Input/ExtRef

Атрибут	Описание
iedName	Имя IED-устройства, от которого поступают входные данные
IdInst	Имя экземпляра LD, от которого поступают входные данные
prefix	Префикс LN
InClass	Класс LN по определению серии стандартов МЭК 61850-7
InInst	Идентификатор id экземпляра данного экземпляра LN нижележащего класса LN в IED-устройстве
doName	Имя, идентифицирующее DO (в пределах LN). В случае структурированных DO именные части каскадно сцеплены через точку (.)
daName	Атрибут, обозначающий входные данные. Средства программирования IED-устройства должны использовать пустое значение при наличии некоего связывания по умолчанию IntAdr для всех атрибутов входных данных DO процесса (fc = ST или MX), главным образом для t и q. Если атрибут принадлежит к структуре типа данных, то части имени структуры должны отделяться точками (.)
intAddr	Внутренние адреса, к которым привязаны входные данные. Только средства программирования данного конкретного IED-устройства должны использовать это значение. Все остальные средства программирования должны его сохранять

Пустое значение имени daName означает атрибуты всех операционных значений DO, то есть stVal, mag и т.д. В этом случае intAdr может также определять адреса операционных атрибутов некоторым способом, специфичным для средств программирования IED-устройств.

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

9.3.14 Ассоциации

<xs:complexType name=«tAccessControl» mixed=«true»> <xs:complexContent mixed=«true»> <xs:extension base=«tAnyContentFromOtherNamespace»/> </xs:complexContent> </xs:complexType>

Определение управления доступом. Смысловое значение и возможное уточнение определения решается на уровне стека (SCSM).

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

Определение каждой ассоциации задает одну предконфигурированную ассоциацию между данным сервером и LN клиента. Возможны два вида предконфигурирования. «Предопределенный» означает, что ассоциация определена, но не открыта, и ее открытие выполняет клиент. «Предустановленный» означает, что ассоциация определена, и ее открытие предполагается сразу же после запуска IED-устройства.

<xs:complexType name=«tAssociation»>

<xs:attribute name=«kind» type=«tAssociationKindEnum» use=«required»/>

Используют атрибуты, приведенные в таблице 31.

Атрибуты элемента Association

Атрибут	Описание
kind	Род предконфигурированной ассоциации — либо предопределенной, либо предустановленной
association ID	Идентификация предконфигурированной ассоциации (в противном случае — пустая)
iedName	Ссылка, идентифицирующая IED-устройство, на котором резидентно расположен клиент
IdInst	Ссылка на логическое устройство клиента
InClass	Класс LN клиента
prefix	Префикс LN
InInst	Номер экземпляра LN клиента

Пустая Id-ассоциация, задаваемая по умолчанию, означает, что Id-ассоциация еще не определена. Для законченного файла языка SCL и предустановленной ассоциации Id-ассоциация задается, так что LN клиента и сервер могут проверить его корректность. Один и тот же клиент может использовать одни и те же ассоциации с различными LN на одном сервере. На уровне SCSM задаются требования к однозначности, а также диапазон значений Id-ассоциации (например, целое число 32 бита, уникальное на уровне сервера, или для сервера IED-устройства и Id-клиента, или в пределах всей системы).

9.4 Описание системы связи

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

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

UML-схема, приведенная на рисунке 16, дает общее представление о секции Communication.

Рисунок 16 — Общее представление о секции Communication через схему UML

Далее следует формальное определение XML schema:

<xs:element name=«Communication» type=«tCommunication»> <xs:unique name=«uniqueSubNetwork»> <xs:selector xpath=»./scl:SubNetwork«/> <xs:field xpath=»@name«/> </xs:unique> </xs:element> <xs:complexType name=»tCommunication«> xs:complexContent <xs:extension base=»tUnNaming«> xs:sequence <xs:element name=»SubNetwork» type=«tSubNetwork» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

Секция Communication может дополнительно содержать секции Text и Private (как производные от tUnNaming). Имена SubNetworks (подсети) должны быть уникальными.

9.4.2 Определение SubNetwork

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

<xs:complexType name=«tSubNetwork»> xs:complexContent <xs:extension base=«tNaming»> xs:sequence <xs:element name=«BitRate» type=«tBitRateInMbPerSec» minOccurs=«0»/> <xs:element name=«ConnectedAP» type=«tConnectedAP» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«type» type=«xs:normalizedString» use=«optional»> xs:annotation <xs:documentation xml:lang=«en»>The bus protocol types are defined in IEC 61850 Part 8 and 9 </xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType>

Атрибуты подсети SubNetwork определены, как показано в таблице 32.

Атрибуты элемента SubNetwork

Атрибут	Описание
name	Имя, идентифицирующее данную шину; является уникальным в пределах данного файла SCL
desc	Некоторый пояснительный текст к данной SubNetwork
type	Тип протокола SubNetwork; типы протокола определяют на уровне SCSM. В примерах в качестве протокола, определенного в МЭК 61850-8-1, используют 8-MMS

Типы протокола определены в отображениях стека (на уровне SCSM), для данной серии стандартов — в серии стандартов МЭК 61850-8-1 и в МЭК 61850-9-1, МЭК 61850-9-2. Названия протоколов МЭК 61850-8-1 начинаются с "8 - » , а МЭК 61850-9-1 и МЭК 61850-9-2 — с "9 - » . Исключение — случай, когда они идентичны. Например, протокол МЭК 61850-8-1 есть 8-MMS; тот же протокол использует МЭК 61850-9-2.

SubNetwork содержит дополнительный элемент BitRate, определяющий скорость передачи битов в Мбит/с, а также список точек доступа IED-устройства, через которые эти IED-устройства соединяются с точками доступа подсети SubNetwork. Она наследует из tUnNaming элементы Private и Text.

<xs:complexType name=«tConnectedAP»> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«Address» type=«tAddress» minOccurs=«0»/> <xs:element name=«GSE» type=«tGSE» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«SMV» type=«tSMV» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«PhysConn» type=«tPhysConn» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«iedName» type=«tName» use=«required»/> <xs:attribute name=«apName» type=«tName» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType>

Точкой доступа IED-устройства для соединения с SubNetwork является ConnectedAP.

Она имеет атрибуты, приведенные в таблице 33.

Атрибуты элемента ConnectedAP (точка доступа к соединению)

Атрибут	Описание
iedName	Имя, идентифицирующее IED-устройство
apName	Имя, определяющее данную точку доступа в пределах IED-устройства
desc	Некоторый пояснительный текст к данной точке доступа в данной подсети

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

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

9.4.3 Определение адреса

Элемент Address (адрес) содержит параметры адреса данной точки доступа на данной шине — по меньшей мере один параметр. Определение различных параметров приводится в содержащихся элементах P. Атрибут type элемента P определяет значение параметра. Смысловое значение параметров P зависит от типа протокола подсети и поэтому должно быть определено на соответствующем уровне SCSM. Те параметры, которые используют с МЭК 61850-8-1 и МЭК 61850-9-1, МЭК 61850-9-2, содержатся в атрибуте type перечисляемого типа tPTypeEnum. Объяснение см. в соответствующих частях настоящего стандарта.

<xs:complexType name=«tAddress»> xs:sequence <xs:element name=«P» type=«tP» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType>

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

<xs:complexType name=«tP»> xs:simpleContent <xs:extension base=«tPAddr»> <xs:attribute name=«type» type=«tPTypeEnum» use=«required»/> </xs:extension> </xs:simpleContent> </xs:complexType>

tPAddr — непустая строка, не содержащая никаких специальных знаков, например LF, CR или Tab. Предопределенные значения tPTypeEnum определены в МЭК 61850-8-1. Допускаются также типы адресов, определенные пользователем (см. ниже).

С тем чтобы обеспечить высокую достоверность проверки содержимого адреса XML-анализатором, tP был ограничен (в смысле XML schema) для каждого из этих определенных типов адреса. Эти ограничения типов называют tP_, после них следует тип адреса, как в tPTypeEnum. Для того чтобы использовать эти ограничения, в элементе P должен быть задан атрибут xsi:type. Таким образом, есть два способа обеспечить такой адрес. Например, для IP-адреса обе из приведенных формулировок являются эквивалентными с точки зрения семантики и синтаксиса:

10.0.0.11

10.0.0.11

Преимущество второй формулировки, в которой используется тип ограничения tP, заключается в том, что достоверность значения адреса (здесь — 10.0.0.11) может быть подтверждена XML-анализатором. При использовании первой формулировки значение адреса abc будет рассматриваться как абсолютно корректное, тогда как во второй формулировке ожидается значение, приведенное к виду ddd.ddd.ddd.ddd, где каждая буква d соответствует цифре.

Даже при использовании ограниченного типа должен быть указан (корректный) тип адреса.

Ограничение: расширения типа P типа перечисления type tPTypeEnum должны начинаться с прописной буквы и содержать только буквенно-цифровые знаки и дефисы (-).

9.4.4 Определение адреса GSE-сообщений

Сведения об адресах всех блоков управления основаны на абстрактном типе tControlBlock. Он дает элемент Address, который устанавливает параметры адреса, связанные с блоком управления, и ссылку на блок управления в пределах IED-устройства с помощью атрибутов IdInst и cbName. Поскольку GSE-сообщения, равно как и блоки управления SMV, должны находиться в пределах LLN0, этого достаточно.

<xs:complexType name=«tControlBlock» abstract=«true»> xs:annotation <xs:documentation xml:lang=«en»>A control block within a Logical Device (in LLN0).</xs:documentation> </xs:annotation> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«Address» type=«tAddress» minOccurs=«0»/> </xs:sequence> <xs:attribute name=«IdInst» type=«tName» use=«required»/> <xs:attribute name=«cbName» type=«tName» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType>

Элемент GSE-сообщения определяет адрес блока управления GSE в данном IED-устройстве.

<xs:complexType name=«tGSE»> xs:complexContent <xs:extension base=«tControlBlock»> xs:sequence <xs:element name=«MinTime» type=«tDurationInMilliSec» minOccurs=«0»/> <xs:element name=«MaxTime» type=«tDurationInMilliSec» minOccurs=«0»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

Атрибуты имеют значения, приведенные в таблице 34.

Атрибуты элемента GSE

Атрибут	Описание
desc	Пояснительный текст
IdInst	Идентификация экземпляра LD в пределах данного IED-устройства, на котором расположен блок управления. В LN нет необходимости, поскольку эти блоки управления содержатся только в LLN0
cbName	Имя блока управления в пределах LLN0 экземпляра LD IdInst

Элемент Address содержит параметры адреса GSE-сообщения в том же синтаксисе, что и адрес сервера. Соответствующие значения типа P определены на соответствующем уровне SCSM.

Элементы MinTime и MaxTime задают следующие интервалы времени:

• MinTime — максимально допустимая задержка отправки в миллисекундах при изменении данных;
• MaxTime — время контроля источника в миллисекундах (время цикла поступления контрольного сигнала). В течение этого времени отказ источника должен быть обнаружен клиентом.

Элементы MinTime и MaxTime могут влиять на параметры на уровне SCSM. Какие это параметры и какое влияние они испытывают, определяется на соответствующем уровне SCSM.

9.4.5 Определение адреса SMV

Элемент SMV определяет адрес блока управления выборочными значениями — точно так же, как элемент GSE-сообщения делает это для блоков управления GSE-сообщениями. Он также основан на типе схемы tControlBlock и следовательно имеет те же атрибуты, что и блок управления GSE-сообщениями.

<xs:complexType name=«tSMV»> xs:complexContent <xs:extension base=«tControlBlock»/> </xs:complexContent> </xs:complexType>

Атрибуты имеют значения, приведенные в таблице 35.

Атрибуты элемента SMV

Атрибут	Описание
desc	Пояснительный текст
IdInst	Идентификация экземпляра LD в пределах данного IED-устройства, на котором расположен блок управления. В LN нет необходимости, поскольку эти блоки управления существуют только в LLN0
cbName	Имя блока управления в пределах LLN0 экземпляра LD IdInst

Элемент Address содержит параметры адреса SMV в том же синтаксисе, что и адрес сервера. Соответствующие значения типа P определены на соответствующем уровне SCSM.

9.4.6 Параметры физических соединений

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

<xs:complexType name=«tPhysConn»> xs:sequence <xs:element name=«P» type=«tP» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«type» type=«xs:normalizedString» use=«required»/> </xs:complexType>

Атрибут type специфицирует тип физического соединения данной точки доступа к шине, а value (значение) специфицирует экземпляр данного типа (например, для type=Plug value будет ST). Допустимые типы и значения определяются в отображении стека. Допускается повторение элемента P, если одного значения недостаточно. Для физического соединения, определенного в МЭК 61850-8-1, должны использоваться типы и соответствующие значения, приведенные в таблице 36.

Определения PhysConn P-Type

Тип PhysConn	Тип P	Рекомендуемые значения (зависимые от МЭК 61850-8-1)
Connection	Type	10BaseT для электрического соединения; FOC для оптического соединения; Radio для радиосвязи, например сеть WLAN
	Plug	RJ45 разъем для электрического штепсельного разъема; ST для штекера соединения байонетного типа (оптоволоконная связь)

Ограничение: значения типа PhysConn должны начинаться с прописной буквы и содержать только буквенно-цифровые символы.

9.4.7 Пример секции Communication

Следующая часть SCL показывает секцию Communication с одной подсетью XW1, к которой подключены два IED-устройства, имеющие точки доступа S1. Тип протокола 8-MMS специфицирует протокол, как определено в МЭК 61850-8-1 и МЭК 61850-9-2. PhysConn и типы адресов приводятся просто для примера. Одно IED-устройство также содержит блок управления GSE-сообщениями с адресом, однако без элементов MaxTime и MinTime, которые являются дополнительными. Другое устройство содержит блок управления выборочными значениями.

Station bus 10 10.0.0.11 255.255.255.0 10.0.0.101 00000001 01 01 FOC ST 01-0C-CD-04-00-01 4000 123 4
10.0.0.1 255.255.255.0 10.0.0.101 00000001 01 01 01-0C-CD-01-00-01 3000 4

9.5 Шаблоны типа данных

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

Этот раздел определяет типы инстанцируемых LN. Тип LN является инстанцируемым шаблоном данных логического узла. К LNodeType (в других местах он называется также LN type) обращаются всякий раз, когда этот инстанцируемый тип необходим в пределах IED-устройства. Шаблон типа логического узла строится из элементов DATA (DO), которые, в свою очередь, имеют тип DO — производный классов данных DATA (CDC), определенных в МЭК 61850-7-3. DO состоят из атрибутов (DA) или из элементов уже определенных типов DO (SDO). Атрибут (DA) имеет функциональную связь и может либо иметь базисный тип, либо быть перечислением или структурой DAType. DAType строится из элементов BDA, определяющих элементы структуры, которые вновь могут быть элементами BDA или иметь базовый тип — например, DA.

Все типы имеют уникальную идентификацию через свой type id и через атрибут iedType. При генерации системного файла SCD из файлов ICD IED-устройства может возникнуть необходимость изменения идентификации типа LN, для того чтобы сохранить однозначность всех определений IED-устройств. В целях сохранения возможной семантической информации об именах типов рекомендуется использовать атрибут iedType для определения отношения специфического типа LN к типу IED-устройства. Если этого недостаточно, может быть сгенерировано новое имя типа LN путем конкатенации имени IED-устройства (которое должно быть уникальным в пределах файла) со старым именем типа (которое должно быть уникальным по меньшей мере в пределах IED-устройства). Если тип LN в целом действителен для нескольких IED-устройств, то атрибут IEDType должен быть определен как пустая строка. Это особенно необходимо для определений типа, которые должны использоваться в файле SSD с несуществующими IED-устройствами и, следовательно, типами IED-устройств.

Порядок элементов DO в пределах определения LNodeType и элементов SDO/DA в пределах определения DOType должен также специфицировать порядок значений данных в пределах сообщения, если он не задан в другом месте, например путем явным образом заданных определений FCDA в наборе данных, вплоть до атрибута. Порядок в определении LNodeType входит в задачи средств управления конфигурированием IED-устройств, в то время как порядок в наборе данных является задачей средств управления конфигурированием системы.

Рисунок 17 дает общее представление о секции DataTypeTemplates в Schema на основе UML.

Рисунок 17 — Общее представление о секции DataTypeTemplates на основе UML

Далее следует определение XML schema, включая ограничения, заданные в пределах DataTypeTemplates.

<xs:element name=«DataTypeTemplates» type=«tDataTypeTemplates»> <xs:unique name=«uniqueLNodeType»> <xs:selector xpath=«scl:LNodeType»/> <xs:field xpath=«@id»/> <xs:field xpath='@iedType«/> </xs:unique> <xs:key name=»DOTypeKey«> <xs:selector xpath=»scl:DOType«/> <xs:field xpath=»@id«/> </xs:key> <xs: keyref name=»ref2DOType» refer=«DOTypeKey»> <xs:selector xpath=«scl:LNodeType/scl:DO»/> <xs:field xpath=«@type»/> </xs:keyref> <xs: keyref name=«ref2DOTypeForSDO» refer=«DOTypeKey»> <xs:selector xpath=«scl:DOType/scl:SDO»/> <xs:field xpath=«@type»/> </xs:keyref> <xs:key name=«DATypeKey»> <xs:selector xpath=«scl:DAType»/> <xs:field xpath=«@id»/> </xs:key> <xs:key name=«EnumTypeKey»> <xs:selector xpath=«scl:EnumType»/> <xs:field xpath=«@id»/> </xs:key> <xs:complexType name=«tDataTypeTemplates»> xs:sequence

<xs:element name=«LNodeType» type=«tLNodeType» maxOccurs=«unbounded»> <xs:unique name=«uniqueDOInLNodeType»> <xs:selector xpath=«scl:DO»/> <xs:field xpath=«@name»/> </xs:unique> </xs:element> <xs:element name=«DOType» type=«tDOType» maxOccurs=«unbounded»> <xs:unique name=«uniqueDAorSDOInLDOType»> <xs:selector xpath=»./*«/> <xs:field xpath=»@name«/> </xs:unique> </xs:element> <xs:element name=»DAType» type=«tDAType» minOccurs=«0» maxOccurs=«unbounded»> <xs:unique name=«uniqueBDAInLDAType»> <xs:selector xpath=«scl:BDA»/> <xs:field xpath=«@name»/> </xs:unique> </xs:element> <xs:element name=«EnumType» type=«tEnumType» minOccurs=«0» maxOccurs=«unbounded»> <xs:unique name=«uniqueOrdInEnumType»> <xs:selector xpath=«scl:EnumVal»/> <xs:field xpath=«@ord»/> </xs:unique> </xs:element> </xs:sequence> </xs:complexType> </xs:element>

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

Таблица 37

Элементы определения шаблона

Имя элемента (Element) из части Template	Описание
LNodeType	Тип инстанцируемого LN, к которому обращаются IED-устройства и элементы из секции Substation согласно МЭК 61850-7-4
DOType	Тип инстанцируемых данных DATA, к которому обращаются из LNodeType или из элемента SDO другого DOType. Инстанцируемая версия на основе определений CDC из МЭК 61850-7-3
DAType	Тип инстанцируемого структурированного атрибута; получает ссылки от элемента DA DOType или от другого DAType для определений вложенного типа. Основано на определениях структуры атрибута МЭК 61850-7-3
EnumType	Перечисляемый тип; получает ссылки от элемента DA DOType или от DAType, в случае когда bType есть Enum. Определения должны соответствовать перечисляемым определениям в МЭК 61850-7-3 и МЭК 61850-7-4

9.5.2 Определения LNodeType

Тип LN (элемент LNodeType) содержит список данных DATA (объекты данных, DO), их атрибуты, возможные значения по умолчанию для параметров конфигурирования.

<xs:complexType name=«tLNodeType»> xs:complexContent <xs:extension base=«tIDNaming»> xs:sequence <xs:element name=«DO» type=«tDO» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«iedType» type=«tAnyName» use=«optional»/> <xs:attribute name=«InClass» type=«tLNClassEnum» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType>

Атрибуты имеют значения, приведенные в таблице 38.

Таблица 38

Атрибуты элемента LNodeType

Атрибут	Описание
id	Ссылка, идентифицирующая данный тип LN в пределах данной секции языка SCL; используется атрибутом логического узла LNType для ссылки на данное определение
desc	Дополнительный текст для пояснения к данному LN type
iedType	Тип производителя IED-устройства, к которому принадлежит данный LN type
InClass	Базовый класс LN данного типа, как указано в МЭК 61850-7-3. Следует обратить внимание, что здесь присутствует перечисление, которое позволяет расширения (имена, содержащие только прописные буквы)

<xs:complexType name=«tDO»> xs:annotation <xs:documentation xml:lang=«en»>See Section 9.5.1</xs:documentation> </xs:annotation> xs:complexContent <xs:extension base=«tUnNaming»> <xs:attribute name=«name» type=«tRestrName1stU» use=«required»/> <xs:attribute name=«type» type=«tName» use=«required»/> <xs:attribute name=«accessControl» type=«xs:normalizedString» use=«optional»/> <xs:attribute name=«transient» type=«xs:boolean» use=«optional» default=«false»/> </xs:extension> </xs:complexContent> </xs:complexType>

Атрибуты DO определены, как приведенные в таблице 39.

Таблица 39

Атрибуты элемента DO

Атрибут	Описание
name	Имя данных DATA, как указано, например, в стандарте МЭК 61850-7-4
type	Тип обращается к id определения DOType
accessControl	Определение управления доступом для данного DO. При его отсутствии применяется любое определение управления доступом верхнего уровня
transient	При задании логической единицы (true) указывает на применение определения Transient в соответствии с МЭК 61850-7-4

9.5.3 Определение DOtype

Элемент DOType, к которому обращается атрибут type элемента LNodeTypeDO, имеет следующий синтаксис:

<xs:complexType name=«tDOType»> xs:complexContent <xs:extension base=«tlDNaming»> <xs:choice minOccurs=«1» maxOccurs=«unbounded»> <xs:element name=«SDO» type=«tSDO»/> <xs:element name=«DA» type=«tDA»/> </xs:choice> <xs:attribute name=«iedType» type=«tAnyName» use=«optional»/> <xs:attribute name=«cdc» type=«tCDCEnum» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType>

DOType определяет содержимое DO. Это могут быть атрибуты (элементы DA) или ссылка на другой DOType (элемент SDO). Атрибуты имеют значения, приведенные в таблице 40.

Таблица 40

Атрибуты элемента DOType

Атрибут	Описание
id	Идентификация (глобальная идентификация) данного DOType в пределах iedType. Используется для обращения к этому типу
iedType	Тип IED-устройства, к которому принадлежит данный DOType. Пустая строка позволяет ссылки для всех типов IED-устройств или из секции Substation
cdc	Базисный CDC (Common Data Class — класс общих данных) в соответствии с определением МЭК 61850-7-3

Далее элемент SDO обращается к другому определению DOType. Предупреждение: не допускаются рекурсивные ссылки, которые, однако, могут не проверяться на уровне синтаксиса!

<xs:complexType name=«tSDO»> xs:complexContent <xs:extension base=«tNaming»> <xs:attribute name=«type» type=«tName» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tDA»>

Атрибуты элемента SDO приведены в таблице 41.

Атрибуты элемента SDO

Атрибут	Описание
name	Имя SDO
desc	Пояснительный текст для SDO
type	Ссылки DOType, определяющие содержимое SDO

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

9.5.4 Определение атрибута данных DA

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

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

Элемент DA имеет либо базисный тип, либо ссылку на определение типа структурированного атрибута, например, в случае атрибута, имеющего структуру, аналогичную ScaledValueConfig. Если DA — массив, тогда атрибут count дает количество элементов в массиве. МЭК 61850-7-3 и для некоторых перечислений МЭК 61850-7-4 определяют тип определенного атрибута, основанного на CDC DO.

Синтаксис кодирования значений в элементе Val элемента DA в этом случае должен соблюдать определения кодирования типа данных XML schema для серии стандартов МЭК 61850-7. Отображение типа выполняется, как приведенные в таблице 42.

Таблица 42

Отображение типа данных

Базисный тип МЭК 61850-7-x	Тип данных XML Schema (xs)	Отображение значения
INT8, INT16, INT24, INT32, INT8U, INT16U, INT24U, INT32U	integer	Целое число, десятичная точка отсутствует (99999)
FLOAT32, FLOAT64	double	Число с десятичной точкой или без точки (999,99999)
BOOLEAN	boolean	false, true или 0, 1
ENUMERATED, CODED ENUM	normalizedString	Имена элемента перечисления, как определено в серии стандартов МЭК 61850-7, как строковые значения
Octet string	base64Binary	Кодирование в соответствии с RFC 2045, пункт 6.8
VisibleString	normalizedString	Символьная строка без символов табуляции, перевода строки или возврата каретки, ограничена 8-разрядными символами (UTF-8 однобайтовое кодирование, ИСО/МЭК 8859-1)
UnicodeString	normalizedString	Символьная строка без символов табуляции, перевода строки или возврата каретки. Все символы в файле XML принципиально Unicode, например в UTF-8 кодировании

Примечание - Не предусмотрено специфицировать в файле SCL значения типов Timestamp, EntryTime, INT128 и Quality, поскольку они принадлежат к реальным оперативным данным.

Смысловое значение средства управления конфигурацией IED-устройства может быть различным в зависимости от возможностей устройства, функциональных характеристик атрибута и этапа процесса проектирования и разработки. Атрибут valKind DA позволяет выполнить спецификацию этого смыслового значения. Он игнорируется, если значение не задается, и в таблице 43 специфицирован не для всех случаев (например, для атрибутов q и t).

<xs:simpleType name=«tValKindEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«Spec»/> <xs:enumeration value=«Conf»/> <xs:enumeration value=«RO»/> <xs:enumeration value=«Set»/> </xs:restriction> </xs:simpleType>

Смысловое значение атрибута value kind (valKind)

Значение valKind	Функциональные связи	Этап проектирования и разработки	Смысловое значение
Spec	Неоперационные (CF, DC)	Этап спецификации	На этапе спецификации, как правило, в файле SCD определяется желаемое значение
Conf	CF, DC, операционный атрибут CDC, применяемый для настроек	Шаблон IED-устройства, после программирования IED-устройства	Это значение недоступно в режиме онлайн на IED-устройстве. IED-устройство программируется таким образом, чтобы использовать это значение
RO	Атрибут состояния операционного процесса	Шаблон IED-устройства	Значение по умолчанию данного атрибута, применяемое, если q.source установлен на умолчание или значение фиксировано для IED-устройства
RO	CF, DC, операционный атрибут данных, применяемый для настроек	Шаблон IED-устройства, после конфигурирования IED-устройства	Значение только для считывания на IED-устройстве — может задаваться лишь во время конфигурирования
Set	CF, DC	Во время/после конфигурирования IED-устройства	Определенное значение уставки. Значение установлено (должно быть установлено) в пределах IED-устройства
Set	Операционные значения процесса (за исключением времени и качества)	Во время (после) конфигурирования IED-устройства (возможно изменение RO на Set)	Значение по умолчанию данного операционного атрибута, применяемое, если q.source установлен на умолчание
Set	Значение операционной уставки (SP, SG для всех данных, используемых как уставки)	Во время (после) конфигурирования IED-устройства	Значение уставки для точки настройки относительно параметра

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

Далее следует определение синтаксиса. Оно основано на абстрактном типе tAbstractDatAttribute, который позднее повторно используют в определении структуры атрибута.

<xs:complexType name=«tDA»> xs:complexContent <xs:extension base=«tAbstractDataAttribute»> <xs:attributeGroup ref=«agDATrgOp»/> <xs:attribute name=«fc» type=«tFCEnum» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:attributeGroup name=«agDATrgOp»> <xs:attribute name=«dchg» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«qchg» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«dupd» type=«xs:boolean» use=«optional» default=«false»/> </xs:attributeGroup> <xs:complexType name=«tAbstractDataAttribute» abstract=«true»> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«Val» type=«tVal» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«name» type=«tAttributeNameEnum» use=«required»/> <xs:attribute name=«sAddr» type=«xs:normalizedString» use=«optional»/> <xs:attribute name=«bType» type=«tBasicTypeEnum» use=«required»/> <xs:attribute name=«valKind» type=«tValKindEnum» use=«optional» default=«Set»/> <xs:attribute name=«type» type=«tAnyName» use=«optional»/> <xs:attribute name=«count» type=«xs:unsignedInt» use=«optional» default=«0»/> </xs:extension> </xs:complexContent> </xs:complexType>

Атрибуты элемента DA определены в таблице 44.

Таблица 44

Атрибуты элемента DA

Атрибут	Описание
desc	Некоторый пояснительный текст к атрибуту
name	Имя атрибута; тип tAttributeEnum ограничивает имена атрибутов по МЭК 61850-7-3, а также новыми, начинающимися со строчных букв
fc	Функциональная связь для данного атрибута; fc=SG всегда имеет следствием также fc=SE; если атрибут имеет ST и CO соответственно MX и SP, то всегда принимается функционально связанное значение состояния. Вторая функциональная связь либо определяется атрибутами на уровне SCSM (например, в МЭК 61850-8-1) либо неявным образом определяется значениями ctlModel
dchg, qchg, dupd	Определяет опции пуска, которые поддерживает атрибут. Значение, равное логической единице (true), означает поддержку
sAddr	Дополнительный короткий адрес данного атрибута DO (9.5.4.3)
bType	Базисный тип атрибута, принятый из tBasicTypeEnum (9.5.4.2)
type	Используется, только если bType = Enum или bType = Struct для обращения к соответствующему перечисляемому типу или определению DAType (структуре атрибута)
count	Дополнительный атрибут. Задает число элементов массива для тех случаев, когда атрибут есть массив
valKind	Определяет интерпретацию значения, если оно задано (см. таблицу 43)

Атрибуты name, fc и bType определяются всегда. Должны быть определены инстанцируемые атрибуты, содержащиеся в пределах DO.

9.5.4.2 Базисный тип атрибута

<xs:simpleType name=«tPredefinedBasicTypeEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«BOOLEAN»/> <xs:enumeration value=«INT8»/> <xs:enumeration value=«INT16»/> <xs:enumeration value=«INT24»/> <xs:enumeration value=«INT32»/> <xs:enumeration value=«INT128»/> <xs:enumeration value=«INT8U»/> <xs:enumeration value=«INT16U»/> <xs:enumeration value=«INT24U»/> <xs:enumeration value=«INT32U»/> <xs:enumeration value=«FLOAT32»/> <xs:enumeration value=«FLOAT64»/> <xs:enumeration value=«Enum»/> <xs:enumeration value=«Dbpos»/> <xs:enumeration value=«Tcmd»/> <xs:enumeration value=«Quality»/> <xs:enumeration value=«Timestamp»/> <xs:enumeration value=«VisString32»/> <xs:enumeration value=«VisString64»/> <xs:enumeration value=«VisString255»/> <xs:enumeration value=«Octet64»/> <xs:enumeration value=«Struct»/> <xs:enumeration value=«EntryTime»/> <xs:enumeration value=«Unicode255»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tExtensionBasicTypeEnum»>

xs:annotation <xs:documentation xml:lang=«en»>User extensible basic types.</xs:documentation> </xs:annotation> <xs:restriction base=«xs:Name»> <xs:pattern value=«[\p{L},\d]+»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tBasicTypeEnum»> xs:annotation <xs:documentation xml:lang=«en»>All possible basic types.</xs:documentation> </xs:annotation> <xs:union memberTypes=«tPredefinedBasicTypeEnum tExtensionBasicTypeEnum»/> </xs:simpleType>

tPredefinedBasicTypeEnum содержит определения согласно серии стандартов МЭК 61850-7. CODED ENUMs замещаются конкретными базисными типами Quality, Dbpos для положений двойного бита в DPC и DPS и Tcmd для команд переключателя напряжения, как в BSC. Поскольку Quality остается непрозрачным (значения в SCL не требуются), при кодировании значения Dbpos и Tcmd обрабатываются как Enum. Для VisibleString, UnicodeString и OctetString вводятся типы (подтипы) в зависимости от длины. VisString32, например, есть VisibleString с максимальной длиной 32 знака.

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

Приведенный ниже пример определяет атрибут stVal для DPC CDC без значения согласно МЭК 61850-7-3:

9.5.4.3 Короткие адреса

Атрибут sAddr разрешает размещение короткого адреса в атрибутах DO. Короткие адреса могут быть использованы при обмене информацией для повышения эффективности связи либо при обработке сообщений на стороне клиента или сервера. Более того, они могут быть использованы с атрибутом как внутренняя идентификация IED. Чтобы использовать короткие адреса при обмене сообщениями, необходимо соблюдать следующие условия:

• отображение стека должно допускать их и определять их смысловое значение;
• IED-устройства должны разрешать их.

Детальный синтаксис значения короткого адреса зависит от стека, если стек (на уровне SCSM) определяет его использование. В противном случае детальный синтаксис зависит от средства программирования IED. SCL предусматривает двухуровневую иерархию для коротких адресов, которые используют при обмене сообщениями:

1. коммуникационный адрес IED-устройства/сервера/точки доступа;

2. короткий адрес элемента данных на уровне атрибута.

Можно использовать короткий адрес вместо символического коммуникационного адреса IED-устройства, если короткий адрес является уникальным на уровне всей системы и это не противоречит требованиям на уровне SCSM. В противном случае объем значения короткого адреса и синтаксис являются частными для IED-устройства.

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

9.5.4.4 Значения

Определение дополнительного значения содержит одно значение. Для атрибутов с fc = SG атрибут sGroup специфицирует группу настроек, к которой принадлежит это значение. Значение может быть определено для каждой заданной группы настроек. Смысл значения в процессе разработки и проектирования определяется на уровне DA/DAI через атрибут valKind.

<xs:complexType name=«tVal»> xs:simpleContent <xs:extension base=«xs:normalizedString»> <xs:attribute name=«sGroup» type=«xs:unsignedInt» use=«optional»/> </xs:extension> </xs:simpleContent> </xs:complexType>

Описание атрибута: sGroup определяет номер группы настроек (при fc = SG), к которой принадлежит это значение.

Значение sGroup, применяемое в пределах IED-устройства, должно быть проверено относительно определения существующей группы настроек на данном IED-устройстве, для которой указан максимально допустимый номер (SettingControl.numOfSGs). Если дополнительный атрибут sGroup полностью отсутствует, то либо атрибута рассматриваемых данных нет ни в одной группе настроек (fc /= SG), либо значение данных применяется ко всем группам настроек.

9.5.5 Тип структуры атрибута данных

В случае если значение DA.bType есть Struct, атрибут DA.type обращается к структуре атрибута. Эти структуры задаются элементами DAType.

<xs:complexType name=«tDAType»> xs:annotation <xs:documentation xml:lang=«en»>See Section 9.5.2</xs:documentation> </xs:annotation> xs:complexContent <xs:extension base=«tIDNaming»> xs:sequence <xs:element name=«BDA» type=«tBDA» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«iedType» type=«tAnyName» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType>

Элемент DAType содержит список атрибутов с элементом BDA. Эти атрибуты могут либо иметь базисный тип, либо обращаться к структуре другого атрибута. В отношении структуры, типа и присваивания имени определение должно следовать МЭК 61850-7-3.

<xs:complexType name=«tBDA»> xs:annotation <xs:documentation xml:lang=«en»>Basic Data Attribute?</xs:documentation> </xs:annotation> xs:complexContent <xs:extension base=«tAbstractDataAttribute»/> </xs:complexContent> </xs:complexType>

Элемент BDA инстанцирует tAbstractDataAttribute и, следовательно, имеет те же атрибуты.

Атрибуты элемента BDA определены в таблице 45.

Таблица 45

Атрибуты элемента BDA

Атрибут	Описание
desc	Некоторый пояснительный текст к атрибуту
name	Имя атрибута; тип tAttributeEnum ограничивает имена атрибутов по МЭК 61850-7-3, а также новыми, начинающимися со строчных букв
sAddr	Дополнительный короткий адрес данного атрибута BDA
bType	Базисный тип атрибута, принятый из tBasicTypeEnum
type	Используется, только если bType = Enum или bType = Struct для ссылки на соответствующий перечислимый тип и определение DAType
count	Дополнительный. Задает число элементов массива в тех случаях, когда атрибут есть массив
valKind	Определяет интерпретацию значения, если оно задано (см. таблицу 43)

Следует обратить внимание, что атрибут sAddr может появляться на нескольких уровнях начиная с элемента DA. В принципе эта ситуация разрешается двояко:

• используется только значение низшего уровня;
• используются значения на всех уровнях как род короткого адреса в иерархии.

Решение о том, какой метод использовать для программирования IED, принимается в соответствии с SCSM (см. также 9.5.4.3).

Для valKind должно быть использовано только значение низшего уровня.

9.5.6 Перечисляемые типы

Перечисления обычно используют в нескольких типах LNodeType. Для них выполняется определение типа перечисления.

<xs:complexType name=«tEnumType»> xs:complexContent <xs:extension base=«tIDNaming»> xs:sequence <xs:element name=«EnumVal» type=«tEnumVal» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

Определения перечисления действительны для всех IED-устройств; они не являются IED-зависимыми. Поэтому допустимые имена стандартизированы следующим образом:

• для перечислений из МЭК 61850-7-3 принимается имя атрибута. В тех случаях, когда при различных перечислениях для различных CDC используется одно и то же имя атрибута, перед именем атрибута дополнительно указывается CDC-имя;
• перечисления из МЭК 61850-7-4 задаются поверх классов общих данных INC или INS. Поэтому и значение состояния (value status), и значение управления для INC (control value) должны содержать тип перечисления Enum вместо INT32. На уровне стека должны также применяться отображения типов данных Enum. Для этих перечислений должно быть принято имя данных DATA. В тех случаях, когда для различных классов LN из различных перечислений принимаются одинаковые имена данных DATA, действуют следующие условия:
• одно перечисление является подмножеством другого: в этом случае в качестве перечисления применяется надмножество;
• перечисления различны: в этом случае перед именем DATA должно дополнительно указываться имя класса LN.

Полученные нормативные определения перечисления из МЭК 61850-7-3 и МЭК 61850-7-4 приведены в приложении B. Они также служат примерами определений перечисления.

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

Смысловое значение атрибутов элемента EnumType (тип перечисления) приведено в таблице 46.

Атрибуты элемента EnumType

Атрибут	Описание
id	Ссылка, определяющая тип перечисления; используется атрибутом type элементов DA и BDA для обращения к определению в том случае, когда bType есть Enum
desc	Дополнительный текст для описания данного LN type

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

<xs:complexType name=«tEnumVal»> xs:simpleContent <xs:extension base=«xs:normalizedString»> <xs:attribute name=«ord» type=«xs:integer» use=«required»/> </xs:extension> </xs:simpleContent> </xs:complexType>

Атрибут ord содержит порядок значений начиная с 0. Значением типа normalizedString является строка символов, как определено в МЭК 61850-7-3 или МЭК 61850-7-4.

9.5.7 Примеры шаблона типа данных

Примеры можно найти в секции DataTypeTemplates в разделе D.2 (приложение D).

Приложение A (обязательное)

СИНТАКСИС ЯЗЫКА SCL: ОПРЕДЕЛЕНИЕ XML SCHEMA

A.1 Базовые типы

Файл SCL_BaseSimpleTypes.xsd

<xs:schema targetNamespace=«http://www.iec.ch/61850/2003/SCL» xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:xs=«http://www.w3.org/2001/XMLSchema» elementFormDefault=«qualified» attributeFormDefault=«unqualified» version=«1.0»> xs:annotation <xs:documentation xml:lang=«en»>COPYRIGHT IEC, 2003. Version 1.0. Release 2003/09/19. (Uncommented)</xs:documentation> </xs:annotation> <xs:simpleType name=«tRef»> <xs:restriction base=«xs:normalizedString»> <xs:pattern value=».+/.+/.+/.+«/> </xs:restriction> </xs:simpleType> <xs:simpleType name=»tAnyName«> <xs:restriction base=»xs:normalizedString«/> </xs:simpleType> <xs:simpleType name=»tName«> <xs:restriction base=»tAnyName«> <xs:minLength value=»1«/> </xs:restriction> </xs:simpleType> <xs:simpleType name=»tRestrName«> <xs:restriction base=»xs:Name«> <xs:pattern value=»[\d,\p{L}]+«/> </xs:restriction>»

</xs:simpleType> <xs:simpleType name=«tRestrName1stU»> <xs:restriction base=«xs:Name»> <xs:pattern value=«\p{Lu}[\d,\p{L}]„/> </xs:restriction> </xs:simpleType> <xs:simpleType name=“tRestrName1stL»> <xs:restriction base=«xs:Name»> <xs:pattern value=«\p{LI}[\d,\p{L}]„/> </xs:restriction> </xs:simpleType> <xs:simpleType name=“tPAddr»> <xs:restriction base=«xs:normalizedString»> <xs:minLength value=«1»/> </xs:restriction> </xs:simpleType> </xs:schema>

Файл SCL_Enums.xsd

<xs:schema targetNamespace=«http://www.iec.ch/61850/2003/SCL» xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:xs=«http://www.w3.org/2001/XMLSchema» elementFormDefault=«qualified» attributeFormDefault=«unqualified» version=«1.0»> xs:annotation <xs:documentation xml:lang=«en»>COPYRIGHT IEC, 2003. Version 1.0. Release 2003/09/19. (Uncommented)</xs:documentation> </xs:annotation> <xs:include schemaLocation=«SCL_BaseSimpleTypes.xsd»/> <xs:simpleType name=«tPredefinedPTypeEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«IP»/> <xs:enumeration value=«IP-SUBNET»/> <xs:enumeration value=«IP-GATEWAY»/> <xs:enumeration value=«OSI-NSAP»/> <xs:enumeration value=«OSI-TSEL»/> <xs:enumeration value=«OSI-SSEL»/> <xs:enumeration value=«OSI-PSEL»/> <xs:enumeration value=«OSI-AP-Title»/> <xs:enumeration value=«OSI-AP-Invoke»/> <xs:enumeration value=«OSl-AE-Qualifier»/> <xs:enumeration value=«OSI-AE-Invoke»/> <xs:enumeration value=«MAC-Address»/> <xs:enumeration value=«APPID»/> <xs:enumeration value=«VLAN-PRIORITY»/>
<xs:enumeration value=«VLAN-ID»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tExtensionPTypeEnum»> <xs:restriction base=«xs:normalizedString»> <xs:pattern value=«\p{Lu}[\d,\p{L},-]*»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tPTypeEnum»> <xs:union memberTypes=«tPredefinedPTypeEnum tExtensionPTypeEnum»/> </xs:simpleType> <xs:simpleType name=«tPredefinedAttributeNameEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«T»/> <xs:enumeration value=«Test»/> <xs:enumeration value=«Check»/> <xs:enumeration value=«SIUnit»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tExtensionAttributeNameEnum»> <xs:restriction base=«tRestrName1stL»/> </xs:simpleType> <xs:simpleType name=«tAttributeNameEnum»> <xs:union memberTypes=«tPredefinedAttributeNameEnum tExtensionAttributeNameEnum»/> </xs:simpleType> <xs:simpleType name=«tPredefinedCommonConductingEquipmentEnum»>
<xs:restriction base=«xs:Name»> <xs:enumeration value=«CBR»/> <xs:enumeration value=«DIS»/> <xs:enumeration value=«VTR»/> <xs:enumeration value=«CTR»/> <xs:enumeration value=«GEN»/> <xs:enumeration value=«CAP»/> <xs:enumeration value=«REA»/> <xs:enumeration value=«CON»/> <xs:enumeration value=«MOT»/> <xs:enumeration value=«EFN»/> <xs:enumeration value=«PSH»/> <xs:enumeration value=«BAT»/> <xs:enumeration value=«BSH»/> <xs:enumeration value=«CAB»/> <xs:enumeration value=«GIL»/> <xs:enumeration value=«LIN»/> <xs:enumeration value=«RRC»/> <xs:enumeration value=«SAR»/> <xs:enumeration value=«TCF»/> <xs:enumeration value=«TCR»/> <xs:enumeration value=«IFL»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tExtensionEquipmentEnum»> <xs:restriction base=«xs:Name»> <xs:pattern value=«E\p{Lu}*»/>
</xs:restriction> </xs:simpleType> <xs:simpleType name=«tCommonConductingEquipmentEnum»> <xs:union memberTypes=«tPredefinedCommonConductingEquipmentEnum tExtensionEquipmentEnum»/> </xs:simpleType> <xs:simpleType name=«tPowerTransformerEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«PTR»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tTransformerWindingEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«PTW»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tPredefinedEquipmentEnum»> <xs:union memberTypes=«tCommonConductingEquipmentEnum tPowerTransformerEnum tTransformerWindingEnum»/> </xs:simpleType> <xs:simpleType name=«tEquipmentEnum»> <xs:union memberTypes=«tPredefinedEquipmentEnum tExtensionEquipmentEnum»/> </xs:simpleType> <xs:simpleType name=«tPredefinedGeneralEquipmentEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«AXN»/> <xs:enumeration value=«BAT»/>
<xs:enumeration value=«MOT»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tExtensionGeneralEquipmentEnum»> <xs:restriction base=«xs:Name»> <xs:pattern value=«E\p{Lu}*»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tGeneralEquipmentEnum»> <xs:union memberTypes=«tPredefinedGeneralEquipmentEnum tExtensionGeneralEquipmentEnum»/> </xs:simpleType> <xs:simpleType name=«tServiceSettingsEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«Dyn»/> <xs:enumeration value=«Conf»/> <xs:enumeration value=«Fix»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tPhaseEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«A»/> <xs:enumeration value=«B»/> <xs:enumeration value=«C»/> <xs:enumeration value=«N»/> <xs:enumeration value=«all»/> <xs:enumeration value=«none»/>
</xs:restriction> </xs:simpleType> <xs:simpleType name=«tAuthenticationEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«none»/> <xs:enumeration value=«password»/> <xs:enumeration value=«week»/> <xs:enumeration value=«strong»/> <xs:enumeration value=«certificate»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tAssociationKindEnum»> <xs:restriction base=«xs:token»> <xs:enumeration value=«pre-established»/> <xs:enumeration value=«predefined»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tLPHDEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«LPHD»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tLLN0Enum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«LLN0»/> </xs:restriction> </xs:simpleType>
<xs:simpleType name=«tDomainLNGroupAEnum»> <xs:restriction base=«xs:Name»> <xs:pattern value=«A[A-Z]„/> <xs:enumeration value=“ANCR»/> <xs:enumeration value=«ARCO»/> <xs:enumeration value=«ATCC»/> <xs:enumeration value=«AVCO»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tDomainLNGroupCEnum»> <xs:restriction base=«xs:Name»> <xs:pattern value=«C[A-Z]„/> <xs:enumeration value=“CILO»/> <xs:enumeration value=«CSWI»/> <xs:enumeration value=«CALH»/> <xs:enumeration value=«CCGR»/> <xs:enumeration value=«CPOW»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tDomainLNGroupGEnum»> <xs:restriction base=«xs:Name»> <xs:pattern value=«G[A-Z]*»/> <xs:enumeration value=«GAPC»/> <xs:enumeration value=«GGIO»/> <xs:enumeration value=«GSAL»/> </xs:restriction> </xs:simpleType>
<xs:simpleType name=«tDomainLNGrouplEnum»> <xs:restriction base=«xs:Name»> <xs:pattern value=«I[A-Z]„/> <xs:enumeration value=“IHMI»/> <xs:enumeration value=«IARC»/> <xs:enumeration value=«ITCI»/> <xs:enumeration value=«ITMI»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tDomainLNGroupMEnum»> <xs:restriction base=«xs:Name»> <xs:pattern value=«M[A-Z]„/> <xs:enumeration value=“MMXU»/> <xs:enumeration value=«MDIF»/> <xs:enumeration value=«MHAI»/> <xs:enumeration value=«MHAN»/> <xs:enumeration value=«MMTR»/> <xs:enumeration value=«MMXN»/> <xs:enumeration value=«MSQI»/> <xs:enumeration value=«MSTA»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tDomainLNGroupPEnum»> <xs:restriction base=«xs:Name»> <xs:pattern value=«P[A-Z]*»/> <xs:enumeration value=«PDIF»/> <xs:enumeration value=«PDIS»/>
<xs:enumeration value=«PDIR»/> <xs:enumeration value=«PDOP»/> <xs:enumeration value=«PDUP»/> <xs:enumeration value=«PFRC»/> <xs:enumeration value=«PHAR»/> <xs:enumeration value=«PHIZ»/> <xs:enumeration value=«PIOC»/> <xs:enumeration value=«PMRI»/> <xs:enumeration value=«PMSS»/> <xs:enumeration value=«POPF»/> <xs:enumeration value=«PPAM»/> <xs:enumeration value=«PSCH»/> <xs:enumeration value=«PSDE»/> <xs:enumeration value=«PTEF»/> <xs:enumeration value=«PTOC»/> <xs:enumeration value=«PTOF»/> <xs:enumeration value=«PTOV»/> <xs:enumeration value=«PTRC»/> <xs:enumeration value=«PTTR»/> <xs:enumeration value=«PTUC»/> <xs:enumeration value=«PTUV»/> <xs:enumeration value=«PUPF»/> <xs:enumeration value=«PTUF»/> <xs:enumeration value=«PVOC»/> <xs:enumeration value=«PVPH»/> <xs:enumeration value=«PZSU»/> </xs:restriction>
</xs:simpleType> <xs:simpleType name=«tDomainLNGroupREnum»> <xs:restriction base=«xs:Name»> <xs:pattern value=«R[A-Z]„/> <xs:enumeration value=“RSYN»/> <xs:enumeration value=«RDRE»/> <xs:enumeration value=«RADR»/> <xs:enumeration value=«RBDR»/> <xs:enumeration value=«RDRS»/> <xs:enumeration value=«RBRF»/> <xs:enumeration value=«RDIR»/> <xs:enumeration value=«RFLO»/> <xs:enumeration value=«RPSB»/> <xs:enumeration value=«RREC»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tDomainLNGroupSEnum»> <xs:restriction base=«xs:Name»> <xs:pattern value=«S[A-Z]„/> <xs:enumeration value=“SARC»/> <xs:enumeration value=«SIMG»/> <xs:enumeration value=«SIML»/> <xs:enumeration value=«SPDC»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tDomainLNGroupTEnum»> <xs:restriction base=«xs:Name»>
<xs:pattern value=«T[A-Z]„/> <xs:enumeration value=“TCTR»/> <xs:enumeration value=«TVTR»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tDomainLNGroupXEnum»> <xs:restriction base=«xs:Name»> <xs:pattern value=«X[A-Z]„/> <xs:enumeration value=“XCBR»/> <xs:enumeration value=«XSWI»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tDomainLNGroupYEnum»> <xs:restriction base=«xs:Name»> <xs:pattern value=«Y[A-Z]„/> <xs:enumeration value=“YPTR»/> <xs:enumeration value=«YEFN»/> <xs:enumeration value=«YLTC»/> <xs:enumeration value=«YPSH»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tDomainLNGroupZEnum»> <xs:restriction base=«xs:Name»> <xs:pattern value=«Z[A-Z]„/> <xs:enumeration value=“ZAXN»/> <xs:enumeration value=«ZBAT»/> <xs:enumeration value=«ZBSH»/>
<xs:enumeration value=«ZCAB»/> <xs:enumeration value=«ZCAP»/> <xs:enumeration value=«ZCON»/> <xs:enumeration value=«ZGEN»/> <xs:enumeration value=«ZGIL»/> <xs:enumeration value=«ZLIN»/> <xs:enumeration value=«ZMOT»/> <xs:enumeration value=«ZREA»/> <xs:enumeration value=«ZRRC»/> <xs:enumeration value=«ZSAR»/> <xs:enumeration value=«ZTCF»/> <xs:enumeration value=«ZTCR»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tDomainLNEnum»> <xs:union memberTypes=«tDomainLNGroupAEnum tDomainLNGroupCEnum tDomainLNGroupGEnum tDomainLNGrouplEnum tDomainLNGroupMEnum tDomainLNGroupPEnum tDomainLNGroupREnum tDomainLNGroupSEnum tDomainLNGroupTEnum tDomainLNGroupXEnum tDomainLNGroupYEnum tDomainLNGroupZEnum»/> </xs:simpleType> <xs:simpleType name=«tPredefinedLNClassEnum»> <xs:union memberTypes=«tLPHDEnum tLLN0Enum tDomainLNEnum»/> </xs:simpleType> <xs:simpleType name=«tExtensionLNClassEnum»> <xs:restriction base=«xs:Name»> <xs:minLength value=«1»/>
<xs:pattern value=«\p{Lu}+»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tLNClassEnum»> <xs:union memberTypes=«tPredefinedLNClassEnum tExtensionLNClassEnum»/> </xs:simpleType> <xs:simpleType name=«tPredefinedCDCEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«SPS»/> <xs:enumeration value=«DPS»/> <xs:enumeration value=«INS»/> <xs:enumeration value=«ACT»/> <xs:enumeration value=«ACD»/> <xs:enumeration value=«SEC»/> <xs:enumeration value=«BCR»/> <xs:enumeration value=«MV»/> <xs:enumeration value=«CMV»/> <xs:enumeration value=«SAV»/> <xs:enumeration value=«WYE»/> <xs:enumeration value=«DEL»/> <xs:enumeration value=«SEQ»/> <xs:enumeration value=«HMV»/> <xs:enumeration value=«HWYE»/> <xs:enumeration value=«HDEL»/> <xs:enumeration value=«SPC»/> <xs:enumeration value=«DPC»/> <xs:enumeration value=«INC»/>
<xs:enumeration value=«BSC»/> <xs:enumeration value=«ISC»/> <xs:enumeration value=«APC»/> <xs:enumeration value=«SPG»/> <xs:enumeration value=«ING»/> <xs:enumeration value=«ASG»/> <xs:enumeration value=«CURVE»/> <xs:enumeration value=«DPL»/> <xs:enumeration value=«LPL»/> <xs:enumeration value=«CSD»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tExtensionCDCEnum»> <xs:restriction base=«xs:Name»> <xs:minLength value=«1»/> <xs:pattern value=«\p{Lu}+»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tCDCEnum»> <xs:union memberTypes=«tPredefinedCDCEnum tExtensionCDCEnum»/> </xs:simpleType> <xs:simpleType name=«tTrgOptEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«dchg»/> <xs:enumeration value=«qchg»/> <xs:enumeration value=«dupd»/> <xs:enumeration value=«none»/>
</xs:restriction> </xs:simpleType> <xs:simpleType name=«tTrgOptControlEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«dchg»/> <xs:enumeration value=«qchg»/> <xs:enumeration value=«dupd»/> <xs:enumeration value=«period»/> <xs:enumeration value=«none»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tFCEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«ST»/> <xs:enumeration value=«MX»/> <xs:enumeration value=«CO»/> <xs:enumeration value=«SP»/> <xs:enumeration value=«SG»/> <xs:enumeration value=«SE»/> <xs:enumeration value=«SV»/> <xs:enumeration value=«CF»/> <xs:enumeration value=«DC»/> <xs:enumeration value=«EX»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tPredefinedBasicTypeEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«BOOLEAN»/>
<xs:enumeration value=«INT8»/> <xs:enumeration value=«INT16»/> <xs:enumeration value=«INT24»/> <xs:enumeration value=«INT32»/> <xs:enumeration value=«INT128»/> <xs:enumeration value=«INT8U»/> <xs:enumeration value=«INT16U»/> <xs:enumeration value=«INT24U»/> <xs:enumeration value=«INT32U»/> <xs:enumeration value=«FLOAT32»/> <xs:enumeration value=«FLOAT64»/> <xs:enumeration value=«Enum»/> <xs:enumeration value=«Dbpos»/> <xs:enumeration value=«Tcmd»/> <xs:enumeration value=«Quality»/> <xs:enumeration value=«Timestamp»/> <xs:enumeration value=«VisString32»/> <xs:enumeration value=«VisString64»/> <xs:enumeration value=«VisString255»/> <xs:enumeration value=«Octet64»/> <xs:enumeration value=«Struct»/> <xs:enumeration value=«EntryTime»/> <xs:enumeration value=«Unicode255»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tExtensionBasicTypeEnum»> <xs:restriction base=«xs:Name»>
<xs:pattern value=«\p{Lu}[\p{L},\d]*»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tBasicTypeEnum»> <xs:union memberTypes=«tPredefinedBasicTypeEnum tExtensionBasicTypeEnum»/> </xs:simpleType> <xs:simpleType name=«tValKindEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«Spec»/> <xs:enumeration value=«Conf»/> <xs:enumeration value=«RO»/> <xs:enumeration value=«Set»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tGSEControlTypeEnum»> <xs:restriction base=«xs:Name»> <xs:enumeration value=«GSSE»/> <xs:enumeration value=«GOOSE»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tSIUnitEnum»> <xs:restriction base=«xs:token»> <xs:enumeration value=«none»/> <xs:enumeration value=«m»/> <xs:enumeration value=«kg»/> <xs:enumeration value=«s»/> <xs:enumeration value=«A»/>
<xs:enumeration value=«K»/> <xs:enumeration value=«mol»/> <xs:enumeration value=«cd»/> <xs:enumeration value=«deg»/> <xs:enumeration value=«rad»/> <xs:enumeration value=«sr»/> <xs:enumeration value=«Gy»/> <xs:enumeration value=«q»/> <xs:enumeration value=«°C»/> <xs:enumeration value=«Sv»/> <xs:enumeration value=«F»/> <xs:enumeration value=«C»/> <xs:enumeration value=«S»/> <xs:enumeration value=«H»/> <xs:enumeration value=«V»/> <xs:enumeration value=«ohm»/> <xs:enumeration value=«J»/> <xs:enumeration value=«N»/> <xs:enumeration value=«Hz»/> <xs:enumeration value=«Ix»/> <xs:enumeration value=«Lm»/> <xs:enumeration value=«Wb»/> <xs:enumeration value=«T»/> <xs:enumeration value=«W»/> <xs:enumeration value=«Pa»/> <xs:enumeration value=«m^2»/> <xs:enumeration value=«m^3»/>
<xs:enumeration value=«m/s»/> <xs:enumeration value=«m/s^2»/> <xs:enumeration value=«m^3/s»/> <xs:enumeration value=«m/m^3»/> <xs:enumeration value=«M»/> <xs:enumeration value=«kg/m^3»/> <xs:enumeration value=«m^2/s»/> <xs:enumeration value=«W/m K»/> <xs:enumeration value=«J/K»/> <xs:enumeration value=«ppm»/> <xs:enumeration value=«s^-1»/> <xs:enumeration value=«rad/s»/> <xs:enumeration value=«VA»/> <xs:enumeration value=«VAr»/> <xs:enumeration value=«theta»/> <xs:enumeration value=«cos_theta»/> <xs:enumeration value=«Vs»/> <xs:enumeration value=«V^2»/> <xs:enumeration value=«As»/> <xs:enumeration value=«A^2»/> <xs:enumeration value=«A^2 s»/> <xs:enumeration value=«VAh»/> <xs:enumeration value=«Wh»/> <xs:enumeration value=«VArh»/> <xs:enumeration value=«V/Hz»/> <xs:enumeration value=«b/s»/> </xs:restriction>
</xs:simpleType> <xs:simpleType name=«tUnitMultiplierEnum»> <xs:restriction base=«xs:normalizedString»> <xs:enumeration value=«»/> <xs:enumeration value=«m»/> <xs:enumeration value=«k»/> <xs:enumeration value=«M»/> <xs:enumeration value=«mu»/> <xs:enumeration value=«y»/> <xs:enumeration value=«z»/> <xs:enumeration value=«a»/> <xs:enumeration value=«f»/> <xs:enumeration value=«p»/> <xs:enumeration value=«n»/> <xs:enumeration value=«c»/> <xs:enumeration value=«d»/> <xs:enumeration value=«da»/> <xs:enumeration value=«h»/> <xs:enumeration value=«G»/> <xs:enumeration value=«T»/> <xs:enumeration value=«P»/> <xs:enumeration value=«E»/> <xs:enumeration value=«Z»/> <xs:enumeration value=«Y»/> </xs:restriction> </xs:simpleType> </xs:schema>

Файл SCL_BaseTypes.xsd

<xs:schema targetNamespace=«http://www.iec.ch/61850/2003/SCL» xmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:scl=«http://www.iec.ch/61850/2003/SCL» elementFormDefault=«qualified» attributeFormDefault=«unqualified» version=«1.0»> xs:annotation <xs:documentation xml:lang=«en»>COPYRIGHT IEC, 2003. Version 1.0. Release 2003/09/19. (Uncommented)</xs:documentation> </xs:annotation> <xs:include schemaLocation=«SCL_Enums.xsd»/> <xs:attributeGroup name=«agDesc»> <xs:attribute name=«desc» type=«xs:normalizedString» use=«optional»/> </xs:attributeGroup> <xs:complexType name=«tBaseElement» abstract=«true»> xs:sequence <xs:any namespace=«##other» processContents=«lax» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«Text» type=«tText» minOccurs=«0»/> <xs:element name=«Private» type=«tPrivate» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> <xs:anyAttribute namespace=«##other» processContents=«lax»/> </xs:complexType> <xs:complexType name=«tUnNaming» abstract=«true»> xs:complexContent <xs:extension base=«tBaseElement»> <xs:attributeGroup ref=«agDesc»/>
</xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tNaming» abstract=«true»> xs:complexContent <xs:extension base=«tBaseElement»> <xs:attribute name=«name» type=«tName» use=«required»/> <xs:attributeGroup ref=«agDesc»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tIDNaming» abstract=«true»> xs:complexContent <xs:extension base=«tBaseElement»> <xs:attribute name=«id» type=«tName» use=«required»/> <xs:attributeGroup ref=«agDesc»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tAnyContentFromOtherNamespace» abstract=«true» mixed=«true»> xs:annotation <xs:documentation xml:lang=«en»>An element of this type can contain text mixed with elements from another namespace that this target namespace (but they must be defined in a namespace). Attributes from other namespaces than this target namespace are also allowed.</xs:documentation> </xs:annotation>
<xs:sequence minOccurs=«0» maxOccurs=«unbounded»> <xs:any namespace=«##other» processContents=«lax»/> </xs:sequence> <xs:anyAttribute namespace=«##other» processContents=«lax»/> </xs:complexType> <xs:complexType name=«tText» mixed=«true»> xs:annotation <xs:documentation xml:lang=«en»>Allows an unrestricted mixture of character content and element content and attributes from any namespace other than the target namespace. <1> </xs:documentation> </xs:annotation> <xs:complexContent mixed=«true»> <xs:extension base=«tAnyContentFromOtherNamespace»> <xs:attribute name=«source» type=«xs:anyURI» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tPrivate» mixed=«true»> xs:annotation <xs:documentation xml:lang=«en»>Allows an unrestricted mixture of character content and element content and attributes from any namespace other than the target namespace, along with an optional Type attribute. <2> </xs:documentation> </xs:annotation> <xs:complexContent mixed=«true»> <xs:extension base=«tAnyContentFromOtherNamespace»> <xs:attribute name=«type» type=«xs:normalizedString» use=«optional»/> <xs:attribute name=«source» type=«xs:anyURI» use=«optional»/>
</xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tHeader»> xs:sequence <xs:element name=«Text» type=«tText» minOccurs=«0»/> <xs:element name=«History» minOccurs=«0»> xs:complexType xs:sequence <xs:element name=«Hitem» type=«tHitem» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name=«id» type=«xs:normalizedString» use=«required»/> <xs:attribute name=«version» type=«xs:normalizedString»/> <xs:attribute name=«revision» type=«xs:normalizedString»/> <xs:attribute name=«toolID» type=«xs:normalizedString»/> <xs:attribute name=«nameStructure» use=«required»> xs:simpleType <xs:restriction base=«xs:Name»> <xs:enumeration value=«FuncName»/> <xs:enumeration value=«IEDName»/> </xs:restriction> </xs:simpleType> </xs:attribute>
</xs:complexType> <xs:complexType name=«tHitem» mixed=«true»> xs:annotation <xs:documentation xml:lang=«en»>Allows an unrestricted mixture of character content and element content and attributes from any namespace other than the target namespace, along with the 6 following attributes: Version, Revision, When, Who, What, and Why <3> </xs:documentation> </xs:annotation> <xs:complexContent mixed=«true»> <xs:extension base=«tAnyContentFromOtherNamespace»> <xs:attribute name=«version» type=«xs:normalizedString» use=«required»/> <xs:attribute name=«revision» type=«xs:normalizedString» use=«required»/> <xs:attribute name=«when» type=«xs:normalizedString» use=«required»/> <xs:attribute name=«who» type=«xs:normalizedString»/> <xs:attribute name=«what» type=«xs:normalizedString»/> <xs:attribute name=«why» type=«xs:normalizedString»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tVal»> xs:simpleContent <xs:extension base=«xs:normalizedString»> <xs:attribute name=«sGroup» type=«xs:unsignedInt» use=«optional»/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tValueWithUnit»>
xs:simpleContent <xs:extension base=«xs:decimal»> <xs:attribute name=«unit» type=«tSIUnitEnum» use=«required»/> <xs:attribute name=«multiplier» type=«tUnitMultiplierEnum» use=«optional»/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tVoltage»> xs:simpleContent <xs:restriction base=«tValueWithUnit»> <xs:attribute name=«unit» type=«tSIUnitEnum» use=«required» fixed=«V»/> <xs:attribute name=«multiplier» type=«tUnitMultiplierEnum» use=«optional»/> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tBitRateInMbPerSec»> xs:simpleContent <xs:restriction base=«tValueWithUnit»> <xs:attribute name=«unit» type=«tSIUnitEnum» use=«required» fixed=«b/s»/> <xs:attribute name=«multiplier» type=«tUnitMultiplierEnum» fixed=«M»/> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tDurationInSec»> xs:simpleContent
<xs:restriction base=«tValueWithUnit»> <xs:attribute name=«unit» type=«tSIUnitEnum» use=«required» fixed=«s»/> <xs:attribute name=«multiplier» type=«tUnitMultiplierEnum» use=«optional»/> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tDurationInMilliSec»> xs:simpleContent <xs:restriction base=«tValueWithUnit»> <xs:attribute name=«unit» type=«tSIUnitEnum» use=«required» fixed=«s»/> <xs:attribute name=«multiplier» type=«tUnitMultiplierEnum» fixed=«m»/> </xs:restriction> </xs:simpleContent> </xs:complexType> </xs:schema>

---

<1> Допускается неограниченное смешивание содержания символа, содержания элемента и атрибутов любого пространства имен, кроме целевого пространства имен.

<2> Допускается неограниченное смешивание содержания символа, содержания элемента и атрибутов любого пространства имен, кроме целевого пространства имен, наряду с дополнительным атрибутом типа.

<3> Допускается неограниченное смешивание содержания символа, содержания элемента и атрибутов любого пространства имен, кроме целевого пространства имен, наряду со следующими атрибутами: Version, Revision, When, Who, What, Why.

A.2 Синтаксис Substation

Файл SCL_Substation. xsd

<xs:schema targetNamespace=«http://www.iec.ch/61850/2003/SCL» xmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:scl=«http://www.iec.ch/61850/2003/SCL» elementFormDefault=«qualified» attributeFormDefault=«unqualified» version=«1.0»> xs:annotation <xs:documentation xml:lang=«en»>COPYRIGHT IEC, 2003. Version 1.0. Release 2003/09/19. (Uncommented)</xs:documentation> </xs:annotation> <xs:include schemaLocation=«SCL_BaseTypes.xsd»/> <xs:attributeGroup name=«agVirtual»> <xs:attribute name=«virtual» type=«xs:boolean» use=«optional» default=«false»/> </xs:attributeGroup> <xs:complexType name=«tLNodeContainer» abstract=«true»> xs:complexContent <xs:extension base=«tNaming»> xs:sequence <xs:element name=«LNode» type=«tLNode» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tPowerSystemResource» abstract=«true»> xs:complexContent <xs:extension base=«tLNodeContainer»/> </xs:complexContent>
</xs:complexType> <xs:complexType name=«tEquipmentContainer» abstract=«true»> xs:complexContent <xs:extension base=«tPowerSystemResource»> xs:sequence <xs:element name=«PowerTransformer» type=«tPowerTransformer» minOccurs=«0» maxOccurs=«unbounded»> <xs:unique name=«uniqueWindingInPowerTransformer»> <xs:selector xpath=»./scl:TransformerWinding«/> <xs:field xpath=»@name«/> </xs:unique> </xs:element> <xs:element name=»GeneralEquipment» type=«tGeneralEquipment» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tEquipment» abstract=«true»> xs:complexContent <xs:extension base=«tPowerSystemResource»> <xs:attributeGroup ref=«agVirtual»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tAbstractConductingEquipment» abstract=«true»> xs:complexContent
<xs:extension base=«tEquipment»> xs:sequence <xs:element name=«Terminal» type=«tTerminal» minOccurs=«0» maxOccurs=«2»/> <xs:element name=«SubEquipment» type=«tSubEquipment» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tConductingEquipment»> xs:complexContent <xs:extension base=«tAbstractConductingEquipment»> <xs:attribute name=«type» type=«tCommonConductingEquipmentEnum» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tSubEquipment»> xs:complexContent <xs:extension base=«tPowerSystemResource»> <xs:attribute name=«phase» type=«tPhaseEnum» use=«optional» default=«none»/> <xs:attributeGroup ref=«agVirtual»/> </xs:extension> </xs:complexContent> </xs:complexType>
<xs:complexType name=«tPowerTransformer»> xs:complexContent <xs:extension base=«tEquipment»> xs:sequence <xs:element name=«TransformerWinding» type=«tTransformerWinding» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«type» type=«tPowerTransformerEnum» use=«required» fixed=«PTR»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tTransformerWinding»> xs:complexContent <xs:extension base=«tAbstractConductingEquipment»> xs:sequence <xs:element name=«TapChanger» type=«tTapChanger» minOccurs=«0»/> </xs:sequence> <xs:attribute name=«type» type=«tTransformerWindingEnum» use=«required» fixed=«PTW»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tTapChanger»> xs:complexContent <xs:extension base=«tPowerSystemResource»>
<xs:attribute name=«type» type=«xs:Name» use=«required» fixed=«LTC»/> <xs:attributeGroup ref=«agVirtual»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tGeneralEquipment»> xs:complexContent <xs:extension base=«tEquipment»> <xs:attribute name=«type» type=«tGeneralEquipmentEnum» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tSubstation»> xs:complexContent <xs:extension base=«tEquipmentContainer»> xs:sequence <xs:element name=«VoltageLevel» type=«tVoltageLevel» maxOccurs=«unbounded»> <xs:unique name=«uniqueBayInVoltageLevel»> <xs:selector xpath=»./scl:Bay«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniquePowerTransformerInVoltageLevel«> <xs:selector xpath=»./scl:PowerTransformer«/> <xs:field xpath=»@name«/>»
</xs:unique> <xs:unique name=«uniqueGeneralEquipmentInVoltageLevel»> <xs:selector xpath=»./scl:GeneralEquipment«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueChildNameInVoltageLevel«> <xs:selector xpath=»./*«/> <xs:field xpath=»@name«/> </xs:unique> </xs:element> <xs:element name=»Function» type=«tFunction» minOccurs=«0» maxOccurs=«unbounded»> <xs:unique name=«uniqueSubFunctionInFunction»> <xs:selector xpath=»./scl:SubFunction«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueGeneralEquipmentInFunction«> <xs:selector xpath=»./scl:GeneralEquipment«/> <xs:field xpath=»@name«/> </xs:unique> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=»tVoltageLevel«> xs:complexContent»
<xs:extension base=«tEquipmentContainer»> xs:sequence <xs:element name=«Voltage» type=«tVoltage» minOccurs=«0»/> <xs:element name=«Bay» type=«tBay» maxOccurs=«unbounded»> <xs:unique name=«uniquePowerTransformerInBay»> <xs:selector xpath=»./scl:PowerTransformer«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueConductingEquipmentInBay«> <xs:selector xpath=»./scl:ConductingEquipment«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueGeneralEquipmentInBay«> <xs:selector xpath=»./scl:GeneralEquipment«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueChildNameInBay«> <xs:selector xpath=»./*«/> <xs:field xpath=»@name«/> </xs:unique> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=»tBay«> xs:complexContent»
<xs:extension base=«tEquipmentContainer»> xs:sequence <xs:element name=«ConductingEquipment» type=«tConductingEquipment» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«ConnectivityNode» type=«tConnectivityNode» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tLNode»> xs:complexContent <xs:extension base=«tUnNaming»> <xs:attribute name=«InInst» type=«tAnyName» use=«optional»/> <xs:attribute name=«InClass» type=«tLNClassEnum» use=«required»/> <xs:attribute name=«iedName» type=«tName» use=«optional» default=«None»/> <xs:attribute name=«IdInst» type=«tAnyName» use=«optional»/> <xs:attribute name=«prefix» type=«tAnyName» use=«optional»/> <xs:attribute name=«InType» type=«tName» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tFunction»> xs:complexContent <xs:extension base=«tPowerSystemResource»> xs:sequence
<xs:element name=«SubFunction» type=«tSubFunction» minOccurs=«0» maxOccurs=«unbounded»> <xs:unique name=«uniqueGeneralEquipmentInSubFunction»> <xs:selector xpath=»./scl:GeneralEquipment«/> <xs:field xpath=»@name«/> </xs:unique> </xs:element> <xs:element name=»GeneralEquipment» type=«tGeneralEquipment» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tSubFunction»> xs:complexContent <xs:extension base=«tPowerSystemResource»> xs:sequence <xs:element name=«GeneralEquipment» type=«tGeneralEquipment» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tConnectivityNode»> xs:complexContent <xs:extension base=«tLNodeContainer»> <xs:attribute name=«pathName» type=«tRef» use=«required»/>
</xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tTerminal»> xs:complexContent <xs:extension base=«tUnNaming»> <xs:attribute name=«name» type=«tAnyName» use=«optional»/> <xs:attribute name=«connectivityNode» type=«tRef» use=«required»/> <xs:attribute name=«substationName» type=«tName» use=«required»/> <xs:attribute name=«voltageLevelName» type=«tName» use=«required»/> <xs:attribute name=«bayName» type-«tName» use=«required»/> <xs:attribute name=«cNodeName» type=«tName» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name=«Substation» type=«tSubstation»> <xs:unique name=«uniqueVoltageLevelInSubstation»> <xs:selector xpath=»./scl:VoltageLevel«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniquePowerTranformerInSubstation«> <xs:selector xpath=»./scl:PowerTransformer«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueGeneralEquipmentInSubstation«> <xs:selector xpath=»./scl:GeneralEquipment«/> <xs:field xpath=»@name«/>»
</xs:unique> <xs:unique name=«uniqueFunctionInSubstation»> <xs:selector xpath=»./scl:Function«/> <xs:field xpath=»@name«/> </xs:unique> <xs:key name=»ConnectivityNodeKey«> <xs:selector xpath=».//scl:ConnectivityNode«/> <xs:field xpath=»@pathName«/> </xs:key> <xs:unique name=»uniqueLNode«> <xs:selector xpath=».//scl:LNode«/> <xs:field xpath=»@InInst«/> <xs:field xpath=»@InClass«/> <xs:field xpath=»@iedName«/> <xs:field xpath=»@IdInst«/> <xs:field xpath=»@prefix«/> </xs:unique> <xs:unique name=»uniqueChildNameInSubstation«> <xs:selector xpath=»./*«/> <xs:field xpath=»@name«/> </xs:unique> <!-- Должно быть снято ограничение тождественности, так как имеется проблема (согласно тексту в части 6) в отношении предопределенного заземленного узла связи. Если вывод обращается к этому узлу, который, естественно, не определен явным образом в файле SCL, верификация будет неуспешной. <xs:keyref name=»ref2ConnectivityNode» refer=«ConnectivityNodeKey»>
<xs:selector xpath=».//scl:Terminal«/> xs:fieldxpath=»@connectivityNode«/ </xs:keyref> --> </xs:element> </xs:schema>»

A.3 Шаблоны типа данных

<xs:schema targetNamespace=«http://www.iec.ch/61850/2003/SCL» xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns:scl=«http://www.iec.ch/61850/2003/SCL» elementFormDefault=«qualified» attributeFormDefault=«unqualified» version=«1.0»> xs:annotation <xs:documentation xml:lang=«en»>COPYRIGHT IEC, 2003. Version 1.0. Release 2003/09/19. (Uncommented)</xs:documentation> </xs:annotation> <xs:include schemaLocation=«SCL_BaseTypes.xsd»/> <xs:attributeGroup name=«agDATrgOp»> <xs:attribute name=«dchg» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«qchg» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«dupd» type=«xs:boolean» use=«optional» default=«false»/> </xs:attributeGroup> <xs:complexType name=«tAbstractDataAttribute» abstract=«true»> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«Val» type=«tVal» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«name» type=«tAttributeNameEnum» use=«required»/> <xs:attribute name=«sAddr» type=«xs:normalizedString» use=«optional»/> <xs:attribute name=«bType» type=«tBasicTypeEnum» use=«required»/>
<xs:attribute name=«valKind» type=«tValKindEnum» use=«optional» default=«Set»/> <xs:attribute name=«type» type=«tAnyName» use=«optional»/> <xs:attribute name=«count» type=«xs:unsignedInt» use=«optional» default=«0»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tLNodeType»> xs:complexContent <xs:extension base=«tIDNaming»> xs:sequence <xs:element name=«DO» type=«tDO» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«iedType» type=«tAnyName» use=«optional»/> <xs:attribute name=«InClass» type=«tLNClassEnum» use=«required»/> </xs:extension» </xs:complexContent> </xs:complexType> <xs:complexType name=«tDO»> xs:complexContent <xs:extension base=«tUnNaming»> <xs:attribute name=«name» type=«tRestrName1stU» use=«required»/> <xs:attribute name=«type» type=«tName» use=«required»/> <xs:attribute name=«accessControl» type=«xs:normalizedString» use=«optional»/>
<xs:attribute name=«transient» type=«xs:boolean» use=«optional» default=«false»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tDOType»> xs:complexContent <xs:extension base=«tIDNaming»> <xs:choice minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«SDO» type=«tSDO»/> <xs:element name=«DA» type=«tDA»/> </xs:choice> <xs:attribute name=«iedType» type=«tAnyName» use=«optional»/> <xs:attribute name=«cdc» type=«tCDCEnum» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tSDO»> xs:complexContent <xs:extension base=«tNaming»> <xs:attribute name=«type» type=«tName» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tDA»> xs:complexContent <xs:extension base=«tAbstractDataAttribute»> <xs:attributeGroup ref=«agDATrgOp»/>
<xs:attribute name=«fc» type=«tFCEnum» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tDAType»> xs:complexContent <xs:extension base=«tIDNaming»> xs:sequence <xs:element name=«BDA» type=«tBDA» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«iedType» type=«tAnyName» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tBDA»> xs:complexContent <xs:extension base=«tAbstractDataAttribute»/> </xs:complexContent> </xs:complexType> <xs:complexType name=«tEnumType»> xs:complexContent <xs:extension base=«tIDNaming»> xs:sequence <xs:element name=«EnumVal» type=«tEnumVal» maxOccurs=«unbounded»/> </xs:sequence>
</xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tEnumVal»> xs:simpleContent <xs:extension base=«xs:normalizedString»> <xs:attribute name=«ord» type=«xs:integer» use=«required»/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tDataTypeTemplates»> xs:sequence <xs:element name=«LNodeType» type=«tLNodeType» maxOccurs=«unbounded»> <xs:unique name=«uniqueDOInLNodeType»> <xs:selector xpath=«scl:DO»/> <xs:field xpath=«@name»/> </xs:unique> </xs:element> <xs:element name=«DOType» type=«tDOType» maxOccurs=«unbounded»> <xs:unique name=«uniqueDAorSDOInLDOType»> <xs:selector xpath=»./*«/> <xs:field xpath=»@name«/> </xs:unique> </xs:element> <xs:element name=»DAType» type=«tDAType» minOccurs=«0» maxOccurs=«unbounded»> <xs:unique name=«uniqueBDAInLDAType»>
<xs:selector xpath=«scl:BDA»/> <xs:field xpath=«@name»/> </xs:unique> </xs:element> <xs:element name=«EnumType» type=«tEnumType» minOccurs=«0» maxOccurs=«unbounded»> <xs:unique name=«uniqueOrdInEnumType»> <xs:selector xpath=«scl:EnumVal»/> <xs:field xpath=«@ord»/> </xs:unique> </xs:element> </xs:sequence> </xs:complexType> <xs:element name=«DataTypeTemplates» type=«tDataTypeTemplates»> <xs:unique name=«uniqueLNodeType»> <xs:selector xpath=«scl:LNodeType»/> <xs:field xpath=«@id»/> <xs:field xpath=«@iedType»/> </xs:unique> <xs:key name=«DOTypeKey»> <xs:selector xpath=«scl:DOType»/> <xs:field xpath=«@id»/> </xs:key> <xs:keyref name=«ref2DOType» refer=«DOTypeKey»> <xs:selector xpath=«scl:LNodeType/scl:DO»/> <xs:field xpath=«@type»/> </xs:keyref>
<xs:keyref name=«ref2DOTypeForSDO» refer=«DOTypeKey»> <xs:selector xpath=«scl:DOType/scl:SDO»/> <xs:field xpath=«@type»/> </xs:keyref> <xs:key name=«DATypeKey»> <xs:selector xpath=«scl:DAType»/> <xs:field xpath=«@id»/> </xs:key> <xs:key name=«EnumTypeKey»> <xs:selector xpath=«scl:EnumType»/> <xs:field xpath=«@id»/> </xs:key> </xs:element> </xs:schema>

A.4 Возможности и структура IED-устройства

Файл SCL_IED.xsd

<xs:schema targetNamespace=«http://www.iec.ch/61850/2003/SCL» xmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:scl=«http://www.iec.ch/61850/2003/SCL» elementFormDefault=«qualified» attributeFormDefault=«unqualified» version=«1.0»> xs:annotation <xs:documentation xml:lang=«en»>COPYRIGHT IEC, 2003. Version 1.0. Release 2003/09/19</xs:documentation> </xs:annotation> <xs:include schemaLocation=«SCL_BaseTypes.xsd»/> <xs:attributeGroup name=«agAuthentication»> <xs:attribute name=«none» type=«xs:boolean» use=«optional» default=«true»/> <xs:attribute name=«password» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«weak» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«strong» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«certificate» type=«xs:boolean» use=«optional» default=«false»/> </xs:attributeGroup> <xs:attributeGroup name=«agSmvOpts»> <xs:attribute name=«refreshTime» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«sampleSynchronized» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«sampleRate» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«security» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«dataRef» type=«xs:boolean» use=«optional» default=«false»/> </xs:attributeGroup> <xs:attributeGroup name=«agOptFields»>
<xs:attribute name=«seqNum» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«timeStamp» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«dataSet» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«reasonCode» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«dataRef» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«bufOvfl» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«entryID» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«configRef» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«segmentation» type=«xs:boolean» use=«optional» default=«false»/> </xs:attributeGroup> <xs:attributeGroup name=«agLDRef»> <xs:attribute name=«iedName» type=«tName» use=«required»/> <xs:attribute name=«IdInst» type=«tName» use=«required»/> </xs:attributeGroup> <xs:attributeGroup name=«agLNRef»> <xs:attributeGroup ref=«agLDRef»/> <xs:attribute name=«prefix» type=«tAnyName» use=«optional»/> <xs:attribute name=«InClass» type=«tLNClassEnum» use=«required»/> <xs:attribute name=«InInst» type=«tAnyName» use=«required»/> </xs:attributeGroup> <xs:attributeGroup name=«agDORef»> <xs:attributeGroup ref=«agLNRef»/> <xs:attribute name=«doName» type=«tName» use=«required»/> </xs:attributeGroup> <xs:attributeGroup name=«agDARef»> <xs:attributeGroup ref=«agDORef»/> <xs:attribute name=«daName» type=«tName» use=«optional»/> <xs:attribute name=«fc» type=«tFCEnum» use=«optional»/>
</xs:attributeGroup> <xs:complexType name=«tIED»> xs:complexContent <xs:extension base=«tNaming»> xs:sequence <xs:element name=«Services» type=«tServices» minOccurs=«0»/> <xs:element name=«AccessPoint» type=«tAccessPoint» maxOccurs=«unbounded»> <xs:unique name=«uniqueLNInAccessPoint»> <xs:selector xpath=»./scl:LN«/> <xs:field xpath=»@inst«/> <xs:field xpath=»@InClass«/> <xs:field xpath=»@prefix«/> </xs:unique> </xs:element> </xs:sequence> <xs:attribute name=»type» type=«xs:normalizedString» use=«optional»/> <xs:attribute name=«manufacturer» type=«xs:normalizedString» use=«optional»/> <xs:attribute name=«configVersion» type=«xs:normalizedString» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tServices»> xs:all <xs:element name=«DynAssociation» type=«tServiceYesNo» minOccurs=«0»/>
<xs:element name=«SettingGroups» minOccurs=«0»> xs:complexType xs:all <xs:element name=«SGEdit» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«ConfSG» type=«tServiceYesNo» minOccurs=«0»/> </xs:all> </xs:complexType> </xs:element> <xs:element name=«GetDirectory» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«GetDataObjectDefinition» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«DataObjectDirectory» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«GetDataSetValue» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«SetDataSetValue» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«DataSetDirectory» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«ConfDataSet» type=«tServiceWithMaxAndMaxAttributes» minOccurs=«0»/> <xs:element name=«DynDataSet» type=«tServiceWithMaxAndMaxAttributes» minOccurs=«0»/> <xs:element name=«ReadWrite» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«TimerActivatedControl» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«ConfReportControl» type=«tServiceWithMax» minOccurs=«0»/> <xs:element name=«GetCBValues» type=«tServiceYesNo» minOccurs=«0»/>
<xs:element name=«ConfLogControl» type=«tServiceWithMax» minOccurs=«0»/> <xs:element name=«ReportSettings» type=«tReportSettings» minOccurs=«0»/> <xs:element name=«LogSettings» type=«tLogSettings» minOccurs=«0»/> <xs:element name=«GSESettings» type=«tGSESettings» minOccurs=«0»/> <xs:element name=«SMVSettings» type=«tSMVSettings» minOccurs=«0»/> <xs:element name=«GSEDir» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«GOOSE» type=«tServiceWithMax» minOccurs=«0»/> <xs:element name=«GSSE» type=«tServiceWithMax» minOccurs=«0»/> <xs:element name=«FileHandling» type=«tServiceYesNo» minOccurs=«0»/> <xs:element name=«ConfLNs» type=«tConfLNs» minOccurs=«0»/> </xs:all> </xs:complexType> <xs:complexType name=«tAccessPoint»> xs:complexContent <xs:extension base=«tNaming»> <xs:choice minOccurs=«0»> <xs:element name=«Server» type=«tServer»> <xs:unique name=«uniqueAssociationInServer»> <xs:selector xpath=»./scl:Association«/> <xs:field xpath=»@associationID«/> </xs:unique> </xs:element> <xs:element ref=»LN» maxOccurs=«unbounded»/> </xs:choice> <xs:attribute name=«router» type=«xs:boolean» use=«optional» default=«false»/>
<xs:attribute name=«clock» type=«xs:boolean» use=«optional» default=«false»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tServer»> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«Authentication»> xs:complexType <xs:attributeGroup ref=«agAuthentication»/> </xs:complexType> </xs:element> <xs:element name=«LDevice» type=«tLDevice» maxOccurs=«unbounded»> <xs:unique name=«uniqueLNInLDevice»> <xs:selector xpath=»./scl:LN«/> <xs:field xpath=»@inst«/> <xs:field xpath=»@InClass«/> <xs:field xpath=»@prefix«/> </xs:unique> </xs:element> <xs:element name=»Association» type=«tAssociation» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence>
<xs:attribute name=«timeout» type=«xs:unsignedInt» use=«optional» default=«30»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tLDevice»> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element ref=«LN0»/> <xs:element ref=«LN» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«AccessControl» type=«tAccessControl» minOccurs=«0»/> </xs:sequence> <xs:attribute name=«inst» type=«tName» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tAccessControl» mixed=«true»> <xs:complexContent mixed=«true»> <xs:extension base=«tAnyContentFromOtherNamespace»/> </xs:complexContent> </xs:complexType> <xs:complexType name=«tAssociation»> <xs:attribute name=«kind» type=«tAssociationKindEnum» use=«required»/> <xs:attribute name=«associationID» type=«tName» use=«optional»/> <xs:attributeGroup ref=«agLNRef»/>
</xs:complexType> <xs:element name=«LN0»> xs:complexType xs:complexContent <xs:extension base=«tLN0»/> </xs:complexContent> </xs:complexType> <xs:unique name=«uniqueReportControlInLN0»> <xs:selector xpath=»./scl:ReportControl«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueLogControlInLN0«> <xs:selector xpath=»./scl:LogControl«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueGSEControlInLN0«> <xs:selector xpath=»./scl:GSEControl«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueSampledValueControlInLN0«> <xs:selector xpath=»./scl:SampledValueControl«/> <xs:field xpath=»@name«/> </xs:unique> <xs:key name=»DataSetKeyLN0«> <xs:selector xpath=»./scl:DataSet«/> <xs:field xpath=»@name«/> </xs:key>»
<xs:keyref name=«ref2DataSetReportLN0» refer=«DataSetKeyLN0»> <xs:selector xpath=»./scl:ReportControl«/> <xs:field xpath=»@datSet«/> </xs:keyref> <xs:keyref name=»ref2DataSetLogLN0» refer=«DataSetKeyLN0»> <xs:selector xpath=»./scl:LogControl«/> <xs:field xpath=»@datSet«/> </xs:keyref> <xs:keyref name=»ref2DataSetGSELN0» refer=«DataSetKeyLN0»> <xs:selector xpath=»./scl:GSEControl«/> <xs:field xpath=»@datSet«/> </xs:keyref> <xs:keyref name=»ref2DataSetSVLN0» refer=«DataSetKeyLN0»> <xs:selector xpath=»./scl:SampledValueControl«/> <xs:field xpath=»@datSet«/> </xs:keyref> </xs:element> <xs:element name=»LN» type=«tLN»> <xs:unique name=«uniqueReportControlInLN»> <xs:selector xpath=»./scl:ReportControl«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueLogControlInLN«> <xs:selector xpath=»./scl:LogControl«/> <xs:field xpath=»@name«/> </xs:unique> <xs:key name=»DataSetKeyInLN«>»
<xs:selector xpath=»./scl:DataSet«/> <xs:field xpath=»@name«/> </xs:key> <xs:keyref name=»ref2DataSetReport» refer=«DataSetKeyInLN»> <xs:selector xpath=»./scl:ReportControl«/> <xs:field xpath=»@datSet«/> </xs:keyref> <xs:keyref name=»ref2DataSetLog» refer=«DataSetKeyInLN»> <xs:selector xpath=»./scl:LogControl«/> <xs:field xpath=»@datSet«/> </xs:keyref> </xs:element> <xs:complexType name=»tAnyLN» abstract=«true»> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«DataSet» type=«tDataSet» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«ReportControl» type=«tReportControl» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«LogControl» type=«tLogControl» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«DOI» type=«tDOI» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«Inputs» type=«tInputs» minOccurs=«0»/> </xs:sequence> <xs:attribute name=«InType» type=«tName» use=«required»/>
</xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tLN»> xs:complexContent <xs:extension base=«tAnyLN»> <xs:attribute name=«InClass» type=«tLNClassEnum» use=«required»/> <xs:attribute name=«inst» type=«xs:unsignedInt» use=«required»/> <xs:attribute name=«prefix» type=«tAnyName» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tLN0»> xs:complexContent <xs:extension base=«tAnyLN»> xs:sequence <xs:element name=«GSEControl» type=«tGSEControl» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«SampledValueControl» type=«tSampledValueControl» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«SettingControl» type=«tSettingControl» minOccurs=«0»/> <xs:element name=«SCLControl» type=«tSCLControl» minOccurs=«0»/> <xs:element name=«Log» type=«tLog» minOccurs=«0»/> </xs:sequence>
<xs:attribute name=«InClass» type=«tLNClassEnum» use=«required» fixed=«LLN0»/> <xs:attribute name=«inst» type=«xs:normalizedString» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tDataSet»> xs:complexContent <xs:extension base=«tNaming»> xs:sequence <xs:element name=«FCDA» type=«tFCDA» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tFCDA»> <xs:attribute name=«IdInst» type=«tName» use=«optional»/> <xs:attribute name=«prefix» type=«tAnyName» use=«optional»/> <xs:attribute name=«InClass» type=«tLNClassEnum» use=«optional»/> <xs:attribute name=«InInst» type=«tName» use=«optional»/> <xs:attribute name=«doName» type=«tName» use=«optional»/> <xs:attribute name=«daName» type=«tName» use=«optional»/> <xs:attribute name=«fc» type=«tFCEnum» use=«required»/> </xs:complexType> <xs:complexType name=«tControl» abstract=«true»> xs:complexContent
<xs:extension base=«tNaming»> <xs:attribute name=«datSet» type=«tAnyName» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tControlWithTriggerOpt» abstract=«true»> xs:complexContent <xs:extension base=«tControl»> xs:sequence <xs:element name=«TrgOps» type=«tTrgOps» minOccurs=«0»/> </xs:sequence> <xs:attribute name=«intgPd» type=«xs:unsignedInt» use=«optional» default=«0»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tTrgOps»> <xs:attribute name=«dchg» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«qchg» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«dupd» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«period» type=«xs:boolean» use=«optional» default=«false»/> </xs:complexType> <xs:complexType name=«tReportControl»> xs:complexContent <xs:extension base=«tControlWithTriggerOpt»> xs:sequence <xs:element name=«OptFields»>
xs:complexType <xs:attributeGroup ref=«agOptFields»/> </xs:complexType> </xs:element> <xs:element name=«RptEnabled» type=«tRptEnabled» minOccurs=«0»/> </xs:sequence> <xs:attribute name=«rptID» type=«tName» use=«required»/> <xs:attribute name=«confRev» type=«xs:unsignedInt» use=«required»/> <xs:attribute name=«buffered» type=«xs:boolean» use=«optional» default=«false»/> <xs:attribute name=«bufTime» type=«xs:unsignedInt» use=«optional» default=«0»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tRptEnabled»> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«ClientLN» type=«tClientLN» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«max» type=«xs:unsignedInt» use=«optional» default=«1»/> </xs:extension> </xs:complexContent>
</xs:complexType> <xs:complexType name=«tClientLN»> <xs:attributeGroup ref=«agLNRef»/> </xs:complexType> <xs:complexType name=«tLogControl»> xs:complexContent <xs:extension base=«tControlWithTriggerOpt»> <xs:attribute name=«logName» type=«tName» use=«required»/> <xs:attribute name=«logEna» type=«xs:boolean» use=«optional» default=«true»/> <xs:attribute name=«reasonCode» type=«xs:boolean» use=«optional» default=«true»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tInputs»> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«ExtRef» type=«tExtRef» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tExtRef»> <xs:attributeGroup ref=«agDORef»/>
<xs:attribute name=«daName» type=«tName» use=«optional»/> <xs:attribute name=«intAddr» type=«xs:normalizedString» use=«optional»/> </xs:complexType> <xs:complexType name=«tLog» mixed=«true»> <xs:complexContent mixed=«true»> <xs:extension base=«tAnyContentFromOtherNamespace»/> </xs:complexContent> </xs:complexType> <xs:complexType name=«tControlWithIEDName»> xs:complexContent <xs:extension base=«tControl»> xs:sequence <xs:element name=«IEDName» type=«tName» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«confRev» type=«xs:unsignedInt» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tGSEControl»> xs:complexContent <xs:extension base=«tControlWithIEDName»> <xs:attribute name=«type» type=«tGSEControlTypeEnum» use=«optional» default=«GOOSE»/> <xs:attribute name=«appID» type=«xs:normalizedString» use=«required»/> </xs:extension> </xs:complexContent>
</xs:complexType> <xs:complexType name=«tSampIedValueControl»> xs:complexContent <xs:extension base=«tControlWithIEDName»> xs:sequence <xs:element name=«SmvOpts»> xs:complexType <xs:attributeGroup ref=«agSmvOpts»/> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name=«smvID» type=«xs:normalizedString» use=«required»/> <xs:attribute name=«multicast» type=«xs:boolean» default=«true»/> <xs:attribute name=«smpRate» type=«xs:unsignedInt» use=«required»/> <xs:attribute name=«nofASDU» type=«xs:unsignedInt» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tSettingControl»> xs:complexContent <xs:extension base=«tUnNaming»> <xs:attribute name=«numOfSGs» type=«xs:unsignedInt» use=«required»/> <xs:attribute name=«actSG» type=«xs:unsignedInt» use=«optional» default=«1»/> </xs:extension> </xs:complexContent> </xs:complexType>
<xs:complexType name=«tSCLControl»> xs:complexContent <xs:extension base=«tUnNaming»/> </xs:complexContent> </xs:complexType> <xs:complexType name=«tDOI»> xs:complexContent <xs:extension base=«tUnNaming»> <xs:choice minOccurs=«0» maxOccurs=«unbounded» <xs:element name=«SDI» type=«tSDI»/> <xs:element name=«DAI» type=«tDAI»/> </xs:choice> <xs:attribute name=«name» type=«tRestrName1stU» use=«required»/> <xs:attribute name=«ix» type=«xs:unsignedInt» use=«optional»/> <xs:attribute name=«accessControl» type=«xs:normalizedString» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tSDI»> xs:complexContent <xs:extension base=«tUnNaming»> <xs:choice minOccurs=«0» maxOccurs=«unbounded»> <xs:element name=«SDI» type=«tSDI»/> <xs:element name=«DAI» type=«tDAI»/> </xs:choice> <xs:attribute name=«name» type=«tRestrName1stL» use=«required»/>
<xs:attribute name=«ix» type=«xs:unsignedInt» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tDAI»> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«Val» type=«tVal» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«name» type=«tRestrName1stL» use=«required»/> <xs:attribute name=«sAddr» type=«xs:normalizedString» use=«optional»/> <xs:attribute name=«valKind» type=«tValKindEnum» use=«optional» default=«Set»/> <xs:attribute name=«ix» type=«xs:unsignedInt» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tServiceYesNo»/> <xs:complexType name=«tServiceWithMax»> <xs:attribute name=«max» type=«xs:unsignedInt» use=«required»/> </xs:complexType> <xs:complexType name=«tServiceWithMaxAndMaxAttributes»> xs:complexContent <xs:extension base=«tServiceWithMax»>
<xs:attribute name=«maxAttributes» type=«xs:unsignedInt» use=«optional»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tServiceWithMaxAndModify»> xs:complexContent <xs:extension base=«tServiceWithMax»> <xs:attribute name=«modify» type=«xs:boolean» use=«optional» default=«true»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tServiceSettings» abstract=«true»> <xs:attribute name=«cbName» type=«tServiceSettingsEnum» use=«optional» default=«Fix»/> <xs:attribute name=«datSet» type=«tServiceSettingsEnum» use=«optional» default=«Fix»/> </xs:complexType> <xs:complexType name=«tReportSettings»> xs:complexContent <xs:extension base=«tServiceSettings»> <xs:attribute name=«rptID» type=«tServiceSettingsEnum» use=«optional» default=«Fix»/> <xs:attribute name=«optFields» type=«tServiceSettingsEnum» use=«optional» default=«Fix»/>
<xs:attribute name=«bufTime» type=«tServiceSettingsEnum» use=«optional» default=«Fix»/> <xs:attribute name=«trgOps» type=«tServiceSettingsEnum» use=«optional» default=«Fix»/> <xs:attribute name=«intgPd» type=«tServiceSettingsEnum» use=«optional» default=«Fix»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tLogSettings»> xs:complexContent <xs:extension base=«tServiceSettings»> <xs:attribute name=«logEna» type=«tServiceSettingsEnum» use=«optional» default=«Fix»/> <xs:attribute name=«trgOps» type=«tServiceSettingsEnum» use=«optional» default=«Fix»/> <xs:attribute name=«intgPd» type=«tServiceSettingsEnum» use=«optional» default=«Fix»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tGSESettings»> xs:complexContent <xs:extension base=«tServiceSettings»> <xs:attribute name=«appID» type=«tServiceSettingsEnum» use=«optional» default=«Fix»/>
<xs:attribute name=«dataLabel» type=«tServiceSettingsEnum» use=«optional» default=«Fix»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tSMVSettings»> xs:complexContent <xs:extension base=«tServiceSettings»> xs:sequence <xs:element name=«SmpRate» maxOccurs=«unbounded»> xs:simpleType <xs:restriction base=«xs:decimal»> <xs:minInclusive value=«0»/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> <xs:attribute name=«svID» type=«tServiceSettingsEnum» use=«optional» default=«Fix»/> <xs:attribute name=«optFields» type=«tServiceSettingsEnum» use=«optional» default=«Fix»/> <xs:attribute name=«smpRate» type=«tServiceSettingsEnum» use=«optional» default=«Fix»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tConfLNs»>
<xs:attribute name=«fixPrefix» type=«xs: boolean» use=«optional» default=«false»/> <xs:attribute name=«fixLnInst» type=«xs:boolean» use=«optional» default=«false»/> </xs:complexType> <xs:element name=«IED» type=«tIED»> <xs:unique name=«uniqueAccessPointInIED»> <xs:selector xpath=»./scl:AccessPoint«/> <xs:field xpath=»@name«/> </xs:unique> <xs:key name=»LDeviceInIEDKey«> <xs:selector xpath=»./scl:AccessPoint/scl:Server/scl:LDevice«/> <xs:field xpath=»@inst«/> </xs:key> <xs:keyref name=»ref2LDeviceInIED» refer=«LDeviceInIEDKey»> <xs:selector xpath=»./scl:AccessPoint/scl:Server/scl:LDevice/scl:LN0/scl:LogControl«/> <xs:field xpath=»@logName«/> </xs:keyref> </xs:element> </xs:schema>»

A.5 Подсети связи

Файл SCL_Communication.xsd

<xs:schema targetNamespace=«http://www.iec.ch/61850/2003/SCL» xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:scl=«http://www.iec.ch/61850/2003/SCL» xmlns:xs=«http://www.w3.org/2001/XMLSchema» elementFormDefault=«qualified» attributeFormDefault=«unqualified» version=«1.0»> xs:annotation <xs:documentation xml:lang=«en»>COPYRIGHT IEC, 2003. Version 1.0. Release 2003/09/19.</xs:documentation> </xs:annotation> <xs:include schemaLocation=«SCL_BaseTypes.xsd»/> <xs:complexType name=«tControlBlock» abstract=«true»> xs:annotation <xs:documentation xml:lang=«en»>A control block within a Logical Device.</xs:documentation> </xs:annotation> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«Address» type=«tAddress» minOccurs=«0»/> </xs:sequence> <xs:attribute name=«ldInst» type=«tName» use=«required»/> <xs:attribute name=«cbName» type=«tName» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tCommunication»> xs:complexContent
<xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«SubNetwork» type=«tSubNetwork» maxOccurs=«unbounded»> <xs:unique name=«uniqueConnectedAP»> <xs:selector xpath=»./scl:ConnectedAP«/> <xs:field xpath=»@iedName«/> <xs:field xpath=»@apName«/> </xs:unique> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=»tSubNetwork«> xs:complexContent <xs:extension base=»tNaming«> xs:sequence <xs:element name=»BitRate» type=«tBitRateInMbPerSec» minOccurs=«0»/> <xs:element name=«ConnectedAP» type=«tConnectedAP» maxOccurs=«unbounded»> <xs:unique name=«uniqueGSEinConnectedAP»> <xs:selector xpath=»./scl:GSE«/> <xs:field xpath=»@cbName«/> </xs:unique> <xs:unique name=»uniqueSMVinConnectedAP«>»
<xs:selector xpath=»./scl:SMV«/> <xs:field xpath=»@cbName«/> </xs:unique> </xs:element> </xs:sequence> <xs:attribute name=»type» type=«xs:normalizedString» use=«optional»> xs:annotation <xs:documentation xml:lang=«en»>The bus protocol types are defined in IEC 61850 Part 8 and 9</xs: documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tConnectedAP»> xs:complexContent <xs:extension base=«tUnNaming»> xs:sequence <xs:element name=«Address» type=«tAddress» minOccurs=«0»/> <xs:element name=«GSE» type=«tGSE» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«SMV» type=«tSMV» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element name=«PhysConn» type=«tPhysConn» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«iedName» type=«tName» use=«required»/>
<xs:attribute name=«apName» type=«tName» use=«required»/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tAddress»> xs:sequence <xs:element name=«P» type=«tP» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«tGSE»> xs:complexContent <xs:extension base=«tControlBlock»> xs:sequence <xs:element name=«MinTime» type=«tDurationInMilliSec» minOccurs=«0»/> <xs:element name=«MaxTime» type=«tDurationInMilliSec» minOccurs=«0»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name=«tSMV»> xs:complexContent <xs:extension base=«tControlBlock»/> </xs:complexContent> </xs:complexType> <xs:complexType name=«tPhysConn»>
xs:sequence <xs:element name=«P» type=«tP» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> <xs:attribute name=«type» type=«xs:normalizedString» use=«required»/> </xs:complexType> <xs:complexType name=«tP»> xs:simpleContent <xs:extension base=«tPAddr»> <xs:attribute name=«type» type=«tPTypeEnum» use=«required»/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tP_IP»> xs:annotation <xs:documentation xml:lang=«en»>A TCP/IP address</xs:documentation> </xs:annotation> xs:simpleContent <xs:restriction base=«tP»> <xs:pattern value=«[0-2]?\d{1,2}.[0-2]?\d{1,2}.[0-2]?\d{1,2}.[0-2]?\d{1,2}»/> <xs:attribute name=«type» type=«tPTypeEnum» use=«required» fixed=«IP»/> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tP_IP-SUBNET»> xs:annotation
<xs:documentation xml:lang=«en»>A subnet Mask for TCP/IP profiles</xs:documentation> </xs:annotation> xs:simpleContent <xs:restriction base=«tP»> <xs:pattern value=«[0-2]?\d{1,2}.[0-2]?\d{1,2}.[0-2]?\d{1,2}.[0-2]?\d{1,2}»/> <xs:attribute name=«type» type=«tPTypeEnum» use=«required» fixed=«IP-SUBNET»/> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tP_IP-GATEWAY»> xs:annotation <xs:documentation xml:lang=«en»>A First Hop IP gateway address for TCP/IP profiles</xs:documentation> </xs:annotation> xs:simpleContent <xs:restriction base=«tP»> <xs:pattern value=«[0-2]?\d{1,2}.[0-2]?\d{1,2}.[0-2]?\d{1,2}.[0-2]?\d{1,2}»/> <xs:attribute name=«type» type=«tPTypeEnum» use=«required» fixed=«IP-GATEWAY»/> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tP_OSI-NSAP»>
xs:annotation <xs:documentation xml:lang=«en»>An OSI Network Address</xs:documentation> </xs:annotation> xs:simpleContent <xs:restriction base=«tP»> <xs:maxLength value=«40»/> <xs:pattern value=«[\d,A-F]+»/> <xs:attribute name=«type» type=«tPTypeEnum» use=«required» fixed=«OSI-NSAP»/> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tP_OSI-TSEL»> xs:annotation <xs:documentation xml:lang=«en»>An OSI Transport Selector</xs:documentation> </xs:annotation> xs:simpleContent <xs:restriction base=«tP»> <xs:maxLength value=«8»/> <xs:pattern value=«[\d,A-F]+»/> <xs:attribute name=«type» type=«tPTypeEnum» use=«required» fixed=«OSI-TSEL»/> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tP_OSI-SSEL»>
xs:annotation <xs:documentation xml:lang=«en»>An OSI Session Selector</xs:documentation> </xs:annotation> xs:simpleContent <xs:restriction base=«tP»> <xs:maxLength value=«16»/> <xs:pattern value=«[\d,A-F]+»/> <xs:attribute name=«type» type=«tPTypeEnum» use=«required» fixed=«OSI-SSEL»/> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tP_OSI-PSEL»> xs:annotation <xs:documentation xml:lang=«en»>An OSI Presentation Selector</xs:documentation> </xs:annotation> xs:simpleContent <xs:restriction base=«tP»> <xs:maxLength value=«16»/> <xs:pattern value=«[\d,A-F]+»/> <xs:attribute name=«type» type=«tPTypeEnum» use=«required» fixed=«OSI-PSEL»/> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tP_OSI-AP-Title»>
xs:annotation <xs:documentation xml:lang=«en»>An OSI ACSE AP Title value</xs:documentation> </xs:annotation> xs:simpleContent <xs:restriction base=«tP»> <xs:pattern value=«»[\d,,]+«»/> <xs:attribute name=«type» type=«tPTypeEnum» use=«required» fixed=«OSI-AP-Title»/> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tP_OSI-AP-Invoke»> xs:annotation <xs:documentation xml:lang=«en»>An OSI ACSE AP Invoke ID</xs:documentation> </xs:annotation> xs:simpleContent <xs:restriction base=«tP»> <xs:maxLength value=«5»/> <xs:pattern value=«\d+»/> <xs:attribute name=«type» type=«tPTypeEnum» use=«required» fixed=«OSI-AP-Invoke»/> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tP_OSI-AE-Qualifier»>
xs:annotation <xs:documentation xml:lang=«en»>An OSI ACSE AE Qualifier</xs:documentation> </xs:annotation> xs:simpleContent <xs:restriction base=«tP»> <xs:maxLength value=«5»/> <xs:pattern value=«\d+»/> <xs:attribute name=«type» type=«tPTypeEnum» use=«required» fixed=«OSI-AE-Qualifier»/> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tP_OSI-AE-Invoke»> xs:annotation <xs:documentation xml:lang=«en»>An OSI ACSE AE Invoke ID</xs:documentation> </xs:annotation> xs:simpleContent <xs:restriction base=«tP»> <xs:maxLength value=«5»/> <xs:pattern value=«\d+»/> <xs:attribute name=«type» type=«tPTypeEnum» use=«required» fixed=«OSI-AE-Invoke»/> </xs:restriction> </xs:simpleContent> </xs:complexType>
<xs:complexType name=«tP_MAC-Address»> xs:annotation <xs:documentation xml:lang=«en»>A Media Access Address value</xs:documentation> </xs:annotation> xs:simpleContent <xs:restriction base=«tP»> <xs:minLength value=«17»/> <xs:maxLength value=«17»/> <xs:pattern value=«[\d,A-F]{2}-[\d,A-F]{2}-[\d,A-F]{2}-[\d,A-F]{2}-[\d,A-F]{2}-[\d,A-F]{2}»/> <xs:attribute name=«type» type=«tPTypeEnum» use=«required» fixed=«MAC-Address»/> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tP_APPID»> xs:annotation <xs:documentation xml:lang=«en»>An Application Identifier</xs:documentation> </xs:annotation> xs:simpleContent <xs:restriction base=«tP»> <xs:minLength value=«4»/> <xs:maxLength value=«4»/> <xs:pattern value=«[\d,A-F]+»/> <xs:attribute name=«type» type=«tPTypeEnum» use=«required» fixed=«APPID»/>
</xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tP_VLAN-PRIORITY»> xs:annotation <xs:documentation xml:lang=«en»>A VLAN User Priority</xs:documentation> </xs:annotation> xs:simpleContent <xs:restriction base=«tP»> <xs:pattern value=«[0-7]»/> <xs:attribute name=«type» type=«tPTypeEnum» use=«required» fixed=«VLAN-PRIORITY»/> </xs:restriction> </xs:simpleContent> </xs:complexType> <xs:complexType name=«tP_VLAN-ID»> xs:annotation <xs:documentation xml:lang=«en»>A VLAN ID</xs:documentation> </xs:annotation> xs:simpleContent <xs:restriction base=«tP»> <xs:minLength value=«3»/> <xs:maxLength value=«3»/> <xs:pattern value=«[\d,A-F]+»/> <xs:attribute name=«type» type=«tPTypeEnum» use=«required» fixed=«VLAN-ID»/> </xs:restriction>
</xs:simpleContent> </xs:complexType> <xs:element name=«Communication» type=«tCommunication»> <xs:unique name=«uniqueSubNetwork»> <xs:selector xpath=»./scl:SubNetwork«/> <xs:field xpath=»@name«/> </xs:unique> </xs:element> </xs:schema>»

A.6 Основной язык SCL

Файл SCL.xsd

<xs:schema targetNamespace=«http://www.iec.ch/61850/2003/SCL» xmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:scl=«http://www.iec.ch/61850/2003/SCL» elementFormDefault=«qualified» attributeFormDefault=«unqualified» finalDefault=«extension» version=«1.0»> xs:annotation <xs:documentation xml:lang=«en»>COPYRIGHT IEC, 2003. Version 1.0. Release 2003/09/19.(Uncommented)</xs:documentation> </xs:annotation> <xs:include schemaLocation=«SCL_Substation.xsd»/> <xs:include schemaLocation=«SCL_IED.xsd»/> <xs:include schemaLocation=«SCL_Communication.xsd»/> <xs: include schemaLocation=«SCL_DataTypeTemplates.xsd»/> <xs:element name=«SCL»> xs:complexType xs:complexContent <xs:extension base=«tBaseElement»> xs:sequence <xs:element name=«Header» type=«tHeader»> <xs:unique name=«uniqueHitem»> <xs:selector xpath=»./scl:History/scl:Hitem«/> <xs:field xpath=»@version«/> <xs:field xpath=»@revision«/> </xs:unique> </xs:element>»
<xs:element ref=«Substation» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element ref=«Communication» minOccurs=«0»/> <xs:element ref=«IED» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element ref=«DataTypeTemplates» minOccurs=«0»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:unique name=«uniqueSubstation»> <xs:selector xpath=»./scl:Substation«/> <xs:field xpath=»@name«/> </xs:unique> <xs:key name=»IEDKey«> <xs:selector xpath=»./scl:IED«/> <xs:field xpath=»@name«/> </xs:key> <xs:key name=»LNodeTypeKey«> <xs:selector xpath=»./scl:DataTypeTemplates/scl:LNodeType«/> <xs:field xpath=»@id«/> <xs:field xpath=»@InClass«/> </xs:key> <xs:keyref name=»ref2LNodeTypeDomain1» refer=«LNodeTypeKey»> <xs:selector xpath=»./scl:IED/scl:AccessPoint/scl:LN«/> <xs:field xpath=»@InType«/> <xs:field xpath=»@InClass«/>»
</xs:keyref> <xs:keyref name=«ref2LNodeTypeDomain2» refer=«LNodeTypeKey»> <xs:selector xpath=»./scl:IED/scl:AccessPoint/scl:Server/scl:LDevice/scl:LN«/> <xs:field xpath=»@InType«/> <xs:field xpath=»@InClass«/> </xs:keyref> <xs:keyref name=»ref2LNodeTypeLLN0» refer=«LNodeTypeKey»> <xs:selector xpath=»./scl:IED/scl:AccessPoint/scl:Server/scl:LDevice/scl:LN0«/> <xs:field xpath=»@InType«/> <xs:field xpath=»@InClass«/> </xs:keyref> </xs:element> </xs:schema>»

Приложение B (обязательное)

<SCL xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:xsi=«http://www.w3.org/2001/XMLSchema-instance» xsi:schemaLocation=«http://www.iec.ch/61850/2003/SCL SCL.xsd»> status-only direct-with-normal-security sbo-with-normal-security direct-with-enhanced-security sbo-with-enhanced-security operate-once operate-many
not-supported bay-control station-control remote-control automatic-bay automatic-station automatic-remote maintenance process unknown forward backward both Unknown critical major minor warning normal high low
high-high low-low V A other Va Vb Vc Aa Ab Ac Vab Vbc Vca Aother Vother A B C
pos-neg-zero dir-quad-zero fundamental rms absolute ANSI Extremly Inverse ANSI Very Inverse ANSI Normal Inverse ANSI Moderate Inverse ANSI Definite Time Long-Time Extremely Inverse Long-Time Very Inverse Long-Time Inverse IEC Normal Inverse IEC Very Inverse IEC Inverse IEC Extremely Inverse IEC Short-Time Inverse IEC Long-Time Inverse IEC Definite Time Reserved
y z a f p n \mu m c d da h k M G T P E Z Y m kg
s A K mol cd deg rad sr Gy q °C Sv F C S H V ohm J N Hz Ix Lm Wb T W Pa
ml mi m/s m/sl mi/s m/mi M kg/mi ml/s W/m K J/K ppm 1/s rad/s VA W VAr theta cos(theta) Vs VI As Al Alt VAh Wh VArh
V/Hz intermediate off on bad stop lower higher reserved on blocked test test/blocked off on blocked test test/blocked
off Ok Warning Alarm None Open Close-Open Open-Close-Open Close-Open-Close-Open NonDirectional Forward Inverse Current Breaker Status Both current and breaker status Other
Inactive Stage 1 Stage 2 Stage 3 Stopped Stopping Started Starting Disabled Positive or Rising Negative or Falling Both Other Dead Line, Dead Bus Live Line, Dead Bus Dead Line, Live Bus Dead Line, Dead Bus OR Live Line, Dead Bus Dead Line, Dead Bus OR Dead Line, Live Bus Live Line, Dead Bus OR Dead Line, Live Bus
Dead Line, Dead Bus OR Live Line, Dead Bus OR Dead Line, Live Bus None Zero Sequence Current Zero Sequence Voltage Negative Sequence Voltage None Close Open Close and Open Overwrite existing values Stop when full or saturated Off Without Check With Current Check With Breaker Status Check With Current and Breaker Status Check Other Checks
None Harmonic2 Harmonic5 Harmonic2and5 WaveformAnalysis WaveformAnalysisAndHarmonic2 Other Off On None Intertrip Permissive Underreach Permissive Overreach Blocking None Open Close Open and Close
None Open Close Open and Close Load Break Disconnector Earthing Switch High Speed Earthing Switch Internal External Both 3 phase tripping 1 or 3 phase tripping specific None Definit Time Delayed Reset Inverse Reset
Off Permanent Time window Off Operate Echo Echo and Operate

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

ПРИМЕРЫ РАСШИРЕНИЯ СИНТАКСИСА

C.1 Синтаксис расширения для координат разметки чертежей

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

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

Система координат является относительной системой координат X, Y, использующей положительные целочисленные значения. Точка (0,0) является верхней левой точкой плоскости черчения с неограниченным движением в направлении вниз и вправо. Блок 1 в принципе относится к размеру объекта. Если используются объекты других размеров, тогда 1 — это размер наименьшего объекта. Однако перенос координат между различными графическими приложениями может в этом случае привести к искаженному отображению.

Если координаты определены на различных уровнях иерархии тегов языка SCL, то каждый уровень содержит координаты относительно верхнего уровня. Следовательно, абсолютные координаты нижнего уровня рассчитывают путем суммирования всех координат верхнего уровня и самих координат объектов. Если на верхнем уровне нет определенных координат, предполагается, что (X,Y) = (0,0).

Это проиллюстрировано на рисунке C.1. Здесь показаны подстанции 1 и 2; в качестве примера приведено присоединение 3 подстанции 1 уровня напряжения 1, которое имеет абсолютные координаты (0+1+6, 0+1+4) = (7,5).

Рисунок C.1 — Пример координат

Дополнительные элементы языка XML:

Для координат в направлениях X и Y, которые представляют графически отображаемые объекты, дополнительно к элементам языка SCL нужны только добавочные атрибуты X и Y языка XML. Кроме того, добавочный атрибут dir, имеющий значение horizontal (горизонтальный) или vertical (вертикальный), может дополнительно определять предпочтительное направление соединения объекта. Если указанный атрибут определен при присоединении, это значит, что все вложенные основные устройства ориентированы вертикально за исключением тех, для которых другое значение установлено явным образом. Пространством имени координат будет http://www.iec.ch/61850/2003/SCLcoordinates.

Соответствующим определением XML schema является следующее:

<xs:schema targetNamespace=«http://www.iec.ch/61850/2003/SCLcoordinates» xmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns=«http://www.iec.ch/61850/2003/SCLcoordinates» elementFormDefault=«qualified» attributeFormDefault=«unqualified» version=«0.1»> xs:annotation <xs:documentation xml:lang=«en»> COPYRIGHT IEC, 2003. Version 1.0. Release 2003/09/19. This schema is for informational purposes only, and is not normative! </xs:documentation> </xs:annotation> <xs:simpleType name=«tConndir»> <xs:restriction base=«xs:normalizedString»> <xs:enumeration value=«horizontal»/> <xs:enumeration value=«vertical»/> </xs:restriction> </xs:simpleType> <xs:attribute name=«x» type=«xs:int»/> <xs:attribute name=«y» type=«xs:int»/> <xs:attribute name=«dir» type=«tConndir»/> </xs:schema>

Ниже приведен пример использования координат с языком SCL. В данном примере трансформатор baden220_132.T1 имеет координаты (1,10) относительно подстанции. Присоединение D1Q1 уровня напряжения D1 располагается в верхнем левом углу разметки подстанции.

Следует обратить внимание, что это стандартизированное расширение, то есть имя расширения (sxy) начинается не с символа e. У частных расширений имя должно начинаться с символа e (см. 8.2.5).

<SCL xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:xsi=«http://www.w3.org/2001/XMLSchema-instance» xsi:schemaLocation=«http://www.iec.ch/61850/2003/SCLSCL.xsd» xmlns:sxy=«http://www.iec.ch/61850/2003/SCLcoordinates» sxy:schemaLocation=«d:\data\IECTC57\SCLXML<br>SCLcoordinates.xsd»>

C.2 Синтаксис расширения для технического обслуживания

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

Пространством имени указанного пакета расширений будет http://www.iec.ch/61850/2003/SCLmaintenance. Именем пространства имен будет smop (xmlns:smop).

Соответствующим определением XML schema является следующее:

<xs:schema targetNamespace=«http://www.iec.ch/61850/2003/SCLmaintenance» xmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns=«http://www.iec.ch/61850/2003/SCLmaintenance» elementFormDefault=«qualified» attributeFormDefault=«unqualified» version=«0.1»> xs:annotation <xs:documentation xml:lang=«en»>COPYRIGHT IEC, 2003. Version 0.1. Draft 2003/08/28.</xs:documentation> </xs:annotation> <xs:simpleType name=«tRestrName1stL»> <xs:restriction base=«xs:Name»> <xs:pattern value=«\p{LI}[\d,\p{L},_]*»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tMopEnum»> <xs:restriction base=«xs:string»> <xs:enumeration value=«M»/> <xs:enumeration value=«O»/> <xs:enumeration value=«P»/> <xs:enumeration value=«C»/> <xs:enumeration value=«C1»/> <xs:enumeration value=«C2»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«tExtensionMopEnum»> <xs:restriction base=«tRestrName1stL»/> </xs:simpleType>

<xs:simpleType name=«tMOP»> <xs:union memberTypes=«tMopEnum tExtensionMopEnum»/> </xs:simpleType> <xs:attribute name=«mop» type=«tMOP»/> <xs:element name=«CondDesc»> xs:complexType <xs:attribute name=«desc» type=«xs:string» use=«required»/> <xs:attribute ref=«mop» use=«required»/> </xs:complexType> </xs:element> </xs:schema>

Данный синтаксис определяет атрибут mop с допустимыми значениями M, O, P и C, C1, C2. Значение M для mop означает «обязательный», O — «дополнительный», а P — «частный», то есть специфичный для изготовителя конкретного типа IED-устройства. Значения C, C1, C2 представляют собой различные условия, при которых соответствующий объект является или не является обязательным. Более специфичные условия (например, определенные в МЭК 61850-7-3) могут быть заявлены дополнительно. Частные условия должны начинаться с символа E. Можно использовать элемент CondDesc для создания тестовых пояснений к условиям.

Примечание - Упомянутое определение синтаксиса не может ограничивать употребление атрибута mop. Однако он используется только в пределах секции DataTypeTemplates с элементами DO, DA, SDO и BDA.

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

ПРИМЕР

D.1 Пример спецификации

Здесь рассмотрен пример на основе спецификации, приведенной в МЭК 61850-5. Однако присвоение имен устройствам изменено и соответствует серии стандартов МЭК 61346. Данный пример не является полностью законченным, однако он иллюстрирует большинство возможностей языка SCL по описанию системы, то есть это файл SCD.

D.1.1 Конфигурация подстанции

Пример T1-1

Два уровня напряжения:

D1 — 220 кВ;

E1 — 132 кВ;

5 присоединений:

1 — D1Q1 фидер с трансформатором тока CT;

2 — E1Q2 фидер с разъединителем DIS, выключателем CBR, трансформатором тока CT, трансформатором напряжения VT;

3 — E1Q4 статическая шина;

4 — E1Q1 фидер с разъединителем DIS, выключателем CBR, трансформатором тока CT, трансформатором напряжения VT;

5 — E1Q3 фидер с разъединителем DIS, выключателем CBR, трансформатором тока CT, трансформатором напряжения VT

Рисунок D.1 — T1-1. Конфигурация подстанции

На рисунке D.1 показана однолинейная схема. Ток, поступающий через D1Q1 на трансформатор D1T1, распределяется на стороне низкого напряжения по двум линиям E1Q1 и E1Q3. Автоматический выключатель в D1Q1 находится за пределами рассматриваемой SA-системы.

D.1.2 Конфигурация системы связи

Пример T1-1

Одиночная система шин связи

IED-устройства для:

трансформатора;

комбинированной ячейки (автоматический выключатель, разъединитель, трансформатор тока, трансформатор напряжения);

каждой защиты;

центральных функций

N	Наименование	Идентификационное обозначение
1	Dist	E1Q1BP3 (PDIS)
2	Difn	E1Q1BP2 (PDIF)
3	Dist	E1Q3BP3 (PDIS)
4	Difn	E1Q3BP2 (PDIF)
5	Dist	D1Q1BP3 (PDIS)
6	TDifn	D1Q1BP2 (PDIF)
7	Trafo	D1Q1SB1
8	LVBay1	E1Q2SB1
9	LVBay2	E1Q1SB1
10	LVBay3	E1Q3SB1
11	Central	D1Q1SB4 (CILO, PSYN)

Рисунок D.2 — T1-1. Конфигурация связи

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

D.1.3 IED-устройство трансформатора

На рисунке D.3 инстанцированная функциональность IED-устройства управления трансформатором показана как набор LN.

Пример T1-1

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

N	Наименование	Идентификационное обозначение
7	Trafo Bay1	D1Q1SB1

Рисунок D.3 — Ячейка трансформатора T1-1

D.2 Пример содержимого файла SCL

Ниже приведен синтаксически корректный, но не полностью законченный файл SCD для приведенного выше примера спецификации. У некоторых IED-устройств отсутствует описание сервера и соответственно не указан поток данных как в направлении упомянутых IED-устройств, так и от самих устройств. С другой стороны, некоторые LN, которые должны резидентно находиться на указанных IED-устройствах, были размещены на секции подстанции. Следовательно, данный файл не только неполный, но также и недействителен на прикладном уровне. Однако два IED-устройства — E1Q1SB1 и D1Q1SB4 — и некоторый поток данных между ними с GOOSE-сообщениями и SV смоделированы, а топология подстанции как таковая имеет законченную информацию о присоединении. Также закончено определение подсети Subnet, по крайней мере, для смоделированного потока данных.

<SCL xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:xsi=«http://www.w3.org/2001/XMLSchema-instance» xsi:schemaLocation=«http://www.iec.ch/61850/2003/SCL SCL.xsd»> 220
132
</Conducting Equipment </Conducting Equipment>
</Conducting Equipment> </Conducting Equipment </Conducting Equipment>
</Conducting Equipment
</Conducting Equipment> </Conducting Equipment> </Conducting Equipment>
Station bus 10 10.0.0.11 255.255.255.0 10.0.0.101 00000001 01 01 01-0C-CD-01-00-02
3001 4 FOC ST 10.0.0.1 255.255.255.0 10.0.0.101 00000001 01 01 01-0C-CD-01-00-01 3000 4
01-0C-CD-04-00-01 4000 123 4 10.0.0.2 255.255.255.0 10.0.0.101 00000001 01 01 10.0.0.3 255.255.255.0 10.0.0.101 00000001 01 01
false
10 200
false
IEC61850-7-4:2003 Rev 3.45 myVendorName
Rev 1.23
unknown forward backward both
pos-neg-zero dir-quad-zero intermediate off on bad stop lower higher reserved on blocked test test/blocked off on blocked test test/blocked
off Ok Warning Alarm

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

ОПРЕДЕЛЕНИЕ XML SCHEMA ВАРИАНТОВ ЯЗЫКА SCL

Следующая часть schema, использующая элементы из нормативного определения SCL schema, сама по себе, однако, не является нормативной и формально определяет ограничения для различных вариантов языка SCL, которые представлены в разделе 7:

CID: описание сконфигурированного IED-устройства;

ICD: описание возможностей IED-устройства;

SCD: описание конфигурации подстанции;

SSD: описание системной спецификации; здесь приведена «чистая» версия без IED-устройств и версия с установкой некоторых уже известных IED-устройств.

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

<xs:schema targetNamespace=«http://www.iec.ch/61850/2003/SCL» xmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns=«http://www.iec.ch/61850/2003/SCL» xmlns:scl=«http://www.iec.ch/61850/2003/SCL» elementFormDefault=«qualified» attributeFormDefault=«unqualified» finalDefault=«extension» version=«1.0»> xs:annotation <xs:documentation xml:lang=«en»> COPYRIGHT IEC, 2003. Version 1.0. Release 2003/08/20. This schema is for international purposes only, and is not normative! Notes: - Identity constraints are in comments, in order to avoid any clashes with the existing ones. - The elements are defined as abstract to prevent their usage in practice. </xs:documentation> </xs:annotation> <xs:include schemaLocation=«SCL.xsd»/> <xs:element name=«SCL_ICD» abstract=«true»> xs:annotation <xs:documentation xml:lang=«en»>SCL for an IED Capability Description (ICD)</xs:documentation> </xs:annotation> xs:complexType
xs:complexContent <xs:extension base=«tBaseElement»> xs:sequence <xs:element name=«Header» type=«tHeader»> </xs:element> <xs:element name=«Substation» type=«tSubstationTemplate» minOccurs=«0»> <!--<xs:unique name=«uniqueVoltageLevelInSubstation»> <xs:selector xpath=»./scl:VoltageLevel«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniquePowerTranformerInSubstation«> <xs:selector xpath=»./scl:PowerTransformer«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueFunctionInSubstation«> <xs:selector xpath=»./scl:Function«/> <xs:field xpath=»@name«/> </xs:unique> <xs:key name=»ConnectivityNodeKey«>»
<xs:selector xpath=».//scl:ConnectivityNode«/> <xs:field xpath=»@pathName«/> </xs:key> <xs:keyref name=»ref2ConnectivityNode» refer=«ConnectivityNodeKey»> <xs:selector xpath=».//scl:Terminal«/> <xs:field xpath=»@connectivityNode«/> </xs:keyref> <xs:unique name=»uniqueLNode«> <xs:selector xpath=».//scl:LNode«/> <xs:field xpath=»@InInst«/> <xs:field xpath=»@InClass«/> <xs:field xpath=»@iedName«/> <xs:field xpath=»@IdInst«/> <xs:field xpath=»@prefix«/> </xs:unique>--> </xs:element> <xs:element ref=»Communication» minOccurs=«0»/> <xs:element name=«IED» type=«tIEDTemplate»> <!--<xs:unique name=«uniqueAccessPointInIED»> <xs:selector xpath=»./scl:AccessPoint«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueLDeviceInIED«> <xs:selector xpath=».//scl:LDevice«/> <xs:field xpath=»@inst«/> </xs:unique>»
<xs:unique name=«uniqueGSEControlInIED»> <xs:selector xpath=».//scl:GSEControl«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueSMVControlInIED«> <xs:selector xpath=».//scl:SampledValueControl«/> <xs:field xpath=»@name«/> </xs:unique> <xs:key name=»LDeviceInIEDKey«> <xs:selector xpath=»./scl:AccessPoint/scl:Server/scl:LDevice«/> <xs:field xpath=»@inst«/> </xs:key> <xs:keyref name=»ref2LDeviceInIED» refer=«LDeviceInIEDKey»> <xs:selector xpath=»./scl:AccessPoint/scl:Server/scl:LDevice/scl:LN0/scl:LogControl«/> <xs:field xpath=»@logName«/> </xs:keyref>--> </xs:element> <xs:element ref=»DataTypeTemplates«/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!--<xs:key name=»LNodeTypeKey«> <xs:selector xpath=»./scl:DataTypeTemplates/scl:LNodeType«/> <xs:field xpath=»@id«/> <xs:field xpath=»@InClass«/> </xs:key>»
<xs:keyref name=«ref2LNodeTypeDomain1» refer=«LNodeTypeKey»> <xs:selector xpath=»./scl:IED/scl:AccessPoint/scl:LN«/> <xs:field xpath=»@InType«/> <xs:field xpath=»@InClass«/> </xs:keyref> <xs:keyref name=»ref2LNodeTypeDomain2» refer=«LNodeTypeKey»> <xs:selector xpath=»./scl:IED/scl:AccessPoint/scl:Server/scl:LDevice/scl:LN«/> <xs:field xpath=»@InType«/> <xs:field xpath=»@InClass«/> </xs:keyref> <xs:keyref name=»ref2LNodeTypeLLN0» refer=«LNodeTypeKey»> <xs:selector xpath=»./scl:IED/scl:AccessPoint/scl:Server/scl:LDevice/scl:LN0«/> <xs:field xpath=»@InType«/> <xs:field xpath=»@InClass«/> </xs:keyref>--> </xs:element> <xs:element name=»SCL_pureSSD» abstract=«true»> xs:annotation <xs:documentation xml:lang=«en»>SCL for a «Pure» System Specification Document (SSD)</xs:documentation> </xs:annotation> xs:complexType xs:complexContent <xs:extension base=«tBaseElement»> xs:sequence
<xs:element name=«Header» type=«tHeader»> </xs:element> <xs:element ref=«Substation» maxOccurs=«unbounded»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name=«SCL_SSD» abstract=«true»> xs:annotation <xs:documentation xml:lang=«en»>SCL for a System Specification Document (SSD)</xs:documentation> </xs:annotation> xs:complexType xs:complexContent
<xs:extension base=«tBaseElement»> xs:sequence <xs:element name=«Header» type=«tHeader»> </xs:element> <xs:element ref=«Substation» maxOccurs=«unbounded»/> <xs:element ref=«Communication» minOccurs=«0»/> <xs:element ref=«IED» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element ref=«DataTypeTemplates» minOccurs=«0»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!--<xs:unique name=«uniqueSubstation»> <xs:selector xpath=»./scl:Substation«/> <xs:field xpath=»@name«/> </xs:unique> <xs:key name=»IEDKey«> <xs:selector xpath=»./scl:IED«/> <xs:field xpath=»@name«/> </xs:key> <xs:key name=»LNodeTypeKey«>»
<xs:selector xpath=»./scl:DataTypeTemplates/scl:LNodeType«/> <xs:field xpath=»@id«/> <xs:field xpath=»@InClass«/> </xs:key> <xs:keyref name=»ref2LNodeTypeDomain1» refer=«LNodeTypeKey»> <xs:selector xpath=»./scl:IED/scl:AccessPoint/scl:LN«/> <xs:field xpath=»@InType«/> <xs:field xpath=»@InClass«/> </xs:keyref> <xs:keyref name=»ref2LNodeTypeDomain2» refer=«LNodeTypeKey»> <xs:selector xpath=»./scl:IED/scl:AccessPoint/scl:Server/scl:LDevice/scl:LN«/> <xs:field xpath=»@InType«/> <xs:field xpath=»@InClass«/> </xs:keyref> <xs:keyref name=»ref2LNodeTypeLLN0» refer=«LNodeTypeKey»> <xs:selector xpath=»./scl:IED/scl:AccessPoint/scl:Server/scl:LDevice/scl:LN0«/> <xs:field xpath=»@InType«/> <xs:field xpath=»@InClass«/> </xs:keyref>--> </xs:element> <xs:element name=»SCL_SCD» abstract=«true»> xs:annotation <xs:documentation xml:lang=«en»>SCL for a Substation Configuration Description (SCD)</xs:documentation>
</xs:annotation> xs:complexType xs:complexContent <xs:extension base=«tBaseElement»> xs:sequence <xs:element name=«Header» type=«tHeader»> </xs:element> <xs:element ref=«Substation» maxOccurs=«unbounded»/> <xs:element ref=«Communication»/> <xs:element ref=«IED» maxOccurs=«unbounded»/> <xs:element ref=«DataTypeTemplates»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!--<xs:unique name=«uniqueSubstation»> <xs:selector xpath=»./scl:Substation«/> <xs:field xpath=»@name«/> </xs:unique> <xs:key name=»IEDKey«> <xs:selector xpath=»./scl:IED«/> <xs:field xpath=»@name«/>»
</xs:key> <xs:key name=«LNodeTypeKey»> <xs:selector xpath=»./scl:DataTypeTemplates/scl:LNodeType«/> <xs:field xpath=»@id«/> <xs:field xpath=»@InClass«/> </xs:key> <xs:keyref name=»ref2LNodeTypeDomain1» refer=«LNodeTypeKey»> <xs:selector xpath=»./scl:IED/scl:AccessPoint/scl:LN«/> <xs:field xpath=»@InType«/> <xs:field xpath=»@InClass«/> </xs:keyref> <xs:keyref name=»ref2LNodeTypeDomain2» refer=«LNodeTypeKey»> <xs:selector xpath=»./scl:IED/scl:AccessPoint/scl:Server/scl:LDevice/scl:LN«/> <xs:field xpath=»@InType«/> <xs:field xpath=»@InClass«/> </xs:keyref> <xs:keyref name=»ref2LNodeTypeLLN0» refer=«LNodeTypeKey»> <xs:selector xpath=»./scl:IED/scl:AccessPoint/scl:Server/scl:LDevice/scl:LN0«/> <xs:field xpath=»@InType«/> <xs:field xpath=»@InClass«/> </xs:keyref>--> </xs:element> <xs:element name=»SCL_CID» abstract=«true»> xs:annotation
<xs:documentation xml:lang=«en»>SCL for a Configured IED Description (CID)</xs:documentation> </xs:annotation> xs:complexType xs:complexContent <xs:extension base=«tBaseElement»> xs:sequence <xs:element name=«Header» type=«tHeader»> </xs:element> <xs:element ref=«Substation» minOccurs=«0» maxOccurs=«unbounded»/> <xs:element ref=«Communication»/> <xs:element ref=«IED» maxOccurs=«unbounded»/> <xs:element ref=«DataTypeTemplates»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!--<xs:key name=«LNodeTypeKey»> <xs:selector xpath=»./scl:DataTypeTemplates/scl:LNodeType«/> <xs:field xpath=»@id«/> <xs:field xpath=»@InClass«/>»
</xs:key> <xs:keyref name=«ref2LNodeTypeDomain1» refer=«LNodeTypeKey»> <xs:selector xpath=»./scl:IED/scl:AccessPoint/scl:LN«/> <xs:field xpath=»@InType«/> <xs:field xpath=»@InClass«/> </xs:keyref> <xs:keyref name=»ref2LNodeTypeDomain2» refer=«LNodeTypeKey»> <xs:selector xpath=»./scl:IED/scl:AccessPoint/scl:Server/scl:LDevice/scl:LN«/> <xs:field xpath=»@InType«/> <xs:field xpath=»@InClass«/> </xs:keyref> <xs:keyref name=»ref2LNodeTypeLLN0» refer=«LNodeTypeKey»> <xs:selector xpath=»./scl:IED/scl:AccessPoint/scl:Server/scl:LDevice/scl:LN0«/> <xs:field xpath=»@InType«/> <xs:field xpath=»@InClass«/> </xs:keyref>--> </xs:element> <xs:complexType name=»tSubstationTemplate«> xs:complexContent <xs:restriction base=»tSubstation«> xs:sequence xs:sequence <xs:any namespace=»##other» minOccurs=«0» maxOccurs=«unbounded»/>
<xs:element name=«Text» type=«tText» minOccurs=«0»/> <xs:element name=«Private» type=«tPrivate» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> xs:sequence <xs:element name=«LNode» type=«tLNode» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> xs:sequence <xs:element name=«PowerTransformer» type=«tPowerTransformer» minOccurs=«0» maxOccurs=«unbounded»> </xs:element> </xs:sequence> xs:sequence <xs:element name=«VoltageLevel» type=«tVoltageLevel» maxOccurs=«unbounded»> <!--<xs:unique name=«uniqueBayInVoltageLevel»> <xs:selector xpath=»./scl:Bay«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniquePowerTransformerInVoltageLevel«> <xs:selector xpath=»./scl:PowerTransformer«/>»
<xs:field xpath=«@name»/> </xs:unique> </xs:element> <xs:element name=«Function» type=«tFunction» minOccurs=«0» maxOccurs=«unbounded»> <xs:unique name=«uniqueSubFunctionInFunction»> <xs:selector xpath=»./scl:SubFunction«/> <xs:field xpath=»@name«/> </xs:unique> <xs:unique name=»uniqueGeneralEquipmentInFunction«> <xs:selector xpath=»./scl:GeneralEquipment«/> <xs:field xpath=»@name«/> </xs:unique>--> </xs:element> </xs:sequence> </xs:sequence> <xs:attribute name=»name» type=«tName» use=«required» fixed=«TEMPLATE»/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name=«tIEDTemplate»> xs:complexContent <xs:restriction base=«tIED»> xs:sequence xs:sequence <xs:any namespace=«##other» minOccurs=«0» maxOccurs=«unbounded»/>
<xs:element name=«Text» type=«tText» minOccurs=«0»/> <xs:element name=«Private» type=«tPrivate» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> xs:sequence <xs:element name=«Services» type=«tServices» minOccurs=«0»/> <xs:element name=«AccessPoint» type=«tAccessPoint» maxOccurs=«unbounded»> </xs:element> </xs:sequence> </xs:sequence> <xs:attribute name=«name» type=«tName» use=«required» fixed=«TEMPLATE»/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:schema>

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

Таблица ДА.1

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
МЭК 61850-2:2000	-	<*>
МЭК 61850-5:2003	-	<*>
МЭК 61850-7-1:2003	IDT	ГОСТ Р МЭК 61850-7-1-2009 «Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 1. Принципы и модели»
МЭК 61850-7-2:2003	IDT	ГОСТ Р МЭК 61850-7-2-2009 «Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 2. Абстрактный интерфейс услуг связи (ACSI)»
МЭК 61850-7-3:2003	IDT	ГОСТ Р МЭК 61850-7-3-2009 «Сети и системы связи на подстанциях. Часть 7. Базовая структура связи для подстанций и линейного оборудования. Раздел 3. Классы общих данных»
МЭК 61850-7-4:2003	-	<*>
<*> Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Перевод данного международного стандарта находится в ОАО «Научно-технический центр электроэнергетики» (E-mail: vulis@vniie.ru, vulis@ntc-power.ru). Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов: - IDT — идентичные стандарты.

БИБЛИОГРАФИЯ

[1]	МЭК 61346-1:1996	Системы, установки и аппаратура промышленные и промышленная продукция. Принципы организационной структуры и ссылочные обозначения. Часть 1. Основные правила (Заменен на IEC 81346-1(2009) Производственные системы, установки и оборудование и промышленная продукция. Принципы структурирования и условные обозначения. Часть 1. Основные правила)
[2]	МЭК 61346-2:2000	Системы, установки и аппаратура промышленные и промышленная продукция. Принципы организационной структуры и ссылочные обозначения. Часть 2. Классификация объектов и коды для классов (Заменен на IEC 81346-2(2009) Производственные системы, установки и оборудование и промышленная продукция. Принципы структурирования и условные обозначения. Часть 2. Классификация объектов и коды классов)
[3]	МЭК 61850-8-1:2004	Сети и системы связи на подстанциях. Часть 8-1. Специфическое отображение сервиса связи (SCSM). Схемы отображения на MMS (ISO 9506-1 и ISO 9506-2) и на ISO/IEC 8802-3
[4]	МЭК 61850-9-1:2003	Сети и системы связи на подстанциях. Часть 9-1. Специфическое отображение сервиса связи (SCSM). Выборочные значения в пределах последовательного однонаправленного многоточечного канала связи типа «точка-точка»
[5]	МЭК 61850-9-2:2004	Сети и системы связи на подстанциях. Часть 9-2. Специфическое отображение сервиса связи (SCSM). Выборочные значения в соответствии с ИСО/МЭК 8802-3
[6]	ИСО/МЭК 8859-1	Информационные технологии. 8-битные однобайтовые наборы кодированных графических символов. Часть 1. Латинский алфавит № 1
[7] Расширенный язык разметки (XML) 1.0, рабочая группа W3C, ссылка: <http://www.w3.org/TR/2000/REC-xml-20001006>
[8] Пространства имен в расширенном языке разметки (XML) 1.0, рабочая группа W3C, ссылка: <http://www.w3.org/TR/1999/REC-xml-names-19990114>
[9] Язык XML schema Часть 0: Основные понятия, рабочая группа W3C, ссылка: <http://www.w3.org/TR/2001/REC-xmlschema-0-20010502>
[10] Язык XML schema Часть 1: Структуры, рабочая группа W3C, ссылка: <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502>
[11] Язык XML schema Часть 2: Типы данных, рабочая группа W3C, ссылка: <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>
[12] Документ RFC 1952 Спецификация формата файла GZIP, версия 4.3, RFC, ссылка: <http://www.ietf.org/rfc/rfc1952.txt>
[13] Документ RFC 2045 Многоцелевые расширения электронной почты (MIME). Первая часть: Формат тела электронных сообщений, RFC, ссылка: <http://www.ietf.org/rfc/rfc2045.txt>
[14] Ссылка UMLTM Resource Page, OMG, адрес: http://www.omg.org/uml

УДК 621.398.606.394:006.354	ОКС 33.200	П77	ОКП 42 3200
Ключевые слова: сети связи, подстанция, интеллектуальные электронные устройства, конфигурирование, расширенный язык разметки XML

---