1.- OBJETO DEL CONTRATO

Transcripción

1 PLIEGO DE CONDICIONES TÉCNICAS PARA LA CONTRATACIÓN DEL DESARROLLO DEL SOFTWARE PARA LA GESTIÓN DE LA TARJETA ÚNICA DE PAGO PARA LA ISLA DE GRAN CANARIA MEDIANTE PROCEDIMIENTO ABIERTO 1.- OBJETO DEL CONTRATO La finalidad del contrato será el análisis, desarrollo, puesta a punto, implantación, mantenimiento y explotación del nuevo título (tarjeta) único de pago con tecnología sin contacto para su utilización en el transporte regular de viajeros de la isla de Gran Canaria y de la correspondiente Cámara de Compensación, con el que la Autoridad Única del Transporte de Gran Canaria pretende conseguir los siguientes objetivos: - Facilitar al viajero el acceso a la totalidad de la red de transporte insular. - Conseguir una mayor velocidad comercial de los servicios de transporte. - Realizar una política de tarifas de transporte homogénea, independiente del operador y del ámbito geográfico del viaje. - Facilitar al usuario del transporte público regular de viajeros la adquisición de su medio de pago. - Mejorar el nivel tecnológico de la Autoridad Única del Transporte de Gran Canaria y de las operadoras en relación con la información proveniente de las formas de pago. Como objetivo final se persigue potenciar el transporte público regular de viajeros como alternativa al transporte privado para conseguir un desarrollo sostenible y respetuoso con el medio ambiente. En el presente pliego se describe las especificaciones técnicas que han de cumplir los elementos software del Sistema del Título Único para el Transporte en la Isla de Gran Canaria, STUT en adelante, contemplando aspectos como la definición, venta, recarga, control, recaudación y consolidación de los ingresos de los medios de pago, basados en la tecnología de las tarjetas sin contacto, tarjetas en adelante, que la Autoridad Única del Transporte de Gran Canaria decida poner en funcionamiento y que son objeto de este contrato. Concretamente afecta a los siguientes elementos: - Software para la definición y creación de distintos títulos de tarjetas. - Software requerido para la venta y recarga de las distintas tarjetas. 1/14

2 - Software requerido para la inspección del uso de las tarjetas en los vehículos de las flotas de los operadores. - Software para la transferencia de las anotaciones de los usos por parte de los clientes en los distintos operadores. - Software de procesamiento en los sistemas de la AUT de los datos obtenidos de la red de puntos de venta y de los operadores relativos a la venta, recarga y uso de las tarjetas. El objeto del presente contrato corresponde al código de la nomenclatura de la Clasificación Nacional de Productos por Actividades 2002 (CNPA-2002) y al código del Vocabulario Común de Contratos Públicos (CPV). 2.- PERSONAS QUE INTERVIENEN EN EL PRESENTE CONTRATO El órgano de contratación designará un director del trabajo, quien supervisará la ejecución del mismo, comprobando que su realización se ajusta a lo establecido en el pliego de prescripciones técnicas, y cursará al contratista las órdenes e instrucciones del órgano de contratación. El adjudicatario pondrá a disposición de la Autoridad Única del Transporte de Gran Canaria el personal necesario para la correcta ejecución del contrato, designando a un delegado con la titulación profesional competente, que lo represente en el cumplimiento de las obligaciones contractuales, que organice y ponga en practica los trabajos encomendados. Además de los medios personales, el adjudicatario pondrá a disposición los medios materiales necesarios para el cumplimiento del mismo. Durante el desarrollo de los trabajos y la ejecución de las diferentes fases del proyecto, la Autoridad Única del Transporte de Gran Canaria podrá establecer controles de calidad sobre la actividad desarrollada y los productos obtenidos, siempre en el marco específico de calidad aplicable en cada caso. 3.- RESPONSABILIDADES El adjudicatario será responsable de las consecuencias de las acciones y omisiones en las materias en que, en ejercicio de sus funciones, hubieran actuado, salvo que el 2/14

