गतिशील सिमुलेशन की प्रक्रिया में टीओआर आवश्यकताओं का स्वचालित सत्यापन

विषय को जारी रखना "आपके पास क्या सबूत है?"आइए गणितीय मॉडलिंग की समस्या को दूसरी तरफ से देखें। जब हम आश्वस्त हो जाते हैं कि मॉडल जीवन की घरेलू सच्चाई से मेल खाता है, तो हम मुख्य प्रश्न का उत्तर दे सकते हैं: "वास्तव में, हमारे पास यहाँ क्या है?" किसी तकनीकी वस्तु का मॉडल बनाते समय, हम आमतौर पर यह सुनिश्चित करना चाहते हैं कि यह वस्तु हमारी अपेक्षाओं को पूरा करेगी। इस प्रयोजन के लिए, प्रक्रियाओं की गतिशील गणना की जाती है और परिणाम की आवश्यकताओं के साथ तुलना की जाती है। यह एक डिजिटल ट्विन, एक वर्चुअल प्रोटोटाइप आदि है। फैशनेबल छोटे लोग, जो डिज़ाइन चरण में, इस समस्या का समाधान करते हैं कि यह कैसे सुनिश्चित किया जाए कि हमने जो योजना बनाई है वह हमें मिले।

हम जल्दी से यह कैसे सुनिश्चित कर सकते हैं कि हमारा सिस्टम बिल्कुल वैसा ही है जैसा हम डिज़ाइन करते हैं, क्या हमारा डिज़ाइन उड़ेगा या तैरेगा? और यदि यह उड़ता है, तो कितनी ऊँचाई तक? और यदि यह तैरता है, तो कितनी गहराई तक?

यह आलेख तकनीकी प्रणालियों के गतिशील मॉडल बनाते समय तकनीकी भवन की आवश्यकताओं के अनुपालन के सत्यापन के स्वचालन पर चर्चा करता है। उदाहरण के तौर पर, आइए एक विमान वायु शीतलन प्रणाली के तकनीकी विनिर्देश के एक तत्व को देखें।

हम उन आवश्यकताओं पर विचार करते हैं जिन्हें एक विशिष्ट गणना मॉडल के आधार पर संख्यात्मक रूप से व्यक्त किया जा सकता है और गणितीय रूप से सत्यापित किया जा सकता है। यह स्पष्ट है कि यह किसी भी तकनीकी प्रणाली के लिए सामान्य आवश्यकताओं का केवल एक हिस्सा है, लेकिन यह उनकी जांच पर है कि हम वस्तु के गतिशील मॉडल बनाने पर समय, तंत्रिकाएं और पैसा खर्च करते हैं।

दस्तावेज़ के रूप में तकनीकी आवश्यकताओं का वर्णन करते समय, कई प्रकार की विभिन्न आवश्यकताओं को प्रतिष्ठित किया जा सकता है, जिनमें से प्रत्येक को आवश्यकताओं की पूर्ति के स्वचालित सत्यापन के गठन के लिए अलग-अलग दृष्टिकोण की आवश्यकता होती है।

उदाहरण के लिए, आवश्यकताओं के इस छोटे लेकिन यथार्थवादी सेट पर विचार करें:

1. जल उपचार प्रणाली के प्रवेश द्वार पर वायुमंडलीय हवा का तापमान:
   पार्किंग स्थल में - माइनस 35 से 35 ºС तक,
   उड़ान में - माइनस 35 से 39 तक।
2. उड़ान में वायुमंडलीय वायु का स्थिर दबाव 700 से 1013 GPa (526 से 760 मिमी Hg तक) होता है।
3. उड़ान में एसवीओ वायु सेवन के प्रवेश द्वार पर कुल वायु दबाव 754 से 1200 जीपीए (566 से 1050 मिमी एचजी तक) है।
4. ठंडी हवा का तापमान:
   पार्किंग स्थल में - 27 ºС से अधिक नहीं, तकनीकी ब्लॉकों के लिए - 29 ºС से अधिक नहीं,
   उड़ान में - 25 ºС से अधिक नहीं, तकनीकी ब्लॉकों के लिए - 27 ºС से अधिक नहीं।
5. ठंडी हवा का प्रवाह:
   पार्क करने पर - कम से कम 708 किग्रा/घंटा,
   उड़ान में - 660 किग्रा/घंटा से कम नहीं।
