गतिशील मोडेलिङको समयमा प्राविधिक विशिष्टता आवश्यकताहरूको स्वचालित प्रमाणीकरण

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

हामीले कसरी डिजाइन गर्ने हाम्रो प्रणाली ठ्याक्कै त्यही हो भनेर हामी कसरी चाँडै सुनिश्चित गर्न सक्छौं, हाम्रो डिजाइन उड्छ वा तैर्छ? र यदि यो उड्यो भने, कति उच्च? र यदि यो तैरिन्छ, कति गहिरो?

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

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

कागजातको रूपमा प्राविधिक आवश्यकताहरू वर्णन गर्दा, विभिन्न प्रकारका विभिन्न आवश्यकताहरू छुट्याउन सकिन्छ, जसमध्ये प्रत्येकलाई आवश्यकताहरू पूरा गर्ने स्वचालित प्रमाणीकरणको गठनको लागि विभिन्न दृष्टिकोणहरू आवश्यक पर्दछ।

उदाहरणका लागि, आवश्यकताहरूको यो सानो तर यथार्थपरक सेटलाई विचार गर्नुहोस्:

1. जल उपचार प्रणालीको प्रवेशद्वारमा वायुमण्डलीय हावाको तापमान:
   पार्किङ स्थलमा - माइनस ३५ देखि ३५ ºС सम्म,
   उडानमा - माइनस 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 kg/h,
   उडानमा - 660 kg/h भन्दा कम छैन।
6. उपकरण डिब्बाहरूमा हावाको तापमान 60 ºС भन्दा बढी छैन।
7. चिसो हावामा राम्रो मुक्त आर्द्रताको मात्रा 2 ग्राम / किलोग्राम सुख्खा हावा भन्दा बढी हुँदैन।

आवश्यकताहरूको यो सीमित सेट भित्र पनि, त्यहाँ कम्तिमा दुई कोटिहरू छन् जुन प्रणालीमा फरक रूपमा ह्यान्डल गर्न आवश्यक छ:

• प्रणालीको अपरेटिङ सर्तहरूको लागि आवश्यकताहरू (खण्ड 1-3);
• प्रणालीको लागि प्यारामेट्रिक आवश्यकताहरू (खण्ड 3-7)।

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

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

आवश्यकता पहिचान र कोडिङ

आवश्यकताहरूसँग काम गर्न सजिलोको लागि, अवस्थित मापदण्डहरूले प्रत्येक आवश्यकतालाई पहिचानकर्ता तोक्न सिफारिस गर्दछ। पहिचानकर्ताहरू नियुक्त गर्दा, यो एक एकीकृत कोडिङ प्रणाली प्रयोग गर्न अत्यधिक वांछनीय छ।

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

तालिका १ ले आवश्यकताहरू कोडिङको सरल उदाहरण प्रदान गर्दछ।

1. आवश्यकताहरूको स्रोतको कोड R-आवश्यकताहरू TK;
2. आवश्यकताहरूको कोड प्रकार E - आवश्यकताहरू - वातावरणीय मापदण्डहरू, वा सञ्चालन अवस्थाहरू
   S - प्रणाली द्वारा प्रदान आवश्यकताहरु;
3. विमान स्थिति कोड 0 - कुनै पनि, G - पार्क गरिएको, F - उडानमा;
4. भौतिक प्यारामिटर प्रकार कोड T - तापमान, P - दबाव, G - प्रवाह दर, आर्द्रता H;
5. आवश्यकता को क्रम संख्या।

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

आवश्यकता प्रमाणीकरण प्रणाली डिजाइन।

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

र प्रमाणिकरण एउटा एल्गोरिथ्म हो, त्यसोभए हामीले नियन्त्रण कार्यक्रमहरू सिर्जना गर्न प्रयोग गर्ने समान उपकरण र उपकरणहरू प्रयोग गर्न सक्छौं। उदाहरणका लागि, SimInTech वातावरणले तपाईंलाई मोडेलका विभिन्न भागहरू समावेश गरी अलग-अलग परियोजनाहरू (वस्तु मोडेल, नियन्त्रण प्रणाली मोडेल, वातावरण मोडेल, आदि) को रूपमा कार्यान्वयन गरिएको परियोजना प्याकेजहरू सिर्जना गर्न अनुमति दिन्छ।

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

