Estudo de Caso: Projeto e Implementação do Protocolo IEC de Diversos Fabricantes em La Venta II, CFE

Transcrição

1 Estudo de Caso: Projeto e Implementação do Protocolo IEC de Diversos Fabricantes em La Venta II, CFE Julian Alzate e Dave Dolezilek, Schweitzer Engineering Laboratories, Inc. Resumo: Usando o conhecimento obtido a partir de diversos projetos de sistemas, este artigo aborda o primeiro sistema inservice aplicado no mundo real que integra Dispositivos Eletrônicos Inteligentes (IEDs) de diversos fabricantes. A norma IEC fornece métodos de desenvolvimento das melhores práticas de engenharia de proteção, integração, controle, monitoração, medição e testes de subestações. A empresa concessionária de energia elétrica do México, Comisión Federal de Electricidad (CFE), optou por implantar o seu mais novo sistema integrado de proteção e controle do sistema de transmissão usando o protocolo IEC e avaliou a tecnologia para possíveis futuras inclusões na padronização de seus projetos. Os primeiros IEDs escolhidos para a proteção foram selecionados a partir de dispositivos que suportam o IEC e que foram aprovados pelos consumidores. Para o projeto de La Venta II, o foco principal foi incluir dispositivos com IEC do maior número possível de fabricantes ao invés de adotar critérios tradicionais de projeto. Além dos equipamentos principais de proteção e controle, o consumidor solicitou que todos os fabricantes conectassem os IEDs à rede para demonstrar sua capacidade de comunicação via IEC IEDs adicionais foram acrescentados num bay auxiliar, pois as limitações do projeto requeriam que o núcleo do sistema fosse efetivo e de grande utilidade; isto não é uma demonstração de um sistema de controle, mas sim um projeto piloto para adquirir experiência com o novo protocolo. Este sistema integrou 24 dispositivos de 9 diferentes plataformas de produtos fornecidos por 6 fabricantes diferentes. A implementação foi concluída em quatro meses e incluiu os mais novos produtos do mercado de diversos fabricantes, envolvendo dispositivos apropriados para comunicação via Internet e contando com as contribuições de engenheiros de sete fusos horários. IEC é uma norma abrangente com muitos protocolos diferentes incluídos. Os fabricantes podem desenvolver e os usuários finais podem projetar a implementação de diferentes combinações dos protocolos e dos diversos recursos que eles fornecem. Portanto, é importante que esses usuários finais não apenas especifiquem sua intenção de usar o IEC 61850, mas também indiquem quais as partes da norma eles querem usar e, mais importante ainda, como esperam que seja o desempenho do sistema. Durante a implementação deste projeto, tornou-se aparente que alguns detalhes importantes da implementação fossem definidos de acordo com os critérios dos fabricantes e não estabelecidos pela norma. A CFE concluiu que a única forma de ser bem sucedida seria documentar separadamente os pontos abordados, sobre o que a norma é bastante vaga, como requisitos para garantir a funcionalidade requerida do sistema. A seguir, exemplos desses detalhes: Quantidade de associações cliente/servidor para o dispositivo Quantidade de mensagens peer-to-peer que o dispositivo vai exibir ou transmitir Quantidade de mensagens peer-to-peer que o dispositivo vai subscrever ou receber Número de caracteres permitidos no nome do dispositivo Diagnósticos do tempo de operação ( run-time ) do dispositivo Configuração do dispositivo através da linguagem SCL ( Substation Configuration Language ), baseada nos arquivos XML ao invés de ajustes 1. HISTÓRICO A CFE escolheu desenvolver o projeto de La Venta II como um sistema funcional totalmente baseado nos protocolos incluídos na norma IEC 61850, integrando dispositivos de diversos fabricantes, com o objetivo de avaliar o IEC para possíveis inclusões na especificação de seu sistema. La Venta II é uma usina eólica que vai gerar aproximadamente 3 GWh até 2014, tornando-se a maior usina eólica do México e da América Central. A concorrência para o primeiro estágio do projeto foi ganha pela IBERINCO (IBERDROLA Ingeniería y Construcción) e integra dispositivos da SEL, GE, ZIV, Siemens, RuggedCome e Team Arteche. Outros fabricantes foram convidados a participar; no entanto, ou eles não tinham o protocolo IEC disponível ou não foram aprovados. A IBERINCO forneceu os serviços de gerenciamento global do projeto, para todo o projeto, bem como as diretrizes para os dispositivos lógicos, nós lógicos, controles e mapeamento de dados. Também foi responsável pela definição da IHM e dos bancos de dados das portas de ligação ( gateway ). A CFE definiu os bancos de dados da estação mestre. A SEL forneceu os dispositivos de proteção e controle, projetou e implementou a integração do IEC de todos os IEDs, desenvolveu o gateway para os protocolos do SCADA existente, criou um esquema de chaveamento automático para um gateway redundante usando GOOSE via IEC 61850, projetou e construiu os painéis, preparou o sistema para testes, treinou a CFE e forneceu suporte no local para o comissionamento. Ou outros fabricantes forneceram suporte para seus dispositivos durante os testes e comissionamento no local. Para comparação, um projeto alternativo foi também desenvolvido, usando Rua Ana Maria de Souza, 61 Campinas-SP CEP: Tel: (19) Fax: (19) Pg: 1

