FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

IDE Eclipse para as linguagens deprogramação da norma IEC 61131

(Versão 1.0)

Filipe Miguel de Jesus Ramosee99033@fe.up.pt

MIEECPreparação da Dissertação

Supervisor: Mário Jorge Rodrigues de Sousa (Prof. Dr.)

Controlo de Revisão

Versão Data Secções Afetadas Descrição0.1 12/12/12 Todas Escrita do primeiro esboço.0.2 23/12/12 Todas Escrita do segundo esboço.0.3 08/04/13 Todas Escrita do terceiro esboço.0.4 12/05/13 Análise de Requisitos Escrita do primeiro esboço.0.5 20/05/13 Análise de Requisitos Escrita do segundo esboço.

Todas Correções menores.

1.0 02/07/13 Análise de RequisitosInserção de imagens e alteração donome para Objetivos Específicos.

CalendarizaçãoEscrita e alteração do nome para

Conclusões.

Todas Correções menores.

i

Conteúdo

1 Contexto 11.1 PLC’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 IEC 61131-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Ferramentas Open Source Existentes . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Estado da Arte 32.1 A norma IEC 61131-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 POU’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 Structured Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3 Instruction List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.4 Function Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.5 Ladder Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.6 Sequential Function Chart . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.7 Elementos de configuração . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.8 Tipos de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 IDE’s para IEC 61131-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.1 Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1.1 Beremiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.1.2 4DIAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.2 Comerciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2.1 CoDeSys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2.2 ISaGRAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.2.3 Unity Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1 Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.2 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.3 Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.4 Extension Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Objetivos Específicos 143.1 Integração com o Compilador MATIEC . . . . . . . . . . . . . . . . . . . . . . 143.2 Gravação em XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Editores Textuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3.1 Sintax Highlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4 Editores Gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4.1 Editor de Variáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.2 Editor de POU’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

ii

CONTEÚDO iii

3.5 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5.1 Lista de Tipos de Variáveis . . . . . . . . . . . . . . . . . . . . . . . . . 173.5.2 Lista de POU’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5.3 Caixa de Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.5.4 Árvore de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.5.5 Code Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Conclusões 194.1 Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Calendarização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Lista de Figuras

1.1 Exemplo de um PLC (Siemens Simatic S7 400). . . . . . . . . . . . . . . . . . . 1

2.1 Exemplo de um programa em FBD. . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Exemplo de um programa em LD. . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Exemplo de um programa em SFC. . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Janela do Beremiz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 Um Function Block na norma IEC 61499. . . . . . . . . . . . . . . . . . . . . . 82.6 Janela do 4DIAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.7 Janela do CoDeSys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.8 Janela do ISaGRAF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.9 Diagrama SAMA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.10 Janela do Unity Pro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.11 Janela do Eclipse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.12 Organização do Workbench Eclipse. . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Sintax Highlight. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Exemplo de um editor de variáveis (Beremiz). . . . . . . . . . . . . . . . . . . . 163.3 Exemplo de como será o editor de POU’s (retirado do Beremiz). . . . . . . . . . 163.4 Exemplo de uma lista de tipos de variáveis (Beremiz). . . . . . . . . . . . . . . . 173.5 Exemplo de uma árvore de projeto (Beremiz). . . . . . . . . . . . . . . . . . . . 183.6 Exemplo de uma view de code outline (Eclipse). . . . . . . . . . . . . . . . . . . 18

4.1 Esquema da janela do IDE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Diagrama de Gantt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

iv

Abreviaturas e Símbolos

ANSI American National Standards InstituteCLP Controladores Lógicos ProgramáveisCP Controladores ProgramáveisFB Function BlockFBD Function Block DiagramIDE Integrated Development EnvironmentIEC International Electrotechnical CommissionIL Instruction ListLD Ladder DiagramPC Personal ComputerPLC Programmable Logic ControllerPOU Program Organization UnitSAMA Scientific Apparatus Makers AssociationSFC Sequential Function ChartST Structured TextUDT User Defined TypesUML Unified Modeling LanguageXML eXtensible Markup Language

v

Capítulo 1

Contexto

1.1 PLC’s

Um Controlador Lógico Programável (PLC) é um computador digital usado em aplicações

industriais para automação de sistemas eletromecânicos (e.g., linhas de montagem automóvel),

construído por forma a suportar elevadas variações de temperatura, ruído elétrico, vibrações e

