Boundary Scan, Flying Probe и функциональное тестирование: выбор перед релизом PCBA

• Рассматривайте выбор метода в первую очередь как решение об электрическом доступе. Плата должна определить, что именно должна доказать следующая сборка, прежде чем обращаться к терминологии boundary scan, flying probe или FCT.
• Разделяйте boundary scan / JTAG, flying probe, ICT на базе тестовых адаптеров (fixtures) и функциональное тестирование под напряжением (powered functional test). Они решают разные задачи и не должны сваливаться в одну общую корзину тестирования.
• Используйте полноту пакета данных как пороговое правило. Файлы для производства (Fabrication files) важны, но сами по себе они недостаточны для выбора маршрута тестового доступа к собранной плате.
• Привязывайте boundary scan исключительно к плотному цифровому тестовому доступу и планированию межсоединений. Это не доказывает качество высокоскоростных каналов, радиочастотные характеристики (RF) или общую готовность продукта.
• Держите flying probe и FCT в рамках руководства по планированию релиза, а не как рекламные заявления о стоимости или возможностях. На этой странице не публикуются проценты покрытия, расчеты времени цикла, ROI для адаптеров, обещания по срокам или заявления о надежности.

Надежное руководство по электрическому доступу начинается с одного небольшого вопроса: какие именно доказательства нужны следующей сборке? Как только этот вопрос станет ясным, boundary scan, flying probe, планирование адаптеров (fixture planning) и функциональное тестирование под напряжением смогут занять свое правильное место, а не использоваться в качестве общих успокаивающих слов.

Поисковые запросы, связанные с boundary scan, flying probe, ICT и FCT, часто рассматривают все эти фразы так, как будто они относятся к одному типу статей. Это не так. Некоторые вопросы действительно касаются тестового доступа на плотных цифровых сборках. Другие — об электрической проверке без адаптеров (fixture-free) в условиях часто меняющихся сборок (changing builds). Третьи — о том, когда стоит начинать планирование маршрута на базе адаптера. А некоторые касаются функционального подтверждения под напряжением после того, как вопросы электрического доступа уже решены. Это руководство становится полезным только тогда, когда оно сводит этот шум к меньшему решению на уровне отдельной платы.

Это решение звучит не как "какой тест лучше?". Оно звучит как "какое семейство методов ответит на вопрос следующей сборки, не давая завышенных обещаний о том, что оно доказывает?".

Это важно, потому что терминология методов тестирования очень легко смещается. В слабом черновике используется больше аббревиатур, чтобы звучать более полно. В более сильном черновике каждая аббревиатура сужается до тех пор, пока читатель не увидит её реальную задачу. Boundary scan полезен, когда цифровой доступ ограничен, но плате по-прежнему требуется структурированный тестовый доступ, ориентированный на межсоединения. Flying probe полезен, когда плате требуются электрические проверки без использования адаптеров, а стадия проектирования или программы еще не оправдывает специализированное планирование адаптеров (fixture planning). ICT имеет значение здесь как схема сравнения (на базе адаптеров) позади этого выбора, даже если он не является главным методом для текущей сборки. FCT имеет значение, когда поведение под напряжением в заданной конфигурации является основным последующим вопросом. Ни один из этих методов не станет более полезным, если описывать его как универсальное доказательство всего.

Самый безопасный способ организовать эту страницу — вокруг ответственности за релиз (release ownership). Прежде чем плата дойдет до запуска, пакет данных уже должен знать:

• какой тип электрических доказательств нужен следующей сборке
• какие входные данные пакета (package inputs) доступны для поддержки этого метода
• меняется ли еще плата, или она уже достаточно стабилизировалась для более глубокого планирования адаптеров
• делают ли скрытые ограничения доступа или плотные цифровые структуры терминологию boundary-scan релевантной
• требуется ли следующей сборке электрический доступ, ориентированный на дефекты, или подтверждение поведения под напряжением

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

В этом руководстве

1. Что на самом деле решает это руководство по выбору?
2. Как следует разделить Boundary Scan, Flying Probe, ICT и FCT по разным доказательным направлениям?
3. Какие входные данные пакета и условия доступа должны определять выбор метода тестирования?
4. Как передать следующую сборку, не превращая один метод в доказательство всего?
5. Что должно быть включено в контрольный список RFQ для выбора тестирования PCBA?
6. Часто задаваемые вопросы (FAQ)
7. Следующие шаги

Что на самом деле решает это руководство по выбору?

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

