18
На начальном этапе от всех производителей
предоставлялись файлы с описанием возможностей
устройств (ICD) на все ИЭУ проекта. Предоставленные
файлы в обязательном порядке проходили проверку на
соответствие синтаксису SCL, а также дополнительно на
соответствие корпоративному профилю МЭК 61850 ПАО
«ФСК ЕЭС» [1]. Уже на данном этапе стали возникать
первые проблемы. В соответствии с МЭК 61850, на ИЭУ
предоставляется
ICD
файл,
который
должен
соответствовать
функционалу
терминала.
Проанализировав предоставленные файлы, их часть
оказалась некорректна и отправлялась на доработку.
Некоторые файлы частично отличались от реального
функционала. Такой подход не должен применяться, ведь
если файл не может быть записан в терминал, пользы от
него, как и от SCD в целом, не будет. Конфигурирование
терминала в таком случае возможна только через
программное обеспечение (ПО). Так же вопрос встал о
совместимости редакций разных ICD файлов. У одного из
производителей ICD были выполнены по 1 редакции МЭК
61850, в этом сложности не было, редакции между собой
совместимы.
Но
проблема
была
в
обратной
совместимости. Разработанный SCD был выполнен по 2
редакции в соответствии с корпоративным профилем
МЭК 61850 ПАО «ФСК ЕЭС». Ввиду возможности
загрузки в ICT этого производителя только файлов 1
редакции, использование разработанного SCD для него
стало невозможным.
На следующем этапе, в ПО STS Helinks
импортировались все ICD и составлялась конфигурация.
Конфигурирование устройств в части описывания
посигнального обмена и параметров осуществлялась на
основании методических указаний по проектированию
ЦПС [2], а также по СТО 56947007 на типовые шкафы [3].
На данном этапе основная сложность заключалась в
составлении набора данных. В СТО на типовые шкафы
описаны все атрибуты и объекты данных, которые
должны входить в состав наборов данных. В 70% случаев
для GOOSE и MMS не удавалось составить набор
аналогичный СТО. По этой причине приходилось
связываться с производителями и выяснять, каким
атрибутом из всей информационной модели можно
заменить необходимый сигнал. Так же усложнило работу
использование
для
составления
набора
данных
логического узла GGIO. Логический узел GGIO
представляет собой обезличенный набор объектов и
атрибутов, которые не дают информации о смысловом
назначении сигналов.
В рамках разработки электронного проекта были
сконфигурированы:
1.
имя ИЭУ в проекте и его сетевые параметры;
2.
наборы передаваемых данных для GOOSE
сообщений, SV потоков и MMS отчетов всех
ИЭУ;
3.
коммуникационные
параметры
блоков
управления GOOSE, SV, MMS;
4.
связи
«издатель-подписчик»
между
устройствами;
5.
oписание входящих сигналов у подписчика.
В составе шины процесса было сконфигурировано 26
SV потоков. В составе шины станции было
сконфигурировано 72 GOOSE сообщения и 40 MMS
отчетов. Все этапы разработки SCD сопровождались
использованием системы Tekvel Park для управления
жизненным циклом цифровой подстанции. Именно с
помощью этого инструмента производилась проверка,
контроль и визуализация SCD на разных стадиях его
готовности.
По завершению описания конфигурации, SCD файл
был предоставлен всем производителям, для загрузки
конфигураций в их устройства. Данный этап является
одним из ключевых, так как согласно бизнес-процессу
использования файлов SCL, разработанный SCD файл
значительно
сокращает
время
конфигурирования
устройств. Таким образом, загружая SCD файл в
конфигураторы IED, большая часть конфигурации уже
есть, остается только дополнить ее файлами уставок,
логики и задать для приходящих сигналов внутренний
адрес. Но получилось немного иначе.
После предоставления SCD для загрузки, многими
производителями стали высылаться новые ICD, в связи с
обновлением прошивки на терминалах. В реальных
проектах это частый случай, если реализация ЦПС в
среднем длится 6-12 месяцев, то за этот период прошивка
один раз да обновится. Общее количество обновленных
ICD составило 18 файлов. Так же надо учитывать, что ICD
файл на устройство один, а устройств в составе шкафа в
основном 2 и зачастую с разными наборами данных и
входящими сигналами. Таким образом в изменении
конфигурации нуждались 34 устройства. Обновить
автоматически модель данных в SCD через ICD файл
нельзя, сделать это можно только через IID файл.
IID
–
это
файл
описания
предварительно
сконфигурированного устройства, то есть для обновления
там должна быть составленная конфигурация на основе
SCD и тогда можно через SCT обновить модель данных
ИЭУ. Но так как предоставлялись именно ICD, сначала
приходилось конфигурировать до IID файла, а потом уже
обновлять конфигурацию в SCD.
После обновления SCD файла он был применен для
загрузки в конфигураторы ИЭУ. И, как оказалось,
практически во все конфигураторы ИЭУ загружалась не
вся конфигурация разработанная в SCD. Таким образом,
много работы предстояло повторно делать уже в
конфигураторах, что замедлило предполагаемый процесс
наладки.
III.
С
РАВНИТЕЛЬНЫЙ ЭКСПЕРИМЕНТ
Для определения временных затрат в разработке и
применении SCD файла мультивендорной подстанции
был проведен сравнительный эксперимент, для которого
был взят аналогичный, ранее разработанный SCD файл,
состоящий из устройств одного производителя (Рис. 2).
В качестве критериев оценки было взято время,
уходящее на основные этапы разработки SCD. Среди
которых:
1.
Получение актуальных ICD файлов на все ИЭУ
от всех производителей. Было взято среднее
значение, так как у некоторых производителей
ICD есть на сайте, но все равно требуется
уточнение об их актуальности.
2.
Составление
конфигурации
проекта.
При
одинаковом количестве ИЭУ, данный показатель
зависит только от описания модели в ICD файле.
Если она не соответствует типовым требованиям,
приходится связываться с производителями для
уточнения деталей конфигурирования.
