CONTRATACIÓN DEL SISTEMA DE BILLETAJE SIN CONTACTO EN EL ENTORNO DE TENERIFE y DEL NUEVO SAE PARA TITSA

	Sistema de Billetaje de Tenerife y	Código:TITSA-BIL-PG
	nuevo SAE TITSA	Edición: 2.0 Fecha: 27/2/2014
	Pliego de Prescripciones Técnicas
		Página: Página 9 de 278

1. OBJETO ‌

El objeto de este pliego es la definición de los suministros a realizar para la implementación de un sistema de Billetaje sin contacto en el entorno de Tenerife, así como el suministro e implementación de un nuevo SAE para TITSA.

En primer lugar se describen los antecedentes que dan lugar a la elaboración de este pliego y se describe a grandes rasgos el sistema actual, basado en tecnología xx xxxxx magnética, para TITSA (Transportes Interurbanos de Tenerife, S.A.) y MTSA (Metropolitano de Tenerife, S.A.).

Posteriormente se define el alcance del proyecto y la descripción de los suministros y adaptaciones a realizar, para finalmente indicar las condiciones de los planes de calidad, normativa aplicable, condiciones de mantenimiento del sistema, presupuesto y condiciones económicas y otros y anexos.

2. ANTECEDENTES ‌

2.1. ESTUDIOS INICIALES ‌

La consecución de un modelo de movilidad y transporte público adaptado a las necesidades que requiere una sociedad avanzada exige, entre otros requisitos, la mayor integración posible entre los distintos modos y operadores.

Un elemento clave para alcanzar esta integración reside en la existencia de un sistema tarifario que permita al usuario la utilización de los distintos medios de transporte sin necesidad de adquirir títulos diferentes. La experiencia nacional e internacional pone de manifiesto que este tipo de iniciativas suponen no solo una mayor calidad de servicio para el usuario del servicio de transporte, sino, adicionalmente, un mayor uso en general de los medios de transporte público integrados.

A este respecto, TITSA y MTSA han decidido la puesta en marcha de un Sistema de Billetaje integrado y han impulsado un proceso de licitación, del cual es objeto este pliego, para la Contratación del Sistema de Billetaje Sin contacto en el entorno de Tenerife para TITSA y MTSA, así como el suministro e implementación del Sistema de Ayuda a la Explotación (SAE) para TITSA.

2.2. SISTEMA TARIFARIO ACTUAL. OPERADORES, ZONAS Y TÍTULOS ‌

Todas las líneas de tranvía de MTSA pertenecen al Área Metropolitana, por lo cual en MTSA se aplica una tarifa plana para todos los trayectos.

En cuanto a TITSA, existen varios grupos de líneas, que son las líneas urbanas de algunos municipios, y otras que son líneas interurbanas.

Las líneas urbanas tienen tarifa plana.

En las líneas interurbanas, el tarifario TITSA consiste en tarifas kilométricas variables, es decir que el precio del trayecto depende de la distancia recorrida. Existe un “mínimo de percepción”, que es el precio del trayecto por cualquier distancia inferior a 10 km. Por encima de 10 km existe un coeficiente multiplicador que permite calcular un precio proporcional a la distancia.

El concepto de zona tarifaria sólo se aplica al Área Metropolitana (AM), que es la lista de las líneas de guaguas y de tranvía que pertenecen a los municipios de Santa Xxxx, La Laguna, Tegueste y El Rosario. En el Área Metropolitana, las tarifas de TITSA y de MTSA son constantes e iguales al “mínimo de percepción” de TITSA en interurbano.

Para las tarifas variables en función de la distancia los niveles de precios se definen con base en las zonas tarifarias, que son delimitadas por paradas tarifarias.

Para definir una parada tarifaria se entenderá mejor explicando previamente el concepto xx xxxxxx real, que será aquella que representa de manera unívoca un punto geográfico que está situado dentro del recorrido de una línea de transportes. Por lo tanto una parada tarifaria será un grupo de esas paradas geográficas. Esto permite que todos los clientes que hacen un trayecto interurbano entre dos municipios, paguen el mismo precio, independientemente de si bajan en la parada que está a la entrada o a la salida del mismo municipio. En la situación actual TITSA mantiene el concepto xx xxxxxx tarifaria hasta que logre migrar todos sus sistemas de manera que soporten la identificación de manera automática de las paradas geográficas. Por ello de manera transitoria TITSA maneja los dos conceptos tanto lo xx xxxxxx real como lo xx xxxxxx tarifaria. Es el SAE embarcado de TITSA que da al sistema de billetaje embarcado el xxxxx xx xxxxxx. Si el SAE está averiado, lo da el conductor.

2.2.1. Operadores ‌

Actualmente están integrados en la red de billetaje de Tenerife tres operadores:

• TITSA - Transportes Interurbanos de Tenerife, S.A.U.

• TGLE - Transportes por Guaguas La Esperanza – Guaguas regionales. El sistema de billetaje de TGLE es gestionado por XXXXX, por lo cual en el resto del documento al hacer referencia a “TITSA”, se debe entender “TITSA y TGLE”

• MTSA – (tranvía) Metropolitano de Tenerife, S.A.

2.2.2. Soportes de Billetaje ‌

El sistema de billetaje actual está basado principalmente en soportes magnéticos, interoperables entre los diferentes transportes con guagua y el Metro.

Los billetes sencillos que son vendidos a bordo de las guaguas son emitidos en papel y son válidos para un único viaje, o para una ida y vuelta.

Los soportes magnéticos son de validación obligatoria en las canceladoras instaladas a bordo de las guaguas y de los tranvías.

A continuación se incluye un resumen de los títulos existentes en soporte xx xxxxx magnética.

2.2.3. Resumen de títulos de transporte existentes en Banda Magnética ‌

A continuación se incluye un resumen de los títulos xx Xxxxx Magnética en vigor actualmente en TITSA y MTSA.

2.2.3.1. Títulos interoperables-no interoperables

Son títulos interoperables aquellos que pueden ser usados en diferentes operadores, y no interoperables aquellos que pueden ser usados en un solo operador.

En la actualidad existen unos 50 títulos en funcionamiento, de los cuales aproximadamente una tercera parte son interoperables.

2.2.3.2. Tipo de título

Define la característica general de funcionamiento del título, pudiendo ser esta:

o Tiempo: son títulos que tienen una limitación de tiempo para su uso. Aunque existen títulos mixtos donde existe una limitación de uso del título en el periodo de tiempo para el que es válido, en la actualidad los títulos temporales no tienen limitación de uso, sólo limitación temporal.

Los títulos disponibles permiten definir un periodo de validez en función de:

• La primera validación (título “deslizante”). Por ejemplo, si se trata de un título de validez temporal 3 horas, será válido durante las 3 horas posteriores a la primera validación.

• Fecha fija: válido hasta una fecha determinada grabada como fecha caducidad en el bono.

• Por calendario: válido en días, semanas o meses concretos del año (por ejemplo 2 xx xxxxx aniversario de la inauguración, meses xx xxxxxx, etc.).

Los bonos mensuales son vendidos para el Área Metropolitana, que es la lista de las líneas de guaguas y de tranvía que pertenecen a los municipios de Santa Xxxx, La Laguna, Tegueste y El Rosario. Durante el periodo mensual definido en el bono, el pasajero puede viajar sin limitaciones en el Área Metropolitana.

Los bonos mensuales son de validación obligatoria.

Por otro lado, existen bonos gratuitos para los perfiles de clientes subvencionados (Mayor xxx Xxxxxxx, Discapacitado xxx Xxxxxxx, Mayor de Santa Xxxx, etc.…), en soporte magnético, de obligatoria cancelación.

o Dinero: Los bonos dinero se venden pre-cargados con un valor inicial en euros. Cuando se presentan en las canceladoras, éstas hacen un débito del valor correspondiente al tarifario aplicable para el trayecto.

Los bonos dinero pueden ser de utilización individual o para múltiples pasajeros que compartirán el mismo trayecto. Para utilizar un bono dinero cargado en una tarjeta magnética, como billete múltiplo, se presenta en las canceladoras repetidas veces para cada uno de los pasajeros. Debido a restricciones técnicas, no más de 9 personas pueden viajar con un mismo bono dinero.

El precio cobrado por cancelación de un bono dinero siempre es inferior a la tarifa plena del mismo viaje.

Debido a restricciones técnicas, un bono dinero tiene por defecto una fecha de fin de validez de 1 año desde la primera cancelación. Si vence esta fecha, se sustituye gratuitamente este bono para el cliente.

Actualmente los bonos dinero disponibles a la venta son bonos de un valor en euros inicial (se permiten varios importes según el título), pudiendo tener una tarifa subvencionada en la cancelación.

o Viajes: Son bonos cargados con una determinada cantidad de viajes.

En MTSA existe el Bono viaje único o ida-y-vuelta, cargados en soportes magnéticos.

2.2.3.3. Perfiles con descuento

Según el perfil del usuario se aplica la tarifa general o la tarifa con descuento si el usuario tiene un perfil con este derecho. A continuación se incluyen algunos ejemplos:

• Usuarios sin descuentos.

• Jóvenes (menores de 4 años) viajan gratis.

• Estudiantes de la Universidad de La Laguna.

• Jubilados TITSA.

• Personal TITSA. Aclarar qué título tienen.

• VIP TITSA.

• VIP MTSA.

• Personal MTSA.

• Participante a Congresos.

• Familias Numerosas.

• Mayores xxx Xxxxxxx (recursos < R).

• Discapacitados xxx Xxxxxxx (recursos < R).

• Mayores del Ayuntamiento de Santa Xxxx (recursos < R).

• Bonos para Institutos IES.

2.2.3.4. Propietario del título

El propietario del título es el responsable último de la gestión del título (de su funcionamiento, de la actuación a efectuar si existen problemas para su uso, etc.).

En la actualidad existen títulos propiedad de TITSA y de MTSA.

2.2.3.5. Multioperador

El título tiene la característica de multioperador si puede ser utilizado en más de un operador de transporte (títulos interoperables).

2.2.3.6. Multipersonal

El título tiene la característica de multipersonal si puede ser validado por un grupo de más de una persona que viajan juntas. Por limitaciones técnicas en la banda magnética este grupo no puede superar los 9 viajeros.

2.2.3.7. Multimodal

El título tiene la característica de multimodal si puede ser utilizado en diferentes modos de transporte (es el caso de los títulos interoperables que pueden ser usados en las guaguas y en el tranvía).

2.2.3.8. Antipassback

Se entiende antipassback como el tiempo definido entre la primera validación y la segunda en un mismo punto. Tienen antipassback los títulos personales para evitar que varias personas viajen juntas con un título de tarifa subvencionada.

2.2.3.9. Requiere acreditación personal

Requieren acreditación (carné de jubilado, de estudiante, etc…) personal los títulos personales que tienen subvención en su tarifa.

2.2.3.10. Tarifa

Los títulos monedero tienen tarifa de validación que puede variar entre tarifa plana (entorno metropolitano), tarifa origen destino (interurbano) o establecimiento de tarifas mínimas.

Para los bonos temporales o de viajes no existe una tarifa de validación a descontar (se descuentan unidades de viaje).

2.2.3.11. Saldo de viajes

Para aquellos títulos del tipo “viajes”, se vende con su saldo de viajes inicial, quedando impreso el saldo restante tras cada validación.

2.2.3.12. Validez temporal

Aplica para títulos que caducan tras un periodo de N unidades temporales, pudiendo también tener viajes o saldo.

2.2.3.13. Renovación título

Existen títulos (especialmente algunos bonos subvencionados) que tienen derecho a renovación según los periodos a los que tiene derecho a subvención el usuario de acuerdo a su perfil.

2.2.3.14. Monedero

El título puede tener o no monedero de dinero.

2.2.4. Traspaso xxx xxxx x

A excepción de los bonos temporales, las cancelaciones de los bonos magnéticos siempre se imprimen en la cara térmica xxx xxxx. Ocurre muy frecuentemente que un mismo bono sea usado para más de 18 cancelaciones, que es el espacio disponible en un bono. En este caso, el sistema de billetaje permite entregar al cliente un bono magnético nuevo, virgen de cancelaciones, reconduciendo todas las propiedades de tipo xx xxxx, saldo disponible, derecho a transbordo, acumuladas en el soporte anterior, sin coste para el cliente. Esta operación se puede realizar en las canceladoras de TITSA, en las máquinas expendedoras de MTSA, y en los puestos de venta de MTSA.

2.2.5. Canje xxx xxxx x

En MTSA el cliente tiene la posibilidad de canjear un bono dinero de cualquier importe. Esto permite a un cliente comprar un bono del mismo tipo, aprovechando el saldo restante, y pagando sólo la diferencia. Esta operación se puede realizar en los puestos de venta y en las expendedoras automáticas de MTSA.

El cliente también puede ir a las agencias comerciales o taquillas de MTSA y TITSA con uno o varios bonos dinero con saldo residual. En este caso se reúnen los saldos restantes de los bonos y se propone al cliente comprar un nuevo bono, sólo pagando la diferencia o se emite un bono nuevo con la suma de los saldos.

2.2.6. Pago del complemento al conductor de la guagua ‌

En caso de que el saldo restante en el bono dinero sea inferior al precio del trayecto, el cliente puede pagar la diferencia al conductor de la guagua para realizar este viaje.

En el tranvía esto no es posible, por lo cual la cancelación no es válida y el cliente debe canjear su bono en la red de ventas.

2.2.7. Transbordos ‌

Para las utilizaciones xx xxxx dinero el pasajero puede hacer transbordos entre diferentes líneas del mismo operador o entre diferentes operadores sean de guaguas o de tranvía.

En caso de transbordo, el valor a cobrar al pasajero depende del valor pagado en la anterior utilización, del valor a pagar en el trayecto actual, y de un tiempo límite transcurrido desde la primera cancelación, parametrizable por cada línea.

Los transbordos se aplican a bonos dinero y bonos de viajes. Funcionan también en caso de cancelaciones múltiples con un bono dinero/ viajes (uso de un mismo bono por varios pasajeros). Para los billetes de un viaje vendidos a bordo no hay transbordos.

2.2.8. Puntos de venta ‌

Según el título, puede ser vendido en los diferentes puntos de venta actuales: expendedoras automáticas, oficinas comerciales MTSA y TITSA, y otros puntos especiales para títulos subvencionados.

2.3. MTSA ‌

2.3.1. Arquitectura del Sistema de MTSA ‌

Figura 1 - Arquitectura actual de MTSA

Además de los elementos y comunicaciones representados en el gráfico anterior, MTSA dispone del sistema VIA-MOVIL para validación con un terminal móvil usando códigos QR.

El Puesto Central de Gestión de Billetaje (PCGB) es la parte del sistema que concentra los datos relacionados con billetaje generados por la explotación de MTSA.

El PCGB gestiona toda la red de ventas de MTSA (expendedoras y Puntos de Venta); pero no hace lo propio con los equipos embarcados (Concentrador Embarcado y Canceladoras) ya que no hay interfaz entre ellos. Mediante una carga diaria, el Concentrador Embarcado de cada vehículo sí envía al PCGB por FTP (File Transfer Protocol) las cancelaciones realizadas. De este modo la información embarcada más importante se concentra en el PCGB permitiendo extraer informes de cancelaciones.

Funcionalmente el PCGB se divide en módulos a los que los usuarios acceden en función de su perfil. Los módulos se enumeran a continuación:

o Gestión de Equipos – estado de equipos, comunicación con los equipos y envío de comandos (sólo red de ventas).

o Gestión de la Explotación - alarmas, niveles de consumibles, estadísticas de producción.

o Gestión del Negocio - importación de matrices de distancias, estadística de la explotación y de cancelaciones.

o Gestión de Fraude - gestión de multas, algunas búsquedas sobre cancelaciones, lista negra.

o Gestión de Clientes - gestión de fiscalizaciones efectuadas por los agentes, búsqueda de tarjetas, gestión de notas de crédito de las expendedoras, etc.

Las expendedoras generan Notas de Crédito cuando la operación de compra no pudo completarse y ha sido imposible emitir el título o devolver el dinero al cliente. Este documento sirve al cliente para recuperar su dinero al presentarlo en cualquiera de las Oficinas Comerciales de MTSA. La Oficina Comercial comprueba contra el PCGB que la numeración de la Nota de Crédito es correcta y que no ha sido previamente compensada en otra Oficina Comercial y, en ese caso, se procede a su compensación.

En las Oficinas Comerciales también se permite al cliente pagar la sanción impuesta por los Agentes de Fiscalización de MTSA. Esta operación se registra como una operación más de venta y se inserta en el PCGB registrando la numeración de la misma.

o Gestión de la red de Ventas - visualización de datos de venta y recaudaciones, gestión contable con posibilidad de anular o hacer asientos, gestión de notas de crédito de las expendedoras.

o Gestión del mantenimiento - consulta de registros de ocurrencia y de intervenciones.

o Configuración – Posibilidad de modificar el catálogo tarifario aplicable en las expendedoras y en los puestos de venta, posibilidad de configurar los menús de los IHM de las expendedoras y de los puestos de venta, gestión de los usuarios, passwords y derechos de acceso. No permite la configuración del Concentrador Embarcado o Canceladoras.

Los datos producidos por el billetaje son almacenados en el PCGB y su gestión se efectúa a partir de este. Los informes operacionales son también generados aquí.

Adicionalmente, el PCGB genera los datos necesarios para elaborar los ficheros de datos resumen de ventas y cancelaciones que se registran en formato “.xml” y se envían al cabildo mensualmente para la liquidación.

Interfaz entre GTC y PCGB

El GTC (Gestión Técnica Centralizada) es el sistema de MTSA que concentra los eventos y alarmas que se producen en todos los subsistemas de la red. Entre ellos los que generan la red de ventas (expendedoras y puntos de venta) y el material embarcado de Billetaje (canceladoras y concentrador).

La conexión entre GTC y Billetaje se realiza en dos puntos:

o En cada parada - por conexión directa de la URT a la expendedora (la URT es el autómata perteneciente al GTC situado en cada parada que recoge todos los eventos y alarmas que se producen en ella). La URT detecta por ejemplo la apertura de la puerta de la expendedora.

o En el CPD (Centro de Proceso de Datos de MTSA) - el PCGB recibe las alarmas propias de la expendedora (falta de títulos, atasco de monedas, etc.) y las envía a través de un interfaz al GTC. Esta conexión se realiza vía Ethernet.

2.3.2. Expendedora ‌

Cada estación de tranvía está equipada con dos expendedoras automáticas de títulos de transporte, una por andén.

En este momento las expendedoras sólo expenden tarjetas magnéticas, pero disponen de lector sin contacto de tecnología Calypso que no está siendo utilizado actualmente.

Las expendedoras aseguran las siguientes funciones en el momento de la transacción comercial con el cliente:

o Selección del título de transporte,

o Pago del título de transporte (pago con monedas, billetes y/o tarjeta bancaria, permitiendo pago EMV), Verificación de los medios de pago del cliente (detección de monedas falsas, llamada al centro de control para comprobar las tarjetas bancarias).

o Emisión de un recibo si es necesario.

o Emisión de Nota de Crédito si procede.

Para las tarjetas magnéticas, la expendedora permite además dos funciones:

o Canje xx Xxxx: permite utilizar el saldo restante de un bono tipo dinero para comprar otro título, de forma que se descuenta del precio de venta el saldo existente.

o Renovación xx xxxx: permite que un usuario pueda traspasar el saldo actual de un bono tipo dinero a un nuevo soporte. Esto ocurre fundamentalmente cuando se llega al límite de impresiones en la cara térmica y debe cambiar de soporte para que la cancelación pueda seguir imprimiendo.

Los medios de pago aceptados por las expendedoras son las monedas y billetes (Euros) y las tarjetas bancarias.

La expendedora se comunica con el PCGB a través de la red de trasmisión de MTSA recibiendo configuraciones y parametrizaciones y enviando datos producidos durante su operación (alarmas, transacciones de venta, registros de invalidación, etc.). Esta gestión local se realiza mediante un ordenador presente en cada expendedora en el que corre un software propietario del suministrador del PCGB. Cada expendedora puede operar en modo degradado en caso de que no haya conexión al PCGB; es decir, puede seguir realizando ventas y transacciones que posteriormente enviará al PCGB cuando se recupere la comunicación.

La comunicación con el PCGB es permanente a través de red Ethernet Gigabit, permitiendo operaciones remotas de mantenimiento en tiempo real.

Las expendedoras están equipadas con módulos (PINPAD, controladora y lectora) que permiten al cliente el pago con tarjeta bancaria EMV. La transacción bancaria se realiza a través de una pasarela EMV de un tercero que realiza la transacción directamente con REDSYS. En cada ordenador de expendedora corre un proceso que envía de forma segura los datos de la transacción a esta pasarela y que devuelve el resultado de la operación según lo que haya respondido a su vez REDSYS. De esta forma MTSA no tiene que disponer de servidor bancario propio ni preocuparse de certificaciones o actualizaciones de protocolos bancarios.

Como una transacción más que se realiza en la expendedora, esta quedará reflejada en el PCGB.

Se incluyen en anexo a este documento las alarmas actuales de la expendedora automática.

Recargas de nuevo sistema para viajar con el móvil VIA-MÓVIL

La expendedora dispone de una función para permitir recargar el sistema de pago con móvil VIA-MÓVIL.

Actualmente la expendedora expide los denominados títulos recarga para Via- Móvil. Estos títulos no son válidos en las canceladoras actuales sino que únicamente imprimen en la cara térmica un número de secuencia por expendedora más cuatro dígitos aleatorios, de forma que desde la aplicación de Via-Móvil el usuario insertando estas dos cadenas numéricas obtiene un saldo igual al precio de compra realizada en la expendedora. Los servidores de Via-Movil se conectan a la BD de la expendedora para comprobar dicha venta.

2.3.3. Puesto de Venta ‌

Existen tres Oficinas Comerciales en las que MTSA realiza la gestión del cliente atendiendo cualquier tipo de incidencia (cobros erróneos de transbordos, compensación de notas de crédito, cobro de sanciones, reclamaciones, etc.) y también vende títulos de transporte.

Estos puestos están integrados en el PCGB y equipados con un terminal punto de venta que está constituido por un ordenador, una grabadora de bonos magnéticos, un lector de bonos magnéticos, un cajón de cobro y una impresora de recibos.

En las Oficinas Comerciales se ha colocado además un TPV externo propiedad de la entidad bancaria que permite al cliente pagar mediante tarjeta bancaria. El agente que realiza la gestión en el punto de venta indica en ese momento si la compra se ha efectuado en efectivo o con tarjeta bancaria.

2.3.4. Terminal de fiscalización ‌

Actualmente MTSA dispone de 8 terminales de fiscalización que permiten el registro del resultado de la inspección de los bonos magnéticos que se realiza por parte de los Agentes de Fiscalización. Los terminales no generan la sanción ya que no poseen impresora integrada, pero sí permiten registrar el código de la misma si el agente procede a sancionar al pasajero.

Adicionalmente estos terminales se conectan vía 3G a un servicio web existente que devuelve los datos de las cancelaciones realizadas por el sistema Vía-Móvil en cada tranvía, permitiendo así fiscalizar a los usuarios de este sistema.

