Aplicação local

Como já foi referido, para permitir que um conjunto de serviços Web possam monitorizar ou controlar um equipamento, ou seja, a viabilidade da realização de sistemas SCADA remotos, é vital a existência de uma aplicação local. De acordo com a arquitectura seleccionada, será necessária uma aplicação que estabeleça a ponte entre aplicações cliente e os equipamentos, neste sentido, a aplicação será desenvolvida em Visual Basic.Net e permitirá a comunicação com os vários dispositivos seleccionados, sendo apenas uma aplicação para gerir os vários serviços criados para cada equipamento.

O programa consultará, constantemente, uma tabela de troca de informação com as aplicações cliente, de forma a processar, com o menor atraso possível, os pedidos das aplicações cliente. A aplicação local toma conhecimento de um pedido e inicia o processamento do mesmo e actualiza a base de dados para informar que esta se encontra ocupada. Após processar o pedido deverá actualizar, a base de dados, com o resultado do pedido, ou seja, se foi concluído ou se houve um erro.

Com esta gestão, torna-se possível gerir os pedidos contínuos dos clientes que não poderão sobrepor um pedido a um pedido em execução, podendo efectuar o pedido logo que a aplicação local esteja disponível.

63

O programa deverá ter informação actualizada sobre o estado do equipamento, de forma a manter as aplicações cliente informadas do estado do equipamento, ou seja, mediante o estado do equipamento a aplicação poderá ou não fazer determinado tipo de movimentos. Por exemplo, se um equipamento estiver em ciclo automático, não será permitido a aplicações cliente efectuar movimentos ou alterações no ciclo.

O programa será uma pequena aplicação em ambiente Windows e é caracterizada por:

• Interface gráfica simples e intuitiva, possibilitando a verificação de todas as tabelas da base de dados. A interface é orientada a objectos, permitindo a sua selecção em função do tipo de equipamento que se perspectiva.

• A tabela de troca de informação dos diferentes equipamentos deverá ser consultada constantemente, a fim de garantir um rápido processamento e transmissão dos dados

• Permitirá a supervisão e controlo local, de forma simples e rápida, mas operação a operação. A programação será estruturada de forma a permitir a sua fácil adaptação e permitir que de forma simples se adicione e crie toda a estrutura para um novo equipamento. Com estes pressupostos, o programa será muito centrado em “arrays”, matrizes, funções e com grande recurso a variáveis públicas.

O programa deverá estar devidamente estruturado e dividido por blocos, para permitir aceder facilmente a informação e facilitar a edição. Com vista a viabilizar a comunicação com os equipamentos, recorre-se ao controlador da porta série, uma vez que, apesar da comunicação série ser de certa maneira limitada é, no entanto, muito versátil e simples de utilizar, pelo que é suficiente uma porta série no computador e um cabo de comunicação.

As rotinas de comunicação relacionam-se directamente com o CPU (Unidade de Processamento Central) dos PLC’s sem que seja necessário realizar programação adicional nos PLC ou adicionar hardware. As rotinas de comunicação deverão estar reunidas em módulos separados para cada equipamento.

65

4 Implementação

Neste capítulo pretende-se descrever todos os passos que foram necessários para implementar o sistema de Web services para aplicações SCADA, um sistema que possibilita a aplicações cliente remotas, ou apenas através de um browser, a monitorização e controlo remoto de recursos ou aplicações controlados por PLC’s.

A concretização do sistema carece de uma plataforma de comunicação com os PLC’s, que não exija hardware ou software adicional, sendo que para isso foi levada a cabo uma pesquisa para desenvolver os protocolos necessários à comunicação com os CPU's dos recursos. Seguiu-se a implementação de pequenas aplicações para ensaiar a comunicação, a troca de dados com os recursos e a leitura e escrita da base de dados. Foram desenvolvidos alguns Web services para determinar qual a estrutura/arquitectura a implementar e a que se apresentou como mais prática, viável e funcional foi a descrita na hipótese 2 do capítulo 3.1.

A arquitectura proposta foi implementada, tendo-se criado uma pequena aplicação que funciona como aplicação local para os vários equipamentos propostos, para além de se ter desenvolvido os Web services independentes para cada equipamento.

Todo o trabalho foi desenvolvido numa perspectiva 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, projecto e implementação, mas também através de estudo e adaptação de soluções existentes, de forma a completar um sistema orientado a serviços que permita soluções SCADA via Web.

Todos os pontos descritos são devidamente analisados de seguida.

4.1 Arquitectura

A arquitectura implementada é orientada a serviços e permite aceder via Web aos vários dispositivos seleccionados. Para validar a arquitectura seleccionada será necessário implementar os vários elementos indicados - o servidor local com a aplicação local, a base de dados no SGBD seleccionado e criar os Web services.

No servidor local teremos a aplicação local, a ligação física ao recurso, a base de dados e os Web services disponíveis para as aplicações cliente. A aplicação local, 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

66

trocas de informação, com a aplicação cliente, são armazenadas na base de dados e são efectuadas a partir da base de dados, havendo sempre um registo.

Conforme ilustra a Figura 23, a aplicação cliente recorre aos serviços disponíveis para enviar os pedidos para a base de dados no servidor local, através dos Web services, estes, por sua vez, utilizam uma ligação TCP/IP para interagir com a SGBD 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 efectuar. Se os dados enviados estiverem correctos, a aplicação local efectuará 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 23 - Esquema da arquitectura implementada.

Efectuada a comunicação com o recurso, as informações serão armazenadas na base de dados e a aplicação cliente terá de executar um serviço do tipo “pull” do resultado, ou seja, realiza uma leitura na base de dados para verificar o resultado do pedido ou ordem efectuado.

Os elementos da arquitectura em causa podem ser analisados, ressalvando-se a arquitectura funciona como descentralizada e orientada a serviços, que permite a integração de todas as partes criando um sistema distribuído. Os elementos existentes nesta arquitectura são a aplicação cliente, num extremo, o servidor local, que funciona como o “cérebro” do sistema implementado, e no outro extremo os vários equipamentos testados.

No servidor local estão presentes elementos de significativa importância para o bom funcionamento do sistema, como a aplicação local que gere e processa os pedidos das aplicações cliente e efectua as comunicações com os diferentes equipamentos. O Sistema de Gestão de Base de Dados (SGBD), do MySQL, é outro elemento crucial, tendo em conta que armazena todos os dados e permite a troca de

67

informações efectuadas entre aplicações. O último elemento, com igual relevância, são os Web services que acessíveis via Web, permitem a interacção entre as aplicações, sendo que sem a ausência deste elemento tornaria impraticável a implementação da arquitectura proposta.