Ru | En
8 800 700 34 45 info@axenta.tech
Оставить заявку ico
Новости

Техническое задание на мониторинг грузового транспорта: что обязательно включить

Техническое задание на мониторинг грузового транспорта должно описывать не просто количество GPS/ГЛОНАСС-трекеров, которые необходимо установить. Хорошее ТЗ фиксирует, какие данные должен получать бизнес, с какой точностью и периодичностью, как они должны обрабатываться, какие события должна определять система и по каким критериям заказчик будет принимать результат.

Формулировки вроде «установить GPS на 50 грузовиков» недостаточно.

Правильное техническое задание должно отвечать минимум на семь вопросов:

что контролируем → откуда получаем данные → какое оборудование используем → как передаём данные → как обрабатываем → что видит пользователь → как проверяем результат.

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

Поэтому ТЗ на GPS/ГЛОНАСС-мониторинг грузового транспорта должно начинаться с бизнес-задач, а заканчиватьcя измеримыми критериями приёмки.

Что такое техническое задание на систему мониторинга транспорта

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

Оно должно быть одинаково понятно:

  • руководителю автопарка;
  • техническому специалисту;
  • логисту;
  • специалисту по ГСМ;
  • IT-службе;
  • интегратору;
  • монтажной организации;
  • поставщику программного обеспечения.

Главная задача документа — исключить ситуацию, когда заказчик говорит:

«Мы хотели контролировать топливо»,

а исполнитель отвечает:

«Но в договоре была указана только установка GPS-трекера».

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

Чем ТЗ отличается от коммерческого предложения

Это два разных документа.

Техническое задание отвечает:

Что должна делать система?

Коммерческое предложение отвечает:

Сколько будет стоить реализация этих требований?

Сначала желательно сформировать требования.

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

Иначе компании сравнивают совершенно разные решения исключительно по итоговой цене.

Один поставщик включает:

GPS/ГЛОНАСС + CAN + два ДУТ + тарировку + монтаж + настройку.

Другой:

только GPS-трекер.

Формально оба предложения называются «мониторинг транспорта», но фактически решают совершенно разные задачи.

Структура правильного технического задания

Полноценное ТЗ на мониторинг грузового автопарка я рекомендую разделять на 15 основных частей:

  • сведения об автопарке;
  • цели проекта;
  • перечень контролируемых объектов;
  • требования к данным;
  • требования к навигационному оборудованию;
  • требования к CAN/FMS;
  • требования к контролю топлива;
  • требования к прицепам и полуприцепам;
  • требования к дополнительным датчикам;
  • требования к передаче и хранению данных;
  • требования к программной платформе;
  • уведомления и отчётность;
  • интеграции;
  • монтаж и документация;
  • критерии приёмки.

Разберём каждый раздел подробнее.

1. Сведения об автопарке

Первый раздел должен описывать объект внедрения.

Необходимо указать количество транспортных средств и структуру парка.

Например:

Тип

Количество

Магистральные тягачи

50

Рефрижераторы

10

Полуприцепы

65

Грузовые фургоны

15

Но одной классификации недостаточно.

Желательно подготовить отдельную таблицу автомобилей.

Пример

№

Автомобиль

Год

Баков

CAN/FMS

ДУТ

Полуприцеп

1

Volvo FH

2024

2

Да

Нет

Да

2

MAN TGX

2022

2

Да

Нет

Да

3

КАМАЗ

2019

1

Проверить

Нет

Нет

4

Scania R

2023

2

Да

Есть

Да

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

2. Цель внедрения

Одна из самых важных частей ТЗ.

Не пишите:

Цель — внедрить систему GPS/ГЛОНАСС-мониторинга.

Это описание технологии, а не бизнес-цели.

Лучше:

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

Или:

Цель проекта — сформировать единый источник достоверных телематических данных для диспетчерской, логистической, технической и управленческой аналитики.

