REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA

EDUCACION UNIVERSITARIA
INSTITUTO UNIVERSITARIO POLITÉCNICO
“SANTIAGO MARIÑO”
EXTENSIÓN - MATURÍN

SISTEMA AUTOMATIZADO DE MONITOREO DE POZOS PETROLEROS

(SAMPP)

Autor:
Christian López C.I: 29.914.335

Febrero, 2025
 MARCO CONCEPTUAL Y ANÁLISIS
Planteamiento del Problema

En la industria de hidrocarburos, la monitorización de las variables de presión, temperatura

y caudal es vital para la seguridad operativa. La ausencia de un sistema automatizado
conlleva a una toma de decisiones lenta y a errores en la transcripción de datos históricos.
El SAMPP surge como una solución de software para centralizar la lectura de sensores y
automatizar la generación de reportes técnicos.
Especificación de Requisitos

Funcionales:

Captura y procesamiento de datos de sensores cada 15 segundos.

Clasificación dinámica de estados (Normal, Advertencia, Peligro) según umbrales

predefinidos.

Exportación de datos históricos a formato Excel cada 30 minutos o bajo demanda.

No Funcionales:

Portabilidad: Ejecución en entornos Windows/Linux mediante Python.

Concurrencia: Gestión de hilos (threading) para evitar bloqueos en la interfaz de usuario.

Usabilidad: Interfaz minimalista con feedback visual inmediato mediante colores.

DISEÑO DE LA SOLUCIÓN

Diagrama de arquitectura
El sistema se divide en tres niveles de responsabilidad:
Capa de Presentación (Frontend): Lo que el usuario ve. En tu caso, la ventana de Flet con
las tarjetas de colores y el botón de reporte.

Capa de Lógica de Negocio (Backend): El "cerebro". Aquí reside el validador de rangos

(get_estado) y el simulador que corre en hilos secundarios (threading).

Capa de Datos: Donde se guarda la información. Actualmente es el sistema de archivos que

almacena los .xlsx generados por Pandas.
Diagrama de casos usos

Diseño de datos
Elementos del Diagrama

• Entidades (Rectángulos): Los objetos principales (Pozo, Sensor, Lectura).

• Atributos (Óvalos o dentro del cuadro): Las características (ID, Valor, Fecha).
• Relaciones (Rombos o líneas): Cómo se conectan (Un pozo tiene sensores).

Explicación de las Relaciones (Cardinalidad)

Para tu defensa del trabajo, es importante entender por qué las líneas tienen esas formas:
POZO a SENSOR (1:N): Un pozo es una unidad física única, pero puede tener instalados
múltiples sensores (uno de presión, otro de temperatura, etc.).

SENSOR a LECTURA (1:N): Un solo sensor genera miles de registros a lo largo del
tiempo. Cada fila en tu archivo Excel actual representa una "Lectura" vinculada a un sensor
específico.

Mockups/Prototipo
Front (Python, Flet)
Reporte Generado (Excel)

¿Como se construiría el programa completo? (teóricamente)

Dividido en capas quedaría así:

Capa 1: Sensores Físicos en el Pozo

Sensor Medición Rango Protocolo de salida

 Presión diferencial Presión en cabeza y 0-5000psi 4-20 mA, HART,
fondo del pozo RS-485
Termopar/RTD Temperatura del -50°C a 200°C 4-20 mA, Modbus
fluido RTU
Medidor de flujo Caudal de 0-500 bbl/día Pulse, Modbus TCP
másico petróleo/gas/agua
Vibración Estado mecánico de 0-20g 4-20 mA, Modbus
bombas
Nivel de fluido Altura de fluido en 0-3000m Radar, ultrasonido
el pozo

Estos sensores no generan datos "listos": su salida es analógica (4-20 mA) o digital
(Modbus), y deben ser interpretados por un dispositivo de borde.

Capa 2: Dispositivo de Borde (Edge Device / RTU)

Este es el "cerebro" en el campo. Suele ser una Unidad Terminal Remota (RTU) o un PLC
industrial (ej: Siemens S7, Allen-Bradley), o en aplicaciones modernas, un gateway IoT
industrial (ej: Raspberry Pi con carcasa IP67, Siemens IOT2050, Advantech).

