Proteção e Controle Centralizados de Subestações: CPC, IEDs, IEC 61850, redundância e engenharia

Proteção e controle centralizados de subestações: CPC, IEC 61850, Sampled Values, GOOSE, redundância, common-mode failure, cybersecurity, FAT/SAT e ciclo de vida.

Confira!

A proteção e controle centralizados de subestações reorganiza funções tradicionalmente distribuídas entre relés de bay, controladores e dispositivos dedicados para executá-las, total ou parcialmente, em plataformas computacionais centralizadas. O conceito é conhecido internacionalmente como Centralized Protection and Control — CPC e não significa simplesmente colocar vários relés em um mesmo rack. Ele exige uma arquitetura em que dados de corrente, tensão, posição, estado e qualidade sejam adquiridos de forma confiável, transportados por uma infraestrutura determinística e processados com critérios de redundância, segurança e segregação compatíveis com funções de proteção.

A IEEE C37.300-2024 é o guia ativo específico para sistemas CPC em subestações. Ela trata proteção, automação e controle executados a partir de dados provenientes de IEDs e infraestrutura de comunicação. Em paralelo, a série IEC 61850 fornece os modelos de dados, serviços, linguagem de configuração e mecanismos de comunicação que permitem separar cada vez mais a função elétrica do dispositivo físico que a executa.

Essa separação cria oportunidades importantes: reduzir hardware dedicado, compartilhar dados entre funções, facilitar automação, aumentar observabilidade e tornar alterações mais baseadas em software. Mas também concentra riscos. Uma falha de hardware, rede, sincronismo, software ou configuração pode afetar várias funções simultaneamente. Por isso, CPC deve ser projetado a partir de dependability, security, redundancy, common-mode failure e comportamento degradado, e não apenas de eficiência de infraestrutura.

O artigo não substitui uma introdução à IEC 61850. O tema de subestação digital, GOOSE e Sampled Values possui escopo próprio e mais amplo. Aqui o foco é outro: como estruturar proteção e controle quando a inteligência deixa de estar rigidamente vinculada ao IED de cada bay e passa a ser executada em uma arquitetura centralizada ou híbrida.

Arquitetura e fundamentos do CPC em subestações

Em uma arquitetura convencional, cada bay possui um ou mais IEDs responsáveis por funções como 50/51, 21, 87, 25, 79, controle do disjuntor e intertravamentos. Os TCs e TPs são ligados diretamente ao relé, e saídas binárias comandam bobinas de trip.

No CPC, parte dessa cadeia pode mudar:

sensores/TCs/TPs → merging units ou IEDs de interface → rede de processo/estação → plataforma CPC → comando de trip/controle

A função de proteção continua sendo a mesma do ponto de vista elétrico. O que muda é onde ela é executada e como os dados chegam até ela.

CPC não é sinônimo de subestação digital. Uma subestação digital pode continuar usando proteção distribuída por bay. Sampled Values substituem cabos analógicos e GOOSE substitui parte da fiação binária, mas cada IED ainda executa suas próprias funções.

CPC adiciona outro passo: várias funções podem residir em um ou mais computadores/plataformas comuns.

Assim, existem arquiteturas:

• convencionais com IEDs dedicados;
• digitais com IEDs distribuídos;
• centralizadas;
• híbridas, combinando proteção local e funções centralizadas.

A escolha deve ser feita por função e criticidade, não como decisão binária entre “convencional” e “digital”.

Por que centralizar proteção e controle. Entre os potenciais benefícios estão:

• menor quantidade de hardware dedicado;
• menor diversidade de plataformas de configuração;
• uso compartilhado de dados;
• facilidade de implementação de funções sistêmicas;
• automação integrada;
• simplificação de expansão em arquiteturas preparadas;
• maior capacidade de processamento;
• atualização de funções por software;
• consolidação de oscilografias e eventos;
• melhoria de diagnósticos e supervisão.

Esses benefícios só se concretizam se a arquitetura de comunicação e computação atender aos requisitos temporais e de confiabilidade das funções.

O risco da concentração funcional. Um relé convencional pode falhar e afetar um bay. Uma plataforma central pode executar proteção de vários bays simultaneamente. A consequência de uma falha comum pode, portanto, ser maior.

O projeto precisa identificar single points of failure e causas comuns envolvendo:

• servidor ou processador;
• hypervisor ou camada de virtualização;
• sistema operacional;
• aplicação de proteção;
• fonte de alimentação;
• rede;
• switch;
• clock;
• banco de configuração;
• atualização de software;
• erro humano;
• ciberincidente.

A redundância precisa reduzir essas causas comuns em vez de apenas duplicar equipamentos idênticos.

Funções centralizáveis e funções locais. Nem toda função precisa migrar para CPC. Uma arquitetura pode manter funções extremamente críticas ou de alta velocidade localmente e centralizar outras.

Uma análise por função deve considerar:

