PLIEGO DE CONDICIONES TÉCNICAS PARA LA CONTRATACIÓN POR CONCURSO PÚBLICO DE LOS SERVICIOS NECESARIOS PARA EL DESARROLLO SOFTWARE PARA LA IMPLANTACIÓN DE LA PRIMERA FASE DE UN SISTEMA DE RECURSOS COMPARTIDOS DE INFORMACIÓN Y AYUDA A LA EXPLOTACIÓN DE AUTOBUSES INTERURBANOS DEPENDIENTES DEL CONSORCIO REGIONAL DE TRANSPORTES DE MADRID. ---------------------------------------------------------------------------------------------------------1 OBJETO DEL DOCUMENTO El objeto de este documento es establecer las condiciones de carácter técnico que han de regir la contratación de los estudios y el desarrollo software necesario para la implantación de un proyecto piloto de un sistema de recursos compartidos de ayuda a la explotación de autobuses interurbanos, basado en los antecedentes tecnológicos del proyecto i-TRA y de acuerdo con las directivas del programa IDAE (Instituto para la Diversificación y Ahorro de la Enegía) del Mº de Industria, Turismo y Comercio. 2 ANTECEDENTES Y JUSTIFICACIÓN El transporte de autobuses interurbanos representa aproximadamente el 18% de toda la demanda del transporte público de la Comunidad de Madrid, y cerca del 35% de todos los viajes-Km realizados. A pesar de su importancia, por aportar una parte significativa de la oferta de transporte de Madrid, y constituir en muchas zonas la única alternativa de transporte público disponible, existe una brecha tecnológica creciente entre este sistema de transporte y el resto de las, grandes, empresas operadoras. Esta brecha tecnológica significa, para los autobuses interurbanos, una mayor dificultad para conseguir los niveles de calidad ofrecidos por operadores que disponen de sistemas de ayuda a la explotación que les permiten monitorizar permanentemente sus servicios y detectar incidentes, mitigar los efectos de dichos incidentes, mantener informados a sus usuarios y obtener datos relevantes sobre su explotación para optimizar la planificación de sus servicios. En 2004, en el marco de las acciones que desarrolla el Consorcio Regional de Transportes de Madrid (CRTM) para la utilización de nuevas tecnologías, esta institución decide iniciar el proyecto iTRA con el objetivo principal de estudiar la viabilidad, definir, impulsar el desarrollo e implantar un sistema de información en tiempo real para los viajeros de autobuses interurbanos. A partir de los resultados obtenidos con el proyecto iTRA, el CRTM diseña una estrategia para reducir la brecha tecnológica que sufren los servicios de autobuses interurbanos y amplía los objetivos del sistema inicialmente concebido. La nueva solución iTRA incluye un Sistema de Recursos Compartidos de Ayuda a la Explotación e Información de Autobuses Interurbanos viable en un entorno de múltiples concesiones.

3 OBJETO DEL CONTRATO El objeto de este contrato es el estudio y el desarrollo software para la puesta en servicio de un proyecto piloto de un Sistema de Recursos Compartidos de Información y Ayuda a la Explotación de Autobuses Interurbanos de acuerdo con los requerimientos en el proyecto i-TRA con las funciones que se describen más adelante, incluyendo: •

•

•

•

Un centro servidor con funciones de información a los viajeros, base de datos de tiempo real, comunicación permanente con los autobuses para obtener su estado y posición, generación de informes con datos agregados de explotación para el CRTM, y funcionalidad de paradas a la demanda entre otras, según se describe en el apartado 5 CENTRO SERVIDOR. Una serie de aplicativos para el seguimiento de los autobuses, comunicación de voz, aviso de emergencia. Estas aplicaciones podrán ser instaladas en tantos puntos como decida el CTRTM, sin que exista ninguna licencia de uso que lo limite. Desarrollo software para los terminales embarcados suministrados por el CRTM. El adjudicatario desarrollará la funcionalidad necesaria en el terminal para soportar las funciones anteriores del centro servidor y las aplicaciones software, además de una función de actualización remota de software de los propios terminales embarcados. Este software podrá ser instalado en tantos terminales como decida el CTRTM, sin que exista ninguna licencia de uso que lo limite. Estudios necesarios para la definición de las líneas de transporte interurbano que, definidas por el CRTM, sean las que mejor se ajusten a las necesidades de iTRA. Estudios analíticos de datos disponibles en el CRTM (paradas, distancias, etc. ) y comprobación, y en su caso corrección, de dichos datos con medidas en campo. Establecimiento de puntos y secciones de control y planificación de la recogida de datos. Estudios y redacción completa y clara de aquellos manuales de instalación de equipos en los distintos modelos de autobuses del operador.

