Файлы конфигурации: ICD, CID, SCD

Проект на 61850 собирается не настройками в веб-интерфейсах, а файлами описания. Язык этих файлов — SCL (часть 61850-6), обычный XML со строгой структурой. Понимание того, кто какой файл выпускает и что в нём лежит, снимает половину вопросов при интеграции.

Четыре типа файлов

Файл	Кто выпускает	Что содержит
ICD	Производитель устройства	Возможности устройства «как с завода»: какие логические узлы и объекты данных оно умеет, без привязки к объекту
SSD	Проектировщик подстанции	Однолинейная схема и функции: что за объект, какие присоединения, какие функции нужны — без конкретных устройств
SCD	Системный интегратор	Полная конфигурация подстанции: все устройства, их адреса, наборы данных, отчёты, потоки GOOSE и SV, связи между ними
CID	Инструмент конфигурирования	Конфигурация одного конкретного устройства, извлечённая из SCD и загружаемая в него

Порядок работы обычно такой: производители дают ICD → интегратор собирает из них SCD, где прописывает адреса, наборы данных и кто кого слушает по GOOSE → из SCD генерируются CID для каждого устройства → CID загружаются в устройства. Отсюда правило: единственный источник правды — SCD. Настройка, сделанная руками в отдельном устройстве мимо SCD, потеряется при следующей перегенерации и не будет видна остальным участникам проекта.

Что внутри файла
Структура SCL всегда одинакова, и по ней удобно ориентироваться даже в чужом проекте:

• Header — идентификатор проекта, версия, история изменений. Полезнее, чем кажется: по нему отличают редакции файла.
• Substation — описание объекта: распределительные устройства, присоединения, оборудование и привязка функций к нему.
• Communication — подсети и адреса: IP-адреса устройств, параметры стека, а также параметры потоков GOOSE и SV — MAC-адреса, APPID, VLAN и приоритеты.
• IED — по одному разделу на устройство: его логические устройства и узлы, наборы данных, блоки управления отчётами, публикуемые и принимаемые потоки.
• DataTypeTemplates — описания типов, из которых собраны данные устройства: классы логических узлов, объекты данных, перечисления. Именно здесь видно, где производитель вышел за рамки стандарта.

Как этим пользоваться на практике
Файл описания — рабочий инструмент интегратора, а не формальность из комплекта поставки:

• Перечень сигналов берётся из него поиском по именам узлов: не нужно ни опрашивать устройство, ни ждать доступа к объекту.
• Сверка с реальностью — обойти модель на живом устройстве и сравнить с файлом. Расхождение означает, что в устройство залита другая конфигурация.
• Разбор связей GOOSE — раздел Communication вместе с описанием входов подписчиков отвечает на вопрос «кто кого слушает» без анализатора трафика.
• Контроль версий. Файлы проекта хранят с версиями и историей: при разборе инцидента важно знать, какая конфигурация стояла в устройстве в тот момент.

Типовые ошибки

Симптом	Где искать
Инструмент не открывает файл производителя	Разные редакции стандарта у файла и у инструмента; нестандартные расширения в разделе типов
После перезагрузки устройства настройка «откатилась»	Изменения вносились мимо SCD, устройство перечитало свой CID
Подписчик не получает поток, хотя в проекте связь описана	CID сгенерирован из старой версии SCD: не совпали APPID или состав набора данных
Клиент видит не те сигналы, что в файле	В устройство залита конфигурация другого присоединения — сверить идентификатор устройства и версию
Проект не собирается из файлов разных производителей	Несовпадение редакций и частные расширения; требуется приведение к общей редакции