Функциональные испытания в соответствии со второй редакцией стандарта МЭК 61850 Х. ДАВИДЖАК, Т. ДЮФОР, Х. ЭНГЛЕРТ Siemens AG Германия henry.dawidczak@siemens.com
Вторая редакция стандарта МЭК 61850 предоставляет новые возможности в мире автоматизации подстанций, позволяющие повысить функциональную совместимость систем, работающих по стандарту МЭК 61850. В области функционального тестирования и эксплуатационных испытаний было достигнуто значительное расширение возможностей. Для сравнения, в первой редакции стандарта МЭК 61850 определялись основные методы испытаний с базовой поддержкой функциональной совместимости систем. Первое применение в проектах выявило необходимость дополнительных испытательных возможностей и их внедрения в продуктах. В результате некоторые из указанных дополнительных возможностей были описаны в усовершенствованной версии.
Во второй редакции стандарта МЭК 61850 описаны и стандартизованы следующие испытательные возможности:
2.1 Базовая конфигурация
Далее на практических примерах будут описаны испытательные возможности. Для разработки различных испытательных возможностей была создана базовая конфигурация (Рисунок 1).
На рисунке приведена упрощенная конфигурация с использованием традиционного интерфейса процесса. В данном примере не рассматриваются устройства с интеллектуальной шиной процесса. Устройство IED1 является тестируемым устройством (DUT). Оно обменивается данными с клиентскими устройствами с использованием службы отчетов клиент- сервер, управляемые данные которого обрабатываются службами (сервисами) управления. Обмен данными с другими IED (ИЭУ) на уровне присоединения основан на технологии GOOSE по принципу соединения «точка-точка».
Для проверки различных режимов подключено испытательное оборудование. Проверяемое устройство получает измеряемые величины (токи) от стандартного трансформатора, подключенного параллельно. Сигналы отключения на катушку выключателя также передаются по параллельным проводам.
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 (тест/блокировано).
Объект данных Beh, относящийся к логическому узлу, является результатом собственного режима Mod, а также режима Mod логического устройства, к которому он принадлежит.
Объект данных «поведение» (behavior) является обязательным для всех логических узлов, а управляемый объект данных Mod является опциональным, за исключением логического узла LLN0. Наличие Mod в указанном логическом узле определяется только необходимостью обеспечения модульности/возможности установки конкретной функции в определенное состояние. В случае, если Mod отсутствует в логическом узле, то его значение для определения «поведения» логического узла считается как "on" (вкл).
2.3 Мониторинг результатов служб управления
Во всех общих классах данных CDC (МЭК61850-7-3) с управляемыми атрибутами данных дополнительно определены три опциональных атрибута данных:
Указанные атрибуты используются для мониторинга команд управления, когда они принимаются устройством (IED). Сервис команд может быть либо сервисом управления, либо GOOSE-сообщением, передающим объект данных. Это может интерпретироваться как запрос операции на управляемый объект. Атрибуты данных opRcvd, opOk и tOpOk относятся к проверке корректности функции управления, при условии, что «поведение» логического узла задано как "test/blocked" (тест/блокировано).
Основная концепция показана на рисунке 2.
Атрибут данных opRcvd (в значении ИСТИНА) показывает, был ли получен запрос управления объектом управления, то есть, будут выполнены все проверки состояния управления в соответствии с 7-2.
Атрибут данных opOk (в значении ИСТИНА) и его метка времени tOpOk показывают были ли команды приняты (то есть все проверки выполнены успешно) и исполнены («поведение» логического узла хост-системы не равно "test/blocked') или будет выполнено изменение («поведение» логического узла хост-системы равно "test/blocked') выходных сигналов, связанных с процессом.
2.4 Атрибуты данных tstEna, setSrcRef и setTstRef для проведения функциональных испытаний
Общий класс данных ORG содержит кроме всего прочего следующие атрибуты данных:
Принцип использования указанных атрибутов показан на рисунке 3.
Атрибут данных 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 точно определяет ссылку на блок управления издаваемой телеграмме, которая обрабатывается функцией диагностики.
Следующий объект данных, кроме всех прочих, будет облегчать процесс ввода в эксплуатацию системы:
Клиентское приложение для ввода в эксплуатацию может выполнять функции мониторинга указанных логических узлов. После импорта файла системной конфигурации (SCD) и идентификации широковещательной ассоциации между устройствами, клиентское приложение для ввода в эксплуатацию может подключаться к подписчикам, проверять число и достоверность логических узлов LGOS, перекрестно проверять информацию ConfigRevNum. Таким образом, оно указывает, какое ИЭУ имеет проблемы при вводе в эксплуатацию и для какой широковещательной связи (ассоциации).
2.6 Тестирование и симуляция сообщений реального времени, таких как SV и GOOSE
Как было указано ранее, во второй редакции протокола МЭК 61850 четко определены функции симуляции сообщений реального времени. Принцип симуляции состоит в допущении того, что реальный издатель (источник) и симулятор одновременно посылают в сеть одинаковые телеграммы за исключением наличия свойства симуляции у первого. На рисунке 4 показан такой случай, когда устройство объединения (MU) посылает выборочные значения на устройство контроля качества энергии и устройство защиты. При тестировании устройства защиты симулированными выборочными значениями, может появиться необходимость подачи реальных выборочных значений на устройство контроля качества.
Подписчик игнорирует симулированные телеграммы (посылки), так как он не настроен на их получение. Изменение статуса occur на уровне ИЭУ и его коммутационного аппарата доступно на управляемом объекте данных Sim, который находится в логическом узле LPHD (логический узел информации о физическом устройстве).
Для проведения симуляции достаточно иметь устройства IED SIMU и PROT. Устройство IED PROT обрабатывает выборочные значения, посылаемые устройством IED MU. Однако, выключатель, управляемый ИЭУ, останется во включенном положении, таким образом, никакая команда отключения, полученная при испытании устройства защиты, не приведет к отключению выключателя, так как устройство не будет принимать полученные сигналы отключения как тестовые.
Функция симуляции работает исключительно при широковещательной ассоциации, так как устройство-издатель не имеет информации обо всех подключениях. Устройства- подписчики работают независимо, и все получают одни и те же сообщения. Нет необходимости использовать такой подход в случае индивидуальной ассоциации, так как в этом случае речь идет об одном сервере и одном клиенте.
Принцип симуляции может быть объединен с принципом, описанным ранее, когда взаимодействуют Mod и Beh. Данные принципы совершенно не зависят друг от друга. Однако, реальный пример применения в среде шины процесса будет определять какой режим (Mod) выбирать и в каком устройстве.
Шина станции МЭК 61850
Шина станции МЭК 61850
Здесь описан пример тестирования функций защиты, включая заданные уставки. Тестируемое устройство (DUT) полностью подключено к операционной среде, за исключением направления управления первичным оборудованием. По сравнению с описанной ранее конфигурацией шины процесса, в которой для тестирования использовался флаг симуляции, «поведение» Test/Blocked и фильтрация бита качества, в традиционной конфигурации необходимо отсоединение первичного процесса (см. рисунок 6). Для этого обычно используются испытательные блоки.
Шина станции МЭК 61850
Рекомендации по проверке:
Вторая редакция стандарта МЭК 61850 предоставляет расширенные возможности для функционального тестирования. Эти методы позволяют выполнять тестирование с возможностью взаимодействия, а также расширяют возможности тестирования и вводу в эксплуатацию систем автоматизации подстанции. В стандарт были добавлены новые возможности в ответ на имеющиеся технические проблемы, а также для внедрения функциональной совместимости при выполнении проверок. Вскоре после публикации второй редакции станет доступно новое поколение сертифицированных устройств с поддержкой новых функциональных возможностей. После ознакомления с основными понятиями, включая инжиниринг, вторая редакция стандарта продолжает эволюцию автоматизации подстанций, предлагая новые способы тестирования систем автоматизации подстанций.
Никто пока не комментировал эту страницу.