ტექნიკური მახასიათებლების მოთხოვნების ავტომატური გადამოწმება დინამიური მოდელირების დროს

თემის გაგრძელება "რა არის თქვენი მტკიცებულება?", მოდი მეორე მხრიდან შევხედოთ მათემატიკური მოდელირების პრობლემას. მას შემდეგ, რაც დავრწმუნდებით, რომ მოდელი შეესაბამება ცხოვრებისეულ ჭეშმარიტებას, შეგვიძლია ვუპასუხოთ მთავარ კითხვას: „ზუსტად რა გვაქვს აქ?“ ტექნიკური ობიექტის მოდელის შექმნისას, როგორც წესი, გვინდა დავრწმუნდეთ, რომ ეს ობიექტი ჩვენს მოლოდინებს დააკმაყოფილებს. ამ მიზნით ტარდება პროცესების დინამიური გამოთვლები და შედეგი შედარებულია მოთხოვნებთან. ეს არის ციფრული ტყუპი, ვირტუალური პროტოტიპი და ა.შ. მოდური პატარა ბიჭები, რომლებიც დიზაინის ეტაპზე წყვეტენ პრობლემას, თუ როგორ უნდა დავრწმუნდეთ, რომ მივიღებთ იმას, რაც დავგეგმეთ.

როგორ შეგვიძლია სწრაფად დავრწმუნდეთ, რომ ჩვენი სისტემა არის ზუსტად ის, რაც ჩვენ შევქმნით, ჩვენი დიზაინი გაფრინდება თუ ცურავს? და თუ დაფრინავს, რა სიმაღლეზე? და თუ ის ცურავს, რა სიღრმეში?

ეს სტატია განიხილავს ტექნიკური შენობის მოთხოვნებთან შესაბამისობის გადამოწმების ავტომატიზაციას ტექნიკური სისტემების დინამიური მოდელების შექმნისას. მაგალითად, მოდით შევხედოთ თვითმფრინავის ჰაერის გაგრილების სისტემის ტექნიკური სპეციფიკაციის ელემენტს.

ჩვენ განვიხილავთ იმ მოთხოვნებს, რომლებიც შეიძლება იყოს გამოსახული რიცხობრივად და დამოწმებული მათემატიკურად კონკრეტული გაანგარიშების მოდელის საფუძველზე. გასაგებია, რომ ეს არის მხოლოდ ზოგადი მოთხოვნების ნაწილი ნებისმიერი ტექნიკური სისტემისთვის, მაგრამ სწორედ მათ შემოწმებაზე ვხარჯავთ დროს, ნერვებსა და ფულს ობიექტის დინამიური მოდელების შესაქმნელად.

ტექნიკური მოთხოვნების დოკუმენტის სახით აღწერისას შეიძლება განვასხვავოთ სხვადასხვა სახის მოთხოვნების რამდენიმე ტიპი, რომელთაგან თითოეული მოითხოვს განსხვავებულ მიდგომას მოთხოვნების შესრულების ავტომატური გადამოწმების ფორმირებისთვის.

მაგალითად, განიხილეთ მოთხოვნების ეს მცირე, მაგრამ რეალისტური ნაკრები:

1. ატმოსფერული ჰაერის ტემპერატურა წყლის გამწმენდი სისტემის შესასვლელთან:
   ავტოსადგომზე - მინუს 35-დან 35 ºС-მდე,
   ფრენისას - მინუს 35-დან 39 ºС-მდე.
2. ფრენისას ატმოსფერული ჰაერის სტატიკური წნევა არის 700-დან 1013 გპა-მდე (526-დან 760 მმ ვწყ.სვ-მდე).
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 მოთხოვნები	აღწერა	პარამეტრის
REGT01	ატმოსფერული ჰაერის ტემპერატურა წყლის გაგრილების სისტემის შესასვლელთან: ავტოსადგომზე - მინუს 35ºС-დან. 35 ºС-მდე.
REFT01	ატმოსფერული ჰაერის ტემპერატურა საჰაერო თავდაცვის სისტემის შესასვლელთან: ფრენისას - მინუს 35 ºС-დან 39 ºС-მდე.
REFP01	სტატიკური ატმოსფერული ჰაერის წნევა ფრენისას არის 700-დან 1013 hPa-მდე (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 – rNone, მნიშვნელობა არ არის განსაზღვრული;
• 1 – rDone, მოთხოვნა დაკმაყოფილებულია;
• 2 – rFault, მოთხოვნა არ არის დაკმაყოფილებული.

ბლოკის სურათი შეიცავს:

• იდენტიფიკატორის ტექსტი;
• საზომი ლიმიტების პარამეტრების ციფრული ჩვენება;
• პარამეტრის სტატუსის ფერის იდენტიფიკატორი.

ბლოკის შიგნით შეიძლება იყოს საკმაოდ რთული ლოგიკური დასკვნის წრე.

მაგალითად, 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