एवियोनिक्स सॉफ्टवेयर डेवलपमेंट

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

प्रविष्टि

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

विकास मॉडल

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


चित्रा 1. वी-आकार के विकास मॉडल।

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


चित्रा 2. सर्पिल सॉफ्टवेयर विकास-परीक्षण मॉडल

डिजाइन और प्रलेखन

प्रत्येक चरण को नियंत्रित करने और प्रमाणीकरण की बाद की संभावना के लिए, प्रक्रिया को विभिन्न स्तरों में विभाजित किया गया है, जिनमें से प्रत्येक का अपना दस्तावेज़ है, जिसके लिए एक दस्तावेज़ बनाया जाता है जो इसे नियंत्रित करता है (रिपोर्ट)। नतीजतन, विकास के प्रत्येक चरण, सभी त्रुटियों और सुधारों को वर्गीकृत और दस्तावेज किया जाता है। हर बार विकास के पुनरावृत्तियों को दोहराने से, त्रुटि की संभावना कम हो जाती है। ये दस्तावेज़ कंपनी के आंतरिक मानकों और ग्राहक द्वारा प्रस्तुत आवश्यकताओं के आधार पर भी बनाए जाते हैं।


अंजीर 3. दस्तावेजों और आवश्यकताओं का संबंध

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

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


चित्र 4. वी-आकार का मॉडल, वैधानिक दस्तावेजों के अनुसार चरणों में विभाजित

डिज़ाइन

संकल्पना

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

हार्डवेयर और सॉफ्टवेयर

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

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


चित्रा 5. सॉफ्टवेयर संगठन

ढांचा

तदनुसार, फ्रेमवर्क की सार्वभौमिक लाइब्रेरी में विमानन में उपयोग के लिए प्रमाणित उपकरणों के साथ-साथ प्रमाणित मानक कार्यों और प्रक्रियाओं के सभी प्रकार के ड्राइवर शामिल हैं।

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


चित्रा 6. परीक्षण क्लस्टर की वास्तुकला, विभिन्न नियंत्रण और विश्लेषण इंटरफेस का उपयोग करने की क्षमता के साथ *

सभी प्रकार के उपकरणों पर उपयोग के लिए, फ्रेमवर्क में DrvHigh <-> DrvLow संरचना के साथ ड्राइवर सेट शामिल हैं। यहाँ, DrHHigh पैकेज में डिवाइस ड्राइवर (फ़्लैश, इप्रोम मेमोरी, डिजिटल-से-एनालॉग, एनालॉग-टू-डिजिटल कन्वर्टर्स, रियल-टाइम क्लॉक, इंटरप्ट, CAN, ARINC, LAN चिप इत्यादि) के लिए सभी प्रकार के इंटरफेस शामिल हैं। बदले में, इनमें से प्रत्येक ड्राइवर इंटरफेस एक विशिष्ट डिवाइस (एक या किसी अन्य मेमोरी चिप, कनवर्टर, आदि) के लिए एक या अधिक ड्राइवरों का उपयोग कर सकता है। अनुकूलन उद्देश्यों के लिए, इस तरह के ड्राइवरों को पुन: कॉन्फ़िगर किया जाता है या यहां तक ​​कि सीधे DrHHigh स्तर के बिना उपयोग किया जाता है। शायद यह सबसे सुंदर समाधान नहीं है, लेकिन आवेदन कार्यक्रमों के विपरीत, कठिन वास्तविक समय एम्बेडेड सिस्टम के साथ काम करना, जहां "640k सभी के लिए पर्याप्त होना चाहिए" केवल एक काम नहीं है, बल्कि वास्तविकता है। अत्यधिक भरी हुई और दोष-सहिष्णु प्रणालियों के लिए, वास्तविक माइक्रोक्रिसिफ़्ट के चरम लोडिंग के रूप में हैं, डेटा ट्रांसफर बसों का 90-100% भार, चैनलों का समन्वय, उपकरणों और त्रुटि नियंत्रण के लिए इनपुट मापदंडों (फ्रेम निर्धारण) के आधार पर फ्रेम लोडिंग का समय निर्धारण (बहु-स्तरीय निगरानी सहित) स्थैतिक और दोलन त्रुटियों की पुष्टि), साथ ही साथ सभी सॉफ्टवेयर और डेटा ऑब्जेक्ट्स को 64-128kbytes के संस्करणों में डाल दिया।

प्रोग्रामिंग

आवश्यकताओं

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

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

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

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

