Implementação Normalizada de Automatismos de · PDF file5.3 SIPROTEC 7SJ645 -...

Implementação Normalizada de Automatismos de Subestações de

Energia especificados por Redes de Petri

Rui Filipe das Neves Parreira

Dissertação para obtenção do Grau de Mestre em

Engenharia Electrotécnica e Computadores

Júri:

Presidente: Professor Doutor Paulo José da Costa Branco

Orientador: Professor Doutor José Luís Pinto de Sá

Vogal: Professor Doutor Pedro Alexandre Flores Correia

Dezembro 2011

II

Implementação Normalizada de Automatismos de Subestações de

Energia especificados por Redes de Petri

Rui Filipe das Neves Parreira

III

Agradecimentos

Para que fosse possível concluir uma das mais importantes etapas da minha vida, os mais puros

e sinceros agradecimentos para os meus pais, que me apoiaram incondicionalmente em todos os

momentos, e a quem dedico este trabalho.

Aos meus Professores, especialmente ao Professor José Luis Pinto de Sá, por todas as lições e

conhecimento que auxiliaram a minha formação, tanto a nível académico, como pessoal, e por me

proporcionar a oportunidade de participar num projecto tão ambicioso, o meu obrigado.

Agradeço a todos os meus familiares e amigos que estiveram comigo nas fases boas e menos

boas da minha vida, que contribuíram para o que sou hoje, especialmente à Maria Inês, por todos

aqueles momentos de felicidade que vivemos juntos.

À Laura, pelo amor e motivação que durante os últimos anos me deram a força para continuar, e

por ter sido a minha luz quando o caminho esteve muito sombrio, o meu mais profundo obrigado.

IV

Resumo

Com a evolução do paradigma de controlo das Subestações para arquitecturas distribuídas, e

criação da Norma CEI 61850, surge a necessidade de reintroduzir no Sistema de Automação de

Subestação (SAS) os automatismos, descritos em Redes de Petri, desenvolvidos nos anos 80. Tor-

na-se então necessário compatibilizar a Norma com as Redes de Petri, motivação do presente tra-

balho cujo objectivo é definido como o desenvolvimento de metodologias para a implementação de

automatismos na CEI 61850.

A metodologia desenvolvida para solucionar o problema reside na utilização de um controlador

lógico comunicante com os diversos DEIs, através de mensagens GOOSE (definidas na CEI

61850), utilizando uma rede local Ethernet. O processamento dos automatismos é centralizado nes-

te controlador lógico, enquanto os DEIs são utilizados para adquirirem informação indispensável ao

funcionamento dos automatismos e reenviar os comandos operacionais, emitidos pelo controlador,

para os equipamentos da Subestação.

O controlador lógico utilizado é baseado em software executado num computador (SoftPLC),

sendo programável directamente segundo as linguagens da CEI 61131-3, e portanto permite a utili-

zação de ferramentas de conversão automática de Redes de Petri para CEI 61131-3 de acordo com

as metodologias formais existentes que garantem a execução fiel de acordo com os modelos descri-

tivos. Deste modo, obtém-se uma metodologia que realiza uma implementação normalizada dos au-

tomatismos, descritos em Redes de Petri, na arquitectura distribuída dos actuais SAS.

Com o objectivo de comprovar o funcionamento do sistema, foi construído um ambiente de teste

laboratorial, onde se simulou parte de uma Subestação, através da utilização de diversos DEIs.

Com recurso a uma mala de ensaios, foram gerados sinais analógicos representativos dos diversos

incidentes que ocorrem na rede e observado o funcionamento dos dispositivos, comprovando-se o

correcto funcionamento do sistema e bons resultados de tempo real.

Palavras-chave: CEI 61850, CEI 61131-3, SAS, DEI, Redes de Petri

V

Abstract

With the evolution of the Substation control paradigm to distributed architectures, and creation of

the IEC 61850 standard, arises the need to reintroduce in the Substation Automation System (SAS)

the automation functions, modeled by Petri Nets (PN), developed in the 80s. Therefore, it is neces-

sary to match the standard with the PN, which motivated the present thesis with the objective of de-

veloping methodologies of automation functions implementation over the IEC 61850.

The method developed to solve the problem uses a logic controller communicating with Substa-

tion IEDs, through GOOSE messages (defined in the IEC 61850) using an Ethernet Local Area Net-

work. The processing of the automation functions are centralized in the logic controller, while the

IEDs are used to acquire important information to the execution of those functions, and redirection of

operational commands, emitted by the controller, to the Substation Equipment.

The Logic controller is based of software executed on a computer (SoftPLC), being programmed

directly according to the IEC 61131-3 languages, and therefore allowing the use of automatic transla-

tion tools, that translate the PN to the IEC 61131-3 according to formal existing algorithms that guar-

antee the faithful execution of the PN models. This way, it is obtained a methodology that performs a

standardized implementation of the automation control functions, modeled by PN, in the distributed

architectures of the modern SAS.

With the objective of proving the correct execution of the system, it was built a laboratorial test

environment, in which was simulated part of a Substation through the use of several IEDs. Using a

test device were generated analog signals representing several types of incidents, that can occurs in

the Electric Grid, and observed the devices behavior, proving the correct execution of the automation

functions and good results in real-time performance.

Keywords: IEC 61850, IEC 61131-3, SAS, IEDs, Petri Nets

VI

Conteúdo

Agradecimentos ................................................................................................................................... III

Resumo ................................................................................................................................................ IV

Abstract ................................................................................................................................................. V

Conteúdo ............................................................................................................................................. VI

Lista de Figuras ..................................................................................................................................... IX

Lista de Tabelas .................................................................................................................................... XI

Lista de Abreviaturas .......................................................................................................................... XII

1. Introdução ..................................................................................................................................... 1

1.1 Enquadramento ................................................................................................................. 1

1.2 Objectivos .......................................................................................................................... 3

1.3 Organização da Dissertação ............................................................................................. 3

2. Automatismos e Redes de Petri .................................................................................................... 5

2.1 Objectivos e Descrição dos Automatismos ....................................................................... 5

2.2 Modos de Funcionamento dos Automatismos .................................................................. 6

2.3 Introdução às Redes de Petri ............................................................................................ 7

2.4 Definições Fundamentais .................................................................................................. 8

2.5 Modelação de Sistemas .................................................................................................. 10

2.6 Implementação de um sistema de controlo .................................................................... 11

3. CEI 61131-3 .................................................................................................................................. 13

3.1 Introdução à Norma ........................................................................................................ 13

3.2 Diagramas Ladder ........................................................................................................... 15

3.2.1 Lógica de Relés ...................................................................................................... 15

3.2.2 Programação de Diagramas Ladder ....................................................................... 16

3.2.3 Equivalentes em Lógica Elementar ........................................................................ 17

3.3 Lista de Instruções .......................................................................................................... 18

4. Conversão de Redes de Petri ....................................................................................................... 21

4.1 Motivação para a Conversão .......................................................................................... 21

4.2 Conversão para Diagramas Ladder ................................................................................ 21

4.3 Conversão para Lista de Instruções ............................................................................... 26

5. Implementação de Redes de Petri em DEIs ................................................................................. 31

5.1 Introdução ....................................................................................................................... 31

5.2 TPU-S420 – EFACEC ..................................................................................................... 32

VII

5.2.1 Lógica Programável ................................................................................................ 32

5.2.2 Programação de Redes de Petri Interpretadas ...................................................... 35

5.2.3 Simulações e Resultados ........................................................................................ 37

5.3 SIPROTEC 7SJ645 - SIEMENS ..................................................................................... 41

5.3.1 Lógica Programável ................................................................................................ 41

5.3.2 Programação de Redes de Petri Interpretadas ...................................................... 45

5.3.3 Simulações e Resultados ........................................................................................ 47

5.4 Comparação de Resultados e Conclusões ..................................................................... 48

6. Implementação Centralizada ....................................................................................................... 49

6.1 Introdução ao método de implementação centralizada .................................................. 49

6.2 Aplicação de DEIs ........................................................................................................... 51

6.3 Controlador Lógico .......................................................................................................... 53

6.3.1 Software de Automação .......................................................................................... 53

6.3.2 CoDeSys ................................................................................................................. 54

6.3.3 Software de Comunicações GOOSE – AX-S4 MMS .............................................. 57

6.3.4 Tecnologia OPC ...................................................................................................... 58

6.4 Programação e Configuração das Ferramentas ............................................................. 60

6.4.1 Programação e Configuração do Software de Automação .................................... 60

6.4.2 Configuração da Rede no Software de Comunicações GOOSE ............................ 64

6.4.3 AX-S4 GOOSE ........................................................................................................ 66

6.4.4 Software para Interligação de servidores OPC - LinkMaster .................................. 67

6.5 Algoritmo de implementação dos automatismos ............................................................ 68

7. Teste do Sistema em Ambiente Laboratorial .............................................................................. 71

7.1 Arquitectura do Sistema .................................................................................................. 71

7.2 Simulação de Incidentes ................................................................................................. 74

7.3 Bateria de Testes ............................................................................................................ 76

8. Conclusão e Trabalhos Futuros .................................................................................................... 77

9. Referências Bibliográficas ............................................................................................................ 79

Anexo 1 – Redes de Petri dos Automatismos para Linhas MT ........................................................... 81

Anexo 2 – Propriedades das Redes de Petri ....................................................................................... 85

Anexo 3 – Problemas associados à conversão das Redes de Petri ..................................................... 89

Anexo 4 – Exemplo completo de Conversão ...................................................................................... 95

Anexo 5 – Lógica Programável de DEIs ............................................................................................... 99

VIII

Anexo 6 – Substation Configuration Language ................................................................................ 101

IX

Lista de Figuras

Figura 1 - Exemplo de representação de uma Rede de Petri ......................................................... 9

Figura 2 - Escolha Livre e Escolha Imposta .................................................................................. 10

Figura 3 – Arquitectura abstracta do sistema de automação ........................................................ 11

Figura 4 - Arquitectura do PLC ...................................................................................................... 13

Figura 5 - Implementação Interna do PLC ..................................................................................... 13

Figura 6 - Modelo de Programação com a introdução da CEI 61131 ........................................... 14

Figura 7 - Esquema de Funcionamento do Relé [15] .................................................................... 16

Figura 8 - Fluxo de Controlo relativo a Diagramas Ladder ............................................................ 16

Figura 9 - Elementos Básicos do Ladder ....................................................................................... 16

Figura 10 - Diagrama Ladder de Exemplo ..................................................................................... 17

Figura 11 – Conversão de Ladder para Lógica Elementar ............................................................ 18

Figura 12 – Exemplo 1 de Lista de Instruções .............................................................................. 20

Figura 13 - Exemplo 2 de Lista de Instruções ............................................................................... 20

Figura 14 - Circuito do Lugar Pi de uma Rede de Petri ................................................................. 23

Figura 15 - Rede de Petri para exemplo de Conversão ................................................................ 24

Figura 16 - Diagrama Ladder do Exemplo de Conversão ............................................................. 24

Figura 17 - Circuito Equivalente..................................................................................................... 25

Figura 18 - Conversão Genérica de Redes de Petri para Diagramas Ladder .............................. 25

Figura 19 - Arquitectura do Programa em Listas de Instruções .................................................... 26

Figura 20 - Bloco de Transição ...................................................................................................... 27

Figura 21 - Bloco de Lugar ............................................................................................................ 28

Figura 22 - Rede de Petri para exemplo de conversão para Listas de Instruções ....................... 28

Figura 23 - Código em Listas de Instruções convertido da Rede de Petri da Figura 22 ............... 29

Figura 24 - Modelo de Implementação Indirecto ........................................................................... 31

Figura 25 - Menu Principal WinProt4 ............................................................................................. 32

Figura 26 - Menu Principal do WinLogic ........................................................................................ 32

Figura 27 - Funções associadas as Gates .................................................................................... 33

Figura 28 - Edição de Propriedades de uma Gate ........................................................................ 33

Figura 29 - Comandos Lógicos ...................................................................................................... 34

Figura 30 - Exemplo de Gate AND ................................................................................................ 35

Figura 31 - Rede de Petri de Exemplo e Conversão para Diagrama de Ladder ........................... 36

Figura 32 - Circuito Lógico Equivalente ......................................................................................... 36

Figura 33 - Resultados da Simulação ............................................................................................ 38

Figura 34 - Menu de Definições relativas ao Dispositivo ............................................................... 41

Figura 35 - Editor CFC ................................................................................................................... 42

Figura 36 – Listagem de Blocos DIGSI 4 ...................................................................................... 43

Figura 37 - Inserir Blocos no Diagrama CFC ................................................................................. 43

Figura 38 - Conexão a variáveis externas ao CFC ....................................................................... 44

Figura 39 - Controlo da ordem de processamento ........................................................................ 44

X

Figura 40 - Matriz de Configuração ............................................................................................... 44

Figura 41 - Criar nova informação ................................................................................................. 45

Figura 42 - Rede de Petri de Exemplo e Conversão para Ladder Reduzido ................................ 46

Figura 43 - Circuito Lógico Equivalente ......................................................................................... 46

Figura 44 - Circuito Lógico programado no SIPROTEC ................................................................ 47

Figura 45 - Sistema de Comunicações da Implementação Centralizada ..................................... 51

Figura 46 - Modelo de Comunicações ........................................................................................... 51

Figura 47 - Arquitectura do CoDeSys (Suit) [18] ........................................................................... 55

Figura 48 - Fluxo de Informação .................................................................................................... 56

Figura 49 - Arquitectura do Controlador para Tempo-Real [19] .................................................... 56

Figura 50 - Janela principal do CoDeSys ...................................................................................... 61

Figura 51 - Separador Communication Settings do controlador CoDeSys Control RTE .............. 61

Figura 52 - Editor de Configuração Simbólica ............................................................................... 63

Figura 53 - Processo de Configuração Global do Software .......................................................... 58

Figura 54 - Janela para adicionar Dispositivos ao MOE ............................................................... 65

Figura 55 - Janela de exportação de configurações GOOSE ....................................................... 65

Figura 56 - Janela principal do AX-S4 GOOSE ............................................................................. 66

Figura 57 - Pesquisa das etiquetas disponibilizadas pelo Servidor OPC do AX-S4 GOOSE ....... 67

Figura 58 – Interface OPC ............................................................................................................. 59

Figura 59 - Janela principal do LinkMaster .................................................................................... 67

Figura 60 - Arquitectura do Ambiente de Teste ............................................................................. 71

Figura 61 - State Sequencer da Mala de Ensaios da Omicron ..................................................... 74

Figura 62 - Rede de Petri do Automatismo de Religação Automática .......................................... 81

Figura 63 - Rede de Petri do Automatismo de Deslastre por Tensão Zero .................................. 82

Figura 64 - Rede de Petri do Automatismo de Mínimo de Tensão ............................................... 83

Figura 65 - Rede de Petri com os 3 automatismos ....................................................................... 84

Figura 66 - Varrimento Horizontal e Varrimento Vertical nos Diagramas Ladder ......................... 89

Figura 67 - Rede de Petri Genérica ............................................................................................... 90

Figura 68 - Diagrama de Ladder Genérico 1 ................................................................................. 90

Figura 69 - Sequência de Disparo correspondente ao Diagrama da figura 68 ............................. 91

Figura 70 - Diagrama de Ladder Modificado ................................................................................. 91

Figura 71 - Sequencia de Disparo modificada ............................................................................... 92

Figura 72 - Rede de Petri para exemplificação de falha de funcionamento .................................. 93

Figura 73 - Lista de Instruções da conversão da Rede de Petri da Figura 72 .............................. 93

Figura 74 - Lista de Instruções corrigida e optimizada da Rede de Petri da Figura 72 ................ 94

Figura 75 - Rede de Petri para exemplo completo de conversão ................................................. 95

Figura 76 - Diagrama de Ladder resultante da conversão da Rede de Petri da figura 75 ............ 96

Figura 77 - Lista de Instruções resultante da conversão da Rede de Petri da figura 75 .............. 97

Figura 78 - Modelo de Configuração de Subestação .................................................................. 102

XI

Lista de Tabelas

Tabela 1 - Modos de Funcionamento dos Automatismos ............................................................... 6

Tabela 2 - Listagem de Instruções ................................................................................................ 19

Tabela 3 - Blocos de Instruções referentes à Rede de Petri ......................................................... 28

Tabela 4 - Programação de Exemplo da Rede de Petri ................................................................ 36

Tabela 5 - Script de Teste .............................................................................................................. 37

Tabela 6 - Resultados da Simulação ............................................................................................. 38

Tabela 7 - Resultados da Simulação Filtrados .............................................................................. 39

Tabela 8 - Resultados da Simulação ............................................................................................. 47

Tabela 11 - Bateria de Testes Realizados ..................................................................................... 76

Tabela 12 - Lógica Programável dos DEIs .................................................................................... 99

XII

Lista de Abreviaturas

API – Application Programming Interface;

AT – Alta Tensão;

CEI – Comissão Electrotécnica Internacional;

CFC – Continuous Function Chart

CPU – Central Processing Unit;

DEI – Dispositivo Electrónico Inteligente;

DF – Deslastre por Mínimo de Tensão;

DU – Deslastre por Tensão Zero;

FBD – Function Block Diagram;

GOOSE – Generic Object Oriented Substation Event;

GVL – Global Variable List;

IL – Instruction List;

LD – Ladder Logic;

MI – Máxima Intensidade;

MOE – MMS Object Explorer;

MT – Média Tensão;

PLC – Programmable Logic Controller;

POU – Program Organization Unit

RA – Religação Automática;

RdP – Rede(s) de Petri;

RTE – Real Time Environment

SAS – Sistema de Automação de Subestação;

SCD – Substation Configuration Description;

SCL – Substation Configuration Language;

SEE – Sistema de Energia Eléctrica;

SFC – Sequential Function Chart;

SoftPLC – Software PLC;

SPCC – Sistema de Protecção Comando e Controlo;

ST – Structured Text;

TI – Transformador de Intensidade;

TP – Transformador de Potência;

TT – Transformador de Tensão;

Capítulo 1 – Introdução

Página | 1

1. Introdução

1.1 Enquadramento

O sector da energia eléctrica tem vindo a evoluir a longo dos anos, comprovando-se com o

consecutivo aumento da qualidade da energia [1,2]. Um elemento chave para esta evolução é

a inovação dos Sistemas de Protecção, Comando e Controlo (SPCC) instalados nas Subesta-

ções de Energia.

Dispositivos Electrónicos Inteligentes (DEI)

Os sistemas de protecção baseados em relés electromecânicos, e posteriormente, electró-

nicos analógicos, deram lugar a sistemas constituídos por dispositivos electrónicos de proces-

samento digital, denominados de DEIs1. Estes DEIs estão ligados, por cablagem, a aparelhos

de corte, como disjuntores, e realizam funções de protecção, aquisição de medidas, registo

cronológico de acontecimentos e oscilografias [3,4].

Estes dispositivos são equipados com capacidades de lógica programável contudo, a forma

de realizar esta programação não é normalizada, ou seja, cada fabricante possui a sua própria

linguagem [4], embora afirmem que as suas linguagens se baseiam na Norma da Comissão

Electrotécnica Internacional (CEI) 61131-3, desenvolvida para uniformizar o controlo realizado

com Autómatos Programáveis (PLC, Programmable Logic Controllers) [5].

A cada componente primário relevante da Subestação, como Transformador de Potência

(TP), Linhas de Alta Tensão (AT); Linhas de Média Tensão (MT); entre outros; é atribuído um

ou mais DEIs, sendo ligados a este, Transformadores de Intensidade (TI), Transformadores de

Tensão (TT) e Isoladores Ópticos. Deste modo, aos DEIs é disponibilizado um leque de infor-

mações relativas a medidas e estados, que lhes permite desempenhar as suas funções.

Automatismos

O Projecto-Tipo da EDP [3] referente a Subestações de Distribuição define os automatismos

de Deslastre por Tensão Zero, Deslastre de Mínimo de Frequência e Religação Automática.

Estes automatismos não são os únicos desenvolvidos para o SEE, mas constituem a essência

do Projecto-Tipo relativo às Linhas MT.

Os referidos automatismos foram aperfeiçoados e modelados em Redes de Petri (RdP) pelo

Professor José Luís Costa Pinto de Sá, orientador deste trabalho, na sua tese de doutoramento

em 1988 [6], dando origem à construção de um Autómato de Subestações, ligado por cabla-

gem aos equipamentos da subestação e relés não-digitais, programado numa arquitectura de

tempo real multitarefas que implementa fielmente as Redes de Petri concebidas [7].

1 Os actuais relés são a 3ª geração destes dispositivos: primeira geração, 1900-1975, relés electromecânicos; segunda geração,

1975-1992, relés electrónicos analógicos; terceira geração, 1992-actualidade, relés electrónicos digitais;


Página | 2

Entretanto, em 1993, com o surgimento da norma CEI 61131-3, foram definidas linguagens

