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

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

Самые значимые различия (как, впрочем, и сходства) в подходах и методологиях мы рассмотрим через погружение в цикл разработки продуктов потребительской электроники. Разберём, какие именно задачи лежат на инженерах аппаратной разработки, какими знаниями необходимо обладать и почему цена ошибки так велика. А в качестве примера возьмём знакомое и понятное всем устройство: умную колонку с AI‑ассистентом.

Разработка электроники (и сопутствующее налаживание производства) делится на чёткие этапы, у каждого из которых есть определённые условия и артефакты для входа и выхода. На Хабре уже была статья про этот цикл, но мне хочется рассказать про него с точки зрения инженера, проходящего от этапа к этапу «изнутри». И попутно сравнивая подходы к разработке железа и ПО.

Прежде чем мы погрузимся непосредственно в этапы разработки, следует сказать пару слов о стадии исследования (она часто называется Discovery). Здесь важно ответить на ряд вопросов про будущий продукт:

• Какая будет целевая аудитория?

• Какая должна получиться рекомендованная розничная цена?

• Каким будет примерный внешний вид (размеры, цвета, формы, материалы)?

• Какие задачи конечного потребителя будет решать продукт?

• Какие примерные технические характеристики и УТП (уникальные торговые предложения) должны быть заложены?

• Какие продукты являются потенциальными конкурентами?

Конечно, ещё предстоит большая работа по просчёту экономики: сколько будет стоить разработка, производство, логистика, какая выгода получится в итоге и прочее.

И только когда мы ответим на вопросы выше, начнётся одна из самых интересных стадий…

Концепт

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

• Акустические прототипы. Это «коробочки» с установленными динамиками, из которых герметично выведены наружу провода для их подключения. Может быть несколько звуковых схем, разные типы динамиков, разные формы рассеивающей линзы и так далее.

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

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

• CMF (Color, Materials, Finish). Цвет, материалы, обработка поверхностей. Так как это физическое устройство, с которым будут взаимодействовать в реальном мире, важен выбор размера, цвета, материалов и покрытий поверхностей. Это те вещи, которые уже никогда не получится обновить, поэтому важно выбрать именно то, что будет заложено в продукт. Отдельное внимание, конечно, уделяется выбору ткани. Ведь помимо эстетических свойств, она должна обладать необходимой прозрачностью — как акустической, так и световой (для часиков, например), а также износостойкостью и рядом других параметров.

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

Эта стадия напоминает Agile‑подход, так как разработка прототипов идёт очень маленькими итерациями с постоянной обратной связью как от стейкхолдеров, так и от технологов производства.

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

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

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

Engineering Validation Test

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

Изготавливается несколько десятков образцов: главным образом, для команды разработки и тестирования. Инженеры‑конструкторы в тесной связи с акустическими инженерами и промышленными дизайнерами прорабатывают конструкцию устройства. Инженеры‑электронщики проектируют все необходимые печатные платы. Разработчики системного ПО подготавливают первые версии системы, которая будет всё это «оживлять». А команда производственного тестирования уже начинает прорабатывать линию контроля качества.

Здесь уже больше отличий от Agile‑разработки: итерации становятся всё длиннее, и работа начинает переходить в более Waterfall‑подобное русло: есть техническое задание и сроки, к которым нужно подготовить результат.

И именно на этом этапе становится заметным первое большое отличие от софтверной разработки — процесс отладки. А точнее, время, которое на неё требуется, и инструменты, которыми пользуются разработчики.

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

Представим, что инженер‑электронщик допустил ошибку в разработке печатной платы. Назовём это «ошибкой» просто для удобства, так как это не всегда может быть именно ошибкой в полном смысле этого слова. Это может быть просто принятым решением, которое невозможно было проверить заранее в условиях имеющейся на тот момент информации. Скажем, это не такая ошибка, которую легко определит компилятор или кросс‑ревью. Например, неудачно проведённая «чувствительная» трасса вблизи «шумного» узла. Или пропущенный комментарий маленькими буквами в документации на микросхему о каком‑нибудь «особом» режиме работы. Или вовсе ошибка в спецификации на компонент (да, такое тоже бывает).

После того, как плата ушла в релиз, происходит следующее:

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

• Фабрика по производству плат изготавливает многослойную печатную плату.

• Другая фабрика производит установку (SMT, Surface Mount Technology) компонентов. Другими словами, все несколько сотен компонентов нужно припаять на плату.

• Готовая плата высылается разработчику.

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

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

