ડાયનેમિક સિમ્યુલેશનની પ્રક્રિયામાં TOR આવશ્યકતાઓની સ્વચાલિત ચકાસણી

થીમ ચાલુ "તમારો પુરાવો શું છે?", ચાલો બીજી બાજુથી ગાણિતિક મોડેલિંગની સમસ્યા જોઈએ. અમને ખાતરી થઈ જાય કે મોડેલ જીવનના હોમસ્પન સત્યને અનુરૂપ છે, અમે મુખ્ય પ્રશ્નનો જવાબ આપી શકીએ છીએ: "અહીં આપણી પાસે શું છે?" તકનીકી ઑબ્જેક્ટનું મોડેલ બનાવતી વખતે, અમે સામાન્ય રીતે ખાતરી કરવા માંગીએ છીએ કે આ ઑબ્જેક્ટ અમારી અપેક્ષાઓને પૂર્ણ કરશે. આ હેતુ માટે, પ્રક્રિયાઓની ગતિશીલ ગણતરીઓ હાથ ધરવામાં આવે છે અને પરિણામની જરૂરિયાતો સાથે સરખામણી કરવામાં આવે છે. આ ડિજિટલ ટ્વીન, વર્ચ્યુઅલ પ્રોટોટાઇપ વગેરે છે. ફેશનેબલ નાના લોકો, જેઓ, ડિઝાઇન સ્ટેજ પર, અમે જે આયોજન કર્યું છે તે અમને મળે છે તેની ખાતરી કેવી રીતે કરવી તે સમસ્યાનું નિરાકરણ લાવે છે.

અમે કેવી રીતે ઝડપથી ખાતરી કરી શકીએ કે અમારી સિસ્ટમ બરાબર છે જે અમે ડિઝાઇન કરીએ છીએ, શું અમારી ડિઝાઇન ઉડશે કે તરતી રહેશે? અને જો તે ઉડે છે, તો કેટલી ઊંચી? અને જો તે તરતું હોય, તો કેટલું ઊંડું?

આ લેખ તકનીકી સિસ્ટમોના ગતિશીલ મોડલ બનાવતી વખતે તકનીકી બિલ્ડિંગની આવશ્યકતાઓ સાથે પાલનની ચકાસણીના ઓટોમેશનની ચર્ચા કરે છે. ઉદાહરણ તરીકે, ચાલો એરક્રાફ્ટ એર કૂલિંગ સિસ્ટમ માટે તકનીકી સ્પષ્ટીકરણના એક તત્વને જોઈએ.

અમે તે આવશ્યકતાઓને ધ્યાનમાં લઈએ છીએ જે સંખ્યાત્મક રીતે વ્યક્ત કરી શકાય છે અને ચોક્કસ ગણતરી મોડેલના આધારે ગાણિતિક રીતે ચકાસી શકાય છે. તે સ્પષ્ટ છે કે આ કોઈપણ તકનીકી સિસ્ટમ માટેની સામાન્ય આવશ્યકતાઓનો માત્ર એક ભાગ છે, પરંતુ તે તેમને તપાસવા પર છે કે આપણે ઑબ્જેક્ટના ગતિશીલ મોડલ બનાવવા માટે સમય, ચેતા અને નાણાં ખર્ચીએ છીએ.

દસ્તાવેજના સ્વરૂપમાં તકનીકી આવશ્યકતાઓનું વર્ણન કરતી વખતે, વિવિધ પ્રકારની વિવિધ આવશ્યકતાઓને ઓળખી શકાય છે, જેમાંથી દરેકને જરૂરિયાતોની પરિપૂર્ણતાની સ્વચાલિત ચકાસણીની રચના માટે વિવિધ અભિગમોની જરૂર છે.

ઉદાહરણ તરીકે, જરૂરિયાતોના આ નાના પરંતુ વાસ્તવિક સમૂહને ધ્યાનમાં લો:

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 કિગ્રા/ક કરતાં ઓછું નહીં.
6. ઇન્સ્ટ્રુમેન્ટ કમ્પાર્ટમેન્ટ્સમાં હવાનું તાપમાન 60 ºС કરતાં વધુ નથી.
7. ઠંડકવાળી હવામાં સૂક્ષ્મ મુક્ત ભેજનું પ્રમાણ 2 ગ્રામ/કિલો સૂકી હવા કરતાં વધુ નથી.

