automação na coelba - protocolos

Foz do Iguaçu-Pr, 05 a 09 de novembro de 2002 1

Simpósio de Especialistas em Operação de Centrais Hidrelétricas

Título do Artigo: DEFINIÇÃO DOS PROTOCOLOS DE COMUNICAÇÃO EM SISTEMAS DE

AUTOMAÇÃO

Código do Artigo: SP15 - COELBA Tema Preferencial: Centros de Controle

Tópico: Automação Palavras Chave: Protocolo, ICCP, IEC, DNP3, PROCOME,automação

Autor (es): Francisco josé Rocha Santana e-mail para contato: [email protected] Empresa / Endereço

para correspondência: Av Edgard Santos n. 300 Bl-B 2 Andar, Salvador - Bahia

RESUMO

Na implementação de um Sistema de Automação a escolha dos protocolos de comunicação a serem utilizados possui uma elevada relavancia, pois nesta avaliação podemos nos deparar com problemas, tais como: limitação de fornecedores; gasto excessivo de homem/hora em integrações; etc. Na Coelba, esta tarefa contou com a experiência de 20 anos em automação do Grupo Iberdrola. Na escolha de um protocolo deve-se ter atenção especial aos seguintes itens: 1- Funcionalidades a serem disponibilizadas; 2- Padrão amplamente utilizado pelo mercado; 3- Total domínio da equipe técnica das mensagens a serem trafegadas; 4- Busca de padrões abertos e amplamente discutidos por entidades internacionais Na experiência desenvolvida pela Coelba foram definidos os seguintes protocolos: ICCP para comunicação entre centros de controle; IEC para a comunicação entre o centro de controle e as UTR ( Unidades Terminas Remotas ) e para a comunicação entre as UTR’s e os IED’s na SE esta sendo utilizado o DNP3. Com estas definições estamos obtendo uma grande flexibilidade na escolha dos fornecedores pois toda documentação para implementação destes protocolos é de domínio da Coelba. Inicialmente na Coelba foi definido o PROCOME ( Proteção Controle e Medidas ) como o protocolo de comunicação entre UTR e IED’s. Como este protocolo limitava a

participação de fornecedores tradicionais de equipamentos do Setor Eletrico, a Coelba efetuou um estudo amplo para a escolha de um protocolo que atendesse esta necessidade. Foi definido o DNP V3.0 subset 2 como protocolo padrão entre UTR e IED’s. O domínio dos protocolos e suas respectivas implantações é uma necessidade indispensável para garantir a implementação por diferentes fornecedores, haja visto que toda documentação não define de forma precisa os tipos de mensagens que cada fornecedor deve implementar. Assim, é necessário que o cliente defina uma documentação mínima, porém precisa, especificando seu perfil, onde deverá constar toda a denominação utilizada, bem como às interpretações e restrições impostas ao protocolo. Alem dos problemas de implementação a nível de Aplicação é necessário possuir uma definições clara quanto o meio físico e às características a nível de Enlace, tais como Paridade, Bits de Caracteres, Bits de Stop, tempo de estabelecimento de portadora, CTS, RTS e outros. Diante disso, na escolha de um protocolo de comunicação, é importante equacionar de forma clara os quatro itens acima citados levando-nos a garantir uma melhor customização dos investimentos.



Introdução Nos sistemas de automação a troca de informações entre os distintos subsistemas, é uma necessidade indiscutivel para que o sistema de automação possa desempenhar todas suas funcionalidade. A implantação da troca de informações requesita a implantação de um protocolo de comunicação, sendo este protocolo implementado de forma coerente em ambos os lados possibilitando uma comunicação sem erros. Diante desta necessidade se buscam caminhos para se efetuar a escolha do protocolo de comunicação entre equipamentos, a definição do mesmo requer um exaustivo trabalho de analise e conhecimento pois este não finaliza na escolha do protocolo e sim na definição e execução dos testes de integração. Existe hoje no mercado vários tipos de protocolos fruto da necessidade de transferência de informações entre equipamentos. Como a escolha do protocolo em muitos casos ocorreu antes de uma definição padronizada muitos forncedores definiram por seu próprio entendimeto, isto provocou uma dependência de implementações especificas que só funciomam com equipamentos do mesmo forncedor e mesmo modelo pois, mesmo entre equipamentos do mesmo fornecedor porém de modelos diferentes ocorre de não se conseguir uma integração perfeita. Esta possibilidade nos leva à condição temida por todos os clientes tornar-se refém do fornecedor. Definindo-se de forma clara e amplamente discutido os quatro pontos da escolha do protocolo a ser utilizado, 1- Funcionalidade; 2- Padrão amplamente utilizado no mercado; 3- Total domínio da equipe técnica do cliente e 4- Padrões abertos. Dentre todos os passos não se minimizar nenhum dos quatro passos principalmente o conhecimento e treinamento da equipe técnica, por ser este o mais difícil de se obeter sucesso, já que para se conhecer um protocolo requer tempo e dedicação e com certeza muitas horas de estudo.

