Embed Size (px)
Citation preview
Universidade Federal de Pernambuco Centro de Tecnologia e Geociências
Curso de Especialização em Automação Industrial
Automação do Registro de Pesagem de Caminhões em uma Indústria Petroquímica
Rômulo de Almeida Bruno
Orientador: Profª. Maria de Fátima Queiroz Vieira
Monografia apresentada ao Centro de Tecnologia e Geociências da Universidade Federal de Pernambuco como parte dos requisitos para obtenção do Certificado de Especialista em Automação Industrial
Recife, 2016
Resumo
Automação do Registro de Pesagem de Caminhões em uma Indústria Petroquímica
Rômulo de Almeida Bruno
Março/2016
Orientador: Prof.ª Maria de Fátima Queiroz Vieira
Área de concentração: Automação Industrial
Palavras-chaves: automação, MES, carregamento.
Este trabalho descreve a solução implementada para integrar o sistema de chão de fábrica
ao ERP (Enterprise resource planning) de uma indústria petroquímica. A solução foi desenvolvida
internamente utilizando-se da infraestrutura existente: controlador lógico programável modelo
Siemens S7-200 do sistema de carregamento enviando os dados de pesagem via rede para um
computador. Nesse computador os dados são estruturados em um banco de dados, sincronizado ao
sistema concentrador de informações (SCI) que serve como interface levando cada registro ao
sistema integrado de gestão corporativa (ERP, Protheus Totvs).
O sistema de carregamento associado aos silos finais de produção é de fundamental
importância para o funcionamento da fábrica como um todo, sendo responsável pelo escoamento do
produto final fabricado, no caso deste trabalho, ácido tereftálico ou PTA (purified terephthalic acid)
para o destino logístico solicitado. Na época do comissionamento da unidade fabril foram
detectadas lacunas no sistema de carregamento deixando diversas atividades do processo sob
responsabilidade do operador logístico. Dentre essas atividades estão: o registro do valor final de
peso carregado, a configuração do peso a ser carregado e ocasionalmente a interrupção manual do
carregamento. Com a unidade em operação, surgiram reclamações por parte dos clientes acerca do
valor registrado de peso na documentação e o valor real de produto nos caminhões container
fornecidos. Com base na reclamação, foi feito um estudo que detectou possíveis falhas dos
operadores ao registrar o peso, além de falhas no sistema de carregamento e pesagem que
impactaram diretamente na eficiência e confiabilidade dessa atividade.
A automatização de registro de peso otimizou as atividades relacionadas aos escoamento
da produção, reduziu a possibilidade de erro por falha humana, aumentando a confiabilidade do
processo, o que gerou como consequência maior satisfação por parte dos clientes.
Sumário Capítulo 1 Introdução ........................................................................................................... 1
1.1 Apresentação do Sistema de carregamento e faturamento ............................................ 31.2 Declaração do problema ............................................................................................... 71.3 Objetivos ..................................................................................................................... 81.4 Justificativas ................................................................................................................ 81.5 Organização da monografia ......................................................................................... 8
Capítulo 2 Tecnologias disponíveis ........................................................................................ 92.1 CLP S7-200 ................................................................................................................ 102.2 Rede RS485 ................................................................................................................ 132.3 Sistema Concentrador de Informações (SCI) - MES ................................................... 142.4 Oracle Database, Oracle ODI e Oracle GoldenGate .................................................... 192.5 ERP Protheus ............................................................................................................ 232.6 Considerações finais ................................................................................................... 24
Capítulo 3 Implementação da Solução ................................................................................. 253.1 Arquitetura Inicial do Sistema de Carregamento dos Silos Finais de Produção ........... 253.2 Mudança na Arquitetura para automação do registro de pesagem de caminhões ........ 303.3 Modificações no software do CLP de do sistema de integração ................................... 313.3 Definição do Protocolo e software do PC de interface ................................................. 323.4 Projeto de interfaces SCI e integração com o ERP Protheus ....................................... 343.5 Considerações finais ................................................................................................... 35
Capítulo 4 Conclusões ......................................................................................................... 364.1 Testes e Dificuldades no processo de desenvolvimento ................................................ 364.2 Discussão de Resultados e Possibilidades de Melhoria Futura ..................................... 37
Apêndice A ......................................................................................................................... 39Apêndice B .......................................................................................................................... 41Apêndice C ......................................................................................................................... 43Referências Bibliográficas ................................................................................................... 49
Índice de figura
Figura 1.1 Montagem de motor feita por robôs, fabrica de motores Ford. ..................................... 2Figura 1.2 Silos finais de produção e respectivas balanças rodoviárias A, B, C e D. ...................... 3Figura 1.3 Diagrama de fluxo do processo de venda e faturamento de PTA a granel. ..................... 4Figura 1.4 Container com liner para transporte de produto em pó. ............................................... 4Figura 1.5 Procedimento de carregamento de caminhão container. .............................................. 5Figura 1.6 IHM Presys para setpoint de peso e módulo de balança rodoviária Digitron. ................. 5Figura 1.7 Posicionamento da plataforma e conexão do liner a tubulação ..................................... 6Figura 2.1 Siemens S7-200 modelo 224 utilizado no projeto. .................................................... 10Figura 2.2 Tela principal do software STEP 7-Micro/Win. ........................................................ 12Figura 2.3 Conversor RS-485 para USB utilizado no projeto. .................................................... 14Figura 2.4 Pirâmide da automação. ......................................................................................... 16Figura 2.5 Rack do SCI no data center de TI. ........................................................................... 16Figura 2.6 Estrutura de rede que liga o SCI aos demais servidores. ............................................ 17Figura 2.7 Diagrama do ODI Studio e seus módulos. ............................................................... 20Figura 3.1 Arquitetura do Sistema de Carregamento dos Silos Finais de Produção. Inicialmente o módulo de comunicação RS-485 não era utilizado. .................................................................. 26Figura 3.2 Visão interna do painel do sistema de integração dos silos A e B composto por CLP S7-200, cartões de entrada e saída (analógicos e digitais) e demais periféricos (fonte de alimentação, disjuntores, barreiras de proteção, relés). ................................................................................. 27Figura 3.3 Botão de "tara" no módulo de pesagem (Digitron). ................................................... 27Figura 3.4 IHM de seleção e monitoramento de peso (Presys). .................................................. 28Figura 3.5 Cabo de aterramento corretamente posicionado na carcaça do caminhão container. ..... 28Figura 3.6 Sinal de permissão para início do carregamento (Selection Clearance), pré-requisitos: peso ajustado, "tara" da balança realizada e aterramento corretamente posicionado. .................... 29Figura 3.7 Fluxo prévio do registro de peso dos carregamentos de PTA. .................................... 30Figura 3.8 Fluxo final do sistema de carregamento com registro automatizado de pesagem. ......... 30Figura 3.9 Botão seletor de peso (26 ou 27,5 toneladas). ........................................................... 31Figura 0.1 Tabela ASCII (0 a 127). ......................................................................................... 39Figura 0.2 Tabela ASCII (128 a 255). ..................................................................................... 40
Índice de tabelas Tabela 1 Características do CLP S7200 224 (Referência Siemens 6ES7214-1AD23-0X40). ........ 11Tabela 2 Principais características das interfaces RS-232, RS-422 e RS-485 [06]. ....................... 13Tabela 3 Palavra de 25 bytes do protocolo de envio de peso. ..................................................... 32Tabela 4 Tabela de registros de pesagem. ................................................................................ 34
1
Capítulo 1
Introdução
Uma das soluções disponíveis para a indústria aumentar sua competitividade, satisfazendo
clientes, é a automação industrial. Na verdade, as empresas de manufatura estão respondendo aos
desafios do mercado global competitivo atual, investindo em automação industrial e no
desenvolvimento de ferramentas e normas de intercâmbio eletrônico. Estes irão permitir-lhes
aumentar a eficácia de desempenho através de processos cada vez mais integrados e otimizados e,
portanto: acelerar a introdução de produtos; facilitar novas alianças empresariais; melhorar a
qualidade e confiabilidade dos produtos; reduzir os custos de projeto, produção e suporte; e oferecer
produtos e serviços novos e inovadores [1].
Em linhas gerais, a automação industrial consiste no uso de sistemas de controle, como
computadores e robôs, e tecnologias de informação para lidar com diferentes processos e máquinas
em uma indústria para substituir o ser humano, em determinadas atividades. É o segundo passo
além da mecanização no escopo da industrialização.
Primeiramente o propósito da automação girava em torno do aumento da produtividade
(produção 24h/dia), e a redução do custo associado a operadores humanos. Embora, hoje, o foco da
automação está direcionado a melhoria da qualidade e flexibilização do processo de manufatura.
2
Na indústria automotiva, como exposto na figura 1.1, por exemplo, a instalação de pistões no
motor costumava ser feita manualmente com uma taxa de erro de 1-1.5%. Atualmente, esta tarefa é
desempenhada por maquinaria automatizada com uma taxa de erro de 0,00001% [2].
Figura 1.1 Montagem de motor feita por robôs, fabrica de motores Ford.
Este trabalho apresentada uma solução de automação para uma demanda de uma indústria
petroquímica no processo de carregamento de caminhões container a partir dos silos finais de
produção. O produto a ser comercializado é o ácido tereftálico, mais conhecido como PTA (purified
terephthalic acid) [3], sólido incolor que é atualmente uma commodity química e tem seu principal
uso como precursor na formação do polímero poliéster PET, em combinação com o etilenoglicol,
utilizado na produção de tecidos e garrafas plásticas. Vários milhões de toneladas são produzidas
anualmente.
Ao fim do processo de fabricação, o PTA é estocado em quatro silos com capacidade de duas
mil toneladas cada (figura 1.2). Se faz necessária uma operação eficiente por parte da logística para
controlar o estoque e escoamento da produção. Bem como entregar ao cliente um produto de
qualidade e na quantidade correta especificada no pedido.
3
Figura 1.2 Silos finais de produção e respectivas balanças rodoviárias A, B, C e D.
Na época do comissionamento da planta foi detectada uma lacuna no sistema de carregamento
deixando diversas atividades do processo sob responsabilidade do operador logístico dos silos finais
de produção PTA. Dentre essas atividades estão: o registro do valor final de peso carregado, a
configuração do peso a ser carregado e a interrupção manual do carregamento.
Além dos problemas relacionados a erro humano, foram detectadas outras falhas no sistema de
carregamento que serão detalhadas na próxima seção. A solução proposta consiste em uma melhoria
no atual sistema de carregamento através da melhoria do sistema de chão de fábrica e na automação
do processo de envio do registro de peso dos caminhões já carregados para o sistema de gestão
ERP. Como forma de implementar a solução, foram feitas modificações no software do CLP que
integra o controle de carregamento. O sistema foi interligado via rede a um computador (PC) de
interface que envia os dados de pesagem para o ERP da empresa passando pelo sistema
concentrador de informações (SCI).
Neste capitulo inicial serão abordados aspectos motivacionais, as características do processo de
carregamento e registro de peso que será automatizado e alguns dos problemas identificados no
sistema como um todo.
1.1 Apresentação do Sistema de carregamento e faturamento
O processo de venda se inicia com o contato entre o cliente e o setor comercial, onde são
especificados a quantidade a ser faturada e os detalhes de transporte do produto até o local de
armazenagem do cliente final. Após finalizada a negociação, o departamento comercial entra com
A B C D
4
um pedido de venda no módulo de faturamento do sistema de gestão corporativa ERP Protheus [4].
A figura 1.3 apresenta um diagrama de fluxo UML do processo como um todo.
Figura 1.3 Diagrama de fluxo do processo de venda e faturamento de PTA a granel.
O sistema de gestão gera uma notificação de venda para o setor de faturamento com as
informações do cliente, data de faturamento, entrega, quantidade de produto, entre outras
informações. No caso da venda a granel, são carregados caminhões com container tipo Dry Box de
tamanho 20 pés com liner (figura 1.4).
Figura 1.4 Container com liner para transporte de produto em pó.
No dia agendado para faturamento do pedido de venda, o faturista do departamento de logística
faz a liberação do pedido e, juntamente com um integrante da equipe de movimentação externa, cria
um documento chamado booking contendo como principais informações: quantidade de containers
do pedido e a identificação de cada um (container ID), peso a ser carregado e placa dos caminhões
de transporte.
5
O booking é passado aos operadores logísticos do setor de carregamento do turno vigente para
que o produto seja carregado nos caminhões. Os operadores iniciam então o carregamento do
produto em um dos quatro silos finais de produção (A, B, C ou D) seguindo o procedimento
descrito abaixo (figura 1.5):
Figura 1.5 Procedimento de carregamento de caminhão container.
O processo se inicia (1) com o set do valor de peso indicado no booking na IHM (interface
homem-máquina) Presys (figura 1.6). Para clientes no mercado nacional é usualmente carregado o
valor 27,5 toneladas e para exportação marítima o peso é fixado em 26 toneladas.
Figura 1.6 IHM Presys para setpoint de peso e módulo de balança rodoviária Digitron.
1.SelecionarsetpointdepesonaIHMPresys
2.Elevarplataformadecarregamento
3.Posicionarcaminhãoea?vartaradabalança
4.Conectarcabodeaterramentoao
caminhão
5.Abrirportasdocontainereposicionar
plataformadecarregamento
6.Conectarlineràtubulação
7.Abrirválvuladeinflamentodoliner
8.Ligarválvularota?va 9.Abrirválvuladeproduto
10.Apósfinalizaçãodocarregamento:registrar
pesofinal
11.Re?rarlinerelacrarocontainer,
reposicionarplataformaere?raraterramentoliberandoocaminhão.
6
Em seguida, o segundo passo (2) é elevar a plataforma para que o caminhão possa se posicionar
sobre a balança rodoviária. Com o caminhão na posição, o operador pressiona o botão “T” da IHM
da balança (figura 1.6) para zerar o peso do caminhão sem produto (3) e o cabo do aterramento é
conectado (4) à roda do caminhão. Então as portas do container são abertas e a plataforma é
posicionada (5), permitindo ao operador conectar o liner (figura 1.7) na tubulação de saída (6).
Figura 1.7 Posicionamento da plataforma e conexão do liner a tubulação
Posteriormente, o operador abre a válvula para inflar o liner (7) e aciona o motor da válvula
rotativa (8) que joga o produto dentro do container. Após alguns instantes, o LED de liberação de
carregamento indica o momento para acionar a abertura da válvula principal (9) deixando o produto
fluir para dentro do container.
Quando o peso na balança chega ao valor configurado na IHM Presys, a válvula principal é
fechada pelo sistema. Em seguida o motor da válvula rotativa é desligado e a válvula de
insuflamento fechada automaticamente.
O operador deve então tomar nota do peso final carregado junto ao booking (10), e proceder
com a liberação do caminhão (11) retirando e amarrando o liner, lacrando o container, movendo a
plataforma para posição inicial e retirando o cabo do aterramento.
Ao fim do turno, o booking é levado ao faturista que digita os dados no módulo de faturamento
do Protheus, permitindo enviar a nota fiscal ao cliente com o certificado de qualidade e registro
final de peso carregado em cada caminhão do pedido.
7
1.2 Declaração do problema
Com a operação da planta a plena carga e as sucessivas entregas aos clientes vieram à tona
problemas relacionados ao processo de carregamento e ao sistema como um todo.
Clientes alegavam que o peso registrado em nota era diferente (erro normalmente entre 200 e
600 kg) da quantidade real de produto descarregado em seu pátio, realizando verificações com
balanças rodoviárias próprias. O departamento de logística, com o apoio da gerência de manutenção
industrial, realizou diversos estudos em seu sistema identificando uma série de vulnerabilidades,
entre os procedimentos realizados pelos operadores logísticos e o sistema automatizado de
carregamento.
Dentre esses, aqui são apresentados os principais:
1. A anotação manual do peso final por parte do operador eleva o risco de erro desse
registro. O operador trabalha sob estresse, com uma alta carga de atividades de risco e
em um ambiente insalubre. Além disso, ainda há probabilidade de o faturista digitar de
forma errada esse registro no sistema.
2. Pelo procedimento, o registro de peso é realizado logo após o fechamento automático da
válvula principal e desligamento do motor da válvula rotativa, dessa forma, o produto
restante no liner antes de ser amarrado, não é contabilizado.
3. Tanto a comunicação do sistema de setpoint de peso (IHM Presys), como do módulo de
pesagem da balança rodoviária (IHM Digitron), foi implementada por sinais analógicos.
Foi verificado que cabos de força e de sinal passam na mesma calha gerando
interferência no valor do setpoint de peso, e peso real que chega ao software do CLP de
integração.
4. Devido ao sistema não possuir modo de dosagem preciso para o momento em que o peso
se aproxima do valor desejado, o sistema gerava pequenas diferenças de peso entre o
real e o ajustado no setpoint. Devido a isso, muitas vezes o operador encerra a pesagem
pressionando o botão de emergência com o intuito de deixar o peso mais próximo do
valor desejado.
Após o estudo, foi elaborado um relatório de análise de riscos onde foram priorizados os
problemas a serem atacados. Diversas disciplinas das áreas de manutenção e engenharia
trabalharam nesses problemas. A disciplina de automação industrial, ligada ao departamento de
manutenção, ao qual faço parte, teve como foco a interface entre o sistema de carregamento e o
ERP para envio automático dos dados de pesagem.
8
1.3 Objetivos
Este texto tem como objetivo apresentar a solução desenvolvida para realizar a integração entre
o sistema de carregamento nos silos finais de produção (chão de fábrica) e o sistema de gestão
corporativo Protheus Totvs na atividade de registro de pesagem.
Além disso, a solução também contemplou a resolução de outro problema relacionado: o ajuste
do setpoint de peso a ser carregado. Essa solução tem como foco a eliminação de erros quanto ao
registro de pesagem feita previamente pelos operadores logísticos e faturistas.
1.4 Justificativas
Devido aos altos custos relacionados a reengenharia do sistema de carregamento, o
departamento de logística buscou junto a diretoria industrial uma solução desenvolvida in loco.
Alguns dos problemas apresentados, foram identificados no período de comissionamento, porém,
devido a questões financeiras, não puderam ser tratados naquele momento.
Diante de tudo que foi posto anteriormente, se mostrou fundamental a intervenção realizada
como forma de melhorar o desempenho e confiabilidade do sistema reduzindo atividades que
constavam no procedimento operacional da área e eliminado o fator humano na possibilidade do
erro de registro de pesagem.
1.5 Organização da monografia
Este texto está organizado em quatro capítulos, incluindo essa introdução onde foi apresentado o
contexto e motivação para o trabalho.
No Capitulo 2 (Tecnologias Disponíveis), são apresentadas as tecnologias e infraestrutura
utilizadas para o desenvolvimento da solução.
No Capítulo 3 (Desenvolvimento da Solução), são apresentadas as modificações realizadas no
sistema de chão de fábrica e o que mais foi implementado para tornar possível o envio automático
das informações de pesagem.
No Capítulo 4 (Conclusão), são discutidos os resultados do trabalho e apresentadas propostas de
melhoria futura.
9
Capítulo 2
Tecnologias disponíveis
A arquitetura presente do sistema de carregamento é formada pelos seguintes módulos: seleção
de peso, controle de fluxo do produto silo/caminhão, sistema de pesagem (balança rodoviária) e
CLP (Controlador Lógico Programável) de integração dos sistemas. Anteriormente esse conjunto
não possuía qualquer comunicação com o ERP da empresa, que controla as informações gerenciais
de controle de estoque, faturamento entre outras.
A integração entre o sistema de chão de fábrica que controla a pesagem e o sistema gerencial foi
desenvolvida pela equipe de automação industrial como resposta a demanda do departamento de
logística. Essa integração se utilizou da infraestrutura existente e do desenvolvimento de soluções
focadas na robustez e no menor custo final de desenvolvimento para companhia.
Nesse capítulo são apresentadas as tecnologias e ferramentas que serviram de base para o
desenvolvimento da solução de integração.
10
2.1 CLP S7-200
A escolha pelo uso de CLPs para automação de sistemas industriais é predominante devido aos
seguintes fatores:
• Elevada confiabilidade, robustez e eficiência.
• Baixos custos de instalação e operacionalidade.
• Menor espaço e menor consumo de energia elétrica.
• Maior rapidez e flexibilidade na elaboração dos projetos.
• Capacidade expansão futura.
• Fácil integração em sistemas existentes.
No comissionamento da fábrica foi verificada uma lacuna de integração que impedia o
funcionamento do sistema de pesagem. Não havia interface entre o sistema de controle dos silos e o
sistema das balanças rodoviárias. Essa lacuna foi preenchida através utilizando-se um CLP Siemens
S7-200 (figura 2.1) juntamente com cartões de entrada analógica e digital. Esse CLP foi escolhido
por atender aos requisitos do projeto e ter sido utilizado vastamente em outras partes da fábrica,
facilitando sua disponibilidade, e substituição em caso de defeito.
Figura 2.1 Siemens S7-200 modelo 224 utilizado no projeto.
O CLP S7-200 [5] é um sistema baseado em microprocessador voltado para ambientes
industriais que desempenha funções de controle de diversos tipos e níveis de complexidade. A
tabela 1 descreve as características do modelo utilizado no projeto SIMATIC S7-200 224. A
informação vinda dos sensores é recebida por módulos de entrada e repassada a unidade central de
11
processamento (CPU – Central Processing Unit) que de acordo com um programa em memória
define o estado das saídas. É necessária uma proteção especial para os módulos de entrada e saída
isolando-os da CPU, para que esta fique protegida de danos que o ambiente industrial pode trazer
através das linhas de entrada.
Tabela 1 Características do CLP S7200 224 (Referência Siemens 6ES7214-1AD23-0X40).
Tensão de Alimentação 20.4V a 28.8V Tensão de Alimentação de carga L+ 20.4V a 28.8V
Máxima corrente de entrada 12A; a 28.8V Memória de dados 8 kbyte
Memória de programa 12 kbye Número de contadores 256
Número de Temporizadores 256 Número máximo de cartões de expansão 7
Saídas Digitais 10 Entradas Digitais 14
Interface integrada RS485 Dimensões 120,5mm x 80mm x 62mm
Para desenvolvimento do programa do CLP S7-200 foi utilizado o software STEP 7-Micro/Win
(figura 2.2) compatível com Windows XP. Este software é composto por um ambiente de
desenvolvimento, edição, comunicação e monitoramento do programa executando no CLP. Há três
opções de linguagem para codificação: lista de texto estruturado (STL), diagrama Ladder ou
diagrama de blocos. No caso específico desse projeto foi utilizada predominantemente a linguagem
Ladder.
12
Figura 2.2 Tela principal do software STEP 7-Micro/Win.
O computador utilizado no desenvolvimento (que possui o software STEP 7-Micro/Win) se
comunica com o CLP para download/upload/monitoramento através de um cabo com protocolo
Siemens PPI (point to point interface) ligado a porta serial.
Como as interfaces integradas no CLP não eram suficientes para o projeto, foram utilizados
cartões de expansão de entrada/saída analógica e digital. Os seguintes cartões foram utilizados:
• Siemens EM 221 DC (6ES7221-1BH22-0XA0), cartão de expansão para CLP S7-200
com 16 entradas digitais 24V DC.
• Siemens EM 222 DC (6ES7222-1BF22-0XA0), cartão de expansão para CLP S7-200
com 8 saídas digitais 24V DC.
• Siemens EM 231 (6ES7231-0HC22-0XA0), cartão de expansão para CLP S7-200 com 4
entradas analógicas, 0 a 10V DC, com conversor de 12 bits.
• Siemens EM 232 (6ES7232-0HD22-0XA0), cartão de expansão para CLP S7-200 com 4
saídas analógicas entre -10 a 10 V DC (corrente de saída entre 4 a 20 mA), com
conversor de 12/11 bits.
Para comunicação com outros sistemas o CLP S7-200 224 utilizado possui uma porta serial com
protocolo RS 485 integrado.
13
2.2 Rede RS485
A interface RS485 foi escolhida como forma de comunicação entre o CLP S7-200 que integra o
sistema de controle de carregamento e o PC utilizado na integração de dados. A Tabela 2 apresenta
as principais características que levaram a escolha de tal interface. Além de ser a interface padrão
integrada nesse CLP, a razão principal para a escolha foi devido a esse padrão atender aos requisitos
do comunicação do projeto. É uma interface muito usual na aquisição de dados de sistemas de chão
de fábrica.
TIA-485-A (ANSI/TIA/EIA-485) usualmente conhecido como RS-485 é um padrão que define
as características elétricas dos drivers e receptores para uso em sistemas digitais balanceados
multiponto. O padrão é mantido pela Telecommunications Industry Association (TIA) e pode ser
utilizado em redes digitais de longa distância em ambientes com presença de ruído elétrico.
Múltiplos receptores podem se conectar a uma rede RS-485 em uma configuração linear, com todos
ligados ao mesmo barramento.
Tabela 2 Principais características das interfaces RS-232, RS-422 e RS-485 [06].
Especificações RS-232 RS-422 RS-485 Modo de operação Single-end Diferencial Diferencial Número total de
transmissores/receptores no barramento
1 transmissor e 1 receptor
1 transmissor e 9 receptores
1 transmissor e 31 receptores
Comprimento total do cabo 15m 1,2km 1,2km Taxa máxima de transferência 20Kbps 10Mbps 10Mbps Tensão máxima de saída do
transmissor +/- 25V -0,25V a +6V -7V a +12V
Nível do sinal de saída do transmissor (carga mínima)
+/- 5V a +/- 15V
+/- 2,0V +/- 1,5V
Nível do sinal de saída do transmissor (sem carga)
+/- 25V +/- 6V +/- 6V
A norma descreve uma interface de comunicação operando em linhas diferenciais capaz de se
comunicar com 31 “unidades de carga”. Normalmente, um dispositivo transmissor/receptor
corresponde a uma “unidade de carga”, o que faz com que seja possível comunicar com até 31
dispositivos. Entretanto, existem dispositivos que consomem frações de unidade de carga, o que
aumenta o número máximo de dispositivos a serem interligados. O meio físico mais utilizado é um
par trançado. Através deste único par de fios, cada dispositivo transmite e recebe dados. Cada
dispositivo aciona o seu transmissor apenas no instante que necessita transmitir, mantendo-o
desligado no resto do tempo de modo a permitir que outros dispositivos transmitam dados. Em um
14
determinado instante de tempo, somente um dispositivo pode transmitir, o que caracteriza esta rede
como half-duplex. Uma rede RS485 pode também utilizar 2 pares trançados, operando no modo
full-duplex, totalmente compatível com RS422. Existem conversores para comunicação com
dispositivos USB (figura 2.3).
O RS485 se caracteriza pela utilização de um meio de comunicação diferencial que é menos
sensível a interferência eletromagnética, por apresentar rejeição de modo comum. Os circuitos
transmissores e receptores adotados nestas interfaces utilizam como informação a diferença entre os
níveis de tensão em cada condutor do par trançado. Esta técnica resulta no cancelamento de ruídos
induzidos no meio de transmissão, pois se o mesmo ruído é induzido nos 2 condutores, a diferença
de tensão entre eles não se altera e a informação é preservada. A interferência eletromagnética
emitida por um barramento de comunicação diferencial é também menor que a emitida por
barramentos de comunicação não-diferenciais.
Figura 2.3 Conversor RS-485 para USB utilizado no projeto.
A norma não define qual o protocolo a ser utilizado para a comunicação dos dados, e é adotada
como especificação da camada física de diversos protocolos, como, por exemplo, Modbus, Profibus
e DIN-Measurement-Bus. Essas características fazem esse padrão vantajoso para utilização em
ambiente industrial.
2.3 Sistema Concentrador de Informações (SCI) - MES
Manufacturing Execution Systems (MES) [7], é o termo usado para designar os sistemas
computadorizados focados no gerenciamento das atividades de produção e que estabelecem uma
ligação direta entre o planejamento e o chão de fábrica. Serve de ferramenta a gestão para otimizar a
15
produção baseado nas informações da planta em tempo real. São utilizados para rastrear e
documentar, todo o fluxo da transformação de matéria prima em produto final. A importância destes
sistemas vem da lacuna que normalmente existe entre o ERP (Entreprise Resource Planning) e os
softwares específicos da linha de produção.
O MES pode importar dados do ERP e integrá-los com o dia-a-dia da produção, gerenciando e
sincronizando as tarefas produtivas com o fluxo de materiais. Haja visto que na cadeia de
suprimento o maior valor agregado esta na produção, investir em sistemas que otimizem o fluxo,
controle e qualidade do material se faz essencial.
Estas são algumas das funções que os sistemas MES costumam ter:
• Importação de dados do sistema ERP: itens, estações de trabalho, armazenagem,
estoque, planos da qualidade, dados de funcionários, etc.
• Importação de parâmetros para a produção, como pedidos e prioridades de manufatura.
• Emissão automatizada de instruções para que o armazém entregue o material nas células
de trabalho.
• Exibição da fila de trabalho, instruções e documentação específica para a célula de
trabalho, em função das prioridades definidas anteriormente.
• Armazenamento das informações de atividades da produção: tempos de operação (por
operador), tempos de máquinas, componentes usados, material desperdiçado, etc.
• Instruções para reposição de material na linha de produção.
• Armazenamento e divulgação dos dados de qualidade (inspeções, check lists e não
conformidades)
• Instruções para a continuidade do fluxo de materiais pela linha.
• Análise de métricas e desempenho da produção;
• Integração do ERP com o chão de fábrica;
• Apontamento de mão de obra;
• Controle estatístico do processo (CEP) e de indicadores de capacidade (Cp, Cpk);
• Monitoramento on-line da produção (paradas, ritmo de produção, refugos e retrabalhos);
• Gestão on-line da produtividade de máquinas (OEE) e mão de obra (OLE);
• Controle das ocorrências e indicadores de Manutenção (MTBF, MTTR);
Baseado na hierarquia funcional da automação (figura 2.4) o sistema MES se encontra na
camada 4, entre o sistema ERP na camada 5 e os demais sistemas de controle de processo nas
camadas 1 (sensores, atuadores, hardware), camada 2 (CLPs, computadores e sistemas de controle
PID) e camada 3 (redes e sistema de supervisão e aquisição de dados – SCADA) .
16
Figura 2.4 Pirâmide da automação.
O sistema MES utilizado nesse projeto é o sistema concentrador de informações (SCI). O SCI
foi projetado como uma solução customizada de integração entre diversos sistemas de chão de
fábrica e o ERP Protheus da empresa Totvs.
Figura 2.5 Rack do SCI no data center de TI.
17
A estrutura física do sistema SCI é composta por dois servidores Sun Entreprise Sparc T4-2
(figura 2.5) com sistema operacional Oracle solaris 11 e por um storage Pillar Axion com 32TB de
memória em disco. Os dois servidores funcionam em cluster, ou seja, apesar de serem duas
máquinas separadas, elas trabalham como se fosse uma só (interconectadas via fibra ótica de alta
velocidade). A aplicação se utiliza do banco de dados Oracle 11G com a opção Oracle Real
Application Clusters (RAC) que permite executar várias instâncias de banco de dados em
servidores diferentes no cluster. A base de dados abrange vários sistemas de hardware e ainda
aparece como um único banco de dados unificado para a aplicação. Isto permite fornecer um
ambiente de computação escalável que suporta várias cargas de trabalho de aplicativos.
O SCI, na arquitetura de rede (figura 2.6), se encontra interconectado à rede do departamento de
tecnologia da informação (TI) apesar de ter seu gerenciamento e operação vinculado ao
departamento de manutenção – automação, ou, tecnologia de automação (TA). O rack dos
servidores (figura 2.5) fica localizado fisicamente localizado no data center da TI dentro da
companhia.
Figura 2.6 Estrutura de rede que liga o SCI aos demais servidores.
Em termos de funcionalidade, o SCI pode ser caracterizado como um sistema Extract, Load and
18
Transform (ELT), que é uma ferramenta de software cuja função é a extração de dados de sistemas
homogêneos ou heterogêneos, carga desses dados em um data warehouse, e transformação desses
dados conforme regras de negócio. Normalmente essas três fases são executadas em paralelo, já que
a extração de dados é uma fase demorada. O data warehouse, ou, armazém de dados, ou
ainda, depósito de dados, é utilizado para armazenar informações relativas às atividades de uma
organização em bancos de dados, de forma consolidada. O desenho da base de dados favorece os
relatórios, a análise de grandes volumes de dados e a obtenção de informações estratégicas que
podem facilitar a tomada de decisão.
Antes do desenvolvimento da interface proposta nesse trabalho que foi acrescentada projeto, o
SCI realizava a integração dos seguintes sistemas com o ERP Protheus:
• TMT: sistema da empresa TMT Machinery composto por servidores Linux, com banco
de dados Oracle 11G responsáveis pela integração de dados das 64 máquinas
texturizadoras. Cada máquina texturizadora tem como entrada 240 bobinas de fio tipo
partially oriented yarn (POY) e gera a partir desses fio Draw Textured Yarn (DTY, fio
de poliéster pronto para produzir tecido). O sistema registra dados de produção de cada
bobina produzida, armazena no banco de dados e é sincronizado com o SCI via Oracle
GoldenGate.
• MWS: sistema da empresa Toledo do Brasil responsável pelo rastreamento de cada
bobina após sair da máquina texturizadora, pesagem automatizada de caixas (seis
bobinas por caixa), robô para montagem de palete (vinte caixas) e transferência
automatizada para o armazém através de esteiras. O sistema é composto por um servidor
VMware com cinco servidores Windows Server virtualizados. Um para o banco de
dados Microsoft SQL Server, e os outros quatro ligados a terminais em cada máquina
texturizadora. O sistema MWS disponibiliza dados para o SCI através de um Web
service.
• WMS: sistema da empresa coreana SMC responsável pelo gerenciamento de um
armazém automatizado, ou automated storage retrieval system (AS/RS). O armazém
automatizado da logística recebe os paletes de poliéster produzido e armazena em uma
de suas vinte seis mil posições passando por de esteiras e transelevadores. Também tem
a função de armazenagem de paletes de matéria prima, bobinas de fio POY. O sistema é
composto por servidores Linux, com banco de dados Oracle 11G responsáveis pelo
sistema de movimentação de cargas dentro do armazém. É sincronizado com o SCI via
Oracle GoldenGate.
• Lurgi: sistema da empresa alemã Lurgi responsável pelo carregamento de ensacadeiras
19
(big bag machine) e carregamento a granel (caminhões container) para as linhas de
produção de resina PET. O sistema é composto por um PC que serve de IHM com o
software Siemens WinCC para controle de carregamento. A comunicação com o SCI se
dá através da ferramenta MatrikonOPC, que lê as tags do WinCC via protocolo OPC e
sincroniza com o SCI via ODBC.
• LIMS: sistema da empresa americana LabWare para controle e gerenciamento de
laboratório industrial. Composto por servidores Windows Server, com banco de dados
Oracle 11G. Se comunica com o SCI via Oracle GoldenGate.
Como foi apresentado, o SCI interliga diversos projetos heterogêneos: diferentes sistemas
operacionais, bancos de dados, localização física. O sistema foi especificado internamente e
desenvolvido em Belo Horizonte - MG (empresa Casa de Software) utilizando as mais recentes
tecnologia de bancos de dados, data warehouse e business intelligence da empresa americana
Oracle.
2.4 Oracle Database, Oracle ODI e Oracle GoldenGate
O banco de dados Oracle [8] é o líder de mercado e o preferido de centenas de milhares de
empresas, além de desenvolvedores de aplicativos e administradores de bancos de dados no mundo
inteiro. Ao longo dos anos, as empresas passaram a contar com o banco de dados Oracle para
oferecer performance e confiabilidade como grande diferencial. Na versão 10g do banco de dados, a
Oracle ofereceu um banco de dados de autogerenciamento com capacidade inovadora, reduzindo
drasticamente os custos de gerenciamento. A Oracle elevou o nível com o lançamento do Banco de
Dados Oracle 11g (utilizado na maior parte dos projetos apresentados na seção anterior). Projetado
para ambientes de data center em rápida evolução e transformação para acompanhar as demandas
dos negócios, o Banco de Dados Oracle 11g permite às empresas adotar novas tecnologias
rapidamente, ao mesmo tempo minimizando o risco. Além disso, fundamentado em seus recursos
de autogerenciamento, fez avanços significativos nas áreas de capacidade de gerenciamento e
diagnóstico de falhas.
O Oracle Data Integrator (ODI) [9] é uma ferramenta extract, load and transform (ELT)
produzida pela Oracle que oferece um ambiente gráfico para construir, gerenciar e manter processos
de integração de dados em sistemas de business intelligence (BI). BI é o processo de coleta,
organização, análise, compartilhamento e monitoramento de informações que oferecem suporte a
gestão de negócios.
20
Oracle Data Integrator (figura 2.7) é construído em vários componentes, todos trabalhando
juntos em torno de um sistema centralizado de repositório de metadados. Esses componentes,
módulos gráficos, agentes de execução e interfaces baseadas em web, em conjunto com outras
características avançadas tornam ODI leve, legacy-free, estado da arte entre as plataforma de
integração. A arquitetura ODI é organizada em torno de um repositório modular, que pode ser
acessado no modo cliente-servidor por componentes como: o Estúdio ODI e agentes de execução
que são inteiramente escritos na linguagem em Java. A arquitetura também inclui um aplicativo
baseado na web, o ODI Console, que permite aos usuários acesso à informação através de uma
interface web e uma extensão para o Oracle Fusion Middleware Controle Console.
Figura 2.7 Diagrama do ODI Studio e seus módulos.
O ODI Studio fornece quatro opções gráficas para gerenciar artefatos: Designer, Operator,
Topology e Security.
• Designer: define regras declarativas para transformação e integridade de dados. Todo
projeto de desenvolvimento ocorre neste módulo, que é onde banco de dados e
metadados do aplicativo são importados e definidos. O módulo de Designer usa
metadados e regras para gerar dados de cenários de integração ou planos de carga para
a produção. Este é o módulo central para desenvolvedores e administradores de
metadados.
• Operator: módulo de gerenciamento que monitora os processos de integração de
dados em produção. Ele é projetado para operadores e exibe os logs de execução com
contagens de erro, o número de linhas processadas, estatísticas de execução, o código
real que é executado, e assim por diante. Em tempo de projeto, os desenvolvedores
podem também usar o módulo operador para fins de depuração.
21
• Topology: define a arquitetura física e lógica da infraestrutura. Permite a
administradores registrar servidores, esquemas de banco de dados e catálogos,
e agentes no repositório principal através deste módulo.
• Security: gerencia perfis de usuários e seus privilégios. Também pode atribuir acesso
e autorização para objetos e recursos. Os administradores de segurança geralmente
usam este módulo.
Todos os módulos armazenam suas informações no repositório centralizado. O ODI possui
uma interface gráfica de fácil utilização para o usuário e pode ser instalado em várias plataformas,
como Microsoft Windows, Linux e Mac OS.
Em tempo de execução, o agente coordena a execução dos cenários ODI. Ele recupera o
código armazenado dentro o repositório ODI, conecta-se a vários sistemas de origem e destino e
organiza os dados globais do processo de integração. Existem dois tipos de agentes:
• O agente autônomo: pode ser instalado nos sistemas de origem ou destino e requer
uma máquina virtual Java (JVM).
• O Java EE Agent: é implantado no Oracle WebLogic Server e podem se beneficiar
da camada que o servidor de aplicação apresenta como cluster para os requisitos de
alta disponibilidade.
Com a arquitetura Extract Transform Load (ELT), o agente raramente executa qualquer
transformação de dados. Ele simplesmente recupera código do repositório do ODI e dos diversos
servidores de banco de dados da integração, operando sistemas ou mecanismos de script para
executar esse código. Quando a execução é concluída, as atualizações são registradas no repositório
pelo agente e, em seguida, são reportadas mensagens de erro e estatísticas de execução. Os usuários
podem revisar os logs de execução no módulo Operator. É importante compreender que, embora o
agente pode atuar como um mecanismo de transformação, é raramente utilizado para esse efeito. Os
agentes são instalados em locais táticos no sistema de informação para coordenar os processos de
integração e alavancar os sistemas existentes. Eles são de vários segmentos, com balanceamento de
carga, componentes leves nessa arquitetura de integração distribuída.
O Repositório consiste em um repositório principal e, normalmente, vários repositórios de
trabalho. Estes repositórios são conjuntos de tabelas armazenadas em sistemas de gerenciamento de
banco de dados relacionais, como Oracle, Microsoft SQL Server, IBM DB2 e outros. Todos os
objetos que os módulos ODI podem configurar, desenvolver, ou utilizar são armazenados em um
desses repositórios, e são acessados no modo cliente-servidor, além dos vários componentes da
22
arquitetura. O repositório principal contém as informações de segurança (perfis de usuário e
privilégios), a topologia das informações (definições de tecnologias e servidores), e o código fonte
para todas as versões de todos os objetos ODI. As informações contidas no repositório principal é
mantida com os módulos Topology e Security no ODI Estúdio, bem como com no ODI Console.
Objetos do projeto são armazenadas em um repositório de trabalho. Vários repositórios de
trabalho podem coexistir na mesma instalação. Isto é útil para manter ambientes separados ou para
refletir a versão do ciclo de vida. Um instância do repositório de trabalho armazena informações
para:
• Modelos (metadados): incluindo armazenamentos de dados, colunas, restrições de
integridade de dados, referências cruzadas, linhagem de dados e análise de impacto.
• Projetos: incluindo as interfaces, pacotes, procedimentos, pastas, módulos de
conhecimento e variáveis.
• Informação: incluindo cenários, planos de carga, informações de agendamento e
registros. Os usuários podem gerenciar o conteúdo de um repositório de trabalho com
os módulos Design e Operator no ODI Studio.
O agente em tempo de execução também acessa repositórios de trabalho. Quando um
repositório de trabalho é usado apenas para armazenar informações de execução (geralmente para
fins de produção), é chamado de um repositório de execução. Um repositório de execução é
acessado em tempo de execução com o módulo Operator, ODI Console e pelo agentes. É
importante lembrar que cada repositório de trabalho está sempre ligado a um e só um repositório
mestre.
O ODI Console é uma aplicação Java Enterprise Edition (Java EE) que permite o acesso
web à repositórios. Ele permite aos usuários procurar objetos de tempo de design, incluindo
projetos, modelos e execução registros. Através de sua interface web, os utilizadores podem ver os
mapas de fluxo, rastrear a origem de todos os dados, e até mesmo ir até o nível de campo para
entender as transformações usadas para construir os dados. Além disso, usuários finais podem
lançar e acompanhar a execução através de cenários no ODI Console. Pode ser instalado no Oracle
WebLogic Server e também oferece aos administradores a capacidade de visualizar e editar objetos
de topologia, tais como servidores de dados, esquemas físico e lógico, bem como para gerenciar
seus repositórios. Oracle Data Integrator oferece uma extensão para o Oracle Enterprise Manager
Fusion Middleware que permite aos usuários finais monitorar seus componentes ODI, juntamente
com outros módulos Fusion Middleware a partir de um único console de administração.
23
O Oracle GoldenGate [10] é uma aplicação de elevado desempenho destinada à captura,
transação, transformação, o encaminhamento (routing) e entrega de dados, em tempo real, e permite
a replicação bidirecional dos dados baseada em registros. A aplicação garante a sistemas críticos
operacionalidade durante vinte e quatro horas, sete dias por semana e proporciona a distribuição dos
dados por toda a empresa para otimizar o processo de decisão. É focado em bases de dados de
sistemas heterogéneos. O software possui um elevado desempenho, baixo impacto no processo com
uma latência (tempo de espera) de microssegundos para uma grande variedade de bases de dados e
o encaminhamento (routing) exigências de integração dos diversos sistemas da empresa.
2.5 ERP Protheus
O Protheus [11] é uma linha de software para planejamento corporativo de recursos (ERP) e
gestão de relacionamento com o cliente (CRM), baseada na tecnologia By You. Os processos de
negócio do software abrangem processos administrativos e setoriais nas áreas de agroindústria,
construção e projetos, distribuição e logística, educacional, serviços financeiros, jurídico,
manufatura, saúde, serviços e varejo. Criada e desenvolvida atualmente pela TOTVS, a plataforma
by You, suporta o desenvolvimento de todo o portfólio de produtos que envolvem gestão, negócios e
colaboração. Ela garante independência tecnológica oferecendo diversas linguagens de
desenvolvimento e ambientes de execução próprios. Essas características permitem que os produtos
da TOTVS sejam compatíveis com qualquer plataforma de hardware, banco de dados ou modelos
de processamento.
O software de gestão permite o gerenciamento integrado dos processos desde a fabricação até
a rede de distribuição, possibilitando o controle em tempo real das necessidades da empresa e de
seus custos. São atendidas as camadas operacionais, táticas e estratégicas, deste as áreas de
inovação, produção, vendas, entrega e acompanhamento de clientes, até soluções de backoffice. As
diversas áreas são atendidas por módulos específicos, para as áreas principais do negócio, temos os
seguintes módulos: engenharia de produto e processo, desenvolvedor de produtos, planejamento e
controle da produção, planejamento avançado da produção, chão de fábrica, gestão da qualidade e
rastreabilidade. Para as áreas administrativas de suporte ao negócio (backoffice) temos: gestão de
contratos, compras e suprimentos, estoques e custos, vendas e faturamento, financeiro, contábil,
fiscal, ativo imobilizado, planejamento e controle orçamentário, comércio exterior e gestão de
capital humano (HCM). Apresenta ainda outras soluções complementares como: CRM e call center,
gestão de frete embarcador, gestão de armazenagem (WMS), gestão de investimentos, relatórios e
indicadores gerencias (Business Analytics – BA), entre outros.
24
2.6 Considerações finais
Este capítulo apresentou as estruturas física e as principais tecnologias que foram utilizadas
para automatizar o processo de carregamento e envio de dados de pesagem ao ERP. Foi apresentado
o CLP S7-200 e cartões de entrada/saída utilizado na integração do sistema de carregamento e a
infraestrutura de rede RS-485 utilizado no envio de dados ao PC de interface.
Em seguida, foi apresentado o sistema MES utilizado, o SCI, bem como os sistemas de
chão de fábrica que se utilizam do SCI para intercâmbio de informações com o ERP. As tecnologia
da empresa Oracle que serviram como base para a construção do SCI foram apresentadas na seção
2.4. Finalmente, foi introduzida uma visão geral do software Protheus Totvs utilizado como sistema
de gestão corporativa da companhia.
25
Capítulo 3
Implementação da Solução
Baseado nas tecnologias apresentadas no capítulo anterior, foi desenvolvida a integração
entre o sistema de carregamento e o módulo de faturamento do ERP Protheus. O objetivo principal
desse projeto foi tirar a atividade de registro do peso dos procedimentos realizados pelo operador
logístico. A seguir será apresentada a arquitetura do sistema antes e depois das modificações . Serão
detalhados todos os aspectos que envolveram as diversas camadas de sistema para que as
informações de pesagem fossem levadas de forma automatizada até o módulo de faturamento do
sistema de gestão corporativa.
3.1 Arquitetura Inicial do Sistema de Carregamento dos Silos Finais de Produção
No comissionamento da planta de PTA foi descoberta uma lacuna no projeto do sistema de
carregamento de caminhões que impedia a operação do escoamento do produto acabado nos quatro
silos finais de produção (A, B, C e D). A empresa Coperion, responsável pelo projeto de automação
dos silos, disponibilizava o sistema de controle das válvulas e das plataformas de carregamento.
Porém, esse sistema não possuía interface com o módulo de pesagem da balança rodoviária (de
fornecimento da empresa Digitron).
A equipe interna de automação projetou o sistema de integração (CLP Siemens S7-200,
mostrado na figura 3.2) com dois painéis para os quatro silos: um para os silos A e B, e outro para
26
os silos C e D. Tal sistema (figura 3.1) serve de interface de controle enviando para o sistema da
Coperion a liberação para início do carregamento e o sinal de finalização quanto o setpoint de peso
é alcançado.
Figura 3.1 Arquitetura do Sistema de Carregamento dos Silos Finais de Produção. Inicialmente o módulo de
comunicação RS-485 não era utilizado.
O projeto inicialmente se limitava a automação de chão de fábrica, não sendo previsto
comunicação com sistemas supervisórios ou de gerenciamento logístico.
27
Figura 3.2 Visão interna do painel do sistema de integração dos silos A e B composto por CLP S7-200, cartões de
entrada e saída (analógicos e digitais) e demais periféricos (fonte de alimentação, disjuntores, barreiras de proteção, relés).
Antes das modificações descritas nesse trabalho, o sistema de integração que viabilizou o início
das atividades de carregamento obedecia o seguinte fluxo:
1. Receber o sinal de “tara” da balança (figura 3.3) rodoviária após posicionamento do
caminhão (valor “zero kg” vindo via sinal analógico do módulo de pesagem);
Figura 3.3 Botão de "tara" no módulo de pesagem (Digitron).
28
2. Receber as informações do setpoint de peso configurado pelo operador logístico na IHM
Presys, figura 3.4 (comunicação via sinais analógicos entre o módulo Presys e o cartão
de entrada analógica do S7-200);
Figura 3.4 IHM de seleção e monitoramento de peso (Presys).
3. Monitorar se o caminhão já está aterrado, figura 3.5 (sinal digital vindo do sistema da
Coperion) para, em caso positivo, liberar a permissão para início carregamento (sinal
digital de retorno ao sistema Coperion, figura 3.6);
Figura 3.5 Cabo de aterramento corretamente posicionado na carcaça do caminhão container.
29
Figura 3.6 Sinal de permissão para início do carregamento (Selection Clearance), pré-requisitos: peso ajustado, "tara" da
balança realizada e aterramento corretamente posicionado.
4. O operador então inicia os procedimentos de carregamento e o sistema de integração
monitora continuamente o peso da balança com o setpoint ajustado para enviar o sinal de
termino do carregamento ao atingir o peso desejado.
Com esse projeto foi possível iniciar a operação do sistema de carregamento de caminhões
container, permitindo esvaziar os silos das primeiras bateladas de produção de PTA da planta.
Devido as características do sistema, o peso carregado apresenta uma margem de variação e essa
informação deve constar nas documentações de venda enviada ao cliente. Porém, o registro do valor
de peso final de cada carregamento foi adotado como procedimento para os operadores logísticos,
preenchendo essa informação no documento de booking onde constam os detalhes do caminhão
carregado. A arquitetura inicial foi modelada na figura 3.7 como diagrama casos de uso UML. No
fim de cada turno, o booking é devolvido aos faturistas que tem a incumbência de digitar todos os
registros de peso no módulo de faturamento do ERP Protheus.
30
Figura 3.7 Fluxo prévio do registro de peso dos carregamentos de PTA.
3.2 Mudança na Arquitetura para automação do registro de pesagem de caminhões
O foco principal do projeto descrito nesse texto consiste na modificação do procedimento
de coleta de dados de pesagem após o carregamento do caminhão container. Tal modificação foi
realizada com o desenvolvimento da funcionalidade de envio automatizado de registro de pesagem
através de vários sistemas até o módulo de faturamento do ERP Protheus. A figura 3.8 é uma
modelagem de casos de uso UML do sistema, após as modificações propostas serem implantadas.
Foram adicionados dois novos elementos ao fluxo apresentado acima: um computador
que serve de interface recebendo os dados de pesagem do CLP do sistema de integração (com
comunicação via rede RS-485) e o SCI (ethernet e tcp/ip).
Figura 3.8 Fluxo final do sistema de carregamento com registro automatizado de pesagem.
A solução final demandou os seguintes esforços: modificação no software do CLP do
sistema de integração acrescentando a funcionalidade de comunicação em rede serial, projeto de um
protocolo para envio de dados de pesagem, desenvolvimento de software para o PC de interface,
geração de tabelas para registro dos dados no SCI, e modificações nas funcionalidades do SCI e do
ERP Protheus para permitir adicionar a funcionalidade do registro automatizado.
31
3.3 Modificações no software do CLP de do sistema de integração
A primeira tarefa realizada para implementação do sistema foi acompanhar por uma
semana o processo de carregamento e registro. Também foi necessário estudar o código do CLP do
sistema de integração para que as modificações não tivessem impacto negativo na funcionalidade de
controle do carregamento.
A partir dessa avaliação inicial, foi definido como seria desenvolvido o projeto. Além do
envio da informação de pesagem, foi realizado uma modificação na forma como o setpoint de peso
é escolhido. Previamente o operador logístico utilizada a IHM Presys para selecionar o peso a ser
carregado. Porém, foi detectado que essa informação não estava chegando ao CLP S7-200 de forma
correta. A comunicação entre a IHM Presys e o CLP s7-200 se dá através de sinal analógico e os
cabos responsáveis por essa comunicação estavam sofrendo interferência de cabos de alta tensão
passando no mesmo pipe rack. Como a operação possui somente duas configurações usuais de peso,
a entrada de dados na IHM Presys foi substituída por um botão seletor de peso (figura 3.9).
Figura 3.9 Botão seletor de peso (26 ou 27,5 toneladas).
Utilizando a interface serial RS-485 integrada ao CLP S7-200 224, foi implementada a
funcionalidade de envio automático do peso do caminhão. No código fonte, foi implementada uma
nova subrotina (SBR) específica para envio de dados para cada silo “com_silo_1” e “com_silo_2”
(um CLP controla silos A e B e outro os silos C e D). Essa rotina envia o peso carregado cinco
minutos após o operador parar o carregamento na chave seletora start/stop.
Previamente o sistema parava o carregamento automaticamente comparando o peso do
setpoint com o peso recebido do módulo de pesagem porém, devido a problemas de projeto, o
caminhão estava sendo carregado com o um peso cerca de 2% acima do valor configurado (quando
o erro deve estar em torno de 0,6%). O sistema não possui um modo de carregamento preciso para o
32
momento em que o valor de peso se aproxima do que foi configurado, por isso, a tarefa de
interromper o carregamento ficou a cargo do operador logístico que aciona a chave start/stop para
fechar a válvula de alimentação de produto. A parada automática do sistema ainda existe no
software porém, só é utilizada em caso emergencial caso o operador não faça a interrupção manual.
Na implementação do envio de dados de pesagem, a informação é enviada cinco minutos
após o recebimento do sinal de parada do carregamento. Esse período foi acordado com a operação
e é o tempo suficiente para que o operador coloque o restante do produto que fica na boca do liner
dentro do container.
3.3 Definição do Protocolo e software do PC de interface
Para comunicação entre o CLP S7-200 do sistema de integração e o PC de interface foi
definido um protocolo para transmissão de dados utilizando a rede serial RS-485. Nesse protocolo
estão descritas as informações referentes a cada carregamento em um dos quatros silos disponíveis
(A, B, C ou D). Ao término de cada pesagem a mensagem é enviada duas vezes para o PC de
interface como forma de confirmação. A palavra enviada é composta por 25 bytes organizados
conforme a tabela 3.
Tabela 3 Palavra de 25 bytes do protocolo de envio de peso.
Posição do byte Valor em hexadecimal Informação 1° AA início da transmissão, caracter ª em ascii 2° 43 ou 4D 43 – letra C em ascii para caso de parada
automática do carregamento 4D – letra M em ascii para parada manual
3° 30 0 em ascii – primeiro dígito do número do silo
4° 31ou 32 ou 33 ou 34 1, 2, 3 ou 4 em ascii – para respectivamente silo A, B, C ou D
5° e 6° AA e AA Separador, caracteres ªª em ascii 7° ao 14° <valor do contador> 8 bytes com o valor já convertido para ascii
para o contador de pesagens zerado diariamente
15° AA Separador, caracter ª em ascii 16° ao 23° <valor do peso em kg> 8 bytes com o valor já convertido para ascii
com o valor do peso registrado em kg 24° AA Separador, caracter ª em ascii 25° 0 Fim da transmissão, caracter de controle
NULL em ascii
33
No PC de interface foi necessário o desenvolvimento de um software para coletar os dados
recebidos via rede serial e formata-los para o envio ao sistema MES SCI. Esse projeto foi
encaminhado ao departamento de TI, que possui equipe dedicada ao desenvolvimento de software.
Os seguintes requisitos do software foram listados para implementação:
• Alta disponibilidade: o software precisa operar 24 horas, sete dias por semana e, em
caso de falhas, notificar a equipe de TI para resolução imediata do problema.
• Tolerância a falhas: no caso de problemas, o software deve ser capaz de continuar
lendo as informações da rede serial e armazená-las para posterior processamento.
• Leitura dos dados em porta serial utilizando um conversor RS-485/USB
disponibilizado pela equipe de automação.
• Registro dos dados em uma tabela apropriada no banco de dados Oracle 11G
instalado no PC de interface.
O software foi implementado na linguagem Python e atendeu as necessidade do sistema
proposto pela equipe de automação. Ele tem por funcionalidade ler cada mensagem enviada pelos
dois CLPs S7-200, para cada carregamento de produto em um dos quatro silos, e escrever essa
informação em uma tabela do banco de dados instalado localmente no PC. A mensagem possui 25
bytes conforme o protocolo definido e chega via porta serial, por exemplo, com o seguinte formato
já em ascii:
ªM03ªª00000008ª00027360ªnull
O programa extrai as seguintes informações da mensagem: M - para finalização manual do
processo pelo operador, 03 – para carregamento no realizado no silo C, 00000008 – é o sequencial
do silo informando ser o oitavo carregamento para o silo C, 00027360 – peso carregado de
27,360kg, os caracteres ª servem de separador para a o software e a mensagem finaliza com um
caractere de controle null. Finalmente o software escreve essas informações na tabela do banco de
dados local, acrescentando data, hora e tipo do carregamento (a granel, caminhões container).
34
3.4 Projeto de interfaces SCI e integração com o ERP Protheus
Para que a informação coletada dos CLPs referentes a cada carregamento chegue ao
módulo de faturamento do ERP Protheus, foi necessário criar um subsistema intermediário para
formatar os dados e enviá-los através do MES - SCI. Essa tarefa ficou a cargo do PC de interface
com o software desenvolvido pela equipe de TI. Toda integração entre sistemas de chão de fábrica e
o software de gestão corporativa é implementada pelo SCI através de agentes ODI. Os agentes são
responsáveis por coletar informações dos bancos de origem, carregá-los na área temporária do SCI,
e após o processamento, serem consolidados e armazenamento como registros definitivos.
No caso específico do sistema de carregamento dos silos finais de produção, a integração
com o ERP Protheus seguiu os seguintes passos após os dados estarem disponíveis no PC de
interface:
I. Foi definida a tabela (tabela 4) responsável pela troca de informações entre os
sistemas. No PC de interface foi instalado o banco de dados Oracle 11G, e a
tabela definida foi criada nesse banco sendo preenchida pelo software com as
informações enviadas pelo CLP de integração.
Tabela 4 Tabela de registros de pesagem.
Campo Tipo Descrição
T0904_ID_IU NUMBER (10) Identificador da tabela, uso interno no SCI
T0904_LOADING_TYPE CHAR (1) Tipo de carregamento: G - para carga granel, B – para carregamento ensacado em Big Bag
T0904_TNET_WI NUMBER (5) Peso final carregado em kg
T0904_DAY_WEIGHING NUMBER (3) Dia do ano, quando foi realizada a pesagem
T0904_YEAR_WEIGHING NUMBER (2) Ano corrente
T0904_LOADING_LOCATION VARCHAR2 (2) Silo onde o foi realizado o carregamento (01, 02, 03 ou 04)
T0904_TSEQUENTIAL_LOADING VARCHAR2 (4) Numero sequencial que representa a quantidade de carregamentos no dia para o silo
especificado
T0904_PROD_HOUR VARCHAR2 (5) Hora do carregamento
35
II. Utilizando a ferramenta ODI Studio, foi criado um agente de execução autônomo
no banco de dados do PC de interface, que envia a tabela atualizada ao ACI (área
de armazenamento temporário do SCI) após o commit da transação de cada novo
registro.
III. Dentro do SCI foi desenvolvido um procedimento de consolidação da tabela de
registro de peso, transformando os dados a partir da área do ACI no padrão
necessário para armazenamento no repositório.
IV. Foi criada uma área de armazenamento temporário no banco de dados do ERP
Protheus para receber a tabela com os registros de pesagem. Outro agente de
execução foi desenvolvido no ODI Studio para enviar a tabela consolidada no
repositório do SCI para a área de armazenamento temporário do Protheus.
V. A equipe da Totvs juntamente com a equipe de desenvolvimento de software da
TI, realizaram as modificações necessárias no módulo de faturamento para inserir
as informações de pesagem de forma automatizada. Eliminando, dessa forma, a
necessidade prévia do faturista ter que digitar esses dados no sistema a partir do
booking.
Após essa sequência de atividade de desenvolvimento e implantação, e um longo período de
depuração e testes, o sistema de envio de dados de pesagem automatizado ficou pronto para ser
utilizado pelo departamento de logística.
3.5 Considerações finais
Nesse capítulo foi apresentada a solução final para automação do registro de pesagem de
caminhões dos silos finais de produção. Foi detalhada a arquitetura inicial do sistema de
carregamento com todos os módulos presentes e o reflexo no fluxo final da operação logística das
modificações implementadas.
As modificações no CLP de integração foram descritas em detalhes, bem como, o projeto do
protocolo de envio de dados via rede serial RS-485. Também foi citado o desenvolvimento do
software do PC de integração feito pela equipe da TI.
Finalmente foram listados os passos realizados para permitir a troca de informações entre o
PC de interface, o sistema MES SCI, chegando até o módulo de faturamento do ERP Protheus.
36
Capítulo 4
Conclusões
Nesse capítulo serão discutidos os resultados do projeto, destacando o processo de testes,
problemas e dificuldade no processo de desenvolvimento e implantação, bem como a atualização da
documentação do sistema com a melhorias implementadas. Serão apresentados o objetivos
alcançados, tudo que não foi possível realizar, sugestões e planos de melhorias futuras e,
principalmente, o impacto da solução no dia a dia da operação logística, destacando as
contribuições aos respectivos procedimentos operacionais.
4.1 Testes e Dificuldades no processo de desenvolvimento
Desde o início do projeto foram introduzidas rotinas de teste para cada iteração do processo
de desenvolvimento. Inicialmente foram implementadas as modificações no software do CLP de
integração e testadas rigorosamente para que não prejudicassem o sistema que, apesar das
limitações, de encontrava operacional. Os testes seguiram o seguinte fluxo:
1. Testes do software do CLP: foram testadas as modificação na configuração do setpoint
de peso, que passou a utilizar uma chave seletora, e o envio de dados para o PC de
37
interface. Os testes do protocolo e da rede RS-485 foram realizados mesmo antes da
implantação do software do PC de interface, utilizando a ferramenta HyperTerminal do
próprio sistema operacional Windows. Entre as dificuldade encontradas nessa etapa, a
maior delas foi a dificuldade para liberação por parte da logística de um dos silos para a
realização dos testes, pois na maior parte do tempo o sistema estava em operação.
2. Testes do software do PC de integração: nesse caso foi testado juntamente com a equipe
de TI o recebimento dos dados de carregamento e a transcrição desses dados na tabela
do banco de dados local. Como dificuldades, tivemos os problemas relativos a
agendamento de trabalho de diferentes equipes (TI e Automação) e inicialmente a
definição do protocolo.
3. Testes de integração dos repositórios de dados: foram testados os agentes ODI, o
primeiro captura a tabela do PC de interface e leva ao SCI e o segundo transfere a
informação consolidada no SCI para a área de armazenamento temporária do ERP
Protheus. Como dificuldades tivemos a aprendizagem do uso da ferramenta ODI Studio
para projeto dos agentes e a disponibilidade da equipe da Totvs para implementar as
modificações no módulo de faturamento do ERP.
4. Testes finais de implantação: o sistema foi testado de forma plena desde o controle de
carregamento, geração e envio da mensagem com o peso associado até a consolidação da
informação no módulo de faturamento do ERP Protheus. Essa etapa foi a que levou mais
tempo para ser concluída devido a dependência de diferentes equipes e das raras
oportunidades de validação reunindo com todos que de alguma forma contribuíram com
o projeto.
A partir da consolidação da solução com os testes finais de implantação, foram feitas
atualizações na documentação do projeto e principalmente nos procedimentos operacionais dos
operadores logísticos e profissionais do setor de faturamento.
4.2 Discussão de Resultados e Possibilidades de Melhoria Futura
O objetivo principal da solução de automação do registro de pesagem foi alcançada, retirando
essa atividade dos procedimentos da operação logística e equipe de faturamento. Ambas as equipes
tiveram suas tarefas otimizadas e o fator de risco de erro humano nessa coleta de informação foi
eliminado. Após o período de três meses de implantação, o feedback dos profissionais da logística
quanto a eficiência do sistema tem sido dentro do esperado. Além disso, com a implantação da
38
chave seletora de peso, e o tempo de experiência dos operadores logísticos no uso do sistema,
acarretou redução na diferença entre o peso desejado e o peso real carregado.
O sistema adquirido pela companhia para realização de carregamento de caminhões container
ainda apresenta falhas inerentes ao projeto, como a falta de um modo de dosagem precisa no
momento em que o peso se aproxima do setpoint configurado. Esse erro tem sido atenuado pela
parada manual do carregamento e experiência dos operadores no decorrer do tempo de uso.
Já foi planejadas algumas ações que podem, no futuro, significar uma melhoria considerável
nos problemas ainda apresentados pelo sistema. Dentre elas destacam-se:
• Troca dos módulos de pesagem Digitron (associados as células de carga da balança
rodoviária) por outra versão que suporte comunicação digital, reduzindo o ruído na
transmissão do valor de peso para o CLP de integração.
• Projeto do sistema de dosagem fina para aumentar a precisão do carregamento e
eliminar a necessidade de interrupção manual.
39
Apêndice A
Este apêndice apresenta a tabela ASCII utilizada no projeto do protocolo de envio de dados
de pesagem do CLP de integração para o PC de interface.
Figura 0.1 Tabela ASCII (0 a 127).
40
Figura 0.2 Tabela ASCII (128 a 255).
41
Apêndice B
Este apêndice apresenta o código DDL (subconjunto da linguagem SQL para definição de
dados) da tabela de registro de pesagem implementada no banco de dados do PC de interface.
CREATE TABLE PLC_ACI.T0904_QTD_PROD_FATR_PTA_GRL ( T0904_ID_IU NUMBER (10) NOT NULL , T0904_LOADING_TYPE CHAR (1) , T0904_TNET_WI NUMBER (5) , T0904_DAY_WEIGHING NUMBER (3) , T0904_YEAR_WEIGHING NUMBER (2) , T0904_LOADING_LOCATION VARCHAR2 (2) , T0904_TSEQUENTIAL_LOADING VARCHAR2 (4) , T0904_PROD_HOUR VARCHAR2 (5) ) TABLESPACE SCIAPLD01 LOGGING ;
COMMENT ON TABLE PLC_ACI.T0904_QTD_PROD_FATR_PTA_GRL IS 'Tabela para armazenar as quantidades dos produtos faturados.' ;
COMMENT ON COLUMN PLC_ACI.T0904_QTD_PROD_FATR_PTA_GRL.T0904_ID_IU IS 'Identificador da tabela T0158_QTD_PROD_FATR_PET_GRL.' ; COMMENT ON COLUMN PLC_ACI.T0904_QTD_PROD_FATR_PTA_GRL.T0904_LOADING_TYPE IS 'Tipo de carregamento' ; COMMENT ON COLUMN PLC_ACI.T0904_QTD_PROD_FATR_PTA_GRL.T0904_TNET_WI IS 'Peso carregado no caminhão container' ; COMMENT ON COLUMN PLC_ACI.T0904_QTD_PROD_FATR_PTA_GRL.T0904_DAY_WEIGHING IS 'Dia do ano do carregamento' ; COMMENT ON COLUMN PLC_ACI.T0904_QTD_PROD_FATR_PTA_GRL.T0904_YEAR_WEIGHING IS 'Ano do carregamento'
42
; COMMENT ON COLUMN PLC_ACI.T0904_QTD_PROD_FATR_PTA_GRL.T0904_LOADING_LOCATION IS 'Identificação do silo onde foi realizado o carregamento' ; COMMENT ON COLUMN PLC_ACI.T0904_QTD_PROD_FATR_PTA_GRL.T0904_TSEQUENTIAL_LOADING IS 'Sequencial do carregamento de caminhões' ; COMMENT ON COLUMN PLC_ACI.T0904_QTD_PROD_FATR_PTA_GRL.T0904_PROD_HOUR IS 'Hora do carregamento' ; ALTER TABLE PLC_ACI.T0904_QTD_PROD_FATR_PTA_GRL ADD CONSTRAINT PK_T0904_QTD_PROD_FATR_PTA_GRL PRIMARY KEY ( T0904_ID_IU ) ; create sequence plc_aci.S004_T0904_ID_IU MINVALUE 1 MAXVALUE 9999999999 INCREMENT BY 1 START WITH 1 CACHE 20 ORDER CYCLE ;
43
Apêndice C
Este apêndice apresenta o código fonte em STL que implementa as funcionalidade do CLP
S7-200 de integração. São apresentados: o bloco principal, o bloco de controle e o bloco de envio
de dados respectivamente.
Bloco MAIN
Network 1 // Condições de inicialização LD SM0.1 MOVW +0, C0 R M10.0, 8 R M11.0, 8 MOVW +0, VW62 MOVW +0, VW64 Network 2 LD SM0.0 CALL SBR1 Network 3 LD SM0.0 CALL SBR2
Network 4 LD SM0.0 CALL SBR0
Network 5 LD SM0.0 CALL SBR4
Network 6 LD SM0.0 AN SM0.0 CALL SBR3 Bloco Silo_1 // Funcionalidade operacional do Silo A, esse bloco é replicado para a mesma funcionalidade nos silos B, C e D
44
Network 1 // Salva o peso da balanca LD SM0.0 MOVW AIW2, VW86 MOVW AIW2, VW84 AENO MOVW VW84, VW50 +I 0, VW50 Network 2 // Retransmite o sinal para o Presys LD SM0.0 LPS MOVW VW86, VW88 AW>= VW86, 17000 MOVW VW88, VW58 +I 0, VW58 LPP AW< VW86, 17000 MOVW VW86, VW58 Network 3 LD SM0.0 MOVW VW58, AQW0 Network 4 // Setpoint em 26000Kg (Colocar o valor de conversão um pouco menor para compensar o produto que fica na linha) LD SM0.0 A I3.1 MOVW 17600, VW54 Network 5 // Setpoint em 27500Kg (Colocar o valor de conversão um pouco menor para compensar o produto que fica na linha) LD SM0.0 A I3.0 MOVW 18200, VW54 Network 6 // Inicia sequencia LD SM0.1 S M20.0, 1 R M20.1, 12 Network 7 // Verifica se a condição inicial esta satisfeita (Caminhão aterrado e em Stop)
LD M20.0 A I0.3 AN I0.2 R M20.0, 1 S M20.1, 1 S M20.2, 1
Network 8 // Habilita abrir válvulas LD M20.1
45
A I0.3 = Q2.0 Network 9 // Abrir Válvulas LD M20.2 A I0.3 A I0.2 S M20.3, 1 R M20.2, 1 S M20.5, 1 Network 10 // Abre Válvulas LD M20.3 A I0.2 = Q2.1 Network 11 // Condição para ter um mínimo de produto no caminhão antes de enviar os dados LD M20.4 AW> VW50, 16500 AW< VW50, VW54 R M20.4, 1 S M20.5, 1 Network 12 // Parada manual de carregamento (Peso atingindo) LD M20.5 AN I0.2 R M20.5, 1 S M20.6, 1 Network 13 // Se o Temporizador T39 acabar o programa considera que o peso foi realmente atingindo sem problemas LD M20.6 A T39 R M20.6, 1 S M21.0, 1 R M20.3, 1 R M20.1, 1 Network 14 // Se o operador der start antes do tempo de peso atingido o carregamento continua LD M20.6 A I0.3 A I0.2 R M20.6, 1 S M20.5, 1 Network 15 // Parada automática de carregamento (Peso atingindo) LD M20.5 AW>= VW50, VW54 R M20.5, 1 S M20.7, 1 R M20.3, 1 R M20.1, 1 Network 16 // Tempo de Estabilização para enviar mensagem LD M20.7 A T40
46
S M21.1, 1 R M20.7, 1 Network 17 // Incremento o contador LD M21.0 O M21.1 EU +I +1, VW62 Network 18 // O contador vai de 1 ate 99. depois retorna a 1 LDW>= VW90, +100 MOVW +0, VW62 Network 19 // Apos a estabilização, envia a mensagem para o ERP LD M21.0 O M21.1 EU S M10.4, 1 MOVW VW50, VW66 Network 20 LD M21.0 O M21.1 A T44 AN I0.3 AN I0.2 R M21.0, 1 R M21.1, 1 S M20.0, 1 Network 21 LD M20.6 TON T39, 1200 Network 22 LD M20.7 TON T40, 1200 Network 23 LD M21.0 O M21.1 TON T44, 20 Bloco Com_Silo_1 //Código do envio de dados via rede serial ao PC de interface para o Silo A, esse bloco é replicado para os silos B, C e D
Network 1
47
LD SM0.0 MOVB 16#49, SMB30 //set 9600 bauds,8,e,1 MOVW +10, SMW90 MOVB 23, SMB94 MOVB 16#0A, SMB89 Network 2 // Inicia a comunicação com 16#AA LD M10.4 MOVB 16#AA, VB200 Network 3 // Escreve M (Código ASCII 16#4D) Parada manual LD M10.4 A M21.0 MOVB 16#4D, VB201 Network 4 // Escreve C (Código ASCII 16#53) Parada automática LD M10.4 A M21.1 MOVB 16#43, VB201 Network 5 // Primeiro digito do numero do silo - 0 (Código ASCII 30) LD M10.4 MOVB 16#30, VB202 Network 6 // Segundo digito do numero do silo - 3 (Código ASCII 16#33) LD M10.4 MOVB 16#33, VB203 Network 7 // Escreve 16#AA LD M10.4 MOVB 16#AA, VB204 Network 8 // Escreve 16#AA LD M10.4 MOVB 16#AA, VB205 Network 9 // Converte o incremental para ASCII LD SM0.0 ITA VW62, VB206, 16#0 Network 10 // Envia 16#AA LD M10.4 MOVB 16#AA, VB214 Network 11 // Subtrai 6400 (Zero) e depois multiplica por 2.34375 do registro do peso para converter em Kg. O registro da corrente vai de 0 - 32000 e o range de peso vai de 0 a 60 000 Kg com as diferenças de conversão analógica, a multiplicação foi substituída por 2.313. Valor verificado por amostragem de pesagem no campo. LD SM0.0 ITD VW66, VD70 AENO
48
DTR VD70, VD70 AENO -R 6400.0, VD70 AENO *R 2.34375, VD70 Network 12 // Converte o Peso para ASCII LD M10.4 RTA VD70, VB215, 16#82 Network 13 // Escreve 16#AA LD M10.4 MOVB 16#AA, VB223 Network 14 LD SM0.0 MOVB 16#FF, VB198 Network 15 LD SM0.0 MOVB 16#0, VB224 Network 16 LD M10.4 O M11.5 EU XMT VB198, 0 Network 17 LD M10.4 R M10.4, 1 S M11.4, 1 R M11.5, 1 Network 18 // Inicio do timer de 5 segundos para o reenvio da comunicação LD M11.4 TON T107, +50 Network 19 LD T107 R M11.4, 1 S M11.5, 1
49
Referências Bibliográficas
[1] Alain Digeon, revista ISO Focus, Volume 4, No. 12, dezembro 2007, ISSN 1729-8709,
disponível em http://www.iso.org/iso/livelinkgetfile-isocs?nodeId=15008463, acessado em
06/02/2016.
[2] What is Industrial Automation?, Sure Controls, Inc., Greenville, Wisconsin EUA, disponível em
http://www.surecontrols.com/what-is-industrial-automation/, acessado em 06/02/2016.
[3] Richard J. Sheehan, "Terephthalic Acid, Dimethyl Terephthalate, and Isophthalic Acid" in
Ullmann's Encyclopedia of Industrial Chemistry, Wiley-VCH, Weinheim, 2002.
[4] Apresentação das soluções Totvs Protheus para a industrial Metal Mecânica & Plasticos,
disponível em, http://pt.slideshare.net/TOTVS/metal-mecanico-e-plasticos, acessado em
15/02/2016.
[5] BERGER, Hans. Automating with SIMATIC, John Wiley & Sons, Quarta edição, 2009.
[6] Rede RS-485, notas de aula REDES de SENSORES e ATUADORES, Prof. José Sérgio da
Rocha Neto, Curso de Especialização em Automação.
[7] Vinhais, Joseph A. (Setembro 1998). "Manufacturing Execution Systems: The One-Stop
Information Source". Quality Digest. QCI International. Disponível em:
http://www.qualitydigest.com/sept98/html/mes.html, acessado em 15/03/2016.
[8] Loney, Kevin (Dezembro 2008). "Oracle Database 11g The Complete Reference". Primeira
Edição. McGraw-Hill: 1368. ISBN 0-07-159875-8.
[9] Mendes, Carina. (Fevereiro 2014). “ODI – Conceito do Data Integrator”. Disponível em:
http://carinamendes.com/odi-studio-visao-geral/, acessado em 15/03/2016.
[10] Oracle. (Março 2015). “Oracle GoldenGate 12c: Real-Time Access to Real-Time
Information”. Disponível em: http://www.oracle.com/us/products/middleware/data-
integration/oracle-goldengate-realtime-access-2031152.pdf, acessado em 15/032016.
50
[11] Medeiros, Isaac. TOTVS é única latino-america com tecnologia própria. Artigo disponível em: http://isaacmedeiros.blogspot.com.br/2011/07/totvs-e-unica-latino-america-com.html, acessado em 15/03/2016.