प्रणाली डिजाइनको सम्भावित उदाहरण चित्र १ मा देखाइएको छ।

चित्र १. प्रमाणीकरण परियोजनाको डिजाइनको उदाहरण।

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

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

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

मोडेलमा डाटा जडान गर्न, सिग्नल डाटाबेस उत्पन्न गर्नको लागि मानक योजना प्रयोग गरिन्छ, जसले परियोजनाको भागहरू बीचको आदानप्रदानको लागि डाटा भण्डारण गर्दछ।

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

यस अवस्थामा, गतिशील मोडेल आफैलाई कुनै पनि गणितीय मोडेलिङ प्रणालीमा वा कार्यान्वयन योग्य कार्यक्रमको रूपमा कार्यान्वयन गर्न सकिन्छ। बाह्य वातावरणमा मोडलिङ डाटा जारी गर्नको लागि सफ्टवेयर इन्टरफेसहरूको उपस्थिति मात्र आवश्यकता हो।

चित्र ३. प्रमाणीकरण परियोजनालाई जटिल मोडेलमा जडान गर्दै।

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

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

चेक पानाका मुख्य भागहरू चित्र 5 मा वर्णन गरिएको छ। चेक एल्गोरिदम नियन्त्रण एल्गोरिदमको डिजाइन रेखाचित्र जस्तै बनाइएको छ। दायाँ छेउमा डाटाबेसबाट संकेतहरू पढ्नको लागि ब्लक छ। यो ब्लकले सिमुलेशनको समयमा सिग्नल डाटाबेस पहुँच गर्दछ।

प्राप्त संकेतहरू आवश्यकता प्रमाणीकरण सर्तहरू गणना गर्न विश्लेषण गरिन्छ। यस अवस्थामा, विमानको स्थिति (चाहे यो पार्क गरिएको होस् वा उडानमा) निर्धारण गर्न उचाइ विश्लेषण गरिन्छ। यस उद्देश्यको लागि, तपाईं मोडेलको अन्य संकेतहरू र गणना प्यारामिटरहरू प्रयोग गर्न सक्नुहुन्छ।

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

चित्र ५. आवश्यकता प्रमाणीकरण गणना पानाको संरचना।

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

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

लक्ष्यमा उडानको क्रममा सुधार प्रणालीको सक्रियताहरूको संख्या 5 भन्दा बढी हुनु हुँदैन, र सुधार प्रणालीको कुल सञ्चालन समय 30 सेकेन्ड भन्दा बढी हुनु हुँदैन।

यस अवस्थामा, सुरुको संख्या र कुल अपरेटिङ समयको काउन्टर गर्नको लागि एल्गोरिथ्म आवश्यकताहरूको डिजाइन रेखाचित्रमा थपिएको छ।

सामान्य आवश्यकता प्रमाणीकरण ब्लक।

प्रत्येक मानक आवश्यकता जाँच बाकस निश्चित प्रकारको आवश्यकताको पूर्ति गणना गर्न डिजाइन गरिएको हो। उदाहरणका लागि, वातावरणीय आवश्यकताहरूले पार्क गर्दा र उडानमा हुँदा परिवेश सञ्चालन तापमानको दायरा समावेश गर्दछ। यो ब्लकले मापदण्डको रूपमा मोडेलमा हावाको तापक्रम प्राप्त गर्नुपर्छ र यो प्यारामिटरले तोकिएको तापक्रम दायरा कभर गर्छ कि गर्दैन भनेर निर्धारण गर्नुपर्छ।

ब्लकले दुई इनपुट पोर्टहरू, परम र सर्त समावेश गर्दछ।

