Komponen untuk pembaruan perangkat lunak berbasis cloud di IoT
Memperbarui perangkat lunak (komponen) pada perangkat edge terbatas serta pada pengontrol dan gateway yang lebih kuat adalah persyaratan umum di sebagian besar skenario IoT.
Memiliki kemampuan pembaruan perangkat lunak memastikan IoT yang aman dengan memberi proyek IoT kesempatan bertarung melawan kotak Pandora yang mereka buka saat perangkat mereka terhubung . Sejak saat itu, perangkat berada di garis depan ancaman keamanan TI, yang secara historis tidak pernah dihadapi oleh banyak pengembang perangkat lunak tertanam. Saat ini, pengiriman, katakanlah, perangkat yang terhubung ke web yang didukung Linux tanpa pembaruan keamanan apa pun yang pernah diterapkan selama masa pakainya, sama saja dengan bunuh diri.
Argumen yang lebih menarik untuk pembaruan perangkat lunak adalah bahwa pembaruan tersebut memungkinkan pengembangan perangkat keras dan komponen yang terkait dengan perangkat keras secara gesit. Konsep seperti produk minimum yang layak dapat diterapkan ke perangkat, karena tidak semua fitur harus siap pada waktu produksi. Perubahan di sisi cloud dari solusi IoT juga dapat diterapkan ke perangkat saat waktu proses.
Terkadang pembaruan perangkat lunak adalah model bisnis tersendiri, karena perangkat jauh lebih menarik bagi pelanggan jika dapat diperbarui. Dengan kata lain, konsumen tahu bahwa mereka tidak hanya mendapatkan serangkaian fitur tetap, tetapi juga dapat mengharapkan manfaat dari pembaruan produk di masa mendatang. Selain itu, aliran pendapatan baru mungkin muncul dari potensi monetisasi ekstensi fitur (mis. aplikasi ) tanpa perlu merancang, membuat, dan mengirimkan perangkat baru (revisi).
Konektivitas perangkat
Ada berbagai opsi untuk menghubungkan perangkat ke layanan cloud. Dari perspektif arsitektur, harus diputuskan apakah perangkat harus terhubung langsung ke layanan pembaruan perangkat lunak atau secara tidak langsung melalui lapisan konektivitas perangkat (misalnya Bosch IoT Hub, AWS IoT, IBM Watson IoT, Azure IoT Hub, dll.), yang juga dapat menjadi layanan solusi IoT. Saya sendiri sangat percaya pada pendekatan langsung, dan produk saya Bosch IoT Rollouts benar-benar mendukung keduanya. Saya akan menjelaskan alasannya di bawah ini.
Jadi, mari kita mulai:konektivitas langsung akan memungkinkan solusi IoT memiliki pemisahan masalah dengan memiliki saluran berbeda untuk pembaruan perangkat lunak selain saluran mereka sendiri yang digunakan solusi IoT untuk aliran dan perintah peristiwa perangkat.
Ini adalah pendekatan yang menarik karena dua alasan:pertama, lebih mudah untuk menjaga kestabilan API saluran pembaruan perangkat lunak jika Anda tidak perlu repot dengan semua persyaratan bisnis saluran lain . Kita tidak boleh lupa bahwa ada skenario di IoT di mana perangkat yang terhubung mungkin digunakan untuk waktu yang lama tanpa kontak dengan backend. Dalam beberapa kasus mungkin bertahun-tahun, terutama antara manufaktur dan konektivitas awal. Menjaga agar lapisan transport tetap stabil untuk jangka waktu tersebut adalah mudah, tetapi hal itu tentu tidak berlaku untuk lapisan bisnis. Hal ini terutama berlaku di IoT, di mana banyak solusi cloud masih dalam tahap awal kedewasaan.
Kedua, memiliki saluran terpisah juga memungkinkan Anda memisahkan fungsi bisnis dan pembaruan pada perangkat itu sendiri . Terutama di tumpukan yang kompleks (misalnya di gateway IoT), apakah Anda benar-benar ingin mengambil risiko tumpukan yang berpotensi rusak karena harus memperbarui sendiri untuk memperbaiki masalah? Dan apakah bisa dijamin selalu bisa melakukan itu? Bayangkan sebuah skenario di mana Anda memiliki runtime OSGi di gateway Anda dengan satu bundel yang menyebabkan pengecualian kehabisan memori dan klien pembaruan perangkat lunak Anda berjalan dalam runtime yang sama. Bisa jadi sangat sulit untuk memprediksi hasilnya.
Namun, pemisahan itu ada harganya:dua saluran biasanya berarti upaya penerapan yang lebih besar di sisi perangkat, dan dalam beberapa skenario, hal itu juga dapat meningkatkan pengurasan anggaran lalu lintas atau masa pakai baterai Anda.
Opsi kedua adalah menggabungkan kasus penggunaan dalam satu saluran. Kami menyebutnya tidak langsung integrasi dengan layanan pembaruan perangkat lunak, karena lapisan konektivitas awan sebenarnya terhubung ke perangkat dan harus memisahkan solusi dari lalu lintas pembaruan di awan.
Ini memiliki manfaat besar dari arsitektur konektivitas yang disederhanakan. Hal ini juga memungkinkan untuk memanfaatkan standar protokol manajemen perangkat tujuan umum (misalnya LWM2M, OMA-DM, TR-069), yang biasanya menyertakan pembaruan perangkat lunak hanya sebagai subbagian dari standar mereka. Selain itu, memungkinkan penggunaan protokol kepemilikan yang ditentukan oleh perangkat (produsen) itu sendiri.
Pada akhirnya, insinyur solusi IoT memiliki pilihan untuk dibuat:pemisahan masalah vs. kesederhanaan. Dengan Peluncuran IoT Bosch kami, kami telah memutuskan untuk mendukung kedua opsi tersebut, dan kami memiliki pelanggan yang menggunakan keduanya. Konektivitas langsung ternyata jauh lebih mudah dipelihara untuk solusi IoT, sementara konektivitas tidak langsung menambah banyak kerumitan pada keseluruhan arsitektur.
Namun, sebagian besar insinyur IoT memasukkan masalah pembaruan perangkat lunak dalam proses desain mereka sangat terlambat dalam proyek, karena dalam kebanyakan kasus itu bukan bagian dari fungsi bisnis inti, dan ketika mereka melakukannya, mereka tidak ingin membuat perubahan lagi. terhadap arsitektur mereka. Akibatnya, sebagian besar solusi mengambil pendekatan tidak langsung, yang berpotensi menimbulkan konsekuensi setelah go-live.
Keputusan kedua untuk pembaruan perangkat lunak berbasis cloud di IoT berkaitan dengan protokol. Haruskah saya menggunakan protokol manajemen perangkat standar atau mendesain yang khusus? Banyak solusi IoT saat ini mendukung MQTT dengan protokol khusus di atasnya. Selain itu, banyak lapisan konektivitas IoT di pasar juga menawarkan protokol eksklusif selain HTTP, MQTT, atau AMQP.
Saya pribadi percaya bahwa beberapa standar memiliki nilai dan setidaknya harus dipertimbangkan. OMA-DM v2 terlihat menjanjikan dan kami juga memiliki pengalaman dengan LWM2M. Seperti biasa, standar menawarkan kerangka kerja yang baik, tetapi biasanya disertai dengan serangkaian batasan; terutama pada tahap awal proyek IoT, ini dapat menambah banyak kerumitan. Namun, standar yang baik yang mencakup pembaruan perangkat lunak akan memungkinkan solusi IoT untuk memiliki pembaruan perangkat lunak sebagai fungsi tanpa perlu menulis satu baris kode pun jika perangkat dan layanan pembaruan perangkat lunak mendukungnya.
Last but not least, ada pertanyaan tentang otentikasi perangkat. Ini, tentu saja, pertanyaan umum untuk setiap solusi IoT. Tetapi terutama untuk jalur integrasi langsung, pilihan harus dibuat apakah mekanisme otentikasi yang sama dapat digunakan untuk pembaruan perangkat lunak dan saluran solusi IoT. Saya biasanya berpendapat untuk menggunakan mekanisme yang sama. Ini sebenarnya mudah diterapkan dengan otentikasi asimetris (misalnya sertifikat X.509). Bosch IoT Rollouts mendukung ini untuk Direct Device Integration API-nya serta sebagian besar lapisan konektivitas yang biasanya digunakan di IoT. Jika asimetris bukanlah pilihan (yang sering terjadi pada perangkat tersemat yang dibatasi), saya akan merekomendasikan untuk menggunakan penyimpanan kunci sentral (simetris) yang dapat digunakan oleh saluran yang berbeda.
Seperti yang ditunjukkan di atas, ada pilihan yang harus dibuat dan pertanyaan yang harus dijawab. Sayangnya, IoT belum dalam keadaan di mana kami telah menemukan satu arsitektur yang paling tidak cocok dengan sebagian besar skenario. Namun, kabar baiknya adalah bahwa ada opsi dan opsi tersebut berfungsi.
