एवियोनिक्स सॉफ्टवेयर

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

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

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

सामान्य अवलोकन

चूंकि अधिकांश एवियोनिक्स निर्माता सॉफ्टवेयर को भार बढ़ाए बिना मूल्य जोड़ने की विधि के रूप में देखते हैं, इसलिए एवियोनिक प्रणाली में एम्बेडेड सॉफ़्टवेयर का महत्व बढ़ रहा है।

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

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

विनियामक मुद्दे

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

युनाइटेड स्टेट्स|यू.एस. में, एवियोनिक और अन्य एयरक्राफ्ट घटकों में संघीय उड्डयन विनियम, परिवहन हवाई जहाजों के लिए भाग 25, छोटे हवाई जहाजों के लिए भाग 23, और रोटरक्राफ्ट के लिए भाग 27 और 29 द्वारा अनिवार्य सुरक्षा और विश्वसनीयता मानक हैं। इन मानकों को संघीय उड्डयन प्रशासन के नामित इंजीनियरिंग प्रतिनिधियों द्वारा लागू किया जाता है, जिन्हें आम तौर पर निर्माता द्वारा भुगतान किया जाता है और एफएए द्वारा प्रमाणित किया जाता है।

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

सुरक्षा और विश्वसनीयता सुनिश्चित करने के लिए, राष्ट्रीय नियामक प्राधिकरणों (जैसे एफएए, सिविल एरोनॉटिक्स एडमिनिस्ट्रेशन (संयुक्त राज्य अमेरिका), या संयुक्त राज्य रक्षा विभाग) को सॉफ्टवेयर विकास मानकों की आवश्यकता होती है। कुछ प्रतिनिधि मानकों में सैन्य प्रणालियों के लिए MIL-STD-2167, या नागरिक एयरक्राफ्टों के लिए RTCA DO-178B और इसके उत्तराधिकारी DO-178C शामिल हैं।

इस सॉफ़्टवेयर के लिए नियामक आवश्यकताएँ अन्य सॉफ़्टवेयर की तुलना में महंगी हो सकती हैं, किंतु वे आमतौर पर न्यूनतम हैं जो आवश्यक सुरक्षा उत्पन्न करने के लिए आवश्यक हैं।

विकास प्रक्रिया

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

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

किसी विशिष्ट परियोजना से यहां वर्णित प्रक्रियाओं में विचलन वैकल्पिक विधियों के उपयोग या निम्न सुरक्षा स्तर की आवश्यकताओं के कारण हो सकता है।

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

मानव इंटरफेस

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

जोखिम विश्लेषण

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

सैन्य क्रिप्टोग्राफ़िक सुरक्षा से जुड़ी परियोजनाओं में आम तौर पर सुरक्षा विश्लेषण शामिल होता है, जिसमें खतरनाक विश्लेषण जैसी विधियों का उपयोग किया जाता है।

रखरखाव मैनुअल

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

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

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

डिजाइन और विनिर्देश दस्तावेज

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

कोड उत्पादन और समीक्षा

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

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

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

यूनिट परीक्षण

100% कोड कवरेज़  प्राप्त करने के लिए कम से कम  बार कोड के प्रत्येक निर्देश का प्रयोग करने के लिए यूनिट टेस्ट कोड लिखा जाता है।  कवरेज टूल का उपयोग प्रायः यह सत्यापित करने के लिए किया जाता है कि प्रत्येक निर्देश निष्पादित किया गया है, और फिर नियमी कारणों से परीक्षण कवरेज को भी प्रलेखित किया गया है।

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

ता परीक्षण

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

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

कुछ कार्यक्रम प्रबंधक इस ीकरण प्रक्रिया को व्यवस्थित करने का प्रयास करते हैं ताकि कुछ न्यूनतम स्तर के कार्य को प्राप्त करने के बाद, समय बीतने के साथ-साथ सुविधाओं की बढ़ती संख्या के साथ प्रणाली किसी भी बाद की तारीख में सुपुर्दगी योग्य हो जाए।

ब्लैक बॉक्स और स्वीकृति परीक्षण

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

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

प्रमाणन

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

यह भी देखें

• अनुलग्नक: एवियोनिक्स में परिवर्णी शब्द और संक्षिप्त रूप
• डीओ-178बी
• सॉफ्टवेयर विकास मॉडल
• जोखिम विश्लेषण
• 10 की शक्ति: सुरक्षा-महत्वपूर्ण कोड विकसित करने के नियम

बाहरी संबंध

• Generic Avionics Software Specification from the Software Engineering Institute (SEI)