DO-178B और DO-178C सॉफ़्टवेयर प्रमाणन मानक एयरवर्दी वायु प्रणालियों के निर्माण के लिए एक मार्गदर्शक के रूप में काम करते हैं। 1992 में पहली बार प्रकाशित, DO-178B (Software Considerations in Airborne Systems and Equipment Certification) सॉफ़्टवेयर-आधारित वायु प्रणालियों के लिए EASA (European Union Aviation Safety Agency) और FAA (Federal Aviation Administration) जैसे वाणिज्यिक प्राधिकरणों से आवश्यक प्रमाणन प्राप्त करने के लिए विचार किया जाने वाला एक महत्वपूर्ण दस्तावेज़ था। हालांकि, Federal Aviation Regulations ने 2013 में DO-178C को एयरवर्दीनेस अनुपालन प्रदर्शित करने के एक तरीके के रूप में स्वीकार किया। DO-178B और DO-178C मानकों के बारे में अधिक सामान्य जानकारी के लिए, आप यह लेख पढ़ सकते हैं।
DO-178B या DO178C मानकों को निम्नलिखित उदाहरण दस्तावेज़ों और अन्य के साथ पूरा किया जाना चाहिए।
- PSAC (Plan for Software Aspects of Certification)
- SDP (Software Development Plan)
- SVP (Software Verification Plan)
- SCMP (Software Configuration Management Plan)
- SQAP (Software Quality Assurance Plan)
- SAS (Software Accomplishment Summary)
DO-178B और DO-178C मानकों को पूरा करने के लिए आवश्यक दस्तावेज़ इन्हीं तक सीमित नहीं हैं। ऐसे कई अन्य दस्तावेज़ हैं जो एयरवर्दीनेस को समृद्ध करेंगे। आप ये दस्तावेज़ यहां देख और खरीद सकते हैं।
DO178 दस्तावेज़
PSAC दस्तावेज़
PSAC (Plan for Software Aspects of Certification) दस्तावेज़, जीवनचक्र डेटा तैयार करने के अलावा, पालन किए जाने वाले आवश्यक मानकों, प्रक्रियाओं, प्रोटोकॉल और पद्धतियों की व्याख्या करता है। इस प्रकार, DO-178 मानकों को पूरा किया जा सकता है। PSAC सॉफ़्टवेयर विकास की समय-सारिणी और समग्र सिस्टम स्थिति को भी निर्दिष्ट करता है। अनुमोदन देने वाला प्राधिकरण और आवेदक दोनों इस दस्तावेज़ से लाभान्वित होते हैं। PSAC प्रारंभिक सॉफ़्टवेयर योजना प्रक्रिया के दौरान तैयार किया जाना चाहिए और प्रमाणन प्राधिकरण द्वारा अनुमोदित होना चाहिए। हमारे PSAC दस्तावेज़ की जांच के लिए कृपया यहां क्लिक करें।
SDP दस्तावेज़
SDP (Software Development Plan) दस्तावेज़ का उद्देश्य यह जांचना है कि विकास प्रक्रियाएं, प्रोटोकॉल, मानक, जीवनचक्र और विकास वातावरण जैसी आवश्यक जानकारी निर्धारित की गई है या नहीं। SDP दस्तावेज़ सॉफ़्टवेयर योजना प्रक्रिया का एक महत्वपूर्ण हिस्सा है। हमारे SDP दस्तावेज़ की जांच के लिए कृपया यहां क्लिक करें।
SVP दस्तावेज़
SVP (Software Verification Plan) दस्तावेज़ उचित संस्करण नियंत्रण प्रदान करते हुए आवश्यक परीक्षण परिदृश्यों और कवरेज, प्रक्रियाओं, प्रोटोकॉल, आवश्यकता सत्यापन, और स्रोत कोड सत्यापन को निर्दिष्ट करता है। SVP भी योजना प्रक्रिया का एक महत्वपूर्ण हिस्सा है। हमारे SVP दस्तावेज़ की जांच के लिए कृपया यहां क्लिक करें।
SCMP दस्तावेज़
SCMP (Software Configuration Management Plan) दस्तावेज़ योजना प्रक्रिया का एक और महत्वपूर्ण तत्व है। सॉफ़्टवेयर विकास प्रक्रिया के दौरान तैयार की गई प्रारंभिक योजना में अक्सर बदलाव होते हैं। SCMP हमें इन बदलावों का पता लगाने, नियंत्रित करने, बनाए रखने और ट्रैक करने में मदद करता है। इसे पूरी सॉफ़्टवेयर विकास प्रक्रिया के दौरान लागू किया जाता है। SCMP का लक्ष्य त्रुटियों को न्यूनतम करना और दक्षता को अधिकतम करना है। टीम के सदस्यों को एक-दूसरे को बदलावों की रिपोर्ट और सूचना देने का प्रयास करना चाहिए। हमारे SCMP दस्तावेज़ की जांच के लिए कृपया यहां क्लिक करें।
SQAP दस्तावेज़
SQAP (Software Quality Assurance Plan) दस्तावेज़ में वे उपकरण, तरीके और तकनीकें शामिल हैं जिनका उपयोग यह सुनिश्चित करने के लिए किया जाता है कि कोई उत्पाद या सेवा SRS (Software Requirement specification) में दी गई विशिष्टताओं को पूरा करती है। SQAP बताता है कि परियोजना में Software Quality Assurance गतिविधियां कैसे संचालित की जाएंगी। SQA टीम मील के पत्थर स्थापित करती है और प्रत्येक मील के पत्थर पर परियोजना की गुणवत्ता का मूल्यांकन करती है। SQA पूरे सॉफ़्टवेयर जीवनचक्र के दौरान संचालित किया जाता है। हमारे SQAP दस्तावेज़ की जांच के लिए कृपया यहां क्लिक करें
SAS दस्तावेज़
SAS (Software Accomplishment Summary) विकास और सत्यापन प्रक्रियाओं के दौरान सॉफ़्टवेयर घटकों के हर चरण का सारांश प्रस्तुत करता है। SAS में सत्यापन उपकरण योग्यता से प्राप्त निष्कर्षों का सारांश शामिल होना चाहिए। FAA को SAS के बारे में सूचित किया जाना चाहिए। यह प्रमाणन प्राधिकरण को सत्यापन डेटा निष्कर्षों का सत्यापन प्रदान करता है और उपकरण की योग्यता स्थिति के प्रमाण के रूप में काम करता है। हमारे SAS दस्तावेज़ की जांच के लिए कृपया यहां क्लिक करें
ARP4754 मानक और DO178 मानक
ARP4754 "Aerospace Recommended Practice ARP4754A Guidelines for Development of Civil Aircraft and Systems" का संक्षिप्त रूप है। ARP4754 मानक पूरे विमान प्रणालियों के लिए मार्गदर्शन प्रदान करते हैं, जबकि DO178 मानक केवल फ्लाइट सॉफ़्टवेयर के लिए उपयोग किए जाते हैं। दोनों मानक FAA और EASA जैसे प्राधिकरणों द्वारा स्वीकार किए जाते हैं।
ARP4754 को 1996 में SAE (Society of Automotive Engineers) द्वारा विकसित और प्रकाशित किया गया था। 2010 में, SAE ने ARP4754A प्रकाशित किया, जो Guidelines for Development of Civil Aircraft and Systems का संक्षिप्त रूप है। ARP4754A विमान और सिस्टम स्तरों पर उपयोग किए जाने वाले डिज़ाइन आश्वासन के विचार को समृद्ध करता है, और विकास आश्वासन शब्द के उपयोग को भी मानकीकृत करता है। ARP4754 को नवंबर 2011 में FAA द्वारा अनुमोदित किया गया था।
ARP4754 आवश्यकता पहचान से लेकर एकीकरण और सत्यापन प्रक्रियाओं के अंत तक पूरे विमान विकास चक्र को कवर करता है। ARP4754 विमानों, प्रणालियों और घटकों के लिए अमूर्तीकरण प्रदान करता है। घटक डिज़ाइन के लिए, ARP4754 स्पष्ट रूप से DO-178 और DO-254 का संदर्भ देता है। ARP4754 विकास, डिज़ाइन और सत्यापन जैसी विभिन्न प्रक्रियाओं के माध्यम से सुरक्षा मूल्यांकन पर केंद्रित है। हालांकि, यह ध्यान रखना चाहिए कि ARP4754 में सॉफ़्टवेयर या इलेक्ट्रॉनिक हार्डवेयर विकास, सेवा-में सुरक्षा गतिविधियों, और विमान संरचनात्मक विकास प्रक्रिया का विशिष्ट दायरा शामिल नहीं है।
डिज़ाइन चरण
Preliminary Design Review (PDR)
प्रारंभिक डिज़ाइन सॉफ़्टवेयर विकास प्रक्रिया का एक महत्वपूर्ण चरण है। प्रारंभिक डिज़ाइन के दौरान, सिस्टम आर्किटेक्चर बनाने के लिए उच्च-स्तरीय आवश्यकताओं और उपयोग के मामलों की पहचान की जाती है। इंटरफ़ेस, डेटाबेस और आर्किटेक्चर के लिए दस्तावेज़, और घटक संबंधों के लिए डायग्राम डिज़ाइन में उपयोग किए जा सकते हैं। प्रारंभिक डिज़ाइन इन इनपुट के आधार पर परियोजना की शुरुआत में सिस्टम का एक दृश्य चित्रण प्रदान करेगा। प्रारंभिक डिज़ाइन आगे के अधिक विस्तृत डिज़ाइन चरणों की नींव भी रखता है। इसे एक ड्राफ्ट के रूप में देखा जा सकता है।
Preliminary Design Review (PDR) परियोजना के प्रारंभिक डिज़ाइन चरण को समाप्त करता है। PDR को विस्तृत डिज़ाइन के साथ आगे बढ़ने के लिए पर्याप्त आश्वासन प्रदान करना चाहिए। PDR का उद्देश्य यह सुनिश्चित करना है कि प्रारंभिक डिज़ाइन और बुनियादी सिस्टम आर्किटेक्चर पूर्ण हैं, और यह तकनीकी विश्वास है कि आवश्यकताओं को बजट और शेड्यूल के भीतर पूरा किया जा सकता है।
Critical Design Review (CDR)
Critical Design Review (CDR) परियोजना के क्रिटिकल डिज़ाइन चरण को समाप्त करता है। व्यापक विश्लेषण, सिमुलेशन, स्कीमैटिक्स, सॉफ़्टवेयर कोड और परीक्षण डेटा के माध्यम से CDR के ज़रिए अंतिम डिज़ाइन प्रस्तुत किए जाते हैं। CDR यह सुनिश्चित करता है कि सिस्टम परीक्षण और उत्पादन की ओर आगे बढ़ सकता है। यह यह भी बताता है कि संबंधित आवश्यकताओं को बजट और समय-सीमा के भीतर पूरा किया जा सकता है। परिणामी व्यापक ड्रॉइंग और विशिष्टताएं एक प्रारंभिक उत्पाद बेसलाइन के साथ-साथ एक अंतिम बेसलाइन प्रदान करती हैं। CDR का दायरा व्यापक और विस्तृत होना चाहिए।
Final Design चरण
Final Design चरण परियोजना में प्रत्येक घटक के विस्तृत स्थापत्य और इंजीनियरिंग ड्रॉइंग प्रदान करता है। कुछ परियोजनाओं के लिए, एक अंतिम डिज़ाइन रिपोर्ट बनाने की आवश्यकता हो सकती है। अंतिम डिज़ाइन चरण पूरा होने से पहले पहचानी गई डिज़ाइन समस्याओं को हल किया जाना चाहिए। ड्रॉइंग और रिपोर्ट में नियोजित अनुमानों को सक्षम बनाने के लिए पर्याप्त विवरण होना चाहिए। अंतिम डिज़ाइन रिपोर्ट में एक अद्यतन समय-सीमा, लागत अनुमान और विशिष्टताएं शामिल होनी चाहिए। यह भी पुष्टि की जानी चाहिए कि परियोजना आर्थिक रूप से व्यवहार्य है। Final Design चरण के दौरान किए गए किसी भी बदलाव अन्य चरणों की तुलना में अधिक महंगे होते हैं। इसलिए, इन्हें बहुत सावधानी से किया जाना चाहिए।
SOI (Stages of Involvement)
परियोजनाओं के DO-178B अनुपालन का मूल्यांकन करने के लिए, SOI मूल्यांकन संबंधित देशों के विमानन प्राधिकरणों द्वारा परियोजना के विभिन्न चरणों जैसे योजना, विकास और सत्यापन में आयोजित किए जाते हैं। आदर्श रूप से, कुल चार SOI समीक्षाओं की योजना बनाई जाती है।
पहला SOI मूल्यांकन परियोजना के प्रमाणन अनुपालन कार्य के योजना चरण को कवर करता है। दूसरी SOI समीक्षा परियोजना के विकास चरणों पर केंद्रित होती है। उच्च-स्तरीय सॉफ़्टवेयर आवश्यकताओं के विकास से शुरू होकर, यह जांचती है कि डिज़ाइन, निम्न-स्तरीय सॉफ़्टवेयर आवश्यकताएं, और स्रोत कोड DO178B के अनुरूप तैयार किए गए हैं या नहीं। तीसरी SOI समीक्षा सत्यापन चरणों पर केंद्रित होती है। न केवल परीक्षण गतिविधियां, बल्कि सत्यापन उद्देश्यों के लिए की गई सभी गतिविधियों की समीक्षा की जाती है। चौथी SOI परियोजना के अंत की ओर आयोजित की जाने वाली समापन मूल्यांकन है, जो यह जांचती है कि कोई लंबित गतिविधियां हैं या नहीं और पिछले मूल्यांकनों के बाद से कोई नई समस्याएं उत्पन्न हुई हैं या नहीं।
योजना चरण में तैयार सॉफ़्टवेयर उत्पादों से DO-178B की अपेक्षा प्राधिकरण और इसे संचालित करने वाली कंपनी के बीच नियमों के एक सामान्य सेट पर सहमति बनाना, और पूरी परियोजना में इस नियमों के सेट का पालन करना है। दूसरे शब्दों में, योजनाएं और मानक लिखते समय, कंपनी न केवल अपनी स्वयं की प्रक्रियाएं निर्धारित करती है बल्कि यह भी लिखती है कि पूरी प्रमाणन प्रक्रिया के दौरान प्राधिकरण स्वयं का मूल्यांकन कैसे करेगा।
Author: Can Önal ([email protected])