A definição coerente de um protocolo trás bastante beneficios na portabilidade dos sistemas, reduzindo os custos por possibilitar uma concorrência saudável entre os fornecedores.

Corpo do Texto

Durante os trabalhos de especificaão do sistema é que vamos definir quais as funcionalidade a serem intercambiadas entre os distintos subsistemas, como este trabalho tem um enfoque particular para sistemas de automação e especificamente tomando como referência o sistema implementado na Coelba, podemos caracterizar os seguintes subsistema (veja figura 1 e 2 ): • Subsistema COS x COD; • Subsistema COD x SE’s; • Subsustema SE x IED’s; • Subsistema SE x Remotas de Poste. Subsistema COS x COD, neste subsistema foram estabelecidas basicamente as funcionalidades de: Aquisição de dados, nesta deverá ser possibilidado o intercambio de estados, analógicos, cotadores e envio de comandos; Mecanismos de exploração, o mecanismo difinido para este subsistema foi a transferência de informações em blocos não havendo portanto necessidade de um polling contínuo e sendo cada sistema responsavel pelo envio de suas informações sendo assim foi definido um relacionamento mestre/mestre. Este subsistema deverá suportar canais de comunicação que utilizem os seguintes meios: • Comunicação por satélite. • Fibra óptica. • Links dedicados da rede Telefônica. O meio de comunicação e seus parâmetros deverão ser configuráveis a nível de roteadores onde o protocolo especifico será encapsulado em TCP/IP. Dadas as características necessárias a este protocolo elegemos o ICCP.



Subsistema COD x SE’s, neste subsistema foram estabelecidas basicamente as funcionalidades de: Aquisição de dados, nesta deverá ser possibilidado o intercambio de estados, analógicos, cotadores, envio de comandos, sincronização, transferência de parâmetros e transferência de arquivos; Estatística de Comunicaciones, nesta funcinalidade o protocolo, em verdade deverá possibilitar uma gestão da comunicação de forma que o sistema possa analisar suas falhas; Mecanismos de exploração, o mecanismo difinido para este subsistema foi o de polling continuo controlado pela estação mestre com esta informação foi definido o relacionamento mestre/escravo sem informações enviadas expôntamente. Este subsistema deverá suportar canais de comunicação que utilizem os seguintes meios: • Radio. • Comunicação por satélite. • Fibra óptica. • Ondas portadoras. • Par trançado (rede local). • Rede Telefônica Comutada. • Trunking O meio de comunicação e seus parâmetros deverão ser configuráveis a um nível de base de dados para cada canal de comunicação possibilitando caracteristicas diferentes de comunicação a depender do canal escolhido. Dadas as características necessárias a este protocolo elegemos o IEC-870-5-101. Subsustema SE x IED’s; neste subsistema deverá ser possibilidado o intercambio de estados, analógicos, cotadores, envio de comandos, sincronização e transferência de aquivos; Mecanismos de exploração, o mecanismo difinido para este subsistema foi o de polling continuo controlado pela estação mestre sendo que as imformações prioritárias derão ser informadas expôntaneamente foi definido o relacionamento mestre/escravo com informações enviadas expôntamente. Este subsistema deverá suportar canais de comunicação que utilizem os seguintes meios:

• Radio. • Comunicação por satélite. • Fibra óptica. • Ondas portadoras. O meio de comunicação e seus parâmetros deveerão ser configuráveis a um nível de base de dados para cada canal de comunicação possibilitando caracteristicas diferentes de comunicação a depender do canal escolhido. Dadas as caracteristicas necessárias na Coelba inicalmente foi esclhido o protocolo PROCOME após a analise mais aprofundada do mercado mudou-se para o DNP Versão 3.0 Subset 2. Subsistema SE x Remotas de Poste, neste subsistema foram estabelecidas basicamente as funcionalidades de: Aquisição de dados, nesta deverá ser possibilidado o intercambio de estados, analógicos, sincronização e envio de comandos; Mecanismos de exploração, o mecanismo difinido para este subsistema foi o de polling continuo controlado pela estação mestre sendo que as imformações prioritárias derão ser informadas expôntaneamente foi definido o relacionamento mestre/escravo com informações enviadas expôntamente. Este subsistema deverá suportar canais de comunicação que utilizem os seguintes meios: • Radio. • Comunicação por satélite. • Fibra óptica. O meio de comunicação e seus parâmetros deveerão ser configuráveis a um nível de base de dados para cada canal de comunicação possibilitando caracteristicas diferentes de comunicação a depender do canal escolhido. Na busca de documentação de uma documentação já esctrita que suporta-se Dadas as características necessárias a este protocolo elegemos o DNP Versão 3.0 Subset 2. A busca de um padrão amplamente utilizado no mercado não é uma tarefa



fácil, recomendamos neste item a busca de especialistas que já possuam vasta experiência na implementação de protocolos covem lembrar que para cada subsistema poderá haver um especialista em epecifico, isto se faz necessário por se possuir sistemas muito especificos onde um forcedor com toda certeza estará melhor especializado em uma area do que em outra. É recomendavel também que se busque os organismos internacionais que se dedicam a normatização como o IEC, IEEE, CCITT, ANSI e outras. A busca de um protocolo só deve ser finalizada com o total domínio da equipe técnica assim todas as contratações devem ser efetuadas com sua parcela de treinamento. Um treinamento dado no inicio de um projeto deverá ser complementado quando este já estive implementado e em fase de expansão pois é nesta etapa que o aproveitamento de um treinamento terá seu aproveitamento maximizado. Particularidades, uma pergunta clássica é porque não se utilizar o DNP na comunicação entre COD x SE e não o IEC, a resposta foi porque o IEC as mensagens são caracterizadas por inicio e fim sendo mais fácil a determinação de uma mensagem com erro tornando o sistema mais imune, já no DNP as mensagens podem possuir tamanhos variados possibilitando a entrada de informações altamente prejudiciais ao funcionamento do sistema receptor não se devemos eatar atentos pois é atavés dos meios de comunicação que pode-se introduzir erros nos sistemas. Não so a definição das funcionalidades que estão basicamente a nivel de aplicação mas tabém as definições a nível físico e enlace. Nesta definição torna-se bastante clara a importância da documentação das conexões a serem utilizadas entre os distintos equipamentos, esta definição requer que sejam efetuados testes em laboratório garantido-se as pingens, tipos de conectores e tudo mais que seja necessário para que realmente se estabeleça a comunicação.

Após o passo de escolha de um protocolo o passo seguinte tão importante quanto é que se escreva de forma clara o perfil de implementação deste protocolo caso já não exista, é o caso do protocolo IEC 870-5-101, pois o mesmo esta definido como norma mas sua implementação requer uma definição clara de como será usada as mensagens bem como sua sequência segue em anexo o documento de interroperabilidade definido para o protocolo IEC 870-5-101. Conclusão Pode-se verificar que tanto às funcionalidades como os meios são comuns em varios subsistemas isto pode nos levar a uma conclusão precipitada de escolher o mesmo protocolo, sem no entanto efetuar uma avaliação detalhada do mercado onde deverá ser levado em consideração em qual ponta iremos ter ou necessitar de um maior numero de distintos fornecedores e também conhecer a fundo estes fornecedores de forma a evitar que em uma definição precipitada deixar de fora fornecedores consagrados. Não devemos nunca esquecer que o protoclo de comunicação não é objetivo fim do sistema e sim um meio para facilitar e melhorar sua implementação. DOCUMENTO DE INTEROPERABILIDAD. (18/01/00) A continuación se incluye el documento de Interoperabilidad recogido de la Norma de Acompañamiento IEC-870-5-101, señalando las opciones que este Perfil (IBERDROLA-COELBA) incluye. NETWORK CONFIGURATION. (18/01/00) (network-specific parameter) [ x ] Point-to-point [ x ] Multipont-party line [ x ] Multiple point-to point [ ] Multipont-star



