El software de aplicaciones tiene una relación cómoda con los errores. Algo se rompe, se escribe un arreglo, y esa misma tarde se publica.
Un conjunto de reglas distinto
El software embebido vive dentro de un producto. Un controlador de motor, una bomba de infusión médica, un vehículo, un termostato, un satélite, un sensor de fábrica. Las reglas cambian en cuatro sentidos, y cada uno de ellos moldea cómo se hace el trabajo.
El hardware es fijo. Si el procesador es demasiado lento, la memoria demasiado pequeña o el periférico equivocado, no puedes actualizar esa unidad. Solo puedes cambiar el software, y con el tiempo tampoco puedes cambiar eso.
Los recursos son limitados y pequeños. Kilobytes en lugar de gigabytes en muchos productos. La asignación dinámica de memoria a menudo está directamente prohibida, porque un fallo de asignación no tiene una respuesta aceptable y la fragmentación a lo largo de años de funcionamiento es impredecible.
Los plazos son reales. Incumplir uno puede significar que un motor recibe una orden incorrecta, que un lazo de control se vuelve inestable, o que una función de seguridad no se dispara.
El fallo es físico. Cuando falla el software de aplicaciones, aparece un mensaje. Cuando falla el software embebido, algo se mueve, algo se calienta o algo se para.
La disciplina no la define el lenguaje. La define no poder cambiar de opinión más tarde.
Qué abarca esta dirección
El alcance: microcontroladores, desarrollo de firmware, sistemas operativos en tiempo real, interfaces de hardware y software, controladores de dispositivo y seguridad embebida.
Cuatro áreas.
Interfaz con el hardware. Registros, periféricos, interrupciones, buses de comunicación, y la lectura de hojas de datos que va con ellos.
Arquitectura de firmware. Bucles bare metal, sistemas operativos en tiempo real, descomposición en tareas y las decisiones de planificación que hay debajo.
Programación restringida. Trabajar dentro de presupuestos de memoria, temporización y potencia, y demostrar que lo has hecho.
Ciclo de vida. Mecanismos de actualización, seguridad, diagnóstico y mantenimiento a largo plazo.
Tiempo real significa plazos, no velocidad
El término se malinterpreta constantemente. Tiempo real no es una afirmación sobre el rendimiento. Es una afirmación sobre la previsibilidad.
Un sistema de tiempo real estricto tiene que completar una acción dada antes de un plazo dado, absolutamente siempre. El rendimiento medio es irrelevante. Un sistema que responde en cincuenta microsegundos de media y en cinco milisegundos una vez por hora no ha sido rápido la mayor parte del tiempo. Ha fallado, una vez por hora.
De ahí se derivan tres conceptos, que son el núcleo de la disciplina.
Tiempo de ejecución en el peor caso. No el típico, no el medido en una ejecución normal. El tiempo máximo que puede tardar el código, con cada rama tomada de la peor forma, cada fallo de caché y cada interrupción llegando en el peor momento posible. El diseño se hace contra esa cifra.
Latencia de interrupción y jitter. Cuánto tarda el sistema en responder a un evento externo, y cuánto varía eso. En aplicaciones de control el jitter importa tanto como la latencia, porque un lazo de control asume un intervalo de muestreo fijo y se degrada cuando no lo consigue.
Prioridad y planificación. Qué se ejecuta cuando varias cosas están listas, y qué pasa cuando una tarea de baja prioridad retiene un recurso que necesita una de alta prioridad. Esa situación, la inversión de prioridad, ha causado fallos reales y bien documentados en sistemas ya entregados, y los mecanismos que la evitan existen precisamente porque no es obvia.
Los fallos que solo existen en el trabajo embebido
Una categoría de fallo que los desarrolladores de aplicaciones rara vez se encuentran, y que los ingenieros embebidos se encuentran constantemente.
Condiciones de carrera con interrupciones. El código principal y un manejador de interrupción tocando la misma variable, con la interrupción llegando entre la lectura y la escritura. Aparece una vez de cada diez mil ejecuciones y desaparece en cuanto añades una instrucción de impresión.
Desbordamiento de pila. Muchos sistemas pequeños no tienen protección de memoria, así que la pila crece silenciosamente hacia otros datos y el síntoma aparece en algún sitio sin relación, mucho después.
Corrupción de memoria. Un error de puntero o un desbordamiento de búfer que daña datos de un subsistema completamente distinto, produciendo un fallo cuya ubicación no tiene nada que ver con su causa.
Comportamiento dependiente de la temporización. Código que funciona a una velocidad de reloj, un nivel de optimización del compilador o una temperatura, y falla en otra.
Heisenbugs. Fallos que desaparecen bajo el depurador, porque conectarlo cambia la temporización que los causó.
La consecuencia práctica es que la depuración embebida depende de herramientas que observan sin perturbar: trazas de hardware, analizadores lógicos, osciloscopios e instrumentación integrada en el propio producto. Aprender a leer una señal en un osciloscopio no es nostalgia. A menudo es la única forma de ver el fallo.
Dónde encaja dentro del dominio
Sistemas embebidos y hardware de computación es la quinta de las nueve direcciones del dominio de semiconductores, electrónica y cuántica de Astra Trainer. Se empareja con ingeniería electrónica, porque casi toda placa lleva firmware y los dos perfiles comparten una frontera por la que discuten a menudo, y con diseño de chips, donde los programas de sistema en chip necesitan a los dos lados con soltura.
También conecta hacia fuera con robótica, donde la capa de control es embebida, con manufactura avanzada para control industrial, y con medicina y salud digital, donde los dispositivos arrastran obligaciones normativas. Aquí puedes ver las nueve direcciones.
Lanzar el producto es el inicio de una obligación de diez años
Un sensor industrial, un dispositivo médico, un vehículo o una pieza de infraestructura de un edificio va a estar en servicio una década o más. Si se conecta a una red, todo ese periodo es una exposición.
Tres problemas que separan la seguridad embebida de la seguridad de servidor, y ninguno tiene una respuesta limpia.
Actualizar es difícil y arriesgado. Los dispositivos pueden ser inalcanzables, funcionar con batería, tener ancho de banda limitado o ser físicamente inaccesibles. Una actualización que falla a medio camino puede dejar un dispositivo inutilizable, lo que para algunos productos significa una visita técnica y para otros significa una pérdida total. La actualización segura, reanudable y verificada es un problema de diseño que hay que resolver antes de que salga la primera unidad, porque no se puede añadir después a dispositivos que ya están en el campo.
La criptografía tiene que aguantar. Las claves y los algoritmos elegidos hoy se quedan en los dispositivos toda su vida de servicio. Aquí es donde esta dirección se encuentra con comunicación cuántica, sensado y seguridad, y la respuesta es la agilidad criptográfica: diseñar para poder sustituir el algoritmo en lugar de asumir que la primera elección es permanente.
La obligación es cada vez más legal. Varias jurisdicciones han introducido requisitos para productos conectados, entre ellos la prohibición de contraseñas universales por defecto, la obligación de declarar durante cuánto tiempo se darán actualizaciones de seguridad, y procesos de notificación de vulnerabilidades. Los detalles varían según el mercado y cambian, pero la tendencia es constante: el soporte de seguridad está pasando de ser un gesto de buena voluntad a un compromiso declarado con una duración adjunta.
Los puestos, uno a uno
Ingenieros de software embebido. El puesto amplio.
Ingenieros de firmware. Los más cerca del hardware.
Desarrolladores de controladores de dispositivo.
Ingenieros de sistemas en tiempo real, para aplicaciones críticas en temporización y de control.
Ingenieros de Linux embebido, una especialidad distinta del trabajo con microcontroladores.
Ingenieros de integración de hardware y software, que ponen en marcha placas nuevas.
Ingenieros de seguridad embebida. Arranque seguro, gestión de claves, infraestructura de actualización.
Ingenieros de seguridad funcional, para sistemas de automoción, industriales y médicos.
Ingenieros de pruebas y validación embebida, incluido hardware-in-the-loop.
A quién se puede reconvertir hacia aquí
Ingenieros de software de aplicaciones. La cantera más grande. Aportan estructura, disciplina de herramientas y hábitos de control de versiones que a los equipos embebidos a menudo les faltan. Lo que hay que enseñar de forma deliberada es el modelo de hardware: registros, interrupciones, temporización, y por qué la asignación dinámica se mira con sospecha.
Técnicos e ingenieros de electrónica. La reconversión desde el otro lado; ya tienen la intuición de hardware y les falta la estructura de software.
Personal de control industrial y automatización. Los programadores de autómatas (PLC) ya entienden el comportamiento en tiempo real, el escaneo determinista y las restricciones industriales.
Ingenieros de pruebas. Hacia validación y pruebas hardware-in-the-loop.
Ingenieros de TI y de redes. Hacia el trabajo con dispositivos conectados y seguridad embebida, donde el conocimiento de protocolos se traslada y las restricciones de recursos no.
Ingenieros de servicio de campo. Hacia ingeniería de diagnóstico y soporte, porque tienen el conocimiento de fallos en campo que nadie en desarrollo tiene.
Seguridad funcional y dispositivos regulados. El software embebido en dispositivos médicos, vehículos, aviación, maquinaria industrial y sistemas instrumentados de seguridad está regido por normas vinculantes y regímenes normativos con requisitos de proceso de desarrollo, documentación, verificación y control de cambios. Los niveles de integridad de seguridad se asignan mediante evaluación formal, y la certificación la otorgan organismos competentes. La formación desarrolla capacidad de ingeniería y la conciencia de dónde se aplican estas obligaciones. No otorga certificación, ni condición de evaluador de seguridad, ni autoridad para liberar software en un producto regulado.
Qué llevarte de todo esto
El trabajo embebido lo definen las restricciones, no un lenguaje. Hardware fijo, memoria pequeña, plazos estrictos y una vida larga.
Tiempo real significa cumplir un plazo siempre. El número que importa es el tiempo de ejecución en el peor caso, no la media.
Los fallos característicos son de temporización, concurrencia y memoria, y se esconden de los depuradores, por lo que las herramientas de observación de hardware siguen siendo centrales.
La actualización y la agilidad criptográfica hay que diseñarlas antes de que salga la primera unidad, porque no se pueden añadir después a dispositivos que ya están en el campo.
Y las dos mejores fuentes de nuevos ingenieros embebidos llegan desde direcciones opuestas: los desarrolladores de aplicaciones, a quienes les falta el modelo de hardware, y los técnicos, a quienes les falta la estructura de software.
¿Qué significa realmente «tiempo real»?
Cumplir un plazo especificado siempre, no ir rápido. Un sistema que responde rápido de media y a veces tarde ha fallado, porque en aplicaciones de control y seguridad la respuesta tardía es la que importa.
¿Por qué se evita la asignación dinámica de memoria en sistemas embebidos?
Porque la asignación puede fallar y a menudo no hay una respuesta aceptable ante ese fallo, y porque la fragmentación a lo largo de años de funcionamiento continuo es difícil de predecir. Muchos proyectos asignan de forma estática al arrancar en su lugar.
¿Por qué es tan difícil reproducir los fallos embebidos?
Porque muchos dependen de la temporización. Las condiciones de carrera de interrupción, los desbordamientos de pila y la corrupción de memoria producen síntomas alejados de su causa, y conectar un depurador cambia la temporización que los creó.
¿Por qué la seguridad embebida hay que diseñarla con antelación?
Porque un dispositivo puede estar en servicio una década, y el mecanismo de actualización, la gestión de claves y la capacidad de sustituir los algoritmos criptográficos no se pueden añadir a unidades ya desplegadas en el campo.
¿Pueden los desarrolladores de aplicaciones pasarse al trabajo embebido?
Sí, y aportan estructura y disciplina de herramientas muy útiles. La brecha que hay que enseñar de forma explícita es el modelo de hardware: registros, interrupciones, comportamiento de temporización y restricciones de recursos.