چگونه برنامه ریزی DFT تست PCBA و کارایی اشکال زدایی را بهبود می بخشد

PCBA را می توان به درستی مونتاژ کرد و هنوز آزمایش آن دشوار است.

اینجاست که برنامه ریزی DFT اهمیت دارد.

طراحی برای تست‌پذیری یا DFT، تنها در مورد افزودن نقاط تست بیشتر به طرح‌بندی PCB نیست. در یک پروژه PCBA واقعی، برنامه‌ریزی DFT تصمیم می‌گیرد که آیا برد مونتاژ شده را می‌توان تغذیه، برنامه‌ریزی، کاوش، اندازه‌گیری، اشکال زدایی، دوباره کاری، آزمایش مجدد و در شرایط ساخت عملی منتشر کرد یا خیر.

یک آزمون قبولی/شکست به تیم می گوید که آیا یک برد کار می کند یا خیر.

یک طرح خوب DFT به تیم کمک می کند تا بفهمد کجا باید نگاه کند در حالی که اینطور نیست.

این تفاوت در هنگام ارائه- نمونه اولیه، اولین بررسی ساخت، آماده سازی ساخت آزمایشی و تکرار تولید EMS اهمیت دارد. یک مهندس طراح ممکن است بتواند یک برد را با ابزارهای آزمایشگاهی، سیم های جامپر و دانش عمیق محصول رفع اشکال کند. یک تیم آزمایش EMS به یک مسیر قابل تکرار نیاز دارد که در چندین تخته کار کند، با مراحل مستند و مدیریت خرابی واضح.

برنامه‌ریزی DFT با آسان‌تر کردن مسیر شکست احتمالی قبل از رسیدن برد به میز آزمایش، تست PCBA و کارایی اشکال‌زدایی را بهبود می‌بخشد.

DFT یک مرحله آزمایشی نیست. این یک تصمیم طراحی است.

تست بعد از مونتاژ انجام می شود.

برنامه ریزی DFT قبل از ساخته شدن برد اتفاق می افتد.

از دست دادن این تمایز آسان است. بسیاری از تیم‌ها آزمایش را به عنوان چیزی می‌دانند که کارخانه می‌تواند پس از انتشار فایل‌های PCB «پیدا کند». گاهی اوقات برای تخته های ساده کار می کند. اما برای-بردهای مبتنی بر سیستم عامل، بردهای کنترل صنعتی، طرح‌بندی‌های متراکم SMT، بسته‌های BGA، رابط‌های ارتباطی، رله‌ها، حسگرها یا محصورات{4}}محصولات یکپارچه، برنامه‌ریزی آزمایش دیرهنگام می‌تواند به اشکال‌زدایی دیرهنگام تبدیل شود.

ممکن است برد روشن شود، اما مسیر شکست ممکن است نامشخص باشد.

تست ممکن است بگوید "شکست"، اما ممکن است نگوید که آیا مشکل مونتاژ، سیستم عامل، آسیب قطعات، تماس فیکسچر، سیم‌کشی کانکتور، وضعیت بار، یا رفتار طراحی است.

برنامه ریزی آزمون پذیری این تفکر را زودتر به حرکت در می آورد. می پرسد:

• کدام توابع باید تایید شوند؟
• کدام سیگنال ها باید قابل دسترسی باشند؟
• کدام ریل های برق نیاز به اندازه گیری یا جداسازی دارند؟
• کدام رابط ها نیاز به برنامه نویسی یا دسترسی به ارتباط دارند؟
• کدام شکست ها باید به سرعت جدا شوند؟
• کدام مراحل تست باید توسط تیم تست EMS قابل تکرار باشد؟
• کدام اطلاعات اشکال زدایی باید پس از شکست ثبت شود؟

تابلویی که فقط برای عملکرد طراحی شده است ممکن است روی نیمکت مهندس کار کند.

برد طراحی شده برای آزمایش را می توان با حدس و گمان کمتر تأیید، تشخیص، تعمیر و دوباره آزمایش کرد.

با آنچه آزمون باید ثابت کند شروع کنید

بسیاری از بحث های DFT با نکات تست شروع می شوند.

این معمولا بهترین نقطه شروع نیست.

سوال اول بهتر این است: این PCBA قبل از انتشار باید چه چیزی را ثابت کند؟