• Найти ошибку. Путём исключения одного за другим факторов сужать поиск. Здесь на помощь приходит лабораторное оборудование: от мультиметра и осциллографа до анализаторов спектра и безэховых камер для анализа электромагнитного излучения. Микроскоп, паяльник и скальпель (для перерезания дорожек на плате) — тоже обязательные инструменты.

• Исправить ошибку. Даже после того, как она найдена, не всегда есть очевидный путь её исправления. Если процессор прекрасно работает на 1 ГГц, но иногда зависает на 1,2 ГГц — решение, скорее всего, не будет лежать на поверхности. Более того, круг поиска не всегда удаётся сузить до достаточно малого: это могут быть ограничения измерительного или испытательного оборудования, недостаточная поддержка производителя, меняющиеся внешние условия. Но несмотря на это, необходимо внести изменения в схему или конструкцию, чтобы попытаться исправить нежелательное поведение.

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

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

Вот пара примеров из реальной практики:

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

Пример сложной ошибки. Один из каналов Wi‑Fi показывает чуть меньшую чувствительность, чем остальные. Проявляется это только при тестировании в специальной лаборатории: невозможно что‑то попробовать исправить прямо «на столе». Поэтому приходится перебирать различные гипотезы, искать источник помехи с помощью анализатора спектра ближнего поля. И оказывается, что одна из гармоник излучения линии тактирования Wi‑Fi‑интерфейса (SDIO CLK) совпадает по частоте с несущей этого канала. Инженер перетрассирует эту часть так, чтобы она шла только по одному слою, без «захода» под сам Wi‑Fi‑модуль, и окружит защитными земляными линиями. А на уровне драйвера изменит максимальный ток, который выдаёт соответствующая ножка SoC (системы на кристалле). И только через месяц сможет проверить, помогло ли это (спойлер: помогло).

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

Кстати, именно связь с физическим миром сильно затрудняет (если вообще не делает невозможной) работу инженеров на полной удалёнке. Согласитесь, сложно искать проблемы влияния DDR‑памяти на работу Wi‑Fi, лёжа в шезлонге на пляже с ноутбуком на коленках. Однако работа с физическими устройствами несёт в себе другие приятные моменты, о которых чуть позже.

Ещё одно важное отличие от софтверной разработки — возможность обновления «по воздуху» (OTA, Over the Air). Если даже один крохотный резистор был неточно подобран, его не получится обновить у пользователя, выпустив новую прошивку. Здесь‑то и усложняется классический подход SDLC: на самом первом планировании архитектуры необходимо заложить возможность осуществления всех будущих циклов этого подхода.

Поэтому у инженера‑электронщика появляются две ответственные области работы:

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

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

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

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

Решив все эти задачи, можно переходить к следующей стадии.

Design Validation Test

И слово Design здесь не про дизайн в его привычном понимании. В переводе с английского это, в первую очередь, «конструкция». Поэтому‑то инженер‑конструктор на английском будет Design Engineer.

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

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

Важное отличие этого этапа от EVT — детали изготавливаются уже с применением технологий массового производства. Если раньше мы могли, например, напечатать что‑то на 3D‑принтере, то здесь для пластиковых деталей изготавливаются пресс‑формы для отливки в ТПА (термопластавтоматах). Такие пресс‑формы могут изготавливаться месяц и дольше, в зависимости от размера и сложности деталей. Инженер‑конструктор ограничен самой технологией литья пластика: нельзя сделать произвольную форму, потому что пресс‑формы в автомате двигаются, и на их пути не может быть деталей конструкции. К тому же такие стальные пресс‑формы крайне сложно дорабатывать. Одно дело добавить пластика (выточить в пресс‑форме что‑то дополнительно), но убрать — почти никогда невозможно (либо уж очень дорого), потому что стальную деталь так просто не нарастить.

Да‑да, вот она снова, цена ошибки.

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

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

Обычно такое оборудование разделяется на два вида: один используется до сборочной линии, а другой — непосредственно в её составе. Кстати, подробнее про них можно узнать в материалах с конференции Я Железо «Дефект не пройдёт».

До сборочной линии мы поставим так называемые джиги (Test Jig) — это тестовые стенды с подпружиненными иголками, предназначенные для проверки печатных плат с установленными на них компонентами. Простыми словами — мы проверяем все основные функции платы после пайки, но ещё до установки в продукт. Здесь важно убедиться, что все параметры, отклонение которых сразу будет заметно пользователю, находятся в допустимых пределах. Например, дефекты пайки микрофонов могут создать негерметичный акустический канал — записанный звук заметно испортится, а колонка будет хуже «слышать». Или из‑за технологического разброса на производстве светодиодов на одну плату с часиками могут попасть компоненты с различимой глазом разницей. Мы это проверим и при необходимости отбракуем. Ведь если брак обнаружится в самом конце — придётся всё разбирать и ремонтировать, а это время и деньги (да, снова цена ошибки).