de automação normalizadas e em 2000 surgiram trabalhos [8,9] onde foram desenvolvidos mé-

todos para a conversão formal das Redes de Petri para as referidas linguagens, obtendo-se um

funcionamento fiel aos modelos das Redes de Petri.

Contudo, nos últimos 15 anos, os sistemas de controlo evoluíram para arquitecturas distri-

buídas, e a implementação anterior, referente a funções de automação modeladas por RdP, fi-

cou ultrapassada. Nestas arquitecturas distribuídas são utilizados encravamentos (inibição de

funcionamento, originado pela verificação de determinadas condições ou eventos) para a reso-

lução de conflitos no controlo dos dispositivos, gerados pelo funcionamento concorrente de vá-

rios automatismos [3]. Estes encravamentos são, por vezes, demasiado restritivos, oferendo

fraco suporte à coordenação adequada entre funções [10].

CEI 61850

Nos Sistemas de Automação de Subestações (SAS), a ausência de protocolo e de configu-

ração da rede de comunicações normalizados, deu liberdade aos fabricantes para desenvolve-

rem os seus próprios protocolos (proprietários). Nestas condições a interoperabilidade entre

dispositivos de fabricantes diferentes, baseada em conversores de protocolares, era complexa

e dispendiosa. Por interoperabilidade entende-se que um ou mais DEIs de fabricantes diferen-

tes possam trocar informações, sem necessidade de programação específica.

É neste ambiente que, em 2003, surge a Norma CEI 61850 – “Communication Networks

and Systems in Substations” (Sistema e Redes de Comunicação para Subestações). Apoiando-

se na definição de serviços para o suporte e transferência de dados, esta Norma tem como ob-

jectivo implementar um protocolo de comunicações que garanta a interoperabilidade entre dis-

positivos de diversos fabricantes, ligados a uma mesma rede de comunicações [11].

Na parte 7 da CEI 61850 [12] é definido um tipo de comunicação horizontal entre dis-

positivos físicos a nível de painel, as mensagens GOOSE – “Generic Object Oriented Substa-

tion Event”. Estas mensagens suportam a transmissão de vários tipos de informação, como o

estado do disjuntor ou arranque de protecções, pelos dispositivos físicos existentes na Subes-

tação, utilizando uma rede local de Ethernet, com requisitos de tempo real específicos2.

Portanto, o problema actual é a compatibilização dos automatismos, definidos por Redes de

Petri, e a CEI 61850, no novo paradigma de controlo distribuído.

É de notar que a falha do funcionamento dos automatismos não coloca em risco nem a se-

gurança da Subestação, nem da Rede Eléctrica, pois os automatismos são desenvolvidos para

realizar reposições, ou aceleração de protecção. A protecção normal, em si, é independente

dos automatismos. Em derradeira análise, em caso de falha da automação, um operador Hu-

2 Os requisitos de tempo-real exigidos pela Norma são descritos na parte 5 da mesma.


Página | 3

mano pode realizar a reposição, que aliás era a prática comum em Portugal até há 25-30 anos

antes de surgir a automação nas Subestações, onde havia pessoal a trabalhar por turnos para

assegurar o normal funcionamento das Subestações. Noutros países mais avançados, já exis-

tia o telecomando e alguns automatismos dispersos, e portanto não houve preocupação no de-

senvolvimento de automatismos sofisticados.

1.2 Objectivos

O tema desta tese foi abordado em publicações anteriores, destacando-se [13]. No referido

trabalho, o autor conclui que a Norma não consegue suportar o sistema de automação mode-

lado com Redes de Petri, e para solucionar o problema são propostos novos nós lógicos e

classes de funções. A modificação com extensões proprietárias vai contra a própria ideologia

de Norma universal, perdendo-se as vantagens da sua utilização. Esta abordagem difere do

presente trabalho, onde o que se pretende é obter metodologias normalizadas, portando defi-

ne-se como objectivo principal deste trabalho, o desenvolvimento de metodologias para imple-

mentação de automatismos especificados por Redes de Petri no ambiente da Norma CEI

61850.

Sendo que os DEIs possuem lógica programável, é possível programar funções adicionais

para execução. É objectivo deste trabalho determinar a viabilidade desta lógica programável

ser utilizada para a implementação dos automatismos propostos.

É essencial que a implementação dos automatismos reproduza fielmente o comportamento

das Redes de Petri, mantendo válidas as análises matemáticas realizadas às mesmas, portan-

to é necessário investigar os métodos formais existentes e problemas associados na utilização

de Redes de Petri em sistemas de automação distribuídos.

Para além da apresentação dos métodos de implementação, pretende-se demonstrar o fun-

cionamento inerente a cada fase da programação, de modo a exemplificar a realização uma

implementação real a partir de modelos em Redes de Petri.

Para concluir o trabalho construir-se-á um ambiente de teste laboratorial para comprovar o

correcto funcionamento do sistema.

Em suma, pretende-se desenvolver e comprovar uma metodologia que utilize os DEIs pre-

sentes nas Subestações de Energia para implementar automatismos, sobre a CEI 61850, nu-

ma arquitectura distribuída, idealmente com os automatismos executados fielmente de acordo

com os modelos das Redes de Petri, cumprindo os requisitos de tempo real exigidos para estes

sistemas.

1.3 Organização da Dissertação

Este trabalho encontra-se dividido em 9 capítulos e 6 anexos, cujo conteúdo se descreve de

seguidamente.


Página | 4

No capítulo 2 são abordados os automatismos que se propõem implementar, realizando-se

a apresentação dos mesmos e dos seus objectivos, assim como os seus modos de funciona-

mento. São estudadas as Redes de Petri, onde após a introdução deste tipo de linguagem ma-

temática, são apresentadas as definições formais e funcionamento. São ainda indicadas as

medidas para modelação e implementação de sistemas de controlo baseadas neste tipo de

modelos.

O capítulo 3 é referente à Norma CEI 61131-3, procedendo-se a uma introdução teórica

sobre a mesma, seguida de uma apresentação de duas das linguagens da Norma (Diagramas

Ladder e Listas de Instruções), onde se descrevem o seu funcionamento e exemplifica-se a

sua programação.

No capítulo 4 são apresentados os algoritmos aplicados na conversão das Redes de Petri

para as linguagens da CEI 61131-3 abordadas, introduzindo-se os conceitos base e métodos

para a conversão. Procede-se ainda à exemplificação da conversão para os dois tipos de lin-

guagens referidos.

O capítulo 5 foca-se no estudo da implementação das Redes de Petri na lógica programá-

vel dos DEIs. Referindo-se a dois DEIs específicos, é apresentado a programação lógica de

cada dispositivo, seguindo-se a implementação de uma Rede de Petri de exemplo e compro-

vando-se o correcto funcionamento, através de simulações e testes. No final do capítulo são

apresentadas as conclusões referentes a esta implementação.

No capítulo 6 é apresentada a solução desenvolvida consistindo numa metodologia de im-

plementação centralizada que permite ultrapassar as limitações presentes na metodologia an-

terior. São apresentados os diversos componentes que constituem o sistema, demonstrando o

seu processo de configuração.

No capítulo 7 é apresentado o ambiente laboratorial de teste construído para a validação

experimental da metodologia proposta, sendo ainda descrito um exemplo de um teste de coor-

denação, apresentada a bateria de testes realizada e conclusões da experimentação.

No final do documento apresenta-se a conclusão do trabalho e referencias para trabalhos

futuros.

Capítulo 2 – Introdução e Redes de Petri

Página | 5

2. Automatismos e Redes de Petri

2.1 Objectivos e Descrição dos Automatismos

Os automatismos abordados neste capítulo são apenas parte dos apresentados no Pro-

jecto-Tipo da EDP [3], mas representam a essência dos automatismos para as linhas MT. O

funcionamento destes automatismos requer informações relativas ao estado da Rede Eléctrica

e da Subestação, denominadas por condições específicas, e actuam na Subestação através de

comandos para manobras de disjuntores.

Deslastre/Reposição por Tensão Zero na Média Tensão

Esta função de automação responde à falta de alimentação da linha.

Consiste em que, quando falta a tensão num barramento de uma Subestação, todas as saí-

das abrangidas são desligadas simultaneamente, sendo repostas em serviço, gradualmente,

após a normalização do fornecimento de energia.

O principal objectivo desta função é evitar o subido aumento de carga resultante da ligação

simultânea de todos os consumos. Um objectivo secundário é a protecção dos consumidores

contra uma tensão, que no seu regresso, pode estar fora dos limites de segurança dos equi-

pamentos, o que é frequente, sendo portanto, necessário que a reposição espere pela regula-

ção da tensão.

Deslastre/Reposição mínimo de Frequência

Esta função de automação, embora actuando localmente nas saídas MT das Subestações

de distribuição, responde a perturbações globais na rede eléctrica de Energia, nomeadamente

ao défice entre a potência eléctrica gerada e a consumida. O deslastre de cargas visa repor o

equilíbrio entre estas potências, tendo como objectivo evitar a desligação dos geradores sín-

cronos e apagões gerais.

No Projecto-Tipo da EDP, esta função comporta três escalões de deslastre. Dois dos esca-

lões actuam nas Subestações de distribuição, enquanto o terceiro escalão, mais abrangente,

actua nas saídas das Subestações de Transporte para as de Distribuição. Portanto, as saídas

das Subestações de Distribuição podem agrupar-se em classes de prioridade de serviço, onde

as de prioridade mínima pertencem ao primeiro escalão, e as de prioridade máxima não são

abrangidas por nenhum escalão.

A reposição gradual das cargas, estando a situação normalizada, também impõe uma se-

quência de prioridades entre as diversas saídas, cujo critério deverá ser o da importância de

fornecimento de energia. Assim, a reposição deve também ser realizada de acordo com a prio-

ridade dos escalões, e dentro de cada um destes, por prioridade de saída.

Capítulo 2 – Automatismos e Redes de Petri

Página | 6

Religação Automática

Esta função de automação responde a defeitos que ocorram em linhas aéreas.

Dados experimentais mostram que cerca de 82% dos defeitos em linhas aéreas são elimi-

náveis por uma desligação instantânea, seguida de uma pausa que permita a desionização do

arco condutor formado pelo escorvamento da descarga atmosférica, e uma religação rápida;

10% são elimináveis por uma primeira desligação que deixe actuar o relé temporizador da pro-

tecção da saída e a que siga uma religação, após um intervalo entre 15 e 45s, o que repre-

senta uma religação lenta; e cerca de 1,5% por uma segunda religação lenta.

Quando uma religação rápida não consegue eliminar o defeito e existem religações lentas

previstas, assume-se a possibilidade de que o defeito não seja de carácter puramente transitó-

rio, mas semi-permanente, ou seja, o defeito não se deve a uma simples descarga atmosférica.

A desligação do disjuntor de linha ocorre neste caso por disparo da protecção e não por inicia-

tiva da função, com o objectivo de “queimar” a origem do defeito, como chuva, gelo, ramos de

árvores, ou permitir a actuação selectiva das protecções a jusante.

2.2 Modos de Funcionamento dos Automatismos

Os automatismos possuem diversos modos de funcionamento, pelo que as funções de au-

tomação são parametrizadas de modo a obter uma solução adequada a cada caso específico.

Tabela 1 - Modos de Funcionamento dos Automatismos

Automatismo Modos de Funcionamento Disponíveis

Religação Automática

[RA]

Inibido

Religação Rápida [RR]

Religação Lenta [RL]

RL + RL

RR + RL

RR + RL + RL

Inibido para defeitos Fase-Fase / RR para defeitos Fase-Terra

RL para defeitos Fase-Fase / RR + RL para defeitos Fase-Terra

RL + RL para defeitos Fase-Fase / RR + RL + RL para defeitos Fase-

Terra

Deslastre/Reposição

Mínimo Frequência

[DF]

Inibido

Deslastre

Deslastre + Reposição

Operação para 1º e 2º escalão de frequência

Deslastre/Reposição

Tensão Zero [DU]

Inibido

Deslastre

Deslastre + Reposição

Capítulo 2 – Introdução e Redes de Petri

Página | 7

Os incidentes que provocam o arranque dos automatismos têm um carácter aleatório, pelo

que pode ocorrer o caso em que múltiplos automatismos iniciem o seu funcionamento simulta-

neamente, o que poderá gerar conflitos de decisão especialmente no que toca a controlo de

equipamentos, que no presente trabalho, são os disjuntores de saída MT.

Para evitar a ocorrência deste tipo de conflitos, em [6] os automatismos foram melhorados e

especificados em conjunto, criando-se intercomunicação entre estes, ou seja, definiu-se o con-

junto dos automatismos como um único sistema, modelado por Redes de Petri Interpretadas.

Respeitando 3 requisitos essenciais:

Cada automatismo deve evoluir o mais livremente possível;

A manobra de fecho dos disjuntores é efectuada quando todos os automatismos in-

dividuais concordarem;

A manobra final de fecho é efectuada quando todos os automatismos terminarem a

sua actuação;

No anexo 1 são ilustradas as Redes de Petri referentes aos 3 automatismos, desenvolvidas

nos anos 80 pelo Prof. Pinto de Sá [6].

2.3 Introdução às Redes de Petri

A teoria das Redes de Petri teve início em 1962, com a Dissertação de Doutoramento de

Carl Adam Petri, desde então tem sido desenvolvida e aplicada a um leque de áreas, como

Software e Hardware de Computadores, Reacções Químicas e Sistemas Sociais [14].

As Redes de Petri são uma ferramenta matemática, para descrição de relações entre condi-

ções lógicas e eventos discretos, proporcionando modelação e análise de comportamento para

sistemas automáticos de controlo. A sua utilização apresenta diversas vantagens:

Permite especificar sistemas de complexidade elevada;

Capacidade de representar explicitamente as dependências e independências causais

em conjuntos de acontecimentos;

Representação explícita do paralelismo no funcionamento de sistemas concorrentes;

Interpretação gráfica que facilita a compreensão dos sistemas;

Representação em diversos níveis de abstracção sem alterar a linguagem de descri-

ção;

Existência de métodos formais de análise aos sistemas modelados.

“Petri Nets can be mathematically validated before they are implemented. This validation, for


Página | 8

which computer aids exist, can be interpreted into desirable guarantees of good operational

behavior for automatic control functions, whose concurrency makes it extremely difficult to

predict possibel malfunctions”[13].

Em [6, 10] é justificada a utilização das Redes de Petri e evidenciadas as vantagens da sua

utilização no SAS, sendo assegurado uma correcta coordenação entre automatismos, impossí-

vel de obter com encravamentos tradicionais.

De seguida, introduzem-se as definições fundamentais sobre as Redes de Petri, assim

como as suas propriedades [6,13,14], seguindo-se pela sua aplicação em automatismos. Esta

apresentação tem como objectivo fornecer o conhecimento necessário para compreender os

conceitos empregues neste trabalho, não representa, de modo algum, uma introdução

completa às Redes de Petri.

2.4 Definições Fundamentais

Definição 1: Uma Rede de Petri é quintupleto, definida do seguinte modo:

(1), Sendo:

(2), Conjunto finito de lugares;

(3), Conjunto finito de transições;

(4), Função de Entrada ou Lugar Precedente;

(5), Função de Saída ou Lugar Sucessor;

(6), Marcação Inicial.

As funções de entrada e saída interligam lugares às transições e transições a lugares, res-

pectivamente, através de arcos dirigidos. Sendo o valor especificado na função, a indicação do

peso do arco, caso este valor seja nulo, interpreta-se como a inexistência de arco.

A cada lugar está associado um número natural de marcas (tokens) representantes da mar-

cação do lugar. O conjunto da marcação de todos os lugares representa a marcação da Rede

de Petri.

Na representação gráfica da Rede de Petri têm-se um grafo bipartido orientado, sendo os

lugares representados por círculos e as transições por barras. Arcos orientados unem os cír-

culos e barras, de acordo com as funções I e O. A representação gráfica da marcação realiza-

se por colocação de pontos ou marcas no interior dos círculos representativos dos lugares.


Página | 9

Figura 1 - Exemplo de representação de uma Rede de Petri

Definição 2: Uma transição t está sensibilizada para marcação (disparável) para a marca-

ção μi se, μi ≥ I (.,t), ou seja, se todos os lugares precedentes da transição possuírem marca-

ção pelo menos igual ao peso dos arcos incidentes (pré-condição de transposição de t).

A transposição de uma transição t, sensibilizada para a marcação μi é realizada por uma

operação indivisível, retirando-se de cada lugar do conjunto L I (L, t) marcas, e colocando-se

em cada lugar do conjunto P O (P,t) marcas.

Definição 3: Uma Rede de Petri interpretada é constituída por uma RdP M = (P,T, I, O, μ0),

um domínio operacional DOP = (D, OP, PR) e em duas funções Ψ e Φ que estabelecem a rela-

ção entre a RdP (domínio de controlo) e domínio operacional, em que:

D é o conjunto de estados do domínio operacional;

- (7), É um conjunto de operadores;

- (8)

- (9), É um conjunto de predicados sobre D;

- (10), Onde V e F representam os valores lógicos “verdade

iro” e “falso”, respectivamente;

- , (11), Associa a cada lugar da RdP M um operador sobre

os estados operacionais;

- (12), Associa a cada transição de M um par ordenado

(predicado, operador).

Uma RdP interpretada representa um sistema cujo estado é um par (d, μ), em que d ϵ D e μ

é a marcação da Rede.

Numa RdP interpretada, a transposição de uma transição t, é realizada quando se verificar a

pré-condição de transposição e quando os predicados associados à mesma transição tiverem o


Página | 10

valor lógico verdadeiro. Esta verificação adicional no mecanismo de disparo é também denomi-

nada de lógica proposicional.

Definição 4: Um conflito entre transições é de escolha livre caso exista apenas um lugar

precedente comum às várias transições; caso contrário obtém-se situações de escolha impos-

ta.

Figura 2 - Escolha Livre e Escolha Imposta

As Redes de Petri possuem diversas propriedades matemáticas que reflectem, de certo

modo, o seu comportamento dinâmico, no anexo 2 encontram-se descritas estas propriedades

e referidos métodos de análise que são utilizados na determinação das mesmas.

2.5 Modelação de Sistemas

A modelação ou especificação de um sistema, através de uma RdP, é realizada atribuindo

condições do sistema aos lugares e eventos às transições. A marcação de um lugar indica que

a condição representada está activa, já a ausência de marcação indica que a condição está

inactiva, sendo o conjunto da marcação de todos os lugares representativo do estado do sis-

tema.

À semelhança de um sistema real, onde as condições e eventos ditam a evolução do sis-

tema, numa Rede de Petri, a evolução baseia-se na transposição de marcações entre os diver-

sos lugares da rede, sendo o mecanismo definido anteriormente o responsável por este facto.

A aplicação de Redes de Petri no SAS tem sido alvo de diversos trabalhos destacando-se

[6] relativamente à aplicação em Subestações de Distribuição. No referido trabalho foram con-

cebidos, automatismos comunicantes, modelados em uma Rede de Petri interpretada, e anali-

sado o seu comportamento conjunto, com auxílio computacional, de forma a comprovar um

correcto funcionamento do sistema. Desta análise verificou-se que a rede é:

Segura, ou seja, para todas as marcações alcançáveis, o número de marcas em ca-

da lugar não excede 1;

Viva, em qualquer marcação alcançável, existe pelo menos uma transição disparável;

Própria, de qualquer marcação alcançável, existe uma sequência de disparos, que

permite obter qualquer marcação alcançável, incluindo a inicial;


Página | 11

Determinísticos, os conflitos que surgem na RdP estão resolvidos;

Determinada, as operações associadas a transições são compatíveis;

Foram também verificados importantes invariantes de lugares e de transições.

No anexo 1 são apresentadas RdP presentes em [6], onde estão especificados os automa-

tismos de Religação Automática, Deslastre por Tensão Zero e Deslastre por Mínimo de Fre-

quência, interligados através de lugares comuns, que regulam o controlo de recursos parti-

lhados, como por exemplo o controlo do disjuntor.

2.6 Implementação de um sistema de controlo

Estando validadas matematicamente as RdP, torna-se necessário a sua implementação

num sistema real. Na figura 3 encontra-se representado a arquitectura do sistema a construir,

distinguindo 2 elementos, o sistema comandado e o sistema de controlo, que por sua vez é

constituído pela camada de controlo e pela camada de dados.

O sistema comandado fornece todas as informações necessárias ao funcionamento do sis-

tema de controlo, e recebe deste, comandos operacionais a serem executados. A camada de

dados é responsável pelo controlo e sinalização da informação existente no sistema, enquanto

a camada de controlo utiliza a referida informação para execução dos programas de automa-

ção.

Figura 3 – Arquitectura abstracta do sistema de automação

De acordo com esta arquitectura, a camada de controlo do sistema que se pretende cons-

truir, é definida pelos automatismos modelados em RdP interpretadas, sendo o domínio opera-

