R-GOOSE и R-SV: когда МЭК 61850 выходит за пределы подстанции

В МЭК 61850 GOOSE стал одним из ключевых механизмов быстрого обмена между интеллектуальными электронными устройствами. Именно GOOSE позволяет терминалам РЗА, устройствам автоматики, контроллерам присоединений и другим ИЭУ передавать друг другу события: срабатывания защит, блокировки, положения коммутационных аппаратов, команды отключения и др.

Но у классического GOOSE есть принципиальное архитектурное ограничение: это сообщение канального уровня Ethernet. Оно отлично работает внутри локальной сети подстанции, но не предназначено для маршрутизации через обычные IP-сети.

Когда обмен нужно организовать не только внутри одной подстанции, а между удалёнными объектами энергосистемы, возникает потребность в другом механизме — Routable GOOSE, или R-GOOSE.

Классический GOOSE: быстро, локально, внутри подстанции

GOOSE работает по модели publisher/subscriber: одно устройство публикует сообщение, а одно или несколько устройств-подписчиков используют его.

Типовые применения GOOSE:

• передача сигналов отключения;
• межтерминальные блокировки;
• УРОВ, ЛЗШ, АВР;
• обмен положениями выключателей и разъединителей;
• и др.

Главное достоинство GOOSE — высокая скорость и минимальная протокольная «надстройка». Сообщение передаётся непосредственно по Ethernet, на уровне L2. Это делает GOOSE удобным для задач, где важны миллисекунды.

Но это же является и ограничением: обычный GOOSE не маршрутизируется через IP-сети. Его естественная область применения — локальная технологическая сеть подстанции.

Почему появился R-GOOSE

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

Появились задачи, где сообщение должно быть передано от одного узла энергосистемы к другому или сразу к нескольким удалённым узлам:

• телеотключение/телеускорение;
• межобъектовые блокировки;
• противоаварийная автоматика;
• и др.

Для таких сценариев локального Ethernet уже недостаточно. Нужна возможность передавать события через IP-сети, включая WAN-инфраструктуру энергокомпании.

Именно здесь появляется Routable GOOSE — маршрутизируемый GOOSE.

Что такое R-GOOSE

R-GOOSE — это развитие идеи GOOSE для IP-сетей. Если классический GOOSE работает на уровне Ethernet, то R-GOOSE добавляет возможность передачи через маршрутизируемую IP-инфраструктуру.

Если упростить:

GOOSE — для быстрого обмена внутри локальной сети подстанции. R-GOOSE — для обмена через IP-сеть между удалёнными объектами.

В IEC 61850 маршрутизируемые варианты GOOSE и Sampled Values позволяют использовать модель publisher/subscriber не только в пределах одной локальной сети, но и в более широкой сетевой инфраструктуре.

Важно: R-GOOSE — это не «GOOSE, который просто летит дальше». Это другой инженерный контур: IP-маршрутизация, multicast, задержки, джиттер, QoS, отказоустойчивость, кибербезопасность и управление ключами.

А что такое R-SV

Вместе с R-GOOSE рассматривается и второй профиль — Routable Sampled Values, или R-SV.

Здесь логика похожая. Обычные Sampled Values передаются в локальной сети, например по шине процесса цифровой подстанции. Но для некоторых задач требуется передавать данные на большие расстояния.

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

Иными словами:

R-GOOSE — маршрутизируемые события. R-SV — маршрутизируемые потоковые или периодические измерительные данные.

На практике R-GOOSE обсуждается и применяется заметно чаще, потому что сценариев для удалённой передачи событий — телеотключение, блокировки, противоаварийная автоматика — больше и они понятнее для прикладных задач защиты и автоматики.

Пример 1. Телеотключение вместо ОДКЗ

Один из показательных сценариев применения R-GOOSE — передача команды телеотключения вместо использования отделителя с короткозамыкателем.

В традиционных схемах на ответвительных подстанциях или присоединениях может применяться ОДКЗ. Его задача — создать контролируемое короткое замыкание, чтобы защита на питающей стороне надёжно увидела повреждение и отключила линию.

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

R-GOOSE позволяет подойти к этой задаче иначе. Вместо того чтобы создавать искусственное КЗ, можно передать сигнал телеотключения на нужный выключатель или группу выключателей по маршрутизируемой сети.

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

Быстрое телеотключение позволяет уменьшить длительность просадки напряжения и снизить воздействие аварии на смежные участки сети. То есть R-GOOSE здесь интересен не как «новый протокол ради протокола», а как способ реализовать более аккуратную и быструю логику отключения без создания дополнительного короткого замыкания.