На самой сборочной линии мы поставим чемберы (Test Chamber), в которых будем проверять всё, что только можно: нажмём на кнопки, проиграем звук, проверим, как светят светодиоды. Это довольно крупные ящики, выполняющие автоматическое тестирование уже собранного устройства. Они могут различаться по назначению: например, один будет с упором на акустические тесты, а другой — на проверку световых эффектов. Но в обоих случаях задача, которую они выполняют — обнаружение дефектов сборки. Если шлейф до тач‑панели был плохо вставлен (это брак), то при касании панели специальным манипулятором с пневматическим приводом ПО не обнаружит срабатывания. Акустические тесты способны выявить недозакрученный винт, а компьютерное зрение найдёт неоднородности в литье пластика, сквозь который светится логотип.

Дополнительную сложность привнесёт необходимость выполнять тестирование за как можно меньшее время: ведь чем дольше мы будем тестировать, тем больше таких аппаратов нужно ставить на линию. А темп производства может достигать нескольких тысяч штук в день!

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

И здесь стоит поместить ещё одну ремарку касательно ПО. Разработка, улучшение, докатывание новых фич ведётся постоянно. И колонки потом будут получать стабильные обновления. Но с момента, когда ПО загружено в колонку на фабрике, и до того, как пользователь подключит её к интернету для обновления, мы никак не сможем повлиять на прошивку. Поэтому та версия прошивки, которая заливается на производстве (factory‑версия), проходит наиболее тщательное тестирование, и именно в составе готового продукта.

Убедившись, что всё спроектировано верно, «заводское» ПО работает без сбоев, а мы всячески подготовились к самому процессу производства, можем переходить дальше.

Production Validation Test

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

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

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

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

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

Массовое производство

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

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

И, казалось бы, при чём здесь звук? Вот фабрика успешно произвела партию чёрных, серых и зелёных колонок. Но как только началось производство оранжевых, резко выросло количество брака по звуку, тестируемому в автоматическом чембере — THD (Total Harmonic Distortion — коэффициент нелинейных искажений) в районе 500 Гц вырос с 3% до 5%. И вот инженерная команда начинает изучать акустические свойства ткани, сравнивать плетение нитей, состав красителя... А на деле всё оказывается проще.

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

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

Ещё один пример: у небольшой части пользователей часы в полной темноте не гаснут до минимальной яркости. Инженерная команда начинает глубоко анализировать эти образцы и понимает, что у двух контроллеров светодиодов, которые обслуживают левую и правую части часов, наблюдается небольшой разброс производственных параметров выходных каскадов ШИМ‑контроллеров. Он проявляется в небольшой нелинейности в области самых низких значений. А проблему нужно устранить так, чтобы не требовалась аппаратная переделка — только через обновление ПО.

Инженеры выясняют, что нелинейность устраняется при уменьшении частоты ШИМ. Казалось бы, проблема решена — нужно просто поменять по I²C значения пары регистров при конфигурировании микросхемы. Но не тут‑то было: на более низкой частоте керамические конденсаторы в цепи питания часиков начинают издавать еле слышимый писк из‑за своего обратного пьезо‑эффекта.

К счастью, решение находится: у контроллера есть возможность сдвигать фазы каждого ШИМ‑канала и сделать так, чтобы светодиоды включались не одновременно, а со сдвигом на 60 градусов. Ура, проблема решена! Новая версия прошивки проходит полный цикл тестирования и уходит в релиз.

В качестве заключения

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

Дело в том, что далеко не всегда удаётся попасть с разработкой только в одну стадию. И могут появиться EVT-2, DVT-2 этапы, на которых проверяются доработки и исправления.

Также мы сейчас выделяем дополнительную стадию, которую называем preEVT. Это что‑то среднее между концептом и EVT: прототипирование, но уже оформленного продукта, его полнофункциональных образцов. На этом этапе у нас может быть 2–3 варианта инженерных и дизайнерских решений. Благодаря этому мы сможем точнее понять стоимость устройства, а у стейкхолдеров появляется возможность увидеть более приближенные к реальному устройству прототипы, чем на стадиях концепта.

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

«Привет, это Алиса!»