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

Логистика с контролем температуры держится на одном допущении: чистый лог означает безопасную доставку. Так бывает не всегда. Партию фармацевтического дистрибьютора бракуют. Лог выглядел чистым: 18 часов при 3,2 °C. Но аудитор обнаружил 20 минут на погрузочной платформе с открытой дверью — скачок, который стандартные отчёты по рейсам так и не поймали. Большинство систем показывают треки и пороги. Trips Intelli — бесплатное приложение с открытым исходным кодом от Navixy — восстанавливает такой рейс на единой временной шкале, где остановки, открытия дверей и показания датчиков собраны в одном месте.

Часто данные есть, но они разбросаны по трём таблицам с тремя разными разрешениями, и ничто не связывает их, чтобы восстановить тот самый момент. Данные по страховым претензиям TT Club указывают на то же. Более половины инцидентов с контролем температуры вызваны неверно переданными инструкциями по обращению с грузом и ошибочными настройками температуры, тогда как отказ или повреждение оборудования дают около четверти. В этом случае рефрижератор держал температуру всю ночь. Груз оказался под воздействием в течение 22 минут на платформе.

Этот материал показывает, как аналитический слой может ответить на вопрос аудитора: что именно произошло на погрузочной платформе в 14:22?

Изменения состояния — вот где температурно-чувствительные грузы действительно страдают

Руководство ВОЗ по хранению и транспортировке фармацевтической продукции, чувствительной к времени и температуре (TRS 961, Приложение 9), затрагивает эти моменты через требования к погрузочным зонам, квалификации маршрутов перевозки и мониторингу температуры в пути. В рефрижераторной автомобильной перевозке груз наиболее уязвим в точках перегрузки:

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

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

Регуляторное следствие вытекает логически. Руководство ЕС по надлежащей практике дистрибуции (2013/C 343/01) требует, чтобы отклонения температуры в ходе перевозки сообщались дистрибьютору и получателю и расследовались по установленной процедуре. Дистрибьютор также должен уметь доказать, что лекарственные средства не подвергались воздействию условий, способных снизить их качество. GUI-0069 от Health Canada (руководство по контролю окружающей среды для лекарств при хранении и транспортировке) устанавливает схожие требования для препаратов в пути. «Проходное» среднечасовое значение мало что даёт следователю, когда отклонение длилось 22 минуты.

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

Проблема интеграции в логистике с контролем температуры

Вот конкретная проблема с данными. Современное телематическое развёртывание обычно порождает три потока: трек GPS-позиций, лог температурного датчика и события телеметрии — такие как зажигание вкл./выкл. и открытие/закрытие двери.

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

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

Вот он, разрыв. Это не проблема оборудования. Это проблема архитектуры данных.

Navixy IoT Query — платформа аналитики данных — открывает весь набор телеметрических и бизнес-данных как прямое подключение к PostgreSQL: данные трекинга, показания датчиков, события геозон, пользовательские состояния и метаданные рейсов в схеме, которую можно запрашивать стандартным SQL. IoT Query делает связку возможной. Trips Intelli делает расследование удобным.

Что такое Trips Intelli

Приложение Trips Intelli закрывает недостающий слой корреляции событий на уровне рейса как комплексное приложение аналитики рейсов. У него нет собственного слоя приёма данных. Оно подключается к той же поверхности PostgreSQL, которую может запрашивать любой пользователь Navixy с доступом к IoT Query, и прогоняет по этим данным многоэтапный конвейер обработки, формируя аналитику рейсов и записи для комплаенса.

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

Пять вопросов расследования, на которые есть ответ на уровне рейса

Аудитор по комплаенсу, разбирающий температурно-контролируемую доставку, задаёт определённый класс вопросов.

Не «Какова была средняя температура?», а:

• Где находилась машина, когда датчик пересёк порог?
• Была ли дверь открыта в тот момент?
• Это была плановая остановка или незапланированное отклонение?
• Не работал ли этот водитель сверхурочные смены?
• Каков профиль риска этого рейса по сравнению с другими на том же коридоре?

Ни на один из этих вопросов нельзя ответить, имея только температурную ленту и GPS-лог. Комплаенс холодовой цепи нужно понимать в контексте всего рейса, а не как отдельный график температуры. Trips Intelli создан, чтобы свести маршрут, температуру, события дверей, остановки и статус рейса в единый контекст расследования.

