Рівень збору даних

Структура та склад рівня збору даних

Рівень збору даних — це ключовий компонент 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.
• У хмарних середовищах можна додати автоматичне масштабування на основі метрик (CPU, кількість з’єднань).
• Уся взаємодія з пристроями докладно журналюється у файли, тож її можна проаналізувати в разі виявлення проблем і збоїв.

Принципи обміну даними

Нижче наведено схему сеансу зв’язку між 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-й хвилині кожної години. Демон сам визначає найприйнятніший розклад на момент зв’язку з пристроєм і передає найближчий із них.