Servicios de desarrollo de firmware y software embebido

La decisión depende del presupuesto de hardware, los requisitos de tiempo real, el perfil regulatorio y la estrategia de actualización en campo. Bare-metal (sin planificador) cuando hay un único bucle de control ajustado en un Cortex-M0/M0+, RAM de menos de un kilobyte y la duración de la batería es la preocupación dominante — habitual en sensores y periféricos BLE. Zephyr RTOS cuando se necesita un planificador en tiempo real, una pila de red (TCP/IP, BLE, Thread, Matter) y varias tareas concurrentes, pero el presupuesto de RAM es de 32–512 KB y se quiere un proyecto gobernado por la Linux Foundation con soporte a largo plazo. FreeRTOS para stacks heredados y donde se requiera integración con Amazon FreeRTOS / AWS IoT. Linux embebido con Yocto (o Buildroot para sistemas más pequeños) cuando hay un procesador de aplicaciones (Cortex-A / RISC-V), ≥64 MB de RAM y se necesita una pila de red completa, un runtime de contenedores o bibliotecas de terceros que asumen POSIX.

Ambas cosas, con clara preferencia por las segundas como punto de partida. Partimos de la capa Yocto de referencia del fabricante de silicio (meta-st-stm32mp, meta-ti, meta-imx, meta-nxp, meta-raspberrypi, meta-rockchip, etc.) y construimos un meta-layer a medida para su producto. Las recetas se fijan por versión a una versión LTS de Yocto (Kirkstone / Scarthgap) y los builds de bitbake se ejecutan de forma reproducible en CI (GitLab o GitHub Actions con caché sstate en S3 — sin caché sstate, un build limpio de Yocto son 90 minutos de coste puro de CI). Entregamos un SDK para que su equipo de aplicación pueda hacer compilación cruzada sin tocar el BSP, y mantenemos la capa como parte del proyecto.

MISRA C:2012 (con las directivas de la Enmienda 3) es nuestra línea base de análisis estático por defecto en todos los proyectos embebidos — aplicada con PC-lint Plus, Cppcheck Premium o Coverity en CI, con las desviaciones documentadas y revisadas. Para productos sanitarios entregamos conforme a IEC 62304 (ciclo de vida del software de productos sanitarios) con trazabilidad completa desde los requisitos pasando por el diseño, el código y las pruebas unitarias y de integración en DOORS o Polarion; hemos entregado auditorías de clase B y dado soporte a las de clase C. Para automoción trabajamos con ISO 26262 ASIL-B y contribuimos a casos de seguridad ASIL-D bajo un responsable de seguridad funcional. Para industria nos ocupamos de IEC 61508 SIL-2. No nos autocertificamos — la aprobación por un evaluador independiente corresponde a su organismo de auditoría; nosotros preparamos las evidencias.

La OTA se diseña antes de elegir el silicio — las OTA añadidas en fases tardías son la forma en que se inutilizan las flotas. El Linux embebido usa particionado A/B (RAUC, Mender o SWUpdate) con rollback atómico ante un fallo de arranque, paquetes de actualización firmados (normalmente ed25519 o ECDSA P-256) y un mecanismo de actualización delta para dispositivos limitados por celular. Los dispositivos con RTOS usan MCUboot para actualizaciones en la ranura secundaria con firma de imágenes y contadores anti-rollback. El backend es el suyo o IoT de hiperescala (AWS IoT Device Management, Azure Device Update for IoT Hub, servidor Mender). Diseñamos la política de despliegue por fases (canary → 1 % → 10 % → 100 %) y la vía de recuperación de fallos en campo antes de que salga la primera unidad de producción.

BLE 5.x con la pila de Zephyr en Nordic nRF52/nRF53/nRF54 y Silicon Labs EFR32, o SoftDevice cuando lo exijan certificaciones específicas del fabricante. Matter (antes Project CHIP) con el SDK de Matter oficial de código abierto sobre transporte Thread (OpenThread) o Wi-Fi — hemos llevado a la certificación CSA dispositivos Matter sobre Thread puestos en servicio. LoRaWAN con la pila Semtech LoRaMAC-node en STM32WL o chips complementarios SX126x, con backends TTN / ChirpStack. Protocolos propietarios sub-GHz (Wi-SUN, Z-Wave) cuando el caso de uso justifica el coste de BOM. Hacemos preevaluación regulatoria (FCC Part 15, CE RED, MIC) antes del tape-out y coordinamos la certificación completa en laboratorio con un socio (TÜV, Element, Eurofins).

