Исторически сложилось, что самой распространенной схемой каналов является «точка-точка».
Для команд ПА, которые передаются между большим числом объектов в пределах всей энергосистемы, организуется их переприем между УПАСК на промежуточных ПС.
Проблема: с развитием систем ПА требуется все большее число УПАСК, и с ростом числа переприемов команд ПА значительно увеличивается общее время их передачи и затрудняется обеспечение системной надежности.
Сегодня по ЦСС реализованы не только каналы передачи команд РЗА по схемам «точка-точка», но и уже несколько лет эксплуатируются каналы по схемам «точка-многоточка» без переприемов команд РЗА как между УПАСК, так и в самих УПАСК (переприем команд РЗА в УПАСК снижает системную надежность по сравнению с переприемом в оборудовании ЦСС).
Сегодня по ЦСС реализованы не только каналы передачи команд РЗА по схемам «точка-точка», но и уже несколько лет эксплуатируются каналы по схемам «точка-многоточка» без переприемов команд РЗА как между УПАСК, так и в самих УПАСК (переприем команд РЗА в УПАСК снижает системную надежность по сравнению с переприемом в оборудовании ЦСС).
В настоящее время для передачи команд по схемам «точка-точка» и «точка-многоточка» УПАСК используют специально разработанные их производителями проприетарные протоколы, которые учитывают особенности ЦСС (SDH/PDH, MPLS и других) как среды передачи цифровой информации.
Специальные проприетарные протоколы не только обеспечивают соответствие УПАСК общим международным и российским требованиям, а именно
- время передачи отключающих команд РЗА может превысить 10 мс с вероятностью не более 10-4 при коэффициенте битовых ошибок 10-6 в канале между ПС (без учета задержки в канале по ЦСС),
- и вероятность приема ложной отключающей команды РЗА должна быть не более 10-8 при любом коэффициенте битовых ошибок в канале между ПС, но и обеспечивают функциональность, определяемую спецификой каналов между ПС по ЦСС.
Сегодня УПАСК выполняют обмен командами РЗА по дискретным входам/выходам, но с внедрением цифровых ПС на базе МЭК 61850 в них осуществим переход на обмен по GOOSE сообщениям, где УПАСК начнут играть роль шлюза между шиной ПС и ЦСС.
Единственный недостаток: использование специальных проприетарных протоколов не позволяет применять на разных концах канала УПАСК разных производителей.
GOOSE были разработаны для передачи только по локальным сетям внутри ПС, и их передача по каналам связи между ПС не предполагалась.
Туннелирование для передачи GOOSE сообщений требует организации каналов Ethernet уровня L2.
По каналам IP/Ethernet уровня L3 использование туннелирования для передачи GOOSE сообщений не возможно, т.к. маршрутизаторы IP сетей игнорируют Ethernet кадры, не содержащие IP пакеты.
R-GOOSE сообщение является модификацией GOOSE, осуществляемой добавлением UDP/IP заголовка для возможности передачи по IP сетям.
UDP позволяет осуществлять многоадресную рассылку → R-GOOSE сообщения потенциально могут быть применены для передачи команд РЗА между ПС как по схемам «точка-точка», так и «точка-мноточка» теоретически с использованием в канале УПАСК разных производителей GOOSE изначально не были предназначены для передачи по каналам между ПС → R-GOOSE сообщения унаследовали все недостатки GOOSE сообщений.
Одна команда РЗА – это один бит полезной информации
В специальных проприетарных протоколах для передачи 8 команд с вероятностью приема ложной команды не ниже требуемой 10-8 может быть использован, например, прием двух последовательных сообщений о командах длиною по 8 байт (общая длина посылки 16 байт = 128 бит) → эффективность использования доступной полосы канала между ПС (число команд РЗА деленное на общее число бит в посылке) – 6.25 %.
Согласно российским и зарубежным (ITU-T G.826) нормам неготовность канала связи по ЦСС наступает только после 10 последовательных секунд с коэффициентом ошибок не менее 10-3.
Специальные проприетарные протоколы в УПАСК осуществляют непрерывную передачу по каналу сообщений о командах РЗА → возможность обеспечения непрерывного мониторинга состояния и пропускной способности каналов связи по ЦСС.
Применение приведенного механизма для передачи R-GOOSE сообщений по каналу между.
ПС приводит к следующим проблемам:
- приемник не может зафиксировать ошибки в канале и его кратковременные прерывания, произошедшие между передачей R-GOOSE сообщений, → деградация канала связи между ПС может остаться незамеченной
- при уменьшении пропускной способности канала R-GOOSE сообщения будут продолжать приниматься приемником → если по какой-либо причине пропускная способность канала между ПС будет уменьшена, это не будет замечено.
При работе УПАСК по ВЧ трактам и выделенным ОВ задержка в среде распространения сигналов может быть легко оценена и стабильна.
При работе УПАСК по ЦСС задержка может существенно изменяться при переключении на другой маршрут.
В специальных протоколах, используемых сейчас в УПАСК, задержка канала между ПС измеряется методом эхо- сигнала (при этом не требуется синхронизация часов УПАСК на разных ПС от ГЛОНАСС/GPS, к надежности работы которой для целей РЗА имеются обоснованные нарекания).
Измерение задержки R-GOOSE возможно только при синхронизации часов на разных ПС от ГЛОНАСС/GPS и наличии в R-GOOSE метки времени UTC, что существенно увеличивает их длину
→ повышение требований к пропускной способности каналов между ПС и еще большее снижение и без того невысокой надежности передачи команд РЗА
В R-GOOSE отсутствуют надежные механизмы, позволяющие производить измерение задержки в канале между ПС → если по какой-либо причине канал будет переключен на маршрут в ЦСС c недопустимо большой задержкой для передачи команд РЗА, то это не будет замечено.
R-GOOSE сообщения для передачи команд РЗА имеют только одно достоинство: теоретически их использование позволит устанавливать на разных концах канала устройства разных производителей.
R-GOOSE сообщения по сравнению со специальными проприетарными протоколами, которые используются сейчас в УПАСК, имеют много существенных недостатков для передачи команд РЗА → перспектива их использования с целью обеспечения совместимости на канальном уровне устройств разных производителей крайне сомнительна.
С технической, но не организационной, точки зрения для обеспечения совместимости на канальном уровне устройств разных производителей при реализации передачи команд РЗА между ПС по ЦСС значительно более предпочтительной по сравнению с применением R- GOOSE сообщений является разработка и стандартизация специального протокола.
В.А. Харламов, С.Е. Романов, А.Х. Хасанов ООО «Юнител Инжиниринг» Россия