જરૂરિયાતોના આ મર્યાદિત સમૂહમાં પણ, સિસ્ટમમાં ઓછામાં ઓછી બે શ્રેણીઓ છે જેને અલગ રીતે હેન્ડલ કરવાની જરૂર છે:

• સિસ્ટમની ઓપરેટિંગ શરતો માટેની આવશ્યકતાઓ (કલમ 1-3);
• સિસ્ટમ માટે પેરામેટ્રિક આવશ્યકતાઓ (ક્લોઝ 3-7).

સિસ્ટમ ઓપરેટિંગ શરતો જરૂરિયાતો
મોડેલિંગ દરમિયાન વિકસિત થતી સિસ્ટમ માટેની બાહ્ય પરિસ્થિતિઓને સીમાની સ્થિતિ તરીકે અથવા સામાન્ય સિસ્ટમના સંચાલનના પરિણામે ઉલ્લેખિત કરી શકાય છે.
ડાયનેમિક સિમ્યુલેશનમાં, તે સુનિશ્ચિત કરવું જરૂરી છે કે ઉલ્લેખિત ઓપરેટિંગ શરતો સિમ્યુલેશન પ્રક્રિયા દ્વારા આવરી લેવામાં આવી છે.

પેરામેટ્રિક સિસ્ટમ આવશ્યકતાઓ
આ જરૂરિયાતો સિસ્ટમ દ્વારા જ પ્રદાન કરવામાં આવેલ પરિમાણો છે. મોડેલિંગ પ્રક્રિયા દરમિયાન, અમે ગણતરીના પરિણામો તરીકે આ પરિમાણો મેળવી શકીએ છીએ અને ખાતરી કરી શકીએ છીએ કે દરેક ચોક્કસ ગણતરીમાં આવશ્યકતાઓ પૂરી થાય છે.

આવશ્યકતાઓ ઓળખ અને કોડિંગ

જરૂરિયાતો સાથે કામ કરવામાં સરળતા માટે, હાલના ધોરણો દરેક જરૂરિયાત માટે ઓળખકર્તા સોંપવાની ભલામણ કરે છે. ઓળખકર્તાઓને સોંપતી વખતે, એકીકૃત કોડિંગ સિસ્ટમનો ઉપયોગ કરવો ખૂબ જ ઇચ્છનીય છે.

આવશ્યકતા કોડ ફક્ત એક નંબર હોઈ શકે છે જે જરૂરિયાતના ઓર્ડર નંબરને રજૂ કરે છે, અથવા તેમાં જરૂરિયાતના પ્રકાર માટે કોડ, સિસ્ટમ અથવા એકમ માટે કોડ કે જેના પર તે લાગુ થાય છે, એક પરિમાણ કોડ, સ્થાન કોડ અને એન્જિનિયર કલ્પના કરી શકે છે. (એનકોડિંગના ઉપયોગ માટે લેખ જુઓ)

કોષ્ટક 1 જરૂરીયાતો કોડિંગનું એક સરળ ઉદાહરણ પૂરું પાડે છે.

1. આવશ્યકતાઓના સ્ત્રોતનો કોડ આર-જરૂરીયાતો TK;
2. આવશ્યકતાઓનો કોડ પ્રકાર E - જરૂરિયાતો - પર્યાવરણીય પરિમાણો અથવા ઓપરેટિંગ શરતો
   એસ - સિસ્ટમ દ્વારા પૂરી પાડવામાં આવેલ જરૂરિયાતો;
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	ફ્લાઇટમાં 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 પર્યાવરણ તમને મોડેલના વિવિધ ભાગો ધરાવતા પ્રોજેક્ટ પેકેજો બનાવવા માટે પરવાનગી આપે છે, જે અલગ પ્રોજેક્ટ્સ (ઓબ્જેક્ટ મોડેલ, કંટ્રોલ સિસ્ટમ મોડલ, પર્યાવરણ મોડેલ, વગેરે) ના સ્વરૂપમાં ચલાવવામાં આવે છે.