पहिलो एक प्यारामिटर जाँच गरिँदै छ। यस अवस्थामा, "बाह्य तापमान"।

एक बुलियन चर दोस्रो पोर्टमा आपूर्ति गरिएको छ - जाँच प्रदर्शन गर्न सर्त।

यदि TRUE (1) दोस्रो इनपुटमा प्राप्त भयो भने, ब्लकले आवश्यकता प्रमाणीकरण गणना गर्दछ।

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

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

यस ब्लकका प्यारामिटरहरू हुन्:

• सीमा सर्तहरू: माथिल्लो (अपलिमिट) र तल्लो (डाउनलिमिट) दायरा सीमाहरू जुन जाँच गर्नुपर्छ;
• सेकेन्डमा सीमा दायरा (समय अन्तराल) मा आवश्यक प्रणाली एक्सपोजर समय;
• अनुरोध ID ReqName;
• दायरा पार गर्ने अनुमति Out_range एउटा बुलियन चर हो जसले जाँच गरिएको दायरा नाघेको मान आवश्यकताको उल्लङ्घन हो कि होइन भनेर निर्धारण गर्छ।

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

चित्र 6. रेखाचित्र र यसको प्यारामिटरहरूमा एक विशिष्ट सम्पत्ति जाँच ब्लक।

यस ब्लकको गणनाको परिणामको रूपमा, आउटपुटमा परिणाम चर बनाइन्छ, जसले निम्न मानहरू लिन्छ:

• 0 - rNone, मान परिभाषित छैन;
• 1 - rDone, आवश्यकता पूरा भयो;
• 2 - rFault, आवश्यकता पूरा भएको छैन।

ब्लक छवि समावेश:

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

ब्लक भित्र एक जटिल तार्किक अनुमान सर्किट हुन सक्छ।

उदाहरणका लागि, चित्र 6 मा देखाइएको एकाइको सञ्चालन तापमान दायरा जाँच गर्न, आन्तरिक सर्किट चित्र 7 मा देखाइएको छ।

चित्र 7. तापमान दायरा निर्धारण एकाइको आन्तरिक रेखाचित्र।

सर्किट ब्लक भित्र, ब्लक प्यारामिटरहरूमा निर्दिष्ट गुणहरू प्रयोग गरिन्छ।
आवश्यकताहरूको अनुपालनको विश्लेषणको अतिरिक्त, ब्लकको आन्तरिक रेखाचित्रले सिमुलेशन परिणामहरू प्रदर्शन गर्न आवश्यक ग्राफ समावेश गर्दछ। यो ग्राफ गणनाको समयमा हेर्न र गणना पछि परिणामहरू विश्लेषण गर्न दुवै प्रयोग गर्न सकिन्छ।

गणना परिणामहरू ब्लकको आउटपुटमा पठाइन्छ र एकै साथ सामान्य रिपोर्ट फाइलमा रेकर्ड गरिन्छ, जुन सम्पूर्ण परियोजनाको नतिजाको आधारमा सिर्जना गरिन्छ। (चित्र ८ हेर्नुहोस्)

सिमुलेशन परिणामहरूको आधारमा सिर्जना गरिएको रिपोर्टको उदाहरण दिइएको ढाँचा अनुसार सिर्जना गरिएको html फाइल हो। ढाँचा एक विशेष संगठन द्वारा स्वीकार गरिएको ढाँचामा मनमानी रूपमा कन्फिगर गर्न सकिन्छ।

सर्किट ब्लक भित्र, ब्लक प्यारामिटरहरूमा निर्दिष्ट गुणहरू प्रयोग गरिन्छ।
आवश्यकताहरूको अनुपालनको विश्लेषणको अतिरिक्त, ब्लकको आन्तरिक रेखाचित्रले सिमुलेशन परिणामहरू प्रदर्शन गर्न आवश्यक ग्राफ समावेश गर्दछ। यो ग्राफ गणनाको समयमा हेर्न र गणना पछि परिणामहरू विश्लेषण गर्न दुवै प्रयोग गर्न सकिन्छ।

