Принцип работы
На рисунке ниже приведена структурная схема модуля «Мониторинг».
Рис. 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. Выполняется проверка, когда было сгенерировано предыдущее событие для данного правила и объекта мониторинга. Если текущее событие сработало раньше, чем параметр «Пропускать событие, если оно возникает чаще чем», то событие игнорируется.
13. По каждому извлеченному уведомлению формируется сообщение согласно шаблону сообщения и тема согласно шаблону темы сообщения из правила.
14. Если в правиле включена опция «Записать в журнал», событие помещается в журнал.
15. По каждому извлеченному уведомлению из очереди оповещений выполняется отправка уведомления на сервер (почтовый, …) или выполняется действие, включенное в правиле. В случае возникновения ошибки (отправки сообщения, создания файла и т.д.) делается запись в системный журнал с сообщением об ошибке, названием объекта мониторинга и параметра.
Примечание
Т.к. многие параметры имеют и табличные и финальные данные, то следует проявлять внимательность при создании правила. Например, если будет создано правило на финальный параметр «Speed > 60» – то будет происходить сравнение предыдущих финальных данных и текущих. Это повлечет за собой пропуск всех точек трека в которых условие «Speed > 60» выполнялось, если эти точки не были последними за интервал проверки финальных данных. Другими словами, все превышения скорости > 60 км/ч будут пропущены, если они не попали в финальные данные. В случае, если надо проверять аналоговые данные или вычисленные (скорости, уровни), следует создавать правила только на табличные параметры.
Примечание
Количество правил и их условия не имеют влияния на скорость работы. Расчёт выполняется только один раз для каждого объекта мониторинга при изменении данных. Скорость проверки правил на условия сработки – ничтожна по сравнению со скоростью выполнения расчёта.
Примечание
Существует задержка между изменением файла (поступлением данных от приборов) и генерацией события на оповещение. Это связано с тем, что данные от приборов могут приходить быстрее, чем они обрабатываются. Типичная задержка на средней схеме в 150-200 объектов и периодом загрузки 1 минута может достигать 20-30 секунд.
Обработка правил для финальных данных
Для финальных данных происходит проверка аналогично табличным (начиная с п.4 выше), за рядом исключений:
- т.к. финальные данные должны вычисляться и для тех объектов мониторинга, для которых данные перестали поступать и в этом случае никаких событий об изменений файлов не будет генерироваться (например, если правило создано на параметр OutOfDateCoords – устаревшие координаты), то для запуска обработки происходит принудительное добавление фиктивных событий в очередь обработки (блок 2 на структурной диаграмме). Данное действие выполняется для тех приборов, у которых есть хотя бы одно правило с финальным параметром. Фиктивное событие генерируется только для тех приборов, которых ещё нет в очереди. Если событие для прибора уже есть в очереди, значит правила проверяются штатным образом, начиная с п.2.
- для финальных данных нет никакого трека, т.к. есть только предыдущее значение подсчитанных финальных данных и текущее. Фактически выполняется обработка данных из массива, состоящего из двух элементов.