Uma atualização de firmware do inversor só está concluída quando as funções exigidas pelo projeto tiverem sido verificadas, e não quando a barra de progresso termina. O dispositivo pode reiniciar normalmente enquanto uma configuração de exportação, interface de bateria, disposição em paralelo ou comportamento de backup foi alterado. Um upload bem-sucedido prova que o software foi instalado; não prova que a instalação continua a fornecer o serviço contratado.
Para EPCs e distribuidores, trate a atualização como uma alteração de engenharia controlada. Documente o motivo, confirme a combinação exata de hardware e firmware, guarde a configuração aprovada e decida quais funções necessitam de reteste. Aplique atualizações urgentes de segurança ou exigidas pelo fabricante através de uma revisão de risco adequada; não utilize o controlo de alterações como desculpa para ignorar uma instrução de segurança ou do fabricante.
Defina o motivo da versão
Separe uma correção de segurança, uma alteração exigida pelo fabricante, uma correção de falha e uma nova funcionalidade. Cada uma tem uma justificação diferente e pode exigir agendamento diferente. Uma funcionalidade irrelevante para o projeto não é, por si só, evidência de que uma instalação em funcionamento beneficia de uma atualização imediata.
Antes de atualizar um inversor solar HMX, solicite as notas de versão aplicáveis e o procedimento de atualização suportado para o seu modelo exato e revisão de hardware. Confirme quaisquer dependências envolvendo o BMS da bateria, contador, gateway de comunicações ou controlador. Não assuma que um ficheiro para um modelo semelhante é aceitável.
Utilize uma pessoa designada para autorizar a alteração e uma pessoa designada para confirmar o resultado. Num projeto pequeno, estas podem ser membros da mesma equipa de instalação, mas as responsabilidades devem ainda assim ser registadas. O cliente deve saber se a atualização interrompe o serviço e quais os arranjos temporários necessários.
| Registrar | Informação necessária | Decisão de versão que suporta |
|---|---|---|
| Objetivo | Correção, requisito ou funcionalidade do projeto relevante | Por que esta alteração é necessária |
| Identidade do equipamento | Modelo, número de série, hardware e versões de software instaladas | Se o ficheiro de destino se aplica |
| Dependências | Versões suportadas de bateria, contador, controlador e dispositivos em paralelo | Se a combinação do sistema é suportada |
| Baseline de configuração | Configurações aprovadas de exportação, backup, carregamento e acesso | O que deve permanecer correto após a atualização |
| Janela de serviço | Interrupção esperada e arranjos com o cliente | Quando a alteração pode ocorrer em segurança |
| Rota de recuperação | Contactos de recuperação e suporte aprovados pelo fabricante | Como será gerida uma alteração malsucedida |
Não assuma que todas as atualizações preservam as configurações
Uma comparação útil provém de dois documentos atuais dentro da mesma biblioteca do fabricante. O guia geral de firmware VictronConnect descreve a preservação das configurações aplicáveis e do histórico, enquanto direciona explicitamente os produtos VE.Bus para um guia separado. Ler apenas a declaração geral perderia um limite importante do produto.
O guia VictronConnect separado para produtos VE.Bus adverte que o seu processo de atualização repõe as configurações para os padrões de fábrica e exige que configurações multiunidade sejam reprogramadas. Esse comportamento é específico dos produtos e processo documentados; não é uma afirmação sobre equipamento HMX.
A lição de procurement é direta: pergunte se este modelo e método de atualização preservam, migram ou repõem cada configuração relevante. Guarde uma exportação de configuração onde suportado, juntamente com registos legíveis por humanos das configurações essenciais. Um ficheiro que não pode ser restaurado para a nova versão não é um plano de recuperação completo.
Registe os valores atuais aprovados em vez de copiar os padrões de um manual. Os padrões podem não corresponder à aprovação de rede do local, aos limites da bateria ou ao design de backup. Restaurar uma configuração antiga também necessita de revisão se a nova versão alterar o significado ou o intervalo suportado de um parâmetro.
Construa o reteste com base no que o projeto realmente utiliza
Escolha testes de regressão antes de instalar a atualização. Inclua as funções afetadas pelas notas de versão e as funções cuja falha seria importante para o cliente. Um projeto de armazenamento pode depender de permissões de carga da bateria e transições de backup mesmo quando a atualização é descrita como uma melhoria de comunicações.
Mapeie primeiro as relações dos equipamentos. A distinção entre funções de BMS, conversão de potência e gestão de energia ajuda a identificar qual dispositivo fornece um limite ou comando operacional. Um número visível no ecrã não estabelece que o inversor segue o valor permitido mais recente.
| Função utilizada pelo projeto | Foco de verificação | Evidência a reter |
|---|---|---|
| Operação da bateria | Comunicações, limites ativos de carga/descarga e tratamento de alarmes | Versões de dispositivos correspondidas e registos operacionais observados |
| Controlo de exportação | Interpretação do medidor, setpoint e resposta dentro do arranjo aprovado | Configurações e resultado medido do teste |
| Alimentação de reserva | Transferência aprovada, cargas reais e retorno à rede | Cronologia de eventos e observações de serviço |
| Operação paralela ou multifásica | Combinação de versões suportada e funções configuradas | Topologia e resultados funcionais aprovados |
| Monitoramento remoto | Telemetria atual, alarmes e acesso permitido | Timestamps recentes e caminho de notificação testado |
| Despacho agendado | Fuso horário, janelas operacionais e permissões | Política final e transições observadas |
Todas as comutações elétricas e testes de funções de proteção exigem pessoal qualificado seguindo o procedimento aplicável. Não altere a proteção de rede para acelerar uma demonstração, contornar um interbloqueio ou forçar uma falha de bateria. Quando uma função não puder ser testada imediatamente, mantenha-a explicitamente pendente em vez de declarar a liberação totalmente aceita.
Preserve a diferença entre rollback de software e recuperação segura
Um arquivo de firmware anterior não prova que o downgrade é suportado. Formatos de configurações, revisões de hardware ou restrições do fabricante podem impedi-lo. Obtenha uma rota de recuperação suportada antes da alteração. Essa rota pode envolver serviço local ou um controlador de substituição em vez de um downgrade de software.
Para um projeto que utiliza um sistema de bateria residencial para cargas essenciais, providencie uma fonte de alimentação alternativa aprovada quando necessário. O tempo de recuperação não deve ser estimado a partir de outra instalação. Confirme a disponibilidade de pessoal e o acesso de suporte para a janela de serviço acordada.
Mantenha uma linha de base de versões confiável para as equipes de serviço
Orientação de gestão de configuração NIST SP 800-128, publicada em 2011 e atualizada em 2019, explica a gestão e o monitoramento de configurações enquanto apoia as funções de negócio necessárias. É uma orientação geral para sistemas de informação, não um novo requisito de certificação de inversores. Seu princípio de linha de base é útil quando aplicado cuidadosamente aos registros de um projeto de armazenamento.
Após a atualização, salve as versões realmente instaladas, as configurações finais aprovadas e os resultados dos testes. Registre quaisquer diferenças em relação à linha de base anterior, questões não resolvidas e a pessoa que aceitou a alteração. Capture evidências antes e depois da atualização para que um técnico posterior possa distinguir uma alteração relacionada à liberação de um problema não relacionado no local.
Para frotas de instalações, verifique os grupos relevantes de hardware e configuração antes de expandir uma implantação. A aprovação em um modelo não qualifica todas as unidades da frota. A implantação faseada aprovada pelo fabricante pode reduzir a incerteza, mas não deve atrasar uma correção obrigatória além da resposta permitida.
Encerre a alteração com base na função, não no status da instalação
O registro de liberação deve responder: por que a atualização foi necessária, o que mudou, quais funções foram retestadas e o que permanece em aberto? Quando essas respostas estiverem claras, o distribuidor poderá dar suporte à instalação sem depender da memória ou de capturas de tela feitas antes da atualização. O ponto final de aceitação é o serviço restaurado e verificado, não um novo número de versão.