7 лет на рынке контроля транспорта или как мы видим контроль транспорта глазами клиента

В данной статье хочу отразить основные нюансы систем контроля транспорта, так сказать "изнутри" пользования системой. Я пишу эту статью как один из разработчиков и как обычный пользователь системы. К сожалению, все, что обычно отражается в рекламных буклетах, на деле оказывается не самым важным при использовании подобных комплексов. Посмотрите тендерные заявки на закупку или рекламные материалы разработчиков систем спутникового контроля транспорта. В основном весь упор делается на количество входов и выходов, количество памяти в терминале, количество подключаемых карт и т.д. Наш терминал поддерживает порядка 20 датчиков одновременно и более 30 вариантов картографической информации, но неужели потребитель выбирает из этих показателей? По нашей статистике более 97% клиентов используют максимум 3 входа и пользуются 2-3 картами из доступного списка. Раз уж коснулся памяти в терминале, то скажу, что в первых наших блоках стояло всего лишь 64 кБ памяти, вместо 2-4Мб в новых, также у нас были решения с SD картами до 16Гб, но отказались из-за низкой надежности. Так вот 64кБ хватало всего на 200 км пути, но этого было достаточно для контроля транспорта без потерь практически на всей территории России. Мы даже специально добавили в систему отчет "о статусе", в котором можно посмотреть потери сотовой и спутниковой связи в процентах. Так вот, в черте города этот показатель всего 0,8-1,2% для межгорода менее 3%. Да, буферная память обязательна в системах контроля транспорта, но стоит ли делать на этом такой акцент?

Лично на моей машине стоит система контроля транспорта, я ее использую для контроля своей езды по делам фирмы и контролирую заправки для домашнего учета расходов на топливо, также у меня есть несколько подчиненных, чье перемещение по работе также приходится контролировать , и, самое главное, мы с другом купили подержанный грузовик Iveco, наняли водителя, вполне адекватного человека, но контроль просто обязателен, в основном для логистики, безопасности транспорта и груза, ну, и контроль "левых" рейсов, скоростного режима и учет топлива никто не отменял:)

Выбирая систему контроля транспорта, я бы обратил внимание на следующие моменты:

1. Скорость работы системы.

2. Функциональность.

3. Периферийное оборудование.

4. Качество данных.

5. Надежность системы.

6. Абонентская плата, Ежемесячное обслуживание и т.д.

Скорость работы системы

1. Режим online. Казалось бы, сейчас практически все системы работают в онлайн режиме. На самом деле скорость работы различных систем может отличаться в десятки раз.
   Причины возникновения задержек:

• Сотовый оператор. Задержки передачи данных от ГЛОНАСС/GPS автотрекера до сервера в среднем 2-3 секунды. Решить данную проблему практически не возможно.
• Задержка при запуске диспетчерского ПО. Данная задержка может длится от нескольких секунд до нескольких часов(!) на некоторых системах контроля транспорта. Причина такого разброса - различная идеология построения систем мониторинга транспорта.

Различные архитектуры клиент-серверного приложения:

1. На каждом диспетчерском компьютере хранятся все принятые данные от каждого автомобиля. При такой архитектуре при каждом запуске программы все данные, которые еще не получил диспетчер с предыдущего запуска программы, передаются ему на диспетчерское ПО от сервера. Отсюда очень низкая скорость запуска программы и огромный трафик передаваемой информации. Достоинством подобных схем является очень простая реализация серверного ПО и низкая его загруженность, что позволяет использовать в качестве серверной базы даже виртуальные сервера(VPS). Все остальное, к сожалению, недостатки.

2. При запуске диспетчерского ПО с сервера передаются только текущие данные по машинам. В данном случае запуск системы с подключением в 100-200 машин занимает не более 10 секунд. Данные по пройденным маршрутам передаются на диспетчерское ПО только по запросу от диспетчера и кэшируются там для возможности повторного использования. Отчеты же в данной архитектуре формируются на сервере, что позволяет передавать минимальные объемы данных по интернету и формировать отчеты с высокой скоростью при использовании производительных серверов. Идеальным вариантом, по нашему мнению, являются запросы маршрутов и отчетов в отдельных потоках, и их открытие в отдельных окнах или закладках, что позволяет получать онлайн данные во время фонового формирования отчетов и маршрутов.

 Есть такое понятие как "время реакции системы" на запросы оператора системы контроля транспорта. При перемещении карты, выборе объекта на экране, запросе отчетов и маршрутов движения существует максимальное время реакции системы, при превышении которого оператор начинает испытывать психологический дискомфорт, работая с программой. Обычно это время не превышает 2-3 секунд. Представьте, вы переместили карту и ожидаете обновления экрана 10-20 секунд, думаю удобной такую программу Вы не назовете. Эти проблемы можно решить разными методами. Например, для увеличения скорости обновления карт необходимо кэшировать интернет карты на локальном компьютере, а при низкой скорости интернет соединения переходить на отрисовку векторных карт из локальной базы данных. Мы используем для этих целей собственный картографический движок, работающий по международному стандарту OpenGIS, а для пользователей карт CityGuide предусмотрена возможность переключения на картографический движок CityGuide.

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