برای برخی از پروژه‌ها، پاسخ ممکن است ساده باشد: قرار دادن صحیح اجزاء، بدون شورت واضح، روشن بودن{0}پایدار، و بررسی‌های اولیه الکتریکی. برای سایرین، برد ممکن است به بارگذاری میان‌افزار، پاسخ حسگر، تأیید ارتباط، تعویض رله، اندازه‌گیری جریان، کالیبراسیون آنالوگ، یا تعامل سطح سیستم با ماژول دیگر نیاز داشته باشد.

آن موقعیت ها به همان طرح آزمایشی نیاز ندارند.

این از یکی از رایج‌ترین مشکلات تست‌پذیری جلوگیری می‌کند: برد دارای نقاط تست است، اما دسترسی تست مناسبی ندارد.

پدی که برای چیدمان مناسب است ممکن است به تیم آزمایش کمک نکند تا یک شکست را جدا کند. کانکتوری که در حین بالا آوردن مهندسی کار می‌کند، ممکن است پس از مونتاژ، پوشش، یا یکپارچه‌سازی محفظه مسدود شود. یک رابط میان‌افزاری که برای یک مهندس کار می‌کند ممکن است برای آزمایش تکرار تولید عملی نباشد.

برنامه‌ریزی خوب DFT با شرایط انتشار شروع می‌شود، سپس برای دسترسی، روش ثابت، ورودی سیستم‌افزار، نقاط اندازه‌گیری، و قوانین تست مجدد کار می‌کند.

حرکت فراتر از تست گذرا/شکست

نتیجه قبولی / شکست مفید است، اما با تشخیص یکسان نیست.

پاسخ های تشخیص: آیا تخته قبول شد؟

پاسخ های تشخیص: تیم بعدی باید به کجا نگاه کند؟

این تفاوت زمانی اهمیت پیدا می‌کند که یک PCBA FCT، ICT، کاوشگر پرنده، برنامه‌نویسی، یا تأیید برق{0}} از کار بیفتد. اگر آزمایش فقط یک خرابی کلی برد را گزارش کند، ممکن است تیم همچنان به یک حلقه اشکال زدایی دستی طولانی برای یافتن مشکل واقعی نیاز داشته باشد.

یک رویکرد DFT قوی تر به فرآیند آزمایش دید بیشتری می دهد.

به عنوان مثال، اگر یک پورت ارتباطی خراب شود، مسیر اشکال زدایی ممکن است به دسترسی به موارد زیر نیاز داشته باشد:

• منابع برق و زمین برای مدار رابط؛
• بازنشانی، فعال کردن یا راه‌اندازی سیگنال‌ها.
• خروجی ساعت یا نوسانگر؛
• تایید پین اوت کانکتور؛
• نسخه سیستم عامل یا وضعیت برنامه نویسی؛
• تایید تماس ثابت؛
• شناخته شده-کابل، بار، یا وضعیت ماژول خارجی خوب؛
• نقاط سیگنال میانی بین بلوک های عملکردی.

این بدان معنا نیست که هر بردی به یک معماری تشخیصی سنگین وزن نیاز دارد.

یک برد ساده نباید بیش از-برای آزمایش طراحی شود. اما اگر محصول دارای سفت‌افزار،-قطعات با چگالی بالا، سیم‌کشی میدان، ورودی/خروجی صنعتی، سوئیچینگ برق، حسگرها، یا رابط‌های خاص مشتری- باشد، برنامه‌ریزی DFT باید فراتر از یک نتیجه عبور/خروش فکر کند.

نتیجه آزمایشی که می‌گوید «شکست» بدون مسیر اشکال‌زدایی می‌تواند یک برد بد را به یک بررسی طولانی تبدیل کند.

دسترسی تست در Layout شروع می شود، نه در ایستگاه آزمایش

بخش تست نمی‌تواند به سیگنالی دسترسی پیدا کند که طرح‌بندی هرگز قابل دسترسی نبوده است.

این بدیهی به نظر می رسد، اما یکی از ساده ترین چیزهایی است که وقتی تیم طراحی تحت فشار برنامه است، از دست می رود.

دسترسی تست به تصمیمات طرح بستگی دارد:

• آیا شبکه های حیاتی دسترسی پروب عملی دارند یا خیر.
• آیا نقاط تست توسط پروب های ثابت قابل دسترسی هستند یا خیر.
• آیا اجزای بلند جلوی حرکت پروب را می گیرند یا خیر.
• آیا نقاط تست خیلی نزدیک به بدنه اجزا یا لبه های برد هستند.
• آیا حفره‌ها و سوراخ‌های ابزار از همترازی ثابت ثابت پشتیبانی می‌کنند یا خیر.
• آیا هدرهای برنامه نویسی پس از مونتاژ در دسترس باقی می مانند یا خیر.
• آیا می توان یک تخته را قبل یا بعد از پوشش یا یکپارچه سازی محفظه آزمایش کرد.

یک نقطه آزمایشی که در مکان اشتباه قرار می‌گیرد می‌تواند تقریباً به همان اندازه بی‌فایده باشد که هیچ نقطه آزمایشی وجود ندارد.

برای تخته‌های با تراکم بالا، پاسخ همیشه این نیست که "به هر شبکه یک نقطه آزمایش اضافه کنید." فضای برد، یکپارچگی سیگنال، هزینه، حجم تولید و روش تست همه مهم هستند. در برخی موارد، شبکه‌های بحرانی، ریل‌های برق، خطوط تنظیم مجدد، ساعت‌ها، سیگنال‌های برنامه‌نویسی، و{3}}رابط‌های پرخطر شایسته اولویت هستند. در موارد دیگر، اسکن مرزی، کاوشگر پرواز یا آزمایش عملکردی ممکن است بخش هایی از نیاز آزمایش را به طور موثرتری پوشش دهد.

برنامه ریزی DFT در مورد افزودن کورکورانه ویژگی ها نیست.

این در مورد دسترسی تیم آزمایش به سیگنال های مهم است.

اسکن مرزی می تواند مشکل جعبه سیاه را کاهش دهد

اسکن مرزی، که اغلب با IEEE 1149.1 و JTAG مرتبط است، زمانی که دسترسی کاوشگر فیزیکی محدود باشد، می تواند ارزشمند باشد.

این امر به‌ویژه برای بردهایی با BGA،-ICهای دقیق، پردازنده‌ها، FPGA، دستگاه‌های حافظه یا اتصالات دیجیتال متراکم مرتبط است. در این طرح ها، بسیاری از پین های مهم پس از مونتاژ به صورت فیزیکی قابل دسترسی نیستند. بدون مسیر اسکن یا روش تشخیصی دیگری، برد ممکن است در صورت خرابی مانند یک جعبه سیاه رفتار کند.

اسکن مرزی می‌تواند به تأیید اتصالات بین دستگاه‌های سازگار کمک کند، از برنامه‌نویسی یا جریان‌های کاری پیکربندی پشتیبانی کند، و دید تشخیصی را در مواردی که کاوش فیزیکی دشوار است فراهم کند.

اما فقط در صورتی کمک می کند که برنامه ریزی شده باشد.

برنامه ریزی اسکن مرزی مفید ممکن است شامل موارد زیر باشد:

• مسیریابی سیگنال های اسکن به یک رابط قابل دسترسی یا رابط آزمایشی؛
• تأیید اینکه کدام دستگاه ها از اسکن مرزی پشتیبانی می کنند.
• تعریف صحیح زنجیره اسکن؛
• ارائه فایل های BSDL در صورت نیاز.
• تأیید اینکه آیا اسکن مرز برای آزمایش تولید، اشکال زدایی مهندسی یا هر دو استفاده می شود.
• اطمینان حاصل کنید که رابط تست توسط طراحی مکانیکی یا محدودیت‌های محفظه مسدود نشده است.

اسکن مرزی جایگزین تمام دسترسی‌های آزمایشی فیزیکی نمی‌شود و شرایط آنالوگ، برق یا اتصال را تأیید نمی‌کند. زمانی که زنجیره اسکن توسط دستگاه های انتخاب شده برنامه ریزی، مستندسازی و پشتیبانی می شود بسیار مفید است.

برای یک برد ساده با پیچیدگی دیجیتال محدود، اسکن مرز ممکن است ارزش کمی اضافه کند. برای یک برد کنترل متراکم یا مجموعه مبتنی بر پردازنده-، می تواند تفاوت بین جداسازی مفید خطا و یک خرابی عملکردی عمومی باشد.

پارتیشن بندی قدرت و سیگنال می تواند حلقه های اشکال زدایی را کوتاه کند

