Verifikasi otomatis tina syarat spésifikasi téknis salami modél dinamis

Nuluykeun téma "Naon bukti anjeun?", hayu urang nempo masalah modeling matematik ti sisi séjén. Saatos kami yakin yén modél éta cocog sareng kabeneran kahirupan anu asli, urang tiasa ngajawab patarosan utama: "Naon, persis, anu urang gaduh di dieu?" Nalika nyieun modél obyék téknis, biasana urang hoyong mastikeun yén obyék ieu bakal nyumponan ekspektasi urang. Pikeun tujuan ieu, itungan dinamis prosés dilaksanakeun sareng hasilna dibandingkeun sareng sarat. Ieu kembar digital, prototipe virtual, jsb. guys saeutik fashionable anu, dina tahap desain, ngajawab masalah kumaha carana mastikeun yén urang meunang naon urang rencanana.

Kumaha urang tiasa gancang mastikeun yén sistem urang persis naon urang ngarancang, bakal design urang ngapung atawa ngambang? Tur upami flies, sabaraha luhur? Sareng upami ngambang, kumaha jerona?

Tulisan ieu ngabahas otomatisasi verifikasi patuh kana sarat wangunan téknis nalika nyiptakeun modél dinamis sistem téknis. Salaku conto, hayu urang tingali unsur spésifikasi téknis pikeun sistem pendingin hawa pesawat.

Kami nganggap sarat anu tiasa dikedalkeun sacara numerik sareng diverifikasi sacara matematis dumasar kana modél itungan khusus. Ieu jelas yén ieu téh ngan bagian tina sarat umum pikeun sagala sistem teknis, tapi dina mariksa aranjeunna urang méakkeun waktu, saraf jeung duit dina nyieun model dinamis objék.

Nalika ngajéntrékeun syarat téknis dina bentuk dokumén, sababaraha jinis sarat anu béda-béda tiasa dibédakeun, masing-masing butuh pendekatan anu béda pikeun formasi verifikasi otomatis pikeun minuhan sarat.

Contona, pertimbangkeun set leutik tapi realistis ieu sarat:

1. Suhu hawa atmosfir di lawang ka sistem perlakuan cai:
   di tempat parkir - tina minus 35 dugi ka 35 ºС,
   dina penerbangan - ti dikurangan 35 dugi ka 39 ºС.
2. Tekanan statik hawa atmosfir dina hiber nyaéta ti 700 nepi ka 1013 GPa (tina 526 nepi ka 760 mm Hg).
3. Tekanan hawa total dina lawang asupan hawa SVO dina penerbangan nyaéta ti 754 dugi ka 1200 GPa (tina 566 dugi ka 1050 mm Hg).
4. Suhu hawa cooling:
   di tempat parkir - henteu langkung ti 27 ºС, pikeun blok téknis - henteu langkung ti 29 ºС,
   dina penerbangan - henteu langkung ti 25 ºС, pikeun blok téknis - henteu langkung ti 27 ºС.
5. Aliran hawa cooling:
   nalika diparkir - sahenteuna 708 kg / jam,
   dina hiber - teu kurang ti 660 kg / h.
6. Suhu hawa dina kompartemen alat henteu langkung ti 60 ºС.
7. Jumlah Uap bébas rupa dina hawa cooling teu leuwih ti 2 g/kg hawa garing.

Malah dina set sarat kawates ieu, sahenteuna aya dua kategori anu kedah diurus sacara béda dina sistem:

• syarat pikeun kaayaan operasi sistem (klausa 1-3);
• syarat paramétrik pikeun sistem (klausa 3-7).

Syarat kaayaan operasi sistem
Kaayaan éksternal pikeun sistem anu dikembangkeun nalika modél tiasa dispésikeun salaku kaayaan wates atanapi salaku hasil tina operasi sistem umum.
Dina simulasi dinamis, perlu pikeun mastikeun yén kaayaan operasi husus katutupan ku prosés simulasi.

Syarat sistem paramétrik
Syarat ieu mangrupikeun parameter anu disayogikeun ku sistem sorangan. Salila prosés modeling, urang bisa ménta parameter ieu salaku hasil itungan jeung pastikeun yén sarat anu patepung dina unggal itungan husus.

