Уровень сбора данных

Структура и состав уровня сбора данных

Уровень сбора данных — это ключевой компонент IIoT Платформы, обеспечивающий интеграцию с устройствами. Он включает набор специализированных приложений, каждое из которых предназначено для взаимодействия с определённым типом IoT-устройств (счётчиками, датчиками и т. д.). Эти приложения функционируют как сетевые службы, обрабатывая входящие подключения через выделенные порты и управляя передачей данных между устройствами и платформой. Такая архитектура гарантирует масштабируемость и гибкость при работе с разнородным оборудованием.

Структура и состав приложений уровня сбора данных представлены ниже:

flowchart TD
    A(Household energy meters) <-->|Data transfer| B("Data collection daemon (Type-J)")
    C(Industrial energy meters) <-->|Data transfer| D("Data collection daemon (Type-T)")
    E(Smart sensors) <-->|Data transfer| F("Data collection daemon (DDT)")
    subgraph " "
    B("Data collection daemon (Type-J)") <--> I{"Balancer (Pgbouncer)"}
    D("Data collection daemon (Type-T)") <--> I{"Balancer (Pgbouncer)"}
    F("Data collection daemon (DDT)") <--> I{"Balancer (Pgbouncer)"}
    X@{ shape: braces, label: "Data Polling Subsystem" }
    end
    I{"Balancer (Pgbouncer)"} <--> J[(DBMS PostgreSQL)]

Обмен с конечными устройствами выполняется по TCP-соединению, при этом каждый демон сбора реализует собственный прикладной протокол обмена для обслуживания определённого типа IoT-устройств.

Эти демоны обладают рядом общих архитектурных особенностей, описанных ниже.

Особенности архитектуры

• Каждый контейнер содержит приложение, специализированное под определённый протокол.
• Используются легковесные базовые образы (alpine в базовой конфигурации) для минимизации накладных расходов. Тем не менее возможна сборка образов под ОС заказчика.
• Для управления зависимостями между службами (например, доступом к базе данных) в Docker Compose указываются секции depends_on и health-check.
• Демоны compose запускаются в нескольких экземплярах (репликах) для распределения нагрузки. При этом каждый демон сбора может одновременно обслуживать десятки тысяч подключений.
• Балансировщик (HAProxy, Nginx Stream) направляет трафик на доступные демоны по алгоритмам Round Robin или Least Connections.
• В облачных средах можно добавить автоматическое масштабирование на основе метрик (загрузка ЦП, число подключений).
• Весь обмен с устройствами подробно журналируется в файлы, чтобы его можно было проанализировать при обнаружении проблем и сбоев.

Принципы обмена данными

Ниже приведена схема сеанса связи между IoT-устройством и демоном сбора:

sequenceDiagram
    autonumber
    participant D as IoT device
    participant I as Data collection <br/>daemon
    Note over I,D: Stages of interaction
    D->>I: Session start, authentication
    I-->>D: Sending request parameters
    D->>I: Data acquisition
    I-->>D: Sending the next session time

Принципы организации обмена данными:

• Инициирование сеанса связи.
  Сеанс связи всегда инициируется IoT-устройством. После установления соединения с демоном сбора данных устройство передаёт идентификационный пакет.

• Процедура аутентификации
  Демон сбора данных аутентифицирует устройство. В случае успешной аутентификации он выполняет:

  • Извлечение сохранённой конфигурации устройства из базы данных.
  • Отправку текущих настроек интерфейса устройству.

• Передача данных
  На основании полученного запроса устройство передаёт на сервер сбора:

  • Текущие показания устройства.
  • Архивные записи (при их наличии).

• Планирование следующего сеанса
  После завершения приёма данных демон сбора:

  • Формирует метку времени следующего сеанса.
  • Передаёт метку времени следующего сеанса устройству.
  • Инициирует разрыв соединения.