После этого можно перечислить конкретные задачи.

Например:

  • контроль маршрутов;
  • снижение простоев;
  • контроль топлива;
  • контроль полуприцепов;
  • контроль температуры;
  • получение данных CAN/FMS;
  • автоматическая отчётность;
  • интеграция с 1С или TMS.

3. Какие объекты должны контролироваться

В грузовой логистике «автомобиль» не всегда равен одному объекту мониторинга.

Например:

тягач + полуприцеп — это два самостоятельных актива.

Сегодня они работают вместе.

Завтра тягач уезжает с другим полуприцепом.

Поэтому в ТЗ необходимо отдельно определить:

Транспортные средства

  • тягачи;
  • фургоны;
  • рефрижераторы;
  • спецтехника.

Дополнительные активы

  • прицепы;
  • полуприцепы;
  • контейнеры;
  • другое мобильное оборудование.

Если требуется видеть полуприцеп после расцепки, это должно быть прямо записано:

После отсоединения от тягача полуприцеп должен продолжать отображаться в системе как самостоятельный объект мониторинга.

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

4. Требования к координатам и движению

Вместо общего:

Система должна показывать автомобиль на карте,

лучше описать необходимые данные.

Например:

Система должна получать и хранить:

  • координаты;
  • дату и время;
  • скорость;
  • направление движения;
  • состояние движения/стоянки;
  • пробег;
  • маршрут;
  • историю перемещений.

Дополнительно необходимо определить частоту формирования сообщений.

Она может зависеть от:

  • времени;
  • расстояния;
  • изменения направления;
  • состояния зажигания;
  • наступления события.

Слишком редкая передача ухудшает детализацию трека.

Слишком частая увеличивает объём сообщений и мобильного трафика.

Поэтому частота должна определяться эксплуатационной задачей.

5. Требования к GPS/ГЛОНАСС-терминалу

Не стоит указывать только марку устройства.

Гораздо полезнее определить функциональные требования.

Например:

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

В ТЗ желательно указать требования к:

  • GNSS;
  • мобильной связи;
  • внутренней памяти;
  • резервному питанию;
  • CAN;
  • RS-232;
  • RS-485;
  • цифровым входам;
  • аналоговым входам;
  • Bluetooth — если требуется;
  • удалённой настройке;
  • температурному диапазону;
  • защите корпуса.

Главное — терминал должен соответствовать архитектуре проекта.

Если позже потребуется подключить два ДУТ, CAN, идентификацию водителя и дополнительные датчики, дешёвое устройство с минимальным количеством интерфейсов может потребовать замены.

6. Что прописать про работу без GSM

Для грузовых перевозок это обязательный раздел.

Автомобиль может находиться:

  • между городами;
  • в промышленной зоне;
  • возле границы;
  • в роуминге;
  • на территории со слабым мобильным покрытием.

GPS/ГЛОНАСС определяет местоположение, а GSM/LTE используется для передачи данных.

Поэтому хорошая формулировка требования выглядит так:

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

В критерии приёмки можно добавить тест:

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

Это уже проверяемое требование.

7. Требования к CAN/FMS

Формулировка:

Подключить CAN.

слишком расплывчата.

Необходимо указать, какие конкретно параметры нужны бизнесу.

Например:

Параметр

Требуется

Пробег

✓

Моточасы

✓

Обороты двигателя

✓

Скорость

✓

Расход топлива

✓

Уровень топлива

при наличии

Температура ОЖ

✓

Нагрузка двигателя

желательно

Ошибки

желательно

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

Поэтому полезно добавить:

Перед массовым монтажом исполнитель должен подтвердить перечень доступных CAN/FMS-параметров для каждой группы транспортных средств.

Это защищает заказчика от обещаний:

«CAN там есть — значит получим всё».

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

8. Требования к контролю топлива

Если топливо является одним из ключевых KPI, этот раздел необходимо описывать особенно подробно.

