AWS IoT также поддерживает стандартные протоколы передачи данных, но Amazon еще предоставляет собственные SDK для упрощения жизни разработчиков. Во-первых, SDK для встроенного языка C, который является кросс-платформенным и может быть использован на различных операционных системах и оборудовании, даже на операционных системах реального времени. SDK добавляет еще один уровень абстракции для доступа к брокеру сообщений, относящихся к безопасности канала передачи; передачи данных, отправки и подписки на сообщения с помощью протокола MQTT, а также ко всем операциям, нацеленным получение/изменение данных о тенях: изменение, создание, удаление, чтение.

IBM Bluemix IoT тоже предоставляет доступ по MQTT и HTTP, имеет REST API. Существует библиотека для проведения CRUD (create, read, update, delete) операций над устройствами в сети для использования при программирования на языке Java. Также есть библиотека для NodeJS, распространяемая через npm (node package manager). По своей сути, эти библиотеки не несут в себе логики, а просто являются обертками над запросами к открытому API для упрощения разработки.

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

2.3 Безопасность и аутентификация

Соединение устройств и IoT Hub основано на TLS (Transport Layer Securiy, безопасность транспортного уровня). Таким образом все сообщения, посылаемые по каналу, зашифрованы, что гарантирует конфиденциальность данных. Сервис аутенифицируется благодаря собственному X.509 сертификату, который он отправляет на устройство во время TLS «рукопожатия».

Аутентификация между устройством и сервисом проходит благодаря «контролю доступа» и «параметрам доступа». В контроле доступа IoT Hub описывает набор разрешений для предоставления доступа ко всем открытым точкам доступа; эти разрешения относятся к реестру идентификации, доступному только для чтения, для чтения и записи, подключения к устройствам. Разрешения можно раздавать в рамках целого хаба (уже есть список заданных политик безопасности), или настраивать набор разрешений для каждого конкретного устройства в сети.

Аутентификация, предоставляемая IoT Hub, проверяется с помощью токена, отправленного с устройства. Как и большинство сервисов в Azure, токен является SAS токеном. Симметричные ключи шифрования, относящиеся к параметрам доступа конкретного устройства, никогда не посылаются по каналу связи.

AWS IoT тоже работает по протоколу безопасности транспортного уровня таким образом, что канал связи с брокером сообщений зашифрован и клиент (устройство или внешний сервис) аутентифицируется посредством взаимной аутентификации. Сертификаты для такой аутентификации могут быть созданы, активированы или выключены с помощью командной строки в консоли Amazon. AWS IoT не поддерживает идентификационных принципалов, основанных на сертификате, но поддерживает IAM сервис (пользователи, группы и роли), а также Amazon Cognito Service.

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

2.4 Протоколы соединения

На текущий момент AMQP 1.0 официально поддерживается всеми сервисами Azure, которые являются частью шлюза соединения. Microsoft сориентировался на этом протоколе для многих своих продуктов (будучи частью комитета по разработке стандарта) и решила использовать его в IoT Hub. Безусловно протокол HTTP тоже поддерживается, но AMQP более уместный в рамках IoT по причине того, что в HTTP нет реализации push сообщений на сервер, а модель поллинга неэффективна для задач Интернета Вещей.

MQTT версии 3.1.1 в данный момент является официально поддерживаемым протокол для AWS IoT, используемый брокером сообщений для публикации и подписки на сообщения, такая же ситуация и с IBM Bluemix.

2.5 Взаимодействие устройств

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

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