El sistema iTRA y su modelo de operación se fundamentan en las siguientes características: •

Compartir el sistema de comunicaciones, basado en el servicio GPRS de telefonía móvil, contratado bajo un único contrato por razones de eficacia en coste.

•

Compartir recursos humanos para la prestación de servicios comunes que se consideran imprescindibles para el éxito del sistema: gestión de las incidencias, operación y mantenimiento del centro servidor, normalización de interfaces y mantenimiento de la documentación del sistema y asistencia técnica, evaluación de la calidad del sistema y otras..

•

•

•

Centralizar las siguientes funciones principales: •

Función de información a los viajeros. Existen paradas comunes a varias empresas operadoras, por lo que esta función ha de estar necesariamente centralizada. El CRTM será el titular de todos los servicios de información a los usuarios de los autobuses interurbanos.

•

Bases de datos de tiempo real. Se centralizan por existir numerosos elementos comunes a varios operadores (cartografía, paradas, calendarios y otros datos) y con el fin de posibilitar su mantenimiento centralizado, compartiendo los recursos humanos necesarios, que a su vez serán los mismos encargados de gestionar todas las incidencias (obras, eventos especiales..) que afecten a los itinerarios, paradas u horarios.

•

Comunicación permanente de datos con los autobuses para obtener su estado y posición. Esta función se centraliza por estarlo también las bases de datos y necesitar estos datos de forma centralizada para los servicios de información a los viajeros. En la práctica, estos datos sólo serán accesibles por parte del operador correspondiente y por parte del CRTM.

Establecer un centro de gestión de la explotación en cada operador de transporte, mediante una aplicación con funciones de ayuda a la explotación, fundamentalmente: • • •

diversas funciones de seguimiento de los autobuses. comunicaciones de voz con los conductores. obtención de datos sobre la explotación.

•

El CRTM podrá distribuir esta aplicación a cualquier operador, de acuerdo con sus requisitos de explotación.

Garantizar la multiplicidad de fuentes para el equipamiento embarcado, mediante las siguientes previsiones: •

Normalizar los interfaces y la funcionalidad del equipamiento embarcado. • Proporcionar documentación y asistencia técnica a cualquier suministrador interesado en homologar su equipamiento para operar con el sistema compartido. ● Independizar el suministro del sistema central del suministro de los terminales embarcados.

4 4.1

ALCANCE Y CONTENIDO DE LOS TRABAJOS DESARROLLOS PARA LOS TERMINALES EMBARCADOS.

Uno de los objetivos del modelo iTRA es que las aplicaciones desarrolladas puedan operar en el futuro con distintos tipos de terminales embarcados; por ello, se desea separar el suministro de dichos terminales de la prestación de servicios de desarrollo del resto del sistema. Consecuentemente, el adjudicatario deberá utilizar los terminales seleccionados por el CRTM, cuya viabilidad ya ha sido probada en la mencionada experiencia iTRA de 2004. El adjudicatario deberá probar la funcionalidad e interfaces de datos de los equipos embarcados y analizar la viabilidad de normalizar dichos interfaces y funcionalidad con el fin de que pueda ser implantada en otros equipos. 4.2

CARACTERÍSTICAS DE LOS TERMINALES DISPONIBLES.

El CRTM dispone actualmente de terminales Owasys Owa22A, con las siguientes características básicas: • Sistema operativo Linux • Diferentes conectores para múltiples funciones, fácil instalación, SIM externa, conectores robustos para la alimentación, conector multifunción, antenas, switch de encendido/apagado, leds de estado. • Microprocesador 32 bits RISC ARM7 a 70 MHz con 2Mbytes de RAM y 1Mbyte Flash libre para desarrollar aplicaciones. • GSM/GPRS class B, Class 8 (4+1), dual 900/1800 • GPS Tiempos de obtención de señal: Cold Start: 45 seconds. Warm Start: 38 seconds.Hot Start: < 8 seconds.Reacquisition: 100 mseconds • SMS (Short Message Service) • Alimentación: Rango nominal: +12 - +36Vdc Rango máximo: +8 +40Vdc • Cuatro entradas digitales • Cuatro salidas digitales • Entrada del odómetro • Dos entradas analógicas • Conector de antena GSM • Conector de antena GPS • Sensor de temperatura interna • Watchdog • Puerto RS-232 • Modos de funcionamiento: Run: 70, Mhz, Slow: 35 Mhz, Deep Sleep

También estarán disponibles para la aplicación INTERLOC terminales Owasys Owa22A-ETH, con las características del Owa22A además de un puerto Ethernet y otro USB. El adjudicatario recibirá un entorno de desarrollo y la siguiente documentación: • owa2X Family Integrator’s Manual • owa2X Family Programming Reference Manual • owa2X Family Programming Guide • owa2X Family Developers Board Manual • Protocolo de comunicaciones terminal embarcado – modulo distribuidor. 4.3 •

DESARROLLOS SOBRE LOS TERMINALES DISPONIBLES FUNCIONES PRINCIPALES DE LOS TERMINALES El software que deberá ser desarrollado para estos terminales queda determinado por los requerimientos y la funcionalidad del resto del sistema, e incluye fundamentalmente la localización autónoma del autobús, identificación de paradas, y la fiabilidad para soportar dichas funciones, la gestión de las comunicaciones de datos con el módulo distribuidor del centro servidor, la obtención del estado de diversos sensores (llave de contacto, apertura de puertas, pulsadores del interfaz de conductor..) y la gestión de las llamadas de fonía/emergencia y de las solicitudes de paradas a la demanda.

● FUNCIÓN DE ACTUALIZACIÓN REMOTA DEL SOFTWARE DE LOS TERMINALES En una fase de pruebas durante la cual serán implementadas numerosas funciones es esencial contar con un sistema flexible para actualizar el software de los terminales embarcados. Para ello, se implementará un procedimiento de actualización remota de estos terminales. La actualización del software de los terminales debe realizarse con garantías de que el terminal cargará una aplicación fiable y que le permita seguir comunicándose con el servidor. La actualización del software se hará siempre que sea posible cuando el autobús esté en cocheras y haya finalizado su turno. Al recibir del centro servidor el comando de actualización remota, el terminal embarcado deberá detener todas las acciones que esté realizando la aplicación y ejecutar la función de actualización que descarga un archivo del servidor remoto mediante una conexión FTP segura. Se comprobará que la aplicación descargada coincide con la que se debe ejecutar.

Se comprobará que la versión de la aplicación descargada es diferente que la aplicación que tiene el terminal. Se deberán implementar comprobaciones para tener la certeza de que la aplicación descargada es fiable y se corresponde con la que posteriormente se desea ejecutar. Para ello se utilizará un código de cheksum y la comprobación del tamaño del archivo. En caso de cortes de comunicaciones o cualquier otra circunstancia que impida una descarga correcta, el terminal deberá ser capaz de arrancar con la versión anterior. 4.4

INTERFAZ CON EL CONDUCTOR Por razones de ergonomía y economía, es deseable que no existan interfaces de conductor redundantes en el autobús. Siempre que sea posible, es deseable que la máquina expendedora constituya un interfaz único para las funciones relacionadas con el billetaje y con la explotación. Para ello, dentro del presente contrato se deberán normalizar y documentar los interfaces de datos y la funcionalidad del equipamiento embarcado, de forma que en el futuro sea posible la integración de las máquinas expendedoras independientemente de cual sea el suministrador o fabricante de las mismas. Esta integración será realizada y probada en el marco del desarrollo de la aplicación INTERLOC descrita más adelante. No obstante, también se deberá resolver la necesidad inmediata de un interfaz con el conductor para las funciones objeto del propio contrato sin integración con una máquina expendedora, contemplando una consola con al menos los siguientes elementos: ● Pulsador para que el conductor pueda solicitar la comunicación de voz con un operador, indicador que confirme al conductor que su solicitud ha sido recibida en el centro y avisador acústico que le indique que se ha abierto la comunicación. ● Control de volumen. ● Pulsador oculto para el envío de un aviso de atraco, e indicador discreto del estado de este aviso (recibido en el centro de gestión, centro de gestión a la escucha) ● Interfaz con que le indique al conductor si debe o no atender una parada a la demanda (de forma acústica y visual). ● Otros elementos que sean necesarios para satisfacer la funcionalidad requerida al sistema. El CRTM adquirirá todo el hardware necesario, siendo el contratista responsable del diseño y montaje de la consola y su integración con el terminal embarcado.

5 •

CENTRO SERVIDOR CONFIGURACIÓN. El centro servidor estará compuesto por los siguientes módulos: •

Base de datos

Almacena toda la información necesaria para el correcto funcionamiento del sistema, datos relativos a las líneas y a los turnos, cartografía y parámetros de configuración. También se guarda información relacionada con la explotación de red de autobuses y del sistema como: las peticiones atendidas por el sistema, eventos e incidencias, información que sirve de base para generar los informes. Su diseño viene determinado por el resto de las funcionalidades del sistema. •

Módulo distribuidor.

Módulo es responsable de atender las peticiones SMS y GPRS del sistema y darles el curso correspondiente dentro de la lógica de cada aplicación y con los protocolos adecuados, según la naturaleza de la petición, así como enviar solicitudes de manera automática hacia dichos dispositivos. •

Gestor de aplicaciones.

Módulo principal del centro servidor, responsable de las siguientes funciones: • Base de datos actualizada en tiempo real sobre el estado y ubicación de los autobuses. • Información sobre la hora de llegada de los autobuses a las paradas. • Funcionalidad de Parada a la demanda. • Generador de informes de explotación. • Servicios para las aplicaciones descritas en el apartado 9 APLICACIONES •

Simuladores para pruebas • Simulador de solicitudes de parada a la demanda • Simulador de solicitudes SMS de información sobre la próxima llegada del autobús.

6

FUNCIONALIDAD DE PARADA A LA DEMANDA.

Una parada a la demanda sólo es atendida por un autobús si alguien lo solicita. Para ello, la parada debe disponer de un medio para que los usuarios puedan solicitar un autobús y dicha solicitud sea transmitida al centro. El centro servidor debe determinar cual es el autobús más adecuado para atender dicha solicitud, y comunicar la necesidad de atender dicha parada al conductor de dicho autobús, así como enviar una confirmación al equipamiento en la parada, indicando el tiempo estimado de espera. El centro servidor realiza un seguimiento del autobús hasta que llega a la parada y notifica cualquier incidencia al equipamiento de la parada, incluyendo retrasos o adelantos. El adjudicatario deberá implementar la funcionalidad de atención de paradas a la demanda , que será probada en una parada equipada por el CRTM. La parada equipada servirá para realizar pruebas de la funcionalidad y, en su caso, depurar el software del centro y de la parada, establecer nuevos puntos de control en la base de datos, y en general cualquier otra tarea necesaria en relación con el desarrollo de software y actualización de la base de datos hasta poner en marcha la funcionalidad de parada a la demanda en dicha parada. 6.1

DESCRIPCIÓN DE LA FUNCIONALIDAD DE PARADAS A LA DEMANDA

Determinadas paradas (paradas PBD) sólo serán atendidas por el autobús si alguien lo solicita. Para ello, la parada dispone de un pulsador por cada ruta/itinerario que incluya a dicha parada. Cuando uno de estos pulsadores es pulsado, se envía un mensaje SMS al centro servidor (CS) conteniendo el código de parada y ruta correspondiente. En el CS se activa una solicitud para esa parada para la RUTA o RUTAS solicitadas. El CS podrá devolver alguna de las siguientes respuestas: ● Respuesta 1: indica el tiempo estimado de llegada del autobús solicitado. El terminal de la PBD puede utilizar esta información para mostrarla en una pantalla en la parada o tan sólo como confirmación de que el servidor ha recibido y procesado la solicitud. En este último caso, el terminal de la PBD debe activar una indicación luminosa en el botón de la ruta correspondiente para indicar a los usuarios que la parada será atendida (de esta forma, si llega un nuevo usuario a la parada, no tendría que volver a solicitar el servicio). Otros mensajes que pueden ser enviados por el CS a la PBD mientras existan solicitudes activas: • Una vez el autobús solicitado haya pasado por la PBD, el CS enviará a la PBD un mensaje indicando qué solicitudes siguen

•

•

activas para esa parada; es decir, para qué rutas será atendida la parada. (El terminal de la PBD deberá entonces apagar los indicadores correspondientes). Si existen alteraciones del servicio que afectan el tiempo de llegada del autobús solicitado, el CS actualizará el tiempo estimado de llegada para la ruta o rutas solicitadas. Mensaje de estado indicando algún fallo en el sistema.

● Respuesta 2: Mensaje de estado indicando algún fallo en el sistema Además de los mensajes de solicitud, el terminal en la PBD podrá realizar dos tipos de consulta al CS en cualquier momento: ● Consulta de estado (la respuesta será un mensaje de estado). ● Consulta del tiempo estimado de llegada del siguiente autobús de cada ruta (la respuesta será el tiempo estimado de llegada para la ruta o rutas solicitadas). En caso de fallo en las comunicaciones, o de cualquier otra eventualidad, el CS dará orden de atender la parada a todos los autobuses, y el equipamiento de la parada activará los indicadores luminosos de todas las rutas. 7

INFORMES •

El objetivo de esta funcionalidad es utilizar la información almacenada en el registro histórico para producir informes de explotación de utilidad para el CRTM. El adjudicatario deberá analizar, con los responsables que determine el CRTM, los informes de utilidad para las distintas áreas de este Organismo. Se incluirán los siguientes, como mínimo:

•

Informe de solicitudes de información sobre la llegada del próximo autobús, comparando la información enviada a los usuarios con las horas de paso reales.

•

Informe sobre solicitudes de parada a la demanda: •

Evaluación del servicio (peticiones no atendidas y pasos por parada sin petición).

•

Uso del servicio. Ahorro de Km.

•

Informe sobre tiempos de recorrido de una línea, por expedición y día, por franja horaria y por intervalos de tiempo definidos.

•

Informe de horas de salida de cabecera, por expedición y día e informe mensual de puntualidad.

8 8.1

•

Informe de detención en paradas, mostrando un histograma del número de detenciones en cada parada durante un mes, filtrando por tipo de día (por ejemplo sólo laborables) y por franja horaria.

•

Informe de tiempos de espera en cabeceras.

•

Informe de tiempos de utilización de los autobuses.

OTRAS FUNCIONES DEPENDIENTES DEL CENTRO SERVIDOR ACTUALIZACIÓN DEL SOFTWARE DE LOS TERMINALES DEL CRTM

Se desea poder actualizar el software de los terminales embarcados desde el servidor. La carga en el servidor de una nueva versión de software para los terminales deberá ser realizada vía página web. Una vez el servidor disponga de una nueva versión de software para los terminales, deberá gestionar su actualización. La actualización debe ser realizada en momentos en los que el autobús no se encuentra prestando servicio en línea. El servidor deberá mantener el software de los terminales, con un registro de versión que permita a éstos comprobar si la versión que poseen es anterior o posterior a la disponible en el terminal, y en su caso, actualizarla. El servidor recibirá confirmación del éxito de la actualización y registrará la versión de software cargada en el Terminal. Se deberá garantizar que el medio de transmisión de las actualizaciones es seguro. 8.2

OPERACIÓN CON TERMINAL AVERIADO

El oferente deberá proponer los modos de operación en modo degradado que implementará para la funcionalidad de información a los viajeros y de atención de paradas bajo demanda para el caso de fallo de un terminal de un autobús, utilización de un autobús sin equipar y fallo de comunicaciones. 9

APLICACIONES.

Las aplicaciones son módulos cliente del centro servidor, recibiendo de éste en tiempo real el estado y ubicación de los autobuses. Se deberán desarrollar las siguientes aplicaciones: ● Gestión de emergencias: comunicación de avisos de emergencia desde los autobuses con escucha de ambiente y localización permanente. ● Aplicación de información en paradas accesible para Especialmente dirigida a personas con movilidad reducida.

todos.

● Página web de información a los usuarios ● Aplicación interloc: terminal embarcado integrado expendedora y transmisión de datos vía WiFi.

con

máquina

10 GESTIÓN DE EMERGENCIAS. El propósito de esta funcionalidad es mejorar la seguridad de los conductores, y en especial de aquellos que operan líneas nocturnas. Los autobuses serán equipados con un pisón oculto que el conductor podrá activar fácilmente y sin equivocación para indicar una emergencia que no pueda comunicar de otra forma (atraco..) El terminal embarcado gestionará la activación de este pisón, enviando un mensaje al centro de control que se determine, pasando a enviar su localización cada 20 segundos u otro período inferior configurable. En el centro de gestión se recibirá este aviso mostrándose en color rojo parpadeante en una pantalla de gestión de comunicaciones, con una indicación acústica que no se detendrá hasta que el operador confirme el aviso. La confirmación del aviso resultará en el envío de una orden de paso a modo de escucha en el terminal embarcado, que permitirá al operador en el centro escuchar lo que sucede dentro del autobús. El conductor recibirá una indicación discreta de que su aviso ha llegado al centro de gestión. Un icono representará el autobús en una pantalla del centro, indicando su estado y su posición permanentemente actualizada. Se desarrollará un interfaz de intercambio de datos para permitir que estos datos sean enviados a un centro externo (como el 1-1-2). El evento será registrado indicando la fecha y hora de la llegada de la solicitud y de su atención por parte del operador, datos identificativos del autobús y su posición. 11 APLICACIÓN DE INFORMACIÓN EN PARADAS ACCESIBLE PARA TODOS Y ESPECIALMENTE PARA PERSONAS CON MOVILIDAD REDUCIDA El adjudicatario deberá preparar el sistema para soportar la funcionalidad requerida por el proyecto de información en paradas accesible para todos llevado a cabo por el CRTM. 11.1 PROYECTO DE INFORMACIÓN EN PARADAS ACCESIBLE PARA TODOS Y ESPECIALMENTE PARA PERSONAS CON MOVILIDAD REDUCIDA Este proyecto pretende ofrecer información precisa y en tiempo real a los viajeros en las paradas de autobuses dando una especial atención a las personas con discapacidad ó deficiencia. Al llegar a una de estas paradas, denominadas paradas SIVAAT, el usuario del transporte público dispondrá de información de horarios a través de un panel informativo luminoso. Habrá también un módulo con altavoz y teclado numérico reservados para personas discapacitadas. Además, seguirán existiendo las hojas de horarios editadas por el CRTM y accesibles en los postes y marquesinas.

El equipo instalado en las paradas SIVAAT dispone de un sistema de detección para activar automáticamente una ayuda adaptada al tipo de discapacidad del usuario. Esta identificación se efectúa localizando una secuencia especial en una tarjeta de proximidad suministrada por el CRTM. Esta tarjeta llevará, previa autorización del interesado, información sobre el tipo de ayuda a activar. El sistema ofrece a los usuarios discapacitados la misma información que cualquier otro usuario, personalizándola en función de los parámetros almacenados en la tarjeta. Como ejemplo, podemos citar los siguientes casos: •

el usuario con deficiencia visual podrá recibir información acústica sobre horarios ó tiempo que falta para el próximo autobús de una línea determinada,

•

el usuario con discapacidad física podrá conocer la disponibilidad y horarios de vehículos adaptados,

•

las personas con discapacidad acústica dispondrán información a través de los mismos dispositivos que el público en general (paneles informativos y carteles).

Además el sistema facilitará el envío de un aviso al conductor para advertirle de la presencia de un discapacitado en una parada determinada. De esta forma, el conductor puede prever la utilización de la plataforma parando más cerca de la acera y evitar que una persona con discapacidad visual se equivoque de vehículo. Por lo tanto, en cada parada SIVAAT (Sistema de Información al Viajero de Autobús Accesible para Todos), los usuarios de la red de transporte dispondrán de: •

Información visual ó acústica sobre la llegada del próximo vehículo,

•

Información visual ó acústica sobre el horario de una línea,

•

Información acústica sobre vehículos adaptados con plataforma,

La información acústica se generará a través de un módulo software con voz sintetizada de alta calidad y un nivel de inteligibilidad óptimo. Para evitar molestias innecesarias a los vecinos cercanos, el dispositivo acústico será localizado (similar a una interfonía) y sólo se activa cuando se detecta una tarjeta parametrizada en ese sentido, o por cualquier otro modo que determine el CRTM. El equipamiento de la parada irá dotado con un panel informativo donde se indica de forma cíclica el tiempo de llegada del próximo autobús. El Terminal de conductor deberá disponer de un indicador que le advierta sobre la existencia de una persona con necesidades especiales en la parada.

