Beberapa hari yang lalu saya membaca artikel yang bagus, “Manifesto Pengembang Sistem Cerdas: 15 Prinsip”

Saya memutuskan untuk membagikan pemikiran saya tentang lapisan di bawah ini, yaitu prinsip-prinsip dasar arsitektur, yang pada dasarnya akan sesuai dengan prinsip-prinsip yang diusulkan.

Karena sifat puasa, itu akan menjadi lebih subjektif daripada Manifesto.

Pertama, mari kita berurusan dengan beberapa istilah, misalnya, pengembang dan pengguna sistem pintar. Siapa ini dan di mana perpisahan itu terjadi?

Ada 2 ekstrem yang jelas: pembuat saklar pintar yang dibeli dan istri saya, yang menyalakan lampu. Tetapi kepada siapa saya mengambil anak saya atau saya, yang kadang-kadang mengambil dan mendapatkan ESP32 untuk menyolder sepasang sensor, tombol, dan strip LED lainnya, yang kemudian juga berinteraksi dengan sakelar yang sama?

Tetapi bahkan jika kita mengalihkan pandangan kita ke vendor, itu juga tidak sepenuhnya jelas. Saya akan jelaskan. Jelas ekstrim: semua perangkat dari produsen yang sama, hub juga miliknya, aplikasi di smartphone-nya adalah pengembang sistem cerdas. Tetapi bagaimana jika beberapa vendor di jaringan yang sama? Tetapi bagaimana jika hub pusat dari satu, perangkat yang lain, dan awan yang dengannya saya berinteraksi, katakanlah, Siri, apakah Apple sama sekali? Manakah dari mereka yang ditujukan kepada Manifesto, yang mana dari mereka adalah pengembang yang sama? Saya berpikir bahwa turun sedikit di bawah tingkat abstraksi global Manifesto, yang, omong-omong, saya hampir sepenuhnya bagikan, pemisahan fungsional yang lebih dalam harus diperkenalkan, jika tidak, tanggung jawab kolektif untuk pengalaman pengguna akan menghasilkan baik tanggung jawab kolektif yang sekarang kita amati pada tingkat tertentu, atau dalam selungkup ekosistem yang kaku dengan integrasi di tingkat pengguna: manakah di antara Anda yang memiliki lebih dari satu aplikasi untuk mengelola rumah pintar di ponsel Anda?

Saya mengusulkan pemisahan objek berikut: perangkat akhir, hub, gateway, cloud data, layanan integrasi, antarmuka pengguna.

Subjek (seperti peran), misalnya, pengguna, penyesuai, pengembang, produsen atau pemasok, ada dalam konteks objek-objek ini.

Bersama-sama mereka menciptakan dan membentuk suatu sistem yang, melalui pertukaran data, menyediakan fungsinya.

Dalam sedikit lebih detail dalam posting ini saya hanya akan fokus pada objek.

Perangkat akhir

Ya, dan ini pertanyaan yang agak lucu. Apa perangkat akhirnya, yaitu, “benda” Internet dari segala sesuatu?

Dengan penyedot debu pintar, semuanya jelas: mereka menarik keluar kotak dan menancapkan dudukannya ke stopkontak, ia menyingkirkannya, pergi dan membuat superposisi karpet putih dengan kreativitas bebas hewan peliharaan Anda dan pergi untuk mengisi daya. Tapi sudah dengan bola lampu, anehnya, itu tidak begitu sederhana.

Sekarang saya melihat kandil saya dengan beberapa lampu, yang saya nyalakan dengan 3 sakelar berbeda (secara terpisah, dan bukan sebagai pengaktifan hulu ledak nuklir), pada kenyataannya, dimmer pada rel DIN pada panel berfungsi. Di sini, menurut "sesuatu", tampaknya, yang kami maksud adalah aktuator terakhir, tetapi lucunya bahwa dimmer ini multi-channel dan saya bahkan tidak ingat yang mana dari chandelier lain yang juga dikontrolnya, jadi ini dia perangkatnya, tetapi tidak semua, tetapi hanya sebagian. Tetapi pada saat yang sama, ungkapan istri "nyalakan lampu" adalah intuitif.