اشکال زدایی برخی از خرابی ها سخت است زیرا مدار برای ایزوله طراحی نشده است.

اتصال کوتاه روی ریل برق مشترک ممکن است بر بسیاری از قسمت های برد تأثیر بگذارد. یک رابط ارتباطی ناموفق ممکن است به سختی از سیستم عامل، سیم‌کشی رابط، آسیب فرستنده گیرنده یا تماس فیکسچر جدا شود. یک زنجیره سیگنال آنالوگ ممکن است در خروجی از کار بیفتد، در حالی که مشکل واقعی چندین مرحله زودتر رخ داده است.

برنامه ریزی DFT می تواند این عدم قطعیت را کاهش دهد.

انتخاب های مفید طراحی ممکن است شامل موارد زیر باشد:

• نقاط اندازه گیری قابل دسترسی روی ریل های برق مهم؛
• ارجاعات زمینی عملی نزدیک سیگنال های اندازه گیری شده.
• گزینه های جداسازی مانند پیوندهای 0 اهم، جامپرها یا اتصالات قابل جابجایی در صورت لزوم.
• نقاط تست میانی در زنجیره سیگنال؛
• فعال کردن یا تنظیم مجدد کنترل برای بلوک های عملکردی؛
• شناخته شده-گزینه های بارگذاری یا حلقه بک خوب برای رابط های انتخابی؛
• جداسازی واضح بین خرابی برنامه نویسی، خرابی فیکسچر و خرابی برد.

اینها همیشه تغییرات طراحی گران قیمت نیستند. اغلب، آنها تصمیمات کوچکی هستند که به اندازه کافی زود گرفته می شوند.

نکته کلیدی این است که به این فکر کنید که تکنسین در هنگام از کار افتادن برد چه خواهد دید.

اگر تمام سیستم آزمایشی که می‌تواند گزارش کند «برد شکست خورد» است، مسیر اشکال‌زدایی با عدم قطعیت آغاز می‌شود. اگر برنامه‌ریزی DFT به بلوک‌های عملکردی، حوزه‌های قدرت و رابط‌های حیاتی دسترسی پیدا کند، تیم شانس بیشتری برای تبدیل شکست به یک اقدام خاص خواهد داشت.

سیستم عامل و برنامه نویسی متعلق به برنامه ریزی DFT است

برای بسیاری از PCBA های مدرن، آزمایش فقط الکتریکی نیست.

همچنین وابسته به نرم افزار-است.

ممکن است یک برد قبل از آزمایش عملکردی به سیستم عامل نیاز داشته باشد. ممکن است به یک بوت لودر، تصویر آزمایشی، تصویر تولید، فایل پیکربندی، شماره سریال، آدرس MAC، داده کالیبراسیون یا اسکریپت ارتباطی نیاز داشته باشد. اگر آن ورودی ها کنترل نشوند، بردی که به درستی مونتاژ شده است ممکن است همچنان به دلیل اشتباهی در تست شکست بخورد.

برنامه ریزی DFT باید روشن کند:

• چه کسی سیستم عامل را فراهم می کند.
• کدام نسخه سیستم عامل برای تست تولید استفاده می شود.
• آیا برد قبل یا بعد از بازرسی برنامه ریزی شده است.
• کدام رابط برای برنامه نویسی استفاده می شود.
• آیا اتصال برنامه نویسی در دسترس باقی می ماند.
• آیا یک چک‌سوم، فایل گزارش یا سابقه نسخه مورد نیاز است.
• اگر برنامه نویسی با شکست مواجه شود چه اتفاقی می افتد.
• آیا برد باید بعد از کار مجدد برنامه ریزی شود یا خیر.

این یکی از رایج ترین شکاف های بین تست مهندسی و تست تولید است.

ممکن است تیم طراحی بداند که چگونه سفت‌افزار را از یک کامپیوتر آزمایشگاهی بارگیری کند. تیم آزمایش EMS به روشی نیاز دارد که بتوان آن را مستند کرد، دنبال کرد، بررسی کرد و تکرار کرد.

اگر سیستم عامل بخشی از برنامه ریزی DFT نباشد، تست عملکرد ممکن است قبل از شروع آزمایش واقعی به یک جلسه عیب یابی برنامه نویسی تبدیل شود.

