Software & Systems

Современные предприятия и организации имеют сложную информационную инфраструктуру, которая, как правило, включает в себя большое количество разнородных источников данных, в том числе связанных с мониторингом процессов [1]. Одной из частных задач мониторинга процессов является мониторинг перемещений движущихся объектов на определенной территории и (или) между распределенными зонами, входящими в состав сложного объекта.

Как правило, для этого используются различные системы мониторинга, включающие системы контроля доступа, средства фото- и видеофиксации и т.п., преимущественно при­меняющиеся для получения данных о таких процессах, как попадание движущегося объекта на закрытую территорию (вход, въезд), перемещение из одной зоны в другую, а также покидание закрытой территории (выход, выезд). Системы мониторинга разных типов имеют разные базы для записи и хранения данных [2].

Все данные, получаемые от систем монито- ринга, направляются на центральный узел сбора данных. Они поступают в разном формате, который зависит от типа средства мониторинга, зафиксировавшего информацию. Как правило, на центральном узле осуществляются некоторые первичные преобразования данных с целью приведения к виду, удобному для представления и хранения, однако их формат по-прежнему остается разным и зависит от типа источника.

Разнообразные средства мониторинга и контроля зачастую фиксируют определенный набор параметров при возникновении того или иного события. При этом несколько средств мониторинга могут одновременно зафиксировать одно и то же событие, каждый со своим набором параметров. Как правило, получаемые от различных датчиков «сырые» данные оказываются непригодными для анализа существующими методами и нуждаются в ряде предварительных преобразований.

При подготовке данных для применения к ним средств интеллектуального анализа данных необходимо решить следующие задачи:

-     привести данные к единому формату, пригодному для анализа;

-     интегрировать записи, относящиеся к одному событию, в одну запись;

-     при большом количестве разных типов событий, характеризующихся разным составом атрибутов, выделить группы событий со схожим составом атрибутов.

В данной работе представлен метод подготовки данных от разнородных источников к единому формату. Предлагаемый метод доработан по сравнению с первоначальной версией, представленной в работе [3]. В качестве источников данных учитываются не только датчики систем мониторинга, но и учетные базы, данные из которых используются для сопоставления субъектов разных типов с целью более точного выделения записей, относящихся к одному событию. Метод был опробован на реальных данных, полученных от предприятия.

Обзор существующих методов

Рассмотрим известные методы подготовки данных, поступивших от разнородных источников.

Задача интеграции таких данных описана в работе [4], где авторы предлагают метод, основанный на онтологии и определении семантической близости концептов. Метод позволяет группировать семантически близкие записи и структурировать БД для более удобной обработки информации, однако не выявляет взаимосвязи между записями, относящимися к одному событию.

В работе [5] предлагается способ приведения XML-данных к единому формату на основе теории графов, деревьев решений и XSTL-пре­образований. Метод используется для решения достаточно узкого круга задач (анализа данных, поступающих от веб-сервисов). Кроме того, он решает лишь задачу приведения данных к единому формату.

Задача интеграции разнородных данных, поступающих от дорожных датчиков и GPS-треков, решается в [6]. В работе учитываются взаимосвязи между записями от различных источников, относящимися к одному событию. Авторы ставят задачу моделирования транспортных потоков на основе реальных данных, поэтому задача приведения их к формату, удобному для последующего анализа, в рамках исследования не рассматривается.

В работе [7] описан основанный на гауссовой графической модели метод объединения данных от разнородных датчиков, каждый из которых способен фиксировать разнородные параметры. Метод предлагает сократить размерность данных, однако не предусматривает корреляцию различных записей и предназначен лишь для сбора информации и ее удобного представления.

Алгоритмы корреляции событий [8, 9] решают задачу объединения данных от разнородных источников и установления взаимосвязей между ними, однако, как правило, в контексте задачи обеспечения безопасности вычислительных сред разнородными источниками являются различные компоненты сети, при этом данные имеют единый формат и не требуют дополнительных преобразований для дальнейшей обработки и анализа.

