हमारी फर्मवेयर विकास प्रक्रिया पांच-चरणीय दृष्टिकोण पर आधारित है

पिछले कुछ वर्षों में, हमने सफल, लंबे समय तक चलने वाले उत्पादों और उत्पाद परिवारों के लिए फर्मवेयर विकसित करते समय सॉफ्टवेयर विकास टीमों के साथ व्यापक परामर्श और प्रशिक्षण आयोजित किया है। जबकि मजबूत फर्मवेयर आर्किटेक्चर बनाना और विरासत सॉफ्टवेयर को फिर से तैयार करना एक जटिल, महीनों लंबी प्रक्रिया हो सकती है, हमने पाँच प्रमुख चरणों की पहचान की है जो एक कदम-दर-कदम दृष्टिकोण बनाते हैं, जिससे हमारी टीम सही रास्ते पर शुरू करने में सक्षम होती है।

चरण 1: आवश्यकताएँ परिभाषित करें

एम्बेडेड सिस्टम या उसके फ़र्मवेयर को डिज़ाइन करने से पहले, स्पष्ट आवश्यकताएँ आवश्यक हैं। अच्छी तरह से परिभाषित आवश्यकताएँ निर्दिष्ट करती हैं कि उत्पाद उपयोगकर्ता के लिए क्या करेगा, बिना यह बताए कि इन उद्देश्यों को कैसे प्राप्त किया जाएगा। यह आवश्यक है कि प्रत्येक आवश्यकता कथन स्पष्ट और परीक्षण योग्य हो। एक स्पष्ट कथन स्पष्ट और संक्षिप्त होता है, जिसके लिए किसी और स्पष्टीकरण की आवश्यकता नहीं होती है।

परीक्षण योग्यता एक महत्वपूर्ण कारक है; एक अच्छी तरह से लिखी गई आवश्यकता को इसकी पूर्ति को सत्यापित करने के लिए सीधे परीक्षण निर्माण की अनुमति देनी चाहिए। आवश्यकताओं के एक उचित सेट में '[उत्पाद] को ...' से शुरू होने वाले कथन शामिल होते हैं, जो इस बात पर ध्यान केंद्रित करते हैं कि इसे कैसे प्राप्त किया जाए, इसके बजाय क्या आवश्यक है, और स्पष्टता और परीक्षण योग्यता सुनिश्चित करना। नतीजतन, प्रभावी वास्तुकला अच्छी तरह से परिभाषित आवश्यकताओं पर निर्भर करती है।

चरण 2: वास्तुकला और डिजाइन के बीच अंतर करें

हमारा अनुभव रहा है कि कई इंजीनियरों और उनके प्रबंधकों को फ़र्मवेयर इंजीनियरिंग के विभिन्न पहलुओं के बीच अंतर करने में कठिनाई होती है। सिस्टम आर्किटेक्चर HOW के उच्चतम स्तर का प्रतिनिधित्व करता है, जो उत्पाद की स्थायी विशेषताओं को परिभाषित करता है और एक बार स्थापित होने के बाद इसे बदलना चुनौतीपूर्ण बनाता है। यह सुनिश्चित करने के लिए कि यह सही तरीके से किया गया है, उत्पाद के इच्छित और अनुमेय उपयोगों पर सावधानीपूर्वक विचार करने की आवश्यकता है।

सिस्टम का डिज़ाइन कैसे की मध्यवर्ती परत का प्रतिनिधित्व करता है। जबकि आर्किटेक्चर व्यापक विशेषताओं को रेखांकित करता है, यह फ़ंक्शन या चर नाम निर्दिष्ट नहीं करता है। एक फ़र्मवेयर डिज़ाइन दस्तावेज़ इन विवरणों को भरता है, जिसमें विशिष्ट सबसिस्टम या डिवाइस ड्राइवर के भीतर कार्य नाम और ज़िम्मेदारियाँ, उपयोग किए गए RTOS (यदि कोई हो), और सबसिस्टम के बीच इंटरफ़ेस की विशिष्टताएँ शामिल हैं।

कार्यान्वयन चरण परियोजना प्रबंधन पदानुक्रम के निम्नतम स्तर का प्रतिनिधित्व करता है। जब डिज़ाइन चरण में इंटरफ़ेस स्पष्ट रूप से परिभाषित किए जाते हैं, तो इंजीनियर समानांतर रूप से विभिन्न घटकों को लागू करना शुरू कर सकते हैं। जबकि चुनौतियाँ उद्योग के अनुसार अलग-अलग हो सकती हैं, वे आम तौर पर तीन मुख्य श्रेणियों में आती हैं: वास्तविक समय की समयसीमा को पूरा करना, परीक्षण करना और विविधता का प्रबंधन करना। इन मुद्दों को अंतिम तीन चरणों में संबोधित किया जाता है।

चरण 3: समय प्रबंधन

कुछ उत्पाद आवश्यकताएँ स्पष्ट समय सीमाएँ निर्दिष्ट करेंगी। आम तौर पर, उत्पादों में गैर-वास्तविक-समय, सॉफ्ट-वास्तविक-समय और हार्ड-वास्तविक-समय आवश्यकताओं का संयोजन शामिल होता है। इनमें से, सॉफ्ट डेडलाइन को स्पष्ट रूप से परिभाषित करना, परीक्षण करना और लागू करना अक्सर सबसे चुनौतीपूर्ण होता है। एक बार डेडलाइन की पहचान हो जाने के बाद, आर्किटेक्चरल प्रक्रिया में पहला कदम सॉफ़्टवेयर से हार्डवेयर तक जितनी संभव हो उतनी समय-संवेदनशील आवश्यकताओं को उतारना है।

