Dinamik simulyasiya prosesində TOR tələblərinin avtomatik yoxlanılması

Mövzunun davamı "Sənin sübutun nədir?", riyazi modelləşdirmə probleminə digər tərəfdən baxaq. Modelin həyat həqiqətinə uyğun olduğuna əmin olduqdan sonra əsas suala cavab verə bilərik: "burada, dəqiq olaraq, bizdə nə var?" Texniki obyektin modelini yaradan zaman biz adətən əmin olmaq istəyirik ki, bu obyekt bizim gözləntilərimizə cavab verəcək. Bu məqsədlə proseslərin dinamik hesablamaları aparılır və nəticə tələblərlə müqayisə edilir. Bu rəqəmsal əkiz, virtual prototip və s. dizayn mərhələsində, planlaşdırdığımızı əldə etməyimizə necə əmin olmaq problemini həll edən dəbli kiçik uşaqlar.

Sistemimizin dizayn etdiyimiz kimi olduğuna necə tez əmin ola bilərik, dizaynımız uçacaq, yoxsa üzəcək? Və uçursa, nə qədər yüksəkdir? Və əgər üzürsə, nə qədər dərinlikdə?

Bu məqalə texniki sistemlərin dinamik modellərini yaratarkən texniki binanın tələblərinə uyğunluğunun yoxlanılmasının avtomatlaşdırılmasından bəhs edir. Nümunə olaraq, təyyarənin hava soyutma sistemi üçün texniki spesifikasiyanın bir elementinə baxaq.

Biz konkret hesablama modelinə əsaslanaraq, rəqəmlə ifadə oluna və riyazi olaraq yoxlana bilən tələbləri nəzərdən keçiririk. Aydındır ki, bu, hər hansı bir texniki sistem üçün ümumi tələblərin yalnız bir hissəsidir, lakin biz obyektin dinamik modellərini yaratmaq üçün vaxt, əsəb və pul sərf edirik.

Texniki tələbləri sənəd şəklində təsvir edərkən, tələblərin yerinə yetirilməsinin avtomatik yoxlanışının formalaşdırılması üçün hər biri müxtəlif yanaşmalar tələb edən bir neçə növ müxtəlif tələbləri ayırd etmək olar.

Məsələn, bu kiçik, lakin real tələblər toplusunu nəzərdən keçirin:

1. Su təmizləmə sisteminin girişində atmosfer havasının temperaturu:
   dayanacaqda - mənfi 35 ilə 35 ºС arasında,
   uçuşda - mənfi 35 ilə 39 ºС arasında.
2. Uçuş zamanı atmosfer havasının statik təzyiqi 700 ilə 1013 GPa (526 ilə 760 mm Hg arasında) təşkil edir.
3. Uçuş zamanı SVO hava qəbulunun girişindəki ümumi hava təzyiqi 754 ilə 1200 GPa (566 ilə 1050 mm Hg arasında) təşkil edir.
4. Soyutma havasının temperaturu:
   dayanacaqda - 27 ºС-dən çox olmayan, texniki bloklar üçün - 29 ºС-dən çox olmayan,
   uçuşda - 25 ºС-dən çox deyil, texniki bloklar üçün - 27 ºС-dən çox olmamalıdır.
5. Soyuducu hava axını:
   park edərkən - ən azı 708 kq/saat,
   uçuşda - 660 kq/saatdan az olmamalıdır.
6. Alət bölmələrində havanın temperaturu 60 ºС-dən çox deyil.
7. Soyuducu havada incə sərbəst nəmin miqdarı quru havanın 2 q/kq-dan çox deyil.

Bu məhdud tələblər dəsti daxilində belə, sistemdə fərqli şəkildə idarə edilməli olan ən azı iki kateqoriya var:

• sistemin iş şəraitinə dair tələblər (1-3-cü bəndlər);
• sistem üçün parametrik tələblər (3-7-ci bəndlər).

