Как расставить приоритеты для изменений в конструкции печатной платы после тестирования

Отчеты по прототипам возвращаются, и представление о том, что уже готово, меняется. Одна плата перезагружается под нагрузкой. Разъем, который в CAD выглядел нормально, при сборке не обеспечивает надежную стыковку. Кабель не удается проложить внутри корпуса без натяжения. У одного компонента в BOM срок поставки составляет 26 недель. Трассировка завершена, но система не готова к сборке. Что дальше? 

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

Цель — превратить результаты испытаний в сфокусированный набор изменений, который продвинет следующую сборку вперед.

Ключевые выводы

• Тестирование прототипа выявляет смесь отказов, рисков и доработок. Команды работают быстрее, когда распределяют их по понятным приоритетам, связанным с рисками сборки и готовностью к релизу.
• Хорошая приоритизация связывает результаты испытаний с требованиями, объектами проекта, снабжением и технологичностью производства еще до внесения каких-либо изменений.
• Изменение в проекте готово тогда, когда оно проверено во всех затрагиваемых областях, поскольку исправления, устраняющие проблему в одной области, могут вызвать новые проблемы в другой.

Начните с разделения отказов, рисков и доработок

Обратная связь после тестирования становится управляемой, если распределить ее по четким категориям:

• Отказы: Проблемы, нарушающие функциональность или не соответствующие требованиям
• Риски: Проблемы, угрожающие технологичности, снабжению, надежности или сборке
• Доработки: Улучшения, повышающие запас по параметрам, удобство использования или производительность

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

Структурированные проверки проекта — подходящее место, чтобы формализовать такую сортировку и назначить ответственных. Рекомендации по их эффективному проведению см. в 6 Areas Your PCB Design Reviews Should Focus On.

Ранжируйте изменения по риску для сборки и влиянию

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

I. Обязательно исправить до следующей сборки

Проблемы, блокирующие функциональность, безопасность или соответствие требованиям, например:

• Шина питания, на которой происходит просадка напряжения под нагрузкой
• Интерфейс связи, работающий с периодическими сбоями
• Нарушение требований по путям утечки
• Разъем, который невозможно корректно состыковать при сборке

II. Желательно исправить, если позволяет график

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

• Пограничная целостность сигнала на высокоскоростной линии
• Ограниченный тепловой запас при пиковой нагрузке
• Тестовая точка, к которой сложно подвести щуп
• Компонент со статусом жизненного цикла, указывающим на снижение доступности

III. Отложить с пониманием риска

Проблемы, которые команда понимает и принимает для данной сборки, имея документированный план вернуться к ним позже:

• Незначительные опасения по запасу EMI в пределах допустимого
• Обходное решение, приемлемое для малых объемов, но не для масштабирования
• Оптимизации трассировки с ограниченным влиянием на систему

IV. Отслеживать как будущее улучшение

Доработки, повышающие удобство использования, обслуживания или запас по параметрам без влияния на текущую сборку:

• Более понятная маркировка или документация
• Оптимизированная тепловая компоновка
• Упрощенная консолидация BOM
• Дополнительные диагностические функции

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

Риски снабжения заслуживают отдельного внимания. Компонент, который работал в прототипе, может задержать следующую сборку, если изменились доступность, статус жизненного цикла или срок поставки. Тестирование прототипов редко выявляет такие риски, но это делает анализ цепочки поставок. Подробнее см. Why You Need a PCB Supply Chain Review.

Проверяйте изменения во всех затрагиваемых областях

Изменение в проекте считается готовым, когда оно проверено во всех областях, на которые влияет. 

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

• Электрическая часть: Соответствует ли новая сеть развязки целевому импедансу во всем нужном диапазоне частот? Моделирование целостности питания подтверждает исправление и проверяет, не возник ли новый резонанс. Также нужно оценить тепловое поведение, поскольку повышенный переходный ток теперь протекает по другому пути. 

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

• Производство: Добавленные компоненты влияют на зазоры при сборке, доступ к тестовым точкам и видимость для инспекции. Если новое размещение перекрывает точку для щупа или скрывает репер, то вместе с трассировкой нужно обновить план тестирования и проверки DFM.

• Снабжение: Любые новые или замененные компоненты могут отличаться от исходных по доступности, статусу жизненного цикла или сроку поставки. Изменение, прошедшее инженерные проверки, все равно может задержать сборку, если сами компоненты сложно получить к моменту готовности производства.

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

Для многоплатных изделий такие междисциплинарные проверки становятся все более взаимозависимыми. Изменение на одной плате может повлиять на разъемы, кабельные сборки и посадку в корпусе по всей системе. Подробнее об управлении такими взаимодействиями см. в Deliver Production-Ready Multiboard PCBs Faster with Manufacturing-Driven Design.

Изменение, прошедшее все релевантные проверки, готово. Изменение, которое устраняет симптом в одной области, но создает новый риск в другой, — нет. Этап валидации отделяет реальное исправление от такого, которое устраняет текущий отказ на испытаниях, но незаметно закладывает основу для следующего.

Сохраняйте связь изменений с проектом

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

Чтобы уменьшить неоднозначность, связывайте обратную связь напрямую с проектом: 

• Комментируйте конкретные компоненты, цепи или области трассировки
• Связывайте проблемы с результатами испытаний и требованиями
• Обеспечивайте прозрачность того, кто отвечает за каждое изменение

Переносите утвержденные изменения в чистый релиз

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

Готовый к сборке релиз для следующего прототипа включает:

• Обновленные схему и трассировку, отражающие все утвержденные изменения
• Проверенные данные BOM и снабжения, включая любые альтернативы, добавленные после тестирования
• Согласованные документацию и процедуры тестирования
• Актуальные выходные данные для изготовления и сборки, сформированные из последнего состояния проекта

При таком подходе производство получает полный и точный комплект данных, а следующий цикл испытаний начинается с чистой базовой точки.

Превратите результаты испытаний в правильную следующую сборку

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

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