6. उपकरण डिब्बों में हवा का तापमान 60 ºС से अधिक नहीं है।
7. ठंडी हवा में महीन मुक्त नमी की मात्रा 2 ग्राम/किग्रा शुष्क हवा से अधिक नहीं है।

आवश्यकताओं के इस सीमित सेट के भीतर भी, कम से कम दो श्रेणियां हैं जिन्हें सिस्टम में अलग-अलग तरीके से संभालने की आवश्यकता है:

• सिस्टम की परिचालन स्थितियों के लिए आवश्यकताएँ (खंड 1-3);
• सिस्टम के लिए पैरामीट्रिक आवश्यकताएँ (खंड 3-7)।

सिस्टम परिचालन स्थितियों की आवश्यकताएँ
मॉडलिंग के दौरान विकसित की जा रही प्रणाली के लिए बाहरी स्थितियों को सीमा स्थितियों के रूप में या सामान्य प्रणाली के संचालन के परिणामस्वरूप निर्दिष्ट किया जा सकता है।
गतिशील सिमुलेशन में, यह सुनिश्चित करना आवश्यक है कि निर्दिष्ट परिचालन स्थितियां सिमुलेशन प्रक्रिया द्वारा कवर की गई हैं।

पैरामीट्रिक सिस्टम आवश्यकताएँ
ये आवश्यकताएँ सिस्टम द्वारा ही प्रदान किए गए पैरामीटर हैं। मॉडलिंग प्रक्रिया के दौरान, हम इन मापदंडों को गणना परिणामों के रूप में प्राप्त कर सकते हैं और सुनिश्चित कर सकते हैं कि प्रत्येक विशिष्ट गणना में आवश्यकताओं को पूरा किया गया है।

आवश्यकताएँ पहचान और कोडिंग

आवश्यकताओं के साथ काम करने में आसानी के लिए, मौजूदा मानक प्रत्येक आवश्यकता के लिए एक पहचानकर्ता निर्दिष्ट करने की सलाह देते हैं। पहचानकर्ता निर्दिष्ट करते समय, एकीकृत कोडिंग प्रणाली का उपयोग करना अत्यधिक वांछनीय है।

एक आवश्यकता कोड बस एक संख्या हो सकती है जो आवश्यकता की क्रम संख्या का प्रतिनिधित्व करती है, या इसमें आवश्यकता के प्रकार के लिए एक कोड, उस सिस्टम या इकाई के लिए एक कोड हो सकता है जिस पर यह लागू होता है, एक पैरामीटर कोड, एक स्थान कोड, और एक इंजीनियर और कुछ भी कल्पना कर सकता है। (एन्कोडिंग के उपयोग के लिए लेख देखें)

तालिका 1 आवश्यकताओं कोडिंग का एक सरल उदाहरण प्रदान करती है।

1. आवश्यकताओं के स्रोत का कोड आर-आवश्यकताएँ टीके;
2. कोड प्रकार की आवश्यकताएँ ई - आवश्यकताएँ - पर्यावरणीय पैरामीटर, या परिचालन स्थितियाँ
   एस - सिस्टम द्वारा प्रदान की गई आवश्यकताएं;
3. विमान स्थिति कोड 0 - कोई भी, जी - पार्क किया हुआ, एफ - उड़ान में;
4. भौतिक पैरामीटर प्रकार कोड टी - तापमान, पी - दबाव, जी - प्रवाह दर, आर्द्रता एच;
5. आवश्यकता की क्रम संख्या.

