Análisis e Implementación de la Actualización del Centro ...

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


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


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


SOFTWARE INSTALADO Intouch For System Platforn / Wonderware Historian Client- Microsoft Windows 7 Professional SP 1- Windows Office 2010.- Wonderware Historian Client.- Intouch Viewer.

SCADAXP02


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.


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


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


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




Para este tipo de estación, se pueden identificar las siguientes variables de mediciones tanto


Tabla 3-2 Variables Actuales Típicas de una estación tipo Reguladora y Medición


Presión de Medición

Presión de Salida

Temperatura

Flujo



Volumen Corregido del día anterior


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




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





Tabla 3-3. Variables Actuales Típicas de una estación tipo Gasoducto Virtual


Presión de Medición - Salida

Temperatura

Flujo





Digitales de Entrada Intrusión Cuarto de Control

Estado de Actuador




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.



31




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





Digitales de Entrada Falla de Suministro Eléctrico AC


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


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.




Tabla 3-5. Variables Actuales Típicas de una estación Valvula de Seccionamiento.


Presión de Salida

Digitales de Entrada Intrusión Gabinete de Control Local

Intrusión Estación Reguladora

Estado de Actuador



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


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


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


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


1 Accionamiento cierre actuador X X N/A N/A X


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


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.


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


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


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


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


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.


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


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%


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



Previsto: 52 min/año

Completa sincronización de los sistemas

primarios y secundarios.

Level 4 Tolerancia a

Fallos



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.


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


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




COCLOGDOAP23


COCLOGDOAP62


COCLOGDOAP44


COCLOGDOBD08

4 Threads8GB RAM

160 GB DD

COCLOGDOAP38

4 Threads8GB RAM

120 GB DD

COCLOGDOAP37


COCLOGDOVT08


COCLOGDOVT07


Figura 4-5. Estructura Plataforma SCADA Gases de Occidente S.A. E.S.P., implementada en la

actualización.


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




Memoria 8 GB


Productos de System Platform Instalados Application Server

Máquina Virtual 3: Nodo Intouch Terminal Services




Memoria 4 GB


Productos de System Platform Instalados Intouch con Terminal Services Habilitado

Máquina Virtual 4: Nodo 1 Application Server Runtime




Memoria 4 GB


Productos de System Platform Instalados Application Server Runtime e Intouch

Máquina Virtual 5: Nodo 2 Application Server Runtime




Memoria 4 GB


Productos de System Platform Instalados Application Server Runtime

Máquina Virtual 6: Nodo Information Server




Memoria 4 GB

72


Productos de System Platform Instalados Information Server

Máquina Virtual 7: Nodo Historian Client



Sistema Operativo Windows 7 Enterprice

Memoria 4 GB


Productos de System Platform Instalados Historian Client

Ambiente de Desarrollo SCADA Desarrollo y Pruebas

Máquina Virtual 1: Nodo Historian




Memoria 4 GB


Productos de System Platform Instalados Historian

Máquina Virtual 2: Nodo Application Server




Memoria 8 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


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


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


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.


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.


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


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.


- 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.


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.


- 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.


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


Barra de Encabezado

Figura 4-18 Barra superior Panel Principal


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.


92

Barra Alarmas

Figura 4-20. Barra Alarmas Actuales


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


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


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


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


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


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


Consolidado EDS


Estaciones de Servicio.

97

Figura 4-27. Panel Consolidado Estaciones de Servicio


Consolidado ERM Municipios


Estaciones Reguladoras de Medición de los municipios interconectados a la red de

distribución.

Figura 4-28. Panel Consolidado Estaciones Reguladores Municipios


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


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


Botones de Acceso a Consolidados Tipo Estación

Este panel está compuesto por:

Figura 4-31. Barra de Herramientas Panel Históricos


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


Área de Visualización

En esta área se encuentra lo siguiente:

Figura 4-33. Área de Visualización


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


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


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


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


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


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


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.


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





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.


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


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


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.



#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.


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


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


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


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


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.


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.


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.

122

Figura 5-12. Resumen Consolidado Por Localidad


123

Figura 5-13. Grafico Consolidado por Municipios y Distrito de Cali


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


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


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


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


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.


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.


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.


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


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


Figura 6-4. Datos de Registros por Hora.


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.

Análisis e Implementación de la Actualización del Centro ...

Documents

Transcript of Análisis e Implementación de la Actualización del Centro ...