Artigos Técnicos

Disponibilização dos dados de processo, interfaceamento com

sistemas ERP e protocolo OPC: em que ponto estamos?

Constantino Seixas Filho e Magno Adriano Lisboa, Diretor de P&D e Analista de Sistemas Sênior,
respectivamente, da Atan Sistemas de Automação.

Um dos grandes desafios de todo o projeto de automação está em como disponibilizar os

dados de processo para os diversos níveis dentro da hierarquia da empresa. Relatórios em
papel são volumosos, não retratam as necessidades de cada área em particular e não
permitem manipular os dados para atender a um novo foco de pesquisa. Exportar os dados
para bancos de dados relacionais ou planilhas não resolve o problema de disponibilizar dados
históricos de longo prazo e de buscar dados em diversas fontes. Usar o supervisório para
essa tarefa já demonstrou ser uma solução inadequada.
Os requisitos hoje desejados são os seguintes:
1. Acesso a múltiplas fontes de dados - Deve ser possível buscar dados de diversas
fontes como sistemas SCADA, CLPs, SDCDs, LIMS e outros tipos de aplicativos. Algumas
fontes fornecem dados de processo, outras dados de produção, outras dados de qualidade. A
visão necessária a um gerente pode depender de todos esses tipos de dados. Concentre o
seu foco de interesse em um produto ou batelada. Por exemplo: um lote de um xampu. Não
interessa que subsistema contém uma dada informação. Aquele lote possui uma hora de
início de produção e uma hora final de produção. Foi produzido em um reator bem
determinado e assistido por um operador também determinado. Ingredientes A, B e C foram
pesados e adicionados ao reator para sua formação. Parâmetros de processo, tais como:
temperatura de processamento, viscosidade, pH, etc., foram controlados durante o processo
de fabricação. Amostras foram tomadas, cujo resultado constituem características de
qualidade do mesmo produto; enfim, não interessa como essas informações entram no
sistema e onde foram introduzidas; elas constituem apenas aspectos que descrevem o
produto e que, portanto, devem estar associadas a ele.
2. Registros de dados históricos - Os dados devem poder ser armazenados por longos
períodos de tempo. Deve ser possível buscar dados de um ano atrás ou de cinco anos com
um mínimo uso de backups externos (fitas DAT, CDs, etc.).
3. Facilidade de extração de dados - Deve ser possível visualizar dados através de
planilhas, não através de exportação estática, mas através de um acoplamento dinâmico e
em tempo real.
4. Suporte a pesquisa AD HOC - O usuário não sabe a priori de quais dados vai precisar.
Deve ser possível realizar consultas a base de dados para buscar informações, relacionando
tabelas, datas e áreas de processo diferentes.
5. Facilidade de personalizar vistas de processo - Cada usuário da planta tem uma
necessidade diferente. Um operador ligado à produção prefere acessar dados em tempo real
na forma de gráficos de tendência. Um gerente deseja o histórico de produção dos últimos
três turnos. Um operador da manutenção quer saber o tempo de parada de uma linha e as
principais causas responsáveis pela parada. Um técnico de qualidade quer saber os
resultados de laboratório das últimas bateladas. Todos esses dados estão no mesmo banco
de dados. Nós queremos filtrar a informação que interessa a cada um e produzir a sua visão
particularizada do processo. Sem informação em excesso. Apenas o essencial estará exibido.
6. Disseminação de dados através da Intranet - Todos os dados devem ser distribuídos
através da Intranet ou visualizados de casa através da Internet. Isso diminui o custo de
relatórios e vistas de processo. A maior vantagem é não ter que convencer o usuário a
aprender um novo paradigma de como operar uma interface.

Uma classe de produto que atende bem a esses requisitos são os PIMS (Plant Information
Management Systems). Esses sistemas têm sido empregados em todo tipo de indústria,
sozinhos ou interfaceados a bancos de dados relacionais, como topo de uma hierarquia ou
subordinados a um ERP (Enterprise Rosource Planning).
Os PIMS recolhem as informações de diversas áreas da planta e as disponibilizam em um
grande número de formatos. É possível armazenar diversos anos de operação da planta em
um banco de dados único. Essa ferramenta é ideal para a indústria de processos. Para a área
de manufatura e para processos em batelada, muitas vezes, é necessário combiná-la com
um banco de dados relacional.
Interfaceamento com sistemas ERP
Introdução
A difusão dos sistemas de ERP tem obrigado os demais fabricantes de software a estarem
atentos às necessidades dessa categoria de programas. Esses sistemas têm assumido um
papel importante e decisivo no sucesso das empresas em mercados cada vez mais exigentes
e competitivos.
Para otimizar a atuação dos ERPs, estes precisam se comunicar com diversos outros tipos de
sistemas externos, que auxiliam no desempenho das atividades específicas do negócio das
empresas, muitas vezes incompletas ou não cobertas pelo sistema de gestão.
As principais atribuições desses satélites são:
• Prover dados ao ERP, para que sejam consistidos e formatados para fundamentar a
tomada de decisões.
• Permitir que o ERP atue efetivamente nos processos.

