- PVSM.RU - https://www.pvsm.ru -
Сейчас намного проще найти финансирование для своего проекта, проводятся стартап-аллеи, краудфандинговые платформы пестрят новинками. Ардуино приблизило мечтателей к заветной славе. IoT технологии взяли свое и IT фирмы поняли, что не кодом единым можно жить. Не редкое явление, когда hardware проектом руководят люди, которые несколько далеки от электроники. И еще чаще они думают, что жизненный цикл software-проекта аналогичен жизненному циклу hardware-проекта. Увы, это не так.
Организация процесса разработки железа — очень важный момент. Ошибка на любом этапе может «вылезти боком» и цена может оказать непомерно высокой. При создании материального объекта нет возможности выпускать каждый день новую версию. Проектирование — самый сложный этап разработки и о нем далее пойдет речь.
Примечание 1: данный материал предназначен для людей, которые не знакомы с (реальной) разработкой, это студенты и преподаватели, стартаперы, IT-фирмы, программисты. Все изложенное — личный опыт и наблюдения. Если Вы инженер с опытом и Вам есть что добавить — пишите в комментарии.
Примечение 2: здесь речь идет о простом жизненном цикле, от идет до железячки, но не до продажи. Почему так? Разной сложности проекты могут проходить очень многие этапы до продажи: поиск инвестора, если его нет, юридическая волокита, муляж, макет, устройство, отладка, разработки отладочных стендов (которые могут быть еще сложнее), сертификация, серийное устройство.
Хорошая команда — неотъемлемая часть проекта. Поскольку приходится работать с разными людьми и вливаться в проекты на разных этапах, собственно затем и был описан «жизненный цикл hardware проекта». В электронике бывают разные специалисты: инженер-схемотехник, инженер-конструктор печатных плат, инженер-программист (низкий уровень, то есть микроконтроллеры, микропроцессоры, ПЛИСы), инженер-технолог, технический дизайнер, монтажник и руководитель технической части или технический директор. Есть такая категория, как Embedder это специалист, который рассчитывает схему, проектирует, программирует, паяет (и швец, и жнец, и на дуде игрец). Среди заказчиков нередко бытует мнение, что нужно нанять человека, который сделает все, но разделение труда лучшая позиция и не стоит все валить на одного человека, особенно, если речь идет о стартапе, когда нужно вписаться в сжатые временные рамки и проделать много работы.
//естественно по этому поводу начали спорить с коллегой. Мол у стартапов не много денег, но, по-моему, количество денег это уже забота не инженера или тех директора. Если хотите одного человека, то ему придется работать день и ночь, а за это нужно очень хорошо платить (дешевле брать ему помощников), кроме того, некоторое время такая работа может быть интересной, но потом может просто начаться выгорание. Специалист бросает все и уходит в закат, а у начальства горит и подгорает.
Не так давно меня спросили как же все таки формируется команда для проекта разной сложности. Собственно это зависит от очень многих факторов: временные рамки, финансовые ограничения, исходные данные (напр. предыдущие наработки), что нужно получить на выходе (муляж, макет, красивый макет, устройство, серийный вариант, etc) и от ведущего проекта. Для простого проекта, типа драйвера для некой светодиодной вещицы может хватить и одного ембедера (рассчитал схему, растрассировал, запаял, запрограммировал и в продакшн). Был медицинский проект с составом: ведущий, эмбедер для основного блока и блока передачи энергии, программист низкого уровня для работы с передачей информации, программист высокого уровня (ПО для ПК и телефона), около-инженеришка для мелкой работы (на тот далекий момент я) типа рисования библиотеки компонентов для САПР, документации, теор. расчеты, отдельный логист (он сам занимался закупками и контролем поставок), технолог и технический дизайнер. Но это с учетом того, что были предыдущие версии устройства, специалисты, которые их разрабатывали, дедлайны много раз передвигались, отладка и испытания на живых образцах (никто не пострадал). Работы было очень много, но никто не представлял на начальном этапе НАСКОЛЬКО много, хотя наработки и опыт был.
Для проекта носимых устройств мне хватает конструктора ПП, который и логистикой занимается, ембедер для расчетов и программирования, монтаж на фирме или частное лицо. Соответственно верхнее ПО/дизайн на себя берет заказчик (или по договору подыскивается человек).
Почему нет смысла валить все на одного человека/на себя любимого? Конечно, если целыми днями бьешь баклуши и у тебя один заказчик, которому сроки не горят, то делай. НО если проектов много и человек действительно ценит свое время и деньги, то рациональнее делегировать задачи другим. Например: я могу сама заняться программирование МК, но буду разбираться с этим дольше, чем инженер-программист (поскольку я лучше работаю с проектированием ПП) и я потеряю больше, чем получу, при нарушении сроков и штрафах (например) или могу вовсе потерять клиента.
В любом случае, думаю, что этот опыт формируется только в процессе работы. Так же интересно в комментариях услышать ваше мнение на этот счет.
Чтобы не было вот так ^, нужно четко и железно (как ни иронично) все распланировать.
Отдельный привет тем, кто любит не объяснять толком задачу, но просит рассчитать себестоимость. Это глупая затея, поскольку предварительная оценка совершенно не гарантирует того, что в эту сумму можно будет вписаться;
Жизненный цикл программного обеспечения зависит от специфики проекта, но в основном все по шаблону:
Стоит добавить, что все таки разработка ПО нижнего уровня и ПО верхнего уровня отличаются, поскольку все очень и очень зависит от железа. Непропаи, качество платы, компонентов, фаза луны, да что угодно могут повлиять на корректность работы программы, именно потому инженер-программист таки инженер, ему так же приходится помимо постукивания по клавиатуре тыкать паяльником в плату.
Серьезно, полоскайте своего программиста, как хотите, но он должен вести документацию. Ему вдруг предложили более лакомое место или переехал велосипедист — все. Разбираться в чужом коде, без комментариев, без алгоритма — невыносимая боль, проще писать все с нуля (а это время и деньги).
Программист, помни про карму, сдашь проект без комментиков и сам однажды в такой же попадешь!
Работаем в паре с техническим дизайнером на этапе трассировки, потому как нужно утвердить, что плата устраивает и становится корпус, до отправки в производство. Если программное обеспечение позволяет, то удобнее всего выкатить 3D модель печатной платы. У дизайнеров свои нюансы, но тоже нужно учесть из какого материала будет корпус, каким методом он будет производиться (если уже серийный, то можно делать пресс-форму или 3D-печать для макета) или это будет покупаться готовый и просто дорабатываться.
Организация производства тоже немаловажная часть, особенно, если у вас нет своего цеха. На все про все (организацию, не само производство) лучше выделить ~месяц, далее объясняем почему.
Когда появилась утвержденная схема, пора браться за покупку компонентов, поскольку не все бывает в наличии. Пока плата не растрассирована, есть возможность без проблем внести изменения. Компоненты лучше закупать у официальных поставщиков и дистрибьюторов. Конечно, вы можете закупить в Китае, но если это китайский Китай, то половина микросхем может быть бракованная. То же касается и покупки на сайтах частных объявлений.
Поставщиков много, если у одного светодиоды стоят дешевле, то не значит, что у него все дешевле (да, есть люди, которые так думают, для них и замечание). Эффективнее всего сводить цены и сроки разных поставщиков в таблице. Закупать лучше с запасом 20-30% (была ситуация с транзисторами 0402, которые купили впритык по количеству, а при пайке их феном посдувало).
Также есть нюансы с поставками, например, требовался модуль, он есть только в Китае, нам необходимо всего пару десятков, но поставщикам не выгодно его везти (особенно в таком количестве), потому что они потратят слишком большую сумму на получение специальных документов. Потому заказывали обычной почтой, сроки там сильно плавают. Недавние грабли научили еще вот чему: держите руку на пульсе, звоните своему поставщику каждые 3-5 дней, потому что чаще всего они сами и не уведомят о том, что возникли проблемы. Товар едет из Англии, обещали 5-9 рабочих дней. Прошло две недели, окей, после долгого смущения и попыток оправдаться, оказалось, что на момент заказа товара на складе не было (хотя говорили, что все в наличии, все ок) и он только выехал и будет еще через неделю, а уже нужно запускать производство. Цирковые-поставщики.
Когда плата растрассирована, проверена, то быстро оформляем гербер-файлы и отправляем в производство. Но, тут тоже подводный камень, на производствах обычно есть очередь.
Производители бывают разные, есть те, кто делает долго и качественно, а есть те, кто быстро и не очень качественно, но для небольшой партии макета подойдет. Все допускают ошибки, заказали платы на лучшем предприятии, все по фен-шую, но тут они приходят и на месте центрального пада одной из микрух (барабанная дробь) маркировка (шелкография). Был один вопрос: как? Сроки позволяли и нам их переделали, но в следующий раз они вообще умудрились один из полигонов удалить. Бывают разные ситуации, все риски не учесть, но стоит быть к ним готовыми.
Монтаж. Если партии большие, то есть смысл заказывать автоматизированный монтаж или если эти платы не один раз будут запускаться в производство. В любом другом случае — ручной монтаж. Предприятия берутся за мелкие партии очень неохотно, потому что это скорее убыточно.
Если ищем самостоятельно монтажников, то лучше заранее спросить чем паяет, о сложных корпусах (например, транзисторы в корпусе 0402 или LGA-14), показать монтажку (убедиться, что человек действительно в нее будет смотреть, а то один раз припаяли два вертикально и близко расположенных резистора горизонтально).
Тут еще следует упомянуть, что иногда вопрос о способе монтажа может подняться на этапе трассироваки. Например, есть компонент в корпусе SOT-23, но в библиотеке для этого корпуса два посадочных места — обычное и от NXP; для микросхем посадочные могут быть с задним и передним миниском.
Это крайне специфический этап. Порой для отладки нужно собирать целые стенды, которые дороже устройства. Еще может быть такое, что от способа отладки может зависеть концепция платы, например: устройство состоит из 3 плат и раньше отлаживали каждую отдельно, а потом все в куче, но начальство предложило вообще все 3 платы делать одним куском, а потом их разламывать. В таком случае устройство для отладки одно, но нужно тогда потратить время уже на три платы и новый стенд, это оказалось не выгодно (просто потому что тогда нужна была модификация только одной платы).
Если в ходе отладки были выявлены ошибки, их лучше всего задокументировать, чтобы впредь не наступать на те же грабли.
Почему все таки лучше начинает проект с макета, а не разрабатывать сразу опытное устройство/серийное? Потому что в случае второго невозможно сразу сказать дело в качестве платы, элементной базе или в пайке.
И не забываем об использовании блоков питания и особенно юсб-хабов (а то один горе-падаван спалил себе комп в первые же дни).
Разработка железа это долго, дорого, сложно, но очень-очень интересно, писать об этом можно еще и еще. Главное не забывать фразу "Делай хорошо, плохо получится само".
В планах так же написать статьи о схемотехнике (от идеи до схемы, с чего вообще начинать, как делать расчеты, что нужно знать и понимать? То есть, для новичков), трассировке (прорисовка компонентов, сложные посадочные места, лайфхаки, туториал по САПР), пайке и граблях с масштабированием производства, если вам, конечно, интересно.
Всех с праздничками и наступающими рабочими буднями!
Автор: AnotherReality
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/electronics/232531
Ссылки в тексте:
[1] Источник: https://habrahabr.ru/post/319370/?utm_source=habrahabr&utm_medium=rss&utm_campaign=sandbox
Нажмите здесь для печати.