Utilizacion de MDE para resolver el problema´ de ...

UNIVERSIDAD DE LOS ANDESFACULTAD DE INGENIERIADepartamento de Sistemas

y ComputacionGrupo de construccion de software

Utilizacion de MDE para resolver el problemade modelamiento simultaneo de redes de

Acueducto y Alcantarillado

Daniel Eduardo Luna Beltran

Tesis de grado presentado para optar por el tıtulo deMagıster en Ingenierıa de Sistemas y Computacion de la

Universidad de los Andes

Mayo, 2014

Asesor: Prof. Dr. Rubby Casallas

Resumen

Si bien el modelado de redes de acueducto y el de redes de alcantarillado essimilar, la mayorıa de herramientas de diseno permiten modelar solo un tipo dered, lo que implica para el disenador realizar el procedimiento en dos herramien-tas diferentes. En este documento se presenta Hydraulic Networks, un lenguajegrafico que permite modelar ambos tipos de redes de forma simultanea, aprove-chando que estas comparten caracterısticas como el flujo del agua, la distribucionurbanıstica y la topografıa. Mediante el lenguaje se crea un modelo inicial de lared, y por medio de una Cadena de Transformacion de Modelos (MTC) se gene-ran archivos de entrada para las herramientas que realizan calculos hidraulicos.La informacion de respuesta de estos motores es traducida nuevamente, y a travesde la MTC es regresada a Hydraulic Networks, en donde se informa al usuariosobre eventos generados por los modelos de forma individual y analiza las ex-cepciones que se generan de forma conjunta entre ambas redes, permitiendo alingeniero entender el funcionamiento de la redes urbanas de una nueva forma,aproximandose mejor a realidad, y facilitando el ejercicio de su labor.

i

Abstract

Despite of similarities in water supply and sewerage modelling, most hy-draulic software allows to work only in one kind of network. Then, hydraulicengineers have to model both networks separately. This article presents Hydrau-lic Networks, a graphical language that allows joint modelling of water supplyand drainage networks, leveraging their common features, like water flow, urbantopology and topography. Through this language, hydraulic engineers can createan initial joint model that contains the information of both networks. Using aModel Transformation Chain (MTC), this initial model can be transformed intwo files. The first one can be used by hydraulic software that solves the equa-tions to simulate water supply flux. The second one can be used to simulatesewerage flux. The answer of those hydraulic tools can be traduced once moreto a model that is consistent with Hydraulic Networks. Then, it can analyze thejoint model and report to the engineer if something went wrong, and gave himsome new information about the way both networks interact.

ii

Indice general

Resumen I

Abstract I

Tabla de contenidos III

1 Introduccion 31.1 Administracion de redes de Acueducto . . . . . . . . . . . . . . . 41.2 Administracion de redes de Alcantarillado . . . . . . . . . . . . . 51.3 Limitaciones relativas a la actual administracion . . . . . . . . . 6

2 Problema 72.1 Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Dialogo con Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Objetivos 113.1 Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Objetivos Especıficos . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Base Teorica 134.1 Definiciones relativas al MDE . . . . . . . . . . . . . . . . . . . . 13

4.1.1 Ingenierıa orientada por modelos . . . . . . . . . . . . . . 134.1.2 Modelos y Metamodelos . . . . . . . . . . . . . . . . . . . 134.1.3 Transformacion de Modelos . . . . . . . . . . . . . . . . . 144.1.4 Cadena de Transformacion de Modelos - MTC . . . . . . 144.1.5 Modelamiento en Ingenierıa Hidraulica y en Ingenierıa de

Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2 Herramientas de Modelamiento . . . . . . . . . . . . . . . . . . . 14

4.2.1 Eclipse - EMF . . . . . . . . . . . . . . . . . . . . . . . . 144.2.2 EMF Core . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2.3 Sirius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2.4 ATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2.5 Acceleo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.3 Herramientas de Calculo Hidraulico . . . . . . . . . . . . . . . . 154.3.1 Epanet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3.2 Epaswmm . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Propuesta de Solucion 175.1 Resumen de la solucion . . . . . . . . . . . . . . . . . . . . . . . 175.2 Definicion del Lenguaje . . . . . . . . . . . . . . . . . . . . . . . 19

iii

iv Indice general

5.2.1 Elementos del lenguaje Hydraulic Networks . . . . . . . . 195.2.2 Reglas sintacticas del lenguaje Hydraulic Networks . . . . 205.2.3 Elementos del modelo Epanet . . . . . . . . . . . . . . . . 205.2.4 Elementos del modelo Epaswmm . . . . . . . . . . . . . . 21

5.3 Editor Grafico del Lenguaje . . . . . . . . . . . . . . . . . . . . . 215.4 Resumen de la Cadena de Transformacion de Modelos . . . . . . 235.5 Transformacion M2M - Desagregacion . . . . . . . . . . . . . . . 245.6 Transformacion M2T - Traduccion . . . . . . . . . . . . . . . . . 265.7 Ejecucion del Analisis Hidraulico . . . . . . . . . . . . . . . . . . 275.8 Recuperacion de los datos de los Reportes . . . . . . . . . . . . . 285.9 Analisis Conjunto del Modelo . . . . . . . . . . . . . . . . . . . . 28

5.9.1 Eventos Conjuntos . . . . . . . . . . . . . . . . . . . . . . 295.9.2 Solucion a los eventos conjuntas . . . . . . . . . . . . . . 29

5.10 Manejo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . 305.10.1 Excepciones y Advertencias Independientes . . . . . . . . 30

6 Validacion 336.1 Obtencion de los Datos de Entrada . . . . . . . . . . . . . . . . . 33

6.1.1 Datos de Cedritos . . . . . . . . . . . . . . . . . . . . . . 336.1.2 Datos de Acacias . . . . . . . . . . . . . . . . . . . . . . . 346.1.3 Resutados esperados . . . . . . . . . . . . . . . . . . . . . 34

6.2 Recuperacion de los datos de los reportes . . . . . . . . . . . . . 366.3 Agregacion de los datos en el Modelo Conjunto . . . . . . . . . . 376.4 Visualizacion de Alertas en el Editor Grafico . . . . . . . . . . . 396.5 Validacion Conjunta de los Modelos . . . . . . . . . . . . . . . . 41

7 Conclusiones y Trabajo Futuro 43

8 Anexos 478.1 Metamodelo Conjunto Hydraulic Networks . . . . . . . . . . . . 478.2 Metamodelo Acueductos Epanet . . . . . . . . . . . . . . . . . . 508.3 Metamodelo Alcantarillados Epaswmm . . . . . . . . . . . . . . . 52

Indice de figuras

5.1 Esquema general de la solucion . . . . . . . . . . . . . . . . . . . 185.2 Lenguaje de Hydraulic Networks . . . . . . . . . . . . . . . . . . 195.3 Metamodelo en Ecore para los acueductos. . . . . . . . . . . . . . 215.4 Metamodelo en Ecore para los alcantarillados. . . . . . . . . . . . 225.5 Editor Grafico de Hydraulic Networks . . . . . . . . . . . . . . . 225.6 Esquema general de la MTC sobre la cual funciona Hydraulic Net-

works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.7 Esquema de la transformacion Modelo a Modelo de la MTC. . . 255.8 Esquema de la transformacion Modelo a Texto de la MTC. . . . 275.9 Esquema de la ejecucion de los motores hidraulicos. . . . . . . . 285.10 Esquema de la transformacion Texto a Modelo de la MTC. . . . 29

6.1 Acueducto Cedritos vista desde Epanet. . . . . . . . . . . . . . . 346.2 Alcantarillado Cedritos vista desde Epaswmm. . . . . . . . . . . 346.3 Acueducto Acacias vista desde Epanet. . . . . . . . . . . . . . . . 356.4 Alcantarillado Acacias vista desde Epaswmm. . . . . . . . . . . . 356.5 Modelos de Cedritos conforme con los metamodelos Epanet y

Epaswmm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.6 Modelos de Acacias conforme con los metamodelos Epanet y Epaswmm. 366.7 Acueducto Cedritos vista desde Epanet. . . . . . . . . . . . . . . 376.8 Cedritos desde el editor de HydraulicNetworks. . . . . . . . . . . 386.9 Acacias desde el editor de HydraulicNetworks. . . . . . . . . . . . 386.10 Acacias sin alteraciones. . . . . . . . . . . . . . . . . . . . . . . . 396.11 Acacias con nodos desconectados. . . . . . . . . . . . . . . . . . . 406.12 Acacias con nombres repetidos. . . . . . . . . . . . . . . . . . . . 406.13 Acacias con presiones negativas. . . . . . . . . . . . . . . . . . . . 416.14 Excepcion arrojada por Hydraulic Networks en el analisis conjunto

del modelo Acacias. . . . . . . . . . . . . . . . . . . . . . . . . . 41

1

2 Indice de figuras

1Introduccion

Las empresas encargadas de la administracion y el manejo de las redes dedistribucion de agua potable y de drenaje urbano en las ciudades han cumplidosu labor a traves del manejo adecuado de la informacion relacionada con estas,la cual es recolectada en campo, o tomada de los registros catastrales realizadosdurante los procesos constructivos. La forma como se realiza este trabajo es deimportancia central para los organismos encargados de la administracion de laciudad, ya que de su servicio depende la calidad de vida de la poblacion.

La Division de Agua Potable de la Universidad de Utah ha establecido unaserie de regulaciones a traves de las cuales se rigen las entidades encargadasde administrar el agua en Estados Unidos [3, Datwyler, 2012]. Dentro de estoslineamientos, uno de los mas conocidos es la necesidad de tener un modelo ac-tualizado de las redes de acueducto y alcantarillado de la ciudad. Esto permiteconocer el estado de las redes, y entender la forma como estas responden anteposibles eventos de emergencia que ocurran en el tiempo.

En Colombia no hay ninguna entidad que exija tener un modelo de las redesinstaladas en el paıs. Incluso en ciudades grandes como Bogota, no existe unregistro catastral completo de las redes, es decir, que los ingenieros civiles enmuchos casos no tienen forma de saber donde se encuentran las tuberıas, y enla gran mayorıa de sectores no pueden saber tampoco en de que material estanhechos los conductos, que tamano tienen, cuando fue la ultima vez que se leshizo mantenimiento o fueron reemplazados, y tampoco su estado: si estan fun-cionando, si estan obstruidos, si tienen fugas, etc. Se han hecho intentos parareunir la informacion de las redes en modelos que permitan entender su compor-tamiento, y de esta manera administrarlas de una forma que disminuya los costosde operacion y mantenimiento, aumentando la calidad del servicio. A pesar deesto, en muchas ocasiones los proyectos de construccion deben ser reajustadoso cambiados completamente (incluso cuando las obras ya han empezado y lospresupuestos ya han sido aprobados y dispuestos) debido a obstrucciones conotras redes que no se habıan tenido en cuenta por falta de informacion catas-tral. Se ha calculado que solo la red de acueducto de Bogota (con alrededor de230 mil tuberıas) cuenta con mas de 8 240 Km de tuberıas. De igual forma,en cada cuadra debe haber una valvula de control, y cada tuberıa cuenta con

3

4 1.1. Administracion de redes de Acueducto

dos valvulas de cierre; cuyo estado es generalmente desconocido. Por lo tanto,mantener un registro conjunto de toda la informacion actualizada, tanto de lared de acueducto como de alcantarillado es un gran desafıo, no solo en Bogota,sino en las grandes ciudades del paıs, y sobre todo en pequenas urbanizacionesdonde nunca se han guardado registros de las obras.

La Division de Agua Potable de la Universidad de Utah reconoce la impor-tancia administrativa, economica, tecnica y ambiental sobre el uso de modelospor parte de las empresas encargadas de las redes urbanas, que les permita nosolo tener un registro preciso y actualizado del estado de la red, sino predecirsu comportamiento y ası mejorar el servicio mediante mantenimientos preventi-vos (y no reactivos, como ocurre generalmente en Colombia), reduciendo fugas,conexiones fraudulentas, manteniendo las valvulas en aberturas que controlen co-rrectamente el flujo, conociendo la dinamica de los tanques de almacenamientode la ciudad e incluso, permitiendo la implementacion de sistemas de control entiempo real que manejen la forma en la que se presta el servicio en cada instantedel tiempo.

A continuacion se hara una breve introduccion sobre las redes urbanas, y laforma como los modelos actualmente ayudan al ingeniero a resolver problemasconcretos con los que debe enfrentarse en el ejercicio de su labor.

1.1 Administracion de redes de Acueducto

Es comun encontrar que los ingenieros alrededor del mundo que se dedicana la modelacion de acueductos utilizan herramientas que les permiten abstraerlos componentes principales de las redes de agua potable, de tal forma que seaposible analizar el comportamiento hidraulico y la calidad del agua en el sis-tema. Algunos ejemplos de estas herramientas son EPANET, WaterCAD, Wa-terGEMS, HAMMER, HydrauliCAD, entre otros. El mas utilizado es EPANET—desarrollado por la Agencia de Proteccion Ambiental (EPA)— debido a quees gratuito, facil de utilizar y ha mostrado tener una excelente aproximacion alcomportamiento real de las redes de acueducto.

