Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет Бизнеса и Менеджмента

Выпускная квалификационная работа

по направлению подготовки Бизнес-Информатики

образовательная программа «Бизнес-Информатика»

?????????? ?????? ??????????????? ????????? ?????????????? ????????? ? ?????? ?????????????? ????????? ????????? ?????

Королев Даниил Александрович

Рецензент

к.т.н., доцент Дорофеев Алексей Николаевич

Научный руководитель

к.т.н., старший преподаватель

Ефремов Сергей Геннадьевич

Москва 2016



Оглавление

Введение

1. Обзор литературы

1.1 История и основные парадигмы

1.2 Модели взаимодействия интернета вещей

1.3 Основные проблемы интернета вещей

1.4 Архитектурные решения интернета вещей

1.5 Применение интернета вещей в разных областях

2. Исследование возможностей для интеграции модуля программируемых сценариев

2.1 Существующие интеграционные платформы

2.2 Поддерживаемые языки и библиотеки

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

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

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

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

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

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

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

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

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

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

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

Заключение

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



Введение

Предметная область

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

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

Способность оснащать подключением к сети даже самые маленькие устройства с относительно слабым процессором, памятью и энергозатратами, позволяет найти применение IoT почти в любой сфере деятельности. Системы с анализом внешней среды могут быть использованы, например, в экологическом мониторинге или градостроительстве. С другой стороны, IoT может быть использован не только для получения данных с устройств, но и для выполнения действий в физическом мире. Множество примеров может быть приведено в приложениях, где производить необходимо производить контроль температуры, влажности, света и других показателей. Другим важным способом применения IoT является расширение функционала домашней безопасности и «умных» домов. Одним из самых востребованных применений IoT является производство, в связи с чем появился термин «промлышенный интернет» [2]. С помощью интернета вещей также могут быть автоматизированы большинство стадий производства. Это снизит человеческий фактор, что приведет к меньшему количеству ошибок на производстве и, как следствие, к более качественному продукту и снижению затрат.

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

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

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

· Разработка стандартизированых мер безопасности, в частности, анонимизации;

· Устройства все больше проникают в нашу жизнь, затрагивая персональную информацию.

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

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

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

Актуальность

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

Рисунок 1. Упрощенная схема Интернета Вещей

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

Цель исследования

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

Задачи исследования

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

· Провести обзор и анализ решений в области взаимодействия устройств Интернета Вещей.

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

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

· Выявить необходимый набор технологий для разрабатываемого модуля.

· Разработать программный модуль.

Объект и предмет исследования

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

Методы исследования

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

· анализ литературы;

· изучение и обобщение отечественной и зарубежной практики;

· сравнение;

· теоретический анализ и синтез.

Научная новизна и практическая значимость результатов

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

Краткое описание структуры работы

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

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

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

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

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



1. Обзор литературы

1.1 История и основные парадигмы

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

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

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

1) общее понимание ситуации о пользователях и их устройствах;

2) архитектуру ПО, способную обрабатывать и передавать контекстно-зависимую информацию туда, где она будет релевантна;

3) аналитические инструменты Интернета Вещей, целью которых является автономность и умное поведение

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

Первый раз концепция, похожая на то, что сейчас называется Интернетом Вещей, была упомянута в 1991 г. ученым компании Xerox Марком Вайзером [3]. Он высказал идею о том, что в 21 веке специализированные программные продукты и устройства, подключенные проводами и радиоволнами, станут настолько вездесущими, что люди перестанут их замечать. Предсказание оказалось абсолютно верным. 8 лет спустя впервые был упомянут термин «Интернет Вещей» Кэвином Эштоном в 1999 г. в контексте управления цепями поставок [4]. Однако с прошествием времени использование этого термина расширилось и стало применяться для таких областей как здравоохранение, логистика и т.д. Области применения Интернета Вещей можно увидеть на Рисунке 2. Несмотря на то, что определение «вещей» изменилось с развитием технологий, основная цель осталась: научить компьютеры собирать и обрабатывать информацию без участия человека. Радикальной ступенью эволюции можно считать переход текущего интернета в сеть соединенных объектов, которые не только собирают информацию об окружающем мире (сенсоры), но и взаимодействуют с физическим миром (актуаторы), а также используют существующие стандарты интернета для предоставления сервисов для передачи информации, ее анализа и т.п. С развитием таких технологий, как Bluetooth, WiFi, радиочастотная идентификация, сервисы телефонии, Интернет Вещей становится чем-то более обозримым и трансформирует текущий статический интернет в полностью интегрированный Интернет Будущего. Революцией в интернете стала взаимосвязь между людьми, которая росла с огромной скоростью. Следующей такой революцией будет взаимосвязь между устройствами, с целью создания «умного пространства». Однако количество различных взаимосвязанных устройств только в 2011 году превысило количество людей на планете. На данный момент насчитывается около 9 миллиардов соединенных устройств и ожидается, что к 2020 году их будет около 20 миллиардов [5].