• Обработка и хранение данных
  Полученная информация:

  • Агрегируется в структурированные JSON-объекты.
  • Сохраняется в промежуточной базе данных PostgreSQL.
  • Форматируется в соответствии со спецификацией протокола конкретного демона.

• Интеграция с системой управления
  Данные становятся доступны верхнему уровню системы (подсистеме управления) для:

  • Дальнейшей аналитической обработки.
  • Визуализации в интерфейсах управления.
  • Формирования автоматизированных отчётов.

Взаимодействие с уровнем управления платформы

Архитектура взаимосвязи подсистем

Демоны сбора данных интегрируются с верхним уровнем системы (уровнем управления) через промежуточную базу данных. Для обеспечения этого взаимодействия используется Docker-контейнер с развёрнутой СУБД PostgreSQL.

Результаты успешного взаимодействия с устройствами автоматически сохраняются демонами в специализированной таблице той же базы данных, что обеспечивает прозрачность передачи данных между уровнем управления и устройствами.

Схема взаимодействия подсистем показана ниже:

flowchart LR
A@{ shape: procs, label: "Data Polling Subsystem"} -->|Readings data| B[(DBMS PostgreSQL)]
B[(DBMS PostgreSQL)] -->|Configuration| A@{ shape: procs, label: "Data Polling Subsystem"}
B[(DBMS PostgreSQL)] -->|Readings data| C@{ shape: procs, label: "Control Subsystem"}
C@{ shape: procs, label: "Control Subsystem"} -->|Configuration| B[(DBMS PostgreSQL)]

Конфигурация устройства

Конфигурация устройства включает следующую информацию:

• Даты последних показаний по архивам: часовой, суточный, месячный. Эти параметры указывают дату, начиная с которой следует считывать данные соответствующего архива.
• Код прибора учёта (для IoT-устройств, использующих протокол Type-T). Этот параметр требуется только для демонов сбора, обслуживающих протокол Type-T, и сообщает серверу сбора, какой алгоритм использовать для работы с устройством.
• Скорость последовательного порта (для IoT-устройств, работающих по протоколу Type-T). Этот параметр сообщает IoT-устройству, с какой скоростью оно должно обмениваться данными со счётчиком. Демон сбора отправляет его в начале сеанса обмена.
• Расписание связи. Подсистема управления сохраняет все расписания в промежуточной базе данных, а демон сбора вычисляет ближайшую дату из полученных расписаний и отправляет её устройству.
• Команды управления устройством. В зависимости от типа IoT-устройства и его возможностей команды управления включают:
  • Команду обновления программного обеспечения телеметрической части IoT-устройства. При получении этой команды устройство загружает новую прошивку с сервера и выполняет обновление.
  • Команду обратного считывания конфигурации прибора учёта.
  • Команду закрытия или открытия клапана (если клапан присутствует и поддерживается программным обеспечением IoT-устройства).
  • Команду установки рабочих параметров прибора учёта (зависит от модели).
  • Команду перезагрузки IoT-устройства.

Основная часть конфигурации устройства хранится в промежуточной базе данных в формате JSON.

Пример конфигурации приведён ниже:

{
  "settings": "1",
  "day_event": 1706140800,
  "hour_event": 1706140800,
  "month_event": 1673857740,
  "net_address": 58
}

Здесь day_event, hour_event и month_event — это метки времени в формате unixtime последних сохранённых записей суточного, часового и месячного архивов соответственно.

Расписания хранятся отдельно, также в формате JSON. Сама строка расписания формируется и обрабатывается в формате CRON. Такой подход обеспечивает гибкость при настройке и обработке любых расписаний.

Ниже приведён пример хранения нескольких расписаний для устройства:

[
  { "crontab": "10 * * * *", "schedule_id": 6 },
  { "crontab": "40 * * * *", "schedule_id": 7 }
]

Согласно этим расписаниям устройство должно подключаться на 10-й и 40-й минуте каждого часа. Демон сам определяет наиболее подходящее расписание в момент связи с устройством и передаёт ближайшее.