Actualizaciones Over-the-Air (OTA) en aplicaciones de microcontroladores embebidos: Transferencias de diseño y lecciones aprendidas

Resumen

Muchos sistemas integrados se instalan en lugares de difícil o poco práctico acceso para un operador humano. Esto es especialmente cierto en el caso de las aplicaciones del Internet de las Cosas (IoT), que suelen desplegarse en grandes cantidades y con una autonomía limitada. Algunos ejemplos son los sistemas integrados que controlan la salud de una persona o una máquina. Estos retos, combinados con el rápido ciclo de vida del software, hacen que muchos sistemas deban admitir actualizaciones over-the-air (OTA). Una actualización OTA sustituye el software del microcontrolador o microprocesador del sistema integrado por un nuevo software. Aunque mucha gente está muy familiarizada con las actualizaciones OTA en sus dispositivos móviles, el diseño y la implementación en un sistema con recursos limitados conlleva muchos retos diferentes. En este artículo, describiremos varios diseños de software diferentes para las actualizaciones OTA y discutiremos sus ventajas y desventajas. Veremos cómo se pueden aprovechar las características de hardware de dos microcontroladores de muy bajo consumo en el software de actualización OTA.

Bloques de construcción

Servidor y cliente

Una actualización OTA sustituye el software actual de un dispositivo por otro nuevo, y el nuevo software se descarga de forma inalámbrica. En un sistema integrado, el dispositivo que ejecuta este software suele ser un microcontrolador. Un microcontrolador es un pequeño dispositivo informático con memoria, velocidad y consumo de energía limitados. Un microcontrolador suele contener un microprocesador (núcleo) y bloques de hardware digital para operaciones específicas (periféricos). Los microcontroladores de muy bajo consumo, que suelen consumir entre 30 μA/MHz y 40 μA/MHz en modo activo, son ideales para este tipo de aplicaciones. Utilizar dispositivos de hardware específicos en estos microcontroladores y colocarlos en modos de bajo consumo es una parte importante del diseño del software de actualización OTA. En la Figura 1 se muestra un ejemplo de sistema embebido que puede requerir actualizaciones OTA. Aquí vemos un microcontrolador conectado a una radio y a un sensor, que puede utilizarse en una aplicación IoT que recoge datos sobre el entorno utilizando el sensor y los transmite periódicamente utilizando la radio. Esta parte del sistema se llama nodo de borde o cliente y es el objetivo de la actualización OTA. La otra parte del sistema se llama nube o servidor y es el proveedor del nuevo software. El servidor y el cliente se comunican a través de una conexión inalámbrica mediante transceptores (radios).

¿Qué hace una aplicación informática?

Gran parte del proceso de actualización OTA consiste en transferir el nuevo software del servidor al cliente. El software se transfiere como una secuencia de bytes, después de ser convertido en formato binario desde el formato de origen. El proceso de conversión compila los archivos de código fuente (por ejemplo, c, cpp)y enlazarlos en un archivo ejecutable (por ejemplo exe, elf), entonces el ejecutable se convierte a un formato de archivo binario portátil (por ejemplo bin, hex). A alto nivel, estos formatos de archivo contienen una secuencia de bytes que pertenecen a una dirección concreta de la memoria del microcontrolador. En general, conceptualizamos la información enviada a través de un enlace inalámbrico como datos, como una orden para cambiar el estado del sistema o los datos de los sensores recogidos por el sistema. En el caso de la actualización OTA, los datos son el nuevo software en formato binario. En muchos casos, el archivo binario será demasiado grande para enviarlo en una sola transferencia del servidor al cliente, lo que significa que el archivo binario tendrá que colocarse en paquetes separados, en un proceso llamado paquetización. Para visualizar mejor este proceso, la Figura 2 muestra cómo las diferentes versiones del software producirán diferentes archivos binarios y, por tanto, diferentes paquetes para enviar durante la actualización OTA. En este sencillo ejemplo, cada paquete contiene 8 bytes de datos, y los primeros 4 bytes representan la dirección en la memoria del cliente para almacenar los siguientes 4 bytes