У IBM Bluemix IoT с этим дела обстоя лучше. Они предлагают встроенную в платформу решение - Nodered. Это инструмент для визуального построения пользовательских сценариев взаимодействия устройств в рамках интеграционной платформы IBM Bluemix. В NodeRed есть 3 основных типа элементов: входной узел, узел обработки, выходной узел. Входной узел слушает HTTP, MQTT или Websockets, а затем при получении сообщения передает информацию следующим узлам, подключённым к нему. Узлы обработки обрабатывает информацию каким-то образом. Это может быть выполнение кода обработки прямо на сервере, на котором стоит Nodered, отправка данных в аналитическую БД для их обработки и получение соответствующего ответа или отправка файла на один из сервисов IBM (например, IBM Visual Recognition для определения объектов на изображении). Выходные узлы отправляют данные во внешнюю систему и завершают выполнение. Внешней системой может быть База данных, другой сервис IBM или устройство, на которое отправляется команда для дальнейшего выполнения сценария. Этот инструментарий очень удобен для построение пользовательских сценариев взаимодействия, однако имеет ряд недостатков. Во-первых, даже при построении базового сценария придется писать код для обработку данных, приходящих с устройств, поэтому человек не знающий основ программирования, не сможет разработать даже базовый сценарий интеракции устройств. Во-вторых, несмотря на открытый исходный код, так как Nodered является частью IBM Bluemix, в нем существует возможность интеграции только с устройствами, зарегистрированными в системе IBM Bluemix, поэтому не получится подключить к сценарию устройства, например, зарегистрированные в платформе Azure IoT Hub. На рисунке 12 представлен графический интерфейс основного функционала Node-Red.

Рисунок 12. Графический интерфейс Node-RED

2.6 Сравнительный анализ интеграционных платформ

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

Первым критерием, выбранным для анализа, является возможность интеграции модуля в архитектуру платформы. Этот критерий является очень важным при выборе платформы, т.к. если возможность встраивания низкая или совершенно отсутствует, разрабатываемый модуль будет непригодным при использовании с конкретной платформой. Определим вес этого критерия в 0,4. В зависимости от архитектуры платформы удобство встраивания дополнительных модулей может различаться, особенно если эти модули тесно взаимодействуют с существующими модулями платформы. Разрабатываемый модуль полностью возьмет на себе функционал взаимодействия устройств, необходимо будет слушать события с устройств и посылать сообщения. Azure IoT Hub, как и IBM Bluemix, предоставляют прямой доступ к своим устройствам через широкий API, их архитектуры подразумевает шаблон подписки и публикации сообщений, поэтому оценка данного критерия для обоих платформ равна 10. В AWS IoT немного иная концепция обмена сообщений и контроля состоянием, для встраивания модуля в такую архитектуру потребуется написание отдельного модуля, специализированного под такую архитектуру, который будет неприменим для других платформ. Поэтому данный критерий для AWS IoT оценивается в 2.

Следующим критерием, выбранным для анализа, является возможность хостинга модуля вместе с платформой. Определим весь этого критерия в 0,1, т.к. поднять свой сервер для хостинга модуля не является трудным, единственным плюсом является уменьшение задержки отправки и получения сообщений, что может быть критично для желания достижения работы системы в реальном времени, но на данный момент в любом случае «горлышком бутылки» распределенных систем Интернета вещей является задержка в обмене сообщениями с самими устройствами. AWS IoT является частью стэка сервисов Amazon, который также предоставляет удобные сервисы для хостинга на тех же серверах. С Azure IoT такая же ситуация: для этих двух платформ данный критерий оценим в 10. IBM Bluemix довольно закрытая платформа, поэтому встроиться со своим модулем не предоставляется возможным, данный критерий оценим в 0.

Следующим критерием является возможность программной интеграции, т.е. доступность библиотек и SDK для разработки взаимодействия устройств. Этот критерий является довольно значимым, так как доступность технологий для разработки даст свободу выбора технологии и языка при программировании модуля. Обозначим вес для это критерия 0,2. В данном контексте все платформы предоставляют тот или иной доступ к управлению устройствами, однако только AWS IoT не предоставляет библиотек для доступа к устройствам на одном из самых популярных и кросс-платформенных языков JavaScript, что безусловно сужает возможности при разработке модуля под эту платформу, поэтому данный критерий оценим в 3 балла. Как уже было описано выше, IBM Bluemix предоставляет готовые библиотеки для взаимодействия на языках Java и JavaScript, а IoT Hub для платформы .NET и языка JavaScript, поэтому обе платформы оценим в 10 баллов.