Saya menyarankan pembaca untuk menemukan "benda" di bundel lain: pengontrol ruangan (termostat), yang mengontrol kepala radiator (pemanasan) melalui 1 saluran dari 8 saluran PWM, dan pendinginan melalui 1 saluran 4 saluran 0-10V aktuator saluran, yang telah menetapkan pengaturan untuk rana konstan aliran udara di saluran.

Saya memiliki pemikiran untuk menabrak kanselir yang kejam dan memperkenalkan definisi yang tepat tentang "hal-hal" dalam konteks ini, tetapi mari kita bicara tentang perangkat akhir dalam hal fungsi mereka, dan berapa banyak dari mereka dan bagaimana mereka berinteraksi akan ditinggalkan dari kurung untuk saat ini.

Kemudian, intuitif “buatlah lebih hangat” atau “nyalakan mode ekonomi saat kita pergi” cukup jelas.

Hub

Mengingat pemikiran sebelumnya tentang hal-hal apa, hub pada dasarnya adalah pabrik yang bahkan lebih virtual. Ini adalah hub yang dapat membuat termostat ketika sudah ada sensor suhu dan kepala di radiator. Dia dapat membuat perangkat "seluruh dunia", yang dapat dimatikan. Ini lucu, tetapi hub bisa benar-benar virtual, misalnya, di EIB atau KNX, konsep dasarnya adalah alamat grup: sensor mengirim data ke sana, dan aktuator menerima satu atau lebih alamat grup untuk setiap fungsi. Jadi, jika di pintu keluar dari apartemen Anda memiliki saklar yang mengirim ke beberapa 1/1/1 negara 0, dan di masing-masing aktuator yang bertanggung jawab untuk cahaya itu hadir (bersama dengan lebih banyak individu, katakanlah, 1/0 / 11, 1/0/12/12, dll.) Anda akan memiliki perangkat seperti itu "matikan seluruh dunia" tanpa perangkat fisik tambahan.

Dalam contoh ini, hub adalah jaringan itu sendiri, dalam kasus lain, hub sering ada di dunia fisik sebagai perangkat fisik yang terpisah, tetapi Anda dapat memberikan contoh yang baik dari hub "tidak terlalu fisik" - ini adalah Node-RED.

Saya meminta Anda untuk memberikan perhatian khusus pada fakta bahwa saya sengaja tidak mengatakan bagaimana aliran data dari perangkat yang sudah ada masuk ke hub ini dan bagaimana mereka mengalir dari itu ke bagian lain dari sistem. Objek sistem lainnya - gateway - bertanggung jawab atas fungsi ini.

Gateway

Kebetulan selama 40-50 tahun terakhir, banyak jaringan telah dibuat yang berbeda dalam topologi dan tingkat abstraksi (dengan protokol mereka sendiri), yang dengan satu atau lain cara dapat menjadi bagian dari sistem Internet of things. Untuk menghubungkan 2 jaringan, sebuah simpul pertukaran lalu lintas dibuat, jika simpul semacam itu mengemas semua data dari satu protokol ke protokol lain, maka biasanya disebut sebagai terowongan, karena di sisi lain, Anda dapat sepenuhnya membuat seluruh aliran berfungsi dengan seolah-olah itu lokal, jika penggantian terjadi abstraksi, maka simpul seperti itu disebut gateway.

Karena kita cukup fasih dalam terminologi dalam posting ini, mari kita gunakan istilah gateway dan menghabiskan sedikit lebih banyak waktu untuk parsing dari mana dan di mana sebenarnya perangkat yang ada sebenarnya gateway. Setiap orang yang bekerja dengan sistem kontrol proses cepat atau lambat memperluas jaringan "pusat" dengan yang tambahan, misalnya, banyak meter terhubung ke Profibus di Modbus.

