Особенности создания ПО в эпоху Интернета вещей

Интернет вещей (Internet of Things, IoT) стал очередным грандиозным витком эволюции Сети: в 1970-х и 1980-х годах Интернет использовали для соединения компьютеров друг с другом, в 1990-х и 2000-х — для связи между людьми, а в наши дни он служит для соединения всего на свете. Исследования в области Интернета вещей сегодня в основном касаются получения данных, аналитики реального времени, машинного обучения, визуализации и других задач, связанных с Большими Данными [1], однако впереди нас ждет не менее важная, хотя и не такая очевидная перемена — благодаря усовершенствованиям аппаратного обеспечения и доступности мощных недорогих встроенных процессоров появится возможность практически повсеместного внедрения средств связи и полноценных виртуальных машин. В результате обычные предметы: лампочки, дверные ручки, кондиционеры, системы поливки газонов, зубные щетки — объединятся и станут динамически программируемыми. Однако путь от нынешних систем Интернета вещей, полагающихся на данные и облака, к миру, где повседневные предметы соединены с сетью и полностью программируемы, не будет устлан розами — с наступлением этой эпохи у разработчиков ПО появятся совершенно новые сложности.

Конечно, появление виртуальных машин в мобильных телефонах в конце 1990-х само по себе не было революционным техническим достижением, но его следствием стало то, что освоением мобильных платформ занялся широкий круг программистов — и это привело к зарождению многомиллиардной индустрии мобильных приложений. История часто повторяется, и в данном случае параллели с прошлым особенно очевидны, что позволяет предсказать приближение времени, когда можно будет наделять возможностями динамического программирования практически все, что нас окружает [2, 3].

Зарождение универсальной архитектуры Интернета вещей

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

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

Зарождение универсальной архитектуры Интернета вещей. Несмотря на разнообразие, обусловленное большой численностью поставщиков, выходящих на рынок Интернета вещей, некоторые элементы новой архитектуры повторяются во всех системах

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

Шлюзы и концентраторы собирают, предварительно обрабатывают и передают данные от устройств Интернета вещей и их датчиков, применяя различные, как правило беспроводные, коммуникационные технологии — например, Wi-Fi или Bluetooth Smart. Шлюзы обеспечивают защищенную трансляцию протоколов связи между устройствами и облаком, а также могут временно хранить показания датчиков и выполнять другие функции. Кроме того, шлюзы передают запросы на выполнение действий от облака к устройствам.

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

Облачные сервисы, хранилища и аналитические решения являются ключевыми элементами большинства платформ Интернета вещей. В универсальной архитектуре Интернета вещей общего назначения облако играет три основные роли.

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

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

Третья роль — выдача команд на выполнение действий: данные в системах Интернета вещей проходят в разных направлениях, и помимо пересылки показаний датчиков необходимо обеспечить защищенную передачу из облака команд активации подвижных частей устройств.

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

Путь в Программируемый мир

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

Возможности оборудования Интернета вещей растут, цены падают, и скоро наступит время, когда на устройствах практически любых типов можно будет запускать полноценные копии Linux, стеки виртуализованного ПО и среды выполнения динамических языков программирования. Появившиеся сегодня недорогие процессоры уже превосходят по мощности мобильные телефоны конца 1990-х — периода, когда платформа Java 2 Micro Edition инициировала революцию мобильных приложений. Легко предположить, что похожие возможности кросс-платформенного программирования уже скоро будут реализованы и для повседневных вещей.

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

Сам термин «периферийные вычисления» появился в 2002 году и первоначально ассоциировался с развертыванием приложений в сетях доставки контента (Content Delivery Network, CDN). Смысл концепции состоял в использовании граничных серверов CDN для улучшения масштабируемости и снижения задержки передачи. В решениях, основанных на концепции периферийных вычислений, граничные устройства, например маршрутизаторы или базовые станции, используются для предварительной обработки показаний датчиков, а также для локальной отправки уведомлений и команд активации приводов при выполнении заранее заданных условий. Подобные системы могут пользоваться локальными технологиями связи, например Bluetooth Smart или Wi-Fi Direct, для прямого, более эффективного децентрализованного обмена данными между датчиками. Ключевую роль в обеспечении возможности переноса вычислительных задач между элементами сети играют технологии виртуализации.

В таблице представлен прогноз эволюции систем Интернета вещей на предстоящие 10 лет с точки зрения работы с данными и программирования. Таблица составлена на основе анализа актуальных тенденций в отрасли и науке, опыта создания прототипов и готовых продуктов [2, 3], а также ретроспективы развития WWW и мобильных вычислений.

Таблица. Прогноз эволюции систем Интернета вещей

Попробуем теперь подробнее рассмотреть конкретные проблемы, касающиеся программируемости Интернета вещей.

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

Вряд ли когда-то появится глобальный API, который можно было бы применять с техникой Интернета вещей всевозможного назначения для разных вертикальных рынков, но можно с уверенностью предположить, что через пять-десять лет степень унификации API и самих устройств существенно вырастет. Кроме того, скорее всего, необходимая инфраструктура «вырастет» на базе существующей инфраструктуры IP-сетей и WWW, дополнив их технологиями локальной связи и периферийных вычислений.

Отличительные особенности разработки ПО для Интернета вещей

Разработка ПО для Интернета вещей отличается от процессов создания обычных мобильных и веб-приложений по целому ряду характеристик.

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

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

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

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

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

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

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

Сложности могут возникнуть и в связи с тем, что сама предметная область Интернета вещей еще относительно молода.