આ કિસ્સામાં જરૂરિયાતો ચકાસણી પ્રોજેક્ટ એ જ અલ્ગોરિધમનો પ્રોજેક્ટ બની જાય છે અને મોડેલ પેકેજ સાથે જોડાયેલ છે. અને ગતિશીલ મોડેલિંગ મોડમાં તે તકનીકી વિશિષ્ટતાઓની આવશ્યકતાઓનું પાલન કરવા માટે વિશ્લેષણ કરે છે.

સિસ્ટમ ડિઝાઇનનું સંભવિત ઉદાહરણ આકૃતિ 1 માં બતાવવામાં આવ્યું છે.

આકૃતિ 1. ચકાસણી પ્રોજેક્ટની ડિઝાઇનનું ઉદાહરણ.

કંટ્રોલ એલ્ગોરિધમ્સની જેમ જ, શીટ્સના સમૂહ તરીકે જરૂરિયાતો તૈયાર કરી શકાય છે. SimInTech, Simulink, AmeSim જેવા માળખાકીય મોડેલિંગ વાતાવરણમાં અલ્ગોરિધમ્સ સાથે કામ કરવાની સગવડતા માટે, સબમોડેલ્સના સ્વરૂપમાં બહુ-સ્તરીય માળખાં બનાવવાની ક્ષમતાનો ઉપયોગ થાય છે. આ સંસ્થા વિવિધ આવશ્યકતાઓને સેટમાં જૂથબદ્ધ કરવાનું શક્ય બનાવે છે, જેથી કંટ્રોલ એલ્ગોરિધમ્સ માટે કરવામાં આવે છે (ફિગ. 2 જુઓ).

આકૃતિ 2. આવશ્યકતાઓની ચકાસણી મોડેલની અધિક્રમિક માળખું.

ઉદાહરણ તરીકે, વિચારણા હેઠળના કિસ્સામાં, બે જૂથોને અલગ પાડવામાં આવે છે: પર્યાવરણ માટેની આવશ્યકતાઓ અને સીધી સિસ્ટમ માટેની જરૂરિયાતો. તેથી, બે-સ્તરના ડેટા સ્ટ્રક્ચરનો ઉપયોગ કરવામાં આવે છે: બે જૂથો, જેમાંથી દરેક એલ્ગોરિધમનું પર્ણ છે.

ડેટાને મોડેલ સાથે કનેક્ટ કરવા માટે, સિગ્નલ ડેટાબેઝ બનાવવા માટેની પ્રમાણભૂત યોજનાનો ઉપયોગ કરવામાં આવે છે, જે પ્રોજેક્ટના ભાગો વચ્ચેના વિનિમય માટે ડેટા સંગ્રહિત કરે છે.

સૉફ્ટવેર બનાવતી વખતે અને પરીક્ષણ કરતી વખતે, નિયંત્રણ સિસ્ટમ દ્વારા ઉપયોગમાં લેવાતા સેન્સર્સ (વાસ્તવિક સિસ્ટમ સેન્સરના એનાલોગ) ના રીડિંગ્સ આ ડેટાબેઝમાં મૂકવામાં આવે છે.
પરીક્ષણ પ્રોજેક્ટ માટે, ડાયનેમિક મોડેલમાં ગણતરી કરાયેલ કોઈપણ પરિમાણો સમાન ડેટાબેઝમાં સંગ્રહિત કરી શકાય છે અને આ રીતે જરૂરિયાતો પૂરી થાય છે કે કેમ તે તપાસવા માટે ઉપયોગમાં લેવાય છે.

આ કિસ્સામાં, ગતિશીલ મોડેલ પોતે કોઈપણ ગાણિતિક મોડેલિંગ સિસ્ટમમાં અથવા એક્ઝિક્યુટેબલ પ્રોગ્રામના સ્વરૂપમાં પણ ચલાવી શકાય છે. બાહ્ય વાતાવરણમાં મોડેલિંગ ડેટા જારી કરવા માટે સોફ્ટવેર ઈન્ટરફેસની હાજરી એકમાત્ર આવશ્યકતા છે.

