ANAIS DOS TRABALHOS FINAIS DE GRADUAO DEZEMBRO/2012

UNIVERSIDADE FEDERAL DE ITAJUB

ENGENHARIA DE CONTROLE E AUTOMAO

Desenvolvimento de um Sistema de Gerenciamento de Dados de Produo, para

Auxiliar o Gerenciamento das Linhas Produtivas da Automotiva Usiminas.

Felipe Moreira Lagoas

Orientador: Prof. Dr. Luiz Lenarth Gabriel Vermaas

Instituto de Engenharia de Sistemas e Tecnologia da Informao (IESTI)

Resumo Este trabalho apresenta o estudo sobre a automao e informao j podem se beneficiar do
necessidade da integrao do cho de fbrica aos padro OPC (OLE for Process Control) [1].
nveis corporativos e um projeto piloto de
desenvolvimento de um sistema de gerenciamento de
dados de produo, que consiste em um cliente OPC
para realizar a coleta de dados de produo e
monitorar as ocorrncias na linha robotizada H534
Ford, na empresa Automotiva Usiminas S/A e um
software que permite manipular estes dados
remotamente. O sistema deve ser capaz de monitorar
os alarmes de ocorrncias e armazenar os dados sobre
a produo em uma base de dados, alm de permitir a
criao de relatrios e grficos de produo, de
paradas e dos indicadores de desempenho. O estudo
tambm prope a criao de uma estrutura
organizacional para coordenar e auxiliar o
desenvolvimento do sistema e faz um comparativo
econmico com a terceirizao do software.
Fig. 1 Transformando dados brutos em conhecimento.
Palavras-Chave: OPC, cho de fabrica.
A tecnologia OPC foi desenvolvida para permitir que
sistemas de controle possam fazer uso das tecnologias
desenvolvidas pela Microsoft para a plataforma WINTEL
I. INTRODUO [2].
Com a evoluo da automao nas indstrias de
O OPC prope uma interface amigvel entre sistemas que
manufatura, uma grande quantidade de dados do processo
trabalham usando protocolos diferentes. Assim diversas
esto dispostos na planta de forma desorganizada.
aplicaes recebem dados no mesmo formato da sua base
de dados, embora a fonte desses dados possa trabalhar
Um sistema de gerenciamento de dados de produo e de
com um padro diferente de formatao e comunicao
paradas de linha se faz necessrio, para agregar valor a
de dados. O OPC unifica o padro de comunicao de
esta grande quantidade de dados dispostos de forma
dados de controle de processo e permite que diferentes
desorganizada e transform-los em informao (Figura
produtos sejam interfaceados com uma nica tecnologia
1), auxiliando o gestor na tomada de decises.
(Figura 2), promovendo interaes dos sistemas de
operao e integrao de vrios processos em um s
Porm, os padres dos protocolos de comunicao
sistema, isso com o custo e tempo de implementao
impedem a interoperabilidade entre sistemas de
reduzidos [3].
superviso, automao e controle, de diferentes
fabricantes. No entanto a comunicao entre os
dispositivos de cho de fbrica e os sistemas de
 Fig. 2 Interoperabilidade do padro OPC (Fonte: OPC
Foundation).
Este trabalho prope a criao de uma estrutura
organizacional para suporte e desenvolvimento de um
cliente OPC, com o objetivo de centralizar os dados de
produo e manuteno da linha automtica H534,
presente na Automotiva Usiminas.
O cliente OPC, deve realizar a comunicao com diversos
equipamentos de campo, gerar relatrios de produo,
falhas e futuramente realizar o apontamento no sistema
ERP SAP/R3.
II. COMUNICAO DE DADOS EM SISTEMAS
TRADICIONAIS
No ambiente industrial, existem alguns tipos de redes de
comunicao especficas (Profibus, ControlNet,
Foundation Fieldbus, etc.), no entanto a maioria dos
fabricantes utilizam a rede Ethernet com o protocolo
TCP/IP para a transmisso de dados [4]. Sabendo o
protocolo TCP/IP encapsula diferentes tipos de
protocolos, cada fabricante desenvolve um driver
especfico para a comunicao com o seu protocolo
proprietrio. Portanto, existe a necessidade do uso do
driver especfico para acessar informaes dos
dispositivos de um determinado fabricante [4].
Como Ethernet uma rede multi-protocolar e a maioria
dos fabricantes utilizam TCP/IP, possvel interligar
diversos dispositivos de fabricantes diferentes na mesma
rede, porm apenas os dispositivos que possurem o
mesmo driver de comunicao iro se comunicar entre si
[4].
Para solucionar o problema de comunicao de dados, os
sistemas tradicionais como os SCADA (Supervisory
Control And Data Aquisition), possuam um conjunto de
diversos drivers para ento permitir a comunicao entre
dispositivos de diferentes fabricantes, conforme mostrado
na Figura 3 [4].
Fig. 3 - Comunicao do Sistema SCADA
utilizando drivers especficos.
Portando, a qualidade de um sistema SCADA deve ser
avaliada com relao quantidade de drivers especficos
[4]. Apesar do uso de drivers ter resolvido parcialmente
os problemas de comunicao, estes apresentam algumas
desvantagens:
Cada driver implica em um custo adicional;
Cada driver dispe de mecanismos especficos
para comunicao de dados, com diferentes
desempenhos;
Cada driver tem sua prpria interface com o
usurio, dificultando o treinamento e a manuteno do
sistema.
Mesmo com tais desvantagens, o uso de drivers
especficos para comunicao perdurou at meados da
dcada de 90, quando surgiu o padro OPC [4].
III. O PADRO OPC (OLE for Process
Control)
Em 1995, algumas empresas se reuniram com o objetivo
de desenvolver um padro de comunicao baseado na
tecnologia OLE/DCOM para acesso aos dados em tempo
real, no sistema operacional Windows [5]. Este grupo
sem fins lucrativos formado por diversas empresas e
gerenciado pela OPC Foundation.
Para melhor entender o padro OPC e suas
especificaes, devemos compreender alguns conceitos
fundamentais a seguir.
COM (Component Object Model) um padro
criado pela Microsoft para que uma aplicao cliente
possa acessar os servios de uma aplicao servidor. O
servidor implementa seus servios como objetos que
 podem ser acessados pelos clientes. COM especifica as
interfaces para clientes e para a comunicao
padronizada. A interface uma coleo de mtodos ou estejam na mesma especificao do padro [2].
funes e procedimentos relacionados que
implementam os servios especficos providos por
COM [4].
DCOM (Descentralizes Component Object
Model) prov os mesmos servios do COM, porm
utiliza como meio de acesso uma rede de comunicao
de dados. [4]
OLE (Object Linking and Embedding) object
uma unidade de informao que pode ser criada e
manipulada pelos usurios. Em outras palavras, objetos
so mdulos de dados/software que podem ser inclusos
nos pacotes de softwares. Podem ser linked ou
embedded. Enquanto no primeiro tipo os objetos so
armazenados separadamente e repartidos por vrias
aplicaes, no segundo eles so armazenados junto com
as aplicaes, tornando-se de uso exclusivo das
mesmas [4].
O Padro OPC surgiu como uma forma de estabelecer
regras de comunicao entre aplicaes [4]. Portanto o
uso do OPC no elimina a necessidade dos drivers de
comunicao. De forma geral o OPC define interfaces
que esto no nvel do usurio, acima do protocolo de
comunicao, Figura 4.
Fig. 4 - Interfaces entre aplicaes do Padro OPC.
O padro OPC estabelece as regras para que sejam
desenvolvidos sistemas com interfaces padres para a
comunicao dos dispositivos de campo (CLPs, sensores,
balanas, etc.) [6].
Portanto, o padro OPC utiliza a arquitetura
cliente/servidor e est localizado na camada de aplicao
do modelo OSI ISO [4].
O OPC no define como a aplicao servidor ir se
comportar com relao aos drivers de comunicao e
nem como os clientes iro se comportar para outros fins,
por isso h uma grande variedade de clientes e servidores
OPC disponveis no mercado [3]. Porm, qualquer
aplicao OPC ir se comunicar entre si, desde que
A primeira especificao produzida pelo grupo foi
publicada em agosto de 1996, chamada OPC
Specification Version 1.0 [2]. O principal objetivo do
grupo atender s necessidades da indstria, atravs do
aprimoramento e ampliao da especificao OPC. A
estratgia adotada foi a criao de extenses
especificao existente, definio da adio de novas
especificaes e a realizao de modificaes para manter
a compatibilidade com as verses existentes. Em
setembro de 1997 foi liberada a primeira atualizao da
especificao OPC que passou a ser chamada de OPC
Data Access Specification Version 1.0A [2].
A Figura 5 mostra as especificaes atuais do padro
OPC.
Fig. 5 Especificaes do Padro OPC.
As especificaes apresentadas se referem s interfaces
do tipo custom. Estas interfaces definem o acesso aos
servidores OPC por aplicaes clientes desenvolvidas
atravs de linguagens que suportam as chamadas funes
por ponteiros, tais como C/C++, Delphi, etc. [7].
Entretanto, existem linguagens tais como o Visual Basic e
VBA que no suportam ponteiros para funes. Neste
caso foi introduzido o conceito de interface do tipo
automation. Atravs da interface tipo automation, os
clientes desenvolvidos nestas linguagens podem fazer o
uso de uma interface padro onde os mtodos so
chamados pelo nome e no por ponteiros [7]. Existem,
portanto, especificaes OPC separadas para interfaces
do tipo custom e automation. A Figura 6 apresenta estas
interfaces.
Fig. 6 Interfaces Custom e Automation. (Fonte: OPC
Foundation)
A publicao das especificaes para o padro OPC
possibilitou o desenvolvimento de diversos produtos para
a automao industrial, os quais se beneficiam das
vantagens proporcionadas pelo padro.
Padronizao das interfaces de comunicao
entre os servidores e clientes de dados de tempo real,
facilitando a integrao e manuteno dos sistemas;
Eliminao da necessidade de drivers de
comunicao proprietrios;
Melhoria do desempenho e otimizao da
comunicao entre dispositivos de automao;
Interoperabilidade entre sistemas de diversos
fabricantes;
Integrao com sistemas MES, ERP e aplicaes
Windows (Excel, etc.);
Reduo de custos e tempo para
desenvolvimento de interfaces e drivers de
comunicao e reduo do custo de integrao de
sistemas;
Facilidade de desenvolvimento e manuteno
dos sistemas e produtos para comunicao em tempo
real;
Facilidade de treinamento.
Existem quatro tipos de comunicao para que o cliente
obtenha um determinado dado: leitura sncrona,
assncrona, refresh e subscription [6].
Com a leitura sncrona o cliente chama o mtodo e espera
pelo seu retorno. Chamadas sncronas devem somente ser
usadas se os dados de processo forem obtidos
rapidamente, caso contrrio o cliente fica travado.
Nas leituras assncronas, o cliente chama o mtodo no
servidor e fica liberado imediatamente para continuar sua
execuo normal. Aps certo intervalo, que depende de
como o dado aquisitado, o cliente obtm o valor.
Leituras assncronas devem ser utilizadas se a obteno
dos dados do servidor demora muito, como por exemplo,
os valores obtidos diretamente nos dispositivos de campo.
O refresh o tipo de aquisio que faz com que o cliente
leia todos os itens ativos de um determinado grupo, que
por sua vez tambm dever se encontrar ativo.

