Заводские данные под ML: каталог сигналов и миграция

Работа ML-инженера на производстве начинается не с признаков и метрик, а с вопроса, можно ли доверять источникам. Данные лежат в мануалах, электрических схемах, панели оператора, выгрузках от поставщика оборудования и в самих регистрах контроллера. Первый результат проекта — не модель, а каталог сигналов, у которого известны тип, способ чтения, смысл и происхождение.

Ниже — порядок работ, который мы применяем: как собрать источники, почему каталог важнее скорости, как устроен smoke-тест и какие ограничения на чтение действуют на живом оборудовании.

Что такое каталог сигналов

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

Шаг 1. Собрать источники, а не писать код

Заводские данные почти никогда не лежат в одном месте. Часть в мануалах, часть в электрических схемах, часть на панели оператора, часть приходит от поставщика линии, а часть проверяется только запросом к контроллеру.

Поэтому первым шагом идёт не обучение модели, а инвентаризация. На нашем проекте коллега собрал архив мануалов и электрических схем, из него отдельно выгрузили информацию по D-регистрам и общие сведения о станке. Полный разбор всего архива не делали — времени не было, и это нормально: даже частичная выгрузка в структурированный вид, markdown и JSON, меняет ситуацию принципиально.

Шаг 2. Почему каталог важнее скорости

В машинном обучении хочется быстрее получить таблицу вида «время, признаки, целевая переменная». На производстве брать адреса наугад нельзя: потом не восстановить, что искали и где.

По каждому адресу нужно знать шесть вещей:

Мы храним такие справочники как YAML-книги, из которых строится план чтения. Один и тот же каталог тогда работает и для проверки, и для будущего коллектора — не нужно поддерживать две версии правды.

Шаг 3. Smoke-тест: проверка вместо доверия

Smoke-тест берёт одну книгу каталога, достаёт из неё адреса, читает их с оборудования через MC/SLMP и сохраняет результат. Он не угадывает смысл сигнала и не делает выводов уровня «станок сейчас в таком-то режиме». Он отвечает на пять базовых вопросов:

1. Адрес читается или нет.
2. Какое у него текущее значение.
3. Есть ли ошибки по группе адресов.
4. Какая задержка чтения.
5. Можно ли включать этот тип сигналов в будущий коллектор.

Работа скучная, но именно она экономит недели. Если адрес не читается, узнать об этом надо на smoke-тесте, а не на середине сбора обучающего датасета, когда выяснится, что часть признаков пустая.

Шаг 4. Только чтение, без подвигов

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

• никаких команд записи;
• никакого форсирования;
• никаких сбросов;
• никакой групповой записи;
• только чтение;
• один поток чтения;
• одна активная сессия обмена;
• пауза между группами чтения.

Для выходов контроллера — только чтение состояния. Для регистров, связанных с параметрами, — чтение как слова, без записи в рецепты, приводы и прочие настройки.

Это выглядит избыточной осторожностью ровно до первого инцидента. Цена ошибки на линии несопоставима с удобством «заодно и переключим», а восстановление режима после случайной записи занимает не минуты.

Шаг 5. Куда складывать

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

Здесь важна дисциплина: массив связан с каталогом позицией, а не именем. Любое изменение каталога без миграции данных тихо сдвигает смысл всех накопленных выборок.

Как выглядит следующий слой — разбор аварийных битов и диагностическая цепочка — разобрано в материале о карте сигналов PLC. Что из этого даёт предприятию управленческий эффект, показано в разборе, зачем предприятию MES, а как проверять собранное глазами — в настройке мониторинга на Grafana и ClickHouse.

Чеклист

1. Собрать источники и выгрузить их в структурированный вид, не пытаясь разобрать всё сразу.
2. Завести каталог сигналов с типом, способом чтения, смыслом, уверенностью и источником.
3. Хранить каталог в формате, пригодном и для проверки, и для сборщика.
4. Прогнать smoke-тест по каждой книге до начала сбора датасета.
5. Зафиксировать read-only на уровне кода, а не инструкции.
6. Проверить задержки чтения до того, как задавать частоту опроса.
7. Связать позиции массива с каталогом и защитить эту связь миграцией.
8. Пометить гипотезы низкой уверенностью и не повышать её без подтверждения.

Частые ошибки

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

Разбирать архив документации целиком. Полный разбор откладывает проект на месяцы; структурированная выгрузка ключевой части даёт результат сразу.

Считать документацию истиной. Мануал описывает, как задумано; smoke-тест показывает, как есть.

Менять каталог без миграции. Сдвиг на одну позицию обесценивает весь накопленный массив, причём молча.

Оставлять сборщику права на запись. Даже если запись не используется сегодня, права переживут смену версии.

Что делать дальше

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