આકૃતિ 3. ચકાસણી પ્રોજેક્ટને જટિલ મોડેલ સાથે જોડવું.

મૂળભૂત આવશ્યકતાઓની ચકાસણી શીટનું ઉદાહરણ આકૃતિ 4 માં રજૂ કરવામાં આવ્યું છે. વિકાસકર્તાના દૃષ્ટિકોણથી, તે એક પરંપરાગત ગણતરી ડાયાગ્રામ છે જેના પર આવશ્યકતાઓની ચકાસણી અલ્ગોરિધમ ગ્રાફિકલી રજૂ કરવામાં આવે છે.

આકૃતિ 4. જરૂરીયાતો ચેક શીટ.

ચેક શીટના મુખ્ય ભાગોનું વર્ણન આકૃતિ 5 માં કરવામાં આવ્યું છે. ચેક એલ્ગોરિધમ કંટ્રોલ અલ્ગોરિધમ્સના ડિઝાઇન ડાયાગ્રામની જેમ જ રચાય છે. જમણી બાજુએ ડેટાબેઝમાંથી સંકેતો વાંચવા માટે એક બ્લોક છે. આ બ્લોક સિમ્યુલેશન દરમિયાન સિગ્નલ ડેટાબેઝને ઍક્સેસ કરે છે.

આવશ્યકતાઓની ચકાસણી શરતોની ગણતરી કરવા માટે પ્રાપ્ત સંકેતોનું વિશ્લેષણ કરવામાં આવે છે. આ કિસ્સામાં, એરક્રાફ્ટની સ્થિતિ નક્કી કરવા માટે ઊંચાઈનું વિશ્લેષણ કરવામાં આવે છે (પછી ભલે તે પાર્ક કરેલ હોય કે ફ્લાઇટમાં હોય). આ હેતુ માટે, તમે મોડેલના અન્ય સંકેતો અને ગણતરી કરેલ પરિમાણોનો ઉપયોગ કરી શકો છો.

ચકાસણીની શરતો અને પરિમાણો ચકાસવામાં આવી રહ્યા છે તે પ્રમાણભૂત ચકાસણી બ્લોક્સમાં સ્થાનાંતરિત કરવામાં આવે છે, જેમાં આ પરિમાણોને ઉલ્લેખિત આવશ્યકતાઓનું પાલન કરવા માટે વિશ્લેષણ કરવામાં આવે છે. પરિણામો સિગ્નલ ડેટાબેઝમાં એવી રીતે રેકોર્ડ કરવામાં આવે છે કે તેનો ઉપયોગ આપોઆપ ચેકલિસ્ટ જનરેટ કરવા માટે થઈ શકે.

આકૃતિ 5. જરૂરિયાતોની ચકાસણી ગણતરી શીટનું માળખું.

પરીક્ષણ કરવા માટેના પરિમાણો ડેટાબેઝમાં સમાવિષ્ટ સિગ્નલોનો ઉપયોગ કરે તે જરૂરી નથી, જે સિમ્યુલેશન પ્રક્રિયા દરમિયાન ગણતરી કરેલ પરિમાણો દ્વારા નિયંત્રિત થાય છે. અમે ચકાસણીની શરતોની ગણતરી કરીએ છીએ તેવી જ રીતે ડ્રાફ્ટ આવશ્યકતાઓના માળખામાં વધારાની ગણતરીઓ હાથ ધરવાથી અમને કંઈપણ અટકાવતું નથી.

ઉદાહરણ તરીકે, આ જરૂરિયાત:

લક્ષ્ય સુધીની ફ્લાઇટ દરમિયાન કરેક્શન સિસ્ટમના સક્રિયકરણની સંખ્યા 5 થી વધુ ન હોવી જોઈએ, અને કરેક્શન સિસ્ટમનો કુલ ઓપરેટિંગ સમય 30 સેકંડથી વધુ ન હોવો જોઈએ.

આ કિસ્સામાં, શરૂઆતની સંખ્યા અને કુલ ઓપરેટિંગ સમયનો સામનો કરવા માટે એક અલ્ગોરિધમ આવશ્યકતાઓના ડિઝાઇન ડાયાગ્રામમાં ઉમેરવામાં આવે છે.