Idéntifikasi syarat sareng coding

Pikeun ngagampangkeun ngerjakeun sarat, standar anu aya nyarankeun masihan idéntifikasi pikeun unggal sarat. Nalika nangtukeun identifiers, éta kacida desirable ngagunakeun sistem coding hasil ngahijikeun Tatar.

Kode sarat tiasa ngan saukur angka anu ngagambarkeun nomer urutan sarat, atanapi tiasa ngandung kode pikeun jinis sarat, kode pikeun sistem atanapi unit anu dianggo, kode parameter, kode lokasi, sareng nanaon sejenna insinyur bisa ngabayangkeun. (tingali artikel pikeun pamakéan encoding)

Méja 1 nyadiakeun conto basajan tina syarat coding.

1. kode sumber sarat R-sarat TK;
2. tipe kode sarat E - syarat - parameter lingkungan, atawa kaayaan operasi
   S - syarat disadiakeun ku sistem;
3. kode status pesawat 0 - sagala, G - diparkir, F - dina hiber;
4. kode tipe parameter fisik T - suhu, P - tekanan, G - laju aliran, kalembaban H;
5. nomer serial sarat.

ID sarat	gambaran	parameter
REGT01	Suhu hawa ambient di lawang ka sistem cooling cai: di tempat parkir - ti minus 35ºС. nepi ka 35ºС.
REFT01	Suhu hawa atmosfir di lawang ka sistem pertahanan hawa: dina hiber - ti minus 35 ºС ka 39 ºС.
REFP01	Tekanan hawa atmosfir statik dina penerbangan nyaéta ti 700 dugi ka 1013 hPa (tina 526 dugi ka 760 mm Hg).
REFP02	Tekanan hawa total dina lawang asupan hawa SVO dina penerbangan nyaéta ti 754 dugi ka 1200 hPa (tina 566 dugi ka 1050 mm Hg).
RSGT01	Suhu hawa cooling: nalika diparkir teu leuwih ti 27 ºС
RSGT02	Suhu hawa cooling: di tempat parkir, pikeun unit téknis teu leuwih ti 29 ºС
RSFT01	Suhu hawa cooling dina hiber henteu leuwih ti 25 ºС
RSFT02	Suhu hawa cooling: dina hiber, pikeun unit téknis teu leuwih ti 27 ºС
RSGG01	Aliran hawa cooling: lamun diparkir teu kurang ti 708 kg / h
RSFG01	Aliran hawa cooling: dina hiber teu kurang ti 660 kg / h
RS0T01	Suhu hawa dina kompartemen alat henteu langkung ti 60 ºС
RSH01	Jumlah Uap bébas rupa dina hawa cooling teu leuwih ti 2 g/kg hawa garing

Desain sistem verifikasi syarat.

Pikeun unggal sarat desain aya hiji algoritma keur assessing susuratan tina parameter desain jeung parameter dieusian dina sarat. Sacara umum, sistem kontrol naon waé salawasna ngandung algoritma pikeun mariksa syarat sacara standar. Sareng régulator naon waé ngandung aranjeunna. Upami hawa kaluar tina wates, AC bakal hurung. Ku kituna, tahap kahiji tina sagala pangaturan nyaéta mariksa naha parameter minuhan sarat.

Sareng saprak verifikasi mangrupikeun algoritma, maka urang tiasa nganggo alat sareng alat anu sami anu kami anggo pikeun nyiptakeun program kontrol. Contona, lingkungan SimInTech ngidinan Anjeun pikeun nyieun bungkusan proyék nu ngandung sagala rupa bagian tina model, dieksekusi dina bentuk proyék misah (model objék, modél sistem kontrol, modél lingkungan, jsb).

Proyék verifikasi syarat dina hal ieu janten proyék algoritma anu sami sareng disambungkeun kana pakét modél. Sareng dina modeu modél dinamis ngalaksanakeun analisa pikeun minuhan sarat tina spésifikasi téknis.

Conto kamungkinan desain sistem dipidangkeun dina Gambar 1.

Gambar 1. Conto desain proyék verifikasi.

