پی سی بی اسمبلی پروجیکٹس میں پروٹوٹائپ کی توثیق کو کس چیز نے سست کردیا؟

تعارف

بہت سی OEM ٹیمیں فرض کرتی ہیں کہ ایک بار جب پروٹوٹائپ بورڈز پہنچ جائیں گے تو تصدیق تیزی سے آگے بڑھ جائے گی۔

یہ معقول لگتا ہے۔ حقیقی منصوبوں میں، یہ اکثر نہیں ہے.

ایک پروٹوٹائپ پی سی بی اسمبلی شیڈول پر واپس آسکتی ہے اور پھر بھی تصدیق میں دن، یا ایک ہفتہ بھی ضائع کر سکتی ہے، اگر ٹیم اب بھی اس بات پر بحث کر رہی ہے کہ تعمیر کو کیا ثابت کرنا تھا، BOM میں کیا تبدیلی آئی، یا آیا ٹیسٹ کا راستہ قابل استعمال جواب پیدا کرنے کے لیے تیار ہے۔ اس وقت، سست روی اب صرف اسمبلی لیڈ ٹائم کے بارے میں نہیں ہے۔ یہ رہائی، ٹیسٹ، اور ہینڈ آف کا مسئلہ بن جاتا ہے۔

اس مضمون کے پیچھے اصل سوال یہی ہے۔ مسئلہ صرف یہ نہیں ہے کہ پروٹو ٹائپ کتنی تیزی سے بنایا جا سکتا ہے۔ مسئلہ یہ ہے کہ بورڈز پہلے سے بنچ پر ہونے کے بعد بھی تصدیق کیوں رکی ہوئی ہے۔

اگر آپ کی ٹیم پہلے ہی -بورڈ ٹائمنگ سے گزر چکی ہے اور اب یہ سمجھنے کی کوشش کر رہی ہے کہ پروٹو ٹائپ کی پیشرفت اب بھی سست کیوں محسوس ہوتی ہے، تو صرف اسمبلی سے باہر دیکھنے اور ارد گرد کے پورے راستے کا جائزہ لینے کا یہی نکتہ ہے۔پی سی بی اسمبلی.

پروٹو ٹائپ ڈیلیوری اور پروٹوٹائپ کی تصدیق ایک ہی سنگ میل نہیں ہیں۔

یہ وہ جگہ ہے جہاں بہت سارے نظام الاوقات غلط پڑھے جاتے ہیں۔

پروٹوٹائپ ڈیلیوری کا مطلب ہے کہ بورڈز من گھڑت، اسمبل اور وصول کیے گئے ہیں۔ پروٹوٹائپ کی تصدیق کا مطلب ہے کہ ٹیم نے اصل میں ان بورڈز کو مطلوبہ تکنیکی سوال کا جواب دینے اور فیصلہ کرنے کے لیے استعمال کیا ہے کہ آگے کیا ہوتا ہے۔

وہ ایک ہی سنگ میل نہیں ہیں۔

ایک بورڈ وقت پر پہنچ سکتا ہے اور پھر بھی پروجیکٹ کو آگے بڑھانے میں ناکام رہتا ہے۔ یہ طاقتور ہوسکتا ہے، پھر بھی اس ٹیسٹ کے راستے کی حمایت نہیں کرتا جو اہمیت رکھتا ہے۔ اسے صحیح طریقے سے جمع کیا جا سکتا ہے، لیکن پھر بھی متبادلات، پروگرامنگ مفروضوں، انٹرفیس کے رویے، یا بینچ پر واقعی کون سی نظرثانی کے بارے میں شکوک پیدا ہوتے ہیں۔ کبھی کبھی ہارڈ ویئر بالکل مسئلہ نہیں ہے. ٹیم صرف اس بات پر متفق نہیں ہے کہ پاس کے طور پر کیا شمار ہوتا ہے، کیا قابل قبول انحراف کے طور پر شمار ہوتا ہے، اور کس چیز کو ایک اور اسپن کو متحرک کرنا چاہئے۔

یہی وجہ ہے کہ پروٹو ٹائپ کی توثیق اکثر اس سے پہلے کی بجائے ڈیلیوری کے بعد پھسل جاتی ہے۔

ایک بورڈ قابل تعمیر ہوسکتا ہے اس سے پہلے کہ یہ واقعی قابل تصدیق ہو۔

جہاں OEM ٹیمیں عام طور پر مسئلہ کا غلط اندازہ لگاتی ہیں۔

سب سے عام غلطی یہ فرض کر رہی ہے کہ تاخیر اب بھی مینوفیکچرنگ سے تعلق رکھتی ہے۔

کبھی کبھی ایسا ہوتا ہے۔ اکثر ایسا نہیں ہوتا۔

ایک بار جب بورڈز پہلے ہی بنچ پر آجاتے ہیں، تو اصل رکاوٹ عام طور پر توثیق کی منطق، نظرثانی کنٹرول، سورسنگ کی وضاحت، اور ٹیسٹ کی ترتیب میں بدل جاتی ہے۔ پروجیکٹ اب بھی سست محسوس ہوتا ہے، لیکن اب اس کی رفتار اسی وجہ سے نہیں ہے جس کی وجہ سے تعمیر بھیجنے سے پہلے سست تھی۔