લાક્ષણિક જરૂરિયાતો ચકાસણી બ્લોક.

દરેક પ્રમાણભૂત જરૂરિયાત ચેક બોક્સ ચોક્કસ પ્રકારની જરૂરિયાતની પરિપૂર્ણતાની ગણતરી કરવા માટે રચાયેલ છે. ઉદાહરણ તરીકે, પર્યાવરણીય આવશ્યકતાઓમાં જ્યારે પાર્ક કરેલ હોય અને ફ્લાઇટમાં હોય ત્યારે આસપાસના ઓપરેટિંગ તાપમાનની શ્રેણીનો સમાવેશ થાય છે. આ બ્લોકને પરિમાણ તરીકે મોડેલમાં હવાનું તાપમાન પ્રાપ્ત કરવું જોઈએ અને તે નિર્ધારિત કરવું જોઈએ કે શું આ પરિમાણ ઉલ્લેખિત તાપમાન શ્રેણીને આવરી લે છે.

બ્લોકમાં બે ઇનપુટ પોર્ટ છે, પરમ અને કન્ડિશન.

પ્રથમ એક પરિમાણ ચકાસાયેલ સાથે ખવડાવવામાં આવે છે. આ કિસ્સામાં, "બાહ્ય તાપમાન".

બુલિયન વેરીએબલ બીજા પોર્ટને પૂરા પાડવામાં આવે છે - ચેક કરવા માટેની શરત.

જો બીજા ઇનપુટ પર TRUE (1) પ્રાપ્ત થાય, તો બ્લોક આવશ્યક ચકાસણી ગણતરી કરે છે.

જો બીજું ઇનપુટ FALSE (0) મેળવે છે, તો પરીક્ષણ શરતો પૂરી થતી નથી. આ જરૂરી છે જેથી ગણતરીની શરતોને ધ્યાનમાં લઈ શકાય. અમારા કિસ્સામાં, આ ઇનપુટનો ઉપયોગ મોડેલની સ્થિતિના આધારે ચેકને સક્ષમ અથવા અક્ષમ કરવા માટે થાય છે. જો સિમ્યુલેશન દરમિયાન એરક્રાફ્ટ જમીન પર હોય, તો ફ્લાઇટ સંબંધિત જરૂરિયાતો તપાસવામાં આવતી નથી, અને ઊલટું - જો એરક્રાફ્ટ ફ્લાઇટમાં હોય, તો સ્ટેન્ડ પર ઓપરેશન સંબંધિત જરૂરિયાતો તપાસવામાં આવતી નથી.

આ ઇનપુટનો ઉપયોગ મોડેલ સેટ કરતી વખતે પણ થઈ શકે છે, ઉદાહરણ તરીકે ગણતરીના પ્રારંભિક તબક્કે. જ્યારે મોડેલને આવશ્યક સ્થિતિમાં લાવવામાં આવે છે, ત્યારે ચેક બ્લોક્સ અક્ષમ કરવામાં આવે છે, પરંતુ જલદી સિસ્ટમ આવશ્યક ઑપરેટિંગ મોડ પર પહોંચે છે, ચેક બ્લોક્સ ચાલુ થાય છે.

આ બ્લોકના પરિમાણો છે:

• બાઉન્ડ્રી શરતો: ઉપલી (અપ લિમિટ) અને નીચલી (ડાઉનલિમિટ) શ્રેણી મર્યાદાઓ કે જે તપાસવી આવશ્યક છે;
• સીમા રેન્જ પર જરૂરી સિસ્ટમ એક્સપોઝર સમય (સમય ઇન્ટરવલ) સેકંડમાં;
• વિનંતી ID ReqName;
• આઉટ_રેન્જ શ્રેણીને ઓળંગવાની અનુમતિ એ બુલિયન વેરીએબલ છે જે નક્કી કરે છે કે ચેક કરેલ શ્રેણી કરતાં વધી ગયેલી કિંમત જરૂરિયાતનું ઉલ્લંઘન છે કે કેમ.

