Проектирование распределенных систем, которыми являются решения в области Интернета вещей (IoT) – сложный и кропотливый процесс. Если говорить о социальной составляющей IoT, то нужно учитывать и особенности процессов взаимодействия на уровне устройств, людей, а также не забывать о возможностях, которые можно не просто добавить, как внешний процесс, а сделать частью системы, которая уже будет основываться на принципах самоорганизации социальных сообществ. Бесспорно, это очень интересно и перспективно, как для амбициозного стартапа, так и простых энтузиастов, например, занимающихся усовершенствованием систем «умного дома», проектированием решений для аграрного сектора и т.п. Впрочем, успех любого проекта зависит не только от «правильной идеи», но и ее своевременной реализации.
Congatec introduces highly flexible IoT gateway. Press Releases. Image: congatec AG.
Все усложняется тем, что, начиная с уровня формирования идеи проекта, и завершая прототипированием социального IoT, казалось бы, существуют множества подходов и вариантов их решений. При этом, фактически уже на сегодня, сформировалась некая архитектура де-факто для построения решений в области Интернета вещей и наладки способов их взаимодействия с социальными сетями.
Несомненно, успех в разработке многих программно-аппаратных решений зависит от уровня детализации проекта. Вначале нужно определиться – будет ли создаваться проект от разработки платы, низкоуровневого программирования, а затем последует внедрение решения на уровне веб-сервиса и т.п., либо вместо этого будут использованы готовые компоненты и системы, а разработчик выступит в роли интегратора. Понятно, что сейчас низкоуровневое программирование – это не ассемблер, а C/C++ для микроконтроллера, но все-равно это не путь применения скрипт-ориентированного языка или графического языка программирования, например, как это можно сделать в системе виртуальных инструментов LabView компании National Instruments.
Везде есть свой компромисс. Практически любой производитель электроники для своих плат выпускает так называемый «референсный» (Reference) или, правильнее, образцовый вариант интеграции продукта в виде Start KIT, Development KIT и т.п. Поскольку разводка платы и основные программные решения уже предоставлены производителем, такой подход позволяет разработчику ускорить процесс освоения, например, нового микроконтроллера, микропроцессора, операционного усилителя и т.д.
Например, платформа безопасного конфигурирования AWS Zero Touch на базе микросхемы ECC508 компании Microchip позволяет разрабатывать защищенные решения на базе облака AWS IoT. Фактически это программно-аппаратное решение для надежной и защищенной аутентификации устройств Интернета вещей в облачном сервисе Amazon. Производитель чипа выпускает начальный комплект AT88CKECC-AWS-XSTK с функциями безопасного конфигурирования и демонстрации для быстрого начала разработки и прототипирования своих устройств.
The AWS Zero Touch Secure Development Platform. Photo: Microchip Technology.
Такие платы и стартовые наборы зачастую предоставляют для ознакомления или один компонент, или имеют дополнительные элементы и блоки в своем составе, например, для изучения всех особенностей определенного изделия. Иногда ознакомительные платы даже не содержат крепежных отверстий, что во многом сводит на нет создание прототипа на их основе, т.е. в таком случае не обойтись без самостоятельной разработки печатной платы.
Очевидно, появившиеся проекты Arduino, Raspberry Pi и др., так называемые открытые или свободные электронные проекты позволяют быстро и эффективно выполнить прототипирование устройств IoT. Эти продукты вносят определенный уровень унификации в разработку, а их открытый характер позволяет усовершенствовать или доработать существующий функционал для решения конкретной задачи. Фактически все зависит от компетенции разработчика, а также сроков и ограничений проекта.
Поскольку для разработки устройств Интернета вещей существует множество готовых решений на уровне датчиков и исполнительных систем, то логично рассмотреть достаточно типовой вариант разработки на уровне прототипирования на базе открытых электронных проектов. Так или иначе, после прототипа логично выполнить разводку платы, заказать ее изготовление и позаботиться об удобном корпусе для изделия.
Однако, увлекшись размышлениями о реализации, мы забываем об основном фундаменте проектирования. Ведь вначале любого проекта следует решить, а как будет проходить проект: «снизу в верх» или «сверху вниз». Т.е. сначала разработчик углубляется в реализацию деталей, например, создание датчиков и исполнительных устройств, а затем выполняет наладку коммуникаций между IoT, социальными сетями и т.д. Или наоборот, сначала разрабатывается каркас системы или ее концепт в той или иной форме, а уже потом разработчик прорабатывает детали реализации конечных составляющих проекта.
Scrum is a framework for managing software development. Picture: Wikipedia.
Тут нам на помощь должен прийти объектно-ориентированный подход к проектированию и гибкие (Agile) методологии управления проектами, о которых часто забывают разработчики связанные с электроникой или «железом». Совсем не верное мнение, что эти подходы справедливы лишь для разработки программных продуктов.
IoT, являясь по существу очень сложной распределенной системой, вполне может быть описана на уровне объектно-ориентированной модели, а как следствие, дать и инструменты для проектирования, например, использование UML-диаграмм. Как раз для понимания асинхронных процессов, которые являются основой взаимодействия Интернет вещей, понадобятся диаграммы компонентов, пакетов, деятельности, синхронизации и т.п. И как следствие применения объектно-ориентированного подхода, сразу решается выбор в пользу проектирования «сверху вниз».
В свою очередь, гибкие методологии, а тем более, сам Agile-манифест, гласит о том, что: «Люди и взаимодействие важнее процессов и инструментов; работающий продукт важнее исчерпывающей документации; сотрудничество с заказчиком важнее согласования условий контракта; готовность к изменениям важнее следования первоначальному плану».
Поэтому, для проекта социального Интернета вещей, следует сначала продумать и проработать видение платформы с которой будет работать конечный пользователь. Для масштабного проекта – это будет разработка своей кастомизированной платформы, а для менее амбициозного решения – выбор и настройка сервисов известных облачных решений, например, AWS IoT, Azure IoT Suite, Watson Internet of Things или др.
Сейчас для общего представления и самостоятельных изысканий в направлении проектов IoT на первые позиции уверенно вышел продукт Node-RED, разработанный IBM, и сейчас доступный под открытой лицензией проектов JS Foundation. Далее все просто, проект будет постоянно проходить итерации анализа решений и добавления нового функционала.
Для относительно небольшого проекта, настроенный процесс в Node-RED фактически станет, тем самым минимально жизнеспособным продуктом (MVP), который сразу смогут увидеть и оценить пользователи и, например, заказчик. Далее можно совершенствовать логику работы системы в целом на базе онлайн-сервиса и начинать планировать подключение конечных устройств IoT. При этом, не следует забывать о возможности создания панели с визуализацией данных, например, используя сторонние сервисы или модуль Node-RED dashboard.
В таком контексте Node-RED следует рассматривать не только, как программно-аппаратное решение, которое можно запустить локально на Raspberry Pi и начать собирать данные с датчиков, а как сервис, обеспечивающий визуальное конструирование взаимодействия устройств IoT и социальных медиа. Это даст конечному пользователю возможность настройки своих предпочтений в мире социального Интернета вещей или интегратору умного дома удобный инструмент, заменяющий традиционное программирование.
Node-RED. A visual tool for wiring the Internet of Things. Image: JS Foundation.
Для начала ознакомления с Node-RED можно воспользоваться сервисом FRED компании Sense Tecnic Systems. Так же можно запустить систему на базе подготовленного шаблона Boilerplate для IBM Bluemix, сервиса AWS Elastic Beanstalk Service (EBS) или на базе виртуальной машины Ubuntu Server облака, Amazon Web Services, Microsoft Azure и т.п.
Но если дальше задуматься о концепции самого проекта, то для разработки и внедрения решений IoT, кроме гибкого подхода к управлению проектом, становится актуальной и применение методологии DevOps. Именно взаимодействие групп разработки и эксплуатации лежит в основе грамотного подхода к формированию проекта социального Интернета вещей. Такой проект будет стремительно развиваться не только на этапе проектирования и запуска продукта, но и в процессе эксплуатации всех его сервисов и систем. А как известно, на текущий момент стандартом де-факто для внедрения методик DevOps стала контейнерная виртуализация на базе Docker.
Поэтому, есть большие предпосылки и основания, например, для изучения работы сложных веб-решений, таких как Node-RED, или простого их конфигурирования, развернуть такую систему в контейнере Docker на локальном компьютере. Затем можно будет мигрировать разработку в облако или посмотреть в сторону альтернативных решений и так же поэкспериментировать с ними на базе контейнерной виртуализации.
Docker — это кроссплатформенное решение для управления средой виртуализации на базе контейнеров. В общем, Docker уверенно проник в облака и стал одним из основных инструментальных средств DevOps. Платформа позиционируется разработчиками в направлении построения и использования контейнеризации как сервиса – Containers as a Service (CaaS). После установки в среде настольной операционной системы, работа с Docker выполняется на уровне командной строки. Сейчас, правда, уже можно использовать графическую оболочку Kitematic.
Kitematic is a simple application for managing Docker containers on Mac, Linux and Windows. Image: Kitematic.
Но все же Docker – это командная строка. Ведь для загрузки официального образа Node-RED из DockerHub и запуска на его основе контейнера потребуется только одна строка:
Далее, чтобы не остановить работу контейнера и покинуть командную строку Docker нужно нажать клавиши: «Ctrl-p», «Ctrl-q». Чтобы получить командную строку контейнера следует выполнить команду:
Следует оговориться, что установить расширения Node-RED вполне можно и в веб-интерфейсе системы: «Menu-Manage palette», но все же командная строка – это удобно и быстро.
Итак, на верхнем уровне нашей экосистемы социального IoT будет облако с запущенным сервисом Node-RED на базе контейнера на выделенном виртуальном сервере или работающий на кластере контейнеров, фактически – это уже разговор о масштабировании проекта. Главное, за счет контейнерной виртуализации, нам будет практически все-равно где выполнять отладку Node-RED-приложения – локально или в облаке.
Другой вопрос, а есть ли альтернатива Node-RED? Если не использовать эту оболочку, то придется разрабатывать веб-приложение или работать с облачными сервисами на уровне скрипт-ориентированных языков программирования. Интересно на этот счет мнение читателей нашего блога.
На самом деле, Node-RED часто сравнивают с проектами Eclipse Kura и Project Flogo. Для нашего примера Kura не совсем подходит, т.к. ее основное предназначение – это IoT-шлюз и ее лучше рассмотреть в контексте согласования интеллектуальных датчиков и исполнительных механизмов с системами верхнего уровня. А вот проект Flogo компании TIBCO Software заслуживает внимания, т.к. он еще и позиционируется разработчиками, как более быстрое решение, т.к. в отличие от Node-RED, написанного на NodeJS, Flogo разработан на языке Go. Но по существу Flogo – это так же шлюз, хотя есть и другое его применение, в качестве конструктора микросервисов для IoT. Это интерактивный конструктор в контексте событийно-ориентированной логики работы микросервиса. Представить функционал Flogo, конечно, можно с Docker: «docker run -it -p 3303:3303 flogo/flogo-docker eula-accept».
Pi 3 makes ‘ultimate education list’ for engineers. Image: MagPi.
После освоения функционала Node-RED, становится логичным переход к промежуточному слою рассматриваемой системы – интерфейсу взаимодействия датчиков и механизмов IoT с уровнем веб-сервиса. Это место одноплатных компьютеров и платформы Raspberry Pi, как наиболее удобного решения для экспериментов. Здесь, также уже существует, стандарт де-факто – это обмен сообщениями согласно модели «издатель/подписчик» по протоколу MQTT (Message Queue Telemetry Transport). Интересно, что MQTT был предложен все той же IBM совместно с итальянским производителем компьютерного оборудования Eurotech, и сейчас передан некоммерческой организации Eclipse Foundation. Как реализацию MQTT-брокера логично выбрать или достаточно легкое решение Eclipse Mosquitto, HiveMQ или др. В данном случае все зависит от требований к масштабированию системы.
В нашем случае, на промежуточном уровне предложенной системы IoT, запустим брокер Mosquitto, а для его аппаратной реализации выберем платформу Raspberry Pi. Концептуально это приблизит датчики и исполнительные механизмы друг к другу. И в случае отказа Интернет-канала брокер сможет поддерживать взаимодействие устройств IoT локально.
Нижним, или базовым, слоем в предлагаемой реализации, станет сеть интеллектуальных датчиков и исполнительных механизмов, а также устройств, которые, в случае отсутствия связи с Интернет, позволят наладить автономное функционирование системы. Конечно, это взаимодействие следует организовать на основе протокола MQTT.
На основе Raspberry Pi с решениями на Node-RED, Kura или др. вполне можно реализовать систему, которая позволит работать комбинированным датчиками, например, как это было предложено в статье «Взаимодействие машин и людей в среде социального Интернета вещей». В комментариях к статье (@Mobile1) было отмечено решение SensorTag от Texas Instruments, которое хотя и очень заманчиво смотрится, но все же это демонстрационное устройство, которое предназначено для изучения платформы СС13xx/CC26xx Texas Instruments. В качестве концептуального решения для датчиков и исполнительных механизмов для реализации IoT интересно смотрится подход: один датчик – одно устройство или один исполнительный механизм – одно устройство.
D1 mini. D1 mini Shields. Image: WEMOS Electronics.
Хочется поблагодарить наших читателей за весьма содержательные комментарии. Как пример, в контексте комментариев были упомянуты решения от Wemos, которые отлично реализуют концепцию Интернета вещей, но им явно не хватает функционального корпуса и хотя бы наличия на плате крепежных отверстий, например, как это реализовано в серии устройств Sonoff компании ITEAD Intelligent Systems (@IvanT, cheshircat). Благодаря конструктивному диалогу появляются темы для новых статей.
К сожалению, в одной статье «нельзя объять необъятное». В продолжении публикации, как уже догадался читатель, будем рассматривать некоторую идеализированную реализацию социальной IoT на основе предложенной трехуровневой архитектуры и современных методологий проектирования. Кстати, о методологии, конечно, отдельному разработчику, гику, вряд ли понадобятся вообще задумываться об управлении проектом, но, если над решением задачи работает команда – есть над чем поразмышлять.
Congatec introduces highly flexible IoT gateway. Press Releases. Image: congatec AG.
Все усложняется тем, что, начиная с уровня формирования идеи проекта, и завершая прототипированием социального IoT, казалось бы, существуют множества подходов и вариантов их решений. При этом, фактически уже на сегодня, сформировалась некая архитектура де-факто для построения решений в области Интернета вещей и наладки способов их взаимодействия с социальными сетями.
Несомненно, успех в разработке многих программно-аппаратных решений зависит от уровня детализации проекта. Вначале нужно определиться – будет ли создаваться проект от разработки платы, низкоуровневого программирования, а затем последует внедрение решения на уровне веб-сервиса и т.п., либо вместо этого будут использованы готовые компоненты и системы, а разработчик выступит в роли интегратора. Понятно, что сейчас низкоуровневое программирование – это не ассемблер, а C/C++ для микроконтроллера, но все-равно это не путь применения скрипт-ориентированного языка или графического языка программирования, например, как это можно сделать в системе виртуальных инструментов LabView компании National Instruments.
Везде есть свой компромисс. Практически любой производитель электроники для своих плат выпускает так называемый «референсный» (Reference) или, правильнее, образцовый вариант интеграции продукта в виде Start KIT, Development KIT и т.п. Поскольку разводка платы и основные программные решения уже предоставлены производителем, такой подход позволяет разработчику ускорить процесс освоения, например, нового микроконтроллера, микропроцессора, операционного усилителя и т.д.
Например, платформа безопасного конфигурирования AWS Zero Touch на базе микросхемы ECC508 компании Microchip позволяет разрабатывать защищенные решения на базе облака AWS IoT. Фактически это программно-аппаратное решение для надежной и защищенной аутентификации устройств Интернета вещей в облачном сервисе Amazon. Производитель чипа выпускает начальный комплект AT88CKECC-AWS-XSTK с функциями безопасного конфигурирования и демонстрации для быстрого начала разработки и прототипирования своих устройств.
The AWS Zero Touch Secure Development Platform. Photo: Microchip Technology.
Такие платы и стартовые наборы зачастую предоставляют для ознакомления или один компонент, или имеют дополнительные элементы и блоки в своем составе, например, для изучения всех особенностей определенного изделия. Иногда ознакомительные платы даже не содержат крепежных отверстий, что во многом сводит на нет создание прототипа на их основе, т.е. в таком случае не обойтись без самостоятельной разработки печатной платы.
Очевидно, появившиеся проекты Arduino, Raspberry Pi и др., так называемые открытые или свободные электронные проекты позволяют быстро и эффективно выполнить прототипирование устройств IoT. Эти продукты вносят определенный уровень унификации в разработку, а их открытый характер позволяет усовершенствовать или доработать существующий функционал для решения конкретной задачи. Фактически все зависит от компетенции разработчика, а также сроков и ограничений проекта.
Поскольку для разработки устройств Интернета вещей существует множество готовых решений на уровне датчиков и исполнительных систем, то логично рассмотреть достаточно типовой вариант разработки на уровне прототипирования на базе открытых электронных проектов. Так или иначе, после прототипа логично выполнить разводку платы, заказать ее изготовление и позаботиться об удобном корпусе для изделия.
Однако, увлекшись размышлениями о реализации, мы забываем об основном фундаменте проектирования. Ведь вначале любого проекта следует решить, а как будет проходить проект: «снизу в верх» или «сверху вниз». Т.е. сначала разработчик углубляется в реализацию деталей, например, создание датчиков и исполнительных устройств, а затем выполняет наладку коммуникаций между IoT, социальными сетями и т.д. Или наоборот, сначала разрабатывается каркас системы или ее концепт в той или иной форме, а уже потом разработчик прорабатывает детали реализации конечных составляющих проекта.
Scrum is a framework for managing software development. Picture: Wikipedia.
Тут нам на помощь должен прийти объектно-ориентированный подход к проектированию и гибкие (Agile) методологии управления проектами, о которых часто забывают разработчики связанные с электроникой или «железом». Совсем не верное мнение, что эти подходы справедливы лишь для разработки программных продуктов.
IoT, являясь по существу очень сложной распределенной системой, вполне может быть описана на уровне объектно-ориентированной модели, а как следствие, дать и инструменты для проектирования, например, использование UML-диаграмм. Как раз для понимания асинхронных процессов, которые являются основой взаимодействия Интернет вещей, понадобятся диаграммы компонентов, пакетов, деятельности, синхронизации и т.п. И как следствие применения объектно-ориентированного подхода, сразу решается выбор в пользу проектирования «сверху вниз».
В свою очередь, гибкие методологии, а тем более, сам Agile-манифест, гласит о том, что: «Люди и взаимодействие важнее процессов и инструментов; работающий продукт важнее исчерпывающей документации; сотрудничество с заказчиком важнее согласования условий контракта; готовность к изменениям важнее следования первоначальному плану».
Поэтому, для проекта социального Интернета вещей, следует сначала продумать и проработать видение платформы с которой будет работать конечный пользователь. Для масштабного проекта – это будет разработка своей кастомизированной платформы, а для менее амбициозного решения – выбор и настройка сервисов известных облачных решений, например, AWS IoT, Azure IoT Suite, Watson Internet of Things или др.
Сейчас для общего представления и самостоятельных изысканий в направлении проектов IoT на первые позиции уверенно вышел продукт Node-RED, разработанный IBM, и сейчас доступный под открытой лицензией проектов JS Foundation. Далее все просто, проект будет постоянно проходить итерации анализа решений и добавления нового функционала.
Для относительно небольшого проекта, настроенный процесс в Node-RED фактически станет, тем самым минимально жизнеспособным продуктом (MVP), который сразу смогут увидеть и оценить пользователи и, например, заказчик. Далее можно совершенствовать логику работы системы в целом на базе онлайн-сервиса и начинать планировать подключение конечных устройств IoT. При этом, не следует забывать о возможности создания панели с визуализацией данных, например, используя сторонние сервисы или модуль Node-RED dashboard.
В таком контексте Node-RED следует рассматривать не только, как программно-аппаратное решение, которое можно запустить локально на Raspberry Pi и начать собирать данные с датчиков, а как сервис, обеспечивающий визуальное конструирование взаимодействия устройств IoT и социальных медиа. Это даст конечному пользователю возможность настройки своих предпочтений в мире социального Интернета вещей или интегратору умного дома удобный инструмент, заменяющий традиционное программирование.
Node-RED. A visual tool for wiring the Internet of Things. Image: JS Foundation.
Для начала ознакомления с Node-RED можно воспользоваться сервисом FRED компании Sense Tecnic Systems. Так же можно запустить систему на базе подготовленного шаблона Boilerplate для IBM Bluemix, сервиса AWS Elastic Beanstalk Service (EBS) или на базе виртуальной машины Ubuntu Server облака, Amazon Web Services, Microsoft Azure и т.п.
Но если дальше задуматься о концепции самого проекта, то для разработки и внедрения решений IoT, кроме гибкого подхода к управлению проектом, становится актуальной и применение методологии DevOps. Именно взаимодействие групп разработки и эксплуатации лежит в основе грамотного подхода к формированию проекта социального Интернета вещей. Такой проект будет стремительно развиваться не только на этапе проектирования и запуска продукта, но и в процессе эксплуатации всех его сервисов и систем. А как известно, на текущий момент стандартом де-факто для внедрения методик DevOps стала контейнерная виртуализация на базе Docker.
Поэтому, есть большие предпосылки и основания, например, для изучения работы сложных веб-решений, таких как Node-RED, или простого их конфигурирования, развернуть такую систему в контейнере Docker на локальном компьютере. Затем можно будет мигрировать разработку в облако или посмотреть в сторону альтернативных решений и так же поэкспериментировать с ними на базе контейнерной виртуализации.
Docker — это кроссплатформенное решение для управления средой виртуализации на базе контейнеров. В общем, Docker уверенно проник в облака и стал одним из основных инструментальных средств DevOps. Платформа позиционируется разработчиками в направлении построения и использования контейнеризации как сервиса – Containers as a Service (CaaS). После установки в среде настольной операционной системы, работа с Docker выполняется на уровне командной строки. Сейчас, правда, уже можно использовать графическую оболочку Kitematic.
Kitematic is a simple application for managing Docker containers on Mac, Linux and Windows. Image: Kitematic.
Но все же Docker – это командная строка. Ведь для загрузки официального образа Node-RED из DockerHub и запуска на его основе контейнера потребуется только одна строка:
docker run -it -p 1880:1880 --name mynodered nodered/node-red-dockerДалее, чтобы не остановить работу контейнера и покинуть командную строку Docker нужно нажать клавиши: «Ctrl-p», «Ctrl-q». Чтобы получить командную строку контейнера следует выполнить команду:
docker exec -it mynodered /bin/bash, чтобы остановить контейнер: docker stop mynodered и для повторного запуска: docker start mynodered. Как уже стало понятно Node-RED будет доступен по виртуальному адресу, который создаст Docker и на порту: 1880. При работе с командной строкой, следует учесть, что контейнер сконфигурирован на хранение данных пользователей в каталоге «/data». Например, чтобы установить дополнительный компонент Node-RED панель визуализации Node-RED-Dashboard следует в командной строке контейнера mynodered выполнить команды:$ cd /data
$ npm install node-red-dashboard
$ exitСледует оговориться, что установить расширения Node-RED вполне можно и в веб-интерфейсе системы: «Menu-Manage palette», но все же командная строка – это удобно и быстро.
Итак, на верхнем уровне нашей экосистемы социального IoT будет облако с запущенным сервисом Node-RED на базе контейнера на выделенном виртуальном сервере или работающий на кластере контейнеров, фактически – это уже разговор о масштабировании проекта. Главное, за счет контейнерной виртуализации, нам будет практически все-равно где выполнять отладку Node-RED-приложения – локально или в облаке.
Другой вопрос, а есть ли альтернатива Node-RED? Если не использовать эту оболочку, то придется разрабатывать веб-приложение или работать с облачными сервисами на уровне скрипт-ориентированных языков программирования. Интересно на этот счет мнение читателей нашего блога.
На самом деле, Node-RED часто сравнивают с проектами Eclipse Kura и Project Flogo. Для нашего примера Kura не совсем подходит, т.к. ее основное предназначение – это IoT-шлюз и ее лучше рассмотреть в контексте согласования интеллектуальных датчиков и исполнительных механизмов с системами верхнего уровня. А вот проект Flogo компании TIBCO Software заслуживает внимания, т.к. он еще и позиционируется разработчиками, как более быстрое решение, т.к. в отличие от Node-RED, написанного на NodeJS, Flogo разработан на языке Go. Но по существу Flogo – это так же шлюз, хотя есть и другое его применение, в качестве конструктора микросервисов для IoT. Это интерактивный конструктор в контексте событийно-ориентированной логики работы микросервиса. Представить функционал Flogo, конечно, можно с Docker: «docker run -it -p 3303:3303 flogo/flogo-docker eula-accept».
Pi 3 makes ‘ultimate education list’ for engineers. Image: MagPi.
После освоения функционала Node-RED, становится логичным переход к промежуточному слою рассматриваемой системы – интерфейсу взаимодействия датчиков и механизмов IoT с уровнем веб-сервиса. Это место одноплатных компьютеров и платформы Raspberry Pi, как наиболее удобного решения для экспериментов. Здесь, также уже существует, стандарт де-факто – это обмен сообщениями согласно модели «издатель/подписчик» по протоколу MQTT (Message Queue Telemetry Transport). Интересно, что MQTT был предложен все той же IBM совместно с итальянским производителем компьютерного оборудования Eurotech, и сейчас передан некоммерческой организации Eclipse Foundation. Как реализацию MQTT-брокера логично выбрать или достаточно легкое решение Eclipse Mosquitto, HiveMQ или др. В данном случае все зависит от требований к масштабированию системы.
В нашем случае, на промежуточном уровне предложенной системы IoT, запустим брокер Mosquitto, а для его аппаратной реализации выберем платформу Raspberry Pi. Концептуально это приблизит датчики и исполнительные механизмы друг к другу. И в случае отказа Интернет-канала брокер сможет поддерживать взаимодействие устройств IoT локально.
Нижним, или базовым, слоем в предлагаемой реализации, станет сеть интеллектуальных датчиков и исполнительных механизмов, а также устройств, которые, в случае отсутствия связи с Интернет, позволят наладить автономное функционирование системы. Конечно, это взаимодействие следует организовать на основе протокола MQTT.
На основе Raspberry Pi с решениями на Node-RED, Kura или др. вполне можно реализовать систему, которая позволит работать комбинированным датчиками, например, как это было предложено в статье «Взаимодействие машин и людей в среде социального Интернета вещей». В комментариях к статье (@Mobile1) было отмечено решение SensorTag от Texas Instruments, которое хотя и очень заманчиво смотрится, но все же это демонстрационное устройство, которое предназначено для изучения платформы СС13xx/CC26xx Texas Instruments. В качестве концептуального решения для датчиков и исполнительных механизмов для реализации IoT интересно смотрится подход: один датчик – одно устройство или один исполнительный механизм – одно устройство.
D1 mini. D1 mini Shields. Image: WEMOS Electronics.
Хочется поблагодарить наших читателей за весьма содержательные комментарии. Как пример, в контексте комментариев были упомянуты решения от Wemos, которые отлично реализуют концепцию Интернета вещей, но им явно не хватает функционального корпуса и хотя бы наличия на плате крепежных отверстий, например, как это реализовано в серии устройств Sonoff компании ITEAD Intelligent Systems (@IvanT, cheshircat). Благодаря конструктивному диалогу появляются темы для новых статей.
К сожалению, в одной статье «нельзя объять необъятное». В продолжении публикации, как уже догадался читатель, будем рассматривать некоторую идеализированную реализацию социальной IoT на основе предложенной трехуровневой архитектуры и современных методологий проектирования. Кстати, о методологии, конечно, отдельному разработчику, гику, вряд ли понадобятся вообще задумываться об управлении проектом, но, если над решением задачи работает команда – есть над чем поразмышлять.
Интересные ресурсы и ссылки:
- Платформа безопасного конфигурирования AWS Zero Touch — Atmel Corporation
- Рецепт инноваций: модель Agile — Harvard Business Review Россия
- Топ-7 методов управления проектами: Agile, Scrum, Kanban, PRINCE2 и другие — Проектные сервисы
- Визуализация интеграционных приложений — Хабрахабр
- DevOps вам в помощь — Компьютерное Обозрение
- Контейнеры и виртуализация: быстрее, эффективнее, надежнее — Хабрахабр
- Полное практическое руководство по Docker: с нуля до кластера на AWS — Хабрахабр
- A Brief, but Practical Introduction to the MQTT Protocol and its Application to IoT — Zoetrope labs
- Протокол MQTT. Особенности, варианты применения, основные процедуры MQTT Protocol — Технологии и средства связи
- SensorTag CC2650 sending data throw Raspberry Pi 3 to IBM Watson IoT Platform using Node-RED
- Миниатюрный CC2650STK открывает дверь в «Интернет вещей» — КОМПЭЛ
- ESP8266 With DHT11 to AlexaPI to Dashboards — Instructables
Комментарии (2)
lingvo
25.10.2017 13:29С точки зрения архитектуры ИМХО Вы недостаточно подробно остановились на некоторых весьма важных компонентах архитектуры IoT.
Например на уровне железа связь с различными хардварными устройствами не всегда возможна с помощью MQTT. В мире существует множество стандартов, прижившихся в разных сферах — проводных, беспроводных, интернетных. Поэтому тут при прототипировании или построении готовых систем весьма кстати приходятся так называемые Хаб-платформы, которые позволяют подключать различные датчики, устройства, протоколы и сервисы и приводить все это многообразие к одному протоколу. Например я пользуюсь OpenHAB — открытой платформой, которую можно запустить на том же RPI. Она поддерживает больше 100 различных производителей железа и сервисов. Есть множество аналогичных систем — ioBroker, HomeAssistant, Domotiqz и т.д. OpenHAB и NodeRED прекрасно дополняют друг-друга — OpenHAB отвечает за низкий уровень, а Node-RED за сценарии работы.
Второй интересный компонент — удаленный доступ и UI. Облако — это хорошо, и голосовые ассистенты тоже, но пользователи также хотят видеть и управлять с телефона и не только через WEB. А также иметь определенную безопасность. В этом случае мое решение для прототипирования — облачный брокер, например CloudMQTT + приложение не телефон/планшет/компьютер The Home Remote, которое позволяет легко создавать пользовательские UI с поддержкой MQTT. И тогда организация удаленного доступа через интернет становится простой игрой, а не мученьем с проброской портв, dynamic DNS и прочего.
Ну и третий компонент, которые только начинает набирать обороты в IoT — edge computing. Опять же облако — это хорошо, но некоторые задачи и алгоритмы необходимо выполнять на месте, особенно если они требуют определенного времени реакции. Если сработал датчик движения, то система должна включить свет сразу-же, а не через 5 секунд, пока все не пройдет через облако. В данном случае нам помогают промышленные решения, которые выходят на рынок IoT. Например я и использую Codesys — среду и рантайм, который используется для программирования программируемых логических контроллеров и исполнения кода на них в реальном времени + библиотеку MQTT для интеграции с IoT.
potan
А есть какие-нибудь ориентированные на IoT системы, основанные на реактивном программировании? Меня очень обрадовала скорость разработки UI на языке ELM и я подумал, что такой же подход мог бы эффективно применяться и в IoT, только view будет не web-страница, а что-то более специфичное (типа набора сигналов на GPIO).