Привет, Хабр! Когда‑то у нас выходил материал по применению протокола SV на электроэнергетических объектах, в котором мы обещали разбор протокола GOOSE. Итак, время пришло.

В этом материале напомним читателям, зачем нужен этот протокол, кто его использует, как выглядят и из чего состоят GOOSE‑сообщения. Покажем пример обмена устройствами таким трафиком, а также как, имея программно‑аппаратный комплекс для моделирования в реальном времени, создать модель энергосистемы и провести опыт моделирования GOOSE‑spoofing атаки на защищающие ее терминалы РЗА.

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

Что за GOOSE

Для начала немного теории. Если мы обратимся к корпоративному профилю МЭК 61 850 ПАО «ФСК ЕЭС», то протокол GOOSE (Generic Object — Oriented Substation Event) используется для быстрой передачи данных о событиях между интеллектуальными электронными устройствами по локальной вычислительной сети. Под интеллектуальными электронными устройствами (ИЭУ) понимаются терминалы РЗА, контроллеры присоединений (КП), преобразователи дискретных сигналов (ПДС), некоторые измерительные устройства. Фактически данный протокол служит для замены медных кабельных связей, предназначенных для передачи дискретных (но не обязательно) сигналов между устройствами. Под событиями в определении понимаются срабатывания и пуски устройств РЗА, изменения положения коммутационного оборудования и так далее. Даже измерения с датчика температур для работы противоаварийной автоматики можно передать через GOOSE, так как не требуется такой большой частоты передачи измерений, как для тока или напряжения по SV.

Процесс передачи GOOSE

Раз мы упомянули про частоту передачи сообщений, то нужно пояснить, как идет процесс обмена сообщениями. Обмен сообщениями происходит по ЛВС — в стандартной архитектуре это шина станции/подстанции и на канальном уровне, что обеспечивает высокую скорость передачи данных. Устройства общаются с помощью механизма «Издатель — Подписчик», то есть используют multicast‑потоки.

Устройство‑издатель отправляет GOOSE‑сообщение на шину, а подписчики его получают, причем получают все устройства в сети (или виртуальной сети, но об этом чуть позже), а не только подписанные. По сути, устройства принимают все сообщения, но обрабатывают только те, на которые подписаны, остальные отбрасываются.

Сами сообщения передаются в нормальном режиме с постоянным интервалом времени Т0, который измеряется в секундах и может быть достаточно большим. То есть поток GOOSE‑сообщений постоянно передает набор данных, отражающий состояние устройства и контролируемого оборудования. Например, устройство РЗА передает состояние сигнала срабатывания, которое равно логическому 0 в нормальном режиме. Далее рассмотрим процесс передачи сообщений, как это описано в МЭК 61 850–8–1. Как только происходит событие, например короткое замыкание с последующей работой защит с изменением передаваемых данных в потоке GOOSE‑сообщений с 0 на 1, происходит отправка нового сообщения в независимости от того, закончился период Т0 или нет. Следующие сообщения приходят с минимальным интервалом передачи Т1, который с последующими сообщениями увеличивается до Т2 и Т3, пока не придет к значению Т0. Тот же процесс повторится при изменении с 1 на 0 того же сигнала.

Временные интервалы и количество сообщений являются настраиваемыми параметрами. Например, по корпоративному профилю МЭК 61850 ПАО «ФСК ЕЭС» после сообщения при возникновения события идет еще четыре с минимальным временем, а затем до восстановления нормального режима генерируются еще три сообщения с увеличением интервала в два раза.

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

Как выглядит GOOSE-сообщение

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

Итак, начнем разбор полей по порядку с самого начала кадра.

Поля канального уровня:

Preamble длиной 8 байт находится в самом начале Ethernet кадра. Преамбула сообщает получателю о необходимости подготовиться к поступлению кадра. 

Destination Address длиной 6 байт содержит MAC-адрес получателя. Как раз этот адрес определяет используемый в GOOSE режим многоадресной рассылки-multicast. Для данного поля используется стандартизованный диапазон адресов в рамках одного объекта 01:0C:CD:01:00:00-01:0C:CD:01:01:FF, однако он может быть расширен до 01:0C:CD:01:03:FF.