કેટલાક કિસ્સાઓમાં, પરીક્ષણ મૂલ્ય આઉટપુટ સૂચવે છે કે સિસ્ટમમાં થોડો માર્જિન છે અને તે તેની ઓપરેટિંગ શ્રેણીની બહાર કાર્યરત હોઈ શકે છે. અન્ય કિસ્સાઓમાં, આઉટપુટનો અર્થ એ થાય છે કે સિસ્ટમ સેટપોઇન્ટ્સને શ્રેણીમાં રાખવામાં અસમર્થ છે.

આકૃતિ 6. ડાયાગ્રામ અને તેના પરિમાણોમાં એક લાક્ષણિક પ્રોપર્ટી ચેક બ્લોક.

આ બ્લોકની ગણતરીના પરિણામે, પરિણામ ચલ આઉટપુટ પર રચાય છે, જે નીચેના મૂલ્યો લે છે:

• 0 – rNone, મૂલ્ય વ્યાખ્યાયિત નથી;
• 1 – rDone, જરૂરિયાત પૂરી થઈ છે;
• 2 - rફૉલ્ટ, જરૂરિયાત પૂરી થઈ નથી.

બ્લોક ઈમેજ સમાવે છે:

• ઓળખકર્તા ટેક્સ્ટ;
• માપન મર્યાદા પરિમાણોના ડિજિટલ ડિસ્પ્લે;
• પરિમાણ સ્થિતિનું રંગ ઓળખકર્તા.

બ્લોકની અંદર એક જટિલ તાર્કિક અનુમાન સર્કિટ હોઈ શકે છે.

ઉદાહરણ તરીકે, આકૃતિ 6 માં બતાવેલ એકમની ઓપરેટિંગ તાપમાન શ્રેણીને ચકાસવા માટે, આંતરિક સર્કિટ આકૃતિ 7 માં બતાવેલ છે.

આકૃતિ 7. તાપમાન શ્રેણી નિર્ધારણ એકમની આંતરિક રેખાકૃતિ.

સર્કિટ બ્લોકની અંદર, બ્લોક પરિમાણોમાં ઉલ્લેખિત ગુણધર્મોનો ઉપયોગ થાય છે.
આવશ્યકતાઓના અનુપાલનનું વિશ્લેષણ કરવા ઉપરાંત, બ્લોકના આંતરિક આકૃતિમાં સિમ્યુલેશન પરિણામો પ્રદર્શિત કરવા માટે જરૂરી ગ્રાફ શામેલ છે. આ ગ્રાફનો ઉપયોગ ગણતરી દરમિયાન જોવા માટે અને ગણતરી પછી પરિણામોનું વિશ્લેષણ કરવા બંને માટે થઈ શકે છે.

ગણતરીના પરિણામો બ્લોકના આઉટપુટ પર પ્રસારિત થાય છે અને એકસાથે સામાન્ય રિપોર્ટ ફાઇલમાં રેકોર્ડ કરવામાં આવે છે, જે સમગ્ર પ્રોજેક્ટના પરિણામોના આધારે બનાવવામાં આવે છે. (જુઓ ફિગ. 8)

સિમ્યુલેશન પરિણામોના આધારે બનાવેલ અહેવાલનું ઉદાહરણ એ આપેલ ફોર્મેટ અનુસાર બનાવેલ html ફાઇલ છે. ફોર્મેટને કોઈ ચોક્કસ સંસ્થા દ્વારા સ્વીકૃત ફોર્મેટમાં મનસ્વી રીતે ગોઠવી શકાય છે.

સર્કિટ બ્લોકની અંદર, બ્લોક પરિમાણોમાં ઉલ્લેખિત ગુણધર્મોનો ઉપયોગ થાય છે.
આવશ્યકતાઓના અનુપાલનનું વિશ્લેષણ કરવા ઉપરાંત, બ્લોકના આંતરિક આકૃતિમાં સિમ્યુલેશન પરિણામો પ્રદર્શિત કરવા માટે જરૂરી ગ્રાફ શામેલ છે. આ ગ્રાફનો ઉપયોગ ગણતરી દરમિયાન જોવા માટે અને ગણતરી પછી પરિણામોનું વિશ્લેષણ કરવા બંને માટે થઈ શકે છે.

