Pré-detalhamento das arquiteturas de automação de unidades...
96
UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE ENGENHARIA DE CONTROLE E AUTOMAÇÃO INDUSTRIAL Pré-detalhamento das arquiteturas de automação de unidades de processo de um complexo petroquímico Monografia submetida à Universidade Federal de Santa Catarina como requisito para a aprovação da disciplina: DAS 5511 Projeto de Fim de Curso Cleiton Moya de Almeida Florianópolis, Setembro de 2009
Transcript of Pré-detalhamento das arquiteturas de automação de unidades...
UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE ENGENHARIA DE CONTROLE E AUTOMAÇÃO INDUSTRIAL
Pré-detalhamento das arquiteturas de automação de unidades de processo
de um complexo petroquímico
Monografia submetida à Universidade Federal de Santa Catarina como requisito para a aprovação da disciplina:
DAS 5511 Projeto de Fim de Curso
Cleiton Moya de Almeida
Florianópolis, Setembro de 2009
Pré-detalhamento das arquiteturas deautomação de unidades de processo
de um complexo petroquímico
Monografia submetida à Universidade Federal de Santa Catarina
como requisito para a aprovação na disciplina:
DAS 5511: Projeto de Fim de Curso
Cleiton Moya de Almeida
Florianópolis, setembro de 2009
Pré-detalhamento das arquiteturas de automação deunidades de processo de um complexo petroquímico
Cleiton Moya de Almeida
Esta monografia foi julgada no contexto da disciplinaDAS 5511: Projeto de Fim de Curso
e aprovada na sua forma final peloCurso de Engenharia de Controle e Automação
Banca Examinadora:
Thiago de Freitas Santos, Eng.Orientador da empresa
Agustinho Plucenio, Msc.Orientador do curso
Prof. Augusto Humberto BruciapagliaResponsável pela disciplina
Avaliador
Aluno 1, Debatedor
Aluno 2, Debatedor
Agradecimentos
Agradeço em primeiro lugar à minha família o apoio incondicional recebido du-
rante estes cinco anos de graduação.
Agradeço à Universidade Federal de Santa Catarina a execelente formação re-
cebida. Em especial, agradeço aos professores do Departamento de Automação e
Sistemas os ensinamentos não só de controle e automação, mas de vida.
Aos professores do PRH-34 agradeço a formação nos dois anos de trabalho
no grupo. Ao Prof. Agustinho, orientador deste trabalho e de outros nestes dois anos
como bolsista da ANP, agradeço os ensinamentos, o apoio, os conselhos e a amizade.
Agradeço à Chemtech a oportunidade de realizar meu projeto de fim de curso
numa excelente empresa e em um projeto de relevante importância à nação. Aos
colegas "chemtecheanos"da equipe de instrumentação do complexo, agradeço os en-
sinamentos, a amizade e a descontração no dia-a-dia de trabalho. Ao Eng. Thiago
de Freitas Santos, agradeço a amizade e a excelente orientação recebida durante o
trabalho.
Não poderia deixar de agrader aos amigos da turma 042 e “agregados” a parce-
ria nestes 5 anos graduação em estudos, tabalhos, congressos, viagens, churrascos
e festas.
Por fim, agradeço à Agência Nacional do Petróleo, Gás Natural e Biocobustí-
veis e à Fianciadora de Estudos FINEP o auxílio recebido na forma do Programa de
Recursos Humanos PRH-34.
O último grau da sofisticação é a simplicidade.
Leonardo da Vinci
Resumo
Neste trabalho são desenvolvidas arquiteturas de automação das unidades deprocesso de um complexo petroquímico, no contexto de um projeto de pré-detalhamento(FEED). Entende-se como “arquitetura de automação” a especificação dos equipa-mentos e sistemas de automação necessários para a execução das tarefas de controlee gerenciamento do complexo, bem como a integração entre estes sistemas.
Inicialmente faz-se um estudo dos principais sistemas de automação e requisi-tos especificados no projeto conceitual e básico. Desenvolve-se então uma arquiteturaconceitual para uma unidade de processo genérica. A partir desta arquitetura conecei-tual e dos requisitos, desenvolvem-se as arquiteturas de automação dos equipamen-tos e sistemas gerais e das unidades específicas. Como resultado, apresentam-se ediscutem-se os documentos elaborados e as melhorias que o trabalho proporcionouao projeto de FEED do complexo.
Abstract
This work presents the design of automation architectures for process units ofa petrochemichal complex. The work was developed in a Front End Engineering De-sign (FEED). The term automation architecture refers to equipments and automationssystems for control and management of the petrochemical complex, as well as thecommunications among these systems.
Firstly a study of automation systems is presented and the design requerimentsfor the petrochemical complex are analyzed. Them a conceptual architecture is develo-ped and used to design the predetailed automation architectures of the process units.Finally the generated documents in this work are discussed and improvements in theFEED design of the petrochemical complex are showed.
Sumário
Glossário
Lista de Figuras
1 Introdução 14
1.1 Objetivos do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Justificativa e contextualização . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 A Chemtech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4 Projeto FEED do complexo . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.1 Fases de um projeto industrial . . . . . . . . . . . . . . . . . . . 18
1.4.2 Projeto FEED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.6 Cronograma de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.7 Organização do documento . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.8 Considerações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2 Automação de procesos 24
2.1 Hierarquia de automação . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Sistemas de automação . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1 Sistema digital de controle distribuído . . . . . . . . . . . . . . . 26
2.2.2 Sistema instrumentado de segurança . . . . . . . . . . . . . . . 27
2.2.3 Gerenciamento de ativos . . . . . . . . . . . . . . . . . . . . . . 28
2.2.4 Sequenciamento de eventos . . . . . . . . . . . . . . . . . . . . 30
2.2.4.1 Arquiteturas . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3 Automação de grandes máquinas . . . . . . . . . . . . . . . . . . . . . 32
2.3.1 Sistema de óleo de lubrificação e de comando . . . . . . . . . . 33
2.3.2 Sistema de monitoramento . . . . . . . . . . . . . . . . . . . . . 33
2.3.3 Sistema de controle . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.4 Sistema de intertravamento . . . . . . . . . . . . . . . . . . . . . 34
2.4 Redes industriais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.1 Classificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.1.1 Redes de sensores . . . . . . . . . . . . . . . . . . . . 35
2.4.1.2 Redes de campo . . . . . . . . . . . . . . . . . . . . . . 36
2.4.1.3 Redes de controle . . . . . . . . . . . . . . . . . . . . . 37
2.4.2 Modelo OSI/ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4.3 Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.3.1 HART . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.3.2 Foundation Fieldbus . . . . . . . . . . . . . . . . . . . . 39
2.4.3.3 Profibus . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.3.4 Ethernet/TCP-IP . . . . . . . . . . . . . . . . . . . . . . 42
2.4.3.5 Modbus . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4.3.6 OPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3 Desenvolvimento 45
3.1 Arquitetura geral do complexo . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 Levantamento de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3 Arquitetura conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4 Pré-Detalhamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.1 Sistema digital de controle distribuído . . . . . . . . . . . . . . . 51
3.4.1.1 Comunicação com servidores no CIC . . . . . . . . . . 53
3.4.1.2 Comunicação com o PES e CLPs de pacotes . . . . . 53
3.4.1.3 Comunicação com o CCM-CDC . . . . . . . . . . . . . 53
3.4.2 Sistema instrumentado de segurança . . . . . . . . . . . . . . . 53
3.4.2.1 Comunicação com servidores no CIC . . . . . . . . . . 54
3.4.2.2 Comunicação com o SDCD . . . . . . . . . . . . . . . . 54
3.4.2.3 Comunicação com pacotes . . . . . . . . . . . . . . . . 54
3.4.2.4 Comunicação com o CCM-CDC . . . . . . . . . . . . . 56
3.4.2.5 Comunicação com o AMS . . . . . . . . . . . . . . . . 56
3.4.2.6 Comunicação com o sistema SOE . . . . . . . . . . . . 56
3.4.3 Sistema de fogo e gás . . . . . . . . . . . . . . . . . . . . . . . . 56
3.4.3.1 Sistema de fogo e gás do processo . . . . . . . . . . . 57
3.4.3.2 Sistema de fogo e gás da CCL . . . . . . . . . . . . . . 59
3.4.4 Sistema de gerenciamento de ativos . . . . . . . . . . . . . . . . 60
3.4.5 Sistema de sequenciamento de eventos . . . . . . . . . . . . . . 62
3.4.6 Rede de manutenção . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.7 Analisadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.7.1 Analisadores de processo . . . . . . . . . . . . . . . . 64
3.4.7.2 Sistema de monitoramento de emissões . . . . . . . . 67
3.4.8 Fornos a chama . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.4.8.1 Comunicação com outros sistemas . . . . . . . . . . . 69
3.4.9 Máquinas de grande porte . . . . . . . . . . . . . . . . . . . . . 69
3.4.9.1 Arquitetura genérica . . . . . . . . . . . . . . . . . . . . 69
3.4.10 Automação e proteção do sistema elétrico . . . . . . . . . . . . . 73
3.4.10.1 Acionamento de motores . . . . . . . . . . . . . . . . . 75
3.5 Arquitetura geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.5.1 Comunicações não protocoladas . . . . . . . . . . . . . . . . . . 78
3.5.2 Comunicações em rede . . . . . . . . . . . . . . . . . . . . . . . 78
3.6 Arquiteturas especificas . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.6.1 Turboexpansor acionando um gerador elétrico . . . . . . . . . . 82
3.6.1.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.6.1.2 Instrumentação e controle . . . . . . . . . . . . . . . . 82
3.6.1.3 Arquitetura de automação . . . . . . . . . . . . . . . . 84
4 Resultados 87
4.1 Documentos de arquiteturas . . . . . . . . . . . . . . . . . . . . . . . . 87
4.1.1 Metodologia de elaboração . . . . . . . . . . . . . . . . . . . . . 89
4.2 Melhorias no projeto FEED . . . . . . . . . . . . . . . . . . . . . . . . . 90
5 Conclusões e perspectivas 91
5.1 Perspectivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Referências 93
Glossário
AMDAS Analyzer Maintenance and Data Acquisition SystemAMS Asset Management SystemANSI American National Standards InstituteAPC Advanced Process ControlASM Analyzer System ManagerCAD Computer Aided DesignCCL casa de controle localCCM centro de controle de motoresCDC centro de distribuição de cargasCEMS Continuous Emission Monitoring SystemCLP controlador de lógica programávelCIC centro integrado de controleEIA Electronic Industries AllianceEPC Engineering, Procurement and ConstructionE/S entrada/saídaERP Enterprise Resource PlanningESD Emergency Shutdown SystemFCC Fluidic Catalytic CrackingFEED Front End Engineering DesignFF Foundation FieldbusF&G Sistema de fogo e gásF&GBA Fire and Gas Building AutomationFMS Factory Message SpecificationHVAC Heating, Ventilation and Air CoditioningIED Inteligent Electronic DeviceIEEE Institute of Electrical and Electronics EngineersIHM interface homem-máquinaISA The Instrumentation, Systems, and Automation SocietyISO International Organization for StandardsMES Manufacturing Execution SystemLAN Local Area NetworkLCP Local Control PanelLIMS Laboratory Information Management SystemLP Local PanelOPC-DA Data Access OPC SpecificationOPC-A&E Alarms & Events OPC SpecificationOPC-UA Unified Architecture OPC SpecificationOSI Open Systems InterconnectionPASE proteção e automação do sistema elétricoPES Programmable Electronic SystemP&ID Process and Instrumentation DiagramPIMS Plant Information Management SystemRCP Remote Control Panel
RMN rede de manutençãoRTO Real Time OptimizationRTPM Real Time Performance ManagementSDCD sistema digital de controle distribuídoSIF Safety Instrumented FunctionSIL Safety Integrity LevelSIS sistema instrumentado de segurançaSOE Sequence of EventsVSD Variable Speed Driver
Lista de Figuras
1.1 Áreas de atuação da Chemtech . . . . . . . . . . . . . . . . . . . . . . . 18
1.2 Cronograma de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1 Hierarquia de automação de uma refinaria . . . . . . . . . . . . . . . . . 25
2.2 Arquitetura conceitual de um SIS . . . . . . . . . . . . . . . . . . . . . . 28
2.3 Sistema SOE externo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 Sistema SOE integrado ao SDCD . . . . . . . . . . . . . . . . . . . . . 31
2.5 Conexão tradicional de sensores . . . . . . . . . . . . . . . . . . . . . . 36
2.6 Rede de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.7 Modelo de referência OSI/ISO . . . . . . . . . . . . . . . . . . . . . . . 37
2.8 Topologia da rede FF H1 . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.9 Estrutura do protocolo Modbus . . . . . . . . . . . . . . . . . . . . . . . 43
3.1 Arquitetura do complexo petroquímico . . . . . . . . . . . . . . . . . . . 46
3.2 Arquitetura conceitual de uma unidade de processo . . . . . . . . . . . 49
3.3 Simbologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4 Arquitetura do SDCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.5 Arquitetura do SIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.6 Arquitetura do sistema de F&G . . . . . . . . . . . . . . . . . . . . . . . 58
3.7 Arquitetura do sistema de F&GBA . . . . . . . . . . . . . . . . . . . . . 59
3.8 Arquitetura do AMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.9 Arquitetura do sistema SOE . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.10 Arquitetura da rede RMN . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.11 Analisadores - arquitetura 1 . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.12 Analisadores - arquitetura 2 . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.13 Analisadores - arquitetura 3 . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.14 Arquitetura do CEMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.15 Arquitetura de um forno a chama . . . . . . . . . . . . . . . . . . . . . . 70
3.16 Arquitetura de uma máquina rotativa genérica . . . . . . . . . . . . . . . 72
3.17 Arquitetura do PASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.18 Arquitetura de uma unidade genérica . . . . . . . . . . . . . . . . . . . 77
3.19 Comunicações não-protocoladas . . . . . . . . . . . . . . . . . . . . . . 79
3.20 Comunicações em rede . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.21 Turboexpansor em uma unidade de FCC . . . . . . . . . . . . . . . . . 82
3.22 Diagrama P&ID simplificado do turboexpansor . . . . . . . . . . . . . . 83
3.23 Arquitetura dos turboexpansores . . . . . . . . . . . . . . . . . . . . . . 85
4.1 Documento de arquitetura de automação . . . . . . . . . . . . . . . . . 88
Capítulo 1: Introdução
O início da produção de petróleo na jazida Tupi, no pólo do pré-sal, no dia 1o de
maio de 2009, representou um marco na história do Brasil e da indústria petrolífera do
mundo. Com a capacidade de produção do pré-sal, o país entra para o seleto grupo
dos países com grandes reservas petróleo e com capacidade de exportação desta
fonte de energia.
Entretanto, se por um lado o Brasil já é auto-suficiente na produção de petróleo
desde 2006 (ou seja, produz-se mais óleo do que a quantidade total importada), o
mesmo não se pode dizer em relação à produção de derivados de petróleo com maior
valor agregado, tais como gasolina, propeno e eteno. Isso se deve ao fato que a
capacidade de refino atualmente instalada no país não é capaz de atender a demanda
interna. A última refinaria construída no Brasil foi a Revap (Refinaria Henrique Lage),
inaugurada em 1980.
Após um período de mais de 20 anos sem grandes investimentos no setor pe-
troquímico, o governo brasileiro anunciou em 2008 a construção (por parte da Pe-
trobras) de 4 novas refinarias no país. Estas novas unidades processarão petróleo
pesado da Bacia de Campos e do Pré-Sal, garantindo não só a auto-suficiência em
derivados como também a exportação destes produtos.
Dentre todas as atividades industriais, o refino de petróleo está entre as que
possuem maior grau de automação. A evolução das técnicas de controle de pro-
cessos, acompanhada do desenvolvimento da tecnologia da informação, permite que
atualmente todo o processo de produção de uma refinaria seja executado de maneira
automática, através de sistemas de controle digitais e de sistemas de informação para
o gerenciamento da produção. Aos operadores, cabe a supervisão do processo e a
manutenção do sistema.
Diante deste cenário, o projeto dos sistemas de automação de uma refinaria
constitui-se em uma complexa atividade que exige trabalhos em diferentes níveis, ba-
seados em diretrizes, normas, padrões industriais e tecnologias disponíveis. Além
disso, devido ao grande período sem investimentos em novas refinarias e em siste-
mas de automação modernos para as já existentes, o Brasil possui atualmente uma
escassez de tecnologias e engenheiros treinados para estas tarefas.
14
1.1: Objetivos do trabalho
Este trabalho tem por objetivo elaborar o projeto pré-detalhado das arquiteturas
de automação de 27 unidades de processo de um complexo petroquímico as quais a
empresa Chemtech ficou responsável pelo projeto de pré-detalhamento (FEED - Front
End Engineering Design).
Entende-se como “arquitetura de automação” a especificação dos equipamen-
tos e sistemas de automação necessários para a execução das tarefas de controle
e gerenciamento do complexo, bem como a integração destes sistemas. O termo
“pré-detalhamento”, por sua vez, refere-se à etapa de FEED do projeto do complexo,
no qual está contextualizado o trabalho. Por último, entende-se como “unidades de
processo” as unidades principais do complexo, responsáveis pelo refino do petróleo.
Além destas unidades principais, um complexo petroquímico também possui unidades
de utilidades e facilidades, tais como de transporte de materiais e geração de energia
elétrica. O resultado final esperado para o trabalho é a elaboração de documentos de
arquiteturas de automação para as unidades de processo do complexo petroquímico.
Definiu-se em reunião com o cliente que o objetivo de um documento de ar-
quitetura de automação é pré-detalhar os principais equipamentos, instrumentos e
sistemas de automação presentes na unidade e localizados no campo ou na casa
de controle local (CCL), bem como a interface destes com o centro de controle inte-
grado (CIC). O detalhamento da arquitetura do CIC, por sua vez, será feito na etapa
de projeto detalhado, e não nesta etapa de pré-detalhamento.
Durante a etapa de FEED, os documentos de arquitetura serão utilizados como
referência para a elaboração de listas de entradas e saídas (E/S) do SDCD (sistema
digital de controle distribuído) e do PES (Programmable Electronic System) e listas
de portas de comunicação. Além disso, os documentos serão utilizados na fase de
detalhamento para apresentar uma visão geral de automação das unidades.
Em relação às etapas do projeto FEED do complexo, o documento de arquite-
tura de automação faz parte da etapa de complementação do projeto básico (explicado
na seção 1.4).
15
1.2: Justificativa e contextualização
O projeto do complexo petroquímico permitirá ao Brasil reduzir importações de
petroquímicos como nafta e gerar produtos de segunda geração para o mercado in-
terno e externo. Além disso, o projeto de um complexo petroquímico fomenta a enge-
nharia nacional e permite a geração de milhares de emprego direta e indiretamente.
O trabalho está diretamente relacionado ao curso de graduação em Engenharia
de Controle e Automação da UFSC. A disciplina de Processos em Engenharia (DAS-
5151) forneceu a base para o entendimento dos principais processos e equipamentos
presentes em uma refinaria. A disciplina de Instrumentação em Controle (DAS-5151)
forneceu princípios de instrumentação industrial. A disciplina de Informática Industrial
I (DAS-5305) permitiu o entendimento de sistemas de automação como CLPs, senso-
res e atuadores inteligentes. A disciplina de Redes de Computadores para Automação
Industrial (DAS-5314) permitiu uma visão dos princípios utilizados em comunicação de
sistemas controle e automação, bem como das principais tecnologias de rede dispo-
níveis.
O projeto também se insere no contexto do Programa de Recursos Humanos
PRH-34/ANP/MCT, que tem como objetivo a formação de engenheiros para atuar na
área de automação, controle e instrumentação para o setor de petróleo e gás natural.
As disciplinas de especialização cursadas durante o programa contribuíram direta-
mente para a realização deste trabalho, sobretudo a disciplina de Automação Aplicada
à Indústria do P&G (DAS-5921), que permitiu, dentre outras coisas, a familiarização
com tecnologias como Foundation Fieldbus. Também deve-se destacar que o trabalho
desenvolvido durante o estágio no programa (Projeto de uma Unidade para Pesquisa
de Medição e Controle de Escoamento Multifásico [1]) e como estágio do curso de
Automação (DAS-5501) permitiu o estudo de tópicos de instrumentação e automação
aplicados ao projeto de uma unidade de processo.
1.3: A Chemtech
Fundada em 1989 por três engenheiros químicos recém formados pelo Instituto
Militar de Engenharia (IME), no Rio de Janeiro, a Chemtech (das iniciais de Chemical
Engineering e Information Technology ) é uma empresa de consultoria e prestação de
serviços em engenharia básica, tecnologia da informação, controle e automação. A
figura 1.1 mostra um esquemático com as áreas de atuação da Chemtech.16
Os primeiros projetos da Chemtech visavam o desenvolvimento de engenharia
básica e simulação para a indústria de processos. O PETROX - simulador de processo
desenvolvido para a Petrobras e ainda hoje utilizado por esta empresa - é um exemplo
de projeto pioneiro que teve grande sucesso e abriu caminho para a Chemtech ampliar
seus clientes e área de atuação.
Em 1999, a Chemtech adquiriu a empresa EGS (Engineering Sciences) e pas-
sou a contar com maior experiência nas áreas de MES e PIMS. Isso possibilitou o
desenvolvimento de novos projetos como o MES da Companhia Siderúrgica Nacional
(CSN).
Em março de 2001, a empresa foi escolhida pela Siemens para ser a respon-
sável pela área de tecnologia da informação para plantas de processo nos países do
Mercosul e no México, e passou a fazer parte da divisão I&P (Industry and Plants)
do grupo I&S (Industrial Solutions and Services). Em 2008, com a reestruturação do
grupo Siemens, a empresa passou para a divisão Oil & Gas do setor Energy.
Atualmente, a Chemtech possui cerca de 1200 funcionários e escritórios no Rio
de Janeiro, São Paulo, Salvador, Belo Horizonte, Manaus, Porto Alegre, Vitória e em
Houston, nos Estados Unidos da América. A empresa é líder brasileira no forneci-
mento de soluções de otimização para as indústrias de processos e atua em diversos
países, como Alemanha, Estados Unidos, Rússia, Japão, Cingapura, Tailândia, Arábia
Saudita, França, África do Sul, Canadá e Espanha. Entre os principais clientes da
Chemtech, destacam-se Petrobras, Vale, CSN, Braskem, ExxonMobil, Saudi Aramco
e Shell, entre outras.
Em 2009, a Chemtech foi eleita empresa mais inovadora do Brasil pela Fun-
dação Getúlio Vargas e pelo Great Places to Work Institut (GPWI). Foi eleita ainda
a segunda melhor empresa para se trabalhar no Brasil em uma pesquisa feita pelo
GPWI e pela revista Época, tendo conquistado o primeiro lugar nos dois anos anterio-
res. Desde 2004, figura na lista das melhores empresas, de acordo com pesquisas de
clima organizacional.
1.4: Projeto FEED do complexo
Este trabalho está inserido no contexto do projeto de pré-detalhamento (FEED)
de um complexo petroquímico. Nas seções abaixo serão introduzidas as principais
fases de um empreendimento industrial, o conceito e os objetivos de um projeto FEED.
17
Figura 1.1: Áreas de atuação da Chemtech
Para uma discussão geral sobre projetos de empreendimento industrial e uma
discussão aprofundada sobre anteprojeto, sugere-se o trabalho de Casarotto [7]. Uma
metodologia específica para projetos de automação de processos é discutida no livro
[13]. Lucci, Concer e Santana [9] apresentam uma visão geral e a importância da
etapa de FEED do ponto de vista do projeto de instrumentação.
1.4.1: Fases de um projeto industrial
O projeto de um empreendimento industrial é geralmente dividido em 3 etapas
principais:
1. Projeto conceitual;
2. Projeto básico;
3. Projeto detalhado.
O projeto conceitual visa definir os objetivos do projeto e as possibilidades de
soluções para atingir estes objetivos. Como exemplo, pode-se definir que o objetivo
de uma planta é produzir uma certa quantidade de propeno por dia. Para atingir este
objetivo, podem existir diversas tecnologias disponíveis. No projeto conceitual, estas
alternativas são levantadas e analisadas. No final desta fase, tem-se uma estimativa
inicial de custos do projeto.
O projeto básico visa selecionar uma alternativa dentre as várias propostas no
projeto conceitual e então realizar um projeto inicial considerando esta tecnologia.
Nesta fase, são definidos as características principais dos processos, equipamentos,18
sistemas e construções, sem no entanto detalhar estas caracetrísticas. No final do
projeto básico, obtém-se uma estimativa de custos mais precisa que a realizada no
projeto conceitual.
Por último, o projeto de detalhamento visa especificar todas as características
do projeto, possibilitando a construção, compra de materiais, equipamentos e a mon-
tagem. Como exemplo, uma vez especificadas as características dos equipamentos,
um determinado fornecedor é selecionado.
Em alguns projetos, a etapa de detalhamento é feita pela mesma empresa res-
ponsável pela construção da unidade. Neste caso, a etapa é denominada EPC (Engi-
neering, Procurement and Construction). Este é o caso do projeto deste trabalho.
1.4.2: Projeto FEED
O projeto de pré-detalhamento (FEED - Front End Engineering Design) é uma
etapa intermediária e híbrida entre o projeto básico e o detalhado que tem como obje-
tivo principal antecipar algumas etapas de forma a possibilitar uma melhor estimativa
de custos do projeto. Além disso, o FEED antecipa o projeto e compra de equipa-
mentos críticos ao processo que, devido ao seu tamanho e complexidade, poderiam
atrasar o início de operação de uma unidade. Por exemplo, o processo de compra de
um compressor de grande porte específico para uma unidade de processo (incluindo
licitação, especificação, construção e transporte) pode demorar até 3 anos. O projeto
de detalhamento de uma refinaria, por sua vez, pode ser realizado num período de 2
ou 3 anos também. Por isso, se o compressor for especificado e comprado somente
na etapa do projeto detalhado, corre-se o risco de atrasar o início de operação do
empreendimento.
O projeto FEED pode ser divido em três etapas:
1. Análise de consistência do projeto básico;
2. Complementação do projeto básico;
3. Projeto FEED.
Na etapa análise de consistência, as informações dos documentos do projeto
básico são verificadas se estão coerentes com os critérios técnicos do projeto e con-
sistentes entre si. Como exemplo, confrontam-se informações de folhas de dados de19
instrumentos e equipamentos com diagramas de processo e instrumentação (P&ID -
Process and Instrumentation Diagram).
A etapa de complementação do projeto básico consiste em detalhar algumas
informações a fim de permitir a execução da etapa de FEED. O nível de detalhamento
não deve ser tal qual no projeto detalhado, mas deve ser suficiente para que os quan-
titativos possam ser estimados com a precisão requerida. Além disso, a complemen-
tação do projeto básico possui a finalidade de auxiliar a etapa de detalhamento. Como
exemplos de documentos de instrumentação gerados nesta etapa, têm-se diagramas
P&IDs, matrizes de causa e efeito e memoriais descritivos.
Por último, a etapa de FEED propriamente dita consiste em levantar o quantita-
tivo de materiais, equipamentos, cabos, instrumentos, etc., possibilitando assim uma
melhor estimativa de custos do projeto. Como exemplo de documentos gerados nesta
etapa em um projeto de instrumentação e automação têm-se: plantas de locação de
instrumentos, listas de instrumentos, listas de E/S de CLPs, listas de portas de comu-
nicação, listas de cabos, etc.
1.5: Metodologia
Para a elaboração das arquiteturas de automação das unidades, foram definidas
7 etapas:
1. Estudo da arquitetura de automação geral do complexo;
2. Estudo de sistemas de automação de processos;
3. Esboço de uma arquitetura conceitual;
4. Levantamento e análise de requisitos;
5. Pré-detalhamento das arquiteturas de sistemas e equipamentos;
6. Elaboração da arquitetura de uma unidade genérica;
7. Elaboração das arquiteturas específicas de cada unidade.
Na primeira etapa, realizou-se um estudo sobre a arquitetura de automação
geral do complexo petroquímico, definida durante o projeto básico. O estudo abran-
geu o levantamento de documentos de critérios de projeto, memoriais descritivos e20
desenhos. Através dele foram definidos os principais sistemas e equipamentos de
automação presentes numa unidade de processo.
Em paralelo à etapa 1, realizou-se também um estudo sobre os sistemas sob
a óptica de suas arquiteturas. O estudo foi baseado em artigos, livros, catálogos e
também em cursos e palestras realizadas durante o período do trabalho. Dentre os
cursos, destacam-se os de interpretação de fluxogramas de engenharia e o curso de
AutoCAD básico. Dentre as palestas, destacam-se temas como sistemas digitais de
controle distribuído e sistemas integrados de fogo e gás.
Uma vez levantados os principais equipamentos e sistemas de automação do
complexo petroquímico, elaborou-se na etapa 3 uma arquitetura conceitual para uma
unidade de processo genérica. Esta arquitetura serviu como base para a definição
das arquitetura pré-detalhadas.
Após a definição da arquitetura conceitual, a etapa 4 consistiu no levantamento
de requisitos dos sistemas obtidos a partir da documentação estudada na etapa 1.
Estes requisitos, juntamente com a arquitetura conceitual e com o estudo dos siste-
mas, permitiram a realização do pré-detalhamento das arquiteturas de automação das
unidades.
Completado o pré-detalhamento dos sistemas, elaborou-se na etapa 5 uma ar-
quitetura de automação para uma unidade de processo genérica. Esta arquitetura foi
utilizada como base para a elaboração das arquiteturas específicas.
A sétima e última etapa consiste na elaboração da arquitetura específica para
cada unidade. Como exemplo de arquitetura específica, apresenta-se pré-detalhamento
do sistema de automação de um turboexpansor.
1.6: Cronograma de atividades
O trabalho relacionado ao desenvolvimento das arquiteturas de automação foi
iniciado em abril de 2009 e está previsto para finalizar em outubro do mesmo ano. O
digrama de Gantt da figura 1.2 mostra o cronograma de atividades.
Um ponto importante de ser comentado é que o prazo estipulado para a emis-
são dos documentos de arquiteturas das primeiras unidades fez com que no início do
trabalho todas etapas fossem executadas em paralelo. Por isso, demorou-se um pe-
ríodo maior que o desejado para que o desenvolvimento de uma arquitetura genérica
21
Figura 1.2: Cronograma de atividades
chegasse ao nível desejado de maturidade.
1.7: Organização do documento
Esta monografia foi elaborada de forma a apresentar o trabalho seguindo as
etapas da metodologia proposta.
O capítulo 2 apresenta um estudo sobre os principais equipamentos e siste-
mas de automação presentes em um complexo petroquímico. Descreve-se os sis-
tema digital de controle distribuído - SDCD (seção 2.2.1), o sistema instrumentado
de segurança - SIS (seção 2.2.2), sistema de gerenciamento de ativos - AMS (seção
2.2.3) e sistema de sequenciamento de eventos - SOE (seção 2.2.4). Discutem-se
as principais tecnologias de rede utilizadas no complexo petroquímico (seção 2.4).
Apresenta-se ainda conceitos de automação de máquinas de grande porte (e.g. com-
pressores) (seção 2.3). Os conceitos apresentados neste capítulo fornecem a base
para a realização do pré-detalhamento.
No capítulo 3 desenvolve-se a etapa de pré-detalhamento propriamente dita.
Inicialmente, apresenta-se uma arquitetura geral do complexo petroquímico (seção
3.1). Em seguida, apresentam-se os principais requisitos e critérios para o projeto
de automação das unidades de processo (seção 3.2). Elabora-se então uma arqui-
tetura pré-detalhada para uma unidade genérica (3.5). Por último, como exemplo de
arquitetura específica elaborada, apresenta-se a arquitetura de automação de um tur-
boexpansor acionando um gerador (seção 3.6).
No capítulo 4 são apresentados e discutidos os resultados, em termos de docu-22
mentos gerados e melhorias proporcionadas ao projeto FEED do complexo.
Por fim, no capítulo 5 são apresentadas as conclusões e perspectivas do traba-
lho.
1.8: Considerações
Buscou-se utilizar ao longo deste trabalho termos e siglas em português para
os sistemas de automação, como por exemplo SDCD (sistema digital de controle dis-
tribuído) ao invés de DCS (Distributted Control System). Entretanto, verificou-se que
não existem na literatura siglas difundidas em português para alguns sistemas, como
por exemplo para o sistema de gerenciamento de ativos (AMS - Asset Management
System). Neste caso, preferiu-se manter a sigla em inglês.
23
Capítulo 2: Automação de procesos
Neste capítulo são apresentados os principais sistemas de automação utiliza-
dos no complexo petroquímico. Não pretende-se discutir a fundo todos os sistemas,
mas sim apresentar uma visão geral daqueles que são fundamentais em automação
de processos contínuos.
Inicialmente, apresenta-se na seção 2.1 um modelo de hierarquia de automação
em uma refinaria. Em seguida, apresentam-se na seção 2.2 os principais sistemas de
automação encontrados em uma unidade de processo de uma refinaria ou complexo
petroquímico. Discute-se também, na seção 2.3, conceitos de automação de máqui-
nas de grande porte. Por último, a fim de permitir a integração dos diferentes sistemas
pertencentes aos diferentes níveis da hierarquia de automação, apresenta-se na se-
ção 2.4 as redes de comunicação industriais.
2.1: Hierarquia de automação
Se por um lado os processos de manufatura beneficiam-se de modelos e ter-
minologias padrões, tal como o a norma ISA-95.00.01/2000 [8], não se encontra na
literatura um modelo padronizado semelhante para a área de automação de proces-
sos.
A fim de permitir uma visão geral da arquitetura e hierarquia de automação de
uma refinaria, elaborou-se uma arquitetura conceitual, mostrada na figura 2.1. Nesta
arquitetura, os sistemas foram dispostos em níveis segundo uma hierarquia de con-
trole e gerenciamento do processo.
No nível inferior encontram-se os instrumentos de campo, tais como válvulas,
transmissores, painéis, etc. Estes instrumentos são conectados a controladores atra-
vés de redes de campos (e.g. Foundation Fieldbus ou Profibus). Cada unidade da
refinaria pode possuir um ou mais controladores, e em geral módulos de um sistema
digital de controle distribuído (SDCD).
Num segundo nível, os controladores comunicam-se entre si através de uma
rede de controle. Esta rede é utilizada também para a interface com os sistemas de
automação.
24
Figura 2.1: Hierarquia de automação de uma refinaria
25
O terceiro nível é constituído por sistemas automação e informação tais como
sistema de controle avançado (APC - Advanced Process Control), sistema de oti-
mização do processo, (RTO - Real Time Optimizer ), MES (Manufacturing Execution
System), LIMS (Laboratory Information Management System), PIMS (Plant Informa-
tion Management System), sistema de sequenciamento de eventos (SOE - Sequence
of Events System) e sistema de gerenciamento de ativos (AMS - Asset Management
System).
Em um quarto nível encontram-se sistemas corporativos responsáveis pelo ge-
renciamento da produção, tais como o ERP (Enterprise Resource Planning) e o RTPM
(Real Time Performance Management).
Por último, em um quinto nível, encontram-se sistemas de informação como
páginas e portais web, acessíveis através de redes Intranet, Extranet ou ou através
da Internet.
2.2: Sistemas de automação
Nesta seção apresentam-se os principais sistemas de automação utilizados em
uma unidade de processo de uma refinaria: sistema digital de controle distribuído
(SDCD), sistema instrumentado de segurança (SIS), sistema de gerenciamento de
ativos (AMS) e sistema de sequenciamento de eventos (SOE). As principais caracte-
rísticas e arquiteturas gerais destes sistemas são discutidas de forma a possibilitar o
pré-detalhamento no capítulo 3.
2.2.1: Sistema digital de controle distribuído
O sistema digital de controle distribuído (SDCD) pode ser definido como uma
combinação de hardware (instrumentos de campo, painéis, servidores e estações de
operação), redes (topologia, protocolos e conversores) e aplicativos (para supervisão,
aquisição e controle).
As principais funções de um SDCD são a aquisição de dados, controle do pro-
cesso e supervisão. Além disso, sistemas modernos incluem as seguintes funcionali-
dades:
• Estratégias de controle avançado e otimização;
26
• Gerenciamento de alarmes;
• Gerenciamento de ativos;
• Sequenciamento de eventos;
Na figura 2.1 podem-se observar, numa arquitetura conceitual, módulos de
controle, estação de engenharia e alguns sistemas de automação presentes em um
SDCD.
Os instrumentos de campo são conectados ao SDCD através caixas de junções,
painéis de rearranjo e cartões de E/S. As caixas de junções, localizadas no campo,
reúnem uma porção de pares de cabos de instrumentos e os juntam em um único
multicabo. Na CCL, estes multicabos são levados até o painel de rearranjo onde cada
par é então conectado na respectiva porta do cartão. No caso de instrumentos em
rede, um único par de fio correspondente a cada seção da rede é ligado ao cartão do
SDCD, sem a necessidade de um painel de rearranjo.
Os sistemas computacionais são armazenados em gabinetes verticais que in-
cluem fontes de alimentação, painéis de distribuição e módulos. Os módulos de con-
trole são dispositivos microprocessados no qual possuem as funções de controle em-
barcadas.
As estações de engenharia são utilizadas para configuração, manutenção, ope-
ração e supervisão do processo. Localizam-se geralmente em salas de controle.
2.2.2: Sistema instrumentado de segurança
Sistemas instrumentados de segurança (SIS), ou sistemas de desligamentos de
emergência (ESD - Emergency Shutdown System) são uma classe de sistemas res-
ponsáveis pela segurança operacional de unidades e equipamentos industriais. Eles
causam a parada de emergência ou impedem a operação insegura sempre que as
condições de processo ultrapassam os limites preestabelecidos como seguros, ou que
se estabeleçam condições operacionais perigosas [2]. O objetivo final é evitar aciden-
tes, tais como incêndios, explosões e descarga de produtos perigosos ou poluentes à
atmosfera.
A norma IEC 61511 define o SIS como:
Implementação de uma ou mais funções de segurança (SIF – Safety Instrumented
27
Figura 2.2: Arquitetura conceitual de um SIS - Adaptado de [6]
Functions). Um SIS é composto por combinação de sensores, executores de lógica e
atuadores.
Um exemplo simples de SIF é: Se o nível no vaso A exceder um determinado
valor, então feche a válvula de controle. Um sistema instrumentado de segurança pode
consistir em diversas SIFs, e uma SIF pode consistir em um único ou múltiplos grupos
de sensores e atuadores. Além disso, um mesmo grupo de sensores e atuadores
podem fazer parte de mais de uma SIF [6].
A figura 2.2 mostra os componentes de um sistema SIS independente que provê
a função SIF descrita anteriormente. Nesta figura, é possível identificar os principais
elementos de um SIS: sensores, executor de lógica e atuadores. O executor de lógica
consiste em um CLP com certificação para um determinado nível de integridade de
segurança (SIL - Safety Integrity Level), e é comumente chamado de PES (Program-
mable Electronic System).
2.2.3: Gerenciamento de ativos
Os modernos sistemas de diagnóstico e manutenção, conhecidos como siste-
mas de gerenciamento de ativos (AMS – Assset Management System), trabalham co-
nectados à rede de instrumentos, monitorando continuamente suas condições e seus
auto-diagnósticos. Eles estão preparados para notificar o técnico sobre qualquer pos-
sibilidade de falha nos instrumentos da planta ou quando a manutenção programada
é necessária [10].
O sistema de gerenciamento de ativos permite a realização de diagnóstico re-
moto de instrumentos da planta através de uma interface de software. É possível, por
28
exemplo, identificar instrumentos com problemas sem a necessidade de retirá-los da
planta e levá-los a uma sala de manutenção. É possível ainda realizar ajustes no ins-
trumento diretamente a partir da interface remota, sem a necessidade de se deslocar
até o campo.
O AMS permite ainda o gerenciamento de manutenções preventivas e prediti-
vas. Na manutenção preventiva, os equipamentos são checados e testados segundo
um planejamento periódico, onde o intervalo de tempo entre as manutenções é defi-
nido pelo fabricante ou pela equipe de manutenção. Quando existe a necessidade da
manutenção preventiva, o sistema notifica o usuário na tela de alarmes de manuten-
ções pendentes e/ou através de notificações via email. Já na manutenção preditiva, o
sistema monitora continuamente parâmetros de instrumentos os quais permitem iden-
tificar até quando o dispositivo pode operar em um nível seguro, sem ocorrência de
falhas. Este tipo de manutenção permite a operação contínua do instrumento pelo
maior tempo possível antes dele sofrer manutenção ou substituição.
O acesso às informações do instrumento para análise e configuração pode ser
feito de diferentes formas.
Os modernos sistemas de SDCD em geral possuem aplicativos próprios para o
gerenciamento de ativos. Entretanto, pode acontecer destes sistemas não possuírem
todas as funcionalidades e características desejadas. Neste caso, uma solução é
utilizar um aplicativo de AMS externo ao SDCD e realizar o acesso/escrita de dados
nos instrumentos através do protocolo OPC (seção 2.4.3.6).
Os modernos CLPs (controladores de lógica progamável) possuem cartões de
entrada 4− 20 mA + HART capazes de filtrar as informação HART do sinal analógico
e disponibilizá-la numa porta de saída. Desta forma, é possível conectar as saídas do
CLP a um multiplexador HART e acessá-las a partir de uma estação de engenharia.
Caso o CLP não ofereça saída HART, pode-se utilizar um dispositivo externo (interme-
diário entre o instrumento e o CLP) para filtrar o sinal HART e multiplexá-lo.
O gerenciamento de ativos pode também ser feito através de um computador de
mão capaz de ler e escrever informações HART, que pode ser conectado diretamente
ao instrumento sem interromper seu funcionamento.
Em todos os casos, o gerenciamento de ativos só pode de ser feito com “ins-
trumentos inteligentes”, ou seja, instrumentos com poder de microprocessamento. As
informações são enviadas e recebidas através de um protocolo de comunicação digi-
tal, tal como HART, Foundation Fieldbus ou Profibus.29
2.2.4: Sequenciamento de eventos
Um dos principais problemas encontrados na indústria de processos é deter-
minar a causa inicial de um eventual desligamento de emergência automático do sis-
tema. Isso porque numa situação como esta diversos alarmes e intertravamentos são
gerados num período de tempo muito curto, de forma que a resolução de estampagem
de tempo do CLP ou controlador muitas vezes não permite determinar com precisão
qual evento ocorreu primeiro. A situação se agrava quando os alarmes e intertra-
vamentos são gerados em sistemas distintos, com relógios não sincronizados. Por
outro lado, é de extrema importância saber a causa de um desligamento de emergên-
cia afim de evitar uma nova ocorrência deste desligamento ou mesmo evitar eventos
catastróficos.
O sistema de sequenciamento de eventos (SOE - Sequence of Events System
ou SOR - Sequence of Events Recorder ) possui como objetivo o registro de intertrava-
mentos e alarmes que ocorreram no processo de forma a permitir uma análise destes
em casos de desligamentos de emergência.
2.2.4.1: Arquiteturas
Existem basicamente três arquiteturas de sistemas SOE:
• Sistema dedicado;
• Sistema integrado ao controlador (SDCD, PES, CLP);
• Sistema híbrido.
Os sistemas dedicados, cuja arquitetura é mostrada na figura 2.3, são constituí-
dos de processadores, módulos de entrada, aplicativos e impressoras a fim de permitir
a tarefa de sequenciamento de eventos. As saídas de intertravamento de instrumentos
e controladores são duplicadas (geralmente por duplicadores de estado sólido, para
não introduzir atrasos) e então conectadas à entrada do sistema externo.
Embora na arquitetura da figura 2.3 o sistema foi representado como um único
equipamento, a arquitetura de um sistema SOE dedicado pode ser distribuída, de
forma a exisitr módulos para captura de eventos de cada subsistema e um módulo
principal para ordenação e sincronização.
30
Figura 2.3: Sistema SOE externo - adaptado de [11]
Figura 2.4: Sistema SOE integrado ao SDCD - adaptado de [11]
31
Atualmente, diversos CLPs e a maioria dos SDCDs já possuem funções de SOE
incorporadas no equipamento, como mostrado na figura 2.4. No caso de CLPs, uma
solução adotada é utilizar um microprocessador exclusivo para monitorar as portas
do CLP e executar a função de sequenciamento, independentemente do processador
de lógica. As informações do sequenciamento podem ser disponibilizadas a outros
sistemas a partir de comunicação em rede. No caso de SDCDs, além dos processa-
dores dedicados nos cartões de entrada, é comum os sistemas apresentarem também
aplicativos especializados para o SOE.
Por último, pode-se ter um sistema híbrido no qual cada controlador executa o
registro de todos os eventos relacionados a ele (como por exemplo CLPs com fun-
ções de SOE) e repassa então este registro a um sistema superior, responsável por
armazenar, ordenar e exibir estes eventos.
A arquitetura híbrida é muitas vezes mais vantajosa financeiramente em rela-
ção à arquitetura totalmente dedicada. Entretanto, a sincronização entre os diversos
controladores torna-se um problema; nestes casos, uma solução de sincronização, tal
como sincronização por GPS (Global Positioning System), deve ser adotada.
2.3: Automação de grandes máquinas
Nesta seção apresenta-se uma discussão sobre automação de máquinas. Os
conceitos apresentados serão utilizados posteriormente na seção 3.4.9 a fim de per-
mitir o desenvolvimento das arquiteturas de automação das máquinas encontradas no
complexo petroquímico.
Utilizou-se como referência o trabalho de Campos e Filho [3]. Embora este
artigo foque em arquiteturas de automação para compressores dinâmicos (centrífugos
ou axiais), grande parte dos conceitos apresentados e características das arquiteturas
propostas são comuns a outras máquinas de grande porte, tais como compressores
volumétricos (alternativos e rotativos), sopradores, bombas e turbinas.
Campos e Filho [3] dividem a arquitetura de automação de uma máquina de
grande porte em 4 sistemas:
• Sistema de óleo de lubrificação e de comando;
• Sistema de monitoramento operacional;
32
• Sistema de controle;
• Sistema de intertravamento.
2.3.1: Sistema de óleo de lubrificação e de comando
O objetivo do sistema de óleo de lubrificação e de comado é garantir a circula-
ção do óleo de lubrificação, pois sua falta pode danificar seriamente todo o conjunto
rotativo. O sistema também é responsável pelo comando de atuadores hidráulicos.
2.3.2: Sistema de monitoramento
O objetivo do sistema de monitoramento operacional, conforme o nome sugere,
é monitorar as principais variáveis de operação da máquina, as quais podem fornecer
um diagnóstico desta. Como exemplo de variáveis, tem-se a temperatura dos mancais
de rolamento e os níveis de vibração axial e radial.
As informação podem ser coletadas e monitoradas por um dispositivo dedicado
(solução mais utilizada e recomendada para grandes máquinas) ou então pelo próprio
CLP de controle e intertravamento do equipamento. Em todos os casos, a medição das
variáveis de interesse deve ser feita a partir de sensores exclusivos, independentes do
sistema de controle. Além disso, no caso de um sistema de monitoramento dedicado,
este deve se comunicar com o CLP da máquina enviando informações de alarmes e
informações de estado das variáveis.
Os sistemas de monitoramento dedicados podem ser classificados em duas ca-
tegorias: monitoramento contínuo (figura 2.5) e monitoramento por varredura (figura
2.6). Nos sistemas de monitoramento contínuo, os sensores são conectados ao dis-
positivo de monitoramento de forma direta, ponto-a-ponto, formando uma topologia
em estrela. Estes sistemas destinam-se a máquinas críticas cujas variáveis devem
ser monitoradas em curtos espaços de tempo. Já nos sistemas de monitoramento
por varredura, os sensores são conectados ao dispositivo através de um barramento,
utilizando uma rede de sensores. Conforme discutido na seção 2.4.1.1, as redes de
sensores possuem a vantagem de reduzir custos na ligação. Entretanto, o uso de
uma rede pode fazer com que o dispositivo demore alguns segundos ou minutos para
fazer a leitura (ou “varrer”) todos os instrumentos ligados ao barramento. Este tipo de
sistema é utilizado em máquinas não críticas.
33
2.3.3: Sistema de controle
Os sistemas de controle existentes em uma máquina rotativa de grande porte
são: o controle de capacidade e o controle antisurge.
O controle de capacidade é responsável por adequar a vazão correspondente à
demanda instantânea do processo. Geralmente, este controle é feito a partir do SDCD,
o qual envia um sinal correspondente à referência (setpoint)para o controle de rotação
da máquina.
O controle antisurge tem por objetivo evitar que a máquina entre em uma condi-
ção de instabilidade dinâmica denominada de surge, que é uma ameaça à integridade
física do equipamento [4]. Este fenômeno é mais comum de acontecer nos compres-
sores dinâmicos, podendo também acontecer em bombas centrífugas e axiais e em
sopradores; porém, nestes equipamentos a ocorrência é menos frequente e os danos
menos severos. O controle antisurge pode ser implementado tanto em um controlador
independente quanto no CLP de intertravamento do compressor.
Informações mais detalhadas sobre o controle de capacidade e controle anti-
surge podem ser encontradas nos trabalhos de Campos e Teixeira [4] e Campos e
Filho [3].
2.3.4: Sistema de intertravamento
O sistema de intertravamento é responsável pelas ações automáticas (paradas
de emergência, por exemplo) quando a integridade física do equipamento estiver em
risco. Essas situações de risco são identificadas e tratadas como funções de segu-
rança (SIFs). O sistema é implementado em um CLP, e deve-se comunicar tanto com
o PES da unidade (para enviar e receber sinais de intertravamentos) quanto com o
SDCD (para sinais de status e alarmes).
No caso de máquinas com turbinas, além do sistema de intertravamento, deve
haver um sistema de detecção de sobrevelocidade com sensores. Recomenda-se que
este sistema seja um dispositivo eletrônico independente do dispositivo de intertrava-
mento.
34
2.4: Redes industriais
Nestas seção apresentam-se as tecnologias de rede de automação que fo-
ram especificadas no projeto do complexo petroquímico. Inicialmente, apresenta-se
uma classificação das redes industriais quanto à sua aplicação. Comenta-se breve-
mente o modelo de referência OSI/ISO, de forma a embasar a discussão. Por último,
apresentam-se as tecnologias utilizadas no complexo.
Procurou-se neste trabalho apresentar e discutir as redes industriais sob o ponto
de vista do usuário, e não do desenvolvedor. Desta forma, enfatizaram-se aspectos
de funcionalidade, aplicabilidade e características operacionais, discutindo o protocolo
apenas quando relevante ao usuário.
Uma discussão mais aprofundada sobre as tecnologias de redes industriais sob
o ponto de vista do usuário pode ser encontrada no trabalho de Caro [5]. Por outro
lado, uma discussão mais aprofundada sobre os protocolos e princípios das tecnolo-
gias é apresentada por Stemmer em [12].
2.4.1: Classificação
Caro [5] classifica as redes para automação industrial, quanto à finalidade, em
três categorias:
1. Redes de sensores (sensor networks);
2. Redes de campo (fieldbus networks);
3. Redes de controle (control networks).
2.4.1.1: Redes de sensores
As redes de sensores constituem o nível mais baixo da hierarquia de automa-
ção, e são projetadas com o objetivo de reduzir a fiação necessária para ligar o sensor
ao controlador (CLP ou SDCD). As figuras 2.5 e 2.6 mostram, respectivamente, a co-
nexão tradicional de sensores/atuadores e a solução utilizando uma rede. Pode-se
observar que, no caso em que o controlador está em um local distante do sensor, a
economia de cabos pode ser bastante significativa.
35
Figura 2.5: Conexão tradicional de sensores
Figura 2.6: Rede de sensores
O princípio de funcionamento das redes de sensores é o mesmo para todas as
tecnologias disponíveis: o estado do equipamento é detectado e convertido em 0 ou 1
em um registro. O registro é então transmitido pela rede a um dispositivo de varredura,
geralmente um CLP ou computador.
2.4.1.2: Redes de campo
O termo “rede de campo”, ou fieldbus, é usado para designar toda rede em
plantas de manufatura ou processos na qual há “inteligência” programável e distribuída
nos nodos, ou seja, o instrumento possui um microprocessador. O processador em
campo pode ser utilizado para realizar funções de processamento de sinais ou até
mesmo de controle.
O fato que distingue uma rede de sensores de uma rede de campo é que, no
caso daquelas, a informação do sensor é diretamente transmitida à rede, sem nenhum
tipo de processamento da informação. Já numa rede de campo, realiza-se processa-
mento de informações no sensor antes da transmissão para a rede, como por exemplo
uma mudança de escala da variável.
Como exemplo de redes de campo, citam-se as tecnologias Foundation Field-
bus e Profibus-PA.
36
Figura 2.7: Modelo de referência OSI/ISO
2.4.1.3: Redes de controle
As redes de controle (control networks) possuem como objetivo interligar con-
troladores (e.g. CLP ou SDCD) e permitir a comunicação destes com sistemas de
informação.
Em comparação com as redes de campo, as redes de controle possuem ge-
ralmente um tráfego maior de informações, e por causa disso mensagens maiores e
velocidade mais alta. Em alguns casos, é necessário que a rede tenha requisitos de
tempo real a fim de permitir a troca de dados críticos entre controladores.
Como exemplo de tecnologias de redes de controle, tem-se o Profibus-DP e o
Modbus. Atualmente, a tendência é que as redes de controle utilizem como base a
tecnologia Ethernet/TCP-IP devido ao seu baixo custo e capacidade de integração.
Um exemplo é a tecnologia Modbus-TCP.
2.4.2: Modelo OSI/ISO
O modelo de referência OSI (Open Systems Interconnection), descrito pela
norma ISO/IEC 7498-1:1994, é uma tentativa de padronizar as funcionalidades da
comunicação entre computadores. O modelo, ilustrado na figura 2.7, é divido em sete
camadas: física (1), enlace (2), rede (3), transporte (4), sessão (5), presentação (6) e
aplicação (7).
37
A camada de aplicação implementa um conjunto de protocolos bastante diver-
sificado e orientado a aplicações bem definidas. Como exemplo, tem-se o protocolo
HTTP (Hypertext Transfer Protocol), utilizado na web.
A camada de apresentação oferece algumas funções frequentemente neces-
sárias na comunicação (por exemplo compactação de dados), de modo a poupar o
usuário deste trabalho.
A camada de sessão é responsável pelo estabelecimento de sessões de diálogo
para os usuários da rede. Um exemplo de serviço é efetuar a gestão do diálogo, ou
seja, definir, por exemplo, se o diálogo vai ser efetuado em modo uni ou bidirecional.
A camada de transporte representa uma interface entre as camadas orientadas
à comunicação (1, 2 e 3) e as camadas orientadas à aplicação (5, 6, e 7). Ela recebe
os dados enviados da camada de sessão e deve decompô-los, se for o caso, em uni-
dades de dados menores (datagramas) e garantir que todas as partes da mensagem
vão ser transmitidas corretamente à outra extremidade.
A camada de enlace de dados provê o encapsulamento dos dados e a trans-
missão livre de erros para a camada de rede. Ela efetua esta função através da de-
composição das mensagens em unidades menores de dados denominadas quadros
(frames).
A camada física é responsável pela transferência de bits em um circuito de
comunicação. De maneira geral, sua função é garantir que cada bit enviado de um
lado será recebido do outro lado sem ter alterado o seu valor.
2.4.3: Tecnologias
Nesta seção apresentam-se as principais tecnologias de comunicação digital
utilizadas no complexo petroquímico: HART, Foundation Fieldbus, Profibus, Ethernet
/ TCP-IP, Modbus e OPC. Conforme dito anteriormente, a discussão foi baseada nas
características de aplicação de cada tecnologia, do ponto de vista do usuário de auto-
mação.
2.4.3.1: HART
A tecnologia HART (Highway Adressable Remote Transducer ) foi criada para
permitir a comunicação digital entre instrumentos de campos e controladores ou com-
38
putadores, porém mantendo a transmissão da variável no padrão 4−20mA. Os dados
digitais são transmitidos através da modulação de um sinal de corrente de pequena
intensidade junto com o sinal primário 4 − 20 mA. A velocidade da comunicação é
limitada a 1200 bits/s.
Os dispositivos HART podem ser ligados em módulos de entrada somente ana-
lógicos, e neste caso o conteúdo digital do sinal é descartado, ou então ligado em
módulos capazes de ler informações HART. Atualmente, a maioria dos CLPs e SDCD
possuem cartões de entrada 4− 20 mA com capacidade HART.
O protocolo HART é frequentemente utilizado para realizar tarefas de geren-
ciamento de ativos. Pode-se, por exemplo, realizar o ajuste de zero e span através
da interface do SDCD ou através de um computador de mão. Além disso, pode-se
monitorar remotamente variáveis operacionais como a temperatura do invólucro do
instrumento.
Uma versão de barramento da tecnologia HART também é especificada pela
Hart Foundation, permitindo a comunicação totalmente digital (sem utilizar o sinal 4−20mA). Entretanto, este versão não é amplamente utilizada devido à baixa velocidade
de transmissão (1, 2 kbits/s).
Uma tendência futura é o uso do protocolo HART em redes sem fio (wireless).
Esta tecnologia vem sendo desenvolvida pela HART Foundation e as perspectivas de
aplicações são grandes.
2.4.3.2: Foundation Fieldbus
A tecnologia Foundation Fieldbus (FF) foi criada para suprir a necessidade de
uma rede de comunicação digital a fim de ser utilizada em controle de processos. Ini-
cialmente, pretendia substituir as transmissões de sinais em 4 − 20 mA. A tecnologia
deveria também utilizar os mesmos tipos de fios que os instrumentos convencionais,
ser capaz de suprir potência elétrica aos dispositivos e poder cumprir com requisitos
de segurança intrínseca. A norma ANSI/ISA-50.02 serviu de base para a implemen-
tação do protocolo pela Fieldbus Foundation. Mais tarde, a tecnologia foi incorporada
na norma internacional IEC 61158.
A Filedbus Foundation especificou dois níveis de rede FF: o FF H1 e o FF HSE.
O nível H1 (abreviatura de Hunk 1) é utilizado para interligar instrumentos inte-
ligentes em rede utilizando um barramento (segmento H1). Neste nível, a rede opera39
Figura 2.8: Topologia da rede FF H1
na velocidade de 31, 25kbps. Esta velocidade baixa é necessária para que os requi-
sitos de rejeição de ruído, entrega de potência e segurança intrínseca possam ser
implementados.
A topologia da rede FF H1, ilustrada na figura 2.8, é chamada de “tronco e
ramal” (trunk and spur ). Nesta topologia, todos os dispositivos de um segmento H1
são interconectados em caixa de junção, localizada no campo. Desta caixa de junção
sai um multicabo que é ligado a um cartão de entrada FF do controlador (host).
A principal característica da rede FF H1 é a capacidade de implementar as
malhas de controle diretamente nos instrumentos em campo, permitindo uma real dis-
tribuição do controle. Como exemplo, num controle em cascata de nível, o controlador
de vazão (escravo) é usualmente implementado no transmissor da válvula; o contro-
lador de nível (mestre), por sua vez, é implementado no transmissor de nível. Nesta
configuração, o transmissor de nível envia a referência de vazão diretamente à válvula
de controle, e esta envia o valor da variável de processo diretamente ao transmissor
de nível. Convém salientar que esta característica de implementar malhas de controle
nos próprios transmissores só é possibilitada atualmente pela tecnologia Foundation
Fieldbus.
O FF HSE (High Speed Ethernet) foi especificado para permitir a comunicação
entre diferentes segmentos H1, e utiliza a Ethernet como camada física e de enlace.
Maiores informações sobre o FF HSE e sobre FF em geral podem ser encontradas em
[5].
40
2.4.3.3: Profibus
O Profibus (Process Field Bus) foi desenvolvido na Alemanha, inicialmente pela
Siemens em conjunto com a Bosch e Klockner-Moeller, em 1987, a fim de permitir a
comunicação de CLPs com outros dispositivos de fábrica. O protocolo começou como
uma especificação de trocas de mensagens que ficou conhecida como Profibus FMS
(Factory Message Specification). O FMS, por sua vez, é um subconjunto da norma
ISO 9509, MMS (Manufacturing Message Specification), eliminando os comandos que
não são necessários para a comunicação entre CLPs.
Apesar do Profibus ter sido desenvolvido com o objetivo de ser um padrão para
a comunicação entre CLPs e sistemas como IHMs, o antigo protocolo Profibus FMS
mostrou-se ser muito lento para suportar atualizações das interfaces homem-máquina
(IHM). Quando conexões com terminais remotos de CLPs ou multiplexadores remotos
tornaram-se uma necessidade, o protocolo Profibus-DP (Device Protocol) foi criado
para resolver ambos os problemas.
O Profibus-DP opera sobre um par-trançado blindado utilizando o protocolo
EIA/TIA-485. A velocidade pode variar de acordo com o cabo, mas é especificada
entre 9600 bit/s e 12 Mbit/s. O acesso a informações é feito a partir do protocolo
mestre-escravo, que permite sincronismo e torna a rede determinista. Uma vez que
existe somente um mestre na rede em todo instante de tempo, a comunicação é half-
duplex 1. Devido a suas características de determinismo e alta velocidade, o Profibus-
DP pode ser utilizado tanto como rede de controle quanto rede de campo, embora
esta última categoria aplique-se apenas para instrumentos de automação discreta.
O Profibus-PA (Process Automation) foi criado para ser utilizado em controle de
processos. O protocolo utiliza a mesma estrutura de mensagens do Profibus-DP e é
implementando utilizando as mesmas especificações da camada física do Foundation
Fieldbus H1. Normalmente, os instrumentos são conectados em uma caixa de junção
que os acoplam na rede Profibus-DP. Entretanto, existem SDCDs e CLPs com cartões
de entrada diretamente Profibus-PA.
Um substituto natural do Profibus é a tecnologia PROFInet, que utiliza um mo-
delo de objetos baseados em XML (Extensible Markup Language) e Ethernet com
TCP-IP [5].1Uma explicação sobre termos como half-duplex é feita em [12]
41
2.4.3.4: Ethernet/TCP-IP
A Ethernet é uma tecnologia de rede local (LAN - local area network ) definida
pela norma IEC/ISO 8802-3 (idêntica à norma IEEE 802.3), especificando somente a
camada física e a camada de enlace de dados do modelo de referência OSI.
Atualmente, a Ethernet é utilizada em diversas tecnologias abertas e mesmo
em redes proprietárias. Como exemplo, cita-se o Modbus-TCP, apresentado na seção
2.4.3.5. A vantagem de se utilizar o padrão Ethernet é o reduzido custo dos compo-
nentes, visto que a tecnologia é amplamente difundida para troca de informações nos
ambientes comerciais e residenciais.
A idéia fundamental da Ethernet é utilizar um meio de acesso (“ether”) compar-
tilhado entre os diversos nodos da rede, utilizando um protocolo de controle de acesso
ao meio denominado CSMA/CD (Carrier Sense Multiple Access / Colision Detection),
especificado pela norma IEC/ISO 8802-3. Por não garantir determinismo, este pro-
tocolo é uma das principais objeções para o uso da Ethernet em redes de controle e
principalmente em redes de campo.
Atualmente, uma modalidade de Ethernet denominada Ethernet comutada vêm
sendo cada vez mais utilizada. O uso de swtiches (comutadores) no lugar de hubs
(concentradores) permite descartar o protocolo CSMA/CD e assim, em princípio, eli-
minar o não-determinismo da rede. Desta forma, diversos trabalhos têm sido desen-
volvidos para permitir aplicações deterministas em redes Ethernet comutadas.
O TCP (Transport Control Protocol) é um protocolo que pode ser enquadrado
na camada 4 do modelo de OSI e tem por função estabelecer uma conexão “confiável”
para a camada de aplicação. O protocolo IP (Internet Protocol), por sua vez, enquadra-
se na camada 3 do modelo OSI e permite a interconexão de redes locais. Embora em
princípio os procolos TCP e IP possam ser utilizados com outras tecnologias de enlace
de dados, eles são em geral utilizados em conjunto com a Ethernet.
2.4.3.5: Modbus
O Modbus é o protocolo de comunicação a nível de rede de controle mais di-
fundido no meio industrial [5]. Ele foi desenvolvido inicialmente pela empresa Modicon
para estabelecer um protocolo mestre-escravo para comunicação de seus CLPs com
computadores.
42
Figura 2.9: Estrutura do protocolo Modbus
O protocolo define um conjunto de comandos e um formato de mensagens que
permitem a transferência de registros de CLPs ou outros dispositivos de controle para
um segundo dispositivo. Assim, o conjunto de comandos por ser visto como um proto-
colo da camada 7 do modelo OSI. Diversas camadas físicas tem sido utilizadas para
implementar o Modbus, conforme mostra a figura 2.9.
O Modbus foi originalmente desenvolvido para operar sobre uma linha serial as-
síncrona descrita pela norma ANSI/EIA/TIA-232F, utilizando assim a topologia ponto-
a-ponto. Posteriormente, passou-se a utilizar o padrão ANSI/EIA/TIA-485. O padrão
485 utiliza uma linha diferencial balanceada, possibilitando distâncias maiores e me-
lhor imunidade ao ruído. Além disso, o padrão 485 permite utilizar um barramento
para conectar vários equipamentos.
Existem dois modos de operação do Modbus sobre uma linha serial: Modbus
ASCII e Modbus RTU. No primeiro modo, a mensagem (dígitos hexadecimais) é co-
dificada em caracteres ASCII (ISO-14962-1997). No modo RTU (também conhecido
como modo binário), o a mensagem é convertida diretamente para o formato binário,
tendo a mensagem a metade do tamanho em bytes daquela convertida em ASCII. Por
ser mais rápido, o Modbus RTU é frequentemente mais utilizado.
Em 1998, foi desenvolvido o protocolo Modbus-TCP. Esta especificação foi ori-
ginalmente publicada na página web da Modicon/Schneider, entretanto foi posteri-
ormente transferida para a associação independente Modbus.org. A principal vanta-
gem do Modbus-TCP perante as outras especificações consiste no reduzido custo dos
componentes Ethernet, além de permitir que dispositivos de controle sejam facilmente
integrados e acessados a partir de redes locais ou através da Internet.
43
2.4.3.6: OPC
O OPC é uma série de especificações padrões utilizadas para comunicação
entre sistemas de automação industrial.
A primeira especificação, originalmente chamada simplesmente de OPC e agora
chamada de Data Access Specification, resultou da cooperação entre fornecedores de
equipamentos de automação com a Microsoft. A especificação definiu um conjunto de
objetos, interfaces e métodos para utilização em aplicações de controle de processos
e automação da manufatura a fim de facilitar a interoperabilidade dos sistemas. Este
padrão foi originalmente baseado nas tecnologias OLE COM e DCOM da Microsoft.
Os servidores OPC provêem métodos para que aplicativos possam acessar
dados de um dispositivo de controle, tal como CLP ou SDCD. Uma vez que um servidor
OPC é escrito para um determinado equipamento, ele pode ser utilizado por qualquer
aplicativo capaz de agir como cliente OPC. Os servidores OPC utilizam a tecnologia
COM para comunicar com os clientes, permitindo a troca de informações do processo
em tempo-real.
A especificação original (OPC-DA) padronizou a aquisição de dados de pro-
cesso. A partir dela, percebeu-se que a comunicação de outros tipos de dados po-
deriam também ser padronizados. Atualmente, além do OPC-DA, diversas especifi-
cações estão em andamento ou já foram completadas, dentre elas: OPC Alarms &
Events, OPC Batch, OPC Historical Data Access, OPC Security e OPC Commands.
Uma das principais desvantagens das especificações OPC é dependência da
tecnologia COM da Microsoft. A fim de resolver este problema, uma especificação
denominada OPC Unified Architecture vem sendo desenvolvida e testada. Esta espe-
cificação pode ser implementada utilizando Java, Microsoft .NET ou C, eliminando a
necessidade do uso da plataforma Windows.
44
Capítulo 3: Desenvolvimento
Neste capítulo é apresentado o desenvolvimento das arquiteturas de automação
das unidades de processo do complexo petroquímico.
Inicialmente, descreve-se a arquitetura geral do complexo petroquímico (seção
3.1). Em seguida, apresentam-se os principais requisitos e critérios para o projeto
de automação das unidades de processo (seção 3.2). Elabora-se então uma arqui-
tetura pré-detalhada para uma unidade genérica (3.5). Por último, como exemplo de
arquitetura específica elaborada, apresenta-se a arquitetura de automação de um tur-
boexpansor acionando um gerador (seção 3.6).
3.1: Arquitetura geral do complexo
O complexo petroquímico pode ser divido em um conjunto de 3 tipos de unida-
des:
• Unidades de processo;
• Utilidades;
• Facilidades.
As unidades de processo possuem como finalidade produzir matéria-prima pe-
troquímica como propeno, eteno, benzeno e butadieno e também produtos de segunda
geração, tais como como polipropileno, polietileno, etileno glicol, estireno, PTA e PET.
As unidades de utilidades auxiliam a operação das unidades de processo. Exomo
exemplo de utilidades, têm-se as unidade des tratamento de água e condensado, uni-
dades de combustíveis, unidade de ar comprimido de serviço, unidade de geração de
energia elétrica, subestações de distribuição, dentre outras.
As facilidades são: parque de armazenamento de matéria-prima, produtos inter-
mediários e finais, instalações administrativas, de manutenção e operação, instalações
de recebimento e expedição de produtos e instalações de infraestrutura.
A operação de todo o complexo petroquímico é feita a partir de um centro inte-
grado de controle (CIC). Este centro recebe e envia informações para as unidades do45
Figura 3.1: Arquitetura do complexo petroquímico
complexo que possuem sistemas de controle e automação.
Os sistemas de constrole das unidades consistem basicamente em sensores
e atuadores localizados no campo e de controladores localizados em uma casa de
controle local (CCL). Cada unidade de processo possui sua CCL, enquanto que o
controle de unidades de facilidades e utilidades é feito em salas de controle geral-
mente compartilhadas. A figura 3.1 mostra um esquema da arquitetura do complexo
petroquímico.
Conforme discutido na seção 1.1, neste trabalho será dada ênfase aos equipa-
mentos e sistemas localizados no campo e nas CCLs das unidades de processo. O
detalhamento dos sistemas do CIC será feito na etapa de detalhamento do projeto. A
unidades de utilidades e facilidades não fazem parte do escopo do trabalho.
3.2: Levantamento de requisitos
Os requisitos de automação do complexo petroquímico foram levantados a partir
de documentos de especificações técnicas do projeto, que foram elaborados durante
a etapa conceitual.
O levantamento de requisitos permitiu, além da base para o desenvolvimento
das arquiteturas, uma análise de consistência dos documentos do projeto. Requisitos
46
levantados como inconsistentes ou dúbios foram discutidos em reuniões com o cliente.
Os requisitos levantados para cada sistema particular (por exemplo requisitos
do SDCD) serão apresentados na seção de pré-detalhamento destes sistemas. Nesta
seção, serão apresentados os requisitos dos sistemas de “pacote”.
Entende-se como “pacote” o conjunto de instrumentos, equipamentos e siste-
mas fornecidos por empresas terceiras, as quais são responsáveis pela instalação,
configuração e integração do equipamento à unidade. Um exemplo de pacote são os
compressores, os quais devem ser fornecidos pelo fabricante juntamente com seus os
sistemas auxiliares (lubrificação, controle, intertravamento, supervisão).
Denomina-se RCP (Remote Control Panel) um gabinete, localizado numa CCL,
que contém dispositivos para controle e supervisão (e.g. CLP) de um determinado
equipamento. Se este gabinete localizar-se no campo, próximo ao equipamento, o
gabinete recebe a denominação de LCP (Local Control Panel). Um painel com função
apenas de comando e supervisão, sem possuir CLP ou outro dispositivo de controle,
é denominado LP (Local Panel).
Os requisitos de automação levantados para os pacotes são os seguintes:
1. Para fim de padronização, todos instrumento devem ser do tipo 4 − 20 mA ou
0− 24V dc.
2. Todos os instrumentos analógicos 4− 20 mA devem ser compatíveis com o pro-
tocolo HART e devem ser conectados à rede de gerenciamento de ativos (AMS);
3. A operação e supervisão do pacote deve ser feita, em condições normais, atra-
vés do SDCD. Assim, os sinais necessários para operação e supervisão do pa-
cote devem estar disponíveis no SDCD, incluindo sinais de status e alarmes;
4. Sinais de alarme e status devem ser transmitidos via comunicação serial utili-
zando preferencialmente o protocolo Modbus-TCP;
5. A comunicação entre LCPs ou LPs e SDCD deve ser feita utilizando fibra óptica
para o caso de sinais de monitoramento;
6. Intertravamentos e sinais de controle devem ser transmitidos entre o RCP ou
LCP ao PES (explicado na seção 2.2.2) utilizando comunicação não protocolada
(hardwired);
47
7. Os CLPs de pacote, controladores e outros equipamentos configuráveis devem
possuir uma porta Ethernet para manutenção remota;
8. Comandos de partida, parada e parada de emergência (trip) de motores elétri-
cos devem ser enviados diretamente para o CCM utilizando comunicação não
protocolada(hardwired).
Um item que vale a pena ser comentado é sobre o requisito de transmissão de
sinais de supervisão utilizando o protocolo Modbus-TCP. Embora este protocolo tenha
sido definido há mais de 10 anos, muitos sistemas ainda oferecem suporte somente
ao Modbus padrão (RTU sobre EIA/TIA-485). Este é o caso por exemplo, de alguns
controladores de velocidade de turbinas. Nestes casos, a opção é ou utilizar o pro-
tocolo padrão ou utilizar um conversor de protocolos (gateway ) a fim de convertê-lo
para Modbus-TCP. Neste projeto, adotou-se a primeira opção, visto que o uso de um
conversor acrescenta custos e aumenta a probabilidade de falhas.
3.3: Arquitetura conceitual
Com base nos requisitos levantados e em documentos do projeto conceitual,
elaborou-se, para as unidades de processo do complexo, uma arquitetura de automa-
ção conceitual, mostrada na figura 3.2. Esta arquitetura tem por objetivo apresentar
uma visão geral de automação das unidades e servir de base para a elaboração da
arquitetura pré-detalhada.
Na figura 3.2, são mostradas três partes do complexo: o campo, a casa de
controle local (CCL), e o centro integrado de controle (CIC). Na CCL encontram-se os
principais equipamentos de controle da unidade:
• SDCD (sistema digital de controle distribuído);
• PES (Programmable Electronic System);
• PES de F&G;
• PES de fornos a chama (se existentes).
Os equipamentos de controle comunicam-se com elementos sensores e atua-
dores no campo, que podem ser analógicos, digitais ou do tipo Foundation Fieldbus.
48
Figura 3.2: Arquitetura conceitual de uma unidade de processo
49
Para os elementos analógicos e digitais, utilizam-se painéis de rearranjo para a cone-
xão com os cartões de E/S dos controladores, a fim de permitir melhor organização
da fiação.
Mostra-se também, na CCL, um painel de controle remoto (RCP) de um equi-
pamento típico. Neste painel localiza-se o CLP responsável pelo controle e intertrava-
mento do equipamento e dos sistemas auxiliares. Geralmente o os sensores, atuado-
res , CLPs e sistemas de controle de equipamentos são fornecidos em conjunto pelo
fabricante do equipamento, constituindo um “pacote”, conforme explicado na seção
3.2.
Também está presente CCL redes para os sistemas gerenciamento de informa-
ções, a saber:
• Rede de manutenção (RMN);
• Sistema de gerenciamento de ativos (AMS);
• Sistema de sequenciamento de eventos (SOE).
Representou-se também na arquitetura conceitual uma sala para os equipa-
mentos elétricos. Nesta sala encontram-se o centro de distribuição de cargas (CDC),
o centro de controle de motores (CCM) e conversores de freqüência (VSD – Variable
Speed Drivers).
A comunicação entre os sistemas e equipamentos ocorre em dois níveis: em
nível de troca de informações de status e alarmes (representado no nível superior do
diagrama) e em nível de intertravamentos (representados por ligações entre os painéis
de rearranjo).
Na arquitetura conceitual representaram-se apenas as principais comunicações
entre os sistemas, sem detalhar a topologia e os protocolos. O detalhamento das
arquiteturas é feito na seção seguinte.
3.4: Pré-Detalhamento
Nesta seção apresentam-se as arquiteturas de automação desenvolvidas para
os seguintes sistemas: sistema digital de controle distribuído (SDCD), sistema ins-
trumentado de segurança (SIS), sistema de fogo e gás (FeG e FeGBA), sistema de
50
Figura 3.3: Simbologia
gerenciamento de ativos (AMS), sistema de sequenciamento de eventos (SOE), rede
de manutenção (RMN), analisadores, fornos a chama e sistemas de automação de
máquinas de grande porte. Estes sistemas são o presentes na maioria das unidades
de processo.
A simbologia adotada para representar os tipos de comunicações entre os sis-
temas é mostrada na figura 3.3.
3.4.1: Sistema digital de controle distribuído
Conforme definido na seção 2.2.1, o sistema digital de controle distribuído (SDCD)
é o conjunto de hardware e software integrados com o objetivo de implementar estra-
tégias de controle e gerenciamento de informações.
A figura 3.4 mostra a arquitetura pré-detalhada desenvolvida para o SDCD das
unidades de processo do complexo petroquímico.
Em cada CCL, o SDCD é constituído por controladores e cartões de entrada
e saída analógicos, digitais e FF localizados em um gabinete. Conforme requisito de
projeto, os instrumentos analógicos e digitais digitais devem ser ligados em painéis
de rearranjo, e estes por sua vez são ligados nos cartões de E/S de controladores
do SDCD. O uso de painéis de rearranjo permite uma melhor organização da fiação e
evita a realização de manuseios diretos nos cartões de E/S.
51
Figura 3.4: Arquitetura do SDCD
52
3.4.1.1: Comunicação com servidores no CIC
O SDCD comunica-se com servidores no CIC (centro integrado de controle)
através de uma rede utilizando os protocolos Ethernet/TCP-IP nas camadas inferio-
res (1 a 4) do modelo OSI e protocolo próprio do sistema (proprietário ou não) nas
camadas superiores. Esta rede interliga os controladores de todas as unidades do
complexo a sistemas localizados no CIC, como por exemplo ao sistema de controle
avançado e às estações de operação do SDCD. Como se trata de comunicação crí-
tica, evolvendo dados de controle, esta rede foi especificada como sendo redundante
e com rotas diferentes até o CIC. Utiliza-se fibra óptica para a extensão da rede da
CCL ao CIC, devido à distância entre os locais.
Especificou-se também uma estação de engenharia na CCL conectada ao SDCD
por meio da rede descrita acima. Esta estação tem por finalidade a configuração e ma-
nutenção do SDCD e de seus instrumentos.
3.4.1.2: Comunicação com o PES e CLPs de pacotes
O SDCD recebe informações de status e alarme do PES da unidade e de CLPs
de pacote através de comunicação Modbus-TCP. Por outro lado, sinais de partida,
parada e parada de emergência (trip) de equipamentos são enviados através de sinais
0− 24 V cc.
3.4.1.3: Comunicação com o CCM-CDC
No caso de motores elétricos, o comando de partida e parada é enviado ao
centro de controle de motores (CCM) ou ao centro de distribuição de cargas (CDC),
explicados na seção 3.4.10, através de comunicação utilizando o protocolo Profibus-
DP. Informações de status dos motores são recebidas do mesmo modo. Por outro lado,
comandos de desligamento de emergência são enviados ao CCM ou CDC através de
sinais 120 V ca. Na seção 3.4.10, as comunicações dos sistemas com CCM e CDC
são mais detalhadas.
3.4.2: Sistema instrumentado de segurança
Conforme apresentado na seção 2.2.2, o sistema instrumentado de segurança
(SIS) possui como função impedir que o processo e equipamentos operem em faixas53
que possam causar riscos à segurança das pessoas ou ao meio-ambiente.
Definiu-se para a arquitetura do sistema instrumentado de segurança um exe-
cutor de lógica (PES) independente do SDCD. Como requisito de projeto, este PES
deve possuir certificação TÜV SIL3. 1
Ainda como requisito, todos os instrumentos relacionados ao SIS devem comu-
nicar-se com o PES através de comunicação não protocolada (hardwired), não sendo
permitido a via rede.
A figura 3.5 mostra a arquitetura pré-detalhada desenvolvida para o SIS.
3.4.2.1: Comunicação com servidores no CIC
O SIS possuirá no centro integrado de controle (CIC) servidores (hospendando
sistemas de automação) e estações de engenharia para operação e manutenção. O
PES comunica-se com estes sistemas através de uma rede Ethernet com rotas re-
dundantes e com fibra óptica como meio. Além disso, no CIC existirá um painel com
botoeiras de emergência, interliado a um módulo do SIS também localizado no CIC.
A comunicação entre este módulo do SIS (localizado no CIC) e o PES (localizado na
CCL) é feito através de uma rede Ethernet redundante, com rotas diferentes e com
certificação TÜV SIL3.
3.4.2.2: Comunicação com o SDCD
De acordo com requisito de projeto, os sinais de intertravamentos enviados do
SDCD ao PES não podem ser transmitidos utilizando comunicação serial digital; deve-
se utilizar sinais 4−20 mA (analógicos) ou 0−24 V cc (digitais). Entretanto, informações
de status e alarmes podem ser enviadas através de uma rede de controle redundante
utilizando protocolo Modbus-TCP.
3.4.2.3: Comunicação com pacotes
Os pacotes devem enviar e receber sinais de parada de emergência (trip) atra-
vés de sinais 0− 24 V cc, não sendo permitida comunicação serial digital.
1SIL significa nível de integridade de segurança (Safety Integrity Level) [2]. TÜV são organizaçõesde origem alemã que certificam protudos e serviços; um exemplo é a TÜV Rheinland.
54
Figura 3.5: Arquitetura do SIS
55
3.4.2.4: Comunicação com o CCM-CDC
Em situações de riscos onde se faz necessário o desligamento de compresso-
res, bombas ou outros equipamentos com motores elétricos, bem como todo o sistema
de alimentação da unidade, a informação de parada destes sistemas elétricos deve ser
comandada pelo PES através de sinais digitais 0− 120 V ca;
3.4.2.5: Comunicação com o AMS
Os instrumentos analógicos 4 − 20 mA + HART são conectados ao sistema de
gerenciamento de ativos (AMS - Asset Management System) através de um multiple-
xador HART. Este multiplexador filtra as informações HART dos sinais e as multiple-
xam em um par-trançado utilizando o protocolo EIA/TIA-485. O sinal multiplexado é
então encapsulado em um quadro Ethernet e enviado ao switch AMS da CCL, o qual
está conectado ao sistema AMS no CIC.
3.4.2.6: Comunicação com o sistema SOE
Conforme discutido na seção 2.2.4, os atuais CLPs, SDCDs e PES possuem
nos próprios cartões de entrada um microprocessador dedicado para realizar a varre-
dura e registro dos eventos, e então transmiti-los a uma estação utilizando protocolo
OPC. Na arquitetura mostrada na figura 3.5, a comunicação do PES com o sistema
SOE dá-se através de uma rede local Ethernet na CCL, que por sua vez está ligada
ao CIC por meio de fibra óptica.
Para garantir a sincronização dos eventos do SIS com o dos outros sistemas,
o PES deve ser conectado a um sistema externo para sincronização de relógio. Na
arquitetura pré-detalhada, o sistema de sincronização não foi representado, porém a
informação da necessidade deste sistema foi registrada através de uma nota.
3.4.3: Sistema de fogo e gás
O sistema de detecção de fogo monitora, através de sensores de chama e de
fumaça, focos de incêndio no campo e na CCL. Caso seja detectado a presença de
fogo, um sistema constituído de válvulas de dilúvio 2 é disparado, alertas visuais e2Válvulas que pulverizam água no processo em caso de incêndio.
56
sonoros são emitidos no campo e no CIC e intertravamentos de emergência são ini-
ciados pelo PES da unidade. Semelhantemente, caso seja detectado fogo na CCL,
alarmes locais e no CIC são gerados, intertravamentos de emergência processo são
disparados pelo PES da unidade e intertravamentos são iniciados a fim de garantir a
integridade do processo.
O sistema de detecção de gás tem por objetivo detectar vazamentos logo no
início da ocorrência, possibilitando assim a tomada de ações rápidas, tais como isola-
mento da área, desligamento de equipamentos, minimização ou parada do vazamento.
O sistema também pode ainda ser utilizado para investigações pós-incidentes
ou acidentes. No caso de vazamento de gás tóxico, pode-se estimar a concentração
do gás contaminante presente na área e, partir desta informação, determinar os níveis
máximos de exposição humana à área ou auxiliar em ações médicas e ambientais.
No caso de vazamento de gás combustível o qual resultou uma explosão, o sistema
de detecção pode auxiliar a determinar o momento exato da da ocorrência do evento.
Subdividiu-se o sistema de F&G da unidade em dois sistemas: um para a de-
tecção de fogo e gás no processo, cuja arquitetura é mostrada na figura 3.6, e outro
para detecção de fogo e gás na CCL, cuja arquitetura é mostrada na figura 3.7.
3.4.3.1: Sistema de fogo e gás do processo
Os detectores de F&G (figura 3.6) são instrumentos convencionais (4 − 20 mA
e 0− 24 V cc) ligados ao PES de F&G através de sinais analógicos 4 20 mA ou digitais
0 − 24 V cc. Caso os instrumentos analógicos tenham capacidade de comunicação
digital HART, estes devem são ligados à rede de gerenciamento de ativos (conforme
representado na figura). Além dos transmissores, é conectado ao PES de F&G do
processo válvulas de dilúvio e dispositivos de alarmes audiovisuais.
Na ocorrência de detecção de fogo ou gás, o PES de F&G envia alarmes ao
SDCD via comunicação ponto-a-ponto redundante utilizando o protocolo Modbus-TCP.
Caso os alarmes sejam causadores de intertravamentos de processo, a informação
deve ser transmitida ao PES da unidade através de sinais digitais 0− 24 V cc.
Como o sistema de F&G é gera alarmes e intertravamentos, o mesmo deve
possuir cartões com capacidade de sequenciamento de eventos e deve ser conectado
à rede SOE da unidade.
57
Figura 3.6: Arquitetura do sistema de F&G
58
Figura 3.7: Arquitetura do sistema de F&GBA
3.4.3.2: Sistema de fogo e gás da CCL
O sistema de fogo e gás da CCL (figura 3.7), denominado F&GBA (Fire and Gas
Buiding Automation), é composto por instrumentos convencionais (4 20 mA +HART e
0−24 V cc) conectados a um PES. Os instrumentos analógicos compatíveis com HART
são conectados à rede de gerenciamento de ativos.
Caso seja detectado a presença de gás no sistema de ventilação ou condicio-
namento de ar da CCL (HVAC – Heating,Ventilation and Air Conditioning), o F&GBA
deve enviar alarmes a este sistema para que intertravamentos sejam realizados. Estas
informações são transmitidas através de sinais digitais 0 − 24V cc. Semelhantemente,
sinais que geram intertravamentos de processo devem ser enviados ao PES da uni-
dade também através de sinais digitais.
Em relação à comunicação com o SDCD, alarmes são enviados a este sistema
através de comunicação redundante via Modbus-TCP. Além disso, como o sistema
F&GBA gera alarmes e intertravamentos, este deve possuir cartões com capacidade
de sequenciamento de eventos e deve ser conectado à rede SOE da unidade.
Por último, o F&GBA comunica-se com uma painel principal de controle de F&G
localizado no CIC, que tem como objetivo monitorar todas as subestações do com-
plexo.
59
3.4.4: Sistema de gerenciamento de ativos
O sistema de gerenciamento de ativos (AMS - Asset Management System),
apresentado na seção 2.2.3, possui como objetivo monitorar continuamente os instru-
mentos da planta, permitindo a realização de diagnósticos, configurações e manuten-
ções .
A figura 3.8 mostra a arquitetura desenvolvida para o sistema de gerenciamento
de ativos da CCL.
Para cada pacote com instrumentos analógicos, especificou-se que o acesso às
funções de gerenciamento por meio de um filtro e multiplexador HART independente
do CLP ou controlador. Isto porque não se sabe nesta etapa de projeto se o modelo
do CLP/controlador possuirá cartões com saída HART.
O multiplexador possui um microprocessador capaz de filtrar as informações
HART do sinal 4− 20 mA e multiplexar as informações em uma linha de comunicação
serial padrão EIA-485. Estas informações, por sua vez, passam por um conversor
EIA-485/Ethernet, que encapsula as informações em um datagrama TCP e as tornam
disponíveis para acesso via uma rede Ethernet TCP/IP.
Especificou-se para cada CCL uma rede local para o gerenciamento de ativos.
Esta rede, por sua vez, está interligada à rede de gerenciamento de ativos do CIC
através de comunicação via fibra ótica (devido à distância entre a CCL e o CIC), com
redundância e rotas diferentes.
No caso do SDCD, conforme comentado na seção 2.2.3 os sistemas modernos
já possuem integrado um sistema próprio de gerenciamento de ativos. Assim, não
é necessário o uso de um dispositivo independente com filtro e multiplexador HART;
as informações são acessadas pelo aplicativo AMS (localizado em servidores no CIC)
diretamente do SDCD através do protocolo OPC-UA ou OPC-DA.
Além do ser possível realizar o gerenciamento de ativos a partir do CIC, pode-
se configurar e diagnosticar instrumentos conectados ao SDCD e ao PES a partir de
estações de engenharia localizadas na CCL. Estas estações, mostradas nas figuras
3.4 e 3.5, foram especificadas para a configuração dos referidos sistemas.
60
Figura 3.8: Arquitetura do AMS
61
3.4.5: Sistema de sequenciamento de eventos
O sistema de sequenciamento de eventos, apresentado na seção 2.2.4, possui
como objetivo capturar e gravar sequencias de eventos que podem ocasionar o des-
ligamento de emergência de um sistema ou processo, ajudando no diagnóstico das
causas e consequências do desligamento.
O sistema SOE do complexo é constituído por servidores no CIC capazes de co-
letar dados de todos os sistemas que geram alarmes e intertravamentos e disponibilizá-
los a um aplicativo de análise. Os sistemas que geram alarmes e intertravamentos
são: SDCD, PES, F&G, F&GBA, sistemas de monitoramento de máquinas, CLPs de
pacotes e controladores dedicados.
A arquitetura desenvolvida para o sistema SOE é mostrada na figura 3.9. Os
dados são coletados no campo ou na CCL através de um sistema integrado ao con-
trolador ou através de um sistema externo e enviados aos servidores no CIC através
do protocolo OPC-UA ou OPC-A&E. Para isso, especificou-se na CCL uma rede local
Ethernet interligando todos os dispositivos da unidade através um switch principal, e
este por sua vez conectado aos servidores do CIC através de fibra óptica. Além disso,
especificou-se um switch local para cada pacote, reunindo dados de todos os CLPs e
controladores do equipamento e enviando-os ao switch da unidade.
3.4.6: Rede de manutenção
A fim de facilitar a configuração dos CLPs e controladores que não possuem
uma estação de engenharia própria, especificou-se uma rede local de manutenção
(RMN), mostrada na figura 3.10. Esta rede interliga dispositivos através de um switch
e permite que um computador portátil seja usado para realizar configuração ou manu-
tenção.
3.4.7: Analisadores
Analisadores são instrumentos utilizados para a medição de variáveis não ele-
mentares do processo, tais como a composição de uma mistura, pH, condutividade,
densidade e viscosidade. Estes instrumentos podem ter função meramente supervi-
sória ou podem ser utilizados em malhas de controle e em otimização [2].
Os analisadores podem ser classificados quanto à localização em dois tipos:
62
Figura 3.9: Arquitetura do sistema SOE
Figura 3.10: Arquitetura da rede RMN
63
analisadores in situ, nos quais os sensores operam diretamente no processo, e os
extrativos, nos quais a amostra é retirada por meio de uma sonda, condicionada e
levada até o instrumento. A possibilidade de instalação in situ limita-se a a alguns
poucos casos, sendo usual nos analisadores de pH, condutividade e nos analisadores
de combustão.
A instalação in situ tem menor custo e proporciona melhor tempo de resposta e
fidelidade. Em muitos casos, porém, a natureza dos sensores e fatores como pressão,
temperatura, corrosão, umidade e sujeira impossibilitam a montagem do sensor no
processo, exigindo o pré-tratamento ou condicionamento da amostra. Neste caso, é
comum localizar o analisador em um “abrigo” (shelter ) ou em uma “casa” (analiser
house).
O sistema de condicionamento de amostras é constituído por diversos compo-
nentes, tais como válvulas, transmissores, bombas, aquecedores e resfriadores. O
controle destes sistemas pode ser feito tanto pelo próprio analisador quanto por um
CLP externo.
3.4.7.1: Analisadores de processo
Independentemente da finalidade do analisador (se é utilizado para controle ou
supervisão), o instrumento deve enviar ao SDCD informações de interesse do pro-
cesso, a fim de permitir o controle ou a simples supervisão de parâmetros.
O envio de dados de controle ao SDCD é feito através de sinais analógicos
4 − 20 mA ou (preferencialmente) através do protocolo Foundation Fieldbus. Já os
dados de supervisão podem ser enviados ao SDCD através de sinais 4−20 mA (menos
comum) ou protocolos de comunicação como Modbus-RTU, Modbus-TCP ou OPC-DA.
Além disso, todos os analisadores devem estar conectados a um sistema de
aquisição de dados e manutenção (AMDAS – Analyzer Maintenance and Data Ac-
quisition System) localizado no CIC. Este sistema provê ferramentas para facilitar a
configuração, manutenção dos instrumentos e validação dos dados adquiridos.
O AMDAS é constituído por um servidor no CIC onde se encontra um aplica-
tivo para tratamento de dados e manutenção. Este servidor pode obter dados de
supervisão tanto diretamente do analisador (se este possuir um servidor OPC) quanto
indiretamente através do servidor OPC do SDCD.
Com base nos requisitos apresentados, elaboraram-se 3 arquiteturas diferentes64
Figura 3.11: Analisadores - arquitetura 1
para os analisadores, mostradas nas figuras 3.11 a 3.13, respectivamente.
Na primeira arquitetura (figura 3.11), o analisador em questão é utilizado para
controle de processos. Ele envia as variáveis de análise para o SDCD através de
sinais 4 − 20 mA ou através do protocolo FF. Além disso, o analisador comunica-se
com o sistema AMDAS através de uma rede Ethernet e protocolo OPC-DA (tendo o
analisador um servidor OPC).
Na segunda arquitetura (figura 3.12), o analisador também é utilizado para con-
trole e envia variáveis de processo ao SDCD da mesma maneira que na arquitetura 1
(via sinais 4 − 20 mA ou FF). Porém, o analisador não possui um servidor OPC para
disponibilizar informações ao AMDAS. Desta forma, utiliza-se um CLP (sistema inter-
mediário) para fazer a aquisição destes dados - via protocolo Modbus-RTU, Modbus-
TCP, HART ou mesmo via sinais 4− 20 mA - e disponibilizá-los ao AMDAS através de
OPC-DA.
Por último, na terceira arquitetura (figura 3.13), tem-se um cenário com ana-
lisadores de multicomponentes que não são utilizado para controle e por isso não
suportam FF (como por exemplo cromatógrafos). Neste caso, enviam-se os dados
de interesse ao SDCD via OPC-DA. O AMDA consegue então acessá-los através do
65
Figura 3.12: Analisadores - arquitetura 2
Figura 3.13: Analisadores - arquitetura 3
66
servidor OPC do SDCD.
3.4.7.2: Sistema de monitoramento de emissões
O sistema de monitoramento contínuo de emissões – CEMS (Continuous Emis-
sion Monitoring System) possui como finalidade monitorar gases tóxicos originados
em fornos, queimadores e caldeiras e que são emitidos na atmosfera. O CEMS é
constituído por analisadores e por um sistema de condicionamento de amostras.
O condicionamento de amostras é feito por um CLP independente localizado na
casa de analisadores. Este sistema de gerenciamento é denominado ASM (Analyzer
System Manager ).
A figura 3.14 mostra a arquitetura para o CEMS. Observa-se a presença dos
analisadores in situ e analisadores localizados na casa comunicando-se com o CLP
de ASM através do protocolo Modbus-TCP. O ASM, por sua vez, envia dados ao SDCD
também via Modbus-TCP. Estes dados podem ser acessados pelo AMDAS através de
um servidor OPC.
Na arquitetura proposta, representaram-se apenas os analisadores e o ASM,
sendo omitidos os instrumentos e equipamentos pertencentes ao sistema de condici-
onamento de amostras.
3.4.8: Fornos a chama
O forno industrial é um dos principais equipamentos de fornecimento de calor
para as diversas correntes de uma planta industrial. Sua função, em alguns processos,
vai além da complementação de calor para fins de condicionamento da temperatura
da carga que alimenta as torres de fracionamento ou os reatores; viabiliza também
processos de craqueamento térmico, atuando, por exemplo, como os próprios reatores
em unidades de coqueamento retardado, unidades de geração de hidrogênio e de
produção de eteno [4].
Os fornos industriais podem ser divididos em duas categorias quanto à fonte de
calor: fornos a chama e fornos elétricos.
A figura 3.15 mostra a arquitetura de automação pré-detalhada de um forno a
chama.
Para a implementação das funções de segurança, especificou-se de um PES67
Figura 3.14: Arquitetura do CEMS
dedicado para forno, independente do PES da unidade. Isso porque, além de ser
um equipamento crítico, o forno é o equipamento que mais possui instrumentos. O
controle do forno (temperatura de saída do produto, vazões de cada passe, pressão
interna, pressão dos queimadores, dentre outros), por sua vez, é executado no SDCD.
Os instrumentos destinados ao controle são do tipo Foundation Fieldbus, en-
quanto que instrumentos relacionados ao sistema instrumentado de segurança são
do tipo 4− 20mA + HART (analógicos) ou 0− 24 V cc (digitais).
Especificou-se ainda que cada forno deve possuir um painel local com IHM.
Através deste painel, o operador executa comandos de abertura e fechamento de
válvulas de óleo, desligamento manual do forno e executa o comando de permissão
para partida do equipamento. Informações como status de purga, status de testes de
vazamento são mostrados na IHM.
Todos os comandos do LP devem ser enviados ao PES do forno através de de
comunicação não protocolada (hardwired). Por outro lado, a comunicação entre a IHM
e o PES do forno é feita via protocolo Modbus-TCP.
68
3.4.8.1: Comunicação com outros sistemas
Mensagens de status e alarmes são enviados do PES do forno ao SDCD atra-
vés de comunicação redundante via protocolo Modbus-TCP. Os sinais de parada de
emergência são enviados do SDCD ao PES da unidade através de comunicação não
protocolada.
Como o PES do forno gera alarmes e intertravamentos, ele deve ser conectado
ao sistema de sequenciamento de eventos (SOE), sendo a comunicação realizada
através de uma porta Ethernet e através do protocolo OPC-UA ou OPC-E&A.
Os instrumentos 4 − 20 mA + HART, utilizados para execução de lógicas de
intertravamento, são conectados ao sistema de gerenciamento de ativos (AMS).
Observa-se que o PES do forno está conectado a duas redes distintas do SIS:
uma rede interligada à sala de automação - conectada a uma estação de engenharia
- e outra interligada à sala de servidores de E/S. Estas duas redes fazem parte do
sistema instrumentado de segurança (SIS) e são explicadas na seção 3.4.2.
3.4.9: Máquinas de grande porte
Nesta seção discutem-se as arquiteturas de automação desenvolvidas para as
principais máquinas de grande porte presentes nas unidades de processo do com-
plexo petroquímico. Para a elaboração destas arquiteturas, utilizou-se como base os
conceitos apresentados na seção 2.3, além dos critérios de automação e instrumen-
tação do projeto.
Ao invés de apresentar a arquitetura epecífica de cada equipamento, será apre-
sentada uma arquitetura de uma máquina genérica. Esta arquitetura contempla os
requisitos e as comunicações com outros sistemas do complexo, e foi utilizada como
base para o desenvolvimento de arquiteturas de máquinas específicas.
3.4.9.1: Arquitetura genérica
A figura 3.16 mostra a arquitetura genérica desenvolvida para máquinas de
grande porte. Esta arquitetura contempla os 4 principais sistemas das grandes máqui-
nas, apresentados na seção 2.3:
• subsistema de óleo de lubrificação e comando;69
Figura 3.15: Arquitetura de um forno a chama
70
• subsistema de intertravamento;
• subsistema de controle de velocidade /capacidade (se aplicável);
• subsistema de monitoramento.
O sistema de óleo e lubrificação é constituído por instrumentos transmissores
e válvulas 4 − 20 mA + HART e instrumentos digitais 0 − 24 V cc. Na arquitetura,
representou-se estes instrumentos de forma genérica, como entradas e saídas (E/S)
analógicas e discretas para o CLP da máquina.
O sistema de intertravamento é constituído por um CLP e instrumentos (também
enquadrados nas E/S genéricas). Os sinais de desligamento de emergência são envi-
ados ou recebidos do PES por meio de comunicação não protocolada (hardwired). Já
os sinais de alarmes e status são enviados ao SDCD via comunicação Modbus-TCP.
A detecção de sobrevelocidade é feita por um equipamento separado. No caso
deste sistema detectar velocidade excessiva da máquina, um sinal 0− 24 V cc de des-
ligamento de emergência é enviado ao CLP e ao PES, a fim de que estes possam
realizar os devidos intertravamentos de segurança.
O controle de velocidade ou capacidade da máquina pode ser feito tanto por
um controlador dedicando quanto pelo próprio CLP da máquina. Nesta fase de pré-
detalhamento, considerou-se que o controle de velocidade ou capacidade é feito por
um controlador dedicado, que envia e recebe sinais analógicos de sensores e atuado-
res na planta e comunica-se com o CLP do pacote e demais sistemas da unidade.
Este controlador recebe a referência (setpoint) de velocidade do SDCD, através
de um sinal 4 − 20 mA, lê variáveis do processo e realiza atuação; a variável de
processo é realimentada ao SDCD também via sinal 4− 20 mA. Além disso, há troca
sinais de status e alarmes com o CLP da máquina e diretamente com o SDCD através
do protocolo Modbus-TCP.
Conforme discutido na seção 2.3, existem basicamente dois tipos de sistemas
de monitoramento: monitoramento contínuo (figura 2.5) ou por varredura (figura 2.6).
O tipo de sistema a ser utilizado depende da criticidade da máquina e de característi-
cas mecânicas tais como o tipo de mancal de rolamento.
O CLP de intertravamento e o sistema de sobrevelocidade comunicam-se com
a rede SOE através de uma porta Ethernet. Os instrumentos analógicos, bem como o
sistema de monitoramento, devem estar conectados com a rede de gerenciamento de71
Figura 3.16: Arquitetura de uma máquina rotativa genérica
72
ativos (AMS) através de um multiplexador HART e de umconversor EIA-485/Ethernet.
Além disso, o CLP e controladores são ligados a uma rede Ethernet para fins de
manutenção remota (seção 3.4.6).
3.4.10: Automação e proteção do sistema elétrico
O PASE (proteção e automação do sistema elétrico) possui como objetivo mo-
nitorar variáveis do sistema elétrico e integrá-lo com o sistema de controle e intertra-
vamento do processo.
O PASE é formando basicamente por duas redes de gerenciamento de informa-
ções: uma que interliga os dispositivos elétricos ao SDCD e outra que coleta dados
de dispositivos elétricos inteligentes (IEDs - Intelligent Electronic Device). A gerência
da rede elétrica possui os seguintes objetivos:
• Prover, de forma confiável a atualizada, dados de status dos principais sistemas
elétricos e de geração;
• Identificar problemas elétricos antes que falhas ocorram;
• Permitir a realização de auditorias automatizadas da qualidade da sistema elé-
trico, através de relatórios que determinam de forma precisa causas de falhas e
possíveis medidas preventivas.
A figura 3.17 mostra a arquitetura desenvolvida para o PASE. Nela observam-se
os principais equipamentos do sistema elétrico.
O RUPS (Redundant Uninterruptable Power Supply ) é o sistema responsável
pela alimentação contínua da unidade, possuindo associado a ele um banco de bate-
rias.
Os CCMs (centro de controle de motores) são painéis elétricos de baixa tensão
(480 V ) responsáveis pela alimentação de motores com potência até 55 kW , conver-
sores de frequência com saída nominal de corrente até de 100 A e RUPSs de potência
até 75 kV A.
O CDC de baixa tensão (480 V ) é responsável por alimentar os CCMs de 480 V ,
motores com potência acima de 55 kW até 110 kW e conversores de frequência com
corrente nominal acima de 100 A até 400 A.
73
Figura 3.17: Arquitetura do PASE
74
O CDC de tensão 4, 16 kV alimenta motores com potência acima 110 kW até
2000 kW e conversores de frequência com potência acima de 330 kW e até 4000 kW .
Tanto o CCM quanto o CDC são possuem gavetas denominadas IEDs (Inteligent
Electronic Devices). Estas gavetas são dispositivos microprocessados que permitem o
fechamento e abertura do circuito de alimentação de forma remota; permitem também
o monitoramento de variáveis de estado, tais como tensão, corrente, potência ativa,
dentre outras.
Todos os conversores de frequência (VSD - Variable Speed Driver ) são agru-
pados em painéis localizados na subestação, evitando-se a presença destes equipa-
mentos no campo.
Na arquitetura desenvolvida, representaram-se os sistemas elétricos com a fi-
nalidade de mostrar sua interface com o sistema de controle e automação da unidade;
detalhas das conexões elétricas e do sistema elétrico não foram mostrados. De ma-
neira apenas ilustrativa, ligaram-se os motores de compressores e bombas de grande
porte no CDC, sem no entanto realizar antes um levantamento da potência e tensão
destes equipamentos.
3.4.10.1: Acionamento de motores
Os motores elétricos das unidades de processo podem ser partidos, de ma-
neira geral, de duas formas: (i) no campo, através um botão de partida conectado
diretamente ao CDC, CCM ou VSD ou (ii) remotamente a partir da interface do SDCD.
Como requisito de projeto, todos os motores devem ser capazes de serem partidos via
SDCD.
O comando de partida e parada é enviado do SDCD ao CCM, CDC ou VSD
através de uma rede Profibus-DP. Esta rede também é responsável por transmitir o
estado (ligado ou desligado) do motor. No caso de motores de velocidade variável, a
referência (setpoint) de velocidade é enviado do SDCD ao VSD através de um sinal
4− 20 mA. Da mesma forma, o sinal de realimentação é enviado do VSD ao SDCD.
Equipamentos de grande porte, como compressores, devem ser partidos so-
mente a partir do SDCD. Entretanto, para que a partida remota possa ser realizada,
é necessário que um operador vá até o local do equipamento, verifique suas condi-
ções e então efetue um comando de “permissão para partida”. Este comando é feito
através de um botão físico localizado em um painel local, próximo ao equipamento. A
75
permissão é comunicada então ao CLP do equipamento através de um sinal 0−24 V cc
e ao SDCD através de comunicação digital em rede.
Após a permissão de partida, o comando é inicialmente enviado do SDCD ao
CLP do equipamento através de um sinal 0 − 24 V cc. Estando o equipamento em
condições de operar, o CLP envia então o comando ao CDC ou CCM através de um
sinal 120 V ca, tensão especificada para o comando das gavetas dos painéis elétricos.
A parada de emergência (trip) de motores elétricos é feita através de um sinal
120 V ca enviado pelo CLP do equipamento à gaveta ou então enviado diretamente
pelo PES unidade, caso o equipamento não possua CLP dedicado. É importante
observar que uma parada de emergência pode se originar de três locais: do LP do
equipamento, da interface SDCD, de uma lógica do CLP ou ainda de uma lógica do
PES da unidade.
3.5: Arquitetura geral
Após desenvolver a arquitetura dos sistemas que estão presentes em todas as
unidades, elaborou-se então a arquitetura de unidade de processo genérico, contem-
plando a comunicação entre todos os sistemas. Nesta arquitetura genérica não foram
representados sistemas particulares, como por exemplo o painel remoto (RCP) de
compressores.
A arquitetura desenvolvida, mostrada na figura 3.18, é dividade em três partes:
campo, CCL e CIC. No campo encontram-se os instrumentos e equipamentos da uni-
dade, tais como válvulas, transmissores, compressores, bombas e fornos. Na CCL
encontram-se os equipamentos de automação da unidade (SDCD, PES, RCPs, etc).
O CIC é representado apenas para mostrar as interfaces dos sistemas presentes na
CCL.
Organizou-se de forma separada as comunicações de intertravamentos e co-
municações de alarmes e status. As comunicações de intertravamento, realizadas
através de sinais físicos (hardwired) e entre painéis de rearranjo do SDCD, PES e
PES de fornos, foram representados em um nível inferior. Já as comunicações de
status e alarmes, feitas através de comunicação em rede, foram representados em
um nível superior do desenho. Esta separação entre os tipos de sinais permite uma
melhor organização e entendimento da arquitetura.
76
Figura 3.18: Arquitetura de automação de uma unidade de processo genérica
77
3.5.1: Comunicações não protocoladas
A figura 3.19 mostra as principais comunicações de intertravamentos entre os
sistemas de uma unidade de processo. Na figura, representaram-se os sinais com a
direção da comunicação e com o tipo do sinal (4 20 mA, 0 − 24V cc ou 0 − 120V ca).
Sinais com a mesma direção e mesmo tipo foram agrupados para simplificar a repre-
sentação.
Conforme discutido na seção 3.4.10, o SDCD é o responsável pela partida e
parada em condições normais de todos os equipamentos da unidade. Quando o equi-
pamento possui um CLP para controle e intertravamento, o sinal de partida e parada
do equipamento é enviado através de uma comunicação física digital.
O SDCD possui em seus sinópticos chaves para a parada de emergência dos
equipamentos (fornos, compressores, turbinas). Quando uma chave desta é acionada,
um sinal de parada de emergência é enviado ao PES e este por sua vez envia o
comando de parada ao equipamento.
Numa situação de emergência, além de parar o equipamento solicitado, o PES
deve realizar outros intertravamentos necessários para manter a segurança do pro-
cesso. Além disso, o PES monitora também o processo e pode realizar paradas de
emergência de equipamentos sem a intervenção do SDCD.
Numa situação de presença de fogo ou vazamento de gás, os sistemas de F&G
e F&GBA enviam ao PES sinais que causam desligamentos de emergência, conforme
explicado na seção 3.4.3.
3.5.2: Comunicações em rede
A figura 3.20 mostra um esquemático das comunicações seriais presentes na
arquitetura geral pré-detalhada. O protocolo da comunicação não foi representado.
É importante ressaltar que, embora a rigor todas as comunicações Ethernet são em
geral bidirecionais, representou-se no diagrama o sentido do fluxo da informação final,
do ponto de vista da aplicação.
A troca de status e alarmes entre os principais controladores da unidade -
SDCD, PES, sistema de F&G e F&GBA – é feita através de switches Ethernet re-
dundantes e interligados. Optou-se por utilizar um switch ao invés de ligações ponto-
a-ponto a fim de reduzir o número de portas Ethernet necessárias em cada sistema.
78
Figura 3.19: Comunicações não-protocoladas
79
Entretanto, foi solicitado pelo Cliente que a ligação entre o SDCD e os pacotes, in-
cluindo os fornos a chama, fossem mantidas ponto-a-ponto.
O protocolo utilizado para a troca de status e alarmes foi o Modbus-TCP (2.4.3.5).
Atualmente, o Modbus é o protocolo mais utilizado para integração de dispositivos de
automação. Além disso, o Modbus-TCP permite, além do baixo custo da rede Ether-
net, maior facilidade de integração com as redes locais.
O switch RMN interliga os principais CLP de sistemas a uma rede de manuten-
ção, permitindo que a partir deste switch os dispositivos sejam acessados e configu-
rados através de uma estação de engenharia (veja seção 3.4.6).
O swtich do sistema AMS conecta os instrumentos analógicos com capacidade
HART dos RCPs, do PES da unidade e do PES do forno, conforme explicado na seção
3.4.4.
O switch SOE conecta todos os sistemas que geram alarmes ou intertravamen-
tos ao sistema de sequenciamento de eventos, conforme explicado na seção 3.4.5.
3.6: Arquiteturas especificas
Após a elaboração de arquiteturas dos sistemas que são geralmente presen-
tes em todas as unidades de processo (SDCD, SIS, AMS, SOE, RMN, F&G, F&GBA,
analisadores), detalharam-se então os sistemas e equipamentos específicos para uni-
dades particulares.
Como exemplo de arquitetura específica desenvolvida, será apresentada a ar-
quitetura de automação de um conjunto turboexpansor-gerador presente na unidade
de craqueamento catalítico em leito fluidizado (FCC – Fluidic Catalytic Cracking) do
complexo petroquímico.
Para a elaboração desta arquitetura, fez-se um estudo sobre o sistema de con-
trole de um turboexpansor-compressor e materiais do projeto básico. Além disso,
alguns integrantes da equipe realizaram uma visita técnica a uma unidade de FCC a
fim de esclarecer dúvidas.
80
Figura 3.20: Comunicações em rede
81
Figura 3.21: Turboexpansor em uma unidade de FCC - Extraído de [4]
3.6.1: Turboexpansor acionando um gerador elétrico
3.6.1.1: Introdução
Na unidade de craqueamento catalítico em leito fluidizado, uma carga de hidro-
carbonetos pesados é convertido em produtos mais leves e nobres, como a gasolina e
o GLP, em um reator pela ação de um catalisador fluidizado aquecido. Um subproduto
da reação é o coque que se deposita no catalisador. Este catalisador é enviado para
um regenerador, onde o coque é queimado de forma controlada com ar comprimido.
Os gases de combustão deste regenerador tem uma grande vazão, alta temperatura
e uma pressão manométrica em torno de 2, 5 kgf/cm2. Atualmente, coloca-se um
turboexpansor para realizar trabalho e movimentar um gerador de energia elétrica an-
tes de enviar os gases de combustão para uma caldeira [4]. A figura 3.21 mostra um
turboexpansor de uma unidade de FCC.
3.6.1.2: Instrumentação e controle
O diagrama de processo e instrumentação (P&ID) da figura 3.22 mostra um
esquema de controle simplificado do turboexpansor acionando um gerador elétrico
da unidade de FCC. Representou-se nesta figura o regenerador de catalisador, o se-
parador (que separa restos do catalisador) e as válvulas principais utilizadas para o
controle do conjunto turboexpansor-gerador.
Quando o turboexpansor está em operação, controla-se o diferencial de pressão
através da manipulação em split-range de 3 válvulas principais: válvula de admissão
82
Figura 3.22: Diagrama P&ID simplificado do turboexpansor
83
de gases no turboexpansor (PDV-001), válvula de grande bypass (PDV-002), e válvula
de trim bypass (PDV-002).
Em condições normais de operação, e em regime permanente, o controle de
pressão é feito somente pela válvula de admissão do turboexpansor (PDV-001). Caso
ocorra uma perturbação muito grande, como por exemplo a parada da máquina, a
pressão passa a ser controlada a partir da válvula de grande bypass (PDV-002). A
válvula de trim-bypass só é utilizada durante a partida da máquina. Uma característica
necessária para estas válvulas é a rápida atuação (resposta máxima em torno de
1s), pois se ocorre uma quebra do acoplamento turboexpansor-gerador, a rotação do
turboexpansor é acelerada de forma brusca.
A válvula de admissão (PDV-001) e a válvula de trim bypass (PDV-002) são
controladas a partir de um CLP dedicado para o para o turboexpansor, que por sua vez
recebe a referência de setpoint de pressão do SDCD. Já a válvula de grande bypass
pode ser controlada tanto pelo CLP quando pelo SDCD. Esta última forma de operação
ocorre em caso de falha do CLP, por exemplo, e pode se acionada automaticamente
ou manualmente através de uma chave lógica implementada na interface do SDCD.
Por se tratar de um chaveamento crítico, esta operação de troca de controle
entre SDCD e CLP é coordenada pelo PES da unidade, que compara o sinal dos dois
sistemas e define qual deles será enviado à válvula.
No caso do complexo petroquímico deste trabalho, foram especificadas, além
das válvulas de grande bypass e trim bypass, uma válvula de tamanho menor (PDV-
003) (small bypass) atuando em split range com válvula de grande bypass.
Além destas 3 válvulas principais, fazem parte do pacote do turboexpansor vál-
vulas de isolamento (HV-001 e XV-002) e uma válvula de parada de emergência (XV-
001).
3.6.1.3: Arquitetura de automação
A figura 3.23 mostra a arquitetura de automação pré-detalhada para os 2 tur-
boexpansores (idênticos e com a mesma função) da unidade de FCC do complexo pe-
troquímico deste trabalho. Definiu-se que todo o sistema de automação do turboexpansor-
gerador, bem como os painéis de controle do gerador, ficariam localizados em uma
casa de controle localizada no campo.
A arquitetura de automação do turboexpansor foi definida com base na arquite-84
Figura 3.23: Arquitetura dos turboexpansores
85
tura de máquina genérica apresentada na seção 3.4.9 e com base na documentação
do projeto. O sistema consiste em um CLP, painel de controle localizado na sala e
no campo, um subsistema de sobrevelocidade e um subsistema de monitoramento.
O CLP é responsável por acionar as válvulas principais do turboexpansor e também
por controlar os sistemas auxiliares. Além disso, especificou-se um painel de controle
próprio para o gerador, contendo informações sobre a geração de energia. As co-
municações entre estes sistemas (painéis, CLP, sistema de sobrevelocidade, sistema
de monitoramento) e suas interfaces com sistemas da unidade (SDCD, AMS, SOE,
RMN) foram especificadas seguindo a arquitetura genérica de máquina apresentada
na seção 3.4.9, figura 3.16.
Na arquitetura, observa-se que o CLP do turboexpansor recebe a referência
(setpoint) de pressão do SDCD. A partir de medidores de pressão, o CLP calcula então
a referência setpoint de posição da válvula de admissão e o envia para a unidade de
controle desta válvula. Todas as válvulas de controle do turboexpansor são do tipo
eletro-hidráulica, e possuem uma unidade de acionamento e controle própria, com
CLP, painel de operação e IHM.
As válvulas grande e pequeno bypass são comandadas, conforme discutido
anteriormente, pelo PES da unidade, o qual seleciona o sinal do CLP ou do SDCD.
Por isso, é necessário que o CLP do turboexpansor envie o sinal de referência setpoint
destas válvulas ao PES da unidade. Além disso, como pode ocorrer do controle ter
que ser assumido pelo SDCD, para que não ocorra uma mudança abrupta ao chavear
os sistemas, é necessário que o SDCD receba continuamente o valor de referência
setpoint destas válvulas, calculado pelo CLP.
Para que o turboexpansor possa ser partido, é necessário que as válvulas de
isolamento (comandadas somente a partir de seu painel local) estejam totalmente
abertas. Esta informação de posição é disponibilizada pelo CLP das válvulas de iso-
lamento ao CLP do turboexpansor através de um sinal 4 − 20 mA. Além disso, estas
válvulas só podem ser operadas se o turboexpansor estiver parado. Por isso, um sinal
de 0− 24 V cc de status de operação é enviado a elas pelo CLP do turboexpansor.
86
Capítulo 4: Resultados
Neste capítulo são apresentados e discutidos os resultados do trabalho. Discutem-
se os documentos de arquiteturas elaborados para as unidade de processo e as me-
lhorias que o trabalho trouxe ao projeto FEED do complexo petroquímico.
4.1: Documentos de arquiteturas
O objetivo final deste trabalho visava a elaboração de documentos de arquite-
turas de automação para unidades de proceso do complexo petroquímico. Ao todo,
foram elaborados documentos para 27 unidades de processo, cujos projetos FEED
são de responsabilidade da Chemtech.
A figura 4.1 mostra a visão geral e o nível de detalhamento de um documento
gerado para uma unidade de processo do complexo petroquímico.
Os documentos de arquitetura foram elaborados utilizando-se um aplicativo
CAD (Computer Aided Engineering). A partir do estudo da complexidade das uni-
dades, definiu-se que os documentos seriam feitos em folhas de tamanho A1 ou A0,
dependendo da unidade.
O ciclo de vida de um documento possui três fases: elaboração, verificação
e aprovação. A fase de elaboração, como o nome sugere, consiste na criação do
documento. A fase de verificação tem por objetivo fazer uma análise minuciosa do do-
cumento, tanto em termo técnicos quanto em termos de apresentação do documento;
esta etapa é feita geralmente por um engenheiro com maior experiência. Por último,
a etapa de aprovação possui como objetivo analisar o documento de forma geral (e
não minuciosamente), levando-se em consideração critérios do projeto como um todo;
esta etapa é realizada por uma pessoa com grande experiência técnica e experiência
no projeto.
Por tratar-se de um projeto de grande porte e com milhares de documentos
produzidos, a gerência da documentação é feita com o auxílio de um aplicativo de
gerenciamento eletrônico de documentos (GED). Este aplicativo é responsável pelo
armazenamento do documento, controle de versões, fluxos de trabalho, dentre outros.
Com estas informações, além de melhor organizar o projeto, é possível gerar infor-
87
Figura 4.1: Documento de arquitetura de automação
88
mações úteis para a gerência, como por exemplo quais documentos demandam mais
tempo de elaboração.
4.1.1: Metodologia de elaboração
A fim de desenvolver o trabalho, definiu-se uma metodologia para a elaboração
dos documentos de arquitetura de automação. Inicialmente, fez-se uma pesquisa das
simbologias de equipamentos e sinais geralmente usados em projetos de automação,
tendo como referência outros projetos desenvolvidos pela Chemtech. Criou-se en-
tão uma biblioteca CAD com esta simbologia, constituída por representação de CLPs,
controladores, switches, entre outros. Esta biblioteca permitiu a padronização da re-
presentações utilizadas durante o projeto.
A partir do desenvolvimento da arquitetura de uma unidade de processo ge-
nérica, apresentada na seção 3.5, criou-se um modelo de documento padrão. Este
modelo foi utilizado como base para a elaboração das arquiteturas das unidades, per-
mitindo assim uma padronização dos documentos.
Uma vez criado o modelo genérico de documento, já contendo a arquitetura pré-
detalhada dos principais equipamentos, o procedimento definido para a elaboração de
um documento de arquitetura pode ser resumido nos seguintes passos:
1. Levantamento dos equipamentos principais da unidade e identificação dos sis-
temas de automação. Para esta etapa, criou-se uma planilha padrão para ser
utilizada em cada unidade;
2. Estudo e pré-detalhamento dos equipamentos e sistemas de automação espe-
cíficos da unidade em questão. Nesta etapa, documentos sobre o equipamento
são analisados, bibliografias levantadas e dúvidas discutidas com consultores
e/ou com o cliente;
3. Levantamento de outras informações pertinentes à unidade e necessárias à ela-
boração do documento, como por exemplo qual subestação elétrica alimentará
os equipamentos;
4. Elaboração, verificação e aprovação do documento.
A fim de documentar, padronizar e auxiliar o procedimento de elaboração e ve-
rificação de arquiteturas de automação, criou-se um manual de execução contendo89
informações técnicas para a elaboração destes documentos. Este manual foi criado
para que que novos engenheiros que começassem a trabalhar com arquiteturas de
automação pudessem entender os objetivos do documento e a metodologia de exe-
cução, além de apresentar os conceitos técnicos fundamentais. Além disso, o manual
estabeleceu uma metodologia que pode ser utilizada em projetos futuros.
4.2: Melhorias no projeto FEED
O projeto de arquiteturas de automação para as unidades de processo possibi-
litou diversas melhorias no projeto FEED do complexo.
Na disciplina de instrumentação, as arquiteturas foram utilizadas como refe-
rência para a elaboração de listas de entradas e saídas (E/S) e listas de portas de
comunicação do SDCD e PES. Além disso, o estudo em um nível mais aprofundado
dos sistemas de automação das unidade contribuiu para a melhoria das atividades de
análise de consistência.
O trabalho permitiu também a identificação de inconsistências nas folhas de
dados de equipamentos elaboradas pela disciplina de máquinas, sobretudo nos dados
relativos à instrumentação e automação.
Por fim, o trabalho permitiu uma maior integração ente as disciplinas de instru-
mentação, mecânica/máquinas e elétrica. Para o projeto de pré-detalhamento dos
sistemas de automação, foi necessário diversas vezes o esclarecimento e troca de
informações sobre os equipamentos elétricos e mecânicos com as respectivas disci-
plinas. O projeto do sistema do turboexpansor-gerador, por exemplo, no tocante às
interfaces do sistema de automação com o sistema de geração, foi feito em conjunto
com a disciplina de elétrica.
90
Capítulo 5: Conclusões e perspectivas
Este trabalho apresentou o pré-detalhamento das arquiteturas de automação
das unidades de processo de um complexo petroquímico. Inicialmente, realizou-se
um estudo sobre os principais sistemas de controle e automação atualmente utiliza-
dos em uma refinaria. Desenvolveu-se então o trabalho através do levantamento dos
requisitos, elaboração de uma arquitetura conceitual, pré-detalhamento das arquitetu-
ras de equipamentos gerais e pré-detalhamento das arquiteturas específicas.
Como resultado do trabalho, foram elaborados documentos para 27 unidades de
processo do complexo petroquímico. Além disso, foi desenvolvida e documentada uma
metodologia para elaboração destes tipos de documentos, a qual pode ser utilizada
em projetos futuros da empresa.
Em relação ao projeto de FEED do complexo petroquímico, pôde-se perceber
a importância de um projeto de pré-detalhamento em um empreendimento de grande
porte. Além do objetivo principal de possibilitar uma melhor estimativa de custos do
empreendimento, permitindo a análise de sua viabilidade e um parâmetro de custo na
hora de contratar uma empresa de EPC, o projeto de FEED permite antecipar diversos
problemas da etapa de detalhamento que poderiam prolongar o início da operação das
unidades, como por exemplo a especificação e encomenda de máquinas críticas.
Constatou-se que uma dificuldade no projeto FEED é determinar o grau de de-
talhamento necessário nesta etapa. Se por um lado quanto mais detalhado o projeto
melhor a acuracidade dos quantitativos, por outro lado o projeto de FEED tem por
objetivo ser uma etapa rápida e com baixo custo em relação às outras.
Também pôde-se vivenciar todas as dificuldades encontradas em um projeto de
grande porte. O projeto de FEED do complexo possuía em torno de 400 funcioná-
rios, divididos em 20 disciplinas; a disciplina de instrumentação (onde realizou-se o
trabalho) contava com cerca de 40 funcionários. Questões como bom planejamento
de trabalho, treinamento constante, ferramentas adequadas, entrosamento, motivação
da equipe e diversidade desta (em formação e experiência) são fatores fundamentais
para o sucesso de um projeto deste porte.
Outrossim, comprovou-se a importância da documentação em um projeto de
engenharia. Percebeu-se que grande parte do tempo utilizado no projeto é gasto
91
apenas para entender um documento.
Finalmente, comprovou-se na prática que um projeto na área de automação é
bastante multidisciplinar e integrador. Durante a realização deste trabalho, foi neces-
sário o contato com temas de processos, segurança, mecânica, elétrica, comunicação
e qualidade de projetos. Além disso, constatou-se que cada vez mais a automação
está presente em todas as áreas. Como exemplo, se antes bastavam engenheiros
mecânicos para projetar ou especificar um compressor, bastavam engenheiros ele-
tricistas para projetar um sistema elétrico, ou ainda bastavam engenheiros químicos
para projetar um processo químico, atualmente o grau de controle e automação pre-
sente nestes três tipos de sistemas citados (dentre outros) justifica a participação de
um engenheiro de controle e automação em todas etapas de projeto e especificação.
5.1: Perspectivas
Espera-se que as arquiteturas desenvolvidas neste trabalho possam ser usadas
com sucesso para o projeto detalhado dos sistemas de automação do complexo pe-
troquímico. O projeto de detalhamento do complexo será feito juntamente com a etapa
de compra de materiais e construção, segundo a metodologia EPC (seção 1.4.1).
Por outro lado, são grandes as perspectivas de crescimento do setor petroquí-
mico no Brasil. Conforme dito na introdução, o projeto de novas refinarias está pre-
visto. Espera-se que este trabalho possa auxiliar projetos futuros da empresa e tam-
bém contribuir para a divulgação, no meio acadêmico e industrial, de conceitos e tec-
nologias de controle e automação utilizados na área de refino de petróleo.
92
Referências
[1] ALMEIDA, Cleiton M. de. Projeto de uma Unidade para Pesquisa de Medição
e Controle de Escoamento Multifásico. 2009. Relatório (Estágio em Controle e
Automação) - Departamento de Automação e Sistemas, Universidade Federal de
Santa Catarina, Florianópolis, 2009.
[2] BEGA, Egídio (Org.). Instrumentação Industrial. 1. ed. Rio de Janeiro: IBP,
2006.
[3] CAMPOS, Mário C. M. M. FILHO, Miguel J. B. Automação de grandes máqui-
nas: uma proposta de padronização para compressores dinâmicos. Rio de
Janeiro: Petrobras, 2006. (Boletim Técnico da Petrobras v. 49).
[4] CAMPOS, Mário C. M. M.; TEIXEIRA, Hebert. C. G. Controles Típicos de Equi-
pamentos e Processos Industriais. 1. ed. Rio de Janeiro: Egard Blücher, 2006
[5] CARO, Richard H. Automation Network Selection. 1. ed. North Carolina: ISA
Press, 2004.
[6] CHEDDIE, H. L. Safety Instrumented Systems: Design, Analysis and Operation.
In: LIPTÁK, Béla G. Instrument engineers’ handbook: process software and
digital networks. 3. ed. Noth Carolina: CRC Press, 2000.
[7] FILHO, Nelson C. Anteprojeto Industrial: Das Estratégias Empresariais à En-
genharia. 1995. Tese (Doutorado em Engenharia de Produção) - Departamento
de Produção e Sistemas, Universidade Federal de Santa Catarina, Florianópolis,
1995.
[8] INSTRUMENTATION, SYSTEMS AND AUTOMATION SOCIETY. ISA-95 -00.01-
2000: Enterprise-Control System Integration Part 1: Models and Termino-
logy. North Carolina, 2000.
[9] LUCCI, Felipe A.; CONCER, Gustavo M. SANTANA, Wanessa, A. F. A importân-
cia de um projeto de pré-detalhamento (FEED). Revista Controle & Instrumen-
tação, São Paulo, n. 37, 2009.
[10] PAGNANO, M. A de O. Gerenciamento de ativos na manutenção. Revista Meca-
trônica Atual, São Paulo, ed. 34, jun./jul. 2007.93
[11] ROHR, A. Sequence of Event Recorders and Post-Trip Reviwes. In: LIPTÁK, Béla
G. Instrument engineers’ handbook: process software and digital networks.
3. ed. Noth Carolina: CRC Press, 2000.
[12] STEMMER, Marcelo R. Sistemas Distribuídos e Redes de Computadores
para Controle e Automação Industrial. Florianópolis: [S.n], 2000. (Apostila da
disciplina Redes de Computadores para Controle e Automação Industrial, Curso
de Graduação em Engenharia de Controle e Automação, Universidade Federal
de Santa Catarina).
[13] WHITT, Michael D. Successful Instrumentation and Control Systems Design.
1. ed. NoRrth Carolina: ISA Press, 2004.
94