Função	Questões principais
50/51	latência de medição, trip e fallback
87B	grande volume de correntes, zona dinâmica, alta consequência
87T	sincronismo, saturação e dependência de dados de múltiplos lados
21	processamento de tensão/corrente, memória e telecomunicação
50BF	dependência de trip anterior e retorno de disjuntor
79	coordenação entre terminais e estados
intertravamentos	disponibilidade de posições e consistência lógica
controle	permissivos, autoridade local/remota e segurança operacional

A arquitetura deve justificar o local de execução de cada função.

Filosofia de proteção, disponibilidade e retaguarda

A centralização não elimina a necessidade de independência entre proteção principal e backup.

Uma estratégia robusta pode manter:

• proteção principal em plataforma CPC A;
• proteção redundante em CPC B;
• função local independente no IED de bay;
• retaguarda remota temporizada;
• combinação desses níveis.

O objetivo é impedir que uma única falha de software, rede ou configuração retire simultaneamente principal e retaguarda.

O artigo Proteção de Sistemas Elétricos de Potência fornece a base para analisar essas camadas.

Arquitetura híbrida. Em muitas aplicações brownfield, uma arquitetura híbrida é tecnicamente mais prudente do que migração total.

IEDs existentes continuam executando funções principais enquanto a plataforma central recebe os mesmos dados para:

• retaguarda;
• automação;
• análise;
• funções de área;
• supervisão;
• consolidação de eventos.

Com a maturidade operacional, funções podem ser transferidas gradualmente.

Essa abordagem reduz risco de mudança abrupta e permite validar infraestrutura digital sob carga real.

Aquisição de dados, IEDs e process bus IEC 61850

Mesmo em CPC, dispositivos próximos ao processo continuam necessários para converter grandezas físicas em dados digitais e executar saídas.

Merging units podem publicar correntes e tensões como Sampled Values. IEDs de interface podem adquirir contatos de disjuntores, seccionadoras e alarmes e emitir comandos de trip.

O conteúdo IED em Subestações detalha essa camada de dispositivos inteligentes.

Process bus. Process bus transporta dados entre o pátio/equipamento primário e as funções de proteção e controle.

Em arquiteturas com Sampled Values, a cadeia analógica deixa de ser individual até cada relé e passa a incluir:

• TC/TP ou sensor;
• conversão/merging unit;
• timestamp;
• Ethernet;
• switch/rede;
• assinante CPC.

Cada elemento passa a integrar a cadeia metrológica e funcional da proteção.

Sampled Values — IEC 61850-9-2. A IEC 61850-9-2 define o mapeamento para transmissão de valores amostrados por Ethernet. Em CPC, SV pode ser a principal forma de distribuir correntes e tensões para várias funções.

Isso permite que a mesma medição alimente diferentes proteções sem múltiplos circuitos secundários de cobre.

Em contrapartida, qualidade do fluxo, perda de frames, sincronismo e latência precisam ser supervisionados.

GOOSE para trips e estados. GOOSE pode transportar sinais de alta prioridade como:

• trip;
• bloqueio;
• permissivo;
• falha de disjuntor;
• posição;
• intertravamento;
• transferência de zona.

A lógica distribuída deve ser documentada. Um trip pode depender de uma cadeia de publicadores e assinantes que não é visível em um diagrama elétrico convencional.

A matriz causa-efeito precisa identificar essas dependências.

MMS e funções de supervisão. MMS é utilizado para comunicação cliente-servidor, supervisão, comandos, relatórios e dados menos críticos em tempo que GOOSE/SV.

CPC pode consolidar informações operacionais e disponibilizá-las ao SCADA/centro de controle.

O projeto precisa separar tráfego de proteção de tráfego de supervisão e evitar que aplicações não críticas prejudiquem funções determinísticas.

SCL e a configuração como ativo de engenharia. A IEC 61850-6 define a linguagem SCL para descrever IEDs, comunicação, estrutura da subestação e relações funcionais. A versão consolidada atual incorpora a AMD2:2024.

Em CPC, SCL é ainda mais importante porque a arquitetura funcional pode ser distribuída entre numerosos dispositivos e aplicações.

A baseline precisa controlar:

• ICD/IID;
• SCD;
• CID quando aplicável;
• datasets;
• GOOSE control blocks;
• Sampled Value control blocks;
• endereçamento;
• relações de assinatura;
• revisões de engenharia.

Engenharia funcional versus engenharia de comunicação. Uma proteção 87B pode estar correta matematicamente e falhar por associação errada de Sampled Values. Um intertravamento pode estar correto em lógica e falhar por qualidade inválida de um estado.

Por isso, CPC exige validação em duas dimensões inseparáveis:

função elétrica + caminho de dados.

A revisão deve rastrear cada grandeza desde sua origem física até a aplicação e de volta ao atuador.

Sincronismo, latência e redes redundantes

Funções que comparam grandezas de fontes distintas exigem alinhamento temporal consistente.

