Общий смысл такого действия - выдать оперативное сообщение-окно для диспетчера о каких-либо проблемах, зарегистрировать комментарий по данному сообщению, оставить след об этом в событиях (базе данных), предоставить возможность анализа отчетами ПО таких событий.
В данной статье я расскажу о реализации датчика, выводящего тревожное сообщение при отсутствии данных от ДУТ больше 1 час, приведу пример такой реализации, расскажу на каких принципах она построена.
Задача стояла:
При наступлении определенной ситуации, вызвать тревожное окно сообщений на экран, и выдать информацию пользователю для комментария.
При ее решении, самым сложным оказалось именно вызвать данное окно, ибо все перепробованные мною способы не вызывали окно. Проконсультировавшись с разработчиками я пришел к выводу, что окно можно вызывать, зарегистрировав в списке не обработанных событий срабатывание датчика (с определенными координатами).
Решение виделась мне так.
1. Зарегистрировать какой-то датчик, с заранее известными параметрами (например, с фиксированным номером), с признаком тревога.
2. Создать процедуру, которая периодически бы анализировала данные, и принимала решение о срабатывании данного датчика для каждого ТС (терминала).
3. Обеспечить периодический запуск процедуры.
4. Так как процедура просто имитирует работу службы доставки сообщений, то дальше будет работать уже стандартный алгоритм CyberFleet.
В результате система решит, что у терминала сработал "настоящий" датчик,а так как датчик сей помечен как тревожный в КиберФлите, то будет выведено окно тревожных сообщений.
Минусы решения: так как данные от терминала могут накапливаться в черном ящике, а при регистрации срабатывания нашего датчика нужно будет указать какие-то координаты (например последние известные), то после прихода данных от терминала, может получиться так, что машина совершит "скачок" на карте. Однако прироста пробега по одометру это не даст, но даст прирост пробега по карте. 100% гарантировать что данная ситуация не случится, мы естественно не можем.
Если же мы зарегистрируем данные от датчика с пометкой "невалидные", то увидеть в истории место на карте не получится. Для каких-то датчиков это можно сделать (анализ, что нет данных от прибора, например), а для каких-то важно в каком именно месте сработал датчик (фиксация простоя ТС). Для каждого типа датчика нужно принимать решение и реализовывать его в алгоритме процедуры обработки датчика отдельно.
Это была теория, а теперь пора перейти к практике.
В примере я покажу, как реализовать датчик, который будет срабатывать при отсутствии данных от датчика уровня топлива.
Решение по пунктам.
1. Выбираем номер датчика для работы - я решил что это будет датчик №30. Типа цифровой, тревожный. Должен быть активным для прибора. Так как датчик будет срабатывать для топлива, то у прибора должен быть зарегистрирован датчик уровня топлива: Аналоговый, топливный, №10
2. Алгоритм работы процедуры таков:
- проверяем, что у прибора есть топливных датчик (аналоговый, №10, активный), и что есть датчик №30. Если у прибора их нет, или один из них не активный - то и проверять нечего.
- Находим когда были последние данные от прибора. Если они были позже чем 30 минут назад проверку выполнять дальше смысла нет (выбор периода зависит от того, как именно настроены периоды отбивки данных от приборов и от датчиков - типовые периоды = ДУТ 1 минута, данные от терминала не позже чем раз в 5 минут, но проверка будет запускаться не чаще чем 1 раз в 60 мин).
- Проверяем, что от датчика были данные в период в течении 30 минут, перед последней зарегистрированной координатой.
- Если данные от ДУТ отсутствуют в указанный период - регистрируем приход данных от терминала, с текущим временем, с активным датчиком №30, с пометкой, что данные невалидные, с отметкой, что данные не содержат показаний спидометра, в таблице sys_dev_dirtydata
- При регистрации срабатывания считаем, что данных в sys_dev_dirtydata по данному прибору нет - для целей демонстрации такое допущение вполне может быть сделано. На практике же, данные могут там находиться, но не быть еще обработанные (только включили компьютер). Это нужно учитывать при реализации процедуры срабатывания датчика.
3. Данную процедуру запускаем каждые 60 минут - для наших целей такой периодичности вполне достаточно (ибо решить проблему с ДУТ быстрее вряд ли получится).
4. При срабатывании сервиса анализа, он увидит данные от "датчика", и отдаст команду на показ тревожного окна, запишет данные в историю машины о срабатывании датчика.
Для размещения процедуры я использовал отдельную БД, с названием BN_Jobs (заменить первую строку на нужную). База данных КиберФлита у меня имеет имя BN. Если ваша БД КиберФлита имеет другое название, отличное от BN, потребуется внести изменения в тело процедуры.
Скрипт процедуры можно посмотреть на форуме (ссылка). Тело процедуры разбито на две части: 1. Формирование списка приборов и датчиков, которые подходят под условия.
2. Обход данного списка, имитация для каждого датчика срабатывания.
Такой подход позволяет в теле цикла обхода (цикл посредством курсора) создать дополнительные проверки необходимости в выводе сообщения о датчике, которые крайне сложно реализовать через фильтры-запросы.
В случае примера этого не потребовалось, потому в теле цикла производится только инициализация срабатывания датчика.
Далее, следует создать задание (например через MS Management Studio) для запуска данной процедуры, установить период запуска каждые 60 минут.
Задания SQL запускаются службой SQLSERVERAGENT входящей в состав SQL. Она может быть отключена - не забудьте настроить ее на работу (запуск авто, перезапуск если повисла).
В результате я имею - каждые 60 минут запускается процедура, которая проверяет, что разрыв между данными навигации и ДУТ не превысил 30 мин, если же больше - выводится окно сообщения.
Недостатки примера:
1. Если данные перестали идти от ДУТ, то сообщения по данному прибору будут всплывать КАЖДЫЙ ЧАС (точнее каждый период запуска процедуры - указывается в расписании задания). Что хорошо для примера, но в реальной жизни будет действовать на нервы операторам... хотя может это тоже хорошо.
2. Не проверяется наличие данных о датчике в таблице с еще не разобранными данными. Для примера это не нужно, а в жизни не всегда нужно...
3. Запись о датчике производится с пометкой "невалидные координаты". Причем точка берется из данных о последнем положении машины. Если же после будут получены данные о движении в это время (из черного ящика), то в истории будет "прыжок" машины, что некрасиво скажется на построении маршрута. - к сожалению это "родовой" косяк всего метода, а не просто примера...