Сначала определяется источник данных.

Возможные варианты:

CAN/FMS

ДУТ

или

CAN/FMS + ДУТ.

Если используется ДУТ, в ТЗ необходимо указать:

  • количество датчиков;
  • количество баков;
  • способ подключения;
  • необходимость тарировки;
  • диапазон измерения;
  • требования к монтажу.

9. Как прописать автомобиль с двумя баками

Для магистрального тягача это принципиальный момент.

Плохая формулировка:

Установить контроль топлива.

Хорошая:

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

Если между баками возможен переток:

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

То есть аналитика должна учитывать:

бак №1 + бак №2 + суммарный остаток.

Критерий проверки

Во время перетока:

  • уровень первого бака уменьшается;
  • второго — увеличивается;
  • общий баланс изменяется в пределах допустимого расхода.

Такое событие не должно автоматически трактоваться только как слив.

10. Требования к заправкам

Если необходимо контролировать ГСМ, ТЗ должно описывать результат.

Например:

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

Для события желательно получать:

  • автомобиль;
  • дату;
  • время;
  • координаты;
  • геозону;
  • уровень до;
  • уровень после;
  • рассчитанный объём изменения.

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

телематическая заправка ↔ транзакция топливной карты.

11. Требования к возможным сливам

Здесь особенно важно избегать формулировки:

Система должна определять все сливы со 100%-ной точностью.

Телематика фиксирует изменение данных и формирует событие, которое требует интерпретации.

Корректнее:

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

Для проверки могут сопоставляться:

  • ДУТ;
  • GPS;
  • движение;
  • зажигание;
  • CAN;
  • геозона;
  • время;
  • два бака.

Так появляется полноценная логика:

событие → проверка → решение.

12. Требования к температурному контролю

Для рефрижераторов необходимо отдельно описать:

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

Пример:

При выходе температуры за установленный диапазон более чем на X минут система должна сформировать уведомление.

Очень важно указать именно условие формирования события, а не просто:

контролировать температуру.

13. Датчики дверей

Для перевозки ценных или температурных грузов можно добавить:

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

Дополнительно:

При открытии двери вне разрешённых геозон должно формироваться уведомление ответственному пользователю.

Теперь обычный дискретный датчик превращается в реальный бизнес-сценарий.

14. Требования к TPMS

Если необходимо контролировать шины, можно указать:

  • давление;
  • температуру;
  • идентификатор колеса;
  • пороги уведомлений.

Пример:

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

15. Требования к идентификации водителя

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

В ТЗ можно записать:

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

После этого можно рассчитывать:

  • пробег на водителя;
  • расход;
  • превышения;
  • резкие торможения;
  • нарушения;
  • время работы.

16. Геозоны

На этапе ТЗ необходимо определить не только наличие функции геозон, но и какие именно зоны нужны бизнесу.

Например:

  • база;
  • склад;
  • клиент;
  • терминал;
  • АЗС;
  • сервис;
  • погрузка;
  • разгрузка;
  • зона ожидания.

Для каждой можно определить события:

въезд

выезд

время нахождения.

Пример требования

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

AXENTA позволяет создавать геозоны и контролировать положение объектов относительно них.

17. Требования к трекам

В ТЗ желательно указать:

Пользователь должен иметь возможность строить историю движения объекта за выбранный период с отображением маршрута и связанных событий.

Для грузового транспорта особенно полезно отображать:

  • остановки;
  • стоянки;
  • заправки;
  • возможные сливы;
  • посещения геозон;
  • превышения;
  • другие события.

AXENTA поддерживает построение и воспроизведение треков с отображением событий движения объекта.

18. Какие уведомления прописывать

Не надо включать десятки уведомлений просто потому, что система их поддерживает.

Каждое уведомление должно отвечать на вопрос:

Какое действие совершит сотрудник после его получения?

Для грузового парка типовыми могут быть:

Событие

Получатель

