Melanjutkan topik OOP dalam bahasa pemrograman grafis, kami akan memeriksa dalam desain berbasis model yang lebih detail. Apa itu model-oriented design (MOS), cara memasaknya dan apa yang harus dimakan.

Ketika menggambarkan desain berorientasi model sistem kontrol, beberapa penulis dalam publikasi mereka mentransmisikan gagasan bahwa kata "model" berarti "model sistem kontrol". Apa yang tidak benar.

Mengapa ini tidak benar, bagaimana melakukannya dengan benar dan di mana Chernobyl, baca terus.

Berikut ini adalah contoh khas - gambar dari artikel oleh penulis yang dihormati tentang "praktik terbaik dalam pengembangan perangkat lunak menggunakan desain berorientasi model":

Gambar 1. Salah satu opsi untuk MOS.

Secara pribadi, melihat gambar ini, pertanyaan tidak senonoh segera muncul, dan dari tempat mana, saya minta maaf, apakah Anda memiliki vektor uji?

Atau, misalnya, gambar untuk rekomendasi dari proses pengembangan perangkat lunak yang khas:

Gambar 2. Versi lain dari proses MOS.

Di mana model dalam gambar ini? Di sini adalah kotak ini dari mana kode sumber diperoleh? Benarkah ?! Jadi ini lagi-lagi model perangkat lunak kontrol.

Terutama menyentuh dalam gambar ini adalah adanya persyaratan perangkat lunak awal.
Contohnya, seperti Anda, yang sangat biasa, hampir seperti buku teks, persyaratan untuk sistem kontrol:

" Ketika tekanan naik di atas nilai batas, waktu tutup (pembukaan) katup pengaman tidak boleh lebih dari 5 detik ."

Dan bagaimana Anda memesan di bawah skema ini untuk memeriksa berapa detik setelah tekanan terlampaui, katup pengaman akan terbuka? Rupanya ada sesuatu yang hilang di sini. Kami beralih ke sumber kebenaran yang tidak ada habisnya di jalan terakhir - Wikipedia:

Desain berbasis model menyediakan pendekatan yang efisien untuk membangun kerangka kerja umum untuk komunikasi selama proses desain sambil mendukung siklus pengembangan (model-V). Dalam desain sistem kontrol berbasis model, pengembangan dimanifestasikan dalam empat langkah berikut:

1. pemodelan tanaman,
2. menganalisis dan mensintesis pengontrol untuk pabrik,
3. mensimulasikan tanaman dan pengontrol,
4. mengintegrasikan semua fase ini dengan menggunakan controller.

Pengembangan model suatu objek adalah titik pertama dalam menentukan MOS. Pertama, model objek, dan kemudian kontrol untuk itu. Dan ini benar: tidak ada model objek, "terima kasih semua - semua orang bebas" dan ini bukan desain yang berorientasi model, tetapi penipuan konsumen yang lengkap.

Mengapa ini penting dan dari mana Chernobyl berasal?

Dalam Chernobyl, apa yang terjadi tanpa adanya model objek terjadi. Ilmuwan Soviet bertanya pada diri sendiri: "Apa yang akan terjadi jika catu daya terputus, dan pompa pendingin reaktor disuplai dengan arus dari generator yang berjalan di turbin yang sedang padam? "Berapa banyak air yang akan dipompakan melalui reaktor sebelum turbin dan generator berhenti?" Yang menarik, mereka mengajukan pertanyaan semacam itu berdasarkan pengalaman kecelakaan di pembangkit listrik tenaga nuklir Amerika, di mana pasokan air tidak cukup untuk pendinginan dan reaktor Amerika meleleh. Dan untuk memastikan bahwa reaktor kami tidak meleleh, kami memutuskan untuk melakukan percobaan. Mungkin jawaban untuk pertanyaan ini akan membuat reaktor RBMK generasi berikutnya lebih aman. Kami menginginkan yang terbaik, tetapi ternyata seperti biasa. Sebagai hasil dari percobaan, reaktor yang aman pertama kali mengarah ke keadaan berbahaya, dan kemudian meledak. Dan reaktor RBMK generasi berikutnya tidak lagi dan tidak diharapkan. Amin

