Na conceituação de Willian Sobel (SOBEL, 2010), colaborador do MTConnect Institute, o MTCon- nect é um padrão baseado em um protocolo aberto para a integração de dados. "MTConnect não pretende substituir as funcionalidades do produtos existentes, mas atua para aprimorar as capacidades de aquisi- ção de dados de dispositivos e aplicações, e move-se no sentido de criar um ambiente plug-and-play que represente redução de custo de integração".
Esse protocolo foi desenvolvido com base nos mais dominantes padrões da manufatura e da indústria de software, o que maximiza o número de ferramentas disponíveis para sua implementação e fornece um maior nível de interoperabilidade com outros padrões e ferramentas nessas indústrias (SOBEL, 2010).
O MTConnect veio responder a um dilema industrial. Uma instalação de manufatura típica tem cen- tenas de máquinas e sistemas operacionais independentes associados para assegurar um produto fabricado no tempo, com a qualidade e o custo efetivos. Essas máquinas acumulam informações sobre sua operação e, frequentemente, estão impossibilitadas de se comunicarem com outros dispositivos. Mesmo havendo exceções, esse é o caso preponderante, é difícil comunicar informações processar dados entre essas máqui- nas e sistemas. O resultado disso é uma maior dificuldade na otimização, coordenação e rastreamento de dados para assegurar que máquinas, fábricas e sistemas operem em um nível aceitável (RANGARAJAN; DORNFELD; WRIGHT, 2003).
No entendimento de Silva et al. (SILVA et al., 2010), há muitos dados disponíveis no chão-de-fábrica, porém, o fato de as plantas de fabricação utilizarem máquinas de diferentes fabricantes implica no uso de
diferentes padrões de entrada e saída de dados, o que torna trabalhosa a tarefa de projetar e configurar um sistema que possa se comunicar e coletar dados sobre o funcionamento de todas as máquinas ao mesmo tempo. Isso faz com que sistemas de monitoramento tenham que ser projetados especialmente para cada planta, representando maiores custos e menor eficiência.
Há a necessidade de uma interface padronizada para máquinas-ferramenta e outros equipamentos que garantam estreita integração e interoperabilidade. O MTConnect é um padrão que surgiu para tentar res- ponder a essa necessidade ao reduzir a questão das “ilhas”de tecnologia (Fig.3.1) e criar um canal de comunicação entre/para máquinas-ferramenta que utilizem uma linguagem comum, conforme ilustra a Fig.3.2.
Figura 3.1: Máquinas de diferentes fabricantes baseadas em padrões proprietários, adaptado de (EDS- TROM, 2013)
Figura 3.2: MTConnect como um padrão universal para conectar equipamentos de manufatura com apli- cações, adaptado de (EDSTROM, 2013)
O MTConnect foi criado com o propósito de se tornar um padrão entre os fabricantes de máquinas CNC, como são o Bluetooth e o USB em suas respectivas áreas (WARNDORF; FOX; SOBEL, 2007). A
adoção de um formato único para distribuição de dados facilita grandemente a implementação de sistemas de monitoramento e análise dados. O fato de o protocolo ser baseado em HTTP permite o monitoramento remoto e através da Internet de vários dispositivos de linhas de produção simultaneamente.
O padrão MTConnect é baseado em XML, que é um padrão amplamente utilizado e oferece uma re- presentação flexível para troca de dados semi-estruturados. É aberto e livre de royalties, para garantir que ele seja utilizado em seu máximo potencial. A interoperabilidade permitida pelo protocolo estimula o desenvolvimento de hardware e software por terceiros, tornando processo de manufatura mais produtivo. Essa abordagem permite a conectividade do nível mais básico do processo produtivo, próximas às peças e máquinas no chão-de-fábrica, até as ferramentas no nível de projeto e planejamento de processo (VIJAYA- RAGHAVAN et al., 2008). A Figura 3.3 apresenta uma visão resumida da utilização do MTConnect na integração de um sistemas de manufatura para a interoperabilidade inter e intra sistemas.
Figura 3.3: Integração de Sistema de Manufatura usando MTConnect, adaptado de (VIJAYARAGHAVAN et al., 2008)
Tipicamente as arquiteturas de sistemas que empregam MTConnect são formadas por alguns compo- nentes que caracterizam o padrão. Eles são:
Adaptador
Como o MTConnect é uma padrão em desenvolvimento, a grande maioria dos CNCs são incompatíveis com ele. Para implementar o protocolo com essas máquinas é necessário o uso de um elemento adaptador. Em geral, o adaptador é um software que tem a função de realizar a "tradução"do formato proprietário utilizado pelo CNC para o padrão MTConnect.
Agente
dos fornecidos pelo adaptador. O agente é o elemento central do MTConnect. Os dados coletados por ele são arranjados no formato XML e repassados para aplicações cliente, que os utilizam para diferentes finalidades.
Dispositivo
São equipamentos ou grupo de componentes capazes de fornecer dados para a aplicação. Um disposi- tivo é uma entidade que possui pelo menos um controlador conduzindo sua operação.
Cliente
O Cliente representa todas as aplicações (mobile App, aplicações Web para browser,etc) com capaci- dade de conectar o Agente através de requisições HTTP a fim de obter dados para diferentes finalidades. De acordo com Silva et al. (SILVA et al., 2010), o padrão MTConnect foi desenvolvido com uma estrutura para que clientes possam ser desenvolvidos sem a preocupação com o formato em que os dados foram coletados.
O MTConnect é um padrão desenvolvido com base em uma arquitetura modular, isso permite o uso de diferentes ferramentas e métodos para conectar os dispositivos.
De acordo com Rondon (RONDON, 2010), é possível identificar até quatro diferentes arquiteturas para implementar o padrão (Fig. 3.4). Considerando a primeira opção de arquitetura (a) apresentada na Figura 3.4, observa-se o caso ideal de implementação da arquitetura, em que o dispositivo é complemente compatível com o MTConnect, tendo o Agente como elemento nativo do controlador. Na arquitetura (B) o Adaptador é incorporado ao dispositivo, mas o Agente é instalado como um servidor em um hardware separado. As arquiteturas (C) e (D) ilustram os casos em que os dispositivos não são compatíveis com o MTConnect, ou são dispositivos legados. Nesses casos é necessário programar o Agente e o Adaptador. Sendo que deve ser desenvolvido um Adaptador para cada modelo de CNC, por possuírem protocolos de comunicação proprietário.
A estrutura de dados que o Agente transmite para uma aplicação cliente é descrito em um documento XML de nome Devices.xml (Fig.3.5). Este arquivo é estruturado de forma que caracterize um controlador (Device), com seus componentes (Components), e dados (DataItems) gerados por eles. O arquivo mapeia a estrutura do dispositivo real. Para que um dado possa ser enviado para o Agente, ele precisa estar descrito no documento, caso contrário resulta em um erro de requisição HTTP. Sobel (SOBEL, 2010) lista e define os principais elementos que compõe o arquivo Devices.xml e componentes do padrão MTConnect, alguns dos quais são descritos abaixo:
Alarm- indica que um evento quer requer atenção e indica um desvio da operação normal.
Application- um processo ou um conjunto de processos que acessa o Agente MTConnect para realizar alguma tarefa.
Component- Parte de um dispositivo que contem subcomponentes ou itens de dados. Os componentes são blocos que compõe os dispositivos.
Probe- Uma requisição que resulta da descrição da configuração e da composição do dispositivo. Stream- Coleção de Events, Condition e Samples organizados por Dispositivos (Devices) e Compo-
Figura 3.4: Possíveis arquiteturas para implementação do padrão MTConnect, adaptado de (RONDON, 2010)
nentes (Components).
Current- Requisição feita pelo Agente para valores atuais de todos os itens de dados especificados. Se nenhum item é especificado o Agente retorna os valores de todos os componentes disponíveis.
Sample- Um dado exato de uma serie de dados contínuos. Exemplo: a posição de um eixo em um dado momento.
Event- Representa quando ocorre uma alteração de estado em um determinado momento. É importante comentar que um evento não ocorre sob frequência pré-definida.
DataItem - Representa uma descrição ou valor de qualquer informação que possa ser coletada do Agente.
Condition- Uma informação que o dispositivo fornece como um indicador da sua saúde e capacidade de funcionar. Uma condição pode ser : Normal, Warning, Fault ou Unavailable. Um único tipo de condição pode ter várias Faults ou Warnings a qualquer momento. Esse comportamento é diferente de Events e Samplesonde um DataItem deve ter apenas um único valor em um dado momento.
As Figuras 3.6 e 3.7 representam os fluxos entre as quatro entidades que compõe a arquitetura MT- Connect: O Name Service (um servidor LDAP que converte nomes de dispositivos para a URI do Agente), Application (uma aplicação de usuário que faz uso especial dos dados do dispositivo), Agent (o processo de coleta de dados do dispositivo e entregá-lo aos aplicativos), e Device (um equipamento).
O diagrama da Figura 3.6 ilustra a inicialização de um Agente (Agent) e a comunicação com o dis- positivo (Device). Inicialmente o Agente conecta-se e autentica-se com o Name Service (LDAP Server). Após isso, o Agente registra sua URI com o Name Service para que ele possa ser localizado. Em se- guida, conecta-se ao dispositivo (Device) usando a API do dispositivo ou outro processo especializado. O
Figura 3.5: Arquivo Devices.xml
dispositivo envia dados para o Agente ou o Agente sonda o dispositivo por dados.
Na Figura 3.7 mostra como todos os principais componentes do MTConnect se interrelacionam e como as quatro operações básicas são usadas para localizar e comunicar-se com o Agente em relação ao disposi- tivo. O processo de comunicação entre os elementos da arquitetura é descrito nas etapas abaixo (SOBEL, 2010):
1. O dispositivo envia continuamente informações ao Agente. O Agente coleta e salva as informações com base em sua capacidade de armazenar informações. O fluxo de dados do dispositivo para o Agente depende da implementação. O fluxo de dados pode inciar uma vez que um pedido tenha sido emitido a partir de uma aplicação cliente, a critério do Agente.
2. O aplicação localiza o dispositivo usando o Name Service com a sintaxe LDAP padrão que é inter- pretada da seguinte maneira: a fresa(mill) está na unidade organizacional Equip que está no domínio example.com. O registro LDAP para este dispositivo conterá uma URI que o aplicação pode usar para contatar o Agente.
Figura 3.6: Inicialização do Agente (SOBEL, 2010)
3. A Aplicação tem a URI para entrar em contato com o Agente, e assim o dispositivo Mill. O primeiro passo é um pedido de informação descritiva do dispositivo utilizando o pedido Probe. O Probe retornará a composição dos componentes do dispositivo, bem como todos os DataItems disponíveis. 4. O aplicativo solicita o estado atual (current) do dispositivo. Os resultados conterão o fluxo (stream) do dispositivo e todos os fluxos (streams) de componentes para esse dispositivo. Cada um dos Da- taItems reportará seus valores como Samples, Events ou Condition. O aplicativo receberá o Next- Serquence do Agente para usar no pedido de amostra (Sample) subseqüente.
5. A Aplicação usa o número nextSequence para amostrar(sample) os dados do Agente a partir do número de seqüência. Os resultados serão Events, Condition e Sample; e a contagem (count) não é especificada, portanto, o padrão é 100.