Звучит очевидно, но названия методов быстро размывают решение. Boundary scan, flying probe, ICT на базе адаптеров и FCT под напряжением — все они находятся рядом с тестированием и валидацией. Но все они не отвечают на один и тот же вопрос, и полезное руководство должно быть более строгим, чем просто список названий методов.

Самый полезный первый шаг — исключить четыре слишком широких толкования.

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

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

Оно не публикует руководство по экономике тестовых адаптеров. Доступные источники поддерживают позицию "без адаптера" (fixture-free) в сравнении с позицией "на базе адаптера" (fixture-backed), но не публикуют расчеты затрат, модели окупаемости или пороги объемов в качестве публичных заявлений.

Оно не публикует заявлений о целостности сигналов. Boundary scan относится к уровню цифрового тестового доступа и не доказывает качество высокоскоростных каналов, коэффициент битовых ошибок (BER), джиттер, раскрытие глаз-диаграммы (eye opening) или соответствие протоколам.

Как только эти широкие, небезопасные углы будут устранены, вопрос о релизе станет конкретным:

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

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

Boundary scan зависит от намерений проектирования для тестирования (Design-for-Test). Он применяется на плате, когда плотные цифровые сборки, ограниченный физический доступ или планирование доступа на уровне компонентов делают структурированную проверку цифровых межсоединений актуальной. Это вопрос планирования и доступа прежде всего остального.

Flying probe зависит от доступных электрических точек, стадии платы и отсутствия выделенных обязательств по адаптерам. Он наиболее силен, когда проекту все еще требуется электрическая проверка, но стадия проектирования или программы еще не оправдывает отношение к ICT на базе адаптеров как к основному маршруту.

ICT имеет значение здесь, даже если он не является ведущим методом в заголовке. Почему? Потому что выбор flying probe имеет смысл только тогда, когда статья помогает читателю понять схему сравнения. Flying probe — это позиция без адаптера (fixture-free); ICT — это позиция на базе адаптера (fixture-backed). Странице не нужно становиться учебником по ICT, но ей нужен этот контраст, чтобы выбор метода оставался честным.

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

Следовательно, эта страница решает четыре более узких вопроса:

1. Какие доказательства нужны следующей сборке в первую очередь?
2. Какое семейство методов разработано, чтобы ответить на этот вопрос?
3. Какая полнота пакета данных требуется, прежде чем этот метод можно будет ответственно выбрать?
4. Что выбранный метод по-прежнему не доказывает?

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

Матрица решений: Ранние цели методов тестирования

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

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

Как следует разделить Boundary Scan, Flying Probe, ICT и FCT по разным доказательным направлениям?

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

Первое семейство методов — boundary scan, часто называемое JTAG. Здесь правильной является консервативная позиция: boundary scan относится к набору инструментов проектирования для тестирования (DFT) и электрической валидации для плотных цифровых сборок, особенно там, где прямой физический доступ ограничен. Это точное и полезное утверждение. Ему не нужно обещать большего.

Поэтому boundary scan наиболее силен, когда вопрос релиза касается структурированного цифрового доступа:

• может ли собранная плата чисто обеспечить ориентированный на межсоединения цифровой тестовый доступ
• поддерживает ли смесь компонентов и предполагаемое поведение цепи использование терминологии boundary-scan вообще
• является ли плата настолько плотной, что прямое физическое зондирование не дает полного ответа
• понимает ли пакет релиза уже намерения boundary-scan, а не просто упоминает его

Именно поэтому boundary scan следует описывать как уровень доступа, а не как уровень производительности (performance layer). Как только черновик начинает подразумевать, что прохождение JTAG (JTAG pass) или наличие boundary-scan доказывает качество высокоскоростного канала, поведение протокола или полную готовность платы, статья пересекает черту, которую она пересекать не должна.

Второе семейство методов — flying probe (летучие матрицы). Flying probe полезен тем, что он работает без адаптеров (fixture-free), но отсутствие адаптера — это еще не вся суть. Более полезное для планирования утверждение заключается в том, что flying probe подходит для плат, которые все еще нуждаются в электрической проверке (screening), пока дизайн изменяется, объем сборки ниже, или специализированный маршрут на базе адаптера пока не является правильным краткосрочным обязательством.

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

Эта позиция позволяет статье опираться на реальные вопросы релиза:

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