O sincronismo também é fundamental para:

• SOE;
• oscilografia;
• correlação de eventos;
• Sampled Values;
• teste end-to-end.

Arquiteturas podem usar PTP conforme perfis aplicáveis, GNSS ou clocks redundantes.

A falha do clock precisa possuir comportamento definido: continuar, degradar, bloquear determinada função ou alarmar.

Perda de sincronismo. Uma arquitetura bem desenhada não assume que o tempo sempre estará correto.

Deve definir:

• limite de erro admissível;
• detecção de perda;
• holdover;
• fonte secundária;
• funções afetadas;
• alarmes;
• fail-safe.

A consequência pode variar: uma função de sobrecorrente local pode permanecer válida, enquanto diferencial entre dados não alinhados pode precisar ser bloqueado.

Latência ponta a ponta. O tempo de proteção é soma de vários componentes:

aquisição → publicação → transporte → processamento → comando → transporte → saída → disjuntor

Cada etapa precisa possuir orçamento de tempo.

Uma rede com latência média baixa mas jitter imprevisível pode ser inadequada para função crítica.

O desempenho precisa ser medido em condições normais e degradadas.

Jitter e congestionamento. Ethernet com prioridade e engenharia correta pode suportar tráfego crítico, mas dimensionamento precisa considerar picos, multicast e falhas de rede.

GOOSE e SV não devem depender de uma infraestrutura saturada por tráfego corporativo ou de manutenção.

O projeto de rede precisa controlar:

• VLANs;
• prioridade;
• multicast;
• bandwidth;
• storm control quando apropriado;
• paths redundantes;
• gerenciamento.

PRP e HSR. IEC 62439-3 define mecanismos de redundância paralela amplamente utilizados em subestações digitais, como PRP e HSR.

O conteúdo PRP e HSR detalha princípios e aplicações.

Para CPC, a questão central é se a perda de um link, switch ou caminho provoca perda de dados ou apenas redução de redundância.

O failover precisa ser compatível com o tempo da proteção.

Redundância A/B. Uma arquitetura pode duplicar:

• plataformas CPC;
• switches;
• redes;
• fontes CC;
• clocks;
• merging units;
• interfaces de trip.

A independência deve ser avaliada fisicamente e logicamente.

Dois servidores alimentados pela mesma fonte e conectados ao mesmo switch não formam redundância completa.

Common-mode failure. O maior desafio da centralização é a falha comum.

Exemplos incluem:

• mesma versão de software com bug;
• arquivo de configuração errado replicado em A e B;
• atualização simultânea;
• clock comum;
• erro de engenharia em SCD;
• malware ou credencial comprometida;
• mesma alimentação;
• mesmo switch central;
• mesma origem de dados.

A análise de redundância deve mapear dependências compartilhadas.

Diversidade funcional. Em aplicações de alta consequência, pode ser justificável manter princípios distintos entre proteção principal e redundante.

Exemplos:

• diferencial centralizado + distância local;
• CPC + IED convencional;
• fabricantes ou plataformas diferentes, quando o benefício superar a complexidade.

Diversidade reduz determinados modos comuns, mas aumenta esforço de engenharia, testes e gestão de competências.

Alta disponibilidade da plataforma. CPC pode utilizar arquitetura de alta disponibilidade com processamento redundante, watchdogs e failover.

O tempo de recuperação precisa ser comparado ao requisito da função. Um failover de segundos pode ser aceitável para supervisão, mas não para proteção principal sem uma camada independente ativa.

Por isso, alta disponibilidade de TI não é automaticamente alta disponibilidade de proteção.

Virtualização. Funções podem ser executadas em máquinas virtuais ou contêineres conforme a plataforma e certificação da solução.

A virtualização cria abstração útil para manutenção e provisionamento, mas adiciona camadas:

• hypervisor/runtime;
• scheduler;
• drivers;
• isolamento de recursos;
• imagens de software;
• storage;
• mecanismos de atualização.

Cada camada precisa ser incluída na análise de falhas e cybersecurity.

Determinismo computacional. Proteção elétrica possui deadlines. O processador precisa garantir que a função execute dentro de tempo previsível mesmo quando múltiplas aplicações competem por recursos.

CPU média de 20% não prova determinismo.

A validação precisa incluir carga máxima, eventos simultâneos, falhas, logging, comunicação e outras tarefas concorrentes.

Recursos reservados. Plataformas podem reservar cores, memória e interfaces para funções críticas.

A engenharia deve documentar:

• recursos mínimos;
• oversubscription permitida;
• prioridade de processos;
• comportamento em overload;
• watchdog;
• critérios de health.

Uma expansão futura não pode consumir recursos que comprometem proteção existente.

Escalabilidade. Um benefício de CPC é adicionar funções por software, mas a infraestrutura tem limites.

Cada novo bay aumenta:

• SV streams;
• GOOSE;
• I/O;
• processamento;
• storage de eventos;
• tráfego de gerenciamento.