Рисунок 2. Применение Интернета вещей в различных областях.

1.2 Модели взаимодействия интернета вещей

С эксплуатационной точки зрения удобно рассматривать то, как устройства в IoT соединяются и «общаются» друг с другом, говоря о технических моделях взаимодействия. В Марте 2015 года IAB выпустили документ, описывающий рекомендуемую архитектуру для создания сети «умных» устройств (RFC 7452), в котором говорится о 4 основных моделях взаимодействия, используемых в Интернете Вещей, в рамках этой работы будут разобраны основные три из них. [6]

Первой из таких моделей является модель Устройство-Устройство. Модель Устройство-Устройство предполагает, что 2 или более устройств напрямую соединены друг к другу, нежели чем через сервер-посредник. Такие устройства могут быть соединены через различные типы сетей, включая IP или Интернет. Чаще всего такие устройства используют такие протоколы как Bluetooth, Z-Wave или ZigBee, для прямого соединения друг с другом. Эта модель схематично представлена на Рисунке 3.



Рисунок 3. Модель Устройство-Устройство

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

Следующей моделей является Устройство-Облако. В такой модели устройства IoT напрямую соединено с облачным сервисом. В таком подходе часто используется уже существующие механизмы соединения, как, например, Ethernet или WiFi, для подключения устройств к IP сети, которая в последствии подключается к облачному сервису. Пример такой архитектуры можно увидеть на Рисунке 4.

Рисунок 4. Модель Устройство-Облако

Эта модель уже используется несколькими крупными компаниями, работающими со сферой IoT, такими как Samsung и Nest Labs. [7] В случае второго, термостат передает данные в облачную базу данных, где данные используются для анализа использования энергии в доме. Также облачное соединение позволяет пользователю получить удаленный доступ к термостату через смартфон. Безусловно модель Устройство-Облако добавляет ценности конечному пользователю, расширяя возможность устройства с помощью технологий, предоставляемых IoT. Однако возникают проблемы совместимости при интеграции устройств, сделанных разными производителями.

Следующей моделью является Устройство-Шлюз. В этом случае устройство соединяется не напрямую с облачным сервисом, а через локальный шлюз, обычно находящийся в непосредственной близости от конечных. Модель изображена на Рисунке 5.

Рисунок 5. Модель Устройство-Шлюз

Не смотря на технологический аспект, использование той или иной модели в конечном итоге в значительной степени зависит от того, открыты или закрыты (proprietary) используемые в сети устройства. Главным преимуществом модели Устройство-Шлюз заключается в том, что она может обойти проприетарные ограничения соединения IoT устройств. Таким образом можно сказать, что взаимодействие устройств и открытость стандартов являются ключевыми соображениями при проектировании и разработке систем Интернета Вещей.



1.3 Основные проблемы интернета вещей

Проблема безопасности

С подключением все большего количества устройств к интернету возникает больше возможных уязвимостей с точки зрения безопасности. Плохо защищенные IoT устройства могут стать входными точками для кибераттак, предоставляя злоумышленникам возможность перепрограммировать устройство или давать сбои. Устройства, которые работают некорректно, также создают уязвимости в безопасности. Чтобы удержать цену на уровне конкуренции и вместить необходимый функционал в технологические ограничения, накладываемые размером и возможностью потребления ресурсов, производители должны с особой бережливостью подходить к проектированию и разработке функционала по информационной безопасности устройств [8] [9].

