Actualizaciones OTA en productos electrónicos

Un producto electrónico conectado puede necesitar actualizar su firmware muchas veces a lo largo de su vida útil. Una actualización puede servir para corregir un error, incorporar una nueva funcionalidad, mejorar el rendimiento o solucionar una vulnerabilidad de seguridad.

Cuando el equipo está instalado en una fábrica, una máquina, un vehículo o una infraestructura remota, acceder físicamente a cada unidad para realizar estas actualizaciones puede resultar costoso o directamente inviable. Por eso, las actualizaciones OTA (Over The Air) se han convertido en una función cada vez más habitual en dispositivos IoT y equipos electrónicos conectados.

Pero incorporar OTA no consiste únicamente en añadir una función al firmware.

El hardware también debe estar preparado para recibir, almacenar, verificar e instalar nuevas versiones del software. La capacidad de memoria, el almacenamiento disponible, la conectividad, la alimentación y determinados mecanismos de recuperación pueden condicionar la arquitectura del producto desde las primeras fases del desarrollo.

Una función de software que empieza en el hardware

Imaginemos un equipo que se diseña hoy con una primera versión de firmware perfectamente dimensionada. Si la memoria se selecciona pensando únicamente en esa versión, puede no quedar suficiente espacio cuando el software incorpore nuevas funciones dentro de unos años.

Algo similar puede ocurrir con la conectividad. Un dispositivo puede disponer de una conexión suficiente para enviar pequeñas cantidades de datos, pero necesitar mucho más tiempo para descargar una actualización completa. Si además funciona con batería, el consumo durante el proceso también pasa a ser una variable de diseño.

Por eso, una estrategia OTA debe plantearse junto con la arquitectura electrónica del producto, y no cuando el hardware ya está cerrado. Esta planificación forma parte de un enfoque de diseño orientado a crear productos electrónicos preparados para el futuro.

Diseñar un producto preparado para OTA significa reservar capacidad para su evolución futura.

Este enfoque es especialmente importante en productos industriales y dispositivos IoT que deben permanecer desplegados durante largos periodos. En estos casos, el coste de acceder físicamente a cada equipo puede ser muy superior al esfuerzo adicional realizado durante el diseño inicial.

Una actualización OTA permite instalar una nueva versión del firmware de un dispositivo utilizando una conexión de comunicación, sin necesidad de acceder físicamente al equipo.

De forma simplificada, el proceso puede representarse así:

Servidor → Red → Dispositivo → Almacenamiento → Verificación → Instalación → Nueva versión

El servidor proporciona la actualización y el dispositivo la recibe a través de la conectividad disponible. Antes de utilizarla, el sistema debe comprobar que los datos recibidos son válidos y, dependiendo de la arquitectura, verificar también su autenticidad e integridad.

Una vez completadas estas comprobaciones, el equipo puede instalar la nueva versión y reiniciarse utilizando el firmware actualizado.

Un ejemplo de esto se puede ver en la documentación sobre actualizaciones OTA de Espressif.

Descargar un firmware no es suficiente

El proceso parece sencillo desde fuera, pero una actualización OTA plantea varias situaciones que el diseño debe contemplar.

¿Qué ocurre si la conexión se interrumpe durante la descarga? ¿Y si se pierde la alimentación mientras se está escribiendo la memoria? ¿Dónde se almacena temporalmente la nueva versión? ¿Cómo puede volver el dispositivo a la versión anterior si la actualización no funciona correctamente?

Estas preguntas hacen que OTA deje de ser simplemente una característica del firmware y pase a convertirse en una decisión de arquitectura del sistema.

En un producto bien diseñado, el proceso debe contemplar tanto el funcionamiento normal como los posibles fallos durante la actualización. El objetivo no es solamente conseguir que una nueva versión se instale correctamente, sino evitar que un problema durante el proceso deje el equipo inutilizado.

El hardware debe reservar espacio para el futuro

Una de las primeras consecuencias aparece en el almacenamiento. Durante una actualización puede ser necesario conservar la versión actual mientras se descarga y verifica la nueva.

Por tanto, la memoria necesaria puede ser considerablemente mayor que el tamaño del firmware que ejecuta normalmente el dispositivo.

Esto introduce una cuestión fundamental durante la selección de componentes:

¿Cuánta memoria necesita realmente un producto que deberá actualizarse durante toda su vida útil?

La respuesta no debería basarse únicamente en la primera versión del software. También debe considerar cuánto puede crecer el firmware, qué datos adicionales almacenará el dispositivo y qué estrategia de actualización se utilizará.

La elección de la memoria debe analizarse junto con el crecimiento previsto del firmware y la arquitectura del dispositivo. Puedes ampliar este aspecto en nuestra guía sobre cómo elegir la arquitectura de memoria para dispositivos IoT.

Este es uno de los motivos por los que almacenamiento, memoria y firmware deben analizarse conjuntamente desde la fase de arquitectura.

Incorporar actualizaciones OTA desde el principio del proyecto obliga a revisar algunas decisiones que, en otros productos, podrían parecer independientes del firmware. La capacidad de almacenamiento, la memoria disponible, la conectividad o la alimentación pasan a formar parte de una misma estrategia.

Esto es especialmente relevante cuando el equipo tendrá un ciclo de vida largo. Un dispositivo industrial puede funcionar durante años con el mismo hardware, mientras que su firmware puede recibir varias actualizaciones durante ese periodo.

El objetivo no es simplemente instalar una nueva versión. El sistema debe disponer de los recursos necesarios para recibirla y mantener el funcionamiento del equipo incluso si algo falla durante el proceso.

El tamaño del firmware puede cambiar

La primera versión de un producto suele tener un tamaño de firmware relativamente controlado. Sin embargo, con el tiempo pueden añadirse nuevas funciones, protocolos de comunicación, mejoras de diagnóstico o mecanismos adicionales de seguridad.

Por eso, dimensionar la memoria exactamente para la versión inicial puede convertirse en una limitación futura.

Este aspecto resulta especialmente importante cuando se utilizan plataformas como ESP32 en productos comerciales, donde la memoria, el arranque y la estrategia de actualización deben considerarse desde el diseño inicial.

Un margen de almacenamiento razonable permite que el producto pueda evolucionar sin necesidad de modificar físicamente la electrónica. Esta decisión puede tener un impacto importante en el coste del equipo, ya que aumentar la memoria durante el diseño suele ser mucho más sencillo que rediseñar el hardware cuando el producto ya está fabricado.

Aquí conviene diferenciar entre la memoria utilizada durante la ejecución y el almacenamiento no volátil utilizado para conservar el firmware y otros datos.

No toda la memoria tiene la misma función

La RAM se utiliza durante la ejecución del firmware y puede intervenir en procesos como la recepción de datos, el cifrado o la gestión de buffers.

La memoria Flash u otro almacenamiento no volátil, en cambio, debe conservar el firmware y determinados datos incluso cuando el equipo está apagado.

En una actualización OTA, esta segunda categoría adquiere especial importancia. Dependiendo de la estrategia utilizada, puede ser necesario conservar simultáneamente la versión que está funcionando y la nueva versión que se está descargando.

Esto hace que la capacidad de almacenamiento necesaria pueda ser considerablemente superior al tamaño del firmware instalado.

No existe una capacidad universal. Depende de la arquitectura del dispositivo, del tamaño del firmware y de la estrategia de actualización.

Una estimación inicial debería considerar al menos:

Firmware actual + nueva versión + espacio temporal + bootloader + configuración + datos persistentes

También conviene reservar margen para el crecimiento futuro del software.

Por ejemplo, un equipo cuyo firmware ocupa actualmente 2 MB no debería dimensionarse necesariamente con 2 MB de almacenamiento disponible. Si el proceso de actualización necesita conservar la versión actual mientras descarga una nueva, la capacidad requerida será mayor.

El almacenamiento forma parte de la arquitectura

Esta cuestión puede parecer exclusivamente relacionada con el software, pero la decisión se toma en realidad durante la definición del hardware.

Elegir un microcontrolador con una determinada cantidad de Flash integrada, añadir una memoria externa o seleccionar una capacidad superior puede modificar:

• El coste de la electrónica.
• El número de componentes.
• El espacio ocupado en el PCB.
• El consumo del equipo.
• La estrategia de actualización.
• La capacidad de evolución futura.

Por eso, en un nuevo producto conectado, la pregunta no debería ser únicamente “¿cuánto firmware tenemos ahora?”, sino “qué capacidad necesita el producto durante toda su vida útil?”.

Esta perspectiva resulta especialmente importante en equipos industriales, donde sustituir una unidad instalada para aumentar su capacidad de almacenamiento puede ser mucho más costoso que haber previsto ese margen durante el diseño inicial.

Diseñar con margen, pero sin sobredimensionar

Reservar capacidad para el futuro no significa instalar siempre la memoria más grande disponible.

Un exceso de capacidad también puede incrementar innecesariamente el coste del producto. La decisión debe buscar un equilibrio entre las necesidades actuales, el crecimiento esperado del firmware y el ciclo de vida previsto.

El objetivo es disponer de margen suficiente para evolucionar el producto sin pagar desde el principio por recursos que probablemente nunca se utilizarán.

Este análisis debe realizarse junto con la estrategia de actualización, porque la forma en que se instala el firmware determinará cuánto almacenamiento necesita realmente el dispositivo.

Una actualización OTA no debería sustituir el firmware que está funcionando hasta que la nueva versión haya sido descargada y validada correctamente. Si el proceso se interrumpe antes de ese momento, el dispositivo debe disponer de algún mecanismo para recuperar un estado funcional.

Una estrategia habitual consiste en mantener dos imágenes de firmware, de forma que una versión pueda seguir funcionando mientras la siguiente se descarga y verifica.

El esquema A/B

En una arquitectura sencilla podemos imaginar el almacenamiento dividido en dos espacios:

Firmware A → versión actualmente activa.
Firmware B → espacio destinado a la nueva versión.

El dispositivo continúa ejecutando A mientras recibe B. Una vez completada la descarga, el sistema comprueba que la nueva imagen es válida y puede seleccionarla para el siguiente arranque.

Si B no supera las comprobaciones necesarias, A puede permanecer disponible como versión de recuperación.

Este planteamiento evita depender de una única copia del firmware durante una operación que puede verse interrumpida.

¿Qué ocurre si falla la actualización?

El sistema debe contemplar diferentes situaciones:

• La descarga se interrumpe antes de completarse.
• La alimentación desaparece durante la actualización.
• La imagen recibida está dañada.
• El firmware no supera las comprobaciones de integridad o autenticidad.
• La nueva versión no consigue arrancar correctamente.

La estrategia concreta dependerá del microcontrolador, del bootloader y del sistema operativo utilizado. Sin embargo, el principio es el mismo: una actualización no debería dejar al producto sin una versión funcional a la que volver.

Esto tiene una consecuencia directa para el diseño de hardware: utilizar una estrategia A/B requiere suficiente almacenamiento para conservar las imágenes necesarias. Por tanto, la decisión sobre las particiones y el mecanismo de recuperación debe tomarse antes de seleccionar definitivamente la memoria.

Existe otro aspecto que puede pasar desapercibido: el equipo necesita permanecer correctamente alimentado durante el proceso de actualización.

En un dispositivo conectado a la red eléctrica, una interrupción puede producirse por un fallo de suministro o por el apagado accidental del equipo. En dispositivos alimentados por batería, la situación es todavía más importante: una actualización puede consumir energía adicional y dejar al sistema sin suficiente capacidad para completar el proceso.

Por eso, la gestión de la alimentación debe formar parte de la estrategia OTA.

Evitar que una pérdida de alimentación deje el equipo inutilizado

El diseño puede incorporar mecanismos para detectar situaciones en las que no existe suficiente energía para comenzar o completar una operación crítica.

Dependiendo del producto, pueden intervenir elementos como:

• Supervisión de la tensión de alimentación.
• Detección de batería baja.
• Gestión controlada del apagado.
• Almacenamiento seguro del estado de la actualización.
• Reserva de energía para completar operaciones críticas.

No todos los productos necesitarán las mismas medidas. Un sensor alimentado durante años con una batería no tiene las mismas necesidades que un controlador industrial conectado permanentemente a la red.

Lo importante es analizar qué ocurre si la alimentación desaparece en cada fase de la actualización.

OTA en equipos alimentados por batería

En dispositivos IoT de bajo consumo, además, el tamaño del firmware y la tecnología de comunicación pueden afectar directamente al consumo energético.

Descargar una actualización completa mediante una conexión inalámbrica puede requerir bastante más energía que una comunicación habitual de telemetría. Por ello, el sistema puede necesitar estrategias como actualizaciones programadas, comprobación previa del nivel de batería o transferencia de imágenes optimizada.

