Retos y oportunidades de movilidad urbana en las …...Retos y oportunidades de movilidad urbana en...

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

Retos y oportunidades de movilidad urbana en las ciudades inteligentes.

El caso de Ciudad 2020Autores:

J. Torres Arjona, M. Quintana González, A. Cerezo Beltrán, C. Bravo Hernández, J.M. Menéndez GarcíaGaTV - Universidad Politécnica de Madrid

Nº 05/ 2014Cuadernos Tecnológicos de la PTC

Con la colaboración especial de Indra Sistemas

3

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 ciencia-tecnologí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).

LA COLECCIÓN “CUADERNOS TECNOLÓGICOS DE LA PTC”

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

5

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”

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

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

En colaboración con:

Autores: R. V. J. Torres Arjona, M. Quintana González,

A. Cerezo Beltrán, C. Bravo Hernández, J.M. Menéndez GarcíaG@TV – Universidad Politécnica de Madrid

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

Agenda Estratégica

de Investigación

de la Carretera en España

(2011-2025)

Temáticas: Sub-temáticas:

ITS y movilidad

Desarrollo de aplicaciones que consigan la sinergia de los datos suministrados por el equipamiento ITS ya instalado en

la infraestructura viaria en España

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 intermodalidad Fomento de la cooperación entre los modos de transporte

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

13

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

14

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.

15


17

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,

2. Servicio de rutas intermodales

18


datos proporcionados por operadores de forma directa o a través de Open 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.

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

8

Figura 1. Construcción del grafo (Fuente [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, datos proporcionados por operadores de forma directa o a través de Open 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.

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.

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

19


Las diferencias en los modelos de transporte, situación de los mercados y modelos de negocio hacen que los dominios en los que se alojan estos datos de diversa naturaleza sean muy diferentes, lo que complica encontrar una solución que abarque todas las entidades que componen el entorno y que pueda ser implantada en cualquier escenario.

Por esa razón, se planteó la posibilidad de crear una infraestructura común basada en estándares no discriminativos e interoperables, que sirviera para facilitar y homogeneizar las comunicaciones correspondientes entre operadores, distintos proveedores de datos y servicios, y usuarios.

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

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, orientada a servicios, escalable y segura. Además, debe ser capaz de adoptar protocolos estándar 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 creación de sistemas altamente escalables que reflejan el negocio de la organización que gestione el CIV. A su vez brinda una forma bien definida de exposición e invocación de servicios, lo cual facilita la interacción entre diferentes sistemas propios o de terceros

9

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

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

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

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, orientada a servicios, escalable y segura. Además, debe ser capaz de adoptar protocolos estándar 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 creación de sistemas altamente escalables que reflejan el negocio de la organización que gestione el CIV. A su vez brinda una forma bien definida de exposición e invocación de servicios, lo 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 de paso, recorrido etc.

Datos de sensores/equipamiento instalados en la infraestructura: por ejemplo de cámaras, espiras, sensores de aparcamiento.

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

20


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 de paso, recorrido etc.

• Datos de sensores/equipamiento instalados en la infraestructura: por ejemplo de cámaras, espiras, sensores de aparcamiento.

• Datos de Open Data: publicados por instituciones públicas o comunidades de aficionados 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.

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

10

Datos de Open Data: publicados por instituciones públicas o comunidades de aficionados 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.

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.

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

A modo de ejemplo, para el caso de OpenData, el CIV permite automatizar la ingesta de datos de transporte publicados por el Ayuntamiento de Zaragoza en JSON1, y su adaptación al modelo de datos usado en el CIV. Este proceso incluye la construcción y compilación de un archivo GTFS [5] o la inserción de los datos de aparcamientos públicos, zonas de estacionamiento regulado y la geolocalización de aparcamientos de bicicletas. Todos ellos son leídos de los datos publicados por el Ayuntamiento de Zaragoza en formato JSON para, posteriormente, adaptarlos al servicio requerido.

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

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

21


A modo de ejemplo, para el caso de OpenData, el CIV permite automatizar la ingesta de datos de transporte publicados por el Ayuntamiento de Zaragoza en JSON1 , y su adaptación al modelo de datos usado en el CIV. Este proceso incluye la construcción y compilación de un archivo GTFS [5] o la inserción de los datos de aparcamientos públicos, zonas de estacionamiento regulado y la geolocalización de aparcamientos de bicicletas. Todos ellos son leídos de los datos publicados por el Ayuntamiento de Zaragoza en formato JSON para, posteriormente, adaptarlos al servicio requerido.

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 de tráfico en las zonas con mayor tránsito, así como datos sociales mediante 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.

En la Figura 4 se puede ver la información de utilidad para Ciudad 2020 que publica el Ayuntamiento de Zaragoza, que se puede usar en el servicio de rutas.

En lo que respecta a los datos recogidos directamente de la infraestructura, dentro del proyecto se hizo especial hincapié en el uso de algoritmos de Visión Artificial para la obtención automática de información de la vía a partir de imágenes recogidas por cámaras, que pueden incluso estar ya instaladas en la infraestructuras con fines de control o seguridad. Se desarrollaron algoritmos para la recogida de parámetros de tráfico (intensidad, densidad, velocidad media, etc), seguimiento de trayectorias de peatones y bicicletas, detección de la congestión en intersecciones y detección de la ocupación de plazas libres (Capítulo 4).

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

11

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 de tráfico en las zonas con mayor tránsito, así como datos sociales mediante 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.

En la Figura 4 se puede ver la información de utilidad para Ciudad 2020 que publica el Ayuntamiento de Zaragoza, que se puede usar en el servicio de rutas.

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

En lo que respecta a los datos recogidos directamente de la infraestructura, dentro del proyecto se hizo especial hincapié en el uso de algoritmos de Visión Artificial para la obtención automática de información de la vía a partir de imágenes recogidas por cámaras, que pueden incluso estar ya instaladas en la infraestructuras con fines de control o seguridad. Se desarrollaron algoritmos para la recogida de parámetros de tráfico (intensidad, densidad, velocidad media, etc), seguimiento de trayectorias de peatones y bicicletas, detección de la congestión en intersecciones y detección de la ocupación de plazas libres (Capítulo 4).

Una vez hemos analizado cómo se obtienen las fuentes de información que se tienen en cuenta para el cálculo de las rutas intermodales, pasamos a describir el algoritmo de cálculo desarrollado.

2.2. Creación de rutas La herramienta utilizada 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.

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

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

22


Una vez hemos analizado cómo se obtienen las fuentes de información que se tienen en cuenta para el cálculo de las rutas intermodales, pasamos a describir el algoritmo de cálculo desarrollado.

2.2. Creación de rutas

La herramienta utilizada 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.

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

12

componentes que intervienen en el sistema. Se pueden diferenciar dos partes en cuanto al funcionamiento de la misma:

1. API para la colección de datos o capa de persistencia. 2. API para cubrir los servicios o capa de funcionalidad.

La primera se nutre de datos de diferente naturaleza principalmente asociados a la geolocalización de la ciudad inteligente 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 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 aplicación cliente para que el usuario final pueda realizar sus peticiones y visualizar los resultados correspondientes.

Figura 5. Diagrama de componentes de la plataforma OTP

Con esto se pretende facilitar la adaptación de la plataforma a los diferentes escenarios en los que se puede desplegar. Por un lado se facilita la creación del grafo correspondiente a la zona o ciudad elegida, y por otro se facilita un cliente web ya empaquetado para poder 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:

Figura 5. Diagrama de componentes de la plataforma OTP

23


intervienen en el sistema. Se pueden diferenciar dos partes en cuanto al funcionamiento de la misma:

1. API para la colección de datos o capa de persistencia.

2. API para cubrir los servicios o capa de funcionalidad.

La primera se nutre de datos de diferente naturaleza principalmente asociados a la geolocalización de la ciudad inteligente 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 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 aplicación cliente para que el usuario final pueda realizar sus peticiones y visualizar los resultados correspondientes.

Con esto se pretende facilitar la adaptación de la plataforma a los diferentes escenarios en los que se puede desplegar. Por un lado se facilita la creación del grafo correspondiente a la zona o ciudad elegida, y por otro se facilita un cliente web ya empaquetado para poder 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.

13

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 annotatedStopPoint que se encarga de almacenar los nodos en la base de datos más cercanos a los señalados por el usuario en el mapa. Cuando esta información llega a JourneyPatter se genera un objeto ruta con una referencia y el área en la que se va a calcular la misma. A partir de ahí el objeto principal consulta las diferentes opciones tanto en cuanto a servicios públicos de transporte como a vehículos privados. Con estas opciones se generan muchas posibilidades que serán analizadas mediante una función heurística y un algoritmo de búsqueda que serán explicados posteriormente en la sección 2.2.2.

2.2.1. Generación del grafo

Como se vio en la introducción de este capítulo, es necesario generar los datos de transporte para que el sistema pueda acceder a la información de la zona en la que se desea generar la ruta. Para ello se suelen utilizar los siguientes datos:

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

La de las calles aportada por el mapa OSM y/o por un fichero shapefile (Figura 7). Éste es un formato vectorial de almacenamiento digital donde se guarda la localización de los elementos geográficos y los atributos asociados a ellos.

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

Figura 6. Diagrama de colaboración OTP

24


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 annotatedStopPoint que se encarga de almacenar los nodos en la base de datos más cercanos a los señalados por el usuario en el mapa. Cuando esta información llega a JourneyPatter se genera un objeto ruta con una referencia y el área en la que se va a calcular la misma. A partir de ahí el objeto principal consulta las diferentes opciones tanto en cuanto a servicios públicos de transporte como a vehículos privados. Con estas opciones se generan muchas posibilidades que serán analizadas mediante una función heurística y un algoritmo de búsqueda que serán explicados posteriormente en la sección 2.2.2.

2.2.1. Generación del grafo

Como se vio en la introducción de este capítulo, es necesario generar los datos de transporte para que el sistema pueda acceder a la información de la zona en la que se desea generar la ruta. Para ello se suelen utilizar los siguientes datos:

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

• La de las calles aportada por el mapa OSM y/o por un fichero shapefile (Figura 7). Éste es un formato vectorial de almacenamiento digital donde se guarda la localización de los elementos geográficos y los atributos asociados a ellos.

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

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

14

Figura 7. Ejemplo de shapefile

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

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.

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 un movimiento de coste mayor para alcanzar la solución. Es por

Figura 7. Ejemplo de shapefile

25


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.

26


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 un movimiento de coste mayor para alcanzar la solución. Es por ello bastante intuitivo el hecho de que un buen algoritmo de búsqueda informada debería tener en cuenta ambos 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:

Donde h’(n) representa el valor heurístico del nodo a evaluar desde el actual, n, hasta el final, y g(n) el coste real del camino recorrido para llegar a dicho nodo, n, desde el nodo inicial. A* mantiene dos estructuras de datos auxiliares, que podemos denominar abiertos, implementado como una cola de prioridad (ordenada por el valor f(n) de cada nodo), y cerrados, donde se guarda la información de los nodos que ya han sido visitados. En cada paso del algoritmo, se expande el nodo que esté primero en abiertos, y en caso de que no sea un nodo objetivo, calcula la f(n) de todos sus hijos, los inserta en abiertos, y pasa el 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) tiende a primero en anchura. De este modo, se cambia de camino de búsqueda cada vez que existen nodos más prometedores.

Se pueden enumerar diferente propiedades de este algoritmo:

• Como todo algoritmo de búsqueda en amplitud, A* es un algoritmo completo: en caso de existir una solución, siempre dará con ella.

• Si para todo nodo n del grafo se cumple g(n) = 0, nos encontramos ante una búsqueda voraz. Si para todo nodo n del grafo se cumple: h(n) = 0, A* pasa a ser una búsqueda de coste uniforme no informada.

• Para garantizar que el algoritmo sea óptimo, la función h(n) debe ser heurística admisible, esto es, que no sobrestime el coste real de alcanzar el nodo objetivo.

• De no cumplirse dicha condición, el algoritmo pasa a denominarse simplemente A, y a pesar de seguir siendo completo, no se asegura que el resultado obtenido sea el camino

15

ello bastante intuitivo el hecho de que un buen algoritmo de búsqueda informada debería tener en cuenta ambos 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:

Ecuación 1. Función heurística

Donde h’(n) representa el valor heurístico del nodo a evaluar desde el actual, n, hasta el final, y g(n) el coste real del camino recorrido para llegar a dicho nodo, n, desde el nodo inicial. A* mantiene dos estructuras de datos auxiliares, que podemos denominar abiertos, implementado como una cola de prioridad (ordenada por el valor f(n) de cada nodo), y cerrados, donde se guarda la información de los nodos que ya han sido visitados. En cada paso del algoritmo, se expande el nodo que esté primero en abiertos, y en caso de que no sea un nodo objetivo, calcula la f(n) de todos sus hijos, los inserta en abiertos, y pasa el 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) tiende a primero en anchura. De este modo, se cambia de camino de búsqueda cada vez que existen nodos más prometedores.

Se pueden enumerar diferente propiedades de este algoritmo:

Como todo algoritmo de búsqueda en amplitud, A* es un algoritmo completo: en caso de existir una solución, siempre dará con ella.

Si para todo nodo n del grafo se cumple g(n) = 0, nos encontramos ante una búsqueda voraz. Si para todo nodo n del grafo se cumple: h(n) = 0, A* pasa a ser una búsqueda de coste uniforme no informada.

Para garantizar que el algoritmo sea óptimo, la función h(n) debe ser heurística admisible, esto es, que no sobrestime el coste real de alcanzar el nodo objetivo.

De no cumplirse dicha condición, el algoritmo pasa a denominarse simplemente A, y a pesar de seguir siendo completo, no se asegura que el resultado obtenido sea el camino 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.

Ecuación 1. Función heurística

27


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

28


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í puede estar interesado en reducir 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.

16

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 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í puede estar interesado en reducir los niveles de contaminación en una determinada zona.

Figura 8. Ejemplo de interfaz de selección de costes para el usuario (Fuente [1])

A modo de ejemplo se puede ver en la Figura 9 una ruta que incluye diferentes medios de transporte.

Figura 8. Ejemplo de interfaz de selección de costes para el usuario (Fuente [1])

17

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 distintos servicios de movilidad, como son el transporte público y el estacionamiento privado, a través del teléfono móvil.

Figura 9. Ejemplo de ruta combinando varios medios (Fuente [1])

29


31

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.

3. Plataforma interoperable de pago

32


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.

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.

Figura 10. Esquema modular de la plataforma de pago Ciudad 2020 (Fuente [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.

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

33


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:

34


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,

35


21

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:

Figura 11. Arquitectura física del caso práctico (Fuente [1])

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 11. Arquitectura física del caso práctico (Fuente [1])

22

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

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

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

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

36


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

37


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 proporcionada por PayPal.

23

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 proporcionada por PayPal.

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

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


23

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 proporcionada por PayPal.


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

38


24

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

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.

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


24




3.2.2. Servidor




39



3.2.2. Servidor



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.

40


25

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.

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

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

26

Figura 18. Validación en el modo textual (Fuente [1])

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.

Figura 18. Validación en el modo textual (Fuente [1])

41


43

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.

4. Monitorización de zonas de aparcamiento

44


La aplicación desarrollada sigue un algoritmo basado en el análisis temporal de los frames procedentes de la cámara de vídeo correspondiente. El procesado se puede descomponer en un conjunto de bloques funcionales tal y como se presenta en la Figura 19.

A continuación, se describen en profundidad cada uno de los bloques implementados así como el proceso de validación correspondiente a cada uno de ellos. Además, al final se comenta el tratamiento especial que se realiza durante transiciones día/noche y noche/día que permiten al sistema funcionar durante 24 horas si las condiciones de iluminación lo permiten.

4.1. Módulo de Inicialización.

En el módulo de inicialización, la aplicación utiliza información introducida manualmente acerca de la escena para comenzar a funcionar:

• Zonas de aparcamiento. Aquellas regiones en las que está permitido el estacionamiento de vehículos.

• Opcionalmente, si se desea crear un mapa detallado de la escena diferenciando plazas individuales, se puede delimitar el contorno correspondiente a cada una de las plazas, dado que el algoritmo propuesto no incluye la funcionalidad de identificación automática de plazas individuales. Con dicha información, la aplicación generará el mapa correspondiente.

28

Figura 19. Diagrama de bloques del sistema de detección de aparcamiento libre (Fuente

[1])

A continuación, se describen en profundidad cada uno de los bloques implementados así como el proceso de validación correspondiente a cada uno de ellos. Además, al final se comenta el tratamiento especial que se realiza durante transiciones día/noche y noche/día que permiten al sistema funcionar durante 24 horas si las condiciones de iluminación lo permiten.

4.1. Módulo de Inicialización. En el módulo de inicialización, la aplicación utiliza información introducida manualmente acerca de la escena para comenzar a funcionar:

Zonas de aparcamiento. Aquellas regiones en las que está permitido el estacionamiento de vehículos.

Opcionalmente, si se desea crear un mapa detallado de la escena diferenciando plazas individuales, se puede delimitar el contorno correspondiente a cada una de las plazas, dado que el algoritmo propuesto no incluye la funcionalidad de identificación automática de plazas individuales. Con dicha información, la aplicación generará el mapa correspondiente.

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

Inicialización y calibración

Sustracción de fondo

Mapa de transiciones

Control de oclusiones

Modelo escena

Caracterización plazas (alto

nivel)

α

Presentación

Asociación y tracking

Framesvídeo

Detección de aparcamiento

/salida

Figura 19. Diagrama de bloques del sistema de detección de aparcamiento libre (Fuente [1])

45


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

46


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

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.

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.

29

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.

4.3. Módulo de detección de objetos de interés (Sustracción de fondo) 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.

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 (GMM3) [19] y mapa de transiciones [20] que dan máscaras de blobs transitorios (Figura 20).

(a)

(b)

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

3 Del inglés, Gaussian Mixture Model.

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

47


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

48


tendrá unas dimensiones similares a la longitud del coche y en el caso de aparcamiento en línea, MetrosAnchura tendrá unas dimensiones similares al ancho del coche.

También se muestra en formato gráfico, representando sobre el frame actual las plazas libres (en verde) y las ocupadas (en rojo).

Como se puede observar en la Figura 21, la interfaz gráfica muestra gráficamente y textualmente las zonas libre existentes en la bolsa de aparcamiento, así como la longitud del espacio libre.

El cálculo de los espacios libres se basa en el estudio del ángulo de una de las rectas que definen cada una de las regiones de aparcamiento. De las cuatros rectas que delimitan cada región, se estudia el ángulo de la recta con mayor longitud, el ángulo se calcula con la arco-tangente de los puntos inicio y final de la recta.

Por cada frame procesado, se estudian posteriormente las zonas libres que quedan 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.

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

31

en batería tendrá unas dimensiones similares a la longitud del coche y en el caso de aparcamiento en línea, MetrosAnchura tendrá unas dimensiones similares al ancho del coche. También se muestra en formato gráfico, representando sobre el frame actual las plazas libres (en verde) y las ocupadas (en rojo).

(a)

(b)

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

Como se puede observar en la Figura 21, la interfaz gráfica muestra gráficamente y textualmente las zonas libre existentes en la bolsa de aparcamiento, así como la longitud del espacio libre. El cálculo de los espacios libres se basa en el estudio del ángulo de una de las rectas que definen cada una de las regiones de aparcamiento. De las cuatros rectas que delimitan cada región, se estudia el ángulo de la recta con mayor longitud, el ángulo se calcula con la arco-tangente de los puntos inicio y final de la recta. Por cada frame procesado, se estudian posteriormente las zonas libres que quedan entre los coches estacionados. Para cada una de las zonas:


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

que pertenece. d) Aquel lado, cuyo ángulo se encuentre más próximo al ángulo de la región, será

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 cuenta que si la región de aparcamiento es en línea, considerando que la longitud de una plaza de aparcamiento es L_plaza (una constante a definir por el gestor), en las zonas libres en línea, el cálculo se realiza de la siguiente forma:

Por otro lado, si la región de aparcamiento es en batería, y considerando que la 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:


49


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



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 buenas tasas de detección cuando en la escena existe iluminación suficiente. Para aquellos escenarios en los que la luz existente no sea la necesaria para el correcto funcionamiento del sistema, se podrían desarrollar otros algoritmos de visión, por ejemplo basados en la iluminación de los faros de los coches. Por ello se ha implementado un algoritmo que detecta las transiciones de las condiciones de luminosidad.

El algoritmo que permite detectar cuándo existe suficiente iluminación para que el sistema funcione correctamente está basado en el espacio de color de HSV. Se analiza en cada frame, la media de los valores de color en la zona correspondiente a asfalto dentro del parking seleccionada previamente. Utilizando para ello dos umbrales para hacer la transición estimados empíricamente. Cuando la media del nivel de color del asfalto de una imagen concreta se halla por debajo del umbral de día, se considera que la escena ha cambiado a estado nocturno. En estado nocturno, si la media del 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 de nuevo el algoritmo de detección de plazas descrito. Esta rutina también se basa en el estudio de color en el espacio HSV. Para ello, se analizaron cada uno de los tres canales de HSV por separado, llegando a la conclusión, que es el canal H, el que mejor resultados producía.

31

en batería tendrá unas dimensiones similares a la longitud del coche y en el caso de aparcamiento en línea, MetrosAnchura tendrá unas dimensiones similares al ancho del coche. También se muestra en formato gráfico, representando sobre el frame actual las plazas libres (en verde) y las ocupadas (en rojo).

(a)

(b)


Como se puede observar en la Figura 21, la interfaz gráfica muestra gráficamente y textualmente las zonas libre existentes en la bolsa de aparcamiento, así como la longitud del espacio libre. El cálculo de los espacios libres se basa en el estudio del ángulo de una de las rectas que definen cada una de las regiones de aparcamiento. De las cuatros rectas que delimitan cada región, se estudia el ángulo de la recta con mayor longitud, el ángulo se calcula con la arco-tangente de los puntos inicio y final de la recta. Por cada frame procesado, se estudian posteriormente las zonas libres que quedan entre los coches estacionados. Para cada una de las zonas:


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

que pertenece. d) Aquel lado, cuyo ángulo se encuentre más próximo al ángulo de la región, será