3 director las hubiese rectificado, en cuyo caso éste último será responsable únicamente de las consecuencias de la rectificación. El director del contrato no será responsable, ni directa ni solidariamente, de lo que, con plena responsabilidad técnica y legal, decida el adjudicatario, el cual deberá disponer del personal adecuado y con la titulación legal necesaria para la realización del trabajo objeto de este contrato. Las responsabilidades derivadas de las acciones del adjudicatario serán asumidas por él mismo o por las personas de su plantilla en función de las atribuciones derivadas de los nombramientos realizados. Las penas se entenderán atribuidas a las personas físicas que ostenten para las diversas cuestiones la representación del consultor. El mencionado consultor será responsable subsidiario de las acciones de su personal relacionadas con el contrato. El adjudicatario será responsable de las decisiones que tome por su iniciativa en las funciones establecidas expresamente en este pliego. No lo será, en cambio, de las consecuencias derivadas de las acciones o decisiones del director. 4.- PRINCIPIOS GENERALES DE FUNCIONAMIENTO DEL STUT Los principios mínimos de funcionamiento del STUT serán los siguientes: - Flexibilidad para soportar distintos tipos de títulos. - Capacidad para integrar equipamiento de distintos proveedores. - Capacidad para soportar crecimientos futuros de la red de transporte terrestre de la isla de Gran Canaria: nuevos operadores, crecimientos de la red de paradas, líneas, medios de pago, etc. - Capacidad de integración con otros modos de transporte y servicios públicos (acceso centros culturales y ocio, etc.). - Compatibilidad con otras tecnologías con el objeto de poder utilizar cualquier tipo de tarjeta inteligente que tenga una interfaz sin contacto y cumpla con las especificaciones técnicas del sistema. - Facilidad para el mantenimiento, el sistema debe estar dotado de mecanismos que permitan realizar cambios en el software (programas y 3/14

4 datos) de forma automática, desasistida y segura con el objeto de facilitar la explotación y optimizar sus costes de explotación. - Capacidad de autodiagnóstico con el objeto de que fallos en los equipos en red de ventas y recargas sean comunicadas automáticamente al centro de proceso de datos de la Autoridad Única del Transporte de Gran Canaria. - El sistema debe tener la capacidad para conectar puntos de recarga automáticos, terminales de venta remotos y equipos de validación en vehículos. - La interacción del software con todos los usuarios del sistema deberá estar en castellano. 5.- ESPECIFICACIONES GENERALES SOBRE LAS TARJETAS_: CARACTERÍSTICAS TÉCNICAS, DEFINICIÓN Y CREACIÓN DE TARJETAS Tal y como ya se expresado con anterioridad, la tecnología base a emplear para desarrollar el medio de pago es la tarjeta sin contacto, concretamente la tipo ISO 1443 tipo A Mifare-DESFire. Debiendo cumplir con las siguientes especificaciones: - Tarjeta sin contacto tipo MIFARE-DESFire, según norma ISO tipo A de al menos 4 Kbyte de memoria. - Frecuencia de operación: 13,56 Mhz. - Características físicas según norma ISO Señal de radiofrecuencia de acuerdo a norma ISO Anticolisión de acuerdo a ISO Protocolo de transporte según norma ISO Dimensiones según norma ISO Los datos almacenados en la tarjeta deberán contemplar al menos: 4/14

5 a) Datos relativos del fabricante. b) Datos relativos a la seguridad. c) Datos relativos al control de acceso. d) Datos relativos al usuario que contemplan datos sobre la identidad del usuario, para el caso de tarjetas personales, y datos relacionados con los usos con al menos un historial de los 10 últimos movimientos realizados. El diseño de los títulos a desarrollar deberá garantizar la seguridad y rapidez en las transacciones. Funcionalmente deberá permitir: - La consulta de datos almacenados. La información mostrada en la consulta dependerá del agente que la realice; al personal de control del servicio prestado se mostrará aquella que permite validar su uso correcto y al propietario podrá proporcionar información personal mediante una clave de acceso que la tarjeta deberá poseer almacenada. - La validación del acceso al servicio pagado en un tiempo no superior a 250 milisegundos. - Permitir su uso como medio de pago para servicios distintos a los del transporte, en particular, en la red de aparcamientos de la Autoridad Única del Transporte de Gran Canaria y en general en cualquier otro sistema o servicio en el que se desee incluir como medio de pago. - Poderse utilizar como medio de pago por un periodo de tiempo parametrizable. - Permitir su uso en campañas de fidelización. - Posibilitar su personalización mediante datos del cliente para un posible uso personal e intransferible. Para este tipo de uso personal e intransferible deberá permitir su bloqueo y recuperación del saldo pendiente en el caso de pérdida o robo. 5/14