Пример 2. Противоаварийная автоматика

Второй важный сценарий — противоаварийная автоматика.

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

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

R-GOOSE может использоваться как транспорт для быстрого событийного обмена между объектами противоаварийной автоматики. Например:

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

В таких системах особенно важны требования к задержке, резервированию каналов, кибербезопасности и диагностике. Нельзя просто сказать: «сообщение передаётся по IP, значит всё работает». Нужно доказать, что сеть обеспечивает требуемое время доставки в нормальном режиме, при отказах и при переключениях маршрутов.

Пример 3. Векторные измерения

Ещё одна область применения маршрутизируемых профилей IEC 61850 — передача данных векторных измерений.

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

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

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

Сетевой уровень: L2 против L3

С инженерной точки зрения главное различие между GOOSE и R-GOOSE — уровень сети.

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

Безопасность: почему Secure R-GOOSE важнее, чем просто R-GOOSE

Когда GOOSE остаётся внутри изолированной технологической сети подстанции, безопасность всё равно важна: VLAN, контроль доступа, сегментация и другие мероприятия.

Но когда сообщение выходит за пределы одной подстанции, вопрос безопасности становится центральным.

Для R-GOOSE и R-SV необходимо учитывать:

• аутентификацию источника сообщения;
• целостность данных;
• защиту от подмены;
• защиту от повторной передачи старых сообщений;
• управление ключами;
• разграничение сетевых зон;
• межсетевые экраны и правила маршрутизации;
• мониторинг аномалий;
• проверку поведения при потере связи и деградации канала.

В локальной сети подстанции ошибочно опубликованный GOOSE уже может привести к серьёзным последствиям. В межобъектовой сети цена ошибки ещё выше: сообщение может запускать отключение, противоаварийное воздействие или изменение режима сразу на нескольких объектах.

Поэтому R-GOOSE нельзя рассматривать в отрыве от вопросов информационной безопасности.

Почему для multicast нужна особая модель защиты

Для классической клиент-серверной связи можно использовать привычную схему: клиент, сервер, TLS, сертификаты.

Но GOOSE, R-GOOSE, SV и R-SV работают по другой логике. Это publisher/subscriber и multicast. Одно сообщение может быть предназначено сразу нескольким подписчикам.

Значит, модель безопасности тоже должна учитывать групповую коммуникацию. Нужно определить:

• кто имеет право публиковать поток;
• кто имеет право его получать;
• какие устройства входят в группу подписчиков;
• как распространяются ключи;
• как часто они обновляются;
• что происходит при компрометации устройства;
• как вывести устройство из группы;
• как диагностировать отказ подписки из-за проблем безопасности.

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

KDC: зачем он нужен в Secure R-GOOSE и Secure R-SV

Когда мы говорим о защищённых R-GOOSE и R-SV, важно понимать: речь идёт не только о маршрутизации сообщений через IP-сеть. Речь идёт о защищённой групповой коммуникации.

GOOSE, R-GOOSE, SV и R-SV работают по модели publisher/subscriber. Одно устройство публикует поток, а несколько устройств могут быть его подписчиками. Это не классическая схема «клиент — сервер», где два участника устанавливают защищённое соединение друг с другом. Здесь один источник должен безопасно передавать сообщение группе получателей.

Именно поэтому появляется понятие Security Group — группы безопасности. В неё входят издатель и все подписчики, которые имеют право получать конкретный поток.

Например, для потока Sampled Values в такую группу могут входить:

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

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

Чтобы все участники такой группы могли проверять подлинность сообщений, а при необходимости и расшифровывать их, им нужен общий симметричный ключ. Устройство или функция, которая распределяет этот ключ между участниками группы, называется KDC — Key Distribution Center, то есть центр распределения ключей.

