Cuadernos Tecnológicos de la PTC

Nº 05/ 2014

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020 Autores: J. Torres Arjona, M. Quintana González, A. Cerezo Beltrán, C. Bravo Hernández, J.M. Menéndez García GaTV - Universidad Politécnica de Madrid

Con la colaboración especial de Indra Sistemas

P L ATA F O R M A T E C N O L Ó G I C A E S PA Ñ O L A D E L A C A R R E T E R A ( P T C )

© Plataforma Tecnológica Española de la Carretera (PTC). Goya, 23 - 3º, 28001 Madrid. Reservados todos los derechos. ISBN: XXX-XX-XXX-XXXX-X.

LA COLECCIÓN “CUADERNOS TECNOLÓGICOS DE LA PTC” La Plataforma Tecnológica Española de la Carretera (PTC) es el foro de encuentro apoyado por el Ministerio de Economía y Competitividad para todos los agentes del sistema cienciatecnología-empresa con un papel relevante en el fomento del empleo, la competitividad y el crecimiento en el sector de las infraestructuras viarias en España. Desde su presentación en sociedad en febrero de 2010, la PTC trabaja como una plataforma transversal que fomenta el intercambio fluido de información y las discusiones a nivel tecnológico entre los agentes privados y públicos del sector, con el objeto de contribuir a que España se convierta en el referente mundial en materia de tecnologías asociadas a la carretera. La colección de publicaciones “Cuadernos Tecnológicos de la PTC” surge de los convenios de colaboración que la Plataforma mantiene con un importante número de instituciones académicas activas en la I+D+i en materia de infraestructuras viarias. Cada Cuaderno se incardina dentro de alguna o varias de las temáticas y sub-temáticas de la vigente Agenda Estratégica de Investigación de la Carretera en España (2011-2025).

3

Colección de Cuadernos Tecnológicos de la PTC Año 2013 01/2013: Técnicas avanzadas de fusión de información de fuentes heterogéneas para la extracción de información de movilidad en carreteras 02/2013: Software para la explotación de datos LiDAR en carreteras 03/2013: Desarrollo de una metodología de análisis del coste de ciclo de vida 04/2013: Carga tarifaria y fiscal del transporte por carretera: un análisis comparado entre E.E.U.U. y Europa 05/2013: Captación de energía en carretera: colectores solares asfálticos 06/2013: Nuevo proceso de diseño geométrico para unas carreteras convencionales más seguras 07/2013: Informe del estado del arte sobre el factor humano en la conducción 08/2013: Optimización del uso de las carreteras existentes 09/2013: Diseño de estación de carga para vehículos eléctricos mediante energías renovables

Año 2012 01/2012: Análisis del Megatruck en España 02/2012: Conceptualización del transporte sostenible desde el comportamiento prosocial 03/2012: Consideraciones para la modificación de los límites de la velocidad en base a la accidentalidad 04/2012: Extrapolación de materiales viarios 05/2012: Gestión de la mejora de la movilidad 06/2012: Influencia de la meteorología adversa sobre las condiciones operacionales del tráfico y recomendaciones para la localización de sensores de variables atmosféricas 07/2012: Membranas flexibles ancladas al terreno para la estabilización de taludes en carreteras 08/2012: Priorización de actuaciones sobre accidentes de tráfico mediante reglas de decisión 09/2012: Sistemas lidar móvil para el inventario geométrico de carreteras

Año 2011 01/2011: Los retos de “Sistemas de adquisición de información de tráfico: estado actual y futuro” 02/2011: Los retos de “Firmes Permeables” 03/2011: Los retos del “Sistema fotogramétrico para la medición remota de estructuras en programas de inspección de puentes” 04/2011: Los retos de “Pago por uso de las infraestructuras viarias: Estudio de los accesos a Madrid” 05/2011: Los retos del “Sistema eCall: Situación actual y estándares” 06/2011: Los retos de “La velocidad de operación y su aplicación en el análisis de la consistencia de carreteras para la mejora de la seguridad vial” 07/2011: Los retos de “Desarrollo de una metodología de análisis de ciclo de vida integral específica para carreteras” 08/2011: Los retos de “Control pasivo de velocidad: intervención en tramos de acceso a entornos urbanos”

5

Para cualquier información adicional, contacte con [email protected] o visite www.ptcarretera.es

Cuaderno Tecnológico de la PTC Nº 05/2014

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020 Autores: R. V. J. Torres Arjona, M. Quintana González, A. Cerezo Beltrán, C. Bravo Hernández, J.M. Menéndez García G@TV – Universidad Politécnica de Madrid Temáticas: Agenda Estratégica de Investigación de la Carretera en España (2011-2025)

Sub-temáticas: Desarrollo de aplicaciones que consigan la sinergia de los datos suministrados por el equipamiento ITS ya instalado en la infraestructura viaria en España

ITS y movilidad

Optimización del uso de las infraestructuras de carreteras existentes Suministro al usuario de información de calidad y a tiempo real sobre alternativas de desplazamiento dentro de la red de carreteras, en el transporte público y en otros modos de transporte

Transporte e Fomento de la cooperación entre los modos de transporte intermodalidad

En colaboración con:

Resumen Dentro del proyecto INNPRONTA Ciudad 2020 se están llevando a cabo varias líneas de investigación respecto a la movilidad en las smart cities focalizando los esfuerzos en una mejora de los servicios prestados al ciudadano. En este cuaderno se realiza una exploración de dichas líneas, analizando el estado de la tecnología actual y las oportunidades que se ofrecen en el corto plazo. De este modo, se abordan temas como la creación de un servicio de rutas intermodales que fomenta el uso de los medios de transporte menos contaminantes y que integra información proporcionada por el ciudadano a través de las redes sociales, la definición de una plataforma interoperable para el pago de servicios de movilidad y un servicio de información de plazas libres de aparcamiento que fomenta el cambio intermodal.

Índice

Índice������������������������������������������������������������������������������������������������������������������������ 9 1. Introducción........................................................................................................13 2. Servicio de rutas intermodales...........................................................................17 2.1. Centro Intermodal Virtual�������������������������������������������������������������������������� 17 2.1.1. Arquitectura y fuentes de datos������������������������������������������������������� 19 2.2. Creación de rutas��������������������������������������������������������������������������������������� 22 2.2.1. Generación del grafo������������������������������������������������������������������������ 24 2.2.2. Algoritmo de cálculo de ruta������������������������������������������������������������ 25 3. Plataforma interoperable de pago.....................................................................31 3.1. Arquitectura física�������������������������������������������������������������������������������������� 34 3.2. Desarrollo del caso práctico����������������������������������������������������������������������� 36 3.2.1. Cliente����������������������������������������������������������������������������������������������� 37 3.2.2. Servidor��������������������������������������������������������������������������������������������� 39 3.2.3. Punto de acceso�������������������������������������������������������������������������������� 41 4. Monitorización de zonas de aparcamiento........................................................43 4.1. Módulo de Inicialización.���������������������������������������������������������������������������� 44 4.2. Calibración�������������������������������������������������������������������������������������������������� 45 4.3. Módulo de detección de objetos de interés (Sustracción de fondo)���������� 46 4.4. Asociación de blobs y seguimiento������������������������������������������������������������ 46 9

4.5. Módulo de control de oclusiones����������������������������������������������������������������47 4.6. Detección de aparcamiento/liberación de plaza����������������������������������������47 4.7. Caracterización de plazas y presentación���������������������������������������������������47 4.8. Adaptación a transición noche/día y día/noche�����������������������������������������49 5. Conclusiones.......................................................................................................53 6. Agradecimientos.................................................................................................57 7. Bibliografía y referencias....................................................................................59 8. Índice de figuras..................................................................................................63 9. Glosario...............................................................................................................67

11

1. Introducción

La masificación en los entornos urbanos crea enormes problemas para la movilidad de las personas y mercancías. Además de las consecuencias económicas y de confort de los ciudadanos, la emisión de gases de efecto invernadero se incrementa notablemente. Por ello, la reducción de las congestiones y el uso de medios de transporte más ecológicos se establecen como objetivos prioritarios dentro del marco de investigación internacional. Las posibles soluciones pasan por la implantación de estrategias que permitan optimizar el uso de las infraestructuras y estimular un cambio hacia modos de transporte más sostenibles y limpios, logrando un sistema de transporte más competitivo y eficiente en el uso de los recursos. Con estos objetivos, el proyecto INNPRONTA Ciudad 2020 [1] ha trabajado para ofrecer herramientas y estrategias de gestión apoyadas en las Tecnologías de la Información y las Comunicaciones (TIC), que permitan hacer un uso de los recursos más adaptado a las necesidades reales de la ciudad, así como influir sobre las decisiones de los usuarios, orientándolos hacia una movilidad urbana más sostenible. En esta línea, el proyecto apuesta por promover y facilitar la intermodalidad, buscando una reducción en el consumo energético y las emisiones. Para ello se proponen nuevas soluciones tecnológicas, basadas en los Sistemas Inteligentes de Transporte (Intelligent Transportation Systems -ITS-) y el Internet de las Cosas (Internet of Things -IoT-), consistente en que cualquier dispositivo electrónico puede ser accesible desde cualquier lugar. Las soluciones ITS se basan en la captación y tratamiento de información relacionada con el transporte y el desarrollo de servicios para un uso más eficiente de la infraestructura. Dichos servicios están principalmente orientados a mejorar la movilidad del ciudadano, que se establece como una pieza clave tanto para recibir información como para proveerla, creándose lo que se ha llamado, la figura del sensor ciudadano. Además, también se presentan como son herramientas para el operador que le ayudan a gestionar de forma más eficiente la demanda, orientándola hacia un uso más sostenible del los transporte. En este cuaderno se realiza una exploración de algunas de las líneas más relevantes, analizando el estado de la tecnología actual y las oportunidades que se ofrecen en el corto plazo. De este modo, se abordan temas como la creación de un servicio de rutas intermodales que fomenta el uso de los medios de transporte menos contaminantes y que integra información proporcionada por el ciudadano a través de las redes sociales, la definición de una plataforma interoperable para el pago de servicios de movilidad y un servicio de información de plazas libres de aparcamiento que fomenta el cambio 13

Cuaderno Tecnológico de la PTC

Nº 05/ 2014

intermodal. Estas líneas pueden ser combinadas para ofrecer soluciones globales de movilidad en las ciudades del futuro. El resto del cuaderno está organizado como sigue: • En el capítulo 2 se describe el servicio de rutas intermodales. Por una parte de explica qué tipo de datos utiliza y cómo son recolectados e integrados. Por otra parte se describe cómo se generan los mapas y cómo se calculan los distintos tipos de rutas, • El capítulo 3 aborda el diseño y desarrollo de una plataforma interoperable de pago. Dicha plataforma combina el pago de distintos servicios de movilidad utilizando un mismo medio de pago y validación. • En el capítulo 4 se describe un sistema de monitorización de plazas de aparcamiento basado en Visión Artificial y válido para lugares con plazas delimitadas y no delimitadas. • A modo de conclusión, en el capítulo 5 se hace un análisis de las oportunidades que se abren tras la presentación de estos servicios y se realizan algunas indicaciones relativas a su futura implantación.

14

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

15

2. Servicio de rutas intermodales