A arquitetura deve possuir margem e processo de capacity planning.

Funções de proteção e controle em operação normal e degradada

87B é uma candidata natural à centralização porque já depende de correntes de vários bays.

Entretanto, sua alta consequência exige cuidado com:

• qualidade de todos os SV;
• seleção dinâmica de zonas;
• posição de seccionadoras;
• check zone;
• 50BF;
• matriz de trip;
• perda de uma merging unit.

O artigo Proteção de Barramentos aprofunda esses requisitos elétricos.

Proteção de transformadores em CPC. 87T precisa de correntes de múltiplos enrolamentos, compensações e tratamento de inrush/saturação.

Centralizar pode permitir compartilhar dados com medição e outras funções, mas a proteção deve permanecer disponível mesmo diante de falhas de rede ou plataforma previstas.

O Proteção de Transformadores detalha o princípio funcional que o CPC deve preservar.

Proteção de linhas e teleproteção. Funções 21 e 87L também dependem de canais entre subestações. CPC não elimina essa infraestrutura; pode aumentar a necessidade de separar claramente redes internas e canais WAN.

O Proteção de Linhas de Transmissão discute 21, 87L, POTT/PUTT/DCB e teste end-to-end.

A arquitetura central precisa preservar tempos e segurança da teleproteção.

50BF centralizada. Falha de disjuntor utiliza informação de trip, corrente e posição. Em CPC, essas grandezas podem estar disponíveis de forma ampla, permitindo lógica integrada.

Mas 50BF é uma função de alta consequência: uma associação errada pode desligar múltiplos bays.

A matriz de retaguarda deve ser verificada contra o unifilar real e testada por disjuntor.

Intertravamentos centralizados. Intertravamentos podem usar a visão completa da subestação para validar manobras.

A centralização facilita lógicas complexas, mas cria dependência de estados remotos e qualidade dos dados.

Cada permissivo deve considerar:

• posição válida;
• qualidade;
• timeout;
• estado intermediário;
• modo local/remoto;
• manutenção;
• falha de comunicação.

O operador precisa compreender por que uma manobra está bloqueada.

Autoridade de comando. CPC pode receber comandos do HMI local, SCADA, centro remoto ou automações.

A arquitetura precisa definir prioridade e arbitragem entre:

• proteção;
• intertravamento;
• operador local;
• operador remoto;
• automação;
• manutenção/teste.

Proteção deve ter caminho de trip independente de indisponibilidade da interface de operação.

Estado degradado. A pergunta mais importante não é apenas “o sistema funciona?”, mas “como ele se comporta quando parte dele falha?”.

Para cada falha, deve estar definido:

• funções preservadas;
• funções bloqueadas;
• alarmes;
• restrições operacionais;
• possibilidade de manutenção;
• necessidade de retirar bay ou subestação de serviço.

Essa matriz de degradação é um entregável de engenharia.

Perda de uma merging unit. A perda de uma MU pode remover correntes e tensões de várias funções.

A arquitetura pode:

• usar MU redundante;
• obter dados alternativos;
• transferir para proteção local;
• bloquear funções dependentes;
• alarmar e impor restrição operacional.

O comportamento não deve ficar implícito.

Perda de um switch. Redes redundantes precisam demonstrar que a falha de um switch não interrompe o fluxo crítico.

O teste deve provocar falha real ou simulada e medir:

• perda de frames;
• continuidade de SV;
• GOOSE;
• tempo de recuperação;
• alarmes;
• estado da aplicação CPC.

A simples existência de dois switches não comprova redundância.

Perda de uma plataforma CPC. Em redundância ativa-ativa ou ativa-standby, a falha de uma plataforma deve ser detectada e tratada sem perda de proteção incompatível com os critérios do sistema.

É preciso verificar:

• transferência;
• estado das aplicações;
• consistência de settings;
• sessões de comunicação;
• outputs;
• eventos;
• alarmes.

O teste de failover deve fazer parte do FAT/SAT.

Cibersegurança, virtualização e gestão de configuração

CPC concentra funções críticas em uma plataforma computacional conectada. Isso amplia a importância de hardening, controle de acesso e gestão de atualizações.

A série IEC 62351 trata segurança de protocolos de automação, incluindo IEC 61850, enquanto IEC 62443 fornece estrutura ampla para sistemas de automação e controle industrial.

O conteúdo IEC 62351 detalha essa camada.

Segurança sem prejudicar tempo de proteção. Controles de segurança não podem introduzir latência ou indisponibilidade incompatível com a função.

Alterações como:

• firewall;
• inspeção de tráfego;
• criptografia;
• autenticação;
• segmentação;
• patches;
• EDR;

precisam ser avaliadas em ambiente representativo antes de produção.

OT security e engenharia de proteção precisam trabalhar juntas.

Gestão de identidades e privilégios. Uma plataforma central pode permitir alteração de múltiplas proteções por um único acesso. O princípio de menor privilégio torna-se ainda mais importante.

