Visual Paradigm Desktop | 
Visual Paradigm Online
जटिल प्रणालियों का अभियांत्रिकी करने के लिए केवल घटकों के डिजाइन करने से अधिक चाहिए; इरादे और कार्यान्वयन के बीच एक कठोर संबंध बनाना आवश्यक है। जैसे-जैसे प्रणालियों के दायरे में वृद्धि होती है, जिसमें सॉफ्टवेयर, हार्डवेयर, यांत्रिक संरचनाएं और संचालन तर्क शामिल होते हैं, विभाजन का जोखिम बढ़ता है। SysML के उपयोग से मॉडल-आधारित प्रणाली अभियांत्रिकी (MBSE) इस जटिलता को प्रबंधित करने के लिए ढांचा प्रदान करती है, लेकिन केवल तभी जब ट्रेसेबिलिटी सही तरीके से स्थापित की जाती है। यह मार्गदर्शिका विभिन्न अभियांत्रिकी क्षेत्रों में एक सुसंगत प्रणाली परिभाषा बनाए रखने के लिए आवश्यक संरचनात्मक पैटर्न का अध्ययन करती है।
SysML में ट्रेसेबिलिटी केवल रिपोर्टिंग विशेषता नहीं है; यह सत्यापन और मान्यता की रीढ़ है। आवश्यकताओं, डिजाइन तत्वों और परीक्षणों के बीच मजबूत संबंधों के बिना, प्रणाली संरचना अलग-अलग बंद कमरों के संग्रह के रूप में बन जाती है। अभियंताओं को यह समझना चाहिए कि भाषा का उपयोग कैसे करें ताकि डिजाइन अनुक्रमण और क्षेत्र स्थानांतरण के दौरान भी टिके रहने वाले मजबूत संबंध बनाए जा सकें।
पैटर्न के कार्यान्वयन से पहले, भाषा के आधारभूत तंत्रों को समझना आवश्यक है। SysML ट्रेसेबिलिटी को मुख्य रूप से ट्रेससंबंध के माध्यम से परिभाषित करता है, जिसे विभिन्न तत्वों के बीच लागू किया जा सकता है। यह संबंध मानक संरचनात्मक या व्यवहारात्मक संबंधों से अलग है।
आवश्यकता तत्व: ये यह निर्धारित करते हैं कि प्रणाली क्या करनी चाहिए। ये ट्रेसेबिलिटी नेटवर्क के आधार हैं।
ब्लॉक परिभाषा आरेख (BDD): भौतिक और तार्किक संरचना को परिभाषित करते हैं।
आंतरिक ब्लॉक आरेख (IBD): आंतरिक इंटरफेस और प्रवाह को परिभाषित करते हैं।
पैरामीट्रिक आरेख: सीमाएं और गणितीय संबंधों को परिभाषित करते हैं।
सत्यापन परीक्षण: आवश्यकता प्रकार या अलग सत्यापन आवश्यकताओं के रूप में आमतौर पर प्रस्तुत किया जाता है।
ट्रेसेबिलिटी का मुख्य निर्देश यह सुनिश्चित करना है कि प्रत्येक आवश्यकता एक डिजाइन तत्व द्वारा संतुष्ट हो और एक परीक्षण मामले द्वारा सत्यापित हो। इससे साक्ष्य का एक बंद लूप बनता है। बहु-क्षेत्रीय प्रणालियों में, इस लूप को विभिन्न तकनीकी भाषाओं और अभियांत्रिकी विषयों के बीच फैलना चाहिए।
विभिन्न अभियांत्रिकी प्रश्नों के लिए विभिन्न ट्रेसेबिलिटी पैटर्न की आवश्यकता होती है। एक सामान्य दृष्टिकोण अक्सर गड़बड़ी या पर्याप्त दृश्यता के अभाव का कारण बनता है। नीचे प्रणाली की जानकारी को संरचित करने के लिए उपयोग किए जाने वाले प्राथमिक पैटर्न दिए गए हैं।
अग्रगामी ट्रेसेबिलिटी आवश्यकता से शुरू होती है और डिजाइन और कार्यान्वयन की ओर नीचे की ओर बढ़ती है। यह प्रश्न का उत्तर देती है: “कौन से डिजाइन तत्व इस आवश्यकता को संतुष्ट करते हैं?”
दिशा: आवश्यकता → डिजाइन → कार्यान्वयन।
उपयोग केस:यह सुनिश्चित करना कि कोई भी आवश्यकता अकार्यान्वित न छूटे।
लाभ: यह सुनिश्चित करके स्कोप क्रीप को रोकता है कि प्रत्येक मांगी गई विशेषता आर्किटेक्चर में संबोधित की गई है।
कार्यान्वयन: उपयोग करें deriveReqt या संशोधित करें संबंधों का उपयोग आवश्यकताओं को ब्लॉक या उपयोग केस से जोड़ने के लिए करें।
उलटी ट्रेसेबिलिटी डिज़ाइन तत्व से उत्पत्ति आवश्यकता तक ऊपर की ओर जाती है। यह प्रश्न का उत्तर देती है: “इस घटक का अस्तित्व क्यों है?”
दिशा: डिज़ाइन/कार्यान्वयन → आवश्यकता।
उपयोग केस:मॉडल में आवश्यकता से अधिक तत्वों या मृत कोड की पहचान करना।
लाभ: यदि एक विशिष्ट घटक को संशोधित किया जाता है, तो कौन सी आवश्यकताएं प्रभावित होंगी, इसका प्रदर्शन करके परिवर्तन प्रबंधन का समर्थन करता है।
कार्यान्वयन: आवश्यकता आरेख में विशिष्ट आवश्यकताओं के लिए IBD में ब्लॉक को वापस जोड़ें।
इस पैटर्न में आगे और पीछे के संबंधों को मिलाकर एक पूर्ण सत्यापन श्रृंखला बनाई जाती है। यह सुरक्षा-महत्वपूर्ण प्रणालियों के लिए स्वर्ण मानक है।
दिशा: आवश्यकता ↔ डिज़ाइन ↔ परीक्षण।
उपयोग केस: प्रमाणीकरण प्रक्रियाएं और नियामक सुसंगतता।
लाभ: ऑडिट और सुरक्षा मामलों के लिए पूर्ण कवरेज सुनिश्चित करता है।
बहु-क्षेत्रीय प्रणालियों में, सॉफ्टवेयर आवश्यकता को हार्डवेयर ब्लॉक से जोड़ना होता है, जो यांत्रिक सीमा से जुड़ता है। इस पैटर्न अलग-अलग इंजीनियरिंग भाषाओं के बीच के अंतर को पार करता है।
दिशा: सॉफ्टवेयर आवश्यकता → फर्मवेयर → विद्युत ब्लॉक → यांत्रिक सीमा।
उपयोग केस: साइबर-भौतिक प्रणालियाँ जहाँ व्यवहार भौतिक गुणों पर निर्भर करता है।
लाभ: सुनिश्चित करता है कि सॉफ्टवेयर विशेषता किसी भौतिक सीमा का उल्लंघन नहीं करती है।
इन पैटर्न को व्यवस्थित करने के लिए एक संरचित दृष्टिकोण की आवश्यकता होती है। एक मैट्रिक्स फॉर्मेट अक्सर संबंधों को दृश्यमान बनाने का सबसे प्रभावी तरीका होता है। नीचे दी गई तालिका एक व्यापक ट्रेसेबिलिटी मैट्रिक्स के लिए सिफारिश किए गए कॉलम को चिह्नित करती है।
|
आवश्यकता पहचान |
आवश्यकता पाठ |
स्रोत |
डिज़ाइन तत्व पहचान |
डिज़ाइन तत्व प्रकार |
प्रमाणीकरण विधि |
परीक्षण मामला पहचान |
स्थिति |
|---|---|---|---|---|---|---|---|
|
REQ-001 |
प्रणाली को स्टार्टअप अनुक्रम शुरू करना चाहिए |
हितधारक |
BLOCK-100 |
नियंत्रण तर्क |
विश्लेषण |
TEST-001 |
प्रमाणित किया गया |
|
REQ-002 |
पावर उपभोग < 5W |
नियामक |
PARAM-200 |
सीमा |
सिमुलेशन |
TEST-002 |
प्रगति में |
|
REQ-003 |
आवरण को टक्कर का सामना करना चाहिए |
पर्यावरणीय |
MECH-300 |
यांत्रिक भाग |
भौतिक परीक्षण |
TEST-003 |
अनुमोदित |
एक संरचित मैट्रिक्स का उपयोग करने से यह सुनिश्चित होता है कि समीक्षा प्रक्रिया के दौरान कोई भी कॉलम छोड़ा न जाए। इससे इंजीनियर को प्रत्येक अनिवार्य आवश्यकता के लिए सत्यापन विधि को विचार करने के लिए मजबूर किया जाता है।
जटिल प्रणालियाँ अक्सर एक ही इंजीनियरिंग क्षेत्र से नहीं बनती हैं। इनमें सॉफ्टवेयर, इलेक्ट्रॉनिक्स, यांत्रिकी और संचालन के बीच बातचीत शामिल होती है। प्रत्येक क्षेत्र का अपना जीवनचक्र और शब्दावली होती है, जिससे ट्रेसेबिलिटी कठिन हो जाती है।
सॉफ्टवेयर और हार्डवेयर के मिलने वाले स्थान पर सबसे आम तनाव बिंदु होता है। एक सॉफ्टवेयर आवश्यकता में कहा जा सकता है कि “प्रणाली 50ms के भीतर प्रतिक्रिया करेगी।” यह एक सामान्य बात है। इसे प्रोसेसर की गति और मेमोरी लेटेंसी को परिभाषित करने वाले हार्डवेयर ब्लॉक तक ट्रेस किया जाना चाहिए।
पैटर्न: एक का उपयोग करें सुधारेंसॉफ्टवेयर आवश्यकता से हार्डवेयर परिभाषा में एक कार्यात्मक ब्लॉक तक लिंक करें।
चुनौती:समय सीमाएँ अक्सर पैरामेट्रिक आरेखों में परिभाषित की जाती हैं, जबकि तर्क राज्य मशीनों में परिभाषित किया जाता है।
समाधान: एक निर्दिष्ट इंटरफेस ब्लॉक जो स्पष्ट रूप से समय गुणों को परिभाषित करता है और सॉफ्टवेयर आवश्यकता को इस इंटरफेस से जोड़ता है।
यांत्रिक सीमाएँ अक्सर संचालन सीमाओं को निर्धारित करती हैं। यदि एक यांत्रिक भाला अधिकतम टॉर्क के साथ है, तो संचालन मोड इस सीमा को दर्शाना चाहिए।
पैटर्न:संचालन उपयोग केस को उन यांत्रिक ब्लॉक्स से जोड़ें जिनसे वे बातचीत करते हैं।
चुनौती:संचालन आवश्यकताएँ अक्सर प्राकृतिक भाषा में लिखी जाती हैं, जबकि यांत्रिक मॉडल गणितीय सीमाओं का उपयोग करते हैं।
समाधान:संचालन सीमाओं को पैरामेट्रिक सीमाओं में बदलें। आवश्यकता को पैरामेट्रिक आरेख में समीकरण से सीधे जोड़ें।
फर्मवेयर अक्सर उच्च स्तर के सॉफ्टवेयर और निम्न स्तर के भौतिक संकेतों के बीच चिपकाव के रूप में कार्य करता है। ट्रेसेबिलिटी को सुनिश्चित करना चाहिए कि फर्मवेयर ड्राइवर भौतिक सेंसर की क्षमताओं को सही तरीके से प्रदर्शित करे।
पैटर्न:फर्मवेयर कार्यों को विशिष्ट हार्डवेयर ड्राइवर्स के लिए आवंटित करने के लिए आवंटन संबंधों का उपयोग करें।
चुनौती:फर्मवेयर अपडेट भौतिक हार्डवेयर के बदले बिना हो सकते हैं।
समाधान:ट्रेसेबिलिटी लिंक्स पर वर्जनिंग रणनीति बनाए रखें। यदि फर्मवेयर बदलता है लेकिन आवश्यकता पूरी होती है, तो संबंध को तोड़ने के बजाय लिंक स्थिति को अपडेट करें।
ट्रेसेबिलिटी को लागू करना बिना बाधाओं के नहीं है। जटिल वातावरणों में कई सामान्य समस्याएँ उत्पन्न होती हैं। इन्हें जल्दी से पहचानने से बेहतर योजना बनाने में मदद मिलती है।
समय के साथ, आवश्यकताओं में परिवर्तन या डिजाइन विकास के कारण, लिंक अप्रासंगिक हो जाते हैं। एक आवश्यकता को हटा दिया जा सकता है, लेकिन लिंक अभी भी एक अस्तित्वहीन ब्लॉक की ओर इशारा करता रहता है।
नियंत्रण:बिल्ड प्रक्रिया के दौरान असंगत लिंक्स की जांच करने वाले स्वचालित सत्यापन स्क्रिप्ट्स को लागू करें।
नियंत्रण:प्रत्येक लिंक पर एक स्थिति फ्लैग की आवश्यकता होती है (उदाहरण के लिए, सक्रिय, प्राचीन, प्रतीक्षा में)।
कभी-कभी एक आवश्यकता एकल घटक के साथ जोड़ने के लिए बहुत उच्च स्तर की होती है, या एक घटक एकल आवश्यकता के साथ जोड़ने के लिए बहुत विस्तृत होता है। इससे एक बहुत-से-बहुत संबंध बनता है जिसे प्रबंधित करना मुश्किल होता है।
नियंत्रण:उच्च स्तर की आवश्यकताओं को निम्न स्तर की कार्यात्मक आवश्यकताओं में विभाजित करें जो सिस्टम ब्लॉक्स के साथ मेल खाती हों।
नियंत्रण:बहुत सी निम्न स्तर की घटकों को एक संयुक्त ब्लॉकमें समूहित करें और उसके बजाय उससे जोड़ें।
सॉफ्टवेयर � ingineers के पास यांत्रिक इंजीनियरों के विपरीत अलग टूल्स होते हैं। वे एक ही ट्रेसेबिलिटी संदर्भ को नहीं देख सकते।
नियंत्रण:एकल सच्चाई के स्रोत मॉडल रिपॉजिटरी को अपनाएं जो बाहरी क्षेत्र टूल्स के साथ एकीकरण को समर्थन देती हो।
नियंत्रण:सभी क्षेत्रों में सभी ट्रेसेबल तत्वों के लिए एक सामान्य नामकरण प्रणाली स्थापित करें।
ट्रेसेबिलिटी बनाए रखने के लिए अनुशासन की आवश्यकता होती है। यह एक बार की सेटअप नहीं है बल्कि एक निरंतर गतिविधि है।
जल्दी शुरू करें: अवधारणा चरण के दौरान ट्रेसेबिलिटी आवश्यकताओं को परिभाषित करें। लिंक जोड़ने के लिए डिज़ाइन चरण तक इंतजार न करें।
नामकरण मानकीकरण: एक संगत ID प्रारूप का उपयोग करें (उदाहरण के लिए, REQ-SYS-001, BLK-INT-001)। इससे स्वचालित खोज और रिपोर्टिंग संभव होती है।
नियमित ऑडिट: ट्रेसेबिलिटी ग्राफ की तिमाही समीक्षा की योजना बनाएं। टूटे हुए लिंक और अनाथ आवश्यकताओं की जांच करें।
जहां संभव हो, स्वचालित करें: असंगतियों को चिह्नित करने के लिए निर्मित मॉडल सत्यापन विशेषताओं का उपयोग करें। लिंक की हस्ताक्षरित सत्यापन से बचें।
पैटर्न को दस्तावेज़ीकृत करें: एक मानक संचालन प्रक्रिया (SOP) बनाएं जो यह निर्धारित करे कि लिंक कैसे बनाए जाएं, लेबल किए जाएं और बनाए रखे जाएं।
ट्रेसेबिलिटी नेटवर्क के स्वस्थ रहने की गारंटी देने के लिए विशिष्ट मापदंडों को ट्रैक किया जाना चाहिए। ये मापदंड सिस्टम परिभाषा की गुणवत्ता के बारे में दृश्यता प्रदान करते हैं।
इस मापदंड की गणना आवश्यकताओं के अनुपात के रूप में की जाती है जिनके कम से कम एक नीचे की ओर लिंक (डिज़ाइन या परीक्षण) हैं।
लक्ष्य: महत्वपूर्ण आवश्यकताओं का 100% कवरेज होना चाहिए।
मापन: (लिंक की गई आवश्यकताएं / कुल आवश्यकताएं) × 100।
इसके द्वारा एक सत्यापन विधि से जुड़ी आवश्यकताओं के अनुपात को मापा जाता है।
लक्ष्य: आवश्यकताओं का 100% के लिए एक सत्यापन विधि निर्धारित करनी चाहिए।
मापन: (परीक्षण/विश्लेषण के साथ आवश्यकताएं / कुल आवश्यकताएं) × 100।
इसके द्वारा समय के साथ लिंक के टूटने या बदले जाने की दर को ट्रैक किया जाता है।
लक्ष्य: परिवर्तन की कम दर स्थिर आवश्यकताओं को दर्शाती है।
मापन: (माहानुमाह टूटे हुए लिंक / कुल लिंक) × 100।
सुरक्षा-महत्वपूर्ण प्रणालियों में, एक साधारण लिंक अक्सर पर्याप्त नहीं होता है। प्रत्येक स्तर पर सुसंगतता को सिद्ध करने के लिए एक पदानुक्रमिक सत्यापन संरचना की आवश्यकता होती है।
स्तर 1: प्रणाली आवश्यकता (उदाहरण के लिए, “वाहन को 100 मीटर में रुकना चाहिए”)।
स्तर 2: उप-प्रणाली आवश्यकता (उदाहरण के लिए, “ब्रेक प्रणाली को 500 एन बल उत्पन्न करना चाहिए”)।
स्तर 3: घटक आवश्यकता (उदाहरण के लिए, “हाइड्रोलिक पंप को 10 लीटर/मिनट का प्रवाह करना चाहिए”)।
स्तर 4: कार्यान्वयन परीक्षण (उदाहरण के लिए, “पंप प्रवाह परीक्षण परिणाम”)।
यह पदानुक्रम सुनिश्चित करता है कि घटक स्तर पर एक विफलता को प्रणाली स्तर की आवश्यकता तक ट्रेस किया जा सकता है। इससे इंजीनियरों को तर्क के श्रृंखला में विफलता के ठीक स्थान को निर्धारित करने में सहायता मिलती है।
परिवर्तन अपरिहार्य है। जब कोई आवश्यकता बदलती है, तो प्रभाव विश्लेषण पूरी तरह से ट्रेसेबिलिटी लिंक पर निर्भर करता है।
प्रभाव विश्लेषण: जब कोई आवश्यकता संशोधित की जाती है, तो सभी नीचे की ओर जाने वाले लिंक को अनुसरण करें ताकि प्रभावित ब्लॉक, इंटरफेस और परीक्षण को पहचाना जा सके।
अनुमोदन प्रवाह: किसी आवश्यकता को बदलने से पहले प्रभावित सभी क्षेत्रों से अनुमोदन प्राप्त करना आवश्यक है। उदाहरण के लिए, यदि किसी सॉफ्टवेयर आवश्यकता को बदलने से प्रोसेसर लोड प्रभावित होता है, तो हार्डवेयर टीम से अनुमोदन प्राप्त करना आवश्यक हो सकता है।
संस्करण नियंत्रण: ट्रेसेबिलिटी ग्राफ का इतिहास बनाए रखें। यदि कोई लिंक हटाया जाता है, तो कारण का दस्तावेजीकरण करना आवश्यक है।
वास्तविक दुनिया की प्रणालियाँ अक्सर बाहरी स्रोतों से डेटा खींचती हैं, जैसे कि आपूर्तिकर्ता विवरण या सिमुलेशन परिणाम। SysML ट्रेसेबिलिटी को इन स्रोतों को एकीकृत करना चाहिए।
आपूर्तिकर्ता आवश्यकताएँ: आ inter आवश्यकताओं को बाहरी आपूर्तिकर्ता दस्तावेजों से जोड़ने के लिए सुधारें संबंधों का उपयोग करें।
सिमुलेशन परिणाम: संदर्भ बनाने के लिए पैरामेट्रिक आरेख सीमाओं के साथ सिमुलेशन आउटपुट फ़ाइलें जोड़ें।
समस्या ट्रैकिंग: बग ट्रैकर से दोषों या समस्याओं को सीधे उस आवश्यकता से जोड़ें जिसने उन्हें उत्पन्न किया।
बड़े प्रोजेक्ट्स में अक्सर विभिन्न उपप्रणालियों के लिए कई मॉडल शामिल होते हैं। ट्रेसेबिलिटी को इन मॉडल सीमाओं के बीच बनाए रखना आवश्यक है।
मॉडल आयात:अपनी पहचान और ट्रेसेबिलिटी लिंक्स बनाए रखते हुए एक मॉडल से दूसरे मॉडल में ब्लॉक्स को आयात करने के लिए रेफरेंस पैकेज का उपयोग करें।
इंटरफेस परिभाषा: मॉडल के बीच सख्त इंटरफेस को परिभाषित करें। ट्रेसेबिलिटी को अस्पष्ट संदर्भों के माध्यम से मॉडल सीमाओं को पार करने नहीं दें।
वैश्विक रजिस्ट्री: सभी आवश्यकताओं और उनकी अद्वितीय पहचान संख्याओं के एक केंद्रीय रजिस्ट्री को बनाए रखें ताकि मॉडल के बीच दोहराव रोका जा सके।
एक टिकाऊ ट्रेसेबिलिटी नेटवर्क बनाना एक रणनीतिक निवेश है। यह बदलाव की लागत को कम करता है, सत्यापन की आत्मविश्वास को बढ़ाता है, और सिस्टम के स्वास्थ्य के बारे में स्पष्ट दृश्यता प्रदान करता है। उपरोक्त वर्णित पैटर्न के अनुप्रयोग से, इंजीनियर बहु-क्षेत्रीय प्रणालियों की जटिलता को नियंत्रित कर सकते हैं बिना मूल इरादे को खोए।
इस क्षेत्र में सफलता अनुशासन, स्वचालन और आवश्यकताओं, डिजाइन और सत्यापन के बीच संबंधों की स्पष्ट समझ पर निर्भर करती है। ट्रेसेबिलिटी ग्राफ को एक जीवित कलाकृति के रूप में देखें जो प्रणाली के साथ बढ़ती और विकसित होती रहती है। नियमित रखरखाव और मान्यता सुनिश्चित करती है कि मॉडल प्रोजेक्ट के जीवनचक्र के दौरान एक विश्वसनीय सत्य स्रोत बना रहे।