6 - Permitir su uso mediante claves de acceso. Inicialmente la tarjeta deberá estar diseñada para soportar los siguientes tipos: - Personalizado. Se construye registrando los datos personales del cliente al que se le entrega con su nombre, número identificador y foto impresos, inicialmente sin saldo. En caso de denuncia de pérdida, hurto o robo, se deberá bloquear en un plazo parametrizable y no superior a 24 horas y recuperar el saldo que tuviera. Inicialmente se distinguirán los siguientes tipos de tarjetas: a) Estudiante. b) Jubilado. c) Frecuente. d) Distancia. El tratamiento de los títulos personales permitirá la definición dinámica y automática del grupo de pertenencia, por ejemplo: si un cliente pertenece al grupo de estudiante y termina sus estudios, o se está en periodo no académico, entonces funcionará como usuario frecuente. O también, si un cliente perteneciente al grupo Frecuente, entonces cuando alcance su edad de jubilación pasará al grupo de Jubilado. - Al portador. No se registran los datos del cliente y su uso, por tanto, no es personal ni intransferible. En caso de pérdida, hurto o robo no se podrá bloquear ni recuperar su saldo. 6.- ESPECIFICACIONES GENERALES SOBRE LOS MÓDULOS SAM Los módulos SAM deberán cumplir con las siguientes especificaciones: - Formato ID Norma ISO /14

7 Las herramientas software para la programación y configuración de los módulos SAM forman parte del objeto de este concurso. 7.- PRINCIPIOS BÁSICOS SOBRE LA SEGURIDAD DE STUT Partiendo de la idea que la emisión de tarjetas, recargas y uso implica transacciones con valor monetario y que además, al ser un sistema ínter operable, repercutirán sobre distintos agentes del sistema (clientes, operadores y AUT) es fundamental que el sistema esté dotado de mecanismos que den seguridad a todos los participantes que intervienen en las transacciones. Por ello, y de cara a la seguridad, los distintos elementos que forman parte del STUT deberán tener presente los siguientes principios de operación: - Uso de módulos SAM con el objeto de: a) Autenticar a cada uno de los dispositivos que tengan acceso a las tarjetas. b) Acceder de forma segura a los datos almacenados en las tarjetas. c) Sellar los datos generados en la explotación. d) Garantizar la integridad (secuencia y completitud) de los datos. - Uso de protocolos seguros para la comunicación entre los distintos elementos del STUT (dispositivos de venta y recarga, sistemas de transferencia de datos de la explotación de los operadores, etc.) y el centro de proceso de datos de la Autoridad Única del Transporte de Gran Canaria, homologable con los sistemas bancarios. - Particular y especial atención a los mecanismos de control, detección, seguimiento y gestión en general de los registros duplicados, discordantes, incoherentes o incorrectos y de los posibles usos fraudulentos de los títulos de pago. 8.- SISTEMAS DE VENTA, CARGA Y RECARGA DE TARJETAS Estos sistemas serán dispositivos que se instalarán en los distintos puntos de venta, de carga y recarga de títulos de la red de transporte. Podrán funcionar como elementos añadidos a elementos ya existentes, por ejemplo cajeros de entidades bancarias, puntos 7/14

8 de información de la red de transporte, etc., o bien, como terminales para su uso en comercios o puntos de venta ya existente de la red de transporte o por Internet. En cada venta, carga o recarga estos elementos deberán: - Mostrar al cliente el saldo anterior y posterior de una carga o recarga. - Permitir la carga o recarga del saldo solicitado por el cliente, siempre y cuando dicha cantidad cumpla con las condiciones que se establezcan. - Proporcionar un recibo al cliente Además deberán poseer como mínimo las funcionalidades siguientes: - Autenticar al usuario operador del sistema, en el caso de terminales. - Registrar la autentificación con éxito de un usuario del sistema. Además deberá poderse configurar para que el sistema la comunique a una central de incidencias. También deberá registrarse la finalización de una sesión de venta y si se configura, su comunicación a la central de incidencias. - Poder establecer un límite máximo de autenticaciones erróneas seguidas, para que una vez alcanzado este máximo, bloquearse y comunicar el bloqueo a una central de incidencias. - Registrar y comunicar en tiempo real cada venta, carga y recarga de títulos. - Proporcionar información a los clientes sobre el estado de sus tarjetas. Para el caso de tarjetas de uso personal, se deberá requerir al cliente su clave de acceso a la información de la tarjeta. - El software (datos y programas) deberá ser actualizable tanto de forma asistida por un operador autorizado, como de forma automática, desasistida y remota desde un sistema central de administración de la red puntos de venta. - Definición dinámica del conjunto de eventos, por ejemplo: autenticación exitosa de operador de venta, transacciones de venta, carga y recarga, alarmas técnicas, etc. a registrar y comunicar en tiempo real. La redefinición de los eventos no deberá implicar la modificación del código de los 8/14

