Para aproveitar todo o desenvolvimento consumado até ao momento, foi decido beneficiar dos algoritmos já implementados nos controladores e a partir desse ponto desenvolver o novo software de controlo tendo em conta os requisitos exigidos.
Assim sendo, e a partir desse reaproveitamento de algoritmos, pretende-se conceber um software que seja exequível em qualquer PC, que permita gerar relatório produtivos, fazer comparações gráficas entre várias linhas produtivas, verificar o estado atual das linhas e adicionar ou remover linhas de produção no sistema.
Existe uma iminente importância em adicionar ou eliminar linhas de produção, uma vez que os processos industriais na indústria automóvel estão constantemente em alteração, podendo ser considerada hoje a linha necessária, no entanto, amanhã poderá já não o ser.
45 Como o objetivo principal é o controlo remoto das linhas de produção, é necessário detalhar todos os parâmetros atuais de cada linha de produção. Atualmente as indústrias atribuem como dados produtivos de maior importância o objetivo atual, o objetivo total e o que foi produzido.
Criar relatórios com o número total de paragens por linha e/ou por posto com os respetivos motivos irá ajudar o gestor de linha a perceber quais as razões da maioria dos estrangulamentos.
Para aumentar a destreza na gestão de linhas, foram solicitados filtros para efetuar comparações de diversas formas. No software desenvolvido será possível comparar uma linha X com uma linha Y, o posto N da linha X com o posto N da linha Y e completar a comparação com a relação de diferentes referências.
Após algumas reuniões cujo objetivo passaram por perceber se o software reunia toda a informação necessária, foram considerados relevantes os seguintes pontos:
Atribuição de prioridades a todos os utilizadores com as seguintes classificações: Alta, Media, Baixa;
Adicionar ou remover utilizadores;
Comparação dos dados por turnos;
Comparação dos dados por data;
47
5. S
OFTWARE DE CONTROLO
Neste capítulo pretende-se descrever todos os passos que foram necessários para implementação do sistema de SCADA, um sistema que possibilita a monitorização e o controlo remoto de recursos ou aplicações controlados por PLC. A concretização do sistema carece de uma plataforma de comunicação com os PLC que não obrigue a aquisição de hardware ou software adicional, foi realizada uma pesquisa com o objetivo de optar pelo melhor protocolo a usar na comunicação com os CPU. Seguiu-se a implementação de pequenas aplicações para analisar a comunicação, a troca de dados com os recursos e a leitura e escrita da base de dados. Foram desenvolvidas algumas base de dados, com o intuito de determinar qual a estrutura/arquitetura a implementar. Foi criada uma pequena aplicação que funciona como aplicação local para as várias linhas propostas. Todo o trabalho foi desenvolvido numa perspetiva de Round-Trip Engineering, que consiste num misto de Reverse Engineering e Forward Engineering, o que se traduz num trabalho concluído através de pesquisa, projeto e implementação, mas também através de estudo e adaptação de soluções existentes.
5.1. B
ASE DE DADOSA base de dados apresenta-se como uma componente essencial na arquitetura escolhida pois faz a ponte entre PLC e PC para a troca de dados. Com a base de dados torna-se possível a consulta de informação em qualquer momento.
A seleção do sistema de gestão de base de dados mais adequado e compatível com o pretendido mereceu alguma pesquisa, no sentido em que o que se pretende é que a base de dados seja flexível, de fácil integração com o software e com aplicações web de fácil acesso.
Numa primeira pesquisa os sistemas de gestão de bases de dados (SGBD) que se mostraram possíveis para a solução em questão foram o Microsoft Access, Microsoft SQL e o Oracle - sistemas de gestão de bases dados bem conhecidos. Qualquer um dos sistemas de base de dados poderia ser utilizado, no entanto, o objetivo é a utilização de uma base de dados freeware e que não implique encargos com licenças. As SGBD freeware mais apreciadas são o MySQL e a PostgreSQL, sendo o MySQL a mais
48 conhecida e a mais usada em todo o mundo, mesmo em companhias de relevância mundial como por exemplo a NASA. A SGBD MySQL enquadra-se perfeitamente com o pretendido, uma vez que para além de ser freeware possui as características necessárias para o sistema proposto, é muito fácil de integrar numa aplicação e é muito rápida, o que se reflete como uma mais-valia para diminuir o atraso na comunicação de dados entre cliente e servidor.
Entre as características técnicas do SGBD MySQL estão [34]:
• Alta compatibilidade com linguagens como PHP, Java, Python, C#, Ruby e C/C++, VB.Net;
• Portabilidade (suporta praticamente qualquer plataforma atual);
• Baixa exigência de processamento (em comparação como outros SGBD); • Ligação segura, indexação de campos de texto, replicação;
• Instruções em SQL;
• Excelente desempenho e estabilidade;
• Pouco exigente quanto a recursos de hardware; • Facilidade de uso, implementação e integração; • Software livre;
• Interfaces gráficas “MySQL Toolkit” de fácil utilização cedidos pela MySQL Inc.
A base de dados foi dimensionada para possibilitar o armazenamento eficiente dos dados, resultando numa estrutura compreensível e de fácil acesso aos diferentes dados. Com o objetivo de evitar a confusão entre dados de diferentes recursos, no SGBD foram criados esquemas (bases de dados) distintos para cada recurso, o que implica que as tabelas de armazenamento dos dados fiquem agrupadas por esquemas relativos a um recurso em específico.
Na Figura 30 pode ver-se a estrutura da base de dados, com o nome de “bd_final_v_1”, desenvolvida em MySQL para o desenvolvimento da dissertação.
49
Figura 30 - Base de dados utilizada
A disposição da base de dados neste formato permite-nos adicionar mais requisitos assim que for necessário. Outra razão pela qual foi escolhida esta organização passa pela divisão de programas de aplicações criadas no servidor, onde existirá uma aplicação que escreve na tabela “paragem_posto” e “produção” segundo os “id_ip” da tabela “gestao_de_ips”. Os “utilizadores” entram noutra aplicação desenvolvida, que permite a consulta de todos os dados da base de dados. Estas aplicações são descritas em capítulos posteriores.
O esquema da Figura 31 diz respeito á identificação do PLC da linha de produção. A variável “id_ip” é uma variável auto incremental, que incrementa automaticamente sempre que um novo PLC é adicionado. As restantes informações da tabela são detalhes que permitiram a comunicação entre o servidor e o PLC, de tal forma que é obrigatório introduzir na tabela o endereço IP atribuído pela rede (endereço_ip), a porta (porta) e o nome que será atribuído à nova linha de produção (nome_linha). Para segurança do sistema será sempre memorizada na tabela o utilizador que fez o registo de uma nova linha (id_utilizador).
50
Figura 31 - Tabela referente à descrição do PLC
Para todos os recursos ou equipamentos existe um esquema semelhante na SGBD, com as tabelas supra mencionadas, exatamente com a mesma nomenclatura e estrutura. Assim é possível criar uma norma de programação, tornando exequível adaptar ou acrescentar um novo recurso, sendo que no sistema de gestão dos dados a única diferença será o nome do esquema do respetivo ao recurso. Os dados podem desta forma ser organizados por recurso ou equipamento, evitando a perda e a troca de informações. Por outro lado, é importante sublinhar que é sempre possível consultar toda a informação relativa às ações efetuadas com solicitação de aplicações cliente, ou servidor.
5.2. P
LCPor ser o controlador mais utilizado na empresa Pinto e Brasil foi utilizado nesta dissertação o Mitsubishi MELSEC FX3G (Figura 32).
Figura 32 - Mitsubishi MELSEC FX3G
A série FX3G apresenta um PLC de elevada performance num corpo de pequenas dimensões. Muitas aplicações onde a automação nem sequer era opção passaram a beneficiar das várias vantagens deste tipo de controladores. Especialmente vocacionado
51 para pequenas e médias aplicações, o PLC MELSEC FX3G, é utilizado onde o desempenho e a velocidade de processamento são críticos.
Quanto às principais características deste autómato, este apresenta:
128 Pontos de I/O ou 256 I/O usando a rede CClink Remota;
Alimentação: 100/240 VAC (+10% / -15%), 50/60 Hz;
Memória de 32000 Passos/Programa (EEPROM);
Tempo instrução: 0,21 µs;
Entradas: Sink / Source 24V DC (±10 %);
Saídas: Relé ou Transístor;
6 Contadores Rápidos a 60 KHz;
3 Saídas de alta velocidade para posicionamento a 100 kHz.
Os benefícios deste PLC passam pela compatibilidade total com o autómato FX1N, a flexibilidade e a fiabilidade, e o relógio de tempo real integrado. O número de instruções alargado, porta de programação USB integrada e as funções para posicionamento com controlo de 3 eixos complementam as características.
5.2.1. M
ÓDULOFX3U-ENET
O módulo de comunicação FX3U-ENET provê o PLC FX3U com ligação direta Ethernet. Com o módulo instalado no PLC é possível a troca de dados com um sistema de visualização adicional que suporta uma monotorização compreensiva.
O FX3U-ENET suporta comunicação peer-to-peer e o MC Protocol. Permite 8 conexões configuradas facilmente pelo software disponível pela Mitsubishi, FX Configurator-EN (Figura 33).
52
Figura 33 - FX Configurator-EN
Tecnicamente estamos perante um módulo que tem a capacidade de comunicar pelo protocolo TCP/IP e pelo UDP, consequentemente, suporta modos de comunicação em full-duplex / half-duplex. O buffer de comunicação tem a capacidade de 123 words, consegue utilizar mail server SMTP e POP3 e pode enviar frames dos tipos IEEE802.3u ou IEEE802.3.
O conector de comunicação é o RJ45, atinge velocidade na transação de dados à volta dos 100 Mbits/s e em torno dos 10 Mbits/s. Este módulo é alimentado a 24Vdc.
Quanto às configurações dos módulos através do FX Configurator-EN, é necessário definir o módulo referente à expansão, o tipo de comunicação, tipo de protocolo, etc.
Para exemplificar, será usada a configuração referente ao primeiro módulo Ethernet utilizado nesta dissertação.
Tal como diz nas especificações, é possível atribuir 8 módulos de expansão, assim sendo, a primeira configuração passou por atribuir um valor ao módulo que vai de 0 a 7 (Figura 34).
53
Figura 34 - Seleção do módulo Ethernet
O passo seguinte define as Operational Settings, selecionando os tipos de dados que serão utilizados e qual o endereço IP atribuído ao módulo. No caso, foi usado:
1. Comunicação em código ASCII;
2. A frame de dados será do tipo Ethernet;
3. A confirmação de que o módulo está ligado será efetuada por ping; 4. E o endereço IP atribuído pela rede ao autómato será o 192.168.10.99.
Após esta seleção é obrigatório clicar no “End” para que as configurações não sejam perdidas (Figura 35).
54
Figura 35 - Configuração Operational Settings
A Figura 36 mostra o quadro mais importante desta configuração, sendo consumadas neste campo as configurações mais refinadas do módulo. Os pontos 1 e 3 definem o protocolo a usar, TCP ou UDP; neste caso, vamos trabalhar com o protocolo TCP.
As configurações que se seguem descrevem o seguinte: 1. Protocolo TCP;
2. MELSOFT Connection: Permite a ligação por TCP entre o computador de programação e PLC;
3. Protocolo TCP;
4. Unpassive: Mantem o módulo Ethernet sem filtros, tendo uma função semelhante ao ponto 2;
5. Send: Permite o envio de dados;
6. Procedure exist (MC): Seleciona o MC Protocol como comunicação. O MC Protocol permite a comunicação direta entre PLC sem programação Ladder;
7. No Confirm: Como já faz a confirmação de módulo Ethernet por ping, não é necessária esta opção;
55
Figura 36 - Configuração Open Settings
Para verificar a se configuração foi bem sucedida, é possível fazer um ping pela consola de comandos do Windows como é possível contemplar na Figura 37.
Figura 37 - Ping que garante a ligação do PLC configurado
5.2.2. F
RAMES DE LEITURAA vantagem da comunicação Ethernet passa pela quantidade de informação que somos capazes de aceder através de uma única frame. O PLC utilizado para a realização desta dissertação tem a capacidade de enviar dados com um tamanho de 256 bits e 64 words no caso de os dados enviados pelo PLC forem no código ASCII.
56 Contudo, antes de serem enviados dados do PLC para o servidor, o PLC precisa de receber inicialmente uma frame com o pedido dos dados, que poderá atingir um tamanho de 160 bits e no caso do código ASCII um máximo de 64 words.
A resposta entre o módulo Ethernet e o servidor é automaticamente definida pela figura seguinte, que se traduz nos pontos imediatamente apresentados:
Header: Indica o tipo de protocolo a usar (TCP/IP ou UDP/IP).
Subheader: Espaço reservado da frame que dirá ao PLC que tipo de ação quer realizar. No caso da leitura, se o valor colocado for 00h, será pedido bits do registo
M. Se o valor for 01h, o PLC retornará valor em código ASCII do registo D.
PC number: É um valor fixo com o valor hexadecimal “FFh”. No caso de a
comunicação ser binária o módulo automaticamente traduz para “11111111”.
Monitoring timer: Tempo que o módulo Ethernet deve aguardar por uma resposta do PLC. Pode variar entre 0001 até FFFFh (250 ms). Por definição o tempo
normalmente utilizado é 0A00h (2500 ms).
Head Device Number: Valor do registo que pretendemos aceder.
Device Name: Nome do registo que queremos aceder. No caso apenas iremos utilizar os registos M e D.
Number of device points: Numero de pontos que pretendemos aceder, a partir do Head Device Number.
Figura 38 - Estrutura da frame de envio
Como exemplo de aplicação, na Figura 39 e na Figura 40 são disponibilizadas as configurações das frames dos registos M e D respetivamente.
57
Figura 40 - Frame para pedir dados do registo D
As frames enviadas pelo módulo Ethernet com o resultado do pedido, é ligeiramente diferente do anterior. A frame de resposta contém:
Header: Indica o tipo de protocolo a usar (TCP/IP ou UDP/IP).
Subheader: Espaço reservado da frame que dirá ao PLC que tipo de ação quer realizar. No caso da escrita, se o valor colocado for 02h, será enviado bits para
alteração do registo M. Se o valor for 03h, o PLC escreverá valores em código
ASCII no registo D.
Complete: O resultado processado pelo PLC e colocado neste campo da frame vai de encontro à ligação entre o servidor e o módulo Ethernet. No caso de a frame ser enviada corretamente o código enviado é 00h, caso contrário, é enviado um
código resultante de anomalia 50h.
Text with response: O texto com resposta aos pedidos poderá ser devolvido em binário ou em código ASCII, dependendo de como o pedido foi feito, e é apresentado conforme o exemplo da Figura 41.
Figura 41 - Frame de resposta ao pedido
5.2.3. F
RAMES DE ESCRITAA parte de escrita no PLC através do módulo Ethernet é muito semelhante às frames já apresentadas. Para isso, é concatena-se um campo adicional à frame exemplo (ver
58 Figura 38), que contem os novos valores que se pretende escrever nessas variáveis, alterando-se apenas o Subheader.
Neste caso o Subheader pode tomar dois valores diferentes, para o registo M, o manual obriga a alteração para 02h e para o registo D a alteração para 03h. Estes valores
dizem que a frame recebida pelo módulo Ethernet será de escrita.
A Figura 42 e a Figura 43 mostram um exemplo de comunicação dos registos M e D, onde o registo M receberá uma sequência de valores binários e o registo D uma sequência de valores em código ASCII.
Figura 42 - Frame para escrever nos registo M
Figura 43 - Frame para escrever no Registo D
5.3. S
OFTWAREA arquitetura implementada é orientada a serviços e permite aceder via web aos vários dispositivos selecionados. Para validar a arquitetura selecionada é necessário
59 implementar os vários elementos indicados - o servidor local com a aplicação local e a base de dados. No servidor local temos a aplicação desenvolvida, a ligação física ao recurso e a base de dados disponíveis para as aplicações cliente. A aplicação, para além de permitir a monitorização e controlo remoto do recurso, praticamente anula a perda de dados e informações, pelo facto de que todas as trocas de informação com a aplicação cliente são armazenadas na base de dados e são efetuadas a partir da base de dados, havendo sempre um registo. Conforme ilustra a Figura 44, a aplicação cliente recorre aos serviços disponíveis para enviar os pedidos para a base de dados no servidor local, através da web; estes, por sua vez, utilizam uma ligação TCP/IP para interagir com a base de dados MySQL. A base de dados é constantemente analisada pela aplicação local, por meio de uma ligação TCP/IP, para verificar se há novos pedidos/ordens a efetuar. Se os dados enviados estiverem corretos, a aplicação local efetuará o pedido/ordem comunicando com o recurso através das rotinas de comunicação implementadas de acordo com o protocolo de comunicação do recurso.
Figura 44 - Comunicação entre aplicação, PLC e base de dados
Para efetuar a supervisão e controlo do protótipo desenvolvido foram criadas duas interfaces de teste, uma aplicação em Visual Basic e um portal web.
O Visual Basic é uma linguagem de programação controlada por eventos que evoluiu a partir da linguagem de programação Basic. Possui um ambiente de desenvolvimento integrado com uma componente gráfica, o que facilita a criação de interfaces das aplicações. O MySQL é um sistema de gestão de bases de dados que
60 permite gerir bases de dados com um elevado número de registos de uma forma rápida e eficiente e para além disso é facilmente integrado com linguagens de programação como é o caso do Visual Basic ou o PHP.
O Xampp é um pacote de servidores no qual se encontra o servidor de base de dados MySQL e um interpretador de PHP, entre outros. Esta é uma aplicação bastante útil no desenvolvimento de aplicações web e não necessita de licença de utilização.
5.3.1. V
ISUAL BASICOs softwares de controlo e monitorização tendem a ser apelativos, de fácil perceção, flexíveis e, mais importante, eficazes. Contudo, para a área que este software foi especificamente desenvolvido, constata-se que o mais importante é o tratamento dos dados.
Uma das formas que foi encontrada para melhorar a segurança na consulta dos dados passou por atribuir prioridades aos utilizadores, permitindo o acesso às funcionalidades que vão de encontro com as necessidades desses níveis.
O software desenvolvido permite três tipos de prioridades, que consistem no seguinte:
Prioridade baixa: Apenas permite consultar os dados e exportar esses mesmos dados, ou para um ficheiro EXCEL ou para uma folha PDF.
Prioridade média: Esta prioridade tem o mesmo acesso da anterior. Nesta opção é atribuida a possibilidade de se poderem alterar os parâmetros da linha.
Prioridade alta: É a prioridade de administrador. Inclui as duas anteriores e é adicionada a possibilidade de adicionar utilizadores e linhas de produção.
Na Figura 45 é adicionado o utilizador “sergio” com prioridade alta, e este será o utilizador empregado ao longo da explicação do sistema para demonstrar as interfaces desenvolvidas. Todos os utilizadores são gerados na aba “Gestão de Credenciais” que por sua vez são armazenados na base de dados na tabela “utilizadores” (Figura 30).
61
Figura 45 - Registo de novo utilizador
Quando um utilizador efetua o registo com sucesso, o nome de utilizador surge no canto inferior esquerdo da janela de login, assim como, um botão que permite passar para a janela seguinte. No caso de o nome de utilizador ou a password estarem, incorretos, surge uma mensagem de alerta, a avisar que não foi efetuado nenhum login com sucesso e o botão de avanço mantem-se oculto. Este método de login é bastante utilizado em muitos softwares de diversas áreas, pois oferece dinâmica à interface.
62 Como o utilizador “sergio” tem prioridade alta, consegue adicionar novas linhas de produção. No exemplo que se segue na Figura 47 é possível verificar os campos que são necessários preencher para adicionar uma nova linha. Caso alguns dos campos não seja preenchido, a linha não será adicionada.
Para evitar que se adicionem linhas adulteradamente, fica registado na base de dados, através do “id_utilizador” da tabela “gestão de ips”, o nome do utilizador que fez esse registo.
A razão pela qual se decidiu atribuir um nome à linha surge dos novos métodos produtivos, que usualmente atribuem nomes às linhas, para facilitarem os relatórios produtivos na distinção produtiva semanal ou mensal entre as várias linhas da empresa.
Figura 47 - Interface para adicionar linhas de produção
O objetivo da interface que se segue na figura seguinte pretende mostrar a diferença entre os objetivos planeados e os cabos que foram verdadeiramente produzidos. Nesta aba, “Relatório Objetivos”, existem várias possibilidades de comparação, sendo oferecida ao gestor de linha a capacidade de comparar a linha por turno, referenciada ou por data. A quantidade de dados fornecida permite ao gestor de linha visualizar o rendimento da linha, em termos de quebras e aumentos produtivos. Estes dados são provenientes dos registos D664, D680 e D728 do PLC e armazenados constantemente na base de dados, na tabela “produção”, nos campos “referência”, “objetivos“ e “produzidos”, respetivamente.
63
Figura 48 - Interface para relatório de objetivos
A aba que se apresenta na Figura 49, colmata um tema importante na indústria, os