Как разработать электронное устройство по принципам DFM



    DFM (design for manufacturing) — это принципы разработки, которые нацелены на успешное производство готового изделия. Казалось бы, проектирование любого электронного устройства должно проходить с учетом производственных возможностей, однако на практике это не всегда так. Начинающая команда разработчиков может получить на выходе устройство, которое становится источником самых разных проблем на этапе производства, вплоть до невозможности его изготовить на базе доступных технологий. Какие вопросы нужно решить в процессе проектирования электроники, чтобы сократить риски на финальном этапе проекта? Мы ответим на этот вопрос в данной статье.

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

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

    Этап №1. Сбор информации о технологиях производства


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

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

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

    Итак, все параметры устройства определены, производитель найден, разработчик выбран.

    Этап №2. Расчет и согласование себестоимости устройства


    На втором этапе необходимо рассчитать себестоимость изделия, в которую входят затраты на следующие элементы:

    1. Электронные компоненты (стандартные и специально разрабатываемые)
    2. Все материалы.
    3. Разработка (работа инженеров, дизайнеров, менеджеров и др.).
    4. Производство.
    5. Сборка.
    6. Накладные расходы.

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

    Этап №3. Старт разработки устройства


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

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

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

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

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

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

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

    Этап №4. Моделирование и постановка на производство


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

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

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

    Спасибо за внимание! Более подробно об проектировании новых устройств можно почитать на сайте команды Promwad в разделе «Этапы разработки электроники».
    • +18
    • 19.8k
    • 9
    Promwad
    32.22
    Контрактная разработка и производство электроники
    Share post

    Comments 9

      0
      Было бы очень здорово привести примеры конкретных требований для «классических» типов производства влияющих на процесс разработки. Или рассказать о своих граблях.
        0
        Нельзя закладывать в устройства позиции не имеющие аналогов или уже не закупленные в нужном количестве(в рамках серийного производства) Иногда бывает что достать 5-100 шт. элемента легко, а когда дело идет о серии 1000 шт. и более сроки поставки становятся от 8 недель…

        Из опыта скажу, как только разработчик ПП сделал BOM (перечень элементов) — то по этому перечню обязательно нужно проверить возможность закупки на серию, и за частую после таковой проверки в ПП вноситься изменения — возможность установки 2 типов элементов (SMD / DIP элементы) или 2 типоразмеров. (к примеру конденсаторы)
          +2
          Я не очень понимаю, что такое «классический» тип производства. А вот о граблях – это пожалуйста.

          1. Самая первая моя разработка. Я не сделал отступ меди от контура платы. Даже не думал, что это надо делать. На производстве контур фрезеровался. При проходе фрезы по контуру образовалась «медная шуба». И даже в нескольких местах образовались КЗ. Вот так незнание технологий производства привело к не работоспособной плате. Кстати, такие глупые ошибки встречаются постоянно. И, как это ни странно, не только у начинающих разработчиков.

          2. Более сложный пример. Разрабатывали сложное устройство. В частности корпус (речь пойдет о нем). По дизайну выходные разъемы устройства располагались по трем сторонам. К моменту разработки уже был накоплен достаточно большой опыт и была сильная команда разработчиков. Когда печатная плата и корпус были спроектированы, мы стали проводить моделирование на собираемость (компьютерное). По результатам редактировали модели деталей корпуса, пока на модели все стало «хорошо собираться». Получив хорошие результаты моделирования, мы сразу отдали устройство на производство. Выпустили пресс-форму (корпус должен был отливаться). Получили готовые детали. И при «живой сборке» не смогли ничего сделать. Там мешало какое-то маленькое ребро жесткости. Этого не заметили на моделировании. Пришлось дорабатывать пресс-форму, избавляться от брака – а ведь это очень дорого. Вот если бы до этапа производства мы отдали наши модели на выращивание и проверили все «вживую», то избежали бы потерь как по времени, так и финансовых.
            0
            1. Как САПР это допустил? Даже простейший Eagle в DRC по дефолту имеет ненулевое значение отступа от Miling слоев.
          +1
          Выглядит как текст для робота. Ключевых слов много, смысла нет.
            +1
            Уважаемый Amarao, предположу, что Вы ошиблись веткой или далеки от темы разработки и последующего производства, раз не увидели смысла. Возможно, Вы эксперт в отрасли, в таком случае, буду рад, если поделитесь своей практикой.
              +1
              На самом деле, для тех, кто работает в теме разработки и последующего производства — сабж капитанский :) Подойдет для чтения свежеиспеченным руководителям проектов, хотя тут опять же очень мало конкретики(такой, как в вашем комменте выше). Обычно ведущий инженер разработки всегда держит в голове мысль «надо ничего не забыть и предусмотреть все, что возможно», однако на практике о чем-то он не знает, о чем-то забывает в запаре. И хотя в конечном итоге все фиксится перед постановкой на серию(если сроки не поджимают), но сроки разработки увеличиваются.

              А еще очень важна вовлеченность сотрудников в процесс. Например, топологу ПП зачастую «влом» добиваться идеальной разводки — формально все ок, ну и пошел домой в 18.00. Тогда ведущий садится и думает, что и как разводить, используя затем тополога как интерфейс к cad'у. Аналогично и с моделированием — работник сделал, все ок. А проверять все равно ведущему. И у него голова будет болеть о всех недочетах, тогда как сотруднику условно — все равно. Ну допустил ошибку, с кем не бывает.

              Ну а если кратко, то ваш пост можно заменить немножко подправленной вашей же фразой:
              «Быстрое решение руководителем проекта всех возникающих в ходе проектирования вопросов — это один из основополагающих факторов, которые способствуют успешному завершению всего проекта.»
                0
                Я так понимаю, «капитанский» значит очевидный? В принципе любая тема, в которой разобрался – «капитанская» :). Вот только мне присылают на проверку много проектов, и на эти проекты «больно смотреть». И разработчики этих проектов совсем не начинающие, а очень даже опытные. Собственно стимулом для написания этой статьи стали 2 проекта, которые попали ко мне одновременно. Если вкратце: в одном из них был совершенно не оптимизированный BOM, во втором – какая-то невообразимо сложная структура ПП. Оба эти проекта мне принесли с вопросом: «Почему так дорого? И почему мы не можем это произвести?». Ну очевидно же…

                Руководитель проекта – очень важная и ответственная работа, и область ответственности там намного шире, чем просто следить за разработчиками. Действительно, очень часто руководитель проекта, по сути, является разработчиком, а разработчики, как Вы удачно выразились, только интерфейсы к CAD’ам. И это, на мой взгляд, не совсем правильно. Намного лучше организовать процесс разработки так, чтоб каждый ее участник отвечал за свою часть работ.

                Вопрос мотивации сотрудников – один из самых сложных и его надо решать. Я не видел, чтобы его «пристегивали» к принципам DFM. Разве что косвенно, при расчете себестоимости. Но идея интересная. Ведь качественно выполнить работу может только тот специалист, который хочет ее выполнить.

                Про конкретику. Мне тоже очень хотелось бы получить универсальный набор правил. Выполнил все по пунктам – получил хорошее изделие. Но такого набора нет. И не может быть в принципе. Очень много переменных: разные задачи, разные инструменты, разные пути реализации, разное количество специалистов и т. д. Вопросов слишком много. Поэтому придумали принципы DFM. Принципы. Не правила!
            0
            DFM правила обычно используются при разработке топологии
            интегральных схем. Выглядит это примерно так:
            минимальное расстояние между проводниками равно, например, 40 нанометров,
            рекомемендуемое расстояние — 60.

            Only users with full accounts can post comments. Log in, please.