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

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

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

Небольшое предисловие


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

  • Постараюсь не говорить про общепринятые best practice хардварной разработки: «Сначала делаем EVT и, возможно, EVT 2 и только потом запускаем DVT». Про них, а также про терминологию хардварной разработки можно почитать в этой статье.
  • Свой опыт я описал с прицелом на модель производства CMS. При этом он почти полностью применим и для ODM — хорошим тоном будет контролировать те же самые вещи при разработке дизайна на стороне подрядчика.
  • Мой рассказ будет построен на примере разработки абстрактного устройства. В целом тип девайса мало на что влияет.
  • Буду исходить из того, что производство располагается в Китае. Это придаёт некоторую специфику.
  • Я менеджер в конструкторском бюро Яндекс Go. Наши схемотехники, embedded-разработчики и тестировщики создают устройства для решения задач Самокатов, Такси, Еды и других сервисов — как быстрые прототипы, так и долгие проекты, которые включают сопровождение в постпродакшене. И в нашей команде за все пункты отвечает один менеджер (можете начинать меня жалеть), но в рассказе будут появляться несколько ролей: продакт, технический менеджер или проджект, а также операционный менеджер.

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

Погружение в мир хардвара


Уделяем внимание разработке платы


Главное, к чему надо быть морально готовым: плата для устройства точно не получится с первого раза. Тут без вариантов. Разработка железа — это итеративный и порой медитативный процесс, которому нужно помогать.

Когда схемотехник выдаёт первую версию документации, я прошу ребят из команды провести ревью — да, прямо как с кодом. Мы отсматриваем электрические схемы, гербера, BOM (Bill Of Materials). Причём такое ревью можно проводить не только силами своей команды: правильно советоваться и с производителем — как минимум о доступности выбранных компонентов.

Менеджерам отдельно рекомендую уметь читать и ревьюить BOM самостоятельно: именно вам потом подтверждать его покупку на миллионы денег. И если что-то меняется, то важно понимать, зачем, сколько это будет стоить и какие есть риски.

Заказывать настоящие PCB и тем более их собирать бывает долго и дорого. Но что делать, если хочется вот прямо сейчас удостовериться, что плата встанет в корпус? Я решаю эту проблему так: даю схемотехнику распечатанный на 3D-принтере корпус и прошу распечатать получившуюся плату на обычном офисном принтере. Так он может убедиться, что попал в посадочные места и вообще в габариты. Это лучше, чем примерять исключительно in silico. Но, конечно, от примерки готовой платы в будущем это никак не освобождает.


Примерка бумажной платы на посадочное место

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

Покупаем материалы для экспериментов


Подготовка к производству — это не только отладка прототипов и документации. Чтобы комфортно себя чувствовать при решении проблем с первыми EP, EVT и DVT, всегда нужно много материалов в запасе. Добиться этого просто: меньше тратить и больше приобретать заранее.

Да, BOM наверняка поменяется, но тут точно не стоит экономить — даже попадание на 50% уже окупится. Дешевле без спешки купить лишнего, чем второпях покупать недостающее.


Примерно так выглядит BOM

Также при планировании количества материалов на эксперименты нужно учитывать, что при каждой настройке SMT-линии тратится значимое количество компонентов. То есть 200 комплектов на складе — это не 200 готовых устройств, а… не знаю, сколько, зависит от количества итераций, которое понадобится, но вряд ли больше 180 штук.

Кстати про итерации. При производстве EVT или DVT никогда не делайте много экземпляров сразу. Даже если очень спешите. Даже если отличия от предыдущей итерации минимальны. Производить больше 10 экземпляров, полагаясь на удачу, — почти всегда пустая трата компонентов. Потому что с очень высокой вероятностью нужно будет вносить правки ещё раз. Если очень хочется, можно заранее заказать побольше PCB, но для начала собрать и проверить только несколько штук. Если всё хорошо — прекрасно, а если нет — поправить за счёт изменений в BOM. Да и даже если придётся переделывать PCB, это будет не очень затратно.

И тоже в тему экспериментов: при проверке любого образца должны быть однозначные критерии, что значит «работает» и «не работает», причём зафиксированные в документе. Не столь важно, что именно это будет: напряжение на тестпойнтах или продуктовое поведение. Важно, чтобы всё было записано, а все участники процесса понимали, кто и когда проверит образец, а также как интерпретировать результаты этой проверки.

Получаем поддержку от вендора


В процессе разработки как хардвара, так и прошивки под него всегда возникает много вопросов. В основном это касается всех сложных программируемых компонентов, например модемов, MCU, BLE-модулей. Конечно, инженеры изучат всю документацию и на большинство вопросов ответят самостоятельно, но… Здесь есть два веских «но».

  • Во-первых, актуальную документацию не всегда легко достать. Например, она не всегда есть в открытом доступе, и её надо запрашивать у производителя компонента и бесконечно ждать (а иногда и умолять).
  • Во-вторых, даже официальная документация может быть неполной или неточной. И тут очень пригодится личная поддержка вендора конкретного модуля.

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

