Embed Size (px)
Citation preview
MODELO DE ARQUITECTURA DE MIDDLEWARE PARA UN SISTEMA DE TRANSPORTE PÚBLICO DE PASAJEROS EN CIUDADES BASADO EN SMART CITY
Ricardo Alfonso Gómez Suárez
CODIGO: 20141195001
PROYECTO DE TESIS PARA OPTAR POR EL TÍTULO DE MAGISTER EN CIENCIAS DE LA INFORMACIÓN Y LAS COMUNICACIONES
Director de Tesis
PhD. Roberto Ferro Escobar
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
MAESTRÍA EN CIENCIAS DE LA INFORMACIÓN Y LAS COMUNICACIONES
ÉNFASIS EN TELEINFORMÁTICA
BOGOTÁ, COLOMBIA
JULIO DE 2016
FACULTAD DE INGENIERÍA
MAESTRÍA EN CIENCIAS DE LA INFORMACIÓN Y LAS COMUNICACIONES
PRESENTACIÓN PROYECTO
2
Contenido
INTRODUCCIÓN, FORMULACIÓN DEL PROBLEMA Y OBJETIVOS ................................................................... 1
1.1 RESUMEN .................................................................................................................................................... 1 1.2 INTRODUCCIÓN ............................................................................................................................................. 1 1.3 PREGUNTA DE INVESTIGACIÓN ......................................................................................................................... 4 1.4 HIPÓTESIS .................................................................................................................................................... 4 1.5 OBJETIVOS ................................................................................................................................................... 5
MARCO TEÓRICO Y ESTADO DEL ARTE ......................................................................................................... 6
2.1 MARCO TEÓRICO .......................................................................................................................................... 6 2.1.1 Smart City y Smart Mobility .............................................................................................................. 6 2.1.2 Wireless Sensor Networks (WSN) y Global Positioning Systems (GPS) ........................................... 10 2.1.3 Middleware ..................................................................................................................................... 15
2.2 ESTADO DEL ARTE ....................................................................................................................................... 21 2.2.1 Smart City y Smart Mobility ............................................................................................................ 21 2.2.2 Middleware ..................................................................................................................................... 26
METODOLOGÍA Y DISEÑO DEL MODELO DE ARQUITECTURA DE MIDDLEWARE PROPUESTO ..................... 32
3.1 METODOLOGÍA ........................................................................................................................................... 32 3.2 CONSIDERACIONES DEL MODELO .................................................................................................................... 32
3.2.1 Heterogeneidad de dispositivos ...................................................................................................... 32 3.2.2 Interoperabilidad ............................................................................................................................ 32 3.2.3 Escalabilidad ................................................................................................................................... 34 3.2.4 Modularidad de programación ....................................................................................................... 34 3.2.5 Transparencia ................................................................................................................................. 34 3.2.6 Formalización del entorno .............................................................................................................. 35
3.3 DISEÑO DEL MODELO DE MIDDLEWARE ........................................................................................................... 35 3.3.1 Diagramas de Casos de Uso ............................................................................................................ 36 3.3.2 Diagramas de Actividades .............................................................................................................. 38 3.3.3 Diagramas de Secuencia ................................................................................................................. 41
3.3 MODELO DE MIDDLEWARE PROPUESTO .......................................................................................................... 44
SIMULACIÓN DEL MODELO Y RESULTADOS ............................................................................................... 47
4.1 ESCENARIOS DE VALIDACIÓN ......................................................................................................................... 47 4.1.1 Escenario 1 ...................................................................................................................................... 47 4.1.2 Escenario 2 ...................................................................................................................................... 48 4.1.3 Escenario 3 ...................................................................................................................................... 49
4.2 HERRAMIENTAS UTILIZADAS .......................................................................................................................... 50 4.2.1 Hardware ........................................................................................................................................ 50 4.2.1 Software .......................................................................................................................................... 50
4.3 INDICADORES O PARÁMETROS DE EVALUACIÓN .................................................................................................. 52 4.3.1 Latencia........................................................................................................................................... 52 4.3.2 Escalabilidad ................................................................................................................................... 52 4.3.3 Pertinencia de los indicadores evaluados ....................................................................................... 53
4.4 RESULTADOS .............................................................................................................................................. 54
EVALUACIÓN DEL DESEMPEÑO .................................................................................................................. 58
5.1 EVALUACIÓN CUALITATIVA ............................................................................................................................ 58
3
5.2 EVALUACIÓN CUANTITATIVA .......................................................................................................................... 59
CONCLUSIONES Y TRABAJO FUTURO ......................................................................................................... 61
REFERENCIAS BIBLIOGRÁFICAS ..................................................................................................... 64
4
Lista de Figuras
Figura 1. Población mundial periodo 1960 – 2030 ........................................................................... 2
Figura 2. Consumo energético por sector y fuente en 2010 (ktep). .................................................. 3
Figura 3. Cadena de valor de Smart City. ......................................................................................... 10
Figura 4. Esquema de la intersección de las señales de 4 satélites para la determinación de la
posición de un objeto en tierra. ....................................................................................................... 15
Figura 5. Middleware omnipresente. ............................................................................................... 17
Figura 6. Clasificación de Middleware. ............................................................................................ 18
Figura 7. Arquitectura de Middleware para WSN. .......................................................................... 20
Figura 8. Ciudades de la Unión Europea incluidas en la iniciativa CIVITAS. ................................... 23
Figura 9. Principales iniciativas de Smart City en el mundo. ........................................................... 23
Figura 10. Middleware de plataforma. ............................................................................................ 29
Figura 11. Diagrama de Actividades del proyecto. .......................................................................... 33
Figura 12. Diagrama general del sistema. ........................................................................................ 36
Figura 13. Diagrama de Casos de Uso General ................................................................................ 37
Figura 14. Diagrama de Casos de Uso del módulo cliente .............................................................. 38
Figura 15. Diagrama de Actividades para cargar Datos en el sistema desde los Sensores. ........... 39
Figura 16. Diagrama de Actividades para Extracción de Datos por parte de las aplicaciones. ...... 40
Figura 17. Diagrama de Secuencia para cargar, codificar y formatear Datos en el sistema desde
los Sensores. ..................................................................................................................................... 41
Figura 18. Diagrama de Secuencia para petición de Datos Antigüos del sistema desde las
Aplicaciones. ..................................................................................................................................... 42
Figura 19. Diagrama de Secuencia para solicitud de estadísticas del sistema desde las
Aplicaciones. ..................................................................................................................................... 43
Figura 20. Diagrama de Secuencia para solicitud y obtención de información de auditoría por
parte del Auditor. ............................................................................................................................. 44
Figura 21. Diagrama jerárquico del Middleware propuesto. .......................................................... 45
Figura 22. Estructura y mapa de flujo de datos para el Middleware propuesto. ........................... 46
Figura 23. Escenario de validación 1 en OPNET Modeler versión académica. ............................... 48
Figura 24. Escenario de validación 2 en OPNET Modeler versión académica. ............................... 49
Figura 25. Escenario de validación 3 en OPNET Modeler versión académica. ............................... 50
Figura 26. “Acuerdo de Uso Restringido” para el simulador OPNET versión académica. .............. 51
Figura 27. Tiempo promedio procesamiento de paquetes para el escenario 2 planteado. .......... 55
Figura 28. Tiempo promedio procesamiento de paquetes para el escenario 3 planteado. ......... 55
Figura 29. Porcentaje de utilización de la CPU para los escenarios 2 y 3 planteados. ................... 56
Figura 30. Tráfico caído (Dropped traffic) para los escenarios 2 y 3 planteados. .......................... 56
Figura 31. Cantidad de tráfico de bits para el escenario 2 planteado. ........................................... 57
Figura 32. Cantidad de tráfico de bits para el escenario 3 planteado. ........................................... 57
5
1
INTRODUCCIÓN, FORMULACIÓN DEL PROBLEMA Y OBJETIVOS
1.1 Resumen
La solución de los problemas asociados con la dinámica migratoria de la población
humana hacia las ciudades se está abordando a nivel mundial bajo el concepto de Smart
City, el cual acude a las Tecnologías de la Información y las Comunicaciones (ICT) para
proveer soluciones sostenibles. El mencionado concepto abarca, entre otros, los aspectos
relacionados con el transporte urbano en general y el transporte público de pasajeros en
particular.
El presente proyecto se encarga de proponer un modelo de arquitectura de Middleware,
para apoyar el desarrollo rápido y conveniente de servicios distribuidos y aplicaciones de
interoperabilidad entre las tecnologías heterogéneas actualmente usadas para el sensaje
y monitoreo.
El modelo propuesto permitirá la unificación de la información de sensaje y monitoreo
recopilada, tanto por las redes implementadas en Bogotá, como por aquellas que se han
implementado en otros países y que se espera a futuro sean incluidas en aquellas;
asimismo permitirá la conformación de la plataforma subyacente de las aplicaciones y
servicios que permitirá la agregación de inteligencia y autonomía en la toma de decisiones
de las máquinas que controlarán los sistemas de gestión del transporte urbano de
pasajeros.
1.2 Introducción
A nivel mundial las ciudades están experimentando un gran crecimiento, siendo así que
en Estados Unidos casi el 80% de la población vive en ciudades, mientras que en
España, alrededor del 70% de la población está concentrada en áreas con más de 50.000
habitantes [1]. En la figura 1 se presentan las cifras estadísticas de la población mundial
en comparación con la población urbana para el periodo 1960 – 2010 [2].
2
Figura 1. Población mundial periodo 1960 – 2030 Fuente: Banco Mundial.
De acuerdo con la tendencia mostrada se estima que en el 2050 el 70% de la población
mundial vivirá en ciudades.
De esta situación, los gobiernos, impulsados por la ciudadanía, ven cada vez más
necesario realizar un cambio en el modelo actual de ciudad que mitigue las
consecuencias de este crecimiento y permita un manejo adecuado a problemas futuros.
Es en este marco de donde se toma la noción de Smart City como un concepto amplio y
abierto de ciudad, cuyo propósito final es lograr una gestión eficiente en todos los
aspectos de la ciudad, satisfaciendo las necesidades de la urbe y de sus ciudadanos, en
consonancia con los principios de Desarrollo Sostenible expuestos en el Programa 21 de
las Naciones Unidas [3]. Estos principios deben aplicarse especialmente a: la
infraestructura tecnológica (redes de información, plataformas inteligentes, etc.), la
estrategia energética (uso de energías renovables, sistemas de almacenamiento y
aprovechamiento de energía, etc.), la gestión y protección de los recursos (ordenación del
territorio y de los recursos basada en principios de sostenibilidad, etc.), la provisión de
servicios (desarrollo de nuevos modelos colaborativos que permitan integrar lo público y lo
privado, etc.), y El Gobierno (accesibilidad de los datos, transparencia en la gestión,
aplicación de políticas sostenibles, etc.).
3
Este proyecto se concentra en la aplicación de conceptos de Smart City para aportar a la
solución de la problemática asociada con el transporte urbano público de pasajeros,
siendo el manejo eficiente de la flota de buses una contribución a la disminución de la
congestión del tráfico y al ahorro energético y la disminución de niveles de polución,
conceptos que se deben aplicar de manera transversal a todas las dimensiones de una
Smart City. A nivel de la Unión Europea se fijó en 2008 el denominado “Objetivo
20/20/20”, que pretende conseguir en el año 2020: una mejora del 20% de eficiencia
energética, que el 20% de la energía proceda de fuentes renovables, y una reducción del
20% en la emisión de gases de efecto invernadero [4] . Para cumplir con este tipo de
objetivos, se contribuirá con la solución de los mencionados temas para obtener una
mejor calidad de vida para los ciudadanos vía reducción de emisiones y de consumo
energético.
La importancia de la solución de la problemática asociada con el transporte urbano para el
cumplimiento de las mencionadas metas, tanto para el caso de las grandes ciudades
europeas como las del resto del mundo, se ilustra en la figura 2, la cual permite apreciar la
necesidad de tender hacia un modelo de movilidad menos dependiente del combustible
fósil y más eficiente desde el punto de vista energético; en este último aspecto contribuye
el presente proyecto.
Figura 2. Consumo energético por sector y fuente en 2010 (ktep). Fuente: Balance energético de 2010 (IDAE y Antiguo Ministerio de Industria, Turismo y Comercio de España).
Para lograr la solución de los mencionados problemas se viene investigando sobre el
concepto de WSN (Wireless Sensor Networks ó Redes de Sensores inalámbricos), que
usando los avances en sensores, comunicación y computación, permite la recolección de
4
información de diferentes redes de comunicaciones para gestionar el transporte urbano;
Las investigaciones realizadas permiten concluir que, si bien hay avances importantes en
el campo de los sensores inalámbricos, todavía se presentan problemas de índole técnico
por solucionar como la interoperabilidad de las diferentes tecnologías actualmente usadas
en los desarrollos pilotos implementados. Para solucionar estos problemas se necesita un
bloque constructivo funcional que permita la centralización y gestión de la información
recolectada por las mencionadas redes WSN en una plataforma unificada TIC
(Telecomunicaciones, Información y Comunicaciones) que permita el desarrollo potencial
de la visión de Smart City en materia de transporte urbano [5] [6], con la que no se cuenta
actualmente.
Por lo señalado anteriormente, mediante el modelo de arquitectura de middleware
planteado en este proyecto, se logrará la centralización y gestión de la información como
aporte a la solución del sistema de transporte urbano de pasajeros, contribuyendo a la
disminución de la congestión del tráfico y los problemas derivados de ésta, que en últimas
apuntan a brindar una mejor calidad de vida para los habitantes de las grandes ciudades.
La solución aquí planteada se basa en el concepto de Smart City.
1.3 Pregunta de investigación
De acuerdo con lo anterior, surge la formulación de las siguientes preguntas:
¿Cómo mejorar la calidad y la eficiencia del transporte urbano a través del desarrollo de
un modelo de arquitectura de Middleware para el sistema de transporte urbano de
pasajeros que permita realizar una gestión integral, generar servicios de valor agregado y
que a futuro pueda implementarse como parte del desarrollo en ciudades inteligentes?
1.4 Hipótesis
Las investigaciones y experimentos piloto en diferentes ciudades del mundo que han
abordado el tema del transporte urbano de pasajeros, han permitido establecer que la
implementación de Smart City está relativamente adelantado en temas de sensaje y
monitoreo, pero no en el aspecto de interoperabilidad entre las tecnologías heterogéneas
usadas. Es necesario desarrollar un bloque funcional o plataforma TIC (Middleware) que
5
realice esta integración, de tal manera que los problemas relacionados con este tema
sean afrontados de manera unificada.
Un modelo de arquitectura de Middleware permitirá la prestación de servicios finales
integrados, interoperables, robustos, portables, escalables, y seguros, en el transporte
urbano de pasajeros.
1.5 Objetivos
Objetivo General: Proponer un modelo de arquitectura de middleware para un sistema
de transporte urbano de pasajeros basado en el concepto de Smart City.
Objetivos Específicos:
1. Identificar y evaluar a través de la revisión del estado del arte los factores que son
más significativos para el desempeño de un Middleware en el entorno de WSN para
la comparación de alternativas de modelos de arquitectura de Middleware para un
sistema de transporte urbano de pasajeros basado en el concepto de Smart City.
2. Proponer un método para la evaluación del desempeño de un modelo de arquitectura
de mediador para un sistema de transporte urbano de pasajeros basado en Smart
City.
3. Definir las características asociadas a WSN, GPS, y RFID, que se tendrán en cuenta
para su integración como fuentes de información para el modelo de arquitectura de
Middeware.
6
MARCO TEÓRICO Y ESTADO DEL ARTE
2.1 Marco Teórico
En este apartado se describen los conceptos teóricos básicos de este proyecto, los
cuales son: Smart City, Smart Mobility (transporte urbano de pasajeros), Wireless
Sensor Networks (WSN), Global Positioning Systems (GPS), y middleware, los cuales
conformarán la fundamentación para el entendimiento y desarrollo del trabajo
propuesto.
2.1.1 Smart City y Smart Mobility
El término “Smart City” es un concepto utilizado en investigaciones científicas y en
marketing empresarial [7], siendo empleado frecuentemente tanto por organismos
públicos como privados; si bien, todavía no se ha establecido una definición universal
para este concepto, hay tres características principales que parecen ser comunes al
uso de esta expresión:
i) no dañar el medio ambiente;
ii) utilización de las tecnologías de la información y las comunicaciones (TIC) como
herramientas para la gestión (inteligente)
iii) su fin último debe ser el desarrollo sostenible.
La iniciativa europea de “Smart City” se centra en la problemática de sostenibilidad de
las ciudades actuales y, más específicamente, de los sistemas energéticos (European
Commission, 2010a). Una Smart City se define implícitamente como una ciudad que
mejora la calidad de vida y la economía local, avanzando hacia un futuro bajo en
emisiones de CO2.
Smart City conlleva medidas innovadoras respecto a la gestión de la energía
(incluyendo las redes de transporte, los edificios y el transporte), la reducción en gran
medida del uso de combustibles fósiles y la disminución de emisiones de CO2; todo ello
7
enfocado al cumplimiento de los objetivos marcados para 2020 dentro de la iniciativa
de Smart Cities [8].
La Iniciativa europea en Smart Cities and Communities [9] tiene por objeto apoyar a
ciudades pioneras europeas que supongan un impacto en una población mínima total
de veinte millones de habitantes que reflejen diferentes condiciones socio-económicas
y regionales. Esta iniciativa se centra principalmente en acciones innovadoras en
eficiencia energética, uso de tecnologías de bajas emisiones, redes inteligentes y
acciones de movilidad sostenible.
Entre las áreas de influencia de Smart City están:
Movilidad Smart, logística y tecnología.
Desarrollo de recursos humanos y capital humano: Personas (Smart People).
Economía Smart para la competitividad.
Urbanismo y Vivienda sostenible.
Ecosistema: entorno sostenible, energías renovables y otros recursos.
E-democracy, e-Government 2.0, Smart Government
Las TIC son un recurso transversal, cuyas herramientas constituyen un elemento
crucial para el desarrollo del concepto de Smart City en cada una de las áreas
mencionadas anteriormente. Para mostrar su importancia, a continuación se relacionan
algunas de las herramientas TIC que actualmente son utilizadas en las Smart Cities [1]:
Portal multiacceso (web, TV, internet móvil, canal telefónico, etc.).
“Smart Cards” o tarjetas inteligentes para el acceso a algunos de los servicios de
la ciudad.
Servicios de atención telefónica o presencial.
Puntos municipales inalámbricos de conexión WIFI.
Sensores distribuidos por la ciudad que recopilan y tratan la información
(aparcamiento, alumbrado, tráfico, control ambiental, residuos y papeleras).
Información en tiempo real del tráfico, el transporte público, etc.
8
2.1.1.1 Cadena de Valor de la Smart City
Una Smart City es un ecosistema complejo en el que intervienen numerosas
tecnologías [7], las cuáles se enfrentan a retos como: escalabilidad, capacidad,
movilidad, y gestión de la seguridad y privacidad de la información. Desplegar una
Smart City lleva asociada la creación de una serie de infraestructuras y a disponer de
mecanismos de gestión de la información y diferentes plataformas, con todo integrado
bajo una visión global.
De manera sintética se pueden definir en cinco los pasos de la que se podría
denominar “cadena de valor tecnológica” de la Smart City:
Recolección de datos de la ciudad. Esta tarea se realiza utilizando sensores,
actuadores (encargados de ejecutar acciones, no de recoger información) y
diferentes dispositivos, entre los que hay que incluir los móviles de las personas,
diferentes aparatos del entorno del hogar, los vehículos, así como los dispositivos
de medida situados en infraestructuras fijas, como mobiliario urbano, edificios,
sistemas de canalización y tuberías, estaciones meteorológicas y así un largo
etcétera.
Transmisión de los datos recopilados de la ciudad a través de las redes de
comunicación. Esto se lleva a cabo mediante una combinación de infraestructura
inalámbrica, móvil y fija dependiendo de las necesidades de movilidad, ancho de
banda y latencia de la aplicación en concreto. En algunos casos las redes
inalámbricas y móviles serán las únicas de las que se disponga. La arquitectura de
esta red es muy variada. Por regla general, los sensores transmiten la información a
través de protocolos ligeros a coordinadores o gateways que a su vez enrutan los
datos a través de líneas móviles o fijas y los hacen llegar a las bases de datos y
plataformas que faciliten la provisión de los servicios.
En esta arquitectura hay que destacar que, en algunas ocasiones, los propios
sistemas de sensado van provistos de cierta inteligencia y son capaces de actuar de
manera autónoma para proveer ciertos servicios o partes del servicio sin la
necesidad de conectar con el servidor central. Un ejemplo en este sentido podría ser
9
el de los sistemas de riego, que podrían activarse con una programación horaria que
también tuviera en cuenta la humedad del ambiente, por lo que cierta parte del
servicio, con su lógica o inteligencia, podría funcionar de manera autónoma sin
necesidad de conectar con un servidor central. De manera adicional el sistema
podría ser activado remotamente, o reportar datos al sistema central con el fin de
utilizarlos posteriormente para analizar la manera de optimizar el mantenimiento de
los jardines, aprender del uso, etc. En cualquier caso, el hecho de disponer de la
conectividad a la Red es lo que lo dotaría de toda su funcionalidad “smart”.
Almacenamiento y el análisis de los datos. se trata de almacenar en una
plataforma central los datos recopilados en el entorno de la ciudad al mismo tiempo
que se facilita su procesamiento posterior mediante diferentes sistemas analíticos.
Para ello, el repositorio de información no ha de ser volátil, permitiendo el uso
posterior de los datos por parte de aplicaciones y servicios diseñados para
satisfacer las necesidades de los actores involucrados.
Alimentación de Plataforma de provisión de servicios. Esta plataforma recibe
como insumo los datos almacenados y a partir de ellos facilita la prestación de los
servicios en el ámbito de la Smart City y está formada a su vez por módulos que
permiten, por ejemplo, gestionar el precio, facturar, gestionar las relaciones con el
cliente, etc. Además, tiene interfaces que serán utilizadas para implementar los
servicios que serán entregados a los clientes finales.
Servicios de la Smart City. Podrán ser desarrollados por los mismos agentes
involucrados en el resto de la cadena de valor tecnológica o por otros agentes, en
muchos de los casos, los agentes ya involucrados en la provisión de cada servicio
en concreto en el ámbito de la ciudad pertenecientes a los diferentes sectores y
ámbitos económicos.
En la figura 3 se presenta el esquema que describe la cadena de valor tecnológica de
la Smart City, donde se resalta en color naranja los eslabones relacionados con el
desarrollo de este proyecto.
10
Figura 3. Cadena de valor de Smart City. Fuente: Adaptado de [7].
2.1.2 Wireless Sensor Networks (WSN) y Global Positioning Systems (GPS)
Actualmente, las aplicaciones de WSN han aumentado considerablemente debido a la
necesidad de monitorear el estado de un determinado entorno en tiempo real y gracias
al Sistema de Posicionamiento Global, se puede determinar la localización de un objeto
o persona dentro de éste.
2.1.2.1 Wireless Sensor Networks (WSN)
Las Redes de Sensores Inalámbricas o llamadas comúnmente WSN, son redes
inalámbricas compuestas por varios dispositivos autónomos distribuidos llamados
nodos sensores, las cuales son capaces de crear sistemas de monitoreo y adquisición
de datos del entorno donde son configuradas. Las WSN son un área emergente de los
sistemas embebidos que tienen el potencial para revolucionar nuestras vidas en la
casa y en el trabajo, con aplicaciones de gran escala, incluyendo monitoreo y
conservación ambiental (por ejemplo en invernaderos), control industrial,
administración de negocios, monitoreo estructural y sísmico, transporte, salud y
domótica. En una WSN, cada nodo sensor posee capacidades de procesamiento,
almacenamiento y sensado, y una comunicación radio entre nodos. Además, cada
nodo está equipado con uno o más dispositivos sensores, tales como sensores de luz
visible o infrarroja, campos magnéticos, resistencia eléctrica, aceleración o vibración,
pH, humedad o temperatura, micrófonos acústicos y/o video o cámaras fotográficas
[10].
Además, las redes de sensores son conscientes de su posición geográfica, por lo tanto
se encuentran más ligadas al medio ambiente físico en el cual se encuentran que las
redes centralizadas [11].
Almacenamientoy análisis de datos
Plataformade provisión deservicios
5. CADENA DE VALOR TECNOLOGICA - SMART CITY
11
Dentro del grupo de sensores inmersos dentro de una WSN, se encuentran los
localizadores GPS que permiten conocer la posición de un punto cualquiera en un
espacio de coordenadas (x,y,z) en tiempo real, los cuales son útiles para monitorear y
rastrear objetos en estado estacionario o en movimiento.
Las WSN se caracterizan por ser redes homogéneas, debido a que están compuestas
típicamente por nodos con las mismas características; por ser redes estacionarias o
cuasi-estacionarias ya que sus nodos son estacionarios a menos que se trate del
seguimiento de los movimientos de objetos, animales o personas; por ser relativamente
dispersas gracias a que los nodos están dispersos en una gran región geográfica y
poseen tamaños grandes usando hasta miles de nodos [12].
Las WSN poseen varios retos que deben ser tratados antes de desplegarlas e
implementarlas a gran escala:
Conservación de la energía: debido al tamaño reducido de los nodos, las baterías
tienen poca capacidad, y la energía disponible es muy limitada.
Comunicaciones de baja calidad: las WSN a menudo son implementadas en
ambientes ásperos y a veces operan bajo condiciones climáticas extremas, por lo
tanto, esto puede generar que la calidad de la comunicación radio se vea afectada y
el sensado se vuelva muy difícil.
Operación en ambientes hostiles: en muchas ocasiones, se espera que las redes de
sensores operen bajo condiciones ambientales críticas.
Recursos limitados de cómputo: los protocolos para las redes de sensores deben
esforzarse para proporcionar la calidad de servicio deseada a pesar de los pocos
recursos disponibles.
Procesamiento de información: dadas las restricciones de energía y la relativamente
baja calidad de comunicación, la información recolectada por el nodo sensor debe
ser localmente comprimida, y complementada con información similar generada por
nodos vecinos.
Escalabilidad: debido a la gran cantidad de nodos que pueden componer una WSN,
la escalabilidad de protocolos para ésta debe ser considerada en la etapa de diseño.
12
La falta de aplicaciones de fácil comercialización: es difícil para las compañías de
electrónica comercializar aplicaciones basadas en redes de sensores debido a que
son muy específicas al depender de un escenario determinado.
Aunque los nodos sensores poseen varias limitaciones y los desarrolladores se
enfrentan a varios desafíos de diseño, existen varias ventajas para la instrumentación
de un área con una red de sensores [13]. Entre ellas se resaltan un alto nivel de
tolerancia a fallas en la WSN debido al despliegue denso de un gran número de nodos;
una mejora en la calidad de sensado, combinando lecturas de múltiples sensores
independientes y la sustracción de cualquier factor ambiental en el entorno que
interfiera con la observación del fenómeno deseado debido a que los nodos son
desplegados muy cerca al evento sensado.
Además, las WSN cuentan con una lista de métricas que determinan el funcionamiento
de éstas, entre las más importantes se encuentran el rendimiento de energía/tiempo de
vida del sistema, la latencia, la precisión, la tolerancia a fallas, la escalabilidad y la
capacidad de transporte/rendimiento [14].
Una red de sensores es diseñada para realizar una serie de tareas de procesamiento
de alto nivel tales como detección, seguimiento o clasificación, entre otras. Los agentes
inmersos en estas redes optimizan algunas tareas como la toma de decisiones y otras
mencionadas anteriormente como la eficiencia en el consumo de energía. Por lo tanto
surgen muchas áreas de aplicación de esta integración, donde además pueden existir
sensores GPS que brinden la localización de algún elemento dentro de la red o incluso
de esta misma. Entre estas áreas se encuentran: el monitoreo y control industrial, la
medicina, los entornos de alta seguridad y fines militares, la agricultura inteligente y
sensado ambiental, y la automatización del hogar [15].
Los nodos sensores inalámbricos más conocidos son los tmotes, mica2, Xbee –
microcontrolador y los diseñados recientemente por Sun Microsystems llamados Sun
SPOT. Estos nodos o comúnmente conocidos como motes se comunican a través de
alguna tecnología inalámbrica (IEEE 802.15.4, Bluetooth, UWB ) para WSN que tienen
varias características útiles que consideran las limitaciones inherentes a su reducido
tamaño (ver tabla 1).
13
Tabla 1. Módulos comerciales para WSN
Fuente: Fernández L., Blasco J.M. Wireless Sensor Networks [16].
De la comparación de estas tecnologías inalámbricas se puede inferir que el uso de
ellas dependerá considerablemente del tipo de aplicación y del diseñador de la WSN.
2.1.2.2 Global Positioning Systems (GPS)
El Sistema de Posicionamiento Global (GPS) es un servicio propiedad de los EE.UU.
que proporciona a los usuarios información sobre posicionamiento, navegación y
cronometría. Este sistema está constituido por tres segmentos: el segmento espacial,
el segmento de control y el segmento del usuario. La Fuerza Aérea de los Estados
Unidos desarrolla, mantiene y opera los segmentos espacial y de control [17].
Este sistema fue creado inicialmente con fines militares para proporcionar estimaciones
precisas de posición, velocidad y tiempo; utiliza conjuntamente una red de ordenadores
(estaciones en tierra) y una constelación de 24 satélites para determinar por
triangulación, la altitud, longitud y latitud de cualquier objeto en la superficie terrestre.
La altitud es la distancia vertical entre un punto dado y otro punto considerado como
nivel cero, el cual es el nivel medio del mar; las líneas de longitud o meridianos van de
14
polo a polo y dividen la circunferencia de la Tierra (el Ecuador) en 24 horas; y las líneas
de latitud o paralelos son aquellas que rodean la circunferencia de la tierra en el plano
horizontal.
Los satélites artificiales son utilizados por el GPS, como punto de referencia para el
cálculo de posiciones de puntos sobre la superficie de la tierra [18] y cada uno emite de
manera continua una señal indicando su posición y la hora de sus relojes atómicos.
El sistema GPS tiene por objetivo calcular la posición de un punto cualquiera en un
espacio de coordenadas (x,y,z), basándose en la medición de distancias a partir de
señales de radio transmitidas por un grupo de satélites artificiales cuya órbita se
conoce con precisión, y captadas y decodificadas por receptores ubicados en los
puntos cuya posición se desea determinar.
Si se miden las distancias de al menos tres diferentes satélites a un punto sobre la
tierra, es posible determinar la posición de dicho punto por triangulación. Supóngase
que un receptor en la tierra capta una señal de un primer satélite determinando la
distancia entre ambos, lo cual indica que el receptor puede estar ubicado en un punto
cualquiera dentro de la superficie de una esfera de radio R1. Si se mide la distancia de
un segundo satélite al mismo receptor se generará una superficie esférica de radio R2,
que al interceptarse con la primera esfera se formará un círculo en cuyo perímetro
pudiera estar ubicado el punto a medir. Si se agrega una tercera medición, la
intersección de la nueva esfera con las dos anteriores se reduce a dos puntos sobre el
perímetro del círculo descrito en la figura 4, donde uno de estos dos puntos puede ser
descartado por ser una respuesta incorrecta. Finalmente, debido a la imprecisión del
reloj del receptor es necesario un cuarto satélite para resolver el respectivo error.
Hoy en día el GPS supone una gama de aplicaciones disponibles. Estas se
orientan principalmente a sistemas de navegación y aplicaciones cartográficas:
topografía, cartografía, geodesia, sistema de información geográfica (GIS),
mercado de recreo (deportes de montaña, náutica, expediciones de todo tipo, etc.),
patrones de tiempo y sistemas de sincronización, aplicaciones diferenciales que
requieran mayor precisión además de las aplicaciones militares y espaciales.
15
En cuanto al reparto del mercado, los más importantes son la navegación marítima, la
aérea y la terrestre. El volumen de venta de equipos GPS está en torno a los
300 millones de dólares anuales. En cuanto a la navegación aérea, con unos
300.000 aviones en todo el mundo, el equipamiento de GPS para navegación
intercontinental o entre aeropuertos tiene una penetración anual del 5%
(aproximadamente unas 15.000 unidades). Sin embargo, el auténtico mercado del GPS
en el mundo es la navegación terrestre. Con 435 millones de turismos y 135
millones de camiones, es el más amplio mercado potencial de las aplicaciones
comerciales del GPS [19].
De hecho, el crecimiento de equipamiento de GPS mundial rodea los 2.000
millones de dólares anuales.
Para el presente proyecto el Sistema de Posicionamiento Global se utiliza
principalmente en el sistema de transporte público, a través de la instalación en los
autobuses de dispositivos denominados AVL (Automatic Vehicle Location), que tienen
en su interior dispositivos GPS, cuya función es la entrega de información en tiempo
real de la localización de los autobuses para fines de seguimiento y control.
Figura 4. Esquema de la intersección de las señales de 4 satélites para la determinación de la posición de un objeto en tierra.
Fuente: Casanova, L. (2002). Topografía Plana [18].
2.1.3 Middleware
El término middleware se deriva de la computación distribuida y se refiere a un
conjunto de servicios habilitantes tales como APIs (Application Programming Interfaz),
protocolos y servicios estandarizados de infraestructura para apoyar el desarrollo
16
rápido y conveniente de servicios distribuidos, y aplicaciones basadas inicialmente en
el paradigma cliente / servidor y después en el de varios niveles, que fue esencial para
la migración de aplicaciones mainframe/terminal de un solo nivel a la arquitectura de
varios niveles.
En el ámbito de la computación distribuida el concepto de Middleware, se define como:
“…el software de conectividad que está compuesto por un conjunto de servicios que
permiten a varios procesos (que se ejecutan en una o varias máquinas) interactuar a
través de la red” [20]
“…Son servicios que facilitan el desarrollo y despliegue de aplicaciones distribuidas en
ambientes heterogéneos” [21]
Middleware trata sobre la integración e interoperabilidad de aplicaciones y servicios
que se ejecutan sobre computación y dispositivos de comunicaciones heterogéneos.
Los servicios que ofrece, incluyendo la identificación, autenticación, autorización,
conmutación suave, certificación, y la seguridad, se usan en un amplio espectro de
accesorios y sistemas, desde tarjetas inteligentes y dispositivos inalámbricos hasta
servicios móviles y comercio electrónico.
El término middleware se refiere a un nivel que está localizado en la cima de los
sistemas operativos y las pilas de comunicaciones donde esconden la heterogeneidad
de las aplicaciones a través de un conjunto de interfaces comunes bien definidas,
como se muestra en la figura 5.
El Middleware ayuda a abstraer la distribución y hererogeneidad subyacente del
ambiente computacional y los servicios disponibles, además de soportar la adición de
características no funcionales como rendimiento, escalabilidad, confiabilidad,
disponibilidad, usabilidad, administrabilidad, QoS (Calidad de Servicio), eficiencia y
seguridad [22].
El middleware presenta los siguientes valores agregados:
Permite a las aplicaciones correr a través de múltiples plataformas comunicándose
unas con otras.
17
Protege al desarrollador de dependencias de los protocolos de red, sistemas
operativos, y plataformas de hardware.
Es una capa de software que subyace entre el sistema operativo y las aplicaciones
sobre cada sitio del sistema.
Figura 5. Middleware omnipresente. Fuente: Qusay H. Mahmoud, Middleware for Communications, John Wiley & Sons [23].
Oculta la heterogeneidad e independiza de la localización.
Incrementa la portabilidad del software.
Provee la funcionalidad común para varias aplicaciones.
Ayuda a la interoperabilidad de las aplicaciones.
Contribuye a la escalabilidad.
Ayuda a integrar instalaciones heredadas.
El Middleware está presente en casi todos los lugares donde un sistema de tecnologías
de la información y las comunicaciones existe. Muchos tipos de Middleware son
descritos en los libros relacionados en [23], [24]. A continuación se compila una lista de
middleware:
Message-Oriented Middleware (MOM/MQ/JMS/ESB).
CEP (Complex Event Processing) Middleware (Tibco, Sybase).
Adaptative and Reflective Middleware (TAO/DynamicTAO/OpenORB [25].
Transaction Middleware (TPM/Tuxedo).
18
Peer-to-Peer Middleware (JXTA).
Grid Middleware (PVM/MPI/Schedulers).
Model-Driven Middleware (CoSMIC).
Games Middleware (Autodesk).
Mobile Computer Middleware (OSA/Parlay/JAIN/OMA).
Radio-Frequency Identification (RFID) (Smart Cards) Middleware (Edgeware).
Three-tiered Application Server Middleware (Weblogic, Websphere).
Real-time CORBA Middleware (Real-time CORBA).
High-Availability (Fault Tolerance) Middleware (MHP/GEM/OCAP) [26].
RFID Edge Middleware (OATSystems, sybase, Oracle, Tibco, SeeBeyond, IBM,
SAP, Connectera, GlobeRanger, Manhattan Asociates).
Process-Oriented Middleware (WebMethods, SeeBeyond, Tibco, IBM, SAP, Oracle).
Business-to-Business (B2B)-Oriented Middleware (SeeBeyond/Oracle, Tibco,
webMethods).
Middleware for Location-Based Services.
Surveillance Middleware.
En la figura 6 se presenta una clasificación de los tipos de Middleware de acuerdo con
lo enunciado anteriormente.
Figura 6. Clasificación de Middleware. Fuente: Qusay H. Mahmoud, Middleware for Communications, John Wiley & Sons [23].
Se ha afirmado que por su proliferación actual el Middleware está en todas partes.
Parece que cada vez que más de dos aplicaciones han necesitado integrarse, un
pedazo de middleware ha sido desplegado para esta tarea. El problema es que esto ha
19
conducido a la producción de muchos Middlewares debido a que la mayoría de
desarrollos de Middlewares han sido tácticos, en lugar de ser parte de una estrategia
de tecnología de información.
Adicionalmente, el Middleware es el software “pegante” que ayuda a los programas y
bases de datos a correr sobre diferentes computadores para trabajar conjuntamente.
Gartner define formalmente el Middleware como: “Software de tiempo de ejecución del
sistema que permite las interacciones directas a nivel de aplicación entre los
programas en un ambiente de computación distribuida” [27].
La evolución rápida y omnipresencia de la red y las aplicaciones distribuidas ha dado
lugar a una proliferación de servicios de Middleware. Esta proliferación puede
percibirse a partir de tres dimensiones. En primer lugar, el middleware encapsula más
capacidades para gestionar subyacente a los recursos de computación, mientras que
estas funciones son consideradas tradicionalmente como las principales funciones del
sistema operativo distribuido. En segundo lugar, aunque las tecnologías de middleware
se han desarrollado inicialmente para hacer frente a problemas recurrentes en el
desarrollo de los sistemas distribuidos, a menudo se implementan funciones
adicionales que sólo son reutilizables en un dominio de aplicación específico, como las
finanzas, las ventas al por menor y telecomunicaciones. En tercer lugar, un middleware
proporciona algunas funcionalidades adicionales, como modelos de componentes y
herramientas de implementación, que facilitan el desarrollo y despliegue de los
sistemas distribuidos [28].
2.1.3.1 Middleware para WSN
Middleware también puede referirse a software y herramientas que pueden ayudar a
ocultar la complejidad y heterogeneidad de las plataformas subyacentes de hardware y
de red, facilitar la gestión de los recursos del sistema, y aumentar la estabilidad de
ejecuciones de aplicación. El middleware para WSN es un tipo de middleware que
provee los servicios deseados para aplicaciones de computación ubicua que utilizan
una WSN y el correspondiente sistema operativo embebido o firmware de los nodos
sensores [29]. En la mayoría de los casos, el Middleware para WSN es implementado
como embebido en el nodo [30].
20
Mientras la mayoría de las técnicas de sistemas distribuidos de Middleware embebidos
apuntan a la provisión de transparencia escondiendo el contexto de la información, las
aplicaciones basadas en WSN requieren ser sensibles al contexto [31].
Una solución completa de Middleware debe incluir cuatro componentes principales:
abstracciones de programación, servicios del sistema, soporte en tiempo de ejecución,
y mecanismos de calidad de servicio (QoS).
Las abstracciones de programación definen la interfaz del Middleware para el
programador de aplicación. Los servicios del sistema proveen implementaciones para
lograr las abstracciones. El soporte en tiempo de ejecución sirve como una extensión
del sistema operativo embebido para soportar los servicios del Middleware. Los
mecanismos de calidad del servicio definen las restricciones de QoS del sistema.
Figura 7. Arquitectura de Middleware para WSN. Fuente: Honbo Zhou, The Internet of things in the cloud [32] .
La figura 7 muestra la arquitectura del Middleware para WSN, el cual debe facilitar el
desarrollo, mantenimiento, despliegue y ejecución de aplicaciones basadas en sensaje.
Muchos desafíos deben superarse para diseñar Middeware para WSN, entre otras, por
las siguientes razones:
Recursos y potencia limitados, como la batería.
Topología de red móvil y dinámica.
21
Heterogeneidad, varias clases de hardware y protocolos de red.
Organización dinámica de la red, capacidad ad-hoc.
2.2 Estado del Arte
2.2.1 Smart City y Smart Mobility
2.2.1.1 Smart City para el Sistema de Transporte en el ámbito de la Unión Europea
El objeto de estudio para el presente proyecto está en la primera de las áreas
mencionadas en el numeral 2.1.1 [7]; para el ámbito de aplicación de la Unión Europea
se han pre cuantificado los objetivos iniciales según los siguientes criterios [33]:
Análisis de los flujos de tráfico, dando prioridad al transporte de emergencias y al
transporte público.
Detección automática de las infracciones del código de circulación y los peligros en
las carreteras, información mediante señales adecuadas o información online de los
accidentes producidos en las vías de circulación a los vehículos próximos.
Establecimiento de una serie de tarifas para el transporte privado, en función del
impacto ambiental y del uso de las infraestructuras (contaminación, ocupación de
espacios públicos, zonas por horas, etc.)
Implantación de servicios de información online para los ciudadanos: búsqueda a
través de Smartphones, dispositivos móviles, o pantallas fijas: conexiones, tiempos
estimados de llegada del transporte público, servicios para compartir bicicletas o
vehículos (car sharing), etc.
Impulso del desarrollo de medios de transporte más “sostenibles” y menos
contaminantes, como: vehículos eléctricos, medios de transporte impulsados por
hidrógeno, tranvías interurbanos, combustibles renovables, etc.
2.2.1.2 Financiación en la Unión Europea: El Séptimo Programa Marco (7PM)
El Séptimo Programa Marco (7PM) agrupa todas las iniciativas de la Unión Europea
relativas a la investigación y desempeña un papel crucial en el logro de los objetivos de
22
crecimiento, competitividad, empleo e innovación. Las temáticas del 7PM que
demuestran sinergias con el concepto de Smart City, están relacionadas
principalmente con energía y transporte eficiente. Para este tema se destaca la
iniciativa CIVITAS, cuya sigla significa CIty-VITAlity-Sustainability (Ciudad-VITAlidad-
Sostenibilidad).
Esta iniciativa se ha desarrollado en las siguientes fases, bajo cada una de las cuáles
se han realizado diversos proyectos [34]:
CIVITAS I (2002-2006) (dentro del 5° Programa Marco de Investigación); 19
ciudades agrupadas en 4 proyectos de demostración.
CIVITAS II (2005-2009) (dentro del 6° Programa Marco de Investigación), forman
parte 17 ciudades distribuidas en 4 proyectos demostrativos.
CIVITAS PLUS (2008-2012); 25 ciudades distribuidas en 5 proyectos.
CIVITAS PLUS II (2012-2016); 8 ciudades distribuidas en 2 proyectos
demostrativos.
Dos proyectos horizontales apoyan los proyectos de demostración y las ciudades
CIVITAS: (METEOR, CIVITAS GUARD)
Entre las áreas de interés para el presente proyecto están las siguientes:
Fase CIVITAS I: Estimulación del transporte colectivo y de la calidad del servicio
ofrecido a los pasajeros; Promover e implementar medidas de transporte urbano
sostenible, limpio y económico.
Fase CIVITAS II: Nuevas formas de uso de vehículos y estilos de vida menos intensiva
del coche; Vehículos eléctricos; Medidas Innovadoras para la gestión de la demanda
de movilidad; Integración de sistemas de gestión de transporte y servicios relacionados
con las TIC.
En la figura 8 se presenta un mapa de proyectos con las ciudades de la Unión Europea
incluidas en la iniciativa, haciendo la aclaración que en él se incluyen todas las áreas
relacionadas con el concepto de Smart City:
23
Figura 8. Ciudades de la Unión Europea incluidas en la iniciativa CIVITAS. Fuente: http://www.civitas-initiative.org
En la figura 9 se muestran la localización y nombre de las principales iniciativas de
Smart City a nivel mundial:
Figura 9. Principales iniciativas de Smart City en el mundo.
Fuente: http://www.civitas-initiative.org.
De los proyectos mostrados en el mapa anterior, a continuación se describen los que
incluyen entre sus temas el de movilidad:
24
Proyecto Smart City Malta
Ubicación: Smart City Malta se desarrolla en el emplazamiento de Ricasoli Industrial
Estate en Malta.
Fechas: 2006 /en curso
El proyecto se está desarrollando teniendo en cuenta los siguientes campos de
actuación [35].
En el tema de transporte y movilidad:
Una mezcla de los distintos usos para reducir las necesidades de viajes.
Un plan verde de viaje para la gestión de tráfico.
Fomento de los carriles bici así como de los medios públicos de transporte.
Proyecto Smart City Málaga
Ubicación: La zona elegida para implantar Smartcity es el Paseo Marítimo de Málaga.
Fechas: 2009 en curso (duración prevista 4 años)
El proyecto se está desarrollando teniendo en cuenta los siguientes campos de
actuación [36].
En el tema de transporte y movilidad:
Vehículos mediante gas natural/biocombustibles/hidrógeno.
Tarjeta sin contacto y pago NFC.
Paneles de información (GPS).
Autobuses accesibles + Sistema Invidente
Proyecto 22@Urban Lab
Ubicación: Barcelona (España)
Año Inicio: 2008
En el tema de transporte y movilidad:
Proyecto de movilidad sostenible. Despliegue de la infraestructura de recarga de
vehículos eléctricos y dos motos de la Guardia urbana de propulsión eléctrica.
Cámaras de control de tráfico conectadas por fibra óptica con la central de vía
pública para controlar en tiempo real el tráfico.
Semáforos adaptados para invidentes en todos los cruces del 22@Barcelona.
25
Varios tipos de carriles bici han sido testeados en el distrito 22@ con objeto de
detectar cuál de los pilotos contribuía a una mejor circulación y seguridad de los
ciclistas.
Proyecto: Masdar City
Ubicación: Abu Dhabi
Año Inicio: La estrategia original se desarrolló en 2006.
En el tema de transporte y movilidad: contará con un sistema pionero de transporte
público
Proyecto Song do International Business District
Ubicación: Songdo (Corea del sur)
Año Inicio: 2009
En el tema de transporte y movilidad:
Se creará una infraestructura de puntos de recarga para vehículos eléctricos en
diferentes plazas de garaje.
Los aparcamientos se construirán bajo el nivel del suelo, minimizando el impacto
visual. El 5% de los aparcamientos estarán reservados a vehículos con bajas
emisiones de CO2
Se crearán una red de “carril bici” con una extensión de 25 Km, para fomentar el
transporte libre de emisiones
Iniciativa Smart City Valladolid y Palencia
Ubicación:
Valladolid y Palencia están situadas en Castilla y León, España. Se trata de dos
ciudades muy cercanas, unidas por un importante eje de comunicación y transporte.
Año Inicio:
La Smart City Valladolid y Palencia comenzó su andadura en el año 2010.
En el tema de transporte y movilidad:
Vehículo Verde
Logística
Sistemas Inteligentes de Transporte
Movilidad Urbana interconectada e inteligente
26
2.2.1.3 Otras iniciativas:
Empresas relacionadas con el sector de las telecomunicaciones como IBM, Microsoft,
Cisco, Accenture, Siemens, Ericsson o Indra y centros de investigación como el MIT
o Terreform One han creado líneas de negocio o grupos de trabajo específicos
relacionados con el desarrollo de las ciudades inteligentes y la mayoría participa en
grandes proyectos, aunque existen también iniciativas de menor envergadura que
tienen relevancia ya que fomentan la innovación dentro del ámbito de las Smartcities,
algunos ejemplos son:
El Instituto Tecnológico de Massachusetts fundó en 2004 el MIT Senseable City Lab
cuyo objetivo es investigar la interacción que se produce entre las personas, la
tecnología y la ciudad, sus proyectos más recientes han sido “The Copenhagen
Wheel” (transformación de bicicletas convencionales en bicicletas hibridas) y el
“Trash Track” (investigación sobre la cadena de valor de la gestión de residuos en
ciudades).
IBM ha creado una competición mundial de emprendedores, denominada “Smart
camp”, en la que se seleccionará la mejor solución de base tecnológica para contribuir
a la construcción de un planeta más inteligente.
2.2.2 Middleware
La ISO formalizó la base para acercar todos los enfoques de Middleware, definiendo
los principios y estructuras comunes a Middleware en un marco de referencia conocido
como Modelo de Referencia para Procesamiento Distribuido Abierto (RM-ODP), cuyo
objetivo principal es alcanzar la distribución, interconexión, y portabilidad en un
ambiente de recursos heterogéneos de IT y múltiples dominios organizacionales de
diferentes participantes. ODP agrupa las funciones de Middleware en diversos
mecanismos de transparencia, como localización, fallas, persistencia, transacción, y
escalabilidad.
Los principios comunes de ODP han sido adoptados por varias de las principales
plataformas de Middleware, como OSP DCE (Open Software Foundation´s Distributed
Computing Environment), Common Object Request Broker Architecture (CORBA),
27
Java´s Remote Method Invocation (RMI) y Java EE, .NET/DCOM de Microsoft, LAMP
(Linux, Apache, MySQL, PHP/Perl/Python), y varios enfoques para sevicios web.
Una taxonomía funcional de Middleware es esbozada por Gartner [27] con tres
categorías principales: el Middleware de integración, el Middleware básico, y el de
desarrollo y administración de herramientas. Se han identificado más de una docena
de funciones que pueden realizarse con un Middleware.
El Middleware de integración cubre orientación al negocio y a la aplicación, que incluye
lo siguiente:
Gestión de procesos de negocios
Reglas de negocio/flujo de trabajo
Gestión de eventos de negocio
Enrutamiento de datos y adaptadores
El Middleware básico es el fundamento que se aplica para la infraestructura del Internet
de las Cosas (IoT), y puede categorizarse como sigue:
Middleware de gestión de datos: Ayuda a los programas a leer y escribir en las
bases de datos o archivos remotos. Ejemplos de este Middleware incluyen sistemas
de archivos distribuidos y paralelos, como el Sistema de Archivos de Google, IBM
GPFS, Sistema de Archivos de Red, y Windows; también incluye el Middleware de
acceso a bases de datos remotas, como Conectividad de Bases de Datos Abiertas o
librerías de Conectividad de Bases de Datos de Java que están atadas en DBMS´s
como IBM DB2, Oracle, y Microsoft SQL Server.
Middleware de Comunicación: Software que soporta protocolos para transmisión de
mensajes o datos entre dos puntos, así como una interfaz de programación del
sistema (SPI) para invocar el servicio de comunicación. Middleware más avanzado
de comunicación (como un middleware orientado al mensaje) también soporta
entrega de mensajes más seguro (usando seguridad fuerte) y confiable (garantizado
una y sólo una vez). Los protocolos y SPI´s usados en Middlewares de
comunicaciones pueden ser propietarios (por ejemplo, IBM WebSphere MQ/MQ-TT
28
o Microsoft MSMQ) o basados en estándares de industria como ASN.1, llamada a
procedimiento remoto RPC DCE, CORBA/HOP, Java Message Service (JMS) o
servicios web (Basados en SOAP o REST). Los Middleware de comunicación de
hoy generalmente corren sobre protocolos basados en Internet, como HTTP
(HTTPS), IP, SMTP, entre otros. Pueden implementarse protocolos de nivel
superior, incluyendo estándares de industria (por ejemplo, mensajería y servicios
web ebXML), y protocolos propietarios (por ejemplo, Oracle AQ), y pueden correr
sobre redes privadas o Internet. Los protocolos de comunicación de Middleware
también incluyen el Middleware Embebido.
Se ha investigado sobre el Middleware y los protocolos estándar asociados para
automatización de hogares y controles de edificios [37]. La tabla 2 es una lista de
algunos proyectos emergentes de Middlerawe para IoT.
Middleware de Plataforma: proporciona el entorno de alojamiento de tiempo de
ejecución (un container) para componentes de aplicación (ver figura 10). Utiliza un
Middleware embebido o de comunicación externa para ayudar a los programas a
interactuar con otros programas. Además provee servicios de gestión de recursos
para módulos de alojamiento de aplicaciones en tiempo de ejecución (caching,
arranque, parada, y programas de multiplexación, balanceo de carga, tolerancia a
fallas, seguridad de acceso, monitoreo y administración, procesamiento de
transacción distribuida, etc.). El Middleware de plataforma también provee
interfaces para una o varias formas de Middleware de comunicación (mensajería
unidireccional y solicitud/respuesta). El Middleware de plataforma es conocido hoy
como servidores de aplicación (JAVA EE o .NET Framework/COM+), Sin embargo,
históricamente muchas otras categorías de productos han servido como el
Middleware de plataforma entonces prevaleciente. Como ejemplos se incluyen los
monitores de procesamiento de transacción de mainframe (TPM´s como IBM
CICS), TPMS´s Distribuidos de Unix (como BEA Tuxedo; el autor usado para ser
parte del equipo), implementaciones RPC extendidas, objetos extendidos de
requerimiento de brokers (ORB´s) y monitores de transacciones de objetos,
plataformas de procedimientos almacenados DBMS, lenguajes propietarios de
cuarta generación, y servidores web programables.
El Middleware de plataforma ha evolucionado más en parte por el creciente interés en
servicios de portales, tales como personalización, acceso multicanal, y gestión de
29
contenido. Varios vendedores ofrecen servicios de portal como productos separados
como BEA Weblogic Portal, Plumtree, Vignette, y otros que tienen el propósito de
complementar los servidores web y servidores de aplicación.
Tabla 2. Middleware embebido para IoT.
Figura 10. Middleware de plataforma. Fuente: Honbo Zhou, The Internet of things in the cloud [32].
30
2.2.2.1 Middleware para WSN
Este tipo de Middleware está diseñado usando varios enfoques como máquina virtual,
agentes móviles, basados en bases de datos, orientados al mensaje, y más. A
continuación se listan ejemplos de Middleware de esta clase [38]:
MagnetOS (Cornell University): Consciente de la energía, adaptativo; la red entera
se ve como una sola JVM, los programas estándar de Java son reescritos por
MAGNET como componentes de red, y los componentes pueden ser “inyectados”
hacia la red mediante un esquema optimizado de energía.
IMPALA: Modular; eficiencia de las actualizaciones y soporte de aplicaciones
dinámicas; adaptación de aplicación con diferentes perfiles posibles; uso eficiente
de energía; usado en el proyecto ZebraNet para el monitoreo de la vida silvestre.
Cougar: Representa todos los sensores y los datos de los sensores en una base de
datos relacional; el control de sensores y la extracción de datos ocurre a través de
consultas especiales tipo SQL; implementación descentralizada; paso de mensajes
basado inundación controlada.
SINA (System Information Networking Architecture): Basado en la base de datos de
una hoja de cálculo donde la red es una colección de hojas de datos y las celdas
son atributos; denominación basada en atributos; preguntas realizadas en un
lenguaje tipo SQL; implementación descentralizada basada en clustering.
MIRES: Publicación/suscripción; enrutamiento multi salto; servicio adicional (como
agregación de datos); sentido-anuncio sobre P/S y ruta sumidero.
MQTT-S (Message Queue Telemetry Transport for Sensors, IBM); un protocolo de
mensajería tipo publicación/suscripción para WSN, con el objetivo de extender el
protocolo MQTT más allá del alcance de infraestructuras TCP/IP (redes no TCP/IP,
como Zigbee) para soluciones con sensores y actuadores; un producto comercial.
MiLAN: Provee un mecanismo que permite la adaptación de diferentes protocolos
de enrutamiento; localizado en la cima de múltiples redes físicas; actúa como una
capa que permite a conectores específicos de red conviertan comandos MiLAN en
otros específicos del protocolo que son pasados a través de la pila de protocolos
usual; puede adaptarse continuamente a las características específicas de cualquier
red que se esté usando en la comunicación.
31
El Middleware para WSN es considerado como “proactivo” en la familia de Middleware.
En la tabla 3 se presenta una lista más exhaustiva de plataformas existentes de
Middleware para WSN, software/OS, y lenguajes de programación. En [39] está
disponible Una comparación de algunos de los Middleware para WSN.
Tabla 3. Muestra de Middleware para WSN y lenguajes para WSN.
32
METODOLOGÍA Y DISEÑO DEL MODELO DE ARQUITECTURA DE
MIDDLEWARE PROPUESTO
3.1 Metodología
Para el desarrollo de este proyecto de investigación, se dividieron las actividades en las
cinco fases que se presentan en el diagrama de actividades de la figura 11, el cual se
diseñó para ser desarrollado en concordancia con los objetivos planteados:
3.2 Consideraciones del modelo
Con el fin de diseñar un modelo integral que maneje las tecnologías diversas descritas en
el capítulo anterior con el diseño y el desarrollo de un modelo de Arquitectura de
Middleware, es necesario cumplir con algunas consideraciones y exigencias propias de un
ambiente tan diverso. Las consideraciones presentadas a continuación pretenden
enfrentar y dar solución a las limitaciones encontradas, las cuáles se presentaron en el
capítulo 2.
3.2.1 Heterogeneidad de dispositivos
Actualmente existe una gran cantidad de dispositivos comerciales, tanto de WSN como de
sistemas AVL (que incluyen GPS) y de sistemas de video vigilancia. Por lo anterior es
necesario desarrollar un modelo escalable que sea acorde con la dinámica del mercado,
Se espera que en un espacio geográfico urbano la infraestructura instalada de
dispositivos sea muy colorida, conformada por diferentes tecnologías que poseen a su vez
distintos sensores y actuadores. El modelo a plantear debe integrar todas las tecnologías
y manejar interoperabilidad de componentes heterogéneos.
3.2.2 Interoperabilidad
Es la Característica de un sistema de lograr que todas sus partes interactúen entre sí, en
este caso se busca que las partes en el modelo se integren a través de capas de
33
abstracción, las cuáles de manera transparente deberán proveer los mecanismos
necesarios para su integración.
Figura 11. Diagrama de Actividades del proyecto.
34
3.2.3 Escalabilidad
Es la propiedad que puede tener un sistema para crecer o disminuir su tamaño sin que
esto altere su funcionamiento ni eficiencia, con esta premisa surgen dos sub
consideraciones con respecto a la escalabilidad.
Escalabilidad a nuevas tecnologías: En primer lugar y volviendo al tema de la
diversidad de dispositivos, es de esperar que surjan nuevos dispositivos de sensaje en
cada una de las líneas que se han mencionado, que mejoren las tecnologías en todos los
aspectos actuales. Los nuevos dispositivos sobrepasarían a los actuales en aspectos
como capacidad de procesamiento, de almacenamiento, precisión, consumo de energía,
tasas de transferencia de datos, tasa de errores, tamaño físico, entre otros.
Escalabilidad a tecnologías soportadas: Tanto las WSN como los dispositivos AVL
estarán geográficamente dispersos y ocasiones se encontrarán expuestos a condiciones
propias del entorno, las cuáles deteriorarán prematuramente sus características de
rendimiento; adicionalmente algunos son dependientes de la duración de la carga de la
batería propia, por lo que aparece la necesidad de añadir nuevos dispositivos a la red
para reemplazar los defectuosos o aquellos sin energía sin que esto afecte el
funcionamiento del sistema, ni las operaciones que en un momento dado se estén
efectuando. Por lo anterior, el sistema debe detectar, integrar y transferir de manera
automática las operaciones de los dispositivos defectuosos a aquellos que están
conectados.
3.2.4 Modularidad de programación
Para conseguir aspectos claves como la escalabilidad es muy importante considerar una
programación modular, que facilite el acople y desacople de nuevos componentes de
software. Así, el modelo debe poseer una arquitectura modular de modo que integre
nuevas funcionalidades y/o puedan ser actualizadas las vigentes con facilidad.
3.2.5 Transparencia
La transparencia es la función fundamental de un Middleware, es la capacidad de mapear
funcionalidades y mecanismos complejos en interfaces cómodas para el desarrollador. En
35
este caso se refiere a la posibilidad de que agentes de software puedan utilizar dichas
interfaces para acceder a dispositivos complejos de bajo nivel con capacidades de
percepción y actuación en un entorno determinado.
3.2.6 Formalización del entorno
El entorno está definido como el espacio geográfico de interés, en el cual están
distribuidos los sensores y actuadores de la red, con el fin de percibir y actuar sobre dicho
entorno. Ahora bien, el entorno es un ambiente dinámico y altamente cambiante lo cual lo
convierte en una gran fuente de información, que a su vez se convertirá en conocimiento
para aquellos agentes que soliciten conocer su entorno. Sin embargo, no todo es color de
rosa, es necesario dar un formato a todo el conocimiento del entorno y para ello el modelo
debe implementar un mecanismo que permita que se puedan establecer actos
comunicativos de alto nivel.
3.3 Diseño del Modelo de Middleware
Teniendo en cuenta las consideraciones del modelo descritas en el apartado anterior y la
tipología general, tanto de los dispositivos sensores que constituirán las entradas para el
Middleware, como de las aplicaciones que serán usuarias del Middleware, en la figura 12
se presenta el diagrama general del sistema, donde se muestran las relaciones de flujo de
información entre los mencionados componentes.
36
Figura 12. Diagrama general del sistema.
A continuación se presenta el proceso de diseño desde el punto de vista de Ingeniería de
Software para el Middleware, en sus diferentes aspectos fundamentales.
3.3.1 Diagramas de Casos de Uso
Las diferentes funcionalidades del sistema a desarrollar y sus respectivas interacciones
con los usuarios, que no son humanos sino dispositivos y aplicaciones, se definen tres
casos de uso y dos actores genéricos; todo lo anterior se describe en la figura 13.
Middleware
AVL
ID_Dispositivo
Fecha
Hora
Latitud
Longitud
Altura
Velocidad
WSN
ID_Dispositivo
Fecha
Hora
Protocolo
Temperatura
Presión
CÁMARA
ID_Dispositivo
Fecha
Hora
Protocolo
Imagen
RFID
ID_Dispositivo
Fecha
Hora
Protocolo
Saldo
APLICACIÓN 1
ID_Aplicación
Fecha
Hora
Protocolo
Señal 1
Señal 2
Señal n
APLICACIÓN n
ID_Aplicación
Fecha
Hora
Protocolo
Señal 1
Señal 2
Señal m
………
Base de Datos
37
Figura 13. Diagrama de Casos de Uso General
Como se puede observar, el Middleware debe recoger la información recibida de los
diferentes dispositivos de sensaje heterogéneos, los cuáles son mencionados en el
capítulo anterior, a saber: WSN, GPS, y dispositivos RFID.
Estas fuentes de información cumplen la función básica de alimentar al Middleware con
los datos recogidos de la operación normal del sistema de transporte público de pasajeros
de la ciudad, para procesarlos, codificarlos en un formato único, y administrarlos de
acuerdo a las necesidades de información.
Una vez los datos son procesados, se almacenan en la Base de Datos (ver figura 12) para
que las diferentes aplicaciones actuales y futuras dispongan de ellos (Caso de uso Extraer
Datos). La capacidad del Middleware será medida en términos de su poder para proveer
la información requerida de manera transparente, oportuna, y confiable; en esa misma
proporción debe medirse su pertinencia y aporte al sistema de transporte masivo de
pasajeros.
Las aplicaciones permitirán a los actores del sistema de transporte masivo de pasajeros a
saber: La administración municipal, los operadores del sistema, y los pasajeros, obtener
MIDDLEWARE
38
información relevante para la administración, control, y uso del sistema de manera
oportuna, confiable y escalable.
La figura 14 muestra el diagrama de casos de uso desde el módulo cliente.
Figura 14. Diagrama de Casos de Uso del módulo cliente
El cliente puede consultar el listado de paquetes de información, lo cual incluye el listar
paquetes de información disponibles, y listar paquetes de información adquiridos.
3.3.2 Diagramas de Actividades
Para el Caso de Uso de obtener información de los sensores de información se deben
efectuar las actividades descritas en la figura 15.
39
Figura 15. Diagrama de Actividades para cargar Datos en el sistema desde los Sensores.
El sensor en cuestión debe iniciar el procedimiento enviando una solicitud de conexión, la
cual es confirmada por el sistema, luego de la cual se inicia el envío de datos sensados
por parte del sensor. Una vez iniciada la transmisión de datos, el Middleware debe hacer
la verificación del registro correcto de la información en la Base de Datos del sistema, de
tal manera que cuando éste no se logre, solicite al sensor el reenvío de la información; el
Middleware también debe verificar la obtención de la totalidad de la información, para que
en la Base de Datos del sistema se obtenga información confiable y completa.
En la figura 16 se muestra el diagrama de actividades correspondiente al Caso de Uso
denominado Extraer Datos, proceso en el cual intervienen el sistema de información y las
aplicaciones que requieren hacer uso de la información procesada, ya sea para entregarla
40
transparentemente, o para generar procesos que agreguen valor a sus clientes mediante
herramientas de apoyo y de toma de decisiones.
Figura 16. Diagrama de Actividades para Extracción de Datos por parte de las aplicaciones.
La aplicación en cuestión debe iniciar el proceso mediante la solicitud de conexión la cual,
una vez confirmada por el sistema, da lugar por parte de éste último al envío de
información desde la Base de Datos. Una vez iniciada la transmisión de datos, la
aplicación debe hacer la verificación del registro correcto de la información, de tal manera
que cuando no se logre obtener notifique al sistema a través del Middleware para que se
efectúe el reenvío de la información; la aplicación también debe verificar la obtención de la
totalidad de la información, para asegurar la transferencia confiable y completa de ésta.
41
3.3.3 Diagramas de Secuencia
A partir de los diagramas de actividades descritos en el apartado anterior, se generan los
diagramas de secuencia, que permiten presentar de una manera ordenada desde la
perspectiva del tiempo las acciones entre los actores que intervienen en cada uno de los
Casos de Uso planteados.
La figura 17 presenta el diagrama de secuencia para el Caso de Uso denominado
“Información Codificada y Formateada”.
Figura 17. Diagrama de Secuencia para cargar, codificar y formatear Datos en el sistema desde los Sensores.
En la figura se aprecia que el proceso inicia con una solicitud de conexión por parte del
Dispositivo de Sensaje el cual es aceptado por el servidor, quien inmediatamente procede
a tomar los datos recopilados por el sensor en cuestión; el sensor envía, además de la
información leída del sitio de monitoreo, la fecha, hora, número de secuencia de la
muestra, identificación del sensor que envía la información.
Esta información es reenviada por el servidor al Middleware, quien luego de procesarla y
organizarla en paquetes la entrega al servidor de aplicaciones en el formato establecido
42
para almacenamiento; eventualmente, puede también entregarla a una aplicación que la
esté requiriendo en ese momento.
La figura 18 presenta el diagrama de secuencia para el Caso de Uso denominado
“Petición de Datos Antiguos”.
Figura 18. Diagrama de Secuencia para petición de Datos Antigüos del sistema desde las Aplicaciones.
El Diagrama de Secuencia inicia con la solicitud por parte de la aplicación de datos
antiguos al Middleware, quien los busca y obtiene del servidor de aplicaciones, luego de lo
cual los envía a la aplicación solicitante. Es responsabilidad de la aplicación la
verificación de la obtención de la totalidad de la información, para asegurar la
transferencia confiable y completa de ésta.
La figura 19 presenta el diagrama de secuencia para el Caso de Uso denominado
“Solicitud de Estadísticas”.
El Diagrama de Secuencia inicia con la solicitud por parte de la aplicación de datos
estadísticas al Middleware, quien busca y obtiene la información necesaria del servidor de
aplicaciones, genera las estadísticas solicitadas, y finalmente las envía a la aplicación
solicitante. Es responsabilidad de la aplicación verificar la obtención de la información de
manera confiable y completa.
43
Figura 19. Diagrama de Secuencia para solicitud de estadísticas del sistema desde las Aplicaciones.
Finalmente, la figura 20 presenta el diagrama de secuencia para el Caso de Uso
denominado “Modelo de auditoría”.
El Diagrama de Secuencia inicia con la solicitud por parte del Auditor de datos originales y
estadísticos al Middleware, quien busca y obtiene los datos solicitados del servidor de
aplicaciones, los envía al auditor, genera y envía las estadísticas solicitadas con destino al
Auditor, y finalmente el auditor envía su informe al Middleware para que éste los envíe al
servidor.
44
Figura 20. Diagrama de Secuencia para solicitud y obtención de información de auditoría por parte del Auditor.
3.3 Modelo de Middleware Propuesto
Realizado el procedimiento de diseño presentado en el apartado anterior, se propone el
modelo de Middleware mostrado en la figura 21, el cual está conformado por las capas de
Interfaz Red de Sensores, de Proceso de Datos, y de Interfaz de Servicios de Aplicación.
La capa Interfaz Red de Sensores provee funciones de interfaz comunes a las múltiples
redes de sensores, funciones de monitoreo y control para los estados de diferentes redes
de sensores.
La Capa de proceso de datos provee diferentes funciones para el procesamiento de
consultas basadas en los datos recolectados por los sensores, además, un componente
de gestión de datos está en la capa de procesamiento de datos para filtrar los datos
sensados y dar soporte a diferentes formas de consultas.
45
Figura 21. Diagrama jerárquico del Middleware propuesto.
La capa Interfaz de Servicios de Aplicación, que está en la cima del Middleware, juega un
rol importante en los servicios de procesamiento de eventos, y soporta conexión con el
exterior mediante el procesamiento de consultas.
En la figura 22 se muestra la estructura y el mapa de flujo de datos para el Middleware
propuesto, así como las funciones para cada módulo del Middleware y un flujograma
estructural con los sensores, el Gateway, y el sistema de monitoreo.
La interfaz de Red de Sensores guarda los diferentes formatos de datos de los nodos de
sensores por adelantado para asegurarse que los datos transportados en el ambiente de
redes de sensores heterogéneos puedan reconocerse. La situación ideal es la de tener un
transductor integrado para convertir a un formato común todos los datos obtenidos del
Control de InstalacionesCapa de
Aplicación
Servicio de Eventos
Capa de Middleware
Interfaz de Servicios de Aplicación
Gestor de Servicio de Datos
Proceso de Datos
Controlador de Base de Datos
Gestor de Datos (Filtrado)
Integrador de Datos
Interfaz Red de Sensores
Decodificador
Clasificador de Datos
Cola de Datos
G/W
Capa FísicaG/W G/W G/W
AVL WSN CAM RFID
46
cualquier sensor heterogéneo, no obstante, dado que hay un estándar para los datos de
cada tipo de nodo sensor, esta situación no se da.
Figura 22. Estructura y mapa de flujo de datos para el Middleware propuesto.
El filtrado de datos no almacena datos entregados desde la interfaz Red de Sensores en
la BD si el dato está duplicado, o almacena datos sólo cuando el dato ha sido cambiado.
47
SIMULACIÓN DEL MODELO Y RESULTADOS
4.1 Escenarios de Validación
Para la realización de las pruebas de validación se efectuó una simulación que permitió
comparar el desempeño del modelo propuesto, bajo la modalidad manejada por el
simulador OPNET Modeler (versión académica) de escenarios.
Para la simulación se utilizó como referencia la red troncal del sistema de transporte
masivo de Bogotá, denominado Transmilenio S.A., en aras de armonizar y aplicar en un
futuro el modelo de arquitectura diseñado en este trabajo de grado en aquel sistema de
transporte. La simulación se efectuó bajo tres escenarios:
4.1.1 Escenario 1
En este escenario sirvió de referencia para crear los escenarios 2 y 3, en cuanto a la
cantidad de tráfico que generan los nodos sensores, el cual es transportado hasta el
servidor en el que se implementa el Middleware.
Se configuró la red de Transmilenio conformada por cuarenta y cuatro nodos sensores
inalámbricos, entre fijos (diecinueve, instalados en estaciones) y móviles (veinticinco,
instalados en buses), localizados en las troncales de la Fase I (Avenida Caracas,
Autopista Norte, y Calle 80) y de la Fase II (Autopista Sur, NQS, y Avenida Suba) de este
sistema de transporte masivo. Este escenario se muestra en la Figura 23.
Para la simulación se recrearon las tramas procedentes de las diferentes fuentes de
información, datos que ingresarán al Middleware. Los campos de información relevantes
de estas tramas se mostraron en la figura 12, los cuáles constituyen la materia prima a
procesar por el Middleware y los posteriores insumos de entrada para las aplicaciones
que serán los clientes finales para el Middleware.
48
Figura 23. Escenario de validación 1 en OPNET Modeler versión académica.
4.1.2 Escenario 2
Dadas las limitaciones de la versión académica del OPNET, particularmente en la
cantidad máxima de nodos admitidos en un escenario simulación, cuyo valor es de 80,
para este escenario se aprovechó la simulación del escenario 1, que permitió establecer
el tráfico unitario de los nodos sensores allí recreados.
A partir de esta información, se agregó un único nodo que generó la cantidad de tráfico de
datos equivalente al que entregarían 500 nodos sensores, entre cámaras instaladas en
las estaciones, portales y demás instalaciones de Transmilenio, y dispositivos AVL
instalados en los buses del sistema.
El tráfico simulado en este escenario corresponde al equivalente a 500 nodos sensores
más el generado en el escenario 1, como se muestra en la figura 24.
49
Figura 24. Escenario de validación 2 en OPNET Modeler versión académica.
4.1.3 Escenario 3
Para este escenario, al igual que se hizo con el anterior, se utilizó un único nodo que
genera cantidad de tráfico de datos equivalente al que entregarían varios dispositivos
sensores, en este caso 2500, entre cámaras instaladas en las estaciones, portales y
demás instalaciones de Transmilenio, y dispositivos AVL instalados en los buses del
sistema. Al tráfico de éstas cámaras se agrega el generado en el escenario 1, como se
muestra en la figura 25.
50
Figura 25. Escenario de validación 3 en OPNET Modeler versión académica.
4.2 Herramientas Utilizadas
A continuación se describen las herramientas de hardware y de software que se utilizaron
para la validación del modelo de Middleware objeto de este proyecto.
4.2.1 Hardware
Las características del hardware bajo el cual se corrió el simulador para el Middleware
propuesto son las que se presentan en la tabla No. 4.
Tabla 4. Características del hardware para la simulación.
4.2.1 Software
CPU Intel core i3 @ 1.8 Ghz
RAM 8 GB
S O Windows 8.1
51
Para la verificación del modelo propuesto, se realizó una simulación utilizando el
programa simulador de redes OPNET Modeler versión académica. El “Acuerdo de Uso
Restringido” aparece cada vez que se abre el programa y es como se muestra en la
Figura 26. Básicamente, lo que dice este “Acuerdo de Uso Restringido” es que el
simulador tiene licencia únicamente para uso educacional (o académico), no-comercial.
Y que por ningún motivo se debe usar con fines lucrativos, sin previa autorización
por escrito de OPNET [40]. Para lograr hacer la simulación superando la limitación de la
cantidad máxima de nodos a simular, que es de 80 para esta versión de OPNET, se
realizó la implementación de un nodo que generaba el tráfico equivalente a múltiples
nodos, de tal manera que los escenarios recreados sean representativos de la red a
simular.
El programa de simulación OPNET permite crear formatos personalizados de unidades de
información para las tramas que no estén disponibles en el mencionado software.
Figura 26. “Acuerdo de Uso Restringido” para el simulador OPNET versión académica.
Fuente: [34].
52
4.3 Indicadores o parámetros de evaluación
De la simulación del modelo de Middleware propuesto se obtuvo una evaluación del
rendimiento del mismo, teniendo en cuenta los siguientes indicadores:
4.3.1 Latencia
Este indicador tiene particular importancia en aplicaciones interactivas, que demandan
que la latencia de ejecución de un evento debe encontrarse acotada. En este contexto, la
latencia debe ser tal que el usuario no perciba una demora entre su acción y la
respuesta esperada. Como ejemplo, se tienen los juegos interactivos en línea basados en
la web, para los cuáles es necesaria una latencia menor a los 180 ms [41].
Para este proyecto en particular, se tomará este indicador como un 50% por encima del
establecido en la mencionada aplicación (para un total de 270 ms), dado que el objetivo
principal es que la información sensada esté disponible para aplicaciones que permitan ya
sea el monitoreo desde el Centro de Control de Transmilenio, en cuyo caso los
funcionarios del operador de la red encargado podrán contar con elementos de juicio para
la toma de decisiones, o desde otras aplicaciones que permitan la generación de valor
agregado para los clientes, como por ejemplo conocer en tiempo cercano al real la
demora del servicio expreso que pueda llevarlo a su destino.
4.3.2 Escalabilidad
Se refiere a cómo varía la respuesta o rendimiento del Middleware en términos de tiempos
de notificación y carga de información a la Base de Datos a medida que crece la cantidad
de dispositivos de sensado que generan y entregan datos al sistema. En este sentido se
debería contar con la modularidad necesaria que permita aumentar la cantidad de nodos
de manera sistemática y ordenada sin que el rendimiento del Middleware se degrade
significativamente, es decir, más de un 50% con respecto al rendimiento planteado en el
escenario 1 especificado en el numeral 4.1.1 de este documento.
53
Como parámetros para cuantificar indirectamente este indicador, se midieron tres
parámetros en los escenarios planteados:
Porcentaje de utilización de la CPU: Permite establecer que tanto se satura el
procesador del servidor que tiene implementadas las funciones del Middleware.
Para el escenario 3 (peor caso), este porcentaje debe ser inferior al 80%, de tal
manera que exista un margen de utilización que permita el manejo y gestión de una
mayor cantidad de tráfico proveniente de los sensores de la red.
Tráfico caído (Dropped traffic): Indica cuanta información se pierde por unidad de
tiempo cuando se efectúa el incremento del tráfico entre cada uno de los
escenarios. Algunas de las causas de esta pérdida de tráfico incluyen condiciones
de sobrecarga del sistema, perfiles y políticas que restringen el ancho de banda o
prioridad de tráfico, caídas de la red, o interrupción por fallas en los medios físicos.
Este parámetro no debe exceder un umbral, cuyo valor depende de la cantidad de
información total de una fuente determinada. Para el escenario 3 (peor caso), este
valor no debe superar el 0,01% del total de paquetes transmitidos. En [42] se utiliza
la fórmula estándar para medir este parámetro.
Incremento de tráfico: Permite evaluar cuanta información deberá manejar el
Middleware y dimensionar si los buses de datos, procesadores, y demás recursos
con que cuenta el Middleware son suficientes para gestionarla o no. También
permite dimensionar la Base de Datos necesaria para almacenar la información
procesada por el Middleware para su posterior consulta por parte de los clientes.
4.3.3 Pertinencia de los indicadores evaluados
Los anteriores indicadores, tomados como criterios para la evaluación del cumplimiento
de las seis (6) consideraciones del modelo enunciadas en el numeral 3.2 de este
documento, se pueden medir indirectamente en términos de los parámetros: tiempo de
retardo, porcentaje de utilización de la CPU, tráfico caído, e incremento del tráfico,
considerando que el objetivo del Midddleware es efectuar una serie de procesos que
inician con la recepción de los datos tomados de los diferentes dispositivos de sensaje
heterogéneos y transportados hasta la entrada del Middleware, y terminan con la entrega
por parte de los mismos a las aplicaciones que lo requieran. Bajo esta óptica, la
54
efectividad del Middleware, se podrá establecer mediante el cumplimiento de los umbrales
de los mencionados parámetros en la simulación, bajo condiciones de:
Baja, media, y alta cantidad de datos que ingresan desde los sensores
heterogéneos, en cuyos casos se exige mayor capacidad de procesamiento en
términos de ciclos de CPU y transacciones que permitan la transformación de los
mismos hasta dejarlos almacenados en la Base de Datos del sistema. En este ítem
está implícito el cumplimiento de las consideraciones de heterogeneidad de
dispositivos (diferentes tipos de sensores y naturaleza de información ingresada por
los mismos), interoperabilidad (la cual está integrada en los bloques del
Middleware), y modularidad de programación (al ingresar nuevos formatos y
naturaleza de datos provenientes de otros sensores de información diversa).
Atención a las aplicaciones que requieran los datos del Middleware, los cuáles
también exigirán mayor cantidad de datos transferidos desde éste hacia aquellas.
En este ítem está implícito el cumplimiento de las consideraciones de modularidad
de programación (acople y desacople de diferentes componentes de software que
conforman las aplicaciones), transparencia (mapeo de funcionalidades en
interfaces cómodas para el desarrollador).
Tanto en unas como en otras condiciones está implícita la escalabilidad, última
consideración de diseño presentada en el numeral 3.2 del presente documento.
La medición de los mencionados indicadores permitirá hacer una evaluación adecuada
del comportamiento del Middleware bajo condiciones reales de trabajo.
4.4 Resultados
Mediante las simulaciones efectuadas se demostró que la implementación del Middleware
permite que el sistema funcione bajo los indicadores de latencia y escalabilidad señalados
en los numerales 4.3.1 y 4.3.2.
Efectuadas las primeras simulaciones, bajo las condiciones para los escenarios 1, 2 y 3
especificadas en los numerales 4.1.1, 4.1.2 y 4.1.3 de este documento, se consideran en
este documento los datos obtenidos de las simulaciones de los escenarios 2 y 3, que
55
corresponden a un nivel de tráfico más representativo del realmente generado en un
sistema de transporte masivo como Transmilenio.
En la Figuras 27 y 28 se muestran los resultados que se obtuvieron en los escenarios 2 y
3 para el parámetro tiempo promedio de procesamiento de los paquetes recibidos y
procesados por parte del servidor donde se implementó el Middleware.
Figura 27. Tiempo promedio procesamiento de paquetes para el escenario 2 planteado.
Figura 28. Tiempo promedio procesamiento de paquetes para el escenario 3 planteado.
56
En la Figura 29 se muestran los resultados obtenidos en los escenarios 2 y 3 para el
parámetro porcentaje de utilización de la CPU por parte del servidor encargado de
ejecutar los procesos del Middleware.
Figura 29. Porcentaje de utilización de la CPU para los escenarios 2 y 3 planteados.
En la Figura 30 se muestran los resultados obtenidos en los escenarios 2 y 3 para el
parámetro Tráfico caído (Dropped traffic).
Figura 30. Tráfico caído (Dropped traffic) para los escenarios 2 y 3 planteados.
57
Finalmente, en las figuras 31 y 32 se muestran los resultados obtenidos en los escenarios
2 y 3 para el parámetro incremento de tráfico, en bits por segundo, que llegan al servidor
como consecuencia del aumento de nodos sensores cuando se pasa del escenario 2 al
escenario 3.
Figura 31. Cantidad de tráfico de bits para el escenario 2 planteado.
Figura 32. Cantidad de tráfico de bits para el escenario 3 planteado.
58
EVALUACIÓN DEL DESEMPEÑO
5.1 Evaluación Cualitativa
En cuanto al indicador de latencia, se observó una un incremento en el retardo del 74,8%,
cuando se pasa del escenario 2 al escenario 3.
Es pertinente resaltar que para todos los escenarios de simulación realizados, el tiempo
de retardo obtenido fue muy inferior al umbral establecido en el numeral 4.3.1 de este
documento. Considerando los resultados obtenidos, se permite inferir que hay un gran
margen adicional para el cual este parámetro no será crítico al incrementar el tráfico
entregado al Middleware.
Por lo tanto se puede esperar que el sistema entregará la información procesada en
tiempo real a los usuarios (aplicaciones) del mismo en condiciones reales de trabajo.
En cuanto al indicador de escalabilidad, los resultados de los parámetros elegidos para
evaluar indirectamente el mencionado indicador también permiten deducir que el sistema
es escalable:
Porcentaje de utilización de la CPU: el incremento en el número de nodos
equivalentes, representados en los escenarios 2 y 3, representó un incremento de
este parámetro del 57.5%. En ningún caso excedió el valor fijado en el numeral
4.3.2 de este documento. No obstante, este es el parámetro que potencialmente
será más crítico a la hora de incrementar sustancialmente el tráfico con respecto al
simulado en el escenario 3
Tráfico caído (Dropped traffic):El cambio en el tráfico cursado entre los escenarios 2
y 3, representó un incremento de la tasa de tráfico caído del 250%, ninguno de los
cuales constituye un valor que exceda el umbral fijado en el numeral 4.3.2 de este
numeral. De los resultados obtenidos, se puede esperar que el sistema entregará la
información procesada en tiempo real a los usuarios (aplicaciones) del mismo en
condiciones reales de trabajo.
Incremento de tráfico: La variación en el tráfico cursado entre los escenario 2 y 3 fue
del 860%, lo cual mide directamente lo que se incrementó el tráfico entre estos
escenarios. De los resultados obtenidos, se puede esperar que el sistema entregará
59
la información procesada en tiempo real a los usuarios (aplicaciones) del mismo en
condiciones reales de trabajo.
Los indicadores señalados indican que el modelo de Middleware es escalable para los
escenarios simulados; para simulaciones donde se requiera realizar una ampliación
importante en la cantidad de nodos sensores, se deberá prestar atención al monitoreo del
parámetro porcentaje de utilización de la CPU, cuyo valor se acercó más al umbral
propuesto.
5.2 Evaluación Cuantitativa
Para el indicador de latencia, la simulación mostró un promedio de tiempo de
procesamiento del Middleware para el escenario 2 de 1590 microsegundos y un valor pico
de 1628 microsegundos, mientras que para el escenario 3 se presentó un promedio de
2810 microsegundos y un valor pico de 2845 microsegundos (2,85 milisegundos).
Lo anterior representa un incremento entre los dos escenarios planteados de 1217
microsegundos (tomando los valores pico, que es el peor caso), lo cual equivale a un
incremento aproximado del 74,8%, y permite prever que el sistema se comportará en
condiciones reales de funcionamiento con un retardo muy inferior al umbral máximo de
270 milisegundos establecido en el numeral 4.3.1 de este documento, por lo que los
usuarios podrán percibir y considerar que los servicios ofrecidos por el sistema se prestan
en tiempo real.
En cuanto al indicador de escalabilidad, los resultados de los parámetros elegidos para
evaluarlo indirectamente fueron los siguientes:
Porcentaje de utilización de la CPU: el incremento en el número de nodos
equivalentes, representados en el escenarios 2 fue del 20% en promedio con picos
del 20,2%, mientras que para el escenario 3 este valor fue del 77% en promedio,
con picos del 77,7%, lo cual representa un incremento de este parámetro del 57.5%
para los valores pico (peor caso). En los escenarios simulados, no se excedió el
valor fijado en el numeral 4.3.2 de este documento para este parámetro, quedando
margen para un aumento del tráfico en condiciones más críticas de funcionamiento.
60
Tráfico caído (Dropped traffic): Este parámetro presentó un valor promedio de 4,2
paquetes por segundo con picos de 4,22 paquetes por segundo; para el escenario 3
estos valores fueron de 10,45 paquetes por segundo y 10,55 paquetes por segundo,
respectivamente. Esto representa un incremento del 250% de incremento entre
escenarios.
Dado que para el escenario 2 el valor pico de tráfico obtenido fue de 57 millones de
paquetes por segundo, y para el escenario 3 fue de 490 millones de paquetes por
segundo, los valores para el parámetro de tráfico caído fueron de 7,07x10-6% y
2,15x10-6%, respectivamente. Estos valores están muy por debajo del umbral fijado
en el numeral 4.3.2 de este documento.
Incremento de tráfico: Con respecto a este parámetro, los valores obtenidos para el
escenario 2 fueron de 50,6 Gbps en promedio y de 54 Gbps máximo; mientras que
para el escenario 3 estos valores fueron de 424,8 Gbps y 466 Gbps. Lo anterior
representa un incremento para los valores pico (peor caso) del 860%, lo cual mide
directamente el incremento del tráfico entre estos escenarios.
Los parámetros señalados indican que el modelo de Middleware es escalable para los
escenarios simulados. Es importante notar que para simulaciones donde se requiera
realizar una ampliación importante en la cantidad de nodos sensores, se deberá prestar
atención al monitoreo del parámetro porcentaje de utilización de la CPU, cuyo valor se
acercó más al umbral propuesto.
61
CONCLUSIONES Y TRABAJO FUTURO
El Middleware se refiere a un nivel que está localizado en la cima de los sistemas
operativos y las pilas de comunicaciones, donde esconde la heterogeneidad de las
aplicaciones a través de un conjunto de interfaces comunes bien definidas; en virtud de lo
anterior, ayuda a abstraer la distribución y hererogeneidad subyacente del ambiente
computacional y los servicios disponibles, además de soportar la adición de
características no funcionales como rendimiento, escalabilidad, confiabilidad,
disponibilidad, usabilidad, administrabilidad, QoS (Calidad de Servicio), eficiencia.
Para el diseño del modelo de arquitectura de Middleware propuesto en este documento,
se tuvo en cuenta el cumplimiento de las siguientes consideraciones: Heterogeneidad de
dispositivos, Interoperabilidad, Escalabilidad, Modularidad de programación,
Transparencia, y Formalización del entorno.
Para el diseño del Modelo de Arquitectura de Middleware propuesto, también se tuvo en
cuenta, que su capacidad se pudiese evaluar en términos de su poder para proveer la
información requerida de manera transparente, oportuna, y confiable; en esa misma
proporción debe medirse su pertinencia y aporte a un sistema de transporte público
masivo de pasajeros.
Considerando lo enunciado en las dos conclusiones anteriores, se eligieron para la
simulación dos indicadores: latencia y escalabilidad. Como parámetros para medir los
citados indicadores tomaron los parámetros de latencia, porcentaje de utilización de la
CPU, Tráfico caído (Dropped traffic), e incremento del tráfico.
Para la simulación del Middleware se recrearon tres escenarios de simulación, el primero
de los cuales sirvió como insumo para estimar el tráfico a recrear en los escenarios 2 y 3,
lo anterior ante las limitaciones encontradas a la hora de realizar las simulaciones,
particularmente en la cantidad máxima de nodos de la versión académica del OPNET
Modeler, cuyo valor máximo es de 80.
De los resultados obtenidos de la simulación se puede apreciar para los escenarios
propuestos que el retardo es un indicador que el diseño cumple sobradamente, ya que en
62
el peor de los casos su valor máximo fue de 2,85 milisegundos, mientras que el valor
umbral establecido fue de 270 milisegundos.
En cuanto al porcentaje de utilización de la CPU del servidor que tendrá implementado el
Middleware, se observa también que el diseño propuesto cumple, siendo así que en el
caso más crítico este parámetro alcanza un valor pico del 77,7%, valor inferior al umbral
establecido para los escenarios de simulación del 80%.
No obstante mencionado en la anterior conclusión, es necesario hacer dos observaciones:
la primera, que el factor de incremento del número equivalente de nodos entre el
escenario 2 y el escenario 3 es de 8,5, al pasar de 552 nodos en el primero a 4692 en el
segundo; si bien el resultado obtenido en los escenarios simulados permite predecir un
adecuado cumplimiento de este parámetro para una mayor cantidad equivalente de
nodos, este valor no se podrá incrementar en las proporciones simuladas en los
mencionados escenarios; la segunda es que la cantidad de nodos implementados en el
escenario 3, tiene un orden de magnitud similar a la infraestructura que actualmente
posee Transmilenio S.A., la cual se puede dimensionar con los siguientes datos: 2027
buses, 138 estaciones y 9 portales [43]. Esta última observación permite inferir que el
modelo de arquitectura de Middleware propuesto en este documento es adecuado para
suplir las necesidades para las cuales fue diseñado.
En cuanto al parámetro de tráfico caído (Dropped traffic), se logró un parámetro de varias
órdenes de magnitud inferiores al umbral planteado inicialmente, el cual es un requisito
importante para el cumplimiento del indicador de escalabilidad.
Finalmente, la cantidad de tráfico recreado en el escenario 3 corresponde a unas
condiciones similares en cuanto a volumen de información que deberá asumir y procesar
el Middleware en condiciones reales de funcionamiento. Esto permite concluir, junto con
los demás resultados obtenidos de los demás parámetros, que este modelo de
arquitectura de Middleware diseñado para este proyecto cumple con los requerimientos
mínimos necesarios para satisfacer las necesidades de un sistema de transporte urbano
de pasajeros real.
63
Como trabajo futuro está la armonización e integración de esta tesis con lo establecido en
el Plan de Desarrollo de la ciudad de Bogotá 2016-2020 [44], el cual en su numeral 4.2.6
indica que sólo el 19% de la ciudadanía reporta estar satisfecho con el transporte troncal,
foco de este trabajo de investigación. Entre los problemas asociados con esta situación
están la frecuencia, infraestructura, comunicación al usuario, y congestión, los cuales
pueden ser mitigados mediante la integración de plataformas tecnológicas y el desarrollo
de herramientas de información cuyo éxito depende en gran medida de un Middleware
que permita a desarrolladores de software diseñar e implementar aplicaciones que
contribuyan con la satisfacción de las necesidades los diferentes actores involucrados en
el tema del transporte público urbano de pasajeros.
El trabajo futuro también incluye el desarrollo e implementación del modelo de
arquitectura propuesto, necesarios para que se haga realidad la integración de ese
proyecto en el Plan de Desarrollo de la ciudad de Bogotá.
Finalmente, se deja para trabajo futuro la ampliación de la simulación a otros escenarios
más generales que el del sistema de transporte masivo Transmilenio, utilizando la versión
profesional del OPNET Modeler, que permite trabajar con características adicionales
como cantidad ilimitada de nodos que se pueden incluir en los escenarios de red a
simular.
64
REFERENCIAS BIBLIOGRÁFICAS
[1] Enerlis, Erns and Young, Ferrovial and Madrid Network, Libro Blanco Smart
Cities, Imprintia, 2012.
[2] Banco Mundial, «www.worldbank.com,» 2011. [En línea]. [Último acceso:
2011].
[3] Naciones Unidas,
«http://www.un.org/spanish/esa/sustdev/agenda21/agenda21toc.htm,» 2011.
[En línea]. [Último acceso: 2011].
[4] E. parliament, «http://ec.europa.eu/clima/policies/package/documentaction
en-htm,» 2009. [En línea]. Available:
http://ec.europa.eu/clima/policies/package/documentaction en-htm. [Último
acceso: Octubre 2014].
[5] J. V. L. M. J. M. P. L. H. G. a. J. P. J.M. Hernández-Muñoz, «Smart Cities at
the ForeFront of the Future Internet,» de The Fitire Inernet, Lecture Notes in
Computer Science, 2011.
[6] M. O. C. E. A. Mulligan, «Architectural implications of smart city business
models: an evolutionary perspective,» IEEE Communications Magazine, vol.
51, nº 6, pp. 80-85, 2013.
[7] IDAE, Observatorio tecnológico de la energía, «Mapa Tecnológico "Ciudades
Inteligentes",» 2012.
[8] European University instritute, «Think,» 2013. [En línea]. Available:
http://think.eui.eu. [Último acceso: Octubre 2014].
[9] CDTI, «European Innovation Partnership on Smart Cities,» 2012.
[10] F. Zhao y L. Guibas, Wireless Sensor Networks: An Information Processing
Approach, Palo Alto: Elsevier/Morgan-Kaufmann, 2004.
[11] E. Cheong, Actor-Oriented Programming for Wireless Sensor Networks,
Berkeley: University of California, 2007.
65
[12] P. Santi, Topology Control in Wireless Ad Hoc and Sensor Networks,
England: John Wiley & Sons Ltd., 2005.
[13] I. Stojmenovic, Handbook of Sensor Networks: Algorithms and
Architectures, Canadá: John Wiley & Sons, Inc., 2005.
[14] I. &. I. M. Mahgoub, Smart dust: sensor network applications, architecture,
and design., Florida, USA: Taylor & Francis Group, 2006.
[15] A. Asensio, A. Miguel y J. Pascual, Diseño de un simulador para redes de
sensores, Madrid: Facultad de Informática, Universidad Complutense de
Madrid., 2009.
[16] L. Fernández, J. M. Blasco, J. Hernández y E. Montón, Wireless Sensor
Networks in Ambient Intelligence, Valencia, 2006.
[17] N. y. C. p. S. Oficina de Coordinación Nacional de Posicionamiento,
«http://www.gps.gov/systems/gps/spanish.php,» 13 Mayo 2016. [En línea].
[Último acceso: 24 Junio 2016].
[18] L. Casanova Matera, «Sistema de Posicionamiento Global (G.P.S.),» de
Topografía Plana, Mérida, Taller de Publicaciones de Ingeniería, ULA, 2002,
pp. 10-1 - 10-11.
[19] J. C. y. o. Alexis Vásquez,
«https://www.researchgate.net/publication/282769206_Documento_de_Invest
igacion_sobre_el_Sistema_GPS_y_su_fundamento_matematico,» Junio
2014. [En línea]. Available:
https://www.researchgate.net/publication/282769206. [Último acceso: 24
Junio 2016].
[20] U. d. Valladolid, «Introducción a los Sistemas Distribuidos,» Valladolid,
2005.
[21] A. S. Méndez, «Técnicas Avanzadas de Middleware,» Madrid, 2005.
[22] N. M. Jameela Al-Jaroodi, «Service-oriented middleware: A survey,» Journal
of Network and Computer Applications, nº 35, pp. 211-220, 2011.
[23] H. M. Qusay, Middleware for Communications, John Wiley & Sons, 2003.
66
[24] P. Bellavista y A. Corradi, The Handbook of Mobile Middleware, John Wiley
& Sons, 2006.
[25] A. Rasche, «Adaptive and Reflective Middleware,» [En línea]. Available:
http://www.dcl.hpi.uni-potsdam.de/teaching/mds_07/mds10_adaptivemw.pdf.
[Último acceso: 15 Junio 2015].
[26] E. Tsekleves, J. Cosmas, A. Aggoun y J. Loo, «Converged Digital TV
Services: The Role of Middleware and Future Directions of Interactive
Television,» Junio 2009. [En línea]. Available:
http://www.hindawi.com/journals/ijdmb/2009/643680/. [Último acceso:
Diciembre 2015].
[27] Gartner Report, «Who’s Who in Middleware,» 2004. [En línea]. Available:
http://www-01
.ibm.com/software/info/websphere/partners4/articles/gartner/garwho.html#fig
1, 2004.
[28] W. W. a. o. Gang Huang, «Simulation-based analysis of middleware service
impact on system reliability: Experiment on Java application server,» The
Journal of Systems and Software, nº 84, pp. 1160-1170, 2011.
[29] M. W. e. al, «Middleware for Wireless Sensor Networks: A Survey,» Mayo
2008. [En línea]. Available: http://www.ccf.org.cn/web/resource/8301.pdf.
[Último acceso: Enero 2016].
[30] M. Li y T. Lee, «Middleware for Sensor Network,» [En línea]. Available:
http://www.eecg
.toronto.edu/~jacobsen/courses/ece1770/slides/snetworks.ppt. [Último acceso:
Enero 2016].
[31] B. Schilit, N. Adams y R. Want, «Context-Aware Computing Applications,»
1995. [En línea]. Available: IEEE Workshop on Mobile Computing Systems
and Applications. [Último acceso: Diciembre 2015].
[32] H. Zhou, The Internet of Things in the Cloud A Middleware Perspective,
CRC Press, 2012.
[33] SETIS, «European Comission, sistema de información SETIS,» 2012. [En
línea]. Available: http://setis.ec.europa.eu/about-setis/technology-
roadmap/european-initiative-on-smart-cities. [Último acceso: Octubre 2015].
67
[34] Civitas Initiative, «Civitas Initiative,» 2012. [En línea]. Available:
www.civitas-initiative.org. [Último acceso: Septiembre 2014].
[35] KPMG, «Socio-economic impact assesment of the SmartCity (Malta)
project,» 2007.
[36] Ayuntamiento de Málaga, [En línea]. Available:
http://www.socinfo.es/contenido/seminarios/smart5/malaga.pdf. [Último
acceso: Enero 2016].
[37] L. N. Hoang, «Middlewares for Home Monitoring and Control,» 2007. [En
línea]. Available:
http://www.tml.tkk.fi/Publications/C/23/papers/NguyenHoang_final.pdf.
[Último acceso: Diciembre 2015].
[38] M.-M. W. e. al., «Middleware for Wireless Sensor Networks: A Survey,»
Journal of Computer Science and Technology, vol. 23, nº 3, pp. 305-326,
2008.
[39] S. Tong, «An Evaluation Framework for Middleware Approaches on Wireless
Sensor Networks,» 27 Abril 2009. [En línea]. Available: http://www.cse.tkk
.fi/en/publications/B/5/papers/tong_final.pdf. [Último acceso: Diciembre
2015].
[40] Riverbed, «OPNET Modeler,» [En línea]. Available:
http://www.opnet.com/services/university/. [Último acceso: Diciembre 2015].
[41] J. L. y. F. D. R. G. Lucas Guaycochea, «Middleware P2P para la
sincronización de eventos discretos en una simulación distribuida de sistemas
que evolucionan en el tiempo,» de XVIII Congreso Argentino de Ciencias de
la Computación, Buenos Aires, 2012.
[42] I. E. S. A. A. K. Suleyman Cakici, «A Novel Cross-layer Routing Protocol for
Increasing Packet Transfer Reliability in Mobile Sensor Networks,» de
Wireless Personal Communications, New York, 2014.
[43] T. S.A., «http://www.transmilenio.gov.co/es/articulos/historia,» 30 Junio
2016. [En línea]. [Último acceso: 14 Julio 2016].
[44] A. M. d. Bogotá, «http://www.sdp.gov.co,» Alcadía Mayor de Bogotá D.C.,
19 Abril 2016. [En línea]. Available:
68
http://www.sdp.gov.co/portal/page/portal/PortalSDP/PlanDistritalDesarrollo/
Documentos/20160429_proyecto_PDD.pdf. [Último acceso: 14 Julio 2016].