impactos (Figura 1.1). A programação dos PLC’s é feita pelo utilizador, e os programas ficam

guardados numa memória não volátil. Recebe nas entradas sinais de sensores que são logicamente

combinados de forma a gerar sinais de saída para controlar atuadores. Atualmente os PLC’s podem

ser ligados a uma rede e programados remotamente. Pupo [2002]

Figura 1.1: Exemplo de um PLC (Siemens Simatic S7 400).

De forma a diminuir o esforço dos programadores e aumentar a interoperabilidade dos mesmos

(e respetivos programas), foi preciso padronizar protocolos e linguagens de programação para os

PLC’s. Foi nesse sentido que em 1990 a International Electrotechnical Commission criou a norma

IEC 61131. IEC [2003]

1

Contexto 2

Embora tenha sido lançada recentemente a terceira edição da norma (fevereiro de 2013), no

nosso projeto vamos continuar a referir a segunda edição, pois as alterações introduzidas não se

enquadram no âmbito do projeto.

1.2 IEC 61131-3

A norma IEC 61131 está dividida em oito partes, cada uma sumariza os requisitos de hardware

e de programação de PLC’s modernos. Mais especificamente, a parte três da norma (IEC 61131-3)

é um guia para a programação de PLC’s, unificando as várias linguagens de programação utilizadas

por todo o mundo, e orientando-as para uma evolução futura. John and Tiegelkamp [2001]

Na norma IEC 61131-3 são definidas duas linguagens de programação textuais: Structured

Text (ST) e Instruction List (IL); e três gráficas: Function Block Diagram (FBD), Ladder Diagram

(LD) e Sequential Function Chart1 (SFC). Sousa [2011] Na Secção 2.1.2 serão abordadas com

maior detalhe.

Embora tenha demorado algum tempo, a norma acabou por ser largamente adotada, possi-

bilitando a diferentes programadores de diferentes empresas a combinação de componentes de

programas e a reutilização de software de alto nível.

1.3 Ferramentas Open Source Existentes

De modo a facilitar a escrita de programas foram criados vários IDE’s, alguns deles Open

Source. São o caso do 4DIAC e do Beremiz.

Estes programas vieram preencher uma lacuna importante, mas nenhum deles permite uma

utilização satisfatória. Os editores das linguagens gráficas contêm bastantes lacunas, muitas das

vezes dificultando o desenho e a legibilidade dos programas. Durante o desenvolvimento de gran-

des projetos, com programas longos e complexos, os IDE’s tornam-se lentos e não responsivos.

O programa a desenvolver poderia basear-se em um ou mais dos IDE’s Open Source existentes,

mas dados estes e outros problemas, optou-se pela programação de um IDE de raiz.

1.4 Objetivo

A dissertação a ser preparada tem como objetivo a elaboração de um IDE Open Source para

IEC 61131-3. Esse IDE deve ser incorporado na ferramenta de desenvolvimento Eclipse, e deve

suportar tanto as linguagens textuais como as gráficas.

O IDE deve conter editores textuais e gráficos, sendo que estes últimos devem ser completos

e fáceis de usar.

1A SFC não é estritamente um linguagem de programação, uma vez que nenhum programa pode ser escrito em SFCsem que sejam usados blocos de uma ou mais das outras linguagens de programação. Serve primeiramente para definirmáquinas de estado. Tisserant et al. [2007]

Capítulo 2

Estado da Arte

2.1 A norma IEC 61131-3

A norma IEC 61131-3 define o que são Unidades de Organização de Programas (Program

Organization Units — POU), especifica cinco linguagens de programação (Structured Text, Ins-

truction List, Function Block Diagram, Ladder Diagram e Sequencial Function Chart), os tipos

de dados que podem ser usados e vários elementos de configuração. Segue-se uma breve descrição

de cada.

2.1.1 POU’s

A norma IEC 61131-3 incentiva o desenvolvimento estruturado de programas permitindo que

um programa seja dividido em elementos funcionais (POU’s) que podem ser de quatro tipos:

Programas, Funções, Blocos Funcionais (Function Block — FB) e Configurações. Os POU’s

podem ser reutilizados e escritos em mais do que uma linguagem.

O POU de mais alto nível é o Programa. Pode ser escrito em qualquer das linguagens da

norma. Pode conter Funções e Blocos Funcionais, mas não outros Programas.

