В качестве исходных данных для анализа мы использовали 124 уникальных файла SCL, среди которых были и файлы ICD отдельных устройств, так и файлы SCD полноценных проектов. В общей сложности, файлы описывали 316 экземпляров устройств, из которых 57 устройств были уникальными. Наконец, эти устройства были настроены на выдачу 219 GOOSE-сообщений и 836 отчетов.

Методология исследования

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

Мы проанализировали 124 уникальных файла SCL, среди которых были как ICD файлы устройств, так и SCD файлы полноценных проектов.

Перед началом исследования общее количество файлов SCL превышало 500, поэтому для объективности результатов мы должны были избавиться от файлов-дубликатов и различных версий одних и тех же проектов. Отбор данных выполнялся в несколько этапов. На первом этапе мы произвели вычисление хеша md5 для каждого файла и исключили из обработки файлы с одинаковым значением хеша. На втором этапе мы обеспечили валидацию файлов согласно схеме SCL (в зависимости от того, в соответствии с какой редакцией стандарта был сформирован файл, использовалась соответствующая схема SCL) и, таким образом, для последующего анализа мы отобрали только валидные файлы. Мы также проанализировали заголовки файлов для того, чтобы исключить из обработки разные версии одних и тех же проектов. И, наконец, для последующего анализа мы оставили только уникальные типы устройств.

У нас не было цели отдать предпочтение какому-либо проекту, производителю или типоисполнению устройств, поэтому никакой идентификации исходных данных в ходе анализа файлов мы не предусматривали.

Результаты

В ходе выполнения анализа нас интересовали 3 аспекта:

• Количество ЛУ GGIO, используемых в рассматриваемых уникальных устройствах.
• Количество ЛУ GGIO, на которые ссылаются элементы наборов данных, передаваемых посредством сервиса отчётов.
• Количество ЛУ GGIO, на которые ссылаются элементы наборов данных, передаваемых посредством GOOSE-сообщений.

Использование классов логических узлов

Для того, чтобы понять, какие ЛУ наиболее широко используются в устройствах, мы проанализировали модели данных 57 уникальных типов устройств. Мы просуммировали все экземпляры ЛУ каждого класса, встретившиеся в файлах SCL. Затем мы поделили число экземпляров ЛУ определенного класса на общее число логических узлов. Результат представлен на рис. 1.

Мы представили данные таким образом, что наиболее популярные классы ЛУ, образующие 50% от общего числа встретившихся, идентифицированы своим наименованием, в то время как остальные 77 классов ЛУ, которые мы обнаружили при анализе, образовали группу «другие». Как видно из рис. 1, ЛУ GGIO является безоговорочным лидером, опережая на 7% своего ближайшего преследователя и составляя 1/5 часть от общего числа ЛУ. На втором месте ожидаемо оказался ЛУ PTOC (14%). Следующие три класса ЛУ, отхватившие доли размером по 4% каждый, – LPHD (который может быть принят за базисный ЛУ, т.е. можно предположить, что каждое логическое устройство имеет в своем составе в среднем по 21/4 = 5,25 ЛУ класса GGIO), MMXU, PTOV. Наконец, на класс ЛУ CSWI приходится 3%.

Стоит отметить, что классы ЛУ MMXU, PTOV и CSWI могли бы быть заменены другими классами при большем числе уникальных устройств, участвоваших в анализе, поскольку мы не можем принять отличие долей на 1% показательным. При этом лидер – ЛУ GGIO – остается в недосягаемости. Также стоит отметить, что ситуация могла бы выглядеть еще хуже, если бы рассматривались не экземпляры ЛУ, а экземпляры объектов/атрибутов данных, поскольку, как известно, в устройствах в составе одного экземпляра GGIO встречается более одного объекта данных. Об этом можно косвенно судить по результатам анализа, представленным далее.

Классы логических узлов, передаваемые посредством сервиса отчётов