Deve existir separação entre:

• operação;
• manutenção;
• engenharia de settings;
• administração de sistema;
• cybersecurity.

Alterações críticas precisam ser auditáveis.

Gestão de patches. Não é aceitável aplicar patches automaticamente como em TI corporativa sem avaliar a função elétrica.

O processo deve incluir:

1. análise de vulnerabilidade
2. avaliação de impacto
3. teste em ambiente representativo
4. aprovação
5. janela de manutenção
6. rollback
7. verificação pós-update

A redundância pode permitir manutenção sem perda total de função, mas isso precisa ser demonstrado.

Firmware e software baseline. CPC possui várias camadas de versão:

• firmware de MU/IED;
• switch;
• sistema operacional;
• hypervisor;
• aplicação CPC;
• bibliotecas;
• SCL;
• settings.

A baseline de engenharia precisa relacionar essas versões à revisão aprovada do sistema.

Gestão de configuração. Uma alteração aparentemente pequena em SCD pode afetar vários assinantes.

O processo de change management deve exigir:

• solicitação;
• análise de impacto;
• revisão técnica;
• geração de arquivos;
• comparação de versão;
• teste;
• aprovação;
• implantação controlada;
• As-Built.

A Governança Documental é particularmente relevante nesse ambiente.

Versionamento de lógica de proteção. Além do SCL, as lógicas internas do CPC precisam ser versionadas e rastreáveis.

Cada release deve indicar:

• funções alteradas;
• settings;
• dependências;
• casos de teste afetados;
• bugs corrigidos;
• compatibilidade de hardware.

Não se deve perder a capacidade de reconstruir exatamente a versão que estava ativa durante um evento.

Observabilidade da plataforma. A operação precisa enxergar não apenas estados elétricos, mas saúde da infraestrutura digital.

Indicadores podem incluir:

• CPU/memória;
• perda de SV;
• GOOSE timeout;
• clock quality;
• interface de rede;
• switch health;
• redundância;
• serviços CPC;
• storage;
• temperatura;
• fontes.

Alarmes devem ser classificados por impacto funcional.

SOE e oscilografia centralizada. CPC pode consolidar registros de vários bays com tempo comum, facilitando análise de perturbações.

Entretanto, é necessário garantir que eventos não sejam perdidos em falha da plataforma ou da rede.

Armazenamento local em IEDs/MUs pode fornecer redundância de evidência.

O formato e retenção dos registros devem fazer parte dos requisitos.

Engenharia de requisitos e avaliação de riscos da arquitetura

Projetos CPC precisam especificar requisitos mensuráveis, não apenas “alta disponibilidade”.

Exemplos:

• máximo tempo ponta a ponta por classe de função;
• disponibilidade requerida;
• quantidade de falhas toleradas;
• tempo de detecção de falha;
• capacidade computacional mínima;
• perda máxima de frames;
• holdover do clock;
• recuperação após reboot;
• quantidade de bays expansíveis;
• tempo de retenção de eventos.

A Gestão de Requisitos, Evidências e Critérios de Aceite ajuda a ligar cada requisito a um ensaio verificável.

Arquitetura de referência. Antes do detalhamento, deve ser produzido um diagrama que mostre:

• equipamento primário;
• TCs/TPs/sensores;
• merging units;
• IEDs locais;
• redes A/B;
• switches;
• clocks;
• plataformas CPC A/B;
• gateways;
• HMI;
• SCADA;
• interfaces WAN;
• fontes CC;
• caminhos de trip.

O diagrama precisa evidenciar dependências e redundâncias.

Matriz função × plataforma. Uma tabela útil associa cada função ao local de execução e backup.

Função	Principal	Redundante	Fallback
87B	CPC A	CPC B	retaguarda remota/local
50/51 feeder	CPC	IED local	proteção upstream
50BF	CPC A/B	lógica local quando prevista	retaguarda sistêmica
controle	CPC	gateway/HMI	operação local
intertravamento	CPC	lógica distribuída	procedimento operacional

O conteúdo exato depende da subestação. A tabela força a explicitação da arquitetura.

Matriz de dependências. Outra visão liga funções aos recursos de infraestrutura.

Uma função pode depender de:

• MU X;
• switch A1/A2;
• clock;
• CPC A/B;
• output IED Y;
• bateria CC1/CC2.

A análise ajuda a identificar common-mode failure antes do FAT.

FMEA da arquitetura CPC. Uma FMEA ou análise equivalente pode avaliar modos de falha de hardware, software e comunicação.

Para cada falha, registrar:

• detecção;
• efeito local;
• efeito sistêmico;
• função perdida;
• redundância disponível;
• ação automática;
• ação operacional.

Essa abordagem transforma “redundância” em engenharia verificável.

Design Review. CPC exige revisão multidisciplinar envolvendo proteção, automação, telecom, OT, cibersegurança e operação.

