Салют, Хабр! 

Меня зовут Алексей, я руководитель 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

Proof-of-Content — это постоянная проверка команды на креативность и понимание пользователя. Разработчики программного обеспечения, разумеется, активно участвуют в этом процессе.  

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

ES. Engineering Samples

Когда готова первая версия платы, задача команды разработки программного обеспечения — провести первичный bring up: запустить её и отладить. Для этого необходимо:

• углубленно изучить Software Development Kit и datasheet на отдельные компоненты;

• внедрить уже существующие драйвера или написать свои собственные. При этом драйвер на этом этапе не обязательно должен быть полнофункциональным. Скорее нужно убедиться, что с девайсом можно будет работать именно так, как задумано — например, обмениваться с компонентом данными через SPI и в свою очередь получать по команде какие-то данные.

На pre-ES у нас есть только платы. На ES уже появляются первые прототипы корпуса. Поднимать прошивку мы можем начать в любой из этих моментов. Если «железо» — например, SoC, память DDR, Flash, беспроводные/проводные интерфейсы, датчики — не новое для технических команд, можем даже запустить уже дышащую прошивку. Кроме того, необходимо настроить бэкенды для работы с новым девайсом, чтобы убедиться, что прошивка в целом работает на устройстве плюс провести тесты на текущих образцах. В среднем на этом этапе создаётся 20-30 экземпляров прототипа. Они позволяют оценить внешний вид устройства и запустить далее производство туллинга.

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

EVT, или Engineering Validation Test

Тут нужно забежать вперёд: на производстве для проверки умных устройств Sber применяют специальные тестовые стенды. Мы называем их чемберами (chamber), так как иногда они представляют собой радио- и звуконепроницаемые камеры. В чемберах тестируют железо — хорошо ли работает Wi-Fi-чип, правильная ли амплитудно-частотная характеристика у динамика умной колонке — а также готовят устройство к работе у конечного пользователя. На EVT-этапе мы работаем не только с программным обеспечением самого девайса, но и с ПО чемберов. Его нужно адаптировать под конкретный продукт: определить, где требуются доработки, а что можно переиспользовать. Для экономии времени при переделке софта чемберов под каждое новое устройство используется специальный компонент. Это высокоуровневая абстракция для работы чембера с хардвером девайса, благодаря которой тесты одного продукта можно с минимальными доработками использовать для другого.

Кроме того, мы разрабатываем защищённую версию прошивки с проверкой целостности исполняемого кода и закрытыми отладочными интерфейсами. Она необходима для первого бета-тестирования, которое тоже проходит на EVT-этапе: сотрудники испытывают устройства дома и дают свой фидбэк. Мы понимаем, как продукт работает в реальных условиях, а не на столах разработчиков и стендах. На этом этапе существует уже порядка 50 прото-устройств. 

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

DVT — Design Validation Test

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

В-третьих, доводя factory-прошивку до идеала, мы одновременно смещаем фокус работ на prod-прошивку. Именно её получит девайс, когда пользователь обновит его. Прошивка, которая попадает на устройства первых пользователей — это так называемая 0-day-prod. Туда включены все фичи, которые поддерживаются устройством: от привычных до новых, которые намечены к старту продаж. 

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

Параллельно дорабатываются все компоненты, которые будут работать с новым девайсом. Даже если сам функционал не нуждается в доработке, нужна поддержка нового устройства, нужно провести e2e-тесты. 

DVT-этап закончен, когда:

• финально утверждены внутренний и внешний дизайны устройства;

• мы передали на фабрику factory-прошивку, а также тестовую и настроечную оснастку;

• (опционально) ещё и начали пользовательское тестирование prod-прошивки.

PVT — Production Validation Test

Ниже небольшая шпаргалка: что софтверная команда делает на каждом этапе.

Заключение

Конечно, это верхнеуровневый рассказ о разработке программного обеспечения для умных устройств Sber (если вдаваться в детали, придется писать книгу). При разработке прошивки существует высокая доля вариативности. Например, можно на  DVT-этапе передать на фабрику промежуточную factory-прошивку, функций которой достаточно для отладки производства, а целевую сдать уже на этапе PVT. 

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

В подготовке статьи участвовали: @kpvf2d, @rockosov, @olegartys, @HallEffect, @kuro3kin