Формальная модель процесса

Приведенная далее формальная модель процесса является доработанной и уточненной версией модели, представленной в [10]. Добавлено описание зон, введены подмножества движущихся объектов, подвергаемых наблюдению, а также объектов мониторинга. Уточнены параметры атрибутов и формальное описание событий с помощью атрибутов.

Производственные объекты, как распределенные, так и расположенные в пределах определенной территории, как правило, представляют собой конечное множество отдельно взятых зон: Z = {z1, z2, …, zn}.

Зоны могут быть выделены изначально в зависимости от их расположения, функционального назначения или же заданы в процессе решения конкретной задачи в зависимости от ее условий.

На производственном объекте могут происходить различные фиксируемые события. Их можно представить конечным множеством: E = {e1, e2, …, en}.

В контексте решаемой задачи событиями считаются разного рода перемещения движущихся объектов, составляющих множество SB: SB = {sb1, sb2, …, sbk}.

Можно выделить различные типы движущихся объектов, подвергаемых мониторингу: транспортные средства (автомобили, автобусы, поезда и т.д.), люди (сотрудники организации, студенты учебных заведений и т.д.) и др. Поэтому в зависимости от процесса и участвую- щих в нем перемещающихся объектов можно выделить разные подмножества движущихся объектов: SB = {SB1, SB2, …, SBm}.

Для фиксации событий используются различные средства мониторинга SM: SM = {sm1, sm2, …, smj}.

В зависимости от характера наблюдаемых процессов на предприятиях используются средства мониторинга различных типов, которые составляют подмножества: SM = {SM 1, SM 2, …, SM b}.

Различные системы мониторинга, как правило, распределены среди всех анализируемых зон или некоторых из них. Каждый отдельно взятый элемент системы мониторинга (конкретная фото- или видеокамера, датчик контроля пропускной системы и пр.) имеет свой уникальный идентификатор. При анализе данных этот параметр может быть использован для определения места, где было зафиксировано событие.

В качестве источников данных DS могут выступать как средства мониторинга SM, так и различные виды документации или дополнительные БД: DS = {DSdoc, DSbd, …, DSsm}.

В некоторых DS может содержаться информация от отдельно взятого средства мониторинга (sm = const), в то время как в других DS консолидироваться информация от разных средств мониторинга (sm = var).

Информация об одном и том же событии может содержаться в нескольких DS и, таким образом, представляться в виде нескольких различных записей.

Каждая запись содержит определенный набор атрибутов из множества атрибутов А и значений этих атрибутов. Набор атрибутов обычно определяется типом средства мониторинга SM.

Как правило, набор атрибутов в любой записи содержит следующую информацию:

-     временные характеристики события (t);

-     тип совершенного действия (type);

-     средство мониторинга (sm), также указывающее на место совершения события (z);

-     сущность, совершившая действие (sb);

-     объект, над которым было совершено действие (sv);

-     дополнительные параметры (pgg).

Таким образом, множество атрибутов можно условно разбить на подмножества: A = At È Atype È È Asm È Az È Asb È AsvÈ .

В одних случаях атрибуты, указывающие на место совершения события (Аz), могут быть вынесены в отдельный атрибут, в других – определяться только принадлежностью средства мониторинга sm конкретной зоне z. Как правило, данные от средств мониторинга sm должны позволять определять моменты вхождения в ту или иную зону, нахождения внутри зоны и выхода из нее.

Зачастую наименования атрибутов, описывающих один и тот же параметр, могут отличаться в разных типах источников данных. Кроме того, разные средства мониторинга могут фиксировать различные параметры, идентифицирующие сущность, совершившую действие: asb = á asb_a, asb_b, …, asb_gñ.

В ходе мониторинга также могут возникать непредвиденные ситуации, в результате которых определение некоторых параметров может быть затруднено, то есть возникает проблема пропуска данных или их нечеткость.

При фиксации одного и того же события разными средствами мониторинга необходимо принимать во внимание возможные временные задержки, возникающие из-за различных особенностей выполнения исследуемых действий, размещения объектов мониторинга и иных факторов, обусловливающих неодновременность создания записей. В связи с этим для каждого типа выполняемых действий необходимо ввести допустимые временные задержки t.

Таким образом, отдельно взятое событие ei может быть описано с помощью набора атрибутов:

При анализе такого рода данных возникают следующие проблемы:

-     определение типа события в зависимости от состава атрибутов;

-     синхронизация временных параметров с целью точной группировки данных для описания отдельно взятого события;

-     дублирование, нечеткость или пропуск данных.

Таким образом, для анализа событий и выявления среди них возможных нарушений необходимо решить следующие задачи:

-     выполнить общие преобразования, позволяющие привести данные к виду, пригодному для дальнейшего анализа; так, для ме- тодов Data Mining необходим набор в виде матрицы (таблицы), где каждая строка представляет собой описание события, а столбцы – атрибуты этого события;

-     записи, поступившие от разных систем мониторинга и относящиеся к одному и тому же событию, должны быть сгруппированы, для чего, прежде всего, необходимо определить критерии, по которым следует выделять и объединять такие записи.

Общие преобразования

Любое событие ei происходит в определенной точке пространства в определенный момент времени [5]. При этом событие может быть инициировано одним субъектом или группой субъектов. В рамках данной работы будут рассмотрены события, инициированные одним субъектом sbk.

Таким образом, каждое событие имеет набор атрибутов A, относящихся к субъекту, инициировавшему событие (Asb), месту (Az) и времени совершения события (At). Такие атрибуты, а также атрибуты, повторяющиеся для всех без исключения типов событий, можно назвать общими и выделить их в группу Common (рис. 1). Разные средства мониторинга могут описывать события с помощью разных наборов атрибутов. Поэтому описания событий могут отличаться друг от друга и зависеть от типа события и средств, которые фиксируют такие типы событий. Вариативные атрибуты могут быть выделены в группу Variable.

Особенностью такого рода баз является различное представление событий. В таблице Common, как правило, каждое событие, зафиксированное той или иной системой мониторинга, описывается одной строчкой, а атрибуты расположены по столбцам. В таблице Variable, напротив, каждая строка описывает отдельно взятый атрибут и соответствующее ему значение.

Для комплексного анализа событий необходимо интегрировать данные, полученные от всех типов источников, в единую таблицу. Для БД, где данные хранятся так, как показано на рисунке 1, прежде всего необходимо привести две разнородные таблицы к общему виду. К таблицам из группы Variable предлагается применить преобразование pivot. Это позволит расположить атрибуты по столбцам и записать соответствующие им значения в виде одной строки. Далее следует объединить таблицы Common и Variable по атрибуту, идентифицирующему событие, как показано на рисунке 2.

В результате будет получена общая таблица UDS_SM, содержащая множество записей от всех возможных средств мониторинга. Каждая строка такой таблицы соответствует одной записи, полученной от какого-либо источника данных, а столбцы описывают все возможные атрибуты, фиксируемые всеми имеющимися средствами фиксации инцидентов.

Таблица, тем не менее, является лишь промежуточным вариантом обработанных данных, так как при таком представлении данных имеется ряд нерешенных проблем.

Во-первых, каждая строка такой таблицы представляет собой единственную запись от конкретной системы мониторинга для конкретного события. Если одно событие может быть одновременно зафиксировано несколькими си- стемами мониторинга, то в таблице оно будет описано с помощью нескольких строк, при этом число строк будет равным числу систем мониторинга, зафиксировавших событие.