ગણતરીના પરિણામો બ્લોકના આઉટપુટ પર પ્રસારિત થાય છે અને એકસાથે સામાન્ય રિપોર્ટ ફાઇલમાં રેકોર્ડ કરવામાં આવે છે, જે સમગ્ર પ્રોજેક્ટના પરિણામોના આધારે બનાવવામાં આવે છે. (જુઓ ફિગ. 8)

સિમ્યુલેશન પરિણામોના આધારે બનાવેલ અહેવાલનું ઉદાહરણ એ આપેલ ફોર્મેટ અનુસાર બનાવેલ html ફાઇલ છે. ફોર્મેટને કોઈ ચોક્કસ સંસ્થા દ્વારા સ્વીકૃત ફોર્મેટમાં મનસ્વી રીતે ગોઠવી શકાય છે.

આકૃતિ 8. સિમ્યુલેશન પરિણામો પર આધારિત રિપોર્ટ ફાઇલનું ઉદાહરણ.

આ ઉદાહરણમાં, રિપોર્ટ ફોર્મ સીધા પ્રોજેક્ટ પ્રોપર્ટીઝમાં ગોઠવેલ છે, અને ટેબલમાં ફોર્મેટ વૈશ્વિક પ્રોજેક્ટ સિગ્નલ તરીકે સેટ કરેલ છે. આ કિસ્સામાં, SimInTech પોતે રિપોર્ટ સેટ કરવાની સમસ્યાનું નિરાકરણ કરે છે, અને ફાઇલમાં પરિણામો લખવા માટેનો બ્લોક રિપોર્ટ ફાઇલ પર લખવા માટે આ રેખાઓનો ઉપયોગ કરે છે.

આકૃતિ 9. વૈશ્વિક પ્રોજેક્ટ સિગ્નલોમાં રિપોર્ટ ફોર્મેટ સેટ કરી રહ્યું છે

જરૂરિયાતો માટે સિગ્નલ ડેટાબેઝનો ઉપયોગ કરવો.

પ્રોપર્ટી સેટિંગ્સ સાથે કામને સ્વચાલિત કરવા માટે, દરેક લાક્ષણિક બ્લોક માટે સિગ્નલ ડેટાબેઝમાં એક માનક માળખું બનાવવામાં આવે છે. (ફિગ. 10 જુઓ)

આકૃતિ 10. સિગ્નલ ડેટાબેઝમાં જરૂરી ચેક બ્લોકની રચનાનું ઉદાહરણ.

સિગ્નલ ડેટાબેઝ પ્રદાન કરે છે:

• તમામ જરૂરી સિસ્ટમ આવશ્યકતા પરિમાણોને સંગ્રહિત કરવું.
• ઉલ્લેખિત પરિમાણો અને વર્તમાન મોડેલિંગ પરિણામોથી હાલની પ્રોજેક્ટ આવશ્યકતાઓને અનુકૂળ જોવા.
• સ્ક્રિપ્ટીંગ પ્રોગ્રામિંગ લેંગ્વેજનો ઉપયોગ કરીને એક બ્લોક અથવા બ્લોકનું જૂથ સેટ કરવું. સિગ્નલ ડેટાબેઝમાં ફેરફાર ડાયાગ્રામમાં બ્લોક પ્રોપર્ટીના મૂલ્યોમાં ફેરફાર તરફ દોરી જાય છે.
• જરૂરીયાતો વ્યવસ્થાપન સિસ્ટમમાં ટેક્સ્ટ વર્ણનો, તકનીકી વિશિષ્ટતાઓની આઇટમ્સ અથવા ઓળખકર્તાઓની લિંક્સ સંગ્રહિત કરવી.

જરૂરિયાતો માટે સિગ્નલ ડેટાબેઝ સ્ટ્રક્ચર્સ સરળતાથી તૃતીય-પક્ષ આવશ્યકતાઓ વ્યવસ્થાપન સિસ્ટમ સાથે કામ કરવા માટે ગોઠવી શકાય છે. જરૂરિયાતો વ્યવસ્થાપન પ્રણાલીઓ સાથે ક્રિયાપ્રતિક્રિયાનો સામાન્ય રેખાકૃતિ આકૃતિ 11 માં પ્રસ્તુત છે.