Esta relación entre OTA, conectividad y consumo es especialmente importante cuando el producto se instala en lugares donde cambiar una batería o acceder físicamente al dispositivo supone un coste elevado.

En definitiva, una arquitectura OTA robusta debe contemplar no solo qué firmware se descarga, sino también cómo se almacena, cómo se valida y qué ocurre si el proceso se interrumpe.

Y estas decisiones afectan directamente al hardware que debe acompañar al firmware durante toda la vida útil del producto.

Para que una actualización OTA sea posible, el dispositivo necesita un canal de comunicación suficientemente fiable para recibir el nuevo firmware. La tecnología utilizada dependerá del producto y de las condiciones en las que vaya a funcionar.

Un equipo conectado mediante Wi-Fi, Ethernet, LTE-M, NB-IoT u otra tecnología inalámbrica tendrá requisitos diferentes. La elección no debería basarse únicamente en la velocidad máxima de comunicación, sino también en el consumo, la cobertura, la disponibilidad de la conexión y la cantidad de datos que será necesario transferir.

No todas las actualizaciones necesitan el mismo ancho de banda

Una actualización de firmware puede ocupar desde unos pocos cientos de kilobytes hasta varios megabytes o más, dependiendo de la plataforma y de las funcionalidades del producto.

En un equipo conectado mediante Ethernet, una descarga relativamente grande puede tener un impacto reducido sobre el funcionamiento normal. En cambio, un dispositivo que utiliza una conexión celular y funciona con batería puede necesitar una estrategia diferente.

También puede ser interesante utilizar actualizaciones incrementales, descargando únicamente los cambios necesarios cuando la plataforma y el software lo permitan.

Esto reduce la cantidad de datos transferidos y puede disminuir tanto el tiempo de actualización como el consumo energético asociado.

La conectividad debe seguir funcionando cuando más se necesita

Un dispositivo instalado en campo no siempre tendrá unas condiciones de comunicación ideales.

Puede existir una cobertura inalámbrica limitada, pérdidas temporales de conexión o periodos en los que el equipo no tenga acceso a la red. Por eso, el sistema debe ser capaz de gestionar una actualización incompleta sin considerar automáticamente que el dispositivo ha quedado fuera de servicio.

La estrategia puede incluir mecanismos para:

• Reanudar una descarga interrumpida.
• Comprobar qué parte del firmware se ha recibido correctamente.
• Esperar hasta disponer de una conexión adecuada.
• Evitar iniciar una actualización cuando las condiciones no sean suficientes.

Desde el punto de vista del hardware, esto vuelve a conectar la OTA con una decisión que debe tomarse durante la arquitectura inicial: qué interfaz de comunicación tendrá el producto y qué prestaciones necesitará durante toda su vida útil.

Permitir que un equipo reciba firmware desde una red introduce otro requisito fundamental: el dispositivo debe poder distinguir una actualización legítima de un archivo que no debería ejecutar.

Una actualización OTA no consiste únicamente en comprobar que el archivo se ha descargado correctamente. También es necesario garantizar que el firmware procede de una fuente autorizada y que no ha sido alterado durante el proceso.

Autenticidad e integridad del firmware

Los mecanismos de seguridad pueden utilizar firmas digitales, criptografía y diferentes funciones de validación para comprobar la legitimidad de una imagen antes de instalarla.

Aquí aparece una relación directa entre firmware seguro y hardware seguro.

Determinados microcontroladores incorporan funciones como secure boot, almacenamiento protegido de claves o aceleradores criptográficos. Estas características pueden facilitar una arquitectura en la que el dispositivo compruebe la autenticidad del firmware antes de ejecutarlo.

Por este motivo, si un producto va a necesitar actualizaciones OTA durante años, la seguridad debería formar parte de la selección del microcontrolador desde el principio, y no añadirse como una función posterior.

Evitar que una versión antigua vuelva a instalarse

También puede ser necesario controlar qué versiones de firmware están autorizadas.

Imaginemos que una actualización corrige una vulnerabilidad de seguridad. Si el dispositivo permite instalar posteriormente una versión antigua que contiene esa vulnerabilidad, parte del beneficio de la actualización desaparece.

Los mecanismos de protección contra rollback permiten establecer restricciones sobre las versiones que pueden instalarse, siempre de acuerdo con la estrategia de seguridad definida para el producto.