PHYSICAL LAYER. (18/01/00) (network-specific parameter) Transmission speed (control drirection) Unbalance interchange Unbalanced interchange Balanced interchange circuit V.24 / V.28 circuit V.24 / V.28 circuit X.24 / X.27 Standard Recommended if > 1200 bit/s [ ] 100 bit/s [ x ] 2400 bit/s [ ] 2400 bit/s [ ] 56000 bit/s [ ] 200 bit/s [ x ] 4800 bit/s [ ] 4800 bit/s [ ] 64000 bit/s [ ] 300 bit/s [ x ] 9600 bit/s [ ] 9600 bit/s [ ] 600 bit/s [ x ] 19200 bit/s [ ] 19200 bit/s [ x ] 1200 bit/s [ ] 38400 bis/s Transmission speed (monitor drirection) Unbalance interchange Unbalanced interchange Balanced interchange circuit V.24 / V.28 circuit V.24 / V.28 circuit X.24 / X.27 Standard Recommended if > 1200 bit/s [ ] 100 bit/s [ x ] 2400 bit/s [ ] 2400 bit/s [ ] 56000 bit/s [ ] 200 bit/s [ x ] 4800 bit/s [ ] 4800 bit/s [ ] 64000 bit/s [ ] 300 bit/s [ x ] 9600 bit/s [ ] 9600 bit/ [ ] 600 bit/s [ x ] 19200 bit/s [ ] 19200 bit/s [ x ] 1200 bit/s [ ] 38400 bis/s LINK LAYER. (18/01/00) (network-specific parameter) Frame format FT1.2, single caracter 1 and the fixed time out interval are used exclusively in this companion standard.

Link transmission procedure Address field of the link [ ] Balanced transmission [ ] Not present (balanced transmission only) [ x ] Unbalanced transmission [ ] One octet [ x ] Two octetes Frame length [ ] Structured __255___ Maximum length L (number of octets) [ x ] Unstructured APPLICATION LAYER. (18/01/00) Transmission mode of application data Mode 1 (Least significant octet first), as defined in clause 4.10 of IEC/870-5-4, is used exclusively in this companion standard. Common address of ASDU (system-specific parameter) [ ] One octet [ x ] Two octets Information object address (system-specific parameter) [ ] 1 octet [ ] Structured [ ] 2 octets [ x ] Unstructured [ x ] 3 octets Cause of transmission (system-specific parameter) [ x ] One octet [ ] Two octets (with originator address) Selection od standard ASDUs



Process information in monitor direction (station-specific parameter) [ x ] <1> := Single-point information M_SP_NA_1 [ ] <2> := Single-point information with time tag M_SP_TA_1 [ x ] <3> := Double-point information M_DP_NA_1 [ ] <4> := Double-point information with time tag M_DP_TA_1 [ x ] <5> := Step position information M_ST_NA_1 [ ] <6> := Step position information with time tag M_ST_TA_1 [ ] <7> := Bitstring of 32 bit M_BO_NA_1 [ ] <8> := Bitstring of 32 bit with time tag M_BO_TA_1 [ x ] <9> := Measured value, normalized value M_ME_NA_1 [ ] <10> := Measured value, normalized value with time tag M_ME_TA_1 [ ] <11> := Measured value, scaled value M_ME_NB_1 [ ] <12> := Measured value, scaled value with time tag M_ME_TB_1 [ ] <13> := Measured value, short floating point value M_ME_NC_1 [ ] <14> := Measured value, short floating point value with time tag M_ME_TC_1 [ ] <15> := Integrated totals M_IT_NA_1 [ ] <16> := Integrated totals with time tag M_IN_TA_1 [ ] <17> := Event of protection equipment with time tag M_EP_TA_1 [ ] <18> := Packed start events of protection equipment with time tag M_EP_TB_1 [ ] <19> := Packed output circuit info of protection equip. with time tag M_EP_TC_1 [ ] <20> := Packed single-point information with status change detection M_PS_NA_1 [ ] <21> := Measured value, normalized value without quality descriptor M_ME_ND_1

[ x ] <30> := Single-point information with time tag CP56Time2a M_SP_TB_1 [ x ] <31> := Double-point information with time tag CP56Time2a M_DP_TB_1 [ x ] <32> := Step position information with time tag CP56Time2a M_ST_TB_1 [ ] <33> := Bitstring of 32 bit with time tag CP56Time2a M_BO_TB_1 [ ] <34> := Measured value, normalized value with time tag CP56Time2a M_ME_TD_1 [ ] <35> := Measured value, scaled value with time tag CP56Time2a M_ME_TE_1 [ ] <36> := Measured value, short floating value with time tag CP56Time2a M_ME_TF_1 [ x ] <37> := Integrated totals with time tag CP56Time2a M_IT_TB_1 [ ] <38> := Event of protection equipment with time tag CP56Time2a M_EP_TD_1 [ ] <39> := Packed start events of protection equipment with time tag CP56Time2a M_EP_TE_1 [ ] <40> := Event output circuit information of protection equipment with time tag CP56Time2a M_EP_TF_1 Process information in control direction (station-specific parameter) [ x ] <45> := Single command C_SC_NA_1 [ x ] <46> := Double command C_DC_NA_1 [ x ] <47> := Regulating step command C_RC_NA_1 [ x ] <48> := Set point command, normalized value C_SE_NA_1