La gestión de estos terminales (definición de la topología de red, títulos, etc...) no se realiza desde el PCGB, sino desde un software independiente y específico. Los resultados de las inspecciones tampoco se vuelcan al PCGB sino a una Base de Datos aparte a partir de la cual MTSA realiza los informes necesarios.

Los terminales son PARTNER modelo OT-300 y sistema operativo ANDROID que ya están provistos de un acoplador para tarjetas sin contacto (13,56 MHz, ISO14443 A/B, FeliCa R/W), pero el software actual no los gestiona.

Para mayor detalle los ofertantes podrán solicitar información complementaria a TITSA/MTSA.

2.3.5. Tranvías ‌

El Sistema de Billetaje embarcado de los tranvías está compuesto por 12 canceladoras y un concentrador embarcado (CE). Este concentrador se comunica con las canceladoras a través de un puerto serie, al igual que con el SAE embarcado. El CE dispone de un interfaz Ethernet para conectarse a la red LAN existente en el vehículo

Los sistemas embarcados se comunican con los servidores centrales a través de dos redes inalámbricas:

- TETRA: utilizada fundamentalmente por el SAE para permitir las conversaciones de voz entre el conductor y el Puesto de Control; y la comunicación de datos entre el SAE embarcado y los sistemas centrales de SAE (alarmas, localización, gestión, etc.)

- WIRELESS: utilizada por el sistema de video embarcado que envía imágenes del interior del tranvía en tiempo real para permitir la supervisión del servicio. Cuando el vehículo entra en TyC (Talleres y Cocheras) se interrumpe la transmisión de video y el CE envía por FTP los registros almacenados. De la misma forma, cuando cae la red TETRA se interrumpe la transmisión de video y se utiliza la red Wireless para la comunicación del SAE. Cuando arranca el concentrador chequea si hay cancelaciones pendientes de enviar, en el caso afirmativo lo envía al servidor a través de FTP.

Figura 2 - Arquitectura actual del tranvía

El Sistema de Billetaje Embarcado no depende del SAE para comunicarse con el PCGB. Esta comunicación es realizada a través del interfaz WLAN existente en los tranvías que es compartida con los otros sistemas embarcados (SAE y Video). Sin embargo, la comunicación entre el CE y el PCGB sólo se realiza cuando el vehículo entra en Talleres y Cocheras, evitando así hacer uso de la red WLAN cuando el vehículo está en línea. Esta comunicación se limita a realizar un FTP para volcar el contenido de las cancelaciones realizadas en el vehículo.

Esta red WLAN es interna de MTSA y no es accesible desde clientes wireless estándar.

El sistema es ampliable a 14 canceladoras en previsión del caso de que MTSA compre un módulo adicional a ALSTOM para aumentar la capacidad de sus tranvías.

El concentrador se encarga de recibir las cancelaciones desde cada canceladora y enviarles la configuración específica (títulos, configuración de la red, reglas de descuento, reglas de transbordo, línea actual, parada, etc.).

Cuando existe un fallo de comunicación entre una canceladora y el concentrador, la canceladora queda operativa para los clientes, memorizando las cancelaciones realizadas, y volcándolas cuando recupera la comunicación con un concentrador válido. Igualmente, si el CE no consigue establecer comunicación ftp con el PCGB mantiene los ficheros hasta que esta se restablece. Está previsto que el equipo pueda albergar hasta un mes de cancelaciones.

Fallos de comunicación.

Cuando el CE no tiene comunicación con el SAE embarcado y por tanto no dispone de información de localización, por defecto el CE se ubica en la línea,

sentido y parada por defecto, enviando esta información a cada canceladora para que apliquen las tarifas y transbordos correspondientes. Esta información por defecto es configurable y MTSA puede cambiarla en cada concentrador.

Para casos de alta demanda, el tranvía puede operar en unidad múltiple.

Se trata de la unión de dos tranvías conectados entre sí que permite a MTSA aumentar la oferta de servicio en eventos de gran afluencia de pasajeros. En este caso los SAEs embarcados de cada vehículo están conectados e intercambian la información necesaria para operar conjuntamente. Cada concentrador de billetaje recibe la información de su respectivo SAE embarcado y cada uno de ellos gestiona sus canceladoras como si fueran en unidad simple.

Alimentación a equipos.

Hay tres señales de alimentación. La permanente (+) y la masa (-), siempre están conectadas al concentrador y canceladoras; mientras que la preparada (también +) que se conecta al concentrador se activa únicamente cuando se arranca el tranvía y es el evento que indica a concentrador y canceladoras que deben encenderse. De la misma manera, estos equipos comienzan a apagarse de forma controlada desde el concentrador cuando desaparece la tensión de preparada.

Software de Configuración de canceladoras (BRIO)

El BRIO, que permite la configuración de las canceladoras, es independiente del PCGB. En él se definen los títulos, configuración de la red, reglas de descuento, reglas de transbordo, etc. Este software genera unas Tablas de configuración que se cargan manualmente en el CE y que las distribuye a las canceladoras. Las canceladoras al arrancar comprueban si hay en el CE una nueva versión de Tablas de configuración, realizando la carga en caso afirmativo.

En estas Tablas no sólo se define la configuración de MTSA, sino también se definen las líneas, servicios y paradas de TITSA ya que son datos necesarios para realizar el transbordo. Esto obliga a que TITSA y MTSA se comuniquen cualquier cambio en sus líneas, políticas de descuentos y transbordos para aplicarlas coordinadamente a sus respectivas canceladoras.

Interfaz del SAE con sistema de billetaje

El OB (Ordenador de a Bordo) del SAE implementa un protocolo de comunicación con el sistema de billetaje sobre un soporte RS-232. El diálogo se hace con el concentrador del billetaje y no con cada una de las canceladoras distribuidas por el vehículo. Esta interfaz permite enviar al concentrador los datos relevantes como línea actual en la que opera el vehículo, parada actual, número de vehículo, etc. En sentido contrario, el concentrador envía las cancelaciones, alarmas de canceladoras, etc. hacia el SAE Embarcado.

Esta comunicación entre el SAE embarcado y el CE también permite enviar ciertas instrucciones a las canceladoras a través del CE. De este modo el conductor puede bloquear, reiniciar o dejar fuera de servicio una o varias canceladoras.

Alarmas del sistema de billetaje

A través de la conexión serie, el SAE Embarcado recibe alarmas del sistema de billetaje embarcado siguientes:

- Concentrador con memoria llena

- Canceladora con memoria llena

- Canceladora fuera de servicio

- Error de comunicación con canceladora

Estas alarmas se muestran al conductor en tiempo real y se comunican por la red TETRA a los servidores centrales de SAE que a su vez las envía al GTC llegando así a los técnicos de mantenimiento.

El CE también registra más alarmas y otros eventos de interés, pero sólo las envía al PCGB por medio de la red Wireless cuando el vehículo entra en TyC al final del servicio, por lo que su utilidad es escasa.

Funcionamiento del SAE

o Sincronización de la hora del sistema de billetaje: El OB del SAE hace la sincronización de la hora del concentrador de billetaje cuando se conecta e intercambia los primeros mensajes con el sistema. La hora de las canceladoras es sincronizada por el concentrador de billetaje.

o Modo degradado: cuando el CE pierde la comunicación con SAE, se sincroniza con la hora del PCGB a través de la conexión WLAN. Cuando se recupera el SAE, vuelve a sincronizarse con el CE.

Cuando el CE está fuera de servicio, las canceladoras siguen con su hora autónoma. No se sincronizan hasta estar de nuevo en comunicación con un CE operativo.

o Información de localización que se proporciona al sistema de billetaje: La información de línea, xxxxx xx xxxxxx, con la indicación de la parada donde el tranvía se encuentra en cada instante, es realizada por el SAE, que determina el posicionamiento del tranvía a través de balizas geográficas instaladas en la línea y del odómetro del vehículo.

El OB del SAE alimenta el sistema de billetaje con datos de localización del vehículo en tiempo real. Momentos antes de llegar a cada estación (a 50 metros de distancia) el SAE informa al sistema de billetaje de la próxima estación y la línea y sentido del servicio.

o Información de desconexión (en TyC) al sistema de billetaje: El SAE informa al sistema de billetaje cuando entra en talleres y cocheras y momentos antes de desconectarse. Con esta información el sistema de billetaje podrá empezar a transmitir las cancelaciones registradas al PCGB.

Modo degradado

Cuando el vehículo regresa a TyC sin que el CE haya recibido la señal, las cancelaciones se quedan en la memoria del concentrador. Se pueden recuperar manualmente a través de la red WLAN o a bordo del vehículo con el terminal de mantenimiento, pero lo más habitual es que al día siguiente cuando el vehículo vuelve a regresar a TyC, el CE vuelca los datos de cancelaciones que están pendientes de enviar, es decir las cancelaciones de los 2 días.

Información de las cancelaciones

Las canceladoras reenvían las informaciones de cancelación al CE en tiempo real. El concentrador del sistema de billetaje informa al SAE en cuanto al número de cancelaciones registradas en el vehículo. Para ello, el SAE utilizará comandos de lectura y puesta a cero (reset) de estos contadores del sistema de billetaje. El comando de lectura del número de cancelaciones en el billetaje será realizado por el SAE siempre que el vehículo sale de una estación y justo antes de llegar a la estación siguiente (a 50 metros de distancia).

Por otro lado, el CE memoriza todas las cancelaciones del turno comercial hasta que llegue al TYC y las vuelque al PCGB a través de FTP por XXXX.

Cuando el CE pierde la comunicación con SAE, o cuando el SAE está fuera de servicio, el SAE no recibe las cancelaciones, y el CE no las memoriza para enviarlas al SAE la próxima vez que se conecten. De cualquier forma, el CE memoriza todas las cancelaciones del turno comercial hasta que llegue al TYC y las vuelque al PCGB a través de FTP por XXXX.

Cuando el CE está fuera de servicio, las canceladoras permiten cancelar los bonos, y memorizar las cancelaciones. La próxima vez que se conecten a un CE, volcarán estas cancelaciones al CE.

Interfaz IHM con el sistema de billetaje

A nivel del IHM existen las siguientes funcionalidades en la interfaz con billetaje con arreglo a la consola del SAE:

o El conductor puede bloquear las canceladoras (bloquea las cancelaciones en todo el sistema de billetaje).

o El conductor puede poner fuera de servicio individualmente cada una de las canceladoras instaladas en el interior del vehículo.

o El conductor puede pedir el reset de cada una de las canceladoras instaladas en el interior del vehículo.

o El conductor puede consultar al sistema de billetaje en cuanto al estado de cada una de las canceladoras. Las canceladoras pueden estar en uno de los tres estados siguientes:

- Operativa.

- Bloqueada.

- Fuera de servicio.

En los vehículos 121 a 126, el conductor dispone de interruptores que permiten controlar la alimentación de las canceladoras. Son 4 interruptores, cada uno controla 3 de las 12 canceladoras.

Fallo de comunicación con el sistema de billetaje

El protocolo de comunicación entre el SAE y el concentrador de billetaje prevé la emisión / recepción regular de mensajes del tipo “lifecheck”.

Siempre que el SAE detecta que no logra establecer comunicación con el sistema de billetaje o que no recibe el lifecheck periódico, envía a los servidores centrales del SAE y estos al GTC una indicación de posible avería en el equipamiento embarcado: fallo de comunicación con el sistema de billetaje.

2.4. TITSA ‌

2.4.1. Arquitectura actual de TITSA ‌

A continuación se muestra un esquema de las comunicaciones del sistema actual de TITSA:

Figura 3 - Arquitectura actual de TITSA

2.4.2. Guaguas.‌

Actualmente las guaguas están equipadas con un SAE, un Pupitre y una Canceladora. Algunas guaguas pueden tener otra canceladora adicional.

Todas las canceladoras están instaladas en la puerta delantera de la guagua, de tal forma que está prohibido a los pasajeros subir por una puerta trasera. Tener “doble canceladora” permite ganar tiempo en el embarque de los pasajeros en las paradas, en particular en las líneas urbanas con alto nivel de ocupación.

El sistema permite configurar los títulos válidos en cada canceladora. Por ejemplo, la canceladora más cerca del conductor permite validar todos los títulos, en particular los títulos que requieren la presentación al conductor de un documento justificativo (carné de Mayor xxx Xxxxxxx, matrícula en la Universidad de La Laguna…). La canceladora

más lejos del conductor sólo permite cancelar los bonos no subvencionados, como por ejemplo el bono dinero.

El Sistema de Billetaje Embarcado depende del SAE para comunicar con el PCGB. Esta comunicación es realizada a través del interfaz WiFi conectado directamente al SAE. Este tipo de conexión actual resulta en que cada fallo de SAE además implica fallo de transmisión de datos de billetaje, lo que perjudica gravemente la explotación del sistema.

La información de xxxxx xx xxxxxx, con la indicación de la parada geográfica o tarifaria donde la guagua se encuentra en cada instante, es realizada por el SAE que integra un módulo GPS y comunicada al pupitre.

Actualmente el interfaz entre el SAE de GMV (proveedor del SAE de TITSA) y el pupitre de ERG se realiza como se ha indicado en el esquema del apartado Arquitectura actual de TITSA.

Existe una librería de software desarrollada por ERG que fue integrada en el software del SAE por GMV. Esta librería permite la comunicación de datos desde el SAE para el pupitre.

El interfaz entre la consola de SAE y el pupitre de billetaje es propietario de ERG. En cambio el mapping de datos entre el software de SAE y la librería de ERG es conocido de XXXXX y se podrá comunicar al adjudicatario del este suministro.

2.4.3. PCGB TITSA ‌

Actualmente existe un PCGB en TITSA, el cual concentra los datos generados por la operación del magnético corrientemente usada en Tenerife.

Adicionalmente, el PCGB genera los datos necesarios para elaborar los ficheros de datos resumen de ventas y cancelaciones que se registran en formato “.xls” y se envían al cabildo mensualmente para la liquidación.

2.4.1. SAE Y SIV TITSA ‌

XXXXX dispone de un SAE basado en comunicación vía radio y un sistema de información al viajero que informa a los viajeros por los siguientes medios:

o Paneles y Displays embarcados.

o Paneles informativos instalados en Paradas (calle)

o Paneles informativos en Dársenas (estaciones)

o Murales (paneles multilínea) situados en estaciones

o Monitores de información situados en estaciones y otros recintos

o Sistema de Información integral para estación (ej.- Intercambiador La Laguna) conectado el Sistema Integral de Estación vía servicio Web

2.5. OTROS ‌

2.5.1. La Esperanza ‌

Actualmente las guaguas de La Esperanza se gestionan como si fuesen guaguas de TITSA.

2.5.2. Parking (Aparcamientos “Park & Ride”)‌

TITSA gestiona 2 aparcamientos de coches, situados en el intercambiador de Santa Xxxx y el intercambiador de La Laguna.

Los aparcamientos funcionan con un ticket de aparcamiento propio, pero los autómatas de pago permiten usar el bono magnético para bonificar a los usuarios del transporte público. También se puede usar el bono de transporte como medio de pago en el aparcamiento. Las barreras de entrada y de salida sólo funcionan con el ticket de aparcamiento.

En el caso de TITSA, Actualmente existe una solución que está implementada y en explotación sobre soporte magnético para el sistema de pago Park & Ride en el intercambiador de S/C de Tenerife.

El sistema se compone por un pupitre y una canceladora idénticos a los instalados en las guaguas. La canceladora está conectada al cajero automático del parking mediante RS-232, y esta última por RS-232 al PC de la caja central del parking (únicamente se comunican a este PC los cobros efectuados por estacionamiento, que dependen de los descuentos efectuados según las lecturas de los viajes efectuados que la canceladora comunica al cajero automático).

Cuando la canceladora está en modo reposo no acepta bonos.

Cuando el usuario introduce el bono del parking en el cajero automático, si existe deuda, el cajero automático habilita entre otros modos de pago el pago con bono, de forma que la canceladora se activa. Si el usuario paga con otro modo de pago, la canceladora vuelve al modo reposo, y en caso contrario el cajero automático le comunica a la canceladora el importe que tiene que cobrar, de forma que la canceladora calcula el importe final aplicando los descuentos correspondientes según el trayecto que el usuario ha efectuado en el transporte.

Si la canceladora detecta que el bono no tiene suficiente saldo, le comunica al cajero automático la diferencia que el usuario debe pagar con dinero en la automática.

La descarga de datos de las operaciones efectuadas con el bono de transporte se efectúa de forma manual (llave) desde el pupitre.

Para la Caja Central del parking existe otro punto para realizar los cobros a los usuarios que paguen en caja central. El sistema aquí se compone también de un pupitre y una canceladora que descargan los datos a un PC (al que está conectada la caja central), donde reside una aplicación desarrollada por ERG que simula el funcionamiento xxx xxxxxx automático. En este caso la descarga de los datos de

operaciones efectuadas con el bono de transporte se efectúa manualmente desde el pupitre (mediante llave).

Este mecanismo está habilitado únicamente para los bonos de dinero de 12 y 30 euros.

En el intercambiador de Santa Xxxx actualmente tiene las dos modalidades (canceladora+cajero y canceladora+PC) y la de La Laguna únicamente la modalidad canceladora+PC.

2.5.3. Taxi ‌

TITSA gestiona las cancelaciones efectuadas en los taxis de la siguiente forma:

o El equipamiento del taxi consiste en una canceladora idéntica a la instalada en las guaguas.

o La configuración de la canceladora y los comandos que en la guagua le transmite el pupitre se cargan mediante tarjetas de BM especiales que contienen los comandos de trabajo (por ejemplo, para la apertura del servicio).

o Una vez al mes, los datos de las operaciones efectuadas en la canceladora se descargan manualmente al PCGB.

2.5.4. Red de Ventas ‌

TITSA tiene actualmente dos canales de ventas directas:

o Ventas a bordo. A bordo sólo se venden los títulos sencillos o ida y vuelta en papel, válidos para el mismo día.

o Puestos de venta. En cada una de las estaciones principales existe un puesto de venta donde se puede comprar cualquier título magnético. En la actualidad TITSA gestiona 12 puntos de atención al cliente y dos puestos independientes de personalización de carnets de empleados (uno para bono sociales y otro para el resto).

Dispersos por la isla de Tenerife existen kioscos que venden bonos dinero pre- cargados. Existe una instalación central de producción masiva de bonos dinero pre- cargados, que actualmente es operada por TITSA. Los bonos dinero pre-cargados son distribuidos:

o Por compra directa de los kioscos en las oficinas de TITSA.

o Por los kioscos usando un distribuidor que efectúa la compra como mayorista en las oficinas de TITSA.

2.6. COMPENSACIÓN A LOS OPERADORES DE TRANSPORTE ‌

La venta de títulos es realizada por los operadores, constituyendo junto con la tarifa ordinaria cobrada a los usuarios del servicio, ingresos comerciales de los operadores, que forman parte de su cuenta de explotación ordinaria.

En este escenario las compensaciones tienen sentido únicamente entre el Cabildo de Tenerife y los distintos operadores, nunca entre los operadores directamente. Este mecanismo de compensación tiene en cuenta las cancelaciones de todos los servicios prestados, independientemente de a qué operador se ha hecho el pago xxx xxxx.

El dinero a compensar es la liquidación entre el importe de los servicios prestados, que se calcula en base a las cancelaciones reales, restándole a esta cantidad la suma de las ventas y recargas cobradas por un operador en el periodo de tiempo para el cual se calcula la compensación. Debido a la complejidad de las tarifas kilométricas variables, el importe a compensar también es variable por cada cancelación, por lo cual se calcula en los servidores centrales de TITSA y MTSA, según Tablas acordadas con el Cabildo, y se reenvía al Cabildo en el archivo de cancelaciones y ventas. Cabe notar que el Cabildo compensa el importe por una cancelación, dependiendo de si es transbordo bonificado o no.

Para cada tipo xx xxxx, pero en particular para los bonos dinero, existen 4 conceptos de importe en la cancelación:

o Importe cobrado al cliente (el que se descuenta del saldo disponible en el soporte).

o Importe tarifa a compensar por el Cabildo al operador de transporte.

o Importe tarifa bono, que es el precio del trayecto si es un bono dinero y si no ha existido una cancelación previa que da derecho a bonificación del transbordo.

o Importe de subvención, que es la diferencia entre el importe a compensar al Cabildo y el importe cobrado al cliente, que es soportado por el Cabildo o por cualquier otra entidad que subvenciona, dependiendo del tipo xx xxxx usado y del perfil del cliente.

Aunque los ingresos de las ventas pertenecen a TITSA y a MTSA, virtualmente todo se calcula como si las ventas pertenecieran al Cabildo, y que el Cabildo sólo pagara los importes a compensar a cada operador.

CAPÍTULO II: ALCANCE DEL PROYECTO

3. ALCANCE DEL PROYECTO ‌

3.1. ALCANCE GENERAL ‌

El alcance de esta contratación es el suministro/adaptación, instalación, pruebas, documentación, formación del personal y puesta en marcha del equipamiento necesario para la implantación de un sistema de billetaje SIN CONTACTO (incluyendo los sistemas centrales - PCGBs de TITSA y MTSA), del SCGB (Sistema Central de Gestión de Billetaje), así como de un nuevo Sistema de Ayuda a la Explotación (SAE) para TITSA y su respectivo centro de control, que se detallan en este pliego así como las obras a realizar para su puesta en funcionamiento y los trabajos de mantenimiento (durante el periodo de garantía) una vez recepcionados dichos sistemas.

Se incluye también en este pliego:

▪ La descripción de las funcionalidades a cubrir por cada tipo de equipo,

▪ El detalle de las obras a realizar,

▪ Las pruebas y ensayos previos a la recepción de los diferentes suministros,

▪ Condiciones de Seguridad y Salud.

▪ Plan de Calidad.

▪ Otras consideraciones aplicables al suministro.

3.2. CONDICIONES DEL CONTRATO ‌

Las condiciones de la contratación objeto de este pliego se incluyen en el pliego administrativo.

Con respecto al código fuente de los suministros, una vez certificado y una vez finalizado el plazo de garantía, deberá ser depositado ante notario para garantizar la continuidad del sistema a lo largo de tiempo y en los procesos de migración a pesar de las contingencias que pudieran producirse en el adjudicatario.

Para ello se firmará un contrato de entrega de dichos códigos que guarde adecuadamente los intereses de las partes.

El suministrador entregará al final del periodo de garantía las credenciales de acceso 'root' o 'administrador' de todos los sistemas software y bases de datos que formen parte del proyecto.

3.3. DESCRIPCIÓN DE LAS OBRAS E INSTALACIONES ‌

El suministro objeto de este pliego se resume en la tabla siguiente, teniendo en cuenta que existen requisitos:

• Obligatorios: requisitos que están incluidos explícitamente en la oferta.

• Que se valorarán positivamente: en este caso si el ofertante los incluye en su oferta, se tendrán en cuenta en la valoración.

3.4. RESUMEN DE SUMINISTROS ‌

ITEM

DESCRIPCIÓN

SE VALORARÁ POSITIVAMENTE

ELEMENTOS MTSA

Expendedora MTSA

- Criptoprocesador adicional al módulo XXX (al menos para 3DES/AES/RSA) para poder realizar las encriptaciones necesarias para ejecutar transacciones en tiempos óptimos.

