Реверс-инжиниринг конфигурационных файлов АСУ ТП: amcfg.lst и UmasV.txt

Зачем начинать с конфигурационных файлов

В legacy-АСУ ТП часто остаются исполняемые модули, текстовые конфигурации, ресурсы HMI, журналы и фрагменты проектной документации. Текстовые конфигурации удобны для первичной инвентаризации: из них можно извлечь повторяющиеся поля, связи и ссылки на другие файлы, а затем собрать проверяемый перечень исходных данных.

Этот этап не заменяет физический реверс, проектирование, пусконаладку или подтверждение алгоритмов. Его задача — отделить то, что прямо записано в файле, от гипотез и от сведений, которых в архиве нет.

Какие поля искать в amcfg.lst

В архивах UMAS-V и сходных систем файл с именем amcfg.lst может содержать строки точек, групп, экранных позиций и ссылок на блокировки. Набор полей и их семантика зависят от версии системы; трактовку каждого поля следует подтверждать по доступной документации или связанным файлам.

Iono    P.no    Type    Gr    Li    BlockBy    Text
1618    1007    DI      1     50    0          DG1 PS PMS Alarm

Строка конфигурации может быть сведена к карточке: исходный файл, строка, исходные поля, нормализованное имя, возможная связь с I/O или HMI и статус проверки. Такая карточка позволяет обсуждать конкретную запись, а не интерпретацию «по памяти».

Что может содержать UmasV.txt

Файл UmasV.txt или аналогичный системный конфигурационный файл может содержать параметры контроллеров, интерфейсов, портов, сетевых подключений и ссылки на таблицы ввода-вывода. Наличие строки в конфигурации подтверждает наличие записи в архиве, но не подтверждает, что канал сейчас подключён или работает.

Какие файлы нужны рядом с конфигурацией

Как подготовить структуру передачи для внешнего подрядчика

1. Инвентаризировать архив. Зафиксировать дерево папок, имена файлов, размеры, даты и доступные версии. Не менять исходные файлы и не переименовывать их в рабочей копии.

2. Выделить повторяющиеся структуры. Для каждой записи сохранить исходный файл, строку или секцию, поля, текст и явные ссылки. Если формат неясен, это отмечают как ограничение, а не заполняют предположением.

3. Собрать реестр точек и связей. В одном наборе данных удобно хранить идентификатор, тип, HMI-группу, связь с другими точками, связанный файл и статус. Пример статусов: подтверждено файлом, требует проверки, недостаточно данных.

4. Разделить факты и выводы. Значение, прямо записанное в конфигурации, сохраняется как факт файла. Предполагаемая роль сигнала, связь со шкафом или трактовка алгоритма фиксируются отдельно с основанием и уровнем уверенности.

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

Что остаётся неизвестным без дополнительных данных

• Фактическое подключение к полевому оборудованию и состояние кабельных цепей.
• Полярность дискретных входов, если она не подтверждена связанными файлами и схемами.
• Задержки, фильтры, тайминги, квитирование и часть алгоритмов, реализованных в исполняемых модулях.
• Работоспособность канала, устройства или HMI без журналов, диагностики и проверки на объекте.
• Соответствие сохранённой версии архива действующей системе после последующих изменений.

Кто принимает решение дальше

RD[AI] подготавливает структурированный набор исходных данных, ссылки на файлы и перечень неопределённостей. Заказчик подтверждает состав архива, историю изменений и связь записей с объектом. Проектировщик или внешний подрядчик определяет целевую архитектуру, выполняет проектирование и принимает технические решения. RD[AI] не выполняет физический реверс, не выпускает РКД, не подтверждает работоспособность системы и не проводит ПНР.

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

FAQ

Можно ли восстановить систему только по amcfg.lst?

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

Если есть только текстовые конфиги, это уже полезно?

Да. Они позволяют начать инвентаризацию, выделить повторяющиеся структуры, найти связанные файлы и подготовить вопросы к владельцу системы или внешнему подрядчику. Полнота результата зависит от состава архива и доступной документации.

Можно ли переносить параметры интерфейса из UmasV.txt без проверки?

Нет. Параметры из сохранённой конфигурации используют как исходные данные для сверки. Их применимость к действующей системе подтверждают по версии архива, документации, диагностике и сведениям владельца объекта.

RD[AI] публикует внутренние базы по таким системам?

Нет. В публичных статьях RD[AI] показывает методологию и общие принципы. Внутренние базы знаний и проектные материалы заказчиков не публикуются.