2 somente IEDs da SEL para montar um sistema completo, visando atender a todos os requisitos dos IEDs e IHM da subestação. Embora esse projeto não tenha sido implementado, ele serve como um exemplo para aqueles que quiserem usar o IEC 61850, mas que prefiram um único fornecedor e uma única interface nas configurações. Alguns consumidores desenvolveram um projeto de um único fabricante com o objetivo de simplificar o treinamento e a manutenção ao mesmo tempo em que propicia suporte para futuras inclusões de dispositivos com IEC de qualquer fabricante. Com o objetivo de criar a função do gateway do protocolo necessário para conexão da rede IEC aos protocolos do SCADA existente, a equipe de projetos da SEL projetou a integração de todos os IEDs. Essa equipe estava bem preparada para essa tarefa uma vez que os produtos e sistemas da SEL têm sido disponibilizados, desde 2001, com protocolos MMS, GOOSE e GSSE via IEC e UCA2. O desenvolvimento recente de produtos de outros fabricantes criou a oportunidade de um verdadeiro projeto multifabricante. 2. ESCOPO A subestação La Venta II é parte de um sistema de transmissão associado à Usina Eólica La Venta II e, no seu primeiro estágio, consistirá numa subestação elevadora de 34,5/230 kv. Cem geradores eólicos, em grupos de 20, serão conectados à barra de 34,5 kv. No sistema de 230 kv, um arranjo barra principal/barra auxiliar vai conectar a usina eólica ao sistema nacional. O diagrama unifilar do lado de 230 kv está mostrado na Fig L 21PP 79 50BF 50BF 50BF 51PHS 87T 51PHS 51NHS 51NLS 87B RD Fig. 1. Requisitos de proteção da subestação La Venta II 3. NOVO SOFTWARE CRIA AUTOMATICAMENTE A CONFIGURAÇÃO E OS AJUSTES DAS COMUNICAÇÕES DOS SISTEMAS INTEGRADOS DE COMUNICAÇÃO Os novos métodos de configuração do IEC trabalham em conjunto com o software de configuração das aplicações dos IEDs existentes anteriormente para criar os ajustes, parametrizar os relés e outros IEDs para que possam executar as lógicas, intertravamentos e proteção. O melhor método prático mencionado na norma é baseado na criação de um arquivo CID ( Configured IED Description ) configurado para descrição dos IEDs, o qual usa SCL para descrever todas as configurações do protocolo IEC 61850, sendo o download efetuado em seguida, diretamente no IED. Quando da inicialização do IED, ele encontra o arquivo CID e executa a autoconfiguração. Esse arquivo é transferido localmente ou remotamente para o IED sem afetar qualquer outra funcionalidade do mesmo. Considerando que essa configuração é somente um arquivo de configuração da comunicação IEC 61850, não tem como impactar de forma inadvertida nos ajustes de proteção e automação. Dessa forma, a comunicação é configurada, testada e comissionada sem afetar as demais aplicações do IED. Além disso, esse arquivo CID é também restituído diretamente da memória do IED para confirmar de forma definitiva qual a configuração que está sendo usada pelo IED. Como a norma IEC não especifica uma forma única de executar a configuração, diversos fabricantes optaram por adicionar a configuração do IEC como ajustes entre os ajustes existentes de proteção e automação do seu IED. Para esses IEDs, o software de ajustes da proteção é usado para criar e efetuar o download de todos os ajustes do IED. É necessário tomar todos os cuidados para preservar, testar e comissionar todos os ajustes afetados, ou possivelmente afetados. A porção superior da Fig. 2 ilustra a relação entre as configurações do IEC via projetos salvos como arquivos a serem distribuídos através de meios tradicionais de transferência de arquivos, como FTP, e carregados diretamente nos IEDs locais ou remotos. A porção inferior da Fig. 2 ilustra os ajustes de proteção e automação sendo criados e o IED sendo configurado com uma aplicação de software separada e específica, com propósitos especiais. Rua Ana Maria de Souza, 61 Campinas-SP CEP: Tel: (19) Fax: (19) Pg: 2 selbr@selinc.com