Esta decisión afecta nuevamente al conjunto del sistema:

Microcontrolador + memoria + bootloader + almacenamiento + gestión de claves + firmware.

Por tanto, la seguridad de una actualización OTA no debería analizarse como una función aislada del software. Forma parte de la arquitectura del dispositivo conectado y puede influir desde la selección del procesador hasta la memoria utilizada para almacenar el firmware.

Seguridad desde el diseño, no después del prototipo

Añadir mecanismos de seguridad cuando el hardware ya está definido puede limitar las opciones disponibles.

Si desde el comienzo se conoce que el producto necesitará secure boot, actualizaciones OTA firmadas o almacenamiento protegido de credenciales, resulta mucho más sencillo seleccionar una plataforma que proporcione los recursos necesarios.

Esta planificación es especialmente importante en equipos industriales o IoT con un ciclo de vida largo. El dispositivo no solo debe ser capaz de ejecutar el firmware actual, sino también de recibir y validar de forma segura las versiones que utilizará en el futuro.

En definitiva, una estrategia OTA bien diseñada debe responder a tres preguntas fundamentales:

¿Cómo llega el firmware? ¿Dónde se almacena? ¿Cómo sabemos que podemos confiar en él?

Responderlas durante la fase de arquitectura permite evitar muchas de las limitaciones que aparecen cuando OTA se incorpora al producto demasiado tarde.

Una vez analizados el almacenamiento, la alimentación, la conectividad y la seguridad, queda claro que una estrategia OTA afecta a muchas decisiones que normalmente se toman por separado durante el desarrollo de un producto.

Por eso, si las actualizaciones remotas forman parte de los requisitos del equipo, conviene incorporarlas desde la fase de definición de la arquitectura. No se trata de reservar recursos de forma indiscriminada, sino de identificar qué necesitará el producto para poder evolucionar durante su ciclo de vida.

Una arquitectura preparada para evolucionar

Antes de seleccionar definitivamente los componentes, conviene responder algunas preguntas:

• ¿Cuánto puede crecer el firmware durante la vida útil prevista?
• ¿Cuánto almacenamiento necesita la estrategia de actualización elegida?
• ¿Qué ocurre si se interrumpe la alimentación durante una actualización?
• ¿Qué conectividad utilizará el producto y qué condiciones tendrá en campo?
• ¿Cómo se verificará la autenticidad del nuevo firmware?
• ¿Existe una versión anterior a la que volver si la actualización falla?
• ¿Qué recursos de procesamiento y memoria necesitarán las futuras versiones?

Las respuestas condicionarán la selección del microcontrolador, la memoria, la conectividad y otros elementos del hardware.

Por eso, una arquitectura preparada para OTA no consiste en añadir simplemente más Flash. Consiste en diseñar el equipo teniendo en cuenta cómo será actualizado, mantenido y ampliado durante toda su vida útil.

El coste de prever OTA frente al coste de añadirlo después

Incorporar estas consideraciones durante el diseño inicial suele ofrecer más margen de decisión que intentar añadirlas cuando el producto ya está terminado.

Por ejemplo, descubrir durante la validación que no existe suficiente almacenamiento para una estrategia A/B puede obligar a cambiar la memoria, el PCB y parte del firmware. Si el problema aparece cuando el producto ya está fabricado, las consecuencias pueden ser todavía mayores.

Lo mismo puede ocurrir con la seguridad. Si el microcontrolador seleccionado inicialmente no dispone de las funciones necesarias para implementar una estrategia de arranque seguro o protección de claves, cambiar de plataforma puede afectar a buena parte de la arquitectura.

Diseñar pensando en OTA desde el principio reduce el riesgo de que una decisión tomada para la primera versión limite la evolución posterior del producto.

La principal ventaja de una estrategia OTA aparece cuando dejamos de considerar el lanzamiento como el final del desarrollo.

Un producto conectado puede recibir nuevas versiones durante años. Algunas estarán destinadas a corregir errores, otras incorporarán nuevas funcionalidades y otras responderán a cambios en los requisitos de seguridad o conectividad.

Esto modifica la forma de plantear el desarrollo.

En lugar de diseñar únicamente para:

Producto → lanzamiento → mantenimiento

podemos plantear:

Producto → lanzamiento → actualización → evolución → nuevas actualizaciones

El hardware también necesita margen de evolución