El objetivo global del servicio planteado en Ciudad 2020 consiste en proporcionar al ciudadano la ruta intermodal más eficiente en términos temporales y ecológicos, buscando tanto el beneficio de cada ciudadano como el de la ciudad. La ruta calculada incluye distintos medios de transporte (vehículo privado, autobús, metro, caminar…) y tiene en cuenta diversa información en tiempo real, como horarios y rutas del transporte público, disponibilidad de aparcamientos, eventos detectados en la ciudad etc. Este servicio utiliza información de movilidad heterogénea que es gestionada en un Centro Intermodal Virtual (CIV) (sección 2.1). Dicho centro es capaz de integrar información heterogénea de diversas fuentes: desde información proveniente de sensores y cámaras, hasta información publicada como Open Data. El tipo de información está relacionado con la movilidad de los vehículos privados, líneas de transporte urbano, incidencias y zonas de aparcamiento tanto de vehículos privados como de bicicletas. La solución propuesta busca facilitar al usuario el uso de diferentes medios de transporte públicos y privados para realizar un trayecto, fomentando la intermodalidad y el uso del transporte público, incluyendo funcionalidades como la de “Park & Ride” [2]. Para la implementación del servicio se ha hecho uso de herramientas de software libre, principalmente Open Street Maps (OSM) [3] para el uso de mapas y Open Trip Planner (OTP) [4] para el cálculo de las rutas óptimas (sección 2.2). Para poder hacer uso de datos no proporcionados por OTP, se necesita construir previamente un grafo compuesto por un conjunto de objetos llamados vértices o nodos unidos por enlaces llamados aristas o arcos, que permiten representar relaciones binarias entre elementos de un conjunto correspondiente. En este caso, este grafo relaciona las relaciones mediante uno o varios tipos de transporte, en los diferentes puntos del entorno urbano. Este grafo se construye a través de datos de diferente índole, como se puede apreciar en Figura 1.

2.1. Centro Intermodal Virtual El CIV es el encargado de integrar y monitorizar toda la información necesaria para alimentar herramientas y servicios desplegados en el proyecto, incluyendo el servicio de rutas intermodales. El CIV integra información de diversas fuentes: sensores de movilidad y medioambientales, cámaras, datos de tráfico, información del transporte público,

17

Cuaderno Tecnológico de la PTC

Nº 05/ 2014

Figura 1. Construcción del grafo (Fuente [1])

Figura 1. Construcción del grafo (Fuente [1])

datos proporcionados por operadores de forma directa o a través de Open Data y datos proporcionados por el ciudadano. 2.1. Centro Intermodal Virtual El CIV sirve también de centro de monitorización de datos a disposición de: • ElLos operadores y autoridades de ylamonitorizar ciudad, para que usen como apoyo para para una CIV es el encargado de integrar toda la las información necesaria gestión inteligente deylaservicios movilidad. alimentar herramientas desplegados en el proyecto, incluyendo el servicio de rutas intermodales. El CIV integra información de diversas fuentes: sensores de

• movilidad Los ciudadanos, que la tendrán en cuenta a ladehora de planificar susdel desplazamientos, y medioambientales, cámaras, datos tráfico, información transporte permitiéndoles tomar mejores decisiones, como por ejemplo evitar público, datos proporcionados por operadores de forma directa o a travéslas de zonas Open más congestionadas o con incidencias. Data y datos proporcionados por el ciudadano. El CIV sirve también de centro de monitorización de datos a disposición de:  Los operadores y autoridades de la ciudad, para que las usen como apoyo para una gestión inteligente de la movilidad. 18  Los ciudadanos, que la tendrán en cuenta a la hora de planificar sus desplazamientos, permitiéndoles tomar mejores decisiones, como por ejemplo evitar las zonas más congestionadas o con incidencias.

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

Diagrama del CIV (Fuente [1]) Figura 2. Diagrama del CIV Figura (Fuente2.[1])

diferenciasen enlos losmodelos modelos de de de los los mercados y modelos de de LasLas diferencias de transporte, transporte,situación situación mercados y modelos negocio hacen los dominios que seestos alojan estos datos de diversa sean negocio hacen queque los dominios en losen quelos se alojan datos de diversa naturaleza naturaleza sean lo que complica encontrar solución que las abarque muy diferentes, lo muy que diferentes, complica encontrar una solución queuna abarque todas entidades todas las entidades que componen el entorno y que pueda implantada en cualquier que componen el entorno y que pueda ser implantada en ser cualquier escenario. escenario. esa razón,seseplanteó planteó la la posibilidad infraestructura común basada en en PorPor esa razón, posibilidadde decrear crearuna una infraestructura común basada estándares no discriminativos e interoperables, que sirviera para y facilitar y estándares no discriminativos e interoperables, que sirviera para facilitar homogeneizar homogeneizar las comunicaciones correspondientes entre operadores, distintos las comunicaciones correspondientes entre operadores, distintos proveedores de datos proveedores de datos y servicios, y usuarios.

y servicios, y usuarios.

El resto de la sección ofrece unas pinceladas sobre la arquitectura que sustenta el CIV El resto de la ofrece pinceladas la arquitectura que sustenta el CIV así así como lossección datos que son unas integrados y cómosobre se realiza esta integración.

como los datos que son integrados y cómo se realiza esta integración. 2.1.1. Arquitectura y fuentes de datos

2.1.1. Arquitectura y fuentes de datos El objetivo de este centro de datos da lugar

a plantearse una serie de requisitos en relación al tipo de arquitectura que debe utilizarse. Así, ésta ser abierta, modular, El objetivo de este centro de datos da lugar a plantearse una serie de requisitos en relación orientada a servicios, escalable y segura. Además, debe ser capaz de adoptar al tipo de arquitectura que debe utilizarse. Así, ésta ser abierta, modular, orientada a protocolos estándar para la intercomunicación tanto a nivel de equipamiento como a servicios, escalable y segura. Además, debe ser capaz de adoptar protocolos estándar nivel de compartición de información.

para la intercomunicación tanto a nivel de equipamiento como a nivel de compartición de información. Para cumplir estos requerimientos, la Arquitectura Orientada a Servicio, o SOA

(Service Oriented Architecture) se presenta como la mejor alternativa. SOA permite la Para cumplir requerimientos, la Arquitectura Orientada a Servicio, o SOA (Service creación deestos sistemas altamente escalables que reflejan el negocio de la organización Oriented Architecture) mejor alternativa. SOA permite la creación que gestione el CIV. seApresenta su vez como brindalauna forma bien definida de exposición e de sistemas altamente escalables reflejan el negocio de la organización quepropios gestione el invocación de servicios, lo cualque facilita la interacción entre diferentes sistemas CIV. A terceros su vez brinda una forma bien definida de exposición e invocación de servicios, lo o de

cual facilita la interacción entre diferentes sistemas propios o de terceros En relación a los datos que se integran dentro del CIV, se incluyen:

 Datos propios de los operadores de transporte público: horarios, frecuencias de19 paso, recorrido etc.  Datos de sensores/equipamiento instalados en la infraestructura: por ejemplo de cámaras, espiras, sensores de aparcamiento.

del CIV.

Cuaderno Tecnológico de la PTC

Nº 05/ 2014

3. Fuentes datos utilizadas en la implementación (Fuente [1]) Figura 3. Figura Fuentes de datosdeutilizadas en la implementación del del CIVCIV (Fuente [1])

A modo de ejemplo, de OpenData, el CIV automatizar la ingesta En relación a los datospara que elsecaso integran dentro del CIV,permite se incluyen:

• •

de datos de transporte publicados por el Ayuntamiento de Zaragoza en JSON1, y su adaptación al modelo datos usadode en transporte el CIV. Este proceso la construcción y de paso, Datos propios de losdeoperadores público:incluye horarios, frecuencias compilación de un archivo GTFS [5] o la inserción de los datos de aparcamientos recorrido etc. públicos, zonas de estacionamiento regulado y la geolocalización de aparcamientos de bicicletas. ellos son leídos de los datos publicados por el Ayuntamiento Datos de Todos sensores/equipamiento instalados en la infraestructura: por de ejemplo de Zaragoza en formato JSON para, posteriormente, adaptarlos al servicio requerido. cámaras, espiras, sensores de aparcamiento.

• Datos de Open Data: publicados por instituciones públicas o comunidades de aficionados 1 http://www.zaragoza.es/ciudad/risp/buscar_Risp para facilitar su acceso a terceros. En caso de que no se disponga de datos propios de transporte, se pueden obtener a través de Open Data si la autoridad en cuestión lo publica en ese formato. 10 • Datos de redes sociales, como Twitter, Foursquare, etc. Que ofrecen información sobre movilidad, así como semántica. • Datos de sensor ciudadano: además de a través de las redes sociales, los ciudadanos pueden generar información sobre el uso que hace del transporte público (a través de aplicaciones móviles o uso de su tarjeta de transporte/ciudadana), su posición GPS, destino, etc. • Otras fuentes de datos que aporten información relevante para la movilidad de la ciudad, por ejemplo meteorología, datos medioambientales, incidencias reportadas etc. En la Figura 3 se representan las fuentes de datos utilizadas para la implementación del CIV. 20

una API de Twitter [6]. A partir de la concentración de los últimos es posible inferir el nivel de congestión de una determinada zona. Retos de movilidad en las de ciudades inteligentes. El caso de Ciudad 2020el En ylaoportunidades Figura 4 se puede ver la urbana información utilidad para Ciudad 2020 que publica Ayuntamiento de Zaragoza, que se puede usar en el servicio de rutas.

Figura 4. Esquema de datos públicos de Zaragoza (Fuente [1])

Figura 4. Esquema de datos públicos de Zaragoza (Fuente [1])

En lo que respecta apara los datos recogidos directamente la infraestructura, dentro del de A modo de ejemplo, el caso de OpenData, el CIV de permite automatizar la ingesta 1 proyecto se hizo especial hincapié el uso de algoritmos de Visión Artificial la datos de transporte publicados por elen Ayuntamiento de Zaragoza en JSON , y supara adaptación de información de proceso la vía a partir delaimágenes recogidas por al obtención modelo deautomática datos usado en el CIV. Este incluye construcción y compilación queGTFS pueden estar ya infraestructuraspúblicos, con fineszonas de de decámaras, un archivo [5] oincluso la inserción deinstaladas los datosen delaaparcamientos control o seguridad. Se desarrollaron algoritmos para la recogidadede parámetros de ellos estacionamiento regulado y la geolocalización de aparcamientos bicicletas. Todos tráfico (intensidad, densidad, velocidad etc), seguimiento de trayectorias deJSON son leídos de los datos publicados por elmedia, Ayuntamiento de Zaragoza en formato peatones y bicicletas,adaptarlos detección de la congestión en intersecciones y detección de la para, posteriormente, al servicio requerido. ocupación de plazas libres (Capítulo 4).

También se obtienen por este medio otros datos más directamente relacionados con el estado del tráfico, como pueden ser las incidencias en las vías y los niveles de densidad vez en hemos analizado se tránsito, obtienen las de información que se tienen deUna tráfico las zonas concómo mayor así fuentes como datos sociales mediante una API en cuenta para el cálculo de las rutas intermodales, pasamos a describir el algoritmo de Twitter [6]. A partir de la concentración de los últimos es posible inferir el nivel de de cálculode desarrollado. congestión una determinada zona. 2.2. Creación de rutas En la Figura 4 se puede ver la información de utilidad para Ciudad 2020 que publica el La herramienta utilizada para del en servicio (OTP)dees una plataforma de Ayuntamiento de Zaragoza, quelasecreación puede usar el servicio rutas.

código abierto para la generación de rutas multimodales y multiagente. Frente a otras que se han en el proyecto, como PGRouting [7], esta plataforma Enplataformas lo que respecta a losanalizado datos recogidos directamente de la infraestructura, dentro presenta la ventaja de que ofrece flexibilidad a la hora de tener en cuenta nodos de del proyecto se hizo especial hincapié en el uso de algoritmos de Visión Artificial para público-privado. Es decir, permite indicar el usuario aparcar por la intercambio obtención automática de información de la vía adónde partirpuede de imágenes recogidas su coche o pueden bicicleta incluso y enlazar conyatransporte lo que es fundamental para el cámaras, que estar instaladaspúblico, en la infraestructuras con fines de control de un servicio comprometido con la sostenibilidad energética medioambiental. o éxito seguridad. Se desarrollaron algoritmos para la recogida dey parámetros de tráfico

