Карта сигналов PLC: как подготовить станок к ML-диагностике
Диагностика на станке начинается не с модели, а со словаря сигналов. Пока адреса контроллера безымянны, любая аналитика учится на потоке битов без значения. Первый этап ML-проекта — собрать карту сигналов, разложить аварии по человеческому контексту и проверить чтение на живом оборудовании.
Что такое карта сигналов PLC
Карта сигналов PLC — это справочник, который связывает адрес программируемого контроллера (X, Y, M, D, W, GD) с его смыслом: типом сигнала, текстом аварии, категорией, экраном оператора, связанными устройствами и списком того, что проверять руками. Карта решает задачу перевода: она превращает запись вида «M6001 = 1» в событие, по которому можно принять решение. Для промышленного ML она же становится основой разметки данных — без неё обучать модель не на чем.
Материал собран на нашей работе с реальным станком: индекс на 4710 адресов, справочник аварий на 451 бит, smoke-тест чтения на действующем оборудовании. Ниже — порядок работ, цифры каждого этапа и правила безопасности, которые на производстве нарушать нельзя.
Почему «M6001 = 1» — это ещё не диагностика
Запись «M6001 = 1» сообщает единственное: включился внутренний бит с таким адресом. Оператору у станка это бесполезно, модели — тем более. Диагностика появляется там, где у адреса есть контекст: что за авария, к какой категории относится, на каком экране видна, какие сигналы с ней связаны и что проверять физически.
Вторая причина не работать с адресами напрямую: одинаковое значение у разных типов сигналов означает разные вещи. Единица на входе и единица на выходе — это разные события, и путать их дорого.
Что означают X, Y, M, D, W, GD
| Тип | Что это | Как читать значение |
|---|---|---|
| X | Входы контроллера | Датчики, кнопки, концевики, аварийные цепи |
| Y | Выходы контроллера | Состояние выходной команды, а не факт срабатывания механики |
| M | Внутренние биты | Аварии, события, промежуточные флаги |
| D, W, GD | Регистры и слова | Параметры, состояния, аналоговые значения |
| L/M внутри ladder | Промежуточные условия логики | Может не иметь физического источника вообще |
Самая опасная ошибка — делать вывод по адресу. Если Y320 = 1, это означает только, что контроллер держит выходную команду включённой. Не что механизм сработал и не что мы им управляем. Эту границу важно держать в голове на всех этапах работы.
Шаг 1. Сырой индекс с сохранением источника
Первым делом мы строим не сборщик данных, а раскладку: выгрузки, электрические схемы и карты сигналов разносятся по справочникам с сохранением связи на исходную строку документа. Индекс по нашему станку получился такой:
| Тип сигнала | Количество |
|---|---|
| X (входы) | 372 |
| Y (выходы) | 287 |
| M (внутренние биты) | 450 |
| D (регистры) | 3393 |
| W (слова) | 188 |
| GD | 20 |
| Всего | 4710 |
Читать такой индекс подряд бессмысленно — он нужен как аудит. У каждой записи хранится, откуда взят адрес, какой была исходная строка, какая у связи уверенность (confidence) и какой приоритет. Когда два документа противоречат друг другу, спор решается возвратом к источнику, а не памятью инженера.
Проверка на нашем проекте: после разбора дополнительных документов справочники почти не выросли. Добавился один вход X из электрической схемы, один аварийный бит M6475 вне основного диапазона и несколько регистров ошибок модулей. Новых физических входов и выходов сводная карта не дала — и это был нужный результат: справочники не разваливаются при добавлении источников.
Шаг 2. Книга аварий: 451 бит с человеческим контекстом
Самый полезный слой — аварийные M-биты. Мы довели справочник аварий до 451 бита (диапазон M6001–M6450 плюс M6475) и добавили к каждому поля, которых в исходных выгрузках нет:
- человекочитаемый текст аварии;
- категория;
- экран интерфейса, где авария видна оператору;
- связанные устройства, если они были в источниках;
- активные трассировки — 58 строк, часть с высокой уверенностью, часть с низкой;
- поля «что проверить» и «какой процесс затронут».
Низкую уверенность мы храним честно, а не округляем до факта. Модель, обученная на гипотезах, поданных как достоверные связи, ошибается молча — и разбираться придётся уже после ложной тревоги на линии. Тот же принцип действует при настройке детекции аномалий: порог, выставленный по непроверенной связи, даёт ложные срабатывания, которым потом перестают верить.
Шаг 3. Read-only для выходов: правило на уровне данных и кода
Y-выходы читать можно, трогать нельзя. Правило формулируется в четыре строки и выносится в код как ограничение, а не как договорённость:
- Y читаем;
- Y не пишем;
- Y не форсим;
- Y не используем как управляющий канал.
В коде сборщика не должно быть операций записи, форсирования, сброса и удалённого управления. На действующем производстве цена такой невнимательности несопоставима с удобством «а давайте заодно и переключим».
Шаг 4. Smoke-тест вместо доверия к документации
Excel-файлы, инструкции и записки из цеха проверяются чтением, а не принимаются на веру. Наш тест шёл через MC/SLMP 3E Binary, командой 0401 batch read в битовом режиме, только на чтение.
| Показатель | Результат |
|---|---|
| Запланировано Y-сигналов | 287 |
| Прочитано успешно | 287 из 287 |
| Циклов без ошибок | 287 из 287 |
| Batch reads успешно | 40 из 40 |
| Batch reads с ошибкой | 0 |
| Ошибок всего | 0 |
За пять циклов чтения активными были 61 Y-адрес, и четыре выхода меняли состояние прямо во время теста: Y081, Y084, Y1A0, Y32B. Это важнее нулевых ошибок: слой Y не просто формально доступен, он отражает живое состояние выходных команд контроллера. Если бы значения стояли неподвижно, это был бы повод искать ошибку в адресации, а не радоваться стабильности.
Какой командой читать: сравнение
| Команда | Назначение | Когда применять |
|---|---|---|
| 0401 | Batch read больших последовательных диапазонов | Основной сбор X/Y/M/L/D |
| 0406 | Чтение нескольких разнесённых блоков одним запросом | Нужные адреса лежат вразброс |
| 0403 | Чтение одиночных адресов | Редкие точечные проверки |
| 0801 + 0802 | Monitor registration и execution | Стабильный набор сигналов, есть ограничения |
| 0601 | Buffer memory intelligent-модулей | Аналоговый слой, если device memory не подтверждена |
| 0613 | Buffer memory Ethernet-модуля | Диагностика самой коммуникации |
Рядом с этим списком всегда лежит красная табличка: в протоколе существуют команды записи и удалённого управления. Перепутать их при невнимательной работе технически несложно.
Отдельный вопрос — на чём выполняется сборщик. Опрос контроллера, буферизация и первичная обработка живут на промышленном вычислителе у линии; подобрать его по характеристикам и бюджету можно в каталоге вычислителей и AI-модулей.
Диагностическая цепочка: Y → X → M
Наивная схема выглядит как «датчик сработал → авария включилась → причина найдена». Иногда так и есть, но часть аварий приходит через внутреннюю логику: servo-биты, L/M-условия, регистры D и W или вовсе без понятного физического источника.
Рабочая последовательность другая. Контроллер выдал команду (Y) → проверяем, пришла ли обратная связь (X) → если не пришла, смотрим, какая авария поднялась (M) → получаем её текст, категорию и экран → смотрим связанные сигналы и внутренние условия → получаем список того, что проверять руками.
Это уже не сбор данных, а перевод с языка контроллера на человеческий. Именно он потом становится разметкой для модели. Следующий этап — чеклист запуска предиктивного обслуживания, требования к самим данным разобраны в материале о том, какие данные нужны для цифрового двойника, а стыковка с производственными системами — в разборе интеграции AI-модуля в MES/SCADA. Как навести порядок в источниках до сбора — в материале о том, как привести заводские данные под ML; зачем сигналу нужен физический контекст — в разборе подготовки станка к ML; как смотреть на собранный поток — в инструкции по мониторингу PLC на Grafana и ClickHouse.
Порядок работ: чеклист
- Собрать сырой индекс всех адресов, не теряя ссылку на источник каждой записи.
- Разделить сигналы по смыслу: входы, выходы, аварии, регистры, внутренние условия.
- Не читать всё подряд — сначала определить, что можно читать и зачем.
- Для аварий завести человеческий контекст: текст, категорию, экран, связи, что проверить.
- Для Y зафиксировать read-only и на уровне данных, и на уровне кода.
- Хранить confidence: гипотетическая связь должна быть помечена как гипотеза.
- Проверить чтение smoke-тестами по каждому справочнику.
- Не смешивать наблюдение и управление ни в архитектуре, ни в правах доступа.
Частые ошибки
Начинать с модели, а не со словаря сигналов. Нейросеть, предсказывающая аварию за час, выглядит убедительнее справочника на 4710 строк. Но обучать её не на чем, пока биты безымянные.
Считать выход подтверждением действия. Y — это команда контроллера. Подтверждение приходит по входу X, и разрыв между ними сам по себе диагностический признак.
Терять источник записи. Индекс без ссылки на исходный документ невозможно перепроверить: при первом же противоречии между выгрузками спор упирается в память инженера.
Записывать гипотезы как факты. Связь без подтверждения должна нести низкий confidence, иначе ошибка всплывёт после ложной остановки линии.
Подключать сборщик с правами на запись. Даже если записи нет в коде сегодня, права остаются — и следующая версия сборщика может ими воспользоваться. Ограничение ставится на уровне доступа, а не намерений.
Что делать дальше
Начните не с выбора модели, а с инвентаризации: выгрузите адреса контроллера и посчитайте, у скольких из них есть человекочитаемое описание и подтверждённый источник. Эта доля и есть реальная готовность станка к предиктивному обслуживанию — всё остальное считается уже от неё. Если доля ниже половины, следующий шаг проекта не модель, а справочник.