View
236
Download
1
Category
Preview:
Citation preview
1
Análisis e Implementación de la Actualización del Centro de Control del Sistema SCADA
de Gases de Occidente S.A. E.S.P.
Leidy Yinet Ferro Lara
Código: 20021005013
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERIA
PROYECTO CURRICULAR DE INGENIERÍA ELECTRONICA
BOGOTÁ D.C
2016.
2
Análisis e Implementación de la Actualización del Centro de Control del Sistema SCADA
de Gases de Occidente S.A. E.S.P.
Leidy Yinet Ferro Lara
Código: 20021005013
Director Interno: Pablo Emilio Rozo García
Docente Ingeniería Electrónica
Director Externo: Rodolfo Yesid Meza Patacón
Gerente Ingeniería RAYCO Ltda.
Trabajo de Grado para optar al título de profesional en Ingeniería Electrónica
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERIA
PROYECTO CURRICULAR DE INGENIERÍA ELECTRONICA
BOGOTÁ D.C
2016.
iii
Dedicatoria
Y todo lo que hagáis, hacedlo de corazón, como para el Señor y no para los hombres;
sabiendo que del Señor recibiréis la recompensa de la herencia porque a Cristo el Señor
servís.
Colosenses 3: 23-24.
iv
Agradecimientos
Agradezco, sobre todas las cosas, a Dios: Padre, Hijo y Espíritu Santo.
A mi familia, por su amor, paciencia y apoyo incondicional.
A Rodolfo, que más que un jefe, ha sido un gran amigo, un líder digno a seguir. Mi gran
apoyo durante todo este proceso de aprendizaje, reconocimiento y valoración del camino
que he llevado a cabo durante este tiempo.
Al equipo de ingeniería de Rayco (Gustavo, Sebastián, Andrés, Ferney, Leonardo), con
quienes llevamos a cabo la ejecución de este proyecto. Sin ellos no hubiese sido una
realidad.
A mis amigos Andrea, Angelica, Nataly, Carolina, Paola, Ingrid, Camilo, Andrés, Leyla,
Amanda, Catalina, Edison, Pablo, que con sus consejos, confrontaciones y palabras de
apoyo estuvieron siempre ahí para lo que necesitara.
Al profesor Pablo Emilio, por su apoyo en el proceso de gestión con la Universidad.
v
Resumen
Este documento es un compendio general del proceso llevado a cabo para el alcance de
actividades propuesto para la actualización del centro de control del sistema SCADA de la
empresa Gases de Occidente S.A. E.S.P.
Comprende una etapa inicial de conocimiento general del negocio y del proceso de
distribución para identificar plenamente las necesidades planteadas por el cliente, de acuerdo
a los requerimientos, seguido del planteamiento de cómo será la estructura de la información
y la iteración de los diferentes actores como usuarios finales, para así generar la propuesta
de actualización y su posterior implementación.
Finalmente, se presentan los resultados obtenidos y las lecciones aprendidas durante el
proceso, para tenerlas en cuenta en las futuras implementaciones que se tienen proyectadas.
Palabras Clave
SCADA, Balance de Gas, Medición Volumétrica, ERM, Distribución, Procesamiento,
Nominación.
vi
Abstract
This document is a general summary of the undertaken process for the scope of activities
proposed to update the Control Center of SCADA System the Gases de Occidente S.A.
E.S.P.
Comprises an initial stage of general business knowledge and the distribution process to
identify the needs expressed by the costumer, according to the requirements, followed by the
approach of that will be the structure of the information and iteration of the different actors
and final users in order to generate the proposed update and its implementation.
Finally, the results and lessons learned during the process are presented, to take then into
reflected in future implementations.
Keywords
SCADA, Gas Balance, Volumetric Measurement, ERM, Distribution, Processing,
Nomination.
vii
Tabla de Contenido
1. Capítulo 1 Descripción General del Proceso de Distribución de Gas Natural. ................... 1
1.1. Generación y Transporte. ................................................................................................ 1
1.1.1. Sectores de Aplicación del Gas Natural ................................................................. 2
1.1.2. Componentes de la infraestructura de gas natural. ............................................... 2
1.1.3. Proceso de Distribución en el Valle del Cauca y Cauca. ....................................... 4
1.1.4. Tipos de Estaciones que conforman la red de distribución ................................... 6
1.2. Regulación Mercado Mayorista Gas Natural – Resolución 089 de 2013 ..................... 9
1.2.1. Consideraciones ........................................................................................................ 9
1.2.2. Objeto de la Resolución .......................................................................................... 10
1.2.3. Conceptos Claves a Tener en Cuenta de la Resolución ....................................... 10
2. Capítulo 2 Contexto y Planteamiento de Requerimientos de la Actualización ................. 13
2.1. Contexto del Proyecto ..................................................................................................... 13
2.2. Panorama Actual del Sistema SCADA ......................................................................... 13
2.2.1. Antecedente Histórico............................................................................................. 13
2.3. Revisión Estructura Actual ............................................................................................ 16
2.3.1. Componente Hardware .......................................................................................... 16
2.3.2. Componente Software ............................................................................................ 18
2.3.3. Esquema General Entrega de Información .......................................................... 20
2.3.4. Limitaciones Plataforma vs. Nuevos Requerimientos ......................................... 21
3. Capítulo 3. Estructura de Datos – Modelo Planta ............................................................... 24
3.1. Tipos de Estaciones ......................................................................................................... 24
3.1.1. City Gate .................................................................................................................. 24
3.1.2. Estaciones de Regulación y Medición ................................................................... 26
3.1.3. Estaciones de Gasoducto Virtual ........................................................................... 28
3.1.4. Estaciones de Servicio GNV y Clientes Industriales ............................................ 30
3.1.5. Válvulas de Seccionamiento ................................................................................... 31
3.1.6. Modelo Generalizado de Estación Típica ............................................................. 32
3.2. Medición Volumétrica .................................................................................................... 33
3.2.1. Medidores de Flujo Volumétrico ........................................................................... 34
3.2.2. Factor de Corrección y Correctores Electrónicos de Volumen .......................... 35
3.2.3. Medición Tipo Turbina, AGA 7. ........................................................................... 37
3.2.4. Cálculo del factor de supercompresibilidad. Reporte AGA 8 ............................ 42
viii
3.2.5. Medición Electrónica de gas. Norma API MPMS 21.1. ...................................... 44
3.3. Requerimientos de auditoría y reporte ......................................................................... 46
3.3.1. Estructura Registro Hora – Hora .......................................................................... 48
3.3.2. Estructura Registro Día – Día ............................................................................... 49
3.3.3. Estructura Registro Máximos y Mínimos............................................................. 50
4. Capítulo 4 Propuesta de Actualización ................................................................................. 52
4.1. Filosofía de Procesamiento de Información ................................................................. 53
4.1.1. Aplicación en la RTU Remota ............................................................................... 54
4.1.2. Red de Comunicaciones Remotas - Centro de Control ..................................... 56
4.1.3. Actualización de Equipos y Aplicación del FEP .................................................. 57
4.2. Actualización de la infraestructura de servidores y del software SCADA ................ 63
4.2.1. Soporte Hardware - Virtualización ....................................................................... 63
4.2.2. Planificación del Ambiente Virtual ....................................................................... 69
4.3. Aplicación SCADA ......................................................................................................... 72
4.3.1. Casos de Uso ............................................................................................................ 73
4.3.2. Acondicionamiento del diseño a la herramienta usada. ...................................... 77
4.3.3. Ventajas de la Utilización de Framework System Platform de Wonderware. .. 86
4.4. Aplicación Cliente ........................................................................................................... 87
4.4.1. Diseño del HMI ....................................................................................................... 88
4.4.2. Diseño de Aplicación Web .................................................................................... 104
5. Capítulo 5 Proceso de Implementación .............................................................................. 106
5.1. Implementación de Front End Processor. .................................................................. 106
5.1.1. Tabla Mapeo Datos ............................................................................................... 107
5.1.2. Tabla Queue Status ............................................................................................... 108
5.1.3. Tabla Mapeo Canales ........................................................................................... 109
5.1.4. Tablas de Almacenamiento Temporal de Datos. ............................................... 110
5.2. Implementación de la aplicación SCADA .................................................................. 112
5.2.1. Los Objetos de la Galaxia .................................................................................... 112
5.2.2. Historización de Señales y Alarmas .................................................................... 116
5.3. Reportes Consolidados ................................................................................................. 120
5.3.1. Reporte Consolidado Previous Day ..................................................................... 120
5.3.2. Base de Datos Cuenta Balance ............................................................................. 123
5.3.3. Base de Datos Current Day .................................................................................. 126
ix
6. Capítulo 6 Resultados y Conclusiones ................................................................................ 128
6.1. Resultados Obtenidos ................................................................................................... 128
6.1.1. Tiempos de Polling Variables Actuales. .............................................................. 128
6.1.2. Petición de Registros por demanda del usuario. ................................................ 131
6.1.3. Parámetros de medición sin historizar. .............................................................. 132
6.1.4. Disponibilidad de registros horarios, diarios, máximos y mínimos para la
nominación y subasta diaria del bien energético. .............................................................. 133
6.2. Novedades Presentadas Durante el Proyecto ............................................................. 134
6.2.1. Cambio de Frecuencias en el Sistema de Radiocomunicaciones ...................... 134
6.2.2. Implementación de Politica Ley Sox en la Compañía ....................................... 135
6.3. Conclusiones Finales ..................................................................................................... 136
6.4. Trabajos Futuros .......................................................................................................... 136
Lista de Referencias ...................................................................................................................... 138
x
Lista de Tablas
Tabla 2-1. Relación de aspectos a revisión y objetivos a alcanzar en la actualización. ................... 23
Tabla 3-1 Variables Actuales Típicas de una estación tipo City Gate .............................................. 26
Tabla 3-2 Variables Actuales Típicas de una estación tipo Reguladora y Medición ....................... 27
Tabla 3-3. Variables Actuales Típicas de una estación tipo Gasoducto Virtual ............................... 29
Tabla 3-4. Variables Actuales Típicas de una estación tipo GNV y CLientes Industriales ............. 31
Tabla 3-5. Variables Actuales Típicas de una estación Valvula de Seccionamiento. ...................... 32
Tabla 3-6. Relación de Variables Análogas Comunes para los diferentes tipos de estaciones. ....... 32
Tabla 3-7. Relación de Variables Digitales Comunes para los diferentes tipos de estaciones. ........ 33
Tabla 3-8. Relación de Variables Digitales para control de los diferentes tipos de estaciones. ....... 33
Tabla 3-9.. Tabla Comparativa de medidores volumétricos (Información recuperada de
Itron/Actaris y consolidada por el autor) .......................................................................................... 35
Tabla 3-10 Rangos de composición de mezclas de gas .................................................................... 43
Tabla 3-11 Campos de un registro Hora - Hora ................................................................................ 48
Tabla 3-12 Campos de un registro Día – Día ................................................................................... 49
Tabla 3-13 Campos de un registro de Máximos y Mínimos ............................................................. 51
Tabla 4-1. Estimación tiempos de actualización de datos en aplicación de FEP.............................. 62
Tabla 4-2. Beneficios de la Virtualización de la Plataforma SCADA. ............................................. 65
Tabla 4-3 Niveles de Disponibilidad de Plataformas ....................................................................... 66
Tabla 5-1 Campos de variables actuales por brazo de medición .................................................... 111
Tabla 6-1 Proyección Datos Actuales, de acuerdo a la cantidad de brazos de medición, antes y
después de la migración. ................................................................................................................. 130
Tabla 6-2.Proyección Datos de Registros por Cantidad de Brazos de Medición ........................... 132
xi
Lista de Figuras
Figura 1-1 Cobertura de Servicio Gas Natural Valle del Cauca y Cauca. .......................................... 6
Figura 1-2. Esquema General Estación Tipo City Gate ...................................................................... 7
Figura 1-3. Esquema General Estación Tipo ERM ............................................................................ 8
Figura 1-4. Esquema General Estación Gas Virtual ........................................................................... 9
Figura 2-1. Topología Centro de Control Gases de Occidente S.A. E.S.P. ...................................... 15
Figura 3-1 Esquema General Estación Tipo City Gate ..................................................................... 25
Figura 3-2. Esquema General Estación Tipo ERM .......................................................................... 27
Figura 3-3. Esquema General Estación Gas Virtual ........................................................................ 29
Figura 3-4. Esquema General Estación Tipo ERM .......................................................................... 30
Figura 3-5. Esquema general Estación Tipo Válvula de Seccionamiento ........................................ 31
Figura 3-6. Factores que afectan una medición ................................................................................ 34
Figura 3-7. Partes de un medidor tipo turbina. ................................................................................. 38
Figura 4-1. Estructura Flujo de datos aplicación estación remota. Fuente: Elaboración Propia. ..... 54
Figura 4-2. Esquema Flujo de Datos Aplicación FEP. .................................................................... 58
Figura 4-3. Arquitectura de Recuperación a Desastres, usando la virtualización ubicados en lugares
geográficamente separados. .............................................................................................................. 67
Figura 4-4. Representación Gráfica de las tablas de almacenamiento temporal de los datos
recolectados de las estaciones remotas en FEP. ............................................................................... 69
Figura 4-5. Estructura Plataforma SCADA Gases de Occidente S.A. E.S.P., implementada en la
actualización. .................................................................................................................................... 70
Figura 4-6. Actores del Sistema SCADA ......................................................................................... 73
Figura 4-7 Diagrama de Casos de Uso ............................................................................................. 74
Figura 4-8 Diagrama de Clases ......................................................................................................... 77
Figura 4-9 El Framework System Platform de Wonderware, de acuerdo a la aplicación de Gases de
Occidente S.A. E.S.P. ....................................................................................................................... 78
Figura 4-10 La Galaxia y su contenido. ............................................................................................ 79
Figura 4-11. Diagrama de clases de una aplicación Wondeware Application Server ...................... 80
Figura 4-12 Diagrama de Clases adaptado al Framework ................................................................ 82
Figura 4-13 Diagrama de secuencia actualización estado variables actuales. .................................. 83
Figura 4-14 Diagrama de secuencia solicitud e historización registros. .......................................... 83
Figura. 4-15 Diagrama de secuencia de visualización de variables actuales en HMI. ..................... 84
Figura 4-16 Diagrama de Secuencia, generación Reporte Consolidado Previous Day. ................... 85
Figura 4-17 Layout Común de las pantallas del HMI ...................................................................... 90
Figura 4-18 Barra superior Panel Principal ...................................................................................... 90
Figura 4-19 Descripción General de Iconos Menú de Funcionalidades. .......................................... 91
Figura 4-20. Barra Alarmas Actuales ............................................................................................... 92
Figura 4-21 Mapa General Red de Distribución ............................................................................... 92
Figura 4-22. Panel Cabecera Municipal Cali .................................................................................... 93
Figura 4-23 Formato Tabla Consolidado Cali .................................................................................. 94
Figura 4-24 Mapa Distrito de Cali .................................................................................................... 95
Figura 4-25. Botones de Acceso Consolidados ................................................................................ 96
Figura 4-26. Panel Consolidado Estaciones Clientes Industriales .................................................... 96
Figura 4-27. Panel Consolidado Estaciones de Servicio .................................................................. 97
xii
Figura 4-28. Panel Consolidado Estaciones Reguladores Municipios ............................................. 97
Figura 4-29. Panel de Visualización Alarmas y Eventos .................................................................. 98
Figura 4-30. Panel de Visualización y Consulta Históricos ............................................................. 99
Figura 4-31. Barra de Herramientas Panel Históricos ...................................................................... 99
Figura 4-32 Menú Tags .................................................................................................................. 100
Figura 4-33. Área de Visualización ................................................................................................ 100
Figura 4-34. Panel de Tiempo Real ................................................................................................ 101
Figura 4-35. Panel de visualización y Configuración de Set Points ............................................... 102
Figura 4-36. Panel Site Map ........................................................................................................... 102
Figura 4-37. Panel de Máximos y Mínimos ................................................................................... 103
Figura 4-38. Panel de Ayuda .......................................................................................................... 104
Figura 4-39 Navigator Map del Portal Web ................................................................................... 105
Figura 4-40. Visualización de una estación remota típica desde el portal Web. ............................ 105
Figura 5-1. Distribución de Front End Processors Motorola. ......................................................... 106
Figura 5-2.Tabla Mapeo Datos. ...................................................................................................... 107
Figura 5-3 Tabla Queue Status ....................................................................................................... 109
Figura 5-4 Tabla Mapeo Canales .................................................................................................... 109
Figura 5-5 Ejemplo de tabla datos temporales de brazos de medición. .......................................... 110
Figura 5-6 Visualización Objetos de la aplicación SCADA ........................................................... 113
Figura 5-7 Atributos del template del objeto Motorola .................................................................. 114
Figura 5-8. Intouch Distributed Alarm System. ............................................................................. 118
Figura 5-9. Configuración de alarmas ............................................................................................ 119
Figura 5-10. Configuración de Alarmas. ........................................................................................ 119
Figura 5-11 visualización preliminar configuración de parámetros y datos de las estaciones remotas
en el Reporte Consolidado PD. ....................................................................................................... 121
Figura 5-12. Resumen Consolidado Por Localidad ........................................................................ 122
Figura 5-13. Grafico Consolidado por Municipios y Distrito de Cali ............................................ 123
Figura 5-14 Formato Registros Hora – Hora en Cuenta Balance. .................................................. 124
Figura 5-15 Formato Registros Máximos y Mínimos en Cuenta Balance ...................................... 125
Figura 5-16 Formato Registro Diario en Cuenta Balance .............................................................. 125
Figura 5-17 Formato original de registros Hora-Hora de un brazo de medición, almacenado en la
base de datos de Historian. ............................................................................................................. 126
Figura 5-18. Formato de entrega Volumen Corregido Actual ........................................................ 127
Figura 6-1. Crecimiento Sitios Remotos SCADA GDO. ............................................................... 129
Figura 6-2. Estimación Adquisición de Datos, antes y después de la actualización del centro de
control. ............................................................................................................................................ 129
Figura 6-3. Comparación entre datos estimados y cuantificación de datos historizados. ............... 130
Figura 6-4. Datos de Registros por Hora. ....................................................................................... 132
1
1. Capítulo 1
Descripción General del Proceso de Distribución de Gas Natural.
1.1. Generación y Transporte.
Este tipo de energía de origen fósil, es una mezcla de diferentes elementos gaseosos que
reaccionan muy bien con el oxígeno mediante su combustión. Se encuentra en las
profundidades de la tierra, muchas veces compartiendo los mismos depósitos del petróleo y
el carbón. Cerca del 90% de su composición está dada por carbono e hidrógeno, del cual su
mayor referente en cantidad es el metano, acompañado por otros gases, como el etano,
propano, butano, nitrógeno y CO2, aunque la capacidad energética de los dos últimos es
nula.
Dado que esta clase de recurso energético es compatible con el medio ambiente y se puede
aplicar en múltiples actividades por su alta eficiencia, se ha convertido en una de las fuentes
de energía más utilizada, creciendo año a año su demanda.
Una vez que ha sido extraído, mediante perforaciones de yacimientos que se localizan en el
subsuelo o bajo el mar, debe ser tratado para su uso comercial o doméstico. En su estado
original, es inodoro, incoloro, no tóxico y más liviano que el aire, es por ello que para el uso
doméstico por ejemplo se le agrega un poco de metil-mercaptano, para que sea fácil detectar
una posible fuga y evitar su composición espontánea.
Otros gases que se separan, son aquellos que no tienen aporte energético (como el nitrógeno
y el CO2) y aquellos que pueden generar accidentes durante la incineración del gas natural
(propano, butano e hidrocarburos). Por la misma razón, el vapor de agua es extraído, ya que
a presiones elevadas y temperatura ambiente produce hidratos de metano, que pueden tapar
los gasoductos. Otro elemento que se disminuye lo más posible es el nivel de azufre, para
eliminar la corrosión y los olores nocivos.
Esta fuente de energía es enviada a través de gasoductos o tuberías que salen directamente
de los tanques de almacenamiento, una vez que llega a su destino y es re gasificado, se
distribuye a los lugares de consumo a través de tuberías subterráneas, las cuales lo impulsan
por media y baja presión. Si no es utilizado, se almacena en grandes contenedores.
2
1.1.1. Sectores de Aplicación del Gas Natural
Funcionamiento industrial
El gas natural es usado en las industrias como combustible para la fabricación de diversos
productos. Por ejemplo, la confección de cristal laminado y acero de alta calidad necesita de
las temperaturas extremas que este tipo de fuente energética es capaz de proveer, ya que
puede arder a mayor cantidad de grados que el carbón o petróleo. Por eso es muy usado en
hornos y en plantas de tratamiento térmico y petroquímico.
Vehículos gaseosos
De acuerdo con la Asociación Internacional de Vehículos de Gas Natural, hay cerca de un
dieciséis millones vehículos en todo el mundo que emplean esta fuente energética. Estas
máquinas contaminan un 20% menos que los que utilizan gasolina o diésel. Además, es más
barato, ya que el consumidor puede llegar a gastar hasta un 75% menos que usando los otros
tipos de combustible.
Uso doméstico
Son múltiples las aplicaciones que tiene el gas natural en el hogar. Puede ser utilizado para
cocinar, climatizar, tener agua caliente para la ducha, etcétera. Sus ventajas son: facilidad de
instalación, suministro continuo, su combustión no contamina ni ensucia la vivienda y es
más barato que otros combustibles similares. Además, la conservación de los equipos que
funcionan con gas natural es mayor, debido a que no requieren mucho mantenimiento.
1.1.2. Componentes de la infraestructura de gas natural.
Desde el proceso de extracción en el pozo hasta la conexión en las industrias y los hogares,
se presenta la intervención de diferentes empresas y equipos para asegurar la confiabilidad
del sistema y hacen posible el uso del gas natural. Se presenta a continuación las diferentes
etapas recorridas por una molécula desde su explotación hasta que se convierte en energía
mediante los diferentes procesos de combustión.
3
Producción (P)
Existen dos pozos de producción de gas natural en Colombia y se encuentran ubicados en la
Guajira (Campo Chuchupa – A y B y Campo Ballena) y en Casanare (Campos Cupiagua y
Cusiana), los cuales están interconectados al Sistema Nacional de Transporte de gas (Bernal
Ortíz, 2009).
En los yacimientos se encuentra el gas natural asociado (con trazas de agua, petróleo y otros
componentes disueltos), el cual es extraído y “refinado” por diferentes sistemas de limpieza
hasta garantizar los límites permisibles estipulados en el Registro Único de Transporte
(RUT) y con los cuales debe ser entregado a la empresa transportadora.
Transporte (T)
Una vez se recibe el gas natural en las instalaciones de la empresa transportadora, éste
ingresa a la red de gasoductos de nuestro país, conformado por tubería de Acero Carbono de
diferentes diámetros y encargada de llevar el gas natural a los diferentes puntos de consumo.
Con el fin de evitar las pérdidas de presión en la tubería y en los diferentes accesorios, se
instalan una serie de compresores en la línea de gas natural, los cuales mantienen una presión
de suministro constante, alrededor de los 1200 PSI y aseguran el flujo continuo de gas a
través de todo el sistema.
Distribución (D)
El gas natural que es transportado a alta presión en el gasoducto, es entregado en las
estaciones conocidas como City Gates. En estas estaciones se realiza el proceso de reducir
la presión, por lo general a un valor nominal de 250 PSI, esto con el fin de que pueda ser
distribuido a los diferentes puntos de consumo, a través de redes de polietileno o de acero
carbono, de acuerdo a las necesidades o especificaciones del mercado.
Por lo general, los sistemas de distribución están conformados por estaciones de distrito, las
cuales reciben el gas natural a 250 PSI y reducen su presión hasta 60 PSI, para facilitar su
transporte y disminuir los costos de montaje asociados a las redes fabricadas en acero
carbono.
4
Comercialización (C).
Toda la relación entre el usuario final y los diferentes agentes de la cadena se realiza a través
de un agente comercializador, el cual se encarga de reunir las tarifas de cada una de las etapas
y presentar un precio final (P+T+D+C) por cada metro cubico (m3) de gas natural, el cual
se cancela de manera mensual por el consumidor, de acuerdo al volumen total de metros
cúbicos utilizados.
En todo el proceso intervienen diferentes organizaciones que hacen posible el consumo de
gas natural en los sectores de la economía. Estos no actúan solos, están regulados por la
Comisión Reguladora de Energía y Gas (CREG) y cuentan con el soporte por diferentes
gremios, como la Agencia Nacional de Hidrocarburos (ANH) y la Asociación Colombiana
de Gas Natural (NATURGAS), entre otras.
1.1.3. Proceso de Distribución en el Valle del Cauca y Cauca.
Gases de Occidente S.A. E.S.P. es la segunda compañía en número de usuarios de
distribución y comercialización de gas natural del país. Sus procesos incluyen el transporte
de gas combustible a través de redes de tubería, desde las estaciones reguladoras de puerta
de ciudad, hasta la conexión de un usuario (Gases de Occidente S.A. E.S.P., 2012)
Actualmente, la compañía cuenta con una red primaria de distribución de 119 Km,
compuesta por tuberías de acero operadas a alta presión. Estas tuberías conducen el gas a
una presión máxima de 250 PSI hasta las estaciones de distrito dispuestas en la red de
distribución, los centros de medición de los grandes consumidores industriales y las
estaciones de servicio de GNCV (Gas Natural Comprimido Vehicular). Asimismo, la
compañía posee una red secundaria de distribución de 8000 Km de tuberías en polietileno
de mediana densidad, que deriva de las redes primarias en las estaciones de distrito y se
extiende hacia los centros de medición de los clientes residenciales, comerciales y pequeños
establecimientos industriales, para conducir el gas a una presión máxima de 60 PSI. Estas
redes cumplen con las normas NTC 3728 (Instituto Colombiando de Normas Técnicas y
Certificación, 2011), NTC 1746 ( (Instituto Colombiando de Normas Técnicas y
5
Certificación, 2008) y ASME B31.8 (The American Society of Mechanical Engineers,
1999).
En este momento, esta red de distribución cuenta con tres estaciones City Gate de su
propiedad: La Paila y Hormiguero en el Valle del Cauca y Yarumos en el Cauca,
adicionalmente recibe gas de otras 24 estaciones reguladoras de puerta de ciudad que hacen
parte del Sistema Nacional de Transporte (SNT), de propiedad de la empresa Transportadora
de Gas Internacional S.A. Igualmente, cuenta con 69 estaciones de distrito, de las cuales 21
se encuentran ubicadas en Cali, 36 en municipios y 9 en corregimientos. Estas estaciones
permiten controlar y reducir la presión de entrega de la red de alta presión a la red de media
presión.
La compañía también presta el servicio de gas natural a través de sistemas de gasoducto
virtual. En la actualidad, atiende tres poblaciones con este sistema: dos en el Cauca, Villa
Rica y Santander de Quilichao y una en el Valle del Cauca, Buenaventura. A continuación,
se presenta un mapa general de la cobertura de servicio (Gases de Occidente S.A. E.S.P.,
2012):
6
1.1.4. Tipos de Estaciones que conforman la red de distribución
Como se indicó en la sección de la composición de la infraestructura del gas natural, todas
las fases de la cadena productiva, salvo la comercialización, incluyen equipos de regulación
de gas natural para obtener las presiones de operación requeridas en los sistemas de
distribución y llegar a todos los puntos de consumo, cumpliendo las especificaciones
adecuadas. A continuación se presentan los diferentes tipos de estaciones que hacen parte de
este proceso de distribución:
Figura 1-1 Cobertura de Servicio Gas Natural Valle del Cauca y Cauca.
Fuente: (Gases de Occidente S.A. E.S.P., 2012)
7
City Gate
Un City Gate es el punto de entrega del transporte de gas natural y el inicio de la red de
distribución, incluye equipos de filtrado y regulación de presión y medición. La función
principal de un City Gate es totalmente analógica a la de una subestación de transformación
eléctrica, es decir, de recibir un flujo de energía en alta tensión (o presión en el caso del gas
natural), reducir la tensión (o presión en el caso del gas), medir el flujo de energía y luego
dar inicio a la distribución.
.
Figura 1-2. Esquema General Estación Tipo City Gate
Fuente: (RAYCO Ltda., 2014)
El módulo de medición es de alta resolución, exactitud e integridad, que permite medir con
precisión los volúmenes recibidos. La información obtenida localmente es transmitida hasta
un control central, donde se consolidan todos los datos.
Estaciones de Regulación y Medición
Las estaciones de regulación y medición (ERM), son sistemas dedicados a acondicionar y
medir el gas natural que se entrega a un determinado punto de consumo y puede brindar las
siguientes funciones:
8
- Protección a los equipos conectados aguas abajo de la ERM,
- Acondicionar el gas natural que fluye por los equipos mediante filtros y separadores,
- Garantizar una presión de suministro homogénea,
- Medir el flujo de gas natural,
- Aumentar la temperatura del gas natural para mantener la integridad de los equipos
de la ERM.
Figura 1-3. Esquema General Estación Tipo ERM
Fuente: (RAYCO Ltda., 2014)
Estaciones de Gasoducto Virtual
En las estaciones de descompresión de gas natural para gasoducto virtual, se requiere una
serie de equipos y elementos para garantizar la seguridad de la operación y cumplir con las
funciones de toda ERM.
Debido a los altos costos de suministro e instalación de un gasoducto de transporte y/o
distribución, que oscila entre USD 600.000 y USD 2’000.000 por Km (Bernal Ortíz, 2009),
Colombia ha venido incursionando en sistemas no tradicionales conocidos como gasoductos
virtuales.
9
1.2. Regulación Mercado Mayorista Gas Natural – Resolución 089 de 2013
La Resolución CREG 089 de 2013 regula los aspectos comerciales del mercado mayorista
del gas natural, como parte del reglamento de operación del bien energético. Esta resolución
contiene el conjunto de disposiciones aplicables a las negociaciones que se realizan en los
mercados primario y secundario para el suministro y el transporte del gas natural utilizándolo
de manera efectiva como combustible.
1.2.1. Consideraciones
Mediante la resolución CREG 071 de 1999, la CREG adoptó el reglamento único de
transporte del gas natural RUT. Mediante este reglamento, se prevé la existencia del mercado
secundario de suministro y transporte de gas natural, el cual se basa en los sistemas de
información implementados por cada transportador a través de los boletines electrónicos de
operaciones.
Este mercado secundario, previsto en la regulación es físico, de tal forma que su desarrollo
depende de las gestiones que realizan los propios participantes del mercado que cuentan con
excedentes y aquellos que tienen desbalances en sus propias compras.
Dada esta premisa, con esta resolución se busca:
- Mejorar la disponibilidad de información (consumos hora – hora y diarios de cada
nodo de distribución).
Figura 1-4. Esquema General Estación Gas Virtual
Fuente: (RAYCO Ltda., 2014)
10
- Mejorar la liquidez a través de requisitos mínimos en los contratos de compra y venta
de gas natural.
- Buscar que los participantes estén regulados, inspeccionados, vigilados y controlados
por las entidades competentes.
Así mismo, las plantas de generación de energía a base de gas, están sujetas a la posibilidad
de re-despachos en el sector eléctrico, lo cual implica re-nominaciones, tanto de suministro,
como de transporte de gas natural, durante el día de gas, lo cual puede generar posibles
compensaciones a causa de la dinámica diaria de los participantes del mercado, situación
que justifica aún más la necesidad de tener disponible la información de consumo de cada
nodo de distribución, por cada integrante de la cadena de suministro de gas natural.
1.2.2. Objeto de la Resolución
Regular aspectos comerciales del mercado mayorista de gas natural, como parte del
reglamento de operación de Gas Natural.
Definir el conjunto de disposiciones aplicables a las negociaciones del suministro y del
transporte del gas natural, utilizado efectivamente como combustible en las aplicaciones que
se realizan en los mercados primario y secundario.
1.2.3. Conceptos Claves a Tener en Cuenta de la Resolución
Boletín Electrónico Central: Es una herramienta que usa el gestor del mercado para
desplegar la información transaccional y operativa que haya sido recopilada, verificada y
publicada, conforme a los lineamientos de la Resolución 089 de 2013. Es también una
herramienta que permite a los participantes del mercado, intercambiar información para la
compra y venta de gas natural y de capacidad de transporte de gas natural, dotando también
la publicidad y transparencia de las transacciones al mercado.
11
Día D-1: Es el día oficial de la Republica de Colombia, que va desde las 00:00 horas, hasta
las 24:00 horas, durante el cual se efectúa el suministro y el transporte de gas.
Día de Gas: Es el día oficial de la República de Colombia, que va desde las 00:00 horas,
hasta las 24:00 horas, durante el cual se efectúa el suministro y el transporte de gas.
Responsable de la Nominación de Gas: Será el comprador primario cuando este no haya
cedido sus derechos contractuales; o el comprador cesionario cuando hay suscrito la sesión
de derechos de suministro de gas.
Spread: Diferencia entre el precio de venta y el precio de compra de las ofertas que realiza
un promotor de mercado.
Gestor del Mercado. Es el responsable de la prestación de los servicios de gestión de
mercado primario y del mercado secundario, en los términos establecidos en la Resolución.
Este organismo se encarga de garantizar:
- Centralización de información transaccional y operativa, recopilando, verificando,
publicando y conservando la información sobre el resultado de las negociaciones
entre:
o Mercado Primario y mercado Secundario.
o Comercializadores y usuarios no regulados.
Así como toda la información operativa del sector de gas natural.
- Gestión del mecanismo de subasta en el mercado primario de gas natural.
- Gestión de los mecanismos de comercialización del mercado secundario de gas
natural, de acuerdo a los procedimientos de los artículos 41 (Ofertas de compra y
venta), 44, 45 y 46 (modalidades de úselo o véndalo a corto y largo plazo, de acuerdo
a demanda) de la resolución 089 de 2013.
- Gestión del mecanismo de subasta previsto para los contratos con interrupciones en
el mercado mayorista de gas natural.
12
De acuerdo a la información preliminar, Gases de Occidente S.A. E.S.P., hace parte del
mercado de gas natural, participando como comercializador del mercado secundario. Para
dar cumplimiento a esta resolución deben cumplirse los requerimientos de entrega de
información, de acuerdo al anexo 2 de esta resolución, como soporte a las transacciones de
compra y venta de gas natural, los cuales serán especificados en la próxima sección.
13
2. Capítulo 2
Contexto y Planteamiento de Requerimientos de la Actualización
2.1. Contexto del Proyecto
Para dar cumplimiento a los requerimientos de información solicitados por la Resolución
089 de 2013, Gases de Occidente S.A. E.S.P., ha generado la necesidad de actualizar su
plataforma SCADA para:
- La inclusión de todos los nodos regulación y distribución que se encuentran en la
actualidad para su supervisión y monitoreo, con el fin de asegurar la integridad del
gasoducto.
- Recolección de los registros hora-hora, diarios y máximos y mínimos para la nominación
al gestor de mercado del día D-1. Esta información debe estar disponible para su entrega
a más tardar a las 8:00AM, los 7 días de la semana.
- La generación de un reporte consolidado, con la sumatoria del consumo generado por
todos los nodos de distribución, a partir de la variable del Volumen Corregido del Día
Anterior (Previous Day). Este reporte debe ser entregado a las 7:00AM, del día de
nominación.
- Como parte del ejercicio de subasta, compra y venta del bien energético, los usuarios no
regulados deben contar con la información del volumen corregido del transcurso del día,
por tanto, se requiere que la variable de Volumen Corregido Actual (Current Day), esté
disponible y actualizada cada hora para su respectiva consulta en la plataforma web que
se dispondrá para esta finalidad.
2.2. Panorama Actual del Sistema SCADA
2.2.1. Antecedente Histórico
El propósito del sistema SCADA de Gases de Occidente S.A. E.S.P. en sus inicios, fue la
programación y puesta en marcha del centro de control para monitorear y recolectar datos
14
actuales de 20 sitios de Cali conocidos como Estaciones Reguladoras de Medición (ERM),
40 sitios ubicados en la misma ciudad y algunos municipios del Valle del Cauca, conocidos
como Estaciones de Servicio (EDS). A través del software supervisorio se monitoreaba:
- Presión de entrada,
- Presión de salida,
- Presión de la estación,
- Protección catódica,
- Temperatura del fluido y
- Flujo
Esto se realiza con equipos MOSCAD de Motorola que se comunican al Centro de Control
por medio de radio en la banda VHF y estos datos eran concentrados en un MCPM (Equipo
para recibir las lecturas de los equipos remotos). El software supervisorio es llamado Intouch
versión 7.5 del fabricante Wonderware.
Por otro lado, se contaba con otro SCADA proporcionado por la empresa NIMOCOM
llamado Phanteon. Este es el encargado de recopilar los datos de los clientes industriales y
City Gates, cuyos correctores electrónicos son tipo Eagle. La comunicación se realiza vía
telefónica.
En una fase preliminar se realizó el reemplazo de los dos anteriores software supervisorios
(Intouch 7.5 y Phanteon), por la herramienta de software Wonderware System Platform. En
esta primera versión, el centro de control está configurado solo para una sección de las
estaciones que cuentan con equipo Motorola, debido su criticidad a nivel operativo en la red
del gasoducto.
Este centro de control estaba organizado de forma distribuida, tal como se presenta en la
Figura 2-1, compuesto por los siguientes elementos:
Compuesto por cinco CPUs 420 MOSCAD de Motorola y el Servidor OPC de Motorola. La
comunicación entre el OPC Server y los equipos MOSCAD se realiza a través de conexión
Ethernet de 10MBPS.
15
Estación de Ingeniería (AppServer IO Server)
Servidor encargado de desplegar y procesar todos los objetos de la aplicación del sistema en
general. Es en esta estación donde se administran los permisos, las alarmas, los eventos,
entre otros servicios. Además es el encargado de ejecutar cualquier proceso que sea
programado.
Historian - Galaxia Repository.
Servidor encargado de almacenar y gestionar toda la base de datos, tanto de los datos
almacenados del proceso (Historian), como de los objetos de la aplicación (Galaxia
Repository).
Nodos de Usuario
Estaciones encargadas de:
o Visualización del proceso.
o Ejecución de servicios de herramienta MOPC.
o Reportes Active Factory
System Platform Server Environment.
SCADA1
2 Threads2GB RAM16 GB DD
Puertos USB
SOFTWARE INSTALADO Wonderware Application Server- Microsoft Windows Server 2003- Windows Office 2003.- Microsoft SQL Server 2005- Wonderware Application Server (4500 I/O)- Galaxy Repository.- Wonderware Historian Server (4500 Tag)
SCADA2
4 Threads4 GB RAM40 GB DD
SOFTWARE INSTALADO Wonderware Information Server- Microsoft Windows Server 2003- Wonderware Information Server Portal - Info Server Advanced Client Per Name Used (5 Users) v3.0.
System Platform Development and Client Environment.
SCADAXP03
1 Threads1GB RAM4 GB DD
SOFTWARE INSTALADO Intouch For System Platforn / Wonderware Historian Client- Microsoft Windows 7 Professional SP 1- Windows Office 2010.- Wonderware Historian Client.- Intouch Viewer.
SCADAXP02
1 Threads1 GB RAM4 GB DD
SOFTWARE INSTALADO ArchestrA IDE / Intouch Window Maker y Viewer.- Microsoft Windows XP SP2- Windows Office 2003.- Active Factory- Industrial Application Server IDE-Intouch 9.5 Maker and Viewer
Motorola OLE Process Control 3.00.08
Dominio Gases de Occidente
Archivos
Grupos de Usuarios
Seguridad
Red global
Front End Processors MOSCAD 420 Motorola
MOSCAD 4201.
MOSCAD 4202.
MOSCAD 4203.
MOSCAD 4204.
MOSCAD 4205.
Comunicación Radio.
Comunicación Conmutada
Figura 2-1. Topología Centro de Control Gases de Occidente S.A. E.S.P.
Fuente: (RAYCO Ltda., 2008)
16
2.3. Revisión Estructura Actual
Como se describió en la sección anterior, el centro de control está compuesto por dos
componentes, uno a nivel de hardware y el otro a nivel de software, que en conjunto,
permiten la adquisición, procesamiento y almacenamiento de la información suministrada
por las estaciones remotas (datos actuales y solicitud por demanda de los registros de
consumo o volumen corregido), tal como se observa en la Figura 2-1. A continuación se
presenta en detalle la estructura que hace parte del Centro de Control del sistema SCADA
actual de Gases de Occidente S.A. E.S.P.
2.3.1. Componente Hardware
MOSCAD FIU Serie 420
La MOSCAD FIU es una unidad intermediaria que conecta el centro de control con los
equipos MOSCAD remotos que se encuentran en la red del sistema SCADA. En efecto se
comporta como una puerta de enlace entre las dos partes de la red y se comunica con las
RTU usando el protocolo MDLC, propietario de Motorola, el cual se basa en las siete capas
del modelo OSI y es adaptado para las comunicaciones SCADA. Este protocolo provee un
soporte en la red y multiples canales lógicos por cada puerto físico, habilita simultáneamente
sesiones como:
- Centro de Control a RTU
- RTU a RTU
También permite a cada RTU ejecutar simultáneamente varias sesiones de comunicación,
tales como el intercambio de datos, monitoreo en línea y diagnóstico. Las comunicaciones
pueden ser a través de la radio, la telefonía fija y con otro canal MDLC (Motorola Solutions
Inc., 2009).
17
Modulo CPU
En este módulo se concentra la mayor parte de las funcionalidades de la FIU. Tiene un
procesador Motorola 68302 CMOS de 16/32-bit, RAM, ROM y memoria flash, batería de
reserva de litio, reloj de tiempo real y sus respectivas interfaces de E/S y el manejo de la
comunicación de la RTU. Este módulo puede ser programado, utilizando la herramienta
Programming Tool-Box.
La serie de módulos CPU 400 utiliza memoria Flash a cambio de la memoria EPROM,
permitiendo un mayor almacenamiento para los archivos de código fuente comprimido.
Un chip de reloj en tiempo real se encuentra en el módulo de la CPU y ofrece años
(incluyendo el año bisiesto), mes, día, fecha, hora, minuto, segundo, y el apoyo milisegundos
a la aplicación. Los mensajes de diagnóstico o de error contienen el momento de la
ocurrencia; eventos de entrada pueden ser en tiempo marca; tareas de aplicaciones sensibles
al tiempo se pueden crear. Los relojes dentro de la RTU pueden ser sincronizados por una
descarga manual de la hora de la caja de herramientas, una descarga automática de la hora
desde el Administrador de SCADA, o por medio de un mensaje automático de otra RTU con
un receptor GPS.
Módulos de CPU múltiples
El estándar RTU contiene un único módulo CPU que controla todas las actividades en la
RTU. Para la actual implementación, se tienen disponibles 5 módulos, que en este caso
permiten manejar simultáneamente 4 canales de comunicación tipo Red Conmutada
(módems dial-up) y un canal de radiocomunicaciones en la banda VHF.
De acuerdo a esto, se facilita el establecimiento de una red de comunicación de datos hibrida
hacia las estaciones remotas y re-direccionar la información hacia la red ethernet de la
compañía para que sea entregada al servidor que realiza las tareas de gestión y
procesamiento.
Dadas las múltiples velocidades de señalización de datos, permite una mayor disponibilidad
de usar varios tipos de enlaces. Velocidades de datos más bajos son usadas cuando el ancho
18
de banda de la conexión se reduce, ya sea por su diseño o por las leyes del país del usuario
o se sacrifica la velocidad de datos para lograr un mayor alcance de las comunicaciones
(Motorola Solutions Inc., 2009).
2.3.2. Componente Software
Wonderware System Platform, es una plataforma escalable para requerimientos de
procesamiento de información y automatización industrial, relacionados con soluciones de
software SCADA, HMI de supervisión, Manufactura y Administración de Operaciones.
En el núcleo central de Wonderware System Platform, se encuentra el “modelo de la planta”,
que es la representación lógica de los procesos físicos que están siendo controlados o
supervisados, esto mediante la tecnología de objetos ArchestrA, los cuales permiten que la
configuración, el registro de datos, la entrega y el mantenimiento tanto de la información
histórica como de tiempo real sea más simple.
Adicionalmente se cuenta con un historizador de procesos de alto desempeño con
almacenamiento de historia de producción, compresión eficiente de los datos y
autoconfiguración de almacenamiento histórico que elimina la duplicidad de esfuerzos.
Las herramientas que hacen parte de esta plataforma, están distribuidas en varios equipos y
servidores, dada su filosofía de trabajo distribuido. A continuación se presentan las tareas
específicas que cada equipo desempeña:
Nodo SCADAXP02
Contiene las herramientas ArchestrA IDE e Intouch Window Maker y Viewer:
Archestra IDE (Entorno de Desarrollo Integral): Es una arquitectura de software de
información y automatización diseñada para integrar y extender la vida de los sistemas
heredados, aprovechando las tecnologías de software y los estándares abiertos más
avanzados de la industria. Permite el diseño y desarrollo integrado para la configuración de
objetos del modelo planta y la infraestructura subyacente.
19
Intouch Window Maker y Viewer: A través de esta herramienta se realizan las funciones de
visualización gráfica que permiten realizar la gestión de operaciones, control y optimización.
Su extensión Maker permite realizar la edición de gráficos, la definición de scripts para
extender y personalizar la aplicación, de acuerdo a las necesidades específicas de la planta y
el seguimiento de las alarmas generadas en la operación. La extensión viewer es la versión
ejecutable del maker, la cual no permite su edición en línea.
Nodo SCADAXP03
Contiene las herramientas Wonderware Historian Client e Intouch Window Viewer:
Wonderware Historian Client: Esta herramienta proporciona la presentación de datos y
tendencias, permitiendo al operador la consulta rápida de la información que se ha
almacenado en el Historian, generando reportes de apoyo para la toma de decisiones en la
operación.
Intouch Window Viewer: Al igual que el servidor SCADAXP02, se cuenta con un nodo de
visualización de respaldo, con el fin de garantizar la continuidad de la operación, en caso de
que el equipo 1 presente algún tipo de novedad que pueda interrumpir su funcionalidad.
Nodo SCADA 1
Servidor dedicado a Wonderware Application Server y Wonderware Historian Server.
Wonderware Application Server: Es el entorno central de la aplicación SCADA, en esta
herramienta se realizan las tareas de gestión de todos los componentes que hacen parte del
proceso de adquisición, procesamiento, almacenamiento y consulta de las variables del
modelo de planta.
Wonderware Historian Server: Es un historiador de procesos de alto rendimiento, que
permite almacenar grandes volúmenes de datos generados a partir de las instalaciones de la
planta de proceso. Esta herramienta es el complemento para Wonderware InTouch
permitiendo que los datos críticos del proceso sean capturados y estén disponibles para el
análisis de solución de problemas del proceso en caso de una necesidad putual.
20
Nodo SCADA 2
Servidor dedicado a Wonderware Information Server:
Wonderware Information Server: Es una herramienta que permite la presentación de los
datos de producción, a través de una solución web, de forma segura y sin intervención directa
en el proceso. Los usuarios que tienen acceso, tienen vistas personalizadas de la operación,
de acuerdo a su perfil.
Adicionalmente al software SCADA Wonderware, en el nodo SCADAXP2, se encuentra
instalada la herramienta M-OPC, la cual usa una arquitectura cliente / servidor estándar para
facilitar las comunicaciones entre los componentes de la red de centro de control y el FIU.
2.3.3. Esquema General Entrega de Información
Inicialmente este centro de control se había configurado para supervisión y monitoreo de las
variables actuales de 20 Estaciones Reguladoras de Medición (ERM) de Distrito, ubicadas
en el Distrito de Cali y 40 Estaciones de Servicio de Gas Vehicular ubicadas en diferentes
municipios del Valle del Cauca y norte del Cauca. Adicionalmente cuenta con la opción de
solicitar por demanda de los registros diarios y horarios (40 días) de la base de datos propia
de cada RTU, por parte del ingeniero de balance de gas.
Para la comunicación con las 60 estaciones remotas existen dos medios de comunicación, el
primero que es a través de comunicación conmutada mediante módems dial-up y el segundo
a través de un enlace de radiocomunicaciones en la banda VHF.
Dada su criticidad en la red del gasoducto, las remotas ERM-Cali, están configuradas con
los dos medios de comunicación, siendo el enlace de radiocomunicaciones el medio principal
y el de la red conmutada como el medio secundario, esto debido a que la disponibilidad del
segundo medio, depende directamente del operador del servicio.
Bajo estas condiciones, la actualización de las variables de medición en el centro de control,
se realiza mediante dos caminos:
21
- El polling o las preguntas periódicas desde el centro de control a cada una de las
remotas, el cual para cada una de las estaciones se encontraba en promedio cada 20
minutos, dado que el FIU está configurado para realizar las preguntas de forma
cíclica y teniendo en cuenta la disponibilidad del canal conmutado (para el caso de
las EDS).
- Reporte de la RTU mediante excepción, en el cual el remoto envía la actualización
de sus variables de medición, cuando una de estas presenta un cambio de estado (para
el caso de las señales digitales) o sobrepasa su rango de operación ya sea por encima
o por debajo de parámetros configurados (para el caso de las variables análogas).
Cada estación remota está configurada de tal forma, que permite la medición y corrección
volumétrica del bien energético. Esta medición genera un reporte consolidado del consumo
hora – hora, diarios y los valores máximos y mínimos de los parámetros de medición en
cada corte horario, de los últimos 40 días de medición, información que se almacena en una
base de datos de la aplicación de la RTU.
El ingeniero de balance de gas, puede solicitar por demanda esta información, mediante la
gestión remota de la RTU. Este procedimiento puede tardar entre 5 a 10 minutos,
dependiendo de la disponibilidad del canal y cuando es usado, está completamente dedicado
a esta actividad.
2.3.4. Limitaciones Plataforma vs. Nuevos Requerimientos
Estas dos actividades (actualización de variables actuales y solicitud de consolidado de
registros), era sostenible para la cantidad de estaciones remotas a las cuales fue configurado,
sin embargo, a medida que avanzó el crecimiento de la red de acero y por ende la
construcción de nuevas estaciones reguladoras que se debían integrar al sistema SCADA
para su supervisión y monitoreo, se comenzaron a presentar las siguientes limitaciones:
22
- Al incrementar el número de sitios por supervisar, (de 60 a 102) el ciclo de polling
se ve afectado al pasar de un tiempo promedio de 20 minutos a tiempos que oscilan
entre los 30 y 40 minutos.
- Como se menciona anteriormente, la solicitud por demanda del consolidado de
registros horarios dura aproximadamente entre 5 a 10 minutos, esto significa que por
cada petición, uno de los canales dedicados no estaría disponible para la actividad de
ciclo de polling, lo que afecta aún más la actualización de los datos actuales y los
posibles retardos en las excepciones, generando inestabilidad en la integridad del
gasoducto.
- El incremento de las estaciones remotas, ha generado que a nivel de procesamiento
de datos entre la unidad FIU – MOPC – DAServer, se presenten perdidas de
información, debido a que las herramientas y los recursos de máquina no son
suficientes para el volumen de datos que se requieren historizar.
- La metodología de solicitud por demanda de los registros, pasa a ser obsoleta, dadas
las condiciones generadas por la CREG mediante la resolución 089 de 2013, no es
viable contar con la información de manera oportuna.
- La petición de registros, no puede realizarse de manera parcial o definida en un rango
de fechas requerido, actualmente esta petición trae el historial de los últimos 40 días,
de los cuales para cada día de nominación, solo serían importantes el día más
reciente, el resto de información ya fue solicitada previamente.
- No se está historizando las variables Previous Day y Current Day de las estaciones
remotas, estos parámetros se hacen necesarios para los reportes consolidados que
solicita la Resolución 089 de 2013.
De acuerdo a lo expuesto previamente, se hace necesario realizar una actualización de todo
el sistema SCADA (Centro de Control – Medios de Comunicación – Estaciones Remotas),
que permita alcanzar los objetivos, que se presentan en la Tabla 2-1 :
23
Tabla 2-1. Relación de aspectos a revisión y objetivos a alcanzar en la actualización.
Aspecto por Revisar Objetivo a Alcanzar
Tiempos de polling variables actuales. En este
momento se encuentra en promedio entre 30 y 40
minutos.
Disminuir el tiempo de polling de 10 a 15 minutos.
Petición de Registros por demanda del usuario. Eliminar la petición por demanda y generar el envío
de registros de manera automática al centro de
control.
Parámetros de medición sin historizar. Revisión e historización de parámetros de medición
requeridos para los reportes consolidados solicitados
por la Resolución 089 de 2013.
Disponibilidad de registros horarios, diarios,
máximos y mínimos para la nominación y subasta
diaria del bien energético.
Cumplimiento de la hora de entrega de la
información consolidada de todas las estaciones
remotas. 8:00AM
Fuente: Elaboración Propia
24
3. Capítulo 3.
Estructura de Datos – Modelo Planta
3.1. Tipos de Estaciones
La red de distribución de Gas Natural de Gases de Occidente S.A. E.S.P., está conformada
básicamente por los siguientes tipos de estación:
- City Gate
- Estación Reguladora de Medición
- Estación Reguladora de Medición Remota o Gas Virtual
- Estación de Servicio GNV
- Cliente Industrial
- Válvula de Seccionamiento.
3.1.1. City Gate
Un City Gate es el punto de entrega del transporte de gas natural y el inicio de la red de
distribución, incluye equipos de filtrado y regulación de presión y medición. La función
principal de un City Gate es totalmente analógica a la de una subestación de transformación
eléctrica, es decir, de recibir un flujo de energía en alta tensión (o presión en el caso del gas
natural), reducir la tensión (o presión en el caso del gas), medir el flujo de energía y luego
dar inicio a la distribución.
El City Gate comprende un sistema de filtrado, regulación de presión y medición para recibir
el gas entregado por la empresa transportadora y así controlar su presión hasta niveles que
corresponden al servicio de la red de distribución.
25
Figura 3-1 Esquema General Estación Tipo City Gate
Fuente: (RAYCO Ltda., 2014)
El módulo de medición es de alta resolución, exactitud e integridad, que permite medir con
precisión los volúmenes recibidos. La información obtenida localmente es transmitida hasta
un control central, donde se consolidan todos los datos.
Cuenta con reguladores de presión, los cuales regulan desde un valor alto requerido para la
transmisión de gas hacia un valor más bajo necesario para el consumo. Estos reguladores de
presión son equipos mecánicos de alta confiabilidad y de relativa simplicidad mecánica y
por eso es casi improbable las fallas en su funcionamiento. Adicionalmente se cuenta con
reguladores idénticos en serie (uno de ellos conocido como monitor). El “monitor” está
abierto y dispuesto a entrar en funcionamiento, cuando detecte una subida anormal de la
presión, en un rango de más o menos del 5%.
Debido a la carencia de olor que presenta el gas natural y para facilitar su percepción en caso
de fugas, se inyecta un producto químico (conocido como Mercaptano) en el flujo del gas a
ser distribuido. Este compuesto se aplica en muy pequeñas concentraciones (partes por
millón), con la finalidad de darle al gas un olor característico fácilmente identificable al
olfato. Este método permite detectar una posible fuga mucho antes de que la concentración
del gas en el aire alcance los límites de mezcla peligrosa.
26
Variables que intervienen
Para este tipo de estación, se pueden identificar las siguientes variables de medición, tanto
análogas como digitales:
Tabla 3-1 Variables Actuales Típicas de una estación tipo City Gate
Análogas Presión de Entrada
Presión Intermedia
Presión de Medición
Temperatura
Flujo
Factor de Corrección
Volumen Corregido Actual
Volumen Corregido Acumulado
Digitales de Entrada Intrusión Cuarto de Control
Estado de Actuador
Falla de Suministro Eléctrico AC
Digitales de Salida Cierre de Actuador
Fuente: Elaboración Propia
3.1.2. Estaciones de Regulación y Medición
Las estaciones de regulación y medición (ERM), son sistemas dedicados a acondicionar y
medir el gas natural que se entrega a un determinado punto de consumo y tiene las siguientes
funciones:
a. Brindar protección a los equipos conectados aguas abajo de la ERM.
b. Acondicionar el gas natural que fluye por los equipos mediante filtros y separadores.
c. Garantizar una presión de suministro homogénea en todos los puntos de consumo.
d. Medir el flujo de gas natural.
e. Odorizar el gas natural para modificar sus propiedades físicas.
f. Contener el gas natural y garantizar su flujo hacia los puntos de consumo.
g. Aumentar la temperatura del gas natural para mantener la integridad de los equipos
de la ERM.
27
Figura 3-2. Esquema General Estación Tipo ERM
Fuente: (RAYCO Ltda., 2014)
Variables que intervienen
Para este tipo de estación, se pueden identificar las siguientes variables de mediciones tanto
análogas como digitales:
Tabla 3-2 Variables Actuales Típicas de una estación tipo Reguladora y Medición
Análogas Presión de Entrada
Presión de Medición
Presión de Salida
Temperatura
Flujo
Factor de Corrección
Volumen Corregido Actual
Volumen Corregido del día anterior
Volumen Corregido Acumulado
Protección Catódica
LEL – Atmósfera Explosiva
Digitales de Entrada Intrusión Gabinete de Control Local
Intrusión Estación Reguladora
Estado de Actuador
Falla de Suministro Eléctrico AC
Digitales de Salida Cierre de Actuador
Fuente: Elaboración Propia
28
3.1.3. Estaciones de Gasoducto Virtual
En las estaciones de descompresión de gas natural para gasoducto virtual, se requiere una
serie de equipos y elementos para garantizar la seguridad de la operación y cumplir con las
funciones de toda ERM. Sus elementos son:
- Tubería y accesorios: Diámetro y SCH dependiendo de la presión de la línea y del
volumen.
- Válvulas de corte: Elementos de manipulación y control del flujo de gas natural.
- Filtro y separador: Elemento principal de limpieza para contener las partículas e
impurezas con que pueda llegar el gas natural.
- Sistema de calentamiento: Para contrarrestar el efecto Joule-Thomson en cada una
de las etapas de regulación, en el cual el gas natural pierde temperatura debido al
cambio abrupto de presión, el sistema de calentamiento opera con gas natural tomado
de la ERM, el cual llega a un calderín para calentar el agua y generar un intercambio
de calor gas natural – agua caliente mediante un intercambiador de calor de coraza y
tubo.
- Regulador: Elemento que se encarga de reducir la presión en el gas natural
manteniendo el caudal constante.
- Válvula de corte (Slam Shut Off): Sistema de corte automático por sobre-presión y
sub-presión, el cual puede encontrarse incorporado al regulador o independiente
sobre la línea.
- Válvula de alivio: Esta válvula permite aliviar un volumen mínimo de gas natural,
cercano al 10%, para prevenir el disparo repentino de la válvula Slam Shut-Off.
- Medidor: Instrumento de medición de volumen entregado a los usuarios para su
consumo.
- Instrumentación, accesorios y elementos de telemetría.
El mecanismo permite llevar el gas natural del punto A al punto B, mediante vehículos de
transporte en los cuales es almacenado el gas a alta presión (220 Bar o 3200 PSI
aproximadamente), manteniendo su estado gaseoso, utilizando los sistemas de compresión
de gas natural vehicular.
29
Una vez el gas natural es almacenado en cilindros especialmente diseñados para soportar la
presión, puede ser llevado por las carreteras a puntos alejados hasta 200Km, donde será
distribuido en redes de polietileno o acero carbono una vez que pasa por estaciones de
regulación conocidas como estaciones de descompresión.
Figura 3-3. Esquema General Estación Gas Virtual
Fuente: (RAYCO Ltda., 2014)
Variables que intervienen
Para este tipo de estación, se pueden identificar las siguientes variables de mediciones tanto
análogas como digitales:
Tabla 3-3. Variables Actuales Típicas de una estación tipo Gasoducto Virtual
Análogas Presión de Entrada
Presión de Medición - Salida
Temperatura
Flujo
Factor de Corrección
Volumen Corregido Actual
Volumen Corregido del día anterior
Volumen Corregido Acumulado
Digitales de Entrada Intrusión Cuarto de Control
Estado de Actuador
Falla de Suministro Eléctrico AC
Digitales de Salida Cierre de Actuador
Fuente: Elaboración Propia
30
Este tipo de estación, dados los múltiples procesos que realiza, tiene una mayor cantidad de
variables análogas y digitales, pero para el alcance de este proyecto, solo se han identificado
las correspondientes a: la regulación, la vigilancia y la corrección volumétrica.
3.1.4. Estaciones de Servicio GNV y Clientes Industriales
Las estaciones de Servicio GNV y los Clientes Industriales, son sistemas dedicados a
acondicionar y medir el gas natural que se entrega a un determinado punto de consumo para
grandes consumidores de gas natural. Estas estaciones cumplen con las siguientes funciones:
a. Brindar protección a los equipos conectados aguas abajo de la ERM.
b. Acondicionar el gas natural que fluye por los equipos mediante filtros y separadores.
c. Garantizar una presión de suministro homogénea en todos los puntos de consumo.
d. Medir el flujo de gas natural.
e. Contener el gas natural y garantizar su flujo hacia el punto de consumo.
Su configuración y diseño mecánico e hidraúlico es similar a una estación reguladora de
medición o ERM.
Figura 3-4. Esquema General Estación Tipo ERM
Fuente: (RAYCO Ltda., 2014)
31
Variables que intervienen
Para este tipo de estación, se pueden identificar las siguientes variables de mediciones tanto
análogas como digitales:
Tabla 3-4. Variables Actuales Típicas de una estación tipo GNV y CLientes Industriales
Análogas Presión de Medición
Temperatura
Flujo
Factor de Corrección
Volumen Corregido Actual
Volumen Corregido del día anterior
Volumen Corregido Acumulado
Digitales de Entrada Falla de Suministro Eléctrico AC
Fuente: Elaboración Propia
3.1.5. Válvulas de Seccionamiento
Todas las líneas de transporte y redes de distribución a alta y media presión deben tener
válvulas espaciadas de tal forma, que en caso de emergencia se minimice el tiempo de cierre
de un tramo o sección de la línea. La separación de las válvulas está determinada por la
presión de operación, el tamaño de la red y las condiciones físicas locales.
Figura 3-5. Esquema general Estación Tipo Válvula de Seccionamiento
Fuente: (RAYCO Ltda., 2014)
32
Este tipo de válvulas de acuerdo a su diseño electro-neumático, permiten realizar cierre
remoto, pero su apertura debe realizarme manualmente.
Variables que intervienen
Para este tipo de estación, se pueden identificar las siguientes variables de mediciones tanto
análogas como digitales:
Tabla 3-5. Variables Actuales Típicas de una estación Valvula de Seccionamiento.
Análogas Presión de Entrada
Presión de Salida
Digitales de Entrada Intrusión Gabinete de Control Local
Intrusión Estación Reguladora
Estado de Actuador
Digitales de Salida Cierre de Actuador
Fuente: Elaboración Propia
3.1.6. Modelo Generalizado de Estación Típica
Dado el crecimiento de la red de distribución y la inclusión de estaciones con variantes en
su diseño y funcionalidad, se hizo necesario realizar una identificación detallada de las
variables de medición, tanto las de tipo análogo como las digitales, esto con el fin de definir
una estructura estándar para la adquisición de los datos y su respectivo tratamiento, a nivel
de remota, medio de comunicación y centro de control.
Para el proceso de actualización del sistema SCADA de GDO, se ha dado como prioridad el
tratamiento de las variables y datos asociados a la nominación de gas natural. Las variables
de medición análogas que se han dado como prioridad han sido las que se presentan en el
siguiente cuadro comparativo:
Tabla 3-6. Relación de Variables Análogas Comunes para los diferentes tipos de estaciones.
Variable Análoga Tipo de Estación
City Gate ERM GV EDS y CI Válvula
1 Flujo X X X X N/A
2 Presión de Medición X X X X N/A
3 Temperatura de Medición X X X X N/A
4 Volumen Corregido Día Anterior X X X X N/A
5 Volumen Corregido Actual X X X X N/A
6 Factor de Corrección X X X X N/A
7 Volumen Corregido Acumulado X X X X N/A
8 Presión Entrada X X X N/A X
9 Atmósfera Explosiva X X N/A N/A N/A
33
10 Protección Catódica X X N/A N/A N/A
11 Presión Salida X X X N/A X
12 Presión Intermedia X N/A N/A N/A N/A
Fuente: Elaboración Propia
En cuanto a las variables digitales, se incluirán las asociadas principalmente a la supervisión
de componentes de la estación reguladora y la vigilancia del sitio. De acuerdo a esto, se han
considerado las siguientes:
Tabla 3-7. Relación de Variables Digitales Comunes para los diferentes tipos de estaciones.
Variable Digital Tipo de Estación
City Gate ERM GV EDS y CI Válvula
1 Intrusión Estación Reguladora N/A X N/A N/A X
2 Intrusión Gabinete de Control Local X X X N/A X
3 Estado de Actuador X X N/A N/A X
4 Estado Válvula de Alivio N/A X N/A N/A N/A
5 Falla AC X X X X N/A
6 Inundación Estación N/A X N/A N/A N/A
Fuente: Elaboración Propia
Adicionalmente, ya que una buena parte de las estaciones reguladoras tienen un actuador en
su proceso, se debe tener en cuenta el elemento de control de cierre remoto, el cual se realiza
mediante accionamiento digital. Esta señal se considerará a nivel de remota como una salida
digital y a nivel de centro de control y comunicaciones como el envío de un comando de
control, debidamente encriptado.
Tabla 3-8. Relación de Variables Digitales para control de los diferentes tipos de estaciones.
Variable Digital de Salida Tipo de Estación
City Gate ERM GV EDS y CI Válvula
1 Accionamiento cierre actuador X X N/A N/A X
Fuente: Elaboración Propia
3.2. Medición Volumétrica
Bajo condiciones nominales de operación, el gas natural se encuentra en estado gaseoso a su
paso por las tuberías que lo transportan, es decir, que no tiene un volumen y forma definida,
salvo por el conducto que lo contiene, posee una masa constante, la cual se contrae o se
expande de acuerdo a las fuerzas que actúen sobre este y su comportamiento físico es
modelado matemáticamente mediante la Ley de los gases ideales.
34
El control y supervisión de las variables de proceso, buscan garantizar la calidad,
confiabilidad y seguridad del proceso, pero un componente de gran importancia en los
procesos de distribución de gas natural es la medición fiscal, siendo este mecanismo, el
vínculo de transacción entre los proveedores, vendedores y usuarios finales. Esto se realiza
mediante sistemas de medición de gas natural de diferentes tipos.
Para asegurar una correcta medición de flujo de gas natural, debe recurrirse a conceptos
estadísticos, variables de presión temperatura, cromatografía, densidad y otros factores tal
como se observa en la Figura 3-6 que llevan a preguntar, ¿Cuál es el medidor más adecuado
para estimar una correcta medición?
Medición de Gas Natural
Composición
Software e Instrumentación
Recursos Humanos
Instalación
Otros
Factores Ambientales
Calibración
Tipo de Medidor
Figura 3-6. Factores que afectan una medición
Fuente: (Ecopetrol, 2010)
3.2.1. Medidores de Flujo Volumétrico
Este tipo de medidores son los más usados en la industria, comercio y domicilios, por su
combinación única de especificaciones técnicas, precio y duración. Entre sus características
se encuentran:
- Utilizan un principio de medición volumétrica para determinar el caudal de gas
natural que pasa por el medidor.
- Se pueden clasificar en tres grandes grupos:
35
o Desplazamiento Positivo o Rotativos
o Velocidad o Turbina
o Inferenciales o Diafragma
- El error de la medición es menor al 0.5% durante operación normal
En la siguiente tabla se relaciona las características principales de los medidores de flujo
volumétrico y se realiza una comparación entre ellos, siendo uno (1) el nivel máximo y tres
(3) el nivel mínimo:
Tabla 3-9.. Tabla Comparativa de medidores volumétricos (Información recuperada de Itron/Actaris y
consolidada por el autor)
Criterio de Comparación Diafragma Rotativo Turbina
Precisión 2 1 1
Caudal De Arranque 1 2 3
Rangueabilidad 1 2 3
Poca Sensibilidad Al Flujo Variable 1 1 2
Sensibilidad A Carga Pulsante 1 1 2
Aviso Automatico De Falla 2 1 3
By-Pass En Caso De Falla 2 3 1
Metrología Fácil De Verificar 1 2 2
Tamaño 2 1 1
Montaje Directo 2 1 1
Emisión De Pulsos De Baja Frecuencia 3 2 1
Emisión De Pulsos De Alta Frecuencia 0 2 1
Costo De Instalación 2 1 1
Costo De Mantenimiento Y Re calibración 1 3 2
Fuente: Elaboración Propia
3.2.2. Factor de Corrección y Correctores Electrónicos de Volumen
Dado que las condiciones volumétricas en el gas natural cambian permanentemente de
acuerdo a diferentes factores que la componen, como son la presión, la temperatura, la
densidad o la composición del fluido, se hace necesaria la instalación de equipos auxiliares
conocidos como correctores electrónicos de volumen.
Estos equipos, conocidos también como electro-corrector, reciben una señal de pulsos de
alta frecuencia (HF) o baja frecuencia (LF) proveniente del medidor, una señal de presión
proveniente de un transductor de presión, una señal de temperatura proveniente de una
termocupla y la composición del gas natural o cromatografía, con esta información aplica un
36
modelo de cálculo tomado de la Ley de Gases Reales para convertir en “tiempo real” el
volumen bruto que pasa por la tubería en un volumen corregido.
𝐹𝑐 = [𝑃𝑡𝑟𝑎𝑏𝑎𝑗𝑜 (𝐵𝑎𝑟) + 𝑃𝑎𝑡𝑚𝑧𝑜𝑛𝑎(𝐵𝑎𝑟)
𝑃𝑟𝑒𝑓 (𝐵𝑎𝑟)] ∗ [
273.15 + 15.6
273.15 + 𝑇𝑡𝑟𝑎𝑏𝑎𝑗𝑜 (°𝐶)]
Estos equipos pueden ser utilizados en cualquier instalación donde se tenga un medidor de
flujo volumétrico.
Criterios de Selección de Medidores.
Para la selección adecuada de un medidor correcto, se deben tener en cuenta los siguientes
criterios de selección.
- Tipo de aplicación: Fiscal, No Fiscal, Transferencia de Custodia, entre otros.
- Tipo de caudal a medir: Másico y/o volumétrico.
- Cantidad y característica del flujo a medir.
- Presión y Temperatura de operación.
- Composición del gas natural; Impurezas, coexistencia de estados.
- Facturación: Factor fijo, telemedida, descarga de datos.
- Unidades de medida.
- Condiciones de instalación (vertical, horizontal, tensiones)
- Rangeabilidad
- Precisión
- Capacidad de recalibración.
- Aspectos legales y normatividad.
Los sistemas de medición de gas de transferencia de custodia con el fin de garantizar
confiabilidad en los resultados deben cumplir la normatividad que ha sido desarrollado bajo
la dirección de organismos internacionales que basados en pruebas experimentales han
definido los criterios para su montaje, operación y verificación. (Ecopetrol, 2010)
Dado que Ecopetrol y los respectivos sistemas de transporte y distribución deben cumplir el
RUT (Resolución CREG 077 de 1999 y posteriores resoluciones que la modifiquen), en el
numeral 5.3.1 se definen los elementos que componen el sistema de medición y fija la
obligatoriedad de usar medidores homologados por la Superintendencia de Industria y
Comercio de conformidad con el decreto 2269 de 1993 o las respectivas recomendaciones
de la AGA.
37
Para el caso de Gases de Occidente S.A. E.S.P., debido que en la configuración de sus
estaciones reguladoras tienen medidores tipo turbina y no tienen incluidos densímetros en
su instrumentación, se regirán bajo los siguientes estándares:
- Reporte AGA 7 (Requerimientos de Instalación para la Medición de Gas Natural
usando medidores tipo turbina.)
- Reporte AGA 8 (Cálculo del factor de supercompresibilidad)
- API MPMS 21.1 (Medición electrónica de gas)
3.2.3. Medición Tipo Turbina, AGA 7.
Descripción del medidor tipo turbina
El objetivo de una turbina es medir la velocidad, en el cual el flujo de gas es paralelo al eje
del rotor y la velocidad de rotación del rotor es proporcional a la velocidad de flujo. El
volumen de gas se determina contando las revoluciones del rotor, esta debe operar con perfil
de velocidad uniforme, para lo cual se debe acondicionar el sistema para eliminar remolinos
y pulsaciones por presencia de filtros, codos, válvulas y otros accesorios.
El medidor de turbina consta de tres elementos básicos tal como se muestra en la Figura 3-7.
- El cuerpo
- El mecanismo de medición
- El instrumento de lectura o salida
38
Figura 3-7. Partes de un medidor tipo turbina.
Fuente: (Ecopetrol, 2010)
El gas que entra al medidor aumenta su velocidad al pasar a través del espacio anular
formado por el cono de nariz y la pared interior del cuerpo del medidor. El movimiento del
gas sobre las aspas del rotor, ubicadas angularmente, imparte una fuerza al rotor,
ocasionando que éste gire. La velocidad rotacional ideal es directamente proporcional a la
rata de flujo. La velocidad rotacional real es función del tamaño y forma del pasaje anular y
del diseño del rotor. Además, depende de la carga a la cual se somete el rotor, debido a la
fricción mecánica interna, el arrastre de fluido y la densidad del gas.
Instrumento de salida.: Los medidores de turbina están disponibles con salidas de pulso
eléctrico y/o mecánico. Para los mecanismos de transmisión mecánica la salida consiste en
39
un árbol o eje, engranajes y otros componentes de transmisión necesarios para transmitir las
revoluciones del rotor a la parte exterior del cuerpo del medidor, para el posterior registro de
volúmenes no corregidos.
Para los medidores de pulso eléctrico, la salida incluye el sistema detector de pulso y todas
las conexiones eléctricas necesarias para transmitir las revoluciones indicadas por el sensor
a la parte exterior del cuerpo del medidor para el registro de un volumen no corregido.
Conexión instrumentación asociada: La instrumentación asociada así como los equipos
auxiliares de control de calidad del gas que se requieren para integrar el volumen no
corregido a las condiciones estándar o para registrar los parámetros de operación, deben
instalarse apropiadamente.
Medidor de temperatura. Puesto que los disturbios aguas arriba deben mantenerse al
mínimo, el pozo del termómetro debe ubicarse aguas abajo del medidor. Debe estar
localizado entre uno y cinco diámetros nominales de tubería a partir de la salida del medidor
y aguas arriba de cualquier accesorio o válvula.
Medidor de presión. El fabricante provee una toma de presión sobre el cuerpo del medidor
la cual debe ser el punto de conexión para medir la presión.
Cálculo de flujo volumétrico El medidor de turbina es un equipo que mide la velocidad. Es
decir, dependiendo de la rata de flujo del gas, el rotor del medidor se mueve a una velocidad
proporcional a la velocidad de flujo.
Las revoluciones del rotor se cuentan mecánica o electrónicamente y se convierten a un
registro volumétrico continuamente totalizado. Puesto que el volumen registrado está en las
condiciones de presión y temperatura de flujo (volumen real), debe corregirse a las
condiciones base para propósitos de venta.
Caudal (tasa de flujo) a condiciones de flujo.
La tasa de flujo (tasa volumétrica) a las condiciones de flujo se determina por:
𝑄𝑓 =𝑉𝑓
𝑡
40
Donde:
Qf = Rata de flujo de gas a las condiciones de flujo
Vf = Volumen de gas medido a las condiciones de flujo
- Rata de flujo a condiciones base
𝑄𝑏 = (𝑄𝑓)(𝐹𝑝𝑚)(𝐹𝑡𝑚)(𝑠)
- Factor de Presión, Fpm
𝐹𝑝𝑚 =𝑝𝑓
𝑝𝑏
Donde: 𝑝𝑓 = 𝑃𝑓 + 𝑃𝑎
Pf = Presión absoluta del proceso, psia
Pf = Presión estática manométrica, psig
pa= Presión atmosférica, psia
Pb= Presión base: 14,65 psia
𝐹𝑝𝑚 =𝑝𝑓
14.65
- Factor de temperatura, Ftm
Se calcula a partir de la siguiente ecuación, suponiendo una temperatura base de 60°F o
519.67 °R.
𝐹𝑚 =519.67
𝑇𝑓
Tf = temperatura real del gas que fluye, en grados Rankine
Relación de compresibilidad,”s”
La relación de compresibilidad “s” se define como:
41
𝑠 =𝑍𝑏
𝑍𝑓
Donde
Zb = factor de compresibilidad en condiciones base
Zf = factor de compresibilidad en condiciones de flujo
El factor de compresibilidad Zb como Zf se deben obtener por medio del programa de
computador de AGA que usa los métodos de cálculo dados en el ― “AGA Transmission
Measurement Committe Report No. 8”.
Componentes adicionales para la medición de flujo
Un medidor de turbina mide las cantidades de gas en unidades volumétricas en las
condiciones de presión y temperatura en que se encuentra el flujo que pasa por el medidor.
Estas unidades de volumen se deben convertir a volúmenes equivalentes en algunas
condiciones de presión y temperatura. Esto se puede hacer en uno de varios métodos
disponibles.
Computación electrónica. Los medidores de turbina que utilizan señales electrónicas de
salida, miden los volúmenes que se pueden convertir a condiciones base utilizando
transductores electrónicos de presión y temperatura, en conjunto con computadores de flujo
electrónicos, dando de esta forma los volúmenes corregidos para facturación o telemedida
de acuerdo a los reportes AGA y Normas API MPMS.
Dispositivos integradores mecánicos. Por medio del uso de mecanismos especialmente
diseñados, estos instrumentos aplican un factor de presión o un factor combinado de presión
y supercompresibilidad al volumen de gas medido, corrigiéndolo a presión base. Con un
mecanismo adicional, el instrumento aplica el factor de temperatura a ese volumen de gas,
corrigiéndolo a temperatura base.
42
Dispositivos de registro de presión, volumen y temperatura. Varios tipos de dispositivos
de registro están disponibles para registrar presión, temperatura y unidades de volumen sin
corregir, de tal manera que los cálculos se pueden hacer para corregirlos a condiciones base.
3.2.4. Cálculo del factor de supercompresibilidad. Reporte AGA 8
El reporte No 8 de AGA proporciona la información técnica necesaria para computar los
factores de compresibilidad, los factores de supercompresibilidad y las densidades del gas
natural y otros gases relacionados. Este reporte reemplazó y dejó sin vigencia el AGA NX-
19 y el AGA 8 de 1985, y está en conformidad con el Documento ISO 12213, llamado
“Natural Gas – Calculation of Compression Factors”.
Este reporte es válido solamente para la fase gaseosa. Se puede aplicar para temperaturas de
–200ºF a 760ºF (-130ºC a 400ºC) y presiones hasta de 40.000 psia (280 (Mpa)). Las
aplicaciones a condiciones extremas se deben verificar por otros medios, por ejemplo,
comprobaciones experimentales. No se recomiendan los métodos de cálculo en la vecindad
del punto crítico. Usualmente esto no es una limitación en los gasoductos, donde
generalmente no se encuentran condiciones de operación cercanas al punto crítico.
El Reporte No 8 de AGA proporciona métodos recomendados para calcular con gran
exactitud los factores de compresibilidad y las densidades del gas natural para transferencia
de custodia y otras aplicaciones de medición de gas. El AGA 8 proporciona dos métodos de
ecuaciones de estado, los cuales se diferencian por los parámetros de entrada que se necesitan
para los cálculos.
Método Detallado de Caracterización
El primer método aplica un conocimiento detallado de la composición del gas natural para
computar el factor de compresibilidad; es decir, se requiere el análisis del gas. Se conoce
como el “MÉTODO DETALLADO DE CARACTERIZACION” y se puede aplicar sobre
todo el rango de presión, temperatura y composición mencionado anteriormente.
43
Este método se desarrolló para describir, en una forma muy exacta, el comportamiento en la
fase gaseosa de la relación presión-temperatura-densidad de mezclas de gases naturales
sobre un amplio rango de condiciones, incluyendo los gases con porcentajes molares de
hexanos e hidrocarburos más pesados mayores de 1%. También permitió reducir la
incertidumbre en el cálculo de gases naturales que contienen sulfuro de hidrógeno (H2S) y
CO2 (gases ácidos). Finalmente, fueron desarrolladas correlaciones del segundo coeficiente
virial para agua y mezclas binarias de agua con metano, etano, hidrógeno y gas carbónico,
para reducir la incertidumbre en el cálculo de gases naturales que contienen vapor de agua
(gases húmedos).
Método General (“Gross”) de Caracterización
El segundo método aplica un conocimiento general o grueso (“gross”) de la composición del
gas natural (dado por el poder calorífico y/o la densidad relativa y la información del
contenido de “diluyentes”) para computar el factor de compresibilidad. Se denomina el
“MÉTODO GENERAL DE CARACTERIZACIÓN” (“GROSS CHARACTERIZATION
METHOD”). Este método se puede aplicar en una región limitada de presión y temperatura,
para composiciones de gas natural que estén en el “Rango Normal” de la Tabla 3-10. Este
método solo se puede aplicar en gases naturales secos y dulces.
Tabla 3-10 Rangos de composición de mezclas de gas
Cantidad Rango Normal Rango Expandido
Densidad Relativa* 0.554 a 0.87 0.07 a 1.52
Poder calorífico superior** 477 a 1150 Btu/scf 0 a 1800 Btu/scf
Poder calorífico superior*** 18.7 a 45.1 MJ/m3 0 a 66 MJ/m3
Porcentaje de metano 45 a 100 0 a 100
Porcentaje de nitrógeno 0 a 50 0 a 100
Porcentaje de dióxido de carbón 0 a 30 0 a 100
Porcentaje de etano 0 a 10 0 a 100
Porcentaje de propano 0 a 4 0 a 42
Porcentaje de butanos 0 a 1 0 a 5
Porcentaje de pentanos 0 a 0.3 0 a 4
Porcentaje de hexanos + 0 a 0.2 0 a Punto de Rocio
Porcentaje de helio 0 a 0.2 0 a 3
Porcentaje de hidrógeno 0 a 10 0 a 100
Porcentaje monóxido de carbón 0 a 3 0 a 3
Porcentaje de argón # 0 a 1
Porcentaje de oxigeno # 0 a 21
44
Porcentaje de agua 0 a 0.05 0 a Punto de Rocio
Porcentaje sulfuro de hidrógeno 0 a 0.02 0 a 100 *Condiciones de referencia 60ºF
**Condiciones de referencia 60ºF y 14.73 psia ***Condiciones de referencia 25ºC ; 0.1325 Mpa
# Rango normal es considerado 0 para estos componentes
Fuente: (Ecopetrol, 2010)
3.2.5. Medición Electrónica de gas. Norma API MPMS 21.1.
Este estándar se ha definido con el fin de establecer las especificaciones mínimas para los
sistemas electrónicos de medición de gas que usan parámetros de flujo en aplicaciones de
transferencia de custodia.
El sistema de medición lo compone un elemento primario de donde se deduce una señal
directa de la medición de flujo, que para nuestro caso es la turbina. El elemento secundario
o instrumentación está asociado al medidor que toma lectura de las condiciones
operacionales de presión y temperatura para ser enviadas junto con la señal de flujo directa
del primario a un elemento terciario el cual consiste de un computador de flujo programado
correctamente para calcular el flujo dentro de las condiciones especificadas para el tipo de
medidor.
Algoritmos de los computadores de flujo
Define los procedimientos de muestreo, la metodología de cálculo y la técnica de promedio
a aplicar en la ecuación de flujo para asegurar un aceptable sistema de medición. Se debe
usar para cada caso la última revisión de los procedimientos de cálculo disponibles para cada
tipo de medidor así como el uso de AGA 8 para factor de supercompresibilidad.
Medidor tipo Diferencial: La aplicación en medidores tipo diferencial el flujo total se
determina por la integración de la ecuación de la rata de flujo en un intervalo de tiempo.
𝑄𝑡 = ∫ 𝑞𝑡𝑑𝑡
Donde:
Qt: Cantidad acumulada entre to y t.
qt: Ecuación de rata de flujo en una unidad de tiempo
45
dt: Diferencia de tiempo entre muestreo.
Las variables incluidas en la ecuación no son estáticas, por lo que el flujo total es la
integración de variables que cambian en el tiempo.
Medidor tipo Lineal: En aplicaciones de medidores tipo lineal (turbina, ultrasónico,
Coriolis) la cantidad de flujo total es determinada por la sumatoria de flujo durante un
intervalo de tiempo determinado.
𝑄𝑡 = ∫ 𝑄𝑛𝑑𝑡
Donde:
Qt: Cantidad acumulada entre to y t.
Qn: Ecuación de rata de flujo para el intervalo dt
dt: Diferencia de tiempo entre muestreo.
Al igual que en el medidor diferencial las variables son no estáticas. En medidores lineales
el elemento primario envía medición volumétrica a condiciones de flujo. Las unidades
volumétricas para un intervalo de tiempo son pulsos que son linealmente proporcionales a la
unidad de volumen.
Disponibilidad de datos
Para buscar exactitud en la medición se debe asegurar que los datos requeridos se encuentran
disponibles y retenidos para permitir el cálculo de las cantidades a medir a través del
elemento primario.
Tanto para medidores diferenciales como lineales se requiere los valores promedio hora-
hora y día –día de las variables temperatura, presión estática, presión diferencial,
volúmenes no corregidos y cantidad de volumen acumulada. De igual manera valores de
aquellas variables como diámetro de referencia, los rangos de calibración de la
instrumentación asociada y características de la calidad del gas (densidad, poder calorífico,
composición, etc).
46
Se requiere disponibilidad de lecturas instantáneas de los valores de presión, temperatura,
rata de flujo, volumen acumulado y alarmas o condiciones de error que afecten la medición.
Adicionalmente las condiciones de calidad cuando no son fijas.
En el computador de flujo debe quedar registrado los valores as found como as left resultado
de los procesos de calibración de la instrumentación asociada al medidor. Los cambios en
los valores configurados como valores fijos deben quedar registrados.
El computador de flujo debe disponer para efectos de auditoría, de un registro resumen de
todas las alarmas y condiciones de error que afectan la medición incluyendo su descripción
y un registro de las horas y minutos que operó el sistema en un día. La capacidad de
almacenamiento mínima deberá ser de 30 días.
El sistema de medición y su computador de flujo debe tener una identificación visible.
3.3. Requerimientos de auditoría y reporte
Un sistema de medición electrónica de gas debe facilitar la auditoría mediante la
disponibilidad de registros día-día y hora-hora de las variables que intervienen en la
medición. La auditoría incluye adicionalmente configuración de variables fijas y volátiles,
eventos y alarmas. La razón importante de disponer de los registros históricos es suministrar
soporte a los registros oficiales, realizar ajustes cuando el equipo lo requiera y observar datos
incorrectos.
El volumen diario representa el promedio de la suma de datos colectados y calculados
durante el periodo contractual de un día. Igual concepto se aplica para los registros hora-
hora.
El algoritmo utilizado en el sistema de medición electrónica debe estar identificado por el
fabricante y su versión.
La revisión de la configuración es una actividad importante dentro de la auditoria e
inspección de un sistema de transferencia de custodia. Se busca identificar todos os
parámetros fijos que se requieren para el cálculo de flujo.
47
Deben quedar registrados en el momento que ocurren, todos los eventos que generen
cambios en los parámetros de flujo y que se salen de los valores normales afectando la
exactitud del medidor.
Instalación de transmisores: Se deben establecer claramente el rango, los valores límites
operacionales, y las condiciones ambientales de la instrumentación asociada como son los
transmisores. El fabricante debe establecer la exactitud combinada por el efecto de
linealidad, histéresis y repetitividad. El efecto de temperatura sobre el cero y el span deben
estar considerados. De igual manera otros efectos que afectan la exactitud como vibración,
variación de potencia y localización deben ser considerados.
Los transmisores deben ser mantenidos de acuerdo a las instrucciones del fabricante y
protegerlos del medio ambiente cuando eso se requiera. Para medidores tipo diferencial el
transmisor de presión estática debe estar conectado a una de las tomas de alta o baja de la
presión diferencial. Toma separada de presión estática no es permitida.
Líneas manométricas: Toda pulsación debe ser eliminada en su origen. Efectos de pulsación
son causados por la instalación de válvulas de bloque obstrusivas, se deben instalar válvulas
full-port, área de flujo uniforme entre la válvula y la tubería. De igual manera líneas de gran
longitud ocasionan pulsaciones por lo que se debe minimizar su longitud. Las líneas
manométricas deben ser uniformes en diámetro, y de material compatible con la calidad del
gas a medir. La pendiente debe impedir la acumulación de condensados, positiva una
pulgada por pie y debe estar correctamente soportada para evitar vibración.
Equipos Auxiliares: Equipos periféricos tales como analizadores de calidad del gas
(cromatógrafos o gravitómetros) pueden ser instalados siguiendo las recomendaciones del
fabricante. Las conexiones al elemento primario deben realizarse siguiendo la última versión
de los estándares aplicables.
Conexión al computador de flujo: Tanto el computador de flujo como su comunicación con
los transmisores y/o unidades de transmisión remota (RTU) deben ser instalados y
mantenidos de acuerdo a las instrucciones del fabricante. Todos los materiales de
construcción deben ser compatibles con el servicio y el medio ambiente. El computador de
48
flujo debe poseer protección por interferencia por frecuencia y electromagnética. El
computador de flujo debe incluir eliminador de transientes para su protección.
Cableado: El cableado debe obedecer a la clase de servicio e instalado de acuerdo a la
normativa NEC. Todos los cables deben ser resistentes al medio ambiente y evitar
interferencia eléctrica. Se debe impedir el cableado conjunto de corriente directa con
corriente alterna.
Dadas las premisas anteriores en cuanto a la medición volumétrica de gas natural,
adicionalmente a las variables instantáneas mencionadas en las sección 2, es necesario
garantizar la historización de esta medición, ya que no solo basta con la información
almacenada en el computador de flujo por el tiempo mínimo definido por el estándar, sino
que debe ser enviados a una base de datos para su consulta posterior y como soporte para los
procesos de nominación, compra y venta del elemento energético.
De acuerdo a esto, la estructura de los datos asociados a cada registro hora – hora y día –
día, se ha definido de acuerdo a como estos son generados por el computador de flujo, como
se presenta a continuación:
3.3.1. Estructura Registro Hora – Hora
A continuación se describen los datos que componen un registro hora – hora:
Tabla 3-11 Campos de un registro Hora - Hora
Información de un registro hora - hora
H_TRIndx Índice del registro
H_TRMID1 Identificador Medidor 1
H_TRMID2 Identificador Medidor 2
H_ODATE La fecha en que inició el registro horario
H_OTIME La hora en que inició el registro horario
H_CDATE La fecha en que terminó el registro horario
H_CTIME La hora en que terminó el registro horario
H_Nsmpls Número Total de muestras en la hora
H_Flowtm El tiempo de flujo medido en segundos
H_Av_P La presión absoluta promedio de la hora
49
H_Av_T La temperatura promedio de la hora
H_UncQty El volumen no corregido medido en la hora
H_Av_dnB La densidad calculada en condiciones base para la hora
H_Mass La masa total calculada en la hora
H_Energy La energía total en condiciones de referencia base para la hora
H_VolBas El volumen total en condiciones de referencia base para la hora
H_Metha % Metano
Composición del gas
H_Nitro % Nitrogeno
H_CrbnD % Dioxido de Carbono
H_Ethan % Etano
H_Propa % Propano
H_Water % Agua
H_HydrS % Sulfuro de Hidrógeno
H_Hydro % Hidrogeno
H_CrbnM % Monoxido de Carbono
H_Oxyge % Oxigeno
H_i_But % Isobutano
H_n_But % n_Butano
H_i_Pen % Isopentano
H_n_Pen % n_pentano
H_n_Hex % n_hexano
H_n_Hep % n_heptano
H_n_Oct % n_octano
H_n_Non % n_nonano
H_n_Dec % n_decano
H_Helium % Helio
H_Argon % Argón
Fuente: Elaboración Propia
3.3.2. Estructura Registro Día – Día
A continuación se describen los datos que componen un registro día – día:
Tabla 3-12 Campos de un registro Día – Día
D_TRIndx Índice del registro
D_TRMID1 Identificador Medidor 1
D_TRMID2 Identificador Medidor 2
D_ODATE La fecha en que inició el registro diario
D_OTIME La hora en que inició el registro diario
D_CDATE La fecha en que terminó el registro diario
D_CTIME La hora en que terminó el registro diario
D_Nsmpls Número Total de muestras en el día
50
D_Flowtm El tiempo de flujo medido en segundos
D_Av_P La presión absoluta promedio del día
D_Av_T La temperatura promedio del día
D_UncQty El volumen no corregido medido en el día
D_Av_dnB La densidad calculada en condiciones base para el día
D_Mass La masa total calculada en el día
D_Energy La energía total en condiciones de referencia base para el día
D_VolBas El volumen total en condiciones de referencia base para el día
D_Metha % Metano
Composición del gas
D_Nitro % Nitrogeno
D_CrbnD % Dioxido de Carbono
D_Ethan % Etano
D_Propa % Propano
D_Water % Agua
D_HydrS % Sulfuro de Hidrógeno
D_Hydro % Hidrogeno
D_CrbnM % Monoxido de Carbono
D_Oxyge % Oxigeno
D_i_But % Isobutano
D_n_But % n_Butano
D_i_Pen % Isopentano
D_n_Pen % n_pentano
D_n_Hex % n_hexano
D_n_Hep % n_heptano
D_n_Oct % n_octano
D_n_Non % n_nonano
D_n_Dec % n_decano
D_Helium % Helio
D_Argon % Argón
Fuente: Elaboración Propia
3.3.3. Estructura Registro Máximos y Mínimos
Adicional a los registros horarios y diarios, para el seguimiento del comportamiento de la
medición, se ha requerido que también se generen registros hora – hora de los valores
máximos y mínimos de las variables usadas y generadas para el cálculo: Presión,
Temperatura, Flujo, Densidad y Poder Calorífico. Estos datos tendrán la siguiente estructura:
51
Tabla 3-13 Campos de un registro de Máximos y Mínimos
Información de un Registro de Máximos y Mínimos
MxMn_Indx Índice Registro
MxMn_Date Fecha del registro
MxFlow Flujo Máximo
MxFlow_Time Hora del Flujo Máximo
MxTemp Temperatura Máxima
MxTemp_Time Hora de la Temperatura Máxima
MxPres Presión Máxima
MxPres_Time Hora de la Presión Máxima
MxDens Densidad Máxima
MxDens_Time Hora de la Densidad Máxima
MnFlow Flujo Mínimo
MnFlow_Time Hora del Flujo Mínimo
MnTemp Temperatura Mínima
MnTemp_Time Hora de la Temperatura Mínima
MnPres Presión Mínima
MnPres_Time Hora de la Presión Mínima
MnDens Densidad Mínima
MnDens_Time Hora de la Densidad Mínima
HV Poder Calorífico
Fuente: Elaboración Propia
52
4. Capítulo 4
Propuesta de Actualización
De acuerdo a lo mencionado en el capítulo 2, el diseño inicial del sistema SCADA estaba
dimensionado inicialmente para la captura de datos actuales de 60 sitios remotos y la
eventual solicitud de la base de datos de los registros de la medición de los últimos cuarenta
días.
Con el crecimiento de la red del gasoducto y los requerimientos de entrega de información
al gestor de mercado, de acuerdo a la Resolución 089 de 2015, se hace necesario realizar una
restructuración general de todos los componentes de la plataforma (centro de control –
medios de comunicación – remotas), no solo para cumplir con la demanda actual de flujo de
datos, sino también con el objetivo de proyectar el crecimiento escalable de toda la
plataforma de forma modular.
Teniendo presente los requerimientos y objetivos a alcanzar y que fueron descritos en la
Tabla 2-1 se determinan las siguientes acciones a realizar sobre toda la plataforma SCADA:
- Actualización de toda la infraestructura, es decir, remotas, FEP y servidores del
software SCADA, así como la inclusión de nodos repetidores a lo largo del
departamento del Valle del Cauca, para la cobertura del medio de comunicación radio
convencional.
- Acondicionamiento de red local y extendida de GDO para la comunicación entre
servidores, FEPs y repetidores. Este ítem será responsabilidad de GDO.
- Cambio en las aplicaciones del FEP y remotas para re-dimensionar la cantidad de
sitios de manera que se mejore el tiempo de actualización de los datos en el FEP. En
esta propuesta que se describe a continuación, se especifica el dimensionamiento en
cuanto a cantidad de sitios remotos que se podrán manejar y los tiempos de refresco
que se pueden garantizar de acuerdo al número de sitios remotos activos.
- Actualización del Software Wonderware a la última versión liberada.
- Validación y ajustes de la arquitectura del software SCADA para el funcionamiento
adecuado.
53
- Actualización de la aplicación SCADA, de acuerdo a cambio en la estructura de datos
a procesar e historizar.
Se plantea un re-diseño de las aplicaciones tanto de los sitios remotos como del FEP,
encaminadas a mejorar el tiempo de actualización de la información. Esta aplicación cubre
las siguientes funcionalidades básicas, además de las otras que sean necesarias para
garantizar su funcionamiento adecuado.
- Solicitar al sitio remoto los datos actuales con la mejor periodicidad posible, es decir,
tan pronto como el FEP solicita datos y los procesa para que a su vez sean
actualizados en el software SCADA.
- Revisar y ajustar las rutinas que garanticen la entrega de datos al FEP después de un
fallo de comunicación, de manera que la información concerniente a los registros de
AGA 7/8 que no se hayan enviado al centro de control por el evento de
comunicaciones, sean entregados, una vez se restablezca la comunicación.
- Las rutinas del FEP deben solo funcionar para los sitios que estén activos en el
sistema, de manera que se mantengan tiempos de refresco menores al límite
programado. Esto quiere decir, que las aplicaciones del FEP no deben realizar
ejecución de rutinas para sitios que se contemplan incluir, pero que en este momento
no existen ya que esto generaría retrasos en la obtención de datos de los sitios que si
se encuentran activos. La inclusión de nuevos sitios remotos, se realizará de manera
manual, mediante configuración de parámetros, sin necesidad de reiniciar toda la
plataforma.
4.1. Filosofía de Procesamiento de Información
La actualización del Centro de Control, comprende básicamente dos etapas, la primera es la
actualización de los equipos y la correspondiente aplicación de los Front End Processor y la
segunda etapa es respecto a la actualización de la infraestructura de servidores y del software
SCADA. Sin embargo, para realizar esta actualización debe tenerse presente los cambios
adicionales que son necesarios para generar este procedimiento, como son la actualización
54
de la aplicación de los equipos remotos y la actualización de la red de comunicaciones. A
continuación se realizará una breve descripción de estos cambios.
4.1.1. Aplicación en la RTU Remota
Las RTU ACE3600, son unidades inteligentes modulares, diseñadas para operar como
controladores standalone o como parte de un sistema con un número de RTUs, centros de
control y sub centrales, conectados a través de una red de comunicaciones con un cierto
número de links y nodos. Las RTU son configuradas y cargadas con una aplicación
apropiada, a través de la herramienta STS (Motorola ACE3600 System Tools Suite)
(Motorola Solutions, Inc., 2011).
Las RTU remotas son modificadas, con el fin de que pueda realizarse sin inconveniente la
comunicación con el centro de control y así efectuar la optimización de tiempos y
confiabilidad en la información. En la Figura 4-1, se presenta como será llevado a cabo el
flujo de datos:
AGA 7/8
PROCESO I/O
Control Reg.
Modulos I/O
Datos
instantáneos calculados
Datos
Entrada AGA
Recepción
Armar Paquete Tx
Datos Instantáneos para Tx
DO / AO
Indices
Solicitud Registros
Registros a TransmitirSolicitud Instantáneos
Bu
ffer
Tx.
Bu
ffer
Rx.
Comando
Datos TxPuerto Comm.
Ind. Reg.
Instantáneos
Reg. D
Reg. H
Reg. Mx Mn
Comm
Centro de
Control.
Figura 4-1. Estructura Flujo de datos aplicación estación remota.
Fuente: Elaboración Propia.
Los sitios remotos reciben comandos del centro de control, que indican que tipo de acción
la RTU debe ejecutar.
55
La rutina llamada Recepción se encarga de procesar estos comandos, cada uno para una
tarea específica. Para comprender la dinámica del manejo de la información, se analizará el
caso de recibir solicitudes de datos instantáneos o datos de registros.
En el caso de recibir una solicitud de datos instantáneos, se le solicita a la rutina “Armar
paquete Tx", que se dirija a la tabla donde se encuentran todos los datos instantáneos a
transmitir y armar la correspondiente trama con los encabezados asociados y ejecutar las
acciones para que el buffer de transmisión envíe los datos al centro de control. En caso de
recibir solicitud de registros, se ajustan varias banderas en las tablas de “Ind. Reg” indicando
que se debe transmitir un registro identificado mediante un índice ya sea horario o diario.
Este índice que se debe transmitir, es un dato que viene incluido en la solicitud desde el
centro de control, ya que el FEP controla y establece cual registro necesita para mantener la
información completa.
La rutina Control Reg, es la encargada de verificar los índices de registros y así saber en qué
momento se requiere enviar uno al centro de control, caso en el cual lo extrae de la base de
datos de registros diarios u horarios según la solicitud y entrega la información a transmitir
a la rutina Armar Paq Tx.
Es importante tener presente que las bases de datos de registros almacenan la información
de los últimos 30 días de registros, es decir 30 o más registros diarios y 720 o más registros
horarios. De esta manera se garantiza que la información esté siempre disponible en las RTU
remotas y que ante fallas de comunicación sea siempre posible recuperarla en el centro de
control. Los FEPs monitorean las fechas y horas de todos los registros y determina si debe o
no solicitar registros e indica mediante un índice aquel que sea necesario. La tabla de índices
en el remoto y la rutina de control de registros se encargan siempre de transmitir el registro
solicitado por el FEP.
Finalmente se presenta la rutina de AGA 7/8 que realiza todos los cálculos del standard a
partir de la información obtenida en las entradas análogas y por modbus. Las salidas del
bloque AGA 7/8 alimentan las bases de datos de registros hora a hora, día a día y los
máximos y mínimos de las variables de medición en cada corte hora – hora.
56
4.1.2. Red de Comunicaciones Remotas - Centro de Control
Tal como se presentó en el Capítulo 2, la estructura de comunicaciones entre el centro de
control y las estaciones remotas estaba configurado a través de dos medios de comunicación,
el primero a través de la red conmutada, mediante 4 canales dedicados y el segundo medio
a través de radio convencional, para cierto tipo de estaciones (alrededor de 20 sitios), que
son de prioridad para el monitoreo del gasoducto.
Con el aumento del flujo de información desde las estaciones remotas, se hace necesario
cambiar la metodología de comunicación entre las remotas y el centro de control, con el fin
de tener acceso a todos los puntos remotos, teniendo presente que buena parte de los sitios
se encuentran apartados de las cabeceras municipales.
Esta actualización contempló lo siguiente:
- Migración de canal conmutado telefónico, a servicio general de paquetes vía radio o
GPRS. Dado que la transferencia de datos de GPRS se cobra por volumen de información
transmitida (en kilo o megabytes), mientras que la comunicación de datos a través de
conmutación de circuitos tradicionales se factura por minuto de tiempo de conexión,
independientemente de si el usuario utiliza toda la capacidad del canal o está en un estado
de inactividad.
Los servicios de paquetes como GPRS se orientan al tráfico de datos. La tecnología
GPRS como bien lo indica su nombre es un servicio (Service) orientado a radio enlaces
(Radio) que da mejor rendimiento a la conmutación de paquetes (Packet) en dichos radio
enlaces.
El operador de servicios ha sido definido por el cliente, de acuerdo a estudio previo de
cobertura de servicios a lo largo de los dos departamentos, siendo Claro Servicios
Móviles el proveedor. Con el fin mantener niveles de servicio homogéneos para todas
las estaciones, el operador ha definido un canal APN dedicado al direccionamiento IP
asignado para cada uno de los módems instalados en las estaciones remotas y los 4
modems instalados en el centro de control, que continuamente estarán recibiendo y
entregando paquetes de datos a las estaciones remotas asignadas previamente.
57
- Ampliación del canal de comunicación de radio convencional. Dado que la red de
distribución ha tenido un plan de expansión a lo largo de los dos departamentos, se
hace necesario que la supervisión y monitoreo de cada uno de los nodos de
distribución sea dedicado y de esta forma se garantice la integridad del gasoducto.
Este crecimiento ha generado la integración de tres sitios de repetición, que se
encarguen de recibir la información de cada una de las remotas y la retransmita
mediante conexión de banda ancha dedicado hacia el centro de control. Estos tres
repetidores han sido instalados en tres puntos geográficos, para que se dediquen a
cierto número de estaciones de acuerdo a su radio de cobertura.
4.1.3. Actualización de Equipos y Aplicación del FEP
El computador de centro de control, con la respectiva interfaz de usuario, proporciona al
usuario un control gráfico completo del funcionamiento de la RTU, incluyendo bases de
datos y parámetros de cambios y monitoreo de aplicaciones en línea para el ingeniero del
sistema. El computador central se comunica con las RTUs utilizando el protocolo MODBUS,
ya sea sobre medios de comunicación en serie o por TCP/IP. El computador central se
comunica con la puerta de enlace IP que utiliza el protocolo TCP/IP.
Una de las funciones del centro de control es el intercambio de datos con la RTU. Se puede
interrogar a la RTU para cualquier parte de su base de datos. Se pueden manejan ciclos de
polling con diferentes prioridades y por diferentes mecanismos de activación (tiempos o
eventos).
En figura que se presenta a continuación, se describe la filosofía de operación del FEP que
se ha planteado para filosofía de adquisición de los datos enviados por las estaciones
remotas:
58
Parámetros
configuraci
ón s itios
Instan
táneos
Reg.
D
Reg.
H
Reg.
Mx
Mn
Instantáneos
Registros
Info Sitios
Parámetros de
Configuración Sitios
Hora
Cola de
Tareas
Comm
Recepción
Bu
ffer T
x.
Bu
ffer R
x.
Comm
Sitios
remotos
Instantáneos
Temporal de
Datos de
Remotos
Comandos
Application Server
Comunicación Modbus
Figura 4-2. Esquema Flujo de Datos Aplicación FEP.
Fuente: Elaboración Propia.
En el diagrama presentado previamente, se representa el flujo de información entre las
rutinas y tablas de la aplicación interna del FEP. A través de este esquema, se explican las
principales rutinas de programación del FEP que se encargan en gestionar la información
más importante para el usuario, que se resume en los cuatro conjuntos de datos que se
enuncian a continuación:
- Datos instantáneos
- Datos del registro horario
- Datos del registro diario,
- Datos del registro de máximos y mínimos.
El FEP se comunica con los sitios remotos a través de un switch Ethernet que a su vez brinda
conexión mediante enlaces de banda ancha a cada uno de los repetidores. Adicionalmente,
cuenta con uno de los canales dedicados de comunicación GPRS, como segundo medio de
comunicación para las estaciones remotas.
Internamente el FEP y las RTU remotas cuentan con un buffer de almacenamiento temporal
de datos de transmisión y recepción. En estos buffer, se ubican los datos para ser transmitidos
59
y serán leídos continuamente en el buffer de recepción para saber cuándo se ha recibido una
transmisión de cualquiera de los sitios remotos.
Los bloques funcionales descritos como instantáneos, registros, recepción, representan las
rutinas que se encargan de desempeñar ciertas tareas usando como base la información de
entrada y a su vez generando cierta información de salida. Cada una tiene una o varias flechas
de entrada y de salida que representan esos datos de entrada y salida al bloque funcional.
Se encuentran adicionalmente bloques de información del equipo, es decir, conjuntos de
tablas (columnas y filas) en las cuales se almacena información organizada y lógicamente
relacionada entre sí de alguna manera.
Para el caso específico de la aplicación que se plantea en el FEP, estos bloques representan
dos conjuntos de tablas importantes, en las cuales se fundamenta toda la ejecución de la
aplicación:
- PARAMETROS CONFIGURACIÓN SITIOS: En estas tablas se deben ingresar
todos los parámetros más relevantes de cada uno de los sitios remotos como son:
o Bandera de activación de sitio: Esta bandera le indicará a la aplicación si el
sitio está actualmente activo o disponible para ser activado posteriormente.
o Site ID del sitio: Número para identificar a cada sitio remoto dentro de la red
de RTUs.
o Id interno del sitio: Numero para darle manejo interno a los datos de cada
sitio remoto dentro de la aplicación.
o Control de registro horario y diario: Conjunto de valores para indicar el
consecutivo de registros horarios y diarios que permiten llevar control de la
solicitud y recepción de datos de registros AGA por cada sitio remoto.
o Fallas de comunicación: Valores para indicar cuantos intentos fallidos se han
tenido en la comunicación con cada sitio remoto.
60
- TEMPORAL DE DATOS DE REMOTOS: En estas tablas se cuenta con una
columna dedicada enteramente a recibir y guardar de manera temporal los datos de
cada sitio remoto: instantáneos, registros horarios y registros diarios. De esta tabla,
el software SCADA realiza la lectura continua mediante Modbus y de esta manera
los datos llegan al sistema para su visualización, almacenamiento histórico y manejo
de alarmas. En otras palabras, esta tabla va a contener siempre el último conjunto de
datos que fue recibido de cada sitio remoto, ya sean instantáneos, registros horarios,
diarios o máximos y mínimos. Cada vez que haya un cambio en estos datos debe
entenderse por parte del software SCADA como una recepción de datos por parte del
sitio remoto.
El llamado Cola de Tareas Comm, representa la cola de tareas del FEP. Dado que el
FEP es un “Front End Processor” o terminal de procesamiento de datos,
esencialmente este desempeña rutinas de comunicación, por tanto esta cola puede
entenderse como una cola de tareas pendientes de comunicación. La cola interactúa
con todas las rutinas pero en especial quien controla la ejecución de las tareas es la
rutina llamada “Control Tx”. Cada tarea de comunicación está compuesta por:
o ID del sitio al cual se debe enviar comunicación.
o Comando indicando que tipo de comunicación o solicitud es la que se enviará.
o Parámetro del comando anterior que se usa dependiendo de la solicitud.
o Reintentos de la tarea. Para conocer cuántas veces se ha intentado la ejecución
de la misma pero sin recibir confirmación.
o Confirmación de la tarea.
Como se mencionó previamente, la cola de tareas tiene especial interacción con la rutina
Control Tx. Las cuales se describirán a continuación:
- Rutina Control Tx: Esta rutina se encarga de realizar el mayor esfuerzo en ejecutar
todas las tareas pendientes que estén en la cola en el menor tiempo posible, Es decir,
toma cada elemento de esa lista y envía al buffer la información necesaria para que
se ejecute el envío al sitio remoto de la solicitud. Si culmina con todas las tareas
61
pendientes, revisa continuamente toda la lista para que tan pronto una tarea se reciba
allí sea ejecutada de inmediato.
- Rutina Instantáneos: Esta rutina se encarga de poner en la cola de tareas, las
solicitudes de datos instantáneos a los sitios remotos.Para poder cumplir esto, la
rutina revisa la información de cada uno de los sitios determinado de acuerdo a las
tablas de “parámetros de configuración de sitios” a cuales sitios debe pedirles
instantáneos y a cuáles NO. Debido a que en las tablas solo estarán como activos
aquellos sitios que realmente exista en el campo, esta rutina optimiza la solicitud de
instantáneos buscando hacer la solicitud con la mayor periodicidad posible.
- Rutina Registros: Esta rutina se encarga de poner en la cola las tareas de solicitud
de registros horarios y diarios a los sitios remotos. La rutina revisa la hora actual de
la RTU, de esta manera solo al inicio de cada hora de corte realiza la solicitud de
registros horarios y al inicio del día realiza la solicitud del registro diario
correspondiente. De esta manera se optimiza el tiempo de ejecución de tareas de
comunicación ya que no pone tareas innecesarias de sitios que no existan aun o estén
inactivos. La rutina también monitorea la fecha de corte (cierre) del último registro
que se recibió y mediante los valores de control de registros de cada sitio determina
si faltan registros, lo cual puede ocurrir por perdidas temporales de comunicación
con los remotos. En el caso que falten registros, se realizan las peticiones con una
periodicidad mayor hasta que los registros del sitio que se hayan recibido
completamente.
Teniendo en cuenta las características de funcionamiento de esta aplicación y su interacción
con el FEP en el centro de control, se pueden garantizar los siguientes aspectos:
- Los tiempos de comunicación y por tanto de recepción de datos se optimizan ya que
las rutinas de instantáneos y registros no envían a la cola tareas innecesarias que
hacen perder tiempos en el FEP en cuanto a solicitud de datos y por lo tanto ocasionan
que el periodo de refresco de datos sea mayor.
62
- La cola de tareas y su rutina de control garantizan la mayor rapidez en la solicitud de
la información y sin generar interferencias entre las distintas solicitudes de datos.
Mediante ciertos parámetros de esta lista es posible dar prioridad dependiendo del
caso a la solicitud de los datos actuales o de registros. De esta manera se garantiza
que los instantáneos se reciban con el mejor periodo de refresco posible y que las
solicitudes de registros sean confiables en cuanto a que se ejecuta la tarea varias
veces si no se confirma que se recibió.
- De acuerdo a lo anterior, se puede garantizar que esta aplicación podrá tener un
crecimiento 75 sitios por cada FEP de manera que las tareas se puedan ejecutar sin
problemas de retraso o pérdida de datos.
- Se estima que teniendo 75 sitios remotos sería el peor de los casos en cuanto a tiempo
de refresco de los datos, el tiempo de actualización estará alrededor de los 25
segundos. Sin embargo, este tiempo mejora en la medida que la cantidad de sitios sea
menor de acuerdo a la siguiente tabla:
Tabla 4-1. Estimación tiempos de actualización de datos en aplicación de FEP.
Cantidad de Sitios Periodo de
Actualización Max
Periodo de
Actualización Min
Periodo de
Actualización Típico
1 a 15 14 seg 6 seg 10 seg
16 a 30 26 seg 10 seg 14 seg
31 a 45 38 seg 14 seg 18 seg
46 a 60 50 seg 18 seg 22 seg
61 a 75 62 seg 22 seg 26 seg
Fuente: Elaboración Propia
El tiempo de actualización máximo se presentará solo en los caso en que se esté realizando
la solicitud de datos de registros, esto se hace cada hora para los registros horarios y de
máximos y mínimos, cada día para los diarios. En el resto del tiempo, el periodo de
actualización estará alrededor del valor típico. Estos tiempos se pueden garantizar, siempre
y cuando se mantengan los medios de comunicación en buen estado de funcionamiento y se
realicen los trabajos relacionados con las mejoras en la red.
63
4.2. Actualización de la infraestructura de servidores y del software SCADA
Para el proceso de actualización de la infraestructura de servidores y del software SCADA,
se partieron de las siguientes decisiones de diseño básicas sobre los requerimientos de
servidores y equipos de escritorio:
4.2.1. Soporte Hardware - Virtualización
Hoy en día, muchas de las principales empresas del mundo están utilizando la tecnología de
virtualización de software para ofrecer importantes ahorros de costes, la mejora de la
eficiencia, una mayor agilidad, una mayor disponibilidad del sistema y la mejora de las
capacidades de recuperación de desastres (Frider, 2012).
Un proceso típico de una planta industrial, incluyendo plantas de fabricación, servicios
públicos (como es precisamente nuestro caso puntual) o empresas de servicios, tienen
muchas aplicaciones de software importantes que pueden ser virtualizadas, entre ellas
encontramos, las aplicaciones Interfaz Hombre Máquina (HMI), los historiadores de datos
de proceso y sistemas de ejecución de fabricación (MES), junto con otras aplicaciones de
análisis y presentación de informes, propios de los sistemas SCADA.
A continuación se presentará un contexto general de lo que es en sí la virtualización y de las
condiciones de configuración con las que se ha realizado la actualización de la plataforma
software del sistema SCADA de Gases de Occidente.
¿Qué es la virtualización?
En términos simples, la virtualización es la creación y el empleo de una versión “virtual”, de
una versión “real” de algo. La virtualización puede aplicarse tanto a dispositivos físicos,
sistemas operativos, recursos de red o controladores de dispositivos que permitan su
sustitución.
64
La virtualización es una forma de abstracción de software, lo que permite a los usuarios
manipular las versiones virtuales de una manera que sería imposible que con sus contrapartes
físicas. Esta es una de las propiedades que ofrece potencia y flexibilidad de obtener
beneficios considerables al usar este tipo de tecnología.
Virtualización de Hardware
La virtualización de hardware emplea la tecnología de software, como el ofrecido por
Microsoft® y VMware®, transformando o “virtualizando” una computadora para crear un
equipo virtual que puede ejecutar su propio sistema operativo y las aplicaciones al igual que
una computadora física. Con la virtualización, varias aplicaciones y sus sistemas operativos
requeridos pueden ejecutar de forma segura y a la vez en un solo equipo físico.
El corazón del proceso de virtualización es un componente software llamado “Hypervisor”,
término acuñado durante los primeros días del Mainframe de IBM. Existen dos categorías
generales de hipervisor. Los hypervisor tipo 1, se ejecutan directamente en un hardware o
host físico y se gestionan invitados o máquinas virtuales para que sus sistemas operativos
pueden ejecutarse simultáneamente en el hardware. Esto se logra mediante la interceptación
o “atrapamiento” de las instrucciones de los sistemas operativos invitados y resolverlos de
manera que la función de invitados pueda trabajar adecuadamente en su entorno virtualizado.
Ejemplo de este tipo de hipervisor son las plataformas VMware ESXi y Microsoft Hyper-V.
Los hypervisor tipo 2, se ejecutan en la parte superior de un sistema operativo host y no son
usados comúnmente en sistemas basados en PC.
Virtualización de Escritorios
Además de la virtualización de aplicaciones industriales, otra área de la virtualización que
está cobrando fuerza es la interfaz de escritorio virtual (VDI). Es comúnmente utilizado en
aplicaciones de escritorio y sus recursos de sistema requeridos están contenidas dentro de un
VDI y se pueden acceder desde un servidor de red.
65
Dado que ninguno de los aplicativos se ejecuta en la máquina local del usuario, pueden ser
usados equipos informáticos de menor costo. Las responsabilidades de Soporte de TI se
reducen y la carga de la copia de seguridad de los datos se elimina por parte del usuario. Los
usuarios de VDI tienen la ventaja añadida y es la de ser capaz de acceder a su escritorio
virtual desde una variedad de otros dispositivos, incluyendo su teléfono inteligente, tableta
u ordenador personal.
Plataformas de virtualización
Muchas empresas están utilizando la virtualización a nivel de empresa para crear
infraestructuras informáticas virtuales enteras que permiten los departamentos de TI
desplegar automáticamente los recursos de computación cuando y donde lo necesiten, con
un mínimo de intervención manual.
Beneficios de la Virtualización para Infraestructura IT, Operaciones e Ingeniería
A continuación, se presentan los siguientes beneficios que se han identificado para cada una
de las áreas de la organización y que hicieron parte de los argumentos con los cuales se
determina la continuidad y actualización del software Wodnerware.
Tabla 4-2. Beneficios de la Virtualización de la Plataforma SCADA.
Área Beneficio Características
IT Consolidación de
Servidores Físicos
La virtualización permite mejor aprovechamiento de
hardware, de modo que se requieren menos servidores físicos
para el propósito.
Reducción de Energía Menos servidores significa menos energía se consume en los
centros de datos.
Extención del Ciclo de Vida Las aplicaciones virtuales tienen un ciclo de vida más largo,
generando más retorno de la inversión para el negocio.
Actualizaciones de
Hardware
Menos actualizaciones de hardware son necesarios en el
tiempo, lo que reduce los requisitos de gastos de capital y la
carga de trabajo
Administración Central El uso de las máquinas virtuales facilita la gestión
centralizada de las aplicaciones ya que menos aplicaciones
residen en servidores locales.
Escritorios Virtuales Permite la eficiencia en la gestión de máquinas de escritorio.
Despliegues Rápidos Dado que el software de aplicación no reside en cada máquina
de escritorio, las nuevas aplicaciones se pueden rotar entre un
gran número de usuarios, de manera más rápida.
Procedimientos de Copias
de Seguridad más eficaces
Todos los datos se mantienen en los servidores corporativos
o en la nube, permitiendo que las operaciones de copia de
66
seguridad más sofisticados para eliminar de manera eficaz la
pérdida de datos.
Operaciones Continuidad del Negocio Varias instancias de la misma máquina virtual pueden
funcionar en un modo de conmutación por fallo automático
(redundancia), para ayudar a asegurar la continuidad del
negocio.
Costos Operacionales Reducción de servidores físicos, permiten reducción en el
capital de retorno.
Soporte Reducción de tiempos de atención a eventualidades que
detengan las operaciones del negocio.
Ingeniería Costos de Desarrollo Reduce los costos de infraestructura de ingeniería, ya que se
requieren menos servidores físicos con menos modificaciones
a través del tiempo, para mantener las aplicaciones
funcionando correctamente.
Velocidad en Desarrollos Instancias virtuales de aplicaciones basadas en objetos, como
System Platform de ArchestrA, se pueden desarrollar y
desplegar más rápido que las aplicaciones convencionales.
Colaboración Desde varias instancias de una máquina virtual, se pueden
ejecutar al mismo tiempo varios desarrolladores, permitiendo
el trabajo colaborativo y eficiente.
Fuente:(Frider, 2012)
Niveles de Disponibilidad de la Plataforma
Cuando hablamos acerca de soluciones de “alta disponibilidad”, típicamente se mencionan
soluciones con componentes de software y/o hardware redundante, que en caso de algún tipo
de evento definido, ofrecen disponibilidad del servicio, después de cierta franja de tiempo.
A continuación se presentan los diferentes niveles de disponibilidad:
Tabla 4-3 Niveles de Disponibilidad de Plataformas
Disponibilidad Descripción Tiempo de Respuesta a Fallos Detalle
Level 0 Sin
redundancia Ninguna
Sin redundancia incorporada en la
arquitectura del sistema.
Level 1 Espera en
Frío
Disponibilidad: 99%
Tiempo de Inactividad
Previsto: 4 dias/año
Sistemas primarios y secundarios,
conmutación por fallo al sistema
secundario, los datos son sincronizados
periódicamente.
Level 2 Alta
Disponibilidad
Disponibilidad: 99.9%
Tiempo de Inactividad
Previsto: 8 horas/año
Se usa la virtualización par los sistemas
primarios y secundarios.
La recuperación de desastres a través de
máquinas virtuales ubicadas en lugares
geográficamente separados.
Level 3 Redundancia
en Caliente
Disponibilidad: 99.99%
Tiempo de Inactividad
Previsto: 52 min/año
Completa sincronización de los sistemas
primarios y secundarios.
Level 4 Tolerancia a
Fallos
Disponibilidad: 99.999%
Tiempo de Inactividad
Previsto: < 5 min/año
Tolerante a fallos de hardware,
conmutación por fallo redundantes
inclusive a instancias de la aplicación.
Fuente: (Frider, 2012)
67
Para el caso de Gases de Occidente, se ha implementado un sistema con disponibilidad tipo
2, específica para recuperación en caso de desastres, como se observa en la Figura 4-3 . La
virtualización para este nivel, ofrece una forma realista y practica de recuperación de las
aplicaciones críticas y sus datos asociados de forma rápida y económica.
Al mantener servidores idénticos y máquinas virtuales idénticas entre sí en el modo de
conmutación por fallos, pero con diferentes ubicaciones geográficas, pueden lograrse
disponibilidades de Nivel 2 o Nivel 3.
Figura 4-3. Arquitectura de Recuperación a Desastres, usando la virtualización ubicados en lugares
geográficamente separados.
Fuente: (Frider, 2012)
Despliegue de los nodos del sistema
El framework de Wonderware permite el despliegue de la aplicación en un solo nodo o en
varios. Se decide desplegar la aplicación de tal manera que cada nodo desempeña una de las
68
tareas o funciones de la aplicación. Cada nodo será un servidor encargado de una tarea
específica. El hecho de separar las tareas entre varios servidores hace que el sistema sea más
robusto y de mantenimiento tipo modular o intercambiable en caso de fallos parciales.
Protocolo de Comunicaciones Concentrador FEPs. Con el fin de establecer un alto grado
de conectividad entre los FEPs y la plataforma de servidores del software SCADA se ha
definido usar el protocolo MODBUS TCP, el cual nos permite realizar gestión remota de los
equipos a través de la red corporativa a la cual estarán conectados los equipos. La técnica
usada de consulta/respuesta en la que se basa el protocolo Ethernet, encaja perfectamente
con la naturaleza maestro/esclavo de modbus. El empleo del protocolo abierto Modbus con
TCP proporciona una solución para la gestión desde unos pocos a decenas de miles de nodos.
En cuanto a las prestaciones de un sistema Modbus TCP/IP, dependen básicamente de la red
y el hardware, en cuanto a tiempos de respuesta en internet, que no siempre serán las
deseables para un sistema de control, sin embargo pueden ser suficientes para la
comunicación destinada a depuración y mantenimiento, evitando así desplazamientos al
lugar de la instalación. Si se dispone de una intranet de altas prestaciones con conmutadores
Ethernet de alta velocidad, la situación es completamente diferente.
En teoría, MODBUS® TCP/IP, transporta datos hasta 250/(250+70+70) o alrededor de un
60% de eficiencia cuando se trasfieren registros en bloque, y puesto que 10 Base
T proporciona unos 1.25 Mbps de datos, la velocidad de transferencia de información útil
será:
1.25M / 2 * 60% = 360000 registros por Segundo
En 100BaseT la velocidad es 10 veces mayor. Esto suponiendo que se están empleando
dispositivos que pueden dar servicio en la red Ethernet aprovechando todo el ancho de banda
disponible.
Además, con la disminución del costo de los ordenadores personales y el desarrollo de redes
69
Ethernet cada vez más rápidas, permite elevar las velocidades de funcionamiento,
a diferencia de otros buses que están inherentemente limitados a una sola velocidad.
Organización de las señales de los FEPs: El modelo de comunicación es mediante tabla de
datos compartida, la cual es consultada y escrita por todos los equipos que manejan el mismo
protocolo de comunicación, como se observa en la Figura 4-4. Periódicamente los equipos
actualizarán su información en estas tablas, donde las señales de todas las remotas se
almacenarán por número de RTU en una columna previamente asignada.
Figura 4-4. Representación Gráfica de las tablas de almacenamiento temporal de los datos recolectados de las
estaciones remotas en FEP.
Fuente: Elaboración Propia.
4.2.2. Planificación del Ambiente Virtual
Partiendo de la premisa por parte del cliente del uso de un ambiente virtual para alojar los
servidores que hacen parte de la plataforma y que infraestructura virtual está configurada
con un hypervisor tipo VSphere de VMware, se presenta a continuación el diseño de la
arquitectura de todo el sistema SCADA. En la Figura 4-5 se presenta como la plataforma
está compuesta básicamente por 3 instancias:
- El entorno de la aplicación SCADA Servidor
- El entorno de aplicación SCADA Cliente
70
- El entorno de la aplicación SCADA para desarrollo y pruebas.
Flujo de información bidireccionalFlujo de información unidireccionalFlujo de información bidireccional entre equipos del mismo sistemaEnlace de Comunicación InalámbricoEquipos que interactúan directamente con Wonderware System Platform
Equipos que interactúan indirectamente con Wonderware System Platform
Equipos que consultan información de Wonderware System Platform
Firewall aplicación Web Server
System Platform Server Environment.
MODBUS TCP-IP
SUITE LINK
CEOGAS
File Server
COCLOGDOFS14
?
2 34
5
System Platform Development and Client Environment.
1
Ingeniero Balance de Gas
Comité de Gerencia
System Platform Server Environment. Estación Ambiente de Desarrollo.
COCLOGDOAP63
8 Threads8GB RAM
120 GB DD
Front End Processors ACE3600 Motorola
Front End Processor 1FEP 6000MorotolaACE3600
Front End Processor 2FEP 7000MorotolaACE3600
Front End Processor 3FEP 8000MorotolaACE3600
Front End Processor 4FEP 9000MorotolaACE3600
COCLOGDOAP23
2 Threads4GB RAM80 GB DD
COCLOGDOAP62
4 Threads4GB RAM60 GB DD
COCLOGDOAP44
4 Threads4GB RAM60 GB DD
COCLOGDOBD08
4 Threads8GB RAM
160 GB DD
COCLOGDOAP38
4 Threads8GB RAM
120 GB DD
COCLOGDOAP37
2 Threads4 GB RAM40 GB DD
COCLOGDOVT08
4 Threads4 GB RAM80 GB DD
COCLOGDOVT07
4 Threads4GB RAM80 GB DD
Figura 4-5. Estructura Plataforma SCADA Gases de Occidente S.A. E.S.P., implementada en la
actualización.
Fuente: Elaboración Propia.
Las recomendaciones que se adoptaron en cuanto a los requerimientos de hardware y
software para las máquinas tanto virtuales como tipo host para el ambiente seleccionado para
la compañía (Nivel 2), son los siguientes:
Ambiente de Producción SCADA Cliente y Servidor
Máquina Virtual 1: Nodo Historian
Procesador Host Compatible para 2 a 4 Cores.
CPUs Virtuales 4 vCPUs
Sistema Operativo Windows Server 2008 R2 Standard
Memoria 8 GB
Almacenamiento 200 GB
71
Productos de System Platform Instalados Historian
Máquina Virtual 2: Nodo Application Server
Procesador Host Compatible para 2 a 4 Cores.
CPUs Virtuales 4 vCPUs
Sistema Operativo Windows Server 2008 R2 Standard
Memoria 8 GB
Almacenamiento 100 GB
Productos de System Platform Instalados Application Server
Máquina Virtual 3: Nodo Intouch Terminal Services
Procesador Host Compatible para 2 a 4 Cores.
CPUs Virtuales 2 vCPUs
Sistema Operativo Windows Server 2008 R2 Standard
Memoria 4 GB
Almacenamiento 80 GB
Productos de System Platform Instalados Intouch con Terminal Services Habilitado
Máquina Virtual 4: Nodo 1 Application Server Runtime
Procesador Host Compatible para 2 a 4 Cores.
CPUs Virtuales 2 vCPUs
Sistema Operativo Windows Server 2008 R2 Standard
Memoria 4 GB
Almacenamiento 80 GB
Productos de System Platform Instalados Application Server Runtime e Intouch
Máquina Virtual 5: Nodo 2 Application Server Runtime
Procesador Host Compatible para 2 a 4 Cores.
CPUs Virtuales 2 vCPUs
Sistema Operativo Windows Server 2008 R2 Standard
Memoria 4 GB
Almacenamiento 80 GB
Productos de System Platform Instalados Application Server Runtime
Máquina Virtual 6: Nodo Information Server
Procesador Host Compatible para 2 a 4 Cores.
CPUs Virtuales 1 vCPUs
Sistema Operativo Windows Server 2008 R2 Standard
Memoria 4 GB
72
Almacenamiento 80 GB
Productos de System Platform Instalados Information Server
Máquina Virtual 7: Nodo Historian Client
Procesador Host Compatible para 2 a 4 Cores.
CPUs Virtuales 1 vCPUs
Sistema Operativo Windows 7 Enterprice
Memoria 4 GB
Almacenamiento 80 GB
Productos de System Platform Instalados Historian Client
Ambiente de Desarrollo SCADA Desarrollo y Pruebas
Máquina Virtual 1: Nodo Historian
Procesador Host Compatible para 2 a 4 Cores.
CPUs Virtuales 4 vCPUs
Sistema Operativo Windows Server 2008 R2 Standard
Memoria 4 GB
Almacenamiento 80 GB
Productos de System Platform Instalados Historian
Máquina Virtual 2: Nodo Application Server
Procesador Host Compatible para 4 a 8 Cores.
CPUs Virtuales 4 vCPUs
Sistema Operativo Windows Server 2008 R2 Standard
Memoria 8 GB
Almacenamiento 100 GB
Productos de System Platform Instalados Application Server
4.3. Aplicación SCADA
A continuación se presenta el diseño de la aplicación SCADA. Esta aplicación permite la
supervisión de las estaciones remotas, la recolección, almacenamiento y posterior consulta
de los registros de consumo hora – hora, diarios y máximos y mínimos en base de datos,
así como la generación de reportes consolidados y la visualización mediante aplicación web
del estado actual de cada una de las estaciones remotas.
73
La descripción de diseño se realiza mediante diagramas UML. Se iniciará con los casos de
uso, el diagrama de clases, para luego culminar con los diagramas de secuencia.
4.3.1. Casos de Uso
Actores del Sistema
Operador Centro de Control
Ingeniero SCADA
Ingeniero Balance Gas
Directivo
Figura 4-6. Actores del Sistema SCADA
Fuente: Elaboración Propia.
Para nuestro sistema hay cuatro actores distintos. El operador de centro de control, el
ingeniero SCADA, el ingeniero de Balance de Gas y el Directivo. Esto es porque cada actor
o tipo de usuario utiliza funcionalidades distintas del sistema SCADA.
El directivo utiliza la aplicación para obtener información de consolidados de consumo o el
estado especifico de alguno de los nodos ya sea puerta de entrada (City Gates) o de
distribución.
El ingeniero de Balance de Gas utiliza la aplicación para la revisión detallada del
comportamiento de consumo en cada uno de los nodos de la red de distribución y la
configuración de parámetros propios de medición de las estaciones reguladoras.
El ingeniero SCADA utiliza la aplicación, para el monitoreo y seguimiento de la integridad
del gasoducto, es decir de consulta de tendencias históricas, definición de cierres de actuador,
reconocimiento y trazabilidad de alarmas, cambios de parámetros de configuración de los
correctores electrónicos por modificaciones en las estaciones reguladoras, ajustes de set
points.
74
El operador de centro de control utiliza la aplicación para la consulta de tendencias históricas
de variables de medición específicas, visualización de variables actuales de las estaciones
reguladoras y el reconocimiento de alarmas durante la operación.
Diagrama de Casos de Uso
Operador
Centro de Control
Ingeniero
SCADA
Ingeniero
Balance Gas
Directivo
Interfaz Hombre Máquina
(HMI)
Bases de Datos Cuenta
Balance y Reportes
Web Server
Figura 4-7 Diagrama de Casos de Uso
Fuente: Elaboración Propia.
Como se observa en la Figura 4-7, existen tres casos de uso de Interfaz Hombre Máquina
(HMI), bases de datos y reportes y Web Server. En el caso de uso de HMI tenemos dos
escenarios, el de la visualización y reconocimiento de alarmas por parte del operador de
centro de control y el de visualización y supervisión y modificación de parámetros de
configuración de los nodos de distribución, por parte del ingeniero SCADA.
75
En el caso de Bases de Datos y Reportes, tenemos también dos escenarios, las consultas de
información por parte del Directivo y verificación y seguimiento de la calidad de la
información por parte del ingeniero de Balance de Gas.
En el caso de Web Server, se presentan tres escenarios, la visualización por parte del
ingeniero SCADA, la visualización por parte del ingeniero de Balance de Gas y la
visualización por parte del Directivo.
A continuación detallaremos cada uno de estos escenarios.
- Caso de uso Interfaz Hombre Máquina, escenario de consulta por parte del Operador
de Centro de Control.
o El usuario visualiza las variables actuales de cada uno de los nodos de
distribución configurados.
o Realiza consulta de tendencias históricas de variables de medición puntuales
durante la operación.
o Realiza reconocimiento de alarmas durante la operación para seguimiento de
eventualidades durante la operación.
- Caso de uso Interfaz Hombre Máquina, escenario de consulta por parte del Ingeniero
SCADA.
o Realiza consultas de tendencias históricas, para evaluar comportamiento del
nodo de distribución.
o Realiza cierres de actuador, de acuerdo al evento presentado durante la
operación, para garantizar la integridad del gasoducto.
o El usuario visualiza las variables actuales de cada uno de los nodos de
distribución.
o Realiza reconocimiento y seguimiento de alarmas y eventos presentados.
o Realiza cambios de parámetros de configuración para alarmas (Set Points).
o Realiza cambios de cromatografía, de acuerdo a actualización de la
composición de gas para la medición volumétrica.
- Caso de uso Bases de Datos Cuenta Balance y Reportes, escenario de consulta por
parte del Ingeniero de Balance de Gas.
76
o Realiza consultas a la base de datos de Cuenta Balance, para la generación
de reportes de integración de sumatoria de registros horarios y diarios, para
la nominación diaria de gas y subasta del bien energético.
o Entrega de reportes de consumo diario y horario de los clientes regulados y
no regulados.
o Consulta de Base de Datos de Current Day, para seguimiento hora a hora del
consumo registrado por los clientes regulados y no regulados, para
suministros extemporáneos.
o Consulta de reporte consolidado de consumo del día D-1, para sugerencias de
topes de negociación y subasta del bien energético, de acuerdo al
comportamiento histórico.
- Caso de uso Bases de Datos Cuenta Balance y Reportes, escenario de consulta por
parte del Directivo.
o Visualización de reportes de integración de sumatoria de registros horarios y
diarios, para la nominación diaria de gas y subasta del bien energético.
o Visualización de reportes de consumo diario y horario de los clientes
regulados y no regulados.
o Visualización de reporte consolidado de consumo del día D-1, para toma de
decisiones en cuanto a topes de negociación y subasta del bien energético, de
acuerdo al comportamiento histórico.
- Caso de uso Web Server, escenario de consulta por parte del Ingeniero SCADA.
o Visualización de variables actuales de estaciones, cuando no hay
disponibilidad de servidor dedicado de HMI.
- Caso de uso Web Server, escenario de consulta por parte del Ingeniero Cuenta
Balance.
o Visualización de variables actuales de estaciones, para validar estado de
medición de la estación reguladora.
- Caso de uso Web Server, escenario de consulta por parte del Directivo
o Visualización de variables actuales de estaciones de manera remota, en caso
de eventualidades que sean de consideración para la continuidad del negocio.
77
Diagrama de Clases
El diseño de la aplicación sigue básicamente una premisa, crear un modelo de la planta con
las estaciones remotas. De esta manera lo que se busca es reproducir lo que nos interesa de
la planta en la plataforma, para luego historizar y realizar la consolidación de datos pertinente
para las bases de datos y los reportes.
Figura 4-8 Diagrama de Clases
Fuente: Elaboración Propia.
Este es el dominio de la aplicación SCADA. Vemos que toda la información se recoge en
los objetos que modelan las estaciones remotas Motorola. Estos se encargan de historizar y
hacer cálculos para obtener la información que se desea procesar.
4.3.2. Acondicionamiento del diseño a la herramienta usada.
A continuación se realiza el acondicionamiento del diseño en la herramienta SCADA: El
Framework System Platform de WOnderware.
Las clases generadas en el dominio se han adaptado a las clases del framework donde serán
contenidas. Los diagramas de secuencia se adaptan al funcionamiento de este framework
(los objetos utilizan un ciclo de “scan”). También se han utilizado 4 bases de datos diferentes
para la historización, las alarmas y eventos, cuenta balance y Current Day. Cada una de estas
bases de datos con requerimientos de tiempos de procesamiento diferentes.
El framework System Platform de Wonderware
78
A continuación se detalla el funcionamiento del framework, en lo que se ha referido al
dominio, centrándonos en el diseño y dejando de lado aspectos técnicos de la arquitectura.
System Platform Server Environment.
Wonderware Historian Server (25000 I/
O)Wonderware Application Server
Wonderware Information Server
Wonderware Info Server Adv
Client
Wonderware MBTCP
DAServer
3rd Party Data SourcesS/W
Applications3rd Party Controllers
System Platform Client Environment.
Intouch
ViewerIntouch For System Platforn Wonderware Historian Client Cuenta Balance
Current
DayReporte PD
Reportes Consolidados
System Platform Development
Wonderware Historian ClientWonderware IntouchWonderware
Historian
Wonderware
IDE
Figura 4-9 El Framework System Platform de Wonderware, de acuerdo a la aplicación de Gases de Occidente
S.A. E.S.P.
Fuente: Elaboración Propia.
El framework agrupa distintas aplicaciones como se puede apreciar en la figura. El modelado
de la aplicación y su lógica se encuentran en el Application Server. En este servicio está
alojado el dominio donde se controlan el resto de acciones, como la adquisición de señales
mediante aplicaciones de Device Integration o la historización de datos mediante el
Historian.
La Galaxia
Para la herramienta que se ha usado, Wonderware System Platform, la aplicación se
denomina “Galaxia”. Una “Galaxia” es el entorno de producción, incluye todos los
componentes y nodos del sistema. Está compuesta por un conjunto de “platforms”,
“engines”, “templates” e instancias u objetos y un espacio de nombres para todos sus
79
elementos. Existe una base de datos que guarda todas las aplicaciones o galaxias. El espacio
de nombres y los valores de los identificadores definen una aplicación Wonderware
Application Server. El espacio de nombres permite referenciar desde cualquier script u
objetos de cualquier nodo, otro objeto sin necesidad de indicar la localización de este último.
La Galaxia gestiona también los temas de seguridad (permite asociar roles y grupos con
acceso a ciertos elementos de la aplicación) y de licencias (se comprueba que la licencia es
válida para ejecutar la aplicación en cualquiera de los nodos).
Attributes
UDAs, scripts,
I/O tags, and so on
Application Objects
Devices, external data access
Container Application Objects
Higher-level devices, contained names.
Galaxy
Single namespace, all configuration
Platform
Computer, load distribution, HW dignostics
Engine
Scan rate, execution order
Figura 4-10 La Galaxia y su contenido.
Fuente: (Invensys Systems, Inc., 211, 2012)
Diagrama de Clases de la Aplicación
Se utilizan conceptos similares a la programación orientada a objetos, pero no es
exactamente lo mismo. Para el modelado de un sistema en la aplicación, existen los
“templates” que son como las clases en programación orientada a objetos. Estos templates
deben ser instanciados para obtener objetos que se ejecutan en la aplicación.
80
Los conceptos similares a la programación orientada a objetos son la herencia y que una
clase (o template) puede contener atributos, métodos y otros objetos. Existe herencia entre
clases, pero no hay herencia múltiple.
Una de las características que diferencian este tipo de aplicación de la programación
orientada a objetos es el hecho de que un “template” puede tener atributos o scripts (métodos)
bloqueados. Cuando un “template” tiene un atributo o un método bloqueado, toda
modificación del atributo o del método se propaga a las instancias de este “template”. Pero
si este atributo o método no se encuentra bloqueado, los cambios no se propagarán a las
instancias creadas antes de la realización de cambios. A continuación se presenta el
diagrama de clases de la aplicación.
Galaxy Objects
AutomationObjects
System Objects Domain Objects
PlatformObjectsEngineObjects AreaObjects
AppEngine WinPlatform Area
Application Objects
AnalogDevice
DiscreteDevice
Field Reference
Switch
User-Defined
Device Integration
Objects (DIObjects)
FS Gateway
TCP Network
FEPs
And so on
Figura 4-11. Diagrama de clases de una aplicación Wondeware Application Server
Fuente: (Invensys Systems, Inc., 211, 2012)
El diseño de la aplicación, parte de este diagrama de clases. Se utilizaran básicamente 3 tipos
de objetos para crear la aplicación. Estos tipos de objetos o “templates” son:
- Application Templates: Objetos para modelar, contienen atributos, métodos y otros
objetos.
81
- Device Integration Templates: Se encargan de la comunicación con elementos
externos de la aplicación. Ejemplo de esto es la conexión con los FEPs.
- System Template: Representan partes del sistema en sí, pero no su dominio. Se
utilizan para montar la arquitectura y desplegar la aplicación. Existen los
WinPlatformsObjects para desplegar en un nodo y monitorizar el estado del nodo.
Existen también los AppEngine Objects. Estos templates contienen los objetos que
ejecutarán:
o La aplicación,
o El modelado de la planta,
o Inicializar los objetos que se tienen desplegados,
o Controla los ciclos de scan (adquisición de datos) de los objetos
Adicionalmente también están las Áreas, que agrupan objetos lógicos para representar partes
de la planta física. Un área recoge todas las alarmas de los objetos que contiene y se pueden
jerarquizar distintas áreas de manera que se pueda realizar un tratamiento de alarmas
jerarquizado.
De forma simple, se usan entonces Application Templates, Áreas y Device Integration
Templates para modelar nuestro modelo de planta y crear el dominio completo del sistema
SCADA. El resto de tipos de objetos nos servirán de apoyo para realizar el montaje de la
arquitectura. A continuación se presenta el diagrama de clases, con la respectiva adaptación
al framework.
82
Figura 4-12 Diagrama de Clases adaptado al Framework
Fuente: Elaboración Propia.
Diagramas de Secuencia
A continuación se presenta el funcionamiento de la aplicación mediante diagramas de
secuencia. Estos diagramas, por pertenecer a la fase de diseño están simplificados para
centrarnos en el funcionamiento general.
- Diagrama de Secuencia Variables Actuales
A cada ciclo de polling los objetos Motorola Actuales actualizan su estado, Primero
consultan los datos almacenados en los FEPs y bases de datos del proceso. Seguidamente
realizan el cálculo de conversión de unidades de medida para los datos que lo requieren y
finalmente historizan su estado. Estos ciclos de escaneo son controlados por el contenedor
“ApplicationEngine” de los objetos lógicos que representan las estaciones remotas.
83
Figura 4-13 Diagrama de secuencia actualización estado variables actuales.
Fuente: Elaboración Propia.
- Diagrama de Secuencia Registros
El diagrama de secuencia de registros muestra el proceso de iteración de solicitud de
registros hora-hora, diarios y máximos y mínimos, los cuales están configurados de tal
manera que se activan a cortes horarios específicos y pueden ser pedidos por demanda, una
vez se consolide la información en la base de datos de cuenta balance.
Figura 4-14 Diagrama de secuencia solicitud e historización registros.
Fuente: Elaboración Propia.
84
- Diagrama de Secuencia Visualización de Variables Actuales HMI
El diagrama de secuencia de visualización de variables actuales en el HMI, muestra la
interacción ya sea entre el operador de centro de control o el ingeniero SCADA y la
aplicación intouch viewer del sistema SCADA. Cuando aparece una alarma, esta es mostrada
en la aplicación cliente. El operador puede, previo control de usuario, confirmar la alarma.
La acción de confirmación de la alarma se guarda en un histórico junto con los datos de fecha
y nombre del usuario.
Figura. 4-15 Diagrama de secuencia de visualización de variables actuales en HMI.
Fuente: Elaboración Propia.
- Diagrama de Secuencia Generación Reporte PD
El diagrama de secuencia de generación de Reporte PD, presenta el proceso mediante el cual
se genera uno de los reportes consolidados de consumo de gas natural. Este reporte recopila
el valor del Previous Day de cada una de las estaciones remotas y lo consolida en un solo
archivo, en el cual se realiza la sumatoria de cada uno de los totales generados por cada sitio.
Este consolidado, una vez generado, se envía correo electrónico a un listado de usuarios
configurado previamente.
85
Figura 4-16 Diagrama de Secuencia, generación Reporte Consolidado Previous Day.
Fuente: Elaboración Propia.
Historización de Señales y Alarmas
En esta sección se realizará un detalle acerca de la historización. De manera preliminar se
puede decir que se utilizan dos bases de datos distintas. Una base de datos historiza las
señales recogidas de los FEPs, los cuales previamente han solicitado los datos a cada una de
las estaciones remotas y los han almacenado temporalmente en sus tablas de registros. Otra
base de datos se utiliza para historizar las alarmas y su confirmación por parte de los
operadores de centro de control.
Para estas dos bases de datos, se guardarán datos cuando éstos se modifiquen.
Independientemente se pueden visualizar los datos como si se hubieran guardado en
intervalos de tiempos fijos, o todos los datos a la vez, pero este aspecto es relativo a la
visualización. Los datos que se historizan por cada brazo de medición, son los que han sido
descritos en el capítulo tres, de acuerdo a la siguiente clasificación:
Variables actuales: De acuerdo a la descripción realizada en, Tabla 3-6, Tabla 3-7 y Tabla
3-8.
Registros Hora- Hora: De acuerdo a la descripción realizada en, Tabla 3-11.
Registros Diario: De acuerdo a la descripción realizada en, Tabla 3-12.
Registros Máximos y Mínimos: De acuerdo a la descripción realizada en, Tabla 3-13.
86
El Reporte Consolidado de Previous Day
El reporte Consolidado de Previous Day, o Reporte PD indican el consumo total de gas
natural generado en toda la red de distribución, el día inmediatamente anterior. La
información consolidada en este reporte es organizada por localidades y municipios, tipo de
estaciones y los sitios que presentaron algún tipo de novedad en sus registros para ser
revisado en detalle, para el ajuste de pérdidas en el balance general de gas.
4.3.3. Ventajas de la Utilización de Framework System Platform de
Wonderware.
Como resumen de esta sección, que ha sido dedicada al diseño de la aplicación SCADA, se
remarcan las ventajas de utilizar la herramienta seleccionada.
Como ventaja principal referente al diseño tenemos la perfecta integración de todas las
aplicaciones de la herramienta SCADA. Es decir, a la hora de crear una aplicación SCADA
con el System Platform de Wonderware, el analista /programador no debe preocuparse de
cómo integrar los FEPs con la base de datos y con las clases de dominio o con las
aplicaciones cliente, ni preparar interfaces para comunicar entre los objetos de la aplicación.
Todas las herramientas bajo el Framework quedan totalmente integradas y no hace falta
diseñar ninguna clase controlador, interface u observador. Esto facilita enormemente la fase
de diseño reduciendo en tiempo y complejidad. Se puede decir que la aplicación SCADA
utiliza el patrón de diseño modelo-vista-controlador, pero solo está en enfocarse en cuanto
al diseño del modelo y de las vistas (para el caso del entorno HMI). La herramienta ya tiene
implementado un controlador (que para nuestro caso sería La Galaxia), donde se ejecutan
los objetos (o clases) creados. La Galaxia, es quien controla los ciclos de escaneo, la
ejecución de scripts y la comunicación entre los objetos (todos los objetos se ven entre sí).
Otra ventaja importante es la predisposición de la herramienta para aplicaciones de
adquisición de datos y supervisión, lo que facilita aún más el diseño y la implementación.
Los objetos o clases creados derivan todos de diferentes tipos de objetos ya preparados para
este tipo de aplicaciones. Al estilo de la programación orientada a objetos, las clases de las
que se hereda contienen atributos y métodos. Pero estas clases están preparadas además para
87
diferentes tipos de atributos (de entrada/salida para conectar con fuentes de datos o PLCs y
otros objetos creados por el usuario), para scripts que se ejecutan según condiciones sobre
los atributos y todo ello sincronizado con los ciclos de escaneo de cada “Engine” o
contenedor de objetos.
Hay que remarcar que para crear los objetos o clases no hace falta escribir código, sólo en
los métodos. Se dispone de unas pantallas o formularios donde se modifican las
características de los atributos y scripts del objeto, añadiendo conexión con la base de datos
histórica, definiendo alarmas sobre condiciones o valores de atributo e interconectando los
atributos con fuentes de datos u otros objetos. Todo esto, además de facilitar el diseño y la
implementación puesto que solo se escribe código al programar los métodos o scripts, facilita
la estandarización de estas aplicaciones. Es decir, que todas las aplicaciones creadas con
esta herramienta poseen clases similares, donde su configuración o parametrización se hace
de la misma forma. Así pues se consigue que cualquier técnico de esta herramienta pueda
entender una aplicación sin necesidad de profundizar mucho. Esto ayuda a independizar la
aplicación y el sistema de los profesionales que lo han desarrollado.
Se remarca un aspecto técnico muy importante, la rapidez y fiabilidad del sistema de
historización. Este sistema de historización garantiza tiempos de almacenamiento de hasta
1ms y sistemas de recuperación en caso de fallo de la base de datos o de la comunicación.
Todo esto sin ningún esfuerzo de programación y configuración. Este aspecto se vuelve a
mencionar puesto que es una de las partes más críticas de una aplicación SCADA y aquí se
adquiere una ventaja significativa para el desempeño de la plataforma.
4.4. Aplicación Cliente
La aplicación cliente está dedicada a la interfaz gráfica con el usuario. Su función es mostrar
los datos de la aplicación SCADA e interactuar con el usuario.
La aplicación SCADA tiene 8 casos de uso generales que son:
- Panel Principal
88
- Consulta de Alarmas y Eventos
- Consulta de Tendencias Históricas
- Visualización Tiempo Real
- Consulta y configuración de Set Points.
- Site Map
- Consulta de Máximos y Mínimos
- Consulta y Configuración de Cromatografía.
Por un lado está el HMI (Human Machine Interface) para que el usuario interactúe en la
supervisión en tiempo real con la aplicación SCADA en planta. Por otro lado, una aplicación
web que muestra los valores actuales de cada una de las estaciones remotas a modo de
consulta, cuando no se encuentra en el centro de control o en las estaciones de trabajo
definidas para los HMI. Esta aplicación web se integra en la intranet de la planta. A
continuación se presenta una descripción de cada uno de estos casos.
4.4.1. Diseño del HMI
En esta sección se explica el diseño de las pantallas del HMI para los casos de uso
mencionados previamente. Cada uno de los casos, tiene una pantalla específica para su
interacción con el usuario. El panel principal, no solo contiene el detalle de la ubicación
geográfica de cada una de las estaciones remotas, sino que se complementa con un
compendio de 40 mini mapas, que presentan acercamientos de la ubicación de cada uno de
los sitios de monitoreo y cada sitio, está animado con una representación típica del diseño
electromecánico de la estación, donde se visualizan cada una de las variables actuales del
proceso.
Wonderware Intouch
La herramienta Intouch 11 de Wonderware®, es una aplicación que permite hacer pantallas
de control /supervisión SCADA. Originalmente Intouch conformaba la aplicación SCADA
con la recogida de señales, historización de datos y alarmas y finalmente la visualización.
89
Con el nuevo Framework de Wonderware esta aplicación (que ha mantenido sus
funcionalidades), está destinada básicamente a la visualización. Las tareas de conexión a los
FEPs, recogida de datos y envío a las bases de datos de historización de eventos y alarmas
quedan cubiertas por varios elementos de IAS (Industrial Application Server) que es donde
se ejecuta la aplicación SCADA de este proyecto.
Así pues el Intouch se utiliza en este proyecto para la creación de las pantallas del HMI y
también para su ejecución. Intouch dispone de la aplicación Window Maker donde se
construyen las pantallas gráficas y de la aplicación Window Viewer donde se ejecutan.
- Partes Comunes de las Pantallas del HMI
Las pantallas gráficas del HMI tienen partes comunes. Hay una pantalla de inicio que
permite navegar hacia las dos pantallas diseñadas. Todas las pantallas, tienen un layout
común. Dentro de esta disposición habrá elementos que compartirán todas las pantallas
(banner superior, control de usuario, menú de selección) y otros específicos (pantalla central
y menús específicos, de acuerdo a la funcionalidad).
Layout: La disposición de las diferentes partes se organiza con un layout. Este layout
dispone las partes compartidas por las dos pantallas y las partes específicas siguiendo una
lógica común. Esta disposición será la siguiente:
90
1680
10
50
BANNER SUPERIORANAGRAMA
CLIENTE
MENU HORIZONTAL
BANNER ALARMAS
PANTALLAMen
u V
erti
cal
Figura 4-17 Layout Común de las pantallas del HMI
Fuente: (RAYCO Ltda., 2014)
Barra de Encabezado
Figura 4-18 Barra superior Panel Principal
Fuente: (RAYCO Ltda., 2014)
Usuario Registrado: Se visualiza el usuario que actualmente se encuentra registrado en la
sesión. Recuerde que este usuario es personal e intransferible, de acuerdo a las políticas de
seguridad del área de Infraestructura de T.I. de Gases de Occidente S.A. E.S.P.
Menú de Acceso Rápido: Se encuentran los accesos directos para las siguientes
funcionalidades:
91
- Inicio: Cierra la sesión actual y re-direcciona al frontal de la aplicación.
- Mapa: Retorna al panel principal.
- Históricos: Direcciona hacia la funcionalidad de consulta de tendencias de
variables de medición y registros de consumo de las estaciones.
- Alarmas: Direcciona hacia la funcionalidad de consulta de alarmas.
- Login: Despliega la ventana de login para realizar cambio de usuario, sin
necesidad de cerrar la aplicación.
Fecha y Hora Plataforma: Se visualiza constantemente la fecha y hora que registra la
plataforma.
Barra Menú Funcionalidades
Esta barra la encontrará a disposición permanente, a medida que vaya ingresando en
los diferentes paneles de la plataforma. A continuación se presenta una descripción general
de cada icono y se describirán con mayor detalle en las siguientes secciones.
Figura 4-19 Descripción General de Iconos Menú de Funcionalidades.
Fuente: (RAYCO Ltda., 2014)
92
Barra Alarmas
Figura 4-20. Barra Alarmas Actuales
Fuente: (RAYCO Ltda., 2014)
En esta barra se presentan las ultimas alarmas generadas y que se encuentran ya sea en
proceso de reconocimiento o que han sido reconocidas pero que aún no se han restablecido.
Panel Principal
Figura 4-21 Mapa General Red de Distribución
Fuente: (RAYCO Ltda., 2014)
En el panel principal se encuentra el mapa de los municipios del Valle del Cauca y del Cauca
de la red de distribución de Gas Natural, visto desde cada una de las cabeceras municipales.
A través de cada nodo de cabecera municipal, se inicia la navegación en la herramienta, para
localizar la estación reguladora que desea consultarse.
Existen algunos nodos que contienen un alto número de estaciones, como son los siguientes:
93
Cartago
Tuluá
Buga
Yumbo
Palmira
Cali
Parque Industrial
Panel Cabecera Municipal Cali
En el caso especial de Cali, una vez que se ingresa a esta cabecera municipal, encontrará a
continuación el siguiente panel:
Figura 4-22. Panel Cabecera Municipal Cali
Fuente: (RAYCO Ltda., 2014)
Este panel está compuesto por:
Tabla Consolidada Estaciones Reguladoras
94
Se presenta el consolidado de los valores actuales de las siguientes variables de medición
de las 20 estaciones reguladoras del distrito de Cali:
Figura 4-23 Formato Tabla Consolidado Cali
Fuente: (RAYCO Ltda., 2014)
Presión de Entrada
Presión de Estación
Presión de Salida
Temperatura
Flujo
Mapa Distrito de Cali
En este panel se encuentra el mapa del Distrito de Cali de la red de distribución de Gas
Natural, visto desde cada una de las estaciones reguladoras. A través de cada nodo de
estación reguladora, se continúa con la navegación en la herramienta, para localizar las
estaciones reguladoras de clientes industriales que se encuentran geográficamente cerca al
nodo.
95
Figura 4-24 Mapa Distrito de Cali
Fuente: (RAYCO Ltda., 2014)
Cuadro de Convenciones
Se encuentran las siguientes indicaciones:
Estado de Comunicaciones
Distribución Calibre Red de Acero
Botones de Acceso a Consolidados Tipo Estación
En el panel principal, también se encuentra los siguientes botones de acceso:
96
Figura 4-25. Botones de Acceso Consolidados
Fuente: (RAYCO Ltda., 2014)
Consolidado de Industrias
Este botón conduce a la tabla de consolidado de los valores actuales de las estaciones tipo
Clientes Industriales.
Figura 4-26. Panel Consolidado Estaciones Clientes Industriales
Fuente: (RAYCO Ltda., 2014)
Consolidado EDS
Este botón conduce a la tabla de consolidado de los valores actuales de las estaciones tipo
Estaciones de Servicio.
97
Figura 4-27. Panel Consolidado Estaciones de Servicio
Fuente: (RAYCO Ltda., 2014)
Consolidado ERM Municipios
Este botón conduce a la tabla de consolidado de los valores actuales de las estaciones tipo
Estaciones Reguladoras de Medición de los municipios interconectados a la red de
distribución.
Figura 4-28. Panel Consolidado Estaciones Reguladores Municipios
Fuente: (RAYCO Ltda., 2014)
98
Panel Alarmas y Eventos
En la barra menú de funcionalidades se encuentra el icono de alarmas y eventos. En este
panel se encuentra un consolidado general de las ultimas 22 alarmas generadas en el sistema.
Figura 4-29. Panel de Visualización Alarmas y Eventos
Fuente: (RAYCO Ltda., 2014)
Aquí se visualizan los siguientes parámetros por cada alarma generada:
Time: Fecha y hora del evento o alarma generado.
Name: Nombre del Tag o variable que ha presentado la alarma.
Value: Valor actual de la variable.
Limit: Valor definido para la generación de la alarma.
State: Estado actual de la alarma, de acuerdo a la siguiente nomenclatura:
o ACK: Estado de alarma reconocida y restablecida. Se muestra en color negro.
o UNACK: Estado de alarma no reconocida y no restablecida. Se muestra en
color rojo.
o ACK_RTN: Estado de alarma no reconocida y restablecida. Se presenta en
color azul.
Panel de Históricos
En la barra menú de funcionalidades se encuentra el icono de históricos. En este apartado,
pueden realizarse la consulta y a la vez se generan las tendencias históricas tanto de las
99
variables de medición, como de los registros de consumo de cada una de las estaciones
remotas.
Figura 4-30. Panel de Visualización y Consulta Históricos
Fuente: (RAYCO Ltda., 2014)
Botones de Acceso a Consolidados Tipo Estación
Este panel está compuesto por:
Figura 4-31. Barra de Herramientas Panel Históricos
Fuente: (RAYCO Ltda., 2014)
Menú Tags configurados
En este menú encontrará las siguientes ventanas:
Servers: Servidor o servidores donde se encuentra alojado el historian (base de datos de la
información histórica de las variables de medición).
100
Tags: Se encuentra con detalle el listado completo de las variables que se están
monitoreando, clasificadas de acuerdo al tipo de señal (análoga, digital).
Figura 4-32 Menú Tags
Fuente: (RAYCO Ltda., 2014)
Área de Visualización
En esta área se encuentra lo siguiente:
Figura 4-33. Área de Visualización
Fuente: (RAYCO Ltda., 2014)
Grilla de visualización, se generan las gráficas correspondientes al tag seleccionado, de
acuerdo al rango de fechas por consultar.
Banner de consolidado, se presenta un resumen de la configuración del tag, como el
nombre, el tipo de señal, direccionamiento de la información, color asignado (para
101
visualización de varias señales), unidad de medida, valor mínimo y máximo del rango de
datos solicitado.
Panel Tiempo Real
Figura 4-34. Panel de Tiempo Real
Fuente: (RAYCO Ltda., 2014)
En este panel se puede realizar seguimiento por cada instante de actualización de datos, de
una variable de medición.
Panel Set Points
En este panel, pueden realizarse la consulta y modificación de los valores de set points,
máximo y minino de cada una de las variables de medición (flujo, temperatura y presiones).
Estas modificaciones solo podrán ser realizadas por los perfiles de usuario autorizados, de
acuerdo al Procedimiento de usuarios y perfiles (RAYCO Ltda., 2014).
102
Figura 4-35. Panel de visualización y Configuración de Set Points
Fuente: (RAYCO Ltda., 2014)
Para mayor detalle de cómo realizar cambio de parámetros, consulte el Procedimiento
Consulta, Modificación y Actualización de Set Points (RAYCO Ltda., 2014).
Panel Site Map
Como una herramienta para ubicar las estaciones en el entorno HMI, se ha generado
esta funcionalidad con el fin de que con solo el nombre de la estación, nos ubique en que
zona geográfica se encuentra localizada la ERM.
Para la consulta, las estaciones han sido clasificadas de acuerdo a su diseño, ya sea estación
reguladora de municipio, estación reguladora de Cali, City Gate, Gas virtual, Estación de
Servicio, Cliente Industrial o Válvula.
Figura 4-36. Panel Site Map
Fuente: (RAYCO Ltda., 2014)
103
Para mayor detalle de cómo realizar la búsqueda, consulte el Procedimiento de Consulta en
Site Map (RAYCO Ltda., 2014).
Panel de Máximos Y Mínimos
En esta funcional puede realizarse la consulta de los registros históricos de los valores
máximos y mínimos almacenados de cada corte horario de las estaciones reguladoras de
medición.
Al igual que en el panel de Site Map, las estaciones están clasificadas, de acuerdo al tipo de
estación y de este proceso se genera un archivo .csv, para su posterior uso.
Figura 4-37. Panel de Máximos y Mínimos
Fuente: (RAYCO Ltda., 2014)
Para mayor detalle de cómo realizar la consulta, puede apoyarse del Procedimiento de
Consulta de máximos y mínimos) (RAYCO Ltda., 2014) .
Panel De Ayuda
En este apartado se encuentra la correspondiente documentación para la consulta y apoyo de
los diferentes procedimientos que se requieren realizar en la plataforma, de acuerdo al nivel
de acceso que tienen los usuarios autorizados, tal como se describe en el Procedimiento de
Usuarios y Perfiles (RAYCO Ltda., 2014).
104
Figura 4-38. Panel de Ayuda
Fuente: (RAYCO Ltda., 2014)
Esta documentación se encuentra en formato Acrobat Reader, y solo puede ser de consulta,
no podrá ser copiada o modificada, sin la respectiva autorización por escrito del personal
encargado de la administración de la plataforma.
4.4.2. Diseño de Aplicación Web
La aplicación web está enfocada a visualización de las variables actuales de cada una de las
estaciones remotas. La función principal es por tanto la de mostrar la información necesaria
de manera simple. Esta aplicación web se compone de páginas web navegables desde una
página principal. La herramienta SCADA dispone de un portal web en el que se puede
fácilmente publicar contenidos. Algunos de estos contenidos se generan dinámicamente.
Este portal web se incluirá en la intranet de Gases de Occidente y será consultada por 5
usuarios autorizados para el uso de esta herramienta.
Navegación
Las páginas se ubican dentro del portal web de la herramienta, el Wonderware Information
Server (WIS). La navegación por las páginas se lleva a cabo desde la página principal del
105
portal WIS. Esta página principal se compone de un menú lateral izquierdo con todas las
páginas a las que se puede navegar.
Portal WIS
SCADA Web
Consulta Variables
Actuales
Petición de Polling por
usuario
Figura 4-39 Navigator Map del Portal Web
Fuente: Elaboración Propia
La visualización del SCADA
Esta página mostrará las pantallas de HMI dedicadas a la visualización de variables actuales
de manera simplificada. Estas pantallas sirven para la visualización del estado. Solo es
permitido realizar polling para actualizar los datos, pero no se permite realizar cambios de
cromatografía, set points, o cierres remotos de actuador.
Figura 4-40. Visualización de una estación remota típica desde el portal Web.
Fuente: (RAYCO Ltda., 2014)
106
5. Capítulo 5
Proceso de Implementación
En este capítulo se realiza el detalle de las partes más relevantes de la implementación de
este proyecto. Se observarán partes de los scripts desarrollados, configuración de framework
de Wonderware® y los inconvenientes más relevantes presentados con sus respectivas
soluciones. Se realiza una descripción en la implementación de la aplicación SCADA (los
objetos que representan las estaciones remotas Motorola), para continuar con la
implementación de los clientes (HMI, Portal Web, Reporte PD, Cuenta Balance y Current
day) y finalizando con la arquitectura implementada.
5.1. Implementación de Front End Processor.
A continuación se presenta una descripción general del modo final de configuración de los
Front End Processor del centro de control. De acuerdo a la cantidad de estaciones en campo
instaladas, se han configurado 4 FEPs, en los cuales se han distribuido equitativamente todos
los brazos de medición. Cada FEP tiene asociado un canal de comunicación GPRS y a su
vez, está conectado a la red de datos de Gases de Occidente, por la cual llegan los paquetes
de datos provenientes de los nodos de repetición del sistema de radio, tal como se presenta
a continuación:
Comunicación GPRS.
MDLC
MODBUS TCP-IP 5
LINE 2
Front End Processors ACE3600 Motorola
Front End Processor 1FEP 6000MorotolaACE3600
Front End Processor 2FEP 7000MorotolaACE3600
Front End Processor 3FEP 8000MorotolaACE3600
Front End Processor 4FEP 9000MorotolaACE3600
LINE 3 LINE 4 LINE 5
Figura 5-1. Distribución de Front End Processors Motorola.
Fuente: Elaboración propia
107
Los FEPs, están configurados por parejas de tal forma que en caso de presentar falla uno
de ellos, el otro puede dar soporte a la adquisición de datos de los sitios que estaban activos
en el otro FEP, esto con el fin de garantizar la continuidad del procesamiento de registros y
monitoreo de las variables de medición de cada sitio remoto.
Para la configuración y activación de un brazo de medición, la aplicación diseñada para los
FEPs tiene varios parámetros, con los cuales se establece la ubicación de los datos en las
tablas de memoria temporal, su parametrización, el estado de los medios de comunicación y
el seguimiento a la escritura de los comandos de solicitud de información.
5.1.1. Tabla Mapeo Datos
En esta tabla se configura la activación del sitio remoto que se va a monitorear, de acuerdo
a los siguientes parámetros:
Figura 5-2.Tabla Mapeo Datos.
Fuente: Elaboración Propia
EnSite: En este parámetro se configura la activación o no del sitio. Los estados de activación
son los siguientes:
0: Sitio no habilitado
108
1: Sitio habilitado para solo petición de datos actuales
2: Sitio habilitado para petición de datos actuales y registros
3: Sitio habilitado para petición de datos actuales, registros y MxMn.
SiteID: Se configura el ID RTU que tiene asignado la estación remota.
Brazo#: Para los casos en los cuales las estaciones remotas, tienen configurados varios
brazos de medición, se hace necesario que adicional al ID RTU, se adicione un ID adicional
para la lectura específica de cada brazo.
Ix_SiteTableP: Parámetro que indica la posición de lectura del medio de comunicación que
tiene asociado a nivel de RTU para el enrutamiento de los datos en las tablas de
almacenamiento.
Coor: Parámetro que indica la columna que debe ser consultada para la lectura de los datos
provenientes del brazo de medición configurado.
5.1.2. Tabla Queue Status
En esta tabla se monitorean y canalizan las escrituras de comandos para la petición de datos actuales,
registros, visualización de índices y cierres de actuador. Los parámetros que se monitorean son:
SiteID: Índice RTU asignado a la estación remota, configurado en la tabla Mapeo Datos.
Brazo#: Índice asignado a los brazos de medición habilitados en la estación remota. Se configura en
la tabla Mapeo de Datos.
Coor: Indice asociado a la columna donde se encuentra alojada la información del brazo de medición.
Este parámetro es configurado en la tabla Mapeo Datos.
ComAct: En esta posición se verifica la escritura del comando de cierre de actuador.
ComHor: En esta posición se verifica la escritura del comando solicitud de registros horarios.
ComDia: En esta posición se verifica la escritura del comando solicitud de registros diarios.
ComHMI: En esta posición se verifica la escritura del comando solicitud de actualización de
variables actuales.
109
Inx_ComHMI: En esta posición se verifica el índice del registro ya sea diario, horario o MxMn que
en momento se está solicitando.
Figura 5-3 Tabla Queue Status
Fuente: Elaboración Propia
5.1.3. Tabla Mapeo Canales
En esta tabla se configuran los medios de comunicación asociados a cada brazo de medición.
Figura 5-4 Tabla Mapeo Canales
Fuente: Elaboración propia
110
SiteID: Índice RTU asignado a la estación remota, configurado en la tabla Mapeo Datos.
Brazo#: Índice asignado a los brazos de medición habilitados en la estación remota. Se configura en
la tabla Mapeo de Datos.
Coor: Indice asociado a la columna donde se encuentra alojada la información del brazo de medición.
Este parámetro es configurado en la tabla Mapeo Datos.
Active Link:Medio de comunicación activo en ese momento .
CH1: Canal de comunicación 1 configurado para el brazo de medición.
CH2: Canal de comunicación 2 configurado para el brazo de medición.
CH3: Canal de comunicación 3 configurado para el brazo de medición.
#retraies_P: Numero de intentos de comunicación a realizar en caso de no recibir respuesta,
una vez culminado el tiempo de espera.
5.1.4. Tablas de Almacenamiento Temporal de Datos.
Una vez configurado el sitio en las tablas de comunicación, toda la información correspondiente a la
estación remota puede ser almacenada de manera temporal en las columna asignada al brazo de
medición, con el fin de que cada vez que se refresque o actualice el dato asociado a cada celda, sea
interpretado por la herramienta de integración y posteriormente almacenada en la base de datos de
Historian.
Figura 5-5 Ejemplo de tabla datos temporales de brazos de medición.
Fuente: Elaboración propia
111
Las primeras 18 filas, corresponden a los datos actuales de medición, tal como se describen
a continuación en la Tabla 5-1:
Tabla 5-1 Campos de variables actuales por brazo de medición
Información de Variables Actuales por Brazo de Medición
Clave Ultimo comando enviado para solicitud de datos al brazo de medición.
CoordFEP Índice de Ubicación en Tablas del FEP.
EvDi Palabra de Señales Digitales – Parte 1
EvDi1 Palabra de Señales Digitales – Parte 2
Flujo Valor Instantáneo del Flujo
P_Flow Valor Instantáneo de la Presión de Medición
T_Flow Valor Instantáneo de la Temperatura de Medición
VolCorrLD Valor del Volumen Corregido del día anterior,
VolCorrCD Valor Instantáneo del Volumen Corregido del día.
Factor C Factor de Corrección de la medición volumétrica.
VolCorrAcc Valor del Volumen Corregido acumulado del brazo de medición
Presion2 Valor Instantáneo de la Presión de Entrada del brazo de medición.
AtmExpl Valor Instantáneo de la atmósfera explosiva.
ProtC Valor Instantáneo de la Protección Catódica
Status Palabra de Señal Digital Estado de Aplicación RTU – Parte 1
Status1 Palabra de Señal Digital Estado de Aplicación RTU – Parte 2
MainFail Palabra de Señal Digital Estado de Falla RTU – Parte 1
MainFail1 Palabra de Señal Digital Estado de Falla RTU – Parte 2
Presion3 Valor Instantáneo de la Presión de Entrada del brazo de medición
Frec Valor Instantáneo de la Frecuencia del brazo de medición
AI_Aux1 Valor Instantáneo de la Variable Análoga 1 Adicional del brazo de medición
AI_Aux2 Valor Instantáneo de la Variable Análoga 2 Adicional del brazo de medición
Fuente: Elaboración Propia
De las filas 19 a la 55, se encuentran las variables asociadas a un registro hora – hora, tal
como se describe en la Tabla 3-11. Así mismo, desde la fila 56 a la 92, se encuentran las
variables asociadas a un registro diario, de acuerdo a la Tabla 3-12 y finalmente, desde la
fila 93 a la 111 se estarán almacenando las variables asociadas a un registro de Máximo y
Mínimo, como se ha presentado en la Tabla 3-13.
112
5.2. Implementación de la aplicación SCADA
Esta sección está dedicada a la implementación de la aplicación SCADA. Como se visualizó
en el capítulo de diseño de la aplicación SCADA, se realiza básicamente la tarea de recoger
datos de los FEPs y encapsularlos en objetos que representan el modelo lógico de las
estaciones reguladoras de medición de gas natural. Con estos datos recogidos se realiza la
consolidación del volumen de gas suministrado en dicho nodo de distribución y se historiza
su evolución y correspondientes alarmas.
En concreto la aplicación SCADA se implementa con las herramientas Wonderware
Application Server 4.0 , Industrial SQL Server Historian 11.5 (INSQL) Wonderware
MBTCP DAServer 2.0 (DASMBTCP) e Intouch 11.0.04 de framework de Wonderware
(Wonderware® FactorySuite A2 System environment using the ArchestrA™ infrastructure).
En esta sección se presentarán tambien algunos detalles más relevantes de la configuración
de estas aplicaciones para la implementación de esta aplicación.
El Industrial Application Server (IAS) recoge las señales de los FEPs por medio del servidor
de datos DAServer DASMBTCP. Estas señales recogidas se distribuyen en varios objetos
que se ejecutan dentro del IAS que son la representación lógica de las estaciones reguladoras,
supervisadas por la aplicación. Estos objetos obtienen información a través de estas señales
y las envían al sistema de historización de datos y de alarmas (INSQL y Distributed Alarm
System de Intouch). Estos objetos también preparan los datos para obtener información sobre
el proceso de producción. Todos estos objetos y aplicaciones se ejecutan en el marco de una
“ArchestrA Galaxia” que es el nombre que se da a una aplicación SCADA concreta (sus
objetos, servidores de datos, configuración y despliegue en nodos físicos).
5.2.1. Los Objetos de la Galaxia
Como se había mencionado en el capítulo anterior, una galaxia está compuesta por diferentes
tipos de objetos (o “templates” según la nomenclatura de la herramienta utilizada) según las
diferentes funciones que realiza la aplicación. Están los objetos que representan las
estaciones remotas en la captura de los variables actuales, los objetos que representan la
113
captura de datos de los registros hora-hora, diarios, horarios, los objetos asociados a las
tablas dinámicas para la sincronización de procesos y/o tareas de acuerdo a cada estación
remota. Estos objetos están contenidos en áreas, esto con el fin de realizar una administración
de alarmas no solo a nivel de Set Points de cada una de las señales, sino además del proceso
de ejecución de los objetos contenidos. A continuación se presenta la implementación de
cada clase o template.
Figura 5-6 Visualización Objetos de la aplicación SCADA
Fuente: Elaboración propia
Objeto Motorola
Este objeto es la representación lógica dentro de la aplicación de una estación remota.
Realiza la recolección de datos actuales y lo complementa con los objetos de registros. Envía
las señales pertinentes a la base de datos histórica o de alarmas.
114
El template del objeto tiene tantos atributos de entrada salida (I/O s) como señales que se
reciben de una estación remota. Cada instancia representa una de las variables tanto análogas
como digitales. Hay que indicar para cada atributo la dirección del dato en el servidor
DAServer en cada instancia.
Figura 5-7 Atributos del template del objeto Motorola
Fuente: Elaboración propia
También contiene la publicación obtenida de una de las bases de datos de cierre por medio
del objeto de conexión a bases de datos. Este ítem hace parte de los elementos de
configuración general del template para que sea adoptado por cada uno de los objetos
creados de manera específica. Adicionalmente tiene gráficos embebidos que hacen parte del
HMI, para la representación estructural de la estación remota.
El template del objeto Motorola contiene adicional a los atributos otro objeto, el objeto
Registros. Este objeto obtiene de su contenedor algunos atributos para realizar cálculos, los
cuales son de base para los objetos que se han asociado de manera específica a cada tipo de
registros, Registro (registros hora-hora), RegistroD (registros diarios), Registro_N (registros
de máximos y mínimos).
Cada uno de estos objetos contienen los respectivos scripts que se han diseñado para:
115
- La captura y generación del archivo csv compatible con Historian para alimentar la
base de datos general y que a partir de esta, pueda ser alimentada la base de datos de
cuenta balance.
- Las tareas programadas para las peticiones de cada uno de los tipos de registros, una
vez que se haya generado en la estación remota, es decir, por cada corte horario y/o
diario, se activan estos procesos.
- La identificación de cortes parciales que generan registros adicionales en la base de
datos de la remota por eventos asociados al proceso y que deben ser consolidados
en un solo registro. Esta consolidación, se realiza directamente en la aplicación de
cuenta balance, de acuerdo a las banderas generadas desde estos objetos.
Dada la cantidad de estaciones, los cambios de parámetros de manera específica implicarían
un mayor esfuerzo para el control de cambios de la configuración de cada una de las remotas.
Es por ello que durante la implementación se han generado varios objetos de control, en los
cuales se condensan mediante arreglos, los valores o parámetros de cada sitio, simplificando
procesos propios de la operación. Entre los objetos de control encontramos:
Pantallas HMI
Este objeto contiene los objetos asociados a las pantallas específicas para cambios de
configuración de las estaciones o para el almacenamiento de logs específicos y que son
propios de la operación. Estos son:
Cromatografía: Contiene los scripts necesarios para la actividad de consulta y cambio de
valores en los parámetros de la cromatografía
Sesión: Contiene los scripts que nos permiten el seguimiento de los usuarios que han
ingresado a cada uno de los nodos HMI, para el respectivo control de cambios.
Set Points: El comportamiento de estos scripts es de alguna manera similar a los scripts
asociados a la pantalla de cromatografía. En este caso, se realiza la consulta de los valores
almacenados en el objeto de sincronización de parámetros de las estaciones y los modifica o
los descarga a la estación remota, según sea el tipo de tarea que se vaya a realizar.
116
Tiempo Real: Dado que en esta pantalla se realiza seguimiento continuo de cualquier
variable seleccionada, se han generado scripts con el fin de que el tiempo de polling sea de
mayor frecuencia, para que sea un continuo seguimiento de acuerdo a la dinámica de la
situación presentada.
Objeto Reporte PD
Este objeto está contenido en el área denominada como AP38_GDO_Systems. Hace parte
de los 4 objetos generales de control de la plataforma. A través de este objeto se programaron
los scripts que nos apoyan en las labores de recolección y consolidación de la variable
Previous Day de todas las estaciones remotas, esto con el fin de generar el archivo csv, que
nos alimentará la plantilla definida para el Reporte Diario Consolidado de nominación dé
gas natural.
Objeto Sincronizador
Mediante este objeto, se consolida la configuración general de cada una de las estaciones
remotas, desde los tipos de medios de comunicación con los que cuenta el sitio, que variables
físicamente están disponibles para su captura e historización, cuales son los setpoints que
están definidos para cada nodo remoto, de acuerdo a su dinámica de regulación, en que nodo
y pantalla deben ser visualizados sus datos en las pantallas del HMI o del aplicativo Web
Server, así como su posicionamiento y ubicación en los FEPs. De los objetos de control, este
viene siendo uno de los más significativos y de crucial interés en toda la estructura de la
galaxia.
5.2.2. Historización de Señales y Alarmas
Una de las partes más importantes de la aplicación SCADA es la base de datos histórica o
log. En ella quedan registrados todos los eventos, su evolución temporal y todas las alarmas
ocurridas. En el sistema que se implementa se definen dos bases de datos, una para
historización de señales y otra para historización de alarmas. A continuación se observa
cómo se han implementado la historización de señales y alarmas para cada caso.
117
Base de Datos Histórica
En la herramienta utilizada, el System Platform 4.0 de Wonderware, la base de datos
histórica es quizá el aspecto más importante. La base de datos que nos ofrece su INSQL 11.5,
también conocido como Historian, posee un mecanismo fiable y muy rápido de almacenar
los datos. Industrial SQL Server Historian combina la potencia y flexibilidad de Microsoft
SQL Server con la adquisición de datos comprimidos eficiente y a gran velocidad de un
sistema de tiempo real. Su tiempo (hasta 1ms para adquisición de datos) radica en el hecho
de que los datos se guardan en unos ficheros comprimidos, pero pueden ser accesibles
mediante consultas a la base de datos relacional.
Esta base de datos se instala y configura al momento de instalar el paquete de software
INSQL (Historian) 11.5 de Wonderware. Para ello requiere también la instalación de
Microsoft SQL Server 2008 R2. Se crea en la instalación una base de datos de nombre
“Runtime” que es donde se accede a la información del histórico mediante consultas SQL.
Para historizar datos de un objeto de la aplicación hace falta indicar en el Platform, el Engine
y el Área que contienen al objeto, la localización de esta base de datos. Los permisos de
acceso a la BD se gestionan con el usuario de dominio común a toda la aplicación o Galaxia.
En cada objeto dentro del Area, Engine y Platform en cuestión, se seleccionan los atributos
que se requieren guardar en la base de datos histórica (ya sean entradas desde un servidor de
datos que vienen de un PLC o atributos calculados internamiento en el objeto). Esto se puede
hacer para atributos de entrada – salida en la pestaña Field Attributes bien para los atibutos
internos (UDAS User Defined Attributes) en la pestaña “Extensions”. Como complementos
se puede especificar la historización cada cierto intervalo de tiempo o por evento. Todo esto
para cada atributo a historizar. Además se define un directorio local donde guardar los datos
a historizar en caso de caída temporal de la base de datos histórica. Este proceso se repite
para todos los datos historizados pero solo es necesario hacerlo en el template del objeto
Motorola.
118
Base de Datos de Alarmas
Para historizar alarmas se utilizan las capacidades de la aplicación Intouch. Esta aplicación
ha estado ligada históricamente al tratamiento de las alarmas. Se utilizará el denominado
“Intouch Distributed Alarm System” (Invensys Systems, Inc., 2007). Este sistema de alarmas
distribuido consiste en tener proveedores de alarmas y consumidores de alarmas.
Los proveedores de alarmas son aplicaciones que indican al sistema de alarmas cuando el
estado de una alarma camba. Un proveedor de alarmas puede ser Intouch o también puede
ser otra aplicación del framework como una “Galaxy ArchestrA” o SPCPro, QIAnalyst. En
este proyecto Intouch solo se utiliza como capa de visualización e interacción con el usuario
y por lo tanto tenemos los objetos ejecutándose. Los consumidores de alarmas sirven para
consultar el estado de las alarmas y también para enviar la acción de confirmación de una
alarma, acción que realiza un usuario operario al darse cuenta de la alarma y antes de actuar
para solventar la incidencia. Existen una serie de controles ActiveX y herramientas que se
incluyen en las pantallas de Intouch para este propósito.
Además de proveedores y consumidores, tenemos también la base de datos de alarmas, el
Alarm DB Logger y el Alarm Manager que recogen alarmas de los proveedores y las
presentan a los consumidores.
Figura 5-8. Intouch Distributed Alarm System.
Fuente: (Invensys Systems, Inc., 2007)
119
Para historizar alarmas primero se instala Microsoft SQL Server y se crea la base de datos
WWALMDB. En este caso, para tener un sistema más compacto se crea la base de datos
WWALMDB en el mismo nodo donde se ha instalado Historian y su Base de Datos Runtime.
Luego es preciso instalar las aplicaciones del Intouch Distributed Alarm System en el nodo
donde se encuentran los objetos de la “Galaxia” desplegados por comodidad. Hay que
configurar el Alarm DB Logger indicando en que base de datos se guardan las alarmas y
dejar esta aplicación ejecutándose siempre.
Figura 5-9. Configuración de alarmas
Fuente: (Invensys Systems, Inc., 2007)
Finalmente desde el “ArchestrA IDE” se configuran las alarmas para cada atributo. Hay que
indicar diferentes parámetros según el tipo de alarma. En este proyecto las alarmas que se
recogen son tanto análogas como digitales, los cuales se leen directamente de los FEPs.
Figura 5-10. Configuración de Alarmas.
Fuente: (Invensys Systems, Inc., 2007)
120
Este proceso se repite para todas las alarmas, pero solo se realiza en el objeto template de
Motorola, para que sea heredado a todos los objetos hijos que representan a cada una de las
estaciones remotas.
5.3. Reportes Consolidados
Como productos finales de entrega, una vez completado todo el proceso de adquisición de
datos, son los reportes consolidados donde se consolida toda la información de consumo del
Gas Natural. Estos reportes brindan la información concerniente al consolidado general por
estación reguladora, localidad o nodos de distribución, así como el consumo hora a hora del
día de consumo, para que los clientes industriales no regulados y regulados, puedan definir
la cantidad de Gas Natural que requieren para su operación de forma adicional o para
proyectar su producción a lo largo de su periodo de facturación.
5.3.1. Reporte Consolidado Previous Day
En este reporte se genera un resumen general del consumo de Gas Natural en las diferentes
localidades y nodos de distribución, respecto al día anterior. Para su generación, se parte de
un archivo CSV que se genera a través de scripts diseñados en el objeto Reporte PD, que
básicamente se encarga de consolidar el dato de VolCorrLD de todas las estaciones remotas,
tan pronto pasa la hora de la media noche para tener el valor exacto del consumo del día
culminado.
Una vez generado este archivo, se programa una plantilla macro de Excel como se observa
en la Figura 5-11, con la cual se inyecta la información capturada y se genera de manera
automática este documento, el cual se envía por correo electrónico al personal interesado
por esta información, es decir los actores Ingeniero SCADA, Ingeniero Balance de Gas y
Directivo. Este reporte indica adicionalmente, que estaciones presentaron consumo cero
(amarillo) o cuales han tenido fallas de comunicación prolongadas (rojo), para su respectiva
intervención y revisión.
121
Figura 5-11 visualización preliminar configuración de parámetros y datos de las estaciones remotas en el
Reporte Consolidado PD.
Fuente: Elaboración Propia
En la Figura 5-12, se presenta el esquema general del formato, siendo la hoja 1 el resumen
consolidado de estaciones por localidad, y la hoja 2 (Figura 5-13), la descripción gráfica del
consumo generado en las localidades.
123
Figura 5-13. Grafico Consolidado por Municipios y Distrito de Cali
Fuente: Elaboración Propia
5.3.2. Base de Datos Cuenta Balance
Como soporte detallado de los consumos generados hora – hora, diarios y máximos y
mínimos de cada uno de los brazos de medición, se encuentra la base de datos de Cuenta
Balance. Este reporte detallado es entregado diariamente al gestor de mercado, como soporte
de los consumos realizados el día inmediatamente anterior, para las respectivas
negociaciones de conciliación o sobrecostos por exceso o reserva de consumo del bien
energético, conforme a la Resolución 089 de 2013 (Comisión de Regulación de Energía y
Gas, 2013).
124
A continuación en la Figura 5-14, Figura 5-15 y Figura 5-16 se presenta un esquema general
del modo de presentación de la información solicitada por brazo de medición:
Registros Hora –Hora
Se encuentran los siguientes campos: Id_Sitio, corte evento, Hora-Fecha, Volumen No
Corregido, Volumen Corregido, Temperatura y Presión.
Figura 5-14 Formato Registros Hora – Hora en Cuenta Balance.
Fuente: Elaboración propia.
Registros Máximos y Mínimos
Se encuentran los siguientes campos:
- Máxima Presión,
- Hora-fecha máxima presión,
- Mínima Presión,
- Hora-fecha mínima presión,
- Máximo Flujo,
- Hora-fecha máximo Flujo,
- Mínimo Flujo,
125
- Hora-fecha mínimo Flujo,
- Máxima Temperatura,
- Hora-fecha máxima Temperatura,
- Mínima temperatura,
- Hora-fecha mínima Temperatura.
Figura 5-15 Formato Registros Máximos y Mínimos en Cuenta Balance
Fuente: Elaboración Propia.
Registro Diario
Se encuentran los siguientes campos: Id_Sitio, corte evento, Día-Fecha, Volumen No
Corregido, Volumen Corregido, Temperatura y Presión.
Figura 5-16 Formato Registro Diario en Cuenta Balance
Fuente: Elaboración Propia
Cabe resaltar que la información que se consolida en esta base de datos, previamente ha sido
almacenada en la base de datos de Historian, la cual llega tal cual como proviene de la
estación remota. Antes de ser entregada a Cuenta Balance, se requiere de la conversión de
unidades o la consolidación de datos parciales generados por eventos que se presentan en los
sitios remotos. Todo esto se realiza mediante scripts diseñados en los objetos de registros
descritos en la sección anterior.
126
Un ejemplo de lo expuesto en el párrafo anterior lo podemos observar en la Figura 5-17,
donde particularmente para este brazo de medición ha presentado falla en el sensor de
temperatura, lo cual genera para el intervalo de la hora de las 6:01AM y las 7:00AM cortes
parciales. Esta información requiere ser consolidada en un solo registro, de acuerdo al
requerimiento del formato de presentación de la información al gestor de mercado; por tanto
para este tipo de eventos, se aplican las rutinas de verificación y consolidación de la
información.
Figura 5-17 Formato original de registros Hora-Hora de un brazo de medición, almacenado en la base de
datos de Historian.
Fuente: Elaboración propia.
5.3.3. Base de Datos Current Day
Esta base de datos permite consultar vía web el consumo hora-hora del día de cada una de
las estaciones remotas, principalmente los nodos de clientes industriales regulados y no
regulados, para su seguimiento de consumos y compras de subasta del Gas Natural a lo largo
127
del día. Esta información es generada a partir de la variable actual VolCorrCD, la cual se
actualiza entre cada 10 a 20 min, de acuerdo al estado de comunicaciones de cada uno de los
sitios remotos, conforme a la solicitud de polling programado en los FEPs. Como se observa
en la Figura 5-18, los datos que se entregan para consulta son: Id_sitio, Estampa de hora del
dato capturado, valor de Volumen Corregido Actual.
Figura 5-18. Formato de entrega Volumen Corregido Actual
Fuente: Elaboración Propia
128
6. Capítulo 6
Resultados y Conclusiones
6.1. Resultados Obtenidos
De acuerdo a los objetivos planteados en el capitulo 2:
Aspecto por Revisar Objetivo a Alcanzar
Tiempos de polling variables actuales. En este
momento se encuentra en promedio entre 30 y 40
minutos.
Disminuir el tiempo de polling de 10 a 15 minutos.
Petición de Registros por demanda del usuario. Eliminar la petición por demanda y generar el envío
de registros de manera automática al centro de
control.
Parámetros de medición sin historizar. Revisión e historización de parámetros de medición
requeridos para los reportes consolidados solicitados
por la Resolución 089 de 2013.
Disponibilidad de registros horarios, diarios,
máximos y mínimos para la nominación y subasta
diaria del bien energético.
Cumplimiento de la hora de entrega de la
información consolidada de todas las estaciones
remotas. 8:00AM
Fuente: Elaboración Propia
Se presentan a continuación los resultados obtenidos una vez implementado el proceso de
cambio y culminado el tiempo de estabilización de la plataforma:
6.1.1. Tiempos de Polling Variables Actuales.
Durante las etapas de análisis y diseño del nuevo centro de control, se identificó la necesidad
de realizar una separación de los procesos de adquisición de los datos para los casos en que
se presentan varios brazos de medición, esto con el fin de solicitar de manera independiente
la información y así no saturar el canal de comunicaciones del sitio en específico, al
momento de realizar cualquier tipo de petición o envío de comandos de cierre de actuador,
los cuales son los de mayor criticidad en la operación.
Por esta razón, ya no se estarían hablando de 102 sitios remotos de medición, sino de 175
brazos de medición, lo que incrementa de manera considerable el flujo de información.
De acuerdo a esto, la estructura del Front End Processor, se ha dimensionado con una
proyección de hasta 280 brazos de medición, lo cual nos permite mantener tiempos de
polling de máximo 15 minutos, sin que se vea afectada la calidad de la información. A
129
continuación en la Figura 6-1 la relación de crecimiento del sistema SCADA, desde su
primera versión, hasta la futura proyección de nuevos sitios a 2025:
Figura 6-1. Crecimiento Sitios Remotos SCADA GDO.
Fuente: Elaboración Propia
De acuerdo a esta tasa de crecimiento del sistema SCADA, se ha estimado una relación entre
el aumento de los sitios y la cantidad de datos actuales que serán procesados, de acuerdo a
su comportamiento antes del proceso de actualización y después del procedimiento.
Figura 6-2. Estimación Adquisición de Datos, antes y después de la actualización del centro de control.
Fuente: Elaboración Propia
0
50
100
150
200
250
300
1999 2004 2009 2014 2019 2024
Crecimiento Estaciones Motorola
Motorola
130
Esta estimación ha sido validada con muestras de datos durante toda la etapa de migración,
de acuerdo al proceso de integración de sitios remotos que se realizó de manera simultánea,
lo que nos permitió medir de forma progresiva el desempeño en el centro de control, a
medida que se iban agregando las estaciones que se fueron migrando o instalando. Esto se
puede observar en la Figura 6-3
Figura 6-3. Comparación entre datos estimados y cuantificación de datos historizados.
Fuente: Elaboración Propia
Tabla 6-1 Proyección Datos Actuales, de acuerdo a la cantidad de brazos de medición, antes y después de la
migración.
Cantidad
Brazos de
Medición
Datos
Actuales
Por Sitio
Total
Actuales en
un polling.
Total hatos
antes y
después
migración
Total datos
por hora,
historizados.
Antes de la
Actualización del
Centro de
Control
20 6 120 360 378 25 6 150 450 472
28 6 168 453 476 30 6 180 450 472
40 6 240 600 630 50 6 300 600 570
60 6 360 648 615
70 6 420 546 464 90 6 540 648 486
95 6 570 684 444 102 6 612 734 403
Después de la
Actualización del
130 18 2340 14040 15444
175 18 3150 18900 20790 185 18 3330 19980 21978
195 18 3510 21060 22113
131
Centro de
Control
200 18 3600 21600 22680
210 18 3780 22680 23814 220 18 3960 23760 24948
230 18 4140 24840 26082
240 18 4320 25488 26762 250 18 4500 26100 27405
260 18 4680 26910 28255 280 18 5040 28728 30164
Fuente: Elaboración Propia
De acuerdo a esto, no solo se cumplió el requerimiento de conservar tiempos de polling entre
10 y 15 minutos (actualmente se están manejando 12 minutos) (RAYCO Ltda., 2014), sino
que se ha pasado de un rango de procesamiento de 470 datos por hora a 12100 datos, si se
compara la misma cantidad de estaciones, antes y después del proceso de actualización, es
decir un aumento de 25 veces la capacidad.
6.1.2. Petición de Registros por demanda del usuario.
Se elimina por completo la petición por demanda, se han generado rutinas de solicitud de
paquetes individuales de registros, hora a hora, tanto de horarios, diarios y máximos y
mínimos. Para no generar picos de volumen de datos, se han programado de tal forma, que
no se solapen con los tiempos de petición de datos actuales. De esta forma, sumado a los
datos actuales, cada hora se estarán adquiriendo aproximadamente 9450 datos y en el corte
de la media noche, cuando se traen los registros diarios, se estarán solicitando alrededor de
15750 datos, de manera adicional, para la cantidad de estaciones que actualmente están
activas. La proyección de adquisición de datos, se presenta a continuación:
132
Tabla 6-2.Proyección Datos de Registros por Cantidad de Brazos de Medición
Cantidad
Brazos de
Medición
Datos
Actuales
Por Sitio
Total Datos para
registros horarios y
máximos y minimos,
por hora.
Total Datos -
Registros
Diarios
Total Datos
Registros
Hora 24
130 54 7020 4680 11700
175 54 9450 6300 15750
185 54 9990 6660 16650
195 54 10530 7020 17550
200 54 10800 7200 18000
210 54 11340 7560 18900
220 54 11880 7920 19800
230 54 12420 8280 20700
240 54 12960 8640 21600
250 54 13500 9000 22500
260 54 14040 9360 23400
280 54 15120 10080 25200
Fuente: Elaboración Propia
Figura 6-4. Datos de Registros por Hora.
Fuente: Elaboración propia
Esta filosofía de adquisición de registros, además de mantener la información actualizada
del consumo de la hora inmediatamente anterior, permite adicionalmente, realizar la consulta
y petición dedicada a registros específicos, que por ejemplo por temas de comunicación no
fue posible traer en su momento o que se requieren consultar de nuevo para identificar
posibles fallas de la estación remota.
6.1.3. Parámetros de medición sin historizar.
Antes del proceso de actualización del centro de control, el monitoreo de las variables de
medición estaba solo a los siguientes:
133
- Presión Entrada
- Presión Salida
- Presión Estación o Medición
- Protección Catódica
- Temperatura
- Flujo
Que anunque para la operación son las escenciales, se generaba la necesidad de conocer el
estado completo de todas las variables asociadas, dados los procesos de ampliación y detalle
que a nivel mecánico e hidraulico estaban presentando los sitios por el crecimiento de la
demanda del bien energético. Es por ello que para esta actualización se adicionan las
siguientes variables:
- Volumen Corregido Día Anterior
- Volumen Corregido del Día
- Factor de Corrección
- Volumen Corregido Acumulado
- Atmósfera Explosiva
- Frecuencia
- Estado Válvula de Alivio
- Estado Actuador de Seccionamiento o de Seguridad
- Intrusión a Estación
- Intrusión a Gabinete
- Estatus de Suministro de Energía
- Banderas de estado del computador electrónico.
6.1.4. Disponibilidad de registros horarios, diarios, máximos y mínimos para
la nominación y subasta diaria del bien energético.
De acuerdo al requerimiento de la Resolución 089 de 2013, es necesario que la información
se encuentre disponible en la pagina destinada por el gestor de mercado desde las 8:00AM,
134
para que tanto GDO, como sus clientes Regulados y No Regulados, puedan generar sus
reportes diarios de balance, así como la nominación díaria de consumo del bien energético.
Dado que el almacenamiento de la información se realiza hora a hora y se completa en las
primeras horas de la madrugada del día siguiente, principalmente por eventos de
comunicación del canal de servicios GPRS, la inserción de datos a la base de datos de Cuenta
Balance, se ejecuta a partir de las 6:00AM, culminando los jobs de inserción a las 7:00AM.
A partir de este momento se realiza la entrega del Reporte Consolidado del consumo del día
anterior y por su parte el ingeniero SCADA, realiza el chequeo de los posibles eventos que
se hayan presentado en las estaciones remotas y que por ende no tienen completos sus
registros, esto con el fin de actualizar la información o generar el soporte correspondiente
del faltante de información antes de la hora acordada.
De acuerdo a la medición detallada del consolidado de registros, se ha identificado que por
este tipo de eventos, puede generarse un faltante del 3% de la información, la cual en la
mayoría de los casos, se puede solicitar de manera inmediata, salvo en las eventualidades en
las que el computador electrónico ha presentado falla general.
6.2. Novedades Presentadas Durante el Proyecto
A continuación se presentan los eventos presentados durante la ejecución del proyecto, los
cuales generaron impactos de importancia para llevar a cabo las actividades, respecto a la
planeación inicial:
6.2.1. Cambio de Frecuencias en el Sistema de Radiocomunicaciones
Debido a la reasingnación del espectro presentada durante el 2013 a 2015, de acuerdo a la
Resolución 449 del 11 de Marzo de 2013, Gases de Occidente se vió obligado a apagar todo
su sistema de radiocomunicaciones, mientras se generaba el respectivo proceso de cambio
de frecuencias, el cual fue otorgado solo hasta mediados de 2015.
135
Este evento generó que durante el proceso de implementación, solo se contara con el medio
de comunicación GPRS, generando que por prioridades de operación, el proceso de
migración de las estaciones remotas se extendiera más tiempo del que se había contemplado
inicialmente.
Adicionalmente, este evento generó que durante varias ocasiones se presentaran bloques de
retraso de la información, fruto de la disponibilidad del canal de servicios, presentando una
alta vulnerabilidad en el monitoreo de los sitios remotos. Por esta razón, se genera la
necesidad de que por parte del cliente se solicitara al prestador de servicios un canal dedicado
y de alta disponibilidad, para garantizar de esta manera la continuidad de la operación. En
este momento, ya se están realizando las actividades de restablecimiento del canal primario
de comunicaciones (radio) y la respectiva actualización de infraestructura que implicó la
reasignación de frecuencias.
6.2.2. Implementación de Politica Ley Sox en la Compañía
En su plan de expansión, Gases de Occidentes ha requerido la ampliación de su
infraestructura de información, esto con el fin de garantizar a su consorcio de inversionistas
mayor fidelidad en la calidad y veracidad de la información financiera. En este proceso,
desde el 2014 han implementado la Ley SOX (Sarbanes Oxley Act) (Commission, 2009), la
cual ha elevado los controles para la emisión de cuentas anuales y reportes financieros.
Dado que la información entregada a las bases de datos de Cuenta Balance son de crucial
interés para los analisis financieros de la compañía, durante el proceso de implementación,
se hicieron necesarios varios procesos de revisión de politicas, validación de compatibilidad
entre las herramientas de adquisición y almacenamiento de datos con el software
especializado de seguridad y la generaciójn de procedimientos de seguridad para posteriores
actualizaciones o futuras mejoras. Situación que durante el diseño de la propuesta no se había
contemplado y que generó tiempo adicional durante la implementación de la red de
servidores y puesta en marcha de las bases de datos.
136
6.3. Conclusiones Finales
De acuerdo al alcance planteado en este proyecto, se lleva a cabo a satisfacción los cuatro
objetivos planteados, es decir, se logra obtener tiempos de polling en el rango de minutos
acordado y que a su vez no está sujeto a la cantidad de sitios actualmente activos, sino con
una proyección del 75% adicional de su capacidad actual.
Se realiza la ampliación de datos a historizar, lo que mejoran los procesos de seguimiento y
trazabilidad del comportamiento dinámico de las estaciones remotas, esto con el fin de
plantear procesos de mantenimiento o expansión más acertivos y con un sustento técnico
más evidente.
Adicionalmente, la inclusión de estas nuevas variables, no solo permite mayor control y
seguimiento por parte del cliente, sino que a través de las nuevas herramientas de consulta
para los clientes, extiende una dinámica de trabajo y cooperación entre cliente – distribuidor
más activa para la optimización del uso del recurso energético.
Se automatiza la petición de registros de cada una de las estaciones remotas, permitiendo
obtener de manera oportuna la información que se requiere entregar al gestor de mercado de
manera oportuna y efectiva. Adicionalmente, esto también permite cumplir a la compañía
uno de los requerimientos de los controles SOX y es el de que la información que se esté
reportando, no sea manipulada o ajustada por parte de personal directo o indirecto de la
compañía, sin una justificación técnica justificable.
6.4. Trabajos Futuros
Los trabajos a futuro que proyecta desarrollar e implementar en esta plataforma SCADA
son los siguientes:
- Inclusión de la red de correctores Eagle para su monitoreo , supervisión y adquisición
de registros horarios y diarios para la nominación de Balance de Gas. Un total de 150
estaciones remotas.
137
- Inclusión de las estaciones tipo calentadores de gas (alrededor de 15 sitios), para su
supervisión y monitoreo.
- Inclusión de las estaciones tipo odorizadores de gas (alrededor de 15 sitios), para su
supervisión y monitoreo.
- Generar plan piloto para la supervisión y monitoreo de las estaciones de transporte de
contenedores de gas natural a municipios de Buenaventura y Calima – Darien.
- Implementación del centro de control alterno, para el monitoreo y supervisión de las
estaciones propias de Gases de Occidente, en caso de falla general del centro de control
principal, por eventos de desastre natural.
- Implementación de ambiente de desarrollo, de acuerdo a la aplicación de las politicas de
seguridad SOX.
- Desarrollo de aplicativos, aplicando herramientas de inteligencia computacional y/o
minería de datos, para la detección de fallas o desviaciones en la medición volumétrica,
para la disminuación de error de balance de gas entre clientes y transportadores.
138
Lista de Referencias
(Instituto Colombiando de Normas Técnicas y Certificación. (2008). Plásticos. Tubos y
Accesorios Termoplásticos para la conducción de Gases a Presión. Bogotá:
ICONTEC.
American Petroleum Institute. (2013). ANSI / API MPMS Chapter 21.1. Flow Measurement
Using Electronic Metering Systems—Electronic Gas Measurement. American
Petroleum Institute.
Bernal Ortíz, A. (2009). Sistemas de Distribución y Transporte de Gas Natural. Boletín
Técnico de INDISA S.A. No 78, 1-7.
Clarke, G., Reynders, D., & Wright, E. (2004). Practical Modern SCADA Protocols: DNP3,
60870.5 and Related Systems. Burlington, MA 01803: Elsevier.
Comisión de Regulación de Energía y Gas. (14 de Agosto de 2013). Resolución 089 de 2013.
Bogotá.
Comité de Normalización de Petróleos Mexicanos y Organismos Subsidiados. (2009).
Desplegados Gráficos y Bases de Datos para el SDMC de Procesos. México D.F.
Commission, O. o. (09 de 2009). United States and Exchange Commission. Obtenido de
https://www.sec.gov/news/studies/2009/sox-404_study.pdf
De la Rosa Galván, H. (2008). Implementación de Un Sistema SCADA para la Mezcla de
Dos Sustancias en una Industria Química. México: Instituto Politécnico Nacional.
De Sousa Costa, J. J. (2006). Estudio Técnico Para La Actualización De Sistemas De
Supervisión, Control Y Protección De La Planta De Rucio Viejo De Total Ubicada
En Jusepin, Edo. Monagas. Caracas: Universidad Central de Venezuela.
Ecopetrol. (2010). Manual de Medición de Hidrocarburos y Biocombustibles - Capitulo 14
- Medición de Gas Natural. Bogotá.
Ehrenreich, D., & Liberman, S. (s.f.). Motorola's MDLC Protocol Enhances DNP 3.0 Based
SCADA Systems.
Frider, J. (2012). Leveraging Virtualization for Higher Business Continuity within Industrial
Facilities. Plano, TX 75024.: Invensys Systems Inc.
139
Gases de Occidente S.A. E.S.P. (2012). Informe de Gestión y Sostenibilidad. Santiago de
Cali: PHVA Consultores S.A.S.
Instituto Colombiando de Normas Técnicas y Certificación. (2011). Gasoductos. Lineas de
Transpoirte y Redes de Dsitribución de Gas. Bogotá: ICONTEC.
Instituto Colombiano de Normas Técnicas y Certificación. (2002). Gasoductos. Estaciones
de Regulación de Presión para Lineas de Transporte y Redes de Distribución de Gas
Combustible. Bogotá: ICONTEC.
Instituto Colombiano de Normas Técnicas y Certificación. (2007). NTC 3838. Gasoductos.
Presiones de Operación Permisibles para el Transporte, Distribución y Suministro
de Gases Combustibles. Bogotá: ICONTEC.
Invensys Systems, Inc. (2007). InTouch HMI Concepts and Capabilies Guide. Lake Forest,
CA.: Invensys Systems, Inc. Recuperado el 01 de 12 de 2015, de
http://www.wonderware.com,
Invensys Systems, Inc. (211, 2012). Wonderware, ArchestrA System Platform in a
Virtualiazed Environment Implementation Guide. Lake Forest, CA.: Invensys
Systems, Inc.
Kamioka, N. (2012). SCADA System of Tokyo Gas for Wide-Area City Gas Distribution.
IEEE SICE Annual Conference, 333-336.
KEMA INC. (2004). Informe de Diseño del SCADA/EMS Inicial, Proyecto SIEPAC.
México.
Motorola Solutions Inc. (2009). M-OPC Server User Guide.
Motorola Solutions, Inc. (2000). MOSCAD TECHNICAL NOTES: " MDLC Communication
Protocol Overview".
Motorola Solutions, Inc. (2007). AGA7+AGA8 (AGA78) Gas Flow Calculations.
Schaumburg, IL: Motorola Solutions, Inc.
Motorola Solutions, Inc. (2011). ACE3600 System Tools Suite (STS) User Guide Version
15.50. Schaumburg.
Ospina López, V. H. (2003). Diseño de Centro de Control Para Aguas de Manizales.
Manizales: Universidad Nacional de Colombia, Sede Manizales.
140
RAYCO Ltda. (2008). Programación y Puesta en Marcha del Software del Centro de
Control y el Frond End Processor Motorola Moscad y Recolección de datos para 20
Sitios en Cali y Municipios Asbuilt. Santiago de Cali.
RAYCO Ltda. (2008). Software de Monitoreo Estaciones de Servicio Gases de Occidente
S.A. E.S.P., Guía Rápida de Uso. Bogotá.
RAYCO Ltda. (2014). Procedimiento Consulta en Site Map Entorno HMI Centro de Control
Principal GDO. Bogotá. Recuperado el 15 de 08 de 2014
RAYCO Ltda. (2014). Procedimiento Consulta Máximos y Mínimos Entorno HMI Centro
de Control Principal GDO. Bogotá.
RAYCO Ltda. (2014). Procedimiento Consulta, Modificación y Actualización de Set Points
Entorno HMI Centro de Control Principa. Bogotá.
RAYCO Ltda. (2014). Procedimiento Usuarios y Perfiles HMI Centro de Control Principal
GDO. Bogotá.
RAYCO Ltda. (2014). Procedimiento Usuarios y Perfiles HMI Centro de Control Principal
GDO. Bogotá.
RAYCO Ltda. (2014). Reporte Tiempos de Polling Estaciones Motorola. Bogotá.
The American Society of Mechanical Engineers. (1999). ASME B 31.8., Sistemas de Tubería
Para Transporte y Distribución de Gas. The American Society of Mechanical
Engineers.
VMware , Inc. (2012). Wonderware System Platform 2012, Superior Agility with VMware
vSphere 5. Palo Alto, CA 94304: VMware , Inc.
Recommended