Коротко: в legacy-АСУ ТП конфигурационные файлы часто дают больше практической пользы, чем попытка сразу декомпилировать исполняемые модули. По ним можно восстановить точки, HMI-группы, физические каналы, блокировки, Modbus-адреса и границы между мониторингом и управлением.
Зачем вообще читать конфигурационные файлы
В большинстве проектов по legacy-АСУ ТП исходного кода нет. Есть только то, что осталось на носителях системы: исполняемые модули, файлы ресурсов и конфигурационные файлы. Именно конфигурационные файлы — самый доступный и при этом самый информативный слой.
В отличие от бинарных исполняемых модулей, конфигурация в большинстве промышленных систем часто хранится в читаемом текстовом формате. Это не случайность: конфигурацию должны были редактировать инженеры на этапе пусконаладки, иногда прямо на объекте, без полноценной среды разработки.
Из конфигурационных файлов можно получить полный список точек системы, структуру отображения на HMI, часть логики блокировок, маппинг на внешние устройства и топологию системы. Это уже достаточная база для первичного отчёта, оценки рисков и подготовки следующей фазы миграции.
Что такое amcfg.lst
amcfg.lst — главный конфигурационный файл системы аварийного мониторинга UMAS-V. По сути, это плоская база данных всех точек системы: входов, устройств, групп, строк HMI, блокировок и операторских текстов.
Типовая строка может выглядеть так:
Iono P.no Type Gr Li BlockBy Text
1618 1007 DI 1 50 0 DG1 PS PMS Alarm| Поле | Что означает |
|---|---|
Iono | Номер входа или канала в системе. Префикс часто помогает понять шкаф, модуль или физическую зону. |
P.no | Point Number — уникальный идентификатор точки, который используется для перекрёстных ссылок. |
Type | Тип точки: DI, AI, DO, DEV, S.IO, PAG и другие. |
Gr | Группа на HMI. Показывает, где логически живёт точка. |
Li | Строка внутри группы. Вместе с Gr задаёт позицию точки в операторском представлении. |
BlockBy | Номер точки, при активном состоянии которой текущая точка блокируется. 0 означает отсутствие такой блокировки. |
Text | Операторский текст точки. Именно его часто видят на экране или панели. |
Что искать в первую очередь
Подсчёт типов точек
Сначала нужно понять, сколько в системе DI, AI, DO, AO и служебных объектов. Это быстро показывает, является ли система только мониторинговой или действительно управляет исполнительными механизмами.
Анализ BlockBy
Все точки с BlockBy=0 активны без внешней блокировки. Точки с ненулевым BlockBy нужно связать с теми точками, которые их блокируют. Так появляется граф зависимостей и режимных ограничений.
Структура Gr и Li
Группировка по Gr показывает, как разработчик системы разделял объект: генераторы, ГРЩ, вспомогательные системы, системные параметры, панели, аварии. Распределение Li внутри группы помогает понять приоритет и порядок отображения.
Iono как след физического размещения
Префиксы Iono часто дают привязку к шкафам, модулям или физическим каналам. Группировка по этому полю помогает понять, какие сигналы живут рядом физически, а какие пересекают границы шкафов.
Что такое UmasV.txt
Если amcfg.lst отвечает на вопрос «что подключено», то UmasV.txt помогает понять, как система устроена и с чем она общается. В нём могут быть параметры контроллеров, сетевые настройки, Modbus-каналы и ссылки на файлы ввода/вывода.
Особенно важны секции, связанные с Modbus: COM-порт, скорость, чётность, стоп-биты, slave-адреса и тип протокола. Если эти параметры не перенести точно, новая система может иметь правильные теги, но не сможет получить данные с полевых устройств.
Отдельно нужно искать привязки к файлам уровня ioman. В таких файлах могут находиться параметры полярности контактов и активного уровня дискретных входов. Без них остаётся неясным, что означает единица на входе: норму или тревогу.
Типичные находки при анализе amcfg.lst
Архитектура «только чтение» у PMS-интерфейса
Если в группе, связанной с PMS, нет DO и AO, это сильный признак, что система мониторинга не управляет генераторами, а только принимает их состояние. Это важно: разработчику замены не нужно воспроизводить управляющую логику PMS, если исходная система её не выполняла.
Перекрёстный мониторинг критических тревог
Иногда точка физически приходит в один шкаф, а логически относится к зоне другого. Это может быть не ошибкой, а осознанной кросс-публикацией критической тревоги между узлами. Такое решение нужно заметить и отдельно описать в отчёте.
Параллельные каналы диагностики
Один объект может присутствовать несколько раз: через PMS, релейную защиту, контроллер двигателя или отдельный модуль. Это не обязательно дубль. Часто это разные источники информации об одном агрегате.
Граница между «нет данных» и «нет сигнала»
Если у целой группы точек BlockBy=0, это может быть системным решением: эти сигналы не должны подавляться никаким режимом. Для новой системы это превращается в требование к логике отображения и аларминга.
Смежные файлы: что читать вместе с amcfg.lst
| Файл | Что содержит | Почему важен |
|---|---|---|
UmasV.txt | Параметры контроллеров и Modbus-каналов | Без него неясно, как система общается с полевыми устройствами |
ioman009–ioman014 | Параметры I/O, полярность, активные уровни | Помогает понять смысл физического состояния входа |
mb-addr.sdv / modbus.dat | Таблицы Modbus-адресов | Даёт маппинг регистров по slave-устройствам |
lauer.dat | Тексты и элементы панелей оператора | Помогает восстановить, что видел оператор |
alarmdat.* | Базы тревог и событий | Дополняет картину аларминга и исторических событий |
Практическая последовательность анализа
- Откройте
amcfg.lstи подсчитайте количество строк. Это даст масштаб системы. - Разберите строки в таблицу: отдельные колонки для
Iono,P.no,Type,Gr,Li,BlockBy,Text. - Сгруппируйте точки по
Type, чтобы понять, система мониторит или управляет. - Сгруппируйте точки по
Gr, чтобы восстановить логическую карту HMI. - Найдите все точки с
BlockBy != 0и постройте граф зависимостей. - Сравните префиксы
Ionoс физическими шкафами, если доступны фото или схемы. - Откройте
UmasV.txtи выпишите все каналы связи, параметры портов и slave-адреса.
Ограничения конфигурационных файлов
Конфигурация показывает не всё. Она хорошо отвечает на вопросы «что подключено», «как сгруппировано», «как отображается» и «какие есть явные зависимости». Но она не всегда показывает алгоритмы фильтрации, задержки, внутреннюю обработку, квитирование тревог и поведенческую логику исполняемых модулей.
Для полной реконструкции поведения нужен следующий уровень: анализ бинарных модулей, понимание целевой архитектуры, проверка RTOS-окружения и сопоставление результата с документацией, логами и фактическими наблюдениями на объекте.
Вывод для разработчика замены
amcfg.lst и UmasV.txt — это фундамент для инженерного разбора legacy-АСУ ТП. По ним можно составить спецификацию I/O, структуру тегов, карту HMI, список Modbus-каналов, перечень неопределённостей и первичное ТЗ для следующей фазы.
Главное — не превращать конфигурационный анализ в гадание. Каждый вывод нужно маркировать: подтверждено файлом, вероятно по структуре, требует проверки, не удалось установить. Тогда результат можно безопасно передать в проектирование, а не оставить в виде набора догадок.
Есть пакет конфигов, дампов или старых файлов проекта?
Пришлите список файлов, фрагмент структуры папок и краткое описание системы. Мы оценим, что можно восстановить по конфигурационному уровню и где потребуется более глубокий инженерный разбор.
FAQ
Можно ли восстановить систему только по amcfg.lst?
Иногда можно восстановить значительную часть сигнальной карты и HMI-структуры. Но для полярности, таймингов, внутреннего поведения и управляющих алгоритмов обычно нужны дополнительные файлы.
Если есть только текстовые конфиги, это уже полезно?
Да. Даже неполный набор текстовых конфигов помогает оценить масштаб системы, типы сигналов, группы, физическое размещение и границы неопределённости.
RD[AI] публикует внутренние базы по таким системам?
Нет. В публичных статьях мы показываем методологию и общие принципы. Внутренние базы знаний и проектные артефакты заказчиков не публикуются.
Комментарии
Комментарии проходят модерацию и появляются на странице после подтверждения.
Загружаем комментарии...