Você está na página 1de 9
Resumo executivo OPC: Tudo o que você precisa saber “Guia do OPC para todos” Darek

Resumo executivo

OPC: Tudo o que você precisa saber

“Guia do OPC para todos”

Darek Kominek, Eng. P. Alberta, Canadá - 2009

O Guia do OPC para todos apresenta uma visão geral

e acessível do padrão industrial de conectividade

aberta mais popular do mercado. Este guia apresenta inicialmente a ideia principal por trás do OPC e segue demonstrando porque o OPC é diferente dos protocolos de comunicação convencionais (geralmente proprietários), explicando como ele auxilia a superar as limitações de tais protocolos nativos.

Em seguida, o artigo define quais são os blocos que formam o OPC (clientes e servidores OPC) e como estes funcionam em conjunto para tornar possível

o compartilhamento de dados. Utilizando ilustrações

claras e o mínimo de jargão técnico, o Guia do OPC

para todos ajuda leitores de todos os níveis técnicos

a compreenderem rapidamente o que é o OPC e como

podem utilizá-lo para estabelecer interconectividade

em seus ambientes.

Figura 1: Problema do driver padronizado - Cada aplicativo exige um driver específico para o

Figura 1: Problema do driver padronizado - Cada aplicativo exige um driver específico para o dispositivo ou protocolo a fim de permitir sua comunicação com o dispositivo correspondente. Os drivers não são reutilizáveis entre aplicativos porque cada aplicativo utiliza seu próprio formato de dados.

Como o oPC soluCiona o PRoblema da ConeCtividade de dados de automação

Nos dias atuais, a automação é largamente utilizada nas grandes indústrias.

Enquanto indústrias diferentes utilizam dispositivos especializados, sistemas de controle e aplicativos variados, elas compartilham um desafio comum que aumenta a cada dia: como compartilhar dados entre todos esses componentes

e com o restante da empresa.

Antes de conceituarmos o OPC e explicarmos como ele auxilia a solucionar um dos maiores problemas de comunicação da automação, vale a pena discutirmos um pouco sobre esses problemas específicos. Apresentamos

a seguir uma lista de fatores que, tradicionalmente, causaram os maiores

problemas de compartilhamento de dados, seguida de uma explicação breve

sobre o impacto do OPC em cada uma dessas questões:

Protocolos proprietários: Os fornecedores geralmente utilizavam protocolos proprietários que permitiam que os produtos de uma linha particular comunicassem entre si, mas que exigiam drivers padronizados para comunicarem com produtos de outros fornecedores. Para piorar a situação, as linhas de produtos diferentes do mesmo fornecedor geralmente não comunicavam entre si, o que gerava a necessidade de conectores adicionais.

O OPC resolve essa questão ao tornar desnecessário que o Coletor de dados

saiba como a Fonte de dados se comunica ou organiza seus dados.

“O OPC elimina a necessidade de drivers padronizados entre cada novo aplicativo e a Fonte de dados.”

Drivers padronizados: Toda conexão ponto a ponto exigia um driver padronizado para facilitar as comunicações entre pontos extremos específicos. Por exemplo, se uma HMI necessitasse comunicar com um CLP, ela exigiria um driver HMI padronizado e codificado para o protocolo específico do CLP. Se fosse necessário fazer o histórico dos dados desse CLP, o historiador deveria ter o seu próprio driver porque o driver padronizado da HMI só poderia ser utilizado para comunicações com a HMI, e não com o historiador. Se um driver padronizado para os pontos extremos específicos não estivesse disponível, a comunicação de dados tornava-se difícil e onerosa.

O OPC elimina a necessidade de drivers padronizados entre cada novo

aplicativo e a Fonte de dados. Na Figura 1, um único driver padrão CLP poderia ser compartilhado tanto pela HMI quanto pelo historiador através de um conector OPC, com o benefício adicional do conector OPC precisar de uma única conexão para o CLP, reduzindo a carga do controlador.

Integração complexa: O uso de drivers padronizados entre cada ponto de destino exigia que mesmo um pequeno número de dispositivos e aplicativos envolvesse vários drivers. A mesma HMI sendo executada em vários computadores – e todos se comunicando com o mesmo dispositivo – exigia várias instalações e configurações do mesmo driver em cada computador. Se as HMIs se comunicassem com dispositivos adicionais, cada uma exigia seu próprio conjunto de drivers padronizados para cada dispositivo. Isso criava um pesadelo para a manutenção de versões.