یہ فرق اہمیت رکھتا ہے کیونکہ ٹیمیں اکثر غلط مسئلے پر ردعمل ظاہر کرتی ہیں۔ وہ ایک تیز تر اگلے-موڑ کی تعمیر کے لیے زور دیتے ہیں جب انہیں واقعی ایک سخت توثیق کا مقصد، ایک صاف ستھرا نظرثانی کی بنیاد، یا ایک ایسا امتحانی راستہ جو درحقیقت صرف مزید بحث پیدا کرنے کے بجائے فیصلوں کی حمایت کر سکتا ہے۔

ایک بورڈ شیڈول پر واپس آ سکتا ہے اور پھر بھی تصدیق میں ایک ہفتہ ضائع کر سکتا ہے اگر ٹیم ابھی بھی اس بات پر بحث کر رہی ہے کہ اسے بالکل کیا ثابت کرنا تھا۔

ایک مفید باؤنڈری کیس

ایک چھوٹی پروٹو ٹائپ لاٹ کا خود بخود مطلب یہ نہیں ہے کہ تصدیق تیز ہونی چاہیے۔

دس-بورڈ کی تعمیر اب بھی آہستہ آہستہ تصدیق کر سکتی ہے اگر ہر یونٹ میں حل نہ ہونے والی سورسنگ تبدیلیاں، غیر واضح ٹیسٹ کا ارادہ، اور مخلوط نظرثانی کے مفروضے ہوں۔ ایک پانچ- بورڈ اسپن بھی گھسیٹ سکتا ہے اگر فرم ویئر کی بیس لائن ایک ہی وقت میں حرکت کر رہی ہو اور توثیق کا منصوبہ کبھی بھی کافی تنگ نہیں کیا گیا تھا۔

دوسری طرف، اگر BOM صاف ہے، سوال تنگ ہے، اور لانے کا راستہ پہلے سے ہی ترتیب دیا گیا ہے تو کچھ بڑی لاٹ تیزی سے تصدیق کر سکتی ہے۔

یہی وجہ ہے کہ صرف بورڈ کی گنتی ہی تصدیق کی رفتار کا ناقص پیش گو ہے۔

تصدیق کو تیزی سے منتقل کرنے میں کیا مدد کرتا ہے۔

اگر مقصد پروٹوٹائپ کی تصدیق کو مختصر کرنا ہے، تو عام طور پر اگلی تعمیر شروع ہونے سے پہلے سب سے بڑی اصلاحات کی جاتی ہیں۔

توثیق کے سوال کو پہلے لاک کریں۔

ایک پروٹو ٹائپ تیزی سے تصدیق کرتا ہے جب ٹیم کو معلوم ہوتا ہے کہ اس اسپن کو کیا ثابت کرنا ہے، اور اتنا ہی اہم بات یہ ہے کہ اسے کیا ثابت کرنا نہیں ہے۔

سورسنگ کی تبدیلیوں کو مرئی رکھیں

اگر دستیابی- سے چلنے والے متبادل استعمال کیے گئے تھے، تو وہ بلڈ ریکارڈ میں واضح اور توثیق کے دوران ان پر بات کرنا آسان ہونا چاہیے۔ پوشیدہ سورسنگ تبدیلیاں سست سیکھنے کو جنم دیتی ہیں۔

ڈیٹا پیکج کو ٹیسٹ پاتھ کے ساتھ سیدھ کریں۔

BOM نظرثانی، اسمبلی آؤٹ پٹ، فرم ویئر ورژن، پروگرامنگ مفروضے، اور لانے والی{0}}چیک لسٹ سبھی کو ایک ہی مطلوبہ بنیاد کی طرف اشارہ کرنا چاہیے۔

بورڈز کے آنے سے پہلے امتحان کا راستہ تیار کریں۔

پروگرامنگ، بینچ سیٹ اپ، پاس معیار، اور کسی بھی سادہ فکسچر کے کام کو اس وقت تک انتظار نہیں کرنا چاہئے جب تک کہ اسمبلیاں ہاتھ میں نہ ہوں۔

ڈی ایف ایم کا علاج کریں اور تصدیق کی تیاری کے مسائل کے طور پر رسائی کی جانچ کریں۔

اگر ٹیسٹ تک رسائی ناقص ہے یا مینوفیکچریبلٹی کے خطرات ابھی بھی حل نہیں ہوئے ہیں، تو تصدیق شاذ و نادر ہی صاف رہے گی، چاہے بورڈز کتنی جلدی بنائے گئے ہوں۔

یہ بالکل وہی ہے جہاں کے لحاظ سے سوچناجانچ اور معائنہمفید ہو جاتا ہے، یہاں تک کہ پروٹوٹائپ مرحلے پر۔

موجودہ ماحول میں یہ کیوں زیادہ اہمیت رکھتا ہے۔