principales retos

Basándonos en esta descripción de alto nivel del proceso de actualización de la OTA, hay tres grandes retos que la solución de actualización de la OTA debe abordar. El primer reto se refiere a memoria. La solución de software deberá organizar la nueva aplicación de software en la memoria volátil o no volátil del dispositivo cliente para que pueda ser ejecutada cuando se complete el proceso de actualización. La solución deberá garantizar que se conserve una versión anterior del software como aplicación de respaldo en caso de que el nuevo software tenga problemas. Además, tenemos que hacer un seguimiento del estado del dispositivo cliente entre los reinicios y los ciclos de alimentación, como la versión del software que estamos ejecutando en ese momento y dónde se encuentra en la memoria. El segundo gran reto es comunicación El nuevo software debe enviarse desde el servidor al cliente en paquetes discretos, cada uno de ellos dirigido a una dirección concreta de la memoria del cliente. El esquema de paquetización, la estructura de los paquetes y el protocolo utilizado para transferir los datos deben tenerse en cuenta en el diseño del software. El último gran reto es seguridad. Como el nuevo software se envía de forma inalámbrica desde el servidor al cliente, tenemos que asegurarnos de que el servidor es una parte de confianza. Este reto de seguridad se conoce como autentificación. También tenemos que asegurarnos de que el nuevo software quede oculto para cualquier observador, ya que puede contener información sensible. Este reto de seguridad se conoce como confidencialidad El último elemento de la seguridad es la integridad, garantizar que el nuevo software no se corrompe cuando se envía por aire

El cargador de arranque de la segunda etapa (FOSS)

Comprender la secuencia de arranque

El cargador de arranque primario es una aplicación de software que reside permanentemente en el microcontrolador en una memoria de sólo lectura. La región de la memoria en la que reside el cargador de arranque primario se conoce como espacio de información y a veces no es accesible para los usuarios. Esta aplicación se ejecuta cada vez que se produce un reinicio, normalmente realizando alguna inicialización esencial del hardware, y puede cargar el software del usuario en la memoria. Sin embargo, si el microcontrolador contiene una memoria no volátil en el chip, como la memoria flash, el cargador de arranque no necesita realizar ninguna carga y simplemente transfiere el control al programa de la memoria flash. Si el gestor de arranque primario no admite actualizaciones OTA, se necesita un gestor de arranque de segunda fase. Al igual que el gestor de arranque principal, el SSBL se ejecutará siempre que se produzca un reinicio, pero implementará parte del proceso de actualización de la OTA. Esta secuencia de arranque se ilustra en la Figura 3. En esta sección, explicaremos por qué es necesario un cargador de arranque de segunda fase y cómo especificar el papel de esta aplicación es un compromiso de diseño clave.

Lección aprendida: tener siempre FOSS

Conceptualmente, puede parecer más sencillo omitir el SSBL y colocar toda la funcionalidad de actualización de la OTA en la aplicación del usuario, ya que así se aprovecharía sin problemas un marco de software, un sistema operativo y unos controladores de dispositivo ya existentes para el proceso de la OTA. El mapa de memoria y la secuencia de arranque de un sistema que eligió este enfoque se muestran en la Figura 4.

La aplicación A es la aplicación original que se despliega en el microcontrolador en el campo. Esta aplicación contiene el software relacionado con la actualización OTA, que se utiliza para descargar la aplicación B cuando el servidor lo solicita. Una vez completada la descarga y verificada la Aplicación B, la Aplicación A transfiere el control a la Aplicación B ejecutando una instrucción de bifurcación al manejador de reinicio de la Aplicación B. El controlador de reinicio es un pequeño fragmento de código que es el punto de entrada de la aplicación de software y se ejecuta durante el reinicio. En este caso, el reinicio se imita realizando una bifurcación, que equivale a una llamada a la función. Hay dos problemas importantes con este enfoque:

• Muchas aplicaciones de software embebido utilizan un sistema operativo en tiempo real (RTOS), que permite dividir el software en tareas concurrentes, cada una con diferentes responsabilidades en el sistema. Por ejemplo, la aplicación mostrada en la Figura 1 puede tener tareas de RTOS para leer el sensor, ejecutar un algoritmo sobre los datos del sensor e interactuar con la radio. El propio RTOS está siempre activo y se encarga de cambiar entre estas tareas basándose en eventos asíncronos o en retrasos específicos basados en el tiempo. Por lo tanto, no es seguro cambiar a un nuevo programa desde una tarea del RTOS, ya que otras tareas seguirán ejecutándose en segundo plano. La única forma segura de terminar un programa con un sistema operativo en tiempo real es realizar un reinicio.
• A partir de la Figura 4, una solución al problema anterior sería que el cargador de arranque principal pasara a la aplicación B en lugar de la aplicación A. Sin embargo, en algunos microcontroladores, el cargador de arranque principal siempre ejecuta el programa cuya tabla de vectores de interrupción (IVT), una parte clave de la aplicación que describe las funciones de gestión de las interrupciones, se encuentra en la dirección 0. Esto significa que se requiere alguna forma de reubicación de la IVT para tener un mapa de reposición a la aplicación B. Si se produce un ciclo de alimentación durante esta reubicación del IVT, podría dejar el sistema en un estado de ruptura permanente.

Estos problemas se mitigan teniendo un SSBL configurado en la dirección 0, como se muestra en la Figura 3. Como el SSBL es un programa que no tiene RTOS, puede cambiar con seguridad a una nueva aplicación. No hay riesgo de que un ciclo de alimentación ponga al sistema en un estado catastrófico, ya que el IVT del SSBL en la dirección 0 nunca se mueve.

El compromiso del diseño: el papel del SSBL

Hemos dedicado mucho tiempo a hablar del SSBL y su relación con el software de aplicación, pero ¿qué hace este programa SSBL? Como mínimo, el programa tiene que determinar cuál es la aplicación actual (dónde se inicia), y luego cambiar a esa dirección. La ubicación de las distintas aplicaciones en la memoria del microcontrolador suele guardarse en una tabla de contenidos (ToC), como se muestra en la Figura 3. Se trata de una región compartida de memoria persistente que el FOSS y el software de la aplicación utilizan para comunicarse entre sí. Cuando el proceso de actualización de la OTA finaliza, la TdC se actualiza con la nueva información de la aplicación. Parte de la funcionalidad de la actualización OTA también puede ser empujada a FOSS. La elección de las porciones es una importante decisión de diseño al desarrollar el software de actualización OTA. El SSBL mínimo descrito anteriormente será extremadamente sencillo, fácil de verificar y lo más probable es que no requiera ningún cambio durante la vida de la aplicación. Sin embargo, esto significa que cada aplicación debe ser responsable de descargar y verificar la siguiente aplicación. Esto puede llevar a la duplicación de código en la pila de radio, el firmware del dispositivo y el software de actualización OTA. Por otro lado, podemos optar por empujar todo el proceso de actualización OTA a FOSS. En este escenario, las aplicaciones simplemente establecen una bandera en la TdC para solicitar una actualización y luego realizan un reinicio. A continuación, el FOSS realiza la secuencia de descarga y el proceso de verificación. Esto minimizará la duplicación de código y simplificará el software específico de la aplicación. Sin embargo, introduce el nuevo reto de tener que actualizar el propio FOSS (es decir, actualizar el código de actualización). En última instancia, la elección de qué funcionalidad colocar en el SSBL dependerá de las limitaciones de memoria del dispositivo cliente, la similitud entre las aplicaciones descargadas y la portabilidad del software de actualización OTA.