Проблема конфиденциальности

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

Проблема стандартов взаимодействия

В полностью совместимом окружении любое IoT устройство может соединиться с любым другим устройством или системой и обменяться любой информацией. На практике совместимость гораздо сложнее. Совместимость между устройствами и системами существует в разных степенях на разных слоях протокола связи. Также необходимо понимать, что полная совместимость каждого аспекта технического продукта не всегда осуществимы, необходима и/или желательна. Стандартизация и использование протоколов, описывающих подробности связи, находятся в центре обсуждения Интернета Вещей. [12]

1.4 Архитектурные решения интернета вещей

Для определения наиболее актуальных функциональных требований необходимо полностью рассмотреть предлагаемые в научном сообществе решения по инфраструктуре Интернета Вещей. В "Flexible Architecture for Internet of Things Utilizing an Local Manager" авторы описывают несколько решений по архитектуре Интернета Вещей, первое из которых является стандартом в большинстве инфраструктур [13].

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

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

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

Для понимания того, какие задачи должен решать программный модуль, необходимо рассмотреть то, как Интернет Вещей уже сейчас применяется в бизнесе, решение каких проблем с помощью модуля могло бы улучшить существующие продукты. Описание применения Интернета Вещей в различных сферах приведено в «Internet of Things (IoT): A vision, architectural elements, and future directions», by Jayavardhana Gubbi, Rajkumar Buyya, Slaven Marusic, Marimuthu Palaniswami [14]. Авторы утверждают, что применение может быть классифицировано по типу доступности сети, распространению, масштабу, разнородности, повторению, участию пользователя и воздействию. Применение было разделено на 4 сферы:

1. домашнее и персональное;

2. на предприятии;

3. вспомогательное;

4. передвижное.

1.5 Применение интернета вещей в разных областях

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

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

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

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

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

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

· основанный на данных с устройства Интернета вещей;

· основанный на данных из внешнего сервиса.

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

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

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

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

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

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

В книге «IoT-From Research and Innovation to Market Deployment» более подробно рассмотрены возможности использования IoT в различных сферах бизнеса, описаны существующие решения и ожидаемые разработки [15].

К 2020 году, по мнению авторов, ожидается больше развития в области телекоммуникаций среди и внутри городов, объединяя несколько городов в одну большую сеть. К 2025 году ожидается, что более 60% людей будут жить в черте городов, урбанизация как тренд безусловно влияла и еще больше повлияет на развитие сопутствующих технологий. Это приведет к развитию так называемых «Умных городов». Этот термин подразумевает такие особенности, как «Умная Экономика», «Умные здания», «Умный транспорт», «Умная энергия», «Умные телекоммуникации», «Умное планирование» «Умный гражданин» и «Умное управление». Всего ожидается около 40 умных городов по всему миру к 2025 году.

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

В Европе самой крупной инициативой по разработке умного города с использованием Интернета Вещей является SmartSantader project, разрабатываемый FP7. Этот проект нацелен на развертывание инфраструктуры интернета вещей, состоящей из тысяч устройств IoT, распределенных по многим городам (Сантандер, Гилфорд, Любек и Белград). Этот даст возможность одновременной разработки и оценке сервисов, а также различным исследовательским экспериментам, выполнение которых будет содействовать созданию среды умных городов.

«Умный город» можно определить, как город, в котором контролируются все аспекты его критических инфраструктур, таких как дороги, мосты, туннели, метро, телеком, ЖКХ, аэропорты и т.д. Слежение в режиме реального времени позволит предотвратить различные катастрофы, как природного, так и человеческого характера [16]. С использованием прогрессивных технологий по слежению и встроенных умных сенсоров появляется возможность собирать и анализировать данные в реальном времени, тем самым улучшая системы по принятию решений на городском уровне. Рассматривая долгосрочные перспективы, можно предположить, что в будущем системы и структуры будут сами следить за своим состоянием и при необходимости сами чинить неисправности в работе.

