🥇ડાયનેમિક મોડેલિંગ દરમિયાન ટેકનિકલ વિશિષ્ટતાઓની સ્વચાલિત ચકાસણી

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

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

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

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

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

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

SVO ના પ્રવેશદ્વાર પર વાતાવરણીય હવાનું તાપમાન:
પાર્કિંગમાં - માઈનસ 35 થી 35 ºС સુધી,
ફ્લાઇટમાં - માઈનસ 35 થી 39 ºС સુધી.
ઉડાન દરમિયાન વાતાવરણીય હવાનું સ્થિર દબાણ 700 થી 1013 GPa (526 થી 760 mmHg) સુધી હોય છે.
ફ્લાઇટમાં SVO ના હવાના સેવનના પ્રવેશદ્વાર પર કુલ હવાનું દબાણ 754 થી 1200 GPa (566 થી 1050 mm Hg) છે.
ઠંડક હવાનું તાપમાન:
પાર્કિંગમાં - 27 ºС થી વધુ નહીં, ટેકનિકલ બ્લોક્સ માટે - 29 ºС થી વધુ નહીં,
ફ્લાઇટમાં - 25 ºС થી વધુ નહીં, ટેકનિકલ બ્લોક્સ માટે - 27 ºС થી વધુ નહીં.
ઠંડક આપતી હવાનો પ્રવાહ:
સ્થિર સ્થિતિમાં - ઓછામાં ઓછું 708 કિગ્રા/કલાક,
ફ્લાઇટમાં - 660 કિગ્રા/કલાકથી ઓછું નહીં.
ઇન્સ્ટ્રુમેન્ટ કમ્પાર્ટમેન્ટમાં હવાનું તાપમાન 60 ºС થી વધુ નથી.
ઠંડક આપતી હવામાં બારીક વિખરાયેલા મુક્ત ભેજનું પ્રમાણ 2 ગ્રામ/કિલો સૂકી હવા કરતાં વધુ ન હોવું જોઈએ.

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

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

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

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

જરૂરિયાતોની ઓળખ અને એન્કોડિંગ

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

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

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

જરૂરિયાત સોર્સ કોડ આર - તકનીકી સ્પષ્ટીકરણોની આવશ્યકતાઓ;
કોડ પ્રકારની આવશ્યકતાઓ E - આવશ્યકતાઓ - પર્યાવરણીય પરિમાણો, અથવા ઓપરેટિંગ પરિસ્થિતિઓ
S — સિસ્ટમ દ્વારા પૂરી પાડવામાં આવતી જરૂરિયાતો;
એરક્રાફ્ટ સ્ટેટસ કોડ 0 – કોઈપણ, G – પાર્ક કરેલ, F – ફ્લાઇટમાં;
ભૌતિક પરિમાણોના પ્રકારનો કોડ T – તાપમાન, P – દબાણ, G – પ્રવાહ દર, ભેજ H;
જરૂરિયાતનો ક્રમાંક.

ID જરૂરીયાતો	વર્ણન	પેરામીટર
REGT01	SVO ના પ્રવેશદ્વાર પર વાતાવરણીય હવાનું તાપમાન: સ્થિર સ્થિતિમાં - માઈનસ 35ºС થી 35ºС સુધી.
REFT01 નો પરિચય	SVO ના પ્રવેશદ્વાર પર વાતાવરણીય હવાનું તાપમાન: ફ્લાઇટમાં - માઈનસ 35 ºС થી 39 ºС સુધી.
આરઇએફપી01	ઉડાન દરમિયાન વાતાવરણીય હવાનું સ્થિર દબાણ 700 થી 1013 hPa (526 થી 760 mm Hg) સુધી હોય છે.
આરઇએફપી02	ફ્લાઇટમાં SVO ના હવાના સેવનના પ્રવેશદ્વાર પર કુલ હવાનું દબાણ 754 થી 1200 hPa (566 થી 1050 mm Hg) છે.
આરએસજીટી01	ઠંડક આપતી હવાનું તાપમાન: જ્યારે પાર્ક કરેલ હોય ત્યારે 27 ºС થી વધુ ન હોય
આરએસજીટી02	ઠંડક હવાનું તાપમાન: જ્યારે પાર્ક કરવામાં આવે છે, ત્યારે તકનીકી એકમો માટે 29 ºС થી વધુ નહીં
આરએસએફટી01	ફ્લાઇટ દરમિયાન ઠંડક આપતી હવાનું તાપમાન 25 ºС કરતા વધુ ન હોય
આરએસએફટી02	ઠંડક હવાનું તાપમાન: ફ્લાઇટમાં, તકનીકી એકમો માટે 27 ºС થી વધુ નહીં
આરએસજીજી01	ઠંડક હવાનો વપરાશ: સ્થિરતા પર ઓછામાં ઓછું 708 કિગ્રા/કલાક
આરએસએફજી01	ઠંડક હવાનો વપરાશ: ફ્લાઇટમાં 660 કિગ્રા/કલાકથી ઓછો નહીં
RS0T01 નો પરિચય	ઇન્સ્ટ્રુમેન્ટ કમ્પાર્ટમેન્ટમાં હવાનું તાપમાન 60 ºС થી વધુ નથી
આરએસએચ01	ઠંડી હવામાં બારીક વિખરાયેલા મુક્ત ભેજનું પ્રમાણ 2 ગ્રામ/કિલો સૂકી હવા કરતાં વધુ ન હોવું જોઈએ.

આવશ્યકતાઓ ચકાસણી સિસ્ટમ પ્રોજેક્ટ.

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

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

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

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

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

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

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

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

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

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

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

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

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

આકૃતિ 4. આવશ્યકતાઓની ચેકલિસ્ટ.

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

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

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

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

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

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

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

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

લાક્ષણિક આવશ્યકતાઓ ચકાસણી બ્લોક.

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

બ્લોકમાં બે ઇનપુટ પોર્ટ, param અને condition છે.

પ્રથમ પરિમાણ પરીક્ષણ હેઠળ છે તે પરિમાણ સાથે ફીડ કરવામાં આવે છે. આ કિસ્સામાં, તે "એમ્બિયન્ટ તાપમાન" છે.

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

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

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

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

આ બ્લોક માટે નીચેના પરિમાણો ઉલ્લેખિત છે:

સીમાની સ્થિતિઓ: તપાસવા માટેની શ્રેણીઓની ઉપલી (UpLimit) અને નીચલી (DownLimit) મર્યાદાઓ;
સીમા શ્રેણીઓ (સમય અંતરાલ) પર જરૂરી સિસ્ટમ નિવાસ સમય સેકન્ડમાં;
ReqName જરૂરિયાત ઓળખકર્તા;
આઉટ_રેન્જ ટોલરન્સ - એક બુલિયન ચલ જે નક્કી કરે છે કે ચેક કરેલ રેન્જની બહાર જતું મૂલ્ય જરૂરિયાતનું ઉલ્લંઘન કરે છે કે નહીં.

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

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

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

0 – rNone, મૂલ્ય વ્યાખ્યાયિત નથી;
૧ – પૂર્ણ થયું, જરૂરિયાત પૂરી થઈ ગઈ;
2 – rFault, જરૂરિયાત પૂરી થઈ નથી.

બ્લોક છબીમાં આ શામેલ છે:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

તારણો

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

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

સોર્સ: www.habr.com