Испытания в соответствии со второй редакцией МЭК 61850

PS3 - S7-05

Функциональные испытания в соответствии со второй редакцией стандарта МЭК 61850

Х. ДАВИДЖАК, Т. ДЮФОР, Х. ЭНГЛЕРТ Siemens AG Германия henry.dawidczak@siemens.com

КЛЮЧЕВЫЕ СЛОВА

МЭК 61850, система автоматизации подстанции, тестирование, наладка, обмен данными.

1 ВВЕДЕНИЕ

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

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

1. Использование объекта данных Behavior "Beh" соответственно его значению ""test" (тестирование) и "test/blocked" (тест/блокировано).
2. Были введены новые атрибуты данных "opRcvd", "opOk", "tOpOk" во всех управляемых общих классах данных (Common Data Classes) для мониторинга результатов служб управления.
3. Для функциональных испытаний введены новые объекты данных для ссылок на поступающий поток данных, а также новые атрибуты данных "tstEna", "setSrcRef" и "setTstRef" для ссылок на входные данные.
4. Представление поля данных Simulation bit в SV (выборочные значения) и GOOSE - сообщениях в соответствии со разделами стандарта 61850-8-1 и 9-2.
5. Бит качества "q" со значением "Test" (тестирование) для оценки или селективной обработки результатов испытаний способом, обеспечивающим функциональную совместимость.
6. Использование сервисного параметра "Test" в командах управления способом, обеспечивающим функциональную совместимость.
7. Функционал диагностика и протоколирования с помощью логического узла Tracking "LTRK" для регистрации любых запрашиваемых из ИЭУ (IED) сервисов.
8. Функционал диагностики для подписок GOOSE и SV с описанием логических узлов LGOS/LSVS.

2 ИСПОЛЬЗОВАНИЕ ИСПЫТАТЕЛЬНЫХ ВОЗМОЖНОСТЕЙ ВТОРОЙ РЕДАКЦИИ СТАНДАРТА МЭК 618502.1 Базовая конфигурация

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

На рисунке приведена упрощенная конфигурация с использованием традиционного интерфейса процесса. В данном примере не рассматриваются устройства с интеллектуальной шиной процесса. Устройство IED1 является тестируемым устройством (DUT). Оно обменивается данными с клиентскими устройствами с использованием службы отчетов клиент- сервер, управляемые данные которого обрабатываются службами (сервисами) управления. Обмен данными с другими IED (ИЭУ) на уровне присоединения основан на технологии GOOSE по принципу соединения «точка-точка».

DUT = Тестируемое устройство

Рис. 1: Базовая конфигурация испытательной системы

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

2.2 Объект данных "Beh" (behavior) логических узлов

Объект данных "Beh" (behavior=поведение), относящийся к логическому узлу, отображает режим обмена данными в соответствии с изменением его входов, выходов, внутренних состояний, а также параметров логического узла и сервисов обмена данными.

Поведение "Beh" может быть изменено воздействием на объект данных "Mod" (Режим). Режим представляет собой управляемые перечисляемые данные (ENC).

Объект данных "Beh" является перечисляемым объектом (CDC ENS), со следующими возможными значениями: on (вкл) , on-blocked (вкл-блокировано), test (тест), test/blocked (тест/блокировано), и off (выкл) (см. МЭК61850-7-4). К режиму тестирования относятся состояния on (вкл), test (тест) и test/blocked (тест/блокировано).

1. on (вкл) - Логический узел функционирует в нормальном режиме, то есть все его службы обмена данными находятся в работе и получают обновленные значения от приложения, которое данный логический узел представляет. Приложение отклоняет все входящие данные и входящие запросы с битом качества = test (тест).
2. test (тест) - Приложение, представляемое данным логическим узлом, выполняется. Службы обмена данными находятся в работе и получают обновленные значения. Все объекты данных, выданные этим логическим узлом (LN) будут иметь дополнительный бит качества = test (тест). Приниматься будут только команды управления с битом качества = test (тест), а все остальные будут отвергаться (отрицательный ответ с указанием причины Blocked-by-Mode).
3. test/blocked (тест/блокировано) - Приложение, представляемое данным логическим узлом (LN), выполняется, но если логический узел является «узлом-постояльцем» (boarder LN) (физический интерфейс процесса), то процессу не будут переданы никакие выходные данные (например, не будет воздействия на выходные реле). Все службы обмена данными находятся в работе и получают обновленные значения. Все данные, выданные этим логическим узлом (LN) будут иметь дополнительный бит качества = test (тест). Приниматься будут только команды управления с битом качества = test (тест), а все остальные будут отвергаться (отрицательный ответ с указанием addCause = Blocked-by-Mode). Следует иметь в виду, что логический узел, «поведение» которого блокировано режимом теста, не будет передавать процессу никакие выходные команды. Следовательно, все циклы управления будут квитированы с отрицательным откликом и причиной addCause = "blocked-by-mode" (без воздействий на уровень процесса). Однако, логический узел выдаст уведомление о выданной команде на уровень процесса, если имеется разрешение от Beh. Это условное различение отображается позже с использованием атрибутов данных opOk и tOpOk.

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