Uma Função é um bloco de código que pode ser chamado em várias partes de um programa,

à imagem do que acontece com as funções da linguagem C, mas ao contrário destas, não permite

recursão, e é mais limitada no que respeita aos parâmetros de entrada e saída. Não podem ser

escritas em SFC (ver Secção 2.1.6).

Um FB é muito parecido com uma Função, mas com duas propriedades adicionais: pode

conter variáveis persistentes e pode ser escrito em SFC. Para além disso existe uma diferença

fundamental: ao passo que as funções são chamadas diretamente, um FB tem de ser instanciado

primeiro (mas não pode ser instanciado dentro de uma Função). Comporta-se como uma classe de

uma linguagem de programação de alto nível (embora com algumas limitações), permitindo criar

estruturas de dados complexas, e abrindo portas à programação orientada a objectos.

Uma Configuração reúne toda a informação necessária do estado exato que queremos para

o software a ser descarregado para o PLC (e.g., definição de variáveis, agendamento de tarefas,

etc.) Sousa [2011]

3

Estado da Arte 4

Dentro dos POU’s podem ser usadas variáveis de vários tipos (ver Secção 2.1.8), e que podem

ser declaradas usando diferentes palavras chave, conferindo-lhes diferentes propriedades. Segue-

se uma lista com a descrição das palavras chave usadas na declaração de variáveis:

◦ VAR: variável interna de um POU;

◦ VAR_INPUT: variável fornecido ao POU por entidades externas;

◦ VAR_OUTPUT: variável fornecida pelo POU a entidades externas;

◦ VAR_IN_OUT: variável que pode cumprir o papel de ambas as anteriores;

◦ VAR_GLOBAL: variável global;

◦ VAR_EXTERNAL: variável proveniente de uma Configuração (onde é declarada como

VAR_GLOBAL). Pode ser modificada dentro do POU;

◦ VAR_ACCESS: contém o registo do Caminho de Acesso (apenas usada em Configurações

— ver Secção 2.1.7).

◦ VAR_TEMP: variável internas de um FB (só existem durante a sua execução).

Cada POU começa com uma keyword que identifica do seu tipo(e.g., FUNCTION_BLOCK).

Segue-se a declaração das variáveis agrupadas por blocos de diferentes tipos, cada um identificado

por uma keyword específica das mostradas acima. De seguida vem o corpo do POU, onde é

feita a programação. Finalmente o POU termina com a keyword complementar daquela com que

começou (e.g., END_FUNCTION_BLOCK).

2.1.2 Structured Text

A ST é uma linguagem de alto nível, sintaticamente parecida com Pascal1. É estruturada por

blocos e suporta declarações complexas como IF. . .THEN. . .ELSE e WHILE. . .DO.

Exemplo:

Txt := TXTS[Estado];

CASE Estado OF

1: Fechar();

ELSE

Erro();

END_CASE;

1De facto, é baseada em Pascal.

2.1 A norma IEC 61131-3 5

2.1.3 Instruction List

Ao contrário da ST, a IL é uma linguagem de baixo nível, muito parecida com assembly. As

instruções são executadas uma por linha, e podem ser usadas chamadas a funções e jumps para

controlo de fluxo.

Exemplo:

LD Velocidade

GT 120

JMPCN ACE_OK

LD Acel

ACE_OK LD 1

ST %Q75

2.1.4 Function Block Diagram

Tal como o nome indica, um FBD é um diagrama de blocos que descreve uma função (ou a

instância de um FB) entre variáveis de entrada e de saída. Usa blocos elementares (que represen-

tam funções ou instâncias de um FB) conectados por linhas orientadas que transportam os dados.

Em qualquer bloco as entradas encontram-se sempre do lado esquerdo e as saídas do lado direito.

Um diagrama exemplo pode ser visto na Figura 2.1.

Figura 2.1: Exemplo de um programa em FBD.

2.1.5 Ladder Diagram

A linguagem LD tem uma semelhança aparente com diagramas de circuitos elétricos com re-

lés. Usa interruptores e bobines inseridos num percurso onde circula corrente elétrica, da esquerda

para a direita. Tem duas colunas verticais, uma de cada lado, onde se podem ligar os circuitos.

Cada bobine do LD representa um bit no PLC. Um contacto pode representar um interruptor real,

ou um estado do PLC. Um exemplo de um programa em LD pode ser visto na Figura 2.2.

2.1.6 Sequential Function Chart

Os diagramas SFC são baseados na linguagem GRAFCET — um tipo particular de máquina

de estados. Neles são representados os passos dados no decorrer da execução do programa. Cada

passo representa um estado, e a cada estado estão associadas ações que se executam quando o

Estado da Arte 6

Figura 2.2: Exemplo de um programa em LD.

estado fica ativo. A passagem entre diferentes estados dá-se quando determinadas condições são

satisfeitas. As ações podem ser escritas numa qualquer das linguagens da norma. A execução do

programa em SFC ocorre de cima para baixo, e pode divergir em ramos paralelos que se ativam

simultaneamente (linha dupla) ou em ramos paralelos dos quais apenas um pode ficar ativo (linha

simples). Um exemplo de um programa em SFC pode ser visto na Figura 2.3.

Figura 2.3: Exemplo de um programa em SFC.

2.1.7 Elementos de configuração

Uma configuração serve para definir parâmetros iniciais, e para criar as primeiras instâncias de

POU’s. Estão estruturados em Recursos (normalmente um por cada unidade de processamento).

Dentro de cada recurso podem existir várias Tarefas, que podem executar POU’s de forma perió-

dica, time triggered, event triggered, ou apenas uma vez. Podem também ser definidas variáveis

globais e Caminhos de Acesso. Os Caminhos de Acesso permitem que um utilizador aceda re-

motamente a variáveis locais — é criado um caminho único que permite a ligação à variável em

questão.

2.2 IDE’s para IEC 61131-3 7

2.1.8 Tipos de Dados

A norma IEC 61131-3 define vários tipos de dados para uso na programação dos diferentes

POU’s. Segue-se uma lista dos principais tipos:

◦ Inteiros: permite vários tipos de inteiros, desde o Short Integer — SINT (8 bit) ao Unsigned

Long Integer — ULINT (64 bit);

◦ Reais: Real — REAL (32 bit) ou Long Real — LREAL (64 bit);

◦ Tipos orientados ao Bit: desde o Boolean — BOOL (1 bit) ao Long Word — LWORD

(64 bit);

◦ Strings: String — STRING (com carateres de 8 bit) ou Wide String — WSTRING (com

carateres de 16 bit);

◦ Tempo e Data: permite vários formatos, como TIME (durações temporais) ou DATE (dia,

mês e ano);

◦ Sub Ranges: define um intervalo de valores para dada variável;

◦ Tipos de dados derivados: permite criar novos tipos de dados baseados nos anteriores.

– Vetores: contém vários elementos de um qualquer tipo de dados dos anteriores;

– Estruturas: agrupamentos de vários outros tipos de dados;

– Enumerações: um tipo de variável que pode tomar apenas os valores enumerados;

2.2 IDE’s para IEC 61131-3

O mundo dos PLC’s pode ser dividido em dois: de um lado existem os PLC’s físicos (tais

como os Allen Bradley, Siemens — ver Figura 1.1, Omron, Schneider, Faruc, etc.), do outro lado

os softPLC, que não são mais que um software que correm em PC’s e que permite emular as

funcionalidades de um PLC físico. Alguns dos softPLC existentes são o SoftPLC, o CoDeSys e o

ISaGRAF.

Dos IDE’s que permitem a programação de softPLC’s existem vários compatíveis com as

linguagens IEC 61131-3. Alguns são Open Source, outros Comerciais. Para a elaboração deste

documento foram testados os principais de ambas as categorias. Segue-se uma breve descrição de

cada, indicando quais os pontos fortes e fracos de cada um.

2.2.1 Open Source

2.2.1.1 Beremiz

Beremiz é o resultado de um esforço conjunto da empresa LOLITECH, sediada em Saint-Dié-

des-Vosges, França, com a Universidade do Porto. Tem como base, entre outros, o compilador

MatIEC e o editor gráfico PLCopen editor. (Ver Figura 2.4.)

Estado da Arte 8

O facto de ser programado em Python pode diminuir a sua performance em algumas circuns-

tancias, potencia alguma dificuldade na sua manutenção e possibilita o aparecimento de bugs

facilmente evitáveis noutras linguagens (principalmente relacionados com a declaração de variá-

veis).

Ao editor gráfico, também escrito em Python faltam algumas características básicas (e.g., de-

vido à dificuldade em alinhar blocos o resultado é visualmente desagradável).

