Как построить систему мониторинга датчиков в реальном времени для складов и не только

Если вы строите рабочие процессы для складов, объектов холодовой цепи или технических площадок, этот кейс показывает, как превратить уже собранные телематические данные в целевую систему мониторинга датчиков без отдельного пайплайна данных. Здесь же разобрана архитектура приложения: доступ к PostgreSQL, конфигурация датчиков, живая логика порогов, история, отчеты и карта.

Возьмите склад, где показания температуры и влажности уже собираются с подключенных устройств. Операционной команде может не понадобиться еще один экран, организованный по трекерам и ID датчиков. Ей может быть нужен более простой ответ: какие холодильные камеры или зоны хранения сейчас находятся в заданном диапазоне?

IoT Query, платформа аналитики флотов Navixy, дает структурированный доступ к данным флота и датчиков через PostgreSQL, а интегратор задает интерфейс вокруг процесса клиента. Sensoriqua, приложение, построенное партнером Navixy, показывает этот подход. Оно группирует отдельные каналы датчиков по физической зоне, применяет настроенные пределы и показывает операционный статус раньше сырых значений.

Цветовая кодировка в интерфейсе упрощает чтение статуса без проверки каждого показания. Зеленый означает, что все настроенные показания в зоне находятся в заданном диапазоне. Красный выделяет зону, где хотя бы один датчик вышел за порог. Нейтральный статус означает, что для этого датчика порог не задан.

Где применяется зонный мониторинг датчиков

Тот же прикладной паттерн подходит для сценариев, в которых пользователи работают с физическими локациями, а не с ID устройств:

• Клиентам фармацевтики и продовольственных складов могут быть нужны записи температуры и влажности по зонам хранения, оформленные по GxP или стандартам соответствия холодовой цепи. Для аудиторского следа важен вопрос, какая зона оставалась в заданном диапазоне, а не какой ID устройства дал отдельное показание.
• Клиентам ЦОД и серверных могут быть нужны статусы по ряду стоек или по комнате, чтобы операционная команда проверяла конкретную зону без сверки с таблицей.
• Клиенты чистых комнат и лабораторий мониторят условия среды, которые могут различаться между участками контролируемого пространства.
• Клиенты теплиц и сельского хозяйства могут отслеживать микроклимат по секторам выращивания, где условия отличаются между секциями одной площадки.
• Операторы музеев и архивов могут организовать мониторинг температуры и влажности по комнатам, сопоставляя показания с пространствами хранения коллекций.
• Промышленные клиенты могут группировать данные о состоянии оборудования по линии, цеху или крылу здания.

В каждом случае IoT Query поставляет исходные телематические данные и данные датчиков. Интегратор определяет, как приложение сопоставляет эти показания с локациями и операционными понятиями клиента.

Из чего состоит кастомная система мониторинга датчиков

Sensoriqua — референсная реализация, построенная партнером Navixy под конкретный тип процесса. Приложение работает поверх Navixy IoT Query и обращается к данным датчиков прямым SQL.

Архитектура сочетает три прикладных слоя и дополняется историей, отчетами и картой:

1. Доступ к данным: прямое PostgreSQL-подключение к базе внутри IoT Query.
2. Конфигурация датчиков: постоянный маппинг между исходными объектами, каналами датчиков, зонами клиента, порогами, коэффициентами масштаба и подписями. Данные датчиков можно организовать независимо от трекеров, которые их доставили.
3. Живая доска: дашборд, который опрашивает свежие значения с настраиваемым интервалом, оценивает пороги в браузере и показывает агрегированный статус по зоне.
4. История и отчеты: представление запросов для сравнения показаний во времени, просмотра дневных минимума, максимума и среднего, а также поиска аномалий и повторяющихся паттернов.
5. Карта: представление локаций, которое размещает наблюдаемые объекты на карте и позволяет фильтровать их по условию порога. Это полезно, когда склады или другие объекты распределены по нескольким площадкам.

Бэкенд получает данные и хранит конфигурацию приложения. Фронтенд считает текущее визуальное состояние по последнему ответу, поэтому статус зоны не нужно вести отдельной серверной записью.

Слой 1: Прямой доступ к данным датчиков через IoT Query

При входе бэкенд Sensoriqua отправляет учетные данные пользователя в Navixy App Connect. Этот инструмент служит интеграционным шлюзом: аутентификация платформы и доступ к базам остаются в прикладном контексте Navixy, а Sensoriqua ведет клиентский процесс.

Показания доступны через raw_telematics_data и raw_business_data: значения датчиков представлены колонками, а не строками. Чтобы заполнить список доступных датчиков для каждого объекта, Sensoriqua динамически запрашивает наборы колонок в inputs, states и tracking_data_core.

Подробности сырого слоя IoT Query — в документации Navixy для аналитиков.

В итоге оператор, настраивающий систему мониторинга датчиков, видит имена устройств, которые реально есть в данных клиента, а не выбирает из заранее заданного статического списка.

Прямой SQL также дает интегратору контроль над тем, как эти данные запрашиваются. Приложение может, например, считать минутные средние, менять окна спарклайнов или запрашивать конкретный исторический период без дополнительного эндпоинта в фиксированном REST-контракте.

Запрос и интерфейс можно подогнать под процесс мониторинга клиента, а IoT Query остается нижележащим слоем данных.

Слой 2: Настройка датчиков независимо от трекеров

Второй слой — постоянная карта датчиков, которая задает, какие датчики относятся к каждой зоне и как интерпретировать показания.

Для каждого настроенного датчика хранятся:

• объект и колонка исходной таблицы, откуда идет чтение
• человекочитаемая подпись
• множитель, используемый как коэффициент масштаба перед отображением для перевода единиц или калибровки
• пороги MIN и MAX, которые задают рабочий диапазон для визуального статуса
• глубина спарклайна: сколько часов минутных средних показывает виджет — 1, 2, 4 или 8 часов

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

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

Сама карта датчиков хранится в базе состояния приложения.

Слой 3: Расчет живого статуса зоны по свежим показаниям

Живая доска использует опрос (polling), а не push-обновления. Она запрашивает свежие данные с настраиваемым интервалом 30 секунд, 1 минута или 5 минут.

Эндпоинты живых данных напрямую запрашивают PostgreSQL IoT Query и возвращают значения датчиков. Оценка порогов затем выполняется в браузере.

После применения настроенного множителя фронтенд сравнивает каждое показание с границами MIN и MAX. Значение вне любой из границ переводит статус этого датчика в красный. Если любой датчик в зоне красный, панель зоны тоже отображается красной. Если все настроенные датчики остаются в порогах, панель зеленая. Нейтральный датчик не имеет заданного порога.

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

В текущей реализации приложение не ведет серверную запись момента пересечения порога. Оно также не отправляет push-уведомления и не ставит оповещения в очередь. Если опрос не удался, отображаемые значения остаются без изменений до следующего успешного запроса.

Просмотр исторических показаний и дневных отчетов

Живая доска отвечает на вопрос, находится ли наблюдаемая зона сейчас в диапазоне. Виды истории и отчетов Sensoriqua дают исходные показания для более длинного разбора.

Эндпоинт истории принимает ID объекта, имя датчика и диапазон времени, затем получает сырые показания из IoT Query за период до 90 дней. Приложение рисует их как интерактивный график с наложенными полосами порогов.

Вид отчета агрегирует временной ряд в дневную статистику по каждому датчику:

• минимум
• максимум
• среднее

Отчеты можно выгрузить в нескольких форматах:

• JSON: сырые дневные агрегаты
• HTML и PDF: оформленные таблицы со встроенными графиками
• XLSX: табличный вывод

Агрегация и отрисовка происходят в браузере. Бэкенд остается слоем получения данных, а клиентское приложение формирует и скачивает отчет без дополнительного серверного рендера.

Географический контекст для исключений по датчикам

IoT Query также дает Sensoriqua доступ к данным локации, связанным с наблюдаемыми объектами. Карта Sensoriqua наносит последнюю GPS-позицию каждого объекта вместе с недавними показаниями. Операторы могут фильтровать карту по бизнес-сущности и условию порога.

Если клиент ведет несколько складов или технических площадок, оператор может отфильтровать объекты с показаниями вне диапазона, найти нужную площадку и открыть детальный вид датчиков.

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

Собирать приложение мониторинга на слое данных IoT Query

Сырой слой данных IoT Query позволяет Sensoriqua читать поток датчиков через PostgreSQL без отдельного middleware API и без кастомного ETL-пайплайна.

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

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

Navixy IoT Logic, инструмент автоматизации обработки данных, может независимо запускать правила по тому же потоку. Так представление данных в кастомном приложении отделено от автоматизации процессов.

Использовать Sensoriqua как референсную реализацию

Для телематических сервис-провайдеров и системных интеграторов кейс показывает, как кастомное приложение можно собрать на уже существующих возможностях Navixy:

• аутентификация App Connect
• прямые PostgreSQL-запросы к IoT Query
• постоянная схема зон и конфигурации датчиков
• клиентская оценка порогов
• запросы исторических данных
• выгрузки дневных сводок
• географическая фильтрация наблюдаемых объектов

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

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