Prueba del éxito de las actualizaciones Over the Air [cerrado]

10

¿Cuál es la mejor práctica para garantizar que un dispositivo IoT se haya actualizado correctamente?

¿Qué debe hacer para probar las actualizaciones de OTA y autenticar dispositivos? Dando un paso más allá, ¿cómo puede monitorear / administrar las versiones de software (actualizaciones) de una flota de dispositivos IoT?

testing authentication over-the-air-updates Noam Hacker
fuente
1
Esto es demasiado amplio, como su otra pregunta. Y dependerá mucho del tipo de dispositivo y modo de implementación.
Gilles 'SO- deja de ser malvado'
1
Cuando dices "flota", ¿te refieres a una flota de vehículos? Si es así, presumo la comunicación por SMS (encriptado), o HTTPS a través de GPRS, o satélite de eventos, usando algo como un módem SkyWave. Si puede editar su pregunta para aclararla, estoy seguro de que se volverá a abrir.
Mawg dice que reinstale a Mónica el

Respuestas:

10

Tengo un software (Windows Server, un poco diferente a 'cosas' pero el principal es el mismo) que llama cada 24 horas; envía varios metadatos sobre sí mismo:

  • nombre del cliente (o identificación única)
  • Versión del software
  • marca de tiempo de llamada / solicitud
  • tipo de producto / id

El servicio web analiza los datos e inserta (o actualiza si el cliente tiene una fila existente) una fila en una base de datos.

De esta forma, los nuevos clientes se agregan automáticamente a la base de datos, los clientes existentes actualizan su marca de tiempo "visto por última vez" y siempre tenemos su última versión de software. Puedo ejecutar consultas DB que me dicen qué clientes están en versiones anteriores y / o qué clientes no han llamado por un tiempo.

También implementamos una actualización automática (piense en la actualización OTA) recientemente y debido a que este es un proceso crítico, implementamos una telemetría específica para esto, que registra:

  • Versión actual.
  • Versión a actualizar.
  • Quién / cuándo lo autorizó (si se requiere la aceptación del cliente).
  • Marcas de tiempo y códigos de estado para cada uno de los pasos principales.

Esto nos permite determinar si ciertos aspectos de la actualización automática están fallando y, en muchos casos, nos permite llamar al cliente a menudo antes de que noten que algo está mal.

La gran diferencia con las 'cosas' es que normalmente tiene limitaciones de memoria, por lo que para realizar una actualización OTA xxx Kbde firmware necesita xxx Kb * 2memoria disponible (firmware existente + memoria suficiente para almacenar nuevo firmware antes de comenzar la actualización real del firmware)

KennetRunner
fuente
1
gracias por compartir. El uso de la memoria es un punto importante que hacer. ¿Cómo se realiza la autorización y la aceptación del cliente, cuando corresponde? ¿Necesita una contraseña para aceptar una actualización?
Noam Hacker
2
Es un caso de uso diferente (porque es Windows Server), pero tenemos una interfaz de usuario que muestra una alerta cuando se ha descargado la actualización OTA: la alerta le pregunta al cliente si desea actualizar (e incluye enlaces a las notas de la versión, etc.). En un thingyo probablemente un flash de LED o algo para alertar al usuario (suponiendo que desea que el usuario 'permitir' la actualización) y luego tenerlos 'pulsación larga' un botón para empezar ...
KennetRunner
5

Podría, por ejemplo, hacer una solicitud cada X semanas / días / horas ... a un servidor con el número de versión actual del software. Luego podrá usar análisis para ver el porcentaje actual y la cantidad de dispositivos actualizados.

WayToDoor
fuente
1
¿Esto tiene en cuenta los dispositivos que se han bloqueado o no han podido completar una actualización (tal vez atascado en un reinicio, descarga, ciclo de bloqueo?)
Sean Houlihane
1
En cierto modo, sí. Si tienes 100 dispositivos en el día 1, envías la actualización en el día 2, y el día 3 solo tienes 25 dispositivos en análisis, significa que sucedió algo malo
WayToDoor
1
eso es interesante. ¿Hay alguna manera de diferenciar entre tipos de fallas?
Noam Hacker
1
dividir la actualización en pasos discretos (por ejemplo, añadir nuevos valores de configuración , gps reinicio , programar una ID de dispositivo , el firmware de sobreescritura , etc) y cada una tiene un empezando .. llamada de envío 'casa' y una completa con xx estado de la casa llamada enviada. De esa manera puede saber (aproximadamente) dónde falló y (con suerte) cuál fue el código de estado.
KennetRunner
4

Se trata de una política de sincronización inteligente

Necesita una política de sincronización inteligente que funcione en conjunto con su enfoque de implementación de su actualización. El momento más obvio en el que el dispositivo IoT debe sincronizar su versión es directamente después de la actualización . El resto de la programación de sincronización depende en gran medida del tipo de dispositivo.

¿Está siempre encendido y conectado a través de una conexión por cable donde una sola sincronización no cuesta (mucho) tiene sentido sincronizar periódicamente para mantener sus datos sobre el dispositivo actual.

Si el dispositivo está en algún lugar donde todo es costoso porque está utilizando costosas conexiones satelitales, el programa de sincronización tiene que adaptarse a esa circunstancia.

Verificación de la sincronización

En un dispositivo suficientemente avanzado (lea un rango de precios o un área de operación que lo justifique) cada dispositivo podría estar equipado con un certificado de cliente que permita una verificación de autenticidad de la sincronización.

De todos modos, con los dispositivos de los clientes finales , siempre tendrá dispositivos que no se verán en el radar debido a baterías agotadas, que el dispositivo se caiga o simplemente que el cliente cambie su contraseña inalámbrica y no informe al dispositivo IoT. Es posible que no tengan que hacer nada con su actualización, incluso si se unen en el tiempo.

Helmar
fuente
No creo que esto dé una solución a la pregunta del OP.
WayToDoor
@WayToDoor mi primer párrafo aconseja sincronizar directamente después de la actualización. Eso proporciona la información si la nueva versión se alcanzó con éxito. Las posibles contramedidas si ese no ha sido el caso son demasiado amplias (y no se solicitan). El resto de mi respuesta trata de monitorear las versiones en el campo. ¿Qué pregunta me perdí?
Helmar