el que defina la longitud de la zona de aparcamiento y a partir del cual el número de espacios libres debe ser calculado.



32

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 buenas tasas de detección cuando en la escena existe iluminación suficiente. Para aquellos escenarios en los que la luz existente no sea la necesaria para el correcto funcionamiento del sistema, se podrían desarrollar otros algoritmos de visión, por ejemplo basados en la iluminación de los faros de los coches. Por ello se ha implementado un algoritmo que detecta las transiciones de las condiciones de luminosidad.

El algoritmo que permite detectar cuándo existe suficiente iluminación para que el sistema funcione correctamente está basado en el espacio de color de HSV. Se analiza en cada frame, la media de los valores de color en la zona correspondiente a asfalto dentro del parking seleccionada previamente. Utilizando para ello dos umbrales para hacer la transición estimados empíricamente. Cuando la media del nivel de color del asfalto de una imagen concreta se halla por debajo del umbral de día, se considera que la escena ha cambiado a estado nocturno. En estado nocturno, si la media del 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 de nuevo el algoritmo de detección de plazas descrito. Esta rutina también se basa en el estudio de color en el espacio HSV. Para ello, se analizaron cada uno de los tres canales de HSV por separado, llegando a la conclusión, que es el canal H, el que mejor resultados producía.

50


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.

33

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])


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 ejecutado, se consiguen localizar los coches por separado como muestra la Figura 24.

carnocar

h

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])

33

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])




carnocar

h


51



Finalmente, en la Figura 25 se puede apreciar una captura de pantalla de la aplicación desarrollada.

34

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 desarrollada

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

34

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 desarrollada


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


53

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.

5. Conclusiones

54


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.

55


57

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)

6. Agradecimientos

59

[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

7. Bibliografía y referencias

60


[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 Video-Based 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.

61


63

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

8. Índice de figuras

64


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

65


67

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

9. Glosario

Con el apoyo de:

En colaboración con:

PLATAFORMA TECNOLÓGICA ESPAÑOLA DE LA CARRETERA (PTC)Goya, 23 - 3º, 28001 Madrid (España)

Web: www�ptcarretera�esE-mail:info@ptcarretera�es

Retos y oportunidades de movilidad urbana en las …...Retos y oportunidades de movilidad urbana en...

Documents

Transcript of Retos y oportunidades de movilidad urbana en las …...Retos y oportunidades de movilidad urbana en...