En ingenierıa hidraulica, los tipos de problemas mas comunes a los que seenfrentan los ingenieros son: validacion de la red, calibracion y diseno. Pararesolver estos problemas usando modelos, el primer paso que se debe realizares la caracterizacion fısica de la red, construyendo el modelo que la represente.En este procedimiento el ingeniero define la cantidad de tuberıas que componela red, la forma como estan conectadas y los componentes de abastecimiento,regulacion y control que hacen parte de ella.

Si el ingeniero se encuentra en la labor de validar una red existente, debebuscar, dentro de los registros catastrales de la ciudad, los datos de la red: ma-teriales, diametros y longitudes de cada tuberıa; ubicacion de valvulas y otrosaccesorios; estaciones de bombeo y sus parametros de funcionamiento y, de serposible, patrones de consumo en diferentes zonas de la ciudad. En caso de nohaber disponibilidad de informacion, el ingeniero debe recolectar la informacionen campo. De esta forma construye su modelo, definiendo los puntos de unionde las tuberıas, incluyendo los elementos especiales que la compongan (tanques,embalses, valvulas, etcetera) e introduciendo los datos que ha obtenido de losregistros. Este procedimiento es necesario cuando se desea evaluar el funciona-miento de un diseno que esta en funcionamiento, o una propuesta de diseno que

Introduccion 5

se planea construir.Si el ingeniero desea realizar la calibracion de un modelo hidraulico antiguo,

debe realizar una gran cantidad de mediciones de presion y flujo en diferentessectores de la red. Con ayuda de la empresa prestadora del servicio de agua po-table, el ingeniero obtiene los datos sobre la cantidad de agua que se consume encada zona de la ciudad. Haciendo uso de diferentes tecnicas de ajuste, el inge-niero es capaz de encontrar los valores reales de rugosidad, diametros internos,estados de las valvulas, etcetera, obteniendo finalmente un modelo actualizadode la red.

Si el ingeniero desea realizar el diseno de una red de acueducto, debe llevar acabo un estudio hidrologico de las zonas alrededor del lugar donde se encuentrala red. A traves de un analisis estadıstico, encuentra la cantidad de agua (cau-dales) que debe ser llevada a cada lugar de la ciudad, y precisar la fuente deabastecimiento. Teniendo estos datos, el ingeniero crea un modelo basado en latopologıa de la ciudad, y es responsable de darle una dimension a la red, defi-niendo el tamano de las tuberıas, de tal forma que se satisfagan las necesidadesde la poblacion. El interes de la comunidad academica que trabaja en estos te-mas, desde hace unas decadas, se centra en la obtencion de la dimension mınimaposible y factible, haciendo que los costos del proyecto se reduzcan al mınimo.Estos costos deben contemplar no solo la etapa de construccion, sino la opera-cion y el mantenimiento de la red a lo largo del tiempo hasta el horizonte dediseno. Este proceso reune una gran cantidad de variables que deben ser tenidasen cuenta, y por lo cual el uso de modelos que manejen la informacion de lared son una valiosa herramienta para conseguir una optimizacion en el diseno deredes urbanas.

En algunas ciudades y en algunos edificios es usual encontrar redes de abas-tecimiento en paralelo. Esto ocurre porque la calidad del agua que transportala red puede variar, dependiendo de la fuente y del uso que se le va a dar. Unejemplo de esto es el uso de aguas lluvias para el abastecimiento de tanquessanitarios y fluxometros, pues la calidad del agua para estos usos no debe sernecesariamente potable.

1.2 Administracion de redes de Alcantarillado

La modelacion de redes de alcantarillado es un problema bastante mas com-plejo, en comparacion con la modelacion de redes de acueducto, debido a la grancantidad de variables geometricas que entran a jugar. Por esta razon, existen unamayor cantidad de herramientas para resolverlos, tales como EPASWMM, Sewer-CAD, SewerGEMS, MOUSE, StormCAD, InfoWorks, MikeUrban, MikeSWMM,entre otros. Uno de los mas utilizados es EPASWMM —desarrollado por la Agen-cia de Proteccion Ambiental (EPA)— debido a que, al igual que EPANET, esgratuito, facil de utilizar y ha mostrado tener una buena aproximacion al com-portamiento real de las redes de alcantarillado. Para este tipo de problemas estoresulta fundamental, ya que es necesario modelar de forma precisa una grancantidad de fenomenos: lluvia, infiltracion, saturacion del suelo, inundaciones,evaporacion, flujo subterraneo, entre otros.

Las redes de drenaje se dividen en 3, dependiendo del tipo de agua quetransporte. Si la red transporta solo el aguas servidas (aguas negras o residuales)es una red sanitaria; si transporta el agua de lluvia, es una red pluvial; mientras

6 1.3. Limitaciones relativas a la actual administracion

que si la red transporta, de manera premeditada o no, aguas sanitarias y aguaslluvias, es una red combinada.

Para el caso de alcantarillados, tambien es posible usar los modelos parahacer validacion del flujo, calibracion de la red y diseno de nuevas redes. Sinembargo, para cada uno de estos casos es necesario recolectar una gran cantidadde informacion, con el fin de introducirla en el modelo para que sea capaz derepresentar de la mejor manera los fenomenos del flujo para el drenaje de laciudad. Esto puede ser una tarea complicada, puesto que los registros catastralesde las redes de drenaje son aun mas escasos que los que existen para acueductos.

La forma en la que trabajan las redes de drenaje tiene muchas variedades.Como regla general, las redes de drenaje no fluyen a presion por razones deseguridad, puesto que ante las posibles fugas que se presenten en la red, se debegarantizar que se escape la menor cantidad de agua contaminada al suelo. Sinembargo, no siempre es posible que toda la red se mantenga a flujo libre, yaque en ocasiones debe ser bombeada, o debe pasar ciertos obstaculos (como rıos,canales, calles, tuberıas de acueducto, entre otros) para los cuales se construyeun sifon. Estas son algunas de las excepciones al flujo que tienen estas redes, yhacen que los modelos cuenten con una mayor cantidad de elementos y motoresde calculo que permitan resolver las ecuaciones hidraulicas tanto para flujo librecomo para flujo a presion.

1.3 Limitaciones relativas a la actual administracion

Las empresas encargadas de la administracion del agua urbana construyenactualmente los modelos de las redes de acueducto y alcantarillado separada-mente. Esto genera algunos problemas, tales como la insercion repetida de datosde entrada y la actualizacion paralela de ambos modelos frente a cambios en lasredes. Del mismo modo, al tener los modelos separados resulta imposible predecirla forma en la que interactuan ambas redes.

Por estas razones se construyo Hydraulic Networks, un lenguaje grafico enel que se maneja de forma conjunta la informacion de las redes de acueducto yalcantarillado.

A traves del siguiente documento se vera en detalle los problemas a los cualesse desea dar solucion a traves de este nuevo lenguaje grafico, los pasos requeridospara su contruccion, y las metodologıas usadas en su validacion, siguiendo laestructura mostrada a continuacion:

Capıtulo 1: Introduccion al contexto en el que se desarrolla el proyecto.

Capıtulo 2: Problematica derivada de la forma en la que tradicionalmente seha trabajado usado modelos hidraulicos

Capıtulo 3: Objetivos que buscan darle solucion al problema planetado.

Capıtulo 4: Marco teorico sobre el cual se trabaja.

Capıtulo 5: Propuesta de solucion hecha, siguiendo los objetivos propuestos.

Capıtulo 6: Validacion de la herramienta a traves de casos de estudio.

Capıtulo 7: Conclusiones del proyecto y propuestas para trabajos futuros.

2Problema

Teniendo en cuenta la importancia que tiene para el ingeniero civil el uso demodelos que contengan la informacion de las redes de acueducto y alcantarillado,para su evaluacion y manipulacion, se describen una serie de problemas y limi-taciones que estos tienen actualmente, a raız de tener que construir sus modelosde forma separada.

2.1 Limitaciones

Modelar de forma separada redes de acueducto y alcantarillado acarrea parael ingeniero hidraulico distintos problemas:

Introduccion de informacion de entrada repetidamente: Como es el caso dela topografıa y las aguas que fluyen por la red, ya que los caudales de aguapotable terminan parcialmente en la red de drenaje.

Generacion de cambios en alguno de los modelos por cambios en el otro: Esnecesario, entonces, tener claridad de la forma como afectan los cambiosen ambos modelos, lo que no es posible teniendolos separados de las redes.Dentro de los cambios que pueden presentarse se incluyen los caudales quese aportan a la red de acueductos, debidos a densificaciones, redisenos, ocambios en el uso del suelo, cambios en la distribucion de las calles, cambiosen las rugosidades y diametros internos de las tuberıas de acueducto porefectos del desgaste, cambios por renovacion de las redes de acueducto oalcantarillado e incluso cambios en los eventos de precipitacion por efectode fenomenos como el cambio climatico.

Disposicion de las tuberıas de drenaje por debajo de todas las tuberıas deacueducto, como una de las restricciones de calidad de las redes.

Garantizar la no interseccion de tuberıas de acueducto y alcantarillado. Altener los modelos separados, no es posible evaluar si existe la posibilidadde que las redes coincidan espacialmente en algun punto.

7

8 2.2. Dialogo con Usuarios

Desconocimiento de la forma como se afectan las redes por la ocurrencia deuna falla en alguna de ellas. Un ejemplo de esto es cuando una tuberıa dealcantarillado se presuriza y el nivel del agua sale por fuera de las tuberıas.En este caso, aunque se sabe que los tanques de almacenamiento de aguapotable estan impermeabilizados, se recomienza hacer revisiones sobre lacalidad del agua en estos puntos.

Calculo de caudales por problemas de infiltracion en las redes de alcanta-rillado, que es una variable difıcil de calcular, y de gran importancia enel diseno de las redes. El modelo de la red de acueducto puede dar lucesa posibles fugas de agua potable que se presenten, y que pueden terminardrenandose por la red de alcantarillado.

Administracion separada de las redes: La empresa que se encarga de reali-zar el mantenimiento y operacion de las redes de acueducto y alcantarilladotiene sus modelos en herramientas separadas, lo que puede presentar des-ventajas a la hora de llevar a cabo obras de rehabilitacion.

2.2 Dialogo con Usuarios

Con el objetivo de centrar el trabajo en la construccion de una herramien-ta que represente una solucion real a problemas con los que esten lidiando losingenieros hidraulicos, se realizaron una serie de entrevistas en las que se reco-lecto informacion valiosa con respecto al modelamiento separado de redes:

Diego Paez Profesor Instructor Departamento de Ingenierıa Civil y Ambientalde la Universidad de Los Andes, Bogota. Octubre 24 del 2013.Las ideas puntuales propuestas por el profesor Paez son las siguientes:

“Tener los modelos de redes en una herramienta conjunta permiteresolver algunos problemas, sin embargo, el numero de nuevas posibi-lidades que se abren con este programa es aun mayor que la cantidadde problemas resueltos”

“Con el objetivo de aprovechar mejor las ventajas del modelo con-junto, es necesario contar con herramientas hidraulicas capaces derealizar disenos en redes de acueducto y redes de alcantarillado”

Paula Cuero Asistente Graduada Centro de Investigacion en Acueductos y Al-cantarillados de la Universidad de Los Andes, Bogota. Octubre 24 del 2013.Las ideas puntuales planteadas por la ingeniera Paula son las siguientes:

“Quiza sea posible entender la forma como se relacionan las fugas delos acueductos con las filtraciones en las redes de alcantarillado. Paraesto, es necesario contar con un modelo de flujo subsuperficial.”

“La herramienta posibilitara el analisis de procesos como el diseno,puesto que funcionan de forma similar. De esta forma, los criterioshidraulicos usados para el diseno optimizado de acueductos puedenser comparados o aplicados a redes de drenaje urbano.”

“La herramienta facilita la evaluacion conjunta de criterios de calidadde disenos como Resiliencia.”

Problema 9

“El programa tiene gran potencial como herramienta de trabajo, puesbrinda nuevas posibilidades a los ingenieros que trabajan en hidraulicade redes.”

“Es importante resaltar la importancia de los Sistemas de InformacionGeografica en el aporte de datos de entrada a cualquier herramientaque administre informacion.”

Juan Saldarriaga Profesor Titular Departamento de Ingenierıa Civil y Am-biental y Vicedecano de Desarrollo de la Facultad de Ingenierıa de la Uni-versidad de Los Andes. Director del Centro de Investigacion en Acueduc-tos y Alcantarillados de la Universidad de Los Andes - CIACUA. Bogota,Diciembre 10 del 2013. Las ideas puntuales planteadas por el profesor Sal-darriaga son las siguientes:

“Debido a que la herramienta es capaz de administrar informacion,serıa util permitirle al usuario realizar consultas sobre la misma. Deesta forma se puede facilitar la administracion de las redes, basada enlos datos que contenga el modelo”