Sistemin iş şəraiti tələbləri
Modelləşdirmə zamanı işlənən sistem üçün xarici şərtlər sərhəd şərtləri kimi və ya ümumi sistemin işləməsi nəticəsində göstərilə bilər.
Dinamik simulyasiyada müəyyən edilmiş iş şəraitinin simulyasiya prosesi ilə əhatə olunmasını təmin etmək lazımdır.

Parametrik sistem tələbləri
Bu tələblər sistemin özü tərəfindən təmin edilən parametrlərdir. Modelləşdirmə prosesi zamanı biz bu parametrləri hesablama nəticələri kimi əldə edə və hər bir konkret hesablamada tələblərin yerinə yetirildiyinə əmin ola bilərik.

Tələblərin identifikasiyası və kodlaşdırılması

Tələblərlə işləmək asanlığı üçün mövcud standartlar hər bir tələbə identifikator təyin etməyi tövsiyə edir. İdentifikatorları təyin edərkən, vahid kodlaşdırma sistemindən istifadə etmək çox arzu edilir.

Tələb kodu sadəcə tələbin sifariş nömrəsini əks etdirən rəqəm ola bilər və ya tələbin növü üçün kod, onun tətbiq olunduğu sistem və ya vahid üçün kod, parametr kodu, yer kodu və mühəndisin təsəvvür edə biləcəyi başqa hər şey. (kodlaşdırmanın istifadəsi üçün məqaləyə baxın)

Cədvəl 1 tələblərin kodlaşdırılmasının sadə nümunəsini təqdim edir.

1. tələblər mənbəyinin kodu R-tələblər TK;
2. tələblərin kodu növü E - tələblər - ətraf mühit parametrləri və ya iş şəraiti
   S - sistem tərəfindən verilən tələblər;
3. hava gəmisinin status kodu 0 – hər hansı, G – park edilmiş, F – uçuşda;
4. fiziki parametr tip kodu T – temperatur, P – təzyiq, G – axın sürəti, rütubət H;
5. tələbin seriya nömrəsi.

ID Tələblər	Təsvir	Parametr
REGT01	Su soyutma sisteminin girişində ətraf mühitin temperaturu: dayanacaqda - mənfi 35ºС-dən. 35 ºС-ə qədər.
REFT01	Hava hücumundan müdafiə sisteminin girişində atmosfer havasının temperaturu: uçuş zamanı - mənfi 35 ºС-dən 39 ºС-ə qədər.
REFP01	Uçuş zamanı statik atmosfer təzyiqi 700 ilə 1013 hPa (526 ilə 760 mm Hg arasında) təşkil edir.
REFP02	Uçuş zamanı SVO hava qəbulunun girişindəki ümumi hava təzyiqi 754 ilə 1200 hPa (566 ilə 1050 mm Hg) arasındadır.
RSGT01	Soyutma havasının temperaturu: park edildikdə 27 ºС-dən çox deyil
RSGT02	Soyutma havasının temperaturu: dayanacaqda, texniki bölmələr üçün 29 ºС-dən çox olmayan
RSFT01	Uçuş zamanı soyuducu havanın temperaturu 25 ºС-dən çox olmamalıdır
RSFT02	Soyutma havasının temperaturu: uçuş zamanı, texniki bölmələr üçün 27 ºС-dən çox olmayan
RSGG01	Soyuducu hava axını: park edildikdə 708 kq/saatdan az olmamalıdır
RSFG01	Soyuducu hava axını: uçuş zamanı 660 kq/saatdan az olmamalıdır
RS0T01	Alət bölmələrində havanın temperaturu 60 ºС-dən çox olmamalıdır
RSH01	Soyuducu havada incə sərbəst nəmin miqdarı quru havanın 2 q/kq-dan çox deyil

Tələblərin yoxlanılması sisteminin dizaynı.

