--- title: 'Уровень сбора данных' section: 'Concepts' weight: 1 description: Структура уровня сбора данных IIoT Платформы, его демоны, принципы обмена данными и взаимодействие с уровнем управления. related: - architecture - architecture/abstract-data-layer - protocols - equipment --- import Alert from '@/components/docs/Alert.astro'; ## Структура и состав уровня сбора данных **Уровень сбора данных** — это ключевой компонент IIoT Платформы, обеспечивающий интеграцию с устройствами. Он включает набор специализированных приложений, каждое из которых предназначено для взаимодействия с определённым типом IoT-устройств (счётчиками, датчиками и т. д.). Эти приложения функционируют как сетевые службы, обрабатывая входящие подключения через выделенные порты и управляя передачей данных между устройствами и платформой. Такая архитектура гарантирует масштабируемость и гибкость при работе с разнородным оборудованием. Для повышения безопасности, отказоустойчивости и упрощения установки и обновлений приложения упакованы в Docker-контейнеры. Набор контейнеров управляется [технологией Docker Compose](https://docs.docker.com/compose/), которая позволяет объединить связанные контейнеры в единую панель управления. Структура и состав приложений уровня сбора данных представлены ниже: ```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. - В облачных средах можно добавить автоматическое масштабирование на основе метрик (загрузка ЦП, число подключений). - Весь обмен с устройствами подробно журналируется в файлы, чтобы его можно было проанализировать при обнаружении проблем и сбоев. ### Принципы обмена данными Ниже приведена схема сеанса связи между IoT-устройством и демоном сбора: ```mermaid sequenceDiagram autonumber participant D as IoT device participant I as Data collection
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. Подсистема управления хранит в этой базе данных всю необходимую конфигурацию опрашиваемых IoT-устройств. Демоны сбора данных используют эти настройки для установления связи с устройствами и выполнения операций обмена данными. Результаты успешного взаимодействия с устройствами автоматически сохраняются демонами в специализированной таблице той же базы данных, что обеспечивает прозрачность передачи данных между уровнем управления и устройствами. Схема взаимодействия подсистем показана ниже: ```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-й минуте каждого часа. Демон сам определяет наиболее подходящее расписание в момент связи с устройством и передаёт ближайшее.