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

Зачем вообще эмулировать устройство

Передача телеинформации по МЭК 61850 — это всегда две стороны: устройство-сервер (ИЭУ РЗА, контроллер присоединения, измерительный преобразователь), которое формирует отчёты по MMS, и клиент верхнего уровня (сервер телемеханики, SCADA), который на эти отчёты подписывается и отображает их оператору. Первую сторону в проекте обычно проверяют вдоль и поперёк. А вот приёмную сторону — как именно верхний уровень принимает, разбирает и показывает отчёты — проверить куда сложнее.

Причина простая: чтобы честно испытать клиента, нужен работающий сервер, который выдаёт нужные данные в нужный момент. И тут начинаются трудности:

  • Некоторых устройств ещё нет на объекте или они еще не налажены в полном объеме. Настройка и приёмка верхнего уровня часто идут параллельно с конфигурированием или даже поставкой некоторых устройств — а иногда и с опережением. Проверять верхней уровень не на чем.
  • Устройство есть, но нужного состояния из него не добиться. Как заставить реальный терминал выдать bad-state по положению выключателя, качество questionable или флаг test — да ещё в контролируемой последовательности? На боевом устройстве это либо невозможно, либо небезопасно (например, потому что присоединения энергообъекта уже введены в работу).
  • Нужно воспроизвести редкий сценарий. Потеря и восстановление достоверности, подмена значений — такие ситуации на реальном объекте просто не создать.

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

Веб-панель симулятора MMS-сервера: общий вид
Рис. 1. Веб-панель симулятора: состояние блоков управления экспонируемого сервера, структура наборов данных, управление значениями и качеством сигналов, лента изменений, журнал операций.

Место в серии сценариев испытаний АСУ ТП: читать, показывать, документировать — и сыграть за устройство

Чтобы не путать близкие задачи, удобно держать в голове разделение по всей серии сценаиев проверки, касающейся АСУ ТП:

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

Ключевое отличие четвёртого кейса — он активный. Первые три работают с тем, что уже существует: читают, сравнивают, показывают, документируют. Здесь Магия впервые не наблюдает за трафиком, а сама его создаёт — выступает сервером МЭК 61850 и играет роль устройства, которого на объекте может ещё и не быть или оно может быть еще не сконфигурировано. Это переносит фокус проверки с устройства на верхний уровень: не «правильно ли настроено ИЭУ», а «правильно ли принимает и отображает данные тот, кто стоит выше».

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

Сценарий максимально короткий. Запускаете модуль — и в первом диалоге выбираете файл SCL: это может быть отдельный CID/ICD с одним устройством или подстанционный SCD с несколькими десятками ИЭУ. Если устройств в файле несколько, модуль предложит выбрать одно — то, за которое будет «играть».

Дальше всё происходит автоматически: модуль поднимает MMS-сервер по модели данных выбранного устройства и открывает в браузере панель управления. С этого момента для любого клиента верхнего уровня в сети симулятор неотличим от настоящего ИЭУ: у него та же модель данных, те же блоки управления отчётами, те же наборы данных и адрес из SCL.

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

flowchart TB
    A["Запуск модуля"]
    F["Выбор файла SCL<br/><i>CID / ICD / SCD</i>"]
    S["Выбор устройства<br/><i>если в файле несколько IED</i>"]
    P["Проверка: есть ли RCB<br/>с наборами данных?"]
    B["Поднятие MMS-сервера<br/><i>модель выбранного IED</i>"]
    C["Внутренний клиент<br/><i>readback + фоновый опрос</i>"]
    W["Веб-панель<br/><i>открывается в браузере</i>"]

    A --> F --> S --> P --> B
    B --> C
    B --> W
    W ==> ACT

    subgraph ACT["Действия инженера в панели"]
        direction TB
        V["Изменение значений сигналов"]
        Q["Изменение качества (validity / test / source)"]
        AC["Автоперебор значений и качества"]
        V --> RPT
        Q --> RPT
        AC --> RPT
        RPT["Отчёты dchg / qchg по MMS"]
    end

    ACT ==> EXT["<b>КЛИЕНТ ВЕРХНЕГО УРОВНЯ</b><br/>АСУ ТП / шлюз / АСДУЭ —<br/>принимает и отображает отчёты"]

    style A fill:#F3F3F3,stroke:#888
    style F fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style S fill:#EDE7F6,stroke:#7E57C2,color:#311B92
    style P fill:#EDE7F6,stroke:#7E57C2,color:#311B92
    style B fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style C fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style W fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style V fill:#FFF8E1,stroke:#F9A825,color:#E65100
    style Q fill:#FFF8E1,stroke:#F9A825,color:#E65100
    style AC fill:#FFF8E1,stroke:#F9A825,color:#E65100
    style RPT fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style EXT fill:#E8F5E9,stroke:#43A047,color:#1B5E20
Рис. 2. Алгоритм работы симулятора: от выбора SCL-файла до потока отчётов на верхний уровень.

Отдельно стоит отметить работу с подстанционным SCD. По МЭК 61850‑6 такой файл описывает десятки устройств в одной модели — и напрямую поднять из него сервер по одному ИЭУ нельзя. Модуль решает это сам: выделяет выбранное устройство во временный одно-устройственный файл, аккуратно разбираясь с точками доступа (в том числе с конструкцией ServerAt, когда одна точка ссылается на сервер другой). Инженеру об этом думать не нужно — достаточно указать имя устройства.

И еще момент - ПО Теквел Магия может экспонировать симулируемое устройство по его IP-адресу, извлеченному из файла SCL. Это также важно.