Именно здесь плотные BGA-платы создают ложную уверенность. Команда убирает физические контрольные точки (test points), чтобы сэкономить место на двусторонней плотной сборке, а затем предполагает, что фабрика сможет просто "использовать flying probe" после изготовления. Этот запрос игнорирует физические пределы метода. Flying probe не может добраться до скрытых BGA-соединений или внутренних цепей (nets), которые никогда не были выведены для доступа. Если на этапе трассировки (layout) эти "темные цепи" (dark nets) так и не были включены в используемую цепь boundary-scan или другую продуманную структуру DFT, то после сборки основные межсоединения могут стать электрически нетестируемыми. Тогда дорогая плата с замыканием под BGA может пройти доступные проверки flying-probe, только чтобы затем выйти из строя во время функционального тестирования под напряжением, когда уже было потрачено гораздо больше средств. Вот почему выбор метода тестирования не может ждать, пока плата будет изготовлена. Планирование электрического доступа должно быть заморожено, пока трассировка (layout) еще контролирует, что можно достать, а что нельзя.

Третье семейство методов — ICT, но опять же только в позиции сравнения. Языка ICT нужно лишь столько, чтобы сохранить рамки принятия решений вокруг flying probe. Полезный момент заключается в том, что flying probe не имеет смысла в отрыве от остального. Он становится более понятным, когда читатель понимает, что ICT — это маршрут на базе адаптера, а flying probe — это маршрут без адаптера.

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

Четвертое семейство методов — FCT. Эта категория должна оставаться отдельной, потому что она отвечает на другой вопрос. FCT касается поведения под напряжением при заданной конфигурации (setup). Он может иметь большое значение для программы, но это не то же самое, что решение о том, как будет обеспечиваться электрический доступ для проверок или контроля межсоединений.

Это означает, что FCT входит в статью как последующее (downstream) или смежное семейство методов:

• он становится релевантным, когда следующей сборке требуется подтверждение поведения под напряжением, а не только электрическая проверка, ориентированная на доступ
• он зависит от определенных ожиданий поведения, интерфейсов и логики "прошел/не прошел" (pass/fail)
• он не должен использоваться так, как будто он устраняет необходимость в планировании доступа, проверке на наличие дефектов или полноте пакета данных

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

Используется ли этот метод для объяснения своей собственной роли, или он используется для того, чтобы позаимствовать авторитет у другого метода?

Boundary scan не должен заимствовать авторитет доказательств высокоскоростных характеристик. Flying probe не должен заимствовать авторитет в области надежности. ICT не должен заимствовать экономический авторитет. FCT не должен заимствовать авторитет доступа к узлам (node-access). Если каждый термин остается в рамках своей роли, статья остается и полезной, и защищенной.

Такое разделение также оставляет отраслевые или системные слова на своих местах. Автомобильная промышленность, ADAS, питание для электромобилей и ИИ-чипы могут изменить давление вокруг вопроса о релизе, но они не должны втягивать статью в заявления о производительности или квалификации, специфичные для конкретного сектора. Вопрос на уровне платы остается прежним: какие доказательства доступа или поведения нужны этой сборке дальше?

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

Какие входные данные пакета и условия доступа должны определять выбор метода тестирования?

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

Именно здесь незаметно проваливаются многие обсуждения методов тестирования. Они предполагают, что выбор метода происходит после того, как плата уже находится на стадии рассмотрения для производства (production review). На практике выбор метода зависит не только от производственных файлов, поэтому пакет релиза должен выявить соответствующие намерения проектирования и производства до того, как плата перейдет к следующей сборке.

Первый входной параметр (input) — это контекст конструкции платы. Gerber-файлы, данные для сверления, примечания к стекапу и другие файлы, ориентированные на производство плат (fabrication), важны, но они являются лишь отправной точкой. Они определяют, чем является плата, а не то, какой метод тестового доступа для собранной платы следует использовать.

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

Третий параметр — физический доступ. И flying probe, и планирование на базе адаптеров зависят от того, какие электрические точки реально достижимы на собранной плате. Boundary scan зависит от предполагаемого поведения цифрового доступа, а не только от физической досягаемости зонда. FCT снова зависит от другой концепции доступа, поскольку он определяется конфигурацией под напряжением, интерфейсами и ожидаемым поведением. Статья становится сильнее, когда учит читателя, что "доступ" — это не что-то однородное. Разные методы требуют разных форм доступа.

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

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

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

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

Шестой параметр — ясность передачи (handoff). Если выбранный метод невозможно объяснить с помощью пакета для релиза, следующая сборка уже несет в себе скрытые допущения. Полезный публичный шаг — научить читателя тому, что выбор метода должен быть виден в записях о релизе, а не открываться заново после того, как плата поступит на сборку.