(intensidad, velocidad media, etc), seguimiento de trayectorias de peatones El servicio densidad, desarrollado sigue una arquitectura cliente servidor, ofreciendo diferentes y bicicletas, de la en API intersecciones y detección deaplicaciones la ocupación de interfaces detección web basados encongestión mapas y una REST [8] para el uso de plazas librescomo (Capítulo 4). externas la presente. En la Figura 5 se pueden observar los diferentes 1

11

http://www.zaragoza.es/ciudad/risp/buscar_Risp 21

dentro de la misma. La segunda aporta servicios para que el usuario pueda realizar consultas geolocalizadas respecto a elementos de interés para el mismo, ó pueda demandar rutas entre dos puntos. Esta segunda capa también se comunica con la Cuaderno Tecnológico de laque PTCel usuario final pueda realizar sus peticiones y visualizar Nº 05/ aplicación cliente para los 2014 resultados correspondientes.

Figura 5. Diagrama de componentes de la plataforma OTP Figura 5. Diagrama de componentes de la plataforma OTP

Una vezesto hemos analizadofacilitar cómo se lasde fuentes de información que se tienen Con se pretende la obtienen adaptación la plataforma a los diferentes enescenarios cuenta para las rutas intermodales, pasamos a describir algoritmo en el loscálculo que se de puede desplegar. Por un lado se facilita la creacióneldel grafo de cálculo desarrollado. correspondiente a la zona o ciudad elegida, y por otro se facilita un cliente web ya empaquetado para poder realizar las pruebas iniciales.

2.2. EnCreación la Figura 6de se rutas puede observar el diagrama de colaboración en el que se muestran

los mensajes intercambiados entre los diferentes objetos que intervienen en el proceso Ladel herramienta utilizada cálculo de una ruta: para la creación del servicio (OTP) es una plataforma de código

abierto para la generación de rutas multimodales y multiagente. Frente a otras plataformas que se han analizado en el proyecto, como PGRouting [7], esta plataforma presenta la ventaja de que ofrece flexibilidad a la hora de tener en cuenta nodos de intercambio público-privado. Es decir, permite indicar dónde puede el usuario aparcar su coche o bicicleta y enlazar con transporte público, lo que es fundamental para el éxito de un servicio comprometido con la sostenibilidad energética y medioambiental. 12

El servicio desarrollado sigue una arquitectura cliente servidor, ofreciendo diferentes interfaces web basados en mapas y una API REST [8] para el uso de aplicaciones externas como la presente. En la Figura 5 se pueden observar los diferentes componentes que 22

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

Figura 6. Diagrama de colaboración OTP Figura 6. Diagrama de colaboración OTP En el mismo se puede apreciar un objeto principal en medio a partir del cual se despliegan el resto: JourneyPattern. Inicialmente el usuario especifica origen y destino que son almacenados en Se annotatedStopPoint quedos se encarga decuanto almacenar los nodos intervienen en el sistema. pueden diferenciar partes en al funcionamiento la base de datos más cercanos a los señalados por el usuario en el mapa. Cuando deen la misma: esta información llega a JourneyPatter se genera un objeto ruta con una referencia y el en la la que se va a calcular A partir de ahí el objeto principal consulta las 1. área API para colección de datoslaomisma. capa de persistencia. diferentes opciones tanto en cuanto a servicios públicos de transporte como a privados. estasoopciones se generan muchas posibilidades que serán 2. vehículos API para cubrir los Con servicios capa de funcionalidad. analizadas mediante una función heurística y un algoritmo de búsqueda que serán posteriormente en la de sección 2.2.2. naturaleza principalmente asociados a la Laexplicados primera se nutre de datos diferente

geolocalización de ladel ciudad 2.2.1. Generación grafointeligente y la colección de datos interés para el usuario dentro de la misma. La segunda aporta servicios para que el usuario pueda realizar consultas Como se vio respecto en la introducción de este capítulo,para es necesario datos de rutas geolocalizadas a elementos de interés el mismo, generar ó puedalos demandar transporte para que sistemacapa pueda accederseacomunica la información la zona en la quepara se que entre dos puntos. Estaelsegunda también con ladeaplicación cliente desea generar la ruta. Para ello suelen utilizar los siguientes datos: correspondientes. el usuario final pueda realizar sussepeticiones y visualizar los resultados 

La de transporte público contenida en los ficheros GTFS.



Datos de elevación (opcional, solo para Estados Unidos).

Con esto se pretende facilitar la adaptación de la plataforma a los diferentes escenarios en  La de las calles aportada por el mapa OSM y/o por un fichero shapefile (Figura los que se puede desplegar. Por un lado se facilita la creación del grafo correspondiente a 7). Éste es un formato vectorial de almacenamiento digital donde se guarda la la zona o localización ciudad elegida, y por otro segeográficos facilita un cliente web yaasociados empaquetado para poder de los elementos y los atributos a ellos. realizar las pruebas iniciales. En la Figura 6 se puede observar el diagrama de colaboración en el que se muestran los mensajes intercambiados entre los diferentes objetos que intervienen en el proceso del cálculo de una ruta. 23

Cuaderno Tecnológico de la PTC

Figura 7. Ejemplo de shapefile

Nº 05/ 2014

Figura 7. Ejemplo de shapefile

Los principales tipos de datos que se permiten almacenar en el grafo son los siguientes:

En el mismo se puede apreciar un objeto principal en medio a partir del cual se despliegan el resto: JourneyPattern. Inicialmente el usuario especifica origen y destino que son 1. Anotaciones comunes, referentes a permisos, seguridad de bicicletas, almacenados en annotatedStopPoint oclusiones por pendiente, etc. que se encarga de almacenar los nodos en la base de datos más cercanos los señalados el usuario en el mapa.elCuando esta información 2. Segmentos de acalles, donde sepor entiende por segmentos tramo de calle entre llega a JourneyPatter se genera un objeto conseuna referencia y el áreaque en alasu que se dos intersecciones consecutivas. Lasruta calles dividen en segmentos, vez la son agrupados ende caminos, si sonprincipal segmentos de calle que comparten va a calcular misma. A partir ahí el objeto consulta las diferentes opciones varios atributos en el mapa OSM. tanto en cuanto a servicios públicos de transporte como a vehículos privados. Con estas 3. Permisos, define qué posibilidades tipos de usuarios pueden atravesarmediante qué segmentos. opciones se generan muchas que serán analizadas una función Ejemplo: un atributo puede hacer que un segmento pueda ser atravesado heurística y un algoritmo de búsqueda que serán explicados posteriormente en lasolo sección por una bici en una dirección. Los permisos existentes son los siguientes: 2.2.2.  NONE (Ninguno)  ALL del (Todos) 2.2.1. Generación grafo  PEDESTRIAN (Peatón)  laBICYCLE (Bicicleta) Como se vio en introducción de este capítulo, es necesario generar los datos de transporte  PEDESTRIAN_AND_BYCICLE (Peatón y bicicleta) para que el sistema pueda acceder a la información de la zona en la que se desea generar  PEDESTRIAN_AND_CAR (Peatón y coche) la ruta. Para ello se suelen utilizar los siguientes datos:  BICYCLE_AND_CAR (Bicicleta y coche)  CAR (Coche)

• La de transporte público contenida en los ficheros GTFS.

4. Seguridad de bicicletas, donde se define la seguridad de un segmento para

• La de las calles Un aportada por estándar el mapa OSM fichero (Figura 7). Éste ciclistas. segmento tiene y/o un por valorunde 1, las shapefile más seguras están entre 0 y 1 y las más por encima de 1.donde se guarda la localización de es un formato vectorial deinseguras almacenamiento digital Los datosgeográficos de pendientes de un origen que no tiene en cuenta la red los5.elementos y losvienen atributos asociados a ellos. formada a diferentes elevaciones en la calle en cuestión. Por ejemplo, se puede poner a 0 en algunos segmentos que no están en el suelo.

• Datos de elevación (opcional, solo para Estados Unidos). 2.2.2. Algoritmo de cálculo de ruta

Los principales tipos de datos que se permiten almacenar en el grafo son los siguientes: La plataforma OTP utiliza el algoritmo de búsqueda A* [9]. Los algoritmos de búsqueda se utilizan en teoría de grafos para hallar el camino con menor coste entre dos puntos dados. 24 El problema de algunos algoritmos de búsqueda en grafos informados, como puede ser el algoritmo voraz [10], es que se guían en exclusiva por la función heurística, la cual puede no indicar el camino de coste más bajo, o por el coste real de desplazarse

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

1. Anotaciones comunes, referentes a permisos, seguridad de bicicletas, oclusiones por pendiente, etc. 2. Segmentos de calles, donde se entiende por segmentos el tramo de calle entre dos intersecciones consecutivas. Las calles se dividen en segmentos, que a su vez son agrupados en caminos, si son segmentos de calle que comparten varios atributos en el mapa OSM. 3. Permisos, define qué tipos de usuarios pueden atravesar qué segmentos. Ejemplo: un atributo puede hacer que un segmento pueda ser atravesado solo por una bici en una dirección. Los permisos existentes son los siguientes: • NONE (Ninguno) • ALL (Todos) • PEDESTRIAN (Peatón) • BICYCLE (Bicicleta) • PEDESTRIAN_AND_BYCICLE (Peatón y bicicleta) • PEDESTRIAN_AND_CAR (Peatón y coche) • BICYCLE_AND_CAR (Bicicleta y coche) • CAR (Coche) 4. Seguridad de bicicletas, donde se define la seguridad de un segmento para ciclistas. Un segmento estándar tiene un valor de 1, las más seguras están entre 0 y 1 y las más inseguras por encima de 1. 5. Los datos de pendientes vienen de un origen que no tiene en cuenta la red formada a diferentes elevaciones en la calle en cuestión. Por ejemplo, se puede poner a 0 en algunos segmentos que no están en el suelo.

2.2.2. Algoritmo de cálculo de ruta La plataforma OTP utiliza el algoritmo de búsqueda A* [9]. Los algoritmos de búsqueda se utilizan en teoría de grafos para hallar el camino con menor coste entre dos puntos dados.

25

Cuaderno Tecnológico de la PTC

Nº 05/ 2014

El problema de algunos algoritmos de búsqueda en grafos informados, como puede ser el algoritmo voraz [10], es que se guían en exclusiva por la función heurística, la cual puede no indicar el camino de coste más bajo, o por el coste real de desplazarse de un nodo a otro (como los algoritmos de escalada), pudiéndose dar el caso de que sea necesario realizar bastante intuitivo el mayor hecho de que un buen algoritmo de búsqueda informada unello movimiento de coste para alcanzar la solución. Es por ello bastante intuitivo el debería en buen cuentaalgoritmo ambos factores, el valor heurístico de debería los nodostener y el coste real ambos hecho de tener que un de búsqueda informada en cuenta del recorrido. factores, el valor heurístico de los nodos y el coste real del recorrido. Así, el algoritmo A* utiliza una función de evaluación:

Así, el algoritmo A* utiliza una función de evaluación:

Ecuación 1. Función heurísticaEcuación 1. Función heurística Donde h’(n) representa el valor heurístico del nodo a evaluar desde el actual, n, hasta

