Как повысить эффективность внедрения навигацииОчень часто, читая описания от инвестиций во внедрение навигационного и связанного с ним оборудования (например Датчиков Уровня Топлива), можно встретить о замечательных эффектах от инвестиций, с указанием цифр экономии в 20-30% топлива, сокращении пробегов, низких сроках возврата инвестиций и тп. Давайте попробуем разобраться, в каких случаях достигаются данные результаты.
Данная информация может показаться "детской", и "само собой разумеющейся" (особенно для самих "внедренцев"), однако, как показывает опыт, даже на крупных предприятиях не всегда есть понимание того, как добиться оного результата, от чего он зависит. Данная статья направлена на то, что бы сократить расстояние в понимании ситуации между "внедренцами" и "фирмами".
Статья адресована руководству организаций.
Начнем с азов. С того, что такое управление чем-либо, из каких частей оно состоит? Будем сразу приводить примеры из области объектно-ориентированной телематики.
Любое управление состоит из следующих этапов (упрощенно):
1. Составление Модели какого-то процесса - это представление данного процесса в какой-либо упрощенной форме, когда нам важны определенные параметры (например, положение машины в пространстве, ее скорость), которые, обычно, могут быть выражены в количественно-цифровых показателях (скорость, координаты, уровень топлива в баке и тп). Модель не учитывает параметров для нее не важных (например, цвет машины для слежения за ней - не значимый параметр).
2. В соответствии с моделью собираются наблюдаемые параметры-данные - приходят данные о положении транспорта, его скорости, срабатывании датчиков, уровне топлива, его расходе и так далее.
3. Собранная информация анализируется - проверяем, что скорость не превышена, что машина находится на нужном участке маршрута, что данные о заправках соответствуют и так далее.
4. Если на основании анализа выявляются отклонения (превышена скорость, зафиксирован слив топлива, машина сделала "левый рейс" и т.п.) то далее на выбор: 4.1. Принимается управленческое решение - водителя за левый рейс наказать, или вычесть из зарплаты за слив топлива. 4.2. или Корректируется модель - модель не отвечает нашим требованиям (не установили датчики, данных не достаточно для принятия решения).
5. Повторяется все по кругу п.п. 2-5
Если любой из данных пунктов не выполняется, то эффекта от инвестиций в навигацию ждать не приходится, ибо цикл нарушен. Т.е. эффектность зависит не только от КАЧЕСТВА и КОЛИЧЕСТВА датчиков/оборудования, но и от ОРГАНИЗАЦИОННЫХ вопросов.
- Например - произвели инвестиции в датчики топлива, навигацию, но данные никто не анализирует (или предоставляет не достоверные данные) - эффекта не будет, или он будет не значительный....
- Или анализирует (например найден левый рейс), но никаких мер воздействия не предпринимается - эффекта не будет, или он будет не значительный...
- Или модель не достаточно точна, не имеет нужных параметров (например, ДУТ поставили, но не подключили датчики оборудования) - эффект будет значительно меньше.
Именно данные 5-ять пунктов, в случае их нарушения, дадут полное разрушение ВСЕЙ конструкции - это САМЫЕ важные части внедрения, ибо составляют "костяк" всех действий, их скелет (если сравнить с человеком - то как раз скелет, на котором держаться мышцы, кожа, и так далее). Самые "замечательные датчики" будут просто потраченными деньгами, если из данного "скелета" выпадет любой из пунктов!!!
Теперь рассмотрим каждый пункт более подробно.
МодельКак любая модель, и модель для объектно-ориентированной телематики имеет свою точность, "плюсы" и "минусы".
Какие параметры модели (какая модель) важны для объектно-ориентированной телематики? Упрощение чего и как будет достаточно для задачи?
Обычно оперируют такими параметрами: 0. Время - пожалуй, это самый важный параметр, потому что от него зависят все остальные! Точное время! Все данные должны быть "привязаны" к нему. Все алгоритмы учитывают время получения данных в своей работе! Время получается навигационным прибором от спутников. Оно нигде в терминале не "настраивается". Навигация не может работать не опираясь на точное время, поэтому в приемнике оно есть всегда.
1. Местоположение машины (в момент времени) - где находится транспорт (в каких координатах) в определенное время. Естественно, навигационный прибор имеет точность определения координат, в современных моделях для коммерческого использования она составляет примерно 10 кв.м (т.е. точность чуть меньше 3-ех метров на карте - сторону дороги вы определите, а вот о номере полосы движения уже будут трения). 2. Скорость транспорта (в момент времени) - мгновенная скорость ТС (большинство приборов не способно вывести именно скорость, и выдает этот параметр как отношение пройденного пути ко времени его прохождения, но обычно погрешность не составляет более 1 км/ч) 3. Направление движения (азимут) (в момент времени)- в какое направление движется ТС. Причем, не важно движется оно "вперед", или "назад" (для нашей модели). В большинстве приборов направление движения определяется навигационным маяком тоже только в моменты движения, от предыдущей точки к последней (примерно как со скоростью). Если ТС стоит, то показания берутся последние определенные в момент движения (сохраняются в памяти), или строго Север (азимут "нуль", если в памяти нет последнего значения).
Все указанны параметры являются БАЗОВЫМИ - это минимально возможный набор данных, которые должны выдавать абонентские терминалы в транспортных средствах (для слежения за персоналом из данного списка можно вычеркнуть одометр, ибо для персонала смысла он не несет).
Большинство абонентских терминалов имеют возможность подключения к ним различных датчиков (тревожных кнопок, герконов, ДУТ, измерение температуры, зажигания и тп) и/или каких-либо поставщиков данных (RFID метки, пассажиропоток, CAN-шина и т.п.). Все эти данные должны "транзитом" передаваться для обработки в навигационное ПО (обрабатывающее ПО). Эти данные так же интересны исключительно в привязке к координатам и времени.
Построение модели (определение параметров) исходит из того, для достижения какого именно эффекта мы хотим вводить управление - т.е. что мы хотим добиться в результате. Перед объектно-ориентированной телематикой обычно ставятся следующие задачи:
1. Контроль положения транспорта - точно знать где и когда находится машина. и подзадачи: 1.1. Контроль левых рейсов - что водитель не гоняет машины на "лево" для себя. 1.2. Контроль выполнения маршрутных заданий на работу - что машина вовремя (по плану) подается клиенту, что вовремя доставляется груз 1.3. Контроль за маршрутом следования ТС - что ТС не отклоняется от заранее заданного маршрута, что ТС останавливается только в обозначенных для этого местах. 1.4. Контроль за скоростью - что скорость не превышает установленного предела в 80 км/час. Актуально, в основном, для машин с опасными грузами. 1.5. Контроль выхода-входа в зону - так называемый "охранный режим", что ТС не покидает стоянку ранее, например, чем 06:00
2. Контроль работы узлов (узлов и механизмов) и подзадачи: 2.1. Когда, где и какой датчик сработал - поднялась стрела, подъем кузова, опустился нож, включилась поливалка, открылась дверь, зашел человек, включилось зажигание и так далее. 2.2. Учет количества оборотов - бетономешалки, крутящиеся агрегаты.
3. Контроль топливной системы - учет топлива: 3.2. Учет расхода топлива 3.2.1. Сравнение расхода топлива с нормами 3.2.2. Поиск "сливов" топлива - в общем случае - сверхнормативного расхода топлива.
4. Учет различных датчиков, выдающих "аналоговые значения"4.1. Температура 4.2. Штатные уровни топлива (да и просто датчики уровня топлива с аналоговыми выходами) 4.3. Напряжение бортсети и т.п.
Так же важным моментом является наличие сертификатов на абонентские терминалы как на средство измерения, соответствия госта-м (помехозащищенность, электрозащищенность) и так далее. Это вам потребуется в случае, если будут трения с водителями, доходящие до судов. Так же не стоит забывать, что к определенным типам ТС могут применяться специализированные требования (взрывоопасность, влагозащита, помехозащищенность, использование ГЛОНАСС оборудования и т.д. и т.п.). В случае, если ТС находятся на гарантии так же не помешают сертификаты соответствия ГОСТ для электрического оборудования устанавливаемого на транспорте.
Как видим из наших задач, нам ВСЕГДА интересны данные о положении машины во времени и пространстве! т.е. задача Контроль положения транспорта является БАЗОВОЙ. Без нее все прочие задачи (в большинстве своем) не имеют какого-либо большого значения для объектно-ориентированной телематики.
Действительно, что вам даст датчик подъема кузова, если навигационный маяк не способен определить где он находится? Или график расхода топлива, если мы не можем определить какой пробег был у машины?
Однако, подчас столь же важной задачей является и контроль работы установленного на машину оборудования.
Например, представьте, что ваша организация занимается доставкой цемента. На качество бетона сильно сказывается, было ли его перемешивание во время доставки. Водитель же, в целях слива топлива, не заинтересован во включении столь топливно-затратного механизма (однако, будет утверждать, что он ее включал), и потому включит его лишь за несколько минут до прибытия к заказчику. В результате чего, клиент будет не доволен качеством бетона (как минимум) и потребует от вас компенсаций (описан реальный случай таких требований). И не имея соответствующего датчика крайне проблематично определить, была ли работа оборудования или нет.
Другим случаем, для примера, будет учет работы самосвалов и, например, мест выгрузки груза. В этом случае вам потребуются датчик подъема кузова (как минимум) и датчик нагрузки на ось (определить, есть ли в кузове груз).
Как и любые датчики, они имеют свою точность работы.
В приведенных случаях, выгода от использования дополнительных датчиков гораздо выше, чем затраты на оборудование! И эти случаи не единичны. В каждой конкретной ситуации следует проводить исследование возможности и целесообразности установки датчиков учета работы оборудования.
Учет топлива так же организуется при помощи датчиков. Обычно они бывают двух типов: 1. Измерение уровня топлива в баке в моменты времени - ДУТ/ДУЖ. С определенной периодичностью (например, 1 раз в минуту) данный датчик присылает какие-то значения (в советском мультике, удава измеряли в "попугаях", вот и датчик тоже меряет в "попугаях"), соответствующие высоте уровне топлива ("33 попугая"). Программный комплекс, посредством тарировочной таблицы переводит данные "попугаи" в литры. И уже значение литров и видит пользователь. По уровню топлива в баке программа уже и определяет что происходит - расход топлива, или заправка. Т.е. всегда может быть случаи замедленного определения наступления момента заправки или слива, пропуска алгоритмом мелких заправок или сливов. 2. Измерение количества протекшего топлива - Проточные датчики. Данные датчики считают количество протекшей мимо них жидкости (ничем по принципу учета не отличаются от обычных счетчиков воды, или газа в квартире). Данные датчики тоже должны тарироваться (сколько "попугаев" от датчика какому объему протекшего топлива соответствуют). Обычно, датчики устанавливаются внутрь топливной системы от бака к двигателю, и обратно (для "обратки" в дизельных двигателях). Проточные датчики дает точное количество расхода топлива через двигатель, но не позволяют учесть его возможный слив "с горла".
Оба варианта имеют как плюсы так и минусы, однако, на практике, в большинстве случаев используются датчики уровня топлива - именно они позволяют настроить контроль за уровнем топлива, и "ловить сливы" эффективно. В любом случае, датчики как и любое другое измерительное устройство имеют точность, условия для работы, в которых они должны эксплуатироваться.
Например, при движении ТС, наблюдается "болтанка" графика расхода топлива, и приходящие от датчика значения напоминают "пилу". Для "выравнивания" приходится применять алгоритмы сглаживания данных ситуаций ("среднее значение"), что вносит дополнительный процент неточности, и так далее. Так же на работе датчиков может сказываться качество топливо, его состав, попадание в бак посторонних предметов, изменение геометрии бака, изменение температуры топлива. Все эти факторы вносят определенную долю в погрешность измерения датчиком. И влияют на конечный результат. Так же важной составляющей является наличие сертификата на датчик уровня топлива как на измерительное устройство - это повышает гораздо шансы в суде против нерадивых водителей.
При сравнении с нормами расхода топлива, оказывается, что нормы нужно указывать не только на километраж пробега ТС, но и нормочас работы оборудования и агрегатов, а значит, устанавливать датчики работы данного оборудования.
Например, на рисунке ниже показан график топлива (верхний), совмещенный с графиком скорости (нижний). При этом, на графике уровня черная кривая - это реально выданные значения датчиком, а красная - усреднение этих значений. Так же на графике уровня топлива серым фоном обозначены интервалы работы датчика зажигания.
На графике видно, что в период с 09:00 по 12:00 идет медленный расход топлива (красная и черная кривые практически совпадают), при этом, есть периоды, когда не включено зажигание. Это говорит или о сливе топлива водителем, или о наличии неучтенного датчиком агрегата (расход идет и без датчика зажигания), который расходует топливо на свою работу. Действительно, в качестве примера приведено ТС с миксером для бетона, и как раз период с 09:00 до 12:00 и есть работа миксера (в остальное время расход топлива на миксер "замаскирован" расходом на работы двигателя при движении). Соответственно, если не подключить датчик работы данного агрегата (как видим, его работа от наличия сигнала зажигания не зависит), то алгоритм поиска сливов (отчетность в ПО) будет "ругаться" на сверхнормативный расход (пробег=0, расход=10 литров). Так же, отсутствие датчика работы оборудования создаст для водителя возможность злоупотреблений сливом топлива - так как любой "медленный" расход топлива можно будет списать на работу оборудования.
Так же нам могут быть интересны датчики, присылающие значение какого-либо параметра (температура среды, напряжение питания, количество оборотов, частота оборотов и т.п.) - по принципу работы они ничем практически не отличаются от датчиков уровня топлива (те же "попугаи", которые по таблице переводятся в "показания" температуры, или вольтов, или еще чего).
Сбор информации, обработка.Теперь, когда мы определились с параметрами модели, переходим ко сбору информации.
Так как, базовым элементов модели являются навигационные маяки и датчики (данные от них), то если от них не поступают данные, то и нечего анализировать уже дальше... Посему наиболее базовой задачей является обеспечить нормальную работу установленного оборудования, своевременную его замену, ремонт, выявление проблем.
Основная причина отсутствия данных от оборудования - это проблемы с его питанием. Все очень просто - нет электричества в проводах - лампочки не горят. Не работающие приборы (или еще какие проблемы) оставят вас без данных - это база для анализа. За этим нужно следить в первую очередь. Поэтому следует принять меры к выявлению и своевременному устранению проблем, профилактике.
Например, установить приказами ответственность водителей за порчу имущества, выпускать ТС из предприятия только при условии работающей навигации, назначить ответственных за своевременное решение данных проблем. Заключить, при необходимости, договора с обслуживающими приборы организациями или завести свою службу первичного устранения проблем с приборами. Прописать в договорах сроки устранения проблем, возможность подмены приборов на время ремонта.
Собранная информация должна быть доставлена для анализа. Причем чем быстрее тем лучше, для многих задач скорость достаточно критична. После доставки данных в ПО, оно должно произвести ее анализ: 1. Отнести данные от приборов к машинам 2. Расставить данные по шкале времени, произвести предварительные расчеты.
Скорость первичной обработки данных должна как минимум в два раза быстрее, чем они будут приходить. Например, если у вас есть 100 машин, от которых приходят данные 2 раза в минуту (два пакета), то за минуту ПО должно обработать минимум 100*2*2=400 пакетов. Запас закладывается для случаев, когда по каким-либо причинам будет приостановлена доставка пакетов от навигационного оборудования, и после ее возобновления системе придется обрабатывать данные под большей загрузкой. Тогда, при двукратном запасе мощности, в случае отсутствия всех данных в течении 24 часов, за следующие 24 часа система войдет в нормальный режим работы (т.е. по обработанным данным ПО догонит текущие от приборов). Так же, кроме обработки данных будут запросы к ним от отчетов-пользователей, что будет создавать так же нагрузку. Потому подходите к выбору компьютерного железа вдумчиво, советуйтесь с профессионалами, узнавайте требования к производительности, ПО, СУБД, наличию дополнительных программ для работы.
Для того, что бы данные были доступны круглосуточно стоит обязательно подумать над выделением отдельного сервера для их хранения и обработки, обеспечения его питанием, связью. Обеспечение бесперебойного питания так же сократит возможность потери данных (как всех, так и части). В случае критичности ваших данных стоит подумать о наличии системы резервирования данных на отдельных носителях (других компьютерах). Это позволит сократить в случае критичных сбоев время на восстановление работоспособности. Не повредит наличие запасной линии связи сервера (с орг мерами быстрого переключения между данными линиями, желательно в автоматическом режиме).
Узнайте, сохраняют ли промежуточные сервера ваши данные, как долго, в каком объеме, сколько будет стоит их восстановление и хранение. Возможно, заключите договоры на подобные услуги. Обеспечьте надежное сохранение данных! Иначе будет нечего анализировать, в случае потери (случайной, или преднамеренной)!
Когда применять вышеперечисленные меры - решать вам, но консультация со специалистами, в любом случае, не повредит. Все вышеназванное не является аксиомой, но части от этого так или иначе будут вами реализованы в том или ином объеме.
Кроме того, не повредит иметь хотя бы базовые данные посредством web доступа к какому-либо сайту в интернете по пользователю и паролю.
Так же ваше ПО должно позволяет решать задачи, которые стоят перед вами. Т.е. если вы следите за маршрутами - ПО должно позволять вносить их, составлять задания, получать отчетность. Если за работой оборудование - видеть моменты срабатывания, отчетность и так далее.
Анализ информации.
В общем случае - анализ сводится к сравнению данных с заранее определенными параметрами. Причем, чем больше возможностей по анализу предоставляется ПО в автоматическом режиме, тем лучше - меньше ошибок, быстрее получение данных, данные более достоверные.
Например, вы можете сами лично просматривать историю передвижения транспорта, и выявлять моменты когда оно прибыло в ту или иную точку, но лучше и быстрее за вас справится программа, имеющая данный функционал - предоставит вам отчет о времени, количество срабатываний датчика в заранее определенной зоне.
Потому важным моментом является наличие нужного вам функционала в ПО - чем больше оно будет "уметь делать" само, тем меньше времени будет уходить на анализ, тем меньше ошибок будет допущено при анализе.
Так как, в большинстве случаев конечным "звеном" анализа является человек , то следует заинтересовать его административными мерами (метод "кнута" и/или "пряника") в его своевременном проведении, в точности и достоверности.
Например, в практике мы сталкивались в искажении данных диспетчерами о работе тех или иных водителей - сговоре. Доказать его сложно, ибо диспетчер всегда может сослаться на "усталость", "ошибку" и так далее. Так что следует заранее предпринять меры для ограничения данного.
Посему не стоит доверять данную работу людям:
1. Находящимся в отношениям с персоналом (родственных)
2. У которых может быть какой-либо интерес в искажении данных, в их не своевременном предоставлении.
Даже, если в данный момент диспетчер - это "чужой" водителям человек, то через какое-то время они найдут "путь" к нему (так или иначе). Потому, надо сразу сокращать эти пути-дорожки.
Нужные умения диспетчера (требования к нему): 1. Человек, понимающий на минимальном уровне, что такое машина, чем она занимается, что такое топливо, что такое зажигание. 2. Умение работы в офисных пакетах (MS Office, OpenOffice) - существенная необходимость! 3. Элементарная компьютерная грамотность - как включить компьютер, как сохранять, печать, отправлять по почте файлы, как подключиться к интернету, как запускать программы, что делать, если программа "повисла", как снять снимок с экрана.
Рабочее место должно быть обеспечено как минимум:1. Компьютер (с источником бесперебойного питания) 2. Принтер 3. Доступ к сети (интернету) 4. Телефон - диспетчер должен иметь возможность быстро связываться с разными службами, и они с ним.
Следует нормативными актами (приказами) установить сроки, ответственных и ответственность за проведение анализа, его достоверность и т.п. Предусмотреть меры по проверке качества работы данного персонала.
Потребуется приказ о назначении на должность диспетчера, должностные обязанности, инструкции, оговоренные сроки анализа, ответственность за недостоверность и т.п.
Используемое ПО должно иметь возможность простой интеграции с вашими учетными системами (например, 1С), дабы ее можно было "вмонтировать" в общую систему управления фирмой. Что бы ваши бухгалтера не производили лишние действия по анализу. Интеграция и автоматизация позволит сократить вам затраты на работу персонала, сократить количество ошибок в отчетности, повысить ее достоверность.
Одно дело, когда вы просите диспетчера для вас составить отчет, а другое когда вы можете на сайте компании нажать кнопку, и получить данные там в течении нескольких секунд.
Выявления отклонений.
В первое время, пока система внедряется и персонал еще не привык, что за ним осуществляется постоянное слежение, могут наблюдаться (будут или нет зависит от того, на сколько ответственно водители относятся к своей работе) различные нарушения - сливы топлива, "левые рейсы", нарушения скоростного режима и т.п.
Желательно диспетчеров обязать вести журналы найденных отклонений, фиксируя дату происшествия, дату и время начала-окончания происшествия, его описание (что нашли), дату обнаружения, порядковый номер. Так же стоет там же отмечать случаи нарушения в работе оборудования (отсутствия показаний навигации, отсутствие данных), описание нарушения. При возможности сохранять файлы с данными. Ведение такого журнала упростит принятие решений об административных воздействиях, создаст историю найденных отклонений. Для более подробных фиксаций можно использовать системы, типа megaplan.ru или ему подобные. Журнал лучше вести в электронном виде (для последующего анализа), производя его распечатку и подписание (для сохранения а архиве "неизменной" копии) каждый отчетный период. Так же по каждому отклонению желательно иметь подтверждающие его файлы (распечатки).
После ввода в эксплуатацию (если все будет "правильно") количество случаев пойдет на убыль, что, впрочем не отменяет важность проведения подобного анализа.
Сделать из слежения "большой секрет" и "прятать" приборы и антенные не имеет смысла, так данный "секрет" вы раскроете в тот же момент, когда будете применять меры воздействия на водителей. Дальше народная молва очень быстро разнесет факт наличия слежения за ними. Тем более подобная "секретность" сразу создаст проблемы с установкой оборудования (например громкой связью). Посему, выгода от этого исчезающе мала, и затраты не оправдаются. Гораздо больше вы добьетесь, если организуете работу так, что бы ТС не выходили за ворота предприятия, если у них проблемы с навигацией (если "их не видно в программе") - в первый день это кажется не возможным, но уже через 3-7 дней все к этому привыкают. Соответственно данные меры нужно подкрепить административно.
После ввода в эксплуатацию (если все будет "правильно") количество случаев пойдет на убыль, что, впрочем не отменяет важность проведения подобного анализа. Реакции на отклонение может быть две:
1. Если установлено, что данное отклонение произошло по причине не точности нашей модели (например, не все датчики установлены) - модель нужно уточнить, внести отсутствующие данные, возможно, установить какое-то оборудование.
Например, отчет зафиксировал слив топливом водителем - что бы убедиться так ли это, следует детально просмотреть график уровня топлива, узнать что это за ТС, чем оно занимается, где оно было в момент слива. Возможно (особенно на этапе внедрения навигационного оборудования) просто не все данные учтены. Пример не учтенной информации приводился выше (см рисунок). В приведенном примере, программа фиксировала слив (сверхнормативный расход топлива), так как миксер, перемешивающий бетон не был оборудован датчиком работы (или, что тоже самое, для данного датчика в программе не выполнены настройка, и/или не указаны нормы расхода топлива).
2. Если обнаружено отклонение подлежащее административному воздействию - выполнить его. Обычно это сводится к наказанию ответственного лица.
Соответственно, сотрудник должен быть ознакомлен с тем, что его могут и за что наказать (как говорили в одной комедии - "Огласите весь список, пжалуста"). В организации следует организовать работу и взаимодействие служб эффективным образом. Т.е. диспетчер для выполнения своей работы должен обладать как можно большей информацией (маршрутные задания ТС, данные о первичных документах о заправках, о сливах, заполненные по возвращению путевые листы и так далее и тп). Найденные диспетчером отклонения должны по цепочке "уходить" выше, писаться водителями объяснительные, применяться штрафные санкции. Естественно, разбирать найденные диспетчерами случаи должны лица, не имеющие умысла к фальсификации (например, не стоит доверять такие "разборки" начальникам АТП - так как водители находятся в его прямом подчинении)
Источник: внедрение навигации, ГЛОНАСС, GPS, учет топлива, повышение эффективности, CyberFleet, Cyber GLX |