Atualmente existem diversos produtos no mercado que

utilizam o OPC para comunicao com dispositivos de
cho de fabrica. O OPC est se tornando rapidamente o
padro de comunicao adotado pelo mercado de
automao industrial e pela indstria [4]

IV. OPC DA 2.0

Para o desenvolvimento do cliente OPC, foi utilizada a
especificao OPC DA (Data Access) 2.0 que define as
regras para a troca de dados em tempo real entre clientes
e servidores OPC. De forma geral o funcionamento dos
servidores OPC consiste em fazer a aquisio dos dados e
deixar essa informao acessvel para os clientes OPC
que nele se conectarem. Essa disponibilizao se d
atravs do que a especificao OPC chama de Itens. Um
Item um dado que pode ser uma temperatura, presso,
estado de uma vlvula, etc., disponvel para ser lido por
um cliente OPC.
Um cliente OPC uma aplicao a qual ir se conectar
com um servidor para interagir com os itens
disponibilizados [4]. Para uma melhor organizao e
melhoria na transmisso de informaes entre
servidores/clientes, os clientes OPC devem criar grupos
de itens com caractersticas semelhantes [5]. Os grupos
alm de definir as principais caractersticas de leitura dos
itens (taxa de atualizao, estado ativou ou inativo, banda
morta, leitura sncrona ou assncrona) so usados para
estrutur-los.
Nesse contexto, podemos organizar os objetos OPC
atravs de uma hierarquia. A Figura 7 ilustra a
organizao destes objetos.
Fig. 7 - Estrutura interna dos objetos do padro OPC.
Os trs tipos de aquisio descritos at o momento so
feitos por iniciativa do cliente. Porm nem sempre isso
uma alternativa eficiente, j que o cliente obter valores
independentes deles terem sofrido qualquer alterao.
Para suprir tal necessidade que existe o tipo de troca de
informao chamado subscription. Nesta forma de
aquisio, o servidor faz leituras em ciclos determinados
pela taxa de atualizao e os envia para o cliente caso a
mudana de valor ou estado ocorrer. O cliente, por sua
vez, tem a opo de definir a taxa de atualizao com que
os dados sero varridos pelo servidor, bem como a
sensibilidade de mudana desse valor para que os
mesmos sejam enviados (banda morta).
V. DESENVOLVIMENTO DO SISTEMA DE
GERENCIAMENTO DE DADOS DE
PRODUO
Este trabalho consiste em desenvolver um sistema para
monitorar e auxiliar no gerenciamento da linha de
fechamento de cabines de caminhes FORD H534. Para
isto necessrio conhecer o processo e o sistema de
controle e automao da linha de produo.
A linha robotizada Ford H534 dividida em oito
operaes, sendo seis automticas e duas manuais, alm
de quatro postos de abastecimento externos, Figura 8.
Fig. 8 Ford H534.
O processo se inicia na operao 10 onde so montados o
assoalho e o painel frontal (dash), as operaes 20 e 30,
so manuais e realizam uma solda MIG nos lados direito
e esquerdo, respectivamente. As laterais e a traseira so
montadas na operao 40 e armazenadas em um buffer,
operao 50. Finalmente o teto montado na operao paradas de linha e os indicadores de desempenho podem
60, transportado e armazenado na operao 70 e sai para
a linha de acabamento, na operao 80.
O sistema de controle composto por CLPs Allen-
Bradley ControlLogix Standard e Safety comunicando em
um rede Ethernet, que controlam os dispositivos
automticos de transporte e os robs de solda, alm de
IHMs Allen-Bradley PanelView Plus, para a superviso.
Atualmente a linha H534 no possui um sistema
apropriado para realizar os apontamentos de paradas e
capaz de gerenciar as informaes sobre o processo,
acarretando uma grande impreciso com relao aos
tempos e as causas de tais ocorrncias e dificultando o
clculo dos indicadores de desempenho.
Diante deste cenrio, prope-se definir pontos de
monitoramento na linha robotizada H534 e desenvolver
um sistema capaz de coletar dados do processo,
ocorrncias de alarmes, criar relatrios e grficos e
realizar o apontamento de paradas.
VI. ARQUITETURA DO SISTEMA
O sistema de gerenciamento de dados de produo
composto por um gerenciador de desempenho e um portal
de visualizao. Os dados do processo so coletados
automaticamente dos controladores e armazenados
diretamente no banco de dados do sistema atravs de um
cliente OPC
Fig. 9 Arquitetura do Sistema
A arquitetura do sistema consiste em um servidor Xeon
Quad Core 2,26 GHz; 8 GB RAM, com o sistema
operacional Windows 2008 Server R2 Standard,
coletando os dados dos CLPs e disponibilizando para o
portal de visualizao. As informaes referentes s
ser visualizados em tempo real na IHM Panel View.
(Figura 9)
O cliente OPC foi desenvolvido na linguagem VB.NET,
utilizando a biblioteca (dll) OPCDAAUTO.dll para
acessar o servidor OPC RSLinx, da Rockwell Automation
e armazenar os dados em um banco de dados Access
2007.
Para cada uma das operaes da linha de produo, foram
criados OPC Groups, contendo os bits de falhas que
devem ser monitorados (OPC Items) alm de um grupo
que monitora a sada da linha, para determinar o modelo e
tempo de produo da cabine. A leitura foi feita pelo
mtodo Subscription, com taxa de atualizao de 1000
ms, ou seja, a cada 1 segundo o sistema verifica se houve
alguma alterao nos valores do itens de cada grupo e
armazena no banco de dados, em caso de alteraes.
Na Figura 10 est representado como os dados referentes
produo so armazenados.
Fig. 10 Dados de Produo.
Com relao s paradas de linha, o sistema deve mandar
um bit para o CLP, impedindo o retorno do
funcionamento da linha a menos que a parada seja
apontada na IHM com sua respectiva justificativa. A
Figura 11, mostra como so armazenadas as ocorrncias
de paradas de linha no sistema.
Para o gerenciamento de desempenho, os dados coletados
sero calculados e o sistema ir disponibilizar os
relatrios de forma grfica e tabular, permitindo o
entendimento da situao da produo em tempo real.
A Figura 14 mostra uma tela do portal de visualizao,
que permite realizar consultas referentes produo,
assim como gerar o respectivo relatrio (Figura 15).

Fig. 11 Dados de Paradas.

Para o monitoramento em tempo real, foram

desenvolvidas duas telas, a primeira contendo os dados de
produo, como a quantidade produzida de cada modelo,
o tempo do ltimo ciclo, o tempo mdio, o ritmo da linha
e a estimativa de produo (Figura 12).

Fig. 14 Portal de Visualizao.

Fig. 12 Tempo Real Ford H534.

Fig. 15 Relatrio de Produo.
A segunda tela mostra o estado de funcionamento de cada
operao e no caso de parada de linha, permite o operador
apontar tal ocorrncia (Figura 13).
O software utiliza o indicador OEE (Overrall Equipment
Effectiveness) para o clculo do desempenho da linha
clula ou equipamento. As informaes de desempenho
tambm podem ser acessadas com detalhe por operao
da linha, permitindo o usurio identificar os principais
motivos de paradas e/ou perdas de produo.

Fig. 13 Tempo Real Paradas Ford H534.

Fig. 16 Eficincia Geral do Equipamento.
A Figura 16 apresenta algumas definies gerais sobre o
indicador de OEE.
O calculo do indicador OEE feito multiplicando as trs
variveis: OEE = AT * P * Q, sendo que:
AT = Avaliable time disponibilidade
AT = B/A (tempo real de produo / tempo disponvel
para a produo);
Ao retornar do retrabalho, o sistema solicita o nmero do
controle interno e nmero do chassi j apontado no SAP e
assim registra o retorno do controle interno com o novo
nmero de chassi para a linha de acabamento.
A arquitetura da linha de acabamento mostrada na
Figura 17.

