La tecnología nunca se detiene, y nosotros tampoco
Plataformas Mini-ITX validadas y diseñadas para una implantación fiable en entornos industriales, periféricos y de sistemas integrados.
Ingeniería de firmware de plataformas
Ingeniería de BIOS y firmware
Convierte una placa base Mini-ITX homologada en una plataforma de producto controlada. Definimos los valores predeterminados de UEFI, el comportamiento de arranque y alimentación, los controles de watchdog y a nivel de placa, los datos ACPI y SMBIOS, la configuración de Secure Boot y las normas de lanzamiento de firmware en función del hardware y el sistema operativo que realmente utilices.
El hardware arranca, pero el producto no
El desarrollo del firmware comienza una vez que la placa se enciende
Una placa base puede completar el POST y, aun así, no ser la adecuada para el producto instalado. Puede detenerse en el dispositivo de arranque incorrecto, permanecer apagada tras el restablecimiento de la alimentación de CA, mostrar opciones de configuración que los operadores sobre el terreno nunca deberían modificar, indicar una identidad de producto incorrecta o no recuperarse cuando el software de aplicación deja de responder.
La ingeniería de firmware convierte esos requisitos del producto en un comportamiento controlado de la plataforma. El punto de partida es una revisión concreta de la placa base, la versión actual del firmware, la imagen del sistema operativo, los dispositivos conectados, los requisitos de estado de alimentación, la política de seguridad y el método de actualización.
Diseño personalizado de placas Mini-ITX → Especificaciones de la plataforma →
Ámbito de aplicación del firmware a nivel de producto
Qué podemos configurar en la BIOS y en el firmware UEFI
- Configuración predeterminada
- Prioridad de arranque, dispositivos habilitados, virtualización, modo de almacenamiento, configuración de puertos serie, opciones de seguridad y valores predeterminados de producción.
- Configuración del acceso
- Ocultar los menús seleccionados, restringir los cambios, configurar el acceso de administrador y eliminar las opciones de servicio técnico que deben seguir estando controladas por fábrica.
- Política de arranque
- NVMe, SATA, USB, PXE o las opciones compatibles de prioridad de arranque HTTP, orden de reserva, retardo de arranque y condiciones de las entradas de recuperación.
- Política energética
- Recuperación tras corte de corriente alterna, activación por RTC, comportamiento de apagado suave, estados de suspensión compatibles, y fuentes de activación específicas de la placa.
- Identidad de la plataforma
- Fabricante, nombre del producto, información de serie, identificación de la placa, campos SMBIOS, datos de activos y cambios aprobados en el logotipo de arranque.
- Seguridad y actualizaciones
- Titularidad de la clave de arranque seguro, exposición del TPM, protección de la configuración, política de actualizaciones firmadas, ruta de recuperación y aprovisionamiento en producción.
Requisitos relativos al estado de alimentación
Define exactamente qué ocurre al arrancar, al apagar el sistema y al volver a conectarse a la red eléctrica
Los equipos sin supervisión no pueden depender de que un técnico pulse una tecla tras un corte de corriente. El comportamiento de arranque y alimentación debe definirse en función de la implementación real de la UEFI, la lógica de alimentación de la placa base, los dispositivos de almacenamiento conectados, la ruta de red y la imagen del sistema operativo.
| Evento | Decisión sobre el producto | Control del firmware |
|---|---|---|
| Se ha restablecido el aire acondicionado | Apagar, restablecer el estado anterior o encenderse automáticamente. | Configura la política de pérdidas de CA admitida para la configuración de producción. |
| Falta la transmisión principal | Detente, prueba con otro dispositivo, accede al modo de recuperación o inicia el sistema desde la red. | Controla el orden de arranque (BootOrder), la prioridad de los dispositivos, el tiempo de espera y el comportamiento de reserva. |
| Horario del RTC | Activar el sistema a una hora determinada, siempre que la placa admita el encendido mediante RTC. | Sincronizar la configuración del RTC, el comportamiento de activación de ACPI y el estado de alimentación. |
| Implementación remota | Arranque una imagen de implementación o de recuperación sin necesidad de intervención local. | Controlar la capacidad de arranque desde la red, la prioridad y las restricciones de configuración. |
Control a nivel del consejo de administración
El firmware solo puede controlar lo que la placa pone a su disposición
Los diseños Mini-ITX integrados suelen incluir controles que no aparecen en la BIOS de un ordenador de sobremesa. Su comportamiento depende del Super I/O, el controlador integrado, el expansor GPIO, el transceptor, el watchdog, el controlador del ventilador o el chipset que se haya instalado.
Watchdog de hardware
Define el estado de activación, el tiempo de espera admitido, la acción de reinicio, el traspaso de la aplicación y el comportamiento tras el reinicio utilizando el dispositivo watchdog real.
Modos GPIO y serie
Define la dirección y el estado de los GPIO compatibles, además de los modos seleccionables RS-232/422/485, para los que la placa incluye la ruta de transceptor necesaria.
Control de ventiladores y temperatura
Define la fuente del sensor, el control PWM o de tensión compatible, el comportamiento en caso de fallo del ventilador y los umbrales de firmware que ofrece la plataforma.
Datos del firmware al sistema operativo
ACPI y SMBIOS deben describir el hardware incluido en el envío
El firmware proporciona información estandarizada que el sistema operativo y el software de gestión utilizan para la configuración, la gestión de la alimentación y el inventario de hardware. No basta con que la estructura sea correcta; los datos deben coincidir exactamente con la placa de producción y la identidad del producto.
| Interfaz | Qué incluye el firmware | Impacto del producto |
|---|---|---|
| ACPI | Descripciones de dispositivos, recursos de alimentación, métodos de activación y tablas de plataformas. | Comportamiento en modo de suspensión, de activación, térmico, de botones y de los dispositivos tal y como se presenta al sistema operativo. |
| SMBIOS | Información sobre el sistema, la placa, el firmware, el procesador, la memoria, el puerto serie y el fabricante de equipo original (OEM). | Inventario de activos, herramientas de servicio, gestión de dispositivos e identificación de productos. |
Revisión de los requisitos de firmware
¿Tienes una versión revisada de la placa y una imagen del sistema operativo Golden?
Envíe la revisión de la placa base, la versión actual de la BIOS, el sistema operativo, la secuencia de arranque, el comportamiento de recuperación tras un corte de corriente, los requisitos del watchdog, la política de seguridad, la lista de dispositivos y las restricciones de actualización en campo.
Confianza previa al arranque
El arranque seguro requiere que se definan el propietario de la clave y la ruta de actualización
El arranque seguro en producción no es simplemente una opción que se puede activar o desactivar. El proyecto debe definir quién controla la clave de plataforma, qué claves de intercambio de claves son fiables, qué datos se incluyen en la base de datos de firmas permitidas, cómo se incorporan a dbx las imágenes revocadas, y cómo se garantiza la recuperabilidad de las actualizaciones autorizadas de los campos.
Los requisitos actuales de UEFI establecen que el formato de la clave de plataforma de arranque seguro (Secure Boot Platform Key) debe ser, como mínimo, RSA-2048, y exigen que los hash de las imágenes UEFI almacenados en dbx utilicen, como mínimo, SHA-256. Se trata de requisitos criptográficos mínimos, no de una política completa de seguridad del producto.
- Titularidad de PK
- Decida si es el fabricante de equipos originales (OEM), el cliente u otro propietario autorizado quien controla la clave de la plataforma utilizada para establecer la titularidad del arranque seguro.
- KEK, db y dbx
- Defina las autoridades de actualización de confianza, las imágenes permitidas, las firmas revocadas y el método de aprovisionamiento utilizado en producción.
- TPM 2.0
- Poner a disposición y configurar el TPM de la plataforma, cuando sea compatible, con la titularidad y la política de implementación definidas por el sistema final.
- Recuperación
- Mantener una ruta de recuperación autorizada para las actualizaciones fallidas o los cambios de claves, sin eludir la política de confianza prevista.
Control del firmware de producción
Publica el binario junto con su tabla de configuraciones, valores predeterminados y registro de cambios
Un archivo de firmware solo se convierte en un artefacto de producción cuando se controlan su identidad y su compatibilidad. El binario publicado debe estar vinculado a la revisión de la placa base, la configuración predeterminada, el aprovisionamiento de seguridad, el método de actualización y el motivo del cambio.
- Identidad binaria Anota la versión del firmware, la revisión exacta de la placa, el tamaño del archivo, el hash SHA-256 y la fecha de lanzamiento.
- Valores predeterminados de producción Bloquea los valores de configuración enviados por separado de los ajustes de depuración de ingeniería y de los cambios realizados por los técnicos locales.
- Modificar registro Identificar las funciones modificadas, el hardware afectado o las versiones del sistema operativo, las restricciones conocidas y las pruebas de regresión necesarias.
- Actualización y recuperación Defina el método de actualización aprobado, la política de versiones, las precauciones en caso de corte de suministro eléctrico, las normas de reversión y la ruta de recuperación.
Especificaciones de referencia
Interfaces de firmware y especificaciones de referencia
- UEFI 2.11
- Especificación UEFI actual relativa al entorno estandarizado de firmware previo al sistema operativo, los servicios de arranque, los servicios en tiempo de ejecución, las variables y los protocolos.
- ACPI 6.6
- Especificación ACPI vigente para la configuración de dispositivos dirigida por el sistema operativo, la descripción de la plataforma, la gestión de la energía y los eventos del sistema.
- SMBIOS 3.9.0
- Especificación de la DMTF para la información de gestión estandarizada que proporciona el firmware del sistema sobre la plataforma y el hardware instalado.
- TCG TPM 2.0 v185
- Especificación de la biblioteca TPM 2.0 de marzo de 2026, que define la arquitectura, las estructuras y los comandos utilizados por las implementaciones de TPM 2.0.
Página de lanzamientos de firmware
Comprueba que la versión exacta del firmware que pretendes distribuir sea la correcta
El proceso de ingeniería del firmware concluye con un binario definido y una configuración de producción. A continuación, la validación de ingeniería ejecuta esa versión concreta en la placa de destino con la imagen del sistema operativo prevista, los periféricos, los estados de alimentación, la configuración de seguridad, el método de actualización y la ruta de recuperación.
PREGUNTAS FRECUENTES
Preguntas sobre ingeniería de BIOS y firmware
¿Se pueden personalizar los ajustes de la BIOS?
Sí, siempre que el firmware lo permita. Entre los cambios habituales se incluyen la prioridad de arranque, la activación de dispositivos, el comportamiento de la alimentación, la configuración serie, la virtualización, las opciones de seguridad y el acceso a la configuración.
¿Puede la BIOS encenderse automáticamente?
Sí, en las placas compatibles. El firmware permite configurar la recuperación ante corte de corriente alterna para que el dispositivo se encienda, permanezca apagado o recupere el estado anterior una vez restablecida la alimentación.
¿Se pueden personalizar los ajustes del sistema de supervisión?
Sí, siempre que la placa incorpore un watchdog de hardware compatible. Los intervalos de tiempo de espera disponibles y las acciones de reinicio dependen del controlador instalado y de la implementación del firmware.
¿Se pueden personalizar las claves de arranque seguro?
Sí, en el firmware compatible. El aprovisionamiento de PK, KEK, db y dbx puede definirse en función de la titularidad de las claves por parte del fabricante o del cliente y de la política de actualización requerida.
¿Cómo se gestionan las actualizaciones de la BIOS?
Utiliza un binario con número de revisión, un resumen verificado, un método de flasheo aprobado, un registro de cambios, normas de compatibilidad y una ruta de recuperación definida antes de lanzar una actualización al entorno de producción.