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

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

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

Сначала немного об общем


Первая и основная функция — отслеживание через GPS. Видно, где грузовик проезжал, можно определить, где он терял позицию, и где её снова находил, практически в реальном времени.

Если соединения с сервером нет, трек записывается в память бортового компьютера. При отсутствии приёма GPS возможен косвенный мониторинг через позиции вышек GSM. В своё время у нас было партнёрство с OpenCellId — открытым банком данных местоположения базовых станций GSM (подробнее об этом писалось тут), куда я каждую неделю заливал около миллиона координат, но к сожалению партнёрство закрылось, когда OpenCellId был продан индийской фирме, которая превратила сервис в платный даже для содействующих — а ведь одна наша система давала примерно четверть всех координат, которые они получали.

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

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

Дальше идёт мониторинг FMS и различных сенсоров. Современные грузовики имеют довольно сложную цифровую систему управления мотором, и чтобы облегчить сбор информации для вот таких вот бортовых компьютеров, семь европейских производителей грузовых машин вместе создали формат FMS (Fleet Management System), стандартизированный интерфейс для подключения (только для чтения) к системе управления мотором через CAN-Bus, в котором в реальном времени присутствуют основные параметры грузовика, такие как скорость, километраж, расxод горючего в определённом стандартном формате.

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

Кроме этого, приходит некоторая часть информации из цифрового тахографа — обязательного в Европейском союзе прибора, который фиксирует рабочие периоды водителей и скоростной режим транспортного средства. Таким образом без подключения к тахографу напрямую можно узнать, когда какой-то конкретный водитель сел за руль или закончил работу. Различные сенсоры — это, как правило, цифровые входы, таким образом можно проверять, что где включено (фары, ремень безопасности итд). Элементарный пример для такого рода сенсоров — бортовой компьютер следит за ручным тормозом, и только если тормоз включен, перестаёт блокировать телефон — многие компании, которые перевозят опасные грузы, запрещают водителям разговаривать по телефону во время езды.

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

Приём и посылка СМС тоже есть, из-за чего иногда приходится выслушиватъ жалобы водителей, часто находившихся рядом с границей — постоянно приходят сообщения о тарифах, что приводило к дилемме — без дополнительного чёрного списка можно только отключить приём СМС полностью (просто удаляя таблицу СМС из банка данных), но тогда сообщения вообще приходить не будут.

Есть ещё одна полезная функция, связанная с использованием GSM-модема — при поступлении сигнала с регистратора данных об аварии (EDR — Event Data Recorder) бортовой компьютер может автоматически набирать определённый номер телефона.

А теперь немного о различиях


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

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

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

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

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


Проверка весов

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

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

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

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

Дальше идёт мониторинг тех самых действий, которых может быть очень много. Раскрыты створки системы слива цистерны, слив жидкости из цистерны, открытый ремень безопасности, да даже остановка дольше 5 минут. Мониторинг системы слива чаще всего и ловит водителей, которые хотят поживиться за чужой счёт: несколько дней вподряд приходят оповещения, что сливается горючее вне геозоны. Трек показывает, что водитель в том месте, где он проводил сливы, вообще не должен был находиться. На следующий день там его ждала полиция.

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

Об используемой технике



Aplicom F-Series

Когда я начинал свою работу с транспортной телематикой в 2003 году, на рынке практически не было подходящих сравнительно универсальных приборов, под которые можно было бы писать свои программы. Выбор в то время, по большему счёту, ограничивался Aplicom C series/F series и Owasys Owa2x.

Первый прибор был сделан выходцами из Nokia, работал на их собственной операционной системе (OS95A), которая являлась вариантом ОС для старых нокиевских телефонов, ещё тех, у которых были две строчки текстового экрана. Разработка велась на C99 компилятором CodeWarrior ARM, и была довольно неудобной и из-за устаревшего компилятора, и из-за довольно примитивной операционной системы, которая фактически компилировалась вместе с программой, которую я писал под прибор.

Второй прибор был сделан выходцами из испанского филиала Ericsson, имел чуть более быстрый процессор, но на один порт RS232 меньше и работал под довольно древним Линуксом. Разработка велась таким же древним GCC (2.95.3) со всеми вытекающими из этого последствиями (багами, нерабочими функциями языка, откровенно отстойной поддержки C++ и плохой оптимизацией кода).

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