Sapertos pikeun algoritma kontrol, syarat tiasa digambar salaku sakumpulan lembar. Pikeun genah gawé bareng algoritma dina lingkungan modeling struktural kayaning SimInTech, Simulink, AmeSim, kamampuhan pikeun nyieun struktur multi-tingkat dina bentuk submodels dipaké. Organisasi ieu ngamungkinkeun pikeun ngagolongkeun rupa-rupa sarat kana set pikeun simplify karya kalawan Asép Sunandar Sunarya sarat, sakumaha anu dipigawé pikeun algoritma kontrol (tingali Gbr. 2).

Gambar 2. Struktur hirarki model verifikasi sarat.

Salaku conto, dina hal anu ditaliti, dua kelompok dibédakeun: syarat pikeun lingkungan sareng syarat langsung pikeun sistem. Ku alatan éta, struktur data dua tingkat dipaké: dua grup, nu masing-masing mangrupakeun daun tina algoritma.

Pikeun nyambungkeun data kana modél, skéma standar pikeun ngahasilkeun database sinyal dianggo, anu nyimpen data pikeun tukeur antara bagian-bagian proyék.

Nalika nyiptakeun sareng nguji parangkat lunak, bacaan sensor (analog sensor sistem nyata) anu dianggo ku sistem kontrol disimpen dina pangkalan data ieu.
Pikeun proyék uji, parameter naon waé anu diitung dina modél dinamis tiasa disimpen dina pangkalan data anu sami sareng ku kituna dianggo pikeun mariksa naha sarat anu dicumponan.

Dina hal ieu, model dinamis sorangan bisa dieksekusi dina sagala sistem modeling matematik atawa malah dina bentuk program laksana. Hiji-hijina sarat nyaéta ayana interfaces software pikeun ngaluarkeun data modeling ka lingkungan éksternal.

Gambar 3. Nyambungkeun proyék verifikasi ka model kompléks.

Conto lambar verifikasi syarat dasar dibere dina Gambar 4. Ti sudut pandang pamekar, éta diagram itungan konvensional dimana algoritma verifikasi syarat dibere grafis.

Gambar 4. Lembar cék sarat.

Bagian utama lembar cek dijelaskeun dina Gambar 5. Algoritma mariksa kabentuk sarua jeung diagram desain algoritma kontrol. Di sisi katuhu aya blok pikeun maca sinyal tina pangkalan data. Blok ieu ngaksés pangkalan data sinyal nalika simulasi.

Sinyal anu ditampi dianalisis pikeun ngitung syarat verifikasi syarat. Dina hal ieu, analisa luhurna dilakukeun pikeun nangtukeun posisi pesawat (naha éta diparkir atanapi di hiber). Pikeun tujuan ieu, anjeun tiasa nganggo sinyal sanés sareng parameter anu diitung tina modél.

Kaayaan verifikasi sareng parameter anu dipariksa ditransferkeun ka blok verifikasi standar, dimana parameter ieu dianalisis pikeun sasuai sareng sarat anu ditangtukeun. Hasilna dirékam dina pangkalan data sinyal ku cara anu tiasa dianggo pikeun otomatis ngahasilkeun daptar pariksa.

Gambar 5. Struktur lembar itungan verifikasi sarat.

Parameter anu bakal diuji henteu kedah nganggo sinyal anu aya dina pangkalan data, anu dikawasa ku parameter anu diitung nalika prosés simulasi. Henteu aya anu ngahalangan kami pikeun ngalaksanakeun itungan tambahan dina kerangka draf syarat, sapertos urang ngitung kaayaan verifikasi.

Contona, sarat ieu:

Jumlah aktivasina sistem koreksi salila hiber ka udagan teu kudu ngaleuwihan 5, sarta total waktu operasi sistem koreksi teu kudu ngaleuwihan 30 detik.

Dina hal ieu, hiji algoritma pikeun countering jumlah dimimitian jeung total waktu operasi ditambahkeun kana diagram desain sarat.

Blok verifikasi syarat has.

