Сколько стоит разработка электроники? Допустим, нужно спроектировать очень простое коммерческое устройство – что‑то уровня датчика или маленького контроллера. Если делать все “по-взрослому”, а не на уровне хобби, то типовая вилка такого проекта будет в районе 1,5–3 млн рублей. Это только за разработку, без учета стоимости серийного производства.
С ростом сложности устройства будет расти и бюджет. Отсюда закономерный вопрос, который можно часто услышать от заказчиков без опыта подобных проектов: “А чё так дорого?”
В этой статье мы объясним, почему разработка электроники стоит так дорого и какие ошибки часто ведут к превышению бюджета.
Если вы как раз прикидываете бюджет своего проекта, можно просто написать нам. Обсудим идею, оценим трудозатраты и назовем реалистичные цифры.
Из чего состоит бюджет проекта по разработке электроники?
Как правило, бюджет проекта складывается из следующих составляющих:
- Оплата труда специалистов;
- Закупка материалов;
- Оплата изготовления прототипов;
- Оплата лицензий на программное обеспечение (если используется проприетарное ПО);
- Расходы на сертификацию.
Сначала пройдемся по первому пункту, а остальные затронем в других блоках.
Итак, поговорим о зарплатах в сфере разработки встроенных систем. Когда дело касается разработки мобильных или веб-приложений, то такие проекты можно выполнить относительно быстро и дешево без привлечения дорогих спецов. Но для проектирования встроенной электроники нужны узкие знания в сложных областях – в схемотехнике, программировании микроконтроллеров на C/C++, операционных системах реального времени, безопасности, технологиях беспроводной связи, FPGA и др. Порог вхождения в эти технологии очень высок, что сказывается на заработных платах специалистов.
Для разработки даже простого устройства нужен не один и не два таких кудесника. Проектирование устройства – это многоэтапный процесс, на каждом из которых требуется своя экспертиза.
Ниже приведен типовой перечень задач и участников проекта по разработке электроники.
1. Проработать архитектуру решения
Не каждый заказчик приходит к нам с готовым и проработанным техническим заданием. Нередко клиент лишь озвучивает боли своего бизнеса и “хотелки”. На этом этапе нужен системный аналитик. Он выступает эдаким мостом между заказчиком и командой разработки. Его задача – перевести “хотелки” клиента в четкие технические требования.
Системный аналитик собирает и формализует требования, сценарии использования и ограничения, оценивает выполнимость и экономическую целесообразность проекта, прорабатывает архитектуру будущего решения, выбирает технологии. Он также сопровождает проект на других этапах, в том числе на тестировании.
2. Разработать схемотехнику печатной платы
На следующем этапе требуется разработать принципиальную электрическую схему и топологию печатной платы. Здесь за дело берется схемотехник. Он должен не просто отрисовать плату так, чтобы компоненты на ней выполняли возложенные на них функции, но и решить следующие типовые сложности:
- Сделать плату надежной, чтобы не горела от любого чиха.
- Решить проблему отведения тепла.
- Сделать так, чтобы плата была защищена от электромагнитных помех и сама не фонила больше допустимого.
- Сделать плату технологичной, чтобы ее можно было изготовить на любой фабрике.
3. Написать прошивку
“Железо” без программы – это всего лишь дорогой кирпич. Поэтому далее наступает очередь программиста микроконтроллеров, который пишет встроенное ПО для будущего устройства.
В зависимости от сложности и ограничений по ресурсам может потребоваться создать bare-metal прошивку или программу на операционной системе. Важно при этом максимально оптимизировать код, чтобы минимизировать потребление памяти, процессорных ресурсов и электроэнергии – особенно если в устройстве мы вынуждены применять слабое аппаратное обеспечение или если устройство питается от аккумулятора.
Может также понадобиться разработать пользовательский интерфейс, если в устройстве предусмотрен экран, реализовать кастомные протоколы связи, добавить сервисные возможности для настройки прибора, обновления прошивки или диагностики.
4. Написать прикладное ПО
Если вы проектируете устройство, так сказать, “само в себе”, то на этом разработка ПО заканчивается. Но довольно часто встроенные системы помимо прошивки также требуют разработки серверных, мобильных или десктоп-приложений. Например, если мы хотим управлять прибором со смартфона, то нужно пилить приложение под Android или iOS, а возможно, еще и поднимать облако с блэкджеком и базой данных. В таких ситуациях подключается еще один программист, а то и несколько.
5. Протестировать систему
На следующем этапе проверяем, не долбанет ли корректно ли работает спроектированное решение. Этим занимается тестировщик, он же QA-инженер.
Цель тестирования – определить, соответствует ли разработанное решение требованиям заказчика и удобно ли им пользоваться. В задачи QA-специалиста входит выявление возможных рисков и “опасных зон”, подготовка тест-кейсов, сборка тестовых стендов, проведение собственно испытаний системы, в том числе в реальных условиях эксплуатации, и составление баг-репортов и другой документации.
Если обнаруживаются недочеты, разработчики их устраняют и устройство снова отправляется на испытания, и так пока тестировщику не к чему будет придраться.
Узнаете в этом списке свой будущий проект? Если не хотите собирать всю эту экспертизу по частям, можно привлечь внешнюю команду. Мы берем на себя как раз такие “сквозные” проекты – от формализации концепции до серийного производства. Напишите нам, чтобы обсудить ваш проект.
Сертификация устройств
Это еще один шаг, который часто обязателен в проектах по разработке электроники. Но часто это такая головная боль, что о сертификации стоит сказать отдельно.
Чтобы подтвердить, что разрабатываемое устройство не нарушает требований законодательства, нужны испытания. Иногда достаточно протестировать прибор у себя или в любой лаборатории, где есть нужное оборудование, и предоставить протоколы испытаний. Это если требуется декларация соответствия. Иногда испытания должны проводиться в аккредитованной лаборатории – чтобы заявитель не читерил. Это если нужен собственно сертификат соответствия. Читайте наши статьи про сертификацию электроники, чтобы разобраться в этом бедламе.
Суть в том, что, скорее всего, заказчику придется нанять юриста, который займется подготовкой документов. Есть целые компании, специализирующиеся на сопровождении сертификационных испытаний. Кроме того, если вы привлекаете лабораторию, ей тоже нужно заплатить за тестирование. Некоторые тесты устройство может вообще не пережить, а значит, придется заказывать еще один образец – это снова расходы. А если экспертиза покажет, что устройство не соответствует требованиям, то плату или ПО придется переделывать.
Впрочем, если все было сделано правильно – сертификационные требования были прописаны в ТЗ в начале проекта, и команда их реально учитывала при разработке, – то больших доработок не потребуется.
Приведем пример.
Был у нас проект по разработке USB перехватчика ввода.
Это маленький девайс, который ставится в клавиатуру компьютера для защиты корпоративных данных и их резервного сохранения на внутреннюю флеш-память NAND. Никакого криминала. Клиент с самого начала предупредил, что потребуется сертификация. Помимо прочего, нам нужно было уменьшить излучаемые устройством радиошумы.
Мы поставили на плату компоненты малой мощности и дополнительные фильтрующие конденсаторы на USB-интерфейс. Предусмотрели и особую трассировку для снижения помех. Гордые за проделанную работу, понесли приблуду в лабораторию… и провалили тестирование.
Оказалось, фонил тактовый генератор. По-хорошему, надо было использовать более дорогой и качественный, но это повышало себестоимость продукта. Так что мы просто защитили этот участок платы дополнительными фильтрующими цепями и поменяли расположение некоторых компонентов. Сработало.
Это мы еще легко отделались – потому что изначально учитывали требования сертификации. Но без переделок все равно не обошлось.
Итеративность разработки и стоимость ошибок
Зачем делать несколько итераций?
В стоимость разработки электроники входит не только оплата труда специалистов, но и расходы на всевозможные лицензии, закупку компонентов и производство печатных плат. Последнее не так уж и дорого по сравнению со стоимостью собственно разработки. Но в ходе проекта обычно приходится заказывать не одну, а несколько плат, что увеличивает расходы. Кто-то может возразить: а зачем делать несколько, если нужен лишь один образец?
Дело в том, что спроектировать электронику, которая полностью соответствует всем требованиям заказчика, с первой попытки почти невозможно. В первом прототипе неизбежно вылезет хоть один недочет, который потребуется исправлять. Поэтому разработка аппаратного обеспечения – процесс итеративный.
В идеале команда должна спроектировать и изготовить следующие итерации.
1. Макет
Бывает неясно, можно ли реализовать задумку теми или иными способами, как поведет себя некоторый компонент или насколько экономически эффективным будет решение. Тогда команде нужно сначала проверить концепцию.
Иногда достаточно моделирования, а иногда приходится создавать макет с помощью девкитов. Выглядят такие “платы” громоздко и неказисто, но позволяют точно сказать, будет ли работать то, в чем команда сомневается, или нет.
2. Функциональный прототип
Это уже полноценная печатная плата, но выполняет она только основную функцию. Второстепенные функции в ней могут быть не реализованы, она может не дотягивать до требований по характеристикам и дизайну, но позволяет начать работу над встроенным ПО.
3. Экспериментальный образец
Здесь мы уже рассчитываем получить устройство, полностью соответствующее требованиям заказчика и подходящее для серийного изготовления (если перед нами стоит такая задача). Но как правило, с первого раза не выходит, и в плате или прошивке обнаруживается пара косяков – обычно некритичных. В этом случае такой прототип называется экспериментальным образцом.
4. Опытный (серийный) образец
После устранения недостатков мы получаем устройство, которое полностью соответствует требованиям. Его уже можно производить на фабрике в нужном количестве, выкладывать фоточки в соцсетях, вешать на стену и все такое.
Подробнее о прототипировании можно почитать в нашем блоге.
Приведем пример.
Заказчик попросил нас спроектировать емкостную клавиатуру по образцу существующей модели. В емкостных клавиатурах под клавишами стоят конденсаторы и конусообразные пружины. Когда клавиша нажата, пружина сжимается и взаимная емкость площадок конденсатора возрастает. Команда должна была разработать матричную схему для опроса клавиш и добиться времени опроса не более 1 мс.
Было решено использовать в схеме операционный усилитель, чтобы сигналы можно было распознать, а также компаратор для отсечения слабых сигналов, которые возникают у не нажатых клавиш. Подобрать компоненты и вычислить коэффициент усиления мы решили с помощью виртуальной модели в LTSpice. Таким образом мы реализовали виртуальный макет.
Затем нужно было уточнить коэффициент усиления и уровень сравнения, и мы собрали прототип с помощью девкита. Это уже функциональный прототип: выглядит дешево и сердито, но ключевую функцию выполняет.
Затем команда спроектировала окончательный вариант платы и заказала его на фабрике. Когда плата приехала, пошли тестировать, и – кто бы сомневался – усиление оказалось ниже, чем показывали модели и макет. Так что на этом этапе получился экспериментальный образец.
Чтобы исправить недочет, пришлось заменить инвертирующий операционный усилитель на неинвертирующий и доработать трассировку. Тогда все заработало как требовалось, так что этот вариант стал опытным образцом.
Так вышло, что этот проект двигался по идеальной схеме прототипирования, но обычно мы стараемся ускорить процесс – без ущерба качеству. Если проект прост и понятен, а у команды есть релевантный опыт, то может потребоваться всего одна итерация. Если проект сложный и масштабный, итераций будет много. В среднем же в одном проекте делается 2–3 итерации одной платы.
Стоимость исправления ошибок
Допустим, у вас чисто софтовый проект. Вы пилите приложение для распознавания хотдогов котлет, проверяете очередную версию, и вдруг выясняется, что из-за какой-то ошибки программа принимает за котлеты сковородки. Вы находите баг, переписываете код, выкатываете обновление, и все работает как надо. На исправление ошибки ушло несколько часов работы. А теперь посмотрим, будет ли это работать в хардварном проекте.
Когда мы работали над системой для безопасной буксировки самолетов, наш схемотехник перепутал ноги микроконтроллера RX и TX. Все, кто проверял схему после него, благополучно это проморгали, и файл поехал на фабрику.
А теперь считаем: обнаружить ошибку – пару часов; исправить ее в документации – пара минут; изготовить новую версию платы – пару месяцев. А если бы увидели ошибку на ревью, ограничились бы только перерисовкой схемы.
Тогда перепутанные ноги удалось исправить с помощью паяльника непосредственно в офисе. К тому же, это был лишь первый прототип, в котором хватало и других недочетов, так что мы все равно собирались заказывать новую итерацию. Но суть в том, что в хардварных проектах даже небольшая ошибка, которую вовремя не заметили и не исправили, может ощутимо увеличить стоимость и сроки разработки.
Таким образом, исправлять ошибки в аппаратном обеспечении может быть значительно дороже, чем в программном. Это к вопросу, почему выгоднее вкладываться в выявление и решение всевозможных проблем “на берегу”, еще до старта собственно разработки. Лучше потратить время и деньги на проработку технического задания, проверку концепции на симуляциях или макетах, разные ранние тесты и вдумчивую проработку архитектуры, чем потратить еще больше на поздние переделки.
7 ошибок, из-за которых дорожает разработка встроенных систем
1. Непроработанное техническое задание
Признак: Регулярные недопонимания между заказчиком и командой; кардинальные изменения по ходу проекта.
Если у заказчика нет четкого видения продукта и понимания, какие функции нужно реализовать и какие характеристики он должен показывать, то проект может затянуться. Требования будут меняться в ходе работы. Это потянет за собой каскадные изменения по “железу” и софту. От некоторых фичей, возможно, придется отказаться, а значит, часть проделанной работы улетит в трубу.
Как лечится: Следует написать ясное ТЗ и устранить неопределенности “на берегу”. Бывают проекты, в которых четкого ТЗ нет и быть не может. В них высока доля исследовательской работы, многое выясняется и решается непосредственно в процессе, изменения ожидаемы. Но даже тогда до реальной разработки должны появиться минимум цели и границы продукта, набросок архитектуры, перечень ограничений, критерии готовности продукта.
2. Пытаться сделать швейцарский нож
Признак: Через полгода выясняется, что половина реализованных функций не используется, а сроки и бюджет уже съедены.
Попытки сделать швейцарский нож и запихнуть в продукт все функции, которые когда-либо могут понадобиться пользователю, значительно повышают стоимость разработки. И дело не только в том, что реализация каждой функции потребует времени и ресурсов команды. Проектирование универсального супер‑продукта приводит к усложнению схемы, разрастанию BOM, трудностям на этапе сертификации, росту числа отказов.
Как лечится: Отсекаем желательный, но не обязательный функционал.
3. Создавать разовый продукт, а не платформу
Признак: У каждого устройства своя схемотехника, свой софт и протоколы, а команда постоянно копирует и адаптирует старые решения вручную, вместо использования модулей или библиотек и общей архитектуры под линейку устройств.
Если речь идет о разработке модельного ряда со схожими функциями и характеристиками, то дешевле не проектировать каждую модель с нуля, а создавать модифицируемую платформу. Да, первый проект будет дороже, но уже со второго–третьего проекта расходы и время вывода продукта на рынок заметно снижаются.
Как лечится: На уровне стратегии зафиксировать, что делаем не один продукт, а платформу под линейку: выделить общие блоки (железо, ПО, протоколы) и спроектировать их как переиспользуемые модули с четкими интерфейсами.
4. Изобретать велосипеды
Признак: Большая часть времени уходит не на уникальные фичи, а на отладку базовых вещей, для которых уже есть серийные или готовые аналоги.
Если возможно, выгоднее использовать готовые компоненты и модули (Wi‑Fi, LTE, интерфейсы, датчики) вместо кастомных решений. То же касается программного обеспечения: если можно воткнуть в код готовые библиотеки или реализовать общение по готовому протоколу, не стоит тратить время и силы на кастомные. Чем больше вы опираетесь на уже протестированное “железо” и ПО, тем меньше итераций, багов и затрат на валидацию.
Как лечится: На этапе архитектуры явно проговаривать принцип “готовое где можно, свое где нужно”: сначала искать готовые модули и библиотеки и только при объективных причинах уходить в кастом.
5. Непродуманный выбор компонентной базы
Признак: Ключевой чип либо недоступен, либо делает изделие нерентабельным.
Радиоэлектронные компоненты – это такой же товар, как и все остальное. Их кто-то выпускает, объемы их производства ограничены, на них есть спрос, они устаревают, их подделывают. Не следует выбирать крутые, но экзотические и редкие компоненты – если только вы не проектируется единичное изделие под себя.
Как лечится: При подборе компонентов проверяем их жизненный цикл, смотрим остатки не в одном локальном магазине, а на крупных агрегаторах, закладываем возможность установки альтернатив.
6. Оставлять тесты на потом
Признак: Команда не выполняет системных тестов и ревью; недочеты копятся и “кочуют” из одной итерации устройства в другую.
Критичные риски можно устранить на этапе макетирования. Некритичные ошибки в дизайне платы или баги в прошивке можно выявить у первого же прототипа. Чем раньше обнаруживается проблема, тем дешевле ее устранить.
Как лечится: Закладывать бюджет и время на проведение испытаний до того, как команда перейдет к следующим этапам проекта.
7. Не вспоминать о сертификации до самого конца
Признак: В техническом задании ни слова о сертификационных требованиях.
Кажется, будто сертификация – это такой отдельный этап проекта, связанный с бумажками, а не с разработкой. Если плата работает как надо, то и сертификацию она пройдет без проблем. Знаем, плавали!
Как лечится: Нужно уже “на берегу” понимать, какие требования будут предъявляться к разрабатываемому решению, и учитывать их даже в архитектуре системы. Использование заранее сертифицированных модулей, блоков питания или компонентов обычно облегчает процесс, а значит, понадобится меньше переделок. Перед тем как обращаться к внешней лаборатории, стоит провести необходимые тесты самостоятельно (если есть оборудование): возможно, проблемы удастся выявить самим, и не придется зря платить за испытание, которое все равно будет провалено.
Подводим итоги
Разработка электроники дорогая потому, что заказчик оплачивает сложный и многоэтапный процесс, где на каждом этапе участвуют дорогие узкие специалисты. Кроме того, бюджет проекта раздувается, если у команды нет четкого технического задания, а требования постоянно меняются. При этом стоимость исправления ошибок может быть значительно выше, чем в чисто софтовых проектах, т.к. изготовление новой версии печатной платы стоит денег. Дополнительно заказчик тратится на сертификацию устройства.
Снизить стоимость можно только за счет зрелого подхода: писать внятное ТЗ, заранее учитывать сертификационные требования, по возможности использовать готовые модули и библиотеки, а также разумно выбирать компонентную базу с учетом доступности и альтернатив.
У каждого проекта своя цена и свой набор рисков. Их почти невозможно оценить абстрактно. Если хотите определить бюджет и самые дорогие риски именно для вашей задачи, свяжитесь с нами, и мы разберем ваш кейс точечно.