Следующим критерием является стоимость использования платформы. Этот критерий не является критическим на данном этапе, но впоследствии, при развитии модуля и количества устройств, подключенных к нему, может сыграть важную роль. Определим вес данного критерия в 0,1. Чем меньше итоговая стоимость, тем выше будет балл критерия. На рисунке 13 представлена информация о ценовой политике Azure IoT Hub.

Рисунок 13. Стоимость Azure IoT Hub

До 8000 сообщений в день и их размере до 0,5 килобайт Azure IoT Hub является абсолютно бесплатным. Для домашнего использования в контексте «умного дома» такого количества и объема сообщений будет хватать сполна. 6 миллионов сообщений максимальным весом в 4 килобайта будет хватать для даже больших распределенных систем, $500 для таких систем справедливая цена. Поэтому оценим данный критерий для Azure IoT Hub в 7 баллов.

На рисунке 14 представлена информация о ценовой политике AWS IoT.

Рисунок 14. Стоимость Amazon AWS IoT

Первые 12 месяцев AWS IoT является бесплатным, а становится платным по тем квотам, обозначенным на рисунке. В эту стоимость не входит использование другие сервисов AWS, поэтому данный критерий оценим в 5 баллов.

В IBM Bluemix более гибкая ценовая политика. Можно настроить, сколько потребуется памяти, сообщений, вычислительных мощностей. Для самых базовых домашних операций система платформа будет бесплатна. Если приравнять мощности к тем, предлагаемых за $500 в IoT Hub, стоимость IBM Bluemix будет равняться $450, что даже меньше чем в IoT Hub. IBM Bluemix можно оценить в 10 баллов за гибкую ценовую политику и низкие цены.

Последним, но не менее важным критерием, можно выделить безопасность и защищенность протокола. Определим вес этого критерия в 0,2. Все платформы предоставляют современные меры защиты информации, о которых уже писалось выше, однако более удобный для разработки способ можно выделить у IBM Bluemix, подключение просто идет по токену и секретному ключу, что безусловно упрощает разработку. Поэтому IoT Hub и Amazon AWS оценим в 8 баллов, а IBM Bluemix в 10.

В таблице 1 приведены критерии и их соответствующие веса.

Таблица 1. Критерии и веса сравнительного анализа интеграционных платформ

Название	Возможность интеграции в архитектуру	Хостинг вместе с платформой	Удобство программной интеграции	Стоимость	Безопасность
Вес	0,4	0,1	0,2	0,1	0,2

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

Таблица 2. Результаты сравнительного анализа интеграционных платформ

	Возможность интеграции в архитектуру	Хостинг вместе с платформой	Удобство программной интеграции	Стоимость	Безопасность	Результат
IBM Bluemix	10	0	10	10	10	9
Azure IoT Hub	10	10	10	7	8	9,3
AWS IoT	2	10	3	5	10	4,9

Как видно из результатов проведенного анализа, наиболее предпочтительной для разработки платформой является Azure IoT Hub, следом за ней тесно идет IBM Bluemix. Разница между ними незначительна, поэтому разработку можно произвести под обе платформы, так как интерфейсы взаимодействия у них похожи, это не потребует дополнительной разработки. На данном этапе разработки по AWS IoT судя по результатам анализа является нецелесообразной, однако, в будущем, при развитии модуля, можно будет подключить и платформу AWS IoT.



3. Разработка модуля программируемых сценариев

3.1 Разработка требований к программному модулю

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

Разработка требований входит в структуру разработки технического задания, описанного в ГОСТ 34.003-90, однако следование данному ГОСТ не входит в рамки данный работы.

В требованиях к программному обеспечению выделяют 3 типа:

· Функциональные;

· Пользовательские;

· Бизнес-требования.

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

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

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

3.2 Формирование пользовательских требований

