Տեխնիկական բնութագրերի պահանջների ավտոմատ ստուգում դինամիկ մոդելավորման ժամանակ

Շարունակելով թեման «Ի՞նչ ապացույցներ ունեք»:, մյուս կողմից նայենք մաթեմատիկական մոդելավորման խնդրին։ Այն բանից հետո, երբ համոզվենք, որ մոդելը համապատասխանում է կյանքի իրական ճշմարտությանը, կարող ենք պատասխանել հիմնական հարցին. Տեխնիկական օբյեկտի մոդել ստեղծելիս մենք սովորաբար ցանկանում ենք համոզվել, որ այս օբյեկտը կհամապատասխանի մեր սպասելիքներին: Այդ նպատակով իրականացվում են գործընթացների դինամիկ հաշվարկներ և արդյունքը համեմատվում է պահանջների հետ։ Սա թվային երկվորյակ է, վիրտուալ նախատիպ և այլն: նորաձև փոքրիկ տղաներ, ովքեր դիզայնի փուլում լուծում են այն խնդիրը, թե ինչպես համոզվել, որ մենք ստանում ենք այն, ինչ պլանավորել ենք:

Ինչպե՞ս կարող ենք արագ համոզվել, որ մեր համակարգը հենց այն է, ինչ մենք նախագծել ենք, մեր դիզայնը թռչելու է, թե՞ լողալու: Եվ եթե այն թռչում է, ապա որքան բարձր է: Եվ եթե այն լողում է, ապա որքան խորը:

Այս հոդվածում քննարկվում է տեխնիկական համակարգերի դինամիկ մոդելների ստեղծման ժամանակ տեխնիկական շենքի պահանջներին համապատասխանության ստուգման ավտոմատացումը: Որպես օրինակ, եկեք դիտարկենք օդանավի օդային հովացման համակարգի տեխնիկական բնութագրի տարրը:

Մենք համարում ենք այն պահանջները, որոնք կարող են թվային կերպով արտահայտվել և մաթեմատիկորեն ստուգվել՝ հիմնվելով կոնկրետ հաշվարկային մոդելի վրա: Հասկանալի է, որ սա ցանկացած տեխնիկական համակարգի ընդհանուր պահանջների միայն մի մասն է, բայց դրանք ստուգելու վրա է, որ մենք ժամանակ, նյարդեր և գումար ենք ծախսում օբյեկտի դինամիկ մոդելներ ստեղծելու վրա:

Տեխնիկական պահանջները փաստաթղթի տեսքով նկարագրելիս կարելի է առանձնացնել տարբեր պահանջների մի քանի տեսակներ, որոնցից յուրաքանչյուրը պահանջում է տարբեր մոտեցումներ պահանջների կատարման ավտոմատ ստուգման ձևավորման համար:

Օրինակ, հաշվի առեք այս փոքր, բայց իրատեսական պահանջների շարքը.

1. Մթնոլորտային օդի ջերմաստիճանը ջրի մաքրման համակարգի մուտքի մոտ.
   ավտոկայանատեղում՝ մինուս 35-ից մինչև 35 ºС,
   թռիչքի ժամանակ - մինուս 35-ից մինչև 39 ºС:
2. Մթնոլորտային օդի ստատիկ ճնշումը թռիչքի ժամանակ կազմում է 700-ից 1013 ԳՊա (526-ից մինչև 760 մմ Hg):
3. Օդի ընդհանուր ճնշումը SVO օդի ընդունման մուտքի մոտ թռիչքի ժամանակ կազմում է 754-ից մինչև 1200 ԳՊա (566-ից մինչև 1050 մմ Hg):
4. Սառեցման օդի ջերմաստիճանը.
   ավտոկայանատեղում՝ ոչ ավելի, քան 27 ºС, տեխնիկական բլոկների համար՝ ոչ ավելի, քան 29 ºС,
   թռիչքի ժամանակ՝ ոչ ավելի, քան 25 ºС, տեխնիկական բլոկների համար՝ ոչ ավելի, քան 27 ºС:
