Автоматизация на предприятии — это не «скрипт, который кликает кнопки в Excel». В промышленности это контур, который должен работать в смену, когда оператор занят, сеть нестабильна, а простой линии стоит дороже месяца разработки. Запросы «разработка автоматизации», «ПО для автоматизации производства» и «интеграция оборудования» обычно скрывают одну задачу: связать датчики, контроллеры, учёт и людей в предсказуемый процесс с прозрачной ответственностью за каждое действие.
Ниже — как спроектировать такой контур, какие технологии выбирать и где чаще всего ломаются внедрения.
Где заканчивается Excel и начинается система
Автоматизация окупается, когда выполняется хотя бы два условия из списка:
- данные с линии нужны не раз в сутки, а в реальном времени или ближе к нему;
- решения зависят от состояния оборудования, а не от памяти смены;
- отчётность должна сходиться с 1С / ERP без ручного копирования;
- ошибки оператора должны блокироваться системой, а не разбираться постфактум;
- простой из-за «не той уставки» измеряется в деньгах, а не в неудобстве.
| Сигнал «пора в систему» | Что обычно делают до этого | Что даёт переход |
|---|---|---|
| Сводки раз в смену | Бумажный журнал, Excel | Тренды, алерты, корреляция с браком |
| Ручной ввод в ERP | Двойной учёт | Автоматическая выгрузка проводок / нарядов |
| «Позвони механику» | Телефон, мессенджер | Эскалация по правилам, SLA, история |
| Разные версии регламента | PDF на стене | Единый цифровой регламент с версионированием |
Типовой контур выглядит так: сбор телеметрии → нормализация → правила и сценарии → уведомления → журнал действий → дашборд. Отдельно проектируется офлайн-режим: контроллер или edge-узел продолжает критичную логику, если облако или корпоративная сеть недоступны.
Архитектура промышленного контура
Уровни по классической модели
[Поле: датчики, ПЛК, приводы]
↓ Modbus / OPC-UA / PROFINET
[Edge: шлюз, буфер, локальная логика]
↓ MQTT / AMQP / REST
[Платформа: правила, история, API]
↓
[Интеграции: ERP, MES, CMMS, BI]
↓
[Интерфейсы: SCADA, мобильное приложение оператора]Поле (OT) — реальное время, миллисекунды–секунды. Здесь не место тяжёлому веб-стеку: логика аварийного останова остаётся на ПЛК или сертифицированном контроллере.
Edge — агрегация, буферизация при обрыве связи, предобработка (фильтрация выбросов, агрегаты по минутам). Edge не заменяет ПЛК, но снимает нагрузку с облака и сокращает объём передаваемых данных.
Платформа (IT) — долгосрочное хранение, бизнес-правила, роли, интеграции. Здесь уместны PostgreSQL/TimescaleDB, InfluxDB, очереди (Kafka, RabbitMQ), сервисы на Go, Java, .NET.
SCADA vs MES vs собственная разработка
| Решение | Сильные стороны | Слабые стороны |
|---|---|---|
| Классическая SCADA | Готовые мнемосхемы, драйверы ПЛК | Слабая кастомизация бизнес-процессов, лицензии |
| MES | Учёт партий, маршруты, качество | Долгое внедрение, жёсткая методология |
| Кастомная платформа | Процесс «как у вас», интеграции под заказ | Нужна сильная команда и сопровождение |
| Гибрид | SCADA на операторской, API в свою систему | Два контура согласования и ответственности |
Разумный компромисс на средних предприятиях: визуализацию и прямое управление критичными циклами оставить на проверенной SCADA или ПЛК, а учёт, аналитику, мобильные сценарии и интеграции с ERP строить в отдельном программном продукте.
Принципы разработки, без которых система не переживёт смену
1. Идемпотентность
Повтор команды не должен «двойно» запустить цикл. Оператор нажал «Старт» дважды из-за лага — линия не должна удвоить выдачу. Реализация: идемпотентные ключи команд, состояние конечного автомата (idle → running → done), отказ повторного принятия той же команды с тем же id.
2. Наблюдаемость
Метрики, логи, трассировка — иначе ночную смену нельзя диагностировать удалённо. Минимальный набор:
- телеметрия с метками времени и quality flag (good / substituted / bad);
- корреляционный id от датчика до записи в ERP;
- дашборд «здоровья» шлюзов: последний пакет, очередь, ошибки парсинга.
Подробнее про удалённый мониторинг: ПО для мониторинга оборудования и удалённое обслуживание промышленного оборудования.
3. Роли и аудит
Кто изменил уставку, когда, с какого устройства, какое было предыдущее значение. Без неизменяемого журнала споры «кто завалил партию» не решаются, а регуляторные проверки становятся болезненными.
Рекомендуемая модель ролей:
| Роль | Права |
|---|---|
| Оператор | Пуск/стоп в рамках регламента, подтверждение алертов |
| Мастер смены | Корректировка уставок в допустимых пределах |
| Технолог | Изменение рецептов, версионирование |
| Администратор | Пользователи, интеграции, не производственные команды |
4. Интеграции как контракт
Modbus, OPC-UA, MQTT, REST — с версионированием API, таймаутами, явными схемами данных и политикой обратной совместимости. «Поле в JSON пришло строкой вместо числа» — классика, которая роняет ночную выгрузку в ERP.
Для MQTT: фиксированные topic-конвенции, retained messages только где уместно, QoS по критичности. Для REST: идемпотентные POST с ключом, пагинация истории, лимиты на размер ответа.
5. Безопасность OT/IT
Сегментация сети, отсутствие прямого выхода ПЛК в интернет, VPN или выделенные каналы для удалённого доступа, обновления по окну простоя. Разработка ПО не отменяет требований ИБ на уровне инфраструктуры.
Протоколы и выбор технологий
| Протокол | Типичное применение | На что смотреть при разработке |
|---|---|---|
| Modbus RTU/TCP | Датчики, счётчики, простые ПЛК | Таймауты, endianness, batch-опрос |
| OPC-UA | Современные ПЛК, единая модель данных | Сертификаты, подписки vs poll |
| MQTT | Edge → облако, много точек | Брокер HA, ACL, переполнение очереди |
| REST/GraphQL | Интеграция с ERP, мобильные клиенты | Версии API, rate limit |
| AMQP/Kafka | Высокий поток событий, аналитика | Порядок партиций, replay |
Хранилища временных рядов: InfluxDB, TimescaleDB, VictoriaMetrics — выбор по объёму, retention и необходимости SQL-отчётов поверх сырых тегов.
Очереди: при пиковой нагрузке (тысячи тегов в секунду) буфер между edge и обработчиками спасает от потери данных при кратковременном падении consumer.
Стек приложения: Go и .NET часто выбирают за предсказуемость под долгоживущие сервисы; Node.js — для быстрых админок и BFF; Python — для прототипов аналитики и ML на исторических данных. Связка с ИИ для предиктивного обслуживания разобрана в автоматизации с AI.
Сценарии из практики
Сценарий 1. Линия упаковки
Задача: считать брак, останавливать при отклонении веса, печатать этикетку из ERP.
Решение: весы по Modbus → edge агрегирует 1 измерение/сек → правило «3 подряд вне допуска» → команда на ПЛК → событие в очередь → запись партии в MES/ERP.
Ошибка, которую избегали: не останавливать линию из облака напрямую — только через ПЛК с локальным interlock.
Сценарий 2. Энергомониторинг цеха
Задача: пиковые нагрузки, связь с графиком смен, отчёт для экономиста.
Решение: счётчики по OPC-UA → TimescaleDB → дашборд + ежесуточная выгрузка в 1С.
Критично: единая timezone и привязка к календарю производства, иначе «пик» смещается на бумаге.
Сценарий 3. Мобильный обходчик
Задача: обход оборудования, QR/NFC точки, фото дефекта, заявка в CMMS.
Решение: офлайн-first приложение, синхронизация при Wi-Fi в цехе, конфликты по timestamp и id обхода.
Офлайн-режим и отказоустойчивость
Промышленная сеть не гарантирует 100% доступность. Минимальные требования к проекту:
- Edge-буфер на 24–72 часа телеметрии при обрыве uplink.
- Локальные правила для аварийных порогов без облака (уже на ПЛК или edge).
- Очередь исходящих команд с экспоненциальным retry и dead letter для ручного разбора.
- Healthcheck шлюзов: heartbeat, алерт если нет данных N минут (с учётом планового простоя).
- Процедура восстановления: после длительного офлайна — сверка счётчиков и партий, не слепой replay всей очереди.
Таблица режимов деградации:
| Компонент недоступен | Допустимое поведение |
|---|---|
| Облако | Edge + ПЛК, локальные алерты |
| ERP | Буфер проводок, ручной импорт по регламенту |
| SCADA-станция | Резервная станция или read-only мобильный вид |
| Брокер MQTT | Локальный буфер на edge, backpressure |
Внедрение: пошаговый план
Фаза 0. Обследование (1–3 недели)
- Карта оборудования, протоколов, существующих систем.
- Интервью с операторами, мастерами, IT, ИБ.
- Фиксация KPI: что измеряем до и после (простой, брак, время отчёта).
Фаза 1. Пилот на одной линии / участке
- Один шлюз, ограниченный набор тегов, один дашборд, один интеграционный поток.
- Параллельный учёт со старым процессом 2–4 недели для сверки.
Фаза 2. Продуктизация
- CI/CD для конфигураций (не только для кода), staging-контур.
- Документация регламентов и runbook инцидентов.
- Обучение смен, назначение владельца продукта со стороны заказчика.
Фаза 3. Масштабирование
- Тиражирование шаблонов edge-узлов, единый каталог тегов.
- Централизованный мониторинг всех площадок.
Типичные ошибки внедрения:
- Начать с «всего цеха» без пилота — год интеграции без измеримого эффекта.
- Игнорировать операторов при проектировании UI — систему обходят стороной.
- Не заложить сопровождение: вендор ушёл, некому менять рецепт при новой SKU.
- Путать демо-дашборд с production: без аудита, ролей и резервирования.
Чеклист требований к ТЗ на разработку
Перед стартом разработки зафиксируйте:
- Перечень оборудования, протоколов, частота опроса / подписки.
- Список интеграций (ERP, MES, CMMS) и формат обмена.
- Требования к задержке (от датчика до алерта / до ERP).
- Сценарии офлайна и аварийного останова — что где исполняется.
- Роли, аудит, хранение журналов (срок, неизменяемость).
- Требования ИБ и сегментация сети.
- Кто владелец данных и кто меняет уставки в production.
- SLA поддержки и окна обслуживания.
Заключение
Разработка автоматизации — это проектирование программного продукта вокруг реального процесса: поле, edge, платформа, интеграции и люди. Системы, которые переживают смену, строят на идемпотентности, наблюдаемости, контрактных интеграциях и честном офлайн-режиме — а не на иллюзии «всё всегда онлайн». Пилот на одном участке, сверка с ручным учётом и вовлечение операторов с первой недели отделяют окупаемое внедрение от дорогой витрины данных.