Ini semua adalah kasus yang cukup berhasil dan Anda tidak bisa berhenti terlalu banyak, tetapi kemana Xiaomi Mijia Multifunctional Gateway mengunci? Saya ingin mengatakan itu dari ZigBee ke Wi-Fi, tetapi ini tidak sepenuhnya benar. Ya, ada jaringan ZigBee di satu sisi gateway, tetapi bahkan jika Anda menghubungkan perangkat pihak ketiga, Anda tidak dapat mencapainya melalui gateway ini. Ada Wi-Fi di sisi lain dari gateway, tetapi gateway tidak hanya menyediakan komunikasi jaringan area lokal menggunakan protokol (yang disebut protokol miIO oleh peretas), tetapi juga dengan Xiaomi cloud, yang memastikan pengoperasian aplikasi Mi Home ketika Anda meninggalkan jaringan lokal. Gateway lain yang sangat menarik adalah Samsung SmartThings, tetapi ada kesulitan.

Jika sebelumnya ada pertanyaan mengapa Groovy dengan segala keberagamannya, sekarang saya akan menyebut kesulitan tender menjadi keruh.

Saya akan menjelaskan posisi saya, dengan harapan saya salah. Saat membuat perangkat baru yang kompatibel dengan ekosistem Samsung SmartThings, Anda dapat memilih 2 opsi: terhubung ke hub, atau langsung ke cloud, jika Anda ingin membuat otomatisasi, yang saya sebut di atas sebagai perangkat yang dihasilkan oleh hub, ia pindah ke cloud. Intinya. Artinya, ada pelanggaran terhadap Manifesto. Anda tidak akan menyalakan lampu di toilet jika Internet tidak bekerja untuk Anda, baik melalui aplikasi (tampaknya tidak ada harapan lagi secara lokal, berdasarkan diagram dalam artikel IoT dan Tizen IoT ), atau secara lokal dari sensor gerak jaringan lain, karena Anda perlu mengintegrasikan perangkat dan bukan jaringan - sebaliknya melalui cloud.

Mereka yang berhasil bekerja dengan Tizen IoT, tolong perbaiki saya.

Situasi serupa terjadi dengan Logitech Harmony, yang memutuskan otomatisasi lokal setelah pembaruan.

Jika kita membuang gateway dari jenis "jaringan otomasi - jaringan otomasi", hal terpenting dalam pengoperasian gateway adalah abstraksi target, di mana ia menerjemahkan presentasi perangkat dari jaringan inti, dan ini sudah ditentukan oleh awan data.

Awan data

Ini adalah objek sistem yang paling jelas dan paling tidak jelas pada saat yang bersamaan. Fungsi dan kebutuhannya jelas, tetapi bagaimana tepatnya komponen ini diimplementasikan adalah yang paling tidak jelas dan tidak tergantung pada keinginan pengguna akhir.

Karena itu, saya lebih suka mengisi bagian Keinginan dan pikiran pribadi saya ini.

Adalah baik ketika ada API yang dapat dimengerti dan yang sederhana, bahkan lebih baik ketika API ini terbuka dan terhubung saja.

Di sini saya akan membuat reservasi tentang kesederhanaan. Kesederhanaan, jika tidak berbicara tentang matematika, pada prinsipnya subyektif. Pendapat pribadi saya didasarkan pada pengalaman dan keinginan saya. Tentu saja, untuk perusahaan yang akan merilis produk tertentu dalam jumlah beberapa ratus ribu kesederhanaan benar-benar berbeda.

Saya ingin saya dapat menenun hasil hobi saya ke dunia di sekitar saya. Apa yang diperlukan untuk ini?

Sumber daya pembatas utama adalah waktu, yang kedua adalah pengetahuan, yang ketiga adalah uang. Jika saya tidak dapat membuat perangkat yang entah bagaimana berfungsi melalui cloud dalam satu hari, maka itu akan dilakukan "nanti", selama itu identik dengan "Mayy Chumorrow" dan "Magnya". Sekarang, jika itu bekerja entah bagaimana, maka setelah beberapa hari libur, mungkin itu akan berfungsi sebagaimana mestinya. IoT bersifat interdisipliner, dan di sini Anda perlu meningkatkan beberapa server OAuth2, menambahkan sertifikat, mengimplementasikan API, dan semua ini dilakukan untuk membuat mikrokontroler kecil buatan rumah saya dengan asisten suara, yang akan saya tulis di bagian selanjutnya.

