Сейчас намного проще найти финансирование для своего проекта, проводятся стартап-аллеи, краудфандинговые платформы пестрят новинками. Ардуино приблизило мечтателей к заветной славе. IoT технологии взяли свое и IT фирмы поняли, что не кодом единым можно жить. Не редкое явление, когда hardware проектом руководят люди, которые несколько далеки от электроники. И еще чаще они думают, что жизненный цикл software-проекта аналогичен жизненному циклу hardware-проекта. Увы, это не так.
Организация процесса разработки железа — очень важный момент. Ошибка на любом этапе может «вылезти боком» и цена может оказать непомерно высокой. При создании материального объекта нет возможности выпускать каждый день новую версию. Проектирование — самый сложный этап разработки и о нем далее пойдет речь.
Примечание 1: данный материал предназначен для людей, которые не знакомы с (реальной) разработкой, это студенты и преподаватели, стартаперы, IT-фирмы, программисты. Все изложенное — личный опыт и наблюдения. Если Вы инженер с опытом и Вам есть что добавить — пишите в комментарии.
Примечение 2: здесь речь идет о простом жизненном цикле, от идеи до железячки, но не до продажи. Почему так? Разной сложности проекты могут проходить очень многие этапы до продажи: поиск инвестора, если его нет, юридическая волокита, муляж, макет, устройство, отладка, разработки отладочных стендов (которые могут быть еще сложнее), сертификация, серийное устройство.
ПП — печатная плата;
ТЗ — техническое задание;
BOM — Vill Of Materials или перечень элементов.
Жизненный цикл проекта
- Составление ТЗ (общая концепция, функции, проработки потенциальных путей решения, сопоставление со сроками);
- Разработка приблизительной концепции (картиночки для начальства/спонсоров);
- Составление диаграммы Ганта/расписания/дедлайнов;
- Утверждения поставленных задач с командой;
- Разработка ПП + написание программы для МК;
- Прорисовка корпуса (по утвержденной 3д модели) + заказ ПП и закупка комплектующих для ПП;
- Монтаж ПП + изготовление корпуса;
- Отладка, много отладки, море отладки;
- Тестирование;
- Фоточки/пресс-релизы/слезы/звонки маме.
Команда
Хорошая команда — неотъемлемая часть проекта. Поскольку приходится работать с разными людьми и вливаться в проекты на разных этапах, собственно затем и был описан «жизненный цикл hardware проекта». В электронике бывают разные специалисты: инженер-схемотехник, инженер-конструктор печатных плат, инженер-программист (низкий уровень, то есть микроконтроллеры, микропроцессоры, ПЛИСы), инженер-технолог, технический дизайнер, монтажник и руководитель технической части или технический директор. Есть такая категория, как Embedder это специалист, который рассчитывает схему, проектирует, программирует, паяет (и швец, и жнец, и на дуде игрец). Среди заказчиков нередко бытует мнение, что нужно нанять человека, который сделает все, но разделение труда лучшая позиция и не стоит все валить на одного человека, особенно, если речь идет о стартапе, когда нужно вписаться в сжатые временные рамки и проделать много работы.
//естественно по этому поводу начали спорить с коллегой. Мол у стартапов не много денег, но, по-моему, количество денег это уже забота не инженера или тех директора. Если хотите одного человека, то ему придется работать день и ночь, а за это нужно очень хорошо платить (дешевле брать ему помощников), кроме того, некоторое время такая работа может быть интересной, но потом может просто начаться выгорание. Специалист бросает все и уходит в закат, а у начальства горит и подгорает.
Не так давно меня спросили как же все таки формируется команда для проекта разной сложности. Собственно это зависит от очень многих факторов: временные рамки, финансовые ограничения, исходные данные (напр. предыдущие наработки), что нужно получить на выходе (муляж, макет, красивый макет, устройство, серийный вариант, etc) и от ведущего проекта. Для простого проекта, типа драйвера для некой светодиодной вещицы может хватить и одного ембедера (рассчитал схему, растрассировал, запаял, запрограммировал и в продакшн). Был медицинский проект с составом: ведущий, эмбедер для основного блока и блока передачи энергии, программист низкого уровня для работы с передачей информации, программист высокого уровня (ПО для ПК и телефона), около-инженеришка для мелкой работы (на тот далекий момент я) типа рисования библиотеки компонентов для САПР, документации, теор. расчеты, отдельный логист (он сам занимался закупками и контролем поставок), технолог и технический дизайнер. Но это с учетом того, что были предыдущие версии устройства, специалисты, которые их разрабатывали, дедлайны много раз передвигались, отладка и испытания на живых образцах (никто не пострадал). Работы было очень много, но никто не представлял на начальном этапе НАСКОЛЬКО много, хотя наработки и опыт был.
Для проекта носимых устройств мне хватает конструктора ПП, который и логистикой занимается, ембедер для расчетов и программирования, монтаж на фирме или частное лицо. Соответственно верхнее ПО/дизайн на себя берет заказчик (или по договору подыскивается человек).
Почему нет смысла валить все на одного человека/на себя любимого? Конечно, если целыми днями бьешь баклуши и у тебя один заказчик, которому сроки не горят, то делай. НО если проектов много и человек действительно ценит свое время и деньги, то рациональнее делегировать задачи другим. Например: я могу сама заняться программирование МК, но буду разбираться с этим дольше, чем инженер-программист (поскольку я лучше работаю с проектированием ПП) и я потеряю больше, чем получу, при нарушении сроков и штрафах (например) или могу вовсе потерять клиента.
В любом случае, думаю, что этот опыт формируется только в процессе работы. Так же интересно в комментариях услышать ваше мнение на этот счет.
Организационные моменты
Чтобы не было вот так ^, нужно четко и железно (как ни иронично) все распланировать.
- Составление ТЗ (общая концепция, функции, проработки потенциальных путей решения, сопоставление со сроками). Есть много шуток на тему «какое ТЗ — такое и решение», но лишний раз не стоит пренебречь напоминанием. Чем подробнее ТЗ, тем меньше сюрпризов будет возникать по ходу дела. Не обязательно разбираться в электронике, но более чем достаточно описать, что должно делать устройство, какие ориентировочные габариты, особые составляющие, бюджет, сроки. Если инженеры — отдельная команда, то можно оформить коммерческое предложение, где инженеры опишут ваше ТЗ с технической стороны (не бесплатно, конечно, потому что это уже серьезная работа):
- метод реализации, например, это может быть полногабаритный макет с последующими доработками для создания опытного образца или сразу опытный образец (а такое тоже бывает, но не рекомендую);
- выходная продукция (можно просто отдать работающее устройство, а можно и схемы/чертежи/сборочную документацию);
- перечень задач обычно описывает жизненный цикл проекта;
- технические требования к устройству;
- расценки сроки и оплата.
Отдельный привет тем, кто любит не объяснять толком задачу, но просит рассчитать себестоимость. Это глупая затея, поскольку предварительная оценка совершенно не гарантирует того, что в эту сумму можно будет вписаться;
- Разработка приблизительной концепции (картиночки для начальства/спонсоров). Чаще всего это на скорую руку подобранная элементная база и накиданная на печатную плату, чтобы получить 3D модель, примерить ее в корпус и обрадовать начальство. Но это только ориентировочная модель, в 90% случаев что-то может пойти не так (нет нужных размеров аккумулятора, например, или при трассировке просто не влазит в эти габариты и нужно буквально на пару мм увеличить, или все пошло слишком хорошо и плату можно уменьшить);
- Разработка диаграммы Ганта/расписания/дедлайнов. Один из важнейших моментов. Инженеру нужно оценить сроки и объем задач в комплексе. Есть промежуточные этапы демонстрации результатов, их тоже нужно оглашать, чтобы не было сюрпризов. Обязательно нужно закладывать риски. Например, один важный элемент едет из-за границы, заплатили за срочную доставку, но он где-то задержался. Кроме того, все мы знаем, что если дедлайна нет, то все это делается без всякого энтузиазма, вяло, долго и нудно;
- Утверждения поставленных задач с командой. Все расписано, составлено, еще раз просматриваем графики и задачи, обсуждаем спорные моменты, подписываем/не подписываем бумажки и начинаем работать.
Жизненный цикл разработки ПП
- Подбор элементной базы (какие компоненты будут закладываться). Анализируем цены, доступность и сроки поставки. Подбор выполняется в динамическом режиме вместе с созданием схемы. Выбор элементной базы проводится на основе схемы электрической принципиальной с учетом изложенных в ТЗ условий и требований;
- Прорисовка компонентов. Условно-графическое обозначение, посадочное место, 3D-модель, параметры — составляющие любого компонента. Разные инженеры по разному ведут свои библиотеки, некоторые пользуются готовыми. Для меня правило — дотошная прорисовка. 3D-модель компонента позволяет не только потом выкатить 3D-модель платы, но и проверить правильность посадочного места. Под разные технологии разные посадочные места. Разные параметры (пусть даже номинал просто отличается) — разные компоненты. Это упразняет море ошибок ручной правки;
- Создание схемы. Как есть правила написания читабельного кода, так есть правила создания читабельной схемы. Схему можно разделить на блоки, подписать их, расставить по пути протекания тока. Указать пины, которые можно свапать. Чем подробнее схема, тем меньше вопросов при трассировке. Если устройство состоит из нескольких печатных плат, то намного удобнее каждую схему вести отдельно, но потом обязательно нужно создать сборочную схему с указанием как платы между собой соединяются. Впрочем, все это описано в стандартах;
- Утверждение схемы. Еще раз проверяем элементную базу, расчеты, даташиты. Лучше лишний раз потратить 5-15 минут, чем потом резать дорожки и паять бутерброды;
- Правки схемы по необходимости. Внесли правки, утвердили и уже на этом этапе можно выкатить BOM (перечень элементов) и заказать ключевые микросхемы, которые наверняка меняться не будут. Мелочевка (резисторы/конденсаторы/диоды etc) может меняться;
- Трассировка печатной платы. При необходимости корректируется схема и элементная база. Это довольно творческий процесс, можно трассировать, трассировать, а потом забить и начать все заново. Про автотрассировщики мнение неоднозначное, все делают как считают нужным. Так же при трассировке важно учитывать и технологию производства печатной платы, потому как если я знаю, что буду делать там, где качество не блещет, то не стану делать сверхтонкие дорожки и маленькие переходные;
- Утверждение растрассированной ПП;
- Выдача 3D-модели ПП. Честно, все заказчики любят модельки, это беспроигрышный вариант, если дедлайн на подходе. Кроме того отдаем модель нашим дизайнерам и они подгоняют корпус или ворчат и просят тебя что-то изменить;
- Подготовка гербер-файлов для изготовления печатной платы. На производство лучше всего отправлять именно гербера. Во-первых, если вы отправите просто *.pcbdoc, то по нему можно сделать реверс инжиниринг. Во-вторых, в этом случае производитель не несет ответственности за то, как они подготовят гербера, то есть, если вы отдали *.pcbdoc и они при «конвертации» случайно удалили какой-нибудь полигон/компонент, то не их вина. Не ленитесь, подготавливайте гербера, проверяйте их в специальных программах. Особенно важно сопоставить вместе со сверловкой;
- Подготовка документации. Стандартный комплект документации: перечень элементов, спецификация, чертеж, топология, монтажная документация. Ее можно делать по ГОСТу, по зарубежным стандартам или по своему собственному. Если же делаете по-своему, то лучше придерживаться унификации, проще будет разобраться.
- Перечень элементов нужен как для закупки, так и для монтажника (в основном достаточно туда вывести designator, component name, package, quantity, по наличию/желанию value, marking). Маркировку указывают не все, но это упрощает работу монтажнику, ему не приходится думать 30KOm это 303 или 304? Полнота документации наше все;
- Спецификация — все составные части, входящие в изделие, здесь также отмечена входящая в данное изделие документация: сборочный чертеж печатной платы, схема электрическая принципиальная, перечень элементов;
- Чертеж — это может быть габаритный чертеж или сборочный. Он может пригодится для проверки ПП после производства или для доработки купленного корпуса;
- Топология — нужна для проверки платы. Если плата маленькая или на ней много компонентов, то лучше всего проверить все ли правильно, не ошибся ли где-то производитель;
- Монтажная документация — контурное изображение изделия, а также данные, необходимые для его установки (монтажа) на месте применения. В состав входит: контур печатной платы, топология, изображение компонентов (вид сверху), маркировка, обозначение, иногда вид сбоку или в разрезе, если монтаж сложный. Не забываем про ключи на компонентах, это тоже очень важно, чтобы потом монтажник не устраивал истерики. Ушла как-то моя еще первая плата на монтаж с моей первой документацией и тут залетает в КБ тетенька с криком «Где тут плюс и минут у диода?». Или заказчик сам все припаял, пожаловался что ничего не работает, прислал фотографию, а контроллер-то он не так припаял.
- Перечень элементов нужен как для закупки, так и для монтажника (в основном достаточно туда вывести designator, component name, package, quantity, по наличию/желанию value, marking). Маркировку указывают не все, но это упрощает работу монтажнику, ему не приходится думать 30KOm это 303 или 304? Полнота документации наше все;
- Утверждение документации
Написание программы нижнего уровня
Жизненный цикл программного обеспечения зависит от специфики проекта, но в основном все по шаблону:
- Анализ требований;
- Разработка алгоритмов (создание логики работы программы);
- Написание исходного кода;
- Компиляция;
- Тестирование и отладка (очень много отладки);
- Документация.
Стоит добавить, что все таки разработка ПО нижнего уровня и ПО верхнего уровня отличаются, поскольку все очень и очень зависит от железа. Непропаи, качество платы, компонентов, фаза луны, да что угодно могут повлиять на корректность работы программы, именно потому инженер-программист таки инженер, ему так же приходится помимо постукивания по клавиатуре тыкать паяльником в плату.
Серьезно, полоскайте своего программиста, как хотите, но он должен вести документацию. Ему вдруг предложили более лакомое место или переехал велосипедист — все. Разбираться в чужом коде, без комментариев, без алгоритма — невыносимая боль, проще писать все с нуля (а это время и деньги).
Программист, помни про карму, сдашь проект без комментиков и сам однажды в такой же попадешь!
Прорисовка корпуса
Работаем в паре с техническим дизайнером на этапе трассировки, потому как нужно утвердить, что плата устраивает и становится корпус, до отправки в производство. Если программное обеспечение позволяет, то удобнее всего выкатить 3D модель печатной платы. У дизайнеров свои нюансы, но тоже нужно учесть из какого материала будет корпус, каким методом он будет производиться (если уже серийный, то можно делать пресс-форму или 3D-печать для макета) или это будет покупаться готовый и просто дорабатываться.
Почему цикл?
Я все это называю циклом, потому что эта серия задач (схема, плата, корпус, программа) составная часть продукта. Порой для достижения финишной точки «продукт» эту цепочку задач необходимо пройти несколько раз. Даже внутри «серии» тоже все циклично. При разработке схемы вы снова и снова возвращаетесь к элементной базе; от платы к схеме; от корпуса к плате. И туда сюда. Это, наверное, похоже на паутину, изменение в одном узле иногда тянет за собой изменения и во многих других. Поэтому я применяю такой термин. Если у тру инженеров это называется иначе, — напишите и я поправлю.
Производство
Организация производства тоже немаловажная часть, особенно, если у вас нет своего цеха. На все про все (организацию, не само производство) лучше выделить ~месяц, далее объясняем почему.
Когда появилась утвержденная схема, пора браться за покупку компонентов, поскольку не все бывает в наличии. Пока плата не растрассирована, есть возможность без проблем внести изменения. Компоненты лучше закупать у официальных поставщиков и дистрибьюторов. Конечно, вы можете закупить в Китае, но если это китайский Китай, то половина микросхем может быть бракованная. То же касается и покупки на сайтах частных объявлений.
Поставщиков много, если у одного светодиоды стоят дешевле, то не значит, что у него все дешевле (да, есть люди, которые так думают, для них и замечание). Эффективнее всего сводить цены и сроки разных поставщиков в таблице. Закупать лучше с запасом 20-30% (была ситуация с транзисторами 0402, которые купили впритык по количеству, а при пайке их феном посдувало).
Также есть нюансы с поставками, например, требовался модуль, он есть только в Китае, нам необходимо всего пару десятков, но поставщикам не выгодно его везти (особенно в таком количестве), потому что они потратят слишком большую сумму на получение специальных документов. Потому заказывали обычной почтой, сроки там сильно плавают. Недавние грабли научили еще вот чему: держите руку на пульсе, звоните своему поставщику каждые 3-5 дней, потому что чаще всего они сами и не уведомят о том, что возникли проблемы. Товар едет из Англии, обещали 5-9 рабочих дней. Прошло две недели, окей, после долгого смущения и попыток оправдаться, оказалось, что на момент заказа товара на складе не было (хотя говорили, что все в наличии, все ок) и он только выехал и будет еще через неделю, а уже нужно запускать производство. Цирковые-поставщики.
Когда плата растрассирована, проверена, то оформляем гербер-файлы и отправляем в производство. Но, тут тоже подводный камень, на производствах обычно есть очередь.
Производители бывают разные, есть те, кто делает долго и качественно, а есть те, кто быстро и не очень качественно, но для небольшой партии макета подойдет. Все допускают ошибки, заказали платы на лучшем предприятии, все по фен-шую, но тут они приходят и на месте центрального пада одной из микрух (барабанная дробь) маркировка (шелкография). Был один вопрос: как? Сроки позволяли и нам их переделали, но в следующий раз они вообще умудрились один из полигонов удалить. Бывают разные ситуации, все риски не учесть, но стоит быть к ним готовыми.
Монтаж. Если партии большие, то есть смысл заказывать автоматизированный монтаж или если эти платы не один раз будут запускаться в производство. В любом другом случае — ручной монтаж. Предприятия берутся за мелкие партии очень неохотно, потому что это скорее убыточно.
Если ищем самостоятельно монтажников, то лучше заранее спросить чем паяет, о сложных корпусах (например, транзисторы в корпусе 0402 или LGA-14), показать монтажку (убедиться, что человек действительно в нее будет смотреть, а то один раз припаяли два вертикально и близко расположенных резистора горизонтально).
Тут еще следует упомянуть, что иногда вопрос о способе монтажа может подняться на этапе трассировки. Например, есть компонент в корпусе SOT-23, но в библиотеке для этого корпуса два посадочных места — обычное и от NXP; для микросхем посадочные могут быть с задним и передним миниском.
Отладка
Это крайне специфический этап. Порой для отладки нужно собирать целые стенды, которые дороже устройства. Еще может быть такое, что от способа отладки может зависеть концепция платы, например: устройство состоит из 3 плат и раньше отлаживали каждую отдельно, а потом все в куче, но начальство предложило вообще все 3 платы делать одним куском, а потом их разламывать. В таком случае устройство для отладки одно, но нужно тогда потратить время уже на три платы и новый стенд, это оказалось не выгодно (просто потому что тогда нужна была модификация только одной платы).
Если в ходе отладки были выявлены ошибки, их лучше всего задокументировать, чтобы впредь не наступать на те же грабли.
Почему все таки лучше начинает проект с макета, а не разрабатывать сразу опытное устройство/серийное? Потому что в случае второго невозможно сразу сказать дело в качестве платы, элементной базе или в пайке.
И не забываем об использовании блоков питания.
Заключение
Разработка железа это долго, дорого, сложно, но очень-очень интересно, писать об этом можно еще и еще. Главное не забывать фразу "Делай хорошо, плохо получится само".
В планах так же написать статьи о схемотехнике (от идеи до схемы, с чего вообще начинать, как делать расчеты, что нужно знать и понимать? То есть, для новичков), трассировке (прорисовка компонентов, сложные посадочные места, лайфхаки, туториал по САПР), пайке и граблях с масштабированием производства, если вам, конечно, интересно.
Всех с праздничками и наступающими рабочими буднями!
Комментарии ()
Prometheus
12.01.2017 12:47В жизненном цикле проекта, самое простое и легкое — это разработка ПП, чуть сложнее — разработка ПО, а самое сложное и дорогое — корпус устройства. Чтобы было технологично и в то же время концептуально — куча итераций.
AnotherReality
12.01.2017 13:22+2Каждый специалист считает, что его работа самая сложная. Есть много устройств, где корпус был самой меньшей проблемой. Мне, как конструктору ПП, не очень, когда сеют подобные высказывания среди народа, потому что потом заказчики начинают «а почему так долго, а почему то, а почему се». Потому и описан цикл разработки ПП, на этом этапе закладывается элементная база и ошибка при выборе или при трассировке может стоить очень и очень дорого, кроме того нужно балансировать на стыке средств и технологий производства.
mitgard
12.01.2017 14:17Поддерживаю, мне кажется, что самое главное в цикле, это чтобы цикл работал ровно без резких ускорений и простоев. Сложнее тому, кому подстраиваться больше надо.
P.S. В примечание 2 опечатка в слове «идеи».
user343
12.01.2017 16:33"Печень элементов" и "полоскайте программиста" — тоже как-то двузначно.
То ли прополоскайте ему мозги (метод Кнута), то ли облАскайте (пряником). Но кавычек не хватает ПМСМ.
Вопрос автору — это в России или где такое живое пр-во ещё сохранилось?
Если захотеть машину времени и нарисовать её цикл разработки — тоже получится? :)
трассироваки— ??
Или к этому сайту надо приделать Ctrl+Enter про опечатки, чтоб он не был машиной для подавления угнетенных (кармой) классов. https://orphus.ru/AnotherReality
12.01.2017 17:02Методы принуждения на ваше усмотрение, просто рекомендации с благими намерениями. Коллеге достался проект, думал разберется в коде предшественника, где, по словам начальства, отличный алгоритм. А в итоге оказалось, что все работало на чистом слове. А время потеряно.
В Украине. Работы достаточно, дефицит специалистов и все такое.
За опечатки каюсь, поправила, благодарю.
AnotherReality
12.01.2017 16:58Спасибо, поправила. Много раз вычитываешь и все равно что-то не замечаешь. Каюсь
NikitaKhvoryk
12.01.2017 14:45Я думаю, что вы измените своё мнение относительно простоты изготовления корпуса, когда посмотрите цены на пресс-формы и их изготовление. Если корпус покупной, то вы правы. Но устройство в покупном корпусе не продаст себя само. А если делать устройство не для продаж, то есть ли смысл его делать вообще?
Надо понимать, что один ваш неверный шаг создаст проблем другим, кто идёт после вас в цепочке. Тем же конструкторам корпуса. Оснастку переделай, пресс-формы переделай, инструмент поменяй, и т.д. Для этого и сделаны CAD программы, чтобы заранее находить проблемные моменты и несовпадения интересов.
AnotherReality
12.01.2017 17:06Я не утверждаю, что это всегда просто, абсолютно все зависит от содержимого проекта. Для тех же релюшек покупают готовые корпуса и они продаются. Электроника бывает разная. Для промежуточного этапа устройства порой тоже нужен корпус. Но зачем делать пресс-форму, если количество небольшое и от него требуют не красочности, а функциональности?
VT100
12.01.2017 23:58+1Соглашусь в тем, что оригинальный корпус (оснастка, материалы, подрядчик или собственное производство) если и не перевесит «схема+плата+ПО», то, по крайней мере, составит им существенную конкуренцию.
semimaks
12.01.2017 14:17Прочитал с удовольствием, спасибо за интересное изложение и охват обширной и сложной темы! Буду ждать новых публикаций.
hardegor
12.01.2017 16:14Все примерно так, только вы смешали разные процессы — разработка, подготовка к производству и само производство. В общем-то ГОСТ еще с советских времен описывают всю цепочку. Если разработка еще туда-сюда можно и не сильно соблюдать, то подготовка к производству и производство настоятельно рекомендуется вести по ГОСТ, потому что там предусмотрен обход максимального количество «подводных камней» и просто минимизирует издержки производства в дальнейшем. Тот, кто поучаствовал в полном цикле начинает понимать — этих «камней» там гигантское количество. И написать по этой теме можно еще десятка два статей.
Да, я так понимаю ваш опыт ограничивает малой серий, сотня-другая штук.
Кстати, вы забыли еще два важнейших этапа производства — контроль(ОТК) и упаковка.AnotherReality
12.01.2017 22:14Все примерно так, только вы смешали разные процессы — разработка, подготовка к производству и само производство
Я постаралась описать процессы относящиеся к железной части поскольку в университетах с этим не знакомят и много людей не представляет себе в принципе эту «карту сокровищ».
В общем-то ГОСТ еще с советских времен описывают всю цепочку
ГОСТ вещь своеобразная и не всегда и не ко всему применима. Был опыт написания стандарта работы предприятия поскольку ГОСТ в большинстве своем многое усложнял. В том числе и шаблоны использовали свои.
Почитала ГОСТ 15 (может не тот?), но конкретики мало. Всегда проще, когда кто-то обычными словами поясняет.
Да, я так понимаю ваш опыт ограничивает малой серий, сотня-другая штук
В общем то да, но в недалеком будущем будет масштабирование производства, но перед этим нужно еще пару макетов (макетов много не бывает :D).
Кстати, вы забыли еще два важнейших этапа производства — контроль(ОТК) и упаковка
А мы же не обсуждаем готовый продукт для продажи. Это некое абстрактное железо на невесомой спице в вакууме. Хотя вот процесс контроля меня саму немного беспокоит, но с этим нужно на тостер сходить.hardegor
13.01.2017 08:54Был опыт написания стандарта работы предприятия поскольку ГОСТ в большинстве своем многое усложнял.
Усложнение потом окупается многократно. Я сам когда-то сопротивлялся и не понимал, но когда сопровождал настоящее производство, понял — лучше перебдеть, чем недобдеть :)
В общем случае, какими-то можно пренебречь, главное понимать.
разработка ГОСТ 2.103, производство ГОСТ 14, 15
Хотя вот процесс контроля меня саму немного беспокоит
Однако, этот вопрос один из важнейших — проверить создало ли производство то, что вы от него ожидали?
А что вы ожидали? Какие параметры определяют, что изделие работоспособно, какие необходимо контролировать и в каких условиях? и т.д. Для этого на изделие пишутся ТУ(технические условия) по ГОСТ 2.114
Да и в процессе производства необходимо контролировать, там уже ОТК и еще какой-то ГОСТ :)
R6MF49T2
12.01.2017 16:45И всё же на предприятиях разного уровня по разному реализован процесс разработки.
Из моей практики, больше всего времени отнимает составление технического облика изделия (исследовательская работа, проработка различных вариантов решения задачи, защита проекта, согласование с заказчиком) и написание встроенного по (зачастую 80% времени до отгрузки, и потом столько же на стыковку/доработку/устранение ошибок). Ну и не затронуто ОТК, испытания (климатика/вибрации и удары/плесневые грибы и так далее), сдача военпреду если надо, упаковка.AnotherReality
12.01.2017 16:55От «идет до железа», не до устройства, которое идет в применение/продажу, потому что там действительно уже много промежуточных вариантов. У меня пока только опыт бытовой электроники и мед. электроники.
user343
12.01.2017 17:56+1Интересно было бы почитать о тонкостях расположения силовых цепей рядом с сигнальными.
Какими пакетами программ пользоваться?
Не для СВЧ, а чтоб допустим получить точность АЦП 12-14 бит в полосе до 30 кГц рядом с контурами импульсных токов под 100А.
Некоторые разработчики ультразвуковых усилителей мощности по долям пФ подгоняли ёмкости пар проводников относительно друг друга, земли и источников помех. Но на макете, ползая по нему вручную с осциллографом.
Можно ли такое заранее смоделировать, без вдыхания паров припоя?v777779
18.01.2017 00:37+1Не там тонкостей, все просто. Любые цепи создают обратные токи по GND, токи протекают по назначению через импеданс, в разные стороны через емкость диэлектрика.
Чтобы ток не попал куда не нужно, надо просто усложнить ему жизнь. Для чего снижается импеданс GND и снижается емкость диэлектрика. Импеданс как известно снижается когда поперечное сечение меди большое, а расстояние малое. Емкость снижается когда расстояние большое. ВСЕ.
Чтобы рассчитать наводки по спектру нужен именно пакет СВЧ, любой, например MWO или CST.
Эти пакеты позволяют в 3D рассчитать нужные Вам параметры, а без 3D тут не обойтись.
Смоделировать можно, но ооччень долго будете считать, и еще дольше выставлять setup на это дело.
Ведь получить результаты несложно, сложно убедиться что это валидные результаты.
А для этого делается несколько проверочных тестов и много итераций.
И каждая считается довольно долго.
VDG
12.01.2017 17:57+1Ощущение, что слово «цикл» стали употреблять на автомате, не понимая его значения. Цикл на то и цикл, что подразумевает итерации в процессе разработки, а не линейное перечисление этапов. В этом особенная сложность хардварного проекта.
AnotherReality
12.01.2017 21:55Ммм, но разве в процессе разработки устройства эти «линейные этапы» не повторяются? И внутри тоже, от схемы к элементной базе нужно возвращаться, от платы к схеме, на этапе заказа комплектующих приходится возвращаться или на этапе подгонки под корпус, все очень динамично. Или как тогда логичнее назвать?
LampTester
17.01.2017 23:44Все примерно так и есть, как написано, за исключением одного: разделение проектирования схемы, трассировки PCB, а также (при наличии программируемой элементной базы) программирования HAL на разных людей я считаю крайне порочной практикой, которая снижает эффективность разработки, затягивает время и порождает бюрократию. Дело в том, что эти этапы очень тесно связаны, и для достижения наилучшего результата выполнять их должен один человек, который держит в голове картину целиком, и потому способен производить перекрестные оптимизации в проекте.
Это не мои праздные измышления — я сам разработчик (по вашей классификации — эмбеддер), причем я работал как в компании, которая исповедовала предельное разделение труда, так и в компании, в которой мне предоставляли возможность делать все перечисленные этапы (схемотехника, PCB, HAL) самому — второе для меня гораздо удобнее (собственно, во второй компании я работаю по сей день, прошедшее время — только для красоты предложения).
Будучи единоличным автором схемы и платы, я могу править и то, и другое параллельно. Вижу, что для оптимизации платы требуется изменение в схеме? Сразу правлю схему. Нашел ошибку в схеме, надо поправить плату? Сразу правлю плату. В процессе трассировки выяснилось, что компонент не влезает по геометрии, и надо поменять его? Сразу правлю схему и плату. Это как минимум быстрее, потому что не предполагает никаких занимающих время объяснений и согласований с кем-то еще. Кроме того, чем меньше людей вносило изменения в проект — тем меньше потенциально будет внесено ошибок.
С программистом HAL та же история. Либо это должен быть человек с неплохими знаниями схемотехники (а тогда почему бы ему не проектировать схему самому?), либо разработчик будет вынужден долго и в деталях пояснять, как и каким образом нужно инициализировать оборудование.
Если устройство сложное, лучше разделить его на законченные модули (схема + плата + прошивка), и уже эти модули распределить для разработки между разными людьми.
Так что я бы скорректировал набор специалистов до такого:
1. Разработчик аппаратной части: схема, плата, ПО нижнего уровня.
2. Программист (опционально, если необходимо): прикладной софт (например, под тот же Android).
3. Конструктор механической части: корпус, сборочные чертежи.
4. Менеджер проекта (опционально, если необходимо): беготня с бумажками.
Это в предположении использования контрактного производства.AnotherReality
18.01.2017 00:25Приветствую. Очень интересно почитать про чужой опыт. В принципе, можно с вами согласиться, это логично все звучит. Если конструктора ПП не очень образованы в электронике, то это действительно может усложнять процесс. НО это все таки применимо в случае, если человек во всех трех направлениях разбирается и если у него есть время.
Например, я работала на фирме только в качестве трассировщика и инженера по документации. У начальника КБ бывали сильные авралы, схему всего немного нужно модернизировать, но времени на перетрассировку нет. Он мог просто распечатать старую, указать что и как поменять, а потом уже просто проверял все ли верно. Равно так же, как был эмбеддер, но он просто разрывался в проекте, потому что много нужно было сделать, а он не успевал по срокам (и то нужно сделать, и это), а на том этапе уже заняло бы много времени вводить в курс нового человека. А если с разработчиком что-то случилось? Весь проект стал мертвым камнем.
Или, например, человек знает схемотехнику, программирование, но посредственный трассировщик, пока он разберется могут поплыть сроки. Кроме того, пока кто-то занимается проектированием, уже можно заниматься программой и алгоритмом, изучением предметной области (если это важно).
Если разделять задачи по компетенциям — это ведет к достижению высокого уровня в своих областях. Но естественно, порой бывает, когда специалисты перестают друг друга понимать и не могут найти точки соприкосновения (особенно, когда говорят об одном и том же, но разными терминами). В этом случае поможет человек, который разбирается в этих всех областях, даже если и не так хорошо — обычно это и есть ведущий проекта, он видит весь проект целиком.
В принципе не сталкивалась с проблемами коммуникации при раздельном проектировании (почти как раздельное питание :D). Некоторые САПР даже имеют специальные для этого функции (контроль версий и жизненного цикла проекта, возможность комментировать прям в проекте).
Очень любопытное обсуждение в тему
D_dMer
17.01.2017 23:44Подскажите пожалуйста, на каком этапе необходимо производить анализ на наличие патентов и их нарушение при производстве изделий?
Если позволите, у меня есть идея сделать аппарат для считывания ЭКГ, ведь здесь запатентовано может быть, что угодно, от самой идеи снимать потенциалы сердца, до наличия на корпусе розовой кнопочки в верхнем правом углу. Приходилось ли сталкиваться с такой проблемой?AnotherReality
18.01.2017 00:36Добрый вечер. Анализ патентов проводится на этапе идеи. Но стоит все таки немного разбираться в видах патентов. Если, например, патент зарегистрирован в каком-то Зимбабве, то Китайцы могут смело передрать все до последней пылинки, потому что патент страны распространяется только на страну. Международные патенты очень дорогие. Патенты на идеи не оформляют.
Устройств ЭКГ безусловно много, если ваш отличается методом обработки или получения сигналов, то этого достаточно, чтобы оформить патент. Иногда патенты вообще оформляют на всякую чушь, главное уметь правильно составить, так называемую, патентную формулу (есть целые учебники, где это объясняется).
Что касается медицинского оборудования, то Вам так же стоит понимать, что сертификация (для мед оборудования она, по-моему, обязательна) очень долгий и трудоемкий процесс. Собственно и разработка мед оборудования требует больших вложений финансовых и временных.
v777779
18.01.2017 04:10Статья содержит много неоднозначных моментов.
Предлагаю автору почитать статьи по разработке элетроники, здесь, от компании Promwad.
Да, они говорят по существу не много, но то, что они все таки раскрывают, сделано очень профессионально.
R_V_A
18.01.2017 15:49Спасибо за статью. Познавательно.
Но учитывая примечание №1, не плохо было бы дать определение сокращению ПП в начале статьи.
vehar
Хоть не назвал бы себя новичком, но прочитал с удовольствием, прям жиза!
Можно ещё добавить про «технический долг» и его последствия, особенно в контексте стартапа
AnotherReality
Про технический долг вроде была статья, хотя под этим термином, насколько я понимаю, подразумевают два процесса: взятие кредита для разработки «железной» части или о плохой продуманности системы.
Вот была ситуация, когда коллега поправил номинал резистора вручную (только value, а component name и marking оставил без изменений), хотя 100500 раз просила так не делать, лучше оставить пометку или полностью заменить компонент. Но нет. В итоге закупили резисторов не того номинала и хорошо, что случайно в который раз решила проверить перечень, что все куплено и уже в пути. А если другой резистор, так еще и монтажную документацию менять. Сплошная боль. Но это, наверное, самый страшный мой «технический долг» на данный момент.
И спасибо =)