Integración De Un Sistema Automatizado Para Medición Fiscal Y De

Transcript

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" (). 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: , ). Existen, no obstante, algunas marcas que no requieren su pareja de cierre, como
(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. 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:///, 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:///) 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://). 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:///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.