Во-вторых, для каждой системы мониторинга может существовать свой набор наименований одних и тех же параметров, то есть обозначения параметров могут отличаться в зависимости от типа системы мониторинга. Таким образом, в подобного рода таблице будет присутствовать большое количество атрибутов, имеющих разные названия, но дублирующих друг друга по смыслу, что приведет к большому количеству пропущенных значений.

Для решения описанных проблем следует сделать ряд преобразований, позволяющих объединить записи, относящиеся к одному событию, тем самым снизив избыточность представления данных и значительно уменьшив число пропущенных значений.

Объединение записей, описывающих одно и то же событие

Если событие ei может быть описано с помощью нескольких записей от разных систем мониторинга, то такие записи должны быть сформированы в одно и то же время источниками данных, расположенными в одном и том же месте, и указывать на один и тот же субъект, инициировавший событие.

Пусть некоторый субъект sb1 совершает действия, фиксируемые системами мониторинга sm1, sm2, sm3. Каждая из этих систем генерирует записи с определенным набором параметров. Допустим, данные, формируемые системой sm1, описываются таким набором атрибутов, как . Аналогично данные, формируемые системой sm2, описываются набором атрибутов  , а данные, формируемые системой sm3, – .

Объединение всех записей представлено в таблице 1.

Таблица 1

Формат данных после объединения записей в таблицу UDS_SM

 Table 1

Data format after merging records into UDS_SM table

В таблице показан вариант, когда в полученном файле имеются одновременно два атрибута, идентифицирующих субъект, инициировавший событие. Формат записи может как отличаться (один из атрибутов может указывать на субъект в виде слова, другой – на идентификатор в виде номера и пр.), так и быть одинаковым для всех трех колонок. В некоторых случаях исходная строка может содержать и два атрибута, указывающих на субъект: например, цифровой идентификатор и соответствующая ему фамилия, номер транспортного средства и пр. Таким образом, на данном этапе необходимо сначала найти и объединить атрибуты, описывающие один и тот же смысловой параметр.

В первую очередь, нужно объединить все повторяющиеся атрибуты, указывающие на один и тот же параметр и имеющие общий формат записи, при этом сами значения должны совпадать.

Например, при получении таблицы подобного вида необходимо выделить все атрибуты, указывающие на субъект, и объединить их в один общий атрибут. Для этого можно как создать совершенно новый атрибут, идентифицирующий субъект, так и выбрать один из уже существующих. В приведенном примере будет создан новый атрибут value_sb. Аналогично должны быть проанализированы и преобразованы все атрибуты с общим смыслом.

При анализе отдельно взятых событий или отдельных типов событий важно понимать, из каких процедур, фиксируемых средствами мониторинга, состоит это событие. Необходимо определить последовательность этих процедур и временные задержки между ними. Например, при входе в офисное здание сотрудник организации прикладывает пропуск на входе, а через несколько секунд его лицо попадает в объектив камеры наблюдения. Следовательно, необходимо понимать, что временные атрибуты записей, относящихся к одному событию, могут отличаться на определенное значение, а не быть одинаковыми. Поэтому на данном этапе временные атрибуты следует оставлять неизменными.

В некоторых случаях процесс может включать в себя события, совершаемые разными типами субъектов (например, автобусы и поезда), действия которых фиксируются разными средствами контроля. Параметры записей при этом могут существенно различаться для разных типов субъектов. В таких случаях количество ат- рибутов, идентифицирующих субъект, будет равно количеству типов субъектов.

Результаты преобразования представлены в таблице 2.

Таблица 2

Формат данных после объединения одинаковых по смыслу атрибутов

Table 2

Data format after combining attributes with the same meaning

Очевидно, что при большом количестве атрибутов с одинаковым смысловым значением таблица такого вида является более наглядной и удобной. Она не перегружена лишними параметрами, а количество пропущенных значений будет существенно меньше, чем в таблице 1. Тем не менее, в такой таблице еще имеется некоторое количество пропущенных значений, что по-прежнему создает неудобства при ее анализе.

