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

Достаточно часто можно услышать или встретить в публикациях и докладах утверждение - «Нет синхронизации — нет ЦПС» или «Потеря временной синхронизации приводит к неправильному действию устройств релейной защиты и автоматики (РЗА) на ЦПС». Так ли оно на самом деле?

Sept. 5, 2019, 5:18 p.m. | 2043 Теквел Парк (GT)

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

  • Инструментальная синхронизация цифровых трансформаторов тока и напряжения (ЦТТН), преобразователей аналоговых сигналов (ПАС). Для указанных устройств, осуществляющих измерения токов и напряжений, инструментальная синхронизация обеспечивает единство моментов выборок мгновенных значений. Согласно СТО ПАО «ФСК ЕЭС» «Технические требования к аппаратно-программным средствам и электротехническому оборудованию ЦПС», а также проектам СТО ПАО «Россети» «Цифровые трансформаторы тока (напряжения) 6-750 кВ. Общие технические условия». Точность привязки шкалы времени ЦТТН/ПАС к внешнему серверу времени (после завершения процедуры синхронизации) должна составлять не более 1 мкс.

  • Календарная синхронизация всех других интеллектуальных электронных устройств (ИЭУ) на ЦПС, за исключением ЦТТН и ПАС. Календарная синхронизация обеспечивает единые метки времени, соответствующие астрономическому времени в стандарте UTC для всех сигналов, регистрируемых на цифровой подстанции.

Календарная синхронизация присутствует на любой современной подстанции с микропроцессорной техникой и АСУ ТП, даже если она реализована без применения стандарта МЭК 61850. А высокоточная синхронизация времени появилась на ЦПС, когда появились ИЭУ нижнего уровня ЦПС - ЦТТН и ПАС. С нарушением условий синхронизации именно этих устройств часто и связывают нарушение функционирования ЦПС и РЗА в её составе. Но не всё так однозначно.

Пример научно-технической публикации, в которой утверждается, что нарушение синхронизации времени приводит к неправильной работе РЗА

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

  • Для инструментальной (да и, впрочем, для календарной) синхронизации времени на ЦПС используется протокол PTP (Precision Time Protocol) согласно профилю IEC 61850-9-3, обеспечивающий эту синхронизацию по локальной сети Ethernet.
  • Система инструментальной синхронизации времени строится с использованием, как минимум, двух северов времени.
  • Инструментальная синхронизация времени осуществляется по резервированной сети Ethernet.
  • Система синхронизации времени поддерживает, как минимум, один из следующих глобальных источников времени (GPS/GLONASS).
  • В пакетах Sampled Values c выборочными значениями тока и напряжения, публикуемых ЦТТН/ПАС, передается признак состояния синхронизации времени SmpSynch, который может принимать три значения (Global - Глобальная синхронизация, Local - Локальная синхронизация, None - Синхронизация отсутствует).

Сценарии нарушения работы системы обеспечения единого времени

В нормальном режиме все ЦТТН/ПАС на ЦПС синхронизированы друг относительно друга и относительно глобального времени (о чём индицирует признак SmpSynch==Global в пакетах Sampled Values), а все ИЭУ ЦПС получают в цифровом формате по протоколу Sampled Values синхронизированные выборочные значения, РЗА готова к выполнению своих функций.

