Antes de definir os detalhes da aquisição, é fundamental que o projeto de automação de alimentadores conclua o objetivo operacional, os estados da topologia, os limites de proteção e comutação, as funções e interfaces dos dispositivos, a continuidade da alimentação de controle, o comportamento da comunicação e dos dados, a responsabilidade pela cibersegurança e o fallback local ou manual. Esses parâmetros se restringem mutuamente. Um estado de interligação indefinido altera a lógica de proteção e comando; uma lista de pontos incompleta impede a revisão da comunicação; um orçamento de energia não calculado torna a seleção da alimentação de controle arbitrária. Portanto, um diagrama unifilar com o nome de um protocolo não constitui uma base de projeto completa. Este guia fornece uma estrutura de lançamento em nível de sistema antes que um projeto avance para a atribuição de funções aos dispositivos ou para a aquisição de controladores dentro de um pacote de equipamentos de rede inteligente.
Comece com o resultado operacional que o esquema deve produzir e, em seguida, descreva cada estado do alimentador necessário para alcançá-lo. Um diagrama unifilar estático identifica a localização dos equipamentos, mas não as transições permitidas, a autoridade de comando, as alterações de proteção ou o comportamento degradado.
| Design gate | Entrada necessária | Liberar evidências | Condição de retenção |
|---|---|---|---|
| Objetivo operacional | Resposta necessária em condições normais, de falha, de restauração e de degradação. | Descrição funcional aprovada | O objetivo permanece verbal ou ambíguo. |
| Topologia normal | Pontos normalmente abertos e fechados, limites de fonte, alimentador e ramificação | Registrador de uma linha e de comutação controlado | A posição ou o estado do dispositivo não foram confirmados. |
| Estado alternativo ou de empate | Estado de transferência permitido, base de carregamento, intenção de proteção e autoridade de fechamento | Diagrama de estados e sequência aprovada | O empate é mostrado sem regras de transição. |
| Resposta a falhas | Limite de isolamento, intenção de restauração e proprietário da sequência | Narrativa lógica ou especificação de sequência | As ações são presumidas a partir da localização dos dispositivos. |
| Estado de manutenção | Estado de isolamento, bypass, inibição de automação e retorno ao serviço | Nota de projeto do estado de manutenção | A manutenção impediria a automação adjacente. |
| Propriedade de proteção | Responsável pela zona e transferência em cada ponto de comutação | Matriz de coordenação ou de responsabilidades | Os limites são implícitos, não atribuídos. |
| Estado de reserva | Comportamento após perda de comunicação, controle ou automação. | Estado definido para cada ponto | O comportamento de perda de serviço está ausente. |
Cada estado também precisa de um responsável. O projeto deve distinguir ações autônomas, comandos confirmados pelo operador, ações somente locais e transições proibidas. Isso evita que um símbolo no desenho seja confundido com uma sequência operacional aprovada. Também expõe conflitos precocemente: um ponto proposto pode estar corretamente localizado, mas não possuir o comando, a detecção, o intertravamento ou a interface de energia necessários para a sequência pretendida.
Antes de nomear uma família de dispositivos, traduza cada posição do alimentador em funções do sistema. O objetivo é definir o que a posição deve fazer e quais evidências comprovarão que um pacote proposto pode fazê-lo.
| Posição do alimentador | Dever de definir | Entradas de interface | Provas antes da liberação |
|---|---|---|---|
| Saída da fonte | Origem da zona de proteção, interrupção da falha e intenção de religamento, quando aplicável. | Baseado em carga e falha, detecção, desligamento/fechamento, status, sequência | Base para estudo e coordenação de falhas |
| Ponto intermediário do alimentador | Suporte para isolamento, seccionamento e transferência | Comutação de funções, capacidade de suportar carga, detecção, comandos, status, intertravamentos | Sequência e atribuição de zona aprovadas |
| Lateral ou ramo | Isolamento de ramificação sem operação não intencional do tronco | Carga/falha, operação local, sensoriamento, status | Proteção e base operacional da filial |
| Gravata normalmente aberta | Transferência controlada e permissão para fechamento seguro | Realizar tarefas, verificar a lógica de tensão quando necessário, fechar a autoridade, feedback de estado | Especificação de transferência e alteração de proteção |
| Limite do cliente | Demarcação, transferência de proteção e monitoramento. | Dever de fronteira, interface de viagem, status, responsabilidade | Estudo de limites e registro de propriedade |
| Ponto de manutenção | Isolamento seguro sem comprometer as funções adjacentes. | Isolamento visível, bypass, interface de aterramento quando necessário, intertravamentos. | Projeto de isolamento e bypass |
Para cada posição, registre a tensão e a corrente contínua; a capacidade de interrupção, falha ou resistência a falhas, conforme aplicável; os requisitos de chaveamento ou isolamento de carga; a sequência de operação; a detecção; a interface de comando; o status auxiliar; a operação local/manual; os intertravamentos; o isolamento para manutenção; o ambiente; a montagem; e a conexão de linha ou cabo. Um religador a vácuo automático ilustra por que o corpo de chaveamento e a camada de controle devem ser analisados separadamente. Uma chave de limite de usuário adiciona uma demarcação e um limite de coordenação que não podem ser inferidos apenas por sua localização. Para terminologia básica, consulte o guia básico de proteção e automação de religadores.
Este artigo não atribui funções de religador, seccionador, chave de interrupção de carga ou chave de limite. Essa escolha só ocorre após a aprovação das atribuições e interfaces de cada cargo.
A automação pode perder a função mesmo quando a capacidade de comutação primária está correta. Cada local precisa de uma fonte de alimentação de controle, faixa de operação verificada, balanço de carga e energia, objetivo de continuidade, método de supervisão e comportamento definido para quando a energia disponível diminuir.
| Carga ou estado | Função necessária | Entrada para cálculo | Base de sequência | Proprietário da prova |
|---|---|---|---|---|
| Carga normal em pé | Monitoramento, prontidão de controle e comunicação. | Todas as cargas contínuas | Estado operacional contínuo | Projetista de sistemas |
| Perda de fornecimento primário | Monitoramento necessário e disponibilidade de comando | Armazenamento e cargas restantes | Período de contingência definido pelo projeto | Dono do projeto |
| Comando de abertura ou disparo | Execute a operação necessária | Demanda de bobina, atuador e interface | Sequência de falha ou isolamento aprovada | Fornecedor de embalagens de dispositivos |
| Comando para fechar ou restaurar | Feche e recarregue, se aplicável. | Demanda por mecanismos e acessórios | Sequência de restauração aprovada | Fornecedor de embalagens de dispositivos |
| Comunicação | Manter o vínculo e processar eventos | Carga de rádio, modem, gateway ou rede | Estados normais e degradados | Designer de comunicação |
| Acessórios ecológicos | Aquecimento ou outras cargas necessárias na estrutura | Dados sobre acessórios e ambiente | Ciclo de trabalho específico do local | Projetista de invólucros |
Calcule a carga em repouso, a demanda de pico, a energia de comando, o comportamento de recarga e quaisquer requisitos de autonomia ou capacidade de resposta a falhas, considerando a arquitetura e a sequência selecionadas. Não comece com um tamanho de bateria ou duração de autonomia universais. Defina o alarme de baixa energia, as operações que se tornam proibidas, o estado de segurança de contingência, a responsabilidade pela recuperação e o acesso para manutenção dos elementos de armazenamento. O projeto só poderá ser liberado quando o orçamento e a sequência necessária estiverem de acordo.
O nome de um protocolo identifica apenas parte da interface. O pacote de projeto deve definir funções, propriedade, pontos de acesso, estados, temporização, acesso e comportamento em caso de falha.
| Entrada | O que deve ser congelado | Liberar evidências |
|---|---|---|
| Proprietário e caminho do sistema | Proprietário principal, meio, rota, propriedade do segmento e limite de manutenção | Arquitetura de comunicação rotulada |
| Base de interface | Protocolo, versão/perfil, base de conformidade e responsabilidade do gateway | Especificação de interface controlada |
| Lista de pontos | Comandos, indicações, medições, alarmes, unidades, estados de qualidade e regras de validade. | Lista de pontos revisada |
| Autoridade de comando | Comandos automáticos, confirmados pelo operador, somente locais e bloqueados | Matriz de comando aprovada |
| Eventos e tempo | Prioridade do evento, armazenamento, recuperação, fonte de tempo e classe de precisão do projeto | Especificação do evento e do horário |
| Aula de performance | Requisitos de disponibilidade e latência definidos pelo projeto por função | Requisito de desempenho funcional |
| Responsabilidade pela cibersegurança | Aprovação de acesso, autenticação, credenciais, chaves/certificados, registro de atividades e atualizações. | Matriz de responsabilidades e acesso |
| Perda de serviço | Comportamento após perda de link, mestre, fonte de tempo ou acesso remoto | Especificação de fallback por estado |
A norma IEC 61850-5:2013+AMD1:2022 aborda os requisitos de comunicação para funções e modelos de dispositivos em automação de concessionárias de energia elétrica, incluindo a comunicação além dos limites da subestação. Esse escopo permite definir os requisitos funcionais antes da seleção de uma interface. A norma não define a topologia do alimentador, as capacidades de chaveamento, a autonomia de controle de potência ou a política de cibersegurança do projeto. A interoperabilidade ainda requer um perfil acordado, um modelo de dados ou mapeamento de pontos, uma base de conformidade, a definição de responsabilidade e testes específicos do projeto.
A mesma disciplina se aplica independentemente de um projeto usar uma interface baseada em IEC ou outro protocolo. A perda de comunicação não deve criar um estado de comutação indefinido, e o acesso remoto para manutenção não deve ser tratado como uma mera conveniência informal durante o comissionamento.
Um dispositivo eletricamente adequado ainda pode falhar na integração com o sistema de automação. Analise todas as interfaces em conjunto, pois uma alteração na detecção, na alimentação de controle, no feedback de estado ou nas comunicações pode alterar os limites do encapsulamento.
| Interface | Requisitos do sistema | Documentação necessária para comprovação | Motivo típico de retenção |
|---|---|---|---|
| Função principal | Carga aplicável, tarefas de montagem, desmontagem e resistência | Classificações e documentação de teste aplicável | A sequência de tarefas ou operações não foi verificada. |
| Sentindo | Base em quantidade, localização, classe, produção e ônus. | Dados do sensor e da fiação | A saída está ausente ou é incompatível. |
| comandos | Tipo de sinal, energia, permissivos e estado de falha | Cronograma da interface de controle | A saída do controlador e a entrada do atuador não correspondem. |
| Posição / status | Definições estaduais, contatos, qualidade e indicação local. | Contato auxiliar e cronograma estadual | O estado do SCADA é ambíguo. |
| Poder de controle | Alcance, demanda em pé/de pico, continuidade e supervisão. | Dados de carga verificados | O orçamento omite um mecanismo ou acessório. |
| Comunicação/tempo | Perfil da interface, pontos, eventos, comportamento temporal | Evidências de conformidade e configuração | O nome do protocolo existe, mas o mapeamento não. |
| Operação local/manual | Autoridade local, indicação, inibir e recuperação | Descrição de funcionamento e intertravamento | A perda remota não oferece uma alternativa definida. |
| Instalação/manutenção | Ambiente, montagem, conexão, isolamento e bypass | Desenhos e limites de manutenção | A interface física ou de isolamento permanece sem solução. |
Uma discrepância em uma linha é motivo para bloqueio na liberação, não para correção pela equipe de comissionamento. A revisão também deve identificar o responsável por cada interface, desde o projeto, passando pela configuração de fábrica, integração no local, até a manutenção. Isso evita a transferência silenciosa de dados faltantes entre a concessionária de energia, a empresa de engenharia, aquisição e construção (EPC), o provedor de comunicação, o fornecedor do controlador e o fornecedor do dispositivo de comutação.
Libere os detalhes de engenharia e aquisição somente quando um pacote com controle de revisão contiver:
Considere esta lista de verificação de dados de aprovação como o pacote de dados técnicos de liberação, e não como um resumo narrativo. Verifique se a tensão nominal, a corrente nominal, as interfaces de comutação e de disparo aplicáveis estão vinculadas aos dados do fabricante; verifique se os estados de operação e as atribuições de aceitação estão vinculados à especificação do projeto; e verifique se a base da falha está vinculada ao estudo de curto-circuito aprovado. Desenhos, tabelas de interfaces, cálculos e quaisquer registros de teste aplicáveis devem identificar a mesma revisão e aplicação do equipamento. O título de um documento, por si só, não constitui evidência de liberação.
Análise de engenharia representativa, não um projeto de cliente da XIYA. Um alimentador radial com interligação normalmente aberta e seccionamento remoto planejado possui um diagrama unifilar e a localização proposta dos dispositivos. A análise mostra que os estados normal e de emergência não estão totalmente definidos, a responsabilidade pela zona de proteção está indefinida, a base de continuidade de controle e alimentação está ausente, a responsabilidade pela comunicação não foi atribuída, a lista de pontos carece de estados de qualidade, a base temporal está ausente e o fallback manual não está documentado. A decisão correta é a suspensão do projeto. Cada lacuna recebe um responsável pela evidência e um critério de liberação; a atribuição de função aos dispositivos e a aquisição do controlador aguardam até que as informações estejam em consonância. Este exemplo não contém nenhuma classificação de projeto, resultado do cliente, medição em campo ou resultado de comissionamento.
Para iniciar uma análise de compatibilidade de interface, envie à XIYA POWER o diagrama unifilar e os estados da topologia, a base de falhas/proteção, o registro de regime de comutação, a planilha de controle de energia, a arquitetura de comunicação, a lista de pontos e as condições de instalação. A análise identifica interfaces completas e abertas; ela não garante adequação, conformidade ou interoperabilidade antes da verificação das evidências.
O conjunto mínimo consiste em um objetivo operacional aprovado, estados de topologia, limites de proteção e comutação, funções e interfaces dos dispositivos posição por posição, continuidade de controle e energia, arquitetura de comunicação, lista de pontos, autoridade de comando, comportamento de eventos/tempo, responsabilidade pela segurança cibernética e fallback local/manual. Esses elementos devem formar um pacote coordenado e aprovado.
A topologia determina quais pontos isolam uma falha, quais caminhos podem restabelecer o fornecimento de energia, como as zonas de proteção se alteram e quem pode comandar cada transição. Os estados normal, interligado, de falha, de manutenção e degradado, portanto, necessitam de definições explícitas. Um diagrama unifilar estático não fornece essas regras de operação.
Especifique a fonte e a faixa de operação, todas as cargas em repouso e de pico, a energia de comando, as cargas de comunicação e acessórios, a continuidade necessária, a supervisão e o comportamento de baixo consumo de energia, as operações proibidas, a responsabilidade pela recuperação e o acesso para manutenção. Calcule os valores a partir da arquitetura e da sequência aprovada, em vez de aplicar uma regra universal para baterias.
Inclui os proprietários do mestre e do caminho, limites de meio e segmento, protocolo/perfil e base de conformidade, endereçamento, lista completa de pontos e estados de qualidade, matriz de comandos, eventos e fonte de tempo, classes de desempenho do projeto, comportamento em caso de perda de link, acesso remoto, propriedade de credenciais/chaves, registro e responsabilidade de atualização.
Compare os requisitos de sistema documentados com as evidências do pacote do dispositivo em relação à função principal, sensoriamento, comandos, status, alimentação de controle, comunicação, tempo/eventos, intertravamentos, operação local, ambiente, montagem, isolamento e documentação. A ausência ou incompatibilidade de evidências em qualquer interface necessária resulta em bloqueio da liberação.
Congele o objetivo, os diagramas de estado, as atribuições de proteção e comutação, a base de carga/falha, o registro de interface do dispositivo, a planilha de controle de energia, o pacote de comunicação e lista de pontos, as responsabilidades de comando/tempo/segurança cibernética, o comportamento de fallback e os dados de instalação. Feche ou dê um destino explícito a todos os itens em aberto que afetam o escopo da aquisição.