آمادگی فیکسچر به تصمیمات DFT بستگی دارد

یک دستگاه تست فقط یک نگهدارنده مکانیکی نیست.

این نتیجه فیزیکی تصمیمات آزمایش پذیری قبلی است.

آمادگی فیکسچر به موارد زیر بستگی دارد:

• جایی که پروب ها می توانند با هیئت مدیره تماس بگیرند.
• آیا لنت ها به اندازه کافی بزرگ هستند و برای روش مورد نظر فاصله دارند.
• آیا ارتفاع جزء دسترسی را مسدود می کند.
• آیا پشتیبانی هیئت مدیره از خم شدن در هنگام تماس جلوگیری می کند.
• آیا کانکتورها به کابل های جفت نیاز دارند یا خیر.
• آیا تخته از یک طرف یا هر دو طرف آزمایش می شود.
• آیا آزمایش قبل یا بعد از پوشش یا یکپارچه سازی محفظه انجام می شود.
• آیا اپراتور به تعامل بارکد، برچسب یا شماره سریال نیاز دارد.
• آیا واحدهای ناموفق نیاز به جداسازی و آزمایش مجدد دارند یا خیر.

اگر این تصمیمات تا دیر وقت باقی بماند، ممکن است مجمع به جلو حرکت کند در حالی که آزمایش تبدیل به گلوگاه می شود.

تیم EMS برای هر ساخت اولیه مهندسی نیازی به یک دستگاه کامل تولید ندارد. اما باید مسیر مورد انتظار را بداند: آزمایش دستی، کاوشگر پرواز، ICT، اسکن مرزی، FCT، تجهیزات موقت،-راه اندازی ارائه شده توسط مشتری، یا تجهیزات تولید{2}}.

اینها فرضیات ساخت متفاوتی هستند.

مشکل ثابت اغلب مانند خرابی برد به نظر می رسد تا زمانی که تیم ثابت کند تماس، کابل یا راه اندازی پایدار است.

یک پروژه می تواند آماده باشدمونتاژ PCBو هنوز برای آزمایش های قابل تکرار آماده نیستید.

برنامه ریزی DFT باید حلقه Rework و Retest را تعریف کند

آزمایش با شکست یک برد تمام نمی شود.

سوال بعدی این است که بعد از شکست چه اتفاقی می افتد.

بدون یک مسیر تست مجدد تعریف شده، تصمیمات دوباره کاری می توانند ناسازگار شوند. یک تکنسین ممکن است یک قطعه مشکوک را جایگزین کند و فقط مرحله شکست خورده را تکرار کند. دیگری ممکن است تست عملکردی کامل را دوباره اجرا کند. یک سوم ممکن است پس از چک کردن سریع- از تخته عبور کند زیرا علامت اصلی ناپدید شده است.

که ریسک ایجاد می کند.

یک طرح عملی DFT باید تعریف کند:

• کدام شکست نیاز به بررسی مهندسی دارد.
• چه کارهای مجددی مجاز است
• آنچه باید پس از کار مجدد بررسی شود.
• آیا توالی کامل آزمون باید تکرار شود.
• آیا آزمون مجدد متمرکز قابل قبول است یا خیر.
• چه داده های خرابی باید ثبت شود.
• چگونه شکست های مکرر تشدید می شوند.

این به خاطر خودش کاغذبازی نیست.

یک PCBA بازسازی شده نباید منتشر شود زیرا "حالا خوب به نظر می رسد." باید منتشر شود زیرا مسیر آزمایش مجدد توافق شده تأیید می کند که مشکل بسته شده است.

اینجاست که برنامه ریزی DFT هم از راندمان تولید و هم از کنترل کیفیت پشتیبانی می کند.

بسته DFT{0}}آماده PCBA باید شامل چه چیزی باشد

برنامه ریزی DFT زمانی مفید می شود که در بسته مهندسی قابل مشاهده باشد.

این یک سند اجباری برای هر ساختنی نیست. این روشی است برای نشان دادن چه اطلاعاتی ممکن است زمانی که محدوده آزمایش فراتر از یک بازرسی بصری ساده یا کنترل{1}} مورد نیاز باشد.

برای خریداران OEM، یک بسته آماده {0}DFT ممکن است شامل موارد زیر باشد:

یک تخته ساده ممکن است فقط به یک مسیر تست سبک تر نیاز داشته باشد. یک برد کنترل صنعتی مبتنی بر سیستم عامل-ممکن است به بسته DFT کاملتری نیاز داشته باشد. یک ساخت آزمایشی ممکن است به رکوردهای تکرارپذیر بیشتری نسبت به نمونه مهندسی اولیه نیاز داشته باشد.

نکته مهم حجم سند نیست.

نکته مهم این است که آیا تیم EMS اطلاعات کافی برای آزمایش برد بدون ساخت روش تست از روی حدس و گمان دارد یا خیر.

از نتایج تست برای بهبود نسخه بعدی استفاده کنید

DFT یک چک لیست- یکباره نیست.

بیلد اول اغلب چیزی را به تیم می آموزد که در بررسی طرح بندی مشخص نبود.

پس از تست PCBA و اشکال زدایی، تیم OEM و EMS باید بپرسند:

• جداسازی کدام شکست ها دشوار بود؟
• کدام مراحل تست بیشتر از حد انتظار طول کشید؟
• کدام عملکرد را نمی توان به طور قابل اعتماد آزمایش کرد؟
• دسترسی به کدام نقاط کاوشگر سخت بود؟
• کدام اتصالات ثابت باعث خرابی های کاذب شده است؟
• کدام سیستم عامل یا مراحل برنامه نویسی باعث سردرگمی شد؟
• کدام تخته‌های بازسازی‌شده بیش از حد انتظار نیاز به آزمایش مجدد دارند؟
• دفعه بعد کدام نتایج آزمایش باید متفاوت ثبت شود؟

این بازخورد نباید فقط در منطقه آزمایش باقی بماند.

باید نسخه بعدی PCB، روش آزمایش بعدی، طراحی ثابت بعدی و بسته NPI بعدی را تغذیه کند.

یک فرآیند DFT خوب، اولین ساخت را به یک حلقه یادگیری تبدیل می کند.

چگونه این به پشتیبانی مونتاژ و تست PCB متصل می شود

برای خریداران OEM، برنامه ریزی DFT زمانی بسیار مفید است که طراحی برد، محدوده مونتاژ، نیازهای برنامه نویسی، دسترسی تست و انتظارات انتشار را قبل از شروع تولید به هم متصل کند.

STHL از پروژه های OEM از طریق آماده سازی مونتاژ، برنامه ریزی تست وتست و بازرسی، از جمله بحث در مورد AOI، ICT، FCT، بازرسی اشعه ایکس-، ورودی‌های برنامه‌نویسی میان‌افزار، آمادگی فیکسچر، انتظارات مجدد و آزمایش مجدد، و نیازهای ردیابی.

هدف اضافه کردن تست های غیر ضروری نیست.

هدف این است که محدوده آزمایش به اندازه کافی برای عملکرد هیئت مدیره، مرحله تولید و سطح ریسک کاربردی باشد.

آیا ساخت PCBA را آماده می کنید که به دسترسی آزمایشی واضح تر یا برنامه ریزی آزمایش عملکردی نیاز دارد؟ پروژه خود را از طریق ارسال کنیددرخواست یک نقل قولیا ایمیلinfo@pcba-china.com.

نتیجه گیری

برنامه ریزی DFT تست PCBA و کارایی اشکال زدایی را بهبود می بخشد زیرا تفکر تست را قبل از اینکه برد به خط برسد به سمت بالا حرکت می دهد.

این به تیم OEM و EMS کمک می کند تا مشخص کند چه چیزی باید آزمایش شود، کجا به دسترسی نیاز است، چگونه سیستم عامل بارگذاری می شود، چه فیکسچر یا کابلی مورد نیاز است، چه نتیجه ای به عنوان پاس یا خرابی به حساب می آید، و چگونه بردهای ناموفق باید اشکال زدایی، کار مجدد و آزمایش مجدد شوند.

بوردی که مونتاژ آن آسان است همیشه آزمایش آن آسان نیست.

بردی که تست آن آسان است معمولاً بردی است که دسترسی تست، برنامه نویسی، آمادگی فیکسچر و دید اشکال زدایی قبل از مونتاژ در نظر گرفته شده است.

برای خریداران OEM، درس عملی ساده است: بهترین زمان برای پرسیدن اینکه چگونه یک برد آزمایش می شود، قبل از قفل شدن بسته بندی طرح و ساخت است.