Source Address длиной 6 байт содержит MAC-адрес отправителя, то есть устройства – источника сообщений.

Priority tagging/Virtual LAN длиной 4 байта для разметки приоритета в соответствии с IEEE 802.1Q. Используется для разделения критического по времени и высокоприоритетного трафика шины от низкоприоритетной нагрузки на шину. А также деления нашей шина на виртуальные для управления трафиком. 

Поле TPID (Tag Protocol Identifier) указывает тип Ethertype, назначенный для кадров типа Ethernet 802.1Q и должно быть равно 0x8100.

Поле TCI (Tag Control Information) состоящее из: User Priority – того самого приоритета, который равен значению 4 (GOOSE и SV – крайне важная информация и трафик с высоким приоритетом), CFI – флаг канонического формата и равен 0, VID – идентификатор виртуальной сети.

Ethertype длиной 2 байта указывает тип протокола (0x88b8 для GOOSE).

APPID длиной 2 байта – идентификатор приложения – для выбора кадров, содержащих GOOSE. Диапазон зарезервированных значений для GOOSE Type 1 составляет от 0x0000 до 0x3FFF, для GOOSE Type 1A диапазон зарезервированных значений составляет от 0x8000 до 0xBFFF. Про классификацию сообщений можно подробнее почитать в МЭК61850-8-2 или ПАО «ФСК ЕЭС».

Length длиной 2 байта содержит значение количества байт, начиная с поля APPID до конца блока APDU.

Reserved 1 длиной 2 байта содержит S (simulated) бит, устройство в режиме теста, когда равен 1, три R бита, зарезервированных для будущего и двенадцать зарезервированных битов безопасности, которые должны использоваться, когда передается GOOSE с защитой, в противном случае он должен быть установлен в 0.

Reserved 2 длиной 2 байта полностью зарезервирован под безопасность.

Frame check sequence длиной 4 байта со значением контрольной суммы для проверки целостности данных при передаче.

Поля прикладного уровня

Тут нужно сделать небольшое отступление и дать объяснение тому, как кодируются дальнейшие поля в APDU. Все поле – это набор байт, где первый байт это Tag или Тип, далее идут байты со значением длины (Length) полезной информации в триплете, а затем и сами полезные данные (Value). Value тоже в свою очередь может быть триплетом.

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

Итак, кодируя число 127 формата INT32U, мы можем использовать фиксированный вариант кодировки и получим триплет 0x86 0x05 0x00 0x00 0x00 0x00 0x7f, а можем использовать плавающую длину и получить триплет 0x86 0x01 0x7f. При этом информация останется одной и той же. И тот и другой способ имеет свое применение.

Перейдем к нашим полям (кстати, их длина указана на диаграмме сверху):

goCBRef — ссылка на блок управления GOOSE — это уникальное имя пути к экземпляру блока управления GOOSE (goCB) в узле LLN0. Формат — LDName/LLN0.GoCBName, например, GEDeviceF650/LLN0gcb01, где имя LD — GEDeviceF650, класс LN — LLN0 (нулевой логический узел), функциональное ограничение — GO (управление GOOSE), а экземпляр goCB — gcb01. Длина поля может быть разной в зависимости от конфигурации.

timeAllowedtoLive – информирует подписчиков о том, как долго ждать следующего повторения сообщения.

datSet – ссылки на набор данных, значения элементов которого необходимо передать, например, GEDeviceF650/LLN0$GOOSE1. Длина поля может быть разной в зависимости от конфигурации.

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

t – время, когда атрибут stNum был увеличен.

stNum (номер состояния) — это счетчик, который увеличивается каждый раз, когда обнаруживается изменение значения в наборе данных. Начальное значение должно быть 1. Значение 0 зарезервировано.

sqNum – текущий порядковый номер отчетов. Он должен увеличиваться каждый раз при отправке сообщения GOOSE. После изменения stNum счетчик sqNum должен быть установлен на значение 0. Начальное значение для sqNum при передаче равно 1.

