Integración de un sistema automatizado para medición fiscal y de

UNIVERSIDAD SIMÓN BOLÍVAR
Decanato de Estudios Profesionales
Coordinación de Ingeniería Electrónica
INTEGRACIÓN DE UN SISTEMA AUTOMATIZADO PARA MEDICIÓN FISCAL Y
DE REFERENCIA PARA LAS ESTACIONES DE FLUJO Y PATIO DE
TANQUES DE PDVSA DIVISIÓN CENTRO-SUR.
Por
Víctor René Rodríguez Gutiérrez
Realizado con la Asesoría de
Ing. Cristhian de Castro
PROYECTO DE GRADO
Presentado ante la Ilustre Universidad Simón Bolívar
como requisito parcial para optar al título de Ingeniero Electrónico
Sartenejas, Abril de 2005.
ii
UNIVERSIDAD SIMÓN BOLÍVAR
Decanato de Estudios Profesionales
Coordinación de Ingeniería Electrónica
Integración de un Sistema Automatizado para Medición Fiscal y de Referencia para las
Estaciones de Flujo y Patio de Tanques de PDVSA División Centro-Sur.
PROYECTO DE GRADO presentado por
Víctor René Rodríguez Gutiérrez
REALIZADO CON LA ASESORÍA DE:
Ing. Cristhian de Castro (Tutor Académico)
Ing. Juan Pomares (Tutor Industrial)
RESUMEN
La integración del Sistema Automatizado para Medición Fiscal y de Referencia
basada en el Sistema de Adquisición de Datos en Red Net-DAS y en tecnologías Web para la
visualización de los datos, propone una alternativa para Supervisión y Monitoreo de las
variables de proceso involucradas en la medición en línea en los oleoductos de las Estaciones
de Flujo y Patio de Tanques de PDVSA Distrito Sur. Dicha integración contempla el estudio
integral del funcionamiento del sistema de adquisición de datos y la comprensión de todos los
elementos involucrados: computador modular industrial con estándar PC/104-Plus,
transmisores de campo, servidor Web, entre otros. De esta manera, se puede apreciar los
requerimientos para la selección de los protocolos de comunicación entre las etapas de la
arquitectura y los lenguajes de programación a utilizar para el desarrollo de las aplicaciones,
para plantear una solución para la integración e implementación del sistema. Posteriormente,
se adecuó el despliegue gráfico para mostrar en ambiente Web, los datos recogidos de campo a
través de las redes que se integran al sistema de adquisición de datos.
Se logró presentar una alternativa para la integración del sistema automatizado de
medición en cuestión, que permite un avance en cuanto a características técnicas y mejora en
la relación costo/funcionalidad.
PALABRAS CLAVES
Medición Fiscal y de Referencia, Adquisición de Datos, Supervisión y Monitoreo, Oleoductos,
PDVSA.
Aprobado con mención:
Postulado para el premio:
Sartenejas, Abril de 2005.
iii
Dedico este libro a mis padres y a mi hermanita Carla,
por ser las personas más especiales que conozco en el mundo,
Víctor René.
iv
AGRADECIMIENTO
Por sobre todas las cosas le agradezco a Dios, quién me ha brindado paz, fuerza, gran
paciencia, voluntad, y autodominio, para culminar satisfactoriamente mis metas a lo largo de
mi vida.
A mis Padres, Pedro y Mercedes, a mi Hermanita Carla, quienes con humildad, ánimo,
dedicación y amor, me han apoyado, aconsejado e inspirado para culminar mi carrera.
A abuelita Doris, quien con sus sabios consejos me ha guiado por los caminos
correctos durante toda mi vida.
A mis familiares, Abuela Ángela, Luis Gonzalo, Ludys, Marisela, Tío Rafael, Tía
Chepi, Tía Candi, Cabeto, Tía Negra, Mariela, quienes me han ayudado de alguna manera u
otra a lo largo de mi carrera.
Al ingeniero Juan Pomares, tutor industrial, quien con gentileza y profesionalismo se
esforzó por ayudarme y atender cualquier problema e inquietud durante el desarrollo del
trabajo.
A la ingeniero Teresa De Caires, quién con su dedicación y esfuerzo hizo posible que
llevará a cabo mi trabajo.
Al ingeniero, Cristhian de Castro, tutor académico, por comprometerse y disponer de
tiempo para atender la realización de mi trabajo.
A mis Grandes Amigos quienes compartieron conmigo toda la carrera, ayudándonos
unos a los otros: Fran, Fede, Dioris, Silvia, Antonio, Mara, Álvaro, Gabriel, Max, Francisco,
Gus, Emilio, Lenny, José Rafael, Raúl, Katiuska, Pedro, José Javier, Ian.
A dos Grandes Personas, Martina y Dayana, quienes con su humildad, cariño y amor,
me han ayudado y apoyado en mis cosas.
A mis Amigos y Compañeros de Trabajo quienes me apoyaron y me ayudaron cuando
lo necesité: Ana María, Guillermo, Reneé, Galo, Carlos, Luisa, Grace, Sr. Tony, Kathleen,
Celeste, Romel, Karina.
A todos Muchas Gracias!
v
ÍNDICE GENERAL
RESUMEN
ii
DEDICATORIA
iii
AGRADECIMIENTO
iv
INDICE GENERAL
v
INDICE DE TABLAS
ix
INDICE DE FIGURAS
x
LISTA DE ABREVIATURAS
xii
CAPITULO 1.- INTRODUCCIÓN
1
CAPITULO 2.- PLANTEAMIENTO DEL PROYECTO
6
2.1.- Introducción
6
2.2.- Antecedentes y Justificación
6
2.3.- Objetivos del Proyecto
8
2.4.- Alcance del Proyecto
8
CAPITULO 3.- MARCO TEÓRICO
10
3.1.- Introducción
10
3.2.- Descripción del área de Coordinación Operacional
10
3.2.1.- Aspectos Generales
10
3.2.2.- Descripción de los Servicios del área Coordinación Operacional
11
3.2.3.- Estaciones de Válvulas
13
3.2.4.- Estaciones de Rebombeo
14
vi
3.2.5.- Estaciones de Flujo
14
3.2.6.- Mediciones Más Importantes
16
3.2.6.1.- Medición De Presión
16
3.2.6.2.- Medición de Temperatura
16
3.2.6.3.- Medición de Flujo
16
3.3.- Medición Fiscal y de Referencia
17
3.3.1.- Medición en Tanques
18
3.3.2.- Medición en Línea
18
3.4.- Protocolos de Comunicación
20
3.4.1.- HART
20
3.4.1.1.- Descripción
20
3.4.1.2.- Lazo de Conexión
21
3.4.1.3.- Conexión Multipunto
22
3.4.1.4.- Estructura del Mensaje
23
3.4.2.-Modbus
27
3.4.2.1.- Introducción
27
3.4.2.2.- Modbus RTU
29
3.4.2.3.- Modbus TCP
29
3.4.2.4.- Enmarcado del Mensaje Modbus
30
3.4.3.- HTTP
34
3.4.4.- XML – RPC
36
3.4.5.- Interfaces RS - 232 & RS- 485
37
3.5.- PC Industrial Modular / Arquitectura Net-DAS
39
3.5.1.- Características Técnicas
39
3.5.2.- Estándar PC/104
40
3.5.3.- Estructura del PC Industrial Modular
41
3.5.4- Arquitectura Net-DAS
46
3.5.4.1.- Definición
46
3.5.4.2.- Objetivos
47
3.5.4.3.- Ventajas
47
3.5.4.4.- Características
48
vii
3.6.- Servidores HTTP Apache
50
3.7.- Lenguajes de Programación
51
3.7.1.- HTML
51
3.7.2.- PHP
52
3.7.3.- JavaScript
53
3.7.4.- Perl
53
CAPITULO 4.- SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
57
4.1.- Introducción
57
4.2.- Metodología
57
4.2.1.- Primera Fase: Ingeniería
57
4.2.2.- Segunda Fase: Desarrollo e Implementación del Sistema
58
4.2.3.- Tercera Fase: Pruebas
60
4.3.- Sistema integrado de Supervisión y Monitoreo
60
4.3.1.- Generalidades del Sistema
60
4.3.2.- Módulo de Captación de Datos en Campo
64
4.3.2.1.- Lazos de Comunicación
65
4.3.2.2.- Captación de Datos con Net-DAS
70
4.3.3.- Módulo de Comunicación entre Servidor Agente Interfaz y
Computador Net-DAS
83
4.3.4.- Módulo de Captación de Datos desde el Servidor Web
84
4.3.5.- Módulo de Visualización en Web
87
4.4.- Dominio Web
CAPITULO 5.- PRUEBAS Y ANÁLISIS DE RESULTADOS
90
94
5.1.- Introducción
94
5.2.- Pruebas y Resultados Técnicos
94
5.3.- Ventajas del Sistema
98
5.4.- Limitaciones del Sistema
100
CAPITULO 6.- CONCLUSIONES Y RECOMENDACIONES
101
viii
REFERENCIAS BIBLIOGRÁFICAS
APÉNDICES.- Contenido del CD Anexo
APÉNDICE A.- Especificaciones Técnicas de los Módulos del Computador
Industrial PC/104 - Plus
A.1.- MOPSlcd7
A.2.- PCM-3116
A.3.- PCM-3660
A.4.- Xtreme/104
A.5.- HE104
APÉNDICE B.- Códigos Fuentes
B.1.- Archivo dat_EF_SIN.pl
B.2.- Archivo HTMLRenderData.pm
B.3.- Archivo FieldAccess.pm
B.4.- Archivo dsp_EF_SIN.htm
B.5.- Archivo netdaslib.js
B.6.- Archivo htmlIO.js
B.7.- Archivo netdasPageRefresh.js
APÉNDICE C.- Configuración del Setup del PC Modular PC/104-Plus
APÉNDICE D.- Archivo de Configuración del Servidor Web
APÉNDICE E.- Normas Técnicas para la Fiscalización de
Hidrocarburos Líquidos.
APÉNDICE F.- Especificaciones Técnicas de los Equipos de Campo
F.1.- Transmisor de Flujo Micromotion RFT9739
F.2.- Transmisor de Presión Rosemount 3051TG
F.3.- Transmisor de Temperatura Rosemount 3144P
104
ix
ÍNDICE DE TABLAS
Tabla 3.1.- Descripción de los Servicios
12
Tabla 3.2.- Byte de inicio
24
Tabla 3.3.- Especificaciones Módulo Xtreme/104
45
Tabla 3.4.-Especificaciones Módulo HE104
46
Tabla 4.1.- Especificaciones de la Comunicación Modbus RTU empleada
68
Tabla 4.2.- Registros de los Transmisores de Presión y Temperatura
79
Tabla 4.3.- Distribución de los Registros de Entrada en la Tabla Modbus
Interna de la Net-DAS
79
Tabla 4.4.- Distribución de los Registros de Estatus de Comunicación
81
Tabla 4.5.- Registros de las Variables de Proceso del Transmisor de Flujo
82
Tabla 4.6.- Detalle de Mapeo de Memoria de la Net-DAS
85
x
ÍNDICE DE FIGURAS
Figura 3.1.- Procesos Operacionales Asociados
11
Figura 3.2.- Ubicación Esquemática de las Instalaciones de P.T.S
13
Figura 3.3.- Estaciones de Flujo
15
Figura 3.4.- Medición en Tanques
18
Figura 3.5.- Medición en Línea
19
Figura 3.6.- Señal HART BELL 202
20
Figura 3.7.- Lazo HART
22
Figura 3.8.- Estructura del Mensaje HART
23
Figura 3.9.- Dirección HART en Formato Corto
25
Figura 3.10.- Dirección HART en Formato Largo
25
Figura 3.11.- Ciclo de Pregunta – Respuesta en Modbus
28
Figura 3.12.- Marco Modbus TCP
30
Figura 3.13.- Marco Modbus RTU
31
Figura 3.14.- Principio de Solicitud/Respuesta del Protocolo http
35
Figura 3.15.- RS -485 de un solo par trenzado
38
Figura 3.16.- RS -485 de dos pares trenzado
39
Figura 3.17.- PC Industrial Modular PC/104-Plus
42
Figura 3.18.- Módulo MOPSlcd7
42
Figura 3.19.- Módulo PCM-3116
43
Figura 3.20.- Módulo PCM-3660
44
Figura 3.21.- Módulo Xtreme/104
44
Figura 3.22.- Módulo HE104
45
Figura 3.23.- Ejemplo sencillo de un código PHP
52
Figura 4.1.- Módulos de la Arquitectura SAMEL
61
Figura 4.2.- Diagrama de Bloques de las Etapas de la Arquitectura SAMEL
61
Figura 4.3.- Arquitectura del Sistema Automatizado de Medición en Línea
63
Figura 4.4.- Diagrama de Flujo entre las Etapas de la Arquitectura SAMEL
64
Figura 4.5.- Lazo HART de la Arquitectura SAMEL
66
Figura 4.6.- Esquema de Conexión Modbus de la Arquitectura SAMEL
67
xi
Figura 4.7.- Terminales del Transmisor de Flujo RFT9739
69
Figura 4.8.- Pantalla de Configuración en el Prolink
70
Figura 4.9.- Pantalla de Inicio de la Administración Web para Net-DAS
71
Figura 4.10.- Applet de Java/Configuración de Amos
72
Figura 4.11.- Applet de Java/Configuración de Esclavos
73
Figura 4.12.- Despliegue Completo/Configuración de Esclavos
73
Figura 4.13.- Despliegue Completo/Configuración TCP/IP
74
Figura 4.14.- Aplicación Telnet en el Navegador Web
75
Figura 4.15.- Visualización del Contenido de los Registros
75
Figura 4.16.- Estadísticas de Comunicación de los Puertos del
Computador Modular
76
Figura 4.17.- Pantalla de Selección de Puerto para la Detección de
Dispositivos Hart
77
Figura 4.18.- Estaciones del Amo Hart
78
Figura 4.19.- Asignación de Registros en la Estación asociada al
Transmisor de Presión
80
Figura 4.20.- Asignación de Registros en la Estación asociada al
Transmisor de Flujo
83
Figura 4.21.- Ejemplo de Definición de TAGs a ser Consultados desde el
Servidor Web al Servidor Agente Interfaz
86
Figura 4.22.- Esquema de Funcionamiento del Módulo de Captación de Datos
desde el Servidor Web
87
Figura 4.23.- Plantilla Gráfica para la Visualización de los Datos de Campo
89
Figura 4.24.- Esquema de Funcionamiento del Módulo de Visualización en Web
89
Figura 4.25.- Página Inicial de la URL del Dominio Web
90
Figura 5.1.- Respuesta de los Transmisores en la Detección Hart
95
Figura 5.2.- Configuración de un Amo Modbus TCP para Prueba de
Comunicación con Net-DAS
96
Figura 5.3.- Comunicación con el Esclavo Modbus TCP configurado
en la Net-DAS
96
Figura 5.4.- Datos de Campo vistos desde el Script de Perl
97
Figura 5.5.- Despliegue Gráfico de la Arquitectura Desarrollada
98
xii
LISTA DE ABREVIATURAS
AIT: Superintendencia de Automatización, Informática, Telecomunicaciones y Seguridad.
CGI: Common Gateway Interface.
CRC: Cyclic Redundancy Check.
DC: Direct Current
DHCP: Dynamic Host Configuration Protocol
EF: Estación de Flujo.
HART: Highway Addressable Remote Transducer.
HTML: HyperText Markup Language
HTTP: Hypertext Transfer Protocol.
ID: Identificación
IP: Internet Protocol
LAN: Local Area Network.
MEM: Ministerio de Energía y Minas.
Net-DAS: Network Data Acquisition System.
PC: Personal Computer.
PCI: Peripheral Component Interconnect.
PDVSA: Petróleos de Venezuela, S.A.
Perl: Practical Extraction and Report Language.
PHP : Hypertext Preprocessor.
PLC: Programmable Logic Controller.
PTS: Patio de Tanques de Silvestre.
RFC: Request for Comments.
RPC: Remote Procedure Call.
RTU: Remote Terminal Unit.
SAMEL: Sistema Automatizado de Medición en Línea
SCADA: Supervisory Control And Data Acquisition
TCP: Transmission Control Protocol.
UE: Unidad de Explotación.
URL: Uniform Resource Locator.
xiii
XML: Extensible Markup Language.
CAPÍTULO 1.- INTRODUCCIÓN
El presente libro expone el trabajo de pasantía realizado en el Departamento de
Automatización Industrial, de la Superintendencia de Automatización, Informática,
Telecomunicaciones y Seguridad (AIT) del Distrito Sur dentro de la División Centro - Sur de
Petróleos de Venezuela, S.A, ubicado en la ciudad de Barinas, Venezuela.
El Proyecto contempla la planificación, desarrollo e implementación de la integración
de un Sistema Automatizado de Medición en Línea modelando las arquitecturas dispuestas
para las Estaciones de Flujo y Patio de Tanques. Para la medición en línea de la producción en
los oleoductos de las Estaciones de Flujo y Patio de Tanques se utilizan estaciones de
medición, las cuales contienen la instrumentación necesaria para medir flujo volumétrico o
másico, presión, temperatura, densidad y corte de agua. Para el desarrollo de la integración se
utilizó instrumentos de campo para modelar las estaciones de medición instaladas en los
oleoductos.
En Barinas la industria petrolera tuvo su origen en junio de 1930, con la perforación
del pozo Uzcategui-1, a cargo de la Zamora Venezuela Petroleum Company, ubicada en las
inmediaciones del que era entonces el caserío de Quebrada Seca, a unos 14 kilómetros al
noroeste de la ciudad de Barinas. En marzo de 1934 los trabajos en el pozo Uzcategui-1 fueron
abandonados. Fue hasta el año 1942, cuando la Socony Vacuum Oil Company, reinicia la
perforación con resultados satisfactorios. En agosto de 1947, se une la explotación del pozo
Silvestre-2 en el Municipio Torunos, con una producción para la época de 2.800 barriles
diarios de petróleo. En 1953 la Sinclair Venezuela Oil Company, perforó con éxito el pozo
Sinco-1 y logra una producción diaria de 1.000 barriles, y en ese año se desarrollan los campos
San Silvestre-2 y Sinco-1, con 35 pozos perforados todos productores de los cuales 18
correspondieron a Campo San Silvestre y 17 a Campo Sinco. En 1960 la misma empresa
perforó el pozo Nutria-2, en el Campo Nutrias, descubriéndose hidrocarburos líquidos con una
densidad de 11 grados API y un alto porcentaje de agua, hallazgo que para le época no era
comercial por lo que es abandonado al poco tiempo. En 1961 la Mobil Oil Company perfora el
pozo Hato-1 a unos 38 kilómetros al sur de la ciudad de Barinas, vecino del Campo Sinco. Un
año más tarde la Corporación Venezolana de Petróleo (CVP), perfora los pozos Maporal,
2
INTRODUCCIÓN
Silván y Palmita. En 1965 la Venezuela Atlantic Refining Company, perfora el pozo Páez-4,
con una producción inicial de 300 barriles por día. En 1977 con la nacionalización petrolera,
las 14 empresas operadoras que existían para ese momento pasan a ser propiedad del Estado.
Entre su nueva estructura destaca Llanoven que en ese año se fusiona con la CVP, absorbiendo
a Palmaven, Bariven y Deltaven para formar CVP – Llanoven. En 1978, se firma el registro
mercantil de Corpoven filial de Petróleos de Venezuela y al año siguiente la casa matriz le
asigna a la nueva empresa las áreas operacionales integradas, entre las cuales se encuentra la
de Barinas donde seguiría la extracción de crudos en campos ya existentes como Sinco,
Silvestre, Mingo, Maporal, Silván, Hato y Páez.
La Unidad de Explotación de Apure (U.E.A) comprende los campos de la Victoria y
Guafita que fueron descubiertos en 1984 y explotados firmemente dos años después de su
descubrimiento. La Unidad de Explotación de Apure fue creada en el año 1998, para coordinar
la explotación racional de las reservas de los yacimientos. A finales de 1997, la Corporación
Energética Venezolana creó la empresa PDVSA Petróleo y Gas fusionando las tres filiales
principales existentes: Corpoven, Maraven y Lagoven.
Hoy en día PDVSA Petróleo y Gas se constituye por tres grandes divisiones, dedicadas
a las actividades medulares del negocio: PDVSA Exploración, Producción y Mejoramiento;
PDVSA Refinación, Suministro y Comercio; y PDVSA Gas. Cada una de estas divisiones a su
vez está integrada por diversas empresas y unidades de negocio, ubicadas tanto en Venezuela
como en el exterior, siendo desarrollado el sector petroquímico por Pequiven y sus empresas
mixtas. Con esta reestructuración organizativa las áreas operacionales de Barinas y Apure
quedaron ubicadas dentro del organigrama en la división correspondiente a Exploración,
Producción y Mejoramiento, específicamente en Producción bajo la denominación de Distrito
Sur, al mismo nivel de las otras dos gerencias en el ámbito nacional: Gerencia General
Oriente y Gerencia General Occidente. De esta manera, el Distrito Sur maneja hoy por gestión
directa las Unidades de Explotación de los yacimientos petrolíferos de crudos livianos y
medianos, ubicados en los llanos occidentales, en los estados Barinas y Apure, abarcando una
superficie estimada de 280 Km2. En esta área no hay campos bajo convenios operativos. Su
capacidad de producción actual es de 150 mil barriles diarios de crudo, los cuales vienen a
3
INTRODUCCIÓN
representar el cuatro por ciento de la capacidad de producción nacional. Se espera llegar a una
capacidad de producción de 260 mil barriles diarios de crudo y condensado, para finales del
año 2009. Su producción es transferida a la Refinería El Palito por el Oleoducto de 20
pulgadas con una longitud de 643 Km, recorriendo los estados Apure, Barinas, Portuguesa,
Yaracuy y Carabobo.
Actualmente, en el Departamento de Automatización Industrial de la División Centro –
Sur, por las necesidades de buscar alternativas de Supervisión, Control y Adquisición de Datos
de última generación que se adapten a los requerimientos de costo, funcionalidad y calidad, se
han ido emprendiendo proyectos pilotos de escala intermedia y de poco impacto con miras a
obtener resultados y soluciones en un corto plazo. A partir de esto, se origina la necesidad de
planificar, desarrollar e implementar la integración de un Sistema Automatizado para
Medición Fiscal y de Referencia que contribuya con todos los esfuerzos que se están llevando
a cabo dentro del Departamento de Automatización Industrial de la División Centro-Sur, en
busca de nuevas alternativas de menor costo que aumenten las capacidades y desempeño del
sistema.
La integración del sistema implicó establecer la interacción de las distintas etapas que
conforman la arquitectura, desde la captación de los datos de campo enviados por los distintos
transmisores de las variables de procesos, hasta la disposición de esos datos en un ambiente
desarrollado bajo estándares Web que permita la consulta de los mismos desde cualquier parte
de la red de procesos de la Corporación, sin necesidad de utilizar computadores y herramientas
especializadas. La aplicación Web debe ser consultada desde un explorador convencional, que
contenga los requerimientos que comúnmente se exigen al navegar en Internet. La Captación
de Datos está basada en el Sistema Net-DAS montado sobre un computador modular de
estándar industrial de conexión PC/104 – Plus. Los protocolos de comunicación están dentro
de los estándares utilizados comúnmente en las redes industriales de la Corporación. Las
aplicaciones utilizadas para la implementación están desarrolladas en lenguajes de
programación comúnmente utilizados, siguiendo los estándares más empleados para
arquitecturas basadas en Web.
4
INTRODUCCIÓN
Antes de establecer la integración de la arquitectura se garantizó un correcto
funcionamiento de cada una de las etapas que conforman a la misma, para luego, conformar
las diferentes redes de comunicación y realizar la implementación completa del sistema,
demostrando que los datos mostrados en el entorno Web, correspondían a los datos registrados
por los equipos de campo.
La implementación del sistema se hizo localmente en un espacio de laboratorio,
utilizando los equipos reales de campo. Para realizar la implementación se desarrolló la
ingeniería previa para diseñar las estrategias de montaje, y se configuraron e instalaron las
distintas redes y equipos que componen la arquitectura del sistema. La selección de los
protocolos de comunicación y lenguajes de programación, y la estructuración de la
arquitectura fueron la más acertadas que permitieron obtener los resultados óptimos esperados.
El libro consta de seis capítulos, los cuales son brevemente descritos a continuación:
El segundo capítulo plantea los argumentos y bases teóricas necesarias para ayudar al
lector al entendimiento del contenido del resto de los capítulos que conforman el libro. Se dan
definiciones y características de los principales tópicos abarcados en el contexto del Proyecto.
En el tercer capítulo, se hace revisión de la descripción del Proyecto que permite
conocer en rasgos generales el contexto sobre el cual está enmarcado el mismo, seguido del
planteamiento del objetivo principal junto con el detalle de sus objetivos específicos. La
justificación y el alcance del Proyecto también forman parte de este capítulo.
El desarrollo del Proyecto está explicado en el cuarto capítulo, el cual empieza por una
descripción de la metodología empleada para lograr la integración del sistema. La metodología
está conformada por un grupo de fases que hacen posible llevar a cabo el Proyecto de manera
exitosa y organizada. El cuerpo principal de este capítulo esta constituido por el estudio a
fondo de la arquitectura del sistema, para lo cual se hace una descripción técnica – detallada de
cada uno de los módulos que conforman a la misma. Se describe el funcionamiento lógico del
sistema, la configuraron los transmisores de campo, la conformación de las redes para la
5
INTRODUCCIÓN
comunicación de las distintas partes, la instalación y configuración del sistema de adquisición
de datos, la adaptación de las distintas interfaces para el entendimiento entre las distintas
etapas de la arquitectura y la programación de las aplicaciones basadas en ambiente Web. A lo
largo del capítulo se hace referencia a los protocolos y herramientas utilizadas para la
conformación del sistema, de acuerdo a los requerimientos planteados con el Proyecto.
En el quinto capítulo se describen por un lado las ventajas y limitaciones del sistema, y
por otro, el conjunto de pruebas hechas para evaluar el funcionamiento de las etapas que
constituyen el sistema, y los resultados obtenidos de cada una de ellas.
Por último se presenta el capítulo de las conclusiones obtenidas del Proyecto y
recomendaciones sugeridas para futuros desarrollos basados en la misma arquitectura.
CAPITULO 2.- PLANTEAMIENTO DEL PROYECTO
2.1.- Introducción
Debido a los constantes cambios y las crecientes exigencias por las que atraviesan
todas las empresas productoras de bienes y servicios en lo referente a calidad de la
información, productividad, disminución de costos de producción, la industria en general ha
venido encaminando sus acciones hacia la formulación de planes que hagan posible la
optimización y el mejoramiento de los procesos, con el fin de obtener los mayores beneficios y
cumplir con los retos que se imponen.
El Departamento de Automatización Industrial del División Centro – Sur tiene como
propósito fundamental proveer dos líneas de servicios: Soporte y Mantenimiento de la
infraestructura de automatización de operaciones de producción; Ingeniería y Proyecto para la
automatización de nuevas instalaciones de acuerdo al plan de crecimiento del distrito de tal
forma de racionalizar y optimizar la operación y control de sus procesos industriales e
incrementar la productividad de sus actividades. Por lo tanto, una de las responsabilidades de
este departamento es mantener actualizados, en cuanto a avances tecnológicos en
automatización, a los Sistemas de Adquisición de Datos, Control y Supervisión de los distintos
procesos industriales que se desarrollan en el distrito.
2.2.- Antecedentes y Justificación
El Departamento de Automatización Industrial de la Superintendencia de
Automatización, Informática, Telecomunicaciones y Seguridad (AIT) de la División Centro –
Sur de Petróleos de Venezuela, S.A., sobre la base de excelentes resultados obtenidos en otras
regiones y el incentivo de implementar en todos sus procesos tecnología de punta, decidió
emprender proyectos pilotos para la Automatización de los Sistemas de Adquisición de Datos
de Campo que garantice las operaciones de mando, señalización, medición y ocurrencia de
incidentes en los parámetros operacionales asociados a la Estaciones de Flujo y el Patio de
Tanques Silvestre (PTS), empleando una Nueva Arquitectura conocida como Net-DAS
(Network Data Acquisition System) desarrollada por Intevep, S.A., basada en computadores
modulares que utilizan el estándar industrial PC/104. La tecnología de medición y control de
los procesos industriales automatizados presentes en el área, son de última generación; se
7
PLANTEAMIENTO DEL PROYECTO
obtienen datos en tiempo real y continuo de las variables importantes. Por lo tanto, es factible
la prueba de sistemas alternativos de captación de datos, más aún si son desarrollos propios de
la Corporación.
Actualmente el Sistema de Supervisión, Control y Adquisición de Datos está basado en
el Sistema Especializado SCADA (siglas de Supervisory Control And Data Acquisition).
Debido a la robustez de este sistema, es muy difícil que sea reemplazado en un corto plazo.
Los proyectos pilotos con la Nueva Arquitectura contemplan inicialmente la Supervisión y
Adquisición de Datos, debido a que implementar el Control sin contar con una madurez
suficiente de las nuevas aplicaciones, es una tarea sumamente delicada y difícil. Se pretende ir
implementando y probando la Nueva Arquitectura en paralelo al Sistema actual, para evitar
causar algún impacto dentro de los procesos que luego se pueda convertir en costosas
pérdidas.
El Ministerio de Energía y Minas, como ente regulador y supervisor de la disposición
de los hidrocarburos y de todos sus derivados, ha exigido a través de unos lineamientos de
política petrolera la automatización de las mediciones sobre puntos críticos para la
contabilización de volúmenes netos de hidrocarburos producidos, siendo necesaria la adecuada
disposición de los datos obtenidos para el correspondiente monitoreo por parte del Ministerio.
Por lo tanto, es recomendable y obligatorio que los puntos críticos de supervisión, deban estar
basados en sistemas de medición que cumplan con los requerimientos exigidos en las Normas
impuestas por el Ministerio. La División Centro – Sur, no cuenta con un sistema que le
permita al Ministerio monitorear y supervisar fácilmente los datos críticos de campo, es por
ello que se origina la necesidad de planificar, desarrollar e implementar la integración de un
Sistema Automatizado para Medición Fiscal y de Referencia, bajo la filosofía de incorporar,
desarrollar y utilizar aplicaciones y sistemas propios de la Corporación, basados en estándares
y protocolos de tecnología de punta, sin que haya la necesidad de invertir en costosos sistemas
especializados que actualmente se encuentran en el mercado.
Este Sistema para Medición Fiscal y de Referencia, va completamente alineado a la
filosofía de las nuevas alternativas para Supervisión de menor costo y de mayor desempeño,
8
PLANTEAMIENTO DEL PROYECTO
formando parte de los proyectos pilotos que actualmente se desarrollan en el área de
Automatización. Este Sistema aprovecha las ventajas de los protocolos utilizados en el mundo
Web, por lo que la disposición de los datos al supervisor, en este caso al Ministerio, sería de
manera inmediata y desde cualquier ubicación dentro de la red de procesos de la Corporación.
2.3.- Objetivos del Proyecto
Objetivo General:
Planificar, Desarrollar e Implantar un Sistema Integrado para Medición Fiscal y de
Referencia en las Estaciones de Flujo y Patio de Tanques.
Objetivos Específicos:
•
Seleccionar los protocolos de comunicación a emplear en cada una de las
interfaces del sistema.
•
Instalar y Configurar el Módulo de Captación de Datos en Campo constituido
por el Computador Modular PC/104-Plus y el Sistema Net-DAS.
•
Establecer la comunicación entre los transmisores de mediciones y la unidad
terminal remota Net-DAS.
•
Estudiar la interfaz entre el Net-DAS y la Recepción de Datos para la
Visualización vía Web.
•
Diseñar la estrategia de contenido a manejar en el monitoreo, adaptado a la
normativa utilizada en la Corporación.
•
Implementar la Aplicación Web para el monitoreo, empleando los lenguajes de
comunicación PHP, HTML, JavaScript y Perl.
•
Configurar el Servidor Web y puesta en marcha de la aplicación corriendo
sobre el mismo.
2.4.- Alcance del Proyecto
El Proyecto se desarrolló a nivel de laboratorio en las oficinas del Departamento de
Automatización Industrial de la División Centro Sur de PDVSA. La implementación de la
9
PLANTEAMIENTO DEL PROYECTO
arquitectura para el Sistema de Monitoreo y Supervisión vía Web, se hizo localmente
utilizando los transmisores reales de campo (presión, temperatura y flujo), el computador
modular con el Sistema Net-DAS, un computador personal haciendo las funciones de Servidor
Web, y un servidor dedicado para unas funciones de comunicación para la transmisión de los
datos. El Proyecto no contempla la instalación en campo, por lo tanto, la integración se
desarrolló a manera de prueba como posible alternativa para supervisión de las variables de
proceso en los oleoductos de las Estaciones de Flujo y Patio de Tanques. Debido que la
integración no se hizo directamente en campo, era inadecuado instalar todos los equipos en las
oficinas donde se estableció el laboratorio, como son los casos del transmisor de corte de agua,
del sensor de corte de agua, y del sensor de flujo. Para el caso en particular del transmisor de
flujo, por ausencia del sensor, se dispuso de un simulador para enviar datos empleando el
mismo protocolo de comunicación del equipo. Se dispuso de las herramientas y equipos
necesarios para llevar a cabo con éxito la integración del Sistema.
CAPÍTULO 3.- MARCO TEÓRICO
3.1.- Introducción
En el presente capítulo se pretende hacer una revisión por cada uno de los conceptos
abarcados en el desarrollo del proyecto, para facilitar el entendimiento de los distintos
sistemas y aplicaciones que conforman la integración de la arquitectura del Sistema de
Medición Fiscal y de Referencia en Línea.
3.2.- Descripción del área de Coordinación Operacional
3.2.1.- Aspectos Generales
El Patio de Tanques de Silvestre (P.T.S.) está definido como el gran centro de acopio
de la producción del Distrito Sur. Está ubicado geográficamente a 35 Km de la ciudad de
Barinas en el campo Silvestre a 2 Km de la carretera Barinas-San Silvestre, a una altitud de
125 m con respecto al nivel del mar. Fue diseñado para la recolección del crudo producido
tanto en Apure como de Barinas.
Los procesos operacionales que están asociados a P.T.S. son los siguientes (ver Figura
3.1):
•
Recepción de crudo, proveniente de los campos del Estado Apure
(Estaciones de Flujo Guafita y La Victoria) y del Estado Barinas
(Estaciones de Flujo Silván, Mingo, Silvestre B, Sinco y Palmita).
•
Almacenamiento de crudo, a través de cuatro tanques de techo flotante
con capacidad nominal de 150 mil barriles cada uno, altura de 50 pies
y 150 pies de diámetro. Cada tanque cuenta con un patio, muros de
contención de 2.5 Mts de altura, sistemas de drenajes de agua de lluvia
y rampas de acceso. El crudo llega a través de líneas de 20 pulgadas
para el caso de Apure y 16 pulgadas para Barinas, distribuyéndose al
tanque de interés por medio de sistemas de válvulas motorizadas con
acción remota desde la Sala de Control.
11
MARCO TEÓRICO
•
Transporte de crudo almacenado, hacia la Refinería El Palito en el
Estado Carabobo, por medio de un sistema de bombas de precarga,
sistema de bombas principales y tres Estaciones Reforzadoras.
•
Transferencia de custodia de crudo, a través del Oleoducto P.T.SRefinería El Palito. El proceso de transferencia de custodia abarca
tanto la llegada del crudo a los tanques de almacenamiento de la
Refinería, así como su contabilización a través de medidores de flujo.
Es importante destacar que estos medidores son monitoreados desde
P.T.S. y son considerados solo una medida operacional de referencia
por cuanto la medida oficial del crudo bombeado es la que arroja el
proceso de aforo de los tanques de la Refinería.
Figura 3.1.- Procesos Operacionales Asociados
3.2.2.- Descripción de los Servicios del área Coordinación Operacional
Los servicios prestados son cinco en total y están asignados actualmente a un área
determinada de la siguiente manera (ver Tabla 3.1).
La supervisión y control de las
operaciones de producción en el Patio de Tanques Silvestre (P.T.S.) de la U.E. Barinas, está
basada en un SCADA marca Intellution, modelo FIX32 v7.0 ubicado en la sala de telemetría
12
MARCO TEÓRICO
de dicha localidad (el mismo que supervisa y controla las operaciones de los campos de
producción de Barinas), en 1 PLC marca Allen Bradley, modelo 5/20E ubicado en la sala de
bombas de dicha instalación, en 2 RTU’s marca Bristol Babcock, modelo DPC3330 ubicadas
en la sala de telemetría de dicha localidad. La comunicación entre el sistema SCADA y las
RTU’s se realiza a través de la aplicación OpenBSI v2.3 de Bristol Babcock y el controlador
BR3 v6.10f del referido SCADA. La comunicación con los equipos de campo se realiza
mediante enlaces seriales a 9.600 bps con el protocolo BISAP. La comunicación entre el
sistema SCADA y el PLC se realiza a través de la aplicación RsLinx Gateway v02.10.118.0 de
Rockwell Software y el controlador ABR v6.53g del referido SCADA, mediante un enlace de
red Ethernet TCP/IP (tanto el SCADA como el PLC están conectados a la red de datos de la
corporación).
Tabla 3.1.- Descripción de los Servicios
Servicio
Instalación
Estación Patio Tanques
Bombas Booster y Filtros de Crudo
Línea de Entrada de Crudo de Apure - Barinas
Patio Tanques Silvestre
Bombas de Torres de Enfriamiento
Trampa de Salida de PTS
Bombas Principales de PTS
Oleoducto Apure – Barinas
(28 Estaciones de Válvula)
Oleoducto Barinas - El Palito
(13 Estaciones de Válvula)
Estación Reforzadora Guanare
Estaciones de Rebombeo
Estación Reforzadora Yaritagua
Estación Reforzadora Acarigua
Estación de Flujo Palmita
Estaciones de Flujo
Estación de Flujo Silvestre B
Estación de Flujo Sinco D
Barinas
Estación de Flujo Silvan
Estación de Flujo Mingo
13
MARCO TEÓRICO
Dentro de este servicio se encuentran las siguientes instalaciones:
Patio de Tanques, Bombas Booster y Filtros de Crudo, Línea de Entrada de Crudo de
Apure – Barinas, Bombas de Torres de Enfriamiento, Trampa de Salida de PTS, Bombas
Principales de PTS (ver Figura 3.2).
Figura 3.2.- Ubicación Esquemática de las Instalaciones de P.T.S
3.2.3.- Estaciones de Válvulas.
Las Estaciones de Válvulas supervisan y controlan el transporte de crudo desde su
extracción hasta la Refinería el Palito para su posterior embarque o proceso en la planta.
Dentro de la arquitectura de las Estaciones del Oleoducto Apure – El Palito se
encuentran las remotas y radios, las remotas 3305 marca Brístol y los radios digitales. Las
Estaciones de Válvulas supervisan y controlan el transporte de crudo desde su extracción hasta
la refinería el palito para su posterior embarque o proceso en la planta.
Dentro de este servicio se encuentran las siguientes instalaciones:
•
Oleoducto Apure - Barinas (conformado por 28 Estaciones de
Válvula): La Victoria 4 , La Victoria 5, La Mona, Caño Colorada,
14
MARCO TEÓRICO
Mata Larga, Hato Angostura, Caño Muñoz, El Amparo, Pueblo Viejo,
La Miel, Guaritico, Bogante, La Idea, Palmarito 1, Palmarito 2, Caño
el Babo, Mata de Banco, Apure Sur; Apure Norte, Araguaney, Calzada
Páez, Canagua, Zamoa, Paguey, Morrocoy.
•
Oleoducto Barinas - El Palito (conformado por 13 Estaciones de
Válvula): Torunos, San Nicolás,
Guanare, Por Fin, Acarigua,
Cambiaba, Chivacoa, Boraure, El Peñón, Bananera, Santa Rita,
Simonera.
3.2.4.- Estaciones de Rebombeo.
El sistema de control de las Reforzadoras se encuentra conformado por dos remotas
Bristol (Esclava y Maestra) ubicada en la sala de control. Las remotas permiten operar,
supervisar y controlar el bombeo de la planta, en forma remota (desde la estación PTS) ya que
la estación es desasistida.
El sistema se divide en dos gabinetes, el primero se encuentra en la sala de control y
contiene: dos remotas, una amo y una segunda remota esclava, el equipo de comunicación con
P.T.S. y en la misma sala se encuentra una consola de operación local. El segundo gabinete se
encuentra en un centro de control de motores (CCM) en el cual se concentra el I/O discretos
involucrados en el manejo de las bombas. Adicionalmente se encuentra con dos reguladores
cargadores ubicados en la misma sala de control que asegura el suministro eléctrico para las
remotas y parte de la instrumentación. El sistema de automatización esta conformado por tres
remotas una interfaz Hart, los equipos de comunicación, una consola local y una Master
Rotork.
3.2.5.- Estaciones de Flujo.
La supervisión y control de las operaciones de producción en los campos de la Unidad
de Explotación (U.E.) Barinas, que cubren un radio máximo de 70 kilómetros de la ciudad de
Barinas, en el Edo. Barinas) está basada en un SCADA marca Intellution, modelo FIX32 v7.0
ubicado en la sala de telemetría del Patio de Tanques Silvestre, y en RTU’s marca Bristol
Babcock, modelo DPC3330 como equipos de adquisición de datos de campo.
15
MARCO TEÓRICO
La comunicación entre el sistema SCADA y las RTU’s se realiza a través de la
aplicación OpenBSI v2.3 de Bristol Babcock y el controlador BR3 v6.10f del referido
SCADA. La comunicación con los equipos de campo se realiza mediante un enlace serial de
radio punto-multipunto a 9.600 bps con el protocolo BISAP.
Las instalaciones que conforman este servicio son cinco Estaciones de Flujo: Estación
de Flujo Mingo, Estación de Flujo Palmita, Estación de Flujo Silván, Estación de Flujo
Silvestre - B, Estación de Flujo Sinco - D. En la Figura 3.3 se muestra una estación de Flujo.
Figura 3.3.- Estaciones de Flujo
Cada una de las instalaciones asociadas a un servicio están compuestas por siete
sistemas: SCADA, Sistema de Energía de Sala de Control, Sistema de Energía de la Estación,
Telecomunicaciones, Equipos de Adquisición de Datos (PLC o RTUs), Equipos Inteligentes e
Instrumentación de Campo).
Es necesario destacar que ésta es la arquitectura actual presente en el Distrito Sur, la
cual está sujeta a variación. De los elementos anteriormente nombrados: los servicios y las
instalaciones pueden cambiar, en otras palabras pueden desaparecer o crearse nuevos
elementos; a excepción de los sistemas que no pueden modificarse bajo ningún concepto, ni en
este distrito ni en cualquier otra parte del país.
16
MARCO TEÓRICO
3.2.6.- Mediciones Más Importantes
3.2.6.1.- Medición De Presión
La presión se define como la fuerza ejercida por unidad de área. Existen muchas
razones por las cuales en un determinado proceso se puede medir presión. Entre estas se tiene:
calidad del producto, seguridad de los procesos, contabilidad, etc.
La presión se puede medir en valores absolutos o diferenciales. La presión
manométrica se define como la presión relativa a la presión atmosférica. La presión absoluta
es la suma de la presión manométrica más la presión atmosférica. El vacío es la diferencia
entre la presión atmosférica y la presión absoluta, es decir, la presión medida por debajo de la
presión atmosférica.
3.2.6.2.- Medición de Temperatura
La temperatura es una propiedad termodinámica de la materia y no existe un medio
directo de medirla. Sin embargo, esta puede medirse en términos de los efectos indirectos que
ella tiene sobre las propiedades físicas de los materiales (como la presión), o por el cambio
que produce en circuitos eléctricos (cambios de voltaje y resistencia). Los sensores más
utilizados para medir temperatura son: termómetros (de bulbo, bimetálicos, de resistencia),
termistores, termocuplas, pirómetros de radiación, sensores infrarrojos, radiación laser.
3.2.6.3.- Medición de Flujo
La medición de flujo es uno de los aspectos más importantes en el control de procesos.
De hecho, bien puede ser la variable más comúnmente medida. Existen muchos métodos
confiables y precisos para medir flujo. Algunos son aplicables solamente a líquidos, algunos
solamente a gases o vapores y otros a los dos últimos nombrados. El fluido puede ser limpio o
sucio, seco o húmedo, erosivo o corrosivo. Las condiciones del proceso tales como presión,
temperatura, densidad, viscosidad, pueden variar afectando la medición y por tanto deben ser
tomados en cuenta al momento de seleccionar
el medidor de flujo a implementar. Es
necesario por lo tanto conocer el principio de operación y características de funcionamiento de
los diferentes medidores de flujo disponibles. Sin tal conocimiento es muy difícil seleccionar
17
MARCO TEÓRICO
el medidor más apropiado para una determinada aplicación. Para mayor información sobre la
Descripción del área de Coordinación Operacional consultar [GARCÍA, 2004].
3.3.- Medición Fiscal y de Referencia
En el año 2001, el Ministerio de Energía y Minas emitió un lineamiento de política
petrolera relacionada con la fiscalización automática de los volúmenes de hidrocarburos
producidos por esfuerzo propio de Petróleos de Venezuela, S.A. y bajo la figura de
Asociaciones y Convenios Operativos, para efectuar una medición más efectiva y precisa de
los volúmenes de hidrocarburos producidos en los campos y vendidos en los Mercados Interno
y de Exportación, mediante la aplicación de unas Normas Técnicas de Fiscalización que
garanticen los pagos de estipendios a los contratistas por servicios prestados, así como también
los montos por concepto de los diferentes impuestos en el ramo de los hidrocarburos que las
empresas operadoras deben pagar al Fisco Nacional.
Esa Norma tiene como propósito principal servir de guía a la industria petrolera
establecida en el país para alcanzar un nivel de medición automatizado que permita conocer
exactamente la producción y utilización de los recursos naturales explotados. Las normas de
Fiscalización de Hidrocarburos de Venezuela utiliza algunos procedimientos acreditados
internacionalmente provenientes de organismos oficiales y de instituciones especializadas en
la materia, así como la aplicación de patrones adecuados que garanticen la exactitud de la
medición fiscal en la industria petrolera nacional, con la utilización de equipos confiables
debidamente certificados por empresas terceras acreditadas. En el Apéndice E se encuentra en
detalle las Normas Técnicas para la Fiscalización de Hidrocarburos Líquidos.
Del lineamiento de política petrolera que establece la normativa para la fiscalización de
hidrocarburos líquidos, se deduce que toda aquella medición que no cumpla a cabalidad con
los requerimientos de precisión, efectividad y certificación exigidos para la medición de
volúmenes de hidrocarburos producidos, será considerada una Medición de Referencia.
18
MARCO TEÓRICO
3.3.1.- Medición en Tanques
La medición de nivel por tanque constituye un método indirecto de cálculo del
volumen contenido en el mismo basado en la geometría del tanque y de las variables claves de
medición. Los componentes básicos asociados a este método de medición son:
a. Medidor de nivel de crudo.
b. Medidor de nivel de agua libre.
c. Medidor múltiple de temperatura.
d. Medidor de presión.
e. Medidor de contenido de agua en hidrocarburos líquidos.
f. Sistema de monitoreo de inventario en tanques.
g. Sistema de fiscalización y contabilidad de hidrocarburos líquidos.
En la Figura 3.4 se muestra el diagrama típico de la instrumentación de tanques, el cual
cumple con los requerimientos para la fiscalización.
Figura 3.4.- Medición en Tanques1
3.3.2.- Medición en Línea
En los puntos de fiscalización donde se acuerde realizar la medición en línea de la
Producción se deben utilizar estaciones de medición, las cuales contengan la instrumentación
necesaria para medir flujo volumétrico o másico, presión, temperatura, densidad, corte de agua
1
Figura extraída de las Normas Técnicas para la Fiscalización de Hidrocarburos Líquidos (ver Apéndice E).
19
MARCO TEÓRICO
y tomamuestra automático en línea y las facilidades mecánicas para la conexión de un
probador. Así mismo, deben contener todos los accesorios necesarios para la correcta
adecuación del líquido (válvulas de bloqueo, válvulas de control de presión y retropresión,
filtros y/o separadores de gas y vapor). El número de medidores de flujo en paralelo, debe
garantizar que a la máxima rata nominal de flujo prevista, siempre exista, al menos un
medidor de reserva para ser utilizado en caso de contingencia. De esta forma se garantiza el
alto grado de disponibilidad que se necesita para estas operaciones. El diseño y construcción
de la estación de medición debe permitir que los medidores individuales puedan ser excluidos
del servicio sin necesidad de suspender la operación de la estación completa. Los sistemas de
medición de flujo, deben incluir las facilidades necesarias para probar el comportamiento de
los equipos y determinar los correspondientes factores del medidor.
Las estaciones de
medición con gran cantidad de medidores, manejo de grandes volúmenes y manejo de
diferentes tipos de fluidos por los mismos medidores, deben poseer probadores en sitio,
preferiblemente de tipo bidireccional. No es permitida la construcción de vías alternas a los
medidores o bypass que puedan permitir que el líquido sea transferido sin medición. Los
medidores de flujo utilizados deben incluir compensación automática por temperatura. Esta
compensación es ejecutada de manera individual en cada ramal de las estaciones de medición.
En la Figura 3.5 se muestra el diagrama típico de la instrumentación de Estación de Medición
en Línea para fiscalización.
Figura 3.5.- Medición en Línea2
2
Figura extraída de las Normas Técnicas para la Fiscalización de Hidrocarburos Líquidos (ver Apéndice E).
20
MARCO TEÓRICO
3.4.- Protocolos de Comunicación
3.4.1.- HART
3.4.1.1.- Descripción
HART es un acrónimo para Highway Addressable Remote Transducer. El protocolo
HART fue desarrollado por Rosemount Inc, sin embargo, para difundir el uso de
comunicación digital en los dispositivos de campo, Rosemount ha transferido todos sus
derechos sobre el protocolo HART a la Fundación de Comunicación HART (HCF, siglas en
inglés) y está disponible para el uso de cualquier compañía o persona.
HART utiliza una señal estándar de BELL, 202 codificada por desplazamiento en
frecuencia, para comunicar a 1200 baudios, superpuesta sobre la señal de medición de 420mA. Teniendo un promedio de cero, la señal codificada por desplazamiento en frecuencia
no interfiere con la señal analógica. El “1” es representado por un ciclo de 1200Hz, mientras
que el “0” es representado por aproximadamente dos ciclos de 2200Hz, tal como se muestra en
la Figura 3.6.
I (mA)
“1”
+0.5 mA
0
20
1200 Hz
“0”
2200 Hz
-0.5 mA
comando
respuesta
comando
respuesta
4
t (s)
Figura 3.6.- Señal HART BELL 202
Hart es un protocolo amo-esclavo. Puede haber hasta dos amos y hasta 15 dispositivos
esclavos se pueden conectar en configuración multipunto. Cada mensaje incluye las
direcciones de su fuente y destino, para asegurarse de que es recibido por el dispositivo
21
MARCO TEÓRICO
correcto, y tiene una suma de verificación (checksum) para poder detectar cualquier
corrupción del mensaje. El estado del dispositivo de campo está incluido en cada mensaje de
respuesta, indicando su estado de operación correcto. Puede o no haber información o datos
incluidos en el mensaje, dependiendo del comando en particular. Dos o tres transacciones de
mensajes se pueden realizar cada segundo.
HART es un protocolo Half-Duplex, la portadora debe ser desactivada para permitir
que la otra estación transmita. Las reglas de tiempo de la portadora establecen que la portadora
debe ser activada no más del tiempo de 5 bits antes del inicio del mensaje (preámbulo) y ser
desactivada no más del mismo tiempo después de la transmisión del último byte del mensaje
(la suma de verificación). El amo es el responsable de las transacciones de mensajes. Si no hay
respuesta a un comando dentro de cierto tiempo, el amo debe retransmitir el mensaje. Después
de unos cuantos intentos debe abandonar la transacción y notificar el problema. La longitud y
retardo típicos de los mensajes, permiten dos transacciones por segundo.
Para llevar a cabo diferentes funciones preestablecidas el protocolo HART utiliza los
comandos, o en otras palabras los identificadores de la funciones que se pretende utilizar. Los
comandos del protocolo HART se clasifican en tres grupos. El primer grupo es el de
comandos universales, y provee funciones que están implementadas en todos los dispositivos
de campo. El segundo grupo, comandos de práctica común, provee funciones comunes a
muchos dispositivos de campo, pero no todos. Si un dispositivo implementa funciones que
estos comandos describen, deberán ser invocadas mediante el número de comando asignado
por la Fundación Hart. El tercer grupo, comandos específicos de dispositivo provee funciones
que son más o menos únicas para un dispositivo particular.
3.4.1.2.- Lazo de Conexión
La conexión convencional para un transmisor alimentado por lazo de corriente de dos
hilos se muestra en la Figura 3.7. Las especificaciones de Hart permiten resistencias de carga
de 230 a 1100 ohms.
22
MARCO TEÓRICO
+ 24 V
+
Tx
RL
-
0V
Figura 3.7.- Lazo HART
La señal HART debe ser introducida y leída del lazo de corriente. La fuente de poder
está casi en corto circuito para las frecuencias de la señal Hart, por lo que el dispositivo amo
no puede ser conectados directamente al lazo, se deben conectar en paralelo al transmisor o a
la resistencia de carga. Un equipo con protocolo de comunicación Hart no debe introducir
ninguna carga DC a la línea. Para asegurarse de que así sea se debe conectar al lazo mediante
un condensador de 5µF o más. Algunos de los dispositivos de campo con lazo de 4-20mA son
activos, es decir, estos son los que alimentan el lazo. Con este tipo de dispositivos no hace
falta la fuente de poder.
3.4.1.3.- Conexión Multipunto
Múltiples dispositivos pueden ser conectados al mismo amo, ya que en los mensajes se
incluye la dirección de los dispositivos que se comunican. Las consecuencias de este tipo de
conexión son, principalmente, el retardo en la comunicación entre amo-esclavo, y la pérdida
de la señal analógica. Cada dispositivo conectado en la red multipunto (paralelo al lazo
HART) debe tener una dirección única comprendida entre cero y quince.
23
MARCO TEÓRICO
3.3.1.4.- Estructura del Mensaje
PREAMBULO
INICIO
DIRECCIÓN
COMANDO
CUENTA
BYTE
ESTATUS
DATOS
CHECKSUM
Figura 3.8.- Estructura del Mensaje HART
La estructura del mensaje se muestra en la Figura 3.8. Existe el formato largo y el
formato corto. Los primeros instrumentos Hart (inclusive la revisión 4) siempre utilizaron el
formato corto. En este formato, la dirección del esclavo es de un byte, y tiene un valor
comprendido del 0 al 15 para configuración multipunto. Esta corta dirección se denomina
dirección multipunto. La revisión 5 introduce el formato largo. En este, la dirección del
esclavo es un número de identificación único, un número de 38 bits derivado del código del
fabricante, del código del tipo de dispositivo y del número de identificación del dispositivo.
De un modo estricto, el identificador único, realmente no es único, puede haber hasta cuatro
veces el mismo número, ya que del código del fabricante solo se toman 6 bits, cuando el
número en realidad consta de 8 bits.
La mayoría de los dispositivos amos deben incluir ambos formatos en su totalidad, de
modo que puedan trabajar correctamente con los dispositivos ya existentes así como con los
nuevos. La revisión 5 establece que todos los dispositivos deben implementar el comando #0
(leer identificación única) en ambos formatos del mensaje. Un amo normalmente utilizará el
comando #0 para la primera conexión con el dispositivo, ya que en ese momento el número
único de identificación no se conoce, sin embargo como el mensaje también incluye el nivel
de revisión de HART, el amo sabrá que formato deberá utilizar.
El preámbulo:
El preámbulo consiste de 5 a 20 bytes con el número hexadecimal FF (todos 1’s). Esto
permite que el receptor sincronice la frecuencia de la señal y la cadena de caracteres recibida
después de la detección inicial del mensaje Hart. Para el primer intento y cualquier intento
sucesivo de comunicación, se debería utilizar 20 bytes de preámbulo para tener la mayor
probabilidad de éxito. La respuesta al comando #0 le dice al amo cuantos caracteres de
24
MARCO TEÓRICO
preámbulo le gustaría recibir al dispositivo; el amo puede utilizar el comando #59 para
indicarle cuantos bytes de preámbulo debe incluir en la respuesta.
El caracter de inicio (start byte):
A través del caracter de inicio se puede indicar cual formato está siendo utilizado, la
fuente del mensaje, y si es o no un mensaje tipo ráfaga. Estos valores se muestran en la Tabla
3.2.
Tabla 3.2.- Byte de inicio
Tipo de Mensaje
Formato Corto
Amo a Esclavo
2H
Formato Largo
82H
Esclavo a Amo
6H
86H
Ráfaga del Esclavo
1H
81H
Después de capturar por lo menos 2 caracteres FF (para sincronizar), los receptores se
encuentran en la búsqueda de estos valores del start byte para indicar el inicio del mensaje.
Estos mensajes se pueden identificar completamente con el contenido de los bits 0,1,2 y 7. Se
ha propuesto que para mejoras futuras se utilicen los bits 5 y 6 del caracter de inicio para
indicar la presencia de bytes extra entre la dirección y el comando.
La dirección (address bytes):
El campo de dirección contiene tanto la dirección del amo como la del esclavo del
mensaje enviado. Esta contenida en un byte, para el formato corto y en 5 bytes para el formato
largo. El bit más significativo de la dirección, indica si el amo es primario (1) o secundario (0)
. Los mensajes de tipo ráfaga son una excepción, en la cual el dispositivo alterna ambas
direcciones, lo que le da oportunidad a ambos amos de interrumpir.
También en ambos formatos, el bit que le sigue al más significativo indica si el
mensaje proviene de un dispositivo en modo ráfaga, lo que no implica que el mensaje sea de
tipo ráfaga. En el formato corto, los dispositivos esclavos tienen direcciones de la cero a la
quince. Este número se incluye de modo binario en los 4 bits menos significativos del byte de
25
MARCO TEÓRICO
dirección. En el formato largo, la dirección de multipunto no es utilizada, conteniendo, los 38
bits restantes de los cinco bytes del campo de direcciones, el valor identificador único del
dispositivo. En las Figuras 3.9 y 3.10 se puede observar la estructura de las direcciones.
DM
MR
0
0
DE
DM: Dirección del Amo (1 bit)
MR: Modo Ráfaga ó BURST (1 bit)
DE: Dirección del Esclavo (4 bits)
Figura 3.9.- Dirección HART en Formato Corto
DM
MR
DE
………
DM: Dirección del Amo (1 bit)
MR: Modo Ráfaga ó BURST (1 bit)
DE: Dirección del Esclavo (38 bits)
Figura 3.10.- Dirección HART en Formato Largo
En la estructura de formato largo, si se asigna cero a todos los bits, se puede utilizar
como un mensaje de transmisión sin destinatario específico, es decir, un mensaje que sea
aceptado por todos los dispositivos. Esto solo es posible si los datos en el mensaje determinan
cual de los dispositivos debe responder. Por ejemplo, el comando #11 (leer el identificador
único asociado a la etiqueta) normalmente utiliza direcciones de transmisión sin destinatario
específico con una etiqueta en el campo de datos, de modo que todos los dispositivos
conectados reciben el mensaje pero solo uno de ellos responde.
Comando:
El campo de comando contiene un entero del 0 al FD (en decimal 253), como su
nombre lo indica representa el comando HART. El comando recibido se incluye en la
respuesta del esclavo al ser enviada, ya que para cada comando se define una estructura
específica para el campo de datos, y una respuesta en particular.
26
MARCO TEÓRICO
Cuenta de bytes:
Este campo contiene un entero, que indica el número de bytes que forman el resto del
mensaje (eso es los campos de estado y de datos, la suma de verificación ó checksum no se
incluye). El dispositivo receptor utiliza esto para identificar el byte de suma de verificación y
para determinar cuando el mensaje se ha completado. Como el campo de datos esta limitado a
25 bytes máximo, esta cuenta puede ser cualquier número decimal entre 0 y 27.
Estado:
El campo de estado también es llamado el “código de respuesta”, solo se incluye en el
mensaje de respuesta de un esclavo. Consta de dos bytes, a través de los cuales se reporta
cualquier error de comunicación, el estado del comando recibido (como por ejemplo
dispositivo ocupado o que no reconoce dicho comando), y el estado de operación del esclavo.
Datos:
No todas las respuestas contienen datos. Para aquellas que si, y además cumplan con
las reglas de tiempo, el campo de datos no puede exceder los 25 bytes. Los datos pueden estar
en forma de enteros sin signo, números de punto flotante o cadenas de caracteres ASCII. El
número de bytes del campo de datos, y el formato de datos utilizado para cada ítem se
especifican de acuerdo al comando recibido.
Suma de verificación (checksum):
El byte de suma de verificación contiene el OR exclusivo (paridad longitudinal) de
todos los bytes que le preceden en el mensaje, comenzando con el carácter de inicio. Esto
provee un segundo chequeo para la integridad de la transmisión después de la paridad por
byte. La combinación de estos dos garantiza la detección de hasta tres errores en un mensaje y
tiene buenas probabilidades de detectar errores en más bits.
Para una información más detallada sobre el Protocolo Hart, consultar
[FEBRES,2001].
27
MARCO TEÓRICO
3.4.2.- Modbus
3.4.2.1.- Introducción
El protocolo Modbus emplea el principio de amo – esclavo aunque la red de
comunicación sea persona a persona, en el cual el dispositivo (el amo) puede inicializar
transacciones llamadas “queries”3. Los otros dispositivos (los esclavos) responden al amo
enviando la data solicitada o ejecutando la acción requerida en el query.
El dispositivo amo puede direccional individualmente a los esclavos, o puede
inicializar un mensaje de difusión (broadcast, en inglés) a todos los esclavos. Éstos devuelven
un mensaje o respuesta a las preguntas que son direccionadas individualmente a cada uno de
ellos. Las respuestas no son contestadas al query de difusión hecho por el amo.
El protocolo Modbus establece un formato para las preguntas hechas por el amo, donde
incluye la dirección del dispositivo (o en su defecto la dirección broadcast), un código de
función de acuerdo a la acción solicitada, una data a ser enviada, y un campo de chequeo de
error. Por otra parte, el formato del mensaje de respuesta originario del esclavo, contiene
campos de confirmación de la acción ejecutada, alguna data a ser regresada, y un campo de
chequeo de error. Si algún error ocurre en la recepción del mensaje, o si el esclavo no esta en
capacidad de realizar la acción solicitada, el esclavo construye un mensaje de error y lo envía
como su respuesta. En la Figura 3.11 que se muestra a continuación se puede apreciar el ciclo
establecido entre el amo y el esclavo.
La Pregunta:
El Código de Función en la Pregunta le dice al dispositivo esclavo direccionado que
tipo de acción debe ejercer. Los bytes de datos contienen información adicional que el esclavo
necesita para ejecutar la función. Por ejemplo, el código de función 03 le solicita al esclavo la
lectura de los registros de mantenimiento (holding registers, en inglés), y éste responde con
los datos contenidos en tales registros. El campo de datos debe contener la información del
registro de inicio en la cual empezará a leer el esclavo, así como también la cantidad de
3
En español se interpreta como preguntas, solicitudes.
28
MARCO TEÓRICO
registros a leer. El campo de chequeo de error proporciona un método para que el esclavo
pueda validar la integridad de los contenidos del mensaje.
Figura 3.11.- Ciclo de Pregunta – Respuesta en Modbus
La Respuesta:
Si el esclavo hace una respuesta normal, el código de función en la respuesta es una
replica del código de función en la preguntas. Los bytes de datos contienen la información
recolectada por el esclavo, tal como los valores de registro o estatus. Si un error ocurre, el
código de función es modificado para indicar que la respuesta es un error, y los bytes de datos
contienen un código que describe el error. El campo de chequeo de error le permite al amo
confirmar que el contenido del mensaje es válido.
Dos Modos de Transmisión Serial:
Existen dos modos de comunicación serial en las redes Modbus estándar; ASCII y
RTU. Los usuarios pueden seleccionar el modo deseado, siempre y cuando sea el mismo para
todos los dispositivos en la red Modbus. Cada modo define el contenido de bit de los campos
del mensaje transmitidos serialmente, y determina como la información será empaquetada en
los campos del mensaje, para su posterior decodificación.
29
MARCO TEÓRICO
El proyecto contempla la utilización del modo RTU. Por ello a lo largo del libro no se
hace referencia al modo ASCII. Para más detalles sobre este protocolo consultar
[MODICON,1996].
3.4.2.2.- Modbus RTU
En el modo RTU (siglas en inglés de Remote Terminal Unit) cada byte en el mensaje
contiene dos caracteres en hexadecimal. La principal ventaja de este modo es que su mayor
densidad de caracteres permite mejor transferencia de datos que el ASCII para una misma tasa
de baudios. Cada mensaje debe ser trasmitido en una corriente de bits continua.
El formato de cada byte en el modo RTU es el siguiente:
Sistema de Codificación:
Binario 8 – bit, hexadecimal 0-9, A-F
Dos caracteres hexadecimal contenidos
en cada campo de 8 bit del mensaje
Bits por Byte:
1 bit de inicio
8 bits de datos, LSB4 se envía primero
1 bit de paridad (par/impar); 0 bit sin paridad
1 bit de parada (con paridad); 2 bits (sin paridad)
Campo de Chequeo de Error:
Chequeo de Redundancia Cíclica
(CRC, siglas en inglés de Cyclic Redundancy Check)
3.4.2.3.- Modbus TCP
Modbus TCP/IP es un protocolo de Internet. De hecho TCP/IP es el protocolo de
transporte de Internet, lo que significa automáticamente que Modbus TCP puede ser usado
sobre la Internet. Por lo tanto, un dispositivo instalado en Barinas (Venezuela), puede ser
direccionado a través de Modbus TCP/IP desde Caracas (Venezuela), o desde cualquier otra
parte del mundo. Se puede obtener información adicional de este protocolo en
[INTELLICOM, 2005].
4
Least Significant Bit. En español, Bit Menos Significativo.
30
MARCO TEÓRICO
Modbus TCP básicamente embebe, de una manera simple, un marco (frame) Modbus
en un marco TCP. Esto es una transacción orientada a conexión lo cual significa que cada
query o pregunta debe tener su correspondiente respuesta.
El principio de pregunta/respuesta se ajusta bien a la naturaleza de amo/esclavo de
Modbus, unido a la ventaja determinística que el Ethernet suichado ofrece a los usuarios
industriales. El uso de Modbus con el marco TCP proporciona una solución totalmente
escalable de diez a cientos de nodos sin mayor riesgo. En la Figura 3.12 se muestra el marco
del Modbus TCP.
Identificador de
Transacción
MARCO
MODBUS
Identificador
de Protocolo
Dirección del
Dispositivo
Campo de
Longitud
Código de
Función
Marco Modbus
Datos
MARCO
TCP
Chequeo
de Error
Figura 3.12.- Marco Modbus TCP
3.4.2.4.- Enmarcado del Mensaje Modbus
El mensaje Modbus es generado por el dispositivo transmisor dentro un marco (frame,
en inglés) que tiene un punto conocido de inicio y de fin. Esto le permite a lo receptores ubicar
el comienzo del mensaje, leer la porción correspondiente a la dirección y determinar cual
dispositivo es direccionado (o todos los dispositivos, si el mensaje es de difusión), y por
último, conocer cuando ha culminado el mensaje. Los mensajes incompletos pueden ser
detectados y los errores ocurridos pueden ser enviados como un resultado.
Enmarcado RTU:
En este modo, los mensajes comienzan con un intervalo de silencio de no menos de 3.5
veces de caracter. Esto es implementando más fácilmente como un múltiple de veces de
31
MARCO TEÓRICO
caracter en la tasa de baudios, el cual es utilizado en la red (mostrando en la Figura 3.13 como
T1-T2-T3-T4). El primer campo transmitido es la dirección del dispositivo.
Inicio
Dirección
Función
Datos
T1 – T2 – T3 –T4
8 bits
8 bits
n x 8 bits
Chequeo de
Error (CRC)
16 bits
Final
T1-T2-T3-T4
Figura 3.13.- Marco Modbus RTU
Los caracteres permitidos para todos los campos son hexadecimal 0-9, A-F. Los
dispositivos monitorean continuamente el bus de la red, incluso durante los intervalos de
silencio. Cuando el primer campo (el campo de dirección) es recibido, cada dispositivo lo
decodifica para determinar si el es el dispositivo direccionado.
Seguido al último caracter transmitido, un intervalo similar de no menos de 3.5 veces
de caracter marca el final del mensaje, por lo tanto, un nuevo mensaje puede comenzar
después de este intervalo.
Similarmente, si un nuevo mensaje comienza antes del intervalo final de las 3.5 veces
de caracter de un mensaje previo, el receptor lo considera como una continuación del mensaje
previo. Esto origina un error, como un valor inválido del campo CRC (o Chequeo de Error)
por la combinación de los mensajes. Un marco típico del mensaje Modbus RTU se muestra a
continuación.
Campo de Dirección:
El campo de dirección del marco del mensaje contiene 8 bits en el modo RTU. El
rango de las direcciones válidas de dispositivos esta comprendido entre 0 – 247 en decimal.
Los dispositivos esclavos utilizan direcciones comprendidas en el rango entre 1 – 247. Un
dispositivo amo direcciona a un esclavo colocando la dirección del esclavo en el campo
correspondiente en el mensaje. Cuando el esclavo envía su respuesta, éste ubica su propia
dirección en el campo de dirección para que el amo conozca cual dispositivo esta
respondiendo.
32
MARCO TEÓRICO
La dirección 0 es utilizada como la dirección de difusión, la cual todos los dispositivos
reconocen. Cuando el protocolo Modbus es utilizada en redes de alto nivel, la difusión puede
no ser permitida y puede ser reemplazada por otros métodos.
Campo de Función:
El campo de código de función de un marco de mensaje contiene 8 bits en el modo
RTU. Los códigos válidos están en el rango de 1 – 255 en decimal. Dependiendo del
dispositivo algunos códigos aplican, otros no.
Cuando un mensaje es enviado del amo al esclavo, el campo de código le permite al
esclavo saber que tipo de acción realizar. Por ejemplo, la lectura de estado 0N/OFF de un
grupo de entradas analógicas y discretas; la lectura de contenido de datos de un grupo de
registros; la lectura del estatus de diagnostico de un dispositivo esclavo; la escritura a
determinados registros; o permitir la carga, el grabado, o la verificación de un programa con el
esclavo.
Cuando el esclavo le responde al amo, éste utiliza el campo de código de función para
indicar si es una respuesta sin error o si algún tipo de error ocurrió (llamada una respuesta de
excepción). Para una respuesta normal, el esclavo simplemente replica el código de función
original. Para una respuesta de excepción, el esclavo retorna un código que es equivalente al
código de función original con su bit más significativo puesto en 1 lógico.
Por ejemplo, un mensaje del amo al esclavo para leer un grupo de registros de
mantenimiento (holding registers, en inglés) tendría el siguiente código de función:
0000 0011 (hexadecimal 03)
Si el dispositivo esclavo toma la acción solicitada sin error, éste regresa el mismo
código como su respuesta. Si excepción ocurre, éste regresa:
1000 0011 (hexadecimal 83)
33
MARCO TEÓRICO
En adición a su modificación del código de fundón, el esclavo coloca un código único
en el campo de datos en el mensaje de respuesta. Esto le dice al esclavo que tipo de error
ocurrió, o la razón de la excepción. La aplicación del dispositivo amo tiene la responsabilidad
de manejar respuestas de excepción.
Campo de Datos:
El campo de datos es construido utilizando conjuntos de dígitos hexadecimales, en el
rango de 00 a FF hexadecimal. El campo de data de los mensajes enviados de un amo a un
esclavo contiene información adicional, la cual debe ser usada por el esclavo para tomar la
acción definida por el código de función. Esto puede incluir direcciones de registros, la
cantidad de términos a ser manejados, y la cuenta de bytes de la data actual en el campo.
Por ejemplo, si el amo le solicita al esclavo la lectura de un grupo de registros de
mantenimiento (código de función 03 en hex), el campo de datos especifica el registro de
comienzo y cuantos registros serán leídos. Si el amo escribe a un grupo de registros en el
esclavo (código de función 10 en hex), el campo de datos especifica el registro de comienzo,
la cantidad de registros a escribir, la cuenta de bytes de datos tal campo, y los datos a escribir
en los registros. Si no ocurre error, el campo de datos de una respuesta esclavo – amo,
contiene la información solicitada. De lo contrario, el campo contiene un código de excepción.
El campo de datos puede ser no-existente (de longitud cero) en ciertos tipos de
mensajes. Por ejemplo, cuando el amo solicita el registro (log, en inglés) de evento de
comunicaciones, el esclavo no requiere ninguna información adicional. El código de función
por sí solo especifica la acción completa.
Campo de Chequeo de Error:
En modo RTU, el campo de chequeo de error contiene un valor de 16 bits
implementado con dos bytes. El valor del chequeo de error es el resultado de un cálculo de
Chequeo de Redundancia Cíclica (CRC, siglas en inglés) realizado al contenido del mensaje.
34
MARCO TEÓRICO
El campo de CRC esta adherido al mensaje como el último campo del mismo. Cuando
está hecho, el byte de orden bajo se encuentra seguido del byte de orden alto. El byte de orden
alto del CRC es el último byte enviado en el mensaje.
Registros Modbus Más Utilizados:
•
Coil Status: Estatus ON/OFF de salidas discretas (referenciadas
con 0X) en el esclavo. Soportan Lectura y Escritura. No es
soportada la difusión o broadcast. Ejemplo: El registro 08004,
es de Coil Status.
•
Input
Status:
Estatus
ON/OFF
de
entradas
discretas
(referenciadas con 1X) en el esclavo. Soportan solo Lectura.
No es soportada la difusión. Ejemplo: El registro 10000, es de
Input Status.
•
Holding Register: Contenido binario referenciado con 4X en el
esclavo. Soportan Lectura y Escritura. No es soportada la
difusión. Ejemplo: El registro 41008, es un Holding Register.
•
Input Register: Contenido binario referenciado con 3X en el
esclavo. Soportan solo Lectura. No es soportada la difusión.
Ejemplo: El registro 30010, es un Input Register.
3.4.3.- HTTP
El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol, en inglés)
es un sencillo protocolo cliente-servidor que articula los intercambios de información entre los
clientes Web y los servidores HTTP. La especificación completa del protocolo HTTP 1/0 está
recogida en el RFC 1945. Fue propuesto por Tim Berners-Lee, atendiendo a las necesidades
de un sistema global de distribución de información como el World Wide Web.
Desde el punto de vista de las comunicaciones, está soportado sobre los servicios de
conexión TCP/IP, y funciona de la misma forma que el resto de los servicios comunes de los
entornos UNIX: un proceso servidor escucha en un puerto de comunicaciones TCP (por
defecto, el 80), y espera las solicitudes de conexión de los clientes Web. Una vez que se
35
MARCO TEÓRICO
establece la conexión, el protocolo TCP se encarga de mantener la comunicación y garantizar
un intercambio de datos libre de errores.
HTTP se basa en sencillas operaciones de solicitud/respuesta (ver Figura 3.14). Un
cliente establece una conexión con un servidor y envía un mensaje con los datos de la solicitud
o petición. El servidor responde con un mensaje similar, que contiene el estado de la operación
y su posible resultado. Todas las operaciones pueden adjuntar un objeto o recurso sobre el que
actúan; cada objeto Web (documento HTML, fichero multimedia o aplicación CGI) es
conocido por su URL.
Cliente
Servidor
HTTP
Figura 3.14.- Principio de Solicitud/Respuesta del Protocolo HTTP
Las principales características del protocolo HTTP son:
•
Toda la comunicación entre los clientes y servidores se realiza a partir de
caracteres de 8 bits. De esta forma, se puede transmitir cualquier tipo de
documento: texto, binario, etc., respetando su formato original.
•
Permite la transferencia de objetos multimedia.
•
Existen tres verbos básicos (hay más, pero por lo general no se utilizan)
que un cliente puede utilizar para dialogar con el servidor: GET, para
recoger un objeto, POST, para enviar información al servidor y HEAD,
para solicitar las características de un objeto (por ejemplo, la fecha de
modificación de un documento HTML).
36
MARCO TEÓRICO
•
Cada operación HTTP implica una conexión con el servidor, que es
liberada al término de la misma. Es decir, en una operación se puede
recoger un único objeto.
•
No mantiene estado. Cada petición de un cliente a un servidor no es
influida por las transacciones anteriores. El servidor trata cada petición
como una operación totalmente independiente del resto.
•
Cada objeto al que se aplican los verbos del protocolo está identificado a
través de la información de situación del final de la URL.
En [UNICAN, 2005] se encuentra más información sobre el protocolo HTTP.
3.4.4.- XML – RPC
Es un conjunto de implementaciones que permiten ejecutar programas en sistemas
operativos diferentes, corriendo en ambientes diferentes para hacer llamadas a procedimiento
sobre la Internet. Es decir, es la Llamada Remota de Procedimiento (ó RPC, por sus siglas en
inglés) usando el protocolo HTTP como el transporte y el XML (Extensible Markup
Language) como el codificador. XML – RPC es diseñado para ser tan simple como sea
posible, permitiendo que estructuras complejas de datos sean transmitidas, procesadas y
regresadas.
Una llamada de procedimiento es el nombre del procedimiento, sus parámetros, y el
resultado que genera. RPC es una extensión muy sencilla de la idea de llamada de
procedimiento, permitiendo crear conexiones entre procedimientos que están corriendo en
diferentes aplicaciones, o en diferentes máquinas.
Conceptualmente, no hay diferencia entre una llamada local de procedimiento y una
remota, pero ellas son implementadas de manera diferente, tienen un desenvolvimiento
diferente (RPC es mucho más lento), y por consiguiente, son usadas para utilidades diferentes.
Las llamadas remotas son enmarcadas en un formato que puede ser entendido desde el
otro lado de la conexión. Mientras las dos máquinas estén de acuerdo en un formato, ellas se
pueden hablar entre sí. He ahí el valor de estandarizar la plataforma intermedia para poder
37
MARCO TEÓRICO
hacer llamadas de procedimiento entre máquinas de sistemas operativos diferentes, por
ejemplo, máquinas Unix hablen con máquinas Windows y viceversa.
Hay un número infinito de formatos posibles para la estandarización entre los
diferentes sistemas. Un formato es XML, un nuevo lenguaje que tanto los humanos como los
computadores pueden leer. XML – RPC emplea XML para establecer el formato. Con este
lenguaje de marcado es fácil ver lo que se este haciendo, y también es relativamente fácil
replicar el formato interno de llamada de procedimiento en un formato remoto. Para mayor
información consultar [XML-RPC, 2005]
3.4.5.- Interfaces RS - 232 & RS- 485
La interfaz RS-232 es bien conocida debido a la popularidad que tienen hoy en día las
PCs, a diferencia de RS-485, la cual es utilizada a nivel industrial para sistemas de control y
transferencia de volúmenes pequeños de datos.Las señales RS-232 son representadas por
niveles de voltajes con respecto a tierra. Tiene un cable para cada señal junto con la señal de
tierra (referencia para los niveles de voltaje). Esta interfaz es útil para la comunicación punto a
punto a bajas velocidades. Por ejemplo, el puerto COMM1 en una PC puede ser utilizado para
un ratón, el COMM2 para un modem, etc. Este es un ejemplo de una comunicación punto a
punto: un puerto, un dispositivo. Debido a la manera que las señales son conectadas, una tierra
común es requerida. Esto implica cable limitado de longitud alrededor de 30 a 60 metros como
máximo, los principales problemas son la interferencia y la resistencia del cable. RS - 232 fue
diseñado para comunicación de dispositivos locales, y soporta un transmisor y un receptor.
RS - 485 utiliza un principio diferente: Cada señal utiliza una línea de par trenzado (2
cables trenzados alrededor de ellos mismos). Se habla de Transmisión de Data Balanceada o
Transmisión de Voltaje Diferencial. Por simplicidad, se habla de un par trenzado ‘A’ y otro
‘B’. Entonces, la señal esta inactiva cuando el voltaje en ‘A’ es negativo y el voltaje en ‘B’ es
positivo. De otra forma, la señal esta activa cuando ‘A’ es positivo y ‘B’ es negativo. Con RS 485 el cable puede sobrepasar los 1200 metros de longitud, y comúnmente trabaja en circuitos
a una tasa de transferencia a 2.5 MB/s.
38
MARCO TEÓRICO
La interfaz RS - 485 utiliza transmisores diferenciales con voltajes alternados entre 0 y
5V. Por utilizar dos pares trenzados de cables, la data puede ser transferida en ambas
direcciones simultáneamente. Esta interfaz es utilizada para comunicación multipunto, en la
cual muchos dispositivos pueden ser conectados a un cable de señal sencillo, similar a redes
Ethernet de cable coaxial. La mayoría de los sistemas emplean la arquitectura Amo/Esclavo,
cuando cada unidad esclavo tiene su dirección única y responde sólo a los paquetes
direccionados a esta unidad. Esos paquetes son generados por un amo, el cual periódicamente
chequea todas las unidades esclavas conectadas. La interfaz RS - 485 existe en dos versiones:
la de un solo par trenzado y la de dos pares trenzados.
Un solo par trenzado:
En esta versión, todos los dispositivos están conectados en un par trenzado sencillo.
Por lo tanto, cada uno de ellos debe tener manejadores de salidas tri-state (incluyendo el amo).
La comunicación se realiza sobre la línea sencilla en ambas direcciones. Es importante
prevenir que muchos dispositivos transmitan a la vez (problema de programa). Ver Figura
3.15.
Doble par trenzado:
Aquí, el amo no es necesario que tenga salida con tri-state, ya que el esclavo transmite
sobre el segundo par trenzado. Ver Figura 3.16.
Equipo Terminal de Data
(DTE, en inglés)
Periférico
RS-485
Conector
DB9
Figura 3.15.- RS -485 de un solo par trenzado
39
MARCO TEÓRICO
Equipo Terminal de Data
(DTE, en inglés)
Periférico
RS-485
Conector
DB9
Figura 3.16.- RS -485 de dos pares trenzado
3.5.- PC Industrial Modular / Arquitectura Net-DAS
3.5.1.- Características Técnicas
El computador utilizado para la implementación de la Arquitectura Net-DAS,
(arquitectura que se estudiará más adelante en la sección 3.5.4) está basada en el estándar
PC/104-Plus, con las siguientes características técnicas principales:
•
Procesador Intel Pentium III de 700 MHz
•
512 MB de Memoria RAM
•
Compact Flash de 1 GB (Dispositivo de Almacenamiento)
•
10 puertos de Comunicación Serial (2 RS – 232 + 8 configurable como RS
-232/RS - 485).
•
1 puerto paralelo.
•
2 Puertos USB.
•
Controlador de Unidad de Diskette, de Teclado y de Ratón.
•
Controlador Gráfico Integrado.
•
Ethernet 10/100 Base T
•
Sistema Operativo Embebido QNX 4.0
40
MARCO TEÓRICO
3.5.2.- Estándar PC/104
PC/104 se trata del bus ISA adaptado para satisfacer las necesidades de las
aplicaciones empotradas e industriales. Es un estándar para módulos PC-compatible que
pueden ser apilados uno sobre otro para crear un sistema de cómputo empotrado. El estándar
PC/104 se describe como una especificación publicada por el consorcio PC/104. Su nombre
(PC/104) deriva de su arquitectura PC y el conector de 104 pines.
Seleccionando la tecnología PC/104, ingenieros y programadores pueden tomar ventaja
de sus conocimientos de hardware y software PC-compatible para desarrollar rápidamente
sistemas empotrados. PC/104 es simplemente una versión de la arquitectura PC para
aplicaciones empotradas e industriales, donde el espacio, consumo de energía, o la
confiabilidad son factores críticos.
Los sistemas basados en PC/104 son utilizados para varias aplicaciones, incluyendo
fábricas, laboratorios, plantas de proceso, vehículos y casi cualquier otro lugar donde los
dispositivos deban ser controlados por una computadora programable.
PC/104 difiere de sistemas PC estándar en lo siguiente:
•
Las tarjetas PC104 (90 x 96mm) son mucho mas pequeñas que las tarjetas
ISA comparable a un disquete de 3.5”. Se apilan una sobre otra mediante
conectores pin /socket, lo que elimina la necesidad de placas base,
backplane o chasis.
•
Se reducen los requerimientos de alimentación (1-2 Vatios por modulo) y
manejo de señal (4mA) y minimiza la circuiteria.
•
Además de esto, los sistemas PC104 están diseñados para ser más robustos
que los sistemas PC.
Los módulos PC/104 se encuentran comercialmente disponibles para un amplio rango
de funciones, incluyendo:
•
Tarjetas CPU compatibles con PC completas
41
MARCO TEÓRICO
•
Entradas / Salidas analógicas y digitales
•
Video: VGA, LCD, EL, Frame Grabbers
•
Redes: Ethernet, CAN bus, ARCNET
•
Controladores : FDD, IDE HDD, SCSI
Las especificaciones PC/104 mecánicas y eléctricas comunes de los módulos hacen
que sean intercambiables con productos de cualquiera de los cientos de fabricantes de
dispositivos PC/104 que existen actualmente. Entre algunas formas de utilizar módulos
PC/104, se tienen:
•
Un modulo PC/104 puede ser utilizado como un sistema independiente (stand–
alone)
•
Módulos PC/104 pueden ser añadidos como parte de otro sistema (cPCI, VME, etc)
•
Múltiples módulos PC/104 pueden ser apilados entre si para crear un sistema.
PC/104-Plus
PC/104-Plus es básicamente el agregado del bus PCI (Peripheral Component
Interconnect5) al estándar PC/104. PCI permite acceso directo a los dispositivos periféricos al
CPU el cual puede mejorar en forma considerable el desempeño el sistema. PC/104-Plus ha
llegado justo a tiempo para controladores de video, procesadores y otros dispositivos de alto
rendimiento, manteniendo la compatibilidad hacia atrás con PC/104. La especificación
PC/104-Plus define la adición de PCI a PC/104 incluyendo detalles de los conectores. El
nuevo conector tiene 120 pines con espacio de 2mm.
3.5.3.- Estructura del PC Industrial Modular
El Computador Personal Industrial Modular está conformado por cinco módulos
interconectados a través del conector de 104 pines (ver Figura 3.17). Las especificaciones
técnicas de cada módulo se encuentran el Apéndice A. Los módulos están apilados en el
mismo orden (de arriba hacia abajo) como son descritos a continuación.
5
Interconexión de Componente Periférico
42
MARCO TEÓRICO
Figura 3.17.- PC Industrial Modular PC/104-Plus
Módulo MOPSlcd7
Es la tarjeta madre del equipo. En este módulo se encuentra el procesador Intel
Pentium III de 700 MHz, la memoria RAM de 512 MB, dos puertos RS - 232, un puerto
paralelo, una entrada IDE6 para dispositivo de almacenamiento, conector para la unidad de
diskette, conector para el modem, una salida de video y por último, conectores para teclado y
ratón. El módulo MOPSlcd7 se muestra en la Figura 3.18.
Figura 3.18.- Módulo MOPSlcd7
6
Intergrated Drive Electronics, una interfaz popular para conectar dispositivo de almacenamientos en PCs.
43
MARCO TEÓRICO
Módulo PCM-3116
Permite manejar el Compact Flash como un dispositivo de almacenamiento de
conector IDE. Este salida IDE va conectada a través de un cable plano a la entrada de la tarjeta
madre. Este módulo se muestra en la Figura 3.19.
Salida IDE
Compact Flash
Figura 3.19.- Módulo PCM-3116
Módulo PCM-3660
Es la Tarjeta de Red del Computador. Tiene las siguientes características técnicas (ver
Figura 3.20):
•
Rendimiento de Procesamiento de 10Mbps
•
Bus de data de 8/16 bits (auto-detección)
•
Direcciones de I/O: 300,320,340 o 360 en hexadecimal.
•
IRQ: 3,4,5,9,10,11,12, ó 15
•
Conector 10 Base – T
•
Fuente de Poder Sencilla de +5V @ 400 mA.
•
Incluye los drives para ODI, NDIS, PC/TCP, PC-NFS, NCSA, LAN, PATHWAY,
WFW y SCO UNIX.
44
MARCO TEÓRICO
Figura 3.20.- Módulo PCM-3660
Módulo Xtreme/104
El adaptador Xtreme/104 ofrece ocho puertos seriales RS - 232 y/o RS - 422/485 para
los dispositivos de recolección de data en automatización industrial (ver Figura 3.21). Este
adaptador fue diseñado para soluciones industriales para aplicaciones de control y
automatización que requieren comunicación de nodo simple o comunicaciones multipunto
para cortas o largas distancias utilizando computadores compatibles con bus PC/104. Las
especificaciones en detalle se muestran en la Tabla 3.3.
Figura 3.21.- Módulo Xtreme/104
45
MARCO TEÓRICO
Tabla 3.3.- Especificaciones Módulo Xtreme/104
Número de Puertos
Interfaz Eléctrica
Ocho
RS-232 y/o RS-422/485. Cada puerto es seleccionable
por jumper.
Dos conectores de 40 pines para los ocho puertos. (un
cable plano con cuatro cables DB-9 por cada conector
Conectores
de 40 pines)
Señales de Control
RS - 422/485: TxD +, RxD +, CTS +, RTS +
RS-232: 50 bps - 230,4 Kbps
Tasa de Baudios
RS-422/485: 50 bps - 460,8 Kbps
Ocho grupos predefinidos de direcciones I/O son
Direcciones I/O
seleccionables por jumper.
Seleccionables
Interrupciones
por
jumper
para
IRQs
3,4,5,6,7,9,10,11,12,14,15
Requerimientos de Fuente de
Poder
RS-232: DTR, DST, RTS, CTS, RI, TxD, RxD, DCD
+ 5VDC @ 100 mA (max)
+5%
Módulo HE104
El Módulo HE104 de múltiple salida DC es una unidad de alta eficiencia y de alto
desempeño diseñado para sistemas de computadores embebidos PC/104 de bajo ruido, con un
rango de entrada comprendido entre 6 y 40 V (ver Figura 3.22). Las especificaciones técnicas
se muestran en la Tabla 3.4.
Figura 3.22.- Módulo HE104
46
MARCO TEÓRICO
Tabla 3.4.- Especificaciones Módulo HE104
Salida de 5V
10 A
Salida de 12V
2A
Salida de -5V
400 mA
Salida de -12V
500 mA
Rango de Voltaje de Entrada
6 a 40V
Regulación de Carga
< 60 mV
Regulación de Línea
+ 40 mV
Frecuencia de Suicheo
75 KHz
Ripple de Salida
< 20 mV
Rango de Temperatura
-40 a 85 °C
3.5.4.- Arquitectura Net-DAS
3.5.4.1.- Definición
Network Data Acquisition System (en español, Sistema de Adquisición de Datos en
Red) es un sistema de supervisión y control, construido sobre elementos comerciales abiertos:
PC Industrial Modular PC/104-Plus, Interfaces de Campo (Hart, RS-485,TCP/IP, Direct I/O),
sistema Operativo QNX - Linux, SoftPLC Virgo ISAGRAF IEC1131 (SFC, FBD, ST, IL, LD
+ FC), Radios IP, Interconectividad hacia campo (Modbus RTU/TCP, Hart, Fieldbus),
Interconectividad hacia usuario (Modbus, XML, PHP, HTML, Applets de Java, Corba, SQL,
ODBC, OPC); a los cuales se les ha agregado valor y funcionalidad en cuanto a conectividad,
integrabilidad, mantenibilidad y aplicaciones de negocio, mediante el desarrollo de programas
basados en tecnologías de comunicación TCP/IP, de bases de datos y de IHM7 sobre
navegadores Web.
El Sistema Net-DAS ha sido desarrollado por Intevep, S.A por parte de Petróleos de
Venezuela, S.A. Para mayor información sobre esta arquitectura revisar [INTEVEP, 2004].
7
Interfaz Hombre – Máquina.
47
MARCO TEÓRICO
3.5.4.2.- Objetivos
El Sistema Net-DAS se desarrollo con el fin de:
•
Adquirir, procesar, convertir y transmitir grandes cantidades de
variables de cualquier proceso industrial, desde sus instalaciones en
campo hasta los sistemas de información, control, y bases de datos
corporativas,
mediante
la
programación
de
protocolos
de
comunicación asociados a dispositivos ya existentes o propios.
•
Monitorear y controlar las instalaciones de campo utilizando
navegadores Web convencionales y estándares sin que se haga
indispensable de invertir en sistemas especializados (SCADA).
3.5.4.3.- Ventajas
Entre las principales ventajas que ofrece el Sistema Net-DAS se encuentran:
•
Permite la Adquisición y transmisión de nuevos tipos de variables,
caracterizadas por contener grandes volúmenes de información, tales
como perfiles térmicos y cartas dinagráficas, entre otros.
•
Realiza la distribución masiva de la información de proceso de
campo a toda la Corporación sin necesidad de adquirir sistemas de
programas de visualización especializados y agregando valor a la
infraestructura de redes ya instalada.
•
Efectúa la conversión de protocolos entre dispositivos especializados
que generan la información de campo y los sistemas corporativos de
visualización, almacenamiento y explotación de dicha información,
permitiendo
así
la
integración
de
sensores,
analizadores
especializados y los sistemas de automatización ya existentes,
utilizando como medio la Internet/Intranet.
•
Permite el control avanzado de procesos de producción mediante la
ejecución en campo, de lógicas y aplicaciones de alto nivel descritas
en cualquier combinación de los lenguajes IEC-61131-3 y lenguajes
como C y Java.
48
MARCO TEÓRICO
•
Configuración y explotación de los datos vía Web, usando
protocolos estándares no propietarios tales como Java y Modbus
TCP.
•
Esta equipado con aplicaciones propias del negocio para la
supervisión y control especializados de instalaciones 2S (explotación
de data SAGD, Cartas Dinagráficas, AI2S, Weltech, WTD, etc.)
•
Responde a los requerimientos del concepto AI2S, en cuanto a
escalabilidad, conectividad, mantenabilidad y capacidad de disponer
de toda la inteligencia en sitio para ejecutar las funciones de control,
supervisión y optimización en tiempo real.
3.5.4.4.- Características
Las características más relevantes del Sistema Net-DAS se pueden clasificar en los
siguientes rubros:
a. Aplicación y Configuración
Se realizan remotamente o localmente: descarga de software desarrollado, debugging y
mantenimiento de las lógicas realizadas. Dicha configuración y actualización se pueden
realizar local o desde cualquier computadora en PDVSA vía Web/TCP/IP (caso remoto), sin
detener los procesos.
b. Obtención de los Datos hacia:
•
Campo: Vía Modbus RTU, Modbus TCP, Hart, I/O directo, Fieldbus,
otros especiales.
•
SCADA: Vía Modbus RTU, Modbus TCP, OPC.
•
Hacia aplicaciones: Igual a SCADA más SQL, Applets de Java para
Web, servlets PHP y Java, Corba.
•
Otras Net-DAS: anterior + intercambio de variables entre lógicas sobre
TCP/IP.
•
Conectividad global gracias a la aplicación de las tecnologías de redes y
servicios TCP/IP en aplicaciones de supervisión y control en campo.
49
MARCO TEÓRICO
c. Entradas y Salidas
Net-DAS soporta un número ilimitado de entradas y salidas tanto analógicas como
digitales, las cuales son cambiables “en caliente” sin parar el proceso ni desconectar el campo.
d. Integración de Elementos de Campo:
Capacidad de integrar transmisores Hart directamente, pudiéndose realizar la
configuración de dichos transmisores desde el SCADA. Igualmente Net-DAS es capaz de
integrar múltiples equipos y obtener de estos sus datos.
e. Control:
Posee la capacidad de: ejecutar varios PLC virtuales para acciones de control en un
mismo Hardware, diferentes lógicas en diferentes RTUs (repartición de carga, sistemas DCS),
así como la capacidad de Trending, Data Logging y Alarming en la misma RTU.
f. Protocolos:
•
Capacidad de adquisición de datos desde dispositivos Modbus RTU,
Modbus TCP y Hart, mientras que los datos son comunicados hacia
Sistemas SCADA, mediante Modbus – RTU y Modbus TCP. Con ello
se desprende que el equipo realiza implícitamente conversiones entre
estos protocolos, y la función de concentrador de datos.
•
No existe limitación en cuanto a los protocolos, pues el sistema es
modular y expansible en cuanto a la cantidad de protocolos, tanto amos
como esclavos que se deseen ejecutar en un momento dado.
g. Comunicación/Conectividad:
Dos opciones para la comunicación CPU – señales de entradas y salidas (I/O
Remotos):
1. RS-485 multipunto, bajo Modbus RTU.
2. TCP/IP Ethernet, bajo Modbus TCP.
50
MARCO TEÓRICO
h. Supervisión:
•
Se puede iniciar cámara de video en color, para supervisión visual vía
navegadores Web desde cualquier computadora de PDVSA.
•
Es factible establecer el envío de fotos automáticamente, a intervalos
regulares, a otra computadora o servidor Web, o vía email a cualquier
usuario.
3.6.- Servidor HTTP Apache
El Servidor HTTP Apache es un servidor HTTP de código abierto para plataformas
Unix (BSD, GNU/Linux, etc.), Windows y otras, que implementa el protocolo HTTP (ver
sección 3.4.3) y la noción de sitio virtual. Cuando comenzó su desarrollo en 1995 se basó
inicialmente en código del popular NCSA HTTPd 1.3, pero más tarde fue reescrito por
completo. Su nombre se debe a que originalmente Apache consistía solamente en un conjunto
de parches a aplicar al servidor de NCSA. Era, en inglés, a patchy server (un servidor
parcheado).
El Servidor HTTP Apache tiene capacidad para servir páginas tanto de contenido
estático (para lo cual serviría sencillamente un viejo ordenador 486) como de contenido
dinámico a través de otras herramientas soportadas que facilitan la actualización de los
contenidos mediante bases de datos, ficheros u otras fuentes de información. El servidor
Apache se desarrolla dentro del proyecto HTTP Server (httpd) de la Apache Software
Foundation.
Apache presenta entre otras cosas mensajes de error altamente configurables, bases de
datos de autenticación y negociado de contenido, pero fue criticado por la falta de una interfaz
gráfica que ayude en su configuración. En la actualidad (2005), Apache es el servidor HTTP
más usado, siendo el servidor HTTP del 68% de los sitios Web en el mundo y creciendo aún
su cuota de mercado (estadísticas históricas y de uso diario proporcionadas por Netcraft).
51
MARCO TEÓRICO
3.7.- Lenguajes de Programación
3.7.2.- HTML
HTML, HyperText Markup Language, es un lenguaje simple utilizado para crear
documentos de hipertexto para World Wide Web (siglas WWW). No es un lenguaje de
descripción de página como Postcript; HTML no permite definir de forma estricta la
apariencia de una página, aunque una utilización algo desviada hace que se utilice en
ocasiones como un lenguaje de presentación. Además, la presentación de la página es muy
dependiente del navegador utilizado: el mismo documento no produce el mismo resultado en
la pantalla si se visualiza con navegadores diferentes, o sea, HTML se limita a describir la
estructura y el contenido de un documento, y no el formato de la página y su apariencia.
Una de las claves del éxito de WWW, aparte de lo atractivo de su presentación es sin
duda, su organización y coherencia. Todos los documentos WWW comparten un mismo
aspecto y una única interfaz, lo que facilita enormemente su manejo por parte de cualquier
persona. Esto es posible porque el lenguaje HTML, en que están escritos los documentos, no
solo permite establecer hiperenlaces entre diferentes documentos, sino que es un "lenguaje de
descripción de página" independiente de la plataforma en que se utilice. Es decir un
documento HTML contiene toda la información necesaria sobre su aspecto y su interacción
con el usuario, y es luego el navegador Web el responsable de asegurar que el documento
tenga un aspecto coherente, independientemente del tipo de estación de trabajo desde donde se
efectúe la consulta.
Su simplicidad es tal que no es necesario utilizar un editor particular. Su gran
permisividad exige rigor y atención en la estructura de documentos con el fin de que éstos se
visualicen correctamente al margen del contexto y el navegador utilizado. Por tanto, HTML es
un lenguaje muy sencillo que permite preparar documentos Web insertando en el texto de los
mismos una serie de marcas (tags) que controlan los diferentes aspectos de la presentación y
comportamiento de sus elementos.
Para escribir HTML lo único que se necesita es un editor de texto. Las marcas o tags
que controlan el comportamiento del documento son fragmentos de texto encerrados entre los
52
MARCO TEÓRICO
signos "mayor que" y "menor que" (<marca>). Existen diferentes tipos de marcas: unas,
controlan simplemente la presentación del texto del documento; otras, la forma en que se
incluirán en él imágenes; otras, finalmente, los hiperenlaces con documentos o con diferentes
partes del mismo documento. Existen una serie de programas que ayudan en la elaboración de
documentos HTML, pero no son imprescindibles para escribir el código. Lo que si es
necesario es un programa cliente WWW (navegador) para probar el documento a medida que
se va desarrollando.
Las marcas funcionan muchas veces por parejas, una para indicar el inicio de enlace o
formato, y otra para señalar el final. La marca de inicio consiste en una letra o una palabra (por
ejemplo, estas son marcas de inicio: <B>, <title>). La marca de final es la misma letra o
palabra precedida por la barra inclinada o "slash" (es decir,</B>, </title>). Existen, no
obstante, algunas marcas que no requieren su pareja de cierre, como <br> (que obliga un salto
de línea). Es importante señalar que las marcas, en general pueden estar indistintamente en
mayúsculas o en minúsculas. Como todo lenguaje, está en constante evolución. La versión en
curso es la versión 2.0 pero existe ya un proyecto para la versión 3.0. En [TECNOLOGÍAS
WEB, 2005] se consigue más información sobre HTML y otros lenguajes de programación.
3.7.2.- PHP
PHP (acrónimo de "PHP: Hypertext Preprocessor") es un lenguaje de "código abierto"
interpretado, de alto nivel, embebido en páginas HTML y ejecutado en el servidor. En la
Figura 3.23 se muestra un ejemplo sencillo de PHP.
<html>
<head>
<title>Ejemplo</title>
</head>
<body>
<?php
echo "Hola, este es un script PHP!";
?>
</body>
</html>
Figura 3.23.- Ejemplo sencillo de un código PHP
53
MARCO TEÓRICO
Puede apreciarse que no es igual a un script escrito en otro lenguaje de programación
como Perl o C++. En vez de escribir un programa con muchos comandos para crear una salida
en HTML, se escribe el código HTML con cierto código PHP embebido (incluido) en el
mismo, que producirá cierta salida (en el caso del ejemplo, producirá un texto). El código PHP
se incluye entre etiquetas especiales de comienzo y final que permiten entrar y salir del modo
PHP.
Lo que distingue a PHP de la tecnología JavaScript, la cual se ejecuta en la máquina
cliente, es que el código PHP es ejecutado en el servidor. Si se tuviese un script similar al
ejemplo en el servidor, el cliente solamente recibiría el resultado de su ejecución en el
servidor, sin ninguna posibilidad de determinar qué código ha producido el resultado recibido.
El servidor Web puede ser incluso configurado para que procese todos los archivos HTML
con PHP. Para información completa y detallada sobre este lenguaje consultar [PHP, 2005].
3.7.3.- JavaScript
JavaScript es un lenguaje interpretado por el navegador que permite realizar páginas
interactivas. El lenguaje permite el acceso y manipulación de las propiedades del documento
HTML, de manera que se pueden verificar datos de formularios, hacer animaciones, crear
menús, entre otros. JavaScript no es una versión reducida de Java. Tiene sintaxis similar a
C++ o Java, muchos menos restrictiva (el “;” al final de la sentencia es opcional, la
declaración de variables no es obligatoria, etc. Por otra parte, en este lenguaje no existen
clases; los objetos son colecciones de métodos y propiedades.
3.7.4.- Perl
Perl (Practical Extraction and Report Languaje) es un lenguaje de programación
creado por Larry Wall, surgido a inicios de los noventas, que busca antes que nada el facilitar
la elaboración de tareas comunes en sistemas tipo UNIX, donde tradicionalmente las tareas de
administración y proceso de datos se realiza con herramientas muy rudimentarias y por demás
hostiles al usuario o administrador. Pero que se aplican sobre grandes cantidades de
información (por lo regular texto) por lo que se requiere que sean de alto rendimiento.
54
MARCO TEÓRICO
Perl surgió como una opción para una gran cantidad de herramientas de UNIX en las
cuales basa su propia sintaxis, buscando el mínimo sacrificio de su desempeño por una
máxima facilidad de programación e integración, sigue la filosofía de mantener un ambiente
que sea capaz de detectar y corregir pequeñas omisiones del programador, y de proporcionarle
una forma abreviada de realizar múltiples tareas. En una palabra, es una herramienta que
pretende facilitar el proceso de grandes volúmenes de información sin sacrificar el
rendimiento.
Las plataformas donde Perl más se ha desarrollado son los servidores UNIX, por sus
necesidades de administración y lo robusto de su manejo de memoria y de procesos (requisitos
de PERL hacia el S. O.) además de la facilidad de Perl para realizar los así llamados CGI8,
interfaces para comunicar recursos del servidor con un servicio de Internet particular (como
podría ser WWW). En otras plataformas, PC en particular, se han desarrollado versiones que
mantienen un razonable grado de funcionalidad, pero en realidad, el sistema DOS no tiene un
manejo lo bastante bueno de los procesos o de la memoria para permitir a Perl dar un buen
desempeño, además de que no es común ver en PC necesidades de administración de la
magnitud de un servidor institucional. Sin embargo, puede practicarse la programación en Perl
de PC, o incluso elaborar programas de reporteo en él, sin embargo, es algo que no se ha
popularizado hasta hoy.
Perl no establece ninguna filosofía de programación (de hecho, no se puede decir que
sea orientado a objetos, modular o estructurado aun cuando soporta directamente todos estos
paradigmas), los objetivos que se tuvieron en cuenta al diseñar la sintaxis de Perl fueron la
facilidad de aprendizaje y de uso y la claridad de código, las cuales son necesarias (aunque
pueden escribirse programas en Perl complejos e inteligibles si así se desea).
Por si fuese poco, Perl no es ni un compilador ni un interprete, esta en un punto
intermedio, cuando mandamos a ejecutar un programa en Perl, se compila el código fuente a
un código intermedio en memoria, se le optimiza (como si se fuese a elaborar un programa
ejecutable) pero es ejecutado por un motor, como si se tratase de un interprete. El resultado
final, es que se utiliza algo que se comporta como un intérprete pero que tiene un rendimiento
8
Common Gateway Interface, es un estándar para comunicar aplicaciones externas con los servidores de información.
55
MARCO TEÓRICO
comparativo al de programas compilados. Sin embargo, ya existen compiladores de Perl con la
versión 5.
Perl esté disponible libremente para los sistemas operativos Unix, MVS, VMS,
MS/DOS, Macintosh, OS/2, Amiga y otros. Perl está alcanzado popularidad para la
programación de formularios electrónicos en la WWW, y generalmente, actúa como
intermediario entre sistemas, bases de datos y usuarios.
CAPITULO 4.- SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
4.1.- Introducción
En el presente capítulo se hace una revisión de la metodología empleada para la
planificación, desarrollo e implementación del Sistema, así como también una descripción
técnica detallada de cada una de las partes que conforman al mismo, explicando las
especificaciones y consideraciones que implica su integración, incluyendo el funcionamiento
lógico y operativo de la Arquitectura desarrollada.
4.2.- Metodología
Para cumplir con todos los objetivos planteados, el procedimiento de investigación,
definición e implementación para el desarrollo del proyecto de grado fue dividido en tres
fases:
Primera Fase: Ingeniería
Segunda Fase: Desarrollo e Implementación del Sistema
Tercera Fase: Pruebas
4.2.1.- Primera Fase: Ingeniería
En esta fase se recopiló toda la información en cuanto a los protocolos de
comunicación posibles a utilizar para la interacción de las distintas partes de la Arquitectura,
tanto los protocolos de campo basados en los estándares industriales, como los protocolos
basados en TCP/IP para la disposición de los datos en la red de procesos de la Corporación.
Por otra parte, por las necesidades de adaptar los sistemas de medición a la normativa
impuesta por el Ministerio de Energía y Minas, se requirió el estudio de la información
referida a la Fiscalización de Hidrocarburos Líquidos para posteriormente definir si la
Arquitectura a desarrollar cumplía con estas exigencias. También se realizó la recopilación y
estudio de las arquitecturas de medición actualmente propuestas para las Estaciones de Flujo y
Patio de Tanques en el distrito, referencias acerca de las variables y parámetros a medir y
contabilizar, estudio de los equipos de campo involucrados en la automatización, estudio del
58
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
programa de configuración de
equipo de campo, definición de la nomenclatura de las
variables a integrar en el sistema de supervisión basado en Web, estudio de los lenguajes de
programación empleados en el desarrollo de la Arquitectura, estudio de la Interfaz entre el
Sistema de Adquisición de Datos y el Servidor Web, y estudio para la instalación y
configuración del Servidor Web.
Por otra parte se hizo el estudio de todos los tópicos referentes al computador industrial
modular con estándar PC/104 – Plus y al Sistema de Adquisición de Datos Net-DAS. Esto
incluye la revisión de los manuales de cada uno de los módulos o tarjetas que conforman al
computador industrial, así como los manuales y documentos desarrollados para la Arquitectura
Net-DAS. De acuerdo a la información recolectada se elaboró el esquema de la Arquitectura
del Sistema, para lo cual se definieron los esquemas de conexión para las redes de
comunicación entre los equipos de campo y el sistema de adquisición de datos. También se
definió la información a mostrar en los despliegues gráficos para la visualización de los datos
en la aplicación Web.
Esta correspondió a la fase inicial del proyecto y se completó aproximadamente en mes
y medio. Para el desarrollo de esta fase se contó con todo el apoyo del personal interno del
Departamento de Automatización Industrial para la disposición del material informativo
constituido por manuales técnicos, documentos de otros proyectos, etc. El acceso a Internet
fue de mucha utilidad para la recopilación de la información. De igual manera la asistencia a
diversos talleres y reuniones relacionadas directa o indirectamente con el tema, contribuyó al
cumplimiento del objetivo primordial de esta fase, el cual corresponde a la obtención de todo
el conocimiento necesario para hacer posible el desarrollo y la implementación del Sistema.
4.2.2.- Segunda Fase: Desarrollo e Implementación del Sistema
En esta fase se configuró las especificaciones de comunicación en el transmisor de
presión, el transmisor de temperatura, y el transmisor de flujo, de acuerdo a los protocolos
utilizados. También se realizó la instalación del computador industrial modular con estándar
59
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
PC/104-Plus, para lo cual se armó la torre que conforman sus cinco módulos. Para el correcto
funcionamiento con el Sistema Net-DAS al computador modular se le hicieron cambios a
nivel del setup de la tarjeta madre. A este computador se le instaló el sistema operativo QNX
4.0 en conjunto con el Sistema Net-DAS. Para la comunicación con los equipos de campo, se
ajustaron unos jumpers del módulo multipuerto de este computador. Igualmente, se requirió
configuración del modulo de red.
Una vez configurados los transmisores y el computador modular, dentro del Sistema
Net-DAS se incluyeron las redes de comunicación con los equipos de campo. En esta fase, de
acuerdo a la definición de las variables de campo hecha en la fase de Ingeniería, se agregaron
los registros de lectura de valores correspondientes a cada dispositivo en las redes de
adquisición de datos. Teniendo los datos direccionados en la tabla de registros del Sistema
Net-DAS, se habilitó la disposición de la misma a la red de procesos de la Corporación a
través de un protocolo amo - esclavo basado en TCP/IP. Para efectos del proyecto se instaló y
configuró el Servidor Web Apache bajo una plataforma Win32. Por lo tanto, todos los
archivos para la extracción de datos de la Net-DAS, creados para correr en este Servidor, se
migraron a esta plataforma. Originalmente fueron desarrollados en el Sistema Operativo
Debian/Linux por un grupo de trabajo conformado por personal contratado e interno.
Después de la adecuación de los programas para la extracción de los datos desde el
Sistema Net-DAS, se programó el módulo de visualización de los datos utilizando lenguajes
comúnmente conocidos para aplicaciones Web. El despliegue gráfico se orientó siguiendo los
esquemas de visualización utilizados por los sistemas actuales de supervisión y monitoreo del
distrito.
Esta fue la fase principal del proyecto con una duración de aproximadamente dos
meses y medio. Inicialmente no se contaba con todos los transmisores de campo, fue en el
transcurso de la misma que se dispuso de todos los equipos para la conformación de las redes
de comunicación. El desarrollo de esta fase se hizo en las instalaciones de las oficinas del
60
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Departamento a manera de laboratorio controlado, para lo cual se contó con el apoyo del
personal para la utilización de espacios y de las herramientas necesarias para armar e instalar
los diferentes equipos e instrumentos. Con esta fase se alcanzó el principal propósito del
proyecto el cual es la implementación de la arquitectura, para luego ser evaluada en la
siguiente fase mediante las pruebas de funcionamiento.
4.2.3.- Tercera Fase: Pruebas
En esta fase se realizaron todas las pruebas necesarias para comprobar el correcto
funcionamiento de las distintas etapas de la Arquitectura. Esta fase abarca las pruebas hechas
localmente en las distintas etapas, y la prueba del funcionamiento completo del Sistema
implementado. Esta fase forma parte del último mes del proyecto y se hizo utilizando las
herramientas que comúnmente se emplearon para la implementación, es decir, no se contó con
ningún equipo adicional especializado para la realización de las mismas. Para la evaluación de
la aplicación final se contó con la ayuda del personal interno del Departamento.
4.3.- Sistema Integrado de Supervisión y Monitoreo
4.3.1.- Generalidades del Sistema
Como Arquitectura Modelo del presente Proyecto se empleó una arquitectura basada
en el Sistema de Medición en Línea de Crudo de la Estación de Flujo SINCO - D, ubicada en
el Estado Barinas. Actualmente, el Sistema de Medición de la Estación de Flujo SINCO – D
no está físicamente instalado, sin embargo, se cuenta con las especificaciones reales y válidas
del sistema que será implementado en dicha estación.
La Arquitectura Modelo al igual que la arquitectura de SINCO-D contempla la
Medición de Flujo de Crudo, del Porcentaje de Corte de Agua contenido en el Crudo, de la
Presión y de la Temperatura en el Oleoducto. Por otra parte emplea, para la recolección de los
datos provenientes de los distintos transmisores, una unidad terminal Net-DAS basada en un
computador industrial modular de estándar PC/104-Plus. (Ver sección 3.5)
61
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
De acuerdo a las Normas Técnicas para la Fiscalización de Hidrocarburos Líquidos
aplicadas por el Ministerio de Energía y Minas, la Arquitectura Modelo no cumple con todos
los requerimientos exigidos para la fiscalización automática de hidrocarburos líquidos
producidos, por lo tanto, la Medición es de tipo Referencial basada en un nuevo sistema de
recolección de datos, distinto al Computador de Flujo exigido para Medición Fiscal en Línea
en la Norma.
Para efectos del Proyecto, esa Arquitectura Modelo recibe el nombre de Arquitectura
del Sistema Automatizado de Medición en Línea (SAMEL), y está conformada
funcionalmente por cuatro módulos que abarcan desde la extracción de los datos en campo,
hasta la visualización de los mismos en una interfaz humano - máquina basada en Web. Estos
módulos son: Captación de Datos en Campo, Comunicación entre Servidor Agente Interfaz y
Computador Net-DAS, Captación de Datos desde el Servidor Web y la Visualización en Web.
En la Figura 4.1 se puede apreciar el conjunto de módulos que conforman a la Arquitectura.
Visualización en Web
Captación de Datos desde el Servidor Web
Comunicación entre Servidor Agente Interfaz y Computador Net-DAS
Captación de Datos en Campo
Figura 4.1.- Módulos de la Arquitectura SAMEL
Equipos de
Campo
Servidor
Agente
Interfaz
Servidor
HTTP
Apache
Cliente Web
Figura 4.2.- Diagrama de Bloques de las Etapas de la Arquitectura SAMEL
62
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
El Sistema está conformado físicamente por cuatro etapas constituidas por: Equipos
de Campo, Servidor Agente Interfaz, Servidor HTTP Apache y Cliente Web. En la Figura 4.2
se muestra un diagrama de bloques que simplifica la interacción de las distintas etapas que
conforman a la Arquitectura del Sistema. Como se puede apreciar en la Figura 4.2 existe
comunicación bidireccional entre cada unas de las etapas contiguas del Sistema. Para
visualizar los datos de campo en explorador Web es necesario que se llame la dirección URL
correspondiente para que el Servidor Web interprete y responda a todas las peticiones de
ejecución de aplicaciones. Desde este servidor se hace la solicitud de datos al Servidor Agente
Interfaz, quién a su vez se comunica con la etapa de Recolección de Datos para extraer la
información suministrada por los dispositivos de campo. En la Figura 4.3 se muestra un
diagrama físico de la Arquitectura, en la cual se detalla los equipos e instrumentos que
conforman a cada una de las etapas.
El computador industrial PC/104-Plus que cumple con las funciones de adquisición de
datos a través del Sistema Net-DAS, periódicamente consulta los datos de campo a los
distintos transmisores que conforman la Arquitectura. Se comunica con el transmisor de
presión y de temperatura mediante el protocolo Hart y con el transmisor de flujo por el
protocolo Modbus RTU.
Cuando el cliente Web de visualización de PDVSA hace una consulta de los datos de
campo, escribiendo la URL asociada a la aplicación en el explorador o navegador Web
convencional, el Servidor Web recibe la petición a través del protocolo HTTP e interpreta y
ejecuta el código de los archivos que se encuentran en los directorios de la aplicación. Entre
los archivos que se ejecutan corre un cliente XML - RPC para solicitar los datos al Servidor
Agente Interfaz. Este Servidor se comunica inmediatamente al recibir la petición de los datos,
con el computador Net-DAS vía el protocolo Modbus TCP. A partir de ahí los datos empiezan
a subir por los medios correspondientes, hasta que a través de unos campos de texto son
mostrados en el despliegue gráfico en el navegador. El tiempo de respuesta es similar al
tiempo que tarda en cargar una página Web convencional dentro de la red de PDVSA.
63
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
ARQUITECTURA DEL SISTEMA AUTOMATIZADO DE MEDICIÓN
EN LÍNEA (Modelo de Medición E.F. SINCO – D, Medición de Referencia )
Servidor HTTP Apache
Red de Datos de PDVSA
Servidor Agente Interfaz
• Despliegue Dinámico (Perl)
Servidor Modbus –
XML/RPC
(Lenguaje C )
XML/RPC
(HTTP)
Clientes WEB de
Visualización PDVSA
•Presentación (PHP + HTML
+ JavaScript)
Navegador Web
HTTP
Modbus TCP
Conexiones Ethernet
10/100/1000 MBPS
LAN/WAN
Recolecció
Recolección de Datos
Interfaz
RS232
Viator
Net-DAS
Conversor
RS-485 a RS-232
B&B Electronics
Modelo 485LDRC9
Hart Bell
202
Modbus/RTU
RS485
Modbus/RTU
RS485 2 hilos
Transmisor
de Presión
Rosemount
3051TG
*
Transmisor
de Flujo
Micromotion
RFT9739
Sensor de
Flujo
Micromotion
CMF400
*
Medidor de
Corte de
Agua Agar
OW-202
Transmisor
de Temp.
Rosemount
3144P
Modbus RTU a 9600 bps, 8 bits de Datos, Sin paridad, 1 bit parada,
Figura 4.4.- Arquitectura del Sistema Automatizado de Medición en Línea
64
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Cliente Web
6
1
Servidor
HTTP Apache
5
2
Servidor Agente
Interfaz
3
Equipos de
Campo
4
Figura 4.4.- Diagrama de Flujo entre las Etapas de la Arquitectura SAMEL
Mientras la página de despliegue esté abierta, periódicamente se establece la cadena
de comunicación hasta el nivel más bajo para mantener actualizados los datos, tal como se
muestra en el diagrama de flujo de la Figura 4.4. De lo contrario, mientras la página no sea
consultada no existe comunicación entre las distintas partes, a excepción de los lazos de
comunicación Hart y Modbus RTU entre el computador industrial Net-DAS y los
instrumentos de campo. En las siguientes secciones se hará una descripción detallada del
desarrollo y la implementación de cada módulo que conforma a la Arquitectura SAMEL.
4.3.2.- Módulo de Captación de Datos en Campo
La captación de datos empleada para la Arquitectura SAMEL esta compuesta por los
siguientes instrumentos: un Transmisor de Flujo Micromotion RFT9739 (con su sensor
Micromotion CM F400), un Transmisor de Temperatura Rosemount 3144P (con su sensor
Rosemount NEMA 4), un Transmisor de Presión Rosemount 3051TG (sensor del mismo
fabricante) y un Medidor de Corte de Agua Agar OW-202 (Ver Figura 4.3). Sin embargo,
para efectos del Proyecto no se pudo contar con todos los instrumentos antes nombrados. El
sensor de flujo Micromotion CM F400 por sus dimensiones era imposible utilizarlo para el
montaje, además no tiene sentido utilizar el sensor si éste no está conectado a una tubería
donde haya volumen de líquido en circulación, que en el caso de la Arquitectura sería flujo
de crudo por un oleoducto. Por lo tanto, los datos registrados por el transmisor de flujo no
son válidos y únicamente se utilizó para pruebas de comunicación. Por otra parte, no se
dispuso del medidor de corte de agua Agar OW-202 el cual, para efectos del montaje, no hizo
65
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
falta ya que con el resto de los datos recogidos era suficiente para la puesta en práctica y
prueba de la Arquitectura SAMEL.
Este módulo utiliza como unidad de recolección de datos un computador industrial
modular de estándar PC/104-Plus que tiene instalado el Sistema Net-DAS. Este computador
embebido se encarga de hacer la consulta de los datos a los distintos transmisores y de
disponer los datos en la red debido a la capacidad de manejo del protocolo de comunicación
Modbus TCP. Para establecer la comunicación de los transmisores con el computador NetDAS se utilizó un Conversor RS-485/422 a RS-232 de B&B Electronics Modelo 485LDRC9
para la conexión vía Modbus, y un modem Viator de MACTEK como una interfaz RS-232
para los dispositivos conectados en la red Hart. A continuación se hará una descripción de los
lazos de comunicación establecidos, y la instalación y configuración de cada uno de los
equipos utilizados.
4.3.2.1.- Lazos de Comunicación
Los transmisores están conectados al computador Net-DAS a través de dos redes
basadas en protocolos de comunicación diferentes: Modbus RTU y HART BELL 202. (Ver
sección 3.4, Protocolos de Comunicación).
Red HART BELL 202
El lazo Hart esta conformado por una fuente de poder DC de 24 V, una resistencia de
carga RL de 250 ohmios de ¼ Vatios, un transmisor de temperatura Rosemount 3144P y un
transmisor de presión Rosemount 3051TG (ver especificaciones técnicas de ambos
transmisores en Apéndice F). En la Figura 4.5 se muestra el esquema de conexión.
Esta configuración es conocida como Conexión Multipunto ya que más de un
dispositivo Hart está conectado en la misma red. La Interfaz RS - 232 o modem Hart se debe
conectar en paralelo al lazo, ya sea entre los extremos de los transmisores o en los extremos
de la resistencia de carga RL. Esta interfaz es utilizada para poder conectar estos equipos a
un puerto de comunicación serial RS - 232 común del computador Net-DAS. Para mayor
información sobre el protocolo de comunicación Hart, ver la sección 3.4.
66
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
+ 24 V
Transmisor de
Temperatura
Rosemount
3144P
+
-
Transmisor de
Presión
Rosemount
3051TG
+
-
Fuente de Poder
de 24 VDC
Interfaz RS-232
Viator de MACTEK
RL
250 Ω
0V
Figura 4.5.- Lazo HART de la Arquitectura SAMEL
La ventaja que ofrece este tipo de conexión es que ambos transmisores serán
consultados a través del mismo puerto, ya que cada dispositivo tiene una dirección Hart única
en esa red. La asignación de la dirección Hart se hace directamente en el transmisor,
utilizando diferentes herramientas: Una, empleando un programa de configuración como el
AMS propietario de la misma casa fabricante (Emerson Process Management) de los
transmisores Rosemount. Este programa se ejecuta desde un computador común con puerto
de comunicación serial RS-232 (para ello es necesario el modem Hart). Otra opción, es
utilizando un Comunicador de Campo como el 375 Field Communicator fabricado por la
misma compañía anteriormente nombrada en este párrafo. En este caso, no se requiere el
modem Hart, el Comunicador se conecta directamente en paralelo al lazo Hart. Esta
herramienta de campo para configuración es comúnmente conocida en el ámbito industrial
como HandHeld Hart Communicator. Ambos transmisores fueron configurados utilizando el
HandHeld de Campo.
El transmisor de Temperatura tiene asignado una dirección Hart igual a “1”, un ID de
Manufacturador (Código MFR) igual a “9753”, y un ID de Dispositivo igual a “1442780”.
El transmisor de Presión tiene la dirección Hart “2”, con un Código MFR igual a “9734” y un
ID de Dispositivo igual a “7429882”. Por lo tanto, si se quiere hacer una petición del valor de
temperatura es necesario leer el contenido de ciertos registros del transmisor de temperatura a
través de la dirección “1” en la red Hart. Análogamente para el caso de presión. El detalle de
los registros, y la manera como se debe hacer para extraer la información, se explica más
adelante en la sección de Captación de Datos con Net-DAS. El computador Net-DAS actúa
67
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
como un dispositivo amo dentro de la red Hart, ya que es quién genera las peticiones y espera
por las respuestas de los distintos esclavos, en este caso los dos transmisores.
Red Modbus RTU
El transmisor de flujo Micromotion RFT9739 se comunica con el Computador NetDAS a través del protocolo Modbus RTU. El transmisor de flujo tiene para Modbus una
interfaz RS-485 de dos hilos, y debido a que los puertos de comunicación serial del
Computador Net-DAS se estandarizaron a una interfaz RS-232, es necesario utilizar un
conversor RS-485/422 a RS-232 entre el transmisor y el puerto COMM17. El conversor
utilizado es fabricado por B&B Electronics como el modelo 485LDRC9. En la Figura 4.6 se
muestra el esquema de conexión. Ver especificaciones técnicas del transmisor de flujo en el
Apéndice F.
Transmisor de
Flujo
Micromotion
RFT9739
Computador PC/104Plus
Arquitectura Net-DAS
TDB
26
27
RDA
Conversor
RS-485/422 a RS-232
B&B Electrionics
Modelo 485LDRC9
Figura 4.6.- Esquema de Conexión Modbus de la Arquitectura SAMEL
El Transmisor de Flujo utiliza los pines 26 y 27 para la interfaz RS-485. El pin 26 se
conecta con el terminal TDB del Conversor, y el 27 con el terminal RDA, tal como se
muestra en la Figura 4.6. Cuando el Conversor se configura a través de suiches en modo de
interfaz RS-485 de dos hilos, los terminales TDB y RDB están internamente cortocircuitados,
igualmente sucede para los terminales TDA y RDA. Dejan de ser igual cuando la
configuración es RS-485 de 4 hilos. La conexión entre el Conversor y el Computador NetDAS se hace a través de un cable uno-a-uno convencional DB-9.
17
Nombre con el se conoce el puerto de comunicación serial en un computador.
68
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
La comunicación Modbus RTU funciona bajo el principio amo/esclavo. En este caso,
el amo es el Computador PC/104-Plus y el esclavo es el Transmisor de Flujo, el cual tiene
asignada una dirección de dispositivo igual a “1”. Por lo tanto, para hacer una petición desde
el amo al transmisor hay que referenciar a esa dirección. Las especificaciones técnicas de la
comunicación Modbus RTU utilizadas en el Proyecto, se encuentran en la Tabla 4.1.
Tabla 4.1.- Especificaciones de la Comunicación Modbus RTU empleada.
Tasa de Baudios
9600 bps
Bits de Datos
8
Paridad
Sin paridad
Bits de Parada
1
DTR
No
RTS
No
Para establecer la comunicación entre el amo y el esclavo es necesario, en este caso,
que ambos tengan configurando Modbus RTU con las especificaciones descritas en la Tabla
4.1 (el Conversor debe trabajar a la misma tasa de baudios). En el transmisor de flujo
RFT9739 esta configuración se hace directamente en el equipo a través de un juego de 10
suiches y un botón con etiqueta Zero, utilizado para el grabado de la configuración. Eso en el
caso que se quiera un modo definido por el usuario. Existe una opción de comunicación
estándar, para lo cual no es necesario establecer ninguna configuración. En el modo estándar
el Modbus RTU maneja una tasa de bits 9600 bps, 8 bits de datos, paridad par, y 1 bit de
parada. La descripción exacta de cómo configurar las especificaciones de comunicación a
través del juego de suiches, se encuentra en la hoja de especificaciones del equipo en el
Apéndice F. Adicionalmente existe otra manera, a través del panel frontal del transmisor para
lo cual se utilizan dos perillas giratorias identificadas con Scroll y Zero. Para entrar en este
modo es necesario girar simultáneamente ambas perillas.
69
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Para la configuración del funcionamiento del transmisor de flujo se utilizó el
programa Prolink II v2.0 propietario de la casa fabricante Emerson Process Management. La
comunicación con el equipo desde este programa se puede hacer vía Hart o Modbus. Para
comunicarlo vía Hart es necesario: Primero, colocar una resistencia entre 250 - 1000 Ω entre
los terminales 17 y 18 mostrados en la Figura 4.7. Segundo, conectar una interfaz RS-232
para redes Hart en los extremos de la resistencia o en los pines indicados como HART en la
Figura 4.7. Tercero, conectar el otro extremo del modem Hart en un puerto COMM del
computador personal donde esté instalado el programa Prolink. Y por último dentro de la
aplicación hay que seleccionar el protocolo HART BELL 202.
Figura 4.7.- Terminales del Transmisor de Flujo RFT9739
En caso que la configuración de funcionamiento del equipo se desee hacer vía
Modbus, se debe implementar el esquema mostrado en la Figura 4.6, con la diferencia que el
amo en este caso es el computador personal con el programa Prolink en vez del computador
Net-DAS. En el programa hay que seleccionar el protocolo Modbus RTU, y luego indicar las
especificaciones de comunicación del equipo.
Una vez establecida la conexión ya sea con Hart o con Modbus, el programa permite
entre algunas cosas: ver el valor actual de las variables de proceso, cambiar las direcciones
Hart y Modbus18 del dispositivo, configurar ciertos parámetros por cada una de las variables
de proceso, seleccionar el sensor, ver registro de alarmas, entre otras cosas. (Ver Figura 4.8)
18
La dirección Modbus sólo se puede cambiar si la comunicación con el transmisor de flujo se hace utilizando el protocolo
Modbus RTU.
70
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Figura 4.8.- Pantalla de Configuración en el Prolink
4.3.2.2.- Captación de Datos con Net-DAS
Esta sección contiene una descripción q abarca desde la instalación del Sistema NetDAS, hasta la configuración de los módulos de comunicación con las redes Hart y Modbus.
Instalación del Sistema Net-DAS
Como paso inicial se armó, con el cuidado que amerita, la torre de los cinco módulos
que conforman el computador industrial modular con estándar PC/104-Plus. Simplemente se
fue uniendo un módulo con otro a través del conector de 104 pines siguiendo un orden
específico. Luego se procedió a instalar la memoria RAM, el Compact Flash, y los cables
necesarios (cables de salida de monitor y de teclado, cable IDE para el módulo Compact
Flash, dos cables planos con terminación en DB-9 de los ocho puertos adicionales del
módulo Xtreme/104).
Una vez armado el computador modular se instaló el teclado y el monitor. Luego se le
suministró energía al computador utilizando un adaptador DC con una salida de 13,8 VDC @
1,5 A max. Las especificaciones del rango de voltaje DC requerido por el modulo de fuente
de poder del computador modular se encuentra en la sección 3.6 del Capítulo de Marco
Teórico. Al arrancar por primera vez el computador se hicieron algunos cambios en el
71
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
SETUP de la tarjeta madre. Cambios requeridos para el correcto funcionamiento del Sistema
Net-DAS. Los detalles de la configuración del setup se encuentran en el Apéndice C. La
instalación del Sistema Operativo QNX versión 4.0 + Arquitectura Net-DAS se hizo
utilizando unos discos de 31/2 ‘’ suministrados por los creadores de esa Arquitectura (Intevep,
S.A.). Durante la instalación se van seleccionando algunas opciones como: tipo de
dispositivo de almacenamiento (en este caso es Compact Flash), tipo de tarjeta de red, si el
acceso al sistema operativo es local (teclado, monitor) o si el acceso es remoto (vía telnet por
el COMM1 de la tarjeta madre), configuración de red (ip, máscara de red, etc.), entre otros.
Administración del Sistema Net-DAS
El Sistema Net-DAS instalado en el computador modular tiene una herramienta de
Administración Web, gracias al Servidor Web Apache que tiene corriendo internamente tal
sistema. Este servidor ofrece entre sus ventajas: el manejo de páginas Web estándares hechas
en HTML, interpretación del lenguaje PHP, ejecución de Applets de Java, entre otras. Es
recomendable aclarar que este servidor interno no tiene relación alguna con el Servidor Web
contemplado en la Arquitectura SAMEL. Para acceder a la Administración Web de la NetDAS, basta con incluir en un navegador convencional la dirección URL: http://<ip-asignadoa-la-Net-DAS>/, y aparecerá una pantalla de entrada como la que se muestra en la Figura 4.9.
Para el caso particular de la Net-DAS utilizada para el Proyecto, que tiene una dirección
162.122.233.14, se incluye la dirección URL: http://162.122.233.14/. Como se aprecia en la
Figura 4.9, las opciones disponibles del menú de entrada son:
Figura 4.9.- Pantalla de Inicio de la Administración Web para Net-DAS
Configuración
72
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Permite la Configuración de Amos (la Net-DAS como amo), la Configuración de
Esclavos (la Net-DAS como esclavo) y la Configuración TCP/IP de la Net-DAS. Estas
opciones se encuentran en el Applet19 de Java que se ejecuta en el despliegue que aparece al
entrar en esta sección de Configuración. Al entrar en esta sección por primera vez, el Applet
se ejecuta igual al mostrado en la Figura 4.10.
Figura 4.10.- Applet de Java/Configuración de Amos
Como se aprecia en la Figura 4.10, en la Configuración de Amos inicialmente no hay
ningún protocolo/puerto asignado, mostrando la opción de agregar algún puerto o canal. En
cambio si se llama por primera vez la pestaña de Configuración de Esclavos, aparece un
canal de Esclavo Modbus TCP (slave_modTCP), lo cual indica que por defecto la Net-DAS
esta preconfigurada como un esclavo Modbus TCP por el puerto 502 y con dirección “1” (ver
Figura 4.12), para el acceso a la tabla de registros Modbus que contiene internamente. En el
Applet se visualiza este canal, tal como se muestra en la Figura 4.11. Por último en la
pestaña de Configuración de TCP/IP en el Applet, se configuran todos los parámetros
relacionados con la red a la cual la Net-DAS está conectada.
19
Para correr el Applet de Java es necesario que el computador, donde se esté ejecutando el navegador Web, tenga
instalado Virtual Machine de Java.
73
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Figura 4.11.- Applet de Java/Configuración de Esclavos
Figura 4.12.- Despliegue Completo/Configuración de Esclavos
74
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Figura 4.13.- Despliegue Completo/Configuración TCP/IP
También se puede configurar un servidor DHCP (siglas de Dynamic Host
Configuration Protocol), el nombre del Dominio, la dirección IP, el nombre en red (host
name) de la Net-DAS, la máscara de red, la puerta de enlace predeterminada (Gateway), y el
servidor DNS (siglas de Domain Name Server).
Aplicación Telnet
Ejecuta una aplicación telnet internamente en el navegador Web, para entrar al
directorio del sistema operativo, emulando como si se entrará directamente en el computador
modular por terminal con monitor y teclado. Tal como se muestra en la Figura 4.14.
Registros Modbus
Permite visualizar el contenido de los registros de la tabla Modbus interna del NetDAS. Esta tabla es servida a través del protocolo de comunicación Modbus TCP cuando la
Net-DAS está actuando como esclava. Un ejemplo de la visualización de un grupo de
registros se muestra en la Figura 4.15.
75
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Figura 4.14.- Aplicación Telnet en el Navegador Web
Figura 4.15.- Visualización del Contenido de los Registros
76
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Estatus COMMs
Permite visualizar las estadísticas de comunicación de los distintos puertos de
comunicación serial del computador modular. Es necesario aclarar que los puertos de
comunicación serial (de propósito general) del computador comienzan desde el COMM3
hasta el COMM12 (que son los ocho puertos del módulo Xtreme/104). El COMM1 y el
COMM2 físicamente están ubicados en la tarjeta madre y tienen un uso especial en el
Sistema Net-DAS. En la Figura 4.16 se muestra la página resultante al entrar a esta sección
Estatus COMMs.
Figura 4.16.- Estadísticas de Comunicación de los Puertos del Computador Modular
Detección HART
A través de este módulo se puede detectar si, por un puerto en específico, está
conectado algún dispositivo HART. Al entrar en esta sección se selecciona el puerto y se
envía la consulta. En la Figura 4.17 se muestra la pantalla inicial de Detección HART.
77
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Configuración de Amos
Esta es la sección más importante en la Captación de Datos con Net-DAS, ya que es
donde se describe la configuración de la Net-DAS para la comunicación y extracción de
información de las redes Hart y Modbus establecidas con los distintos transmisores. La
comunicación con el Net-DAS se establece a través de los puertos de comunicación serial
(COMM) con interfaz RS-232 y conectores DB-9. Los puertos COMMs disponibles van
desde el COMM3 (llamado /dev/ser3 en el computador Net-DAS) hasta el COMM10
(conocido como /dev/ser10 en Net-DAS). Los puertos COMM1 y COMM2 están reservados
para administración de la Net-DAS.
Figura 4.17.- Pantalla de Selección de Puerto para la Detección de Dispositivos Hart
Para el Lazo Hart
Para incluir la Net-DAS dentro del Lazo Hart descrito en la sección 4.3.2.1.1, se
agregó un Amo Hart en la Configuración de los Amos en el Applet que se ejecuta en la
Página de Configuración dentro de la Administración de Net-DAS. Este Amo Hart se
configuró por el puerto /dev/ser4 (COMM4) del computador, puerto en el cual está conectado
el modem Hart RS-232. Una vez agregado el Amo Hart, se configuraron las dos estaciones o
esclavos correspondientes a los dos transmisores Hart conectados en el Lazo. Utilizando los
78
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
datos asignados a cada transmisor (ver sección 4.3.2.1.1), se agregaron las dos estaciones
como se muestra en el Applet en la Figura 4.18.
Figura 4.18.- Estaciones del Amo Hart
La estación con IP = 9734 (realmente, equivale al Código MFR del Dispositivo), y
Addr = 7429882 (equivale al ID de Dispositivo), representa el transmisor de Presión
Rosemount 3051TG. Mientras, que la otra estación, con IP = 9753 y Addr = 1442780 es el
transmisor de Temperatura Rosemount 3144P. Como parámetros adicionales para agregar
una estación, hay que definir el tiempo máximo de espera de respuesta de dispositivo
(Timeout), definir el número de reintentos en caso de falla comunicación (Retries), y
habilitar el escaneo (SCAN = Yes) al dispositivo para actualizar continuamente los datos de
los registros con la información de las variables de proceso.
Ambos transmisores contienen la información de Campo en los primeros siete
registros a partir de la dirección 30001. El primer registro contiene la salida de corriente de 0
a 4mA en un entero de 16 bits con signo. El segundo registro representa el Estatus de
Comunicación y genera un valor de -1 cuando hay error de comunicación. El tercer y cuarto
registro, están ocupados por la Salida de Corriente en formato float (32 bits). Los registros
30005 y 30006 contienen la Variable de Proceso en formato float. El último registro se utiliza
79
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
para la unidad de la Variable de Proceso. En la Tabla 4.2 se aprecia tal distribución de los
registros.
Tabla 4.2.- Registros de los Transmisores de Presión y Temperatura
Salida de Corriente; 0 a 4mA).
30001
Estatus (-1 Err de Comm)
30002
30003
Salida de Corriente (Float)
30004
30005
Variable de Proceso (Float)
30006
30007 Unidad de la Variable de Proceso
Para tener los datos de campo a la disposición de la tabla Modbus interna de la NetDAS, la cual puede ser consultada desde un amo a través del protocolo de comunicación
Modbus TCP, se tiene que asociar cada registro del transmisor a un registro de la tabla
Modbus de la Net-DAS. Para ello se cuenta con una tabla elaborada internamente en el
Departamento de Automatización, que generaliza y estandariza la organización y disposición
de los registros Modbus de la Net-DAS (ver Tabla 4.3). Sin embargo, no es posible que
ocurra algún conflicto de datos por duplicar direcciones ya que el Sistema Net-DAS es capaz
de identificar si algún registro ya ha sido asignado. En la Tabla 4.3 se muestra la distribución
general de los registros de los transmisores de Presión, Temperatura, y Flujo Másico. Para un
mejor entendimiento de las tablas y las asignaciones de los registros es recomendable, revisar
el marco teórico referente a los registros Modbus en la sección 3.4.2.4 del capítulo 3.
Tabla 4.3.- Distribución de los Registros de Entrada en la Tabla Modbus Interna de la Net-DAS
Registros de Entrada
Instrumentos/Equipos
Cantidad
Máxima
I/O Ethernet / Analógico
I/O Ethernet / Discreto
6
6
Numero De
Registros Por
Unidad
16
16
Transmisor de Flujo Másico
5
18
Transmisores de Presión
Transmisores de Temperatura
Controladores BES Vortex
Discretas
Controladores BES Vortex
Analog.
30
30
8
8
20
16
20
Controladores BES CTI 1800
Discretas
Controladores BES CTI 1800
Analog.
Actuadotes Eléctricos Limitorque
Actuadotes Eléctricos Auma
Numero
Total De
Registros
96
56
Dirección
Inicial
Dirección
Final
30001
10001
30096
10056
90
30401
30490
240
240
31001
31501
31240
31740
320
11001
11320
18
360
32001
32360
20
96
1920
12001
13920
20
52
1040
33001
34040
80
80
5
9
400
720
35001
36001
35400
36720
80
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Como se aprecia en la Tabla 4.3, se reservan 240 registros para los Transmisores de
Presión a partir de la dirección 31001 en la tabla Modbus interna de la Net-DAS. Por
estandarización se estima que un proyecto de gran magnitud como máximo utilizaría 30
transmisores de presión conectados a la misma Net-DAS, reservando 8 registros por cada
transmisor (por lo general estos transmisores utilizan sólo 7 registros, pero por holgura se
asignó un registro más). Utilizando la distribución de la Tabla 4.3, al Transmisor de Presión
Rosemount 3051TG le corresponde la dirección de inicio 31001 y una dirección final 31007.
Para el Transmisor de Temperatura Rosemount 3144P el rango de registros comprendido
entre 31501 y 31507. Para el Transmisor de Flujo RFT9739 se reservan 18 registros a partir
de la dirección 30401. Todos estos registros son asociados en la Tabla 4.3 como Registros de
Entrada (Input Registers - IREG).
Para incluir los registros del Transmisor de Presión dentro del Sistema, hay que
agregar en el Applet de Configuración del Amo Hart en la estación asociada a éste
transmisor, un Poll Record especificando las direcciones correspondientes. Se quiere el rango
30001 - 30007 del transmisor a partir del IREG 31001 de le Net-DAS, por lo tanto, en las
especificaciones del Poll Record hay que colocar el tipo de registro IREG, sin offset (valor
0), con una cuenta de 7 registros mapeados a la dirección 1001, y con un tiempo de
refrescamiento de 4 (internamente, x 250 milisegundos). El mapeo se hace a la dirección
1001 ya que al indicar el tipo de registro IREG se asocia que es 31001. El esquema en el
Applet resulta tal como se muestra en la Figura 4.19.
Figura 4.19.- Asignación de Registros en la Estación asociada al Transmisor de Presión
81
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Por otra parte el sistema Net-DAS permite supervisar el estatus de comunicación de
los distintos dispositivos conectados a través de sus puertos, indicando entre algunos detalles,
el número de preguntas hechas al dispositivo y el número de respuestas válidas que se obtuvo
de él. Para el estatus de comunicación del Transmisor de Presión el cual esta conectado como
una estación del Amo Hart a través del puerto /dev/ser4, se agrega un bloque de 7 registros a
partir de una de dirección especificada en la Tabla 4.4.
Tabla 4.4.- Distribución de los Registros de Estatus de Comunicación
Instrumentos/Equipos
Cantidad
Máxima
Registros Por
Unidad
Numero Total De
Registros
Dirección
Inicial
Dirección
Final
I/O Ethernet / Analógico
6
7
42
42001
42042
Transmisor de Flujo Másico
5
7
35
42043
42077
Válvulas Multipuerto Bettis
2
7
14
42078
42091
Válvulas Multipuerto Equipetrol
2
7
14
42092
42105
Transmisores de Presión
30
7
210
42106
42315
Transmisores de Temperatura
30
7
210
42316
42525
Controladores BES Vortex Analog.
20
7
140
42526
42665
Controladores BES CTI 1800 Analog.
20
7
140
42666
42805
Actuadores Eléctricos Limitorque
80
7
560
42806
43365
Actuadores Eléctricos Auma
80
7
560
43366
43925
Las direcciones mostradas en la Tabla 4.4 se refieren a los registros destinos del Poll
Record. Los datos del estatus los devuelve la misma Net-DAS en las direcciones desde la
48193 hasta la 48199. De acuerdo a la estación en que se agregue el estatus, la lectura de los
registros 48193 - 48199 devuelve valores únicos para esa estación, es decir, que para otros
dispositivos se utilizarán los mismos registros 48193 – 48199, pero los números de preguntas
y respuestas válidas serán diferentes. Por lo tanto, para el caso del estatus de comunicación
del transmisor de presión hay que mapear a partir de la dirección 42106, leyendo los siete
registros desde la dirección 48193. El Poll Record en la estación es igual a HREG 48193 –
48199 @ 42106. Análogamente, se agregan los registros para el Transmisor de Temperatura.
En este caso, los Poll Records son igual a IREG 30001-30007@31501 y HREG 48193 –
48199 @ 42316. Con este paso culminado, queda completada la configuración de la red Hart
entre el computador Net-DAS y los transmisores.
82
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Para la Red Modbus
En este caso se agregó un Amo Modbus por el puerto /dev/ser3 (COMM3) con las
características de comunicación serial descritas en la Tabla 4.1. En este puerto está conectada
la salida del Conversor RS 485 / RS-232 de la Red Modbus.
Como el único dispositivo esclavo conectado en esta red es el Transmisor de Flujo,
solo se incluyó una estación dentro del Amo Modbus. Esta estación tiene una dirección de
dispositivo igual a “1”, un tiempo máximo de espera de respuesta de dispositivo igual a 1
seg (Timeout) y el número de reintentos en caso de falla comunicación (Retries) igual a “2”.
Como se aprecia en la Tabla 4.3¸ se tienen reservados 18 registros para el transmisor
de flujo a partir de la dirección 30401 en la tabla Modbus de la Net-DAS. Sin embargo, para
efectos del Proyecto solo se utilizan 8 registros los cuales representan las variables de
proceso del transmisor. En la Tabla 4.5 se puede observar el contenido de estos registros con
sus direcciones correspondientes en la tabla Modbus del transmisor.
Tabla 4.5.- Registros de las Variables de Proceso del Transmisor de Flujo
30004
Temperatura
30002
Rata de Flujo másico
30005 Rata de flujo volumétrico
30008
Masa total
30003
Densidad
30010
Inventario de masas
30009
Volumen total
30011
Inventario de volumen
La asignación de cada registro en la tabla Modbus de la Net-DAS se hizo agregando
en la estación del Amo Modbus un Poll Record por cada registro (ocho en total), y un Poll
Record de estatus de comunicación del dispositivo definido de acuerdo a la Tabla 4.4. En la
Figura 4.20 se puede apreciar cada registro con su respectiva ubicación. Una vez definidas
las direcciones de los registros del transmisor de flujo en la Net-DAS, queda complemente
configurada la red Modbus.
83
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Figura 4.20.- Asignación de Registros en la Estación asociada al Transmisor de Flujo
4.3.3.- Módulo de Comunicación entre Servidor Agente Interfaz y Computador NetDAS
El Servidor Agente Interfaz es un programa desarrollado en lenguaje C bajo el
sistema operativo Debian/Linux, que tiene como función extraer la información vía Modbus
TCP (puerto 502) de la tabla de registros de la Net-DAS, tal como se muestra en la Figura 4.3
que se encuentra al comienzo de este capítulo. Información sobre el protocolo de
comunicación Modbus TCP se encuentra en la sección 3.4.2.3.
Este Servidor se comunica a campo (Net-DAS) a través del protocolo Modbus TCP
por el puerto 502, y dispone los datos al Servidor Web a través del protocolo XML - RPC
utilizando HTTP a través del puerto 8080. Actualmente el Servidor Agente Interfaz tiene una
dirección IP 162.122.233.231, y esta corriendo en un equipo eServer de la serie 346 de IBM,
bajo el sistema operativo Debian/Linux. Es un programa creado por un grupo de trabajo
conformado por personal interno y personal contratado, bajo la filosofía de Software
Libre/Código Abierto. Como parte de sus objetivos les corresponde implementar todas las
aplicaciones necesarias para extraer los datos de la Net-DAS y disponerlos al modulo de
Visualización en Web.
84
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
El Servidor Agente Interfaz puede obtener información de un gran número de
computadores Net-DAS, lo cuales son conocidos como nodos dentro del programa de
configuración de este servidor. Para agregar un nodo o computador Net-DAS hay que indicar
su dirección IP para que el servidor pueda establecer la comunicación. A cada nodo es
necesario configurarle los TAGs. El principio de los TAGs se basa en asignarle una etiqueta
(TAG) a cada valor que se desee consultar en la tabla Modbus de la Net-DAS. Un valor
puede ser la información de un solo registro de la tabla cuando es de 16 bits o de dos
registros en caso que sea de 32 bits. Los TAGs deben tener un formato estándar ajustados a
unas Normas Básicas de la Nomenclatura para los Datos y Señales, emitidas por la Sección
de Ingeniería y Proyectos de la Superintendencia de Automatización.
Dentro de la configuración se indica el nombre del TAG, la dirección inicial en la
tabla Modbus, el tipo de dato (entero de 16 bits con/sin signo, flotante, etc.), el rango de
valores y las unidades en caso que aplique. En la Tabla 4.6 se muestra el grupo de TAGs
incluidos en el Servidor Agente Interfaz utilizando su programa de configuración. Los TAGs
definidos corresponden a algunos valores de todos los incluidos en la tabla Modbus de la
NetDAS.
El Servidor Agente Interfaz además de enviar los valores asociados a ciertos
registros, tiene la capacidad de generar diferentes estados, que permiten indicar si el dato
solicitado no existe, si esta fuera del rango, si es una señal de alarma, si es de acceso
prohibido, si tiene estado normal, entre otras, de manera que del lado del Servidor Web, sean
interpretados como colores e indicadores para darle a conocer al usuario final el estatus del
dato mostrado.
4.3.4.- Módulo de Captación de Datos desde el Servidor Web
El Servidor Web utilizado es un servidor de distribución libre y muy reconocido a
nivel mundial conocido como Apache. Se instaló la versión 2.0.50 para plataformas Win32
(Windows), con un modulo adicional de Perl (mod_perl/1.99) y un modulo de PHP versión
4.3.7. Este servidor esta corriendo en un computador personal Pentium III bajo el sistema
operativo Windows XP. Para información sobre Apache, Perl y PHP dirigirse al capítulo 3.
85
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Tabla 4.6.- Detalle de Mapeo de Memoria de la Net-DAS
Dirección Modbus En La NetDas
Descripción
TAG
Instrumento / Equipo
30401
Temperatura
EF_SIN_FTT_7162200
Transmisor de Flujo Másico
30402
Rata de Flujo másico
30403
Rata de flujo volumétrico
30404
Masa total
30405
Densidad
30406
Inventario de masas
30407
30408
31001
31002
31003
31004
31005
31006
31007
Transmisor de Flujo Másico
EF_SIN_FTFV_7162200 Transmisor de Flujo Másico
Transmisor de Flujo Másico
EF_SIN_FTD_7162200
Transmisor de Flujo Másico
Volumen total
EF_SIN_FTV_7162200
Transmisor de Flujo Másico
Inventario de volumen
EF_SIN_FTVI_7162200
Transmisor de Flujo Másico
Transmisor de Flujo Másico
Salida de Corriente (-32768 a 32767; 0 a
4mA).
Status (-1 Err de Comm)
Presión
Presión
Presión
Salida de Corriente (Float)
Variable de Proceso (Float)
Presión
EF_SIN_PT_9734
Unidades de la Variable de Proceso
31502
31503
31504
31505
31506
31507
Presión
Presión
31008
31501
Presión
Presión
Salida de Corriente (-32768 a 32767; 0 a
4mA).
Status (-1 Err de Comm)
Temperatura
Temperatura
Salida de Corriente (Float)
Variable de Proceso (Float)
EF_SIN_TT_9753
Unidades de la Variable de Proceso
Temperatura
Temperatura
31508
Temperatura
42043
Errores de CRC
Transmisor de Flujo Másico
42044
# de Preguntas
EF_SIN_FTAP_7162200 Transmisor de Flujo Másico
42045
# Resp. Inválidas
Transmisor de Flujo Másico
42046
# No Respuestas
Transmisor de Flujo Másico
42047
# Timet-outs
42048
# Resp. Válidas
Transmisor de Flujo Másico
EF_SIN_FTAR_7162200 Transmisor de Flujo Másico
42049
# Reintentos
Transmisor de Flujo Másico
42106
Errores de CRC
Presión
42107
# de Preguntas
42108
# Resp. Inválidas
EF_SIN_PTAP_9734
Presión
Presión
42109
# No Respuestas
Presión
42110
# Timet-outs
42111
# Resp. Válidas
Presión
EF_SIN_PTAR_9734
Presión
42112
# Reintentos
Presión
42316
Errores de CRC
Temperatura
42317
# de Preguntas
42318
# Resp. Inválidas
EF_SIN_TTAP_9753
Temperatura
Temperatura
42319
# No Respuestas
Temperatura
42320
# Timet-outs
42321
# Resp. Válidas
42322
# Reintentos
Temperatura
EF_SIN_TTAR_9753
Temperatura
Temperatura
86
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
La configuración del Servidor Web Apache se hace a través del archivo “httpd.conf”
utilizando cualquier editor sencillo de texto. En el Apéndice D se encuentra este archivo de
configuración. Las características principales del Servidor Web son:
•
Escucha peticiones a través del puerto 80.
•
Capacidad de Interpretar documentos PHP.
•
Capacidad de manejo de Scripts CGI, Scripts de Perl y JavaScript.
El Módulo de Captación de Datos desde el Servidor Web es el que se encarga de
extraer los datos de la tabla Modbus de la Net-DAS a través del protocolo XML - RPC
utilizando HTTP por el puerto 8080. Es decir, en el Servidor Web se ejecuta un Cliente XML
– RPC el cual se comunica con el Servidor Agente Interfaz o Servidor XML - RPC. Este
cliente se ejecuta cuando a través del explorador se hace una llamada, dentro de un archivo
HTML, al Script de Perl “dat_EF_SIN.pl”, el cual utiliza los módulos de Perl
“HTMLRenderData.pm” y “FieldAccess.pm”. Estos archivos se muestran en el Apéndice B.
Estos archivos son creación del mismo grupo de trabajo que diseñó el Servidor Agente
Interfaz. Dentro del archivo “dat_EF_SIN.pl” se edita un arreglo de datos types para indicarle
cada TAG que se desea consultar al Servidor Agente Interfaz. Es necesario recordar con
exactitud el nombre del TAG incorporado en el Servidor Agente Interfaz. Este arreglo es de
tamaño variable y tiene una estructura como se muestra en la Figura 4.21.
TAG Módulo de
Visualización
$types={
'EF_SIN_PT_9734'=>[
Formato de Dato 2
decimales
'EF_SIN_PT_9734',
'%.2f'
],
'EF_SIN_TT_9573'=>[
TAG Servidor
Agente Interfaz
'EF_SIN_TT_9753',
'%.2f'
],
};
Figura 4.21.- Ejemplo de Definición de TAGs a ser Consultados desde el Servidor Web al Servidor Agente
Interfaz
Como se muestra en la Figura 4.21, dentro del archivo de Perl “dat_EF_SIN.pl”
también se especifica el nombre del TAG que utilizará el modulo de Visualización para
87
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
mostrar los datos. En ese ejemplo, el nombre del TAG coincide tanto del lado del Servidor
Agente Interfaz como del lado de la Visualización de Datos. Esto no necesariamente es así.
Funcionamiento
Cuando se llama al Script de Perl “dat_EF_SIN.pl” directamente desde el navegador
o a través de un documento HTML, lo primero que se realiza, es la lectura de los TAGs que
se desean consultar en el Servidor Agente Interfaz, es decir, la lectura del arreglo types
descrito en la página anterior. Luego, se hace una llamada a una función del módulo
HTMLRenderData.pm que codifica los datos la cual a su vez hace llamadas a todas las
funciones necesarias dentro del módulo FieldAccess.pm, para extraer los datos del Servidor
Agente Interfaz a través del protocolo XML – RPC. Una vez que se obtienen los datos el
módulo HTMLRenderData.pm los codifica, y se muestran a través de una función de
impresión llamada en el Script de Perl. En la Figura 4.22 se tiene el esquema de
funcionamiento, junto con el orden de ejecución. En los Apéndice B se encuentra el código
fuente de cada uno de estos archivos.
dat_EF_SIN.pl
1
HTMLRenderData.pm
Se solicita ejecución
del Script de Perl (.pl)
2
FieldAccess.pm
5
3
6
4
Se imprime el valor del TAG
solicitado, junto con el estado
del dato. *
* En este punto todavía falta un paso para disponerlo al documento HTML de visualización
Figura 4.22.-Esquema de Funcionamiento del Módulo de Captación de Datos desde el Servidor Web
4.3.5.- Módulo de Visualización en Web
La Visualización en Web permite mostrar los datos provenientes del nivel más bajo
de toda la Arquitectura, conformado por los instrumentos de campo. Este módulo esta
constituido por el documento HTML que contiene la Interfaz Gráfica del Sistema y tres
archivos JavaScript utilizados para la lectura de los datos extraídos en el Módulo de
Captación de Datos desde el Servidor Web a través del Script hecho en Perl, y para el
88
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
refrescamiento periódico de los datos en la página. La plantilla diseñada para la
Visualización de los datos de Campo modelando el Sistema de Medición de la Estación de
Flujo SINCO-D, esta contenida en el documento HTML “dsp_EF_SIN.htm”, y se muestra en
la Figura 4.23.
La Medición en la Estación de Flujo SINCO - D se hace en línea directamente en el
oleoducto. Tal como se describió en la sección 4.3.1, los distintos instrumentos son: un
Transmisor de Flujo Micromotion RFT9739 ubicado aparte del oleoducto, un sensor de flujo
Micromotion CM F400, un Transmisor de Temperatura Rosemount 3144P con su sensor, un
Transmisor de Presión Rosemount 3051TG con su sensor y un Transmisor de Corte de Agua
Agar OW-202. El sensor y el display de corte de agua en la actualidad no están instalados.
En la plantilla gráfica se indican tanto los valores de procesos, como el estado de
comunicación de cada uno de los transmisores de campo.
La estructura del documento HTML desarrollado para el Módulo de Visualización es
sencilla: dentro del código fuente se tiene la referencia a la imagen de fondo (foto real de la
Arquitectura actual en SINCO - D), un grupo de capas (layers en inglés) utilizadas para
mostrar las etiquetas y los campos de datos numéricos para cada uno de los instrumentos, y
unas referencias a los Script de Java. La implementación en detalle de este documento
HTML, se encuentra en su código fuente que forma parte del Apéndice B.
Funcionamiento
El cuerpo del Módulo de Visualización está constituido por el documento HTML
“dsp_EF_SIN.htm” (ver figura 4.24). Los campos de datos tienen asociado un TAG en
específico de acuerdo a la variable correspondiente. La librería “netdaslib.js”, es utilizada
para indicar la dirección URL necesaria para ejecutar el Script de Perl “dat_EF_SIN.pl”
descrito en la sección anterior. La librería “hmlIO.js” contiene las funciones de extracción de
los datos resultantes del Script de Perl. Y por último, el archivo “netdasPageRefresh.js”
contiene las funciones para el refrescamiento de la página. Cuando se llama el documento
HTML desde el explorador, el Servidor Web interpreta el código y genera una salida donde
se visualizan los datos de campo. Los códigos fuentes de esos Scripts de Java se encuentran
en el Apéndice B.
89
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Figura 4.23.- Plantilla Gráfica para la Visualización de los Datos de Campo
netdaslib.js
dsp_EF_SIN.htm
htmlIO.js
Despliegue en
el Explorador
netdasPageRefresh.js
Servidor Web
Apache
Figura 4.24.- Esquema de Funcionamiento del Módulo de Visualización en Web
90
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
4.4.- Dominio Web
Esta sección como tal no forma parte de la Arquitectura del Sistema Automatizado de
Medición en Línea, pero si pertenece al compendio final del Proyecto, es por ello que será
brevemente explicado, para entender exactamente como se accede al despliegue dinámico
para la visualización de los datos de campo.
El Dominio Web esta conformado por un conjunto de marcos (frames), los cuales
sirven de alojamiento para las distintas páginas desarrolladas en PHP, HTML y Perl. Al
llamar al URL del Servidor Web (http://<ip_del_servidor>/) se carga este juego de marcos,
apareciendo en la parte central izquierda un menú, el cual no es más que una página
desarrollada en PHP que permite explorar fácilmente todas las secciones del Dominio. En la
Figura 4.25 se muestra la página inicial del Dominio, la cual contiene un menú donde se
tienen tres categorías: Arquitecturas, Net-DAS Configuración y el Proyecto SAMEL.
Arquitecturas
En esta categoría se encuentra las imágenes de las Arquitecturas de Medición actuales
para Crudo y Gas, correspondientes a las Estaciones de Flujo y el Patio de Tanques de las
regiones de Apure y Barinas. Por otra parte, se muestra el diseño de la Arquitectura
contemplada en el Proyecto SAMEL.
Figura 4.25.- Página Inicial de la URL del Dominio Web
91
SISTEMA INTEGRADO DE SUPERVISIÓN Y MONITOREO
Net-DAS Configuración
Contiene una Administración de las Net-DAS basadas en su dirección IP. En esta
categoría se muestran dos secciones: Administrar Bases de Datos Net-DAS y Net-DAS
Online. En la primera se pueden agregar, editar y eliminar equipos Net-DAS a la base de
datos, de tal manera que desde la sección Online se haga una consulta de cuales equipos NetDAS están conectados en Red (sólo para aquellos Net-DAS que hayan sido agregados a la
base de datos). Esa consulta se hace a través del comando de estatus de conexión en red
conocido como ping, desde un Script de Perl. Para aquellos equipos que estén conectados, se
habilitará la URL para acceder directamente a su página interna de configuración. La base de
datos esta corriendo sobre el Servidor de Bases de Datos MySQL instalado en el mismo
equipo donde esta corriendo el Servidor Web Apache. Todas las páginas utilizadas en esta
categoría están hechas con PHP.
SAMEL
En esta categoría se encuentran los despliegues para la visualización de los datos
provenientes de campo. Por el momento, solo esta implementado la Medición de Referencia
de Crudo en la E.F Sinco – D, ya que el Proyecto modela la arquitectura de esta Estación de
Flujo. Es precisamente en esta categoría donde esta alojada la página HTML
“dsp_EF_SIN.htm” utilizada por el Módulo de Visualización en Web.
CAPITULO 5.- PRUEBAS Y ANÁLISIS DE RESULTADOS
5.1.- Introducción
Como resultado de la planificación, desarrollo e implementación de un Sistema de
Medición y Monitoreo, en este capítulo se abarca cada una de las pruebas hechas para evaluar
el correcto funcionamiento de las distintas partes que conforman a la Arquitectura para
Medición Fiscal y de Referencia, así como también el resultado obtenido en la integración
completa del Sistema. Por otra parte, se pretende describir las Ventajas y Limitaciones del
Sistema.
5.2.- Pruebas y Resultados Técnicos
Las pruebas hechas abarcan todos los niveles de la Arquitectura, empezando por la
instrumentación de campo. A continuación sea irá describiendo cada una de las pruebas:
Lazo Hart
Para comprobar que efectivamente existía comunicación Hart entre los transmisores de
presión y temperatura, y el computador embebido Net-DAS se utilizó la herramienta de
Detección Hart que ofrece el Sistema Net-DAS. Para ello, se incluyó en el URL del
explorador Web la dirección IP del computador Net-DAS (http://<ip_Net-DAS>). Debe
aparecer el menú de Administración. Seleccionando la opción de Detección Hart, aparece una
página para indicar el puerto donde este conectado la Interfaz Hart RS-232. Seleccionado el
puerto adecuado aparece una pantalla con el siguiente resultado mostrado en la Figura 5.1.
Esta prueba fue hecha sin haber incluido los transmisores Hart dentro del Sistema Net-DAS,
simplemente el puerto /dev/ser4 fue configurado como Amo Hart.
Red Modbus
Para este caso no existe una herramienta de detección de dispositivos Modbus en el
Sistema Net-DAS. Es necesario que sea previamente conocida la dirección Modbus que tiene
el dispositivo para poder establecer comunicación con la Net-DAS. El transmisor de flujo
RFT9739, único dispositivo conectado en la red Modbus, fue configurado vía Modbus
utilizando el programa Prolink II que viene con este equipo. El transmisor tiene configurado
una comunicación Modbus RTU a 9600 bps con 8bits de datos,1 bit de parada, sin paridad.
95
PRUEBAS Y RESULTADOS
Este software a través de un escaneo de todas las direcciones válidas Modbus, detectó al
transmisor por la dirección “1”. De esta manera, se logró conocer que dirección Modbus tenía
asignado el equipo y que efectivamente se esta comunicando por este protocolo. Una vez
agregado el transmisor al Sistema Net-DAS por el puerto /dev/ser3 configurado como Amo
Modbus, se comprobó que los datos se estaban registrando en la tabla Modbus.
Scanning HART devices at port /dev/ser4, please wait...
Transmitter found at device address 1
MFR_ID=
26
MFR_DT=
19
UNIV_REV=
5
DEV_ID1=
16
DEV_ID2=
03
DEV_ID3=
DC
MANUFACTURER ID= 9753
(0x2619)
DEVICE ID=
1442780
(0x1603DC)
RESP1=
0x00
RESP2=
0xC8
Continuing sacanning process, please wait...
Transmitter found at device address 2
MFR_ID=
26
MFR_DT=
06
UNIV_REV=
5
DEV_ID1=
71
DEV_ID2=
5E
DEV_ID3=
FA
MANUFACTURER ID= 9734
(0x2606)
DEVICE ID=
7429882
(0x715EFA)
RESP1=
0x00
RESP2=
0x48
Continuing sacanning process, please wait...
End of HART scanning process!
Scanning HART devices at port /dev/ser4, please Wait...
Figura 5.1.- Respuesta de los Transmisores en la Detección Hart
Comunicación Modbus TCP
La manera como se extraen los datos de la Net-DAS provenientes de los dispositivos
de campo, es utilizando el protocolo de comunicación Modbus TCP. La Net-DAS tiene
configurado un Esclavo Modbus TCP con dirección “1”, para responder a las peticiones
hechas por Amos Modbus TCP a través del puerto 502. Para realizar la prueba se utilizó un
programa que permite configurar Amos Modbus, conocido como ModScan32. Los detalles de
la comunicación se muestran en la Figura 5.2.
96
PRUEBAS Y RESULTADOS
Figura 5.2.- Configuración de un Amo Modbus TCP para Prueba de Comunicación con Net-DAS
Como se muestra en la Figura 5.2, se esta usando un Servidor Remoto de Modbus
TCP/IP, al cual se le especifica el IP de la Net-DAS y el puerto de servicio a utilizar. Una vez
establecida la conexión, como se observa en la Figura 5.3 en la parte superior derecha, aparece
el número de preguntas hechas al esclavo Net-DAS y el número de respuestas válidas dadas
por el mismo.
Figura 5.3.- Comunicación con el Esclavo Modbus TCP configurado en la Net-DAS
En la Arquitectura desarrollada el Servidor Agente Interfaz es quién se comunica con
la Net-DAS vía Modbus TCP. El Servidor Agente Interfaz no cuenta con un despliegue donde
se puedan apreciar los datos recogidos y transferidos a las aplicaciones que se ejecutan gracias
al Servidor Web. Por lo tanto, básicamente no se dispone de herramientas para evaluar en
etapas intermedias la comunicación entre la Net-DAS y el despliegue Web. La única manera
97
PRUEBAS Y RESULTADOS
es evaluando directamente desde estas aplicaciones Web, y observando que efectivamente si
se obtienen los datos de campo.
El Script de Perl
Existe una posibilidad de ver los datos de campo desde el Script de Perl sin necesidad
de consultarlos directamente en el despliegue Web final. Para ello desde el explorador hay que
llamar la dirección URL http://<ip_del_servidor_web>/modperl/nodos/dat_EF_SIN.pl. El
resultado se muestra en la Figura 5.4.
Figura 5.4.- Datos de Campo vistos desde el Script de Perl
Despliegue Web Final
Este corresponde el objetivo final del diseño de la Arquitectura, ver los datos de campo
en un despliegue gráfico utilizando los estándares de Internet. En la siguiente figura se
muestra el resultado de una consulta hecha de los datos de campo (presión, temperatura, etc.)
En la Figura 5.5 se observan las variables de proceso con sus unidades, y el estatus de
la comunicación de cada dispositivo. Esto representa un modelo de lo que vería un cliente de
PDVSA que desee consultar los datos importantes de las distintas unidades de producción,
transporte y almacenamiento de crudo.
98
PRUEBAS Y RESULTADOS
Figura 5.5.- Despliegue Gráfico de la Arquitectura Desarrollada
5.3.- Ventajas del Sistema
Las Ventajas del Sistema Automatizado para Medición Fiscal y de Referencia en
Línea, son considerables en comparación a los sistemas actuales para Adquisición de Datos y
Supervisión con los que cuenta el Departamento de Automatización Industrial en la División
Centro – Sur. Estas ventajas se pueden clasificar como:
Técnicas
Las Ventajas Técnicas se refieren básicamente a los beneficios que ofrece la utilización
del Sistema de Adquisición de Datos Net-DAS.
•
Permite la Adquisición y transmisión de grandes volúmenes de
información, tales como perfiles térmicos y cartas dinagráficas, entre
otros.
99
PRUEBAS Y RESULTADOS
•
Permite la distribución masiva de la información de proceso de
campo a toda la Corporación sin necesidad de adquirir sistemas de
software de visualización especializados y agregando valor a la
infraestructura de redes ya instalada.
•
Efectúa la conversión de protocolos entre dispositivos especializados
que generan la información de campo y los sistemas corporativos de
visualización, almacenamiento y explotación de dicha información,
permitiendo así la integración de los sistemas de automatización ya
existentes, utilizando como medio la Internet/Intranet.
•
Permite el control avanzado de procesos de producción mediante la
ejecución en campo, de lógicas y aplicaciones de alto nivel descritas
en cualquier combinación de los lenguajes IEC-61131-3 y lenguajes
como C y Java.
•
Configuración y explotación de los datos vía Web, usando
protocolos estándares no propietarios tales como Java y Modbus
TCP.
•
Esta equipado con aplicaciones propias del negocio para la
supervisión y control especializados de instalaciones.
Costo/Funcionalidad
La Arquitectura desarrollada esta basada en aplicaciones propias de la Corporación,
por lo tanto, la disminución de los costos es enorme en comparación con los sistemas
especializados de adquisición de datos como los SCADA. Básicamente la Arquitectura NetDAS puede tener las mismas características de estos sistemas, inclusive ofreciendo nuevos
beneficios.
Accesibilidad
Como es una Arquitectura basada en estándares de Internet, le brinda facilidad de uso
al cliente que desee hacer consultas de campo, debido a que solo necesita estar conectado
dentro de la red de proceso, y no se necesitan computadores con programas propietarios
100
PRUEBAS Y RESULTADOS
especializados. Cualquier usuario con un computador personal de características comunes,
puede acceder a la aplicación.
Tecnología
Todas las herramientas y equipos utilizados son de última generación, abarcando desde
la adquisición de los datos en campo hasta la visualización de los mismos en la aplicación
Web.
5.4.- Limitaciones del Sistema
El Sistema Net-DAS actualmente en el Departamento de Automatización en la
División Centro – Sur es relativamente nuevo, por lo tanto, todos los desarrollos locales deben
empezar por proyectos pilotos que no expongan a ningún proceso crítico que tenga valor de
negocio. Es por ello que el proyecto presente esta limitado a ser desarrollado solo a nivel de
laboratorio.
El Sistema implementado sólo aplica para la Supervisión y Monitoreo, pero si
requiriese tiene capacidades de expansión para ejercer Control. La Arquitectura es bastante
escalable por estar basada en estándares de comunicación industrial.
Los tiempos de respuesta para la visualización dependen en gran medida del ancho de
banda de la red y de la capacidad de respuesta de los equipos críticos de la Arquitectura, como
es el caso del Servidor Web.
CAPITULO 6.- CONCLUSIONES Y RECOMENDACIONES
Como parte primordial de las conclusiones es necesario nombrar que efectivamente se
logró cumplir con los objetivos planteados al inicio del trabajo. Estos incluyeron una serie de
estudios teóricos y documentación previa muy importante para luego definir la integración
propuesta como una alternativa para la Supervisión y Monitoreo, empleando un Sistema
Alternativo de Adquisición de Datos. Más allá de los resultados obtenidos, la experiencia
vivida durante el desarrollo de la pasantía en las instalaciones del Departamento de
Automatización Industrial, tiene una importancia invaluable que contribuye significativamente
a la adquisición de valores y al desarrollo de habilidades para el desenvolvimiento adecuado y
competente dentro del ámbito empresarial.
La integración e implementación de la Arquitectura para Medición Fiscal y de
Referencia en Línea basada en el Sistema Net-DAS y en tecnologías Web, genera beneficios
importantes para el Departamento de Automatización Industrial. Es una arquitectura que está
totalmente alineada a las exigencias actuales propuestas internamente en el Departamento, las
cuales se resumen en la búsqueda de alternativas para la Supervisión, Monitoreo, y Control
que empleen tecnologías de punta orientadas a estándares mundiales para el desarrollo de
aplicaciones, soportada por las ventajas que ofrece la plataforma TCP/IP y los protocolos
utilizados con la Internet.
Como el Sistema Net-DAS es relativamente nuevo dentro del Departamento y más que
esta siendo instalado en un nuevo computador modular industrial con estándar PC/104-Plus de
mayor capacidad, único entre los distintos computadores a nivel nacional utilizados para esta
Arquitectura, se considera que está aún en fase de prueba. Por lo tanto todos los desarrollos
basados en él, permiten que vaya adquiriendo madurez a lo largo del tiempo, de tal manera
que se pueda ir incorporando paulatinamente dentro de los procesos que tengan valor de
negocio dentro de la Corporación. La integración de este Sistema de Adquisición de Datos
para Supervisión y Monitoreo vía Web, contribuye significativamente en este sentido, dándole
soporte para futuros proyectos pilotos que actualmente están en sus primeras fases. Una gran
ventaja que ofrece la utilización del Sistema Net-DAS, es el alto nivel de integración que
102
CONCLUSIONES Y RECOMENDACIONES
ofrece dentro de los procesos industriales. La interoperabilidad entre diversos sistemas es, por
lo general, el principal problema dentro de los procesos en campo, debido a los diferentes
protocolos de comunicación con los que cuentan cada equipo de un fabricante diferente. Con
este sistema, se abarca una gama de protocolos comúnmente utilizados por los transmisores en
campo, y por si fuera poco, es capaz de soportar un número ilimitado de entradas y salidas
tanto analógicas como digitales. Es un sistema sumamente escalable, con capacidades para
permitir control avanzado procesos especializados de producción en materia de hidrocarburos,
mediante la ejecución en campo de lógicas y aplicaciones de alto nivel descritas en cualquier
combinación de los lenguajes IEC-61131-3 y lenguajes como C y Java.
Actualmente, a nivel nacional en la Corporación se ha incorporado la filosofía de
Software Libre/Código Abierto, y se ha ido poco a poco incursionado en el tema. En el
Departamento de Automatización de este Distrito, están tomando cartas en el asunto, y han
comenzado con los desarrollos en código abierto para la disposición de los datos
suministrados por la Net-DAS, en ambientes Web. Desde el sistema operativo (Linux/Debian)
hasta las herramientas utilizadas para la programación de las aplicaciones, están bajo esta
filosofía. Esto se ha incorporando por un grupo de trabajo conformado por personal interno y
contratado especialistas en la materia.
La Arquitectura desarrollada con este proyecto no está completamente basada en
código abierto, ya que algunas aplicaciones están corriendo sobre plataformas Win32, que
pertenece al gran mundo de software propietario para los cuales se requieren grandes
inversiones en licenciamiento para la adquisición y utilización de estas herramientas. La
Corporación actualmente invierte miles de millones únicamente para el pago de licencias para
software. Sin embargo, todas las aplicaciones utilizadas para la integración están disponibles
libremente para ambas plataformas (Win32 y Linux), o simplemente, son independientes del
sistema operativo. Como por ejemplo, en el caso del Servidor Web Apache, se consigue
libremente (bajo las licencias creadas por la Apache Software Foundation) en ambas
plataformas. Igualmente, para el intérprete de Perl. En caso de los lenguajes de programación
como PHP y HTML son independientes del sistema operativo, solo se requiere que el servidor
Web pueda interpretarlos. Dentro de las aplicaciones utilizadas, sólo los sistemas operativos
103
CONCLUSIONES Y RECOMENDACIONES
Windows (donde esta corriendo el Servidor Web) y QNX (sobre el cual corre Net-DAS)
requieren licencias para su uso legal. Ningún software desarrollado queda limitado a una
plataforma en específico, y mucho menos requiere licencia del algún programa para
ejecutarlos. Por lo tanto, se puede decir que de alguna manera es una arquitectura alineada en
gran parte a esta filosofía que actualmente gana terreno en los proyectos de avances
tecnológicos dentro de la Corporación.
La supervisión y monitoreo basado en tecnologías Web, brinda las facilidades de
consulta sin necesidad utilizar sistemas especializados. El propósito final de la Arquitectura
desarrollada es precisamente la visualización de los datos de campo, y hacerlo vía Web es una
excelente herramienta sobretodo si se propone el Sistema como una Arquitectura alternativa
para Medición Fiscal. Para este caso al cliente, el Ministerio de Energía y Minas (MEM), se le
facilitaría en gran medida la supervisión y monitoreo de los puntos de Fiscalización en las
distintas divisiones de la Corporación a nivel nacional, únicamente contando con el acceso a la
red de procesos donde esté montada la Arquitectura. Para la visualización de los datos, se
puede modelar fácilmente en aplicaciones Web los despliegues gráficos utilizados para la
supervisión con el sistema especializado SCADA con el que cuenta actualmente el Distrito.
Por otra parte los avances en esta tecnología son muy frecuentes, y por lo general, están a
disposición de los usuarios/desarrolladores interesados, más aún cuando se trate de estándares,
y aplicaciones en código abierto.
Las recomendaciones se resumen en dos grandes aspectos. Por una parte, que todos
los desarrollos posteriores en materia de automatización deben siempre seguir los estándares
internos a nivel corporativo, y en lo posible adaptarse a los estándares comúnmente manejados
a nivel mundial, considerando la tecnología Web como una herramienta poderosa para el
desarrollo de aplicaciones que requieran accesos remotos. Por otra parte, como recomendación
en tema de Fiscalización, considerar a Net-DAS como un posible sistema para las mediciones
críticas de las distintas áreas de producción e incentivar a buscar una aprobación por parte del
Ministerio de Energía y Minas.
104
REFERENCIAS BILIOGRÁFICAS
[INTEVEP, 2004] Manual Arquitectura Net-DAS. “Una solución de PDVSA para PDVSA.
PDVSA Intevep”. Intevep, S.A. Año 2004.
[FEBRES, 2001] Proyecto de Grado de la Universidad Simón Bolívar (USB) . “Protocolo
de Comunicación HART, para los instrumentos de FLOTECH, S.A.”. FEBRES, Erika. Año
2001. Documento Electrónico en formato PDF.
[MODICON, 1996] Guía de Referencia. “Modicon Modbus Protocol”. Modicon, Inc.
Año 1996. Documento Electrónico en formato PDF.
[INTELLICOM, 2005] Modbus TCP. Documentación en Línea disponible en:
www.intellicom.se (Consulta: Enero, 2005)
[XML-RPC, 2005] XML – RPC. Documentación en Línea disponible en: www.XMLRPC.com (Consulta: Enero, 2005)
[PHP, 2005] Lenguaje PHP. Documentación en Línea disponible en: www.php.net
(Consulta: Noviembre, 2004)
[UNICAN,
2005]
Protocolo
HTTP.
Documentación
en
Línea
disponible
en:
www.unican.es (Consulta: Febrero, 2005)
[TECNOLOGÍAS WEB, 2005] Tecnologías Web. Documentación en Línea disponible
en:
http://www.dccia.ua.es/dccia/inf/asignaturas/TW/teoria.htm
(Consulta,
Diciembre
2004)
[GARCÍA, 2004] Proyecto de Grado de la Universidad Nacional Experimental del Táchira
(UNET). Definición e Implementación de las Políticas y Seguridad de Alarmas para el
Sistema SCADA en PDVSA – Sur. GARCÍA, Reneé. Año 2004.
105
[PÉREZ, 2004] Proyecto de Grado del Instituto Universitario Politécnico Santiago Mariño.
“Propuesta de un Portal Web para el Departamento de Automatización Industrial de la
Superintendencia de Automatización, Informática, Telecomunicaciones y Seguridad (AIT)
de PDVSA División Centro – Sur”. PÉREZ, Thayré. Año 2004.