एवियोनिक्स सॉफ्टवेयर: Difference between revisions
(Created page with "{{Short description|Embedded software with legally mandated safety and reliability concerns}} {{multiple issues| {{more citations needed|date=August 2021}} {{original research...") |
No edit summary |
||
| Line 1: | Line 1: | ||
{{Short description|Embedded software with legally mandated safety and reliability concerns}} | {{Short description|Embedded software with legally mandated safety and reliability concerns}}[[ वैमानिकी |वैमानिकी]] सॉफ्टवेयर कानूनी रूप से अनिवार्य [[विमानन सुरक्षा]] और एवियोनिक्स में उपयोग की जाने वाली विश्वसनीयता इंजीनियरिंग चिंताओं के साथ [[ अंतः स्थापित प्रणाली ]] है। एवियोनिक सॉफ़्टवेयर और पारंपरिक एम्बेडेड सॉफ़्टवेयर के बीच मुख्य अंतर यह है कि सॉफ़्टवेयर विकास मॉडल ''क़ानून द्वारा आवश्यक'' है और ''सुरक्षा के लिए अनुकूलित'' है। | ||
यह दावा किया जाता है कि नीचे वर्णित [[सॉफ्टवेयर विकास प्रक्रिया]] वाणिज्यिक [[कंप्यूटर सॉफ्टवेयर]] के लिए उपयोग की जाने वाली सामान्य ''तदर्थ'' प्रक्रियाओं की तुलना में केवल थोड़ी धीमी और अधिक महंगी (शायद 15 प्रतिशत) है। चूँकि अधिकांश सॉफ़्टवेयर गलतियों के कारण विफल हो जाते हैं, गलतियों को जल्द से जल्द समाप्त करना भी सॉफ़्टवेयर बनाने का अपेक्षाकृत सस्ता और विश्वसनीय तरीका है। हालांकि कुछ परियोजनाओं में, तैनाती तक विनिर्देशों में गलतियों का पता नहीं लगाया जा सकता है। उस समय, उन्हें ठीक करना बहुत महंगा हो सकता है। | |||
किसी भी [[ सॉफ्टवेयर विकास मॉडल ]] का मूल विचार यह है कि डिजाइन प्रक्रिया के प्रत्येक चरण में आउटपुट होते हैं जिन्हें डिलिवरेबल्स कहा जाता है। {{Citation needed|date=July 2011}} यदि सुपुर्दगी की शुद्धता के लिए परीक्षण किया जाता है और तय किया जाता है, तो सामान्य मानवीय गलतियाँ आसानी से खतरनाक या महंगी समस्याओं में विकसित नहीं हो सकती हैं। अधिकांश निर्माता{{Citation needed|date=July 2011}} डिज़ाइन उत्पाद को समन्वयित करने के लिए [[झरना मॉडल]] का पालन करें, लेकिन लगभग सभी स्पष्ट रूप से पहले के काम को संशोधित करने की अनुमति देते हैं। परिणाम अधिक बार [[सर्पिल मॉडल]] के करीब होता है। | |||
किसी भी [[ सॉफ्टवेयर विकास मॉडल ]] का मूल विचार यह है कि डिजाइन प्रक्रिया के प्रत्येक चरण में आउटपुट होते हैं जिन्हें डिलिवरेबल्स कहा जाता है। {{Citation needed|date=July 2011}} यदि सुपुर्दगी की शुद्धता के लिए परीक्षण किया जाता है और तय किया जाता है, तो सामान्य मानवीय गलतियाँ आसानी से खतरनाक या महंगी समस्याओं में विकसित नहीं हो सकती हैं। अधिकांश निर्माता{{Citation needed|date=July 2011}} डिज़ाइन उत्पाद को समन्वयित करने के लिए [[झरना मॉडल]] का पालन करें, लेकिन लगभग सभी स्पष्ट रूप से पहले के काम को संशोधित करने की अनुमति देते हैं। परिणाम अधिक बार | |||
एम्बेडेड सॉफ़्टवेयर के अवलोकन के लिए एम्बेडेड सिस्टम और सॉफ़्टवेयर डेवलपमेंट मॉडल देखें। इस लेख का शेष भाग उस जानकारी से परिचित होने का अनुमान लगाता है, और वाणिज्यिक एम्बेडेड सिस्टम और व्यावसायिक विकास मॉडल के बीच अंतर पर चर्चा करता है। | एम्बेडेड सॉफ़्टवेयर के अवलोकन के लिए एम्बेडेड सिस्टम और सॉफ़्टवेयर डेवलपमेंट मॉडल देखें। इस लेख का शेष भाग उस जानकारी से परिचित होने का अनुमान लगाता है, और वाणिज्यिक एम्बेडेड सिस्टम और व्यावसायिक विकास मॉडल के बीच अंतर पर चर्चा करता है। | ||
| Line 19: | Line 11: | ||
ऑटो-पायलट वाले अधिकांश आधुनिक वाणिज्यिक विमान उड़ान कंप्यूटर और तथाकथित उड़ान प्रबंधन प्रणाली (FMS) का उपयोग करते हैं जो उड़ान के कुछ चरणों के दौरान पायलट के सक्रिय हस्तक्षेप के बिना विमान को उड़ा सकते हैं। इसके अलावा विकास या उत्पादन के तहत मानव रहित वाहन हैं: मिसाइल और ड्रोन जो हवाई पायलट के हस्तक्षेप के बिना उड़ान भर सकते हैं, क्रूज और जमीन पर उतर सकते हैं। | ऑटो-पायलट वाले अधिकांश आधुनिक वाणिज्यिक विमान उड़ान कंप्यूटर और तथाकथित उड़ान प्रबंधन प्रणाली (FMS) का उपयोग करते हैं जो उड़ान के कुछ चरणों के दौरान पायलट के सक्रिय हस्तक्षेप के बिना विमान को उड़ा सकते हैं। इसके अलावा विकास या उत्पादन के तहत मानव रहित वाहन हैं: मिसाइल और ड्रोन जो हवाई पायलट के हस्तक्षेप के बिना उड़ान भर सकते हैं, क्रूज और जमीन पर उतर सकते हैं। | ||
इनमें से कई प्रणालियों में, विफलता अस्वीकार्य है। हवाई वाहनों (नागरिक या सैन्य) में चल रहे सॉफ़्टवेयर की विश्वसनीयता इस तथ्य से प्रदर्शित होती है कि अधिकांश हवाई दुर्घटनाएं मैन्युअल त्रुटियों के कारण होती हैं। दुर्भाग्य से विश्वसनीय सॉफ़्टवेयर का उपयोग करना आसान या सहज नहीं है, खराब उपयोगकर्ता इंटरफ़ेस डिज़ाइन कई एयरोस्पेस दुर्घटनाओं और मौतों का | इनमें से कई प्रणालियों में, विफलता अस्वीकार्य है। हवाई वाहनों (नागरिक या सैन्य) में चल रहे सॉफ़्टवेयर की विश्वसनीयता इस तथ्य से प्रदर्शित होती है कि अधिकांश हवाई दुर्घटनाएं मैन्युअल त्रुटियों के कारण होती हैं। दुर्भाग्य से विश्वसनीय सॉफ़्टवेयर का उपयोग करना आसान या सहज नहीं है, खराब उपयोगकर्ता इंटरफ़ेस डिज़ाइन कई एयरोस्पेस दुर्घटनाओं और मौतों का महत्वपूर्ण कारण रहा है।{{citation needed|date=November 2013}} | ||
== विनियामक मुद्दे == | == विनियामक मुद्दे == | ||
सुरक्षा आवश्यकताओं के कारण, अधिकांश राष्ट्र एवियोनिक्स को विनियमित करते हैं, या कम से कम सहयोगियों या सीमा शुल्क संघ के समूह द्वारा उपयोग में मानकों को अपनाते हैं। अंतर्राष्ट्रीय विमानन विकास को सबसे अधिक प्रभावित करने वाले तीन नियामक संगठन यू.एस., ई.यू. और रूस। | सुरक्षा आवश्यकताओं के कारण, अधिकांश राष्ट्र एवियोनिक्स को विनियमित करते हैं, या कम से कम सहयोगियों या सीमा शुल्क संघ के समूह द्वारा उपयोग में मानकों को अपनाते हैं। अंतर्राष्ट्रीय विमानन विकास को सबसे अधिक प्रभावित करने वाले तीन नियामक संगठन यू.एस., ई.यू. और रूस। | ||
युनाइटेड स्टेट्स|यू.एस. में, एवियोनिक और अन्य विमान घटकों में संघीय उड्डयन विनियम, परिवहन हवाई जहाजों के लिए भाग 25, छोटे हवाई जहाजों के लिए भाग 23, और रोटरक्राफ्ट के लिए भाग 27 और 29 द्वारा अनिवार्य सुरक्षा और विश्वसनीयता मानक हैं। इन मानकों को संघीय उड्डयन प्रशासन के नामित इंजीनियरिंग प्रतिनिधियों द्वारा लागू किया जाता है, जिन्हें आम तौर पर | युनाइटेड स्टेट्स|यू.एस. में, एवियोनिक और अन्य विमान घटकों में संघीय उड्डयन विनियम, परिवहन हवाई जहाजों के लिए भाग 25, छोटे हवाई जहाजों के लिए भाग 23, और रोटरक्राफ्ट के लिए भाग 27 और 29 द्वारा अनिवार्य सुरक्षा और विश्वसनीयता मानक हैं। इन मानकों को संघीय उड्डयन प्रशासन के नामित इंजीनियरिंग प्रतिनिधियों द्वारा लागू किया जाता है, जिन्हें आम तौर पर निर्माता द्वारा भुगतान किया जाता है और [[एफएए]] द्वारा प्रमाणित किया जाता है। | ||
[[यूरोपीय संघ]] में अंतर्राष्ट्रीय इलेक्ट्रोटेक्निकल कमीशन सुरक्षा-महत्वपूर्ण प्रणालियों के लिए अनुशंसित आवश्यकताओं का वर्णन करता है, जिन्हें आमतौर पर सरकारों द्वारा परिवर्तन के बिना अपनाया जाता है। एवियोनिक्स के | [[यूरोपीय संघ]] में अंतर्राष्ट्रीय इलेक्ट्रोटेक्निकल कमीशन सुरक्षा-महत्वपूर्ण प्रणालियों के लिए अनुशंसित आवश्यकताओं का वर्णन करता है, जिन्हें आमतौर पर सरकारों द्वारा परिवर्तन के बिना अपनाया जाता है। एवियोनिक्स के सुरक्षित, विश्वसनीय टुकड़े पर सीई मार्क होता है। नियामक व्यवस्था उल्लेखनीय रूप से अमेरिका और कनाडा में अग्नि सुरक्षा के समान है। सरकार परीक्षण प्रयोगशालाओं को प्रमाणित करती है, और प्रयोगशालाएँ निर्मित वस्तुओं और संगठनों दोनों को प्रमाणित करती हैं। अनिवार्य रूप से, इंजीनियरिंग का निरीक्षण सरकार और निर्माता से परीक्षण प्रयोगशाला में आउटसोर्स किया जाता है। | ||
सुरक्षा और विश्वसनीयता सुनिश्चित करने के लिए, राष्ट्रीय नियामक प्राधिकरणों (जैसे एफएए, [[सिविल एरोनॉटिक्स एडमिनिस्ट्रेशन (संयुक्त राज्य अमेरिका)]], या संयुक्त राज्य रक्षा विभाग) को सॉफ्टवेयर विकास मानकों की आवश्यकता होती है। कुछ प्रतिनिधि मानकों में सैन्य प्रणालियों के लिए [[MIL-STD-2167]], या नागरिक विमानों के लिए RTCA [[DO-178B]] और इसके उत्तराधिकारी [[DO-178C]] शामिल हैं। | सुरक्षा और विश्वसनीयता सुनिश्चित करने के लिए, राष्ट्रीय नियामक प्राधिकरणों (जैसे एफएए, [[सिविल एरोनॉटिक्स एडमिनिस्ट्रेशन (संयुक्त राज्य अमेरिका)]], या संयुक्त राज्य रक्षा विभाग) को सॉफ्टवेयर विकास मानकों की आवश्यकता होती है। कुछ प्रतिनिधि मानकों में सैन्य प्रणालियों के लिए [[MIL-STD-2167]], या नागरिक विमानों के लिए RTCA [[DO-178B]] और इसके उत्तराधिकारी [[DO-178C]] शामिल हैं। | ||
| Line 35: | Line 27: | ||
एवियोनिक्स सॉफ़्टवेयर और अन्य एम्बेडेड सिस्टम के बीच मुख्य अंतर यह है कि वास्तविक मानक अक्सर व्यावसायिक मानकों की तुलना में कहीं अधिक विस्तृत और कठोर होते हैं, आमतौर पर सैकड़ों पृष्ठों वाले दस्तावेज़ों द्वारा वर्णित किया जाता है। यह आमतौर पर रीयल टाइम ऑपरेटिंग सिस्टम पर चलता है। | एवियोनिक्स सॉफ़्टवेयर और अन्य एम्बेडेड सिस्टम के बीच मुख्य अंतर यह है कि वास्तविक मानक अक्सर व्यावसायिक मानकों की तुलना में कहीं अधिक विस्तृत और कठोर होते हैं, आमतौर पर सैकड़ों पृष्ठों वाले दस्तावेज़ों द्वारा वर्णित किया जाता है। यह आमतौर पर रीयल टाइम ऑपरेटिंग सिस्टम पर चलता है। | ||
चूंकि प्रक्रिया कानूनी रूप से आवश्यक है, अधिकांश प्रक्रियाओं में विशिष्टताओं और डिजाइनों में गिने हुए पैराग्राफों से कोड के सटीक टुकड़ों तक, प्रत्येक के लिए सटीक परीक्षण और अंतिम प्रमाणन चेकलिस्ट पर | चूंकि प्रक्रिया कानूनी रूप से आवश्यक है, अधिकांश प्रक्रियाओं में विशिष्टताओं और डिजाइनों में गिने हुए पैराग्राफों से कोड के सटीक टुकड़ों तक, प्रत्येक के लिए सटीक परीक्षण और अंतिम प्रमाणन चेकलिस्ट पर बॉक्स के साथ आवश्यकताओं का पता लगाने के लिए दस्तावेज़ या सॉफ़्टवेयर होते हैं। यह विशेष रूप से कानूनी रूप से अनिवार्य मानक के अनुरूप साबित करने के लिए है। | ||
किसी विशिष्ट परियोजना से यहां वर्णित प्रक्रियाओं में विचलन वैकल्पिक विधियों के उपयोग या निम्न सुरक्षा स्तर की आवश्यकताओं के कारण हो सकता है। | किसी विशिष्ट परियोजना से यहां वर्णित प्रक्रियाओं में विचलन वैकल्पिक विधियों के उपयोग या निम्न सुरक्षा स्तर की आवश्यकताओं के कारण हो सकता है। | ||
| Line 42: | Line 34: | ||
=== मानव इंटरफेस === | === मानव इंटरफेस === | ||
पर्याप्त मानव इंटरफेस वाली परियोजनाएं आमतौर पर प्रोटोटाइप या सिम्युलेटेड होती हैं। वीडियोटेप आमतौर पर बनाए रखा जाता है, लेकिन परीक्षण के तुरंत बाद प्रोटोटाइप सेवानिवृत्त हो जाता है, क्योंकि अन्यथा वरिष्ठ प्रबंधन और ग्राहक विश्वास कर सकते हैं कि सिस्टम पूरा हो गया है। | पर्याप्त मानव इंटरफेस वाली परियोजनाएं आमतौर पर प्रोटोटाइप या सिम्युलेटेड होती हैं। वीडियोटेप आमतौर पर बनाए रखा जाता है, लेकिन परीक्षण के तुरंत बाद प्रोटोटाइप सेवानिवृत्त हो जाता है, क्योंकि अन्यथा वरिष्ठ प्रबंधन और ग्राहक विश्वास कर सकते हैं कि सिस्टम पूरा हो गया है। प्रमुख लक्ष्य मानव-इंटरफ़ेस मुद्दों को ढूंढना है जो सुरक्षा और उपयोगिता को प्रभावित कर सकते हैं। | ||
=== [[जोखिम विश्लेषण]] === | === [[जोखिम विश्लेषण]] === | ||
सुरक्षा-महत्वपूर्ण एवियोनिक्स में आमतौर पर | सुरक्षा-महत्वपूर्ण एवियोनिक्स में आमतौर पर खतरनाक विश्लेषण होता है। परियोजना के शुरुआती चरणों में, पहले से ही परियोजना के मुख्य भागों का कम से कम अस्पष्ट विचार है। इंजीनियर तब ब्लॉक आरेख के प्रत्येक ब्लॉक को लेता है और उन चीजों पर विचार करता है जो उस ब्लॉक के साथ गलत हो सकती हैं, और वे पूरे सिस्टम को कैसे प्रभावित करते हैं। इसके बाद, खतरों की गंभीरता और संभावना का अनुमान लगाया जाता है। समस्याएँ तब आवश्यकताएं बन जाती हैं जो डिज़ाइन के विनिर्देशों में फ़ीड करती हैं। | ||
सैन्य क्रिप्टोग्राफ़िक सुरक्षा से जुड़ी परियोजनाओं में आम तौर पर | सैन्य क्रिप्टोग्राफ़िक सुरक्षा से जुड़ी परियोजनाओं में आम तौर पर सुरक्षा विश्लेषण शामिल होता है, जिसमें खतरनाक विश्लेषण जैसी विधियों का उपयोग किया जाता है। | ||
=== रखरखाव मैनुअल === | === रखरखाव मैनुअल === | ||
जैसे ही इंजीनियरिंग विनिर्देश पूरा हो जाता है, रखरखाव मैनुअल लिखना शुरू हो सकता है। मरम्मत के लिए | जैसे ही इंजीनियरिंग विनिर्देश पूरा हो जाता है, रखरखाव मैनुअल लिखना शुरू हो सकता है। मरम्मत के लिए रखरखाव मैनुअल आवश्यक है, और निश्चित रूप से, यदि सिस्टम को ठीक नहीं किया जा सकता है, तो यह सुरक्षित नहीं होगा। | ||
अधिकांश मानकों के कई स्तर हैं। | अधिकांश मानकों के कई स्तर हैं। कम सुरक्षा वाला उत्पाद जैसे कि इन-फ्लाइट एंटरटेनमेंट यूनिट ( उड़ने वाला टीवी) स्थापना और समायोजन के लिए योजनाबद्ध और प्रक्रियाओं से बच सकता है। नेविगेशन सिस्टम, ऑटोपायलट या इंजन में प्रक्रियाओं, निरीक्षणों और हेराफेरी के निर्देशों के हजारों पृष्ठ हो सकते हैं। दस्तावेज़ अब (2003) सीडी-रोम पर नियमित रूप से वितरित किए जाते हैं, मानक स्वरूपों में जिसमें पाठ और चित्र शामिल होते हैं। | ||
अन्य दस्तावेज़ीकरण आवश्यकताओं में से | अन्य दस्तावेज़ीकरण आवश्यकताओं में से यह है कि अधिकांश वाणिज्यिक अनुबंधों के लिए आश्वासन की आवश्यकता होती है कि सिस्टम प्रलेखन अनिश्चित काल तक उपलब्ध रहेगा। यह आश्वासन प्रदान करने का सामान्य व्यावसायिक तरीका छोटी सी नींव या ट्रस्ट बनाना और निधि देना है। तब ट्रस्ट सुरक्षित स्थान पर मेलबॉक्स और जमा प्रतियां (आमतौर पर [[बेहद पतली]] में) रखता है, जैसे कि विश्वविद्यालय के पुस्तकालय में किराए की जगह ( विशेष संग्रह के रूप में प्रबंधित), या (अब शायद ही कभी) गुफा या रेगिस्तानी स्थान में दफन हो।<ref>Personal Information, Robert Yablonsky, Engineering manager, B.E. Aerospace, Irvine, CA, 1993</ref> | ||
=== डिजाइन और विनिर्देश दस्तावेज === | === डिजाइन और विनिर्देश दस्तावेज === | ||
ये आमतौर पर अन्य सॉफ्टवेयर डेवलपमेंट मॉडल के समान ही होते हैं। | ये आमतौर पर अन्य सॉफ्टवेयर डेवलपमेंट मॉडल के समान ही होते हैं। महत्वपूर्ण अंतर यह है कि आवश्यकताओं को आमतौर पर ऊपर वर्णित अनुसार खोजा जाता है। बड़ी परियोजनाओं में, आवश्यकता-पता लगाने की क्षमता इतना बड़ा महंगा काम है कि इसे प्रबंधित करने के लिए बड़े, महंगे कंप्यूटर प्रोग्राम की आवश्यकता होती है। | ||
=== कोड उत्पादन और समीक्षा === | === कोड उत्पादन और समीक्षा === | ||
कोड लिखा जाता है, फिर आमतौर पर | कोड लिखा जाता है, फिर आमतौर पर प्रोग्रामर (या प्रोग्रामर के समूह, आमतौर पर स्वतंत्र रूप से) द्वारा समीक्षा की जाती है, जिसने इसे मूल रूप से नहीं लिखा था (अन्य कानूनी आवश्यकता)। विशेष संगठन भी आमतौर पर संभावित गलतियों की चेकलिस्ट के साथ कोड समीक्षा करते हैं। जब नए प्रकार की गलती पाई जाती है तो उसे चेकलिस्ट में जोड़ दिया जाता है, और पूरे कोड में ठीक कर दिया जाता है। | ||
कोड की अक्सर विशेष कार्यक्रमों द्वारा जांच की जाती है जो शुद्धता (स्टेटिक कोड विश्लेषण) का विश्लेषण करती है, जैसे [[स्पार्क प्रोग्रामिंग भाषा]] के लिए स्पार्क परीक्षक (एडा प्रोग्रामिंग भाषा का | कोड की अक्सर विशेष कार्यक्रमों द्वारा जांच की जाती है जो शुद्धता (स्टेटिक कोड विश्लेषण) का विश्लेषण करती है, जैसे [[स्पार्क प्रोग्रामिंग भाषा]] के लिए स्पार्क परीक्षक (एडा प्रोग्रामिंग भाषा का उपसमूह) या प्रोग्रामिंग भाषाओं के सी-परिवार के लिए [[लिंट प्रोग्रामिंग टूल]] (मुख्य रूप से) सी, हालांकि)। | ||
[[संकलक]] या विशेष जाँच कार्यक्रम जैसे लिंट जाँच यह देखने के लिए कि क्या डेटा के प्रकार उन पर संचालन के साथ संगत हैं, ऐसे उपकरण नियमित रूप से वैध प्रोग्रामिंग भाषा सबसेट और प्रोग्रामिंग शैलियों के सख्त उपयोग को लागू करने के लिए उपयोग किए जाते हैं। | [[संकलक]] या विशेष जाँच कार्यक्रम जैसे लिंट जाँच यह देखने के लिए कि क्या डेटा के प्रकार उन पर संचालन के साथ संगत हैं, ऐसे उपकरण नियमित रूप से वैध प्रोग्रामिंग भाषा सबसेट और प्रोग्रामिंग शैलियों के सख्त उपयोग को लागू करने के लिए उपयोग किए जाते हैं। | ||
प्रोग्राम का | प्रोग्राम का और सेट [[सॉफ्टवेयर मीट्रिक]] को मापता है, कोड के उन हिस्सों को देखने के लिए जिनमें गलतियाँ होने की संभावना है। | ||
सभी समस्याएं ठीक हो गई हैं, या कम से कम समझी गई हैं और दोबारा जांच की गई हैं। | सभी समस्याएं ठीक हो गई हैं, या कम से कम समझी गई हैं और दोबारा जांच की गई हैं। | ||
| Line 71: | Line 63: | ||
=== यूनिट परीक्षण === | === यूनिट परीक्षण === | ||
100% [[ कोड कवरेज़ ]] प्राप्त करने के लिए कम से कम | 100% [[ कोड कवरेज़ ]] प्राप्त करने के लिए कम से कम बार कोड के प्रत्येक निर्देश का प्रयोग करने के लिए यूनिट टेस्ट कोड लिखा जाता है। कवरेज टूल का उपयोग अक्सर यह सत्यापित करने के लिए किया जाता है कि प्रत्येक निर्देश निष्पादित किया गया है, और फिर कानूनी कारणों से परीक्षण कवरेज को भी प्रलेखित किया गया है। | ||
यह परीक्षण सबसे शक्तिशाली में से | यह परीक्षण सबसे शक्तिशाली में से है। यह प्रोग्राम लॉजिक की विस्तृत समीक्षा के लिए बाध्य करता है, और अधिकांश कोडिंग, कंपाइलर और कुछ डिज़ाइन त्रुटियों का पता लगाता है। मॉड्यूल विनिर्देश के रूप में सॉफ़्टवेयर डिज़ाइन का उपयोग करके, कुछ संगठन कोड लिखने से पहले यूनिट परीक्षण लिखते हैं। यूनिट टेस्ट कोड निष्पादित किया गया है, और सभी समस्याएं ठीक हो गई हैं। | ||
=== | === ता परीक्षण === | ||
जैसे ही कोड के टुकड़े उपलब्ध होते हैं, उन्हें कोड के कंकाल में जोड़ दिया जाता है, और यह सुनिश्चित करने के लिए परीक्षण किया जाता है कि प्रत्येक इंटरफ़ेस काम करता है। इलेक्ट्रॉनिक्स के बर्न-इन और रेडियो उत्सर्जन परीक्षण शुरू करने के लिए आमतौर पर इलेक्ट्रॉनिक्स के अंतर्निर्मित परीक्षण पहले समाप्त किए जाने चाहिए। | जैसे ही कोड के टुकड़े उपलब्ध होते हैं, उन्हें कोड के कंकाल में जोड़ दिया जाता है, और यह सुनिश्चित करने के लिए परीक्षण किया जाता है कि प्रत्येक इंटरफ़ेस काम करता है। इलेक्ट्रॉनिक्स के बर्न-इन और रेडियो उत्सर्जन परीक्षण शुरू करने के लिए आमतौर पर इलेक्ट्रॉनिक्स के अंतर्निर्मित परीक्षण पहले समाप्त किए जाने चाहिए। | ||
अगला, सॉफ़्टवेयर की सबसे मूल्यवान विशेषताओं को | अगला, सॉफ़्टवेयर की सबसे मूल्यवान विशेषताओं को ीकृत किया गया है। इंटीग्रेटर्स के लिए कोड के छोटे चयनित टुकड़ों को चलाने का तरीका होना बहुत सुविधाजनक है, शायद साधारण मेनू सिस्टम से। | ||
कुछ कार्यक्रम प्रबंधक इस | कुछ कार्यक्रम प्रबंधक इस ीकरण प्रक्रिया को व्यवस्थित करने का प्रयास करते हैं ताकि कुछ न्यूनतम स्तर के कार्य को प्राप्त करने के बाद, समय बीतने के साथ-साथ सुविधाओं की बढ़ती संख्या के साथ सिस्टम किसी भी बाद की तारीख में सुपुर्दगी योग्य हो जाए। | ||
=== ब्लैक बॉक्स और स्वीकृति परीक्षण === | === ब्लैक बॉक्स और स्वीकृति परीक्षण === | ||
इस बीच, परीक्षण इंजीनियर आमतौर पर | इस बीच, परीक्षण इंजीनियर आमतौर पर परीक्षण रिग को असेंबल करना शुरू करते हैं, और सॉफ्टवेयर इंजीनियरों द्वारा उपयोग के लिए प्रारंभिक परीक्षण जारी करते हैं। किसी बिंदु पर, परीक्षण इंजीनियरिंग विनिर्देश के सभी कार्यों को कवर करते हैं। इस बिंदु पर, संपूर्ण एवियोनिक इकाई का परीक्षण शुरू होता है। स्वीकृति परीक्षण का उद्देश्य यह साबित करना है कि इकाई संचालन में सुरक्षित और विश्वसनीय है। | ||
सॉफ्टवेयर का पहला परीक्षण, और | सॉफ्टवेयर का पहला परीक्षण, और तंग कार्यक्रम में पूरा करना सबसे कठिन है, यूनिट के रेडियो उत्सर्जन का यथार्थवादी परीक्षण है। यह आम तौर पर परियोजना में जल्दी शुरू किया जाना चाहिए ताकि यह सुनिश्चित किया जा सके कि इलेक्ट्रॉनिक्स के डिजाइन में कोई आवश्यक बदलाव करने का समय है। | ||
सॉफ्टवेयर को | सॉफ्टवेयर को संरचनात्मक कवरेज विश्लेषण के अधीन भी किया जाता है, जहां परीक्षण चलाए जाते हैं और कोड कवरेज त्र और विश्लेषण किया जाता है। | ||
=== प्रमाणन === | === प्रमाणन === | ||
प्रत्येक चरण | प्रत्येक चरण सुपुर्दगी योग्य, या तो दस्तावेज़, कोड, या परीक्षण रिपोर्ट तैयार करता है। जब सॉफ़्टवेयर अपने सभी परीक्षण (या सुरक्षित रूप से बेचे जाने के लिए पर्याप्त) पास कर लेता है, तो ये प्रमाणीकरण रिपोर्ट में बंधे होते हैं, जिसमें सचमुच हजारों पृष्ठ हो सकते हैं। नामित इंजीनियरिंग प्रतिनिधि, जो पूरा करने के लिए प्रयास कर रहा है, फिर तय करता है कि परिणाम स्वीकार्य है या नहीं। यदि ऐसा है, तो वह इस पर हस्ताक्षर करता है, और एवियोनिक सॉफ्टवेयर प्रमाणित होता है। | ||
== यह भी देखें == | == यह भी देखें == | ||
Revision as of 23:19, 28 June 2023
वैमानिकी सॉफ्टवेयर कानूनी रूप से अनिवार्य विमानन सुरक्षा और एवियोनिक्स में उपयोग की जाने वाली विश्वसनीयता इंजीनियरिंग चिंताओं के साथ अंतः स्थापित प्रणाली है। एवियोनिक सॉफ़्टवेयर और पारंपरिक एम्बेडेड सॉफ़्टवेयर के बीच मुख्य अंतर यह है कि सॉफ़्टवेयर विकास मॉडल क़ानून द्वारा आवश्यक है और सुरक्षा के लिए अनुकूलित है।
यह दावा किया जाता है कि नीचे वर्णित सॉफ्टवेयर विकास प्रक्रिया वाणिज्यिक कंप्यूटर सॉफ्टवेयर के लिए उपयोग की जाने वाली सामान्य तदर्थ प्रक्रियाओं की तुलना में केवल थोड़ी धीमी और अधिक महंगी (शायद 15 प्रतिशत) है। चूँकि अधिकांश सॉफ़्टवेयर गलतियों के कारण विफल हो जाते हैं, गलतियों को जल्द से जल्द समाप्त करना भी सॉफ़्टवेयर बनाने का अपेक्षाकृत सस्ता और विश्वसनीय तरीका है। हालांकि कुछ परियोजनाओं में, तैनाती तक विनिर्देशों में गलतियों का पता नहीं लगाया जा सकता है। उस समय, उन्हें ठीक करना बहुत महंगा हो सकता है।
किसी भी सॉफ्टवेयर विकास मॉडल का मूल विचार यह है कि डिजाइन प्रक्रिया के प्रत्येक चरण में आउटपुट होते हैं जिन्हें डिलिवरेबल्स कहा जाता है।[citation needed] यदि सुपुर्दगी की शुद्धता के लिए परीक्षण किया जाता है और तय किया जाता है, तो सामान्य मानवीय गलतियाँ आसानी से खतरनाक या महंगी समस्याओं में विकसित नहीं हो सकती हैं। अधिकांश निर्माता[citation needed] डिज़ाइन उत्पाद को समन्वयित करने के लिए झरना मॉडल का पालन करें, लेकिन लगभग सभी स्पष्ट रूप से पहले के काम को संशोधित करने की अनुमति देते हैं। परिणाम अधिक बार सर्पिल मॉडल के करीब होता है।
एम्बेडेड सॉफ़्टवेयर के अवलोकन के लिए एम्बेडेड सिस्टम और सॉफ़्टवेयर डेवलपमेंट मॉडल देखें। इस लेख का शेष भाग उस जानकारी से परिचित होने का अनुमान लगाता है, और वाणिज्यिक एम्बेडेड सिस्टम और व्यावसायिक विकास मॉडल के बीच अंतर पर चर्चा करता है।
सामान्य अवलोकन
चूंकि अधिकांश एवियोनिक्स निर्माता सॉफ्टवेयर को वजन बढ़ाए बिना मूल्य जोड़ने के तरीके के रूप में देखते हैं, एवियनिक सिस्टम में एम्बेडेड सॉफ़्टवेयर का महत्व बढ़ रहा है।
ऑटो-पायलट वाले अधिकांश आधुनिक वाणिज्यिक विमान उड़ान कंप्यूटर और तथाकथित उड़ान प्रबंधन प्रणाली (FMS) का उपयोग करते हैं जो उड़ान के कुछ चरणों के दौरान पायलट के सक्रिय हस्तक्षेप के बिना विमान को उड़ा सकते हैं। इसके अलावा विकास या उत्पादन के तहत मानव रहित वाहन हैं: मिसाइल और ड्रोन जो हवाई पायलट के हस्तक्षेप के बिना उड़ान भर सकते हैं, क्रूज और जमीन पर उतर सकते हैं।
इनमें से कई प्रणालियों में, विफलता अस्वीकार्य है। हवाई वाहनों (नागरिक या सैन्य) में चल रहे सॉफ़्टवेयर की विश्वसनीयता इस तथ्य से प्रदर्शित होती है कि अधिकांश हवाई दुर्घटनाएं मैन्युअल त्रुटियों के कारण होती हैं। दुर्भाग्य से विश्वसनीय सॉफ़्टवेयर का उपयोग करना आसान या सहज नहीं है, खराब उपयोगकर्ता इंटरफ़ेस डिज़ाइन कई एयरोस्पेस दुर्घटनाओं और मौतों का महत्वपूर्ण कारण रहा है।[citation needed]
विनियामक मुद्दे
सुरक्षा आवश्यकताओं के कारण, अधिकांश राष्ट्र एवियोनिक्स को विनियमित करते हैं, या कम से कम सहयोगियों या सीमा शुल्क संघ के समूह द्वारा उपयोग में मानकों को अपनाते हैं। अंतर्राष्ट्रीय विमानन विकास को सबसे अधिक प्रभावित करने वाले तीन नियामक संगठन यू.एस., ई.यू. और रूस।
युनाइटेड स्टेट्स|यू.एस. में, एवियोनिक और अन्य विमान घटकों में संघीय उड्डयन विनियम, परिवहन हवाई जहाजों के लिए भाग 25, छोटे हवाई जहाजों के लिए भाग 23, और रोटरक्राफ्ट के लिए भाग 27 और 29 द्वारा अनिवार्य सुरक्षा और विश्वसनीयता मानक हैं। इन मानकों को संघीय उड्डयन प्रशासन के नामित इंजीनियरिंग प्रतिनिधियों द्वारा लागू किया जाता है, जिन्हें आम तौर पर निर्माता द्वारा भुगतान किया जाता है और एफएए द्वारा प्रमाणित किया जाता है।
यूरोपीय संघ में अंतर्राष्ट्रीय इलेक्ट्रोटेक्निकल कमीशन सुरक्षा-महत्वपूर्ण प्रणालियों के लिए अनुशंसित आवश्यकताओं का वर्णन करता है, जिन्हें आमतौर पर सरकारों द्वारा परिवर्तन के बिना अपनाया जाता है। एवियोनिक्स के सुरक्षित, विश्वसनीय टुकड़े पर सीई मार्क होता है। नियामक व्यवस्था उल्लेखनीय रूप से अमेरिका और कनाडा में अग्नि सुरक्षा के समान है। सरकार परीक्षण प्रयोगशालाओं को प्रमाणित करती है, और प्रयोगशालाएँ निर्मित वस्तुओं और संगठनों दोनों को प्रमाणित करती हैं। अनिवार्य रूप से, इंजीनियरिंग का निरीक्षण सरकार और निर्माता से परीक्षण प्रयोगशाला में आउटसोर्स किया जाता है।
सुरक्षा और विश्वसनीयता सुनिश्चित करने के लिए, राष्ट्रीय नियामक प्राधिकरणों (जैसे एफएए, सिविल एरोनॉटिक्स एडमिनिस्ट्रेशन (संयुक्त राज्य अमेरिका), या संयुक्त राज्य रक्षा विभाग) को सॉफ्टवेयर विकास मानकों की आवश्यकता होती है। कुछ प्रतिनिधि मानकों में सैन्य प्रणालियों के लिए MIL-STD-2167, या नागरिक विमानों के लिए RTCA DO-178B और इसके उत्तराधिकारी DO-178C शामिल हैं।
इस सॉफ़्टवेयर के लिए नियामक आवश्यकताएँ अन्य सॉफ़्टवेयर की तुलना में महंगी हो सकती हैं, लेकिन वे आमतौर पर न्यूनतम हैं जो आवश्यक सुरक्षा उत्पन्न करने के लिए आवश्यक हैं।
विकास प्रक्रिया
एवियोनिक्स सॉफ़्टवेयर और अन्य एम्बेडेड सिस्टम के बीच मुख्य अंतर यह है कि वास्तविक मानक अक्सर व्यावसायिक मानकों की तुलना में कहीं अधिक विस्तृत और कठोर होते हैं, आमतौर पर सैकड़ों पृष्ठों वाले दस्तावेज़ों द्वारा वर्णित किया जाता है। यह आमतौर पर रीयल टाइम ऑपरेटिंग सिस्टम पर चलता है।
चूंकि प्रक्रिया कानूनी रूप से आवश्यक है, अधिकांश प्रक्रियाओं में विशिष्टताओं और डिजाइनों में गिने हुए पैराग्राफों से कोड के सटीक टुकड़ों तक, प्रत्येक के लिए सटीक परीक्षण और अंतिम प्रमाणन चेकलिस्ट पर बॉक्स के साथ आवश्यकताओं का पता लगाने के लिए दस्तावेज़ या सॉफ़्टवेयर होते हैं। यह विशेष रूप से कानूनी रूप से अनिवार्य मानक के अनुरूप साबित करने के लिए है।
किसी विशिष्ट परियोजना से यहां वर्णित प्रक्रियाओं में विचलन वैकल्पिक विधियों के उपयोग या निम्न सुरक्षा स्तर की आवश्यकताओं के कारण हो सकता है।
लगभग सभी सॉफ़्टवेयर विकास मानकों का वर्णन है कि विशिष्टताओं, डिज़ाइन, कोडिंग और परीक्षण को कैसे निष्पादित और सुधारना है (सॉफ़्टवेयर विकास मॉडल देखें)। हालाँकि एवियोनिक्स सॉफ़्टवेयर विकास मानक सुरक्षा और प्रमाणन के लिए विकास में कुछ कदम जोड़ते हैं:
मानव इंटरफेस
पर्याप्त मानव इंटरफेस वाली परियोजनाएं आमतौर पर प्रोटोटाइप या सिम्युलेटेड होती हैं। वीडियोटेप आमतौर पर बनाए रखा जाता है, लेकिन परीक्षण के तुरंत बाद प्रोटोटाइप सेवानिवृत्त हो जाता है, क्योंकि अन्यथा वरिष्ठ प्रबंधन और ग्राहक विश्वास कर सकते हैं कि सिस्टम पूरा हो गया है। प्रमुख लक्ष्य मानव-इंटरफ़ेस मुद्दों को ढूंढना है जो सुरक्षा और उपयोगिता को प्रभावित कर सकते हैं।
जोखिम विश्लेषण
सुरक्षा-महत्वपूर्ण एवियोनिक्स में आमतौर पर खतरनाक विश्लेषण होता है। परियोजना के शुरुआती चरणों में, पहले से ही परियोजना के मुख्य भागों का कम से कम अस्पष्ट विचार है। इंजीनियर तब ब्लॉक आरेख के प्रत्येक ब्लॉक को लेता है और उन चीजों पर विचार करता है जो उस ब्लॉक के साथ गलत हो सकती हैं, और वे पूरे सिस्टम को कैसे प्रभावित करते हैं। इसके बाद, खतरों की गंभीरता और संभावना का अनुमान लगाया जाता है। समस्याएँ तब आवश्यकताएं बन जाती हैं जो डिज़ाइन के विनिर्देशों में फ़ीड करती हैं।
सैन्य क्रिप्टोग्राफ़िक सुरक्षा से जुड़ी परियोजनाओं में आम तौर पर सुरक्षा विश्लेषण शामिल होता है, जिसमें खतरनाक विश्लेषण जैसी विधियों का उपयोग किया जाता है।
रखरखाव मैनुअल
जैसे ही इंजीनियरिंग विनिर्देश पूरा हो जाता है, रखरखाव मैनुअल लिखना शुरू हो सकता है। मरम्मत के लिए रखरखाव मैनुअल आवश्यक है, और निश्चित रूप से, यदि सिस्टम को ठीक नहीं किया जा सकता है, तो यह सुरक्षित नहीं होगा।
अधिकांश मानकों के कई स्तर हैं। कम सुरक्षा वाला उत्पाद जैसे कि इन-फ्लाइट एंटरटेनमेंट यूनिट ( उड़ने वाला टीवी) स्थापना और समायोजन के लिए योजनाबद्ध और प्रक्रियाओं से बच सकता है। नेविगेशन सिस्टम, ऑटोपायलट या इंजन में प्रक्रियाओं, निरीक्षणों और हेराफेरी के निर्देशों के हजारों पृष्ठ हो सकते हैं। दस्तावेज़ अब (2003) सीडी-रोम पर नियमित रूप से वितरित किए जाते हैं, मानक स्वरूपों में जिसमें पाठ और चित्र शामिल होते हैं।
अन्य दस्तावेज़ीकरण आवश्यकताओं में से यह है कि अधिकांश वाणिज्यिक अनुबंधों के लिए आश्वासन की आवश्यकता होती है कि सिस्टम प्रलेखन अनिश्चित काल तक उपलब्ध रहेगा। यह आश्वासन प्रदान करने का सामान्य व्यावसायिक तरीका छोटी सी नींव या ट्रस्ट बनाना और निधि देना है। तब ट्रस्ट सुरक्षित स्थान पर मेलबॉक्स और जमा प्रतियां (आमतौर पर बेहद पतली में) रखता है, जैसे कि विश्वविद्यालय के पुस्तकालय में किराए की जगह ( विशेष संग्रह के रूप में प्रबंधित), या (अब शायद ही कभी) गुफा या रेगिस्तानी स्थान में दफन हो।[1]
डिजाइन और विनिर्देश दस्तावेज
ये आमतौर पर अन्य सॉफ्टवेयर डेवलपमेंट मॉडल के समान ही होते हैं। महत्वपूर्ण अंतर यह है कि आवश्यकताओं को आमतौर पर ऊपर वर्णित अनुसार खोजा जाता है। बड़ी परियोजनाओं में, आवश्यकता-पता लगाने की क्षमता इतना बड़ा महंगा काम है कि इसे प्रबंधित करने के लिए बड़े, महंगे कंप्यूटर प्रोग्राम की आवश्यकता होती है।
कोड उत्पादन और समीक्षा
कोड लिखा जाता है, फिर आमतौर पर प्रोग्रामर (या प्रोग्रामर के समूह, आमतौर पर स्वतंत्र रूप से) द्वारा समीक्षा की जाती है, जिसने इसे मूल रूप से नहीं लिखा था (अन्य कानूनी आवश्यकता)। विशेष संगठन भी आमतौर पर संभावित गलतियों की चेकलिस्ट के साथ कोड समीक्षा करते हैं। जब नए प्रकार की गलती पाई जाती है तो उसे चेकलिस्ट में जोड़ दिया जाता है, और पूरे कोड में ठीक कर दिया जाता है।
कोड की अक्सर विशेष कार्यक्रमों द्वारा जांच की जाती है जो शुद्धता (स्टेटिक कोड विश्लेषण) का विश्लेषण करती है, जैसे स्पार्क प्रोग्रामिंग भाषा के लिए स्पार्क परीक्षक (एडा प्रोग्रामिंग भाषा का उपसमूह) या प्रोग्रामिंग भाषाओं के सी-परिवार के लिए लिंट प्रोग्रामिंग टूल (मुख्य रूप से) सी, हालांकि)। संकलक या विशेष जाँच कार्यक्रम जैसे लिंट जाँच यह देखने के लिए कि क्या डेटा के प्रकार उन पर संचालन के साथ संगत हैं, ऐसे उपकरण नियमित रूप से वैध प्रोग्रामिंग भाषा सबसेट और प्रोग्रामिंग शैलियों के सख्त उपयोग को लागू करने के लिए उपयोग किए जाते हैं। प्रोग्राम का और सेट सॉफ्टवेयर मीट्रिक को मापता है, कोड के उन हिस्सों को देखने के लिए जिनमें गलतियाँ होने की संभावना है। सभी समस्याएं ठीक हो गई हैं, या कम से कम समझी गई हैं और दोबारा जांच की गई हैं।
कुछ कोड, जैसे कि डिजिटल फिल्टर, ग्राफिकल यूज़र इंटरफ़ेस और जड़त्वीय नेविगेशन प्रणाली, इतनी अच्छी तरह से समझे जाते हैं कि सॉफ्टवेयर लिखने के लिए सॉफ्टवेयर टूल विकसित किए गए हैं। इन मामलों में, विशिष्टताओं को विकसित किया जाता है और विश्वसनीय सॉफ्टवेयर स्वचालित रूप से तैयार किया जाता है।
यूनिट परीक्षण
100% कोड कवरेज़ प्राप्त करने के लिए कम से कम बार कोड के प्रत्येक निर्देश का प्रयोग करने के लिए यूनिट टेस्ट कोड लिखा जाता है। कवरेज टूल का उपयोग अक्सर यह सत्यापित करने के लिए किया जाता है कि प्रत्येक निर्देश निष्पादित किया गया है, और फिर कानूनी कारणों से परीक्षण कवरेज को भी प्रलेखित किया गया है।
यह परीक्षण सबसे शक्तिशाली में से है। यह प्रोग्राम लॉजिक की विस्तृत समीक्षा के लिए बाध्य करता है, और अधिकांश कोडिंग, कंपाइलर और कुछ डिज़ाइन त्रुटियों का पता लगाता है। मॉड्यूल विनिर्देश के रूप में सॉफ़्टवेयर डिज़ाइन का उपयोग करके, कुछ संगठन कोड लिखने से पहले यूनिट परीक्षण लिखते हैं। यूनिट टेस्ट कोड निष्पादित किया गया है, और सभी समस्याएं ठीक हो गई हैं।
ता परीक्षण
जैसे ही कोड के टुकड़े उपलब्ध होते हैं, उन्हें कोड के कंकाल में जोड़ दिया जाता है, और यह सुनिश्चित करने के लिए परीक्षण किया जाता है कि प्रत्येक इंटरफ़ेस काम करता है। इलेक्ट्रॉनिक्स के बर्न-इन और रेडियो उत्सर्जन परीक्षण शुरू करने के लिए आमतौर पर इलेक्ट्रॉनिक्स के अंतर्निर्मित परीक्षण पहले समाप्त किए जाने चाहिए।
अगला, सॉफ़्टवेयर की सबसे मूल्यवान विशेषताओं को ीकृत किया गया है। इंटीग्रेटर्स के लिए कोड के छोटे चयनित टुकड़ों को चलाने का तरीका होना बहुत सुविधाजनक है, शायद साधारण मेनू सिस्टम से।
कुछ कार्यक्रम प्रबंधक इस ीकरण प्रक्रिया को व्यवस्थित करने का प्रयास करते हैं ताकि कुछ न्यूनतम स्तर के कार्य को प्राप्त करने के बाद, समय बीतने के साथ-साथ सुविधाओं की बढ़ती संख्या के साथ सिस्टम किसी भी बाद की तारीख में सुपुर्दगी योग्य हो जाए।
ब्लैक बॉक्स और स्वीकृति परीक्षण
इस बीच, परीक्षण इंजीनियर आमतौर पर परीक्षण रिग को असेंबल करना शुरू करते हैं, और सॉफ्टवेयर इंजीनियरों द्वारा उपयोग के लिए प्रारंभिक परीक्षण जारी करते हैं। किसी बिंदु पर, परीक्षण इंजीनियरिंग विनिर्देश के सभी कार्यों को कवर करते हैं। इस बिंदु पर, संपूर्ण एवियोनिक इकाई का परीक्षण शुरू होता है। स्वीकृति परीक्षण का उद्देश्य यह साबित करना है कि इकाई संचालन में सुरक्षित और विश्वसनीय है।
सॉफ्टवेयर का पहला परीक्षण, और तंग कार्यक्रम में पूरा करना सबसे कठिन है, यूनिट के रेडियो उत्सर्जन का यथार्थवादी परीक्षण है। यह आम तौर पर परियोजना में जल्दी शुरू किया जाना चाहिए ताकि यह सुनिश्चित किया जा सके कि इलेक्ट्रॉनिक्स के डिजाइन में कोई आवश्यक बदलाव करने का समय है। सॉफ्टवेयर को संरचनात्मक कवरेज विश्लेषण के अधीन भी किया जाता है, जहां परीक्षण चलाए जाते हैं और कोड कवरेज त्र और विश्लेषण किया जाता है।
प्रमाणन
प्रत्येक चरण सुपुर्दगी योग्य, या तो दस्तावेज़, कोड, या परीक्षण रिपोर्ट तैयार करता है। जब सॉफ़्टवेयर अपने सभी परीक्षण (या सुरक्षित रूप से बेचे जाने के लिए पर्याप्त) पास कर लेता है, तो ये प्रमाणीकरण रिपोर्ट में बंधे होते हैं, जिसमें सचमुच हजारों पृष्ठ हो सकते हैं। नामित इंजीनियरिंग प्रतिनिधि, जो पूरा करने के लिए प्रयास कर रहा है, फिर तय करता है कि परिणाम स्वीकार्य है या नहीं। यदि ऐसा है, तो वह इस पर हस्ताक्षर करता है, और एवियोनिक सॉफ्टवेयर प्रमाणित होता है।
यह भी देखें
- अनुलग्नक: एवियोनिक्स में परिवर्णी शब्द और संक्षिप्त रूप
- डीओ-178बी
- सॉफ्टवेयर विकास मॉडल
- जोखिम विश्लेषण
- 10 की शक्ति: सुरक्षा-महत्वपूर्ण कोड विकसित करने के नियम
संदर्भ
- ↑ Personal Information, Robert Yablonsky, Engineering manager, B.E. Aerospace, Irvine, CA, 1993