Как было сказано ранее, любое событие имеет три наиболее важные характеристики:

-     время совершения события (t);

-     место, где событие было совершено (z);

-     субъект, инициировавший событие (sb).

В общем случае при анализе и группировке некоторого количества (d) записей, которые лишь частично описывают одно и то же событие, важно следовать трем основным правилам.

1.  Временные атрибуты события должны совпадать или разница между ними не должна превышать допустимую задержку t:

 Dt £ t.

2.  Должны совпадать пространственные атрибуты события:

3.  Субъект должен быть одним и тем же:

Однако не всегда можно однозначно соотнести данные от разных источников, особенно, если в некоторых записях отсутствуют временные параметры или же зафиксированы идентификаторы разных объектов наблюдения (например, номер автомобиля и идентификатор пропуска, записанный на определенного водителя). В таком случае необходимо сопоставлять информацию от дополнительных источников данных, например, учетных систем.

В общем виде алгоритм группировки данных может быть таким, как представлен на рисунке 3. После выполнения данного преобразования каждый отдельно взятый набор данных (табл. 2) будет иметь вид, представленный в таблице 3.

Таблица 3

Формат данных после преобразований

Table 3

Data format after transformation

Полученные данные пригодны для дальнейшего анализа методами Data Mining.

Пример применения подхода

Для проверки применимости алгоритмов интеллектуального анализа данных к данным, преобразованным с помощью предложенного метода, были проведены эксперименты в среде RapidMiner версии 8.001 [11]. Среда Rapid­Miner представляет собой удобный инструмент анализа данных с простым и понятным пользовательским интерфейсом. Процесс обработки данных реализуется в виде набора блоков, выбираемых пользователем в зависимости от решаемой задачи. При необходимости настройки каждого блока могут быть изменены. Несомненными преимуществами использования среды RapidMiner являются простота и удобство реализации экспериментов, так как от пользователя не требуется знание языков программирования, а блоковая структура процесса позволяет быстро внести изменения в процесс.

Для проведения экспериментов использовалась выборка данных, полученная от предприятия. Источниками данных являлись такие системы мониторинга, как системы контроля доступа, видеокамеры, измерительные системы, кроме того, имелись учетные таблицы о соответствии номеров пропусков фамилиям сотрудников и о соответствии фамилий водителей номерам управляемых ими транспортных средств. Выборка представляла собой две таблицы из БД. Таблица incident содержала данные о зафиксированных событиях, то есть являлась аналогом таблицы Common (рис. 1), таблица incident_attributes содержала наименования вариативных атрибутов и их значения, то есть являлась аналогом таблицы Variable (рис. 1).

Реализация данного алгоритма в среде RapidMiner показана на рисунке 4.

Операторы Read CSV используются для чтения исходных таблиц incident и incident_at­tributes.

После выбора необходимых атрибутов (incident_id, value, name) в блоке Select Attributes к таблице incident_attributes было применено преобразование Pivot, после чего преобразованная таблица была объединена (оператор Join) с таблицей incident по идентификатору инцидента incident_id. В результате получена общая таблица, состоящая из 5 493 строк, соот- ветствующих инцидентам, и 92 столбцов, соот- ветствующих атрибутам. В таблице представлены данные, описывающие разные типы событий, инициированные разными типами субъектов.

Далее был выполнен ряд операций, связанных с группировкой атрибутов. Сначала выбраны атрибуты (Select Attributes), имеющие общее смысловое значение, но записанные в разные столбцы общей таблицы. В некоторых случаях было осуществлено переименование атрибутов (Rename), а потом созданы новые атрибуты (Generate Attributes), при этом каждый из них представлял собой совокупность значений заданных атрибутов, имеющих общий смысл. После проведения этого этапа была получена таблица, число столбцов которой сократилось до 47.