- Aceptación de pago con tarjetas EMV sin contacto (ver apartado Tarjeta bancaria-EMV).

- Sistema de encaminamiento de monedas y billetes flexibles

- Capacidad de contenedores (o rollos/conjunto unificado de rollos) de tarjetas superior a

3.000 bonos cada uno.

- Comunicación ordenador-periféricos no serial

- Soluciones del tipo cableado de vaina plana para puente grúa.

Puestos de venta/ Recarga/gestión de incidencias y personalización

MTSA

- Integración de aplicación de gestión de incidencias y venta/recarga.

- Configuración hardware/software que permita un restablecimiento de las comunicaciones entre el ordenador y sus periféricos sin necesidad de reinicio del primero.

Nuevo PCGB MTSA

- Entorno diferenciado de desarrollo – pruebas que permita testear nuevas funcionalidades antes de ponerlas en producción sin interferir en los procesos en funcionamiento.

- Entorno para elaboración de informes personalizados

Validadora sin contacto dependiente de MTSA

- Criptoprocesador adicional al módulo XXX (al menos para 3DES/AES/RSA) para poder realizar las encriptaciones necesarias para ejecutar transacciones en tiempos óptimos.

- Capacidad de emitir mensajes de voz pre-grabados en el equipo. Se valorará positivamente que incluya sintetizador de voz.

Concentrador embarcado MTSA

- Se valorará positivamente una segunda tarjeta de red Ethernet.

- Se valorará positivamente que el concentrador permita levantar varias máquinas virtuales en el mismo hardware.

Terminales de inspección / mantenimiento MTSA

- Criptoprocesador adicional al módulo XXX (al menos para 3DES/AES/RSA) para poder realizar las encriptaciones necesarias para ejecutar transacciones en tiempos óptimos.

ELEMENTOS TITSA

Pupitre TITSA

- Criptoprocesador adicional al módulo XXX.

- Capacidad de emitir mensajes de voz pre-grabados en el equipo. Se valorará positivamente que incluya sintetizador de voz.

- Integración del lector de código xx xxxxxx 2D en el equipo.

- Se valorará positivamente la oferta de consola de SAE-pupitre en un mismo equipo.

Validadora sin contacto dependiente TITSA

- Criptoprocesador adicional al módulo XXX (al menos para 3DES/AES/RSA) para poder realizar las encriptaciones necesarias para ejecutar transacciones en tiempos óptimos.

- Capacidad de emitir mensajes de voz pre-grabados en el equipo. Se valorará positivamente que incluya sintetizador de voz.

Concentrador cochera TITSA

Nuevo PCGB TITSA

- Entorno diferenciado de desarrollo – pruebas que permita testear nuevas funcionalidades antes de ponerlas en producción sin interferir en los procesos en funcionamiento.

- Partes del sistema que puedan funcionar en plataformas diferentes.

Puesto emisión masiva TITSA

Puesto personalización TITSA

Puntos de venta/atención al cliente propios

- Integración de aplicación de gestión de incidencias y venta/recarga.

- Configuración hardware/software que permita un restablecimiento de las comunicaciones entre el ordenador y e sus periféricos sin necesidad de reinicio del primero.

Equipos de venta/recarga para puntos red ventas externa

TITSA

Validadora sin contacto independiente (taxis) TITSA

- Capacidad de emitir mensajes sonoros.

- Criptoprocesador adicional al módulo XXX (al menos para 3DES/AES/RSA) para poder realizar las encriptaciones necesarias para ejecutar transacciones en tiempos óptimos.

Adaptación Park & Ride TITSA

Terminales de inspección / mantenimiento TITSA

- Criptoprocesador adicional al módulo XXX (al menos para 3DES/AES/RSA) para poder realizar las encriptaciones necesarias para ejecutar transacciones en tiempos óptimos.

ITEM	DESCRIPCIÓN	SE VALORARÁ POSITIVAMENTE
18	Suministro SAE TITSA	- Gestión la voz por datos VOIP. - Módulo de gestión de información multimedia a pasajero integrado en la unidad de control embarcada del SAE. - Canal adicional WIFI y GPRS/3G/4G. - Conexión a CANBUS/FMS y módulo gestor para esta información. - Comunicación con sistema de priorización semafórica. - Integración en una sola antena de WIFI, GPRS/3G, GPS. - Sistema de ayuda a la toma de decisiones. - Planificación de recursos en tiempo real. - Posibilidad de integración en el mismo terminal del SAE el terminal de Billetaje. - Gestión de desvíos por obras, averías u otras incidencias
ELEMENTOS COMUNES TITSA MTSA
19	Suministro SCGB	- Entorno diferenciado de desarrollo – pruebas que permita testear nuevas funcionalidades antes de ponerlas en producción sin interferir en los procesos en funcionamiento. - Partes del sistema que puedan funcionar en plataformas diferentes.
20	Seguridad y Suministro módulos XXX
21	Mantenimiento y Garantía
22	Garantía Suministros de stock

CAPÍTULO III: DESCRIPCIÓN DE LOS SUMINISTROS

4. DESCRIPCIÓN GENERAL DEL SISTEMA SIN CONTACTO ‌

4.1. LA TARJETA SC DE TENERIFE ‌

La tarjeta SC de Tenerife es el soporte de los títulos de transporte integrados de la isla de Tenerife. La tarjeta podrá albergar también títulos no interoperables propiedad de los operadores si así se acuerda.

Está previsto el siguiente escenario en cuanto a los tipos de soportes a utilizar:

• Títulos sencillos:

o En tarjeta Sin Contacto flexible: Mifare Ultralight C ®.

o Sencillo en papel para compra en pupitre de autobús.

o Tarjeta de crédito/Débito sin contacto.

o Móvil NFC.

• Billete incidencia:

o En papel para compra en pupitre de autobús.

o Mifare Ultralight C ® para compra en expendedora automática o taquillas.

• Bonos/monedero y títulos de pos-pago.

o En soporte Sin Contacto rígido (anónima / personalizada): Mifare Desfire EV1 ® 4-8K.

o Móvil NFC.

• Títulos Especiales: eventos, tarjeta turística, etc.

o En tarjeta Sin contacto Flexible: Mifare Ultralight C ®

o Tarjeta Sin Contacto rígida: Mifare Desfire EV1 ® 4-8K.

NOTA: Aunque a fecha de elaboración de este pliego todavía no se comercializa, NXP está desarrollando un nuevo chip MIFARE DESFIRE EV2 ® que incluye mejoras sobre la versión EV1. Todos los suministros deberán tener en cuenta la posibilidad de la implementación futura del nuevo chip.

La tarjeta mayoritaria preliminarmente elegida es una MIFARE ® DESFIRE EV1, pero se debe tener en cuenta que:

o La tarjeta podrá ser híbrida y tener otros chips como UHF o criptográfico para otros usos (no se requiere el tratamiento de estos chips por los equipos de Billetaje sujetos a este contrato).

o Además de MIFARE ® DESFIRE EV1 podrán existir tarjetas de otros tipos dentro de la familia MIFARE (por ejemplo, MIFARE PLUS), para otros usos como tarjetas desechables para títulos sencillos o dispositivos como llaveros o relojes.

o El soporte del chip podrá ser, además de tarjeta rígida o flexible o de otros tipos como llaveros y relojes.

o Para el pago de billetes sencillos podrán usarse tarjetas de crédito bancarias sin contacto.

o Como mínimo la tarjeta tendrá que soportar 1 título interoperable + 1 título propio + 1 monedero.

4.1.1. Tipos de tarjetas ‌

Se prevé que existan los siguientes tipos de tarjetas:

o Tarjetas anónimas: albergan títulos de transporte de uso multipersonal (bonos multiviaje, títulos basados en monedero, etc.) y a tarifa general (los títulos con tarifas especiales requieren tarjetas personalizadas). Estas tarjetas tienen diseño predeterminado de fábrica y no contienen datos personales del usuario ni interna ni externamente.

o Tarjetas personalizadas: pueden albergar títulos de uso personal (títulos temporales, usuarios con perfiles subvencionados) y son personalizadas en los puntos de atención al cliente con los datos de usuario impresos externamente y grabados electrónicamente. También pueden albergar títulos multipersonales al igual que las tarjetas anónimas.

o Otros soportes: tales como llaveros, relojes, etc. Estos dispositivos pueden vincularse a una tarjeta, pudiendo esta ser personalizada o no, y los títulos que pueden cargarse en ellos dependen de su vinculación o no con los tipos de tarjeta mencionados.

o Teléfonos y otros dispositivos móviles (ver punto teléfonos móviles).

o Tarjeta bancaria (ver punto tarjeta bancaria-EMV).

4.2. SISTEMA TARIFARIO ‌

Aunque el Sistema Tarifario actual se basa en tarifas planas para el caso de MTSA y líneas urbanas de TITSA y tarifas kilométricas variables donde la tarifa a aplicar depende de la distancia recorrida (ver Descripción del Sistema Actual en este mismo documento), el nuevo sistema prevé además un sistema tarifario basado en saltos zonales. Se establecerá una matriz que indica los xxxxxx xx xxxx que existen entre las diferentes zonas, de forma que se liga una tarifa por cantidad de xxxxxx xx xxxx.

Inicialmente se gestionarán títulos basados en el Sistema Tarifario actual que convivirán en el futuro con los nuevos títulos basados en Sistema Tarifario zonal, que se irán integrando gradualmente.

4.2.1. Títulos ‌

El diseño de la tarjeta SC de Tenerife está orientado a soportar cualquier tipo de título:

Perfiles.

Los que se deseen configurar y al menos los indicados en el punto Perfiles con descuentos incluido en la descripción del Sistema Tarifario Actual.

Títulos.

Los equipos deberán poder tratar todos los títulos de transporte actualmente en vigor en Tenerife y todos aquellos que puedan encuadrarse, entre otras, en las siguientes categorías:

- Títulos temporales, multiviaje y mixtos con capacidad de transbordo y control de tiempo en red.

- Monederos asociados o no a títulos de transporte concretos.

- Títulos pos-pago basados en cobro según el uso realizado.

- También debe permitir comportamientos transparentes para permitir pagos que no afecten a los derechos de viaje (pagos de otros servicios que no afectan a los datos relativos al transporte).

- Bonificaciones según el uso en cancelación.

- Gestión de tarifas por tramos horarios.

- Etc.

El sistema permitirá establecer promociones entendidas como descuentos personalizados que se aplican en determinadas condiciones y a grupos de usuarios previamente definidos. Estos descuentos pueden ser, por ejemplo:

- En la venta/recarga: estableciendo un descuento en la venta o recarga de un título concreto.

- En la cancelación: estableciendo un descuento nulo para títulos tipo Viaje, o un descuento menor al de la tarifa correspondiente para títulos tipo Dinero.

4.3. MAPA Y PROCEDIMIENTOS ‌

Se pondrá a disposición del adjudicatario toda la información relativa a los mapas de las tarjetas a implementar (según los tipos de tarjeta pueden existir diferentes mapas, por ejemplo, uno para la tarjeta MIFARE ® DESFIRE general y otro para las tarjetas desechables), así como a los procesos por los que pasa la tarjeta, donde se describe la lógica a implementar en los equipos para tratar la tarjeta. A modo orientativo (los procedimientos a elaborar pueden verse modificados según las necesidades del proyecto) se incluyen a continuación los documentos previstos:

o Estructura de Datos

o Diseño Funcional tarjeta

o Diseño Localización

o Diseño Seguridad tarjeta y XXX

o Diseño procesos:

- Proceso Validación

- Proceso Carga

- Proceso Fabricación

- Proceso Inspección

- Otros procesos

- Diseño Comunicaciones

4.4. RED DE VENTAS Y PERSONALIZACIÓN ‌

Existirán diferentes puntos de venta de tarjetas y títulos:

- Taquillas/ Puntos de atención al cliente.

- Expendedoras automáticas.

- Kioscos.

TITSA gestiona los puntos de venta en kioskos, los cuales dispondrán de terminales tipo POS propiedad de TITSA, así como los puntos de venta propios en sus taquillas, donde

además de las funciones de venta, se gestionarán incidencias, consultas, etc. dentro de las tareas propias de atención al cliente mediante una aplicación en entorno PC.

Por su parte, MTSA gestionará las ventas en expendedoras automáticas y en sus puntos de venta propios (taquillas), donde además gestionarán también las tareas de atención al cliente (gestión de incidencias, consultas, etc.).

En referencia a la personalización:

• TITSA gestionará la personalización no presencial, es decir, se habilitarán mecanismos de pre-personalización, donde se solicitará al usuario la documentación necesaria para llevar a cabo la personalización en los puntos de personalización masiva. Una vez personalizada la tarjeta, se entregará al usuario en los puntos habilitados para ello.

• MTSA gestionará la personalización on-line, presencial, en sus puntos de personalización, pudiendo habilitar también procesos de personalización no presencial.

4.5. EL SISTEMA CENTRAL DE GESTIÓN DE BILLETAJE (SCGB)‌

4.5.1. Descripción ‌

Deberá suministrarse un Sistema central de Billetaje (SCGB) para la gestión de las operaciones efectuadas en el nuevo Sistema Sin Contacto.

Es objeto de este contrato el suministro tanto del SW como del HW del SCGB, así como su mantenimiento posterior según los términos especificados más adelante en el apartado de mantenimiento.

En el SCGB residirá la BBDD común, en especial en lo referente a las tarjetas y títulos de uso combinado entre TITSA y MTSA y es donde correrán los procesos relacionados con dichos títulos y tarjetas, siendo los sistemas centrales de TITSA y MTSA (PCGBs), los encargados del control operacional de los equipos (mantenimiento, alarmas, monitorización).

Cuando se hace referencia al Ente Gestor del SCGB puede hacer referencia a una gestión compartida entre el cabildo y los operadores. Por este motivo en el diseño del nuevo SCGB ha tenido muy en cuenta el acceso de terceros a los datos del SCGB y a su gestión.

Los procesos necesarios para gestionar los datos del sistema integrado de transporte se reparten entre el SCGB y los PCGBs de cada operador, tal y como se describe en este apartado y en los apartados correspondientes a los PCGBs.

4.5.2. Funciones ‌

Todos los equipos deben comunicarse con el SCGB para el envío de las transacciones efectuadas y con el PCGB del operador correspondiente para la recepción de listas y datos de parametrización/configuración.

Se incluye una descripción general de las funcionalidades del SCGB (como propuesta de diseño para la configuración de los sistemas centrales y de las comunicaciones entre estos y los equipos. Los ofertantes podrán proponer otras variantes según su experiencia), así como de la arquitectura de comunicaciones prevista, que debe prever la comunicación on-line del SCGB a los PCGBs de los operadores y de éstos con todos los equipos que gestionen listas y los datos de configuración actualizables (por ejemplo, si se incluyen operaciones de recarga de lista blanca, la comunicación debe poder ser on-line para que el usuario pueda efectuar la recarga en cuanto haga la próxima operación en el equipo).

El SCGB es el Sistema Central de Gestión de Billetaje, donde residirá toda la información proveniente de los diferentes equipos de Billetaje. El SCGB se comunica a su vez con los PCGBs tal y como se indica en el siguiente gráfico:

	Sistema de Billetaje de Tenerife y	Código:TITSA-BIL-PG
	nuevo SAE TITSA	Edición: 2.0 Fecha: 27/2/2014
	Pliego de Prescripciones Técnicas
		Página: Página 42 de 278

Figura 4 - Configuración SCGB-PCGBs

Como puede observarse en el esquema anterior:

• Existe una comunicación directa de los equipos de cada operador con el SCGB para el envío de las transacciones, que podrá efectuarse off-line u on-line (en algunos casos podrá requerirse obligatoriamente on-line, como en el caso de las operaciones de la red de ventas).

• Se requiere un interfaz para gestión de diferentes procesos entre los PCGBs y el SCGB por parte de los operadores (configuración, consultas, listas, etc.).

• Se requieren servicios web para gestionar las personalizaciones, el servicio web a usuario final y la gestión de incidencias.

• Se requiere un acceso directo a la BBDD por parte de los operadores.

A continuación se incluye un esquema con los módulos funcionales de los que deberá constar el SCGB:

Figura 5: Módulos funcionales del SCGB.

Las funcionalidades de cada módulo se detallan en el punto siguiente.

4.5.3. Arquitectura lógica ‌

A continuación se describen las funcionalidades de los diferentes módulos y elementos incluidos en el anterior esquema.

4.5.3.1. Grupo módulos Gestión del Sistema

Módulos necesarios para una adecuada gestión del sistema desde el punto de vista de las funcionalidades que debe cumplir.

Se entiende que estos módulos serán gestionados por los técnicos responsables del buen uso y gestión de este sistema en el nivel operativo. Por ejemplo, gestión de listas, controles de fraude, etc.

Estos son:

o Gestión del fraude: se implementarán procesos para la monitorización del fraude, de modo que existan procesos de detección del fraude automáticos que generen alarmas para su análisis. Como ejemplo, se implementarán, entre otros, controles como detección xx xxxxxx en saldos, contraste de cargas con validaciones, saltos en número secuencial de transacciones, etc.

En el SCGB se implementarán los algoritmos de detección del fraude y la generación de alarmas al respecto en una interfaz en las que el gestor del sistema (ya sea el cabildo o los operadores) puedan interactuar para analizar las alarmas y resolver el problema (por ejemplo, si se trata de un salto en saldos acompañado de un salto en el contador secuencial de transacciones, puede deberse a una operación de carga no enviada, y la solución puede pasar por “reconstruir” la operación de carga faltante para cerrar la validación). Podrán definirse procedimientos de resolución de alarmas automáticos y manuales.

o Gestión de seguridad: Incluye las siguientes funcionalidades:

- Gestión de permisos y usuarios por entidades y perfiles, con definición de permisos y accesos a las diferentes aplicaciones y datos: por ejemplo, podrá definirse que para el operador 1 existe un perfil de consulta que sólo puede acceder a la consulta de datos provenientes de su sistema y a los informes de liquidación. Existirá una interfaz para la configuración de dichos perfiles y permisos por parte xx xxxxxxx/operadores según los permisos que se establezcan para cada uno.

- Procesos para asegurar la autenticidad de los registros recibidos y la autenticidad de los datos:

▪ En el SCGB se implementarán controles sobre las BBDD para cargar datos (registros de las operaciones que se efectúan en los equipos del sistema) que sean consistentes (por ejemplo, formatos de datos correctos) y sobre la autenticidad de los registros recibidos según los algoritmos de encriptación que se definan (ver módulo Administración y monitorización para otras verificaciones sobre los registros).

▪ Se tendrá en cuenta que puedan incluirse ficheros manualmente en el FTP de SCGB y que sean procesados por éste, en previsión de que algunos datos puedan no llegar por las vías habituales y deban ser descargados manualmente por los operadores.

o Gestión de tarjetas y otros soportes: gestión de vinculación de otros soportes a las tarjetas (por ejemplo, vinculación de un reloj a una tarjeta personalizada), y de construcción xx xxxxxx de la tarjeta (deberá poder reconstruirse una imagen de los datos más representativos de la tarjeta con los datos que se tienen de ésta hasta el momento):

o Vinculación: existirá una interfaz accesible por los operadores/cabildo desde donde puedan vincularse los diferentes dispositivos a tarjetas existentes.

o Espejo de las tarjetas: el SCGB procesará los datos de todas las tarjetas recibidos para construir la imagen de estas. Este procesado podrá efectuarse con la periodicidad que se determine, teniendo en cuenta la periodicidad de recepción de datos. Existirá un interfaz de consulta para operadores/cabildo de los datos xxx xxxxxx de la tarjeta.

o Gestión de listas:

Aunque puede gestionarse como una única lista, según su funcionalidad pueden definirse tres tipos de listas:

- Lista Negra: Las listas negras deben almacenar datos relativos a tarjetas que debieran ser bloqueadas o rechazadas por las razones que se estimen oportunas.

- Lista Blanca: Las listas blancas deben almacenar aquellas tarjetas en las que está pendiente cargar un título o saldo, que ya ha sido abonado por algún medio que no permite la comunicación con la propia tarjeta. Dentro de este grupo se contemplan los siguientes casos:

▪ Pago de una recarga a través de la página web de usuario final.

▪ Pago con móvil.

▪ Pago en un terminal que no tenga lector sin contacto.

- Lista Gris: Las listas grises deben almacenar tarjetas sobre las que será necesario realizar algún tipo de actuación específica. Por ejemplo, si algunos datos no están correctos en la tarjeta, o se quiere actualizar la versión de la tarjeta y cambiar los campos de algún bloque, etc.

Dentro de la Gestión de Listas el SCGB debe cumplir con las siguientes funciones:

- Gestión de Listas y Sublistas: Con el objeto de no saturar los equipos con listas incrementales de gran tamaño, pero manteniendo un adecuado control de las tarjetas, se establece una organización de cada lista en tres sublistas (aplicable a los tres tipos definidos, pero particularmente a la lista negra): sublistas reciente, latente e histórica.

- Localizador de Lista: El SCGB deberá poder gestionar los contadores a modo de “localizador” asociados a cada tarjeta, de forma que el contador se ve incrementado con cada acción por lista.

- Propagación de acciones de lista a realizar a los equipos: el SCGB pondrá a disposición de los PCGBs las listas a propagar a los equipos para que este último la distribuya a los equipos afectados:

▪ Listas completas e incrementales: el SCGB podrá generar listas completas (toda la sublista reciente) mediante una lista completa o bien únicamente las nuevas acciones de lista mediante una lista incremental.

▪ Lista de acciones individuales o lista de acciones conjuntas: el SCGB será capaz de generar listas de acciones a realizar para cada tarjeta individual o bien listas con acciones a realizar por un grupo de tarjetas.

- Operaciones efectuadas en los equipos: los equipos enviarán al PCGB (y de este al SCGB) las acciones de listas efectuadas (bloqueos, recargas, etc.) con una periodicidad que dependerá de la criticidad de la operación y que variará desde on- line a periodicidades mayores, de forma que el SCGB deberá actualizar las listas con dichas acciones.

- Los operadores/cabildo podrán efectuar ABMs (Altas/Bajas/Modificaciones) en las listas mediante interfaz web apropiada para este uso. Para ellos deberán habilitarse:

▪ Procedimientos de inclusión y permanencia en lista.

▪ Procedimientos para la transmisión de la lista a los equipos.

▪ Procedimientos de baja en la lista.

▪ Procedimientos de modificación xx xxxxxx.

Dichas operaciones podrán ser realizadas:

▪ A petición de un usuario concreto (por ejemplo, alta de tarjeta en lista negra a petición de un operador -gestor del PCGB- a través de la interfaz al efecto del SCGB).

▪ De forma automática (por ejemplo, a la recepción de acción de lista realizada por un equipo o por alarma de fraude ya definida en el SCGB).

- Desbloqueo de tarjeta: el SCGB será capaz de gestionar operaciones de desbloqueo de una tarjeta en condiciones específicas (por ejemplo, desbloqueo de una tarjeta en un Centro de Atención al cliente tras comprobar que se ha localizado una tarjeta robada).

o Gestión de entidades y configuraciones: el SCGB permitirá el almacenamiento de los datos y configuraciones del sistema tales como:

o Códigos de títulos

o Códigos de empresas

