Как связать собственное ПО с IT/OT/IIoT и не сломать производство

9 января, 2026

Автор: Инженер-программист

Практическое руководство с примерами и схемами

Главная ошибка: смотреть на производство глазами веб-разработчика

Реальный случай:
Завод внедрил систему мониторинга оборудования. Архитектор из IT настроил прямые запросы от облака к PLC. Результат: сеть производства упала на 40 минут, убытки — 12 млн руб. Причина: не учли задержки протокола и нагрузку на промышленную сеть.

Что отличает OT от IT:

Параметр	IT (офис, веб)	OT (производство)
Связь	Стабильная, 99.9%	Нестабильная, помехи
Цена ошибки	Неудобство	Остановка линии, травмы
Цикл обновлений	Недели	Годы (ремонтные окна)
Ответственность	Разработчик	Инженер + юр. лицо
Протоколы	HTTP, REST	Modbus, OPC UA, Profinet

Edge-слой: обязательная прослойка между производством и IT

Зачем нужен edge

Без edge (антипаттерн):

[PLC] ---(WiFi)---> [Облако] ---> [Аналитика]
         ↑
    Проблема: потеря связи = потеря данных

С edge (правильно):

[PLC] ---(кабель)---> [Edge-шлюз] ---(буфер)---> [Облако]
                           ↓
                    Локальная логика
                    (работает автономно)

Практическая схема edge-слоя

Состав edge-узла:

Сбор данных: Опрос PLC каждые 100–500 мс
Фильтрация: Убрать шум, выбросы, дубли
Предобработка: Агрегация (среднее за минуту), расчёты
Буферизация: Хранение 24–72 часов при потере связи
Передача: Отправка в центр батчами

Пример настройки edge-правила (псевдокод):

yaml

источник: PLC_Линия1.Температура_Печи
фильтр:
  - мин_значение: 150
  - макс_значение: 850
  - изменение_более: 5  # градусов
предобработка:
  - среднее_за: 1_минута
буфер:
  - размер: 100_МБ
  - сброс_при: 80%
передача:
  - интервал: 10_секунд
  - при_потере_связи: буферизовать
```

### Железо для edge

**Типовые решения:**
- **Промышленные ПК:** Advantech, Beckhoff (190–350 тыс. руб.)
- **Edge-контроллеры:** Siemens IOT2050, Schneider Electric (30–80 тыс. руб.)
- **Одноплатники:** Raspberry Pi 4 в промкорпусе (10–20 тыс. руб., для некритичных задач)

**Требования:**
- Температурный диапазон: -20 до +60°C
- Защита: IP54 минимум
- Питание: 24V DC с резервированием
- Хранение: SSD промышленный (не обычный SSD!)

---

## Low-code в промышленности: где можно и где нельзя

### Зелёная зона (можно и нужно)

**1. Интеграция SCADA → MES → ERP**

**Задача:** Передавать данные о выпуске продукции из SCADA в ERP для учёта.

**Решение с low-code интеграцией (n8n, Node-RED):**
```
Триггер: SCADA отправила событие "Партия завершена"
  ↓
Шаг 1: Получить детали партии (OPC UA запрос)
  ↓
Шаг 2: Обогатить данными из MES (номенклатура, смена)
  ↓
Шаг 3: Отправить в ERP (REST API)
  ↓
Шаг 4: Записать в локальную БД (резервная копия)
```

**Экономия:** 2–3 недели разработки vs. 2 часа настройки.

**2. Визуализация и дашборды оператора**

**Инструменты:** Grafana, Node-RED Dashboard, низкокодовые HMI.

**Пример:** Дашборд для линии розлива:
- Текущая скорость (бутылок/мин)
- Температура пастеризатора
- Уровень сырья в бункерах
- Алерты при отклонениях

**Настройка:** 1 день vs. 2 недели на написание веб-приложения.

**3. Алертинг и реакции**

**Правило в low-code:**
```
ЕСЛИ температура > 800°C И длительность > 5 минут
ТО:
  - отправить Telegram оператору
  - записать в журнал
  - отправить команду PLC: снизить мощность
```

### Красная зона (категорически нельзя)

**❌ Управление safety-контурами**  
Пример: аварийная остановка при превышении давления.  
Причина: low-code не сертифицирован по функциональной безопасности (SIL).

**❌ Real-time управление**  
Пример: позиционирование робота с точностью до миллиметра.  
Причина: задержки low-code платформ — 50–200 мс, нужно < 10 мс.

**❌ Прямые команды на PLC без подтверждения**  
Причина: риск конфликта с локальной логикой контроллера.

---

## Архитектура интеграции: 4 слоя
```
Слой 4: ERP (SAP, 1С)
   ↕ (события, очереди)
Слой 3: MES / собственное ПО
   ↕ (API, OPC UA)
Слой 2: SCADA (мастер-данные)
   ↕ (Modbus, Profinet)
Слой 1: PLC / Edge (источник истины)
```

### Принципы взаимодействия слоёв

**1. SCADA — источник факта**  
Только SCADA знает реальное состояние оборудования. MES и ERP работают с её данными, а не наоборот.

**2. MES — контекст**  
Добавляет информацию: какой заказ, какая смена, какой оператор.

**3. ERP — планирование и учёт**  
Получает факт выполнения, обновляет склад и финансы.

**4. Собственное ПО — аналитика и оптимизация**  
Анализирует исторические данные, предлагает улучшения, не вмешивается в реальный процесс.

### Пример интеграционного flow

**Кейс:** Автоматический учёт брака на линии.
```
1. Датчик на линии (PLC) обнаружил брак
   ↓
2. Edge фиксирует событие, отправляет в SCADA
   ↓
3. SCADA публикует событие в MQTT
   ↓
4. Low-code интегратор (Node-RED) подписан на топик:
   - Запрашивает у MES: что это за партия?
   - Записывает в базу аналитики
   - Обновляет счётчик в ERP
   - Отправляет уведомление мастеру смены
```

**Ключевое:** Каждый слой работает асинхронно через очереди. Если ERP недоступен, событие не потеряется.

---

## Гарантии доставки и деградация

### Паттерн: Inbox/Outbox

**Проблема:** Сетевой сбой между SCADA и MES.

**Решение:**
```
[SCADA] ---> [Outbox таблица] ---> [фоновый процесс] ---> [MES]
                    ↓
          Гарантия: запись в локальную БД

Даже если MES недоступен 2 часа, все события будут доставлены после восстановления.

Деградация при отказах

Сценарий: Облачная аналитика недоступна.

Поведение системы:

Edge продолжает собирать данные в локальный буфер
SCADA работает в штатном режиме
Операторы видят дашборд на edge-узле (локальная копия)
После восстановления связи данные синхронизируются

Правило: Производство НЕ ДОЛЖНО зависеть от облака/центра.

Чек-лист перед внедрением

Технический аудит

Составлен список всего оборудования с протоколами (Modbus RTU, TCP, OPC UA, и т.д.)
Проверена пропускная способность промышленной сети
Определены критичные процессы (где простой недопустим)
Выбраны точки установки edge-узлов (доступность, питание, климат)

Регламентный аудит

Согласованы окна для тестирования (когда можно остановить линию)
Определены ответственные лица (главный механик, энергетик, ИТ)
Получены допуски для работ на производстве
Оформлена документация для службы безопасности

Риски

План отката (что делать, если система упала)
Резервирование критичных узлов (edge, коммутаторы)
Тестирование отказоустойчивости (выдернуть кабель, перезагрузить edge)

Почему нужен интегратор, а не обычная студия

Студия разработки знает:

React, Python, API
Agile, CI/CD
Облака и микросервисы

Промышленный интегратор знает:

Протоколы: Modbus, Profinet, EtherCAT, OPC UA
Стандарты: ISA-95, IEC 61131
Безопасность: функциональная безопасность (SIL), кибербезопасность (IEC 62443)
Железо: ПЛК Siemens/Schneider/ABB, промышленные сети
Регламенты: как получить допуск, как согласовать изменения

Реальность: 70% успеха интеграции — это правильная работа с людьми на производстве (механики, энергетики, технологи), а не красота кода.

Roadmap интеграции IT/OT (первые 3 месяца)

Месяц 1: Аудит и пилот

Выбрать 1 линию/участок для пилота
Установить 2–3 edge-узла
Настроить сбор 5–10 ключевых параметров
Проверить стабильность связи и буферизации

Месяц 2: Интеграция

Настроить передачу данных в центральную систему
Создать дашборд для операторов (Grafana/low-code HMI)
Внедрить 3–5 правил алертинга
Провести тесты отказоустойчивости

Месяц 3: Масштабирование

Документировать процесс и шаблоны настройки
Обучить инженеров завода базовой настройке edge
Подключить 2–3 дополнительных участка
Интегрировать с MES/ERP через очереди

Главные принципы

Edge — обязателен: Производство не должно зависеть от облака.
Low-code — для интеграции, не для управления: Оркестрация, дашборды, алертинг — да. Управление PLC — нет.
Асинхронность: Все системы взаимодействуют через очереди, а не прямые вызовы.
Деградация: Система работает при отказе любого некритичного компонента.
Люди: 50% успеха — договориться с главным механиком и энергетиком.

Стоимость типового пилота: 1–2 млн руб. (3–5 edge-узлов, настройка интеграции, дашборды).
Срок окупаемости: 6–12 месяцев за счёт снижения простоев и оптимизации процессов.