9 programas, por tanto se deberá realizar mediante archivos de datos de configuración. - Podrán funcionar también como puntos de captura de datos del cliente para aquellos títulos que sean de uso personal e intransferible. - Los cambios en los valores de las bonificaciones, tarifas y demás parámetros definidos en el tratamiento de los títulos deberán realizarse de forma automática desde un sistema central de administración de la red de puntos de venta, en ningún caso este tipo de cambio implicará cambio en el código de los programas. - Tratamiento de listas negras. Los sistemas deberán ser capaces, como mínimo de: identificar una tarjeta perteneciente a una lista negra, no permitiéndose operar con ella, registrar su detección, comunicar en tiempo real la detección y proceder a su desactivación. - Imprimir informes técnicos tanto a los operadores técnicos, como informes de servicio a los operadores de venta. - Uso de módulos SAM para el acceso a los datos almacenados en las tarjetas. - Uso de protocolos seguros de comunicación entre los sistemas de venta, carga y recarga y los sistemas centrales de la Autoridad Única del Transporte de Gran Canaria (central de incidencia y sistema central de administración), homologable con los sistemas bancarios. - Gestión de las ventas de títulos a los vendedores al público. Esta gestión deberá contemplar, al menos, el suministro de tarjetas a dichos vendedores con pago al contado y a crédito y el control de saldos de stocks tanto de títulos como de recargas. 9.- SOFTWARE DEL CENTRO DE PROCESO DE DATOS El Centro de Procesamiento de Datos, CPD en adelante, se compone de la infraestructura física, equipos de comunicaciones, procesamiento y almacenamiento, y de los programas informáticos que permiten: 9/14

10 - La consolidación y la administración de la totalidad de equipos y procesos que se ejecutan en el STUT. - La monitorización de los distintos dispositivos de venta y recarga de los títulos. - La administración de la seguridad. - La administración de las bases de datos que intervienen en el STUT. - La administración de las configuraciones. - Proporcionar un entorno de desarrollo para la modificación e incorporación de nuevos elementos software. - Llevar a cabo las políticas y procedimientos de seguridad física del CPD. Para ello, el CPD deberá: - Recoger y almacenar todos los datos de las cargas, validaciones y usos de los títulos, así como las incidencias de los puntos de venta y recarga. - Generar los informes diarios, semanales, mensuales y anuales de las recaudaciones, las ventas, el tráfico, las alarmas técnicas, los datos relacionados con la seguridad y el fraude. - Generar informes contables, entre otros los necesarios para efectuar la conciliación de la recaudación entre los distintos operadores del Sistema. - Generación de datos estadísticos. - Procesar los datos para generar la información que se suministrará a los otros sistemas de información de la AUT, como por ejemplo: sistema de control de las explotación de las concesiones, portal de información del transporte público, e incluso proporcionar información y retroalimentarse de otros sistemas de información más allá del ámbito de la AUT. 10/14

11 - Tener la flexibilidad para generar informes adicionales que requerirse en un futuro y poseer una herramienta de exportación que permita que los datos puedan ser analizados por otros manejadores de bases de datos o aplicaciones de gestión GENERACIÓN DE INFORMES Todos los datos recabados deben ser registrados en una base de datos para poder proceder, posteriormente, a las diferentes selecciones. Los análisis podrán hacerse en los siguientes períodos: por franjas horarias, diariamente, semanalmente, mensualmente y anualmente. Se podrán ver e imprimir los datos estadísticos en forma de cuadros y gráficos, según solicite el usuario. Al menos se deberá dotar al sistema de las consultas que proporcionen: - Información sobre la recaudación en las ventas. Las diferentes operaciones de creación, carga y recarga de tarjetas. Tanto las realizadas en máquinas de venta de la red de transporte de la isla de Gran Canaria, como las realizadas en máquinas externas a la red (comercios, entidades bancarias, etc.). El análisis se deberá poder realizar por cada tarjeta, por tipo de tarjeta, por una estación, por operador, por una línea, por un período de tiempo configurable: día, semana, mes, etc. - Información sobre los movimientos realizados por los viajeros. Cantidad de movimientos registrados en los equipos de facturación embarcado, por lector de tarjeta, por consola del conductor, por operador, por vehículo, por línea, por tipo de pago, por periodo de tiempo, por origen y/o destino del trayecto, etc. - Información sobre las operaciones de explotación realizadas por los operadores. Realización de expediciones, paso por paradas, por líneas, por franjas horarias, por periodos, etc. - Seguimiento de fallos de los equipos. Generando informes tanto de las alarmas de avería como las preventivas de los equipos, por tipo, por estación, por línea, etc., por un período configurable: día, semana, mes, etc. También deberán generarse informes sobre la no disponibilidad de los equipos, por tipo de máquinas, por estación, por línea, etc. e informes de intervenciones del personal de mantenimiento. 11/14