Выход из маршрута

диспетчер

Вход в запрещённую геозону

диспетчер

Длительный простой

логист

Возможный слив

ГСМ / безопасность

Температурное отклонение

логист

Открытие двери вне зоны

безопасность

Потеря связи

технический специалист

Превышение скорости

руководитель автопарка

AXENTA предусматривает настройку уведомлений о событиях объектов.

19. Требования к отчётам

Фраза:

Нужны отчёты.

ничего не означает.

Надо определить конкретные показатели.

Отчёт по рейсам

  • начало;
  • окончание;
  • пробег;
  • длительность;
  • стоянки;
  • посещённые точки.

Отчёт по топливу

  • начальный уровень;
  • конечный уровень;
  • расход;
  • заправки;
  • возможные сливы.

Отчёт по простоям

  • автомобиль;
  • место;
  • начало;
  • окончание;
  • продолжительность.

Отчёт по водителям

  • водитель;
  • пробег;
  • время;
  • нарушения.

Управленческий отчёт

  • расход на 100 км;
  • простой;
  • пробег;
  • выполнение рейсов;
  • отклонения;
  • KPI.

Платформа AXENTA позволяет работать со стандартными отчётами и формировать собственные шаблоны на основе необходимых параметров.

20. Требования к пользователям и правам

Для большого автопарка всем пользователям не должен быть доступен весь парк и все функции.

В ТЗ следует определить роли.

Например:

Диспетчер

Видит:

  • свой автопарк;
  • карту;
  • маршруты;
  • уведомления.

Специалист по ГСМ

  • топливо;
  • ДУТ;
  • заправки;
  • события.

Механик

  • пробег;
  • моточасы;
  • CAN;
  • ТО.

Руководитель

  • весь парк;
  • KPI;
  • аналитика.

Дилер / интегратор

  • технические настройки в пределах необходимых полномочий.

AXENTA предусматривает работу с пользователями, группировкой объектов и настройкой прав доступа.

21. Требования к API и интеграциям

Для корпоративного автопарка это стоит определить ещё до покупки оборудования.

Необходимо ответить:

Нужно ли использовать телематические данные за пределами системы мониторинга?

Возможные потребители:

  • 1С;
  • TMS;
  • ERP;
  • BI;
  • система ТО;
  • собственный портал;
  • мобильное приложение.

В ТЗ желательно составить таблицу.

Данные

Источник

Куда передать

Координаты

AXENTA

TMS

Пробег

CAN/GPS

система ТО

Моточасы

CAN

система ТО

Топливо

ДУТ

BI

Геозоны

AXENTA

TMS

События

AXENTA

корпоративная система

Это позволяет IT-службе заранее оценить интеграционную часть проекта.

22. Совместимость существующего оборудования

Если в автопарке уже установлены терминалы, не нужно автоматически планировать их замену.

Сначала необходимо определить:

  • производителя;
  • модель;
  • протокол;
  • версию прошивки;
  • подключённые датчики.

В ТЗ можно включить:

Перед заменой существующего оборудования исполнитель обязан провести проверку его совместимости с целевой платформой мониторинга.

На странице решения для грузового транспорта AXENTA указывает поддержку существующего оборудования и универсальных протоколов Wialon IPS, Wialon Retranslator, Wialon Combine и EGTS; также предусмотрен запрос на добавление оборудования в платформу.

Это особенно важно для миграции больших парков.

Замена 500 работающих терминалов только ради смены платформы способна значительно увеличить стоимость проекта.

23. Требования к передаче данных

Необходимо определить:

  • используемую мобильную сеть;
  • SIM;
  • роуминг;
  • международные маршруты;
  • объём данных;
  • период отправки;
  • буферизацию.

Для перевозок Россия + СНГ стоит отдельно проверить:

  • работу SIM за пределами РФ;
  • тариф;
  • роуминг;
  • APN;
  • ограничения операторов.

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