С другой стороны, у Owa2x было одно большое достоинство — Линукс — и огромное количество недостатков — всего два порта RS232, что затрудняло даже элементарный дебаггинг через консоль, баганутый контроллер CAN-Bus, который регулярно зависал, использование одного внутреннего RS232-порта и для GPS и для GSM при помощи мультиплексора, из-за чего GPS зависал, когда GSM стартовал или останавливался, файловая система, которая распаковывалась в RAM-диск при каждом старте, из-за чего было невозможно перманентно заменить какой-нибудь системный файл, и, на десерт, документация, у которой польза была ниже, чем у туалетной бумаги.

Когда я посетил офис производителя и показал им все эти проблемы (которые в последствии так и не решили, просто сказав, что они сейчас делают новое железо — Owa3x, в котором всё будет лучше), я им оставил апликомовскую документацию, чтобы брали пример (пример начали брать примерно через 6 лет, когда уже делали следущее поколение — Owa4x).


Перепрошивка Owa2x

Когда вышел Owa3x, в первое время я был очень рад. Там был более новый компилятор (GCC 4.3), быстрый процессор, три порта RS232, и, наконец-то, слот для карточек MicroSD. Теперь можно было ставить программу на карточку, чтобы в последствии, если что, её можно было бы просто заменить. Однако радовался я рано.

Ошибки архитектуры, типа распаковывающейся файловой системы и тот же мультиплексор для GPS и GSM остались, причём первая ошибка стала более серьёзной — прошивки стали намного больше размером, а модем так и дальше поддерживал только GPRS, версия с поддержкой UMTS стоила намного дороже, и это в 2011 году.

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

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


Owa3x

Два года назад я решил сделатъ серьёзный рефакторинг и переписать часть программы, потому-что до этого она просто бессистемно обрастала всякими функциями. Заодно решил избавиться от зависимости от boost, которые сильно раздували и иcxодник и бинарник, и стандартизировать подход к решению задач, а то часто использовалась то функция boost, то функция c++, то вообще классика из C для достижения одного и того-же эффекта.

От boost легче всего было избавиться, переписав программу под C++11, который заодно и упростит многое другое — чего стоит один только range based for вместо километровых итераторов.

Как выяснилось, поддержка C++11 под GCC 4.3 абсолютно кривая, даже минимальные программы с использованием STL не компилировались. От производителя был официальный ответ, что другой компилятор на данном железе не поддерживается, но неофициально работает 4.7.3, если загрузить соответствующий libstdc++, что более-менее работало, но было нереальным.

Тут уже пришлось скрестить ужа с ежом — я взял GCC 4.8.3 (4.9 уже не получилось бы, там что-то поменяли в ABI), засунул в него libstdc++ от моего GCC 4.3 и копировал поочерёдно системные include-файлы, в которых находились ошибки, оттуда-же до тех пор, пока не стало компилироваться. Как ни странно, вся эта конструкция заработала, причём неплохо.

Получившуюся смесь библиотек и include-ов некоторое время возможно даже было использовать в clang, но бинарники получались неоптимальными и ошибок было больше — clang иногда компилировал вызовы каких-то функций, которых в старой библиотеке просто не было, но, по крайней мере, таким образом нашлись стилистические ошибки, которые GCC прощал.

