IoT. Попытка навести порядок (в голове) № N+1 (часть 2)

Продолжу предыдущую запись без лишних вступлений. Кроме одного – все приводимые в тексте ссылки достойны прочтения.

Проблема «владельца предмета» в IoT имеет одну совсем малозаметную, и потому очень неприятную, особенность. Дело в том, что владельцев у предмета может быть много, а факт самого «владения» – временный. С этим уже столкнулись первопроходцы и практикующие специалисты в самых близких смежных областях.

Например, при создании масштабных систем, основанных на технологиях «маячков» (iBeacon и подобных). Такие системы, несмотря на невысокую популярность в тематической прессе, существуют и работают, а «недостаток шума» о них больше связан с принципиально «неприбыльным» характером их надсистем, чем с технологической простотой.

Большие инсталляции систем, использующих «маячки» (схожие во многих нюансах, например, с инсталляциями сенсорных сетей), стали атрибутом и практикой крупных музеев, например. И позволили вскрыть самые простые, даже очевидные (если хорошо подумать прежде чем начать делать), вещи.

У сети маячков (и у каждого из них) в ходе эксплуатации появляются несколько «владельцев». Создатели системы со временем от неё «отдаляются», зато приходят, например, эксплуатационные и ремонтные службы, далёкие от всяких информационных технологий. И тут всплывает «внезапно ужасное» – производители маячков, например, не наносят на них никакой уникальной информации (хотя бы штрих- или QR-кода), позволяющей неспециалисту быстро и просто вскрыть связь конкретного маячка с местом его установки (и всем прочим, связанным с ним) даже если есть какая-то система, хранящая такую информацию. Вся стройная цепочка «маячок (сенсор) – место установки – семантика» разрушается, и никто из «владельцев» системы не может эту цепочку восстановить без обращения к создателям системы.

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

К этому моменту мы располагаем куда большим информационным полем для дальнейших рассуждений. Это очень важно, потому что в реальных IoT-проектах уже наблюдается «приземляющее» фантазёров ужесточение требований, причём самых критичных.

Поясню о чём идёт речь на примере объявленного властями города Сан Хосе «аукциона» проекта модернизации уличного освещения. Городские власти хотят заменить 40 тысяч устаревших уличных фонарей на современную IoT-систему светодиодного освещения. Фрагменты её, содержащие более 23 тысяч фонарей, уже модернизированы за счёт грантов и в рамках демонстрационных (читать рекламных) проектов. Теперь наступил коммерческий этап. Но с одним очень хитрым условием-требованием «сурового реализма» - владелец системы должен сам создать механизм её окупаемости.

То есть, все возвышенные слова о «передовитости IoT» - это безусловно хорошо, но ROI – то, что решается владельцем системы.

Нет никаких оснований думать, что подход властей Сан Хосе станет исключением из правил. Скорее, наоборот. Можно считать этот пример одновременно подтверждением сказанному ранее. И об обязательной или гениальности IoT-разработчиков, или необходимости создавать принципиально новые «предметы. И о характере «IoT value», о той самой побочной информации, приобретающей самостоятельную ценность по мере развития IoT систем. Последнее не совсем очевидно, но никто пока не знает в какой большой автоматизированной (или даже роботизированной) системе кому и зачем может понадобиться что-то от системы управления городским освещением. И эта фраза вовсе не утверждает, что «никому» и «ни для чего». Просто мы говорим о системах такого масштаба и такой новизны, с какими ранее не сталкивались. Что означает и высокие риски, и огромные возможности.

Возвращаемся к конкретике. Итак, у «предмета» есть множественные владельцы, «предмет» существует в надсистеме, специфические потребности владельцев, свойства надсистемы и самого «предмета» формируют требования (критерии) к IoT-подсистеме, в первую очередь к гарантируемому ею общему времени реакции на какие-то обнаруженные изменения в состоянии предмета и надсистемы. Это несколько больше, чем просто квадратик «сенсор» на диаграмме.

Время реакции определяет чуть ли не всё. Начиная от общей архитектуры IoT-системы, и заканчивая деталями и нюансами на самых нижних уровнях проекта. И осторожное эволюционное понимание термина IoT, например, принятое немецкими специалистами (Industry 4.0, TL;DR, но очень интересный текст), в громком слове «революция» на деле подразумевает оправданно и обоснованно ожидаемый эффект, а не набор архитектурных решений и рекомендованных деталей реализации.

