Гайд з розробки hardware-продуктів. Від ініціації програми до старту продажів

Вітаю всіх. Я Олександр Кузьмюк, Technical Program Manager у R&D центрі SQUAD. Наша команда займається дослідженнями та реалізацією проєктів у сфері сучасних систем безпеки розумного дому та Інтернету речей.

В Україні дуже добре розвинений ринок розробки software-продуктів. Водночас компанії, які розробляють масові споживчі hardware-продукти, можна перерахувати на пальцях. І мало хто має дійсно широке уявлення про те, як виглядає розробка саме «заліза».

Сьогодні ми спробуємо це виправити та розглянемо, як насправді побудований процес випуску «залізних» продуктів та які етапи їхньої розробки існують.

Чим відрізняються Software та Hardware-продукти

Hardware. Вже саме слово натякає нам, що просто не буде. Така розробка важка і цьому є безліч причин. Насамперед потрібно розуміти, що розробка заліза відбувається ітераціями. Про самі ітерації поговоримо трохи пізніше. Але важливо одразу зазначити, що ці ітерації займають багато часу. Як правило, необхідно спроєктувати друковані плати, виготовити їх, зібрати, протестувати на електронному рівні, доставити через половину світу, і лише потім інженери зможуть почати писати софт для них.

Потім у процесі роботи зʼясовується, що потрібно поліпшити кілька ліній, замінити деякі компоненти, трохи змінити форму корпусу. І цикл запускається заново: вносяться правки до схем, узгоджуються з усіма стейкхолдерами, відправляються у виробництво та збірку. Через деякий час ви отримаєте на руки нову ревізію плат. А ще є така річ як оснащення для лиття корпусів та інші штуки, про які мало хто замислюється. Термін виготовлення подібної пресформи може займати понад місяць.

Таких ітерацій на життєвому шляху пристрою зазвичай буває близько 10. На відміну від Software Development, у нашому випадку недостатньо заново скомпілювати проєкт, щоб отримати нову, покращену версію продукту. Тому й планувати всі свої дії необхідно на багато кроків уперед.

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

У повноцінному виробництві з’являються такі поняття як пропускна здатність конвеєра та ланцюг постачання — пристрій недостатньо лише спроєктувати, його потрібно вміти виробляти з необхідною швидкістю і якістю. Є окремі спеціалісти, які займаються пошуком та закупівлею компонентів. У сучасному світі, де термін постачання деяких мікросхем легко може становити один рік, ця робота — справжнє випробування. Необхідно знайти щонайменше двох постачальників, які зможуть надати потрібну кількість взаємозамінних компонентів за прийнятною ціною. Не забуваймо і про життєвий цикл цих компонентів. Рано чи пізно може виявитися, що ваш чип пам’яті більше не виробляється та йому потрібно заздалегідь знайти заміну: перевірити її, погодити, затвердити та закупити.

Окремим пластом викликів є регуляторні вимоги та фізична безпека. Для всіх радіоінтерфейсів, таких як Wi-Fi, Bluetooth, LoRa — необхідно проходити сертифікацію. У різних країнах діють свої правила, яким потрібно відповідати. Сам пристрій має бути безпечним для людини та її власності — цим питанням приділяється найбільша увага та проводиться безліч тестів роботи у різних режимах та за різних погодних умов. У жодному разі не можна допустити удару струмом, самозаймання пристрою чи проводки тощо.

Як бачимо, шлях цей тернистий та дуже відрізняється від процесу розробки софту. Давайте тепер розглянемо основні етапи життєвого циклу hardware-продукту.

Ініціація програми

Найпершим етапом є ініціація програми. Перш ніж запускати процес розробки принципово нового пристрою, запускається невеликий пілотний проєкт з перевірки життєздатності ідеї. Збирається прототип для перевірки того, чи цей пристрій в принципі може працювати так, як хоче цього бізнес. Простіше кажучи, якщо ви хочете розробити розумний годинник, який працює від акумулятора один місяць і це його ключова відмінність від конкурентів, то необхідно перевірити на практиці чи вдасться досягти бажаної автономності.

