ЖелезоХабрахабр

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хабы

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

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

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

Шлюзы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть