ESTUDIOS DE I+D+I

Nuacutemero 57

Sistema de informacioacuten al viajero de autobuacutes accesible para todos

Autores Domiacutenguez Morrondo Fernando Filiacioacuten Page Ibeacuterica SA Contacto Fecha 2005

Para citar este documento

DOMIacuteNGUEZ MORRONDO Fernando (Convocatoria 2005) ldquoSistema de informacioacuten al viajero de autobuacutes accesible para todosrdquo Madrid Estudios de I+D+I nordm 7 [Fecha de publicacioacuten 06052010] lthttpwwwimsersomayorescsicesdocumentosdocumentosimserso-estudiosidi-57pdfgt

Una iniciativa del IMSERSO y del CSIC copy 2003

Portal Mayores httpwwwimsersomayorescsices

Resumen

El objetivo es disentildear desarrollar e implementar un sistema de informacioacuten para viajeros de autobuacutes accesible para todos que informe a los viajeros que estaacuten esperando en las paradas de autobuacutes de cuando pasaraacute el proacuteximo autobuacutes de cada liacutenea cuales son los horarios de autobuses y que autobuses estaacuten adaptados para poder transportar sillas de ruedas

La informacioacuten se daraacute por medio de panales luminosos y por medio de un menuacute vocal para hacer dicha informacioacuten accesible para todos La propuesta aborda la elaboracioacuten de un proyecto piloto que engloba tres fases

En una primera fase se desarrollaraacute un prototipo inicial (hardware y software) que permitiraacute probar el funcionamiento global del sistema en condiciones reales y maacutes particularmente probar y validar las interfaces destinadas al usuario En una segunda fase se contempla la implementacioacuten del sistema de informacioacuten en el nuacutecleo urbano de Majadahonda realizando un proyecto piloto que se instalaraacute donde se considere maacutes oportuno

En una fase paralela a ambas se elaboraraacute en conjunto con las diferentes instituciones implicadas el estudio que serviraacute de base para la validacioacuten de las especificaciones de cara a un futuro crecimiento

Portal Mayores httpwwwimsersomayorescsices

Autobus SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Autobus SIVAAT-PARDEM 1

(Especificacion Tecnica) 1

1 INTRODUCCIOacuteN 2

2 Localizacioacuten de autobuses 2

3 Moacutedulo de aplicaciones del sistema embarcado (OBU) 2

AG 33sivaat 12092007 125600 127

1 INTRODUCCIOacuteN

En este documento se indica el desarrollo para los autobuses realizado como parte del desarrollo del sistema SIVAAT-PARDEM (Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda oacute PARDEM)

2 Localizacioacuten de autobuses

La funcioacuten de localizacioacuten de autobuses puede tener una repercusioacuten importante en los costes y por ello se decidieron analizar varias alternativas incluyendo la utilizacioacuten de receptores GPS la utilizacioacuten de balizas WiFi y la utilizacioacuten de un Terminal telefoacutenico para ubicar la posicioacuten del autobuacutes en base a las ceacutelulas visibles en cada momento por dicho terminal Tras los primeros anaacutelisis se descartoacute la utilizacioacuten de servicios de localizacioacuten ofrecidos por los operadores de telefoniacutea moacutevil debido a su coste excesivo para este tipo de aplicaciones Con respecto a la utilizacioacuten de balizas Wifi se han realizado pruebas con un nodo de acceso fijo y un nodo Wifi moacutevil y se ha concluido lo siguiente

Breve descriopcioacuten de desarrollos pruebas y Conclusiones Con respecto a la utilizacioacuten de la informacioacuten de ceacutelulas GSM Breve descriopcioacuten de desarrollos pruebas y Conclusiones Por todo ello el sistema de localizacioacuten finalmente implementado tras los resultados obtenidos en la pruebas utiliza en el terminal embarcado la sentildeal del odoacutemetro del autobuacutes la sentildeal de apertura de puertas la estimacioacuten realizada por un receptor GPS y una base de datos de la topologiacutea de las liacuteneas con las coordenadas de puntos de control predefinidos la distancia entre ellos la ruta y la liacutenea a la que pertenecen y un listado de la secuencia de viajes realizados por el autobuacutes Soacutelo teniendo en cuenta toda esta informacioacuten es posible realizar una estimacioacuten autoacutenoma de la posicioacuten del autobuacutes con las posibles excepciones que pueden tener lugar en el servicio y con la precisioacuten suficiente para estimar tiempos de llegada adecuados Por otro lado la realizacioacuten de una estimacioacuten de la localizacioacuten de forma totalmente autoacutenoma es imprescindible para optimizar las comunicaciones de datos entre los autobuses y el centro Este meacutetodo de localizacioacuten funciona satisfactoriamente en la prueba y se pondraacute a prueba en otra liacutenea maacutes compleja Salvo en el caso de la localizacioacuten no se han identificado otros factores relevantes inesperados por lo que el resto de las liacuteneas de trabajo (Comunicaciones de datos Centro compartido y Difusioacuten de informacioacuten a los usuarios) se describen dentro de la descripcioacuten global del sistema implementado que se aborda en el siguiente apartado La uacuteltima liacutenea de trabajo (Gestioacuten del traacutefico de autobuses en intercambiadores) se trata maacutes abajo en un apartado independiente

3 Moacutedulo de aplicaciones del sistema embarcado (OBU)

Consta de dos aplicaciones fundamentales

AG 33sivaat 12092007 125600 227

1 Aplicacioacuten para la captura de datos de la Red y Servicio

2 Aplicacioacuten principal del sistema embarcado Aplicacioacuten para la captura de datos de la Red y Servicio

Constituye el modo de funcionamiento del sistema que se utiliza para la obtencioacuten de datos cada vez que se instale en iTRA una nueva liacutenea de servicio Esta aplicacioacuten permite

Realizar pruebas en los aspectos relacionados con la cobertura GPS existente en el

recorrido que realizan los autobuses y cobertura disponibilidad y costes del servicio GPRS

Recoger los datos necesarios para elaborar la base de datos topoloacutegica de las liacuteneas

(ubicacioacuten de las paradas y seleccioacuten de puntos de control) y tiempos de recorrido entre

puntos de control

El OBU registra una serie de eventos de arranque perioacutedicos de detencioacuten y en parada para obtener datos de posicioacuten velocidad pulsos de odoacutemetro informacioacuten sobre la cobertura GPS Para obtener el Cell ID y el LAC es necesario usar la funcioacuten para enviar comando directamente al MODEM en formato AT Cada vez que el conductor apaga el autobuacutes (llave de contacto en off) el OBU cierra el fichero y lo enviacutea al servidor viacutea GPRS a traveacutes de un protocolo establecido entre el OBU y el Distpacher Una vez tenga constancia de que el fichero ha sido recibido en el servidor borra el fichero y desconecta el releacute de alimentacioacuten apagaacutendose Aplicacioacuten principal del sistema embarcado

El OBU basa parte de su funcionamiento en datos que tiene almacenados en forma de ficheros de configuracioacuten Este consta de tres ficheros uno que almacena datos que determinan ciertos comportamientos del equipo y otros dos con informacioacuten de lineas rutas y puntos La funcionalidad fundamental del OBU es la de reportar el paso por determinados puntos definidos en el sistema paradas puntos de control cabeceras fin de viaje etc Esto se lleva a cabo mediante un proceso que estaacute obteniendo en todo momento las coordenadas GPS y la distancia recorrida por el autobuacutes seguacuten odoacutemetro de manera que pueda estar comprobando a la vez si ha recorrido la distancia del ultimo punto reportado al siguiente o si seguacuten el GPS se encuentra en un entorno de ese punto

El OBU tiene un proceso concurrente que esta atendiendo en todo momento una vez esteacute en funcionamiento una posible peticioacuten desde el servidor esto lo usa el CG para poder solicitar en cualquier momento la posicioacuten en la que se encuentra el autobuacutes con el objetivo de rectificar tiempos Paralelamente se estaacute atendiendo cualquier evento propio del modulo GSM del OBU que pueda afectar la comunicacioacuten del mismo con el servidor de manera que esta comunicacioacuten pueda ser restablecida inmediatamente levantando nuevamente la sesioacuten GPRS ya que el mantener la misma es algo critico e imprescindible dentro del sistema A la vez que las otras funcionalidades el OBU lleva el control de la ocurrencia de ciertos eventos loacutegicos que se han definido en el sistema como son el tiempo que transcurre donde el autobuacutes tiene velocidad cero si se ha puesto el contacto de la llave en OFF si se ha pulsado el botoacuten de fuera de servicio si se ha llegado al uacuteltimo viaje entrada en el entorno de un punto salida del entorno de un punto etc Algunos de estos eventos generan comunicacioacuten con el servidor para reportar la ocurrencia de los mismos como son el caso del apagado del autobuacutes la pulsacioacuten del botoacuten la terminacioacuten del uacuteltimo viaje y el excederse del tiempo predefinido con velocidad cero Una vez que el OBU sale de su funcionamiento normal sea cual sea la causa y esteacute listo para apagarse entra en un proceso donde verifica la versioacuten del software que el

AG 33sivaat 12092007 125600 327

servidor tiene disponible como vaacutelida de manera que si esta difiere de la actual procede a actualizarla Todas las comunicaciones con el servidor se realizan mediante protocolos de

comunicacioacuten propietarios disentildeados e implementados para cada tarea especifica del sistema que se soportan encima del protocolo UDP

AG 33sivaat 12092007 125600 427

Centro de Gestion SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Centro de Gestion SIVAAT-PARDEM 5

(Especificacion Tecnica) 5

1 INTRODUCCIOacuteN 6

2 Arquitectura loacutegica del sistema 6

3 Moacutedulos principales del sistema 6

4 Gestor de mensajes y distribuidor (Distpacher) 7

5 Composicioacuten del Centro 8

6 Moacutedulo WEB 8

AG 33sivaat 12092007 125600 527

4 INTRODUCCIOacuteN

En este documento se indica el desarrollo para el Centro de Gestion realizado como parte del desarrollo del sistema SIVAAT-PARDEM (Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda oacute PARDEM)

5 Arquitectura loacutegica del sistema

La solucioacuten del sistema se basa en una arquitectura multicapas capa Cliente capa Servidor y capa del Sistema de informacioacuten empresarial

En la parte cliente se encuentran todos los usuarios en general es decir todos los que interactuacutean con el Centro de Gestioacuten moacuteviles parada a la demanda (PBD) unidad embarcada (OBU) y alguacuten cliente Web En esta parte se han implementado la loacutegica necesarias sobre la parte embarcada (OBU) La capa Servidor es la maacutes importante pues contendraacute toda la loacutegica de negocio Esta se compone de varios componentes de servidor que son los encargados de procesar la informacioacuten almacenada con el objetivo de elaborar una respuesta como resultado de una peticioacuten desde los distintos tipos de clientes Tambieacuten contiene un grupo de componentes con una funcionalidad de gestioacuten sobre los datos del sistema ya sea informativa o de administracioacuten El Dispatcher es el moacutedulo responsable de atender todas las peticiones SMS y GPRS

del sistema y darles el curso correspondiente dentro de la loacutegica de negocio y con los protocolos adecuados seguacuten la naturaleza de la peticioacuten asiacute como enviar solicitudes de manera automaacutetica hacia dichos dispositivos Se trata de un interfaz entre los dispositivos perifeacutericos del sistema (paradas autobuses y SMSs de usuario PARDEM) y el Centro de Gestioacuten El sistema cuenta con una capa de datos que almacena toda la informacioacuten necesaria para el correcto funcionamiento del sistema Aquiacute se almacena todo lo relativo a las liacuteneas a las que se les ofrece el servicio asiacute como las rutas servicios (coches) y autobuses de las mismas (Base de datos de la Red) Tambieacuten se guarda informacioacuten sobre las peticiones atendidas por el sistema eventos e incidencias (Base de Datos de Servicio) informacioacuten que sirve de base para generar los informes que se presentan en la WEB que permitiraacuten hacer estudios de explotacioacuten que ayuden a mejorar y hacer mas eficiente el sistema

6 Moacutedulos principales del sistema

AG 33sivaat 12092007 125600 627

Servidor de Aplicaciones JAVA

Moacutedulo WEB Centro de Gestioacuten

Aplicacioacuten WEB

(Cocoon)

Online

Consultas

Informes

Gestor de Informacioacuten de localizacioacuten y estado

Gestor de Informacioacuten de Peticiones

Gestor de Histoacutericos

Base de

Datos

Distpacher

Interfaz entre dispositivos

moacuteviles y el Centro de

Gestioacuten

Carga de Datos de

la Red

Teleacutefonos moacuteviles SMS

GSM

Usuario WEB

HTTP

Usuario

Carga de Datos

OBU

Owasys

Moacutedulo de Captura

de Datos

Aplicacioacuten del

Sistema

Embarcado

Fig

El Sistema estaacute dividido en 5 subsistemas o moacutedulos principales igrave Moacutedulo de aplicaciones de la Parada

igrave Moacutedulo de aplicaciones del sistema embarcado (OBU)

igrave Gestor de mensajes y distribuidor (Distpacher)

igrave Centro de Gestioacuten

Moacutedulo WEB

7 Gestor de mensajes y distribuidor (Distpacher)

El moacutedulo Dispatcher es un interfaz entre los dispositivos perifeacutericos del sistema (moviles y fijos) y el Centro de Gestioacuten Por un lado estaacute el Centro de Gestioacuten con una comunicacioacuten viacutea Intranet con HTTP con un protocolo basado en XML (Extensible Markup Language) y por otro los teleacutefonos moacuteviles los OBU y las paradas La comunicacioacuten con los teleacutefonos moacuteviles se realiza a traveacutes de SMS La comunicacioacuten con los OBU y con las paradas se realiza viacutea Internet con protocolo UDP (User Datagram Protocol) Al Dispatcher van conectados tres modems GSM modelo Siemens TC45 que son los encargados de recibir y enviar los mensajes en principio uno por cada operador de telefoniacutea moacutevil en Espantildea Estos modems TC45 soportan el leguaje de programacioacuten Java y poseen una Maacutequina Virtual Java (JVM) propietaria de Siemens para ello

AG 33sivaat 12092007 125600 727

EL Distpacher es el moacutedulo que gestiona todo el proceso de atencioacuten de peticiones viacutea UDP instanciando un hilo para cada OBU de autobuacutes y para cada parada Este hilo efectua todo el proceso para dicho OBU y cuando se recibe un EOT (End Off Transmission) se elimina ese hilo eliminaacutendose de la tabla de hilos Es decir cuando el autobuacutes o parada realizan una peticioacuten UDP el Dispatcher comprueba si tiene su hilo activo y si no lo instancia Todas las peticiones a traveacutes del protocolo establecido tienen el identificador del peticioinario Si el identificador no se encuentra en el fichero de configuracioacuten entonces la peticioacuten es ignorada

8 Composicioacuten del Centro

El centro de gestioacuten consta de tres moacutedulos principales

Gestor de Informacioacuten de localizacioacuten y estado Gestiona la informacioacuten relacionada con el

estado de los autobuses y su posicioacuten

igrave Asignar autobuses a liacuteneas rutas y coches

igrave Determinacioacuten de la ubicacioacuten y estado de los autobuses

igrave Conocer queacute autobuses estaacuten actualmente en servicio y en queacute liacutenea y ruta estaacuten y van

a estar prestando servicio en los proacuteximos T minutos

igrave Conocer queacute autobuses entraraacuten en servicio en las rutas de intereacutes en los proacuteximos T

minutos

igrave Conocer queacute autobuses dejaraacuten el servicio que estaacuten prestando en las rutas de intereacutes

en los proacuteximos T minutos

Gestor de Informacioacuten de Peticiones Gestiona la informacioacuten relacionada con las peticiones

de los usuarios

igrave Anaacutelisis continuo de las solicitudes

Gestor de Histoacutericos Gestiona toda la informacioacuten relacionada con los histoacutericos de

solicitudes servicio de autobuses y eventos

9 Moacutedulo WEB

Las moacutedulos principales que se presentaraacuten en la WEB son ONLINE Tiempo Real

Consultas Informes

Trazas de la Aplicacioacuten

Actualizacioacuten OBU de autobuses y paradas

A traveacutes del moacutedulo ONLINE es posible visualizar en tiempo real el comportamiento de Autobuses Informacioacuten relacionada con los autobuses que pertenecen a una liacutenea

determinada en cuanto a tiempos de recorridos reales retrasosadelantos etc

Solicitudes Todas las solicitudes activas o las recibidas desde el inicio del servicio

Incidencias Se visualizan todas las incidencias recibidas desde el inicio del servicio

incidencias relacionadas con los autobusesparadas servicio de autobuses solicitudes

AG 33sivaat 12092007 125600 827

Traza de aplicacioacuten

A traveacutes del moacutedulo Consultas Informes es posible obtener informacioacuten del Histoacuterico del sistema iTRA en temas de Tiempos de recorrido

A traveacutes de esta consulta el usuario puede visualizar y comparar los tiempos de recorridos teoacutericos y reales teniendo en cuenta los datos registrados en el Centro de Gestioacuten para cada uno de los autobuses en las diferentes liacuteneas Pueden ser Tiempos de recorrido para una liacutenea y ruta determinada o Tiempos de recorrido entre dos paradas

Horas de salida de cabeceras

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de salida de cabecera estimado y real

Hora de paso por paradas

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de paso por paradas estimado y real

Incidencias

Se puede obtener una tabla con la informacioacuten sobre las incidencias del vehiacuteculo o la

parada en el diacutea a partir de la seleccioacuten de una Fecha Liacutenea yo Tipo de Incidencia

presentaacutendose una lista con los resultados de la consulta

Solicitudes

Se puede obtener una tabla con informacioacuten completa sobre la situacioacuten de las solicitudes

al seleccionar en el menuacute principal esta opcioacuten

A traveacutes del moacutedulo Trazas de la Aplicacioacuten se presenta el registro de la aplicacioacuten a partir de la seleccioacuten realizada por el usuario Fecha determinada

Entre Fechas

Por moacutedulos

A traveacutes del moacutedulo Actualizacioacuten OBU o Actualizacioacuten Parada se puede actualizar el software instalado en los OBU o en las paradas viacutea ftp

AG 33sivaat 12092007 125600 927

Parada

Indice

Parada 10

1 INTRODUCCIOacuteN 11

2 SERVICIOS 11

3 COMPOSICION 11

4 DISTRIBUCION DE EQUIPAMIENTO 13

5 NECESIDADES PREVIAS A LA INSTALACION 18

6 DESCRIPCION HW 18

7 DESCRIPCION SW 18

8 COMUNICACIOacuteN CON CENTRO DE GESTION (CG) 19

9 ASPECTOS DE USUARIO 19

10 CONFIGURACION Y MANTENIMIENTO 19

11 REFERENCIAS 19

AG 33sivaat 12092007 125600 1027

10 INTRODUCCIOacuteN

Como se indica en la descripcioacuten del sistema la Parada estaacute para proporcionar interaccioacuten con el usuario para los servicios SIVAAT (Sistema de Informacioacuten al Viajero de Autobuacutes Accesible para Todos) y para los servicios PARDEM (PARada a la DEManda)

11 SERVICIOS

Tanto servicios SIVAAT como PARDEM Dicho de otro modo proporciona interaccioacuten a los usuarios

bull Normales- A traveacutes de Display y teclas

bull Discapacitados Auditivos- A traveacutes de Display y teclas

bull Discapacitados Visuales- A traveacutes de altavoz y teclas previa lectura de

tarjeta FRID

bull Discapacitados Visuales- tras la lectura de tarjeta RFID y peticioacuten de info

mediante tecla se mostraraacute tanto el proacuteximo autobuacutes como el proacuteximo de

plataforma baja (si lo hubiere)

Asimismo permite realizar peticiones con efecto sobre el conductor de autobuses bull En el caso de Discapacitado Visual se le indica al conductor del autobuacutes

bull En el caso de Discapacitado Fiacutesico tambieacuten se le indica al conductor del

autobuacutes de plataforma baja correspondiente

bull En el caso de haber pulsado tecla de PARada a la DEManda tambieacuten se le indica

al conductor del autobuacutes correspondiente para cualquier tipo de usuario

12 COMPOSICION

Para la realizacioacuten de la necesaria interaccioacuten tanto con el usuario (de distintos tipos) y con el resto del sistema a traveacutes de la comunicacioacuten con el Centro de Gestioacuten (CG) se utiliza un sistema de microprocesador con Sw basado en Linux con el esquema de bloques HW que se indicada en la siguiente figura compuesta de

bull Unidad de Control con el procesador y Sw basado en Linux que controla toda

la parada

bull Detector de Presencia capaz de distinguir la presencia de personas y no la de

coches o pequentildeos animales

bull Lector de tarjeta RFID del tipo tarjeta Sube-T usada en el consorcio de

transportes de la comunidad de Madrid Lee la identidad de la tarjeta

bull Teclas y LEDs de iluminacioacuten con teclas antivandaacutelicas y diodos LED de

iluminacioacuten para permitir la realizacioacuten de peticiones de usuario (cualquiera que

sea el tipo) y para permitir la lectura nocturna de la info impresa junto a las

teclas acerca de las lineas que pasan por la parada

AG 33sivaat 12092007 125600 1127

bull Modem GPRS para comunicacioacuten con el Centro de Gestioacuten (CG) para permitir

interaccion con el resto del sistema

bull Modem BlueTooth para comunicacioacuten con Consola de Mantenimiento

(Consola) situada a escasos metros de la parada usando comunicacioacuten sin hilos

bull Display para proporcionar tanto indicaciones de uso como informacioacuten horaria

y de llegadas previstas de autobuses Es del tipo grafico de frac14 de VGA

bull Altavoz para proporcionar indicaciones sonoras Es del tipo intemperie

bull Sistema de Alimentacioacuten para proporcionar energia a todo el sistema de la

Parada Toma energia de la red de alumbrado (durante la noche) por lo que

necesita bateriacuteas ya que durante el diacutea no llega energiacutea

bull Consola de Mantenimiento se usaraacute solo para pruebas de puesta a punto y

para mantenimiento o ciertos cambios de configuracioacuten en las paradas

ldquoprototipordquo Se comunica a traveacutes de comunicacioacuten inalaacutembrica del tipo

BlueTooth Para un despliegue masivo de paradas debe realizarse a traveacutes de

GPRS e integraacutendolo con el Centro de Gestioacuten (CG)

AG 33sivaat 12092007 125600 1227

76

Unidad

Control

(CPU)

Teclado + LEDs

Expansor

de Puertos

Display

Altavoz

Detector

Presencia

Sistema de

Alimentacion

(en techo)

Modem GPRS

Lector

Tarjeta RFID

Puerto

Mantenimiento

(Modem BlueTooth)

Ethernet

Serie RS 232

4

10

8

Serie RS 232

Serie RS 232

Nota Hilos a la alimentacioacuten no representados

Antena

Fig1 Diagrama de bloques de la Parada

13 DISTRIBUCION DE EQUIPAMIENTO

En la siguiente figura aparece una foto de una parada (donde se equipara uno de los prototipos) asiacute como un detalle de la columna ancha donde va encastrada una caja de material plaacutestico con la mayor parte de los componentes del sistema (todos menos el sistema de alimentacioacuten y el detector de presencia) estos van en sobre refuerzo a realizar sobre la columna ancha a modo de techo plano interior bajo el techo curvo de plaacutestico

AG 33sivaat 12092007 125600 1327

Fig2 Vistas de parada y poste ancho donde se coloca la caja encastrada en

lugar de los carteles informativos

La caja encastrada contiene bull El display bull Las teclas de liacuteneas bull Los textos impresos descriptivos de las liacuteneas con su iluminacioacuten bull Las pegatinas transparentes externas por liacutenea-ruta para poner al lado de cada

tecla con la escritura en coacutedigo Braille bull El lector de tarjeta RFID bull El altavoz

Ademaacutes tambieacuten figuran en el interior de esta caja bull La Unidad de Control (CPU)

AG 33sivaat 12092007 125600 1427

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

Autobus SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Autobus SIVAAT-PARDEM 1

(Especificacion Tecnica) 1

1 INTRODUCCIOacuteN 2

2 Localizacioacuten de autobuses 2

3 Moacutedulo de aplicaciones del sistema embarcado (OBU) 2

AG 33sivaat 12092007 125600 127

1 INTRODUCCIOacuteN

En este documento se indica el desarrollo para los autobuses realizado como parte del desarrollo del sistema SIVAAT-PARDEM (Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda oacute PARDEM)

2 Localizacioacuten de autobuses

La funcioacuten de localizacioacuten de autobuses puede tener una repercusioacuten importante en los costes y por ello se decidieron analizar varias alternativas incluyendo la utilizacioacuten de receptores GPS la utilizacioacuten de balizas WiFi y la utilizacioacuten de un Terminal telefoacutenico para ubicar la posicioacuten del autobuacutes en base a las ceacutelulas visibles en cada momento por dicho terminal Tras los primeros anaacutelisis se descartoacute la utilizacioacuten de servicios de localizacioacuten ofrecidos por los operadores de telefoniacutea moacutevil debido a su coste excesivo para este tipo de aplicaciones Con respecto a la utilizacioacuten de balizas Wifi se han realizado pruebas con un nodo de acceso fijo y un nodo Wifi moacutevil y se ha concluido lo siguiente

Breve descriopcioacuten de desarrollos pruebas y Conclusiones Con respecto a la utilizacioacuten de la informacioacuten de ceacutelulas GSM Breve descriopcioacuten de desarrollos pruebas y Conclusiones Por todo ello el sistema de localizacioacuten finalmente implementado tras los resultados obtenidos en la pruebas utiliza en el terminal embarcado la sentildeal del odoacutemetro del autobuacutes la sentildeal de apertura de puertas la estimacioacuten realizada por un receptor GPS y una base de datos de la topologiacutea de las liacuteneas con las coordenadas de puntos de control predefinidos la distancia entre ellos la ruta y la liacutenea a la que pertenecen y un listado de la secuencia de viajes realizados por el autobuacutes Soacutelo teniendo en cuenta toda esta informacioacuten es posible realizar una estimacioacuten autoacutenoma de la posicioacuten del autobuacutes con las posibles excepciones que pueden tener lugar en el servicio y con la precisioacuten suficiente para estimar tiempos de llegada adecuados Por otro lado la realizacioacuten de una estimacioacuten de la localizacioacuten de forma totalmente autoacutenoma es imprescindible para optimizar las comunicaciones de datos entre los autobuses y el centro Este meacutetodo de localizacioacuten funciona satisfactoriamente en la prueba y se pondraacute a prueba en otra liacutenea maacutes compleja Salvo en el caso de la localizacioacuten no se han identificado otros factores relevantes inesperados por lo que el resto de las liacuteneas de trabajo (Comunicaciones de datos Centro compartido y Difusioacuten de informacioacuten a los usuarios) se describen dentro de la descripcioacuten global del sistema implementado que se aborda en el siguiente apartado La uacuteltima liacutenea de trabajo (Gestioacuten del traacutefico de autobuses en intercambiadores) se trata maacutes abajo en un apartado independiente

3 Moacutedulo de aplicaciones del sistema embarcado (OBU)

Consta de dos aplicaciones fundamentales

AG 33sivaat 12092007 125600 227

1 Aplicacioacuten para la captura de datos de la Red y Servicio

2 Aplicacioacuten principal del sistema embarcado Aplicacioacuten para la captura de datos de la Red y Servicio

Constituye el modo de funcionamiento del sistema que se utiliza para la obtencioacuten de datos cada vez que se instale en iTRA una nueva liacutenea de servicio Esta aplicacioacuten permite

Realizar pruebas en los aspectos relacionados con la cobertura GPS existente en el

recorrido que realizan los autobuses y cobertura disponibilidad y costes del servicio GPRS

Recoger los datos necesarios para elaborar la base de datos topoloacutegica de las liacuteneas

(ubicacioacuten de las paradas y seleccioacuten de puntos de control) y tiempos de recorrido entre

puntos de control

El OBU registra una serie de eventos de arranque perioacutedicos de detencioacuten y en parada para obtener datos de posicioacuten velocidad pulsos de odoacutemetro informacioacuten sobre la cobertura GPS Para obtener el Cell ID y el LAC es necesario usar la funcioacuten para enviar comando directamente al MODEM en formato AT Cada vez que el conductor apaga el autobuacutes (llave de contacto en off) el OBU cierra el fichero y lo enviacutea al servidor viacutea GPRS a traveacutes de un protocolo establecido entre el OBU y el Distpacher Una vez tenga constancia de que el fichero ha sido recibido en el servidor borra el fichero y desconecta el releacute de alimentacioacuten apagaacutendose Aplicacioacuten principal del sistema embarcado

El OBU basa parte de su funcionamiento en datos que tiene almacenados en forma de ficheros de configuracioacuten Este consta de tres ficheros uno que almacena datos que determinan ciertos comportamientos del equipo y otros dos con informacioacuten de lineas rutas y puntos La funcionalidad fundamental del OBU es la de reportar el paso por determinados puntos definidos en el sistema paradas puntos de control cabeceras fin de viaje etc Esto se lleva a cabo mediante un proceso que estaacute obteniendo en todo momento las coordenadas GPS y la distancia recorrida por el autobuacutes seguacuten odoacutemetro de manera que pueda estar comprobando a la vez si ha recorrido la distancia del ultimo punto reportado al siguiente o si seguacuten el GPS se encuentra en un entorno de ese punto

El OBU tiene un proceso concurrente que esta atendiendo en todo momento una vez esteacute en funcionamiento una posible peticioacuten desde el servidor esto lo usa el CG para poder solicitar en cualquier momento la posicioacuten en la que se encuentra el autobuacutes con el objetivo de rectificar tiempos Paralelamente se estaacute atendiendo cualquier evento propio del modulo GSM del OBU que pueda afectar la comunicacioacuten del mismo con el servidor de manera que esta comunicacioacuten pueda ser restablecida inmediatamente levantando nuevamente la sesioacuten GPRS ya que el mantener la misma es algo critico e imprescindible dentro del sistema A la vez que las otras funcionalidades el OBU lleva el control de la ocurrencia de ciertos eventos loacutegicos que se han definido en el sistema como son el tiempo que transcurre donde el autobuacutes tiene velocidad cero si se ha puesto el contacto de la llave en OFF si se ha pulsado el botoacuten de fuera de servicio si se ha llegado al uacuteltimo viaje entrada en el entorno de un punto salida del entorno de un punto etc Algunos de estos eventos generan comunicacioacuten con el servidor para reportar la ocurrencia de los mismos como son el caso del apagado del autobuacutes la pulsacioacuten del botoacuten la terminacioacuten del uacuteltimo viaje y el excederse del tiempo predefinido con velocidad cero Una vez que el OBU sale de su funcionamiento normal sea cual sea la causa y esteacute listo para apagarse entra en un proceso donde verifica la versioacuten del software que el

AG 33sivaat 12092007 125600 327

servidor tiene disponible como vaacutelida de manera que si esta difiere de la actual procede a actualizarla Todas las comunicaciones con el servidor se realizan mediante protocolos de

comunicacioacuten propietarios disentildeados e implementados para cada tarea especifica del sistema que se soportan encima del protocolo UDP

AG 33sivaat 12092007 125600 427

Centro de Gestion SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Centro de Gestion SIVAAT-PARDEM 5

(Especificacion Tecnica) 5

1 INTRODUCCIOacuteN 6

2 Arquitectura loacutegica del sistema 6

3 Moacutedulos principales del sistema 6

4 Gestor de mensajes y distribuidor (Distpacher) 7

5 Composicioacuten del Centro 8

6 Moacutedulo WEB 8

AG 33sivaat 12092007 125600 527

4 INTRODUCCIOacuteN

En este documento se indica el desarrollo para el Centro de Gestion realizado como parte del desarrollo del sistema SIVAAT-PARDEM (Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda oacute PARDEM)

5 Arquitectura loacutegica del sistema

La solucioacuten del sistema se basa en una arquitectura multicapas capa Cliente capa Servidor y capa del Sistema de informacioacuten empresarial

En la parte cliente se encuentran todos los usuarios en general es decir todos los que interactuacutean con el Centro de Gestioacuten moacuteviles parada a la demanda (PBD) unidad embarcada (OBU) y alguacuten cliente Web En esta parte se han implementado la loacutegica necesarias sobre la parte embarcada (OBU) La capa Servidor es la maacutes importante pues contendraacute toda la loacutegica de negocio Esta se compone de varios componentes de servidor que son los encargados de procesar la informacioacuten almacenada con el objetivo de elaborar una respuesta como resultado de una peticioacuten desde los distintos tipos de clientes Tambieacuten contiene un grupo de componentes con una funcionalidad de gestioacuten sobre los datos del sistema ya sea informativa o de administracioacuten El Dispatcher es el moacutedulo responsable de atender todas las peticiones SMS y GPRS

del sistema y darles el curso correspondiente dentro de la loacutegica de negocio y con los protocolos adecuados seguacuten la naturaleza de la peticioacuten asiacute como enviar solicitudes de manera automaacutetica hacia dichos dispositivos Se trata de un interfaz entre los dispositivos perifeacutericos del sistema (paradas autobuses y SMSs de usuario PARDEM) y el Centro de Gestioacuten El sistema cuenta con una capa de datos que almacena toda la informacioacuten necesaria para el correcto funcionamiento del sistema Aquiacute se almacena todo lo relativo a las liacuteneas a las que se les ofrece el servicio asiacute como las rutas servicios (coches) y autobuses de las mismas (Base de datos de la Red) Tambieacuten se guarda informacioacuten sobre las peticiones atendidas por el sistema eventos e incidencias (Base de Datos de Servicio) informacioacuten que sirve de base para generar los informes que se presentan en la WEB que permitiraacuten hacer estudios de explotacioacuten que ayuden a mejorar y hacer mas eficiente el sistema

6 Moacutedulos principales del sistema

AG 33sivaat 12092007 125600 627

Servidor de Aplicaciones JAVA

Moacutedulo WEB Centro de Gestioacuten

Aplicacioacuten WEB

(Cocoon)

Online

Consultas

Informes

Gestor de Informacioacuten de localizacioacuten y estado

Gestor de Informacioacuten de Peticiones

Gestor de Histoacutericos

Base de

Datos

Distpacher

Interfaz entre dispositivos

moacuteviles y el Centro de

Gestioacuten

Carga de Datos de

la Red

Teleacutefonos moacuteviles SMS

GSM

Usuario WEB

HTTP

Usuario

Carga de Datos

OBU

Owasys

Moacutedulo de Captura

de Datos

Aplicacioacuten del

Sistema

Embarcado

Fig

El Sistema estaacute dividido en 5 subsistemas o moacutedulos principales igrave Moacutedulo de aplicaciones de la Parada

igrave Moacutedulo de aplicaciones del sistema embarcado (OBU)

igrave Gestor de mensajes y distribuidor (Distpacher)

igrave Centro de Gestioacuten

Moacutedulo WEB

7 Gestor de mensajes y distribuidor (Distpacher)

El moacutedulo Dispatcher es un interfaz entre los dispositivos perifeacutericos del sistema (moviles y fijos) y el Centro de Gestioacuten Por un lado estaacute el Centro de Gestioacuten con una comunicacioacuten viacutea Intranet con HTTP con un protocolo basado en XML (Extensible Markup Language) y por otro los teleacutefonos moacuteviles los OBU y las paradas La comunicacioacuten con los teleacutefonos moacuteviles se realiza a traveacutes de SMS La comunicacioacuten con los OBU y con las paradas se realiza viacutea Internet con protocolo UDP (User Datagram Protocol) Al Dispatcher van conectados tres modems GSM modelo Siemens TC45 que son los encargados de recibir y enviar los mensajes en principio uno por cada operador de telefoniacutea moacutevil en Espantildea Estos modems TC45 soportan el leguaje de programacioacuten Java y poseen una Maacutequina Virtual Java (JVM) propietaria de Siemens para ello

AG 33sivaat 12092007 125600 727

EL Distpacher es el moacutedulo que gestiona todo el proceso de atencioacuten de peticiones viacutea UDP instanciando un hilo para cada OBU de autobuacutes y para cada parada Este hilo efectua todo el proceso para dicho OBU y cuando se recibe un EOT (End Off Transmission) se elimina ese hilo eliminaacutendose de la tabla de hilos Es decir cuando el autobuacutes o parada realizan una peticioacuten UDP el Dispatcher comprueba si tiene su hilo activo y si no lo instancia Todas las peticiones a traveacutes del protocolo establecido tienen el identificador del peticioinario Si el identificador no se encuentra en el fichero de configuracioacuten entonces la peticioacuten es ignorada

8 Composicioacuten del Centro

El centro de gestioacuten consta de tres moacutedulos principales

Gestor de Informacioacuten de localizacioacuten y estado Gestiona la informacioacuten relacionada con el

estado de los autobuses y su posicioacuten

igrave Asignar autobuses a liacuteneas rutas y coches

igrave Determinacioacuten de la ubicacioacuten y estado de los autobuses

igrave Conocer queacute autobuses estaacuten actualmente en servicio y en queacute liacutenea y ruta estaacuten y van

a estar prestando servicio en los proacuteximos T minutos

igrave Conocer queacute autobuses entraraacuten en servicio en las rutas de intereacutes en los proacuteximos T

minutos

igrave Conocer queacute autobuses dejaraacuten el servicio que estaacuten prestando en las rutas de intereacutes

en los proacuteximos T minutos

Gestor de Informacioacuten de Peticiones Gestiona la informacioacuten relacionada con las peticiones

de los usuarios

igrave Anaacutelisis continuo de las solicitudes

Gestor de Histoacutericos Gestiona toda la informacioacuten relacionada con los histoacutericos de

solicitudes servicio de autobuses y eventos

9 Moacutedulo WEB

Las moacutedulos principales que se presentaraacuten en la WEB son ONLINE Tiempo Real

Consultas Informes

Trazas de la Aplicacioacuten

Actualizacioacuten OBU de autobuses y paradas

A traveacutes del moacutedulo ONLINE es posible visualizar en tiempo real el comportamiento de Autobuses Informacioacuten relacionada con los autobuses que pertenecen a una liacutenea

determinada en cuanto a tiempos de recorridos reales retrasosadelantos etc

Solicitudes Todas las solicitudes activas o las recibidas desde el inicio del servicio

Incidencias Se visualizan todas las incidencias recibidas desde el inicio del servicio

incidencias relacionadas con los autobusesparadas servicio de autobuses solicitudes

AG 33sivaat 12092007 125600 827

Traza de aplicacioacuten

A traveacutes del moacutedulo Consultas Informes es posible obtener informacioacuten del Histoacuterico del sistema iTRA en temas de Tiempos de recorrido

A traveacutes de esta consulta el usuario puede visualizar y comparar los tiempos de recorridos teoacutericos y reales teniendo en cuenta los datos registrados en el Centro de Gestioacuten para cada uno de los autobuses en las diferentes liacuteneas Pueden ser Tiempos de recorrido para una liacutenea y ruta determinada o Tiempos de recorrido entre dos paradas

Horas de salida de cabeceras

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de salida de cabecera estimado y real

Hora de paso por paradas

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de paso por paradas estimado y real

Incidencias

Se puede obtener una tabla con la informacioacuten sobre las incidencias del vehiacuteculo o la

parada en el diacutea a partir de la seleccioacuten de una Fecha Liacutenea yo Tipo de Incidencia

presentaacutendose una lista con los resultados de la consulta

Solicitudes

Se puede obtener una tabla con informacioacuten completa sobre la situacioacuten de las solicitudes

al seleccionar en el menuacute principal esta opcioacuten

A traveacutes del moacutedulo Trazas de la Aplicacioacuten se presenta el registro de la aplicacioacuten a partir de la seleccioacuten realizada por el usuario Fecha determinada

Entre Fechas

Por moacutedulos

A traveacutes del moacutedulo Actualizacioacuten OBU o Actualizacioacuten Parada se puede actualizar el software instalado en los OBU o en las paradas viacutea ftp

AG 33sivaat 12092007 125600 927

Parada

Indice

Parada 10

1 INTRODUCCIOacuteN 11

2 SERVICIOS 11

3 COMPOSICION 11

4 DISTRIBUCION DE EQUIPAMIENTO 13

5 NECESIDADES PREVIAS A LA INSTALACION 18

6 DESCRIPCION HW 18

7 DESCRIPCION SW 18

8 COMUNICACIOacuteN CON CENTRO DE GESTION (CG) 19

9 ASPECTOS DE USUARIO 19

10 CONFIGURACION Y MANTENIMIENTO 19

11 REFERENCIAS 19

AG 33sivaat 12092007 125600 1027

10 INTRODUCCIOacuteN

Como se indica en la descripcioacuten del sistema la Parada estaacute para proporcionar interaccioacuten con el usuario para los servicios SIVAAT (Sistema de Informacioacuten al Viajero de Autobuacutes Accesible para Todos) y para los servicios PARDEM (PARada a la DEManda)

11 SERVICIOS

Tanto servicios SIVAAT como PARDEM Dicho de otro modo proporciona interaccioacuten a los usuarios

bull Normales- A traveacutes de Display y teclas

bull Discapacitados Auditivos- A traveacutes de Display y teclas

bull Discapacitados Visuales- A traveacutes de altavoz y teclas previa lectura de

tarjeta FRID

bull Discapacitados Visuales- tras la lectura de tarjeta RFID y peticioacuten de info

mediante tecla se mostraraacute tanto el proacuteximo autobuacutes como el proacuteximo de

plataforma baja (si lo hubiere)

Asimismo permite realizar peticiones con efecto sobre el conductor de autobuses bull En el caso de Discapacitado Visual se le indica al conductor del autobuacutes

bull En el caso de Discapacitado Fiacutesico tambieacuten se le indica al conductor del

autobuacutes de plataforma baja correspondiente

bull En el caso de haber pulsado tecla de PARada a la DEManda tambieacuten se le indica

al conductor del autobuacutes correspondiente para cualquier tipo de usuario

12 COMPOSICION

Para la realizacioacuten de la necesaria interaccioacuten tanto con el usuario (de distintos tipos) y con el resto del sistema a traveacutes de la comunicacioacuten con el Centro de Gestioacuten (CG) se utiliza un sistema de microprocesador con Sw basado en Linux con el esquema de bloques HW que se indicada en la siguiente figura compuesta de

bull Unidad de Control con el procesador y Sw basado en Linux que controla toda

la parada

bull Detector de Presencia capaz de distinguir la presencia de personas y no la de

coches o pequentildeos animales

bull Lector de tarjeta RFID del tipo tarjeta Sube-T usada en el consorcio de

transportes de la comunidad de Madrid Lee la identidad de la tarjeta

bull Teclas y LEDs de iluminacioacuten con teclas antivandaacutelicas y diodos LED de

iluminacioacuten para permitir la realizacioacuten de peticiones de usuario (cualquiera que

sea el tipo) y para permitir la lectura nocturna de la info impresa junto a las

teclas acerca de las lineas que pasan por la parada

AG 33sivaat 12092007 125600 1127

bull Modem GPRS para comunicacioacuten con el Centro de Gestioacuten (CG) para permitir

interaccion con el resto del sistema

bull Modem BlueTooth para comunicacioacuten con Consola de Mantenimiento

(Consola) situada a escasos metros de la parada usando comunicacioacuten sin hilos

bull Display para proporcionar tanto indicaciones de uso como informacioacuten horaria

y de llegadas previstas de autobuses Es del tipo grafico de frac14 de VGA

bull Altavoz para proporcionar indicaciones sonoras Es del tipo intemperie

bull Sistema de Alimentacioacuten para proporcionar energia a todo el sistema de la

Parada Toma energia de la red de alumbrado (durante la noche) por lo que

necesita bateriacuteas ya que durante el diacutea no llega energiacutea

bull Consola de Mantenimiento se usaraacute solo para pruebas de puesta a punto y

para mantenimiento o ciertos cambios de configuracioacuten en las paradas

ldquoprototipordquo Se comunica a traveacutes de comunicacioacuten inalaacutembrica del tipo

BlueTooth Para un despliegue masivo de paradas debe realizarse a traveacutes de

GPRS e integraacutendolo con el Centro de Gestioacuten (CG)

AG 33sivaat 12092007 125600 1227

76

Unidad

Control

(CPU)

Teclado + LEDs

Expansor

de Puertos

Display

Altavoz

Detector

Presencia

Sistema de

Alimentacion

(en techo)

Modem GPRS

Lector

Tarjeta RFID

Puerto

Mantenimiento

(Modem BlueTooth)

Ethernet

Serie RS 232

4

10

8

Serie RS 232

Serie RS 232

Nota Hilos a la alimentacioacuten no representados

Antena

Fig1 Diagrama de bloques de la Parada

13 DISTRIBUCION DE EQUIPAMIENTO

En la siguiente figura aparece una foto de una parada (donde se equipara uno de los prototipos) asiacute como un detalle de la columna ancha donde va encastrada una caja de material plaacutestico con la mayor parte de los componentes del sistema (todos menos el sistema de alimentacioacuten y el detector de presencia) estos van en sobre refuerzo a realizar sobre la columna ancha a modo de techo plano interior bajo el techo curvo de plaacutestico

AG 33sivaat 12092007 125600 1327

Fig2 Vistas de parada y poste ancho donde se coloca la caja encastrada en

lugar de los carteles informativos

La caja encastrada contiene bull El display bull Las teclas de liacuteneas bull Los textos impresos descriptivos de las liacuteneas con su iluminacioacuten bull Las pegatinas transparentes externas por liacutenea-ruta para poner al lado de cada

tecla con la escritura en coacutedigo Braille bull El lector de tarjeta RFID bull El altavoz

Ademaacutes tambieacuten figuran en el interior de esta caja bull La Unidad de Control (CPU)

AG 33sivaat 12092007 125600 1427

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

1 INTRODUCCIOacuteN

En este documento se indica el desarrollo para los autobuses realizado como parte del desarrollo del sistema SIVAAT-PARDEM (Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda oacute PARDEM)

2 Localizacioacuten de autobuses

La funcioacuten de localizacioacuten de autobuses puede tener una repercusioacuten importante en los costes y por ello se decidieron analizar varias alternativas incluyendo la utilizacioacuten de receptores GPS la utilizacioacuten de balizas WiFi y la utilizacioacuten de un Terminal telefoacutenico para ubicar la posicioacuten del autobuacutes en base a las ceacutelulas visibles en cada momento por dicho terminal Tras los primeros anaacutelisis se descartoacute la utilizacioacuten de servicios de localizacioacuten ofrecidos por los operadores de telefoniacutea moacutevil debido a su coste excesivo para este tipo de aplicaciones Con respecto a la utilizacioacuten de balizas Wifi se han realizado pruebas con un nodo de acceso fijo y un nodo Wifi moacutevil y se ha concluido lo siguiente

Breve descriopcioacuten de desarrollos pruebas y Conclusiones Con respecto a la utilizacioacuten de la informacioacuten de ceacutelulas GSM Breve descriopcioacuten de desarrollos pruebas y Conclusiones Por todo ello el sistema de localizacioacuten finalmente implementado tras los resultados obtenidos en la pruebas utiliza en el terminal embarcado la sentildeal del odoacutemetro del autobuacutes la sentildeal de apertura de puertas la estimacioacuten realizada por un receptor GPS y una base de datos de la topologiacutea de las liacuteneas con las coordenadas de puntos de control predefinidos la distancia entre ellos la ruta y la liacutenea a la que pertenecen y un listado de la secuencia de viajes realizados por el autobuacutes Soacutelo teniendo en cuenta toda esta informacioacuten es posible realizar una estimacioacuten autoacutenoma de la posicioacuten del autobuacutes con las posibles excepciones que pueden tener lugar en el servicio y con la precisioacuten suficiente para estimar tiempos de llegada adecuados Por otro lado la realizacioacuten de una estimacioacuten de la localizacioacuten de forma totalmente autoacutenoma es imprescindible para optimizar las comunicaciones de datos entre los autobuses y el centro Este meacutetodo de localizacioacuten funciona satisfactoriamente en la prueba y se pondraacute a prueba en otra liacutenea maacutes compleja Salvo en el caso de la localizacioacuten no se han identificado otros factores relevantes inesperados por lo que el resto de las liacuteneas de trabajo (Comunicaciones de datos Centro compartido y Difusioacuten de informacioacuten a los usuarios) se describen dentro de la descripcioacuten global del sistema implementado que se aborda en el siguiente apartado La uacuteltima liacutenea de trabajo (Gestioacuten del traacutefico de autobuses en intercambiadores) se trata maacutes abajo en un apartado independiente

3 Moacutedulo de aplicaciones del sistema embarcado (OBU)

Consta de dos aplicaciones fundamentales

AG 33sivaat 12092007 125600 227

1 Aplicacioacuten para la captura de datos de la Red y Servicio

2 Aplicacioacuten principal del sistema embarcado Aplicacioacuten para la captura de datos de la Red y Servicio

Constituye el modo de funcionamiento del sistema que se utiliza para la obtencioacuten de datos cada vez que se instale en iTRA una nueva liacutenea de servicio Esta aplicacioacuten permite

Realizar pruebas en los aspectos relacionados con la cobertura GPS existente en el

recorrido que realizan los autobuses y cobertura disponibilidad y costes del servicio GPRS

Recoger los datos necesarios para elaborar la base de datos topoloacutegica de las liacuteneas

(ubicacioacuten de las paradas y seleccioacuten de puntos de control) y tiempos de recorrido entre

puntos de control

El OBU registra una serie de eventos de arranque perioacutedicos de detencioacuten y en parada para obtener datos de posicioacuten velocidad pulsos de odoacutemetro informacioacuten sobre la cobertura GPS Para obtener el Cell ID y el LAC es necesario usar la funcioacuten para enviar comando directamente al MODEM en formato AT Cada vez que el conductor apaga el autobuacutes (llave de contacto en off) el OBU cierra el fichero y lo enviacutea al servidor viacutea GPRS a traveacutes de un protocolo establecido entre el OBU y el Distpacher Una vez tenga constancia de que el fichero ha sido recibido en el servidor borra el fichero y desconecta el releacute de alimentacioacuten apagaacutendose Aplicacioacuten principal del sistema embarcado

El OBU basa parte de su funcionamiento en datos que tiene almacenados en forma de ficheros de configuracioacuten Este consta de tres ficheros uno que almacena datos que determinan ciertos comportamientos del equipo y otros dos con informacioacuten de lineas rutas y puntos La funcionalidad fundamental del OBU es la de reportar el paso por determinados puntos definidos en el sistema paradas puntos de control cabeceras fin de viaje etc Esto se lleva a cabo mediante un proceso que estaacute obteniendo en todo momento las coordenadas GPS y la distancia recorrida por el autobuacutes seguacuten odoacutemetro de manera que pueda estar comprobando a la vez si ha recorrido la distancia del ultimo punto reportado al siguiente o si seguacuten el GPS se encuentra en un entorno de ese punto

El OBU tiene un proceso concurrente que esta atendiendo en todo momento una vez esteacute en funcionamiento una posible peticioacuten desde el servidor esto lo usa el CG para poder solicitar en cualquier momento la posicioacuten en la que se encuentra el autobuacutes con el objetivo de rectificar tiempos Paralelamente se estaacute atendiendo cualquier evento propio del modulo GSM del OBU que pueda afectar la comunicacioacuten del mismo con el servidor de manera que esta comunicacioacuten pueda ser restablecida inmediatamente levantando nuevamente la sesioacuten GPRS ya que el mantener la misma es algo critico e imprescindible dentro del sistema A la vez que las otras funcionalidades el OBU lleva el control de la ocurrencia de ciertos eventos loacutegicos que se han definido en el sistema como son el tiempo que transcurre donde el autobuacutes tiene velocidad cero si se ha puesto el contacto de la llave en OFF si se ha pulsado el botoacuten de fuera de servicio si se ha llegado al uacuteltimo viaje entrada en el entorno de un punto salida del entorno de un punto etc Algunos de estos eventos generan comunicacioacuten con el servidor para reportar la ocurrencia de los mismos como son el caso del apagado del autobuacutes la pulsacioacuten del botoacuten la terminacioacuten del uacuteltimo viaje y el excederse del tiempo predefinido con velocidad cero Una vez que el OBU sale de su funcionamiento normal sea cual sea la causa y esteacute listo para apagarse entra en un proceso donde verifica la versioacuten del software que el

AG 33sivaat 12092007 125600 327

servidor tiene disponible como vaacutelida de manera que si esta difiere de la actual procede a actualizarla Todas las comunicaciones con el servidor se realizan mediante protocolos de

comunicacioacuten propietarios disentildeados e implementados para cada tarea especifica del sistema que se soportan encima del protocolo UDP

AG 33sivaat 12092007 125600 427

Centro de Gestion SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Centro de Gestion SIVAAT-PARDEM 5

(Especificacion Tecnica) 5

1 INTRODUCCIOacuteN 6

2 Arquitectura loacutegica del sistema 6

3 Moacutedulos principales del sistema 6

4 Gestor de mensajes y distribuidor (Distpacher) 7

5 Composicioacuten del Centro 8

6 Moacutedulo WEB 8

AG 33sivaat 12092007 125600 527

4 INTRODUCCIOacuteN

En este documento se indica el desarrollo para el Centro de Gestion realizado como parte del desarrollo del sistema SIVAAT-PARDEM (Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda oacute PARDEM)

5 Arquitectura loacutegica del sistema

La solucioacuten del sistema se basa en una arquitectura multicapas capa Cliente capa Servidor y capa del Sistema de informacioacuten empresarial

En la parte cliente se encuentran todos los usuarios en general es decir todos los que interactuacutean con el Centro de Gestioacuten moacuteviles parada a la demanda (PBD) unidad embarcada (OBU) y alguacuten cliente Web En esta parte se han implementado la loacutegica necesarias sobre la parte embarcada (OBU) La capa Servidor es la maacutes importante pues contendraacute toda la loacutegica de negocio Esta se compone de varios componentes de servidor que son los encargados de procesar la informacioacuten almacenada con el objetivo de elaborar una respuesta como resultado de una peticioacuten desde los distintos tipos de clientes Tambieacuten contiene un grupo de componentes con una funcionalidad de gestioacuten sobre los datos del sistema ya sea informativa o de administracioacuten El Dispatcher es el moacutedulo responsable de atender todas las peticiones SMS y GPRS

del sistema y darles el curso correspondiente dentro de la loacutegica de negocio y con los protocolos adecuados seguacuten la naturaleza de la peticioacuten asiacute como enviar solicitudes de manera automaacutetica hacia dichos dispositivos Se trata de un interfaz entre los dispositivos perifeacutericos del sistema (paradas autobuses y SMSs de usuario PARDEM) y el Centro de Gestioacuten El sistema cuenta con una capa de datos que almacena toda la informacioacuten necesaria para el correcto funcionamiento del sistema Aquiacute se almacena todo lo relativo a las liacuteneas a las que se les ofrece el servicio asiacute como las rutas servicios (coches) y autobuses de las mismas (Base de datos de la Red) Tambieacuten se guarda informacioacuten sobre las peticiones atendidas por el sistema eventos e incidencias (Base de Datos de Servicio) informacioacuten que sirve de base para generar los informes que se presentan en la WEB que permitiraacuten hacer estudios de explotacioacuten que ayuden a mejorar y hacer mas eficiente el sistema

6 Moacutedulos principales del sistema

AG 33sivaat 12092007 125600 627

Servidor de Aplicaciones JAVA

Moacutedulo WEB Centro de Gestioacuten

Aplicacioacuten WEB

(Cocoon)

Online

Consultas

Informes

Gestor de Informacioacuten de localizacioacuten y estado

Gestor de Informacioacuten de Peticiones

Gestor de Histoacutericos

Base de

Datos

Distpacher

Interfaz entre dispositivos

moacuteviles y el Centro de

Gestioacuten

Carga de Datos de

la Red

Teleacutefonos moacuteviles SMS

GSM

Usuario WEB

HTTP

Usuario

Carga de Datos

OBU

Owasys

Moacutedulo de Captura

de Datos

Aplicacioacuten del

Sistema

Embarcado

Fig

El Sistema estaacute dividido en 5 subsistemas o moacutedulos principales igrave Moacutedulo de aplicaciones de la Parada

igrave Moacutedulo de aplicaciones del sistema embarcado (OBU)

igrave Gestor de mensajes y distribuidor (Distpacher)

igrave Centro de Gestioacuten

Moacutedulo WEB

7 Gestor de mensajes y distribuidor (Distpacher)

El moacutedulo Dispatcher es un interfaz entre los dispositivos perifeacutericos del sistema (moviles y fijos) y el Centro de Gestioacuten Por un lado estaacute el Centro de Gestioacuten con una comunicacioacuten viacutea Intranet con HTTP con un protocolo basado en XML (Extensible Markup Language) y por otro los teleacutefonos moacuteviles los OBU y las paradas La comunicacioacuten con los teleacutefonos moacuteviles se realiza a traveacutes de SMS La comunicacioacuten con los OBU y con las paradas se realiza viacutea Internet con protocolo UDP (User Datagram Protocol) Al Dispatcher van conectados tres modems GSM modelo Siemens TC45 que son los encargados de recibir y enviar los mensajes en principio uno por cada operador de telefoniacutea moacutevil en Espantildea Estos modems TC45 soportan el leguaje de programacioacuten Java y poseen una Maacutequina Virtual Java (JVM) propietaria de Siemens para ello

AG 33sivaat 12092007 125600 727

EL Distpacher es el moacutedulo que gestiona todo el proceso de atencioacuten de peticiones viacutea UDP instanciando un hilo para cada OBU de autobuacutes y para cada parada Este hilo efectua todo el proceso para dicho OBU y cuando se recibe un EOT (End Off Transmission) se elimina ese hilo eliminaacutendose de la tabla de hilos Es decir cuando el autobuacutes o parada realizan una peticioacuten UDP el Dispatcher comprueba si tiene su hilo activo y si no lo instancia Todas las peticiones a traveacutes del protocolo establecido tienen el identificador del peticioinario Si el identificador no se encuentra en el fichero de configuracioacuten entonces la peticioacuten es ignorada

8 Composicioacuten del Centro

El centro de gestioacuten consta de tres moacutedulos principales

Gestor de Informacioacuten de localizacioacuten y estado Gestiona la informacioacuten relacionada con el

estado de los autobuses y su posicioacuten

igrave Asignar autobuses a liacuteneas rutas y coches

igrave Determinacioacuten de la ubicacioacuten y estado de los autobuses

igrave Conocer queacute autobuses estaacuten actualmente en servicio y en queacute liacutenea y ruta estaacuten y van

a estar prestando servicio en los proacuteximos T minutos

igrave Conocer queacute autobuses entraraacuten en servicio en las rutas de intereacutes en los proacuteximos T

minutos

igrave Conocer queacute autobuses dejaraacuten el servicio que estaacuten prestando en las rutas de intereacutes

en los proacuteximos T minutos

Gestor de Informacioacuten de Peticiones Gestiona la informacioacuten relacionada con las peticiones

de los usuarios

igrave Anaacutelisis continuo de las solicitudes

Gestor de Histoacutericos Gestiona toda la informacioacuten relacionada con los histoacutericos de

solicitudes servicio de autobuses y eventos

9 Moacutedulo WEB

Las moacutedulos principales que se presentaraacuten en la WEB son ONLINE Tiempo Real

Consultas Informes

Trazas de la Aplicacioacuten

Actualizacioacuten OBU de autobuses y paradas

A traveacutes del moacutedulo ONLINE es posible visualizar en tiempo real el comportamiento de Autobuses Informacioacuten relacionada con los autobuses que pertenecen a una liacutenea

determinada en cuanto a tiempos de recorridos reales retrasosadelantos etc

Solicitudes Todas las solicitudes activas o las recibidas desde el inicio del servicio

Incidencias Se visualizan todas las incidencias recibidas desde el inicio del servicio

incidencias relacionadas con los autobusesparadas servicio de autobuses solicitudes

AG 33sivaat 12092007 125600 827

Traza de aplicacioacuten

A traveacutes del moacutedulo Consultas Informes es posible obtener informacioacuten del Histoacuterico del sistema iTRA en temas de Tiempos de recorrido

A traveacutes de esta consulta el usuario puede visualizar y comparar los tiempos de recorridos teoacutericos y reales teniendo en cuenta los datos registrados en el Centro de Gestioacuten para cada uno de los autobuses en las diferentes liacuteneas Pueden ser Tiempos de recorrido para una liacutenea y ruta determinada o Tiempos de recorrido entre dos paradas

Horas de salida de cabeceras

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de salida de cabecera estimado y real

Hora de paso por paradas

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de paso por paradas estimado y real

Incidencias

Se puede obtener una tabla con la informacioacuten sobre las incidencias del vehiacuteculo o la

parada en el diacutea a partir de la seleccioacuten de una Fecha Liacutenea yo Tipo de Incidencia

presentaacutendose una lista con los resultados de la consulta

Solicitudes

Se puede obtener una tabla con informacioacuten completa sobre la situacioacuten de las solicitudes

al seleccionar en el menuacute principal esta opcioacuten

A traveacutes del moacutedulo Trazas de la Aplicacioacuten se presenta el registro de la aplicacioacuten a partir de la seleccioacuten realizada por el usuario Fecha determinada

Entre Fechas

Por moacutedulos

A traveacutes del moacutedulo Actualizacioacuten OBU o Actualizacioacuten Parada se puede actualizar el software instalado en los OBU o en las paradas viacutea ftp

AG 33sivaat 12092007 125600 927

Parada

Indice

Parada 10

1 INTRODUCCIOacuteN 11

2 SERVICIOS 11

3 COMPOSICION 11

4 DISTRIBUCION DE EQUIPAMIENTO 13

5 NECESIDADES PREVIAS A LA INSTALACION 18

6 DESCRIPCION HW 18

7 DESCRIPCION SW 18

8 COMUNICACIOacuteN CON CENTRO DE GESTION (CG) 19

9 ASPECTOS DE USUARIO 19

10 CONFIGURACION Y MANTENIMIENTO 19

11 REFERENCIAS 19

AG 33sivaat 12092007 125600 1027

10 INTRODUCCIOacuteN

Como se indica en la descripcioacuten del sistema la Parada estaacute para proporcionar interaccioacuten con el usuario para los servicios SIVAAT (Sistema de Informacioacuten al Viajero de Autobuacutes Accesible para Todos) y para los servicios PARDEM (PARada a la DEManda)

11 SERVICIOS

Tanto servicios SIVAAT como PARDEM Dicho de otro modo proporciona interaccioacuten a los usuarios

bull Normales- A traveacutes de Display y teclas

bull Discapacitados Auditivos- A traveacutes de Display y teclas

bull Discapacitados Visuales- A traveacutes de altavoz y teclas previa lectura de

tarjeta FRID

bull Discapacitados Visuales- tras la lectura de tarjeta RFID y peticioacuten de info

mediante tecla se mostraraacute tanto el proacuteximo autobuacutes como el proacuteximo de

plataforma baja (si lo hubiere)

Asimismo permite realizar peticiones con efecto sobre el conductor de autobuses bull En el caso de Discapacitado Visual se le indica al conductor del autobuacutes

bull En el caso de Discapacitado Fiacutesico tambieacuten se le indica al conductor del

autobuacutes de plataforma baja correspondiente

bull En el caso de haber pulsado tecla de PARada a la DEManda tambieacuten se le indica

al conductor del autobuacutes correspondiente para cualquier tipo de usuario

12 COMPOSICION

Para la realizacioacuten de la necesaria interaccioacuten tanto con el usuario (de distintos tipos) y con el resto del sistema a traveacutes de la comunicacioacuten con el Centro de Gestioacuten (CG) se utiliza un sistema de microprocesador con Sw basado en Linux con el esquema de bloques HW que se indicada en la siguiente figura compuesta de

bull Unidad de Control con el procesador y Sw basado en Linux que controla toda

la parada

bull Detector de Presencia capaz de distinguir la presencia de personas y no la de

coches o pequentildeos animales

bull Lector de tarjeta RFID del tipo tarjeta Sube-T usada en el consorcio de

transportes de la comunidad de Madrid Lee la identidad de la tarjeta

bull Teclas y LEDs de iluminacioacuten con teclas antivandaacutelicas y diodos LED de

iluminacioacuten para permitir la realizacioacuten de peticiones de usuario (cualquiera que

sea el tipo) y para permitir la lectura nocturna de la info impresa junto a las

teclas acerca de las lineas que pasan por la parada

AG 33sivaat 12092007 125600 1127

bull Modem GPRS para comunicacioacuten con el Centro de Gestioacuten (CG) para permitir

interaccion con el resto del sistema

bull Modem BlueTooth para comunicacioacuten con Consola de Mantenimiento

(Consola) situada a escasos metros de la parada usando comunicacioacuten sin hilos

bull Display para proporcionar tanto indicaciones de uso como informacioacuten horaria

y de llegadas previstas de autobuses Es del tipo grafico de frac14 de VGA

bull Altavoz para proporcionar indicaciones sonoras Es del tipo intemperie

bull Sistema de Alimentacioacuten para proporcionar energia a todo el sistema de la

Parada Toma energia de la red de alumbrado (durante la noche) por lo que

necesita bateriacuteas ya que durante el diacutea no llega energiacutea

bull Consola de Mantenimiento se usaraacute solo para pruebas de puesta a punto y

para mantenimiento o ciertos cambios de configuracioacuten en las paradas

ldquoprototipordquo Se comunica a traveacutes de comunicacioacuten inalaacutembrica del tipo

BlueTooth Para un despliegue masivo de paradas debe realizarse a traveacutes de

GPRS e integraacutendolo con el Centro de Gestioacuten (CG)

AG 33sivaat 12092007 125600 1227

76

Unidad

Control

(CPU)

Teclado + LEDs

Expansor

de Puertos

Display

Altavoz

Detector

Presencia

Sistema de

Alimentacion

(en techo)

Modem GPRS

Lector

Tarjeta RFID

Puerto

Mantenimiento

(Modem BlueTooth)

Ethernet

Serie RS 232

4

10

8

Serie RS 232

Serie RS 232

Nota Hilos a la alimentacioacuten no representados

Antena

Fig1 Diagrama de bloques de la Parada

13 DISTRIBUCION DE EQUIPAMIENTO

En la siguiente figura aparece una foto de una parada (donde se equipara uno de los prototipos) asiacute como un detalle de la columna ancha donde va encastrada una caja de material plaacutestico con la mayor parte de los componentes del sistema (todos menos el sistema de alimentacioacuten y el detector de presencia) estos van en sobre refuerzo a realizar sobre la columna ancha a modo de techo plano interior bajo el techo curvo de plaacutestico

AG 33sivaat 12092007 125600 1327

Fig2 Vistas de parada y poste ancho donde se coloca la caja encastrada en

lugar de los carteles informativos

La caja encastrada contiene bull El display bull Las teclas de liacuteneas bull Los textos impresos descriptivos de las liacuteneas con su iluminacioacuten bull Las pegatinas transparentes externas por liacutenea-ruta para poner al lado de cada

tecla con la escritura en coacutedigo Braille bull El lector de tarjeta RFID bull El altavoz

Ademaacutes tambieacuten figuran en el interior de esta caja bull La Unidad de Control (CPU)

AG 33sivaat 12092007 125600 1427

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

1 Aplicacioacuten para la captura de datos de la Red y Servicio

2 Aplicacioacuten principal del sistema embarcado Aplicacioacuten para la captura de datos de la Red y Servicio

Constituye el modo de funcionamiento del sistema que se utiliza para la obtencioacuten de datos cada vez que se instale en iTRA una nueva liacutenea de servicio Esta aplicacioacuten permite

Realizar pruebas en los aspectos relacionados con la cobertura GPS existente en el

recorrido que realizan los autobuses y cobertura disponibilidad y costes del servicio GPRS

Recoger los datos necesarios para elaborar la base de datos topoloacutegica de las liacuteneas

(ubicacioacuten de las paradas y seleccioacuten de puntos de control) y tiempos de recorrido entre

puntos de control

El OBU registra una serie de eventos de arranque perioacutedicos de detencioacuten y en parada para obtener datos de posicioacuten velocidad pulsos de odoacutemetro informacioacuten sobre la cobertura GPS Para obtener el Cell ID y el LAC es necesario usar la funcioacuten para enviar comando directamente al MODEM en formato AT Cada vez que el conductor apaga el autobuacutes (llave de contacto en off) el OBU cierra el fichero y lo enviacutea al servidor viacutea GPRS a traveacutes de un protocolo establecido entre el OBU y el Distpacher Una vez tenga constancia de que el fichero ha sido recibido en el servidor borra el fichero y desconecta el releacute de alimentacioacuten apagaacutendose Aplicacioacuten principal del sistema embarcado

El OBU basa parte de su funcionamiento en datos que tiene almacenados en forma de ficheros de configuracioacuten Este consta de tres ficheros uno que almacena datos que determinan ciertos comportamientos del equipo y otros dos con informacioacuten de lineas rutas y puntos La funcionalidad fundamental del OBU es la de reportar el paso por determinados puntos definidos en el sistema paradas puntos de control cabeceras fin de viaje etc Esto se lleva a cabo mediante un proceso que estaacute obteniendo en todo momento las coordenadas GPS y la distancia recorrida por el autobuacutes seguacuten odoacutemetro de manera que pueda estar comprobando a la vez si ha recorrido la distancia del ultimo punto reportado al siguiente o si seguacuten el GPS se encuentra en un entorno de ese punto

El OBU tiene un proceso concurrente que esta atendiendo en todo momento una vez esteacute en funcionamiento una posible peticioacuten desde el servidor esto lo usa el CG para poder solicitar en cualquier momento la posicioacuten en la que se encuentra el autobuacutes con el objetivo de rectificar tiempos Paralelamente se estaacute atendiendo cualquier evento propio del modulo GSM del OBU que pueda afectar la comunicacioacuten del mismo con el servidor de manera que esta comunicacioacuten pueda ser restablecida inmediatamente levantando nuevamente la sesioacuten GPRS ya que el mantener la misma es algo critico e imprescindible dentro del sistema A la vez que las otras funcionalidades el OBU lleva el control de la ocurrencia de ciertos eventos loacutegicos que se han definido en el sistema como son el tiempo que transcurre donde el autobuacutes tiene velocidad cero si se ha puesto el contacto de la llave en OFF si se ha pulsado el botoacuten de fuera de servicio si se ha llegado al uacuteltimo viaje entrada en el entorno de un punto salida del entorno de un punto etc Algunos de estos eventos generan comunicacioacuten con el servidor para reportar la ocurrencia de los mismos como son el caso del apagado del autobuacutes la pulsacioacuten del botoacuten la terminacioacuten del uacuteltimo viaje y el excederse del tiempo predefinido con velocidad cero Una vez que el OBU sale de su funcionamiento normal sea cual sea la causa y esteacute listo para apagarse entra en un proceso donde verifica la versioacuten del software que el

AG 33sivaat 12092007 125600 327

servidor tiene disponible como vaacutelida de manera que si esta difiere de la actual procede a actualizarla Todas las comunicaciones con el servidor se realizan mediante protocolos de

comunicacioacuten propietarios disentildeados e implementados para cada tarea especifica del sistema que se soportan encima del protocolo UDP

AG 33sivaat 12092007 125600 427

Centro de Gestion SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Centro de Gestion SIVAAT-PARDEM 5

(Especificacion Tecnica) 5

1 INTRODUCCIOacuteN 6

2 Arquitectura loacutegica del sistema 6

3 Moacutedulos principales del sistema 6

4 Gestor de mensajes y distribuidor (Distpacher) 7

5 Composicioacuten del Centro 8

6 Moacutedulo WEB 8

AG 33sivaat 12092007 125600 527

4 INTRODUCCIOacuteN

En este documento se indica el desarrollo para el Centro de Gestion realizado como parte del desarrollo del sistema SIVAAT-PARDEM (Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda oacute PARDEM)

5 Arquitectura loacutegica del sistema

La solucioacuten del sistema se basa en una arquitectura multicapas capa Cliente capa Servidor y capa del Sistema de informacioacuten empresarial

En la parte cliente se encuentran todos los usuarios en general es decir todos los que interactuacutean con el Centro de Gestioacuten moacuteviles parada a la demanda (PBD) unidad embarcada (OBU) y alguacuten cliente Web En esta parte se han implementado la loacutegica necesarias sobre la parte embarcada (OBU) La capa Servidor es la maacutes importante pues contendraacute toda la loacutegica de negocio Esta se compone de varios componentes de servidor que son los encargados de procesar la informacioacuten almacenada con el objetivo de elaborar una respuesta como resultado de una peticioacuten desde los distintos tipos de clientes Tambieacuten contiene un grupo de componentes con una funcionalidad de gestioacuten sobre los datos del sistema ya sea informativa o de administracioacuten El Dispatcher es el moacutedulo responsable de atender todas las peticiones SMS y GPRS

del sistema y darles el curso correspondiente dentro de la loacutegica de negocio y con los protocolos adecuados seguacuten la naturaleza de la peticioacuten asiacute como enviar solicitudes de manera automaacutetica hacia dichos dispositivos Se trata de un interfaz entre los dispositivos perifeacutericos del sistema (paradas autobuses y SMSs de usuario PARDEM) y el Centro de Gestioacuten El sistema cuenta con una capa de datos que almacena toda la informacioacuten necesaria para el correcto funcionamiento del sistema Aquiacute se almacena todo lo relativo a las liacuteneas a las que se les ofrece el servicio asiacute como las rutas servicios (coches) y autobuses de las mismas (Base de datos de la Red) Tambieacuten se guarda informacioacuten sobre las peticiones atendidas por el sistema eventos e incidencias (Base de Datos de Servicio) informacioacuten que sirve de base para generar los informes que se presentan en la WEB que permitiraacuten hacer estudios de explotacioacuten que ayuden a mejorar y hacer mas eficiente el sistema

6 Moacutedulos principales del sistema

AG 33sivaat 12092007 125600 627

Servidor de Aplicaciones JAVA

Moacutedulo WEB Centro de Gestioacuten

Aplicacioacuten WEB

(Cocoon)

Online

Consultas

Informes

Gestor de Informacioacuten de localizacioacuten y estado

Gestor de Informacioacuten de Peticiones

Gestor de Histoacutericos

Base de

Datos

Distpacher

Interfaz entre dispositivos

moacuteviles y el Centro de

Gestioacuten

Carga de Datos de

la Red

Teleacutefonos moacuteviles SMS

GSM

Usuario WEB

HTTP

Usuario

Carga de Datos

OBU

Owasys

Moacutedulo de Captura

de Datos

Aplicacioacuten del

Sistema

Embarcado

Fig

El Sistema estaacute dividido en 5 subsistemas o moacutedulos principales igrave Moacutedulo de aplicaciones de la Parada

igrave Moacutedulo de aplicaciones del sistema embarcado (OBU)

igrave Gestor de mensajes y distribuidor (Distpacher)

igrave Centro de Gestioacuten

Moacutedulo WEB

7 Gestor de mensajes y distribuidor (Distpacher)

El moacutedulo Dispatcher es un interfaz entre los dispositivos perifeacutericos del sistema (moviles y fijos) y el Centro de Gestioacuten Por un lado estaacute el Centro de Gestioacuten con una comunicacioacuten viacutea Intranet con HTTP con un protocolo basado en XML (Extensible Markup Language) y por otro los teleacutefonos moacuteviles los OBU y las paradas La comunicacioacuten con los teleacutefonos moacuteviles se realiza a traveacutes de SMS La comunicacioacuten con los OBU y con las paradas se realiza viacutea Internet con protocolo UDP (User Datagram Protocol) Al Dispatcher van conectados tres modems GSM modelo Siemens TC45 que son los encargados de recibir y enviar los mensajes en principio uno por cada operador de telefoniacutea moacutevil en Espantildea Estos modems TC45 soportan el leguaje de programacioacuten Java y poseen una Maacutequina Virtual Java (JVM) propietaria de Siemens para ello

AG 33sivaat 12092007 125600 727

EL Distpacher es el moacutedulo que gestiona todo el proceso de atencioacuten de peticiones viacutea UDP instanciando un hilo para cada OBU de autobuacutes y para cada parada Este hilo efectua todo el proceso para dicho OBU y cuando se recibe un EOT (End Off Transmission) se elimina ese hilo eliminaacutendose de la tabla de hilos Es decir cuando el autobuacutes o parada realizan una peticioacuten UDP el Dispatcher comprueba si tiene su hilo activo y si no lo instancia Todas las peticiones a traveacutes del protocolo establecido tienen el identificador del peticioinario Si el identificador no se encuentra en el fichero de configuracioacuten entonces la peticioacuten es ignorada

8 Composicioacuten del Centro

El centro de gestioacuten consta de tres moacutedulos principales

Gestor de Informacioacuten de localizacioacuten y estado Gestiona la informacioacuten relacionada con el

estado de los autobuses y su posicioacuten

igrave Asignar autobuses a liacuteneas rutas y coches

igrave Determinacioacuten de la ubicacioacuten y estado de los autobuses

igrave Conocer queacute autobuses estaacuten actualmente en servicio y en queacute liacutenea y ruta estaacuten y van

a estar prestando servicio en los proacuteximos T minutos

igrave Conocer queacute autobuses entraraacuten en servicio en las rutas de intereacutes en los proacuteximos T

minutos

igrave Conocer queacute autobuses dejaraacuten el servicio que estaacuten prestando en las rutas de intereacutes

en los proacuteximos T minutos

Gestor de Informacioacuten de Peticiones Gestiona la informacioacuten relacionada con las peticiones

de los usuarios

igrave Anaacutelisis continuo de las solicitudes

Gestor de Histoacutericos Gestiona toda la informacioacuten relacionada con los histoacutericos de

solicitudes servicio de autobuses y eventos

9 Moacutedulo WEB

Las moacutedulos principales que se presentaraacuten en la WEB son ONLINE Tiempo Real

Consultas Informes

Trazas de la Aplicacioacuten

Actualizacioacuten OBU de autobuses y paradas

A traveacutes del moacutedulo ONLINE es posible visualizar en tiempo real el comportamiento de Autobuses Informacioacuten relacionada con los autobuses que pertenecen a una liacutenea

determinada en cuanto a tiempos de recorridos reales retrasosadelantos etc

Solicitudes Todas las solicitudes activas o las recibidas desde el inicio del servicio

Incidencias Se visualizan todas las incidencias recibidas desde el inicio del servicio

incidencias relacionadas con los autobusesparadas servicio de autobuses solicitudes

AG 33sivaat 12092007 125600 827

Traza de aplicacioacuten

A traveacutes del moacutedulo Consultas Informes es posible obtener informacioacuten del Histoacuterico del sistema iTRA en temas de Tiempos de recorrido

A traveacutes de esta consulta el usuario puede visualizar y comparar los tiempos de recorridos teoacutericos y reales teniendo en cuenta los datos registrados en el Centro de Gestioacuten para cada uno de los autobuses en las diferentes liacuteneas Pueden ser Tiempos de recorrido para una liacutenea y ruta determinada o Tiempos de recorrido entre dos paradas

Horas de salida de cabeceras

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de salida de cabecera estimado y real

Hora de paso por paradas

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de paso por paradas estimado y real

Incidencias

Se puede obtener una tabla con la informacioacuten sobre las incidencias del vehiacuteculo o la

parada en el diacutea a partir de la seleccioacuten de una Fecha Liacutenea yo Tipo de Incidencia

presentaacutendose una lista con los resultados de la consulta

Solicitudes

Se puede obtener una tabla con informacioacuten completa sobre la situacioacuten de las solicitudes

al seleccionar en el menuacute principal esta opcioacuten

A traveacutes del moacutedulo Trazas de la Aplicacioacuten se presenta el registro de la aplicacioacuten a partir de la seleccioacuten realizada por el usuario Fecha determinada

Entre Fechas

Por moacutedulos

A traveacutes del moacutedulo Actualizacioacuten OBU o Actualizacioacuten Parada se puede actualizar el software instalado en los OBU o en las paradas viacutea ftp

AG 33sivaat 12092007 125600 927

Parada

Indice

Parada 10

1 INTRODUCCIOacuteN 11

2 SERVICIOS 11

3 COMPOSICION 11

4 DISTRIBUCION DE EQUIPAMIENTO 13

5 NECESIDADES PREVIAS A LA INSTALACION 18

6 DESCRIPCION HW 18

7 DESCRIPCION SW 18

8 COMUNICACIOacuteN CON CENTRO DE GESTION (CG) 19

9 ASPECTOS DE USUARIO 19

10 CONFIGURACION Y MANTENIMIENTO 19

11 REFERENCIAS 19

AG 33sivaat 12092007 125600 1027

10 INTRODUCCIOacuteN

Como se indica en la descripcioacuten del sistema la Parada estaacute para proporcionar interaccioacuten con el usuario para los servicios SIVAAT (Sistema de Informacioacuten al Viajero de Autobuacutes Accesible para Todos) y para los servicios PARDEM (PARada a la DEManda)

11 SERVICIOS

Tanto servicios SIVAAT como PARDEM Dicho de otro modo proporciona interaccioacuten a los usuarios

bull Normales- A traveacutes de Display y teclas

bull Discapacitados Auditivos- A traveacutes de Display y teclas

bull Discapacitados Visuales- A traveacutes de altavoz y teclas previa lectura de

tarjeta FRID

bull Discapacitados Visuales- tras la lectura de tarjeta RFID y peticioacuten de info

mediante tecla se mostraraacute tanto el proacuteximo autobuacutes como el proacuteximo de

plataforma baja (si lo hubiere)

Asimismo permite realizar peticiones con efecto sobre el conductor de autobuses bull En el caso de Discapacitado Visual se le indica al conductor del autobuacutes

bull En el caso de Discapacitado Fiacutesico tambieacuten se le indica al conductor del

autobuacutes de plataforma baja correspondiente

bull En el caso de haber pulsado tecla de PARada a la DEManda tambieacuten se le indica

al conductor del autobuacutes correspondiente para cualquier tipo de usuario

12 COMPOSICION

Para la realizacioacuten de la necesaria interaccioacuten tanto con el usuario (de distintos tipos) y con el resto del sistema a traveacutes de la comunicacioacuten con el Centro de Gestioacuten (CG) se utiliza un sistema de microprocesador con Sw basado en Linux con el esquema de bloques HW que se indicada en la siguiente figura compuesta de

bull Unidad de Control con el procesador y Sw basado en Linux que controla toda

la parada

bull Detector de Presencia capaz de distinguir la presencia de personas y no la de

coches o pequentildeos animales

bull Lector de tarjeta RFID del tipo tarjeta Sube-T usada en el consorcio de

transportes de la comunidad de Madrid Lee la identidad de la tarjeta

bull Teclas y LEDs de iluminacioacuten con teclas antivandaacutelicas y diodos LED de

iluminacioacuten para permitir la realizacioacuten de peticiones de usuario (cualquiera que

sea el tipo) y para permitir la lectura nocturna de la info impresa junto a las

teclas acerca de las lineas que pasan por la parada

AG 33sivaat 12092007 125600 1127

bull Modem GPRS para comunicacioacuten con el Centro de Gestioacuten (CG) para permitir

interaccion con el resto del sistema

bull Modem BlueTooth para comunicacioacuten con Consola de Mantenimiento

(Consola) situada a escasos metros de la parada usando comunicacioacuten sin hilos

bull Display para proporcionar tanto indicaciones de uso como informacioacuten horaria

y de llegadas previstas de autobuses Es del tipo grafico de frac14 de VGA

bull Altavoz para proporcionar indicaciones sonoras Es del tipo intemperie

bull Sistema de Alimentacioacuten para proporcionar energia a todo el sistema de la

Parada Toma energia de la red de alumbrado (durante la noche) por lo que

necesita bateriacuteas ya que durante el diacutea no llega energiacutea

bull Consola de Mantenimiento se usaraacute solo para pruebas de puesta a punto y

para mantenimiento o ciertos cambios de configuracioacuten en las paradas

ldquoprototipordquo Se comunica a traveacutes de comunicacioacuten inalaacutembrica del tipo

BlueTooth Para un despliegue masivo de paradas debe realizarse a traveacutes de

GPRS e integraacutendolo con el Centro de Gestioacuten (CG)

AG 33sivaat 12092007 125600 1227

76

Unidad

Control

(CPU)

Teclado + LEDs

Expansor

de Puertos

Display

Altavoz

Detector

Presencia

Sistema de

Alimentacion

(en techo)

Modem GPRS

Lector

Tarjeta RFID

Puerto

Mantenimiento

(Modem BlueTooth)

Ethernet

Serie RS 232

4

10

8

Serie RS 232

Serie RS 232

Nota Hilos a la alimentacioacuten no representados

Antena

Fig1 Diagrama de bloques de la Parada

13 DISTRIBUCION DE EQUIPAMIENTO

En la siguiente figura aparece una foto de una parada (donde se equipara uno de los prototipos) asiacute como un detalle de la columna ancha donde va encastrada una caja de material plaacutestico con la mayor parte de los componentes del sistema (todos menos el sistema de alimentacioacuten y el detector de presencia) estos van en sobre refuerzo a realizar sobre la columna ancha a modo de techo plano interior bajo el techo curvo de plaacutestico

AG 33sivaat 12092007 125600 1327

Fig2 Vistas de parada y poste ancho donde se coloca la caja encastrada en

lugar de los carteles informativos

La caja encastrada contiene bull El display bull Las teclas de liacuteneas bull Los textos impresos descriptivos de las liacuteneas con su iluminacioacuten bull Las pegatinas transparentes externas por liacutenea-ruta para poner al lado de cada

tecla con la escritura en coacutedigo Braille bull El lector de tarjeta RFID bull El altavoz

Ademaacutes tambieacuten figuran en el interior de esta caja bull La Unidad de Control (CPU)

AG 33sivaat 12092007 125600 1427

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

servidor tiene disponible como vaacutelida de manera que si esta difiere de la actual procede a actualizarla Todas las comunicaciones con el servidor se realizan mediante protocolos de

comunicacioacuten propietarios disentildeados e implementados para cada tarea especifica del sistema que se soportan encima del protocolo UDP

AG 33sivaat 12092007 125600 427

Centro de Gestion SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Centro de Gestion SIVAAT-PARDEM 5

(Especificacion Tecnica) 5

1 INTRODUCCIOacuteN 6

2 Arquitectura loacutegica del sistema 6

3 Moacutedulos principales del sistema 6

4 Gestor de mensajes y distribuidor (Distpacher) 7

5 Composicioacuten del Centro 8

6 Moacutedulo WEB 8

AG 33sivaat 12092007 125600 527

4 INTRODUCCIOacuteN

En este documento se indica el desarrollo para el Centro de Gestion realizado como parte del desarrollo del sistema SIVAAT-PARDEM (Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda oacute PARDEM)

5 Arquitectura loacutegica del sistema

La solucioacuten del sistema se basa en una arquitectura multicapas capa Cliente capa Servidor y capa del Sistema de informacioacuten empresarial

En la parte cliente se encuentran todos los usuarios en general es decir todos los que interactuacutean con el Centro de Gestioacuten moacuteviles parada a la demanda (PBD) unidad embarcada (OBU) y alguacuten cliente Web En esta parte se han implementado la loacutegica necesarias sobre la parte embarcada (OBU) La capa Servidor es la maacutes importante pues contendraacute toda la loacutegica de negocio Esta se compone de varios componentes de servidor que son los encargados de procesar la informacioacuten almacenada con el objetivo de elaborar una respuesta como resultado de una peticioacuten desde los distintos tipos de clientes Tambieacuten contiene un grupo de componentes con una funcionalidad de gestioacuten sobre los datos del sistema ya sea informativa o de administracioacuten El Dispatcher es el moacutedulo responsable de atender todas las peticiones SMS y GPRS

del sistema y darles el curso correspondiente dentro de la loacutegica de negocio y con los protocolos adecuados seguacuten la naturaleza de la peticioacuten asiacute como enviar solicitudes de manera automaacutetica hacia dichos dispositivos Se trata de un interfaz entre los dispositivos perifeacutericos del sistema (paradas autobuses y SMSs de usuario PARDEM) y el Centro de Gestioacuten El sistema cuenta con una capa de datos que almacena toda la informacioacuten necesaria para el correcto funcionamiento del sistema Aquiacute se almacena todo lo relativo a las liacuteneas a las que se les ofrece el servicio asiacute como las rutas servicios (coches) y autobuses de las mismas (Base de datos de la Red) Tambieacuten se guarda informacioacuten sobre las peticiones atendidas por el sistema eventos e incidencias (Base de Datos de Servicio) informacioacuten que sirve de base para generar los informes que se presentan en la WEB que permitiraacuten hacer estudios de explotacioacuten que ayuden a mejorar y hacer mas eficiente el sistema

6 Moacutedulos principales del sistema

AG 33sivaat 12092007 125600 627

Servidor de Aplicaciones JAVA

Moacutedulo WEB Centro de Gestioacuten

Aplicacioacuten WEB

(Cocoon)

Online

Consultas

Informes

Gestor de Informacioacuten de localizacioacuten y estado

Gestor de Informacioacuten de Peticiones

Gestor de Histoacutericos

Base de

Datos

Distpacher

Interfaz entre dispositivos

moacuteviles y el Centro de

Gestioacuten

Carga de Datos de

la Red

Teleacutefonos moacuteviles SMS

GSM

Usuario WEB

HTTP

Usuario

Carga de Datos

OBU

Owasys

Moacutedulo de Captura

de Datos

Aplicacioacuten del

Sistema

Embarcado

Fig

El Sistema estaacute dividido en 5 subsistemas o moacutedulos principales igrave Moacutedulo de aplicaciones de la Parada

igrave Moacutedulo de aplicaciones del sistema embarcado (OBU)

igrave Gestor de mensajes y distribuidor (Distpacher)

igrave Centro de Gestioacuten

Moacutedulo WEB

7 Gestor de mensajes y distribuidor (Distpacher)

El moacutedulo Dispatcher es un interfaz entre los dispositivos perifeacutericos del sistema (moviles y fijos) y el Centro de Gestioacuten Por un lado estaacute el Centro de Gestioacuten con una comunicacioacuten viacutea Intranet con HTTP con un protocolo basado en XML (Extensible Markup Language) y por otro los teleacutefonos moacuteviles los OBU y las paradas La comunicacioacuten con los teleacutefonos moacuteviles se realiza a traveacutes de SMS La comunicacioacuten con los OBU y con las paradas se realiza viacutea Internet con protocolo UDP (User Datagram Protocol) Al Dispatcher van conectados tres modems GSM modelo Siemens TC45 que son los encargados de recibir y enviar los mensajes en principio uno por cada operador de telefoniacutea moacutevil en Espantildea Estos modems TC45 soportan el leguaje de programacioacuten Java y poseen una Maacutequina Virtual Java (JVM) propietaria de Siemens para ello

AG 33sivaat 12092007 125600 727

EL Distpacher es el moacutedulo que gestiona todo el proceso de atencioacuten de peticiones viacutea UDP instanciando un hilo para cada OBU de autobuacutes y para cada parada Este hilo efectua todo el proceso para dicho OBU y cuando se recibe un EOT (End Off Transmission) se elimina ese hilo eliminaacutendose de la tabla de hilos Es decir cuando el autobuacutes o parada realizan una peticioacuten UDP el Dispatcher comprueba si tiene su hilo activo y si no lo instancia Todas las peticiones a traveacutes del protocolo establecido tienen el identificador del peticioinario Si el identificador no se encuentra en el fichero de configuracioacuten entonces la peticioacuten es ignorada

8 Composicioacuten del Centro

El centro de gestioacuten consta de tres moacutedulos principales

Gestor de Informacioacuten de localizacioacuten y estado Gestiona la informacioacuten relacionada con el

estado de los autobuses y su posicioacuten

igrave Asignar autobuses a liacuteneas rutas y coches

igrave Determinacioacuten de la ubicacioacuten y estado de los autobuses

igrave Conocer queacute autobuses estaacuten actualmente en servicio y en queacute liacutenea y ruta estaacuten y van

a estar prestando servicio en los proacuteximos T minutos

igrave Conocer queacute autobuses entraraacuten en servicio en las rutas de intereacutes en los proacuteximos T

minutos

igrave Conocer queacute autobuses dejaraacuten el servicio que estaacuten prestando en las rutas de intereacutes

en los proacuteximos T minutos

Gestor de Informacioacuten de Peticiones Gestiona la informacioacuten relacionada con las peticiones

de los usuarios

igrave Anaacutelisis continuo de las solicitudes

Gestor de Histoacutericos Gestiona toda la informacioacuten relacionada con los histoacutericos de

solicitudes servicio de autobuses y eventos

9 Moacutedulo WEB

Las moacutedulos principales que se presentaraacuten en la WEB son ONLINE Tiempo Real

Consultas Informes

Trazas de la Aplicacioacuten

Actualizacioacuten OBU de autobuses y paradas

A traveacutes del moacutedulo ONLINE es posible visualizar en tiempo real el comportamiento de Autobuses Informacioacuten relacionada con los autobuses que pertenecen a una liacutenea

determinada en cuanto a tiempos de recorridos reales retrasosadelantos etc

Solicitudes Todas las solicitudes activas o las recibidas desde el inicio del servicio

Incidencias Se visualizan todas las incidencias recibidas desde el inicio del servicio

incidencias relacionadas con los autobusesparadas servicio de autobuses solicitudes

AG 33sivaat 12092007 125600 827

Traza de aplicacioacuten

A traveacutes del moacutedulo Consultas Informes es posible obtener informacioacuten del Histoacuterico del sistema iTRA en temas de Tiempos de recorrido

A traveacutes de esta consulta el usuario puede visualizar y comparar los tiempos de recorridos teoacutericos y reales teniendo en cuenta los datos registrados en el Centro de Gestioacuten para cada uno de los autobuses en las diferentes liacuteneas Pueden ser Tiempos de recorrido para una liacutenea y ruta determinada o Tiempos de recorrido entre dos paradas

Horas de salida de cabeceras

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de salida de cabecera estimado y real

Hora de paso por paradas

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de paso por paradas estimado y real

Incidencias

Se puede obtener una tabla con la informacioacuten sobre las incidencias del vehiacuteculo o la

parada en el diacutea a partir de la seleccioacuten de una Fecha Liacutenea yo Tipo de Incidencia

presentaacutendose una lista con los resultados de la consulta

Solicitudes

Se puede obtener una tabla con informacioacuten completa sobre la situacioacuten de las solicitudes

al seleccionar en el menuacute principal esta opcioacuten

A traveacutes del moacutedulo Trazas de la Aplicacioacuten se presenta el registro de la aplicacioacuten a partir de la seleccioacuten realizada por el usuario Fecha determinada

Entre Fechas

Por moacutedulos

A traveacutes del moacutedulo Actualizacioacuten OBU o Actualizacioacuten Parada se puede actualizar el software instalado en los OBU o en las paradas viacutea ftp

AG 33sivaat 12092007 125600 927

Parada

Indice

Parada 10

1 INTRODUCCIOacuteN 11

2 SERVICIOS 11

3 COMPOSICION 11

4 DISTRIBUCION DE EQUIPAMIENTO 13

5 NECESIDADES PREVIAS A LA INSTALACION 18

6 DESCRIPCION HW 18

7 DESCRIPCION SW 18

8 COMUNICACIOacuteN CON CENTRO DE GESTION (CG) 19

9 ASPECTOS DE USUARIO 19

10 CONFIGURACION Y MANTENIMIENTO 19

11 REFERENCIAS 19

AG 33sivaat 12092007 125600 1027

10 INTRODUCCIOacuteN

Como se indica en la descripcioacuten del sistema la Parada estaacute para proporcionar interaccioacuten con el usuario para los servicios SIVAAT (Sistema de Informacioacuten al Viajero de Autobuacutes Accesible para Todos) y para los servicios PARDEM (PARada a la DEManda)

11 SERVICIOS

Tanto servicios SIVAAT como PARDEM Dicho de otro modo proporciona interaccioacuten a los usuarios

bull Normales- A traveacutes de Display y teclas

bull Discapacitados Auditivos- A traveacutes de Display y teclas

bull Discapacitados Visuales- A traveacutes de altavoz y teclas previa lectura de

tarjeta FRID

bull Discapacitados Visuales- tras la lectura de tarjeta RFID y peticioacuten de info

mediante tecla se mostraraacute tanto el proacuteximo autobuacutes como el proacuteximo de

plataforma baja (si lo hubiere)

Asimismo permite realizar peticiones con efecto sobre el conductor de autobuses bull En el caso de Discapacitado Visual se le indica al conductor del autobuacutes

bull En el caso de Discapacitado Fiacutesico tambieacuten se le indica al conductor del

autobuacutes de plataforma baja correspondiente

bull En el caso de haber pulsado tecla de PARada a la DEManda tambieacuten se le indica

al conductor del autobuacutes correspondiente para cualquier tipo de usuario

12 COMPOSICION

Para la realizacioacuten de la necesaria interaccioacuten tanto con el usuario (de distintos tipos) y con el resto del sistema a traveacutes de la comunicacioacuten con el Centro de Gestioacuten (CG) se utiliza un sistema de microprocesador con Sw basado en Linux con el esquema de bloques HW que se indicada en la siguiente figura compuesta de

bull Unidad de Control con el procesador y Sw basado en Linux que controla toda

la parada

bull Detector de Presencia capaz de distinguir la presencia de personas y no la de

coches o pequentildeos animales

bull Lector de tarjeta RFID del tipo tarjeta Sube-T usada en el consorcio de

transportes de la comunidad de Madrid Lee la identidad de la tarjeta

bull Teclas y LEDs de iluminacioacuten con teclas antivandaacutelicas y diodos LED de

iluminacioacuten para permitir la realizacioacuten de peticiones de usuario (cualquiera que

sea el tipo) y para permitir la lectura nocturna de la info impresa junto a las

teclas acerca de las lineas que pasan por la parada

AG 33sivaat 12092007 125600 1127

bull Modem GPRS para comunicacioacuten con el Centro de Gestioacuten (CG) para permitir

interaccion con el resto del sistema

bull Modem BlueTooth para comunicacioacuten con Consola de Mantenimiento

(Consola) situada a escasos metros de la parada usando comunicacioacuten sin hilos

bull Display para proporcionar tanto indicaciones de uso como informacioacuten horaria

y de llegadas previstas de autobuses Es del tipo grafico de frac14 de VGA

bull Altavoz para proporcionar indicaciones sonoras Es del tipo intemperie

bull Sistema de Alimentacioacuten para proporcionar energia a todo el sistema de la

Parada Toma energia de la red de alumbrado (durante la noche) por lo que

necesita bateriacuteas ya que durante el diacutea no llega energiacutea

bull Consola de Mantenimiento se usaraacute solo para pruebas de puesta a punto y

para mantenimiento o ciertos cambios de configuracioacuten en las paradas

ldquoprototipordquo Se comunica a traveacutes de comunicacioacuten inalaacutembrica del tipo

BlueTooth Para un despliegue masivo de paradas debe realizarse a traveacutes de

GPRS e integraacutendolo con el Centro de Gestioacuten (CG)

AG 33sivaat 12092007 125600 1227

76

Unidad

Control

(CPU)

Teclado + LEDs

Expansor

de Puertos

Display

Altavoz

Detector

Presencia

Sistema de

Alimentacion

(en techo)

Modem GPRS

Lector

Tarjeta RFID

Puerto

Mantenimiento

(Modem BlueTooth)

Ethernet

Serie RS 232

4

10

8

Serie RS 232

Serie RS 232

Nota Hilos a la alimentacioacuten no representados

Antena

Fig1 Diagrama de bloques de la Parada

13 DISTRIBUCION DE EQUIPAMIENTO

En la siguiente figura aparece una foto de una parada (donde se equipara uno de los prototipos) asiacute como un detalle de la columna ancha donde va encastrada una caja de material plaacutestico con la mayor parte de los componentes del sistema (todos menos el sistema de alimentacioacuten y el detector de presencia) estos van en sobre refuerzo a realizar sobre la columna ancha a modo de techo plano interior bajo el techo curvo de plaacutestico

AG 33sivaat 12092007 125600 1327

Fig2 Vistas de parada y poste ancho donde se coloca la caja encastrada en

lugar de los carteles informativos

La caja encastrada contiene bull El display bull Las teclas de liacuteneas bull Los textos impresos descriptivos de las liacuteneas con su iluminacioacuten bull Las pegatinas transparentes externas por liacutenea-ruta para poner al lado de cada

tecla con la escritura en coacutedigo Braille bull El lector de tarjeta RFID bull El altavoz

Ademaacutes tambieacuten figuran en el interior de esta caja bull La Unidad de Control (CPU)

AG 33sivaat 12092007 125600 1427

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

Centro de Gestion SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Centro de Gestion SIVAAT-PARDEM 5

(Especificacion Tecnica) 5

1 INTRODUCCIOacuteN 6

2 Arquitectura loacutegica del sistema 6

3 Moacutedulos principales del sistema 6

4 Gestor de mensajes y distribuidor (Distpacher) 7

5 Composicioacuten del Centro 8

6 Moacutedulo WEB 8

AG 33sivaat 12092007 125600 527

4 INTRODUCCIOacuteN

En este documento se indica el desarrollo para el Centro de Gestion realizado como parte del desarrollo del sistema SIVAAT-PARDEM (Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda oacute PARDEM)

5 Arquitectura loacutegica del sistema

La solucioacuten del sistema se basa en una arquitectura multicapas capa Cliente capa Servidor y capa del Sistema de informacioacuten empresarial

En la parte cliente se encuentran todos los usuarios en general es decir todos los que interactuacutean con el Centro de Gestioacuten moacuteviles parada a la demanda (PBD) unidad embarcada (OBU) y alguacuten cliente Web En esta parte se han implementado la loacutegica necesarias sobre la parte embarcada (OBU) La capa Servidor es la maacutes importante pues contendraacute toda la loacutegica de negocio Esta se compone de varios componentes de servidor que son los encargados de procesar la informacioacuten almacenada con el objetivo de elaborar una respuesta como resultado de una peticioacuten desde los distintos tipos de clientes Tambieacuten contiene un grupo de componentes con una funcionalidad de gestioacuten sobre los datos del sistema ya sea informativa o de administracioacuten El Dispatcher es el moacutedulo responsable de atender todas las peticiones SMS y GPRS

del sistema y darles el curso correspondiente dentro de la loacutegica de negocio y con los protocolos adecuados seguacuten la naturaleza de la peticioacuten asiacute como enviar solicitudes de manera automaacutetica hacia dichos dispositivos Se trata de un interfaz entre los dispositivos perifeacutericos del sistema (paradas autobuses y SMSs de usuario PARDEM) y el Centro de Gestioacuten El sistema cuenta con una capa de datos que almacena toda la informacioacuten necesaria para el correcto funcionamiento del sistema Aquiacute se almacena todo lo relativo a las liacuteneas a las que se les ofrece el servicio asiacute como las rutas servicios (coches) y autobuses de las mismas (Base de datos de la Red) Tambieacuten se guarda informacioacuten sobre las peticiones atendidas por el sistema eventos e incidencias (Base de Datos de Servicio) informacioacuten que sirve de base para generar los informes que se presentan en la WEB que permitiraacuten hacer estudios de explotacioacuten que ayuden a mejorar y hacer mas eficiente el sistema

6 Moacutedulos principales del sistema

AG 33sivaat 12092007 125600 627

Servidor de Aplicaciones JAVA

Moacutedulo WEB Centro de Gestioacuten

Aplicacioacuten WEB

(Cocoon)

Online

Consultas

Informes

Gestor de Informacioacuten de localizacioacuten y estado

Gestor de Informacioacuten de Peticiones

Gestor de Histoacutericos

Base de

Datos

Distpacher

Interfaz entre dispositivos

moacuteviles y el Centro de

Gestioacuten

Carga de Datos de

la Red

Teleacutefonos moacuteviles SMS

GSM

Usuario WEB

HTTP

Usuario

Carga de Datos

OBU

Owasys

Moacutedulo de Captura

de Datos

Aplicacioacuten del

Sistema

Embarcado

Fig

El Sistema estaacute dividido en 5 subsistemas o moacutedulos principales igrave Moacutedulo de aplicaciones de la Parada

igrave Moacutedulo de aplicaciones del sistema embarcado (OBU)

igrave Gestor de mensajes y distribuidor (Distpacher)

igrave Centro de Gestioacuten

Moacutedulo WEB

7 Gestor de mensajes y distribuidor (Distpacher)

El moacutedulo Dispatcher es un interfaz entre los dispositivos perifeacutericos del sistema (moviles y fijos) y el Centro de Gestioacuten Por un lado estaacute el Centro de Gestioacuten con una comunicacioacuten viacutea Intranet con HTTP con un protocolo basado en XML (Extensible Markup Language) y por otro los teleacutefonos moacuteviles los OBU y las paradas La comunicacioacuten con los teleacutefonos moacuteviles se realiza a traveacutes de SMS La comunicacioacuten con los OBU y con las paradas se realiza viacutea Internet con protocolo UDP (User Datagram Protocol) Al Dispatcher van conectados tres modems GSM modelo Siemens TC45 que son los encargados de recibir y enviar los mensajes en principio uno por cada operador de telefoniacutea moacutevil en Espantildea Estos modems TC45 soportan el leguaje de programacioacuten Java y poseen una Maacutequina Virtual Java (JVM) propietaria de Siemens para ello

AG 33sivaat 12092007 125600 727

EL Distpacher es el moacutedulo que gestiona todo el proceso de atencioacuten de peticiones viacutea UDP instanciando un hilo para cada OBU de autobuacutes y para cada parada Este hilo efectua todo el proceso para dicho OBU y cuando se recibe un EOT (End Off Transmission) se elimina ese hilo eliminaacutendose de la tabla de hilos Es decir cuando el autobuacutes o parada realizan una peticioacuten UDP el Dispatcher comprueba si tiene su hilo activo y si no lo instancia Todas las peticiones a traveacutes del protocolo establecido tienen el identificador del peticioinario Si el identificador no se encuentra en el fichero de configuracioacuten entonces la peticioacuten es ignorada

8 Composicioacuten del Centro

El centro de gestioacuten consta de tres moacutedulos principales

Gestor de Informacioacuten de localizacioacuten y estado Gestiona la informacioacuten relacionada con el

estado de los autobuses y su posicioacuten

igrave Asignar autobuses a liacuteneas rutas y coches

igrave Determinacioacuten de la ubicacioacuten y estado de los autobuses

igrave Conocer queacute autobuses estaacuten actualmente en servicio y en queacute liacutenea y ruta estaacuten y van

a estar prestando servicio en los proacuteximos T minutos

igrave Conocer queacute autobuses entraraacuten en servicio en las rutas de intereacutes en los proacuteximos T

minutos

igrave Conocer queacute autobuses dejaraacuten el servicio que estaacuten prestando en las rutas de intereacutes

en los proacuteximos T minutos

Gestor de Informacioacuten de Peticiones Gestiona la informacioacuten relacionada con las peticiones

de los usuarios

igrave Anaacutelisis continuo de las solicitudes

Gestor de Histoacutericos Gestiona toda la informacioacuten relacionada con los histoacutericos de

solicitudes servicio de autobuses y eventos

9 Moacutedulo WEB

Las moacutedulos principales que se presentaraacuten en la WEB son ONLINE Tiempo Real

Consultas Informes

Trazas de la Aplicacioacuten

Actualizacioacuten OBU de autobuses y paradas

A traveacutes del moacutedulo ONLINE es posible visualizar en tiempo real el comportamiento de Autobuses Informacioacuten relacionada con los autobuses que pertenecen a una liacutenea

determinada en cuanto a tiempos de recorridos reales retrasosadelantos etc

Solicitudes Todas las solicitudes activas o las recibidas desde el inicio del servicio

Incidencias Se visualizan todas las incidencias recibidas desde el inicio del servicio

incidencias relacionadas con los autobusesparadas servicio de autobuses solicitudes

AG 33sivaat 12092007 125600 827

Traza de aplicacioacuten

A traveacutes del moacutedulo Consultas Informes es posible obtener informacioacuten del Histoacuterico del sistema iTRA en temas de Tiempos de recorrido

A traveacutes de esta consulta el usuario puede visualizar y comparar los tiempos de recorridos teoacutericos y reales teniendo en cuenta los datos registrados en el Centro de Gestioacuten para cada uno de los autobuses en las diferentes liacuteneas Pueden ser Tiempos de recorrido para una liacutenea y ruta determinada o Tiempos de recorrido entre dos paradas

Horas de salida de cabeceras

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de salida de cabecera estimado y real

Hora de paso por paradas

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de paso por paradas estimado y real

Incidencias

Se puede obtener una tabla con la informacioacuten sobre las incidencias del vehiacuteculo o la

parada en el diacutea a partir de la seleccioacuten de una Fecha Liacutenea yo Tipo de Incidencia

presentaacutendose una lista con los resultados de la consulta

Solicitudes

Se puede obtener una tabla con informacioacuten completa sobre la situacioacuten de las solicitudes

al seleccionar en el menuacute principal esta opcioacuten

A traveacutes del moacutedulo Trazas de la Aplicacioacuten se presenta el registro de la aplicacioacuten a partir de la seleccioacuten realizada por el usuario Fecha determinada

Entre Fechas

Por moacutedulos

A traveacutes del moacutedulo Actualizacioacuten OBU o Actualizacioacuten Parada se puede actualizar el software instalado en los OBU o en las paradas viacutea ftp

AG 33sivaat 12092007 125600 927

Parada

Indice

Parada 10

1 INTRODUCCIOacuteN 11

2 SERVICIOS 11

3 COMPOSICION 11

4 DISTRIBUCION DE EQUIPAMIENTO 13

5 NECESIDADES PREVIAS A LA INSTALACION 18

6 DESCRIPCION HW 18

7 DESCRIPCION SW 18

8 COMUNICACIOacuteN CON CENTRO DE GESTION (CG) 19

9 ASPECTOS DE USUARIO 19

10 CONFIGURACION Y MANTENIMIENTO 19

11 REFERENCIAS 19

AG 33sivaat 12092007 125600 1027

10 INTRODUCCIOacuteN

Como se indica en la descripcioacuten del sistema la Parada estaacute para proporcionar interaccioacuten con el usuario para los servicios SIVAAT (Sistema de Informacioacuten al Viajero de Autobuacutes Accesible para Todos) y para los servicios PARDEM (PARada a la DEManda)

11 SERVICIOS

Tanto servicios SIVAAT como PARDEM Dicho de otro modo proporciona interaccioacuten a los usuarios

bull Normales- A traveacutes de Display y teclas

bull Discapacitados Auditivos- A traveacutes de Display y teclas

bull Discapacitados Visuales- A traveacutes de altavoz y teclas previa lectura de

tarjeta FRID

bull Discapacitados Visuales- tras la lectura de tarjeta RFID y peticioacuten de info

mediante tecla se mostraraacute tanto el proacuteximo autobuacutes como el proacuteximo de

plataforma baja (si lo hubiere)

Asimismo permite realizar peticiones con efecto sobre el conductor de autobuses bull En el caso de Discapacitado Visual se le indica al conductor del autobuacutes

bull En el caso de Discapacitado Fiacutesico tambieacuten se le indica al conductor del

autobuacutes de plataforma baja correspondiente

bull En el caso de haber pulsado tecla de PARada a la DEManda tambieacuten se le indica

al conductor del autobuacutes correspondiente para cualquier tipo de usuario

12 COMPOSICION

Para la realizacioacuten de la necesaria interaccioacuten tanto con el usuario (de distintos tipos) y con el resto del sistema a traveacutes de la comunicacioacuten con el Centro de Gestioacuten (CG) se utiliza un sistema de microprocesador con Sw basado en Linux con el esquema de bloques HW que se indicada en la siguiente figura compuesta de

bull Unidad de Control con el procesador y Sw basado en Linux que controla toda

la parada

bull Detector de Presencia capaz de distinguir la presencia de personas y no la de

coches o pequentildeos animales

bull Lector de tarjeta RFID del tipo tarjeta Sube-T usada en el consorcio de

transportes de la comunidad de Madrid Lee la identidad de la tarjeta

bull Teclas y LEDs de iluminacioacuten con teclas antivandaacutelicas y diodos LED de

iluminacioacuten para permitir la realizacioacuten de peticiones de usuario (cualquiera que

sea el tipo) y para permitir la lectura nocturna de la info impresa junto a las

teclas acerca de las lineas que pasan por la parada

AG 33sivaat 12092007 125600 1127

bull Modem GPRS para comunicacioacuten con el Centro de Gestioacuten (CG) para permitir

interaccion con el resto del sistema

bull Modem BlueTooth para comunicacioacuten con Consola de Mantenimiento

(Consola) situada a escasos metros de la parada usando comunicacioacuten sin hilos

bull Display para proporcionar tanto indicaciones de uso como informacioacuten horaria

y de llegadas previstas de autobuses Es del tipo grafico de frac14 de VGA

bull Altavoz para proporcionar indicaciones sonoras Es del tipo intemperie

bull Sistema de Alimentacioacuten para proporcionar energia a todo el sistema de la

Parada Toma energia de la red de alumbrado (durante la noche) por lo que

necesita bateriacuteas ya que durante el diacutea no llega energiacutea

bull Consola de Mantenimiento se usaraacute solo para pruebas de puesta a punto y

para mantenimiento o ciertos cambios de configuracioacuten en las paradas

ldquoprototipordquo Se comunica a traveacutes de comunicacioacuten inalaacutembrica del tipo

BlueTooth Para un despliegue masivo de paradas debe realizarse a traveacutes de

GPRS e integraacutendolo con el Centro de Gestioacuten (CG)

AG 33sivaat 12092007 125600 1227

76

Unidad

Control

(CPU)

Teclado + LEDs

Expansor

de Puertos

Display

Altavoz

Detector

Presencia

Sistema de

Alimentacion

(en techo)

Modem GPRS

Lector

Tarjeta RFID

Puerto

Mantenimiento

(Modem BlueTooth)

Ethernet

Serie RS 232

4

10

8

Serie RS 232

Serie RS 232

Nota Hilos a la alimentacioacuten no representados

Antena

Fig1 Diagrama de bloques de la Parada

13 DISTRIBUCION DE EQUIPAMIENTO

En la siguiente figura aparece una foto de una parada (donde se equipara uno de los prototipos) asiacute como un detalle de la columna ancha donde va encastrada una caja de material plaacutestico con la mayor parte de los componentes del sistema (todos menos el sistema de alimentacioacuten y el detector de presencia) estos van en sobre refuerzo a realizar sobre la columna ancha a modo de techo plano interior bajo el techo curvo de plaacutestico

AG 33sivaat 12092007 125600 1327

Fig2 Vistas de parada y poste ancho donde se coloca la caja encastrada en

lugar de los carteles informativos

La caja encastrada contiene bull El display bull Las teclas de liacuteneas bull Los textos impresos descriptivos de las liacuteneas con su iluminacioacuten bull Las pegatinas transparentes externas por liacutenea-ruta para poner al lado de cada

tecla con la escritura en coacutedigo Braille bull El lector de tarjeta RFID bull El altavoz

Ademaacutes tambieacuten figuran en el interior de esta caja bull La Unidad de Control (CPU)

AG 33sivaat 12092007 125600 1427

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

4 INTRODUCCIOacuteN

En este documento se indica el desarrollo para el Centro de Gestion realizado como parte del desarrollo del sistema SIVAAT-PARDEM (Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda oacute PARDEM)

5 Arquitectura loacutegica del sistema

La solucioacuten del sistema se basa en una arquitectura multicapas capa Cliente capa Servidor y capa del Sistema de informacioacuten empresarial

En la parte cliente se encuentran todos los usuarios en general es decir todos los que interactuacutean con el Centro de Gestioacuten moacuteviles parada a la demanda (PBD) unidad embarcada (OBU) y alguacuten cliente Web En esta parte se han implementado la loacutegica necesarias sobre la parte embarcada (OBU) La capa Servidor es la maacutes importante pues contendraacute toda la loacutegica de negocio Esta se compone de varios componentes de servidor que son los encargados de procesar la informacioacuten almacenada con el objetivo de elaborar una respuesta como resultado de una peticioacuten desde los distintos tipos de clientes Tambieacuten contiene un grupo de componentes con una funcionalidad de gestioacuten sobre los datos del sistema ya sea informativa o de administracioacuten El Dispatcher es el moacutedulo responsable de atender todas las peticiones SMS y GPRS

del sistema y darles el curso correspondiente dentro de la loacutegica de negocio y con los protocolos adecuados seguacuten la naturaleza de la peticioacuten asiacute como enviar solicitudes de manera automaacutetica hacia dichos dispositivos Se trata de un interfaz entre los dispositivos perifeacutericos del sistema (paradas autobuses y SMSs de usuario PARDEM) y el Centro de Gestioacuten El sistema cuenta con una capa de datos que almacena toda la informacioacuten necesaria para el correcto funcionamiento del sistema Aquiacute se almacena todo lo relativo a las liacuteneas a las que se les ofrece el servicio asiacute como las rutas servicios (coches) y autobuses de las mismas (Base de datos de la Red) Tambieacuten se guarda informacioacuten sobre las peticiones atendidas por el sistema eventos e incidencias (Base de Datos de Servicio) informacioacuten que sirve de base para generar los informes que se presentan en la WEB que permitiraacuten hacer estudios de explotacioacuten que ayuden a mejorar y hacer mas eficiente el sistema

6 Moacutedulos principales del sistema

AG 33sivaat 12092007 125600 627

Servidor de Aplicaciones JAVA

Moacutedulo WEB Centro de Gestioacuten

Aplicacioacuten WEB

(Cocoon)

Online

Consultas

Informes

Gestor de Informacioacuten de localizacioacuten y estado

Gestor de Informacioacuten de Peticiones

Gestor de Histoacutericos

Base de

Datos

Distpacher

Interfaz entre dispositivos

moacuteviles y el Centro de

Gestioacuten

Carga de Datos de

la Red

Teleacutefonos moacuteviles SMS

GSM

Usuario WEB

HTTP

Usuario

Carga de Datos

OBU

Owasys

Moacutedulo de Captura

de Datos

Aplicacioacuten del

Sistema

Embarcado

Fig

El Sistema estaacute dividido en 5 subsistemas o moacutedulos principales igrave Moacutedulo de aplicaciones de la Parada

igrave Moacutedulo de aplicaciones del sistema embarcado (OBU)

igrave Gestor de mensajes y distribuidor (Distpacher)

igrave Centro de Gestioacuten

Moacutedulo WEB

7 Gestor de mensajes y distribuidor (Distpacher)

El moacutedulo Dispatcher es un interfaz entre los dispositivos perifeacutericos del sistema (moviles y fijos) y el Centro de Gestioacuten Por un lado estaacute el Centro de Gestioacuten con una comunicacioacuten viacutea Intranet con HTTP con un protocolo basado en XML (Extensible Markup Language) y por otro los teleacutefonos moacuteviles los OBU y las paradas La comunicacioacuten con los teleacutefonos moacuteviles se realiza a traveacutes de SMS La comunicacioacuten con los OBU y con las paradas se realiza viacutea Internet con protocolo UDP (User Datagram Protocol) Al Dispatcher van conectados tres modems GSM modelo Siemens TC45 que son los encargados de recibir y enviar los mensajes en principio uno por cada operador de telefoniacutea moacutevil en Espantildea Estos modems TC45 soportan el leguaje de programacioacuten Java y poseen una Maacutequina Virtual Java (JVM) propietaria de Siemens para ello

AG 33sivaat 12092007 125600 727

EL Distpacher es el moacutedulo que gestiona todo el proceso de atencioacuten de peticiones viacutea UDP instanciando un hilo para cada OBU de autobuacutes y para cada parada Este hilo efectua todo el proceso para dicho OBU y cuando se recibe un EOT (End Off Transmission) se elimina ese hilo eliminaacutendose de la tabla de hilos Es decir cuando el autobuacutes o parada realizan una peticioacuten UDP el Dispatcher comprueba si tiene su hilo activo y si no lo instancia Todas las peticiones a traveacutes del protocolo establecido tienen el identificador del peticioinario Si el identificador no se encuentra en el fichero de configuracioacuten entonces la peticioacuten es ignorada

8 Composicioacuten del Centro

El centro de gestioacuten consta de tres moacutedulos principales

Gestor de Informacioacuten de localizacioacuten y estado Gestiona la informacioacuten relacionada con el

estado de los autobuses y su posicioacuten

igrave Asignar autobuses a liacuteneas rutas y coches

igrave Determinacioacuten de la ubicacioacuten y estado de los autobuses

igrave Conocer queacute autobuses estaacuten actualmente en servicio y en queacute liacutenea y ruta estaacuten y van

a estar prestando servicio en los proacuteximos T minutos

igrave Conocer queacute autobuses entraraacuten en servicio en las rutas de intereacutes en los proacuteximos T

minutos

igrave Conocer queacute autobuses dejaraacuten el servicio que estaacuten prestando en las rutas de intereacutes

en los proacuteximos T minutos

Gestor de Informacioacuten de Peticiones Gestiona la informacioacuten relacionada con las peticiones

de los usuarios

igrave Anaacutelisis continuo de las solicitudes

Gestor de Histoacutericos Gestiona toda la informacioacuten relacionada con los histoacutericos de

solicitudes servicio de autobuses y eventos

9 Moacutedulo WEB

Las moacutedulos principales que se presentaraacuten en la WEB son ONLINE Tiempo Real

Consultas Informes

Trazas de la Aplicacioacuten

Actualizacioacuten OBU de autobuses y paradas

A traveacutes del moacutedulo ONLINE es posible visualizar en tiempo real el comportamiento de Autobuses Informacioacuten relacionada con los autobuses que pertenecen a una liacutenea

determinada en cuanto a tiempos de recorridos reales retrasosadelantos etc

Solicitudes Todas las solicitudes activas o las recibidas desde el inicio del servicio

Incidencias Se visualizan todas las incidencias recibidas desde el inicio del servicio

incidencias relacionadas con los autobusesparadas servicio de autobuses solicitudes

AG 33sivaat 12092007 125600 827

Traza de aplicacioacuten

A traveacutes del moacutedulo Consultas Informes es posible obtener informacioacuten del Histoacuterico del sistema iTRA en temas de Tiempos de recorrido

A traveacutes de esta consulta el usuario puede visualizar y comparar los tiempos de recorridos teoacutericos y reales teniendo en cuenta los datos registrados en el Centro de Gestioacuten para cada uno de los autobuses en las diferentes liacuteneas Pueden ser Tiempos de recorrido para una liacutenea y ruta determinada o Tiempos de recorrido entre dos paradas

Horas de salida de cabeceras

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de salida de cabecera estimado y real

Hora de paso por paradas

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de paso por paradas estimado y real

Incidencias

Se puede obtener una tabla con la informacioacuten sobre las incidencias del vehiacuteculo o la

parada en el diacutea a partir de la seleccioacuten de una Fecha Liacutenea yo Tipo de Incidencia

presentaacutendose una lista con los resultados de la consulta

Solicitudes

Se puede obtener una tabla con informacioacuten completa sobre la situacioacuten de las solicitudes

al seleccionar en el menuacute principal esta opcioacuten

A traveacutes del moacutedulo Trazas de la Aplicacioacuten se presenta el registro de la aplicacioacuten a partir de la seleccioacuten realizada por el usuario Fecha determinada

Entre Fechas

Por moacutedulos

A traveacutes del moacutedulo Actualizacioacuten OBU o Actualizacioacuten Parada se puede actualizar el software instalado en los OBU o en las paradas viacutea ftp

AG 33sivaat 12092007 125600 927

Parada

Indice

Parada 10

1 INTRODUCCIOacuteN 11

2 SERVICIOS 11

3 COMPOSICION 11

4 DISTRIBUCION DE EQUIPAMIENTO 13

5 NECESIDADES PREVIAS A LA INSTALACION 18

6 DESCRIPCION HW 18

7 DESCRIPCION SW 18

8 COMUNICACIOacuteN CON CENTRO DE GESTION (CG) 19

9 ASPECTOS DE USUARIO 19

10 CONFIGURACION Y MANTENIMIENTO 19

11 REFERENCIAS 19

AG 33sivaat 12092007 125600 1027

10 INTRODUCCIOacuteN

Como se indica en la descripcioacuten del sistema la Parada estaacute para proporcionar interaccioacuten con el usuario para los servicios SIVAAT (Sistema de Informacioacuten al Viajero de Autobuacutes Accesible para Todos) y para los servicios PARDEM (PARada a la DEManda)

11 SERVICIOS

Tanto servicios SIVAAT como PARDEM Dicho de otro modo proporciona interaccioacuten a los usuarios

bull Normales- A traveacutes de Display y teclas

bull Discapacitados Auditivos- A traveacutes de Display y teclas

bull Discapacitados Visuales- A traveacutes de altavoz y teclas previa lectura de

tarjeta FRID

bull Discapacitados Visuales- tras la lectura de tarjeta RFID y peticioacuten de info

mediante tecla se mostraraacute tanto el proacuteximo autobuacutes como el proacuteximo de

plataforma baja (si lo hubiere)

Asimismo permite realizar peticiones con efecto sobre el conductor de autobuses bull En el caso de Discapacitado Visual se le indica al conductor del autobuacutes

bull En el caso de Discapacitado Fiacutesico tambieacuten se le indica al conductor del

autobuacutes de plataforma baja correspondiente

bull En el caso de haber pulsado tecla de PARada a la DEManda tambieacuten se le indica

al conductor del autobuacutes correspondiente para cualquier tipo de usuario

12 COMPOSICION

Para la realizacioacuten de la necesaria interaccioacuten tanto con el usuario (de distintos tipos) y con el resto del sistema a traveacutes de la comunicacioacuten con el Centro de Gestioacuten (CG) se utiliza un sistema de microprocesador con Sw basado en Linux con el esquema de bloques HW que se indicada en la siguiente figura compuesta de

bull Unidad de Control con el procesador y Sw basado en Linux que controla toda

la parada

bull Detector de Presencia capaz de distinguir la presencia de personas y no la de

coches o pequentildeos animales

bull Lector de tarjeta RFID del tipo tarjeta Sube-T usada en el consorcio de

transportes de la comunidad de Madrid Lee la identidad de la tarjeta

bull Teclas y LEDs de iluminacioacuten con teclas antivandaacutelicas y diodos LED de

iluminacioacuten para permitir la realizacioacuten de peticiones de usuario (cualquiera que

sea el tipo) y para permitir la lectura nocturna de la info impresa junto a las

teclas acerca de las lineas que pasan por la parada

AG 33sivaat 12092007 125600 1127

bull Modem GPRS para comunicacioacuten con el Centro de Gestioacuten (CG) para permitir

interaccion con el resto del sistema

bull Modem BlueTooth para comunicacioacuten con Consola de Mantenimiento

(Consola) situada a escasos metros de la parada usando comunicacioacuten sin hilos

bull Display para proporcionar tanto indicaciones de uso como informacioacuten horaria

y de llegadas previstas de autobuses Es del tipo grafico de frac14 de VGA

bull Altavoz para proporcionar indicaciones sonoras Es del tipo intemperie

bull Sistema de Alimentacioacuten para proporcionar energia a todo el sistema de la

Parada Toma energia de la red de alumbrado (durante la noche) por lo que

necesita bateriacuteas ya que durante el diacutea no llega energiacutea

bull Consola de Mantenimiento se usaraacute solo para pruebas de puesta a punto y

para mantenimiento o ciertos cambios de configuracioacuten en las paradas

ldquoprototipordquo Se comunica a traveacutes de comunicacioacuten inalaacutembrica del tipo

BlueTooth Para un despliegue masivo de paradas debe realizarse a traveacutes de

GPRS e integraacutendolo con el Centro de Gestioacuten (CG)

AG 33sivaat 12092007 125600 1227

76

Unidad

Control

(CPU)

Teclado + LEDs

Expansor

de Puertos

Display

Altavoz

Detector

Presencia

Sistema de

Alimentacion

(en techo)

Modem GPRS

Lector

Tarjeta RFID

Puerto

Mantenimiento

(Modem BlueTooth)

Ethernet

Serie RS 232

4

10

8

Serie RS 232

Serie RS 232

Nota Hilos a la alimentacioacuten no representados

Antena

Fig1 Diagrama de bloques de la Parada

13 DISTRIBUCION DE EQUIPAMIENTO

En la siguiente figura aparece una foto de una parada (donde se equipara uno de los prototipos) asiacute como un detalle de la columna ancha donde va encastrada una caja de material plaacutestico con la mayor parte de los componentes del sistema (todos menos el sistema de alimentacioacuten y el detector de presencia) estos van en sobre refuerzo a realizar sobre la columna ancha a modo de techo plano interior bajo el techo curvo de plaacutestico

AG 33sivaat 12092007 125600 1327

Fig2 Vistas de parada y poste ancho donde se coloca la caja encastrada en

lugar de los carteles informativos

La caja encastrada contiene bull El display bull Las teclas de liacuteneas bull Los textos impresos descriptivos de las liacuteneas con su iluminacioacuten bull Las pegatinas transparentes externas por liacutenea-ruta para poner al lado de cada

tecla con la escritura en coacutedigo Braille bull El lector de tarjeta RFID bull El altavoz

Ademaacutes tambieacuten figuran en el interior de esta caja bull La Unidad de Control (CPU)

AG 33sivaat 12092007 125600 1427

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

Servidor de Aplicaciones JAVA

Moacutedulo WEB Centro de Gestioacuten

Aplicacioacuten WEB

(Cocoon)

Online

Consultas

Informes

Gestor de Informacioacuten de localizacioacuten y estado

Gestor de Informacioacuten de Peticiones

Gestor de Histoacutericos

Base de

Datos

Distpacher

Interfaz entre dispositivos

moacuteviles y el Centro de

Gestioacuten

Carga de Datos de

la Red

Teleacutefonos moacuteviles SMS

GSM

Usuario WEB

HTTP

Usuario

Carga de Datos

OBU

Owasys

Moacutedulo de Captura

de Datos

Aplicacioacuten del

Sistema

Embarcado

Fig

El Sistema estaacute dividido en 5 subsistemas o moacutedulos principales igrave Moacutedulo de aplicaciones de la Parada

igrave Moacutedulo de aplicaciones del sistema embarcado (OBU)

igrave Gestor de mensajes y distribuidor (Distpacher)

igrave Centro de Gestioacuten

Moacutedulo WEB

7 Gestor de mensajes y distribuidor (Distpacher)

El moacutedulo Dispatcher es un interfaz entre los dispositivos perifeacutericos del sistema (moviles y fijos) y el Centro de Gestioacuten Por un lado estaacute el Centro de Gestioacuten con una comunicacioacuten viacutea Intranet con HTTP con un protocolo basado en XML (Extensible Markup Language) y por otro los teleacutefonos moacuteviles los OBU y las paradas La comunicacioacuten con los teleacutefonos moacuteviles se realiza a traveacutes de SMS La comunicacioacuten con los OBU y con las paradas se realiza viacutea Internet con protocolo UDP (User Datagram Protocol) Al Dispatcher van conectados tres modems GSM modelo Siemens TC45 que son los encargados de recibir y enviar los mensajes en principio uno por cada operador de telefoniacutea moacutevil en Espantildea Estos modems TC45 soportan el leguaje de programacioacuten Java y poseen una Maacutequina Virtual Java (JVM) propietaria de Siemens para ello

AG 33sivaat 12092007 125600 727

EL Distpacher es el moacutedulo que gestiona todo el proceso de atencioacuten de peticiones viacutea UDP instanciando un hilo para cada OBU de autobuacutes y para cada parada Este hilo efectua todo el proceso para dicho OBU y cuando se recibe un EOT (End Off Transmission) se elimina ese hilo eliminaacutendose de la tabla de hilos Es decir cuando el autobuacutes o parada realizan una peticioacuten UDP el Dispatcher comprueba si tiene su hilo activo y si no lo instancia Todas las peticiones a traveacutes del protocolo establecido tienen el identificador del peticioinario Si el identificador no se encuentra en el fichero de configuracioacuten entonces la peticioacuten es ignorada

8 Composicioacuten del Centro

El centro de gestioacuten consta de tres moacutedulos principales

Gestor de Informacioacuten de localizacioacuten y estado Gestiona la informacioacuten relacionada con el

estado de los autobuses y su posicioacuten

igrave Asignar autobuses a liacuteneas rutas y coches

igrave Determinacioacuten de la ubicacioacuten y estado de los autobuses

igrave Conocer queacute autobuses estaacuten actualmente en servicio y en queacute liacutenea y ruta estaacuten y van

a estar prestando servicio en los proacuteximos T minutos

igrave Conocer queacute autobuses entraraacuten en servicio en las rutas de intereacutes en los proacuteximos T

minutos

igrave Conocer queacute autobuses dejaraacuten el servicio que estaacuten prestando en las rutas de intereacutes

en los proacuteximos T minutos

Gestor de Informacioacuten de Peticiones Gestiona la informacioacuten relacionada con las peticiones

de los usuarios

igrave Anaacutelisis continuo de las solicitudes

Gestor de Histoacutericos Gestiona toda la informacioacuten relacionada con los histoacutericos de

solicitudes servicio de autobuses y eventos

9 Moacutedulo WEB

Las moacutedulos principales que se presentaraacuten en la WEB son ONLINE Tiempo Real

Consultas Informes

Trazas de la Aplicacioacuten

Actualizacioacuten OBU de autobuses y paradas

A traveacutes del moacutedulo ONLINE es posible visualizar en tiempo real el comportamiento de Autobuses Informacioacuten relacionada con los autobuses que pertenecen a una liacutenea

determinada en cuanto a tiempos de recorridos reales retrasosadelantos etc

Solicitudes Todas las solicitudes activas o las recibidas desde el inicio del servicio

Incidencias Se visualizan todas las incidencias recibidas desde el inicio del servicio

incidencias relacionadas con los autobusesparadas servicio de autobuses solicitudes

AG 33sivaat 12092007 125600 827

Traza de aplicacioacuten

A traveacutes del moacutedulo Consultas Informes es posible obtener informacioacuten del Histoacuterico del sistema iTRA en temas de Tiempos de recorrido

A traveacutes de esta consulta el usuario puede visualizar y comparar los tiempos de recorridos teoacutericos y reales teniendo en cuenta los datos registrados en el Centro de Gestioacuten para cada uno de los autobuses en las diferentes liacuteneas Pueden ser Tiempos de recorrido para una liacutenea y ruta determinada o Tiempos de recorrido entre dos paradas

Horas de salida de cabeceras

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de salida de cabecera estimado y real

Hora de paso por paradas

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de paso por paradas estimado y real

Incidencias

Se puede obtener una tabla con la informacioacuten sobre las incidencias del vehiacuteculo o la

parada en el diacutea a partir de la seleccioacuten de una Fecha Liacutenea yo Tipo de Incidencia

presentaacutendose una lista con los resultados de la consulta

Solicitudes

Se puede obtener una tabla con informacioacuten completa sobre la situacioacuten de las solicitudes

al seleccionar en el menuacute principal esta opcioacuten

A traveacutes del moacutedulo Trazas de la Aplicacioacuten se presenta el registro de la aplicacioacuten a partir de la seleccioacuten realizada por el usuario Fecha determinada

Entre Fechas

Por moacutedulos

A traveacutes del moacutedulo Actualizacioacuten OBU o Actualizacioacuten Parada se puede actualizar el software instalado en los OBU o en las paradas viacutea ftp

AG 33sivaat 12092007 125600 927

Parada

Indice

Parada 10

1 INTRODUCCIOacuteN 11

2 SERVICIOS 11

3 COMPOSICION 11

4 DISTRIBUCION DE EQUIPAMIENTO 13

5 NECESIDADES PREVIAS A LA INSTALACION 18

6 DESCRIPCION HW 18

7 DESCRIPCION SW 18

8 COMUNICACIOacuteN CON CENTRO DE GESTION (CG) 19

9 ASPECTOS DE USUARIO 19

10 CONFIGURACION Y MANTENIMIENTO 19

11 REFERENCIAS 19

AG 33sivaat 12092007 125600 1027

10 INTRODUCCIOacuteN

Como se indica en la descripcioacuten del sistema la Parada estaacute para proporcionar interaccioacuten con el usuario para los servicios SIVAAT (Sistema de Informacioacuten al Viajero de Autobuacutes Accesible para Todos) y para los servicios PARDEM (PARada a la DEManda)

11 SERVICIOS

Tanto servicios SIVAAT como PARDEM Dicho de otro modo proporciona interaccioacuten a los usuarios

bull Normales- A traveacutes de Display y teclas

bull Discapacitados Auditivos- A traveacutes de Display y teclas

bull Discapacitados Visuales- A traveacutes de altavoz y teclas previa lectura de

tarjeta FRID

bull Discapacitados Visuales- tras la lectura de tarjeta RFID y peticioacuten de info

mediante tecla se mostraraacute tanto el proacuteximo autobuacutes como el proacuteximo de

plataforma baja (si lo hubiere)

Asimismo permite realizar peticiones con efecto sobre el conductor de autobuses bull En el caso de Discapacitado Visual se le indica al conductor del autobuacutes

bull En el caso de Discapacitado Fiacutesico tambieacuten se le indica al conductor del

autobuacutes de plataforma baja correspondiente

bull En el caso de haber pulsado tecla de PARada a la DEManda tambieacuten se le indica

al conductor del autobuacutes correspondiente para cualquier tipo de usuario

12 COMPOSICION

Para la realizacioacuten de la necesaria interaccioacuten tanto con el usuario (de distintos tipos) y con el resto del sistema a traveacutes de la comunicacioacuten con el Centro de Gestioacuten (CG) se utiliza un sistema de microprocesador con Sw basado en Linux con el esquema de bloques HW que se indicada en la siguiente figura compuesta de

bull Unidad de Control con el procesador y Sw basado en Linux que controla toda

la parada

bull Detector de Presencia capaz de distinguir la presencia de personas y no la de

coches o pequentildeos animales

bull Lector de tarjeta RFID del tipo tarjeta Sube-T usada en el consorcio de

transportes de la comunidad de Madrid Lee la identidad de la tarjeta

bull Teclas y LEDs de iluminacioacuten con teclas antivandaacutelicas y diodos LED de

iluminacioacuten para permitir la realizacioacuten de peticiones de usuario (cualquiera que

sea el tipo) y para permitir la lectura nocturna de la info impresa junto a las

teclas acerca de las lineas que pasan por la parada

AG 33sivaat 12092007 125600 1127

bull Modem GPRS para comunicacioacuten con el Centro de Gestioacuten (CG) para permitir

interaccion con el resto del sistema

bull Modem BlueTooth para comunicacioacuten con Consola de Mantenimiento

(Consola) situada a escasos metros de la parada usando comunicacioacuten sin hilos

bull Display para proporcionar tanto indicaciones de uso como informacioacuten horaria

y de llegadas previstas de autobuses Es del tipo grafico de frac14 de VGA

bull Altavoz para proporcionar indicaciones sonoras Es del tipo intemperie

bull Sistema de Alimentacioacuten para proporcionar energia a todo el sistema de la

Parada Toma energia de la red de alumbrado (durante la noche) por lo que

necesita bateriacuteas ya que durante el diacutea no llega energiacutea

bull Consola de Mantenimiento se usaraacute solo para pruebas de puesta a punto y

para mantenimiento o ciertos cambios de configuracioacuten en las paradas

ldquoprototipordquo Se comunica a traveacutes de comunicacioacuten inalaacutembrica del tipo

BlueTooth Para un despliegue masivo de paradas debe realizarse a traveacutes de

GPRS e integraacutendolo con el Centro de Gestioacuten (CG)

AG 33sivaat 12092007 125600 1227

76

Unidad

Control

(CPU)

Teclado + LEDs

Expansor

de Puertos

Display

Altavoz

Detector

Presencia

Sistema de

Alimentacion

(en techo)

Modem GPRS

Lector

Tarjeta RFID

Puerto

Mantenimiento

(Modem BlueTooth)

Ethernet

Serie RS 232

4

10

8

Serie RS 232

Serie RS 232

Nota Hilos a la alimentacioacuten no representados

Antena

Fig1 Diagrama de bloques de la Parada

13 DISTRIBUCION DE EQUIPAMIENTO

En la siguiente figura aparece una foto de una parada (donde se equipara uno de los prototipos) asiacute como un detalle de la columna ancha donde va encastrada una caja de material plaacutestico con la mayor parte de los componentes del sistema (todos menos el sistema de alimentacioacuten y el detector de presencia) estos van en sobre refuerzo a realizar sobre la columna ancha a modo de techo plano interior bajo el techo curvo de plaacutestico

AG 33sivaat 12092007 125600 1327

Fig2 Vistas de parada y poste ancho donde se coloca la caja encastrada en

lugar de los carteles informativos

La caja encastrada contiene bull El display bull Las teclas de liacuteneas bull Los textos impresos descriptivos de las liacuteneas con su iluminacioacuten bull Las pegatinas transparentes externas por liacutenea-ruta para poner al lado de cada

tecla con la escritura en coacutedigo Braille bull El lector de tarjeta RFID bull El altavoz

Ademaacutes tambieacuten figuran en el interior de esta caja bull La Unidad de Control (CPU)

AG 33sivaat 12092007 125600 1427

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

EL Distpacher es el moacutedulo que gestiona todo el proceso de atencioacuten de peticiones viacutea UDP instanciando un hilo para cada OBU de autobuacutes y para cada parada Este hilo efectua todo el proceso para dicho OBU y cuando se recibe un EOT (End Off Transmission) se elimina ese hilo eliminaacutendose de la tabla de hilos Es decir cuando el autobuacutes o parada realizan una peticioacuten UDP el Dispatcher comprueba si tiene su hilo activo y si no lo instancia Todas las peticiones a traveacutes del protocolo establecido tienen el identificador del peticioinario Si el identificador no se encuentra en el fichero de configuracioacuten entonces la peticioacuten es ignorada

8 Composicioacuten del Centro

El centro de gestioacuten consta de tres moacutedulos principales

Gestor de Informacioacuten de localizacioacuten y estado Gestiona la informacioacuten relacionada con el

estado de los autobuses y su posicioacuten

igrave Asignar autobuses a liacuteneas rutas y coches

igrave Determinacioacuten de la ubicacioacuten y estado de los autobuses

igrave Conocer queacute autobuses estaacuten actualmente en servicio y en queacute liacutenea y ruta estaacuten y van

a estar prestando servicio en los proacuteximos T minutos

igrave Conocer queacute autobuses entraraacuten en servicio en las rutas de intereacutes en los proacuteximos T

minutos

igrave Conocer queacute autobuses dejaraacuten el servicio que estaacuten prestando en las rutas de intereacutes

en los proacuteximos T minutos

Gestor de Informacioacuten de Peticiones Gestiona la informacioacuten relacionada con las peticiones

de los usuarios

igrave Anaacutelisis continuo de las solicitudes

Gestor de Histoacutericos Gestiona toda la informacioacuten relacionada con los histoacutericos de

solicitudes servicio de autobuses y eventos

9 Moacutedulo WEB

Las moacutedulos principales que se presentaraacuten en la WEB son ONLINE Tiempo Real

Consultas Informes

Trazas de la Aplicacioacuten

Actualizacioacuten OBU de autobuses y paradas

A traveacutes del moacutedulo ONLINE es posible visualizar en tiempo real el comportamiento de Autobuses Informacioacuten relacionada con los autobuses que pertenecen a una liacutenea

determinada en cuanto a tiempos de recorridos reales retrasosadelantos etc

Solicitudes Todas las solicitudes activas o las recibidas desde el inicio del servicio

Incidencias Se visualizan todas las incidencias recibidas desde el inicio del servicio

incidencias relacionadas con los autobusesparadas servicio de autobuses solicitudes

AG 33sivaat 12092007 125600 827

Traza de aplicacioacuten

A traveacutes del moacutedulo Consultas Informes es posible obtener informacioacuten del Histoacuterico del sistema iTRA en temas de Tiempos de recorrido

A traveacutes de esta consulta el usuario puede visualizar y comparar los tiempos de recorridos teoacutericos y reales teniendo en cuenta los datos registrados en el Centro de Gestioacuten para cada uno de los autobuses en las diferentes liacuteneas Pueden ser Tiempos de recorrido para una liacutenea y ruta determinada o Tiempos de recorrido entre dos paradas

Horas de salida de cabeceras

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de salida de cabecera estimado y real

Hora de paso por paradas

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de paso por paradas estimado y real

Incidencias

Se puede obtener una tabla con la informacioacuten sobre las incidencias del vehiacuteculo o la

parada en el diacutea a partir de la seleccioacuten de una Fecha Liacutenea yo Tipo de Incidencia

presentaacutendose una lista con los resultados de la consulta

Solicitudes

Se puede obtener una tabla con informacioacuten completa sobre la situacioacuten de las solicitudes

al seleccionar en el menuacute principal esta opcioacuten

A traveacutes del moacutedulo Trazas de la Aplicacioacuten se presenta el registro de la aplicacioacuten a partir de la seleccioacuten realizada por el usuario Fecha determinada

Entre Fechas

Por moacutedulos

A traveacutes del moacutedulo Actualizacioacuten OBU o Actualizacioacuten Parada se puede actualizar el software instalado en los OBU o en las paradas viacutea ftp

AG 33sivaat 12092007 125600 927

Parada

Indice

Parada 10

1 INTRODUCCIOacuteN 11

2 SERVICIOS 11

3 COMPOSICION 11

4 DISTRIBUCION DE EQUIPAMIENTO 13

5 NECESIDADES PREVIAS A LA INSTALACION 18

6 DESCRIPCION HW 18

7 DESCRIPCION SW 18

8 COMUNICACIOacuteN CON CENTRO DE GESTION (CG) 19

9 ASPECTOS DE USUARIO 19

10 CONFIGURACION Y MANTENIMIENTO 19

11 REFERENCIAS 19

AG 33sivaat 12092007 125600 1027

10 INTRODUCCIOacuteN

Como se indica en la descripcioacuten del sistema la Parada estaacute para proporcionar interaccioacuten con el usuario para los servicios SIVAAT (Sistema de Informacioacuten al Viajero de Autobuacutes Accesible para Todos) y para los servicios PARDEM (PARada a la DEManda)

11 SERVICIOS

Tanto servicios SIVAAT como PARDEM Dicho de otro modo proporciona interaccioacuten a los usuarios

bull Normales- A traveacutes de Display y teclas

bull Discapacitados Auditivos- A traveacutes de Display y teclas

bull Discapacitados Visuales- A traveacutes de altavoz y teclas previa lectura de

tarjeta FRID

bull Discapacitados Visuales- tras la lectura de tarjeta RFID y peticioacuten de info

mediante tecla se mostraraacute tanto el proacuteximo autobuacutes como el proacuteximo de

plataforma baja (si lo hubiere)

Asimismo permite realizar peticiones con efecto sobre el conductor de autobuses bull En el caso de Discapacitado Visual se le indica al conductor del autobuacutes

bull En el caso de Discapacitado Fiacutesico tambieacuten se le indica al conductor del

autobuacutes de plataforma baja correspondiente

bull En el caso de haber pulsado tecla de PARada a la DEManda tambieacuten se le indica

al conductor del autobuacutes correspondiente para cualquier tipo de usuario

12 COMPOSICION

Para la realizacioacuten de la necesaria interaccioacuten tanto con el usuario (de distintos tipos) y con el resto del sistema a traveacutes de la comunicacioacuten con el Centro de Gestioacuten (CG) se utiliza un sistema de microprocesador con Sw basado en Linux con el esquema de bloques HW que se indicada en la siguiente figura compuesta de

bull Unidad de Control con el procesador y Sw basado en Linux que controla toda

la parada

bull Detector de Presencia capaz de distinguir la presencia de personas y no la de

coches o pequentildeos animales

bull Lector de tarjeta RFID del tipo tarjeta Sube-T usada en el consorcio de

transportes de la comunidad de Madrid Lee la identidad de la tarjeta

bull Teclas y LEDs de iluminacioacuten con teclas antivandaacutelicas y diodos LED de

iluminacioacuten para permitir la realizacioacuten de peticiones de usuario (cualquiera que

sea el tipo) y para permitir la lectura nocturna de la info impresa junto a las

teclas acerca de las lineas que pasan por la parada

AG 33sivaat 12092007 125600 1127

bull Modem GPRS para comunicacioacuten con el Centro de Gestioacuten (CG) para permitir

interaccion con el resto del sistema

bull Modem BlueTooth para comunicacioacuten con Consola de Mantenimiento

(Consola) situada a escasos metros de la parada usando comunicacioacuten sin hilos

bull Display para proporcionar tanto indicaciones de uso como informacioacuten horaria

y de llegadas previstas de autobuses Es del tipo grafico de frac14 de VGA

bull Altavoz para proporcionar indicaciones sonoras Es del tipo intemperie

bull Sistema de Alimentacioacuten para proporcionar energia a todo el sistema de la

Parada Toma energia de la red de alumbrado (durante la noche) por lo que

necesita bateriacuteas ya que durante el diacutea no llega energiacutea

bull Consola de Mantenimiento se usaraacute solo para pruebas de puesta a punto y

para mantenimiento o ciertos cambios de configuracioacuten en las paradas

ldquoprototipordquo Se comunica a traveacutes de comunicacioacuten inalaacutembrica del tipo

BlueTooth Para un despliegue masivo de paradas debe realizarse a traveacutes de

GPRS e integraacutendolo con el Centro de Gestioacuten (CG)

AG 33sivaat 12092007 125600 1227

76

Unidad

Control

(CPU)

Teclado + LEDs

Expansor

de Puertos

Display

Altavoz

Detector

Presencia

Sistema de

Alimentacion

(en techo)

Modem GPRS

Lector

Tarjeta RFID

Puerto

Mantenimiento

(Modem BlueTooth)

Ethernet

Serie RS 232

4

10

8

Serie RS 232

Serie RS 232

Nota Hilos a la alimentacioacuten no representados

Antena

Fig1 Diagrama de bloques de la Parada

13 DISTRIBUCION DE EQUIPAMIENTO

En la siguiente figura aparece una foto de una parada (donde se equipara uno de los prototipos) asiacute como un detalle de la columna ancha donde va encastrada una caja de material plaacutestico con la mayor parte de los componentes del sistema (todos menos el sistema de alimentacioacuten y el detector de presencia) estos van en sobre refuerzo a realizar sobre la columna ancha a modo de techo plano interior bajo el techo curvo de plaacutestico

AG 33sivaat 12092007 125600 1327

Fig2 Vistas de parada y poste ancho donde se coloca la caja encastrada en

lugar de los carteles informativos

La caja encastrada contiene bull El display bull Las teclas de liacuteneas bull Los textos impresos descriptivos de las liacuteneas con su iluminacioacuten bull Las pegatinas transparentes externas por liacutenea-ruta para poner al lado de cada

tecla con la escritura en coacutedigo Braille bull El lector de tarjeta RFID bull El altavoz

Ademaacutes tambieacuten figuran en el interior de esta caja bull La Unidad de Control (CPU)

AG 33sivaat 12092007 125600 1427

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

Traza de aplicacioacuten

A traveacutes del moacutedulo Consultas Informes es posible obtener informacioacuten del Histoacuterico del sistema iTRA en temas de Tiempos de recorrido

A traveacutes de esta consulta el usuario puede visualizar y comparar los tiempos de recorridos teoacutericos y reales teniendo en cuenta los datos registrados en el Centro de Gestioacuten para cada uno de los autobuses en las diferentes liacuteneas Pueden ser Tiempos de recorrido para una liacutenea y ruta determinada o Tiempos de recorrido entre dos paradas

Horas de salida de cabeceras

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de salida de cabecera estimado y real

Hora de paso por paradas

Al seleccionar esta consulta el usuario podraacute visualizar para una Liacutenea Ruta determinada

la Hora de paso por paradas estimado y real

Incidencias

Se puede obtener una tabla con la informacioacuten sobre las incidencias del vehiacuteculo o la

parada en el diacutea a partir de la seleccioacuten de una Fecha Liacutenea yo Tipo de Incidencia

presentaacutendose una lista con los resultados de la consulta

Solicitudes

Se puede obtener una tabla con informacioacuten completa sobre la situacioacuten de las solicitudes

al seleccionar en el menuacute principal esta opcioacuten

A traveacutes del moacutedulo Trazas de la Aplicacioacuten se presenta el registro de la aplicacioacuten a partir de la seleccioacuten realizada por el usuario Fecha determinada

Entre Fechas

Por moacutedulos

A traveacutes del moacutedulo Actualizacioacuten OBU o Actualizacioacuten Parada se puede actualizar el software instalado en los OBU o en las paradas viacutea ftp

AG 33sivaat 12092007 125600 927

Parada

Indice

Parada 10

1 INTRODUCCIOacuteN 11

2 SERVICIOS 11

3 COMPOSICION 11

4 DISTRIBUCION DE EQUIPAMIENTO 13

5 NECESIDADES PREVIAS A LA INSTALACION 18

6 DESCRIPCION HW 18

7 DESCRIPCION SW 18

8 COMUNICACIOacuteN CON CENTRO DE GESTION (CG) 19

9 ASPECTOS DE USUARIO 19

10 CONFIGURACION Y MANTENIMIENTO 19

11 REFERENCIAS 19

AG 33sivaat 12092007 125600 1027

10 INTRODUCCIOacuteN

Como se indica en la descripcioacuten del sistema la Parada estaacute para proporcionar interaccioacuten con el usuario para los servicios SIVAAT (Sistema de Informacioacuten al Viajero de Autobuacutes Accesible para Todos) y para los servicios PARDEM (PARada a la DEManda)

11 SERVICIOS

Tanto servicios SIVAAT como PARDEM Dicho de otro modo proporciona interaccioacuten a los usuarios

bull Normales- A traveacutes de Display y teclas

bull Discapacitados Auditivos- A traveacutes de Display y teclas

bull Discapacitados Visuales- A traveacutes de altavoz y teclas previa lectura de

tarjeta FRID

bull Discapacitados Visuales- tras la lectura de tarjeta RFID y peticioacuten de info

mediante tecla se mostraraacute tanto el proacuteximo autobuacutes como el proacuteximo de

plataforma baja (si lo hubiere)

Asimismo permite realizar peticiones con efecto sobre el conductor de autobuses bull En el caso de Discapacitado Visual se le indica al conductor del autobuacutes

bull En el caso de Discapacitado Fiacutesico tambieacuten se le indica al conductor del

autobuacutes de plataforma baja correspondiente

bull En el caso de haber pulsado tecla de PARada a la DEManda tambieacuten se le indica

al conductor del autobuacutes correspondiente para cualquier tipo de usuario

12 COMPOSICION

Para la realizacioacuten de la necesaria interaccioacuten tanto con el usuario (de distintos tipos) y con el resto del sistema a traveacutes de la comunicacioacuten con el Centro de Gestioacuten (CG) se utiliza un sistema de microprocesador con Sw basado en Linux con el esquema de bloques HW que se indicada en la siguiente figura compuesta de

bull Unidad de Control con el procesador y Sw basado en Linux que controla toda

la parada

bull Detector de Presencia capaz de distinguir la presencia de personas y no la de

coches o pequentildeos animales

bull Lector de tarjeta RFID del tipo tarjeta Sube-T usada en el consorcio de

transportes de la comunidad de Madrid Lee la identidad de la tarjeta

bull Teclas y LEDs de iluminacioacuten con teclas antivandaacutelicas y diodos LED de

iluminacioacuten para permitir la realizacioacuten de peticiones de usuario (cualquiera que

sea el tipo) y para permitir la lectura nocturna de la info impresa junto a las

teclas acerca de las lineas que pasan por la parada

AG 33sivaat 12092007 125600 1127

bull Modem GPRS para comunicacioacuten con el Centro de Gestioacuten (CG) para permitir

interaccion con el resto del sistema

bull Modem BlueTooth para comunicacioacuten con Consola de Mantenimiento

(Consola) situada a escasos metros de la parada usando comunicacioacuten sin hilos

bull Display para proporcionar tanto indicaciones de uso como informacioacuten horaria

y de llegadas previstas de autobuses Es del tipo grafico de frac14 de VGA

bull Altavoz para proporcionar indicaciones sonoras Es del tipo intemperie

bull Sistema de Alimentacioacuten para proporcionar energia a todo el sistema de la

Parada Toma energia de la red de alumbrado (durante la noche) por lo que

necesita bateriacuteas ya que durante el diacutea no llega energiacutea

bull Consola de Mantenimiento se usaraacute solo para pruebas de puesta a punto y

para mantenimiento o ciertos cambios de configuracioacuten en las paradas

ldquoprototipordquo Se comunica a traveacutes de comunicacioacuten inalaacutembrica del tipo

BlueTooth Para un despliegue masivo de paradas debe realizarse a traveacutes de

GPRS e integraacutendolo con el Centro de Gestioacuten (CG)

AG 33sivaat 12092007 125600 1227

76

Unidad

Control

(CPU)

Teclado + LEDs

Expansor

de Puertos

Display

Altavoz

Detector

Presencia

Sistema de

Alimentacion

(en techo)

Modem GPRS

Lector

Tarjeta RFID

Puerto

Mantenimiento

(Modem BlueTooth)

Ethernet

Serie RS 232

4

10

8

Serie RS 232

Serie RS 232

Nota Hilos a la alimentacioacuten no representados

Antena

Fig1 Diagrama de bloques de la Parada

13 DISTRIBUCION DE EQUIPAMIENTO

En la siguiente figura aparece una foto de una parada (donde se equipara uno de los prototipos) asiacute como un detalle de la columna ancha donde va encastrada una caja de material plaacutestico con la mayor parte de los componentes del sistema (todos menos el sistema de alimentacioacuten y el detector de presencia) estos van en sobre refuerzo a realizar sobre la columna ancha a modo de techo plano interior bajo el techo curvo de plaacutestico

AG 33sivaat 12092007 125600 1327

Fig2 Vistas de parada y poste ancho donde se coloca la caja encastrada en

lugar de los carteles informativos

La caja encastrada contiene bull El display bull Las teclas de liacuteneas bull Los textos impresos descriptivos de las liacuteneas con su iluminacioacuten bull Las pegatinas transparentes externas por liacutenea-ruta para poner al lado de cada

tecla con la escritura en coacutedigo Braille bull El lector de tarjeta RFID bull El altavoz

Ademaacutes tambieacuten figuran en el interior de esta caja bull La Unidad de Control (CPU)

AG 33sivaat 12092007 125600 1427

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

Parada

Indice

Parada 10

1 INTRODUCCIOacuteN 11

2 SERVICIOS 11

3 COMPOSICION 11

4 DISTRIBUCION DE EQUIPAMIENTO 13

5 NECESIDADES PREVIAS A LA INSTALACION 18

6 DESCRIPCION HW 18

7 DESCRIPCION SW 18

8 COMUNICACIOacuteN CON CENTRO DE GESTION (CG) 19

9 ASPECTOS DE USUARIO 19

10 CONFIGURACION Y MANTENIMIENTO 19

11 REFERENCIAS 19

AG 33sivaat 12092007 125600 1027

10 INTRODUCCIOacuteN

Como se indica en la descripcioacuten del sistema la Parada estaacute para proporcionar interaccioacuten con el usuario para los servicios SIVAAT (Sistema de Informacioacuten al Viajero de Autobuacutes Accesible para Todos) y para los servicios PARDEM (PARada a la DEManda)

11 SERVICIOS

Tanto servicios SIVAAT como PARDEM Dicho de otro modo proporciona interaccioacuten a los usuarios

bull Normales- A traveacutes de Display y teclas

bull Discapacitados Auditivos- A traveacutes de Display y teclas

bull Discapacitados Visuales- A traveacutes de altavoz y teclas previa lectura de

tarjeta FRID

bull Discapacitados Visuales- tras la lectura de tarjeta RFID y peticioacuten de info

mediante tecla se mostraraacute tanto el proacuteximo autobuacutes como el proacuteximo de

plataforma baja (si lo hubiere)

Asimismo permite realizar peticiones con efecto sobre el conductor de autobuses bull En el caso de Discapacitado Visual se le indica al conductor del autobuacutes

bull En el caso de Discapacitado Fiacutesico tambieacuten se le indica al conductor del

autobuacutes de plataforma baja correspondiente

bull En el caso de haber pulsado tecla de PARada a la DEManda tambieacuten se le indica

al conductor del autobuacutes correspondiente para cualquier tipo de usuario

12 COMPOSICION

Para la realizacioacuten de la necesaria interaccioacuten tanto con el usuario (de distintos tipos) y con el resto del sistema a traveacutes de la comunicacioacuten con el Centro de Gestioacuten (CG) se utiliza un sistema de microprocesador con Sw basado en Linux con el esquema de bloques HW que se indicada en la siguiente figura compuesta de

bull Unidad de Control con el procesador y Sw basado en Linux que controla toda

la parada

bull Detector de Presencia capaz de distinguir la presencia de personas y no la de

coches o pequentildeos animales

bull Lector de tarjeta RFID del tipo tarjeta Sube-T usada en el consorcio de

transportes de la comunidad de Madrid Lee la identidad de la tarjeta

bull Teclas y LEDs de iluminacioacuten con teclas antivandaacutelicas y diodos LED de

iluminacioacuten para permitir la realizacioacuten de peticiones de usuario (cualquiera que

sea el tipo) y para permitir la lectura nocturna de la info impresa junto a las

teclas acerca de las lineas que pasan por la parada

AG 33sivaat 12092007 125600 1127

bull Modem GPRS para comunicacioacuten con el Centro de Gestioacuten (CG) para permitir

interaccion con el resto del sistema

bull Modem BlueTooth para comunicacioacuten con Consola de Mantenimiento

(Consola) situada a escasos metros de la parada usando comunicacioacuten sin hilos

bull Display para proporcionar tanto indicaciones de uso como informacioacuten horaria

y de llegadas previstas de autobuses Es del tipo grafico de frac14 de VGA

bull Altavoz para proporcionar indicaciones sonoras Es del tipo intemperie

bull Sistema de Alimentacioacuten para proporcionar energia a todo el sistema de la

Parada Toma energia de la red de alumbrado (durante la noche) por lo que

necesita bateriacuteas ya que durante el diacutea no llega energiacutea

bull Consola de Mantenimiento se usaraacute solo para pruebas de puesta a punto y

para mantenimiento o ciertos cambios de configuracioacuten en las paradas

ldquoprototipordquo Se comunica a traveacutes de comunicacioacuten inalaacutembrica del tipo

BlueTooth Para un despliegue masivo de paradas debe realizarse a traveacutes de

GPRS e integraacutendolo con el Centro de Gestioacuten (CG)

AG 33sivaat 12092007 125600 1227

76

Unidad

Control

(CPU)

Teclado + LEDs

Expansor

de Puertos

Display

Altavoz

Detector

Presencia

Sistema de

Alimentacion

(en techo)

Modem GPRS

Lector

Tarjeta RFID

Puerto

Mantenimiento

(Modem BlueTooth)

Ethernet

Serie RS 232

4

10

8

Serie RS 232

Serie RS 232

Nota Hilos a la alimentacioacuten no representados

Antena

Fig1 Diagrama de bloques de la Parada

13 DISTRIBUCION DE EQUIPAMIENTO

En la siguiente figura aparece una foto de una parada (donde se equipara uno de los prototipos) asiacute como un detalle de la columna ancha donde va encastrada una caja de material plaacutestico con la mayor parte de los componentes del sistema (todos menos el sistema de alimentacioacuten y el detector de presencia) estos van en sobre refuerzo a realizar sobre la columna ancha a modo de techo plano interior bajo el techo curvo de plaacutestico

AG 33sivaat 12092007 125600 1327

Fig2 Vistas de parada y poste ancho donde se coloca la caja encastrada en

lugar de los carteles informativos

La caja encastrada contiene bull El display bull Las teclas de liacuteneas bull Los textos impresos descriptivos de las liacuteneas con su iluminacioacuten bull Las pegatinas transparentes externas por liacutenea-ruta para poner al lado de cada

tecla con la escritura en coacutedigo Braille bull El lector de tarjeta RFID bull El altavoz

Ademaacutes tambieacuten figuran en el interior de esta caja bull La Unidad de Control (CPU)

AG 33sivaat 12092007 125600 1427

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

10 INTRODUCCIOacuteN

Como se indica en la descripcioacuten del sistema la Parada estaacute para proporcionar interaccioacuten con el usuario para los servicios SIVAAT (Sistema de Informacioacuten al Viajero de Autobuacutes Accesible para Todos) y para los servicios PARDEM (PARada a la DEManda)

11 SERVICIOS

Tanto servicios SIVAAT como PARDEM Dicho de otro modo proporciona interaccioacuten a los usuarios

bull Normales- A traveacutes de Display y teclas

bull Discapacitados Auditivos- A traveacutes de Display y teclas

bull Discapacitados Visuales- A traveacutes de altavoz y teclas previa lectura de

tarjeta FRID

bull Discapacitados Visuales- tras la lectura de tarjeta RFID y peticioacuten de info

mediante tecla se mostraraacute tanto el proacuteximo autobuacutes como el proacuteximo de

plataforma baja (si lo hubiere)

Asimismo permite realizar peticiones con efecto sobre el conductor de autobuses bull En el caso de Discapacitado Visual se le indica al conductor del autobuacutes

bull En el caso de Discapacitado Fiacutesico tambieacuten se le indica al conductor del

autobuacutes de plataforma baja correspondiente

bull En el caso de haber pulsado tecla de PARada a la DEManda tambieacuten se le indica

al conductor del autobuacutes correspondiente para cualquier tipo de usuario

12 COMPOSICION

Para la realizacioacuten de la necesaria interaccioacuten tanto con el usuario (de distintos tipos) y con el resto del sistema a traveacutes de la comunicacioacuten con el Centro de Gestioacuten (CG) se utiliza un sistema de microprocesador con Sw basado en Linux con el esquema de bloques HW que se indicada en la siguiente figura compuesta de

bull Unidad de Control con el procesador y Sw basado en Linux que controla toda

la parada

bull Detector de Presencia capaz de distinguir la presencia de personas y no la de

coches o pequentildeos animales

bull Lector de tarjeta RFID del tipo tarjeta Sube-T usada en el consorcio de

transportes de la comunidad de Madrid Lee la identidad de la tarjeta

bull Teclas y LEDs de iluminacioacuten con teclas antivandaacutelicas y diodos LED de

iluminacioacuten para permitir la realizacioacuten de peticiones de usuario (cualquiera que

sea el tipo) y para permitir la lectura nocturna de la info impresa junto a las

teclas acerca de las lineas que pasan por la parada

AG 33sivaat 12092007 125600 1127

bull Modem GPRS para comunicacioacuten con el Centro de Gestioacuten (CG) para permitir

interaccion con el resto del sistema

bull Modem BlueTooth para comunicacioacuten con Consola de Mantenimiento

(Consola) situada a escasos metros de la parada usando comunicacioacuten sin hilos

bull Display para proporcionar tanto indicaciones de uso como informacioacuten horaria

y de llegadas previstas de autobuses Es del tipo grafico de frac14 de VGA

bull Altavoz para proporcionar indicaciones sonoras Es del tipo intemperie

bull Sistema de Alimentacioacuten para proporcionar energia a todo el sistema de la

Parada Toma energia de la red de alumbrado (durante la noche) por lo que

necesita bateriacuteas ya que durante el diacutea no llega energiacutea

bull Consola de Mantenimiento se usaraacute solo para pruebas de puesta a punto y

para mantenimiento o ciertos cambios de configuracioacuten en las paradas

ldquoprototipordquo Se comunica a traveacutes de comunicacioacuten inalaacutembrica del tipo

BlueTooth Para un despliegue masivo de paradas debe realizarse a traveacutes de

GPRS e integraacutendolo con el Centro de Gestioacuten (CG)

AG 33sivaat 12092007 125600 1227

76

Unidad

Control

(CPU)

Teclado + LEDs

Expansor

de Puertos

Display

Altavoz

Detector

Presencia

Sistema de

Alimentacion

(en techo)

Modem GPRS

Lector

Tarjeta RFID

Puerto

Mantenimiento

(Modem BlueTooth)

Ethernet

Serie RS 232

4

10

8

Serie RS 232

Serie RS 232

Nota Hilos a la alimentacioacuten no representados

Antena

Fig1 Diagrama de bloques de la Parada

13 DISTRIBUCION DE EQUIPAMIENTO

En la siguiente figura aparece una foto de una parada (donde se equipara uno de los prototipos) asiacute como un detalle de la columna ancha donde va encastrada una caja de material plaacutestico con la mayor parte de los componentes del sistema (todos menos el sistema de alimentacioacuten y el detector de presencia) estos van en sobre refuerzo a realizar sobre la columna ancha a modo de techo plano interior bajo el techo curvo de plaacutestico

AG 33sivaat 12092007 125600 1327

Fig2 Vistas de parada y poste ancho donde se coloca la caja encastrada en

lugar de los carteles informativos

La caja encastrada contiene bull El display bull Las teclas de liacuteneas bull Los textos impresos descriptivos de las liacuteneas con su iluminacioacuten bull Las pegatinas transparentes externas por liacutenea-ruta para poner al lado de cada

tecla con la escritura en coacutedigo Braille bull El lector de tarjeta RFID bull El altavoz

Ademaacutes tambieacuten figuran en el interior de esta caja bull La Unidad de Control (CPU)

AG 33sivaat 12092007 125600 1427

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

bull Modem GPRS para comunicacioacuten con el Centro de Gestioacuten (CG) para permitir

interaccion con el resto del sistema

bull Modem BlueTooth para comunicacioacuten con Consola de Mantenimiento

(Consola) situada a escasos metros de la parada usando comunicacioacuten sin hilos

bull Display para proporcionar tanto indicaciones de uso como informacioacuten horaria

y de llegadas previstas de autobuses Es del tipo grafico de frac14 de VGA

bull Altavoz para proporcionar indicaciones sonoras Es del tipo intemperie

bull Sistema de Alimentacioacuten para proporcionar energia a todo el sistema de la

Parada Toma energia de la red de alumbrado (durante la noche) por lo que

necesita bateriacuteas ya que durante el diacutea no llega energiacutea

bull Consola de Mantenimiento se usaraacute solo para pruebas de puesta a punto y

para mantenimiento o ciertos cambios de configuracioacuten en las paradas

ldquoprototipordquo Se comunica a traveacutes de comunicacioacuten inalaacutembrica del tipo

BlueTooth Para un despliegue masivo de paradas debe realizarse a traveacutes de

GPRS e integraacutendolo con el Centro de Gestioacuten (CG)

AG 33sivaat 12092007 125600 1227

76

Unidad

Control

(CPU)

Teclado + LEDs

Expansor

de Puertos

Display

Altavoz

Detector

Presencia

Sistema de

Alimentacion

(en techo)

Modem GPRS

Lector

Tarjeta RFID

Puerto

Mantenimiento

(Modem BlueTooth)

Ethernet

Serie RS 232

4

10

8

Serie RS 232

Serie RS 232

Nota Hilos a la alimentacioacuten no representados

Antena

Fig1 Diagrama de bloques de la Parada

13 DISTRIBUCION DE EQUIPAMIENTO

En la siguiente figura aparece una foto de una parada (donde se equipara uno de los prototipos) asiacute como un detalle de la columna ancha donde va encastrada una caja de material plaacutestico con la mayor parte de los componentes del sistema (todos menos el sistema de alimentacioacuten y el detector de presencia) estos van en sobre refuerzo a realizar sobre la columna ancha a modo de techo plano interior bajo el techo curvo de plaacutestico

AG 33sivaat 12092007 125600 1327

Fig2 Vistas de parada y poste ancho donde se coloca la caja encastrada en

lugar de los carteles informativos

La caja encastrada contiene bull El display bull Las teclas de liacuteneas bull Los textos impresos descriptivos de las liacuteneas con su iluminacioacuten bull Las pegatinas transparentes externas por liacutenea-ruta para poner al lado de cada

tecla con la escritura en coacutedigo Braille bull El lector de tarjeta RFID bull El altavoz

Ademaacutes tambieacuten figuran en el interior de esta caja bull La Unidad de Control (CPU)

AG 33sivaat 12092007 125600 1427

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

76

Unidad

Control

(CPU)

Teclado + LEDs

Expansor

de Puertos

Display

Altavoz

Detector

Presencia

Sistema de

Alimentacion

(en techo)

Modem GPRS

Lector

Tarjeta RFID

Puerto

Mantenimiento

(Modem BlueTooth)

Ethernet

Serie RS 232

4

10

8

Serie RS 232

Serie RS 232

Nota Hilos a la alimentacioacuten no representados

Antena

Fig1 Diagrama de bloques de la Parada

13 DISTRIBUCION DE EQUIPAMIENTO

En la siguiente figura aparece una foto de una parada (donde se equipara uno de los prototipos) asiacute como un detalle de la columna ancha donde va encastrada una caja de material plaacutestico con la mayor parte de los componentes del sistema (todos menos el sistema de alimentacioacuten y el detector de presencia) estos van en sobre refuerzo a realizar sobre la columna ancha a modo de techo plano interior bajo el techo curvo de plaacutestico

AG 33sivaat 12092007 125600 1327

Fig2 Vistas de parada y poste ancho donde se coloca la caja encastrada en

lugar de los carteles informativos

La caja encastrada contiene bull El display bull Las teclas de liacuteneas bull Los textos impresos descriptivos de las liacuteneas con su iluminacioacuten bull Las pegatinas transparentes externas por liacutenea-ruta para poner al lado de cada

tecla con la escritura en coacutedigo Braille bull El lector de tarjeta RFID bull El altavoz

Ademaacutes tambieacuten figuran en el interior de esta caja bull La Unidad de Control (CPU)

AG 33sivaat 12092007 125600 1427

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

Fig2 Vistas de parada y poste ancho donde se coloca la caja encastrada en

lugar de los carteles informativos

La caja encastrada contiene bull El display bull Las teclas de liacuteneas bull Los textos impresos descriptivos de las liacuteneas con su iluminacioacuten bull Las pegatinas transparentes externas por liacutenea-ruta para poner al lado de cada

tecla con la escritura en coacutedigo Braille bull El lector de tarjeta RFID bull El altavoz

Ademaacutes tambieacuten figuran en el interior de esta caja bull La Unidad de Control (CPU)

AG 33sivaat 12092007 125600 1427

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

bull El modem GPRS bull El modem BlueTooth

El aspecto de la caja se muestra en las siguiente figuras

Dimensiones 775 x 170 mm Fig3 Aspecto frontal de la caja encastrada (como lo ve el puacuteblico)

En la parte superior de la columna ancha se colocaraacute un techo plano de algo mas de 20 cm de ancho con ayuda de un perfil cuadrangular como aparece en la siguiente

AG 33sivaat 12092007 125600 1527

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

figura Sobre dicho techo se colocara una caja eleacutectrica donde se equipa tanto el sistema de alimentacioacuten como el detector de presencia

AG 33sivaat 12092007 125600 1627

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

AG 33sivaat 12092007 125600 1727

Fig 4 Plano modificado de la parada)

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

Fig4 +++ Planos modificados de la parada De esta caja parten los cables de

bull Alimentacioacuten para el resto del sistema (5 12 y 24Vdc) bull 2 hilos maacutes para unir el detector de presencia con la Unidad de Control bull El cable de red para conexioacuten al alumbrado bull El cable de tierra para la conexioacuten a pica en el caso de que la tierra del citado

techo plano no fuera lo bastante buena

14 NECESIDADES PREVIAS A LA INSTALACION

bull Parada con techo modelo de la comunidad con poste ancho bull Alimentacioacuten de alumbrado bull Tierra de suficiente calidad (en estructura metalica de la parada o en pica) bull Cobertura GSMGPRS

15 DESCRIPCION HW

Ver documento de Descripcioacuten Hw de la Parada (fichero DescripcionHwParadadoc)

16 DESCRIPCION SW

Ver documento de Descripcioacuten Sw de la Parada (fichero DescripcionSwParadadoc)

AG 33sivaat 12092007 125600 1827

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

17 COMUNICACIOacuteN CON CENTRO DE GESTION (CG)

Se realiza a traveacutes del modem GPRS Para ello se usa el protocolo de comunicacioacuten que se describe en el documento de Tekia Protocolo_ITRA - SIVAAT v17doc

18 ASPECTOS DE USUARIO

La interaccioacuten del usuario se realiza a traveacutes del frontal de la caja encastrada a traveacutes del Display teclas Textos impresos y Braille altavoz y lector de tarjeta RFID (Tarjeta Sube-T) La funcionalidad de usuario se describe para el usuario en el documentos Manual de usuario (ficheros ManualUsuariodoc) Un mayor detalle estaacute contenido en el documento Aspecto de Usuario fichero AspectoUsuariodoc

19 CONFIGURACION Y MANTENIMIENTO

Configuracioacuten de textos impresos Configuracioacuten de textos Braille y abreviaturas en relieve Configuracioacuten del HW Configuracioacuten desde Consola

bull Carga de Sw bull Cambio de guiacuteas vocales bull Cambio de paraacutemetros de configuracioacuten bull Log de anomaliacuteas bull Pruebas de consistencia

Protocolo de pruebas de funcionalidad de usuario Es un protocolo de pruebas cuyo paso exitoso significa que la parada queda en perfectas condiciones operativas fichero ProtocoloPruebasParada-Rev0doc Un mayor detalle sobre estos aspectos puede encontrarse en el documento de Montaje e Instalacioacuten Puesta a Punto y Mantenimiento fichero MontajeInstalacionPuestaAPuntoManteniemientodoc

20 REFERENCIAS

PAGE

Fichero Nombre Descripcioacuten

Docsdoc Documentacioacuten de la Parada EspecificacionTecnicaParadadoc Parada DescripcionHwParadadoc Descripcioacuten Hw de la Parada DescripcionSwParadadoc Descripcioacuten Sw de la Parada ManualUsuariodoc Manual de Usuario AspectoUsuariodoc Aspecto de Usuario

AG 33sivaat 12092007 125600 1927

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

MontajeInstalacionPuestaAPuntoM anteniemientodoc

Montaje e Instalacioacuten Puesta a Punto y Mantenimiento

ProtocoloPruebasParada-Rev0doc Protocolo de Pruebas de Parada

PlanificacionInstalacionParadasdo c

Planificacioacuten de Instalacioacuten de Paradas

ElementosParadaxls Lista de Materiales

TEKIA Fichero Nombre Descripcion

Descripcioacuten Funcional SIVAAT V05doc

Descripcioacuten funcioanal de del sistema SIVAAT

Protocolo_ITRA - SIVAAT v17doc Protocolo de comunicacioacuten Parada - Centro de Gestioacuten

AG 33sivaat 12092007 125600 2027

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

Sistema SIVAAT-PARDEM

(Especificacion Tecnica)

Indice

Sistema SIVAAT-PARDEM 21

(Especificacion Tecnica) 21

1 INTRODUCCIOacuteN 22

2 Objetivo principal del proyecto 22

3 Actividades 22

4 Arquitectura fisica del Sistema 23

5 Entorno Tecnoloacutegico 24

6 Prueba Piloto 24

7 Incidencias 24

8 Asignacioacuten a liacutenea y ruta 24

9 Precisioacuten en la estimacioacuten de los tiempos 25

10 Carga de datos 25

11 Gestioacuten del traacutefico de autobuses en intercambiadores 26

12 Proacuteximos pasos 27

13 INFORMACIOacuteN Y PUBLICIDAD 27

AG 33sivaat 12092007 125600 2127

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

21 INTRODUCCIOacuteN

Este documento constituye el informe teacutecnico de justificacioacuten de las actividades realizadas por Page en el proyecto SIVAAT-PARDEM para el desarrollo del prototipo de un Sistema de Informacioacuten en tiempo real para los usuarios del transporte de Autobuses Accesible a Todos con funcionalidad antildeadida de PARada a la DEManda (PARDEM)

22 Objetivo principal del proyecto

La indicacioacuten del tiempo de espera en paradas de autobuses requiere de un sistema de localizacioacuten de los autobuses y de un medio de comunicacioacuten de datos entre eacutestos y un centro Estas funciones estaacuten disponibles en los sistemas de ayuda a la explotacioacuten (SAE) pero estos sistemas son complejos de aplicar en un escenario de numerosas empresas operadoras muchas de ellas de pequentildeo tamantildeo donde los beneficios que podriacutean ser obtenidos no compensan los costes de inversioacuten y explotacioacuten del SAE y donde la cobertura de comunicaciones requerida (normalmente en aacutereas interurbanas extensas) hace econoacutemicamente difiacutecil la utilizacioacuten de las soluciones hasta ahora convencionales basadas en sistemas propietarios de transmisioacuten de datos sobre radiotelefoniacutea moacutevil privada Es en las aacutereas interurbanas y regionales donde maacutes interesante resulta ofrecer al usuario la informacioacuten en tiempo real sobre tiempos de llegada del proacuteximo autobuacutes Por ello en el marco de las acciones que desarrolla el Consorcio Regional de Transportes (CRTM) de Madrid para la utilizacioacuten de nuevas tecnologiacuteas esta institucioacuten decidioacute iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad definir impulsar el desarrollo e implantar una solucioacuten viable para ofrecer a los viajeros de autobuses interurbanos de Madrid informacioacuten en tiempo real sobre el tiempo de llegada del proacuteximo autobuacutes a su parada La implantacioacuten de tarjetas de proximidad (RFID) como abono de transporte permite la identificacioacuten del servicio del sistema de trasnporte para una persona discapacitada Por ejemplo locuciones sonoras para discapacitados visuales o autobuses de plataforma baja para discapacitados con sillas de ruedas

23 Actividades

1 Anaacutelisis y disentildeo seguacuten requerimientos establecidos por el Consorcio Regional de Transportes de Madrid de soluciones teacutecnica y econoacutemicamente viables para

bull la localizacioacuten de autobuses bull las comunicaciones de datos entre los autobuses y un centro bull el desarrollo de un centro compartido bull la difusioacuten de informacioacuten a los usuarios bull la gestioacuten del traacutefico de autobuses en intercambiadores

2 Desarrollo de una prueba Piloto incluyendo el desarrollo e implantacioacuten de las soluciones disentildeadas

AG 33sivaat 12092007 125600 2227

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

33sivaat 12092007 125600 2327

24 Arquitectura fisica del Sistema

Los siguientes elementos principales intervienen en el sistemaズ Servidor principal Servidor Web de aplicaciones y de Base de Datosズ Moacutedulo de atencioacuten a dispositivos moacuteviles OBU Distpacherズ Usuarios del sistema ズ OBU (En Autobuses) ズ Paradas Los Autobuses (OBU) y las paradas se comunican con el centro de gestion por la red SMSGPRS con el moacutedulo de atencioacuten a dispositivos moacuteviles (distpacher) Los usuarios del Consorcio del sistema iTRA pueden comunicarse con el servidor principal mediante Internet Los servidores se conectan entre ellos por TCPIP Se usoacute como equipo embarcado (OBU) el OWASYS de la familia 22X (modelo OWA 22A) Se usoacute para el control de la parada la placa PI-TAI486 (de Page) basada en procesadror PowerPC y sistema operativo Linux El Servidor de Bases de Datos y de aplicaciones es un equipo que cuenta con las prestaciones y recursos adecuados para el sistema a plena capacidad suficiente memoria RAM discos duros redundantes y procesadores y placa base de uacuteltima generacioacuten con una conexioacuten a Internet (ADSL) Ademaacutes cuenta con tres dispositivos modems GSM Siemens TC-45

Fig1 AG

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

25 Entorno Tecnoloacutegico

Los moacutedulos del Centro de Gestioacuten estaacuten desarrollados sobre la plataforma Java 2 Edicioacuten Empresarial (J2EE) Se ejecuta sobre un servidor de aplicaciones compatible con J2EE JRun Las diferentes piezas de coacutedigo donde se implementa la loacutegica de negocio son componentes EJB aprovechaacutendose todas las funcionalidades de un contenedor EJB como seguridad persistencia control de transacciones etc El Moacutedulo WEB estaacute implementado sobre una arquitectura soportada sobre un framework de desarrollo de aplicaciones Web de Jakarta Apache Cocoon 21 que se basa en trasformaciones de documentos XML con paginas de estilo XSL Como IDE de desarrollo del Centro de Gestioacuten y del Distpacher se utilizoacute el entorno JBuilder 90 Como servidor de bases de datos se utiliza SQL Server gestor de bases de datos que ofrece prestaciones en cuanto a seguridad escalabilidad replicacioacuten eficiencia concurrencia etc Todas estas prestaciones se hacen imprescindibles para el tratamiento de la informacioacuten que deben realizar los moacutedulos del sistema El moacutedulo de Carga de Datos iTRADAT se desarrolloacute en C++ entorno C++Builder y se utilizoacute el componente GeoView disponible como un control OCX en la visualizacioacuten cartograacutefica de la ruta paradas como un medio auxiliar en el proceso de carga El moacutedulo de aplicaciones del sistema embarcado (OBU) se desarrolloacute en C++ en entorno Linux utilizando las libreriacuteas suministradas por OWASYS El moacutedulo de aplicaciones de la parada se desarrolloacute en C++ en entorno Linux

26 Prueba Piloto

El sistema se encuentra en pruebas en la liacutenea 626 (Las Rozas ndash Villanueva de la Cantildeada) con praacutecticamente toda la funcionalidad descrita (a falta de la creacioacuten de informes web) Esta liacutenea tiene una frecuencia de paso de aproximadamente 30 minutos y una longitud de unos 36 Km con una variacioacuten muy grande entre las distancias entre paradas (entre poco mas de 100 metros y varios kiloacutemetros)

27 Incidencias

No se han registrado auacuten incidencias en el servicio (averiacutea de autobuacutes supresioacuten de viajes u otras) ni teacutecnicas (fallo de equipos embarcados) que puedan poner en riesgo la correcta estimacioacuten de los tiempos de recorrido en casos excepcionales muchos de ellos previstos en el sistema

28 Asignacioacuten a liacutenea y ruta

Mientras soacutelo se implemente el servicio de informacioacuten iTRA en una liacutenea la asignacioacuten de autobuacutes a liacutenea es obvia Sin embargo es necesario asignar el autobuacutes a ruta (la liacutenea 626 tiene uacutenicamente dos rutas ida y vuelta pero los autobuses pueden

AG 33sivaat 12092007 125600 2427

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

iniciar el servicio en cualquiera de las dos cabeceras) (la liacutenea 567 tiene dos rutas ida y vuelta pero los autobuses pueden iniciar el servicio en cualquiera de las dos cabeceras) Se ha minimizado la necesidad de actuaciones del conductor (a quien uacutenicamente se requiere pulsar un botoacuten en caso de que se averiacutee el autobuacutes) consecuentemente la asignacioacuten de autobuacutes a ruta ha de hacerse automaacuteticamente Para ello se utilizan determinados puntos de paso que son uacutenicos para cada trayecto desde cocheras hasta cada una de las cabeceras Ademaacutes el sistema comprueba automaacuteticamente la hora a la que existe un servicio y asigna el autobuacutes al servicio a la vez que a la ruta La asignacioacuten automaacutetica de servicio y ruta funciona correctamente

29 Precisioacuten en la estimacioacuten de los tiempos

La precisioacuten en los tiempos de recorrido depende de varios factoresズ Correcta ubicacioacuten de los autobusesズ Disponibilidad de datos fiables sobre los tiempos de recorrido entre paradas ズ Factores externos que influencien los anteriores tiempos de recorrido La ubicacioacuten de los autobuses no resulta un una fuente de error relevante sin embargo auacuten no se dispone de una buena estimacioacuten de los tiempos de recorrido y se han identificado factores externos (traacutefico y variabilidad en la demanda de las paradas) que afectan de forma importante la estimacioacuten de los tiempos de recorrido Se estaacute analizando si dicha variabilidad es recurrente (por hora del diacutea y tipo de diacutea) por lo que auacuten no se puede hablar de una precisioacuten garantizada en la estimacioacuten El objetivo sigue siendo del orden de mas menos un minuto

30 Carga de datos

Se ha infravalorado el esfuerzo requerido para la obtencioacuten y carga de datos (coordenadas de las paradas y otros puntos de control distancias entre puntos tiempos de recorrido entre puntos y servicios de los autobuses fundamentalmente) que para el caso de la liacutenea 626 ha supuesto maacutes de un mes de trabajo para dos personas (se utilizan maacutes de 100 puntos) al igual que en el caso de la liacutenea 567 De hecho se habiacutea considerado conveniente realizar la prueba en dos liacuteneas (para poder probar mejor la funcionalidad de seleccioacuten automaacutetica de liacutenea y la operacioacuten con ramales) pero la necesidad de utilizar datos fiables y precisos no disponibles y el esfuerzo que requiere la obtencioacuten de estos datos ha obligado a posponer las pruebas en la segunda liacutenea (justificacioacuten si alguna parte no estaacute desarrollada en este caso ESTAacuteN MONTADOS 7 AUTOBUSES EN LA LIacuteNEA 567 DE LLORENTE Y 5 EN LA LIacuteNEA 626 DE AUTOPERIFERIA DE CARA AL SIVAAT EN LA PARTE DEL AUTOBUacuteS YA ESTAacute MONTADO EL ZUMBADOR QUE SE UTILIZARIacuteA PARA GUIAR A LOS CIEGOS Y EL PUPITRE DE CONDUCTOR QUE APARECE EN LA FOTO INDICARAacute SI HAY EN LA PARADA UN CIEGO CON EL LED VERDE O SI ES DISCAPACITADO FIacuteSICO EL LED VEDE PARPADEARAacute EL LED ROJO SE UTILIZA PARA INDICARLE LA PARADA PARDEM

AG 33sivaat 12092007 125600 2527

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

Fig2

31 Gestioacuten del traacutefico de autobuses en intercambiadores

Los intercambiadores subterraacuteneos han demostrado ser una solucioacuten viable y ventajosa en Madrid varias de estas infraestructuras estaacuten en fase de planeamiento proyecto o ejecucioacuten y seraacuten puestas en servicio en los proacuteximos antildeos Una vez disentildeado y construido la calidad la seguridad y la eficacia de un intercambiador subterraacuteneo descansan sobre su explotacioacuten Una explotacioacuten adecuada permitiraacute aprovechar al maacuteximo la capacidad del intercambiador y asegurar unos niveles de seguridad y comodidad tan altos o maacutes que los que pudieran conseguirse a cielo abierto Sin embargo a la hora de definir la explotacioacuten de un intercambiador y en especial a la hora de disentildear soluciones telemaacuteticas para llevar a cabo dicha explotacioacuten apenas existen referencias mundiales en las que apoyarse La necesidad de definir una solucioacuten de referencia para los sistemas de explotacioacuten de los futuros intercambiadores llevoacute al Consorcio Regional de Transportes a incluir en el proyecto iTRA una liacutenea de trabajo para analizar uno de los aspectos de explotacioacuten de mayor complejidad la gestioacuten del traacutefico de autobuses Dentro del proyecto iTRA el Consorcio Regional de Transportes de Madrid ha analizado la problemaacutetica de la gestioacuten del traacutefico en el Intercambiador de Moncloa con el objetivo de establecer los requerimientos de una serie de sistemas telemaacuteticos que permitan mejorar la explotacioacuten de los intercambiadores El resultado ha sido el documento ldquoSistemas de explotacioacuten requeridos en los intercambiadores de transporte dependientes del Consorcio Regional de Transportes de Madridrdquo que ya se ha empezado a utilizar para establecer el modelo de equipamiento telemaacutetico para los futuros intercambiadores de transporte de Madrid

AG 33sivaat 12092007 125600 2627

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727

32 Proacuteximos pasos

Con los resultados obtenidos hasta el momento se han identificado las siguientes necesidades y oportunidades 1 Recopilar toda la informacioacuten necesaria y analizar los siguientes aspectos

Fiabilidad del sistema (fallos teacutecnicos y nivel de incidencias en el servicio) Precisioacuten conseguida en la estimacioacuten de los tiempos de llegada Costes de comunicaciones GPRS y SMS Nivel de demanda y aceptacioacuten de los usuarios

2 Extender la prueba a la liacutenea de autobuses interurbanos 567 de mayor complejidad (posee 4 rutas posibles y un servicio acortado a determinadas horas) y prestar el servicio en ambas liacuteneas 4 Desarrollar un sistema semi-automaacutetico de recogida y anaacutelisis de datos de las liacuteneas con el fin de reducir el esfuerzo necesario para incluir una nueva liacutenea en servicio 5 Analizar la viabilidad y en su caso desarrollar un servicio de informacioacuten a los usuarios utilizando un servicio de voz interactiva destinado a aquella poblacioacuten que no sabe utilizar el servicio SMS

33 INFORMACIOacuteN Y PUBLICIDAD

El proyecto iTRA ha sido objeto de un artiacuteculo publicado en los siguientes mediosズ Traffic Technology International (marzo-abril 2005) ズ Revista iTS (nuacutemero 1) ズ Paacutegina web wwwdirectorioitscom en el apartado de ldquoExperiencias de intereacutesrdquo del Transporte Puacuteblico

AG 33sivaat 12092007 125600 2727