موجودہ سورسنگ ماحول میں، دستیابی-سے چلنے والے متبادلات زیادہ عام ہیں، اور لیڈ-وقت کی ریلیف تمام زمروں میں ناہموار ہے۔ جب بھی مادی تبدیلیاں توثیق کے منصوبے میں واضح طور پر ظاہر نہیں ہوتی ہیں تو اس سے پروٹو ٹائپ کی توثیق سست ہوجاتی ہے۔ بورڈ اب بھی وقت پر پہنچ سکتا ہے۔ سیکھنے کا راستہ اکثر ایسا نہیں ہوتا ہے۔

یہ ایک اور وجہ ہے کہ پروٹو ٹائپ کی تصدیق کو اس کی اپنی انجینئرنگ اور کوآرڈینیشن اسٹیج کے طور پر سمجھا جانا چاہئے، نہ کہ صرف اسمبلی لیڈ ٹائم کے ٹیل اینڈ کی طرح۔

نتیجہ

پی سی بی اسمبلی پروجیکٹس میں پروٹوٹائپ کی تصدیق اکثر اس وجہ سے سست ہوجاتی ہے کہ بورڈز کے آنے کے بعد کیا ہوتا ہے، نہ صرف یہ کہ وہ کتنی تیزی سے بنائے گئے تھے۔

سب سے عام وجوہات میں کمزور ڈیٹا ہینڈ آف، دیر سے DFM کی تلاش، دستیابی-سے چلنے والے متبادلات، ٹیسٹ کی ناقص تیاری، دستی پروبنگ رگڑ، نظرثانی میں اضافہ، اور توثیق کے اہداف ہیں جو ایک اسپن کے صاف جواب دینے کے لیے بہت وسیع ہیں۔

یہ سب مینوفیکچرنگ کے مسائل نہیں ہیں۔ ان میں سے بہت سے ریلیز، ٹیسٹ، اور ہینڈ آف کے مسائل ہیں اس سے پہلے کہ وہ خالص مینوفیکچرنگ کے مسائل ہوں۔

اس لیے ٹیموں کو "پروٹو ٹائپ ڈیلیور" کا علاج کرنا بند کر دینا چاہیے گویا اس کا مطلب ہے "پروٹو ٹائپ تصدیق شدہ"۔

بینچ پر موجود بورڈ خود شیڈول کو مختصر نہیں کرتے ہیں۔ ایک قابل استعمال تصدیقی راستہ کرتا ہے۔

اگر آپ کی ٹیم پروٹوٹائپ کی توثیق کو مختصر کرنے کی کوشش کر رہی ہے، تو ایک عملی اگلا مرحلہ اس کے خلاف تعمیر کا جائزہ لینا ہے۔پی سی بی اسمبلی،کی درست سطح کے ساتھ توثیق کے راستے کو سخت کریں۔جانچ اور معائنہسوچ، اور پھر اگلے پروٹوٹائپ دائرہ کار کے ذریعے سیدھ کریںاقتباس کی درخواست کریں۔یا ٹیم سے براہ راست رابطہ کریں۔info@pcba-china.com۔

اکثر پوچھے گئے سوالات

پروٹو ٹائپ ڈیلیوری اور پروٹو ٹائپ تصدیق میں کیا فرق ہے؟

پروٹوٹائپ کی ترسیل کا مطلب ہے کہ بورڈز کو جمع اور موصول کیا گیا ہے. پروٹوٹائپ کی تصدیق کا مطلب ہے کہ ٹیم نے مطلوبہ تکنیکی سوال کا جواب دینے اور فیصلہ کرنے کے لیے ان بورڈز کا استعمال کیا ہے کہ آگے کیا ہوتا ہے۔

ایک پروٹوٹائپ بورڈ کو وقت پر کیوں پہنچایا جا سکتا ہے اور پھر بھی آہستہ آہستہ تصدیق کی جا سکتی ہے؟

کیونکہ سست روی اکثر مینوفیکچرنگ سے توثیق کی منطق، BOM کی وضاحت، متبادل-حصہ کی غیر یقینی صورتحال، ٹیسٹ کی تیاری، نظرثانی کنٹرول، اور کراس-فنکشنل الائنمنٹ میں بدل جاتی ہے۔

کیا تیز تر پروٹو ٹائپ اسمبلی کا مطلب خود بخود تیز تر تصدیق ہے؟

نہیں، تیز تر اسمبلی صرف اس صورت میں مدد کرتی ہے جب توثیق کا راستہ پہلے سے پہلے کے ہارڈویئر کو مؤثر طریقے سے استعمال کرنے کے لیے کافی واضح ہو۔

تصدیق میں تاخیر کی سب سے زیادہ نظر انداز کی جانے والی وجوہات میں سے ایک کیا ہے؟

ایک عام نظر انداز کی وجہ یہ ہے کہ تعمیراتی پیکج جاری کرنے کے لیے کافی مکمل تھا، لیکن بورڈز کے آنے کے بعد صاف طور پر توثیق کرنے کے لیے اتنا مکمل نہیں تھا۔