P = Performance desempenho P = D/C

(desempenho real / desempenho desejado com ciclo
ideal);

Q = Quality qualidade - Q = F/E (quantidade

produzida dentro dos padres / quantidade total dentro
dos padres esperado, ou seja, quantidade da ordem de Fig. 17 Arquitetura do Sistema para o Acabamento.
produo);
VIII. ESTRUTURA ORGANIZACIONAL
VII. DESENVOLVIMENTO FUTURO
Para auxiliar e coordenar o desenvolvimento do sistema
Atualmente as informaes sobre a produo so foi proposto a criao de uma estrutura organizacional.
apontadas manualmente no ERP SAP/R3. ERP um Tal estrutura apresentada na Figura 18.
software de gesto empresarial que facilita o fluxo entre
todos os departamentos da empresa, tais como fabricao,
logstica, finanas e recursos humanos [8].

O apontamento de produo realizado aps a cabine sair

da linha automtica e passar pela linha de acabamento
para realizar algum retrabalho necessrio.

No cenrio atual, quando a cabine entra no acabamento

um nmero de chassi associado a ela e registrado do
ERP como uma cabine existente na linha. Porm
possvel que seja diagnosticada a necessidade de
retrabalho com horas de durao prevista. Quando isto
acontece, como no possvel perder a sequencia do
nmero de chassi entregue a prxima linha (pintura),
retirado o nmero do chassi anteriormente atribudo
cabine em questo e este nmero atribudo a uma nova
cabine que est entrando na linha. Quando concludo o
retrabalho, a cabine recebe um novo nmero de chassi,
como se estivesse entrando na linha pela primeira vez.
Desta forma, no existe rastreabilidade do que aconteceu
com as cabines retrabalhadas assim como as estatsticas
que permitem a avaliao do tempo mdio de
permanncia no acabamento, considerando tais
retrabalhos.
Fig. 18 Estrutura Organizacional.
Inicialmente a estrutura contar com trs membros, dois
engenheiros e um analista de sistemas, divididos de forma
que o analista seja responsvel pela parte de TI, que
dever modificar a arquitetura das redes de comunicao
assim como gerenciar o banco de dados do sistema.
Os engenheiros sero responsveis pelo desenvolvimento
do software e adaptao das estruturas de automao para
fornecer os dados para o cliente OPC. Um engenheiro ir
acumular a funo de coordenador, onde dever gerenciar
as pessoas da estrutura, estipular prazos e metas e
acompanhar o desenvolvimento assim como suas
documentaes.