cional desta rede directamente relacionado com a camada de dados, de onde obtêm as infor-

mações para o processamento da lógica proposicional, e onde coloca a suas ordens de opera-

ção, que posteriormente são sinalizadas para o sistema comandado.

Em [7] foi desenvolvida uma arquitectura de software para a implementação de automatis-

mos concorrentes modelados em Redes de Petri, sendo indicado que para satisfazer requisitos

de modularidade, obter respostas em tempo-real, e tradução fiel das Redes de Petri, os ambi-

entes de processamento paralelos seriam os mais adequados.


Página | 12

Na computação paralela existem várias tarefas sequencias a serem executadas em parale-

lismo temporal. O paralelismo pode ser real (multiprocessamento ou processamento distri-

buído) ou virtual (multitarefa). No último caso não existe um paralelismo real do ponto de vista

da CPU, contudo este facto torna-se transparente pois existe poder de processamento sufi-

ciente para partilha temporal do processador.

No referido trabalho, foi utilizado um paralelismo por multitarefa. A partir desse trabalho foi

construído um sistema protótipo, o “ Autómato de Subestações”, que centraliza o processa-

mento dos automatismos num único dispositivo, ligando-se por cablagem aos diversos equi-

pamentos da Subestação. Este protótipo comprovou o correcto funcionamento dos automatis-

mos, com respostas satisfatórias em tempo real.

Em [7] é ainda apresentado um problema na implementação do sistema que garante execu-

ção fiel das Redes de Petri, nomeadamente na existência de conflitos (Definição 4), con-

cluindo-se que a solução passa pela construção de uma tarefa especializada, o “sincronizador”,

que resolva o conflito numa operação indivisível. Nesta tarefa são centralizadas todas as inter-

ligações entre os automatismos concorrentes, tornando o sincronizador, num gestor de concor-

rência.

No entanto, o que se pretende no presente trabalho é uma implementação distribuída com

paralelismo real, onde cada DEI executa as respectivas funções de automação, comunicando

entre si para aquisição de dados, através das mensagens GOOSE.

Em [13] é referenciado um problema relacionado com a implementação fiel das Redes de

Petri em arquitecturas distribuídas, nomeadamente em lugares que interligam os automatis-

mos, surgindo conflitos apenas resolvidos com a lógica proposicional, sendo necessário sin-

cronizar a informação de predicados e marcação de lugares nos dispositivos intervenientes, pa-

ra que não existam decisões assíncronas. No mesmo trabalho é apresentada uma metodologia

para sincronizar a informação somente através de mensagens GOOSE, contudo, essa metodo-

logia requer alterações estruturais das RdP, obrigando a realizar novas análises às mesmas. A

solução para este género de casos, à semelhança do apresentado em [7], passa pela utilização

de um controlador dedicado que funciona como sincronizador, centralizando em si as interliga-

ções entre automatismos.

A execução fiel dos modelos em Redes de Petri tem importância para que se mantenham

válidas as análises realizadas às mesmas, onde foram comprovadas propriedades e funciona-

mentos correctos.

.

Capítulo 3 – CEI 61131-3

Página | 13

3. CEI 61131-3

3.1 Introdução à Norma

Com a evolução da Engenharia de Controlo, o que era comandado por operadores Huma-

nos, nos dias de hoje, é controlado de forma automática, com decisões lógicas [15]. Para esta

nova forma de controlo surgiram computadores dedicados, os Controladores Lógicos Progra-

máveis, usualmente denominados PLCs (Programmable Logic Controllers), que apresentam

diversas vantagens:

Baixo custo para sistemas de controlo complexos;

Flexibilidade que permitem a sua reutilização de um modo rápido e simples;

Capacidade Computacional que permite um controlo mais sofisticado;

Componentes com elevado grau de robustez que podem operar durante anos sem ava-

ria.

Figura 4 - Arquitectura do PLC

Figura 5 - Implementação Interna do PLC

As figuras 4 e 5 representam, respectivamente, a arquitectura e a implementação interna do


Página | 14

PLC.

Para além do controlo de entrada e saída de sinais, os PLCs possuem, temporizadores,

contadores e capacidades de memória [5,15].

Estes controladores lógicos ganharam popularidade na indústria, predominando entre as ou-

tras tecnologias de controlo. Neste sentido, em 1993, surge a CEI 61131 que pretende nor-

malizar o ambiente de desenvolvimento dos PLCs, cuja terceira parte (CEI 61131-3) descreve

as respectivas linguagens de programação [5].

A adopção desta Norma uniformizou a programação, e levou à extinção das linguagens

proprietárias dos fabricantes, separando os serviços de programação, do fabrico do equipa-

mento (figura 6).

As Linguagens descritas na CEI 61131-3 são:

Diagramas Ladder (LD – Ladder Diagram) – Linguagem Gráfica;

Diagramas de Blocos de Funções (FBD – Function Block Diagram) – Linguagem Grá-

fica;

Gráfico de Funções Sequenciais (SFC – Sequential Function Chart) – Linguagem Grá-

fica;

Lista de Instruções (IL – Instruction List) – Linguagem Textual;

Texto Estruturado (ST – Structured Text) – Linguagem Textual;

Este trabalho foca-se em duas linguagens específicas, LD e IL.

O LD porque é a linguagem mundialmente mais utilizada, e sendo uma linguagem gráfica, a

sua aprendizagem é simples e rápida; acrescenta-se ainda o facto de existir uma conversão

Figura 6 - Modelo de Programação com a introdução da CEI 61131


Página | 15

dos Diagramas de Ladder para a lógica baseada em gates AND, OR e NOT, que à frente neste

trabalho se revela importante.

A IL porque é uma linguagem semelhante ao Assembly3, e o facto de ser textual propor-

ciona-lhe flexibilidade (ao contrário das linguagens gráficas), para ser utilizada em qualquer fer-

ramenta de programação por replicação de código. Todas as outras linguagens da CEI 61131-

3 possuem equivalentes para esta linguagem.

Os aspectos teóricos relativos à programação de cada linguagem estão exaustivamente

descritos em [5].

A conversão dos automatismos para linguagens de automação normalizadas permite o uso

de quaisquer dispositivos para executar os programas, partindo do pressuposto que estão em

conformidade com a CEI 61131-3.

3.2 Diagramas Ladder

3.2.1 Lógica de Relés

A linguagem de programação mais utilizada em PLCs, os Diagramas Ladder, foi desenvol-

vida para replicar o funcionamento da lógica de relés, de forma a facilitar a aprendizagem de

programador já formados, e permitir adaptação dos sistemas de automação baseados em

relés, para sistemas de automação digitais [15].

Um relé é um dispositivo que utiliza campo magnético para controlar um interruptor. Quando

se aplica tensão à bobina de entrada (activação de bobina), a corrente resultante cria um cam-

po magnético. Esse campo magnético atrai um interruptor metálico, fechando os contactos do

interruptor e consequentemente energizando-o. Estes contactos têm o nome de normalmente

abertos. Os contactos que estão energizados quando a bobine de entrada não está sob tensão,

têm o nome de normalmente fechados. A figura 7 representa o funcionamento do relé.

Os relés são normalmente utilizados para permitir que uma fonte de alimentação feche o cir-

cuito para outra (normalmente fontes com elevada corrente), mantendo as duas isoladas. Des-

te modo, associam-se diversos tipos de contactos para criar um “caminho lógico energizável”

para actuação de bobines, constituindo os circuitos lógicos de relés.

Os Diagramas de Ladder tentam replicar este funcionamento, utilizando os módulos de en-

trada e as capacidades internas do PLC para controlar sinais dos módulos de saída.

3 Assembly é a linguagem de baixo nível utilizada na programação de computadores, microprocessadores e microcontroladores.


Página | 16

Figura 7 - Esquema de Funcionamento do Relé [15]

Figura 8 - Fluxo de Controlo relativo a Diagramas Ladder

3.2.2 Programação de Diagramas Ladder

Sendo os Diagramas de Ladder uma programação para imitar a lógica de relés, os elemen-

tos básicos desta linguagem coincidem com os elementos de um simples relé, podendo consi-

derar-se as seguintes representações gráficas (Figura 9):

Activação de Bobina – Circunferência, ou dois arcos orientados para o centro;

Contactos normalmente abertos – duas barras verticais;

Contactos normalmente fechados – duas barras verticais com uma linha diagonal entre

elas;

Figura 9 - Elementos Básicos do Ladder


Página | 17

Nos Diagramas Ladder, para além dos elementos já mencionados, ainda existem: detecto-

res de pulso ascendente/descendente; desactivação de bobina; activação permanente de bobi-

na (Set); desactivação permanente de bobina (Reset); Blocos de Temporizadores; Blocos de

Contadores; Blocos de Operações Matemáticas.

A programação de diagramas Ladder é dividida por regras (rungs), que designam cada cir-

cuito lógico. No início de cada regra (esquerda do diagrama), existe uma barra vertical repre-

sentativa da fonte de alimentação que activa os elementos no final do circuito. A figura 10

apresenta, a título de exemplo, um diagrama de Ladder composto por duas regras.

Genericamente, os circuitos são constituídos por elementos de entrada e elementos de saí-

da, correspondentes a variáveis obtidas pelos módulos de entrada/saída ou memória interna do

PLC. Neste caso (Figura 10), os elementos de entrada são os contactos normalmente abertos

das variáveis A, Y, X e os normalmente fechados de B e W; os de saída são a activação de

bobina de C e Z.

Figura 10 - Diagrama Ladder de Exemplo

Em termos de funcionamento, para determinar o estado a que devem ser colocados os ele-

mentos de saída, são avaliados os estados de cada elemento de entrada e a sua respectiva

disposição no circuito. Caso exista uma ligação activa de elementos de entrada, conectando os

elementos de saída à fonte de alimentação, então esses elementos de saída são activados.

Na regra 1, podemos verificar que se A estiver activo e B estiver inactivo, então C será acti-

vado. Já na regra 2, para que Z seja activado, basta estarem activos Y e X, ou W estar inactivo.

3.2.3 Equivalentes em Lógica Elementar

Analisando o diagrama da Figura 10 e o respectivo funcionamento, escrevem-se as seguin-

tes equações lógicas:

(13)

(14)


Página | 18

Através das equações obtidas do diagrama Ladder verifica-se que é possível construir um

circuito equivalente utilizando lógica elementar de portas AND, OR e NOT:

Os contactos normalmente abertos conectados em série são convertidos em portas

AND;

Os contactos normalmente abertos conectados em paralelo são convertidos em portas

OR;

Para converter os contactos normalmente fechados, em normalmente abertos, adiciona-

se uma porta NOT antes da respectiva conexão;

O sinal digital resultante da composição lógica simboliza o estado a que devem ser coloca-

dos os elementos de saída dos diagramas de Ladder.

Tendo em conta o método acima descrito, constroem-se os seguintes circuitos:

Circuito 1:

Circuito 2:

A figura 11 exemplifica a conversão dos diagramas de Ladder para circuitos com portas ló-

gicas elementares:

Figura 11 – Conversão de Ladder para Lógica Elementar

Existem diagramas de Ladder cujos circuitos lógicos são mais complexos que os exemplifi-

cados, contudo não se pretende com este trabalho aprofundar este tipo de conversão, sendo

apenas explorados os aspectos mais importantes que vão de encontro aos objectivos deste

trabalho.

3.3 Lista de Instruções

A lista de instruções é uma linguagem textual, pertencente à Norma CEI 61131 e seme-

lhante à linguagem assembly, cujo funcionamento se baseia na avaliação de uma pilha de ins-

truções.

O funcionamento desta linguagem é sequencial e realizado com instruções de apenas uma


Página | 19

variável, recorrendo a um acumulador para gerir o valor da pilha.

Para gerir o funcionamento do programa são introduzidas etiquetas (labels) nas instruções,

as quais são utilizadas como referências para os saltos de execução.

Na tabela 2 apresenta-se uma listagem de instruções disponíveis nesta linguagem, que se-

rão utilizadas durante este trabalho.

Tabela 2 - Listagem de Instruções

Instrução Descrição

CAL Carrega para execução um programa ou bloco de funções definido pela variá-

vel

LD / LDN Carrega o valor da variável no início do acumulador

AND /

ANDN

Analisa o valor lógico da variável e realiza um AND/ANDN lógico com o valor

do acumulador e guarda o respectivo resultado no acumulador

OR / ORN Analisa o valor lógico da variável e realiza um OR/ORN lógico com o valor do

acumulador e guarda o respectivo resultado no acumulador

S Realiza um SET à variável

R Realiza um RESET à variável

ST Armazena o valor do acumulador na variável

EQ Avalia se o valor da variável é igual ao valor do acumulador e guarda o res-

pectivo resultado no acumulador

JMP A execução de instruções salta para a etiqueta designada na variável

JMPC Avalia se o valor lógico do acumulador é “Verdadeiro”, se afirmativo, a execu-

ção de instruções salta para a etiqueta designada na variável; se negativo a

execução de instruções prossegue para a próxima linha

JMPCN Avalia se o valor lógico do acumulador é “Falso”, se afirmativo, a execução de

instruções salta para a etiqueta designada na variável; se negativo a execu-

ção de instruções prossegue para a próxima linha

Estas instruções incidem na manipulação de valores lógicos e não em operações matemáti-

cas. Apesar de não representar a totalidade das instruções disponíveis, estas instruções per-

mitem demonstrar o funcionamento da linguagem e evidenciar a sua contribuição para este

trabalho.

O exemplo de lista de instruções da figura 12 reflecte o funcionamento dos circuitos lógicos

apresentados na figura 11 da secção anterior.


Página | 20

Figura 12 – Exemplo 1 de Lista de Instruções

Figura 13 - Exemplo 2 de Lista de Instruções

O funcionamento do exemplo 2 (Figura 13) é descrito do seguinte modo:

Carregamento do valor de V1 no acumulador, realização de AND lógico com V2 e ANDN

lógico com V3. Se o valor presente no acumulador for “Falso”, a execução salta para a etiqueta

L_2; se o valor for “Verdadeiro”, as variáveis V1 e V2 são colocadas a “Falso” (Reset) e V3 é

colocada a “Verdadeiro” (Set) e a execução de instruções prossegue para a próxima linha.

Na etiqueta L_2, é carregado o valor de V4 para o acumulador, caso seja “Verdadeiro” a

execução de instruções salta para L_1, se o valor for “Falso”, é carregado no acumulador o va-

lor 2 e é comparado com o valor na variável N1, o valor lógico resultante da comparação é ar-

mazenado em V5.

Capítulo 4 – Conversão de Redes de Petri

Página | 21

4. Conversão de Redes de Petri

4.1 Motivação para a Conversão

Os automatismos que se pretendem implementar estão modelados em Redes de Petri In-

terpretadas. Como abordado anteriormente, esta linguagem apresenta diversas vantagens em

termos de desenvolvimento de sistemas complexos, devido às capacidades e métodos formais

de análise às próprias redes, com os quais se podem verificar propriedades importantes e mo-

dos de funcionamento. Contudo, as Redes de Petri não são uma das linguagens normalizadas

de automação, pelo que os sistemas de controlo, actualmente existentes, não são programá-

veis segundo as suas especificações.

Em [8] e [9] são apresentadas metodologias comprovadas de conversão fiel das Redes de

Petri para linguagens da CEI 61131-3. Com base nestes métodos é possível converter os e im-

plementar os automatismos segundo uma linguagem normalizada, programável em autómatos,

assegurando que são executados fielmente de acordo com os seus modelos em Redes de Pe-

tri.

Um outro aspecto importante em ter os automatismos descritos em linguagens de automa-

ção normalizadas está no facto, de se poder garantir a operabilidade com autómatos de qual-

quer tipo de fabricantes, não estando dependente de linguagens e protocolos proprietários, o

que aliás vai de encontro aos objectivos que levaram à criação da norma CEI 61131.

A capacidade de utilizar uma mesma programação independentemente do hardware propor-

ciona flexibilidade e facilita a implementação, manutenção e aperfeiçoamento do sistema de

automação.

A conversão foca duas linguagens: Diagramas de Ladder e Listas de Instruções.

Os métodos de conversão abordados neste trabalho referem-se a Redes de Petri seguras,

ou seja, redes que verifiquem a propriedade de Segurança que garante que um lugar não pos-

sui mais que uma marca (token). Deste modo é possível utilizar variáveis booleanas para re-

presentar a marcação de lugares.

4.2 Conversão para Diagramas Ladder

Teoria

A metodologia de conversão exemplificada nesta secção do trabalho foi apresentada em [8],

contudo nesse trabalho o tema é abordado de uma forma muito genérica, sendo necessário al-

terar algumas especificações para a implementação do presente sistema.

O funcionamento das Redes de Petri baseia-se no disparo de transições, alterando a mar-

cação da rede e consequentemente o estado do sistema. Tendo em conta o tipo de redes que


Página | 22

se pretende converter, o mecanismo de disparo de uma transição tem de verificar o seguinte:

Lugares de entrada marcados;

Condição associada à transição com valor lógico “Verdadeiro”;

Estando todas as condições verificadas, procede-se ao disparo, marcando os lugares de sa-

ída e desmarcando os de entrada.

De acordo com este mecanismo de disparo, do ponto de vista do lugar, descrevem-se dois

tipos de condições: Condição de Marcação (Latch) – L; Condição de Desmarcação (Unlatch) –

U;

Definição 5: A Condição de Marcação é definida por um “ou” lógico de subcondições as-

sociadas a todas as transições que possuam como lugar de saída o lugar em questão. Nestas

subcondições, realiza-se um “e” lógico entre todos os lugares de entrada e proposição lógica

referentes à respectiva transição.

Definição 6: A Condição de Desmarcação 1 é definida por um “ou” lógico de subcondi-

ções associadas a todas as transições que possuam como lugar de entrada o lugar em ques-

tão. Nestas subcondições, realiza-se um “e” lógico entre a proposição lógica da transição e os

restantes lugares de entrada.

A condição de desmarcação em cima descrita, defina de modo fiel ao mecanismo de dis-

paro, apresenta falhas de funcionamento, dependentes do tipo de varrimento que o controlador

lógico executa durante o processamento dos Diagramas, portanto redefine-se esta condição

para uma alternativa que se possa utilizar para casos genéricos, independentemente do tipo de

varrimento do controlador lógico.

Definição 7: A Condição de Desmarcação 2 é definida por um “ou” lógico de subcondi-

ções associadas a todas as transições que possuam como lugar de entrada o lugar em ques-

tão. Nestas subcondições, realiza-se um “e” lógico entre a proposição lógica da transição e um

lugar de saída dessa transição (aleatório).

Esta definição não vai de encontro ao definido pelo mecanismo de disparo, no entanto, para

o tipo de redes que se pretende converter, representa uma alternativa válida. Caso seja possí-

vel controlar a ordem de processamento dos Diagramas é possível utilizar a definição original.

Mais informações sobre este aspecto podem ser consultadas no Anexo 3.

Com estas definições é possível construir um circuito lógico que represente um lugar da

Rede de Petri e o respectivo funcionamento:

Como se pode verificar no circuito da Figura 14, o lugar Pi é activado quando a sua condi-

ção de marcação (L) estiver com valor lógico “Verdadeiro”, e mantém-se activo enquanto a sua

condição de desmarcação (U) estiver com valor lógico “Falso”.


Página | 23

Figura 14 - Circuito do Lugar Pi de uma Rede de Petri

Para completar a implementação dos automatismos nos Diagramas Ladder são criadas re-

gras para executar as condições lógicas das transições. Caso estas condições não estejam

descritas nas Redes de Petri, assume-se que o seu valor lógico é permanentemente “Verda-

deiro”, e portanto os seus contactos normalmente abertos são substituídos por shunts e os con-

tactos normalmente fechados são removidos.

Para lugares que possuam acções associadas, como por exemplo, inicialização de tempori-

zadores, são criadas regras (rungs) específicas.

As impurezas, usualmente denominados, lugares de teste, representam casos excepcionais

na conversão. Como estes lugares possuem arcos bidireccionais para as transições, o disparo

das mesmas não afecta a sua marcação, e portanto apenas devem ser avaliados para Condi-

ções de Marcação.

No anexo 4 é apresentado um exemplo de conversão mais complexo, contemplando diver-

sos casos especiais na conversão.

Programação e Exemplos

De acordo com a teoria apresentada na secção anterior torna-se possível programar nos

controladores lógicos, Redes de Petri Interpretadas.

A título de exemplo de conversão, considera-se a Rede de Petri representada pela figura

15.

Esta Rede de Petri é uma rede com 2 lugares e 2 transições, tornando o exemplo de con-

versão simples e pouco extenso. A conversão de uma Rede de Petri mais complexa, contem-

plando todos os aspectos da conversão é apresentada no Anexo 3. Para este exemplo não se-

rão representadas as condições lógicas das transições e acções dos lugares.

Iniciando a conversão da Rede de Petri para Diagrama de Ladder, escrevem-se as Condi-

