ПО для удалённого мониторинга оборудования нужно, когда простой дороже датчика: линия в другом городе, парк печей, насосы, станки, инженерные системы здания. Поиск «мониторинг промышленного оборудования», «диспетчеризация», «IIoT-платформа» чаще всего означает одно: видеть состояние сейчас и историю за смену — не ждать звонка с площадки. Ниже — как проектировать такую систему: от протоколов до тревог, SLA и интеграций с ERP и CMMS.

Функции, без которых продукт не монитор

• Сбор тегов — Modbus, OPC-UA, MQTT, SNMP, вендорские API, иногда файловый импорт из legacy.
• Нормализация — единицы (°C vs °F), часовые пояса площадок, единый asset id.
• Тревоги — пороги, эскалация, подавление, «тишина» по сменам.
• Дашборды по ролям — технолог, энергетик, директор филиала, дежурная смена.
• История — не «последние 15 минут в RAM»; политика retention по классу данных.
• Экспорт и API — в 1С, MES, CMMS, BI.

Мониторинг — глаза. Руки — удалённое обслуживание: сессии специалиста и командный канал с белым списком. График не должен сам закрывать задвижку без отдельного контура команд.

Архитектура: от датчика до дашборда

Типовая многоуровневая схема:

 [Датчики / PLC / CNC / SCADA]
           │
           │  Modbus / OPC-UA / MQTT / SNMP
           ▼
 ┌─────────────────────────────────────┐
 │  Edge gateway (площадка)            │
 │  • ingest + буфер                   │
 │  • нормализация / unit conversion   │
 │  • локальные тревоги (fallback)     │
 │  • опционально: лёгкий HMI          │
 └──────────────┬──────────────────────┘
                │  TLS, частный канал / VPN
                ▼
 ┌─────────────────────────────────────┐
 │  Ingest / message bus               │
 │  Kafka / MQTT broker / Timescale    │
 └──────────────┬──────────────────────┘
                │
     ┌──────────┼──────────┐
     ▼          ▼          ▼
 [Rule engine] [TSDB]  [API layer]
     │          │          │
     ▼          ▼          ▼
 [Алерты]   [Дашборды] [CMMS/ERP/MES]

Ingest принимает потоки с edge, проверяет схему (имя тега, timestamp, quality). Time-series DB хранит высокочастотные данные с downsampling для старых периодов. Rule engine — пороги, окна, эскалация. API layer — REST/GraphQL для дашбордов, мобильных push и внешних систем.

Метрики самого монитора (lag ingest, dropped messages, query latency) должны быть на отдельном дашборде «здоровья платформы» — не хуже метрик станка.

Выбор протоколов

Практика: на edge — нативный протокол поля; в центр — MQTT или Kafka с единой схемой (protobuf/JSON schema). Не смешивайте «сырой Modbus» и бизнес-теги в одном топике без маппинга.

Дискретность сбора: для энергии и медленных процессов — 1–60 с; для вибрации и качества — ms–с на edge с агрегацией (min/max/avg) в центр. Хранить всё в 10 ms на год — редко нужно и дорого.

Edge vs облако vs on-prem

Edge нужен почти всегда на промышленной площадке:

• буфер при обрыве связи (от часов до суток);
• предобработка и фильтрация шума;
• локальные тревоги, если облако недоступно;
• снижение объёма трафика (агрегация);
• выполнение политики «данные не покидают завод» (отправка только агрегатов или алертов).

Облако (публичное или private cloud) — дашборды, долгая история, мобильные уведомления, ML на агрегированных данных, мультисайтовая аналитика для OEM.

On-prem в ЦОД завода — когда регулятор или ИБ не разрешает operational data outside; облако только для анонимизированной отчётности или не используется вообще.

Гибридная модель чаще всего побеждает: edge = операционная надёжность; центр = визуализация, интеграции, отчёты. Критично определить RPO/RTO для буфера edge: сколько данных можно потерять при смерти шлюза и как быстро поднимается replacement.

Модель безопасности

Сеть. PLC не в интернете. Edge — единственный шлюз; firewall: deny inbound, allow outbound to known endpoints. Сегментация OT/IT; при необходимости — data diode для однонаправленной телеметрии.

Транспорт. TLS 1.2+ на всех каналах; сертификаты с ротацией; для OPC-UA — signed + encrypted.

Идентификация. RBAC в платформе: технолог видит линию, филиал — агрегаты, аудитор — только логи. SSO для корпоративных пользователей. API keys с scope per site для интеграций.

Данные. Шифрование at rest для TSDB и бэкапов. Разделение tenant для мультиклиентских OEM-платформ. Логи доступа к истории параметров — для разборов «кто видел уставки».

Мониторинг ≠ управление. Write-путь в PLC либо отсутствует, либо изолирован в сервисном контуре с белым списком.

Дизайн тревог и эскалации

Плохие тревоги убивают мониторинг: операторы отключают уведомления, реальные аварии пропускаются.

Классы тревог (пример):

Правила:

• Deadband и hysteresis — не дребезжать на границе порога.
• Duration — «температура > 80 °C не менее 2 мин», не мгновенный пик.
• Escalation — если не ack за N минут → следующий уровень (мастер → главный технолог).
• Suppression — при плановом останове или активной заявке CMMS повторяющиеся тревоги агрегируются.
• Shift calendar — разные пороги или каналы для ночи/выходных (тишина для Low, Critical всегда).
• Correlation — «10 насосов offline» одна тревога «сеть сегмента», не 10 SMS.