Este IDE apresenta alguns blocos relevantes para o nosso projeto, como uma toolbox com os

elementos gráficos passíveis de serem integrados nos editores, e um editor de variáveis.

Figura 2.4: Janela do Beremiz.

2.2.1.2 4DIAC

O IDE 4DIAC tem como base a framework Eclipse (ver Secção 2.3), e tem como objetivo

principal a criação de aplicações compatíveis com a norma IEC 61499. Pode ver o software na

Figura 2.6.

A norma IEC 61499 centra-se nos seus FB’s muito específicos. Como se pode ver na Fi-

gura 2.5, cada FB da norma tem dois grupos distintos de entradas/saídas: eventos e dados. Quando

um evento é ativado na entrada, o código do programa correspondente é executado, tirando partido

das entradas de dados associadas com o evento. O programa, depois de executado, coloca dados

nas respetivas saídas de dados, e o evento correspondente é ativado na saída.

Figura 2.5: Um Function Block na norma IEC 61499.

2.2 IDE’s para IEC 61131-3 9

Não tendo como foco principal a programação nas linguagens IEC 61131-3, não se mostra

verdadeiramente como uma alternativa ao software pretendido, e embora fosse possível expandir

o IDE 4DIAC de modo a suportar as linguagens IEC 61131-3, optamos por criar um IDE indepen-

dente, mas tendo em vista uma possível integração futura, dados que os FB do IEC 61499 podem

ser programados usando as linguagens IEC 61131-3.

Figura 2.6: Janela do 4DIAC.

2.2.2 Comerciais

De forma a poderem ser usados sem limitações é necessário pagar pelos IDE’s comerciais. Na

sua maioria têm também a desvantagem de suportarem linguagens de programação não definidas

pela norma IEC 61131-3, o que impossibilita a combinação de componentes de programas e a

reutilização de software de alto nível.

Testámos vários IDE’s comerciais de forma a perceber melhor quais as características a im-

plementar no nosso IDE.

2.2.2.1 CoDeSys

O CoDeSys é desenvolvido e comercializado pela empresa de software alemã 3S-Smart Soft-

ware Solutions desde 1994. (Ver Figura 2.7.) Suporta todas as linguagens IEC 61131-3, bem como

uma linguagem gráfica própria, de nome Continuous Function Chart, muito próxima da FBD, mas

oferecendo mais liberdade ao utilizador. Integra também suporte para a linguagem UML e permite

integração de sistemas de controlo de versão.

Neste IDE destaca-se o bloco com a árvore do projeto e os seus componentes. Permite uma

fácil leitura de todos os ficheiros que integram o projeto e facilita a sua edição. Esta funciona-

lidade parece relevante para o nosso projeto, e por isso temos em vista a criação de um módulo

semelhante.

Estado da Arte 10

Figura 2.7: Janela do CoDeSys.

2.2.2.2 ISaGRAF

O ISaGRAF é um IDE desenvolvido pela companhia Rockwell Automation, sediada nos Es-

tados Unidos da América, e é baseado no Microsoft R© Visual Studio R©. Também suporta todas

as linguagens definidas pela norma IEC 61131-3, e tal como o IDE 4DIAC, também suporta as

linguagens da norma IEC 61131-3. Para além destas suporta também a construção de diagramas

SAMA2 (Figura 2.9). Tal como o IDE CoDeSys, também suporta sistemas de controlo de versão.

Pode ver o software na Figura 2.8.

Figura 2.8: Janela do ISaGRAF.

2Diagramas usados na indústria da energia para implementação de estratégias de controlo. Foca-se no fluxo deinformação dentro do sistema ao invés da interconetividade dos processos.

2.3 Eclipse 11

Figura 2.9: Diagrama SAMA.

2.2.2.3 Unity Pro

O Unity Pro é desenvolvido pela companhia francesa Schneider Electric (ver Figura 2.10).

Tal como os anteriores, suporta na íntegra as linguagens definidas pela norma IEC 61131-3, bem

como a linguagem 984 LL (984 Ladder logic) para PLC’s Modicon.

Dos IDE’s testados é aquele que apresenta uma curva de aprendizagem mais elevada, e um

user interface menos intuitivo.

Figura 2.10: Janela do Unity Pro.

2.3 Eclipse

O Eclipse (ver Figura 2.11) é um IDE Open Source concebido primeiramente com o intuito do