Dan jika, alih-alih bereksperimen pada reaktor, akan mungkin untuk melakukan hal yang sama pada model matematika suatu objek, maka, sangat mungkin, kita sekarang akan membangun RBMK-2400 di seluruh dunia, bukan reaktor VVER-1200.

Setelah kecelakaan Chernobyl di industri nuklir, model objek (reaktor nuklir) adalah bagian wajib dari proyek. Perancang harus menunjukkan pada model apa yang akan terjadi jika terjadi kesalahan. Dan oleh karena itu, perancangan berorientasi model muncul di antara para insinyur nuklir jauh lebih awal daripada di industri lain, karena persyaratan dari badan pengawas.

Tetapi bahkan ketika tidak ada persyaratan dari otoritas pengatur, model objek sangat memudahkan desain sistem kontrol dan objek itu sendiri. Sekarang kami menunjukkan ini dengan contoh dari industri di mana "mimpi menjadi kenyataan".

Pendekatan berorientasi model yang tepat.

Sebagai contoh MOS halal yang benar, pertimbangkan proses pengembangan perangkat lunak kontrol untuk sistem kontrol hidrolik kompleks penambangan bawah air (seperti biasa, benar-benar secara tidak sengaja saya mendapatkan model ini di komputer saya).

Kontrol aliran utama gas yang diproduksi oleh pasokan dilakukan oleh alat kelengkapan bawah air hidrolik. Di pantai ada stasiun pompa, yang memberikan tekanan dalam sistem hidrolik, minyak disuplai melalui umbilical di bawah tekanan di bawah air. Pembukaan dan penutupan katup dilakukan oleh aktuator hidrolik, yang dikendalikan oleh sistem kontrol terdistribusi. Sistem terdiri dari:

• modul kontrol tanah untuk seluruh bidang;
• satu set modul kontrol bawah air (PMU) yang menyediakan kontrol langsung terhadap katup.

Untuk kenyamanan pemasangan dan pemeliharaan, saluran pipa digabungkan menjadi manifold, di mana katup dan modul kontrol yang diperlukan dipasang pada satu platform. Jika di stasiun bumi Anda dapat menggunakan alat SCADA standar, server arsip dan PLC dengan sistem operasi konvensional dan (atau) waktu-nyata, maka modul kontrol bawah air, sebagai suatu peraturan, mikroprosesor non-operasional, kode kontrol yang harus dikembangkan secara terpisah dari perangkat lunak kontrol pantai . (Tidak C ++, hanya C, hanya hardcode) Kemudian beberapa PMU ini harus diintegrasikan ke dalam sistem umum dan diuji. Dan pada saat yang sama, keseluruhan sistem harus bekerja secara keseluruhan dan menyediakan pembukaan dan penutupan katup dalam 30 tahun di bawah air.

Tugas ini diperumit oleh kenyataan bahwa sampai sekarang semua peralatan yang digunakan di rak itu adalah barat, dan rak itu sekarang sedang dikenai sanksi. Dan, oleh karena itu, perlu untuk membuat kompleks di mana banyak solusi teknis baru dan tidak terawat bagi kita. Bagaimana cara mendapatkan hasilnya, mengurangi kesalahan desain jika memungkinkan? Baik untuk pengembang Barat: mereka sudah memiliki pengalaman, mereka tahu tentang jebakan dalam penambangan bawah laut. Dan di sini desain berorientasi model datang untuk membantu pengembang. Alih-alih melakukan eksperimen pada peralatan mahal, seperti ilmuwan nuklir Soviet di Chernobyl, kami membuat model objek dan melakukan eksperimen pada model.

Model terintegrasi dari sistem kontrol bawah air

Untuk desain perangkat lunak, model terintegrasi dibuat dalam bentuk paket yang berisi kedua model aliran fluida hidrolik di bawah air dengan peralatan dan proyek sistem kontrol. (lihat gambar 3)

Gambar 3. Paket model terintegrasi sistem manajemen SPD.

Paket ini berisi proyek - model stasiun hidrolik berbasis darat (file 200.prt pada Gbr. 3), yang menyediakan pemodelan proses dinamis dari peralatan sistem pasokan fluida hidrolik berbasis darat untuk air. (lihat gambar 4)