Почему бывают "тяжелые" данные и как их облегчить? Нужно понимать, что все данные, поступающие от терминалов обычно хранятся в СУБД и архитектура и выбранная платформа для построения структуры базы данных может существенно повлиять на скорость обработки данных. Из анализа данных по контролю транспорта за 7 лет мы выяснили, что 96% запросов клиентов затрагивают данные только последних 35 дней, а 72% запросов только последних 2-х дней. Исходя из этих данных, мы построили логику СУБД таким образом, что все таблицы в автоматическом режиме разбиваются по месячным партициям, а данные за последние 4 дня постоянно хранятся в оперативной памяти сервера. Что это дает? Вы наверняка замечали в рекламных буклетах многих компаний ограничение по хранению данных системы контроля транспорта до 3-х, 6-и месяцев и т.д. Это связано с тем, что без необходимой оптимизации и идеологии построения структуры СУБД при увеличении объема данных в системе контроля транспорта уменьшается скорость выборки из нее. Таким образом запрос, например, маршрута за одну неделю с каждым месяцем будет выполняться все медленнее и медленнее. При использовании подхода, реализованного в системе контроля транспорта "Сириус Навигатор", скорость выборки не зависит от объема данных в системе и является практически постоянной величиной.

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

• группировка транспортных средств;
• отображение отдельных групп транспортных средств в отдельных окнах, закладках или экранах; нанесение собственных объектов на карты. Для нанесения своих территорий, баз, места стоянки, территорий клиентов и т.д. Очень удобно, когда в онлайн режиме Вы видите в табличном виде сколько машин и какие именно машины стоят на конкретной базе, без необходимости поиска на карте;
• При просмотре маршрута движения транспортного средства за заданный период очень информативно наложение графиков топлива, температуры или работы исполнительных механизмов на трек с возможностью интерактивного перемещения по нажатию кнопкой мыши;
• Отчеты. Ценность всей системы для использования на предприятии очень часто зависит именно от информативности отчетов. При использовании от 5 машин и более любой контроль необходимо начинать с отчетов. Правильно разработанные отчеты могут моментально предоставить Вам информацию где и когда была конкретная машина, сколько проработала за сутки, сколько времени в движении, сколько на холостом ходу, каково пройденное расстояние за сутки, неделю или месяц, сколько топлива израсходовала. Также отчеты могут предоставить Вам информации о превышении скорости и режиме работы водителя. Если Вы хотите мотивировать работу водителя в ночное время, отчеты могут предоставить информацию сколько времени он проработал днем, а сколько ночью. Помните, в некоторых системах контроля транспорта отчеты могут быть отдельным модулем и стоить отдельных денег.
• Многие используют систему контроля транспорта без установки датчиков топлива, а расход топлива списывают по нормативам. Во многих программах реализован расчет нормативного расхода топлива по пробегу, но не все учитывают в расчетах коэффициенты рекомендованные минтрансом. Программа должна учитывать зимние надбавки по регионам, коэффициенты при езде в городе в зависимости от населения, износ автомобиля по годам выпуска, высоту над уровнем моря, езда по трассе и т.д. Клиент, естественно должен иметь возможность приводить эти коэффициенты к утвержденным в его компании.
• Возможность интеграции с другими системами, например 1С;
• Наличие возможности выгрузки данных федеральному оператору НИС-ГЛОНАСС.

Периферийное оборудование

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

Надежность системы

Система спутникового контроля транспорта состоит из трех частей:

• бортовой навигационный терминал;
• серверный программно-аппаратный комплекс;
• диспетчерский программно-аппаратный комплекс;

Надежность всего комплекса зависит от надежности каждого узла. Рассмотрим каждый из них отдельно:

Бортовой навигационный терминал

