для работы каких устройств интернета вещей характерно использование облачных технологий
Что такое IoT и что о нем следует знать
Интернет вещей (Internet of Things, IoT) — это множество физических объектов, подключенных к интернету и обменивающихся данными. Концепция IoT может существенно улучшить многие сферы нашей жизни и помочь нам в создании более удобного, умного и безопасного мира. Примеры Интернета вещей варьируются от носимых вещей, таких как умные часы, до умного дома, который умеет, например, контролировать и автоматически менять степень освещения и отопления. Также ярким примером служит так называемая концепция умного предприятия (Smart Factory), которое контролирует промышленное оборудование и ищет проблемные места, а затем перестраивается так, чтобы не допустить поломок. Интернет вещей занимает важное место в процессе цифровой трансформации в компаниях. Прогнозируется, что к 2030 году количество подключенных к сети устройств вырастет примерно до 24 млрд с годовой выручкой до 1,5 трлн долларов.
История происхождения
Термин «Интернет вещей» был впервые употреблен в 1999 году Кевином Эштоном, предпринимателем и соучредителем центра Auto-ID Labs (независимая сеть лабораторий и исследовательская группа в области сетевой радиочастотной идентификации и новых сенсорных технологий) при Массачусетском технологическом институте. Эштон состоял в команде, которая сумела изобрести способ подключения объектов к интернету с при помощи технологии RFID. RFID-метка — это метка идентификации, позволяющая идентифицировать объекты посредством радиосигналов; на нее можно нанести определенную информацию, а позднее считать устройством.
В 2012 году произошли значительные изменения датчиков, что привело к ускорению рыночной готовности IoT, и для многих компаний это означало, что цифровая трансформация набирает обороты. Технологическое совершенствование сделало возможным появление МЭМС — микроэлектромеханических систем (миниатюрное устройство, изготовленное методом микрообработки как из механических, так и из электрических компонентов). Благодаря этому датчики уменьшились настолько, что их стало возможно фиксировать, например, на одежде.
История развития IoT. Источник изображения: https://www.avsystem.com/blog/what-is-internet-of-things-explanation/
Из чего состоит IoT? Архитектура
Для простоты попробуем разбить стек технологий IoT на четыре технологических уровня и рассмотреть их раздельно.
Конечные устройства
Устройства — это объекты, которые фактически образуют «вещи» (Things) в Интернете вещей. Они играют роль интерфейса между реальным и цифровым мирами и принимают разные размеры, формы и уровни технологической сложности в зависимости от задачи, которую они выполняют в рамках конкретного развертывания IoT. Будь то микрофоны размером с булавочную головку или внушительного размера машины, практически любой материальный объект можно превратить в подключенное устройство путем добавления необходимых элементов (датчиков или приводов вместе с соответствующим программным обеспечением).
Программное обеспечение
Это то, благодаря чему подключенные устройства можно назвать «умными». Программное обеспечение отвечает за связь с облаком, сбор данных, интеграцию устройств и за анализ данных в реальном времени. Также оно предоставляет возможности для визуализации данных и взаимодействия с системой IoT.
Коммуникации
Уровень коммуникации включает в себя как решения для физического подключения (сотовая и спутниковая связь, LAN), так и специальные протоколы, используемые в различных средах IoT (ZigBee, Thread, Z-Wave, MQTT, LwM2M). Выбор подходящего коммуникационного решения — одна из жизненно важных частей при построении каждой IoT-системы. Выбранная технология будет определять не только способы отправки и получения данных из облака, но способы связи со сторонними устройствами.
Платформа
Устройства способны «ощущать», что происходит вокруг и сообщать об этом пользователю через определенный канал связи. IoT-платформа — это место, где все эти данные собираются, анализируются и передаются пользователю в удобной форме. Платформы могут быть установлены локально или в облаке. Выбор платформы зависит от требований конкретного проекта IoT и многих факторов: архитектура и стек технологий, надежность, параметры настройки, используемые протоколы, аппаратная независимость, безопасность, эффективность, стоимость.
Ниже можно рассмотреть подробнее составляющие трех уровней IoT: конечных устройств (вещей), сети, облака.
Типовая архитектура IoT-системы. Источник изображения: https://ru.rsdelivers.com/campaigns/InternetofThings/internet-of-things
Безопасность
Одновременно с тем фактом, что IoT-системы несут в себе значительную бизнес-ценность, интеллектуальные объекты также становятся уязвимы для киберпреступности, в результате которой может происходить утечка данных, в том числе и конфиденциальной информации. Несмотря на то, что поле работы с вопросом безопасности остается огромным, сейчас существуют решения, позволяющие осуществлять развертывание IoT более надежно. Например, для решения проблемы устаревания программного обеспечения устройств, есть возможности эффективных стратегий автоматическиого обновления.
Благодаря SOTA (Software Over the Air) «обновление по воздуху» и FOTA (Firmware Over the Air) — «прошивка по воздуху», программное обеспечение подключенных устройств и настройки можно обновлять с помощью беспроводной связи.
Примеры областей применения IoT
IoT применим в разных отраслях для различных целей: отслеживания потребительского поведения в режиме реального времени, улучшения качества работы машин и систем, нахождение инновационных методов работы в рамках цифровой трансформации и многое другое.
Розничная торговля
Среди примеров приложений IoT в сфере розничной торговли можно встретить множество случаев использования интеллектуальных устройств для повышения качества обслуживания в магазинах. В частности, различные приложения IoT здесь означают, что возможности использования смартфонов (на основе технологии Beacon — миниатюрных маячков) облегчают общение между розничными продавцами и покупателями, а наиболее востребованные товары и услуги появляются перед глазами клиентов в нужном месте. Кроме того, интеллектуальная розничная торговля открывает возможности для приложений IoT с точки зрения точной рекламы, улучшения цикла цепочки поставок и фактического анализа моделей спроса. Также приложения IoT уже включают приложения для платежей NFC и интеллектуальных покупок. И конечно, нельзя не упомянуть RFID-метки для маркировки товара, которые обеспечивают моментальный и точный сбор информации, что помогает непрерывно отслеживать перемещение товаров, упростить процесс инвентаризации и в целом сократить количество ошибок.
Источник изображения: https://www.pochta.ru/support/post-rules/rfid
Производство
Благодаря IoT производство может получать общую картину о процессах производства и состоянии продукта на всех этапах — от поставки сырья до отгрузки готового продукта.
С помощью датчиков, установленных на заводском оборудовании и в складских помещениях, анализа больших данных и прогностического моделирования (predictive modeling) можно предотвратить множество ошибок, ведущих к простою и убыткам, максимизировать производительность, уменьшить гарантийные расходы и в целом улучшить качество клиентского сервиса.
Здравоохранение
С помощью технологии IoMT (The Internet of Medical Things, Интернет медицинских вещей) в режиме реального времени происходит сбор потоков малых данных из медицинских сетевых и других носимых устройств, отслеживающих различные физиологические моменты, связанные со здоровьем пациентов — движения, динамика сна, сердечный ритм, аллергические реакции и прочее. Собранные данные помогают врачам в постановке точных диагнозов, построении плана лечения, повышают безопасность пациентов, упрощают уход за ними, дают возможность непрерывного мониторинга состояния тяжелобольных пациентов.
Применение Интернета вещей способствует созданию более персонализированного подхода к анализу состояния здоровья и более последовательных стратегий борьбы с болезнями.
Ключевые моменты в сфере здравоохранения, которые можно улучшить с помощью IoT. Источник изображения: https://evercare.ru/news/kak-internet-medicinskikh-veschey-vliyaet-na-zdravookhranenie
Энергетика
Здесь с помощью IoT конструкция электрических сетей меняет правила потребления, автоматически собирая данные и обеспечивая мгновенный анализ циркуляции электроэнергии. В результате этого и клиенты, и поставщики лучше понимают, как оптимизировать использование ресурса.
Заключение
Революция в области Интернета вещей представляется важной для развития бизнеса, и это может относиться к любому типу предприятия. Будь то выращивание устриц или создание системы управления движением, самое ценное в технологической концепции IoT — это то, что он открыт к новым вызовам, и в нем достаточно возможностей для реализации практически любой бизнес-идеи.
Прямо сейчас в OTUS открыт набор на курс «Разработчик IoT». Приглашаем на бесплатный вебинар, в рамках которого наши эксперты расскажут еще больше о том, что такое интернет вещей и где он применяется, а также о карьерных перспективах в данной сфере.
Что такое интернет вещей?
Как устроен интернет вещей?
Интернет вещей (IoT) объединяет устройства в компьютерную сеть и позволяет им собирать, анализировать, обрабатывать и передавать данные другим объектам через программное обеспечение, приложения или технические устройства
IoT-устройства функционируют самостоятельно, хотя люди могут настраивать их или предоставлять доступ к данным. IoT-системы работают в режиме реального времени и обычно состоят из сети умных устройств и облачной платформы, к которой они подключены с помощью WiFi, Bluetooth или других видов связи.
Что происходит, когда температура оказывается слишком высокой или в доме появился грабитель? Система оповещает об этом пользователя или сама выполняет дальнейшие действия — например, включает кондиционер или звонит в полицию.
Сначала устройства собирают данные — например, о температуре в квартире или частоте сердцебиения пользователя, затем эти данные отправляются в облако. Там программное обеспечение обрабатывает их, причем интернет вещей неразрывно связан с Big Data, отмечает в подкасте РБК Трендов Александр Сурков, менеджер по развитию IoT «Яндекс.Облака».
Из чего состоит интернет вещей?
Помимо Big Data для работы интернета вещей также важны аналитика, соединения, устройства и опыт. Для простоты этот принцип представляют как ABCDE: Analytics, BigData, Connection, Devices, Experience.
Где используют интернет вещей?
IoT позволяет компаниям автоматизировать процессы и снижать трудозатраты. Это сокращает объем отходов, улучшает качество предоставляемых услуг, удешевляет процесс производства и логистику.
«С IoT можно столкнуться практически во всех сферах: начиная от контекстной рекламы, которая подсказывает пользователю, где можно пообедать или заправиться в зависимости от текущей геолокации, и заканчивая доставкой еды или покупкой автомобиля», — рассказал РБК Трендам технический директор IoT-системы прогностики ПРАНА Максим Липатов.
По данным исследования IoT Analytics [1], в 2020 году самый высокий уровень проникновения технологии IoT наблюдался в транспорте, энергетике, ретейле, управлении жизнью города, здравоохранении и промышленности.
Чем IoT полезен человеку?
Интернет вещей у многих ассоциируется с «умным» домом. Благодаря технологиям и устройствам, разработанным компаниями Google, «Яндекс», Amazon, Apple и другими, пользователи могут совершать онлайн-покупки, регулировать температуру в комнате, включать свет и музыку, отдавая голосовые команды виртуальным помощникам.
Вам больше не надо опасаться, что вы забыли выключить утюг или кран — достаточно нажать кнопку в смартфоне, и «умный» дом все исправит. А можно и не нажимать, ведь дом настолько умный, что сам приведет все в порядок, а владельцу отправит уведомление по итогу. Система наблюдения с помощью компьютерного зрения распознает всех, кто проходит мимо вашей квартиры, и сравнит изображения с базой полиции.
Сегодня «умный» дом в России — это в основном интеллектуальный помощник «Яндекса» «Алиса», которая включает музыку, ищет информацию в интернете, советует фильмы, регулирует освещение и температуру в доме, включает чайник.
Американская компания Qualcomm также предлагает систему, которая сделает любой дом «умнее». Она позволяет удаленно следить за обстановкой в доме, сообщает о появлении шума, с ее помощью можно раздавать указания роботу-пылесосу и другим подключенным устройствам, а также открывать двери по системе распознавания лиц.
Есть ли недостатки у интернета вещей?
Основная проблема, с которой связано развитие IoT, — безопасность. Киберпреступники постоянно пытаются взламывать устройства удаленного наблюдения за пациентами, базы данных с информацией о здоровье людей, интеллектуальные системы управления автомобилем, совершают фишинговые атаки, подгружают вирусы на взломанные устройства и даже совершают целые диверсии на производствах. Поэтому участникам рынка IoT-рынка надо учиться защищать свои системы.
Еще одна сложность интернета вещей — возможная несовместимость программного обеспечения разных устройств разных производителей, объединенных в единую систему. Такая ситуация может возникнуть, когда разработчики выпускают обновление ПО для своего устройства и не проверяют его совместимость со старыми версиями ПО других связанных устройств. Для устранения неполадок придется связываться с другими компаниями-разработчиками и просить их вносить изменения в свое ПО для корректной работы всей системы IoT.
Подключение все большего количества устройств к интернету неизбежно приведет к потере рабочих мест. Например, IoT-системы заменят часть специалистов по техобслуживанию, ремонту и установке оборудования. Кроме того, сегодня правовые аспекты внедрения интернета вещей достаточно расплывчаты.
Проблемы внедрения IoT
Максим Липатов разделяет проблемы при внедрении интернета вещей на технологические и кадровые:
«Мнение о том, что внедрение хайповых технологий вроде Big Data или Data Science станет панацеей от всех бед, ошибочно, — добавляет Липатов. — Организации нужно начать с переосмысления бизнес-процессов и определения инструментов цифровизации, а для этого нужна экспертиза. Возможно, подходящим решением станет именно прогностика на основе IoT. Она способна предотвратить чрезмерный расход ресурсов и отклонения в техническом состоянии оборудования, а также продлить его жизненный цикл. Все это снижает риски внезапной остановки производства из-за неисправностей, а значит, исключает прямые финансовые потери».
Прогностика — последний на сегодняшний день этап эволюции промышленного интернета вещей. Она подразумевает не просто сбор данных с единиц оборудования, а локальную систему с распределенной сетью, в которой информация из разных источников поступает в одно хранилище, где обрабатывается и отправляется обслуживающему устройства персоналу.
Будущее интернета вещей
По прогнозам IDC, к 2025 году в мире будет насчитываться 55,7 млрд подключенных устройств. Киберпреступники будут продолжать атаковать их, потому что IoT-система — это достаточно быстрый способ распространить вредоносное ПО. Рядовые пользователи, компании и целые города будут все чаще применять интеллектуальные технологии, чтобы сэкономить время и деньги. Например, холодильники смогут предупреждать о скорой порче продуктов, светофоры со встроенными видеодатчиками будут регулировать дорожное движение в зависимости от трафика.
Сейчас, однако, ключевая проблема внедрения IoT — отсутствие единых стандартов. Поэтому имеющиеся решения сложно интегрируются между собой, а новые появляются медленнее, чем могли бы.
Еще один нюанс — «вещи» в интернете вещей должны быть автономны, то есть иметь возможность получать энергию из окружающей среды, без участия человека.
IoT, туман и облака: поговорим про технологии?
Развитие технологий в области софта и железа, появление новых протоколов связи привели к расширению интернета вещей (IoT). Количество устройств растёт день ото дня, и они генерируют огромный объём данных. Поэтому возникает потребность в удобной архитектуре системы, способной обрабатывать, хранить и передавать эти данные.
Сейчас для этих целей используют облачные сервисы. Однако становящаяся всё более популярной парадигма туманных вычислений (Fog) способна дополнить облачные решения, масштабировав и оптимизировав инфраструктуру IoT.
«Облака» способны закрыть большинство запросов IoT. Например, обеспечить мониторинг служб, быструю обработку любых объёмов данных, генерируемых устройствами, а также их визуализацию. Туманные же вычисления эффективнее при решении real-time задач. Они обеспечивают быстрый отклик на запросы и минимальную задержку при обработке данных. То есть Fog именно дополняет «облака», расширяет его возможности.
Впрочем, главный вопрос в другом: как всё это должно взаимодействовать в контексте IoT? Какие протоколы связи будут наиболее эффективными при работе в объединённой системе IoT-Fog-Cloud?
Несмотря на кажущееся доминирование HTTP, в системах IoT, Fog и Cloud используется большое количество других решений. Это объясняется тем, что IoT должен сочетать функциональные возможности разнообразных датчиков устройств с безопасностью, совместимостью и другими требованиями, предъявляемыми пользователями.
Вот только единого представления об эталонной архитектуре и стандарте связи попросту нет. Поэтому создание нового протокола или доработка существующего под конкретные задачи IoT является одной из важнейших задач, стоящих перед ИТ-сообществом.
Какие протоколы используются сейчас и что они могут предложить? Давайте разбираться. Но для начала обсудим принципы экосистемы, в которой взаимодействуют облака, туман и интернет вещей.
Архитектура IoT Fog-to-Cloud (F2C)
Вы наверняка замечали, сколь значительные усилия прикладываются для изучения преимуществ и выгод, связанных с рациональным и скоординированным управлением IoT, облаками и туманом. Если же нет, то вот вам аж три инициативы по стандартизации: OpenFog Consortium, Edge Computing Consortium и mF2C H2020 EU project.
Если раньше рассматривали только 2 уровня, облака и конечных устройств, то предлагаемая архитектура вводит новый уровень — туманные вычисления. При этом уровень тумана может быть разделён на несколько подуровней, в зависимости от специфики ресурсов или набора политик, определяющих использование разных устройств в этих подуровнях.
Как может выглядеть эта абстракция? Вот типичная экосистема IoT-Fog-Cloud. IoT-устройства отправляют данные на более производительные сервера и вычислительные устройства, чтобы решать задачи, требующие низкого уровня задержки. В этой же системе облака отвечают за решение задач, требующих большого объёма вычислительных ресурсов или места для хранения данных.
Смартфоны, умные часы и другие гаджеты тоже могут быть частью IoT. Но такие устройства, как правило, используют проприетарные протоколы связи от крупных разработчиков. Сгенерированные данные интернета вещей передаются на уровень тумана через протокол REST HTTP, который обеспечивает гибкость и функциональную совместимость при создании RESTful-сервисов. Это важно в свете необходимости обеспечения обратной совместимости с существующей вычислительной инфраструктурой, работающей на локальных компьютерах, серверах или кластере серверов. Локальные ресурсы, которые называют «узлами тумана», фильтруют полученные данные и обрабатывают их локально либо пересылают в облако для дальнейших вычислений.
Облака поддерживают разные протоколы связи, среди которых чаще всего встречаются AMQP и REST HTTP. Так как HTTP общеизвестен и заточен под интернет, может возникнуть вопрос: «а не использовать ли его для работы с IoT и туманом?». Однако у данного протокола есть проблемы с производительностью. Об этом позже.
В целом, существует 2 модели протоколов связи, подходящих под нужную нам систему. Это запрос-ответ и публикация-подписка. Первая модель известна шире, особенно в архитектуре сервер-клиент. Клиент запрашивает информацию с сервера, а тот получает запрос, обрабатывает его и возвращает ответное сообщение. По этой модели работают протоколы REST HTTP и CoAP.
Вторая модель возникла из-за необходимости обеспечить асинхронную, распределённую, слабую связь между источниками, генерирующими данные, и получателями этих данных.
Модель предполагает трёх участников: издатель (источник данных), брокер (диспетчер) и подписчик (получатель). Здесь клиент, выступающий в роли подписчика, не должен запрашивать информацию с сервера. Вместо отправки запросов он подписывается на определённые события в системе через брокера, ответственного за фильтрацию всех входящих сообщений и их маршрутизацию между издателями и подписчиками. А издатель, когда происходит событие, касающееся определённой темы, публикует его брокеру, который отправляет подписчику данные по запрошенной теме.
По сути, эта архитектура основана на событиях. И такая модель взаимодействия интересна для приложений в IoT, облаке, тумане из-а её способности обеспечивать масштабируемость и упрощать взаимосвязь между различными устройствами, поддерживать динамическую связь «многие ко многим» и асинхронную связь. Среди наиболее известных стандартизированных протоколов обмена сообщениями, использующих модель «публикация-подписка», можно назвать MQTT, AMQP и DDS.
Очевидно, что у модели «публикация-подписка» есть масса преимуществ:
Также есть протоколы, которые поддерживают обе модели. Например, XMPP и HTTP 2.0, поддерживающие опцию «server push». IETF также выпустил CoAP. В попытке решить проблему обмена сообщениями было создано несколько других решений, таких как протокол WebSockets или использование протокола HTTP через QUIC (Quick UDP Internet Connections).
В случае с WebSockets, хотя он и используется для передачи данных в режиме реального времени с сервера на веб-клиент и обеспечивает постоянные соединения с одновременной двунаправленной связью, он не предназначен для устройств с ограниченными вычислительными ресурсами. QUIC тоже заслуживает внимания, поскольку новый транспортный протокол даёт массу новых возможностей. Но так как QUIC ещё не стандартизирован, преждевременно прогнозировать его возможное применение и влияние на решения в сфере IoT. Так что WebSockets и QUIC мы оставляем в памяти с прицелом на будущее, но подробнее изучать пока не будем.
Кто на свете всех милее: сравниваем протоколы
Теперь поговорим о сильных и слабых сторонах протоколов. Забегая вперёд, сразу оговоримся, что нет одного явного лидера. Какие-то достоинства/недостатки есть у каждого протокола.
Одной из важнейших характеристик протоколов связи, особенно применительно к интернету вещей, является время отклика. Но среди существующих протоколов нет безусловного победителя, демонстрирующего минимальный уровень задержки при работе в разных условиях. Зато есть целая куча исследований и сравнений возможностей протоколов.
Например, результаты сравнения эффективности HTTP и MQTT при работе с IoT показали что время отклика для запросов у MQTT меньше, чем у HTTP. А при изучении времени приёма-передачи (RTT) MQTT и CoAP выяснилось, что средний RTT CoAP на 20% меньше, чем у MQTT.
Другой эксперимент с RTT у протоколов MQTT и CoAP проводился в двух сценариях: локальной сети и сети IoT. Оказалось, что средний RTT в 2-3 раза выше в сети IoT. MQTT с QoS0 показал более низкий результат в сравнении с CoAP, а MQTT с QoS1 продемонстрировал более высокий RTT благодаря ACK на прикладном и транспортном уровнях. Для разных уровней QoS задержки в сети без перегрузки у MQTT составили миллисекунды, а для CoAP — сотни микросекунд. Однако стоит помнить, что при работе в менее надёжных сетях MQTT, работающий поверх TCP, покажет совершенной другой результат.
Сравнение времени отклика у протоколов AMQP и MQTT путём увеличения полезной нагрузки показало, что при небольшой нагрузке уровень задержки почти одинаков. Но при передаче больших объёмов данных MQTT демонстрирует меньшее время отклика. Ещё в одном исследовании CoAP сравнили с HTTP в сценарии межмашинной связи с устройствами, развернутыми поверх транспортных средств и оснащенными датчиками газа, датчиками погоды, местоположением (GPS) и интерфейсом мобильной сети (GPRS). Время, необходимое для передачи сообщения CoAP через мобильную сеть, было почти в три раза короче, чем время, необходимое для использования сообщений HTTP.
Проводились исследования, в которых сравнивались не два, а три протокола. Например, сравнение производительности IoT-протоколов MQTT, DDS и CoAP в сценарии медицинского применения с использованием сетевого эмулятора. DDS превзошел MQTT с точки зрения испытанной задержки телеметрии в различных плохих условиях сети. CoAP на основе UDP работал хорошо для приложений, которым требовался быстрый отклик, однако из-за того, что он основан на UDP, произошла значительная непредсказуемая потеря пакетов.
Сравнение MQTT и CoAP с точки зрения эффективности использования пропускного канала проводилось как подсчёт общего количества данных, передаваемых за одно сообщение. CoAP показал меньшую пропускную способность, чем MQTT при передаче небольших сообщений. Но при сравнении эффективности протоколов с точки зрения соотношения количества полезных информационных байтов к общему количеству переданных байтов CoAP оказался эффективнее.
При анализе использования пропускного канала MQTT, DDS (с TCP в качестве транспортного протокола) и CoAP выяснилось, что CoAP, как правило, показывал сравнительно более низкое потребление полосы пропускания, которое не увеличивалось при увеличении потерь сетевых пакетов или увеличенной задержки сети, в отличие от MQTT и DDS, где в упомянутых сценариях наблюдался рост использования пропускной способности канала. В другом сценарии было задействовано большое количество устройств, передающих данные одновременно, что является типичным случаем в средах IoT. Результаты показали, что для более высокой загрузки лучше использовать CoAP.
При небольшой нагрузке CoAP использовал наименьшую пропускную способность, за ним следовали MQTT и REST HTTP. Однако, когда размер полезных нагрузок увеличился, наилучшие результаты были у REST HTTP.
Вопрос энергопотребления всегда имеет большое значение, а в системе IoT — особенно. Если сравнивать потребление электроэнергии у MQTT и HTTP, то HTTP «сжирает» намного больше. А CoAP более энергоэффективен по сравнению с MQTT, позволяя управлять питанием. При этом в простых сценариях MQTT больше подходит для обмена информацией в сетях интернета вещей, особенно если нет ограничений по мощности.
Другой эксперимент, в ходе которого сравнили возможности AMQP и MQTT на испытательном стенде мобильной или нестабильной беспроводной сети, показало, что AMQP предлагает больше возможностей в плане безопасности, тогда как MQTT является более энергоэффективным.
Безопасность — это ещё один важнейший вопрос, поднимаемый при изучении темы интернета вещей и туманных/облачных вычислений. Механизм безопасности обычно основан на TLS в HTTP, MQTT, AMQP и XMPP, на или DTLS в CoAP, а также поддерживающим оба варианта DDS.
TLS и DTLS начинаются с процесса установления связи между клиентской и серверной сторонами для обмена поддерживаемыми комплектами шифров и ключами. Обе стороны согласовывают комплекты, чтобы гарантировать, что дальнейшая связь происходит в безопасном канале. Разница между ними заключается в небольших модификациях, которые позволяют DTLS на основе UDP работать по ненадёжному соединению.
При тестовых атаках на несколько разных реализаций TLS и DTLS выяснилось, что TLS лучше справился с задачей. Атаки на DTLS были успешнее из-за его терпимости к ошибкам.
Впрочем, самая большая проблема этих протоколов заключается в том, что они изначально не были предназначены для использования в IoT и не предполагали работу в тумане или облаке. Через согласованный обмен (handshaking) они добавляют дополнительный трафик с каждым установлением соединения, что истощает вычислительные ресурсы. В среднем наблюдается увеличение на 6,5% для TLS и 11% для DTLS в служебной нагрузке по сравнению со связью без уровня безопасности. В богатых ресурсами средах, которые обычно расположены на облачном уровне, это не будет проблемой, но в связи между IoT и уровнем тумана это становится важным ограничением.
Что же выбрать? Однозначного ответа нет. MQTT и HTTP кажутся наиболее перспективными протоколами, так как считаются сравнительно более зрелыми и более стабильными решениями для IoT в сравнении с другими протоколами.
Решения на основе единого коммуникационного протокола
Практика однопротокольного решения имеет много недостатков. Например, протокол, который удовлетворяет ограниченной среде, может не работать в домене, который имеет строгие требования безопасности. Имея это в виду, нам остаётся отбросить почти все возможные решения на основе одного протокола в экосистеме Fog-to-Cloud в IoT, кроме MQTT и REST HTTP.
REST HTTP как однопротокольное решение
Есть хороший пример взаимодействия запросов и ответов REST HTTP в сфере IoT-to-Fog: интеллектуальная ферма. Животные снабжаются носимыми датчиками (IoT-клиент, C) и управляются через облачные вычисления умной фермерской системой (Fog-сервер, S).
В заголовке метода POST указывается ресурс для изменения (/farm/animals), а также версия HTTP и тип содержимого, который в данном случае является объектом JSON, представляющим животноводческую ферму, которой должна управлять система (Дульсинея/корова). Ответ от сервера указывает, что запрос был успешен, присылая код состояния HTTPS 201 (resource created). Метод GET должен указывать только запрошенный ресурс в URI (например, /farm/animals/1), который возвращает JSON-представление животного с этим идентификатором с сервера.
Метод PUT используется, когда необходимо обновить некоторую конкретную запись ресурса. В этом случае в ресурсе указывается URI для параметра, подлежащего изменению, и текущего значения (например, указывающего, что корова в данный момент гуляет, /farm/animals/1? состояние=ходьба). Наконец, метод DELETE используется в равной степени для метода GET, но просто удаляет ресурс в результате операции.
MQTT как однопротокольное решение
Возьмём всё ту же умную ферму, но вместо REST HTTP используем протокол MQTT. Локальный сервер с установленной библиотекой Mosquitto выполняет роль брокера. В этом примере простой компьютер (обозначается как сервер фермы) Raspberry Pi служит клиентом MQTT, реализованным через установку библиотеки MQTT Paho, полностью совместимой с брокером Mosquitto.
Данный клиент соответствует уровняю абстракции IoT представляющему устройство с возможностями обнаружения и вычислений. Посредник, с другой стороны, соответствует более высокому уровню абстракции, представляющему вычислительный узел тумана, характеризующийся большими мощностями в плане обработки и хранения данных.
В предлагаемом сценарии «умной фермы» Raspberry Pi подключается к акселерометру, GPS и датчикам температуры и публикует данные с этих датчиков в узле тумана. Как вы наверняка знаете, MQTT рассматривает темы как иерархию. Один издатель MQTT может публиковать сообщения в определенном наборе тем. В нашем случае их три. Для датчика, который измеряет температуру в сарае для животных, клиент выбирает тему (animalfarm/shed/temperature). Для датчиков, которые измеряют местоположение GPS и движение животных через акселерометр, клиент опубликует обновления (animalfarm/animal/GPS) и (animalfarm/animal/movement).
Эта информация будет передана брокеру, который может временно сохранить его в локальной базе данных на случай, если позже появится другой заинтересованный подписчик.
Кроме локального сервера, выполняющего роль брокера MQTT в тумане и которому Raspberry Pi, выступающие в роли клиентов MQTT, отправляют данные с датчиков, на облачном уровне может быть ещё один брокер MQTT. В этом случае информация, передаваемая локальному брокеру, может временно храниться в локальной базе данных и/или отправляться в облако. Туманный MQTT-брокер в данной ситуации используется для связывания всех данных с облачным MQTT-брокером. При такой архитектуре пользователь мобильного приложения может быть подписан на обоих брокеров.
В случае сбоя соединения с одним из брокеров (например, облачным), конечный пользователь получит информацию от другого (туманного). Это характерная особенность комбинированных систем тумана и облачных вычислений. По умолчанию мобильное приложение может быть настроено на первое подключение к туманному MQTT-брокеру, а в случае неудачи — на подключение к MQTT-брокеру в облаке. Это решение является лишь одним из многих в системах IoT-F2C.
Многопротокольные решения
Решения с одним протоколом популярны из-за их более лёгкой реализации. Но очевидно, что в системах IoT-F2C имеет смысл комбинировать разные протоколы. Смысл в том, что на разных уровнях могут работать разные протоколы. Возьмём, к примеру, три абстракции: уровни IoT, тумана и облачных вычислений. Устройства на уровне IoT обычно считаются ограниченными. Для этого обзора давайте рассмотрим уровни IoT как наиболее ограниченные, облачные наименее ограниченные и вычисление тумана как «где-то посередине». Тогда получается, что между IoT и абстракциями тумана текущие протокольные решения включают в себя MQTT, CoAP и XMPP. Между туманом и облаком, с другой стороны, AMQP является одним из основных используемых протоколов вместе с REST HTTP, который благодаря своей гибкости также используется между IoT и слоями тумана.
Основной проблемой тут выступает функциональная совместимость протоколов и простота перевода сообщений из одного протокола в другой. В идеале, в будущем архитектура системы интернета вещей с облачными и туманными ресурсами будет независимой от используемого протокола связи и обеспечит хорошее взаимодействие разных протоколов.
Поскольку на данный момент это не так, имеет смысл объединять протоколы, не имеющих значительных различий. С этой целью одно потенциальное решение основано на комбинации двух протоколов, которые придерживаются одного и того же архитектурного стиля, REST HTTP и CoAP. Другое предлагаемое решение основано на сочетании двух протоколов, которые предлагают взаимодействие по модели «публикация-подписка», MQTT и AMQP. Использование близких концепций (и MQTT, и AMQP используют брокеров, CoAP и HTTP используют REST), упрощает реализацию этих комбинаций и требует меньших усилий по интеграции.
На рисунке (а) показаны две модели на основе запросов-ответов, HTTP и CoAP, и их возможное размещение в решении IoT-F2C. Поскольку HTTP является одним из наиболее известных и адаптированных протоколов в современных сетях, маловероятно, что он будет полностью заменен другими протоколами обмена сообщениями. Среди узлов, представляющих мощные устройства, которые находятся между облаком и туманом, REST HTTP является разумным решением.
С другой стороны, для устройств с ограниченными вычислительными ресурсами, которые связываются между уровнями тумана и IoT, более эффективно использовать CoAP. Одним из больших преимуществ CoAP на самом деле является его совместимость с HTTP, так как оба протокола основаны на принципах REST.
На рисунке (б) показаны две модели взаимодействия «публикация-подписка» в одном сценарии, включая MQTT и AMQP. Хотя гипотетически оба протокола могут использоваться для связи между узлами на каждом уровне абстракции, их положение должно определяться на основе производительности. MQTT был разработан как упрощенный протокол для устройств с ограниченными вычислительными ресурсами, поэтому его можно использовать для связи между IoT и туманом. AMQP больше подходит для более мощных устройств, которые идеально расположили бы его между узлами тумана и облака. Вместо MQTT в IoT можно использовать протокол XMPP, так как он считается легковесным. Но он не так широко используется в подобных сценариях.
Выводы
Маловероятно, что одного из рассмотренных протоколов будет достаточно для охвата всей связи в системе, начиная с устройств с ограниченными вычислительными ресурсами и заканчивая облачными серверами. Исследование показало, что два наиболее перспективных варианта, которые чаще используют разработчики, это MQTT и RESTful HTTP. Эти два протокола являются не только наиболее зрелыми и стабильными, но также включают в себя множество хорошо документированных и успешных реализаций и онлайн-ресурсов.
Благодаря своей стабильности и простой конфигурации, MQTT является протоколом, который с течением времени доказал свою превосходную производительность при использовании на уровне IoT с ограниченными устройствами. В частях системы, где ограниченная связь и потребление батареи не являются проблемой, например, в некоторых сферах тумана и большинстве облачных вычислений, RESTful HTTP является простым выбором. CoAP также следует принимать во внимание, поскольку он также быстро развивается как стандарт обмена сообщениями IoT, и вполне вероятно, что в ближайшем будущем он достигнет уровня стабильности и зрелости, аналогичного MQTT и HTTP. Но стандарт сейчас развивается, что сопряжено с краткосрочными проблемами совместимости.
Что ещё полезного можно почитать в блоге Cloud4Y
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью! Пишем не чаще двух раз в неделю и только по делу.