У нынешних систем Интернета вещей несовместимые друг с другом, «сырые» интерфейсы программирования, а стандартных общеотраслевых API пока нет. В отличие от разработки мобильных и веб-приложений, где конвергенция уже произошла, API для Интернета вещей сегодня обычно предлагаются конкретными производителями для конкретных устройств. В связи с этим сильно осложнено создание ПО, способного работать с различными устройствами и системами разных производителей. Реализуются ряд инициатив по стандартизации, в том числе осуществляемых Консорциумом Промышленного интернета, IPSO Alliance, Open Connectivity Foundation и Open Mobile Alliance, но пройдет еще несколько лет, прежде чем эти проекты достигнут зрелости.

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

Трудности разработки

Обобщая, перечислим теперь особенности, отличающие мир Интернета вещей от разработки мобильных и веб-приложений:

• программирование одновременно множества устройств;
• постоянно работающая система, реагирующая на любые воздействия;
• гетерогенность и разнообразие;
• распределенный, чрезвычайно динамичный характер ПО, вероятность его миграции;
• необходимость создания отказоустойчивого, высокозащищенного кода.

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

Заблуждения относительно распределенных вычислений

Тем не менее среднестатистический разработчик мобильных и клиентских веб-приложений плохо представляет себе сложности, с которыми можно столкнуться при создании приложений Интернета вещей. Среди программистов распространены следующие ложные предположения: сеть надежна; задержка нулевая; пропускная способность неограниченная; сеть защищена; топология не меняется; администратор только один; транспортные расходы нулевые. Такие предположения неизбежно приводят к ошибкам: открытые порты, ожидание соединений с уже недоступными устройствами, расчет на мгновенный отклик, бесконечное ожидание ответных пакетов; перерасход памяти и энергии. В распределенной системе сбой компьютера, о существовании которого вы даже не подозреваете, может вызвать неработоспособность вашего собственного ПК.

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

В целом скрытые затраты на создание и сопровождение ПО для распределенных систем практически всегда недооценивают, однако, согласно исследованиям, на верификацию и тесты может уходить до 75% всех затрат, связанных с разработкой.

Языки и инструменты, не соответствующие требованиям Интернета вещей

Сегодня для Интернета вещей используются практически те же языки и инструменты программирования, что и для мобильной и веб-разработки. В частности, создание кода для популярных сегодня плат Arduino, Espruino, Tessel, Intel Edison и Galileo осуществляется на Си, C#, Java, JavaScript и Python.

JavaScript и его серверная версия Node.js становятся предпочтительными инструментами программирования Интернета вещей ввиду их колоссальной популярности в мире веб-разработки, но это не лучший выбор, поскольку JavaScript не был рассчитан на создание асинхронных распределенных приложений и программирование больших систем. С некоторых пор среди программистов на JavaScript стало расхожим выражение callback hell («кошмар отложенных вызовов»), означающее порождение «многоэтажного» трудночитаемого кода, который приходится писать для вызова асинхронных функций и обработки ошибочных и успешных завершений. Механизм Promises, появившийся в стандарте ECMAScript 6, позволяет частично справиться с этой проблемой. Тем не менее JavaScript — неоптимальный выбор для разработки распределенных систем.

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

Динамичная природа систем Интернета вещей

Сегодня разработка ПО стала скорой и динамичной, большинство приложений соединены с какими-либо сервисами, популярность приобрели динамические языки программирования наподобие Python. С развитием WWW появилась возможность мгновенного развертывания ПО по всему миру — разработчики могут рассылать обновления приложений гораздо быстрее, чем еще десять лет назад. Модель разработки и развертывания DevOps в значительной степени вытеснила более ранние методы автоматизации выпуска ПО и управления инфраструктурой.

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

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

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

Взгляд в будущее с оглядкой на прошлое

Для наступления Программируемого мира будет мало лишь появления нового оборудования, коммуникационных протоколов и технологий, а также методов компрессии и анализа огромных срезов данных. Чтобы полностью реализовался потенциал Программируемого мира, понадобятся новые технологии проектирования и разработки ПО, а также соответствующие процессы, методологии, абстракции и инструменты. Предыдущий опыт разработки распределенных систем и критически важного ПО поможет избежать дублирования усилий, чтобы не «изобретать велосипед». В целом проблемы необходимо решать, обучая программистов пониманию того, в чем разработка для Интернета вещей принципиально отличается от создания мобильных и веб-приложений.

Безопасность

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

***

На данный момент программирование систем Интернета вещей в основном возможно с помощью специализированных приложений, созданных самими производителями соответствующего оборудования. К примеру, лампочками Philips можно управлять посредством приложения Philips Hue, а компании GE и Cree разработали собственные приложения для контроля предлагаемых ими систем освещения. Но принцип «отдельное приложение для каждого устройства» препятствует масштабированию и обречен быть лишь временным решением до появления соответствующих отраслевых стандартов.

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

Литература

1. R. Stackowiak et al. Big Data and the Internet of Things: Enterprise Information Architecture for a New Age, Apress, 2015.
2. P. Selonen, A. Taivalsaari. Kiuas: IoT Cloud Environment for Enabling the Programmable World. Proc. 42nd Euromicro Conf. Software Eng. And Advanced Applications (SEAA 16). — 2016. — P. 250–257.
3. F. Ahmadighohandizi, K. Systa. Application Development and Deployment for IoT Devices. To be published in Proc. 4th Int’l Workshop Cloud for IoT (CLIoT 16), 2016.

Антеро Тайвалсаари (antero.taivalsaari@nokia.com) — научный сотрудник Nokia; Томми Микконен (tommi@mozilla.com) — профессор, Хельсинкский университет.