Что умеет панель управления

Панель открывается в обычном браузере и обновляется в реальном времени. Внутри — несколько согласованных блоков.

Состояние блоков управления отчётами, экспонируемых симулируемым устройством. Таблица всех блоков — буферизируемых (BRCB) и небуферизируемых (URCB) — с их живым состоянием: RptEna, SqNum, EntryID, Owner, признак общего опроса (GI), время последнего события, набор данных, активные триггеры (TrgOps) и опциональные поля (OptFlds). Видно, какой клиент на какой блок подписался и что реально включено.

Таблица «Состояние Report Control Blocks» с подписанным клиентом
Рис. 3. Живое состояние блоков управления отчётами: видно, кто подписан и какие триггеры активны.

Управление значениями. Сигналы сгруппированы по наборам данных. Для каждого объекта данных панель сама подбирает удобный ввод: выпадающий список для дискретных сигналов (положение выключателя — off/on/intermediate/bad-state), числовое поле для измерений. Многофазные величины (WYE/DEL/SEQ) записываются сразу по всем фазам. Каждая запись проверяется обратным чтением — то, что вы видите в панели, гарантированно ушло в модель и в отчёт.

Управление качеством. Отдельная форма на каждый сигнал: validity (good / invalid / questionable), флаги test и operatorBlocked, источник process/substituted. Любое изменение качества порождает отчёт qchg — именно то, что нужно, чтобы проверить, как верхний уровень отображает недостоверность и тестовые данные.

Управление значениями и качеством сигналов набора данных
Рис. 4. Управление значениями и качеством сигналов: ввод подстраивается под тип объекта данных.

Лента изменений и журнал операций. Каждое изменение значения или качества фиксируется в хронологической ленте — с текущим значением, текущим качеством и отметкой времени. Отдельно ведётся журнал действий оператора. Ничего не теряется, даже если изменения идут быстрее, чем обновляется страница.

Автоперебор — массовая проверка сценариев в один клик

Ручное переключение хорошо для точечной проверки, но когда нужно прогнать сигнал по всем состояниям — или проверить сразу весь набор данных — на помощь приходит автоперебор. Отмечаете сигналы галочками, задаёте интервал и число циклов — и модуль сам циклически проходит по всем осмысленным значениям каждого сигнала в зависимости от его типа (CDC):

  • дискретные (DPC/DPS): off → on → intermediate → bad-state;
  • одиночные (SPC/SPS/ACT): false → true;
  • перечислимые и целочисленные (INS/ENS): по ряду значений;
  • измерения (MV/CMV/WYE/DEL/SEQ): по ряду значений.

Включив опцию «+ качество», после каждого значения можно дополнительно прогонять последовательность состояний достоверности: invalid → questionable → good+test → good+operatorBlocked → good+substituted → и обратно в good. Так за один запуск верхний уровень получает полный спектр комбинаций «значение × качество» — идеально, чтобы проверить отображение всех состояний разом. Перебор можно поставить на паузу или остановить; при остановке качество всех сигналов аккуратно возвращается в good, чтобы модель не осталась в «испорченном» состоянии.

Панель автоперебора значений и качества
Рис. 5. Автоперебор значений и качества: массовая проверка сценариев по одному набору данных или сразу по всем.

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

Главная ценность — возможность проверять верхний уровень тогда, когда это удобно, а не когда «повезёт» с трафиком от реальных устройств.

Наладка верхнего уровня с опережением. Устройства ещё в пути, а сервер телемеханики или SCADA уже нужно настраивать и проверять. Симулятор из проектного SCD играет за будущее устройство — маппинг сигналов, подписки на отчёты и отображение можно отладить заранее.

Верхний уровень внедряют, когда шкафы уже в эксплуатации. Частая ситуация: шкафы РЗА и АСУ ТП присоединения давно введены в работу, а расширение или модернизация верхнего уровня (нового сервера АСУ ТП, шлюза, диспетчерского пункта) выполняется позже. Инициировать изменения сигналов с боевых устройств, чтобы проверить приём на верхнем уровне, уже нельзя — оборудование под нагрузкой, и вмешиваться в его работу недопустимо. Симулятор снимает это ограничение: он выступает «дублёром» действующего устройства по его же SCL-конфигурации, и все нужные изменения — положения, измерения, качество — инициируются с него, не затрагивая реальные шкафы в эксплуатации.

Проверка отображения качества и тестовых данных. Как оператор увидит сигнал с качеством invalid? Отфильтрует ли верхний уровень данные с флагом test? Симулятор позволяет выставить любое сочетание битов качества и посмотреть реакцию — то, что на боевом устройстве воспроизвести практически нереально.

Воспроизведение редких и «неудобных» сценариев. Промежуточное положение выключателя, недостоверность и её снятие, серия быстрых изменений — всё это задаётся из панели или прогоняется автоперебором в контролируемой последовательности.

Обучение и демонстрация. Симулятор — наглядный стенд для обучения персонала работе с отчётами МЭК 61850 и для демонстрации того, как передача телеинформации выглядит «в динамике».

В связке с предыдущими кейсами получается хороший набор тестовых сценариев для современного специалиста АСУ ТП. Кейс #1 проверяет, что устройство настроено по проекту; кейс #2 показывает, как отчёты работают сейчас; кейс #3 формирует читаемую документацию; а кейс #4 позволяет сыграть за устройство и убедиться, что верхний уровень принимает и отображает всё правильно. «Как настроено», «как сейчас работает», «как это объяснить другим» — и, наконец, «как это примут на том конце».

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