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

ГОСТ Р МЭК 61850-6-2009

Группа П77

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

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

Часть 6

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

Communication networks and systems in substations. Part 6. Configuration description language for communication in electrical substations related to IEDs

ОКС 33.200
ОКП 42 3200

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

Предисловие

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

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

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

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 15 декабря 2009 г. N 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")
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке. - .

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

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

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


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

Введение

Введение

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

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

Рисунок 1 - Эталонная модель потока информации в процессе конфигурирования

Рисунок 1 - Эталонная модель потока информации в процессе конфигурирования

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

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

- его сопровождает файл SCL, в котором содержится описание возможностей устройства, или специальная программа, которая может сгенерировать этот файл из IED-устройства;

- оно может напрямую использовать системный файл 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

Рисунок 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 также использует это обозначение для описания связей между различными объектами модели. В данном случае атрибут, содержащий ссылку, если это возможно, получает имя в виде <Targettype>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 кВ с присоединением типа Е1 представляет собой двойную систему шин с двумя присоединениями линий =Е1Q1 и =Е1Q3 и шиносоединительным выключателем =Е1Q2. IED-устройства уже ассоциированы с функциональностью первичного оборудования (например, контроллер присоединения E1Q1SB1 как продукт сопоставлен с присоединением =E1Q1, а его LN CSWI1 управляет автоматическим выключателем =E1Q1QA1 через LN XCBR1 на IED-устройстве E1Q1QA1B1). Следует обратить внимание на то, что согласно терминам МЭК 61346-1 присоединение является переходным объектом. Это значит, что оно имеет функцию (знак = (равно) на уровне распределительного устройства) и в качестве продукта рассматривается как компонент распределительного устройства. Этот переход виден в описании языка SCL только в структуре имен IED-устройства. Явным образом моделируется только переход на LN. На рисунке 3 знаком - (минус) отмечены обозначения, относящиеся к продукту. Функциональное имя не повторяется. Подсеть связи на уровне станции называется W1. На уровне процесса имеются три дополнительные подсети (технологические шины) - W2, W3, W4. На рисунке можно видеть точки доступа, но их обозначения не показаны. На рисунке также не показаны LD и серверы. В основном это означает, что не показаны динамические соединения, например ассоциации.

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

Рисунок 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 - Следует обратить внимание на то, что иерархическая структура применяется в основном для функциональных обозначений. Если необходимы подструктуры присоединений, их можно ввести через имена соответствующих присоединений. Если, например, присоединение В1 структурно включает подгруппы присоединений SB1 и SB2, в SCL-модели это может привести к созданию двух присоединений, называемых B1.SB1 и B1.SB2. Если на уровне структуры В1 дополнительно присоединяются LN, тогда В1 может быть введено как третье присоединение.


