InstrumentaçãoeAutomaçãoLaboratorial Cassel 2022

Universidade Federal do Rio Grande do Norte
Centro de Tecnologia - CT
Curso de Engenharia Mecatrônica
Instrumentação e Automação Laboratorial:

Projeto e Execução de Infraestrutura de
Controle de Sonda em Escala Real no Geowellex
TechCenter
Iago Pereira Cassel

Natal
2022
Iago Pereira Cassel
Instrumentação e Automação Laboratorial: Projeto e

Execução de Infraestrutura de Controle de Sonda em
Escala Real no Geowellex TechCenter
Trabalho de Conclusão de Curso apresentado

ao curso de Engenharia Mecatrônica da Uni-
versidade Federal do Rio Grande do Norte
como parte dos requisitos para a obtenção do
título de Engenheiro Mecatrônico, orientado
pelo Prof. Samaherni Morais Dias
Universidade Federal do Rio Grande do Norte (UFRN)

Centro de Tecnologia (CT)
Curso de Engenharia Mecatrônica
Orientador: Samaherni Morais Dias
Natal
2022
Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede
Cassel, Iago Pereira.

Instrumentação e Automação Laboratorial: Projeto e Execução de Infraestrutura de Controle de
Sonda em Escala Real no Geowellex TechCenter/ Iago Pereira Cassel. - 2022
72f.: il.
Monografia (Graduação) - Universidade Federal do Rio Grande do Norte, Centro de Tecnologia,

Engenharia Mecatrônica, Natal, 2022.
Orientador: Samaherni Morais Dias.
1. Plataforma de Perfuração - Monografia. 2. National Instruments - Monografia. 3. LabVIEW

- Monografia. 4. Atuação - Monografia. 5. Aquisição de dados - Monografia. I. Dias, Samaherni
Morais. II. Título.
RN/UF/BCZM CDU 004.4
Elaborado por Raimundo Muniz de Oliveira - CRB-15/429

Iago Pereira Cassel
Instrumentação e Automação Laboratorial: Projeto e

Execução de Infraestrutura de Controle de Sonda em
Escala Real no Geowellex TechCenter
Trabalho aprovado. Natal, 29 de julho de 2022:
Samaherni Morais Dias

Orientador
Kurios Iuri Pinheiro De Melo Queiroz

Avaliador interno
Joilson Batista De Almeida Rego

Avaliador interno
Natal
2022
Agradecimentos
À minha avó, Maria Selma da Câmara Lima Pereira, minha maior inspiração como
ser humano. Dona de um espírito caridoso, uma mente brilhante e um semblante terno.
Aos meus pais, Flávia Simone Lima Pereira e Alessandro Falleiro Cassel, que
compartilharam seus atos de motivação e carinho, desde de minha tenra idade. Par que
sempre acreditou na educação e cultura como elementos transformadores de vida para sua
prole.
Ao meu professor orientador Samaherni Morais Dias, por todas as oportunidades
por ele concebidas nas áreas de monitoria e pesquisa, além da sua dedicação ao ensido do
conhecimento teórico e prático de seus alunos.
À Antônio Carlos Brasileiro de Almeida Jobim, que em 1970 lançou seu álbum
Stone Flower pela gravadora CTI Records. Compostitor das melodias que preencheram
meus ambientes de estudo nos momentos de pesquisa e foco.
Aos meus amigos, por todos os sorrisos, risadas, desabafos e concelhos.
“Longa é a arte.
Tão breve a vida.”
(Antônio Carlos Jobim)
Resumo
Com o avanço da industria de extração do petróleo, desde a segunda metade do século
XIX até o dias atuais, tornou-se notório o potencial industrial, energético e econômico
do nomeado “ouro negro”. Assim, a comunidade industrial aperfeiçoou as técnicas de
perfuração e extração de poços produtivos e desenvolveu cada vez mais produtos derivados
de petróleo, afim de expandir seu potencial. Com o objetivo de desenvolver-se, a indústria
passou de poços onshore, para perfuração em ambientes marítimos de alto estresse aos
sistemas mecânicos e elétricos, em poços offshore. Tamanho o potencial econômico vislum-
brado pela indústria e o histórico do uso óleo, que erguemos plataformas de perfuração,
com equipamentos sofisticados e custosos, em ambientes que apresentam riscos expressivos.
Com o objetivo de garantir que tal investimento tenha uma base sólida de operação e
apresente as condições mínimas de planejamento, a indústria vem requisitando que suas
plataformas de perfuração sejam cada vez mais proativas nas tarefas de aquisição de
dados, controle e atuação de equipamentos. Este trabalho propõe um modelo de atuação e
aquisição de dados para plataforma de petróleo onshore, localizada na base TechCenter da
Geowellex do Brasil Serviços Petrolíferos LTDA, utilizando equipamentos proprietários da
National Instruments e programação em ambiente LabVIEW. Os resultados são obtidos
através da utilização do modelo na plataforma real de escala média presente na base, afim
de garantir a fidelidade da funcionalidade do modelo desenvolvido em um ambiente que
componha uma simulação mais próxima possível da realidade da indústria.
Palavras-chave: Plataforma de Perfuração; National Instruments; LabVIEW; Atuação;

Aquisição de dados;
Abstract
With the advance of the oil extraction industry, from the second half of the 19th century
to the present day, the industrial, energy and economic potential of the so-called “black
gold” became notorious. Thus, the industrial community has perfected the techniques
of drilling and extracting productive wells and has developed more and more petroleum
products in order to expand their potential. In order to develop, the industry has moved
from onshore wells, for drilling in high-stress marine environments to mechanical and
electrical systems, in offshore wells. Such is the economic potential envisioned by the
industry and the history of oil use, that we build drilling platforms, with sophisticated and
expensive equipment, in environments that present significant risks. With the objective of
guaranteeing that such investment has a solid base of operation and presents the minimum
planning conditions, the industry has been requesting that its drilling rigs be increasingly
proactive in the tasks of data acquisition, control and equipment performance. This work
proposes an action model and data acquisition for an oil platform onshore, located at the
base TechCenter of Geowellex do Brasil Serviços Petrolíferos LTDA, using proprietary
equipment from National Instruments and programming in LabVIEW environment. The
results are obtained through the use of the model in the real platform of medium scale
present in the base, in order to guarantee the fidelity of the functionality of the model
developed in an environment that composes a simulation as close as possible to the reality
of the industry.
Keywords: Drilling Platform; National Instruments; LabVIEW; Control; Data acquisi-

tion;
Lista de abreviaturas e siglas
UFRN Universidade Federal do Rio Grande do Norte
GLP Gás Liquefeito de Petróleo
cRIO CompactRIO
NI National Instruments
E/S Entrada/Saída
FIFO First In, First Out
IHM Interface Homem-Máquina
VI Virtual Instrument
QMH Queued Message Handling
EHL Event Handler Loop
MHL Message Handling Loop
SPSV Single Process Shared Variable
NPSV Network-Published Shared Variable
NF Normalmente Fechado
NA Normalmente Aberto
DO Digital Output
DI Digital Input
AI Analog Input
RT Sistema Real Time
IU Sistema de Interface de Usuário
RPM Rotações Por Minuto
PSI Pound Force per Square Inch
CSV Comma-Separated Values

Sumário
1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Revisão Bibliográfica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Visão geral dos capítulos seguintes . . . . . . . . . . . . . . . . . . . . . 13
2 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Instalação Mecânica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Elementos da Torre de Perfuração . . . . . . . . . . . . . . . . . . . . . 15
2.1.2 Elementos adjacentes à Torre de Perfuração . . . . . . . . . . . . . . . . 16
2.1.3 Elementos Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Instalação Elétrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1 Quadro dos Soft-Starters . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.2 Quadro do Inversor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.3 Quadro do cRIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Elementos de Operação e Sinalização . . . . . . . . . . . . . . . . . . . 27
3 Fundamentação teórica . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1 Arquitetura Combinacional de Circuitos Digitais . . . . . . . . . . . . . 29
3.1.1 Lógica da Álgebra Booleana . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.2 Propriedades da Álgebra Booleana . . . . . . . . . . . . . . . . . . . . . 32
3.2 Interpolação Polinomial . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 Arquitetura do Armazenamento FIFO . . . . . . . . . . . . . . . . . . . 33
3.4 Arquitetura de Software para LabVIEW . . . . . . . . . . . . . . . . . . 34
3.4.1 Queued Message Handling (QMH) . . . . . . . . . . . . . . . . . . . . . 34
3.4.2 Escopos de Variáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.2.1 Local Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.2.2 Global Variable (Single Process Shared Variable) . . . . . . . . . . . . . 37
3.4.2.3 Shared Variable Network-Published . . . . . . . . . . . . . . . . . . . . 37
3.4.3 Formatação e Tratamento de Erro . . . . . . . . . . . . . . . . . . . . . 38
4 Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1 Sistema Real Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.1 Inicialização do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.2 QMH do Sistema Real Time . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1.3 Bloco Lógico Combinacional do Guincho . . . . . . . . . . . . . . . . . 41
4.1.4 RPM da Bomba de Lama . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.5 Cálculo de movimentação vertical de tubos por Encoder . . . . . . . . . 46
4.1.6 Tratamento de erro e prevenção de falha . . . . . . . . . . . . . . . . . . 49
4.2 Sistema de Interface de Usuário . . . . . . . . . . . . . . . . . . . . . . 50
4.2.1 QMH da Interface de Usuário . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.2 Conexão com os elementos monitorados pelo sistema Real Time . . . . 51
4.2.3 Calibração dos Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.4 Armazenamento de parâmetros de calibração . . . . . . . . . . . . . . . 55
4.2.5 Criação de dataset de operação em CSV . . . . . . . . . . . . . . . . . . 58
4.2.6 Organização visual da IHM . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.6.1 Tela “Operar” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.6.2 Tela “Configurar” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1 Resultados do Sistema Real Time . . . . . . . . . . . . . . . . . . . . . 63
5.2 Resultados do Sistema IU . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.1 Conclusões acerca do projeto desenvolvido . . . . . . . . . . . . . . . . . 69
6.2 Planos futuros de expansão do sistema . . . . . . . . . . . . . . . . . . . 69
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
11
1 Introdução
1.1 Motivação
Durante o século XX o petróleo se consolidou como uma das commodities de
maior importância no mercado internacional. É através de derivados do petróleo de onde
é retirada a matéria prima para a elaboração de produtos globalmente consumidos em
larga escala. Dentre esses produtos, temos combustíveis automotivos, óleos lubrificantes,
gás liquefeito de petróleo (GLP), produtos asfálticos e produtos plásticos. Apesar da
exploração comercial do petróleo ter começado somente na segunda metade do século XIX,
a história mostra que o produto participou da cultura de povos de tempos anteriores à
história moderna. De acordo com THOMAS (2001, p. 1):
O registro da participação do petróleo na vida do homem remonta a

tempos bíblicos. Na antiga Babilônia, os tijolos eram assentados com
asfalto e o betume era largamente utilizado pelos fenícios na calefação de
embarcações. Os egípcios o usaram na pavimentação de estradas, para
embalsamar os mortos e na construção de pirâmides, enquanto gregos e
romanos dele lançaram mão para fins bélicos. No Novo Mundo, o petróleo
era conhecido pelos índios pré-colombianos, que utilizavam para decorar
e impermeabilizar seus potes de cerâmica. Os incas, os maias e outras
civilizações antigas também estavam familiarizadas com o petróleo, dele
se aproveitando para diversos fins.
Entretanto, apesar da presença cultural do petróleo nos povos antigos, o primeiro