В контексте «умного города» можно выделить следующие научные направления:

· Создание алгоритмов и схем, необходимых для описания информации, собираемой разными сенсорами в разных приложениях для обмена информации между различными сервисами;

· Экономически выгодное развертывание и обслуживание таких распределенных систем;

· Обеспечение надежного чтения данных с большого количество сенсоров и их эффективная калибровка;

· Низкозатратные протоколы передачи данных и алгоритмы их обработки;

· Развертывание и интеграция IoT приложений.

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

Другим применением реальным IoT, описанным в книге, является применение Интернета Вещей в контексте «Умного Дома» и «Умного Здания». Возможность построение умных систем в рамках домашнего использования появилась благодаря развитию роли WiFi в домашнем использовании технологий. Все больше домов оснащены все большим количеством электронных устройств, подключенных к сети интернет, они становятся частью IP сети, в которую также входят мобильные устройства пользователей, создавая домашнюю сетевую среду, в рамках которой можно настроить автоматизацию многих рутинных процессов.

На сегодняшний день существует несколько организаций, занимающихся оснащением домов такой технологией, которая позволяет жильцам управлять всей домашней сетью с помощью одного устройства. Решения по большей части основаны следующих функциональных сферах: слежению за показателями окружающей среды, управлением электроэнергии, содействие жизни, комфорту и удобству. Эти решения базируются на открытых платформах, использующих сеть умных сенсоров, предоставляющих информацию о состоянии дома. Эти сенсоры следят за использованием электроэнергии, отоплением, вентиляцией и кондиционированием воздуха; освещением и безопасностью, а также другими ключевыми показателями окружающей среды. Информация, собранная с датчиков, обрабатывается и доступна пользователю через несколько медиумов: тач-устройство, мобильный телефон или вэб-браузер. Многие компании рассматривают такой вариант разработки платформ, включающих в себе автоматизацию с развлечением, слежением за здоровьем, отслеживанием потребления электроэнергии, а также беспроводным слежением за окружающей средой внутри и снаружи дома [17] [18].

На Рисунке 6 представлен один из примеров инфраструктуры использования IoT в домашних условиях.



Рисунок 6. Пример инфраструктуры IoT в домашних условиях.

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

· Устройство-сенсор в сети;

· Мобильный телефон, тач-скрин или вэб-браузер

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

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

Перспективным направлением использования Интернета Вещей также является концепция «Умной фабрики» и «Умного производства» [19]. IoT предоставит возможность соединить производство с еще большим количеством различных приложений автоматизации и контроля процессов, ранее недоступных ввиду технологических и инфраструктурных возможностей. Применение может варьироваться от подключения завода к «умной сети электроснабжения» до использования производственных возможностей как сервис (Production as a Service) или в целом предоставить больше подвижности и гибкости в производственных системах [20]. В этом смысле можно считать производственную систему одну из множества в IoT, где можно определить новую экосистему для более умного и автоматизированного производства.

Первым эволюционным шагом к общей «умной фабрике» можно определить предоставление доступа существующим заинтересованным в производстве лицам для того, чтобы они могли взаимодействовать с производственной системой, основанной на Интернете Вещей [21]. Этими заинтересованными лицами могут быть поставщики оборудования, поставщики логистических инструментов, а также лица, занимающиеся поддержкой производства. Сервисы и приложения завтрашнего дня не обязательно должны быть строго завязаны на физической инфраструктуре, а могут быть предоставлены на производство в качестве сервисов, интегрированных в реальный физический мир. По мнению авторов, ключевым элементом в концепции внедрения Интернета Вещей на производство является то, как мы управляем и обращаемся с элементами физического мира, в котором сенсоры, актуаторы и производство должны управляться таким же или хотя бы похожим способом, что и стандартные интерфейсы и технологии в сфере Интернета Вещей. Эти устройства впоследствии предоставляют свои сервисы в структурированном виде и могут быть оркестрированы и задействованы множеством приложений одновременно. Авторы выделяют следующие проблемы имплементации кибер-физических систем на производстве:

· Доступность;

· Сетевая интеграция;

· Совместимость физических систем

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

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

Далее стоит рассмотреть более «личный» вариант использования интегрированных умных устройств - «умной здоровье» [23]. На данный момент рынок устройств, следящих за здоровьем, можно охарактеризовать как состоящий из решений, основанных на конкретных приложениях, которые не взаимодействуют друг с другом и сделаны из различных архитектур. В перспективе Интернет Вещей в этой сфере может быть использован в клиническом лечении, где можно будет следить ненавязчиво следить за госпитализированными пациентами. Для это требуется, чтобы сенсоры собирали достаточную информацию о психологическом состоянии пациента, шлюзы доступа вместе с облачными технологиями анализировали и хранили информацию, а затем отправляли анализированные данные ухаживающему персоналу для последующего обзора и анализа. Эти методы улучшат качество заботы о таких пациентах с помощью постоянно слежения, а также снизят издержки ухода за пациентами, по причине того, что ухаживающему персоналу не нужно будет постоянно собирать информацию о психологическом состоянии пациента. Собирать информацию можно не только о психологическом состоянии, но и о физических показателях пациента в целом. Такая информация может быть полезна докторам для определения более точного диагноза и последующего формирования рекомендаций.

На Рисунке 7 изображена инфраструктура платформы «Умного здоровья».



Рисунок 7. Инфраструктура платформы «Умного Здоровья»

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

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

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

· Правила взаимодействия жестко заданы, поэтому невозможно выйти за рамки преконфигурированных сценариев;

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

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



2. Исследование возможностей для интеграции модуля программируемых сценариев

Разработка интеграционных платформ началась одновременно с исследованием и развитием Интернета Вещей. Это происходило по той причине, что сама концепция Интернета Вещей подразумевает их объединение и управление из одной точки, либо действиями человека, либо в ручном режиме. Основной проблемой при разработке платформ является масштабируемость устройств в сети [24]. Домашняя сеть может состоять из десятка устройств, а распределенная сеть на национальном уровне может содержать миллионы устройств. Необходимо разработать такую систему, которая позволила бы относительно легко производить масштабирование и получать и, или обрабатывать данные без замедления всего процесса. После получения данных система должна предоставить их на модулю, содержащему бизнес-правила, в котором есть 2 пути: «горячий путь» подразумевает анализ потоковых данных в реальном времени, а «холодный путь» передает данные на хранение для последующего анализа. Оба пути могут предоставить информацию конечному пользователю, у которого есть возможность наблюдать за устройства в сети. Эта информация также может быть полезна в качестве входных данных для алгоритмов машинного обучения для последующей разработки предиктивных алгоритмов, которые смогут нам предоставить знание о том, как информация может измениться в будущем, основываясь на текущих данных, а также принимать превентивные меры, в случае, если это необходимо.

Для подключения устройств к платформе нам необходим облачный шлюз доступа. Это не локальный шлюз доступа, описанный в предыдущих главах, к которому устройства подключаются напрямую через, например, радио модуль. Облачный шлюз обычно один и находится инфраструктурно близко к платформе, поэтому, если у устройств есть возможность передачи по IP (используется Ethernet или WiFI подключение), то можно подключить эти устройства напрямую. Если нет, то используется локальный шлюз доступа, который агрегирует все устройства в локальной сети, а затем отправляет их на облачный шлюз доступа. На Рисунке 8 приведена описанная архитектура, предлагаемая в документации IoT Hub.

Рисунок 8. Базовая архитектура IoT решения

Можно выделить 3 продукта на рынке облачных, которые являются наиболее популярными и развиваемыми на данный момент: «Azure IoT Hub», «Amazon AWS IoT» и IBM Bluemix IoT Foundation. Каждая из этих платформ позволяет регистрировать устройства в системе, подписываться на их события, отправлять им действия, получать своевременную аналитику со всех устройств в сети, предсказывать дальнейшее поведение с помощью алгоритмов, основанных на машинном обучении, а также в целом автоматизировать процесс взаимодействия устройств [25].

2.1 Существующие интеграционные платформы

IoT Hub новый сервис, предоставляемый в рамках набора сервисов Azure. Этот сервис предоставляет двустороннее взаимодействие между устройствами и облачной платформой. Канал связи является надежным и защищенным [26]. Аутентификация происходит отдельно для каждого устройства с помощью параметров доступа. На Рисунке 9 представлена IoT архитектура IoT Hub.

Рисунок 9. Архитектура IoT Hub

Благодаря двусторонней концепции взаимодействия сообщения между устройствами и облаком передаются в обоих направлениях по установленному каналу связи. Каждое устройства содержит 2 конечных точки для взаимодействия с IoT Hub:

· Устройство-Облако: устройство использует конечную точку для отправления сообщения в облако. Это может быть просто данные, собранные с сенсора, результат полученной команды или запрос на выполнение команды;

· Облако-Устройство: устройство получает команды по этой конечной точки для выполнения соответствующего действия.

С другой стороны IoT Hub тоже предоставляет 2 конечные точки:

· Облако-Устройство: платформа использует эту конечную точку для отправки сообщений (например, команд) устройствам. Это конечная точка реализована в виде очереди и у каждого сообщения есть TTL (Time to Live, время на жизнь), по истечению которого команда удаляется из очереди (система стремится к выполнению в реальном времени, поэтому устаревшие команды уже теряют актуальность). Платформа также может получить сообщение с подтверждением о том, что команда успешно дошла до устройства или наоборот, устройство не получило команду;

· Устройство-Облако: эта конечная точка используется для получения сообщений с устройств.

В IoT Hub присутствует Identity registry, в котором хранится информация о всех подключенных к платформе устройств. В нем не хранятся мета-данные устройств, а только необходимая информация для идентификации и аутентификации устройств в системе. Identity registry также предоставляет такую информацию, как текущий статус подключения и последнее время активности. У пользователя есть возможность включить/выключить взаимодействие с устройством. Также IoT Hub предоставляет отдельную точку доступа для управления устройствами в сети, в котором можно создавать, получать, изменять и удалять устройства, т.е. производить СRUD операции.

AWS IoT в целом преследует те же цели, но достигает их по-другому. На Рисунке 10 представлена архитектура сервисов AWS IoT [27].

Рисунок 10. Amazon AWS IoT.

Основной концепцией этой платформы является состояние устройства. Устройства докладывают о своем текущем состоянии путем публикации сообщений брокеру сообщений. Брокер передает конкретные сообщения всем подписчикам на соответствующую тему. Можно заметить, что такая модель отправки/подписки напоминает протокол MQTT, который и лежит в основе AWS IoT.

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

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

IBM Bluemix IoT Foundation похож архитектурой и основной идеей на Microsoft Azure IoT Hub. Отдельные устройства или локальные шлюзы доступа являются конечными участниками сети, принимая команды из платформы или просто собирая данные [29]. Далее данные уходят на платформу посредством протоколов MQTT или HTTP. После этого данные приходят на IBM Watson IoT Platform, в которой уже есть много различных сервисов для обработки и визуализации этих данных. Также платформа предоставляет REST и Real-Time API для подключения собственных сервисов к платформе. На Рисунке 11 представлена высокоуровневая архитектура IBM Bluemix IoT Foundation.



Рисунок 11. Высокоуровневая архитектура IoT решения от IBM

2.2 Поддерживаемые языки и библиотеки

Несмотря на то, что к IoT Hub можно подключиться напрямую, используя протоколы HTTP или AMQP), Microsoft также предоставляет разные SDK для разных языков программирования и платформ. Безусловно, т.к. IoT Hub разрабатывается Microsoft, они предоставляют .NET SDK, SDK для универсальной платформы Windows (UWP) и приложений для ОС Windows 10, включая ее IoT версию - Windows 10 IoT Core), а также SDK для Java и NodeJS. Большим плюсом платформы является поддержка языка C для устройств с небольшой языковой поддержкой, ввиду малых мощностей некоторых «вещей».