3.10 Sistemas embebidos y en tiempo real

Visión general y motivación

Un sistema embebido es un software que se ejecuta en un dispositivo, no en una computadora de propósito general. Vive dentro de un automóvil, un marcapasos, un termostato, un robot industrial o una unidad de guiado. El software está dedicado a ese dispositivo, y el dispositivo suele tener límites estrictos en memoria, potencia de procesamiento y consumo energético. No siempre se pueden añadir más recursos con un clic en la consola de la nube. Lo que se entrega es, con frecuencia, lo que funcionará durante años.

Un sistema en tiempo real es aquel en el que la corrección depende del momento de la respuesta, no solo de producir el resultado correcto. Un controlador de airbag que calcula un comando de despliegue impecable, pero un segundo tarde, ha fallado de forma absoluta. El trabajo en tiempo real añade a cada tarea una pregunta ineludible: ¿terminará antes de su plazo límite, cada vez, en el peor escenario posible? Esta es una disciplina distinta de la mentalidad orientada al rendimiento que domina el software web y en la nube.

Para una gran organización, esto importa mucho más de lo que podría parecer a primera vista. Las empresas construyen coches conectados, dispositivos médicos, controladores industriales y miles de millones de dispositivos del Internet de las Cosas (IoT). Los gobiernos operan plataformas de defensa, aviónica, controladores de redes eléctricas y dispositivos médicos regulados. En estos ámbitos, un defecto de software puede lesionar personas, detener una línea de producción o comprometer la seguridad nacional. Las normas son más estrictas, las pruebas más difíciles y los estándares tienen carácter legal vinculante. Este capítulo ayuda a construir software correcto, puntual, seguro y protegido bajo restricciones reales. Se conecta con la construcción de software (capítulo 2.9), los sistemas distribuidos (capítulo 3.3), la escalabilidad y el rendimiento (capítulo 3.5), la infraestructura y la seguridad en la nube (capítulo 4.3) y el mantenimiento de software (capítulo 3.7).

Principios clave

El plazo es un requisito de corrección, no un capricho de rendimiento. Una respuesta tardía puede ser una respuesta incorrecta.
Diseña para el peor caso, no para el promedio. Las garantías en tiempo real se fundan en el comportamiento en el peor escenario, no en la velocidad habitual.
La determinación vence a la velocidad bruta. Un sistema predecible que siempre cumple su plazo supera a uno más rápido que de vez en cuando se le escapa.
Los recursos son finitos y fijos. Presupuesta memoria, ciclos de CPU y energía con la misma deliberación con la que presupuestas dinero.
La seguridad y la protección se integran desde el diseño, no se añaden después. En dominios regulados, hay que demostrar el trabajo, no solo afirmar la calidad.
El hardware forma parte del sistema. No se puede razonar sobre el software sin razonar sobre el chip, los sensores y la física.
Las actualizaciones en el campo son una capacidad de ciclo de vida, no una idea de última hora. Los dispositivos en el mundo real necesitan un mecanismo seguro para recibir correcciones.

Recomendaciones

Clasifica cada requisito de plazo como estricto, rígido o flexible

No todos los plazos son iguales. Un plazo de tiempo real estricto no puede fallar jamás, porque una incumplimiento provoca una falla del sistema o un daño: piensa en el control del motor o las superficies de vuelo. Un plazo rígido tolera fallos esporádicos, pero un resultado tardío es inútil y se descarta. Un plazo flexible degrada su valor de forma gradual: un fotograma de vídeo que llega ligeramente tarde reduce la calidad, pero no causa un desastre. Etiqueta cada tarea sensible al tiempo con su clase, porque el esfuerzo, la rigurosidad de las pruebas y el coste diferirán enormemente. Dos propiedades describen el comportamiento temporal. La latencia es el retardo entre un evento y su respuesta. El jitter es la variación de esa latencia de una ocurrencia a la siguiente. Los sistemas en tiempo real estricto se preocupan tanto de acotar el jitter como de reducir la latencia, porque la previsibilidad es lo que permite demostrar que un plazo se cumple siempre.

