Hardware разработка: что стоит знать тем, кто затеял «железный» стартап

Аналитики компании Cbinsights выяснили, что только 48% стартапов удается привлечь второй раунд инвестиций, до третьего и четвертого доходят 15%, а единорогами становятся лишь 1%. Их успешность складывается из многих составляющих. Одна из них – успешный электронный дизайн в Hardware разработке, о котором и пойдет речь в этой статье.

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

Благодаря таким крупным IT-компаниям, как Яндекс, Сбер и Mail.ru сейчас на рынок поступает много девайсов российской разработки, и рынок «железных» продуктов быстро растёт. Однако менеджеров по управлению железной продуктовой разработкой на рынке совсем немного. Причина в том, что исторически «железной» и продуктовой разработкой занимались разные специалисты.

Я проджект менеджер и занимаюсь Hardware разработкой и оптимизацией процессов производства уже более 10 лет. Из них шесть лет я работала в космическом приборостроении, а четыре года - в коммерческих компаниях, в том числе WayRay и SberDevices, где занималась управлением проектами по разработке и производству устройств.

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

В этой статье я расскажу о разработке электронного дизайна устройства. Я не буду затрагивать тему разработки дизайна корпуса девайса, так как в сети есть отличная статья на эту тему.

Перед подробным разбором хочу выделить несколько этапов в разработке электронного дизайна. Это разработка технических требований (technical requirements), прототипирование (proto stage), разработка электронного дизайна (schematics, layout), изготовление сэмплов (samples production), тестирование (reliability tests) и утверждение электронного дизайна (confirmation). Для более простого запоминания ниже привожу схематичное изображение последовательности шагов. Далее в статье я детально остановлюсь на каждом шаге.

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

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

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

Некоторые требования не существуют как продуктовые, а фигурируют только как технические. Например, требование к тепловыделению проектора или умной колонки пользователю не важно и не несет для него никакой практической пользы (если вы не разработчик обогревателей :D ). Но оно важно с технической точки зрения, так как перегрев некоторых компонентов может вывести девайс из строя, и пользователь не сможет больше прослушивать музыку или смотреть видосики.

Технические требования – это то, что обязательно проверяется перед утверждением электронного дизайна. Если, например, по какой-то причине требование по объему перегоняемого воздуха датчиком загрязнения воздуха не будет прописано как техническое, то на этапе тестирования оно не будет валидировано, и электронный дизайн будет утвержден без его проверки. В результате после начала продаж мы можем получить жалобы на то, что датчик загрязнения воздуха меняет свои показания при перемещении на каждые 10 см.

Чек-лист технических требований - это авторская неформальная трактовка стандарта ГОСТ 15.016-2016 “Техническое задание. Требования к содержанию и оформлению”, которые написаны канцелярским языком и могут быть сложны для понимания.

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

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

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

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

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

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

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

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

Электронная часть устройства состоит из печатных плат с установленными электронными компонентами, коннекторов, шлейфов, антенн, кнопок и других электронных компонентов.

Не менее важная часть электронного дизайна - внешние компоненты, которые подключаются к девайсу и поставляются в комплекте с ним. Это, например, аккумуляторы, сетевые адаптеры питания, переходники, наушники, кабели или донглы.

На этом этапе команда разработки готовит документацию для изготовления электроники. Я рекомендую использовать такой набор документации:

• электрические схемы плат
• электрическая схема соединений плат между собой
  
• спецификация/БОМ (BOM файл)
  
• файлы с топологией печатных плат (layout files)
  
• габаритный чертеж или 3D-модель платы
  
• сборочный чертеж (обычно требуется, если есть слесарные работы при сборке)
  
• низкоуровневое ПО для обеспечения базовых функций компонентов (например, прошивка микроконтроллера, управляющего светодиодами)
  

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

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

В VC уже были публикации про подготовку этих процессов. Например, много ценных рекомендаций по работе с БОМ файлом вы можете найти в этой статье.

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

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

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

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

Количество девайсов для каждого вида испытаний, уточняет проджект-менеджер совместно с командой разработки и QA на этапе согласования программы испытаний.

К примеру, на термоиспытания и стресс-тесты я рекомендую выделять большее количество девайсов (по 5-10 штук), чем на другие виды испытаний (2-5 шт) из-за погрешностей измерения температуры и возможной неравномерности в нагрузке девайса. То же самое касается и других важных тестов. Минимальное количество девайсов на испытания – 2-3 штуки, чтобы исключить ошибки сборки или брак какого-то одного компонента на единственном девайсе из-за того, что сборщик чихнул при сборке =D

Например, для тестирования я изготавливала 20 девайсов в корпусе и 30 комплектов плат без корпуса. Девайсы использовались для тестов, в которых корпус влияет на измерения. При проведении стресс-тестов измеряется тепловыделение девайса, и корпус играет важную роль в этом процессе – форма корпуса напрямую влияет на процесс рассеивания тепла внутри девайса.