Compromisos de diseño: caché y compresión

Otra decisión de diseño clave en el software de actualización OTA será cómo organizar la aplicación entrante en la memoria durante el proceso de actualización OTA. Los dos tipos de memoria que suelen encontrarse en un microcontrolador son la memoria no volátil (por ejemplo, la memoria flash) y la memoria volátil (por ejemplo, la SRAM). La memoria flash se utilizará para almacenar el código de programa y los datos de sólo lectura de una aplicación, así como otros datos a nivel de sistema, como las TdC y un registro de eventos. La SRAM se utilizará para almacenar las partes modificables de la aplicación de software, como las variables globales no constantes y la pila. El binario de la aplicación de software que se muestra en la Figura 2 sólo contiene la parte del programa que vive en la memoria no volátil. La aplicación inicializará las partes que pertenecen a la memoria volátil durante una rutina de arranque.

Durante el proceso de actualización de la OTA, siempre que el dispositivo cliente reciba un paquete del servidor que contenga parte del binario, éste se almacenará en la SRAM. Este paquete puede estar comprimido o sin comprimir. La ventaja de comprimir el binario de la aplicación es que será más pequeño, lo que permite enviar menos paquetes y reducir el espacio necesario en la SRAM para almacenarlos durante el proceso de descarga. La desventaja de este enfoque es el tiempo de procesamiento adicional que la compresión y la descompresión añaden al proceso de actualización, así como la necesidad de agrupar el código relacionado con la compresión en el software de actualización OTA.

Como el nuevo software de aplicación pertenece a la memoria flash, pero llega a la SRAM durante el proceso de actualización, el software de actualización OTA tendrá que realizar una escritura en la memoria flash en algún momento del proceso de actualización. Almacenar temporalmente la nueva aplicación en la SRAM se llama caché. A alto nivel, hay tres enfoques diferentes que el actualizador OTA puede adoptar para el almacenamiento en caché.

• Sin almacenamiento en caché: Cada vez que llegue un paquete que contenga parte de la nueva aplicación, escríbelo en su destino en la memoria flash. Este esquema es extremadamente sencillo y minimizará la cantidad de lógica en el actualizador OTA, pero requiere que la región de memoria flash para la nueva aplicación se borre completamente. Este método utiliza la memoria flash y añade una sobrecarga.
• Caché parcial: Reserva una región de la SRAM para el caché y, cuando llegan nuevos paquetes, los almacena en esa región. Cuando la región se llene, vacíala escribiendo los datos en la memoria flash. Esto puede resultar complejo si los paquetes llegan fuera de orden o si hay huecos en el nuevo binario de la aplicación, ya que se necesita un método para hacer coincidir las direcciones de la SRAM con las de la flash. Una estrategia es hacer que la caché actúe como un espejo de parte de la memoria flash. La memoria flash está dividida en pequeñas regiones llamadas páginas, que son la división más pequeña para el borrado. Debido a esta división natural, un buen enfoque es almacenar en caché una página de la memoria flash en la SRAM y, cuando se llene o el siguiente paquete pertenezca a una página diferente, vaciar la caché escribiendo esa página en la memoria flash.
• Caché completo: almacena toda la nueva aplicación en la SRAM durante el proceso de actualización de la OTA y sólo la escribe en la flash cuando se ha descargado completamente del servidor. Este enfoque supera las desventajas de los enfoques anteriores al minimizar el número de escrituras en la memoria flash y evitar la compleja lógica de almacenamiento en caché en el software de actualización OTA. Sin embargo, impone un límite al tamaño de la nueva aplicación descargada, ya que la cantidad de SRAM disponible en el sistema suele ser mucho menor que la cantidad de memoria flash disponible.