5. Սառեցման օդի հոսք.
   երբ կայանված՝ առնվազն 708 կգ/ժամ,
   թռիչքի ժամանակ՝ 660 կգ/ժ-ից ոչ պակաս։
6. Գործիքների խցիկում օդի ջերմաստիճանը 60 ºС-ից ոչ ավելի է:
7. Սառեցման օդում նուրբ ազատ խոնավության քանակը 2 գ/կգ չոր օդից ոչ ավելի է:

Նույնիսկ այս սահմանափակ պահանջների շրջանակում կա առնվազն երկու կատեգորիա, որոնք պետք է տարբեր կերպ վարվեն համակարգում.

• համակարգի գործառնական պայմանների պահանջները (կետեր 1-3);
• Համակարգի պարամետրային պահանջներ (3-7 կետեր):

Համակարգի աշխատանքային պայմանների պահանջներ
Մոդելավորման ընթացքում մշակվող համակարգի արտաքին պայմանները կարող են սահմանվել որպես սահմանային պայմաններ կամ ընդհանուր համակարգի աշխատանքի արդյունքում։
Դինամիկ մոդելավորման ժամանակ անհրաժեշտ է ապահովել, որ նշված աշխատանքային պայմանները ծածկված լինեն սիմուլյացիայի գործընթացով:

Պարամետրային համակարգի պահանջները
Այս պահանջները համակարգի կողմից տրված պարամետրեր են: Մոդելավորման գործընթացում մենք կարող ենք ստանալ այս պարամետրերը որպես հաշվարկման արդյունքներ և համոզվել, որ պահանջները բավարարված են յուրաքանչյուր կոնկրետ հաշվարկում:

Պահանջների նույնականացում և կոդավորում

Պահանջների հետ աշխատելու հեշտության համար գոյություն ունեցող ստանդարտները խորհուրդ են տալիս յուրաքանչյուր պահանջին նույնացուցիչ հատկացնել: Նույնացուցիչներ նշանակելիս շատ ցանկալի է օգտագործել միասնական կոդավորման համակարգ:

Պահանջների կոդը կարող է լինել պարզապես մի թիվ, որը ներկայացնում է պահանջի հերթականության համարը, կամ այն ​​կարող է պարունակել պահանջի տեսակի ծածկագիր, համակարգի կամ միավորի ծածկագիրը, որի վրա կիրառվում է, պարամետրի կոդը, գտնվելու վայրի կոդը և այլ բան, որ ինժեները կարող է պատկերացնել: (տե՛ս հոդվածը կոդավորման օգտագործման համար)

Աղյուսակ 1-ում ներկայացված է պահանջների կոդավորման պարզ օրինակ:

1. Պահանջների աղբյուրի ծածկագիրը R-պահանջներ TK;
2. Պահանջների ծածկագրի տեսակը E - պահանջներ - շրջակա միջավայրի պարամետրեր կամ աշխատանքային պայմաններ
   S - համակարգի կողմից նախատեսված պահանջներ;
3. օդանավի կարգավիճակի կոդը 0 – ցանկացած, G – կայանված, F – թռիչքի ժամանակ;
4. ֆիզիկական պարամետրի տիպի կոդը T – ջերմաստիճան, P – ճնշում, G – հոսքի արագություն, խոնավություն H;
5. պահանջի սերիական համարը.