flowchart TB
    subgraph PKI["Инфраструктура доверия"]
        PKIICON["🏛️ PKI<br/>выдача и отзыв сертификатов"]
    end

    KDC["<b>🔐 KDC</b><br/><i>Key Distribution Center</i><br/>• проверка сертификатов<br/>• политика группы<br/>• выдача симметричных ключей<br/>• ротация (типично 24 ч)<br/>• KDA — Key Delivery Assurance"]

    PKIICON -. сертификаты .-> KDC

    subgraph SG["Security Group · поток R-GOOSE / R-SV"]
        direction LR
        PUB["<b>Издатель</b><br/>например, ПАС / ЦТ"]
        SUB1["Подписчик 1<br/>IED на удалённой ПС"]
        SUB2["Подписчик 2<br/>устройство ПА"]
        SUB3["Подписчик N<br/>WAMS / ЦУС"]
        PUB ==>|"R-GOOSE / R-SV<br/>multicast"| SUB1
        PUB ==>|" "| SUB2
        PUB ==>|" "| SUB3
    end

    KDC -. "<b>PUSH</b><br/>централизованная<br/>ротация ключа" .-> PUB
    KDC -. " " .-> SUB1
    KDC -. " " .-> SUB2
    KDC -. " " .-> SUB3
    SUB1 -. "<b>PULL</b><br/>после перезапуска<br/>или рассинхронизации" .-> KDC

    NOTE["<b>Что доставляется</b><br/>• текущий ключ<br/>• следующий ключ + время его активации<br/>• политика: алгоритм MAC, шифрование, период ротации"]
    KDC -.-> NOTE

    style KDC fill:#FDE8E8,stroke:#F56C6C,color:#B71C1C
    style PUB fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style SUB1 fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style SUB2 fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style SUB3 fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style PKIICON fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style NOTE fill:#F4F6FB,stroke:#9aa6c8,color:#3a4566

Почему используется симметричный ключ

В защищённых R-GOOSE/R-SV обязательной является аутентификация и контроль целостности сообщения. Конфиденциальность, то есть шифрование содержимого, может применяться дополнительно.

Аутентификация выполняется через вычисление специальной криптографической подписи сообщения — Message Authentication Code, или MAC. В ряде описаний используется термин HMAC, если подпись строится на основе hash-алгоритма.

Логика такая:

1. Издатель формирует сообщение.
2. По содержимому сообщения вычисляется криптографический hash.
3. Этот hash защищается с использованием симметричного ключа.
4. Получатель принимает сообщение и сам пересчитывает hash по тем же правилам.
5. Если рассчитанное значение совпадает с полученным, сообщение считается подлинным и не изменённым.

То есть подписчик может проверить, что сообщение действительно пришло от участника группы и не было подменено по пути.

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

Что именно делает KDC

KDC решает несколько задач.

Во-первых, он проверяет, имеет ли устройство право быть участником группы безопасности. Для этого используются цифровые сертификаты. Участники группы и сам KDC должны иметь доверенные сертификаты, а подлинность участника проверяется через инфраструктуру открытых ключей — PKI.

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

В-третьих, KDC управляет политикой безопасности группы. В политике могут задаваться:

• какой алгоритм MAC используется для формирования криптографической подписи;
• какой алгоритм шифрования применяется, если шифрование включено;
• как часто должен обновляться ключ;
• используется ли механизм подтверждения доставки ключей;
• когда новый ключ должен вступить в действие.

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

PUSH и PULL: два способа доставки ключей

Доставка ключей от KDC участникам группы может выполняться двумя способами: PULL и PUSH.

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

В режиме PUSH KDC сам рассылает новый ключ участникам группы. Такой режим полезен для централизованного обновления ключей, особенно в больших системах, где ручное управление ключами становится невозможным.

На практике оба механизма важны. PULL позволяет устройству восстановиться после перезапуска или проблем с ключами. PUSH позволяет KDC централизованно проводить регулярную ротацию ключей для всей группы.

Key Delivery Assurance: почему нельзя просто «сменить ключ»

В обычной IT-системе сбой обновления ключа может привести к потере доступа к сервису. В энергосистеме последствия могут быть гораздо серьёзнее: если часть устройств не получила новый ключ, они могут перестать принимать критически важные сообщения R-GOOSE или R-SV.

Для функций телеотключения или противоаварийной автоматики это недопустимо. Смена ключей не должна блокировать работу основной функции.

Поэтому применяется механизм KDA — Key Delivery Assurance. Его смысл в том, что KDC может контролировать успешность доставки ключа участникам группы. Если новый ключ успешно доставлен заданному проценту участников, KDC отправляет издателю разрешающую информацию, после чего издатель может перейти на новый ключ в установленное время.

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

Текущий и следующий ключ

Важная практическая деталь: участникам могут передаваться сразу два ключа — текущий и следующий.

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

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

Что происходит при недоступности KDC

Очень важный эксплуатационный вопрос: что будет, если KDC временно недоступен?

Для инженерных функций ответ не должен быть таким: «всё перестало работать». Если R-GOOSE используется для телеотключения или противоаварийной автоматики, временная потеря связи с KDC не должна немедленно блокировать передачу и приём технологических сообщений.

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

Но это не значит, что KDC можно считать второстепенным элементом. Его отказ должен диагностироваться, события должны регистрироваться, а эксплуатация должна понимать:

• сколько времени система может работать без связи с KDC;
• какие группы безопасности уже имеют следующий ключ;
• какие устройства не получили обновление;
• когда начнётся риск потери защищённой коммуникации;
• как восстановить синхронизацию ключей после возврата KDC.

KDC и SCL-файл

Для инженера МЭК 61850 важно, что группы безопасности не появляются из воздуха. В SCL-файлах уже содержится информация о потоках, publisher/subscriber-связях, DataSet, Control Block, адресации и подписках.

На основе этих данных можно определить, какие устройства участвуют в конкретном GOOSE, R-GOOSE, SV или R-SV обмене. Соответственно, SCL-информация может использоваться как основа для формирования групп безопасности и политики доступа.

Это важный момент для проектирования и эксплуатации: безопасность маршрутизируемых профилей должна быть связана с инженерной моделью объекта, а не настраиваться отдельно «вручную» без связи с SCD/SCD-проектом.

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

Что должен проверить инженер при внедрении Secure R-GOOSE

При внедрении Secure R-GOOSE или Secure R-SV инженер должен проверить не только факт прохождения сообщений, но и всю цепочку доверия и управления ключами.

Практический чек-лист может выглядеть так:

• определены издатель и все подписчики для каждого защищённого потока;
• для каждого потока определена Security Group;
• понятно, какие сертификаты используются устройствами и KDC;
• проверена процедура выдачи, обновления и отзыва сертификатов;
• задана политика группы: алгоритмы, ротация ключей, необходимость шифрования;
• проверены режимы PUSH и PULL;
• проверено, что устройство получает ключ после перезапуска;
• проверена работа при временной недоступности KDC;
• проверен механизм ротации ключей;
• проверено, что смена ключа не блокирует технологическую функцию;
• события KDC и ошибки ключей доступны для диагностики;
• изменения в SCD/SCL-проекте синхронизированы с группами безопасности.

Routable не значит public Internet

То, что R-GOOSE и R-SV являются маршрутизируемыми, не означает, что их следует передавать через незащищённый публичный интернет.

R-GOOSE — это не «GOOSE через интернет». Это механизм для управляемой, защищённой и инженерно рассчитанной IP-инфраструктуры энергосистемы.

Такая сеть должна обеспечивать:

• предсказуемую задержку;
• резервирование;
• контроль маршрутов;
• QoS;
• защиту от несанкционированного доступа;
• диагностику;
• мониторинг состояния каналов;
• понятную эксплуатационную ответственность.

Именно поэтому внедрение R-GOOSE — это не только задача РЗА, но и задача сетевой архитектуры, информационной безопасности и эксплуатации.

Задержки и производительность

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

Для R-GOOSE требования сложнее. Кроме времени доставки самого сообщения появляются:

• задержки маршрутизации;
• обработка multicast;
• работа WAN-каналов;
• резервирование;
• возможная криптографическая обработка;
• поведение при деградации связи;
• время восстановления после переключения маршрута.

Для мониторинговых задач часть этих задержек может быть допустима. Для телеотключения и противоаварийной автоматики — нет. Там задержка становится частью общего времени действия функции.

Поэтому при проектировании R-GOOSE нужно начинать не с вопроса «как передать сообщение», а с вопроса:

какое максимальное время доставки допустимо для этой функции?

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

Практическая разница для инженера

Для инженера РЗА и АСУ ТП различие между GOOSE и R-GOOSE можно сформулировать так:

GOOSE — это локальная задача на цифровой подстанции. R-GOOSE — это задача в пределах энергосистемы.

GOOSE требует понимания:

• SCD-файла;
• GOOSE Control Block;
• DataSet;
• VLAN и priority tagging;
• multicast MAC;
• параметров stNum, sqNum, timeAllowedToLive;
• признаков test, simulation, ndsCom;
• поведения подписчика при потере или изменении сообщения;
• и др.

R-GOOSE требует всего этого плюс:

• IP-адресации и маршрутизации;
• UDP multicast;
• multicast-инфраструктуры;
• QoS и расчёта задержек;
• резервирования WAN;
• управления ключами;
• сертификатов и групп безопасности;
• диагностики защищённых потоков;
• и др.

Где использовать GOOSE, а где R-GOOSE