ções de Marcação seguidas pelas Condições de Desmarcação para todos os Lugares da Re-

de:

Lugar P1:

Lugar P2:


Página | 24

Figura 15 - Rede de Petri para exemplo de Conversão

Visto que nos Diagramas de Ladder as Condições de Desmarcação são negadas, reava-

liam-se as respectivas equações:

(15)

(16)

Deste modo implementam-se as Condições de Desmarcação recorrendo ao rearranjo dos

contactos, poupando no número de regras a utilizar no diagrama. Estando descritas todas as

condições obtém-se o seguinte Diagrama de Ladder (Figura 16), representativo da Rede de

Petri da figura 15:

Figura 16 - Diagrama Ladder do Exemplo de Conversão

Equivalentes em Portas Lógicas

De acordo com o capítulo referente à Norma CEI 61131-3, a linguagem de Diagramas de

Ladder possui equivalente em circuitos baseados em portas lógicas AND, OR e NOT, portanto,

estando as Redes de Petri convertidas para Diagramas Ladder, é possível obter o circuito


Página | 25

equivalente em portas lógicas.

Figura 17 - Circuito Equivalente

Tomando como exemplo o diagrama da figura 16, o circuito equivalente será o da fig. 17.

Nesta é representado o circuito equivalente, contudo não tem em conta a avaliação das condi-

ções lógicas das transições e acções de lugares.

Genericamente a conversão é realizada do modo apresentado na fig. 18, acrescentando-se

aos Diagramas Ladder, as regras para verificação das condições lógicas das transições e ac-

ções dos lugares.

Figura 18 - Conversão Genérica de Redes de Petri para Diagramas Ladder


Página | 26

4.3 Conversão para Lista de Instruções

Teoria

A base para metodologia de conversão exemplificada nesta secção do trabalho foi apre-

sentada em [9], sendo necessário realizar algumas alterações específicas para adaptar a me-

todologia para o sistema que se pretende implementar.

A conversão das Redes de Petri para Listas de Instruções apresenta diferenças significati-

vas face à conversão para Diagramas de Ladder. Sendo que na Lista de Instruções, as instru-

ções são realizadas sequencialmente, a ordem pela qual são executadas tem especial impor-

tância.

A conversão das Redes de Petri para esta linguagem baseia-se em 2 tipos de blocos de ins-

truções, blocos de transições e blocos de lugares. A cada bloco é atribuído uma etiqueta (La-

bel) e constrói-se o programa tal como indicado pela figura 19:

Figura 19 - Arquitectura do Programa em Listas de Instruções

Sendo que existem n transições, a etiqueta do primeiro bloco de lugar terá a etiqueta n+1.

As inicializações são realizadas no início do programa e referem-se a temporizadores e con-

tadores.

O bloco de transição é composto por 3 sub-blocos:

1. Validade de Lugares: Verifica se todos os lugares de entrada da transição estão mar-

cados/activos e se os lugares de saída estão não marcados/inactivos, realizando um

“e” lógico entre os lugares de entrada e os lugares de saída negados. Após esta verifi-

cação é adicionado um salto condicional negado para a etiqueta do próximo bloco, des-

te modo, se as condições de disparo por marcação de lugares não se verificarem a

execução salta para o próximo bloco;


Página | 27

2. Validade da proposição lógica: Verifica o valor lógico da condição da transição, reali-

zando as respectivas operações lógicas com os diversos intervenientes da mesma.

Após esta verificação é adicionado um salto condicional negado para a etiqueta do

próximo bloco, deste modo, se a condição não se verificar a execução salta para o pró-

ximo bloco;

3. Disparo da Transição: Estando todas as condições de disparo verificadas, os lugares

de entrada são desmarcados e os lugares de saída são marcados, realizando Resets e

Sets, respectivamente, às variáveis correspondentes aos lugares. Após a marca-

ção/desmarcação de lugares, adiciona-se um salto para o primeiro bloco de lugares;

Figura 20 - Bloco de Transição

No sub-bloco de Validade de Lugares, a verificação dos lugares de saída é realizada como

uma salvaguarda para garantir as propriedades de conservação e de segurança das Redes de

Petri. Assim, se um lugar de saída da transição estiver activo, o disparo é bloqueado para evi-

tar o desmarque de lugares e marcação de lugares já activos. Se as redes forem previamente

analisadas para evitar este tipo de situações, como é o caso das redes que descrevem os au-

tomatismos, a verificação dos lugares de saída pode ser excluída do código.

O sub-bloco de Validação da Proposição Lógica é criado apenas para transições que pos-

suam condições lógicas associadas.

No sub-bloco de Disparo da Transição, o salto para o primeiro bloco de lugar, é realizado

para garantir que as acções dos lugares são executadas sempre que ocorra um disparo de

transição. Mais detalhes sobre este aspecto podem ser encontrados no Anexo 3.

O bloco dos lugares é composto por 2 sub-blocos:

1. Verificação de Marcação: Verifica se o lugar está marcado através do valor lógico da

respectiva variável. Após esta verificação é adicionado um salto condicional negado

para a etiqueta do próximo bloco, deste modo, se o lugar não estiver marcado, a exe-

cução salta para o próximo bloco;

2. Acções do Lugar: Estando o lugar marcado, são realizadas as acções corresponden-

tes;


Página | 28

Figura 21 - Bloco de Lugar

Os blocos de lugar são apenas criados para lugares que possuam acções associadas.

Programação e Exemplos

De acordo com a teoria apresentada na secção anterior torna-se possível converter as Re-

des de Petri para Listas de Instruções, e implementa-las em Controladores Lógicos.

Para exemplificação da conversão, considera-se a mesma Rede de Petri utilizada nos

exemplos anteriores (Figura 22), mas com condições lógicas associadas às transições e ac-

ções associadas aos lugares:

Figura 22 - Rede de Petri para exemplo de conversão para Listas de Instruções

Para realizar a conversão constroem-se as seguintes tabelas relativas a cada bloco:

Tabela 3 - Blocos de Instruções referentes à Rede de Petri

Bloco 1 Bloco de Transição – T1 Etiqueta L_1

Lugares de Entrada P1

Lugares de Saída P2

Proposição Lógica A.B


Página | 29

Bloco 2 Bloco de Transição – T2 Etiqueta L_2

Lugares de Entrada P2

Lugares de Saída P1

Proposição Lógica C.B

Bloco 3 Bloco de Lugar – P1 Etiqueta L_3

Acções Reset C

Set A

Bloco 4 Bloco de Lugar – P2 Etiqueta L_4

Acções Reset A

Set C

Através dos dados da tabela 3, anteriormente descrita, constrói-se o código de acordo com

a ordem especificada na figura 19 e as regras teóricas apresentadas:

Figura 23 - Código em Listas de Instruções convertido da Rede de Petri da Figura 22

No Anexo 4 é apresentado um exemplo de conversão mais complexo. Uma vantagem na

utilização de Listas de Instruções é a disponibilidade de ferramentas que permitem a conversão

automática das Redes de Petri para esta linguagem da CEI 61131-3. Um exemplo destas fer-

ramentas é o SIPN Editor que converte automaticamente as Redes de Petri interpretadas para

Listas de Instruções.

Capítulo 5 – Implementação de Redes de Petri em DEIs

Página | 31

5. Implementação de Redes de Petri em DEIs

5.1 Introdução

O início deste trabalho foi motivado pela tentativa de utilização da capacidade lógica pro-

gramável dos DEIs para implementação de automatismos nas Subestações de Distribuição de

Energia. Este capítulo apresenta a metodologia para implementação das Redes de Petri nos

DEIs.

Como abordado anteriormente, os automatismos estão descritos em Redes de Petri Inter-

pretadas, as quais foram convertidas, formalmente, para linguagens de automação normaliza-

das, descritas na norma CEI 61131-3. Para implementar o código convertido é ainda necessá-

rio realizar uma adaptação para as linguagens de programação dos diferentes DEIs (Alegada-

mente estas linguagens baseiam-se na Norma CEI 61131-3).

Figura 24 - Modelo de Implementação Indirecto

Portanto, neste capítulo do trabalho são estudadas as formas de programação lógica dos

DEIs [16,17], de modo a se poder implementar indirectamente, Redes de Petri nos mesmos e

ainda averiguada a capacidade desta lógica programável de suportar a totalidade do código

necessário para execução da automação.

O trabalho foca-se em dois DEIs de diferentes fabricantes referentes a saídas de linha MT,

o TPU-S420 da EFACEC e o SIPROTEC 7SJ645 da SIEMENS, visto serem os dois tipos de

DEIs presentes no Laboratório de Protecções do Instituto Superior Técnico – Campus da Ala-

meda, local onde foi realizada a componente experimental deste trabalho. Contudo, foi reali-

zada uma pesquisa sobre a lógica programável de DEIs de outros fabricantes, a qual pode ser

consultada no Anexo 5. As conclusões podem ser extrapoladas para as outras Gamas de DEIs

de cada fabricante, visto que se baseiam na mesma linguagem de programação.


Página | 32

5.2 TPU-S420 – EFACEC

5.2.1 Lógica Programável

O software que a EFACEC disponibiliza para programar o TPU-S420 é o WinProt4 [16].

Figura 25 - Menu Principal WinProt4

Figura 26 - Menu Principal do WinLogic

Este software possui diversos módulos, contudo, este trabalho foca-se no WinLogic, o mó-

dulo que permite programar a lógica do DEI, a qual se baseia em portas AND, OR, NOT, Tem-

porizadores e Contadores.


Página | 33

A figura 26 apresenta o menu principal do WinLogic, onde se destacam 3 secções princi-

pais:

Quadro verde: Diversos módulos programáveis dentro do DEI;

Quadro azul: Ferramentas disponíveis para programação lógica;

Quadro vermelho: Janela principal de edição das Gates Lógicas.

Dentro da janela principal (Quadro vermelho) é possível navegar pelo módulo, observar as

Gates disponíveis para programação, e realizar conexões entre estas, utilizando a ferramenta

conector.

Associado a cada Gate existem duas opções primárias, Edição de Propriedades, e Coman-

dos Lógicos, tal como se verifica na figura 27.

Figura 28 - Edição de Propriedades de uma Gate

Figura 27 - Funções associadas as Gates


Página | 34

Pode observar-se na figura 29, as funções associadas aos comandos lógicos das Gates:

Módulo & Variável: Escolha da Gate que se pretende comandar logicamente;

Enviar Comando: Enviar comando para a Gate seleccionada, para alterar o seu estado

para 1 ou 0, como impulso, ou como sinalização;

Obter Estado: Determina qual o valor lógico presente na Gate seleccionada.

Na figura 28 está representada a janela da edição de propriedades de uma Gate, nesta po-

demos destacar:

Tipo Porta: Escolha, se a Gate em questão, se comporta como uma porta OR, ou como

porta AND;

Estado Inicial: Directamente associados ao tipo de porta da Gate, os estados iniciais

estão relacionados com o estado lógico das entradas. Caso um estado inicial esteja acti-

vo, o DEI força o estado lógico da entrada sempre a 1, independentemente de qualquer

conexão ligada nessa entrada. Caso um estado inicial esteja inactivo, o DEI assume o

valor lógico da entrada como 0, até que uma conexão ligada a essa entrada o coloque a

1.

Portanto, é simples verificar que para uma Gate OR, todos os estados iniciais devam estar

inactivos, e que para uma Gate AND, todos os estados iniciais devem estar activos, com

excepção das entradas que possuam conexões a outras Gates.

Ligações Externas: Permite conectar a Gate a uma outra, presente num módulo dife-

rente, são necessários os parâmetros do módulo, n.º da Gate, e qual a entrada a que se

pretende conectar.

Caso se pretender ligar a Gate a uma outra no mesmo módulo, não se poderá utilizar esta

função, será necessário utilizar a ferramenta “conector” na janela principal do WinLogic.

Figura 29 - Comandos Lógicos


Página | 35

Saídas Negadas: Como o nome indica, permite negar uma saída da Gate;

Na figura 30 está representado um exemplo de configuração de uma Gate AND com cone-

xões nas duas primeiras entradas. A primeira saída desta Gate está negada e conecta-se a ou-

tra Gate presente no mesmo módulo. A segunda saída conecta-se a uma Gate presente num

módulo diferente.

A programação lógica pode então ser realizada construindo tabelas de configuração para

cada Gate de acordo com os seus diversos parâmetros. Como fonte de informação para o fun-

cionamento lógico são utilizados as Gates dos vários módulos do DEI, aplicando-se o cálculo

auxiliar nos dois módulos disponibilizados para o efeito, Lógica Auxiliar 1 e Lógica Auxiliar 2.

5.2.2 Programação de Redes de Petri Interpretadas

Como abordado no capítulo referente à Norma CEI 61131-3, os Diagramas Ladder possuem

um equivalente para circuitos baseados em portas lógicas AND,OR e NOT. Sendo que a lógica

programável deste DEI se baseia na utilização do mesmo tipo de portas lógicas, é possível

converter Redes de Petri para diagramas de Ladder, determinar o circuito equivalente em por-

tas lógicas e implementa-lo no DEI, de acordo com a metodologia apresentada anteriormente

relativa à lógica programável do TPU-S420.

A título de exemplo considera-se a seguinte Rede de Petri, já utilizada em exemplos anterio-

res, e a respectiva conversão para diagrama de Ladder, exceptuando as acções de lugares e

condições lógicas de transições:

Figura 30 - Exemplo de Gate AND


Página | 36

Figura 31 - Rede de Petri de Exemplo e Conversão para Diagrama de Ladder

O respectivo circuito lógico será:

Figura 32 - Circuito Lógico Equivalente

Para programar o circuito equivalente obtido, constroem-se as seguintes tabelas de configu-

ração para as Gates do DEI:

Tabela 4 - Programação de Exemplo da Rede de Petri

Lugar Gate Tipo Saída Nome Gate Entrada Negada

P1 Log.A. 1 Gate 33 OR

1 Aux 2 Log.A. 2 Gate 2 1 Não


3 Aux 4 Log.A. 2 Gate 4 2 Sim


P2 Log.A. 1 Gate 34 OR






Página | 37

Transição Gate Tipo Saída Nome Gate Entrada Negada

T1 Log.A. 1 Gate 35 OR 1 Aux 3 Log.A. 2 Gate 3 2 Não


T2 Log.A. 1 Gate 36 OR 1 Aux 1 Log.A. 2 Gate 1 2 Não


Portas

Auxiliares

Gate Tipo Saída Nome Gate Entrada Negada

Aux 1 Log.A. 2 Gate 1 AND 1 P1 Log.A. 1 Gate 33 1 Não






Marcação Inicial (Ligação por Conector)

Nome Gate Tipo Saída Nome Gate Entrada Negada

Pulso

Inicial

Log.A. 1 Gate 49 OR 1 P1 Log.A. 1 Gate 33 4 Não

5.2.3 Simulações e Resultados

Para realizar a simulação do funcionamento das Gates utiliza-se a própria ferramenta de

simulação do WinLogic. Tendo em conta os números das Gates utilizadas no exemplo, pode-

mos escrever o seguinte script de teste:

Tabela 5 - Script de Teste

Gate Modo Tempo Objectivo

Pulso para

Marcação Inicial

Log.A. 1 Gate 49 0->1 0 Gate 33 -> 1 Marcação de P1

Log.A. 1 Gate 49 1->0 10

Pulso para

Transição T1

Log.A. 1 Gate 35 0->1 10 Gate 33 -> 0 Desmarcação P1

Gate 34 -> 1 Marcação P2 Log.A. 1 Gate 35 1->0 10

Pulso para

Transição T2

Log.A. 1 Gate 36 0->1 10 Gate 34 -> 0 Desmarcação P2

Gate 33 -> 1 Marcação P1 Log.A. 1 Gate 36 1->0 10

Com esta simulação pretende-se:


Página | 38

Colocar a marcação inicial na Rede, activando a Gate 33 (P1);

Disparar a Transição 1, activando a Gate 34 (P2) e desactivando a Gate 33 (P1);

Disparar a Transição 2, activando a Gate 33 (P1) e desactivando a Gate 34 (P2);

Verificar que estando P1 marcado (Gate 33), T2 (Gate 36) estar activa não altera a marcação da Rede de Petri;

Verificar que estando P2 marcado (Gate 34), T1 (Gate 35) estar activa não altera a marcação da Rede de Petri;

Os resultados da simulação estão representados na Figura 33 e são verificáveis na tabela 6.

Figura 33 - Resultados da Simulação

Tabela 6 - Resultados da Simulação

Tempo Módulo Variável Lógica Estado da Transição

0 Lógica Auxiliar 1 Gate 49 Lógica Auxiliar 1 0->1









Página | 39


















Retirando a informação relativa às Gates do módulo de Lógica Auxiliar 2 nos resultados na

simulação obtemos o seguinte:

Tabela 7 - Resultados da Simulação Filtrados

Tempo Módulo Variável Lógica Estado da Transição Significado

0 Lógica Auxiliar 1 Gate 49 Lógica Auxiliar 1 0->1 Activar Marca-

ção Inicial

0 Lógica Auxiliar 1 Gate 33 Lógica Auxiliar 1 0->1 Marcação de

P1


Desactivar

Marcação Ini-

cial

20 Lógica Auxiliar 1 Gate 35 Lógica Auxiliar 1 0->1 T1 Activa

20 Lógica Auxiliar 1 Gate 34 Lógica Auxiliar 1 0->1 Marcação P2

20 Lógica Auxiliar 1 Gate 33 Lógica Auxiliar 1 1->0 Desmarcação

P1

30 Lógica Auxiliar 1 Gate 35 Lógica Auxiliar 1 1->0 T1 Inactiva

40 Lógica Auxiliar 1 Gate 36 Lógica Auxiliar 1 0->1 T2 Activa

40 Lógica Auxiliar 1 Gate 33 Lógica Auxiliar 1 0->1 Marcação P1

40 Lógica Auxiliar 1 Gate 34 Lógica Auxiliar 1 1->0 Desmarcação


Página | 40

P2

50 Lógica Auxiliar 1 Gate 36 Lógica Auxiliar 1 1->0 T2 Inactiva

Através da Tabela 7 é possível verificar que os resultados obtidos são os previstos teorica-

mente no script de teste, comprovando que a programação lógica realizada implementa a Rede

de Petri proposta.

Apesar de se comprovar a implementação de Redes de Petri na lógica programável do DEI,

existem diversos aspectos relacionados com as capacidades do TPU-S420 que impedem a im-

plementação da totalidade da lógica referente aos automatismos:

Gates Lógicas

O número de Gates é fixo. Não é possível acrescentar, nem reduzir o número de Gates

presentes nos módulos;

Apenas existem dois módulos para programação de Lógica Auxiliar;

Cada Gate possui apenas oito entradas e oito saídas;

Existem apenas 104 Gates Auxiliares para realizar a programação.

Programação

A ferramenta “conector” cria um “emaranhado” de ligações entre as Gates do mesmo

módulo que torna incompreensível os circuitos por inspecção visual dos módulos. Tor-

na-se “quase obrigatório” o uso de módulos diferentes para que se possa fazer a pro-

gramação por referência através das Propriedades das Gates.

Limite de Complexidade associado à Rede de Petri

Sendo que existem 104 Gates disponíveis para programação, se a cada lugar de uma

Rede de Petri corresponder uma Gate, tendo o mínimo de Gates Auxiliares (3), e sem

utilizar Gates que calculam as condições lógicas das transições, é possível implemen-

tar redes com apenas 26 lugares.


Página | 41

5.3 SIPROTEC 7SJ645 - SIEMENS

5.3.1 Lógica Programável

O software disponibilizado pela Siemens para configuração dos DEIs é o DIGSI 4 [12]. Este

software é constituído por diversos módulos, sendo o responsável pela programação lógica,

uma versão compacta do SIMATIC STEP 7, adaptada para corresponder às especificações

dos DEIs deste fabricante.

O SIMATIC STEP 7 é uma ferramenta da SIEMENS para desenvolvimento de projectos de

automação e implementação em PLCs deste fabricante. Para além de realizar a programação

sob diversas linguagens, incluindo as linguagens da Norma CEI 61131-3, este software é res-

ponsável pela interface de comunicações entre os componentes do sistema.

Contudo, a versão compacta do SIMATIC STEP 7, presente no DIGSI 4, apenas permite

programação segundo uma linguagem proprietária da Siemens, o CFC (Continuous Function

Chart). Esta linguagem baseia-se numa interface gráfica com a qual se constroem os progra-

mas utilizando blocos pré-configurados.

Este trabalho foca-se em dois módulos deste software:

CFC: Editor de CFC, permite inserir os blocos em diagramas, modificar parâmetros dos

blocos, realizar interconexões entre estes e ainda gerir o processamento dos CFCs no

DEI;

Matriz de Configuração: Realiza a gestão de variáveis e as suas interconexões entre

os diversos módulos do sistema.

Figura 34 - Menu de Definições relativas ao Dispositivo

Na figura 34, está representado o Menu de Definições relativas ao DEI, é neste módulo que