11.2 TAREAS A REALIZAR POR EL ADJUDICATARIO El adjudicatario implementará las funciones necesarias, elaborará la documentación requerida por el CRTM, prestará el soporte técnico necesario, dará la formación precisa y participará en las pruebas, en su caso realizando las correcciones o modificaciones de su parte que el CRTM considere necesarias para el correcto funcionamiento del sistema. Entre los trabajos del adjudicatario se incluyen: ● Definir el interfaz GPRS requerido e implementarlo en el terminal embarcado y en el resto de los módulos del sistema. ● Implementar un interfaz en el terminal embarcado para la conexión del avisador acústico. ● Implementar la funcionalidad requerida añadida a PARDEM (Parada a la demanda) en la lógica del servidor para la gestión de las nuevas solicitudes con aviso de que hay un invidente en la parada SIVAAT. ● Implementar la funcionalidad requerida en el terminal embarcado: Aviso al conductor, activación de avisador acústico al llegar a la parada, finalizar aviso al cerrar las puertas. ● Participación en la prueba evaluando el funcionamiento de iTRA con la nueva funcionalidad y, en su caso, realizando correcciones. 12 PÁGINA WEB DE INFORMACIÓN A LOS USUARIOS Esta aplicación está orientada a ofrecer información a los usuarios de autobuses lanzadera que operan en polígonos industriales. Los usuarios podrán conocer la hora de llegada del próximo autobús a una parada determinada solicitándolo mediante un mensaje SMS o consultándolo en una página web. La página web permitirá seleccionar la línea, el itinerario y la parada de interés, y mostrará el tiempo de llegada del próximo autobús en llegar a dicha parada. Este tiempo será permanentemente actualizado. 13 APLICACIÓN “INTERLOC” •

Los nuevos Intercambiadores subterráneos estarán dotados de un avanzado sistema de gestión de tráfico que requiere la localización precisa y permanente de los autobuses, así como el conocimiento de su estado. Puesto que los receptores GPS no tienen cobertura dentro del Intercambiador, es necesario implantar un sistema de localización específico, que funcionará de forma independiente a los SAE de los autobuses. Sin embargo, es necesario que exista una comunicación entre ambos sistemas.

•

•

El CRTM está llevando a cabo un proyecto en el Intercambiador de Av. de América en el que se pretende probar la idoneidad de un sistema de localización basado en WiFi para satisfacer los requerimientos del sistema de gestión de tráfico del Intercambiador, incluyendo la comunicación con un SAE externo que notifique al Intercambiador el estado de los autobuses. En el marco de esta actuación, el adjudicatario deberá desarrollar la siguiente funcionalidad:

•

Implementación en el terminal embarcado del interfaz requerido para el intercambio de datos con la máquina expendedora MAEXBIC M3000 y extracción de datos de la trama recibida.

•

Transmisión vía Wifi (utilizando una red de nodos de acceso Wifi instalada en el Intercambiador) de la siguiente información: •

Número de conductor.

•

Número de autobús.

•

Número de parada actual

•

Asignación de línea.

•

Número de viaje.

•

Hora de salida

•

Identificación del servicio

•

Apertura de puertas

•

Estado de la llave de contacto (motor parado/encendido)

•

Número de billetes vendidos.

•

Aplicación servidor para la recepción de esta información sobre UDP y su registro en el Intercambiador.

•

Los mismos autobuses estarán equipado con un tag Wi-fi y serán localizados dentro del intercambiador mediante un sistema de localización Wifi instalado por el CRTM. El objeto de la actuación es poner de manifiesto que es posible mantener localizados los autobuses dentro del Intercambiador, a la vez que perfectamente identificados y conocidos sus estados en tiempo real.

•

14 LÍNEAS Y AUTOBUSES Las líneas dónde se aplicarán las innovaciones tecnológicas objeto de los trabajos son las siguientes:

Nº de Recorrido línea

Empresa concesionaria

Funcionalidad

• Monitorización

gráfica autobuses en línea

567

Villaviciosa de Odón Llorente Majadahonda

• Información próxima llegada vía SMS

• Parada PARDEM • Parada SIVAAT • Informes CRTM • Monitorización

gráfica autobuses en línea

626

Las Rozas Villanueva de Cañada

– la Autoperiferia

Madrid(Moncloa)N901 PozueloMajadahonda-Madrid Madrid(Moncloa)N902 Pozuelo Madrid(Moncloa)N906 Majadahonda-Madrid

Llorente

Llorente

próxima

llegada

SMS

• Parada PARDEM • Parada SIVAAT • Informes CRTM • Gestión Emergencias • Información próxima

llegada

• Gestión Emergencias • Información próxima

llegada

SMS Llorente

• Gestión Emergencias • Información próxima

llegada

SMS

Getafe(centro)-Pol Ind. Los Ángeles-Pol. Busursa Ind. Los Olivos

