Post on 18-Mar-2018
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;
Capítulo 1 – Introdução
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.
Capítulo 1 – Introdução
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.
Capítulo 1 – Introdução
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
Capítulo 2 – Automatismos e Redes de Petri
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.
Capítulo 2 – Automatismos e Redes de Petri
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
Capítulo 2 – Automatismos e Redes de Petri
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;
Capítulo 2 – Automatismos e Redes de Petri
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.
Capítulo 2 – Automatismos e Redes de Petri
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
Capítulo 3 – CEI 61131-3
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
Capítulo 3 – CEI 61131-3
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.
Capítulo 3 – CEI 61131-3
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
Capítulo 3 – CEI 61131-3
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)
Capítulo 3 – CEI 61131-3
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
Capítulo 3 – CEI 61131-3
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.
Capítulo 3 – CEI 61131-3
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
Capítulo 4 – Conversão de Redes de Petri
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”.
Capítulo 4 – Conversão de Redes de Petri
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:
Capítulo 4 – Conversão de Redes de Petri
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
Capítulo 4 – Conversão de Redes de Petri
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
Capítulo 4 – Conversão de Redes de Petri
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;
Capítulo 4 – Conversão de Redes de Petri
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;
Capítulo 4 – Conversão de Redes de Petri
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
Capítulo 4 – Conversão de Redes de Petri
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.
Capítulo 5 – Implementação de Redes de Petri em DEIs
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.
Capítulo 5 – Implementação de Redes de Petri em DEIs
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
Capítulo 5 – Implementação de Redes de Petri em DEIs
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
Capítulo 5 – Implementação de Redes de Petri em DEIs
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
Capítulo 5 – Implementação de Redes de Petri em DEIs
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
2 Aux 3 Log.A. 2 Gate 3 1 Não
3 Aux 4 Log.A. 2 Gate 4 2 Sim
4 Aux 5 Log.A. 2 Gate 5 1 Não
P2 Log.A. 1 Gate 34 OR
1 Aux 1 Log.A. 2 Gate 1 1 Não
2 Aux 2 Log.A. 2 Gate 2 2 Sim
3 Aux 4 Log.A. 2 Gate 4 1 Não
4 Aux 6 Log.A. 2 Gate 6 1 Não
Capítulo 5 – Implementação de Redes de Petri em DEIs
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
2 Aux 5 Log.A. 2 Gate 5 2 Sim
T2 Log.A. 1 Gate 36 OR 1 Aux 1 Log.A. 2 Gate 1 2 Não
2 Aux 6 Log.A. 2 Gate 6 2 Sim
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
Aux 2 Log.A. 2 Gate 2 AND 1 P1 Log.A. 1 Gate 33 2 Não
Aux 3 Log.A. 2 Gate 3 AND 1 P2 Log.A. 1 Gate 34 1 Não
Aux 4 Log.A. 2 Gate 4 AND 1 P2 Log.A. 1 Gate 34 2 Não
Aux 5 Log.A. 2 Gate 5 AND 1 P1 Log.A. 1 Gate 1 3 Não
Aux 6 Log.A. 2 Gate 6 AND 1 P2 Log.A. 1 Gate 2 3 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:
Capítulo 5 – Implementação de Redes de Petri em DEIs
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
0 Lógica Auxiliar 1 Gate 33 Lógica Auxiliar 1 0->1
0 Lógica Auxiliar 2 Gate 2 Lógica Auxiliar 2 0->1
0 Lógica Auxiliar 2 Gate 5 Lógica Auxiliar 2 0->1
10 Lógica Auxiliar 1 Gate 49 Lógica Auxiliar 1 1->0
20 Lógica Auxiliar 1 Gate 35 Lógica Auxiliar 1 0->1
20 Lógica Auxiliar 2 Gate 3 Lógica Auxiliar 2 0->1
20 Lógica Auxiliar 1 Gate 34 Lógica Auxiliar 1 0->1
Capítulo 5 – Implementação de Redes de Petri em DEIs
Página | 39
20 Lógica Auxiliar 2 Gate 2 Lógica Auxiliar 2 1->0
20 Lógica Auxiliar 2 Gate 6 Lógica Auxiliar 2 0->1
20 Lógica Auxiliar 2 Gate 5 Lógica Auxiliar 2 1->0
20 Lógica Auxiliar 1 Gate 33 Lógica Auxiliar 1 1->0
20 Lógica Auxiliar 2 Gate 3 Lógica Auxiliar 2 1->0
20 Lógica Auxiliar 2 Gate 4 Lógica Auxiliar 2 0->1
30 Lógica Auxiliar 1 Gate 35 Lógica Auxiliar 1 1->0
40 Lógica Auxiliar 1 Gate 36 Lógica Auxiliar 1 0->1
40 Lógica Auxiliar 2 Gate 1 Lógica Auxiliar 2 0->1
40 Lógica Auxiliar 1 Gate 33 Lógica Auxiliar 1 0->1
40 Lógica Auxiliar 2 Gate 4 Lógica Auxiliar 2 1->0
40 Lógica Auxiliar 2 Gate 5 Lógica Auxiliar 2 0->1
40 Lógica Auxiliar 2 Gate 6 Lógica Auxiliar 2 1->0
40 Lógica Auxiliar 1 Gate 34 Lógica Auxiliar 1 1->0
40 Lógica Auxiliar 2 Gate 1 Lógica Auxiliar 2 1->0
40 Lógica Auxiliar 2 Gate 2 Lógica Auxiliar 2 0->1
50 Lógica Auxiliar 1 Gate 36 Lógica Auxiliar 1 1->0
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
10 Lógica Auxiliar 1 Gate 49 Lógica Auxiliar 1 1->0
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
Capítulo 5 – Implementação de Redes de Petri em DEIs
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.
Capítulo 5 – Implementação de Redes de Petri em DEIs
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
Capítulo 5 – Implementação de Redes de Petri em DEIs
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:
Capítulo 5 – Implementação de Redes de Petri em DEIs
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).
Capítulo 5 – Implementação de Redes de Petri em DEIs
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
Capítulo 5 – Implementação de Redes de Petri em DEIs
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:
Capítulo 5 – Implementação de Redes de Petri em DEIs
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.
Capítulo 5 – Implementação de Redes de Petri em DEIs
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
Não há alteração da
marcação da Rede
4 F3 Realizar marcação inicial
da rede
Led 1 – ON
Led 2 – OFF
Marcação do Lugar P1
Capítulo 5 – Implementação de Redes de Petri em DEIs
Página | 48
5 F2 Verificar manutenção da
marcação (T2 não dispará-
vel)
Led 1 – ON
Led 2 – OFF
Não há alteração da
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
Não há alteração da
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
Capítulo 6 – Implementação Centralizada
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.
Capítulo 6 – Implementação Centralizada
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
Capítulo 6 – Implementação Centralizada
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-
Capítulo 6 – Implementação Centralizada
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.
Capítulo 6 – Implementação Centralizada
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.
Capítulo 6 – Implementação Centralizada
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.
Capítulo 6 – Implementação Centralizada
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]
Capítulo 6 – Implementação Centralizada
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.
Capítulo 6 – Implementação Centralizada
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-
Capítulo 6 – Implementação Centralizada
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.
Capítulo 6 – Implementação Centralizada
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;
Capítulo 6 – Implementação Centralizada
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
Capítulo 6 – Implementação Centralizada
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:
a. Seleccionar (não editar), no Menu de Dispositivos, o componente Application;
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:
Capítulo 6 – Implementação Centralizada
Página | 63
a. Seleccionar (não editar), no Menu de Dispositivos, o componente Application;
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.
Capítulo 6 – Implementação Centralizada
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;
Capítulo 6 – Implementação Centralizada
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
Capítulo 6 – Implementação Centralizada
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.
Capítulo 6 – Implementação Centralizada
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
Capítulo 6 – Implementação Centralizada
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;
Capítulo 6 – Implementação Centralizada
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
Capítulo 7 – Teste do Sistema em Ambiente Laboratorial
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
Capítulo 7 – Teste do Sistema em Ambiente Laboratorial
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.
Capítulo 7 – Teste do Sistema em Ambiente Laboratorial
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
Capítulo 7 – Teste do Sistema em Ambiente Laboratorial
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.
Capítulo 7 – Teste do Sistema em Ambiente Laboratorial
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
Referências Bibliográficas
[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;
Referências Bibliográficas
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 Marcação de Pi está inactiva, logo o lugar não está forçado a estar activo;
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 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 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.