Самовосстанавливающийся трекинг активов: как автоматизация сократила количество выездов на 80%

Трекеры редко выходят из строя все сразу. Чаще всего они продолжают передавать данные, постепенно теряя качество сведений, от которых зависит работа автопарка. В этом примере из практики показано, как один контейнерный терминал автоматизировал восстановление устройств с помощью шаблона Device Health Check в Navixy IoT Logic, сократив ручные действия по восстановлению на 80%. Также рассказывается, как этот же подход может перерасти в гораздо более всеобъемлющую систему контроля состояния устройств.

Когда трекеры остаются в сети, но перестают быть надежными

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

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

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

Узнайте больше о готовых автоматизациях с IoT Logic:

• Автоматическая реакция на холостой ход
• Контроль доступа водителей

Автоматизация состояния устройств без разработки с нуля

Построить подобный рабочий процесс несложно, но это однообразная работа. Каждая реализация должна принимать телеметрию, оценивать состояние устройства, решать, нужно ли восстановление, выполнять соответствующее действие и продолжать обработку.

Шаблон Device Health Check в Navixy IoT Logic уже содержит этот рабочий процесс. Вместо проектирования логики с нуля инженеры могут адаптировать условия работоспособности и действия по восстановлению к своим устройствам и условиям эксплуатации.

На высоком уровне процесс остается неизменным для любого автопарка:

1. Получение входящей телеметрии.
2. Оценка настроенных условий работоспособности.
3. Продолжение обычной обработки, если устройство исправно.
4. Выполнение указанных действий по восстановлению, если нет.

Шаблон предназначен для доработки, а не для прямого использования без изменений. В разных автопарках свои характерные отказы, разное оборудование и разные критерии «исправности». Основной алгоритм при этом остается прежним, а модель оценки работоспособности может развиваться.

Пример из практики: адаптация шаблона для техники портового терминала

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

В парке использовались GPS-трекеры Teltonika, которые могут контролировать внешнее питание, конфигурируемую телеметрию, интеграцию с CAN и выполнять удаленные команды. Хотя в данном случае речь идет о Teltonika, общий подход подходит и к любым трекерам, поддерживающим удаленное управление.

Установка охватывала транспорт с постоянным питанием, который непрерывно передает телеметрию и может принимать удаленные команды. Трекеры с батарейным питанием в режиме глубокого сна требуют иного подхода к мониторингу.

Операционная задача

Команда по обслуживанию неоднократно сталкивалась с одинаковой ситуацией: трекер вел себя странно. Он все еще был в сети, но что-то явно работало не так. Прием GNSS ухудшался между контейнерными штабелями. Внешнее питание становилось нестабильным после обслуживания. Порой трекер переставал выдавать надежные координаты, хотя оставался на связи с платформой.

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

Ни одна из таких ситуаций по отдельности не оправдывала разработку программного проекта. Все вместе они представляли собой постоянный поток рутинной работы, которая отнимала время инженеров и не приносила большой пользы.

Начало работы со стандартным шаблоном Device Health Check

Вместо создания собственного процесса команда воспользовалась стандартным шаблоном Device Health Check, который поставляется с Navixy IoT Logic.

Из коробки шаблон оценивает четыре основных условия работоспособности:

latitude != null &&
longitude != null &&
satellites >= 4 &&
board_voltage >= 11.5

Если это выражение даёт TRUE, телеметрия продолжает идти по обычному маршруту обработки.