Pi2

Getafe(centro)-Pol Ind. Las Mezquitas/ Busursa SanMarcos/El Lomo Madrid-Guadalajara

• Información

de

SMS

Pi1

221

de

Continental

• Información

próxima

llegada

SMS

• Diversificación

de la información próxima llegada sobre web y monitor informativo general. Pruebas de localización y posicionamiento en el interior del Intercambiador de Av. de América

15 INSTALACIÓN El adjudicatario será responsable de la instalación del equipamiento embarcado, incluidos los terminales del CRTM que serán utilizados para la prueba. Los elementos disponibles en el CRTM para ello son los siguientes: • • • • • •

Terminales Owasys Owa22A y Owa22A-ETH Antenas GPS y GSM Micrófonos Altavoces Tarjetas WiFi Pisones ocultos de alarma

La responsabilidad del adjudicatario incluye: •

El suministro de otros elementos que sean necesarios para la instalación en los autobuses, incluyendo: •

Conversor DC/DC de 24 a 12V y 5A

•

Interfaz de conductor.

•

Tarjeta de interconexión de elementos.

•

Cableado, conectores, soportes.

•

Tarjetas SIM.

•

El diseño de la instalación, analizando cada uno de los modelos de autobuses para localizar las señales necesarias (odómetro, alimentaciones, apertura de puertas y llave de contacto), determinar la ubicación de los elementos a instalar, disponer los pasos de cable y elaborar documentación y guía para la instalación.

•

Instalación de al menos un prototipo de cada línea, formando a la vez a un responsable de la empresa operadora. Este prototipo será aprobado por el CRTM y la empresa operadora antes de continuar la instalación en el resto de los autobuses.

16 PUESTA EN MARCHA DE LÍNEAS El adjudicatario será responsable de las siguientes tareas de puesta en servicio de cada una de las líneas: •

Estudio de las características de la explotación de la línea: horarios, asignación de turnos, autobuses, tipos de días, tramos horarios, calendarios, servicios reducidos, ramales, puntos de cochera, cambios de línea, incidencias contempladas por la empresa operadora (accidente, avería, falta de conductor...) y actuaciones excepcionales (sustituciones, refuerzos, perdida total o parcial de expedición..), usos de los conductores y otros aspectos de la operación relevantes para la carga de las bases de datos así como aspectos que pudieran condicionar la funcionalidad del sistema.

•

Análisis de datos disponibles en el CRTM (paradas, distancias, planos) y comprobación, y en su caso corrección, de dichos datos con medidas en campo. Establecimiento de puntos y secciones de control y planificación de la recogida de datos.

•

Carga de datos, incluyendo la grabación de todos los datos correspondientes a los cuadros de servicio de invierno de 2006.

•

Obtención de tiempos de recorrido (para cada tramo horario, tipo de día y período anual). El adjudicatario deberá definir tramos horarios adecuados para garantizar la mejor estimación de los tiempos de recorrido.

•

Análisis de las variaciones sufridas en los tiempos de recorrido para, en su caso, realizar mejoras en los algoritmos de estimación de llegada a la siguiente parada.

•

Pruebas, y en su caso, correcciones.

17 MANTENIMIENTO El adjudicatario deberá asumir los siguientes costes y servicios del sistema: • Comunicaciones GPRS y SMS. • Mantenimiento del equipamiento embarcado adquirido por el CRTM. • Control de calidad del sistema.

17.1 MANTENIMIENTO DEL EQUIPAMIENTO EMBARCADO Las líneas objeto de dotación tecnológica estarán equipadas por el CRTM con los elementos necesarios. El adjudicatario será responsable del mantenimiento de dicho equipamiento y realizará las siguientes tareas: • Detección y diagnosis de equipos averiados. • Sustitución por equipo de repuesto. • Envío al fabricante y reparación • Reposición del equipo reparado en el stock de repuestos en su caso • Gestión de inventario, Deberá mantenerse un inventario informatizado de todos los elementos adquiridos, fabricados, instalados y en stock, su ubicación, estado e histórico de actuaciones sobre dichos elementos. 18 CALENDARIO DE LOS TRABAJOS El oferente confeccionará y entregará en su oferta un calendario de los trabajos a realizar. 19 PRELIMINARES El adjudicatario deberá estudiar y conocer las aplicaciones tecnológicas PARDEM e I-TRA para lo cual el CRTM facilitará toda la información disponible.