El segundo esquema de caché parcial durante una actualización OTA se muestra en la Figura 5, donde se amplía la parte de memoria flash para la aplicación A de las Figuras 3 y 4 y se muestra un mapa de memoria SRAM funcional para el SSBL. Se muestra un ejemplo de un tamaño de página flash de 2 kB. En última instancia, esta decisión de diseño vendrá determinada por el tamaño de la nueva aplicación y la complejidad permitida del software de actualización OTA.

Seguridad y comunicación

Compromisos de diseño: software vs. protocolo

La solución de actualización OTA también debe tener en cuenta la seguridad y la comunicación. Muchos sistemas como el de la Figura 1 tendrán un protocolo de comunicación implementado en hardware y software para el comportamiento normal del sistema (no relacionado con la actualización OTA), como el intercambio de datos de los sensores. Esto significa que hay un método de comunicación inalámbrica (posiblemente seguro) ya establecido entre el servidor y el cliente. Los protocolos de comunicación que podría utilizar un sistema empotrado como el de la figura 1 serían, por ejemplo, Bluetooth^® Baja energía (BLE) o 6LoWPAN. Estos protocolos a veces soportan la seguridad y el intercambio de datos que el software de actualización OTA puede explotar durante el proceso de actualización OTA

La cantidad de funcionalidad de comunicación que debe incorporarse al software de actualización OTA vendrá determinada, en última instancia, por el grado de abstracción que ofrezca el protocolo de comunicación existente. El protocolo de comunicación existente dispone de facilidades para el envío y la recepción de archivos entre el servidor y el cliente que el software de actualización OTA puede aprovechar simplemente para el proceso de descarga. Sin embargo, si el protocolo de comunicación es más primitivo y sólo permite el envío de datos en bruto, el actualizador de la OTA puede tener que realizar alguna paquetización y proporcionar metadatos con el nuevo binario de la aplicación. Esto también se aplica a los retos de seguridad. Puede ser responsabilidad del actualizador de la OTA descifrar los bytes enviados por el aire para garantizar la confidencialidad si el protocolo de comunicación no lo admite.

En conclusión, la integración de funciones como la estructura de paquetes personalizada, la sincronización servidor/cliente, la encriptación y el intercambio de claves en el software de actualización OTA vendrá determinada por lo que ofrezca el protocolo de comunicación del sistema y los requisitos de seguridad y solidez. En la siguiente sección, propondremos una solución de seguridad completa que resuelva todos los retos presentados anteriormente y mostraremos cómo explotar el dispositivo de hardware criptográfico de un microcontrolador en esta solución.

Resolver los retos de seguridad

Nuestra solución de seguridad debe preservar la confidencialidad de la nueva aplicación enviada por el aire, detectar cualquier corrupción de la nueva aplicación y verificar que la nueva aplicación fue enviada por un servidor de confianza y no por una parte maliciosa. Estos retos pueden resolverse mediante operaciones criptográficas. Más concretamente, en la solución de seguridad se pueden utilizar dos operaciones criptográficas conocidas como encriptación y hashing. El cifrado utilizará una clave compartida (contraseña) entre el cliente y el servidor para ofuscar los datos que se envían de forma inalámbrica. Un tipo específico de encriptación que puede soportar el acelerador de hardware de encriptación del microcontrolador se llama AES-128 o AES-256, según el tamaño de la clave. Con los datos encriptados, el servidor puede enviar un compendio para asegurarse de que no hay corrupción. El compendio se genera mediante el hash del paquete de datos, una función matemática irreversible que genera un código único. Si alguna parte del mensaje o del compendio se modifica después de que el servidor lo haya creado, como un bit invertido durante la comunicación inalámbrica, el cliente se dará cuenta de este cambio cuando ejecute la misma función hash en el paquete de datos y compare los compendios. Un tipo específico de hash que el acelerador de hardware criptográfico del microcontrolador puede soportar es el SHA-256. La figura 6 muestra un diagrama de bloques de un dispositivo de hardware criptográfico en el microcontrolador, con el software de actualización OTA residiendo en el Cortex^®-Capa de aplicación M4. Esta figura también muestra la compatibilidad con el almacenamiento de claves protegidas en el dispositivo, que puede aprovecharse en la solución de software de actualización OTA para almacenar de forma segura las claves del cliente.

