Mari kita mulai dengan besi
Saya pernah bekerja di pabrik yang sama, di mana mereka memahat semua jenis elektronik, tidak terlalu rumit, dan kadang-kadang jatuh di bawah definisi "Internet of things". Sebagian besar, semua jenis sensor untuk sistem keamanan: asap, kebisingan, penetrasi, api, dan banyak lagi. Beraneka ragam produk sangat luas, kadangkala jumlahnya kurang dari 500 buah, dan hampir untuk setiap produk saya harus membuat Fixture Test terpisah - pada kenyataannya, hanya sebuah kotak timah di mana produk tersebut diuji, ditekan dengan sebuah penutup, dan dari bawah jarum kontak ditekan ke titik kontak pada papan sirkuit cetak, sesuatu seperti ini:
Dengan demikian, dimungkinkan untuk berkomunikasi secara fisik dengan perangkat. Protokol komunikasi yang kami miliki cukup umum di industri - RS232 (COM-port, sejenis UART). Semua jenis perangkat terkontrol sederhana untuk menguji produk akhir juga dimasukkan ke dalam kotak. Semua instrumentasi tambahan ini dikendalikan dengan cara yang sama. Seluruh struktur sangat tipis, dan segala macam masalah adalah bagian dari rutinitas sehari-hari.
Berbagai masalah sangat luas - kontak yang buruk, membalik polaritas selama instalasi, masalah dengan produk yang diuji, dengan kontrol dan alat pengukur, dengan jarum kontak, dengan kode uji ... tetapi Anda tidak pernah tahu! Tapi itu perlu untuk menguji terus-menerus, dan jika tes mulai "masuk" di suatu tempat, salah satu insinyur harus menginjak garis dan mulai memeriksa semuanya secara manual.
Pertama-tama, Docklight diluncurkan - utilitas yang bagus untuk "berkomunikasi" melalui port COM, tetapi memiliki banyak keterbatasan. Dan di sini kita mendekati esensi masalah ini.
Mengapa Docklight tidak cocok untuk saya?
Baiklah, ayo pergi.
- Masalah pertama adalah bahwa Docklight hanya berjalan di Windows. Jadi, pemasangan "pusat saraf" dalam bentuk RaspberryPi, yang akan menghubungkan semua perangkat, atau sesuatu seperti itu, bisa dilupakan. Saya harus menginstal NUC - solusi termurah dalam situasi ini. Berat, agak besar, dan bukan yang termurah. Ngomong-ngomong, ketika Perlengkapan Uji ini diseret dari satu tempat ke tempat lain, NUC berjuang sangat, sangat banyak (walaupun saya akui bahwa desain mereka cukup solid).
- Yang kedua - akses jarak jauh hanya dapat dilakukan melalui berbagi Desktop - itu diperlambat bahkan melalui jaringan lokal, dan bahkan melalui Internet itu benar-benar timpang.
- Ketiga, setiap perangkat memiliki seperangkat perintah sendiri, dan Docklight dapat memuat file dengan daftar perintah. Jika, katakanlah, Anda harus berbagi daftar yang sama dengan seseorang di departemen, lalu kirim email dengan file tersebut, atau ... kirim tautan ke file di folder bersama! Secara alami, setiap instalasi Docklight memerlukan file seperti itu secara lokal, dan semua ini harus dilakukan lusinan (jika tidak ratusan kali) secara manual - untuk setiap NUC, setiap insinyur menyeret daftar perintah favorit dan nyamannya. Dan di halaman 2019, izinkan saya mengingatkan Anda ...
- Keempat, Docklight tidak memungkinkan Anda untuk secara otomatis mengaitkan port COM dengan nama perangkat: misalnya, Windows, ketika Anda menghubungkan Power Supply, akan berkomunikasi dengan perangkat melalui COM12. Jika Anda ingin secara manual "menarik string", maka di Docklight Anda harus membuka COM12. Bagaimana kita dapat mengetahui bahwa ini hanya tentang Power Supply, dan bukan, katakanlah, tentang SwitchBoard? Nah, Anda dapat melihat ke manajer perangkat setiap waktu, dan mencoba untuk tidak melupakan perangkat mana yang terhubung ke port mana. Pada saat yang sama, tidak ada yang menjamin bahwa jika Anda cukup mengeluarkan perangkat dan kemudian memasangnya lagi, maka port sebelumnya akan tetap dengan perangkat ini. Singkatnya, setiap kali Anda harus melakukannya secara manual. Dan percayalah, pada akhir hari kepalaku berputar dari ini.
- Kelima, setiap port memerlukan salinan program yang terpisah, dan, tentu saja, semua operasi harus dilakukan secara terpisah untuk setiap perangkat, dan meskipun Docklight mendukung skrip, tidak ada interaksi di antara masing-masing instance.
Selanjutnya Tidak ada integrasi dengan produk lain yang disediakan. Tampaknya menjadi hal yang sepele, tetapi inilah situasi di mana ia menjadi panas: tes jatuh, dan kita perlu mencari tahu mengapa. Pertama-tama, Anda perlu terhubung ke perangkat dan melihat apakah mereka sudah mati sama sekali. Kami pergi ke pengelola perangkat, lihat di mana port tempat perangkat kami duduk, buka Docklight, memulai komunikasi dengan port kami ... Kesalahan. Sialan! Saya lupa untuk menghentikan layanan yang diinstal pada NUC dan menyimpan semua port. Eksklusif, Anda tahu. Oke, kami memperlambat layanan, membuka port, memuat file dengan perintah perangkat, mengirim perintah, kami mendapatkan (atau tidak mendapatkan) jawabannya, kami menyelesaikan masalah. Kami menjalankan tes lagi, crash lagi ... Oh, sial, saya lupa untuk menutup Docklight dan memulai kembali layanan. Semuanya sepertinya tidak ada kesalahan. Tapi ini untuk beberapa jam ke depan, sampai ada yang tidak beres lagi. Dan percayalah, itu perlu untuk memecahkan masalah seperti itu lebih sering daripada yang kita inginkan.
Nah, dan tentu saja, tentang ekstensi apa pun, tambahkan. tidak mungkin ada fitur atau sejenisnya - produk ditutup, ditulis untuk waktu yang lama (tampaknya mereka tidak lagi dikembangkan secara khusus), tidak ada penyesuaian.
Yah, saya memutuskan untuk melakukan sesuatu milikku, tetapi memperbaiki (atau memperbaiki) situasi dengan masalah yang dijelaskan.
Ternyata sesuatu seperti Zabbix, tetapi dengan penajaman untuk situasi tertentu.
Jadi apa bedanya?
Mungkin masuk akal untuk memulai dengan deskripsi umum arsitektur, dan kemudian masuk ke detail.
Skemanya terlihat seperti ini:
Kami memiliki Agen yang beroperasi di stasiun tempat perangkat kami terhubung secara fisik. Agen ditulis dengan Python, sehingga ia berfungsi tanpa masalah di Windows, Linux, dan Anda dapat menyelesaikannya dengan aman untuk digunakan di RaspberryPi dan perangkat serupa. Program ini sangat mudah untuk sumber daya, dan sangat stabil. Agen terus terhubung melalui Websocket ke server (ujung belakang), dan menerima semua pengaturan port dan parameternya dari sana, baik selama inisialisasi dan selama pembaruan. Agen memiliki GUI sendiri untuk pengaturan dan pemantauan dalam hal ini (mungkin koneksi terputus, mungkin lisensi kedaluwarsa).
Selanjutnya Server (alias ujung belakang) naik dari buruh pelabuhan (dan karenanya hanya berjalan tidak hanya di amazon atau Google Cloud, tetapi juga pada mesin yang tidak terlalu kuat di LAN dengan Linux di papan). Itu ditulis dalam Django bersama dengan Redis (untuk mendukung websockets). Ini menyimpan semua pengaturan, dan menyediakan komunikasi antara GUI pengguna (hanya halaman yang ditulis dalam ReactJS) dan melalui Agen - dengan perangkat kami. Komunikasi dua arah, sepenuhnya asinkron. Semua pengaturan disimpan di Postgres dan Mongo.
Yah, dan, mungkin, bagian terpenting dari sistem adalah klien itu sendiri (hanya sebuah halaman di browser, ditulis untuk ReactJS untuk dinamisme yang lebih besar).
Ya, desain visual jauh dari sempurna, tetapi ini bisa diperbaiki.
Nah, ini bisa dibulatkan, saya akan menambahkan hanya beberapa kata tentang status proyek dan demo.
- Ini adalah alpha yang cukup awal, dirancang untuk lebih menunjukkan potensi fasilitas dan memeriksa tingkat minat.
- Mainkan demo - di sini
Untuk masuk
nama pengguna: operator_0
kata sandi: 123456789
Kami memilih QA_Test dan stasiun apa pun (ini hanya upaya untuk mensimulasikan struktur perusahaan - port terhubung ke stasiun, mereka dibagi menjadi beberapa departemen, dan setiap kantor memiliki struktur sendiri)
Pada prinsipnya, jika ada minat, saya akan menambahkan dukungan untuk https, dan saya akan membangun majelis Agen untuk platform yang berbeda, serta menambahkan semua fitur lainnya.
Saya akan dengan senang hati menerima umpan balik dan saran. Kritik dipersilahkan!