Это дает статье практическую последовательность выбора:

1. Определите вопрос для следующих доказательств.
2. Подтвердите, что плата имеет достаточный контекст пакета данных, чтобы поддержать реальный выбор метода.
3. Проверьте, какой вид доступа требуется для этого метода.
4. Проверьте, соответствует ли текущая стадия программы позиции с адаптером или без него.
5. Подтвердите, что метод по-прежнему не будет доказывать.

Матрица решений: Требования к входным данным пакета для методов тестирования

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

То же самое относится к широкому языку flying-probe. Это руководство не рассматривает название метода как универсальное обещание. Оно сохраняет полезную позицию: flying probe принадлежит к тем ситуациям, когда электрическая проверка без адаптеров является правильным краткосрочным маршрутом, а не к тем, где странице требуется широкая гарантия.

Маршрутизация к связанным страницам продуктов также становится более понятной, когда решение принимается на основе входных данных пакета. Если плата уже находится в рамках широкого маршрута сквозной сборки (end-to-end assembly) и ей нужна более четкая передача на уровне программы, то Сборка под ключ (Turnkey Assembly) является естественным путем. Если разговор смещается в сторону более стабильной повторяющейся производственной позиции, то Крупносерийная сборка (Large-volume Assembly) становится более релевантной. Эти ссылки работают, потому что статья сначала проясняет нагрузку при релизе, а не просит связанные страницы поглощать двусмысленность.

Как передать следующую сборку, не превращая один метод в доказательство всего?

После того как плата выбрала семейство методов, последняя задача — передать эстафету следующей сборке (hand off), не преувеличивая того, что доказывает этот выбор. Это та часть статьи, где риск завышенных заявлений возрастает быстрее всего, потому что естественный соблазн — сделать так, чтобы каждый выбранный метод звучал как окончательный приговор.

Более безопасная позиция — рассматривать передачу как трансляцию доказательств (evidence transfer), а не как язык вердиктов.

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

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

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

Если выбранный метод — FCT, при передаче следует сохранить то, какое поведение под напряжением предполагалось подтвердить, при какой логике настройки (setup logic) и как часть какого более широкого потока релизов. Это не должно означать, что подтверждение под напряжением заменяет планирование электрического доступа, полноту пакета данных или долгосрочную оценку надежности.

Это различие важно, потому что разные названия методов создают разные виды ложной уверенности:

• boundary scan может звучать как глубокое цифровое доказательство, тогда как на самом деле это метод доступа и межсоединений
• flying probe может звучать как полная стратегия тестирования с низкими обязательствами, тогда как на самом деле это позиция проверки (screening) без адаптеров
• ICT может звучать как универсальный путь модернизации, тогда как на самом деле это семейство методов на базе адаптеров, которое по-прежнему зависит от пригодности пакета и программы
• FCT может звучать как окончательная правда о продукте, тогда как на самом деле это подтверждение поведения под напряжением в заданной среде

Страница завершается скромной моделью передачи релиза (release-handoff). Сильная передача для следующей сборки обычно несет в себе:

• идентичность ревизии
• выбранную роль доказательств и причину, по которой она была выбрана
• допущения относительно пакета (package assumptions), стоящие за этим выбором
• записи или примечания, показывающие, что должна была подтвердить сборка
• нерешенные вопросы, которые по-прежнему относятся к более поздней валидации или более позднему планированию производства

Этого достаточно, чтобы страница оставалась ценной и не выходила за рамки.

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

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

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

Что должно быть включено в контрольный список RFQ для выбора тестирования PCBA?

Прежде чем запрашивать коммерческое предложение (RFQ) на тестирование PCBA, убедитесь, что пакет данных четко определяет требуемый метод и предоставляет файлы, необходимые для программирования испытательного оборудования, а не оставляет объем покрытия на усмотрение завода.

Данные для Flying Probe и ICT

• Интеллектуальные CAD-данные: Предоставьте файлы ODB++ или IPC-2581. Стандартных Gerber-файлов часто бывает недостаточно для программирования автоматизированных целей зондирования, поскольку в них отсутствуют интеллектуальные данные списка цепей (netlist) и центроидов компонентов.
• Определение контрольных точек: Укажите, добавлены ли выделенные контрольные точки (test points), или ожидается, что фабрика будет зондировать непосредственно переходные отверстия (vias), контактные площадки (pads) или выводы компонентов.
• Ожидания по покрытию: Уточните, является ли целью 100% покрытие цепей (часто физически невозможное на плотных платах) или базовое обнаружение обрывов/коротких замыканий на доступных цепях.