flowchart TB
    START["<b>Какую функцию реализуем?</b>"]
    Q1{"Функция выходит<br/>за пределы<br/>одной подстанции?"}
    Q2{"Что передаём:<br/>событие или<br/>периодические данные?"}
    Q3{"Допустимая задержка<br/>для прикладной<br/>функции?"}

    GOOSE["<b>GOOSE</b><br/>Ethernet L2 · multicast<br/>VLAN · priority tagging<br/>SCD: GoCB · DataSet"]
    RGOOSE["<b>R-GOOSE</b><br/>IP / UDP multicast<br/>+ Secure session, KDC<br/>SCD + сетевая архитектура + ИБ"]
    RSV_MON["<b>R-SV (мониторинг)</b><br/>векторные измерения<br/>WAMS / широкозонный мониторинг<br/>главное — точная метка времени"]
    RSV_AUTO["<b>R-SV (автоматика)</b><br/>задержка, джиттер,<br/>потери — критичны<br/>отдельно проектируется WAN"]

    START --> Q1
    Q1 -- "нет, локально" --> GOOSE
    Q1 -- "да, между объектами" --> Q2
    Q2 -- "событие" --> RGOOSE
    Q2 -- "периодические измерения" --> Q3
    Q3 -- "мониторинг (десятки–сотни мс ок)" --> RSV_MON
    Q3 -- "быстродействующая автоматика" --> RSV_AUTO

    NOTE1["⚠️ R-GOOSE / R-SV ≠ публичный интернет<br/>требуется управляемая WAN-инфраструктура<br/>с QoS, резервированием и контролем маршрутов"]
    RGOOSE -.-> NOTE1
    RSV_MON -.-> NOTE1
    RSV_AUTO -.-> NOTE1

    style START fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style Q1 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style Q2 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style Q3 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style GOOSE fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style RGOOSE fill:#FBE9E7,stroke:#E64A19,color:#BF360C
    style RSV_MON fill:#EDE7F6,stroke:#7E57C2,color:#311B92
    style RSV_AUTO fill:#FDE8E8,stroke:#F56C6C,color:#B71C1C
    style NOTE1 fill:#F4F6FB,stroke:#9aa6c8,color:#3a4566

Обычный GOOSE остаётся оптимальным решением для локальных функций подстанции:

• блокировки;
• отключения;
• сигналы автоматики;
• обмен между терминалами РЗА;
• взаимодействие устройств внутри одной технологической сети;
• замена медных цепей внутри объекта.

R-GOOSE нужен там, где функция выходит за границы одной подстанции:

• телеотключение между объектами;
• противоаварийная автоматика;
• передача событий между подстанциями и электростанциями;
• взаимодействие с удалёнными объектами распределённой генерации;
• межобъектовая логика управления режимом.

R-SV может быть интересен для задач передачи измерительных данных через WAN, особенно если речь идёт о векторных измерениях и распределенном мониторинге.

Что это меняет для эксплуатации цифровых подстанций

Для эксплуатации цифровых подстанций появление R-GOOSE и R-SV означает, что граница ответственности инженера расширяется.

Раньше достаточно было понимать, что происходит в пределах шины станции или шины процесса одной подстанции. Теперь для ряда задач нужно понимать ещё и межобъектовую сеть:

• через какие маршрутизаторы проходит сообщение;
• как построен multicast;
• какие задержки допустимы;
• где находятся издатель и подписчики;
• как защищён поток;
• кто управляет ключами;
• что будет при отказе канала;
• как система поведёт себя при деградации связи;
• как зафиксировать и доказать корректную работу в испытаниях.

Это уже не только «цифровая подстанция» в узком смысле. Это цифровая коммуникационная инфраструктура энергосистемы.

Вывод

GOOSE остаётся базовым и эффективным механизмом быстрого событийного обмена внутри цифровой подстанции.

R-GOOSE расширяет эту идею на маршрутизируемые IP-сети и позволяет строить межобъектовые функции: телеотключение, противоаварийную автоматику, межобъектовые блокировки и другие сценарии, где событие от одного узла должно быстро и безопасно попасть к нескольким удалённым подписчикам.

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

Но главный вывод состоит в другом: R-GOOSE и R-SV — это не просто «GOOSE и SV через IP». Это защищённые маршрутизируемые коммуникационные профили, которые требуют новой инженерной дисциплины: расчёта задержек, проектирования multicast, управления ключами, применения механизмов кибербезопасности и обязательной проверки поведения системы в нормальных и аварийных режимах.

KDC в такой архитектуре — не просто «сервер ключей» где-то в сети. Он связывает между собой инженерную модель IEC 61850, состав publisher/subscriber-групп, цифровые сертификаты устройств, симметрические ключи, политику ротации и эксплуатационную готовность защищённой коммуникации.

Именно поэтому при обсуждении R-GOOSE важно задавать не вопрос «можно ли передать GOOSE дальше?», а совсем другой:

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

Только после ответа на эти вопросы R-GOOSE становится не красивым термином из стандарта, а рабочим инструментом цифровой энергосистемы.