У цей час Product Manager розробляє спеціальний документ із вимогами до продукту. Цей документ описує основні специфікації, функції та інше. Це своєрідна біблія продукту. Програму «драйвить» спеціальний менеджер. Його завдання — випустити продукт у відповідний термін. Він працює з іншими доменними менеджерами, які відповідають за окремі частини програми. Такими доменами можуть бути залізо, прошивка, мобільний додаток, back-end, звук, автономність, штучний інтелект тощо. Наприклад, нещодавно я брав участь у програмі, де було майже два десятки таких доменних менеджерів.

Вони використовують документ, розроблений Product-ом для оцінки обсягу робіт та складання графіка своєї частини програми. Відповідальний за запуск менеджер об’єднує всі ці частини програми докупи та складає майстер-план. Основним викликом при складанні цього плану є необхідність точної синхронізації роботи великої кількості команд. Без цього не вийде досягти необхідних результатів роботи до потрібної дати й таким чином можна заблокувати всю програму. А цього, звісно, ​​не хоче ніхто.

Для ілюстрації цієї концепції розглянемо трохи утопічну аналогію з круїзним лайнером, який йде у дуже довгу подорож та рухається з одного туристичного порту до іншого. У певний день наш лайнер заходить до чергового порту. І поки пасажири сходять на берег і насолоджуються місцевими краєвидами, у порту кипить робота: лайнер заправляють паливом, поповнюють запаси прісної води, провізії, вивантажують пошту, сміття, підсаджують нових пасажирів. Щоб поповнення провізією пройшло за планом, цю провізію хтось повинен розрахувати, заздалегідь замовити, оплатити, розфасувати, доставити в порт. При цьому доставити в порт вчасно — щоб вона не зіпсувалася.

Так і наша програма вимагає планування круїзу на багато кроків вперед і розуміння, де і коли буде перебувати наш лайнер. Усі команди повинні вчасно «відвантажити» свої частини продукту до заздалегідь узгодженої дати. Зволікання хоча б однієї команди призведе до затримки всього круїзу та змістить дату прибуття в кінцевий порт, що є неприпустимим з погляду бізнесу.

Команди та їхні зони відповідальності

Hardware-команди розробляють схему пристрою, друковані плати, корпуси, оптику, підбирають компоненти тощо. Ці ж команди забезпечують закупівлю компонентів для прототипів, працюють із фабриками для організації збирання пристроїв. Окрема команда пише діагностичну прошивку. Цей софт забезпечує перевірку коректної працездатності пристрою під час виробництва. За його допомогою перевіряють роботу усіх компонентів заліза.

З певних ітерацій фабрика починає записувати production-прошивки в пристрої для того, щоб інші команди могли починати роботу. А це означає, що firmware-команда має заздалегідь передати прошивку фабриці. Необхідно планувати фабричні релізи заздалегідь та здійснювати їх перед тим, як фабрика розпочне виробництво відповідної ітерації.

Багато сучасних пристроїв працюють зі своїм додатком через інтернет. Тому з якогось моменту також необхідно забезпечити роботу пристрою з back-end та роботу мобільного додатка з вашим пристроєм.

Якщо Product Manager вирішує, що мінімально необхідний функціонал в об’ємі X має бути доступний починаючи з фази Alpha Trials, які проходитимуть на залізі ревізії EVT (Engineering Validation Test), то це означає, що приблизно за два тижні до виробництва EVT всі компоненти (firmware, app, back-end) повинні бути повністю готові та перевірені командами QA. Хоча, здавалося б, самі Alpha Trials розпочнуться лише за 4 тижні після початку виробництва EVT.

Загальний план програми

Все починається з того, що бізнес вирішує, коли йому потрібно вивести новий продукт на ринок. На це може бути безліч своїх причин, але для нас важлива одна дата — Street Date. Це день, коли продукт потрапляє на полиці магазинів. І вже починаючи від цієї дати команда планує, що і коли має бути зроблено.

Від Street Date ми йдемо у зворотний бік і плануємо, коли мають бути готові певні ключові етапи програми. Все це узгоджується з командами, обговорюється та коригується, закладаються буфери на критичному шляху.

Як правило, основними обмежувальними факторами є виробничі процеси на фабриках. Якщо збільшенням команди розробку прошивки ще можна прискорити, то виробництво пресформи займає 6 тижнів, як не крути. Це ж стосується майже всіх технологічних процесів на виробництві.

Результатом такого планування є дати всіх фаз програми та, як наслідок, вже зрозуміло, що і на коли необхідно зробити. Далі залишається лише отримати необхідну кількість ресурсів та виконати цей план.