Esta perspectiva no significa que todos los componentes deban sobredimensionarse.

Un procesador con mucha más capacidad de la necesaria puede aumentar el coste y el consumo sin aportar un beneficio real. Del mismo modo, instalar una cantidad de almacenamiento excesiva no garantiza que el producto vaya a poder evolucionar correctamente si la arquitectura de actualización no está bien planteada.

El objetivo es identificar qué recursos tienen mayor probabilidad de convertirse en una limitación futura y proporcionarles un margen razonable.

En un dispositivo IoT, por ejemplo, ese margen puede estar relacionado con la memoria y la conectividad. En un controlador industrial puede ser más importante la capacidad de procesamiento, el almacenamiento y la disponibilidad de mecanismos seguros de recuperación.

Pensar más allá de la primera versión

Esta planificación resulta especialmente relevante cuando el producto tiene un ciclo de vida largo o cuando se prevé fabricar un número elevado de unidades.

Cuantas más unidades estén desplegadas, mayor será el impacto de una actualización que requiera intervención física. Una arquitectura OTA bien planteada puede convertir parte de ese mantenimiento en una operación remota y controlada.

Por eso, las actualizaciones OTA no deberían considerarse únicamente una característica del firmware, sino una capacidad del producto completo.

El hardware proporciona los recursos necesarios; el firmware gestiona el proceso; la conectividad permite realizarlo y la arquitectura de seguridad determina qué actualizaciones puede aceptar el dispositivo.

La combinación de estos elementos es la que permite construir un equipo preparado para mantenerse y evolucionar después de su lanzamiento.

No todos los productos electrónicos necesitan una estrategia de actualización OTA. Implementarla implica recursos de hardware, firmware, conectividad y seguridad que deben estar justificados por las necesidades del producto.

La decisión tiene especial sentido cuando el equipo va a permanecer instalado durante años o cuando acceder físicamente a cada unidad supone un coste elevado.

OTA resulta especialmente interesante cuando

• El producto se instala en ubicaciones de difícil acceso.
• Se prevé un ciclo de vida largo.
• El firmware puede necesitar nuevas funcionalidades.
• Es necesario corregir errores sin desplazarse hasta el equipo.
• Las actualizaciones de seguridad forman parte del mantenimiento del producto.
• Existe un número elevado de unidades desplegadas.
• El coste de una intervención presencial es significativo.

En estos casos, la posibilidad de actualizar remotamente puede convertirse en una característica importante del producto y no solamente en una comodidad para el fabricante.

No siempre es necesario implementar una solución compleja

También existen productos en los que OTA puede aportar poco valor.

Un equipo sencillo, accesible físicamente y con un ciclo de vida corto puede actualizarse mediante una conexión local sin que resulte necesario desarrollar una infraestructura remota completa.

La clave está en comparar el coste de implementar y mantener OTA con el coste que tendría acceder físicamente a los dispositivos durante su vida útil.

Además, la estrategia puede variar según el producto. No es lo mismo actualizar ocasionalmente un controlador industrial conectado a Ethernet que cientos de sensores inalámbricos alimentados por batería.

OTA debe responder a una necesidad real del producto y de su mantenimiento.

Cuando las actualizaciones remotas se incorporan como requisito desde las primeras fases, pueden tenerse en cuenta al mismo tiempo que el resto de características del equipo.

Esto permite seleccionar una plataforma que disponga de suficiente memoria, elegir el almacenamiento adecuado, definir la conectividad y establecer una estrategia de recuperación compatible con el hardware.

También permite valorar desde el principio aspectos que pueden ser difíciles de modificar posteriormente, como la protección de claves, el arranque seguro o la capacidad de almacenamiento necesaria para conservar varias versiones del firmware.

Hardware, firmware y conectividad deben diseñarse conjuntamente

Una arquitectura OTA puede resumirse en varios bloques que dependen entre sí:

Hardware → Firmware → Almacenamiento → Conectividad → Seguridad → Actualización

Si uno de ellos presenta una limitación importante, puede afectar al funcionamiento de todo el sistema.

Por ejemplo, disponer de suficiente almacenamiento no soluciona un problema de conectividad. Del mismo modo, disponer de una conexión rápida no sirve de mucho si el hardware no tiene espacio para recibir una nueva imagen de firmware de forma segura.