Página | 42

se encontram as ferramentas de CFC e Matriz de Configuração, entre outras.

CFC – Continuous Function Chart

A janela principal do editor CFC encontra-se representada na figura 35, nesta pode-se des-

tacar:

Quadro Vermelho: Listagem de blocos disponíveis para realizar o desenvolvimento do

programa e ferramentas, como a criação de um novo diagrama, ou adição de texto ao

actual.

Quadro Azul: Folha do diagrama onde se dispõem os blocos e se constroem as interco-

nexões;

Figura 35 - Editor CFC

A listagem dos blocos disponíveis para realizar a programação é apresentada em detalhe

na figura 36:

Verifica-se que estão disponíveis para programação, um leque de portas lógicas, onde se

incluem portas AND, OR e NOT. Portanto, apesar do DEI não ser programável sob as lingua-

gens da CEI 61131-3, é possível utilizar os circuitos lógicos equivalentes aos Diagramas de

Ladder, convertidos das Redes de Petri, e implementá-los no DEI.

Para iniciar a programação é criado um novo diagrama, sendo disponibilizadas 6 folhas para

a construção do circuito. A programação lógica é realizada por interface gráfica, baseada no

método “Arrastar e Largar” (Drag-and-Drop), seleccionam-se os blocos e arrastam-se para a fo-

lha, tal como exemplificado na figura 37:


Página | 43

Figura 36 – Listagem de Blocos DIGSI 4

Figura 37 - Inserir Blocos no Diagrama CFC

Para interligar os blocos, selecciona-se a saída que se pretende conectar, e a respectiva en-

trada no bloco onde se pretende realizar a interligação.

Conexão para outros sistemas do DEI que não o CFC, utiliza-se a opção de Interconexão

para Endereço (Figura 38), disponibilizada nas entradas e saídas dos blocos. Desta opção

surge uma listagem com as variáveis externas ao CFC disponíveis.

A ordem pela qual se realiza o processamento dos blocos é configurável, permitindo a opti-

mização no processo de cálculo e redução do número de blocos necessários (Figura 39).


Página | 44

Figura 38 - Conexão a variáveis externas ao CFC

Figura 39 - Controlo da ordem de processamento

Matriz de Configuração

A matriz de configuração é a ferramenta que gere e interliga variáveis entre os componentes

do DEI.

Figura 40 - Matriz de Configuração


Página | 45

Na figura 40 está representada a janela principal da Matriz de Configuração, onde se des-

taca:

Quadro Vermelho: Grupos e Variáveis, secção da Matriz onde são apresentados os diver-

sos grupos, dentro dos quais se encontram as respectivas variáveis e as suas descrições e

tipo;

Quadro Azul: Fontes e Destinos, secção da Matriz onde estão mapeados diversas fontes e

destinos para configuração das variáveis.

A Matriz não se restringe aos grupos programados de origem, ou seja, é permitida a criação

de novos grupos e novas variáveis, que neste trabalho tem interesse para a interligação de va-

riáveis aos circuitos lógicos programados no CFC.

Figura 41 - Criar nova informação

Para a configuração de Fontes e Destinos, a Matriz de Configuração permite a utilização de

vários componentes do DEI:

Entradas/Saídas Binárias e Analógicas;

Leds;

Teclas de Função;

CFC;

5.3.2 Programação de Redes de Petri Interpretadas

Seguindo as mesmas razões apresentadas para a programação de Redes de Petri Inter-

pretadas no TPU-S420, é possível realizar o mesmo tipo de programação no SIPROTEC.

Sendo que neste DEI é possível gerir o processamento dos CFCs e das suas variáveis, a

conversão das Redes de Petri é realizada utilizando as condições definidas em 6 e 7.

Tomando o exemplo comum a todo o trabalho considera-se o seguinte:


Página | 46

Figura 42 - Rede de Petri de Exemplo e Conversão para Ladder Reduzido

O respectivo circuito lógico será:

Figura 43 - Circuito Lógico Equivalente

De acordo com a lógica programável do DEI e métodos de programação aqui referidos, o

circuito é construído no diagrama através da colocação de blocos e respectiva interconexão, tal

como representado na figura seguinte:

É de notar que as duas portas lógicas OR, representativas da marcação de lugares, apre-

sentam um número diferente de entradas, três entradas na primeira porta OR (Lugar P1) e du-

as entradas na segunda porta OR (Lugar P2). A terceira entrada, referente ao lugar P1, é utili-

zada para realizar a marcação inicial da rede.


Página | 47

Figura 44 - Circuito Lógico programado no SIPROTEC

5.3.3 Simulações e Resultados

Devido à falta de um módulo de simulação no DIGSI 4, o teste do circuito e respectivos re-

sultados da implementação sugerida, são apresentados sob a forma tabular.

Para realizar a simulação, utiliza-se a Matriz de Configuração, mapeando as saídas das por-

tas OR, representativas da marcação dos lugares, para os LEDs 1 e 2, respectivamente, dis-

poníveis no DEI. As condições lógicas das transições são associadas às teclas de função, F1 e

F2. A marcação inicial é realizada com a tecla de função F3.

Tabela 8 - Resultados da Simulação

Número Acção

(Teclas de

Função)

Objectivo Resultado

(Estado dos

LEDs)

Interpretação

1 - Inicialização Led 1 – OFF

Led 2 – OFF

Inicialização do DEI

2 F1 Verificar inactividade da

Rede

Led 1 – OFF

Led 2 – OFF

Não há alteração da

marcação da Rede

3 F2 Verificar inactividade da

Rede

Led 1 – OFF

Led 2 – OFF


marcação da Rede

4 F3 Realizar marcação inicial

da rede

Led 1 – ON

Led 2 – OFF

Marcação do Lugar P1


Página | 48

5 F2 Verificar manutenção da

marcação (T2 não dispará-

vel)

Led 1 – ON

Led 2 – OFF


marcação da Rede

6 F1 Disparo de T1 Led 1 – OFF

Led 2 – ON

Disparo de T1 reali-

zado com sucesso

7 F1 Verificar manutenção da

marcação (T1 não dispará-

vel)

Led 1 – OFF

Led 2 – ON


marcação da Rede

8 F2 Disparo de T2 Led 1 – ON

Led 2 – OFF

Disparo de T2 reali-

zado com sucesso

De acordo com os testes realizados, comprova-se que a programação efectuada imple-

menta a Rede de Petri proposta. Contudo, o limite de memória disponível é insuficiente para

programar a totalidade dos automatismos, ou seja, o tamanho das folhas de programação é in-

suficiente para colocar toda a lógica necessária.

5.4 Comparação de Resultados e Conclusões

Nas tabelas 7 e 8 está representado o funcionamento dos DEIs na execução de uma mes-

ma Rede de Petri. Verifica-se o mesmo comportamento nos dois dispositivos, comprovando a

metodologia proposta. Contudo, apesar de se poder programar e executar correctamente Re-

des de Petri, existem limitações que impossibilitam a implementação total do código do auto-

matismo, sendo a principal razão a baixa capacidade de memória disponibilizada pelos DEIs

para a lógica programável.

Consultando o Anexo 1 verifica-se que a Rede de Petri que se pretende implementar, ape-

sar de ser uma versão muito reduzida da rede original concebida em [6], possui cerca de 88 lu-

gares e 154 transições; o que é bastante superior ao suportado nas lógicas programáveis dos

DEIs.

Conclui-se então que a lógica programável existente nestes DEIs apenas permite a imple-

mentação de programas de reduzida dimensão, não suportando a implementação dos automa-

tismos no seu todo, impossibilitando uma implementação distribuída como delineado inicial-

mente. Deste facto surge a necessidade de pesquisa por um método alternativo que suporte a

totalidade do código, e se possível suporte o código da sua conversão directa das Redes de

Petri para CEI 61131-3.

Capítulo 6 – Implementação Centralizada

Página | 49

6. Implementação Centralizada

6.1 Introdução ao método de implementação centralizada

No método de implementação abordado no capítulo anterior, revelaram-se limitações que

impossibilitam a implementação total dos automatismos. Surgindo então a necessidade de pes-

quisa por um método alternativo que suporte a totalidade do código, com possibilidade de utili-

zar directamente o código da conversão das Redes de Petri para CEI 61131-3, ao contrário da

lógica dos DEIs que necessitam de uma adaptação.

Portanto, a pesquisa foi orientada para o desenvolvimento de um método que consiste em

utilizar os automatismos convertidos das Redes de Petri para as linguagens da CEI 61131-3, e

implementá-los directamente, sob essas linguagens, num controlador lógico autónomo.

No desenvolvimento deste método utiliza-se a linguagem de Listas de Instruções devido à

sua capacidade e flexibilidade de poder ser aplicada em qualquer tipo de controlador lógico,

cumpridor da CEI 61131-3, por simples replicação de código, mas principalmente pela existên-

cia de ferramentas que permitem a conversão automática das RdP para esta linguagem. Con-

tudo, as conclusões relativas à implementação segundo este método podem-se estender às

restantes linguagens.

A execução dos automatismos requer permanente conhecimento das variáveis presentes

nos DEIs e capacidade de enviar comandos para estes, o que torna necessário a existência de

comunicação entre o controlador lógico e os diversos DEIs. É nesta envolvente que se utiliza a

Norma CEI 61850, nomeadamente as mensagens GOOSE por ela definidas [11,12], que atra-

vés de uma rede local Ethernet permitem a realização de todas as comunicações necessárias.

Portanto, os requisitos que o controlador lógico deve cumprir são:

Capacidade de memória suficiente para suportar da totalidade do código dos automa-tismos;

Suporte CEI 61131-3;

Interface Ethernet;

Suporte GOOSE, da CEI 61850.

Sendo a Norma CEI 61850 específica para Subestações, o interesse dos fabricantes de au-

tómatos industriais em produzir controladores lógicos com suporte para esta Norma é baixo,

pelo que os existentes no mercado são dispendiosos e com capacidades limitadas.

De acordo com os requisitos apresentados para o controlador, a interface necessária ao

funcionamento do sistema, em termos de comunicações entre o controlador e os DEIs, é a re-

de Ethernet, e tendo em consideração os dispositivos disponíveis no mercado, a solução en-

contrada consiste em utilizar um computador com placa de rede Ethernet e sistema operativo


Página | 50

Windows, onde se executa um controlador lógico baseado em software (SoftPLC), comuni-

cante com uma aplicação responsável pelas comunicações com os DEIs através de mensa-

gens GOOSE.

Para realizar a interface entre estes dois softwares utiliza-se a tecnologia de OPC, desen-

volvida para permitir a interligação normalizada entre softwares em ambiente Windows. Por-

tanto, é necessário uma terceira aplicação que funciona como ponte, interligando o servidor

OPC do controlador lógico, com o servidor OPC da aplicação controladora dos GOOSE. Mais

informações e detalhes sobre esta tecnologia são apresentados à frente neste capítulo.

Durante o desenvolvimento deste método são utilizados três programas para o funciona-

mento do sistema de automação:

Controlador Lógico: Como controlador lógico utiliza-se o software de automação Co-

DeSys, da 3S-Software. Para além de possuir servidor OPC, a versão de demons-

tração disponibilizada é completa e não possui um período de avaliação ao contrário

dos restantes softwares;

Aplicação responsável pelas comunicações GOOSE: Para realizar as comunica-

ções entre o controlador lógico e os DEIs utiliza-se o AX-S4 MMS da SISCO. Esta fer-

ramenta é a única do seu género pelo que não existem alternativas;

Aplicação para interligação de servidores OPC: A interligação entre os servidores

OPC é realizada pelo LinkMaster, da Kepware. Existem apenas duas ferramentas que

interligam servidores OPC, no entanto o LinkMaster é a única que possuir um período

de demonstração ilimitado.

Esta nova arquitectura centraliza o processamento dos automatismos num controlador lógi-

co especializado, programado directamente sob a CEI 61131-3, enquanto utiliza a infra-

estrutura distribuída de DEIs para a geração de predicados e redireccionamento de comandos

para os disjuntores.

Esta implementação centralizada dos automatismos modelados por Redes de Petri é seme-

lhante ao “Autómato de Subestações” referenciado em [7], mas em vez de se ligar o autómato

por cablagem aos equipamentos e relés não digitais, são utilizadas as mensagens GOOSE

numa rede local Ethernet.

O sistema de comunicações utilizado no método de implementação centralizada é apre-

sentado na figura 45.


Página | 51

Figura 45 - Sistema de Comunicações da Implementação Centralizada

6.2 Aplicação de DEIs

De acordo com a metodologia proposta neste capítulo, o SAS que se pretende implementar

utiliza um controlador lógico, que executa os programas de automação definidos, comunicante

com os DEIs, que recolhem as informações necessárias ao funcionamento das funções de au-

tomação, e redireccionam os comandos destas funções para os equipamentos primários da

Subestação.Para realizar as comunicações entre o controlador lógico, instalado num computa-

dor sob a forma de softPLC, e os DEIs, recorre-se às mensagens GOOSE, definidas na Norma

CEI 61850. Já as comunicações entre os DEIs e os equipamentos primários da subestação são

realizados sob a forma de cablagem (hardwire).

Figura 46 - Modelo de Comunicações


Página | 52

Através das mensagens GOOSE, o controlador lógico recebe as variáveis, as quais utiliza

fazendo associações lógicas entre as mesmas, formando variáveis compostas (ou macro variá-

veis), que posteriormente são utilizadas no funcionamento dos automatismos. De acordo com

esta metodologia, o controlador tem de dispor de capacidade de processamento adicionar para

executar esta composição de variáveis, não se dedicando exclusivamente à execução dos au-

tomatismos convertidos das Redes de Petri.

Sendo que numa Subestação de Distribuição podem existir até 20 saídas MT [3], o que, jun-

tamente com os restantes equipamentos da Subestação, representa um número considerável

de DEIs com o qual o controlador lógico tem de estabelecer comunicações. O mesmo se con-

clui para o número de mensagens GOOSE necessárias que cresce proporcionalmente com o

número de DEIs presentes numa Subestação.

Para optimizar o sistema de comunicações e reduzir a carga de processamento a executar

pelo controlador, utiliza-se a lógica programável dos DEIs na composição das variáveis neces-

sárias aos automatismos, distribuindo assim parte do processamento por todos os DEIs.

A aplicação da lógica programável nesta composição de variáveis apresenta diversas vanta-

gens:

Modularidade: Nas alterações de dispositivos de painel de Subestação para Subesta-

ção, apenas muda a lógica dos DEIs, a configuração do controlador lógico e de men-

sagens GOOSE permanece igual, o que evidencia a reutilização de código preconcebi-

do;

Redução no número de mensagens GOOSE: Sendo que as variáveis transmitidas

pelas mensagens GOOSE são variáveis compostas, o número de GOOSES necessá-

rios para a transferência de informação é inferior;

Redução na frequência do envio das mensagens: Devido à composição das variá-

veis, a mudança de estado de uma variável não implica a mudança de estado da variá-

vel composta, como uma mensagem GOOSE é publicada com mais frequência quando

um dos valores do seu Data-set é alterado, a frequência do envio de GOOSES diminui;

Redução da carga de processamento do controlador lógico: Visto que a composi-

ção de variáveis utilizadas nas funções de automação é distribuída pelos DEIs, o nível

de carga de processamento atribuído ao controlador lógico é reduzido.

Com esta aplicação adicional, os DEIs para além de realizarem as suas funções usuais,

passam a ser incorporados neste sistema de automação, na medida que recolhem, compõem e

enviam variáveis compostas para o controlador lógico que, por sua vez, utiliza-as directamente

nas funções de automação.

De acordo com o apresentado nesta secção, os requisitos que os DEIs necessitam de cum-


Página | 53

prir para serem utilizados no SAS proposto são:

Realização de funções de protecção;

Aquisição de informações necessárias provenientes do equipamento monitorizado;

Realização de operações lógicas sobre as informações adquiridas;

Capacidade de recepção e envio de mensagens GOOSE;

Configurável de acordo com a linguagem SCL4.

Para o desenvolvimento desta metodologia de implementação foram utilizados apenas DEIs

da SIEMENS. A ferramenta de configuração de DEIs disponibilizada pela EFACEC apresenta

limitações pelo que não é possível configurar os dispositivos para a subscrição de mensagens

GOOSE que não sejam enviadas por um DEI do próprio fabricante.

Para iniciar o processo de programação lógica dos DEIs é necessário fazer um levanta-

mento das variáveis utilizadas no funcionamento dos automatismos, e localizar as correspon-

dentes variáveis nos diferentes módulos do DEI. A programação da lógica para composição de

variáveis é realizada de acordo com os métodos apresentados na secção 6.3.1, onde se apre-

senta o funcionamento da lógica programável do DEI.

Estando concluída a programação lógica dos DEIs, é necessário estabelecer a comunica-

ção entre estes dispositivos e o controlador lógico, o que é realizado recorrendo à ferramenta

de configuração do DEI, neste caso o DIGSI, onde são criados blocos de controlo para mensa-

gens GOOSE, de acordo com o número de variáveis a serem enviadas e comandos a serem

recebidos.

Numa ferramenta de configuração de sistema (Helinks) configura-se a rede de comunica-

ções, realizando as correspondências de editor/subscritor das diferentes mensagens GOOSE,

sendo que o controlador lógico subescreve às mensagens enviadas pelos DEIs, e estes,

subescrevem às mensagens enviadas pelo controlador lógico.

6.3 Controlador Lógico

6.3.1 Software de Automação

A necessidade de recorrer a um controlador lógico para implementação do Sistema de Au-

tomação de Subestação (SAS) proposto, deve-se ao facto dos DEIs não suportarem a imple-

mentação completa dos automatismos, pois além de não cumprirem a Norma CEI 61131-3, a

sua capacidade de lógica programável é bastante limitada.

A utilização de um controlador lógico autónomo supera estas limitações, pois sendo um dis-

positivo de automação, possui capacidade de memória suficiente e é programável nas lingua-

4 A linguagem SCL, definida na Norma CEI 61850, é referente à configuração normalizada de Subestações. Apre-

sentado com mais detalhe no Anexo 6.


Página | 54

gens da CEI 61131-3, o que permite a utilização directa do código resultante da conversão das

Redes de Petri que descrevem os automatismos.

Pode-se então utilizar um autómato programável (PLC), como controlador lógico para exe-

cutar o código em CEI 61131-3. Contudo, para as comunicações entre os DEIs e este controla-

dor, é necessário recorrer a mensagens GOOSE, definidas na Norma CEI 61850. Esta Norma

é específica para Subestações e portanto, os fabricantes de PLCs têm pouco interesse em cri-

ar suporte para a mesma, pois sendo as Subestações um mercado de nicho, não se justifica o

desenvolvimento. Os controladores lógicos existentes no mercado que suportam a CEI 61850

estão associados aos fabricantes de DEIs e são dispendiosos.

Estes factos levam a considerar a alternativa de utilizar um computador para funcionar como

controlador lógico recorrendo a softwares de automação, ou seja, um softPLC. Com poder de

processamento dos computadores da actualidade, a performance de um softPLC é equivalente

ou superior aos PLCs tradicionais, usufruindo ainda da vantagem que no computador é possí-

vel executar outras aplicações para além da automação e existência de meios para conectar o

sistema à internet, abrindo a possibilidade de utilizar o computador como ponto de acesso para

o funcionamento de ferramentas de análise automática de dados.

Relativamente às comunicações, existem aplicações, para ambiente Windows, que permi-

tem a gestão de subscrição e publicação de mensagens GOOSE, utilizando a já existente pla-

ca de rede Ethernet, não havendo necessidades de hardware específico adicional para comu-

nicações.

Devido aos requisitos de Compatibilidade Electromagnética exigidos, é necessário que o

computador a utilizar na Subestação, cumpra a Norma CEI 61850-3.

6.3.2 CoDeSys

O CoDeSys (Controller Development System), desenvolvido pela 3S – Smart Software Solu-

tions, é um conjunto de módulos de software (Suit) que têm como objectivo fundamental a exe-

cução de sistemas de automação, em ambiente Windows.

O CoDeSys, além de permitir a implementação e execução dos programas de automação,

realiza a gestão e mapeamento de variáveis de entrada e saída para interface ao sistema de

automação [18], sendo constituído por quatro módulos independentes:

CoDeSys: Ferramenta Principal de Configuração e Programação;

CoDeSys Control: Controlador Lógico Virtual;

Gateway: Módulo para interface ao Controlador Lógico Virtual

CoDeSys OPC Server: Módulo para acesso a variáveis segundo as Normas do OPC.


Página | 55

Figura 47 - Arquitectura do CoDeSys (Suit) [18]

O módulo principal, o CoDeSys, é a ferramenta responsável pela gestão e programação do

sistema de automação e implementação do código no controlador. Através desta ferramenta,

são criados projectos e associado a estes, dispositivos de controlo lógico, dentro dos quais são

