Всем привет!
В данной статье мы рассмотрим примеры ошибок при проектировании электронных устройств и как с ними бороться, посчитаем стоимость отката партии девайсов, ознакомимся с основным циклом прототипирования.
Введение
Вы наверняка слышали о случаях отзыва партии электронных устройств у различных производителей. Зависающие смартфоны, внезапно отключающиеся фотоаппараты, взрывающиеся электронные сигареты — все это результаты отсутствия правильного подхода к прототипированию устройств и экономия на тестировании девайсов.
Для пользователей такие случаи выглядят как обыденность и могут лишь подорвать их доверие к производителю девайсов. Для компании же, которая выпустила непротестированные должным образом устройства в серию случай брака может довести до отката всей партии девайсов, выплаты компенсаций и банкротства.
Инциденты из реальной жизни
Сейчас почти все портативные или стационарные устройства имеют интеллектуальное управление — используют вычислительные возможности микроконтроллеров, микропроцессоров, процессоров для своей работы. Тем самым перекладывая сложные схемотехнические взаимодействия на взаимодействия программные что очень упрощает отладку, разработку и фиксы ошибок, также, уменьшая стоимость девайсов. Плюс к этому производители стараются обезопасить себя в использовании схемотехнических решений в пользу программных чтобы в случае ошибок не перестраивать линии производства (на что затрачиваются немалые ресурсы). Тем не менее с развитием технологий технические требования устройств возрастают как и возрастает их сложность что накладывает дополнительные требования к проектированию и тестированию девайсов.
Программные ошибки решаются обновлением ПО девайса и не наносят серьезного ущерба. Примеры таких ошибок недавнего времени у известных компаний:
- 2019 год — ошибка входа в систему на умных часах от Samsung:
https://www.phonearena.com/news/Samsung-Gear-Galaxy-Watch-Wearable-app-down_id115504 - 2018 год — нашли ошибку вызывающую перезапуск Apple iPhone при отправке на них сообщения с определенными символами: https://www.express.co.uk/life-style/science-technology/919343/iPhone-Text-Message-Crash-WhatsApp
- 2016 год — найденная уязвимость в Android позволяет злоумышленникам получить доступ к ряду моделей смартфонов:
https://www.bbc.com/news/technology-37005226 - 2016 год — проблема с застреванием затвора в камерах Nikon D750:
http://thenewcamera.com/nikon-d750-shutter-err-problem/
Ошибки в ПО обычное дело для любого производителя устройств, они лишь говорят о том что схемотехника девайса была спроектирована должным образом и девайс не прекратил работу, не был поврежден при появлении таких ошибок.
Совсем другой характер носят ошибки схемотехники, компоновки электронных компонентов, механических частей, защиты девайса от внешних воздействий. В отличие от программных ошибок их невероятно тяжело либо невозможно устранить удаленно, а само устранение зачастую требует вливания средств перекрывающих перевыпуск продукта. К тому же ошибки в аппаратной части устройств часто носят деструктивных характер выводя девайс из строя.
Тем не менее к ошибкам в прошивках устройств (особенно выполняющих простые задачи, без возможности удаленного обновления прошивки) безответственно тоже относиться не стоит. Такие ошибки если и не вызовут полную переделку всей схемотехники, то могут вызвать откат всей партии девайсов для перепрошивки. При проектировании устройств на простых микроконтроллерах с периферией для связи с внешним миром можно обезопасить себя добавив в прошивку функционал удаленного обновления. Более подробно тему удаленного обновления прошивок мы затронем в одной из следующих публикаций.
Известные примеры проблем с аппаратной частью устройств:
- 2017 год — Spectre, Meltdown — масштабные аппаратные уязвимости на уровне ядра большинства процессоров Intel, AMD, ARM использующие механизм оптимизации выполнения команд для доступа к произвольным участкам памяти выделенной под конкретные приложения:
https://www.theguardian.com/technology/2018/jan/04/meltdown-spectre-worst-cpu-bugs-ever-found-affect-computers-intel-processors-security-flaw - 2016 год — известная проблема с аккумуляторами Samsung Galaxy Note 7 приводящая к возгоранию смартфонов. Последствия возгорания этой модели смартфонов привели к запрету их перевозке по воздуху в некоторых странах:
https://www.theguardian.com/technology/2016/oct/10/samsung-galaxy-note-7-exploding-phone-brand - 2013 год — наши дни — многочисленные инциденты с возгоранием аккумуляторов электронных сигарет приводящие к серьезным ожогам и травмам пользователей:
https://edition.cnn.com/2019/06/19/health/e-cigarette-vape-explode-teen-study/index.html (осторожно! шок-контент)
Данные примеры показывают, что ошибки аппаратной части устройств могут быть фатальными как для самого устройства так и для производителя. Именно поэтому разработка и тестирование аппаратной части должна проходить более деликатно.
Простой пример разрушающей ошибки в проектировании девайса
Последствия аппаратных ошибок понятны, но в чем же их причина?
Зачастую причиной появления ошибок в схемотехнике и механике девайса является неправильный подход либо вовсе отсутствие нагрузочных, краш тестов, тестов в агрессивной среде.
Предположим мы спроектировали простой девайс — компонент системы сбора метеоданных.
Девайс устанавливается на возвышенности (фонарный столб, ствол дерева, крыша здания).
Устройство состоит из:
- Ряда датчиков;
- Микроконтроллера;
- ZigBee передатчика;
- LiFePO4 аккумулятора на 2000мАч;
- Преобразователя напряжения;
- Контроллера заряда аккумулятора;
- Солнечной батареи для подзарядки.
Для герметизации устройства служит корпус выполненные по стандарту IP67 (см. https://en.wikipedia.org/wiki/IP_Code).
Блок схема девайса следующая:
Предположим что во время разработки были проведены тесты на:
- Автономную работу с использованием подзарядки от солнечной батареи;
- Передачу актуальных данных сенсоров на нужное расстояние;
- Потребление тока устройством в допустимых пределах;
- Герметичность корпуса.
Кажется что все необходимые тесты пройдены и можно запускать серийное производство.
Далее возможен следующий сценарий:
- Проходит подготовка документации к серийному производству.
- Выпускается пробная партия продукта в количестве 100 штук.
- Запуск продукта.
- После продолжительного успешного использования в несколько месяцев происходит расширение компании и выпуск партии в несколько тысяч устройств.
- Наступает лето, температура окружающей среды повышается.
- Из-за излишней герметичности устройства и отсутствия активного охлаждения девайсы постепенно нагреваются до температур непригодных для эксплуатации аккумуляторов.
- Емкость аккумуляторов стремительно падает из за чего становиться тяжелее поддерживать напряжение питания на должном уровне.
- DC/DC преобразователь чаще работая на пределе возможностей теряет КПД преобразования со временем рассеивая все большую мощность.
- В конце концов из за возросшей температуры активных элементов девайса происходит возгорание.
В при данном сценарии в лучшем случае девайсы просто выйдут из строя, в худшем станут причиной пожара.
Ошибка в проектировании девайса из этого примера лежит на начальных этапах построения схемотехники, отсутствии нагрузочных тестов в агрессивных условиях. Для предотвращения ошибки на оставшихся девайсах нужно полностью перестроить подход к использованию питающей части, герметизации.
Это означает что выпускать хотфиксы для девайсов с проблемами в схемотехнике, механике герметизации просто бессмысленно, намного дешевле и быстрее перевыпустить всю партию устройств.
Расчет цены простой ошибки в аппаратном проекте
В случае возникновения в аппаратном проекте сценария описанного выше производитель (заказчик) потерпит колоссальные убытки и упадок доверия со стороны клиентов, что может привести к банкротству.
В случае если компания намерена заняться перепроектированием и перевыпуском простых девайсов из примера, ей нужно будет потратить огромные средства как на себестоимость, так и на повторную разработку проблемных частей, тестирование.
Проведем простой расчет на перевыпуск всей серии девайсов:
Себестоимость: цена составных частей для одного девайса из примера колеблется в пределах 70–90$
Разработка: исправление проблем с питающей частью и герметизацией с предварительными тестами займет в таком проекте около 15 часов для Embedded Systems Engineer.
Симуляция, тестирование в агрессивных условиях: симуляция поведения девайса в окружающей среде, расчет потребления и рассеивания мощности, тесты в агрессивных условиях могут занять до 50 часов.
Средняя оплата труда для Embedded Systems Engineer составляет 30$/час.
Таким образом для покрытия затрат на исправление ошибок в на примере данного проекта понадобиться около 2000$, для перевыпуска пробной партии устройств в размере 100 штук — около 8000$.
Следует также прибавить к получившейся сумме стоимость потерянного времени и доверия клиентов, плюс при разворачивании худшего сценария сумму компенсации за причиненный девайсом ущерб.
Как избежать таких ошибок? Каким тестам нужно уделить большее внимание? В чем основные проблемы при проектировании аппаратных частей устройства? Об этом далее.
Пошаговое планирование разработки прототипа девайса
Для успешного запуска тестовой партии устройств необходимо иметь на руках полностью протестированный прототип девайса и полную техническую документацию описывающую технологию производства.
Ключевое слово тут “прототип” — девайс полностью реализующий требуемый функционал и готовый к доработкам и оптимизации для выпуска серии.
На этапе согласования сроков и тех. задания с заказчиком и командой, очень важно донести следующие факты:
- Если аппаратные модули работают стабильно по отдельности это нисколько не гарантирует их совместную стабильную работу.
- Успешное создание прототипа не означает что продукт можно запускать в серию — это лишь одно из достижений на пути к серийному производству.
- Каждое существенное исправление схемотехники, механики требует изготовления нового прототипа, проведения тестов (сколько бы времени на это не потребовалось, иначе изготовление прототипов не имеет смысла вообще).
- Сроки изготовления прототипов необходимо выделять с запасом т.к. производство зависит от многих внепроектных факторов.
- Симуляция и тестирование на отладочных стендах дает прирост скорости разработки только на ранних этапах проектирования, на поздних этапах оно лишь добавляет ошибок в прототипирование.
- После подготовки технологии производства нельзя сразу выпускать большую серию устройств, нужно обойтись мелкой партией для получения фибека и проведения тестов в “полевых условиях”.
- На этап планирования реализации устройства необходимо заложить дополнительные сроки и средства на поиск и приобретение аналогов, reverse-engineering решений.
- Все измерения характеристик устройства необходимо проводить на предельных режимах работы.
- Нагрузочные тесты и тесты в агрессивных условиях проводятся на больших промежутках времени в подготовленной среде.
Рассмотрим примерный план разработки прототипа устройства и подготовки к серийному производству:
- Проработка идеи устройства
Заказчик не всегда видит оптимальный путь решения задачи девайсов. Необходимо провести детальный ресерч и предложить свои варианты решения. - Составление тех. задания
Детальное тех. задание поможет в трудную минуту как команде исполнителей, так и заказчику для фокусировки процесса разработки на актуальных целях. - Постановка сроков на разработку прототипа устройства
Для адекватной постановки сроков необходимо разбить разработку девайса на несколько этапов, добавив поправки на производство прототипов. - Поиск готовых реализаций
Зачастую разработка нового девайса предполагает что такого девайса еще нет на рынке, либо характеристики устройства превосходят характеристики аналогов. Поэтому не стоит заострять внимание на готовых реализациях и компонентах общего назначения. Использование таких компонентов (готовые модули периферии, отладочные платы) позволит ускорить разработку на ранних этапах, но введет ограничение на дальнейшую разработку и прототипирование. - Поиск компонентов устройства
При выборе компонентной базы девайса не стоит мелочиться на себестоимости дискретных деталей. Микросхемы, микроконтроллеры, платы все это стоит копейки по сравнению с затратами на прототипирование и разработку проекта гарантируя стабильную работу компонентов. Лучше всего заказывать детали у проверенных авторитетных производителей, таких как: Microsemi, STMicroelectronics, ON Semiconductor, Honeywell, Panasonic, Vishay, Texas Instruments, Analog Devices. При выборе компонентов необходимо детально изучить их документацию. Иначе на последующих этапах может обнаружится что приобретенные компоненты не подходят под заявленные требования.
Данный подход актуален для решений специального назначения в которых девайс может выполнять только функции которые от него требуются, но не более. При использовании модулей общего назначения приходится экономить т.к. модульные решения обходятся не дешево. От чего естественно страдает качество компонентов, урезается функционал и появляются рамки использования таких модулей. Высокая себестоимость разработки на готовых модулях является дополнительным стимулом для разработки используя дискретные компоненты. - Разработка схемотехнической части
Во время разработки схемотехники девайса важно понимать как работает каждая дискретная часть устройства, иметь обширную документацию на каждый из компонентов и стараться дробить максимально модульные компоненты чтобы избавиться от “черных ящиков”. Важно добиться ясности в проектировании схем, чтобы избежать всех подводных камней на будущих этапах. - Симуляция схемотехники
Симуляция схемотехнической части очень помогает на ранних этапах проектирования, когда необходимо произвести проверку низкоуровневого взаимодействия компонентов. На последующих этапах проектирования становиться очень сложно проводить симуляцию т.к. подготовка симулятора занимает много времени. А результаты начинают разниться с реальным поведением девайсов из-за многих внешних воздействий которые симулятор воспроизвести не способен. Это связано с усложнением схемотехники и увеличением числа компонентов. Также детальная симуляция больших схем в реальном времени требует огромных вычислительных мощностей которые не всегда можно обеспечить. - Трассировка платы, проверка трассировки
Трассировку и проверку трассировки можно осуществить с использованием многочисленных САПР(Систем автоматизированного проектирования), таких как: Altium Design, KiCAD, EAGLE CAD, EasyEda.
При разработке трассировки необходимо провести расчеты на длину и ширину проводников ( исходя из частоты передаваемого сигнала, величины проходящих токов), расчеты расположения элементов, расчеты рассеивания мощности активных элементов. - Заказ плат для тестовой партии
Для экспресс тестов аппаратной части и ускорения разработки на ранних этапах можно изготавливать платы прототипов кустарным методом в домашних условиях. На последующих этапах разработки лучше всего отдавать изготовление плат на аутсорс (JLCPCB, PCBWAY как пример сервисов по профессиональному и дешевому изготовлению плат). - Сборка прототипа без прошивки
Для изготовление первого прототипа лучше всего заказать/произвести небольшую партию плат (5–10 шт.). Также необходимо заранее подготовить обширную элементную базу для замены комплектующих. - Тесты схемотехники
Тесты схемотехники девайса производятся по мере добавления новых частей на плату. К примеру:
1. Монтаж элементов питающей части.
2. Проверка соединений.
3. Запуск питающей части, сбор выходных характеристик в холостом и предельном режимах работы.
4. В случае соответствия необходимым требования монтаж следующей части и т.д.
5. В случае провала поиск ошибки и возвращение к пункту 6. основного списка. (да, это куча времени между началом разработки и первыми тестами, но иначе нельзя, новые изменения — новый прототип).
У производителей плат есть опция автоматического тестирования всех дорожек, проводников по предоставленному GERBER файлу. Стоит такая услуга недорого, а экономия средств и времени на последующих этапах ощутимая. - Разработка прошивки для тестов взаимодействия с периферией
На этом этапе необходимо написать прошивку выполняющую не функционал устройства а лишь правильно взаимодействующую с периферией девайса. Включить в тестовую прошивку основные вычислительные алгоритмы. - Тесты прошивки
Провести тестирование вычислительных алгоритмов прошивки можно локально, взаимодействие с периферией можно протестировать при помощи симулятора. Пример тестирования для микроконтроллеров AVR описывается в одной из прошлых статей.
Прогон тестовой прошивки на железе используя отладчик.
14. Разработка прошивки реализующей функционал устройства
Реализация прошивки на основе ранее протестированных модулей взаимодействия с периферией, вычислительных алгоритмов, оптимизация прошивки. Модульные тесты, тесты на симуляторе, тесты на железе. Можно смело применять TDD на данном этапе.
15. Что если выяснились недостатки схемотехники?
В случае если во время тестов прошивки выяснились существенные недостатки схемотехники (нестабильное поведение периферии, недостаток вычислительных мощностей) вернуться к пункту 5. (неизбежная потеря времени и средств).
16. Нагрузочные тесты, тесты в агрессивных условиях
Тесты в агрессивных условиях лучше всего проводить в специально подготовленном окружении имитирующем внешние воздействия. Предполагается что на этом этапе имеется десяток прототипов с стабильно работающей прошивкой готовые быть выведенным из строя предельными режимами работы. Сбор и проверка необходимых характеристик девайса. При провале тестов поиск ошибок и методов их устранения, вернуться к пункту 5.
17. Подготовка конструкторской документации для запуска тестовой серии продукта
Сбор актуальной документации в проекте, подготовка производственных файлов, поиск изготовителей, размещение заказов на площадках по изготовлению плат, корпусов, механики. При наличии нужного оборудования локально необходимо подготовить план технологии серийного производства, найти персонал. (данная тема заслуживает отдельной статьи и мы рассмотрим ее в следующих публикациях)
18. Если необходима сертификация девайса в специальных органах
В случае необходимости обязательной сертификации девайса для повседневного использования:
— Обращение в орган сертификации.
— Предоставление тех. документации.
— Выпуск небольшой партии (до 10 шт.) устройств, передача устройства органу сертификации для проведения тестов.
19. Запуск тестовой партии в количестве не более 100 штук
Поставка продукта в продакшн, сбор фидбека, поддержка.
- В случае обнаружения ошибок схемотехники — поиск методов решения, перейти к пункту 7;
- В случае обнаружения ошибок ПО — поиск методов их решения и перейти к пункту 12;
- В случае успешного использования на долгом промежутке времени запуск масштабной партии устройств.
В контексте данного плана разработка корпусов устройств, механических частей плотно коррелирует с разработкой схемотехнической и ее можно проводить параллельно проходя по тем же самым пунктам что и при разработки схемотехники.
Разработка и прототипирование устройств сильно разниться с разработкой ПО. Основной причиной этого является отсутствие возможности быстрой манипуляции физическими компонентами девайса в отличие от манипуляций виртуальными компонентами ПО. Проще говоря очень тяжело произвести или откатить изменения электронного девайса. На много проще и быстрее просто сделать девайс с нуля предварительно внеся нужные изменения в схему.
Выводы
Ошибки в аппаратных проектах также неизбежны как и в любых других. Важностью устранения таких ошибок является своевременное их обнаружение и адекватная реакция на них. Не стоит боятся перевыпуска прототипов — это обычная практика достижения стабильной работы аппаратной части устройства. Одним из главных факторов успешного построения плана разработки устройства является прозрачная коммуникация как внутри команды разработки, так и команды с заказчиком. Надеюсь данная статья помогла Вам приобрести основные навыки и знания по продвижения своего проекта разработки девайсов. Удачи в разработке и прототипировании!
Ранее статья была опубликована тут.
