Несмотря на то, что устройства интернета вещей подразумевают наличие интернета уже в своём названии, зачастую распространены ситуации, когда управление локальными системами умного дома/промышленности/авто имеют локальные контроллеры системы в своём составе. Рассмотрим эти решения более подробно.
Будем рассматривать контроллеры умного дома, как основу. Считая, что решения для умной промышленности и умного авто являются модифицированными (адаптированными) версиями умного дома, который появился исторически раньше.
Наличие локального контроллера в системах умного дома обусловлено как историческими, так и технологическими факторами. Среди исторических факторов можно назвать:
- низкая скорость интернета в рамках глобальной вычислительной сети (ГВС/WAN),
- отсутствие готового решения для удалённого управления системами умного дома в момент появления интереса к технологии умного дома,
- высокая стоимость аренды оборудования и каналов передачи данных для случая выделенного сервера на проект и малое количество таких проектов, как дополнительный фактор отсутствия возможности снижения издержек за счёт распределения,
- различия в протоколах и интерфейсах устройств умного дома и интернета (необходимость применения дополнительных преобразователей/шлюзов),
- ограниченность пула адресов IPv4, высокая стоимость их покупки/аренды.
Из этого списка практически все факторы можно отнести также и к техническим составляющим, т.к. они они таковыми являлись на момент появления первых систем умного дома. Однако, если большинство из них были устранены по мере развития технологий, то некоторые остаются актуальными и сейчас.
Практически все вышеперечисленные факторы привели к тому, что стали появляться решения управления умным домом практически без непосредственного выхода в интернет каждым конкретным узлом системы. Как правило центром системы был простой ПК, на котором устанавливалась программа которая занималась опросом датчиков, обработкой алгоритмов управления и раздачей управляющих воздействий исполнительным устройствам. В большинстве случаев такая функциональность не требует больших ресурсов по причинам относительно малого числа устройств в умном доме (десятки-сотни штук), простоты алгоритмов управления (логика, линейные или ПИД-регуляторы) и невысокой скорости происходящих процессов (периоды от десятков миллисекунд до десятков минут). Применение ПК было обосновано простотой разработки ПО, конфигурации системы, стандартными интерфейсами, а также значительными ресурсами по сравнению с МК.
В настоящий момент подобную функциональность «потянет» практически любой маршрутизатор/Wi-Fi точка доступа обеспечивающий интернетом квартиру или частный дом. Такие устройства получили широкое распространение последние лет 5-10 и установлены у большинства дома. Однако, т.к. не всё же не все производители маршрутизаторов закладывают подобную функциональность на стадии разработки устройств и не предоставляют возможности модифицировать прошивки своих устройств, то также распространена модель, когда в домашней ЛВС используется дополнительное устройство, которое выполняет роль контроллера умного дома. При этом аппаратно оно представляет собой практически тот же самый маршрутизатор, возможно с рядом дополнительных блоков (как правило, контроллеров интерфейсов). Этот фактор можно отнести к техническим актуальным в текущий момент.
Стоит отметить, что и в настоящий момент нет полной необходимости подключения абсолютно всех узлов умного дома к интернету напрямую. В большинстве случае достаточно, чтобы прямой доступ в интернет имел только контроллер системы. Последний занимается управлением локальной системы (сбором информации с датчиков, выработкой необходимых действий и выдачей команд исполнительным устройствам). Он же через интернет может быть сконфигурирован под актуальную потребность. С этой точки зрения можно считать, что устройством интернета вещей является умный дом, а не каждый его компонент. Однако, в настоящий момент задача подключения всех узлов умного дома к интернету уже технически реализуема. И есть ряд систем построенных по такому принципу (примеры рассмотрим ниже).
Среди других факторов использования локального контроллера умного дома можно отметить:
- независимость работы системы от наличия канала связи с сервером и задержек передачи данных (актуально для критически важных процессов),
- отсутствие платы за использование сторонних сервисов,
- минимизация трафика в сети интернет (снижение затрат на интернет для удалённых регионов, повышение защищённости системы, применение более простых алгоритмов внутри ЛВС),
- низкая стоимость и распространённость аппаратных платформ и решений для контроллеров на рынке,
- наличие открытых бесплатных программных решений (возможность гибкой настройки и расширения).
В результате можно сделать вывод, что использование локальных контроллеров умного дома обосновано по факторов и имеет ряд особенностей описанных выше. Рассмотрим существующие решения. Первоначально необходимо определиться с составляющими системы, т.к. умный дом состоит из 3 основных составляющих: аппаратной, программной и облачной. Соответственно могут предоставляться, как законченные решения, включающие всё сразу, так и различные менее функциональные комбинации. В рамках этой статьи наиболее интересны решения с функциональностью контроллера. В таблицах ниже «~» обозначает частичную поддержку, «3P» — поддержку решений от 3 партнёров (проектов).
Таблица 1.1 — составляющие системы умного дома.
| Название | Аппаратные решения | Программные решения | Облачные сервисы | Функциональность |
| CubieBoard | + | + | ~ | Контроллер |
| Razberry | + | + | Контроллер | |
| OpenRemote | 3P | + | + | Контроллер |
| DeviceHive | 3P | + | +, 3P | Контроллер |
| OpenHab | 3P | + | +, 3P | Контроллер |
| BeagleBone | + | 3P | +, 3P | Контроллер |
| OSGi | 3P | 3P | + | Контроллер через облако |
| People Power | 3P | 3P | + | Контроллер через облако |
| iControl | 3P | + | + | Контроллер через облако |
| LinuxMCE | 3P | + | Контроллер, свет, климат, безопасность, телеком | |
| Ago Control | 3P | + | + | Контроллер, свет, безопасность, телеком |
Среди рассмотренных систем только OSGi позиционирует себя, как универсальное решение, остальные ориентированы на умный дом.
Не маловажными являются также такие составляющие проектов, текущее состояние проекта (готовность к практической реализации, развёртыванию системы на практике), а также условия лицензирования продуктов. Страна происхождения в условия мировой глобализации уже почти не играет роли, но эта информация может быть интересна с точки зрения понимания тенденций.
Таблица 1.2 — составляющие системы умного дома.
| Название | Статус | Лицензия | Страна |
| CubieBoard | массовое | Open Hardware | Международная |
| Razberry | массовое | закрытая | Швейцария |
| OpenRemote | массовое | закрытая | Нидерланды? |
| DeviceHive | Дизайн | MIT | Международная |
| OpenHab | Дизайн | Eclipse PL | Международная |
| BeagleBone | массовое | Open Hardware | Америка, международная |
| OSGi | Концепция | закрытая | Америка |
| People Power | дизайн | Закрытая, Open API | Америка |
| iControl | n/a | закрытая | Америка |
| LinuxMCE | дизайн | GPL, Pluto | Международная |
| Ago Control | n/a | GPL 3 |
Стоит сделать несколько замечаний относительно некоторых проектов:
- Razberry построен на базе связки Raspberry Pi и закрытого протокола Z-Wave (есть открытая библиотека, которая позволяет общаться с устройствами Z-Wave посредством API от производителя),
- OpenRemote согласно бизнес модели занимается продажей сервисов, лицензий и OEM-дизайнов для крупных производителей электроники,
- DeviceHive поддерживает множество различных модулей и языков программирования, в числе сверхвысокоуровневые, как, например Python. Благодаря большому количеству модулей этот проект обладает, наверное, самыми большими возможностями по управлению и аналитике процессов, а также поддерживает множество аппаратных платформ,
- OpenHab с самого начала разрабатывался, как платформонезависимое решение для контроллера умного дома, поэтому имеет правильную архитектуру и ряд специализированных сопутствующих решений, таких, как например, ПО для смартфонов,
- BeagleBone — система на модуле (SoM) от Texas Instruments, благодаря поддержке сообщества и доступной цене нашла широкое распространение в среде энтузиастов, под большинство открытых проектов в этом списке есть реализации на этом модуле,
- OSGi разрабатывался как платформа IoT на Java с оглядкой на корпоративный сегменте,
- People Power предлагают платформу IoT на нескольких уровнях для различных участников интернета вещей, акцентируя внимания на системном подходе и решениях для всех участников рынка интернета вещей,
- iControl отличается форматом распространения, т.к. работает с сетями кабельных ТВ и охранными компаниями.
Цветом в таблице 1.2 выделены открытые для лицензирования решения. Наибольший интерес для начинающих компаний и разработчиков составляют проекты обеспечивающие совокупность ряда фактов: открытость исходных кодов, поддержка программных решений, готовность к развёртыванию. Данным условиям удовлетворяют следующие решения:
Как видно на основе проведённого анализа существует ряд решений ориентированных на различных потребителей и различные модели бизнеса (распространения и поддержки) — начиная от полностью открытых и поддерживаемых сообществом до закрытых и распространяемых крупными корпорациями и альянсами. В зависимости от задачи оптимальным является тот или иной вариант.
Russian IoT 
Контроллеры системы умного дома: 3 комментария