Elige tu base de ejecución deliberadamente: RTOS o metal desnudo

Tienes dos bases principales. La firmware sobre metal desnudo se ejecuta directamente sobre el hardware, sin sistema operativo, mediante un bucle simple y manejadores de interrupción. Es la opción más pequeña y predecible, y resulta ideal para dispositivos diminutos con una única función clara. Un sistema operativo en tiempo real (RTOS) es un sistema operativo ligero que programa tareas por prioridad y garantiza límites de tiempo. Ofrece varias tareas concurrentes, un programador y servicios como temporizadores y colas de mensajes, manteniendo la previsibilidad temporal. Elige un RTOS cuando tengas varias tareas concurrentes con plazos distintos. Elige metal desnudo cuando el dispositivo sea muy restringido o la temporización deba ser demostrablemente simple. Para trabajo en tiempo real estricto, prefiere un programador preemptivo basado en prioridades y analízalo con un método como la planificación por monotonicidad de frecuencia (rate-monotonic scheduling), que asigna prioridades según la frecuencia de cada tarea y permite demostrar que el conjunto de tareas es programable.

Presupuesta memoria, CPU y energía como recursos de primera clase

Trata cada recurso escaso como un presupuesto con un límite máximo inamovible. En memoria, prefiere la asignación estática sobre la dinámica en el heap, porque la memoria dinámica puede fragmentarse y fallar de forma impredecible en el peor momento. Muchas normas de seguridad restringen o prohíben el uso del heap tras el arranque precisamente por esta razón. En CPU, mide el tiempo de ejecución en el peor caso (TEPC, o worst-case execution time, WCET), el tiempo máximo que una tarea puede tardar, y programa en función de ese valor, no del promedio. En energía, recuerda que muchos dispositivos funcionan con batería o recogen energía del entorno, así que diseña ciclos de trabajo, estados de reposo y eventos de activación que cumplan un presupuesto energético que debe durar meses o años. Anota estos presupuestos y revísalos como cualquier otro requisito.

Maneja las interrupciones y la concurrencia con disciplina estricta

Una interrupción es una señal de hardware que detiene el trabajo actual para ejecutar un manejador de inmediato. Las interrupciones son el mecanismo por el que los dispositivos reaccionan instantáneamente al mundo, y son una fuente importante de errores sutiles. Mantén los manejadores lo más breves posible: reconoce el evento, almacena los datos mínimos y delega el trabajo real en una tarea normal. Como una interrupción puede dispararse entre cualquier par de instrucciones, debes proteger los datos compartidos de condiciones de carrera con esmero. Utiliza técnicas sin bloqueo, secciones críticas breves o primitivas bien comprendidas, y protégete de la inversión de prioridad, en la que una tarea de baja prioridad que mantiene un bloqueo impide el avance de una de alta prioridad. Esta concurrencia comparte el razonamiento del capítulo 3.3, pero con una temporización más rigurosa y sin margen para reintentos.

Escribe controladores de dispositivo que aílen el detalle del hardware

Un controlador de dispositivo es la capa de software que se comunica con una pieza concreta de hardware: un sensor, un radio, un controlador de motor. Mantén el código específico de hardware detrás de una interfaz limpia, para que el resto del software dependa de una abstracción estable en lugar de de direcciones de registro. Esto hace que el código sea testeable fuera del dispositivo, más fácil de portar cuando un chip se agota en el mercado y más sencillo de analizar. Documenta cada supuesto sobre temporización, orden de bytes y particularidades del hardware, porque son los detalles que provocan fallos en el campo. Es la disciplina de construcción del capítulo 2.9 aplicada a un contexto en el que un bit incorrecto puede detener un motor.

Adopta la norma de seguridad funcional que rige tu dominio

Si tu dispositivo puede dañar a personas o propiedades, es muy probable que aplique una norma de seguridad funcional, y a menudo se trata de una obligación legal. La IEC 61508 es la norma general sobre la seguridad de sistemas electrónicos y la madre de varias otras. ISO 26262 rige la seguridad de vehículos terrestres. DO-178C rige el software embarcado en aviación civil. La IEC 62304 rige el software de dispositivos médicos. En cuanto a programación, MISRA C es un conjunto de reglas ampliamente adoptado que restringe funciones peligrosas del lenguaje C para hacer el código más seguro y analizable. Estas normas exigen trazabilidad desde el requisito hasta el código y la prueba, procesos definidos y evidencias que se pueden entregar a un auditor o a un organismo regulador. Adopta la norma adecuada desde el principio, porque retrotraer la documentación al final es un proceso doloroso y a veces imposible.

Prueba con simulación y con hardware en el bucle

No se puede probar software embebido como se prueba una aplicación web. Construye una estrategia en capas. Ejecuta pruebas unitarias en un ordenador convencional contra la interfaz de abstracción de hardware. Utiliza simulación para modelar el dispositivo y su entorno cuando el hardware real escasea o resulta peligroso de poner a prueba. Luego emplea pruebas con hardware en el bucle (hardware-in-the-loop, HIL), donde el controlador real se ejecuta frente a una versión simulada del sistema físico que controla, de modo que puedas probar con seguridad condiciones de fallo como un sensor atascado o una carga súbita. Automatiza estas pruebas en tu pipeline para que cada cambio se verifique bajo condiciones realistas antes de llegar a un dispositivo.

Diseña las actualizaciones OTA y la seguridad del dispositivo desde el día uno

Los dispositivos en el campo necesitarán correcciones, así que planifica las actualizaciones OTA: un mecanismo para entregar firmware nuevo de forma segura a través de la red. Un diseño OTA seguro firma cada actualización criptográficamente, verifica la firma antes de instalar, actualiza de forma atómica y puede hacer retroceso a una imagen conocida y funcional si la nueva no arranca. Combínalo con los principios de seguridad del capítulo 4.3, adaptados al hardware restringido. Utiliza una raíz de confianza en hardware y un arranque seguro para que solo se ejecute firmware firmado. Cifra los datos en tránsito y en reposo. Cambia las credenciales por defecto y desactiva las interfaces que no se usen. Una flota IoT es un sistema distribuido con una superficie de ataque enorme, y una sola contraseña por defecto débil puede comprometer millones de dispositivos a la vez.

Contrapartidas: ventajas y desventajas

Decisión	Ventajas	Desventajas / coste
RTOS	Multitarea, programación por prioridad, servicios temporales	Sobrecarga, mayor huella, curva de aprendizaje
Metal desnudo	Mínimo, máximamente predecible, control total	Difícil de escalar a muchas tareas, más trabajo manual
Asignación estática	Predecible, sin fragmentación, compatible con la seguridad	Menos flexible, hay que dimensionar todo de antemano
Certificación formal de seguridad	Acceso legal al mercado, evidencia rigurosa, mayor confianza	Gran inversión de tiempo y dinero, iteración más lenta
Actualizaciones OTA	Corregir y mejorar dispositivos en campo, prolongar su vida	Infraestructura de actualización, carga de seguridad, riesgo de retroceso

La contrapartida maestra es entre previsibilidad y flexibilidad. Todo lo que hace que un sistema de propósito general sea conveniente (memoria dinámica, recopilación de basura en segundo plano, programación por esfuerzo mejor, recursos elásticos) va en contra de la garantía de que una tarea siempre termina a tiempo dentro de una huella fija. La ingeniería embebida y en tiempo real renuncia deliberadamente a la flexibilidad a cambio de determinación y seguridad. La habilidad consiste en gastar ese intercambio solo allí donde el plazo o el riesgo lo exigen de verdad, y mantener las partes flexibles y de ciclo rápido (como el backend en la nube del dispositivo) al otro lado de una frontera limpia.

Preguntas para discutir con tu equipo

¿Medís el jitter, o solo la latencia media, en vuestros caminos críticos de tiempo? La corrección en tiempo real estricto se sostiene en acotar la variación del tiempo de respuesta (jitter), no solo en reducir la latencia habitual, porque la previsibilidad es lo que permite demostrar que un plazo se cumple siempre. Un bucle de control con un promedio bajo pero picos ocasionales elevados puede seguir incumpliendo su plazo y causar daño, y el promedio lo ocultará. Traed mediciones de la dispersión, con el peor caso incluido, para cada tarea crítica en el tiempo, y etiquetad cada una como estricta, rígida o flexible para que la rigurosidad de las pruebas se corresponda con la consecuencia de un incumplimiento. Todo lo conveniente en los sistemas de propósito general (memoria dinámica, recopilación de basura, programación por esfuerzo mejor) ataca la previsibilidad, así que permanece fuera del camino estricto. Si solo reportáis promedios, no podéis afirmar con honestidad que un plazo estricto se cumple.
¿La elección de RTOS o metal desnudo sigue siendo la adecuada, y podéis demostrar que el conjunto de tareas es programable? La base de ejecución es una decisión que conviene revisar a medida que el dispositivo crece: el metal desnudo es la opción más compacta y predecible para una función clara, mientras que un RTOS justifica su sobrecarga una vez que hay varias tareas concurrentes con plazos distintos. Para el trabajo en tiempo real estricto, el capítulo apunta a un programador preemptivo basado en prioridades, analizado con un método como la planificación por monotonicidad de frecuencia, que permite demostrar que las tareas caben en lugar de esperarlo. Traed el conjunto de tareas actual, sus frecuencias y sus tiempos de ejecución en el peor caso, y verificad si la programabilidad se sostiene realmente o si las tareas se han acumulado silenciosamente más allá de lo que la base puede garantizar. Protegedos de la inversión de prioridad, donde una tarea de baja prioridad que mantiene un bloqueo frena a una de alta prioridad. Elegir la base por costumbre en lugar de por el conjunto de tareas es cómo se erosionan los plazos de forma silenciosa.
¿Dónde está exactamente la frontera entre el dispositivo determinista y el backend flexible de la nube, y es lo suficientemente limpia para avanzar rápido en un lado sin poner en riesgo al otro? La contrapartida maestra del capítulo renuncia a la flexibilidad a cambio de determinación y seguridad, y la habilidad está en gastar ese intercambio solo donde el plazo o el riesgo de verdad lo exigen. Una frontera limpia permite que el firmware crítico para la seguridad se mantenga conservador y certificado mientras el backend en la nube itera con rapidez, de modo que ambos evolucionan a su propio ritmo seguro. Traed vuestra arquitectura y localizad esa costura: qué debe demostrarse determinista y actualizarse por una vía firmada y verificada, frente a qué puede cambiar cada semana en el servidor. Difuminar la línea arrastra hábitos de la nube (asignación dinámica, temporización por esfuerzo mejor) al camino de control, o frena el backend al ritmo del firmware sin necesidad. Situar la frontera correctamente es lo que mantiene intactos tanto las evidencias de seguridad como la velocidad de entrega.
¿Qué norma de seguridad funcional rige cada producto y cuán lejos está la evidencia actual de lo que un auditor aceptaría? La norma (IEC 61508, ISO 26262 para vehículos terrestres, DO-178C para software aeronáutico, IEC 62304 para dispositivos médicos) es a menudo la ley, y exige trazabilidad desde el requisito hasta el código y la prueba que no se puede fabricar al final. En un equipo grande, el riesgo es que los grupos adopten la documentación de forma desigual, de modo que una línea de producto esté lista para la auditoría mientras otra descubre a mitad de la certificación que sus requisitos nunca se trazaron. La tensión contraria es la velocidad: la trazabilidad completa y la aplicación de MISRA C frenan la iteración diaria, y un equipo bajo presión de plazo siente la tentación de posponer la evidencia para «más adelante». Traed la matriz de trazabilidad actual, los hallazgos de análisis estático aún abiertos y un análisis de brechas honesto frente al nivel de garantía objetivo. En contextos empresariales y de gobierno, añadid el tiempo de anticipación de la certificación y las expectativas del auditor, porque retrotraer la evidencia tras el diseño es lento, costoso y a veces imposible, y un retraso en la certificación puede bloquear el acceso al mercado por completo.
Si mañana se descubriera un defecto grave en un dispositivo en campo, ¿cuán rápido podríais corregirlo de forma segura en toda la flota, y habéis ensayado el retroceso? Un dispositivo que no se puede parchear se convierte en una responsabilidad permanente de seguridad y seguridad funcional, y un retiro físico cuesta órdenes de magnitud más que una actualización OTA firmada. La tensión es que un mecanismo de actualización descuidado es en sí mismo una superficie de ataque y un riesgo de inutilización: una vía OTA que instala imágenes sin firmar, o que no puede hacer retroceso ante un arranque defectuoso, puede convertir un solo lanzamiento malo en millones de unidades inoperativas. Traed vuestro diseño de actualización (firmado criptográfico, verificación de firma antes de instalar, instalación atómica, retroceso automático a una imagen conocida y funcional), el estado del arranque seguro y la raíz de confianza en hardware, y la última vez que alguien ensayó un retroceso en hardware real. Para una flota empresarial o pública, añadid quién es responsable de las claves de firma y cómo revocaríais una comprometida, porque una clave filtrada o una credencial por defecto compartida puede comprometer toda la flota de golpe.
¿Vuestros presupuestos de memoria, CPU y energía están documentados con límites máximos, y vuestra estrategia de pruebas ejerce tanto la simulación como el hardware real? Las garantías en tiempo real se fundan en el tiempo de ejecución en el peor caso y una huella de recursos fija, no en el comportamiento medio, de modo que una asignación dinámica sin presupuestar o una carga en el peor caso no probada es donde la determinación se erosiona en silencio. Para un equipo grande, el peligro es la deriva: las tareas se acumulan, la memoria crece y nadie es responsable del presupuesto hasta que un dispositivo falla en el campo tras semanas de funcionamiento ininterrumpido. La contrapartida es cobertura frente a coste, porque un rig de pruebas HIL que inyecta fallos como un sensor atascado es costoso de construir, mientras que la simulación pura oculta errores de temporización que solo aparecen en el chip real. Traed los presupuestos documentados, los tiempos de ejecución en el peor caso medidos frente a ellos, y evidencia de que vuestro pipeline ejecuta pruebas unitarias en la capa de abstracción, simulación y pruebas HIL antes de un lanzamiento. En entornos regulados y de gobierno, vinculad esto a la cobertura de prueba estructural que exige la norma, porque un auditor querrá prueba de que las condiciones de fallo se ejercitaron, no una garantía de que el caso medio parecía correcto.

Perspectiva por sector

Empresa en fase inicial. La velocidad y la supervivencia dominan, así que elige un RTOS ligero o un bucle simple sobre metal desnudo, prohíbe la asignación dinámica tras el arranque y mide el tiempo en el peor caso de tu bucle crítico en lugar de perseguir un presupuesto de certificación que no tienes. Omites los procesos formales de seguridad funcional a menos que tu mercado te lo exija, pero no omitas jamás las actualizaciones OTA firmadas con retroceso automático: una empresa joven no sobrevive a un retiro en campo, y la corrección remota es la diferencia entre una noche mala y un producto muerto. Mantén el firmware del dispositivo pequeño y conservador para que tus ingenieros, escasos, no tengan que mantener una infraestructura que no pueden permitirse.

Pequeña empresa. Sin un especialista embebido en plantilla, apóyate en módulos probados, diseños de referencia y distribuciones de RTOS de proveedores en lugar de construir tu propio programador o gestor de arranque. Enmarca la decisión de construir o comprar en torno a quién parcheará el dispositivo durante la próxima década: un stack de seguridad y actualización adquirido sobre el que puedes fiarte supera a uno a medida que nadie dejará de poder mantener. Trata las contraseñas por defecto, las interfaces de depuración abiertas y las actualizaciones sin firmar como los fallos más probables de causarte daño, porque son baratos de prevenir y ruinosos de descubrir en el campo.

Gran empresa. El problema es la coherencia entre muchas líneas de producto y equipos: una política compartida de base de ejecución, plantillas comunes de presupuesto de recursos, aplicación de MISRA C y análisis estático, y una plataforma certificada de actualizaciones OTA y arranque seguro para que cada grupo no lo reinvente. Presupuesta explícitamente la carga de seguridad funcional y de pruebas HIL, estandariza la interfaz de abstracción de hardware para que un chip agotado no deje varada una línea de producto, y gestiona las evidencias temporales, los artefactos de seguridad y la postura de seguridad de la flota como activos gobernados, no como sabiduría tribal de cada equipo. Una credencial débil por defecto en toda la flota es una responsabilidad a escala empresarial, así que centraliza la gestión de credenciales y claves.

Sector público. Las normas de contratación, la transparencia y la rendición de cuentas pública condicionan cada decisión. Exige a los proveedores que desarrollen software aeronáutico, médico o de defensa conforme a la norma que rige (DO-178C, IEC 62304, IEC 61508) al nivel de garantía que corresponde al peligro, y que entreguen la trazabilidad y la evidencia de cobertura estructural que los auditores revisarán. Exige arranque seguro, una raíz de confianza en hardware y un proceso de actualización de campo controlado y firmado, porque una actualización no verificada en un sistema de vuelo o de red eléctrica es inaceptable. Prefiere contratos que otorguen derechos al código fuente, los artefactos de seguridad y la posibilidad de recertificar con un segundo proveedor, para que un proveedor que cierre no deje varado un sistema del que el público depende durante décadas.

Ejemplos

Empresa en fase inicial. Una pequeña empresa de hardware construye un monitor de calidad del aire alimentado por batería. Escribe su firmware sobre un RTOS ligero con un conjunto fijo de tareas y sin asignación dinámica tras el arranque, de modo que el dispositivo que se envía es el que funciona durante años con una pila de moneda. Incluso sin presupuesto de certificación, el equipo mide el tiempo en el peor caso de su bucle de lectura de sensores y pone a prueba la unidad frente a condiciones de fallo inyectadas en un banco de pruebas antes de cada lanzamiento. Las actualizaciones OTA firmadas con retroceso automático les permiten corregir un defecto en todas las unidades enviadas, de modo que una lectura incorrecta en el campo no significa un retiro que la empresa joven no podría soportar.

Gran empresa. Un fabricante de vehículos conectados construye un controlador de frenos electrónico. El bucle de control en tiempo real estricto se ejecuta en un RTOS con planificación por monotonicidad de frecuencia y memoria estática, y cada tarea lleva un tiempo de ejecución en el peor caso medido. El equipo desarrolla conforme a ISO 26262 con trazabilidad completa desde el requisito hasta el código y la prueba, y aplica MISRA C con análisis estático en cada commit. Un rig de pruebas HIL reproduce miles de escenarios de carretera, incluyendo fallos de sensores inyectados, antes de que salga firmware alguno. Las actualizaciones OTA firmadas permiten a la empresa corregir un defecto en toda la flota sin un retiro costoso, con retroceso automático si un coche no arranca con la nueva imagen.

Sector público. Una autoridad aeronáutica nacional certifica un ordenador de gestión de vuelo nuevo. El proveedor desarrolla el software aeronáutico conforme a DO-178C al nivel de garantía que corresponde al peligro, produciendo evidencia de cobertura de requisitos y de cobertura estructural de prueba que los auditores revisan. La temporización se demuestra determinista bajo carga en el peor caso, con latencia de interrupción acotada y sin asignación dinámica tras el arranque. El arranque seguro y una raíz de confianza en hardware garantizan que solo se ejecute firmware firmado y certificado. Las actualizaciones de campo siguen un proceso controlado y firmado, porque una actualización no verificada en un sistema de vuelo es inaceptable.

Casos de negocio: motivaciones, retorno de inversión y coste total de propiedad

El caso de negocio lo domina el coste del fallo y el coste de acceso al mercado. En dominios regulados, no se puede vender el producto sin la certificación de seguridad, de modo que el coste del proceso es simplemente el precio de entrada. Más allá de eso, los defectos en hardware desplegado son extraordinariamente costosos: un retiro físico cuesta mucho más que un parche en la nube, e un incidente de seguridad conlleva responsabilidad legal, sanción regulatoria y daño reputacional que pueden acabar con una línea de producto. Integrar seguridad, determinación y capacidad de actualización desde el diseño es barato comparado con descubrir su ausencia en el campo.

Enmarca el retorno de inversión en torno a los retiros evitados, la certificación más rápida y la vida útil prolongada del dispositivo. Una capacidad OTA robusta convierte muchos retidos inevitables en correcciones remotas de bajo coste, y cada retiro evitado puede pagar todo el programa de actualización. Un análisis riguroso del TEPC y la presupuestación de recursos permiten lanzar sobre hardware más económico con confianza, reduciendo el coste por unidad en una flota grande. En cuanto al coste total de propiedad, recuerda que estos dispositivos viven durante años o décadas: la carga de mantenimiento, parches de seguridad y soporte (capítulo 3.7) eclipsa la inversión inicial. Diseñar para la actualizabilidad, con abstracción clara del hardware y presupuestos documentados, es lo que mantiene esa larga cola asequible.

Antipatrón y errores frecuentes

Optimizar para el caso medio. Cumplir el plazo «normalmente» es incumplir un requisito en tiempo real estricto.
Asignación dinámica en el camino de control. La fragmentación de la memoria dinámica provoca un fallo que solo aparece tras semanas de funcionamiento ininterrumpido.
Manejadores de interrupción sobrecargados. Colocar procesamiento pesado dentro de una interrupción desborda el presupuesto temporal y genera condiciones de carrera.
Ignorar la norma hasta la auditoría. Retrotraer la trazabilidad y la evidencia al final es lento, costoso y a veces imposible.
Lanzar sin una vía de actualización. Un dispositivo que no se puede parchear se convierte en una responsabilidad permanente de seguridad y seguridad funcional.
Contraseñas por defecto e interfaces abiertas. Una credencial débil convierte una flota IoT en una red de bots.
Probar solo en simulador o solo en hardware. Cada uno oculta errores que el otro detectaría; hacen falta ambos.
Tratar el hardware como problema ajeno. La temporización, el orden de bytes y las particularidades de los sensores son aquí preocupaciones de software.

Modelo de madurez

Nivel 1: Iniciar. La temporización se espera, no se analiza. La memoria se asigna dinámicamente a voluntad. No se sigue ninguna norma de seguridad funcional. Las pruebas son manuales y solo en el dispositivo. Los dispositivos no pueden actualizarse una vez enviados, de modo que un defecto en campo significa un retiro o una responsabilidad permanente.
Nivel 2: Desarrollar. Algunas tareas tienen tiempos medidos y un RTOS básico o bucle estructurado está en marcha, pero la práctica varía de equipo en equipo. Existen pautas de programación, pero no se aplican de forma obligatoria. Las pruebas incluyen algo de simulación. Existe una vía de actualización manual y arriesgada en algunos productos y no en otros. Los buenos hábitos están presentes, pero de forma inconsistente, y nada garantiza que la próxima línea de producto los herede.
Nivel 3: Estandarizar. Los requisitos de temporización se clasifican como estrictos, rígidos o flexibles, y se analizan con el tiempo de ejecución en el peor caso y un método de programabilidad, documentados y aplicados en toda la organización. Los presupuestos de memoria, CPU y energía están escritos con límites máximos inamovibles. La norma de seguridad funcional que rige se aplica con trazabilidad desde el requisito hasta el código y la prueba, y MISRA C o su equivalente se aplica mediante análisis estático en cada commit. Las pruebas HIL se ejecutan en el pipeline. Las actualizaciones OTA firmadas y atómicas con retroceso y arranque seguro son el nivel base exigido en todas partes.
Nivel 4: Gestionar. La organización mide y controla su parque de dispositivos frente a líneas base. Supervisa los márgenes de tiempo de ejecución en el peor caso, las distribuciones de jitter, las tasas de incumplimiento de plazos, los márgenes de memoria y energía, los hallazgos de análisis estático aún abiertos, la cobertura de evidencia de certificación y las tasas de éxito y retroceso de las actualizaciones OTA, y las compara con objetivos acordados. La deriva respecto a un presupuesto de recursos o temporización dispara una acción antes de que un dispositivo falle en el campo, y las decisiones de lanzamiento o no lanzamiento se apoyan en estos datos en lugar de en el juicio del momento. Los gestores pueden ver qué líneas de producto están listas para la auditoría y cuáles tienden a incumplir un plazo o a agotar un presupuesto.
Nivel 5: Orquestar. La determinación, la evidencia de seguridad y la protección se verifican y automatizan de forma continua. La inyección de fallos y las pruebas HIL se ejecutan en cada cambio, y los artefactos de certificación se generan como subproducto del proceso. La flota se monitorea, parchea y actualiza con seguridad a gran escala a lo largo de una vida útil prolongada. La organización adapta sus bases de ejecución, presupuestos de recursos y adopción de normas a medida que los chips se agotan, las amenazas evolucionan y la regulación cambia, reequilibrando todo el portafolio de dispositivos sobre la evidencia en lugar de reaccionar a cada crisis por separado.

Ideas para la discusión

¿Cuáles de las tareas de vuestro dispositivo son realmente en tiempo real estricto, y podéis demostrar que cada una cumple siempre su plazo?
¿Conocéis el tiempo de ejecución en el peor caso de vuestro bucle de control crítico, o solo su promedio?
¿Qué norma de seguridad funcional rige vuestro producto y cuán lejos está la evidencia actual de lo que exige?
Si mañana se descubriera un defecto grave en un dispositivo en campo, ¿cómo lo corregiríais y con qué rapidez?
¿Dónde sigue existiendo asignación de memoria dinámica en vuestro camino de control, y qué ocurre si falla a la hora 1000?
¿Cómo resistiría vuestra flota IoT a un atacante que encontrara una credencial por defecto compartida?

Conclusiones clave

El software embebido se ejecuta sobre hardware restringido, y la corrección en tiempo real depende del momento, no solo del resultado correcto.
Clasifica cada plazo como estricto, rígido o flexible, y diseña para la temporización en el peor caso, el jitter acotado y la determinación sobre la velocidad bruta.
Elige un RTOS o metal desnudo de forma deliberada, y presupuesta memoria, CPU y energía como recursos fijos y de primera clase.
Mantén los manejadores de interrupción breves, protege los datos compartidos e aísla el hardware detrás de interfaces limpias y testeables.
Adopta desde el principio la norma de seguridad funcional que exige tu dominio (IEC 61508, ISO 26262, DO-178C, IEC 62304, MISRA C), con trazabilidad completa.
Prueba con simulación y con hardware en el bucle, y construye actualizaciones OTA firmadas, con retroceso y seguridad del dispositivo, desde el día uno.

Referencias y lectura adicional

IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems
ISO 26262, Road Vehicles: Functional Safety
RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification
IEC 62304, Medical Device Software: Software Life Cycle Processes
MISRA, MISRA C: Guidelines for the Use of the C Language in Critical Systems
Michael Barr y Anthony Massa, Programming Embedded Systems
Elecia White, Making Embedded Systems
Jane W. S. Liu, Real-Time Systems
Giorgio Buttazzo, Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications
Colin Walls, Embedded Software: The Works
Philip Koopman, Better Embedded System Software
OWASP, pautas de seguridad para el Internet de las Cosas (IoT)