Также на девайсах в корпусах обычно проверяются акустические параметры, работа при повышенной и пониженной температуре окружающей среды, работа компонентов, закрепленных непосредственно на корпусе (разъемы, микрофоны, кнопки и т.п.).

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

Из опыта своей работы, я выделила пять основных этапов испытаний электронного дизайна (EVT tests):

1. Базовый функциональный тест (Hardware function tests)
   Электронный дизайн разбивается на функциональные узлы. Каждый функциональный узел базово проверяется на работоспособность и функционал. Качество выполнения функции на этом этапе не оценивается.
   Например, базовый функционал HDMI проверяется так – девайс подключается к ТВ и проверяется есть ли сигнал на ТВ или нет. Если сигнал есть и видео на ТВ транслируется, значит, базовая функция работает.
   
2. Качественные функциональные тесты (Performance tests)
   На этом этапе каждый функциональный узел основательно тестируется. Каждое из его технических требований проверяется по отдельности. Например, для RAM измеряется скорость записи (максимальная, минимальная, средняя), скорость считывания (максимальная, минимальная, средняя), объем памяти.
   
3. Стресс тесты (Stress tests)
   Это тестирование функционирования девайса в нормальных условиях эксплуатации, но в максимально нагруженном режиме всех функций одновременно. Максимальное количество функций должно работать на самых производительных режимах. Например, динамики включены на полную громкость, транслируется видео 4к через WiFi, включен Bluetooth и параллельно выдается и обрабатывается голосовая команда.
   
4. Тесты на совместимость (Compatibility tests)
   Это качественное тестирование сигналов, поступающих на внешние устройства по выходным коннекторам (например, HDMI, USB и тп.) и по беспроводным каналам (WiFi, Bluetooth). На этом этапе проверяется, например, насколько качественно транслируется HDMI-сигнал при подключении телевизоров разных производителей.
   
5. Тесты на надежность (Reliability tests)
   Здесь проверяется надежность функционирования девайса под воздействием внешних факторов. Набор тестов на надежность определяется требованиями к устройству.
   

Приведу пример набора тестов:

• проверка функционирования при повышенной температуре (+40 градусов С во включенном состоянии в течении 10ч);
• проверка стойкости при пониженной температуре при хранении (-20 градусов С в выключенном состоянии в течение 4ч с последующим включением и проверкой функционирования).
  

Часто на этапе EVT девайс много раз собирается и разбирается, происходят замены плат и иногда компонентов, где-то что-то отваливается, отклеивается, раскручивается и ломается. Все замечания я рекомендую собирать в списки и на этапе DVT/PVT возвращаться к ним и перепроверять. На этом этапе стоит составить два списка потенциальных рисков для проверки на следующих стадиях разработки: конструктивные и сборочные.

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

Второй тип рисков - потенциальные риски сборочного процесса.

Примером потенциального риска сборочного процесса может быть раскрученный винт (он мог раскрутиться при транспортировании или недостаточно закручен при сборке); компонент, упирающийся в другие детали; разъем, мешающий установке других компонентов; болтающиеся провода и шлейфы; ненадежное приклеивание проводов, шлейфов и прочих компонентов. Это может быть даже выкрутившийся звенящий винт, перекатывающийся внутри девайса (и такое встречалось в нескольких проектах =) )

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

Если недостаток некритичный (например, необходима замена номинала резистора в том же типоразмере компонента), то можно перепаять элемент и провести повторные тесты, на которых недостаток выявился.

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

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

Если недостаток критичный, то чаще всего требуется переразведение платы. Это чаще всего повлечет за собой увеличение сроков разработки.

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

На этапе DVT проджект-менеджер совместно с заводом-изготовителем начинает производство дорогостоящего туллинга (оснастки) для производства корпусов. Время изготовления оснастки - от 45 календарных дней, стоимость - от 10 тысяч долларов для маленького устройства (примеры цен на начало 2021г.).

Все выявленные ошибки должны быть устранены до начала этой стадии разработки. Если какая-то проблема будет выявлена на стадии DVT, это потребует перезапуска туллинга. То есть нужно будет заново начать стадию DVT с новой оплатой и потерей 45 дней.

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

Это мой первый опыт публикации в VC. Буду рада узнать, откликнулась ли у вас эта статья и почитать в комментариях о вашем опыте в hardware разработке. В следующих статьях я хотела бы подробнее рассказать о видах испытания «железа» и поделиться своим опытом запуска серийного производства в одной российской компании. Хотели бы узнать больше об этих темах?:)

П.С.: Спасибо Насте Седухиной за помощь в ректировании текста.