Simulation no GOOSE: conceito, função e onde se aplica

Antes de configurar Simulation: função, fronteiras e dependências

Indicadores de Test/Simulation permitem distinguir tráfego de ensaio de tráfego operacional conforme o mecanismo suportado pelo projeto. Eles são importantes para evitar que uma atividade de teste seja interpretada como condição real.

Para aprender Simulation sem depender de uma tela específica de fabricante, separe função, entradas, saídas e dependências. Em GOOSE, os pontos mais próximos deste recorte são Test, Needs Commissioning, GOOSE publicado. O leitor iniciante deve conseguir dizer quem produz a informação e quem a usa; o leitor experiente deve conseguir apontar o limite entre comportamento normal, exceção e implementação particular do equipamento.

Mecanismo de Simulation: campos, estados e transições que importam

Defina claramente quais IEDs aceitam mensagens em modo de teste/simulação e em quais estados operacionais. Essa política precisa estar no procedimento de comissionamento.

Implemente primeiro uma troca mínima e conhecida entre as duas pontas. Depois acrescente eventos, exceções, temporização e funções opcionais. Uma sessão estabelecida não é critério suficiente: o dado precisa manter tipo, qualidade, endereço, sequência e tempo até o destino. Durante o estudo, acompanhe heartbeat, Test, Needs Commissioning, GOOSE publicado como uma cadeia causal. Para cada item, pergunte o que o altera, como aparece no tráfego ou no equipamento e qual seria o primeiro sintoma se estivesse incorreto.

• heartbeat — defina primeiro o que representa em GOOSE e qual elemento produz ou consome essa informação; depois identifique em que condição ele muda.
• Test — relacione o valor ou estado ao efeito sobre Simulation; registre também qual campo permite confirmar que a interpretação está correta.
• Needs Commissioning — na configuração, verifique dependências nas duas pontas e evite copiar valor de outro projeto sem comparar topologia, versão e capacidade do equipamento.
• GOOSE publicado — no diagnóstico, associe pelo menos um sintoma de configuração errada e uma evidência que diferencie esse sintoma de falha física ou de rede.
• GOOSE recebido — no comissionamento, crie um estímulo que faça o item mudar de forma previsível e registre antes/depois, horário e resposta observada.

A cadeia causal de Simulation: o que muda e onde observar

O fundamento de Simulation aparece nas transições. Acompanhe uma operação normal do início ao fim e marque quando heartbeat e Test mudam. Depois repita mentalmente o fluxo com perda de comunicação, reinício ou dado inválido. Essa comparação revela quais campos representam estado e quais apenas transportam informação.

Para que Simulation seja reproduzível em GOOSE, transforme a definição em uma cadeia causa → estado → evidência. Compare heartbeat em condição normal e degradada, verifique a dependência de Test e use Needs Commissioning como critério de encerramento. O objetivo é justificar a configuração sem depender de “valor que sempre usamos”.

• Descrever a sequência normal de Simulation
• Descrever uma exceção sem recorrer a “reiniciar e testar”
• Identificar o papel de heartbeat
• Identificar o papel de Test

Cenário prático: uma decisão de engenharia envolvendo Simulation

Imagine uma integração nova em que Simulation precisa funcionar entre equipamentos de fabricantes diferentes dentro de GOOSE. Comece por uma transação mínima e observável nas duas pontas. Acompanhe heartbeat, Test e Needs Commissioning, além de endereço/identidade, sequência e tempo. Depois introduza uma única exceção — perda do enlace, reinício, evento pendente ou função não suportada — e observe qual estado muda primeiro. Esse exercício mostra se a interoperabilidade existe no mecanismo ou apenas na condição ideal.

O aceite de Simulation precisa responder quem inicia a transação, qual resposta confirma heartbeat, como Test se comporta em exceção e qual log ou captura prova Needs Commissioning. Esses critérios tornam o artigo útil tanto na configuração inicial quanto anos depois, quando outra equipe precisar comparar a ocorrência com o baseline.

• Definir uma condição normal de Simulation e salvar a evidência associada a heartbeat.
• Escolher uma única variável relacionada a Test e prever o efeito antes de alterar.
• Repetir o mesmo teste e comparar Needs Commissioning nas mesmas medições ou campos.
• Registrar o critério que permite aceitar, rejeitar ou reverter a configuração de Simulation.

Teste de aceitação: evidências que comprovam Simulation

Em ambiente autorizado, altere o estado de teste e confirme o bit no frame e a reação esperada do subscriber sem produzir atuação indevida.

Defina evidência antes de testar Simulation. Para esta categoria, sinais úteis incluem endereço, campo, estado, sequência, timestamp, qualidade. O teste deve ter estado inicial conhecido, estímulo reproduzível e resultado esperado. Quando houver dois equipamentos, registre os dois lados; quando houver gateway, registre também a transformação intermediária.

• Validar heartbeat em condição normal
• Forçar uma condição degradada ligada a Test
• Confirmar recuperação sem perder estado, evento ou evidência relevante
• Salvar configuração, logs/captura e horário do teste como baseline

Diagnóstico de Simulation: a primeira divergência vale mais que o último alarme

Se um subscriber ignora GOOSE durante ensaio, verifique compatibilidade de Test/Simulation e modo do IED antes de alterar a rede.

Não conclua a partir do sintoma sozinho. Para Simulation, cruze pelo menos duas fontes de evidência e procure a primeira divergência. Se heartbeat, Test, Needs Commissioning estão corretos mas o resultado final continua errado, avance para a próxima fronteira do sistema em vez de alterar parâmetros já comprovados.

• heartbeat: registre um caso saudável, um caso com falha e a diferença objetiva em estado.
• Test: registre um caso saudável, um caso com falha e a diferença objetiva em sequência.
• Needs Commissioning: registre um caso saudável, um caso com falha e a diferença objetiva em timestamp.
• GOOSE publicado: registre um caso saudável, um caso com falha e a diferença objetiva em qualidade.

Simulation: dados exclusivos deste recorte (fundamentos)

Em Simulation, GOOSE deve ser comprovado por EtherType 0x88B8, MAC multicast 01-0C-CD-01-00-00…01-0C-CD-01-01-FF, APPID, stNum, sqNum, ConfRev e TimeAllowedToLive. Quando 802.1Q é usado, registre VID e PCP até a porta do subscriber.

Nos fundamentos de Simulation, acompanhe a transição que altera APPID e confirme como stNum reage antes, durante e depois do evento.

• APPID: 16 bits. Confirmar fluxo configurado.
• stNum: estado. Incrementa quando DataSet muda.
• sqNum: retransmissão. Cresce no mesmo estado e evidencia gaps.
• ConfRev / TAL: revisão / validade. Comparar SCL e expiração no subscriber.

Simulation: Ethernet multicast, VLAN e prioridade do GOOSE — Simulation / fundamentos

Nos fundamentos de Simulation, trate retransmissão como parte de uma sequência causal: condição inicial, transição, campo alterado e reação do outro lado. GOOSE opera diretamente sobre Ethernet com EtherType 0x88B8. Endereços multicast reservados para GOOSE usam a faixa 01-0C-CD-01-00-00 a 01-0C-CD-01-01-FF. Quando 802.1Q é usado, VID e PCP precisam ser coerentes com o projeto; PCP ocupa 3 bits no tag VLAN e deve ser tratado em conjunto com filas/QoS dos switches. O critério de encerramento para Simulation em fundamentos é obter o mesmo resultado em novo teste de retransmissão, mantendo o ponto de medição e a condição inicial.

O mecanismo de Simulation deve ser lido a partir de Test; observe qual estado antecede a mudança e qual confirmação prova que ela terminou. No diagnóstico de Simulation, verifique MAC destino, VLAN ID, PCP, APPID e entrega na porta do subscriber. “Frame visto no trunk” não prova que ele chegou ao IED. Use port mirroring/contadores multicast e, quando possível, captura no ponto mais próximo do assinante. Para este artigo de Simulation, a evidência ligada a Test deve ser armazenada com horário, origem e condição de teste, permitindo comparação posterior.

• Simulation · fundamentos · retransmissão: Filtro: eth.type == 0x88b8.
• Simulation · fundamentos · fast retransmission: Confirmar MAC multicast GOOSE, VID/PCP e APPID conforme SCL/projeto.
• Simulation · fundamentos · heartbeat: Validar flooding/filtragem multicast e membership quando o switch implementar mecanismos adicionais.
• Simulation · fundamentos · Test: Correlacionar perda de GOOSE com counters, congestionamento e filas de prioridade.