“O tráfego e, consequentemente, a carga do dispositivo, é altamente reduzida quando se utiliza os

“O tráfego e, consequentemente, a carga do dispositivo, é altamente reduzida quando se utiliza os conectores OPC [porque todos os clientes usam uma única conexão para a fonte de dados.]”

Utilizar o OPC simplifica bastante a integração porque uma vez que um Conector OPC seja configurado para uma Fonte de dados em particular, todos os aplicativos OPC podem começar a compartilhar dados com a Fonte de dados sem a necessidade de drivers padronizados adicionais.

Carga do dispositivo e do controlador: Cada driver estabelece sua

própria conexão com o dispositivo ou controlador projetado para comunicar-se com ele. Devido ao grande número de drivers padronizados utilizados em uma instalação típica, o controlador geralmente era bombardeado por inúmeras solicitações da mesma informação a partir de cada aplicativo que necessitasse comunicar com ele. Além disso, muitos dispositivos podiam aceitar apenas um número limitado de conexões simultâneas. Se o número de drivers tentando se conectar a um dispositivo excedesse o número de conexões disponíveis, outras providências se faziam necessárias.

O tráfego e, consequentemente, a carga do dispositivo, é altamente reduzida

quando se utiliza os conectores OPC já que um único conector OPC, específico do dispositivo, exige apenas uma única conexão com a Fonte de dados

enquanto comunica simultaneamente com muitos aplicativos.

Obsolescência da infraestrutura legado: À medida que os

fornecedores lançam novos produtos, geralmente param de oferecer suporte aos produtos antigos. Quando uma nova versão de uma HMI é lançada, esta pode exigir seu próprio conjunto de drivers de dispositivo, sendo que estes muitas vezes não suportam mais a comunicação com um dispositivo suportado pela versão anterior.

“O OPC estende a vida útil dos sistemas legado Portanto, o OPC permite que os aplicativos mais recentes continuem se comunicando com os sistemas mais antigos.”

O OPC estende a vida útil dos sistemas legado, porque uma vez que um

conector OPC para um sistema legado tenha sido configurado, este permite que qualquer aplicativo OPC (a maioria) se comunique o sistema legado, independentemente do aplicativo suportar comunicação com o sistema legado nativo ou não. Portanto, o OPC permite que os aplicativos mais recentes

continuem a se comunicar com os sistemas mais antigos.

Conectividade de dados por toda a empresa: À medida que a

necessidade de automação de dados cresce na empresa, os problemas de conectividade de dados vão se ampliando porque os aplicativos do lado corporativo não foram projetados para se comunicar com dispositivos e controladores. Isso pode adicionar, potencialmente, uma carga extra à infraestrutura de automação e aumentar as preocupações com a segurança da automação.

O OPC torna o compartilhamento de dados de automação por toda a empresa

uma realidade possível ao permitir que aplicativos aprovados compartilhem dados com Fontes de dados de automação, sem a necessidade de instalar

drivers padronizados. O único requisito é um conector OPC.

existe algum exemplo real do oPC em ação?