Вторая часть нашего исследования заключалась в анализе состава классов ЛУ, передаваемых посредством сервиса отчётов. При этом мы не различали буферизируемые и небуферизируемые отчёты. В общей сложности мы проанализировали 836 блоков управления передачей отчётов. Сразу же хочется отметить интересное наблюдение: в проанализированных файлах (большее число из которых представляли собой файлы SCD) было обнаружено в 4 раза больше блоков управления передачей отчётов по сравнению с блоками управления передачей GOOSE-сообщений, что говорит о значительно меньшем объёме использования IEC 61850 для целей РЗА, нежели чем для решения задач АСУ ТП сегодня. Набор данных каждого блока управления передачей отчётов анализировался на класс ЛУ, на который ссылаются его элементы. Например, 2 элемента набора данных, ссылающиеся на определенный класс ЛУ, давали этому классу 2 очка в копилку. Суммарное число очков по классам ЛУ (количество ЛУ определенного класса, встретившихся в рассмотренных наборах данных) было отнесено к общему числу элементов данных в наборах данных. Результаты анализа представлены на рис. 2.

Мы были действительно удивлены: 64% элементов данных, передаваемых посредством отчётов, представлены логическими узлами GGIO.

Мы были удивлены результатам анализа. На всякий случай, мы даже дважды проверили наши алгоритмы на предмет ошибок в вычислениях, но ошибок не было. 64% элементов данных, передаваемых посредством сервиса отчётов, представлены ЛУ GGIO. Мы также представили данные по 3 другим классам ЛУ. Классы ЛУ PTOC и MMXU разделили второе место, составив в процентном соотношении по 6% каждый. А третье место взял класс ЛУ PDIS – лишь 2% передаваемых отчётами данных представлены этим классом ЛУ. В ходе анализа были выявлены и данные, которые представлены другими классами ЛУ – их количество составило 47 или 21% от общего числа передаваемых данных, а доля каждого класса ЛУ не превышала 0,5%. Наряду с интересным наблюдением о том, что около 2/3 данных, передаваемых в АСУ ТП, представлены ЛУ GGIO, другим интересным фактом является то, что в АСУ ТП передается лишь немногим более половины классов ЛУ от общего их числа (передается 51 класс ЛУ при общем числе классов равном 83). То есть модель данных, доступная в устройствах, используется не в полном объёме.

Классы логических узлов, передаваемые посредством GOOSE

Плохие новости: 83% данных, передаваемых посредством 219 проанализированных GOOSE-сообщений, представлены логическим узлом GGIO.

Данные, передаваемые посредством GOOSE-сообщений, были проанализированы точно также, как и данные, передаваемые сервисом отчётов. Результаты анализа представлены на рис. 3.

83% данных, передаваемых посредством 219 GOOSE-сообщений, – это данные ЛУ GGIO. Что это означает для заказчика? Это эквивалентно тому, что вы возьмёте все клеммники и просто избавитесь от 83% маркировки…

В условиях, когда лишь один класс ЛУ составляет более 5% (ЛУ RBRF), совсем не интересно анализировать структуру оставшихся 17%.

Почему это происходит?

Получается, 21% ЛУ класса GGIO, реализованных в устройстве, о которых мы говорили в самом начале анализа результатов исследования, это не так уж и плохо… если сравнивать с 83% данных того же класса в GOOSE-сообщениях. Но почему это проихсодит? Кто виноват?

Далее мы приводим наблюдения, основанные на нашем опыте работы с устройствами и на анализе проектов, в которых мы выступали консультантами. Эти наблюдения не универсальны, однако описывают ситуации, взятые из реальной жизни, и могут являться отправной точкой для более других исследований. Среди факторов, которые приводят к чрезмерному злоупотреблению ЛУ GGIO мы можем отметить следующие:

• Недостаток компетенции у специалистов проектных и наладочных организаций.
• Несоответствие применяемой модели данных утвержденным национальным профилям IEC 61850 (если таковые имеются).
• Недостатки первой редакции стандарта.
• Некачественная реализация стандарта IEC 61850 в устройствах.
• Недостаток качественных инструментов для конфигурирования систем на основе IEC 61850.