इसके अलावा, डेवलपर के काम के लिए, जैसा कि मैंने पहले ही उल्लेख किया है, निम्न-स्तरीय आवश्यकताओं (एचएसआई, आईसीडी (इंटरफेस कम्युनिकेशन), डेटाशीट्स (डिवाइस के संचालन का वर्णन करने वाले दस्तावेज, डिवाइस निर्माताओं से (विभिन्न चिप्स के लिए) के रूप में) के ज्ञान की आवश्यकता हो सकती है।

प्रक्रिया है

विकास प्रक्रिया में स्वयं निम्नलिखित चरण होते हैं:

1. डिजाइन - डिजाइन (यूएमएल और / या मॉडलिंग प्रणाली में डिजाइन विकास (इस तरह के सॉफ़्टवेयर का उपयोग करना जैसे कि अमीस, एससीएडीई, सिमुलिंक, आदि) -
2. निम्न-स्तर की आवश्यकताएँ - परीक्षक के लिए कार्यान्वित आवश्यकता को हल करने के लिए कार्यक्षमता और एल्गोरिथ्म का वर्णन (ब्लैक बॉक्स मॉडल का उपयोग: इनपुट का विवरण और अपेक्षित प्रतिक्रिया)। यानी निम्न स्तर के विनिर्देश।
3. कोडिंग - कोड लिखने की प्रक्रिया सीधे (किसी भी चीज में, यदि आप एक स्वचालित कोड जनरेटर का उपयोग नहीं करते हैं, जैसा कि SCADE \ Matlab में है, क्योंकि विकास का वातावरण (IDE) किसी भी हो सकता है और किसी भी OS के तहत उपयोग किया जा सकता है (मैं ग्रहण, कोडब्लॉक का उपयोग करता हूं) , हालांकि अन्य समाधान निषिद्ध नहीं हैं)।
4. डिबगिंग - डिबगिंग प्रक्रिया, या बिना किसी त्रुटि के राज्य में प्रसंस्करण और असेंबली की प्रक्रिया (चयनित कंपाइलर के स्थापित मापदंडों के साथ त्रुटियां, चेतावनी) की अनुपस्थिति।
5. स्टेटिक चेक - कोड एनालाइज़र (xLite, Polyspace, MISRA, QAC) के आधार पर कोड की जाँच और सही करने की प्रक्रिया।
6. इंजीनियरिंग परीक्षण - एक सिम्युलेटर पर सॉफ्टवेयर लॉन्च करने और एकीकृत करने की प्रक्रिया (जो कि उपकरणों के एक प्रोटोटाइप पर है, जिसका अंतिम संस्करण बाद में उड़ान में स्थापित किया जाएगा, यदि संभव हो तो इंटरफेस और हेरफेर उपकरण हटा दिए जाएं) (आमतौर पर LabB + Trace32 डिबगर का एक गुच्छा)। कुछ मामलों में, सिम्युलेटर की कार्यक्षमता अतिरिक्त उपकरणों (सेंसर, ब्रेक सर्किट, सिग्नल जनरेटर, और यहां तक ​​कि पायलट की कलम, आदि जैसे नियंत्रण और निगरानी उपकरणों) को स्थापित करके विस्तारित की जाती है। बहुत कम मामलों में, कुछ नियंत्रण प्रणालियों के लिए, यह विमान के वास्तविक पूर्ण पैमाने पर बेंच मॉडल पर किया जा सकता है।
7. संस्करण नियंत्रण प्रणाली और रिपोर्ट (आईबीएम तर्कसंगत समाशोधन \ ClearQuest) में परिणाम दर्ज करना ।


अंजीर 7. "इलेक्ट्रॉनिक पक्षी" सुखोई सुपरजेट 100 *

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

विनिर्देश

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

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

परीक्षण

एक परीक्षक का काम लगभग आधा है, अगर सॉफ्टवेयर विकास के पूरे समय के 2 \ 3 नहीं। यह श्रमसाध्य और लंबा काम है, जिसमें शामिल हैं:

निम्न स्तर का परीक्षण

जिसमें शामिल हैं, बदले में:

• कोड की समीक्षा - प्रोग्रामिंग मानक के अनुपालन के लिए स्रोत कोड की समीक्षा, साथ ही कोड और आवश्यकताओं (एसडीडी) के अनुपालन के लिए।
• निम्न-स्तरीय परीक्षण - निम्न-स्तरीय परीक्षण, जैसे कि इकाई-परीक्षण और इकाई-एकीकरण-परीक्षण (रेज़रकोट टेसी + पर्यावरण और प्रोसेसर एमुलेटर), अर्थात्। मैककेबे मीट्रिक और संशोधित स्थिति / निर्णय कवरेज (नासा एमसीडीसी मानक का उपयोग करके) का उपयोग करके प्रत्यक्ष कोड आवश्यकताओं के आधार पर परीक्षण। यहां, सभी सीमा मानों की जांच की जाती है, साथ ही स्वीकार्य स्थितियों से बाहर निकलने के लिए प्रणाली की प्रतिक्रिया (अमान्य गणितीय संचालन, स्मृति के साथ संचालन, संकेत, सीमा से बाहर जाना, आदि) (मजबूती परीक्षण)।
• एक रिपोर्टिंग दस्तावेज़ बनाना (सॉफ़्टवेयर सत्यापन मामले और प्रक्रियाएँ / सॉफ़्टवेयर इकाई और एकीकरण सत्यापन मामले और प्रक्रियाएँ)।
• VoV (सत्यापन का सत्यापन) - सत्यापन सत्यापन प्रक्रिया, जो QAR (गुणवत्ता आश्वासन रिकॉर्ड) में दर्ज किए गए परिणामों के साथ परीक्षण और बनाए गए दस्तावेज़ की शुद्धता की पुष्टि करती है, जिसे बाद में त्रुटियों को सही करने के लिए अगले पुनरावृत्ति में उपयोग किया जाएगा (किसी अन्य परीक्षक द्वारा निष्पादित) )। , QAR , Iteration .

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


चित्रा 8. इलेक्ट्रॉनिक्स और संबंधित प्रणालियों के लिए टेस्ट बेंच *

उच्च स्तरीय परीक्षण

• दस्तावेज़ की समीक्षा (SWRD समीक्षा) - सिस्टम की आवश्यकताओं और विनिर्देशों के साथ-साथ हार्डवेयर-सॉफ़्टवेयर अनुपालन (ICD, HSI) के लिए त्रुटियों और परीक्षण क्षमता के लिए दस्तावेज़ की समीक्षा।
• Hardware-Software testing – , (), (, - - , ), Unit- ( , , \ ). Engineering , , , (Hardware/Software Integration Verification Cases and Procedures), , , .
• HwSw VoV – , , QAR (Quality Assurance Record), ( ).

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

प्रमाणपत्र

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

इस बिंदु पर, संपूर्ण परियोजना का ऑडिट और सत्यापन शुरू होता है, जिसके आधार पर अंतिम तीन दस्तावेज बनाए जाते हैं:

• पहली डिलीवरी की समीक्षा (FDR) - पैकेज वितरण दस्तावेज,
• पहली उड़ान की समीक्षा (FFR) - पहली उड़ान पर रिपोर्ट,
• सॉफ़्टवेयर प्रमाणन समीक्षा (SCR) - प्रमाणन आयोग का निर्णय।

स्वाभाविक रूप से, यदि इन चरणों में से एक पर समस्याएं आती हैं, तो एक स्थिति दूसरे (कम से कम) सॉफ्टवेयर प्रसंस्करण शुरू करने के लिए काफी संभव है। एक नियम के रूप में, प्रलेखन की प्रचुरता के कारण इस तरह के प्रमाणीकरण (यह लगभग 100-200 हजार पृष्ठों का है) विशेष रूप से निम्न स्तर पर चुनिंदा रूप से जांच की जाती है, और उच्च स्तर पर, ग्राहक के जवाब के अनुसार, प्रमाणन आयोग और परीक्षण पायलटों, संशोधन की आवश्यकताएं बनती हैं। एक नियम के रूप में, उड़ान निरीक्षण के चरणों की संख्या दो या तीन है, और प्रमाणन - 1-2।

निष्कर्ष

काम के विशाल मात्रा के लिए, अपेक्षाकृत सरल प्रणाली (टैक्सीिंग सिस्टम और लैंडिंग गियर) के विकास के लिए आवंटित समय 1.5-2 वर्ष है, सतह नियंत्रण प्रणाली (इलेक्ट्रिक एक्ट्यूएटर्स और हाइड्रोलिक सिस्टम) के लिए 5-6 वर्ष है। इस प्रकार, औसतन, एक प्रणाली 2-3 बड़े पुनरावृत्तियों (आधार रेखा) से बड़े और जटिल प्रणालियों के लिए 18-20 तक जाती है, और फ्रेमवर्क परत के लिए 40 से अधिक होती है।
रिपोर्टिंग प्रणालियों और परीक्षण रूटीनों की अत्यधिक जटिलता और बोझिलता के कारण, आउटसोर्सिंग संसाधन भारत में काम करने के लिए आकर्षित होते हैं, और चीन और पूर्वी यूरोप में अक्सर कम होते हैं। सभी प्रमाणीकरण, एक नियम के रूप में, उस क्षेत्र में होता है जहां प्रमाण पत्र वैध है (ईएएसए - यूरोप के लिए, एफएए - अमेरिका के लिए) और रूसी मानकों के लिए - रूस। उपकरण को अलग से प्रमाणित किया जाता है, या इसके पास पहले से ही अपना प्रमाण पत्र होना चाहिए, इसलिए, दुर्भाग्य से, या सौभाग्य से, अपेक्षाकृत "आउटडेटेड" मॉडल और समाधान जिन्हें तापमान, समय और आक्रामक परिचालन स्थितियों में परीक्षण किया गया है, का उपयोग विमानन में किया जाता है। विशाल जटिलता और मांग के बावजूद, इतने अच्छे विशेषज्ञ नहीं हैं, और यहां तक ​​कि अमेरिका और यूरोप में भी - इलेक्ट्रॉनिक नियंत्रण प्रणाली - बस शुरुआत की दिशा है, जो, ज़ाहिर है, जिसमें एक छोटा, लेकिन त्रुटियों का एक हिस्सा है ... हालांकि,डराने के लिए नहीं, हम अगली बार सुरक्षा और दोष-सहिष्णु वास्तुकला के बारे में बात करेंगे।

* Cosateq .