Объект данных «поведение» (behavior) является обязательным для всех логических узлов, а управляемый объект данных Mod является опциональным, за исключением логического узла LLN0. Наличие Mod в указанном логическом узле определяется только необходимостью обеспечения модульности/возможности установки конкретной функции в определенное состояние. В случае, если Mod отсутствует в логическом узле, то его значение для определения «поведения» логического узла считается как "on" (вкл).

2.3 Мониторинг результатов служб управления

Во всех общих классах данных CDC (МЭК61850-7-3) с управляемыми атрибутами данных дополнительно определены три опциональных атрибута данных:

1. opRcvd (operate command received=команда управления получена), (тип Булевый)
2. opOk (operate command evaluated and accepted=команда управления оценена и принята) (тип Булевый) и
3. tOpOk (метка времени атрибута данных opOk).

Указанные атрибуты используются для мониторинга команд управления, когда они принимаются устройством (IED). Сервис команд может быть либо сервисом управления, либо GOOSE-сообщением, передающим объект данных. Это может интерпретироваться как запрос операции на управляемый объект. Атрибуты данных opRcvd, opOk и tOpOk относятся к проверке корректности функции управления, при условии, что «поведение» логического узла задано как "test/blocked" (тест/блокировано).

Основная концепция показана на рисунке 2.

Атрибут данных opRcvd (в значении ИСТИНА) показывает, был ли получен запрос управления объектом управления, то есть, будут выполнены все проверки состояния управления в соответствии с 7-2.

