Melanjutkan tema , mari kita lihat masalah pemodelan matematika dari sisi lain. Setelah kita yakin bahwa model tersebut sesuai dengan kebenaran hidup yang ada di rumah, kita dapat menjawab pertanyaan utama: βapa sebenarnya yang kita miliki di sini?β Saat membuat model suatu objek teknis, biasanya kita ingin memastikan bahwa objek tersebut memenuhi harapan kita. Untuk tujuan ini, perhitungan proses dinamis dilakukan dan hasilnya dibandingkan dengan persyaratan. Ini adalah kembaran digital, prototipe virtual, dll. shnyag modis yang, pada tahap desain, memecahkan masalah bagaimana memastikan bahwa kita mendapatkan apa yang kita rencanakan.
Bagaimana kita dapat dengan cepat memastikan bahwa sistem kita sesuai dengan apa yang kita desain, apakah desain kita akan terbang atau melayang? Dan jika ia terbang, seberapa tinggi? Dan jika terapung, seberapa dalam?
Artikel ini membahas otomatisasi verifikasi kepatuhan terhadap persyaratan bangunan teknis saat membuat model dinamis sistem teknis. Sebagai contoh, mari kita lihat elemen spesifikasi teknis sistem pendingin udara pesawat terbang.
Kami mempertimbangkan persyaratan yang dapat dinyatakan secara numerik dan diverifikasi secara matematis berdasarkan model perhitungan tertentu. Jelas bahwa ini hanya sebagian dari persyaratan umum untuk sistem teknis apa pun, tetapi untuk memeriksanya kita menghabiskan waktu, tenaga, dan uang untuk membuat model dinamis suatu objek.
Ketika menggambarkan persyaratan teknis dalam bentuk dokumen, beberapa jenis persyaratan yang berbeda dapat dibedakan, yang masing-masing memerlukan pendekatan berbeda untuk pembentukan verifikasi otomatis pemenuhan persyaratan.
Misalnya, pertimbangkan serangkaian persyaratan kecil namun realistis ini:
- Suhu udara atmosfer di pintu masuk sistem pengolahan air:
di tempat parkir - dari minus 35 hingga 35 ΒΊΠ‘,
dalam penerbangan - dari minus 35 hingga 39 ΒΊΠ‘. - Tekanan statis udara atmosfer dalam penerbangan adalah 700 hingga 1013 GPa (dari 526 hingga 760 mm Hg).
- Tekanan total udara di pintu masuk asupan udara SVO dalam penerbangan adalah dari 754 hingga 1200 GPa (dari 566 hingga 1050 mm Hg).
- Suhu udara pendingin:
di tempat parkir - tidak lebih dari 27 ΒΊΠ‘, untuk blok teknis - tidak lebih dari 29 ΒΊΠ‘,
dalam penerbangan - tidak lebih dari 25 ΒΊΠ‘, untuk blok teknis - tidak lebih dari 27 ΒΊΠ‘. - Aliran udara pendingin:
saat diparkir - setidaknya 708 kg/jam,
dalam penerbangan - tidak kurang dari 660 kg/jam. - Suhu udara di kompartemen instrumen tidak lebih dari 60 ΒΊΠ‘.
- Jumlah uap air bebas halus di udara pendingin tidak lebih dari 2 g/kg udara kering.
Bahkan dalam rangkaian persyaratan yang terbatas ini, setidaknya ada dua kategori yang perlu ditangani secara berbeda dalam sistem:
- persyaratan kondisi pengoperasian sistem (klausul 1-3);
- persyaratan parametrik untuk sistem (klausul 3-7).
Persyaratan kondisi pengoperasian sistem
Kondisi eksternal dari sistem yang dikembangkan selama pemodelan dapat ditentukan sebagai kondisi batas atau sebagai akibat dari pengoperasian sistem secara umum.
Dalam simulasi dinamis, perlu dipastikan bahwa kondisi operasi yang ditentukan tercakup dalam proses simulasi.
Persyaratan sistem parametrik
Persyaratan ini merupakan parameter yang disediakan oleh sistem itu sendiri. Selama proses pemodelan, kita dapat memperoleh parameter-parameter tersebut sebagai hasil perhitungan dan memastikan bahwa persyaratan terpenuhi dalam setiap perhitungan tertentu.
Identifikasi persyaratan dan pengkodean
Untuk kemudahan bekerja dengan persyaratan, standar yang ada merekomendasikan untuk menetapkan pengidentifikasi untuk setiap persyaratan. Saat menetapkan pengidentifikasi, sangat diinginkan untuk menggunakan sistem pengkodean terpadu.
Kode persyaratan dapat berupa angka sederhana yang mewakili nomor urut persyaratan, atau dapat berisi kode untuk jenis persyaratan, kode untuk sistem atau unit yang menerapkannya, kode parameter, kode lokasi, dan hal lain yang dapat dibayangkan oleh insinyur tersebut. (lihat artikel untuk penggunaan pengkodean)
Tabel 1 memberikan contoh sederhana pengkodean kebutuhan.
- kode sumber persyaratan R-persyaratan TK;
- kode jenis persyaratan E - persyaratan - parameter lingkungan, atau kondisi pengoperasian
S - persyaratan yang disediakan oleh sistem; - kode status pesawat 0 β apa saja, G β parkir, F β dalam penerbangan;
- kode jenis parameter fisik T β suhu, P β tekanan, G β laju aliran, kelembaban H;
- nomor seri persyaratan.
| ID Persyaratan |
ΠΠΏΠΈΡΠ°Π½ΠΈΠ΅ | Parameter |
| REGT01 | Suhu udara sekitar di pintu masuk sistem pendingin air: di tempat parkir - mulai minus 35ΒΊΠ‘. hingga 35 ΒΊΠ‘. | |
| KEMBALI01 | Suhu udara atmosfer di pintu masuk sistem pertahanan udara: dalam penerbangan - dari minus 35 ΒΊΠ‘ hingga 39 ΒΊΠ‘. | |
| REFP01 | Tekanan udara atmosfer statis dalam penerbangan berkisar antara 700 hingga 1013 hPa (dari 526 hingga 760 mm Hg). | |
| REFP02 | Tekanan total udara di pintu masuk asupan udara SVO dalam penerbangan adalah dari 754 hingga 1200 hPa (dari 566 hingga 1050 mm Hg). | |
| RSGT01 | Suhu udara pendingin: saat parkir tidak lebih dari 27 ΒΊΠ‘ | |
| RSGT02 | Suhu udara pendingin: di tempat parkir, untuk unit teknis tidak lebih dari 29 ΒΊΠ‘ | |
| RSFT01 | Suhu udara pendingin dalam penerbangan tidak lebih dari 25 ΒΊΠ‘ | |
| RSFT02 | Suhu udara pendingin: dalam penerbangan, untuk unit teknis tidak lebih dari 27 ΒΊΠ‘ | |
| RSGG01 | Aliran udara pendingin: saat diparkir tidak kurang dari 708 kg/jam | |
| RSFG01 | Aliran udara pendingin: dalam penerbangan tidak kurang dari 660 kg/jam | |
| RS0T01 | Suhu udara di kompartemen instrumen tidak lebih dari 60 ΒΊΠ‘ | |
| RSH01 | Jumlah uap air bebas halus di udara pendingin tidak lebih dari 2 g/kg udara kering |
Desain sistem verifikasi persyaratan.
Untuk setiap persyaratan desain terdapat algoritma untuk menilai kesesuaian parameter desain dan parameter yang ditentukan dalam persyaratan. Pada umumnya, sistem kontrol apa pun selalu berisi algoritma untuk memeriksa persyaratan secara default. Dan bahkan regulator mana pun memuatnya. Jika suhu melampaui batas, AC akan menyala. Oleh karena itu, tahap pertama dari setiap peraturan adalah memeriksa apakah parameternya memenuhi persyaratan.
Dan karena verifikasi adalah sebuah algoritma, maka kita dapat menggunakan alat dan alat yang sama yang kita gunakan untuk membuat program kontrol. Misalnya, lingkungan SimInTech memungkinkan Anda membuat paket proyek yang berisi berbagai bagian model, dijalankan dalam bentuk proyek terpisah (model objek, model sistem kontrol, model lingkungan, dll.).
Proyek verifikasi persyaratan dalam hal ini menjadi proyek algoritma yang sama dan terhubung ke paket model. Dan dalam mode pemodelan dinamis, ia melakukan analisis untuk memenuhi persyaratan spesifikasi teknis.
Contoh yang mungkin dari desain sistem ditunjukkan pada Gambar 1.
Gambar 1. Contoh desain proyek verifikasi.
Sama seperti algoritma kontrol, persyaratan dapat dibuat sebagai satu set lembar. Untuk kenyamanan bekerja dengan algoritma dalam lingkungan pemodelan struktural seperti SimInTech, Simulink, AmeSim, digunakan kemampuan untuk membuat struktur multi-level dalam bentuk submodel. Organisasi ini memungkinkan untuk mengelompokkan berbagai persyaratan ke dalam kumpulan untuk menyederhanakan pekerjaan dengan serangkaian persyaratan, seperti yang dilakukan untuk algoritma kontrol (lihat Gambar 2).
Gambar 2. Struktur hierarki model verifikasi persyaratan.
Misalnya, dalam kasus ini, ada dua kelompok yang dibedakan: persyaratan lingkungan dan persyaratan langsung untuk sistem. Oleh karena itu, struktur data dua tingkat digunakan: dua kelompok, yang masing-masing merupakan bagian dari algoritma.
Untuk menghubungkan data ke model, skema standar untuk menghasilkan database sinyal digunakan, yang menyimpan data untuk pertukaran antar bagian proyek.
Saat membuat dan menguji perangkat lunak, pembacaan sensor (analog dari sensor sistem nyata) yang digunakan oleh sistem kontrol ditempatkan di database ini.
Untuk proyek uji, parameter apa pun yang dihitung dalam model dinamis dapat disimpan dalam database yang sama dan digunakan untuk memeriksa apakah persyaratan terpenuhi.
Dalam hal ini, model dinamis itu sendiri dapat dieksekusi dalam sistem pemodelan matematika apa pun atau bahkan dalam bentuk program yang dapat dieksekusi. Satu-satunya persyaratan adalah adanya antarmuka perangkat lunak untuk mengeluarkan data pemodelan ke lingkungan eksternal.
Gambar 3. Menghubungkan proyek verifikasi ke model kompleks.
Contoh lembar verifikasi persyaratan dasar disajikan pada Gambar 4. Dari sudut pandang pengembang, ini adalah diagram perhitungan konvensional di mana algoritma verifikasi persyaratan disajikan secara grafis.
Gambar 4. Lembar pemeriksaan persyaratan.
Bagian utama dari lembar periksa dijelaskan pada Gambar 5. Algoritma pemeriksaan dibentuk mirip dengan diagram desain algoritma kontrol. Di sisi kanan terdapat blok untuk membaca sinyal dari database. Blok ini mengakses database sinyal selama simulasi.
Sinyal yang diterima dianalisis untuk menghitung kondisi verifikasi persyaratan. Dalam hal ini analisis ketinggian dilakukan untuk mengetahui posisi pesawat (apakah sedang parkir atau sedang terbang). Untuk tujuan ini, Anda dapat menggunakan sinyal lain dan parameter model yang dihitung.
Kondisi verifikasi dan parameter yang diperiksa ditransfer ke blok verifikasi standar, di mana parameter ini dianalisis untuk memenuhi persyaratan yang ditentukan. Hasilnya dicatat dalam database sinyal sedemikian rupa sehingga dapat digunakan untuk menghasilkan daftar periksa secara otomatis.
Gambar 5. Struktur lembar perhitungan verifikasi kebutuhan.
Parameter yang akan diuji tidak serta merta menggunakan sinyal yang terdapat dalam database, melainkan dikontrol oleh parameter yang dihitung selama proses simulasi. Tidak ada yang menghalangi kami untuk melakukan perhitungan tambahan dalam kerangka rancangan persyaratan, seperti halnya kami menghitung kondisi verifikasi.
Misalnya, persyaratan ini:
Jumlah aktivasi sistem koreksi selama penerbangan menuju target tidak boleh melebihi 5, dan total waktu pengoperasian sistem koreksi tidak boleh melebihi 30 detik.
Dalam hal ini, algoritma untuk menghitung jumlah start dan total waktu pengoperasian ditambahkan ke diagram desain persyaratan.
Blok verifikasi persyaratan umum.
Setiap kotak centang persyaratan standar dirancang untuk menghitung pemenuhan suatu jenis persyaratan tertentu. Misalnya, persyaratan lingkungan mencakup kisaran suhu pengoperasian sekitar saat parkir dan dalam penerbangan. Blok ini harus menerima suhu udara dalam model sebagai parameter dan menentukan apakah parameter ini mencakup kisaran suhu yang ditentukan./p>
Blok tersebut berisi dua port input, param dan kondisi.
Yang pertama dimasukkan dengan parameter yang sedang diperiksa. Dalam hal ini, βSuhu eksternalβ.
Variabel Boolean disuplai ke port kedua - kondisi untuk melakukan pemeriksaan.
Jika BENAR (1) diterima pada input kedua, maka blok melakukan perhitungan verifikasi kebutuhan.
Jika input kedua menerima FALSE (0), maka kondisi pengujian tidak terpenuhi. Hal ini diperlukan agar kondisi perhitungan dapat diperhitungkan. Dalam kasus kami, masukan ini digunakan untuk mengaktifkan atau menonaktifkan pemeriksaan bergantung pada status model. Jika pesawat berada di darat selama simulasi, maka persyaratan terkait penerbangan tidak diperiksa, dan sebaliknya - jika pesawat sedang terbang, maka persyaratan terkait pengoperasian di stand tidak diperiksa.
Masukan ini juga dapat digunakan pada saat menyiapkan model, misalnya pada tahap awal penghitungan. Ketika model dibawa ke keadaan yang diperlukan, blok pemeriksaan dinonaktifkan, tetapi segera setelah sistem mencapai mode operasi yang diperlukan, blok pemeriksaan diaktifkan.
Parameter blok ini adalah:
- kondisi batas: batas rentang atas (UpLimit) dan bawah (DownLimit) yang harus diperiksa;
- waktu pemaparan sistem yang diperlukan pada rentang batas (TimeInterval) dalam hitungan detik;
- Permintaan ID NamaPermintaan;
- izin melebihi rentang Out_range adalah variabel Boolean yang menentukan apakah nilai yang melebihi rentang yang dicentang merupakan pelanggaran terhadap persyaratan.
Dalam beberapa kasus, keluaran nilai pengujian menunjukkan bahwa sistem memiliki margin tertentu dan mungkin beroperasi di luar rentang operasinya. Dalam kasus lain, keluaran berarti sistem tidak mampu mempertahankan tekanan yang dikehendaki dalam jangkauan.
Gambar 6. Blok pemeriksaan properti tipikal dalam diagram dan parameternya.
Sebagai hasil perhitungan blok ini, variabel Result terbentuk pada output, yang mengambil nilai berikut:
- 0 β rTidak ada, nilai tidak ditentukan;
- 1 β Selesai, persyaratan terpenuhi;
- 2 β rKesalahan, persyaratan tidak terpenuhi.
Gambar blok berisi:
- teks pengenal;
- tampilan digital parameter batas pengukuran;
- pengidentifikasi warna status parameter.
Di dalam blok mungkin terdapat rangkaian inferensi logis yang agak rumit.
Misalnya, untuk memeriksa kisaran suhu pengoperasian unit yang ditunjukkan pada Gambar 6, rangkaian internal ditunjukkan pada Gambar 7.
Gambar 7. Diagram internal unit penentuan rentang suhu.
Di dalam blok rangkaian, properti yang ditentukan dalam parameter blok digunakan.
Selain menganalisis kepatuhan terhadap persyaratan, diagram internal blok berisi grafik yang diperlukan untuk menampilkan hasil simulasi. Grafik ini dapat digunakan baik untuk melihat selama penghitungan maupun untuk menganalisis hasil setelah penghitungan.
Hasil perhitungan ditransmisikan ke output blok dan sekaligus dicatat dalam file laporan umum, yang dibuat berdasarkan hasil keseluruhan proyek. (lihat Gambar 8)
Contoh laporan yang dibuat berdasarkan hasil simulasi adalah file html yang dibuat sesuai format tertentu. Formatnya dapat dikonfigurasi secara sewenang-wenang ke format yang diterima oleh organisasi tertentu.
Di dalam blok rangkaian, properti yang ditentukan dalam parameter blok digunakan.
Selain menganalisis kepatuhan terhadap persyaratan, diagram internal blok berisi grafik yang diperlukan untuk menampilkan hasil simulasi. Grafik ini dapat digunakan baik untuk melihat selama penghitungan maupun untuk menganalisis hasil setelah penghitungan.
Hasil perhitungan ditransmisikan ke output blok dan sekaligus dicatat dalam file laporan umum, yang dibuat berdasarkan hasil keseluruhan proyek. (lihat Gambar 8)
Contoh laporan yang dibuat berdasarkan hasil simulasi adalah file html yang dibuat sesuai format tertentu. Formatnya dapat dikonfigurasi secara sewenang-wenang ke format yang diterima oleh organisasi tertentu.
Gambar 8. Contoh file laporan berdasarkan hasil simulasi.
Dalam contoh ini, formulir laporan dikonfigurasikan langsung di properti proyek, dan format dalam tabel ditetapkan sebagai sinyal proyek global. Dalam hal ini, SimInTech sendiri memecahkan masalah pengaturan laporan, dan blok untuk menulis hasil ke file menggunakan baris ini untuk menulis ke file laporan.
Gambar 9. Mengatur format laporan dalam sinyal proyek global
Menggunakan database sinyal untuk persyaratan.
Untuk mengotomatisasi pekerjaan dengan pengaturan properti, struktur standar dibuat dalam database sinyal untuk setiap blok tipikal. (lihat Gambar 10)
Gambar 10. Contoh struktur blok pemeriksaan persyaratan dalam database sinyal.
Basis data sinyal menyediakan:
- Menyimpan semua parameter persyaratan sistem yang diperlukan.
- Melihat dengan mudah persyaratan proyek yang ada dari parameter yang ditentukan dan hasil pemodelan saat ini.
- Menyiapkan satu blok atau sekelompok blok menggunakan bahasa pemrograman scripting. Perubahan pada database sinyal menyebabkan perubahan nilai properti blok pada diagram.
- Menyimpan deskripsi teks, tautan ke item spesifikasi teknis atau pengidentifikasi dalam sistem manajemen persyaratan.
Struktur database sinyal untuk persyaratan dapat dengan mudah dikonfigurasi agar berfungsi dengan sistem manajemen persyaratan pihak ketiga.Diagram umum interaksi dengan sistem manajemen persyaratan disajikan pada Gambar 11.
Gambar 11. Diagram interaksi dengan sistem manajemen kebutuhan.
Urutan interaksi antara proyek uji SimInTech dan sistem kendali persyaratan adalah sebagai berikut:
- Kerangka acuan dipecah menjadi persyaratan.
- Persyaratan spesifikasi teknis diidentifikasi yang dapat diverifikasi dengan pemodelan matematis dari proses teknis.
- Atribut persyaratan yang dipilih ditransfer ke database sinyal SimInTech dalam struktur blok standar (misalnya, suhu maksimum dan minimum).
- Selama proses perhitungan, data struktur ditransfer ke diagram desain blok, analisis dilakukan dan hasilnya disimpan dalam database sinyal.
- Setelah perhitungan selesai, hasil analisis ditransfer ke sistem manajemen persyaratan.
Persyaratan langkah 3 sampai 5 dapat diulangi selama proses desain ketika terjadi perubahan pada desain dan/atau persyaratan dan dampak perubahan tersebut perlu diuji ulang.
Kesimpulan.
- Prototipe sistem yang dibuat memberikan pengurangan yang signifikan dalam waktu analisis model yang ada untuk memenuhi persyaratan spesifikasi teknis.
- Teknologi pengujian yang diusulkan menggunakan model dinamis yang sudah ada dan dapat digunakan bahkan untuk model dinamis apa pun, termasuk yang tidak dilakukan di lingkungan SimInTech.
- Menggunakan organisasi data batch memungkinkan Anda membuat paket verifikasi persyaratan secara paralel dengan pengembangan model, atau bahkan menggunakan paket ini sebagai spesifikasi teknis untuk pengembangan model.
- Teknologi ini dapat diintegrasikan dengan sistem manajemen persyaratan yang ada tanpa biaya yang signifikan.
Bagi yang membaca sampai akhir,
Sumber: www.habr.com