На рисунке ниже приведена структурная схема модуля мониторинга.
Рис.1. Структурная схема модуля мониторинга.
1. При приеме новых данных модуль мониторинга получает оповещение об изменении/создании файла. При этом происходит следующее:
•Из имени измененного/созданного файла считывается серийный номер устройства, с которого эти данные получены и далее проверяется – есть ли у данного прибора хотя бы одно включенное правило мониторинга для обработки. Если нет правил – никаких действий далее не предпринимается. Если есть хотя бы одно включенное правило, в очередь обработки помещается серийный номер этого устройства.
•Правила мониторинга могут использоваться для проверки, как табличных, так и финальных данных. Механизм обработки правила зависит от типа параметров.
Обработка правил для табличных данных
2. По принципу FIFO (first in, first out) обработчик правил выполняет поочередный анализ событий из очереди на обработку – поиск нужного транспортного средства по серийному номеру и переход к обработке правил.
3. На этом этапе выполняется расчет рейса и трека за следующий период с [Текущее время] – [Окно просмотра] до [Текущее время] + [2 минуты]
Рис.2. Анализ табличных данных.
После расчета рейса модуль «Монитор» начинает проверку правил за этот рейс.
|
Две минуты добавляются к текущему времени для корректной работы на компьютерах с несинхронизированным временем. Если на сервере системное время отстаёт от актуального (GPS), возникает запаздывание обработки событий. То есть, в данных, полученных от прибора, присутствуют данные в «будущем» относительно системного времени компьютера и эти данные будут отброшены при вычислении рейса без корректировки. Данные инциденты имели место до внесения этой корректировки. На компьютерах с точным системным временем данная корректировка не вносит никаких искажений в расчёт, т.к. в «будущем» времени нет никаких данных и эта настройка будет проигнорирована. |
|
Настройка «Окно просмотра» задается в настройках модуля мониторинга и должна подбираться так, чтобы в этот интервал попадала хотя бы одна запись проверяемого параметра. В случае редких данных (записываемых в память прибора с большим периодом), настройка «Окно просмотра» должна быть увеличен. В противном случае при обновлении значения параметра, оно может не попасть в интервал проверки и будет проигнорировано при анализе правила – при проверке условия правила будет использоваться значение из последней обработанной точки, которое не будет являться актуальным. Следовательно, будет пропущено событие, в случае его срабатывания. |
4. Для каждого включенного правила проверяются следующие условия:
•Проверяется расписание правила, если правило «выключено» в данное время, его обработка прекращается.
•Проверяется наличие параметров, указанных в правиле у данного ТС. Если данного параметра нет, обработка правила прекращается.
5. Если есть сохраненное предыдущее состояние из предыдущего цикла проверки правила (см. п.10) – начальным условием при текущей проверке берётся сохраненное значение параметра из п.10 и цикл п.6 начинается с 0-й точки. В противном случае – цикл начинается с 1-й точки.
На рисунке ниже приведен порядок проверки условия из правила в каждой записи на примере поиска превышения.
Рис.3. Механизм проверки условия.
6. В цикле для каждой вычисленной записи проверяется выполнение условия в правиле. Например, если правило содержит условие «Speed > 60», то в каждой записи проверяется значение параметра Speed и проверяется условие > 60. Если обнаружено, что в предыдущей точке данное условие не выполнялось, а в текущей выполняется – считается, что произошло срабатывание правила, после чего в существующем наборе данных находится окончание срабатывания правила. Если такая точка найдена, вычисляется длительность правила.
7. Если у правила стоит флаг «на начало события», собирается информация по событию (координаты, дата/время, копия табличных и финальных данных и т.д.) и далее в очередь оповещений добавляется событие на уведомление по этому правилу. Если у правила стоит флаг «на окончание события», то это событие сохраняется для последующей обработки и не генерирует события на уведомление.
8. Если в правиле было вычислена длительность события, то проверяется условие «минимальная длительность события». Если длительность события меньше, оно игнорируется.
9. После обработки всех правил для данного ТС все полученные уведомления помещаются в очередь оповещений на отправку.
10. Запоминается дата/время последней обработанной точки и значение параметра в этой точке для обработки с этого значения в п.6.
11. Выполняется аналогичная проверка для правил с финальными параметрами, начиная с п.4.
Обработка уведомлений
12. Выполняется проверка, когда было сгенерировано предыдущее событие для данного правила и ТС. Если текущее событие сработало раньше, чем параметр «игнорировать дубликаты событий, если они произошли в течение N секунд», то событие игнорируется.
13. По каждому извлеченному уведомлению формируется сообщение согласно шаблону сообщения и тема согласно шаблону темы сообщения из правила.
14. Если в правиле включена опция «Записать в журнал», событие помещается в журнал.
15. По каждому извлеченному уведомлению из очереди оповещений выполняется отправка уведомления на сервер (почтовый, ...) или выполняется действие, включенное в правиле. В случае возникновения ошибки (отправки сообщения, создания файла, ...) делается запись в системный журнал с сообщением об ошибке, названием ТС и параметра.
|
Т.к. многие параметры имеют и табличные и финальные данные, то следует проявлять внимательность при создании правила. Например, если будет создано правило на финальный параметр «Speed > 60» – то будет происходить сравнение предыдущих финальных данных и текущих. Это повлечет за собой пропуск всех точек трека в которых условие «Speed > 60» выполнялось, если эти точки не были последними за интервал проверки финальных данных. Другими словами, все превышения скорости > 60 км/ч будут пропущены, если они не попали в финальные данные. В случае, если надо проверять аналоговые данные или вычисленные (скорости, уровни), следует создавать правила только на табличные параметры. |
|
Количество правил и их условия не имеют влияния на скорость работы. Расчёт выполняется только один раз для каждого ТС при изменении данных. Скорость проверки правил на условия сработки – ничтожна по сравнению со скоростью выполнения расчёта. Примечание 5. Существует задержка между изменением файла (поступлением данных от приборов) и генерацией события на оповещение. Это связано с тем, что данные от приборов могут приходить быстрее, чем они обрабатываются. Типичная задержка на средней схеме в 150-200 ТС и периодом загрузки 1 минута может достигать 20-30 секунд. |
Для финальных данных происходит проверка аналогично табличным, за рядом исключений:
•Т.к. финальные данные должны вычисляться и для тех ТС, для которых данные перестали поступать и в этом случае никаких событий об изменений файлов не будет генерироваться (например, если правило создано на параметр OutOfDateCoords – устаревшие координаты), то для запуска обработки происходит принудительное добавление фиктивных событий в очередь обработки (блок 2 на структурной диаграмме). Данное действие выполняется для тех приборов, у которых есть хотя бы одно правило с финальным параметром. Фиктивное событие генерируется только для тех приборов, которых ещё нет в очереди. Если событие для прибора уже есть в очереди, значит правила проверяются штатным образом, начиная с п.2.
•Для финальных данных нет никакого трека, т.к. есть только предыдущее значение подсчитанных финальных данных и текущее. Фактически выполняется обработка данных из массива, состоящего из двух элементов.