Стоит рассмотреть каждый из аспектов подробнее.

Профили IEC 61850 и их знание

Для того, чтобы искоренить чрезмерное использование логических узлов GGIO для принятых схем РЗА должны быть утверждены профили IEC 61850.

Практически в каждой стране есть устоявшиеся принципы реализации комплексов РЗА. Для реализации этих принципов инженеры часто используют свободно-программируемую логику. В большинстве случаев сигналы, получающиеся на выходе пользовательских схем логики, выводятся посредством элементов данных ЛУ GGIO. Для того, чтобы искоренить эту плохую привычку для принятых схем РЗА должны быть утверждены национальные профили IEC 61850. И специалисты должны знать эти профили и следовать им, конечно, при поддержке производителей устройств.

Некачественная реализация IEC 61850 в устройствах

Тяжело представить, что производители, которых можно считать основными двигателями внедрения стандарта IEC 61850 (по крайней мере, на ранних этапах развития стандарта), могут не достаточно качественно реализовывать стандарт в своих устройствах… Но время от времени мы сталкиваемся с плохими реализациями. К примеру, ниже представлена выдержка из документа PIXIT для одного достаточно популярного устройства РЗА:

Как видно, устройство не поддерживает атрибут Str. То есть, если вам понадобится использовать этот сигнал (например, при реализации логической защиты сборных шин), сначала придется его сформировать в свободно-программируемой логике, а затем вывести его по протоколу GOOSE, используя объект данных логического узла GGIO.

Недостаток качественных конфигураторов систем на основе IEC 61850

Мы могли бы назвать нескольких производителей с достаточно мощными конфигураторами систем на основе IEC 61850, хорошо дополняющих их аппаратные решения, но это статья не про рекламу, поэтому не будем. Эта статья о проблемах, поэтому мы должны отметить то, что есть десятки других производителей, которые не сопровождают свои разработки качественными конфигураторами, обеспечивающими удобство и простоту конфигурирования. Мы даже не говорим здесь о проектах, в которых применяются устройства различных фирм-производителей. Порой, всё доходит до абсурда. Не имея толковых конфигураторов IEC 61850, специалисты идут на ухищирения: делают конфигурацию по информационному обмену единожды, опираясь на объекты данных узлов GGIO (то есть создают статическую конфигурацию коммуникаций между устройствами, используя набор GGIO для выдачи и получения информации). И далее работают со свободно-программируемой логикой, а конфигурация информационного обмена не меняется от проекта к проекту. Здорово! Отлично! А как же семантика? Нет, не слышали 🙂

Не всё так гладко с первой редакцией стандарта

Сам стандарт IEC 61850 также не безгрешен. Как многие знают, использование элемента BlkRef для описания приёма блокирующих сигналов, описание блоков управления в разделе Inputs и другие моменты описаны в более поздних редакциях стандарта, а базовые прикладные профили вовсе находятся в стадии разработки. И, несмотря на то, что многие из нас склонны во всём винить производителей, проектировщиков и наладчиков, правильнее сказать, что все мы ответственны за происходящее.

Выводы

В качестве выводов можно отметить следующее:

• Электросетевые компании ДОЛЖНЫ понимать, что если они вводят в работу системы, где функции моделируются узлами GGIO, то они теряют половину тех преимуществ, которые даёт стандарт IEC 61850 по сравнению с устаревшими коммуникационными протоколами.
• Утверждённые профили стандарта IEC 61850 для прикладных функций должны искоренить использование логических узлов GGIO.
• Электросетевые компании должны обладать инструментами для проверки корректности реализации прикладных функций в соответствии с утвержденными профилями IEC 61850.
• До тех пор, пока ЛУ GGIO применяются, они должны сопровождаться исчерпывающим пользовательским описанием.

Держа это в голове, мы пойдем кратчайшим маршрутом в направлении полного понимания концепций стандарта IEC 61850 и его принятия специалистами отрасли.