Затем была проведена группировка записей об одном событии. Для этого таблица, полученная на предыдущем шаге, была подана на вход оператора Impute Missing Values. Внутри этого блока было задано использование таблицы соответствия номеров транспортных средств и фамилий водителей в качестве опорных данных для заполнения пропущенных значений атрибутов. С помощью оператора Filter Examples были произведены фильтрация записей, относящихся к исследуемому субъекту, и сортировка записей по идентификатору субъекта (Sort). Далее с помощью циклов Loop Values последовательно произведена сортировка (Sort) по зоне наблюдения и по времени совершения действия соответственно. Затем с помощью оператора Append объединены записи, удовлетворяющие условию одновременности.

В заключение были удалены изначально не несущие смысловой нагрузки атрибуты или атрибуты с общим смысловым значением, объединенные ранее в один общий атрибут (Remove Useless Attributes). После всех описанных этапов осуществлена запись итогового файла с помощью оператора Write CSV. Полученная таблица имела размерность 2 598 строк и 32 столбца.

Заключение

В данной работе рассмотрены основные проблемы анализа данных о мониторинге процессов с помощью разнородных систем мониторинга. Предложен подход к объединению данных от разных источников и их представлению в едином формате, удобном для дальнейшего анализа. Выделены критерии объединения записей от различных источников при описании одного и того же события. Показано, что предложенный подход помогает существенно снизить избыточность представления данных, а также снизить число пропущенных значений в совокупной таблице за счет объединения одинаковых по смыслу атрибутов и объединения записей, относящихся к одному событию. С помощью предложенного подхода может быть получена единая таблица, каждая строка которой наиболее полно описывает отдельно взятое событие. Такая таблица может быть проанализирована доступными методами интеллектуального анализа данных с целью выявления аномальных действий или грубых нарушений регламента.

Работа выполнена при финансовой поддержке Министерства образования и науки Российской Федерации в рамках государствен- ного задания «Организация научных исследований», задание № 2.6113.2017/6.7.

Литература

1.    Dumas M., La Rosa M., Mendling J., Rei- jers H. Fundamentals of business process management. Heidelberg: Springer, 2013, vol. 1, p. 2.

2.    Bastani K., Rao P.K., Kong Z. An online sparse estimation-based classification approach for real-time monitoring in advanced manufacturing processes from heterogeneous sensor data. IIE Transactions, 2016, vol. 48, no. 7, pp. 579–598. DOI: 10.1080/0740817X.2015.1122254.

3.    Кузнецов Д.П., Ржеуцкая С.Ю. Метод интеграции онтологий разнородных источников данных в АСУП // Вестн. Череповец. гос. ун-та. 2013. Т. 1. № 4. C. 51.

4.    Сапунов Н.О. Интеграция разнородных источников данных посредством xml Web-сервисов при организации управления транспортным процессом // Вестн. гос. ун-та морск. и реч. флота им. адм. С.О. Макарова. 2010. № 4. C. 8.

5.    Старожилец В.М., Чехович Ю.В. Комплексирование данных из разнородных источников в задачах моделирования транспортных потоков // Машинное обучение и анализ данных. 2016. Т. 2. № 3. С. 260–275. DOI: 10.21469/22233792.2.3.01.

6.    Dong C., Xiuquan Q., Gelernter J., Li Xiaofeng, Meng Luoming. Mining data correlation from multi-faceted sensor data in the Internet of Things. China Communications, 2011, vol. 8, no. 1, pp. 132–138.

7.    Mirheidari S.A., Arshad S., Jalili R. Alert correlation algorithms: a survey and taxonomy. Proc. 5th Intern. Symp. on Cyberspace Safety and Security (CSS 2013). LNCS, 2013, vol. 8300, pp. 183–197.

8.    Valdes A., Skinner K. An Approach to Sensor Correlation. Proc. of the Recent Advances in Intrusion Detection (RAID-2000), Touluse, 2000. URL: https://www.researchgate.net/profile/Alfonso_Valdes/publication/228523518_An_approach_to_sensor_correlation/links/56d4437d08ae868628b24ba8. pdf (дата обращения: 27.10.2018).

9.    Kholod I.I., Bekeneva Ya.A., Novikova E.S., Shorov A.V. Intellectual model for violations detection in the business process. In Young Researchers in Electrical and Electronic Engineering (EIConRus), Proc. IEEE Conf. of Russ., 2018, pp. 313–317. DOI: 10.1109/eiconrus.2018.8317095.

10. Bekeneva Ya.A., Lebedev S.I., Kholod I.I., Shorov A.V., Novikova E.S. Method for transformation of data from heterogeneous monitoring devices for violations detection. Proc. XXI Intern. Conf. (SCM), 2018, pp. 753–756.

11.  RapidMiner: Data Science Platform. URL: https://rapidminer.com/ (дата обращения: 27.10.2018).

References

1. Dumas M., La Rosa M., Mendling J., Reijers H. Fundamentals of Business Process Management. Heidelberg, Springer Publ., 2013, vol. 1, p. 2.
2. Bastani K., Rao P. K., Kong Z. An online sparse estimation-based classification approach for real-time monitoring in advanced manufacturing processes from heterogeneous sensor data. IIE Trans. 2016, vol. 48, no. 7, pp. 579–598. DOI: 10.1080/0740817X.2015.1122254.
3. Kuznetsov D.P., Rzheutskaya S.Yu. Method of integration of ontologies of heterogeneous data sources in automated control systems. Bulletin of Cherepovets State Univ. 2013, vol. 1, no. 4, p. 51 (in Russ.).
4. Sapunov N.O. Integration of heterogeneous data sources through xml Web services when organizing the management of the transport process. Bulletin of the State Univ. of Maritime and River Fleet n.a. Admiral S.O. Makarov. 2010, no. 4, p. 8 (in Russ.).
5. Starozhilets V.M., Chekhovich Yu.V. Integrating data from disparate sources in traffic flow modeling problems. Machine Learning and Data Analysis. 2016, vol. 2, no. 3, pp. 260–275 (in Russ.). DOI: 10.21469/22233792.2.3.01.
6. Dong C., Xiuquan Q., Gelernter J., Li Xiaofeng, Meng Luoming. Mining data correlation from multi-faceted sensor data in the Internet of Things. China Communications. 2011, vol. 8, no. 1, pp. 132–138.
7. Mirheidari S.A., Arshad S., Jalili R. Alert correlation algorithms: a survey and taxonomy. Proc. 5th Intern. Symp. on Cyberspace Safety and Security (CSS 2013). LNCS. 2013, vol. 8300, pp. 183–197.
8. Valdes A., Skinner K. An Approach to Sensor Correlation. Proc. of the Recent Advances in Intrusion Detection (RAID-2000). Toulouse, 2000. URL: https://www.researchgate.net/profile/Alfonso_Valdes/publication/228523518_An_approach_to_sensor_correlation/links/56d4437d08ae868628b24ba8.pdf (accessed October 27, 2018).
9. Kholod I.I., Bekeneva Ya.A., Novikova E.S., Shorov A.V. Intellectual model for violations detection in the business process. 2018 IEEE Conf. of Russ. Young Researchers in Electrical and Electronic Engineering (EIConRus), pp. 313–317 (in Russ.). DOI: 10.1109/eiconrus.2018.8317095.
10. Bekeneva Ya.A., Lebedev S.I., Kholod I.I., Shorov A.V., Novikova E.S. Method for transformation of data from heterogeneous monitoring devices for violations detection. Proc. 2018 21st Intern. Conf. on Soft Computing and Measurements (SCM). St. Petersburg, 2018, pp. 753–756 (in Russ.).
11. RapidMiner: Data Science Platform. URL: https://rapidminer.com/ (accessed October 27, 2018).