Hər bir dizayn tələbi üçün dizayn parametrlərinin və tələbdə göstərilən parametrlərin uyğunluğunu qiymətləndirmək üçün bir alqoritm var. Ümumiyyətlə, hər hansı bir idarəetmə sistemi həmişə standart olaraq tələbləri yoxlamaq üçün alqoritmləri ehtiva edir. Və hətta hər hansı bir tənzimləyici onları ehtiva edir. Temperatur həddindən artıq olarsa, kondisioner işə düşür. Beləliklə, istənilən tənzimləmənin birinci mərhələsi parametrlərin tələblərə cavab verib-vermədiyini yoxlamaqdır.

Doğrulama bir alqoritm olduğundan, biz nəzarət proqramları yaratmaq üçün istifadə etdiyimiz eyni alətlərdən və alətlərdən istifadə edə bilərik. Məsələn, SimInTech mühiti ayrı-ayrı layihələr (obyekt modeli, idarəetmə sistemi modeli, ətraf mühit modeli və s.) şəklində icra edilən modelin müxtəlif hissələrini ehtiva edən layihə paketlərini yaratmağa imkan verir.

Bu halda tələblərin yoxlanılması layihəsi eyni alqoritm layihəsinə çevrilir və model paketinə qoşulur. Dinamik modelləşdirmə rejimində isə texniki spesifikasiyaların tələblərinə uyğunluğunun təhlilini həyata keçirir.

Sistem dizaynının mümkün nümunəsi Şəkil 1-də göstərilmişdir.

Şəkil 1. Doğrulama layihəsinin dizayn nümunəsi.

Nəzarət alqoritmlərində olduğu kimi, tələblər də vərəqlər dəsti kimi tərtib edilə bilər. SimInTech, Simulink, AmeSim kimi struktur modelləşdirmə mühitlərində alqoritmlərlə işləməyin rahatlığı üçün submodellər şəklində çoxsəviyyəli strukturların yaradılması imkanından istifadə edilir. Bu təşkilat, nəzarət alqoritmləri üçün olduğu kimi, bir sıra tələblərlə işi sadələşdirmək üçün müxtəlif tələbləri dəstlərdə qruplaşdırmağa imkan verir (bax. Şəkil 2).

Şəkil 2. Tələblərin yoxlanılması modelinin iyerarxik strukturu.

Məsələn, baxılan halda iki qrup fərqləndirilir: ətraf mühitə olan tələblər və birbaşa sistemə olan tələblər. Buna görə də, iki səviyyəli məlumat strukturundan istifadə olunur: hər biri alqoritmin bir yarpağı olan iki qrup.

Məlumatları modelə qoşmaq üçün layihənin hissələri arasında mübadilə üçün məlumatları saxlayan siqnal verilənlər bazası yaratmaq üçün standart sxem istifadə olunur.

Proqram təminatının yaradılması və sınaqdan keçirilməsi zamanı idarəetmə sistemi tərəfindən istifadə olunan sensorların oxunuşları (real sistem sensorlarının analoqları) bu verilənlər bazasına yerləşdirilir.
Test layihəsi üçün dinamik modeldə hesablanmış istənilən parametrlər eyni verilənlər bazasında saxlanıla bilər və bununla da tələblərin yerinə yetirilib-yetirilmədiyini yoxlamaq üçün istifadə edilə bilər.

Bu halda dinamik modelin özü istənilən riyazi modelləşdirmə sistemində və ya hətta icra olunan proqram şəklində icra oluna bilər. Yeganə tələb xarici mühitə modelləşdirmə məlumatlarının verilməsi üçün proqram interfeyslərinin olmasıdır.

Şəkil 3. Doğrulama layihəsinin kompleks modelə qoşulması.

Əsas tələblərin yoxlanılması vərəqinin nümunəsi Şəkil 4-də təqdim olunur. Tərtibatçının nöqteyi-nəzərindən bu, tələblərin yoxlanılması alqoritminin qrafik şəkildə təqdim olunduğu şərti hesablama diaqramıdır.

Şəkil 4. Tələblərin yoxlanılması vərəqi.