Para alcançar esses objetivos, os sistemas externos usualmente utilizam três formas básicas
de comunicação:
• Troca de arquivos.
• Bancos de dados compartilhados.
• Interfaces através do protocolo TCP/IP.

Essas estratégias são amplamente difundidas em razão de poderem ser utilizadas em

ambientes multiplataforma, ou seja, onde os sistemas operacionais dos sistemas externos
são diferentes do sistema operacional do ERP em si.
Apesar de não ser o foco deste artigo, é interessante lembrar que através de redes WAN
(Wide Area Networks), ou mesmo via Internet, é possível aos ERPs se comunicarem com
outros ERPs, de mesmo fabricante ou não.

O SAP R/3
Por ser um ERP bastante utilizado no mercado, o estudo das interfaces de comunicação do
SAP R/3 pode exemplificar a importância do assunto.
No caso do R/3, as interfaces padronizadas de comunicação são baseadas no protocolo
TCP/IP. Atualmente, a tecnologia central e independente de plataforma são as interfaces
RFCs (Remote Function Calls).
De modo a tirar proveito de tecnologias de comunicação mais atuais, foram desenvolvidos
alguns recursos específicos em algumas plataformas sobre a tecnologia fundamental de RFCs.
No caso do ambiente Windows, por exemplo, o sistema SAP R/3 provê recursos para a
comunicação através da tecnologia DCOM (Distributed Component Object Model), o que pode
simplificar a integração com o ERP.
As interfaces de comunicação disponibilizadas pelo SAP R/3 são:
• Baseada diretamente em RFCs (RFC API).
• Baseada na SAP GUI (Graphic User Interface).
• Via IDocs (Intermediate Documents).
• Baseada em BAPI, Business Application Program Interface, utilizando:
- C++
- Java
- Interfaces de plataformas específicas

A RFC API (Application Program Interface) atua diretamente sobre as RFCs, ou seja, é a
interface básica de comunicação com sistemas SAP R/3. As demais interfaces encapsulam ou
utilizam as funcionalidades da RFC API, gerando interfaces mais adequadas para
determinados tipos de aplicação ou tecnologias.

A tecnologia de RFCS
O que são os RFCs?
As RFCs (Remote Function Calls) são os elementos centrais na comunicação com os sistemas
SAP R/3. As RFCs são subprogramas executados a partir de sistemas remotos.
A linguagem ABAP (Advanced Business Application Programming) é a linguagem de
programação utilizada no ambiente SAP para a realização de tarefas específicas e/ou
customizações.
Caso a comunicação seja originada em um sistema externo, para os ambientes OS/2,
Windows (95, 98, NT, 2000) e alguns tipos de UNIX, a SAP disponibiliza a RFC API (RFC
Application Programming Interface). Essa biblioteca permite a utilização das funcionalidades
das RFCs por sistemas externos, sendo um conjunto de rotinas escritas em C que provêm
recursos para facilitar a comunicação com sistemas SAP.
Para cada plataforma suportada, a SAP disponibiliza um SDK (Software Development Kit) que
contém as bibliotecas específicas da plataforma, header files e alguns programas
exemplificando o uso das RFCs.

Por trás de uma chamada a uma RFC

Quando é feita uma chamada a uma RFC a partir de um sistema externo, diversas operações
são feitas automaticamente. São elas:
• Conversão de parâmetros para as diferentes representações dos dados em ambos os
sistemas.
• Chamadas a rotinas de comunicação para o acesso a sistemas remotos.
• Gerenciamento de eventuais erros durante a troca de dados, notificando o sistema origem
caso desejado.

O processo é iniciado sempre por um RFC Client e se dá em duas etapas:

• Conexão entre o RFC Client (no SAP R/3 ou no sistema externo) e o SAP Gateway.
• Conexão do SAP Gateway ao RFC Server (no SAP R/3 ou no sistema externo).

O SAP Gateway é a interface no sistema SAP através da qual é feita a comunicação via RFCs.
A “Erro! A origem da referência não foi encontrada. “ ilustra o processo.

