परिचय
कई ओईएम टीमें मानती हैं कि एक बार प्रोटोटाइप बोर्ड आ जाएं तो सत्यापन तेजी से हो जाएगा।
यह उचित लगता है. वास्तविक परियोजनाओं में, अक्सर ऐसा नहीं होता है।
एक प्रोटोटाइप पीसीबी असेंबली तय समय पर वापस आ सकती है और सत्यापन में अभी भी दिन या एक सप्ताह का समय बर्बाद हो सकता है, अगर टीम अभी भी इस बात पर बहस कर रही है कि निर्माण को क्या साबित करना था, बीओएम में क्या बदलाव हुआ, या क्या परीक्षण पथ उपयोगी उत्तर देने के लिए तैयार है। उस समय, मंदी अब केवल असेंबली लीड टाइम के बारे में नहीं है। यह एक रिलीज़, परीक्षण और हैंडऑफ़ समस्या बन जाती है।
इस लेख के पीछे असली सवाल यही है। मुद्दा केवल यह नहीं है कि प्रोटोटाइप कितनी तेजी से बनाया जा सकता है। मुद्दा यह है कि बोर्ड पहले से ही बेंच पर होने के बाद भी सत्यापन क्यों रुका हुआ है।
यदि आपकी टीम पहले से ही न्यूनतम बोर्ड टाइमिंग पार कर चुकी है और अब यह समझने की कोशिश कर रही है कि प्रोटोटाइप प्रगति अभी भी धीमी क्यों लगती है, तो केवल असेंबली से परे देखने और संपूर्ण पथ की समीक्षा करने का यही बिंदु हैपीसीबी असेंबली.
प्रोटोटाइप डिलीवरी और प्रोटोटाइप सत्यापन एक ही मील का पत्थर नहीं हैं
यहीं पर बहुत सारे शेड्यूल गलत पढ़े जाते हैं।
प्रोटोटाइप डिलीवरी का मतलब है कि बोर्ड तैयार, असेंबल और प्राप्त कर लिए गए हैं। प्रोटोटाइप सत्यापन का मतलब है कि टीम ने वास्तव में उन बोर्डों का उपयोग इच्छित तकनीकी प्रश्न का उत्तर देने और यह तय करने के लिए किया है कि आगे क्या होगा।
वे वही मील के पत्थर नहीं हैं।
एक बोर्ड समय पर आ सकता है और फिर भी परियोजना को आगे बढ़ाने में विफल हो सकता है। यह चालू हो सकता है, फिर भी यह महत्वपूर्ण परीक्षण पथ का समर्थन नहीं करता है। इसे सही ढंग से इकट्ठा किया जा सकता है, लेकिन फिर भी विकल्प, प्रोग्रामिंग धारणाएं, इंटरफ़ेस व्यवहार, या कौन सा संशोधन वास्तव में बेंच पर है, इसके बारे में संदेह पैदा होता है। कभी-कभी हार्डवेयर बिल्कुल भी समस्या नहीं होती है। टीम बस इस बात पर सहमत नहीं है कि क्या पास के रूप में गिना जाता है, क्या स्वीकार्य विचलन के रूप में गिना जाता है, और क्या एक और स्पिन को ट्रिगर करना चाहिए।
यही कारण है कि प्रोटोटाइप सत्यापन अक्सर डिलीवरी से पहले की बजाय डिलीवरी के बाद हो जाता है।
एक बोर्ड वास्तव में सत्यापन योग्य होने से पहले निर्माण योग्य हो सकता है।
जो आमतौर पर सत्यापन को धीमा कर देता है
प्रोटोटाइप सत्यापन तब धीमा हो जाता है जब टीम "प्राप्त बोर्ड" को ऐसे मानती है मानो इसका मतलब पहले से ही "निर्णय-तैयार हार्डवेयर" हो।
आमतौर पर, ऐसा नहीं होता.
कमज़ोर डेटा हैंडऑफ़
कुछ प्रोटोटाइप बिल्ड को बोर्ड के निर्माण के लिए पर्याप्त जानकारी के साथ जारी किया जाता है, लेकिन इसे स्पष्ट रूप से सत्यापित करने के लिए पर्याप्त जानकारी नहीं होती है।
गेरबर्स और एक बीओएम मौजूद हो सकते हैं। जो चीज़ अक्सर कमज़ोर होती है वह है उनके आस-पास की हर चीज़: प्रोग्रामिंग नोट्स, असेंबली इंटेंट, अनुमोदित विकल्प, फ़र्मवेयर धारणाएँ, ध्रुवीयता कॉलआउट, पास मानदंड और सत्यापन तर्क जो टीम को बताता है कि यह स्पिन वास्तव में क्या व्यवस्थित करने के लिए है।
इससे तुरंत घर्षण पैदा होता है।
बोर्ड आ गए हैं, लेकिन उन्हें मान्य करने की कोशिश कर रहे लोगों को अभी भी स्पष्टीकरण की आवश्यकता है। फिर हर अप्रत्याशित व्यवहार व्याख्या के दूसरे दौर में बदल जाता है। विधानसभा भवन की गति धीमी होने के कारण प्रोजेक्ट अवरुद्ध नहीं हुआ है. इसे अवरुद्ध कर दिया गया है क्योंकि बिल्ड पैकेज रिलीज़ करने के लिए पर्याप्त रूप से पूर्ण था, लेकिन तेज़ सीखने का समर्थन करने के लिए पर्याप्त रूप से पूर्ण नहीं था।
देर से डीएफएम निष्कर्ष
कुछ प्रोटोटाइप सत्यापन में देरी विद्युत विफलता के कारण नहीं होती है। वे विनिर्माण क्षमता के मुद्दों के कारण होते हैं जो डिज़ाइन के बहुत आगे बढ़ जाने के बाद ही स्पष्ट होते हैं।
फ़ुटप्रिंट बेमेल, कमज़ोर परीक्षण बिंदु पहुंच, टालने योग्य थर्मल समस्या, या असेंबली उन्मुख लेआउट विकल्प बोर्ड को बनने से नहीं रोक सकता है। एक बार रुक-रुक कर व्यवहार, सोल्डरिंग असंगतता, या जांच में कठिनाई होने पर यह सत्यापन को बुरी तरह से धीमा कर सकता है, जिससे वास्तविक डिज़ाइन प्रश्न अस्पष्ट हो जाता है।
यही कारण है कि प्रोटोटाइप कार्य में देर से डीएफएम मुद्दे महंगे होते हैं। वे अगली स्पिन में देरी नहीं करते। वे वर्तमान स्पिन के सीखने के मूल्य को भी कम करते हैं।
उपलब्धता-संचालित प्रतिस्थापन
एक प्रोटोटाइप बिल्ड पायलट लॉट की तुलना में अधिक सोर्सिंग लचीलेपन को सहन कर सकता है। यह सामान्य बात है।
समस्या तब शुरू होती है जब स्थानापन्न भागों को तेजी से चुना जाता है, लेकिन सत्यापन तर्क में स्पष्ट रूप से नहीं रखा जाता है। उस बिंदु पर, टीम अब एक साफ़ धारणा का परीक्षण नहीं कर रही है। यह डिज़ाइन और सोर्सिंग वर्कअराउंड का परीक्षण कर रहा है।
यह अंतर कई टीमों की अपेक्षा से कहीं अधिक मायने रखता है।
एक पिन{0}संगत विकल्प अभी भी स्टार्टअप व्यवहार, थर्मल प्रतिक्रिया, टाइमिंग मार्जिन, या सिग्नल विशेषताओं को इतना बदल सकता है कि ऊपर लाना जटिल हो जाए। सत्यापन तब धीमा हो जाता है क्योंकि टीम अपनी योजना से भिन्न प्रश्न का उत्तर देने का प्रयास कर रही है। परियोजना आंशिक रूप से डिबगिंग अभ्यास, आंशिक रूप से पुनः योग्यता अभ्यास बन जाती है।
परीक्षण तत्परता जो निर्माण तत्परता से पीछे रह गई
यह सबसे आम छिपी हुई बाधाओं में से एक है।
एक बोर्ड को समय पर असेंबल किया जा सकता है जबकि वास्तविक सत्यापन पथ बिल्कुल तैयार नहीं है। प्रोग्रामिंग फ़ाइलें अभी भी गतिमान हो सकती हैं. बेंच सेटअप अभी भी अनौपचारिक हो सकता है। फिक्स्चर अभी तक मौजूद नहीं हो सकते हैं. कार्यात्मक अपेक्षाएँ अभी भी अस्पष्ट हो सकती हैं। त्वरित निर्णयों का समर्थन करने के लिए पास/असफल तर्क भी बहुत ढीला हो सकता है।
उन मामलों में, पीसीबी असेंबली ने परियोजना को धीमा नहीं किया है। अंतर निर्माण पूर्णता और प्रयोग योग्य परीक्षण निष्पादन के बीच बैठता है।
एक AOI{{0}पूर्ण प्रोटोटाइप स्वचालित रूप से सत्यापन के लिए तैयार प्रोटोटाइप नहीं है।
मैन्युअल जांच बाधा बनने लगती है
कुछ बहुत शुरुआती बोर्डों के लिए मैन्युअल जांच ठीक है।
यह कई टीमों की अपेक्षा से कहीं अधिक तेजी से खींचतान बन जाता है।
एक बार जब बोर्ड सघन हो जाता है, पहुंच खराब हो जाती है, या यूनिट की गिनती मुट्ठी भर नमूनों से अधिक हो जाती है, तो मैन्युअल सत्यापन प्रत्येक बोर्ड को अपनी छोटी जांच में बदलना शुरू कर देता है। टीम को अभी भी उत्तर मिल सकते हैं, लेकिन वह उन्हें अधिक धीरे-धीरे, अधिक बार-बार जांच के साथ, और इस बात पर अधिक निर्भरता के साथ प्राप्त करती है कि जांच कौन कर रहा है।
यही कारण है कि सरल विकास फिक्स्चर, बेहतर जांच पहुंच, या अधिक संरचित लाने का रास्ता प्रोटोटाइप चरणों में भी मायने रख सकता है। लक्ष्य बहुत जल्दी पूर्ण उत्पादन स्थिरता तैयार करना नहीं है। इसका लक्ष्य टाली जा सकने वाली भौतिक पहुंच समस्याओं पर सत्यापन समय बर्बाद करना बंद करना है।
एक बिल्ड बहुत सारे प्रश्नों का उत्तर देने का प्रयास कर रहा है
कुछ प्रोटोटाइप लॉट धीरे-धीरे चलते हैं क्योंकि निर्माण का दायरा बहुत व्यापक है।
बोर्ड से अपेक्षा की जाती है कि वह हार्डवेयर फ़ंक्शन, सॉफ़्टवेयर व्यवहार, पावर स्थिरता, सिग्नल अखंडता, थर्मल, विनिर्माण क्षमता, फ़ील्ड व्यवहार और शायद प्रारंभिक अनुपालन मान्यताओं को भी एक साथ मान्य कर दे। सिद्धांत रूप में यह कारगर लगता है। व्यवहार में इसका मतलब यह है कि कोई भी खुला प्रश्न साफ-साफ बंद नहीं होता।
एक केंद्रित प्रोटोटाइप आमतौर पर उस बिल्ड की तुलना में तेजी से सत्यापन करता है जो एक ही बार में सब कुछ व्यवस्थित करने की कोशिश कर रहा है।
प्रोटोटाइप कार्य में, शेड्यूल अक्सर सबसे धीमे अनसुलझे प्रश्न के साथ चलता है, न कि केवल सबसे धीमे भौतिक चरण के साथ।
जहां ओईएम टीमें आमतौर पर समस्या का गलत आकलन करती हैं
सबसे आम गलती यह मान लेना है कि देरी अभी भी विनिर्माण से संबंधित है।
कभी-कभी ऐसा होता है. अक्सर ऐसा नहीं होता.
एक बार जब बोर्ड पहले से ही बेंच पर हैं, तो वास्तविक बाधा आमतौर पर सत्यापन तर्क, संशोधन नियंत्रण, सोर्सिंग स्पष्टता और परीक्षण अनुक्रमण में बदल जाती है। प्रोजेक्ट अभी भी धीमा लगता है, लेकिन यह अब उसी कारण से धीमा नहीं है, जिस कारण से निर्माण के शिप होने से पहले यह धीमा था।
यह अंतर मायने रखता है क्योंकि टीमें अक्सर गलत समस्या पर प्रतिक्रिया करती हैं। जब उन्हें वास्तव में एक सख्त सत्यापन उद्देश्य, एक स्वच्छ पुनरीक्षण आधार रेखा, या एक परीक्षण पथ की आवश्यकता होती है, जो अधिक चर्चा उत्पन्न करने के बजाय वास्तव में निर्णयों का समर्थन कर सकता है, तो वे तेजी से अगले चरण के निर्माण पर जोर देते हैं।
यदि टीम अभी भी इस बात पर बहस कर रही है कि उसे वास्तव में क्या साबित करना है तो एक बोर्ड तय समय पर वापस आ सकता है और फिर भी सत्यापन में एक सप्ताह का समय बर्बाद कर सकता है।
एक उपयोगी सीमा मामला
एक छोटे प्रोटोटाइप लॉट का स्वचालित रूप से यह मतलब नहीं है कि सत्यापन तेज़ होना चाहिए।
यदि प्रत्येक इकाई में अनसुलझे सोर्सिंग परिवर्तन, अस्पष्ट परीक्षण उद्देश्य और मिश्रित संशोधन धारणाएँ होती हैं, तो एक दस{0}}बोर्ड बिल्ड अभी भी धीरे-धीरे सत्यापित हो सकता है। यदि फ़र्मवेयर बेसलाइन एक ही समय में चल रही है और सत्यापन योजना कभी भी पर्याप्त रूप से सीमित नहीं की गई है, तो पाँच - बोर्ड स्पिन भी खींच सकता है।
दूसरी ओर, यदि बीओएम साफ-सुथरा है, प्रश्न संकरा है और ऊपर लाने का पथ पहले से ही संरचित है, तो कुछ हद तक बड़ा समूह तेजी से सत्यापन कर सकता है।
यही कारण है कि अकेले बोर्ड गिनती सत्यापन गति का एक खराब भविष्यवक्ता है।
सत्यापन को तेजी से आगे बढ़ने में क्या मदद करता है
यदि लक्ष्य प्रोटोटाइप सत्यापन को छोटा करना है, तो सबसे बड़ा सुधार आमतौर पर अगला निर्माण शुरू होने से पहले किया जाता है।
सत्यापन प्रश्न को पहले लॉक करें
एक प्रोटोटाइप तेजी से सत्यापित होता है जब टीम को पता होता है कि इस स्पिन को क्या साबित करना है, और उतना ही महत्वपूर्ण यह है कि उसे क्या साबित नहीं करना है।
सोर्सिंग परिवर्तन दृश्यमान रखें
यदि उपलब्धता संचालित प्रतिस्थापनों का उपयोग किया गया था, तो उन्हें बिल्ड रिकॉर्ड में स्पष्ट होना चाहिए और सत्यापन के दौरान चर्चा करना आसान होना चाहिए। छिपे हुए सोर्सिंग परिवर्तन धीमी गति से सीखने का कारण बनते हैं।
डेटा पैकेज को परीक्षण पथ के साथ संरेखित करें
बीओएम संशोधन, असेंबली आउटपुट, फ़र्मवेयर संस्करण, प्रोग्रामिंग धारणाएं, और ऊपर लाने वाली चेकलिस्ट सभी को एक ही इच्छित आधार रेखा की ओर इशारा करना चाहिए।
बोर्ड आने से पहले परीक्षण पथ तैयार करें
प्रोग्रामिंग, बेंच सेटअप, पास मानदंड, और किसी भी साधारण फिक्स्चर कार्य के लिए तब तक इंतजार नहीं करना चाहिए जब तक कि असेंबली पहले से ही हाथ में न हो।
डीएफएम और परीक्षण पहुंच को सत्यापन तत्परता के मुद्दों के रूप में मानें
यदि परीक्षण पहुंच खराब है या विनिर्माण क्षमता के जोखिम अभी भी अनसुलझे हैं, तो सत्यापन शायद ही कभी साफ रहेगा, चाहे बोर्ड कितनी भी जल्दी क्यों न बनाए गए हों।
यह बिल्कुल वही है जहां के संदर्भ में सोचा जा रहा हैपरीक्षण एवं निरीक्षणप्रोटोटाइप चरण में भी उपयोगी हो जाता है।
वर्तमान परिवेश में यह अधिक क्यों मायने रखता है?
वर्तमान सोर्सिंग परिवेश में, उपलब्धता-संचालित प्रतिस्थापन अधिक सामान्य हैं, और लीड-समय राहत विभिन्न श्रेणियों में असमान है। जब भी सत्यापन योजना में भौतिक परिवर्तन स्पष्ट रूप से प्रतिबिंबित नहीं होते हैं तो इससे प्रोटोटाइप सत्यापन धीमा हो जाता है। बोर्ड अभी भी समय पर आ सकता है। सीखने का मार्ग प्रायः नहीं चलता।
यह एक और कारण है कि प्रोटोटाइप सत्यापन को अपने स्वयं के इंजीनियरिंग और समन्वय चरण के रूप में माना जाना चाहिए, न कि केवल असेंबली लीड समय के अंतिम छोर के रूप में।
निष्कर्ष
पीसीबी असेंबली परियोजनाओं में प्रोटोटाइप सत्यापन अक्सर बोर्ड आने के बाद क्या होता है उससे धीमा हो जाता है, न कि केवल इस बात से कि वे कितनी तेजी से बनाए गए थे।
सबसे आम कारण हैं कमजोर डेटा हैंडऑफ़, देर से डीएफएम निष्कर्ष, उपलब्धता संचालित प्रतिस्थापन, खराब परीक्षण तैयारी, मैन्युअल जांच घर्षण, पुनरीक्षण बहाव, और सत्यापन लक्ष्य जो एक स्पिन के लिए स्पष्ट रूप से उत्तर देने के लिए बहुत व्यापक हैं।
ये सभी विनिर्माण समस्याएं नहीं हैं। उनमें से कई शुद्ध विनिर्माण समस्याओं से पहले रिलीज़, परीक्षण और हैंडऑफ़ समस्याएं हैं।
इसीलिए टीमों को "प्रोटोटाइप डिलीवर" के साथ ऐसा व्यवहार करना बंद कर देना चाहिए जैसे कि इसका मतलब "प्रोटोटाइप सत्यापित" है।
बेंच पर लगे बोर्ड अपने आप शेड्यूल को छोटा नहीं करते हैं। एक प्रयोग करने योग्य सत्यापन पथ करता है.
यदि आपकी टीम प्रोटोटाइप सत्यापन को छोटा करने का प्रयास कर रही है, तो अगला व्यावहारिक कदम बिल्ड की समीक्षा करना हैपीसीबी असेंबली,के सही स्तर के साथ सत्यापन पथ को मजबूत करेंपरीक्षण एवं निरीक्षणसोच, और फिर अगले प्रोटोटाइप दायरे को संरेखित करेंएक उद्धरण का अनुरोध करेंया सीधे टीम से संपर्क करेंinfo@pcba-china.com.
अक्सर पूछे जाने वाले प्रश्न
प्रोटोटाइप डिलीवरी और प्रोटोटाइप सत्यापन के बीच क्या अंतर है?
प्रोटोटाइप डिलीवरी का मतलब है कि बोर्ड इकट्ठे और प्राप्त कर लिए गए हैं। प्रोटोटाइप सत्यापन का मतलब है कि टीम ने उन बोर्डों का उपयोग इच्छित तकनीकी प्रश्न का उत्तर देने और यह तय करने के लिए किया है कि आगे क्या होगा।
एक प्रोटोटाइप बोर्ड समय पर क्यों वितरित किया जा सकता है और फिर भी धीरे-धीरे सत्यापित किया जा सकता है?
क्योंकि मंदी अक्सर विनिर्माण से सत्यापन तर्क, बीओएम स्पष्टता, स्थानापन्न भाग अनिश्चितता, परीक्षण तैयारी, पुनरीक्षण नियंत्रण और क्रॉस-कार्यात्मक संरेखण तक स्थानांतरित हो जाती है।
क्या तेज़ प्रोटोटाइप असेंबली का मतलब स्वचालित रूप से तेज़ सत्यापन है?
नहीं, तेज़ असेंबली केवल तभी मदद करती है जब सत्यापन पथ पहले से ही पुराने हार्डवेयर का प्रभावी ढंग से उपयोग करने के लिए पर्याप्त स्पष्ट हो।
सत्यापन में देरी के सबसे अधिक नजरअंदाज किए गए कारणों में से एक क्या है?
एक सामान्य अनदेखा कारण यह है कि बिल्ड पैकेज रिलीज़ करने के लिए पर्याप्त रूप से पूरा था, लेकिन बोर्ड आने के बाद सफाई से सत्यापित करने के लिए पर्याप्त रूप से पूरा नहीं हुआ था।
