Концепция и архитектура промышленного IoT

1. Назначение и целеполагание подсистемы IIoT

Микросервис HeatBalance.IoTService представляет собой базовый компонент платформы «UrFU HeatBalance», обеспечивающий автоматизированный сбор, первичную верификацию, нормализацию и передачу технологических параметров с тепловых агрегатов металлургических и огнеупорных производств непосредственно в математические расчётные модули.

Ключевые задачи подсистемы:

1. Исключение человеческого фактора: ликвидация субъективных ошибок операторов печи при ручном заполнении журналов теплотехнических параметров.
2. Непрерывный мониторинг энергоэффективности: расчёт коэффициента полезного действия ($\eta$), структуры тепловых потерь ($q_2, q_3, q_5$) и удельного расхода условного топлива ($b_y$) с периодичностью технологического такта агрегата (от 5 секунд до 1 минуты).
3. Обнаружение тепловых аномалий в реальном времени: непрерывный мониторинг параметров для подсистемы предиктивной аналитики (HeatBalance.AnalyticsService), детектирующей прогары футеровки, разрегулировку горелок и нарушение аэродинамики печи.
4. Аппаратная изоляция и безопасность: жесткое разделение прав доступа по уникальным криптографическим токенам устройств и привязка к идентификаторам владельцев технологических участков (OwnerId).

---

2. Архитектурный конвейер приёма и обработки телеметрии

Конвейер обработки телеметрических данных построен на базе асинхронной событийной модели с применением очередей сообщений RabbitMQ и шины MassTransit. Такая организация предотвращает блокировку входящих запросов от полевых шлюзов при пиковых вычислительных нагрузках расчётных движков.

Детальное описание шагов конвейера:

1. Приём пакета телеметрии (TelemetryController.Ingest):

   • Полевой контроллер или шлюз выполняет HTTP POST запрос на /api/v1/iot/telemetry.
   • В обязательном HTTP-заголовке X-Device-Token передаётся 32-символьный криптографический ключ устройства.
   • Микросервис проверяет наличие устройства в базе данных IoTDbContext.Devices. Если токен не найден, соединение прерывается со статусом 401 Unauthorized.
   • При успешной авторизации формируется запись в таблице TelemetryLogs со статусом Pending (значение 0), после чего шлюз немедленно получает ответ 202 Accepted. Время ответа не превышает 15–25 мс, что критично для полевых контроллеров с ограниченным сетевым таймаутом.

2. Публикация в шину сообщений:

   • Контроллер публикует контрактное событие TelemetryReceivedEvent:

     public sealed class TelemetryReceivedEvent
     {
         public Guid TelemetryLogId { get; set; }
         public Guid DeviceId { get; set; }
         public string PayloadJson { get; set; } = string.Empty;
         public DateTimeOffset Timestamp { get; set; }
     }

3. Обработка консьюмером TelemetryReceivedConsumer:

   • Консьюмер извлекает привязанный к датчику идентификатор шаблона DatasetId и тип тепловой установки CalculationType.
   • Через межсервисный HTTP-клиент DatasetApiClient загружается эталонная технологическая карта агрегата, содержащая неизменяемые конструктивные параметры (геометрия рабочего пространства, характеристики слоев огнеупорной кладки, элементный состав сжигаемого газа).
   • Выполняется алгоритм глубокого слияния (JSON Deep Merge): динамические показания датчика замещают соответствующие поля конфигурации.
   • Модифицированный расчетный вектор направляется в специализированный микросервис (HeatBalance.ChamberKilnService, HeatBalance.ConveyorKilnService, HeatBalance.ElectricKilnService или HeatBalance.DrumDryerService).

4. Фиксация результатов и сохранение технологического следа:

   • Расчётный движок возвращает десериализованную модель HeatBalanceResult, содержащую КПД ($\eta$), балансовые статьи прихода и расхода теплоты ($Q_{in}, Q_{out}$), а также температуры рабочих зон.
   • Консьюмер отправляет команду SaveRunCommand в шину MassTransit для создания постоянной записи в истории расчетов (HeatBalance.RunService).
   • Запись TelemetryLogs переводится в терминальное состояние Success (значение 1), сохраняется результирующий JSON, вычисленный КПД и обновляется метка времени Devices.LastSeenAt.

