Как правильно управлять ІоТ-проектами

В классическом ИТ обновление ПО – это нажатие кнопки. В ІоТ же это действие превращается в логистическую операцию по удаленной доставке обновлений, которую планируют еще на этапе разработки железа. Именно в этом и заключается фундаментальное отличие интернета вещей от всего, к чему привыкла ИТ-индустрия. О том, как устроен жизненный цикл ІоТ-оборудования, и почему управлять им по правилам классического ИТ – заранее готовить почву для провала, IT-World рассказывает Вячеслав Шириков, технический директор ГК Лартех

Два цикла, которые никогда не совпадают

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

Как правильно управлять ІоТ-проектами. Рис. 1

Обзор российского рынка Интернета вещей (IoT)

Синхронизировать нужно не этапы разработки, а общую философию продукта, иначе каждая из групп специалистов будет двигаться в своем направлении и темпе: и встретятся они только на финишной прямой – ленте конвейера – где что-то менять будет уже поздно. Если разработчики прошивки закладывают новый пользовательский сценарий, а железо его физически не поддерживает, то задумка будет обречена на гибель. А теперь представьте, что устройство уже выпущено десятками тысяч штук и разошлось по объектам заказчиков, часть из них стоит без связи в подвалах или полях, и каждое из них должно исправно работать следующие 7-10 лет.

Последствия такого рассинхрона могут быть катастрофическими.

В 2023 году один из городов в Техасе столкнулся именно с этим сценарием. Почти 87 тыс. электронных модулей учета воды, рассчитанных на 20 лет службы, начали преждевременно разряжаться. Вендор расследовал причины инцидента год, и выпустил программное исправление, которое должно было починить батареи удаленно. Но после его установки более 73 тыс. устройств вышли из строя. Город был вынужден экстренно выделить бюджет в сотни тысяч долларов для снятия показаний счетчиков вручную. Полные сроки восстановления системы по состоянию на начало 2026 года остаются неопределенными.

Именно для того, чтобы не допускать таких разочаровывающих ситуаций, в ІоТ-проектах используется подход Stage-Gate: вводятся жесткие контрольные точки, в которых команды аппаратной и программной разработки сверяются друг с другом и могут двигаться дальше только при соответствии заранее оговоренным критериям. Показательный пример того, как выстроенная система управления парком устройств работает в масштабе, – Toyota Material Handling, которая управляет более чем 300 тыс. подключенных вилочных погрузчиков по всему миру. Когда выяснилось, что в ряде стран, в частности в Бразилии, законодательство запрещает постоянный роуминг, компания не стала менять SIM-карты в каждом устройстве вручную и договариваться с операторами в каждой юрисдикции отдельно. Вместо этого была внедрена единая SIM-карта, автоматически переключающаяся между режимами работы в зависимости от страны. Именно такая методичная инженерная работа на этапе проектирования и отличает зрелый IoT-продукт.

Память и энергия: как аппаратные ограничения диктуют правила

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

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

Еще одна трудность – каналы связи, которые в ІоТ отличаются от привычной ИТ-инфраструктуры. Даже если сервер подключен к сети постоянно и надежно, то ІоТ-устройство на батарейках может выходить на связь строго по расписанию: раз в несколько дней, через радиоканал, а иногда и вовсе только тогда, когда окажется в зоне покрытия. Из этого следует неочевидный вывод: не нужно проектировать систему, работающую в реальном времени. Нужно создавать механизм, который допускает задержки и понимает «синхронность» как переход всего парка в новое состояние в течение предсказуемого интервала, а не в конкретную секунду. Такой подход делает систему действительно устойчивой – конечно, при условии, что он заложен с самого начала, а не добавлен позже как вынужденный компромисс.

От прототипа до парка: как не утонуть в логистике

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

Масштабирование ІоТ-парка отличается от создания ИТ-инфраструктуры еще и тем, что устройства расползаются по огромной территории, и вместе с ними должна масштабироваться инфраструктура связи, причем синхронно. На практике это правило регулярно нарушается. Базовые станции ставят одни подрядчики, а устройства монтируют другие. Позже выясняется, что они просто не слышат друг друга. Управление цепочками поставок в такой ситуации превращается в отдельный квест: риск того, что через несколько месяцев, когда устройство готово к серийному производству, какой-либо компонент окажется недоступным на рынке, составляет от 30% до 80%.

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

Жизнь после релиза: как не потерять устройство из виду

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

Заказчик ожидает, что система проработает 10 и более лет. За такой срок в парке неизбежно будет сосуществовать дюжина версий прошивки и три-четыре вариации аппаратной части – фактически несколько поколений одного устройства одновременно. Чем заканчивается игнорирование этой реальности, хорошо показывает история умных счетчиков воды в Кении. Устройства были закуплены, установлены и... брошены. Вендор прекратил поддержку продуктов, прошивки перестали обновляться, а у местных специалистов не было ни доступа к диагностическим инструментам, ни исходного кода устройств. Работающая инфраструктура превратилась в бесполезные килограммы оборудования, просто потому что никто заранее не подумал, кто и как будет все это обслуживать после установки.

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

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