Donde h’(n) representa el valor heurístico del para nodollegar a evaluar desde n, hasta el el coste real del camino recorrido a dicho nodo,eln,actual, desde el el final, y g(n) final, y inicial. g(n) elA*coste real dos del estructuras camino recorrido llegarque a dicho nodo, n, desde el nodo nodo mantiene de datospara auxiliares, podemos denominar inicial. A* mantiene dos como estructuras dededatos auxiliares, quepor podemos denominar abiertos, implementado una cola prioridad (ordenada el valor f(n) de cada abiertos, implementado comodonde una cola de prioridad (ordenada pornodos el valor de cada nodo), y cerrados, se guarda la información de los quef(n) ya han sido nodo), y cerrados, se guarda la información los nodos que ya han sidoprimero visitados. visitados.donde En cada paso del algoritmo, sede expande el nodo que esté en En cada paso del algoritmo, el un nodo que esté primero enf(n) abiertos, y en abiertos, y en caso se de expande que no sea nodo objetivo, calcula la de todos suscaso hijos,de que no sea nodoenobjetivo, f(n) evaluado de todosa sus hijos, los inserta en abiertos, y pasa el losun inserta abiertos, calcula y pasa ellanodo cerrados. nodo evaluado a cerrados. El algoritmo es una combinación entre búsquedas del tipo primero en anchura con primero en profundidad: mientras que h’(n) tiende a primero en profundidad, g(n)

El tiende algoritmo es unaencombinación entremodo, búsquedas del tipo primero anchuracada con primero a primero anchura. De este se cambia de camino de en búsqueda envez profundidad: h’(n) tiende a primero en profundidad, g(n) tiende a primero que existen mientras nodos másque prometedores. en anchura. De este modo, se cambia de camino de búsqueda cada vez que existen nodos Se prometedores. pueden enumerar diferente propiedades de este algoritmo: más Como todo algoritmo de búsqueda en amplitud, A* es un algoritmo completo: en casoenumerar de existir una solución, siempre daráde con ella.algoritmo: Se pueden diferente propiedades este 



Si para todo nodo n del grafo se cumple g(n) = 0, nos encontramos ante una



Para garantizar que el algoritmo sea óptimo, la función h(n) debe ser heurística

• Como todo algoritmo búsqueda enn amplitud, A*cumple: es un algoritmo completo: h(n) = 0, A* pasa a en caso búsqueda voraz. Si de para todo nodo del grafo se ser una búsqueda de siempre coste uniforme no informada. de existir una solución, dará con ella. admisible, esto es, que no sobrestime coste=real de alcanzar el nodoante objetivo. • Si para todo nodo n del grafo se cumpleelg(n) 0, nos encontramos una búsqueda voraz. todo nodo del grafoelsealgoritmo cumple:pasa h(n)a= denominarse 0, A* pasa a simplemente ser una búsqueda de  DeSinopara cumplirse dicha ncondición, coste no seguir informada. A,uniforme y a pesar de siendo completo, no se asegura que el resultado obtenido