Байки у костра


  • Когда я начинал работать в этой сфере, я был абсолютно зелёным студентом-практикантом. Фирма, в которую я устроился работать, только что продала то, что было, по большему счёту, PowerPoint-презентацией, и меня сразу направили на это дело.

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

    Программировать на C я тогда не умел вообще, до этого писал только досовские программки на Turbo Pascal, в основном для фидовских бибиэсок. Язык C меня жутко поразил — это же сколько возможностей выстрелить себе в ногу!

    Через некоторое время дело пошло, и программа, хоть и была написана сильно криво, заработала, но я безбожно опаздывал. В тот момент мне повезло, что как раз в это время вводилась новая немецкая система оплаты дорог, которая по большему счёту тоже такой-же мониторинг транспорта, и её разработчик TollCollect тоже очень сильно опаздывал, став при этом посмешищем всей страны. На этом фоне клиенты приняли наше опоздание на несколько месяцев с пониманием.
  • Представьте себе, что бортовой компьютер умер во время обновления программы, которую он скачал через мобильную связь. Что-то совсем не получилось, компьютер перестал загружаться. Делать нечего, придётся ехать к грузовику, ставить на него обновление вручную через серийный порт.
  • Представительница клиента отвезла меня к базе, где стоял грузовик, от которого у неё были ключи. Но, как оказалось, ключей от внутренних дверей базы у неё не было, а время было уже вечернее, все ушли домой. Она вытянула из стопки бумаг несколько скрепок и попыталась взломать замок, пока я стоял на шухере. В конце концов ничего не получилось, и пришлось одного из водителей вызывать на базу, но попытка была однозначно засчитана.
  • Как-то раз сервер, который принимал данные с бортовых компьютеров, перестал работать на несколько часов. Когда коллеги всё восстановили, и сервер снова заработал, жалобы на работу бортовых компьютеров не переставали приходить — клиенты не видели, где находятся грузовики, не видели, пришли ли на экраны у водителей новые данные. Как оказалось, всё работало как надо, просто за те несколько часов мои приборы набрали кучу данных, и чтобы послатъ все эти данные на сервер, понадобилось достаточно много времени, а по принципу FIFO данные на текущий момент были самыми последними в очереди.
  • Клиент из одного из арабских эмиратов жаловался, что плохо работает система, но никаких конкретных примеров не называл. Когда мы с коллегами прибыли на место, то сильно удивились контрасту между привычными немецкими бензовозами и грузовиками, которые использовались там — Renault Kerax, которые обычно используются на стройках, с примитивными стальными цистернами сделаными в Саудовской Аравии.

    Грузовики выглядят так, как будто 20 лет работали на стройках, хотя им было два-три года от роду, и очень низкий километраж, ведь большую часть времени они простаивали, так как у каждого водителя был свой грузовик. Внутри нас ждали оборваные провода и шелуха от фисташек в принтерах.
  • В Румынии был реализован совместный проект с производителем цистерн и производителей системы измерения слива топлива. Через год у одного клиента постепенно перестали работать приборы, да и система измерения работала не слишком хорошо. В то же время клиент отказался предоставить грузовики, разъезжавшие по всей стране, из-за чего пришлось их догонять и прошивать вручную. За три дня я так повидал всю Румынию, от края до края, только Бухарест объехали вокруг.


Перепрошивка Owa3x в Ватра Дорней

Заключение


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

Да и разработка приложений на современных планшетах без сомнений намного удобнее. Однако полностью они не смогут заменить классическое оборудование транспортной телематики, так для сбора максимального количества информации необходимо большое количество портов ввода/вывода — от обычных серийных типа RS232, до специализированных типа CAN-Bus. Чтобы подключить всё это к обычному планшету на Андроиде, необходимо большое количество перефирии, либо неприлично дорогие малосерийные и узкоспециализированные планшеты, но даже у такого прибора есть один серьёзный недостаток — водитель его легко может выключить и при этом весь сбор информации прекратится.

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

Большое спасибо пользователю hdablin за поддержку и помощь в редакции статьи.