Данные для Boundary Scan (JTAG)

• Файлы BSDL: Предоставьте файлы языка описания Boundary Scan (BSDL) для всех JTAG-совместимых устройств в цепи.
• Архитектура цепи: Включите четкую схему или структурную схему, показывающую маршрутизацию сигналов TDI, TDO, TCK и TMS по всей плате.

Данные для функционального тестирования (FCT)

• Процедура тестирования: Предоставьте подробный пошаговый документ, детализирующий точные входные сигналы, ожидаемые выходные сигналы и приемлемые диапазоны допусков для пределов pass/fail.
• Прошивка и оснастка: Укажите, нужно ли прошивать тестовую прошивку (firmware) перед FCT, и перечислите все необходимые ответные кабели, разъемы или специфические нагрузки для установки (setup).

Часто задаваемые вопросы (FAQ)

Является ли boundary scan тем же самым, что и валидация высокоскоростных сигналов?

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

В каких случаях flying probe обычно является лучшим краткосрочным выбором?

Flying probe наиболее силен, когда плате требуется электрическая проверка без адаптеров, а текущая стадия проектирования или программы еще не оправдывает специализированное планирование на базе адаптеров в качестве основного маршрута. Важным моментом является именно позиционирование (posture), а не точный порог объема или окупаемости.

Почему в этом руководстве упоминается ICT, если ICT не является ведущим методом?

Потому что flying probe имеет смысл как позиция выбора только тогда, когда видна схема сравнения на базе адаптеров. Эта страница использует ICT узко, чтобы объяснить этот контраст. Она не пытается стать полной страницей о проектировании адаптеров или возможностях ICT.

Заменяет ли функциональное тестирование планирование электрического доступа?

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

Достаточно ли Gerber-файлов для выбора между этими методами?

Самих по себе — нет. Файлы для производства важны, но выбор метода также зависит от набора корпусов (package mix), электрического доступа, намерений в отношении цифрового тестового доступа, целей поведения под напряжением и стадии программы.

Доказывает ли выбор одного из этих методов надежность продукта?

Нет. Boundary scan, flying probe, ICT и FCT могут предоставить различные типы доказательств, но сами по себе они не устанавливают широких доказательств надежности, статуса квалификации или полной готовности продукта.

Следующие шаги

Если текущая плата PCBA уже несет в себе риски, связанные с тестовым покрытием, или если команда не может с уверенностью сказать, завершена ли цепь JTAG и сможет ли flying probe физически добраться до критических цепей (nets), то настал момент перестать относиться к выбору тестирования как к последующему (downstream) заводскому выбору. На плотных сборках пробелы в покрытии обычно становятся дорогими только после того, как на плату уже затрачено время сборки и отладки (debug).

Отправьте полный пакет производственных данных, желательно в форматах ODB++ или IPC-2581 с физическими координатами и данными цепей, а также спецификацию (BOM), на [email protected], или загрузите данные через страницу Quote. Команда инженеров по DFT тестированию HILPCB вернет оценку тестового доступа в течение 24 часов. Этот обзор призван закрыть реальные риски до начала сборки: физические слепые зоны для зондов, валидность цепи boundary-scan и смешанную стратегию тестирования, которая дает следующей сборке PCBA наилучшие шансы на выявление дефектов до того, как они ускользнут на этап дорогостоящего FCT или системной отладки.

Источники

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

• HILPCB: Крупносерийная сборка (Large-volume Assembly)
  Поддерживает смежный маршрут производственной стадии, когда позиция сборки (build posture) становится более стабильной и повторяющейся.

• IEEE SA: IEEE 1149.1 overview
  Поддерживает публичную идентичность boundary-scan как архитектуры, ориентированной на тестовый доступ и межсоединения, а не как уровня доказательства целостности сигналов.

• Внутренние источники по границам методов, маршрутизируемые через локальную llm_wiki: pcba-flying-probe-vs-ict-selection-posture, pcba-boundary-scan-jtag-positioning, pcba-test-method-input-package-boundary и boundary-scan-does-not-prove-high-speed-channel-quality
  Подтверждают осторожное разграничение в статье между позицией flying probe без адаптеров, позицией сравнения на базе адаптеров, планированием доступа boundary-scan и явным отказом от заявлений о доказательствах высокоскоростных характеристик.