Существуют различные методы формирования и дальнейшего представления пользовательских требований в визуальном или текстовом виде. Проанализировав источники во второй главе, была собрана необходимая информация о возможных пользовательских сценариях использования программного обеспечения. Для их формализации, требования будут описаны по методологии Scrum, в которой таким образом описываются пользовательские истории [30]. Пользовательская история - это описание того, что разрабатываемый продукт должен делать для конечного пользователя в одном, максимум двух предложениях на повседневном или деловом языке. При написании пользовательских историй в основном следуют шаблону, состоящему из 3 частей:

1. Actor (актер, пользователь, использующий систему)

2. Action (каким образом, какое предпринимает действие)

3. Value (ценность, что он этим действием достигнет)

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

· Пользователь создает сценарий взаимодействия устройств и сервисов в своей сети Интернета Вещей;

· Пользователь следит за выполнением сценариев;

· Пользователь редактирует уже готовый сценарий;

· Пользователь удалить сценарий взаимодействия;

· Пользователь экспортирует сценарий/сценарии.

· Пользователь импортирует сценарий/сценарии.

3.3 Формирование функциональных требований

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

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

· Входной

· Промежуточный

· Выходной

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

Промежуточный узел необходим для обработки информации, пришедшей с предыдущих улов. Обработка может быть произведена как с помощью заданного участка кода, так и с помощью отправки на внешние сервисы. Безусловно необходимо определить заранее заданный список сервисов и реализовать с ними готовую интеграцию, чтобы пользователю требовалось минимальное количество лишних действий для получения желаемого результата. В рамках данной работы необходимо реализовать интеграцию с базовым сервисом по обработке данных, выбранных интеграционных платформ, а также выполнение заданного кода обработки пользователем. После этого обработанная информация передается всем узлам, в которые дальше идет граф после текущей вершины, это могут быть другие промежуточные узлы или выходной узел. Также промежуточный узел может представлять собой конструкцию «ЕСЛИ» для реализации алгоритмов ветвления. В случае если пришел набор данных X, сценарий должен перейти в по ребру x; если пришел набор данных Y, сценарий должен перейти по ребру y.

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

Перед сохранением сценарий должен провериться на правильность построение. Должны проверяться следующие правила:

· В сценарии есть хотя бы один входной узел;

· В сценарии есть хотя бы один выходной узел;

· Устройства, выбранные для входного и выходного узлов действительно существуют в интеграционных платформах;

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

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

После создания сценарий должен сохраниться на жестком диске сервера. У пользователя должна быть возможность получить все доступные ему сценарии.

Должна быть возможность редактировать уже существующие сценарии, а также их удалять.

Также необходимо реализовать функционал статуса сценария:

· Активный;

· Неактивный

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

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

У пользователя должна быть возможность экспортировать все или только выбранные сценарии. Это необходимо для нескольких сценариев:

· Для проведения операции по резервировании данных, чтобы настроенные сценарии не потерялись при сбоях системы;

· Для клонирования сценариев

Для реализации вышеописанных сценариев необходимо также реализовать функционал импорта, в рамках которого ПО принимает на вход экспортированные сценарии и полностью восстанавливает состояние системы до экспорта.

3.4 Выбор набора технологий для разработки

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

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

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

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

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