Pikiran sebelumnya lebih banyak tentang "Bagaimana?", Tapi masalah yang tidak kalah pentingnya (ini bukan tantangan, yaitu masalah) terletak pada "Apa?".

Saya akan membagi semua awan data utama yang dapat digunakan untuk IoT menjadi dua kelas: titik data dan kemampuan.

Awan poin data . Ini bisa berupa evolusi paralel dengan dunia SCADA, atau keturunan langsung.

Di sini Anda memiliki pembacaan sensor suhu - baik, mari kita tulis di suatu tempat di awan, di mana orang yang perlu membacanya. Sensor suhu ada pada baterai, yang berarti Anda masih perlu mempertahankan tingkat pengisian daya - tidak masalah, lihat di atas. Ada seluruh kelas awan yang memungkinkan Anda melakukan ini. Mereka dapat dengan mudah dikenali jika protokol utamanya adalah MQTT (tetapi bisa berupa CoAP dan STOMP). Suatu hal yang luar biasa - saya sendiri menggunakannya dan tidak hanya di IoT, menyebutnya "kemenangan kebebasan atas akal sehat." Hanya saja protokolnya sangat fleksibel sehingga setiap orang memecahkan masalah yang sama dengan caranya sendiri.

Awan data dalam bentuk peluang . Saya akui, sekitar 8-9 tahun yang lalu, ketika saya sedang menulis versi berikutnya dari platform rumah saya, saya ingin mengambil dan mengklasifikasikan objek dalam sistem. Sehingga sistem memahami bahwa ini adalah bola lampu, dan ini adalah sakelar, dan ini adalah katup. Iterasi pertama yang jelas: daftar jenis (tetapi sebenarnya kelas, karena OOP adalah sama). Kemudian sebuah saklar muncul, tetapi pada baterai, kekuatan OOP sedang beraksi - jadi kami mewarisi dan mendapatkan yang baru. Dan ternyata baterainya bisa apa saja. Maka itu perlu untuk memotong tidak menjadi pohon kelas perangkat, tetapi untuk membagi ke dalam "kemampuan" perangkat, menggabungkan yang kita dapatkan switch.

Begitulah cara kerja Apple HomeKit, Alexa, Google, dan ekosistem cloud rumah pintar lainnya. Tampaknya itu adalah kebahagiaan.

Tapi, seperti yang saya katakan di atas, saya menggunakan pendekatan ini 8-9 tahun yang lalu. Dan saya menentukan sendiri fitur-fitur ini, saya ingin menambahkan kamera IP atau Asterisk PBX? Bagus Saya selesai dan bekerja.

Namun, inilah kemalangannya, ekosistem awan rumah pintar yang tercantum di atas sebenarnya bukan ekosistem IoT, melainkan ekosistem asisten suara, yang kemampuannya harus universal untuk seluruh dunia dan untuk semua perangkat. Menambahkan fitur-fitur baru ke dalam proses sangat berbeda dari "Appended and works" saya. Kita semua ingat bagaimana saat fajar ekosistem ini harus "menghidupkan gerbang". Situasinya mirip dengan SmartThings.

Tidak ada pabrikan yang dapat memberikan daftar kemampuan yang jelas dan lengkap untuk perangkat yang dapat dirilis dan menjadi bagian dari ekosistem IoT. Itu sebabnya sistem seperti persentase lemak visceral, gula darah atau aseton tidak memiliki kemampuan untuk mengetahui apa? Mengapa rumah tidak dapat mendukung Anda dengan ilusi gembira ketika semuanya baik-baik saja atau menarik perhatian Anda ketika ada sesuatu yang salah?