गणना परिणामहरू ब्लकको आउटपुटमा पठाइन्छ र एकै साथ सामान्य रिपोर्ट फाइलमा रेकर्ड गरिन्छ, जुन सम्पूर्ण परियोजनाको नतिजाको आधारमा सिर्जना गरिन्छ। (चित्र ८ हेर्नुहोस्)

सिमुलेशन परिणामहरूको आधारमा सिर्जना गरिएको रिपोर्टको उदाहरण दिइएको ढाँचा अनुसार सिर्जना गरिएको html फाइल हो। ढाँचा एक विशेष संगठन द्वारा स्वीकार गरिएको ढाँचामा मनमानी रूपमा कन्फिगर गर्न सकिन्छ।

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

यस उदाहरणमा, रिपोर्ट फारम परियोजना गुणहरूमा सीधा कन्फिगर गरिएको छ, र तालिकामा ढाँचा ग्लोबल परियोजना संकेतहरूको रूपमा सेट गरिएको छ। यस अवस्थामा, SimInTech ले रिपोर्ट सेटअप गर्ने समस्या समाधान गर्दछ, र फाइलमा नतिजाहरू लेख्नको लागि ब्लकले रिपोर्ट फाइलमा लेख्न यी लाइनहरू प्रयोग गर्दछ।

चित्र 9. ग्लोबल प्रोजेक्ट संकेतहरूमा रिपोर्ट ढाँचा सेट गर्दै

आवश्यकताहरूको लागि सिग्नल डाटाबेस प्रयोग गर्दै।

गुण सेटिङहरूसँग काम स्वचालित गर्न, प्रत्येक विशिष्ट ब्लकको लागि सिग्नल डेटाबेसमा मानक संरचना सिर्जना गरिएको छ। (चित्र १० हेर्नुहोस्)

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

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

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

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

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

SimInTech परीक्षण परियोजना र आवश्यकता नियन्त्रण प्रणाली बीच अन्तरक्रियाको अनुक्रम निम्नानुसार छ:

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

आवश्यकताहरू चरण 3 देखि 5 सम्म डिजाइन प्रक्रियाको क्रममा दोहोर्याउन सकिन्छ जब डिजाइन र/वा आवश्यकताहरूमा परिवर्तनहरू हुन्छन् र परिवर्तनहरूको प्रभावलाई पुन: परीक्षण गर्न आवश्यक हुन्छ।

निष्कर्ष।

• प्रणालीको सिर्जना गरिएको प्रोटोटाइपले प्राविधिक विशिष्टताहरूको आवश्यकताहरूको अनुपालनको लागि अवस्थित मोडेलहरूको विश्लेषणको समयमा महत्त्वपूर्ण कमी प्रदान गर्दछ।
• प्रस्तावित परीक्षण टेक्नोलोजीले पहिले नै अवस्थित गतिशील मोडेलहरू प्रयोग गर्दछ र SimInTech वातावरणमा प्रदर्शन नगरिएकाहरू सहित कुनै पनि गतिशील मोडेलहरूको लागि पनि प्रयोग गर्न सकिन्छ।
• ब्याच डेटा संगठनको प्रयोगले तपाईंलाई मोडेल विकासको साथ समानान्तर आवश्यकताहरू प्रमाणीकरण प्याकेजहरू सिर्जना गर्न अनुमति दिन्छ, वा यी प्याकेजहरूलाई मोडेल विकासको लागि प्राविधिक विशिष्टताहरूको रूपमा प्रयोग गर्न अनुमति दिन्छ।
• प्रविधिलाई महत्त्वपूर्ण लागत बिना अवस्थित आवश्यकताहरू व्यवस्थापन प्रणालीहरूसँग एकीकृत गर्न सकिन्छ।

अन्त्यसम्म पढ्नेहरूका लागि, प्रोटोटाइपले कसरी काम गर्छ भनेर देखाउने भिडियोको लिङ्क।

स्रोत: www.habr.com