Выбор интеграционной платформы, обоснованный в предыдущей главе, накладывает определенные рамки на использование технологий. Это обусловлено тем, что, как уже было сказано в предыдущей главе, для интеграции с IBM Bluemix были выпущены библиотеки (SDK) на языках Java и JavaScript, а для Azure IoT Hub были выпущены библиотеки на платформе NET и JavaScript. На пересечении находится язык JavaScript. Безусловно, обе интеграционные платформы предоставляют доступ для интеграции через REST API, который полностью покрывает функционал библиотек, однако, написание собственных библиотек потребует дополнительной разработки и тестирования. А в случае, если API поменяется, то готовые библиотеки тоже будут обновлены, не потребуется переписывать код программы взаимодействия с платформами. Еще одним плюсом JavaScript является то, что он является кроссплатформенным и интерпретируемым, это значит, что может выполняться в режиме реального времени без необходимости компиляции. Также необходимо понимать, что JavaScript несмотря на свою популярность при разработке динамических вэб-страниц является не только языком для разработки в вэбе, а сейчас также используется при разработке десктопных и серверных приложений (десктопных при помощи технологии Electron, а серверных при помощи NodeJS). В случае разработки программного модуля, выберем технологию NodeJS, так как она позволяет не только быстро создавать прототипы серверных приложений с богатым выбором разнообразных библиотек, но и создавать крупные, стабильные Backend приложения с высокой производительностью, а также легко расширяемые. Приложение на NodeJS можно установить на любую операционную систему на реальной или виртуальной машине.

Для NodeJS существует удобных загрузчик программных зависимостей NPM (Node package manager) [31], через который будут загружены следующие пакеты, необходимые для разработки модуля программируемых сценариев:

· ibmiotf - небольшая клиентская библиотека, необходимая для подключения к IoT сервисам IBM Bluemix. Содержит необходимые методы для аутентификации, публикации сообщений, подписки на события с устройств, просмотр базовой информации о состоянии IoT платформы;

· passport-ibmid-oauth2 - небольшой пакет, позволяющий подключиться к IBM ID через протокол OAuth 2.0;

· azure-cli - пакет, предоставляющий интерфейс для доступа к управлению приложениями и сервисами в Microsoft Azure;

· azure-iothub - пакет, позволяющий настраивать взаимодействие с устройствами, зарегистрированными в IoT Hub: создавать/удалять/редактировать зарегистрированные устройства в IoT Hub, а также посылать на них сообщения и получать результат отправки этих сообщений;

· azure-iot-device - пакет, устанавливаемый на устройство в сети, для отправки и получения сообщений. Для удобной интеграции с Azure IoT разрабатываемый модуль будет зарегистрирован как устройство в распределенной сети;

· azure-storage - пакет, необходимый для интеграции с сервисами Microsoft Azure Storage Services. Он позволяет писать запросы к таблицам, взаимодействовать с файлами в хранилище, работать с Azure очередями.

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

3.5 Разработка сущностей программы

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

На Рисунке 15 изображена UML диаграмма классов, относящихся к описанию сценария в разрабатываемом модуле.

Рисунок 15. UML диаграмма классов сценария взаимодействия устройств

Для опиcания одного устройства была создана сущность Device, у которой есть уникальный идентификатор Id и название - Name. Уникальный идентификатор является идентификатором, используемым в платформе для упрощения взаимодействия устройств и отсутствия необходимости создания дополнительных свойств. Чтобы избежать повторения используемых идентификаторов в различных платформах, добавим к идентификатор префикс, соответствующий краткому названию интеграционной платформы. Таким образом мы сможем сразу определить в какой интеграционной платформе зарегистрировано данное устройство, а также обеспечим уникальность идентификатора в модуле, так как в рамках одной платформы идентификаторы будут точно уникальными. Имя загружается из интеграционной платформы. Если оно отсутствует, в этом поле дублируется значение идентификатора.

Следующей сущностью является Event, описывающее событие, пришедшее с устройства и на которое будет происходить подписка в начальном узле. Id генерируется самим модулем, с помощью средств NodeJS. DeviceId - устройства задается пользователем при создании сценария, это то устройство, на которое происходит подписка. EventType - тип сообщения, которое мы ожидаем от платформы. Этот тип зависит от конкретного устройства и платформы. Соответственно, можно создавать несколько сценариев, слушающие различные события с одного устройства. Time - время совершения события, необходимо для логгирования. IsProcessed - поле булевого типа, обозначающее одно из двух состояний события: было ли оно обработано или нет. Data - небольшой объект для хранения данных, пришедших вместе с событием. Взяв пример с датчиком температуры, в Data придет текущее значение температуры с датчика.