3 Fig. 2. Configuração dos arquivos do IEC e configuração dos ajustes de proteção e automação Para os IEDs que suportam os arquivos SCL necessários, o software de configuração de qualquer fabricante deve ter capacidade de visualizar as descrições dos dados dos arquivos SCL que representam as necessidades do sistema e os recursos dos IEDs. Isso permite que o projetista visualize e conecte logicamente os dados entre os IEDs de qualquer fabricante. Usando os métodos descritos na norma, o software de configuração do IEC propicia que o projetista crie pacotes de dados e métodos de emissão de relatórios que identifiquem quais os dados a serem enviados, para quem eles devem ser transmitidos, e quando e sob quais condições devem ser enviados. Uma vez que o software de configuração do IEC importa arquivos que representam os recursos dos IEDs, os projetistas usam esses recursos para trocar dados entre os IEDs. Após os ajustes ou arquivos de configuração terem sido instalados nos IEDs, eles reportam os dados para os gateways do SCADA, estações de trabalho da engenharia, Registradores Seqüenciais de Eventos (SERs), etc., assim como entre eles próprios. Assim que um IED tenha sido configurado para receber dados de outro IED através das mensagens GOOSE, via protocolo IEC 61850, o IED tem acesso a essas informações como um estado lógico com o valor binário de um ou zero. Para o IED, isso representa o mesmo que um estado binário recebido de qualquer outra forma, tal como o espelho do estado de um bit de outro relé via protocolo serial peer-to-peer, uma indicação de mudança de estado via comando SCADA, um comando do operador no painel frontal, um comando remoto via console da engenharia ou um contato de entrada via fiação tradicional. Na Fig. 3, a janela frontal ilustra a combinação de diversas variáveis lógicas digitais do IED numa expressão gráfica da lógica Booleana. Essas variáveis lógicas digitais são usadas livremente, sem restrição, com base na sua fonte, como por exemplo, contatos de entrada via fiação tradicional, GOOSE, serial peer-to-peer, ou comando remoto ou via painel frontal. A janela posterior ilustra a associação do conteúdo das mensagens GOOSE recebidas com as variáveis lógicas digitais de um IED. Nesse caso, os Bits Lógicos RB01 a RB03 são recebidos de outros IEDs via mensagens GOOSE e são, em seguida, combinados. RB04 e RB05 são recebidos de outro IED através de uma mensagem GOOSE e, em seguida, combinados com RB06, o que pode ser atualizado a partir de qualquer fonte de dados possível. Fig. 3. Mapeamento do conteúdo de GOOSE para as variáveis lógicas do IED e uso dessas variáveis em um editor gráfico da lógica Rua Ana Maria de Souza, 61 Campinas-SP CEP: Tel: (19) Fax: (19) Pg: 3

