Позднее выявление механических ограничений — распространенная причина срыва сроков и переделок в проектах по разработке электроники.
Рассмотрим типичный сценарий: через три месяца после начала разработки схема завершена, а трассировка PCB в основном закончена. И только тогда заказчик упоминает, что вторая PCB устанавливается на несколько миллиметров выше основной платы — деталь, которая, как он полагал, была очевидна по ранее отправленным фотографиям. К этому моменту ранее выбранные разъемы и компоненты оказываются слишком высокими, что вынуждает заново подбирать детали, которые и без того трудно найти из-за требований по напряжению и току. Несколько недель работы теряются на устранение ограничения, которое так и не было формально зафиксировано.
Такой тип проблем вовсе не редкость. Это предсказуемый результат разрозненных процессов проектирования.
Во многих командах по разработке аппаратуры процесс проектирования распределен между несколькими несвязанными инструментами. Определения стеков контактных площадок могут храниться в одном приложении. Условные графические обозначения для схем и библиотеки управляются в отдельном инструменте и часто хранятся в разных локальных или сетевых папках. Трассировка PCB выполняется в другом месте. Системная интеграция, анализ целостности сигналов и EMI обычно выполняются в дополнительных специализированных приложениях. Отслеживание проектов и управление задачами часто реализованы через веб-инструменты и не всегда доступны, когда инженеры работают офлайн.
В результате инженерам приходится осваивать и поддерживать навыки работы как минимум с пятью различными инструментами только для того, чтобы пройти путь от схемы до пригодной к производству PCB.
В небольших командах такая фрагментация создает дополнительную нагрузку. Переход между инструментами требует частого экспорта и импорта файлов, а на каждом этапе возникает риск ошибок преобразования. Библиотеки и посадочные места должны находиться в строго определенных структурах каталогов, чтобы оставаться пригодными к использованию; неправильно размещенный файл может помешать корректной передаче компонента из схемы в трассировку.
Значительное время уходит на поиск условных обозначений схемы, посадочных мест PCB и правильных версий файлов — работы, которая должна быть тривиальной, но на практике нередко отнимает дни или недели в течение проекта.
Несмотря на количество задействованных инструментов, итоговая координация по-прежнему опирается на электронную почту и таблицы. Сами инструменты в значительной степени остаются разрозненными, почти не обеспечивая общей прозрачности по всему процессу проектирования.
Интегрированная среда проектирования электроники — это одно приложение или тесно связанный набор инструментов, поддерживающий полный цикл разработки аппаратуры:
В интегрированной среде одни и те же базовые данные используются на всех этапах проектирования. Изменения, внесенные в схему, напрямую передаются в трассировку PCB. Механические ограничения, такие как контуры платы или зазоры корпуса, видны в электротехнической среде проектирования по мере их обновления.
Это устраняет необходимость в ручном экспорте, импорте файлов и несоответствиях версий, которые типичны для цепочек инструментов, построенных вокруг несвязанных приложений.
Вот распространенный сценарий в проекте силовой электроники. Трассировка PCB создается в одном инструменте, схема — в другом, а корпус отдельно проектируется механическим инженером в PTC Creo. Ни одна из этих сред не использует общие актуальные проектные данные.
В этом случае корпус едва вмещал PCB, а кабельные сборки нарушали требования по расстояниям. Эти проблемы сами по себе не были ошибками проектирования. Они возникли потому, что ни одна среда не давала полной видимости механического и электрического контекста. Для устранения конфликтов потребовалось несколько циклов согласования между электротехнической и механической командами, что добавило к графику две-три недели.
Когда инструменты ECAD и MCAD интегрированы, этот контур обратной связи замыкается. Механический инженер задает контур платы и ограничения непосредственно из модели корпуса, и эти ограничения передаются в трассировку PCB. Инженер-электронщик сразу видит доступную площадь платы, подтвержденные положения монтажных отверстий и ограничения по высоте компонентов еще до окончательного выбора деталей или принятия решений по разводке.
Такая двунаправленная синхронизация сокращает число итераций, предотвращает конфликты на поздних стадиях и уменьшает общую длительность цикла проектирования.
Переходные отверстия обратного пути, нарушения зазоров и ошибки расстояний, связанных с технологичностью изготовления или сборки, — частые причины переделок PCB и повторных выпусков. Такие проблемы часто остаются незамеченными, если правила проектирования проверяются только после завершения трассировки.
Проверка правил проектирования в реальном времени выявляет нарушения в момент их появления. Если нарушено ограничение по зазору, это сразу становится видно. Если ширина проводника не соответствует требованиям назначенного ему класса цепей, ошибка непосредственно подсвечивается в трассировке.
Этот подход отличается от пакетной проверки правил проектирования, которая выявляет проблемы только после завершения проектных работ. Пакетные проверки обнаруживают ошибки, которые могли быть внесены часами или днями ранее. Проверка в реальном времени не дает таким ошибкам распространяться дальше, обеспечивая соблюдение ограничений прямо в процессе трассировки.
Фраза «Наша текущая цепочка инструментов работает нормально» часто означает, что процесс хрупок.
В одном проекте программное обеспечение для создания схем использовалось для проектирования кабелей и жгутов. Технически это было возможно, но инструмент не был предназначен для такой задачи. В результате электрические изменения не передавались автоматически в чертежи, и каждую метку и текстовое поле приходилось обновлять вручную.
Это приводило к предсказуемым сбоям. Несколько кабельных сборок были изготовлены с неправильной разводкой, потому что документация не соответствовала фактическому проекту. Инженеры тратили значительное время на просмотр, повторную проверку и исправление ошибок, которые сам инструмент должен был предотвращать. Индивидуальная производительность, по оценке, падала до 40–50% из-за постоянных накладных расходов на ручные обновления и проверку.
Система функционировала, но лишь в том смысле, что не выходила из строя немедленно. Реальная цена этого «нормально» выражалась в переделках, задержках и снижении инженерной производительности.
В одном недавнем проекте разработка основной PCB была завершена, спецификация материалов утверждена, и проект был готов к передаче в производство.
В этот момент возникло новое ограничение: поверх основной платы должна была устанавливаться дополнительная LED-плата, при этом вертикальный зазор составлял всего 10 мм.
Это поздно появившееся требование вынудило переработать затронутую область. Существующие разъемы превышали допустимую высоту. Компоненты с достаточной токовой нагрузочной способностью не были доступны в низкопрофильных корпусах. Альтернативные детали, соответствовавшие ограничению по высоте, имели непрактичные минимальные объемы заказа или уже были сняты с производства.
На оценку альтернатив ушло примерно четыре недели, что привело к дополнительным консультационным расходам в размере $2,000 (примерно 10% общего бюджета проекта), и все это лишь для того, чтобы установить, что исходный подход к проектированию нежизнеспособен.
Ситуацию усугубили остановки производства из-за празднования Китайского Нового года, что задержало изготовление. Платы, которые должны были быть отгружены в октябре или ноябре, были поставлены только в марте.
Коренной причиной была не техническая ошибка, а сбой процесса. Механические ограничения не были доведены до команды в начале проекта, и не существовало общей среды, в которой электротехническая, механическая команды и команда прошивки могли бы на раннем этапе цикла проектирования видеть и проверять требования системного уровня.
Программные системы часто могут выдерживать частичный отказ. Если одна функция ломается, другие части приложения могут продолжать работать, позволяя устранять проблемы постепенно.
Аппаратные системы так не работают.
Если архитектура питания неверна, если преобразователи уровней применены неправильно или если базовые интерфейсы не работают, большие части платы не будут функционировать, либо система вообще не включится. Аппаратуре требуется высокая степень корректности во всех подсистемах еще до того, как можно будет начать осмысленное тестирование.
Поскольку аппаратная часть по своей природе интегрирована, процесс разработки тоже должен быть интегрированным. Требования не могут существовать только в цепочках писем. Правила проектирования нельзя проверять только в конце процесса трассировки. Механические ограничения нельзя обнаруживать через месяцы после начала разработки без неизбежных переделок и задержек.
Инструменты проектирования должны отражать эту реальность. Электрические, механические данные и данные о компонентах должны быть связаны, видимы и доступны на протяжении всего цикла проектирования, а не управляться как разрозненные файлы и передачи между командами.
Для команд, готовых уйти от разрозненной цепочки инструментов, Altium Develop — хорошая отправная точка.
Независимо от того, нужно ли вам создавать надежную силовую электронику или сложные цифровые системы, Altium Develop объединяет все дисциплины в единую совместную силу. Без изолированных процессов. Без ограничений. Это место, где инженеры, разработчики и новаторы работают как единое целое, совместно создавая решения без барьеров. Оцените возможности Altium Develop уже сегодня!
Интегрированная среда проектирования объединяет создание схем, трассировку PCB, моделирование, совместную работу ECAD-MCAD и управление данными в единый связанный процесс. Вместо перемещения файлов между отдельными инструментами инженеры работают с общими данными, поэтому изменения автоматически распространяются между этапами проектирования.
За счет проверки электрических, механических и производственных ограничений в реальном времени такие проблемы, как нарушения зазоров, ограничения по высоте компонентов или конфликты трассировки, выявляются в момент их возникновения, а не спустя недели. Это предотвращает переработки на поздних стадиях, которые обычно приводят к срыву сроков и росту затрат.
Механические ограничения, такие как геометрия корпуса, стек платы и выравнивание разъемов, напрямую влияют на выбор компонентов и решения по компоновке. Когда эти ограничения видны с самого начала, команды избегают выбора деталей или архитектур, которые позже оказываются нереализуемыми.
Проверка в реальном времени немедленно сигнализирует об ошибках при нарушении правила, позволяя инженерам устранять проблемы до того, как они распространятся дальше. Пакетные проверки выявляют проблемы только после завершения трассировки, что часто требует значительного отката и доработки.