Di sisi lain, bagaimana cara membuat antarmuka pengguna tanpa memahami apa yang dapat dilakukan perangkat? Pendekatan titik data di SCADA nyaman untuk menyembunyikan fitur topologi dan protokol. Dapatkan data (daftar horizontal) dengan beberapa properti tambahan, misalnya, keandalan (apakah ada pemutusan sepanjang jalan) atau tingkat akses, tetapi presentasi utama mereka adalah dalam bentuk diagram mnemonik.

Tetapi pengguna IoT hidup di era Post-PC dan sirkuit mnemonik tidak nyaman di layar ponsel, dan setup mereka sangat panjang.

Saya pikir harus ada hibridisasi tertentu. Pertama, sistem harus tahu apa perangkat itu, dan harus memiliki titik data. Namun, yang tidak kalah penting adalah bahwa harus ada juga informasi meta tambahan yang harus dikirimkan ke cloud khusus, misalnya, asisten suara favorit Anda. Informasi tersebut, khususnya, dapat mencakup profil (sekumpulan kemampuan) perangkat, dalam pengertian cloud eksternal, dan pengidentifikasinya.

Fungsi produsen perangkat adalah untuk menggambarkan, antara lain, kinerja yang diinginkan untuk produk ini baik untuk antarmuka visual dan untuk jenis lainnya: interaksi suara, AR / VR dan sejenisnya. Tetapi, bahkan jika pabrikan tidak melakukan ini, dengan enggan dan kewalahan oleh kemalasan, pengguna masih dapat memilih apa yang perangkat Google ini mulai sekarang kenal sebagai "Smart Home Kettle" dan sekarang ia memiliki fitur-fitur seperti: TemperatureControl, OnOff, Mode dan Matikan Ya, saya menjatuhkan action.devices.traits untuk kekompakan.

Itu untuk memastikan interoperabilitas harus sudah layanan integrasi.

Layanan Integrasi

Ini adalah gateway yang sama, tetapi di antara awan. Beberapa abstraksi harus diganti oleh yang lain.

Basis interaksi adalah suatu peristiwa. Ada kedua model permintaan dan publikasi. Topiknya sangat luas sehingga Anda bisa jatuh ke dalam perangkap Bollywood saat menggambarkannya. Di sana, seperti yang Anda tahu, lebih banyak film diproduksi per tahun daripada yang dapat ditonton secara fisik,
oleh karena itu, pada akhir artikel saya akan lebih jauh dari kenyataan daripada saat deskripsi dimulai.

Saya sudah menyebutkan banyak sistem rumah tangga, Anda dapat mengingat LoRaWAN (dan TheThingsNetwork), IFTTT, OpenStreetMap, AWS IoT, Azure IoT, layanan cuaca, ya, pada kenyataannya, hampir semua layanan Internet atau Intranet (apakah ada istilah lain?), Jika data perangkat harus masuk ke sistem perusahaan.

Antarmuka pengguna

Saya tidak akan mendeskripsikan bagian ini secara mendalam, tetapi saya ingin menyesali, tidak layak menurut pendapat saya, dilewati oleh sistem IoT rumah tangga, desktop. Hanya di Mojave HomeKit akhirnya keluar - bagi saya ini membingungkan. Mengapa ketel lebih rumit daripada spreadsheet di mana saya dapat menghitung Arus Kas suatu perusahaan? Lagi pula, dengan Numbers saya dapat bekerja di browser, tetapi saya tidak harus mematikan besi yang terlupakan, dalam pengertian Apple. Singkatnya, berikan PWA!

Antarmuka pengguna pada dasarnya adalah saklar fisik yang mudah digunakan, tetapi tidak banyak dimaafkan.

AR, VR, Mixed Reality, asisten suara, TV pintar, aplikasi untuk smartphone dan tablet, antarmuka saraf EEG adalah ceri pada kue, yang menurut kami sangat menyenangkan untuk dimainkan.

Kata penutup

Tampaknya, apa yang harus dilakukan oleh Docker dan layanan mikro? Jika itu akan menarik bagi pembaca, saya akan dengan senang hati berbagi pemikiran dan perkembangan saya dalam implementasi arsitektur sistem IoT berdasarkan klasifikasi objek ini.

Saya menggunakannya sendiri.