O Design Review deve confrontar:

• filosofia de proteção;
• arquitetura computacional;
• rede;
• sincronismo;
• I/O;
• SCL;
• redundância;
• cybersecurity;
• tempos;
• testes;
• comportamento degradado.

Revisar apenas os settings dos relés deixa de ser suficiente.

FAT, HIL, SAT e critérios de energização

O FAT precisa reproduzir a subestação em escala funcional. Idealmente, inclui equipamentos de rede e IEDs reais ou simulados.

Casos devem envolver:

• faltas elétricas por zona;
• trips simultâneos;
• perda de SV;
• perda de GOOSE;
• falha de switch;
• falha de clock;
• perda de CPC A/B;
• reboot;
• failover;
• degradação de rede;
• mudança de configuração;
• cybersecurity controls;
• restauração.

A plataforma precisa ser testada sob carga representativa.

Hardware-in-the-loop e simulação em tempo real. HIL/RTDS ou ferramentas equivalentes podem reproduzir o sistema elétrico e alimentar a plataforma com sinais dinâmicos.

Isso permite validar:

• tempos;
• sequência de eventos;
• saturação/transitórios;
• lógicas de proteção;
• contingências;
• múltiplas faltas;
• estabilidade de comunicação.

Em sistemas CPC de alta consequência, esse nível de teste pode reduzir significativamente o risco de commissioning.

Teste de performance sob carga. A função precisa manter tempo de atuação quando dezenas de eventos ocorrem simultaneamente.

O FAT deve monitorar:

• CPU;
• memória;
• latência;
• jitter;
• dropped frames;
• tempo de aplicação;
• tempo de GOOSE;
• logging;
• failover.

Benchmark em condição ociosa não demonstra capacidade operacional.

Teste de common-mode. Também é necessário testar falhas que atingem as duas cadeias por um elemento comum.

Exemplos:

• perda da fonte compartilhada;
• SCD incorreto;
• clock comum;
• switch de agregação;
• serviço de autenticação;
• atualização defeituosa.

O objetivo é verificar se existe realmente independência onde o projeto afirma existir.

SAT em campo. No SAT, a plataforma encontra os sensores, switches, clocks, disjuntores e cabos reais.

O Comissionamento e Aceite Técnico de Instalações Elétricas precisa validar ponta a ponta:

processo → aquisição → rede → CPC → comando → atuador → retorno → SCADA.

A associação de cada bay deve ser verificada individualmente.

Testes de trip físico. Mesmo com sistema digital, o objetivo final é abrir o equipamento correto.

Cada função crítica deve demonstrar que:

• utiliza as grandezas corretas;
• identifica a zona correta;
• emite comando correto;
• trafega pela rede esperada;
• chega ao output correto;
• abre o disjuntor correto;
• registra retorno e tempo.

Bits internos não substituem prova do circuito de atuação.

Teste de rede degradada. O SAT deve retirar links, switches e fontes para verificar redundância.

É importante observar não apenas se a função continua disponível, mas se o sistema reconhece que perdeu redundância e alarma adequadamente.

Operar indefinidamente em single path sem indicação é um risco oculto.

Critérios de energização. Antes de liberar CPC em produção, devem estar aprovados:

• arquitetura e As-Built;
• settings;
• SCD e arquivos derivados;
• versões de software;
• redundância;
• sincronismo;
• cybersecurity baseline;
• FAT;
• SAT;
• testes de trip;
• matriz de degradação;
• procedimentos de rollback;
• backup de configuração.

Pendências que afetem função crítica não devem ser tratadas como documentação secundária.

Operação, manutenção e recuperação de sistemas CPC

CPC muda o perfil de competências da equipe. Além de proteção elétrica, manutenção precisa compreender:

• redes Ethernet;
• IEC 61850;
• virtualização quando aplicável;
• servidores;
• sincronismo;
• cybersecurity;
• ferramentas de configuração;
• backup/restore.

Treinamento precisa ser parte do projeto.

Backup e restore. Um backup útil precisa permitir reconstruir a plataforma.

Deve incluir:

• imagens de sistema;
• aplicação;
• settings;
• SCL;
• certificados/chaves conforme política;
• configurações de switches;
• clocks;
• documentação de versão.

Restore deve ser testado periodicamente em ambiente controlado.

Spare strategy. CPC pode reduzir quantidade de modelos de relés, mas aumenta criticidade de determinados componentes centrais.

O plano de sobressalentes deve considerar:

• servidores/plataformas;
• NICs;
• switches;
• clocks;
• MUs;
• fontes;
• storage.

Tempo de reposição e compatibilidade de versão são parte da disponibilidade.

Obsolescência tecnológica. Plataformas computacionais têm ciclo de vida diferente de equipamentos primários. Sistemas operacionais e hardware podem chegar ao fim de suporte antes do transformador ou disjuntor associado.

O plano de ciclo de vida deve prever:

• suporte do fabricante;
• roadmap de software;
• migração de hardware;
• compatibilidade de configuração;
• testes de regressão.

CPC transforma gestão de obsolescência em tema central da engenharia de proteção.

Migração brownfield, convivência e governança de mudanças

Subestações existentes podem migrar por etapas:

1. digitalização de estados
2. IEC 61850 station bus
3. integração de IEDs
4. process bus em bays novos
5. CPC para funções não críticas
6. redundância central
7. transferência gradual de proteção

Cada etapa precisa manter cobertura de proteção durante cutover.

Cutover. A transição entre relé existente e função CPC é um momento de risco elevado.

O plano deve definir:

• proteção temporária;
• bloqueios;
• isolamento de TCs;
• duplicidade de trips;
• teste antes da transferência;
• rollback;
• janela operacional.

A primeira vez que a função CPC controla o disjuntor não pode ocorrer sem prova prévia do caminho.

Convivência com relés legados. Gateways ou IEDs podem integrar dispositivos que não falam IEC 61850. Essa convivência é comum em modernizações.

A arquitetura deve registrar limites de desempenho e qualidade desses dados.

Não é necessário converter todo o parque para obter benefícios, mas as dependências legadas não devem ficar ocultas.

Owner’s Engineering. CPC atravessa fronteiras de fornecedores: relés, servidores, rede, telecom, cybersecurity, SCADA e equipamentos primários.

O Owner’s Engineering mantém a visão do sistema completo e impede que cada fornecedor valide apenas sua parte.

O proprietário precisa receber uma arquitetura operável e verificável, não apenas equipamentos individualmente conformes.

Project Assurance. Em projetos de alta criticidade, gates independentes podem verificar maturidade antes de avançar de design para FAT, SAT e energização.

Critérios incluem:

• requisitos fechados;
• interfaces resolvidas;
• arquitetura aprovada;
• testes completos;
• cybersecurity review;
• documentação sincronizada;
• pendências classificadas.

A centralização aumenta o valor dessa disciplina porque falhas de integração têm maior alcance.

As-Built digital. O As-Built deve incluir muito mais que diagramas PDF.

São ativos de entrega:

• SCD aprovado;
• CID/IID quando aplicável;
• settings;
• lógica CPC;
• configurações de switch;
• topologia de rede;
• endereçamento;
• firmware/software;
• certificados conforme política;
• matriz função-plataforma;
• matriz de dependências;
• relatórios de teste.

O Método de As-Built Elétrico fornece a base de controle da condição energizada.

Erros comuns em projetos CPC. Entre os erros mais críticos estão:

• tratar centralização como simples consolidação de hardware;
• não mapear common-mode failures;
• usar redundância aparente com infraestrutura compartilhada;
• não definir comportamento degradado;
• funções principal e backup no mesmo domínio de falha;
• SCL sem governança de revisão;
• falta de orçamento de latência;
• testes apenas em condição normal;
• ausência de teste de failover;
• não testar restore;
• cybersecurity aplicada depois do FAT;
• expansão sem capacity planning;
• depender de HMI para função de trip;
• não validar caminho físico até disjuntor;
• documentação diferente da versão ativa.

Quando CPC faz sentido. Centralização tende a ser mais atraente quando existem:

• muitas funções e bays;
• alta integração digital;
• process bus;
• necessidade de automação sistêmica;
• forte governança de engenharia;
• equipe capacitada;
• requisitos de disponibilidade claramente definidos;
• capacidade de teste abrangente.

Em instalações menores ou sem infraestrutura digital madura, uma arquitetura distribuída pode continuar sendo mais simples e resiliente.

Entregáveis de engenharia para CPC

Entregável	Conteúdo
filosofia de proteção e controle	funções, principal/backup e autoridade
arquitetura funcional	função × plataforma e fallback
arquitetura física	servidores, IEDs, MUs, redes e clocks
matriz de dependências	função × recurso e common mode
requisitos temporais	latência, jitter, availability e recovery
SCL/SCD	configuração IEC 61850 controlada
cybersecurity design	zonas, acessos, hardening e updates
matriz de degradação	comportamento em falhas
plano FAT/HIL	cenários elétricos e digitais
plano SAT	provas ponta a ponta e failover
As-Built	arquivos executáveis, versões e evidências

Contratação e entregáveis de engenharia para CPC

O escopo precisa ser orientado a desempenho e verificabilidade. Não basta exigir “sistema IEC 61850 redundante”.

Uma contratação madura deve definir:

1. requisitos funcionais
2. requisitos de dependability/security
3. arquitetura principal e backup
4. limites temporais
5. comportamento degradado
6. cybersecurity
7. capacidade e expansão
8. entregáveis digitais
9. FAT/HIL
10. SAT e energização
11. treinamento
12. gestão de ciclo de vida

O Design Review e o Comissionamento devem ser previstos desde a contratação, não adicionados depois.