Основні фази життєвого циклу продукту

Engineering Validation Board

Першою фазою є Engineering Validation Board (EVB). На цьому етапі на одну плату поміщають усі компоненти та зручні debug-порти. Іноді на цьому етапі деякі частини схеми роблять окремо, і вони підключаються до материнської плати через конектори. Це дозволяє налагоджувати частини схем зручніше, швидко виправляти помилки розведення плати й паралелити роботу.

Форма плати не має значення. Адже про корпус, динаміки, лінзи та інші речі на цьому етапі не йдеться. Тиражі цих плат невеликі — 20-50 штук.

Основна мета етапу — перевірити базову схемотехніку, взаємну роботу всіх компонентів, джерел живлення та почати писати софт. У першу чергу, ці плати дозволяють написати та налагодити BSP-частину та запустити операційну систему.

Після того, як базова частина прошивки стабільно стартує, firmware-команда вже може готувати свій перший реліз, а саме прошивку для наступної ревізії — EVT.

Engineer Validation Test

На етапі Engineer Validation Test (EVT) пристрій вже набуває своєї форми та зовнішнього вигляду: з’являється корпус, друковані плати розбиваються на необхідні частини, додаються антени, динаміки, лінзи, батарея та решта обов’язкових компонентів пристрою.

Корпуси на цьому етапі ще чорнові. Вони можуть бути відфрезеровані або відлиті в силікон, але вже відповідають Industrial Design. Їх можна, так би мовити, помацати і зрозуміти, як девайс виглядатиме і відчуватиметься в руках.

EVT-пристрої використовуються широким колом команд для проведення різноманітних інженерних тестів: починаючи від RF desense (radio frequency desensitization) й тестів на падіння та закінчуючи вимірюванням параметрів споживання енергії, аналізу тепловиділення, акустичних характеристик та іншого.

Як правило, EVT-ітерацій буває декілька. Називаються вони EVT1, EVT2, EVT3 і так далі. Це пов’язано з тим, що в процесі тестування виявляються деякі моменти, які можна поліпшити. Усі зауваження збирають, аналізують та вносять зміни до схем, розташування компонентів, форми корпусу тощо.

На цьому етапі firmware-команди пишуть або портують бізнес-логіку, back-end і app-команди додають підтримку нового типу пристрою, а QA-команди готують стенди для автоматичних тестів.

Тиражі на цьому етапі також невеликі. Як правило, це 50-100 пристроїв. До речі, замовлення цих пристроїв також підлягає ретельному плануванню. Всі команди повинні заздалегідь спрогнозувати скільки пристроїв на кожному етапі їм буде необхідно для всіх активностей та всіх членів команди та замовити ці пристрої на кілька місяців наперед.

На етапі EVT проводяться перші випробування пристроїв серед користувачів — Alpha Trials. Девайси поширюються серед співробітників і люди пробують ними користуватися. Мета Alpha Trials — виявити будь-які можливі проблеми якомога раніше.

Device Validation Test

На етапі Device Validation Test (DVT) відбувається перевірка працездатності пристрою загалом. До цього моменту має бути готове програмне забезпечення з усіма базовими функціями. В першу чергу, це Out of the box experience (первинне налаштування та оновлення по повітрю) та мінімальний набір ключових бізнес-функцій, які визначає Product Manager. Мобільний додаток та back-end вже підтримують новий тип пристрою.

Корпуси на етапі DVT — фінальної якості, вони виготовляються методом лиття під тиском. Лінзи, динаміки, антени — теж фінального дизайну. Тиражі тестових пристроїв на цьому етапі вже середні — сотні штук.

DVT-пристрої використовуються всіма командами для фінального тюнінгу режимів роботи своїх компонентів — налаштовується звук, якість картинки, робота радіоінтерфейсів, температурні характеристики. Паралельно з цим додаються нові функції програмного забезпечення.

DVT-пристрої використовують для Beta Trials — це масове тестування пристрою, але все ще співробітниками компанії. Сотні пристроїв використовуються живими людьми протягом багатьох тижнів. Аналізуються метрики та логи. Проводяться опитування та збирається зворотний зв’язок. Ці випробування дозволяють виявляти різні проблеми у прошивці, залізі та особливостях використання пристроїв. Як правило, Beta Trials тривають до запуску продукту та навіть після цієї дати.