poço de petróleo registrado data de 1859, como demonstra BRADLEY (1987, p. 632)
em “Em 1859, o coronel Edwin Drake perfurou e completou o primeiro poço de petróleo
conhecido perto de uma pequena cidade na Pensilvânia. Este poço, que foi perfurado com
ferramentas de cabo, deu início à moderna indústria do petróleo”. Desse modo, podemos
caracterizar esse poço como o primeiro poço onshore registrado. Não muito tempo depois,
há cerca de 38 anos, o ramo da perfuração começou a explorar poços offshore para extração
de petróleo. Com o desenvolvimento do poço offshore, o aumento significativo do potencial
de extração e viabilidade econômica logo foi percebido pela indústria da extração. De
acordo com BRADLEY (1987, p. 632) “Em 1897, perto de Summerland, CA, H.L. Williams
estendeu um campo de petróleo em terra no Canal de Santa Bárbara perfurando um
poço submarino de um píer(...) Cinco anos depois, mais de 150 poços offshore estavam
produzindo petróleo”.
Capítulo 1. Introdução 12
1.2 Objetivo
O objetivo desse trabalho consiste na arquitetura e programação de um Software em
ambiente LabVIEW, para um CompactRIO (cRIO) 9053 em comunicação com uma sonda
petrolífera onshore e elementos sinalizadores na cabine de operação. Como objetivo basilar,
o sistema deve ser capaz de se comunicar com o motor que controla a movimentação do
guincho da instalação mecânica, processar os sinais de elementos de operação e realizar o
controle de movimentação e freio do sistema mecânico. Além disso, o projeto deve adquirir
e converter os sinais analógicos de sensores presentes no ambiente de sonda, bem como ser
capaz de calibrar dados de pressão, temperatura, rotação e comprimento de tubulação. O
sistema deve ser modular, fisicamente seguro e pronto para responder a possíveis erros
computacionais. Por fim, deve-se criar um ambiente homem-máquina para visualização
dos dados e operação do sistema.
1.3 Revisão Bibliográfica

Em Bradley (1987) e Thomas (2001) é feito o embasamento teórico acerca dos
elementos presentes na construção de sondas de perfuração onshore e offshore, bem
como seu método de funcionamento e características intrínsecas. Ademais, é feito um
embasamento histórico da presença do petróleo nas civilizações e do início da exploração
econômica do óleo.
Em Daghlian (1995) e Vahid (2008) é construída a base lógica para entendimento e
elaboração de circuitos lógicos combinacionais. Desse modo, é apresentado a fundamentação
das equações lógicas através da algebra booleana, que será usada para arquitetar o
funcionamento do ambiente de atuação da sonda.
Em Chapra (2008) e Cormen (2012) colhe-se conceitos primordiais para manipu-
lação, aproximação e cálculo numérico de funções, a partir de sistemas computacionais.
Além disso, embasa os conceitos de estrutura de dados computacionais utilizados nas
rotinas de desenvolvimento.
Por fim, através dos manuais físicos e digitais disponibilizados pela National
Instruments (NI), tira-se toda fundamentação técnica para arquitetura, produção, debugging
e funcionamento da linguagem visual LabVIEW. Desse modo, todos os pontos como o
design pattern, em conjunto com as operações entre diversos escopos de variáveis e as
rotinas com abrangência local e/ou global para os diversos dispositivos da rede, vêm
dos manuais descritos pela NI. Por fim e em adição, os escritos ainda contemplam as
características e métodos de resolução de erros em diversos âmbitos do sistema.
Capítulo 1. Introdução 13
1.4 Visão geral dos capítulos seguintes

O Capítulo 2 explicita a formatação do ambiente de trabalho, esclarecendo o
contexto das instalações mecânicas e elétricas previamente desenvolvidas, que possibilitaram
a realização desse projeto. A revisão teórica acerca da arquitetura e método de resolução
das demandas propostas para operação da sonda, bem como a revisão de alguns dos
assuntos estudados durante a graduação se encontram no Capítulo 3. Por consequência,
o próximo tópico, Capítulo 4, demonstra o desenvolvimento do projeto em si, tomando
como base a revisão teórica previamente vista. Ademais, durante o Capítulo 5, é possível
verificar os resultados práticos do desenvolvimento. Por fim, o Capítulo 6 realiza uma
reflexão pessoal acerca do produzido, junto da conclusão do trabalho.
14
2 Contextualização
A Geowellex do Brasil Serviços Petrolíferos LTDA é uma empresa nacional que

lida com serviços de Mud Logging, Avaliação de Formação e Acompanhamento Geológico.
Estes serviços tem como foco principal o auxílio de exploração petrolífera. A empresa
tem e teve como clientes empresas como PretoRio, MAHA Energy, Jowfe Oil Technology,
Centrica, TEK Óleo e Gás, Parnaíba Gás Natural, OGX, Santana Óleo & Gás, Sanangol
HBrasil, ENEVA, Alvopetro, Partex Brasil, GeoPark, Petrosynergy.
A base da Geowellex localizada na cidade de Macaíba, no Rio Grande do Norte,
conta com um Tech Center onde se desenvolvem novas tecnologias para a indústria do
petróleo, tanto na produção de inovações em Software para análise de amostras, quanto
o desenvolvimento de Hardware próprio para serviços prestados pela empresa. Ainda na
base, é possível encontrar uma simulação robusta de um ambiente de sonda petrolífera,
com uma sonda em menor escala, posicionada sob um poço de aproximadamente 120
metros de profundidade, com a sala de operação instalada dentro de um contêiner ao lado
da instalação.
Figura 1 – Base da Geowellex em Macaíba
Fonte: Autoria Própria

Capítulo 2. Contextualização 15
2.1 Instalação Mecânica

2.1.1 Elementos da Torre de Perfuração
A instalação mecânica da sonda segue uma configuração simplificada do padrão
elementar de composição de elementos mecânicos de plataformas de perfuração. Para
facilitar a identificação e nomeação dos componentes, usaremos a Figura 2 de referência.
Figura 2 – Plataforma de Perfuração e seus equipamentos
Fonte: CEPEP
O sistema instalado na base apresenta os elementos:
• Torre de Perfuração (Derrick): estrutura metálica vertical que serve de cerne

para os demais elementos mecânicos.
• Bloco de Coroamento (Crown Block): circuito de polias estacionárias com o eixo

localizado no topo da torre, utilizado para modificar e redirecionar o tensionamento
do cabo de aço utilizado para erguer a tubulação;
• Catarina e Gancho (Traveling Block e Hook): bloco que conta com um

conjunto de polias montadas em um eixo móvel, que varia de altura de acordo com
a ação do motor que traciona o cabo de aço. Este conjunto conta com um gancho
em formato de pinça;
• Cabeça de injeção (Swivel): bloco que injeta fluido de perfuração para dentro da
coluna e separa os elementos rotativos dos estacionários;
• Power Swivel: diferente do esquematizado na imagem 2, a plataforma presente na

base apresenta o Power Swivel, acoplado na cabeça de injeção e responsável pela
transmissão do movimento angular.
É possível visualizar os elementos citados na imagem real do ambiente de trabalho,

representado na Figura 3.
Figura 3 – Plataforma de Perfuração e localizada na base da Geowellex
2.1.2 Elementos adjacentes à Torre de Perfuração

Além dos elementos atrelados à torre de perfuração, temos os elementos adjacentes,
que participam dos processos feitos na sonda. Dentre esses elementos, temos:
• Motor Guincho: elemento de força motriz que transforma energia elétrica para
rotacionar o eixo do guincho, visível na Figura 4, e tensionar o cabo de aço responsável
pelo içamento, descida e freio da tubulação;
Figura 4 – Motor Guincho
• Rampa e e gaveta de tubulação (Pipe Ramp e Pipe Racks): estrutura

montada para facilitar a instalação e desinstalação de tubulações no poço, sendo a
rampa um declive metálico que leva para um armazenamento de tubos, chamado de
gaveta. Ambos visíveis na Figura 5;
Figura 5 – Rampa e e gaveta de tubulação

• Bomba de Lama (Motor a Diesel): um motor alimentado por combustível

diesel, semelhante a o de um automóvel de grande porte, exemplificado na Figura 6,
responsável pela força motriz de bombeamento do fluido de perfuração;
Figura 6 – Motor a Diesel
• Tanque de Lama e Bomba de Mistura (Mud Tank e Mud Pump): estrutura

que recolhe a lama e substrato produzido na ação de perfuração. A bomba tem o
objetivo de mixar os aditivos usados na mistura da lama e manter a homogeneidade
do fluido. Ambos visíveis na Figura 7 e 8;
Figura 7 – Tanque de Lama

Figura 8 – Bomba de Mistura
• Motor Hidráulico: motor nomeado de “Motor Hidráulico”, por fazer parte de uma
futura unidade hidráulica, responsável pelo acionamento de uma bomba hidráulica
(ainda não instalada). A força gerada por suas revoluções irá acionar a bomba, que
através da pressurização de óleo armazenado será responsável pela rotação do Power
Swivel e controle futuro de um freio hidráulico.
Figura 9 – Motor Hidráulico ao lado da caixa armazenadora de óleo
2.1.3 Elementos Sensores

Além dos elementos de atuação presentes na plataforma de perfuração, para
desenvolver sistemas de monitoramento faz-se necessário a instalação dos elementos
sensores. Dentre os elementos sensores presentes na plataforma, temos:
• Sensor de Nível: elemento sensor que mede o nível de liquido, do tipo Dolphin,
presente no tanque de lama. O sensor é calibrado para retornar o valor mínimo
quando o tanque tiver em 0% e o valor máximo quando o tanque estiver em 100%
da capacidade;
Figura 10 – Sensor de Nivel
• Sensor de Densidade: elemento sensor de densidade de lama utilizado para entender

características da geologia retornada pela perfuração e certificar das propriedades da
lama ao misturá-la com aditivos;
• Sensor de Temperatura: elemento sensor de temperatura que, assim como o

Sensor de Densidade, monitora as propriedades do fluido em ocasiões de mistura
com aditivos;
Figura 11 – Sensor de Densidade e Temperatura
• Sensor de de Fluxo (Flow Out): sensor que mede o fluxo de retorno do fluido de
perfuração, junto do ponto de saída da lama;
Figura 12 – Sensor de Fluxo (Flow Out)
• Sensor de Tensionamento de Cabo: sensor que mede a tração do cabo de aço,

para monitorar o peso da carga de trabalho e possibilitar o tratamento de segurança
adequado visto uma situação de sobrecarga.
Figura 13 – Sensor de Tensionamento de Cabo
• Sensor de Pressão: sensor que mede pressão na linha hidráulica do Motor a Diesel,
responsável pelo bombeiamento do fluido de perfuração. Este fator é de grande
significância para averiguação da eficiência de bombeamento, que apresenta um papel
fundamental no processo de perfuração.
Figura 14 – Sensor de Pressão
• Encoder: equipamento que mede o posicionamento vertical do gancho através do

movimento angular do motor guincho. A medição em questão é feita através da
contagem de orifícios presentes na faixa de orifícios no disco metálico do equipamento.
Figura 15 – Encoder
2.2 Instalação Elétrica

A arquitetura da instalação elétrica do sistema baseia-se em três quadros elétricos,
que desempenham tarefas distintas. Os painéis se encontram dentro do contêiner que
funciona como sala de operação. Além disso, dentro dessa sala é possível encontrar os fios
referentes às entradas e saídas de elementos atuadores e sensores instalados na sonda. O
acesso a esses elementos Entrada/Saída (E/S) só é possível devido a uma prévia distribuição
de fiação, que agrupa todas as conexões úteis dos elementos de instrumentação e distribui
para o contêiner.
2.2.1 Quadro dos Soft-Starters

Neste quadro temos dois Soft-Starter SSW07, da WEG. Em suma, a função do
Soft-Starter nesse sistema é inicializar um motor elétrico trifásico com a corrente nominal
baixa. Esta característica se faz necessária pela presença da corrente de pico, possivelmente
presente no acionamento de um motor. Experimentalmente, foi visto que a corrente de
pico nesse circuito pode chegar até oito vezes a amplitude da corrente nominal. Assim,
dependendo da faixa de amplitude da corrente nominal, uma corrente de pico pode causar
instabilidade na rede elétrica e/ou até chegar a derreter a fiação.
A presença de dois Soft-Starter deve-se à necessidade de inicializar dois motores
distintos, motor de uma bomba de mistura e motor hidráulico. Apesar da capacidade de
configurar estes sistemas para regular o tempo de aceleração e desaceleração do motor,
no caso do sistema instalado foi inscrito uma configuração simples de liga e desliga. Em
adição, os dois sistemas contam com disjuntores C32, para proteger a instalação contra
curtos-circuitos ou sobrecargas. A curva C foi escolhida levando em conta seu melhor
funcionamento para cargas que possuem potencial indutivo. Por fim, contamos com um
relé, para cada Soft-Starter, que chaveia uma tensão de 220V a partir de uma entrada de
24V, que terá o origem na saída do cRIO.
O sistema pode ser visualizado na Figura 16.
Figura 16 – Quadro dos Soft-Starters
2.2.2 Quadro do Inversor