Una técnica habitual para resolver el último reto de autenticación es utilizar la encriptación asimétrica. Para esta operación, el servidor genera un par de claves públicas y privadas. La clave privada sólo la conoce el servidor y la clave pública la conoce el cliente. Utilizando la clave privada, el servidor puede generar una firma para un bloque de datos determinado, como el compendio del paquete que se enviará por aire. La firma se envía al cliente, que puede verificar la firma utilizando la clave pública. Esto permite al cliente confirmar que el mensaje fue enviado por el servidor y no por un tercero malicioso. Esta secuencia se ilustra en la Figura 7, con las flechas sólidas que representan la entrada/salida de la función y las flechas de puntos que muestran la información que se envía por el aire.

La mayoría de los microcontroladores no disponen de un acelerador de hardware para estas operaciones de encriptación asimétrica, pero pueden implementarse utilizando bibliotecas de software como Micro-ECCque se dirige específicamente a los dispositivos con recursos limitados. La biblioteca requiere una función de generación de números aleatorios definida por el usuario, que puede implementarse utilizando el dispositivo hardware generador de números aleatorios real del microcontrolador. Aunque estas operaciones de encriptación asimétrica resuelven el reto de la confianza durante una actualización de la OTA, son costosas en términos de tiempo de procesamiento y requieren que se envíe una firma con los datos, lo que aumenta el tamaño del paquete. Podríamos hacer esta verificación una vez al final de la descarga, utilizando un compendio del último paquete o el compendio de toda la nueva aplicación de software, pero esto permitiría a terceros descargar software no fiable en el cliente, lo que no es ideal. Idealmente, queremos verificar que cada paquete que recibimos procede de nuestro servidor de confianza sin la sobrecarga de una firma cada vez. Esto se puede conseguir utilizando una cadena de hash

Una cadena hash incorpora los conceptos criptográficos que hemos tratado en esta sección en una serie de paquetes para enlazarlos matemáticamente. Como se muestra en la Figura 8, el primer paquete (número 0) contiene el resumen del siguiente paquete. En lugar de los datos reales de la aplicación informática, la carga útil del primer paquete es la firma. La carga útil del segundo paquete (número 1) contiene parte del binario y el resumen del tercer paquete (número 2). El cliente comprueba la firma del primer paquete y almacena en caché el compendio, H0, para su uso posterior. Cuando llega el segundo paquete, el cliente hace un hash de la carga útil y la compara con H0. Si coinciden, el cliente puede estar seguro de que el siguiente paquete procede del servidor de confianza sin tener que realizar una comprobación de la firma. La costosa tarea de generar esta cadena se deja en manos del servidor, y el cliente debe limitarse a almacenar en caché y hacer un hash de cada paquete entrante para asegurarse de que los paquetes llegan sin corromper, con integridad y autentificados.

Configuración experimental

Los microcontroladores de ultrabajo consumo que resuelven los problemas de memoria, comunicación y seguridad mencionados en este artículo son el ADuCM3029 y el ADuCM4050. Estos microcontroladores contienen los periféricos de hardware comentados a lo largo del artículo para las actualizaciones OTA, como la memoria flash, la SRAM, el acelerador criptográfico y un verdadero generador de números aleatorios. El sitio paquetes de la familia de dispositivos (DFP) para estos microcontroladores proporcionan soporte de software para crear una solución de actualización OTA en estos dispositivos. El DFP contiene controladores de dispositivos que proporcionan interfaces sencillas y flexibles para utilizar el hardware

Configuración del hardware