Como trabalho futuro, foi proposto a utilizao de um
conector SAP para realizar um controle interno a respeito
dos retrabalhos.
Ao enviar uma cabine para o retrabalho, o sistema solicita
o nmero de chassi inicialmente atribudo, o motivo do
retrabalho e gera um nmero de controle interno para tal
cabine e registra este nmero juntamente com o nmero
de chassi anteriormente atribudo.
O desenvolvimento do software internamente, conta com
algumas vantagens e desvantagens que devem ser
conhecidas.
Como vantagens, podemos destacas os seguintes itens:
Customizao;
Facilidade de Expanso;
O sistema agrega valor empresa, alm de
manter em sigilo dados, processo e tecnologia.
As desvantagens:
Por no ser uma empresa especializada, o prazo
de entrega ser maior;
Necessidade de cursos e treinamentos;
Implantao de uma estrutura de suporte, gesto
e desenvolvimento.
Para justificar a criao de uma estrutura para o
desenvolvimento, foi realizado um estudo comparando o
desenvolvimento interno com duas propostas de empresas
especializadas.
A Figura 19 apresenta o custo do desenvolvimento
interno comparado ao de duas empresas do mercado que
visitaram a linha de produo Ford H534 e oraram o
preo do sistema.
Fig. 19 Investimento Ford H534.
Como pode ser visto na Figura 19, a criao da estrutura
no vivel do ponto de vista econmico. Pois
inicialmente necessrio investir em licenas de
software, cursos e treinamento.
Com isso foi proposto o desenvolvimento do sistema em
outras cinco linhas de produo da Automotiva Usiminas
com os mesmos nveis de automao. Assim, temos na
Figura 20, o novo comparativo.
Fig. 20 Investimento Ford H534 e demais linhas.
Logo, aps o investimento inicial, a estrutura passa a ser
vivel, alm de contar com outros ganhos intangveis,
como o domnio da tecnologia e a distribuio do
conhecimento atravs de treinamentos internos.
Porm, ainda preciso justificar a funo dos membros
da estrutura aps o desenvolvimento do sistema, para as
seis linhas produtivas.
Aps a implantao do sistema, a estrutura
organizacional proposta anteriormente, sofrer
modificaes a fim de manter o funcionamento do
sistema assim como agregar novas funes. A nova
estrutura apresentada na Figura 21.
Fig. 21 Estrutura Organizacional aps o
desenvolvimento.
Com a nova estrutura o coordenador, passa a exercer a
funo de supervisor. O engenheiro e o analista ficaram
responsveis pela manuteno do sistema, alm da
criao de novos projetos de automao e controle. O
setor de automao, atualmente vinculado superviso de
manuteno eltrica, passar a compor a estrutura.
IX. CONCLUSO
A implantao do Sistema de Gerenciamento de Dados
de Produo na linha Ford H534 possibilitou um maior
conhecimento sobre as causas das paradas e
possibilitando atac-las de maneira eficiente, aumentando
assim a eficincia geral dos equipamentos. O sistema
tambm auxiliou no planejamento da produo, pois
agora possvel conhecer o tempo mdio de produo de
cada cabine e consequentemente a capacidade produtiva,
permitindo aos controladores de produo elaborar o
programa de produo de forma eficiente, diminuindo os
atrasos e a quantidade de horas extras.
X. REFERNCIAS BIBLIOGRFICAS
[1] RIBEIRO, DENISE FERREIRA, DOS ANJOS,
RINALDO, LEANDRO. Utilizao do Drive OPC na
Integrao de Sistemas de Automao Industrial 3
Seminrio Nacional de Sistemas Industriais e Automao,
22 a 25 de Outubro de 2008.
[2] FONSECA, MARCOS DE OLIVEIRA.
Comunicao OPC Uma abordagem prtica. VI
Seminrio de Automao de Processos, Associao
Brasileira de Metalurgia e Materiais, 9-10 de outubro de
2002 Vitria ES.