ID आवश्यकताएँ	विवरण	प्राचल
REGT01	जल शीतलन प्रणाली के प्रवेश द्वार पर परिवेशी वायु का तापमान: पार्किंग स्थल में - शून्य से 35ºС तक। 35 ºС तक.
REFT01	वायु रक्षा प्रणाली के प्रवेश द्वार पर वायुमंडलीय हवा का तापमान: उड़ान में - शून्य से 35 डिग्री सेल्सियस से 39 डिग्री सेल्सियस तक।
REFP01	उड़ान में स्थैतिक वायुमंडलीय वायु दबाव 700 से 1013 hPa (526 से 760 मिमी Hg तक) होता है।
REFP02	उड़ान में एसवीओ वायु सेवन के प्रवेश द्वार पर कुल वायु दबाव 754 से 1200 एचपीए (566 से 1050 मिमी एचजी तक) है।
आरएसजीटी01	ठंडी हवा का तापमान: जब पार्क किया जाए तो 27 ºС से अधिक न हो
आरएसजीटी02	ठंडी हवा का तापमान: पार्किंग स्थल में, तकनीकी इकाइयों के लिए 29 ºС से अधिक नहीं
आरएसएफटी01	उड़ान में ठंडी हवा का तापमान 25 ºС से अधिक नहीं
आरएसएफटी02	ठंडी हवा का तापमान: उड़ान में, तकनीकी इकाइयों के लिए 27 ºС से अधिक नहीं
आरएसजीजी01	ठंडी हवा का प्रवाह: जब पार्क किया जाए तो 708 किग्रा/घंटा से कम न हो
आरएसएफजी01	ठंडी हवा का प्रवाह: उड़ान में 660 किग्रा/घंटा से कम नहीं
आरएस0टी01	उपकरण डिब्बों में हवा का तापमान 60 ºС से अधिक नहीं
आरएसएच01	ठंडी हवा में महीन मुक्त नमी की मात्रा 2 ग्राम/किग्रा शुष्क हवा से अधिक नहीं है

आवश्यकताएँ सत्यापन प्रणाली डिज़ाइन।

प्रत्येक डिज़ाइन आवश्यकता के लिए डिज़ाइन मापदंडों और आवश्यकता में निर्दिष्ट मापदंडों के पत्राचार का आकलन करने के लिए एक एल्गोरिदम है। कुल मिलाकर, किसी भी नियंत्रण प्रणाली में हमेशा डिफ़ॉल्ट रूप से आवश्यकताओं की जाँच के लिए एल्गोरिदम होते हैं। और यहां तक ​​कि किसी भी नियामक में वे शामिल हैं। यदि तापमान सीमा से बाहर चला जाता है, तो एयर कंडीशनर चालू हो जाता है। इस प्रकार, किसी भी विनियमन का पहला चरण यह जांचना है कि पैरामीटर आवश्यकताओं को पूरा करते हैं या नहीं।

और चूंकि सत्यापन एक एल्गोरिदम है, तो हम उन्हीं टूल्स और टूल्स का उपयोग कर सकते हैं जिनका उपयोग हम नियंत्रण प्रोग्राम बनाने के लिए करते हैं। उदाहरण के लिए, SimInTech वातावरण आपको मॉडल के विभिन्न भागों वाले प्रोजेक्ट पैकेज बनाने की अनुमति देता है, जो अलग-अलग प्रोजेक्ट (ऑब्जेक्ट मॉडल, कंट्रोल सिस्टम मॉडल, पर्यावरण मॉडल, आदि) के रूप में निष्पादित होते हैं।

इस मामले में आवश्यकता सत्यापन परियोजना एक ही एल्गोरिदम परियोजना बन जाती है और मॉडल पैकेज से जुड़ी होती है। और गतिशील मॉडलिंग मोड में यह तकनीकी विशिष्टताओं की आवश्यकताओं के अनुपालन के लिए एक विश्लेषण करता है।

सिस्टम डिज़ाइन का एक संभावित उदाहरण चित्र 1 में दिखाया गया है।

चित्र 1. सत्यापन परियोजना के डिज़ाइन का उदाहरण.

नियंत्रण एल्गोरिदम की तरह, आवश्यकताओं को शीट के एक सेट के रूप में तैयार किया जा सकता है। SimInTech, Simulink, AmeSim जैसे संरचनात्मक मॉडलिंग वातावरण में एल्गोरिदम के साथ काम करने की सुविधा के लिए, सबमॉडल के रूप में बहु-स्तरीय संरचनाएं बनाने की क्षमता का उपयोग किया जाता है। यह संगठन आवश्यकताओं की एक श्रृंखला के साथ काम को सरल बनाने के लिए विभिन्न आवश्यकताओं को सेट में समूहित करना संभव बनाता है, जैसा कि नियंत्रण एल्गोरिदम के लिए किया जाता है (चित्र 2 देखें)।

चित्र 2. आवश्यकताओं के सत्यापन मॉडल की पदानुक्रमित संरचना।

उदाहरण के लिए, विचाराधीन मामले में, दो समूहों को प्रतिष्ठित किया गया है: पर्यावरण के लिए आवश्यकताएँ और सीधे सिस्टम के लिए आवश्यकताएँ। इसलिए, दो-स्तरीय डेटा संरचना का उपयोग किया जाता है: दो समूह, जिनमें से प्रत्येक एल्गोरिदम का एक पत्ता है।