ligados os programas de automação escritos nas linguagens da Norma CEI 61131-3, listas de

variáveis globais (disponíveis a todos os programas dentro do mesmo dispositivo) e configura-

ções simbólicas, que gerem o acesso às variáveis do sistema de automação realizado através

do servidor OPC. Na mesma ferramenta, são configuradas as ligações aos controladores lógi-

cos e as propriedades destes.

Estando concluída toda a configuração e programação do projecto, o CoDeSys compila o

código e transfere-o para o controlador lógico para que possa ser executado. Após o carrega-

mento do projecto, o CoDeSys pode ser encerrando, funcionando o controlador autonoma-

mente.

O módulo Gateway controla a interface ao controlador lógico, sendo através deste módulo

que se estabelece a comunicação da ferramenta principal e do servidor OPC, ao controlador

lógico. O Gateway não possui interface gráfica, funcionando apenas como um processo no sis-

tema operativo.


Página | 56

Figura 48 - Fluxo de Informação

O CoDeSys OPC Server, é o módulo que através do Gateway, interage com o controlador

lógico, e disponibiliza acesso às variáveis (configuradas previamente na configuração simbó-

lica) para interacção com outros softwares de acordo com as normas OPC.

Relativamente ao CoDeSys Control, o CoDeSys permite escolher entre duas gamas de

controladores virtuais: Win Controller; RTE Controller.

O primeiro é utilizado para projectos que não tenham exigências significativas de processa-

mento em tempo real, onde não há necessidade de resposta imediata a mudanças de variáveis

externas.

O segundo controlador, o RTE (Real-Time Environment) Controller, representa a solução

mais indicada para este trabalho, pois o funcionamento dos automatismos pressupõe utilização

em tempo real, onde a resposta do sistema à mudança de estado de uma variável de entrada

deve ser imediata, e portanto, é necessário que o controlador tenha capacidade de gerar inter-

rupções de elevada prioridade no Sistema Operativo. Para cumprir estes objectivos o RTE

Controller é instalado através de um Driver que comunica ao nível do núcleo (Kernel) do Sis-

tema Operativo [19]

Figura 49 - Arquitectura do Controlador para Tempo-Real [19]


Página | 57

6.3.3 Software de Comunicações GOOSE – AX-S4 MMS

O software AX-S4 MMS, criado pela SISCO, tem como objectivo fornecer acesso, em tempo

real, a dados via CEI 61850 para aplicações Windows compatíveis com OPC [20].

Este software é composto por diversos módulos, cada um com funcionalidades específicas:

AX-S4 MMS: Módulo de comunicações MMS. É através desta aplicação que o soft-

ware estabelece as conexões com os dispositivos específicos;

AX-S4 MMS Configuration: Módulo de configuração das conexões aos dispositivos;

AX-S4 GOOSE: Módulo responsável pelas mensagens GOOSE. É através desta apli-

cação que o software publica e subscreve mensagens GOOSE, recorrendo à rede local

Ethernet;

AX-S4 61850: Este módulo cria um DEI virtual descrito por um ficheiro escrito em SCL.

Através de conexões OPC, podem ser controlados os valores deste DEI virtual;

MMS Object Explorer (MOE): Este módulo configura, apresenta e explora a rede dos

dispositivos configurados, podendo realizar leituras de variáveis dos mesmos, e criar

etiquetas para acesso via OPC. Adicionalmente, através dos blocos de controlo de

GOOSE presentes nos dispositivos, o MOE gera o ficheiro de configuração para a apli-

cação AX-S4 GOOSE (Axs4Goose.xml). Os dispositivos são adicionados à rede por

uma conexão pré-configurada através do AX-S4 MMS Configuration, ou através de

um ficheiro escrito em SCL;

OPC Client: Este módulo é uma simples aplicação cliente OPC que permite conexões

aos servidores OPC para realizar leituras e escritas das etiquetas disponibilizadas pe-

los mesmos.

Portanto, torna-se possível utilizar este software para configurar uma rede de dispositivos, e

através de ficheiros SCD pré-concebidos, gerar um ficheiro de configuração para as mensa-

gens GOOSE. Posteriormente, o módulo AX-S4 GOOSE, ficará responsável pela recepção e

envio das mensagens, realizando-se o controlo e leitura das mesmas através de OPC.


Página | 58

Figura 50 - Processo de Configuração Global do Software

6.3.4 Tecnologia OPC

Em 1994 um grupo de fabricantes representando um grande espectro de áreas no sector

industrial formou o que é hoje conhecida como OPC Foundation. Esta fundação tinha como ob-

jectivo o desenvolvimento de uma especificação cliente/servidor única, que permitiria a qual-

quer fabricante, a criação de software e aplicações que pudessem partilhar dados de forma rá-

pida e robusta, e de certa forma eliminar os protocolos proprietários que que forçavam dos fa-

bricantes a duplicar os seus esforços de desenvolvimento.

A primeira especificação a ser desenvolvida foi chamada de “Especificação de Acesso de

Dados 1.0a” (Data Access Specification 1.0a) [21] que foi lançada em 1996. Utilizando esta es-

pecificação, facilmente se desenvolveu softwares baseados no funcionamento cliente/servidor.

A Especificação de Acesso de Dados define como as interfaces devem ser construídas, tan-

to das aplicações de cliente como as de servidor. Portanto, se a especificação for seguida cor-

rectamente, qualquer aplicação cliente sabe que qualquer servidor existente num dispositivo

industrial pode disponibilizar uma conexão para acesso de dados. Com a adopção da Tecnolo-

gia OPC, um fabricante poderia concentrar os seus esforços quase exclusivamente no desen-

volvimento da aplicação de cliente.

Deste modo, entende-se que um servidor OPC funciona como uma Interface de Programa-

ção de Aplicações (do Inglês API – Application Programming Interface) ou mesmo como um

conversor de protocolos. O servidor OPC conecta-se a um dispositivo como um PLC ou qual-

quer outra base de dados, e converte os dados para um formato normalizado OPC e disponibi-

liza-os para aplicações clientes OPC.

A tecnologia OPC é utilizada neste trabalho para estabelecer a comunicação entre o soft-


Página | 59

ware de automação e o software de comunicações GOOSE.

Figura 51 – Interface OPC

Na figura 51 é representado a arquitectura de interface OPC e a organização hierárquica

dos seus componentes.

Servidor OPC (Server): Possui informações sobre o servidor e funciona como um reci-

piente para Grupos OPC;

Grupo (Group): Possui informação sobre si e disponibiliza mecanismos para manutenção e

organização de etiquetas OPC;

Etiqueta (Tag): Representam conexões para a base de dados à qual está conectado o ser-

vidor. Uma etiqueta, não pode ser acedida através de um cliente OPC, pois não existe interface

externa definida dentro da etiqueta. Todos os acessos a etiquetas OPC têm de ser realizados

através do grupo OPC onde as respectivas etiquetas OPC estão definidas.

Associados a cada etiqueta OPC estão os atributos Valor, Qualidade e Carimbo Temporal

(Value, Quality e Timestamp), o significam, respectivamente, o valor da etiqueta, a qualidade

da leitura do valor e o tempo em que foi realizada última alteração.

É de notar que as etiquetas OPC não são fontes de dados, mas sim conexões para estas

fontes.


Página | 60

6.4 Programação e Configuração das Ferramentas

6.4.1 Programação e Configuração do Software de Automação

Nesta secção do trabalho exemplifica-se passo-a-passo a metodologia utilizada para a pro-

gramação e configuração do software de automação, a qual se divide em 4 fases:

1. Inicialização de projecto e configuração do controlador;

2. Declaração de variáveis e programação segundo CEI 61131-3;

3. Configuração simbólica;

4. Compilação e transferência de código para o controlador e inicialização do sistema.

Inicialização de projecto e configuração do controlador: Nesta fase, são inicializados os

módulos de software necessários, criado um novo projecto, adicionado um controlador lógico e

realizada a configuração das comunicações para o mesmo.

1. Iniciar o CoDeSys Control RTE;

2. Iniciar o CoDeSys – Ferramenta Principal;

3. Criar novo projecto:

a. Na janela principal do CoDeSys, seleccionar a opcção New Project, no menu File;

b. Na nova janela, seleccionar Standard Project, intitular o projecto e determinar a

sua localização no sistema de ficheiros do computador;

c. De seguida, seleccionar para dispositivos a conectar – CoDeSys Control RTE, e para linguagem de programação – Instruction Lists.

Ao efectuar os passos acima descrito, é criado um novo projecto de automação no Co-

DeSys, estando integrado neste, o controlador lógico de tempo-real e um programa segundo a

linguagem de Listas de Instruções com o nome de PRG (intitulado por omissão). Na figura 50

está representada a janela principal do CoDeSys após a criação de um novo projecto, onde se

destaca:

Quadro Azul: Menu de Dispositivos, neste menu estão representados, de forma hie-

rarquizada, os vários componentes do projecto. Através deste menu selecciona-se o

componente que se pretende configurar/programar;

Quadro Vermelho: Janela de Edição, nesta janela são carregados os editores corres-

pondentes ao componente do projecto que se pretende configurar/programar.

4. Configuração do Controlador:

a. No Menu de Dispositivos, seleccionar e editar o controlador CoDeSys Control RTE;

b. Na Janela de Edição, seleccionar o separador Communication Settings;

c. Clicar no botão Add Gateway;


Página | 61

d. Seleccionar o presente Gateway e clicar no botão Scan Network;

e. Confirmar que surge o controlador RTE e está activo.

Figura 52 - Janela principal do CoDeSys

Figura 53 - Separador Communication Settings do controlador CoDeSys Control RTE

Na figura 53 está representado o separador Communication Settings correspondente ao


Página | 62

controlador CoDeSys Control RTE, na figura estão numerados os passos para configuração

das comunicações ao controlador.

Declaração de variáveis e programação segundo CEI 61131-3: Nesta fase, é criada a lis-

ta de variáveis globais (GVL), de modo a permitir a declaração de variáveis comuns a todos os

programas na mesma camada hierárquica. Adicionados novos programas ao controlador (POU

– Program Organization Unit) e realizada a respectiva programação.

1. Criar lista de variáveis globais:

a. Seleccionar (não editar), no Menu de Dispositivos, o componente Application;

b. Seleccionar a opção, Project -> Add Object -> Global Variable List;

c. Intitular o novo objecto;

d. Na Janela de Edição, declarar todas as variáveis necessárias;

2. Adicionar novos programas ao controlador:


b. Seleccionar a opção, Project -> Add Object -> POU;

c. Na janela que surge, seleccionar a linguagem de programação e intitular o pro-grama;

d. Seleccionar e editar o objecto Task, hierarquicamente abaixo de Task Configura-tion;

e. Na Janela de Edição, seleccionar a opção Add POU, e de seguida o programa adicionado no passo 7;

f. Repetir as instruções a partir do passo 5 até obter o número de programas ne-cessários para o projecto;

3. Programação:

a. Seleccionar e editar o programa correspondente, listado no Menu de Dispositi-vos;

b. Na metade superior da Janela de Edição, declarar as variáveis locais necessá-rias;

c. Na metade inferior da Janela de Edição, escrever as linhas de código;

Relativamente à programação, existe a possibilidade de importar código previamente conce-

bido sob a forma de texto, não sendo necessário escrever todas as linhas de código através do

editor do CoDeSys.

Configuração simbólica: Estando declaradas todas as variáveis, é criada a configuração

simbólica, um objecto adicionado ao controlador lógico que realiza a gestão do acesso a variá-

veis internas a este, por interface OPC.

1. Criar Objecto de Configuração Simbólica:


Página | 63


b. Seleccionar a opção, Project -> Add Object -> Symbol Configuration;

Figura 54 - Editor de Configuração Simbólica

Na figura 54 podemos destacar:

Quadro Vermelho: Janela de Pesquisa, onde estão listadas todas as variáveis utiliza-

das no projecto;

Quadro Azul: Janela de Pesquisa, onde estão listadas todas as variáveis com acesso

pelo servidor OPC. Nesta janela podemos ainda modificar os direitos de acesso às va-

riáveis, sendo eles, só escrita, só leitura, ou leitura e escrita;

2. Gestão do acesso às variáveis:

a. Seleccionar e editar o objecto Symbol Configuration, listado no Menu de Dis-positivos;

b. Pesquisar as variáveis que se pretendem disponibilizar na janela apropriada e fazer duplo-clique para disponibilizar;

c. Alterar os direitos de acesso das variáveis de acordo com a sua função no pro-jecto.

Compilação e transferência de código para o controlador e inicialização do sistema:

Na última fase da configuração do software, o código é compilado e transferido para o contro-

lador. Após a transferência, procede-se ao arranque do controlador. Depois de realizar todos

os passos, a ferramenta CoDeSys pode ser encerrada, ficando o controlador a funcionar auto-

nomamente.


Página | 64

1. Seleccionar a opção Build -> Build para compilar o código;

2. Seleccionar a opção Online -> Download para transferir o código;

3. Seleccionar a opção Online -> Login para aceder ao controlador;

4. Seleccionar a opção Debug -> Start para inicializar o sistema;

6.4.2 Configuração da Rede no Software de Comunicações GOOSE

Para fazer correcta utilização do software, é necessário configurar todos os endereços de

rede a ser utilizados antes de iniciar a configuração GOOSES. Para tal procede-se do seguinte

modo:

1. Inicializa-se a aplicação de configuração (axs4mmsc.exe);

2. Seleccionar Addressing no menu Configuration -> Network;

3. No separador Host Name, seleccionar New;

4. Clicar Next, escrever o nome do dispositivo que se pretende adicionar, e voltar a clicar Next;

5. Na nova janela, colocar uma verificação na caixa Yes, abaixo de “Will the Host you are configuring going to use a TCP/IP Network?”, e colocar o endereço IP no respectivo espaço disponibilizado. Por fim, clicar Next;

6. Seleccionar Add AR Names, clicar Next. Na listagem apresentada seleccionar o dispo-sitivo adicionado, e clicar Next;

7. Na nova janela, colocar um nome para o dispositivo adicionado, no espaço reservado abaixo de “What is the AR Name that you are configuring”.Este será o nome do dispo-sitivo apresentado no módulo MOE. Clicar Next;

8. Na janela seguinte deixar todos os valores que foram carregados por omissão, e clicar Next. Na janela seguinte clicar também Next;

9. Clicar Finish até sair das opções de configuração;

É necessário executar estes passos para adicionar o computador e tantos DEIs quanto ne-

cessário à configuração de rede do Ax-S4 MMS.

Para gerar o ficheiro de configuração de GOOSE para o módulo AX-S4 GOOSE, utiliza-se o

MMS Object Explorer (MOE):

1. Inicializar o MOE (MMSexp.exe) e seleccionar a opção Connect to AX-S4 MMS;

2. Seleccionar Add Node from SCL file, no menu Database;

3. Na nova janela, pesquisar o ficheiro SCD previamente concebido, onde estão as confi-gurações da Subestação;

4. Na mesma janela, seleccionar o nome do dispositivo que se pretende adicionar, e qual o nome do DEI correspondente, tal como se apresenta na figura 55;


Página | 65

Figura 55 - Janela para adicionar Dispositivos ao MOE

5. Repetir os passos de 2 a 4 para adicionar todos os dispositivos da rede à configuração do AX-S4 MMS;

6. Quando todos os dispositivos tiverem sido adicionados, seleccionar Export AX-S4 GO-OSE Configuration, no menu File;

7. Na nova janela, representada pela figura 55, seleccionar, no quadro da esquerda, os GOOSE que são enviados para os DEIs, e coloca-los no submenu de outgoing. Selec-cionar os GOOSE que são enviados dos DEIs para o PC e coloca-los no submenu de incoming.

8. Por fim, exportar o ficheiro para o directório da aplicação AX-S4 GOOSE, com o nome de “Axs4goose.xml”.

Figura 56 - Janela de exportação de configurações GOOSE


Página | 66

6.4.3 AX-S4 GOOSE

Figura 57 - Janela principal do AX-S4 GOOSE

O AX-S4 GOOSE é o módulo responsável pela subscrição e publicação de mensagens

GOOSE. As configurações das mensagens são carregadas a partir do ficheiro Axs4goose.xml,

previamente concebido através do ficheiro SCD e do módulo MOE, como apresentado anteri-

ormente.

O AX-S4 GOOSE, não apresenta nenhum controlo sobre as mensagens, mas disponibiliza

informação sobre os blocos de controlo das mesmas, como por exemplo, o número de mensa-

gens enviadas e o estado do GOOSE, tal como é apresentado na figura 56.

O controlo das mensagens é realizado através de um servidor OPC lançado em paralelo à

aplicação, ou seja, quando executamos o AX-S4 GOOSE (Axs4Goose.exe), é iniciado um ser-

vidor OPC conectado à base de dados do módulo, disponibilizando etiquetas de todas as vari-

áveis associadas a estas mensagens GOOSE. Deste modo, através de um cliente OPC, é pos-

sível estabelecer uma conexão a estas variáveis e realizar o respectivo controlo, através de lei-

tura e/ou escrita das mesmas.


Página | 67

Figura 58 - Pesquisa das etiquetas disponibilizadas pelo Servidor OPC do AX-S4 GOOSE

A pesquisa das etiquetas representada na figura 58, foi realizada utilizando uma aplicação

cliente OPC (OPC Client.exe), desenvolvida pela SISCO, com o objectivo de testar e controlar

as variáveis disponibilizadas pelo servidor OPC da AX-S4 GOOSE.

6.4.4 Software para Interligação de servidores OPC - LinkMaster

O LinkMaster é um software criado pela Kepware Technologies, que tem como objectivo

fornecer meios para interligação de etiquetas entre servidores OPC, funcionando como uma

ponte universal para sistemas OPC [22]. No presente trabalho utiliza-se esta aplicação para in-

terligar o servidor OPC do controlador lógico, ao servidor OPC do software de comunicações

GOOSE. Ao interligar duas etiquetas, o LinkMaster copia o valor da etiqueta fonte (input) e es-

creve-o na etiqueta de destino (output), não havendo comunicação directa entre os dois ser-

vidores OPC intervenientes na interligação.

Figura 59 - Janela principal do LinkMaster


Página | 68

Na figura 59 apresenta-se a janela principal do LinkMaster, nela podemos destacar:

Quadro Verde: Pesquisa de etiquetas OPC;

Quadro Vermelho: Pesquisa de etiquetas OPC;

Quadro Azul: Listagem dos Grupos de Interligação;

Quadro Amarelo: Listas de Interligações relativas a um grupo de interligação.

No LinkMaster, as interligações entre as etiquetas OPC são organizadas em directórios de-

nominados de Grupos de Interligação (Link Groups) e programam-se de uma forma simples e

intuitiva baseada numa interface gráfica de arrastar-e-largar (drag-and-drop).

Configuração e Programação do LinkMaster:

1. Seleccionar a opção Edit -> New Link Group, para criar um Grupo de interligação;

2. Selecciona-se numa das janelas de pesquisa, a etiqueta que se pretende utilizar como fonte;

3. Arrasta-se a etiqueta de fonte para a zona de interligação, criando-se uma interligação, cu-ja fonte (input), é a etiqueta arrastada inicialmente;

4. Selecciona-se numa das janelas de pesquisa, a etiquete que se pretende utilizar como destino (output);

5. Arrasta-se a etiqueta de destino para a interligação criada anteriormente;

É de notar que para criar uma interligação é necessário que as duas etiquetas sejam do

mesmo tipo, por exemplo, as duas sejam etiquetas booleanas.

6.5 Algoritmo de implementação dos automatismos

Ao longo deste capítulo foram apresentados os diversos componentes que intervêm na rea-

lização prática da implementação dos automatismos e descritos métodos para utilização dos

mesmos.

Como resumo do capítulo, descreve-se sob a forma de algoritmo a metodologia para imple-

mentação dos automatismos, descritos na linguagem de Redes de Petri, validadas e compro-

vadas:

1. Conversão das Redes de Petri: De acordo com os métodos formais de conversão

apresentados no capítulo 5, converter as Redes de Petri para a linguagem da Norma

CEI 61131-3;

2. Implementação do código obtido da conversão, no controlador lógico:

a. Iniciar novo projecto de automação e configurar o controlador lógico;

b. Implementar o código em programas hierarquicamente organizados no projecto do sistema de automação;

c. Gerir o acesso às variáveis do controlador lógico por interface OPC;


Página | 69

d. Compilar e transferir o código para o controlador lógico e proceder ao arranque do mesmo;

3. Configuração do sistema de comunicações:

a. Concepção de um ficheiro ICD descritivo do computador onde se encontra instalado o controlador lógico, de acordo com as mensagens GOOSE que são necessárias;

b. Recorrendo à ferramenta para configuração de sistema segundo a norma CEI 61850, gerar o ficheiro SCD onde constem as configurações de comunicação atri-buídas a cada dispositivo;

c. Através das ferramentas de configuração de DEIs, realizar a subscrição às mensa-gens GOOSE provenientes do Computador, e implementar as configurações nos DEIs;