24. Требования к хранению данных

ТЗ должно отвечать на вопросы:

  • сколько хранится история;
  • какие сообщения доступны;
  • можно ли получить данные за требуемый период;
  • как происходит экспорт;
  • какие ограничения действуют.

Потребность зависит от процессов компании.

Для операционного контроля могут быть нужны месяцы.

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

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

25. Требования к монтажу

Монтаж необходимо описывать отдельно.

Общие требования

Оборудование должно:

  • надёжно крепиться;
  • не мешать эксплуатации;
  • иметь защищённую проводку;
  • не создавать рисков для штатной электроники;
  • соответствовать условиям эксплуатации.

После установки исполнитель должен:

  • проверить питание;
  • проверить связь;
  • проверить GPS/ГЛОНАСС;
  • проверить входы;
  • проверить датчики;
  • проверить CAN;
  • подтвердить передачу данных.

Для ДУТ дополнительно:

монтаж → тарировка → проверка показаний.

26. Что должно остаться после монтажа

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

Минимальный комплект:

  • список автомобилей;
  • установленное оборудование;
  • серийные номера;
  • SIM;
  • подключённые датчики;
  • схема подключения — при необходимости;
  • таблицы тарировки;
  • дата установки;
  • исполнитель;
  • результаты тестирования.

Это особенно важно через несколько лет, когда оборудование потребуется обслуживать.

27. Техническая поддержка и SLA

Этот раздел необходимо согласовать заранее.

Следует определить:

  • канал обращения;
  • время работы поддержки;
  • категории инцидентов;
  • сроки реакции;
  • сроки устранения;
  • порядок эскалации.

Не надо копировать чужое SLA.

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

Возможная классификация

P1 — критический

Система недоступна для большинства пользователей.

P2 — высокий

Не работает важная функция или группа объектов.

P3 — стандартный

Ошибка отдельного объекта.

P4 — консультация

Настройка или вопрос пользователя.

Конкретные сроки стороны устанавливают договором.

28. Требования к информационной безопасности

Для корпоративного проекта стоит определить:

  • пользователей;
  • роли;
  • парольную политику;
  • разграничение доступа;
  • журналирование;
  • порядок блокировки сотрудников;
  • интеграционные учётные данные.

Особенно важно:

сотрудник должен иметь доступ только к тем объектам и функциям, которые необходимы ему по роли.

29. Миграция с другой системы мониторинга

Если компания уже использует другую платформу, этот раздел нельзя забывать.

Необходимо определить, что переносится:

  • объекты;
  • названия;
  • группы;
  • датчики;
  • геозоны;
  • пользователи;
  • водители;
  • прицепы;
  • настройки.

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

Нужно заранее определить:

Требуется ли перенос истории или достаточно начать накопление новых данных после перехода?

Не все системы позволяют перенести историю одинаково.

30. Пилотный проект

Для крупного автопарка ТЗ должно предусматривать пилот.

Не надо начинать сразу со 100–500 автомобилей.

Выбирается небольшая, но репрезентативная группа.

Например:

  • тягач с одним баком;
  • тягач с двумя баками;
  • автомобиль с CAN/FMS;
  • рефрижератор;
  • тягач + полуприцеп.

Существующее руководство AXENTA также рекомендует перед масштабированием тестировать ключевые функции на ограниченной группе автомобилей.

31. Матрица тестирования пилота

Вот здесь техническое задание становится особенно сильным.

Не просто:

Проверить работу.

А:

№

Сценарий

Ожидаемый результат

1

Автомобиль движется

строится корректный трек

2

Автомобиль остановился

определяется стоянка

3

Въезд в геозону

создаётся событие

4

Потеря GSM

данные сохраняются

5

GSM восстановлен

буфер передаётся

6

Заправка

событие отражается

7

Изменение CAN

параметр приходит

8

Два бака

видны оба уровня

9

Переток

общий баланс корректен

10