Атрибут данных opOk (в значении ИСТИНА) и его метка времени tOpOk показывают были ли команды приняты (то есть все проверки выполнены успешно) и исполнены («поведение» логического узла хост-системы не равно "test/blocked') или будет выполнено изменение («поведение» логического узла хост-системы равно "test/blocked') выходных сигналов, связанных с процессом.

Рис. 2: Концепция мониторинга результата сервиса управления

2.4 Атрибуты данных tstEna, setSrcRef и setTstRef для проведения функциональных испытаний

Общий класс данных ORG содержит кроме всего прочего следующие атрибуты данных:

1. setSrcRef (заданная ссылка на источник)
2. setTstRef (заданная ссылка на испытание)
3. tstEna (ввод режима теста) (Булевый тип)

Принцип использования указанных атрибутов показан на рисунке 3.

Рис. 3: Использование атрибутов CDC ORG для функциональных испытаний

Атрибут данных InRefl.setSrcRef определяет связанный объект данных информации при нормальной работе, то есть отношение между источником (выходные данные логического узла) и приемник (входные данные логического узла) информации. Связанная информация может находиться в том же самом логическом устройстве, внутри того же ИЭУ или даже внутри другого ИЭУ. После задания значения атрибута setTstRef, режима тестирования, установки tstEna в значение TRUE (ИСТИНА), можно включить специальный источник данных. С помощью указанного способа источник данных как бы «перемонтируется». «Перемонтирование» представляет практический интерес, когда выходное значение нового объекта данных может быть изменено и, следовательно, обеспечивает новый входной сигнал для проверяемого логического узла (функции).

Дополнительно могут рассматриваться условия оперативных блокировок. В базовой конфигурации (см. рисунок 1) логический узел CILO тестируемого объекта (DUT) получает информацию от других ИЭУ, включая положение и статус коммутационных аппаратов по технологии GOOSE. На основе принимаемых данных проверяется возможность формирования сигнала разрешения отключения (EnaOpn) и его посылки контроллеру аппарата (CSWI). В процессе испытания отношения между оригинальными источниками могут меняться, например, испытательное оборудование (генератор тестовых сигналов) в свою очередь может посылать данные. Функция оперативных блокировок обрабатывает всю полученную информацию и выдает результаты работы логики блокировок. Кроме того, команда тестового управления может инициироваться контроллером подстанции. Если граничный логический узел XCBR находится в режиме test/blocked, то высоковольтный коммутационный аппарат защищен от воздействий. Правильность работы цикла управления может быть проверена на базе использования атрибутов opOk и opRecvd. Если все участвующие логические узлы посылают свою информацию с битом качества ="test", то может быть сформирован специальный журнал тестирования на базе фильтрации по данному значению.

2.5 Мониторинг подписки выборочных значений (SV) и GOOSE-сообщений

В первой редакции стандарта не было стандартного способа обеспечения проведения наладки подписки GOOSE. В PIXIT описывается как протестировать/проверить «поведение» ИЭУ в случае сбоя подписки GOOSE.

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

И снова, первые опыты применения показали необходимость стандартизированной функции диагностики подписки для общего случая применения. В настоящее время стандарт МЭК 61850-7-4 дает определение логическим узлам LGOS (подписка GOOSE) и LSVS (подписка выборочных значений). Для устройств, поддерживающих диагностику GOOSE и выборочных значений, на каждую подписку будет приходиться по одному экземпляру логического узла. Задание объектов данных GoCBRef и SvCBRef точно определяет ссылку на блок управления издаваемой телеграмме, которая обрабатывается функцией диагностики.

Следующий объект данных, кроме всех прочих, будет облегчать процесс ввода в эксплуатацию системы:

1. St -если задан как true (ИСТИНА), указывает на активность подписки, то есть наличие входящих GOOSE-телеграмм.
2. SimSt - если задан как true (ИСТИНА), указывает на прием сообщений по подписке для целей симуляции, то есть сообщений, выданных симулятором сообщений для тестирования системы. В следующем параграфе будет описано, когда и каким образом выполняется симуляция.

Клиентское приложение для ввода в эксплуатацию может выполнять функции мониторинга указанных логических узлов. После импорта файла системной конфигурации (SCD) и идентификации широковещательной ассоциации между устройствами, клиентское приложение для ввода в эксплуатацию может подключаться к подписчикам, проверять число и достоверность логических узлов LGOS, перекрестно проверять информацию ConfigRevNum. Таким образом, оно указывает, какое ИЭУ имеет проблемы при вводе в эксплуатацию и для какой широковещательной связи (ассоциации).

2.6 Тестирование и симуляция сообщений реального времени, таких как SV и GOOSE

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

Подписчик игнорирует симулированные телеграммы (посылки), так как он не настроен на их получение. Изменение статуса occur на уровне ИЭУ и его коммутационного аппарата доступно на управляемом объекте данных Sim, который находится в логическом узле LPHD (логический узел информации о физическом устройстве).

Для проведения симуляции достаточно иметь устройства IED SIMU и PROT. Устройство IED PROT обрабатывает выборочные значения, посылаемые устройством IED MU. Однако, выключатель, управляемый ИЭУ, останется во включенном положении, таким образом, никакая команда отключения, полученная при испытании устройства защиты, не приведет к отключению выключателя, так как устройство не будет принимать полученные сигналы отключения как тестовые.

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

Принцип симуляции может быть объединен с принципом, описанным ранее, когда взаимодействуют Mod и Beh. Данные принципы совершенно не зависят друг от друга. Однако, реальный пример применения в среде шины процесса будет определять какой режим (Mod) выбирать и в каком устройстве.

Шина станции МЭК 61850

Рис. 4: Нормальная работа (зеленым цветом показано «поведение», черным - SV) и симуляция (оранжевый цвет) в случае широковещательной ассоциации

Шина станции МЭК 61850

Рис. 5: Использование Mod в среде симуляции

3 ПРОВЕРКА ФУНКЦИЙ ЗАЩИТЫ

Здесь описан пример тестирования функций защиты, включая заданные уставки. Тестируемое устройство (DUT) полностью подключено к операционной среде, за исключением направления управления первичным оборудованием. По сравнению с описанной ранее конфигурацией шины процесса, в которой для тестирования использовался флаг симуляции, «поведение» Test/Blocked и фильтрация бита качества, в традиционной конфигурации необходимо отсоединение первичного процесса (см. рисунок 6). Для этого обычно используются испытательные блоки.

Шина станции МЭК 61850

Рис. 6: Тестирование функций защиты и задания уставок в традиционной конфигурации

Рекомендации по проверке:

1. Реле защиты переключается в режим ТЕСТ, то есть все логические узлы данной проверочной конфигурации должны быть в режиме Тест (дополнительно для XCBR необходимо условие: TEST/BLOCKED).
2. Для блокирования первичного оборудования от сигналов отключения и отделения аналоговых входов от первичных ТТ и ТН вставляется испытательный блок.
3. Включается испытательное оборудование для симуляции аналоговых сигналов.
4. Проверка может быть начата подачей токов от испытательного оборудования.
5. Функция защиты выдаст информацию о пуске (PTOC.Str) и срабатывании (PTOC.Op) на логический узел PTRC (Логика отключения).
6. Узел PTRC генерирует сигнал отключения TRIP, и логический узел выключателя сформирует сигнал отключения на клеммы реле, если для узла XCBR не задано Beh=TEST/BLOCKED.
7. Дополнительно, испытательный блок отделяет реле от первичного оборудования (выключателя), тем самым предотвращая выдачу на него команды.
8. Все данные о тестировании защиты могут передаваться клиенту. Клиент фильтрует данные с флагом quality=TEST и сохраняет их в специальном журнале регистрации. Также регистрируются данные о результате отключения выключателя с помощью opRcvd, opOk, tOpOk.
9. И, наконец, последовательность отключения оборудования от тестовой конфигурации:
10. сначала, отсоединить испытательное оборудование,
11. затем извлечь испытательный блок и

- изменить «поведение» в логическом узле реле защиты на ON (ВКЛ). Итак, подводя итоги - В данном примере проверки были использованы следующие средства:

«Поведение» TEST и TEST/Blocked, бит качества = TEST и данные от XCBR.Pos.opRcvd, XCBR.OpOk/tOpOk. Дополнительно, для отделения проверяемого устройства от первичного оборудования необходимо наличие испытательного блока.

4 ЗАКЛЮЧЕНИЕ

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

ЛИТЕРАТУРА

1. МЭК 61850: «Коммуникационные сети и системы на подстанциях», редакция 1, 2004.
2. МЭК 61850: «Коммуникационные сети и системы для автоматизации электрических

сетей», Редакция 2, 2011.