Магический кейс #3: формуляр передачи телеинформации — из SCD или набора CID в один клик

В предыдущих статьях серии мы показывали, как ПО Теквел Магия сравнивает конфигурацию из SCD с фактической конфигурацией ИЭУ и как в один клик снимает текущее состояние блоков управления передачей отчётов по MMS. Сегодня — третий кейс, который закрывает еще одну задачу, связанную с передачей телеинформации: не проверить, а задокументировать. Превратить SCL-конфигурацию передачи отчётов в человекочитаемый формуляр — быстро, по всему парку устройств и без выхода в сеть подстанции.

Зачем вообще нужен формуляр передачи телеинформации

При настройке передачи телеизмерений и телесигнализации по МЭК 61850 — в устройствах РЗА, контроллерах присоединения, измерительных преобразователях — рано или поздно наступает момент передачи их текущей конфигурации. Сконфигурированную модель данных нужно отдать специалистам, которые занимаются наладкой верхнего уровня: АСУ ТП, телемеханики, АСДУЭ и др.

В идеале им передаётся файл SCD — по МЭК 61850‑6 это обязательный элемент проектной и исполнительной документации, и именно он упрощает интеграционные работы. Но на практике SCD есть не всегда: иногда на руках только набор отдельных CID-файлов, выгруженных из устройств. В обоих случаях «голый» XML-файл сам по себе плохо подходит для передачи и согласования — его трудно читать человеку, по нему неудобно объяснять, какие отчёты настроены, с какими параметрами передачи и какие сигналы в них входят.

Поэтому конфигурацию принято сопровождать формуляром передачи телеинформации — документом, который понятным языком описывает, что и как передаётся с использованием отчетов по протоколу MMS. Тот же документ нужен и на финише пусконаладочных работ: после настройки вторичных устройств на объекте требуется сформировать исполнительную документацию по передаче телеинформации. Делать такой формуляр вручную — выписывать из десятков устройств блоки отчётов, их триггеры, наборы данных и состав сигналов — долго и чревато ошибками. Представляемый модуль ПО Теквел Магия делает это автоматически: из SCD-файла или из набора CID-файлов он формирует готовый формуляр за один прогон.

Место в серии: «как настроено», «как сейчас работает», «как это передать»

Чтобы не путать три близких задачи, удобно держать в голове разделение:

• Кейс #1 — соответствие: сверяет проектный SCD с фактической конфигурацией устройств по MMS и выдаёт протокол расхождений.
• Кейс #2 — состояние: подключается к устройствам по MMS и показывает, как отчёты работают сейчас (RptEna, Owner, кто на что подписан).
• Кейс #3 — документирование (этот): берёт SCL-конфигурацию и превращает её в читаемый формуляр и исполнительную документацию. Здесь нет вердиктов «совпало/не совпало» и нет обращения к сети — только аккуратное, человекочитаемое описание того, как настроена передача отчётов.

Ключевое отличие третьего кейса — он полностью работает в оффлайн режиме. Не нужно ни доступа в сеть подстанции, ни живых устройств: достаточно файлов. Это удобно в офисе, на этапе подготовки документации, при передаче проекта между подрядчиками и при формировании комплекта на сдачу.

Как это работает

Сценарий максимально короткий. Запускаете модуль — и в первом диалоге выбираете источник данных:

• один SCL-файл (SCD с несколькими устройствами, либо отдельный CID/ICD), либо
• папку с набором CID-файлов (.cid / .iid / .icd / .scd / .scl) — каждый файл читается отдельно, а устройства из всех файлов объединяются в один общий формуляр.

Дальше предлагается выбрать устройства, по которым формировать документ (есть пункт «выбрать все» — удобно, когда в SCD их несколько десятков). Модуль находит во всех выбранных устройствах блоки управления передачей отчётов — буферизируемые (BRCB) и небуферизируемые (URCB), — разворачивает связанные с ними наборы данных, подтягивает текстовые описания сигналов из SCL и собирает Word-документ. Параллельно формируется отдельный документ с замечаниями по конфигурации (о нём ниже).

Весь алгоритм удобно представить блок-схемой — от выбора источника до готовых документов:

flowchart TB
    A["Запуск модуля"]
    B{"Источник данных?"}
    F["Один SCL-файл<br/><i>SCD / CID / ICD</i>"]
    G["Папка с CID-файлами<br/><i>.cid/.iid/.icd/.scd/</i>"]
    C["Перечень IED<br/><i>имена и desc устройств</i>"]
    S["Выбор устройств<br/><i>есть «выбрать все»</i>"]

    A --> B
    B -->|файл| F --> C
    B -->|папка| G --> C
    C --> S --> LOOP

    subgraph LOOP["Для каждого выбранного IED"]
        direction TB
        R["Поиск блоков URCB / BRCB"]
        D["Разворот наборов данных (DataSet)<br/><i>FCDA → LD / LN / DO / DA / FC</i>"]
        T["Извлечение описаний сигналов<br/><i>desc из SCL: DAI → DOI → LN</i>"]
        R --> D --> T
    end

    LOOP ==> DOC["<b>ФОРМУЛЯР (.docx)</b><br/>обзорная сводка по устройствам •<br/>сводная таблица блоков •<br/>детально по каждому блоку"]
    LOOP --> CHK["<b>ЗАМЕЧАНИЯ ПО КОНФИГУРАЦИИ (.docx)</b><br/>наборы данных, триггеры/период,<br/>IP, пороговые рекомендации"]
    DOC --> SAVE["Сохранение документов на диск"]
    CHK --> SAVE

    style A fill:#F3F3F3,stroke:#888
    style B fill:#EDE7F6,stroke:#7E57C2,color:#311B92
    style F fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style G fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style C fill:#F3F3F3,stroke:#888
    style S fill:#EDE7F6,stroke:#7E57C2,color:#311B92
    style R fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style D fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style T fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style DOC fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style CHK fill:#FFF8E1,stroke:#F9A825,color:#E65100
    style SAVE fill:#FAFAFA,stroke:#AAA