4 4. ARQUITETURA DO SISTEMA A rede local (LAN) da subestação é configurada através de uma topologia em anel com chaves Ethernet instaladas em cada painel. Considerando as curtas distâncias e o fato de que todos os IEDs estão dentro de um painel, os IEDs do bay são conectados à chave através de cabos de cobre. As conexões chave-para-chave entre os bays, mais longas, são efetuadas via cabos de fibra óptica que suportam a topologia em anel, conforme mostrado na Fig. 4. Essa topologia fornece comunicação em anel redundante no nível das chaves, porém as conexões dos IEDs de um mesmo painel do bay não garantem a redundância nas comunicações no nível dos IEDs, conforme observado em experiências anteriores. Além disso, não é permitido o uso de chaves internas aos IEDs conectados em anel, pois isso reduz drasticamente a confiabilidade e aumenta a complexidade para o único propósito que é o de superar uma falha no cabo. Remote HMI Conitel DNP ZIV CPT ZIV HMI ZIV HMI SEL-3332 SCADA Gateway Router + Firewall GPS SW-1 Fiber-Optic Ring SW-5 SEL-487B 87B RuggedCom SW-2 SW-3 SW-4 SEL BC SEL BF, 25, 27 GE F650 BC SEL BF, 25, 27 SEL-387E GE T60 87T GE F60 50, 51HS GE F35 50, 51TZ Siemens 7SJ62 50, 51LS Siemens 7SJ61 50, 51N ZIV 6MCV BC SEL , 67 SEL-279H 79 SEL BF, 25, 27 GE L90 87L SEL-311L Fig. 4. Diversas conexões na rede Ethernet da subestação, conectada em anel via fibra óptica Dois computadores locais propiciam o uso da IHM pelo usuário para visualização e controle local. Os gateways redundantes do protocolo do SCADA propiciam a interface com o SCADA mestre em DNP3 e Conitel A função de religamento de um bay é executada por um relé que não inclui o IEC 61850, com capacidade de suportar protocolos seriais de comunicação via Ethernet. Esse relé tinha sido previamente aprovado e amplamente usado pela CFE; ele foi adicionado posteriormente, durante o estágio de desenvolvimento do projeto, em função de circunstâncias não previstas. Conforme mencionado, cada painel do bay tem sua própria chave Ethernet, independentemente do número de IEDs. Isso se deve a vários motivos: robustez nas comunicações, facilidade de instalação no campo e de futuras manutenções. Os IEDs conectados por meio de chaves num arranjo em estrela, com as chaves conectadas em anel via fibra óptica, fornecem a LAN mais segura e confiável da subestação. Como cada painel tem sua própria chave, nenhuma cablagem de comunicação dos bays precisou ser desconectada ou retestada no período entre os testes de aceitação na fábrica ( factory acceptance testing FAT) e a instalação no campo. Cada painel foi concluído e testado durante o FAT. Assim que foram entregues no local, as chaves foram reconectadas em anel e a rede foi rapidamente reconfigurada, independentemente da eventual distância entre elas. A manutenção e eventuais soluções de problemas futuros na Ethernet foram simplificadas pela inclusão de uma chave em cada bay ao invés de conexões multidrop entre os IEDs ou operação através de cabos longos até uma chave distante. 5. CONSIDERAÇÕES NA IMPLEMENTAÇÃO DAS COMUNICAÇÕES 5.1. Somente o IRIG-B Atende aos Requisitos de Precisão dos Tempos O protocolo IEC requer uma resolução nas estampas de tempo da ordem de microssegundos, com precisão da sincronização de tempo de pelo menos ±100 microssegundos. A precisão do SNTP é, na melhor das hipóteses, de alguns milissegundos e varia de acordo com o tráfego do sistema. Logo, esse não é um método de sincronização de tempo recomendado ou confiável para as redes do IEC A melhor prática recomendada para sincronização de tempo permanece o IRIG-B, pois é o único método que fornece tal precisão. Alterações futuras na norma IEC podem recomendar um método via Ethernet, se houver disponível. O IEEE está trabalhando numa norma, referida como IEEE 1588, que pode fornecer uma precisão da ordem de microssegundos na sincronização de tempo, usando a Ethernet. Rua Ana Maria de Souza, 61 Campinas-SP CEP: Tel: (19) Fax: (19) Pg: 4 selbr@selinc.com