desenvolvido de programas em Java. Foi criado pela IBM que o doou à comunidade de software

livre. Rapidamente se tornou a primeira escolha de muitos utilizadores, e tem vindo a crescer desde

Estado da Arte 12

então. É altamente configurável e permite a criação de novos módulos programados em Java que

comunicam entre si e com o workbench (Secção 2.3.1) através de extension points (Secção 2.3.4).

Existem duas categorias de módulos: views (Secção 2.3.2) e editors (Secção 2.3.3).

Através da utilização de módulos, o Eclipse pode usar-se não só para programar em Java, mas

também em muitas outras linguagens de programação. O nosso projeto criará um conjunto de

módulos que possibilitem a programação das linguagens IEC 61131-3.

Figura 2.11: Janela do Eclipse.

2.3.1 Workbench

Ao iniciar o IDE Eclipse apresenta-se-nos a bancada de trabalho (Workbench), onde estão pre-

sentes vários módulos que se podem combinar de várias formas para criar uma perspective. Cada

perspective define a forma como os módulos estão dispostos no ecrã, bem como quais os módu-

los a apresentar. Cada utilizador pode criar e gravar várias perspectives para uso em diferentes

contextos. Pode ver-se na Figura 2.12 a organização descrita.

O Eclipse apresenta um bloco de code outline que permite ver as principais secções do código

escrito e aceder-lhes rapidamente. Esta funcionalidade parece relevante para o nosso projeto, e

por isso iremos tentar a sua integração.

2.3.2 Views

Os views são módulos cuja principal tarefa é mostrar informação (e.g., uma view onde apare-

cem todos os ficheiros de uma dada pasta.) Serve também para mostrar propriedades de recursos

abertos no sistema, como por exemplo as propriedades de determinado POU ou de determinado

projeto.

No nosso projeto vão ser necessários vários views, pois serão utilizados diversos tipos de

recursos, e um view parece ser a forma mais fácil e rápida de editar as suas propriedades.

2.3 Eclipse 13

Figura 2.12: Organização do Workbench Eclipse.

2.3.3 Editors

Os editors são módulos que possibilitam a edição de ficheiros e outros recursos do sistema

(e.g., um editor textual, ou um editor gráfico.) Podem estar associados a tipos específicos de

ficheiros, de modo que ao selecionar um ficheiro, o Eclipse sabe exatamente qual o editor a usar.

Para o nosso projeto vão ser necessários editors para as várias linguagens de programação,

incluindo editors para as linguagens gráficas.

2.3.4 Extension Points

Os extension points são pontos de comunicação entre módulos, e entre os módulos e o work-

bench Eclipse. São descritos e configurados em ficheiros XML. O Eclipse fornece alguns extension

points de raiz, porem outros podem ser definidos pelos módulos criados pelo utilizador.

Exemplos de alguns extension points que o Eclipse apresenta e que podem são de interesse

para o nosso projeto são o editors, onde se irão ligar os módulos com o mesmo nome, o viewer,

onde se ligam os views, e o menus, onse se ligam módulos que definem menus.

Capítulo 3

Objetivos Específicos

3.1 Integração com o Compilador MATIEC

O MATIEC é um compilador open source para a norma IEC 61131-3, que suporta as lingua-

gens para as quais existem representações textuais (Instructtion List, Structured Text e Sequential

Function Chart).

O desenvolvimento do compilador MATIEC (MatPLC’s IEC compiler)1 é coordenado pelo

Prof. Dr. Mário Jorge Rodrigues De Sousa, é distribuído sob a licença GPL e é usado por diversas

empresas, bem como pelo projeto Beremiz (ver Secção 2.2.1.1).

Do projeto MATIEC fazem parte dois tradutores de código: o iec2iec traduz código escrito

nas linguagens IEC 61131-3 para código escrito na mesma linguagem (serve primeiramente para

debug), o iec2c traduz código IEC 61131-3 para código na linguagem de programação ANSI C.

Um dos requisitos do nosso projeto é a integração com o compilador MATIEC, e deve por isso

converter os projetos feitos em Instructtion List, Structured Text e Sequential Function Chart em

ficheiros de texto compatíveis com a norma IEC 61131-3.

3.2 Gravação em XML

Para uma maior facilidade e versatilidade, e de modo a que possam ser guardados, para além

