Durante décadas, la relación entre un convertidor de potencia y el sistema que lo rodeaba fue casi unidireccional: la carga pedía potencia y el convertidor la suministraba. La señalización se limitaba a una señal de habilitación, una de fallo y, como mucho, una consigna de tensión.

En el rack de IA ese modelo ya no basta. Con potencias por rack que crecen hacia arquitecturas de distribución a 800 VDC (las analizamos en La revolución del 800 VDC), el gestor del data center necesita saber en todo momento cuánta potencia entrega cada etapa de conversión, con qué margen térmico trabaja y si hay alarmas. El convertidor deja de ser un elemento pasivo y pasa a ser un nodo gestionado.

Esta nota explica qué protocolos intervienen en esa cadena de gestión, dónde encaja cada uno y qué capacidades de firmware necesita un convertidor para integrarse en ella.

La cadena de gestión: del gestor del data center al convertidor

No existe un único protocolo que conecte el gestor del data center con el convertidor. La gestión se organiza en capas, y en cada una se usa un estándar distinto:

Para el fabricante del convertidor, la consecuencia práctica es clara: su equipo debe hablar PMBus de forma completa y exponer la información que las capas superiores traducirán a Redfish, ya sea directamente o a través del controlador de la shelf o del rack.

PMBus: el lenguaje del propio convertidor

PMBus es el estándar abierto de comunicación digital para fuentes de alimentación y convertidores. Su revisión publicada vigente es la 1.5. Define un conjunto común de comandos para leer medidas y estados y para configurar el equipo, por ejemplo:

• Medidas: READ_VIN, READ_IOUT, READ_POUT, READ_TEMPERATURE_1.
• Estado y alarmas: STATUS_WORD y los registros de estado específicos (tensión, corriente, temperatura).
• Configuración: umbrales de aviso y de fallo, y consignas de funcionamiento.

Un convertidor con una implementación PMBus completa y bien documentada simplifica la integración: el controlador de rack puede leer sus datos sin desarrollos a medida.

Redfish: la vista de la instalación

Redfish es el estándar de la DMTF para la gestión de infraestructura mediante una API REST con datos en JSON. Para la potencia define esquemas específicos, entre ellos PowerSubsystem, PowerSupply y PowerSupplyMetrics, además de un modelo genérico de sensores.

El convertidor no necesita implementar Redfish por sí mismo en todos los casos. Lo habitual es que el controlador de la shelf o del rack recoja los datos PMBus o Modbus de cada unidad y los publique en Redfish. Lo imprescindible es que el convertidor ofrezca toda la información que esos esquemas esperan: potencia, tensiones, corrientes, temperaturas, eficiencia y estado.

SCMI: dónde encaja realmente

Arm SCMI (System Control and Management Interface) es una interfaz estándar e independiente del transporte entre el software del sistema y el firmware de control de la plataforma. Su ámbito natural es el interior del nodo de cómputo, no el enlace con la fuente de alimentación. Define protocolos para descubrimiento (Base), dominios de potencia, gestión de potencia del sistema, rendimiento, relojes, sensores, reset, tensión y limitación de potencia (Powercap).

El protocolo Powercap incluye, entre otros, los comandos POWERCAP_CAP_GET y POWERCAP_CAP_SET para leer y fijar el límite de potencia de un dominio, y POWERCAP_MEASUREMENTS_GET para leer la potencia media. La versión 4.0 de la especificación, todavía en fase de borrador, añade límites de potencia concurrentes (CPL, Concurrent Power Limits) por dominio y un protocolo de telemetría.

¿Qué relación tiene con el convertidor? La limitación de potencia la ejecuta el silicio a través de SCMI, pero la decisión de limitar depende de la telemetría de toda la cadena de potencia, incluida la del convertidor: si su margen térmico o de potencia se agota, el gestor puede reducir el consumo del cómputo antes de que la etapa de conversión trabaje fuera de su zona segura.

Control térmico en lazo cerrado

En los racks de IA con refrigeración líquida, el control térmico suele organizarse en dos lazos anidados. El lazo interno, en la unidad de distribución de refrigerante (CDU), mantiene la temperatura del refrigerante cerca de su consigna actuando sobre bombas y válvulas. El lazo externo, en el gestor, ajusta esa consigna y los límites de potencia en función de la telemetría térmica de los racks.

Para participar en el lazo externo, el convertidor debe publicar la temperatura de sus semiconductores de potencia, la de sus componentes magnéticos y su eficiencia instantánea. Con esos datos, el gestor puede decidir si hay margen para un aumento transitorio de demanda o si conviene limitar la potencia para proteger la fiabilidad del equipo.

Qué debe ofrecer el firmware del convertidor

• Telemetría PMBus completa: tensión y corriente de entrada y salida, potencia, temperaturas internas y registros de estado.
• Interfaz con el controlador de rack en el protocolo que especifique el integrador, por ejemplo Modbus sobre RS-485 o CAN.
• Información compatible con el modelo Redfish de potencia, publicada directamente o a través del controlador.
• Límites y derating configurables, con notificación de eventos y alarmas.
• Latencia de telemetría coherente con la dinámica de control que defina el integrador.
• Actualización de firmware controlada y trazable.

Referencias

• Arm — System Control and Management Interface (SCMI), especificación DEN0056.
• DMTF — Redfish: esquemas PowerSubsystem, PowerSupply y PowerSupplyMetrics.
• PMBus — Power Management Bus Specification, revisión 1.5.
• Open Compute Project — especificaciones Open Rack V3.