Figura 1 - Processo de comunicação via RFC.

A RFC Transacional (tRFC)

A partir da versão 3.0 do programa, os sistemas SAP R/3 receberam passaram a contar com
as RFCs Transacionais.
Com a introdução desse mecanismo, os sistemas SAP R/3 remotos não precisam mais estar
disponíveis no momento da chamada a uma RFC, pois as informações sobre a chamada são
armazenadas pelo componente tRFC na base de dados SAP, incluindo:
• Nome da RFC.
• Parâmetros de importação, exportação e tabelas.
• TID (Transaction Identifier).

O Componente tRFC é responsável pelo gerenciamento da troca de informações de forma

transacional, permitindo que o programa ABAP não fique bloqueado após a chamada a uma
RFC. Através da criação de TIDs, identificadores únicos de uma transação, é feito o controle
do número de tentativas de envio, do intervalo entre elas, das ações em caso de erro, etc. O
objetivo é garantir que a transação seja concluída de forma única e segura.
Entretanto, esse mecanismo não é completamente suportado pela Biblioteca RFC utilizada
por sistemas externos, basicamente pelas seguintes razões:
• Nem sempre há uma base de dados disponível nos sistemas externos.
• A Biblioteca RFC nem sempre é capaz de repetir as chamadas às RFC em caso de erros,
como, por exemplo, os provocados por problemas nas redes.

Nesse sentido, algum software adicional é necessário nos sistemas externos para tratar tais
particularidades.

As demais interfaces de comunicação do SAP R/3

Fundamentadas sobre a interface básica, outras interfaces são disponibilizadas para a
comunicação com o R/3. Algumas delas são apresentadas a seguir.

A Interface IDoc
Essa interface é orientada a mensagens e opera sobre formatos SAP padronizados
denominados IDocs (Intermediate Documents).
Os IDocs mapeiam um processo de negócio (como uma ordem de compra, por exemplo) em
um formulário eletrônico, sendo por isso adequados para a automatização de processos de
negócio envolvendo troca eletrônica de dados entre sistemas.
Há algumas vantagens em se utilizar IDocs na comunicação entre sistemas. A primeira é a
diminuição da entrada manual de dados, que uma vez inseridos podem ser enviados a
outros sistemas que suportem a tecnologia, o que pode acontecer entre sistemas SAP ou
entre um sistema SAP e um sistema externo.
Outro ponto é a independência da tecnologia de comunicação utilizada, pois os IDocs são
apenas estruturas de dados que podem ser enviadas através de várias formas. Para isso,
basta adaptar o software que gerencia a comunicação entre os sistemas.
Mesmo que as partes utilizem formatos de mensagem diferentes, ainda assim elas podem se
comunicar via IDocs. Para tal, é necessário o mapeamento dos formatos utilizados para o
formato padrão do IDoc pertinente.
Os IDocs são utilizados, por exemplo, entre sistemas SAP distintos, de mesma versão ou de
versões diferentes, através da tecnologia ALE (Application Linking and Embedding). Outra
tecnologia suportada é a troca de informações pelo padrão EDI (Electronic Data Interchange)
ou via Internet.
Os IDocs são enviados através de RFCs transacionais. No SAP R/3, deve-se configurar a sua
criação de acordo com as transações envolvidas. Em um sistema externo, não SAP,
normalmente se utiliza uma biblioteca específica, construída a partir da RFC Lib, com classes
que facilitam a manipulação dos IDocs. Trata-se da chamada IDoc Lib, escrita em C++,
disponibilizada pela SAP juntamente com o SDK.
O processo de comunicação via IDocs está ilustrado na Figura 2.

Figura 2 - O processo de comunicação via IDocs.

A Interface BAPI
Como funcionam os Business Objects?
O BOR (Business Object Repository), oferece objetos para a manipulação de processos de
negócio, utilizando-se a metodologia de orientação por objetos. São os chamados Business
Objects.
Cada Business Object é baseado em um Tipo de Objeto, que determina suas características e
comportamento conforme a lógica de negócio específica.
No BOR, cada Business Object possui um ou mais métodos, sendo que nem todos são
públicos, ou seja, podem ser acessados pelos sistemas externos. O conjunto de todos os
métodos públicos de todos os Business Objects é chamado de BAPI (Business Application
Program Interface). Essa abordagem proporciona o encapsulamento de dados e processos,
escondendo do usuário os detalhes de estrutura e implementação.
Para propiciar o encapsulamento desejado, os Business Objects são construídos com uma
estrutura com as seguintes camadas:
• Kernel
Neste nível estão as propriedades fundamentais do objeto.
• Integridade
Aqui está a lógica de negócio, regras e restrições.
• Interface
O terceiro nível é a interface do objeto com o mundo exterior, composta de um conjunto de
métodos claramente definido.
•Acesso
Define as tecnologias para se obter acesso externo ao objeto.

Os métodos dos objetos do BOR são implementados como módulos no SAP R/3, que podem
ser executados externamente via RFCs.

Biblioteca BAPI C++

Nos sistemas externos baseados no ambiente Windows, a Biblioteca BAPI C++ encapsula a
interface BAPI e possibilita o acesso ao SAP BOR.
Nem todos os Tipos de Objeto do BOR possuem classes equivalentes na Biblioteca BAPI
C++. Apenas os objetos com métodos públicos no BOR possuem uma classe associada nesta
Biblioteca.
As instâncias de objetos baseados nas classes da Biblioteca BAPI C++ são uma
representação local de uma instância remota de um objeto existente no BOR.
Como os métodos disponíveis na BAPI podem ser acessados via RFCs, a Biblioteca RFC C++
pode ser utilizada para facilitar o acesso aos métodos. A Biblioteca RFC C++ serve de base
para a Biblioteca BAPI C++, que implementa outras funcionalidades específicas da
manipulação de objetos do BOR.
As aplicações geradas com a Biblioteca BAPI C++ devem ser compiladas com o Microsoft
Visual C++ 5.0.
No caso da Biblioteca BAPI Java, o mecanismo de funcionamento é basicamente idêntico.

DCOM Connector
Nos ambientes Windows NT e 2000, a SAP disponibiliza uma interface através da tecnologia
DCOM, o DCOM Connector, para que clientes externos possam fazer o acesso às funções de
negócio do SAP R/3 através de BAPIs e RFCs.
A ferramenta permite que sejam geradas DLLs (Dinamically Linked Libraries), que contêm
componentes que encapsulam as chamadas às BAPIs e RFCs. Tais componentes podem ser
utilizados através de diversos ambientes de programação, como Visual Basic, Visual C++,
Delphi, páginas ASP para o acesso via Internet, etc., etc. Ou seja, as possibilidades de
utilização são limitadas às BAPIs e RFCs disponíveis no R/3, que podem ser executadas
indiferentemente por clientes a partir de uma máquina autorizada.
A interface do DCOM Connector, como pode ser visto na Figura 3, é acessada através de
browsers comuns, como o Internet Explorer.

Figura 3 - Tela inicial do DCOM Connector.

Concluindo
Enfim, pela variedade de interfaces disponibilizadas pela SAP para o seu ERP, é fácil perceber
a relevância da questão. Mecanismos simples de comunicação representam um grande
diferencial para os sistemas de gestão, que longe de serem auto-suficientes, são, na verdade,
o núcleo de um arranjo de sistemas que, bem planejado, pode levar a empresa ao topo. Mal
gerenciado, ao fundo do poço.
Protocolo OPC
O protocolo OPC (OLE for Process Control) foi criado para compatibilizar as camadas de
aplicação de dispositivos interligados a redes industriais. Antes éramos obrigados a conviver
com dezenas de padrões proprietários, o que acarretava a necessidade de centenas de
drives de comunicação diferentes. Por exemplo: para ligar um SCADA Factory Link rodando
em Windows NT a uma rede de CLPs Allen-Bradley, utilizando rede Ethernet, precisaríamos
de um drive específico. Isto nos forçava a dispor de drives para cada combinação: sistema
supervisório X plataforma do sistema operacional X placa de comunicação utilizada X CLP
utilizado. Todo integrador era também obrigado a possuir um calabouço com engenheiros
especializados em desenvolver drives específicos para aqueles produtos de mercado, para os
quais não existia interesse comercial em se produzir drives abertos.

Figura 4 - Interligação ponto-a-ponto de aplicações e equipamentos [OPC Foundation].

E se padronizássemos o mesmo tipo de rede – digamos Ethernet TCP/IP –, será que a

diversidade diminuiria? Não necessariamente, pois diferentes fabricantes de CLP utilizam
diferentes camadas de aplicação sobre o mesmo stack TCP/IP. As redes seriam equivalentes
até a camada de transporte, mas daí para cima os protocolos seriam diferentes e
proprietários. Por isso um CLP Rockwell não pode ser conectado à mesma rede de um CLP
GE.

Figura 5 - Interligando aplicações e equipamentos via Protocolo OPC [OPC Foundation].

O OPC representa uma forte tendência de padronização para essa camada de aplicação e é
uma realidade. Todo fabricante de CLP fornece um servidor OPC que permite comunicar o
equipamento com sistemas de nível hierárquico mais alto. Por sua vez, todo fabricante de
sistema SCADA, MES, PIMS, sistema especialista, LIMS, etc., oferece um cliente OPC capaz
de solicitar dados e enviar comandos para um servidor OPC de nível hierárquico mais baixo.
Evidentemente, nem todos os fornecedores desenvolveram drives OPC a tempo, mas nos
casos em que isto não aconteceu, outras empresas que se especializaram rapidamente neste
nicho de mercado, supriram a demanda, passando a fornecer uma grande coleção de drives
para quase qualquer produto do mercado. Entre estes fornecedores se destacam a Matrikon
(www.matrikon.com), eMation (www.emation.com) que adquiriu a Factory Soft especialista
em drives OPC, KEPware (www.opcsource.com), SST (www.mysst.com) e outros.
Uma das grandes dúvidas do mercado residia na performance dos drives OPC. Havia rumores
de que a tecnologia DCOM (Distributed Component Object Model) poderia representar um
overhead indesejável em aplicações críticas. Os primeiros estudos publicados pela Intellution
já em 1998 [Chisholm 98] demonstraram que, ao contrário dos rumores, a performance era
bastante satisfatória. Utilizando um Pentium 233 como servidor, o drive conseguia fornecer
cerca de 20 000 valores por segundo a 4 clientes com apenas 10% de carregamento na CPU.
Estudos realizados por nosso grupo na Universidade Federal de Minas Gerais, confirmou esta
boa performance [Souza 99].
Tabela 1 - Performance do drive OPC construído na UFMG comparada a um drive padrão
fornecido como amostra no site www.opcfoundation.com. Foi utilizado um computador
Pentium II 300MHz, 64kbytes de RAM e 512K bytes de cache em sistema operacional WNT.

Um estudo mais recente foi conduzido pela divisão Powertrain da GM e apresentado durante
o seminário da ARC (Automation Research Corporation) de fevereiro do ano passado, em
Orlando, EUA. Os pesquisadores da GM compararam o desempenho de drives OPC com o de
drives MMS (Manufacturing Message Specification). Esse duelo foi particularmente
importante. Primeiro pela fama adquirida pelos testes da GM, depois dos ensaios publicados
sobre os sistemas operacionais WNT e Windows CE. Depois porque se tratava do duelo entre
o protocolo de aplicação projetado academicamente para ser o padrão e o padrão real de
mercado. O OPC superou largamente os resultados do MMS e sepultou em definitivo a sua
pretensão a se tornar a referência mundial. Enquanto o MMS apresentou um atraso médio de
comunicação de 161 ms com 229ms de desvio padrão, o OPC apresentou um atraso médio
de 63ms com desvio padrão de 5ms [Ghadamabadi 00]. Além de mais eficiente, o protocolo
OPC se mostrou mais consistente.
A nova especificação OPC Alarms and Events [Chisholm 98] padroniza as interfaces
necessárias para troca de informações relativas a alarmes e eventos, utilizando infra-
estrutura similar e compatível ao estabelecido no padrão anterior. Essa interface suporta
níveis incrementais de funcionalidade, desde a simples detecção e transmissão de alarmes ou
de eventos até a implementação de recursos de seleção e filtragem de informação
proveniente de múltiplas fontes.
O melhor de toda esta história é que o OPC representa um grande sucesso em termos de
aceitação. Ele tem sido adotado tanto pelos fabricantes de equipamentos, integradores e
implementadores de sistemas, como pelo cliente final, que em suma é quem define se um
padrão fica ou é eliminado. O OPC, sem dúvida. chegou para ficar.

Bibliografia
Chisholm 98 – Al Chisholm, DCOM, OPC and performance Issues, Intellution 1998.
Souza 99 – Luiz Cláudio Andrade Souza, Desenvolvimento de drive padrão OPC para
Controlador Programável em Ambiente WNT, tese de mestrado em engenharia elétrica,
UFMG, 1999.
Burke 98 – Thomas J. Burke, The Performance and Throughput of OPC - a Rockwell Software
Perspective, June 11, 1988, Rockwell Software Inc.
Ghadamabadi 00 – Hamid Ghadamabadi, John Tsao, Jerry Yen - Applications Technology
validation – OPC and CE 3.0 for Manufacturing, Powertrain Div., GM, Proc. ARC Seminar Feb.
2000.
Chisholm 98 – OPC Alarms and Events Technical Overview – OPC foundation –
www.opcfoundation.com. SAP Automation Help Files.