“Es interesante que la herramienta permita trabajar con el problemade densificacion de la ciudad. Para esto, es necesario que se puedaidentificar la zona del sistema de drenaje urbano que falla, cuando serealiza un aumento en el consumo de agua potable.”

“Mas que el proceso de diseno en sı, resulta interesante el manejode informacion que permite el programa. Por lo tanto, deberıamosconcentrarnos mas en convertirlo en una herramienta de operacion.Esto ocurre porque el proceso de diseno ocurre en un lapso de tiempomuy corto comparado con el proceso de operacion, que debe hacersede forma permanente.”

“Serıa interesante que, la herramienta fuera capaz de almacenar yadministrar informacion historica sobre danos.”

“La herramienta presenta utilidades muy interesantes, por lo que sepuede decir que sı corresponde a la solucion de problemas reales.”

2.3 Estado del Arte

Acerca el desarrollo de herramientas que se encarguen de manejar de maneraconjunta la informacion de redes de acueducto y alcantarillado se encuentran muypocos trabajos al respecto. Esto es algo tıpico en el area de ingenierıa hidraulica,debido a que los analisis de interaccion conjunta se realizan, en los casos en losque se hace, sin usar ningun modelo especializado. Debido a que estas tareas sevuelven una practica tradicional, la idea de cambiar estos procesos no es tomadaen consideracion por la gran mayorıa de ingenieros experimentados.

En el area de la investigacion se han encontrado dos trabajos que son deespecial interes para nosotros, puesto que ofrecen adelantos sobre ciertos aspectosque pueden enriquecer el proyecto actual.

1. Daene McKinney y Ximing Cai: En el ano 2001, estos profesores dela Universidad de Texas desarrollaron una metodologıa orientada a obje-tos que permite conectar la informacion contenida en SIG con modelos

10 2.3. Estado del Arte

hidraulicos. Su aporte principal consiste en el aprovechamiento de la infor-macion ya contenida en SIG. Sin embargo, esta metodologıa no tiene encuenta la recuperacion de los mismos, ni un analisis conjunto de los datosteniendo en cuenta la hidraulica de los modelos [10, McKinney, 2001].

2. Henriette Tamasauskas: En el ano 2008 mostro la forma como el sistemade informacion geografica ESRI-ArcGIS permite combinar la informacionespacial de redes de acueducto y alcantarillado para su visualizacion. Suaporte permite ver de forma conjunta el estado hidraulico de cada una delas redes, que es calculado usando MikeUrban. Sin embargo, su aproxima-cion no tiene en cuenta un analisis espacial conjunto, ni ninguna interaccionentre las redes de acueducto y alcantarillado que son usadas como modelosde entrada al SIG[12, Tamasauskas, 2011].

Estas aproximaciones dejan de lado las ventajas que se obtienen de que losmodelos de las redes puedan ser manejados de forma independiente para suanalisis hidraulico, y luego de manera conjunta. De esta manera, se puede lograruna consistencia geometrica e hidraulica de las redes urbanas que comparten unespacio dentro de una ciudad.

Hydraulic Networks cuenta con estas caracterısticas, sin embargo aun no se hatenido en cuenta la unificacion de su modelo con el de los Sistemas de InformacionGeografica. Esto representara ventajas posteriores para el ingeniero, puesto quelos SIG permiten mezclar informacion adicional sobre los modelos, de maneraque sea posible tomar desiciones de diseno de una forma mas sencilla.

3Objetivos

En el proyecto de desarrollo de Hydraulic Networks se busca entender su im-portancia como herramienta de modelamiento conjunto de redes de acueductoy alcantarillado. Se plantea la construccion de las partes que lo conforman, ha-ciendo uso de las herramientas de modelamiento que ofrece Eclipse Modelling -EMF, e ingenierıa de modelos - MDE.

Dicho esto, los objetivos del proyecto son los siguientes.

3.1 Objetivo General

Construir una herramienta para el ingeniero hidraulico en el que sea posi-ble modelar redes de acueducto y alcantarillado simultaneamente, permitiendoleconstruirlas, validarlas y analizarlas de forma conjunta.

3.2 Objetivos Especıficos

Construir metamodelos que incluyan dentro de sı todos los elementos pararepresentar de forma completa un modelo de red de acueducto y/o dealcantarillado.

Construir un modelo que permita definir graficamente redes de acueductoy alcantarillado de manera conjunta.

Definir las transformaciones de Modelo a Modelo para hacer transferenciasde informacion, simplificaciones y agregaciones basadas en los metamode-los.

Definir una transformacion de Modelo a Texto que permita traducir lainformacion de los modelos al lenguaje de los motores hidraulicos.

Construir algoritmos de analisis conjunto de la informacion de las redes deacueducto y de alcantarillado.

11

12 3.2. Objetivos Especıficos

4Base Teorica

Con el objetivo de introducir los terminos y herramientas usados se procedea hablar sobre los temas que involucran la ingenierıa de modelos y elementos quehacen parte en la construccion de la solucion del problema planteado.

4.1 Definiciones relativas al MDE

Las tecnicas usadas en el desarrollo de Hydraulic Networks estan enmarcadasen la Ingenierıa de Modelos. Las siguientes son definiciones que aclaran la formaen la que funcionan estas tecnicas y una aclaracion de lo que es el modelamientotanto para ingenieros hidraulicos como para ingenieros de sistemas.

4.1.1. Ingenierıa orientada por modelos

Model Driven Engineering (MDE), es una rama de la ingenierıa de sistemasen donde los procesos estan asociados a la produccion y uso de modelos. Esutil, ya que permite el desarrollo de software basado en el conocimiento delproblema, separandolo del conocimiento en lenguajes de programacion de bajonivel [2, Casallas, 2012]. Esta es una ventaja con respecto a otras metodologıasde desarrollo de software, puesto que no requiere un amplio conocimiento enlenguajes programacion, sino en la naturaleza del problema. Para el ingenierohidraulico es mas sencillo programar un modelo de una red urbana en terminosde sus componentes (tuberıas, uniones, valvulas, tanques, etcetera), y no enterminos de un lenguaje de programacion de proposito general.

4.1.2. Modelos y Metamodelos

Segun Stachowiak un modelo es una abstraccion, una representacion de larealidad, una simplificacion que toma un conjunto de partes de interes paraformar un esquema que represente la realidad para un proposito concreto [9,Kuhne, 2005]. Existen varios tipos de modelos, dependiendo de la informacionque contengan. Un grupo especial de modelos esta hecho para describir modelos,

13

14 4.2. Herramientas de Modelamiento

y son llamados metamodelos [9, Kuhne, 2005]. Estos seran usados para construirla solucion al problema planteado.

4.1.3. Transformacion de Modelos

El Grupo de Gerencia de Objetos (Object Management Group - OMG) haceuna definicipon de la transformacion de modelos basada en la Arquitectura yel Desarrollo Orientado por Modelos - MDA y MDD, respectivamente. En estadefinicion, se establece que una transformacion es el proceso de convertir unmodelo en otro modelo de un mismo sistema [1, Biehl, 2010].

4.1.4. Cadena de Transformacion de Modelos - MTC

Hydraulic Networks se vale de una Cadena de Transformacion de Modelos(MTC), en la que se usan una serie de herramientas (que seran explicadas en lasiguiente seccion) para llevar la informacion de un modelo original (el modeloconjunto, en este caso) hasta las herramientas que manejan un lenguaje especıfico(los motores de calculo hidraulico) y del mismo modo en el camino de regresohasta el modelo original.

4.1.5. Modelamiento en Ingenierıa Hidraulica y en Ingenierıa deSistemas

En ingenierıa de sistemas, el modelamiento consiste en la creacion de modelosque incluyan los elementos que hacen parte de un lenguaje especıfico, y la inge-nierıa de modelos se refiere al manejo y la manipulacion de estos. Por otra parte,el modelamiento en ingenierıa hidraulica se ha relacionado tradicionalmente contodas las acciones que involucren al modelo.

4.2 Herramientas de Modelamiento

Con el objetivo de construir Hydraulic Networks se usaron las siguientesherramientas y componentes. Todas las herramientas hacen parte del frameworkpara modelacion que provee Eclipse.

4.2.1. Eclipse - EMF

Es una plataforma de trabajo de Eclipse que permite realizar ingenierıa demodelos (MDE) de una forma sencilla, incluyendo un conjunto de lenguajes yherramientas que logran realizar las tareas y manipulaciones relacionadas conmodelos [7, Eclipse Foundation, 2013].

4.2.2. EMF Core

Es una herramienta que permite construir metamodelos conformes con Ecoreque es un subconjunto del metamodelo UML. Este metamodelo permite definircompletamente todos los elementos que hacen parte de un lenguaje especıfico [7,Eclipse Foundation, 2013].

Base Teorica 15

4.2.3. Sirius

Es una herramienta para modelamiento grafico que permite configurar unavisualizacion personalizada de un modelo de EMF. Provee una gran cantidad deformas de personalizacion y programacion, por lo que se trata de la herramientamas adecuada para ser el editor del lenguaje grafico de Hydraulic Networks [8,Eclipse Foundation, 2012].

4.2.4. ATL

Es un lenguaje de transformacion de modelos, que se basa en los elementosque hacen parte de los metamodelos de origen y de destino, con el objetivo detransformar las partes de un modelo inicial en otro modelo que es conforme almetamodelo de destino. Es usado en la desagregacion del modelo conjunto enlos modelos simples de las redes, y en el proceso inverso [6, Eclipse Foundation,2013].

4.2.5. Acceleo

Es un lenguaje de transformacion que toma modelos y los convierte en texto.Es usado para generar los archivos que van a ser leıdos por los motores de calculohidraulico [11, Obeo, 2013].

4.3 Herramientas de Calculo Hidraulico

Las herramientas de calculo hidraulico que seran usadas son los programasdesarrollados por la Agencia de Proteccion Ambiental Estadounidense - EPA, queson unas de las herramientas mas utilizadas por ingenieros en todos el mundopara la modelacion hidraulica de las redes de agua urbana.

4.3.1. Epanet

EPANET es una herramienta capaz de manejar todos los elementos y lasecuaciones necesarias para describir el comportamiento hidraulico de las redesde acueducto. Esta permite la construccion del modelo a traves de su interfazgrafica o archivos de texto, para lo cual requiere la informacion topografica rela-cionada con cada uno de los nodos de la red. De igual forma, en sus resultadosde reporte, es capaz de identificar irregularidades en el funcionamiento de la redcomo problemas con las presiones, el control de las bombas, los estados de lasvalvulas, la calidad del agua, entre otros[4, Epanet, 2013].

4.3.2. Epaswmm

EPA SWMM (Storm Water Management Model) es una herramienta capaz demanejar los elementos propios de las redes de alcantarillado. Dentro de su modelo,contiene las ecuaciones de masa y energıa que permiten resolver la hidraulica dela red. Al igual que Epanet, Swmm permite la construccion del modelo a travesde su interfaz grafica o archivos de texto, requiriendo informacion topograficaprecisa para cada uno de los nodos de la red [5, Epaswmm, 2013].

16 4.3. Herramientas de Calculo Hidraulico

5Propuesta de Solucion

Con el objetivo de facilitar el trabajo de modelamiento de redes de acueductoy alcantarillado, se ha construido una herramienta que es capaz de unificar losmodelos de ambas redes y producir nueva informacion a partir del analisis con-junto. La nueva herramienta —Hydraulic Networks— esta basada en un modelocapaz de representar los elementos que componen ambos tipos de redes de formasimultanea.

5.1 Resumen de la solucion

Hydraulic Networks es una herramienta que brinda una ayuda a los inge-nieros hidraulicos, mediante la evaluacion conjunta de los datos de acueductoy alcantarillado. Este procedimiento es posible, gracias a la abstraccion de loselementos que componen las redes, en un lenguaje que puede ser usado por cual-quier persona que conozca del tema. El esquema general de solucion se muestraen la Figura 5.1, donde:

1. Es el proceso a traves del cual el ingeniero introduce la informacion almodelo. Este esta compuesto por elementos que hacen parte de las redes deacueducto y/o de alcantarillado, por lo que no es necesario que el ingenieroconozca de temas adicionales a los de su area. De esta manera, se aprovechael hecho de que en ambos tipos de redes existen elementos similares comoconductos, nodos, tanques, entre otros. La abstraccion de los modelos deacueducto y alcantarillado en sus elementos basicos es una de las grandesventajas que ofrece el trabajo con modelos.

2. Cuando los elementos de las redes estan introducidas en el modelo conjuntorepresentado por el cuadro “Elementos de las Redes”, es posible usar lainformacion como datos de entrada de simulaciones en Epanet y Epaswmm(en forma de archivos *.INP). Sin embargo, este procedimiento termina eneste punto, pues no existe ninguna herramienta que permita alimentar elmodelo con la informacion de salida, ni tampoco usar los datos de salidade ambos modelos de manera conjunta.

17

18 5.1. Resumen de la solucion

Figura 5.1 Esquema general de la solucion