do código das linguagens, todos os metadados necessários para as linguagens gráficas (e outros

dados que possam ser necessários), os projetos vão ser guardados em ficheiros XML. A utilização

de XML permite também uma maior facilidade de debugging pois os ficheiros são humanamente

legíveis.

Com o intuito de criar um XML padrão para as linguagens IEC-61131-3 foi criado o grupo de

trabalho TC6 for XML, que definiu um interface entre todos os software que permite a transferência

de toda a informação relevante de um projeto criado por um certo software para outro qualquer

1O MatPLC é um softPLC que corre em linux (também sob a licença GPL) e que prima pela sua organizaçãomodular que permite a criação de módulos por terceiros e a sua integração conjunta num único interface de utilizador.

14

3.3 Editores Textuais 15

software. Esse XML padrão é o PLCopen XML, e encontra-se já na segunda edição (dezembro de

2008).

3.3 Editores Textuais

O desenvolvimento de projetos nas linguagens textuais vai ser possível através da utilização de

editores textuais. Vão ser criados editores textuais para todas as linguagens para as quais existem

representações textuais (Instructtion List, Structured Text e Sequential Function Chart).

3.3.1 Sintax Highlight

A sintax highlight permite colorir de forma diferente pedaços de código com significados

distintos: comentários, variáveis, etc. (Ver Figura 3.1) É uma das principais características de um

editor profissional, permitindo uma melhor leitura do código, e facilitando a deteção de erros.

A sintax highlight no Eclipse funciona da seguinte maneira: de cada vez que é detetada uma

alteração no documento (e.g., o utilizador escreveu algo), é executado o Document Partitioner que

divide o código em partições segundo regras definidas pelo utilizador. De seguida é executado o

Presentation Reconciler que vai analizar a partição do documento que foi alterada e que por sua

vez chama os Presentation Damager e Presentation Repairer que calculam a extensão do “dano”

feito ao documento e fazem a respetiva coloração.

Figura 3.1: Sintax Highlight.

3.4 Editores Gráficos

Para a programação das linguagens gráficas será necessária a criação de editores gráficos. O

IDE Eclipse permite a criação destes editores recorrendo às ferramentas Eclipse Modeling Fra-

mework (EMF) e Graphical Editing Framework (GEF).

Objetivos Específicos 16

O EMF permite a criação de modelos (e.g., através de modelos de classes UML) e fornece

ferramentas para a criação de classes que os implementem, assim como um conjunto de classes

que permitem a sua edição e visualização. O GEF possibilita a edição e visualização de forma

gráfica de modelos criados com EMF.

Para o nosso IDE será necessária a criação de modelos EMF para as linguagens gráficas de

modo a serem representados e editados usando o GEF.

Para além dos editores gráficos para as linguagens visuais, serão necessários outros editores

mais simples descritos nas secções seguintes.

3.4.1 Editor de Variáveis

O editor de variáveis mostrará uma listagem de todas as variáveis no projeto e as respetivas

propriedades, permitindo a sua fácil alteração. Pode ver um exemplo de um editor deste tipo na

Figura 3.2.

Figura 3.2: Exemplo de um editor de variáveis (Beremiz).

3.4.2 Editor de POU’s

O editor de POU’s mostra as propriedade de um POU específico, permitindo que o utilizador

faça a sua edição de forma rápida. O POU cujas propriedades se quer editar pode ser selecionado

usando a respetiva view (ver Secção 3.5.2.) Pode ver um exemplo de como será o editor de POU’s

na Figura 3.3.

Figura 3.3: Exemplo de como será o editor de POU’s (retirado do Beremiz).

3.5 Views 17

3.5 Views

Tal como dito anteriormente, uma view serve para mostrar informação sobre recursos no sis-

tema. Vamos precisar de vários módulos do tipo view no nosso projeto: para visualizar os tipos

de variáveis, para listar os POU’s no projeto, uma caixa de ferramentas gráficas, uma árvore de

projeto e uma view com o code outline.

3.5.1 Lista de Tipos de Variáveis

Esta view servirá para mostrar uma listagem de todos os tipos de variáveis presentes nas lingua-

gens do projeto (ver Secção 2.1.8.) Para além da visualização será também possível a incorporação

no código de variáveis desses tipos (através de um duplo clique). Pode ver como uma lista de tipos

de variáveis na Figura 3.4.

Figura 3.4: Exemplo de uma lista de tipos de variáveis (Beremiz).