CPC como mudança de arquitetura, não de princípio elétrico. Centralizar proteção não altera as leis que regem faltas, zonas, seletividade ou tempos de disjuntores. Uma 87B continua precisando distinguir falta interna de externa; uma 21 continua precisando medir impedância; uma 50BF continua precisando comprovar que o disjuntor falhou.

O que muda é a infraestrutura que permite à função enxergar o sistema e atuar sobre ele. Quando medição, comunicação e processamento passam a ser compartilhados, a engenharia precisa provar que essa infraestrutura possui a mesma — ou maior — confiabilidade que os relés dedicados substituídos.

CPC bem projetado pode elevar flexibilidade, observabilidade e capacidade de automação. CPC mal projetado pode transformar uma falha localizada em falha comum de várias proteções. A diferença está na arquitetura: independência real, redundância verificável, temporalidade medida, configuração governada e testes que deliberadamente provoquem as falhas que o sistema afirma suportar.

Por Eng. Altair Andrade Galvão — Diretor de Engenharia e Projetos, A3A Engenharia.

Referências técnicas

[1] IEEE. IEEE C37.300-2024 — IEEE Guide for Centralized Protection and Control (CPC) Systems within a Substation.

[2] IEC. IEC 61850:2026 SER — Communication networks and systems for power utility automation — all parts.

[3] IEC. IEC 61850-6:2009+AMD1:2018+AMD2:2024 CSV — Configuration description language for communication in electrical substations related to IEDs.

[4] IEC. IEC 61850-9-2:2011+AMD1:2020 CSV — Sampled values over ISO/IEC 8802-3.

[5] IEC. IEC 62351-6:2020 — Security for IEC 61850.

Perguntas frequentes

O que é CPC em subestações?

CPC é Centralized Protection and Control: uma arquitetura em que várias funções de proteção, automação e controle são executadas em plataformas centralizadas a partir de dados provenientes de IEDs, merging units e redes de comunicação.

CPC é a mesma coisa que subestação digital?

Não. Uma subestação digital pode manter proteção distribuída por bay usando IEC 61850. CPC centraliza parte das funções de proteção e controle em plataformas comuns. As duas abordagens podem coexistir.

Qual é o principal risco da centralização?

A concentração aumenta a importância de falhas comuns. Uma falha de plataforma, rede, clock, software ou configuração pode afetar várias funções simultaneamente se a arquitetura não possuir independência e redundância reais.

CPC elimina relés de proteção locais?

Não necessariamente. Arquiteturas híbridas podem manter IEDs locais para proteção principal ou backup e usar CPC para outras funções. A decisão deve ser feita por função e consequência.

Qual o papel da IEC 61850 em CPC?

Ela fornece modelos de dados, serviços de comunicação, GOOSE, Sampled Values e SCL, permitindo separar função de proteção do dispositivo físico e trocar dados entre plataformas de forma padronizada.

Por que sincronismo é crítico?

Funções que comparam grandezas de fontes distintas precisam de alinhamento temporal. Sincronismo também sustenta Sampled Values, SOE, oscilografia e testes end-to-end.

Como provar a redundância de um CPC?

FAT e SAT devem provocar falhas de plataformas, switches, links, clocks, fontes e serviços, medindo continuidade, tempo de recuperação, alarmes e funções preservadas.

Quais documentos precisam compor o As-Built de CPC?

Além de diagramas, devem ser entregues SCD e arquivos IEC 61850, settings, lógica, configurações de rede, versões de software/firmware, matriz de dependências, matriz de degradação e evidências de FAT/SAT.

Proteção centralizada elimina a necessidade de relés de retaguarda?

Não. A filosofia deve avaliar independência funcional, redundância e falhas de modo comum. A migração para CPC não elimina a necessidade de proteção de retaguarda e estudos de dependabilidade.

Como demonstrar a aptidão de um CPC antes da energização?

Com requisitos funcionais, estudos e engenharia de configuração, análise de redundância e falhas comuns, FAT, testes HIL quando aplicáveis, SAT e demonstração das saídas físicas de trip.

Materiais técnicos complementares

Soluções relacionadas

• Instalações Elétricas de Média Tensão
• Gestão de Requisitos, Evidências e Critérios de Aceite
• Governança Documental
• Processos, Workflows e Aprovações

Serviços de Engenharia relacionados

• Design Review em Projetos de Engenharia
• Comissionamento e Aceite Técnico de Instalações Elétricas
• Owner’s Engineering
• Estudo de Curto-Circuito, Seletividade e Coordenação de Proteções

Arquitetura, automação e proteção

• Subestação Digital e IEC 61850
• IED em Subestações
• PRP e HSR
• IEC 62351
• Proteção de Sistemas Elétricos de Potência
• Proteção de Barramentos
• Proteção de Linhas de Transmissão
• Proteção de Transformadores

Governança e ciclo de vida

• Método de As-Built Elétrico
• Guia de Estudos Elétricos em Sistemas de Potência