ИИ на каждом этапе реверс-инжиниринга
Инструменты по стадиям и измеримое сокращение трудоёмкости.
Реверс-инжиниринг · АСУ ТП
Реверс-инжиниринг АСУ ТП: как восстановить документацию на оборудование, когда исходников нет
Система работает, вендор ушёл, исходники и документация утеряны. Разбор начинается не с декомпилятора, а с инвентаризации того, что осталось: конфигурации PLC и HMI, экспорты тегов, чертежи, паспорта, фотографии шкафов.
Коротко: за 5 рабочих дней из неполного набора файлов собирается проверяемая модель фактического состояния системы: реестр оборудования и шкафов, карта сигналов и тегов, реестр документов, описание восстановленной логики, журнал конфликтов и пробелов. У каждого значения виден источник — файл, лист, строка, позиция — и статус уверенности. Ниже: пять стадий разбора, границы метода, типичные ошибки и оценка трудоёмкости.
Ситуация, с которой обращаются
Формулировки заказчиков отличаются, состояние данных почти всегда одинаковое:
- контроллер снят с поддержки, но продолжает работать в основном технологическом контуре;
- проектная организация ликвидирована, исходный проект не передавался или не сохранился;
- бэкап PLC есть, но неизвестно, какая версия соответствует текущему состоянию линии;
- логика уставок и алармов живёт только в коде, а те, кто её задавал, в компании уже не работают;
- шкафы переделывались десять лет, и ни одна схема не совпадает с фактическим монтажом.
Внешне это выглядит как проблема оборудования, фактически — как проблема данных. Пока система работает, отсутствие описания терпимо. В момент отказа, модернизации, смены подрядчика или экспертизы проект останавливается: смету и техническое задание строить не на чем.
Отдельный случай — уход производителя с рынка и потеря официальной поддержки. Что делать с обслуживанием в этой ситуации, разобрано в статье «Производитель ушёл из России: как восстановить поддержку АСУ ТП без вендора».
Что такое реверс-инжиниринг АСУ ТП в инженерном смысле
Реверс-инжиниринг — системное исследование готовой системы, чтобы понять её устройство и восстановить описание: архитектуру, алгоритмы, логику работы, документацию. В промышленном контуре это законная процедура, когда владелец имеет права на систему, а исходники утеряны или созданы на устаревших платформах.
В поиске одним словом называются два разных занятия, и их важно разделять:
| Признак | Реверс-инжиниринг деталей | Реверс-инжиниринг АСУ ТП |
|---|---|---|
| Объект | Физическое изделие, узел, сборка | Система управления и её данные |
| Метод | 3D-сканирование, обмер, восстановление КД | Разбор конфигураций, кода, тегов, документов |
| Результат | Модель и конструкторская документация | Состав системы, сигналы, логика, реестр документов |
| Заказчик | Конструкторское подразделение | Служба АСУ ТП, главный энергетик, интегратор |
RD[AI] работает со вторым. Подмена одного другим приводит к тому, что заказчик получает трёхмерную модель шкафа вместо описания логики, которая в этом шкафу работает.
Пять стадий разбора
Порядок обязателен: до декомпилятора нужно исчерпать все текстовые источники. Это правило снимает большую часть трудоёмкости ещё до того, как кто-то откроет бинарный файл. Детальный разбор инструментов по стадиям — в статье «ИИ на каждом этапе реверс-инжиниринга: конкретные задачи и измеримый выигрыш».
Стадия 1. Инвентаризация того, что осталось
Вход — папка с файлами неизвестного происхождения: конфигурации, экспорты, бэкапы, сканы, фотографии, переписка. Задача — построить карту: что здесь есть, как связано, чего не хватает. Ручная инвентаризация неизвестного массива занимает 2–3 дня, с моделями большого контекста — 1–2 часа.
На этой же стадии фиксируется то, что существует только в памяти персонала: недокументированные участки логики выявляются через интервью со службой обслуживания и операторами, фактический монтаж шкафов — через фотофиксацию. Если этого не сделать, знание уходит вместе с человеком, а не попадает в комплект.
Стадия 2. Извлечение данных из технических руководств и конфигураций
Самое зрелое применение ИИ: читаемый текст с предсказуемой структурой. Здесь восстанавливаются адреса каналов, группы алармов, уставки и маршрутизация сообщений, описания модулей, кросс-референции между десятками файлов и спецификации проприетарных форматов по примерам строк.
| Задача | Вручную | С моделью и проверкой инженера |
|---|---|---|
| Понять формат незнакомой конфигурации на 500+ строк | 4–8 часов | 30–60 минут |
| Собрать функциональную спецификацию из набора конфигураций | 3–5 дней | 4–8 часов |
| Найти все зависимости одного сигнала | 1–2 часа | 5–10 минут |
| Восстановить спецификацию обмена по дампу трафика | 2–3 дня | 4–8 часов |
Практический пример разбора конкретных проприетарных конфигураций — в техническом материале «Реверс-инжиниринг конфигурационных файлов АСУ ТП: amcfg.lst и UmasV.txt».
Стадия 3. Распознавание чертежей и схем
Здесь принципиально различие между OCR и разбором графики. OCR читает текст. Разбор схемы читает саму схему: распознаются символы оборудования, приборы и линии, после чего восстанавливается топология связей, а не только подписи. Точность распознавания типовых символов у передовых моделей превышает 98%, построение иерархии активов автоматизируется примерно на 70–80%, остальное помечается на инженерную проверку.
Отсюда прямое следствие для планирования: распознавание чертежей ИИ сокращает ручной ввод, но не отменяет верификацию. Поэлементная проверка до попадания данных в реестр остаётся частью работ и включается в срок.
Стадия 4. Восстановление логики и протоколов
Когда часть системы понятна только по поведению, правила извлекаются в форме «если условие, то действие» и становятся основой для нового кода. Для неизвестного протокола обмена задача сводится к восстановлению спецификации из трафика. Нормализация обозначений сигналов, которая выполняется на этой же стадии, описана в статье «Нормализация тегов SCADA, PLC и EAM: что это и зачем».
Стадия 5. Сборка комплекта
Финал — не набор наблюдений, а передаваемый комплект документов и данных. Формат согласуется до начала работ: Excel, CSV, JSON, XML, Markdown, DOCX или схема API. Идентификация объектов строится на Master ID — как именно, разобрано в статье «Master ID для промышленного оборудования».
Источник у каждого значения
Реверс-инжиниринг производит утверждения о системе, которая находится в эксплуатации. Утверждение без источника здесь опасно: по нему могут заменить модуль, изменить уставку или заложить объём в смету. Поэтому каждое существенное значение сопровождается происхождением и статусом уверенности.
source:direct
confidence:medium
confidence:high
source:missing
Объект: Насос ЦНС-60 Master ID: PUMP-CNS60-01 ───────────────────────────────────────────────────────── Паспорт: «ЦНС 60-198» → passport_1987.pdf, стр. 4 P&ID: P-07A → unit_3_pid_revB.pdf, лист 12 SCADA: PMP_007 → scada_tags_export.csv, строка 418 EAM: EQ-2847 → equipment_export.xlsx, «Assets», строка 923 ───────────────────────────────────────────────────────── Статус связи: требует подтверждения инженером Причина: в P&ID другая производительность насоса
- Источник не теряется — у критичных данных остаётся ссылка до файла, листа, строки, позиции.
- Конфликт не маскируется — противоречия попадают в реестр, а не «исправляются» моделью без объяснения.
- Автоматизация не подменяет инженера — система предлагает связи и кандидаты на совпадение, решение по физическому объекту принимает специалист заказчика.
Мы не удаляем дубли. Мы находим кандидаты на дубли, показываем источники и различия: разные строки с похожими названиями могут описывать разные физические объекты. Как это устроено на уровне метода — на странице Метод.
Где метод не помогает
Границы, которые фиксируются до старта
- обфусцированный бинарный файл модели распознают заметно хуже;
- на бинарных файлах без символьной информации восстановление типов и имён слабое;
- правдоподобный, но неверный вывод в контуре безопасности опаснее отсутствия вывода, поэтому инженерная верификация обязательна;
- разбиение больших бинарных файлов на фрагменты ломает межфункциональные зависимости;
- отсутствующий документ остаётся в реестре как дефицит данных и не заменяется предположением.
Мы также не выполняем пусконаладку, не проектируем АСУ ТП под ключ и не заменяем интегратора. Результат разбора — проверяемый вход в его проект. Сценарии применения результата описаны в разделе Применение.
Типичные ошибки заказчика
Ошибка 1. Начинать с бинарного файла
Декомпиляция запускается первой, хотя основная часть нужной информации лежит в текстовых источниках: конфигурациях, экспортах тегов, руководствах. Работа удорожается без изменения результата.
Ошибка 2. Передавать весь архив целиком
На вход отдаётся 40 ГБ без описания, время уходит на разбор мусора. Ограниченная выборка из 100–150 характерных файлов даёт такую же оценку состояния данных за меньший срок.
Ошибка 3. Ждать один документ вместо реестра
Запрос «сделайте нам схему» приводит к красивому файлу, который нельзя загрузить в систему. Загружается реестр с идентификаторами и связями, а схема — производная от него.
Ошибка 4. Считать распознавание чертежей готовым результатом
Автоматическое распознавание закрывает 70–80% построения иерархии. Если этап проверки не запланирован, ошибки уезжают в EAM и всплывают на приёмке.
Ошибка 5. Не фиксировать конфликты
Когда паспорт и P&ID расходятся, возникает соблазн молча выбрать более правдоподобное значение. В эксплуатации это приводит к неверной уставке или неверной запчасти. Расхождение должно попасть в журнал с обоими источниками.
Ошибка 6. Не согласовать формат передачи до старта
Формат выгрузки определяется требованиями принимающей системы. Согласование задним числом означает повторную сборку комплекта.
Что получает команда на выходе
| Результат | Для кого | Как используется |
|---|---|---|
| Реестр оборудования, шкафов, контроллеров с Master ID | Служба АСУ ТП | Основа обследования и технического задания |
| Карта сигналов, тегов, I/O и обозначений | Интегратор | Оценка объёма миграции SCADA |
| Реестр документов, версий и комплектности | Эксплуатация, СУИД | Поиск актуальной ревизии схемы |
| Описание восстановленной логики и уставок | Проектная команда | Реализация на новой платформе |
| Журнал конфликтов, пробелов и вопросов | Заказчик | Управляемые решения вместо сюрпризов в проекте |
Комплект принят, если
- каждая запись реестра имеет ссылку до файла и позиции в нём;
- каждое спорное значение имеет статус уверенности и причину;
- все конфликты вынесены в отдельный журнал, а не устранены молча;
- перечень отсутствующих документов передан списком;
- данные отдаются в согласованном открытом формате без ручной доработки.
Сколько занимает работа
| Ситуация | Оценка |
|---|---|
| Есть бэкап PLC и экспорт тегов, документы частично сохранились | 3–5 рабочих дней на выборку |
| Есть конфигурации, документов нет, платформа известна | 5–10 рабочих дней |
| Только чертежи и паспорта в сканах, конфигураций нет | от 10 рабочих дней, объём зависит от качества сканов |
| Нет ни исходников, ни документов, восстановление по поведению системы | оценивается после инвентаризации |
Передавать весь архив не нужно. Достаточно выборки, по которой видно состояние данных: бэкап PLC или конфигурация HMI, экспорт тегов, 5–10 чертежей или схем, паспорта, фотографии шкафов, ранее выпущенные документы. Условия первого шага и состав результата — на странице Метод.
Перед модернизацией АСУ ТП или заменой SCADA сначала соберите реестр сигналов, источников и пробелов. Без него объём проекта оценивается по памяти персонала, а не по данным.
Частые вопросы
Законно ли выполнять реверс-инжиниринг своей АСУ ТП?
Речь о ситуации, когда владелец имеет законные права на систему, исходники утеряны или созданы на устаревших платформах, а цель — эксплуатация, обслуживание или безопасная модернизация. Состав материалов, место обработки и круг участников согласуются до передачи данных.
Можно ли восстановить документацию, если остались только фотографии шкафов и бэкап контроллера?
Да, с ограничениями. Из бэкапа и конфигураций восстанавливаются состав, каналы, теги и значительная часть логики. Фотографии используются для сверки фактического монтажа. То, что не подтверждается ни одним источником, попадает в реестр пробелов, а не достраивается предположением.
Насколько точно ИИ распознаёт чертежи и P&ID?
Для типовых символов точность передовых моделей превышает 98%, построение иерархии активов автоматизируется на 70–80%, остальное уходит на инженерную проверку. Поэтому этап верификации планируется всегда, а уверенность по каждому элементу размечается явно.
Чем это отличается от оцифровки архива?
Оцифровка переводит бумагу в файлы. Реверс-инжиниринг АСУ ТП создаёт данные: объекты, сигналы, связи, логику и Master ID с трассируемостью до источника. Из файлов нельзя собрать реестр, из данных можно собрать любой нужный формат.
Кто должен участвовать со стороны заказчика?
Инженер АСУ ТП, который знает систему в эксплуатации, и ответственный за документацию. Первый подтверждает спорные связи, второй передаёт материалы и принимает комплект.
Что делать с результатом дальше?
Реестры и карты сигналов уходят в проект модернизации, в EAM или ТОиР, в базу знаний. Сценарии описаны в разделе Применение.