На рисунке ниже приведена структурная схема модуля мониторинга.

 

 

Рис.1. Структурная схема модуля мониторинга.

 

1. При приеме новых данных модуль мониторинга получает оповещение об изменении/создании файла. При этом происходит следующее:

•Из имени измененного/созданного файла считывается серийный номер устройства, с которого эти данные получены и далее проверяется – есть ли у данного прибора хотя бы одно включенное правило мониторинга для обработки. Если нет правил – никаких действий далее не предпринимается. Если есть хотя бы одно включенное правило, в очередь обработки помещается серийный номер этого устройства.

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

 

Обработка правил для табличных данных

2. По принципу FIFO (first in, first out) обработчик правил выполняет поочередный анализ событий из очереди на обработку – поиск нужного транспортного средства по серийному номеру и переход к обработке правил.

3. На этом этапе выполняется расчет рейса и трека за следующий период с [Текущее время] – [Окно просмотра] до [Текущее время] + [2 минуты]

 

Рис.2. Анализ табличных данных.

 

После расчета рейса модуль «Монитор» начинает проверку правил за этот рейс.

 

 

 

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. По каждому извлеченному уведомлению из очереди оповещений выполняется отправка уведомления на сервер (почтовый, ...) или выполняется действие, включенное в правиле. В случае возникновения ошибки (отправки сообщения, создания файла, ...) делается запись в системный журнал с сообщением об ошибке, названием ТС и параметра.

 

 

 

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

•Т.к. финальные данные должны вычисляться и для тех ТС, для которых данные перестали поступать и в этом случае никаких событий об изменений файлов не будет генерироваться (например, если правило создано на параметр OutOfDateCoords – устаревшие координаты), то для запуска обработки происходит принудительное добавление фиктивных событий в очередь обработки (блок 2 на структурной диаграмме). Данное действие выполняется для тех приборов, у которых есть хотя бы одно правило с финальным параметром. Фиктивное событие генерируется только для тех приборов, которых ещё нет в очереди. Если событие для прибора уже есть в очереди, значит правила проверяются штатным образом, начиная с п.2.

•Для финальных данных нет никакого трека, т.к. есть только предыдущее значение подсчитанных финальных данных и текущее. Фактически выполняется обработка данных из массива, состоящего из двух элементов.