Если FALSE, данные всё равно перенаправляются дальше, но в то же время workflow выполняет заданное действие по восстановлению. В стандартном шаблоне есть команды перезагрузки устройств для Teltonika (cpureset) и Jimi/Concox (RESET#), что позволяет изначально поддерживать разные линейки оборудования.

Поскольку в парке терминала использовались только устройства Teltonika, команда просто удалила узел с перезагрузкой Jimi и оставила действие для Teltonika.

Сами критерии исправности изменились совсем немного: вместо универсального board_voltage использовался конкретный параметр Teltonika external_voltage. Порог спутников подняли с четырех до пяти. Добавили условие HDOP для более точной оценки GNSS в среде, где краны, штабеля контейнеров и обилие металла делают прием спутниковых сигналов, как известно, весьма нестабильным.

Итоговое условие работоспособности:

external_voltage >= 11.5 &&
latitude != null &&
longitude != null &&
satellites >= 5 &&
(hdop == null || hdop < 2.5)

Все остальное оставили без изменений.

Каков результат?

90-дневный пилотный проект сократил ручные операции по восстановлению трекеров примерно на 80%. Но главное, изменился сам подход к обслуживанию. Устройства, соответствующие заданным критериям восстановления, перезагружались автоматически, зачастую ещё до того, как кто-то замечал проблему. Техники подключались только в случае, когда автоматическое восстановление не помогало, или когда условия здоровья указывали на аппаратные неполадки, а не на временные сбои.

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

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

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

Создание более сложной модели работоспособности устройства

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

Возникает закономерный вопрос: если такой результат достигается при контроле всего четырех-пяти параметров, что будет, если модель работоспособности отразит условия эксплуатации более детально?

Портовые терминалы — хороший пример.

Техника работает среди штабелей контейнеров, кранов, складов и массивных металлических конструкций. Условия приема GNSS-сигналов постоянно меняются. Проводка подвергается вибрациям. При обслуживании возможны перебои питания. CAN-связь может пропадать, даже если сам трекер остается в сети.

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

Обычно в таких случаях контролируются четыре группы параметров:

Область работоспособности	Типичные параметры
GNSS	Количество спутников, HDOP, валидность фиксации, время с последней корректной позиции
Питание	Внешнее напряжение, резервная батарея, состояние зажигания, стабильность напряжения
Связь	Качество сигнала, количество переподключений, частота пакетов, время с последней связи
Интерфейс с ТС	CAN availability, свежесть данных двигателя, цифровые входы

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

Построение логики

Когда нужная телеметрия доступна, к формированию условий работоспособности обычно подходят двумя способами.

Один вариант — описать, как выглядит исправный трекер.

Узел If-then просто проверяет, соответствуют ли входящие данные ожидаемым условиям работы.

Например:

external_voltage >= 11.5 &&
communication_status == "stable" &&
gnss_quality == "good" &&
can_available == true

Если выражение даёт TRUE, процесс продолжается в нормальном режиме.

Если FALSE, трекер вышел за границы ожидаемого состояния, и активируется ветка восстановления.

Второй вариант — описать конкретные ситуации сбоя, которые должны вызвать реакцию.

Например:

external_voltage >= 11.5 &&
communication_status == "stable" &&
gnss_quality == "poor" &&
gnss_bad_duration_min > 10

Здесь у трекера еще есть питание и связь, но качество GNSS достаточно долго остается низким, чтобы считать, что подсистеме позиционирования требуется внимание.

На практике оба подхода хорошо сочетаются.

Сначала проверяется простой вопрос:

"Исправен ли трекер?"

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

Когда телеметрии не хватает

При разработке модели нередко выясняется, что нужны параметры, которые трекер не передает.

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

Здесь пригодится узел Initiate Attribute.

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

Процесс будет выглядеть так:

Incoming telemetry
        │
        ▼
Initiate Attribute
(create operational attributes)
        │
        ▼
Device Health Check
        │
        ▼
Recovery actions

Узел Initiate Attribute — это своего рода слой преобразования.

Исходная телеметрия описывает, что именно передает трекер.

Операционные атрибуты описывают, что означают полученные данные.

Пример: оценка качества GNSS

Предположим, что трекер передает:

• latitude,
• longitude,
• количество спутников,
• HDOP.

Вместо того чтобы повсюду проверять эти четыре показателя, можно в узле Initiate Attribute объединить их в один атрибут:

gnss_quality

Например:

| Входящей телеметрии нет координат | Плохое | | Спутников меньше 5 | Плохое | | HDOP ≥ 4 | Плохое | | HDOP от 2,5 до 4 | Ниже нормы | | Иначе | Хорошее |

Теперь в проверке работоспособности достаточно:

gnss_quality == "good"

вместо анализа нескольких значений.

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

Это важно:

Рабочий процесс не усложняется.

Зато понимание здоровья устройства становится глубже, а процедуры при этом остаются почти неизменны.

Новый взгляд на работоспособность устройств

Самый интересный итог проекта — это не только 80% сокращение ручных операций при восстановлении трекеров, но и переход от вопроса «В сети ли трекер?» к вопросу «Можно ли доверять его данным?».

Это принципиально важный момент, ведь современная телематика поддерживает не только диспетчеризацию, но и обслуживание, контроль соответствия, анализ эффективности использования и планирование эксплуатации. Устройство может оставаться на связи, постепенно выдавая всё более неточные или неполные данные. С точки зрения платформы оно «онлайн», но с практической точки зрения оно уже перестает выполнять свою функцию.

Мониторинг работоспособности решает эту проблему. Вместо того чтобы реагировать постфактум, когда кто-то заметит неполадки, операторы заранее определяют, что считается «исправностью» в их автопарке, непрерывно отслеживают эти параметры и автоматически выполняют первый шаг по восстановлению, если трекер выходит за установленные рамки. Шаблон Device Health Check — это удобная отправная точка для такого подхода. По мере изменения требований модель оценки состояния усложняется, а базовый алгоритм остается понятным.

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

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