o Tarifas: se tendrá en cuenta la diferenciación entre tarifas en la venta de títulos (precio de venta) y en la validación (reglas de descuento).

o Versiones de SW de los equipos.

o Matrices zonales.

o Transbordos: tiempos de transbordo, número de transbordos permitidos, matrices de transbordos entre líneas, etc.

o Etc.

Así mismo, permitirá la actualización de dichos datos, bien de forma manual o bien al recibir cambios en los registros de transacciones recibidas.

Las ABMs (Altas/ Bajas/ Modificaciones) serán efectuadas por los operadores/ cabildo a través de una interfaz web, y los datos del sistema tarifario integrado se almacenarán en el SCGB.

4.5.3.2. Grupo módulos de Comunicaciones y Monitorización.

Módulos dedicados a la administración y monitorización del buen funcionamiento del SCGB y del sistema de billetaje.

Se entiende que estos módulos serán en general gestionados por administradores del sistema, administradores de los equipamientos del sistema de billetaje y otras personas involucradas en el mantenimiento y supervisión de los mismos.

Estos son:

o Gestión y monitorización del sistema: cuadro de mandos para el control de:

o Monitorización y control de procesos activos en el SCGB.

o Monitorización y control de servidores activos (por ejemplo, controles de procesos activos o excesivamente activos, archivos abiertos o bloqueados demasiado tiempo, operaciones programadas no ejecutadas)

o Monitorización y control de BBDD (accesos de los diferentes usuarios, niveles de llenado, etc.).

o Otros.

o Comunicaciones datos del transporte: permitirá controlar los procesos de comunicación de datos del transporte:

o El SCGB recibe las operaciones efectuadas por todos los equipos y llevará a cabo los procesos de confirmación de envío de información por parte de todos los equipos, así como las verificaciones de las operaciones individuales (por ejemplo, aplicación correcta de tarifa de validación), así como la generación de alarmas al respecto para su resolución.

o En el SCGB se efectuarán también las verificaciones que requieran comprobaciones cruzadas con todas las operaciones realizadas con una tarjeta (por ejemplo, si se quiere verificar que el tiempo de transbordo se aplicó correctamente o si una recuperación en otro equipo se hizo según lo especificado).

o Además el SCGB gestionará las autorizaciones on-line de las operaciones de los equipos que pueden efectuar ventas (especialmente los correspondientes a la red de ventas externa de TITSA y las expendedoras en el caso de MTSA), como por ejemplo, verificación de tarjeta existente en la BBDD del SCGB antes de la venta.

En todos los casos, el resultado de las verificaciones desembocará en la generación de alarmas para aquellas verificaciones NO OK, en una interfaz web que puedan gestionar operadores/cabildo.

4.5.3.3. Grupo de módulo de gestión de clientes.

Son módulos que, parcial o totalmente, tienen que ser ejecutados en máquinas externas al ser equipos que necesitan comunicarse y gestionar elementos externos y periféricos y que deben mantener una adecuada comunicación con el resto del sistema (cada uno a diferente nivel). Los “clientes” a gestionar son:

o Personalización y SAC: estos puestos se comunicarán a través de un servicio web del SCGB y podrán llevar a cabo las siguientes funciones:

o Altas/bajas/modificaciones de usuarios: los usuarios deberán registrarse en la BBDD del SCGB y asignar un código de identificación única a cada usuario (podrá determinarse la asignación de lotes de estas codificaciones en caso de caída de las comunicaciones),

o Emisión de tarjetas personalizadas: se establecerán controles sobre los números de chips utilizados, tarjetas dadas de baja, verificación de proceso OK, etc. Asimismo, se registrarán los datos relativos a las tarjetas personalizadas al finalizar el proceso en el SCGB.

o Resolución incidencias:

▪ Gestión de tickets de incidencias emitidos en la guagua o el tranvía cuando una tarjeta sin contacto no funciona.

▪ Reconstrucciones de tarjetas y canjes: cuando una tarjeta no funciona, podrá recuperarse su información del SCGB y grabarla en la misma u otra tarjeta nueva.

▪ Bajas de tarjetas.

▪ Petición de alta de tarjeta en lista negra.

▪ Otros.

o Consultas: desde el punto de personalización/atención al cliente podrán efectuarse consultas sobre las tarjetas contenidas en la BBDD del SCGB.

o Identificación usuario VIA-MÓVIL: entre los datos almacenados de los usuarios registrados en el SCGB, se incluirá la identificación de si el cliente es también usuario de Via-Móvil (ver apartado MTSA en Antecedentes) Esta información reside en el PCGB de MTSA y la identificación se realizará manualmente por un operador mediante uno o varios campos a definir.

o Servicio para web usuarios finales: . Este servicio web del SCGB deberá resolver los siguientes procesos ligados a las funciones que podrá requerir el usuario desde la web (es objeto de este contrato el desarrollo de las webs finales de usuario, cuyas funcionalidades se describen más adelante):

o Registrarse como usuario: el SCGB deberá registrar los usuarios (usuario, contraseña, otros identificadores) que se dan de alta a través de la web y gestionar el control de accesos de dichos usuarios.

o Consultas: los usuarios registrados podrán efectuar consultas sobre los datos de sus tarjetas una vez registrados como usuario.

o Cargas/recargas: los usuarios podrán efectuar cargas/recargas una vez registrados como usuarios, sobre las tarjetas registradas a su nombre (mediante pago con tarjeta de crédito y pasarela bancaria o bien mediante domiciliación bancaria).

El SCGB deberá incluir la tarjeta en lista blanca para comunicarla posteriormente a los equipos que pueden efectuar la acción de recarga.

o Tarjetas registradas: las operaciones a efectuar en las webs de los operadores únicamente serán posibles sobre tarjetas personalizadas o tarjetas anónimas registradas en el SCGB.

o Consultas terceros: el SCGB dispondrá de una interfaz de consulta para los operadores y cabildo con control de usuarios y permisos (por ejemplo, MTSA podrá acceder únicamente a los datos concernientes a su servicio).

Web usuario final:

El alcance de este pliego incluye el desarrollo de la página o entorno web de usuario final para la pre-recarga y posterior actualización en el equipamiento a través de listas blancas. Esta web tendrá las siguientes funcionalidades:

o Pasarela de pagos para la autenticación y cobro de los pagos con tarjeta de crédito (contra el banco) o mediante domiciliación (contra el sistema gestor de domiciliaciones que se defina). El usuario final accederá al servicio web a través de un enlace en la web de cada operador y según el origen del acceso, deberá conectar con la pasarela de pagos de uno u otro operador (en el caso de MTSA se usará el modelo de pasarela de pago ya existente y para TITSA se requiere su implementación).

o Sistema web que permita la verificación on-line en la BBDD del SCGB para la confirmación de la viabilidad de la recarga en cuanto a:

▪ Tarjeta existente en la BBDD y en estado activo.

▪ Tarjeta no caducada o en lista negra.

▪ Viabilidad de la recarga en el tipo de tarjeta solicitado.

o Autenticación del usuario mediante introducción de número de chip/número de serie de la tarjeta y datos de identificación del usuario (contraseña/DNI, etc.).

o Verificación de no superar número máximo de recargas por vía telemática (incluyendo las pendientes).

o Consulta de tarjetas y pre-recarga de títulos previa autenticación del usuario.

o Inclusión de tarjeta en lista blanca para su envío a los equipos afectados.

o Obtención de los importes a abonar por el usuario en función de la recarga solicitada.

o Gestión de información sobre tarjetas/títulos/sugerencias, etc.

o Procesos de pre-personalización: solicitud de personalización de tarjeta, adjuntado de documentación necesaria, seguimiento del proceso, etc.

Procesos con otras entidades/sistemas:

o BANCOS: como se ha comentado anteriormente, existirá una pasarela bancaria para los pagos efectuados con tarjeta de crédito en la página web del usuario final.

4.5.3.4. Grupo de explotación de sistema

Estos módulos son los que permiten realizar la explotación de sistema en su “ruta” normal.

Los módulos que reciben y gestionan la información de las transacciones provenientes de los equipos (por ejemplo, transacciones de carga y de validación), ponen esta información a disposición de las funcionalidades puras de explotación, que los utilizan (distribución de ingresos y subvenciones y módulo de consultas e informes).

o Distribución de ingresos y Subvenciones: incluye los cálculos de los importes a compensar a cada parte (operadores de transporte y red de ventas, teniendo en cuenta que cada operador dispone de sus puntos de venta). El SCGB efectuará los cálculos según los algoritmos de compensación definidos por el cabildo, teniendo en cuenta los ingresos percibidos por las ventas, las cancelaciones efectuadas, los transbordos y los importes de subvención que se consideren. Las fórmulas y reglas de cálculo deberán ser de fácil configuración y parametrización.

o Consultas e Informes: se desarrollarán las siguientes funciones sobre datos integrados en el SCGB:

o Informes automáticos: definición de informes de generación automática.

o Informes a demanda: como resultado de una consulta puntual.

o Como ejemplo se realizarán los siguientes (podrá definirse como automático o por consulta puntual):

▪ Relativos a planificación

• Viajes por expedición

• Viajes por franja horaria

• Viajes por parada

• Viajes por línea

• Viajes por operador

• Viajes por modo

• Viajes unietapa

• Viajes multietapa

• Viajes unimodales

• Transbordos

• Viajes intermodales

• Viajes por título

• Viajes por zona tarifaria

▪ Relativos a Liquidaciones y compensaciones:

• Liquidación de conductores

• Viajes por título y zona

• Títulos vendidos por red de ventas

• Títulos consumidos por modo

• Títulos consumidos por operador

• Ventas y recargas por título/zona/operador

• Canjes efectuados por punto/operador

▪ Relativos a la seguridad del sistema:

• Validaciones indebidas (tarjetas anómalas)

• Validaciones fuera de zona

• Validaciones relaciones inexistentes

• Validaciones de viajes multi-etapa.

o Configuración de calendarios para envíos automáticos de informes.

o Vinculación al proceso de mailing para el envío automático de los informes resultantes

El SCGB dispondrá de un interfaz web para la configuración de informes, periodicidades de envío, destinatarios etc., por parte de los operadores/cabildo.

o Gestión de Explotación: Desempeñará las siguientes funciones:

o Reconstrucción del historial de la tarjeta: podrá consultarse el historial de las operaciones recibidas durante la vida de la tarjeta (venta, recargas, validaciones), pudiendo filtrar el resultado por intervalos de tiempo, por operador u otros criterios.

o Detección y reconstrucción de transacciones faltantes: según el algoritmo que se defina, se detectará si faltan transacciones por recibir y podrán reconstruirse dichas transacciones en los casos en los que el citado algoritmo lo defina.

El SCGB dispondrá de una interfaz web para:

• Consultas sobre los historiales de tarjetas con los filtros que se definan (tiempo, operador u otros).

• Alarmas de operaciones faltantes y gestión de éstas (aprobación, reconstrucción de operaciones faltantes, etc.).

4.5.4. Arquitectura física y comunicaciones ‌

A continuación se incluye la arquitectura física y de comunicaciones propuesta para el SCGB. Los sistemas de MTSA y TITSA se representan con una “caja negra” puesto que sus características se incluyen en los apartados específicos de los sistemas de TITSA y MTSA (se incluye una propuesta. Se admitirán variantes por parte del licitante basadas en su experiencia).

Figura 6: Módulos Arquitectura física y de comunicaciones del SCGB.

4.5.5. Funcionalidades a valorar positivamente ‌

• Entorno diferenciado de desarrollo – pruebas que permita testear nuevas funcionalidades antes de ponerlas en producción sin interferir en los procesos en funcionamiento.

• Partes del sistema que puedan funcionar en plataformas diferentes.

4.5.6. Requisitos Técnicos ‌

A continuación se incluyen los requisitos mínimos que deberán cumplir los equipos representados en la arquitectura física y de comunicaciones anterior.

• Arquitectura basada en redundancia de servidores y multiprocesador en cada servidor.

• Canal de fibra redundante.

• Discos propios de operación interna en cluster compartidos (2 discos RAID 1).

• Redundancia de datos en cluster.

• Sistema de Backup de datos y aplicaciones sobre el servidor de respaldo.

• Capacidad de ejecución de cómo mínimo 100 millones de transacciones al año.

• Servidor OLTP (cluster): la base de datos Transaccional es la encargada del trabajo diario en el que se prevén transacciones de muy distinta índole y desde puntos y clientes diversos. Para poder responder tato a una demanda de transacciones individuales como a una demanda masiva de peticiones en colas (procesos Batch), dispondrá de última versión de SQL Server Enterprise Edition y montada sobre un cluster de 2 nodos en modo failover. Se utilizará la funcionalidad de partitioning de la base de datos con objeto de reubicar, de forma automática, los datos en diferentes pilas de discos, actuando de este modo como históricos de la aplicación y permitiendo que el incremento en la cantidad de información no ahogue los procesos de trabajo diario.

Este servidor albergará las aplicaciones necesarias para el procesamiento y carga de las transacciones en la BBDD (por ejemplo, las verificaciones a efectuar sobre las transacciones antes de su carga en la BBDD).

• Servidor Respaldo BD, BI y aplicaciones: Se utilizarán procesos en background para realizar las cargas y preprocesamientos de la Base de Datos de Bussines Intelligence y consultas directas en la que obtener información corporativa eficiente sin afectar al rendimiento de la base de datos OLTP. Así mismo, este servidor albergará todas las aplicaciones no relacionadas con los procesos a efectuar en la gestión transaccional (por ejemplo web services para configuración y parametrización, web services relacionados con la personalización, procesos de gestión del fraude, etc.).

Este servidor incluirá también un FTP para el intercambio de ficheros entre los operadores y el SCGB, de forma que el servidor OLTP lo consultará para descargar los nuevos registros a cargar en la BBDD.

• Servidor de aplicaciones (público): Servidor de aplicaciones que pueda suministrar los Web services y/o funcionalidad necesarios para atender las peticiones de clientes (por ejemplo, consultas de entidades externas a los operadores y cabildo – los accesos de los usuarios finales se gestionan desde los PCGBs- que puedan requerirse). Estará franqueado por un ISA Server con el objetivo de realizar labores de Proxy Inverso para balancear cargas de trabajo soportadas por éstos.

• Clusters: la conexión internodos en los cluster de servidores se efectuará con red de fibra y, por tanto, con switches de fibra en conexión cruzada, requiriendo un HBA por servidor para cada Switch disponible.

• Almacenamiento de datos:

o SAN (cabina de discos): el almacenamiento físico se producirá en cabina de discos externa (SAN) con tecnología de fibra hasta el disco y en formatos RAID 1,5, 5E con el objetivo de obtener un óptimo rendimiento, seguridad y capacidad de crecimiento.

o Capacidad de almacenamiento de hasta 2 Tbytes.

o Capacidad para gestionar los tres servidores que se conectan a la cabina.

• El Hardware de esta estructura debe cumplir ciertos requisitos de estabilidad, alta tolerancia, flexibilidad y eficiencia:

o La arquitectura HW de los servidores será de 64 bits consiguiendo un mayor redireccionamiento de memoria y, donde sea posible, usando SW diseñado de forma nativa para correr en dicha arquitectura.

o La opción ofertada se debe basar en opciones técnicas de futuro, que no queden obsoletas a corto plazo y proporcionen rentabilidad a la inversión realizada.

o El sistema debe ser modular de forma que sea fácil de mantener.

o El sistema debe ser capaz de cubrir futuras funcionalidades mediante la adopción de nuevos módulos, fácil actualización de nuevas versiones que no impliquen un coste excesivo, etc., de forma que no sea necesario un cambio de sistema en el futuro perdiendo la inversión realizada. Es un factor a tener en cuenta el hecho de que el suministrador incorpore los cambios de versión en su oferta de mantenimiento.

o El sistema debe ser portable a entornos diferentes dentro de las líneas básicas de arquitectura definidas, para posibilitar el cambio o ampliación de los equipos sin el condicionante de un proveedor específico. Se valorará positivamente la posibilidad de que haya partes del sistema que puedan funcionar en plataformas diferentes.

4.5.7. Afecciones a fases y etapas ‌

El SCGB debe estar operativo en el inicio del proyecto.

4.6. OTRAS FUNCIONALIDADES Y ELEMENTOS A TENER EN CUENTA ‌

4.6.1. Domiciliación bancaria ‌

Esta funcionalidad se incluye como posibilidad futura, aunque no está prevista en el inicio del proyecto.

Existirá la posibilidad de crear una asociación entre una tarjeta personalizada y una cuenta bancaria. Esta asociación posibilitará el post-pago de compra/uso de títulos.

Aunque están por definir los procedimientos de domiciliación, esta domiciliación funcionará preferentemente por asociación usuario/tarjeta con una cuenta bancaria o una tarjeta bancaria del usuario, y la gestión de impagos y cargos en la cuenta será gestionada por el gestor/ente que se determine, de forma que si la tarjeta tiene activada la domiciliación bancaria, no necesita tener saldo para poder validar.

Así mismo, debe contemplarse la posibilidad de registro de las tarjetas anónimas en el SCGB, de modo que éstas puedan disfrutar de los mismos servicios que las tarjetas personalizadas, incluyendo la opción de domiciliación bancaria.

4.6.2. Auto TOP-UP ‌

Esta funcionalidad se incluye como posibilidad futura, aunque no está prevista en el inicio del proyecto.

Es un mecanismo que permite la recarga automática de un título configurado para auto top- up. Por ejemplo, un título con precio de venta 12€ se cancela hasta que resta menos de una cantidad parametrizable momento en el que la propia canceladora hace una recarga hasta los 12€.

Es un mecanismo que se procesa en la canceladora, pero las transacciones de carga generadas serán enviadas al sistema central donde se hará el cobro a la cuenta bancaria domiciliada o contra la tarjeta bancaria del dueño de la tarjeta recargada.

Solo se podrá activar bajo acuerdo explícito y firmado del usuario. El usuario podrá activar o desactivar el auto top-up en los puestos de venta atendidos o a través de los medios online disponibles.

4.6.3. Teléfono móvil ‌

Esta funcionalidad se incluye como posibilidad futura, aunque no está prevista en el inicio del proyecto.

Los teléfonos móviles podrán ser utilizados como una tarjeta, cancelando títulos en las validadoras y cargándolos en los puntos de ventas de la red sin contacto, o como terminales de recarga de tarjetas sin contacto.

Estas operaciones se realizarán mediante la tecnología NFC, que permite que el móvil sea usado como tarjeta o como lector, por lo que el lector actuaría como equipo para recargar las tarjetas SC de Tenerife.

Los equipos cumplirán los estándares actuales en cuento a protocolos de comunicación y formatos de intercambio de datos (ISO/IEC 18092 y estándares definidos por el NFC Fórum).

Se mantendrá el actual sistema VIA-MOVIL implementado en MTSA y próximo a implementarse en TITSA (información y servicio disponible en la web de MTSA).

4.6.4. Recarga en cajeros bancarios ‌

Esta funcionalidad se incluye como posibilidad futura, aunque no está prevista en el inicio del proyecto.

La red de ventas del sistema sin contacto podrá ser extendida a los cajeros bancarios.

Estas recargas se efectuarán mediante la interface sin contacto de la tarjeta SC de Tenerife en cajeros bancarios adaptados para sin contacto.

4.6.5. Sistemas de conteo ‌

Esta funcionalidad se incluye como posibilidad futura, aunque no está prevista en el inicio del proyecto.

Aunque su suministro no es objeto de este contrato, los sistemas embarcados deberán prever la posibilidad, disponiendo de los puertos libres adecuados, para la instalación de sistemas de conteo en los vehículos para permitir obtener la ocupación de dichos vehículos.

4.6.6. Validación en salida ‌

En aquellas líneas en las que no se aplique tarifa plana, se instalarán validadoras para validación en salida, de forma que se puedan establecer mecanismos de control para el cobro de la tarifa al usuario según su destino.

El mecanismo de control a implementar consistirá en la validación a la entrada y validación a la salida del viaje. (Sistema cerrado-cerrado) de modo que:

o El usuario valida en la entrada y se le descuenta el máximo importe teniendo en cuenta la zona de validación de inicio y los xxxxxx xx xxxx máximos que puede efectuar.

o Cuando el usuario sale, valida en el punto de salida, cerrando así el viaje y descontándole/devolviéndole la diferencia entre lo que ha pagado en la entrada y el trayecto realizado.

o Podrá permitirse saldo negativo si el importe máximo a descontar es mayor que el que se tiene en la tarjeta, teniendo en cuenta las limitaciones por título, por número de viajeros, etc. que se determinen.

Todas las guaguas, independientemente de si están asignados a líneas urbanas con tarifa plana o no, dispondrán de la preinstalación para validadoras de salida.

4.6.7. Integraciones con otros operadores ‌

Esta funcionalidad se incluye como posibilidad futura, aunque no está prevista en el inicio del proyecto.

Se prevé que en un futuro próximo se puedan integrar otros operadores de transporte, modificando la definición de transbordo.

Está prevista en la implementación del SC la integración de algunos trayectos de taxi con los transportes actuales (guaguas y tranvía). Para ello, los taxis tendrán capacidad de ejecutar cancelaciones a bordo de forma a que los trayectos de taxi sean reconocidos en guaguas o tranvías para implementación de trasbordos.

El sistema deberá permitir incorporar a otros operadores que puedan sumarse en el futuro.

4.6.8. Tarjeta bancaria-EMV con sin contacto.‌

Cobro con tarjeta EMV con y sin contacto.

En el caso de las máquinas expendedoras, en las que pueda efectuarse pago mediante tarjeta bancaria, se requerirá homologación EMV con contacto y se valorará positivamente que estén preparadas para la homologación de EMV sin contacto en el equipo o mediante módulo externo para permitir el pago con tarjeta bancaria sin contacto del billete sencillo.

Preparación Validación EMV sin contacto.

Se desea que el sistema esté diseñado para que el futuro, sea posible aceptar tarjetas EMV sin contacto para acceder al transporte público lo que se concreta en los siguientes requerimientos específicos:

• Esta actualización no debe hacer obsoleto ninguno de los suministros realizados tanto sean hardware como de comunicaciones o servidores y sistemas.

• Se asume que posiblemente sea necesario el suministro de nuevos elementos para cumplir con los requerimientos, tanto como añadido a equipamientos existentes como equipo adicional independiente, siempre que se mantenga dentro de un coste coherente.

• Se asume que será necesario realizar algunas actualizaciones y suministro de elementos adicionales software.

• Este requerimiento se debe realizar a nivel de unidad de sistema embarcado (autobús o coche de tranvía) en un número de unidades coherentes, estimado en que debe haber al menos un 50% de puntos de validación con esta característica.

• Esto es aplicable a TODO EL SISTEMA, y no solo a los equipos.

En la memoria técnica se debe explicar exactamente la solución propuesta para esta actualización, y enumerar los suministros y elementos necesarios.

En cada apartado se recordará esta característica para que el ofertante tenga plena constancia de este requerimiento.

No se exige la validación sin contacto en el equipamiento

En referencia al equipamiento de validación, se valorará positivamente la aceptación del pago sin contacto, pudiendo establecerse diferentes niveles para éste:

o Sólo pago: se emite un billete sencillo con el procedimiento habitual pero el pago se produce con tarjeta bancaria SC en vez de en efectivo.