O quadro do inversor pode ser caracterizado como o quadro de força do guincho.
O guincho tem como objetivo principal o de descer, subir e frear. No caso em questão,
devemos controlar a velocidade de subida e descida do elemento mecânico, para isso usamos
um inversor, um CFW500, da WEG. O motor, da Voges, presente no conjunto, conta com
uma potência de 11 kVA e um freio eletromecânico integrado.
O caminho de força para acionamento do inversor é diferente daquele explicitado
nos Soft-Starter. O caminho da corrente passa por disjuntores do tipo C32, pelos mes-
mos motivos e especificações exploradas no tópico anterior. Logo após, a fiação passa
por contatores Easypact TVS, da Schneider Electric, que servem intertravamento para
acionamento do inversor. Com a saída do contator, o nó de tensão alimenta o Inversor.
Vale salientar que o sistema ainda conta com dois outros conjuntos, os relés e a ponte
retificadora. O bloco de relés conta com quatro dispositivos, sendo o primeiro o responsável
pelo acionamento dos contatores, o que causa o acionamento do Inversor. Ademais, os
três relés restantes recebem sinais do cRIO que representam os movimentos de subida,
descida e freio. Estes sinais acionam os relés, que por sua vez alimentam o inversor com
o comando do controle. Por fim, pelo fato do motor operar com uma tensão de entrada
de 380V a 420V e necessitar de uma corrente contínua, usa-se a ponte retificadora para
transformar o sinal de alimentação analógico em digital.
Um primeiro importante adendo a se fazer é citar que o Inversor pode ser configurado
para trabalhar em diversos tipos de sistemas, adaptando aos seus requisitos. O sistema
já havia tido seus parâmetros previamente configurados, como tempo de rampa, tipo de
freio, corrente do motor, proteções de sobrecarga e outras especificações.
Como segundo importante adendo, é importante relembrar que esta aplicação
lida com uma carga reativa. Tendo em vista que experiências passadas mostraram que a
presença da carga reativa no inversor pode levá-lo a falha, foi importante a instalação de
um Resistor de Frenagem, para dissipar esta carga energética em calor.
Figura 17 – Quadro do Inversor
2.2.3 Quadro do cRIO

O quadro do cRIO também pode ser chamado de quadro de controle. Este quadro
é responsável por hospedar o controlador CompactRIO 9053. De acordo com a National
Instruments, “o controlador CompactRIO é um controlador embarcado de alto desempenho
que apresenta módulos de E/S industriais, extrema robustez, certificações padrão do setor
e recursos integrados de visão, movimento, comunicação industrial e interface homem-
máquina (IHM)”. Este controlador atua no circuito regrando a movimentação do guincho,
bem como adquirindo e processando os dados dos sensores, que serão apresentados em IHM
separada. O cRIO é programável através da linguagem de programação visual proprietária
da NI, o LabVIEW.
O cRIO e os sensores conectados ao controlador são alimentados por uma fonte de
tensão de 24V e protegidos por um disjuntor C25. Além disso, para garantir a segurança dos
componentes, todas as entradas e saídas dos sensores e do hardware da NI são protegidos
por um conjunto de oito barreiras de dois canais.
Figura 18 – Quadro do cRIO
A interação do controlador com os elementos externos é feita através dos cartuchos

de E/S da própria NI, desenvolvidos como elementos modulares, que permitem a persona-
lização do controlador para a diversidade de possíveis ambientes de trabalho. Em nosso
sistema, foi instalado quatro cartuchos, dentre eles:
• NI 9408: Contém 16 canais de ±20mA e módulo de entrada analógica com represen-

tação de 24 bits. Utilizado para receber as saídas analógicas dos sensores presentes
na sonda;
• NI 9375: Contém 32 canais, sendo 16 canais para entradas digitais, do tipo Sinking
Input e 16 canais para saídas digitais, do tipo Sourcing Output. Utilizado para
conectar o sistema com os botões, chaves, joystick e saídas digitais de sensores da
sonda;
• NI 9423: Contém 8 canais de entrada digital do tipo Sinking Input, com no máximo
1 µs de tempo de atraso. Utilizado exclusivamente para detectar o indicador de
rotação do motor da bomba de lama;
• NI 9411: Contém 6 canais de input digital de ±5V até 24V do tipo diferencial ou
simples, com taxa de atualização de 500 ns. Utilizado para medir o posicionamento
do guincho através do Encoder.
2.3 Elementos de Operação e Sinalização

Atrelada a instalação elétrica temos uma mesa de operação e supervisão. Nessa
mesa, possuímos tanto dispositivos de entrada, que se comunicam com o controlador,
quanto dispositivos de saída, que sinalizam estados atuais da operação de movimento
de tubulação. Ademais, possuímos uma tela proprietária da NI, que funciona como IHM
digital do sistema, contendo abas de supervisão de sensores e sinalizadores.
Dentre as entradas presentes na mesa de operação contamos com:
• Três (3) chaves de tipo Switch, que servem para se comunicar com o sistema de
controle e requisitar o acionamentos de três elementos distintos: Inversor, Bomba de
Mistura e Motor Hidráulico;
• Um botão normalmente fechado especial para emergência, que tem como função
requisitar a uma parada manual do sistema de movimentação do guincho em caso
de emergências visuais;
• Um joystick de três fases, usado para comandar a direção de movimento do guincho.

Os três modos são o de subida, movimentando o joystick para cima, o de descida,
movimentado o joystick para baixo, e estático, deixando o joystick em estado neutro.
Dentre as saídas presentes na mesa de operação contamos com:
• Três (3) sinalizadores luminosos, cuja função é identificar por meio de uma iluminação
pontual o atual funcionamento dos elementos: Inversor, Bomba de Mistura e Motor
Hidráulico;
• Um Buzzer, cujo funcionamento baseia-se na sinalização sonora de que o sistema

está em modo de emergência.

Figura 19 – Mesa de operação

29
3 Fundamentação teórica
3.1 Arquitetura Combinacional de Circuitos Digitais

Os circuitos digitais são sistemas que aplicam da lógica binária, afim de solucionar
e regrar as lógicas de funcionamento, em baixo nível, de aparelhos computacionais e
eletrônicos. Conforme VAHID (2008, p. 20):
Nos sistemas de computação, os sinais digitais mais comuns são aqueles

que podem assumir um entre apenas dois valores, como ligado ou desligado
(representando frequentemente como 1 ou 0). Essa representação com
dois valores é conhecida como representação binária. Um sistema digital
é aquele que recebe entradas digitais e gera saídas digitais. Um circuito
digital é uma conexão de componentes digitais que juntos constituem
um sistema digital.
Os componentes digitais citados, que compõem em junção os sistemas digitais, vão

de blocos que realizam operações lógicas de sistemas dicômicos (como negação, conjunção,
disjunção e bicondicional) até, em caso de sistemas mais robustos, elementos de memória
volátil e não-volátil. A sistematização dos blocos operacionais, constituidos nos circuitos
digitais, é feita através da aplicação dos blocos lógicos, equacionados através de funções
booleanas.
3.1.1 Lógica da Álgebra Booleana

De acordo com VAHID (2008, p. 54) “A álgebra booleana usa variáveis cujos valores
podem ser apenas 1 ou 0 (representando verdadeiro ou falso, respectivamente) e cujos
operadores, como AND, OR e NOT, operam com essas variáveis e dão como retorno 1
ou 0.” Esses operadores citados são parte dos blocos lógicos utilizados na construção de
circuitos digitais. Dessa forma, o funcionamento de circuito digital segue a sistematização
imposta por uma equação lógica constituida desses operadores.
O bloco NOT realiza a negação, ou inversão lógica, de um variável booleana.
Como a variável booleana é um sistema dicotômico, a inversão lógica retorna o elemento
contrário ao valor lógico da preposição operada. Portanto, a operação NOT em uma
variável que assume o valor 1 (verdadeiro) retorna o valor 0 (falso). De forma oposta, a
operação NOT em uma variável que assume o valor 0 (falso) retorna o valor 1 (verdadeiro).
O bloco AND realiza a conjunção, ou produto lógico, entre duas variáveis
booleanas. Seu resultado é similar ao de considerarmos a variável booleana como variável
aritimética e considerarmos a operação como um produto aritimético. Assim, tendo A e
B como variáveis booleanas, a operação AND só retorna o valor 1 (verdadeiro), quando
Capítulo 3. Fundamentação teórica 30
tanto A quanto B também assumirem o valor 1 (verdadeiro). Para todos os demais casos
a operação AND retorna o valor 0 (falso).
O bloco OR realiza a disjunção inclusiva, ou soma lógica, entre duas variáveis
booleanas. Neste bloco, o retorno verdadeiro de uma preposição já gante a resposta
verdadeira da operação. Desse modo, sendo A e B variáveis booleanas, a operação OR só
retorna o valor 0 (falso), quando tanto A quanto B também assumirem o valor 0 (falso).
Para todos os demais casos a operação OR retorna o valor 1 (verdadeiro).
As representações dos blocos operacionais, padronizadas pela norma militar ameri-
cana MIL-STD-806B (Defense Standard), atrelados a suas tabelas verdade são visíveis na
Figura 20.
Figura 20 – Blocos operacionais NOT, OR e AND
Fonte: Vahid (2008)
Em adição aos três blocos lógicos principais, comumente mais quatro blocos opera-
cionais podem ser formados através de interações recorrentes entre os blocos de NOT, OR
e AND.
Os blocos NAND e NOR são, respectivamente, representados pela combinação
lógica das portas AND e OR com um inversor lógico (NOT) na saída do bloco. Assim,
NAND e NOT apresentam, respectivamente, as respostas invertidas de AND e OR. Dessa
forma, NAND apresenta valor 0 (falso) somente quando suas duas entradas possuem
valor 1 (verdadeiro), retornando 1 (verdadeiro) para todos os outros casos. Por fim, NOR
apresenta valor 1 (verdadeiro) somente quando suas duas entradas possuem valor 0 (falso),
retornando 0 (falso) para todos os outros casos.
O bloco XOR realiza a disjunção exclusiva entre duas variáveis booleanas.
Assemelhando-se a conjunção “ou” da língua portuguesa, este bloco retorna 1 (verdadeiro)
quando apenas uma das entradas apresentam um valor 1 (verdadeiro). De outro modo,
podemos também interpretar que este bloco apresenta uma saída 1 (verdadeira) quando
as duas variáveis apresentam valores dicotômicos opostos.
O bloco XNOR realiza a bicondicional entre duas variáveis booleanas. De forma

prática, podemos afirmar que este bloco é a inversão da saída do bloco XOR, assim como
os blocos NAND e NOR são, respectivamente inversões nas saídas dos blocos AND e OR.
Sob outra perspectiva, podemos também interpretar que este bloco apresenta uma saída 1
(verdadeira) quando as duas variáveis apresentam valores dicotômicos iguais.
As representações dos blocos adicionais, padronizadas pela norma militar americana
MIL-STD-806B (Defense Standard), atrelados a suas tabelas verdade são visíveis na Figura
21.
Figura 21 – Blocos operacionais NAND, NOR, XOR e XNOR
Fonte: Vahid (2008)
Afim de representar as operações booleanas com notação mais aproximada da

notação algébrica convencional, os blocos são padronizados de acordo com a notação
presente na Tabela 1.
Tabela 1 – Notação algébrica dos operadores booleanos.
Operação Notação
NOT A A
A OR B A+B
A AND B A · B ou AB
A NAND B AB
A NOR B A+B
A XOR B A⊕B
A XNOR B A⊕B
3.1.2 Propriedades da Álgebra Booleana

Assim como sistema o algébrico que rege a aritmética, o sistema algébrico booleano
possui propriedades e leis intríssecas, que possibilitam sua coerência lógica e usabilidade.
Para realizar a simplificação de funções booleanas, especialmente em circuitos digitais,
faz-se necessário o entendimento dessas diretrizes.
Ao fazer uma junção entre os teoremas citados por DAGHLIAN (1995, p. 106-114)
e as propriedades expostas por VAHID (2008, p. 66-67), podemos construir uma Tabela 2
de propriedades úteis na simplificação de funções booleanas, levando em conta que A, B e
C podem ser tanto variáveis booleanas como a representação de uma função de variáveis
booleanas.
Tabela 2 – Propriedades dos sistemas booleanos
Propriedade Notação Algébrica

A+A=A
1 (Idempotência)
A·A=A
A+1=1
2 (Elementos Nulos)
A·0=0
A+0=A
3 (Identidade)
A·1=A
A+A=1
4 (Complemento)
A·A=0
5 (Involução) A=A
A+B =B+A
6 (Comutativa)
A·B =B·A
(A + B) + C = A + (B + C)
7 (Associativa)
(A · B) · C = A · (B · C)
A · (B + C) = A · B + A · C
8 (Distributiva)
A + (B · C) = (A + B) · (A + C)
A + (A · B) = A
9 (Absorção)
A · (A + B) = A
A·B =A+B
10 (De Morgan)
A+B =A·B
Vale notar que a décima propriedade da Tabela 2 demonstra a construção dos

blocos NAND e NOR, respectivamente pelas portas OR e AND com as entradas invertidas,
em contraponto com a ideia mais intuitiva de serem construidas pelas portas AND e OR
com as saídas invertidas.
3.2 Interpolação Polinomial

A Interpolação Polinomial é um processo de construção de uma função polinomial
de grau n − 1 que generaliza um comportamento a partir de um conjunto de n pontos.
Como constata CHAPRA (2008, p. 409) em “Para n + 1 pontos dados, existe um e somente
um polinômio de grau n1 que passa por todos os pontos(...) A interpolação polinomial
consiste em determinar o único polinômio de grau n que passa pelos n + 1 pontos dados.
Esse polinômio, então, fornece uma fórmula para calcular valores intermediários.”
Dentre os métodos utilizados, tem-se o método do Polinômio Interpolador de
Lagrange, onde a função interpolada assume a formulação das Equação 3.1.
n
X
fn (x) = Li (x)f (xi ) (3.1)
i=0
Tal que o termo Li (x) é o polinômico característico de Lagrange, cujo significado

matemático é escrito pela equação 3.2
n
Y x − xj
Li (x) = (3.2)
j=0,j̸=i xi − xj
3.3 Arquitetura do Armazenamento FIFO

A estrutura First In First Out (FIFO), também nomeada de fila, é uma estrutura
de armazenamento de dados que segue uma regra específica de escrita e leitura. De acordo
com CORMEN (2012, p. 200):
A propriedade FIFO de uma fila faz com que ela funcione como uma
fileira de pessoas em uma caixa registradora. A fila tem um início (ou
cabeça) e um fim (ou cauda). Quando um elemento é inserido na fila,
ocupa seu lugar no fim da fila, exatamente como um cliente que acabou
de chegar ocupa um lugar no final da fileira. O elemento retirado da fila
é sempre aquele que está no início da fila, como o cliente que está no
início da fileira e esperou por mais tempo.
Levando em consideração a estrutura metodológica da FIFO, podemos denotar

sua usabilidade na organização de variáveis ou tarefas dentro de uma rotina de códigos.
Tendo em vista sistemas computacionais que façam a interligação entre duas ou mais
instâncias de execução, a comunicação entre esses laços, especialmente entre sistemas
produtor-consumidor, é mais confiável e organizada ao usarmos uma FIFO. Dessa forma,
mantemos a ordem de chegada e execução das requisições, além de armazenarmos as
inscrições em stand-by.
3.4 Arquitetura de Software para LabVIEW

LabVIEW é um sistema de programação visual, desenvolvido pela National Ins-
truments em 1986, que vem o atualizando anualmente desde 2003. A programação visual
desse sistema baseia-se na ligação entre blocos que realizam tarefas unitárias, podendo
ser tarefas de baixo ou alto nível. Desse modo, a ligação entre os blocos é feita por fios.
Por sua vez, o fio pode carregar um valor fixo ou uma variável do sistema. Estes valores
podem ter diversos tipos de formatação, entre eles:
1. Booleana;
2. Numérica;
• Inteiro Sem Sinal (Byte, Word, Long e Quad);

• Inteiro Com Sinal (Byte, Word, Long e Quad);
• Ponto Flutuante Não Complexo (Single, Double e Extended);
• Ponto Flutuante Complexo (Single, Double e Extended);
• Ponto Fixo;
• Instante de Tempo.
3. String;
4. Array;
5. Enum;
6. Dinâmica (que podem ser convertidos para outros tipos de dado);
7. Cluster (agrupamento de variáveis);
Essas variáveis se tornam entradas dos blocos operacionais, que processam os dados
e por sua vez podem ou não retornar saídas com o mesmo, ou outro, tipo de variável. O
conjunto de interações entre blocos, que comumente gera subsistemas que adquirem dados
de entradas e retornam saídas processadas é chamado de Virtual Instrument (VI).
3.4.1 Queued Message Handling (QMH)

Assim como sistemas de programação baseados em texto, o sistema de programação
visual do LabVIEW também possui padrões de projeto para ordenar a produção de VIs
de forma modular, adaptável a erros internos e de escalabilidade profissional. Desse modo,
o padrão QMH segue um design do tipo "Produtor/Consumidor", que apresenta dois laços
de repetição interconectados.
• O laço de repetição nomeado de Event Handler Loop (EHL) reconhece um evento

acionado pelo usuário através de uma estrutura básica chamada de Event Structure,
que aciona uma estrutura de case para um evento previamente cadastrado. Esta
estrutura case é responsável por realizar uma rotina de códigos mínima e enfileirar
uma FIFO de mensagens com a mensagem do evento acionado. A mensagem consiste
em uma string atrelada a um dado variante, tal que esta string é o nome da rotina
a ser acionada no segundo laço de repetição. Dizemos que o EHL é a “entidade
produtora” do nosso padrão de projeto, por produzir mensagens a partir de eventos
na interface do usuário;
• O segundo laço de repetição é nomeado de Message Handling Loop (MHL), que

realiza até três operações. Por padrão, a primeira operação do MHL é desenfileirar
a mensagem mais antiga da FIFO de mensagens, compatilhada pela EHL. Ao
desenfileirar a mensagem, separa-se a string do dado variante. A string é usada como
entrada seletora da estrutura de case do MHL. A estrutura de case, podendo ou não
usar do dado variante atrelado a mensagem, realiza a rotina de código referente a
mensagem enviada pelo EHL. Adicionalemente, a rotina do código dentro do case
pode enfileirar uma nova mensagem para resolução no MHL, possibilitando um
passo-a-passo similar a uma máquina de estados interna.
A robustez desse padrão de projeto é a possibilidade de processar diferentes tipos

de tarefas e rotinas do sistema de forma paralela, podendo contar com tempos de execução
diferentes para cada tarefa. Isso ocorre pelo fato das estruturas EHL e MHL funcionarem
de forma similar a duas máquinas de estado independentes, como visível na Figura 22.
Desse modo, a aquisição de um evento, como uma ação na interface do usuário, não
é perdida caso o sistema esteja processando uma mensagem anterior, permitindo uma
ordenação de processamento sem sacrificar a interação com o sistema. Ademais, apesar
do modelo padrão do QMH, visível na Figura 23, vale salientar que é possível expadir
a capacidade de processamento paralelo ao adicionar mais MHLs para o sistema geral.
Entretanto, adicionar mais MHLs ao sistema requer tratamento na estrutura de mensagens
da FIFO, para que o cluster comporte um número de mensagens unitárias tal qual o
número de MHLs no sistema.
Figura 22 – Máquina de estado do QMH
Figura 23 – Arquitetura base do QMH no LabVIEW
Fonte: National Instruments

3.4.2 Escopos de Variáveis

As variáveis presentes nos sistemas e rotinas do LabVIEW podem ser acessadas de
formas distintas, de acordo com a necessidade de leitura e significância do dado para um
contexto global.
3.4.2.1 Local Variable
As Local Variables são variáveis de escopo local, dentro do próprio VI de origem.

Esta variável pode ler ou escrever em entradas ou saídas inicializadas no VI, de forma
que se torna possível extrair ou modificar dados entre diagramas separados, sem ter a
capacidade de unir-los através de fios. A Figura 24 mostra um exemplo da Local Variable
nomeada de Loop Control, criada no laço de repetição 1, usada como controle no laço de
repetição 2.
Figura 24 – Uso da Local Variable
3.4.2.2 Global Variable (Single Process Shared Variable)
As Global Variables, Single Process Shared Variable (SPSV), são variáveis de escopo
geral, que possuem presença e usabilidade em todos os VIs dentro de um sistema. Esta
variável é criada de forma semelhante a uma VI, com a divergência que o arquivo da Global
Variables apresenta somente o painel frontal com entradas do tipo da variável preconfigurada.
Vale notar que essa variável de escopo geral é atrelada a um determinado hardware. Dessa
forma, caso o sistema projetado possua intercomunicação entre dois hardwares diferentes,
que estejam rodando rotinas em LabVIEW, a Global Variable iniciada em um dos hardwares
não pode ser acessada pelo outro.
3.4.2.3 Shared Variable Network-Published
Afim de comunicar variáveis entre dois ou mais ambientes programados em Lab-

VIEW, hospedados em hardwares distintos, usa-se as Network-Published Shared Variable
(NPSV). Assim como as SPSVs, a variável NPSV é criada de forma semelhante a uma
VI, com a divergência que o arquivo da variável apresenta somente o painel frontal com
entradas do tipo da variável preconfigurada. Pelo fato da existência das possíveis flutuações
em taxas de leitura e escrita devido a instabilidade dos sistemas de rede, é possível acionar
um buffer de rede para garantir a integridade da informação.
3.4.3 Formatação e Tratamento de Erro

Para rotinas produzidas no LabVIEW e na arquitetura do seu fluxo de dados, é de
suma importância o entendimento e tratamento da variável de erro. No sistema, o erro é
um cluster composto de três elementos básicos:
• Status: variável booleana que assume o valor true caso algum erro tenha acontecido
no bloco atual ou no fluxo de dados;
• Code: variável numérica do tipo Long signed integer que indica a codificação do
erro ou advertência ocasionada, pretabelados pela NI. O valor zero (0) nessa variável
indica que o sistema não teve erro ou advertência. Entretanto, para valores diferentes
de zero (0), o sistema aponta um erro caso o status tenha o valor true, caso contrário
o code denota uma advertência;
• Source: variável do tipo string que contêm a origem do erro ocasionado. Esta variável
apresenta a significância de localizar e depurar o elemento causador do erro, tendo
em visto que o tratamento do erro comumente é feito após a junção dos clusters
durante o fluxo de dados.
Tendo em vista a formulação do cluster de erro, conseguimos usar um bloco

de unbundle para extrair as variveis separadamente. Com isso, conseguimos criar uma
estrutura de case, tendo como entrada seletora o código do erro apresentado. De acordo
com o código, é possível criar uma coleção de rotinas de gerenciamento e tratamento de
erro. Esse processo é feito de forma programática e pensada, de acordo com a aplicação
prevista. Ademais, de forma geral e simplificada, podemos extrair por sua vez a variável
status e a partir do seu valor lógico decidir o cessar ou início de uma laço de repetição,
que contenha alguma rotina pertinente ao sistema.
39
4 Desenvolvimento
A organização do desenvolvimento do software, em LabVIEW, seguiu uma separação

padronizada entre a unidade de aquisição, processamento e envio de dados para os sistemas
mecânicos e a unidade de que produz a IHM, armazena e calibra os dados de operação. Esta
separação se faz necessária para garantir a modularidade entre os sistemas computacionais
e evitar o acúmulo de requisições de processamento em um só hardware.
4.1 Sistema Real Time

Nomeado de Sistema Real Time (RT), nos referimos as rotinas desenvolvidas para
aquisição, processamento e envio de comandos aos sistemas mecânicos da plataforma de
perfuração. Este sistema é hospedado no controlador cRIO 9053, localizado no quadro
elétrico de controle (2.2.3), como evidenciado na sessão de Instalação Elétrica (2.2).
4.1.1 Inicialização do Sistema

A inicialização do sistema é um momento prévio a ao ponto de partida dos laços de
repetição que contêm as rotinas de controle desenvolvidas. Afim de direcionar o sistema a
seguir um passo prévio, usamos uma estrutura chamada de Stacked Sequence Structure
que utiliza de quadros numerados, onde o sistema processa as requisições da cada quadro
no ordenamento da numeração. Dessa forma, construímos a rotina de inicialização dentro
do quadro zero (0) da estrutura, afim de garantir a ordem correta de execução.
Figura 25 – Inicialização do Sistema Real Time
O sistema de inicialização, visível na Figura 25, segue o fluxo de dados de forma:

Capítulo 4. Desenvolvimento 40
1. Iniciar o cluster de erro com os elementos básicos de forma nulificados, ou seja, com
o status em valor false, o code igual a zero (0) e o source com string vazio;
2. Iniciar a Global Variable nomeada de All RT Loop Stop em valor false. Essa variável
é responsável por parar todos os laços de repetição dentro da rotina do RT, quando
seu valor modificado para true;
3. Iniciar todas as saídas digitais do cartucho NI 9375 em false. Este passo é feito para
garantir a não flutuabilidade da possível resposta do sistema em suas saídas. Dessa
forma, garantimos que nenhuma saída digital está requisitando comandos indevidos
durante a inicialização. Ademais, a saída DO1 é ligada ao freio eletromecânico. Este
freio, por segurança, é do tipo Normalmente Fechado (NF). Desse modo, o estado de
false significa que estamos com o sistema freado. Consequentemente, quando DO1
recebe true o sistema libera o freio do guincho;
4. O Merge Errors junta os clusters de erro das operações realizadas para passá-los
para a entrada Error In do próximo bloco;
5. O bloco Obtain Message cria uma FIFO de cluster de mensagem, assim, logo após,
o bloco Enqueue Message enfileira a mensagem “Initialize” para o MHL;
6. Por fim, define a variável global Control State como Safe State. Este modo define
que o sistema está funcionando de modo seguro, em tarefa de inicialização. Ademais,
o modo Safe State pode ser utlizado para denotar um modo de segurança do sistema,
em que os objetos de atuação se mantenham em stand-by. O Control State é uma
variável personalizada do tipo enum de words (de até 16 bits).
Com a finalização desse fluxo de dados, passamos o Error Out advindo da variável
global Control State e a linha da FIFO de mensagens, advinda do bloco Enqueue Message
para a próxima página do Stacked Sequence Structure. Desse modo, finaliza-se o processo
de inicialização do sistema RT.
4.1.2 QMH do Sistema Real Time

A estrutura de Queued Message Handler do RT se baseia unicamente na estrutura
de MHL, tendo em vista que as mensagens consumidas pelo RT são enviados pelo sistema
de Interface de Usuário. Dentre os estados presentes no MHL, temos:
• Initialize: estado inicial de espera;
• Critical Error, Log-Only Error, Non-Critical Error: estado com a função de

identificar o tipo de erro enfileirado, ocasionado durante o processo de operação.
Ademais, dependendo do tipo do erro, os sistema adiciona a o código de identificação
do erro no log do sistema. Em caso de erro crítico, o sistema entra em modo Safe
State e impede-se a operação;
• Exit: estado saída do código. Responsável por finalizar a FIFO de mensagens, impõe
ao sistema o modo Safe State, finaliza a comunicação entre o RT e a Interface de
Usuário e, por fim, para todos os laços de repetição.
• Send Error to UI: estado de envio de comunicação de erro no RT para exposição

e processamento na Interface de Usuário.
4.1.3 Bloco Lógico Combinacional do Guincho

Sendo o bloco primordial nas ações de atuação mecânica, temos o bloco de atuação
do guincho. Para criar as regras que regem o movimento do guincho, precisamos primeira-
mente mapear as entradas e saídas dos elementos da plataforma e da mesa de operação. O
mapeamento segue o que é descrito pela Tabela 3.
Tabela 3 – Mapeamento e Simbologia de Entradas e Saídas do Sistema de Atuação
Elemento de Entrada Representação Simbologia

no Sistema
Botão de Emergência DI0 Eme
Chave Ligar (Inversor) DI1 Lig
Chave da Bomba de Mistura DI2 Cbm
Chave do Motor Hidráulico DI3 Cbh
Joystick - Subir DI4 Jsb
Joystick - Descer DI5 Jdc
Entrada Run DI6 Run
Entrada Falha no Inversor DI7 F lh
Entrada Fim de Curso DI8 F nc
Elemento de Saída Representação Simbologia
no Sistema
Ligar Inversor DO0 Inv
Liberar Freio DO1 Lf r
Subida DO2 Sub
Decida DO3 Dsc
Buzzer DO4 Bzz
Acionar Bomba de Mistura DO5 Bbm
Acionar Motor Hidráulico DO6 Bbh
Tendo mapeado os elementos lógicos, podemos iniciar a formulação das funções

booleanas que dão funcionamento ao sistema.
Como o Botão de Emergência é um equipamento normalmente fechado, a sinalização
true indica que o botão não está pressionado, já a false indica que o sistema está em
modo de emergência. Para ligar tanto o inversor, quanto a bomba de mistura e a motor
hidráulico, basta garantirmos que o botão de emergência não esteja pressionado. Desse
modo, podemos começar a equacionar estas saídas.
Bzz = Eme (4.1)
Inv = Lig · Eme (4.2)

Bbm = Cbm · Eme (4.3)
Bbh = Cbh · Eme (4.4)
Para garantir que o sistema de movimentação funcionará de forma correta e

segura, consideramos uma configuração de segurança que habilita a movimentação. Esta
configuração é simplificada na variável booleana Safe. Tal que
Saf e = Lig · Eme · F lh (4.5)
O que inclui o intertravamento do sistema não apresentar falha no inversor, que

comanda o motor do guincho na plataforma. Agora, tendo em vista uma configuração
segura, podemos listar as regras de funcionamento das demais saídas de movimentação da
sonda.
• Subida:
1. O gancho deve subir quando o Joystick estiver articulado na posição de subir;

2. Caso o sensor Fim de Curso seja acionado (retorne o valor false, por ser
normalmente fechado), a subida do gancho deve ser impedida.
Sub = Saf e · F nc · Jsb (4.6)
• Decida:
1. O gancho deve subir quando o Joystick estiver articulado na posição de descer.
Dsc = Saf e · Jdc (4.7)
• Liberar Freio:
1. Observação: Para tornar o trabalho de entender quando o Freio Eletromecânico

deve ser liberado, imaginamos as regras que decidem quando o freio deve
ser acionado. Após a formulação da lógica, basta inserir um inversor lógico
(Operador NOT) na última linha do circuito.
2. O freio deve ser acionado em qualquer situação que o sistema não esteja dentro
da configuração segura postulada anteriormente, de acordo com a Equação 4.5;
3. O freio deve ser acionado quando nenhuma das saídas de Subida ou Descida,
respectivamente Equações 4.6 e 4.7, está acionada;
4. O freio deve ser acionado quando, por algum motivo não previsto, ambas as
saídas Subida e Descida estão acionadas;
5. Alem disso, o freio deve ser acionado sempre que a entrada Run, que denota a
movimentação do motor do guincho, retornar uma resposta false.
Lf r = Saf e + (Sub · Dsc) + (Sub · Dsc) + Run (4.8)
Ao invertermos ambos os lados da equação, obtemos:
Lf r = Saf e + (Sub · Dsc) + (Sub · Dsc) + Run (4.9)
Tomando como base as propriedades apresentadas na Tabela 2, podemos começar

a simplificação da notação com a propriedade da Involução no termo Lf r. Além disso,
podemos rearranjar o termo Saf e + (Sub · Dsc) + (Sub · Dsc) + Run para apresentar o
formato de (Saf e + Run) + ((Sub · Dsc) + (Sub · Dsc)) e com isso aplicar a propriedade
de De Morgan, resultando em:
Lf r = (Saf e + Run) · ((Sub · Dsc) + (Sub · Dsc)) (4.10)
Com isso, podemos aplicar mais uma vez De Morgan em cada um dos termos
resultantes, deixando a equação com a formula de:
Lf r = (Saf e · Run) · ((Sub · Dsc) · (Sub · Dsc)) (4.11)
Ao aplicar novamente a propriedade da Involução, no termo (Saf e · Run) e De

Morgan nos termos (Sub · Dsc) e (Sub · Dsc), conseguimos:
Lf r = (Saf e · Run) · ((Sub + Dsc) · (Sub + Dsc)) (4.12)
Mais uma vez aplicamos a propriedade da Involução, no termo ((Sub + Dsc),

resultando em:
Lf r = (Saf e · Run) · ((Sub + Dsc) · (Sub + Dsc)) (4.13)
Como próximo passo, podemos aplicar a propriedade Distributiva no termo ((Sub +

Dsc) · (Sub + Dsc)), resultando na expansão algébrica:
Lf r = (Saf e · Run) · ((Sub · Sub) + (Sub · Dsc) + (Dsc · Sub) + (Dsc · Dsc)) (4.14)
Por fim, ao aplicarmos a propriedade do Complemento, conseguimos excluir os

termos (Sub · Sub) e (Dsc · Dsc), resultando na equação final:
Lf r = (Saf e · Run) · ((Sub · Dsc) + (Dsc · Sub)) (4.15)
Entretanto, para meios de simplificação, podemos reescrever o termo ((Sub · Dsc) +

(Dsc · Sub)) por (Sub ⊕ Dsc), oque nos dá a função de controle da liberação do freio:
Lf r = (Saf e · Run) · (Sub ⊕ Dsc) (4.16)
4.1.4 RPM da Bomba de Lama

Afim de calcular a quantidade de strokes dados pela Bomba de Lama, precisamos
adquirir o número de rotações por minuto (RPM) do elemento mecânico. Para isso, a
Bomba de Lama conta com um elemento sensor integrado que identifica opticamente um
orifício em um disco que segue o eixo de rotação do motor. Assim, toda vez que o sistema
passa pelo orifício a Bomba de Lama manda uma sinalização booleana para o controlador
cRIO.
Tendo em vista esse comportamento, podemos calcular o valor do RPM da bomba,
através de duas abordagens distintas:
1. Somar a quantidade de pulsos recebidos em um período de um minuto e calcular o

valor exato do RPM no minuto passado;
2. Calcular o diferencial de tempo entre dois pulsos e dividir esse diferencial pelo
tamanho de um minuto, assim retornando do RPM entre dois pulsos.
Apesar da primeira abordagem calcular o RPM com exatidão, não se torna favorável
à aplicação da qual ela participaria, pelo fato de tomar um minuto para conseguir atualizar
os dados requisitados. Este delay não é compatível com tarefas de sensoriamento em tempo
real. Dessa forma, seguiu o desenvolvimento da segunda abordagem para o problema. Já
esta abordagem nos garante uma taxa de atualização célere, sempre atualizando seu valor
na próxima revolução do eixo do motor.
Dessa forma, deve-se fazer um laço de repetição que mantenha-se adquirindo os
dados da entrada digital do cartucho NI 9423, utilizado para receber o sinal do motor.
Entretanto, o laço deve realizar a operação de contar exclusivamente uma vez para cada
pulso, ou seja, sem distinguir as larguras dos pulsos. Para isso, utiliza-se o bloco One Shot
Rising, que detecta a borda de subida de um pulso digital e somente mantém o valor true
durante a duração de um ciclo do laço de repetição que o contém. Dessa forma, garantimos
que uma entrada true vinda do cartucho irá contar como apenas um pulso. Em seguida,
atualizamos a contagem de pulsos para um (1) e esperamos o próximo pulso. A partir de
agora, todo ciclo dado pelo laço de repetição tem seu tempo de execução contabilizado
e somado. Então, quando o segundo pulso é dado, o sistema detecta a entrada, soma a
quantidade pulsos para dois (2) e libera a estrutura de case que divide a quantidade de
milissegundos gastos nos ciclos do laço de repetição, entre o primeiro e segundo pulso,
com o valor de sessenta mil (60000), referente a quantidade de milissegundos presentes em
um minuto. Por fim, o sistema retorna ao estado de um pulso dado, para que no próximo
pulso seja calculado o diferencial de tempo entre o segundo e terceiro pulso.
Assim, a estrutura programática de cálculo do RPM, através do diferencial de
tempo entre pulsos, é exemplificada em ambiente LabVIEW pela Figura 26.
Figura 26 – Rotina de Cálculo de RPM da Bomba de Lama
4.1.5 Cálculo de movimentação vertical de tubos por Encoder

Para conseguirmos entender o posicionamento vertical e realizar medições como
posicionamento de tubulação e profundidade de tubulação montada na sessão, além
de sabermos o posicionamento pontual do gancho da plataforma de perfuração, faz-se
necessária a presença de um Encoder de Quadratura. Dessa forma, foi instalado um
Encoder Diferencial de Quadratura.
O Encoder é um elemento registrador que conta com um disco perfurado, com

orifícios seguindo distâncias angulares iguais. Chamamos o conjunto de orifícios de trilho. O
equipamento conta com um sensor óptico que identifica a passagem por um orifício. Desse
modo, a atuação do elemento vem com a propriedade de somar e registrar a quantidade de
orifícios passados em um certo movimento angular, bem como a propriedade de subtrair
e registrar a quantidade de orifícios passados em um movimento angular contrário. A
representação do Encoder pode ser vista na Figura 27.
Figura 27 – Funcionamento mecânico e sensorial do Encoder
Para realização do cálculo de posição do Encoder, por ser um equipamento do

tipo diferencial, podemos partir para uma abordagem tanto diferencial de quadratura
quanto quadratura de extremidade única. A princípio, foi escolhido o de extremidade
única por apresentar uma maior controlabilidade através da programação desenvolvida. A
formatação de captura de movimento foi feita pela abordagem X4 Encoding. Nesse modo,
contabilizamos a quantidade de bordas de subida e descida de ambos canais, A e B. Para
decidir se devemos somar ou subtrair a borda do sinal digital, basta verificarmos que sinal
lidera na ordem de bordas. Caso a liderança seja do canal A, devemos somar, caso seja do
B, devemos subtrair. A exemplificação desse comportamento é visto ne Figura 28.
Figura 28 – Modo X4 Encoding

Este modo de funcionamento foi implementado pelos blocos One Shot Rising e
One Shot Falling, para identificar as bordas de subida e descida, respetivamente. Para
cada identificação, é gerado um código em string que cataloga o evento. Quando ambos
sinais tiverem eventos catalogados nós concatenamos as strings, gerando um código. A
partir desse código, é possível identificar quem liderou os eventos a partir de uma lista de
combinações possíveis. Assim, soma-se, ou subtrai-se, de acordo com o entendimento da
liderança. O desenvolvimento do código por ser visto na Figura 29.
Figura 29 – Rotina do modo X4 Encoding
Apesar da maior controlabilidade em código do modo de quadratura de extremidade

única, a rotina desenvolvida se demonstrou pouco eficiente no cálculo de posicionamento
e não intuitiva de receber debugging. Desse modo, passou-se para a próxima abordagem,
de realizar o cálculo através do modo diferencial. Este modo se mostrou de mais simples
implementação, pelo fato do cartucho NI 9411 ser capaz de transmitir a informação de
pulsos em número de posicionamento, por ser previamente produzido com o objetivo de

participar de em tarefas de encoding.
Tendo de posse do posicionamento vindo do NI 9411, devemos agora transformar
o dado do contador em uma medida útil para operação de perfuração. Assim, devemos
calibrar as medidas do sensor de pulsos para metros. A rotina de calibração segue uma
interpolação polinomial de três pontos, em que o operador escreve no input da calibração
a posição em metros do centro do gancho. Assim a informação entra no interpolador de
forma (x, y) = (Npulsos , Pmetro ). A medida que o sistema é capaz de identificar a posição
do gancho em metro, é possível começar a registrar a profundidade ganha no processo
de adição de tubulação. É adicionado um botão chamado de “desacunhar” que quando
acionado, soma o ganho de profundidade do movimento de tubulação. Caso este botão
seja despressionado, o operador pode mover livremente o gancho, sem alterar o valor de
profundidade. A representação dessa rotina de código se encontra presente na Figura 30.
Figura 30 – Rotina do modo diferencial, calibração e cálculo de profundidade
4.1.6 Tratamento de erro e prevenção de falha

Com o propósito de deixar a movimentação de tubulação segura, foi integrada à
rotina de atuação da plataforma um intertravamento de erro na leitura dos sensores. O
intertravamento realiza um merge entre as saídas de erro dos elementos de entrada do
sistema e retorna um cluster de erro geral. A presença de erro nesse cluster serve como
seletor em uma estrutura de case. Esta estrutura deixa a arquitetura de atuação seguir
seu fluxo de dados naturalmente, caso não haja nenhum erro presente. Entretanto, em
caso contrário, o cluster é avaliado por um bloco de catalogação de erro. No caso em que
o erro não seja catalogado como um erro crítico, a arquitetura de atuação segue o fluxo
de dados. Por fim, em caso contrário, em que o sistema cataloga um erro crítico, o freio
eletromecânico é acionado e o sistema de movimentação é travado. Além disso, o buzzer
de emergência alterna sua ativação de dois em dois segundos, para denunciar uma falha
detectada por software.
Figura 31 – Modificação da rotina de atuação do guincho para abarcar situações com erro
4.2 Sistema de Interface de Usuário

Nomeado de Sistema de Interface de Usuário (IU), nos referimos as rotinas desen-
volvidas para produção do IHM, armazenamento e calibração dos dados de operação. Este
sistema é hospedado em um computador Windows, localizado no ambiente da mesa de
operação, evidenciado na Figura (19).
4.2.1 QMH da Interface de Usuário

A estrutura de Queued Message Handler do IU, diferentemente do RT, possui as
duas estruturas convencionais do padrão de projeto, o EHL e o MHL. Dentre os eventos
eventos cadastrados no EHL e estados pertencentes ao MHL, temos:
• EHL:
– Botão Operar/Configurar: verifica a mudança de lógica digital nos botões

de operação e produz a mensagem “Tab Home”, para ser consumido no próprio
IU;
– Botão Exit: verifica o pressionamento do botão Exit. Em caso do Control
State estar selecionado no modo Safe State, o evento produz a mensagem Exit
para o MHL do IU. Entretanto, caso o Control State esteja em modo Running,
o evento produz a mensagem Update System Status;
– Botão Connect: verifica o pressionamento do botão Connect. Após a veri-
ficação que o sistema não se encontra conectado ao RT, o evento produz a
mensagem Connect;
– Mudança de IP: verifica a mudança de valor na string de IP. Produz a
mensagem IP Change;
– Seleção no Control State: verifica a mudança de seleção no seletor do Control
State. Produz a mensagem Control System atrelado ao dado modo selecionado.
• MHL:
– Initialize: rotina que inicia a visualização do sistema. Além disso, o sistema

escolhe a tela de configuração como a seleção inicial de telas. Por fim, a rotina
produz a mensagem Connect;
– Connect: estrutura que insere o IP escolhido no bloco de criação de conexão.
Dentro desse bloco, são criados os Endpoints de leitura e escrita entre os
hardwares e as referências das variáveis do tipo Network-Published. O sistema
ainda é encarregado de notificar no log da interface se a conexão foi bem
sucedida. Por fim a estrutura produz a mensagem Get Control Settings from
RT ;
– Get Control Settings from RT : rotina que cria uma requisição de configu-
ração de sistema do RT. Esse estado é feito como garantia que o sistema RT
está em estado pronto para operação;
– Control System: rotina que requisita uma mudança no modo Control State
para o RT.
– IP Change: programação utilizada para alterar o valor da string que contém
o IP do RT, na configuração de conexão;
– Tab Home: rotina de mudança de telas na interface de usuário. Responsável
por intercambiar a exibição das telas de operação e configuração;
– Update System Status: sistema responsável pela exibição dos erros percebidos
pelos blocos de resolução de erro do LabVIEW;
– Exit: rotina responsável pela finalização da FIFO de mensagens, excluir os
eventos pendentes, fechar a conexão com o RT e parar os laços de repetição.
4.2.2 Conexão com os elementos monitorados pelo sistema Real Time

A interface tem como principal função a de receber os dados adquiridos pelo RT e
apresentá-los ao operador da plataforma, bem como ser capaz de manipular estes dados.
Para isso, são criadas Shared Variables do tipo Network-Published e é estabelecida a

conexão dessas entradas e saídas entre os dois sistemas (RT e IU). Além disso, durante
a inicialização do sistema IU, são criadas variáveis globais de referência. Estas variáveis
têm como utilidade a possibilidade serem utilizadas como E/S em blocos de leitura
baseados em conexão Network-Published programática. Dessa forma, uma conexão de
forma programática garante uma maior controlabilidade e eficiência na transferência
de dados. Como é explicitado na Figura 32, parte das conexões são feitas de forma
programática e outra parte é feita de forma direta. De maneira preferencial, estas conexões
devem ser feitas de forma programática. Entretanto, pelo fato do sistema ainda estar sendo
testado e permanecer em fase de expansão, foi decidido que algumas das novas conexões
seriam feitas de forma direta, afim de garantir um maior dinamismo e intuitividade visual
na programação.
Dentre as conexões firmadas dentro da rotina temos:
• De forma programática:
– Valor bruto (em mA) dos sensores analógicos de pressão, nível, fluxo, tempera-
tura, densidade e carga;
– Valor lógico dos elementos digitais status do inversor, bomba de mistura, motor
hidráulico, botão de emergência, freio eletromecânico, comando de subida do
gancho e comando de descida do gancho.
– Valor (em porcentagem) do uso dos processador do RT.
• De forma direta:
– Recebe do RT os valores numéricos do cálculo de RPM, contagem de pulsos

do Encoder, posição vertical do gancho e profundidade do poço preenchida por
tubulação na operação;
– Envia para o RT os sinais digitais representantes dos botões “Atualizar Cali-
bração”, “Resetar Calibração” e “Desacunhar”, para a rotina que comanda o
funcionamento do Encoder. Além disso, manda o dado numérico do seletor de
posição vertical para rotina de calibração do Encoder.
Figura 32 – Rotina monitoramento dos sensores
4.2.3 Calibração dos Sensores

Para realizar o monitoramento eficaz das variáveis do sistema, faz-se necessária a
tradução das saídas dos elementos sensores em unidades de engenharia. Esta necessidade se
deve ao fato da aquisição de dados analógicos, pelo cartucho NI 9408, retornar os valores de
corrente elétrica, retornada pelos elementos sensores. Desse modo, faz-se uma interpolação
entre os valores referência em unidades de engenharia com os limites de operação dos
sensores, pela sua faixa de corrente. Para realizar a calibração seguindo estes preceitos,
foi criada uma rotina que realiza os passos de calibração de acordo com a interação do
usuário. Assim a rotina fica caracterizada por:
1. O sistema recebe como parâmetro uma matriz de calibração C 6x4, tal que:
a) A linhas representam os seis (6) parâmetros calibráveis: Pressão, Nível do

Tanque de Lama, Fluxo, Temperatura da Lama, Densidade da Lama e Carga
Tencionada pelo Guincho;
b) As colunas representam os dois pontos de referência para interpolação, sendo
em ordem: y1 , y2 , x1 , x2 .
2. Caso o interruptor “Habilitar Calibração” esteja ativado o fluxo de dados continua

com a rotina de calibração, caso contrário o sistema espera a próxima iteração do laço
de repetição e segue até o momento pré-interpolação, com a matriz C inicializada;
3. Verifica-se o pressionamento do botão “Resetar configuração” e da variável seletora

de sensor (enum de inteiro). Caso o botão tenha sido pressionado, o sistema substitui
a linha representante do sensor selecionado por uma linha [0, 0, 4, 20]. Desse modo
a rotina impõe que o resultado da interpolação seja sempre igual a zero no sensor
escolhido. De outra forma, caso o botão não tenha sido pressionado o sistema continua
seu fluxo de funcionamento;
4. Como último botão no fluxo de calibração, verifica-se o botão “Atualizar Calibração”.

No caso do botão ter sido pressionado a rotina repõe a linha representante do sensor
selecionado por uma linha que concatena dois pontos numéricos selecionados pelo
usuário para participar da interpolação. Caso os pontos tenham sido, por exemplo,
A e B, a linha formada na calibração é [Ay , By , Ax , Bx ]. Por fim, no caso do botão
não ter sido pressionado, o sistema segue com o fluxo de dados até o momento
pré-interpolação;
5. Ao fim dos passos anteriores, o sistema realiza o tratamento dos dados, dando início
a rotina de pré-interpolação:
a) A matriz C é “quebrada” em 6 vetores 1x4. Cada vetor representa os parâmetros

de um sensor calibrado;
b) Cada vetor 1x4 é dividido ao meio, oque forma dois vetores 1x2. Cada vetor
menor é representante de um eixo de calibração. Nesse caso, um representa
[y1 , y2 ] e o outro representa [x1 , x2 ].
6. No momento da calibração cada par de vetores menores alimenta um bloco de

interpolação polinomial, que então retornará um valor numérico y para qualquer
valor x de entrada. Assim na entrada x, conectamos o valor de retorno do sensor em
miliamperes e o sistema retorna na saída y a correlação desse valor na variável de
engenharia, como pound force per square inch (PSI) para o sensor de pressão.
Vale ainda evidenciar uma funcionalidade adicional ao sistema de calibração. Para

cada ação de “Resetar” e “Atualizar” o sistema apresenta mensagens para o usuário
diretamente nos logs do sistema, acessível no IHM. Levando em consideração o sensor de
pressão da plataforma em um data fictícia, a rotina apresenta as mensagens:
• Resetar:
– “31/12/2022 - 23:59:59: Pressão resetada.”.
• Atualizar:
– “31/12/2022 - 23:59:59: Pressão atualizada.”;

– “X1 = Ax | Y1 = Ay ”;
– “X2 = Bx | Y2 = By ”.
A rotina em LabVIEW do método de calibração pode ser vista na Figura 33.

Figura 33 – Rotina de calibração
4.2.4 Armazenamento de parâmetros de calibração

Afim de manter os dados de calibração após o término do momento de operação,
devemos ser capazes de armazenar os pontos utilizados nos blocos de interpolação, para
todos os elementos sensores envolvidos no sistema. Assim, denota-se que precisamos salvar
os dados em um arquivo local, que contenha todas as variáveis necessárias para recriação
da matriz de calibração C. Para isso, foram desenvolvidas duas rotinas que lidam com os
momentos e ações de criação, leitura e escrita de parâmetros de inicialização.
A primeira rotina, visível na Figura 34, constrói o caminho do diretório usado no
computador e procura um arquivo com nome padronizado do tipo “.ini”, que representa
um arquivo de inicialização de parâmetros. Caso este arquivo não tenha sido encontrado
no diretório especificado, o sistema o cria e retorna true na flag que sinaliza a criação do
arquivo. A informação da flag serve de seletor em uma estrutura de case. Dessa forma, a
estrutura pode se comportar de duas formas diferentes:
Figura 34 – Rotina de Armazenamento de Parâmetros, flag em false
1. Caso a flag retorne o valor false, Figura 34, significa que o sistema conseguiu
identificar o arquivo de inicialização e não precisou criá-lo. Assim, procedemos com
a leitura dos parâmetros presentes no arquivo. Por duas estruturas de for, que criam
a matriz de calibração C. O for mais interno lê os quatro parâmetros de um sensor,
devolvendo uma vetor 1x4 com os valores dos pontos de calibração. Já for mais
externo replica seis (6) vezes a aquisição do vetor de um sensor, assim formando
uma matriz 6x4 pela concatenação desses vetores. Esta matriz é usada como entrada
na rotina de calibração;
2. Caso a flag retorne o valor true, Figura 35, significa que o sistema não encontrou o
arquivo de inicialização de parâmetros e precisou criar um arquivo no diretório local.
Desse modo, o fluxo da rotina segue montando uma matriz 6x4 pela concatenação de
seis (6) vetores padronizados com valores [0, 0, 4, 20]. Esta matriz é escrita, seguindo
o mesmo método de leitura, no arquivo recém criado. Por fim, passa-se a matriz
para o canal de entrada da rotina de calibração.
Figura 35 – Rotina de Armazenamento de Parâmetros, flag em true
A segunda rotina de armazenamento, Figura 36, se encontra dentro do laço de

repetição que contém a rotina de calibração. Esta rotina é ativada sempre que o botão
“Salvar Calibração” é acionado. O sistema segue, utilizando o método de duas estruturas for,
escrevendo no arquivo “ini” o resultado das modificações feitas na matriz de calibração 6x4.
Além disso, o sistema adiciona uma mensagem na caixa de mensagens de logs, informando
a data e hora de armazenamento dos parâmetros de calibração.
Figura 36 – Rotina de Armazenamento de Parâmetros pertencente a Rotina de Calibração

4.2.5 Criação de dataset de operação em CSV

Para que os dados colhidos dos sistemas de sensoriamento e parametrizados através
da interpolação tenham utilidade além da supervisão momentânea do sistema, faz-se
necessário o correto armazenamento do dataset de cada operação. Para isso, foi desenvolvida
uma rotina responsável pela criação e escrita dos dados de operação em uma tabela, de
tipo “CSV”. A formatação do arquivo deve seguir o modelo da Tabela 4.
Tabela 4 – Organização de cabeçalho do arquivo CSV
Hora/Data Pressão (psi) Nível (bbl) Fluxo (%) Temperatura (°C) Densidade Carga (ton) Profundidade (m)
A rotina desenvolvida segue dois estados sequenciais para correto funcionamento e

organização de arquivos de dataset. Estes momentos são:
• Idle: este é o estado inicial de espera e ao mesmo tempo responsável pela pela
criação do arquivo. Enquanto a checkbox de confirmação não for ativada, o sistema
espera o início do próximo laço de repetição. Entretanto, caso a checkbox venha a ser
acionada, a rotina cria no diretório local de documentos um arquivo CSV que contém
os elementos organizados na formatação da Tabela 4. Ademais, a nomeação do
arquivo no diretório local segue um padrão que explicita a data e hora de requisição
do armazenamento das variáveis do sistema. Terminada a rotina, o estado “Idle”
transita para o estado “Save”;
Figura 37 – Rotina “Idle” do CSV
• Save: este estado é responsável por escrever linhas na tabela presente no arquivo
CSV, a cada três (3) segundos. A rotina desse estado adquire o tempo atual do
sistema, junto dos valores presentes em cada um dos sensores. Ao adquirir estes
dados, os valores numéricos são traduzidos para strings e concatenados em ordem
pré definida. Subsequentemente, o resultado da concatenação dos strings é usado de
entrada no bloco responsável pela escrita na tabela CSV. Caso a checkbox continue
acionada, o estado se mantém em “Save” por mais três segundos, até que ele faça
uma nova verificação do valor da checkbox. No caso de desativação, o estado transita

de “Save” para “Idle”.
Figura 38 – Rotina “Save” do CSV
4.2.6 Organização visual da IHM

Para tornar o software desenvolvido em uma ferramenta utilizável, foi preciso de-
senvolver uma IHM intuitiva, que abarque todas as conexões com os métodos programados
e apresente um design agradável. Para isso, foi pensada em uma configuração base, que
figure o status de conexão do RT com o IHM, junto da data e hora atual do sistema. Para
explicitar os dados adquiridos e processados do sistema, foi usada uma estrutura de Tab
Control do LabVIEW. Nessa estrutura, foram criadas duas abas, que dividem a tarefa
de representar a sessão de E/S do sistema, a aba “Operar” e “Configurar”. Por fim, para
realizar a mudança de abas, foram conectados dois interruptores em forma de botão, para
representar a seleção da aba desejada.
4.2.6.1 Tela “Operar”
A Tela “Operar” tem como objetivo ser a tela principal de atuação e monitoramento
do sistema. Desse modo, sua composição compreende:
• Quatro (4) sinalizadores do tipo led que indicam o estado de funcionamento do

Inversor de Frequência, Motor Hidráulico, Bomba de Mistura e o acionamento do
Botão de Emergência;
• Dois (2) sinalizadores personalizados que indicam o comando de movimento vertical

do gancho, na plataforma de perfuração. Um sinalizador representa o movimento de
subida, em consequência o outro sinaliza o movimento de descida;
• Uma caixa de texto que indica o funcionamento do freio eletromecânico responsável

por impedir o movimento rotacional do guincho. Esta caixa apresenta as strings
“Ativado” e “Desativado”;
• Um seletor de ativação das rotinas de controle. Este seletor, quando selecionado

em “Ligado”, habilita a mudança de momentos do sistema de “Safe State” para
“Running”. Esta funcionalidade será explorada em projetos de expansão futuros;
• Dez (10) indicadores numéricos, subdivididos em três funções distintas:
1. Seis (6) indicadores dedicados a explicitar os valores dos sensores previamente

adquiridos pelo sistema real time e interpolados pela rotina de calibração.
2. Um indicador de RPM de funcionamento da bomba de lama;
3. Três (3) indicadores relacionados às rotinas do Encoder. Dentre elas a contagem
de pulsos dados pela rotação do motor do guincho, posição vertical em metros
do gancho e contagem de profundidade do poço.
• Dois (2) botões e um interruptor que comandam os processos de cálculo de profundi-

dade e calibração do Encoder. Entre os botões temos o de “Atualizar Calibração”,
que quando pressionado adiciona os parâmetros de calibração, selecionados na tela,
no vetor de calibração do Encoder, que por sua vez é usado no processo de inter-
polação. Além do botão “Resetar calibração” que reinicia os parâmetros numéricos
que populam o vetor de calibração do Encoder. Por fim, o interruptor “Desacunhar”
ativa o efeito de soma do ganho de profundidade, pela movimentação de tubulação.
• Um seletor numérico que define o valor do posicionamento do gancho (em metros)

por ponto flutuante. Este valor representa um ponto no eixo das ordenadas, que será
usado para compor as entradas do bloco interpolador.
Figura 39 – Visualização da tela “Operar”
4.2.6.2 Tela “Configurar”
A Tela “Configurar” tem como objetivo ser uma tela secundária, tendo como cerne
a configuração, conexão e calibração do sistema. Dessa forma, sua composição compreende:
• Uma entrada de string para mudança de IP de conexão com o CompactRIO 9053,

em caso de mudança de faixa de rede. Junto a um botão que confirme a mudança
desse novo IP;
• Dois (2) gráficos que explicitem o consumo de processamento dos sistema envolvidos
na operação, sendo o processador que roda a rotina de interface do usuário e o
processador do cRIO;
• Três (3) indicadores de diretório para sinalizar os diretórios onde serão salvos os
arquivos de calibração de sensores, encoder e o dataset de operação;
• Um checkbox para habilitação do modo “Save” na rotina de armazenamento e criação

do arquivo CSV;
• Uma caixa de logs do sistema. Responsável por alertar as operações mais recentes
feitas pelo usuário e manter um histórico operacional;
• Seis (6) indicadores numéricos para informar ao usuário a aquisição dos dados brutos
advindos dos sensores instalados na plataforma de perfuração. Estes dados são
formatados para retornar o valor em miliamperes;
• Uma lista seletora de sensores, para lidar com a escolha de que sensor terá seu vetor,
participante da matriz da calibração, reiniciada ou atualizada;
• Três (3) botões e um interruptor, que atuam como os ativadores das rotinas de
calibração e armazenamento. Assim, representam os elementos “Salvar Calibração”,
“Resetar Calibração”, “Atualizar Calibração” e “Habilitar Calibração”;
• Quatro (4) seletores numéricos que definem valores em ponto flutuante. Estes dados
irão participar como referência para o interpolador polinomial e atuar na atualização
da calibração. Dessa forma, substituem-se os valores anteriormente presentes nos
vetores que formam a matriz de calibração.
Figura 40 – Visualização da tela “Configurar”

63
5 Resultados
5.1 Resultados do Sistema Real Time

O módulo de atuação do Sistema Real Time foi testado em ocasiões reais de retirada
e inserção de tubulação no poço presente na base da Geowellex. Durante o processo, o
sistema não apresentou nenhuma falha na aceitação e resposta dos comandos de atuação.
Foram testados, metodicamente, os elementos visíveis na seção 2.3 e os resultados obtidos
foram:
• As três (3) chaves de tipo Switch conseguem acionar devidamente o Inversor de

Frequência e os Soft-Starters responsáveis pelo Motor Hidráulico e Bomba de Mistura.
Isto pode ser verificado pelo acionamento dos três (3) sinalizadores luminosos e a vi-
sualização de atuação dos elementos na plataforma de operação. Este comportamento
pode ser visto nas Figuras 41, 42, 43, 44 e 47.
Figura 41 – Inversor ligado pelo acionamento da chave do inversor

Capítulo 5. Resultados 64
Figura 42 – Soft-Starter da bomba de mistura acionada pela chave da bomba de mistura
Figura 43 – Mesa de operação com os sinalizadores indicando o inversor e bomba de

mistura acionada

Figura 44 – Efeitos do acionamento da Bomba de Mistura
• Um botão normalmente fechado especial para emergência é capaz de interromper