Рассмотрим сценарии, связанные с неисправностями в системе обеспечения единого времени:

  • Отказ основного сервера времени. Резервный сервер времени становится основным, ЦТТН/ПАС продолжают получать сигналы точного времени, они публикуют пакеты Sampled Values с признаком SmpSynch==Global, РЗА готова к выполнению своих функций.
  • Отказ основного и резервного серверов времени. ЦТТН/ПАС перестают получать сигналы точного времени. После истечения нормированного срока сохранности внутренней синхронизации (по требованиям СТО ПАО «Россети» и ПАО «ФСК ЕЭС» — не менее 30 секунд) они начинают публиковать пакеты Sampled Values с признаком SmpSynch==None, а защиты, которые используют измерения от нескольких ЦТТН/ПАС (ДЗТ, ДЗШ, ДЗО и ступенчатые защиты, использующие измерения с разных точек) автоматически блокируются (выводятся из работы). Ни в коем случае этот режим не должен приводить к неправильной работе РЗА (что должно проверяться при аттестационных или прививочных испытаниях). При этом все остальные функции РЗА (например, РЗА с относительной селективностью, получающие измерения с одного ЦТТН/ПАС) остаются в работе. Ни в коем случае этот режим не должен приводить к блокировке всех функций РЗА (что также должно проверяться при аттестационных или прививочных испытаниях). Причина такого поведения заключается в том, что уход внутреннего времени на ЦТТН/ПАС будет приводить к рассинхронизации потоков выборок мгновенных значений, а, следовательно, к появлению не соответствия взаимного расположения векторов электрических величин, вычисленных по полученным измерениям, реальному режиму, и, как следствие, к потенциально неправильной работе РЗА. Например, в дифференциальных защитах это может выражаться «ложным» током небаланса (как следствие, «ложным» дифференциальным током, превышающим величину уставки). РЗА, обрабатывающие измерения с одного ЦТТН/ПАС, не будут подвержены подобному негативному эффекту. Как только персонал восстановит работоспособность сервера времени, все ранее заблокированные защиты возвращаются в работу.
  • Отказ связи с глобальным источником времени GPS/GLONASS (обоих серверов времени). Сервера времени переходят в режим работы по внутренним часам и, по прежнему, рассылают сообщения синхронизации времени всем ИЭУ на ЦПС. В этих сообщениях также указывается статус временной синхронизации (в том числе, есть ли связь с глобальным источником времени или его нет). Отсутствие связи с глобальным источником времени распознается ЦТТН/ПАС и они начинают публиковать сообщения Sampled Values с признаком SmpSynch==Local или же идентификатором локальных часов. Никакие из объектовых функций РЗА, при условии синхронизации ЦТТН/ПАС от одних и тех же локальных часов, в этом режиме не должны блокироваться, поскольку все ИЭУ синхронизируются относительного одного и того же источника времени, что, опять же, должно проверяться при аттестационных или прививочных испытаниях.

Как видно, нарушения работы системы обеспечения единого времени (в том числе, выход из строя обоих серверов времени, что является достаточно маловероятным событием) не приводит к неправильной работе РЗА. Давайте не будем дискредитировать ЦПС! :)

Теквел Парк может обнаруживать сбои в работе системы синхронизации времени

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

Журнал событий Теквел Парк, отображающий события, связанные с нарушением синхронизации времени

Среди данных ситуаций:

  • потеря глобального источника времени (GPS/GLONASS);
  • отказ сервера времени;
  • периодическое изменение состояния признака синхронизации времени в пакетах Sampled Values, связанное с недостатками реализации ЦТТН/ПАС;
  • отказ (блокировка) всех функций РЗА в режиме локальной временной синхронизации, связанный с недостатками реализации ИЭУ;
  • отказ (блокировка) всех функций РЗА в режиме отсутствия временной синхронизации, связанный с недостатками реализации ИЭУ.

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

Latest blog posts

Transmission of data structures in a GOOSE message
Transmission of data structures in a GOOSE message

GOOSE-messaging has been covered a lot in many technical papers and to add anything valuable to the subject is rather difficult. But we will try. And functional constrained data will help us with that.

Quality Assurance requirements and experiences for GOOSE/SV configuration

The paper describes our experiences in applying quality assurance principles during the off-line SCL engineering phase independent of the engineering tool or Excel files used. These principles include requirements for inspection, visualisation and detailed analysis of the configuration of the GOOSE and SV communication all directly from the SCL files. The results of these processes are presented in regards to optimised data flow, identification of unpublished or unsubscribed GOOSE/SV, restriction of use of generic Logical Nodes and generic signal names ensuring better overall performance and reliability.

Software Based Centralized Protection: commissioning experience
Software Based Centralized Protection: commissioning experience

In 2018 Tekvel signed several contracts to commission centralized protection system based on servers and independent software. In this article we would like to share our experience and discuss some of the problems, that might require special attention from utilities on the way to mass deployment of centralized PAC systems.