Сегментация рейсов с классификацией стоянок. Конвейер разбивает каждый поток позиций на рейсы и остановки, классифицирует каждую остановку как MOVING, PARKING или ENGINE_ON_PARKING и добавляет длительность и контекст геозоны. 22-минутная остановка у погрузочной платформы распределительного центра — это отдельное, помеченное событие, а не пробел в GPS-треке.

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

Мониторинг порогов датчиков в контексте геозоны. Температуру, уровень топлива, влажность или любой датчик, доступный в схеме IoT Query, можно отслеживать по настраиваемым порогам мин./макс. Оповещение включает показание датчика, метку времени и геозону, в которой машина находилась в этот момент. Это значит, что вы можете ответить на вопрос «Отклонение произошло во время погрузки на складе отправления B или в пути?» одним запросом, а не ручной связкой.

Корреляция состояния двери с местоположением и температурой. События открытия двери сопоставляются с позицией машины и показанием температуры на той же метке времени. Вместо просмотра отдельных графиков следователь может проследить многослойную временную шкалу, объединяющую температуру, состояние двери, положение на маршруте и статус рейса в одном представлении. Можно увидеть, например, что температура поднялась с 3 °C до 11 °C за 14-минутное событие открытой двери в координатах [x, y], пока машина находилась вне ожидаемого маршрутного коридора. Именно такую последовательность и нужно восстановить регуляторному расследованию.

ML-оценка аномалий с объяснением понятным текстом. Каждый рейс получает оценку риска от модели IsolationForest, обученной на собственной истории рейсов автопарка. Аномальные рейсы всплывают с объяснением понятным текстом: «Вне смены / ночное время», «Необычная длительность для этого коридора» или «Паттерн отклонения датчика не согласуется с маршрутом». Аналитик может расставлять приоритеты расследований, не читая каждую сырую запись. Оценка — это вероятностный индикатор; помеченный рейс требует проверки, а не автоматического отрицательного вывода.

Узнайте больше о разных уровнях отчётности по рейсам в Navixy.

Представление, превращающее сырую телеметрию в запись расследования

Главное представление приложения — таблица рейсов с панелью фильтров, встроенной картой и временной шкалой статусов. Менеджер по комплаенсу, разбирающий помеченную партию, может отфильтровать по отклонению датчика, событию двери или отклонению маршрута, выбрать рейс и увидеть полностью восстановленную временную шкалу в одном представлении: GPS-позицию, канал температуры, состояние двери и аннотированные маркеры событий. Экспорт в XLSX — в один клик.

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

Результаты по ролям: что реально меняется

Trips Intelli формирует единую запись на уровне рейса, сводя данные GPS, датчиков и событий в одно представление. Меняется то, какую часть записи читает каждая роль.

Для менеджера по комплаенсу: отклонение температуры можно отследить до конкретного события погрузки или открытия двери, которое его вызвало, с меткой времени, местоположением и длительностью. НПД ЕС и GUI-0069 Health Canada требуют именно этого перед решением о судьбе партии. Раньше такую запись собирали вручную из трёх систем; теперь это одно отфильтрованное представление.

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

Для менеджера автопарка: ML-оценки аномалий делают еженедельный разбор посильным. Автопарк из 200 машин генерирует 1400 рейсов в неделю. Читать каждую запись — не вариант. Топ-12 по оценке риска, просмотренные в понедельник утром, охватывают инциденты, требующие внимания, включая те, где температурный лог выглядел бы безупречно.

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

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

Первые шаги с Trips Intelli: схема уже на месте

IoT Query — это поверхность подключения к PostgreSQL, к которой обращается Trips Intelli. Если операция клиента по логистике с контролем температуры уже работает на данных автопарка Navixy (GPS-позиции, показания датчиков, события геозон), схема уже на месте. Строить слой приёма данных не нужно.

Это ровно тот тип проблемы, с которой ваши собственные клиенты уже сталкиваются: партия, забракованная на шатких доказательствах, команда комплаенса, задающая вопросы, на которые данные автопарка пока не могут ответить. Trips Intelli даёт готовый ответ — решение, которое можно предложить любому клиенту, перевозящему температурно-чувствительный груз, не выстраивая логику корреляции событий самостоятельно.

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