Gambar 4. Skema desain stasiun hidrolik tanah.

Bersamaan dengan model proses fisik, proyek sistem kontrol sedang dikembangkan yang menyediakan untuk menghidupkan dan mematikan peralatan dan mengendalikan mode operasi peralatan ini. Gambar 5 menunjukkan algoritma kontrol konsep untuk modul kontrol tanah.

Gambar 5. Desain sistem kontrol modul ground.

Pada tahap ini, adalah mungkin untuk membagi pengembangan algoritma kontrol antara tim yang berbeda. Misalnya, untuk pengembang stasiun hidrolik berbasis darat, biaya modul bawah laut dan tekanan di dalamnya adalah kondisi batas. Untuk pengembang peralatan bawah laut, kondisi batas adalah tekanan yang diciptakan oleh stasiun pompa di darat.

Pengembangan modul kontrol bawah air (PMU) dilakukan berdasarkan proyek untuk membagi pipa gas utama di antara manifold. Pertama, sumur terbentuk, perpipaan dan fiting antara sumur dan pantai ditentukan, kemudian sistem kontrol hidrolik untuk katup ini dikembangkan.

Untuk setiap modul bawah laut, model proyek sistem kontrol dan model desain sistem hidrolik manifold dengan katup yang terpasang dibentuk. Pada skema desain sistem hidrolik, katup dipasang, yang dikendalikan dari modul bawah air ini. Desain ini dapat dilakukan secara paralel dengan pengembangan modul kontrol tanah, sedangkan pengembangannya dapat dilakukan secara independen dan paralel. Untuk mengembangkan algoritma PMU dan operasi katup, sistem eksternal ditentukan oleh perintah kontrol dan kondisi batas untuk sistem hidrolik.

Pertimbangkan modul kontrol bawah air (PMU) 502. Dua proyek digunakan di sini:

• 502.prt - model sistem hidrolik (Gbr. 6, 7);
• 502a.prt - proyek sistem kontrol PMU (Gbr. 8).

Gambar 6. Sirkuit hidrolik PMU.

Skema desain ini memberikan simulasi perilaku sistem kontrol hidrolik dan perhitungan laju aliran dan tekanan dalam sistem yang dikendalikan oleh 502 PMU. Sirkuit hidraulik yang dihitung memungkinkan Anda untuk mengatur dampak pada aktuator dan mendapatkan data sensor yang dihitung dalam model proses fisik. Selama kita tidak memiliki stasiun bumi di blok 502 P (sudut kiri bawah Gambar 6), kita dapat mengatur tekanan yang dibuat oleh stasiun pembangkit listrik tenaga air sebagai kondisi batas.

Dalam sistem, gambar menunjukkan 6 katup penutup dan hidraulik hidraulik (ZRA), yang masing-masing secara inheren mewakili silinder hidrolik yang terhubung ke dua saluran tekanan tinggi dan rendah. Kami menerapkan lebih banyak tekanan ke bagian atas silinder, tekanan menggerakkan batang ke bawah, kami menerapkan lebih banyak tekanan ke bagian bawah silinder, batang naik.

Switching dikendalikan oleh katup kontrol yang terletak di dalam blok putih (lihat Gambar 7).

Gambar 7. Blok katup distribusi dalam model.

Prinsip operasi sederhana: tergantung pada posisi katup geser, ruang silinder akan terhubung ke jalur yang berbeda. Pindah spool - mengubah arah gerakan batang di silinder. (detail lebih lanjut tentang pemodelan hidrolik dapat ditemukan di sini ... )

Gambar 8. Desain sistem kontrol PMU.

Perangkat lunak manajemen proyek untuk modul kontrol bawah air berisi beberapa blok perhitungan, yang masing-masing dapat dikembangkan oleh pengembang atau tim yang terpisah. Dalam hal ini, pemisahan menjadi modul terjadi sesuai dengan atribut fungsional, masing-masing blok bertanggung jawab untuk mengontrol jenis katup tertentu. Metodologi pemrograman berorientasi objek diterapkan, di mana bloknya adalah kelas OOP (lebih detail di sini ... dan di sini ... )