मुख्य सॉफ़्टवेयर से वास्तविक समय की कार्यक्षमता को अलग करने से दो मुख्य लाभ मिलते हैं। सबसे पहले, यह गैर-वास्तविक समय सॉफ़्टवेयर के डिज़ाइन और कार्यान्वयन को सरल बनाता है। कोड के थोक से समय की बाधाओं को हटाकर, नौसिखिए डेवलपर्स भी उपयोगकर्ता सुरक्षा से समझौता किए बिना योगदान दे सकते हैं। दूसरा, वास्तविक समय की कार्यक्षमता को समेकित करने से विश्लेषण करना और यह सुनिश्चित करना आसान हो जाता है कि सभी समय सीमाएँ लगातार पूरी हों।

चरण 4: परीक्षण को ध्यान में रखते हुए डिज़ाइन करें

प्रत्येक एम्बेडेड सिस्टम का कई स्तरों पर परीक्षण करना आवश्यक है। कई मामलों में, विभिन्न स्तरों पर परीक्षण न केवल मूल्यवान है बल्कि अनिवार्य भी है।

परीक्षण के सबसे सामान्य स्तरों में शामिल हैं

1. सिस्टम परीक्षणों ने पुष्टि की है कि उत्पाद समग्र रूप से निर्दिष्ट आवश्यकताओं को पूरा करता है या उससे अधिक है। यह अनुशंसा की जाती है कि इन परीक्षणों को इंजीनियरिंग विभाग के बाहर विकसित किया जाए, हालांकि उन्हें इंजीनियरों द्वारा डिज़ाइन किए गए परीक्षण हार्नेस में शामिल किया जा सकता है।

2. एकीकरण परीक्षण यह सुनिश्चित करने के लिए किए जाते हैं कि आर्किटेक्चर आरेखों में उल्लिखित उप-प्रणालियों के उपसमूह ठीक से परस्पर क्रिया करते हैं और अपेक्षित परिणाम देते हैं। ये परीक्षण आम तौर पर सॉफ़्टवेयर इंजीनियरिंग विभाग के भीतर एक परीक्षण टीम या व्यक्ति द्वारा विकसित किए जाते हैं।

3. यूनिट परीक्षण यह गारंटी देते हैं कि मध्यवर्ती डिज़ाइन चरण में परिभाषित व्यक्तिगत सॉफ़्टवेयर घटक, इच्छित तरीके से काम करते हैं। ये परीक्षण सार्वजनिक API (एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस) पर ध्यान केंद्रित करते हैं जो घटक अन्य घटकों को प्रदान करता है। आम तौर पर, यूनिट परीक्षण उन्हीं व्यक्तियों द्वारा विकसित किए जाते हैं जो परीक्षण किए जा रहे कोड को लिखते हैं।

तीन प्रकार के परीक्षणों में से, सिस्टम परीक्षण विकसित करने के लिए सबसे सरल हैं। इंजीनियरिंग और फ़ैक्टरी स्वीकृति परीक्षणों के लिए एक परीक्षण हार्नेस की आवश्यकता हो सकती है, लेकिन यह प्रक्रिया आम तौर पर एकीकरण और इकाई परीक्षणों की तुलना में सरल होती है, जिसके लिए डिवाइस के संचालन में अधिक आंतरिक दृश्यता की आवश्यकता होती है। एकीकरण और इकाई परीक्षणों के विकास, उपयोग और रखरखाव को सुव्यवस्थित करने के लिए, फ़र्मवेयर को इस तरह से डिज़ाइन करना उचित है जो सॉफ़्टवेयर परीक्षण ढांचे के साथ संरेखित हो। सबसे प्रभावी तरीका यह है कि आप जिस स्तर पर परीक्षण करना चाहते हैं, उस स्तर पर सभी सॉफ़्टवेयर घटकों के बीच इंटरैक्शन की संरचना करें।

चरण 5: बदलाव के लिए तैयार रहें

फर्मवेयर आर्किटेक्चर चरण के दौरान, फीचर विविधता और उत्पाद अनुकूलन के प्रबंधन को प्राथमिकता देना आवश्यक है। परिवर्तन के लिए प्रभावी रूप से योजना बनाने के लिए, सबसे पहले उन परिवर्तनों के प्रकारों की पहचान करना महत्वपूर्ण है जो आपके उत्पाद में होने की संभावना है। फिर, फर्मवेयर को इन परिवर्तनों को यथासंभव सबसे कुशल तरीके से समायोजित करने के लिए डिज़ाइन किया जाना चाहिए। एक अच्छी तरह से डिज़ाइन किया गया आर्किटेक्चर कंपाइल-टाइम और/या रन-टाइम स्विच के साथ एकल बिल्ड के माध्यम से फीचर विविधता के प्रबंधन की अनुमति देता है, साथ ही मौजूदा कार्यक्षमता को बाधित किए बिना नई सुविधाओं को सहजता से जोड़ने में सक्षम बनाता है।