[ ] <49> := Set point command, scaled value C_SE_NB_1 [ ] <50> := Set point command, short floating point value C_SE_NC_1 [ ] <51> := Bitstring of 32 bit C_BO_NA_1 System information in monitor direction (station-specific parameter) [ x ] <70> := End of initialization M_EI_NA_1 System information in control direction (station-specific parameter) [ x ] <100> := Interrogation command C_IC_NA_1 [ x ] <101> := Counter interrogation command C_CI_NA_1 [ x ] <102> := Read command C_RD_NA_1 [ x ] <103> := Clock syncrhronization command C_CS_NA_1 [ ] <104> := Test command C_TS_NB_1 [ x ] <105> := Reset process command C_RP_NC_1 [ ] <106> := Delay acquisition command C_CD_NA_1 Parameter in control direction (station-specific parameter) [ x ] <110> := Parameter of measured value, normalized value P_ME_NA_1 [ ] <111> := Parameter of measured value, scaled value P_ME_NB_1 [ ] <112> := Parameter of measured value, short floating point value P_ME_NC_1 [ ] <113> := Parameter activation P_AC_NA_1 File transfer (station-specific parameter)

[ x ] <120> := File ready F_FR_NA_1 [ x ] <121> := Section ready F_SR_NA_1 [ x ] <122> := Call directory, select file, call file call section F_SC_NA_1 [ x ] <123> := Last section, last segment F_LS_NA_1 [ x ] <124> := Ack file, ack section F_AF_NA_1 [ x ] <125> := Segment F_SG_NA_1 [ ] <126> := Directory F_DR_TA_1 BASIC APPLICATION FUNCTIONS. (18/01/00) Station initialization (station-specific parameter) [ x ] Remote initialization General interrogation (system- or station-specific parameter) [ x ] Global [ ] Group 1 [ ] Group 7 [ ] Group 13 [ ] Group 2 [ ] Group 8 [ ] Group 14 [ ] Group 3 [ ] Group 9 [ ] Group 15 [ ] Group 4 [ ] Group 10 [ ] Group 16 [ ] Group 5 [ ] Group 11 [ ] Group 6 [ ] Group 12 Addresses per group have to be defined Clock synchronization (station-specific parameter)



[ x ] Clock synchronization Command transmission (object-specific parameter) [ x ] Direct command transmission [ ] Select and execute command x ] Direct set point command transmission ] Select and execute set point command [ x ] C_SE ACTTERM used [ ] No additional definition [ ] Short pulse duration (duration determined by a system parameter in the outstation) [ ] Long pulse duration (duration determined by a system parameter in the outstation) [ ] Persistent output Transmission of integrated totals (station- or object-specific parameter) [ x ] Counter request [ x ] General request counter [ ] Counter freeze without reset [ ] Request counter group 1 [ ] Counter freeze with reset [ ] Request counter group 2 [ ] Counter reset [ ] Request counter group 3 [ ] Request counter group 4 Addresses per group have to be defined Parameter loading (object-specific parameter) [ x ] Threshold value

[ ] Smoothing factor [ x ] Low limit for transmission of measured value [ x ] High-limit for transmission of measured value Parameter activation (object-specific parameter) [ ] Act/deact of persistent cyclic or periodic transmission of the addressed object File transfer (station-specific parameter) [ x ] File transfer in monitor direction [ x ] File transfer in control direction



Arquitetura do Sistema de Automação

Figura1: Arquitetura do sistema de Automação

Arquitetura de Integração entre IED e UTR

figura 2: Arquitetura de Integração entre IED e UTR



Bibliogria Redes de Computadores Das LANs MANs e WANs às Redes ATAM ( Luis Fernando Gomes Soares, Guido Lemos Sérgio Colcher ). Redes Locais de Computadores, Protoclos de Alto Nivel e Avaliação de Desempenho (José Antão Beltrão Moura, Jacques Philippe Sauvé, William Ferreira Giozza, José Fábio Marinho de Araújo )

automação na coelba - protocolos

Documents