Unggal kotak centang sarat standar dirancang pikeun ngitung minuhan sarat tina tipe nu tangtu. Salaku conto, syarat lingkungan kalebet sauntuyan suhu operasi ambien nalika diparkir sareng di hiber. Blok ieu kedah nampi suhu hawa dina modél salaku parameter sareng nangtoskeun naha parameter ieu nyertakeun kisaran suhu anu ditangtukeun./p>

Blok ngandung dua palabuhan input, param sareng kaayaan.

Anu kahiji dipasihan ku parameter anu dipariksa. Dina hal ieu, "Suhu éksternal".

Variabel Boolean disayogikeun ka port kadua - kaayaan pikeun ngalaksanakeun pamariksaan.

Upami BENER (1) ditampi dina input kadua, blok éta ngalakukeun itungan verifikasi syarat.

Upami input kadua nampi PALSU (0), maka kaayaan uji henteu kapendak. Ieu diperlukeun ku kituna kaayaan itungan bisa dicokot kana akun. Dina kasus urang, input ieu dianggo pikeun ngaktipkeun atanapi nganonaktipkeun cek gumantung kana kaayaan modél. Upami pesawat aya dina taneuh salami simulasi, maka sarat anu aya hubunganana sareng penerbangan henteu dipariksa, sareng sabalikna - upami pesawat nuju hiber, maka syarat anu aya hubunganana sareng operasi di stand teu dipariksa.

Input ieu ogé tiasa dianggo nalika nyetél modél, contona dina tahap awal itungan. Nalika modél dibawa kana kaayaan anu diperyogikeun, blok cek ditumpurkeun, tapi pas sistem ngahontal mode operasi anu diperyogikeun, blok cek dihurungkeun.

Parameter tina blok ieu nyaéta:

• kaayaan wates: luhur (UpLimit) jeung handap (DownLimit) wates rentang nu kudu dipariksa;
• waktos paparan sistem diperlukeun dina rentang wates (TimeInterval) dina detik;
• Ménta ID ReqName;
• permissibility ngaleuwihan rentang Out_range mangrupakeun variabel Boolean nu nangtukeun naha nilai ngaleuwihan rentang dipariksa mangrupakeun palanggaran sarat.

Dina sababaraha kasus, kaluaran nilai tés nunjukkeun yén sistem ngagaduhan sababaraha margin sareng tiasa beroperasi di luar jangkauan operasina. Dina kasus séjén, kaluaran ngandung harti yén sistem teu bisa ngajaga setpoints dina rentang.

angka 6. Blok dipariksa sipat has dina diagram jeung parameter na.

Salaku hasil tina itungan blok ieu, variabel Hasil kabentuk dina kaluaran, anu nyandak nilai-nilai ieu:

• 0 - rEuweuh, nilai teu tangtu;
• 1 - rRengse, sarat geus patepung;
• 2 - rFault, sarat teu patepung.

Gambar blok ngandung:

• téks idéntifikasi;
• tampilan digital parameter wates pangukuran;
• identifier warna tina status parameter.

Di jero blok meureun aya sirkuit inferensi logis anu rada kompleks.

Contona, pikeun mariksa rentang suhu operasi unit ditémbongkeun dina Gambar 6, sirkuit internal ditémbongkeun dina Gambar 7.

Gambar 7. Diagram internal tina Unit tekad rentang suhu.

Di jero blok sirkuit, sipat anu ditunjuk dina parameter blok dianggo.
Salian analisa minuhan sarat, diagram internal blok ngandung grafik dipikabutuh pikeun mintonkeun hasil simulasi. Grafik ieu tiasa dianggo pikeun ningali nalika itungan sareng pikeun nganalisis hasil saatos itungan.

Hasil itungan dikirimkeun ka kaluaran blok sareng sakaligus dirékam dina file laporan umum, anu didamel dumasar kana hasil pikeun sakabéh proyék. (tingali Gbr. 8)

Conto laporan dijieun dumasar kana hasil simulasi mangrupa file html dijieun nurutkeun format dibikeun. Formatna tiasa dikonpigurasi sacara wenang kana format anu ditampi ku organisasi anu khusus.

Di jero blok sirkuit, sipat anu ditunjuk dina parameter blok dianggo.
Salian analisa minuhan sarat, diagram internal blok ngandung grafik dipikabutuh pikeun mintonkeun hasil simulasi. Grafik ieu tiasa dianggo pikeun ningali nalika itungan sareng pikeun nganalisis hasil saatos itungan.