sea el camino de coste mínimo. Asimismo, si garantizamos que h(n) es monótona), es decir, para cualquier nodo h(n) ny cualquiera • Paraconsistente garantizar(oque el algoritmo seaqueóptimo, la función debe serdeheurística sus sucesores, el coste estimado de alcanzar el objetivo desde n no es objetivo. mayor admisible, esto es, que no sobrestime el coste real de alcanzar el nodo que el de alcanzar el sucesor más el coste de alcanzar el objetivo desde el sucesor.

• De no cumplirse dicha condición, el algoritmo pasa a denominarse simplemente A, y a OTP ofrece la posibilidad de establecer diferentes pesos para cada etiqueta definida pesar de seguir siendo completo, no se asegura que el resultado obtenido sea el camino en el mapa OSM, de forma que se pueda favorecer el tránsito por un tipo de vía, nodo o área disminuyendo su peso asociado, mientras que otro elemento puede ser un 26 a evitar por una ruta si el peso que se le asigna es muy elevado. Al margen de punto los pesos que vienen marcados por defecto en OTP y que se pueden variar a nuestra conveniencia para fomentar ciertos comportamientos, también se pueden definir valores para otras etiquetas como, por ejemplo, “park_ride” para que ciertas

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

de coste mínimo. Asimismo, si garantizamos que h(n) es consistente (o monótona), es decir, que para cualquier nodo ny cualquiera de sus sucesores, el coste estimado de alcanzar el objetivo desde n no es mayor que el de alcanzar el sucesor más el coste de alcanzar el objetivo desde el sucesor. OTP ofrece la posibilidad de establecer diferentes pesos para cada etiqueta definida en el mapa OSM, de forma que se pueda favorecer el tránsito por un tipo de vía, nodo o área disminuyendo su peso asociado, mientras que otro elemento puede ser un punto a evitar por una ruta si el peso que se le asigna es muy elevado. Al margen de los pesos que vienen marcados por defecto en OTP y que se pueden variar a nuestra conveniencia para fomentar ciertos comportamientos, también se pueden definir valores para otras etiquetas como, por ejemplo, “park_ride” para que ciertas características se tengan en cuenta a la hora de calcular una ruta. De esta forma, se conseguirá una configuración óptima de pesos cuando la mejor ruta, según el planificador, coincida con la ruta más adecuada desde el punto de vista del usuario. Los nuevos pesos a tener en cuenta en la herramienta a la hora de ofrecer una ruta optimizada al usuario son de varios tipos: • Costes medioambientales: p.ej., la contaminación medida en una vía o ruta. • Costes de tiempo: p.ej., considerando velocidad media de las vías, si hay incidencias/ eventos que las puedan bloquear o colapsar, vías típicamente congestionadas a determinadas horas, etc. • Costes económicos: p.ej., en una ruta con mayor número de semáforos se suele consumir más combustible por el stop & go. • Otros costes: p.ej., existencia de un punto de intercambio modal, como una zona de aparcamiento de vehículos privados o bicicletas. En el caso de que se desee evitar alguno de estos elementos, se asigna un peso más alto, mientras que si se desea fomentar que la ruta pase por ellos, el peso correspondiente disminuye. La modificación de estos pesos implica la necesidad de volver a generar el grafo y cargarlo en el sistema. En OTP existe la posibilidad de que esta carga se pueda hacer en caliente, lo que disminuye el tiempo que tardaría en hacerse efectiva cualquier actualización en la distribución de pesos llevada a cabo por el administrador del sistema. Por último, el servicio diseñado permite seleccionar varios tipos de costes simultáneamente, como se puede apreciar en la Figura 8. La ruta más corta no siempre tiene por qué ser la 27

simultáneamente, como se puede apreciar en la Figura 8. La ruta más corta no siempre tiene por qué ser la más económica o rápida para el usuario, del mismo modo que a éste puede no importarle los costes medioambientales mientras que el gestor sí Cuaderno de la PTC Nº 05/ 2014 puede Tecnológico estar interesado en reducir los niveles de contaminación en una determinada zona.

8. Ejemplo de interfaz de selección de costes el usuario Figura Figura 8. Ejemplo de interfaz de selección de costes para el para usuario (Fuente(Fuente [1]) [1]) A modo de ejemplo se puede ver en la Figura 9 una ruta que incluye diferentes medios de transporte.

16

Figura 9. Ejemplo de ruta combinando varios medios (Fuente [1]) Figura 9. Ejemplo de ruta combinando varios medios (Fuente [1]) A continuación se presenta la plataforma interoperable de pago, que entronca con la idea de integración de información e intermodalidad ya que permite el pago de más económica o rápida para el usuario, del el mismo modopúblico que a éste puede no importarle distintos servicios de movilidad, como son transporte y el estacionamiento losprivado, costes amedioambientales que el gestor sí puede estar interesado en reducir través del teléfono mientras móvil.

los niveles de contaminación en una determinada zona.

A modo de ejemplo se puede ver en la Figura 9 una ruta que incluye diferentes medios de transporte. A continuación se presenta la plataforma interoperable de pago, que entronca con la idea de integración de información e intermodalidad ya que permite el pago de distintos servicios de movilidad, como son el transporte público y el estacionamiento privado, a través del teléfono móvil. 28

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

29

3. Plataforma interoperable de pago

En el proyecto Ciudad 2020 se ha desarrollado una plataforma de pago de transporte intermodal que permitiría a los ciudadanos pagar con un dispositivo móvil en servicios públicos y privados de transporte, buscando que tanto la contratación del servicio como el uso de los sistemas de transporte sean más accesibles, fáciles y cómodos para el ciudadano. A través de la aplicación desarrollada el usuario podría dar de alta un perfil, recargar saldo, consultar el precio de un viaje que incluye varios transbordos y simular la adquisición de un billete único en forma de código QR, que se validaría en cada medio de transporte. El fin es conseguir la integración de pago de distintos medios de transporte en la misma plataforma, consiguiendo que el proceso sea lo más transparente posible para el ciudadano y lo pueda gestionar de forma centralizada, independientemente del servicio a emplear. La plataforma es modular y cada uno de sus módulos cumplen una funcionalidad específica, como son: proveer de una interfaz gráfica de usuario, gestionar el cobro, administrar el perfil de usuario y almacenar la información relacionada. A la izquierda se sitúan los modos de acceso para los usuarios de ésta y en la parte inferior las entidades externas que son necesarias para la funcionalidad prevista. Por una parte existen tres tipos de accesos o comunicaciones de los usuarios de la plataforma que bien podrían ser usuarios finales (consumidores del servicio prestado) o gestores (del servicio de movilidad ofertado). Éstos son: 1. Plataforma PC: mediante un PC tanto el usuario final como el gestor puede acceder a la plataforma de pago para realizar ciertas gestiones. El primero puede hacer gestiones sobre su cuenta: reservar viajes, realizar un pre-pago o recarga de saldo, introducir y consultar datos, etc. El gestor puede realizar una monitorización de la plataforma así como cambios de configuración. 2. Comunicaciones inalámbricas mediante smartphone o tarjeta inteligente: si la plataforma está preparada para aceptar estos métodos de identificación o de pago los usuarios finales pueden utilizarlos para efectuar el pago de sus servicios en los puntos de validación de la infraestructura. Además, mediante el smartphone también se puede tener un acceso similar al de la plataforma PC. 31

transparente posible para el ciudadano y lo pueda gestionar de forma centralizada, independientemente del servicio a emplear. La plataforma es modular y cada uno de sus módulos cumplen una funcionalidad

Cuaderno Tecnológico de la PTC Nº 05/ 2014 específica, como son: proveer de una interfaz gráfica de usuario, gestionar el cobro, administrar el perfil de usuario y almacenar la información relacionada.

Figura 10.modular Esquemade modular de la plataforma deCiudad pago Ciudad (Fuente Figura 10. Esquema la plataforma de pago 20202020 (Fuente [1])[1])

En la Figura 10 se aprecia este carácter modular de la arquitectura de la plataforma de pago Ciudad 2020. La propia plataforma queda enmarcada dentro del rectángulo gris.

3. Comunicaciones inalámbricas vehiculares: a través de un transpondedor (o tag) instalado en un vehículo, el usuario puede identificarse en los puntos de validación dispuestos en la infraestructura para tal fin2. Para realizar la comunicación mediante los usuarios y la plataforma se dispone de distintos puntos de contacto que quedan englobados dentro de la llamada Human-Systems Interface (HSI). Las distintas tecnologías de acceso a la plataforma determinan los tipos de HSI: plataformas web (para PC y para dispositivos móviles), aplicaciones para móviles, puntos de validación (pórticos con antenas DSRC, sistema de lectura de códigos QR [12], dispositivo NFC [13], dispositivo de lectura de tarjetas inteligentes) y puntos de recarga (en caso de decantarse por modelos de prepago). Una vez el usuario ha accedido a la plataforma de pago se hace necesario un módulo encargado de la Autenticación y Autorización de éste, de forma que dé las máximas garantías a la hora de identificar a los usuarios “logueados” en el sistema (tanto usuarios finales como gestores) así como a los dispositivos que pasan por los puntos de validación 2 Aunque el diseño de la plataforma permitiría integrar transpondedores en la plataforma y existen soluciones para comunicarse con éstos a través de NFC, éstas son propietarias y fuera del alcance de l proyecto con lo que no han podido ser utilizadas en el desarrollo de éste. 32

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

para el cobro de los servicios utilizados. Este módulo también se encarga de dar los permisos pertinentes a la hora de acceder a determinados módulos. Cuando se ha producido la autorización o autenticación del usuario, éste puede acceder a dos módulos del sistema: 1. Gestión de cuentas de usuario: si desea introducir, modificar o borrar algún dato de su perfil. En el caso de los gestores de la plataforma, pueden acceder a la información de todos los usuarios mientras que, en un principio, los usuarios finales solo pueden acceder a su perfil. Esto conlleva el acceso al módulo de Administración de perfiles. 2. Gestión del cobro: éste es el módulo principal de la plataforma que se encarga de la gestión del proceso de cobro. Más bien, se trata de un módulo motriz que sabe qué operaciones hay que realizar y a qué otros módulos (y cómo) debe llamar, dependiendo de la funcionalidad requerida en cada momento. El módulo Cálculo de coste se encarga de calcular el coste asociado a cada uno de los servicios pagados/reservados/utilizados en base a las condiciones del servicio pedido y del perfil del usuario que lo utiliza. Esto permite establecer unos costes dinámicos en función del uso del servicio o, por ejemplo, ofrecer descuentos a determinados usuarios que han utilizado determinados modos de transporte. De esta forma se podrían implementar fácilmente políticas que premiaran un uso más sostenible del transporte. Por último, el módulo de Gestión de notificaciones se encarga de generar la información presentada al usuario en cada momento. En la Figura 10, aparecen cilindros grises correspondientes a tres bases de datos necesarias para el buen funcionamiento de la plataforma. Éstas se corresponden con: 1. Perfiles: contiene toda la información correspondiente a cada usuario. 2. Registro de operaciones: contiene los datos resultantes de monitorizar todas las operaciones realizadas por la plataforma con su información pertinente: altas de usuarios, pagos de servicios, etc. 3. Registro de incidencias: donde se recogen las posibles incidencias producidas a lo largo del funcionamiento del sistema: errores en la identificación de algún dispositivo, caídas de alguno de los módulos, etc. Esta BBDD es fundamental para tareas de mantenimiento, así como de gestión de errores y para ofrecer un mejor servicio al usuario. Por último existen 2 entidades externas con cometidos muy específicos:

33

Cuaderno Tecnológico de la PTC

Nº 05/ 2014

1. Entidad de cobro: el proceso de cobro de los servicios a los usuarios puede ser externalizado a entidades dedicadas a estos procesos. Aunque la gestión de los servicios de pago se realiza por la plataforma, el hecho de que las transacciones monetarias, al ser procesos muy delicados con unos requisitos de fiabilidad, robustez seguridad muy restrictivos, se realicen mediante una entidad especializada, presenta múltiples ventajas. Este tipo de entidades pudieran ser entidades bancarias, entidades proveedoras de tarjetas de crédito/debido o entidades tipo PayPal. 2. Entidad certificadora: debido a los requisitos de seguridad que deben existir en este tipo de plataformas donde se intercambia información muy sensible, el uso de una entidad certificadora que asegure que las comunicaciones que se están llevando a cabo en la plataforma son seguras, es más que recomendable para ofrecer un servicio de calidad al usuario. En Ciudad 2020 se ha desarrollado un caso de uso que valida los conceptos analizados de interoperabilidad de pago para el desarrollo de una plataforma real de interoperabilidad orientada a pagos de servicios de movilidad. De esta forma, se escogieron como ejemplos de servicios de pago el transporte público urbano y el aparcamiento. Así, se permite el pago de un trayecto multimodal que incluye transición vehículo privado/público. Para la validación de los tickets se optó por el uso de códigos QR, debido a la sencillez de la implementación y a la amplia disponibilidad de dispositivos compatibles con esta tecnología. A continuación se hace un esbozo de la plataforma implementada, comenzando con su arquitectura física y pasando a describir los módulos que la componen.

3.1. Arquitectura física Los procedimientos descritos en el apartado anterior, se concretan en los elementos y conexiones físicas mostradas en la siguiente figura, en la que se diferencia claramente entre los elementos pertenecientes al usuario y los correspondientes a la infraestructura: En la Figura 11 se pueden distinguir dos partes bien diferenciadas: 1. El lado del ciudadano, el cual se puede comunicar con la plataforma para la gestión de la reserva o de la compra de un bono a través de un PC o un dispositivo móvil. Dado su carácter portable, para la validación de los tickets tan solo se utiliza el dispositivo móvil. 2. El lado del gestor que opera el servicio de movilidad. Por una parte hay una plataforma básica desde donde se gestionan todos los accesos y funcionalidades del servicio. Dicha plataforma puede ser desde un PC con la BBDD dentro de él hasta un sistema de Cloud Computing con los procesos y la BBDD distribuida. Además de esta plataforma central, 34

conexiones físicas mostradas en la siguiente figura, en la que se diferencia claramente entre los elementos pertenecientes al usuario y los correspondientes a la infraestructura: Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

Figurafísica 11. Arquitectura física del caso[1]) práctico (Fuente [1]) Figura 11. Arquitectura del caso práctico (Fuente En la Figura 11 se pueden distinguir dos partes bien diferenciadas:

1. El lado del ciudadano, el cual se puede comunicar con la plataforma para la gestión de la reserva o de la compra de un bono a través de un PC o un dispositivo móvil. Dado su carácter portable, para la validación de los tickets tan solo se utiliza el dispositivo móvil. 2. El lado del gestor que opera el servicio de movilidad. Por una parte hay una plataforma básica desde donde se gestionan todos los accesos y funcionalidades del servicio. Dicha plataforma puede ser desde un PC con la BBDD dentro de él hasta un sistema de Cloud Computing con los procesos y la BBDD distribuida. Además de esta plataforma central, hay al menos un dispositivo móvil en cada uno de los Puntos de Acceso donde se validan los códigos QR de cada viajero. Dicho dispositivo podría ser cualquier dispositivo que tuviera un lector de códigos QR y pudiera conectarse con la plataforma de pago, aunque para las pruebas se hizo uso de un smartphone. Como se ha mencionado, este caso de uso plantea la utilización de los códigos QR para la validación de los tickets, si bien gracias a la modularidad del sistema, es fácilmente ampliable al uso de otra tecnología como por ejemplo NFC. A continuación se muestra un esquema de la arquitectura física de este caso práctico:

Figura 12. Arquitectura física (Fuente [1])

Figura 12. Arquitectura física (Fuente [1]) 3.2. Desarrollo del caso práctico 21

En relación a los métodos de pago, se han implementado los siguientes: 

Pago directo, a través de PayPal.



Pago mediante saldo disponible en la cuenta del usuario.



Pago con saldo disponible de un bono adquirido previamente.

35

Cuaderno Tecnológico de la PTC

Nº 05/ 2014

hay al menos un dispositivo móvil en cada uno de los Puntos de Acceso donde se validan los códigos QR de cada viajero. Dicho dispositivo podría ser cualquier dispositivo que tuviera un lector de códigos QR y pudiera conectarse con la plataforma de pago, aunque para las pruebas se hizo uso de un smartphone. Como se ha mencionado, este caso de uso plantea la utilización de los códigos QR para la validación de los tickets, si bien gracias a la modularidad del sistema, es fácilmente ampliable al uso de otra tecnología como por ejemplo NFC. La Figura 12 muestra un esquema de la arquitectura física de este caso práctico.

3.2. Desarrollo del caso práctico En relación a los métodos de pago, se han implementado los siguientes: • Pago directo, a través de PayPal. • Pago mediante saldo disponible en la cuenta del usuario. • Pago con saldo disponible de un bono adquirido previamente. Para la definición del caso práctico se definen dos fases: 1. Selección y compra del viaje/bono de viajes/saldo a través del cliente web o móvil. 2. Chequeo del trayecto en los puntos de validación mediante un código QR. A lo largo de este apartado se explica más detalladamente la solución adoptada. Los distintos módulos que se han desarrollado en el caso práctico han sido: • Cliente: interfaz desde la que el usuario (el viajero que hace uso del servicio) podrá interactuar con el sistema. Se distinguen dos tipos de clientes en función de la forma de interacción: web y móvil. • Servidor: desde donde se gestionan y resuelven todas las peticiones. • Punto de acceso: desde donde el usuario autentica y valida sus tickets mediante los códigos QR correspondientes. Es decir, es el punto donde se hace la validación en el transporte (aparcamiento, lector del bus, torno de metro, etc.).

36

consulta esquema general generalcon conlas lasdistintas distintas consultade deperfil. perfil.En Enlala Figura Figura 13, 13, se se muestra un esquema pantallas cliente. En En lalaFigura Figura14, 14,un unejemplo ejemplo pantallasde delas lasque queestá estácompuesta compuesta la la aplicación cliente. Retos yde oportunidades de movilidad urbana enmóvil las ciudades El ejemplo caso de de Ciudad 2020 de la inteligentes. Figura 15 15 un un ejemplo detipo tipode de delalainterfaz interfazgráfica gráfica de lala aplicación aplicación y en la Figura pago PayPal. pagodirecto directoutilizando utilizandolalaAPI API proporcionada proporcionada por PayPal.

Figura 13. Esquema general del cliente (Fuente [1]) Figura 13. Esquema general del (Fuente [1]) Figura 13.cliente Esquema general del cliente (Fuente [1])

Figura 14.aplicación Pantalla inicial de la aplicación (Fuente [1]) Figura 14. Pantalla inicial de la (Fuente [1])

Figura 14. Pantalla inicial de la aplicación (Fuente [1])

3.2.1. Cliente El acceso por parte del cliente a la plataforma de pago, se puede llevar a cabo de dos formas: i) mediante una aplicación desarrollada para dispositivos móviles Android, o ii) a través de una plataforma web. Ambas aplicaciones se pueden dividir conforme a sus pantallas de navegación: pantalla de registro, principal, de compra de viajes y de consulta de perfil. En la Figura 13, se muestra un esquema general con las distintas pantallas de las que está compuesta la aplicación cliente. En la Figura 14, un ejemplo de la interfaz gráfica de la aplicación móvil y en la Figura 15 un ejemplo de tipo de pago directo utilizando la API 23 proporcionada por PayPal. 23

37

Cuaderno Tecnológico de la PTC

Nº 05/ 2014

Figura 15. Ejemplo del proceso de pago directo (Fuente [1])

