Несколько дней назад я прочитал отличную статью "Манифест разработчика умных систем: 15 принципов"

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

Ввиду природы поста, он будет еще более субъективным, чем Манифест.

Во-первых, давайте разберемся с несколькими терминами, например, разработчик и пользователь умных систем. Кто это и где проходит разделение?

Есть 2 очевидные крайности: производитель купленного умного выключателя и моя жена, которая включает свет. Но к кому отнести меня или моего сына, которые изредка берем и достаем ESP32, чтобы припаять пару датчиков, кнопочек и прочих светодиодных лент, которые потом еще и взаимодействуют с тем самым выключателем?

Но даже если мы обратим свой взор на вендора, то тоже не совсем ясно. Поясню. Очевидная крайность: все устройства одного производителя, хаб тоже его, приложение в смартфонах его — он разработчик умной системы. А что если несколько вендоров в одной сети? А что если центральный хаб одного, устройства другого, а облако, с которым я взаимодействую с помощью, скажем Siri, и вовсе Apple? Кому из них адресован Манифест, кто из них тот самый разработчик? Думаю, что спускаясь чуть ниже уровня глобальных абстракций Манифеста, который я, кстати, практически полностью разделяю, следует ввести более глубокое функциональное разделение, иначе коллективная отвественность за пользовательский опыт выльется либо в коллективную безответственность, которую мы все сейчас наблюдаем в той или иной степени, либо в жесткое огораживание экосистем с интеграцией на уровне пользователя: у кого из вас больше одного приложения для управления умным домом на телефоне?

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

Субъекты же (как роли), например, пользователи, настройщики, разработчики, производители или поставщики, существуют в контексте этих объектов.

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

Чуть более детально в этом посте я остановлюсь только на объектах.

Конечные устройства

Да и здесь кроется довольно забавный вопрос. Что такое конечное устройство, то есть та самая "вещь" интернета вещей?

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

Вот я сейчас смотрю на свою люстру с несколькими лампами, которую я включаю с помощью 3 разных выключателей (отдельно, а не как активация ядерных боеголовок), фактически же работает диммер на DIN рейке в щите. Здесь под "вещью", казалось бы, имеется в виду конечный актуатор, но самое забавное, что диммер этот многокональный и я даже не помню какую из других люстр тоже контроллирует, так что вот оно устройство, но не все, а только часть. Но при этом, фраза жены "включи свет" интуитивно понятна.

Читателям советую найти "вещь" в другой связке: комнатный контроллер (термостат), который управляет радиаторными головками (отоплением) через 1 канал 8 канального ШИМ, а охлаждением через 1 из каналов 4 канального 0-10В актуатора, который уже задает уставку для заслонок постоянного расхода воздуха в канале воздуховода.

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

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

Хабы

В виду предыдущего размышления про то, что такое вещи, хабы представляют собой по сути фабрику еще более виртуальных вещей. Именно хаб может создать термостат, когда есть уже датчики температуры и головки на радиаторах. Он же может создать устройство "весь свет", который можно выключить. Забавно, но хаб может быть абсолютно виртуальным, например, в EIB или KNX основопологающее понятие — групповой адрес: сенсор шлет в него данные, а актуатор принимает один или более групповой адрес на каждую свою функцию. Таким образом, если на выходе из квартиры у вас есть выключатель, который шлет в какой-нибудь 1/1/1 состояние 0, а в каждом из актуаторов, ответственных за свет он присутствует (наравне с более индивидуальными, скажем, 1/0/11, 1/0/12 и тп) у вас будет такое устройство "выключить весь свет" без дополнительных физических устройств.

В этом примере хабом есть сама сеть, в других случаях хаб часто существует в физическом мире в виде отдельного физического устройства, но можно привести еще хороший пример "не очень физического" хаба — это Node-RED.

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

Шлюзы