[3] IWANITZ, FRANK and LANGE, JRGEN. OLE

for Process Control Fundamentals, Implementation and
Application, Hthig Verlag Heidelberg, 2001.

[4] LEITO, GUSTAVO BEZERRA PAZ (2006).

Arquitetura e Implementao de um Cliente OPC para
Aquisio de Dados na Indstria do Petrleo.

[5] PAVEI, JONATAS (2009) Sistema de Controle via

Redes Industriai: Desenvolvimento de um Software para
Controle Avanado via OPC.

[6] OPC Foundation <http://www.opcfoundation.org/>,

acesso em outubro de 2012.

[7] NOGUEIRA, THIAGO AUGUSTO (2009) Redes

de Comunicao para Sistemas de Automao Industrial.

[8] ERP Enterprise Resource Planning ou Planejamento

dos Recursos Corporativos, 2007. Disponvel em:
<http://www.administradores.com.br/informe-
se/artigos/erp-enterprise-resource-planning-ou-
planejamento-dos-recursos-corporativos/13972/>, aceso
em novembro de 2012.

BIOGRAFIA:
Felipe Moreira Lagoas
Nasceu em Tefilo Otoni (MG), em
1989. Estudou na Escola Tcnica de
Formao Gerencial SEBRAE/MG,
tendo recebido o ttulo de Tcnico em
Administrao. Ingressou na UNIFEI em
2008, participou do projeto especial
Driving4u. Realizou estgio na Automotiva Usiminas
S/A em Pouso Alegre MG.