• Надежность терминала зависит от качества пайки. При визуальном осмотре всегда можно отличить заводской автомонтаж от ручной пайки. Handmade, к сожалению, надежности не прибавляет, а все дело в миниатюризации электронных компонентов и сложности их ручного монтажа. Встречаются же приборы ручной пайки и корпуса "доработанные напильником" достаточно часто, как не странно. Еще более странно при этом слышать слова менеджера о первом месте на рынке и использовании технологий NASA в своих приборах:) Перед покупкой осмотрите товар внешне и попросите вскрыть и посмотрите на качество изготовления платы внутри.
• С данным пунктом не согласятся многие производители систем контроля транспорта, но я его озвучу, пусть будет мое субъективное мнение. Я глубоко убежден что одноплатные терминалы надежнее многоплатных. Не будем забывать что терминал работает в условия с повышенной вибрацией и все эти переходные разъемы между платами вряд ли идут ему на пользу.
• Конечно, на надежность сильно влияет используемая элементная база, источники питания, защитные элементы на входах и выходах, но, к сожалению, неискушенному пользователю вряд ли получится дать какие-то советы в рамках такой обзорной статьи.
• И последнее, качество самого монтажа на объекте играет важную роль в надежности работы системы контроля транспорта. Конечно определить на взгляд хорошего монтажника, знающего электрику автомобиля, сложно. Но стоит помнить что современные автомобили очень сложные устройства, и врезаться в электрику где попало нельзя, провода, которые кажутся источниками питания (для запитки терминала, например), могут на деле оказаться информационными, при просадке которых могут неадекватно срабатывать различные системы автомобиля. Наличие у монтажника переносного осциллографа (благо они сейчас бывают миниатюрные на аккумуляторах) и умение им пользоваться очень хороший тон.

Серверный программно-аппаратный комплекс

Меня всегда удивляло почему представители клиентов (даже системные администраторы) никогда не спрашивают что у нас за сервера, где они расположены и как мы обеспечиваем бесперебойность работы системы контроля транспорта. Ведь сервер за 15 тысяч рублей, на базе обычного компьютера, стоящий под столом у менеджера новоиспеченной компании посредника (а такое я реально видел в Ростове-на-Дону) и специализированный сервер стоимостью от 600 тысяч рублей и выше, установленный в дата-центре с подключением к высокоскоростному интернету, поддержанием температурного режима и бесперебойным питанием это все-таки разные вещи. Один из наших новых клиентов, вспоминая про свой предыдущий опыт установки системы контроля транспорта (название системы контроля транспорта называть не буду т.к., многое зависит не от разработчика, а от конкретного интегратора), рассказывал что летом система часто была не работоспособна и на вопросы интегратор ответил: "а что Вы хотите, такая жара на улице, сервер плавится". В общем и смех и грех.

Если же вы планируете приобретать серверное ПО и использовать систему контроля транспорта без абонентской платы, то необходимо учитывать под какие операционные системы и СУБД она написана. Обычно стоимость этих программных продуктов не указывается в прайсе т.к. это программные продукты сторонних разработчиков. Но без них Вы, естественно, не запустите систему контроля транспорта. Например, при использовании как платформы Microsoft Windows Server c СУБД Oracle Вам возможно придется за "вспомогательное ПО" выложить больше чем за всю систему контроля транспорта. Поэтому просите выставлять цену "под ключ".

Абонентская плата, Ежемесячное обслуживание и т.д.

Абонентская плата - самое ненавистное слово для потенциального клиента. Поэтому многие интеграторы систем контроля транспорта предпочитают использовать другие формулировки: ежемесячное или годовое обслуживание, тех поддержка, тариф "X" и т.д. Есть совсем нечестные способы, когда про абонентскую плату Вы узнаете уже после установки системы, например через год, и слезть с нее уже не просто, т.к. оборудование уже проплачено. Если же Вы используете свои СИМ карты, обязательно просматривайте детализацию, т.к. некоторые "махинаторы" используют для скрытой оплаты своих услуг отправку СМС на короткие номера с автотрекера.

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

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

Теперь про "аутсорсинг". Перед тем как соглашаться на абонентскую плату Вам необходимо выяснить, что в эти деньги включает интегратор.

Выясните:

• Кто платит за СИМ карты.
• Есть ли отдельная оплата за пользование диспетчерским ПО, за запросы отчетов и маршрутов.
• Оказывается техническая поддержка по телефону, емайл и т.д.
• Выезд при неисправности системы на конкретном транспортном средстве. Если нет саботажа со стороны водителя, исправлять проблему должен интегратор за свой счет. Это подстегивает интегратора к качественному монтажу, и, как следствие, клиент получает более надежную систему.

Наши клиенты не платят абонентскую плату за транспортные средства (кроме спец техники) при пробеге менее 100км в месяц. Думаю это честно - техника не используется, Вы на нем не зарабатываете, Вы за нее не платите.

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

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

Андрей Владимирович.