ID Պահանջներ	Նկարագրություն	Parameter
REGT01	Շրջակա օդի ջերմաստիճանը ջրի հովացման համակարգի մուտքի մոտ՝ ավտոկայանատեղում՝ մինուս 35ºС-ից: մինչև 35 ºС:
REFT01	Մթնոլորտային օդի ջերմաստիճանը հակաօդային պաշտպանության համակարգի մուտքի մոտ՝ թռիչքի ժամանակ՝ մինուս 35 ºС-ից մինչև 39 ºС:
REFP01	Ստատիկ մթնոլորտային օդի ճնշումը թռիչքի ժամանակ կազմում է 700-ից 1013 հՊա (526-ից մինչև 760 մմ Hg):
REFP02	Օդի ընդհանուր ճնշումը SVO օդի ընդունման մուտքի մոտ թռիչքի ժամանակ կազմում է 754-ից մինչև 1200 հՊա (566-ից մինչև 1050 մմ Hg):
RSGT01	Սառեցման օդի ջերմաստիճանը` կայանման ժամանակ ոչ ավելի, քան 27 ºС
RSGT02	Սառեցման օդի ջերմաստիճանը` ավտոկայանատեղիում, տեխնիկական բլոկների համար ոչ ավելի, քան 29 ºС
RSFT01	Թռիչքի սառեցման օդի ջերմաստիճանը ոչ ավելի, քան 25 ºС
RSFT02	Սառեցման օդի ջերմաստիճանը` թռիչքի ժամանակ, տեխնիկական ստորաբաժանումների համար ոչ ավելի, քան 27 ºС
RSGG01	Սառեցման օդի հոսքը` կայանման դեպքում ոչ պակաս, քան 708 կգ/ժ
RSFG01	Սառեցման օդի հոսքը՝ թռիչքի ժամանակ ոչ պակաս, քան 660 կգ/ժ
RS0T01	Գործիքների խցիկում օդի ջերմաստիճանը 60 ºС-ից ոչ ավելի է
RSH01	Սառեցման օդում նուրբ ազատ խոնավության քանակը 2 գ/կգ չոր օդից ոչ ավելի է

Պահանջների ստուգման համակարգի ձևավորում:

Նախագծման յուրաքանչյուր պահանջի համար կա նախագծային պարամետրերի համապատասխանությունը գնահատելու ալգորիթմ և պահանջի մեջ նշված պարամետրերը: Մեծ հաշվով, ցանկացած կառավարման համակարգ միշտ պարունակում է ալգորիթմներ՝ պարզապես լռելյայն պահանջները ստուգելու համար: Եվ նույնիսկ ցանկացած կարգավորիչ պարունակում է դրանք: Եթե ​​ջերմաստիճանը դուրս է գալիս սահմաններից, ապա օդորակիչը միանում է: Այսպիսով, ցանկացած կարգավորման առաջին փուլը ստուգելն է, թե արդյոք պարամետրերը համապատասխանում են պահանջներին:

Եվ քանի որ ստուգումը ալգորիթմ է, ապա մենք կարող ենք օգտագործել նույն գործիքներն ու գործիքները, որոնք օգտագործում ենք հսկիչ ծրագրեր ստեղծելու համար։ Օրինակ, SimInTech միջավայրը թույլ է տալիս ստեղծել մոդելի տարբեր մասեր պարունակող նախագծերի փաթեթներ, որոնք իրականացվում են առանձին նախագծերի տեսքով (օբյեկտի մոդել, կառավարման համակարգի մոդել, միջավայրի մոդել և այլն):

Պահանջների ստուգման նախագիծն այս դեպքում դառնում է նույն ալգորիթմի նախագիծը և միացված է մոդելային փաթեթին։ Իսկ դինամիկ մոդելավորման ռեժիմում կատարում է վերլուծություն՝ տեխնիկական բնութագրերի պահանջներին համապատասխանելու համար:

Համակարգի նախագծման հնարավոր օրինակը ներկայացված է Նկար 1-ում:

Նկար 1. Ստուգման նախագծի նախագծման օրինակ:

Ինչպես վերահսկման ալգորիթմների դեպքում, պահանջները կարող են կազմվել որպես թերթիկների հավաքածու: Կառուցվածքային մոդելավորման միջավայրերում, ինչպիսիք են SimInTech, Simulink, AmeSim, ալգորիթմների հետ աշխատելու հարմարության համար օգտագործվում է ենթամոդելների տեսքով բազմամակարդակ կառույցներ ստեղծելու հնարավորությունը: Այս կազմակերպությունը հնարավորություն է տալիս խմբավորել տարբեր պահանջներ խմբերի մեջ՝ պարզեցնելու համար պահանջների զանգվածի հետ աշխատանքը, ինչպես դա արվում է կառավարման ալգորիթմների համար (տես Նկար 2):

Նկար 2. Պահանջների ստուգման մոդելի հիերարխիկ կառուցվածքը:

Օրինակ, քննարկվող դեպքում առանձնանում են երկու խումբ՝ պահանջներ շրջակա միջավայրին և պահանջներ ուղղակիորեն համակարգին։ Հետևաբար, օգտագործվում է երկու մակարդակի տվյալների կառուցվածք՝ երկու խումբ, որոնցից յուրաքանչյուրը ալգորիթմի տևն է։

Տվյալները մոդելին միացնելու համար օգտագործվում է ազդանշանային տվյալների բազա ստեղծելու ստանդարտ սխեմա, որը պահպանում է տվյալներ նախագծի մասերի միջև փոխանակման համար:

Ծրագրային ապահովման ստեղծման և փորձարկման ժամանակ սենսորների ընթերցումները (իրական համակարգի սենսորների անալոգները), որոնք օգտագործվում են կառավարման համակարգի կողմից, տեղադրվում են այս տվյալների բազայում:
Փորձնական նախագծի համար դինամիկ մոդելում հաշվարկված ցանկացած պարամետր կարող է պահվել նույն տվյալների բազայում և այդպիսով օգտագործվել՝ ստուգելու համար, թե արդյոք պահանջները բավարարված են:

Այս դեպքում դինամիկ մոդելն ինքնին կարող է իրականացվել ցանկացած մաթեմատիկական մոդելավորման համակարգում կամ նույնիսկ գործարկվող ծրագրի տեսքով։ Միակ պահանջը ծրագրային ինտերֆեյսների առկայությունն է՝ մոդելավորման տվյալները արտաքին միջավայր տրամադրելու համար:

Նկար 3. Ստուգման նախագիծը համալիր մոդելին միացնելը:

Հիմնական պահանջների ստուգման թերթիկի օրինակը ներկայացված է Նկար 4-ում: Մշակողի տեսանկյունից դա սովորական հաշվարկային դիագրամ է, որի վրա գրաֆիկորեն ներկայացված է պահանջների ստուգման ալգորիթմը:

Նկար 4. Պահանջների ստուգման թերթիկ:

Ստուգման թերթիկի հիմնական մասերը նկարագրված են Նկար 5-ում: Ստուգման ալգորիթմը ձևավորվում է այնպես, ինչպես կառավարման ալգորիթմների նախագծման դիագրամները: Աջ կողմում կա տվյալների բազայից ազդանշաններ կարդալու բլոկ: Այս բլոկը մուտք է գործում ազդանշանային տվյալների բազա մոդելավորման ընթացքում:

Ստացված ազդանշանները վերլուծվում են պահանջների ստուգման պայմանները հաշվարկելու համար: Այս դեպքում կատարվում է բարձրության վերլուծություն՝ որոշելու օդանավի դիրքը (կայանված է, թե թռիչքի ժամանակ): Այդ նպատակով կարող եք օգտագործել մոդելի այլ ազդանշաններ և հաշվարկված պարամետրեր:

Ստուգվող ստուգման պայմանները և պարամետրերը փոխանցվում են ստանդարտ ստուգման բլոկների, որոնցում այդ պարամետրերը վերլուծվում են նշված պահանջներին համապատասխանելու համար: Արդյունքները գրանցվում են ազդանշանային տվյալների բազայում այնպես, որ դրանք կարող են օգտագործվել ավտոմատ կերպով ստուգաթերթ ստեղծելու համար:

Նկար 5. Պահանջների ստուգման հաշվարկային թերթիկի կառուցվածքը:

Փորձարկվող պարամետրերը պարտադիր չէ, որ օգտագործեն տվյալների բազայում պարունակվող ազդանշաններ, որոնք վերահսկվում են մոդելավորման գործընթացում հաշվարկված պարամետրերով: Մեզ ոչինչ չի խանգարում նախագծի պահանջների շրջանակներում լրացուցիչ հաշվարկներ կատարել, ինչպես մենք հաշվում ենք ստուգման պայմանները։

Օրինակ, այս պահանջը.

