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

एवियोनिक्स सॉफ्टवेयर नियमित रूप से अनिवार्य सुरक्षा और विश्वसनीयता संबंधी विचारों के साथ एम्बेडेड सॉफ्टवेयर है। जिसका उपयोग एवियोनिक्स में किया जाता है। एवियोनिक सॉफ़्टवेयर और पारंपरिक एम्बेडेड सॉफ्टवेयर के मध्य मुख्य अंतर यह है कि विकास प्रक्रिया नियम द्वारा आवश्यक है और सुरक्षा के लिए अनुकूलित है। यह आशय किया जाता है कि नीचे वर्णित प्रक्रिया वाणिज्यिक सॉफ्टवेयर के लिए उपयोग की जाने वाली सामान्य तदर्थ प्रक्रियाओं की तुलना में केवल थोड़ी धीमी और अधिक व्यय (संभवतः 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)