Датчик — отдельный объект, а не просто sensor_id в измерении: он имеет UID, батарею, связь, статус и историю привязок.
Датчики давления шин карьерной техники должны управляться как отдельные активы TPMS, а не как случайные идентификаторы в измерениях. Для каждого датчика важны UID, serial number, radio_id, производитель, модель, протокол, тип монтажа, батарея, last_seen, последняя температура, давление, RSSI и история привязок. Датчик может быть на складе, установлен, снят, непривязанно активен, не на связи, с низкой батареей или в конфликте. Если датчик передает данные, но не привязан к позиции, система должна показывать его как непривязанный активный датчик, а не терять измерения и не угадывать позицию автоматически.
Датчик перемещается между позициями и шинами, имеет батарею, связь, протокол и историю замен. Поэтому его нельзя сводить к полю sensor_id в последнем TPMS-пакете.
UID, serial number, radio_id, vendor, model, protocol и mounting_type.
Склад, установлен, снят, offline, battery_low, unassigned_live или conflict.
Когда, куда, кем и почему датчик был привязан, заменен или отвязан.
Эти идентификаторы часто смешивают, но для промышленного учета они имеют разные роли. UID нужен для сопоставления потока, serial number — для физического учета, radio_id — для радиопротокола или приемника.
Стабильный ключ, по которому платформа узнает датчик в потоке.
Физический номер для склада, закупки, ремонта и замены.
Идентификатор канала или протокола, который помогает разбирать интеграционные конфликты.
Корректная схема выглядит так: Датчик → Позиция FL → Шина №12345 → Самосвал №7 → последние pressure/temp данные. Ошибка в любой точке испортит события, инспекции и экономику.
Дает ответ, какое колесо требует осмотра.
Сохраняет историю ресурса и событий конкретного tire asset.
Позволяет связать сигнал с диспетчеризацией, маршрутом и ТОиР.
Датчик может перемещаться между шинами и машинами, поэтому история важнее одного текущего поля sensor_id.
| Проблема | Данные | Аналитика | Действие |
|---|---|---|---|
| На складе | UID, serial number, vendor, model | готов к установке, но не участвует в TPMS-контроле | проверить паспорт и подготовить к монтажу |
| Установлен | equipment_id, position_code, tire_asset_id | измерения можно связать с колесом и шиной | контролировать батарею, связь и последние пакеты |
| Передает без позиции | sensor_uid, pressure, temperature, last_seen | unassigned_live, риск потери контекста | оператор привязывает к позиции после проверки |
| Низкая батарея | battery_status, voltage, last_seen | риск потери контроля позиции | запланировать замену датчика |
| Не на связи | last_seen_at, RSSI, приемник | нет актуального давления и температуры | проверить приемник, монтаж и питание |
| Конфликт | две active assignment или противоречивый payload | ошибочная история шины и событий | разобрать вручную, не переносить автоматически |
Управление датчиками строится через явные действия оператора и сохранение истории.
Добавить sensor_uid, serial_number, производителя, модель и тип монтажа.
Выбрать машину, позицию и при необходимости физическую шину.
Обновлять last_seen, pressure, temperature, battery и RSSI.
Закрыть старую active assignment и создать новую.
Сохранить историю снятия и причину.
Показывать offline, battery_low, unassigned_live и conflict.
Метрики должны строиться на фактических данных и показывать качество входной информации.
Норма, низкая, критическая или неизвестная.
Последняя связь датчика и контроль offline.
Качество радиосигнала при наличии данных.
Когда, куда и почему датчик был привязан или снят.
Поступает сигнал, но нет позиции.
Противоречие между датчиками и позицией.
После монтажа новой шины оператор выбирает позицию FL на схеме, добавляет датчик TPMS-000123 и привязывает его к машине и tire_asset. Через месяц батарея становится низкой: инженер открывает позицию, видит UID, last seen и батарею, выбирает новый датчик из реестра, указывает причину “Низкая батарея” и сохраняет историю замены.
Если датчик передает данные, но не привязан к позиции, MQTECH показывает его как unassigned_live: видны UID, давление, температура и last_seen, но нет автоматической догадки по колесу. Оператор открывает схему, сверяет монтаж, выбирает позицию FL, связывает датчик с шиной №12345 и самосвалом №7. При последующей замене старая assignment закрывается, новая создается, а история не теряется.
Нельзя автоматически переносить датчик между позициями только по совпадению payload. При конфликте нужен оператор, потому что ошибочная привязка испортит историю шины, события и аналитику.
Блок описывает реализованные контуры продукта, а не обещание автоматического эффекта.
Список, поиск, фильтр по статусу и добавление датчика.
Company-scoped привязка к машине, позиции и шине.
Старая привязка закрывается, новая создается.
История сохраняется, датчик получает статус снят.
Unknown sensor из потока может стать unassigned_live.
UID, батарея, последняя связь, давление и температура видны на схеме.
Датчик нельзя считать доказательством установки шины без корректной assignment. Ошибка привязки и sensor conflict должны решаться вручную.
Шинный контур полезнее, когда он связан с телеметрией, ТОиР, дорогами, TCO, оборудованием и диагностикой.
Ответы раскрывают условия применения, ограничения данных и роль инженера.
Датчик живет дольше одного измерения и может перемещаться между позициями, шинами и машинами. Если хранить только строковый sensor_id в пакете, невозможно нормально вести батарею, связь, историю замен и конфликты. Поэтому нужен реестр датчиков.
Это датчик, который передает данные, но еще не привязан к позиции. Такой статус полезен при первичном подключении или после замены. Система не должна угадывать позицию автоматически, потому что ошибка испортит историю.
Нужно закрыть текущую активную привязку с причиной замены и создать новую для нового датчика. История старой привязки остается в системе. Так инженер видит, когда и почему датчик был снят.
Конфликт означает, что два датчика претендуют на одну позицию или payload противоречит текущей привязке. Автоматическая переустановка опасна, поэтому оператор должен проверить монтаж, UID и позицию. После подтверждения выполняется ручная замена или отвязка.