---
title: 'Рівень збору даних'
section: 'Concepts'
weight: 1
description: Структура рівня збору даних IIoT Платформи, його демони, принципи обміну даними та взаємодія з рівнем керування.
related:
  - architecture
  - architecture/abstract-data-layer
  - protocols
  - equipment
---

import Alert from '@/components/docs/Alert.astro';

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

**Рівень збору даних** — це ключовий компонент IIoT Платформи, що забезпечує інтеграцію з пристроями. Він складається з набору спеціалізованих застосунків, кожен з яких призначено для взаємодії з певним типом IoT-пристроїв (лічильники, датчики тощо). Ці застосунки функціонують як мережеві служби, обробляючи вхідні з'єднання через виділені порти та керуючи передаванням даних між пристроями та платформою. Така архітектура гарантує масштабованість і гнучкість під час роботи з різнорідним обладнанням.

<Alert type="note">
  Задля підвищення безпеки, відмовостійкості та зручності встановлення й оновлення застосунки
  пакуються в Docker-контейнери. Набором контейнерів керує [технологія Docker
  Compose](https://docs.docker.com/compose/), яка дає змогу об'єднати пов'язані контейнери в єдину
  панель керування.
</Alert>

Структуру та склад застосунків рівня збору даних узагальнено нижче:

```mermaid
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-пристроєм і демоном збору:

```mermaid
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.

<Alert type="note">
  Підсистема керування зберігає в цій базі даних усю необхідну конфігурацію опитуваних
  IoT-пристроїв. Демони збору даних використовують ці налаштування для встановлення зв'язку з
  пристроями та виконання операцій обміну даними.
</Alert>

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

Схему взаємодії підсистем наведено нижче:

```mermaid
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.

Приклад конфігурації наведено нижче:

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

Тут `day_event`, `hour_event` і `month_event` — це позначки часу у форматі `unixtime` останніх збережених записів добового, погодинного та місячного архівів відповідно.

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

Нижче наведено приклад зберігання кількох розкладів для пристрою:

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

Згідно з цими розкладами пристрій має підключатися на 10-й і 40-й хвилині кожної години. Демон сам визначає найприйнятніший розклад на момент зв'язку з пристроєм і передає найближчий із них.