Что ещё интереснее (несмотря на всё ту же неприятную очевидность) – такое абстрактное понятие, как «время реакции», косвенно определяет возможные диапазоны большого числа конкретных критериев, например, требованиям к источнику питания, к каналам связи и их исполнению etc. Конкретные цифры привести трудно, но уже есть некоторые пограничные оценки, отражающие сегодняшнюю ситуацию. Так, если время реакции IoT системы в целом должно быть на уровне 0,1 с, то сегодня лучше забыть о беспроводных сетях и, тем более, о беспроводных меш (многохоповых) сетях. Также в беспроводных сетях существует неявное косвенное требование к источникам питания, обусловленное временем реакции системы в целом – чем оно ниже, тем большей должна быть ёмкость источника питания, и даже при одной секунде, естественно, ни о каких крохотных литий-ионных аккумуляторах-«таблетках», обеспечивающих годичное время работы, тоже лучше не фантазировать.

Такие пороги ограничивает сверху область традиционных M2M систем (Machine 2 Machine Communication), а в ней каких-то взрывных изменений никто не ожидает. Но этот факт даёт и дополнительную информацию – в масштабных IoT системах M2M подсистемы могут быть (и должны быть) равноправными и полноценными фрагментами единой архитектуры. Именно это частично и подразумевается в концепции Industry 4.0, и именно для этого классические разработки из мира M2M адаптируются для IoT-применений (например, коммуникационный протокол OPC UA, реализации которого являются фундаментальными для систем промышленной автоматики и M2M).

Влияние фундаментального принципа «владения предметом» на подсистемы безопасности заслуживает отдельной записи, здесь и так слишком много информации «для размышлений».

Для компенсации нагрузки – короткий обзор «продуктовых» тематических новостей, совершенно непрофильных для «большой IT». Несмотря на очередное колебание спроса на электронные компоненты и постоянно увеличивающееся число моделей 32-битовых встраиваемых вычислителей, рынок показывает стабильный рост популярности малоразрядных (8 и 16 битов) микроконтроллеров. Объяснение феномену, вероятнее всего, простое – производители буквально «напичкивают» эти устройства интегрированной автономной интеллектуальной периферией, что при низкой цене даёт возможность относиться к ним как к «программируемым дискретным компонентам». И, конечно, сказываются десятилетия опыта разработчиков. Свежий яркий пример – обновление семейства 8-битовых контроллеров Laser Bee компании SiLabs. Казалось бы, видимой программисту архитектуре процессорного ядра этих вычислителей примерно 35 лет (полная совместимость с i8051, модернизации затрагивают только реализацию архитектуры – большинство команд стало однотактовыми, а тактовая частота повысилась до 75 MHz). И на её основе фактически в 2016 году, когда доступна масса копеечных 32-битовых конкурентов, прекрасно поддержанных средствами разработки (например, на ядре ARM Cortex M0), анонсируется целое новое семейство контроллеров. Разгадка такой алогичности проста – конструкторы SiLabs «утрамбовали» в Laser Bee большой «швейцарский нож» аналоговой и прочей периферии, 14-битовый многовходовый аналогово-цифровой преобразователь (ADC), до четырёх 12-битовых цифро-аналоговых (DAC), отдельный 6-битовый DAC, подключенный к входам двух компараторов (аналоговая микросхема, сравнивающая значения напряжений на двух входах и выдающая дискретный результат сравнения), температурный датчик, маленькие, но достаточные для реальных потребностей программируемые логические матрицы, позволяющие переопределить назначение физических выводов микросхемы для удобства проектирования печатной платы. Ещё один характерный пример – обновление Microchip своего 16-битового семейства микроконтроллеров PIC24 моделями с мегабайтом флеш-памяти программ. Мегабайт – это очень много во встраиваемых приложениях. Огромная цифра, потому что в пару десятков килобайтов обычно помещается всё что нужно для реализации иногда очень вычурной функциональности, загрузчик, реализация какого-то M2M протокола и даже что-нибудь для обеспечения надёжности. По-видимому, уже 16-битовые встраиваемые вычислители более чем достаточны и востребованы для аппаратной поддержки реально больших программных систем, раз конструкторы и менеджмент Microchip решились на такой шаг. Ну и, наконец, совсем характерная для IoT новая линейка микросхем от Texas Instruments - SimpleLink CC1310. Это однокристальные гибриды микроконтроллера с полным низкочастотным (до 1 GHz) радиоканалом. Причём процессорное ядро для них выбрано далеко не самым слабым – ARM Cortex M3, а специфический радиоканал позволяет при сочетании массы условий и грамотной реализации всего остального добиваться устойчивой связи на многокилометровых дистанциях. И всё это «упаковано» в крохотный 16-выводный корпус. В этом коротком обзоре забавно, что объём памяти программ у этих микросхем «всего» 128 KB, и он вполне разумен и достаточен для реализации RTOS, стека протоколов и основной функциональности какого-то устройства. Это позволяет представить «программистские возможности» в огромном 1 MB кода программ PIC24 (сравнение тем более допустимо, что, несмотря на 32-битовость рабочих регистров и данных, Cortex M3, как и PIC24, исполняет 16-битовую систему команд).

Такая разносторонняя картина получилась сама собой, просто из анонсов за несколько дней.

TBC

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365