Cadrage préalable et théorique
21. Les approches retenues
Essa seção tem a função de fornecer o resultado complementar da aplicação da metodologia de Pro- jeto Axiomática para os módulos de software orientados a objeto, descrita na seção 3.2. Esses módulos são tratados através do modelo V (vê) com a metodologia de projeto axiomático para sistemas software orientados a objeto (ADo-oSS) o Adaptador MTConnect desenvolvido em linguagem C# e o Web Ser- viceRESTful desenvolvido em Java, que é uma das opções de implementação para o gateway do servidor OPCWeb. As linguagens de programação utilizadas no desenvolvimento de cada aplicação foram escolhi- das com base em critérios como: eficácia na programação e robustez da linguagem para o tipo especifico de aplicação (Windows forms e Web Service RESTful) e, a possibilidade de herança de códigos fonte de aplicações similares previamente desenvolvidas.
A Figura 5.19 apresenta o diagrama de classe do Adaptador com pacotes que representam os names- pacesaos quais pertence cada classe.
O namespace "AdapterLab"é o principal da aplicação, porque foi criado junto com a criação do projeto da aplicação na IDE de desenvolvimento Visual Studio 2010. Nesse pacote está a classe padrão associadas inicialização da aplicação (Program) e a classe do formulário gerado quando da criação de um projeto do tipo Windows Forms, que recebe o nome de MachineTool, nome adequado diante do objetivo que se quer al- cançar com o desenvolvimento da aplicação. Na classe MachineTool estão as referências ao parâmetros da máquina com as variáveis de atributos cujos tipos de dados representam dados de Eventos (Event), Amos- tras de dados (Sample) e Mensagens (Message), baseado na nomenclatura da especificação MTConnect. Nessa mesma classe foram criados os métodos associados a eventos, como os de iniciar (start_Click(...)) e parar (stop_Click(...)) a atividade do Adaptador, e um método temporizador (gather_tick(...)), que atualiza o valores dos atributos em intervalo pré-estabelecido.
O pacote Fanuc desenvolvido no contexto da implementação computacional do sistema contem a classe FocasGateway que recebeu esse nome por encapsular os métodos da API Fanuc-Focas 1 em uma repre- sentação mais simples, de mais fácil compreensão, em linguagem C# (C-Sharp). Esses tem por função a conexão e desconexão com o CNC do centro de torneamento, e a requisição de informações diversas como o status de execução, nome do programa em execução, ferramenta utilizada, posição atual dos eixos, entre outros. No mesmo namespace, a classe FanucPath tem apenas a função de fornecer informações relativas as condições de operação da máquina que tecnicamente estão vinculadas aos tipos de alarmes do CNC. Na especificação MTConnect os itens de dados (DataItem) da categoria Condition estão relacionados aos
Figura 5.19: Estrutura de Classes do Adaptador Fanuc-Focas1 do servidor MTConnect
alarmes do CNC, diferentemente das primeiras versões da especificação onde havia um tipo especial de item de dados chamado Alarm, associado a categoria de item de dados Event.
O diagrama de classe da Figura 5.19 mostra ainda que tanto namespace AdapterLab, quanto o Fanuc tem uma relação de dependência com o pacote MTConnect (https://github.com/mtconnect/dot_net_sdk), um toolkit desenvolvido sob licença livre por William Sobel durante MC2 Conference 2013, na sessão MC2 Adapter Lab Project. William Sobel é um dos pioneiros do padrão e que ajudou a desenvolver toda a especificação MTConnect.
A Figura 5.20 detalha as classes do namespace MTConnect que foram empregadas na implementação do Adaptador desenvolvido neste trabalho.
A estrutura e nomenclatura das classes desse pacote são baseadas completamente na especificação MT- Connect. A classe Adapter funciona como a entidade que manipula a estrutura de dados proveniente do dispositivo CNC, que inclui DataItem (Item de Dados) e Asset (Ativo). Este trabalho tratará especifica- mente dos DataItems, por representarem as principais informações que um controlador de uma máquina- ferramenta fornece.
Figura 5.20: Classes do pacote MTConnect implementadas no desenvolvimento do Adaptador
A classe DataItem do diagrama representa é superclasse das classes que representam as diferentes categorias de DataItem : Event, Sample, Codition, Message e; as subclasses Active, classe interna da classe Condition, e TimesSeries, responsável por associar data e hora aos valores dos itens de dados capturados do CNC da máquina. A classe Condition também está associada a um objeto de enumeração, o Level, que associa a classe os estados de condição de operação da máquina: Unavailable, Normal, Warning e Fault. A classe Message também tem a DataItem como superclasse e tem a função de receber as mensagens de alerta provenientes do controlador que não configuram alarmes. A atualização do estado de uma condição é preparada pela classe Active. Esta classe basicamente recebe o novo valor de uma instância de uma condição e gera uma sequência de caracteres entre barras (protocolo SHDR) para compor o streaming de dados que é enviado para o Agente MTConnect.
O Web Service para o servidor de supervisão OPCWeb é do tipo RESTful. Utilizando os recursos da API JAX-RS 1.1 (Java API for RESTful Web Services 1.1) e framework Jersey 1.19.3 a programação desse middleware é substancialmente facilitada, pois a API e o framework, entre outros recursos, fornecem um conjunto de anotações (@Path, @GET, @POST, etc.) que utilizam URIs ("/{recurso}/{valor}") e os detalhes do protocolo HTTP para acessar os métodos da aplicação Web de forma mais prática. Dessa
forma, a estrutura de classe do Web Service é significativamente enxuta, conforme demonstra o diagrama de classes da Figura 5.21.
Figura 5.21: Estrutura de Classes da proposta do Web Service RESTful do Servidor OPCWeb
Nesse diagrama as classes concebidas foram alocadas em um namespace chamado opcgateway. Neste está a classe OpcConnection que concentra as rotinas para conexão e interação com o servidor OPC-DA, isso inclui geração da estrutura de itens (tags) do servidor no cliente (no caso o Web Service), e execução da atividades de leitura e atualização do status dos parâmetros de CLP no servidor OPC. Para isso, a classe OpcConnectionusa as classes e interfaces da API JOPCClient, um cliente de acesso a dados preferido para comunicação com servidores OPC especificação DCOM.
A classe OpcReadWriteServer tem a função de instanciar a classe OpcConnection, e assim iniciar a conexão com o servidor, criação de grupos, e a esses adicionar itens OPC que são o elo com as tags do servidor OPC. No mesmo pacote está a classe OpcTagsBindings que é uma classe POJO (Plain Old Java Objects) e que tem como função principal serializar os itens (OPC tagname) e seus valores (true para ativado ou false para desativado) em formato XML. A classe RestOPCClient é um intermediário, recebendo requisições do cliente Web (browser) e enviando para o servidor OPC através de métodos da
classe OpcConnection, bem como transmitindo dados provenientes do servidor para o cliente Web em uma resposta XML, em um intervalo de atualização fornecido pela aplicação cliente.
Com o propósito de garantir o adequado funcionamento do serviço OPC através da internet, diante de possíveis dificuldades na avaliação desse servidor, uma abordagem alternativa é utilizada para o desenvol- vimento do elemento gateway para a acesso Web do servidor OPC. Programação não orientada a objeto de scripts escritos em linguagem Python para execução em um servidor Web utilizando protocolo CGI em requisições HTTP em um browser. Esses programas são lidos pela API OpenOPC que faz a comunicação com o servidor OPC-DA. As tags OPC manipuladas são as mesmas, tanto na abordagem com Web Service, quanto por meio de programas em Python.