Отцепка

прицеп остаётся виден

11

Температура выше нормы

формируется уведомление

12

Превышение скорости

фиксируется событие

После прохождения тестов пилот можно принимать.

32. Критерии приёмки системы

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

Нельзя принимать проект только по факту:

оборудование установлено.

Нужно принимать работающий бизнес-сценарий.

Например:

Навигация

✓ координаты поступают;

✓ трек строится;

✓ стоянки определяются.

CAN

✓ согласованные параметры поступают;

✓ значения отображаются корректно.

ДУТ

✓ датчик настроен;

✓ тарировка выполнена;

✓ уровень отображается;

✓ тестовая заправка определяется.

Связь

✓ при потере GSM данные сохраняются;

✓ после восстановления сети передаются.

Геозоны

✓ тестовый въезд фиксируется;

✓ тестовый выезд фиксируется.

Уведомления

✓ тестовое событие доставляется нужному пользователю.

Отчёты

✓ согласованные показатели присутствуют.

Только после этого система считается принятой.

33. Что включить в итоговый акт

Для каждого автомобиля желательно подтвердить:

Проверка

Результат

Терминал установлен

Да

GPS/ГЛОНАСС

Да

GSM

Да

CAN

Да / нет

ДУТ 1

Да / нет

ДУТ 2

Да / нет

Тарировка

выполнена

Температура

Да / нет

Дверь

Да / нет

Водитель

Да / нет

Полуприцеп

Да / нет

Объект создан

Да

Данные проверены

Да

Это значительно лучше акта:

Выполнены монтажные работы — 50 шт.

34. Кто должен участвовать в подготовке ТЗ

Техническое задание не должен писать только IT-специалист.

Потребности формируют разные подразделения.

Участник

За что отвечает

Руководитель

бизнес-цели

Логист

рейсы и простои

Диспетчер

оперативные сценарии

Механик

CAN и технические данные

Специалист по ГСМ

ДУТ и топливо

Безопасность

тревожные события

IT

API и интеграции

Интегратор

техническая реализация

Тогда ТЗ описывает бизнес целиком.

35. Минимальная версия ТЗ

Если проект небольшой, документ необязательно делать на 100 страниц.

Минимальный вариант может выглядеть следующим образом.

1. Объект

20 магистральных тягачей.

2. Цель

Контроль маршрутов, топлива и простоев.

3. Необходимые данные

GPS/ГЛОНАСС, пробег, CAN/FMS, уровень топлива.

4. Оборудование

GPS/ГЛОНАСС-терминал + CAN + ДУТ.

5. ПО

Карта, треки, отчёты, геозоны, уведомления.

6. События

Заправка, возможный слив, превышение скорости, длительная стоянка.

7. Связь

Буферизация при отсутствии GSM.

8. Отчёты

Пробег, расход, топливо, стоянки.

9. Приёмка

Проверка каждого согласованного сценария.

Даже такое ТЗ значительно лучше фразы:

Нужно поставить ГЛОНАСС на 20 машин.

36. Расширенный пример ТЗ для грузового автопарка

Рассмотрим условный проект:

50 тягачей + 65 полуприцепов.

Основные задачи:

  • GPS/ГЛОНАСС-мониторинг;
  • контроль топлива;
  • CAN/FMS;
  • контроль полуприцепов;
  • геозоны;
  • простои;
  • отчётность.

Требование 1. Тягач

Каждый тягач должен отображаться отдельным объектом.

Получаемые данные:

  • координаты;
  • скорость;
  • пробег;
  • трек;
  • стоянки.

Требование 2. CAN/FMS

Необходимо получать:

  • пробег;
  • моточасы;
  • обороты;
  • расход топлива;
  • температуру двигателя.

Требование 3. Топливо

На тягачах с одним баком:

1 ДУТ.

На тягачах с двумя баками:

2 ДУТ.