Para verificar y validar los conceptos aquí expuestos, se creó un diseño de referencia de software de actualización OTA utilizando el ADuCM4050. Para el cliente, un ADuCM4050 EZ-KIT^® se conecta a un ADF7242 mediante el conector de herradura de la placa secundaria del transceptor. El dispositivo cliente se muestra a la izquierda en la Figura 9. Para el servidor, se ha desarrollado una aplicación Python que se ejecuta en un PC con Windows. La aplicación Python se comunica a través del puerto serie con otro EZ-KIT ADuCM4050 al que también se ha conectado un ADF7242 en la misma disposición que el cliente. Sin embargo, el EZ-KIT de la derecha en la Figura 9 no realiza ninguna lógica de actualización OTA y se limita a transmitir los paquetes recibidos del ADF7242 a la aplicación Python.

Componentes de software

El diseño de referencia del software particiona la memoria flash del dispositivo cliente como se muestra en la Figura 3. La aplicación principal del cliente se ha diseñado para que sea muy portátil y configurable, de modo que pueda funcionar en otros diseños o en otras plataformas de hardware. La figura 10 muestra la arquitectura de software del dispositivo cliente. Nota: Aunque a veces nos referimos a toda esta aplicación como FOSS, en la Figura 10 y a partir de ahora separamos lógicamente la parte FOSS propiamente dicha (en azul) de la parte de actualización de la OTA (en rojo), ya que esta última no tiene por qué implementarse íntegramente en la misma aplicación, como hemos visto antes. La capa de abstracción del hardware que se muestra en la Figura 10 permite que el software del cliente OTA sea portátil e independiente de cualquier biblioteca subyacente (mostrada en naranja).

La aplicación informática implementa la secuencia de inicio de la Figura 3, un sencillo protocolo de comunicación para descargar la nueva aplicación desde el servidor, y la cadena hash. Cada paquete del protocolo de comunicación tiene una cabecera de metadatos de 12 bytes, una carga útil de 64 bytes y un resumen de 32 bytes. Además, tiene las siguientes características:

• Almacenamiento en caché: Soporte para no almacenar en caché o para almacenar en caché una página flash, dependiendo de la configuración del usuario.
• El índice de contenidos: El índice de contenidos está diseñado para contener sólo dos aplicaciones, y la nueva aplicación siempre se descarga en la ubicación más antigua, con el fin de mantener una aplicación de reserva. Esto se llama esquema de actualización A/B.
• Mensajería: Soporte para el ADF7242 o la UART para la mensajería, según la configuración del usuario. El uso de la UART para la mensajería elimina el EZ-KIT de la izquierda en la Figura 9, dejando el kit de la derecha para el cliente. Este esquema de actualización de cables es útil para la puesta en marcha y depuración inicial del sistema.

Resultados

Además de cumplir los requisitos funcionales y superar las distintas pruebas, el rendimiento del software también es fundamental para determinar el éxito del proyecto. Dos métricas utilizadas habitualmente para medir el rendimiento del software embebido son la huella y los ciclos. La huella se refiere al espacio que la aplicación de software ocupa en la memoria volátil (SRAM) y no volátil (flash). Los ciclos se refieren al número de ciclos de reloj del microprocesador que el software utiliza para realizar una tarea específica. Aunque es similar al tiempo de ejecución del software, tiene en cuenta que el software puede entrar en modos de bajo consumo durante la actualización OTA, en los que el microprocesador está inactivo y no se consumen ciclos. Aunque el diseño de referencia del software no se ha optimizado para ninguna de estas medidas, son útiles para evaluar el programa y comparar las compensaciones del diseño