a movimentação do gancho e desligar os motores presentes na atuação do sistema,
além de ativar o Buzzer de sinalização de emergência. Comportamento visível nas
Figuras 45 e 48.
Figura 45 – Mesa de operação com o botão de emergência pressionado e o buzzer acionado
• O joystick de três fases, consegue comandar devidamente a movimentação do gancho

na plataforma de operação. Comportamento visível nas Figuras X5.
Afim de verificar a atuação, em audio e vídeo, dos elementos controlados, é possível

assistir os vídeos dos testes presentes no link <https://1drv.ms/u/s!AtvJ3-Q4tWjTgqx_
kDU6bH8gqnS2Mg?e=Nv3qm0>.
5.2 Resultados do Sistema IU

O sistema de Interface do Usuário respondeu de forma congruente com seu propósito
operacional. Explicitado pela Figura 46, o sistema de configuração é capaz de mostrar
corretamente o gráfico de uso dos processadores do RT e IU, eficaz na apresentação
das operações realizadas pelo log do sistema e efetivo na exibição dos valores brutos
dos sensores, capturados pelo RT. Ademais, as rotinas de calibração e armazenamento
de arquivos “ini” e “csv” retornaram resultados frutíferos, notórios pela observação do
operador.
Figura 46 – Tela de Configuração em funcionamento
Ao visualizar a tela de operação, explicitada nas Figuras 47 e 48, torna-se evidente

seu correto funcionamento. O sistema é capaz de evidenciar o estado de operação da bomba
de mistura e moter hidráulico, bem como o status do inversor. Outrossim, a operação é
capaz de exibir os valores calibrados dos sensores da plataforma. Não obstante, é visível
pela Figura 47 alguns valores não retornados pela tela. Dentre eles:
• Densidade: apesar de receber o sinal da corrente pelo RT. O valor se encontra

em zero (0) para evidenciar um valor não calibrado durante a operação da tela de
configuração;
• Carga: o valor encontra-se em zero (0) pelo fato de não estar devidamente conectado
ao hardware do sistema. Este comportamente pode ser verificado pelo retorno de 0
mA na Figura 46;
• RPM: o valor está relacionado as revoluções dadas pela bomba de lama, que tem
como sua força motriz o motor a diesel. Durante o teste feito para captura dessas
imagens, não foi possível opera-la. Entretanto, durante a construção das rotinas, esse
valor foi corretamente detectado pelo software;
• Profundidade do Poço: Durante o teste feito para captura dessas imagens, não
estava planejada nenhuma inserção ou retirada de tubulação. Dessa forma, o numérico
se encontrou zerado.
Por fim, evidenciado na Figura 48, o sistema é capaz de acionar um modo de

segurança que impõe o desligamento dos elementos motores da plataforma, independente
do estado de suas chaves, e ativa o freio eletromecânico, quem tem sua mudança de
operação bem evidenciada pela diferença entre a Figura 47 e 48.
Figura 47 – Tela de Operação em funcionamento
Figura 48 – Tela de Operação em modo de emergência

69
6 Conclusões
6.1 Conclusões acerca do projeto desenvolvido

O desenvolvimento de um sistema de atuação e monitoramento que entra em
contato com elementos reais, de utilização em ambientes empresariais e de operação, capaz
de auxiliar em tarefas com aplicabilidade factual, foi de frutífera importância para prática
e conhecimento das habilidades desenvolvidas durante a graduação.
A produção do sistema, trouxe o desenvolvimento de bagagem teórica e prática
acerca das principais práticas relacionadas aos elementos comumente usados na área de
automação e instrumentação industrial. Ademais, como cerne do projeto, a produção desse
trabalho proporcionou o aprendizado da construção de rotinas em ambiente LabVIEW,
garantindo a segurança e robustez dos métodos de resolução e desenvolvendo o entendimento
crítico acerca dos padrões de projetos em escala profissional.
Os resultados colhidos do trabalho realizado foram a exteriorização da consequência
de uma boa vivência profissional. Os objetivos esperados pelo planejamento do projeto
foram alcançados, resultando em um sistema que apresenta uma boa base de expansão
para operações de atuação, controle e sensoriamento de ambiente de trabalho na área
industrial petrolífera.
6.2 Planos futuros de expansão do sistema

Apesar do êxito na produção do projeto esperado, e das funcionalidades presentes
serem suficientes para o processo de operação, o sistema ainda encontra-se em expansão.
Dessa forma, dentre as ideias de adição e modificação do sistema, estuda-se:
• Uma reorganização geral para adequar todas as rotinas ao padrão de projeto do tipo
Produtor/Consumidor, através do QMH;
• Desenvolver uma interface de comunicação capaz de guardar os dados sensoriados

em um banco de dados relacional, de forma automatizada;
• Instalar e adequar ao código de controle novas ferramentas de atuação e sensoriamento

à plataforma.
Dessa forma, além de manter o sistema mais robusto e funcional, pretendemos

exercitar um dos principais preceitos da prática da engenharia. O preceito da inovação,
Capítulo 6. Conclusões 70
que nos rege a sempre buscar pela otimização de nossas práticas e a evolução de nossas
criações.
71
Referências
BRADLEY, H. B. Petroleum Engineering Handbook. [S.l.: s.n.], 1987. 1 p. ISBN

1-55563-010-3. Citado 2 vezes nas páginas 11 e 12.
CHAPRA, S. C. Métodos Numéricos para Engenharia. [S.l.: s.n.], 2008. 409 p. ISBN
978-85-8055-011-5. Citado 2 vezes nas páginas 12 e 33.
CORMEN, T. H. Algoritmos: Teoria e Prática. [S.l.: s.n.], 2012. 200 p. ISBN

DAGHLIAN, J. Lógica e Álgebra de Boole. [S.l.: s.n.], 1995. 106-114 p. ISBN

THOMAS, J. E. Fundamentos de engenharia de petroleo. [S.l.: s.n.], 2001. 1 p. ISBN

85-7193-046-5. Citado 2 vezes nas páginas 11 e 12.
VAHID, F. Sistemas digitais: projeto, otimização e HDLs. [S.l.: s.n.], 2008. 7-89 p. ISBN
978-85-7780-190-9. Citado 5 vezes nas páginas 12, 29, 30, 31 e 32.
PONTES, Anderson. Produção de Petróleo e Gás: Perfuração, Completação, Elevação e

Recuperação. 10 de Abr de 2015. Apresentação do Power Point. Disponível em: <https:
//pt.slideshare.net/dissonpontes/perfurao-46865081>. Acesso em 20 jun. 2022.
UNITED STATES DEPARTMENT OF LABOR. Drilling Rig Components. Occupational

Safety and Health Administration, 2001. Disponível em: <https://www.osha.gov/etools/
oil-and-gas/illustrated-glossary>. Acesso em: 20 jun. de 2022.
NATIONAL INSTRUMENTS. Using a Queued Message Handler in LabVIEW. NI, 2022.

Disponível em: <https://www.ni.com/pt-br/support/documentation/supplemental/21/
using-a-queued-message-handler-in-labview.html>. Acesso em: 30 jun. de 2022.
NATIONAL INSTRUMENTS. Local Variables, Global Variables, and the Feedback

Node. NI, 2022. Disponível em: <https://www.ni.com/docs/en-US/bundle/labview/page/
lvconcepts/local_and_global_variables.html>. Acesso em: 26 jun. de 2022.
NATIONAL INSTRUMENTS. Using the LabVIEW Shared Variable. NI, 2022. Disponível
em: <shorturl.at/fhuY2>. Acesso em: 26 jun. de 2022.
NATIONAL INSTRUMENTS. Lossless Communication with Network Streams: Compo-

nents, Architecture, and Performance. NI, 2022. Disponível em: <shorturl.at/bkpu6>.
Acesso em: 26 jun. de 2022.
Referências 72
NATIONAL INSTRUMENTS. Handling Errors. NI, 2022. Disponível em: <https://www.ni.

com/docs/en-US/bundle/labview/page/lvconcepts/error_checking_and_error_handling.
html>. Acesso em: 26 jun. de 2022.
NATIONAL INSTRUMENTS. Difference Between Single-Ended and Differential Quadra-

ture Encoders With NI DAQ Cards. NI, 2022. Disponível em: <https://knowledge.ni.com/
KnowledgeArticleDetails?id=kA03q000000YI7DCAW&l=pt-BR>. Acesso em: 6 jul. de
2022.
NATIONAL INSTRUMENTS. Wiring an Encoder to the NI 9411 Module. NI, 2022.

Disponível em: <shorturl.at/eloC7>. Acesso em: 6 jul. de 2022.
NATIONAL INSTRUMENTS. NI Hardware Encoder Measurements: How-To Guide. NI,

2022. Disponível em: <shorturl.at/APVWX>. Acesso em: 6 jul. de 2022.

InstrumentaçãoeAutomaçãoLaboratorial Cassel 2022

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

InstrumentaçãoeAutomaçãoLaboratorial Cassel 2022

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Federal do Rio Grande do Norte

Instrumentação e Automação Laboratorial:

Iago Pereira Cassel

Instrumentação e Automação Laboratorial: Projeto e

Trabalho de Conclusão de Curso apresentado

Universidade Federal do Rio Grande do Norte (UFRN)

Orientador: Samaherni Morais Dias

Cassel, Iago Pereira.

Monografia (Graduação) - Universidade Federal do Rio Grande do Norte, Centro de Tecnologia,

1. Plataforma de Perfuração - Monografia. 2. National Instruments - Monografia. 3. LabVIEW

RN/UF/BCZM CDU 004.4

Elaborado por Raimundo Muniz de Oliveira - CRB-15/429

Instrumentação e Automação Laboratorial: Projeto e

Trabalho aprovado. Natal, 29 de julho de 2022:

Samaherni Morais Dias

Kurios Iuri Pinheiro De Melo Queiroz

Joilson Batista De Almeida Rego

Palavras-chave: Plataforma de Perfuração; National Instruments; LabVIEW; Atuação;

Keywords: Drilling Platform; National Instruments; LabVIEW; Control; Data acquisi-

UFRN Universidade Federal do Rio Grande do Norte

GLP Gás Liquefeito de Petróleo

FIFO First In, First Out

IHM Interface Homem-Máquina

QMH Queued Message Handling

EHL Event Handler Loop

MHL Message Handling Loop

SPSV Single Process Shared Variable

NPSV Network-Published Shared Variable

RT Sistema Real Time

IU Sistema de Interface de Usuário

RPM Rotações Por Minuto

PSI Pound Force per Square Inch

CSV Comma-Separated Values

O registro da participação do petróleo na vida do homem remonta a

Entretanto, apesar da presença cultural do petróleo nos povos antigos, o primeiro

1.3 Revisão Bibliográfica

1.4 Visão geral dos capítulos seguintes

A Geowellex do Brasil Serviços Petrolíferos LTDA é uma empresa nacional que

Figura 1 – Base da Geowellex em Macaíba

Fonte: Autoria Própria

2.1 Instalação Mecânica

Figura 2 – Plataforma de Perfuração e seus equipamentos

O sistema instalado na base apresenta os elementos:

• Torre de Perfuração (Derrick): estrutura metálica vertical que serve de cerne

• Bloco de Coroamento (Crown Block): circuito de polias estacionárias com o eixo

• Catarina e Gancho (Traveling Block e Hook): bloco que conta com um

• Power Swivel: diferente do esquematizado na imagem 2, a plataforma presente na

É possível visualizar os elementos citados na imagem real do ambiente de trabalho,

Figura 3 – Plataforma de Perfuração e localizada na base da Geowellex

Fonte: Autoria Própria

2.1.2 Elementos adjacentes à Torre de Perfuração

Figura 4 – Motor Guincho

Fonte: Autoria Própria

• Rampa e e gaveta de tubulação (Pipe Ramp e Pipe Racks): estrutura

Figura 5 – Rampa e e gaveta de tubulação

Fonte: Autoria Própria

• Bomba de Lama (Motor a Diesel): um motor alimentado por combustível

Figura 6 – Motor a Diesel

Fonte: Autoria Própria

• Tanque de Lama e Bomba de Mistura (Mud Tank e Mud Pump): estrutura

Figura 7 – Tanque de Lama

Fonte: Autoria Própria

Figura 8 – Bomba de Mistura

Fonte: Autoria Própria