Очный этап на площадке конференции стал логичным продолжением этой работы и был сфокусирован на практическом сценарии: как инструменты и устройства ведут себя при внесении регламентированных изменений и обновлении конфигурации по IID-файлу в условиях, максимально приближенных к реальному жизненному циклу ВАПС. Организатором и инициатором испытаний, как и на заочном этапе, выступило ПАО «Россети».
Методика очного этапа: три SCD и один IID
В центре очных испытаний оказался сквозной сценарий работы с конфигурацией одного и того же терминала через три состояния SCD.
- SCD₀ — исходный согласованный файл конфигурации системы.
- SCD₁ — результат модификации конфигурации в SCT производителя по заранее оговорённому сценарию (изменения имени устройства IEDname, IP-параметров и т.п.).
- IID — файл, экспортируемый из ICT после импорта SCD₁ и внесения согласованных изменений на стороне устройства (добавление логических узлов LGOS, изменения параметров GOOSE и т.п.).
- SCD₂ — SCD, полученный после обновления проекта в SCT на основе IID-файла.
Методика верификации
Для каждого участника цепочки сравнение конфигурации выполнялось с помощью ПО «Теквел Магия», которое анализировало изменения в SCD₀, SCD₁ и SCD₂ и формировало отчёт об изменениях, не предусмотренных по заданию.
Анализ охватывал как изменения в конфигурации системы, так и изменения в информационной модели устройств.
Что именно проверялось в моделях ИЭУ и конфигурациях
Критерии проверки были разделены на две группы: «проверка модели ИЭУ» и «проверка конфигурации ИЭУ».
Проверка модели ИЭУ
В части модели ИЭУ проверялись ключевые аспекты:
- структурная целостность модели данных (LNodeType, DOType, DAType и их элементы);
- семантическая неизменность параметров (EnumType, триггеры dchg/qchg/dupd, значения и их типы);
- сохранность экземпляров и связей (LDevice, LN/LN0, DataSet/FCDA, ExtRef, DAI);
- соблюдение ограничений конфигурирования (Services, GSE/Report Settings и др.);
- неизменяемость защищённых атрибутов модели.
Проверка конфигурации ИЭУ
Проверка конфигурации охватывала:
- идентификацию и состав устройств (IEDName, производитель, тип, состав LN);
- сетевые параметры (Communication, IP-настройки);
- конфигурацию GOOSE и Sampled Values (блоки управления, параметры передачи, состав DataSet);
- конфигурацию MMS-отчётов (ReportControl, TrgOps, OptFields, состав DataSet и др.);
- подписки и связи (Inputs, ExtRef и их параметры).
Шкала оценок и интерпретация результатов
Результаты проверки классифицировались по трём категориям в зависимости от характера выявленных изменений:
- НОРМА. Выявлены только изменения, предусмотренные заданием. Недопустимые изменения в конфигурации МЭК 61850 (GOOSE, SV, MMS), а также в модели ИЭУ отсутствуют. Это означает полную сохранность модели и корректную передачу конфигурации между инструментами.
- ПРЕДУПРЕЖДЕНИЕ. Зафиксированы изменения, не предусмотренные заданием, затрагивающие конфигурацию МЭК 61850 и/или модель ИЭУ, но не оказывающие критического влияния на функционирование системы. Как правило, это локальные отклонения параметров или служебных атрибутов, не нарушающие конфигурацию и применимость SCD.
- КРИТИЧНО. Выявлены изменения, не предусмотренные заданием, которые оказывают критическое влияние на функционирование системы и/или приводят к ошибкам. К таким случаям относятся нарушения связей, структуры модели, параметров GOOSE/SV/MMS или потеря значимых частей конфигурации.
Такое разделение позволило не только фиксировать факт расхождений, но и оценивать их влияние на практическую реализуемость конфигурации в среде цифровой подстанции.
Последовательность испытаний и результаты
Этап 1: изменения в SCD (SCD₀ → SCD₁)
На первом шаге производитель вносил оговорённые изменения в SCD₀ в своём системном конфигураторе (SCT), после чего в ПО «Теквел Магия» выполнялось сравнение исходной и модифицированной конфигурации устройств. Задача заключалась в выявлении изменений, не предусмотренных заданием и являющихся недопустимыми.
Результаты показали, что на первом этапе (SCD₀ → SCD₁) большинство системных конфигураторов корректно реализуют заданные изменения (например, изменение IEDName и IP-параметров) без затрагивания лишних элементов модели.
В отдельных случаях, однако, фиксировались побочные эффекты: изменение confRev без фактического изменения состава DataSet, модификация Services или удаление существующих подписок ExtRef, что уже выходит за рамки сценария и требует внимания.
Этап 2: импорт в ICT и экспорт IID (SCD₁ → IID)
Следующий шаг — импорт SCD₁ в конфигуратор устройства (ICT) производителя, выполнение заранее оговорённых изменений на уровне устройства и экспорт IID-файла.
На этом этапе проверялась способность ICT корректно интерпретировать SCD в части конфигурации GOOSE, SV и MMS и переносить в конфигурацию устройства прикладные параметры и сетевые настройки.
Результаты показали, что сами операции импорта/экспорта IID выполняются успешно, но часть инструментов при этом изменяет структуру логических узлов, атрибуты данных или внутренние идентификаторы устройства, что в дальнейшем сказывалось на обновлении SCD в SCT.
Этап 3: обновление проекта SCD через IID (SCD₁ → SCD₂)
Результаты показали, что на этапе обновления через IID (SCD₁ → SCD₂) в большинстве случаев конфигурация корректно передаётся и сохраняет внесённые изменения без искажения модели.
В отдельных сценариях, однако, фиксировались дополнительные изменения параметров и структуры — например, затрагивание DataSet, ExtRef или логических узлов, что выходит за рамки заданного сценария и требует дополнительного контроля со стороны инструментов.
Итоговая оценка
Всего в рамках испытаний было проверено 69 SCD-файлов и выполнено 46 сравнений на различных этапах (SCD₀ → SCD₁ → SCD₂).
Распределение результатов по принятым критериям:
- 78 % — «НОРМА». Изменения соответствуют заданию, модель ИЭУ и конфигурация всех устройств сохраняются без искажений на всех этапах.
- 10 % — «ПРЕДУПРЕЖДЕНИЕ». Фиксируются дополнительные изменения, не предусмотренные заданием, но не влияющие на работоспособность системы и применимость SCD.
- 12 % — «КРИТИЧНО». Выявлены изменения, способные повлиять на функционирование: потеря подписок, рассогласование связей, изменение структуры логических узлов и др.
{
"title": {
"text": "Итоговая оценка: распределение результатов по критериям",
"subtext": "69 SCD-файлов · 46 сравнений на этапах SCD₀ → SCD₁ → SCD₂",
"left": "center",
"top": 10,
"textStyle": { "fontSize": 14, "fontWeight": "bold" },
"subtextStyle": { "fontSize": 11, "color": "#888", "lineHeight": 18 }
},
"tooltip": { "trigger": "item", "formatter": "{b}: {c}% ({d}%)" },
"legend": {
"bottom": 12,
"left": "center",
"itemGap": 22,
"textStyle": { "fontSize": 12 }
},
"series": [{
"name": "Результат",
"type": "pie",
"radius": ["42%", "68%"],
"center": ["50%", "58%"],
"avoidLabelOverlap": true,
"label": {
"show": true,
"position": "inside",
"formatter": "{d}%",
"fontSize": 14,
"fontWeight": "bold",
"color": "#fff"
},
"labelLine": { "show": false },
"data": [
{ "value": 78, "name": "НОРМА", "itemStyle": { "color": "#67C23A" } },
{ "value": 10, "name": "ПРЕДУПРЕЖДЕНИЕ", "itemStyle": { "color": "#E6A23C" } },
{ "value": 12, "name": "КРИТИЧНО", "itemStyle": { "color": "#F56C6C" } }
]
}]
}
В целом, 88 % сценариев проходят без критических нарушений, что подтверждает базовую работоспособность цепочки изменений и обмена конфигурацией.
{
"title": {
"text": "Доля сценариев без критических нарушений",
"left": "center",
"textStyle": { "fontSize": 14 }
},
"tooltip": { "trigger": "axis", "axisPointer": { "type": "shadow" } },
"grid": { "left": "15%", "right": "10%", "top": "25%", "bottom": "15%", "containLabel": true },
"xAxis": {
"type": "value",
"max": 100,
"axisLabel": { "formatter": "{value}%" }
},
"yAxis": {
"type": "category",
"data": ["Все сценарии испытаний"]
},
"series": [
{
"name": "Без критических нарушений",
"type": "bar",
"stack": "total",
"data": [88],
"itemStyle": { "color": "#67C23A" },
"label": { "show": true, "position": "inside", "formatter": "{c}%", "fontWeight": "bold", "fontSize": 14 }
},
{
"name": "Критично",
"type": "bar",
"stack": "total",
"data": [12],
"itemStyle": { "color": "#F56C6C" },
"label": { "show": true, "position": "inside", "formatter": "{c}%", "fontWeight": "bold", "fontSize": 14 }
}
],
"legend": { "bottom": 5 }
}
ПО Теквел Магия как участник испытаний
В рамках очного этапа было принято решение расширить контур испытаний и включить в проверку не только системные конфигураторы (SCT) и конфигураторы устройств (ICT), но и инструменты, применяемые на этапах наладки, испытаний и эксплуатации.
Такой подход обусловлен практикой: в реальных проектах с SCL-файлами работает значительно более широкий набор программных средств. Помимо проектных инструментов, это испытательные установки и программы, которые выполняют чтение, анализ, изменение и обновление SCD-файлов. Соответственно, их корректная работа с SCL напрямую влияет на целостность конфигурации и итоговую работоспособность системы.
В этой логике ПО «Теквел Магия», ориентированное на задачи тестирования устройств РЗА и АСУ ТП на этапах ПНР, ПСИ и ТО, было включено в испытания как представитель данного класса инструментов — в рамках общей методологии проверки. При этом участие «Теквел Магия» в испытаниях следует рассматривать не как полноценную замену SCT или ICT, а как элемент независимой инфраструктуры тестирования.
Такое включение также отражает отраслевую практику: несмотря на то, что системные конфигураторы относятся к этапу проектирования, необходимость внесения изменений в SCD-файлы регулярно возникает на стадии наладки. При этом полнофункциональные вендорские SCT не всегда доступны или применимы в этих условиях, поскольку ориентированы на задачи проектирования и, как правило, отсутствуют в инструментальном наборе наладочных организаций.
В связи с этим в ПО «Теквел Магия» помимо реализации работы по протоколам SV, GOOSE, MMS реализован функционал работы с SCL-файлами, достаточный для решения прикладных задач на объекте: изменение параметров устройства, изменение параметров GOOSE, SV и MMS, наборов данных, а также обновление конфигурации устройств по IID-файлам. Такой подход позволяет использовать единый инструмент для проверки оборудования, для контроля целостности конфигурации и её актуализации в ходе ПНР и ПСИ.
Результаты проверки
В рамках испытаний для конфигураций всех производителей в ПО «Теквел Магия» был выполнен аналогичный сценарий работы:
- Этап 1 — изменение параметров устройства (IEDName);
- Этап 3 — обновление SCD-файла на основе IID-файла, предоставленного производителем.
По результатам анализа во всех рассмотренных комбинациях изменения были обработаны корректно: модель ИЭУ и конфигурация сохранялись в рамках заданного сценария как на этапе SCD₀ → SCD₁, так и при обновлении SCD₁ → SCD₂.
Заключение
Очный этап испытаний, дополнивший заочный анализ SCL-файлов, позволил увидеть, как сценарии изменения и обновления конфигурации реализуются в реальной связке инструментов и устройств разных производителей. Для ПАО «Россети» и участников рынка это даёт практический критерий зрелости решений: не только в части соответствия стандарту МЭК 61850 и отечественной НТД, но и способность выполнять полный цикл изменений без потери целостности модели и конфигурации.
Для компании «Теквел» участие в испытаниях — это одновременно проверка собственных инструментов и продолжение экспертной работы по развитию автоматизированных проверок SCL-файлов. Полученные результаты и отработанные сценарии готовы к использованию в следующих итерациях испытаний, а также при дальнейшем развитии правил анализа и функционала ПО «Теквел Парк Сервер» и ПО «Теквел Магия».
Отдельный вывод, подтверждённый в ходе испытаний, заключается в том, что требования совместимости должны распространяться на все инструменты, работающие с SCL-файлами — включая испытательные установки и системы тестирования. Ведь если такие инструменты некорректно интерпретируют SCD или вносят изменения в модель и конфигурацию, это будет приводить к искажению проводимых испытаний оборудования и может вносить ошибки в проектную конфигурацию системы.