En relación al Figura cliente web, éste facilita el proceso de[1]) compra de billetes, bonos y saldo 15. Ejemplo del proceso de pago directo (Fuente [1]) Figura 15. Ejemplo del proceso de pago directo (Fuente de forma homóloga a la de la aplicación móvil, aunque su esquema es un poco En relacióncomo al cliente web,apreciar éste facilita proceso diferente, se puede en laelFigura 16.de compra de billetes, bonos y saldo de forma homóloga a la de la aplicación móvil, aunque su esquema es un poco diferente, como se puede apreciar en la Figura 16.

Figura 16. Esquema de funcionamiento de la interfaz web del cliente (Fuente Figura 16. Esquema de funcionamiento de la interfaz web del cliente (Fuente [1]) [1]) Figura 16. Esquema de funcionamiento de la interfaz web del cliente (Fuente [1])

3.2.2. Servidor El servidor se ha desplegado sobre un servidor web Apache [15] que se encarga de 3.2.2. Servidor atender todas las peticiones realizadas por el cliente. El38servidor se ha desplegado sobre un servidor web Apache [15] que se encarga de La implementación del servidor se ha por realizado en PHP. Su tarea principal es la de atender todas las peticiones realizadas el cliente. gestionar la base de datos, así como de controlar toda la información requerida por el La implementación del servidor se haadecuada. realizado en PHP. Su tarea principal es la de cliente y proporcionársela de la forma

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

En relación al cliente web, éste facilita el proceso de compra de billetes, bonos y saldo de forma homóloga a la de la aplicación móvil, aunque su esquema es un poco diferente, como se puede apreciar en la Figura 16.

3.2.2. Servidor El servidor se ha desplegado sobre un servidor web Apache [15] que se encarga de atender todas las peticiones realizadas por el cliente. La implementación del servidor se ha realizado en PHP. Su tarea principal es la de gestionar la base de datos, así como de controlar toda la información requerida por el cliente y proporcionársela de la forma adecuada. Las funciones PHP del servidor actúan de la siguiente manera: • Reciben una petición HTTP POST del cliente con distintos parámetros. • Realizan las acciones necesarias, como pueden ser: consultar el identificador de un usuario, mirar el número de viajes, ver si el usuario y contraseña coinciden, etc. • Devuelven por medio de un mensaje JSON toda la información necesaria. Otra de las funciones que tiene que realizar el servidor es la de generar la imagen de un código QR dado un texto identificativo de cada viaje.

3.2.3. Punto de acceso El punto de acceso lo forma un lector de códigos QR. Presenta dos modos de autenticación: a través de un código QR que el lector captura mediante el uso de la cámara (Figura 17) o introduciendo manualmente el texto asociado al código (Figura 18). Además, dispone de otra pantalla que permite modificar el punto de validación, de forma que el lector pueda ser utilizado en varios puntos sin mayores inconvenientes. A continuación, se presenta el sistema de monitorización de las zonas de aparcamiento, que alimenta con información de las plazas disponibles en una zona videovigilada al servicio de rutas.

39

El punto de acceso lo forma un lector de códigos QR. Presenta dos modos de autenticación: a través de un código QR que el lector captura mediante el uso de la cámara (Figura 17) o introduciendo manualmente el texto asociado al código (Figura Cuaderno Tecnológico de lade PTC Nº 05/ 18). Además, dispone otra pantalla que permite modificar el punto de validación, de 2014 forma que el lector pueda ser utilizado en varios puntos sin mayores inconvenientes.

Figura 17. Autenticación del código Figura 17. Autenticación gráfica del códigográfica QR (Fuente [1]) QR (Fuente [1])

25

Figura 18. ValidaciónFigura en el modo textual (Fuente [1]) textual (Fuente [1]) 18. Validación en el modo A40 continuación, se presenta el sistema de monitorización de las zonas de aparcamiento, que alimenta con información de las plazas disponibles en una zona videovigilada al servicio de rutas.

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

41

4. Monitorización de zonas de aparcamiento

Una de las fuentes de información de las que hace uso el servicio de rutas es la ocupación de las plazas de aparcamiento. Dentro de Ciudad 2020 se ha desarrollado un sistema de Visión Artificial capaz de monitorizar una zona de aparcamiento y ofrecer información sobre los espacios libres. El resultado generado está compuesto por una aplicación software encargada, por una parte, de capturar la información recibida por la cámara (instalada con ese fin, o utilizado las imágenes proporcionadas por cámaras previamente instaladas, como las de videovigilancia), y por otra de interaccionar con el CIV, proporcionándole la información de interés y recibiendo datos adicionales para el correcto funcionamiento. El principal objetivo de la aplicación es la caracterización de espacios libres de aparcamiento en áreas que pueden o no estar delimitadas, incluyendo: • Detección de estacionamiento y liberación de plaza por parte de los vehículos. • Estimación de las dimensiones de las áreas libres de estacionamiento (en caso de plazas no delimitadas), información que permite determinar el número de vehículos que pueden estacionar en una determinada región, en función de las medidas estándar de un vehículo. Esta aproximación se presenta como una alternativa a las conocidas redes de sensores inalámbricas (Wireless Sensor Networks –WSNs-) [16], presentándose como una solución no intrusiva, versátil y, en determinadas circunstancias, más económica de desplegar. La aplicación se desarrolló bajo las siguientes restricciones: • Empleo de una cámara única, situada en una posición arbitraria y fija. • Aplicación en entornos urbanos, con posibilidad de obstáculos, oclusiones, y un gran flujo de personas y vehículos. • Las plazas de aparcamiento no tienen por qué estar delimitadas. El sistema analizará una región de aparcamiento en su conjunto, sin diferenciar cada una de las plazas de forma individual, en caso de que estuvieran delimitadas. • Condiciones lumínicas diversas y cambiantes: sombras, reflejos, cambios de iluminación, paso de noche a día, etc. 43

Cuaderno Tecnológico de la PTC

Inicialización y calibración

Nº 05/ 2014

Frames vídeo

Sustracción de fondo

Mapa de transiciones

α

Presentación

Caracterización plazas (alto nivel)

Detección de aparcamiento /salida

Asociación y tracking

Modelo escena

Control de oclusiones

Figura 19.19. Diagrama dede bloques deldel sistema dede detección dede aparcamiento libre [1]) Figura Diagrama bloques sistema detección aparcamiento libre(Fuente (Fuente [1])

continuación, se describen unoende bloques implementados LaAaplicación desarrollada sigueenunprofundidad algoritmo cada basado ellos análisis temporal de los frames así como el proceso de validación correspondiente a cada uno de ellos. Además, al procedentes de la cámara de vídeo correspondiente. El procesado se puede descomponer se comenta tratamiento especialtal que se realiza durante en transiciones enfinal un conjunto de el bloques funcionales y como se presenta la Figura día/noche 19.

y noche/día que permiten al sistema funcionar durante 24 horas si las condiciones de iluminación lo permiten. A continuación, se describen en profundidad cada uno de los bloques implementados así

como proceso validación correspondiente a cada uno de ellos. Además, al final se 4.1. el Módulo dede Inicialización. comenta el tratamiento especial que se realiza durante transiciones día/noche y noche/ módulo aldesistema inicialización, aplicación utilizasi lasinformación díaEn queelpermiten funcionarladurante 24 horas condicionesintroducida de iluminación manualmente acerca de la escena para comenzar a funcionar: lo permiten.  Zonas de aparcamiento. Aquellas regiones en las que está permitido el estacionamiento de vehículos.

4.1. Módulo de Inicialización.

 Opcionalmente, si se desea crear un mapa detallado de la escena diferenciando plazas la aplicación individuales, se información puede delimitar el manualmente contorno En el módulo de inicialización, utiliza introducida cada unaade las plazas, dado que el algoritmo propuesto no acerca decorrespondiente la escena para acomenzar funcionar: incluye la funcionalidad de identificación automática de plazas individuales. Con información, laAquellas aplicación generará correspondiente. • Zonasdicha de aparcamiento. regiones en el lasmapa que está permitido el estacionamiento

de vehículos.  Vehículos iniciales. La aplicación no es capaz de detectar vehículos

estacionados desde el instante inicial, por lo que es preciso indicarlo

• Opcionalmente, si sePara desea mapa detallado de la escena diferenciando manualmente. ellocrear se haundesarrollado un algoritmo semi-automático plazasbasado individuales, se puede delimitar el contorno correspondiente a cada una de las en watershed [17]. plazas, dado que el algoritmo propuesto no incluye la funcionalidad de identificación 4.2. Calibración automática de plazas individuales. Con dicha información, la aplicación generará el mapa correspondiente. Por medio de un proceso de calibración es posible conocer las dimensiones físicas reales de las plazas de aparcamiento visualizadas por la cámara. Esta calibración se basa en tres pasos: 44 1. Transformación de perspectiva. La transformación de perspectiva se emplea en el proceso de calibración para obtener una vista cenital del área bajo análisis, a partir de la visión en perspectiva obtenida por la cámara. Esta etapa es

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

• Vehículos iniciales. La aplicación no es capaz de detectar vehículos estacionados desde el instante inicial, por lo que es preciso indicarlo manualmente. Para ello se ha desarrollado un algoritmo semi-automático basado en watershed [17].

4.2. Calibración Por medio de un proceso de calibración es posible conocer las dimensiones físicas reales de las plazas de aparcamiento visualizadas por la cámara. Esta calibración se basa en tres pasos: 1. Transformación de perspectiva. La transformación de perspectiva se emplea en el proceso de calibración para obtener una vista cenital del área bajo análisis, a partir de la visión en perspectiva obtenida por la cámara. Esta etapa es esencial en el proceso de calibración: debido a la perspectiva, los objetos se muestran más pequeños cuanto más lejos se encuentran del punto focal de la cámara, por lo que una estimación de sus dimensiones reales conduciría a resultados erróneos. Mediante la transformación de perspectiva, por el contrario, se obtiene una vista ortogonal al plano de la carretera (bajo un pequeño error, que se reduce conforme se aumenta la altura a la que se sitúa la cámara) que elimina cualquier efecto de perspectiva y permite obtener las dimensiones reales de los objetos mostrados. Se decidió seguir una solución basada en un algoritmo conocido como “Four-point perspective transform” [18]. Se trata de un algoritmo sencillo de implementar y utilizar por el usuario, que proporciona una buena estimación de la transformación de perspectiva requerida y tan solo requiere marcar 4 puntos coplanarios. 2. Indicación de distancia conocida. Una vez efectuada la transformación de perspectiva, es necesario establecer una correspondencia entre una dimensión observada en la imagen transformada, medida en píxeles, y la medida real, en metros, de esa misma dimensión. Para ello, la aplicación establece una correspondencia inmediata entre longitudes en píxeles y metros. 3. Cálculo de dimensiones. Finalmente, la aplicación realiza una estimación de las dimensiones de las áreas libres de aparcamiento (que pueden contener una o más plazas). Estas áreas se modelan en la aplicación como un cuadrilátero, por lo que se conocen sus 4 vértices. La aplicación calcula el mayor y menor de los lados y traducirá las dimensiones, en píxeles, a metros, empleando el factor de escala calculado previamente gracias a la indicación de la distancia conocida.

45

Tras efectuar un análisis del estado del arte, se decidió emplear una combinación de técnicas ampliamente reconocidas y validadas: mezcla de gaussianas (GMM3) [19] y mapa de transiciones [20] que dan máscaras de blobs transitorios (Figura 20). Cuaderno Tecnológico de la PTC Nº 05/ 2014

(a)

(b)

FiguraFigura 20. Ejemplo de un de frame (a) y la de blobs transitorios (b) asociada (Fuente [1]) 20. Ejemplo un frame (a)máscara y la máscara de blobs transitorios (b) asociada (Fuente [1])

4.3. Módulo de detección de objetos de interés (Sustracción de fondo) 3

Del inglés, Gaussian Mixture Model.

El algoritmo desarrollado tiene su base en la capacidad de detectar objetos en movimiento (principalmente, vehículos) y diferenciarlos del resto de la escena, estática. 29

Para resolverlo, se decidió emplear la técnica de sustracción de fondo, que permite obtener, a partir de un conjunto de frames consecutivos, una imagen actualizada del fondo de la escena por una parte, y otra imagen del fondo, de forma independiente. Tras efectuar un análisis del estado del arte, se decidió emplear una combinación de técnicas ampliamente reconocidas y validadas: mezcla de gaussianas (GMM ) [19] y mapa de transiciones [20] que dan máscaras de blobs transitorios (Figura 20).

4.4. Asociación de blobs y seguimiento Una vez se dispone del mapa de transiciones y las máscaras de blobs transitorios, se añade una capa software de nivel superior para determinar: • De los blobs que aparecen, cuáles se corresponden a vehículos y cuáles no (en cuyo caso deben ser descartados). • En caso de que aparezcan varios blobs asociados a vehículos, cuáles se corresponden con vehículos presentes en el frame anterior (hay que hacer una asociación o matching) y cuáles son vehículos nuevos que han entrado en escena. Para ello, se efectúan dos operaciones iniciales: 1. Extracción de cada uno de los blobs transitorios por separado. 46

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

2. Se define una estructura vehículo que permite almacenar toda la información de interés de un vehículo presente en la escena. Para acometer ambas operaciones, se desarrolló un algoritmo de asociación y seguimiento de vehículos.

4.5. Módulo de control de oclusiones Un aspecto de gran importancia a considerar en la aplicación es la posibilidad de que se produzcan oclusiones entre vehículos. Se distinguen 2 situaciones distintas que el algoritmo debe resolver: 1. Entre vehículos en movimiento. 2. Entre un vehículo estacionado y otro en movimiento. A su vez se distingue el caso en que el vehículo estacionado se encuentre delante o detrás del vehículo en movimiento. El algoritmo detecta cualquiera de estos casos y evita falsas detecciones de aparcamiento o liberación de plaza.

4.6. Detección de aparcamiento/liberación de plaza Tras efectuar el procesado anterior, se dispone de un modelo de la escena suficiente para permitir una adecuada caracterización de las plazas de aparcamiento. El procedimiento de detección se realiza a partir de un análisis temporal de la evolución de los blobs (transitorios y estacionarios obtenidos).

4.7. Caracterización de plazas y presentación El último paso del sistema es la presentación por pantalla de la información obtenida. Esta información se muestra tanto textualmente, como gráficamente. Además también se incluye una estimación del número de espacios de aparcamiento libre, siempre teniendo en cuenta medidas estándar de vehículos. La información textual se presenta por pantalla, según el siguiente formato (Figura 21): [N_Área]: MetrosLongitud x MetrosAnchurametros Donde MetrosLongitud se refiere a la longitud de la zona de aparcamiento, mientras que MetrosAnchura se refiere a la anchura de la zona, que en el caso de aparcamiento en batería 47

coche. También se muestra en formato gráfico, representando sobre el frame actual las plazas Tecnológico libres (en verde) y las ocupadas (en rojo). Cuaderno de la PTC Nº 05/ 2014

(a)

(b)

Figura 21. Presentación de resultados: forma textual (a) y gráfica (b) (Fuente Figura 21. Presentación de resultados: forma textual (a) y gráfica (b) (Fuente [1]) [1])

Como se puede observar en la Figura 21, la interfaz gráfica muestra gráficamente y

tendrá unas dimensiones a la longitud coche en el caso de así aparcamiento textualmente las zonas similares libre existentes en la del bolsa de yaparcamiento, como la en línea, MetrosAnchura longitud del espacio tendrá libre. unas dimensiones similares al ancho del coche. El cálculo de los espacios libres se basa en el estudio del ángulo de una de las rectas

También se muestra en formato gráfico,de representando el cuatros frame actual plazas que definen cada una de las regiones aparcamiento.sobre De las rectaslas que libres (en verde) y las ocupadas rojo). de la recta con mayor longitud, el ángulo se delimitan cada región, se estudia(en el ángulo calcula con la arco-tangente de los puntos inicio y final de la recta.

Como se puede enselaestudian Figura 21, la interfaz gráfica muestra gráficamente y Por cada frame observar procesado, posteriormente las zonas libres que quedan textualmente las zonas libre existentes enuna la bolsa aparcamiento, así como la longitud entre los coches estacionados. Para cada de lasdezonas: del espacio libre. a) Se calcula en qué región de aparcamiento, de las definidas por el operador, recae la zona libre.

