Meneruskan tema , mari kita lihat masalah pemodelan matematik dari sisi lain. Selepas kami yakin bahawa model itu sepadan dengan kebenaran kehidupan yang dibuat sendiri, kita boleh menjawab soalan utama: "apa sebenarnya yang kita ada di sini?" Apabila mencipta model objek teknikal, kami biasanya ingin memastikan bahawa objek ini akan memenuhi jangkaan kami. Untuk tujuan ini, pengiraan dinamik proses dijalankan dan hasilnya dibandingkan dengan keperluan. Ini ialah kembar digital, prototaip maya, dsb. lelaki kecil bergaya yang, pada peringkat reka bentuk, menyelesaikan masalah bagaimana untuk memastikan bahawa kita mendapat apa yang kita rancang.
Bagaimanakah kita boleh memastikan sistem kita betul-betul seperti yang kita reka, adakah reka bentuk kita akan terbang atau terapung? Dan jika ia terbang, berapa tinggi? Dan jika ia terapung, berapa dalam?
Artikel ini membincangkan automasi pengesahan pematuhan dengan keperluan bangunan teknikal apabila mencipta model dinamik sistem teknikal. Sebagai contoh, mari kita lihat elemen spesifikasi teknikal untuk sistem penyejukan udara pesawat.
Kami menganggap keperluan tersebut yang boleh dinyatakan secara berangka dan disahkan secara matematik berdasarkan model pengiraan tertentu. Jelas bahawa ini hanyalah sebahagian daripada keperluan umum untuk mana-mana sistem teknikal, tetapi dengan memeriksanya, kami menghabiskan masa, saraf dan wang untuk mencipta model dinamik objek.
Apabila menerangkan keperluan teknikal dalam bentuk dokumen, beberapa jenis keperluan yang berbeza boleh dibezakan, setiap satunya memerlukan pendekatan yang berbeza untuk pembentukan pengesahan automatik pemenuhan keperluan.
Sebagai contoh, pertimbangkan set keperluan kecil tetapi realistik ini:
- Suhu udara atmosfera di pintu masuk ke sistem rawatan air:
di tempat letak kereta - dari tolak 35 hingga 35 ΒΊΠ‘,
dalam penerbangan - dari tolak 35 hingga 39 ΒΊΠ‘. - Tekanan statik udara atmosfera dalam penerbangan adalah dari 700 hingga 1013 GPa (dari 526 hingga 760 mm Hg).
- Jumlah tekanan udara di pintu masuk ke pengambilan udara SVO dalam penerbangan adalah dari 754 hingga 1200 GPa (dari 566 hingga 1050 mm Hg).
- Suhu udara penyejukan:
di tempat letak kereta - tidak lebih daripada 27 ΒΊΠ‘, untuk blok teknikal - tidak lebih daripada 29 ΒΊΠ‘,
dalam penerbangan - tidak lebih daripada 25 ΒΊΠ‘, untuk blok teknikal - tidak lebih daripada 27 ΒΊΠ‘. - Aliran udara penyejukan:
apabila diletakkan - sekurang-kurangnya 708 kg/j,
dalam penerbangan - tidak kurang daripada 660 kg/j. - Suhu udara dalam petak instrumen tidak lebih daripada 60 ΒΊΠ‘.
- Jumlah lembapan bebas halus dalam udara penyejuk adalah tidak lebih daripada 2 g/kg udara kering.
Walaupun dalam set keperluan terhad ini, terdapat sekurang-kurangnya dua kategori yang perlu dikendalikan secara berbeza dalam sistem:
- keperluan untuk keadaan pengendalian sistem (klausa 1-3);
- keperluan parametrik untuk sistem (klausa 3-7).
Keperluan keadaan pengendalian sistem
Keadaan luaran untuk sistem yang dibangunkan semasa pemodelan boleh ditentukan sebagai syarat sempadan atau hasil daripada operasi sistem umum.
Dalam simulasi dinamik, adalah perlu untuk memastikan bahawa keadaan operasi yang ditentukan dilindungi oleh proses simulasi.
Keperluan sistem parametrik
Keperluan ini adalah parameter yang disediakan oleh sistem itu sendiri. Semasa proses pemodelan, kita boleh mendapatkan parameter ini sebagai hasil pengiraan dan memastikan bahawa keperluan dipenuhi dalam setiap pengiraan khusus.
Pengenalpastian keperluan dan pengekodan
Untuk kemudahan bekerja dengan keperluan, piawaian sedia ada mengesyorkan untuk memberikan pengecam kepada setiap keperluan. Apabila menetapkan pengecam, adalah sangat wajar untuk menggunakan sistem pengekodan bersatu.
Kod keperluan boleh menjadi hanya nombor yang mewakili nombor pesanan keperluan, atau ia boleh mengandungi kod untuk jenis keperluan, kod untuk sistem atau unit yang digunakan, kod parameter, kod lokasi dan apa-apa lagi yang boleh dibayangkan oleh seorang jurutera. (lihat artikel untuk penggunaan pengekodan)
Jadual 1 menyediakan contoh mudah pengekodan keperluan.
- kod sumber keperluan R-keperluan TK;
- jenis kod keperluan E - keperluan - parameter persekitaran, atau keadaan operasi
S - keperluan yang disediakan oleh sistem; - kod status pesawat 0 β mana-mana, G β diletakkan, F β dalam penerbangan;
- kod jenis parameter fizikal T β suhu, P β tekanan, G β kadar aliran, kelembapan H;
- nombor siri keperluan.
| ID Keperluan |
ΠΠΏΠΈΡΠ°Π½ΠΈΠ΅ | Parameter |
| REGT01 | Suhu udara ambien di pintu masuk ke sistem penyejukan air: di tempat letak kereta - dari tolak 35ΒΊΠ‘. sehingga 35ΒΊΠ‘. | |
| REFT01 | Suhu udara atmosfera di pintu masuk ke sistem pertahanan udara: dalam penerbangan - dari tolak 35 ΒΊΠ‘ hingga 39 ΒΊΠ‘. | |
| REFP01 | Tekanan udara statik atmosfera dalam penerbangan ialah dari 700 hingga 1013 hPa (dari 526 hingga 760 mm Hg). | |
| REFP02 | Jumlah tekanan udara di pintu masuk ke pengambilan udara SVO dalam penerbangan adalah dari 754 hingga 1200 hPa (dari 566 hingga 1050 mm Hg). | |
| RSGT01 | Suhu udara penyejukan: apabila diletakkan tidak lebih daripada 27 ΒΊΠ‘ | |
| RSGT02 | Suhu udara penyejukan: di tempat letak kereta, untuk unit teknikal tidak lebih daripada 29 ΒΊΠ‘ | |
| RSFT01 | Menyejukkan suhu udara dalam penerbangan tidak lebih daripada 25 ΒΊΠ‘ | |
| RSFT02 | Suhu udara penyejukan: dalam penerbangan, untuk unit teknikal tidak lebih daripada 27 ΒΊΠ‘ | |
| RSGG01 | Aliran udara penyejukan: apabila diletakkan tidak kurang daripada 708 kg/j | |
| RSFG01 | Aliran udara penyejukan: dalam penerbangan tidak kurang daripada 660 kg/j | |
| RS0T01 | Suhu udara dalam petak instrumen tidak lebih daripada 60 ΒΊΠ‘ | |
| RSH01 | Jumlah lembapan bebas halus dalam udara penyejuk adalah tidak lebih daripada 2 g/kg udara kering |
Reka bentuk sistem pengesahan keperluan.
Bagi setiap keperluan reka bentuk terdapat algoritma untuk menilai kesesuaian parameter reka bentuk dan parameter yang dinyatakan dalam keperluan. Pada umumnya, mana-mana sistem kawalan sentiasa mengandungi algoritma untuk menyemak keperluan secara lalai. Malah mana-mana pengawal selia mengandunginya. Jika suhu melebihi had, penghawa dingin akan dihidupkan. Oleh itu, peringkat pertama mana-mana peraturan adalah untuk memeriksa sama ada parameter memenuhi keperluan.
Dan oleh kerana pengesahan ialah algoritma, maka kami boleh menggunakan alat dan alatan yang sama yang kami gunakan untuk mencipta program kawalan. Sebagai contoh, persekitaran SimInTech membolehkan anda mencipta pakej projek yang mengandungi pelbagai bahagian model, dilaksanakan dalam bentuk projek berasingan (model objek, model sistem kawalan, model persekitaran, dll.).
Projek pengesahan keperluan dalam kes ini menjadi projek algoritma yang sama dan disambungkan ke pakej model. Dan dalam mod pemodelan dinamik ia melakukan analisis untuk pematuhan dengan keperluan spesifikasi teknikal.
Contoh reka bentuk sistem yang mungkin ditunjukkan dalam Rajah 1.
Rajah 1. Contoh reka bentuk projek pengesahan.
Sama seperti untuk algoritma kawalan, keperluan boleh disediakan sebagai satu set helaian. Untuk kemudahan bekerja dengan algoritma dalam persekitaran pemodelan struktur seperti SimInTech, Simulink, AmeSim, keupayaan untuk mencipta struktur berbilang peringkat dalam bentuk submodel digunakan. Organisasi ini memungkinkan untuk mengumpulkan pelbagai keperluan ke dalam set untuk memudahkan kerja dengan pelbagai keperluan, seperti yang dilakukan untuk algoritma kawalan (lihat Rajah 2).
Rajah 2. Struktur hierarki model pengesahan keperluan.
Sebagai contoh, dalam kes yang sedang dipertimbangkan, dua kumpulan dibezakan: keperluan untuk persekitaran dan keperluan secara langsung untuk sistem. Oleh itu, struktur data dua peringkat digunakan: dua kumpulan, setiap satunya adalah daun algoritma.
Untuk menyambung data kepada model, skema standard untuk menjana pangkalan data isyarat digunakan, yang menyimpan data untuk pertukaran antara bahagian projek.
Semasa mencipta dan menguji perisian, bacaan penderia (analog penderia sistem sebenar) yang digunakan oleh sistem kawalan diletakkan dalam pangkalan data ini.
Untuk projek ujian, sebarang parameter yang dikira dalam model dinamik boleh disimpan dalam pangkalan data yang sama dan dengan itu digunakan untuk menyemak sama ada keperluan dipenuhi.
Dalam kes ini, model dinamik itu sendiri boleh dilaksanakan dalam mana-mana sistem pemodelan matematik atau bahkan dalam bentuk program boleh laku. Satu-satunya keperluan ialah kehadiran antara muka perisian untuk mengeluarkan data pemodelan kepada persekitaran luaran.
Rajah 3. Menyambung projek pengesahan kepada model kompleks.
Contoh helaian pengesahan keperluan asas dibentangkan dalam Rajah 4. Dari sudut pandangan pembangun, ia adalah gambar rajah pengiraan konvensional di mana algoritma pengesahan keperluan dibentangkan secara grafik.
Rajah 4. Lembaran semakan keperluan.
Bahagian utama helaian semakan diterangkan dalam Rajah 5. Algoritma semakan dibentuk sama seperti gambar rajah reka bentuk algoritma kawalan. Di sebelah kanan terdapat blok untuk membaca isyarat dari pangkalan data. Blok ini mengakses pangkalan data isyarat semasa simulasi.
Isyarat yang diterima dianalisis untuk mengira syarat pengesahan keperluan. Dalam kes ini, analisis ketinggian dilakukan untuk menentukan kedudukan pesawat (sama ada ia diletakkan atau dalam penerbangan). Untuk tujuan ini, anda boleh menggunakan isyarat lain dan parameter model yang dikira.
Syarat pengesahan dan parameter yang disemak dipindahkan ke blok pengesahan standard, di mana parameter ini dianalisis untuk pematuhan dengan keperluan yang ditentukan. Keputusan direkodkan dalam pangkalan data isyarat dengan cara yang boleh digunakan untuk menjana senarai semak secara automatik.
Rajah 5. Struktur lembaran pengiraan pengesahan keperluan.
Parameter yang akan diuji tidak semestinya menggunakan isyarat yang terkandung dalam pangkalan data, yang dikawal oleh parameter yang dikira semasa proses simulasi. Tiada apa-apa yang menghalang kami daripada menjalankan pengiraan tambahan dalam rangka keperluan draf, sama seperti kami mengira syarat pengesahan.
Sebagai contoh, keperluan ini:
Bilangan pengaktifan sistem pembetulan semasa penerbangan ke sasaran tidak boleh melebihi 5, dan jumlah masa operasi sistem pembetulan tidak boleh melebihi 30 saat.
Dalam kes ini, algoritma untuk mengimbangi bilangan permulaan dan jumlah masa operasi ditambah pada rajah reka bentuk keperluan.
Blok pengesahan keperluan biasa.
Setiap kotak semak keperluan standard direka untuk mengira pemenuhan keperluan jenis tertentu. Sebagai contoh, keperluan alam sekitar termasuk julat suhu operasi ambien apabila diletakkan dan dalam penerbangan. Blok ini mesti menerima suhu udara dalam model sebagai parameter dan menentukan sama ada parameter ini meliputi julat suhu yang ditentukan./p>
Blok mengandungi dua port input, param dan keadaan.
Yang pertama diberi makan dengan parameter yang diperiksa. Dalam kes ini, "Suhu luaran".
Pembolehubah Boolean dibekalkan ke port kedua - syarat untuk melakukan semakan.
Jika BENAR (1) diterima pada input kedua, maka blok melakukan pengiraan pengesahan keperluan.
Jika input kedua menerima FALSE (0), maka syarat ujian tidak dipenuhi. Ini perlu supaya syarat pengiraan dapat diambil kira. Dalam kes kami, input ini digunakan untuk mendayakan atau melumpuhkan semakan bergantung pada keadaan model. Jika pesawat berada di darat semasa simulasi, maka keperluan yang berkaitan dengan penerbangan tidak diperiksa, dan sebaliknya - jika pesawat dalam penerbangan, maka keperluan yang berkaitan dengan operasi di tempat berdiri tidak diperiksa.
Input ini juga boleh digunakan semasa menyediakan model, contohnya pada peringkat awal pengiraan. Apabila model dibawa ke keadaan yang diperlukan, blok semakan dilumpuhkan, tetapi sebaik sahaja sistem mencapai mod pengendalian yang diperlukan, blok semakan dihidupkan.
Parameter blok ini ialah:
- syarat sempadan: had julat atas (UpLimit) dan bawah (DownLimit) yang mesti disemak;
- masa pendedahan sistem yang diperlukan pada julat sempadan (TimeInterval) dalam beberapa saat;
- Minta ID ReqName;
- kebolehpercayaan melebihi julat Out_range ialah pembolehubah Boolean yang menentukan sama ada nilai yang melebihi julat yang disemak adalah melanggar keperluan.
Dalam sesetengah kes, output nilai ujian menunjukkan bahawa sistem mempunyai sedikit margin dan mungkin beroperasi di luar julat pengendaliannya. Dalam kes lain, output bermakna sistem tidak dapat mengekalkan titik set dalam julat.
Rajah 6. Blok semakan sifat tipikal dalam rajah dan parameternya.
Hasil daripada pengiraan blok ini, pembolehubah Hasil terbentuk pada output, yang mengambil nilai berikut:
- 0 β rTiada, nilai tidak ditentukan;
- 1 β rSelesai, keperluan dipenuhi;
- 2 - rFault, keperluan tidak dipenuhi.
Imej blok mengandungi:
- teks pengecam;
- paparan digital parameter had pengukuran;
- pengecam warna status parameter.
Di dalam blok mungkin terdapat litar inferens logik yang agak kompleks.
Sebagai contoh, untuk menyemak julat suhu operasi unit yang ditunjukkan dalam Rajah 6, litar dalaman ditunjukkan dalam Rajah 7.
Rajah 7. Gambar rajah dalaman unit penentuan julat suhu.
Di dalam blok litar, sifat yang dinyatakan dalam parameter blok digunakan.
Selain menganalisis pematuhan keperluan, gambar rajah dalaman blok mengandungi graf yang diperlukan untuk memaparkan hasil simulasi. Graf ini boleh digunakan untuk melihat semasa pengiraan dan untuk menganalisis keputusan selepas pengiraan.
Keputusan pengiraan dihantar ke output blok dan pada masa yang sama direkodkan dalam fail laporan umum, yang dibuat berdasarkan keputusan untuk keseluruhan projek. (lihat Rajah 8)
Contoh laporan yang dibuat berdasarkan hasil simulasi ialah fail html yang dibuat mengikut format yang diberikan. Format boleh dikonfigurasikan sewenang-wenangnya kepada format yang diterima oleh organisasi tertentu.
Di dalam blok litar, sifat yang dinyatakan dalam parameter blok digunakan.
Selain menganalisis pematuhan keperluan, gambar rajah dalaman blok mengandungi graf yang diperlukan untuk memaparkan hasil simulasi. Graf ini boleh digunakan untuk melihat semasa pengiraan dan untuk menganalisis keputusan selepas pengiraan.
Keputusan pengiraan dihantar ke output blok dan pada masa yang sama direkodkan dalam fail laporan umum, yang dibuat berdasarkan keputusan untuk keseluruhan projek. (lihat Rajah 8)
Contoh laporan yang dibuat berdasarkan hasil simulasi ialah fail html yang dibuat mengikut format yang diberikan. Format boleh dikonfigurasikan sewenang-wenangnya kepada format yang diterima oleh organisasi tertentu.
Rajah 8. Contoh fail laporan berdasarkan hasil simulasi.
Dalam contoh ini, borang laporan dikonfigurasikan secara langsung dalam sifat projek dan format dalam jadual ditetapkan sebagai isyarat projek global. Dalam kes ini, SimInTech sendiri menyelesaikan masalah menyediakan laporan, dan blok untuk menulis keputusan ke fail menggunakan baris ini untuk menulis ke fail laporan.
Rajah 9. Menetapkan format laporan dalam isyarat projek global
Menggunakan pangkalan data isyarat untuk keperluan.
Untuk mengautomasikan kerja dengan tetapan harta, struktur standard dicipta dalam pangkalan data isyarat untuk setiap blok biasa. (lihat Rajah 10)
Rajah 10. Contoh struktur blok semakan keperluan dalam pangkalan data isyarat.
Pangkalan data isyarat menyediakan:
- Menyimpan semua parameter keperluan sistem yang diperlukan.
- Paparan mudah keperluan projek sedia ada daripada parameter tertentu dan hasil pemodelan semasa.
- Menyediakan satu blok atau sekumpulan blok menggunakan bahasa pengaturcaraan skrip. Perubahan dalam pangkalan data isyarat membawa kepada perubahan dalam nilai harta blok dalam rajah.
- Menyimpan penerangan teks, pautan ke item spesifikasi teknikal atau pengecam dalam sistem pengurusan keperluan.
Struktur pangkalan data isyarat untuk keperluan boleh dikonfigurasikan dengan mudah untuk berfungsi dengan sistem pengurusan keperluan pihak ketiga. Gambar rajah umum interaksi dengan sistem pengurusan keperluan dibentangkan dalam Rajah 11.
Rajah 11. Gambar rajah interaksi dengan sistem pengurusan keperluan.
Urutan interaksi antara projek ujian SimInTech dan sistem kawalan keperluan adalah seperti berikut:
- Terma rujukan dipecahkan kepada keperluan.
- Keperluan spesifikasi teknikal dikenal pasti yang boleh disahkan melalui pemodelan matematik proses teknikal.
- Atribut keperluan yang dipilih dipindahkan ke pangkalan data isyarat SimInTech dalam struktur blok standard (contohnya, suhu maksimum dan minimum).
- Semasa proses pengiraan, data struktur dipindahkan ke gambar rajah reka bentuk blok, analisis dilakukan dan hasilnya disimpan dalam pangkalan data isyarat.
- Setelah pengiraan selesai, keputusan analisis dipindahkan ke sistem pengurusan keperluan.
Keperluan langkah 3 hingga 5 boleh diulang semasa proses reka bentuk apabila perubahan pada reka bentuk dan/atau keperluan berlaku dan kesan perubahan itu perlu diuji semula.
Kesimpulan.
- Prototaip sistem yang dicipta memberikan pengurangan yang ketara dalam masa analisis model sedia ada untuk pematuhan dengan keperluan spesifikasi teknikal.
- Teknologi ujian yang dicadangkan menggunakan model dinamik sedia ada dan boleh digunakan walaupun untuk mana-mana model dinamik, termasuk yang tidak dilakukan dalam persekitaran SimInTech.
- Menggunakan organisasi data kelompok membolehkan anda membuat pakej pengesahan keperluan selari dengan pembangunan model, atau bahkan menggunakan pakej ini sebagai spesifikasi teknikal untuk pembangunan model.
- Teknologi ini boleh disepadukan dengan sistem pengurusan keperluan sedia ada tanpa kos yang besar.
Bagi yang membaca sampai habis,
Sumber: www.habr.com