Una actualización de firmware del inversor solo está completa cuando se han verificado las funciones requeridas del proyecto, no cuando termina la barra de progreso. El dispositivo puede reiniciarse normalmente mientras ha cambiado un ajuste de exportación, una interfaz de batería, una configuración en paralelo o un comportamiento de respaldo. Una carga exitosa demuestra que el software se instaló; no demuestra que la instalación siga prestando el servicio contratado.
Para los EPC y distribuidores, trate la actualización como un cambio de ingeniería controlado. Documente el motivo, confirme la combinación exacta de hardware y firmware, guarde la configuración aprobada y decida qué funciones deben volver a probarse. Aplique las actualizaciones urgentes de seguridad o requeridas por el fabricante mediante una revisión de riesgos adecuada; no utilice el control de cambios como excusa para ignorar una instrucción de seguridad o protección.
Defina el motivo de la versión
Distinga entre una corrección de seguridad, un cambio requerido por el fabricante, una solución de fallos y una nueva función. Cada uno tiene una justificación diferente y puede requerir una planificación distinta. Una función que es irrelevante para el proyecto no es, por sí misma, evidencia de que una instalación en funcionamiento se beneficie de una actualización inmediata.
Antes de actualizar un inversor solar HMX, solicite las notas de la versión aplicables y el procedimiento de actualización compatible para su modelo exacto y revisión de hardware. Confirme cualquier dependencia relacionada con el BMS de la batería, el medidor, la pasarela de comunicaciones o el controlador. No asuma que un archivo para un modelo similar sea aceptable.
Designe a una persona con nombre para autorizar el cambio y a otra persona con nombre para confirmar el resultado. En un proyecto pequeño, estas pueden ser miembros del mismo equipo de instalación, pero las responsabilidades deben quedar registradas. El cliente debe saber si la actualización interrumpe el servicio y qué arreglos temporales son necesarios.
| Registro | Información requerida | Decisión de versión a la que respalda |
|---|---|---|
| Propósito | Corrección, requisito o función del proyecto pertinente | Por qué se necesita este cambio |
| Identidad del equipo | Modelo, número de serie, hardware y versiones de software instaladas | Si el archivo de destino es aplicable |
| Dependencias | Versiones compatibles de batería, medidor, controlador y dispositivos en paralelo | Si la combinación del sistema es compatible |
| Línea base de configuración | Ajustes aprobados de exportación, respaldo, carga y acceso | Qué debe permanecer correcto después de la actualización |
| Ventana de servicio | Interrupción prevista y arreglos con el cliente | Cuándo puede realizarse el cambio de forma segura |
| Ruta de recuperación | Contactos de recuperación y soporte aprobados por el fabricante | Cómo se gestionará un cambio fallido |
No asuma que todas las actualizaciones conservan los ajustes
Una comparación útil proviene de dos documentos vigentes dentro de la misma biblioteca del fabricante. La guía general de firmware de VictronConnect describe la conservación de los ajustes aplicables y el historial, mientras que dirige explícitamente los productos VE.Bus a una guía separada. Leer solo la declaración general pasaría por alto un límite importante del producto.
La guía separada de VictronConnect para productos VE.Bus advierte que su proceso de actualización restablece los ajustes a los valores predeterminados de fábrica y requiere que las configuraciones de múltiples unidades se reprogramen. Ese comportamiento es específico de los productos y el proceso documentados; no es una afirmación sobre los equipos HMX.
La lección de adquisición es clara: pregunte si este modelo y método de actualización conservan, migran o restablecen cada ajuste pertinente. Guarde una exportación de configuración cuando sea compatible, junto con registros legibles por humanos de los ajustes esenciales. Un archivo que no puede restaurarse a la nueva versión no es un plan de recuperación completo.
Registre los valores aprobados actuales en lugar de copiar los valores predeterminados de un manual. Los valores predeterminados pueden no coincidir con la aprobación de red del sitio, los límites de la batería o el diseño de respaldo. Restaurar una configuración antigua también requiere revisión si la nueva versión cambia el significado o el rango admitido de un parámetro.
Estructure la reprueba en torno a lo que el proyecto realmente utiliza
Elija las pruebas de regresión antes de instalar la actualización. Incluya las funciones afectadas por las notas de la versión y las funciones cuya falla sería importante para el cliente. Un proyecto de almacenamiento puede depender de los permisos de carga de la batería y las transiciones de respaldo incluso cuando la actualización se describe como una mejora de comunicaciones.
Primero mapee las relaciones entre los equipos. La distinción entre funciones de BMS, conversión de potencia y gestión de energía ayuda a identificar qué dispositivo proporciona un límite o un comando operativo. Un número visible en la pantalla no establece que el inversor siga el valor permitido más reciente.
| Función utilizada por el proyecto | Enfoque de verificación | Evidencia a conservar |
|---|---|---|
| Operación de la batería | Comunicaciones, límites activos de carga/descarga y gestión de alarmas | Versiones de dispositivos coincidentes y registros operativos observados |
| Control de exportación | Interpretación del medidor, punto de consigna y respuesta dentro del acuerdo aprobado | Configuraciones y resultado medido de la prueba |
| Suministro de respaldo | Transferencia aprobada, cargas reales y retorno a la red | Cronología de eventos y observaciones del servicio |
| Operación en paralelo o multifásica | Combinación de versiones soportada y roles configurados | Topología y resultados funcionales aprobados |
| Monitoreo remoto | Telemetría actual, alarmas y acceso permitido | Marcas de tiempo recientes y ruta de notificación probada |
| Despacho programado | Zona horaria, ventanas operativas y permisos | Política final y transiciones observadas |
Toda conmutación eléctrica y prueba de funciones de protección requiere personal calificado siguiendo el procedimiento aplicable. No modifique la protección de red para acelerar una demostración, omitir un enclavamiento ni forzar una falla de batería. Cuando una función no pueda probarse de inmediato, manténgala explícitamente pendiente en lugar de declarar la liberación completamente aceptada.
Preserve la diferencia entre la reversión de software y la recuperación segura
Un archivo de firmware anterior no prueba que la degradación sea soportada. Los formatos de configuración, las revisiones de hardware o las restricciones del fabricante pueden impedirlo. Obtenga una ruta de recuperación soportada antes del cambio. Esa ruta puede implicar servicio local o un controlador de reemplazo en lugar de una degradación de software.
Para un proyecto que utiliza un sistema de batería residencial para cargas esenciales, disponga un suministro alternativo aprobado cuando sea necesario. El tiempo de recuperación no debe estimarse a partir de otra instalación. Confirme la disponibilidad del personal y el acceso de soporte para la ventana de servicio acordada.
Mantenga una línea base de versiones en la que los equipos de servicio puedan confiar
La guía de gestión de configuración NIST SP 800-128, publicada en 2011 y actualizada en 2019, explica la gestión y el monitoreo de configuraciones mientras se apoyan las funciones empresariales requeridas. Es una guía general de sistemas de información, no un nuevo requisito de certificación de inversores. Su principio de línea base es útil cuando se aplica cuidadosamente a los registros de un proyecto de almacenamiento.
Después de la actualización, guarde las versiones reales instaladas, las configuraciones finales aprobadas y los resultados de las pruebas. Registre cualquier diferencia respecto a la línea base anterior, los problemas no resueltos y la persona que aceptó el cambio. Capture evidencia antes y después de la actualización para que un técnico posterior pueda distinguir un cambio relacionado con la liberación de un problema del sitio no relacionado.
Para flotas de instalaciones, verifique los grupos relevantes de hardware y configuración antes de ampliar un despliegue. Una aprobación en un modelo no califica a todas las unidades de la flota. La implementación por etapas aprobada por el fabricante puede reducir la incertidumbre, pero no debe retrasar una corrección obligatoria más allá de la respuesta permitida.
Cierre el cambio por función, no por estado de instalación
El registro de liberación debe responder: ¿por qué se requirió la actualización, qué cambió, qué funciones se volvieron a probar y qué queda pendiente? Cuando esas respuestas son claras, el distribuidor puede apoyar la instalación sin depender de la memoria o de capturas de pantalla tomadas antes de la actualización. El punto de aceptación final es el servicio restaurado y verificado, no un nuevo número de versión.