Так уж получилось, что за последние лет 40-50 было создано очень много различных по топологиям и уровням абстракции сетей (со своими протоколами), которые так или иначе могут быть частью системы интернета вещей. Чтобы объеденить 2 сети создается некоторый узел обмена трафиком, если такой узел упаковывает все данные одного протокола в другой, то принято называть его туннелем, так как "с другой стороны" можно полностью достать весь поток работать с ним как с локальным, если же происходит замена абстракций, то такой узел принято называть шлюзом.

Раз уж мы в этом посте довольно свободно обращаемся с терминологией, то давайте использовать термин шлюз и чуть больше времени потратим на разбор откуда и куда на самом деле шлюзуют реально существующие устройства. Все кто работал с АСУТП рано или поздно расширяли "центральные" сети дополнительными, например, к Profibus подключали уйму счетчиков на Modbus.

Это все довольно отработанный случай и можно не слишком останавливаться, а вот откуда куда шлюзует Xiaomi Mijia Multifunctional Gateway? Хотелось бы сказать, что из ZigBee в Wi-Fi, но это не совсем так. Да, с одной стороны шлюза есть сеть ZigBee, но вот, даже подключив устройство стороннего производителя, вы не сможете до него достучаться через этот шлюз. С другой стороны шлюза есть Wi-Fi, но шлюз не только обеспечивает связь по локальной сети по протоколу (который хакерами был назван miIO protocol), но и с облаком Xiaomi, которое обеспечивает работу приложения Mi Home, когда вы покидаете локальную сеть. Другим очень интересным шлюзом является Samsung SmartThings, но здесь есть сложности.

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

Поясню свою позицию, с надеждой на то, что я ошибаюсь. Создавая новое устройство, совместимое с экосистемой Samsung SmartThings вы можете выбрать 2 варианта: подключаться к hub, либо напрямую к облаку, если же хотите создать автоматизацию, ту что у нас выше я назвал устройством, порожденным хабом, то это переместилось в облако. Точка. То есть налицо нарушение Манифеста. Вы не включите свет в туалете, если интернет у вас не работает, ни через приложение (судя по всему, локально больше нет надежд, исходя из диаграммы в статье IoT and Tizen IoT), ни локально с датчика движения другой сети, ведь интегрировать нужно устройство, а не сеть — иначе через облако.

Те, кому удалось поработать с Tizen IoT, поправьте меня, пожалуйста.

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

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

Облака данных

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

Поэтому я скорее насыплю в этой части моих личных хотелок и размышлений.

Хорошо, когда есть понятный API и простой, еще лучше, когда этот API открыт и к нему просто подключиться.

Здесь оговорюсь о простоте. Простота, если не говорить о математике, субъективна в принципе. Мое личное мнение основывается на моем опыте и моих желаниях. Конечно, для компании, которая собирается выпустить некоторый продукт в количестве нескольких сотен тысяч простота совсем иная.

Я хочу, чтобы я мог результаты своего хобби вплетать в мир вокруг меня. Что для этого требуется?

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

Предыдущие размышления были скорее о "Как?", но не менее важная проблема (это не вызов, а именно проблема) кроется в "Что?".

Я бы разделил все основные облака данных, которые можно использовать для IoT на два класса: точек данных и возможностей.

Облако точек данных. Это то ли параллельная эволюция с миром SCADA, то ли прямой потомок.

Вот есть у вас показания датчика температуры — ну так и давайте запишем его куда-то в облако, где тот, кому нужно прочтет. Датчик температуры на батарейке, а значит нужно еще сохранять уровень заряда, — не беда, смотрите выше. Есть целые классы облаков, которые позволяют вам это сделать. Их можно легко узнать, если основной протокол MQTT (но может быть и CoAP, и STOMP). Прекрасная штука — сам пользуюсь и далеко не только в IoT, называя при этом "торжеством свободы над здравым смыслом". Просто протоколы настолько гибкие, что одну и ту же задачу каждый решает по-своему.

Облако данных в форме возможностей. Признаюсь, лет 8-9 назад, когда я писал очередную версию своей домашней платформы, захотелось взять и классифицировать объекты в системе. Вот чтобы система понимала, что это вот лампочка, а это выключатель, а это клапан. Очевидная первая итерация: список типов (а на самом деле классов, ведь ООП же). Потом появляется выключатель, но на батарейке и сила ООП в действии — вот мы отнаследовали и получили новое. А потом оказалось, что на батарейке может быть что угодно. Тогда пришлось нарезать не на дерево классов устройств, а разделить на "возможности" устройств, совмещая которые мы и получаем выключатель.

Вот так и работают Apple HomeKit, Alexa, Google и прочие облачные экосистемы умных домов. Казалось бы вот оно счастье.

Но, как я сказал выше, я этот подход использовал 8-9 лет назад. И я определял эти самые возможности сам, захотелось добавить IP камеру или Asterisk PBX? Супер. Дописал и работает.

Но вот незадача, перечисленные выше облачные экосистемы умных домов на самом деле экосистемы не IoT, а экосистемы голосовых ассистентов, чьи возможности должны быть универсальными для всего мира и для всех устройств. Добавление новых возможностей процесс значительно отличающийся от моего "Дописал и работает". Все мы помним, как на заре этих экосистем приходилось "включать ворота". Аналогичная ситуация и с SmartThings.

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

С другой стороны, как же создать интерфейсы пользователя не понимая что может устройство? Подход с точками данных в SCADA был удобен, чтобы скрыть топологические и протокольные особенности. Получить данные (горизонтальный список) с некоторыми дополнительными свойствами, например, достоверность (нет ли по пути был разрыва связи) или уровни доступа, но их основное представление было в виде мнемосхем.

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

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

Функцией производителя устройства будет описание, в том числе, и желаемых представлений для этого продукта как для визуальных интерфейсов, так и для иных видов: голосовое взаимодействие, AR/VR и тому подобных. Но, даже если производитель не сделал этого, то скрепя сердце и превозмогая лень, пользователь может таки выбрать, что данное устройство Google с этих пор может знать как "Smart Home Kettle" и у него теперь есть такие возможности: TemperatureControl, OnOff, Modes и Toggles. Да, я отбросил action.devices.traits для компактности.

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

Сервисы интеграции

Это такой же шлюз, но уже между облаками. Одни абстракции должны быть заменены другими.

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

Многие бытовые системы я уже упоминал, можно напомнить о LoRaWAN (и TheThingsNetwork), IFTTT, OpenStreetMap, AWS IoT, Azure IoT, сервисы погоды, да, собственно, практически любой сервис Интернета или Интранета(есть еще накой термин?), если данные устройств должны попасть в корпоративные системы.

Интерфейсы пользователей

Я не буду глубоко описывать эту часть, но хочу посокрушаться о, незаслуженно на мой взгляд, обходимых стороной бытовыми системами IoT, десктопах. Только в Mojave наконец вышел HomeKit — для меня это недоумение. Чем чайник сложнее электронных таблиц, в которых я могу рассчитывать Cash Flow какого-то предприятия? Ведь, с Numbers я могу работать в браузере, а вот выключить забытый утюг, в понимании Apple, не должен. Короче говоря, даешь PWA!

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

AR, VR, Mixed Reality, голосовые ассистенты, умные телевизоры, приложения для смартфонов и планшетов, EEG нейроинтерфейсы — это вишенки на торте, с которыми нам, гикам, очень прикольно играться.

Послесловие

Казалось бы, при чем здесь Docker и микросервисы? Если читателям будет интересно, то с удовольствием поделюсь своими размышлениями и наработками в реализации архитектуры системы IoT исходя из этой классификации объектов.

Сам пользуюсь.

Размышления о Манифесте разработчика умных систем