RTCA DO-254, "Design Assurance Guidance For Airborne Electronic Hardware," विमानन इलेक्ट्रॉनिक हार्डवेयर उत्पादन के लिए प्राथमिक मार्गदर्शन है, जिसका नवीनतम संस्करण 2000 में प्रकाशित हुआ था। RTCA DO-254 एवियोनिक प्रणालियों के लिए डिज़ाइन जीवनचक्र आवश्यकताओं को निर्दिष्ट करता है और विमान इलेक्ट्रॉनिक हार्डवेयर की एयरवर्दीनेस के लिए दिशानिर्देश प्रदान करता है। DO-254, DO-178 की तरह, RTCA और EUROCAE के सहयोग से जारी किया गया था। DO-254 को विमानन में विभिन्न इलेक्ट्रॉनिक उपकरणों के बढ़ते उपयोग के जवाब में 2005 में FAA द्वारा आधिकारिक रूप से अपनाया गया था।
DO-254 अनुपालन यात्रियों, चालक दल और ऑपरेटरों की सुरक्षा बढ़ाने में मदद करता है, और आपके संगठन को मज़बूत बनाता है। इसके अतिरिक्त, चूंकि कुछ परियोजनाओं के लिए DO-254 अनुपालन आवश्यक है, यह आपकी कंपनी को इस अनुपालन को प्रदान न करने वाले अन्य निर्माताओं और डेवलपर्स की तुलना में प्रतिस्पर्धात्मक लाभ प्रदान करता है।
DO-254 प्रमाणन की मुख्य प्रक्रियाओं को इस प्रकार संक्षेप में प्रस्तुत किया जा सकता है:
- योजना प्रक्रिया
- विकास प्रक्रिया
- सत्यापन प्रक्रिया
योजना प्रक्रिया पूरी होने के बाद विकास प्रक्रिया शुरू होनी चाहिए, लेकिन सत्यापन प्रक्रिया परियोजना की शुरुआत से अंत तक की जानी चाहिए।
DO-254 मानकों को निम्नलिखित दस्तावेज़ों और अन्य के साथ पूरा किया जाना चाहिए:
- PHAC (Plan for Hardware Aspects of Certification)
- HVP (Hardware Verification Plan)
- HVP (Hardware Validation Plan)
- HPAP (Hardware Process Assurance Plan)
- HAS (Hardware Accomplishment Summary)
कुछ DO-178 दस्तावेज़ DO-254 दस्तावेज़ों के समान हो सकते हैं। आप हमारे DO-178 दस्तावेज़ यहां देख और खरीद सकते हैं।
DO254 दस्तावेज़
PHAC
PHAC (Plan for Hardware Aspects of Certification) योजना प्रक्रिया के दौरान तैयार किया जाना चाहिए और प्रमाणन प्राधिकरण द्वारा अनुमोदित होना चाहिए। PHAC प्रमाणपत्र आवेदक और प्रमाणन प्राधिकरण के बीच की जाने वाली प्रक्रियाओं और कार्रवाइयों, साथ ही प्रमाणन के हार्डवेयर पहलुओं को पूरा करने के लिए बनाए जाने वाले परिणामी साक्ष्य पर एक सहमति को दर्शाता है। इस योजना के भीतर, डेवलपर अपनी रणनीति और DO-254 को लागू करने के तरीके की व्याख्या करता है। हमारे PHAC दस्तावेज़ की समीक्षा के लिए कृपया यहां क्लिक करें।
Hardware Verification & Validation Plan
Hardware Verification Plan यह जांचता है कि क्या हार्डवेयर डिज़ाइन आवश्यकताओं को पूरा करता है। दूसरी ओर, Hardware Validation Plan का उपयोग यह जांचने के लिए किया जाता है कि हार्डवेयर उपयोगकर्ता की परिचालन और कार्यात्मक आवश्यकताओं को पूरा करता है या नहीं। जैसा कि पिछली परिभाषाओं में बताया गया है, सत्यापन और वैधीकरण के बीच मूलभूत अंतर वह वातावरण है जिसमें परीक्षण किए जाते हैं। सत्यापन प्रवाह में डिज़ाइन की शुद्धता की जांच डिज़ाइन आवश्यकताओं के विरुद्ध की जाती है। वैधीकरण प्रवाह के दौरान डिज़ाइन की शुद्धता का मूल्यांकन लक्षित उपयोगकर्ता की आवश्यकताओं के विरुद्ध किया जाता है। ये दस्तावेज़ भी योजना प्रक्रिया के हिस्से के रूप में तैयार किए जाने चाहिए।
HPAP
HPAP (Hardware Process Assurance Plan) यह जांचता है कि हार्डवेयर डिज़ाइन जीवनचक्र प्रक्रियाएं और डेटा पहचाने गए हैं या नहीं और अनुमोदित योजनाओं के अनुरूप हैं या नहीं। परिभाषित रणनीतियों सहित हार्डवेयर डिज़ाइन आश्वासन उद्देश्यों को पूरा करने के लिए आवश्यक तरीकों की सिफारिश प्रमाणन प्राधिकरण को की जाती है। हमारे HPAP दस्तावेज़ की समीक्षा के लिए कृपया यहां क्लिक करें।
HAS
HAS (Hardware Accomplishment Summary) हार्डवेयर पक्ष पर क्या हासिल किया गया है, इसके बारे में प्रमाणन प्राधिकरण को सूचित करता है। PHAC और HAS के बीच अंतर यह है कि PHAC के साथ आप प्रमाणन प्राधिकरण को बताते हैं कि आप क्या करने की योजना बना रहे हैं, जबकि HAS के साथ आप उन्हें बताते हैं कि आपने वास्तव में क्या किया। HAS को अनुमोदित PHAC दस्तावेज़ से विचलन भी दर्शाना चाहिए। HAS में हार्डवेयर पहचान जानकारी, हार्डवेयर स्थिति, संस्करण इतिहास, और अनुपालन घोषणा शामिल होनी चाहिए। यह DO-178 अनुपालन के लिए उपयोग किए जाने वाले Software Accomplishment Summary दस्तावेज़ के समान भी है। HAS में सिस्टम और हार्डवेयर अवलोकन, हार्डवेयर डिज़ाइन जीवनचक्र विवरण, और हार्डवेयर जीवनचक्र डेटा पर अनुभाग शामिल होने चाहिए। हमारे HAS दस्तावेज़ की जांच के लिए कृपया यहां क्लिक करें।
डिज़ाइन चरण
प्रारंभिक डिज़ाइन चरण
प्रारंभिक डिज़ाइन चरण उस कार्यात्मक बेसलाइन से शुरू होता है जो वैचारिक डिज़ाइन के दौरान बनाई जाती है, और सिस्टम को बनाने के लिए संयोजित की जाने वाली उप-प्रणालियों के लिए सिस्टम-स्तरीय कार्यात्मक आवश्यकताओं को डिज़ाइन आवश्यकताओं में अनुवाद करने के साथ जारी रहता है। इस अनुवाद के लिए वैचारिक डिज़ाइन में शुरू किए गए आवश्यकता विश्लेषण को जारी रखने की आवश्यकता होती है। सिस्टम के हार्डवेयर, सॉफ़्टवेयर और कर्मियों के लिए विशिष्ट आवश्यकताओं को परिभाषित किया जाना चाहिए। लाभ/जोखिम विश्लेषण किए जाते हैं, और प्रारंभिक डिज़ाइन कार्य के परिणामस्वरूप एक आवंटित बेसलाइन बनती है जिसमें आवश्यकताओं को सिस्टम बनाने वाली अलग-अलग उप-प्रणालियों को सौंपा जाता है।
क्रिटिकल डिज़ाइन चरण
क्रिटिकल डिज़ाइन चरण एक बहु-विषयक तकनीकी प्रक्रिया है जो यह सुनिश्चित करती है कि कोई सिस्टम लागत, शेड्यूल और जोखिम की सीमाओं के भीतर निर्दिष्ट प्रदर्शन मानदंडों को पूरा करते हुए उत्पादन, प्रदर्शन और परीक्षण की ओर आगे बढ़ सके। उत्पाद बेसलाइन क्रिटिकल डिज़ाइन चरण के दौरान शुरू की जाती है। क्रिटिकल डिज़ाइन का उद्देश्य उत्पाद बेसलाइन में प्रत्येक कॉन्फ़िगरेशन आइटम के लिए उत्पाद विशिष्टताओं में परिभाषित सिस्टम के अंतिम डिज़ाइन का मूल्यांकन करना और यह सत्यापित करना है कि प्रत्येक कॉन्फ़िगरेशन आइटम को विस्तृत डिज़ाइन दस्तावेज़ों में शामिल किया गया है।
क्रिटिकल डिज़ाइन चरण एक Critical Design Review आयोजित करके पूरा किया जाता है। CDR यह सुनिश्चित करता है कि सिस्टम परीक्षण और उत्पादन की ओर आगे बढ़ सकता है। यह यह भी बताता है कि संबंधित आवश्यकताओं को बजट और शेड्यूल के भीतर पूरा किया जा सकता है। परिणामी व्यापक ड्रॉइंग और विशिष्टताएं एक प्रारंभिक उत्पाद बेसलाइन के साथ-साथ एक अंतिम बेसलाइन प्रदान करती हैं। CDR पूर्ण और व्यापक होना चाहिए।
अंतिम डिज़ाइन चरण
Final Design चरण में परियोजना के प्रत्येक घटक के सटीक स्थापत्य और तकनीकी ड्रॉइंग शामिल हैं। कुछ परियोजनाओं के लिए, एक अंतिम डिज़ाइन रिपोर्ट बनाना महत्वपूर्ण है। अंतिम डिज़ाइन चरण पूरा करने से पहले पहचानी गई सभी डिज़ाइन समस्याओं को हल किया जाना चाहिए। ड्रॉइंग और रिपोर्ट समय-सीमा प्रदान करने के लिए पर्याप्त विस्तृत होनी चाहिए। एक संशोधित समय-सीमा, लागत अनुमान, और आवश्यकताओं को अंतिम डिज़ाइन रिपोर्ट में शामिल किया जाना चाहिए। यह भी पुष्टि की जानी चाहिए कि परियोजना वित्तीय रूप से व्यावहारिक है। Final Design चरण के दौरान किए गए किसी भी बदलाव पिछले चरणों में किए गए बदलावों की तुलना में अधिक महंगे होते हैं। परिणामस्वरूप, इन्हें बहुत सावधानी से किया जाना चाहिए।
Author: Can Önal ([email protected])