Официальные поддержки через форму на сайте вроде как есть, но их никто не видел. В идеале в моём WeChat (у всех же есть WeChat, правда?) просто появляется контакт конкретного человека, которому можно писать по любым техническим вопросам. А ещё лучше, если не только в моём, а у всех наших инженеров.

Готовим прошивку под производство


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

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

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

Также нужно помнить, что прошивка есть не только у основного компьютера, но и у периферийных устройств, например у GNSS-модуля или модема. Да, в большинстве случаев подойдёт стандартная от вендора, но иногда она может вести себя не совсем предсказуемо. Так что перед выпуском устройства обязательно нужно ответить себе на вопрос: «Как будет обновляться каждый компонент, если что-то пойдёт не по плану?»

Если что, ответ: «Никак, мы полностью уверены в стандартной прошивке», — тоже ок.

Закладываем время на другие процессы


Кроме разработки и производства, есть и другие важные процессы. Например, изготовление оснастки для литья (тулинга или молдинг-тулс), закупка компонентов и заказ PCB в больших количествах. Все они тоже требуют много времени и внимания.
Формально за все три процесса отвечает контрактный производитель, но лучше самому держать руку на пульсе. Не стесняйтесь уточнять, что именно значит ответ «Everything is ok».

— А уже разместили заказ? И деньги перевели?
— А поставщик сроки подтвердил? А какие именно?
— Уже отгружено? Отлично. А когда именно всё приедет на ваш склад?

Все эти вопросы я обязательно задаю и не отстаю, пока не получу однозначный ответ. Только так можно выяснить, что на самом деле не совсем «everything», а где-то далеко не «is ok». Китайские партнёры любят сглаживать острые углы и могут сказать, что всё хорошо, не потому что и правда всё хорошо, а чтобы просто вас не огорчить. Поэтому, чтобы уверенно управлять ожиданиями, нужно задавать конкретные вопросы по каждому из этапов и дожимать ответы.

Ещё важно предусмотреть и другие достаточно ёмкие или непредсказуемые по времени процессы. Они могут быть специфичными для каждого устройства. Например, я могу попросить контрактного производителя отправить несколько образцов нашего устройства поставщику антенн. Это нужно, чтобы поставщик мог нужным образом подстроить антенну именно под наш девайс или, возможно, дал какие-то рекомендации по доработкам самого устройства для лучшего приёма сигнала.

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

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


Джига сразу под два девайса

А вот если не хватает какого-то специфического оборудования, то надо либо его заказывать (что долго и дорого), либо адаптировать процесс тестирования, что ещё больше затянет подготовку к производству.

Закупаем BOM под массовое производство


Вообще, закупка компонентов — дело контрактного производителя. Но вам нужно понимать, у кого именно он покупает основные компоненты, в особенности — рискованные по срокам.

Например, я хорошо общаюсь с зарубежным офисом продаж производителя нашего Wi-Fi/BLE-модуля. И я всегда дважды переспрашиваю у контрактника, когда и у кого именно он купит модули. Это важно, чтобы офисы (локальный, к которому пойдёт контрактник, и зарубежный, с которым общаюсь я) не начали выяснять между собой, кто именно продаст партию. Ведь пока они договариваются, саму партию никто не готовит к отправке, и из-за этого срок поставки растёт.

Какие компоненты мы считаем рискованными? В этом вопросе ориентируемся на цену и на страну происхождения: локальные (китайские) компоненты доступнее импортных, а дешёвые почти всегда быстрее купить или заменить в отличие от дорогих.

Обычно я просто прошу схемотехников выбирать компоненты на lcsc.com (скорее всего, ваш тоже поймёт такую просьбу). Альтернативные варианты — ickey.cn или mouser.cn. Поиск на этих сервисах даёт какую-никакую гарантию доступности: если компонент есть на этом сайте, то он с высокой вероятностью легкодоступен на китайском рынке.

А ещё бывает, что производитель предлагает заменить какие-то компоненты. Такие советы чаще разумны, чем нет, и к ним стоит прислушиваться. Но непосредственно перед закупкой внимательно проверьте финальный BOM, сформированный именно поставщиком, — мало ли что. Например, поставщик может без предупреждения заменить какой-то компонент аналогом. В большинстве случаев это будет релевантной заменой, но иногда это может сказаться на работоспособности устройства.

Готовимся к худшему


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