Թիրախ թռիչքի ընթացքում ուղղիչ համակարգի ակտիվացումների թիվը չպետք է գերազանցի 5-ը, իսկ ուղղիչ համակարգի ընդհանուր գործառնական ժամանակը չպետք է գերազանցի 30 վայրկյանը:

Այս դեպքում պահանջների նախագծման գծապատկերին ավելացվում է մեկնարկների քանակի և գործառնական ընդհանուր ժամանակի հակազդման ալգորիթմ:

Տիպիկ պահանջների ստուգման բլոկ:

Յուրաքանչյուր ստանդարտ պահանջի վանդակը նախատեսված է որոշակի տեսակի պահանջի կատարումը հաշվարկելու համար: Օրինակ, բնապահպանական պահանջները ներառում են շրջակա միջավայրի աշխատանքային ջերմաստիճանների մի շարք, երբ կայանված և թռիչքի ժամանակ: Այս բլոկը պետք է ստանա մոդելի օդի ջերմաստիճանը որպես պարամետր և որոշի, թե արդյոք այս պարամետրը ընդգրկում է նշված ջերմաստիճանի միջակայքը:/p>

Բլոկը պարունակում է երկու մուտքային պորտ՝ պարամ և պայման։

Առաջինը սնվում է ստուգվող պարամետրով: Այս դեպքում՝ «Արտաքին ջերմաստիճան»:

Երկրորդ պորտին մատակարարվում է Բուլյան փոփոխական՝ ստուգումը կատարելու պայմանը:

Եթե ​​TRUE (1) ստացվում է երկրորդ մուտքագրման ժամանակ, ապա բլոկը կատարում է պահանջների ստուգման հաշվարկ:

Եթե ​​երկրորդ մուտքագրումը ստանում է FALSE (0), ապա փորձարկման պայմանները չեն պահպանվում: Դա անհրաժեշտ է, որպեսզի հաշվի առնվեն հաշվարկի պայմանները։ Մեր դեպքում այս մուտքագրումն օգտագործվում է ստուգումը միացնելու կամ անջատելու համար՝ կախված մոդելի վիճակից: Եթե ​​սիմուլյացիայի ժամանակ օդանավը գտնվում է գետնին, ապա թռիչքի հետ կապված պահանջները չեն ստուգվում, և հակառակը՝ եթե օդանավը թռիչքի մեջ է, ապա կանգառում շահագործման հետ կապված պահանջները չեն ստուգվում։

Այս մուտքագրումը կարող է օգտագործվել նաև մոդելը կարգավորելիս, օրինակ՝ հաշվարկի սկզբնական փուլում: Երբ մոդելը բերվում է անհրաժեշտ վիճակի, ստուգման բլոկներն անջատված են, բայց հենց որ համակարգը հասնում է պահանջվող աշխատանքային ռեժիմին, ստուգման բլոկները միացված են:

Այս բլոկի պարամետրերն են.

• սահմանային պայմաններ. վերին (UpLimit) և ստորին (DownLimit) միջակայքի սահմանները, որոնք պետք է ստուգվեն.
• համակարգի ազդեցության պահանջվող ժամանակը սահմանային միջակայքերում (TimeInterval) վայրկյաններով;
• Հարցման ID ReqName;
• ընդգրկույթը գերազանցելու թույլատրելիությունը Out_range-ը բուլյան փոփոխական է, որը որոշում է, թե արդյոք ստուգված միջակայքը գերազանցող արժեքը պահանջի խախտում է:

Որոշ դեպքերում, փորձարկման արժեքի ելքը ցույց է տալիս, որ համակարգն ունի որոշակի մարժան և կարող է գործել իր աշխատանքային տիրույթից դուրս: Այլ դեպքերում, ելքը նշանակում է, որ համակարգը չի կարողանում սահմանային կետերը պահել տիրույթում:

Նկար 6. Տիպիկ գույքի ստուգման բլոկ դիագրամում և դրա պարամետրերում:

Այս բլոկի հաշվարկի արդյունքում ելքում ձևավորվում է Result փոփոխականը, որն ընդունում է հետևյալ արժեքները.

• 0 – rՈչ մի, արժեքը սահմանված չէ;
• 1 – rԿատարված է, պահանջը բավարարված է.
• 2 – Սխալ, պահանջը չի բավարարվում:

Բլոկի պատկերը պարունակում է.

• նույնականացման տեքստ;
• չափման սահմանաչափերի պարամետրերի թվային ցուցադրում;
• պարամետրի կարգավիճակի գույնի նույնացուցիչ:

Բլոկի ներսում կարող է լինել բավականին բարդ տրամաբանական եզրակացության միացում:

Օրինակ, Նկար 6-ում ցուցադրված միավորի աշխատանքային ջերմաստիճանի միջակայքը ստուգելու համար ներքին միացումը ներկայացված է Նկար 7-ում:

Նկար 7. Ջերմաստիճանի միջակայքի որոշման միավորի ներքին դիագրամ:

Շղթայի բլոկի ներսում օգտագործվում են բլոկի պարամետրերում նշված հատկությունները:
Բացի պահանջներին համապատասխանության վերլուծությունից, բլոկի ներքին դիագրամը պարունակում է սիմուլյացիայի արդյունքների ցուցադրման համար անհրաժեշտ գրաֆիկ: Այս գրաֆիկը կարող է օգտագործվել ինչպես հաշվարկի ընթացքում դիտելու, այնպես էլ հաշվարկից հետո արդյունքները վերլուծելու համար:

Հաշվարկի արդյունքները փոխանցվում են բլոկի ելքին և միաժամանակ գրանցվում ընդհանուր հաշվետվության ֆայլում, որը ստեղծվում է ամբողջ նախագծի արդյունքների հիման վրա: (տես նկ. 8)

Մոդելավորման արդյունքների հիման վրա ստեղծված հաշվետվության օրինակ է html ֆայլը, որը ստեղծված է տվյալ ձևաչափով։ Ձևաչափը կարող է կամայականորեն կարգավորվել որոշակի կազմակերպության կողմից ընդունված ձևաչափով:

Շղթայի բլոկի ներսում օգտագործվում են բլոկի պարամետրերում նշված հատկությունները:
Բացի պահանջներին համապատասխանության վերլուծությունից, բլոկի ներքին դիագրամը պարունակում է սիմուլյացիայի արդյունքների ցուցադրման համար անհրաժեշտ գրաֆիկ: Այս գրաֆիկը կարող է օգտագործվել ինչպես հաշվարկի ընթացքում դիտելու, այնպես էլ հաշվարկից հետո արդյունքները վերլուծելու համար:

Հաշվարկի արդյունքները փոխանցվում են բլոկի ելքին և միաժամանակ գրանցվում ընդհանուր հաշվետվության ֆայլում, որը ստեղծվում է ամբողջ նախագծի արդյունքների հիման վրա: (տես նկ. 8)

Մոդելավորման արդյունքների հիման վրա ստեղծված հաշվետվության օրինակ է html ֆայլը, որը ստեղծված է տվյալ ձևաչափով։ Ձևաչափը կարող է կամայականորեն կարգավորվել որոշակի կազմակերպության կողմից ընդունված ձևաչափով:

Նկար 8. Մոդելավորման արդյունքների հիման վրա հաշվետվության ֆայլի օրինակ:

Այս օրինակում հաշվետվության ձևը կազմաձևվում է անմիջապես նախագծի հատկությունների մեջ, և աղյուսակի ձևաչափը սահմանվում է որպես ծրագրի գլոբալ ազդանշաններ: Այս դեպքում SimInTech-ն ինքն է լուծում հաշվետվությունը կարգավորելու խնդիրը, և ֆայլում արդյունքներ գրելու բլոկը օգտագործում է այս տողերը՝ հաշվետվության ֆայլում գրելու համար։

Նկար 9. Հաշվետվության ձևաչափի սահմանում գլոբալ նախագծի ազդանշաններում

Պահանջների համար ազդանշանային տվյալների բազայի օգտագործումը:

Գույքի կարգավորումների հետ աշխատանքը ավտոմատացնելու համար յուրաքանչյուր բնորոշ բլոկի համար ազդանշանային տվյալների բազայում ստեղծվում է ստանդարտ կառուցվածք: (տես նկ. 10)

