Instalação e Administração do Sistema PI na Unidade

UNIVERSIDADE FEDERAL DE SANTA CATARINA
CURSO DE ENGENHARIA DE CONTROLE E AUTOMAÇÃO INDUSTRIAL
Instalação e Administração do Sistema PI na
Unidade Multipropósito de FCC
Monografia submetida à Universidade Federal de Santa Catarina como requisito
para a aprovação da disciplina:
DAS 5511 Projeto de Fim de Curso
Alex Scheuer
Florianópolis, Agosto de 2004
Instalação e Administração do Sistema PI na Unidade
Multipropóstito de FCC
Alex Scheuer
Esta monografia foi julgada no contexto da disciplina
DAS 5511: Projeto de Fim de Curso
e aprovada na sua forma final pelo
Curso de Engenharia de Controle e Automação Industrial
Banca Examinadora:
Alberto Jamhour, Eng.
Orientador Empresa
Daniel Juan Pagano, Dr.
Orientador do Curso
Prof. Augusto Humberto Bruciapaglia
Responsável pela disciplina
Prof. Carlos Barros Montez, Avaliador
Yoso Nakamura Junior, Debatedor
Tiago Villaça Vianna Ferreira, Debatedor
Agradecimentos
Aos colegas Casavechia, Franci, Luciana, Patrícia e Villela por criarem um
ambiente de trabalho saudável e motivador.
Em especial, a Alberto Jamhour pela oportunidade e sabedoria na condução
dos trabalhos, sempre propondo desafios e estimulando-me a buscar as melhores
soluções.
À Samia Kamal Genena, que “abriu as portas” da SIX para os estudantes de
Engenharia de Controle e Automação Industrial da UFSC, possibilitando a
viabilização deste estágio e futuramente de muitos outros.
À Universidade Federal de Santa Catarina e aos professores do
Departamento de Automação e Sistemas, em especial ao professor e orientador
Daniel Juan Pagano por sua dedicação e orientação neste trabalho e em outros.
Ao apoio financeiro da Agência Nacional do Petróleo (ANP) por meio do
Programa de Recursos Humanos para o Setor de Petróleo e Gás – PRH-ANP/MCT
Nº34.
Por fim, agradeço a todos que contribuíram direta ou indiretamente para
concretização deste trabalho.
i
Resumo
Esta monografia documenta o Projeto de Fim de Curso realizado durante o
período de estágio na PETROBRAS/UN-SIX. O foco do trabalho foi a instalação,
configuração e administração do sistema PI para Unidade de Craqueamento
Catalítico Fluido (U-144).
O sistema PI (Plant Information) corresponde a um conjunto de módulos de
software servidor/cliente responsável pela coleta, armazenamento e exibição de
dados de um processo.
Na U-144, este sistema não era utilizado como ferramenta confiável para o
armazenamento de dados devido a dois fatores principais: primeiro, a interface
utilizada na coleta de dados apresentava problemas, não operando continuamente;
segundo, a U-144 utilizava o mesmo servidor PI do Módulo Indsutrial de
Processamento de Xisto (U-230), não se tendo acesso direto ao sistema para que
fossem realizadas configurações customizadas segundo às necessidades da U-144.
Assim, durante o período de estágio foi realizada a instalação do PI em um
novo servidor, além de realização de configurações específicas e resolução dos
problemas da interface de coleta de dados, que passou a funcionar continuamente.
Foram realizadas ainda atividades sobre o sistema ABB Process Portal,
responsável pela interface com o Sistema Digital de Controle Distribuído (SDCD)
que controla a U-144. Este sistema era utilizado como ferramenta usual de
armazenamento de dados históricos, porém, devido à instalação e configurações
inadequadas, não atendia às necessidades da U-144, levando a busca de meios
alternativos de obtenção de dados confiáveis, neste caso, o sistema PI.
ii
Abstract
This monograph documents the End Course Project accomplished during the
training period at PETROBRAS/UN-SIX. The work focus was the installation,
configuration and administration of the Plant Information System (PI System) for
Fluid Catalytic Cracking Unit (U-144).
The PI System corresponds to a software server/client modules set
responsible by the data collection, storage and exhibition of a process.
In the U-144, this system was not used as reliable tool for data storage due to
two main factors: first, the interface used in the data collection had problems, not
operating continually; second, the U-144 used the same PI server of the Shale
Processing Industrial Module (U-230), not having itself direct access to the system
so that could be accomplished cost configurations according to the U-144 needs.
This way, during the training period was accomplished the PI installation in a
new server, besides accomplishment of specific configurations and problems
resolution of the data collection interface, which proceeded working continually.
It was still accomplished some activities on the ABB Process "Portal",
responsible for the interface with the Digital Control System (DCS) which controls the
U-144. This system was used as frequent tool of historical data storage, however,
due to the installation and inadequate configurations, it did not attend to the U-144
needs, taking this way to search alternative forms to obtain reliable data and, in this
case, the PI System.
iii
Sumário
Agradecimentos................................................................................................. i
Resumo ............................................................................................................ ii
Abstract ........................................................................................................... iii
Sumário ........................................................................................................... iv
Capítulo 1: Introdução ......................................................................................1
Capítulo 2: PETROBRAS – Petróleo Brasileiro S.A. ........................................3
2.1: Áreas de atuação...................................................................................4
2.1.1: Abastecimento.................................................................................5
2.1.2: Exploração e Produção ...................................................................5
2.1.3: Gás e Energia .................................................................................5
2.1.4: Internacional....................................................................................6
2.2: PETROBRAS em números....................................................................6
2.3: Unidade de Industrialização do Xisto.....................................................7
2.4: O Processo PETROSIX .........................................................................8
2.4.1: Processamento de pneus................................................................8
2.5: Gerência de Pesquisa (GEPES) ............................................................9
2.5.1: Unidade Multipropósito de FCC (U-144) .......................................10
2.5.2: Unidade de Nebulizadores de FCC...............................................11
2.5.3: Unidade a Frio de Ciclones ...........................................................11
2.5.4: Unidade de Recirculação de Catalisador ......................................11
2.5.5: Unidade de Destilação ..................................................................11
2.5.6: Unidade de Hidroconversão de Resíduos (U-104)........................12
2.5.7: Unidade de Desasfaltação (U-2325) .............................................12
iv
2.5.8: Unidade de Pneus.........................................................................12
2.5.9: Unidade de Tratamento e Misturas ...............................................13
2.5.10: Laboratório ..................................................................................13
2.5.11: Laboratório de Medição de Partículas a Laser............................13
2.5.12: Laboratório de Combustão..........................................................14
2.5.13:
Unidade
de
Tratamento
Ácido
de Gasóleo/Bancada de
Tratamento de Emulsões ...................................................................................14
2.6: Craqueamento Catalítico Fluido...........................................................14
2.7: Unidade Multipropósito de FCC (U-144)..............................................15
2.7.1: Descrição geral da U-144..............................................................16
Capítulo 3: O Sistema PI ................................................................................18
3.1: PI UDS .................................................................................................18
3.2: PI Network Manager ............................................................................20
3.3: PI-API...................................................................................................20
3.4: Aplicativos clientes...............................................................................21
3.4.1: PI-ProcessBook.............................................................................22
3.4.2: PI-DataLink....................................................................................22
3.4.3: PI-ActiveView ................................................................................23
3.5: Fluxo de dados ....................................................................................23
3.5.1: Configuração dos pontos ..............................................................24
3.5.2: Snapshot .......................................................................................25
3.5.3: Teste de Exceção..........................................................................26
3.5.4: Compressão de dados ..................................................................27
3.6: Tags .....................................................................................................29
3.7: Interfaces para outros sistemas...........................................................30
3.7.1: Interface semAPI...........................................................................32
v
3.7.2: Seqüência de Ações da Interface .................................................34
Capítulo 4: Sistema de Controle Distribuído (SDCD) .....................................36
4.1: SDCD Bailey INFI 90 ...........................................................................37
4.1.1: ABB Process Portal.......................................................................39
Capítulo 5: Tarefas Desenvolvidas.................................................................41
5.1: Instalação e configuração do servidor PI .............................................41
5.1.1: Instalação do servidor PI em uma nova máquina .........................41
5.1.2: Configurações pós-instalação .......................................................43
5.1.3: Criação de um sistema de backup ................................................44
5.1.4: Atualização e configuração de tags...............................................46
5.1.5: Construção e atualização de telas de processo............................48
5.2: Resolução de problemas de hardware no computador interface.........49
5.3: Reinstalação do sistema Process Portal..............................................50
5.3.1: Configuração de tags no PI para realização de testes..................57
Capítulo 6: Conclusões e Perspectivas ..........................................................62
Bibliografia:.....................................................................................................64
Anexo A: Arquitetura SDCD Bailey INFI 90.............................................65
vi
Índice de Figuras
Figura 1: Vista aérea da SIX .......................................................................................7
Figura 2: Processo PETROSIX com pneus ................................................................9
Figura 3: Unidade multipropósito de FCC .................................................................17
Figura 4: PI UDS com seus subsistemas, clientes e nós de coleta de dados...........19
Figura 5: Máquina Cliente com PI-API ......................................................................21
Figura 6: Nós de rede com aplicativos cliente...........................................................22
Figura 7: Fluxo de dados...........................................................................................23
Figura 8: Fluxo de dados nos testes de exceção e compressão ..............................24
Figura 9: Exemplo do processo de filtragem dos dados ...........................................24
Figura 10: Arquitetura do sistema PI na U-144 .........................................................25
Figura 11: Funcionamento do Exception Report.......................................................27
Figura 12: Método de compressão............................................................................28
Figura 13: Interface como intermediadora na coleta de dados .................................31
Figura 14: Sistema PI com arquitetura distribuída para coleta de dados..................32
Figura 15: Interface entre o SDCD (DCS) INFI 90 e o servidor PI utilizando Bailey
semAPI ..............................................................................................................32
Figura 16: Conexão entre computador interface e o SDCD através do cartão INICI03
...........................................................................................................................33
Figura 17: Conexão entre o computador interface e o SDCD ABB/Bailey INFI 90 ...34
Figura 18: Uma das telas de processo da U-144 no Process Portal.........................40
Figura 19: Planilha utilizada para inserção e atualização de tags.............................47
Figura 20: Exemplo de tela de processo do PI-ProcessBook ...................................49
Figura 21 – Janela de configuração dos parâmetros de compressão.......................52
Figura 22 – Arquitetura original do Process Portal....................................................53
vii
Figura 23 – Nova arquitetura do sistema Process Portal ..........................................54
Figura 24: Leitura do painel no momento de início do teste .....................................55
Figura 25: Leitura do painel após uma hora de teste................................................56
Figura 26: Valores obtidos do Historian Server.........................................................56
Figura 27: Evolução de um mesma tag com seus parâmetros de compressão e
exceção originais e desabilitados.......................................................................58
Figura 28: Planilha para recuperação de dados de testes ........................................60
viii
Capítulo 1: Introdução
Esta monografia documenta o Projeto de Fim de Curso realizado durante o
período de estágio na PETROBRAS/UN-SIX. O tema principal deste trabalho foi a
instalação, configuração e administração do sistema PI (Plant Information) para a
unidade multipropósito de FCC (U-144). Houve ainda a realização de trabalhos
relacionados ao Sistema Digital de Controle Distribuído (SDCD) desta mesma
unidade, cujo funcionamento irregular prejudicava o andamento e execução de
tarefas.
O sistema PI constitui-se num conjunto de módulos de software responsável
pela coleta, armazenamento e exibição de dados de processos. Através deste, temse disponível no escritório, ou em qualquer outro lugar da planta, informações em
tempo real sobre a evolução das variáveis de um processo. Operadores,
engenheiros, gerentes e demais interessados podem utilizar as aplicações clientes
para visualizar os dados armazenados no servidor PI.
Assim, sendo o sistema PI uma ferramenta desenvolvida para automatizar
totalmente a coleta, armazenamento e apresentação de informações de um
processo, este Projeto de Fim de Curso está completamente inserido no contexto do
curso de Engenharia de Controle e Automação Industrial.
O principais objetivos durante a realização deste trabalho foram instalar o
servidor PI em uma nova máquina, adquirida especialmente para este fim, executar
configurações adequando-o à necessidade da U-144 e por fim, torná-lo robusto de
modo que pudesse ser utilizado como fonte confiável de dados.
Por ser uma unidade de pesquisa, a U-144 tem seu funcionamento baseado
na realização de testes e análise dos dados gerados. Porém, a não confiança nos
dados armazenados no servidor de dados históricos do SDCD levou a busca por
novos meios de obtenção de dados confiáveis, seja através de configurações sobre
o próprio SDCD, seja através de adequação do sistema PI para este fim.
No decorrer do texto, será possível acompanhar as etapas realizadas no
desenvolvimento deste trabalho. Primeiramente, no segundo capítulo, tem-se uma
1
breve apresentação da PETROBRAS, contemplando relatos sobre sua história,
áreas de atuação e principais números. Neste mesmo capítulo é também
apresentada a UN-SIX, a gerência de pesquisa e a unidade multipropósito de FCC.
No terceiro capítulo é descrito o sistema PI, sua arquitetura e modo de
funcionamento, além de apresentados os diversos módulos que o integram.
Descreve-se ainda a interface utilizada na coleta de dados do SDCD.
No quarto capítulo é apresentado o SDCD ABB/Bailey INFI 90, utilizado no
controle da U-144, além de sua interface de operação (ABB OperateIT Process
Portal).
No quinto capítulo são resumidas as principais atividades executadas durante
o período de estágio, descrevendo-se os passos na instalação do sistema PI, as
configurações realizadas, os trabalhos executados sobre o SDCD, além de
descrição dos problemas encontrados e as soluções propostas.
Por fim, no sexto e último capítulo são discutidos os resultados obtidos,
conclusões e as perspectivas de desenvolvimentos futuros.
2
Capítulo 2: PETROBRAS – Petróleo Brasileiro S.A.
Em outubro de 1953, através da Lei 2.004, a PETROBRAS era criada para
executar as atividades do setor de petróleo no Brasil em nome da União. A Petróleo
Brasileiro S.A. iniciou suas atividades com o acervo recebido do antigo Conselho
Nacional do Petróleo (CNP):
•
Campos de petróleo com capacidade para produzir 2.700 barris por dia
(bpd);
•
Bens da Comissão de Industrialização do Xisto Betuminoso;
•
Refinaria de Mataripe (BA), processando 5.000 bpd;
•
Refinaria em fase de montagem, em Cubatão (SP);
•
Vinte petroleiros com capacidade para transportar 221.295 toneladas;
•
Reservas recuperáveis de 15 milhões de barris;
•
Consumo de derivados de 137.000 bpd;
•
Fábrica de fertilizantes em construção (Cubatão - SP).
Ao longo de quatro décadas, a PETROBRAS tornou-se líder em distribuição
de derivados no país, colocando-se entre as vinte maiores empresas petrolíferas na
avaliação internacional.
Em 1997, o Brasil ingressou no seleto grupo dos dezesseis países que
produzem mais de 1 milhão de barris de óleo por dia. E nesse mesmo ano, foi
criada a Lei n º 9.478, que abre as atividades da indústria petrolífera à iniciativa
privada.
Com a lei, foram criados a Agência Nacional do Petróleo (ANP), encarregada
de regular, contratar e fiscalizar as atividades do setor, e o Conselho Nacional de
Política Energética, um órgão formulador da política pública de energia.
Em sintonia com a mudança do cenário, a PETROBRAS seguiu preparada
para a livre competição, ampliando novas perspectivas de negócios e tendo maior
autonomia empresarial.
3
Atualmente, a PETROBRAS conta com noventa e três plataformas de
produção, mais de dez refinarias, quase dezesseis mil quilômetros em dutos e mais
de sete mil postos de combustíveis, marcando sua forte presença no Brasil.
A PETROBRAS foi a pioneira na indústria do petróleo no Brasil, e por isso
enfrentou dificuldades pela falta de infra-estrutura e de tecnologias adequadas. Nos
anos 50 e 60, com o início das atividades no setor de petróleo no país, a empresa
precisou construir suas primeiras refinarias. A indústria nacional era, até então,
acanhada, e a PETROBRAS contribuiu, assim, para estimular seu crescimento.
Naquela época, com a necessidade de dotar o Brasil de uma infra-estrutura
adequada, o governo brasileiro optou pela substituição de importações e pelo
incentivo à instalação de empresas estrangeiras no Brasil.
No início da década de 80 este modelo foi substituído na PETROBRAS pelo
Sistema de Nacionalização. Além da substituição da importação de itens prioritários,
este sistema passou a buscar fornecedores alternativos e uma maior autonomia de
decisão da empresa nos aspectos tecnológicos e industriais.
A
demanda
por
materiais
altamente
sofisticados
era
crescente,
principalmente pela necessidade de viabilizar a extração do óleo e do gás em águas
cada vez mais profundas, situação em que, muitas vezes, não havia no mundo
tecnologias disponíveis para esse propósito.
No final da mesma década, com a legislação que previa a modernização e o
aumento da competitividade do parque industrial no Brasil, foram criados
mecanismos de estímulo ao desenvolvimento tecnológico. O mercado interno a esta
altura já atendia a 94% das necessidades da PETROBRAS.
2.1: Áreas de atuação
A PETROBRAS atua em várias áreas do setor de energia. Desde a
exploração de gás e petróleo até a distribuição, passando pelo refino e
abastecimento. As atividades da companhia estão divididas em: Exploração e
Produção, Gás e Energia, Abastecimento, e Internacional.
4
2.1.1: Abastecimento
A PETROBRAS abastece quase toda a demanda do mercado brasileiro por
derivados de petróleo – cerca de 1,7 milhões de barris/dia – mercado esse
composto por 140 milhões de consumidores.
Além do objetivo de aumentar sua capacidade de produção, de modo a
atender a crescente demanda por derivados, a PETROBRAS precisa enfrentar outro
desafio: adaptar suas refinarias de modo a aumentar a taxa de conversão de
diferentes tipos de óleo, dentro da já existente estrutura de processamento,
eliminando, assim, a dependência da importação.
De acordo com a Petroleum Intelligence Weekly, a PETROBRAS é a nona
maior companhia no setor downstream (refino), transporte e comercialização. O
termo downstream, na PETROBRAS, está ligado à boa parte da estrutura
operacional da companhia: suas refinarias, fábricas de fertilizantes, bases, dutos,
terminais e navios.
2.1.2: Exploração e Produção
O órgão de Exploração e Produção (E&P) da PETROBRAS é responsável
pela pesquisa, localização, identificação, desenvolvimento, produção e incorporação
de reservas de óleo e gás natural dentro do território nacional.
Impulsionado pelo fato de grande parte das reservas brasileiras se
encontrarem em bacias marítimas a grandes profundidades, o E&P, em parceria
com outras áreas da Companhia, tem alçado a PETROBRAS à excelência mundial
em desenvolvimento e aplicação de tecnologia de exploração e produção em águas
profundas. Esse esforço foi reconhecido internacionalmente através do recebimento,
pela segunda vez, no ano 2001, do prêmio mais importante da indústria mundial de
petróleo, o Distinguished Achievement Award, oferecido na Offshore Technology
Conference (OTC).
2.1.3: Gás e Energia
A área de negócios de Gás & Energia é responsável pela comercialização do
gás natural nacional e importado e pela implantação de projetos, em parceria com o
5
setor privado, que irão garantir a oferta deste combustível em todo o país. Elevar a
participação do gás natural na matriz energética do país dos atuais 3% para 10%
até 2005 é um dos principais objetivos da companhia. Para isso, a PETROBRAS
dedica esforço permanente junto às distribuidoras de gás e seus clientes, buscando
alternativas técnicas e econômicas que ampliem o uso do gás nos segmentos
industriais, automotivos, na geração e co-geração de energia.
2.1.4: Internacional
A PETROBRAS desenvolve diversas atividades no exterior e mantém uma
consistente atividade internacional, tal como: compra e venda de petróleo,
tecnologias,
equipamentos,
materiais
e
serviços;
acompanhamento
do
desenvolvimento da economia americana e européia; operação financeira com
bancos e bolsa de valores; recrutamento de pessoal especializado; afretamento de
navios; apoio em eventos internacionais, entre outros.
Além disso, a Companhia está associada às maiores empresas de petróleo
do mundo, fazendo-se presente em Angola, Argentina, Bolívia, Colômbia,
Casaquistão, Estados Unidos, Guiné Equatorial, Nigéria e Trinidad & Tobago.
2.2: PETROBRAS em números
Abaixo são apresentados dados na áreas de exploração, produção,
abastecimento, entre outras. Dados referentes ao ano de 2003:
Receitas Líquidas (em bilhões de R$): R$ 95,743
Lucro Líquido (em bilhões de R$): R$ 17,795
Investimentos (em bilhões de R$): R$ 18,485
Acionistas: 131.577
Exploração: 35 sondas de perfuração (22 marítimas)
Reservas (Critério SEC): 11,6 bilhões de barris de óleo e gás equivalente (boe)
Poços Produtores: 15.834 (838 marítimos)
Plataformas de Produção: 98 (68 fixas; 30 flutuantes)
Produção Diária: 1,701 milhão bpd de óleo e LGN, 53 milhões de m3 de gás natural
Refinarias: 16
Rendimento das Refinarias: 1,709 milhão barris por dia - bpd
6
Dutos: 27.120 km
Frota de Navios: 97 (54 de propriedade da PETROBRAS)
Postos: 5.074 Ativos (612 próprios)
Fertilizantes: 5 Fábricas, 2.141 toneladas métricas de amônia e 2.437 toneladas
métricas de uréia
2.3: Unidade de Industrialização do Xisto
A Superintendência da Industrialização do Xisto (SIX) foi constituída em 1º de
junho de 1954, com a missão de estudar as potencialidades do xisto betuminoso e a
viabilidade econômica de sua transformação industrial.
Ela incorporou o acervo da extinta Comissão de Industrialização do Xisto
Betuminoso (CIXB), órgão do Governo Federal que tinha sido repassado à
PETROBRAS no momento de sua criação em 3 de outubro de 1953.
A sede está localizada no município de São Mateus do Sul, no Paraná, a 140
quilômetros de Curitiba, onde também se encontram a área de mineração e a
unidade industrial. A Figura 1 apresenta uma vista aérea do complexo industrial de
São Mateus do Sul.
Figura 1: Vista aérea da SIX
7
Em função da capacidade tecnológica desenvolvida no aproveitamento do
xisto, a PETROBRAS optou por transformar a Unidade de Industrialização do Xisto
também num centro avançado de pesquisa na área de refino. O Parque Tecnológico
da SIX é um conjunto de onze plantas protótipo, destinadas a desenvolver
tecnologias na área de refino, podendo executar trabalhos de pesquisa e
desenvolvimento na área de energia de modo geral.
Atualmente, em estrita colaboração com o Centro de Pesquisas da Petrobras
(CENPES), estas plantas participam em dezesseis projetos prioritários dos
Programas de Tecnologia e Meio Ambiente da PETROBRAS, com ênfase no
processamento de petróleo nacional, principalmente Marlim. Poucas empresas de
petróleo possuem um conjunto de plantas protótipo similar a este, que é o maior
parque desta natureza na América Latina e um dos maiores do mundo.
O
Parque
Tecnológico
tem
por
objetivo
desenvolver
os
principais
equipamentos das plantas industriais, testando-os em escala protótipo, reduzindo
assim a margem de incerteza na sua implementação, proporcionando maior
segurança no scale-up. E ainda, desenvolver tecnologias, novas e existentes, nas
áreas de refino, petróleo, energia e tratamento de efluentes da produção industrial.
2.4: O Processo PETROSIX
A principal característica da tecnologia desenvolvida pela PETROBRAS é a
simplicidade operacional. Depois de minerado a céu aberto, o xisto vai para um
britador, que reduz as pedras a tamanhos que variam de 6 a 70 milímetros. Então,
estas pedras são levadas a uma retorta, onde são pirolisadas (cozidas) a uma
temperatura de aproximadamente 500 ºC, liberando-se a matéria orgânica nelas
contida sob a forma de óleo e gás.
2.4.1: Processamento de pneus
A SIX recebe pneus da região do Paraná, Santa Catarina, São Paulo e Rio de
Janeiro e está processando 48 toneladas do material por dia, utilizando apenas 12%
da sua capacidade de processamento que é de 400 toneladas por dia. Essa baixa
capacidade se deve ao fato da legislação, que torna obrigatória a reciclagem de
pneus velhos, ser muito recente. Atualmente a capacidade de processamento da
8
SIX é de 140 mil toneladas por ano, que corresponde a 27 milhões de pneus de
automóveis.
Um dos grandes benefícios que a reciclagem traz para a comunidade está
relacionado à coleta dos pneus armazenados inadequadamente. Com o acúmulo de
água, esses pneus tornam-se ambientes favoráveis à proliferação de insetos que
transmitem doenças infecciosas, como a dengue, febre amarela, filariose e malária.
Como subproduto da reciclagem dos pneus tem-se o enxofre, que é utilizado
na agricultura, indústria farmacêutica e na indústria de vulcanização. A Figura 2 ilustra
o processo PETROSIX com pneus.
Figura 2: Processo PETROSIX com pneus
2.5: Gerência de Pesquisa (GEPES)
Desde sua criação em 1954, a SIX vem atuando como um centro de
desenvolvimento de tecnologia, inicialmente para o aproveitamento do xisto e a
9
partir de 1991 em outros projetos, principalmente na área de refino, trabalhando em
conjunto com o CENPES.
Com a implantação do Programa de Desenvolvimento de Tecnologias
Estratégicas de Refino (Proter), que busca compatibilizar a maior oferta de petróleos
nacionais com o aumento da demanda de combustíveis e apelo da sociedade pela
melhoria do ar e dos produtos, a SIX passa a trabalhar nas áreas de craqueamento
catalítico, desasfaltação, hidrogenação e no desenvolvimento de novas rotas para o
aproveitamento do coque e do resíduo asfáltico.
A SIX também vem desenvolvendo tecnologia na área ambiental, com a
implantação do Laboratório de Combustão (LCS), que tem a função de analisar a
emissão de gases e material particulado durante o processo de combustão.
A SIX desenvolveu e patenteou, ainda, uma tecnologia para a incineração de
resíduos oleosos. Esta alternativa apresenta as vantagens da simplicidade
operacional e queima simultânea de diversos combustíveis, aliadas ao baixo custo
de construção e manutenção. Grande parte destes projetos estão sendo
desenvolvidos em conjunto com universidades. Assim, a SIX sedia um dos maiores
esforços de desenvolvimento tecnológico do país. Apesar do processo PETROSIX
ser considerado uma das tecnologias mais avançadas para o aproveitamento do
xisto brasileiro, existem áreas onde novas tecnologias estão sendo e podem ser
desenvolvidas e incorporadas para melhorar sua competitividade em relação a
outras alternativas energéticas ou mesmo o petróleo. As principais áreas de
desenvolvimento que estão merecendo a atenção são a melhoria do balanço
energético e a valorização dos produtos do xisto.
A SIX vem realizando estudos para desenvolvimento de processos e
equipamentos, principalmente, na área de sólidos e sistemas particulados para todo
o sistema PETROBRAS. A seguir, são apresentadas as unidades e laboratórios que
constituem o parque tecnológico da SIX.
2.5.1: Unidade Multipropósito de FCC (U-144)
•
Estuda o craqueamento catalítico de petróleos nacionais;
10
•
Testa e desenvolve equipamentos como ciclones, riser, regenerador,
resfriador de catalisador e stripper;
•
Determina a influência de variáveis de processo no rendimento e na
qualidade dos produtos;
•
Levanta dados de projetos de novas unidades de FCC de resíduos;
•
Desenvolve equipamentos e processos;
•
Testa catalisadores.
2.5.2: Unidade de Nebulizadores de FCC
•
Desenvolve dispersores de carga com boa distribuição de vazão,
formando um jato em leque, com tamanho e distribuição de gotículas
controlados,
alta
durabilidade, facilidade
de
construção, baixo
consumo de fluido de atomização e baixo diferencial de pressão.
2.5.3: Unidade a Frio de Ciclones
•
Avalia novas concepções e novas geometrias de ciclones;
•
Avalia novas condições operacionais e desenvolve ciclones de alta
eficiência, baixa perda de carga e elevado fator operacional.
2.5.4: Unidade de Recirculação de Catalisador
•
Pesquisa catalisadores para propiciar aumento da taxa média de
utilização do parque de refino;
•
Pesquisa materiais e desenvolve equipamentos para unidades de alto
desempenho e refino de petróleo nacional, com ênfase na conversão
de resíduos.
2.5.5: Unidade de Destilação
•
Produz cortes de gasolinas especiais de competição, especialmente
para a Fórmula 1;
11
•
Produz cortes de petróleo para estudo da qualidade e rendimentos dos
produtos;
•
Avalia internos de torres.
2.5.6: Unidade de Hidroconversão de Resíduos (U-104)
•
Desenvolve tecnologia de hidroconversão, que maximiza a produção
de diesel com qualidade, a partir do resíduo de vácuo de Petróleo
Marlim.
2.5.7: Unidade de Desasfaltação (U-2325)
•
Estuda a influência das variáveis operacionais na qualidade e
rendimento dos produtos;
•
Avalia o desempenho de solventes com diferentes composições;
•
Realiza testes de co-processamento e outros produtos na carga de
desasfaltação;
•
Faz a avaliação de internos de torres;
•
Produz cortes pesados para estudos de produção de asfaltos
especiais.
2.5.8: Unidade de Pneus
•
Armazena e promove a dosagem correta de pneus picados à carga de
minério. O processo PETROSIX permite a reciclagem de 140 mil
toneladas/ano, ou o equivalente a 27 milhões de pneus - 1 tonelada de
pneus rende: 532 kg de óleo, 24 kg de gás, 314 kg de carbono e 110
kg de aço, outros 20 kg são de rejeitos de borracha picada.
12
2.5.9: Unidade de Tratamento e Misturas
•
Reverte termicamente o concentrado nitrogenado de gasóleo gerado
na unidade de tratamento ácido de GOP, viabilizando a acidificação de
cargas para UFCCs;
•
Utilizada para preparo de misturas diversas, combustíveis para queima
e testes de fornos.
2.5.10: Laboratório
O laboratório está preparado para realizar análises elementares completas,
com equipamentos de última geração, tais como:
•
Espectrômetro de absorção atômica com geração de hidretos, da
Varian, modelo Aa220;
•
Espectômetro
por
quimioluminescência
e
fluorescência
para
determinação de nitrogênio e enxofre, da Antec, modelo NS9000;
•
Analisador
por
infravermelho
e
condutividade
térmica
para
determinação de carbono, hidrogênio e nitrogênio, da Leco, modelo
CHN2000;
•
Destilador D-86;
•
Cromatógrafos para destilação simulada (D-2887 e HT750) da HP;
•
Cromatógrafo para análise de PIANIO - HP 6890;
•
Bancada de destilação (PEV, POT STEEL e D1150);
•
Além de executar ensaios de acompanhamento de processos e
vendas da SIX, o laboratório fornece suporte a todas as plantas do
Parque Tecnológico, sendo capacitando a realizar mais de 120
trabalhos e ensaios.
2.5.11: Laboratório de Medição de Partículas a Laser
•
O Parque Tecnológico conta com um laser de argônio INNOVA 70C-5,
de 5 watts, para medir o tamanho de partículas (PDPA - Phase
13
Doppler Particle Analyser) e sua velocidade no interior de ciclones
(LDV - Laser Doppler Velocimeter).
2.5.12: Laboratório de Combustão
•
Obtém informações a respeito da queima de diversos tipos de
combustíveis e suas emissões, inclusive particulados;
•
Testa queimadores, materiais e equipamentos;
•
Otimiza condições operacionais, em função do combustível e
queimador.
2.5.13: Unidade de Tratamento Ácido de Gasóleo/Bancada
de Tratamento de Emulsões
•
Desenvolve o processo de remoção de nitrogênio básico de cargas de
FCC, visando aumentar a conversão e qualidade dos produtos;
•
Estuda emulsões diversas e tratamentos de rejeitos industriais.
2.6: Craqueamento Catalítico Fluido
O craqueamento catalítico é um processo de refino que visa aumentar a
produção de gasolina e GLP de uma refinaria, através da conversão de cortes
pesados provenientes da destilação do petróleo (gasóleo e resíduos), em frações
mais leves. É um processo largamente utilizado em todo o mundo, uma vez que a
demanda de gasolina em vários países é superior a dos óleos combustíveis. O
craqueamento catalítico corrige a produção de gasolina e GLP, suplementando a
diferença entre a quantidade obtida diretamente do petróleo e a requerida pela
refinaria de modo a atender ao mercado.
Até 1913, toda a gasolina produzida era obtida por destilação direta do
petróleo, assim, tanto a qualidade como a quantidade dependiam unicamente do
tipo de óleo cru refinado. Como havia grande variedade de petróleos, havia também
uma grande variação no rendimento e na qualidade das gasolinas. Em média, o
14
rendimento situava-se em torno de 20% em volume, para um produto com índice de
octanagem Research de 50.
A partir da segunda década do século, começaram a surgir processos
comerciais de craqueamento, objetivando suprir as necessidades da indústria
automobilística. Iniciando com o craqueamento térmico, o processo mais tarde
passou a utilizar a versão catalítica, em leitos fixo, móvel ou fluidizado,
desenvolvendo-se de forma notável esta última concepção, até atingir o estágio
onde hoje nos encontramos, onde o craqueamento catalítico fluido é praticamente
um processo imprescindível às modernas refinarias.
O FCC (Fluid Catalytic Cracking) é hoje um processo largamente difundido
em todo o mundo, devido principalmente a dois fatores. O primeiro deles consiste no
fato de contribuir eficazmente com a refinaria no sentido de ajustar sua produção às
reais necessidades do mercado consumidor local, devido à sua grande flexibilidade
operacional. O segundo fator que tornou consagrado o processo está ligado ao
aspecto econômico. Transformando frações residuais, de baixo valor comercial, em
derivados nobres de alto valor, tais como gasolina e GLP, o craqueamento catalítico
aumenta em muito os lucros da refinaria, devido à sua extraordinária rentabilidade.
2.7: Unidade Multipropósito de FCC (U-144)
Plantas multipropósitos são unidades de testes que visam reproduzir
condições operacionais reais. Estas unidades, de porte intermediário entre uma
unidade Piloto e Protótipo, buscam representar os fenômenos de um processo,
sendo adequadas para estudos de otimização de processos e equipamentos.
As principais características das unidades multipropósito são as seguintes:
•
A unidade deve ser flexível para buscar condições operacionais
extremas (não convencionais);
•
A unidade deve ser bem instrumentada para acompanhar com
precisão a grande maioria das variáveis do processo;
•
A
unidade
deve
permitir
modificações
nos
equipamentos
ou
instrumentação sem comprometimento financeiro ou de cronograma;
15
•
A unidade deve ter porte suficiente para validar um modelo (balanço
material e térmico adequado) através de testes desenvolvidos;
•
A unidade deve ter a possibilidade de operar com cargas especiais.
Assim,
os
principais
objetivos
a
serem
alcançados
por
unidades
multipropósito são os seguintes:
•
Aquisição
de
dados
experimentais
para
desenvolvimento
de
modelagem matemática e simulação do processo;
•
Desenvolvimento de equipamentos e sistemas;
•
Estudo de processos em novas condições operacionais, por exemplo,
alteração das vazões processadas e de catalisadores.
2.7.1: Descrição geral da U-144
A unidade de craqueamento catalítico visa o aproveitamento de certas
frações de petróleo, transformando-as em frações nobres, como GLP e Gasolina. A
unidade multipropósito estuda
o comportamento do processo considerando as
variáveis:
•
temperatura;
•
pressão;
•
catalisador;
•
dispersão;
•
relação catalisador/óleo;
•
tempo de contato.
As principais características da planta são:
•
Carga entre 60 e 300 kg/h;
•
Temperatura de reação entre 460 e 580 ºC;
•
Temperatura de carga entre 100 e 350 ºC;
•
Pressão do reator entre 1,0 e 2,5 kgf/cm2 man;
16
•
Temperatura de regeneração entre 600 e 730 ºC.
A planta é monitorada por um Sistema Digital de Controle Distribuído (SDCD)
contando com inúmeros indicadores de pressão, temperatura e diferenciais de
pressão, com grandes facilidades de acompanhamento.
O “riser” apresenta quatro pontos de injeção da carga: na base, a 4, 8 e 12
metros. Isto permite variar o tempo de contato entre 0,5 e 3,0 segundos com
qualquer tipo de carga.
A Figura 3 apresenta uma fotografia da U-144.
Figura 3: Unidade multipropósito de FCC
17
Capítulo 3: O Sistema PI
O sistema PI (Plant Information) corresponde a um conjunto de módulos de
software servidor/cliente para monitoramento e análise de plantas de processo. O PI
Universal Data Server (PI UDS) é a núcleo deste sistema, atuando como servidor de
dados baseado em Microsoft Windows. Operadores, engenheiros, gerentes e outros
interessados no processo podem utilizar uma grande variedade de aplicações
clientes para se conectarem ao PI UDS e observar dados da planta de processo
armazenados no sistema de arquivos do sistema (PI Archive). O Archive Subsystem
é instalado como parte do PI UDS e é responsável pelo armazenamento e
recuperação de dados numéricos, digitais e strings.
O PI UDS é ainda capaz de interagir com dados de processo armazenados
em outros sistemas através da utilização de objetos de software chamados COM
Connectors.
Um sistema PI típico consiste de vários computadores executando diversos
módulos de software que trabalham em cooperação com o PI UDS. Uma opção
freqüente é a utilização do PI-API para implementação de estruturas distribuídas
para coleta de dados.
3.1: PI UDS
O PI UDS é instalado em um nó da rede normalmente chamado de PI Home
Node. Como é mostrado no diagrama da Figura 4, o PI UDS é formando por diversos
módulos interligados, sendo que muitos deles são executados opcionalmente.
18
Figura 4: PI UDS com seus subsistemas, clientes e nós de coleta de dados
O PI UDS inclui:
•
Subsistemas Centrais (Core Subsystems);
•
Utilitários de administração e configuração;
•
Interfaces para simulação e monitoramento de dados;
•
PI-API e PI-SDK, incluídos no PI UDS para utilização interna em
aplicações do PI Home Node.
A seguir é apresentada uma descrição sucinta dos principais subsistemas
que compõe o PI UDS:
•
Base subsystem: Para cada variável de processo a ser rastreada, um
ponto é definido no sistema PI. Cada ponto possui aproximadamente
50 atributos, que definem como o dado será coletado e armazenado. O
Base Subsystem armazena estes atributos, além de manter a tabela
de estados digitais e configurações de segurança para usuários.
•
Snapshot Subsystem: No PI UDS, o valor mais recente para cada
ponto é chamado de Snapshot. O Snapshot Subsystem avalia os
19
valores em snapshot para determinar se estes serão enviados ao
Archive Subsystem, além de torná-los disponíveis para usuários
quando necessário.
•
Archive Subsystem: É onde as várias medições de cada ponto são
armazenadas. Como exemplo tem-se estados digitais (on/off),
pressões, vazões, temperaturas, setpoints, etc.
•
Update Manager Subsystem: Envia notificações de mudanças em
valores ou atributos de pontos para qualquer interface ou aplicação
cliente.
•
Message Subsystem: armazena o status e mensagens de erro do PI
UDS em um arquivo de “log”.
•
SQL Subsystem: É um módulo de software que processa consultas
SQL, incluindo aquelas submetidas ao PI ODBC Driver. O PI ODBC
Driver permite o acesso de aplicações cliente ao PI Archive utilizando a
sintaxe de banco de dados relacionais.
•
COM Connector Redirector: É um módulo de software utilizado como
interface para conexão do PI UDS a outros sistemas.
3.2: PI Network Manager
O PI Network Manager permite a conexão entre os subsistemas do PI UDS
residentes no PI Home Node. Também é responsável pelo gerenciamento
de
conexões de rede entre o servidor PI e aplicações clientes. Os clientes podem ser
produtos padronizados, como por exemplo o PI-ProcessBook, ou então aplicações
PI-API (Aplication Programming Interface) desenvolvidas por usuários.
O PI Network Manager gerência ainda a segurança do sistema PI através da
validação de clientes quando conexões são realizadas.
3.3: PI-API
O PI-API é uma biblioteca de funções que pode ser chamada a partir de
linguagens de programação como C, C++, Visual Basic, Delphi, etc. Estas funções
20
permitem ler e escrever valores no servidor PI, além de alterar ou obter
configurações de pontos.
Figura 5: Máquina Cliente com PI-API
Todas as aplicações clientes da OSIsoft (fabricante do PI) são escritas
usando o PI-API, o PI-SDK ou uma combinação de ambos para comunicação com o
servidor PI. Elas comunicam-se com o servidor através do protocolo de rede TCP/IP.
Entre os softwares clientes disponibilizados pela OSIsoft estão: PI-ProcessBook, PIDataLink, PI-BatchView, PI-SQC, etc.
3.4: Aplicativos clientes
Aplicativos clientes são softwares baseados em bibliotecas PI-API e permitem
acessar os dados armazenados no servidor PI.
Os principais aplicativos clientes disponibilizados pela OSIsoft são:
•
PI-ProcessBook (PI-PB)
•
PI-DataLink (PI-DL)
•
PI-ActiveView
•
PI-BatchView
•
PI-Profile
•
PI-Control Monitor (PI-CM)
•
PI-Manual Logger
21
•
PI-ODBC Driver
•
PI-SQC
•
PI-AlarmView
A Figura 6 ilustra esquematicamente vários nós de rede com aplicativos
clientes.
Figura 6: Nós de rede com aplicativos cliente
3.4.1: PI-ProcessBook
Ferramenta para exibição de informações de processo armazenadas no PI
Archive ou em outras fontes de dados. Permite a construção de gráficos dinâmicos
e de dados históricos, além de criação de telas de processo para acompanhamento
em tempo real. Incorpora o Microsoft Visual Basic for Aplications (VBA), permitindo a
automação e customização de rotinas e tarefas especiais.
3.4.2: PI-DataLink
Add-in para Microsoft Excel que possibilita a visualização de valores do
sistema PI de diversas formas, bem como copiá-los para uma planilha para realizar
análises adicionais. Com o PI-DataLink, um usuário pode trocar informações
22
diretamente com o banco de dados do PI. Essa ferramenta combinada com a
funcionalidade da planilha eletrônica faz com que o PI-DataLink seja um utilitário
poderoso e fácil de usar para reunir, analisar e relatar dados do PI.
3.4.3: PI-ActiveView
Ferramenta
para
visualização
de
dados
instantâneos
e
históricos
provenientes de diversas fontes. É possível visualizar telas de processos com dados
do PI Archive, bem como informações de fontes de dados ODBC (Open DataBase
Connectivity). Aplicações no PI-ActiveView podem ser desenvolvidas para
apresentação de dados na Internet ou Intranet corporativa. Telas do PI-ActiveView
podem também ser inseridas como controles ActiveX em planilhas eletrônicas
existentes ou outros meios de visualização de dados.
3.5: Fluxo de dados
A unidade fundamental de armazenamento de dados no sistema PI é
chamada de evento. Um evento consiste do tempo, valor e status associados a uma
variável.
Um evento significativo é aquele que é essencial para recuperação dos dados
originais. Buscando implementar um armazenamento de dados eficiente, há muitas
etapas ao longo do procedimento de aquisição e armazenamento que podem
determinar se um evento é significativo. Eventos não significativos são descartados
sem perda da informação essencial. A Figura 7 ilustra o fluxo de dados no sistema PI.
Figura 7: Fluxo de dados
23
Uma das grandes qualidades do Archive Subsystem é a capacidade de
armazenar dados eficientemente. Porém, o grau de eficiência depende de como o
PI UDS foi ajustado pelo administrador do sistema. A eficiência pode ser mensurada
por dois indicadores opostos: quanto espaço em disco é utilizado em oposição à
acuidade da informação armazenada. Assim, resulta que quanto mais eficiente é o
armazenamento, maior número de dias a informação pode estar disponível aos
usuários.
Assim, antes de serem armazenados em arquivos, os dados podem ser
filtrados eletronicamente e estatisticamente a fim de se determinar quais eventos
são significativos. O primeiro desses processos ocorre no nó ou ponto de coleta dos
dados e é chamado de Teste de Exceção, enquanto o outro é executado pelo
próprio servidor PI sendo chamado de Teste de Compressão. Um esquema sucinto
desses processos pode ser visualizado na Figura 8 e Figura 9.
Figura 8: Fluxo de dados nos testes de exceção e compressão
Figura 9: Exemplo do processo de filtragem dos dados
3.5.1: Configuração dos pontos
A maioria das fontes de dados para o sistema PI constituem-se de interfaces
de aquisição para sistemas de instrumentação. Um ponto no sistema PI é definido
24
com base na variável a ser rastreada, seja ela uma temperatura, vazão, status de
motor, etc. A Figura 10 ilustra a arquitetura do sistema PI na U-144.
Figura 10: Arquitetura do sistema PI na U-144
Cada ponto tem aproximadamente 50 atributos que definem como a
informação será coletada e armazenada. A configuração adequada destes atributos
é essencial para otimização do sistema PI, tanto em termos de eficiência no
armazenamento quanto para recuperação rápida dos dados. A criação e
manutenção de pontos pode ser feita utilizando um add-in para Microsoft Excel
chamado PI TagConfigurator, ou então através dos aplicativos PI PointerBuilder
(utilizado também para manutenção da tabela de estados digitais) e PIconfig
(ferramenta baseada em scripts executada em ambiente Microsoft DOS).
3.5.2: Snapshot
Um novo evento no sistema PI proveniente de uma interface ou de um
programa de entrada manual de dados é enviado ao Snapshot Subsystem. O
snapshot corresponde ao valor mais recente para um ponto, podendo ser entendido
como um buffer com capacidade para apenas um elemento. Quando um novo
elemento é coletado este se torna o novo snapshot. O snapshot previamente
25
armazenado é avaliado de acordo com os parâmetros de compressão e é então
enviado ao Event Queue ou descartado.
3.5.3: Teste de Exceção
A maioria das interfaces de coleta de dados são ajustadas de forma que
apenas dados significativos são enviados ao PI UDS. Este processo é chamado
teste de exceção. Assim, o valor atual de uma variável é comparado ao valor
anteriormente enviado, sendo que apenas valores significativamente diferentes
serão enviados ao PI UDS.
O teste de exceção é basicamente um meio de filtragem de dados. Os
programas executados na interface normalmente executam um algoritmo similar a:
•
Um novo valor é comparado ao último reportado. O novo valor não
será reportado a menos que:
o A diferença entre o novo e último valor é maior que ExcDev
(Exception Deviation Specification)
o E a diferença entre os tempos do novo e do último valor é
superior ou igual a ExcMin (Minimum Exception Time)
o OU a diferença entre os tempos do novo e do último valor seja
superior a ExcMax (Maximum Exception Time) se nenhum novo
valor é recebido da interface
Quando uma variável viola o teste de exceção, o valor que violou o teste e o
anterior são enviados ao PI UDS. A Figura 11 ilustra este processo.
26
Valor que passou
no teste de exceção
Trend se o valor
anterior não é enviado
Trend se o valor
anterior é enviado
Valor anterior
Valores em snapshot
Figura 11: Funcionamento do Exception Report
3.5.4: Compressão de dados
Após deixarem o Snapshot Subsystem, os eventos são avaliados de acordo
com as políticas de compressão a fim de se determinar se são eventos
significativos. Se sim, serão enviados ao Event Queue. Se não, serão descartados.
Este processo é conhecido como compressão.
O método de compressão utilizado permite ao sistema PI disponibilizar online quantidade de dados significativamente superior e com um maior nível de
detalhamento em comparação com sistemas convencionais de armazenamento,
baseados em média ou amostras periódicas, por exemplo.
O método de compressão utilizado pelo PI é conhecido como “swinging door
compression”. Este método descarta valores que estão dentro de um paralelogramo
em torno da linha que conecta o último valor arquivado e o último valor recebido.
Caso o último valor recebido faça com que o paralelogramo não compreenda todos
os pontos previamente avaliados desde o último ponto arquivado, então o valor
anterior a este último valor recebido é armazenado. A largura do paralelogramo é
duas vezes o valor de CompDev (um valor de desvio para cima e um para baixo). A
Figura 12
ilustra este processo.
27
Este
valor
arquivado
This value
will
beserá
archived.
Eng
Unit
Value
Um
paralelogramo deviation
entre este ponto
eo
A compression
blanket
último
arquivado
compreenderá
drawn
to thisnão
point
would not todos
osinclude
pontos previamente
all points avaliados,
since theassim
most, o
valor
anteriorarchived
será arquivado
recently
value, so the
previous value would be
archived.
Mostvalor
recently
Último
archived value
arquivado
CompDev
Compression
Deviation
Specification
Paralelogramo
Compression Deviation Blanket
Time
Figura 12: Método de compressão
Assim, um teste de compressão é realizado com base em quatro parâmetros:
•
CompDev (Compression Deviation): É o parâmetro de compressão
mais importante (especificado em unidades de engenharia), sendo
freqüentemente ajustado após a criação do ponto. Um valor razoável
para CompDev é de 1 a 2% o range para transmissores e de 0.5 a 1%
do range para termopares. O objetivo é filtrar ruído do instrumento ou
do processo e ainda assim armazenar mudanças significativas na
variável.
•
CompMin (Compression Minimum Time): Tempo mínimo a partir do
último evento arquivado para que um novo ponto possa ser arquivado.
•
CompMax (Compression Maximum Time): Tempo limite a partir do
último ponto arquivado para que um novo ponto seja arquivado.
•
CompDevPercent:
similar
ao
CompDev,
porém,
o
desvio
é
especificado como uma porcentagem do range em unidades de
engenharia.
28
Para pontos digitais, qualquer mudança é considerada como um evento
significativo. Assim, somente os parâmetros CompMin e CompMax devem ser
determinados.
Como pôde ser visto, o processo de compressão de dados é similar ao teste
de exceção, comportando-se como um filtro. A diferença é que as especificações de
exceção determinam quais eventos devem ser enviados ao PI, enquanto a
compressão determina quais dos eventos enviados ao PI serão arquivados.
3.6: Tags
Cada tag possui uma localização única no sistema PI, e deve ser utilizada
para armazenar fluxos individuais de dados, como por exemplo: a vazão em uma
tubulação, o modo de um controlador, um comentário em forma de texto, os
resultados de um totalizador, ou seja, qualquer informação que possa ser medida
pode ter seus valores armazenados em uma tag do PI.
Cada tag do PI possui uma série de atributos para descrever os diferentes
sistemas com que interage. Estes atributos podem ser resumidos pela pergunta que
cada definição tenta responder, como:
•
descrever a tag para uma aplicação cliente e para o usuário,
determinando como a informação deve ser exibida;
•
descrever a tag para a interface, determinando como e onde a
interface deve coletar a informação para a qual está destinada;
•
descrever a tag para o servidor PI, determinando como o servidor deve
armazenar a informação.
As tags possuem certos atributos que controlam como os dados são exibidos
e manipulados dentro do sistema. Alguns dos atributos mais importantes são:
•
Tag name: nome único destinado a cada variável monitorada;
•
Descriptor: descrição da tag com no máximo 26 caracteres;
•
Point Source: permite agrupamento das tags segundo a interface de
dados utilizada (SDCD, CLP, ou outras fontes). O valor padrão é K
para pontos da Pesquisa;
29
•
Zero, Span e Typical Value: valor mínimo, escala e valor típico;
•
Step: mostra a informação como ZOH (Zero Order Holder –
Interpolação de Ordem Zero) ou como uma interpolação linear;
•
Location#: define o endereço da informação no SDCD:
o Location1: contém o número da interface. Normalmente, o
número da interface deve coincidir com o número lógico
utilizado pelo software da interface (ABB/Bailey semAPI RunTime);
o Location2: deve ser igual a (INFI 90 Loop Number * 256) + PCU
Number;
o
Location3: INFI 90 Module Number;
o Location4: INFI 90 Block Number;
o Location5: especifica o tipo de ABB/Bailey Point Type que será
lido, com por exemplo: analog, digital, station, RCM, etc.
•
PtOwner, PtGroup, PtAccess: controla os usuários que podem
modificar ou visualizar os atributos das tags;
•
DataOwner, DataGroup, DataAccess: controla quem pode ler ou
escrever dados;
•
Compression Specification: controla como a informação é arquivada;
•
Exception Specification: controla como os dados e o ruído são filtrados
permitindo-se obter um fluxo de dados limpo e significativo.
3.7: Interfaces para outros sistemas
Interfaces são módulos de software que permitem a coleta de dados
provenientes de dispositivos computacionais que realizam o monitoramento e/ou
controle de um processo. Fontes de dados típicas são SDCDs, CLPs, sistemas de
laborátorio, etc. A maioria destas interfaces também permitem enviar dados no
sentido inverso, ou seja, do sistema PI para o processo. Atualmente, o sistema PI
30
conta com mais de 350 interfaces para mais de 500 sistemas de controle. A Figura 13
demonstra o papel da interface em um sistema de coleta de dados utilizando o PI.
Figura 13: Interface como intermediadora na coleta de dados
O sistema PI permite a coleta simultânea de dados através de uma grande
variedade de nós de rede. Esta arquitetura distribuída para a coleta de dados
oferece muitas vantagens em relação a uma estrutura monolítica, incluindo
escalabilidade, robustez e flexibilidade.
O PI-API corresponde a uma biblioteca de funções que permitem acesso ao
sistema PI, tanto para armazenamento quanto para recuperação de dados. A
OSIsoft tem usado o API para criar interfaces que podem ser executadas sobre uma
grande variedade de plataformas. Usuários podem também usar o PI-API para criar
suas próprias aplicações.
A Figura 14 apresenta um diagrama ilustrando uma arquitetura hipotética para
o sistema PI, composta de uma arquitetura distribuída para a coleta de dados.
31
Figura 14: Sistema PI com arquitetura distribuída para coleta de dados
3.7.1: Interface semAPI
Na U-144, a interface Bailey semAPI realiza a comunicação entre o SDCD
ABB/Bailey INFI 90 e o servidor PI. Para isso, é instalada em um nó da rede sendo
executada como uma aplicação cliente PI-API. Esta situação é ilustrada na Figura 15.
Figura 15: Interface entre o SDCD (DCS) INFI 90 e o servidor PI utilizando Bailey semAPI
32
A comunicação utilizando a interface Bailey semAPI exige o software
ABB/Bailey semAPI Run-Time, o software PI Bailey semAPI, da OSIsoft, e ainda um
cartão de comunicação ICI (INFI-NET to Computer Interface).
O ABB/Bailey semAPI Run-Time manipula em baixo nível os protocolos de
comunicação e o trânsito de dados da rede INFI-NET (principal via de comunicação
do SDCD INFI 90), disponibilizando-os em alto nível para a interface PI Bailey
semAPI. Isto é necessário uma vez que os protocolos de baixo nível são
proprietários.
O computador da interface é conectado ao SDCD via conexão SCSI
utilizando-se um cartão de comunicação INICI03. O cartão INICI03 consiste de três
módulos: INICT03 Computer Transfer, INNIS01 Network Interface, IMMPI01
Multifunction Processor Interface. Esta situação é ilustrada na Figura 16.
Figura 16: Conexão entre computador interface e o SDCD através do cartão INICI03
A interface PI Bailey semAPI fornece uma transferência de dados bidirecional
entre o sistema PI e a rede INFI-NET. Essa interface foi desenvolvida para tirar
proveito da biblioteca semAPI da ABB/Bailey. A interface controla todo o protocolo
de comunicações da rede INFI-NET, tornando assim possível que o sistema PI se
comunique com os cartões ICI conectados ao SDCD por uma série de métodos
(conexão serial, Ethernet e SCSI).
Todos os dados lidos pela interface são provenientes de relatórios de
exceção (Exception Reports) do SDCD INFI 90, que gera uma exceção sempre que
33
o valor ou status de uma variável muda, ou quando um limite específico de tempo foi
atingido desde o último relato.
A topologia de rede usual utilizada pela interface é a ponto-a-ponto, sendo
que os softwares ABB/Bailey semAPI Run-Time e PI Bailey semAPI estão no
mesmo computador. Este computador é fisicamente conectado por um cabo SCSI
ao cartão de comunicação INICI03, e este está conectado à rede INFI-NET, como
descrito na Figura 17.
Figura 17: Conexão entre o computador interface e o SDCD ABB/Bailey INFI 90
3.7.2: Seqüência de Ações da Interface
A seqüência de operações da interface após a inicialização é a seguinte:
•
A interface obtém todas as tags de um respectivo Point Source e
processa somente aquelas tags cujo atributo onde é descrito o número
da INICI coincide com aquele que foi passado para ela como
parâmetro na sua inicialização. No caso da U-144, o Point Source é “K”
e o número da INICI é 2. A interface cria então uma lista indexada pelo
número do pointID da lista de tags.
•
A interface tenta iniciar a comunicação com o cartão de comunicação
INICI. Quando a comunicação é estabelecida, a interface cria um
device driver que manipula fisicamente e em baixo nível os protocolos
de comunicação.
34
•
A interface então estabelece os tags na tabela do módulo de
comunicação
da
ABB/Bailey.
Após
todos
os
dados
serem
estabelecidos e conectados, a interface entra na fase de coleta de
dados.
•
A interface mantém a leitura dos Exception Reports até o número
máximo de exceções especificada na inicialização da interface.
•
Se mais de dois minutos se passarem desde a última leitura na tabela
de pontos, a interface verifica se houveram alterações nesta tabela e
promove então a alteração em sua tabela interna, adicionando,
deletando ou atualizando os atributos dos pontos.
•
Os dois últimos passos são repetidos continuamente enquanto a
interface estiver rodando.
•
Se a interface encontrar dez erros consecutivos durante a coleta de
dados, então ela volta para o início do procedimento, tentando reiniciar
a comunicação com cartão INICI.
35
Capítulo 4: Sistema de Controle Distribuído (SDCD)
O Sistema Digital de Controle Distribuído, muito embora não faça parte do
sistema PI como um todo, é o responsável pela coleta de dados tanto analógicos
quanto digitais na área de processo. Os dados enviados para o SDCD pelos
dispositivos de campo são os mesmos repassados em tempo real para interface que
enviará os dados para o PI Data Archive.
O SDCD, lançado em meados da década de 70, tinha a função de
automatizar uma planta por completo, substituindo os painéis dos controladores
(variáveis analógicas) assim como os de relés (variáveis digitais).
Os SDCDs flexibilizaram o tamanho de seu hardware de forma a atender
aplicações de pequeno/médio portes e também “abriram” o seu sistema viabilizando
a comunicação com uma grande variedade de hardwares/softwares do mercado.
Eles foram concebidos de forma a permitir a escalabilidade do sistema e também a
operação ininterrupta do processo, possibilitando a inclusão de cartões de I/O e a
redundância dos mesmos sem a parada da CPU do sistema.
Os Sistemas de Controle Distribuído têm sido usados em aplicações que
exigem um controle de processo em larga escala, onde é possível rodar várias
operações complexas para uma variada gama de processos diferentes.
A utilização de SDCDs reduziu o uso de computadores centralizados, e,
dentro deste conceito distribuiu a IHM (Interface Homem Máquina), o controle lógico
e a base de dados em diferentes placas de circuito dentro do computador, reduzindo
assim o risco de falhas do sistema como um todo.
A U-144 utiliza para controle e monitoramento de seus processos o SDCD
Bailey INFI 90, que controla ainda as unidades 104 e 2325. Este sistema é ainda
utilizado pelo Módulo Industrial de Processamento de Xisto (U-230), além de ser
largamente utilizado por outras unidades do sistema PETROBRAS. Nas seções
seguintes este sistema será brevemente apresentado.
36
4.1: SDCD Bailey INFI 90
O Sistema Digital de Controle Distribuído INFI 90 é um sistema distribuído de
gerenciamento e controle de processos. Utiliza uma série de unidades de controle
integradas, permitindo monitoramento e controle de variáveis de processos, tais
como vazões, temperatura e pressões, de acordo com as configurações de controle
definidas pelo engenheiro ou técnico do processo.
A arquitetura do INFI 90 é baseada em microprocessadores, possuindo
capacidade de realizar funções de controle e gerenciamento de processos,
permitindo ainda interligação de outros equipamentos, tais como Controladores
Lógicos Programáveis e Computadores de Processo, entre outros.
O sistema possui como principais características:
•
Alta capacidade computacional dos módulos microprocessados,
permitindo ao usuário realizar o controle avançado de múltiplas
variáveis no próprio sistema, sem a necessidade de computador
externo;
•
A arquitetura de comunicação do sistema permite que qualquer
estratégia de controle tenha acesso a qualquer entrada/saída
disponível no sistema, não sendo necessária a utilização de fiação.
Com isto torna-se simples a configuração de um controle avançado;
•
O controle seqüencial pode ser implementado na mesma PCU
(Process Control Unit) ou módulo que os controles analógicos.
O sistema é formado pelas seguintes partes:
•
Unidade de Controle de Processo: onde estão localizados os módulos
de interface com processo;
•
Estações de Operação: são as interfaces do sistema com o operador,
permitindo que este atue nos controles;
•
Rede de Comunicações: permitem a comunicação entre as diversas
partes do sistema e/ou com outras redes e sistemas externos.
37
A unidade de controle e monitoração de processo (PCU) é o coração do
sistema. Funcionalmente, a PCU é o local onde são realizadas as principais funções
de um sistema de automação:
•
Aquisição de dados;
•
Tratamento de sinais analógicos e discretos;
•
Controle regulatório básico e avançado;
•
Controle seqüencial;
•
Intertravamento/segurança de equipamentos.
As Vias de Comunicação de Dados (Data Highways) são utilizadas para
transmissão de dados dentro de uma PCU, entre PCUs, e a outros dispositivos, tais
como Estações de Operação. O sistema INFI 90 pode suportar as seguintes vias de
dados:
•
INFI-NET: é um sistema de comunicação digital, redundante e de alta
velocidade, sendo a via de comunicação central do sistema INFI 90;
•
CONTROLWAY: é a principal via de comunicação dentro de uma PCU.
É um sistema de comunicação redundante, capaz de interligar até 32
módulos inteligentes, chamados de Processadores de Multifunção –
MFP (Multi-Function Processor);
•
SLAVEBUS : é a via que interliga os diversos módulos escravos de
uma MFP. Sua capacidade é de interligar até 64 módulos escravos de
I/O a uma MFP;
•
FIELDBUS: é a via que interliga até 15 transmissores inteligentes
(smart transmitters) ao sistema. O FIELDBUS se interliga ao
SLAVEBUS através de um módulo escravo chamado Fieldbus Slave;
O sistema possui ainda uma grande variedade de ferramentas que facilitam a
integração do sistema de controle à filosofia de controle gerencial da empresa.
Estas ferramentas incluem interfaces de operação, interfaces com outros
dispositivos e ferramentas de engenharia. Entre as interfaces com outros
dispositivos, tem-se, por exemplo, a realização de cálculos e manipulação da base
dados (não disponível no sistema) através de uma interface ICI (INFI-NET to
38
Computer Interface), interligando a rede INFI-NET à outro computador, tal como é
realizada a interface com o sistema PI. A arquitetura do sistema INFI 90 é ilustrada
no Anexo A.
4.1.1: ABB Process Portal
O Process Portal é o sistema que realiza a Interface Homem Máquina para
vários sistemas de controle da ABB. Oferece flexibilidade e consistência como IHM
comum para os seguintes sistemas de controle:
•
Advant Mod 300;
•
Freelance 2000;
•
Symphony Harmony;
•
Symphony Melody.
O suporte ao sistema Symphony Harmony inclui o sistema INFI 90 OPEN,
que, a partir da compra da Elsag Bailey pela ABB, em 1998, passou a integrar a
linha de produtos ABB IndustrialIT - OperateIT.
O sistema Symphony Harmony também fornece suporte a fonte de dados
OPC (OLE for Process Control), permitindo a integração com sistemas de controle
de outros fabricantes.
As principais características do ProcessPortal são:
•
Utilização de tecnologia baseada em “Internet Browser”, fornecendo
integração de todas as tarefas supervisórias em uma única janela;
•
Sistema de controle “True open”;
•
Interface DCOM para acesso à informação;
•
Servidores de dados históricos e configurações baseados em SQL
Server;
•
Políticas de segurança e reconhecimento de usuários que permitem
adaptação da interface IHM às necessidades específicas do processo
e configurações individuais dos usuários;
39
O Process Portal é executado em estações de trabalho sobre o ambiente
Windows 2000. Utilizando gráficos de processo interativos, os operadores do
processo podem monitorar e controlar todas as malhas analógicas e dispositivos
digitais conectados a rede INFI 90. O Process Portal fornece uma interface que
permite configurar e alterar gráficos supervisórios, configurações de variáveis (tags),
alarmes, funções de controle de processos, sequenciamento, e configurações de
segurança, permitindo definir níveis de segurança aos diversos usuários. As maioria
das alterações são realizadas imediatamente, on-line, não requerendo tempos de
compilação e interrupções ao processo.
A Figura 18 apresenta uma tela de processo do ProcessPortal, podendo-se
visualizar sua execução utilizando o browser Internet Explorer.
Figura 18: Uma das telas de processo da U-144 no Process Portal
40
Capítulo 5: Tarefas Desenvolvidas
Neste capítulo são descritas as principais atividades desenvolvidas durante o
período de estágio. Como pode ser visto nas próximas seções, os trabalhos
realizados concentraram-se na resolução de problemas relacionados aos sistemas
de aquisição e armazenamento de dados da U-144. Assim, são sumarizadas as
etapas envolvidas na instalação e administração do sistema PI, além de descrito o
processo de reinstalação e configuração da interface ABB Process Portal.
5.1: Instalação e configuração do servidor PI
O foco do trabalho de estágio estava na instalação, configuração e
administração do sistema PI para as unidades de pesquisa da SIX, em especial para
unidade U-144. Assim, inicialmente, foi realizado o estudo do sistema PI através de
manuais, documentação e suporte técnico.
A instalação de um no servidor para o PI era necessária, pois, as unidades
144, 104 e 2325 estavam utilizando um servidor instalado na gerência de produção,
responsável também pela coleta de dados do Módulo Industrial (U-230). Esta
situação era desconfortável, principalmente, devido ao fato de a gerência de
pesquisa não ter acesso direto ao sistema, sendo este administrado por operadores
da U-230. Havia interesse em dominar o sistema e desmistificá-lo, possibilitando
gerenciamento e configurações especificas conforme será descrito adiante. Além
disso, a versão utilizada na U-230 já estava bastante desatualizada (versão 3.2).
5.1.1: Instalação do servidor PI em uma nova máquina
Primeiramente, realizou-se a instalação do sistema em uma máquina de
testes. Depois, o sistema foi instalado em um servidor específico (s2810au03),
adquirido exclusivamente para este fim, não sendo instalados softwares adicionais
que pudessem concorrer em recursos com o sistema PI. Neste servidor foram
instaladas versões atualizadas do sistema (versão 3.4) e de seus aplicativos, obtidas
junto ao suporte do fabricante (Osisoft).
41
Os aplicativos instalados na máquina s2810au03 foram os seguintes:
•
PI-UDS (Universal Data Server);
•
PI-SDK (Software Development Kit) – fornece uma interface entre o
sistema
PI
e
linguagens
de
programação,
facilitando
o
desenvolvimento de aplicações clientes;
•
PI-ProcessBook – ferramenta cliente para exibição de dados de
processo armazenados na base de dados do sistema PI (PI Data
Archive) e outras fontes de dados;
•
PI-ICU (Interface Configuration Utility) – aplicativo para configuração
de interfaces;
•
PI-SMT (System Management Tools) – conjunto de aplicativos gráficos
utilizados para administrar o sistema PI de computadores clientes;
•
PI-DataLink – fornece uma interface entre a base de dados do sistema
PI e aplicativos de planilha eletrônica (Excel e Lotus 1-2-3) rodando
sobre plataforma Windows. Instala o add-in PI-TagConfigurator.
Além de configurações na máquina interface, que deveria ser ajustada de
modo que passasse a enviar dados para o servidor recém instalado, houve
necessidade de configurações no próprio servidor, que deveria ser habilitado de
modo a permitir escrita de dados provenientes da interface.
Para configurar a interface de modo que esta passasse a enviar dados para o
novo servidor PI, foi necessário editar dois arquivos na própria máquina interface. O
primeiro deles é chamado “pilogin.ini” e estabelece a quais servidores PI o nó PI-API
pode se conectar, permitindo-se definir um servidor padrão. O segundo arquivo
configurado foi o “blysem.exe”, que estabelece os parâmetros de configuração da
interface PI Bailey semAPI. O código do arquivo “blysem2.bat”,que coleta e transfere
corretamente os dados da interface pode ser visualizado a seguir:
rem BLYSEM2.bat
rem Os parametros a seguir sao da interface da pesquisa
rem ICI=2 (numero do ICI)
rem PointSource tipo K (ad pesquisa)
rem IN=2 (respectivo location1 - parametro das tags tipo K no PI
Server)
rem ID=1 (ICI primario, nao redundante)
rem com output habilitada
rem f sao definicoes de scan classes
42
rem ec = io rate counter (utilizado se necessario)
rem to = ICI timeout
rem me = numero maximo de excecoes por iteracao
rem outros parametros setados como default.
blysem2.exe /host=S2810AU03:5450 /id=1 /ec=1 /ps=K /in=2 /ici=2
/me=1000 /to=180 /f=00:00:15,00:00:00 /f=00:00:30,00:00:00
/f=00:00:45,00:00:00 /of=1 /q /stopstat
Para configurar o servidor PI de modo que este fosse habilitado a receber
dados provenientes da interface, foi necessário acrescentar a máquina interface na
tabela PI-Trust, que pode ser acessada a partir da ferramenta PI-SMT. A tabela PITrust é utilizada para permitir a clientes PI-API (no caso a interface) acesso
automático a aplicações do servidor. Após alguns testes verificou-se que o servidor
estava aquisitando corretamente os dados.
Após os procedimentos de instalação, foi realizada a inserção da base de
dados no novo servidor (inserção das tags e suas configurações), realizando-se
atualização em relação a base de dados do SDCD. Nesta etapa foram criadas as
tags no novo servidor, além de eliminação de tags não mais existentes no processo
e correção daquelas que não estavam aquisitando dados corretamente devido a
problemas de configuração (localização não atualizada das tags no SDCD e
atributos mal ajustados). Esta etapa foi realizada utilizando-se o add-in PITagConfigurator e estendeu-se durante todo o período de estágio, sendo esta uma
das atribuições fundamentais do administrador do sistema.
5.1.2: Configurações pós-instalação
Após a instalação do sistema, foi necessária a formatação dos valores
numéricos das tags, que são mostradas em relatórios ou em aplicativos clientes
como o PI-ProcessBook. Os tipos de formato admitidos são mostrados na tabela
abaixo:
43
Novas tags, após criadas, possuem como default DisplayDigits -5. A alteração
do tipo de formato pode ser realizada através do aplicativo PIconfig utilizando-se o
prompt de comando do DOS. Abaixo são mostradas algumas linhas de código no
PIconfig que alteram o formato numérico para “23.45”, por exemplo:
@table pipoint
@mode edit
@select tag=*, pointsource=*
@modify displaydigits=2
@endsection
Este tipo de alteração foi necessária e executada em todas as tags
armazenadas no servidor s2810au03, pois, existem diferentes tipos de tags (digitais,
analógicas, alarmes, etc) e que necessitam configurações especificas para exibição
de seus dados.
Realizou-se ainda a criação de novos archives. Archives são a base de dados
do servidor PI, correspondendo aos arquivos onde os dados de processo que
passam pelos testes de exceção e compressão serão armazenados após
aquisitados. Cada archive é utilizado até que seja completamente preenchido,
passando o servidor PI a gravar dados no archive seguinte. Após todos os archives
terem sido preenchidos, o servidor passa a sobrescrevê-los, devendo-se antes disso
proceder um backup permanente de cada archive em um meio de armazenamento
externo, como por exemplo CD-ROM. Na instalação do PI-UDS são criados, por
default, apenas três archives.
A criação de novos archives pode ser realizada em qualquer instante,
podendo existir no máximo 99 de qualquer tamanho. Para o servidor PI da U-144
foram criados inicialmente quinze archives de 500 MB cada. O tamanho de 500 MB
foi escolhido de forma que seja possível o backup permanente em CD-ROM.
5.1.3: Criação de um sistema de backup
Serão abordadas duas formas de backup. A primeira refere-se a backups
regulares, executados sobre dados que mudam freqüentemente. A segunda forma
refere-se a backups permanentes, que devem ser executados assim que um archive
é substituído (é completamente preenchido, sendo posteriormente sobrescrito).
44
5.1.3.1: Backups regulares
Deve-se programar backups regulares sobre dados que sofram alterações
freqüentes. Para isso, pode utilizar a ferramenta “pibackup.bat”, compatível com as
versões 3.2 SR1 e subseqüentes.
A sintaxe é a seguinte:
pibackup.bat <pi root path> <backup path> <number of additional
archives> [-install]
Como por exemplo:
pibackup.bat d:\pi c:\pibackup 1 [-install]
O argumento <number of additional archives> especifica o número de
arquivos adicionais a serem copiados além do archive que está sendo utilizado no
momento. A execução deste comando pára temporariamente a execução de cada
um dos subsistemas PI, entretanto, não há perda de dados. Estes serão
armazenados no “Event Queue”.
Neste exemplo de implementação, os arquivos de backup são armazenados
em disco, podendo posteriormente ser armazenados em outro meio, como, por
exemplo, fita. Isto é porque uma gravação de disco-para-disco é muito mais rápida,
não deixando os archives off-line mais tempo que o necessário.
O argumento [-install] é opcional. Para poder utilizá-lo é necessário agendar
sua execução no aplicativo Scheduled Tasks do Windows, permitindo a execução
automática do aplicativo “pibackup.bat”.
5.1.3.2: Backups permanentes
Após cada archive ter sido preenchido, será necessário um backup
permanente pois, posteriormente, estes serão sobrescritos. É recomendado
aguardar um período de aproximadamente duas semanas antes de executar o
backup definitivo de cada archive que foi completado, permitindo que algumas
alterações devido a processamentos executados sobre os dados possam ser
armazenadas.
45
Para executar um backup permanente de um único arquivo, podem-se
executar os comandos abaixo (neste exemplo supondo-se que se quer armazenar o
archive 2):
piartool –bs 2
copy myarchivefile.dat c:\MyBackupDir
copy myarchivefile.ann c:\MyBackupDir
piartool –be
Após este procedimento, deve-se copiar o arquivo de backup para outro
meio, como, por exemplo, fita ou CD-ROM.
Opcionalmente, para fins de organização, pode-se gerar um arquivo que
identifica os horários de início e fim de armazenagem de dados associados a um
archive através do comando:
piartool –al > c:\MyBackupDir\myarclist.out
5.1.3.3: Recuperação de backups
Para recuperação de arquivos armazenados em meio externo (fita, CD-ROM,
etc) devem-se seguir os procedimentos:
•
Copiar o arquivo para o disco rígido local;
•
Não sobrescrever o arquivo quando este for copiado;
•
Registrar o arquivo em sua nova localização através do comando:
piartool –ar c:\pi\dat\RestoredArc.dat
•
Ajustar o arquivo de forma que não possa ser sobrescrito, executandose: piartool –ads c:\pi\dat\RestoreArc.dat
5.1.4: Atualização e configuração de tags
Após a instalação do servidor PI na máquina S2810au03, foi necessária a
inserção das tags das unidades U-144, U-104 e U-2325 neste servidor. Como já
descrito, este processo foi realizado através do add-in PI-TagConfigurator, que
exporta as tags e seus atributos através de planilhas Excel. A Figura 19 mostra a
planilha utilizada para inserção e atualização de tags.
46
Figura 19: Planilha utilizada para inserção e atualização de tags
Após este procedimento, foi necessário realizar um estudo comparativo entre
as tags inseridas (importadas do antigo servidor PI) na base de dados do sistema PI
recém instalado e as tags efetivamente utilizadas pelo SDCD, visto que as tags
levantadas já se encontravam desatualizadas, sendo que muitas já não existiam e
outras apresentavam erros de configuração.
Após as configurações iniciais, foi necessária atualização constante da base
de dados do servidor PI. Assim que eram realizadas alterações nas tags do SDCD,
estas eram atualizadas no PI. Este procedimento era bastante importante, pois, tags
não corretamente especificadas não são aquisitadas pela interface, sendo sua
informação perdida. O procedimento de conferência das tags era realizado através
de tabelas em MS-Access que eram geradas pelo SDCD e continham todas as tags
do sistema, além de seus atributos (zero, span, Location, Tag Type, etc.), sendo
então realizadas consultas buscando-se a divergência de dados entre o SDCD e a
base de dados do servidor PI.
47
5.1.5: Construção e atualização de telas de processo
As telas de processo da U-144 em sua grande maioria encontravam-se
desatualizadas. Por ser uma unidade de pesquisa, a U-144 está constantemente
sofrendo modificações, sendo freqüente a inserção de novos equipamentos,
alteração nas tubulações e modificações nos parâmetros de configuração e modos
de controle. Assim, a medida que as alterações são realizadas, estas são
instantaneamente efetuadas no SDCD para que este esteja adequado para o
controle da planta em sua nova configuração estrutural.
As telas de processo do sistema PI eram construídas de forma bastante
manual, utilizando-se a telas de controle do SDCD como base, porém, sendo
efetuadas alterações de cores e forma de exibição dos valores das tags. Deste
modo, houve a necessidade de adequação de todas as telas de processo da U-144
para que estas pudessem ser facilmente atualizadas e refletirem as últimas
modificações efetuadas nas telas de controle do SDCD.
Assim, utilizou-se uma nova metodologia para confecção de telas, passandose a utilizar como pano de fundo para as telas do PI o mesmo pano de fundo
utilizado nas telas do SDCD. Desta forma, assim que atualizações eram realizadas
nas telas do SDCD, o operador responsável disponibilizava o pano de fundo das
telas alteradas, sendo então efetuada substituição e adequação apenas do pano de
fundo (e das tags quando necessário) e não de toda a tela. Outra vantagem desta
abordagem é que as telas do PI passaram a ser idênticas as telas do SDCD,
facilitando sua análise. A Figura 20 mostra um exemplo de tela construída no PIProcessBook.
48
Figura 20: Exemplo de tela de processo do PI-ProcessBook
Além de atualização das telas da U-144, foram confeccionadas todas as telas
de processo da U-104, que ainda não existiam no sistema PI.
5.2: Resolução de problemas de hardware no computador interface
Desde sua instalação, o computador que serve de interface entre o SDCD e o
servidor PI vinha apresentado problemas de funcionamento, prejudicando a
confiabilidade do sistema PI. Sua operação era instável, sendo freqüente a
ocorrência de “congelamentos” do sistema operacional. Esta situação era bastante
delicada, uma vez que o “congelamento” da interface resultava em perda definitiva
dos dados.
Várias alternativas foram executadas na tentativa de resolução deste
problema. Primeiro, imaginava-se que o problema pudesse estar na instalação do
sistema operacional (Windows NT 4.0 SP5) e dos softwares dedicados da interface
(ABB/Bailey semAPI Run-Time e PI Bailey semAPI). Após reinstalação destes
49
verificou-se que o problema persistia. Imaginou-se então que o problema poderia
estar no hardware da interface, passando-se a examinar os itens de hardware que
pudessem causar este comportamento. Uma vez que a máquina está localizada na
sala de controle da unidade, sem ar-condicionado e ao lado dos painéis do SDCD, a
primeira
suspeita
era
que
a
interface
estivesse
“congelando”
devido
a
superaquecimento do processador. Assim, procedeu-se a troca do “cooler” e
verificou-se que problema continuava. O próximo item a ser examinado foi a placa
de comunicação SCSI. Esta também foi substituída, não havendo diferença no
comportamento do computador interface.
Por fim, após a execução de testes com a máquina interface desconectada
do SDCD (conexão SCSI desconectada do cartão ICI), verificou-se que o
“congelamento”
ocorria somente quando a placa de rede estava conectada.
Procedeu-se a substituição desta e finalmente a máquina interface passou a
funcionar continuamente. A placa de rede defeituosa havia sido instalada pelos
técnicos da ABB, quando da instalação do sistema INFI 90. Assim, para sua
substituição foi necessário solicitar uma nova licença do software ABB/Bailey
semAPI Run-Time, pois este possui sua licença de funcionamento vinculada a placa
de rede em utilização. Após recebimento da nova licença e configuração dos
aplicativos do ABB/Bailey semAPI Run-Time, a máquina interface foi colocada em
funcionamento, passando então a transmitir os dados de forma contínua ao servidor
PI.
O correto funcionamento do computador interface é imprescindível, uma vez
que este corresponde a única ligação entre o sistema PI e o processo. Além disso,
tem-se ainda que a interface é responsável pela tarefa de buferização dos dados no
caso de uma indisponibilidade do servidor PI.
5.3: Reinstalação do sistema Process Portal
Desde sua instalação, o sistema Process Portal vinha apresentando
problemas relacionados, principalmente, a lentidão na abertura de telas de controle,
lentidão na obtenção de relatórios de testes e má qualidade
dos dados
armazenados no servidor de dados históricos. A não confiança nos dados históricos
constituía-se no problema mais crítico.
50
Por ser uma unidade de pesquisa, a U-144 tem sua operação diferenciada
em relação às unidades industriais de refinarias, por exemplo. Em unidades
industrias não há grande interesse em relação ao armazenamento e utilização de
dados históricos, salvo em ocasiões em que se deseja identificar algum problema
através da investigação do progresso de algumas variáveis. Todavia, em unidades
de pesquisa, cujo funcionamento não é contínuo e sim determinado pela execução
de testes sobre a unidade, há grande interesse na geração e manutenção de dados
visando posterior análise.
Os dados históricos são obtidos do sistema Process Portal através de um
add-in para Excel chamado EBReportFunctions, responsável pela busca de dados
no servidor de dados históricos (Historian Server). Inicialmente, suspeitava-se que o
problema na recuperação dos dados poderia estar associado ao add-in
EBReportFunctions. Assim, buscou-se um meio de acesso direto aos dados, sem o
uso deste add-in, pretendendo-se utilizar consultas diretas a base de dados
(implementada em SQL Server) através da interface de comunicação ODBC.
Porém, a tabela na qual os dados são armazenados possui uma codificação que
impossibilita a consulta direta aos dados.
Após reunião com o engenheiro José Fratantônio, especialista da ABB nos
sitemas INFI 90 e Process Portal, este elucidou algumas questões referentes ao mal
funcionamento do sistema Process Portal. Primeiramente, o problema de lentidão
do sistema foi associado à arquitetura instalada, que possuía poucos recursos
computacionais para gerenciamento de um número elevado de pontos (tags). O
problema da má qualidade dos dados históricos foi relacionado à configuração
incorreta do sistema, que para economizar espaço em disco aplicava sobre as tags
aquisitadas uma política de compressão, similar à do sistema PI, que permitia que
somente pontos que variassem uma porcentagem do range bastante significativa
em relação ao último ponto gravado fossem armazenados. A Figura 21 mostra a
janela de configuração dos parâmetros de compressão para todas as tags
armazenadas na tabela “Historian_1”, do Historian Server.
51
Figura 21 – Janela de configuração dos parâmetros de compressão
Além dos testes de compressão, o sistema Process Portal executava um
tratamento estatístico sobre os dados, armazenando definitivamente no servidor de
dados históricos somente a média móvel de um determinado número de amostras
que passavam nos testes de compressão. Esta configuração é usual em unidades
industriais, onde o servidor de dados históricos tem por função armazenar apenas
uma tendência da evolução das variáveis. Porém, como na U-144 os balanços de
massa e energia dos testes sobre a unidade são realizados com valores de máximo,
mínimo, média e desvio padrão obtidos a partir dos dados gravados no Historian
Server, tem-se que os dados armazenados devem traduzir com o máximo de
detalhes a evolução das variáveis de interesse durante o período de realização dos
testes.
Como primeira medida, o engenheiro da ABB desabilitou a política de
compressão para todas as tags do sistema (aproximadamente 2000), o que levou o
Historian Server a armazenar os dados por um tempo inferior a 3 dias, em
contraponto a configuração original que retinha os dados por um período de 30 dias,
antes de sobrescrevê-los.
52
Porém, em uma nova visita pretendendo a resolução destes problemas, o
Engenheiro José Fratantônio procedeu a reinstalação e alteração da arquitetura do
sistema Process Portal. A arquitetura original do sistema é apresentada na Figura 22.
Figura 22 – Arquitetura original do Process Portal
Como pode ser visto na Figura 22, a arquitetura original do sistema era
composta de quatro computadores, cada um deles concentrando vários serviços. As
máquinas RTDS1 e RTDS2 eram conectadas à rede de processo (rede INFI-NET,
possuindo instalado o software ABB/Bailey semAPI Run-Time), tinham como
sistema operacional Windows 2000 Server e executavam os serviços de RTDS
(Real Time Data Server), Domain Controller (gerenciamento de rede, DNS e contas
de usuários) e Client (onde é efetuada operação da unidade). O computador
CONFIG era conectado à rede intranet própria do sistema Process Portal, contendo
também como sistema operacional Windows 2000 Server e tendo instalado os
serviços de configuração (Config Server), armazenamento de dados históricos
(Historian Server) e Client. Por fim, a máquina CLIENT4 era apenas um terminal de
operação, possuindo como sistema operacional Windows 2000 Professional e tendo
instalado somente os serviços de Client.
Esta arquitetura foi então modificada, acrescentando-se seis máquinas, como
pode ser visto na Figura 23.
53
Figura 23 – Nova arquitetura do sistema Process Portal
Desta forma, visando a distribuição do processamento, os serviços foram
distribuídos nas diversas máquinas. Assim, as duas máquinas conectadas à rede
INFI-NET tiveram instalados somente os serviços de RTDS, sobre a plataforma
Windows Professional. Os serviços de configuração e armazenamento de dados
históricos também foram instalados em máquinas dedicadas (Windows 2000
Server), bem como os Domain Controllers PRIMARY e BACKUP (Windows 2000
Server) e os clientes (Windows 2000 Professional).
Assim, após a migração para nova arquitetura, teve-se como resultado
imediato incremento na velocidade do sistema, no que diz respeito, principalmente,
a abertura de telas de controle e operação do sistema.
Procedeu-se então a configuração do sistema, de modo que este gerasse
dados históricos de melhor qualidade. A configuração original possuía ajustado o
parâmetro de compressão em 5% do range para todas as tags, como mostrado na
Figura 21.
Esta configuração foi alterada, passando-se a 1% do range, com exceção
das tags utilizadas nos balanços de massa e energia e dos totalizadores, que foram
configuradas sem compressão (Raw Collection). Para o grupo de tags utilizadas nos
balanços e para os totalizadores (efetuam totalização de vazões em massa num
período de tempo), houve ainda execução de configurações no próprio SDCD, que
estava ajustado para enviar valores ao Historian Server (Exception Reports) apenas
quando houvessem variações acima de 1% do range de cada tag. Esse valor foi
então ajustado para uma unidade de engenharia, entrando-se no sistema (através
de uma estação de engenharia CAD) com a porcentagem correspondente. Esse
54
ajuste foi necessário, pois, em totalizadores, por exemplo, o range de medição
geralmente é muito maior o que a faixa de medição efetivamente utilizada,
acarretando que variações de 1% do range acabam por serem significativas e não
podem ser descartadas.
A fim de comprovar esta situação, foi efetuado um teste antes da reinstalação
e reconfiguração do Process Portal. Assim, utilizando-se uma fonte estável de
corrente, injetou-se um sinal de 10 mA (range de 4 a 20 mA), correspondente à
leitura de 15,01 Kg/h, na saída do controlador de vazão FIC-144507 durante o
período de uma hora. Como esta vazão permaneceu constante durante o período do
teste, esperava-se que o tatalizador FQI-144507, que realiza a integração do sinal
obtido do FIC-144507, registrasse ao final do teste 15,01 Kg. A Figura 24 e Figura 25
mostram a evolução destas tags em um terminal de operação.
Figura 24: Leitura do painel no momento de início do teste
55
Figura 25: Leitura do painel após uma hora de teste
Porém, os valores armazenados no servidor de dados históricos são
bastante diferentes dos observados nos painéis de operação. A Figura 26 mostra os
valores obtidos do Historian Server utilizando-se um relatório de testes.
Figura 26: Valores obtidos do Historian Server
Assim, observa-se a divergência entre os valores instantaneamente lidos e
exibidos nos terminais de operação e os valores efetivamente armazenados no
Historian Server. Para a FIC-144507 espera-se no relatório que os valores de
56
máximo, mínimo e media fossem 15,01 Kg/h. E para o totalizador era esperado um
valor mínimo de 0,00 e um máximo de 15,01 Kg. Após reinstação do Process Portal,
reconfiguração dos parâmetros do Exception Reports e eliminação da compressão,
os valores apresentados pelo painel de operação e os obtidos do Historian Server
ficaram muito próximos, dentro de um limite considerado aceitável.
Durante o processo de instalação e configuração do Process Portal, o
sistema PI foi utilizado como referência na comparação com os valores
armazenados no Historian Server. Acompanhando os dados gerados
e
armazenados por ambos os sistemas com os valores instantâneos gerados nos
terminais de operação, verificou-se que o sistema PI armazenava dados
significativamente mais precisos (aplicando as políticas normais de compressão e
exceção) dos que os armazenados no Process Portal antes de sua reinstalação,
sugerindo que o sistema PI poderia ser utilizado como fonte de dados para
realização dos balanços de massa e energia, um dos objetivos há tempo almejados
pelos engenheiros de acompanhamento das unidades de pesquisa.
Ressalta-se que as alterações efetuadas no sistema Process Portal não
tiveram nenhuma influência sobre o sistema PI, que durante o período de
reinstalação e configuração do Proccess Portal permaneceu on-line, aquisitando e
armazenando dados normalmente. Isto explica-se pelo fato de o Process Portal e o
sistema PI utilizarem cartões de comunicação distintos para interfaceamento com a
rede INFI-NET. Assim, alterações em configurações no Process Portal não refletem
sobre o sistema PI.
5.3.1: Configuração de tags no PI para realização de testes
Como apresentado, a obtenção de dados de testes a partir do Process Portal
era realizada de forma bastante não confiável. Como alternativa a esta incerteza,
buscou-se a utilização de dados armazenados no servidor PI. Para utilização com
esta finalidade, visando a obtenção de melhores resultados, foi necessário realizar
algumas configurações nas tags de interesse antes da realização dos testes.
O sistema PI é originalmente utilizado para monitoramento on-line e
armazenamento de dados históricos. Porém, devido às políticas de exceção e
compressão, não armazena valores exatos e sim uma boa tendência do que ocorreu
57
no processo, visto que somente os valores que passarem nos testes de exceção e
compressão são gravados, sendo os demais descartados.
Assim, antes da realização dos testes, criou-se uma ferramenta para que os
parâmetros de compressão e exceção fossem desabilitados durante o período de
realização de testes, de forma que todos os pontos enviados pelo SDCD à interface
fossem gravados. A Figura 27 apresenta uma mesma tag com seus parâmetros de
compressão e exceção originais e desabilitados para realização de testes.
Figura 27: Evolução de um mesma tag com seus parâmetros de compressão e exceção
originais e desabilitados
A utilização de valores precisos é bastante importante para realização dos
balanços de massa e energia, pois, o software utilizado no cálculo possui como
entradas valores de média, máximo, mínimo e desvio padrão de cada variável de
interesse no período de realização do teste.
Uma vez que a não execução dos testes de exceção e compressão resultam
em um número bastante elevado de pontos a serem armazenados, fez-se
necessária a criação de um método de configuração das tags de interesse para que
estas tivessem seus parâmetros de exceção e compressão desabilitados somente
durante a execução de testes. Para automatizar o processo de configuração destas
58
tags foram criados dois arquivos “Batch” do MS-DOS. Um habilitando e outro
desabilitando compressão e exceção para o conjunto de variáveis de interesse.
Estes arquivos “Batch” executam comandos sobre o aplicativo PIconfig de forma a
aplicar as alterações necessárias. Assim, antes da realização de testes é executado
o “Batch” que desabilita compressão e exceção, e quando encerram-se os testes é
executado o outro arquivo “Batch”, retornando as configurações originais de cada
tag. Abaixo é mostrado o código do script apontado pelo “Batch” que executa
alterações nas tags utilizando o PIconfig.
@table pipoint
@mode create, t
@istructure tag,excdev,compressing
@input teste_on.dat
@endsection
@exit
Este código mostra em que parâmetros as alterações serão realizadas
(excdev, compressing) e aponta um arquivo de entrada (teste_on.dat) contendo as
tags e os valores destes parâmetros para cada tag. Um trecho do arquivo
teste_on.dat é apresentado abaixo.
AI-14401,0,0
AI-14402,0,0
AI-14403,0,0
DI-144511,0,0
FI-14405,0,0
FI-144400A,0,0
FI-14440A,0,0
FI-14451A,0,0
FI-14451B,0,0
FI-14455,0,0
FIC-14403,0,0
FIC-14404,0,0
FIC-14410A,0,0
Por fim, tem-se como desenvolvimento futuro a execução automática destes
arquivos “Batch” vinculada a uma tag do processo que aponte de forma precisa o
estado da unidade (se realizando testes ou não).
Além das ferramentas para configuração de tags, criou-se ainda uma planilha
eletrônica em Excel responsável pela recuperação de dados e efetuação dos
cálculos de média, máximo, mínimo e desvio padrão durante o período de
realização de testes. Através da utilização do PI-DataLink, esta planilha recebe
como entrada o período de realização do teste e entrega os valores de mínimo,
59
máximo, média e desvio padrão de todas as tags utilizadas nos balanços. A Figura 28
mostra esta planilha.
Figura 28: Planilha para recuperação de dados de testes
A utilização desta planilha tornou-se bastante importante, uma vez que o
sistema Process Portal não está disponibilizando em seus relatórios de testes o
cálculo correto do desvio padrão (este é calculado utilizando apenas os valores de
mínimo, máximo e média de cada tag), essencial para análise do comportamento
das tags durante a realização de testes.
Além disso, a utilização do sistema PI configurado para a coleta de dados
sem a utilização de políticas de exceção e compressão possibilitou a comparação,
análise e avaliação dos dados provenientes do Process Portal após sua reinstalação
e reconfiguração. Assim, verificou-se que o sistema Process Portal passou a
fornecer dados, em sua grande maioria, coerentes com os aquisitados pelo sistema
PI. Desta forma, como ambos os sistemas coletam dados diretamente da rede INFINET, porém, através de cartões de comunicação diferentes, a concordância da
informação entre os dois sistemas possibilitou maior confiança nos dados a serem
60
inseridos nos balanços. A
não concordância em alguns casos possibilitou a
identificação de configurações inadequadas de tags no SDCD e até mesmo
problemas de configurações dos instrumentos em campo, observando-se casos em
que instrumentos trabalhavam com valores acima do range de medição calibrado,
gerando sinais de “bad quality” para o SDCD.
Adicionalmente, buscando-se identificar o momento exato de entrada em
operação de PSVs (Pressure Security Valves), foram desabilitados os parâmetros
de exceção e compressão para tags de PTs (Pressure Transmiters) localizadas a
montante de PSVs. Isto foi necessário devido ao fato de em algumas ocasiões
ocorrerem o acionamento de PSVs e depois, observado-se os dados históricos do
Process Portal e do próprio sistema PI, não ser possível identificar o ponto de pico
de pressão, possivelmente mascarado pelas configurações de exceção e
compressão.
61
Capítulo 6: Conclusões e Perspectivas
O sistema PI é largamente utilizado por todo o sistema PETROBRAS e por
diversas indústrias de processo de todo o mundo. Sua larga aplicação explica-se por
este fornecer on-line o estado de todas as variáveis monitoradas de um processo,
além de possibilitar a exibição de telas tais como elas são apresentadas nos
terminais de controle e operação das unidades.
Em muitas plantas industriais, como por exemplo o Módulo Industrial de
Processamento de Xisto (U-230), o sistema PI corresponde à única ferramenta de
armazenamento e visualização de dados históricos. Na U-144 seu correto
funcionamento possibilitou a análise, comparação e validação dos resultados
fornecidos pela ferramenta usual de recuperação de dados históricos (Process
Portal).
No início do trabalho, o sistema PI da U-144 encontrava-se numa situação de
pouca ou nenhuma utilização. Sua interface de coleta de dados apesar de estar
corretamente
instalada,
sofria
problemas
de
hardware,
impossibilitando
o
fornecimento contínuo de dados ao servidor PI. A detecção e identificação destes
problemas foi o primeiro passo para que se passasse a acreditar que o sistema PI
pudesse ser utilizado como fonte estável e confiável de dados.
A reinstalação do sistema em um novo servidor trouxe diversas vantagens,
possibilitando que fossem feitas configurações customizadas e que atendessem às
necessidades de exatidão exigidas pela U-144.
Desta forma, obteve-se como resultado final um sistema robusto que passou
a ser utilizado como fonte alternativa de dados para os balanços de massa e
energia, permitindo validar dados fornecidos pelo sistema Process Portal. Além
disso, a utilização do sistema PI permitirá backup permanente da base dados em
contraponto a situação anterior, onde se tinha dados disponíveis por apenas 30 dias
no Process Portal.
Além de o sistema PI possibilitar acesso a dados e telas de processo antes
apenas disponíveis nas salas de controle, tem-se agora acesso total ao processo
62
através da rede corporativa. Assim, pesquisadores do CENPES, por exemplo,
associados às unidades de pesquisa da SIX,
podem acompanhar on-line a
operação das unidades. Houve ainda a especificação e compra do software PIActiveView, tendo-se como desenvolvimento futuro a disponibilização das telas de
processo da U-144 na Internet, permitindo, por exemplo, ao engenheiro responsável
tomar decisões importantes mesmo quando não presente através do monitoramento
remoto.
Na continuação deste trabalho, tem-se como perspectivas de outros
desenvolvimentos futuros:
•
Criação e utilização de ferramentas para inserção automática de
valores obtidos em laboratório no sistema PI;
•
Desenvolvimento de ferramentas para acesso aos dados do servidor PI
utilizando interface ODBC via SQL Server e programação de
aplicações em PHP e Visual Basic, de forma que se tenha inserção
automatizada dos dados nos programas de balanço, atualmente
realizada de forma manual;
•
Utilização do software PI-BatchView para o desenvolvimento de
aplicações batelada, de forma que se tenha configuração automática
das tags de interesse (sem exceção e compressão) durante a
realização de testes;
•
Criação de mecanismos para sincronização (time stamp) dos sistemas
PI e Process Portal para que se tenha melhor precisão na comparação
dos dados oriundos de ambos os sistemas.
63
Bibliografia:
[ 1 ] K. G. Samia, “Implementação, Configuração e Customização do Sistema PI na
Unidade Multipropósito de FCC”, Projeto de Fim de Curso, DAS, UFSC,
Março de 2004.
[ 2 ] PI Server Reference Guide – Version 3.4. OSI Software, Inc., San Leandro, CA,
December 2003.
[ 3 ] System Management Tools 3.x User’s Guide – Version 3.0.0.2. OSI Software,
Inc., San Leandro, CA, December 2003.
[ 4 ] PI Data Link User’s Guide – Version 1.9. OSI Software, Inc., San Leandro, CA,
November 2000.
[ 5 ] PI Process Book User’s Guide – Version 2.3. OSI Software, Inc., San Leandro,
CA, July 2002.
[ 6 ] Bailey Infi90 Inteface to the PI System - NT and UNIX version 1.6 to 1.8. OSI
Software, Inc., San Leandro, CA, 2002.
[ 7 ] Bailey semAPI Interface to the PI System – Version 1.3.6 NT, Version 1.2 VMS.
OSI Software, Inc., San Leandro, CA, 1997.
[ 8 ] ControlIT Product Guide semAPI (Version 2.2). WBPEEUP350003A2. ABB,
December 2002.
[ 9 ] OperateIT Process Portal Version B1.2 Configuration. WBPEEUI220790C2.
ABB, April 2003.
[ 10 ] OperateIT Process Portal Version B1.2 Operation Harmony Connect.
WBPEEUI2200788D2. ABB, April 2003.
[ 11 ] OperateIT Process Portal Version B1.2 Introduction and Instalattion
WBPEEUI220793C2. ABB, April 2003.
[ 12 ] http://www.petrobras.com.br
[ 13 ] http://www.abb.com
[ 14 ] http://www.osisoft.com
64
Anexo A: Arquitetura SDCD Bailey INFI 90
65