simulation – если оно истинно, сообщение и, следовательно, его значение были выданы модулем моделирования и не являются реальными значениями.

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

ndsCom – указывает в сообщении, что требуется некоторая пуско-наладка. Если TRUE – требует дальнейшей настройки.

numDatSetEntries – количество элементов в наборе данных.

allData – список информации, передаваемой в сообщении в соответствии с конфигурацией. Как раз тут и закодированы все сигналы, которые мы хотим передать от одного устройства к другому (срабатывания, пуски, положения, качество этих сигналов и т.д.).

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

Моделирование GOOSE-спуфинга

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

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

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

Для проведения моделирования GOOSE-спуфинг атаки на терминал РЗА в нашей лаборатории был собран испытательный стенд на базе КПМ РИТМ:

В испытаниях участвуют два терминала РЗА: первый выполняет функции дистанционной защиты линии электропередачи, а второй – функции автоматики управления выключатем. Оба терминала общаются между собой по GOOSE по шине станции. Терминал защит передает в терминал автоматики управления выключателем сигнал отключения. КПМ РИТМ в стенде выступает в роли цифрового двойника энергосистемы с функциями моделирования GOOSE-спуфинга. 

Модель энергосистемы собрана в MATLAB/Simulink из блоков библиотеки Simscape Power Systems. Наши испытуемые терминалы защищают линию Л2 и получают с ее конца измерения тока и напряжения. Данные измерения с помощью интерфейса ЦАП передаются на усилитель и идут к терминалам. Также в модели реализован прием сигнала срабатывания через «сухой» контакт, который идет на изменение положения выключателя в модели. При этом в терминал управления выключателем приходит сигнал положения выключателя из модели. Дополнительно в модель добавлены функции АПВ и защиты противоположного конца рассматриваемой линии электропередачи.

Для моделирования GOOSE-спуфинга в модель были добавлены специальные блоки для перехвата и подмены GOOSE-трафика. Эти блоки были специально разработаны для совместной работы с РИТМ и MATLAB/Simulink, с помощью них и платы Ethernet комплекса можно принимать и раскодировать трафик, а затем составлять GOOSE-сообщения для отправки в сеть.

В рамках опыта смоделируем GOOSE-спуфинг атаку на терминал управления выключателем и сделаем три несложных сценария: 

• моделирование КЗ и анализ штатной работы защит;

• моделирование GOOSE-спуфинга и последующего КЗ, при этом увидим отказ работы терминала;

• без КЗ отправим ложный сигнал отключения от терминала защит.

Для удобства будем отслеживать трафик в шине процесса с помощью Wireshark, а процессы в сети будем наблюдать цифровыми осциллографами в модели и на терминалах.

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

Спуфинг активируется по команде в модели, в этот момент происходит перехват трафика, его подмена и отправка ложно трафика в сеть параллельно настоящему. При этом в ложном трафике идет увеличение значения поля stNum (помним по теории), таким образом ложный трафик становится более актуальным для терминала, чем настоящий. В таком случае при возникновении КЗ в сети терминал дистанционной защиты фиксирует повреждение и отправляет сигнал срабатывания на терминал управления выключателем, но для терминала управления эти сообщения отметает как старые. Получаем отказ работы системы защиты! А КЗ будет гореть заданное нами время, достаточное для повреждения оборудования.

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

Таким образом можно проводить тестирование терминалов РЗА на программно-аппаратных комплексах моделирования в реальном времени РИТМ, в том числе проводить испытания на киберустойчивость. При этом можно оценивать физические процессы в системе и информационный обмен.

Итог

Материал получился объемный, но надеемся, интересным и полезным для специалистов в области электроэнергетики и моделирования. 

Если тема моделирования в реальном времени на КПМ РИТМ вам интересна, заходите на наш телеграм-канал. В нем мы регулярно рассказываем о проведенных опытах, выкладываем записи обучающих роликов и анонсируем предстоящие мероприятия.

Ждем вопросы и возможные пожелания в комментариях!

Спасибо за прочтение!

Комплексы полунатурного моделирования РИТМ