Uma exibição de SOC por si só não estabelece uma integração completa. O valor pode vir apenas de algumas mensagens de status ou de dados armazenados em cache. Não prova a interação correta para todos os limites, alarmes e estados de controle. A aceitação deve abranger os dados e estados necessários definidos no protocolo, com equipamentos, firmware e condições de teste registrados.
Verificações de aceitação sugeridas
| Verifique | O que observar | Evidências para reter |
|---|---|---|
| Consistência de dados | Unidades, direção, escala e validade de SOC, tensão, corrente e temperatura | Mensagens brutas, dados decodificados e exibições de dispositivos |
| Restrições operacionais | Transferência de protocolo de tensão, corrente e habilitação de carga ou descarga permitidas | Limites de entrada, resultados de conversão e resposta do dispositivo |
| Alarmes e estados | Ativação consistente de alarme, eliminação e transições de estado | Sequências de estado, carimbos de data/hora e logs |
| Perda de link e dados obsoletos | Detecção e tratamento específico de mensagens interrompidas, links perdidos ou campos inválidos | Definições de tempo limite, etapas de gatilho e comportamento real |
| Recuperação e reinicialização | Inicialização e recuperação permitida após reconexão ou reinicialização | Logs de inicialização, sequências de recuperação e problemas em aberto |
Como definir critérios de aprovação
Antes do teste, defina as condições de entrada, as saídas esperadas, as tolerâncias ou janelas de tempo permitidas, a responsabilidade pela operação do dispositivo e o formato das evidências. Os testes de carga e descarga são realizados pela parte do projeto equipada para operar o sistema. Um gateway não deve fabricar estados normais para ignorar BMS ou proteção do inversor. Esta tabela oferece suporte ao planejamento de testes; os limites vêm dos protocolos do dispositivo e do plano de teste acordado.
Como registrar resultados de marcos
Grave a decodificação de mensagens como verificação de amostra de campo. Registre a interação parcial em uma placa de desenvolvimento com o escopo real do protótipo. Os testes de dispositivos relatam casos aprovados, reprovados e não verificados individualmente. As alterações de modelo ou firmware precisam de avaliação de regressão. Uma única observação no display não substitui condições operacionais não realizadas ou testes de operação contínuos.
Perguntas e Respostas
Um valor plausível de SOC é aprovado se os dados estiverem obsoletos?
Um valor plausível por si só é insuficiente. Verifique o tempo de dados, validade, comportamento de tempo limite e condições de recuperação em relação ao protocolo de destino. Mantenha mensagens de entrada e registros de tempo na evidência de aceitação para que um valor antigo exibido continuamente não seja confundido com um link íntegro.
Que evidências um teste de perda e recuperação de link deve reter?
Registre as versões do equipamento e do firmware, a entrada normal, a condição de interrupção ou desconexão da mensagem, o tempo do evento, as saídas ou estados em ambos os lados, as etapas de recuperação e o resultado real. Os limites de tempo limite e o comportamento esperado vêm dos protocolos aplicáveis e do plano de teste do projeto; este artigo geral não inventa valores universais.
O resultado de aceitação anterior cobre uma atualização de BMS ou firmware do inversor?
O registro antigo permanece como evidência da combinação original testada. A aplicabilidade a uma nova versão requer uma revisão das alterações de protocolo e comportamento. Identifique os campos afetados, limites, alarmes, casos de inicialização, tempo limite e recuperação, execute os testes de regressão relevantes e registre um resultado para a nova versão.
Online
Telefone
WeChat
voltar ao topo