o Validación con selección de zona en el móvil o en la validadora: puesto que no se tiene registro de las validaciones con tarjetas bancarias, no se puede aplicar importe máximo y ajustar en la salida puesto que no puede accederse a la información de la entrada. Es por eso que en la entrada tendría que tenerse un sistema de selección.

El modelo final a implementar dependerá del estado del arte relacionado con el pago con tarjeta bancaria.

5. DESCRIPCIÓN DEL SISTEMA SIN CONTACTO DE XXXXX x

5.1. DESCRIPCIÓN GENERAL DEL NUEVO SISTEMA SC EN TITSA ‌

Debe tenerse en cuenta que al ser una evolución del sistema de billetaje actual, el futuro sistema debe cubrir cualquier otra funcionalidad no detallada en este documento y que esté implementada en el sistema actual que TITSA tiene en funcionamiento para su sistema de billetaje sobre tecnología magnética.

Es objeto de este pliego el suministro tanto del sistema de billetaje que se describe a continuación como de un nuevo SAE descrito más adelante que será implementado en una fase posterior.

La arquitectura prevista para TITSA es la siguiente (es posible que las funcionalidades no obligatorias no estén representadas en el esquema):

Figura 7: Arquitectura final prevista para TITSA. Datos Sin CONTACTO.

Esta arquitectura indica las comunicaciones desde el PCGB y SCGB a los equipos y de éstos al PCGB y el SCGB para los datos SIN CONTACTO en el escenario final en el que no se gestiona

equipamiento ni datos xx xxxxx magnética. Así mismo, se detallan las comunicaciones desde el PCGB al SCGB.

En el esquema anterior se incluye la configuración con el nuevo SAE, descrito más adelante, aunque este podrá ser implementado en etapas posteriores.

Sin embargo, existirá un periodo de migración intermedio en el que el sistema sin contacto convivirá con el magnético, de forma que se gestionarán ambos sistemas según el siguiente esquema:

Figura 8: Arquitectura de migración para TITSA.

Como puede observarse en el esquema anterior, se mantiene la gestión de los datos provenientes del sistema de billetaje xx Xxxxx Magnética con el actual Sistema central de TITSA PCGB, teniendo en cuenta que únicamente se gestiona la recepción de los datos de BM de las transacciones provenientes de los equipos, y no se gestionan ficheros de parametrización desde el PCGB a los equipos xx Xxxxx Magnética, por lo que en el periodo de migración no se podrán modificar parametrizaciones / configuraciones. Debe tenerse en cuenta que actualmente se dan las siguientes circunstancias a efectos del equipamiento magnético:

Equipamiento	PCGB ahora	PCGB migración	Comentarios
Estación-Punto Venta	Se envían ficheros binarios (parámetros y operaciones)	Recibe los datos de BM como hasta ahora.
Kioscos	No recibe nada, puesto que se les entregan bonos pre-cargados.	No hay periodo de convivencia BM-SC en cuanto a los datos a procesar.
Taxi	Ficheros binarios (parámetros y operaciones)	No se prevé convivencia BM-SC. Se sustituye la BM por el SC.
Guagua	Ficheros binarios (parámetros y operaciones)	Recibirá los datos de BM al nuevo SCGB, junto con el volcado de datos de SC y se extraerán para redirigir su procesado al actual PCGB.	El adjudicatario detallará la solución propuesta para el tratamiento de los datos de BM provenientes del pupitre.
Park & Ride	Ficheros binarios (parámetros y operaciones)	Recibirá los datos de BM como hasta hora

El esquema propuesto mantiene el funcionamiento del PCGB para BM y en paralelo el nuevo PCGB y el SCGB para SC (las parametrizaciones y gestiones de alarmas de los equipos serán gestionadas por el PCGB). Una vez finalizada la migración desaparece el actual PCGB para ser sustituido por completo por el nuevo PCGB, ya que no existirán más datos provenientes del sistema xx xxxxx magnética. Esto se ha diseñado así para evitar diseñar en el nuevo sistema central todos los procesos relacionados con la Banda magnética (tratamiento de los registros específicos, títulos, liquidaciones posteriores, etc., que ya está gestionando el PCGB). Además, los cálculos y procesos de adquisición tienen en cuenta datos históricos que ya tienen los sistemas actuales.

A continuación se describen las funcionalidades y requisitos técnicos exigibles a cada uno de los elementos del sistema a suministrar.

En el caso del Park & Ride deberá desarrollarse el protocolo de comunicación con el cajero automático en el caso de la conexión con este, así como la aplicación de simulación xx xxxxxx que reside en el PC y la comunicación con este.

Respecto al periodo de migración, donde el nuevo pupitre coexistirá con el SAE actual, no se requerirá conexión con el SAE, de forma que el pupitre deberá funcionar de modo autónomo, posicionándose a partir del módulo GPS del que dispone.

5.2. REQUERIMIENTOS ESPECÍFICOS SOBRE LAS INSTALACIONES ‌

Con objeto de facilitar y asegurar la correcta ejecución de los trabajos de instalación y cableado de los vehículos, el adjudicatario:

• Efectuará una visita a las instalaciones del carrocero en cada nueva incorporación xx xxxxx durante la ejecución del proyecto (2014 y 2015) para certificar la instalación completa de 1 guagua.

Previamente a dicha visita el adjudicatario deberá suministrar a TITSA las especificaciones para llevar a cabo la pre-instalación.

Se espera incorporar a la flota de TITSA entre 40 y 60 guaguas nuevas cada año.

• El adjudicatario deberá efectuar una visita a TITSA en sus instalaciones de Tenerife antes de planificar las tareas de instalación y cableado de las guaguas para verificar las características de la instalación (y pre-instalación) del sistema SAE y de Billetaje actual. TITSA pondrá a disposición del adjudicatario personal de TITSA adecuado para acompañarlo y proporcionar todas las aclaraciones necesarias.

TITSA proporcionará previamente al adjudicatario las especificaciones técnicas para la pre- instalación del sistema actual.

El adjudicatario deberá intentar APROVECHAR AL MÁXIMO la pre-instalación existentes para el sistema SAE y de Billetaje actuales.

5.3. PUPITRE ‌

5.3.1. Descripción ‌

El pupitre es el interfaz con el conductor para el control del equipamiento embarcado y el interfaz para el usuario para funcionar como punto de validación.

Además puede emitir billetes ocasionales y billetes de incidencia en el caso de tarjetas averiadas (dispone de impresora normal y de código xx xxxxxx).

El pupitre es también el equipo que se comunica con el SCGB para el envío de los datos de las transacciones efectuadas a bordo (cancelaciones, recargas, billetes de incidencia, anulaciones, etc.), y con el PCGB para enviar las alarmas de funcionamiento y recibir las parametrizaciones/listas/configuraciones enviadas por el PCGB.

Se comunica también con el nuevo SAE (ver apartado de Sistema de Ayuda a la Explotación de TITSA) para el intercambio de datos de posicionamiento, gestión xx xxxxx, sincronización horaria, datos de ocupación del vehículo, etc.

5.3.2. Funciones ‌

- Lectura y grabación de tarjetas sin contacto según los procedimientos que se especifiquen para las funciones de:

o Validación: validación de tarjetas sin contacto según los procedimientos que se definan (lecturas y grabaciones necesarias, tratamiento de tarifas preferenciales, posibilidad de validaciones múltiples con tarjetas preferenciales - primera validación con la tarifa subvencionada y las siguientes con tarifa general -, previsión de tratamiento de los diferentes tipos de títulos descritos anteriormente: títulos con saldo de viajes, con saldo monedero, temporales, etc.).

o Recuperación de tarjetas que no han finalizado correctamente el proceso de grabación según los procedimientos que se definan si así fuese necesario.

o Gestión de incidencias en el autobús:

▪ Proceso de gestión de incidencias para usuarios que acceden al autobús con una tarjeta que no funciona: ingreso de número de tarjeta en la consola (o mediante lectura de código xx xxxxxx en la tarjeta), cálculo de número de billete de incidencia.

▪ Venta de billetes de incidencia y emisión de recibo (la impresión del billete de incidencia incluye impresión de código xx xxxxxx con los datos del ticket de incidencia para poder efectuar una lectura automática posteriormente).

o Venta de billetes ocasionales y emisión de recibo.

o Anulaciones.

o Otros.

- Inicio de sesión: para el inicio de sesión del equipo se requerirá la identificación del operador, inspector o personal de mantenimiento según el modo en el que se arranque el equipo. Dicha identificación podrá efectuarse mediante tarjeta de identificación sin contacto o bien mediante código identificativo del usuario.

- Modos de operación:

o Validación: es el modo normal del equipo, en el que al acercar una tarjeta se efectúa la validación del viaje, de forma que se efectúan las lecturas necesarias para los procesos lógicos de validación y posterior grabación de datos en la tarjeta (saldo restante, ruta- parada-autobús en el que se valida, etc.).

o Consulta: existirá una tecla de función que permitirá que el equipo entre en modo consulta. Dicho modo permitirá por defecto visualizar el saldo de los títulos residentes en la tarjeta, así como la fecha de caducidad de ésta y día y hora actual. Existirá la posibilidad de acceder a un menú más extenso donde se permita acceder a otros datos de la tarjeta (histórico de validaciones y de cargas y otros que se definan). Podrá emitirse un recibo o comprobante con la información de la consulta, con posibilidad de activación de esta función según criterio de la empresa gestora.

o Supervisión y mantenimiento: este modo sólo es accesible previa identificación del personal de supervisión o mantenimiento mediante tarjeta sin contacto del empleado correspondiente o introducción del código de identificación de éste y permite acceder a menús de funcionamiento del equipo para funciones de mantenimiento.

o Puesta en marcha: incluye la verificación de la existencia de nuevas configuraciones/parametrizaciones para su actualización.

o Bloqueo: el equipo podrá bloquearse, para evitar manipulaciones, por ejemplo, durante un tiempo de ausencia del operador.

- Cambio de tarifa y parada manual: Permitirá la selección por el conductor de la tarifa para cada trayecto, para la parada en curso ya sea automatizada por SAE/GPS del pupitre o manualmente por teclas para selección de la parada destino.

Se tendrá en cuenta que en los casos en los que una guagua cambie de tarifa plana a tarifa origen-destino o bien la validadora de salida no se encuentre operativa o no disponga de ella, el pupitre debe pasar automáticamente a gestionar saldo máximo en entrada o solicitar destino si no se dispone de importe máximo.

- Billete complementario: cuando se detecte que un usuario no tiene saldo suficiente para el viaje (incluso indicando el destino y aplicando la tarifa correspondiente al trayecto indicado), el pupitre permitirá la emisión de billete complementario por el importe restante (importe trayecto

– saldo disponible), de modo que pueda ser pagado en efectivo.

- Comunicaciones:

o Pupitre-sistema central (SCGB): El pupitre dispondrá de conexión a un módulo GPRS/GSM/3G integrado en el equipo que permita la comunicación on-line de todas las transacciones (validaciones, operaciones de listas, venta billetes ocasionales y de incidencia, etc.) al Sistema Central SCGB (tanto de los datos de operaciones en el pupitre como de las efectuadas en las canceladoras colgadas de él), aunque el equipo tendrá la capacidad de almacenar el número de transacciones necesarias para efectuar las verificaciones que se requieran (al menos un mes). Las transacciones serán enviadas en el formato que se defina (JSON, XML, Binario, CSV, etc.). La contratación del GPRS con el operador de telefonía y la instalación de la tarjeta SIM será realizada por TITSA. Las operaciones serán enviadas por GPRS al SCGB, aunque si se requieren volcados de información fallidos podrán volcarse al concentrador de estación vía WIFI o manualmente para su reenvío al SCGB.

o Pupitre – PCGB: para los envíos de alarmas de equipamiento.

o PCGB-pupitre: para la recepción de nuevas parametrizaciones/listas del PCGB.

o Pupitre-PCGB actual: en la etapa de migración, el pupitre deberá comunicarse con el PCGB antiguo y enviar los datos de las operaciones efectuadas con BM, en el mismo formato utilizado actualmente.

o El pupitre dispondrá de conexión a un módulo WIFI, de modo que pueda parametrizarse el envío de los datos de operaciones desde el pupitre al PCGB por canal GPRS, WIFI o mediante un reparto de ambos según los datos que se parametricen por canal. Será parametrizable el orden de preferencia de los canales y su reparto de forma remota desde el sistema central PCGB y localmente en el pupitre usando el terminal de mantenimiento.

o El pupitre dispondrá también de dispositivo USB (formato llave o similar) para descarga manual de datos, debiendo indicar en la oferta el funcionamiento del mecanismo manual propuesto.

o El equipo será capaz de efectuar la encriptación de los datos transmitidos y firma digital (o algoritmo Hash equivalente) en el formato que se defina (encriptación DES/TDES, AES, firma digital RSA u otros).

o Pupitre-Validadora de ERG xx Xxxxx magnética: capacidad para comunicarse con la validadora actual xx xxxxx magnética (ver apartado canceladoras).

o El pupitre estará conectado al nuevo SAE embarcado (ver apartado “Sistema de ayuda a la explotación de TITSA). Como mínimo se requerirán las siguientes comunicaciones:

▪ SAE-Pupitre: para completar los registros de las cancelaciones con los datos comunicados por el SAE.

▪ Pupitre-SAE: Transmisión de los datos referentes a la ocupación del vehículo.

Además, el pupitre deberá soportar en funcionamiento en modo degradado (sin conexión al SAE) la gestión de intercambio de tarifas, datos de facturación, sincronización de fecha/hora, carga de software de los EEM-Equipos embarcados de billetaje) y en general todas sus funcionalidades sin necesidad de comunicar con el SAE.

o El pupitre deberá tener capacidad para comunicarse con 4 canceladoras (2 de entrada y 2 de salida). El protocolo de comunicaciones entre el pupitre y la validadora del sistema sin contacto, deberá ser entregado a TITSA para evitar dependencias con el proveedor en el futuro.

o El equipo estará preparado para la posible incorporación futura de sistemas de conteo embarcados.

o El equipo estará preparado para poder ser conectado en el futuro a un módulo de comunicaciones WIMAX, de tal forma que sea posible la comunicación del pupitre con los Sistemas Centrales a través de una red WIMAX.

- Capacidad de activar la validadora de salida cuando se produce la apertura de puertas o cambio xx xxxxxx para posibles mecanismos antifraude en salida. Si no existe comunicación con el pupitre funcionará en modo activo.

- Parametrización: el equipo deberá tener la capacidad de:

o Recibir y procesar archivos de parametrización enviados desde el nuevo PCGB:

▪ Rutas, paradas, tarifas, títulos, etc.

▪ Gestión de alarmas y funcionamiento.

▪ Otros.

o Recibir actualizaciones de software en remoto mediante telecarga.

- Gestión de claves y estructuras de datos: ver apartado “Gestión Claves y estructuras de datos” dentro del punto “Detalle funciones y requisitos técnicos”.

- Gestión de listas: Ver apartado “Gestión de listas” dentro del punto “Detalle funciones y requisitos técnicos".

- Anulación de la última operación de cobro: el equipo deberá poder realizar la anulación de la última operación de cobro efectuada mediante petición del conductor, de modo que la tarjeta quede en el estado en el que estaba con anterioridad a la última validación, pudiendo establecerse procesos de grabación de histórico de la anulación realizada, aumento del número de transacción de la tarjeta, así como limitaciones como no haber efectuado ninguna operación intermedia o limitar el tiempo transcurrido desde la validación que se quiere anular y la anulación.

- El pupitre dispondrá de indicadores luminosos (al menos uno rojo y uno verde) y sonoros (al menos con opciones de sonido continuo y discontinuo tiempo de pitido y frecuencias parametrizables) para indicar operación correcta, incorrecta u otros eventos.

- El pupitre podrá emitir mensajes de texto a través de la pantalla (deben existir como mínimo dos pantallas, una para el operador y otra para el usuario):

o Se mostrará al operador de forma predefinida la ruta, parada, fecha y hora.

o Se mostrarán al usuario los mensajes que se definan para cada uno de los eventos que puedan darse (por ejemplo, validación correcta con monedero y saldo viajes restante, tarjeta no válida, etc.).

o El texto de los mensajes existentes será parametrizable.

- El pupitre deberá poder emitir un comprobante con la hoja de liquidación al final del servicio. Dicha hoja de liquidación incluirá la impresión de código xx xxxxxx para lectura automática mediante lector de código xx xxxxxx de la información más relevante. Esta información se facilitará al adjudicatario.

- El pupitre dispondrá de un lector de código xx xxxxxx 2D para lectura de número de chip impreso en las tarjetas. Se valorará positivamente que este lector esté integrado en el equipo. El pupitre será capaz de recibir e interpretar la lectura del código xx xxxxxx.

- El pupitre dispondrá de impresora de código xx xxxxxx 2D para la impresión de hoja de liquidación y billetes de incidencia.

- Alarmas: la consola deberá generar alarmas al conductor para eventos como falta de papel o próximo a agotarse, actualización de los programas en proceso, fallo de comunicación con alguno de los elementos (canceladoras, etc.), fallo de módulo GPRS/GSM/3G o de otro elemento del equipo, etc. El mensaje de alarma deberá mostrarse en continuo hasta que desaparezca el motivo de la alarma.

- Lector y módulo XXX: ver apartados “Módulos XXX” y “Lector/ grabador sin contacto”.

- El pupitre deberá también cumplir con cualquiera de las funciones que cubre el pupitre embarcado actual en explotación.

- El pupitre incluirá un módulo de localización tipo GPS integrado para definir el xxxxx xx xxxxxx independientemente del SAE.

- Preparación para validación de tarjetas EMV sin contacto: Ver punto 4.6.8 “Tarjeta bancaria- EMV con y sin contacto”.

- Ver apartado de “Teléfono móvil” para implicaciones en el equipo.

5.3.3. Funcionalidades a valorar positivamente ‌

- Criptoprocesador adicional al módulo XXX (al menos para 3DES/AES/RSA) para poder realizar las encriptaciones necesarias para ejecutar transacciones en tiempos óptimos.

- Capacidad de emitir mensajes de voz pre-grabados en el equipo. Se valorará positivamente que incluya sintetizador de voz.

- Se valorará positivamente la integración del lector de código xx xxxxxx 2D en el equipo.

- Se valorará positivamente la oferta de consola de SAE-pupitre en un mismo equipo.

5.3.4. Requisitos Técnicos ‌

Las especificaciones que se incluyen a continuación responden a las necesarias para el cumplimiento de las funciones detalladas anteriormente (se incluyen los requisitos técnicos tanto de las funcionalidades obligatorias como las valorables). El pupitre deberá contar con todos los elementos necesarios para su cumplimiento.

El pupitre deberá disponer al menos de:

- Lector/grabador de tarjetas sin contacto, con las características técnicas especificadas más adelante para el lector sin contacto (ver apartado lector/ grabador sin contacto).

- Impresora térmica: Ver apartado “Detalle funciones y requisitos técnicos”, dentro del punto “Requisitos técnicos impresora térmica”.

- Pantallas alfanuméricas de tecnología LCD para operador y pasajero, con suficiente tamaño y buena visibilidad a cualquier hora. Estarán dotados de iluminación regulable. Deberá permitir la visualización de pictogramas y logos y tener como mínimo las siguientes características técnicas:

o Mínimo de dos líneas de 16 caracteres.

o Tamaño del carácter superior a 5mm.

o Retroiluminación.

x Xxxxxx de visión amplio, superior a 50º.

o Visibilidad con incidencia solar directa.

o Intensidad luminosa de las pantallas: Mínimo 300 NITS. Adicionalmente se recomiendan las siguientes características:

o Tamaño del carácter: el mayor posible.

o Capacidad gráfica.

o Capacidad de color.

- Teclado multifuncional programable que permita al operador introducir datos en el sistema, responder a solicitudes del mismo, expender billetes y en general realizar cualquier función definida en el sistema.

o Se preverán teclas de función para la entrada directa, y mediante pulsación simple, de los datos más frecuentes, con objeto de agilizar los procesos.

o Permitirá la introducción de letras y números.

- Capacidad de proceso y almacenamiento suficientes para garantizar las necesidades requeridas, debiendo justificarse técnicamente la validez de las citadas características para las funciones requeridas en el presente pliego.

- Interfaces necesarias para comunicarse con el resto de equipos (validadora de tarjetas sin contacto, validadora de BM, SAE y otros equipos embarcados). Deberá disponerse de suficientes puertos libres para prever en el futuro la conexión con otros sistemas que puedan instalarse para realizar otras funciones. Como mínimo deberá disponer de:

o Tres puertos RS485/232/422 independientes

o Un puerto USB

o Una salida Ethernet Gigabit (TCP/IP)

o Conexión módulo GPRS/GSM/3G/UMTS

o Conexión con módulo GPS o GPS interno con salida de antena externa.

o Conexión WIFI (802.11 n)

o 8 GPIOS: 4 salidas colector abierto + 4 entradas optoacopladas

- El pupitre deberá tener comunicación directa con las antenas WIFI y GPRS.

- Módulo GPS: módulo GPS independiente del SAE para comunicar la posición al pupitre, que tendrá las siguientes características mínimas:

o Precisión: 10m (95%)

o GPS Signal L1, C/A code

o Canales: 32

o Sensibilidad -165dBw

o WAAS Si

o DGPS Sí

o Tiempos de encendido:

▪ Arranque en caliente <10s

▪ Arranque templado <40s

▪ Arranque en frío <50s

o Actualización

▪ Readquisicion <0.1s

▪ Actualización <1s

▪ Velocidad <0.1 m/sec

▪ Aceleración Máx- 4G

o Interfaces

▪ R232 o USB

o Robustez

▪ Voltaje de Entrada 4,5-5,5 Vcc

▪ Rango temperaturas: -20°C +60°C

▪ Para los requisitos de vibración, temperatura, humedad, estanqueidad y robustez de envolventes, ver punto Reglamentación y normativa.

- Procesador criptográfico (incluido como funcionalidad a valorar positivamente): capacidad del lector (y criptoprocesador en su caso) para encriptación como mínimo en:

o DES/3DES: : clave 168 bits

o RSA: clave mínimo 2048 bits.

o AES: clave 128 y 256 bits.

El proveedor deberá especificar cuantos parámetros sean necesarios para poder encriptar/desencriptar con herramientas estándar (ejemplo: openssl).

- Módulo XXX, con las características técnicas referidas en el punto “Módulos XXX”.

- Batería que evite la pérdida de información almacenada.

- Zumbador capaz de generar sonidos: Ver apartado “Detalle funciones y requisitos técnicos”, en el punto “Requisitos técnicos zumbador”.

- Leds de iluminación: Ver apartado “Detalle funciones y requisitos técnicos”, en el punto “Requisitos técnicos leds iluminación”.

- Carcasa de alta resistencia, con diseño ergonómico, ausencia de aristas, y adaptado a la configuración del puesto del operador en los vehículos, para un uso cómodo tanto por aquel, como por parte de los usuarios.

- Lector de código xx xxxxxx (ver apartado “Detalle funciones y requisitos técnicos”, en el punto “Requisitos técnicos lector código xx xxxxxx 2D”).

- Cuando el autobús esté estacionado o fuera de servicio el consumo eléctrico deberá ser mínimo o nulo. Para ello se dispondrá de un sistema automático y manual de encendido/apagado controlado.