12 11.- DATOS SUMINISTRADOS POR LOS OPERADORES DE LA EXPLOTACIÓN Todas las empresas operadoras integradas en el sistema, suministrarán todos los datos obtenidos en la explotación en forma de archivo plano, o sea archivo que contendrá una secuencia cronológica de registros que representan a cada uno de los eventos que se producen en la explotación. La transferencia de estos archivos se realizará desde los sistemas de proceso de datos de las empresas operadoras al CPD de la Autoridad Única del Transporte de Gran Canaria. Esta transferencia se realizará usando protocolos de comunicación seguros y de forma automática, ya sea como consecuencia de una orden emitida desde el CPD de la Autoridad Única del Transporte, o bien, de forma planificada especificando fechas concretas o tipologías de fechas y horas de las transferencias, la unidad mínima de periodo de transferencia será el minuto. La aplicación del CPD de la Autoridad Única del Transporte responsable de recopilar los datos de la explotación forma parte del objeto de este concurso, ésta será responsabilizarse de: - Conectarse a los sistemas de los operadores dónde se almacenan los datos de la explotación. - Recibir desde dichos sistemas los archivos de la explotación. - Insertar los registros contenidos en los archivos en la base de datos que la Autoridad Única del Transporte destine para este fin. La inserción deberá comprobar la no duplicidad de los registros y la validez del contenido de los registros, verificando la coherencia de los contenidos de los campos de los registros, así como su estructuración correcta y generando archivos de diagnostico, informes y menajes asociados a los errores detectados en las inserciones. - Llevar a cabo la desconexión con los sistemas de los operadores, generando los registros de diagnóstico, informe y avisos asociados a la desconexión ENTORNO DE DESARROLLO Y FUNCIONAMIENTO DEL SOFTWARE a) El sistema objeto del contrato, quedará integrado como un subsistema dentro del Sistema de Información General de la Autoridad Única del Transporte de Gran Canaria, cruzando y compartiendo información con otros subsistemas como el Portal de Servicios, la pasarela de pago (web), módulos de datos provenientes de los operadores de transportes (SAE, viajeros,...), GIS, sistema de información al viajero y otros software de gestión del transportes y coordinación de los servicios. Por ello, el 12/14

13 software desarrollado deberá ser permeable y permitir la integración en el Sistema General mediante servicios web (web services) o herramientas similares de tecnología avanzada, abierta y simple. b) El software tendrá una arquitectura modular y escalable, de manera que se puedan poner en marcha las distintas funcionalidades a medidas que vayan siendo comprobadas y validas, permitiendo además las futuras ampliaciones que fuesen necesarias. c) Como ya se ha indicado el sistema debe funcionar en todas sus etapas y elementos con los criterios de seguridad homologables a los sistemas bancarios y en todo caso garantizando la seguridad, confianza e integridad para todos los actores (operadores de transporte y autoridad) y para terceros (banca, servicios de ocio, etc). d) Los sistemas así como la información contenida en ellos deberá cumplir con las leyes en vigor que afectan a la protección de datos de tipo personal y a las garantías jurídicas exigibles a los sistemas de información moderna. e) El sistema estará provisto de la capacidad de realizar copias de seguridad y registro de almacenamiento que garanticen la integridad y seguridad técnica, jurídica y funcional de todos los componentes y datos del sistema. f) El software del sistema de información objeto del contrato se desarrollará en entornos abiertos. g) Los modelos de datos a emplear en la definición e implementación de todos los que sean necesarios en el presente contrato se regirán por los determinados por el CEN (comité europeo de normalización) 13.- PRESUPUESTO DEL CONTRATO Y PLAZO DE EJECUCIÓN El presupuesto máximo de licitación para el análisis, implementación, validación y puesta en marcha definitiva del sistema y su mantenimiento y explotación durante el primer año posterior a la recepción del sistema será por un importe máximo de incluyendo todas aquellas licencias, productos y accesorios necesarios para su normal y correcto funcionamiento (este importe es sin incluir el IGIC que deberá soportar la administración). El importe máximo se desglosa de la siguiente manera: 1.- Análisis, implementación, validación y puesta en marcha definitiva. CUATROCIENTOS CINCUENTA MIL EUROS ( ,00 ). 2.- Mantenimiento y explotación del sistema durante el año posterior a su recepción. CIEN MIL EUROS ( ,00 ). 13/14

14 Respecto al plazo de ejecución de los trabajos será de un máximo de 8 meses desde la adjudicación. 14/14