Скажем, вам в итоге приходит не тот BOM, который вы заказывали, или производитель изначально заказал не то, о чём его просили. Именно поэтому мы приезжаем на производство лично посмотреть на сигнальный экземпляр и сверить если не покомпонентно, то хотя бы основные узлы. Например, один и тот же партнамбер может означать разные компоненты у двух агентов — такое случается редко, но это очень больно. Или на этапе сборки компонент могут забыть положить или положить в неправильной ориентации — такое особенно сложно поймать.

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

Чтобы сократить риски, я самостоятельно проверяю SOPы фабрики — хотя бы по сборке в корпус. Хоть они и на китайском, этого не стоит пугаться: больше 80% информации отражено в картинках, а насчёт остального можно уточнить.

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

Думаем про тестирование и дальнейшую судьбу девайса


Жизненный цикл устройства включает в себя не только разработку и эксплуатацию. Есть ещё один полноценный этап — тестирование.

На этом этапе в голове может появиться соблазнительная мысль: «Производство запустили, софт написан, с DVT проблем не было — как-нибудь да протестируем. А если что, то просто доплатим фабрике за ручное тестирование в две или три смены». Но при грамотной и заблаговременной настройке процесса тестирования никому не придётся выходить на работу в ночь.

Значимую часть процессов, например проверку собранных плат на рентгене, можно полностью отдать на откуп контрактному производителю. А своё внимание сконцентрировать на двух вещах: отдельном софтовом тестировании PCBA и finish good tests — проверке полностью готового устройства.

Теоретически ещё не собранную в корпус плату можно было бы и не тестировать. Но нужно иметь в виду, что чем позже обнаружена проблема, тем дольше и дороже её локализовать и устранять. Придётся разбирать корпус, проверять все возможные точки отказа по отдельности, собирать обратно…

Даже если этот этап тестирования берёт на себя поставщик, ваше внимание всё равно понадобится. Нужно самостоятельно (в идеале — прямо на месте) убедиться в том, что прошивка корректно взаимодействует с тестовым ПО вендора. Само всё получается редко, а что-то больше, чем «it doesn’t work», от инженеров поставщика будет получить достаточно сложно.

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

И ещё несколько вопросов о важных мелочах, которые стоит задать себе при тестировании:

  • Подумайте про SIM-карты, если они нужны: это будут карты целевой страны или китайские? Откуда они появятся на фабрике? Нужен ли на них доступ в интернет? Если да, то точно ли мы не потратим интернета на астрономическую сумму?
  • Как именно вы будете подключать устройство к тестовым стендам: через дебаг-пины, коннектор или как-то ещё?
  • Что делать, если тестовый стенд внезапно перестанет работать? При удалённом общении с заводом лучше завести себе идентичный на месте.
  • Что с пропускной способностью тестовых стендов? Сколько устройств в час? Нас это устраивает?
  • Точно ли после финального тестирования с устройством ничего не случится?

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



Напечатав всё, что выше, понял — получилось много. Хотя и до, и после рассмотренных процессов тоже есть о чём поговорить. Например, о процессе «после» — о доставке произведённого устройства и сопровождении ввода в эксплуатацию. Или о процессе «до» — о выборе подрядчика и предварительных договорённостях с ним.

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

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

Если ничего не делать — само ничего не сделается. Совершенно обо всём нужно договариваться в явном виде, всё нужно проверять и перепроверять. Исправлять ошибки кратно сложнее, чем в софтверной разработке.

И повторюсь: если что-то может пойти не так, оно точно пойдёт не так. Но пугаться этого не надо — это именно то, с чем можно и нужно работать, о чём рефлексировать и из чего делать выводы на будущее.

Комментарии (5)


  1. VL-endo
    19.10.2023 07:12
    -7

    Текст даже читать не стал, т.к. судя по КДПВ "не так" пошло с момента взятия паяльника в руки.


    1. NatalieVT
      19.10.2023 07:12
      +7

      Это же отсылка к великому


  1. VL-endo
    19.10.2023 07:12

    А если почитать текст, то видим оправдание манагера в своей безграмотности. Совместимость платы с корпусом делается на этапе разработки в стандартных САПР. Не надо делать 3D-печать и прикладывать бумажную распечатку платы. Удивительно, что не упоминается ЛУТ.

    ВОМ на дефицит просчитывается схемотехником на этапе создания схемы, а не после запуска в производство.

    Из текста следует, что КБ Яндекса находится на уровне кружка "Умелые руки", на со знанием английских аббревиатур и развитой системой отчетности.


    1. brun4eg
      19.10.2023 07:12
      +1

      На фразе "ВОМ на дефицит просчитывается схемотехником" можно остановиться и дальше не обсуждать подобные комментарии. Уж простите...


    1. AndronNSK
      19.10.2023 07:12

      Да у них и софт во многих продуктах на том же уровне.