4. Programação dos DEIs:

a. Utilizar a lógica programável dos DEIs para realizar a composição lógica de variá-veis necessárias ao funcionamento dos automatismos;

b. Conectar todas as variáveis necessárias às funções de automação aos Data-sets

das mensagens GOOSE;

5. Configuração das Comunicações GOOSE no Computador:

a. Configurar a rede de dispositivos no software responsável pelas comunicações

GOOSE;

b. Configurar a edição e subscrição das mensagens GOOSE relativas ao computador;

6. Interligação OPC: Realizar a interligação dos dois servidores OPC, conectando os Da-

ta-sets das mensagens GOOSE às variáveis do controlador lógico.

É de notar que a realização prática das configurações descritas no passo 3 foi efectuada de

acordo com metodologias concebidas em trabalhos paralelo a este, pelo que no presente capí-

tulo, o método é apenas apresentado não se procedendo a nenhuma exemplificação.

Capítulo 7 – Teste do Sistema em Ambiente Laboratorial

Página | 71

7. Teste do Sistema em Ambiente Laboratorial

7.1 Arquitectura do Sistema

Para comprovar o correcto funcionamento do sistema e coordenação entre automatismos

procedeu-se à implementação do SAS numa Subestação virtual/simulada de pequena dimen-

são, sendo composta por 3 equipamentos primários: um painel de chegada de TP e 2 painéis

de saída para linha MT, construída propositadamente para o efeito.

Sendo a Subestação constituída por 3 equipamentos primários, os dispositivos utilizados fo-

ram:

1x DEI Siemens – 7SJ542, Painel de Chegada do TP;

2x DEI Siemens – 7SJ645, Painel de Saída para Linha MT;

1x Computador Pessoal, com processador Centrino Duo T2400 1.83 GHz, 2,5G

GB RAM, placa de rede Ethernet 100 Mbps e sistema operativo Windows XP;

1x Switch de Rede Ethernet 100 Mbps;

1x Mala de Ensaios Omicron.

Os DEIs são interligados, através do Switch, numa Rede Local Ethernet, ao computador

pessoal, para a troca de informações e comandos. A mala de Ensaios é conectada via hardwire

aos DEIs, produzindo sinais analógicos programáveis de corrente ( DEI de saída de linha MT) e

tensão (DEI de chegada do TP), que simulam as leituras de TIs e TTs na ocorrência de Inci-

dentes.

Figura 60 - Arquitectura do Ambiente de Teste


Página | 72

Os DEIs utilizados para comprovar o sistema são exclusivamente do fabricante SIEMENS,

pois devido de configuração da CEI 61850, os DEIs da EFACEC não cumprem os requisitos

para serem utilizados neste SAS.

Configuração e Parametrização

Como referido na metodologia de implementação, o computador é utilizado para execução

de um controlador lógico responsável pelo processamento dos automatismos. Sendo que o

funcionamento destes requer conhecimento das informações presentes nos DEIs, e capaci-

dade de enviar, através destes, comandos de manobra para os disjuntores, são estabelecidas

comunicações de subscrição e publicação de mensagens GOOSE através da rede Ethernet.

No controlador lógico as funções de automação atribuídas a cada linha de saída MT são di-

vididas em POUs, sendo que em cada programa são utilizadas cerca de 1900 linhas de instru-

ções, 56 variáveis de condições específicas, temporizações, contadores e modos de funciona-

mento e ainda 88 variáveis auxiliares para a execução fiel às Redes de Petri.

No presente sistema o computador recebe de cada DEI de saída de linha MT, 10 mensa-

gens GOOSE relativas a condições específicas da rede e subestação, e publica para estes dis-

positivos 2 GOOSE para manobras de disjuntor. Do DEI de painel de chegada do TP, o com-

putador subscreve 5 GOOSE relativos a informações de tensão e frequência. No total, para es-

ta arquitectura, o computador subescreve a 25 mensagens GOOSE e publica 4.

Em termos de parametrização, nos DEIs de saída de linha MT é parametrizado o nível de

corrente que provoca o arranque da função de protecção de máxima intensidade, enquanto no

DEI de chegada do TP são parametrizados dois escalões da função mínimo/máximo de fre-

quência e ainda a função de mínimo/máximo de tensão. Em relação aos automatismos, as pa-

rametrizações a realizar são a nível de temporizações (tempos de isolamento, confirmação fal-

ta de tensão, …), contadores (número máximo de manobras de disjuntor) e modos de fun-

cionamento.

Sinalização

Como neste sistema de ensaio não existem conexões a disjuntores reais, foram criados cir-

cuitos lógicos que simulam o funcionamento do disjuntor, e apresentado no display dos DEIs o

respectivo estado (disjuntor aberto, fechado, ou desconhecido), deste modo, durante a execu-

ção dos testes é possível verificar qual a posição dos disjuntores e comprovar que estes se

comportam como previsto.

Para simplificar a verificação do sistema são ainda utilizados os Leds dos DEIs, atribuindo-

lhes diversas sinalizações, como o arranque das protecções ou recepção de comandos de

abertura/fecho de disjuntor.

O funcionamento dos automatismos pode ser observado no computador, onde se executa o


Página | 73

controlador lógico, sob a forma de depuração (debug) dos programas em Listas de Instruções.

Tempo de Processamento e Comunicação

No software de automação verifica-se através do monitor de tarefa que os programas de au-

tomação são executados com médias de 19 µs, cumprindo os requisitos de tempo-real exigidos

no processamento deste tipo de sistemas.

Os tempos de comunicações são calculados com recurso a um sistema, em que um ele-

mento envia um sinal e o segundo elemento nega o sinal e reenvia para o primeiro, criando um

“loop”. O “loop” é realizado durante um tempo definido, sendo contado o número de mensa-

gens trocadas. O tempo despendido na comunicação é o resultado obtido pela divisão do nú-

mero de mensagens trocadas pelo tempo de execução do “loop”.

O processo de comunicação divide-se em 2 níveis:

DEI – Software de Comunicações GOOSE – Ponte de OPC;

Software de Automação – Ponte de OPC;

Os tempos de comunicação para o primeiro e segundo nível são de 8.8ms e 60ms, respec-

tivamente. Obtendo-se, para o processo completo, um tempo de comunicação de cerca de

70ms. Este tempo de funcionamento é suficiente para o processamento geral dos automatis-

mos na distribuição de energia, exceptuando o aceleramento de protecção permitido pelo au-

tomatismo de religação automática.

O elevado tempo despendido na comunicação entre o software de automação e a ponte de

OPC é justificada pelo overhead entre as diversas camadas de comunicação internas do soft-

ware de Automação5, sendo que existe interesse numa ferramenta de SoftPLC que possua di-

rectamente suporte GOOSE, consequentemente reduzindo os 60ms a alguns microssegundos,

e portanto dispensáveis no tempo global da comunicação, que por sua vez se reduz ao tempo

despendido pelas mensagens GOOSE na rede Ethernet e processamento da lógica nos DEIs.

Através de uma outra ferramenta de software6 determinou-se que 1ms é o tempo utilizado ex-

clusivamente para troca de mensagens GOOSE entre os DEIs e Controlador, e portanto, os

restantes 7.8ms são utilizados para o processamento da lógica dos DEIs.

Os 8.8ms permitiriam a utilização de todos os automatismos e todos os seus modos de fun-

cionamento ao nível da Distribuição, o que é o objectivo principal o trabalho. Contudo, transfe-

rindo o processamento da composição lógica de variáveis dos DEIs para o Controlador Lógico,

o tempo de funcionamento dos automatismos seria aproximadamente 1ms (limitado pelo pro-

cessamento das mensagens GOOSE na LAN Ethernet), permitindo a utilização do sistema tan-

to ao nível da distribuição de energia como do transporte, mas perdendo-se as vantagens indi-

cadas na secção 2 do capítulo 6. 5 Informações obtidas através dos serviços de suporte ao Software de Automação - CoDeSys

6 Ferramenta de Software – Straton, da COPADATA.


Página | 74

7.2 Simulação de Incidentes

Estando o controlador lógico e DEIs configurados e parametrizados, resta programar a mala

de ensaios para as simulações dos diversos tipos de incidentes que possam ocorrer na rede. O

state sequencer é a ferramenta de software disponibilizada pela Omicron para realizar este tipo

de ensaios. Como o nome indica, esta ferramenta executa uma sequência de estados progra-

mados, gerando os sinais analógicos correspondentes para as 3 fases.

Em cada estado e para cada fase, é configurada a amplitude da tensão e corrente, assim

como o valor da frequência e duração temporal do estado. Portanto, uma execução ordenada

de diferentes estados permite simular a ocorrência dos incidentes.

Exemplo de Teste Realizado

Os casos que suscitam mais interesse a nível de teste são da coordenação entre automa-

tismos, portanto, a título de exemplo é descrito o processo completo para um teste da coorde-

nação entre os automatismos de Religação Automática e Deslastre por Mínimo de Tensão. Es-

te teste representa situações em que é necessário garantir a coordenação sob a pena de pre-

judicar ainda mais o estado da rede.

Na ocorrência de um defeito numa das saídas de linha MT, o respectivo disjuntor fará uma

manobra de abertura; enquanto o automatismo de Religação Automática aguarda que termine

a temporização de isolamento, dá-se o arranque da protecção de frequência levando ao Des-

lastre por Mínimo de Frequência; é de importância que ao terminar a temporização, seja verifi-

cado se a frequência foi normalizada; em caso afirmativo, a Religação Automática religa a li-

nha; caso a frequência ainda não esteja normalizada, a Religação Automática não pode religar

a linha, pois estará a aumentar a carga da rede, agravando a situação, portanto, este automa-

tismo defere a religação da linha ao automatismo de Deslastre por Mínimo de Tensão, que por

sua vez apenas irá realizar esta operação quando a frequência normalizar, a não ser que se

suceda um outro incidente.

A parametrização efectuada para este caso é a seguinte:

Protecção de Máxima Intensidade (MI) do DEI de saída de linha MT: 0,6 A;

Protecção de Mínimo de Frequência do DEI de chegada de TP: 45,6 Hz;

Figura 61 - State Sequencer da Mala de Ensaios da Omicron


Página | 75

Modo de Funcionamento do Automatismo RA: RL;

Tempo de Isolamento para Religações lentas: 15 s;

Modo de Funcionamento do Automatismo DF para os DEIs de saídas de linha MT: Deslastre + Reposição; 1º Escalão;

Para efeito da realização de testes, o comando de reposição está automaticamente acti-

vado, não sendo necessário acção do operador para efectuar a reposição de linhas.

A figura 61 representa os sinais analógicos que correspondem a um defeito na linha

seguido por um abaixamento de frequência. De acordo com a duração temporal dos vários es-

tados e a temporização de isolamento lento definida para RA, prevê-se que este sistema evo-

lua para o caso em que RA defere a religação da linha para o DF.

Ao aplicar os sinais analógicos à “Subestação” verifica-se o seguinte:

1. O DEI de saída de linha MT, ao qual a mala de ensaios conecta os sinais de cor-

rente, sinaliza arranque da protecção MI e publica uma mensagem GOOSE ao

controlador lógico com esta informação;

2. O controlador assiste à manobra de abertura do disjuntor e inicializa uma tempori-

zação de isolamento lento;

3. Enquanto decorre esta temporização, o DEI de chegada do TP sinaliza arranque

da protecção de frequência e comunica esta informação ao controlador;

4. O controlador inicia o deslastre das linhas de acordo com o respectivo escalão, e

portanto envia comando de abertura para o DEI da segunda linha;

5. O DEI da segunda linha sinaliza recepção de comando e realiza a abertura do dis-

juntor;

6. Enquanto ambas as linhas estão deslastradas, a temporização de isolamento lento

termina e o automatismo de RA defere a religação da linha ao DF, verificando-se a

inactivada do disjuntor de linha;

7. O DEI de chegada do TP sinaliza normalização da frequência;

8. O controlador lógico envia os comandos de reposição para ambas as linhas;

9. Os 2 DEIs sinalizam recepção do comando e realizam as respectivas manobras

de fecho.

De acordo com esta ordem de operações conclui-se que o teste foi realizado com sucesso

comprovando-se o funcionamento dos automatismos e respectiva coordenação.


Página | 76

7.3 Bateria de Testes

A bateria de testes utilizada encontra-se descrita na tabela 11, na listagem de testes estão

incluídos todas as combinações de coordenação dos automatismos, inclusive, as suas varian-

tes de acordo com os respectivos modos de funcionamento (tabela 1). Nos casos de coordena-

ção, o automatismo que fica responsável pela reposição é apresentado com “[R]”.

Tabela 9 - Bateria de Testes Realizados

# Descrição do Teste

1 Religação Automática (MF: Inibido) [RA]

2 Religação Automática (MF: Religação Rápida [RR])

3 Religação Automática (MF: Religação Lenta [RL])

4 Religação Automática (MF: RL + RL)

5 Religação Automática (MF: RR + RL)

6 Religação Automática (MF: RR + RL + RL)

7 Religação Automática (MF: Inibido para defeitos Fase-Fase / RR para defeitos Fase-Terra)

8 Religação Automática (MF: RL para defeitos Fase-Fase / RR + RL para defeitos Fase-Terra)

9 Religação Automática (MF: RL + RL para defeitos Fase-Fase / RR + RL + RL para defeitos Fase-

Terra)

10 Religação Automática + Deslastre/Reposição por Frequência [DF]

11 Religação Automática + Deslastre/Reposição por Tensão [DU]

12 Deslastre/Reposição por Frequência (MF: Inibido)

13 Deslastre/Reposição por Frequência (MF: Deslastre)

14 Deslastre/Reposição por Frequência (MF: Deslastre + Reposição)

15 Deslastre/Reposição por Frequência [R] + Deslastre/Reposição por Tensão

16 Deslastre/Reposição por Frequência + Deslastre/Reposição por Tensão [R]

17 Deslastre/Reposição por Tensão (MF: Inibido)

18 Deslastre/Reposição por Tensão (MF: Deslastre)

19 Deslastre/Reposição por Tensão (MF: Deslastre + Reposição)

20 Deslastre/Reposição por Tensão [R] + Deslastre/Reposição por Frequência

21 Deslastre/Reposição por Tensão + Deslastre/Reposição por Frequência [R]

22 RA + DF + DU [R]

23 RA + DU + DF [R]

24 Operação com 1º e 2º Escalão na Frequência

25 Encravamento Pós-fecho de origem externa

Conclusão dos Testes

Todos os testes foram concluídos com sucesso comprovando o correcto funcionamento dos

automatismo e a sua coordenação, consequentemente a metodologia apresentada neste tra-

balho, para a implementação normalizada dos automatismos modelados por Redes de Petri, é

validada.

Capítulo 8 – Conclusão e Trabalhos Futuros

Página | 77

8. Conclusão e Trabalhos Futuros

Este trabalho foi realizado no âmbito das Smart-Grids, envolvendo áreas da Electrotécnia de

Energia, Sistemas de Decisão e Controlo, e Telecomunicações, sendo focado em aplicações

para necessidades reais do sector da distribuição de energia eléctrica, nomeadamente Subes-

tações.

Com objectivo principal, o desenvolvimento de metodologias para implementação normali-

zada de automatismos nas subestações de distribuição, este trabalho possui uma grande com-

ponente de pesquisa relacionada com as tecnologias existentes na área e estudo de normas

internacionais (CEI 61131-3 e CEI 61850), e uma componente prática na experimentação dos

métodos desenvolvidos.

O presente documento é o produto final do trabalho, onde se apresentam e exemplificam as

diversas fases do projecto, culminando na descrição passo-a-passo de um algoritmo para reali-

zação de uma implementação funcional normalizada, testada e comprovada, dos automatismos

descritos em Redes de Petri, nos actuais SAS de arquitectura distribuída.

Neste trabalho é utilizada a tecnologia recente no mercado, nomeadamente: DEIs com su-

porte à Norma CEI 61850; Controladores lógicos, sob a forma de softPLC, que tomam proveito

das capacidades de processamento disponíveis nos processadores da actualidade; Softwares

que utilizam a placa de rede Ethernet na subscrição e publicação de mensagens GOOSE. A

aplicação integrada destas tecnologias num único sistema constitui um projecto pioneiro na

área da automação de subestações.

A arquitectura do sistema assenta na aplicação das Normas Internacionais CEI 61131-3 e

CEI 61850, relativas às linguagens de automação e sistemas e redes de comunicações em

Subestações, respectivamente, as quais proporcionam interoperabilidade a nível da automa-

ção, onde os mesmos programas podem ser executados por quais queres controladores lógi-

cos, e a nível de comunicações, sendo possível configurar DEIs de quais queres fabricantes

com um mesmo ficheiro SCD, dispensando a utilização de conversores protocolares.

A reutilização de programas e configurações, sugerida pela interoperabilidade, tem impactos

a nível de custos de implementação do SAS, tornando a componente de engenharia do pro-

jecto, ou seja, o estudo do sistema, mais barato, permitindo ainda poupança de tempo na con-

figuração de Subestações.

Outro aspecto referente à introdução da interoperabilidade no SAS é a capacidade de sepa-

rar os serviços de Engenharia, do fornecimento/fabrico de equipamentos, ou seja, visto que se

utilizam ferramentas e procedimentos compatíveis com todos os equipamentos, respeitantes

das Normas, não é exigido que sejam os fabricantes a realizar a configuração dos sistemas,

havendo uma separação da entidade responsável pelo fabrico dos equipamentos, da entidade

que configura os respectivos equipamentos.

Capítulo 8 – Conclusão e Trabalhos Futuros

Página | 78

Sendo que o código referente aos automatismos é executado num controlador lógico torna-

se possível realizar alterações nas funções de automação de uma forma simples, rápida e ro-

busta, sem que seja necessário modificar a configuração de todos os DEIs de uma Subesta-

ção, permitindo alteração de parametrizações, realização de manutenção ao sistema, ou o seu

melhoramento, com a possibilidade de introdução de novos automatismos.

O funcionamento do sistema foi comprovado não só através de simulações computacionais,

mas também num ambiente de teste real construído para o efeito.

A metodologia de implementação proposta é apresentada de acordo com uma combinação

de software e hardware específico, cujo propósito é a demonstração do conceito, não é impe-

rativo a sua utilização para realizar uma implementação normalizada com sucesso, existem ou-

tras soluções que podem ser consideradas, como por exemplo, diferentes controladores lógi-

cos ou softwares de comunicações GOOSE.

Trabalhos Futuros

No sentido de aprofundar o desenvolvimento do projecto, como trabalho futuro, propõe-se

testar o sistema com diferentes softwares, tanto para a automação, como para as comunica-

ções GOOSE, ou diferentes dispositivos, por exemplo, substituir o softPLC por hardPLCs e im-

plementar a mesma programação e configuração, comparando-se a performance entre os dife-

rentes sistemas.

A metodologia desenvolvida neste trabalho é testado com recurso a variáveis internas dos

DEIs para simular o comportamento do disjuntor. Será de interesse, conectar os DEIs, a dis-

juntores reais, e observar o comportamento do sistema.

Em termos de novas funções de automação, poderão ser implementados outros automatis-

mos necessários à Subestação, de modo a obter um sistema constituído por automatismos re-

ferentes a linhas AT, saídas MT, Transformadores de Potência e restantes serviços. Deste mo-

do ter-se-ia um SAS completo com possibilidade de implementação numa Subestação Pro-

tótipo, representando uma possibilidade para a próxima geração de controlo de Subestações.

Referências Bibliográficas

Página | 79


[1] – EDP Distribuição em Números 2006,2007 e 2008;

[2] – Relatórios de Qualidade de Serviço, EDP, 2001-2010;

[3] – Projecto-Tipo, Instalações AT e MT Subestações Distribuição, EDP, Fevereiro 2007;

[4] – Catálogos de fabricantes referentes aos respectivos DEIs:

EFACEC: TPU S420, EDIÇÃO 1 – REV. 1.7, MAIO 2010;

SIEMENS: SIPROTEC 4 7SJ64, SIEMENS SIP 2008;

ABB: REF630, ABB 2011;

ALSTOM: MiCOM ALSTOM P145, ALSTOM 2010;

GENERAL ELECTRIC: F60, 090209-v3, GE Digital Energy;

SEL: SEL-351-5, -6, -7 Protection Systems, Schweitzer Engineering Laboratories, Inc. 2010;

[5] – Karl-Heinz John, Michael Tiegekamp, “IEC 61131-3: Programming Industrial Automation

Systems”, 1995;

[6] – J.L. Pinto de Sá, “Automatismos Comunicantes em Subestações de Distribuição”, Tese de

Doutoramento, Universidade Técnica de Lisboa, Março de 1988;

[7] – J.L. Pinto de Sá e J.P.S. Paiva, “A Multitasking Software Architecture to Implement Con-

current Switching Sequences Designed with Petri Nets”, IEEE Trans. Power Del., vol. 6,