Уровни функции и подфункции, показанные на рисунке 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, а LN, размещенные в LD, могут использовать несколько точек доступа как клиенты для соединения с различными подсетями. Как правило, LN контроллера выключателя может получать данные с технологической шины (МЭК 61850-9-1, МЭК 61850-9-2) как клиент и предоставлять данные на шину обмена между присоединениями (МЭК 61850-8-1) как сервер. По терминологии серии стандартов МЭК 61850-7 точка доступа может использоваться сервером, клиентом или тем и другим. Кроме того, одна и та же (логическая) точка доступа может поддерживать различные физические порты доступа, например соединение Ethernet и последовательное соединение на основе РРР (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. При их отсутствии (если необходимо) может быть введен набор частных параметров Р, например, в точках доступа. Из-за частной природы параметров резервирование на их основе может оказаться неуспешным для 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

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

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

- имена типов схемы начинаются со строчной буквы t (например, tSubstation);

- определения группы атрибутов начинаются с акронима ag (например, agAuthorization);

- имена атрибутов начинаются со строчной буквы (нижний регистр клавиатуры) (например, name);

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

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

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

- tUnNaming добавляет дополнительный атрибут описания desc;

- tNaming добавляет дополнительный атрибут описания desc и обязательный атрибут имени name;

- tIDNaming добавляет атрибут описания desc и обязательный атрибут идентификатора id.

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

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

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


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

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

Здесь 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, имеют слабо выраженную семантику, которая может быть расширена за счет некоторых приложений. Некоторые элементы, такие, как элемент параметра Р, были специально оставлены открытыми. Семантика (дополнительная семантика) этих элементов должна быть определена на уровне SCSM. Это выполняется путем определения значения type (тип) для параметра Р с собственной семантикой.

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

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

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

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

xmlns:scl="//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, который определяется следующим образом:

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

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


Таблица 2 - Атрибуты элемента Private

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.

<?xml version="1.0"?>

<!--Пример расширенного файла:

- с элементом Private

- с использованием расширений из других пространств имен

-

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

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

_________________
* Наименование пункта 8.3 в бумажном оригинале выделено курсивом. - .

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

как определено в разделе 9-->

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

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

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

Все элементы являются производными типа 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

Рисунок 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 на lEDName (имя 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 - Элементы имени сигнала при функциональном присвоении имен

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

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

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

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

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

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

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

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

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

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


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

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

9.1 Заголовок

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

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

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

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

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


Таблица 3 - Атрибуты элемента Header

Элемент Text является дополнительным и имеет следующий синтаксис:

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

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

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


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

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

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


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

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

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

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

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

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

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

- подстанция;

- уровень напряжения;

- присоединение.

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

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

ГОСТ Р МЭК 61850-6-2009

Группа П77

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

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

Часть 6

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

Communication networks and systems in substations. Part 6. Configuration description language for communication in electrical substations related to IEDs

ОКС 33.200
ОКП 42 3200

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

Предисловие

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

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

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

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 15 декабря 2009 г. N 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")
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке. - .

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

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

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


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

Введение

Введение

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

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

Рисунок 1 - Эталонная модель потока информации в процессе конфигурирования

Рисунок 1 - Эталонная модель потока информации в процессе конфигурирования

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

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

- его сопровождает файл SCL, в котором содержится описание возможностей устройства, или специальная программа, которая может сгенерировать этот файл из IED-устройства;

- оно может напрямую использовать системный файл 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

Рисунок 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 также использует это обозначение для описания связей между различными объектами модели. В данном случае атрибут, содержащий ссылку, если это возможно, получает имя в виде <Targettype>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 кВ с присоединением типа Е1 представляет собой двойную систему шин с двумя присоединениями линий =Е1Q1 и =Е1Q3 и шиносоединительным выключателем =Е1Q2. IED-устройства уже ассоциированы с функциональностью первичного оборудования (например, контроллер присоединения E1Q1SB1 как продукт сопоставлен с присоединением =E1Q1, а его LN CSWI1 управляет автоматическим выключателем =E1Q1QA1 через LN XCBR1 на IED-устройстве E1Q1QA1B1). Следует обратить внимание на то, что согласно терминам МЭК 61346-1 присоединение является переходным объектом. Это значит, что оно имеет функцию (знак = (равно) на уровне распределительного устройства) и в качестве продукта рассматривается как компонент распределительного устройства. Этот переход виден в описании языка SCL только в структуре имен IED-устройства. Явным образом моделируется только переход на LN. На рисунке 3 знаком - (минус) отмечены обозначения, относящиеся к продукту. Функциональное имя не повторяется. Подсеть связи на уровне станции называется W1. На уровне процесса имеются три дополнительные подсети (технологические шины) - W2, W3, W4. На рисунке можно видеть точки доступа, но их обозначения не показаны. На рисунке также не показаны LD и серверы. В основном это означает, что не показаны динамические соединения, например ассоциации.

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

Рисунок 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 - Следует обратить внимание на то, что иерархическая структура применяется в основном для функциональных обозначений. Если необходимы подструктуры присоединений, их можно ввести через имена соответствующих присоединений. Если, например, присоединение В1 структурно включает подгруппы присоединений SB1 и SB2, в SCL-модели это может привести к созданию двух присоединений, называемых B1.SB1 и B1.SB2. Если на уровне структуры В1 дополнительно присоединяются LN, тогда В1 может быть введено как третье присоединение.


Уровни функции и подфункции, показанные на рисунке 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, а LN, размещенные в LD, могут использовать несколько точек доступа как клиенты для соединения с различными подсетями. Как правило, LN контроллера выключателя может получать данные с технологической шины (МЭК 61850-9-1, МЭК 61850-9-2) как клиент и предоставлять данные на шину обмена между присоединениями (МЭК 61850-8-1) как сервер. По терминологии серии стандартов МЭК 61850-7 точка доступа может использоваться сервером, клиентом или тем и другим. Кроме того, одна и та же (логическая) точка доступа может поддерживать различные физические порты доступа, например соединение Ethernet и последовательное соединение на основе РРР (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. При их отсутствии (если необходимо) может быть введен набор частных параметров Р, например, в точках доступа. Из-за частной природы параметров резервирование на их основе может оказаться неуспешным для 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

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

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

- имена типов схемы начинаются со строчной буквы t (например, tSubstation);

- определения группы атрибутов начинаются с акронима ag (например, agAuthorization);

- имена атрибутов начинаются со строчной буквы (нижний регистр клавиатуры) (например, name);

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

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

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

- tUnNaming добавляет дополнительный атрибут описания desc;

- tNaming добавляет дополнительный атрибут описания desc и обязательный атрибут имени name;

- tIDNaming добавляет атрибут описания desc и обязательный атрибут идентификатора id.

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

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

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


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

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

Здесь 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, имеют слабо выраженную семантику, которая может быть расширена за счет некоторых приложений. Некоторые элементы, такие, как элемент параметра Р, были специально оставлены открытыми. Семантика (дополнительная семантика) этих элементов должна быть определена на уровне SCSM. Это выполняется путем определения значения type (тип) для параметра Р с собственной семантикой.

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

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

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

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

xmlns:scl="//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, который определяется следующим образом:

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

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


Таблица 2 - Атрибуты элемента Private

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.

<?xml version="1.0"?>

<!--Пример расширенного файла:

- с элементом Private

- с использованием расширений из других пространств имен

-

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

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

_________________
* Наименование пункта 8.3 в бумажном оригинале выделено курсивом. - .

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

как определено в разделе 9-->

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

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

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

Все элементы являются производными типа 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

Рисунок 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 на lEDName (имя 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 - Элементы имени сигнала при функциональном присвоении имен

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

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

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

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

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

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

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

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

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

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


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

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

9.1 Заголовок

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

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

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

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

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


Таблица 3 - Атрибуты элемента Header

Элемент Text является дополнительным и имеет следующий синтаксис:

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

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

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


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

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

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


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

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

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

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

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

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

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

- подстанция;

- уровень напряжения;

- присоединение.

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

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

Рисунок 10 - UML-схема секции Substation

Рисунок 10 - UML-схема секции Substation

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

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

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

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

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

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

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

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

- в пределах Substation не может быть двух элементов LNode с одинаковым сочетанием Inlnst, InClass, iedName, Idlnst и префиксом;

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

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

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

- в пределах VoltageLevel не может быть двух прямых дочерних элементов PowerTransformer с одинаковым именем;

- в пределах VoltageLevel не может быть двух прямых дочерних элементов GeneralEquipment с одинаковым именем;

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

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

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

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

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

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

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

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

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


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

- в пределах Bay не может быть двух прямых дочерних элементов PowerTransformer с одинаковым именем;

- в пределах Bay не может быть двух прямых дочерних элементов ConductingEquipment с одинаковым именем;

- в пределах Bay не может быть двух прямых дочерних элементов GeneralEquipment с одинаковым именем;

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

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

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

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

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

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

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

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

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

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


Таблица 5 - Коды типов первичных аппаратных устройств

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

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

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

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

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

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

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

Таблица 7 - Атрибуты элемента SubEquipment

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

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

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


Таблица 8 - Атрибуты элемента LNode

Имя устройства iedName идентифицирует IED-устройство, где резидентно находится LN, и Idlnst логического устройства 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. Однако соединения между единицами оборудования не определяются.

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

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

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

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

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

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

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-устройства и точки доступа

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

- длина атрибута IED Name должна составлять по меньшей мере один символ;

- IED Name для шаблона IED-устройства должно быть TEMPLATE.

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

- в пределах IED-устройства не может быть двух элементов AccessPoint (точка доступа) с одинаковым именем;

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

Элемент Services IED-устройства определяет имеющиеся сервисы.

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

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


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

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

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

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


Таблица 11 - Атрибуты элемента Access point

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

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

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

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

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

- имя не должно быть пустым.

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

- IED-устройство может быть исключительно маршрутизатором или тактовым генератором, если оно не содержит какого-либо другого элемента (главным образом сервера);

- в точке доступа к серверу может существовать дополнительная функция маршрутизатора или часов;

- в наиболее общем случае IED-устройство содержит только сервер;

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

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

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

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


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

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

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

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


Таблица 13 - Атрибуты элемента Authentication

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

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

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


Таблица 14 - Атрибуты элемента LDevice

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

- атрибут inst LD должен быть уникальным в пределах IED-устройства;

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

- длина атрибута inst должна составлять по меньшей мере один символ.

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

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


Таблица 15 - Атрибуты элемента LN0

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

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

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

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

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


Таблица 16 - Атрибуты элемента 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)

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

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


Таблица 17 - Атрибуты элемента DOI

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

Атрибут DAI содержит элементы Val (9.5.4).

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

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


Таблица 18 - Атрибуты элемента DAI

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

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

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

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


Таблица 19 - Атрибуты элемента SDI

Пример

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

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

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

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


Таблица 20 - Атрибуты элемента DataSet

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


Таблица 21 - Атрибуты элемента FCDA

Если оба атрибута - 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 следующее:

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

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


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

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

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

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

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

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

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

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


Таблица 23 - Атрибуты элемента RptEnabled

Согласно МЭК 61850-7-2 блок управления генерацией отчетов предназначен для одновременной работы только с одним клиентом. Это значит, что если задается Мах > 1 для RptEnabled, на IED-устройстве должно быть инстанцировано более одного блока управления генерацией отчетов (RCB) данного типа. Следует обратить внимание, что для всех отложенных блоков управления LN ClientLN должен быть предконфигурирован, то есть Мах должен быть тождествен заданному числу 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 и Мах. Если заданы ClientLN, индекс (положение) ClientLN в списке, размещенном в элементе RptEnabled, используется как данный номер для данного клиента (первый имеет индекс 1). Это значит, что определение блока управления генерацией отчетов на языке SCL должно рассматриваться не как экземпляр, а как тип, который может иметь 99 экземпляров для 99 клиентов.

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

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


Таблица 24 - Атрибуты элемента ClientLN

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

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

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

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

Пример

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

- различные приложения в пределах станции должны иметь уникальные значения appld. Решение о характере приложения принимает инженер проекта/системы.

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

<GSEControl name="ItlPositions" datSet="Positions" appID="Itl"/>

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

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

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

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

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


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

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

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

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

- атрибут Resv блока управления СВ должен быть установлен на логическую единицу (true).

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

Могут быть установлены следующие атрибуты:

Атрибуты элемента Smv Options (опции Smv) определены в таблице 28.


Таблица 28 - Атрибуты элемента Smv Options