Ключевой сущностью является Node - эта сущность обозначает узел в сценарии взаимодействия. Безусловно у Node есть Id идентификатор, уникальный для модуля. За название, данное модулю пользователем, отвечает поле Name. У Node также есть поле NodeType, обозначающее тип этого узла. Это поле может быть одним из трех типов:

· Start - входной узел;

· Intermediate - промежуточный узел;

· End - выходной узел.

Также, в случае, если это промежуточный узел или выходной узел, у Node непустое поле PrevNode - ссылка на предыдущий узел.

В случае, если потребуется обработка данных или ветвление процесса выполнения, у сущности Node есть свойство Func, которое является функцией на языке JavaScript, которая выполнится, когда выполнение сценария перейдет к текущему узлу.

У Node может быть несколько следующих узлов, поэтому поле NextNodes является массивом. Если в поле Func не присутствует условия выбора следующего Node, то будет выбран первый узел из массива. Пришедшая в узел информация из предыдущего узла или из внешнего сервиса хранится в поле CurrentData - это любой JSON объект. В функции, в поле Func, можно использовать CurrentData.

Если текущий узел имеет тип Start, то у него есть ссылка на событие, по которому началось выполнение сценария. Это ссылка находится в поле IncomingEvent.

Если текущий узел имеет тип End, то у него есть ссылка на команду, которую следуют выполнить для завершения выполнения сценария. Эта ссылка находится в поле OutcomingEvent.

Обобщающей сущностью для сценария является Scenario. Как и у всех остальных сущностей, у этого объекта присутствуют поля Id и Name. Также у этого объекта есть ссылка на стартовый узел StartingNode, с которого начинается выполнение сценария. Как было заявлено при разработке требований, у сценария должен присутствовать статус. На данный момент у сценария есть поле Status, значением которого может быть одно из двух:

· Active, означающее, что текущий сценарий активен и событие в стартовом узле должно слушаться;

· Inactive, означающее, что текущий сценарий не активен и событие в стартовом узле НЕ должно слушаться.

3.6 Описание основных модулей программы

В программе присутствуют следующие основные модули:

· PlatformManager

· DeviceManager

· ScenariosManager

· ScenarioEngine

· ExportManager

· ImportManager

· LoggingManager

· BluemixConnectionManager

· AzureIotConnectionManager

· Repository

· SyncManager

· JSONWriter

Repository - инкапсулирует логику хранения и чтения данных с жесткого диска, а также доступ к скаченным с платформ данных об устройствах. Содержит основные методы для получения текущих настроек платформ и настроенных сценариев.

Данные, напрямую относящиеся к модулю программируемых сценариев, записываются и считываются в JSON файл, лежащий на жестком диске на сервере. Записью на жесткий диск занимается модуль JSONWriter, который вызывается модулем Repository.

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

SyncManager напрямую с платформами не общается, подключение к конкретным платформам делегируется соответствующими менеджерами подключения. В рамках этой работы были созданы 2 менеджера - BluemixConnectionManager и AzureIotConnectionManager, которые подключаются к IBM Bluemix и Azure IoT Hub соответственно. В BluemixConnectionManager используются библиотеки ibmiotf и passport-ibmid-oauth2, а в AzureIotConnectionManager - azure-cli, azure-iothub и azure-iot-device.

PlatformManager отвечает за CRUD (Создание, Чтение, Редактирование, Удаление) операции, связанные с платформами.

DeviceManager отвечает за CRUD операции, управление событиями и командами.

ScenariosManager - отвечает за CRUD операции над сценариев. Сценарий представляет собой JSON объект, состоящий из тех сущностей, что были рассмотрены в предыдущем разделе. При сохранении сценария происходит проверка на корректный порядок узлов (есть хотя бы один входной и узел и все ветки узлов сценария заканчиваются выходными узлами), корректность параметров устройств и платформ: у SyncManager запрашиваются актуальные данные об устройствах и платформах. Если все корректно, сценарий сохраняется. В случае ошибки, возвращается тип ошибки и небольшое сообщение с описанием. Также через этот модуль происходит выставление свойства Scenario Status.

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

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

Далее пытается выполниться функция, находящаяся в поле Func. После выполнения управление передается в NextNode. Если NextNode типа Intermediate алгоритм действий повторяется. Если NextNode типа End, выполняется команда, находящаяся в поле OutcomingAction. После ее завершения выполнение сценария заканчивается.

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

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

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



Заключение

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

Проанализировав существующие интеграционные платформы можно сделать вывод, что не все программные решения имеют готовые сервисы для реализации взаимодействия устройств. IBM Bluemix IoT Foundation имеет модуль NodeRed, позволяющий строить пользовательские сценарии взаимодействия, однако без навыков программирования человек не сможет построить даже самый базовый сценарий.

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

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

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

· Подключить к модулю AWS IoT и другие интеграционные IoT платформы.

· Публикация модуля в NPM, чтобы другие разработчики могли подключать модуль и использовать его в своих проектах.

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

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



Список использованной литературы

1. Internet of Things Global Standards Initiative [Электронный ресурс] / ITU -URL: http://www.itu.int/en/ITU-T/gsi/iot/Pages/default.aspx. (Дата обращения: 18.05.16).

2. Lee Jay, Bagheri Behrad; Kao, Hung-An (2015). "A cyber-physical systems architecture for industry 4.0-based manufacturing systems". Manufacturing Letters 3: 18-23.

3. Mark Weiser. Computer for the 21st Century. 1991, Mobile Computing and Communications Review, Volume 3, Number 3.

4. That 'Internet of Things' Thing [Электронный ресурс] / RFID Journal. - URL: http://www.rfidjournal.com/articles/view?4986. (Дата обращения: 18.05.16).

5. Gartner Says 6.4 Billion Connected "Things" Will Be in Use in 2016, Up 30 Percent From 2015 [Электронный ресурс] / Gartner. - URL: http://www.gartner.com/newsroom/id/3165317. (Дата обращения: 18.05.16).

6. Architectural Considerations in Smart Object Networking [Электронный ресурс] / Internet Architecture Board. - URL: https://tools.ietf.org/html/rfc7452 (Дата обращения: 18.05.16).

7. Samsung, Google Inc.'s Nest Labs Unveil `Thread' Network For Smart Homes [Электронный ресурс] / International Business Times. - http://www.ibtimes.com/samsung-google-incs-nest-labs-unveil-thread-network-smart-homes-1629204 (Дата обращения: 18.05.16).

8. Rolf H. Weber. Internet of things: Privacy issues revisited. Computer law & security review 31 (2015) 618-627

9. S. Sicari a, A. Rizzardi a, L.A. Grieco b, A. Coen-Porisini. Security, privacy and trust in Internet of Things: The road ahead. Computer Networks 76 (2015) 146-164

10. Lukas Malina, Jan Hajny, Radek Fujdiak, Jiri Hosek. On perspective of security and privacy-preserving solutions in the internet of things. Computer Networks 102 (2016) 83-95

11. Xavier Caron, Rachelle Bosua, Sean B. Maynard, Atif Ahmad. The Internet of Things (IoT) and its impact on individual privacy: An Australian perspective. Computer law & security review 32 (2016) 4-15

12. Sergey Efremov, Nikolay Pilipenko, Leonid Voskov. An Integrated Approach to Common Problems in the Internet of Things. Procedia Engineering 100 (2015) 1215 - 1223

13. Patrik Huss, Niklas Wigertz, Jingcheng Zhang, Allan Huynh, Qinzhong Ye and Shaofang Gong. Flexible Architecture for Internet of Things Utilizing an Local Manager. International Journal of Future Generation Communication and Networking Vol.7, No.1 2014, pp.235-248

14. Jayavardhana Gubbi, Rajkumar Buyya, Slaven Marusic, Marimuthu Palaniswami. Internet of Things (IoT): A vision, architectural elements, and future directions. Future Generation Computer Systems 29 (2013) pp: 1645-1660

15. Internet of Things - From Research and Innovation to Market Deployment. Dr. Ovidiu Vermesan, Dr. Peter Friess. 2014 River Publishers

16. Adnan Akbar, Francois Carrez, Klaus Moessner, Juan Sancho, Juan Rico. Context-Aware Stream Processing for Distributed IoT Applications. 10.1109/WF-IoT.2015.7389133 Conference: IEEE World Forum on Internet of Things 2015

17. Patrik Huss, Niklas Wigertz, Jingcheng Zhang, Allan Huynh, Qinzhong Ye and Shaofang Gong. Flexible Architecture for Internet of Things Utilizing an Local Manager. International Journal of Future Generation Communication and Networking Vol.7, No.1 2014, pp.235-248

18. Jatinder Singh, Thomas F. J.-M. Pasquier, Jean Bacon. Securing Tags to Control Information Flows within the Internet of Things. 2015 International Conference on Recent Advances in Internet of Things (RIoT). April 7, 2015 to April 9, 2015 pp: 1 - 6

19. Fadi Shrouf, Giovanni Miragliotta. Energy management based on Internet of Things: practices and framework for adoption in production management. Journal of Cleaner Production 100 (2015) 235e246

20. David R. Gnimpieba Z., Ahmed Nait-Sidi-Moha, David Durandb, Jerome Fortin. Using Internet of Things technologies for a collaborative supply chain: Application to tracking of pallets and containers. Procedia Computer Science 56 (2015) 550 - 557

21. Diana M. Segura Velandia, Navjot Kaur, William G. Whittow, Paul P. Conway, Andrew A. West . Towards industrial internet of things: Crankshaft monitoring, traceability and tracking using RFID. Robotics and Computer-Integrated Manufacturing 41 (2016) 66-77

22. Manuel Diмaz, Cristian Martiмn, Bartolomeм Rubio. State-of-the-art, challenges, and open issues in the integration of Internet of things and cloud computing. Journal of Network and Computer Applications 67 (2016) 99-117

23. A guide to healthcare IoT possibilities and obstacles [Электронный ресурс] / Search Health IT. - URL: http://searchhealthit.techtarget.com/essentialguide/A-guide-to-healthcare-IoT-possibilities-and-obstacles (Дата обращения: 18.05.16).

24. Bhumi Nakhuva, Prof. Tushar Champaneria. STUDY OF VARIOUS INTERNET OF THINGS PLATFORMS. International Journal of Computer Science & Engineering Survey (IJCSES) Vol.6, No.6, December 2015

25. Xiong Luoa, Ji Liua, Dandan Zhanga, Xiaohui Chang. A large-scale web QoS prediction scheme for the Industrial Internet of Things based on a kernel machine learning algorithm. Computer Networks 101 (2016) 81-89

26. Azure IoT Hub | Microsoft [Электронный ресурс] / Microsoft Azure. - URL: https://azure.microsoft.com/en-us/services/iot-hub/. (Дата обращения: 18.05.16).

27. How the AWS IoT Platform Works [Электронный ресурс] / Amazon Web Services. - URL: https://aws.amazon.com/iot/how-it-works/. (Дата обращения: 18.05.16).

28. IBM Bluemix - The cloud platform to accelerate innovation on both sides of the firewall [Электронный ресурс] / IBM Bluemix. - URL: http://www.ibm.com/cloud-computing/bluemix/. (Дата обращения: 18.05.16).

29. Node-RED [Электронный ресурс] / Node-RED - URL: http://nodered.org. (Дата обращения: 18.05.16).

30. Veli-Pekka Eloranta, Kai Koskimies, Tommi Mikkonen. Exploring ScrumBut--An empirical study of Scrum anti-patterns. Volume 74, June 2016, Pages 194-203

31. npmjs [Электронный ресурс] / Node Package Manager. - https://www.npmjs.com (Дата обращения: 18.05.16).

Размещено на Allbest.ru