डायनॅमिक मॉडेलिंग दरम्यान तांत्रिक वैशिष्ट्यांच्या आवश्यकतांचे स्वयंचलित सत्यापन

थीम सुरू ठेवत आहे "तुमचा पुरावा काय आहे?", गणितीय मॉडेलिंगची समस्या दुसऱ्या बाजूने पाहू. मॉडेल जीवनाच्या होमस्पन सत्याशी सुसंगत आहे याची आम्हाला खात्री झाल्यानंतर, आम्ही मुख्य प्रश्नाचे उत्तर देऊ शकतो: "आमच्याकडे नक्की काय आहे?" तांत्रिक वस्तूचे मॉडेल तयार करताना, आम्ही सहसा खात्री करू इच्छितो की ही वस्तू आमच्या अपेक्षा पूर्ण करेल. या उद्देशासाठी, प्रक्रियांची डायनॅमिक गणना केली जाते आणि निकालाची आवश्यकतांशी तुलना केली जाते. हे डिजिटल ट्विन, व्हर्च्युअल प्रोटोटाइप इ. फॅशनेबल लहान मुले, जे डिझाइनच्या टप्प्यावर, आम्ही जे नियोजित केले आहे ते आम्हाला कसे मिळेल याची खात्री कशी करायची या समस्येचे निराकरण करतात.

आमची सिस्टीम आम्ही जे डिझाइन करतो तेच आहे याची आम्ही पटकन खात्री कशी करू शकतो, आमची रचना उडेल की तरंगते? आणि जर ते उडते तर किती उंचावर? आणि जर ते तरंगत असेल तर किती खोलवर?

हा लेख तांत्रिक प्रणालींचे डायनॅमिक मॉडेल तयार करताना तांत्रिक इमारतीच्या आवश्यकतांच्या अनुपालनाच्या पडताळणीच्या ऑटोमेशनवर चर्चा करतो. उदाहरण म्हणून, विमान एअर कूलिंग सिस्टमच्या तांत्रिक तपशीलाचा एक घटक पाहू.

आम्ही त्या आवश्यकतांचा विचार करतो ज्या संख्यात्मकरित्या व्यक्त केल्या जाऊ शकतात आणि विशिष्ट गणना मॉडेलच्या आधारे गणितीयदृष्ट्या सत्यापित केल्या जाऊ शकतात. हे स्पष्ट आहे की कोणत्याही तांत्रिक प्रणालीच्या सामान्य आवश्यकतांचा हा केवळ एक भाग आहे, परंतु ते तपासण्यावर आम्ही ऑब्जेक्टचे डायनॅमिक मॉडेल तयार करण्यासाठी वेळ, मज्जातंतू आणि पैसा खर्च करतो.

दस्तऐवजाच्या स्वरूपात तांत्रिक आवश्यकतांचे वर्णन करताना, अनेक प्रकारच्या भिन्न आवश्यकता ओळखल्या जाऊ शकतात, ज्यापैकी प्रत्येकाला आवश्यकतांच्या पूर्ततेच्या स्वयंचलित सत्यापनाच्या निर्मितीसाठी भिन्न दृष्टिकोन आवश्यक आहेत.

उदाहरणार्थ, या लहान परंतु वास्तववादी आवश्यकतांचा विचार करा:

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

आवश्यकतांच्या या मर्यादित संचामध्ये देखील, सिस्टममध्ये कमीतकमी दोन श्रेणी आहेत ज्या वेगळ्या पद्धतीने हाताळल्या पाहिजेत:

• सिस्टमच्या ऑपरेटिंग परिस्थितीसाठी आवश्यकता (कलम 1-3);
• प्रणालीसाठी पॅरामेट्रिक आवश्यकता (कलम 3-7).

सिस्टम ऑपरेटिंग शर्ती आवश्यकता
मॉडेलिंग दरम्यान विकसित होत असलेल्या प्रणालीसाठी बाह्य परिस्थिती सीमा परिस्थिती किंवा सामान्य प्रणालीच्या ऑपरेशनच्या परिणामी निर्दिष्ट केली जाऊ शकते.
डायनॅमिक सिम्युलेशनमध्ये, हे सुनिश्चित करणे आवश्यक आहे की निर्दिष्ट ऑपरेटिंग परिस्थिती सिम्युलेशन प्रक्रियेद्वारे संरक्षित आहेत.

पॅरामेट्रिक सिस्टम आवश्यकता
या आवश्यकता सिस्टमद्वारे प्रदान केलेले पॅरामीटर्स आहेत. मॉडेलिंग प्रक्रियेदरम्यान, आम्ही हे पॅरामीटर्स गणना परिणाम म्हणून मिळवू शकतो आणि प्रत्येक विशिष्ट गणनामध्ये आवश्यकता पूर्ण केल्या आहेत याची खात्री करू शकतो.

आवश्यकता ओळख आणि कोडिंग

आवश्यकतांसह कार्य करणे सुलभतेसाठी, विद्यमान मानके प्रत्येक आवश्यकतेसाठी एक अभिज्ञापक नियुक्त करण्याची शिफारस करतात. अभिज्ञापक नियुक्त करताना, युनिफाइड कोडिंग सिस्टम वापरणे अत्यंत इष्ट आहे.

आवश्यकता कोड हा फक्त एक क्रमांक असू शकतो जो आवश्यकतेच्या ऑर्डर क्रमांकाचे प्रतिनिधित्व करतो किंवा त्यात आवश्यकतेच्या प्रकारासाठी कोड असू शकतो, सिस्टम किंवा युनिटसाठी एक कोड ज्यावर तो लागू होतो, पॅरामीटर कोड, स्थान कोड आणि अभियंता इतर कोणत्याही गोष्टीची कल्पना करू शकतात. (एनकोडिंगच्या वापरासाठी लेख पहा)

तक्ता 1 आवश्यकता कोडिंगचे एक साधे उदाहरण देते.

1. आवश्यकतांच्या स्त्रोताचा कोड आर-आवश्यकता टीके;
2. आवश्यकतांचा कोड प्रकार ई - आवश्यकता - पर्यावरणीय मापदंड किंवा ऑपरेटिंग परिस्थिती
   एस - सिस्टमद्वारे प्रदान केलेल्या आवश्यकता;
3. विमान स्थिती कोड 0 – कोणताही, जी – पार्क केलेला, F – फ्लाइटमध्ये;
4. भौतिक मापदंड प्रकार कोड T – तापमान, P – दाब, G – प्रवाह दर, आर्द्रता H;
5. आवश्यकतेचा अनुक्रमांक.

ID आवश्यकता	वर्णन	पॅरामीटर
REGT01	वॉटर कूलिंग सिस्टमच्या प्रवेशद्वारावर वातावरणीय हवेचे तापमान: पार्किंगमध्ये - उणे 35ºС पासून. 35 ºС पर्यंत.
REFT01	वायु संरक्षण प्रणालीच्या प्रवेशद्वारावर वातावरणातील हवेचे तापमान: उड्डाण करताना - उणे 35 ºС ते 39 ºС पर्यंत.
REFP01	फ्लाइटमध्ये स्थिर वातावरणीय हवेचा दाब 700 ते 1013 hPa (526 ते 760 mm Hg पर्यंत) असतो.
REFP02	फ्लाइटमध्ये एसव्हीओ एअर इनटेकच्या प्रवेशद्वारावरील एकूण हवेचा दाब 754 ते 1200 एचपीए (566 ते 1050 मिमी एचजी पर्यंत) आहे.
RSGT01	थंड हवेचे तापमान: 27 ºС पेक्षा जास्त पार्क केलेले नसताना
RSGT02	थंड हवेचे तापमान: पार्किंगमध्ये, तांत्रिक युनिट्ससाठी 29 ºС पेक्षा जास्त नाही
RSFT01	फ्लाइटमध्ये थंड हवेचे तापमान 25 ºС पेक्षा जास्त नाही
RSFT02	थंड हवेचे तापमान: फ्लाइटमध्ये, तांत्रिक युनिट्ससाठी 27 ºС पेक्षा जास्त नाही
RSGG01	कूलिंग एअर फ्लो: पार्क केल्यावर 708 kg/h पेक्षा कमी नाही
RSFG01	थंड हवेचा प्रवाह: फ्लाइटमध्ये 660 kg/h पेक्षा कमी नाही
RS0T01	इन्स्ट्रुमेंट कंपार्टमेंटमध्ये हवेचे तापमान 60 ºС पेक्षा जास्त नाही
RSH01	थंड हवेतील सूक्ष्म मुक्त आर्द्रतेचे प्रमाण 2 ग्रॅम/किलो कोरड्या हवेपेक्षा जास्त नसते

आवश्यकता पडताळणी सिस्टम डिझाइन.

प्रत्येक डिझाइन आवश्यकतेसाठी डिझाइन पॅरामीटर्स आणि आवश्यकतेमध्ये निर्दिष्ट केलेल्या पॅरामीटर्सच्या पत्रव्यवहाराचे मूल्यांकन करण्यासाठी एक अल्गोरिदम आहे. आणि मोठ्या प्रमाणात, कोणत्याही नियंत्रण प्रणालीमध्ये फक्त डीफॉल्टनुसार आवश्यकता तपासण्यासाठी अल्गोरिदम असतात. आणि अगदी कोणत्याही नियामकात ते समाविष्ट आहेत. तापमान मर्यादेच्या बाहेर गेल्यास, एअर कंडिशनर चालू होते. अशा प्रकारे, कोणत्याही नियमनाचा पहिला टप्पा म्हणजे पॅरामीटर्स आवश्यकता पूर्ण करतात की नाही हे तपासणे.

आणि पडताळणी हा अल्गोरिदम असल्याने, आम्ही नियंत्रण कार्यक्रम तयार करण्यासाठी वापरतो तीच साधने आणि साधने वापरू शकतो. उदाहरणार्थ, SimInTech वातावरण तुम्हाला मॉडेलचे विविध भाग असलेले प्रकल्प पॅकेज तयार करण्यास अनुमती देते, स्वतंत्र प्रकल्प (ऑब्जेक्ट मॉडेल, कंट्रोल सिस्टम मॉडेल, पर्यावरण मॉडेल, इ.) स्वरूपात कार्यान्वित केले जाते.

या प्रकरणात आवश्यकता पडताळणी प्रकल्प समान अल्गोरिदम प्रकल्प बनतो आणि मॉडेल पॅकेजशी जोडलेला आहे. आणि डायनॅमिक मॉडेलिंग मोडमध्ये ते तांत्रिक वैशिष्ट्यांच्या आवश्यकतांचे पालन करण्यासाठी विश्लेषण करते.

सिस्टम डिझाइनचे संभाव्य उदाहरण आकृती 1 मध्ये दर्शविले आहे.

आकृती 1. पडताळणी प्रकल्पाच्या डिझाइनचे उदाहरण.

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

आकृती 2. आवश्यकता पडताळणी मॉडेलची श्रेणीबद्ध रचना.

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

मॉडेलशी डेटा कनेक्ट करण्यासाठी, सिग्नल डेटाबेस तयार करण्यासाठी एक मानक योजना वापरली जाते, जी प्रकल्पाच्या भागांमधील देवाणघेवाणसाठी डेटा संग्रहित करते.

सॉफ्टवेअर तयार करताना आणि चाचणी करताना, नियंत्रण प्रणालीद्वारे वापरल्या जाणार्‍या सेन्सर्सचे वाचन (वास्तविक सिस्टम सेन्सरचे अॅनालॉग) या डेटाबेसमध्ये ठेवले जातात.
चाचणी प्रकल्पासाठी, डायनॅमिक मॉडेलमध्ये गणना केलेले कोणतेही पॅरामीटर्स समान डेटाबेसमध्ये संग्रहित केले जाऊ शकतात आणि अशा प्रकारे आवश्यकता पूर्ण झाल्या आहेत की नाही हे तपासण्यासाठी वापरले जाऊ शकतात.

या प्रकरणात, डायनॅमिक मॉडेल स्वतःच कोणत्याही गणितीय मॉडेलिंग प्रणालीमध्ये किंवा अगदी एक्झिक्युटेबल प्रोग्रामच्या स्वरूपात कार्यान्वित केले जाऊ शकते. बाह्य वातावरणात मॉडेलिंग डेटा जारी करण्यासाठी सॉफ्टवेअर इंटरफेसची उपस्थिती ही एकमेव आवश्यकता आहे.

आकृती 3. पडताळणी प्रकल्पाला जटिल मॉडेलशी जोडणे.

मूलभूत आवश्यकता पडताळणी पत्रकाचे उदाहरण आकृती 4 मध्ये सादर केले आहे. विकासकाच्या दृष्टिकोनातून, हे एक पारंपारिक गणना आकृती आहे ज्यावर आवश्यकता पडताळणी अल्गोरिदम ग्राफिक पद्धतीने सादर केले जाते.

आकृती 4. आवश्यकता चेक शीट.

चेक शीटचे मुख्य भाग आकृती 5 मध्ये वर्णन केले आहेत. चेक अल्गोरिदम कंट्रोल अल्गोरिदमच्या डिझाइन आकृत्यांप्रमाणेच तयार केला जातो. उजव्या बाजूला डेटाबेसमधून सिग्नल वाचण्यासाठी एक ब्लॉक आहे. हा ब्लॉक सिम्युलेशन दरम्यान सिग्नल डेटाबेसमध्ये प्रवेश करतो.

आवश्यकता पडताळणी अटींची गणना करण्यासाठी प्राप्त सिग्नलचे विश्लेषण केले जाते. या प्रकरणात, विमानाची स्थिती निश्चित करण्यासाठी उंचीचे विश्लेषण केले जाते (मग ते पार्क केलेले असो वा उड्डाणात). या उद्देशासाठी, आपण मॉडेलचे इतर सिग्नल आणि गणना केलेले पॅरामीटर्स वापरू शकता.

पडताळणी अटी आणि पॅरामीटर्स तपासले जात आहेत ते मानक पडताळणी ब्लॉक्समध्ये हस्तांतरित केले जातात, ज्यामध्ये निर्दिष्ट आवश्यकतांच्या अनुपालनासाठी या पॅरामीटर्सचे विश्लेषण केले जाते. सिग्नल डेटाबेसमध्ये परिणाम अशा प्रकारे रेकॉर्ड केले जातात की ते स्वयंचलितपणे चेकलिस्ट तयार करण्यासाठी वापरले जाऊ शकतात.

आकृती 5. आवश्यकता पडताळणी गणना पत्रकाची रचना.

तपासले जाणारे पॅरामीटर्स डेटाबेसमध्ये असलेले सिग्नल वापरत नाहीत, जे सिम्युलेशन प्रक्रियेदरम्यान मोजलेल्या पॅरामीटर्सद्वारे नियंत्रित केले जातात. आम्ही पडताळणी अटींची गणना करतो त्याप्रमाणे मसुद्याच्या आवश्यकतांच्या चौकटीत अतिरिक्त गणना करण्यापासून आम्हाला काहीही प्रतिबंधित करत नाही.

उदाहरणार्थ, ही आवश्यकता:

लक्ष्यापर्यंतच्या फ्लाइट दरम्यान सुधारणा प्रणालीच्या सक्रियतेची संख्या 5 पेक्षा जास्त नसावी आणि सुधारणा प्रणालीची एकूण ऑपरेटिंग वेळ 30 सेकंदांपेक्षा जास्त नसावी.

या प्रकरणात, आवश्यकतेच्या डिझाइन आकृतीमध्ये प्रारंभांची संख्या आणि एकूण ऑपरेटिंग वेळेचा सामना करण्यासाठी अल्गोरिदम जोडला जातो.

ठराविक आवश्यकता पडताळणी ब्लॉक.

प्रत्येक मानक आवश्यकता चेक बॉक्स विशिष्ट प्रकारच्या आवश्यकतांच्या पूर्ततेची गणना करण्यासाठी डिझाइन केलेले आहे. उदाहरणार्थ, पार्क केलेले असताना आणि फ्लाइटमध्ये असताना पर्यावरणीय आवश्यकतांमध्ये सभोवतालच्या ऑपरेटिंग तापमानांची श्रेणी समाविष्ट असते. या ब्लॉकला पॅरामीटर म्हणून मॉडेलमधील हवेचे तापमान प्राप्त करणे आवश्यक आहे आणि हे पॅरामीटर निर्दिष्ट तापमान श्रेणी कव्हर करते की नाही हे निर्धारित करणे आवश्यक आहे.

ब्लॉकमध्ये दोन इनपुट पोर्ट आहेत, परम आणि कंडिशन.

पहिले पॅरामीटर तपासले जात आहे. या प्रकरणात, "बाह्य तापमान".

बुलियन व्हेरिएबल दुसऱ्या पोर्टला पुरवले जाते - तपासणी करण्यासाठी अट.

दुसऱ्या इनपुटवर TRUE (1) प्राप्त झाल्यास, ब्लॉक आवश्यक पडताळणी गणना करते.

दुसऱ्या इनपुटला FALSE (0) प्राप्त झाल्यास, चाचणी अटी पूर्ण केल्या जात नाहीत. हे आवश्यक आहे जेणेकरून गणना अटी विचारात घेतल्या जाऊ शकतात. आमच्या बाबतीत, हे इनपुट मॉडेलच्या स्थितीनुसार चेक सक्षम किंवा अक्षम करण्यासाठी वापरले जाते. सिम्युलेशन दरम्यान विमान जमिनीवर असल्यास, फ्लाइटशी संबंधित आवश्यकता तपासल्या जात नाहीत आणि त्याउलट - जर विमान उड्डाण करत असेल, तर स्टँडवर ऑपरेशनशी संबंधित आवश्यकता तपासल्या जात नाहीत.

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

या ब्लॉकचे पॅरामीटर्स आहेत:

• सीमा अटी: वरच्या (अपलिमिट) आणि खालच्या (डाउनलिमिट) श्रेणी मर्यादा ज्या तपासल्या पाहिजेत;
• सीमारेषेवर आवश्यक सिस्टम एक्सपोजर वेळ (टाइम इंटरव्हल) सेकंदांमध्ये;
• विनंती आयडी ReqName;
• Out_range श्रेणी ओलांडण्याची परवानगी हे बुलियन व्हेरिएबल आहे जे तपासलेल्या श्रेणीपेक्षा जास्त मूल्य आवश्यकतेचे उल्लंघन आहे की नाही हे ठरवते.

काही प्रकरणांमध्ये, चाचणी मूल्य आउटपुट सूचित करते की सिस्टममध्ये काही मार्जिन आहे आणि ती त्याच्या ऑपरेटिंग श्रेणीबाहेर कार्यरत असू शकते. इतर प्रकरणांमध्ये, आउटपुटचा अर्थ असा होतो की सिस्टम सेटपॉईंट्स रेंजमध्ये ठेवण्यास अक्षम आहे.

आकृती 6. आकृती आणि त्याचे पॅरामीटर्समधील एक सामान्य मालमत्ता तपासणी ब्लॉक.

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

• 0 - rकाहीही नाही, मूल्य परिभाषित नाही;
• 1 – पूर्ण झाले, आवश्यकता पूर्ण झाली;
• 2 - rफॉल्ट, आवश्यकता पूर्ण झाली नाही.

ब्लॉक इमेजमध्ये हे समाविष्ट आहे:

• अभिज्ञापक मजकूर;
• मापन मर्यादा पॅरामीटर्सचे डिजिटल प्रदर्शन;
• पॅरामीटर स्थितीचा रंग ओळखकर्ता.

ब्लॉकच्या आत एक जटिल तार्किक अनुमान सर्किट असू शकते.

उदाहरणार्थ, आकृती 6 मध्ये दर्शविलेल्या युनिटची ऑपरेटिंग तापमान श्रेणी तपासण्यासाठी, अंतर्गत सर्किट आकृती 7 मध्ये दर्शविले आहे.

आकृती 7. तापमान श्रेणी निर्धारण युनिटचे अंतर्गत आकृती.

सर्किट ब्लॉकच्या आत, ब्लॉक पॅरामीटर्समध्ये निर्दिष्ट केलेल्या गुणधर्मांचा वापर केला जातो.
आवश्यकतांच्या अनुपालनाचे विश्लेषण करण्याव्यतिरिक्त, ब्लॉकच्या अंतर्गत आकृतीमध्ये सिम्युलेशन परिणाम प्रदर्शित करण्यासाठी आवश्यक आलेख समाविष्ट आहे. हा आलेख गणनेदरम्यान पाहण्यासाठी आणि गणना केल्यानंतर निकालांचे विश्लेषण करण्यासाठी दोन्हीसाठी वापरला जाऊ शकतो.

गणना परिणाम ब्लॉकच्या आउटपुटवर प्रसारित केले जातात आणि एकाच वेळी सामान्य अहवाल फाइलमध्ये रेकॉर्ड केले जातात, जे संपूर्ण प्रकल्पाच्या परिणामांवर आधारित तयार केले जाते. (चित्र 8 पहा)

सिम्युलेशन परिणामांवर आधारित तयार केलेल्या अहवालाचे उदाहरण म्हणजे दिलेल्या फॉरमॅटनुसार तयार केलेली html फाइल आहे. एखाद्या विशिष्ट संस्थेने स्वीकारलेल्या फॉरमॅटमध्ये हे फॉरमॅट अनियंत्रितपणे कॉन्फिगर केले जाऊ शकते.

सर्किट ब्लॉकच्या आत, ब्लॉक पॅरामीटर्समध्ये निर्दिष्ट केलेल्या गुणधर्मांचा वापर केला जातो.
आवश्यकतांच्या अनुपालनाचे विश्लेषण करण्याव्यतिरिक्त, ब्लॉकच्या अंतर्गत आकृतीमध्ये सिम्युलेशन परिणाम प्रदर्शित करण्यासाठी आवश्यक आलेख समाविष्ट आहे. हा आलेख गणनेदरम्यान पाहण्यासाठी आणि गणना केल्यानंतर निकालांचे विश्लेषण करण्यासाठी दोन्हीसाठी वापरला जाऊ शकतो.

गणना परिणाम ब्लॉकच्या आउटपुटवर प्रसारित केले जातात आणि एकाच वेळी सामान्य अहवाल फाइलमध्ये रेकॉर्ड केले जातात, जे संपूर्ण प्रकल्पाच्या परिणामांवर आधारित तयार केले जाते. (चित्र 8 पहा)

सिम्युलेशन परिणामांवर आधारित तयार केलेल्या अहवालाचे उदाहरण म्हणजे दिलेल्या फॉरमॅटनुसार तयार केलेली html फाइल आहे. एखाद्या विशिष्ट संस्थेने स्वीकारलेल्या फॉरमॅटमध्ये हे फॉरमॅट अनियंत्रितपणे कॉन्फिगर केले जाऊ शकते.

आकृती 8. सिम्युलेशन परिणामांवर आधारित अहवाल फाइलचे उदाहरण.

या उदाहरणात, अहवाल फॉर्म थेट प्रोजेक्ट गुणधर्मांमध्ये कॉन्फिगर केला आहे आणि टेबलमधील फॉरमॅट ग्लोबल प्रोजेक्ट सिग्नल म्हणून सेट केला आहे. या प्रकरणात, SimInTech स्वतः रिपोर्ट सेट करण्याची समस्या सोडवते आणि फाइलवर परिणाम लिहिण्यासाठी ब्लॉक रिपोर्ट फाइलवर लिहिण्यासाठी या ओळी वापरतो.

आकृती 9. ग्लोबल प्रोजेक्ट सिग्नलमध्ये रिपोर्ट फॉरमॅट सेट करणे

आवश्यकतांसाठी सिग्नल डेटाबेस वापरणे.

मालमत्ता सेटिंग्जसह कार्य स्वयंचलित करण्यासाठी, प्रत्येक विशिष्ट ब्लॉकसाठी सिग्नल डेटाबेसमध्ये एक मानक रचना तयार केली जाते. (चित्र 10 पहा)

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

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

• सर्व आवश्यक सिस्टम आवश्यकता पॅरामीटर्स संचयित करणे.
• निर्दिष्ट पॅरामीटर्स आणि वर्तमान मॉडेलिंग परिणामांमधून विद्यमान प्रकल्प आवश्यकतांचे सोयीस्करपणे पाहणे.
• स्क्रिप्टिंग प्रोग्रामिंग भाषा वापरून एक ब्लॉक किंवा ब्लॉक्सचा समूह सेट करणे. सिग्नल डेटाबेसमधील बदल डायग्राममधील ब्लॉक प्रॉपर्टी व्हॅल्यूमध्ये बदल घडवून आणतात.
• आवश्यकता व्यवस्थापन प्रणालीमध्ये मजकूर वर्णन, तांत्रिक तपशील आयटम किंवा अभिज्ञापकांचे दुवे संग्रहित करणे.

आवश्यकतांसाठी सिग्नल डेटाबेस संरचना तृतीय-पक्ष आवश्यकता व्यवस्थापन प्रणालीसह कार्य करण्यासाठी सहजपणे कॉन्फिगर केली जाऊ शकते. आवश्यकता व्यवस्थापन प्रणालींसह परस्परसंवादाचा एक सामान्य आकृती आकृती 11 मध्ये सादर केला आहे.

आकृती 11. आवश्यकता व्यवस्थापन प्रणालीसह परस्परसंवादाचा आकृती.

SimInTech चाचणी प्रकल्प आणि आवश्यकता नियंत्रण प्रणाली यांच्यातील परस्परसंवादाचा क्रम खालीलप्रमाणे आहे:

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

जेव्हा डिझाइन आणि/किंवा आवश्यकतांमध्ये बदल घडतात आणि बदलांच्या प्रभावाची पुन्हा चाचणी करणे आवश्यक असते तेव्हा डिझाइन प्रक्रियेदरम्यान आवश्यकता चरण 3 ते 5 ची पुनरावृत्ती केली जाऊ शकते.

निष्कर्ष.

• सिस्टमचा तयार केलेला प्रोटोटाइप तांत्रिक वैशिष्ट्यांच्या आवश्यकतांचे पालन करण्यासाठी विद्यमान मॉडेल्सच्या विश्लेषणाच्या वेळेत लक्षणीय घट प्रदान करतो.
• प्रस्तावित चाचणी तंत्रज्ञान आधीपासून अस्तित्वात असलेल्या डायनॅमिक मॉडेल्सचा वापर करते आणि ते SimInTech वातावरणात न सादर केलेल्या कोणत्याही डायनॅमिक मॉडेलसाठी देखील वापरले जाऊ शकते.
• बॅच डेटा ऑर्गनायझेशन वापरणे तुम्हाला मॉडेल डेव्हलपमेंटच्या समांतर आवश्यकता पडताळणी पॅकेजेस तयार करण्यास किंवा मॉडेल डेव्हलपमेंटसाठी तांत्रिक वैशिष्ट्ये म्हणून या पॅकेजेसचा वापर करण्यास अनुमती देते.
• तंत्रज्ञानाला महत्त्वाच्या खर्चाशिवाय विद्यमान आवश्यकता व्यवस्थापन प्रणालींसह एकत्रित केले जाऊ शकते.

जे शेवटपर्यंत वाचतात त्यांच्यासाठी, प्रोटोटाइप कसे कार्य करते हे दर्शविणाऱ्या व्हिडिओची लिंक.

स्त्रोत: www.habr.com