डेटा को मॉडल से जोड़ने के लिए, सिग्नल डेटाबेस बनाने के लिए एक मानक योजना का उपयोग किया जाता है, जो परियोजना के हिस्सों के बीच आदान-प्रदान के लिए डेटा संग्रहीत करता है।

सॉफ़्टवेयर बनाते और परीक्षण करते समय, नियंत्रण प्रणाली द्वारा उपयोग किए जाने वाले सेंसर (वास्तविक सिस्टम सेंसर के एनालॉग) की रीडिंग को इस डेटाबेस में रखा जाता है।
एक परीक्षण परियोजना के लिए, गतिशील मॉडल में गणना किए गए किसी भी पैरामीटर को उसी डेटाबेस में संग्रहीत किया जा सकता है और इस प्रकार यह जांचने के लिए उपयोग किया जाता है कि आवश्यकताएं पूरी हुई हैं या नहीं।

इस मामले में, डायनेमिक मॉडल को किसी भी गणितीय मॉडलिंग सिस्टम में या यहां तक ​​कि एक निष्पादन योग्य प्रोग्राम के रूप में भी निष्पादित किया जा सकता है। बाहरी वातावरण में मॉडलिंग डेटा जारी करने के लिए सॉफ्टवेयर इंटरफेस की उपस्थिति ही एकमात्र आवश्यकता है।

चित्र 3. सत्यापन परियोजना को जटिल मॉडल से जोड़ना।

बुनियादी आवश्यकताओं के सत्यापन पत्र का एक उदाहरण चित्र 4 में प्रस्तुत किया गया है। डेवलपर के दृष्टिकोण से, यह एक पारंपरिक गणना आरेख है जिस पर आवश्यकताओं के सत्यापन एल्गोरिदम को ग्राफिक रूप से प्रस्तुत किया गया है।

चित्र 4. आवश्यकताएँ जाँच पत्रक।

चेक शीट के मुख्य भाग चित्र 5 में वर्णित हैं। चेक एल्गोरिदम नियंत्रण एल्गोरिदम के डिज़ाइन आरेखों के समान ही बनता है। दाईं ओर डेटाबेस से सिग्नल पढ़ने के लिए एक ब्लॉक है। यह ब्लॉक सिमुलेशन के दौरान सिग्नल डेटाबेस तक पहुंचता है।

आवश्यकताओं के सत्यापन की स्थिति की गणना करने के लिए प्राप्त संकेतों का विश्लेषण किया जाता है। इस मामले में, विमान की स्थिति (चाहे वह पार्क किया गया हो या उड़ान में हो) निर्धारित करने के लिए ऊंचाई विश्लेषण किया जाता है। इस प्रयोजन के लिए, आप मॉडल के अन्य संकेतों और परिकलित मापदंडों का उपयोग कर सकते हैं।

जाँच की जा रही सत्यापन शर्तों और मापदंडों को मानक सत्यापन ब्लॉकों में स्थानांतरित कर दिया जाता है, जिसमें निर्दिष्ट आवश्यकताओं के अनुपालन के लिए इन मापदंडों का विश्लेषण किया जाता है। परिणाम सिग्नल डेटाबेस में इस तरह से दर्ज किए जाते हैं कि उनका उपयोग स्वचालित रूप से एक चेकलिस्ट तैयार करने के लिए किया जा सकता है।

चित्र 5. आवश्यकताओं के सत्यापन गणना पत्रक की संरचना।

परीक्षण किए जाने वाले पैरामीटर आवश्यक रूप से डेटाबेस में निहित संकेतों का उपयोग नहीं करते हैं, जो सिमुलेशन प्रक्रिया के दौरान गणना किए गए मापदंडों द्वारा नियंत्रित होते हैं। कुछ भी हमें ड्राफ्ट आवश्यकताओं के ढांचे के भीतर अतिरिक्त गणना करने से नहीं रोकता है, जैसे हम सत्यापन शर्तों की गणना करते हैं।

उदाहरण के लिए, यह आवश्यकता:

लक्ष्य तक उड़ान के दौरान सुधार प्रणाली की सक्रियता की संख्या 5 से अधिक नहीं होनी चाहिए, और सुधार प्रणाली का कुल संचालन समय 30 सेकंड से अधिक नहीं होना चाहिए।

इस मामले में, प्रारंभ की संख्या और कुल परिचालन समय का मुकाबला करने के लिए एक एल्गोरिदम आवश्यकताओं के डिज़ाइन आरेख में जोड़ा जाता है।

विशिष्ट आवश्यकताएँ सत्यापन ब्लॉक।

प्रत्येक मानक आवश्यकता चेक बॉक्स को एक निश्चित प्रकार की आवश्यकता की पूर्ति की गणना करने के लिए डिज़ाइन किया गया है। उदाहरण के लिए, पर्यावरणीय आवश्यकताओं में पार्क किए जाने और उड़ान के दौरान परिवेशीय परिचालन तापमान की एक सीमा शामिल होती है। इस ब्लॉक को एक पैरामीटर के रूप में मॉडल में हवा का तापमान प्राप्त करना होगा और यह निर्धारित करना होगा कि क्या यह पैरामीटर निर्दिष्ट तापमान सीमा को कवर करता है।/p>

ब्लॉक में दो इनपुट पोर्ट, परम और कंडीशन शामिल हैं।

पहले वाले को जांचे जा रहे पैरामीटर के साथ फीड किया जाता है। इस मामले में, "बाहरी तापमान"।

एक बूलियन वैरिएबल को दूसरे पोर्ट पर आपूर्ति की जाती है - चेक करने की शर्त।

यदि दूसरे इनपुट पर TRUE (1) प्राप्त होता है, तो ब्लॉक एक आवश्यकता सत्यापन गणना करता है।

यदि दूसरा इनपुट FALSE (0) प्राप्त करता है, तो परीक्षण शर्तें पूरी नहीं होती हैं। यह आवश्यक है ताकि गणना की शर्तों को ध्यान में रखा जा सके। हमारे मामले में, इस इनपुट का उपयोग मॉडल की स्थिति के आधार पर चेक को सक्षम या अक्षम करने के लिए किया जाता है। यदि विमान सिमुलेशन के दौरान जमीन पर है, तो उड़ान से संबंधित आवश्यकताओं की जांच नहीं की जाती है, और इसके विपरीत - यदि विमान उड़ान में है, तो स्टैंड पर संचालन से संबंधित आवश्यकताओं की जांच नहीं की जाती है।

इस इनपुट का उपयोग मॉडल स्थापित करते समय भी किया जा सकता है, उदाहरण के लिए गणना के प्रारंभिक चरण में। जब मॉडल को आवश्यक स्थिति में लाया जाता है, तो चेक ब्लॉक अक्षम हो जाते हैं, लेकिन जैसे ही सिस्टम आवश्यक ऑपरेटिंग मोड पर पहुंचता है, चेक ब्लॉक चालू हो जाते हैं।

इस ब्लॉक के पैरामीटर हैं:

• सीमा शर्तें: ऊपरी (अपलिमिट) और निचली (डाउनलिमिट) सीमा सीमाएं जिनकी जांच की जानी चाहिए;
• सीमा सीमाओं पर आवश्यक सिस्टम एक्सपोज़र समय (टाइमइंटरवल) सेकंड में;
• अनुरोध आईडी ReqName;
• सीमा से अधिक की अनुमति आउट_रेंज एक बूलियन वैरिएबल है जो यह निर्धारित करता है कि चेक की गई सीमा से अधिक का मान आवश्यकता का उल्लंघन है या नहीं।

कुछ मामलों में, परीक्षण मूल्य आउटपुट इंगित करता है कि सिस्टम में कुछ मार्जिन है और यह अपने ऑपरेटिंग रेंज के बाहर काम कर सकता है। अन्य मामलों में, आउटपुट का मतलब है कि सिस्टम सेटपॉइंट को सीमा के भीतर रखने में असमर्थ है।

चित्र 6. आरेख और उसके मापदंडों में एक विशिष्ट संपत्ति जांच ब्लॉक।

इस ब्लॉक की गणना के परिणामस्वरूप, आउटपुट पर परिणाम चर बनता है, जो निम्नलिखित मान लेता है:

• 0 - कोई नहीं, मान परिभाषित नहीं है;
• 1 - आर हो गया, आवश्यकता पूरी हो गई;
• 2 - rFault, आवश्यकता पूरी नहीं हुई।

ब्लॉक छवि में शामिल हैं:

• पहचानकर्ता पाठ;
• माप सीमा मापदंडों के डिजिटल डिस्प्ले;
• पैरामीटर स्थिति का रंग पहचानकर्ता।

ब्लॉक के अंदर एक जटिल तार्किक अनुमान सर्किट हो सकता है।

उदाहरण के लिए, चित्र 6 में दिखाई गई इकाई के ऑपरेटिंग तापमान रेंज की जांच करने के लिए, आंतरिक सर्किट को चित्र 7 में दिखाया गया है।

चित्र 7. तापमान सीमा निर्धारण इकाई का आंतरिक आरेख।

सर्किट ब्लॉक के अंदर, ब्लॉक मापदंडों में निर्दिष्ट गुणों का उपयोग किया जाता है।
आवश्यकताओं के अनुपालन का विश्लेषण करने के अलावा, ब्लॉक के आंतरिक आरेख में सिमुलेशन परिणाम प्रदर्शित करने के लिए आवश्यक ग्राफ़ होता है। इस ग्राफ़ का उपयोग गणना के दौरान देखने और गणना के बाद परिणामों का विश्लेषण करने के लिए किया जा सकता है।

गणना परिणाम ब्लॉक के आउटपुट में प्रेषित होते हैं और साथ ही एक सामान्य रिपोर्ट फ़ाइल में दर्ज किए जाते हैं, जो पूरे प्रोजेक्ट के परिणामों के आधार पर बनाई जाती है। (चित्र 8 देखें)

सिमुलेशन परिणामों के आधार पर बनाई गई रिपोर्ट का एक उदाहरण किसी दिए गए प्रारूप के अनुसार बनाई गई एक HTML फ़ाइल है। प्रारूप को किसी विशेष संगठन द्वारा स्वीकृत प्रारूप में मनमाने ढंग से कॉन्फ़िगर किया जा सकता है।

सर्किट ब्लॉक के अंदर, ब्लॉक मापदंडों में निर्दिष्ट गुणों का उपयोग किया जाता है।
आवश्यकताओं के अनुपालन का विश्लेषण करने के अलावा, ब्लॉक के आंतरिक आरेख में सिमुलेशन परिणाम प्रदर्शित करने के लिए आवश्यक ग्राफ़ होता है। इस ग्राफ़ का उपयोग गणना के दौरान देखने और गणना के बाद परिणामों का विश्लेषण करने के लिए किया जा सकता है।

गणना परिणाम ब्लॉक के आउटपुट में प्रेषित होते हैं और साथ ही एक सामान्य रिपोर्ट फ़ाइल में दर्ज किए जाते हैं, जो पूरे प्रोजेक्ट के परिणामों के आधार पर बनाई जाती है। (चित्र 8 देखें)

सिमुलेशन परिणामों के आधार पर बनाई गई रिपोर्ट का एक उदाहरण किसी दिए गए प्रारूप के अनुसार बनाई गई एक HTML फ़ाइल है। प्रारूप को किसी विशेष संगठन द्वारा स्वीकृत प्रारूप में मनमाने ढंग से कॉन्फ़िगर किया जा सकता है।

चित्र 8. सिमुलेशन परिणामों पर आधारित रिपोर्ट फ़ाइल का उदाहरण।

इस उदाहरण में, रिपोर्ट फॉर्म सीधे प्रोजेक्ट गुणों में कॉन्फ़िगर किया गया है, और तालिका में प्रारूप वैश्विक प्रोजेक्ट सिग्नल के रूप में सेट किया गया है। इस मामले में, SimInTech स्वयं रिपोर्ट स्थापित करने की समस्या को हल करता है, और किसी फ़ाइल में परिणाम लिखने के लिए ब्लॉक रिपोर्ट फ़ाइल में लिखने के लिए इन पंक्तियों का उपयोग करता है।

चित्र 9. वैश्विक परियोजना संकेतों में रिपोर्ट प्रारूप सेट करना

आवश्यकताओं के लिए सिग्नल डेटाबेस का उपयोग करना।

संपत्ति सेटिंग्स के साथ काम को स्वचालित करने के लिए, प्रत्येक विशिष्ट ब्लॉक के लिए सिग्नल डेटाबेस में एक मानक संरचना बनाई जाती है। (चित्र 10 देखें)

चित्र 10. सिग्नल डेटाबेस में आवश्यकता चेक ब्लॉक की संरचना का उदाहरण।

सिग्नल डेटाबेस प्रदान करता है:

• सभी आवश्यक सिस्टम आवश्यकता पैरामीटर संग्रहीत करना।
• निर्दिष्ट मापदंडों और वर्तमान मॉडलिंग परिणामों से मौजूदा परियोजना आवश्यकताओं को सुविधाजनक रूप से देखना।
• स्क्रिप्टिंग प्रोग्रामिंग भाषा का उपयोग करके एक ब्लॉक या ब्लॉकों का समूह स्थापित करना। सिग्नल डेटाबेस में परिवर्तन से आरेख में ब्लॉक संपत्ति मूल्यों में परिवर्तन होता है।
• आवश्यकता प्रबंधन प्रणाली में पाठ विवरण, तकनीकी विशिष्टताओं वाली वस्तुओं के लिंक या पहचानकर्ताओं को संग्रहीत करना।

आवश्यकताओं के लिए सिग्नल डेटाबेस संरचनाओं को तृतीय-पक्ष आवश्यकताओं प्रबंधन प्रणाली के साथ काम करने के लिए आसानी से कॉन्फ़िगर किया जा सकता है। आवश्यकताओं प्रबंधन प्रणालियों के साथ बातचीत का एक सामान्य आरेख चित्र 11 में प्रस्तुत किया गया है।

चित्र 11. आवश्यकता प्रबंधन प्रणाली के साथ बातचीत का आरेख।

SimInTech परीक्षण परियोजना और आवश्यकता नियंत्रण प्रणाली के बीच बातचीत का क्रम इस प्रकार है:

1. संदर्भ की शर्तें आवश्यकताओं में विभाजित हैं।
2. तकनीकी विशिष्टताओं की आवश्यकताओं की पहचान की जाती है जिन्हें तकनीकी प्रक्रियाओं के गणितीय मॉडलिंग द्वारा सत्यापित किया जा सकता है।
3. चयनित आवश्यकताओं की विशेषताओं को मानक ब्लॉकों (उदाहरण के लिए, अधिकतम और न्यूनतम तापमान) की संरचना में सिमइनटेक सिग्नल डेटाबेस में स्थानांतरित किया जाता है।
4. गणना प्रक्रिया के दौरान, संरचना डेटा को ब्लॉक डिज़ाइन आरेखों में स्थानांतरित किया जाता है, विश्लेषण किया जाता है और परिणाम सिग्नल डेटाबेस में संग्रहीत होते हैं।
5. एक बार गणना पूरी हो जाने पर, विश्लेषण परिणाम आवश्यकता प्रबंधन प्रणाली में स्थानांतरित कर दिए जाते हैं।

आवश्यकताएँ चरण 3 से 5 को डिज़ाइन प्रक्रिया के दौरान दोहराया जा सकता है जब डिज़ाइन और/या आवश्यकताओं में परिवर्तन होते हैं और परिवर्तनों के प्रभाव को फिर से परीक्षण करने की आवश्यकता होती है।

निष्कर्ष।

• सिस्टम का निर्मित प्रोटोटाइप तकनीकी विशिष्टताओं की आवश्यकताओं के अनुपालन के लिए मौजूदा मॉडलों के विश्लेषण के समय में महत्वपूर्ण कमी प्रदान करता है।
• प्रस्तावित परीक्षण तकनीक पहले से मौजूद गतिशील मॉडल का उपयोग करती है और इसका उपयोग किसी भी गतिशील मॉडल के लिए भी किया जा सकता है, जिसमें सिमइनटेक वातावरण में प्रदर्शन नहीं किए गए मॉडल भी शामिल हैं।
• बैच डेटा संगठन का उपयोग करने से आप मॉडल विकास के समानांतर आवश्यकताओं के सत्यापन पैकेज बना सकते हैं, या यहां तक ​​कि इन पैकेजों को मॉडल विकास के लिए तकनीकी विशिष्टताओं के रूप में भी उपयोग कर सकते हैं।
• प्रौद्योगिकी को बिना किसी महत्वपूर्ण लागत के मौजूदा आवश्यकता प्रबंधन प्रणालियों के साथ एकीकृत किया जा सकता है।

उन लोगों के लिए जो अंत तक पढ़ते हैं, एक वीडियो का लिंक जिसमें दिखाया गया है कि प्रोटोटाइप कैसे काम करता है।

स्रोत: www.habr.com