Cigré/Brasil CE B5 – Proteção e Automação

1. Cigré/BrasilCE B5 – Proteção e Automação Seminário Interno de Preparação para a Bienal 2006 Rio de Janeiro, setembro/06

2. Dados do Artigo • Número:B5-107 • Título:STANDARD IEC 61850 OPENS POSSIBILITY TO DEVELOP NEW MORE EFFICIENT ARCHITECTURES OF SUBSTATION AUTOMATION AND PROTECTION SYSTEMS • Autoria:J. CURK, I. KOBAL, G. PARKELJ Iskra Sistemi • País:Slovenia

3. Objetivo • Demonstrar o impacto que as novas tecnologias na área de hardware e software, aliados à introdução da norma IEC 61850 têm sobre as áreas de automação e controle de subestações, particularmente: • Capacidade de processamento • Barramentos seriais de alta velocidade • Tecnologia de rede baseada em TCP/IP • Componentes FPGA (Field Programable gate Arrays) de alta performance

4. Destaques • Alteração na arquitetura do sistema • I/O e processamento fisicamente remotos • É avanço mais significativo (break through) obtido c/IEC 61850 • Maior mudança no conceito de SAS desde a década de 80 • Processamento (CPUs) em área não críticas (EMC), hardware de uso geral, comunicação padronizada, redundância, hot swap • Oportunidades para empresas com foco em áreas distintas participarem (hardware, medição, soft básico, soft. aplicação) • Nível de estação • Componentes (SCADA, gateways, firewalls, GPS) interconectados entre si por rede TCP/IP sem preocupação de tempo real • Nível de Bay • Funções de proteção e controle, intertravamento, tag de tempo • Alta capacidade de processamento • Cada IED gerencia vários bays  redução do número de IEDs • Redundância obtida por funcionamento em paralelo das IEDs • Duas ou mais funções compartilhando mesma CPU e mesmo barramento de dados

5. Destaques • Nível Processo • Aquisição física de sinais • Transdução para forma digital (A/D e debouncing) • Transmissão para o nível de bay em tempo real (hard real time) • Uso de FPGAs • Comunicação veloz • Pré-processamento rápido de sinais (similar aos DSPs) • Processamento paralelo • Software • Separação de hardware X software independente • Modularização permite acrescentar funções sem código fonte do resto  Dispositivos tradicionais viram software • Sist. Op: Portabilidade, escalabilidade e disponibilidade • LINUX com RTAI (RealTime Application Interface) • Porte entre plataformas: não precisa reescrever código • Foco sobre qualidade e funções do código da aplicação • Software para gerenciamento do sistema: Web browser (Java e XML) • Uso de soft de prototipagem (e.g. Matlab) para desenvolver funções de proteção e controle

6. Dúvidas A idéia da prototipagem e desenvolvimento de funções de proteção e controle com ferramentas apenas de software, de forma independente de hardware abre oportunidade para novos módulos serem introduzidos, desenvolvidos por terceiros ou pelo pessoal do próprio cliente. • Que procedimentos a norma indica para garantir a qualidade no funcionamento do sistema? • Na parte 4 da norma (Gestão do projeto e do sistema), é descrito no item 6 (ciclo de vida do sistema) subitem 6.1 a questão de novas versões, mas sem muitos detalhes. • Também na parte 4 da norma, no item 7 (Certificação de Qualidade) são descritos os testes a serem realizados na instalação do SAS. • Que testes serão realizados para uma mudança pontual de uma rotina de software? • Em quais partes do sistema um usuário pode alterar o código? Poderia haver uma separação/modularização de forma a permitir segurança e dinamismo nestas alterações? • Como se alteraria o papel do integrador do sistema diante do cenário apresentado? Haveria um integrador para novas versões do software?

7. Dúvidas • Com a modularidade obtida, inclusive a separação entre hardware e software, quais os esquemas de redundância a serem adotados? A coordenação entre sistemas redundantes será feita da mesma forma que hoje com relés ? • Por exemplo, se adota em proteção de distância de LTs (função 21) usar um relé principal e outro secundário, coordenados de forma que o secundário atue na falha do primário, cada um em uma bobina independente do disjuntor. Com a nova distribuição de funções por IEDs isto poderá ser mantido dessa forma?

8. Conclusões • O artigo discute novas arquiteturas que são possíveis com a norma IEC 61850 • Separação entre unidades de I/O e de processamento • As funções das diferentes CPUs não precisam ser orientadas a bays • Uso de hardware and software de uso geral • Uso de menor quantidade de IEDs, mesmo quando redundância é considerada • Completa independência entre hardware and software • Software de proteção e controle poderá ser fornecido por produtores de software  mais fornecedores • Novas funções podem ser acrescentadas sem necessidade de recompilar código do sistema ou de outros componentes

9. Respostas às questões do REP • Número da questão 1.1 • Questão Which approach allows utilities to define standardized substation architectures once and then re-use them for all substation automation projects? • Resposta: O artigo não trata diretamente desta questão, mas pode-se subentender que a abordagem deve ser de modularização completa dos componentes, permitindo reaproveitamento de soluções em vários níveis, desde uma função específica até um conjunto completo de funções e soluções para um certo nível hierárquico.Ou seja, será necessário adequação apenas de partes específicas.

10. Respostas às questões do REP • Número da questão 1.2 • Questão With the separation of hardware and software, more possibilities emerge to add functions to systems. What will be the impact of such an approach for system testing and system availability and what are the conformance requirements for the individual components? • Resposta: • O artigo não discute a questão do teste, apenas as possibilidades que surgiram com a norma.