Yoxlama vərəqinin əsas hissələri Şəkil 5-də təsvir edilmişdir. Yoxlama alqoritmi nəzarət alqoritmlərinin dizayn diaqramlarına bənzər şəkildə qurulmuşdur. Sağ tərəfdə verilənlər bazasından siqnalları oxumaq üçün blok var. Bu blok simulyasiya zamanı siqnal bazasına daxil olur.

Tələblərin yoxlanılması şərtlərini hesablamaq üçün qəbul edilən siqnallar təhlil edilir. Bu halda, təyyarənin mövqeyini (parkda və ya uçuşda) müəyyən etmək üçün yüksəklik təhlili aparılır. Bu məqsədlə modelin digər siqnallarından və hesablanmış parametrlərindən istifadə edə bilərsiniz.

Yoxlanılan yoxlama şərtləri və parametrləri standart yoxlama bloklarına köçürülür, burada bu parametrlərin müəyyən edilmiş tələblərə uyğunluğu təhlil edilir. Nəticələr siqnal bazasında elə qeyd olunur ki, onlardan avtomatik olaraq yoxlama siyahısı yaratmaq üçün istifadə olunsun.

Şəkil 5. Tələblərin yoxlanılması hesablama vərəqinin strukturu.

Sınaq ediləcək parametrlər verilənlər bazasında olan və simulyasiya prosesi zamanı hesablanmış parametrlərlə idarə olunan siqnallardan mütləq istifadə etmir. Biz yoxlama şərtlərini hesabladığımız kimi, layihə tələbləri çərçivəsində əlavə hesablamalar aparmağa heç nə mane olmur.

Məsələn, bu tələb:

Hədəfə uçuş zamanı korreksiya sisteminin işə salınmalarının sayı 5-dən, korreksiya sisteminin ümumi işləmə müddəti isə 30 saniyədən çox olmamalıdır.

Bu halda, tələblərin dizayn diaqramına başlanğıcların sayına və ümumi iş vaxtına qarşı mübarizə alqoritmi əlavə olunur.

Tipik tələblərin yoxlanılması bloku.

Hər bir standart tələb onay qutusu müəyyən bir növ tələbin yerinə yetirilməsini hesablamaq üçün nəzərdə tutulmuşdur. Məsələn, ekoloji tələblərə park edildikdə və uçuş zamanı ətraf mühitin işləmə temperaturları daxildir. Bu blok modeldə havanın temperaturunu parametr kimi qəbul etməli və bu parametrin göstərilən temperatur diapazonunu əhatə edib-etmədiyini müəyyən etməlidir./p>

Blokda iki giriş portu var, param və şərt.

Birincisi yoxlanılan parametrlə qidalanır. Bu vəziyyətdə "Xarici temperatur".

Boolean dəyişəni ikinci porta verilir - çekin yerinə yetirilməsi üçün şərt.

Əgər ikinci girişdə TRUE (1) alınarsa, o zaman blok tələbin yoxlanılması hesablamasını həyata keçirir.

İkinci giriş YANLIŞ (0) alırsa, test şərtlərinə əməl edilmir. Bu, hesablama şərtlərinin nəzərə alınması üçün lazımdır. Bizim vəziyyətimizdə, bu giriş modelin vəziyyətindən asılı olaraq çeki aktivləşdirmək və ya söndürmək üçün istifadə olunur. Əgər simulyasiya zamanı hava gəmisi yerdədirsə, onda uçuşla bağlı tələblər yoxlanılmır və əksinə - hava gəmisi uçuşdadırsa, dayanacaqda işləmə ilə bağlı tələblər yoxlanılmır.

Bu giriş modeli qurarkən, məsələn hesablamanın ilkin mərhələsində də istifadə edilə bilər. Model tələb olunan vəziyyətə gətirildikdə, yoxlama blokları söndürülür, lakin sistem tələb olunan iş rejiminə çatan kimi yoxlama blokları işə salınır.

Bu blokun parametrləri:

• sərhəd şərtləri: yoxlanılmalı olan yuxarı (UpLimit) və aşağı (Aşağı Limit) diapazon hədləri;
• sərhəd diapazonlarında tələb olunan sistem məruz qalma müddəti (TimeInterval) saniyələrlə;
• Sorğu ID ReqName;
• diapazonu aşma icazəsi Out_aralıq yoxlanılan diapazonu aşan dəyərin tələbin pozulması olub-olmadığını müəyyən edən Boolean dəyişənidir.

Bəzi hallarda, test dəyərinin çıxışı sistemin müəyyən marjaya malik olduğunu və onun işləmə diapazonundan kənarda işlədiyini göstərir. Digər hallarda, çıxış sistemin təyin olunmuş nöqtələri diapazonda saxlaya bilməməsi deməkdir.

Şəkil 6. Diaqramda tipik xüsusiyyət yoxlama bloku və onun parametrləri.

Bu blokun hesablanması nəticəsində çıxışda aşağıdakı dəyərləri alan Nəticə dəyişəni formalaşır:

• 0 – rNone, dəyər müəyyən edilməyib;
• 1 – rTamamlandı, tələb yerinə yetirildi;
• 2 – rFault, tələb yerinə yetirilmir.

Blok şəklinə aşağıdakılar daxildir:

• identifikator mətni;
• ölçmə limitləri parametrlərinin rəqəmsal displeyləri;
• parametr statusunun rəng identifikatoru.

Blokun içərisində kifayət qədər mürəkkəb məntiqi nəticə dövrəsi ola bilər.

Məsələn, Şəkil 6-da göstərilən qurğunun işləmə temperaturu diapazonunu yoxlamaq üçün daxili dövrə Şəkil 7-də göstərilmişdir.

Şəkil 7. Temperatur diapazonunun təyini bölməsinin daxili diaqramı.

Dövrə blokunun içərisində blok parametrlərində göstərilən xüsusiyyətlərdən istifadə olunur.
Tələblərə uyğunluğu təhlil etməklə yanaşı, blokun daxili diaqramı simulyasiya nəticələrini göstərmək üçün lazım olan qrafiki ehtiva edir. Bu qrafikdən həm hesablama zamanı baxmaq, həm də hesablamadan sonra nəticələri təhlil etmək üçün istifadə etmək olar.

Hesablama nəticələri blokun çıxışına ötürülür və eyni zamanda bütün layihə üzrə nəticələr əsasında yaradılan ümumi hesabat faylında qeyd olunur. (şək. 8-ə baxın)

Simulyasiya nəticələrinə əsasən yaradılmış hesabata nümunə verilmiş formata uyğun yaradılmış html faylıdır. Format müəyyən bir təşkilat tərəfindən qəbul edilən formata özbaşına konfiqurasiya edilə bilər.

Dövrə blokunun içərisində blok parametrlərində göstərilən xüsusiyyətlərdən istifadə olunur.
Tələblərə uyğunluğu təhlil etməklə yanaşı, blokun daxili diaqramı simulyasiya nəticələrini göstərmək üçün lazım olan qrafiki ehtiva edir. Bu qrafikdən həm hesablama zamanı baxmaq, həm də hesablamadan sonra nəticələri təhlil etmək üçün istifadə etmək olar.

Hesablama nəticələri blokun çıxışına ötürülür və eyni zamanda bütün layihə üzrə nəticələr əsasında yaradılan ümumi hesabat faylında qeyd olunur. (şək. 8-ə baxın)

Simulyasiya nəticələrinə əsasən yaradılmış hesabata nümunə verilmiş formata uyğun yaradılmış html faylıdır. Format müəyyən bir təşkilat tərəfindən qəbul edilən formata özbaşına konfiqurasiya edilə bilər.

Şəkil 8. Simulyasiya nəticələrinə əsaslanan hesabat faylının nümunəsi.

Bu nümunədə hesabat forması birbaşa layihə xüsusiyyətlərində konfiqurasiya edilir və cədvəldəki format qlobal layihə siqnalları kimi təyin olunur. Bu halda SimInTech özü hesabatın qurulması problemini həll edir və nəticələrin fayla yazılması bloku hesabat faylına yazmaq üçün bu sətirlərdən istifadə edir.

Şəkil 9. Qlobal layihə siqnallarında hesabat formatının qurulması

Tələblər üçün siqnal verilənlər bazasından istifadə.

Mülk parametrləri ilə işi avtomatlaşdırmaq üçün hər bir tipik blok üçün siqnal bazasında standart struktur yaradılır. (şək. 10-a baxın)

Şəkil 10. Siqnal bazasında tələblərin yoxlanılması blokunun strukturunun nümunəsi.

Siqnal bazası təmin edir:

• Bütün lazımi sistem tələbləri parametrlərinin saxlanması.
• Müəyyən edilmiş parametrlərdən və cari modelləşdirmə nəticələrindən mövcud layihə tələblərinə rahat baxmaq.
• Skript proqramlaşdırma dilindən istifadə edərək bir blok və ya bloklar qrupunun qurulması. Siqnal verilənlər bazasındakı dəyişikliklər diaqramdakı blok xassə dəyərlərinin dəyişməsinə səbəb olur.
• Mətn təsvirlərinin, texniki spesifikasiyalar elementlərinə və ya identifikatorlara keçidlərin tələblərin idarə edilməsi sistemində saxlanması.

Tələblər üçün siqnal verilənlər bazası strukturları asanlıqla üçüncü tərəfin tələblərin idarə edilməsi sistemi ilə işləmək üçün konfiqurasiya edilə bilər.Tələblərin idarə edilməsi sistemləri ilə qarşılıqlı əlaqənin ümumi diaqramı Şəkil 11-də təqdim olunur.

Şəkil 11. Tələblərin idarəetmə sistemi ilə qarşılıqlı əlaqə diaqramı.

SimInTech test layihəsi ilə tələblərə nəzarət sistemi arasında qarşılıqlı əlaqənin ardıcıllığı aşağıdakı kimidir:

1. Texniki tapşırıqlar tələblərə bölünür.
2. Texniki şərtlərin tələbləri texniki proseslərin riyazi modelləşdirilməsi ilə yoxlanıla bilən müəyyən edilir.
3. Seçilmiş tələblərin atributları SimInTech siqnal bazasına standart blokların strukturunda (məsələn, maksimum və minimum temperatur) ötürülür.
4. Hesablama prosesi zamanı struktur məlumatları blok dizayn diaqramlarına ötürülür, təhlil aparılır və nəticələr siqnal bazasında saxlanılır.
5. Hesablama başa çatdıqdan sonra təhlil nəticələri tələblərin idarə edilməsi sisteminə ötürülür.

Dizayn və/və ya tələblərdə dəyişikliklər baş verdikdə və dəyişikliklərin təsirini yenidən yoxlamaq lazım olduqda, 3-dən 5-ə qədər olan tələblər layihələndirmə prosesi zamanı təkrarlana bilər.

Nəticələr.

• Sistemin yaradılmış prototipi texniki şərtlərin tələblərinə uyğunluğu üçün mövcud modellərin təhlili vaxtının əhəmiyyətli dərəcədə azaldılmasını təmin edir.
• Təklif olunan sınaq texnologiyası artıq mövcud dinamik modellərdən istifadə edir və hətta SimInTech mühitində yerinə yetirilməyənlər də daxil olmaqla istənilən dinamik modellər üçün istifadə oluna bilər.
• Toplu məlumatların təşkilindən istifadə, modelin inkişafı ilə paralel olaraq tələblərin yoxlanılması paketlərini yaratmağa və ya hətta bu paketləri modelin inkişafı üçün texniki spesifikasiyalar kimi istifadə etməyə imkan verir.
• Texnologiya əhəmiyyətli xərclər olmadan mövcud tələblərin idarə edilməsi sistemləri ilə inteqrasiya oluna bilər.

Sona qədər oxuyanlar üçün prototipin necə işlədiyini göstərən videoya keçid.

Mənbə: www.habr.com