Production Validation Test

Етап Production Validation Test (PVT) необхідний для перевірки та оптимізації виробничої лінії. На цьому етапі завод робить пробну партію в кілька тисяч пристроїв. Виявляються потенційно проблемні моменти, які оптимізуються та покращуються. Є безліч діагностичних утиліт і всі вони повинні працювати коректно, передбачувано, не створювати затримок на лінії. Якщо є можливість прискорити будь-яке тестування або швидкість запису прошивки — це робиться, щоб підвищити пропускну швидкість на лінії.

Для підвищення швидкості іноді ставлять кілька паралельних ліній, які випускають або перевіряють ті самі частини пристрою одночасно. Треба бути готовим до цього. Усі процеси валідації повинні мати змогу проходити паралельно й не конфліктувати одне з одним. Наприклад, перевірка роботи Wi-Fi може конфліктувати із сусідньою лінією. Або якщо у вас є спеціальний сервер, до якого ваші пристрої підключаються для проведення певного тестування — необхідно переконатися, що оператор розуміє, який саме пристрій під’єднався у цей момент часу і випадково не «перевірить» девайс сусіда. Щобільше, поряд у цьому ж приміщенні або через стіну можуть виробляти ваш інший пристрій, і він також може впливати на тести.

Все це потрібно враховувати та проєктувати заздалегідь. Зазвичай робота над цими утилітами ведеться ще на етапах EVT/DVT і до моменту PVT всі вони вже готові й налагоджені. PVT-пристрій — це вже повністю готовий продукт у тому вигляді, в якому його отримує клієнт. Прошивка — стабільна та повна, а пристрої повністю фінальної якості оздоблення та збірки. Єдине, що на цьому етапі може бути ще не готове — це поліграфія та artwork.

Mass Production

І ось ми підійшли до найбільш критичного етапу — Mass Production (MP). Фабрика вмикається на повну потужність та штампує ваші пристрої тисячами штук на день. Пристрої відправляються на фінальні перевірки в інженерні команди, керівництву, у Beta Trials та медіаоглядачам. Тиражі тут обмежені лише вашими фінансовими можливостями й останнім часом наявністю компонентів у постачальників.

Між початком Mass Production та Street Date може бути місяць-два чи навіть більше залежно від обставин. За цей час усі команди полірують функціонал, проводять чергові раунди Trials, виправляють баги й готують прошивку «Day 0» — це та прошивка, яку пристрої отримають повітрям після першого підключення. Вона виправляє всі помилки та неточності, знайдені у процесі валідацій та забезпечує клієнтам найкращий досвід використання.

Street Date

Найважливіший день для продукту — день його початку продажів. Починаючи з цього дня влаштовуються так звані War Rooms — щоденні мітинги всіх ключових учасників програми для аналізу процесу запуску, метрик, відгуків, продажів, трендових проблем та шляхів їх вирішення. Через те, що команди розподілені по всьому світу, таких мітингів може бути кілька штук на день, щоб зачепити всі часові пояси. Всі відгуки проглядаються та аналізуються. Ведеться робота з кожною скаргою. Аналізуються дзвінки до служби підтримки.

За виявленими проблемами проводяться аналіз та планування шляхів вирішення. Для firmware, як правило, плануються релізи на 7-й, 30-й та 60-й дні. У ці релізи потрапляють виправлення багів та заплановані покращення, якщо вони з якоїсь причини не були готові до Day 0.

Post-launch

Коли спека запуску продукту спадає, настає фаза post-launch. Це рутина з підтримки працездатності та розвитку пристрою. Але вона дуже важлива, бо якщо у вас є послуги за передплатою, то критично важливо забезпечувати їхню безперебійну роботу. На регулярній основі 24/7 збираються метрики та аналізується якість роботи вашого продукту. Якщо щось йде не так, може знадобитися випустити hot-fix.

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

Також у процесі роботи можуть бути виявлені місця в залізі, які можна оптимізувати. Це також виконується в штатному режимі. У цілому для підтримки працездатності пристрою потрібно набагато менше ресурсів, ніж для його розробки.

На завершення

Хочу подякувати всім за увагу та сподіваюсь, що білих плям у процесах та тонкощах розробки hardware-продуктів стало трішки менше. Бережіть себе. Україна переможе!