No.4, Julho 1991;

[8] – J.L. Chirn and D. C. McFarlane, “Petri Nets Based Design of Ladder Logic Diagram”, 2000;

[9] – Georg Frey, “Automatic Implementation of Petri Net Based Control Algorithms on PLC”,

2000;

[10] – J.L. Pinto de Sá e J.P.S. Paiva, “Design and Verification of Concurrent Switching Se-

quences with Petri Nets”, IEEE Trans. Power Del., vol. 5, No.4, Outubro 1990;

[11] – Renata S. Nunes, Maurício de Campos, Fabiano Salvadori, “Norma IEC 61850: caracte-

rísticas e possibilidades de implementação na automação de subestações de energia”,

CRICTE, 2006;

[12] – IEC TC 57, IEC 61850-7-2: Communication Networks and Systems in Substations, Part:

7-2: Basic communication structure for substation and feeder equipment – Abstract commu-

nication service interface (ACSI), 2003-05;

[13] – J.L. Pinto de Sá e R. Cartaxo, “Implementing Substations Automatic Control Functions

Designed with Petri Nets on IEC 61850”, IEEE Trans. Power Del., vol. 26, No.2, Abril 2011;


Página | 80

[14] – James L.Peterson, Petri Net Theory and the Modeling of Systems, Prentice-Hall, 1981;

[15] – Hugh Jack, Automating Manufacturing Systems with PLCs, 2005;

[16] – Manual WinProt4, Efacec;

[17] – Manual DIGSI 4, Siemens;

[18] – Manual CoDeSys V3, 3S-Software;

[19] – Manual CoDeSys Control RTE V3, 3S-Software;

[20] – Manual AX-S4 MMS, Sisco;

[21] – OPC Foundation, www.opcfoundation.org;

[22] – Manual Linkmaster, Kepware;

Anexos

Página | 81

Anexo 1 – Redes de Petri dos Automatismos para Linhas MT

As Redes de Petri são as presentes em [6], reproduzidas aqui com a autorização do autor.

Figura 62 - Rede de Petri do Automatismo de Religação Automática

Anexos

Página | 82

Figura 63 - Rede de Petri do Automatismo de Deslastre por Tensão Zero

Anexos

Página | 83

Figura 64 - Rede de Petri do Automatismo de Mínimo de Tensão

Anexos

Página | 84

Figura 65 - Rede de Petri com os 3 automatismos

Anexos

Página | 85

Anexo 2 – Propriedades das Redes de Petri

Alcançabilidade:

Para uma Rede de Petri M= (P,T,I,O,μ0), a alcançabilidade traduz-se no conjunto de

todas as marcações atingíveis, o conjunto alcançável μ’ R(M).

Limitação:

Um lugar é k-limitado se o número de marcas num lugar não exceder o inteiro k.

Definição 7: Um lugar Pi P de uma Rede de Petri M= (P,T,I,O,μ0) é k-limitada se

para qualquer μ’ R(M), μ’ ≤ k.

O número de lugares numa rede é finito, portanto, ao determinar o lugar com o mai-

or k pode-se definir a Rede de Petri como k-limitada, sendo que todos os seus luga-

res são k-limitados.

Segurança:

A segurança é um caso particular de limitação, onde k toma o valor 1, ou seja, um

lugar possui no máximo uma marca.

Definição 8: Um lugar Pi ϵ P de uma Rede de Petri M= (P,T,I,O,μ0) é seguro se pa-

ra qualquer μ’ R(M), μ’(Pi) ≤ 1. Uma Rede de Petri é segura se todos os lugares

dessa rede forem seguros.

Conservação:

Uma Rede de Petri é estritamente conservativa se o número total de marcas per-

manecer constante e igual ao seu valor inicial.

Definição 9: Uma Rede de Petri M= (P,T,I,O,μ0) é estritamente conservativa se pa-

ra qualquer μ’ R(M):

∑

∑

Para sistemas genéricos é definido um vector de peso, w, w = (w1, w2, …, wn) define

um peso wi para cada lugar Pi ϵ P. A soma ponderada, com respeito a este vector

de peso, de todas as marcações alcançáveis da rede deve ser constante, definindo

uma Rede de Petri conservativa.

Anexos

Página | 86

Definição 10: Uma Rede de Petri M= (P,T,I,O,μ0) é conservativa, em concordância

com um vector de peso w, w = (w1, w2, …, wn), n=|P|, wi ≥ 0, se para qualquer μ’ϵ

R(M):

∑

∑

Vivacidade:

A vivacidade está associada à capacidade das transições poderem efectuar o res-

pectivo disparo, e está classificada de acordo com cinco níveis de vivacidade.

Definição 11: A vivacidade de uma Rede de Petri M= (P,T,I,O,μ0) é classificada do

seguinte modo:

Nível 0: A transição tj é viva de nível 0 se nunca poder ser disparada;

Nível 1: A transição tj é viva de nível 1 se for potencialmente disparável, ou se-

ja, existe uma μ’ϵ R(M) tal que tj é disparável em μ’;

Nível 2: A transição tj é viva de nível 2 se para cada inteiro n existe uma se-

quência de disparo na qual tj ocorre pelo menos n vezes;

Nível 3: A transição tj é viva de nível 3 se existe uma sequência infinita de dis-

paros para a qual tj ocorre infinitas vezes;

Nível 4: A transição tj é viva de nível 4 se para cada μ’ R(M) existe uma se-

quência de disparo, σ, tal que tj é disparável em δ(μ’,σ);

Cobertura:

Para uma Rede de Petri M= (P,T,I,O,μ0), a marcação μ’ R(M) é coberta se existir μ,

tal que μ’(i) ≤ μ(i), para todos os lugares Pi ϵ P.

Existem diversos métodos que podem ser executados para determinar estas propriedades

de modo a garantir o correcto funcionamento da Rede, entre eles estão:

Árvore de Alcançabilidade: Partindo de uma marcação inicial e de acordo com o dis-

paro de transições e o conceito de cobertura, é construída uma árvore de alcançabili-

dade para determinar todas as marcações alcançáveis;

Equações Matriciais: Este método consiste em utilizar a matriz de incidência da Rede

de Petri, determinada pela diferença entre a matriz da função de entrada e a matriz da

função de saída, e através de cálculos numéricos determinar vectores de disparo para

atingir uma marcação estipulada. Com este método é possível avaliar invariância tem-

poral da rede, ou seja, verificar se existem ciclos de operações;

Anexos

Página | 87

Uma apresentação mais detalhada dos métodos formais de análise para as Redes de Petri

seria extensa e inapropriada para este trabalho, visto que não se realizam análises às Redes

de Petri dos automatismos. Contudo, no capítulo 4 de [5] é possível consultar os detalhes rela-

tivos a cada método.

Como estas análises não envolvem o domínio operacional é adicionalmente necessário pro-

var que determinadas condições não ocorrem simultaneamente (invariância de lugares) e que

determinados eventos não ocorrem em conjunto (invariância de transições).

Através destes métodos formais de análise às Redes de Petri, torna-se possível modelar o

sistema, detectar problemas e optimizar o comportamento ainda numa fase de desenvolvi-

mento. Existe software onde foi implementado estes métodos, permitindo realizar análises a

redes de elevada dimensão e complexidade, de uma forma rápida e robusta.

Anexos

Página | 89

Anexo 3 – Problemas associados à conversão das Redes de

Petri

Neste anexo são abordados os problemas que surgiram durante o desenvolvimento dos mé-

todos de conversão das Redes de Petri para linguagens da Norma CEI 61131-3, justificando-se

as opções tomadas nestes métodos.

Diagramas Ladder

Os controladores lógicos que executam os Diagramas de Ladder possuem um de dois tipos

de varrimento lógico [5,8]:

Varrimento Horizontal (Horizontal Scanning): Neste tipo de varrimento as regras

(rungs) são processadas uma a uma, avaliando-se os elementos de entrada e actuan-

do de imediato nos elementos de saída. Este tipo de varrimento é o mais utilizado nos

controladores lógicos;

Varrimento Vertical (Vertical Scanning): Com este tipo de varrimento, o controlador

lógico processa os elementos de entrada de todas as regras, e posteriormente actua

nos elementos de saída;

Figura 66 - Varrimento Horizontal e Varrimento Vertical nos Diagramas Ladder

De acordo com o apresentado no capítulo 5, relativo à conversão das Redes de Petri, veri-

fica-se que o diagrama apresentado na figura 14 é a representação de um lugar genérico. No

referido diagrama existem três elementos: Pi, variável booleana que representa a marcação do

lugar; L, condição de marcação do lugar; U, condição de desmarcação do lugar;

Focando-se apenas no funcionamento do mecanismo de disparo das Redes de Petri, a

condição de marcação e desmarcação são definidas do seguinte modo:

Condição de Marcação (L): Definida por um “ou” lógico de subcondições associadas a

todas as transições que possuam como lugar de saída o lugar em questão. Nestas

Anexos

Página | 90

subcondições, realiza-se um “e” lógico entre todos os lugares de entrada e lógica pro-

posicional referente à respectiva transição.

Condição de Desmarcação (U): Definida por um “ou” lógico de subcondições associa-

das a todas as transições que possuam como lugar de entrada o lugar em questão.

Nestas subcondições, realiza-se um “e” lógico entre a lógica proposicional da transição

e os restantes lugares de entrada.

Considera-se a seguinte Rede de Petri genérica:

Figura 67 - Rede de Petri Genérica

De acordo com a metodologia apresentada para a conversão baseada apenas no funciona-

mento do mecanismo de disparo, obtém-se o seguinte Diagrama Ladder:

Figura 68 - Diagrama de Ladder Genérico 1

Sendo executado por um controlador lógico de varrimento horizontal, ou seja, regra a re-

gra, e tendo em conta que a proposição lógica da transição Ti já se encontra activa, a sequên-

cia de disparo é executada do seguinte modo:

1- Regra 1:

Condição de Marcação de Pi está inactiva, logo o lugar não está forçado a estar activo;

Condição de Desmarcação está activa, pois a proposição lógica de Ti está activa, por-

tanto o lugar Pi é desmarcado;

2- Regra 2:

Anexos

Página | 91

Condição de Marcação de Pi+1 está inactiva, pois apesar de Ti estar activa, Pi já não

se encontra marcado;

Figura 69 - Sequência de Disparo correspondente ao Diagrama da figura 68

Como se pode verificar, a marcação do lugar Pi não é transposta, é eliminada, invalidando a

propriedade de conservação e potencialmente provocando falha no funcionamento global do

sistema.

Para corrigir este problema é criada uma condição adicional: Uma transição apenas des-

marca os seus lugares de entrada, quando os seus lugares de saída forem marcados.

Com esta condição redefine-se a condição de desmarcação:

Condição de Desmarcação: Definida por um “ou” lógico de subcondições associadas a to-

das as transições que possuam como lugar de entrada o lugar em questão. Nestas subcondi-

ções, realiza-se um “e” lógico entre a proposição lógica da transição e um lugar de saída dessa

transição (aleatório).

De acordo com a redefinição da condição de desmarcação apresenta-se o novo Diagrama

de Ladder para o lugar genérico Pi:

Figura 70 - Diagrama de Ladder Modificado

Anexos

Página | 92

Com o Diagrama de Ladder modificado, a sequência de disparo é executada do seguinte

modo:

Figura 71 - Sequencia de Disparo modificada

1- Regra 1:


Condição de Desmarcação está inactiva, pois apesar da proposição lógica de Ti está

activa, o lugar Pi+1 não está marcado, portanto o lugar mantém-se activo;

2- Regra 2:

Condição de Marcação de Pi+1 está activa, pois a proposição lógica de Ti está activa e

Pi está marcado, portanto o lugar Pi+1 é marcado;

3- Regra 1:


Condição de Desmarcação está activa, pois a proposição lógica de Ti está activa e o

lugar Pi+1 está marcado, portanto desmarca-se o lugar Pi;

Verifica-se que a redefinição da condição de desmarcação, utilizada na conversão das Re-

des de Petri para Diagramas Ladder, permite a construção de diagramas que funcionam cor-

rectamente para qualquer tipo de varrimento dos controladores lógicos, portanto será esta con-

dição de desmarcação a utilizada de modo genérico.

Listas de Instruções

A conversão das Redes de Petri para Listas de Instruções, é realizada através da constru-

ção de blocos de instruções que são executados sequencialmente, de acordo com uma ordem

específica, tal como se apresenta na figura 19. O método desenvolvido para realizar esta con-

versão é baseado na metodologia apresentada em [9].

Em [9] define-se a ordem pela qual os blocos são sequencialmente executados e os dois ti-

pos de blocos de instruções, contudo, justificando-se pela optimização do código e gestão do

acumulador, o autor não faz uso de qualquer tipo de saltos na execução das instruções, o que

Anexos

Página | 93

pode originar a falha de funcionamento do sistema, tal como se pode verificar na seguinte rede:

Figura 72 - Rede de Petri para exemplificação de falha de funcionamento

De acordo com a metodologia apresentada em [9], a Lista de Instruções resultante da con-

versão é:

Figura 73 - Lista de Instruções da conversão da Rede de Petri da Figura 72

Como se pode constatar pela lista de instruções, as acções dos lugares P2 e P3 nunca são

executadas, pois na sequência de instruções são realizados os disparos de T1,T2 e T3, quan-

do o primeiro bloco de instruções de lugar é processado, a Rede de Petri já regressou à sua

marcação inicial, concluindo-se assim que esta metodologia possui falhas, pelo que é necessá-

rio medidas adicionais para corrigir o problema.

Anexos

Página | 94

A solução encontrada passa por adicionar saltos de instrução, inseridos depois das acções

de Reset/Set das transições, para o primeiro bloco de lugar, deste modo, é garantido que ao se

realizar um disparo de transição, os blocos de lugares são processados.

Outro aspecto desta metodologia é a ineficiência da verificação das condições de disparo

das transições. Considerando o caso da transição T4, a avaliação da condição de disparo é re-

alizada por um “e” lógico de 8 elementos e no entanto a transição nunca é disparável devido à

marcação dos lugares de entrada, seria mais eficiente separar a verificação dos lugares de en-

trada, da verificação da proposição lógica. Para aplicar esta optimização, insere-se um salto

condicional negado após a verificação dos lugares de entrada, para o próximo bloco de instru-

ções, deste modo, se os lugares de entrada não permitirem o disparo da transição, a execução

salta para o próximo bloco, não perdendo tempo de processamento com a verificação da pro-

posição lógica.

De acordo com a correcção e optimização sugerida, a lista de instruções relativas à conver-

são da Rede de Petri da figura 74 é a seguinte:

Figura 74 - Lista de Instruções corrigida e optimizada da Rede de Petri da Figura 72

Anexos

Página | 95

Anexo 4 – Exemplo completo de Conversão

Neste anexo é apresentado um exemplo de conversão de uma Rede de Petri com objectivo

de contemplar todos os casos especiais relativos à conversão.

Figura 75 - Rede de Petri para exemplo completo de conversão

Diagramas de Ladder

De acordo com a metodologia para conversão de Redes de Petri apresentada no capítulo 5

é construído o seguinte Diagrama de Ladder:

É de notar que as transições T4 e T6 não possuem condições lógicas, e portanto o seu va-

lor lógico é sempre verdadeiro, substituindo os contactos normalmente abertos por shunts e os

contactos normalmente fechados por circuitos abertos. Neste diagrama, os contactos das refe-

ridas transições permaneceram por uma questão de compreensão do método de conversão.

Anexos

Página | 96

Figura 76 - Diagrama de Ladder resultante da conversão da Rede de Petri da figura 75

Anexos

Página | 97

Listas de Instruções

De acordo com a metodologia para conversão de Redes de Petri apresentada no capítulo 5

é construída a seguinte Lista de Instruções:

Figura 77 - Lista de Instruções resultante da conversão da Rede de Petri da figura 75

Anexos

Página | 99

Anexo 5 – Lógica Programável de DEIs

Uma pesquisa sobre as capacidades dos DEIs revela que existem diversos tipos de lógica

programável praticada entre os fabricantes, contudo nenhuma está de acordo com as lingua-

gens normalizadas apresentadas na CEI 61131-3.

Tabela 10 - Lógica Programável dos DEIs

Fabricante DEI Software

Programação Lógi-

ca

Tipo de

Programação

ABB REF630 PCM600 Blocos Funções e Matriz de Si-

nais

ALSTOM MiCOM P145 S1 Studio Gates Lógicas Básicas

EFACEC TPU-S420 WinProt 4 Gates Lógicas Básicas

General Elec-

tric

F60 FlexLogic Equações Lógicas

SEL SEL 351 SELogic Equações Lógicas

SIEMENS SIPROTEC 4

7SJ64

DIGSI 4 CFC e Matriz de Sinais

Anexos

Página | 101

Anexo 6 – Substation Configuration Language

Entre outras definições da Norma CEI 61850 foi criada a SCL – “Substation Configuration

Language” (Linguagem de Configuração de Subestações). Esta linguagem tem como objectivo

principal normalizar informações relativas aos DEIs, ou seja, os seus modelos de dados. Com

base neste conceito torna-se possível estabelecer o mapeamento dos diferentes nós lógicos

nos respectivos DEIs que os implementam. Podem também ser adicionadas informações relati-

vas aos canais de comunicação e funcionalidades específicas de cada equipamento de mano-

bra, ao qual se pretende associar um determinado painel da subestação.

Esta linguagem de alto nível, baseada em XML (Extensible Markup Language), permite ob-

ter uma normalização dos métodos para a configuração de subestações e da nomenclatura uti-

lizada, através de um modelo único de descrição de dados.

Ao estabelecer regras para a formatação dos ficheiros, e criar estruturas bem definidas, é

possível garantir a transferência de descrições das funcionalidades dos DEIs e descrições do

SAS de um modo fiável e robusto, tornando-se assim possível executar uma comunicação bidi-

reccional entre as ferramentas de configuração de DEIs e as ferramentas de sistema, e conse-

quentemente, assegurar a interoperabilidade entre as várias ferramentas de engenharia. Deste

modo é possível configurar uma subestação independentemente do fabricante do DEI e das

suas ferramentas específicas.

A norma CEI 61850 define diversos tipos de ficheiros SCL, cada um com a respectiva fun-

ção:

ICD – “IED Capability Description”: Descreve as capacidades do DEI, descrito pelo res-

pectivo fabricante, em termos de comunicações e modelos de dados;

SSD – “System Specification Description”: Descreve o esquema unifilar da subestação,

assim como, as funções executadas pelo equipamento primário, em termos de nós lógicos;

SCD – “Substation Configuration Description”: Descreve a configuração das comunica-

ções e funções do SAS e respectiva relação com a subestação;

CID – “Configured IED Description”: Descreve uma instância de um DEI completamente

configurado.

Recorrendo à linguagem SCL, a configuração de uma Subestação processa-se do seguinte

modo:

1. Através da ferramenta de configuração de sistema, utiliza-se o projecto da Subestação

para construção do ficheiro SSD, descritivo do esquema unifilar e das funções execu-

tadas pelo equipamento primário;

2. Com as ferramentas de configuração de DEIs, obtêm-se destes os ficheiros ICD que

descrevem as capacidades destes dispositivos;

Anexos

Página | 102

3. O conjunto de ficheiros ICD e SSD é utilizado na ferramenta de configuração de siste-

ma para produzir o ficheiro SCD;

4. Com recurso ao ficheiro SCD, as ferramentas de configuração dos DEIs geram fichei-

ros CID, que são implementados nos próprios DEIs.

Na figura 78 está representado o modelo do processo de configuração de uma Subestação.

Figura 78 - Modelo de Configuração de Subestação

De acordo com o modelo apresentado na figura 78, para realizar a configuração da Subes-

tação é necessário o ficheiro ICD de cada dispositivo interveniente. Sendo que o controlador

lógico não cumpre a Norma CEI 61850, não possui ficheiro ICD associado, pelo que se proce-

deu à construção de um ficheiro ICD representativo deste dispositivo, onde constam as suas

capacidades e funções, especificadas de acordo com as necessidades de automação, de mo-

do a que a ferramenta de configuração de sistema possa reconhecer este dispositivo como

cumpridor da Norma em questão.

O estudo de metodologias para realizar este tipo de configuração tem motivado a realização

de teses de mestrado, sendo este facto representativo do grau de exigência e complexidade

necessários para o estudo destas aplicações. Por esta razão, os ficheiros da SCL, utilizados

neste trabalho para configuração de comunicações, provêm de trabalhos que foram realizados

em paralelo a este, no âmbito das Subestações de Energia.

A ferramenta universal de configuração de sistema utilizada para as configurações de co-

municação durante o desenvolvimento desta metodologia é o Helinks – CEI 61850 tools.

Implementação Normalizada de Automatismos de · PDF file5.3 SIPROTEC 7SJ645 -...

Documents

Transcript of Implementação Normalizada de Automatismos de · PDF file5.3 SIPROTEC 7SJ645 -...