La Figura 11 y la Figura 12 muestran la huella del diseño de referencia del software de actualizaciones OTA implementado en el ADuCM4050 sin caché. Las cifras se dividen según los componentes que se muestran en la Figura 10. Como se muestra en la Figura 11, toda la aplicación utiliza unos 15 KB de memoria flash. Esto es bastante pequeño teniendo en cuenta que el ADuCM4050 contiene 512 kB de memoria flash. El software de aplicación propiamente dicho (el desarrollado para el proceso de actualización de la OTA) sólo ocupa unos 1,5 kB, el resto se utiliza para bibliotecas como la pila DFP, el Micro-ECC y el ADF7242. Estos resultados ayudan a ilustrar el compromiso de diseño respecto al papel que debe tener el software libre en el sistema. La mayor parte de los 15 kB que ocupan es para el proceso de actualización. El SSBL en sí mismo sólo ocupa unos 500 bytes de espacio, con 1 kB a 2 kB adicionales de código DFP para el acceso al dispositivo, como el controlador de la flash

Para evaluar la sobrecarga del software, realizamos un recuento de ciclos cada vez que se recibe un paquete de datos y luego examinamos el número medio de ciclos consumidos por paquete. Cada paquete de datos requiere descifrado AES-128, hashing SHA-256, escritura en la memoria flash y cierta validación de los metadatos del paquete. Con un tamaño de la carga útil del paquete de 64 bytes y sin caché, la sobrecarga es de 7409 ciclos para procesar un solo paquete de datos. Utilizando un reloj central de 26 MHz, esto representa aproximadamente 285 microsegundos de tiempo de procesamiento. Este valor se ha calculado utilizando el controlador de recuento de ciclos del DFP ADuCM4050 (ciclos no ajustados) y representa la media tomada durante una descarga binaria de 100 kB (aproximadamente 1500 paquetes). La mínima sobrecarga por paquete puede atribuirse al hecho de que los controladores DFP explotan el dispositivo de hardware de acceso directo a la memoria (DMA) del ADuCM4050 durante las transacciones del bus y a que los controladores colocan el procesador en un estado de reposo de bajo consumo durante cada transacción. Si desactivamos el uso del estado de reposo de bajo consumo en el DFP y cambiamos las transacciones del bus para que no utilicen DMA, la sobrecarga por paquete de datos aumenta a 17.297 ciclos. Esto ilustra el impacto del uso eficiente de los controladores de dispositivos en una aplicación de software embebido. Aunque la sobrecarga también se mantiene baja al utilizar un pequeño número de bytes de datos por paquete, al duplicar el número de bytes de datos por paquete a 128 sólo se produce un pequeño aumento de ciclos, 8362 ciclos para el mismo experimento

Los ciclos y la huella también ilustran la compensación comentada anteriormente de almacenar en caché los datos por paquete en lugar de escribir en la memoria flash cada vez. Al activar una página de caché flash, la necesidad de espacio por paquete de datos se reduce de 7409 a 5904 ciclos. Esta reducción del 20% proviene de la capacidad de evitar la escritura en flash para la mayoría de los paquetes y sólo realizar una escritura en flash cuando la caché está llena. Esta reducción se produce a costa de la huella de la SRAM. Sin caché, HAL sólo necesita 336 bytes de SRAM, como se muestra en la Figura 12. Sin embargo, cuando se utiliza la memoria caché, debemos reservar un espacio equivalente a una página completa de memoria flash, lo que aumenta el uso de SRAM a 2388 bytes. El uso de la memoria flash de la HAL también aumenta un poco debido al código adicional necesario para determinar cuándo debe vaciarse la caché.

Estos resultados demuestran el impacto tangible de las decisiones de diseño en el rendimiento del software. No hay una solución única para todos: cada sistema tendrá requisitos y limitaciones diferentes, y el software de actualización OTA tendrá que ajustarse a ellos. Esperamos que este artículo haya arrojado algo de luz sobre los problemas comunes y las compensaciones a las que te has enfrentado al diseñar, implementar y validar una solución de software de actualización OTA.

Referencias

Nilsson, Dennis Kengo y Ulf E. Larson. "Actualizaciones seguras de firmware en vehículos inteligentes." ICC-2008 Conferencia Internacional del IEEE sobre Talleres de Comunicaciones, mayo de 2008.