Menguji keberhasilan pembaruan Over the Air [ditutup]

10

Apa praktik terbaik untuk memastikan perangkat IoT berhasil diperbarui?

Apa yang perlu Anda lakukan untuk menguji pembaruan OTA dan mengotentikasi perangkat? Melangkah lebih jauh, bagaimana Anda bisa memonitor / mengelola versi perangkat lunak (pembaruan) dari armada perangkat IoT?

testing authentication over-the-air-updates

— Noam Hacker
sumber

1

Ini terlalu luas, seperti pertanyaan Anda yang lain. Dan itu akan sangat tergantung pada jenis perangkat dan mode penyebaran.

— Gilles 'SO- berhenti menjadi jahat'

1

Ketika Anda mengatakan "armada", apakah maksud Anda armada kendaraan? Jika demikian, saya menganggap komunikasi dengan (terenkripsi) SMS, atau HTTPS melalui GPRS, atau satelit acara, menggunakan sesuatu seperti modem SkyWave. jika Anda dapat mengedit pertanyaan Anda untuk menjelaskan, saya yakin itu akan dibuka kembali.

— Mawg mengatakan mengembalikan Monica

10

Saya memiliki perangkat lunak (Windows Server - sedikit berbeda dengan 'sesuatu' tetapi prinsipnya sama) yang memanggil setiap 24 jam - ia mengirimkan kembali berbagai data meta tentang dirinya:

nama pelanggan (atau ID unik)
versi perangkat lunak
cap waktu panggilan / permintaan
jenis produk / id

Layanan web mem-parsing data dan menyisipkan (atau memperbarui jika pelanggan memiliki baris yang ada) baris dalam database.

Dengan cara ini pelanggan baru secara otomatis ditambahkan ke DB, pelanggan yang ada mendapatkan cap waktu 'terakhir terlihat' mereka diperbarui dan kami selalu memiliki versi perangkat lunak terbaru. Saya bisa menjalankan permintaan DB yang memberi tahu saya pelanggan mana yang ada di versi yang lebih lama, dan / atau pelanggan yang belum menelepon untuk sementara waktu.

Kami juga menerapkan pembaruan otomatis (pikirkan pembaruan OTA) baru-baru ini dan karena ini adalah proses kritis, kami menerapkan telemetri khusus untuk ini - yang mencatat:

Versi sekarang.
Versi yang akan diperbarui.
Siapa / kapan mengizinkannya (jika diperlukan penerimaan pelanggan).
Stempel waktu dan kode status untuk setiap langkah utama.

Ini memungkinkan kami untuk menentukan apakah aspek-aspek tertentu dari pembaruan otomatis gagal dan dalam banyak kasus memungkinkan kami menghubungi pelanggan sesering sebelum mereka bahkan melihat ada sesuatu yang salah.

Perbedaan besar dengan 'hal-hal' adalah bahwa Anda biasanya dibatasi oleh memori, jadi untuk melakukan pembaruan xxx Kbfirmware OTA Anda membutuhkan xxx Kb * 2memori yang tersedia (firmware yang ada + memori yang cukup untuk menyimpan firmware baru sebelum memulai pembaruan firmware yang sebenarnya)

— KennetRunner
sumber

1

Terima kasih telah berbagi. Penggunaan memori adalah poin penting untuk dibuat. Bagaimana Anda menjalankan otorisasi dan penerimaan pelanggan, jika ada? Apakah Anda memerlukan kata sandi untuk menerima pembaruan?

— Noam Hacker

2

Ini adalah kasus penggunaan yang berbeda (karena ini adalah Server Windows), tetapi kami memiliki UI yang muncul lansiran ketika pembaruan OTA telah diunduh - lansiran menanyakan pelanggan apakah mereka ingin memperbarui (dan termasuk tautan untuk melepaskan catatan, dll). Pada thingsaya mungkin akan mem-flash LED atau sesuatu untuk mengingatkan pengguna (dengan asumsi Anda ingin pengguna untuk 'mengizinkan' pembaruan) dan kemudian minta mereka 'tekan lama' tombol untuk memulainya ...

— KennetRunner

5

Anda dapat, misalnya, membuat permintaan setiap X minggu / hari / jam ... ke server dengan nomor versi perangkat lunak saat ini. Anda akan dapat menggunakan analitik untuk melihat persentase saat ini dan jumlah perangkat yang diperbarui.

— WayToDoor
sumber

1

Apakah akun ini untuk perangkat yang telah ditutup-tutupi, atau gagal menyelesaikan pembaruan (mungkin macet saat reboot, unduh, siklus rusak?)

— Sean Houlihane

1

Di satu sisi, ya. Jika Anda memiliki 100 perangkat pada hari 1, Anda mendorong pembaruan pada hari 2, dan hari 3 Anda hanya memiliki 25 perangkat pada analitik, itu berarti sesuatu yang buruk terjadi

— WayToDoor

1

Itu menarik. adakah cara untuk membedakan antara jenis kegagalan?

— Noam Hacker

1

pisahkan pembaruan menjadi beberapa langkah terpisah (mis. tambahkan nilai konfigurasi baru , reboot gps , set id perangkat , timpa firmware , dll.) dengan masing-masing memiliki permulaan .. panggilan kirim 'rumah' dan lengkap dengan status xx panggilan dikirim pulang. Dengan begitu Anda dapat mengetahui (kurang-lebih) di mana ia gagal dan (mudah-mudahan) apa kode statusnya.

— KennetRunner

4

Ini semua tentang kebijakan sinkronisasi cerdas

Anda memerlukan kebijakan sinkronisasi cerdas yang bekerja bersama-sama dengan pendekatan peluncuran pembaruan Anda. Titik paling jelas dalam waktu di mana perangkat IoT harus menyinkronkan versinya adalah langsung setelah pembaruan . Jadwal sinkronisasi lainnya sangat tergantung pada jenis perangkat.

Apakah selalu aktif dan terhubung melalui koneksi kabel di mana sinkronisasi tunggal tidak dikenakan biaya (banyak) masuk akal untuk melakukan sinkronisasi secara berkala untuk menjaga data Anda tentang perangkat saat ini.

Jika perangkat ada di suatu tempat setiap bit mahal karena Anda menggunakan koneksi satelit mahal jadwal sinkronisasi harus mengakomodasi keadaan itu.

Verifikasi sinkronisasi

Dalam perangkat yang cukup canggih (baca kisaran harga atau area operasi yang membenarkannya), setiap perangkat dapat dilengkapi dengan sertifikat klien yang memungkinkan pemeriksaan keaslian sinkronisasi.

Bagaimanapun dengan perangkat pelanggan akhir Anda akan selalu memiliki perangkat jatuh dari radar karena baterai sekarat, perangkat jatuh dari penggunaan atau hanya pelanggan mengubah kata sandi nirkabelnya dan tidak memberi tahu perangkat IoT. Mereka mungkin tidak harus melakukan apa pun dengan pembaruan Anda, bahkan jika mereka jatuh bersama waktu-bijaksana.

— Helmar
sumber

Saya tidak berpikir ini memberikan solusi untuk pertanyaan OP.

— WayToDoor

@WayToDoor paragraf pertama saya menyarankan untuk melakukan sinkronisasi langsung setelah pembaruan. Itu memberi informasi jika versi baru berhasil dicapai. Kemungkinan langkah-langkah balasan jika itu belum terlalu luas (dan tidak diminta). Sisa jawaban saya berkaitan dengan pemantauan versi di lapangan. Pertanyaan apa yang saya lewatkan?

— Helmar