5 5.2. Use Nomes Específicos para os Dados para Maximizar a Autodescrição A CFE solicitou que os fabricantes usassem nomes descritivos apropriados nos pacotes e dados do IEC como, por exemplo, nos nomes dos nós lógicos, evitando nomes genéricos. Entretanto, diversos fabricantes usaram nomes genéricos para simplificar e agilizar o desenvolvimento do produto. Esses nomes genéricos estão de acordo com a norma, pois ela suporta convenções de nomes genéricos. No entanto, isso não é de grande utilidade para o usuário final, sendo, na verdade, contraprodutivo para criação da SCL e autodescrição. Ao usar uma denominação genérica, os fabricantes eliminaram a capacidade de efetuar configuração automática, requerendo que o integrador consulte a documentação para ver qual a grandeza genérica do IEC que representa a tensão de fase ou posição do disjuntor requerida. Conforme mostrado na Fig. 4, cada IED deve atuar como servidor de dados para seis clientes, inclusive simultaneamente. Esses seis incluem as duas IHMs primárias duais redundantes, dois gateways dos protocolos primários duais redundantes, uma conexão local para acesso da engenharia e uma conexão remota para acesso da engenharia. Para cada conexão com o cliente, o projeto requisitou relatórios separados para o pacote de dados dos estados binários ( buffered ) e para o pacote de dados da medição ( unbuffered ) Métodos para Compatibilização da Denominação Existente dos Dispositivos A CFE decidiu continuar usando a convenção de denominação desenvolvida na empresa. Todos os bancos de dados que recebem dados da subestação gateway dos protocolos, SCADA, engenharia, IHM e documentação usam o nome do IED fonte. A convenção de nomes da CFE requer 12 caracteres, XXX YYYYY ZZZZ. Esses 12 caracteres representam o nome agregado, onde XXX identifica a subestação (ex., LVD), YYYYY é o identificador do disjuntor associado ao dispositivo (ex., 97010), e ZZZZ identifica a função do IED (ex., MCAD, o acrônimo para controle do bay). Isso combinado fica LVD97010MCAD e representa o controle do bay para o disjuntor de interligação na subestação LVD. Alguns fabricantes não fornecem 12 caracteres na sua descrição dos IEDs incluída na configuração do seu IEC Embora isso não esteja definido na norma, tem sido comum, há vários anos, via diversos protocolos, fornecer caracteres suficientes para que os usuários finais denominem de forma exclusiva cada IED baseando-se nas próprias convenções internas de denominação estabelecidas. Isso se tornou realmente um problemático aspecto local. Aspecto local é o termo usado na norma para se referir a importantes detalhes de implementação que não são abordados pela norma e têm de ser resolvidos localmente quando da implementação do IED. Entretanto, como muitos dos aspectos locais resultam em diferenças que influenciam na integração dos IEDs de fabricantes diferentes, a conotação passa a significar aspectos locais associados à subestação em que o integrador tem que fazer as tarefas funcionarem. Como o tamanho do caractere é um aspecto local, fora do escopo da norma, foram incluídos IEDs que não suportam a convenção de nomes da CFE. Uma vez que esse fato só foi conhecido numa fase adiantada do projeto, houve uma quantidade enorme de re-trabalho e testes, pois cada elemento de cada banco de dados referente aos dados desses IEDs teve de ter seu nome alterado para um nome menor e ser testado novamente. Além disso, a CFE não pôde manter sua convenção de denominação estabelecida Suporte para Funções e Dispositivos Lógicos Específicos do Consumidor A CFE, assim como outros consumidores, queria aproveitar a oportunidade de substituir os IEDs de um fabricante por aqueles de outro fabricante que executassem a mesma função e que tivessem suporte para os mesmos recursos de interface de comunicação. Essa é uma consideração válida, porém mesmo que a comunicação via protocolos IEC possa ser padronizada, somente podem ser padronizados os recursos superpostos de cada produto (o menor denominador comum). Além disso, tenha em mente que mesmo que os IEDs com IEC se comuniquem de forma similar, eles não executam as funções de proteção ou automação da mesma forma, e a norma não especifica como eles executam essas funções. Neste projeto, para permitir a troca no nível de comunicação, os dispositivos lógicos do IEC dos IEDs foram definidos para cada função requerida. Somente foi permitido que os nós lógicos especificados permanecessem dentro de cada dispositivo lógico. Exemplos de dispositivos lógicos incluem: CTRL1 para controle do bay LVD97010MCADCTRL1 PRO para proteção principal LVD97010MCADPRO MET para medição LVD97010MCADMET O lado esquerdo da Fig. 5 ilustra o software de navegação encontrando diversos IEDs (dispositivos físicos) do sistema, incluindo o do controle do bay LVD97010MCAD. O lado direito mostra o detalhe no MCAD que expõe cada dispositivo lógico e os nós lógicos internos ao dispositivo lógico CTRL1. Rua Ana Maria de Souza, 61 Campinas-SP CEP: Tel: (19) Fax: (19) Pg: 5