Նկար 10. Պահանջների ստուգման բլոկի կառուցվածքի օրինակ ազդանշանային տվյալների բազայում:

Ազդանշանների բազան ապահովում է.

• Համակարգի բոլոր անհրաժեշտ պահանջների պարամետրերի պահպանում:
• Նախագծի առկա պահանջների հարմար դիտում նշված պարամետրերից և ընթացիկ մոդելավորման արդյունքներից:
• Մեկ բլոկի կամ բլոկների խմբի ստեղծում՝ օգտագործելով ծրագրավորման ծրագրավորման լեզու: Ազդանշանների տվյալների բազայի փոփոխությունները հանգեցնում են դիագրամում բլոկի գույքի արժեքների փոփոխության:
• Պահանջների կառավարման համակարգում տեքստային նկարագրությունների, տեխնիկական բնութագրերի կետերի կամ նույնացուցիչների հղումների պահպանում:

Պահանջների համար ազդանշանային տվյալների բազայի կառուցվածքները կարող են հեշտությամբ կարգավորվել երրորդ կողմի պահանջների կառավարման համակարգի հետ աշխատելու համար: Պահանջների կառավարման համակարգերի հետ փոխգործակցության ընդհանուր դիագրամը ներկայացված է Նկար 11-ում:

Նկար 11. Պահանջների կառավարման համակարգի հետ փոխգործակցության դիագրամ:

SimInTech թեստային նախագծի և պահանջների վերահսկման համակարգի փոխազդեցության հաջորդականությունը հետևյալն է.

1. Տեխնիկական պայմանները բաժանված են պահանջների:
2. Սահմանված են տեխնիկական բնութագրերի պահանջները, որոնք կարող են ստուգվել տեխնիկական գործընթացների մաթեմատիկական մոդելավորման միջոցով:
3. Ընտրված պահանջների հատկանիշները փոխանցվում են SimInTech ազդանշանային տվյալների բազա՝ ստանդարտ բլոկների կառուցվածքում (օրինակ՝ առավելագույն և նվազագույն ջերմաստիճան):
4. Հաշվարկի ընթացքում կառուցվածքի տվյալները փոխանցվում են բլոկային նախագծման դիագրամներին, կատարվում է վերլուծություն և արդյունքները պահվում են ազդանշանային տվյալների բազայում:
5. Հաշվարկն ավարտվելուց հետո վերլուծության արդյունքները փոխանցվում են պահանջների կառավարման համակարգ:

Պահանջների 3-ից 5-րդ քայլերը կարող են կրկնվել նախագծման գործընթացի ընթացքում, երբ նախագծում և/կամ պահանջների փոփոխություններ են տեղի ունենում, և փոփոխությունների ազդեցությունը պետք է նորից փորձարկվի:

Եզրակացություններ:

• Համակարգի ստեղծված նախատիպը ապահովում է առկա մոդելների վերլուծության ժամանակի զգալի կրճատում՝ տեխնիկական բնութագրերի պահանջներին համապատասխանելու համար:
• Առաջարկվող թեստավորման տեխնոլոգիան օգտագործում է արդեն գոյություն ունեցող դինամիկ մոդելներ և կարող է օգտագործվել նույնիսկ ցանկացած դինամիկ մոդելների համար, ներառյալ նրանց, որոնք չեն իրականացվում SimInTech միջավայրում:
• Խմբաքանակի տվյալների կազմակերպման օգտագործումը թույլ է տալիս մոդելի մշակմանը զուգահեռ ստեղծել պահանջների ստուգման փաթեթներ, կամ նույնիսկ օգտագործել այդ փաթեթները որպես մոդելի մշակման տեխնիկական բնութագրեր:
• Տեխնոլոգիան կարող է ինտեգրվել առկա պահանջների կառավարման համակարգերին՝ առանց զգալի ծախսերի:

Նրանց համար, ովքեր կարդում են մինչև վերջ, հղում դեպի տեսանյութ, որը ցույց է տալիս, թե ինչպես է աշխատում նախատիպը:

Source: www.habr.com