Anti-flapping: cooldown после clear; max N алертов в час на один тег.

Тест тревог — отдельный сценарий пилота: искусственно поднять тег, проверить эскалацию, ack, suppress при maintenance window.

SLA для платформы мониторинга

SLA делят на доступность данных и доступность UI:

Для критичных объектов фиксируйте end-to-end SLA с edge: облако «зелёное», но edge мёртв — линия не мониторится. Healthcheck edge → алерт класса High.

В контракте с вендором платформы: кто отвечает за канал связи, за edge-аппарат, за брокер; исключения (плановое обслуживание, force majeure).

Интеграция с ERP, MES и CMMS

Мониторинг не должен жить в изоляции — он питует процессы обслуживания и учёта.

CMMS / заявки — автосоздание work order при Critical/High с payload: asset id, тег, значение, ссылка на дашборд, snapshot графика. Закрытие тикета при clear + ack или по правилу «auto-close если 24 ч в норме».

ERP — для OEM: счётчик наработки (моточасы, циклы) для гарантии и контрактов; отгрузка ЗИП при накопленных предиктивных тревогах (если бизнес-процесс позволяет).

MES — сравнение фактических параметров с техкартой; тревога «отклонение от recipe»; не записывать уставки из мониторинга в MES без отдельного workflow.

BI / data lake — ETL агрегатов (сменные KPI, OEE-входные) раз в час/сутки; не сырой 1 Hz поток в ERP.

Единый asset registry — серийный номер = node id в MQTT = id в CMMS. Маппинг один раз на пилоте, не при каждой интеграции.

Пример события в API CMMS:

{
  "assetId": "LINE-03-PUMP-A",
  "alarmCode": "HIGH_TEMP_DISCHARGE",
  "severity": "high",
  "value": 92.4,
  "unit": "C",
  "dashboardUrl": "https://monitor/site/3/pump-a",
  "occurredAt": "2026-08-15T14:22:01+03:00"
}

Дашборды и роли

Технолог — live теги, сравнение с нормой, последние аварии линии, drill-down до 15 мин.

Энергетик — агрегаты по цеху, kWh, пики, сравнение площадок.

Директор филиала — KPI: downtime, count critical alarms, trend за месяц; без тысячи мелких графиков.

Дежурная смена — очередь активных тревог, ack, runbook link, телефон ответственного.

Аудитор / ИБ — кто смотрел историю, экспорт логов, без операционных кнопок.

UX: мобильный push для Critical; десктоп для анализа. Не дублировать SCADA HMI — мониторинг дополняет, не заменяет локальный операторский интерфейс, если он уже есть.

Чеклист rollout

1. Scope пилота — 5–10 единиц, разные протоколы и критичность.
2. Asset registry — id, иерархия site → line → unit → tag.
3. Протоколы и дискретность — таблица тегов с единицами и частотой.
4. Edge — установка, буфер, тест обрыва связи 4+ часа.
5. Ingest + TSDB — схема, retention, downsampling policy.
6. Тревоги — классы, пороги, эскалация, shift calendar; тест anti-flap.
7. Дашборды — по ролям; mobile для дежурной.
8. Интеграции — CMMS автотикет, ERP наработка, MES отклонения (по необходимости).
9. ИБ — сегментация, TLS, RBAC, аудит чтения.
10. Health — дашборд lag/drop; алерт при молчании edge.
11. Runbooks — на каждый класс тревоги: что делать до выезда.
12. Обучение — ack vs ignore, maintenance window, false positive feedback.
13. SLA — согласовать с бизнесом и зафиксировать в контракте поддержки.
14. Масштабирование — шаблон site onboarding, версионирование tag map.

Пилот снимает большую часть сюрпризов: «тег в Modbus — centimeters, в документации — mm», «OPC-UA certificate expired», «тревога будит всех, потому что нет shift rule».

Аналитика и AI

Базовый мониторинг — пороги и тренды. Следующий шаг — аномалии (seasonal decomposition, isolation forest на агрегатах), прогноз остаточного ресурса для CMMS. Подробнее о границах AI — в автоматизации с AI.

Правила: AI не подменяет Critical тревоги без объяснения (explainability); оператор видит «почему аномалия»; human ack перед созданием заявки на High из ML, если политика завода требует.

Что подготовить перед разработкой

Заказчику и интегратору нужны: список единиц оборудования с серийными номерами; протоколы и документация тегов; желаемая дискретность и retention; матрица ролей; классы аварий и текущие SLA; схема сети и ограничения ИБ; целевые системы интеграции (1С, SAP, MES); кто дежурит и в какие окна.

Без этого оценка «сделать мониторинг» всегда занижена: 80% усилий — интеграция, модель данных и тревоги, не красивый фронт.

Разработка ПО для удалённого мониторинга — полноценный продукт: edge, ingest, TSDB, rule engine, API, дашборды, мобильные уведомления, аудит. Начинать с пилота и явной модели данных; масштабировать по шаблону площадки, а не копировать конфиг вручную на каждый завод.