6 Logical Devices Physical Device 5.5. Pacotes de Dados dos IEDs Fig. 5. Navegação através dos dispositivos físicos, dispositivos lógicos e nós lógicos Dentro de cada dispositivo lógico, somente os nós lógicos requeridos para o projeto podiam se comunicar dentro dos pacotes de dados. Isso foi atendido por alguns fabricantes através do uso de pacotes de dados configuráveis que foram facilmente modificados para tal. Além disso, diversos nós e dispositivos lógicos default foram deixados no IED para o caso de necessidades futuras, mas eles não foram reportados nos pacotes de dados desenvolvidos para o projeto in-service. A CFE solicitou pacotes de dados para os estados dos dados binários (estados), medições analógicas (medidas), e bits GOOSE (GOOSE), conforme resumido na Tabela I. Tabela I Pacotes de Dados Nome Associação Tipo do Relatório Estados Estado binário Buffered Medidas Medições Unbuffered GOOSE Bits GOOSE Mensagens GOOSE O conteúdo dos pacotes de dados de medição e estados digitais está ilustrado no artigo da referência [1]. 6. MENSAGENS GOOSE PARA A PROTEÇÃO A CFE quis efetuar testes detalhados com o objetivo de ganhar confiança na nova tecnologia. O esquema completo da função de proteção de falha de disjuntor foi implementado usando a fiação tradicional e GOOSE. A seqüência de operação do esquema de falha de disjuntor está apresentada abaixo: Trip do relé de proteção O relé detecta a falta e opera e, ao mesmo tempo, envia uma mensagem GOOSE para o relé de falha de disjuntor. Retrip do relé de falha de disjuntor O relé de falha de disjuntor recebe a mensagem GOOSE e envia o sinal de retrip para o disjuntor associado. Trip da proteção de falha de disjuntor Decorrido o tempo ajustado no temporizador de falha de disjuntor, uma mensagem GOOSE de trip da função de falha de disjuntor é enviada para o relé diferencial de barras para iniciar a isolação da barra. O relé diferencial de barras recebe a mensagem GOOSE, identifica os alimentadores conectados à barra onde houve falha de disjuntor, e envia uma mensagem GOOSE para desligar os disjuntores necessários através do esquema associado de falha de disjuntor. Rua Ana Maria de Souza, 61 Campinas-SP CEP: Tel: (19) Fax: (19) Pg: 6 selbr@selinc.com