Pertimbangkan proses mendesain unit kontrol untuk peralatan mati dan kontrol. Blok di sirkuit ini menerima 4 sinyal input dan menghasilkan 8 sinyal output. (lihat gambar 9)

Gambar 9. Unit kontrol ZRA (Tipe 1).

Diagram blok internal terdiri dari dua lembar algoritma. Lembar pertama ditunjukkan pada Gambar 10a, yang kedua pada Gambar 10b.

Gambar 10a. Skema desain unit kontrol katup. Lembar 1.

Gambar 10b. Skema desain unit kontrol katup. Lembar 2.

Saat mengembangkan unit ini, jenis sinyal berikut digunakan:

• sinyal yang diterima melalui jalur komunikasi (blok biru);
• parameter dan sinyal yang diterima dari basis data sinyal (blok kuning pucat);
• sinyal yang dikirimkan ke basis data sinyal (blok biru pucat);
• sinyal yang dikirimkan ke memori (blok kuning cerah);
• sinyal yang diterima dari memori (blok hijau terang).

Diagram desain unit kontrol katup adalah vektor. Ini berarti bahwa tidak ada sinyal kontrol tunggal yang ditransmisikan pada setiap saluran, tetapi suatu vektor sinyal, dimensi yang sesuai dengan jumlah peralatan jenis ini yang dipasang di PMP. Untuk komunikasi antara unit penghitungan dan sinyal, parameter dan perintah untuk peralatan tertentu, unit antarmuka digunakan.

Dengan demikian, setelah mengembangkan dan menguji satu sirkuit kontrol dari elemen tipikal, karena banyak unit antarmuka dapat ditempatkan pada sirkuit karena peralatan jenis ini terhubung ke modul kontrol bawah air. Dalam hal ini, dalam PMU ada dua unit antarmuka untuk katup pemutus dan kontrol tipe 1 (lihat Gambar 8).

Semua sinyal variabel dan parameter yang diperlukan untuk unit kontrol ditempatkan dalam kategori yang sesuai dari basis sinyal ZRAT1 . Bagian dari kategori ditunjukkan pada Gambar 11.

Pemisahan kategori yang terpisah memungkinkan pembentukan pemisahan pengembangan modul perangkat lunak kontrol menjadi beberapa bagian dan dengan jelas mendefinisikan antarmuka interaksi antara berbagai bagian program. Dengan demikian, pengembangan modul kontrol berlangsung dalam isolasi sepanjang antarmuka dari modul lain dalam perangkat lunak.

Gambar 11. Grup sinyal untuk unit kontrol ZRAT1

Sistem pengkodean proyek

Sistem ini berisi beberapa contoh jenis peralatan ini, yang berarti ada lebih banyak variabel dalam perangkat lunak manajemen. Untuk menghilangkan kesalahan yang terkait dengan nama variabel, sistem pengkodean peralatan digunakan. Dalam basis data sinyal, kelompok-kelompok sinyal dibentuk yang namanya unik berisi kode sistem, jenis peralatan, dan kode unik di dalam sistem.

Dalam contoh ini, pada sirkuit hidrolik, kami memiliki dua contoh katup yang terletak di sistem 502, yang dikendalikan oleh blok ZRA TYPE 1 . (lihat Gambar 12.) Nama mereka dalam database adalah 502GTVOO1 dan 502GTVOO2 . Jendela basis data sinyal ditunjukkan pada Gambar 12.

Gambar 12. Basis data sinyal peralatan SPD sistem kontrol.

Sistem pengkodean menentukan nama variabel untuk modul perangkat lunak kontrol dan memungkinkan Anda untuk mengotomatiskan proses penamaan sinyal dalam seluruh modul perangkat lunak yang dikembangkan. Setiap nama variabel terdiri dari nama grup sinyal dan nama variabel yang dihubungkan oleh tanda “_”.

Untuk setiap katup pemutus dan kontrol yang terkait dengan rentang pemotretan "ZRA Type1", nama sinyal input, variabel status, variabel output terlihat seperti " kode angker " _ " signal_name ". Untuk katup 502GTV002 , ada 65 variabel dalam basis data sinyal, misalnya:

Tim:
502GTV002_open_rem - perintah terbuka jarak jauh.
502GTV002_close_rem - perintah tutup jauh.
502GTV002_open_rem_z - perintah awal untuk menutup.

Variabel status batang:
502GTV002_opened - katup terbuka penuh.
502GTV002_notopened - katup tidak terbuka.
502GTV002_notclosed - katup tidak tertutup.
502GTV002_losed - Katup sepenuhnya tertutup.

Parameter inlet dan outlet fluida hidrolik:

502GTV002_XTK1 - tekanan di garis kerja.
502GTV002_XTK2 - tekanan di saluran tekanan.
502GTV002_XTK3 - tekanan di saluran pembuangan.

Jika kita menambahkan satu lagi unit penguatan ke skema ini, maka namanya akan menjadi 502GTV003, di mana menurut sistem pengkodean yang diterima

502 adalah nama modul.
GTV - jenis penguatan.
003 - nomor seri katup jenis ini dalam modul.

Selama pengembangan modul kontrol, nilai parameter dapat diatur dalam basis data sinyal, dan dengan demikian, kesehatan unit kontrol yang terpisah diverifikasi. Khususnya, keadaan katup dalam contoh ini ditentukan oleh tekanan dalam saluran masuk dan keluar cairan hidrolik. Untuk menguji modul kontrol secara terpisah dari sistem lainnya, tekanan ini dapat diatur secara manual di basis data sinyal.

Ketika unit beroperasi sebagai bagian dari PMU, perlu untuk mentransfer nilai tekanan dari masing-masing sensor ke unit kontrol. Untuk ini, blok antarmuka digunakan, nama yang bertepatan dengan nama peralatan - lihat Gambar. 13. Untuk kenyamanan debugging, blok yang sama menampilkan nilai sinyal yang diterima dari sensor.

Gambar 13. Transmisi sinyal dari sensor ke unit kontrol ZRA T1.

Sebagai hasil dari operasi unit ini, sebuah tim dibentuk untuk memindahkan spool di katup kontrol, yang bertanggung jawab atas gear kontrol dengan nama 502GTV002 .

Selama perhitungan sambungan, nilai parameter yang dihitung dalam model hidrolik ditransfer ke unit pemrosesan pembacaan sensor (lihat Gambar 14), di mana data yang diperoleh dianalisis untuk keandalan, penyaringan, dan terjemahan ke dalam nilai pengukuran yang diperlukan.

Gambar 14. Skema desain untuk memproses sensor.

Skema perhitungan untuk memproses pembacaan sensor yang ditunjukkan pada Gambar 14 juga merupakan program yang berfungsi penuh. Untuk mentransfer sirkuit ini ke peralatan kontrol nyata, cukup bahwa nilai yang diterima dari papan input / output sensor nyata ditempatkan dalam variabel "Nilai estimasi" pada jam pertukaran data di peralatan nyata.

Sirkuit ini juga vektor dan menyediakan pemrosesan semua sensor yang termasuk dalam sirkuit hidrolik 502.prt

Blok desain standar yang dirancang dan diuji ditempatkan di perpustakaan solusi standar dan selanjutnya digunakan oleh pengembang lain untuk semua peralatan jenis ini.

Setelah debugging dan memeriksa semua skema perhitungan yang diperlukan untuk program tipikal, pengembangan perangkat lunak kontrol untuk modul bawah air menjadi jelas, sederhana dan efektif. Anda dapat menambahkan peralatan apa pun dalam dua langkah:

• Tempatkan unit kontrol peralatan.
• Tambahkan unit antarmuka sebanyak instance peralatan akan terhubung ke PMU.

Metodologi OOP dalam bahasa grafis dalam aksi.

.

. . .

.

« , () 5 »

, . . . . . , , , . , , - , .

, - (. . 15).

15. .

. , 9, 10 7, 8 (. . 16).

16. .

(. . 17). , , . , , .

17. .

, , .

18 . , .

19 .

18. 2- .

19. .

, , , , 30,5 , , 32, .

« () 5 »

, 5 , . , « () 5 », , , , 8 ( ). ( ).

Kesimpulan

- , !

. .

. .

, , , , . , - , .

- , !

, — .