Por eso, la estrategia OTA debe definirse como parte de la arquitectura global del producto electrónico.

Esta perspectiva es especialmente importante durante el desarrollo de equipos industriales e IoT, donde las decisiones tomadas en la fase inicial pueden determinar durante años el coste de mantenimiento y la capacidad de evolución del producto.

Una inversión en diseño para reducir costes futuros

El principal beneficio de planificar OTA no siempre aparece durante el lanzamiento.

Su valor puede hacerse evidente meses o años después, cuando aparece una vulnerabilidad, se necesita corregir un error o se decide añadir una nueva funcionalidad.

Si el hardware estaba preparado, el fabricante puede disponer de una vía para actualizar las unidades existentes sin sustituir físicamente el equipo.

Por tanto, diseñar para OTA puede considerarse también una estrategia para reducir el coste de mantenimiento y prolongar la vida útil de un producto conectado.

Y esta es precisamente la razón por la que la capacidad de actualización debería formar parte de las decisiones de diseño desde el comienzo del proyecto, en lugar de añadirse cuando el hardware ya está cerrado.

Las actualizaciones OTA pueden prolongar la vida útil de un equipo y reducir el coste de mantenimiento, pero para conseguirlo deben plantearse desde el inicio del desarrollo.

La arquitectura debe permitir que el producto pueda recibir nuevas versiones de firmware sin comprometer su funcionamiento, su seguridad ni su capacidad de recuperación.

Esto implica coordinar diferentes decisiones de diseño:

Hardware + firmware + almacenamiento + conectividad + alimentación + seguridad

Ninguno de estos elementos funciona de forma completamente independiente.

Una decisión de arquitectura, no una función añadida

Incorporar OTA cuando el hardware ya está terminado puede limitar las opciones disponibles. Es posible descubrir que no existe suficiente almacenamiento para una estrategia de actualización segura, que el microcontrolador no dispone de determinadas funciones de seguridad o que la conectividad elegida no resulta adecuada para transferir las nuevas versiones.

Resolver estas limitaciones posteriormente puede implicar modificar componentes, PCB o incluso la arquitectura completa del equipo.

Por eso, durante la fase inicial de un proyecto de diseño electrónico, conviene definir también cómo se actualizará y mantendrá el producto después de su lanzamiento.

Preparar el producto para su evolución

Diseñar para OTA tampoco significa intentar prever todas las funcionalidades que tendrá el equipo dentro de diez años.

El objetivo es proporcionar suficiente margen para que las decisiones más difíciles de modificar posteriormente no se conviertan en una limitación.

Por ejemplo, puede ser razonable reservar capacidad adicional de almacenamiento, seleccionar un microcontrolador con funciones de seguridad adecuadas o elegir una interfaz de comunicación que permita evolucionar el producto sin cambiar su hardware.

Estas decisiones pueden incrementar ligeramente el coste inicial, pero también pueden evitar rediseños posteriores cuando el producto ya se encuentra en fabricación o instalado en campo.

El valor de OTA aparece especialmente cuando se analiza el producto más allá de su lanzamiento.

Durante su vida útil pueden aparecer nuevas necesidades:

• Correcciones de errores detectados en campo.
• Nuevas funcionalidades.
• Actualizaciones de seguridad.
• Cambios en servicios o sistemas externos.
• Mejoras de rendimiento.
• Nuevas necesidades de diagnóstico o mantenimiento.

La posibilidad de actualizar el firmware permite responder a algunas de estas situaciones sin sustituir físicamente cada dispositivo.

Sin embargo, para que esto sea viable, el hardware debe haber sido diseñado pensando en esa evolución.

Del prototipo al producto mantenible

Esta perspectiva también cambia la forma de plantear el desarrollo.

Un prototipo puede funcionar perfectamente con una cantidad limitada de memoria, una conexión determinada y una actualización manual. Un producto destinado a fabricar cientos o miles de unidades puede necesitar una arquitectura completamente diferente.

Cuando el acceso físico a los equipos instalados tiene un coste elevado, aspectos como la actualización remota, el diagnóstico y la recuperación adquieren un valor mucho mayor.

Por eso, en productos industriales e IoT, la estrategia de mantenimiento debería considerarse junto con la arquitectura electrónica desde las primeras fases del proyecto.

El objetivo final no es simplemente conseguir un equipo que funcione correctamente en el momento de su lanzamiento. Es desarrollar un producto que pueda mantenerse, actualizarse y evolucionar de forma segura durante el tiempo previsto de servicio.

El diseño inicial condiciona los próximos años

Una decisión tomada durante la selección del microcontrolador o de la memoria puede determinar las posibilidades de actualización durante toda la vida del producto.

Por eso, cuando OTA forma parte de los requisitos, conviene plantear desde el principio preguntas como:

¿Cuánto puede crecer el firmware? ¿Cómo se recuperará el equipo si una actualización falla? ¿Qué recursos necesitará dentro de cinco años? ¿Podrá seguir utilizando la misma conectividad?

Responder a estas preguntas antes de cerrar el hardware proporciona mucho más margen para construir una arquitectura equilibrada.

Las actualizaciones OTA son, en definitiva, una capacidad del producto completo. No pertenecen únicamente al firmware.

Planificar las actualizaciones remotas durante las primeras fases del desarrollo permite tomar mejores decisiones sobre el microcontrolador, la memoria, el almacenamiento, la conectividad y la alimentación.

En Kenso Circuits podemos ayudarte a definir la arquitectura electrónica de un producto conectado, teniendo en cuenta no solo los requisitos actuales, sino también las necesidades de mantenimiento y evolución previstas para el futuro.

Una arquitectura bien planteada puede evitar que una limitación de hardware termine condicionando las actualizaciones del producto años después de su lanzamiento.

Si estás desarrollando un nuevo equipo electrónico y quieres que pueda evolucionar mediante actualizaciones OTA, podemos ayudarte a definir la solución desde la fase inicial del proyecto.

Preguntas frecuentes sobre las actualizaciones OTA

¿Qué es una actualización OTA?

Una actualización OTA (Over The Air) permite instalar una nueva versión del firmware de un dispositivo utilizando una conexión de red, sin necesidad de acceder físicamente al equipo. El proceso puede incluir la descarga, almacenamiento, verificación e instalación del nuevo firmware.

¿Qué necesita un dispositivo para recibir actualizaciones OTA?

El dispositivo necesita una combinación adecuada de hardware, almacenamiento, firmware, conectividad y seguridad. También debe disponer de una estrategia para gestionar posibles interrupciones durante la descarga o instalación.

¿Cuánta memoria necesita un dispositivo preparado para OTA?

No existe una capacidad universal. Hay que tener en cuenta el tamaño del firmware actual, su posible crecimiento, el bootloader, los datos persistentes y el espacio necesario para almacenar temporalmente una nueva versión. Si se utiliza una estrategia A/B, puede ser necesario conservar dos imágenes de firmware.

¿Qué ocurre si se interrumpe una actualización OTA?

Una arquitectura correctamente diseñada debe evitar que una interrupción deje el dispositivo inutilizado. Dependiendo de la estrategia utilizada, el equipo puede conservar una versión funcional del firmware y utilizar mecanismos de recuperación o rollback si la nueva versión no puede instalarse o arrancar correctamente.

¿Son seguras las actualizaciones OTA?

Pueden serlo si se implementan mecanismos adecuados para comprobar la integridad y autenticidad del firmware. Dependiendo de la plataforma, pueden utilizarse firmas digitales, secure boot, protección de claves y mecanismos para impedir la instalación de versiones no autorizadas.

¿La actualización OTA afecta al diseño del hardware?

Sí. Una estrategia OTA puede condicionar la selección del microcontrolador, la capacidad de almacenamiento, la conectividad, la alimentación y determinadas funciones de seguridad. Por eso, si el producto necesitará actualizaciones remotas durante años, conviene considerar estos requisitos desde la fase de arquitectura.

¿Merece la pena incorporar OTA a cualquier producto electrónico?

No necesariamente. OTA resulta especialmente interesante en productos con un ciclo de vida largo, muchas unidades desplegadas o ubicaciones de difícil acceso. En equipos sencillos y fácilmente accesibles, una actualización local puede ser una solución más económica y adecuada.

¿Por qué es importante diseñar OTA desde el principio?

Porque algunas decisiones son difíciles o costosas de modificar cuando el producto ya está terminado. Reservar suficiente almacenamiento, seleccionar un microcontrolador con las funciones de seguridad necesarias y definir una estrategia de recuperación desde el inicio permite desarrollar un producto preparado para evolucionar durante toda su vida útil.