આકૃતિ 11. જરૂરીયાતો વ્યવસ્થાપન સિસ્ટમ સાથે ક્રિયાપ્રતિક્રિયાનો આકૃતિ.

SimInTech ટેસ્ટ પ્રોજેક્ટ અને જરૂરિયાત નિયંત્રણ સિસ્ટમ વચ્ચેની ક્રિયાપ્રતિક્રિયાનો ક્રમ નીચે મુજબ છે:

1. સંદર્ભની શરતો આવશ્યકતાઓમાં વિભાજિત કરવામાં આવી છે.
2. તકનીકી વિશિષ્ટતાઓની આવશ્યકતાઓને ઓળખવામાં આવે છે જે તકનીકી પ્રક્રિયાઓના ગાણિતિક મોડેલિંગ દ્વારા ચકાસી શકાય છે.
3. પસંદ કરેલ આવશ્યકતાઓના લક્ષણો પ્રમાણભૂત બ્લોક્સની રચનામાં સિમઇનટેક સિગ્નલ ડેટાબેઝમાં સ્થાનાંતરિત થાય છે (ઉદાહરણ તરીકે, મહત્તમ અને લઘુત્તમ તાપમાન).
4. ગણતરી પ્રક્રિયા દરમિયાન, માળખું ડેટા બ્લોક ડિઝાઇન ડાયાગ્રામ પર સ્થાનાંતરિત થાય છે, વિશ્લેષણ કરવામાં આવે છે અને પરિણામો સિગ્નલ ડેટાબેઝમાં સંગ્રહિત થાય છે.
5. એકવાર ગણતરી પૂર્ણ થઈ જાય, વિશ્લેષણના પરિણામો આવશ્યકતાઓ વ્યવસ્થાપન સિસ્ટમમાં સ્થાનાંતરિત થાય છે.

જ્યારે ડિઝાઇન અને/અથવા આવશ્યકતાઓમાં ફેરફાર થાય અને ફેરફારોની અસરને ફરીથી ચકાસવાની જરૂર હોય ત્યારે જરૂરીયાતો પગલાં 3 થી 5 સુધી ડિઝાઇન પ્રક્રિયા દરમિયાન પુનરાવર્તિત થઈ શકે છે.

તારણો

• સિસ્ટમનો બનાવેલ પ્રોટોટાઇપ તકનીકી વિશિષ્ટતાઓની આવશ્યકતાઓનું પાલન કરવા માટે હાલના મોડલ્સના વિશ્લેષણના સમયમાં નોંધપાત્ર ઘટાડો પૂરો પાડે છે.
• પ્રસ્તાવિત ટેસ્ટીંગ ટેક્નોલોજી પહેલાથી જ અસ્તિત્વમાં છે તે ડાયનેમિક મોડલ્સનો ઉપયોગ કરે છે અને તેનો ઉપયોગ કોઈપણ ડાયનેમિક મોડલ્સ માટે પણ થઈ શકે છે, જેમાં SimInTech વાતાવરણમાં કરવામાં ન આવતા હોય તે સહિત.
• બેચ ડેટા ઓર્ગેનાઈઝેશનનો ઉપયોગ કરવાથી તમે મોડલ ડેવલપમેન્ટની સમાંતર જરૂરિયાતો ચકાસણી પેકેજો બનાવી શકો છો અથવા તો મોડલ ડેવલપમેન્ટ માટે ટેક્નિકલ વિશિષ્ટતાઓ તરીકે આ પેકેજોનો ઉપયોગ કરી શકો છો.
• ટેક્નોલોજીને નોંધપાત્ર ખર્ચ વિના હાલની જરૂરિયાતો વ્યવસ્થાપન પ્રણાલીઓ સાથે સંકલિત કરી શકાય છે.

જેઓ અંત સુધી વાંચે છે તેમના માટે, પ્રોટોટાઇપ કેવી રીતે કાર્ય કરે છે તે દર્શાવતી વિડિઓની લિંક.

સોર્સ: www.habr.com