Тред про то, как делают девайсы
После того, как придумали, а что, собственно делать, появляется 2 трека — физический девайс (собственно, hardware), и software, который на нем бегает и поддерживает жизнь
Execution по hardware — это интересная задача, которая требует крутого проджект менеджера. Там реально нужны ninja skills по контролю кучи людей (в том числе партнеров и поставщиков), заэстимейтам всех фазы разработки, а потом смэтчить software и hardware
Любое замедление и отклонение от плана — это потенциальное попадание компании на деньги (например, потому что нечего продавать, или потому что закоммитились на мощности производителя, которые из-за задержек не используются)
Все начинается с дизайна борды (платы). Примерно сразу же встает выбор между "делать быстро, но не очень кастомно", и "долго и дорого, ЗАТО СВОЕ". (Single Board Computer vs System on a Chip)
SBC это борда с компонентами, которую кто-то уже сделал. Опционально типовую SBC допилят под вас, и это точно будет быстрее, чем спроектировать свое с нуля (time to market!). Хороший пример SBC — Raspberry Pi. Плюс в том, что SBC уже производят, и добрая часть проблем уже решена
SoC дает максимальную гибкость, но требует серьезной экспертизы в не только в проектировании плат, но и в умении просчитывать "а что же будет дальше" при принятии технических решений. У каждого варианта есть плюсы и минусы, но в целом это гибкость против тупой надежности
Если нет полноценной in-house команды проектировщиков hardware, лучше выбирать SBC. Конечно же, у нас этой самой команды не было (но была экспертиза CTO и пары человек, которые имеют скиллы и в этой области).
Конечно же, мы выбрали SoC. Ощущения от процесса незабываемые, некоторые из них очень не хочется повторять никогда. Но было весело :)
Стоило выбрать SoC хотя бы потому, что это красиво!
Важнейшая часть разработки — промышленный дизайн. Это очень важная часть продукта, которая прямо влияет на бренд и пользовательский опыт. А еще она очень плотно интегрирована с hardware и помогает (либо мешает) ему.
Отличный пример — охлаждение. Можно сделать красивый компактный дизайн, который не учитывает нагрев борды, и не дает воздуху уходить, и троттлит девайс. То же самое касается прочности кейса и всей конструкции (не круто разваливаться на куски от падения с метра).
Важно понимать, что все принятые решения по предыдущим пунктам (особенно плохие) с вами навсегда. Недостаточно яркий LED, плохо прожимающаяся кнопка резета, корпус, который на определенных сценариях разогревается до 90 градусов.
В этом, как мне кажется, главное отличие hardware от чистых software продуктов. Плохие технические решения в условных веб-сервисах стоят денег бизнесу и нервов разработчикам, но как правило не пробиваются в материальный мир и не ощущаются юзерами физически.
Конечно, можно быть как Apple, и объяснять что все окей и вообще вы holding it wrong. Но, скорее всего, вы не Apple ¯_(ツ)_/¯
Многие косяки можно пытаться чинить софтварно. Но это применимо далеко не для всех продуктов, и обычно все равно получается херня. Кейс Boeing 737 MAX и из ничего троттлящий Macbook на i9 — яркие примеры решения хардварных проблем софтварными способами.
Но давайте представим, что мы знаем, какая (в светлом будущем) будет борда. В этом случае все приличные партнеры предоставляют development kit, где борда не такая же, но на той же архитектуре и похожая, а еще живая и рабочая. А это значит, что можно начать писать для нее софт.
До определенного момента разработчки работают с dev бордой и пишут под нее. Потом есть стадия bring up, когда первые экземпляры живых плат готовы, и нужно на них запустить софт. Конечно, сначала ничего не работает, но потом медленно начинает.
Как правило, у борды есть несколько итераций (spins) разработки. Отличаются они в основном наборов компонентов, и добавлением некоторых компонентов на поздних стадиях. Условный Ethernet порт могут выбрать ставить последним, если так почему-то проще
Про software я расскажу в другой день, потому что операционка, которая бегает на девайсах, это отдельная большая тема. Там куча вариантов в зависимости от бизнес-потребностей. Как правило, software на девайсе Linux/Android-based
Еще бывает, что бегает RTOS, но (к сожалению) с таким поработать пока не удалось
А пока давайте представим, что есть и дизайн, и борда готова, и софт работает. Время выпускать?
А вот и нет, сначала сертификация. В зависимости от того, что умеет продукт, она может быть сложной или очень сложной.
Сертификация — это злой процесс. На бумаге он выглядит просто — заключаешь контракт с теми, кто занимается сертификацией (certification house), платишь деньги, пьешь чай, а они все делают за тебя.
К сожалению, в реальном мире так не работает; в зависимости от компетенций certification house какие-то части могут длиться 3 месяца вместо обещанных 2 недель, скоуп постоянно растягивается, находятся проблемы, которые мешают сертификации, и нужно все больше денег
В случае беспроводных продуктов необходима отдельная сертификация для US (FCC) и Европы (она попроще).
Про ужасы сертификации я мог бы писать неделю, но просто скажу, что на это нужно закладывать кучу внутренних ресурсов, потому что в один прекрасный день половина команды разработки может начать писать тестовые скрипты, или тюнить software так, чтобы сертификаторы в принципе
могли что-то проверить. И лучше умножать сроки не на 3.14, а примерно так на 10.
Никита Таныгин