- Cumplirá los requisitos de robustez habituales apartado “Detalle funciones y requisitos técnicos”, en el punto “Requisitos técnicos robustez y medioambientales” para equipos embarcados.

- Otros parámetros aplicables:

o Tensión de alimentación 12-30V

o Deberán disponer de fuente de alimentación específicas.

o Deberán estar protegidos contra sobretensiones y efectos radioeléctricos generados por otros elementos embarcados.

5.3.5. Afecciones a Fases y etapas ‌

- Inicialmente, en la etapa de migración (ver apartado Plan de implantación), el pupitre deberá comunicarse con la validadora magnética y la validadora sin contacto (ver opciones en el apartado de validadoras), para posteriormente comunicarse únicamente con las validadoras sin contacto.

- En la etapa de migración, convivirán los sistemas centrales nuevo PCGB y SCGB para Sin Contacto y PCGB para Banda Magnética, de forma que el pupitre deberá recibir parametrizaciones y configuraciones para el sistema sin contacto desde el nuevo PCGB, así como para el envío de las transacciones efectuadas (según las especificaciones que se definan para el nuevo sistema SCGB y en el caso del PCGB actual con el mismo formato actual).

- Inicialmente el sistema tarifario podrá ser a semejanza del actual, kilométrico, con selección de origen-destino, aunque en fases posteriores podrá migrar a zonal (saltos zonales).

- En la etapa de migración no se requiere la comunicación con el SAE actual (el pupitre deberá funcionar de modo autónomo, mediante posicionamiento y Fecha/hora a partir de su módulo GPS). Posteriormente el pupitre se comunicará con el nuevo SAE según se ha indicado en el apartado de funcionalidades.

- Deberá tenerse en cuenta que no existe espacio en los vehículos para la instalación de dos consolas SAE en la etapa de migración.

5.4. VALIDADORA DEPENDIENTE ‌

En el escenario final, las validadoras sin contacto y el pupitre estarán integrados con el nuevo SAE como se observa en la figura “Arquitectura prevista para TITSA” incluida anteriormente.

A continuación se describen las funciones y características técnicas para el caso de la validadora dependiente que deberá ser instalada en las guaguas.

5.4.1. Descripción ‌

La validadora funciona como un segundo punto de validación y depende del pupitre, ya que necesita que este último le pase los datos de configuración, parametrización, etc. La validadora se conecta con el pupitre mediante protocolo TCP/IP.

Está prevista la validación en salida en los trayectos con tarifa variable en el recorrido, y no fuera de este ámbito, aunque las guaguas dispondrán de la instalación de cableado necesaria para la conexión de validadoras de salida en todos los casos.

5.4.2. Funciones ‌

- Lectura y grabación de tarjetas sin contacto según los procedimientos que se especifiquen para las funciones de validación, recuperación, anulación, etc., de la misma forma indicada para el pupitre (exceptuando gestión de incidencias y emisión de billetes ocasionales).

- Capacidad de procesado y almacenamiento suficiente para soportar los requisitos especificados en este documento.

- Modos de operación: Validación, supervisión y mantenimiento y bloqueo, de la misma forma en que se han definido estos modos para el pupitre. La validadora no precisa de la intervención del operador para efectuar normalmente las transacciones con las tarjetas de los usuarios.

- Gestión de claves y estructuras de datos de las tarjetas: Ver apartado “Gestión de claves y estructuras de datos” dentro del punto “Detalle funciones y requisitos técnicos”.

- Gestión de listas (ver apartado “Gestión de listas” en el punto “Detalle funciones y requisitos técnicos”).

- La validadora dispondrá de indicadores luminosos (al menos uno rojo y uno verde) y sonoros (al menos con opciones de sonido continuo y discontinuo de tiempo de pitido y frecuencias parametrizables) para indicar operación correcta, incorrecta u otros eventos.

- La validadora podrá emitir mensajes de texto a través de la pantalla de usuario (se mostrarán al usuario los mensajes que se definan para cada uno de los eventos que puedan darse: por ejemplo, validación correcta con monedero y saldo viajes restante, tarjeta no válida, etc.).

- Deberán estar adaptadas para colectivos con visión reducida (colores, botones, textos, etc.)

- Lector sin contacto y módulos XXX: (ver apartados “Módulo XXX” y “Lector / grabador sin contacto”).

- Comunicaciones:

▪ Canceladora-pupitre: La canceladora deberá conectarse al pupitre para obtener los datos de posicionamiento, configuraciones, activaciones, bloqueos, parada en trayecto interurbano, envío de operaciones efectuadas al pupitre, etc. Deberá aprovecharse para la conexión canceladora-pupitre la instalación actual en la medida de lo posible, teniendo en cuenta que se migrará a IP.

▪ La canceladora dispondrá también de dispositivo USB (formato llave o similar) para descarga manual de datos, debiendo indicar en la oferta el funcionamiento del mecanismo manual propuesto.

▪ El equipo será capaz de efectuar la encriptación de los datos transmitidos y firma digital (o algoritmo Hash equivalente) en el formato que se defina (encriptación DES/TDES, AES, firma digital RSA u otros).

▪ Sin conexión con el pupitre, la canceladora quedará inoperativa.

▪ Será posible que la canceladora de salida reciba del pupitre la orden de activación ligada a la apertura de puertas o cambio xx xxxxxx, manteniéndose desactivada el resto del tiempo. Si no existe comunicación con el pupitre funcionará en modo activo.

▪ El equipo tendrá los interfaces necesarios para comunicarse con el resto de equipos.

▪ Preparación para validación de tarjetas EMV sin contacto: Ver punto 4.6.8 “Tarjeta bancaria-EMV con y sin contacto”.

- Ver apartado de “Teléfono móvil” para implicaciones en el equipo.

5.4.3. Funcionalidades a valorar positivamente ‌

- Criptoprocesador adicional al módulo XXX (al menos para 3DES/AES/RSA) para poder realizar las encriptaciones necesarias para ejecutar transacciones en tiempos óptimos.

- Capacidad de emitir mensajes de voz pre-grabados en el equipo. Se valorará positivamente que incluya sintetizador de voz.

5.4.4. Requisitos técnicos ‌

Las especificaciones que se incluyen a continuación responden a las necesarias para el cumplimiento de las funciones detalladas anteriormente (se incluyen los requisitos técnicos tanto de las funcionalidades obligatorias como las valorables). La validadora deberá contar con todos los elementos necesarios para su cumplimiento. Deberá disponer al menos de:

- Lector/grabador de tarjetas sin contacto, con las características técnicas detalladas en el apartado “lector sin contacto”.

- XXX: ver apartado “Módulos XXX”.

- Procesador criptográfico (incluido como funcionalidad a valorar positivamente): capacidad del lector (y criptoprocesador en su caso) para encriptación como mínimo en:

▪ DES/3DES: : clave 168 bits

▪ RSA: clave mínimo 2048 bits.

▪ AES: clave 256 bits.

El proveedor deberá especificar cuantos parámetros sean necesarios para poder encriptar/desencriptar con herramientas estándar (ejemplo: openssl).

- Pantalla alfanumérica de tecnología LCD para pasajero, con suficiente tamaño y buena visibilidad a cualquier hora. Estarán dotados de iluminación regulable. Deberá permitir la visualización de pictogramas y logos y tener como mínimo las siguientes características técnicas:

▪ Mínimo de dos líneas de 16 caracteres.

▪ Tamaño del carácter superior a 5mm.

▪ Retroiluminación.

▪ Ángulo de visión amplio, superior a 50º.

▪ Visibilidad con incidencia solar directa.

▪ Intensidad luminosa: Mínimo 300 NITS. Adicionalmente se recomiendan las siguientes características:

▪ Tamaño del carácter: el mayor posible.

▪ Capacidad gráfica.

▪ Capacidad de color.

- Capacidad de proceso y almacenamiento suficientes para garantizar las necesidades requeridas

- Interfaces necesarios para comunicarse con el resto de equipos.

- Batería que evite la pérdida de información almacenada.

- Zumbador (ver apartado “Detalle funciones y requisitos técnicos”, en el punto “Requisitos técnicos zumbador”).

- Leds de iluminación (ver apartado “Detalle funciones y requisitos técnicos”, en el punto “Requisitos técnicos leds iluminación”).

- Soporte fijo, preferiblemente xx xxxxx inoxidable, de conexión con un sistema de anclaje seguro y fiable, en especial en lo que respecta a los conectores eléctricos y electrónicos. El equipo se deberá colocar de tal forma que reduzca la obstrucción al paso, dispondrá de protección antivandálica y se podrá fijar en barras horizontales o verticales así como sobre áreas planas verticales (pared). No se podrán desmontar sin el empleo de herramientas específicas de seguridad.

- Carcasa de alta resistencia, con diseño ergonómico, ausencia de aristas, con objeto de facilitar la circulación de los usuarios en el interior del autobús.

- Cumplirá los requisitos de robustez habituales según apartado “Detalle funciones y requisitos técnicos”, en el punto “Requisitos técnicos robustez y medioambientales” para equipos embarcados.

- Deberá en general estar diseñada para reducir el vandalismo y minimizar su impacto en la operación.

- Debido a que la validadora tiene que ser válida para operar en entorno ferroviario la validadora deberá además cumplir con algunos requisitos adicionales que se describen en el correspondiente apartado de las validadoras de MTSA.

- Otros parámetros de funcionamiento:

• Tensión de alimentación 12-30V

• Deberán disponer de fuente de alimentación específicas.

• Deberán estar protegidos contra sobretensiones y efectos radioeléctricos generados por otros elementos embarcados.

5.4.5. Afecciones a fases y etapas ‌

No tiene.

5.5. COMUNICACIONES ‌

Ver apartado Descripción general del nuevo sistema SC en TITSA, donde se incluyen los esquemas de comunicaciones.

5.6. CONCENTRADORES EN COCHERAS ‌

Actualmente toda la información generada por el equipamiento embarcado para el sistema actual de BM se vuelca en los concentradores de cocheras para posteriormente gestionar estos datos en el PCGB.

Durante la etapa de migración, los datos del sistema magnético se seguirán volcando en cocheras (únicamente para las guaguas donde no esté operativo el nuevo pupitre SC) y serán gestionados de la misma forma en la que se hace actualmente al PCGB.

El equipamiento embarcado, y más concretamente el pupitre, vuelca los datos en ficheros (cuyas especificaciones se entregarán al adjudicatario final), que son procesados en el SCGB.

Pasada la etapa de migración, cuando se elimine la BM y se trabaje únicamente con el sistema SIN contacto, los concentradores y PCGB existentes serán sustituidos por el nuevo SCGB, PCGB y nuevos concentradores, que recibirán los datos y los gestionarán (los nuevos datos SC se comunicarán por GPRS/3G al SCGB. Si falla esta comunicación se volcarán por WIFI al concentrador de cocheras y se harán llegar al SCGB). A continuación se incluyen las especificaciones técnicas para los nuevos concentradores.

5.6.1. Descripción ‌

El concentrador estará instalado en las cocheras/oficinas de TITSA y se comunicará con los pupitres embarcados a través de comunicaciones radio (WIFI/GPRS) para recibir las transacciones efectuadas a bordo que no hayan podido ser enviadas por GPRS al SCGB y para comunicar a los pupitres las configuraciones y parametrizaciones a través de los mismos medios.

5.6.2. Funciones ‌

- Recepción de ficheros de operaciones efectuadas a bordo comunicados por el pupitre (Para ello, el concentrador contará con módulo de comunicaciones GPRS y WIFI, además de poder efectuar la descarga con dispositivo de memoria -llave o similar- en caso de que fallen las comunicaciones).

- Comunicación con el SCGB (TCP/IP) de los datos de los registros recibidos de los pupitres (operaciones no enviadas por GPRS al SCGB).

- Comunicación a los pupitres de configuraciones/parametrizaciones.

- Deberá cuidarse especialmente:

▪ La velocidad y tiempos estimados de volcado del sistema propuesto.

▪ Mecanismos para poner seguridad en la red, que impidan accesos no autorizados.

▪ Sencillez de utilización.

▪ Grado de automatización.

▪ Xxxxxxxx y fiabilidad.

- Comunicaciones:

▪ Concentrador-pupitre (WIFI/GPRS/LLAVE MEMORIA): para la comunicación de configuraciones/parametrizaciones al pupitre.

▪ Pupitre-Concentrador: (WIFI/GPRS/LLAVE MEMORIA): para la descarga de ficheros de las operaciones efectuadas a bordo.

▪ Comunicación con el PCGB (TCP/IP): para recepción de configuraciones/parametrizaciones.

▪ Comunicación con el SCGB (TCP/IP): para comunicación de las operaciones recibidas del pupitre.

5.6.1. Funcionalidades a valorar positivamente ‌

No aplica

5.6.2. Requisitos técnicos ‌

Las especificaciones que se incluyen a continuación responden a las necesarias para el cumplimiento de las funciones detalladas anteriormente (se incluyen los requisitos técnicos tanto de las funcionalidades obligatorias como las valorables). El concentrador deberá contar con todos los elementos necesarios para su cumplimiento. Deberá disponer al menos de:

- Interfaces:

▪ Punto de acceso de comunicaciones WIFI para conexión con pupitres embarcados.

▪ Módulo de comunicaciones GPRS para conexión con pupitres embarcados.

▪ Conexión TCP/IP para conexión con PCGB y SCGB.

- Memoria de disco duro para almacenamiento de al menos 1 año de transacciones (mínimo 1Tbyte).

- Accesorios: deberá disponer al menos de:

▪ Dos tarjetas Ethernet.

▪ Tarjeta gráfica.

▪ Lector/grabador de CD-ROM/DVD.

▪ Cuatro puertos USB 2.0.

5.6.3. Afecciones a fases y etapas ‌

No tiene.

5.7. INSPECCIÓN ‌

5.7.1. Descripción ‌

Equipos para inspección del correcto uso de las tarjetas SC de Tenerife por los usuarios de transporte, por parte de los inspectores del sistema de billetaje.

Se incluye también el uso de estos terminales portátiles como terminales de mantenimiento. Son equipos tipo PDA que permiten las comunicaciones de datos.

5.7.2. Funcionalidades ‌

- Inicio de sesión: para el inicio de sesión del equipo se requerirá la identificación del usuario del equipo según el modo en el que se arranque el equipo. Dicha identificación podrá efectuarse mediante tarjeta de identificación sin contacto o bien mediante código identificativo del usuario.

- Posicionamiento: el terminal de inspección podrá recibir del pupitre por vía inalámbrica (WIFI) los datos de configuración del servicio en curso (ruta, parada, etc.), de forma que cuando el inspector acceda al autobús, el equipo de inspección pueda obtener los datos de configuración del servicio en curso y de esta forma pueda realizar los cálculos de validez de las tarjetas inspeccionadas. De forma alternativa este procedimiento podrá efectuarse mediante tarjetas sin contacto de inspector que se validan en el pupitre y son leídas posteriormente por el terminal de inspección.

- Lectura y grabación de tarjetas sin contacto según los procedimientos que se especifiquen para las funciones relacionadas con la inspección:

o Consulta: de forma predeterminada, el equipo mostrará la información relevante para la inspección contenida en la tarjeta (datos del viaje en curso: fecha y hora validación, localización de la validación, saldo cobrado, etc.). Además podrá accederse a un menú para consulta de otros datos (históricos de validaciones y cargas anteriores, etc.).

o Detección de incongruencias: el terminal será capaz de indicar las incongruencias detectadas según la configuración del servicio actual (recibida del pupitre), y los datos grabados en la tarjeta inspeccionada (por ejemplo, no existe validación en el autobús en curso).

o Mecanismos de recuperación de tarjetas al no haber finalizado una transacción, según la documentación de referencia que será entregada al adjudicatario.

o Validación /recarga: el terminal podrá validar y recargar tarjetas, según la documentación de referencia que será entregada al adjudicatario.

o Las funciones anteriores podrán ser habilitadas/deshabilitadas según necesidades.

- Lector/ grabador sin contacto y módulo XXX (ver apartados “Módulos XXX” y “Lector/grabador sin contacto”).

- Modos de operación:

o Inspección (será configurable el modo de arranque por defecto): es el modo normal del equipo, en el que al acercar una tarjeta se muestran los datos más relevantes para la inspección (ver funcionalidad de lectura y grabación).

o Validación/ recarga: el terminal podrá efectuar validaciones y recargas en este modo, según los procedimientos que se definan.

o Mantenimiento: este modo sólo es accesible previa identificación del personal de mantenimiento mediante tarjeta sin contacto del empleado correspondiente o introducción del código de identificación de éste y permite acceder a menús de funcionamiento del equipo para funciones de mantenimiento. Podrán efectuarse operaciones de mantenimiento en remoto. Podrán efectuarse tareas de recarga de tarifas y datos de facturación en guaguas en modo degradado (sin conexión a las redes WIFI de la compañía).

o Bloqueo: el equipo podrá bloquearse, para evitar manipulaciones, por ejemplo, durante un tiempo de ausencia del usuario del equipo.

- Comunicaciones.

o Comunicación directa con el nuevo PCGB on-line mediante GPRS/GSM/3G/UMTS para recepción de configuraciones/parametrizaciones y envío de alarmas.

o Comunicación con el SCGB on-line mediante GPRS/GSM/3G/UMTS para envío de los registros de las operaciones efectuadas.

o El módulo GPRS podrá activarse/ desactivarse por parte del usuario para poder ahorrar energía. Además, podrá configurarse la activación o desactivación automática del módulo GPRS (por ejemplo, en el arranque y fin de servicio del equipo de forma que tras un tiempo X definido entre en estado de reposo, desactivándose la comunicación GPRS).

o Comunicación vía WIFI con el pupitre del autobús (o concentrador del tranvía) para configuración de datos de posicionamiento de la inspección a realizar (servicio, parada, línea, etc.), o bien comunicar esta información a través de la grabación de una tarjeta SC identificada como de inspector. El adjudicatario deberá detallar en su oferta el modo elegido.

o Debe contemplarse la conexión con el sistema Vía Móvil para permitir la fiscalización de los usuarios que usan este sistema (ver apartado “Antecedentes”, en el punto que describe MTSA).

o El equipo estará preparado para poder ser conectado en el futuro a un módulo de comunicaciones WIMAX, de tal forma que sea posible la comunicación del terminal de inspección con los Sistemas Centrales a través de una red WiMax.

- Gestión de listas (ver apartado “Detalle funciones y requisitos técnicos”, en el punto “Gestión de Listas”).

- Cálculo de multas y gestión del cobro: el equipo tendrá la posibilidad de generar una multa si existen incongruencias entre los datos de configuración del servicio actual (recibida del pupitre), y los datos grabados en la tarjeta inspeccionada (por ejemplo, no existe validación en el autobús en curso). Se mostrará la posibilidad al supervisor de cobrar la multa, no cobrarla, o efectuar una consulta más exhaustiva de los datos de la tarjeta.

- Emisión de comprobantes de recibo: el equipo dispondrá de impresora para poder emitir:

• Comprobantes de las operaciones consultas efectuadas según el formato que se establezca.

• Comprobantes de recibo de las multas cobradas.

• Emisión de billetes de incidencia/ sencillos.

• Etc.

- El equipo será capaz de recibir actualizaciones de software en remoto mediante telecarga.

- Capacidad suficiente de almacenamiento de operaciones efectuadas y encolamiento en caso de no existir comunicación para su envío en el momento que sea posible, así como almacenamiento de toda la información de configuración.

- Gestión de claves y estructuras de datos de las tarjetas (ver punto “Detalle funciones y requisitos técnicos” en el apartado “Gestión de claves y estructuras de datos”).

- El equipo podrá emitir mensajes de texto a través de pantalla, de forma que se mostrarán al usuario del equipo los mensajes de menús y los que se definan para cada uno de los eventos que puedan darse (por ejemplo, menús de venta y cargas que pueden efectuarse, carga correcta de saldo, entre otros).

- El equipo dispondrá de un lector de código xx xxxxxx 2D para lectura de billetes sencillos con código xx xxxxxx, billetes sencillos en móviles etc. Este lector deberá estar integrado en el equipo y éste será capaz de recibir e interpretar la lectura del código xx xxxxxx.

- El equipo deberá poder emitir un comprobante de resumen de liquidación al cierre del servicio (inspecciones realizadas, cobros de multas efectuados, entre otros). Dicha información debe poder imprimirse en el mismo ticket en formato código xx xxxxxx (2D).

- Alarmas: el equipo deberá generar alarmas para eventos como falta de papel o próximo a agotarse, actualización de los programas en proceso, fallo de comunicación, etc. El mensaje de alarma deberá mostrarse en continuo hasta que desaparezca el motivo de la alarma.

- Seguridad: Además de lo ya mencionado, se requerirán las siguientes medidas de seguridad:

o Conexión segura entre el equipo y Sistema Central (VPN, encriptación, certificados digitales, etc.).

o Incapacidad de operar el equipo si el mismo recibe más de x intentos (parametrizable) no válidos de acceso o si se encuentra desconectado del sistema central por más de un tiempo parametrizable.

o Se verificarán todas las medidas de seguridad para garantizar que toda operación quede registrada y que toda tarjeta grabada sea considerada una operación (aun pudiendo quitar alimentación eléctrica durante una carga, eliminación del rollo de comprobantes, etc.).

o Acceso limitado al equipo, para lo cual se utilizará un usuario/clave (o simplemente clave) cuyas características garanticen la seguridad (longitud, cambio cada determinada cantidad de tiempo, no se pueden repetir las últimas n claves, etc.). En caso de acceder con algún medio físico (utilización de una tarjeta, por ejemplo), será necesaria la introducción de una clave asociada a dicho medio.

o Garantías de que todo usuario/ que opera el terminal, puede ser identificado.

- Preparación para validación e inspección de tarjetas EMV sin contacto: Ver punto 4.6.8 “Tarjeta bancaria-EMV con y sin contacto”.

- Ver apartado de “Teléfono móvil” para implicaciones en el equipo.

5.7.3. Funcionalidades a valorar positivamente.‌

- Criptoprocesador adicional al módulo XXX (al menos para 3DES/AES/RSA) para poder realizar las encriptaciones necesarias para ejecutar transacciones en tiempos óptimos.

5.7.4. Requisitos Técnicos ‌

- El ofertante deberá indicar en su oferta el sistema operativo que usará el equipo.

- Lector/grabador tarjetas sin contacto. Características técnicas en apartado “lector sin contacto”.

- Procesador criptográfico (incluido como funcionalidad valorable positivamente): capacidad del lector (y criptoprocesador en su caso) para encriptación como mínimo en:

o DES/3DES: : clave 168 bits

o RSA: clave mínimo 2048 bits.

o AES: clave 128 y 256 bits.

El proveedor deberá especificar cuantos parámetros sean necesarios para poder encriptar/desencriptar con herramientas estándar (ejemplo: openssl).

- Módulo XXX, con las características técnicas referidas en el punto “Módulos XXX”.

- Alimentación por batería, debiéndose incluir el soporte de recarga de la misma. Se suministrará una batería adicional para cada unidad.

- Autonomía mínima, por batería, de 800 lecturas de título por turno de 8 horas.

- Capacidad de proceso y almacenamiento suficientes para garantizar las necesidades existentes. Como referencia de mínimos:

o Procesador de 16/32 bits, tecnología CMOS de bajo consumo.

o Memoria Flash (16 MBytes) y SDRAM (4 MBytes).

- Estado de la máquina: la máquina puede encontrarse en diferentes estados, y el estado en el que se encuentra deberá mostrarse siempre en pantalla. Este estado será el resultado de la combinación de los siguientes eventos:

o Emite o no recibos (papel impreso)

o Fuera de servicio por avería.

o Fuera de servicio por mantenimiento.

o Fuera de servicio manual (por petición local o remota).

o Otros.

- Alarmas: la máquina deberá reportar las alarmas de eventos que afecten a su funcionamiento, registrando fecha y hora y reportarlas al PCGB. A modo de ejemplo:

o Fallo de alimentación (previa finalización de la transacción en curso mediante las baterías de las que dispone).

o Agotamiento de papel para impresión de recibos y papel próximo a agotarse.

o Archivo de datos corrupto.

o Fallo en la venta/recarga de tarjetas después de x intentos.

o Fallo en comunicaciones

o Fallo en impresoras

o Otras.

- Módulo comunicaciones GPRS/GSM/3G/UMTS para comunicación con el SCGB y PCGB.

- Pantalla alfanumérica LCD retroiluminado para indicaciones al supervisor:

o Con dimensiones mínimas de 71x39mm.

o Resolución mínima de 128x64 pixels que garantice una buena visibilidad a cualquier hora.

o El contraste y la iluminación deberán ser ajustables.

o Mínimo 8 líneas de 20 caracteres cada una y tamaño de carácter superior a 5mm.

x Xxxxxx de visión amplio, superior a 50º.

o Visibilidad con incidencia solar directa.

o Intensidad luminosa: Mínimo 300 NITS.

- Impresora térmica (ver apartado “Detalle funciones y requisitos técnicos” en el apartado “Requisitos técnicos impresora térmica).

- Teclado 20 teclas multifuncional y alfanumérico programable para utilización por el supervisor. Se preverán teclas de función para la entrada directa, y mediante pulsación simple, de datos más frecuentes para agilizar los procesos. Deberá ser de alta resistencia con retroiluminación.

- Interfaces de comunicaciones:

o Ethernet TCP/IP

o WIFI

o GSM/GPRS/3G/UMTS

o Puertos serie RS-232

- Conectores:

o 1 conector de alimentación

o 1 conector RJ-45

- Avisador acústico e indicadores visuales que faciliten la tarea del supervisor.

- Interfaz ergonómica: deberá estar diseñado para su portabilidad, con dimensiones adecuadas y peso reducido y gran robustez.

- Software: el ofertante deberá especificar en su oferta el SW instalado en el equipo.

- Parámetros ambientales de funcionamiento:

o Temperatura máxima de almacenamiento inferior a 70ºC.

o Rango de temperaturas de funcionamiento: -10ºC / +55ºC

o Humedad máxima: 95%

o Tensión de alimentación 12-30V

o Deberán disponer de fuente de alimentación específicas.

o Deberán estar protegidos contra sobretensiones y efectos radioeléctricos generados por otros elementos conectados al equipo.

- Cumplirá los requisitos de robustez habituales (ver. Punto ”Detalle funciones y requisitos técnicos”, en el apartado “Requisitos técnicos robustez y medioambientales” para equipos portátiles).

- Deberán suministrarse los accesorios suficientes y necesarios para asegurar su movilidad y transporte así como su funcionamiento prolongado en servicio:

o Fundas

o Soportes

o Cargadores para guaguas

o Baterías de larga duración y de reserva

o Otros.

- El adjudicatario deberá especificar los métodos recomendados para la recarga de batería y descarga de datos (posibilidad de recarga de batería y descarga de datos simultánea, modos de descarga de datos, entre otros).

5.7.4.1. Afecciones a fases y etapas.

No tiene.

5.8. PCGB ‌

5.8.1. Descripción ‌

El PCGB actual de TITSA será sustituido por el nuevo PCGB.

Sin embargo, en la fase de migración, donde convivirán el sistema magnético y el sistema sin contacto, se mantendrá la gestión actual del PCGB para el magnético, de forma que los equipos envíen todas las transacciones efectuadas con BM al PCGB en el formato actual (ficheros cuyas características se facilitarán al adjudicatario).

Debe tenerse en cuenta que en el caso del pupitre, el adjudicatario deberá detallar el método propuesto para volcar la información del pupitre al SCGB (información BM y SC) y posteriormente trasladar las operaciones de BM al PCGB actual.

No se gestionarán ficheros de configuración / parametrización del PCGB a los equipos xx Xxxxx Magnética en la etapa de migración.

5.8.2. Funcionalidades ‌

El nuevo sistema central PCGB cubrirá las funcionalidades referentes a monitorización y gestión de los equipos del nuevo sistema, ya que el resto de funcionalidades serán cubiertas por el SCGB. A continuación se incluye un esquema funcional del PCGB.

Figura 9: Esquema funcional PCGB TITSA.

• MÓDULO GESTIÓN DEL SISTEMA:

o Gestión de seguridad:

▪ Gestión de permisos y usuarios por perfiles, con definición de permisos y accesos a las diferentes aplicaciones y datos. Existirá una interfaz para la configuración de dichos perfiles y permisos por parte del operador según los permisos que se establezcan para cada uno.

o Gestión de listas: el PCGB recibirá las listas (blancas, negras, grises) del SCGB, de modo que deberá transmitirlas a todos los equipos y deberá asegurarse de interrogar al FTP del SCGB para comprobar la existencia de actualizaciones.

o Gestión de tarifas: Para cubrir las necesidades derivadas de las configuraciones de las tarifas en BackOffice de las líneas, es necesario un módulo completo que permita a los operadores del SCGB de billetaje de TITSA configurar cualquier cambio de tarifas que se proponga de forma ágil, atendiendo a la cantidad de líneas en producción, diversidad de topologías tarifarias, agrupaciones existentes, tarifas por trayecto kilométricas/zonales, títulos definidos, horarios y otras características.

El módulo anterior permitirá configurar en el sistema los cambios de tarifas que posteriormente serán publicados a las guaguas/taxis/parking/puntos de venta y resto de equipos, de tal forma que los cambios que afecten a gran cantidad de líneas/trayecto y horarios, serán realizados por el sistema de forma automatizada a partir de una orden/parametrización del operador del Sistema Central, no teniendo el operador que configurar línea a línea/trayecto a trayecto.

o Gestión de entidades y configuraciones: las codificaciones referentes a la información integrada (títulos integrados, tarifas títulos integrados, paradas en zona

integrada, etc.) así como de información de títulos propios (códigos de títulos propios, tarifas títulos propios, paradas en área no integrada, códigos de conductores, de equipos, etc.) se gestionan (altas/bajas/modificaciones) a través de la interfaz web con el SCGB.

El PCGB dispondrá de procesos para la propagación de estas configuraciones a aquellas funciones que lo requieran, en especial en el caso de las tarifas (ver apartado anterior).

Así mismo, se gestionará la configuración existente en cada tipo (títulos y tarifario activos en cada equipo, versiones de SW y configuración de cada equipo, etc.), según se indica en el módulo de explotación.

• MÓDULO COMUNICACIONES Y MONITORIZACIÓN:

o Gestión y monitorización del sistema: cuadro de mandos para el control de:

▪ Monitorización y control de procesos activos en el PCGB.

▪ Monitorización y control de servidores activos (por ejemplo, controles de procesos activos o excesivamente activos, archivos abiertos o bloqueados demasiado tiempo, operaciones programadas no ejecutadas)

▪ Monitorización y control de BBDD (accesos de los diferentes usuarios, niveles de llenado, etc.).

▪ Otros.

o Comunicaciones datos del transporte: Las operaciones se enviarán desde los equipos al SCGB y el PCGB interrogará a través de un web service del SCGB sobre los equipos que enviaron operaciones en un periodo determinado para analizar si son todos los que deberían haberse enviado. Si el PCGB detecta incongruencias, generará alarmas que deberán ser gestionadas por el operador de TITSA correspondiente.

o Red de ventas: TITSA gestiona la red de ventas propias y la red de ventas externa: el PCGB incluirá un cuadro de mandos para la red de ventas y procesos de control de terminales activos, alarmas, etc.

• MÓDULO DE EXPLOTACIÓN:

o Parametrizaciones y alarmas:

▪ El PCGB dispondrá de una interfaz para el mantenimiento de configuraciones y parametrizaciones de equipos (por ejemplo, parámetros de tiempos de passback, codificaciones, etc.) y generará los ficheros para su comunicación a todos los equipos. Así mismo, la interfaz permitirá la consulta y seguimiento de los equipos actualizados y versiones de configuración existentes.

▪ El PCGB recibirá las alarmas del equipamiento (por ejemplo, pupitre sin papel, canceladora sin comunicación) y permitirá la monitorización de estas alarmas y del equipamiento.

o Consultas e informes: el PCGB permitirá la generación de informes estáticos y a demanda sobre los datos existentes en la BBDD del PCGB, así como la configuración de tiempos de envío y destinatarios para su recepción vía e-mail. Como ejemplo se incluyen los siguientes informes:

• Alarmas por equipo y tipología.

• Versiones de SW/parámetros por equipo.

• Actualizaciones de SW/parámetros por periodo tiempo/ tipo equipo.

• Etc.

Las consultas relativas a los datos de operaciones enviadas por los equipos se efectuarán a través del interfaz con el SCGB (ver apartado Sistema Central de Gestión de Billetaje SCGB).

o Gestión de fiscalización: Gestionará las inspecciones efectuadas por los terminales de inspección, liquidaciones de multas cobradas, etc. a partir de los datos volcados al SCGB por los terminales de inspección.

o Gestión económica de explotación.

• Elaboración de cierre contable al cierre del día a las 23:59:59 horas.

• Elaboración de informes a medida de transacciones y movimientos de efectivo que se producen en los puntos de venta con capacidad de posibilidad de filtrarlas por tipo de operación, equipo, hora, día, mes.

• Dentro de esta gestión debe estar prevista la gestión de pago mixto de las operaciones en los puntos que esté permitido para cuadrar operaciones de venta/recarga con las operaciones económicas.

Procesos con otras entidades/sistemas:

o BANCOS: como se ha comentado en el apartado “Sistema Central de Gestión de Billetaje SCGB”, existirá una pasarela bancaria para los pagos efectuados con tarjeta de crédito en la página web del usuario final.

o SAE: El sistema SCSAE así como el sistema central de Billetaje de TITSA deben compartir información para no duplicar esta información y no tener información contradictoria. En particular la topología de la red de transporte, paradas y toda la codificación asociada. Según se detalla en el apartado de SAE TITSA se plantean dos posibilidades:

▪ Base de datos común sobre la que acceden ambos sistemas, en la información que es compartida.

▪ Base de datos en uno de los sistemas, donde se actualicen los datos y replicado en el otro sistema donde no tendrán la posibilidad de modificar los datos y solo explotarlos.

Comunicaciones y arquitectura física:

Se incluye un esquema de comunicaciones en las figuras de Arquitectura final y en migración en la descripción general del sistema SC de TITSA.

La figura siguiente muestra un esquema de la arquitectura física del PCGB.

Figura 10: Arquitectura física TITSA.

5.8.3. Funcionalidades a valorar positivamente.‌

• Entorno diferenciado de desarrollo – pruebas que permita testear nuevas funcionalidades antes de ponerlas en producción sin interferir en los procesos en funcionamiento.

• Inclusión de cambios de versiones en la oferta de mantenimiento.

• Partes del sistema que puedan funcionar en plataformas diferentes.

5.8.4. Requisitos técnicos ‌

A continuación se incluyen los requisitos mínimos que deberán cumplir los equipos representados en la arquitectura física y de comunicaciones anterior.

• Arquitectura basada en redundancia de servidores y multiprocesador en cada servidor.

• Canal de fibra redundante.

• Discos propios de operación interna en cluster compartidos (2 discos RAID 1).

• Redundancia de datos en cluster.

• Sistema de Backup de datos y aplicaciones sobre el servidor de respaldo.

• Capacidad de ejecución de cómo mínimo 50 MM transacciones al año.

versión de una aplicación de base de datos estandarizada y montada sobre un cluster de 2 nodos en modo failover.

Se utilizará la funcionalidad de partitioning de la base de datos con objeto de reubicar, de forma automática, los datos en diferentes pilas de discos, actuando de este modo como históricos de la aplicación y permitiendo que el incremento en la cantidad de información no ahogue los procesos de trabajo diario.

• Servidor Respaldo BD, BI y aplicaciones: Se utilizarán procesos en background para realizar las cargas y preprocesamientos de la Base de Datos de Bussines Intelligence y consultas directas en las que obtener información corporativa eficiente sin afectar al rendimiento de la base de datos OLTP. Así mismo, este servidor albergará todas las aplicaciones no relacionadas con los procesos a efectuar en la gestión transaccional (por ejemplo, web services para personalización y atención al cliente, procesos de gestión del fraude, etc.).

• Servidor de aplicaciones (público): Servidor de aplicaciones que pueda suministrar los Web services y/o funcionalidad necesarios para atender las peticiones de los usuarios finales a través de la web de usuario final. Estará franqueado por un ISA Server con el objetivo de realizar labores de Proxy Inverso para balancear cargas de trabajo soportadas por éstos.

• Almacenamiento de datos:

o SAN (cabina de discos): el almacenamiento físico se producirá en cabina de discos externa (SAN) con tecnología de fibra hasta el disco y en formatos RAID 1,5,5E con el objetivo de obtener un óptimo rendimiento, seguridad y capacidad de crecimiento en cada caso concreto.

o Capacidad de almacenamiento de hasta 2 Tbytes.

o Capacidad para gestionar los tres servidores que se conectan a la cabina.

• El Hardware de esta estructura debe cumplir ciertos requisitos de estabilidad, alta tolerancia, flexibilidad y eficiencia:

o La opción ofertada se debe basar en opciones técnicas de futuro, que no queden obsoletas a corto plazo y proporcionen rentabilidad a la inversión realizada.

o El sistema debe ser modular de forma que sea fácil de mantener.

5.8.5. Afecciones a fases y etapas ‌

El PCGB estará implementado desde el inicio del proyecto.

5.9. RED DE VENTAS EXTERNA ‌

Como se ha indicado anteriormente, existirán varios puntos de venta de tarjetas y títulos:

- Taquillas/ Puntos de atención al cliente.

- Expendedoras automáticas.

- Kioscos (red ventas externa).

En este apartado se definen los requisitos que deben cumplir los equipos de venta/recarga de la red de ventas externa, que serán propiedad de TITSA y serán gestionados por éste.

5.9.1. Descripción.‌

Los equipos de venta/ recarga a instalar en los kioscos o puntos de venta que se determinen serán terminales tipo PDA o POS que permitan conexión on-line vía GPRS con el nuevo PCGB para monitorización/configuración de los equipos y con el SCGB para envío de las operaciones efectuadas en éstos y la gestión de tarjetas con lector/grabador y XXX incorporados en el equipo, pudiendo requerirse la operación con módulo HSM centralizado. Además dispondrán de impresora para emisión de recibos.

5.9.2. Funciones ‌

- Lectura y grabación de tarjetas sin contacto según los procedimientos que se especifiquen para las funciones de:

o Venta de tarjetas:

▪ Para los soportes anónimos: incluye la grabación de los datos de inicialización y venta de la tarjeta (cambio de claves, grabación de datos de venta, etc.) y grabación de los datos del título elegido según la matriz de compatibilidad de títulos-tarjetas que se defina.

▪ Para los soportes personalizados: podrán establecerse mecanismos de personalización diferida según los cuales el usuario solicite la tarjeta personalizada (bien a través de medios telemáticos como solicitud a través de página web, o bien por otros medios como entrega de solicitud en el kiosco), de forma que el usuario recoja la tarjeta una vez personalizada en el kiosco, debiendo activarse y grabar el título que corresponda en la tarjeta, al igual que se hace con las tarjetas anónimas.

o Carga y recarga de títulos en los diferentes tipos de tarjetas: recarga de títulos ya cargados en las tarjetas y carga de nuevos títulos según la matriz de compatibilidad que se defina.

o Consulta: consulta de datos contenidos en las tarjetas (saldo, tipo de tarjeta, perfil, históricos, etc.).

o Recuperación de tarjetas que no han finalizado correctamente el proceso de grabación según los procedimientos que se definan.

Podrá exigirse la emisión de recibo de cada una de las operaciones efectuadas.

- Modos de operación:

o Venta: es el modo normal del equipo, en el que se encuentran accesibles las funciones de consulta, venta de tarjeta, recarga de títulos, mediante tecla de pulsación directa. En este modo, y según la función elegida, se efectúan las lecturas necesarias sobre la tarjeta para los procesos lógicos de consulta/venta/recarga y posterior grabación de datos en la tarjeta en aquellas funciones que lo requieran (datos de tarjeta, saldos, históricos de carga, etc.). Se tendrán en cuenta verificaciones sobre parámetros que deberán almacenarse en el equipo o en el PCGB y consultarlas sobre este (por ejemplo, matriz de compatibilidad de títulos – tarjetas, importes máximos a cargar, etc.).

o Bloqueo: el equipo podrá bloquearse, para evitar manipulaciones, por ejemplo, durante un tiempo de ausencia del operador.

- Comunicaciones:

o Equipo-PCGB: el equipo se comunicará con el nuevo PCGB vía TCP/IP para:

▪ Comunicar las alarmas del equipo referentes a todos los elementos del éste en el formato que se defina.

▪ Recibir las configuraciones/ parametrizaciones del nuevo PCGB.

o Equipo – SCGB: el equipo se comunicará con el nuevo SCGB vía TCP/IP para:

▪ Comunicar las operaciones efectuadas en el equipo mediante SC, en el formato que se defina.

▪ Comunicación on-line para verificaciones sobre las operaciones que pueden efectuarse en la tarjeta (por ejemplo, si la tarjeta está dada de alta anteriormente en el SCGB).

o El equipo dispondrá de conexión a un módulo GPRS/GSM/3G/UMTS integrado en el equipo que permita la comunicación on-line al SCGB de TITSA.

o El equipo estará preparado para poder ser conectado en el futuro a un módulo de comunicaciones WIMAX, de tal forma que sea posible su comunicación con los Sistemas Centrales a través de una red WIMAX.

- Parametrización: el equipo deberá tener la capacidad de:

o Recibir y procesar archivos de parametrización enviados desde el nuevo PCGB:

▪ Rutas, paradas, tarifas, títulos, etc.

▪ Importes máximos a cargar, tiempo de passback, etc.

▪ Otros.

o Recibir actualizaciones de software en remoto mediante telecarga.

- Gestión de claves y estructuras de datos (ver apartado “Detalle funciones y requisitos técnicos”, en el punto “Gestión de claves y estructuras de datos”).

- Gestión de listas (ver apartado “Detalle funciones y requisitos técnicos”, en el punto “Gestión de listas”).

- Anulación de la última operación: el equipo deberá poder realizar la anulación de la última operación efectuada mediante petición del usuario, de modo que la tarjeta quede en el estado en el que estaba con anterioridad a la última operación, pudiendo establecerse procesos de grabación de histórico de la anulación realizada, aumento del número de transacción de la tarjeta, así como limitaciones como no haber efectuado ninguna operación intermedia o limitar el tiempo transcurrido desde la operación que se quiere anular y la anulación.

- El equipo indicará el estado resultante de cada una de las operaciones que pueda realizar. Mostrando indicaciones para cada uno de los eventos que puedan darse: por ejemplo, recarga correcta en monedero y saldo viajes restante, tarjeta no válida, etc.

- Lector sin contacto y módulo XXX (ver apartados “Lector/grabador sin contacto” y “Módulos XXX”).

- El equipo podrá emitir mensajes de texto a través de la pantalla, que serán configurables desde el PCGB.

- El equipo deberá poder emitir tickets de recibo de las diferentes operaciones efectuadas. El formato y contenido de estos tickets será configurable desde el PCGB.

- Seguridad: Además de lo ya mencionado, se requerirán las siguientes medidas de seguridad:

o Conexión segura entre el equipo y Sistema Central (VPN, encriptación, certificados digitales, etc.).

o Incapacidad de operar el equipo si el mismo recibe más de x intentos (parametrizable) no válidos de acceso o si se encuentra desconectado del sistema central por más de un tiempo parametrizable.

o Será imprescindible una operación inicial diaria (como mínimo) y on-line contra el SCGB que autorice al equipo para poder operar, así como la comprobación de nuevas parametrizaciones existentes.

o Garantías de que todo usuario/ que opera el terminal, puede ser identificado.

- En previsión del uso de soportes de diferente naturaleza (tarjetas, relojes, llaveros, móviles NFC, etc.), el lector/ grabador sin contacto deberá prever la gestión de dichos soportes, debiendo el ofertante detallar las características morfológicas y de operación de dicho lector (forma de sujeción, medidas, etc.).

5.9.3. Funcionalidades a valorar positivamente ‌

No aplica.

5.9.4. Requisitos Técnicos ‌

Las especificaciones que se incluyen a continuación responden a las necesarias para el cumplimiento de las funciones detalladas anteriormente (se incluyen los requisitos técnicos tanto de las funcionalidades obligatorias como las valorables). El equipo deberá contar con todos los elementos necesarios para su cumplimiento.

Los equipos de venta/ recarga deberán disponer al menos de:

- Lector/grabador de tarjetas sin contacto, con las características técnicas especificadas más adelante para el lector sin contacto.

- Cumplirá los requisitos de robustez habituales según punto “Detalle funciones y requisitos técnicos” en el apartado “Requisitos técnicos robustez y ambientales” para equipos portátiles.

- Impresora térmica (ver punto “Detalle funciones y requisitos técnicos” en el apartado “Requisitos técnicos impresora térmica”).

- Teclado multifuncional programable que permita al usuario introducir datos en el sistema, responder a solicitudes del mismo, y en general realizar cualquier función definida en el sistema.

o Se preverán teclas de función para la entrada directa, y mediante pulsación simple, de los datos más frecuentes, con objeto de agilizar los procesos.

- Interfaces necesarias para comunicarse con el resto de equipos.

- Comunicaciones: módulo GPRS, interfaz Ethernet, WIFI, método de descarga manual.

- Procesador criptográfico (incluido como opción): capacidad del lector (y criptoprocesador en su caso) para encriptación como mínimo en:

o DES/3DES: : clave 168 bits

o RSA: clave mínimo 2048 bits.

o AES: clave 256 bits.

El proveedor deberá especificar cuantos parámetros sean necesarios para poder encriptar/desencriptar con herramientas estándar (ejemplo: openssl).

- Módulo XXX, con las características técnicas referidas en el punto “Módulos XXX”.

- Batería que evite la pérdida de información almacenada.

5.9.5. Afecciones a Fases y etapas ‌

No tiene.

5.10. PUNTOS DE VENTA PROPIOS/ATENCIÓN AL CLIENTE ‌

Los puntos de venta (taquillas) serán puestos atendidos para la venta y carga/recarga de tarjetas. Así mismo, gestionarán las incidencias con las tarjetas sin contacto de Tenerife.

Se prevé que la venta/recarga tenga las mismas funcionalidades descritas para la red de ventas externas, por lo que el equipamiento podrá ser el mismo (teniendo en cuenta que podrán variar las funcionalidades según las necesidades de la red de ventas externas y la red de ventas propias, por lo que deberán gestionarse versiones de SW diferenciadas), aunque se valorará positivamente la integración en entorno PC de las funciones de atención al cliente (resolución de incidencias, consultas, etc.) y las de venta/carga/recarga.

La gestión de incidencias será efectuada en aplicación con entorno PC conectada al SCGB. Las funciones de venta/recarga podrán ser integradas en la aplicación de entorno PC (opción preferible) o efectuarse mediante terminal tipo POS como el especificado para la red de ventas externa.

5.10.1. Funcionalidades Venta / recarga.‌

Para la venta/recarga se considerarán las mismas funcionalidades descritas en el apartado de “Red de ventas externa”.

Pago mixto

La venta y todo el proceso posterior de comunicaciones y gestión contable y de compensaciones, comisiones y liquidaciones en el PCGB y SCGB deberá tener previsto el pago de cualquier operación podrá efectuarse en pago mixto realizado por diferente modos (por ejemplo pagar la mitad al contado y el resto con tarjeta de crédito).

Gestión de incidencias.

Para la gestión de incidencias, el ofertante desarrollará una aplicación entorno PC que se conectará al SCGB mediante TCP/IP de modo que gestionará las funcionalidades que se describen a continuación mediante los web services implementados en el SCGB al efecto:

o Consultas: podrán efectuarse consultas sobre usuarios, tarjetas (históricos, espejos de tarjeta, etc.) pudiendo efectuar filtros sobre dichas consultas (por ejemplo, para un intervalo de fechas, a partir de fecha desde, mostrar sólo operaciones de un tipo específico, etc.).

o Canjes y reconstrucciones:

▪ Reconstrucciones: si la tarjeta queda inutilizada (por ejemplo, por datos corruptos en algún sector), se efectuará una reconstrucción de la tarjeta, de modo que se recuperan los datos de la tarjeta existentes en el sistema central, para grabarlos en la tarjeta.

▪ Canjes: si la tarjeta no puede reconstruirse o no se dispone de ella (por ejemplo, por robo o pérdida), debe destruirse o ponerse en lista negra la tarjeta anterior, que será dada de baja una vez destruida, y canjear la tarjeta antigua por una nueva, recuperando los datos del sistema central.

NOTA: Debe tenerse en cuenta que los datos en el sistema central pueden tener un decalaje de X días (debiera ser como máximo 1 día, puesto que las operaciones se envían on–line para el caso de las ventas y al final del día en el caso de las validaciones, aunque es posible que algunas operaciones lleguen con mayor periodicidad – por ejemplo, fallo en el envío de algún equipo). Es por esto que pueden existir operaciones no actualizadas en el SCGB y que los datos grabados en la tarjeta no se correspondan con la realidad. Para resolver este punto puede indicarse al usuario que espere X tiempo hasta la operación de reconstrucción o canje o aplicar las correcciones de saldo por lista gris a la tarjeta a reconstruida/ canjeada.

o Billetes de incidencia: Podrán efectuarse procesos de actualización de saldo a partir de los billetes de incidencia aportados por el usuario (una vez comprobada su autenticidad) y efectuar su registro en el SCGB. Se dispondrá de un lector de código xx xxxxxx 2D para la lectura de billetes de incidencia y números de tarjeta.

o Listas y recuperaciones: se aplicarán los procesos de recuperación y de listas antes de efectuar las operaciones de reconstrucción y canje anteriores:

• Gestión de claves y estructuras de datos (ver apartado “Detalle funciones y requisitos técnicos”, en el punto “Gestión de claves y estructuras de datos”).

• Gestión de listas (ver apartado “Detalle funciones y requisitos técnicos”, en el punto “Gestión de listas”).

o Inicio de sesión: para el inicio de sesión del equipo se requerirá la identificación del operador, inspector o personal de mantenimiento según el modo en el que se arranque el equipo. Dicha identificación podrá efectuarse mediante tarjeta de identificación sin contacto o bien mediante código identificativo del usuario.

o Todas las operaciones efectuadas (reconstrucciones, canjes, operaciones de listas – por ejemplo, solicitud de inclusión en lista negra de una tarjeta robada), deberán registrarse en el SCGB.

o Alarmas: deberán comunicarse al PCGB todas las alarmas referentes a la aplicación y el equipamiento, especialmente las que puedan inhabilitar el servicio (por ejemplo, no hay comunicación entre el lector y el PC).

o Dispondrá de un lector conectado al PC para efectuar las lecturas/grabaciones de tarjetas que correspondan a cada proceso.

5.10.2. Funcionalidades a valorar positivamente ‌

Integración de aplicación de gestión de incidencias y venta/recarga.

Configuración hardware/software que permita un restablecimiento de las comunicaciones entre el ordenador y sus periféricos sin necesidad de reinicio del primero.

5.10.3. Requisitos técnicos ‌

Las especificaciones que se incluyen a continuación responden a las necesarias para el cumplimiento de las funciones detalladas anteriormente (se incluyen los requisitos técnicos tanto de las funcionalidades obligatorias como las valorables). El equipo deberá contar con todos los elementos necesarios para su cumplimiento.

Los equipos de venta/ recarga cumplirán las mismas especificaciones técnicas que se han indicado en el apartado “Red de ventas externas” en caso de que se opte por terminal POS.

Para la aplicación en entorno PC se tendrán en cuenta las siguientes especificaciones técnicas:

- Lector/grabador de tarjetas sin contacto, con las características técnicas especificadas más adelante para el lector sin contacto.

- Impresora color para impresión de facturas, consultas efectuadas, etc.:

▪ Velocidad de impresión A4 mínima 4ppm (negro), 2 ppm (color).

▪ Capacidad conexión en red.

- PC:

▪ Monitor mínimo 17”.

▪ Mínimo 6 puertos USB 2.0, 2 de ellos en la parte delantera.

▪ Modem integrado.

▪ Memoria disco duro y RAM suficientes para funciones especificadas.

▪ Unidad de DVD +/- RW 16X.

5.10.4. Afecciones a fases y etapas ‌

No aplica.

5.11. PUNTOS DE EMISIÓN MASIVA ‌

TITSA dispondrá en sus oficinas de puestos de emisión masiva donde se grabarán las tarjetas pre- cargadas para distribución en los puntos de venta que no tienen capacidad para ello.

Estos puestos de personalización/emisión masiva permitirán la emisión masiva de tarjetas de rígidas (plástico) y flexibles, de forma que se graben de forma automática dichas tarjetas.

El puesto de emisión masiva consistirá en:

• Un PC donde resida la aplicación de emisión de tarjetas a semejanza de la que se gestiona en los puestos de atención al cliente o de taquilla, con la capacidad añadida de poder configurar las tarjetas con la grabación de los valores deseados en cada campo de la estructura de datos o establecimiento de configuraciones de datos a grabar en las tarjetas.

• Un dispensador/grabador de tarjetas SC rígidas conectada al PC.

• Un dispensador/grabador de tarjetas SC flexibles (FAN-FOLD/ROLLO) conectada al PC.

• Lector SC conectado al PC para lecturas/comprobaciones de tarjetas sin tener que usar el dispensador.

• Lector QR conectado al PC para poder leer números de tarjeta a partir del código QR.

• Impresora conectada al PC para la impresión de informes u otras informaciones acerca del proceso de emisión masiva.

La aplicación en entorno PC permitirá las consultas de datos de tarjetas y usuarios, emisiones masivas de títulos, etc. mediante los web services implementados en el SCGB.

Figura 11: puesto de emisión masiva.

5.11.1. Impresora/ apilador tarjetas rígidas.‌

5.11.1.1.Descripción.

Apilador de tarjetas con capacidad de grabación MIFARE/DESFIRE rígida. Comunicación con el ordenador del puesto de emisión, informando del estado del proceso.

5.11.1.2.Funciones

- Capacidad de carga de tarjetas en espera de su procesado (apilador).

- Lectura y grabación de tarjetas según los datos origen proporcionados por el PC y comunicación a este del resultado del proceso.

- Capacidad de operación en TCP/IP, al objeto de ser operada desde varios puestos de trabajo de forma simultánea.

- Cajetín receptor independiente para tarjetas correctas y tarjetas defectuosas.

- Comunicaciones:

o Equipo-PC: el equipo se comunicará con el PC vía TCP/IP para:

▪ Recibir los datos de la información a grabar en las tarjetas.

▪ Comunicar al PC las operaciones realizadas y los errores que se hayan podido producir.

o Equipo-PCGB: el equipo se comunicará con el nuevo PCGB vía TCP/IP para:

▪ Recibir los datos de configuración/ parametrización sobre códigos de títulos, tarifas, etc. e información a grabar en las tarjetas.

▪ Enviar alarmas.

o Equipo-SCGB: el equipo se comunicará con el nuevo SCGB vía TCP/IP para:

▪ Enviar los registros de las operaciones efectuadas.

- Para los procesos de emisión masiva (por ejemplo, de tarjetas rígidas con títulos promocionales o turísticos ya cargados), podrá configurarse la información a grabar localmente y efectuar los procesos de grabación a partir de estas configuraciones.

- Lector sin contacto y módulo XXX (ver apartados “Lector/ grabador sin contacto” y “Módulos XXX”).

- El equipo indicará el estado resultante de cada una de las operaciones que pueda realizar, mostrando indicaciones para cada uno de los eventos que puedan darse: por ejemplo, grabación correcta /con error, impresión correcta/ con error, etc.

5.11.1.3.Requisitos Técnicos

Las especificaciones que se incluyen a continuación responden a las necesarias para el cumplimiento de las funciones detalladas anteriormente (se incluyen los requisitos técnicos tanto de las funcionalidades obligatorias como las valorables). El equipo deberá contar con todos los elementos necesarios para su cumplimiento.

El dispensador de tarjetas rígidas deberá disponer al menos de:

- Lector/grabador de tarjetas sin contacto, con las características técnicas especificadas más adelante para el lector sin contacto.

- Capacidad mínima de 100 tarjetas

- Capacidad mínima de cajetín de rechazo de 20 tarjetas.

- Capacidad grabación xx xxxx de tarjeta mínimo 100 tarjetas por hora.

- Interfaces: Mínimo USB y Ethernet TCP.

- Condiciones ambientales de funcionamiento:

▪ Min/Max temperatura de funcionamiento: 15° / 35° C

▪ Min/Max temperatura almacenamiento: -5° / +70° C

▪ Humedad: 20% a 65% (sin condensación)

▪ Humedad almacenamiento: 20% a 70% (sin condensación)

- Módulo XXX, con las características técnicas referidas en el punto “Módulos XXX”.

- Cumplirá los requisitos de robustez habituales según apartado “Detalle funciones y requisitos técnicos” en el punto “Requisitos técnicos robustez y ambientales” para impresoras).

5.11.1.4.Afecciones a Fases y etapas.

No tiene.

5.11.2. Impresora/ apilador tarjetas flexibles en FAN/FOLD.‌

5.11.2.1.Descripción.

Apilador de tarjetas con capacidad de grabación MIFARE/DESFIRE flexible en formato FAN-FOLD

/ ROLLO. Comunicación con el ordenador del puesto de emisión, informando del estado del proceso.

5.11.2.2.Funciones

- Capacidad de carga de tarjetas en espera de su procesado (FAN-FOLD / ROLLO).

- Lectura y grabación de tarjetas según los datos origen proporcionados por el PC y comunicación a este del resultado del proceso.

- Mecanismo automático xx xxxxx de tarjetas apiladas en FAN-FOLD / ROLLO.

- Capacidad de operación en TCP/IP, al objeto de ser operada desde varios puestos de trabajo de forma simultánea.

- Cajetín receptor independiente para tarjetas correctas y tarjetas defectuosas.

- Comunicaciones:

o Equipo-PC: el equipo se comunicará con el PC vía TCP/IP para:

▪ Recibir los datos de la información a grabar en las tarjetas.

▪ Comunicar al PC las operaciones realizadas y los errores que se hayan podido producir.

o Equipo-PCGB: el equipo se comunicará con el nuevo PCGB vía TCP/IP para:

▪ Recibir los datos de configuración/ parametrización sobre códigos de títulos, tarifas, etc. e información a grabar en las tarjetas.

▪ Enviar alarmas.

o Equipo-SCGB: el equipo se comunicará con el nuevo SCGB vía TCP/IP para:

▪ Enviar los registros de las operaciones efectuadas.

- Para los procesos de emisión masiva (por ejemplo, de tarjetas flexibles con títulos promocionales o turísticos ya cargados), podrá configurarse la información a grabar localmente y efectuar los procesos de grabación a partir de estas configuraciones.

- Lector sin contacto y módulo XXX (ver apartados “Lector/ grabador sin contacto” y “Módulos XXX”).

- El equipo indicará el estado resultante de cada una de las operaciones que pueda realizar. Mostrando indicaciones para cada uno de los eventos que puedan darse: por ejemplo, grabación correcta /con error, etc.

5.11.2.3.Requisitos Técnicos

Las especificaciones que se incluyen a continuación responden a las necesarias para el cumplimiento de las funciones detalladas anteriormente (se incluyen los requisitos técnicos tanto de las funcionalidades obligatorias como las valorables). El equipo deberá contar con todos los elementos necesarios para su cumplimiento.

El dispensador de tarjetas flexibles en formato FAN-FOLD / ROLLO deberá disponer al menos de:

- Lector/grabador de tarjetas sin contacto, con las características técnicas especificadas más adelante para el lector sin contacto.

- Capacidad mínima de cajetín de rechazo de 20 tarjetas o solución alternativa.

- Grabación xx xxxx de tarjeta mínimo 100 tarjetas por hora.

- Interfaces: Mínimo USB y Ethernet TCP.

- Condiciones ambientales de funcionamiento:

▪ Min/Max temperatura de funcionamiento: 15° / 30° C

▪ Min/Max temperatura almacenamiento: -5° / +70° C

▪ Humedad: 20% a 65% (sin condensación)

▪ Humedad almacenamiento: 20% to 70% (sin condensación)

- Módulo XXX, con las características técnicas referidas en el punto “Módulos XXX”. Dispondrá al menos de 4 bahías para albergar módulos XXX.

- Cumplirá los requisitos de robustez habituales según apartado “Detalle funciones y requisitos técnicos” en el punto “Requisitos técnicos robustez y ambientales” para impresoras.

5.11.2.4.Afecciones a Fases y etapas

No tiene.

5.11.3. Resto de periféricos ‌

• Lector sin contacto: se dispondrá de un lector sin contacto conectado al PC para poder efectuar lecturas y grabaciones de tarjetas sin tener que usar el lector del dispensador. Los requisitos técnicos del lector se incluyen en el apartado “Detalle funciones y requisitos técnicos”.

• Lector código QR: se dispondrá de un lector de código QR conectado al PC para poder efectuar lecturas del código xx xxxxxx QR que contiene el número de tarjeta en los soportes que dispongan de él. Los requisitos técnicos del lector se incluyen en el apartado “Detalle funciones y requisitos técnicos”.

• Impresora color: se dispondrá de una impresora convencional para impresión de informes u otros datos relacionados con el proceso de emisión masiva. Los requisitos técnicos de la impresora color se incluyen en el apartado “Detalle funciones y requisitos técnicos”.

5.12. PUNTOS DE PERSONALIZACIÓN ‌

TITSA dispondrá en sus oficinas de puestos de personalización donde se personalizarán las tarjetas solicitadas en los puntos de venta/ web de usuario final u otros puntos habilitados para ello.

5.12.1. Descripción ‌

El puesto de personalización consistirá en:

• Un PC donde resida la aplicación de personalización con la capacidad de poder personalizar (grabación de datos + impresión externa) tarjetas.

• Una impresora de tarjetas SC rígidas conectada al PC.

• Lector SC conectado al PC para lecturas/comprobaciones de tarjetas sin tener que usar la impresora.

• Lector QR conectado al PC para poder leer números de tarjeta a partir del código QR.

• Escáner conectado al PC para los escaneados que puedan requerirse de la información suministrada por el usuario.

• Impresora color para impresión de informes, consultas, etc.

La aplicación en entorno PC permitirá la personalización/ consultas de datos de tarjetas y usuarios, etc. mediante los web services implementados en el SCGB.

Figura 12: puesto de personalización/emisión masiva.

5.12.2. Funciones ‌

- Capacidad de carga de tarjetas en espera de su procesado (apilador).

- Lectura y grabación de tarjetas según los datos origen proporcionados por el PC y comunicación a este del resultado del proceso.

- Impresión a color de tarjeta, con calidad fotográfica y doble cara. Con comunicación al PC del puesto de personalización del resultado del proceso.

- Capacidad de operación en TCP/IP, al objeto de ser operada desde varios puestos de trabajo de forma simultánea.

- Cajetín receptor independiente para tarjetas correctas y tarjetas defectuosas.

- Comunicaciones:

o Equipo-PC: el equipo se comunicará con el PC vía TCP/IP para:

▪ Recibir los datos de la información a grabar en las tarjetas y diseño externo a imprimir.

▪ Comunicar al PC las operaciones realizadas y los errores que se hayan podido producir.

o Equipo-PCGB: el equipo se comunicará con el nuevo PCGB vía TCP/IP para:

▪ Recibir los datos de configuración/ parametrización/listas sobre códigos de títulos, tarifas, etc. e información a grabar en las tarjetas.

▪ Enviar alarmas.

o Equipo-SCGB: el equipo se comunicará con el nuevo SCGB vía TCP/IP para:

▪ Enviar los registros de las operaciones efectuadas.

▪ Los procesos de personalización se efectuarán mediante los web services implementados en el SCGB, en los que se consulta la BBDD de usuarios, tarjetas, etc. para las diferentes comprobaciones a efectuar al personalizar una tarjeta (consultas de usuarios, altas de usuarios, bajas de tarjetas, tarjetas en lista, etc.).

- Lector sin contacto: se dispondrá de un lector sin contacto conectado al PC para poder efectuar lecturas y grabaciones de tarjetas sin tener que usar el lector del dispensador. Los requisitos técnicos del lector se incluyen en el apartado “Detalle funciones y requisitos técnicos”.

- Lector código QR: se dispondrá de un lector de código QR conectado al PC para poder efectuar lecturas del código xx xxxxxx QR que contiene el número de tarjeta en los soportes que dispongan de él. Los requisitos técnicos del lector se incluyen en el apartado “Detalle funciones y requisitos técnicos”.

- Escáner: se dispondrá de un escáner conectado al PC para poder escanear los documentos entregados por el usuario para la personalización.

5.12.3. Funcionalidades a valorar positivamente ‌

- No tiene.

5.12.4. Requisitos Técnicos ‌

Las especificaciones que se incluyen a continuación responden a las necesarias para el cumplimiento de las funciones detalladas anteriormente (se incluyen los requisitos técnicos tanto de las funcionalidades obligatorias como las valorables). El equipo deberá contar con todos los elementos necesarios para su cumplimiento.

La impresora/ apiladora de tarjetas rígidas deberá disponer al menos de:

- Lector/grabador de tarjetas sin contacto, con las características técnicas especificadas más adelante para el lector sin contacto.

- Impresora a color, con las características técnicas especificadas en el apartado “Detalle funciones y especificaciones técnicas”.

- Escáner, con las características técnicas especificadas en el apartado “Detalle funciones y especificaciones técnicas”.

- Para la impresora de TSC rígidas:

- Módulo de impresión a color doble cara, mínimo 300 dpi

- Capacidad mínima de 100 tarjetas

- Capacidad mínima de cajetín de rechazo de 20 tarjetas.

- Capacidad de impresión a color 2 caras con grabación xx xxxx de tarjeta mínimo 100 tarjetas por hora.

- Interfaces: Mínimo USB y Ethernet TCP.

- Condiciones ambientales de funcionamiento:

▪ Min/Max temperatura de funcionamiento: 15° / 40° C

▪ Min/Max temperatura almacenamiento: -5° / +70° C

▪ Humedad: 20% a 65% (sin condensación)

▪ Humedad almacenamiento: 20% a 70% (sin condensación)

- Módulo XXX, con las características técnicas referidas en el punto “Módulos XXX”.

- Cumplirá los requisitos de robustez habituales según apartado “Detalle funciones y requisitos técnicos” en el punto “Requisitos técnicos robustez y ambientales” para impresoras.

5.12.5. Afecciones a Fases y etapas ‌

No tiene.

5.13. TAXI ‌

Para el uso de la tarjeta sin contacto en el pago de taxi, se instalarán nuevas canceladoras independientes.

5.13.1. Descripción ‌

La validadora independiente, será el equipo usado en los taxis para la validación SC, no habiendo más equipos que este, por lo que la canceladora deberá permitir una gestión independiente en todos los aspectos, a diferencia de la canceladora dependiente del pupitre.

5.13.2. Funciones ‌

- Capacidad de procesado y almacenamiento suficiente para soportar los requisitos especificados en este documento.

- Modos de operación: Validación, supervisión, mantenimiento, y bloqueo, de la misma forma en que se han definido estos modos para el pupitre.

- Gestión de claves y estructuras de datos (ver apartado “Detalle funciones y requisitos técnicos”, en el punto “Gestión claves y estructuras de datos”).

- Gestión de listas (ver apartado “Detalle funciones y requisitos técnicos”, en el punto “Gestión listas”).

- La validadora indicará el estado resultante de cada una de las operaciones que pueda realizar, mostrando indicaciones para cada uno de los eventos que puedan darse: por ejemplo, validación correcta con monedero y saldo viajes restante, tarjeta no válida, etc.

- La validadora dispondrá de un lector de código xx xxxxxx QR para lectura de billetes de incidencia con código xx xxxxxx (también en dispositivos móviles), etc. Este lector deberá estar integrado en el equipo y éste será capaz de recibir e interpretar la lectura del código xx xxxxxx. Así mismo, podrán emitirse billetes de incidencia en papel con impresión en código xx xxxxxx 2D/QR de la información relevante (número de ticket, hora emisión, etc.).

- Lector sin contacto y módulo XXX (ver puntos “Módulos XXX y “Lector/grabador sin contacto”.

- Comunicaciones:

o Validadora-SCGB: La validadora dispondrá de conexión a un módulo GPRS/GSM/3G/UMTS integrado en el equipo que permita la comunicación on-line de todas las transacciones (validaciones, operaciones de listas, anulaciones, etc.) al SCGB de TITSA, aunque el equipo tendrá la capacidad de almacenar el número de transacciones necesarias para efectuar las verificaciones que se requieran (al menos un mes). Las transacciones serán enviadas en el formato que se defina (JSON, XML, Binario, ETC).

o Validadora-nuevo PCGB TITSA: La validadora recibirá la parametrización / configuración desde el nuevo PCGB de TITSA (líneas, tarifas, servicio a realizar, etc.) y enviará las alarmas de funcionamiento a éste.

o La canceladora dispondrá también de dispositivo USB (formato llave o similar) para descarga manual de datos, debiendo indicar en la oferta el funcionamiento del mecanismo manual propuesto.

Document Metadata

Table of Contents

CONTRATACIÓN DEL SISTEMA DE BILLETAJE SIN CONTACTO EN EL ENTORNO DE TENERIFE y DEL NUEVO SAE PARA TITSA

Document Metadata