El cálculo de los espacios libres se basa en el estudio del ángulo de una de las rectas que b) cada Se calculan dede losaparcamiento. cuatro lados queDe forma la zona libre. definen una delos lasángulos regiones las cuatros rectas que delimitan c) Se comparan dichos ángulos con el ángulo de la región de aparcamiento a la con cada región, se estudia el ángulo de la recta con mayor longitud, el ángulo se calcula que pertenece. la arco-tangente de los puntos inicio y final de la recta. d) Aquel lado, cuyo ángulo se encuentre más próximo al ángulo de la región, será Por cada frame se estudian las zonas que el que procesado, defina la longitud de laposteriormente zona de aparcamiento y libres a partir delquedan cual elentre número de espacios libres debe ser calculado. los coches estacionados. Para cada una de las zonas: Si consideramos que la longitud obtenida en el apartado d) se llama L_zona y teniendo a) Se calcula región aparcamiento, delínea, las definidas por elque operador, recae la en cuenta queen si qué la región dede aparcamiento es en considerando la longitud de unalibre. plaza de aparcamiento es L_plaza (una constante a definir por el gestor), en zona las zonas libres en línea, el cálculo se realiza de la siguiente forma:

b) Se calculan los ángulos de los cuatro lados que forma la zona libre. c) Se comparan dichos ángulos con el ángulo de batería, la regiónyde aparcamiento la que Por otro lado, si la región de aparcamiento es en considerando quea la pertenece. anchura de una plaza de aparcamiento es A_plaza (constante a definir por el gestor), en las zonas libres en batería, el cálculo se realiza de la siguiente forma: 31 48

entre los coches estacionados. Para cada una de las zonas: a) Se calcula en qué región de aparcamiento, de las definidas por el operador, recae la zona libre. Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020 b) Se calculan los ángulos de los cuatro lados que forma la zona libre. c) Se comparan dichos ángulos con el ángulo de la región de aparcamiento a la

c) Aquel cuyo ángulo se encuentre más próximo al ángulo de la región, será el que quelado pertenece. defina la longitud de la zona de aparcamiento y a partir del cual el número de espacios d) Aquel lado, cuyo ángulo se encuentre más próximo al ángulo de la región, será libres debe ser calculado. el que defina la longitud de la zona de aparcamiento y a partir del cual el número de espacios libres debe ser calculado.

Si consideramos que la longitud obtenida en el apartado d) se llama L_zona y teniendo en Si consideramos que ladelongitud obtenidaes enen el línea, apartado d) se llama L_zona y teniendo cuenta que si la región aparcamiento considerando que la longitud de una en cuenta que si la región de aparcamiento es en línea, considerando que la longitud plaza de aparcamiento es L_plaza (una constante a definir por el gestor), en las zonas de una plaza de aparcamiento es L_plaza (una constante a definir por el gestor), en libres en línea, el cálculo siguiente las zonas libres en línea,seelrealiza cálculode sela realiza de laforma: siguiente forma:

Por otro lado, si región la región aparcamiento batería, y considerando la Por otro lado, si la de de aparcamiento es es en en batería, y considerando queque la anchura anchura de una plaza de aparcamiento es A_plaza (constante a definir por el gestor), de una plaza de aparcamiento es A_plaza (constante a definir por el gestor), en las zonas en las libres en batería, el cálculo sesiguiente realiza deforma: la siguiente forma: libres enzonas batería, el cálculo se realiza de la 31

4.8. Adaptación a transición noche/día y día/noche 4.8. Adaptación a transición noche/día y día/noche. Por último, el sistema de detección de plazas de aparcamiento, es capaz de funcionar con Por último, el sistema de cuando detección aparcamiento, essuficiente. capaz de funcionar buenas tasas de detección ende la plazas escenade existe iluminación Para aquellos con buenas deladetección cuando la la escena existe iluminación suficiente. Para escenarios en tasas los que luz existente noen sea necesaria para el correcto funcionamiento endesarrollar los que la luz existente no sea necesaria para el correcto delaquellos sistema,escenarios se podrían otros algoritmos delavisión, por ejemplo basados en funcionamiento del faros sistema, se coches. podrían Por desarrollar otros algoritmos de por que la iluminación de los de los ello se ha implementado unvisión, algoritmo ejemplo en de la iluminación de los faros de los coches. Por ello se ha detecta las basados transiciones las condiciones de luminosidad. implementado un algoritmo que detecta las transiciones de las condiciones de El luminosidad. algoritmo que permite detectar cuándo existe suficiente iluminación para que el

sistema funcione correctamente estácuándo basadoexiste en el espacio color de HSV. analiza El algoritmo que permite detectar suficientedeiluminación paraSeque el en cada frame,funcione la mediacorrectamente de los valoresestá de color en la correspondiente a asfalto dentro sistema basado enzona el espacio de color de HSV. Se delanaliza parking seleccionada previamente. Utilizando para ello dos umbrales para hacer la en cada frame, la media de los valores de color en la zona correspondiente a transición estimados empíricamente. Cuando la media del nivel de color del asfalto de asfalto dentro del parking seleccionada previamente. Utilizando para ello dos umbrales una imagen concreta se halla por debajo del umbral de día, se considera que la escena ha para hacer la transición estimados empíricamente. Cuando la media del nivel de color cambiado a estado nocturno. En estado nocturno, si la media del nivel de color de HSV del del asfalto de una imagen concreta se halla por debajo del umbral de día, se considera asfalto se halla por encima del umbral de noche, se considera que la escena ha cambiado que la escena ha cambiado a estado nocturno. En estado nocturno, si la media del a estado diurno. nivel de color de HSV del asfalto se halla por encima del umbral de noche, se considera que la escena ha cambiado a estado diurno.

Cuando el estado de la escena pasa de nocturno a diurno el sistema lo detecta e inicia el algoritmo estado de la pasade deplazas nocturno a diurno el sistema lo detectasee basa inicia en el deCuando nuevo el deescena detección descrito. Esta rutina también de nuevo el algoritmo de detección plazas Esta rutina se basa en estudio de color en el espacio HSV. de Para ello, descrito. se analizaron cada también uno de los tres canales estudio de color en el espacio Para ello, unomejor de los tres deelHSV por separado, llegando a laHSV. conclusión, queseesanalizaron el canal H,cada el que resultados producía. canales de HSV por separado, llegando a la conclusión, que es el canal H, el que mejor resultados producía.

49

Cuaderno Tecnológico de la PTC

Nº 05/ 2014

car nocar

Figura 22. Imagen de muestra (sup); Imagen en el espacio HSV para los pixeles que pertenecen a coche (inf. izqda.); Imagen en el espacio HSV para los pixeles que pertenecen a asfalto (inf. dcha.) (Fuente [1]) car

nocar