---

3. Текущий режим функционирования: Программная симуляция

На текущем этапе развёртывания и верификации платформа «UrFU HeatBalance» функционирует в режиме программной симуляции (Simulation Mode).

Механика работы режима симуляции:

• Интерфейс оператора (frontend/src/pages/IoTPanel): пользователь регистрирует виртуальное устройство, выбирая тип промышленного датчика (от термопар до газоанализатора) и целевой тепловой агрегат.
• Генерация динамических пакетов: интерфейс генерирует валидный JSON-пакет телеметрии на основе предустановленных физических диапазонов по ГОСТ/ТУ с возможностью ручного ввода или автоматической генерации технологических возмущений:
  $$x_i(t) = \bar{x}_i + A \cdot \sin\left(\frac{2\pi t}{T}\right) + \xi(t), \quad \xi(t) \sim \mathcal{N}(0, \sigma^2)$$
  где $\bar{x}_i$ — номинальная уставка технологической карты; $A$ — амплитуда квазипериодических колебаний теплового процесса; $\xi(t)$ — стохастический измерительный шум.
• Сквозная валидация сервисной архитектуры: симуляция задействует реальные производственные микросервисы, таблицы баз данных PostgreSQL, брокер RabbitMQ и движки термодинамического расчета. Это гарантирует, что поведение системы в режиме симуляции на 100% тождественно работе с физическими датчиками.

Цели применения симуляции на этапе внедрения:

1. Безопасность технологического оборудования: отладка алгоритмов оптимизации и выявления аномалий без риска создания аварийных ситуаций на реальных тепловых установках высокой мощности.
2. Стресс-тестирование микросервисной шины: генерация высокоинтенсивного входящего потока телеметрических пакетов для замера латентности и предельной пропускной способности очередей RabbitMQ.
3. Отладка предиктивных алгоритмов: возможность имитации экстремальных предаварийных сценариев (резкое падение давления природного газа, прогар внутреннего слоя огнеупорного кирпича, скачок влажности сырья), которые редко происходят в штатном режиме работы цеха.

---

4. Инженерная дорожная карта вывода в реальный промышленный контур

Для перевода системы из режима программной симуляции в постоянный промышленный рабочий режим с прямым съемом параметров с контроллеров печей разработан детальный регламент интеграции в соответствии со стандартами промышленной автоматизации ГОСТ Р МЭК 62443, ISA-95 и концепцией Purdue Enterprise Reference Architecture (PERA).

Фаза 1: Аппаратный аудит и сопряжение с полевым уровнем (Level 0 - Level 1)

1. Инвентаризация точек измерений:
   • Формирование сводной таблицы технологических сигналов для каждого теплового агрегата (сопоставление физических параметров с 15 типами датчиков системы).
   • Проверка наличия свободных аналоговых и цифровых каналов на действующих модулях ввода-вывода ПЛК.
2. Метрологическая поверка первичных преобразователей:
   • Поверка термопар и термометров сопротивления по ГОСТ 6651-2009 и ГОСТ 8.338-2002.
   • Проверка линейности токовых выходов датчиков давления и расхода (4-20 мА) с использованием калибратора технологических процессов.
3. Конфигурирование блоков данных ПЛК:
   • В среде разработки ПЛК (Siemens TIA Portal, CoDeSys v3.5, Schneider EcoStruxure Machine Expert) создаётся специализированный блок данных обмена (например, DB_HeatBalance_Telemetry).
   • Данные технологического процесса копируются из рабочих переменных программы в блок телеметрии с фиксацией времени выборки и признака достоверности (Quality Bit).

Фаза 2: Развертывание и настройка промышленных шлюзов Edge IoT (Level 3)

1. Выбор аппаратной платформы:
   • Рекомендуется установка безвентиляторных промышленных шлюзов с креплением на DIN-рейку в отдельный шкаф телеметрии (ШТ).
   • Технические требования к шлюзу: диапазон рабочих температур от -40 до +70 °C, виброустойчивость, двойной ввод питания 24 В DC, два независимых сетевых порта Ethernet RJ-45 (для физического разделения сети ПЛК и заводской сети).