Funciones del dispositivo de borde:

Adquisición de datos: Lee las señales de los sensores.

• Para señales 4-20 mA: usa entradas analógicas.

• Para Modbus: comunica vía RS-485.

Preprocesamiento:

• Convierte mA a unidades ingenieriles (ej: 12 mA → 2500 psi).

• Filtra ruido (promedio móvil, eliminación de picos).
• Valida datos (descarta valores fuera de rango físico).
Almacenamiento local: Guarda datos en una tarjeta SD o memoria interna si hay pérdida de
red.

Comunicación: Envía datos a la nube/servidor.

Protocolos de campo:

• Modbus RTU/ASCII: Serial (RS-485), muy común en sensores industriales.

• HART: Superpone datos digitales sobre señal 4-20 mA.
• Foundation Fieldbus / Profibus: En instalaciones más complejas.

Capa 3: Red de Comunicación

La conectividad depende de la ubicación del pozo:

 Tipo de pozo Tecnología de Características
comunicación
Onshore (Cerca de Fibra óptica, Ethernet, Alta velocidad, baja
infraestructura) 4G/LTE latencia
Onshore (remoto) Radio VHF/UHF, Bajo ancho de banda, alto
LoRaWAN, satélite costo (satélite)
(Iridium)
Offshore Microondas, satélite, fibra Muy alto costo, alta
submarina disponibilidad requerida

Protocolos de transporte:

MQTT: Ligero, ideal para IoT, soporta desconexiones.

HTTP/HTTPS: Para APIs REST, pero más pesado.

OPC UA: Estándar industrial para interoperabilidad entre sistemas.

Capa 4: Plataforma Central (Backend)

Puede ser un servidor local (en la oficina de campo) o una plataforma en la nube (AWS IoT
Core, Azure IoT Hub, Google Cloud IoT).

Componentes clave:

Broker MQTT: Recibe todos los mensajes de los pozos (ej: Mosquitto, AWS IoT Core).

API REST: Expone endpoints para el frontend (/api/pozos, /api/lecturas).

Base de datos:

• Time-Series Database: InfluxDB, TimescaleDB (optimizadas para millones de

puntos de datos con timestamp).
• Relacional: PostgreSQL (para metadatos: pozos, usuarios, alertas).
Motor de reglas: Evalúa condiciones en tiempo real (ej: "si presión > 3200 psi → enviar
alerta").

Orquestador: Docker/Kubernetes para gestionar microservicios.

Procesamiento de datos:

• Ingesta: Validación y limpieza inmediata.

• Agregación: Cálculo de promedios cada 30 min para reportes.
• Alertas: Notificaciones por email, SMS o integración con sistemas SCADA.

Capa 5: Interfaz de Usuario (Frontend)

Una aplicación web accesible desde cualquier dispositivo.

Funcionalidades:

• Dashboard en tiempo real: Gráficas dinámicas ([Link], Grafana).

• Mapa geográfico: Muestra estado de todos los pozos (Leaflet, Google Maps).
• Gestión de alertas: Lista de eventos, con botón de "acknowledge".
• Generación de reportes: Exportar a Excel/PDF con datos históricos.
• Configuración: Ajustar umbrales de alerta por pozo.

Seguridad:

• Autenticación (OAuth 2.0, SSO corporativo).

• Roles de usuario (operador, ingeniero, administrador).
• Cifrado TLS 1.3 en toda la comunicación.

Sin embargo, la lógica central (análisis, diseño, arquitectura) es la misma. El proyecto con
Flet y datos simulados es una réplica fiel del núcleo funcional de un sistema real, lo cual es
perfectamente válido.

CONCLUSIONES

El uso de la metodología Waterfall permitió definir claramente los límites de seguridad

(rangos) antes de escribir una sola línea de código. Se logró una herramienta que minimiza
el error humano en la recolección de datos y mejora la respuesta ante emergencias mediante
una interfaz reactiva.
RECOMENDACIONES

Integración Real: Se recomienda en futuras fases sustituir el módulo random por una
conexión serial (RS-232/USB) o protocolos industriales (Modbus) para leer sensores reales.

Base de Datos: Migrar la generación de Excel a una base de datos SQL para permitir
consultas históricas más complejas y de mayor volumen.