Por cada uno de los frames que se analizan se compara con los pixeles que pertenecen a “coche” en la imagen de muestra, con los pixeles que pertenecen a “asfalto” al frame actual, a través de sus histogramas acumulativos. A través del histograma acumulativo se puede calcular un umbral automático, con el cual se detecta con claridad en la imagen qué pixeles pertenecen a coche. Así se obtiene una imagen binaria tras un de procesado posterior, permite localizarHSV lospara coches en la Figuraque 22. muestra (sup); en el espacio los pixeles Figura 22. Imagen de Imagen muestra (sup); Imagen enImagen el espacio HSV para los pixeles que pertenecen imagen. que pertenecen a coche (inf. izqda.); Imagen en el espacio HSV para los pixeles a coche (inf. izqda.); en elaespacio HSVdcha.) para los pixeles queImagen pertenecen asfalto (inf. (Fuente [1])que pertenecen a asfalto (inf. dcha.) (Fuente [1]) h

Por cada uno de los frames que se analizan se compara con los pixeles que pertenecen a “coche” en la imagen de muestra, con los pixeles que pertenecen a “asfalto” al frame actual, a través de sus histogramas acumulativos. A través del histograma acumulativo se puede calcular un umbral automático, con el cual se detecta con claridad en la imagen qué pixeles pertenecen a coche. Así se obtiene una imagen binaria que tras un procesado posterior, permite localizar los coches en la imagen.

h

Figura 23. Imagen binaria tras aplicar el umbral automático calculado (Fuente [1])

Figura 23. Imagen binaria tras aplicar el umbral automático calculado (Fuente [1])

Por de los frames que uno se analizan se compara los pixeles que pertenecen Por cada último,uno la localización de cada de los coches se hacecon a través del algoritmo de explicado con de anterioridad. Una los vezpixeles que el que algoritmo de watershed se haal frame awatershed “coche” en la imagen muestra, con pertenecen a “asfalto” ejecutado, se consiguen los coches por separado como del muestra la Figuraacumulativo 24. actual, a través de sus localizar histogramas acumulativos. A través histograma se puede calcular un umbral automático, con el cual se detecta con claridad en la imagen qué pixeles pertenecen a coche. Así se obtiene una imagen binaria que tras un procesado posterior, permite localizar los coches en la imagen. 50 Figura 23. Imagen binaria tras aplicar el umbral automático calculado (Fuente [1])

Por último, la localización de cada uno de los coches se hace a través del algoritmo de watershed explicado con anterioridad. Una vez que el algoritmo de watershed se ha

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

Figura 24. Imagen izquierda, resultado al aplicar el algoritmo de watershed. Imagen derecha: Localización de cada uno de los coches (Fuente [1])

Finalmente, en la Figura 25 se puede apreciar una captura de pantalla de la aplicación Figura 24. Imagen izquierda, resultado al aplicar el algoritmo de watershed. Imagen Figura 24. Imagen izquierda, resultado al aplicar el algoritmo de watershed. Imagen derecha: desarrollada derecha: Localización de cada uno de los coches (Fuente [1]) Localización de cada uno de los coches (Fuente [1]) Finalmente, en la Figura 25 se puede apreciar una captura de pantalla de la aplicación desarrollada

Figura 25. Captura de la aplicación de monitorización de zonas de aparcamiento Figura 25. Captura de la aplicación de monitorización de zonas de aparcamiento

Por último, la localización de cada uno de los coches se hace a través del algoritmo de Figuraexplicado 25. Captura de la aplicación deUna monitorización zonas de aparcamiento watershed con anterioridad. vez que eldealgoritmo de watershed se ha ejecutado, se consiguen localizar los coches por separado como muestra la Figura 24. Finalmente, en la Figura 25 se puede apreciar una captura de pantalla de la aplicación desarrollada.

51

5. Conclusiones

A lo largo del presente documento se ha realizado una descripción de tres herramientas desarrolladas dentro del proyecto Ciudad 2020 enmarcadas dentro del ámbito de la movilidad. Cada una de ellas sirve de ejemplo para mostrar algunas de las posibilidades que ofrecen las nuevas ciudades inteligentes. La interconexión de dispositivos electrónicos, el aumento de las capacidades de procesamiento, la integración de servicios y el desarrollo y consumo colaborativo permiten mejorar la calidad de vida de los ciudadanos, a través de la reducción de los tiempos de desplazamientos, la mejora del medioambiente y la comodidad a la hora de utilizar los servicios ofrecidos por la ciudad. El IoT, junto con el desarrollo de nuevos sensores, de reducido tamaño y coste y capaces de procesar los datos capturados, proveen de una cantidad ingente de información de la que aún no se sabe muy bien su verdadero potencial. Se ha visto en el capítulo 2, cómo se puede hacer uso de información en tiempo real sobre la movilidad urbana, para generar un servicio que permita al ciudadano desplazarse de forma más eficiente y ecológica, priorizando el uso de los medios de transporte más ecológicos. Como ejemplo de nuevas capacidades de obtención de información compleja, hemos presentado en el capítulo 4 un sistema de Visión Artificial que obtiene información automática y en tiempo real sobre la ocupación de los espacios de aparcamiento. Sin embargo, las funcionalidades de este sistema pueden ser fácilmente ampliables para la monitorización del tráfico o la detección de incidencias o conductas anómalas. En este escenario, la interoperabilidad de servicios es clave para generar casos de éxito. Se ha visto que tanto la integración de fuentes de datos heterogéneas (Capítulo 2), como el uso de un mismo dispositivo de pago para servicios distintos (Capítulo 3) son tecnológicamente viables. Además, los tres casos presentados también pueden ser combinados fácilmente. Sin embargo, queda en manos de los distintos intereses de las administraciones públicas, operadores de transporte y otras empresas privadas, establecer vínculos que satisfagan a todos y faciliten dicha interoperabilidad real. Por otra parte, el uso de herramientas de código libre utilizadas en el desarrollo de los ejemplos mostrados, y que han sido creadas y están mantenidas por una comunidad abierta de desarrolladores, facilita la creación de estos nuevos servicios. Esto demuestra que la compartición del conocimiento va en aras de un mayor y más rápido desarrollo tecnológico donde todos los actores, nuevos o existentes, ciudadanos, entidades públicas y privadas, pueden verse beneficiados. 53

Cuaderno Tecnológico de la PTC

Nº 05/ 2014

También resulta relevante la participación activa de los ciudadanos, presentándose como una fuente de información primordial. En el servicio de rutas se ha visto que el uso de las redes sociales puede permitir caracterizar ciertos aspectos de la movilidad de forma más sencilla que otros dispositivos tradicionales, y tenerlo en cuenta a la hora de indicar a un usuario qué ruta debe seguir. De esta forma el ciudadano se convierte en productor y consumidor de información. Papel que aún no se ha sabido explotar adecuadamente y que empieza a cobrar cada vez mayor relevancia.

54

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

55

6. Agradecimientos

El desarrollo y los resultados que se exponen en el presente son fruto de los trabajos de investigación realizados en el marco del programa INNPRONTA, a través del proyecto CIUDAD 2020 con número de referencia IPT-2011006 (www.innprontaciudad2020.es), cofinanciado por el Centro para el Desarrollo Tecnológico Industrial (CDTI). Indra, la multinacional de TI número 1 en España y una de las principales de Europa, lidera el consorcio del proyecto y las tareas centradas en el ámbito del transporte y la movilidad, financiando los trabajos que se describen en este documento. Completan el consorcio las compañías, Ferrovial Agromán, Atos, Fagor Electrónica y GFI Informática; y las pymes Fractalia, Daedalus, Tekia, e Isoco. El consorcio cuenta también con varios grupos de investigación de la Universidad Politécnica de Madrid, la Universidad de Alcalá de Henares, la Universidad Carlos III, la Universidad de Zaragoza, la Universidad de Cantabria y la Universidad de la Coruña, así como las fundaciones Barcelona Digital y CI3 (Centro de Innovación de Infraestructuras Inteligentes)

57

7. Bibliografía y referencias

[1] Proyecto INNPRONTA Ciudad 2020: www.innprontaciudad2020.es [2] Wikipedia, Park & Ride: http://en.wikipedia.org/wiki/Park_and_ride [3] Portal de Open Street Maps: http://www.openstreetmap.org [4] Portal de Open Trip Planner: http://www.opentripplanner.org/ [5] Librería GTFS: http://www.opentripplanner.org/https://developers.google.com/transit/gtfs [6] Portal de desarrolladores de twitter: https://dev.twitter.com/ [7] Portal de PGRouting: http://pgrouting.org/ [8] Wikipedia, API REST: http://es.wikipedia.org/wiki/Representational_State_Transfer [9] Wikipedia, A* search algorithm: http://en.wikipedia.org/wiki/A*_search_algorithm [10] Wikipedia, Greedy algorithm: http://en.wikipedia.org/wiki/Greedy_algorithm [11] Wikipedia, Dedicated Short-Range Communications: http://en.wikipedia.org/wiki/Dedicated_short-range_communications [12] Wikipedia, QR code: http://en.wikipedia.org/wiki/QR_code [13] Wikipedia, NFC: http://en.wikipedia.org/wiki/Near_field_communication [14] Portal de PayPal: https://www.paypal.com

59

Cuaderno Tecnológico de la PTC

Nº 05/ 2014

[15] Portal de Apache: http://httpd.apache.org/ [16] Vishnubhotla, R.; Rao, P.S.; Ladha, A.; Kadiyala, S.; Narmada, A.; Ronanki, B.; Illapakurthi, S., “ZigBee based multi-level parking vacancy monitoring system,” Electro/Information Technology (EIT), 2010 IEEE International Conference on , vol., no., pp.1,4, 20-22 May 2010 [17] Meyer, F. Color Image Segmentation, ICIP92, 1992. [18] Blinn, J.F., “Inferring transforms [computer graphics],” Computer Graphics and Applications, IEEE , vol.19, no.3, pp.93,98, May/Jun 1999. [19] P. KadewTraKuPong and R. Bowden, An improved adaptive background mixture model for real-time tracking with shadow detection, Proc. 2nd European Workshop on Advanced VideoBased Surveillance Systems, 2001. [20] Kujanperä V. (2010) Highway video surveillance – development of an automatic detection system for abnormal incidents employing computer vision. University of Oulu, Department of Electrical and Information Engineering. Master´s Thesis.

60

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

61

8. Índice de figuras

Figura 1. Construcción del grafo (Fuente [1]).........................................................18 Figura 2. Diagrama del CIV (Fuente [1]).................................................................19 Figura 3. Fuentes de datos utilizadas en la implementación del CIV (Fuente [1]).20 Figura 4. Esquema de datos públicos de Zaragoza (Fuente [1])............................ 21 Figura 5. Diagrama de componentes de la plataforma OTP..................................22 Figura 6. Diagrama de colaboración OTP...............................................................23 Figura 7. Ejemplo de shapefile................................................................................24 Figura 8. Ejemplo de interfaz de selección de costes para el usuario (Fuente [1])28 Figura 9. Ejemplo de ruta combinando varios medios (Fuente [1])...................... 28 Figura 10. Esquema modular de la plataforma de pago Ciudad 2020 (Fuente [1])... .................................................................................................................................32 Figura 11. Arquitectura física del caso práctico (Fuente [1]).................................35 Figura 12. Arquitectura física (Fuente [1]).............................................................35 Figura 13. Esquema general del cliente (Fuente [1])..............................................37 Figura 14. Pantalla inicial de la aplicación (Fuente [1]).........................................37 Figura 15. Ejemplo del proceso de pago directo (Fuente [1])................................38 Figura 16. Esquema de funcionamiento de la interfaz web del cliente (Fuente [1])... .................................................................................................................................38

63

Cuaderno Tecnológico de la PTC

Nº 05/ 2014

Figura 17. Autenticación gráfica del código QR (Fuente [1])................................. 40 Figura 18. Validación en el modo textual (Fuente [1])........................................... 40 Figura 19. Diagrama de bloques del sistema de detección de aparcamiento libre (Fuente [1])..............................................................................................................44 Figura 20. Ejemplo de un frame (a) y la máscara de blobs transitorios (b) asociada (Fuente [1])..............................................................................................................46 Figura 21. Presentación de resultados: forma textual (a) y gráfica (b) (Fuente [1])... .................................................................................................................................48 Figura 22. Imagen de muestra (sup); Imagen en el espacio HSV para los pixeles que pertenecen a coche (inf. izqda.); Imagen en el espacio HSV para los pixeles que pertenecen a asfalto (inf. dcha.) (Fuente [1])......................................................... 50 Figura 23. Imagen binaria tras aplicar el umbral automático calculado (Fuente [1])...........................................................................................................................50 Figura 24. Imagen izquierda, resultado al aplicar el algoritmo de watershed. Imagen derecha: Localización de cada uno de los coches (Fuente [1]).............................. 51 Figura 25. Captura de la aplicación de monitorización de zonas de aparcamiento.... ................................................................................................................................51

64

Retos y oportunidades de movilidad urbana en las ciudades inteligentes. El caso de Ciudad 2020

65

9. Glosario

API: Application Programming Interface BBDD: Base de Datos CDTI: Centro para el Desarrollo Técnico e Industrial CIV: Centro Intermodal Virtual DSRC: Dedicated Short-Range Communications GMM: Gaussian Mixture Model GTFS: General Transit Feed Specification HSI: Human Systems Interface HSV: Hue, Saturation, Value HTTP: Hypertext Transfer Protocol ITS: Intelligent Transportation Systems JSON: JavaScript Object Notation NFC: Near Field Communications OSM: Open Street Maps OTP: Open Trip Planner PC: Personal Computer PHP: PHP Hypertext Pre-processor QR: Quick Response REST: REpresentational State Transfer SOA: Service Oriented Architecture TIC: Tecnologías de la Información y las Comunicaciones WSN: Wireless Sensor Network

67

PLATAFORMA TECNOLÓGICA ESPAÑOLA DE LA CARRETERA (PTC) Goya, 23 - 3º, 28001 Madrid (España) Web: www.ptcarretera.es E-mail:[email protected]

En colaboración con:

Con el apoyo de: