Mavzuni davom ettirish , keling, matematik modellashtirish masalasini boshqa tomondan ko'rib chiqamiz. Model hayotning haqiqiy haqiqatiga mos kelishiga amin bo'lganimizdan so'ng, biz asosiy savolga javob berishimiz mumkin: "Bu erda bizda nima bor?" Texnik ob'ektning modelini yaratishda biz odatda ushbu ob'ekt bizning taxminlarimizga mos kelishiga ishonch hosil qilishni xohlaymiz. Buning uchun jarayonlarning dinamik hisob-kitoblari amalga oshiriladi va natija talablar bilan taqqoslanadi. Bu raqamli egizak, virtual prototip va boshqalar. dizayn bosqichida biz rejalashtirgan narsaga erishishimizga qanday ishonch hosil qilish masalasini hal qiladigan moda yigitlari.
Bizning tizimimiz aynan biz loyihalashtirganiga qanday tezda ishonch hosil qilishimiz mumkin, dizaynimiz uchadimi yoki suzadimi? Va agar u uchsa, qanchalik baland? Va agar u suzayotgan bo'lsa, qanchalik chuqur?
Ushbu maqolada texnik tizimlarning dinamik modellarini yaratishda texnik binoning talablariga muvofiqligini tekshirishni avtomatlashtirish muhokama qilinadi. Misol sifatida, keling, samolyot havo sovutish tizimi uchun texnik spetsifikatsiya elementini ko'rib chiqaylik.
Biz ma'lum bir hisoblash modeli asosida raqamli ifodalanishi va matematik tarzda tasdiqlanishi mumkin bo'lgan talablarni ko'rib chiqamiz. Ko'rinib turibdiki, bu har qanday texnik tizimga qo'yiladigan umumiy talablarning faqat bir qismidir, lekin ularni tekshirish uchun biz ob'ektning dinamik modellarini yaratish uchun vaqt, asab va pul sarflaymiz.
Hujjat shaklida texnik talablarni tavsiflashda turli xil talablarning bir nechta turlarini ajratish mumkin, ularning har biri talablarning bajarilishini avtomatik tekshirishni shakllantirish uchun turli yondashuvlarni talab qiladi.
Masalan, ushbu kichik, ammo real talablar to'plamini ko'rib chiqing:
- Suvni tozalash tizimiga kirishda atmosfera havosining harorati:
to'xtash joyida - minus 35 dan 35 ΒΊS gacha,
parvozda - minus 35 dan 39 ΒΊS gacha. - Parvoz paytida atmosfera havosining statik bosimi 700 dan 1013 GPa gacha (526 dan 760 mm Hg gacha).
- Parvoz paytida SVO havo qabul qilish joyiga kirishdagi umumiy havo bosimi 754 dan 1200 GPa gacha (566 dan 1050 mm Hg gacha).
- Sovutish havosining harorati:
to'xtash joyida - 27 ΒΊS dan oshmasligi kerak, texnik bloklar uchun - 29 ΒΊS dan oshmasligi kerak,
parvozda - 25 ΒΊS dan oshmasligi kerak, texnik bloklar uchun - 27 ΒΊS dan oshmasligi kerak. - Sovutish havosi oqimi:
to'xtab turganda - kamida 708 kg / soat,
parvozda - kamida 660 kg / soat. - Asbob bo'limlaridagi havo harorati 60 ΒΊS dan oshmaydi.
- Sovutish havosidagi nozik erkin namlik miqdori quruq havoning 2 g / kg dan ko'p emas.
Ushbu cheklangan talablar to'plamida ham, tizimda boshqacha ko'rib chiqilishi kerak bo'lgan kamida ikkita toifa mavjud:
- tizimning ishlash shartlariga qo'yiladigan talablar (1-3-bandlar);
- tizim uchun parametrik talablar (3-7-bandlar).
Tizimning ishlash shartlariga qo'yiladigan talablar
Modellashtirish jarayonida ishlab chiqilayotgan tizimning tashqi shartlari chegaraviy shartlar sifatida yoki umumiy tizimning ishlashi natijasida ko'rsatilishi mumkin.
Dinamik simulyatsiyada belgilangan ish sharoitlari simulyatsiya jarayoni bilan qoplanishini ta'minlash kerak.
Parametrik tizim talablari
Ushbu talablar tizimning o'zi tomonidan taqdim etilgan parametrlardir. Modellashtirish jarayonida biz ushbu parametrlarni hisoblash natijalari sifatida olishimiz va har bir aniq hisoblashda talablar bajarilishiga ishonch hosil qilishimiz mumkin.
Talablarni aniqlash va kodlash
Talablar bilan ishlash qulayligi uchun mavjud standartlar har bir talabga identifikator belgilashni tavsiya qiladi. Identifikatorlarni tayinlashda yagona kodlash tizimidan foydalanish juda ma'qul.
Talab kodi oddiygina talabning tartib raqamini ifodalovchi raqam bo'lishi mumkin yoki unda talab turi uchun kod, u qo'llaniladigan tizim yoki birlik uchun kod, parametr kodi, joylashuv kodi va muhandis tasavvur qila oladigan boshqa narsa. (kodlashdan foydalanish uchun maqolaga qarang)
1-jadvalda talablarni kodlashning oddiy misoli keltirilgan.
- talablar manbai kodi R-talablar TK;
- talablarning kod turi E - talablar - atrof-muhit parametrlari yoki ish sharoitlari
S - tizim tomonidan taqdim etilgan talablar; - samolyot holati kodi 0 - har qanday, G - to'xtab turgan, F - parvozda;
- jismoniy parametr turi kodi T - harorat, P - bosim, G - oqim tezligi, namlik H;
- talabning seriya raqami.
| ID talablar |
tavsifi | Parametr |
| REGT01 | Suvni sovutish tizimiga kirishda atrof-muhit havosining harorati: to'xtash joyida - minus 35ΒΊS dan. 35 ΒΊS gacha. | |
| REFT01 | Havo mudofaasi tizimiga kirishda atmosfera havosining harorati: parvoz paytida - minus 35 ΒΊS dan 39 ΒΊS gacha. | |
| REFP01 | Parvozdagi statik atmosfera havosi bosimi 700 dan 1013 hPa gacha (526 dan 760 mm Hg gacha). | |
| REFP02 | Parvoz paytida SVO havo qabul qilish joyiga kirishdagi umumiy havo bosimi 754 dan 1200 hPa gacha (566 dan 1050 mm Hg gacha). | |
| RSGT01 | Sovutish havosining harorati: to'xtab turganda 27 ΒΊS dan oshmasligi kerak | |
| RSGT02 | Sovutish havosining harorati: to'xtash joyida, texnik bloklar uchun 29 ΒΊS dan oshmasligi kerak | |
| RSFT01 | Parvozdagi sovutish havosining harorati 25 ΒΊS dan oshmasligi kerak | |
| RSFT02 | Sovutish havosining harorati: parvoz paytida, texnik birliklar uchun 27 ΒΊS dan oshmasligi kerak | |
| RSGG01 | Sovutish havosi oqimi: to'xtab turganda kamida 708 kg / soat | |
| RSFG01 | Sovutish havosining oqimi: parvozda kamida 660 kg / soat | |
| RS0T01 | Asbob bo'linmalarida havo harorati 60 ΒΊS dan oshmaydi | |
| RSH01 | Sovutish havosidagi nozik erkin namlik miqdori quruq havoning 2 g / kg dan ko'p emas |
Talablarni tekshirish tizimini loyihalash.
Har bir dizayn talabi uchun dizayn parametrlari va talabda ko'rsatilgan parametrlarning muvofiqligini baholash algoritmi mavjud. Umuman olganda, har qanday boshqaruv tizimi har doim sukut bo'yicha talablarni tekshirish algoritmlarini o'z ichiga oladi. Va hatto har qanday regulyator ularni o'z ichiga oladi. Agar harorat chegaradan tashqariga chiqsa, konditsioner yoqiladi. Shunday qilib, har qanday tartibga solishning birinchi bosqichi parametrlarning talablarga javob berishini tekshirishdan iborat.
Va tekshirish algoritm bo'lganligi sababli, biz boshqaruv dasturlarini yaratishda foydalanadigan vositalar va vositalardan foydalanishimiz mumkin. Masalan, SimInTech muhiti modelning turli qismlarini o'z ichiga olgan, alohida loyihalar (ob'ekt modeli, boshqaruv tizimi modeli, muhit modeli va boshqalar) ko'rinishida bajariladigan loyiha paketlarini yaratish imkonini beradi.
Talablarni tekshirish loyihasi bu holda bir xil algoritm loyihasiga aylanadi va model paketiga ulanadi. Va dinamik modellashtirish rejimida u texnik shartlar talablariga muvofiqligini tahlil qiladi.
Tizim dizaynining mumkin bo'lgan namunasi 1-rasmda ko'rsatilgan.
Shakl 1. Tekshiruv loyihasini loyihalash misoli.
Boshqaruv algoritmlari kabi, talablar varaqlar to'plami sifatida tuzilishi mumkin. SimInTech, Simulink, AmeSim kabi strukturaviy modellashtirish muhitlarida algoritmlar bilan ishlash qulayligi uchun submodellar ko'rinishida ko'p darajali tuzilmalarni yaratish imkoniyati qo'llaniladi. Ushbu tashkilot boshqaruv algoritmlari uchun qilinganidek, talablar massivi bilan ishlashni soddalashtirish uchun turli talablarni to'plamlarga guruhlash imkonini beradi (2-rasmga qarang).
Shakl 2. Talablarni tekshirish modelining ierarxik tuzilishi.
Masalan, ko'rib chiqilayotgan holatda ikkita guruh ajratiladi: atrof-muhitga qo'yiladigan talablar va to'g'ridan-to'g'ri tizimga qo'yiladigan talablar. Shuning uchun ikki darajali ma'lumotlar strukturasi qo'llaniladi: ikkita guruh, ularning har biri algoritmning bargi.
Ma'lumotlarni modelga ulash uchun loyiha qismlari o'rtasida almashish uchun ma'lumotlarni saqlaydigan signal ma'lumotlar bazasini yaratishning standart sxemasi qo'llaniladi.
Dasturiy ta'minotni yaratish va sinovdan o'tkazishda boshqaruv tizimi tomonidan ishlatiladigan sensorlarning o'qishlari (haqiqiy tizim sensorlarining analoglari) ushbu ma'lumotlar bazasiga joylashtiriladi.
Sinov loyihasi uchun dinamik modelda hisoblangan har qanday parametrlar bir xil ma'lumotlar bazasida saqlanishi mumkin va shu tariqa talablar bajarilganligini tekshirish uchun ishlatilishi mumkin.
Bunday holda, dinamik modelning o'zi har qanday matematik modellashtirish tizimida yoki hatto bajariladigan dastur shaklida ham bajarilishi mumkin. Yagona talab - tashqi muhitga modellashtirish ma'lumotlarini berish uchun dasturiy interfeyslarning mavjudligi.
Shakl 3. Tekshiruv loyihasini murakkab modelga ulash.
Asosiy talablarni tekshirish varaqasiga misol 4-rasmda keltirilgan. Ishlab chiquvchi nuqtai nazaridan bu an'anaviy hisoblash diagrammasi bo'lib, unda talablarni tekshirish algoritmi grafik tarzda taqdim etiladi.
Shakl 4. Talablarni tekshirish varag'i.
Tekshirish varaqasining asosiy qismlari 5-rasmda tasvirlangan. Tekshirish algoritmi boshqaruv algoritmlarini loyihalash sxemalariga o'xshash tarzda tuzilgan. O'ng tomonda ma'lumotlar bazasidan signallarni o'qish uchun blok mavjud. Ushbu blok simulyatsiya paytida signal bazasiga kiradi.
Qabul qilingan signallar talablarni tekshirish shartlarini hisoblash uchun tahlil qilinadi. Bunday holda, samolyotning holatini aniqlash uchun balandlik tahlili o'tkaziladi (u parkda yoki parvozda). Shu maqsadda siz modelning boshqa signallari va hisoblangan parametrlaridan foydalanishingiz mumkin.
Tekshirish shartlari va parametrlari standart tekshirish bloklariga o'tkaziladi, ularda ushbu parametrlar belgilangan talablarga muvofiqligi tahlil qilinadi. Natijalar signallar bazasida avtomatik ravishda nazorat ro'yxatini yaratish uchun ishlatilishi mumkin bo'lgan tarzda qayd etiladi.
Shakl 5. Talablarni tekshirish hisob varag'ining tuzilishi.
Sinov qilinadigan parametrlar ma'lumotlar bazasida mavjud bo'lgan signallardan foydalanishi shart emas, ular simulyatsiya jarayonida hisoblangan parametrlar bilan boshqariladi. Biz tekshirish shartlarini hisoblaganimizdek, loyiha talablari doirasida qo'shimcha hisob-kitoblarni amalga oshirishga hech narsa to'sqinlik qilmaydi.
Masalan, bu talab:
Maqsadga uchish vaqtida tuzatish tizimining faollashuvi soni 5 tadan oshmasligi kerak va tuzatish tizimining umumiy ish vaqti 30 soniyadan oshmasligi kerak.
Bunday holda, talablarning dizayn sxemasiga ishga tushirish soni va umumiy ish vaqtiga qarshi kurashish algoritmi qo'shiladi.
Oddiy talablarni tekshirish bloki.
Har bir standart talabni belgilash katakchasi ma'lum bir turdagi talabning bajarilishini hisoblash uchun mo'ljallangan. Misol uchun, atrof-muhitga qo'yiladigan talablar to'xtash paytida va parvoz paytida atrof-muhitning ish harorati oralig'ini o'z ichiga oladi. Ushbu blok modeldagi havo haroratini parametr sifatida qabul qilishi va ushbu parametr belgilangan harorat oralig'ini qamrab olishini aniqlashi kerak./p>
Blokda ikkita kirish porti, parametr va shart mavjud.
Birinchisi tekshirilayotgan parametr bilan oziqlanadi. Bunday holda, "Tashqi harorat".
Boolean o'zgaruvchisi ikkinchi portga beriladi - tekshirishni amalga oshirish sharti.
Agar ikkinchi kiritishda TRUE (1) qabul qilinsa, u holda blok talabni tekshirish hisobini amalga oshiradi.
Agar ikkinchi kiritish FALSE (0) ni qabul qilsa, u holda sinov shartlari bajarilmaydi. Bu hisoblash shartlarini hisobga olish uchun zarurdir. Bizning holatda, bu kirish modelning holatiga qarab chekni yoqish yoki o'chirish uchun ishlatiladi. Agar simulyatsiya paytida samolyot yerda bo'lsa, u holda parvoz bilan bog'liq talablar tekshirilmaydi va aksincha - agar samolyot parvozda bo'lsa, u holda stendda ishlash bilan bog'liq talablar tekshirilmaydi.
Ushbu kiritish modelni o'rnatishda, masalan, hisoblashning dastlabki bosqichida ham ishlatilishi mumkin. Model kerakli holatga keltirilgach, tekshirish bloklari o'chiriladi, lekin tizim kerakli ish rejimiga etib borishi bilanoq, tekshirish bloklari yoqiladi.
Ushbu blokning parametrlari:
- chegara shartlari: tekshirilishi kerak bo'lgan yuqori (UpLimit) va pastki (DownLimit) diapazon chegaralari;
- sekundlarda chegara diapazonlarida (TimeInterval) talab qilinadigan tizim ta'sir qilish vaqti;
- So'rov identifikatori ReqName;
- diapazondan oshib ketishning ruxsati Out_diapazoni mantiqiy o'zgaruvchi bo'lib, belgilangan diapazondan oshib ketgan qiymat talabning buzilishi yoki yo'qligini aniqlaydi.
Ba'zi hollarda, sinov qiymatining chiqishi tizimning bir oz chegarasi borligini va uning ishlash doirasidan tashqarida ishlashi mumkinligini ko'rsatadi. Boshqa hollarda, chiqish tizim belgilangan nuqtalarni diapazonda ushlab turolmasligini anglatadi.
Shakl 6. Diagramma va uning parametrlaridagi odatiy xususiyatni tekshirish bloki.
Ushbu blokni hisoblash natijasida chiqishda Natija o'zgaruvchisi hosil bo'ladi, u quyidagi qiymatlarni oladi:
- 0 β rNone, qiymat aniqlanmagan;
- 1 β rBajarildi, talab bajarildi;
- 2 β rFault, talab bajarilmagan.
Blok tasviri quyidagilarni o'z ichiga oladi:
- identifikator matni;
- o'lchov chegaralari parametrlarining raqamli displeylari;
- parametr holatining rang identifikatori.
Blokning ichida ancha murakkab mantiqiy xulosa chiqarish sxemasi bo'lishi mumkin.
Masalan, 6-rasmda ko'rsatilgan qurilmaning ish harorati oralig'ini tekshirish uchun ichki sxema 7-rasmda ko'rsatilgan.
Shakl 7. Harorat diapazonini aniqlash birligining ichki diagrammasi.
O'chirish blokining ichida blok parametrlarida ko'rsatilgan xususiyatlar qo'llaniladi.
Blokning ichki diagrammasi talablarga muvofiqligini tahlil qilishdan tashqari, simulyatsiya natijalarini ko'rsatish uchun zarur bo'lgan grafikni o'z ichiga oladi. Ushbu grafikdan hisoblash paytida ko'rish uchun ham, hisob-kitobdan keyin natijalarni tahlil qilish uchun ham foydalanish mumkin.
Hisoblash natijalari blokning chiqishiga uzatiladi va bir vaqtning o'zida butun loyiha bo'yicha natijalar asosida yaratilgan umumiy hisobot faylida qayd etiladi. (8-rasmga qarang)
Simulyatsiya natijalari asosida tuzilgan hisobotga misol sifatida berilgan formatga muvofiq yaratilgan html faylni keltirish mumkin. Format ma'lum bir tashkilot tomonidan qabul qilingan formatga o'zboshimchalik bilan sozlanishi mumkin.
O'chirish blokining ichida blok parametrlarida ko'rsatilgan xususiyatlar qo'llaniladi.
Blokning ichki diagrammasi talablarga muvofiqligini tahlil qilishdan tashqari, simulyatsiya natijalarini ko'rsatish uchun zarur bo'lgan grafikni o'z ichiga oladi. Ushbu grafikdan hisoblash paytida ko'rish uchun ham, hisob-kitobdan keyin natijalarni tahlil qilish uchun ham foydalanish mumkin.
Hisoblash natijalari blokning chiqishiga uzatiladi va bir vaqtning o'zida butun loyiha bo'yicha natijalar asosida yaratilgan umumiy hisobot faylida qayd etiladi. (8-rasmga qarang)
Simulyatsiya natijalari asosida tuzilgan hisobotga misol sifatida berilgan formatga muvofiq yaratilgan html faylni keltirish mumkin. Format ma'lum bir tashkilot tomonidan qabul qilingan formatga o'zboshimchalik bilan sozlanishi mumkin.
Shakl 8. Simulyatsiya natijalariga asoslangan hisobot fayli namunasi.
Ushbu misolda hisobot shakli to'g'ridan-to'g'ri loyiha xususiyatlarida sozlangan va jadvaldagi format global loyiha signallari sifatida o'rnatiladi. Bu holda SimInTech ning o'zi hisobotni sozlash muammosini hal qiladi va natijalarni faylga yozish bloki hisobot fayliga yozish uchun ushbu qatorlardan foydalanadi.
Shakl 9. Global loyiha signallarida hisobot formatini o'rnatish
Talablar uchun signal ma'lumotlar bazasidan foydalanish.
Mulk sozlamalari bilan ishlashni avtomatlashtirish uchun har bir tipik blok uchun signal bazasida standart tuzilma yaratiladi. (10-rasmga qarang)
10-rasm. Signal bazasidagi talablarni tekshirish blokining tuzilishiga misol.
Signal ma'lumotlar bazasi quyidagilarni ta'minlaydi:
- Barcha kerakli tizim talablari parametrlarini saqlash.
- Belgilangan parametrlar va joriy modellashtirish natijalari bo'yicha mavjud loyiha talablarini qulay ko'rish.
- Skript dasturlash tilidan foydalangan holda bitta blok yoki bloklar guruhini o'rnatish. Signal ma'lumotlar bazasidagi o'zgarishlar diagrammadagi blok xususiyati qiymatlarining o'zgarishiga olib keladi.
- Talablarni boshqarish tizimida matnli tavsiflarni, texnik spetsifikatsiyalar elementlariga yoki identifikatorlarga havolalarni saqlash.
Talablar uchun signal ma'lumotlar bazasi tuzilmalari uchinchi tomon talablarini boshqarish tizimi bilan ishlash uchun osongina sozlanishi mumkin.Talablarni boshqarish tizimlari bilan o'zaro aloqaning umumiy diagrammasi 11-rasmda keltirilgan.
Shakl 11. Talablarni boshqarish tizimi bilan o'zaro aloqa diagrammasi.
SimInTech test loyihasi va talablarni boshqarish tizimi o'rtasidagi o'zaro ta'sir ketma-ketligi quyidagicha:
- Texnik topshiriqlar talablarga bo'linadi.
- Texnik jarayonlarni matematik modellashtirish yo'li bilan tasdiqlanishi mumkin bo'lgan texnik shartlar talablari aniqlanadi.
- Tanlangan talablarning atributlari SimInTech signal bazasiga standart bloklar tarkibida (masalan, maksimal va minimal harorat) uzatiladi.
- Hisoblash jarayonida struktura ma'lumotlari blok-konstruktorlik diagrammalariga o'tkaziladi, tahlillar o'tkaziladi va natijalar signallar bazasida saqlanadi.
- Hisoblash tugallangach, tahlil natijalari talablarni boshqarish tizimiga o'tkaziladi.
Talablarning 3 dan 5 gacha bo'lgan bosqichlari dizayn jarayonida va/yoki talablarga o'zgartirishlar kiritilganda va o'zgarishlarning ta'siri qayta tekshirilishi kerak bo'lganda takrorlanishi mumkin.
Natijalar.
- Tizimning yaratilgan prototipi texnik shartlar talablariga muvofiqligi uchun mavjud modellarni tahlil qilish vaqtini sezilarli darajada qisqartirishni ta'minlaydi.
- Taklif etilayotgan sinov texnologiyasi allaqachon mavjud dinamik modellardan foydalanadi va hatto SimInTech muhitida bajarilmaydigan har qanday dinamik modellar uchun ham foydalanish mumkin.
- To'plamli ma'lumotlarni tashkil etishdan foydalanish sizga modelni ishlab chiqish bilan parallel ravishda talablarni tekshirish paketlarini yaratishga yoki hatto ushbu paketlardan modelni ishlab chiqish uchun texnik xususiyatlar sifatida foydalanishga imkon beradi.
- Texnologiyani mavjud talablarni boshqarish tizimlari bilan sezilarli xarajatlarsiz birlashtirish mumkin.
Oxirigacha o'qiganlar uchun
Manba: www.habr.com