El trabajo embebido e IoT es de alcance cerrado, escalonado según la madurez IoT, todo incluido y presupuestado en USD. Un MVP de IoT cuesta desde $3,500 (primer dispositivo conectado funcional: una función principal, firmware, conectividad básica); la gestión de dispositivos, desde $5,800 (OTA A/B firmada con rollback, aprovisionamiento, configuración remota); la telemetría con panel, desde $9,200 (ingesta de sensores, backend en la nube, panel de monitorización, alertas); una plataforma IoT completa, desde $11,500 (gestión multidispositivo, roles, integraciones, evidencias de seguridad, CI sobre hardware real). La cifra exacta depende de su perfil regulatorio (IEC 62304, ISO 26262, IEC 61508), del alcance de RTOS frente a Linux embebido, de la certificación de radio y conectividad (FCC Part 15, CE RED para BLE / Matter / LoRaWAN) y de la madurez del silicio. Usted ve el presupuesto desglosado tras una evaluación de alcance gratuita y lo aprueba antes de que se escriba una sola línea de código. El código fuente, el BSP y las capas de Yocto están en sus repositorios desde el primer día; el traspaso a producción incluye utillajes de pruebas de fabricación, el SDK de Yocto y un pipeline de releases en CI — sin recargo por intermediación, sin sobrecostes por herramientas y con las tasas de certificación en laboratorio regulatorio en sus propias cuentas.

Sí — la asunción de proyectos brownfield es una parte importante de nuestro trabajo embebido. Empezamos con una auditoría de firmware: reproducibilidad del build (¿podemos reconstruir desde el código fuente el binario exacto que usted distribuye?), fijación de versiones de la cadena de herramientas y del SDK, una línea base de análisis estático MISRA C:2012 para cuantificar la deuda existente y una revisión del diseño de OTA, arranque seguro y gestión de secretos. Recibe un informe escrito de hallazgos con un plan de remediación priorizado por riesgo antes de que toquemos una línea de código. Los detonantes habituales son un proveedor o contratista original que ha dejado de responder, un BSP de Yocto congelado en un kernel al final de su vida útil o un dispositivo que necesita un cumplimiento del Reglamento de Ciberresiliencia de la UE para el que nunca fue diseñado. También podemos hacer la auditoría como un proyecto independiente, sin compromiso de reconstrucción.

Somos una casa de firmware y software embebido, no un estudio de diseño de PCB — pero no trabajamos aislados del hardware. Dirigimos la selección de silicio (lista corta de MCU/SoC con coste de BOM y presupuestos de consumo activo/reposo), revisamos su esquemático y el pin-mux desde el punto de vista de la viabilidad del firmware y escribimos el firmware de puesta en marcha y de pruebas de fabricación de la placa. Para el trazado físico de la PCB, la adaptación de RF y el diseño EMC trabajamos junto a su equipo de EE o a uno de nuestros socios de hardware, y nos hacemos cargo de la frontera del software de extremo a extremo: BSP, bootloader, drivers, firmware de aplicación y OTA. Si usted llega con una placa de desarrollo y una hoja de datos, es un punto de partida normal.

El consumo es una restricción de diseño desde la primera semana, no un ajuste de última fase. Elaboramos un presupuesto energético sobre silicio real — corrientes activa, en reposo y en sueño profundo medidas con un analizador de potencia (Otii, Nordic PPK2 o equipo de laboratorio), no valores típicos de la hoja de datos. El firmware se arquitectura en torno al estado de reposo viable más bajo: desactivación del reloj de periféricos, DMA en lugar de sondeo por CPU, activación por eventos en vez de bucles activos y ciclo de trabajo de la radio (ajuste del intervalo de conexión y de la publicidad BLE, o almacenamiento y reenvío en celular). Le damos una cifra proyectada de duración de la batería vinculada a un perfil de uso definido y la validamos con una pila de botón o un pack real, porque un dispositivo que cumple su especificación de consumo sobre el papel y falla en campo es una retirada de producto a la espera de ocurrir.

La seguridad se diseña desde el origen, con el Reglamento de Ciberresiliencia de la UE como línea base para los dispositivos conectados que se venden en la UE. Implementamos una cadena de arranque seguro con la raíz de confianza en OTP/eFuse, imágenes de firmware firmadas (ed25519 o ECDSA P-256) con contadores anti-rollback y secretos cifrados en reposo mediante el elemento seguro del SoC, un HSM o un TPM. Los paquetes OTA se firman y se verifican antes de aplicarse. En el plano del proceso recibe una SBOM, un modelo de amenazas documentado, una política de divulgación de vulnerabilidades y un compromiso de actualizaciones de seguridad — los artefactos que pide una evaluación de la conformidad de la CRA. El aprovisionamiento y la inyección de claves se hacen en un flujo de fabricación controlado, de modo que las claves privadas nunca estén en el árbol de código fuente. En el trabajo médico y de automoción, esto encaja con la pista de evidencias de IEC 62304 / ISO 26262 en lugar de ir a su lado.