Что внутри формуляра

Документ формируется с автоматически собираемым оглавлением (поле обновляется при открытии в Word). Дальше структура выстроена так, чтобы по ней одинаково удобно работали и наладчик, и интегратор верхнего уровня, и конечный заказчик (выполняющий приёмку).

Обзорная Сводная таблица по устройствам

Если в источнике несколько ИЭУ, документ начинается с верхнеуровневого среза: по строке на каждое устройство — имя (как гиперссылка на соответствующий раздел), описание, IP-адрес, число URCB и BRCB, всего блоков и объектов данных, плюс итоговая строка. Это «карта» всего комплекса: видно, сколько и каких отчётов настроено по объекту в целом, сколько всего сигналов передается на верхний уровень и др.

Раздел по каждому устройству

Внутри — три уровня детализации:

• Параметры устройства: имя, описание (из атрибута desc элемента IED) и таблица всех точек доступа с сетевыми параметрами (точка доступа / подсеть / IP / маска / шлюз).
• Сводная таблица блоков управления: по строке на блок — точка доступа, MMS-ссылка на блок, тип (БО/НБО), число экспонируемых экземпляров, активные триггеры (TrgOps) и опциональные поля (OptFlds), ссылка на набор данных, число объектов данных, время буферизации (BufTm) и интервал периодической рассылки (IntgPd). Здесь же сразу видно «проблемные» места: блоки без заданного набора данных подсвечиваются.
• Детальная информация по каждому блоку: отдельные подразделы — основные атрибуты, триггеры (с битовой строкой TrgOps), опциональные поля (с битовой строкой OptFlds), временны́е параметры с пояснениями, и наконец поэлементный состав набора данных, разложенный по колонкам LD / LN / DO / DA / FC.

Отдельно стоит сказать про индексированные блоки. По МЭК 61850‑6 один блок управления может разворачиваться в несколько независимых экземпляров (имя01 … имяNN, где число задаётся атрибутом RptEnabled max). Формуляр это учитывает: для каждого блока показано фактическое число экспонируемых экземпляров и их имена — то, с чем реально будет работать клиент верхнего уровня.

И самое ценное для читаемости — русскоязычные описания сигналов. К каждому элементу набора данных подтягивается текстовое описание из SCL (атрибут desc). Вместо абстрактного «MMXU1.A.phsA» в документе появляется человеческое пояснение из проекта — и смысл каждого отчёта складывается за секунды, без обращения к браузеру модели данных. Описания берутся строго из SCL, «как есть»: без перевода и без внешних справочников, чтобы документ точно отражал то, что заложено в конфигурации.

Замечания по конфигурации — отдельным документом

Помимо формуляра модуль формирует отдельный документ Замечания по конфигурации. Это лёгкий оффлайн-аудит: проверяются наборы данных (не задан / не найден в нужном логическом узле / пуст), согласованность триггеров и и параметров передачи данных, коммуникационный параметры (нет IP у точки доступа с блоками, дубли IP между устройствами) и пороговые рекомендации (слишком большой BufTm, слишком малый IntgPd). Каждое замечание имеет уровень — ошибка, предупреждение или рекомендация — и попадает в сводную таблицу с цветовой подсветкой. Полезно поймать типовые огрехи ещё на этапе подготовки документации, до передачи.

Зачем это нужно — на практике

Главная ценность — скорость и читаемость при передаче. Передаёте проект интегратору АСУ ТП или заказчику — и вместе с SCD/CID отдаёте понятный формуляр, по которому сразу видно, какие отчёты настроены, что в них входит и как они адресуются. Закрываете пусконаладку — тем же модулем в ПО Теквел Магия получаете исполнительную документацию по передаче телеинформации, аккуратную и единообразную по всему парку устройств. А поскольку модуль работает оффлайн, его удобно применять и в офисе при подготовке комплекта, и на площадке, и при передаче объекта между подрядчиками — там, где живого доступа к устройствам под рукой может и не быть.

В связке с кейсами #1 и #2 получается полный цикл: проверить соответствие SCD факту, снять текущее состояние отчётов по MMS — и сформировать читаемую документацию для передачи. «Как настроено», «как сейчас работает» и «как это объяснить другим» — три задачи, каждая в один прогон.

Пользуйтесь с удовольствием! И помните, иногда инжиниринг МЭК 61850 требует немного Магии :)