Салют, Хабр!
Меня зовут Алексей, я руководитель SW TPM Team — отвечаю за программное обеспечение умных колонок Sber, а также устройств Умного дома Sber.
Разрабатывая девайсы, мы проходим полный цикл создания устройства: ES, EVT, DVT, PVT-этапы. Это международный инженерный фреймворк, его использует множество компаний. Но акцент во фреймворке на валидации и доработке хардверной части. О том, что в рамках каждого этапа требуется от софта, говорят мало и редко. Поэтому расскажу, как мы вписываем разработку программного обеспечения в основные этапы разработки «железа» и что требуют от software-команды на каждом этапе создания умных устройств Sber. Если вы хотите разрабатывать софт в хардверной компании или уже занимаетесь этим, но пока не работали в рамках фреймворка полного цикла — точно будет интересно.
Дисклеймер: статья написана с воспоминаниями, как давным-давно я сам, работая в хардвер-стартапе, мучительно искал подобный текст и не нашёл.
Рождение продукта, или С нуля до прода
Короткое напоминание, из чего состоит «полный цикл создания устройств». В сумме это бесконечный процесс поиска и пять основных этапов, которые проходит хардверная компания, превращая идею в продукт. Названия этапов в очередной раз доказывают, что инженеры любят аббревиатуры.
Внимание: ниже описан исключительно сам процесс разработки полного цикла в общих чертах. Продуктовые требования и брифы, UX-исследования с пользователями, стратегические решения бизнеса, оптимизация себестоимости устройства не рассматриваются. Как и тот факт, что разработка софта подчиняется инженерному фреймворку — но не ограничивается им.
PoC, Proof-of-Concept — проверка гипотез
Процесс постоянный, цикличный и не привязанный к конкретной категории устройств. Участники подают идеи, которые всесторонне рассматривают и, если видят в них потенциал, превращают в гипотезы, в прототип/прототипы, иногда даже в MVP — минимально жизнеспособное решение. Затем решается, стоит ли превращать эту идею в продукт или она не готова к реализации (в этом виде либо вообще). На выходе компания принимает решение о начале разработки конкретного продукта.
Pre-ES + ES, Engineering Samples — этап инженерного прототипирования
На pre-ES этапе разработана предварительная электрическая схема, появляется предварительный BOM (bill of materials) — список компонентов, которые потребуются для его создания. А на ES-этапе уже становится понятен технический и продуктовый облик будущего устройства.
EVT, Engineering Validation Test — инженерное тестирование
Стадия активной разработки прошивки будущего устройства. Вместе с тем команды начинают проверять работу устройства как единого целого и его основных компонент. Девайсы, которые в итоге на руках у разработчиков, уже схожи с финальными: они исправно выполняют свои основные функции. Значит ли это, что больше ничего не изменится? Разумеется, нет.
DVT, Design Validation Test — валидация механического дизайна
В ходе DVT-этапа устройство приобретает свой финальный вид. На этом же этапе проверяют, что конструкция оптимальна, девайс соответствует всем стандартам, физика безупречна, он нравится нам на вид и наощупь. Далее работа хардверной команды по сути завершена.
PVT, Product Validation Test — отладка производства
Когда само устройство готово, нужно обеспечить его массовое производство. На этом этапе настраиваются производственные линии и линия контроля качества (QC): организовывается система проверок уже собранных устройств. Производится первая тестовая партия товаров, чтобы проверить, насколько корректно работает конвейер.
MP, Mass Production — массовое производство
Включаю его в список, потому что софтверная команда продолжает работу. Хотя устройство уже в продаже, это не значит, что мы перестаём реализовывать дополнительные фичи, выпускать обновления прошивки и патчить прошивку.
А теперь — об этих этапах, какими их видит софтверная команда, и о том, что мы делаем на каждом этапе.
PoC, или Proof-of-Concept
Как уже упоминалось, PoC нельзя назвать этапом. Это постоянный процесс поиска новых идей и решений. Гипотезы рождаются всюду: у инженерной команды и в лаборатории, у бизнес-заказчиков и C-level. Команды аккумулируют перспективные гипотезы, затем начинают тестировать их. Условно, возникает гипотеза — будет ли пользователю интересно и комфортно взаимодействовать с виртуальным ассистентом, который установлен в игрушечном роботе? Для проверки нужно найти робота, доработать, интегрировать ассистента, показать всем прототип и сделать выводы, чтобы решить дальнейшую судьбу гипотезы.
Proof-of-Content — это постоянная проверка команды на креативность и понимание пользователя. Разработчики программного обеспечения, разумеется, активно участвуют в этом процессе.
В итоге отобранный набор гипотез попадает в продуктовый бриф нового устройства, и начинается непосредственно его разработка.
ES. Engineering Samples
Технически его можно разделить на два — pre-ES, который мы считаем стартом проекта разработки устройства, и собственно ES. С точки зрения программного обеспечения, а значит, и команды software, это крайне интересная часть: на pre-ES этапе у нас уже появляются первые платы! А также электрическая схема и перечень компонентов, которые соответствуют планируемым в массовом производстве. На этом этапе плата скорее напоминает макетную — её размер и компоновка составляющих не совпадают с итоговыми. Ниже фотография pre-ES-образца колонки SberBoom Home.
Когда готова первая версия платы, задача команды разработки программного обеспечения — провести первичный bring up: запустить её и отладить. Для этого необходимо:
углубленно изучить Software Development Kit и datasheet на отдельные компоненты;
внедрить уже существующие драйвера или написать свои собственные. При этом драйвер на этом этапе не обязательно должен быть полнофункциональным. Скорее нужно убедиться, что с девайсом можно будет работать именно так, как задумано — например, обмениваться с компонентом данными через SPI и в свою очередь получать по команде какие-то данные.
На pre-ES у нас есть только платы. На ES уже появляются первые прототипы корпуса. Поднимать прошивку мы можем начать в любой из этих моментов. Если «железо» — например, SoC, память DDR, Flash, беспроводные/проводные интерфейсы, датчики — не новое для технических команд, можем даже запустить уже дышащую прошивку. Кроме того, необходимо настроить бэкенды для работы с новым девайсом, чтобы убедиться, что прошивка в целом работает на устройстве плюс провести тесты на текущих образцах. В среднем на этом этапе создаётся 20-30 экземпляров прототипа. Они позволяют оценить внешний вид устройства и запустить далее производство туллинга.
В ходе pre-ES и ES команда разработки программного обеспечения должна убедиться, что сможет программно работать с этой схемотехникой и с этими компонентами. И можно переходить к следующему шагу.
EVT, или Engineering Validation Test
На руках у нас уже есть EVT-образцы. В корпусе размещены платы и другие компоненты будущего устройства — динамики, датчики… На этом этапе софтовая команда должна заняться (если ещё не занялась) созданием factory-прошивки — той, что будет зашиваться во время производства. В зависимости от устройства factory-прошивка может обладать самой разной функциональностью. Чаще всего её функции ограничиваются подключением к Интернету, активацией конкретного девайса и скачиванием «по воздуху» prod-прошивки.
В ходе разработки на factory-прошивке QA комплексно начинает тестировать устройство на предмет выполнения требований, описанных в PRD. Product Requirement Document — это бриф, который составили перед ES-этапом.
Тут нужно забежать вперёд: на производстве для проверки умных устройств Sber применяют специальные тестовые стенды. Мы называем их чемберами (chamber), так как иногда они представляют собой радио- и звуконепроницаемые камеры. В чемберах тестируют железо — хорошо ли работает Wi-Fi-чип, правильная ли амплитудно-частотная характеристика у динамика умной колонке — а также готовят устройство к работе у конечного пользователя. На EVT-этапе мы работаем не только с программным обеспечением самого девайса, но и с ПО чемберов. Его нужно адаптировать под конкретный продукт: определить, где требуются доработки, а что можно переиспользовать. Для экономии времени при переделке софта чемберов под каждое новое устройство используется специальный компонент. Это высокоуровневая абстракция для работы чембера с хардвером девайса, благодаря которой тесты одного продукта можно с минимальными доработками использовать для другого.
Кроме того, мы разрабатываем защищённую версию прошивки с проверкой целостности исполняемого кода и закрытыми отладочными интерфейсами. Она необходима для первого бета-тестирования, которое тоже проходит на EVT-этапе: сотрудники испытывают устройства дома и дают свой фидбэк. Мы понимаем, как продукт работает в реальных условиях, а не на столах разработчиков и стендах. На этом этапе существует уже порядка 50 прото-устройств.
Испытывая прототипы девайса, выявляя их проблемы, исправляя их в конструкторской документации, мы плавно переходим к окончательному варианту продукта и окончанию разработки железной части.
DVT — Design Validation Test
В ходе DVT- этапа происходит финальное утверждение внешнего и внутреннего дизайнов устройств — у нас примерно 100 образцов. И это довольно хлопотный для команды разработки программного обеспечения этап.
Во-первых, устройства с factory-прошивкой проходят внутреннее пользовательское тестирование — более масштабное, чем на EVT-этапе. Нужно довести factory-прошивку до идеала. Напомню, что она зашивается на этапе производства — её нельзя будет изменить на уже готовых девайсах. Кроме того, на этом этапе factory-прошивка проходит аудит безопасности.
Во-вторых, этот вариант софта уже начинает обмениваться данными с различными компонентами: бэкендами, мобильным приложением Салют. Следовательно, к началу тестирования новый продукт должен быть готов взаимодействовать со всеми необходимыми компонентами, хотя бы на тестовых средах. Factory-прошивка проходит тесты, в том числе внутренние в тестовой камере — такие же, какие на этапе PVT будут проводить на фабрике. Проходит финальные испытания с участием заинтересованных сторон, они же ПСИ — приёмо-сдаточные испытания. Только после этого она готова к передаче на фабрику для отладки производства девайса.
В-третьих, доводя factory-прошивку до идеала, мы одновременно смещаем фокус работ на prod-прошивку. Именно её получит девайс, когда пользователь обновит его. Прошивка, которая попадает на устройства первых пользователей — это так называемая 0-day-prod. Туда включены все фичи, которые поддерживаются устройством: от привычных до новых, которые намечены к старту продаж.
К началу пользовательского тестирования prod-прошивки все компоненты системы, взаимодействующей с устройством, должны быть протестированы QA и готовы к работе. При этом некоторые функции устройства могут подъехать чуть позже, чем начинается тестирование. Например, пользователи начинают проверять управление состоянием умных встраиваемых выключателей Sber, а изменение цвета LED-индикатора мы добавляем чуть позже, обновив прошивку по воздуху.
Параллельно дорабатываются все компоненты, которые будут работать с новым девайсом. Даже если сам функционал не нуждается в доработке, нужна поддержка нового устройства, нужно провести e2e-тесты.
DVT-этап закончен, когда:
финально утверждены внутренний и внешний дизайны устройства;
мы передали на фабрику factory-прошивку, а также тестовую и настроечную оснастку;
(опционально) ещё и начали пользовательское тестирование prod-прошивки.
PVT — Production Validation Test
У нас на руках 100-200 PVT-устройств, которые идентичны MP-девайсам. На этом этапе изменения вносятся только в производство — донастраивается и оптимизируется оборудование, а мы тем временем завершаем проверку программного обеспечения, то есть prod-прошивки.
Когда мы прошли все необходимые тесты и проверили пользовательские сценарии, устройство готово к продажам. 0-day-prod прошивка загружается на бэкенд для обновления программного обеспечения у первых покупателей устройства. Комплексно проверяются все компоненты, исправляются последние баги. Готово! Впереди дальнейшие улучшения прошивки, выпуски новых фичей… но они работают по другим процессам.
Ниже небольшая шпаргалка: что софтверная команда делает на каждом этапе.
Заключение
Конечно, это верхнеуровневый рассказ о разработке программного обеспечения для умных устройств Sber (если вдаваться в детали, придется писать книгу). При разработке прошивки существует высокая доля вариативности. Например, можно на DVT-этапе передать на фабрику промежуточную factory-прошивку, функций которой достаточно для отладки производства, а целевую сдать уже на этапе PVT.
Общие принципы всегда остаются одинаковыми. Однако у каждой компании, как у самурая, свой путь: они неизбежно проходят все эти этапы самостоятельно, чтобы на практике настроить процессы, которые подойдут конкретно им.
В подготовке статьи участвовали: @kpvf2d, @rockosov, @olegartys, @HallEffect, @kuro3kin
