В одной из прошлых статей мы рассмотрели кейс, в котором ПО Теквел Магия» сравнивает конфигурацию наборов данных, отчётов и блоков управления передачей GOOSE и SV из файла SCL с реальной конфигурацией ИЭУ. Сегодня — другой кейс: как одним нажатием получить срез текущего состояния блоков управления передачей отчётов (URCB / BRCB) сразу по нескольким устройствам.

Зачем вообще копать в сторону RCB

Блоки управления передачей отчётов — это «контракт» между сервером (ИЭУ) и клиентами (SCADA, шлюзы, ПЛК верхнего уровня, инструменты диагностики). Сервер публикует данные через буферизуемые (BRCB) и небуферизуемые (URCB) блоки управления; клиент резервирует нужный блок, включает его (RptEna = true) и начинает получать события по факту изменения данных, качества или периодически (ну, или по запросу). На реальном объекте такие блоки зачастую в устройствах уже настроены, но кто их фактически использует на при реализации объекта — отдельный вопрос.

Бывают и совсем неприятные кейсы: отчёты в устройствах никем не заняты, а клиент верхнего уровня вместо подписки на события ходит по всем серверам периодическим опросом — банальным polling-ом. «Всё вроде работает», но событийная модель МЭК 61850, ради которой и затевался переход на цифровую подстанцию, фактически выключена. Растёт нагрузка на сеть, теряется детерминированность реакции, события «склеиваются» периодом опроса, а сам факт, что отчёты не используются, годами остаётся незамеченным — пока не случится разбор инцидента. Один прогон аудита показывает такое состояние мгновенно.

Какие из блоков сейчас активированы в устройствах на подстанции? Кто из клиентов их занял? Какие триггеры (TrgOps) и опциональные поля (OptFlds) заданы? Какие наборы данных к ним подвязаны и какой состав в этих наборах? Какое значение BufTm и IntgPd, и согласуются ли они с тем, что мы вообще ожидали увидеть в проектной документации? Эти вопросы привычно всплывают на приёмке объекта в эксплуатацию: представителям технических служб конечного заказчика важно убедиться, что отчёты реально работают и реально используются — а не «настроены, но висят без дела». Раньше такой срез собирался вручную: по крупицам — браузером модели данных, бумажными выписками, разговорами с интегратором. Теперь то же самое даёт один прогон.

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

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

  • ввести IP-адрес устройства вручную (когда SCD ещё не в руках или вы проверяете отдельную точку), либо
  • выбрать устройство из SCD-файла — в диалоге появится список ИЭУ с их именами и атрибутом desc (описаниями), с возможностью выбрать одно или сразу несколько.

Во втором случае ПО Теквел Магия само извлекает IP-адреса выбранных устройств из секции Communication (ConnectedAP / Address / P type="IP") и подключается к каждому из них по MMS. То есть на одном клике вы можете провести аудит использования отчетов, скажем, в восьми устройствах подряд — по каждому получите отдельный документ.

После установления MMS-ассоциации ПО читает полную модель данных устройства, находит все блоки URCB и BRCB, и опрашивает их атрибуты — RptID, RptEna, DatSet, ConfRev, OptFlds, BufTm, SqNum, TrgOps, IntgPd, GI, Resv, Owner (для URCB), плюс PurgeBuf, EntryID, TimeOfEntry, ResvTms (для BRCB). Параллельно Теквел Магия подтягивает состав каждого набора данных. По итогу — формируется MS Word-протокол.

Аудит блоков управления передачей отчётов в «Теквел Магия»
Рис. 1. Аудит блоков управления передачей отчётов в ПО Теквел Магия: сценарий теста с этапами «MMS Associate → чтение модели → поиск URCB/BRCB → формирование .docx → разрыв соединения» и журнал прогонов с результатами.

Что внутри протокола

Открыв документ, вы увидите автоматически собранное оглавление и три основных раздела: параметры подключения, сводную таблицу блоков и детальную информацию по каждому из них.

В сводной таблице — по строке на каждый RCB. Для каждого блока указаны:

  • ссылка на блок в информационной модели устройства (например, IEDName/LLN0$BR$Report01);
  • тип блока — БО (буферизируемый) или НБО (небуферизируемый);
  • состояние: RptEna = ВКЛ / ОТКЛ;
  • Owner — IP-адрес клиента-владельца, если блок занят и сервер экспонирует эту информацию. Owner у нас декодируется из «сырого» OCTET STRING в человеческий вид 192.168.0.42:5001, а если блок действительно свободен — в ячейке прочерк;
  • состав заданных триггеров (dchg, qchg, dupd, integrity, GI) и опциональных полей (SeqNum, TimeStamp, ReasonCode, DataSet, DataRef, BufOvfl, EntryID, ConfRev);
  • ссылка на используемый набор данных, время буферизации BufTm и период интегрирования IntgPd.

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

Фрагмент Word-протокола: параметры подключения, сводная таблица RCB, детальная информация
Рис. 2. Фрагмент итогового Word-протокола: параметры подключения, сводная таблица URCB/BRCB и начало детального раздела по конкретному блоку. Состояние RptEna и Owner подсвечены цветом, состав триггеров и опциональных полей разложен в отдельные колонки.

Дальше — детальная информация по каждому блоку. Здесь полный перечень атрибутов с описаниями, отдельные подразделы с расшифровкой битовых полей TrgOps и OptFlds (по биту на строку — что включено, что нет), временны́е параметры с пояснениями, что значит каждое значение, и наконец — поэлементный состав DataSet, разбитый на колонки LD / LN / DO / DA / FC. Если при подключении был выбран SCD-файл, к каждому FCDA дополнительно подтягивается текстовое описание (атрибут desc) — оно берётся прямо из SCL по соответствующему DOI. На практике это бесценно: вместо абстрактного «MMXU1.A.phsA.cVal.mag.f» вы сразу видите «Ток фазы A, ввод № 1» — и весь смысл отчёта складывается за пять секунд.

Документ собирается с оглавлением и автоматической нумерацией разделов.

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

В связке с ранее представленным модулем сравнения конфигурации (когда отчёты из SCD-файла сверяются с реальной конфигурацией ИЭУ) этот модуль закрывает вторую половину типичных вопросов АСУ ТП: «как настроено» дополняется фактом «как сейчас работает». На пусконаладке это сокращает время на разбор «почему не приходят события», на приёмочных — даёт легко проверяемый артефакт для приёмочной комиссии, в эксплуатации — позволяет периодически снимать состояние «кто куда подписан» по всему парку устройств за считанные минуты. И в особенно неприятных случаях помогает поймать главное: что событийная модель МЭК 61850 на объекте формально настроена, а фактически — не работает. Один запуск, один протокол, один разговор с подрядчиком — вместо десятка переписок и таблиц «на коленке».

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