Комментарии (18)


  1. barbanel
    15.11.2017 13:24

    Простите что немного не в тему.
    Глядя на последнее фото, стало интересно: а сегодня устанавливает кто-либо камеры заднего вида на такие длинные прицепы?
    Upd. Спасибо за статью!


    1. dunkelfalke Автор
      15.11.2017 13:42
      +1

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


  1. x893
    15.11.2017 13:42

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


  1. dmitryrf
    15.11.2017 15:41

    Интересно, спасибо! С большим FIFO после перерыва связи коллеги тоже сталкивались. Теперь после восстановления канала сначала отправляется самый свежий пакет и только потом накопленный буфер.


  1. AndreyNikolin
    15.11.2017 17:16

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

    Не имеет ли смысла по умолчанию регулировать частоту сбора обратно пропорционально скорости? По идее как раз если машина находится на трассе, то сразу бы получались прямые отрезки между точками которых было бы достаточно на трассе, а при замедлении уже шёл бы более подробный трек (в случае съезда с трассы или даже при движении по городу).


    1. dunkelfalke Автор
      15.11.2017 17:27
      +1

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


  1. QDeathNick
    15.11.2017 18:06

    А вы где-то реализовали контроль скорости в реальном времени по геозонам?


    Какие по вашему подводные камни могут быть?


    1. dunkelfalke Автор
      15.11.2017 18:34

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

      1) Контроль по скорости необходимо делать через CAN-Bus, так как скорость от GPS не слишком точная и может сильно прыгать, особенно если приёмник старый. Если нет такой возможности, то будет очень много ложных срабатываний.

      2) Геозона для контроля скорости скорее всего будет намного более сложной, чем круг или квадрат. Я в своё время начал делать полигональные геозоны, но для них процессору считать больше, а все вычисления — выполнение этого алгоритма для каждой имеющейся геозоны — должны происходить в течении примерно двух секунд (время от получения одной координаты с GPS до получения следующей). На том железе, которое у меня есть, скорости процессора не хватало. На современном андроид-планшете с мощным процессором может и хватит, если геозон не слишком много.


      1. QDeathNick
        15.11.2017 21:13

        Спасибо.


        1) К сожалению у нас нет подключения к CAN-Bus. Будем усреднять данные GPS.
        2) Мы решили считать уже на сервере после получения данных.


      1. konst90
        16.11.2017 10:04

        2) Геозона для контроля скорости скорее всего будет намного более сложной, чем круг или квадрат. Я в своё время начал делать полигональные геозоны

        А нельзя ли «оптимизировать» полигональные геозоны в набор кругов/квадратов?
        Ведь грузовики ездят по дорогам, и как выглядит граница зоны на поле или в реке рядом с ней — неважно: главное, чтобы граница круга совпадала с границей сложной фигуры в каждой точке, где дорога входит в геозону. А для ряда кругов вроде бы считать проще — последовательно проверяем расстояние от центра каждого и сравниваем с радиусом.
        Показал на примере родного города: чёрные круги — центры условно тех точек, где разрешенные 60 превращаются в разрешенные 90. Красным — сложный полигон, в котором нам надо контролировать скорость, граница которого совпадает с границей города. Синим — круги, в которые входят все дороги полигона (города) и не входит ни одна загородная, а их границы совпадают с выездом из города.
        Картинка с кругами
        image


        1. foatto
          16.11.2017 11:16

          И вместо одной проверки вхождения в регион получаете множество (не сильно более «дешёвых») проверок вхождения в простые фигуры.
          И совсем весело станет проверять скоростной режим на участке дороги.

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


        1. huhen
          16.11.2017 11:55

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


        1. SandmanBrest
          16.11.2017 22:15

          В одной и той же геозоне может быть несколько ограничений скорости — это я как водитель говорю.


          Может быть трасса с ограничением 90 и рядом городская дорога с ограничением 60. А расстояние между ними 10 метров.


  1. begemot_sun
    15.11.2017 19:17

    Стоит ли входить в GPS-мониторинг как некий сервис собирающий данные онлайн и предоставляющий определенное API для разработчиков, ну и плюс веб и все остальное?
    или все места под солнцем уже заняты аля Wialon?
    А какая киллер-фича может быть востребована, которая не реализуется гигантами рынка? :)


    1. dunkelfalke Автор
      15.11.2017 19:37

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


      1. begemot_sun
        15.11.2017 22:21

        По моему разработчики логистики сами способны создать сервер, который принимает данные GPS (они же разработчики).Т.о. сотрудничества тут не получится. Есть много опенсурс решений, которые они могут взять и допилить. Меня больше интересует вопрос, где найти таких «прямых» клиентов, которые были бы заинтересованы в создании специфического мониторинга под себя. С учетом, конечно, того факта что система не будет им принадлежать, и за которую они будут платить на общих основаниях.


  1. PKav
    16.11.2017 12:43

    Эта статья напомнила мне мою первую работу — гос. контору, которую как раз только открыли для установки трекеров на автомобили спецслужб и прочее. Сам ставил трекеры, сам администрировал систему мониторинга. Что только ни делали водители с трекерами — и в воде топили, и 220 на вход подавали, и антены откручивали, и потом, когда был риск спалиться, не в той последовательности прикручивали… Веселое время было.

    Немного странно слышать от вас в комментарии, что скорость по GPS неточна. По спецификации на старых приемниках погрешность по скорости 0.4 км/ч, на новых 0.2 км/ч. Я даже сделал прибор гоночной GPS-телеметрии, которая собирает данные 10 раз в секунду чисто по GPS. Точность получилась на очень высоком уровне, гонщикам нравится.


    1. dunkelfalke Автор
      16.11.2017 12:52

      Ага, было дело. Клиент постоянно ругался, что ничего у него не работает месяцами. А когда наш представитель (бывший водила) приехал, чтобы сам посмотреть на грузовики, внезапно всё заработало.

      Насчёт неточной скорости от GPS — наверное это сильно зависит от приёмника и мне с теми, что были, очень не везло — часто большие прыжки (к примеру с 70 км/ч вдруг на 120 км/ч, хотя у грузовика аппаратно заперто всё, что выше 80 км/ч), приходилось делать фильтры.
      Самые большие проблемы были со старыми ublox TIM.