3.5.2 Lista de POU’s

A view de POU’s, tal como a view de tipos de variáveis, mostrará uma listagem dos POU’s

existentes no projeto. Será possível abrir o POU selecionado ou editar as suas propriedades (ver

Secção 3.4.2.)

Objetivos Específicos 18

3.5.3 Caixa de Ferramentas

Esta view servirá para integração com os editores visuais e mostrará uma listagem dos blocos

gráficos que podem ser utilizados em cada linguagem. O utilizador selecionará nesta view o bloco

que quererá inserir e o IDE incorporará um objeto gráfico desse tipo no respetivo editor.

3.5.4 Árvore de Projeto

Nesta view estarão listados todos os ficheiros que fazem parte do projeto atual, facilitando a

abertura para edição de qualquer um deles usando os respetivos editores (ver Secções 3.3 e 3.4.)

Pode ver um exemplo de uma árvore de projeto na Figura 3.5.

Figura 3.5: Exemplo de uma árvore de projeto (Beremiz).

3.5.5 Code Outline

Na view de code outline será apresentada um vista em grosso do código a ser editado: as

variáveis usadas, os POU’s, etc. O utilizador poderá facilmente deslocar-se pelo código utilizando

esta view, o que será especialmente útil em programas de grande dimensão. Pode ver um exemplo

de uma view de code outline na Figura 3.6.

Figura 3.6: Exemplo de uma view de code outline (Eclipse).

Capítulo 4

Conclusões

Descreve-se de seguida a proposta de trabalho, que tem em conta todos os objetivos descritos,

bem como uma organização que permita uma fácil utilização pelo utilizador final.

4.1 Proposta

A janela principal do IDE deverá apresentar um esquema semelhante ao da Figura 4.1: a view

com a árvore do projeto deverá ficar junto a à margem esquerda (ver número 1 da Figura 4.1). Por

baixo da mesma ficará a view com o code outline (ver número 2 da Figura 4.1). Ao centro, e a

ocupar a maior parte da janela ficarão os editores textuais e gráficos (ver número 3 da Figura 4.1): o

utilizador poderá escolher qual o que estará ativo através de um sistemas de tabs (ver número 4 da

Figura 4.1). Por fim, junto à margem direita da janela ficará a caixa de ferramentas (ver número 5

da Figura 4.1).

As outras views (e.g., lista de variáveis) poderão ser ativadas através dos menus.

O utilizador final poderá alterar a disposição das janelas, bem como terá a última palavra sobre

quais as que prefere estarem ativas de início, podendo para isso recorrer ao sistema de perspectives

do Eclipse (ver Secção 2.3.1).

Figura 4.1: Esquema da janela do IDE.

19

Conclusões 20

4.2 Calendarização

Tendo em conta a proposta e os objetivos descritos, foi planeada a calendarização que está

sumarizada num diagrama de Gantt (Figura 4.2). As tarefas que se pensa mais morosas são a

programação do primeiro editor textual e do primeiro editor gráfico — os seguintes utilizarão

muito do código criado para o primeiro; bem como a escrita da Dissertação.

Durante os testes e validação, vão ser criados programas completos em todas as linguagens, e

usadas todas as funcionalidades de inserção de variáveis e objetos gráficos. O código gerado pelos

programas será depois processado por um compilador para que se tenha a certeza de estarem de

acordo com a norma IEC 61131.

4.2 Calendarização 21

Figura 4.2: Diagrama de Gantt.

Bibliografia

Programmable controllers: Part 3: Programming languages. Programmable Controllers-Part, 3,

2003.

Karl Heinz John and Michael Tiegelkamp. IEC 61131-3: Programming Industrial Automation

Systems: Concepts and Programming Languages, Requirements for Programming Systems,

Decision-Making Aids. Springer, 2001. ISBN 9783642120145.

Maurício Santos Pupo. Interface homem-máquina para supervisão de um CLP em controle de

processos através de WWW. PhD thesis, Escola de Engenharia de São Carlos da Universidade

de São Paulo, 2002.

Mário de Sousa. Substation Automation Systems - Overview of IEC 61131-3. 2011.

E Tisserant, L Bessard, and Mário de Sousa. An open source IEC 61131-3 integrated development

environment. In 5th IEEE International Conference on Industrial Informatics, pages 183 – 7,

Piscataway, NJ, USA, 2007.

22