Industrial Big Data Analytics

Реализация построения хронологического описания работы станка на основе данных промышленного мониторинга для дальнейшего использования при поиске и прогнозировании предстоящих событий

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

Задача: перенести данные промышленного мониторинга в графовую СУБД:

1) Разработать графовую модель для хранения хронологии работы станка для платформы Neo4j на основе JSON-документов с описанием событий станка.

2) Реализовать алгоритм переноса данных из JSON-документов в графовую СУБД Neo4j

 

Условия реализации 

Для реализации поставленных задач использовать платформу с открытым исходным кодом neo4j  https://neo4j.com/

 

Наборы данных

Данные промышленного мониторинга работы станка Varia в формате JSON-документов pmz.tar.gz

 

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

 

Модели представления происходящих событий и окружающего контекста

Событийно-ориентированный подход позволяет определять и описывать явления, происходящие в системе. Более того, это позволяет конкретно описать требования на всех этапах разработки продукта для четкого понимания разработчиком минимальных затрат на разработку. Модель представления происходящих базовых событий в хранилище связанных данных предложена на рисунке 1. Модель описывает структуры JSON-документов.

Рисунок 1 — Модель представления базовых событий

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

Рисунок 2 — Пример JSON-документа с конфигурациями для сервиса детектирования человека

Представленный JSON-документ  состоит из таких параметров, как уникальный идентификатор, описание видеосервиса на русском языке, краткое название видеосервиса, тип сервиса, тип данных, количество видеокамер, использующихся в сервисе, количество кадров в секунду, количество ключевых кадров, параметры идентификации камеры, протокол передачи данных с видеопотока, локальные IP и MAC-адреса. Так же, описанные параметры имеют классификацию и иерархию. Параметры (1-9) являются системными, а также необходимы для сервисов в веб. Остальные параметры (10-28) необходимы на уровне обработки видеоданных конкретным модулем. Большинство описанных параметров являются обязательными, а именно: (10-14, 23, 24, 26). Параметры (15-20) являются обязательными в случае, если параметр (24) равен значению «rtsp». Параметры (27, 28) необходимы для корректного отображения потока в веб-интерфейсе.

Структура записи события представлена в соответствии с рисунком 3 в виде JSON-документа. Запись события включает такие параметры, как уникальный идентификатор события, отметка времени UNIX, тип зарегистрированного события, уровень важности, описание события для фото/видео, путь до фото/видео в ФС. Запись представлена для сервиса детектирования человека с нескольких видеокамер. Параметры являются обязательными для всех сервисов, однако данные в поле «data» могут меняться в зависимости от сервиса. Для сервиса детектирования это пути до изображений и видеозаписей в ФС.

Рисунок 3 — Представление события о распознавание человека в видеопотоке в виде JSON-документа

Модули чтения данных с датчиков используют хранилище связанных данных для получения настроек и сохранения ошибок работы программной части. Структура JSON-документа, описывающего настройки модулей чтения данных с датчиков приведена на рисунке 4. Каждый модуль имеет свои настройки, которые извлекаются с полей данного документа. При этом модуль осведомлен в названиях полей, которые ему необходимы. В полях «host» и «port» содержатся ip/mac адрес и порт для подключения к устройству сбора данных. В поле «settings» хранится динамически создаваемая структура настроек, которую модуль генерирует при запуске. Данная структура используется для настроек, которые получаются модулем от устройства сбора данных. Остальные поля меняются от модуля к модулю, это могут быть различные настройки, например, параметры подписки для получения сигнала с датчика, параметры обработки сигнала, тип фильтра и его параметры, точность подсчета числовых значений.

Рисунок 4 — Представление настроек для модуля чтения данных с датчиков в виде JSON-документа

Структура JSON-документа для хранения ошибок модулей чтения данных с датчиков приведена на рисунке 5. В поле «timestamp» содержится время события, в поле «type» тип события, в полях «сode» и «description» код ошибки и текстовое описание соответственно.

Рисунок 5 — Представление информации о ошибке для модуля чтения данных с датчиков в виде JSON-документа

В JSON-документе на рисунке 6 представлено отображение события изменения статуса работы вентилятора на основе показаний связанных модулей сбора данных с датчиков. В событие включены стандартные значения (уровень, отправитель, временная метка и тип) и данные связанных сервисов, (data/source) на основе которых был определен статус работы вентилятора. Для каждого связанного сервиса отражается его идентификатор (id/$oid), временная метка (timestamp) и тип события (type), а также содержание события (event). Например, модуль чтения данных с тахометра (id/$oid) создал событие с временной меткой 1591275402 указав частоту вращения 22, что было меньше предыдущей частоты (39) и меньше порогового значения статуса (30). Сохранение значений связанных событий продиктовано их малым сроком жизни (по умолчанию, 72 часа).

Рисунок 6 — Представление события изменения статуса работы вентилятора

Ожидаемый результат

Разработана графовая модель для хранения хронологии работы станка для платформы Neo4j на предоставляемых основе JSON-документов с описанием событий станка.

Реализован алгоритм переноса данных из JSON-документов в графовую СУБД Neo4j на основе разработанной модели.

Критерии оценки (0-24 балла)

  1. Модель хронологии работы станка: 8 баллов. 

  2. Время работы реализованного алгоритма составляет меньше 2 секунд: 4 балла.

  3. Процент автоматизации переноса данных (30-60% - 4 балла, 60-80% - 8 баллов, более 80% - 12 баллов).

 


Модератор: Петрина Оксана Борисовна, научный сотрудник, преподаватель Кафедры информатики и математического обеспечения ПетрГУ

Задание #5