7 A operação de retrip usando GOOSE foi 12 ms mais rápida do que a operação via fiação tradicional. A função do diferencial de barras via GOOSE é 8 ms mais rápida, sem considerar que o esquema de fiação ainda tem de passar pelo relé de bloqueio. Testes adicionais foram executados após aumentar o tráfego no sistema, obtendo-se os mesmos resultados. Neste projeto específico, as chaves Ethernet com LAN virtual / priority tagging e tecnologia de colisão zero foram usadas para garantir os resultados. Os testes de tempo e tráfego estão explicados em mais detalhes no artigo da referência [1]. 7. CONCLUSÃO Durante o projeto, aprendeu-se muito, pois este foi o primeiro a integrar IEDs de diversos fabricantes em um sistema e a provar sua interoperabilidade. O sucesso foi possível em função da capacidade e experiência das equipes de trabalho em relação aos métodos e meios de troca de mensagens da nova norma. O fabricante que forneceu a maior parte dos IEDs tem fornecido essa tecnologia há seis anos, como UCA2 e IEC 61850, e recentemente atualizou sua implementação para incorporar SCL. Portanto, grande parte das lições que podem e devem ser consideradas a partir deste projeto referem-se à resolução dos problemas locais documentados em um artigo de referência para servir como um guia para especificação [1]. Esses problemáticos aspectos locais não foram solucionados no passado pois outros projetos do sistema IEC foram criados com uma pequena quantidade de IEDs do mesmo fabricante ou de dois fabricantes diferentes. 8. REFERÊNCIAS [1] FLORES, V. M., ESPINOSA, D., ALZATE, J., E DOLEZILEK, D. Case Study: Design and Implementation of IEC From Multiple Vendors at CFE La Venta II, Proceedings for the 2007 Western Power Delivery Automation Conference, Spokane, WA, 2 a 5 de abril, Para detalhes, visite < 9. BIOGRAFIAS Julian Alzate recebeu seu B.S. em Engenharia Elétrica e Telecomunicações da Universidade Nacional da Colômbia em Em 1999, Alzate ingressou na Schweitzer Engineering Laboratories, Inc. como engenheiro de aplicação em automação e integração na Divisão Internacional de Marketing e Vendas. Forneceu suporte técnico para consumidores internacionais nas aplicações de integração, controle e treinamento de relés. Em 2003, tornou-se gerente de engenharia de automação da Divisão da SEL no México, onde trabalhou na preparação de respostas a concorrências técnicas e gerenciamento de projetos internacionais. Em 2005, ele passou a ser gerente de novas tecnologias e está envolvido no desenvolvimento, implementação e gerenciamento de projetos que incluem novas tecnologias da SEL. Dave Dolezilek é o diretor de tecnologia da SEL. Ele é engenheiro elétrico, com BSEE da Montana State University e com experiência nas áreas de proteção, integração, automação, comunicação, controle, SCADA e EMS de sistemas elétricos de potência. É autor de diversos artigos técnicos e continua a pesquisar tecnologias inovadoras relacionadas à nossa indústria. Dolezilek é um inventor patenteado e participa de diversos grupos de trabalho e comitês técnicos. É membro do IEEE, do IEEE Reliability Society, grupos de trabalho do CIGRE, e dois comitês técnicos da International Electrotechnical Commission (IEC), encarregados da segurança e padronização global dos sistemas e redes de comunicação de subestações. Copyright SEL 2007 (Todos os direitos reservados) TP6271 Rua Ana Maria de Souza, 61 Campinas-SP CEP: Tel: (19) Fax: (19) Pg: 7