Необходимо:

  • тарировать баки;
  • отображать каждый уровень;
  • рассчитывать общий остаток.

Требование 4. Полуприцепы

Каждый полуприцеп должен контролироваться независимо.

После расцепки:

тягач продолжает движение, полуприцеп остаётся видимым в системе.

Требование 5. GSM

При потере мобильной связи терминал сохраняет сообщения.

После восстановления:

данные передаются автоматически.

Требование 6. Геозоны

Создаются:

  • база;
  • склады;
  • клиенты;
  • сервис.

Требование 7. Отчёты

Обязательные отчёты:

  • пробег;
  • стоянки;
  • топливо;
  • заправки;
  • CAN;
  • посещение геозон.

Требование 8. Уведомления

  • длительный простой;
  • отклонение;
  • возможный слив;
  • потеря связи.

Требование 9. Приёмка

Проект считается выполненным только после прохождения тестовой матрицы.

Именно такой документ уже можно использовать как основу для запроса коммерческих предложений.

37. Типичные ошибки при составлении ТЗ

Ошибка №1. Описывать оборудование вместо результата

Плохо:

100 GPS-трекеров.

Хорошо:

100 автомобилей должны передавать координаты, пробег, события движения и согласованные параметры.

Ошибка №2. «Нужен контроль топлива»

Не указано:

  • источник;
  • количество баков;
  • заправки;
  • сливы;
  • точность;
  • тарировка.

Ошибка №3. Не описать два бака

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

Ошибка №4. Не включить полуприцепы

Компания контролирует тягачи, но большая часть активов остаётся невидимой.

Ошибка №5. Требовать «все CAN-параметры»

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

Нужно определить обязательный перечень.

Ошибка №6. Не описать GSM

На трассе пропадает связь, а заказчик думает, что перестал работать GPS.

Ошибка №7. Не определить уведомления

Система либо ничего не сообщает, либо отправляет сотни бесполезных сообщений.

Ошибка №8. Не прописать критерии приёмки

Исполнитель считает результатом факт монтажа.

Заказчик — рабочую аналитику.

Возникает конфликт.

Главный вывод

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

В хорошем ТЗ определены:

объекты → данные → источники → оборудование → программная платформа → события → пользователи → отчёты → интеграции → тестирование → приёмка.

Для небольшого автопарка это может быть документ на несколько страниц.

Для парка из сотен тягачей, полуприцепов и рефрижераторов — полноценная спецификация с таблицами оборудования, интерфейсами, тестовыми сценариями и SLA.

Если требуется внедрить GPS/ГЛОНАСС-мониторинг грузового транспорта, техническое задание лучше подготовить ещё до выбора окончательной комплектации оборудования.

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

FAQ

Кто должен составлять техническое задание на мониторинг транспорта?

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

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

Не обязательно. Часто лучше сначала указать функциональные требования и интерфейсы, которым устройство должно соответствовать.

Они работают как единая система. Хороший терминал с неудобной аналитикой так же малоэффективен, как хорошая платформа с некорректными исходными данными.

Если она критична для задачи — да. Но для большинства стандартных логистических сценариев важнее стабильность трека и корректная обработка событий.

Не писать «подключить CAN», а перечислить параметры, которые необходимо получать.

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

Да, если их необходимо контролировать после расцепки.

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

Не по количеству установленных устройств, а по матрице тестов: координаты, трек, CAN, ДУТ, геозоны, связь, уведомления и отчёты.

← Все публикацииВернуться к началу ↑

Новые публикации — в удобном вам канале

Подписывайтесь на AXENTA в Telegram и MAX.

Telegram ↗MAX ↗
Все публикации →

Обновление приложения AXENTA: версия 1.14.0 для iOS и Android

Читать статью ↗
Обновление AXENTA

Обновление системы AXENTA от 15.10.2026

Читать статью ↗

Вебинар AXENTA AI APPS. Презентация нового продукта

Читать статью ↗
Наверх