24 сентября 2026 года разработчики открытой библиотеки libIEC61850 опубликовали версию 1.6.2.1, устраняющую ошибку в механизме приёма GOOSE-сообщений. Исправление связано с проблемой №603, зарегистрированной в репозитории проекта 24 июля 2026 года.
Прежде всего это касается разработчиков продуктов с поддержкой стандарта МЭК 61850, использующих libIEC61850: устройств, шлюзов, контроллеров, программных комплексов и испытательного ПО. Если в состав продукта вошла версия 1.6.2, выпущенная 23 июля 2026 года, приём GOOSE может нарушиться уже у конечных пользователей — при том что сам обмен по сети выглядит исправным.
Для инженеров РЗА и АСУ ТП случай показателен тем, что демонстрирует ситуацию, когда сетевое взаимодействие работает корректно, но прикладное программное обеспечение не обрабатывает полученные сообщения.
В чём заключалась ошибка?
GOOSE-сообщения в соответствии с МЭК 61850-8-1 передаются непосредственно в Ethernet-кадрах. В заголовке GOOSE предусмотрено поле Length, определяющее длину сообщения, включая служебные поля GOOSE и блок данных APDU.
При получении кадра библиотека libIEC61850 проверяет соответствие фактической длины принятого кадра значению, указанному в заголовке.
В версии 1.6.2 в этой проверке появилась ошибка: кадры, фактическая длина которых точно соответствовала заявленной, ошибочно признавались некорректными.
Причиной стало изменение одного оператора сравнения в функции parseGooseMessage. Вместо условия:
numbytes < length + headerLength
использовалось условие:
numbytes <= length + headerLength
Здесь numbytes — сколько байт фактически получено, headerLength — длина Ethernet-заголовка (14 байт, с тегом VLAN — 18), а length — значение поля Length из заголовка GOOSE. Сумма length + headerLength — это длина кадра, которую он должен иметь согласно собственному заголовку.
Правильная проверка отбрасывает кадр, только если байт получено меньше, чем указано в заголовке, — то есть кадр обрезан. Ошибочная отбрасывала его и тогда, когда байт получено ровно столько, сколько указано. Но именно так выглядит обычный кадр, в конце которого нет лишних байтов.
Такой кадр библиотека считала повреждённым и отбрасывала ещё до того, как проверить, подписан ли на него кто-либо из настроенных подписчиков. При включённой диагностике выводилась ошибка «Invalid PDU size».
Почему одни GOOSE-сообщения принимались, а другие — нет?
Ethernet-кадр не может быть короче 64 байт, или 60 байт без контрольной суммы FCS. Если GOOSE-сообщение короче, передающее устройство дописывает в конец кадра байты заполнения (padding). В значение поля Length они не входят.
Например, если по заголовку кадр должен занимать 44 байта, он будет дополнен до 60. Библиотека получает 60 байт — больше, чем указано в заголовке, — и ошибочная проверка выполняется. Такой кадр принимался.
Если же кадр без заполнения занимает 60 байт или больше, дописывать в него нечего: получено ровно столько байт, сколько указано в заголовке. В примере из сообщения об ошибке длина такого кадра — 111 байт. Именно такие кадры версия 1.6.2 и отбрасывала. Как отмечает автор сообщения об ошибке, это обычный случай для реальных наборов данных: под ошибку попадали все GOOSE-кадры длиннее минимального Ethernet-кадра.
Таким образом, результат приёма GOOSE зависел от длины кадра и наличия байтов заполнения, хотя само сообщение было корректным.
Как обнаружили проблему?
Автор сообщения об ошибке подготовил воспроизводимый пример с GOOSE-кадром длиной 111 байт. При использовании libIEC61850 1.6.2 сообщение не доходило до обработчика подписчика. После исправления условия проверки тот же кадр успешно принимался.
24 сентября другой участник проекта опубликовал результаты независимой проверки с использованием двух контейнеров Linux, соединённых виртуальной сетью. В испытании использовались стандартные примеры издателя и подписчика GOOSE, входящие в состав библиотеки.
Результаты показали, что в версии 1.6.2 передаваемые сообщения поступали на сетевой интерфейс, однако подписчик не вызывал обработчик приёма. После применения исправления корректные сообщения начали обрабатываться.
В тот же день сопровождающий проекта Michael Zillgith подтвердил включение исправления и публикацию версии 1.6.2.1.
Что делать разработчикам продуктов на базе libIEC61850
Для производителей и разработчиков, которые используют libIEC61850 в своих продуктах, вывод прямой: ошибка находится в библиотеке и переходит в каждый продукт, собранный с версией 1.6.2.
- Проверить версию библиотеки в составе продукта — в том числе во встроенном ПО, SDK, сторонних компонентах и копиях исходного кода, перенесённых в собственные репозитории.
- Обновиться до 1.6.2.1 или перенести исправление условия проверки длины в функции
parseGooseMessage, если библиотека дорабатывалась самостоятельно. - Учесть собственный сетевой ввод. По данным сообщения об ошибке, при передаче кадров в библиотеку через
GooseReceiver_handleMessageдополнительных байтов заполнения нет, поэтому отбрасываться может каждый кадр, а не только кадры длиннее 60 байт. - Добавить регрессионные тесты на приём GOOSE-кадров разного размера: с байтами заполнения до минимальной длины Ethernet-кадра и без них.
- Выпустить обновление для пользователей, если продукт с версией 1.6.2 уже поставлялся заказчикам.
Что это означает для инженеров цифровых подстанций?
При диагностике GOOSE-обмена одним из первых инструментов обычно становится Wireshark. Если сообщение присутствует в захвате сетевого трафика, имеет ожидаемые адреса и идентификаторы, а его структура корректно декодируется, инженер может предположить, что проблема связана с настройками подписки или логикой принимающего устройства.
Однако рассмотренный случай показывает: наличие корректного GOOSE-сообщения в сетевом захвате не гарантирует его успешную обработку прикладным программным обеспечением.
При поиске подобных неисправностей важно проверять не только прохождение сообщений по сети, но и работу программного механизма подписки: поступает ли сообщение в приложение, вызывается ли обработчик GOOSE и не содержит ли используемая версия библиотеки известных ошибок.
Для систем на основе libIEC61850 дополнительное внимание следует уделить версии библиотеки и диагностическим сообщениям приёмника. При воспроизведении неисправности полезно сравнивать обработку кадров с дополнительными байтами заполнения и без них.
Вывод
Ошибка libIEC61850 1.6.2 — показательный пример неисправности, возникающей не на уровне передачи Ethernet-кадров, а непосредственно в программной реализации протокола. Проблема была устранена в версии 1.6.2.1, опубликованной 24 сентября 2026 года. Разработчикам продуктов с поддержкой МЭК 61850 на базе libIEC61850 стоит проверить используемую версию библиотеки и при необходимости обновить её в своих продуктах.
Наличие данной ошибки в открытой библиотеке не означает, что ей подвержены промышленные терминалы РЗА: это зависит от программной реализации, её версии и внесённых производителем изменений.
Рассмотренный случай подчёркивает важность комплексной проверки GOOSE-обмена — от присутствия сообщения в сети до его фактической обработки принимающим приложением.