Hasil itungan dikirimkeun ka kaluaran blok sareng sakaligus dirékam dina file laporan umum, anu didamel dumasar kana hasil pikeun sakabéh proyék. (tingali Gbr. 8)

Conto laporan dijieun dumasar kana hasil simulasi mangrupa file html dijieun nurutkeun format dibikeun. Formatna tiasa dikonpigurasi sacara wenang kana format anu ditampi ku organisasi anu khusus.

Gambar 8. Conto file laporan dumasar kana hasil simulasi.

Dina conto ieu, formulir laporan geus ngonpigurasi langsung dina sipat proyék, sarta format dina tabél diatur salaku sinyal proyék global. Dina hal ieu, SimInTech sorangan solves masalah nyetel laporan, sarta blok pikeun nulis hasil kana file ngagunakeun garis ieu nulis ka file laporan.

Gambar 9. Nyetél format laporan dina sinyal proyék global

Ngagunakeun database sinyal pikeun sarat.

Pikeun ngajadikeun otomatis gawé kalawan setélan sipat, struktur baku dijieun dina database sinyal pikeun tiap blok has. (tingali Gbr. 10)

Gambar 10. Conto struktur blok cek sarat dina database sinyal.

Database sinyal nyayogikeun:

• Nyimpen sadaya parameter syarat sistem anu diperyogikeun.
• Ningalian anu gampang pikeun syarat proyék anu tos aya tina parameter anu ditangtukeun sareng hasil modél ayeuna.
• Nyetel hiji blok atawa grup blok ngagunakeun basa programming scripting. Parobahan dina database sinyal ngakibatkeun parobahan dina nilai sipat block dina diagram.
• Nyimpen déskripsi téks, tumbu ka item spésifikasi teknis atanapi identifiers dina sistem manajemen syarat.

Struktur pangkalan data sinyal pikeun sarat tiasa gampang dikonpigurasi pikeun dianggo sareng sistem manajemén syarat pihak katilu. Diagram umum interaksi sareng sistem manajemen syarat dipidangkeun dina Gambar 11.

Gambar 11. Diagram interaksi jeung sistem manajemen syarat.

Runtuyan interaksi antara proyék uji SimInTech sareng sistem kontrol sarat nyaéta kieu:

1. Istilah rujukan diwincik kana sarat.
2. Sarat spésifikasi téknis diidentifikasi anu tiasa diverifikasi ku modél matematis prosés téknis.
3. Atribut sarat anu dipilih ditransferkeun ka pangkalan data sinyal SimInTech dina struktur blok standar (contona, suhu maksimum sareng minimum).
4. Salila prosés itungan, data struktur ditransfer pikeun meungpeuk diagram desain, analisis dipigawé sarta hasilna disimpen dina database sinyal.
5. Saatos itungan réngsé, hasil analisa ditransferkeun kana sistem manajemen syarat.

Sarat léngkah 3 nepi ka 5 bisa diulang salila prosés desain nalika parobahan desain jeung / atawa sarat lumangsung sarta dampak parobahan perlu diuji ulang.

Conclusions.

• Prototipe sistem anu diciptakeun nyayogikeun pangurangan anu signifikan dina waktos analisa model anu tos aya pikeun sasuai sareng sarat spésifikasi téknis.
• Téknologi tés anu diusulkeun ngagunakeun modél dinamis anu tos aya sareng tiasa dianggo bahkan pikeun modél dinamis naon waé, kalebet anu henteu dilaksanakeun di lingkungan SimInTech.
• Ngagunakeun organisasi data bets ngidinan Anjeun pikeun nyieun pakét verifikasi syarat sajajar jeung ngembangkeun model, atawa malah make bungkusan ieu salaku spésifikasi teknis pikeun ngembangkeun model.
• Téknologi tiasa diintegrasikeun sareng sistem manajemén syarat anu tos aya tanpa biaya anu signifikan.

Pikeun anu maca nepi ka ahir, link ka video nu mintonkeun kumaha prototipe jalan.

sumber: www.habr.com