Sim. Para ver exemplos reais do uso do OPC na solução de vários problemas de conectividade de dados de terceiros, consulte estes estudos de caso OPC (http://www.matrikonopc.com/resources/case-studies.aspx).

Figura 2: O OPC funciona como uma camada de abstração entre as Fontes de dados

Figura 2: O OPC funciona como uma camada de abstração entre as Fontes de dados e os Coletores de dados, permitindo intercomunicação sem que cada lado tenha conhecimento do protocolo nativo do outro.

intRodução ao oPC

o que é o oPC?

O OPC é o método de conectividade de dados baseado em padrões mais

popular do mundo. Ele é utilizado para lidar com um dos maiores desafios da indústria de automação: a comunicação entre dispositivos, controladores e/ou aplicativos sem ser surpreendido pelos problemas comuns de conectividade com base em drivers padronizados.

Por que o oPC foi bem sucedido quando os drivers padronizados falharam

A chave do sucesso do OPC em propiciar comunicações verdadeiramente

independentes de fornecedor é que ele abstrai os detalhes de implementação da Fonte de dados (p. ex., CLP) e do Coletor de dados (p. ex., HMI) de cada lado para que os dados possam ser trocados entre eles, sem exigir que tenham conhecimento do protocolo de comunicação nativo e da organização de dados das partes envolvidas. Esse é um grande contraste em relação à abordagem de drivers padronizados de codificar aplicativos que, por definição, devem comunicar-se nativamente tanto com a Fonte de dados quanto com o Coletor de dados.

Como a comunicação do oPC funciona (conceitual)

O OPC pode ser representado por uma camada de “abstração” entre a Fonte

de dados e o Coletor de dados, permitindo que troquem dados sem que

tenham conhecimento algum da outra parte.

dados sem que tenham conhecimento algum da outra parte. Figura 3: Arquitetura Cliente/Servidor OPC - Uma

Figura 3: Arquitetura Cliente/Servidor OPC - Uma visão detalhada da camada de abstração OPC revela dois componentes: um Cliente OPC e um Servidor OPC As especificações OPC definem a interface entre esses dois componentes.

Como o oPC funciona (visão funcional)

A “abstração do dispositivo” OPC é realizada utilizando dois componentes

OPC especializados chamados Cliente OPC e Servidor OPC, os quais são descritos abaixo. É importante observar que o fato da Fonte de dados e do Coletor de dados poderem se comunicar através do OPC não significa que seus respectivos protocolos nativos não sejam mais necessários ou que tenham sido substituídos pelo OPC. Ao contrário, esses protocolos e/ou interfaces nativas ainda estão presentes, mas comunicando-se apenas com um dos dois componentes OPC. Por outro lado, os componentes OPC trocam informações entre si, fechando assim o circuito. Os dados podem trafegar do aplicativo para o dispositivo sem que estes precisem conversar entre si.

benefícios da utilização da conectividade oPC

Primeiramente, trocar um único driver padronizado por dois componentes OPC (Cliente OPC e Servidor OPC) pode não parecer uma grande melhora, mas como a experiência já demonstrou, a melhora é real. A seguir estão alguns dos benefícios-chave do uso do OPC:

1. Um aplicativo para OPC pode comunicar-se livremente com qualquer Fonte de dados para OPC visível para ele na rede, sem a necessidade de qualquer software de driver, específico da Fonte de dados.

2. Os aplicativos para OPC podem comunicar-se com tantas Fontes de dados OPC quanto necessário. Não há limitação inerente no OPC em relação ao número de conexões realizadas.

“O OPC lida com o desafio de trabalhar com essas categorias diferentes de dados ao

“O OPC lida com o desafio

de trabalhar com essas

categorias diferentes de

dados ao especificar, de forma

independente, como cada um

é transmitido.”

4. As Fontes de dados OPC podem ser alteradas, trocadas ou atualizadas, sem a necessidade de atualizar os drivers utilizados por cada aplicativo (Coletor de dados) que se comunica com a Fonte de dados via OPC. Apenas o Servidor OPC para aquela Fonte de dados precisa ser mantido atualizado.

5. Os usuários têm liberdade para escolher os dispositivos, controladores e aplicativos mais adequados aos seus projetos, sem se preocupar com o fornecedor ou se estes vão comunicar-se entre si. Podemos simplesmente assumir que haverá intercomunicação.

Que tipos de dados o oPC suporta?

Os tipos de dados de automação mais comuns transferidos entre dispositivos, controladores e aplicativos, subdivididos em três amplas categorias:

• Dados em tempo real

• Dados históricos

• Dados de alarmes e eventos

Cada um dos tipos de dados acima também suporta uma ampla variedade de tipos de valores. Alguns exemplos comuns desses tipos de dados são: inteiro, ponto flutuante, string, data e vários tipos de array, apenas para citar alguns. O OPC lida com o desafio de trabalhar com essas categorias diferentes de dados ao especificar, de forma independente, como cada um é transmitido pela arquitetura do Cliente e do Servidor OPC.

As três especificações OPC correspondentes às três categorias de dados são:

1. Especificação de acesso de dados OPC (OPC DA) – utilizada para transmitir dados de tempo real

2. Especificação de acesso de dados históricos OPC (OPC HDA) – utilizada para transmitir dados históricos

3. Especificação de alarmes e eventos OPC (OPC A&E) – utilizada para transmitir informações de alarmes

Todos os conectores OPC suportam todas as especificações OPC?

Não. Os conectores OPC não precisam suportar todas as especificações OPC. Historicamente, era mais comum ter servidores OPC que suportavam dados de tempo real, seguido por implementações HDA OPC. É prudente perguntar quais especificações OPC um conector OPC suporta antes de escolhê-lo para um projeto.

“É prudente perguntar quais

especificações OPC um

conector OPC suporta antes de

escolhê-lo para um projeto.”

É importante saber qual especificação OPC um cliente ou servidor oPC suporta?

Sim, isso é crucial. Enquanto todas as três especificações OPC (OPC DA, OPC, HDA e OPC A&E) utilizam a mesma arquitetura básica Cliente/Servidor OPC para transmitir os diferentes tipos de categorias de dados, tanto o Cliente quanto o Servidor OPC devem suportar a mesma especificação OPC para coordenarem adequadamente a passagem de dados entre eles e para funcionarem corretamente com o Coletor de dados e a Fonte de dados respectiva.

seRvidoRes oPC o que é um servidor oPC? Um Servidor OPC é um aplicativo de

seRvidoRes oPC

o que é um servidor oPC?

Um Servidor OPC é um aplicativo de software, um driver “padronizado”, codificado especificamente para ser compatível com uma ou mais especificações OPC. A palavra “servidor” em “Servidor OPC” não se refere ao tipo de computador sendo utilizado, mas reflete seu relacionamento com o contraparte OPC, o Cliente OPC.

o que os servidores oPC fazem?

Os Servidores OPC são conectores que podem ser definidos como tradutores entre o mundo OPC e um protocolo ou interface de comunicação nativa da Fonte de dados. Já que o OPC é bidirecional, isso significa que os Servidores OPC podem tanto ler ou escrever em uma Fonte de dados. O relacionamento Cliente/Servidor OPC é um tipo de relacionamento mestre/escravo onde o Servidor OPC somente transferirá dados para ou de uma Fonte de dados se um Cliente OPC o comandar.

“Os Servidores OPC

podem se comunicar com,

literalmente, qualquer Fonte

de dados.”

Com que tipo de Fontes de dados (dispositivos) os servidores oPC podem se comunicar?

Os Servidores OPC podem se comunicar com, literalmente, qualquer Fonte de dados cuja saída possa ser lida ou escrita por meios eletrônicos. Uma lista breve de possíveis Fontes de dados inclui: dispositivos, CLPs, DCSs, UTRs, balanças eletrônicas, bancos de dados, historiadores, páginas web e atualizações automáticas de arquivos CSV. Para se comunicar com qualquer um desses dispositivos, é necessário utilizar apenas um Servidor OPC que empregue o protocolo ou interface nativa apropriada. Uma vez que tal Servidor OPC seja configurado, qualquer aplicativo para OPC (com permissão) pode começar a se comunicar com a Fonte de dados, sem se preocupar como a Fonte de dados se comunica em sua origem.

onde posso encontrar um servidor oPC para um dispositivo X?

Enquanto muitos fornecedores oferecem Servidores OPC com seus dispositivos, controladores e aplicativos, há muitos que não o fazem. A MatrikonOPC é o maior fornecedor mundial de conectores OPC de alta qualidade para centenas de dispositivos. Um bom local para iniciar é no site de servidores da MatrikonOPC, ou ligando para a MatrikonOPC diretamente.

Como os servidores oPC funcionam?

Enquanto os usuários não necessitam ter conhecimento sobre o funcionamento interno dos Servidores OPC para poder utilizá-los, um entendimento conceitual do que acontece nos bastidores ajuda a compreender porque a qualidade e o desempenho dos vários fornecedores de Servidores OPC varia tanto.

Figura 4: Arquitetura conceitual do Servidor OPC – Conceitualmente, um Servidor OPC pode ser subdividido

Figura 4: Arquitetura conceitual do Servidor OPC – Conceitualmente, um Servidor OPC pode ser subdividido em três módulos: Módulo de comunicações OPC, Módulo de tradução/mapeamento e um Módulo de comunicações nativo.

Uma visão conceitual do funcionamento interno de um Servidor OPC se parece com o seguinte:

• Módulo de comunicações OPC: Esta seção do Servidor OPC é

responsável por comunicar-se adequadamente com um determinado Cliente OPC. Os Servidores OPC bem codificados devem ser totalmente compatíveis com as especificações que implementam para garantir que se comuniquem adequadamente com os Clientes OPC.

• Módulo de comunicações nativas: O Servidor OPC deve

empregar o método mais eficiente de comunicação com a Fonte de dados. Em alguns casos, isso significa conectar-se à Fonte de dados diretamente através de seu protocolo nativo, enquanto em outros casos, isso significa comunicar-se com a Fonte de Dados através de seu driver padronizado por uma Interface de Programação de Aplicativo (API). Geralmente, quanto mais experiência o fornecedor do Servidor OPC tiver com o dispositivo, melhor o Servidor OPC utilizará suas opções de comunicação.

• Módulo de tradução/mapeamento: Aqui é onde acontece a “mágica” no Servidor OPC. Este módulo tem como tarefa interpretar adequadamente as solicitações OPC que chegam do Cliente OPC e transformá-las em solicitações nativas apropriadas, que serão enviadas à Fonte de dados e vice-versa. Se isso for executado de forma eficiente, o fornecedor OPC pode manter a carga da Fonte de dados em um nível mínimo, enquanto maximiza o processamento de dados.

o servidor oPC de um fornecedor pode comunicar-se com

Clientes oPC de outros fornecedores?

Sim, assumindo-se que o Cliente OPC e o Servidor OPC sejam compatíveis com as mesmas especificações OPC, estes serão capazes de se comunicar independentemente do fornecedor.

“Servidores OPC bem

codificados devem ser

totalmente compatíveis

com as especificações que

implementam.”

Os Servidores OPC podem compartilhar informações com outros servidores oPC?

Os Servidores OPC não se comunicam diretamente; eles são projetados para comunicarem-se apenas com Clientes OPC. Entretanto, existem utilitários OPC como o Gerenciador de Dados MatrikonOPC (http://www.matrikonopc.com/ products/opc-data-management/opc-data-manager.aspx), projetado especificamente para tornar essa comunicação entre Servidores OPC algo trivial.

Clientes oPC

o que é um Cliente oPC?

Um Cliente OPC é um software codificado para se comunicar com conectores OPC. Ele utiliza mensagens definidas por uma especificação da OPC Foundation.

Figura 5: Arquitetura conceitual do Cliente OPC – Da mesma forma que o Servidor OPC,

Figura 5: Arquitetura conceitual do Cliente OPC – Da mesma forma que o Servidor OPC, podemos pensar em um Cliente OPC como sendo composto de três módulos: Comunicação do aplicativo nativo, Módulo de tradução/mapeamento e um Módulo

de comunicação.

o que um Cliente oPC faz?

Conceitualmente: Os Clientes OPC representam um coletor de dados. Eles iniciam e controlam as comunicações com os Servidores OPC com base no que o aplicativo onde estão integrados solicita. Os Clientes OPC traduzem solicitações de comunicação de determinado aplicativo para uma solicitação OPC equivalente e as envia para o Servidor OPC apropriado para fins de processamento. Em troca, quando os dados OPC retornam do Servidor OPC,

o Cliente OPC os traduz de volta para o formato nativo do aplicativo para que

este possa trabalhar adequadamente com os dados.

Tecnicamente: Os Clientes OPC são módulos de software utilizados por um aplicativo para permitir que estes se comuniquem com qualquer Servidor OPC compatível e visível na rede. Geralmente, os Clientes OPC estão integrados em aplicativos como HMIs, pacotes de tendências, historiadores e escritores de relatórios para torná-los inerentemente OPC.

É comum fazer referência ao aplicativo com um Cliente OPC integrado como “Cliente OPC”, mesmo que apenas a implementação OPC seja o verdadeiro Cliente OPC.

os Clientes oPC podem comunicar-se simultaneamente com vários dispositivos (servidos oPC)?

Esta resposta contém duas partes:

1. De forma semântica, é importante lembrar que os Clientes OPC são, de

acordo com seu design, capazes de se comunicar com Servidores OPC, e não com os dispositivos propriamente ditos ou outras fontes de dados. Isso

é necessário porque os Clientes OPC devem ser independentes do protocolo.

Caso contrário, eles cairiam na armadilha dispositivo-driver do passado.

2. Sim, os Clientes OPC podem se comunicar com vários Servidores OPC ao

mesmo tempo. Efetivamente, isso significa que um Cliente OPC pode ler

e escrever dados em várias fontes de dados através de seus respectivos Servidores OPC.

Como um Cliente oPC funciona?

Como o Servidor OPC, o Cliente OPC pode ser conceitualmente subdividido em três módulos, que incluem: Módulo de comunicação do aplicativo, Módulo de tradução/mapeamento e Módulo de comunicação OPC. As funções de cada módulo são descritas a seguir.

“Os Clientes OPC podem

se comunicar com vários

Servidores OPC ao mesmo

tempo.”

Módulo de comunicação OPC: Apesar de não estar tão envolvido quanto

o Servidor OPC (a porção do Servidor OPC é mais complicada) esse módulo é

crucial para que o Cliente OPC se comporte corretamente ao se conectar com um Servidor OPC, trocar dados com ele e desconectar-se sem desestabilizar

o Servidor.

Módulo de comunicação do aplicativo: O Cliente OPC geralmente é

codificado para funcionar dentro de um aplicativo específico; por isso, ele se apoia em algumas chamadas para a Interface de Programação do Aplicativo (API) para permitir que os dados sejam passados do aplicativo para o Servidor OPC/Fonte de dados através do Cliente OPC. Também é possível que um Cliente OPC genérico se comunique com um aplicativo através de um protocolo ao invés de uma API, se o aplicativo suportar tal protocolo. (Um exemplo disso

é o Cliente MatrikonOPC para ODBC que utiliza declarações SQL sobre o ODBC para se comunicar com um aplicativo de banco de dados relacional.)

“ não há limite teórico para o número de Servidores OPC aos quais um Cliente

“ não há limite teórico para o

número de Servidores OPC aos

quais um Cliente OPC pode se

conectar.”

Módulo de tradução/mapeamento: Uma função chave do Cliente OPC

é traduzir informações bidirecionalmente, já que o aplicativo que ele representa solicita que dados sejam lidos de ou escritos no dispositivo final ou Fonte de dados.

a quantos servidores oPC um Cliente oPC pode se conectar?

A resposta curta é: tantos quanto for necessário. Dentro da estrutura OPC,

não há limite teórico para o número de Servidores OPC aos quais um Cliente OPC pode se conectar.

os Clientes oPC podem se comunicar diretamente com outros Clientes oPC?

Não. As comunicações entre Clientes OPC não estão definidas em OPC. Apenas

a arquitetura Cliente OPC/Servidor OPC é suportada. Entretanto, se um

aplicativo precisa fornecer dados OPC para outros clientes, ele precisa ter um Servidor OPC próprio. Esse Servidor OPC permitirá então que Clientes OPC de outros aplicativos utilizem esse aplicativo como uma Fonte de dados OPC.

Onde o Cliente OPC fica instalado?

Os Clientes OPC geralmente são integrados aos aplicativos que os utilizam,

como por exemplo, HMIs ou historiadores. Se por qualquer razão, o aplicativo

à mão não possui um Cliente OPC integrado, tal cliente pode estar disponível

de um fornecedor de aplicativos ou de um fornecedor OPC terceirizado como a MatrikonOPC. Um Cliente OPC externo ao aplicativo geralmente se comunicaria com o aplicativo através de um de seus protocolos nativos. Nesse caso, o Cliente OPC nem teria que residir no mesmo computador que o aplicativo.

“A marca tradicional do OPC

como abordagem “plug and play”

para a conectividade de dados

levou ao rápido crescimento de

sua popularidade.”

ConCluindo

Este trabalho explicou como o OPC resolve os crescentes desafios da indústria moderna para acessar e compartilhar dados entre dispositivos, controladores

e aplicativos, independentemente de suas comunicações nativas ou de seus

fornecedores. Uma descrição de alto nível ilustrou o que é o OPC e explicou

o que são Clientes OPC e Servidores OPC (blocos formadores do OPC) e suas

funções nas comunicações OPC. Enquanto um conhecimento profundo do funcionamento interno do OPC não seja um requisito para utilizá-lo, é útil obter uma familiarização breve com seus conceitos principais.

A marca tradicional do OPC como abordagem “plug and play” para a conectividade de dados levou ao rápido crescimento de sua popularidade, fazendo com que se tornasse a tecnologia de conectividade de dados mais popular do mundo. Graças à sua versatilidade, o OPC é utilizado em todos os níveis empresariais

e por todos os setores industriais.

Copyright © Matrikon Inc 2009

Ligação gratuita 1-877-628-7456 Tel.: +1 (780) 945-4099

Américas

Ásia-Pacífico

E-mail: info@MatrikonOPC.com Web: www.MatrikonOPC.com

Europa

Oriente Médio África
Oriente Médio
África