Содержание к диссертации
Введение
Глава 1. Анализ проблемы обработки данных Интернета вещей 11
1.1 Концепция Интернета вещей 11
1.2 Архитектура Интернета вещей 14
1.3 Актуальные проблемы Интернета вещей
1.3.1 Управление электронным устройствами 15
1.3.2 Безопасность 16
1.3.3 Конфиденциальность 17
1.3.4 Обеспечение интероперабельности 17
1.4 Интероперабельность и подходы к ее реализации 18
1.4.1 Понятие интероперабельности 18
1.4.2 Подходы к реализации интероперабельности
1.5 Семантические веб технологии 25
1.6 Обеспечение интероперабельности в рамках Интернета вещей 27
1.7 Анализ существующих систем уровня поддержки услуг и приложений на основе семантических веб технологий 28
1.8 Анализ существующих онтологий для Интернета вещей
1.8.1 SSN - Semantic Sensor Networks 32
1.8.2 DogOnt - Ontology Modeling for Intelligent Domotic Environments 33
1.8.3 SAREF - The Smart Appliances Reference Ontology 34
1.8.4 IoT Lite Ontology 34
1.8.5 SensorML - Sensor Model Language
1.9 Требования к системе уровня поддержки приложений и услуг 36
1.10 Выводы по главе 1 36
Глава 2. Онтологическая модель и метод обработки гетерогенных данных электронных устройств 38
2.1 Постановка задач обработки данных гетерогенных электронных устройств
2.2 Разработка онтологической модели 39
2.2.1 О методологии разработки онтологической модели 39
2.2.2 Цель создания, область действия и язык описания онтологии 41
2.2.3 Предполагаемые конечные пользователи и сценарии применения онтологии 41
2.2.4 Нефункциональные и функциональные требования 42
2.2.5 Предварительный глоссарий терминов 44
2.2.6 Анализ существующих онтологий для переиспользования 44
2.2.7 Концептуализация онтологической модели 47
2.2.8 Верификация онтологической модели 58
2.3 Разработка метода и алгоритмов обработки гетерогенных данных электронных устройств 65
2.3.1 Метод обработки гетерогенных данных электронных устройств 65
2.3.2 Алгоритм аннотирования данных 67
2.3.3 Алгоритм деаннотирования данных 68
2.3.4 Алгоритм интеграции данных 71
2.3.5 Анализ алгоритмов метода обработки гетерогенных данных 72
2.4 Выводы по главе 2 72
Глава 3. Архитектура программной системы для сбора, обработки, хранения и публикации данных электронных устройств 74
3.1 Архитектура программной системы с разных точек зрения 74
3.1.1 О методологии описания архитектуры 74
3.1.2 Подсистемы и модули 75
3.1.3 Подсистемы и связи 78
3.1.4 Среда выполнения 79
3.1.5 Сценарии поведения 81
3.2 Базы данных для хранения данных электронных устройств 83
3.2.1 Хранение метаданных электронных устройств 84
3.2.2 Хранение временных данных электронных устройств 85
3.3 Прикладной программный интерфейс для доступа к данным электронных устройств и выполнения команд 87
3.3.1 Структура прикладного программного интерфейса 87
3.3.2 Типы операций поддерживаемых ресурсами прикладного программного интерфейса 89
3.3.3 Генерация описаний ресурсов и их операций 89
3.4 Методика адаптации программной системы для конкретной предметной области 91
3.4.1 Разработка драйвера электронного устройства 92
3.4.2 Разработка RDF-шаблонов для аннотирования данных электронных устройств 94
3.4.3 Создание конфигурационного файла для драйвера электронных устройств 95
3.5 Выводы по главе 3 97
Глава 4. Апробация программной системы для сбора, обработки, хранения и публикации данных электронных устройств 99
4.1 Цель и сценарий использования 99
4.2 Сценарий применения для обработки и анализа данных температуры в городе 99
4.3 Сценарий применения для автоматизации управления теплоснабжением зданий 100
4.4 Результаты апробации 101
4.5 Выводы по главе 4 103
Заключение 105
Список сокращений и условных обозначений 107
Словарь терминов 108
Список литературы
- Актуальные проблемы Интернета вещей
- Цель создания, область действия и язык описания онтологии
- Прикладной программный интерфейс для доступа к данным электронных устройств и выполнения команд
- Сценарий применения для автоматизации управления теплоснабжением зданий
Введение к работе
Актуальность темы. В настоящее время повышается доступность электронных устройств,в которые встроена поддержка перадачи данных по беспроводным или проводным сетям, а так же появляются новые протоколы идентификации и передачи данных, такие как IPv6, RFID, 6LoWPAN, ZigBeeи т.д., что привело к формированию и развитию концепции Интернета вещей. Возможность получать данные с различных устройств (начиная с бытовых приборов, заканчивая промышленным оборудованием) и управлять ими удаленно уже активно используется во всех видах производства и жизнедеятельности человека.
Например, растет интерес к использованию технологий Интернета вещей в различных областях, таких как сельское хозяйство, пищевая и перерабатывающая промышленность, экологический мониторинг, системы безопасности и многих других. Использование этих технологий позволяет городским и муниципальным органам получать информацию о состоянии окружающей среды (воздух и вода) и различных элементов городской инфраструктуры, тем самым даёт возможность прогнозировать ипринимать обоснованные решения для развития города.
К данному моменту существует большое количество разработок в области обеспечения взаимодействия с электронным устройствами на коммуникационном уровне, но на прикладном уровне, где различные устройства от разных производителей формируют небольшие и обособленные кластеры со своим набором форматов, моделей и стандартов, по прежнему существуют не решенные задачи. Одной из которых является отсутствие механизмов обеспечения семантической интероперабельности на уровне моделей и понятий, что затрудняет разработку информационных систем использующих разные типы и модели устройств от различных производителей.
В тоже время методы обеспечения интероперабельности на основе онтологического подхода уже доказали, что они могут стать инструментом для решения проблем синтаксической и семантической интероперабельности в гетерогенных средах, используя модель данных RDF1 и верхнеуровневые OWL-онтологии. Значительный вклад в разработку таких методов внесли российские и зарубежные ученые А.Ф. Тузовский, O. Corcho, K. Taylor, A. Zaslavsky, N. Noy, M. Krtzsch и другие.
Целью диссертационной работы является создание программных средств обеспечения семантической интероперабельности гетерогенных данных электронных устройств на уровне моделей и системы понятий в рамках концепции Интернета вещей.
1RDF (Resource Description Framework) – модель обмена данными, в рамках которой данные описываются тройками <субъект, предикат, объект>, где элементами являются ресурсы идентифицируемые с помощью URI (Uniform Resource Identifier).
2OWL (Web Ontology Language) – семейство языков представления знаний для создания онтологий.
Для достижения поставленной цели необходимо было решить следующие задачи:
-
Разработать онтологическую модель для виртуального представления электронных устройств на основе семантического описания их характеристик и способов взаимодействия.
-
Разработать метод и алгоритмы обработки гетерогенных данных электронных устройств на основе онтологического подхода.
-
Разработать архитектуру программной системы для сбора, обработки, хранения и публикации данных электронных устройств.
-
Разработать программное обеспечение для сбора, обработки, хранения и публикации данных электронных устройств на основе предложенных онтологической модели, метода и алгоритмов.
-
Провести апробацию разработанного программного обеспечения на реальных и модельных данных.
Объектом исследования являются программные средства сбора, обработки, хранения и публикации гетерогенных данных электронных устройств.
Предметом исследования являются методы и алгоритмы обеспечения семантической интероперабельности гетерогенных данных электронных устройств на основе онтологического подхода.
Методы исследования.Поставленные задачи решаются с использованием методов инжинирии программного обеспечения, методов онтологического инжиниринга, технологий построения веб-сервисов и семантических веб технологий.
Новые научные результаты, выносимые на защиту:
-
Предложена онтологическая модель для виртуального представления электронных устройств. Модель позволяет реализовать гибридный подход к интергации данных электронных устройств и обеспечивает полиномиальное время логического вывода при их обработке;
-
Предложен метод и алгоритмы обработки данных на основе онтологического подхода, обеспечивающие семантическую интероперабель-ность при работе с гетерогенными данными электронных устройств;
-
Предложена архитектура программной системы для сбора, обработки, хранения и публикации данных, обеспечивающая динамическое изменение спецификаций электронных устройств на уровне онтологической модели.
Теоретическая и практическая значимость. Теоретическая значимость результатов, полученных в данной диссертационной работе, заключается в совокупности онтологических моделей для виртуального представления электронных устройств, обеспечивающих переход на семантический уровень при обработке собираемых с устройств данных. Данный переход позволяет унифицировать доступ к данным электронных устройств за счет сокрытия их гетерогенной природы и предоставления возможности идентификации
устройств на основе их метаданных. Разработанные метод и алгоритмы совместно с существующими обеспечивают возможность семантической интерпретации данных при их использовании на уровне приложений. Практическая значимость результатов обуславливается:
-
закодированной с помощью подмножества языка RDF Schema и опубликованной в открытом доступе онтологической моделью для виртуального представления электронных устройств и их характеристик;
-
разработанным программным обеспечением для сбора, обработки, хранения и публикации данных электронных устройств, исходный код которого доступен под открытой лицензией.
Достоверность изложенных в работе выводов подтверждается результатами апробации разработанного программного обеспечения на реальных и модельных данных.
Внедрение результатов работы. Результаты диссертационной работы использовались при выполнении следующих научно-исследовательских работ: – «Разработка прототипа масштабируемой сервис-ориентированной программно-аппаратной платформы на основе беспроводных сенсорных и агентных сетей, технологий семантического веба и облачных вычислений в целях агрегации, нормализации, анализа и визуализации больших массивов неструктурированных данных в распределенной сети электронных гетерогенных структурированных, полуструктурированных и потребительских устройств (Internet of Things)» в рамках ФЦП «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2014–2020 годы», Соглашение № 14.575.21.0101 от 24 ноября 2014 г. – «Разработка методов и алгоритмов семантической интероперабельно-сти для интеграции и предоставления информации в системах семантического поиска и мониторинга» в рамках гранта Правительства Российской Федерации №074-U01. Кроме того, результаты работы были внедрены в учебный процесс на кафедре «Информатики и прикладной математики» Университета ИТМО в дисциплину «Методы онтологического инжиниринга».
Апробация работы. Основные результаты работы докладывались на международных и всероссийских научных конференциях и семинарах: Международный семинар «7th International Workshop on Semantic Sensor Networks» (Италия, Рива-дель-Гарда, 2014), Международная конференция «17th FRUCT conference» (Россия, Ярославль, 2015), Международная научная школа «4th ESWC Summer School» (Греция, Каламаки, 2014), Международная конференция «12th Extended Semantic Web Conference» (Словения, Порторож, 2015), Международная конференция «6th Knowledge Engineering and Semantic Web Conference» (Москва, Россия, 2015), Международная конференция «18th FRUCT conference» (Россия, Санкт-Петербург, 2016), Международный семи-5
нар «7th International Workshop on Web APIs and RESTful Design» (Швейцария, Лугано, 2016).
Личный вклад. Содержание диссертации и основные положения, выносимые на защиту, отражают персональный вклад автора в опубликованные работы. Из работ, выполненных в соавторстве, в диссертацию включены результаты, которые принадлежат лично автору.
Публикации. Основные результаты по теме диссертации изложены в 5 печатных изданиях [; ; ; 11; ], 2 из которых изданы в журналах, рекомендованных ВАК [; ], 3 — в сборниках докладов конференций, индексируемых в Scopus [; 11; ]. Также автором опубликовано 9 работ в журналах и сборниках докладов конференций, индексируемых в Scopus [; ; —; ; ]. Имеется свидетельство о государственной регистрации программы для ЭВМ № 2015660433.
Объем и структура работы. Диссертация состоит из введения, четырех глав, заключения и приложения. Полный объем диссертации - 152 страницы текста с 35 рисунками и 10 таблицами. Список литературы содержит 103 наименования.
Актуальные проблемы Интернета вещей
Подключая электронные устройства к сети Интернет, они наследуют все существующие проблемы обеспечения безопасности узлов сети, в добавок усложняя решения этих проблем из-за свойственных электронным устройствам ограничений [10; 98].
Электронные устройства более уязвимы к физическим атакам, так как небольшие устройство может быть нецелесообразно упаковывать в защищенный контейнер, а также к атаке на отказ в обслуживании, так как у таких устройств вычислительные и энергетические ресурсы могут быть сильно ограничены.
Кроме того из-за ограниченности ресурсов может быть не всегда целесообразно использование шифрования сообщений и авторизация входящих запросов. Поэтому к таким устройства, как правило, доступ происходит через шлюзы с менее ограниченными ресурсами [40].
Рост количества электронных устройств в домах, зданиях и офисах увеличивает количество данных, которые могут быть использованы для слежения за передвижениями и действиями людей, внезависимости от уровня аннонимности данных [92]. Например, с помощью аннонимных данных GPS-системы возможно вычисление места жительства и работы, а так же возможного заболевания, если окажется, что человек переодически бывает в лечебном учереждении [31]. Другим примером может быть использование данных счетчиков воды и электричества для определения наличия людей в квартире.
Необходимость обеспечения конфиденциальности данных, собираемых электронными устройствами, еще больше повышает важность обеспечения безопасности их передачи и контроль доступа.
Как известно, одной из характеристик Интернета вещей является гетерогенность электронных устройств, вызванная нестандартизованным, разнотипным набором применяемых технологий и протоколов передачи данных, а также моделей данных. Данная факт затрудняет развитие горизонтальных решений, работающих с электронным устройствами разных производителей и моделей. Решением данной проблемы является обеспечение интероперабельность.
Такая разнотипность технологий, протоколов, моделей и архитектур вызвана тем, что количество электронных устройств, услуг и приложений растет значительно быстрее чем компании производители и разработчики договориваются об использовании единых стандартов. Согласно исследованию [74] Европейского исследовательского кластер по Интернету вещей3 в ближайшее несколько лет в данной области будут преобладать стандарты, как правило, направленные на определенные предметные области, что будет затруднять горизонтальную интеграцию предметно-ориентированных решений. В том же отчете подчеркивается, что задача обеспечение интероперабельность является одной из ключевых для полноценной реализации концепции Интернета вещей.
Как правило, обеспечение интероперабельности реализуется на уровне поддержки услуг и приложений, и является одной из функций промежуточного программного обеспечения [19; 62].
Далее будет показано, как реализуется интероперабельность в существующем промежуточном программном обеспечения для Интернета вещей и как можно улучшить применяемые подходы.
В информационных системах сущности физического или виртуального мира описываются с помощью структурированных данных, называемых «метаданными» и представляющих собой характеристики этих сущностей для целей обработки информации о них. Основной целью взаимодействия информационных систем, будь то электронные устройств или комплексные программные системы, является обмен метаданными о некоторых сущностях.
Поэтому необходимым условием обеспечения интероперабельности между информационными система является интероперабельность метаданных сущностей, учавствующих во взаимодействии.
Haslhofer и Wolfgang определяют [43] интероперабельность метаданных следующим образом: «Интероперабельность метаданных - это качественное свойство метаданных информационных объектов, которое позволяет системам и прикладному программному обеспечению работать с или использовать эти объекты вне границ систем»4. Они же определяют три основных элемента, из которых строится модель метаданных: (а) язык описания схемы метаданных, (б) схема метаданных, определяющая элементы схемы, и (в) непосредственные значения метаданных, представляющие конкретные значения характеристик сущностей, например, значение размера в метрах, дата и время создание и т.п.
Понятие интероперабельности достаточно широкое и используется в различных областях, в случае информационных систем её можно разделить на два уровня: – На более низком уровне (уровень синтаксической интероперабельности) системы могут обмениваться и корректно обрабатывать метаданные друг друга. На рисунке 1.3 проиллюстрирована синтаксическая интероперабельность. Система А посылает сообщение системе Б о сущности ”Документ”, так как система Б способна обмениваться и обрабатывать метаданные от А, то она распознала в сообщение некоторую сущность, но не в состоянии найти ей соответствие в своем наборе сущностей без специализированного транслирующего модуля.
Цель создания, область действия и язык описания онтологии
За последнее время было предложено немало методологий разработки онтологий. Их общей целью является предложить некоторый инструмент, который мог бы помочь разработчикам онтологий избежать распространенных ошибок. Некоторые из таких распространенных ошибок описаны в работе M.Poveda и её соавторов [75].
Все из существующих методологий предлагают использовать так называемые «компетентностные вопросы» для того чтобы определить область применения онтологии и все детали данной области [42]. Как правило, компетентностные вопросы описываются в самом начале разработки онтологии и служат основой для дальнейших шагов, являясь функциональными требованиями к онтологии. По завершению разработки, компетентностные вопросы используются для оценки полноты разработанной онтологии. Онтология может считаться законченной, если она позволяет ответить на все такие вопросы. N.Noy и D.L.McGuinness в своей работе [68] сформулировали три базовых правила, которые применимы внезависимости от выбранной методологии:
– Не существует одного единственного правильного способа моделирования предметной области, всегда существуют жизнеспособные альтернативы. Наилучшее решение почти всегда зависит от его применения и тех расширений, которые ожидаются. – Разработка онтологий – это неизбежно итеративный процесс. – Концепты в онтологии должны быть как можно близки к объектам (физическим или логическим) и связям в рассматриваемой предметной области. Они наиболее вероятно являются существительными (объекты) и глаголами (связи) в предложениях, описывающих рассматриваемую предметную область. Наиболее популярными методологиями являются: METHONTOLOGY[34], Ono-Knowledge [51], DILIGENT [73]и NeOn [60].В рамках данной работы нами была использована методология NeOn, выбор которой обусловлен следующими заключениями: – является наиболее современной методологией, которая вбралав себя весь опыт, накопленный использованием более ранних методологий, – вотличиеотдругих учитывает наличие большого количества имеющихся онтологий и включает переиспользование существующих онтологий как один из возможных сценариев, – не задает жесткие ограничения на процесс разработки, а предлагает несколько сценариев разработки, которые выбираются в зависимости от входных требований. Согласно выбранной методологии, первым шагом разработки онтологии является описание спецификации требований, состоящей из нескольких пунктов, которые заполняются последовательно, выполняя следующие задачи: 1. Идентификация цели, области действия и языка описания онтологии (см. раздел 2.2.2), 2. Идентификация предполагаемых конечных пользователей (см. раздел 2.2.3), 3. Идентификация предполагаемых сценарии применения (см. раздел 2.2.3), 4. Идентификация функциональных и нефункциональных требований (см. раздел 2.2.4), 5. Группирование функциональных требований (компетентносных вопросов) (см. раздел 2.2.4), 6. Валидация требований (см. раздел 2.2.4), 7. Приоритезация требований (см. раздел 2.2.4), 8. Извлечение терминологии и ее частоты (см. раздел 2.2.5). Следующим после спецификации требований шагом является обзор существующих (онтологий, тезариусов, словарей и т.д.) онтологических (в формате RDFS или OWL) и не онтологических ресурсов (не в формате RDFS или OWL) для переиспользования в разрабатываемой модели. Результаты данного шага описаны в разделе 2.2.6.
После того как сформулированы требования и определены ресурсы, которые будут переиспользованы полностью или частично в новой моделе, выполняется непосредственное структурирование или кодирование модели на языке RDFS или OWL. Результаты данного шага описаны в разделе
Целью разработки онтологии является создание общей онтологии для виртуального представления электронных устройств и моделирования их данных, которые обрабатываются системой уровня поддержки приложений и услуг.
Онтология должна предоставлять возможность моделировать: (а) структуру электронного устройство, а именно имеющиеся подсистемы; (б) измеряемые сенсорами явления, а также их показания; (в) управляемые актуаторами объекты; (г) способы доступа к показаниям сенсоров и способы отправки управляющих команд по средствам протоколов передачи данных; (д) нефункциональные характеристики, такие как название, имя производителя, описание и другие;
Для описания онтологии должны быть использованы языки описания RDF схем – RDF Schema (RDFS) или язык описания онтология – Web Ontology Language (OWL).
Для данной онтологии выделяются несколько групп предполагаемых пользователей: – Пользователь 1: разработчик системы обработки гетерогенных данных электронных устройств, в которой полностью или частично переиспользуется архитектура программной системы, предложенная в данной диссертационной работе; – Пользователь 2: разработчик приложений, использующих прикладной программный интерфейс системы обработки гетерогенных данных электронных устройств; – Пользователь 3: разработчик драйверов электронных устройств, обеспечивающих сбор и нормализацию данных электронных устройств. А в качестве предполагаемых сценариев применения онтологии выступают следующие сценарии: – Сценарий 1: Обработка данных описанных данной онтологической моделью с целью реализации сервисов для уровня приложений. Выполняется Пользователем 1. – Сценарий 2: Взаимодействие с прикладным программным интерфейсом для доступа к данным электронных устройств и отправки управляющих команд. Выполняется Пользователем 2. – Сценарий 3: Моделирование электронных устройств, их характеристик и способов взаимодействия. Выполняется Пользователем 3.
Согласно методологии NeOn функциональными требованиями являются требования к концептам разрабатываемой онтологии, которые записываются в виде компетентностных вопросов и их ответов. Вопросы разбиваются на группы, каждой из которых может быть установлены некоторый приоритет. Все остальные требования являются нефункциональными.
Прикладной программный интерфейс для доступа к данным электронных устройств и выполнения команд
Для того чтобы определить какие значения может принимать параметр, какое у него значение по-умолчанию и т.д., необходимо дополнительно описывать эти параметры. Для этой задачи решено использовать существующую онтологию под названием Shape Constraint Language (SHACL)8. Онтология SHACL позволяет моделировать ограничения и ожидаемую структуру RDF-датасета.
Концепты, предложенные в данном модуле, могут быть расширены для следующих целей: – Для уточнения типа процесса. Например, в случае со стиральной машиной, может быть выделено несколько типов процессов: стирка, ополаскивание и т.д. В случае с погодной станцией, можно выделить процессы измерения температуры и влажности. – Для уточнения типа команды. Например, можно выделить команды запускающие и останавливающие процесс, а так же команды, которые изменяют только параметры процесса. Это только некоторые из возможных примеров того как концепты данного модуля могут быть расширены для моделирования электронных устройств.
Модуль описания интерфейса доступа к данным и отправки управляющих команд Для описания прикладного программного интерфейса доступа внешних информационных систем к данным электронных устройств и отправки управляющих команд, переиспользуется онтология Hydra Core9. Основные концепты онтологии изображены на рисунке 2.6.
Класс hydra:ApiDocumentation используется для моделирования документации данного интерфейса. Документация может включать следующее: – точка входа, т.е. корневой ресурс, от которого клиент должен начинать навигацию по интерфейсу; – классы ресурсов (подклассы класса hydra:Resource) и их свойства (подклассы класса rdf:Property), к которым предоставляется доступ через данный интерфейс; – операции доступные для выполнения над ресурсами интерфейса (подклассы класса hydra:Operation). Для протокола HTTP операции соответствуют HTTP-глаголам GET, POST, PUT, DELETE и другим; – и т.д.
Кроме того, онтология позволяет моделировать коллекции ресурсов (класс hydra:Collection), связи между ресурсами (класс hydra:Link), ошибок, которые могут возникать во время выполнения запросов, (класс hydra:Error) и т.д. Все перечисленные концепты данной онтологии будут переиспользованы в онтологии SemIoT. Более подробно онтология Hydra Core описана в работе [56] и в спецификации10 рабочей группы.
В рамках данной работы были разработаны расширения онтологии Hydra Core концептами необходимые для следующих целей: – Спецификация фильтров над коллекцией ресурсов. На данный момент, онтология Hydra Core не включается концепты для описания фильтров доступных для данной коллекции. – Спецификация интерфейса, работающего по шаблону ”издатель-подписчик”. Такой интерфейс может быть использован для асинхронного доступа к данным электронных устройств, когда обмен данными инициируется сервером, а не клиентом. Например для подписки на новые показания датчика температуры и т.п.
Для спецификации фильтров коллекций было добавлено несколько концептов, объединенных в отдельную онтологию Hydra Filter. Префиксом данной онтологии стал hydra-filter, а URI - https://w3id.org/ semiot/ontologies/hydra/filter#. Концепты данной онтологии представлены на рисунке 2.7.
Фильтр определяется спецификацией подмножества данной коллекции, такие спецификации подмножества моделируются с помощью класса hydra-filter:ViewTemplate, на которые оригинальная коллекция ссылается через свойство hydra-filter:viewTemplate. Каждая такая спецификация подмножества определяется шаблон URL-адреса, по которому, согласно спецификации Hydra, необходимо выполнить GET-запрос для получения данного подмножества. Каждое подмножество, полученное по такому GET-запросу, ссылается на оригинальную коллекцию через свойство hydra-filter:viewOf.
Для описания спецификации подмножества вводятся следующие концепты: hydra-filter:DirectMapping, hydra-filter:greaterOrEquals, hydra-filter:lessOrEquals, hydra-filter:comparator. Класс hydra-filter:DirectMapping указывает на соответствие данному фильтру некоторому свойству ресурсов коллекции, по котором и будет осуществляться фильтрация. Свойство hydra-filter:comparator определяет метод сравнения значения свойства ресурса и значения, по
Аналогично объединены в отдельную онтологию Hydra PubSub концепты для спецификации интерфейса ”издатель-подписчик”. Префиксом данной онтологии стал hydra-pubsub, а URI - https://w3id.org/semiot/ ontologies/hydra/pubsub#. Концепты данной онтологии представлены на рисунке 2.8.
Интерфейс определяет новую операцию, по средствам подкласса hydra-pubsub:SubscribeOperation класса hydra:Operation, которая описывает параметры подписки. Для данной операции введены четыре свойства: – hydra-pubsub:endpoint - адрес брокера, отвечающего за передачу сообщений от издателя к подписчикам и обратно, – hydra-pubsub:protocol - прикладной протокол, по которому осуществляет передача сообщений, Рисунок 2.8 — Концепты онтологии Hydra PubSub – hydra-pubsub:publishes - класс, к которому относятся передаваемые сообщения. Например, ssn:Observation является показаниям некоторого датчика. – hydra-pubsub:topic - идентификатор канала, по которому передаются данный тип сообщений. В результате переиспользования онтологии Hydra Core и её расширении, возможно предоставление такого прикладного программного интерфейса, через который можно получить как сами данные, так и метаданные необходимые для динамической идентификации данных и динамического определения доступных операций над ресурсами. 2.2.8 Верификация онтологической модели О методе верификации онтологической модели
Метод верификации онтологической модели заключается в переписывании компетентностных вопросов в запросы на языке запросов SPARQL, которые в последствии выполняются над данными аннотированными проверяемой онтологической модели.
Оценка соответствия онтологической модели каждому из требований включает следующие шаги: – подготовка RDF-датасета, содержащего описание электронного устройства; – запись компетентносного вопроса в виде SPARQL-запроса; – выполнение данного SPARQL-запроса и сравнение его результатов с ожидаемыми. В качестве RDF-датасета использовался датасет собранный из листингов с описаниями электронных устройств и их данных, представленные в Приложении А. А также для требований ГФТ3 используются описания из листингов Приложения Б. Оценка соответствия онтологической модели функциональным требованиям Первая группа функциональных требований (ГФТ1) включает два компетентностных вопроса.
Компетентностный вопрос ФТ11 ”Найти все электронные устройства”был записан в виде SPARQL-запроса, запрос приведен в листинге 2.2. Согласно требованию ФТ11, в результате выполнения данного запроса должен вернутся результат со списком URI-адресов электронных устройств, а так как RDF-датасет содержит описание только одного устройства, то список должен включать только его.
Сценарий применения для автоматизации управления теплоснабжением зданий
В данном разделе описано несколько ключевых сценария поведения программной системы ”SemIoT Platform”: – регистрация нового электронного устройства в программной системе, – передача сообщений процессов или результатов выполнения команд от электронного устройства к внешним клиентам, – отправка команды для управления процессами электронного устройства. Регистрация нового электронного устройства в программной системе проиллюстрировано с помощью диаграммы последовательности представленной на рисунке 3.4. Регистрация начинается с обнаружения драйвером электронного устройства (на диаграмме он назван Device Driver A) нового устройства, который далее собирает информацию об этом устройстве, нормализует эту информацию в соответствии с алгоритмом нормализации и передает её в подсистему Device Proxy Service. После чего эта подсистема аннотирует данные в соответствии с RDF-шаблоном, предоставленным драйвером, отправляет данные в базу данных RDF Database, а также публикует эти данные в брокере сообщений Message Broker. Брокер сообщений, в свою очередь, передает данные в базу данных через TSDB Service для подписки на сообщения этого устройства и передает всем внешним клиентам, которые подписаны на уведомления о регистрации новых устройств.
Передача данных от электронного устройства к внешним клиентам проиллюстрирована с помощью диаграммы последовательности представленой на рисунке 3.5.
Передача данных начинается сполучения сообщения драйвером устройства (на диаграмме он назван Device Driver A), который выполняет нормализацию этих данных в формат ”ключ-значение” и передает сообщение в подсистему Device Proxy Service. Далее эта подсистема выполняет аннотирование данных с помощью RDF-шаблонов предоставляемых драйвером устройства, выполняет алгоритм интеграции данных и публикует в специальный ”топик” обработанное сообщение в брокере сообщений. И в заключении сообщение получают все подписчики данного топика, одним из которых является Рисунок 3.4 — Диаграмма последовательность вызовов для регистрации нового электронного устройства подсистема TSDB Service, а также внешние клиенты, подписанные на сообщения данного электронного устройства.
Команды отправляются внешними клиентами (на диаграмме - External Client) и отправка команды для него реализуется в синхронном режиме, т.е. TCP-соединение будет открыто до тех пор пока команда не выполнится электронным устройством. Клиент формирует RDF-сообщение в соответствии со структурой требуемой прикладным интерфейсов программирования программной системы и отправляет его HTTP-запросом. Сообщение получает подсистемаAPI Gateway ServiceипередаетегоподсистемеDevice Proxy Service. Далее выполняется алгоритм интеграции данных, который приводит RDF-сообщение в соответствие с концептами общей онтологии, и после чего сообщение деаннотируется в формат ”ключ-значение” на основе RDF-шаблонов, предоставляемых драйвером. И на последнем этапе сообщение валидируется драйвером и отправляется на выполнение электронному устройству. Если во время валидации обнаруживается ошибка или электронное устройство, для которого предназначена данная команда, то обратно по той же цепочке передается сообщение об ошибке внешнему клиенту. Аналогично в случае ошибки во время отправки на выполнение электронному устройству, внешнему клиенту передается сообщением об ошибке. Если же отправка и выполнение команды прошло без ошибок, то внешнему клиенту возвращается результат выполнения команды.
В случае успешного выполнения команды подсистема Device Proxy Service формирует RDF-сообщение о результате выполнения команды и публикует еговброкере сообщений. Это сообщение записываетсявбазу данных и отправляется внешним клиентам, которые подписаны на результаты выполнения команд данным электронным устройством.
Архитектура программной системы ”SemIoT Platform” подразумевает разделение всех хранимых данных на два типа: Рисунок 3.6 — Диаграмма последовательности для обработки команды – метаданные электронных устройств, которые описывают их компоненты, и процессы и команды, ими реализованные, – временные данные электронных устройство, которыми являются выходные сообщения процессов и результаты выполнения команд. Так как второй тип данных отличается тем, что записывать в базу данных их необходимо чаще и запросы для них нужны специальные, то было принято решение хранить их в разных база данных.
Одной из проблем RDF-модели является задача удаления данных, так как в общем случае сложно идентифицировать подграф только по URI-адресу субъекта и не удалить триплы, которые используются в других подграфах. Примером такой задача является метаданных всех электронных устройств, относящихся к некоторому драйверу. Решить эту проблему можно с помощью именованных графов, то есть если метаданных устройств для каждого драйвера хранить в отдельном именованном графе, то для удаления метаданных всех устройство достаточно удалить соответствующий именованный граф.
Во многих предметных областях необходимо знать расположения и выполнять поиск электронных устройств по их геокоординатам. Стандартные возможности языка запросов SPARQL не предоставляют необходимые конструкции, например, для поиска ближайших геоточек в некотором радиусе от заданной точки и т.п. Поэтому необходимо использовать расширение языка SPARQL, например, GeoSPARQL9, для использования специализированных функции поиска.
Временные данные электронных устройств - это сообщения, которые привязанны к некоторой дате и времени. Такими сообщениями являются выходные сообщения процессов, например, измерения температуры ивлажности, и результаты выполнения команд, например, включить свет.
Как было продемонстрировано в работе Stocker M. и соавтр. [33], существующие RDF-базы данных неоптимизированы для хранение временных данных, что вызвано значительным ростом времени выполнения запросов с ростом количества таких данных. Поэтому было принято решение использовать базу данных Apache Cassandra10, так как она реализует гибкую модель хранения данных и позволяет реализовать функции для поиска по временным данным.
Для того чтобы разработать структуру базы данных были: сформулированы типовые запросы к базе данных; и описаны наборы полей, в которые будут записываться RDF-сообщения.