3. La solucion tiene en cuenta la informacion compartida entre ambos tiposde redes, y permite incluirla completamente en el lenguaje Hydrulic Net-works. Aquı, sufre un proceso de transformacion que permite su analisisde forma separada, con el fin de verificar la consistencia de los modelosindependientes. Luego de esto, la informacion del analisis es recuperada,ingresada al modelo original, que tendra los datos necesarios para llevar acabo un analisis conjunto de la informacion contenida en ambas redes. Esteprocedimiento de transformaciones es llamado Cadena de Transformacionde Modelos - MTC, y facilita el trabajo con modelos que siguen un lenguajeespecıfico.

4. Hydraulic Networks esta en la capacidad de informar al ingeniero sobreposibles fallas/errores en la validacion conjunta del modelo. En caso dehaberse obtenido alguna falla en los analisis independientes, esta situaciontambien es reportada al usuario a traves del modelo que construyo inicial-mente.

Vale la pena anadir que el modelo de Hydraulic Networks puede ser alimen-tado a traves de su editor grafico, donde pueden ser construidas redes de ambostipos; o puede obtener la informacion de entrada directamente desde los archivos*.INP que definen de forma separada las redes, para luego unificar los datos enun modelo conjunto.

Poder manejar la informacion de las redes de acueducto y alcantarillado atraves de multiples herramientas y formas de visualizacion, basandose unicamen-te en la definicion de los elementos que las componen, es una de las ventajas masdestacadas del trabajo con modelos. La ingenierıa de modelos ha permitido facili-tar el trabajo de profesionales en areas especıficas gracias a que permite abstraerlos elementos de un problema de interes, definiendo una sintaxis concreta, y usarla informacion para llevarla a otras herramientas con gran facilidad.

Propuesta de Solucion 19

Figura 5.2 Lenguaje de Hydraulic Networks

5.2 Definicion del Lenguaje

El primer paso en la construccion de Hydraulic Networks es la definicion delos metamodelos que definen el lenguaje conjunto y los lenguajes independientes.Los metamodelos necesarios son:

1. Un metamodelo sobre el cual trabajara la aplicacion; que contenga la infor-macion necesaria para representar conjuntamente a las redes de acueductosy a las de alcantarillado. La definicion de este metamodelo se puede apre-ciar en la Figura 5.2.

2. Un metamodelo que contenga la informacion necesaria para definir com-pletamente una red de acueducto (en este caso, con una organizacion talque se facilite la introduccion de los datos a EPANET).

3. Un metamodelo que contenga la informacion necesaria para definir com-pletamente una red de alcantarillado (con una organizacion similar a la deEPASWMM).

5.2.1. Elementos del lenguaje Hydraulic Networks

Los elementos que hacen parte de este lenguaje se muestran en la Figura 5.2de forma separada por colores. Los elementos de color amarillo hacen referenciaa elementos exclusivos de redes de alcantarillado. Los elementos de color azulhacen referencia a elementos exclusivos de redes de acueducto. Los elementosque hacen parte de ambas redes se muestran de color verde. Es responsabilidadde las herramientas de manipulacion de modelos la correcta separacion de estoselementos, de tal forma que los que hagan parte de la red de acueducto seanseparables de los que hacen parte de la de alcantarillado.

20 5.2. Definicion del Lenguaje

5.2.2. Reglas sintacticas del lenguaje Hydraulic Networks

El metamodelo que define Hydraulic Networks se encuentra enriquecido conuna serie de reglas que impiden la ocurrencia de errores durante la construcciondel modelo conjunto. Estas reglas estan escritas en un Lenguaje de Restriccionde Objetos - OCL, y son las que se muestran a continuacion:

1. NodoConectado: No puede existir ningun nodo desconectado en la red.

2. IDRepetidoNodo: No pueden existir dos nodos con el mismo nombre.

3. TuberiaBienConectada: Los nodos de entrada y salida de la tuberıa debenser diferentes.

4. RedConsistente: Los nodos de entrada y salida de la tuberıa deben perte-necer al mismo tipo de red.

5. ContieneSalidasEmbalse: Un embalse, ademas de estar conectado a la red,debe tener al menos una conexion de salida para poder alimentar a la redde acueducto.

6. LimitesAltura: Los lımites de altura en los tanques estan definidos de ma-nera consistente. Esto quiere decir que no pueden ocurrir casos en los quela altura maxima es menor a la mınima, o que la altura inicial esta porfura del rango definido, entre otros eventos.

7. ContieneSalidasTanque: Igual que un embalse, el tanque debe tener al me-nos una tuberıa de salida.

8. IDRepetidoLinea: Ninguna tuberıa, valvula o bomba puede compartir elID con otra linea de la red.

9. ExcepcionEpanet: Si ha ocurrido alguna excepcion en la ejecucion del mo-delo de acueducto.

10. ExcepcionEpaswmm: Si ha ocurrido alguna excepcion en la ejecucion delmodelo de alcantarillado.

11. NumeroNodos: Debe haber al menos un nodo en la red.

12. HayEmbalseOTanque: Debe haber en el modelo al menos un embalse otanque que alimente al acueducto.

5.2.3. Elementos del modelo Epanet

El metamodelo de EPANET fue construido tomando los elementos que con-forman el codigo fuente de los archivos *.INP, que son la forma como se ingresanlos datos de entrada al programa. Sin embargo, el modelo de EPANET es validopara cualquier herramienta de modelamiento de acueductos, como REDES, oWaterGEMS, ya que estos modelos tomaron como ejemplo el esquema de da-tos de EPANET, y tienen pocas diferencias entre sı. Si se desea realizar unatransformacion que se ajuste mucho mas a los modelos de otros programas, serecomienda ajustar el metamodelo de EPANET, con el objetivo de anadir ocambiar las partes necesarias. El metamodelo se muestra en la Figura 5.3.


Figura 5.3 Metamodelo en Ecore para los acueductos.

5.2.4. Elementos del modelo Epaswmm

El metamodelo de EPASWMM fue construido de la misma manera que elmetamodelo de EPANET. Al igual que este, es valido para representar cualquierred de alcantarillado. El metamodelo de SWMM es el que se muestra en la Figura5.4.

5.3 Editor Grafico del Lenguaje

Como ya se ha mencionado anteriormente el editor grafico sobre el cual sepuede construir el modelo conjunto esta definido usando las herramientas queprovee Sirius.

En este editor grafico es posible identificar los errores generados durante laconstruccion del modelo, por violacion de las reglas sintacticas definidas en elmetamodelo.

Tambien, permite definir las caracterısticas graficas y el comportamiento delos elementos en ciertas situaciones, por lo que es la herramienta mas indicadapara ser usada como editor grafico de Hydraulic Networks.

Un ejemplo de como se ve el editor, en su capa de alcantarillados, se muestraen la Figura 5.5

22 5.3. Editor Grafico del Lenguaje

Figura 5.4 Metamodelo en Ecore para los alcantarillados.

Figura 5.5 Editor Grafico de Hydraulic Networks


Figura 5.6 Esquema general de la MTC sobre la cual funciona Hydraulic Networks.

5.4 Resumen de la Cadena de Transformacion de Modelos

Ya se ha dicho que Hydraulic Networks funciona sobre una MTC, a traves dela cual hace uso de los motores de calculo hidraulico y recupera la informacionque estos proveen. Los pasos en los que esto ocurre son los que se mencionan acontinuacion (ver Figura 5.6).

Paso 1: Es la transformacion Modelo a Modelo donde se separa la informacionde una de las redes a partir del modelo conjunto. Durante el proceso seguarda un registro de la transformacion, con el objetivo de poder realizarel proceso inverso.

Paso 2: Es el proceso a traves del cual se traduce el modelo de Acueducto/Al-cantarillado a un archivo (*.INP) que puede ser leıdo por la librerıa deEPANET/EPASWMM.

Paso 3: Es el proceso en el que se toman los datos generados por la herramientade modelacion (EPANET o EPASWMM) y se reincorporan a los modelosindependientes de Acueducto y Alcantarillado.

Paso 4: Es el proceso a traves del cual se incluyen los nuevos datos del modelode Acueducto/Alcantarillado al modelo conjunto de Hydraulic Networks.Para esto es necesario tener acceso a las trazas de transformacion, obtenidasen el Paso 1.

24 5.5. Transformacion M2M - Desagregacion

5.5 Transformacion M2M - Desagregacion

El primer paso en la MTC consiste en usar el lenguaje de transformacion demodelos ATL, con el objetivo de transformar el modelo conjunto de HydraulicNetworks en un modelo simplificado que contenga informacion de una sola red,ya sea de acueducto o de alcantarillado. Para esto, es necesario haber definido elmetamodelo conjunto y los metamodelos independientes de acueductos y alcan-tarillados. De esta manera, el motor de transformacion de ATL toma un modeloconforme con el metamodelo conjunto y, basado en el metamodelo independiente,construye un modelo conforme a este, con informacion proveniente del modelooriginal, como se muestra en la Figura 5.7. Este paso es necesario, ya que seconsiguen aislar los elementos de interes para que funcionen correctamente lasherramientas de calculo hidraulico. Durante este proceso se deja un registro otraza de cada una de las transformaciones realizadas, con el objetivo de conocerel origen de los elementos que componen el modelo de destino, de tal forma quesea posible realizar el proceso inverso.

El proceso inverso debe realizarse siempre que se hayan generado nuevosdatos en los modelos independientes.

El lenguaje de transformacion de modelos de ATL funciona con una maquinavirtual que ordena de manera automatica la cadena de transformaciones que sedeben realizar, segun el codigo. A continuacion se muestra parte del codigo de latransformacion Modelo a Modelo que convierte un modelo de Hydraulic Networksen un modelo de acueductos:


Figura 5.7 Esquema de la transformacion Modelo a Modelo de la MTC.

1 −− @nsURI MM1=http :// epanet /2 .02 −− @nsURI MM=http :// networks345 module n2e ;6 create OUT: MM1 from IN : MM;78 rule red2network {9 from

10 r : MM!Red11 to12 n : MM1! Network (13 t i t l e <− r . nombre ,14 l i n k s <− r . l i n e a s ,15 nodes <− r . nodos ,16 d e s c r i p t i o n <− r . d e s c r i p c i on17 )18 }1920 rule tubo2pipe {21 from22 t : MM! Tuberia (23 not ( t . s a l i d a . oc l IsKindOf (MM!Camara ) )24 )25 to26 p : MM1! Pipe (27 id <− t . nombre ,28 diameter <− t . diametro ,29 length <− t . long i tud ,30 roughness <− t . rugosidad ,31 i n i t S t a t u s <− t . e s t a d o I n i c i a l ,32 minor lo s s <− t . perdidaMenor ,33 input <− t . entrada ,34 output <− t . s a l i da ,35 currentF <− t . fActual ,36 currentFlow <− t . caudalActual ,37 cur rentReactVe loc i ty <− t . velocidadReacActual ,38 cur r entSta tus <− t . estadoActual ,39 currentUnitLoss <− t . perdUnitar iaActual ,40 cu r r en tVe l o c i t y <− t . ve loc idadActual ,41 network <− t . red42 )43 }44 rule union2 junct ion {45 from46 e : MM! Union47 to48 r : MM1! Junct ion (49 id <− e . nombre ,50 xCoord <− e . coordX ,51 yCoord <− e . coordY ,52 e l e v a t i on <− e . cota ,53 baseDemand <− e . demandaBase54 )55 }

26 5.6. Transformacion M2T - Traduccion

5.6 Transformacion M2T - Traduccion

El segundo paso en la MTC consiste en la transformacion del modelo simpli-ficado de la red en texto, haciendo uso de Acceleo, que genera una codificacionque es usada como dato de entrada para el motor de calculo hidraulico (en unarchivo *.INP para EPANET o EPASWMM segun sea el caso). Para esto, la he-rramienta Acceleo toma como referencia el metamodelo de la red independiente,y a traves de un codigo es capaz de transformar la informacion del modelo de lared (conforme con el metamodelo de referencia) en texto, tal como se explica enla Figura 5.8.

Se tomo como ejemplo la estructura del archivo *.INP que contiene los da-tos de entrada para EPASWMM. Parte del codigo de Acceleo usado para latraduccion del modelo de alcantarillados es el siguiente:

[ comment encoding = UTF−8 / ][module generate ( ’ http ://epaswmm/1.0 ’ ) ]

[ template public generateElement ( aSewer : Sewer ) ][ comment @main/ ][ f i l e ( aSewer . t i t l e . concat ( ’EPASWMM. inp ’ ) , f a l s e , ’UTF−8 ’ ) ][ ’ [ ’ / ]TITLE [ ’ ] ’ / ][ aSewer . t i t l e / ] : [ aSewer . d e s c r i p t i o n / ]

[ ’ [ ’ / ]RAINGAGES[ ’ ] ’ / ]; ; Rain Recd . Snow Data Source; ; Name Type Freq . Catch Source Name;;−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−[ for ( ra ingage : Raingage | aSewer . subcatchments . ra ingage ) ]

[ ra ingage . name/ ] [ ra ingage . rainType/ ] [ ra ingage . recdFreq / ][ / for ]

[ ’ [ ’ / ]SUBCATCHMENTS[ ’ ] ’ / ]; ;; ; Name Raingage Outlet;;−−−−−−−−−−−−−− −−−−−−−−−−−−−−−− −−−−−−−−−−−−−−−−[ for ( subc : Subcatchment | aSewer . subcatchments ) ]

[ subc . id / ] [ subc . ra ingage . name/ ] [ subc . ou t l e t . id / ][ / for ]

[ ’ [ ’ / ] INFILTRATION[ ’ ] ’ / ]; ; Subcatchment MaxRate MinRate;;−−−−−−−−−−−−−− −−−−−−−−−− −−−−−−−−−−[ for ( subc : Subcatchment | aSewer . subcatchments ) ]

[ subc . id / ] [ subc . i n f i l t r a t i o n . maxRate/ ] [ subc . i n f i l t r a t i o n . minRate/ ][ / for ]

[ ’ [ ’ / ]JUNCTIONS[ ’ ] ’ / ]; ; Inve r t Max .; ; Name Elev . Depth;;−−−−−−−−−−−−−− −−−−−−−−−− −−−−−−−−−−[ for (manhole : Manhole | aSewer . nodes ) ]

[ manhole . id / ] [ manhole . e l e v a t i on / ] [ manhole . maxDepth/ ][ / for ]

[ ’ [ ’ / ]CONDUITS[ ’ ] ’ / ]; ; I n l e t Outlet; ; Name Node Node;;−−−−−−−−−−−−−− −−−−−−−−−−−−−−−− −−−−−−−−−−−−−−−−[ for ( conduit : Conduit | aSewer . condui t s ) ]

[ conduit . name/ ] [ conduit . i n l e t . id / ] [ conduit . o u t l e t . id / ][ / for ]

[ ’ [ ’ / ]XSECTIONS[ ’ ] ’ / ]; ; Link Shape Geom1;;−−−−−−−−−−−−−− −−−−−−−−−−−− −−−−−−−−−−−−−−−−[ for ( conduit : Conduit | aSewer . condui t s ) ]

[ conduit . name/ ] [ conduit . xSect ion . type/ ] [ conduit . xSect ion . geom1/ ][ / for ]

[ ’ [ ’ / ]COORDINATES[ ’ ] ’ / ]; ; Node X−Coord Y−Coord;;−−−−−−−−−−−−−− −−−−−−−−−−−−−−−−−− −−−−−−−−−−−−−−−−−−[ for ( node : Node | aSewer . nodes ) ]

[ node . id / ] [ node . xCoord/ ] [ node . yCoord/ ][ / for ]

[ / f i l e ][ /template ]


Figura 5.8 Esquema de la transformacion Modelo a Texto de la MTC.

5.7 Ejecucion del Analisis Hidraulico

Los servicios de las herramientas EPANET y EPASWMM seran accedidasmediante los servicios expuestos por sus respectivas librerıas dinamicas (*.dll).

Para esto, se compilaron en Microsoft Visual Studio proyectos ejecutablesque son capaces de leer todas las funciones expuestas en las librerias dinamicastanto de Epanet como de Epaswmm. Estos archivos ejecutables toman el archivo*.INP de acueducto o alcantarillado, segun el caso, y producen un archivo *.RPTcon la informacion de salida de las librerıas (ver Figura 5.9).

La librerıa dinamica de EPANET esta disponible online desde la pagina oficialde la EPA [4]. Aquı muestran en detalle como utilizar las funciones expuestas porla librerıa de una forma sencilla, y los errores que esta puede generar. Tambiencontiene interfaces con las funciones de la librerıa escritos en varios lenguajes deprogramacion, como visual basic, c/c++ y pascal. Todos estos archivos se reunenen un conjunto conocido como EpanetToolkit.

Por otro lado, para EPASWMM no existen recursos en lınea donde se pue-da obtener un toolkit similar al que tiene Epanet. Sin embargo, los ingenierosque han producido la version en espanol de Epanet y EpaSwmm, Pedro Iglesisy Javier Martınes, de la Universidad Politecnica de Valencia, nos han facilitadouna version preliminar del SwmmToolkit. Ası, el proceso para realizar el calculohidraulico en Epaswmm se hizo de la misma manera: se produjo un ejecutabledesde Microsoft Visual Studio que toma el *.INP con la informacion del alcan-tarillado y produce un reporte con los respectivos resultados.

Las librerıas dinamicas de EPANET y EPASWMM para la realizacion de losanalisis hidraulicos, ofrecen los siguientes prodecimientos:

1. Abrir/cerrar un archivo *.INP.

2. Definir los valores de los atributos de los nodos, tubos, patrones, y otroscomponentes de las redes.

3. Realizar un analisis hidraulico a traves de una simulacion de flujo, ya seaen un tiempo puntual o en perıodo extendido. En este proceso se crea unarchivo .RPT donde se encuentran registrados los resultados de la simula-cion.

28 5.8. Recuperacion de los datos de los Reportes

Figura 5.9 Esquema de la ejecucion de los motores hidraulicos.

4. Realizar una simulacion de calidad de agua. En este proceso tambien secrea un archivo .RPT donde se encuentran registrados los resultados de lasimulacion.

5. Obtener informacion de los nodos, los enlaces o los patrones, luego derealizar una simulacion.

5.8 Recuperacion de los datos de los Reportes

El paso siguiente comprende la traduccion de los datos de salida (de un archi-vo *.RPT en el caso de EPANET o EPASWMM) del motor de calculo hidraulicopara construir un modelo, conforme con el metamodelo original simplificado dela red. Este modelo contiene la informacion de salida del modelo, ası como loseventos o excepciones que se hayan generado en el calculo, como se muestra enla Figura 5.10.

Este procedimiento se realiza tomando el modelo que se tenıa antes de rea-lizar la traduccion a texto usando Acceleo. Mediante una rutina que revisa elreporte, se recuperan los datos relevantes y estos son agregados al modelo origi-nal, mediante la identificacion de los elemtos por su ID. De esta manera, no esnecesario reconstruir completamente el modelo original.

En caso de obtenerse alguna excepcion del modelo, los datos del error sonalmacenados en un atributo del elemento principal de la red. Ası, cuando serecupere el modelo conjunto nuevamente, este reportara problemas con las vali-daciones independientes.

5.9 Analisis Conjunto del Modelo

El analisis conjunto se lleva a cabo unicamente cuando el modelo ha sidollevado a traves de la MTC, puesto que ası se valida la consistencia individualde cada red. Una vez hecho esto, se verifica la consistencia conjunta del modelo.Los eventos que verifica Hydraulic Networks son los siguientes:


5.9.1. Eventos Conjuntos

Los eventos conjuntos son los generados a partir del analisis de la informacionde ambas redes. Estos eventos no se generan en los motores de calculo hidraulico,sino que son el resultado de algoritmos de evaluacion conjunta con los que cuentaHydraulic Networks; o bien, restricciones propias del lenguaje. Las excepcionesconjuntas que evalua son las siguientes:

1. Interseccion espacial entre tuberıas de acueducto y de alcantarillado, oentre estas y otros elementos de las redes; tales como tanques, valvulas,vertederos, embalses, bombas, etc. Este aviso debe darse sobre las tuberıaso elementos que se interceptan.

2. Si alguno de los nudos de la red de acueducto no indica el nudo de alcan-tarillado al cual se descargan las aguas servidas luego del consumo. Esteaviso debe darse sobre los nudos que tengan esa propiedad sin definir.

3. Ninguna union puede conectar un nudo de acueducto con uno de alcanta-rillado. El aviso debe darse a las uniones que incumplan con este requisito.

4. El identificador de los elementos de las redes no puede repetirse, ni entrelos nudos, ni entre las uniones. El aviso debe darse sobre los elementos quetengan repetido su identificador.

5. Si el modelo del acueducto arroja alguna excepcion, el modelo del alcantari-llado no puede ser analizado, puesto que algunas de sus entradas dependende las salidas del primer modelo.

6. Si el usuario ası lo requiere se puede realizar una verificacion espacial delalcantarillado, de tal manera que ninguna tuberıa o elemento de alcanta-rillado se encuentre a una cota superior a alguna tuberıa o elemento de lared de acueducto. Este aviso debe darse sobre los elementos que incumplancon la restriccion

5.9.2. Solucion a los eventos conjuntas

La solucion respectiva propuesta, para cada una de las excepciones planteadasanteriormente son las siguientes:

Figura 5.10 Esquema de la transformacion Texto a Modelo de la MTC.

30 5.10. Manejo de Eventos

1. La interseccion espacial se lleva a cabo mediante el calculo de las ecuacio-nes parametricas que definen un cilindro. En primer lugar, se identificanlas coordenadas (x, y, z) maximas y mınimas de cada tuberıa. Luego, secomprarn todas las tuberıas, de tal manera que ninguna comparta un mis-mo espacio 3D. Compartir un espacio 3D quiere decir que alguna tuberıase encuentra parcial o totalmente dentro del rango espacial de otra. Encaso de compartir un espacio 3D, se procede a evaluar punto a punto (conintervalos de un 1 % en la longitud total de la tuberıa) para encontrar ellugar en donde existe la interseccion, en caso de que exista.

2. La verificacion del ingreso de tuberıas de aporte a nudos de acueducto estaespecificada dentro de las reglas del lenguaje.

3. La verificacion de consistencia acueducto/alcantarillado en el modelo estaincluida como una restrccion OCL.

4. La verificacion de no repeticion de nombres se realiza sobre el metamodelode Hydraulic Networks usando OCL.

5. Hydraulic Networks esta encargado, como algoritmo de analisis, de manejarla informacion que recibe de los motores de calculo hidraulico. En caso deque alguno falle, este avisa al usuario y detiene los procesos.

6. Hydraulic Networks usa un algoritmo de analisis espacial similar al usadopara la busqueda de intersecciones: verifica que el espacio 3D en el eje Zde una tuberıa de acueducto se encuentre encima de las de alcantarilladoque comparten

5.10 Manejo de Eventos

Hydraulic Networks es capaz de identificar y e informar al usuario cuan-do ocurre una excepcion o una advertencia en el modelo. En este orden deideas, Hydraulic Networks reconoce cuando una herramienta, ya sea EPANETO EPASWMM, arroja un informe de excepcion o un mensaje de advertencia.

5.10.1. Excepciones y Advertencias Independientes

Los eventos independientes son los retornados por los motores de calculohidraulico EPANET y EPASWMM, cuando trabajan con los datos generadoscon su modelo desagregado. A continuacion hay una lista de las excepciones yadvertencias independientes:

Excepciones de EPANET y EPASWMM

Muchas de las excepciones son compartidas por EPANET y EPASWMM.Cada una de estas cuenta con un codigo caracterıstico, y se genera sobre unelemento particular de la red.

201 Error de sintaxis en el archivo *.INP

202 Illegal numeric value in function call → Un elemento (#ID) tiene unvalor numerico invalido.


203 Undefined node in function call → Un elemento (#ID) esta haciendoreferencia a un nodo inexistente.

204 Undefined link in function call → Un elemento (#ID) esta haciendoreferencia a una tuberıa/valvula/bomba inexistente.

205 Undefined time pattern in function call → Un elemento (#ID) estahaciendo referencia a un patron inexistente.

206 Undefined curve pattern in function call → Un elemento (#ID) estahaciendo referencia a una curva inexistente.

212 Undefined source node in function call → Un elemento (#ID) estahaciendo referencia a un nodo fuente inexistente.

215 ID already in use → un nodo o una lınea repite un ID existente

222 Una lınea sale y entra al mismo nudo.

223 Not enough nodes in the network to analyze → no hay ningun elementoen la red.

224 There was not at least one tank or reservoir in the network → No hayninguna fuente en la red.

225 Invalid lower/upper levels were specified for a tank → Los nivelesmaximos y minimos del tanque (#ID) no abarcan un rango valido.

233 A node was not connected to any links. → El nodo (#ID) se encuentradesconectado.

Hydraulic Networks maneja cada uno de estos eventos, dependiendo del caso,de la siguiente manera:

201: Se avisa al usuario desde la clase principal que algun parametro deentrada es incorrecto.

202: Los valores numericos estan restringidos en la sintaxis del lenguaje,por lo que se impide desde la creacion del modelo.

203, 204, 205, 206, 212: La sintaxis del lenguaje impide que ocurram estasexcepciones.

215: Las restricciones OCL impiden que se repitan ID tanto en lineas comoen nodos.

222: Las restricciones OCL impiden que una tuberıa este mal conectada.

223: El modelo principal tiene una restriccion OCL que verifica que hayamas de un nodo en la red.

224: Las restricciones OCL obligan a que exista al menos un embalse otanque que alimente la red de acueducto.

225: Las restricciones OCL impiden que existan valores inconsistentes deniveles en los tanques.

233: Los nodos cuentan con restricciones OCL que verifican que se encuen-tren conectados al menos a una tuberıa.

32 5.10. Manejo de Eventos

6Validacion

La validacion consiste en tomar una zona con la que se cuente simultanema-mente con un modelo de la red de acueducto y con uno de la red de alcantarillado.Se deben importar estos modelos desde sus archivos *.INP, realizar las valida-ciones independientes, construir el modelo conjunto con los reportes respectivosy llevar a cabo un analisis conjunto de los resultados. Para esto, se llevaron acabo 2 pruebas, una de ella con los datos calibrados de las redes de acueductoy alcantarillado de un sector del barrio Cedritos, en la ciudad de Bogota. Laotra, con datos preliminares de un sector de las redes de acueducto y alcantari-llado de la ciudad de Girardot, llamado Acacias. El objetivo de esta validacion escomprobar el correcto funcionamiento de la MTC, su velocidad, robustez, y losresultados de los analisis conjuntos, dependiendo del caso. Esto, ya que se sabede antemano la calidad de los datos de entrada, por lo que se esperan ciertosresultados desde antes de procesar la informacion conjunta.

6.1 Obtencion de los Datos de Entrada

A continuacion se explica el origen de los modelos que se usaron para lavalidacion.

6.1.1. Datos de Cedritos

El Centro de Investigaciones en Acueductos y Alcantarillados - CIACUA,cuenta con informacion detallada sobre la red de acueducto de la ciudad deBogota. Gracias a un modelo en EPANET que el CIACUA proporciono, ha sidoposible aislar el sector de la red de acueducto que se desea validar. La red deAcueducto Cedritos se muestra en la Figura 6.1. Esta red cuenta con 719 uniones,y 796 tuberıas, por lo que se trata de una red de tamano medio.

El ingeniero Daniel Rodrıguez, que trabaja actualmente en la Empresa deAcueducto y Alcantarillado de la ciudad de Bogota, nos ha proporcionado elmodelo en EPASWMM que contienen el sector de Cedritos que se desea validar.Este modelo se muestra en la Figura 6.2. Como se puede observar, la red cuentacon 209 pozos y 208 conductos, por lo que es de tamano medio.

33

34 6.1. Obtencion de los Datos de Entrada

Figura 6.1 Acueducto Cedritos vista desde Epanet.

Figura 6.2 Alcantarillado Cedritos vista desde Epaswmm.

6.1.2. Datos de Acacias

Tanto el modelo de acueducto en EPANET, como el modelo en EPASWMMhan sido encontrados dentro de los registros de la base de datos del CIACUA.Ya que se trata de versiones en etapa de investigacion, no se ha garantizadoque hayan sido calibradas con datos reales, ni que sean consistentes de formaconjunta. La Figura 6.3 y la Figura 6.4 muestran respectivamente los modelosde acueducto y alcantarillado de Acacias vistas desde Epanet y Epaswmm, segunel caso. Ambas redes son de tamanao muy pequeno. La de acueducto cuenta con13 uniones y 16 tuberıas, mientras que la de alcantarillado cuenta con 22 pozosy 21 conductos.

6.1.3. Resutados esperados

Basados en el origen y el estado de los datos de entrada, se espera que losmodelos de las redes de Cedritos sean consistentes. Del mismo modo, no se puedegarantizar que los modelos de las redes de Acacias tambien lo sean.

Validacion 35

Figura 6.3 Acueducto Acacias vista desde Epanet.

Figura 6.4 Alcantarillado Acacias vista desde Epaswmm.

36 6.2. Recuperacion de los datos de los reportes

6.2 Recuperacion de los datos de los reportes

Los datos fueron recuperados a traves de un procedimiento con el que cuen-ta Hydraulic Networks, mediante el cual es capaz de tomar la informacion quehace parte de los archivos *.INP de acueducto/alcantarillado y disponerlo en unarchivo de propiedades. Luego de esto, se lee este archivo de propiedades y seinstancia un modelo conforme con su respectivo metamodelo.

Se muestra una imagen con el modelo producido por el *.INP de Epanety Epaswmm para la zona Cedritos Bogota en la Figura 6.5. De igual forma semuestra una imagen con el modelo producido por el *.INP de Epanet y Epaswmmpara Acacias en la Figura 6.6.

Figura 6.5 Modelos de Cedritos conforme con los metamodelos Epanet y Epaswmm.

Estos modelos son usados como base para anadir la informacion adicionalque se generara en las ejecuciones independientes de EPANET y EPASWMM.De esta manera, se obtienen, finalmente, modelos con la informacion de salidade los reportes generados por las herramientas de calculo hidraulico.

Figura 6.6 Modelos de Acacias conforme con los metamodelos Epanet y Epaswmm.

Validacion 37

Figura 6.7 Acueducto Cedritos vista desde Epanet.

6.3 Agregacion de los datos en el Modelo Conjunto

Luego de tener los modelos separados de acueducto y alcantarillado, se pro-cede a realizar la transformacion Modelo a Modelo, haciendo uso de ATL. Elresultado es un modelo conjunto para cada uno de los casos de estudio, que sepueden ver en la Figura 6.7

Estos modelos pueden ser visualizados a traves del editor grafico definido conSirius. En la Figura 6.8 se muestra el modelo Conjunto de Cedritos. En la Figura6.9 se muestra el modelo Conjunto de Acacias.

Es importante destacar una de las principales limitaciones del editor grafi-co con respecto a la visualizacion de las redes de agua urbana, pues se tratadel posicionamiento espacial de los nodos en el plano. Sirius no permite definirlas coordenadas espaciales de los nodos, sino que los ubica de manera prede-terminada, favoreciendo el ordenamiento en forma de arbol. Ası, las redes dealcantarillado se visualizan de forma ordenada, mientas que las redes de acue-ducto se visualizan completamente dispersas en el diagrama. En ambos casos,los nodos de las redes no ocupan la posicion esperada en el diagrama.

38 6.3. Agregacion de los datos en el Modelo Conjunto

Figura 6.8 Cedritos desde el editor de HydraulicNetworks.

Figura 6.9 Acacias desde el editor de HydraulicNetworks.

Validacion 39

Figura 6.10 Acacias sin alteraciones.

6.4 Visualizacion de Alertas en el Editor Grafico

A modo de ejemplo, se muestra una pequena seccion del modelo de Acaciasen la Figura 6.10. Esta seccion es alterada, con el objetivo de observar la formacomo responde el editor a las inconsistencias propias del modelo:

1. Se observa en la Figura 6.11 que Sirius permite que el Editor de HydraulicNetworks de un aviso cuando hay nodos desconectados tanto en redes deacueducto como de alcantarillado.

2. En la Figura 6.12 se aprecia que el Editor es capaz de reconocer cuandohay mas de un Nodo o Linea con el mismo nombre.

3. Por ultimo, en la Figura 6.13 se observa que el Editor puede dar avisos dealerta cuando las uniones de acueducto presentan presiones negativas.

Esto es solo una pequena muestra de la forma en la que se manifiestan lasrestricciones OCL en el Editor Grafico del Lenguaje HYdraulic Networks.

40 6.4. Visualizacion de Alertas en el Editor Grafico

Figura 6.11 Acacias con nodos desconectados.

Figura 6.12 Acacias con nombres repetidos.

Validacion 41

Figura 6.13 Acacias con presiones negativas.

6.5 Validacion Conjunta de los Modelos

La validacion conjunta se realiza sobre el modelo conjunto de cada una delas redes. El resultado arrojado para el analisis conjunto espacial de la red deCedritos es que no hay inconsistencias espaciales entre las redes. Sin embargo,para el modelo de Acacias, el resultado arrojado se muestra en la Figura 6.14evidenciando que los modelos de acueducto y alcantarillado no son consistentes

Este tipo de analisis es difıcil de hacer sin tener una herramienta que permitamanejar los datos de las redes de la forma como lo permite EMF.

Figura 6.14 Excepcion arrojada por Hydraulic Networks en el analisis conjunto delmodelo Acacias.

42 6.5. Validacion Conjunta de los Modelos

7Conclusiones y Trabajo Futuro

Terminado el proyecto, la respuesta a la primer pregunta: ¿Es posible cons-truir un modelo que pueda contener de forma conjunta los elementos quehacne parte de las redes de acueducto y alcantarillado? es sı. El manejoadecuado de las transformaciones de modelos permite que los elementoscompartidos entre ambas redes puedan ser separados en modelos indepen-dientes de acueductos y de alcantarillados. El uso de trazas permite quela informacion de estas transformaciones pueda ser usada para reconstruirel modelo original y ası tener retroalimentacion de datos. La inclusion deun editor grafico permite la construccion del modelo conjunto con sus res-pectivos datos de entrada. De esta manera, la herramienta le permite alusuario construir, validar y analizar conjuntamente redes de acueducto yalcantarillado.

La base central de Hydraulic Networks son los algoritmos de analisis con-junto de los datos que lleguan de las transformaciones al modelo conjunto.Esta es una posibilidad que el ingeniero hidraulico no habia tenido hasta elmomento, y la cual facilita el ejercicio de su labor, ya que permite generarnueva informacion a partir de la interaccion entre los modelos separadosde las redes de acueducto y alcantarillado.

Hydraulic Networks, al ser una herramienta que abstrae los elementos queconforman las redes de agua urbana, puede ser usada como lenguaje de unamanera sencilla por ingenieros hidraulicos. Los usuarios que han usado eleditor han manifestado su conformidad con su forma de uso, y su utilidaden cuanto al analisis que permite.

Hydraulic Networks, al estar construido a traves de los principios de Inge-nierıa de Modelos, puede seguir creciendo, al tener la posibilidad de llevarla informacion de las redes a otras herramientas de calculo hidraulico comoWaterCAD, SewerCAD, Mouse e incluso sistemas de informacion geografi-ca como ArcGIS.

El proyecto de desarrollo de la herramienta Hydraulic Networks puede se-guir avanzando en varios aspectos. Es importante que la herramienta cuente

43

44

con una interfaz grafica que permita realizar todos los procedimientos detransformacion de forma encadenada.

Bibliografıa

[1] M. Biehl. Literature Study on Model Transformations. URL:http://staffwww.dcs.shef.ac.uk/people/A.Simons/remodel/papers/ Biehl-ModelTransformations.pdf, 2010. Article of Royal Institute of Technology.

[2] R. Casallas. Model driven engineering. Bogota: Grupo de Construccion deSoftware Uniandes, 2012.

[3] T. Datwyler. Hydraulic modeling: Pipe network analysis. URL: http://digitalcommons.usu.edu/cgi/viewcontent.cgiarticle1220contextgrad-reports, January 2012.

[4] Environmental Proteccion Agency. EPANET. URL: http://www.epa.gov/nrmrl/wswrd/dw/epanet.html, 2013.

[5] Environmental Proteccion Agency. EPASWMM. URL:http://www.epa.gov/ nrmrl/wswrd/wq/models/swmm/, 2013.

[6] E. Foundation. ATL Atlas Transformation Language. URL: http://www.eclipse.org/atl/, 2013.

[7] E. Foundation. Eclipse modeling framework project (emf). URL:http://www.eclipse.org/modeling/emf/, 2013.

[8] E. Foundation. Sirius. URL: http://www.eclipse.org/sirius/overview.html,2014.

[9] T. Kuhne. What is a Model? URL: http://homepages.mcs.vuw.ac.nz/tk/publications/papers/what-is-a-model-dagstuhl.pdf, 2005. Article ofDarmstadt University of Technology.

[10] McKinney. Linking gis and water resources mana-gement models: an object-oriented method. URL:http://www.ce.utexas.edu/prof/mckinney/papers/aral/gis-water.pdf,2001.

[11] Obeo. Acceleo. URL: http://www.acceleo.org/pages/home/en, 2013.

[12] H. Tamasauskas, L. Larsen, and O. Mark. Using gis in water supply andsewer modelling and management. 2011.

45

46 Bibliografıa

8Anexos

8.1 Metamodelo Conjunto Hydraulic Networks

A continuacion se muestra el codigo del metamodelo en Ecore usado paradefinir Hydraulic Networks, visualizado usando la vista ’OCLinEcore’:

1 import ecore : ’ http ://www. e c l i p s e . org /emf/2002/ Ecore#/ ’ ;23 package Networks : Networks = ’ http :// networks ’4 {5 class Red6 {7 annotation ’ gmf . diagram ’8 (9 foo = ’ bar ’ ,

10 ’model . ex tens ion ’ = ’ xmi ’11 ) ;12 attribute nombre : String ;13 property nodos : Nodo [ ∗ ] { ordered composes } ;14 property l i n e a s : Linea [ ∗ ] { ordered composes } ;15 attribute de s c r i p c i on : String [ ? ] ;16 property subcuencas : Subcuenca [ ∗ ] { ordered composes } ;17 property curvas : Curva [ ∗ ] { ordered composes } ;18 attribute estadoAcueducto : String [ ? ] ;19 attribute e s t adoA l can ta r i l l ado : String [ ? ] ;20 invariant ExcepcionEpanet : estadoAcueducto=’ ’ ;21 invariant ExcepcionEpaswmm : e s t adoA l can ta r i l l ado=’ ’ ;22 }23 abstract class Nodo24 {25 attribute nombre : String ;26 attribute coordX : ecore : : EDouble [ ? ] ;27 attribute coordY : ecore : : EDouble [ ? ] ;28 attribute cabezaActual : e core : : EDouble [ ? ] ;29 property red : Red ;30 attribute pres ionActua l : e core : : EDouble [ ? ] ;31 attribute ca l idadActua l : e core : : EDouble [ ? ] ;32 attribute cota : ecore : : EDouble [ ? ] ;33 invariant NodoConectado :34 red . l i n ea s−>c o l l e c t ( l : Linea | ( l . s a l i d a = s e l f ))−>count ( true ) > 0 or35 red . l i n ea s−>c o l l e c t ( l : Linea | ( l . entrada = s e l f ))−>count ( true ) > 0 ;36 invariant IDRepetido :37 red . nodos−>c o l l e c t (n : Nodo | n . nombre = s e l f . nombre)−>count ( true ) = 1 ;38 }39 class Tuberia extends Linea40 {41 annotation ’ gmf . l i n k ’42 (43 source = ’ s a l i d a ’ ,44 ta rg e t = ’ entrada ’ ,45 incoming = ’ f a l s e ’ ,46 ’ l a b e l . t ext ’ = ’ ’ ,47 width = ’ 5 ’ ,48 c o l o r = ’ 170 ,170 ,140 ’49 ) ;50 attribute l ong i tud : ecore : : EDouble [ ? ] ;51 attribute diametro : ecore : : EDouble [ ? ] ;52 attribute rugos idad : ecore : : EDouble [ ? ] ;53 attribute pendiente : ecore : : EDouble [ ? ] ;

47

48 8.1. Metamodelo Conjunto Hydraulic Networks

54 attribute perdidaMenor : ecore : : EDouble [ ? ] ;55 attribute e s t a d o I n i c i a l : EstadoTuberia [ ? ] ;56 attribute perdUnitar iaActua l : e core : : EDouble [ ? ] ;57 attribute fActua l : e core : : EDouble [ ? ] ;58 attribute veloc idadReacActual : e core : : EDouble [ ? ] ;59 attribute estadoActual : EstadoTuberia [ ? ] ;60 invariant tuber iaBienConectada : s a l i d a <> entrada ;61 invariant RedConsistente :62 i f s a l i d a . oclIsTypeOf (Camara) then entrada . oclIsTypeOf (Camara) else 0 = 0 endif ;63 }64 class Union extends Nodo65 {66 annotation ’ gmf . node ’67 (68 l a b e l = ’ nombre ’ ,69 f i g u r e = ’ e l l i p s e ’ ,70 c o l o r = ’ 0 ,0 ,128 ’ ,71 ’ l a b e l . placement ’ = ’ ex t e rna l ’ ,72 r e s i z a b l e = ’ f a l s e ’ ,73 s i z e = ’ 16 ,16 ’74 ) ;75 attribute demandaBase : ecore : : EDouble [ ? ] ;76 attribute demandaActual : e core : : EDouble [ ? ] ;77 property aporte : Tuberia [ ? ] ;78 }79 class Bomba extends Linea80 {81 annotation ’ gmf . node ’82 (83 l a b e l = ’ nombre ’ ,84 f i g u r e = ’ polygon ’ ,85 ’ polygon . x ’ = ’ 0 5 15 20 ’ ,86 ’ polygon . y ’ = ’ 5 0 0 5 ’ ,87 c o l o r = ’ 255 ,128 ,0 ’ ,88 s i z e = ’ 24 ,16 ’ ,89 ’ l a b e l . placement ’ = ’ ex t e rna l ’90 ) ;91 attribute pres ionActua l : e core : : EDouble [ ? ] ;92 property curvasBomba : Curva [ 1 . . 2 ] { ordered } ;93 property curvaBomba : Curva ;94 }95 class Valvula extends Linea96 {97 annotation ’ gmf . l i n k ’98 (99 ’ l a b e l . t ext ’ = ’X ’ ,

100 source = ’ s a l i d a ’ ,101 ta rg e t = ’ entrada ’ ,102 incoming = ’ f a l s e ’ ,103 c o l o r = ’ 98 ,98 ,98 ’ ,104 width = ’ 4 ’ ,105 s t y l e = ’ dot ’ ,106 ’ source . decora t i on ’ = ’ rhomb ’ ,107 ’ t a r g e t . decora t i on ’ = ’ rhomb ’108 ) ;109 attribute diametro : ecore : : EDouble [ ? ] ;110 attribute t ipo : TipoValvula [ ? ] ;111 attribute cons igna : ecore : : EDouble [ ? ] ;112 attribute coefDePerdidas : ecore : : EDouble [ ? ] ;113 attribute e s t a d o I n i c i a l : EstadoValvula [ ? ] ;114 attribute perdidaActual : e core : : EDouble [ ? ] ;115 attribute estadoActual : EstadoValvula [ ? ] ;116 invariant diametroPos i t ivo : diametro >= 0;117 }118 class Embalse extends Nodo119 {120 annotation ’ gmf . node ’121 (122 l a b e l = ’ nombre ’ ,123 f i g u r e = ’ r e c t ang l e ’ ,124 c o l o r = ’ 0 ,110 ,190 ’ ,125 s i z e = ’ 24 ,18 ’126 ) ;127 invariant cont i eneSa l idasEmbalse :128 red . l i n ea s−>c o l l e c t ( t : Linea | ( t . entrada = s e l f ))−>count ( true ) > 0 ;129 }130 class Tanque extends Nodo131 {132 annotation ’ gmf . node ’133 (134 l a b e l = ’ nombre ’ ,135 f i g u r e = ’ r e c t ang l e ’ ,136 c o l o r = ’ 128 ,128 ,128 ’ ,137 r e s i z a b l e = ’ f a l s e ’ ,138 s i z e = ’ 16 ,24 ’139 ) ;140 attribute n i v e l I n i c i a l : e core : : EDouble [ ? ] ;141 attribute nivelMinimo : ecore : : EDouble [ ? ] ;142 attribute nivelMaximo : ecore : : EDouble [ ? ] ;143 attribute diametro : ecore : : EDouble [ ? ] ;144 attribute mezcla : ModeloMezcla [ ? ] ;145 attribute QnetoEntrante : ecore : : EDouble [ ? ] ;146 invariant l im i t e sA l tu r a : nivelMaximo < 100 and nivelMinimo >= 0;147 invariant cont ieneSal idasTanque :148 red . l i n ea s−>c o l l e c t ( t : Linea | ( t . entrada = s e l f ))−>count ( true ) > 0 ;149 invariant diametroPos i t ivo : diametro >= 0;

Anexos 49

150 invariant l im i t e I n i c i a l A l t u r a :151 n i v e l I n i c i a l <= nivelMaximo and nivelMinimo <= n i v e l I n i c i a l ;152 }153 class Camara extends Nodo154 {155 annotation ’ gmf . node ’156 (157 l a b e l = ’ nombre ’ ,158 f i g u r e = ’ e l l i p s e ’ ,159 c o l o r = ’ 128 ,0 ,0 ’ ,160 ’ l a b e l . placement ’ = ’ ex t e rna l ’ ,161 r e s i z a b l e = ’ f a l s e ’ ,162 s i z e = ’ 16 ,16 ’163 ) ;164 attribute a l t u r a I n i c i a l : e core : : EDouble [ ? ] ;165 attribute descarga : Boolean [ ? ] ;166 attribute profundidadMaxima : ecore : : EDouble [ ? ] ;167 attribute profundidadMinima : ecore : : EDouble [ ? ] ;168 }169 class Limite170 {171 attribute nombre : String [ ? ] ;172 property entrada : CoordenadaSimple ;173 property s a l i d a : CoordenadaSimple ;174 invariant l imiteBienConectado : s a l i d a <> entrada ;175 }176 class Subcuenca177 {178 annotation ’ gmf . diagram ’179 (180 foo = ’ bar ’181 ) ;182 annotation ’ gmf . node ’183 (184 l a b e l = ’ nombre ’ ,185 f i g u r e = ’ r e c t ang l e ’ ,186 ’ border . width ’ = ’ 3 ’ ,187 ’ border . c o l o r ’ = ’ 55 ,85 ,45 ’ ,188 ’ border . s t y l e ’ = ’ dash ’ ,189 ’ l a b e l . placement ’ = ’ ex t e rna l ’ ,190 r e s i z a b l e = ’ f a l s e ’ ,191 s i z e = ’ 32 ,32 ’192 ) ;193 attribute area : ecore : : EDouble [ ? ] ;194 attribute pendienteMedia : ecore : : EDouble [ ? ] ;195 attribute porcentajeImpermeable : e core : : EDouble [ ? ] ;196 property l im i t e s : Limite [ ∗ ] { ordered composes } ;197 property coordenadas : CoordenadaSimple [ ∗ ] { ordered composes } ;198 attribute nombre : String [ ? ] ;199 property hidrograma : Hidrograma { composes } ;200 property aporte : Camara ;201 attribute ancho : ecore : : EDouble [ ? ] ;202 }203 class CoordenadaSimple204 {205 attribute nombre : String ;206 attribute coordX : ecore : : EDouble [ ? ] ;207 attribute coordY : ecore : : EDouble [ ? ] ;208 }209 class Hidrograma210 {211 annotation ’ gmf . diagram ’212 (213 foo = ’ bar ’214 ) ;215 annotation ’ gmf . node ’216 (217 l a b e l = ’ nombre ’ ,218 f i g u r e = ’ r e c t ang l e ’ ,219 c o l o r = ’ 0 ,110 ,190 ’ ,220 ’ l a b e l . placement ’ = ’ ex t e rna l ’ ,221 r e s i z a b l e = ’ f a l s e ’ ,222 s i z e = ’ 16 ,16 ’223 ) ;224 attribute nombre : String [ ? ] ;225 property i n t e r v a l o s : I n t e rva l oL luv i a [+] { ordered composes } ;226 attribute t ipoDato : String [ ? ] ;227 attribute f recuenciaMinima : String [ ? ] ;228 }229 class I n t e r va l oL luv i a230 {231 annotation ’ gmf . node ’232 (233 l a b e l = ’minuto ’ ,234 f i g u r e = ’ r e c t ang l e ’ ,235 c o l o r = ’ 0 ,110 ,190 ’ ,236 ’ l a b e l . placement ’ = ’ ex t e rna l ’ ,237 r e s i z a b l e = ’ f a l s e ’ ,238 s i z e = ’ 16 ,16 ’239 ) ;240 attribute minuto : String [ ? ] ;241 attribute va lo r : ecore : : EDouble [ ? ] ;242 }243 abstract class Linea244 {245 attribute nombre : String ;

50 8.2. Metamodelo Acueductos Epanet

246 property entrada : Nodo ;247 property s a l i d a : Nodo ;248 property red : Red ;249 attribute caudalActual : e core : : EDouble [ ? ] ;250 attribute ve loc idadActua l : e core : : EDouble [ ? ] ;251 attribute ca l idadActua l : e core : : EDouble [ ? ] ;252 invariant IDRepetido :253 red . l i n ea s−>c o l l e c t ( l : Linea | l . nombre = s e l f . nombre)−>count ( true ) = 1 ;254 }255 enum EstadoTuberia { ser ia l i zab le }256 {257 l i t e r a l Open ;258 l i t e r a l Closed = 1 ;259 l i t e r a l CV = 2 ;260 }261 enum TipoValvula { ser ia l i zab le }262 {263 l i t e r a l PRV;264 l i t e r a l PSV = 1 ;265 l i t e r a l PBV = 2 ;266 l i t e r a l FCV = 3 ;267 l i t e r a l TCV = 4 ;268 l i t e r a l GPV = 5 ;269 }270 class PuntoCurva271 {272 attribute x : ecore : : EDouble [ ? ] ;273 attribute y : ecore : : EDouble [ ? ] ;274 }275 class Curva276 {277 attribute t ipo : TipoCurva [ ? ] ;278 attribute nombre : String [ ? ] ;279 property puntos : PuntoCurva [+] { ordered composes } ;280 }281 enum TipoCurva { ser ia l i zab le }282 {283 l i t e r a l VOLUME;284 l i t e r a l PUMP = 1 ;285 l i t e r a l EFFICICENCY = 2 ;286 l i t e r a l HEADLOSS = 3 ;287 }288 enum ModeloMezcla { ser ia l i zab le }289 {290 l i t e r a l Mixed ;291 l i t e r a l TwoComp = 1 ;292 l i t e r a l FIFO = 2 ;293 l i t e r a l LIFO = 3 ;294 }295 enum EstadoValvula { ser ia l i zab le }296 {297 l i t e r a l None ;298 l i t e r a l Open = 1 ;299 l i t e r a l Closed = 2 ;300 }301 }

8.2 Metamodelo Acueductos Epanet

A continuacion se muestra el codigo del metamodelo en Ecore usado para de-finir el lenguaje Epanet (acueductos), visualizado usando la vista ’OCLinEcore’:

1 import ecore : ’ http ://www. e c l i p s e . org /emf/2002/ Ecore#/ ’ ;23 package epanet : epanet = ’ http :// epanet /1 .0 ’4 {5 class Junct ion extends Node6 {7 attribute baseDemand : ecore : : EDouble [ ? ] ;8 attribute e l e v a t i on : ecore : : EDouble [ ? ] ;9 property pat te rns : Pattern [ ? ] ;

10 property emi t t e r s : Emitter [ ? ] ;11 property demands : Demand [ ? ] ;12 attribute currentDemand : ecore : : EDouble [ ? ] ;13 }14 class Reservo i r extends Node15 {16 property pat te rns : Pattern [ ? ] ;17 }18 class Tank extends Node19 {20 attribute diameter : e core : : EDouble [ ? ] ;21 attribute e l e v a t i on : ecore : : EDouble [ ? ] ;22 attribute i n i t l e v e l : e core : : EDouble [ ? ] ;23 attribute maxlevel : e core : : EDouble [ ? ] ;24 attribute min leve l : e core : : EDouble [ ? ] ;25 attribute cu r r en t In f l ow : ecore : : EDouble [ ? ] ;26 attribute mixing : MixingModel [ ? ] ;27 }

Anexos 51

28 class Pipe extends Link29 {30 attribute diameter : e core : : EDouble [ ? ] ;31 attribute l ength : ecore : : EDouble [ ? ] ;32 attribute minor lo s s : e core : : EDouble [ ? ] ;33 attribute roughness : e core : : EDouble [ ? ] ;34 attribute i n i t S t a t u s : PipeStatus [ ? ] ;35 attribute cur rentSta tus : PipeStatus [ ? ] ;36 attribute currentUnitLoss : e core : : EDouble [ ? ] ;37 attribute currentF : ecore : : EDouble [ ? ] ;38 attribute cur rentReactVe loc i ty : ecore : : EDouble [ ? ] ;39 }40 class Pump extends Link41 {42 attribute cur r entPre s su re : ecore : : EDouble [ ? ] ;43 property pumpCurve : Curve [ ? ] ;44 property e f fCurve : Curve [ ? ] ;45 }46 class Valve extends Link47 {48 attribute diameter : e core : : EDouble [ ? ] ;49 attribute type : ValveType [ ? ] ;50 attribute s e t t i n g : ecore : : EDouble [ ? ] ;51 attribute minor lo s s : e core : : EDouble [ ? ] ;52 attribute i n i t S t a t u s : ValveStatus [ ? ] ;53 attribute currentLooses : e core : : EDouble [ ? ] ;54 attribute cur rentSta tus : ValveStatus [ ? ] ;55 }56 class Demand57 {58 attribute category : String [ ? ] ;59 attribute demand : String [ ? ] ;60 property has : Pattern ;61 }62 class Status63 {64 attribute id : String [ ? ] ;65 attribute s t a tu sS e t t i n g : String [ ? ] ;66 }67 class Pattern68 {69 attribute id : String [ ? ] ;70 attribute mu l t i p l i e r s : String [ ? ] ;71 }72 class Curve73 {74 attribute name : String [ ? ] ;75 attribute xValue : ecore : : EDouble [ ? ] ;76 attribute yValue : ecore : : EDouble [ ? ] ;77 attribute type : CurveType [ ? ] ;78 }79 class Emitter80 {81 attribute c o e f f i c i e n t : e core : : EDouble [ ? ] ;82 }83 class Qual ity extends Node84 {85 attribute i n i t q u a l : String [ ? ] ;86 attribute node : String [ ? ] ;87 }88 class Source extends Node89 {90 attribute qua l i t y : String [ ? ] ;91 attribute type : String [ ? ] ;92 property has : Pattern ;93 }94 class Reaction95 {96 attribute pipeTank : String [ ? ] ;97 attribute c o e f f i c i e n t : String [ ? ] ;98 attribute type : String [ ? ] ;99 }

100 abstract class Node101 {102 attribute name : String [ ? ] ;103 attribute yCoord : ecore : : EDouble [ ? ] ;104 attribute xCoord : ecore : : EDouble [ ? ] ;105 attribute currentHead : ecore : : EDouble [ ? ] ;106 attribute cur r entPre s su re : ecore : : EDouble [ ? ] ;107 attribute cur rentQua l i ty : ecore : : EDouble [ ? ] ;108 property network : Network ;109 }110 class Vert i c e111 {112 attribute l i n k : String [ ? ] ;113 attribute xCoord : ecore : : EDouble [ ? ] ;114 attribute yCoord : ecore : : EDouble [ ? ] ;115 }116 class Label117 {118 attribute xCoord : ecore : : EDouble [ ? ] ;119 attribute yCoord : ecore : : EDouble [ ? ] ;120 attribute t ext : String [ ? ] ;121 }122 class Network123 {

52 8.3. Metamodelo Alcantarillados Epaswmm

124 property curves : Curve [ ∗ ] { ordered composes } ;125 property r e a c t i o n s : Reaction [ ∗ ] { ordered composes } ;126 property s t a tu s : Status [ ∗ ] { ordered composes } ;127 property l i n k s : Link [ ∗ ] { ordered composes } ;128 property v e r t i c e s : Ver t i c e [ ∗ ] { ordered composes } ;129 property l a b e l s : Label [ ∗ ] { ordered composes } ;130 attribute name : String [ ? ] ;131 property nodes : Node [ ∗ ] { ordered composes } ;132 attribute de s c r i p t i o n : String [ ? ] ;133 attribute s t a t e : String [ ? ] ;134 }135 abstract class Link136 {137 attribute name : String [ ? ] ;138 property input : Node ;139 property output : Node ;140 attribute currentFlow : ecore : : EDouble [ ? ] ;141 attribute cu r r en tVe l o c i t y : ecore : : EDouble [ ? ] ;142 attribute cur rentQua l i ty : ecore : : EDouble [ ? ] ;143 property network : Network ;144 }145 enum ValveType { ser ia l i zab le }146 {147 l i t e r a l PRV;148 l i t e r a l PSV = 1 ;149 l i t e r a l PBV = 2 ;150 l i t e r a l FCV = 3 ;151 l i t e r a l TCV = 4 ;152 l i t e r a l GPV = 5 ;153 }154 enum MixingModel { ser ia l i zab le }155 {156 l i t e r a l Mixed ;157 l i t e r a l TwoComp = 1 ;158 l i t e r a l FIFO = 2 ;159 l i t e r a l LIFO = 3 ;160 }161 enum ValveStatus { ser ia l i zab le }162 {163 l i t e r a l None ;164 l i t e r a l Open = 1 ;165 l i t e r a l Closed = 2 ;166 }167 enum PipeStatus { ser ia l i zab le }168 {169 l i t e r a l Open ;170 l i t e r a l Closed = 1 ;171 l i t e r a l CV = 2 ;172 l i t e r a l EEnumLiteral0 = 3 ;173 }174 enum CurveType { ser ia l i zab le }175 {176 l i t e r a l VOLUME;177 l i t e r a l PUMP = 1 ;178 l i t e r a l EFFICICENCY = 2 ;179 l i t e r a l HEADLOSS = 3 ;180 }181 }

8.3 Metamodelo Alcantarillados Epaswmm

A continuacion se muestra el codigo del metamodelo en Ecore usado pa-ra definir el lenguaje Epaswmm (alcantarillados), visualizado usando la vista’OCLinEcore’:

1 import ecore : ’ http ://www. e c l i p s e . org /emf/2002/ Ecore#/ ’ ;23 package epaswmm : epaswmm = ’ http ://epaswmm/1.0 ’4 {5 class Raingage6 {7 attribute rainType : String [ ? ] ;8 attribute recdFreq : String [ ? ] ;9 attribute snowCatch : String [ ? ] ;

10 attribute dataSource : String [ ? ] ;11 property t imeSe r i e s : TimeSeries { composes } ;12 attribute name : String [ ? ] ;13 }14 class Subcatchment15 {16 attribute name : String [ ? ] ;17 attribute tota lArea : String [ ? ] ;18 attribute s lopePcnt : String [ ? ] ;19 attribute curbLength : String [ ? ] ;20 attribute snowPack : String [ ? ] ;21 attribute impervPcnt : String [ ? ] ;22 attribute width : String [ ? ] ;23 property ra ingage : Raingage { composes } ;

Anexos 53

24 property ou t l e t : Manhole ;25 property i n f i l t r a t i o n : I n f i l t r a t i o n { composes } ;26 property coo rd ina t e s : Node [ 3 . . ∗ ] { ordered composes } ;27 property subarea : Subarea { composes } ;28 }29 class Subarea30 {31 attribute nImperv : String [ ? ] ;32 attribute nPerv : String [ ? ] ;33 attribute sImperv : String [ ? ] ;34 attribute sPerv : String [ ? ] ;35 attribute zeroPcnt : String [ ? ] ;36 attribute routeTo : String [ ? ] ;37 attribute pctRouted : String [ ? ] ;38 }39 class I n f i l t r a t i o n40 {41 attribute maxRate : String [ ? ] ;42 attribute minRate : String [ ? ] ;43 attribute decay : String [ ? ] ;44 attribute dryTime : String [ ? ] ;45 attribute maxIn f i l : String [ ? ] ;46 }47 class Manhole extends Node48 {49 attribute e l e v a t i on : ecore : : EDouble [ ? ] ;50 attribute maxDepth : ecore : : EDouble [ ? ] ;51 attribute in i tDepth : ecore : : EDouble [ ? ] ;52 attribute surchargeDepth : ecore : : EDouble [ ? ] ;53 attribute pondedArea : ecore : : EDouble [ ? ] ;54 attribute currentDepth : ecore : : EDouble [ ? ] ;55 property DryWF : DryWaterFlow [ ? ] { composes } ;56 property i n f l ows : In f low [ ? ] { composes } ;57 }58 class Out fa l l extends Node59 {60 attribute e l e v a t i on : ecore : : EDouble [ ? ] ;61 attribute out fa l lType : String [ ? ] ;62 attribute t ideGate : String [ ? ] ;63 }64 class Conduit65 {66 attribute name : String [ ? ] ;67 attribute l ength : String [ ? ] ;68 attribute manning : String [ ? ] ;69 attribute in i tF low : String [ ? ] ;70 property xSect ion : Xsect ion { composes } ;71 property i n l e t : Node ;72 property ou t l e t : Node ;73 attribute i n l e tO f f s e t : String [ ? ] ;74 attribute ou t l e tO f f s e t : String [ ? ] ;75 attribute maxFlow : String [ ? ] ;76 }77 class Xsect ion78 {79 attribute type : String [ ? ] ;80 attribute ba r r e l s : String [ ? ] ;81 attribute geom1 : String [ ? ] ;82 attribute geom2 : String [ ? ] ;83 attribute geom3 : String [ ? ] ;84 attribute geom4 : String [ ? ] ;85 }86 class Node87 {88 attribute name : String [ ? ] ;89 attribute xCoord : ecore : : EDouble [ ? ] ;90 attribute yCoord : ecore : : EDouble [ ? ] ;91 property sewer : Sewer ;92 }93 class Sewer94 {95 attribute name : String [ ? ] ;96 attribute de s c r i p t i o n : String [ ? ] ;97 property nodes : Node [ ∗ ] { ordered composes } ;98 property subcatchments : Subcatchment [ ∗ ] { ordered composes } ;99 property condui t s : Conduit [ ∗ ] { ordered composes } ;

100 attribute s t a t e : String [ ? ] ;101 property pat te rns : Pattern [ ∗ ] { ordered composes } ;102 }103 class TimeSer ies104 {105 property r e co rds : Time [+] { ordered composes } ;106 attribute name : String [ ? ] ;107 }108 class Time109 {110 attribute minute : String [ ? ] ;111 attribute value : String [ ? ] ;112 }113 class DryWaterFlow114 {115 attribute parameter : String ;116 attribute baseDWF : ecore : : EDouble ;117 property pattern : Pattern [ ? ] ;118 }119 class In f low

54 8.3. Metamodelo Alcantarillados Epaswmm

120 {121 attribute i n f l ow : String ;122 attribute type : String ;123 attribute fUn i t s : e core : : EDouble [ ? ] ;124 attribute f S c a l e : e core : : EDouble [ ? ] ;125 attribute ba s e l i n e : ecore : : EDouble [ ? ] ;126 property pattern : Pattern [ ? ] ;127 }128 class Pattern129 {130 attribute name : String [ ? ] ;131 attribute type : String [ ? ] ;132 property mu l t i p l i e r s : Mu l t i p l i e r [+] { ordered composes } ;133 }134 class Mul t i p l i e r135 {136 attribute value : ecore : : EDouble [ ? ] ;137 }138 }

Utilizacion de MDE para resolver el problema´ de ...

Documents

Transcript of Utilizacion de MDE para resolver el problema´ de ...