Применение интернета вещей в разных областях - Разработка модуля программируемых сценариев взаимодействия устройств в рамках интеграционной платформы интернета вещей

Домашнее использование чаще всего представляет из себя набор сенсоров, собирающих информацию об индивидах, которые напрямую владеют этой сетью. Это могут быть сенсоры в масштабах квартиры, собирающие информацию о данных внутри помещения, или носимые датчики, собирающие показатели жизнедеятельности человека, которые соединяются со смартфоном по 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 элемента напрямую с помощью разных протоколов и технологий подключаются к локальному шлюзу доступа, у которого есть набор интерфейсов для соединения с каждым из устройств сети, базовое ПО для первичной обработки и анализа данных, а также модуль соединения с платформой.

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

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

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

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

Похожие статьи