2. Установка системного ПО и агента сбора:
   • Операционная система: Debian GNU/Linux с отключенными неиспользуемыми демонами и файловой системой в режиме Read-Only (с монтированием раздела логов в RAM/tmpfs) для исключения повреждения флеш-памяти при внезапных отключениях питания.
   • Запуск специализированного сервиса сбора данных heatbalance-edge-daemon (написанного на Python/Go/Rust), работающего как systemd-служба с автоматическим перезапуском.

Фаза 3: Сетевая интеграция и обеспечение кибербезопасности

1. Сетевая сегментация (VLAN & Firewall):
   • Шлюз подключается первым интерфейсом eth0 в локальную технологическую подсеть печи (OT VLAN, адресация 192.168.10.x/24).
   • Второй интерфейс eth1 подключается в заводскую подсеть передачи данных (DMZ VLAN, адресация 10.20.0.x/24). Маршрутизация пакетов между eth0 и eth1 на уровне ядра Linux аппаратно заблокирована (net.ipv4.ip_forward = 0).
2. Организация исходящего защищённого канала:
   • Заводской межсетевой экран блокирует любые входящие сетевые соединения со стороны сети Интернет в цеховую сеть.
   • Шлюз heatbalance-edge-daemon открывает только исходящее соединение по порту 443 (HTTPS) к домену облачной платформы (heatbalance.online).
   • Для повышенных требований к безопасности организуется туннель WireGuard или IPsec с аутентификацией по открытым ключам.
3. Криптографическая идентификация агрегата:
   • Каждому физическому шлюзу присваивается уникальный 256-битный токен доступа, сгенерированный в HeatBalance.IoTService.
   • Токен передаётся в защищенном HTTPS-заголовке X-Device-Token.

Фаза 4: Реализация механизма гарантированной доставки (Store-and-Forward)

В условиях реального металлургического производства неизбежны кратковременные потери связи между цехом и центральным сервером (обрывы оптоволокна, помехи от мощных электродуговых печей, регламентные работы сетевого оборудования).

1. Локальное кэширование:
   • При отказе внешнего канала шлюз накапливает измеренные телеметрические точки в локальной базе данных SQLite (в режиме WAL — Write-Ahead Logging).
   • Глубина локального буфера рассчитывается на хранение данных за 30 календарных дней непрерывного автономного производства.
2. Пакетная досылка данных (Backfill / Catch-up):
   • При восстановлении сетевого подключения агент сбора возобновляет прямую передачу текущих параметров и параллельно в фоновом режиме выгружает исторические пачки из локального буфера.
   • Выгрузка регулируется алгоритмом Rate Limiting для предотвращения насыщения канала связи.

Фаза 5: Опытная эксплуатация и метрологическая валидация («Теневой режим»)

1. Теневой режим (Shadow Run):
   • Система подключается к реальным датчикам, но оперативный персонал продолжает вести стандартный технологический контроль.
   • В течение 14–30 дней выполняется непрерывное сравнение автоматических тепловых балансов с контрольными ручными замерами технологической лаборатории цеха.
2. Калибровка и компенсация погрешностей:
   • Выполняется программная компенсация тепловой инерции массивных термопар и задержки транспортировки газов по импульсным линиям к газоанализаторам.
   • При подтверждении сходимости балансов (невязка расчетного и фактического баланса менее 1.5%) оформляется акт ввода в постоянную промышленную эксплуатацию.

---

5. Сводная таблица статусов телеметрических логов

Каждый пакет телеметрии, поступающий в систему, отслеживается по жизненному циклу через перечисление TelemetryStatus:

Код	Значение enum	Состояние в UI	Описание и технологическая причина
0	Pending	В очереди	Пакет принят контроллером, сохранён в БД, событие ожидает очереди в RabbitMQ
1	Success	Успешно	Пакет успешно объединён с датасетом, тепловой баланс рассчитан, запись сохранена в RunService
2	ParsingError	Ошибка JSON	Полевой шлюз прислал невалидный JSON, либо типы данных не соответствуют числу с плавающей точкой
3	CalculationError	Ошибка расчета	Термодинамический двигатель вернул исключение (физически некорректные параметры, отрицательное давление и т.д.)