Şebeke üzerinden güncellemelerin başarısını test etme [kapalı]

10

Bir IoT cihazının başarıyla güncellendiğinden emin olmak için en iyi uygulama nedir?

OTA güncellemelerini test etmek ve cihazların kimliğini doğrulamak için ne yapmanız gerekir? Bir adım daha ileri giderek, bir IoT cihazı filosunun yazılım sürümlerini (güncellemeleri) nasıl izleyebilir / yönetebilirsiniz?

testing authentication over-the-air-updates

— Noam Hacker
kaynak

1

Bu, diğer sorunuz gibi çok geniş. Ve bu, cihazın türüne ve dağıtım moduna çok bağlı olacaktır.

— Gilles 'SO- kötü olmayı bırak'

1

"Filo" derken araç filosu mu demek istediniz? Eğer öyleyse, SkyWave modem gibi bir şey kullanarak (şifrelenmiş) SMS veya GPRS üzerinden HTTPS veya olay uydusu ile iletişim olduğunu varsayıyorum. sorunuzu açıklığa kavuşturmak için düzenleyebiliyorsanız, yeniden açılacağından eminim.

— Mawg, Monica'nın

10

Her 24 saatte bir çağrı yapan yazılım (Windows Server - 'şeyler' biraz farklı ama ana aynıdır) var - kendisi hakkında çeşitli meta verileri geri gönderir:

müşteri adı (veya benzersiz kimlik)
yazılım versiyonu
çağrı / talep zaman damgası
ürün tipi / kimliği

Web hizmeti verileri ayrıştırır ve veritabanına bir satır ekler (veya müşterinin mevcut bir satırı varsa günceller).

Bu şekilde yeni müşteri otomatik olarak DB'ye eklenir, mevcut müşteriler 'son görülen' zaman damgasını günceller ve her zaman en son yazılım sürümüne sahibiz. Hangi müşterilerin eski sürümlerde olduğunu ve / veya bir süredir aramadıkları DB sorgularını çalıştırabilirim.

Ayrıca son zamanlarda bir otomatik güncelleme uyguladık (OTA güncellemesini düşünün) ve bu kritik bir süreç olduğundan, bunun için belirli bir telemetri uyguladık - aşağıdakileri kaydeder:

Şimdiki versiyonu.
Güncellenecek sürüm.
Kim / ne zaman yetkilendirilir (müşteri kabulü gerekiyorsa).
Önemli adımların her biri için zaman damgaları ve durum kodları.

Bu, otomatik güncellemenin belirli yönlerinin başarısız olup olmadığını belirlememizi sağlar ve çoğu durumda bir şeylerin yanlış olduğunu fark etmeden önce müşteriyi sık sık aramamızı sağlar.

'Şeyler' ile en büyük fark, tipik olarak bellek kısıtlı olmanızdır, bu nedenle mevcut belleğe xxx Kbihtiyacınız xxx Kb * 2olan bellenimin OTA güncellemesini yapmak için (mevcut bellenim + gerçek bellenim güncellemesine başlamadan önce yeni bellenimi depolamak için yeterli bellek)

— KennetRunner
kaynak

1

paylaşım için teşekkürler. Bellek kullanımı önemli bir noktadır. Uygulanabilir olduğunda, yetkilendirme ve müşteri kabulü hakkında ne düşünüyorsunuz? Güncellemeyi kabul etmek için bir şifreye mi ihtiyacınız var?

— Noam Hacker

2

Bu farklı bir kullanım örneğidir (Windows Server olduğu için), ancak OTA güncellemesi indirildiğinde uyarı veren bir kullanıcı arayüzümüz var - uyarı müşteriye güncellemek isteyip istemediklerini sorar (ve sürüm notlarına bağlantılar içerir). Üzerinde thingmuhtemelen bir LED ya da kullanıcıyı uyarmak için bir şey yanıp söner (kullanıcının güncellemeye 'izin vermesini' istediğinizi varsayarsak) ve ardından başlatmak için bir düğmeye 'uzun basması' ...

— KennetRunner

5

Örneğin, yazılımın geçerli sürüm numarasına sahip bir sunucuya her X haftada / gün / saatte bir istekte bulunabilirsiniz. Güncellenen cihaz yüzdesini ve sayısını görmek için analitiği kullanabileceksiniz.

— WayToDoor
kaynak

1

Bu, tuğla haline getirilmiş veya bir güncellemeyi tamamlayamayan cihazlar için mi (belki bir yeniden başlatma, indirme, çökme döngüsünde sıkışmış?)

— Sean Houlihane

1

Bir bakıma, evet. 1. günde 100 cihazınız varsa, 2. günde güncellemeyi

— itersiniz

1

ilginç. Arıza türleri arasında ayrım yapmanın bir yolu var mı?

— Noam Hacker

1

güncellemeyi ayrı adımlara bölün (örn. yeni yapılandırma değerleri ekleyin , gps'i yeniden başlatın , cihaz kimliğini ayarlayın , bellenimin üzerine yazın , vb.) her biri bir başlangıç gönderir. "home" çağrısı ve home xx çağrısı tamamlandı . Bu şekilde (kabaca) nerede başarısız olduğunu ve (umarım) durum kodunun ne olduğunu söyleyebilirsiniz.

— KennetRunner

4

Her şey akıllı bir senkronizasyon politikası ile ilgili

Güncellemenizin kullanıma sunma yaklaşımınızla birlikte çalışan akıllı bir senkronizasyon politikasına ihtiyacınız var. IoT cihazının sürümünü senkronize etmesi gereken en açık nokta güncelleme sonrasındadır . Senkronizasyon zamanlamasının geri kalanı büyük ölçüde cihazın türüne bağlıdır.

Her zaman açık ve tek bir senkronizasyonun (çok fazla) maliyetinin olmadığı kablo bağlantısıyla bağlı mı?

Cihaz pahalı bir uydu bağlantısı kullandığınız için her bitin maliyeti yüksekse, senkronizasyon programı bu duruma uymalıdır.

Senkronizasyonun doğrulanması

Yeterince gelişmiş bir cihazda (bunu haklı kılacak bir fiyat aralığını veya çalışma alanını okuyun) her cihaz, senkronizasyonun orijinal kontrolünü sağlayan bir istemci sertifikası ile donatılabilir.

Her neyse, son müşteri cihazlarına sahip cihazlar, pillerin bitmesi , cihazın kullanımdan düşmesi veya sadece müşterinin kablosuz şifresini değiştirmesi ve IoT cihazını bilgilendirmemesi nedeniyle radardan düşecektir. Bunlar, zamanlama açısından bir araya gelseler bile, güncellemenizle hiçbir şey yapmak zorunda kalmayabilirler.

— Helmar
kaynak

Bunun OP sorununa bir çözüm getireceğini düşünmüyorum.

— WayToDoor

@WayToDoor ilk paragrafım güncellemeden sonra doğrudan senkronize etmenizi önerir. Bu, yeni sürüme başarıyla erişildiyse bilgileri verir. Durum böyle değilse olası karşı önlemler çok geniştir (ve istenmemiştir). Cevabımın geri kalanı sahadaki sürümlerin izlenmesiyle ilgilidir. Hangi soruyu kaçırdım?

— Helmar