Sistema de Compras Públicas de la Ciudad de México/Oportunidades De Negocio

Prebases para la Prestación de servicios de peaje y control de acceso en la Línea 6 y 7 del Metrobús de la CDMX
CERRADO

Datos del Proceso
Número de comentarios

0

Número de sugerencias

0

Número de preguntas

94

Comentario destacado

0

Anexo cuatro. Especificaciones técnicas del sistema de peaje y control de acceso

Para descargar ésta versión del documento, útiliza el boton de descarga que se encuentra al final de la págna o da clik aquí.(la descarga puede tardar unos minutos por el tamaño del documento)

1.   Introducción

El presente Anexo tiene como objetivo describir las características, funcionalidades y requerimientos mínimos para el Sistema de Peaje y Control de Acceso que será implementado en los corredores de Transporte Público de Pasajeros EJE 5 NORTE Y METROBÚS REFORMA correspondiente a las Línea 6 y 7 del Sistema Metrobús.

El Sistema de Peaje y Control de Acceso para Metrobús está definido como el conjunto de componentes tecnológicos (hardware y software) que “LA EMPRESA” deberá instalar operar y mantener durante la vigencia del CONTRATO DE PRESTACIÓN DE SERVICIOS DE PEAJE Y CONTROL DE ACCESO EN LOS CORREDORES EJE 5 NORTE Y METROBÚS REFORMA DEL SISTEMA DE CORREDORES DE TRANSPORTE.

En el capítulo 2 se definen algunos términos técnicos utilizados en el documento, en orden alfabético. Para cada uno de estos se presenta una abreviatura y una definición.

En el capítulo 3 se presenta una descripción del Sistema Metrobús. En este se muestran las características principales de una línea clásica y las características adicionales con las que cuentan las líneas 4 y 7, y se explica el funcionamiento de los transbordos entre las diferentes líneas del Sistema Metrobús.

En el capítulo 4 se describe un diseño de alto nivel para el Sistema de Peaje y Control de Acceso. Dicho diseño incluye una arquitectura general que identifica los componentes que hacen parte del sistema, una descripción de las funciones de cada uno de estos, y las interacciones entre ellos.

En el capítulo 5 se presenta una descripción de la Tarjeta de Movilidad Integrada, usada por los usuarios para acceder a los servicios del Sistema Metrobús. También se resumen los distintos perfiles de usuario que hacen parte del modelo de datos de dicha tarjeta.

En el capítulo 6 se detalla el alcance principal de la implementación del Sistema de Peaje y Control de Acceso. Dicho alcance incluye los requerimientos funcionales y especificaciones técnicas de los elementos en terminales y estaciones, los elementos externos a estas, la API para interacción con medios de pagos que se debe incorporar en algunos de estos elementos, el sistema central y los canales de comunicación.

En el capítulo 7 se especifica el alcance de la implementación del pago con códigos de barras 2D en el Sistema de Peaje y Control de Acceso. Dicho alcance incluye los requerimientos que “LA EMPRESA” debe cumplir para llevar a cabo esta implementación.

En el capítulo 8 se detalla el alcance de la implementación del pago con medios de pago EMV sin contacto en el Sistema de Peaje y Control de Acceso. Dicho alcance incluye los requerimientos que “LA EMPRESA” debe cumplir para llevar a cabo esta implementación.

Por último, en el capítulo 9 se presentan las responsabilidades de “LA EMPRESA” relacionadas con el recaudo y la recolección del dinero. Estas incluyen la recolección de valores y los depósitos al fideicomiso.

2.   Definiciones

Nombre

Abreviatura

Definición

App CDMX

AppCDMX

Es una aplicación móvil desarrollada por la Agencia Digital de Innovación Pública que centraliza el acceso a las aplicaciones existentes de las distintas entidades gubernamentales de la administración pública de la ciudad. Está disponible en Google Play y App Store

Bandera de pago

BP

Franquicia internacional como American Express, Mastercard o Visa, expedidas en México que comunica autorizaciones y liquidaciones correspondientes a transacciones de pago con medios de pago EMV entre los bancos de los comercios y los bancos emisores

Cámaras IP

CAM

Cámaras para registro de incidencias en estación

Centros de Atención al Usuario

CAU

Módulo ubicado en una estación de Metrobús que brinda el apoyo a los usuarios en incidencias con el Sistema de Peaje y Control de Acceso. Además, brinda información general del sistema

CoDi

CoDi

Es una plataforma desarrollada por Banco de México para facilitar las transacciones de pago y cobro a través de transferencias electrónicas, de forma rápida, segura y eficiente, a través de teléfonos móviles, sin ningún costo

Diodo Emisor de Luz

LED

Light-Emitting Diode, dispositivo semiconductor (diodo) que emite luz

Equipo de comunicaciones

COM

Elemento de conectividad entre los equipos en estaciones, centros de control y el sistema central

Estándar PCI DSS

PCI DSS

Es un estándar de seguridad definido por PCI Security Standards Council desarrollado para fomentar y mejorar la seguridad de los datos del titular de la tarjeta y facilitar la adopción de medidas de seguridad uniformes a nivel mundial. El estándar se aplica a todas las entidades que almacenan, procesan o transmiten datos del titular de la tarjeta y/o datos confidenciales de autenticación

Europay Mastercard Visa

EMV

Es un estándar mundial de interoperabilidad de tarjetas bancarias

Garita o Puerta de Cortesía

PSC

Puerta de servicio y cortesía para acceso de usuarios con un perfil autorizado para ingresar por esa puerta

Grabadora de Video en Red (Network Video Recorder)

NVR

Equipo de grabación o digitalización de las imágenes que proceden de las cámaras conectadas

Interfaz de programación de aplicaciones (Application Programming Interface)

API

Conjunto de subrutinas, funciones y procedimientos que ofrece una librería para ser utilizado por otro software como una capa de abstracción

Lista Blanca

LB

Lista que contiene los identificadores de los módulos SAM locales autorizados para interactuar con la Tarjeta de Movilidad Integrada. Estas listas permiten rechazar módulos SAM en casos de detección de actividades de fraude llevadas a cabo con estos elementos

Lista Negra

LN

Una o más listas que contienen los identificadores de las Tarjetas de Movilidad Integrada y medios de pago EMV sin contacto que no deben ser aceptados por los dispositivos que interactúan con estos medios de pago. Estas listas permiten el bloqueo de medios de pago en casos de robo o pérdida. En particular, para medios de pago EMV sin contacto permiten el bloqueo temporal en casos de denegación de transacciones y bloqueo por expiración del medio de pago

Location ID

LID

Ubicación de equipos en el Sistema de Peaje y Control de acceso conforme a las reglas establecidas

Módulo de Acceso Seguro (Secure Access Module)

SAM

Es un pequeño componente de hardware que se utiliza para mejorar la seguridad en dispositivos que requieren efectuar transacciones seguras. Almacena llaves criptográficas y realiza operaciones de autenticación y cifrado para garantizar la seguridad de las comunicaciones entre el dispositivo y los medios de pago, o el dispositivo y el sistema central.

Planta Eléctrica

PLE

Equipo de respaldo eléctrico de gran capacidad. En caso de falla de la UPS, proveen energía de emergencia, por un tiempo determinado

SIM Card

SIM

Es un pequeño chip desmontable que identifica un dispositivo móvil en una red de comunicación. Una SIM almacena de forma segura información específica relacionada con el operador de telefonía móvil

Sistema Metrobús

MB

Sistema Metrobús es un sistema de transporte BRT (Bus Rapid Transit) diseñado para mejorar los servicios de transporte de superficie en la Ciudad de México

Sistema de Pagos Electrónicos Interbancarios

SPEI

Es la infraestructura de pagos del Banco de México que permite a sus participantes, (bancos, casa de bolsa, sofipos y otras entidades financieras reguladas) enviar y recibir pagos entre sí para poder brindar a sus clientes finales el servicio de transferencias electrónicas en tiempo real

Sistema de alimentación ininterrumpida (Uninterruptible Power Supply)

UPS

Equipo de respaldo eléctrico que en caso de un apagón u otra falla eléctrica provee energía de emergencia, por un tiempo determinado

Terminal de Venta y Recarga Completa (Ticket Vending Machine Completa)

TVMC

Máquina de venta y recarga de tarjetas equipada con aceptador de billetes y monedas; así como con dispensador de tarjetas

Terminal de Venta y Recarga Ligera (Ticket Vending Machine Ligera)

TVML

Máquina de recarga de tarjetas sin aceptador de billetes ni dispensador de tarjetas, solo acepta monedas

Terminal Móvil para Supervisión

TMS

Terminal móvil para la inspección, validación, consulta, recarga y venta de la Tarjeta de Movilidad Integrada en situaciones de contingencia

Torniquete de Entrada

TQE

Equipo para el control de acceso a través de un trípode

Torniquete de Salida

TQS

Equipo para el control de salidas a través de un trípode

Validador

VAL

Lector de tarjetas sin contacto que realiza la validación del saldo en las Tarjetas de Movilidad Integrada

 

3.   Sistema de transporte Metrobús

Parte central del desarrollo de una ciudad es un sistema efectivo de transporte público. Para la mayoría de la población de las ciudades, el transporte público es el único medio para acceder a su empleo, educación y servicios públicos, por lo que la Ciudad de México tiene una demanda constante de mayor movilidad.

Metrobús es un sistema de transporte BRT (Bus Rapid Transit) diseñado para mejorar los servicios de transporte de superficie en la Ciudad de México, buscando generar una red de transporte colectivo de pasajeros que se interconecte con la red del Metro de la ciudad y otros medios de transporte.

Metrobús es un sistema de transporte basado en autobuses de alta tecnología, que brinda movilidad urbana rápida y eficiente por medio de la integración de una infraestructura preferente, operaciones frecuentes y excelencia en la calidad en el servicio.

El Organismo Descentralizado Metrobús fue creado en marzo de 2005 con el objetivo de planear, administrar y controlar el Sistema de Corredores de Transporte Público de Pasajeros del Distrito Federal, y disminuir los tiempos de recorrido ofreciendo un transporte eficiente, seguro y de calidad.

Metrobús inició sus operaciones el 19 de junio de 2005 con la Línea 1 Corredor Insurgentes, a lo largo de 19.06 kilómetros de la Avenida Insurgentes desde la terminal Indios Verdes hasta la terminal Doctor Gálvez. Debido al éxito y la demanda de esta línea, el 13 de marzo de 2008 el corredor fue extendido 10 kilómetros en dirección sur hasta la terminal El Caminero constituyendo el primer corredor de transporte ordenado en la ciudad. Este corredor tiene conexión con el Sistema de Transporte Colectivo Metro (STC) Línea 1, 2, 3, 9 y B, y con el Tren Suburbano (transporte público del Estado de México).

El 18 de diciembre de 2008 se inaugura la Línea 2 Corredor Eje 4 Sur con una extensión de 20 kilómetros que conecta el poniente con el oriente de la ciudad desde la terminal de Tacubaya hasta la terminal de Tepalcates. Esta línea tiene conexión con el STC Línea 1, 2, 3, 7, 8, 9 y A, y con el transporte Cero Emisiones.

El 9 de febrero de 2011 inició la operación de la Línea 3 Corredor Eje 1 Poniente, la cual tiene un recorrido de 17 kilómetros que va desde la terminal Tenayuca por la Calzada Vallejo, Prolongación Guerrero, Balderas y Cuauhtémoc, hasta llegar a la terminal de Etiopía. Esta línea tiene conexión con el STC Línea 6, B, 2, 3, 1 y 9, y el Tren Suburbano.

Posteriormente, el 1 de abril de 2012 se inauguró la Línea 4 Corredor Buenavista - Centro Histórico - San Lázaro - Aeropuerto Internacional de la Ciudad de México, con un recorrido de 20 kilómetros y dos rutas: Ruta Sur y Ruta Norte. La Ruta Sur circula por Eje 1 Norte (Mosqueta), Juan Cuamatzin, Eje 1 Oriente (Anillo Circunvalación), Eje 2 Oriente (Congreso De la Unión) y Eje 3 Oriente (Eduardo Molina) hasta la terminal San Lázaro. La Ruta Norte circula por Puente de Alvarado, República de Venezuela, Héroe de Nacozari, General Miguel Alemán, Eje 3 Oriente (Eduardo Molina), Fuerza Aérea Mexicana y Circuito interno del Aeropuerto Internacional de la Ciudad de México con terminales Aeropuerto Terminal 1 y 2. Esta tiene conexión con el STC Línea 1, 2, 3, 4, 5, 8, B, Tren Suburbano, Corredor Cero Emisiones y Terminal 1 y 2 del AICM.

El 5 de noviembre de 2013, entró en operación la Línea 5 Corredor Eje 3 Oriente - Corredor Río de los Remedios - Glorieta de Vaqueritos, la cual tiene un recorrido de 10 kilómetros que va por la Avenida Eduardo Molina desde la terminal Río de los Remedios hasta la terminal San Lázaro. Esta línea tiene conexión con el STC Línea 1, 5, y B, y la Terminal de Autobuses de Pasajeros de Oriente (TAPO).

El 21 de enero de 2016 inició la operación de la Línea 6 Corredor Eje 5 Norte, que tiene un recorrido que va desde Villa de Aragón hasta El Rosario, a través de diversas vialidades tales como, Francisco Morazan, Camino San Juan de Aragón, Calzada San Juan de Aragón, Av. Montevideo, Calle Pte 140 y Av. De las Culturas.

El 4 de marzo de 2018 entró enoperación la Línea 7 Corredor "REFORMA", que tiene un recorrido que va desde Indios Verdes hasta Campo Marte, a través de Av. Paseo de la Reforma y Calzada de los Misterios. Esta línea tiene interconexión con las líneas 1, 4 y 6 de Metrobús. Los vehículos que transitan por esta línea son de doble piso y están equipados con sistema de peaje embarcado, gestionando las zonas de transbordo a través del GPS integrado en la consola del operador.

El 7 de septiembre de 2020 inició operaciones la ampliación de la Línea 5 de Metrobús desde San Lázaro hasta Las Bombas, a través del Eje 3 Oriente, teniendo interconexión con la línea 12 del Sistema de Transporte Colectivo Metro.

El 10 de marzo de 2021 inició operaciones la ampliación de la Línea 3 de Metrobús desde Etiopía hasta Pueblo Sta. Cruz Atoyac, a través del Eje 1 Poniente, teniendo interconexión con la línea 2 de Metrobús.

El 3 de mayo de 2021 inició operaciones la segunda etapa de la ampliación de la Línea 5 de Metrobús desde Las Bombas hasta Preparatoria 1, a través del Eje 3 Oriente.

El 3 de junio de 2021 inició operaciones la ampliación de la Línea 4 de Metrobús desde San Lázaro hasta Pantitlán, a través del Eje 1 Norte, teniendo interconexión con la línea 1, 5, 9 y A del Sistema de Transporte Colectivo Metro.

El Sistema de Transporte Metrobús es flexible, combina estaciones con terminales tipo parabus, vehículos, servicios, corredores y alta tecnología en un sistema integral con una identidad positiva que evoca una imagen única.

El pago se realiza por medio de la Tarjeta de Movilidad Integrada, la cual puede ser adquirida en las máquinas de venta y recarga de tarjetas, presentes en todas las estaciones de Metrobús. También en los puntos de venta instalados en el Sistema de Transporte Colectivo Metro y el Sistema de Transportes Eléctricos de la Ciudad de México, ya que se comparte el mismo medio de pago entre los organismos mencionados. Los transbordos entre Línea 1, Línea 2, Línea 3, Línea 4, Línea 5, Línea 6 y Línea 7 son gratuitos siempre y cuando se realicen dentro de las primeras dos horas de haber ingresado al sistema.

Cabe señalar que el Gobierno de la Ciudad de México a través de la publicación de la Ley de Movilidad del Distrito Federal el 14 de Julio de 2014 en la Gaceta Oficial del Distrito Federal, estableció como principio de interés general el establecimiento del Sistema Integrado de Transporte Público, en el cual se contempla un mismo medio de pago, por lo que es del alcance de los servicios requeridos en este instrumento y se debe realizar la interacción con los demás sistemas de cobro existentes en los Organismos de transporte, en las que ya opera, y con los que en un futuro se integren bajo el marco de la Ley de Movilidad del Distrito Federal.

La operación del servicio controlado por Metrobús cuenta con una flota de 670 unidades de parque vehicular en el Sistema Metrobús, concesionado a 15 (quince) empresas privadas y a la Red de Transporte de Pasajeros (RTP), organismo público del Gobierno de la Ciudad de México.

Las empresas privadas, junto con la RTP y Metrobús han constituido un fideicomiso privado para la contratación de las empresas de Peaje y Control de Acceso que operan en el sistema. Metrobús supervisa el desempeño de las diferentes entidades señaladas. Además, preside los Comités Técnicos de ese Fideicomiso.

3.1 Principales características de una línea clásica de Metrobús

  1. Carril confinado para transporte público.
  2. Estaciones con un diseño uniforme de rápido acceso a los autobuses (plataforma alta).
  3. Infraestructura que incluye elementos de accesibilidad para personas con discapacidad.
  4. Sistema de prepago con tarjetas inteligentes.
  5. Infraestructura de torniquetes, validadores y máquinas de venta y recarga en la estación.
  6. Sistema de control centralizado por medio de modernos instrumentos de comunicación.
  7. Mejoras en las condiciones de tránsito incluido la preferencia de semáforos para Metrobús, eliminación de la mayoría de las vueltas izquierdas y mejoras en general al tránsito de los vehículos particulares.
  8. Reducción de emisiones de gases de efecto invernadero por cambio tecnológico, cambio modal y mejoras en la vialidad.
  9. Sistema de vigilancia remota.

3.2 Características adicionales en la Línea 4 y Línea 7 de Metrobús

  1. Validación a bordo de autobuses.
  2. Registro de ascensos y descensos a través de cámaras estereoscópicas o dispositivos que realicen la función de conteo de pasajeros al ascenso/descenso.
  3. Dispositivo con la capacidad de visualizar los registros de los ascensos y descensos, así como la elección de ruta y cambio de tarifa el cual que opera en forma adicional a la validación de tarjetas.
  4. Máquinas de venta y recarga en las estaciones terminales.
  5. Tarifa diferencial para el servicio al Aeropuerto.

Las características de las líneas 4 y 7 de Metrobús son diferentes ya que, con la excepción de los puntos terminales, no hay estaciones. En su lugar, existen parabuses y el recaudo se hace, en la mayoría de los casos, directamente a bordo de los autobuses. Adicionalmente, estas líneas cuentan con una red externa de recarga para las tarjetas, de la cual hacen parte puntos ubicados en ciertas tiendas de la vecindad de los parabuses.

3.3 Transbordo entre líneas

La posibilidad de transbordo se proporcionará al usuario en las estaciones donde se cruzan las diferentes líneas del sistema de transporte Metrobús. Es decir, estaciones de transferencia física entre líneas diferentes. Estas son llamadas estaciones de transbordo. Es importante tener en cuenta que las estaciones de transbordo pueden aumentar en la medida en que el Sistema de Corredores Metrobús crezca por lo que es necesario que todas las estaciones puedan ser consideradas como una posible estación de transbordo, lo que implica que todos sus dispositivos de validación sean parametrizables en este sentido y que esta parametrización se realice a través del sistema central,  integrando la geolocalización del bus al llegar a algún parabús para habilitar en dicho punto el validador del autobús como de transbordo.

El costo por concepto de transbordo será de $0.00 (cero pesos mexicanos) para el usuario en el momento de realizar la transferencia entre líneas. Se aclara que todas las tarifas y perfiles deben ser parametrizables y sin costo por cambios posteriores a tarifas y perfiles en sistema y tarjetas, a través del sistema central.

El transbordo en Metrobús se gestionará por tiempo y por línea realizándose de la siguiente manera:

  1. Ventana de tiempo: El tiempo máximo que tendrá un usuario para realizar el transbordo será de 120 minutos contabilizados desde su ingreso al sistema.
  2. Número de transbordos: Tomando en consideración la validación por concepto del peaje, el usuario podrá realizar el transbordo entre líneas tomando en cuenta la fecha y hora en que realizó la validación. A partir de ese momento dispondrá de 120 minutos para realizar la transferencia entre líneas. Es importante señalar que los únicos sitios autorizados para llevar a cabo el transbordo serán las estaciones señaladas como puntos de transferencia para los usuarios del sistema. No se autoriza el transbordo de más de un usuario por tarjeta.

Por otro lado, es indispensable que cada operador del Sistema de Peaje y Control de Acceso para cada una de las líneas tenga la información de los usuarios que ingresan al sistema por el concepto de transbordo. Esta regla implica que el transbordo se debe realizar validando la tarjeta en los equipos de todas las líneas.

A continuación, se describe el proceso que se lleva a cabo en un transbordo:

  1. El usuario ingresa al sistema en cualquier estación del Sistema Metrobús validando con su tarjeta. En este caso se descuenta el valor del viaje en la tarjeta del usuario.
  2. El usuario se dirige a la estación de transbordo.
  3. Al momento de realizar la validación en la estación de transbordo, el validador del operador calcula el tiempo que ha pasado desde su uso en la estación del Sistema Metrobús.
  4. Si el tiempo es inferior o igual al tiempo permitido para el transbordo, se libera el torniquete sin descuento en la tarjeta.
  5. Si el usuario está validando la tarjeta en la misma línea donde se originó el viaje, la liberación del torniquete se hará descontando la tarifa en la tarjeta.
  6. Si el usuario está validando la tarjeta en la misma línea donde realizó el último transbordo, la liberación del torniquete se hará descontando la tarifa en la tarjeta.
  7. Si el usuario está validando la tarjeta luego de realizar una recarga, entonces la liberación del torniquete se hará descontando la tarifa en la tarjeta.
  8. El validador graba un registro de transbordo en su memoria. Este registro se transmitirá hacia la base de datos del sistema central para que pueda emitir la información estadística sobre transbordos. Además, la información será grabada en la tarjeta para prohibir una nueva posibilidad de transbordo fuera del tiempo establecido.
  9. Si el tiempo es superior al señalado en la ventana de tiempo, la liberación del torniquete se hará descontando la tarifa en la tarjeta.

Las reglas aquí señaladas deben cumplirse tanto en el validador de torniquete o de autobús, como en el de la puerta de cortesía. Los parámetros de tiempo y validación de transbordo deben ser parametrizables a petición de Metrobús y se podrán modificar en cualquier momento conforme a las necesidades del sistema de transporte sin costo adicional.

Adicionalmente, el sistema debe de estar preparado para poder activar el transbordo entre organismos que conforman el Sistema Integrado de Transporte de la Ciudad de México en caso de que en un futuro se necesite habilitar esta opción, por lo cual la proponente debe de hacer los desarrollos a que haya lugar bajo las reglas que en su momento la ciudad defina.

4.   Descripción del Sistema de Peaje y Control de Acceso

Para los corredores, “EJE 5 NORTE” Y “METROBÚS REFORMA” correspondiente a la Línea 6 y 7 del Sistema Metrobús se requiere un Sistema de Peaje y Control de Acceso que permita:

  1. Recaudar todos y cada uno de los recursos generados por la prestación del servicio público de transporte de pasajeros, utilizando como medio de acceso la Tarjeta de Movilidad Integrada,
  2. La venta y recarga de la Tarjeta de Movilidad Integrada
  3. Para Línea 6 realizar el control de acceso a terminales y estaciones del corredor mediante validadores en los torniquetes y puertas de cortesía
  4. Para Línea 7 realizar el control de acceso a los autobuses, terminales y estaciones del corredor mediante validadores en los autobuses, torniquetes y puertas de cortesía
  5. Permitir múltiples formas de pago para el acceso al sistema en terminales y estaciones
  6. Almacenamiento del sistema de peaje en la consola del conductor a bordo del autobús.
  7. Geolocalización de autobuses, esta función está relacionada directamente al sistema de peaje y control de acceso para que la validación se registre a bordo del autobús identificando el parabus/estación donde se realiza la validación.
  8. La consolidación y generación de informes de la información de las transacciones generadas en los equipos instalados en terminales, autobuses y estaciones
  9. La consolidación de la información generada por el sistema de peaje y control de acceso en donde Metrobús disponga.

 

La Figura 1 presenta una arquitectura de alto nivel para el Sistema de Peaje y Control de Acceso.

Dicha arquitectura está conformada por cinco niveles que interactúan entre sí. Cada nivel presenta unos elementos representados por unas cajas en el diagrama. Las cajas con borde de color naranja son elementos que son especificados por la ciudad. Las cajas con borde de color azul son elementos que debe suministrar “LA EMPRESA” y las cajas con borde de color rojo son elementos que pertenecen a Metrobús o que “LA EMPRESA” debe entregar a Metrobús. Por otra parte, las interacciones entre los elementos se representan con líneas de color verde y azul. Las de color verde son las comunicaciones que estarán a cargo de “LA EMPRESA” y las de color azul son interacciones que no estarán a cargo de esta.  A continuación, se presenta una descripción de cada nivel y de los elementos que la componen.

  • Nivel 0: engloba los medios de pago que están o estarán habilitados dentro del Sistema de Peaje y Control de Acceso. De estos hacen parte:
  • Tarjeta de transporte: es la Tarjeta de Movilidad Integrada usada por los usuarios para acceder a los servicios del Sistema Metrobús. Este medio de pago puede interactuar con los siguientes dispositivos de nivel 1:
  1. Dispositivo portátil, el cual interactúa con el medio de pago para consultar el saldo, redimir recargas remotas y consultar el historial de transacciones. No formará parte del alcance inicial del contrato, sin embargo, debe de evaluarse cuando Metrobús o la Ciudad lo solicite.
  2. TVMC y TVML, la cual interactúa con el medio de pago para consultar el saldo, realizar recargas y redimir recargas remotas
  3. Terminal móvil para supervisión, el cual interactúa con el medio de pago para realizar operaciones de inspección, consulta de saldo, venta, recarga y validación
  4. Dispositivos de personalización del centro de atención al usuario, el cual interactúa con el medio de pago para realizar operaciones sobre la Tarjeta de Movilidad Integrada. Esto con el objetivo de resolver peticiones, quejas y reclamos de los usuarios del Sistema Metrobús que requieran modificaciones en la tarjeta
  5. Validadores, los cuales interactúa con la tarjeta para aplicar las reglas tarifarias del Sistema Metrobús
  • Código de barras 2D: permite el pago de la tarifa para acceder a los servicios del Sistema Metrobús a través de códigos de barras 2D que son generados por una aplicación móvil instalada en dispositivos móviles inteligentes o que son generados en la TVMC y TVML a través de la impresión en un ticket. En el diagrama de arquitectura este medio de pago aparece con línea punteada, pues no hace parte del alcance principal del Sistema de Peaje y Control de Acceso, sino del alcance de pagos con códigos de barras 2D, el cual será explicado con mayor detalle más adelante en este anexo. Este medio de pago puede interactuar con los siguientes dispositivos:
  1. Validadores, los cuales están equipados con lectores de códigos de barras 2D para leer y procesar la información codificada en los códigos de barras presentados a través de un dispositivo móvil inteligente
  • Tarjetas bancarias EMV sin contacto: son tarjetas de débito y crédito con tecnología EMV sin contacto que permiten el pago de la tarifa para acceder a los servicios del Sistema Metrobús. En el diagrama de arquitectura este medio de pago aparece con línea punteada, pues no hace parte del alcance principal del Sistema de Peaje y Control de Acceso, sino del alcance de pagos con medios de pago EMV sin contacto, el cual será explicado con mayor detalle más adelante en este anexo. Este medio de pago puede interactuar con los siguientes dispositivos:
  1. Validadores, los cuales están equipados con lectores EMV para interactuar con tarjetas bancarias EMV sin contacto de las distintas marcas o banderas de pago que se aceptan en México
  • Nivel 1: corresponde a las herramientas a las que pueden acceder los usuarios para conocer información del sistema y a los dispositivos de lectura/escritura que interactúan con los medios de pago.
  • TVMC y TVML: máquinas de autoservicio que permiten la venta y recarga de la Tarjeta de Movilidad Integrada. Por medio de estas también será posible realizar una recarga haciendo uso de CoDi. Dichas máquinas deben estar preparadas para interactuar con:
  1. El SAM físico de manera local a través de una API para interacción con medios de pago, para gestionar la seguridad de las transacciones realizadas en la Tarjeta de Movilidad Integrada. También deberá estar preparada para la habilitación del uso de SAM remoto, el cual no formará parte del alcance inicial, y podrá ser incluido posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” Y “METROBÚS” para su implementación.
  2. El sistema central a través de una API para interacción con medios de pago para intercambiar información transaccional, parámetros operacionales del sistema (estructura tarifaria, listas negras, listas blancas) y actualizaciones de software
  3. La Tarjeta de Movilidad Integrada a través de un lector y una API para interacción con medios de pago para realizar transacciones, como recarga y redención de recarga remota la cual no formará parte del alcance inicial, y podrá ser incluida posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” y “METROBÚS” para su implementación.
  • Terminal móvil para supervisión: es un dispositivo que permite realizar operaciones de inspección, consulta de saldo, venta, recarga y validación sobre la Tarjeta de Movilidad Integrada en casos de contingencia. Dicho dispositivo debe estar preparado para interactuar con:
  1. La tarjeta de Movilidad Integrada a través un lector y una API para interacción con medios de pago para realizar las operaciones de inspección, consulta de saldo, venta, recarga y validación
  2. El SAM físico de manera local a través de una API para interacción con medios de pago, para gestionar la seguridad de las transacciones realizadas en la Tarjeta de Movilidad Integrada. También deberá estar preparada para la habilitación del uso de SAM remoto, el cual no formará parte del alcance inicial, y podrá ser incluido posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” Y “METROBÚS” para su implementación.
  3. El sistema central a través de una API para interacción con medios de pago para intercambiar información transaccional y parámetros operacionales del sistema
  • Centro de atención al usuario: son sitios donde se proporciona información sobre el Sistema Metrobús y se realiza la atención de incidencias y fallas con las Tarjetas de Movilidad Integrada. Estos estarán equipados como mínimo con un PC de última generación y un lector. El PC debe estar preparado para interactuar con un aplicativo con una API para interacción con medios de pago que permite la interacción con el SAM físico de manera local, para gestionar la seguridad de las operaciones realizadas por medio del lector sobre la Tarjeta de Movilidad Integrada, y la interacción con el sistema central para intercambiar información transaccional. También deberá estar preparada para habilitar el uso de SAM remoto, el cual no formará parte del alcance inicial, y podrá ser incluido posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” Y “METROBÚS” para su implementación.
  • Dispositivo de personalización: permite modificar diferentes parámetros en la Tarjeta de Movilidad Integrada. Dicho dispositivo debe estar preparado para interactuar con:
  1. La tarjeta de Movilidad Integrada a través un lector y una API para interacción con medios de pago para llevar a cabo el proceso de personalización
  2. El SAM físico, de manera local, a través de una API para interacción con medios de pago, para gestionar la seguridad de las transacciones realizadas. También deberá estar preparada para la habilitación del uso de SAM remoto, el cual no formará parte del alcance inicial, y podrá ser incluido posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” Y “METROBÚS” para su implementación.
  3. El sistema central a través de una API para interacción con medios de pago para intercambiar información transaccional, parámetros operacionales del sistema (estructura tarifaria, listas negras, listas blancas) y actualizaciones de software.
  • Validadores: es un dispositivo que realiza transacciones de validación y efectúa el cobro de la tarifa para permitir el ingreso de los usuarios al Sistema Metrobús. Dicho dispositivo debe estar preparado para interactuar con:
  1. La tarjeta de Movilidad Integrada a través un lector, un SAM local y una API para interacción con medios de pago para llevar a cabo la transacción de validación
  2. Los códigos de barras 2D a través de un lector de códigos de barras, el cual forma parte de la solución desde el inicio del contrato.
  3. Los medios de pago EMV sin contacto a través de un lector EMV para llevar a cabo una transacción bancaria, el cual forma parte de la solución desde el inicio del contrato.
  4. Los autobuses, torniquetes de entrada y las puertas de cortesía o garita para habilitar el paso al usuario
  5. El sistema central a través de una API para interacción con medios de pago para intercambiar información transaccional, parámetros operacionales del sistema (estructura tarifaria, listas negras, listas blancas) y actualizaciones de software
  6. Sistema de geolocalización que permita asignar las transacciones en el autobús, de acuerdo al parabús donde la validación haya sido realizada.
  • Dispositivo de conteo de ascensos y descensos: Dispositivo instalado en las puertas del autobús para el conteo de los usuarios que entran y salen por las puertas del autobús. Dicho dispositivo debe estar preparado para interactuar con:
  1. El sistema central para enviar los datos del conteo de cada uno de los usuarios que entran y salen por las puertas del autobús el cual debe tener una precisión de al menos 98%.
  • Nivel 2: corresponde a los dispositivos que concentran información del sistema o que hacen parte de un sistema eléctrico complementario. Estos pueden abarcar estaciones y terminales enteras o abarcar estaciones agrupadas. Del nivel 2 del Sistema de Peaje y Control de Acceso hacen parte un sistema de videovigilancia conformado por cámaras y NVR, y un sistema de suministro eléctrico conformado por UPS y plantas eléctricas. A continuación, se presenta una descripción de cada uno de estos elementos:
  • Cámaras: realizan la grabación de video por medio de cámaras de videovigilancia instaladas en las estaciones y terminales. Dichas cámaras interactúan con el NVR para transmitir el video.
  • NVR (Network Video Recorder): almacena el video generado por las cámaras de videovigilancia. Este dispositivo interactúa con un software de gestión de videovigilancia que opera “LA EMPRESA” y un software que permite el acceso remoto al sistema de videovigilancia por parte de Metrobús.
  • UPS: es un sistema de alimentación no interrumpible capaz de mantener energizados los equipos de peaje y control de acceso de una estación o terminal durante una contingencia donde falle la red eléctrica. Dicho sistema interactúa con software de gestión eléctrica que permite su monitoreo.
  • Planta eléctrica: es un sistema de generación de energía a gasolina o diésel capaz de mantener energizados los equipos de peaje y control de acceso de una estación o terminal durante una contingencia donde falle la red eléctrica.
  • Nivel 3: corresponde a los sistemas centrales de cada Sistema de Peaje y Control de Acceso del Sistema Metrobús, así como la Pasarela de pagos que se encargará de procesar e integrar las transacciones bancarias de los validadores de todo el sistema de corredores Metrobús. A este nivel debe ser transmitida la información recolectada los diferentes elementos que tengan una conexión con dichos sistemas centrales. Desde este nivel también se administran todos los elementos de los niveles inferiores. Del nivel 3 hacen parte:
  • Pasarela de Pagos: fungirá como la pasarela principal que concentre y procese todas las transacciones con medios de pago EMV sin contacto. Esta pasarela deberá interactuar con cualquier empresa de peaje y adquirente bancario, así como gestionar las listas de rechazo, transbordos, tarifa y las llaves de tokenización para todos los validadores de estaciones y autobuses de los corredores de Metrobús.
  • Sistema central hospedado en la nube o sistema central: permite almacenar y procesar toda la información transaccional generada por el uso de los medios de pago en los dispositivos de lectura/escritura que conforman el Sistema de Peaje y Control de Accesos, así como administrar toda la información relacionada con las operaciones vinculadas a este sistema. El sistema central está conformado por los siguientes elementos:
  1. Cuenta de usuario: permite la gestión de cuentas para los usuarios de “LA EMPRESA”, de Metrobús y del sistema de transporte público.
  2. Software de monitoreo de equipos: permite la gestión de inventario de todos los dispositivos, elementos, componentes y versiones de software del Sistema de Peaje y Control de Acceso suministrados por “LA EMPRESA”. Este software permite un monitoreo remoto por parte de Metrobús.
  3. SAM físico: es un sistema que permite gestionar remotamente la seguridad de las transacciones realizadas con el SAM local de los equipos
  4. SAM remoto: es un sistema que permite gestionar remotamente la seguridad de múltiples transacciones de forma simultánea y que no formará parte del alcance inicial, y podrá ser incluido posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” Y “METROBÚS” para su implementación.
  5. Software de gestión de videovigilancia: permite a “LA EMPRESA” el acceso remoto al NVR y las cámaras de videovigilancia para descarga de videos y visualización en tiempo real.
  6. Acceso a base de datos y reportes: permite a Metrobús el acceso ilimitado y completo a la base de datos del sistema central y a una herramienta dinámica de reportería.
  • Acceso remoto al sistema de videovigilancia: es un software que permite a Metrobús el acceso remoto y directo al NVR y las cámaras de videovigilancia para descarga de videos y visualización en tiempo real.
  • Sistemas centrales de empresas de peaje: son los sistemas centrales de las Líneas 1, 2, 3, 4 y 5 del Sistema Metrobús.
  • Servidores espejo: son servidores que almacenan una copia de la información transaccional de las Líneas 1, 2, 3, 4 y 5 del Sistema Metrobús.
  • Nivel 4: constituye el nivel más alto en el que se consolida la información proveniente de los sistemas centrales de todos los subsistemas de peaje de la ciudad. De este hará parte el sistema central del Sistema Integrado de Transporte Público de México, el cual recibirá las transacciones de todos los subsistemas de peaje, realizará cálculos de compensación y manejará listas blancas y negras consolidadas. Este sistema interactuará con el sistema central hospedado en la nube de “LA EMPRESA” para la recepción de datos transaccionales y el intercambio de información de peaje.

Teniendo en cuenta esta arquitectura, los componentes del Sistema de Peaje y Control de Acceso comprenden, como mínimo y sin limitarse, los siguientes:

  1. Tarjeta de Movilidad Integrada
  2. Elementos en terminal y estación
  • Validador (VAL)
  • Torniquete de entrada (TQE)
  • Torniquete de salida (TQS)
  • Puerta de Cortesía o Garita (PSC)
  • Terminal Venta y Carga Completa (TVMC)
  • Terminal Venta y Carga Ligera (TVML)
  • Centro de atención al usuario (CAU)
  • Sistema de videovigilancia (SVV)
  • Sistema de suministro eléctrico (SSE)
  1. Elementos Externos
  • Terminal móvil para supervisión (TMS)
  • Dispositivo de personalización

 

  1. Sistema central
  2. Canales de comunicación

La cantidad de elementos a instalar en los autobuses, así como en cada terminal o estación está descrito en el “Anexo 2”: Inventario de Equipos para el Sistema de Peaje y Control de Acceso.

Para asegurar la funcionalidad de todos los componentes del Sistema de Peaje y Control de Acceso, “LA EMPRESA” será la única responsable de la calidad del servicio y el cumplimiento de las obligaciones del contrato durante la instalación, puesta en marcha y operación normal, para lo cual debe validar los requerimientos aquí definidos y complementar a su criterio los que considere necesarios.

En este sentido, para el cumplimiento de las especificaciones que se señalan, “LA EMPRESA” debe asegurar lo siguiente:

  1. Garantizar la disponibilidad de los equipos y sus partes para asegurar su permanente funcionalidad.
  2. Asegurar que el sistema entregado cuente con facilidades para su mantenimiento (disponibilidad de piezas y personal técnico adecuado y capacitado).
  3. Garantizar la escalabilidad del sistema hacia otros usos de la tarjeta y posibilidad de compatibilidad hacia otros modos de transporte.
  4. Suministrar a Metrobús toda la información recolectada y generada por el(los) software(s) que hagan parte de la solución.
  5. Ofrecer un servicio que se pueda actualizar y escalar para soportar la expansión del sistema y la adición de nuevas funcionalidades, componentes tecnológicos y transacciones.
  6. Suministrar a Metrobús la(s) licencia(s) de uso, sin restricciones de tiempo y con actualizaciones hasta la finalización del contrato, del o de los software(s) desarrollados o adquiridos para implementar el Sistema de Peaje y Control de Acceso.
  7. Entregar a Metrobús toda la documentación técnica necesaria para que otros operadores de transporte y/o empresas de peaje puedan integrarse con el sistema central implementado y aceptar todos los medios de pago que hacen parte de los alcances que se definen en esta sección, asegurando la interoperabilidad.

El Sistema de Peaje y Control de Acceso posee tres alcances definidos de la siguiente forma:

  1. Alcance principal

Este alcance contempla la implementación de toda la infraestructura de hardware y software descrita en el “Anexo 2”: Inventario de Equipos para el Sistema de Peaje y Control de Acceso y “Anexo 3”: Inventario de Software para el Sistema de Peaje y Control de Acceso, incluyendo la capacidad en los validadores de geolocalización para transacciones y zonas de transferencia, leer códigos de barras 2D y la certificación de los validadores para aceptar medios de pago EMV sin contacto.

  1. Alcance para pago con código de barras 2D

Este alcance contempla la aceptación del pago con códigos de barras 2D por medio de una aplicación móvil en la cual, previo registro del usuario, se genera un código de barras 2D para realizar el pago del pasaje en los validadores instalados en terminales y estaciones, o generado a través de un código emitido por la TVMC leido en el validador.

  1. Alcance para pago con medios de pago EMV sin contacto

Este alcance contempla la aceptación del pago con medios de pago EMV sin contactos. Dichos medios de pago incluyen tarjetas de débito y de crédito, emitidas por entidades financieras nacionales o internacionales, que satisfagan las especificaciones EMV y cuenten con tecnología de pago sin contacto, así como accesorios que cumplan con estas mismas condiciones (relojes, pulseras, etc.). Cualquier usuario puede hacer uso de estos para efectuar el pago del pasaje en los validadores instalados en terminales y estaciones, y terminales móviles para supervisión.

5.   Tarjeta de Movilidad Integrada

  1. La Tarjeta de Movilidad Integrada es idéntica y común para los usuarios en todos los corredores del Sistema de Corredores de Transporte público de pasajeros de la ciudad de México (Sistema Metrobús) y aceptada en el Metro de la Ciudad de México, Tren Ligero, Trolebús, Red de Transporte de Pasajeros, entre otros.
  2. La Tarjeta de Movilidad Integrada se puede usar en los validadores instalados en los autobuses, terminales y estaciones de todas las líneas o sistemas de transporte sin tomar en cuenta donde han sido adquiridas o recargadas.
  3. Las especificaciones generales de la Tarjeta de Movilidad Integrada basada en el estándar internacional Calypso y serán suministradas bajo un esquema de confidencialidad entre Metrobús y “LA EMPRESA”, que formará parte integral del contrato de prestación de servicios de peaje y control de acceso, motivo de esta especificación.
  4. “LA EMPRESA” es responsable del proceso de compra de las Tarjetas de Movilidad Integrada y su entrega al usuario. Tendrá el derecho de recibir el reembolso por el costo de las tarjetas que suministre mensualmente. Para esto debe presentar los documentos que se describen en el “Anexo 6”: Procedimientos de Reembolso para Tarjetas y Dispositivos Portátiles.
  5. “LA EMPRESA” tiene la obligación de comprar tarjetas a proveedores que tengan el visto bueno de la Secretaría de Movilidad a través del Grupo Técnico del Sistema de Peaje de la Ciudad de México.
  6. A continuación, se presenta un resumen de los perfiles de usuario que se deben incluir en el Sistema de Peaje y Control de Acceso. Estos hacen parte del Modelo de Datos de la Tarjeta Calypso y se describen con mayor detalle en el documento “Definición de los perfiles de usuario de la tarjeta Calypso para la implementación en los equipos de validación de tarjetas sin contacto de los organismos de transporte público de la Ciudad de México”, el cual será suministrado en su totalidad bajo las condiciones y acuerdos de confidencialidad establecidas por Metrobús.

 

Nombre del perfil

Tarifa

Perfil aplicable a todos los organismos

Acceso físico

Personalización gráfica

Usuario General

General

• Validador de Acceso General

• Puerta de Cortesía o Garita

Adulto Mayor (70+)

Gratuidad

• Validador de Acceso General

• Puerta de Cortesía o Garita

Persona con Discapacidad

Gratuidad

• Validador de Acceso General

• Puerta de Cortesía o Garita

Estudiante

Tarifa reducida

No

Tarifa reducida en el organismo que emite el contrato (Por el momento solo aplica en STC)

Validador de Acceso General

Policía

Gratuidad

No

Gratuidad en el organismo que emite el contrato

• Puerta de Cortesía o Garita

Color llamativo y logo de estación El logo de estación solo aplica en STE y MB

Técnico de Mantenimiento

Gratuidad

No

Uso específico en el organismo que emite el contrato

Uso específico por el organismo

No

Recolección de Valores

N/A

No

Uso específico en el organismo que emite el contrato

NA

Color llamativo y número de línea

Supervisor del Organismo

Gratuidad

No

Gratuidad en el organismo que emite el contrato

Validador de Acceso General

No

Empleado Interno del Organismo

Gratuidad

No

Gratuidad en el organismo que emite el contrato

Validador de Acceso General

Depósito de Valores

N/A

No

Permisos especiales en el organismo que emite el contrato (Por el momento solo en MB)

N/A

No

Contralor Ciudadano

Gratuidad

Validador de Acceso General

Adulto Mayor (70+)

Gratuidad

No

Gratuidad en STC, STE y RTO

Rechazado en MB

• Validador de Acceso General

• Puerta de Cortesía o Garita

 

 

  1. Para el caso específico del perfil “Usuario General” podrá realizar la validación y acceso por la Puerta de Cortesía o Garita, pero deberá realizar el siguiente procedimiento:

 

  1. Solicitar al elemento de la Policía Auxiliar del organismo que presente su tarjeta en el validador de la puerta de cortesía o garita.
  2. Presentar la tarjeta “Usuario General” del usuario que desea ingresar por la puerta de cortesía o garita.
  3. Una vez presentada la tarjeta, se aprobará el acceso y se descontará el costo de la tarifa aplicable del saldo de la tarjeta.

6.   Alcance principal

Este alcance contempla la implementación de toda la infraestructura de hardware y software descrita en el “Anexo 2”: Inventario de Equipos para el Sistema de Peaje y Control de Acceso y “Anexo 3”: Inventario de Software para el Sistema de Peaje y Control de Acceso, incluyendo la capacidad en los validadores de leer códigos de barras 2D y la certificación de los validadores para aceptar medios de pago EMV sin contacto.

6.1 Elementos en terminal, estación y autobuses.

 

Se relacionan a continuación los elementos hacen parte de la arquitectura del Sistema de Peaje y Control de Acceso que deben implementarse en autobuses, terminales y estaciones.

6.1.1        Validador (VAL)

  • Descripción general

El VAL suministrado por “LA EMPRESA” debe:

  1. Leer y verificar la autenticidad de la Tarjeta de Movilidad Integrada (Full Calypso).
  2. Poder ser instalado en todos los torniquetes de entrada y puertas de cortesía/garita.
  3. Poder ser instalado en todos los autobuses que prestan servicio en el corredor de Metrobús Reforma.
  4. Para el caso de validadores en autobús, deben dar la opción de seleccionar rutas y tarifas previamente definidas en el sistema central, así mismo debe contar con la alternativa de dar de alta rutas que se requieran en un futuro.
  5. Para el caso de los validadores en autobuses deberán contar con geolocalización para determinar si la posición del autobús es en una terminal o parabús y si el mismo corresponde a un sitio de transbordo.
  6. Para el caso de los validadores en autobuses deben contar con geolocalización del autobús para determinar la ubicación y la zona de transferencias.
  7. Validar el estado de la tarjeta, la presencia en listas negras y blancas, la regla tarifaria a aplicar, entre otros parámetros operacionales del Sistema de Peaje y Control de Acceso.
  8. Efectuar la deducción del monto correspondiente a cada viaje (resultado del perfil del usuario y tarifa aplicable).
  9. Comandar la liberación del torniquete y/o puerta de cortesía al descontar el monto de la tarifa para permitir a los usuarios el ingreso al sistema.
  10. Transmitir toda la información de peaje al sistema central.
  11. Permitir la validación de una tarjeta sólo si está presente el correspondiente SAM.
  12. Contar con una interfaz de usuario en idioma español.
  13. Mostrar permanentemente la tarifa autorizada en el display.
  14. Mostrar el saldo final de la tarjeta y emitir una alarma visual que indique el éxito de la validación, después de validar con éxito una tarjeta de usuario.
  15. Emitir una alarma sonora que indique el éxito de la validación, después de validar con éxito una tarjeta de usuario.
  16. Mostrar el mensaje "Transbordo" y emitir una alarma visual que indique el éxito de la validación, en caso de que una tarjeta tenga habilitado el transbordo y la transacción sea exitosa.
  17. Emitir una alarma sonora que indique el éxito de la validación, en caso de que una tarjeta tenga habilitado el transbordo y la validación sea exitosa.
  18. Mostrar el mensaje "Saldo insuficiente" y el saldo actual de la tarjeta, y emitir una alarma visual que indique el rechazo de la transacción, en caso de que una tarjeta no cuente con el saldo suficiente.
  19. Emitir una alarma sonora que indique el rechazo de la transacción, en caso de que una tarjeta no cuente con el saldo suficiente.
  20. Mostrar el mensaje "Tarjeta inválida" y emitir una alarma visual que indique el rechazo de la transacción, en caso de no poder leer la tarjeta.
  21. Emitir una alarma sonora que indique el rechazo de la transacción, en caso de no poder leer la tarjeta.
  22. Incorporar la API para interacción con medios de pago. Es deseable que puedan desarrollar los aplicativos por medio de Eclipse Keyple™, el cual es una API de código abierto para la integración y el desarrollo de aplicaciones de peaje, permitiendo que los desarrollos implementados por operadores o integradores se basen en una base homologada, a través de un conjunto de librerías de código abierto implementadas inicialmente en Java y C++, compatibles con cualquier arquitectura de terminales, sea móvil, embebida o distribuida, e interoperables con cualquier lector de tarjetas inteligentes: propietario, estándar, local o remoto.
  • Especificación técnica

El VAL debe:

  1. Contar con un lector de tarjetas sin contacto que cumpla con el estándar ISO 14443 A y B.
  2. Estar diseñado con materiales para uso pesado en sistemas de transporte y que con el paso del tiempo mantengan la visibilidad de la pantalla.
  3. Contar con un armazón que contenga toda su electrónica de forma que permita la sustitución e intercambio de un validador por otro de forma ágil, rápida y segura sin afectar la operación.
  4. Tener un display de más de 3.5" de diagonal TFT a color para desplegar mensajes con caracteres visibles.
  5. Contar con el siguiente tipo de comunicación/conectividad:
    1. WIFI: WIFI 802.11 a/b/g/n.
    2. BLUETOOTH: como mínimo de versión 3.0, recomendable en versión 4.0 y soportar BLE (Bluetooth Low Energy).
    3. Cableado: USB y Ethernet RJ45.
    4. Red: 4G, 3G y GPRS sin restricción de carrier y actualización remota de APN.
    5. NFC: Estándar NFCIP-1. Se recomienda soportar comunicación Peer to Peer que permita la comunicación directa del celular con el validador.
    6. GPS: Módulo GPS externo, a instalar en el vehículo, con una precisión de +/- 5 metros, con al menos 32 canales con soporte Glonass.
  6. SLOT de SAM: Con capacidad mínima de 2 Slots habilitados de tarjetas SAM ID-0. Interfaz de tarjeta que cumpla con los estándares ISO 7816 Clase A, B y C Lectura de tarjetas y medios de pago
    1. Tarjeta Inteligente Calypso rev 3 o superior. Certificada por la Red de Asociaciones Calypso (CNA por sus siglas en inglés).
    2. Otras tarjetas inteligentes, de acuerdo a la norma ISO 14443 A y B estándar, partes 2 a 4.
    3. El lector o antena para TISC y NFC deberá cumplir de manera obligada con la certificación de la norma 7816 parte 4.
    4. El lector o antena para TISC y NFC deberán contar con el certificado de cumplimiento CEN TS 16794:2018
    5. Otros dispositivos NFC/RFID.
  7. Contar avances significativos y comprobables de certificaciones EMV Contactless L1, Visa payWave, MasterCard Contactless, Amex ExpressPay (deseable), MasterCard TQM.
  8. Contar con la certificación EMV L2.
  9. Contar con la certificación PCI PTS 5.X o PCI DSS.
  10. Tener un lector de código de barras 2D incorporado.
  11. Velocidad de transacciones típicas no mayor a 250 milisegundos (para pago con Tarjeta Inteligente Sin Contacto-TISC) en tarjetas Calypso.
  12. Contar con indicadores luminosos o simulados en pantalla (rojo y verde) que indiquen al usuario el rechazo o validación exitosa de la transacción.
  13. Contar con indicadores sonoros que indiquen al usuario el rechazo o validación exitosa de la transacción.
  14. Ser resistentes al polvo y agua con un índice de protección nivel IP 54 y tener en cuenta la climatología de la Ciudad de México y en particular de la zona.
  15. Deseable IP 55
  16. Procesador de potencia equivalente o superior a 1 GHz ARM de al menos las siguientes características:
    1. Velocidad de Reloj 800MHz ~ 2GHz.
    2. L1 cache 32 KB I, 32 KB D.
    3. L2 cache 128 KB–8 MB.
    4. Microarquitectura: ARMv7-A.
    5. Multicores: 1-4 Cores.
    6. Memoria igual o superior a 512 MB en RAM.
    7. Almacenamiento interno eMMC igual o superior a 4 GB.
    8. Tarjeta microSD con capacidad mínima de 32 GB.
  17. Cumplimiento general de las recomendaciones establecidas en la norma ETSI EN 300 019-2-5 V3.0.0. Test 5.1.
    1. Temperatura: Rango -20°C +55°C y 5 ciclos de 3 horas de -20°C +30°C
    2. Humedad: Máximo 95%
    3. Vibración: Según Norma IEC 60068-2-64, aceleraciones de 1 m2/s3 (10-200Hz) y 0.3 m2/s3 (200-500Hz).
    4. Golpes: Según la Norma IEC 60068-2-27, tipo 1 duración 11 ms, aceleración 100 m/s2.
    5. Baches: Según Norma IEC 60068-2-29, aceleración 100 m/s2, duración 11ms, 100 en cada dirección.
    6. Grado de protección contra impactos mecánico-externos (IK): 06 o superior.
  18. Tener una capacidad de almacenamiento mínimo de 30 días de transacciones, además de los registros de las listas negras, listas blancas y otras a petición de Metrobús.
  19. Contar con sistema de descarga de datos alternativo en caso de contingencias por fallas en el dispositivo.
  20. Poder liberar los torniquetes o puertas de cortesía/garita, en caso de emergencia. Esta solicitud puede ser realizada desde el sistema central.
  21. Tener los bordes redondeados, de manera que se pueda evitar daño físico a los usuarios.
  22. Tener un software parametrizable.
  23. Permitir la actualización remota desde el sistema central de la estructura tarifaria, mensajes visuales, listas negras, listas blancas y demás parámetros operacionales del sistema.
  24. Poder estar integrado mecánicamente en la tapa del torniquete de entrada o poder utilizar un poste adicional para su instalación. En ambos casos se debe establecer una posición ergonómica para el usuario y mantener el índice de protección de polvo y agua exigido.
  25. Para el caso de los autobuses poder estar integrado en dos posiciones con tubos para la instalación de los mismos. Se debe establecer una altura y posición ergonómica para el usuario
  26. Poder estar integrado mecánicamente en la puerta de cortesía/garita o poder utilizar poste adicional para su instalación. En ambos casos se debe establecer una altura y posición ergonómica para el usuario y mantener el índice de protección de polvo y agua exigido.
  27. Contar con una certificación de compatibilidad con las especificaciones de Calypso Rev 3.1 como mínimo, expedida por una empresa certificadora autorizada por Calypso Network Association (CNA). Este requerimiento es deseable.
  28. Operar con tiempo de procesamiento de transacción de validación menor a 500 milisegundos.
  29. Poder conectarse en el autobús a través del cableado y conexiones existentes, o en su caso cablear con la autorización de la empresa armadora.

6.1.2        Torniquete de entrada (TQE)

  • Descripción general

El TQE suministrado por “LA EMPRESA” debe:

  1. Delimitar la zona libre o vestíbulo exterior y la zona controlada o vestíbulo interior.
  2. Permitir el control del total de las entradas y transbordos realizados en cada estación, con el fin de contabilizar la afluencia de los usuarios que entran a la estación.
  3. Contar con dos dispositivos de conteo: un aforo electromecánico externo instalado en el gabinete del torniquete y un aforo electromecánico en el interior de este. Esto para llevar un control de las entradas de los usuarios al interior de las estaciones con fines estadísticos.
  4. Asegurar el control del acceso de usuarios al interior de la estación, mediante el bloqueo o desbloqueo de su mecanismo de acceso, al momento de recibir la señal enviada por el validador.
  5. Poder ser liberado automáticamente en casos de emergencia a través de la interrupción de la energía eléctrica o mediante el uso de un botón interno que permita la interrupción del suministro de energía. Se deberá crear un registro en el sistema cuando se active dicho botón de emergencia, el cuál deberá estar dentro del torniquete.
  6. Tener en cuenta en su diseño y operación las condiciones de espacio de instalación y demanda previstas en cada estación que Metrobús suministrará.
  7. Permitir el paso libre de salida de la estación en casos de emergencia.
  • Especificación Técnica

El TQE debe:

  1. Tener un gabinete con diseño ergonómico, bordes redondeados sin elementos que puedan causar daño a los usuarios.
  2. Estar fabricado en acero inoxidable AISI 304 con espesor mínimo de 1.5 mm.
  3. Tener escondidas las bisagras y cerraduras para las puertas.
  4. Permitir su apertura con una sola llave maestra.
  5. Tener tres (3) brazos, cada uno de mínimo 50 cm fabricados en acero inoxidable AISI 304 con puntas redondeadas. La longitud de los brazos del trípode deberá poder adaptarse a los espacios disponibles en las estaciones sin permitir el paso libre de usuarios y sin afectar la movilidad de los mismos.
  6. Contar con altura mínima de 90 centímetros y máxima de 120 centímetros.
  7. Tener un ancho mínimo de 10 centímetros y máximo de 30 centímetros. Es responsabilidad de “LA EMPRESA” cubrir los espacios y encausamiento, resultado al ancho del torniquete[1].
  8. Tener un largo mínimo de 90 centímetros y máximo de 120 centímetros.
  9. Permitir el paso por el trípode de mínimo 30 usuarios por minuto.
  10. Ser resistente al polvo y agua con un índice de protección mínimo nivel IP 54 y tener en cuenta la climatología de la Ciudad de México y en particular de la zona.
  11. Contar con pictogramas de tecnología LED con intensidad regulable, que permitan al usuario identificar el sentido de operación del torniquete, utilizando simbología en color verde y rojo.
  12. Tener un contador electromecánico digital de paso de entrada no reversible, visible desde el exterior, empotrado al gabinete, protegido contra reinicio aún con pérdida de corriente eléctrica, el cual será incrementado por cada validación autorizada y verificación de giro del torniquete.
  13. Tener un contador electromecánico digital o analógico de paso de entrada no reversible ubicado al interior del gabinete, protegido contra reinicio aún con pérdida de corriente eléctrica, el cual será incrementado por cada giro del trípode del torniquete.
  14. Poder trabajar en diferentes modos de operación (unidireccional, bidireccional).
  15. Contar con interfaz con el validador para enviar y recibir comandos de inicio y fin del giro.
  16. Tener comunicación Ethernet con el sistema central para transmitir los datos de los conteos.
  17. Contar con la capacidad de almacenar la información de conteos de mínimo 30 días.
  18. Permitir de forma remota el bloqueo por horario.
  19. Permitir de forma remota o manual la selección de direccionalidad.

“LA EMPRESA” debe entregar a Metrobús al menos 8 llaves de gabinetes previo al inicio de operaciones y posteriormente las que Metrobús solicite.

Dependiendo de los anchos de cada estación y terminal, Metrobús indicará el arreglo que considere más conveniente y que permita satisfacer adecuadamente la demanda prevista para cada punto considerando la instalación de los equipos.

6.1.3        Torniquete de salida (TQS)

  • Descripción general

El TQS suministrado por “LA EMPRESA” debe:

 

  1. Delimitar la zona libre o vestíbulo exterior y la zona controlada o vestíbulo interior.
  2. Permitir el control de las salidas, con el fin de contabilizar la afluencia de usuarios que salen a la estación.
  3. Contar con dos dispositivos de conteo: un aforo electromecánico externo instalado en el gabinete del torniquete y un aforo electromecánico en el interior de este. Esto para llevar un control de las salidas de los usuarios al interior de las estaciones con fines estadísticos.
  4. Permitir el paso libre de salida de la estación en casos de emergencia.
  5. Estar bloqueado en sentido de entrada y liberado en sentido de salida.
  6. Enviar al sistema central el valor de conteos diarios.
  7. Tener en cuenta en su diseño y operación las condiciones de espacio de instalación y demanda previstas en cada estación que Metrobús suministrará.
  • Especificación técnica

El TQS debe:

  1. Tener un gabinete con diseño ergonómico, bordes redondeados sin elementos que puedan causar daño a los usuarios.
  2. Estar fabricado en acero inoxidable AISI 304 con espesor mínimo de 1.5 mm.
  3. Tener escondidas las bisagras y cerraduras para las puertas.
  4. Permitir su apertura con una sola llave maestra.
  5. Tener tres (3) brazos cada uno de mínimo 50 cm fabricados en acero inoxidable AISI 304 con puntas redondeadas. La longitud de los brazos del trípode deberá poder adaptarse a los espacios disponibles en las estaciones sin permitir el paso libre de usuarios y sin afectar la movilidad de los mismos.
  6. Contar con una altura mínima de 90 centímetros y máxima de 120 centímetros.
  7. Tener un ancho mínimo de 10 centímetros y máximo de 30 centímetros. Es responsabilidad de “LA EMPRESA” cubrir los espacios y encausamiento, resultado al ancho del torniquete[2].
  8. Tener un largo mínimo de 90 centímetros y máximo de 120 centímetros.
  9. Permitir el paso por el trípode de mínimo 40 usuarios por minuto.
  10. Ser resistente al polvo y agua con un índice de protección mínimo nivel IP 54 y tener en cuenta la climatología de la Ciudad de México y en particular de la zona.
  11. Contar con pictogramas de tecnología LED con intensidad regulable, que permitan al usuario identificar el sentido de operación del torniquete, utilizando simbología en color verde y rojo.
  12. Tener un contador electromecánico digital de paso de salida no reversible, visible desde el exterior, empotrado al gabinete, protegido contra reinicio aún con pérdida de corriente eléctrica, el cual será incrementado por cada giro del trípode del torniquete.
  13. Tener un contador electromecánico digital o análogo de paso de salida no reversible, ubicado al interior del gabinete, protegido contra reinicio aún con pérdida de corriente eléctrica.
  14. Posibilidad de trabajar en diferentes modos de operación (unidireccional, bidireccional).
  15. Comunicación Ethernet con el sistema central para transmitir los datos de los conteos.
  16. Contar con la capacidad de almacenar la información de conteos de mínimo 30 días.
  17. Permitir de forma manual el bloqueo por horario.
  18. Permitir de forma manual la selección de direccionalidad.

“LA EMPRESA” debe entregar a Metrobús al menos 8 llaves de gabinetes previo al inicio de operaciones y posteriormente las que Metrobús solicite.

Dependiendo de los anchos de cada estación y terminal, Metrobús indicará el arreglo que considere más conveniente y que permita satisfacer adecuadamente la demanda prevista para cada punto considerando la instalación de los equipos.

6.1.4        Puerta de cortesía o garita (PSC)

  • Descripción general

La PSC suministrada por “LA EMPRESA” debe:

  1. Delimitar la zona libre o vestíbulo exterior y la zona controlada o vestíbulo interior.
  2. Permitir las entradas y transbordos de personas con discapacidad realizados en cada estación, con el fin de contabilizar la afluencia de este perfil de usuarios que entran a la estación.
  3. Permitir las entradas y transbordos en caso de ser necesario de los siguientes perfiles: usuarios generales, adultos mayores y policía.
  4. Ser lo suficientemente robusta para evitar el ingreso de usuarios a través de ella sin una validación exitosa, exceptuando los casos en los que se habilite el acceso libre por la misma.
  5. Asegurar el control del acceso de usuarios al interior de la estación mediante el desbloqueo de su mecanismo de acceso, al momento recibir la señal enviada por el validador.
  6. Poder ser liberada automáticamente en casos de emergencia a través de la interrupción de la energía eléctrica o mediante el uso de un botón interno que permita la interrupción del suministro de energía. Se deberá crear un registro en el sistema cuando se active dicho botón de emergencia.
  7. Tener en cuenta en su diseño y operación las condiciones de espacio de instalación y demanda previstas en cada estación que Metrobús suministrará.

Será responsabilidad de “LA EMPRESA” operadora realizar los cierres necesarios para la reducción de espacios entre la puerta y los encauzadores. Los encauzadores instalados actualmente en L6 y L7, pertenecen a Metrobús, por lo cual, si la  “EMPRESA” requiere la modificación de los mismos, para adecuar el acceso/salida para colocar sus equipos, deberán colocar encauzadores que no modifiquen la imágen de la estación.

  • Especificación Técnica

La PSC debe:

  1. Tener un diseño ergonómico, bordes redondeados sin elementos que puedan causar daño a los usuarios.
  2. Estar fabricado en acero inoxidable AISI 304 con espesor mínimo de 1.5 mm.
  3. Tener una altura mínima 100 centímetros.
  4. Tener un ancho mínimo 100 centímetros (libres medidos con la puerta abierta).
  5. Permitir la apertura en cualquiera de los sentidos (únicamente trabajará en un sentido, pero debe contar con la posibilidad de elección en el sentido de apertura).
  6. Ser resistente al polvo y agua con un índice de protección, en caso de tener integrado el validador, mínimo nivel IP 54; en caso de utilizar un poste adicional para el validador, mínimo IP 20; y en ambos casos tener en cuenta la climatología de la Ciudad de México y en particular de la zona.
  7. Contar con un mecanismo de cierre robusto que impida la apertura no autorizada.
  8. Tener un ángulo de apertura de 100º como mínimo, con un mecanismo de cierre automático inmediato después de cada apertura.
  9. Contar con un mecanismo de apertura comandado por el validador.
  10. Tener un tiempo máximo de apertura, considerando desde su activación hasta el cierre, no mayor a 11 segundos. Este debe ser parametrizable.
  11. Tener contador de liberación no reversible, digital, electromecánico o electrónico, ubicado en el exterior. Este requerimiento es deseable.

Dependiendo de los anchos de cada terminal y estación, Metrobús indicará el arreglo que considere más conveniente y que permita satisfacer adecuadamente la demanda prevista y de cumplimiento a la normatividad aplicable respecto a personas con discapacidad.

6.1.5        Terminal Venta y Carga Completa (TVMC)

  • Descripción general

La TVMC suministrada por “LA EMPRESA” debe:

  1. Realizar la venta y recarga de la Tarjeta de Movilidad Integrada.
  2. No dar cambio.
  3. Recibir como forma de pago monedas, billetes y tarjetas bancarias (de débito y de crédito EMV de contacto y de interfaz dual).
  4. Operar sin restricción de horario.
  5. Contar con la posibilidad de recargar un saldo inicial al momento de entregar una tarjeta adquirida por el usuario. Este saldo inicial debe ser parametrizable a petición de Metrobús.
  6. Estar preparado para gestionar la seguridad de las transacciones con un SAM remoto, el cual no formará parte del alcance inicial, y podrá ser incluido posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” Y “METROBÚS” para su implementación.
  7. Estar preparado para gestionar la seguridad de las transacciones con un solo SAM local. Para realizar esto la empresa tendrá un máximo de dos años para tener un solo SAM en la máquina de venta y recarga.
  8. Poder parametrizar las opciones para los contenidos (animaciones, mensajes, etc.)
  9. Poder parametrizar las opciones de operatividad.
  10. Permitir modificar los contenidos de pantallas, fuentes, fondos, colores, links de acceso, temporalidad de venta y programación de botones cuando Metrobús lo solicite.
  11. Contar con una interfaz de usuario en idiomas español, inglés y francés como mínimo. El idioma debe poder ser seleccionado por el usuario.
  12. Permitir las actualizaciones de las denominaciones de moneda o billetes dentro de los 15 días hábiles de la emisión de una nueva imagen de denominación de moneda o billete.
  13. Emitir una alarma sonora en la pantalla y audios informativos que permita al usuario identificar que retiró su tarjeta antes de abonar el saldo.
  14. Emitir animaciones preventivas en la pantalla que permitan al usuario identificar que retiró su tarjeta antes de abonar el saldo.
  15. Contar con un espacio en la parte frontal del dispositivo para colocar una etiqueta de calidad en la cual se darán instrucciones escritas para el usuario. Metrobús decidirá el diseño estético además de la selección de la tipografía, al igual que el uso de las imágenes institucionales. “LA EMPRESA” realizará la impresión y colocación de las etiquetas.
  16. Contar con papel de los recibos. Este debe ser suministrado por “LA EMPRESA”.
  17. Contar con un software parametrizable.
  18. Poder configurar parámetros como el monto máximo aceptado, monto mínimo de recarga, costo de tarjeta, LocationID, valores aceptados, denominación de valores, temporalidad de venta, entre otros parámetros que Metrobús establezca.
  19. Poder hacer actualizaciones de software de forma remota desde el sistema central.
  20. Poder hacer la actualización remota desde el sistema central de la estructura tarifaria, mensajes visuales, listas negras, listas blancas, entre otros parámetros que Metrobús establezca.
  21. Contar con un software que tenga una opción "Eventos Especiales" que se habilitará con una tarjeta con el perfil Depósito de Valores el cual permitirá a la TVMC recibir monedas y billetes de manera continua.
  22. Al final del proceso de “Eventos Especiales”, emitir a través de la TMVC un recibo con la descripción detallada por denominación de los valores recibidos, los cuales deberán de transmitirse al sistema central en información independiente.
  23. Permitir la impresión de recibos y recolección de dinero para reclamo de dinero. Adicionalmente, permitir la impresión códigos 2D que podrán ser comprados como un viaje para poderlos usar en los validadores para el ingreso al sistema. En el caso de la funcionalidad de impresión de códigos 2D no forma parte del alcance inicial, sin embargo, las máquinas deberán estar habilitadas, cuando Metrobús lo solicite.
  24. Para el caso de Línea 7, las dimensiones de la TVMC deben adaptarse al espacio destinado para los equipos de recarga en Parabús como se muestra a continuación:

  1. Estar preparado para realizar la redención de recargas remotas efectuadas a través de una aplicación móvil o una aplicación web, haciendo una consulta en línea al sistema central de las recargas a redimir en el medio de pago, directamente en el TVMC. Esta funcionalidad no formará parte del alcance inicial, y podrá ser incluida posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” y “METROBÚS” para su implementación.
  2. Implementar la recarga a través de CoDi. Esta funcionalidad debe estar disponible en todas las TVMC y la activación en una TVMC desde el inicio del contrato.
  3. Incorporar la API para interacción con medios de pago. Es deseable que puedan desarrollar los aplicativos por medio de Eclipse Keyple™, el cual es una API de código abierto para la integración y el desarrollo de aplicaciones de peaje, permitiendo que los desarrollos implementados por operadores o integradores se basen en una base homologada, a través de un conjunto de librerías de código abierto implementadas inicialmente en Java y C++, compatibles con cualquier arquitectura de terminales, sea móvil, embebida o distribuida, e interoperables con cualquier lector de tarjetas inteligentes: propietario, estándar, local o remoto.
  4. Permitir la configuración del contenido de los recibos de reclamo a petición de Metrobús. El recibo base debe contener los siguientes datos:

“LA EMPRESA” debe entregar un manual de usuario y de supervisión donde especificará claramente la tabla de fallas y el posible diagnóstico preliminar para la generación de una orden de mantenimiento (incidencia).

 

  • Especificación Técnica

La TVMC debe:

                                       

  1. Contar con un diseño ergonómico, bordes redondeados sin elementos que puedan causar daño a los usuarios.
  2. Ser fabricado en lámina de acero Cold Rolled calibre diez (10) con acabado en pintura electrostática epóxica horneada de alta resistencia o acero inoxidable AISI 304 como mínimo o presentar un grado de seguridad antivandálica similar.
  3. Tener una altura de la estructura que comprende desde el piso hasta la altura necesaria según el diseño de “LA EMPRESA”.
  4. Estar preparada para recibir el sistema de sujeción a través de tornillos fijos en el piso de la estación.
  5. Tener un lector de tarjetas sin contacto que cumpla con el estándar ISO 14443 A y B.
  6. Contar con pantalla táctil de información de mínimo 15", diseñada con materiales para uso pesado en sistemas de transporte y que con el paso del tiempo mantengan la visibilidad de la pantalla.
  7. Ser resistente al polvo y agua con un índice de protección mínimo nivel IP 54 y tener en cuenta la climatología de la Ciudad de México y en particular de la zona.
  8. Contar con un sistema de audio para emitir alarmas y mensajes a los usuarios, diseñado para trabajo en entornos abiertos, que permita la audición clara de los mensajes y alarmas.
  9. Tener caja de billetes con una capacidad mínima de 1,200 billetes.
  10. Tener bolsa de monedas con una capacidad mínima de 5 litros.
  11. Tener el lector, software, hardware y certificaciones que permitan aceptar el pago con tarjeta bancaria de débito y de crédito EMV de contacto y de interfaz dual.
  12. Contar con capacidad de almacenamiento de mínimo 30 días de transacciones, además de los registros de las listas negras, listas blancas y otras a petición de Metrobús.
  13. Contar con la capacidad de alojar mínimo dos (2) SAM.
  14. En caso de funcionar con SAM local, este debe estar asociado al ID Location asignado a la TVMC.
  15. Contar con un mecanismo para insertar la Tarjeta de Movilidad Integrada con la que se efectuará una transacción. El receptáculo de tarjeta debe ser ergonómico y de fácil uso.
  16. Contar con un mecanismo para insertar tarjetas bancarias. El receptáculo de tarjeta debe ser ergonómico y de fácil uso.
  17. Tener aislamiento físico entre la zona de mantenimiento (electrónica y componentes) y zona de valores (Caja de monedas y caja de billetes).
  18. Contar con chapa de seguridad y apertura electromecánica a través de una tarjeta con perfil Recolección de Valores y su llave mecánica.
  19. Contar con algún elemento que permita la restitución del sistema en caso de falla para la lectura de la tarjeta.
  20. Contar con comunicación base Ethernet.
  21. Contar con mecanismos de seguridad que no permitan el cambio de ID Location asignado.
  22. Contar con una cámara de video y su respectivo NVR que se active cuando la máquina sea abierta.
  23. Realizar la redención de recargas remotas realizadas a través de una aplicación móvil o una aplicación web, haciendo una consulta en línea al sistema central de las recargas a redimir en el medio de pago, directamente en el TVMC. Esta funcionalidad no formará parte del alcance inicial, y podrá ser incluida posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” y “METROBÚS” para su implementación.
  24. Permitir la recepción de monedas y billetes. (Monedas, 1, 2, 5, 10 y 20 pesos en moneda nacional, Billetes 20, 50, 100 y 200 pesos en moneda nacional).
  25. Contar con un sistema de ventilación o enfriamiento interior con filtros y componentes que eviten el ingreso de polvo al interior de la máquina.
  26. Es deseable tener botón de devolución de monedas en caso de que las mismas se queden atoradas.
  27. Accionar una sirena de alarma, en caso de apertura no autorizada o intento de apertura. Esta debe tener independencia de la alimentación eléctrica de la TVMC y contar con su propia alimentación.
  28. Contar con alarmas que enviarán al sistema central como: "fuera de servicio", "falta de tarjetas", "pre-llenado de monedas", "pre-llenado billetes", "falta papel", “Apertura no Autorizada”, “Puertas Abiertas”, Zona de Valores Abierta”.
  29. Contar con una certificación de compatibilidad con las especificaciones de Calypso Rev 3.1 como mínimo, expedida por una empresa certificadora autorizada por Calypso Network Association (CNA). Este requerimiento es deseable.
  30. Revisar que todos los elementos incorporados dentro de la máquina no puedan ser vulnerados a través de campos electromagnéticos u otra posibilidad, incorporando las medidas de protección de software y hardware para evitar posibles daños y ataques que puedan propiciar malos usos y defraudación.

6.1.6        Terminal de Venta y Recarga Ligera (TVML)

  • Descripción general

La TVML suministrada por “LA EMPRESA” debe:

  1. Realizar la recarga de la Tarjeta de Movilidad Integrada.
  2. No dar cambio.
  3. Recibir como forma de pago monedas y tarjetas bancarias (de débito y de crédito EMV de contacto y de interfaz dual).
  4. Operar sin restricción de horario.
  5. Estar preparado para gestionar la seguridad de las transacciones con un SAM remoto, el cual no formará parte del alcance inicial, y podrá ser incluido posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” y “METROBÚS” para su implementación.
  6. Estar preparado para gestionar la seguridad de las transacciones con un SAM local.
  7. Poder parametrizar las opciones para los contenidos (animaciones, mensajes, etc.) y de operatividad.
  8. Permitir modificar los contenidos de pantallas, fuentes, fondos, colores, links de acceso, temporalidad de venta y programación de botones cuando Metrobús lo solicite.
  9. Contar con interfaz de usuario en idiomas español, inglés y francés como mínimo. El idioma debe poder ser seleccionado por el usuario.
  10. Permitir la actualización de las denominaciones de monedas dentro de los 15 días hábiles de la emisión de una nueva imagen de denominación de monedas y billetes.
  11. Emitir una alarma sonora en la pantalla que permita al usuario identificar que retiró su tarjeta antes de abonar el saldo.
  12. Emitir animaciones preventivas en la pantalla que permitan al usuario identificar que retiró su tarjeta antes de abonar el saldo.
  13. Contar con un espacio en la parte frontal del dispositivo para colocar una etiqueta de calidad en la cual se darán instrucciones escritas para el usuario. Metrobús decidirá el diseño estético además de la selección de la tipografía, al igual que el uso de las imágenes institucionales. “LA EMPRESA” realizará la impresión y colocación de las etiquetas. El suministro de papel de los recibos lo proveerá “LA EMPRESA”.
  14. Contar con un software parametrizable.
  15. Poder configurar parámetros como el monto de dinero máximo aceptado, monto mínimo de recarga, costo de tarjeta, LocationID, valores aceptados, denominación de valores, temporalidad de venta, entre otros parámetros que Metrobús establezca.
  16. Permitir actualizaciones de software de forma remota desde el sistema central.
  17. Permitir actualizaciones remotas desde el sistema central de la estructura tarifaria, mensajes visuales, listas negras, listas blancas, entre otros parámetros que Metrobús establezca.
  18. Permitir la impresión de recibos y recolección de dinero para reclamo de dinero. Adicionalmente, permitir la impresión códigos 2D que podrán ser comprados como un viaje para poderlos usar en los validadores para el ingreso al sistema. En el caso de la funcionalidad de impresión de códigos 2D no forma parte del alcance inicial, sin embargo, las máquinas deberán estar habilitadas, cuando Metrobús lo solicite.
  19. Contar con mecanismos de seguridad que no permitan el cambio de ID Location asignado.
  20. Contar con una cámara de video y su respectivo NVR que se active cuando la máquina sea abierta.
  21. Tener un contador de transacciones el cual no pueda ser reiniciado de forma local.
  22. Estar preparada para realizar la redención de recargas remotas realizadas a través de una aplicación móvil o una aplicación web, haciendo una consulta en línea al sistema central de las recargas a redimir en el medio de pago, directamente en el TVML. Esta funcionalidad no forma parte del alcance inicial, sin embargo, debe de estar preparado para realizar esta acción cuando “METROBÚS” o la ciudad lo soliciten.
  23. Implementar la recarga a través de CoDi. Esta funcionalidad debe estar disponible en todas las TVML y su activación en una TVML en particular se dará cuando Metrobús lo solicite.
  24. Incorporar la API para interacción con medios de pago. Es deseable que puedan desarrollar los aplicativos por medio de Eclipse Keyple™, el cual es una API de código abierto para la integración y el desarrollo de aplicaciones de peaje, permitiendo que los desarrollos implementados por operadores o integradores se basen en una base homologada, a través de un conjunto de librerías de código abierto implementadas inicialmente en Java y C++, compatibles con cualquier arquitectura de terminales, sea móvil, embebida o distribuida, e interoperables con cualquier lector de tarjetas inteligentes: propietario, estándar, local o remoto.
  25. Permitir la configuración del contenido de los recibos de reclamo a petición de Metrobús. El recibo base debe contener los siguientes datos:

“LA EMPRESA” debe entregar un manual de usuario y de supervisión donde especificará claramente la tabla de fallas y el posible diagnóstico preliminar para generar una orden de mantenimiento (incidencia).

  • Especificación Técnica

La TVML debe:

  1. Tener un diseño ergonómico, bordes redondeados sin elementos que puedan causar daño a los usuarios.
  2. Ser fabricado en lámina de acero Cold Rolled calibre diez (10) con acabado en pintura electrostática epóxica horneada de alta resistencia o acero inoxidable AISI 304 como mínimo o presentar un grado de seguridad antivandálica similar.
  3. Tener una altura de la estructura que comprende desde el piso hasta la altura necesaria según el diseño de “LA EMPRESA”.
  4. Estar preparada para recibir el sistema de sujeción a través de tornillos fijos en el piso de la estación.
  5. Tener lector de tarjetas sin contacto que cumpla con el estándar ISO 14443 A y B.
  6. Contar con pantalla táctil de información de mínimo 15", diseñada con materiales para uso pesado en sistemas de transporte y que con el paso del tiempo mantengan la visibilidad de la pantalla.
  7. Ser resistente al polvo y agua con un índice de protección mínimo nivel IP 54 y tener en cuenta la climatología de la Ciudad de México y en particular de la zona.
  8. Contar con un sistema de audio para emitir alarmas y mensajes a los usuarios, diseñado para trabajo en entornos abiertos, que permita la audición clara de los mensajes y alarmas.
  9. Para el caso de Línea 7, las dimensiones de la TVML deben adaptarse al espacio destinado para los equipos de recarga en Parabús como se muestra a continuación:

  1. Contar con una bolsa de monedas con una capacidad mínima de 5 litros.
  2. Tener el lector, software, hardware y certificaciones que permitan aceptar el pago con tarjeta bancaria de débito y de crédito EMV de contacto y de interfaz dual.
  3. Contar con la capacidad de almacenamiento mínimo de 30 días de transacciones, además de los registros de las listas negras, listas blancas y otras a petición de Metrobús.
  4. Tener la capacidad de alojar mínimo dos (2) SAM.
  5. En caso de funcionar con SAM local, este debe estar asociado al ID Location asignado a la TVML.
  6. Contar con un mecanismo para insertar la Tarjeta de Movilidad Integrada con la que se efectuará una transacción. El receptáculo de tarjeta debe ser ergonómico y de fácil uso.
  7. Contar con un mecanismo para insertar tarjetas bancarias. El receptáculo de tarjeta debe ser ergonómico y de fácil uso.
  8. Tener aislamiento físico entre la zona de mantenimiento (electrónica y componentes) y zona de valores (Caja de monedas)
  9. Contar con chapa de seguridad y apertura electromecánica a través de una tarjeta con perfil Recolección de Valores y su llave mecánica.
  10. Contar con algún elemento que permita la restitución del sistema en caso de falla para la lectura de la tarjeta.
  11. Contar con comunicación base Ethernet.
  12. Permitir la recepción de monedas (Monedas, 1, 2, 5, 10 y 20 pesos en moneda nacional.)
  13. Contar con un sistema de ventilación o enfriamiento interior con filtros y componentes que eviten el ingreso de polvo al interior de la máquina.
  14. Tener botón de devolución de monedas en caso de que las mismas se queden atoradas.
  15. Accionar una sirena de alarma, en caso de apertura no autorizada o intento de apertura. Esta debe tener independencia de la alimentación eléctrica de la TVML y contar con su propia alimentación.
  16. Contar con alarmas que enviarán al sistema central como: "fuera de servicio", "pre-llenado de monedas ", "falta papel", “Apertura no Autorizada”, “Puertas Abiertas”, “Zona de Valores Abierta”.
  17. Contar con una certificación de compatibilidad con las especificaciones de Calypso Rev 3.1 como mínimo, expedida por una empresa certificadora autorizada por Calypso Network Association (CNA). Este requerimiento es deseable

6.1.7        Centro de atención al usuario (CAU)

  • Descripción general

“LA EMPRESA” debe:

  1. Proveer los centros de atención al usuario.
  2. Suministrar el módulo en sí, además del mobiliario necesario para su operación.
  3. Construir el módulo con perfiles de aluminio y en la parte superior con mamparas de cristal.
  4. Implementar en el módulo un mecanismo de seguridad para su apertura e ingreso de personal autorizado.
  5. Garantizar que el módulo tenga una ventana para atención a usuarios.
  6. Garantizar que el módulo tenga un buzón para quejas y sugerencias.
  7. Garantizar que el módulo cuente con el mobiliario necesario para albergar los equipos y lo necesario para su operación.
  8. Proporcionar en estos centros la información de política, lineamientos y horarios de servicio en general de Metrobús, y la atención de incidencias y fallas con las Tarjetas de Movilidad Integrada.
  9. Ubicar los módulos de acuerdo con las indicaciones dadas por Metrobús, asignando los horarios que se definen de la siguiente forma:

Días

Horario

Estaciones

Lunes a viernes

06:00 a 20:00

Estaciones / Terminales

Sábados

08:00 a 14:00

Estaciones / Terminales

 

  1. Ajustar los horarios de atención, los cuales podrán ser modificados y se definirán en común acuerdo con Metrobús, de acuerdo con las necesidades del Sistema.
  2. Proporcionar en cada CAU material impreso de apoyo a la orientación al usuario, sobre servicios, uso de tarjeta, uso de máquinas expendedoras, transbordos, etc.
  3. Poder cerrar un CAU únicamente en días autorizados. Estos días serán aquellos establecidos en la Ley Federal del Trabajo vigente a la fecha del cierre; para el caso de los períodos vacacionales es obligación de “LA EMPRESA” asignar el personal necesario para que los CAU permanezcan siempre abiertos.
  4. Equipar los CAU con mínimo un PC de última generación, un lector de medios de pagos que permita la lectura y escritura de la Tarjeta de Movilidad Integrada y, opcionalmente una impresora.
  5. Suministrar un aplicativo que permita la lectura y escritura de Tarjetas de Movilidad Integrada. Este aplicativo debe permitir la gestión de seguridad de las transacciones con SAM físico, y en un futuro, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” Y “METROBÚS” para la implementación, a través de SAM remoto, e incorporar la API para interacción con medios de pago. Este aplicativo debe:
  6. Tener comunicación directa con el sistema central.
  7. Generar un registro de las transacciones realizadas en el CAU.
  8. Registrar el inicio y el fin de la operación de un CAU.
  9. Es deseable que puedan desarrollar los aplicativos por medio de Eclipse Keyple™, el cual es una API de código abierto para la integración y el desarrollo de aplicaciones de peaje, permitiendo que los desarrollos implementados por operadores o integradores se basen en una base homologada, a través de un conjunto de librerías de código abierto implementadas inicialmente en Java y C++, compatibles con cualquier arquitectura de terminales, sea móvil, embebida o distribuida, e interoperables con cualquier lector de tarjetas inteligentes: propietario, estándar, local o remoto.

 

  • Especificación Técnica

El lector de tarjetas del CAU debe:

  1. Ser compatible con el estándar ISO 14443 Tipo A y B.
  2. Contar con una certificación de compatibilidad con las especificaciones de Calypso Rev 3.1 como mínimo, expedida por una empresa certificadora autorizada por Calypso Network Association (CNA). Este requerimiento es deseable.

 

6.1.8      Sistema de videovigilancia (SVV)

  • Descripción general

“LA EMPRESA” debe:

  1. Instalar en cada una de las estaciones un conjunto de cámaras que permitan monitorear el área de acceso donde se ubican los torniquetes, dando prioridad al monitoreo del acceso por las puertas de cortesía o garitas.
  2. Almacenar todas las imágenes generadas por las cámaras en un NVR (Network Video Recorder).
  3. Gestionar remotamente todos los NVR, el acceso debe estar protegido con contraseña.
  4. Permitir a Metrobús la gestión remota de todos los NVR, el acceso debe estar protegido con contraseña.
  5. Instalar todos los NVR en lugares seguros para evitar el acceso no autorizado o pérdida del equipo.
  6. Determinar puntos de instalación de las cámaras que permitan la mejor visualización al acceso a la estación por la puerta de cortesía o garita.
  7. Realizar el montaje de las cámaras sobre superficies o estructuras sólidas de tal forma que se obtenga una cobertura ideal, evitando el acceso o manipulación malintencionada de terceros.
  8. Acordar la calidad de grabación, compresión, horario y demás características configurables con Metrobús.
  • Especificación técnica cámaras

Las cámaras suministradas por “LA EMPRESA” deben:

  1. Ser de tipo domo
  2. Tener una resolución mínima 1280 x 720 píxeles
  3. Tener lente fijo gran angular
  4. Permitir la grabación de video mínimo a 30 cuadros por segundo (fps)
  5. Ser cámaras IP con estándar ONVIF
  6. Contar con protección contra agua y polvo mínimo IP54 e IK09
  7. Soportar compresión H.264 o H.264+ o MJPEG
  8. Contar con alimentación Power-over-Ethernet (PoE). Este requerimiento es deseable
  • Especificación técnica NVR

El NVR suministrado por “LA EMPRESA” debe:

  1. Contar con mínimo de 4 canales.
  2. Es deseable alimentación Power-over-Ethernet (PoE).
  3. Tener entrada para conexión de cámaras IP RJ/45 100/1000 Mbps
  4. Tener puerto Rj-45 interfaz de red Ethernet 100/1000 Mbps
  5. Tener conexión con el software de gestión de videovigilancia de “LA EMPRESA” y Metrobús
  6. Soportar compresión H.264/H.264+/MJPEG, estándar ONVIF
  7. Permitir almacenamiento de los videos como mínimo durante 60 días, una vez que vence este periodo, las imágenes pueden borrarse. (es aceptable sobrescribirlas).
  8. Contar con discos duros diseñados para plataformas de videovigilancia

6.1.9       Sistema de suministro eléctrico

  • Descripción general

“LA EMPRESA” debe:

  1. Garantizar que el Sistema de Peaje y Control de Acceso esté diseñado para operar con sistemas de suministro eléctrico ante la falta del sistema eléctrico de la estación, de esta forma asegurar la operación de forma constante de dicho sistema.
  2. Suministrar una fuente ininterrumpida de poder (UPS), a la cual estén conectados todos los equipos del Sistema de Peaje y Control de Acceso instalados en una estación.
  3. Suministrar una planta eléctrica de emergencia para cada dos estaciones.
  4. Realizar la gestión y reubicación de las plantas eléctricas según sea la necesidad del sistema, así como la supervisión durante el tiempo que dure la falta de energía y el suministro de los combustibles necesarios durante el evento.
  • Especificación técnica UPS

La UPS suministrada por “LA EMPRESA” debe:

  1. Poder suministrar energía eléctrica a los equipos de peaje y control de acceso de una estación durante mínimo 120 minutos de operación
  2. Ser Interactiva o tipo ONLINE según arquitectura implementada
  3. Contar con baterías libres de mantenimiento
  4. Permitir el uso de baterías externas de fácil instalación y mantenimiento
  5. Contar con la opción de Bypass con el fin de realizar su mantenimiento
  6. Contar con comunicación Ethernet para conexión con el sistema central

Nota: El dimensionamiento de la capacidad (KVA) debe ser establecida dependiendo del consumo de los equipos instalados. Esta debe ser presentada para aprobación de Metrobús.

  • Especificación técnica planta eléctrica (PLE)

La PLE suministrada por “LA EMPRESA” debe:

  1. Ser móvil y permitir su traslado de forma sencilla a otra estación
  2. Permitir una operación de un mínimo de cuatro días, capaz de suministrar energía eléctrica a los equipos de peaje y control de acceso de una estación
  3. Contar con una salida de voltaje de 110V – 60 Hz
  4. Tener alimentación a gasolina o diésel
  5. Contar con arranque manual, transistorizado o eléctrico (Con botón)
  6. Ser de fácil instalación y mantenimiento

Nota: El dimensionamiento de la capacidad (KVA) debe ser establecida dependiendo del consumo de los equipos instalados. Esta debe ser presentada para aprobación de Metrobús.

6.2 Elementos externos

Se relacionan a continuación los elementos de la arquitectura del Sistema de Peaje y Control de Acceso que se complementan para la operación, pero no están instalados en terminales y estaciones.

6.2.1        Terminal móvil para supervisión (TMS)

  • Descripción general

El TMS suministrado por “LA EMPRESA” debe:

  1. Permitir a un supervisor de Metrobús realizar las siguientes acciones sobre la Tarjeta de Movilidad Integrada en situaciones de contingencia:
  2. Inspección
  3. Validación
  4. Consulta
  5. Recarga
  6. Venta

Las funciones habilitadas en la TMS se resumen en la siguiente tabla:

Modo

Funciones

Descripción

Datos

SUPERVISIÓN EN ESTACIÓN

Inspección

Lectura de tarjeta

Se debe permitir la lectura de todos los campos que conforman la tarjeta Calypso para establecer que la tarjeta es funcional y no presenta errores de almacenamiento de datos.

●         Revisar el Modelo de Datos para tarjetas con Microprocesador V 3.3

Inspección

Tarjeta con Validación

Se debe permitir la lectura de campos transaccionales para establecer que la tarjeta fue validada para el ingreso a la estación.

●         Fecha y hora de la última validación

●         Estación última validación

●         Monto de la validación

●         Tipo perfil

Inspección

Tarjeta con transbordo

Se debe permitir la lectura de campos transaccionales para establecer si la tarjeta puede realizar un transbordo.

●         Fecha y hora última validación

●         Fecha y hora último evento

Inspección

Verificación de validación para reingreso

En caso de contingencia debe permitir la lectura de campos transaccionales para permitir un reingreso al sistema sin cobro.

●         Fecha y hora última validación

●         Location ID última validación

●         Estación última validación

 

Validación

Descuento de tarifa

En caso de contingencia debe permitir la validación y realizar el descuento de la tarifa autorizada.

●         Número de serie

●         Tipo perfil

●         Ultima validación

●         Fecha y hora última validación

●         Saldo

●         Verificación firmas

●         Contadores

●         Location_ID de la máquina

●         Fecha y hora transacción máquina

●         Tipo de operación

Consulta

Lectura de saldo

Se debe permitir la lectura del saldo.

●         Número de serie

●         Tipo perfil

●         Saldo

MODO DE RECARGA Y VENTA DE TARJETAS

Recarga

Recarga de tarjetas

En caso de contingencia debe permitir la recarga de la Tarjeta de Movilidad Integrada

●         Número de serie

●         Tipo perfil

●         Ultima validación

●         Fecha y hora última validación

●         Saldo

●         Verificación firmas

●         Contadores

Venta

Venta de tarjeta

En caso de contingencia debe permitir registrar la venta de una Tarjetas de Movilidad Integrada entregarla con saldo en $0.00 pesos o recargando directamente un monto en la tarjeta.

La TMS debe de diferenciar entre los tipos de operación venta y recarga, para el envío de datos al sistema central.

●         Número de serie

●         Tipo perfil

●         Saldo

●         Verificación firmas

●         Contadores

 

  1. Permitir la impresión de comprobantes para fines de supervisión, sanción y control.
  2. Estar habilitada para imprimir ciertos parámetros de la estructura de datos de la tarjeta; como mínimo los datos base de las últimas transacciones de la tarjeta con los siguientes campos: serie de la tarjeta, fecha, hora, saldo, cobro, validación(es), terminal o estación, contadores e identificador de la terminal.
  3. Permitir la parametrización de los parámetros para imprimir.
  4. Permitir la visualización de los parámetros en la pantalla del dispositivo.
  5. Permitir la impresión de los parámetros en papel.
  6. Permitir la actualización de parámetros como la estructura tarifaria y cualquier otro parámetro operacional que Metrobús solicite, así como la actualización de listas negras y blancas. La actualización debe poder hacerse desde el sistema central.
  7. Presentar una pantalla de ingreso al encender el dispositivo que solicite los datos de usuario para el inicio de una sesión.
  8. Imprimir un ticket al finalizar la sesión en el que se resuman todas las actividades llevadas a cabo en el transcurso de esa sesión, incluidas aquellas actividades tales como inspección, validación, consulta de saldo, recarga y venta.
  9. Gestionar la seguridad de las transacciones con SAM remoto, el cual no formará parte del alcance inicial, y podrá ser incluido posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” y “METROBÚS” para su implementación.
  10. Estar preparado para gestionar la seguridad de las transacciones con un SAM local cuando Metrobús lo solicite.
  11. Disponer de mecanismos de seguridad para el bloqueo de saldos y SAM en caso pérdida o robo del dispositivo.
  12. Contar con mecanismos de seguridad que eviten el cambio de ID Location asignado.
  13. Tener un contador de transacciones, el cual no pueda ser reiniciado de forma local.
  14. Contar con capacidad de conexión a la red WiFi de la estación. Siempre que el servicio de WiFi de la estación esté habilitado y no presente fallas, el TMS debe estar conectado a esta red para su operación.
  15. En caso de contingencias o fallas en la conectividad WiFi, el dispositivo debe tener la capacidad de conectarse a una red móvil 3G o superior. Para esto “LA EMPRESA” es responsable de suministrar una SIM card y habilitar un plan de datos de internet para mantener la conectividad del dispositivo en estos casos de contingencia.
  16. Incorporar la API para interacción con medios de pago a través del SAM físico de manera local, para gestionar la seguridad de las transacciones realizadas en la Tarjeta de Movilidad Integrada. También deberá estar preparada para habilitar el uso de SAM remoto, el cual no formará parte del alcance inicial, y podrá ser incluido posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” y “METROBÚS” para su implementación.
  17. Gestionar múltiples usuarios con diferentes perfiles, a los cuales se les podrá habilitar la ejecución de funciones específicas del TMS. Estas funciones se describen en la tabla detallada en el literal a).
  18. Permitir validación en modo normal: La antena solo será habilitada cuando sea solicitada para la lectura, validación y/o recarga, tal que permita una mayor duración a la batería.
  19. Permitir validación en modo continuo: La antena debe estar activada todo el tiempo para efectuar las operaciones de lectura, validación y/o recarga, a pesar de que la duración de la batería se acorte.
  20. Imprimir un recibo al finalizar una recarga y/o una venta, cuando el dispositivo está en MODO DE RECARGA Y VENTA DE TARJETAS, con las siguientes características:

  1. La información presentada en el recibo debe ser parametrizable.
  2. Imprimir un recibo con el RESUMEN DE ACTIVIDADES con las siguientes características:

  1. La información presentada en el recibo debe ser parametrizable.

 

“LA EMPRESA” es responsable del suministro y mantenimiento de los terminales móviles para supervisión.

 

  • Especificación técnica

El TMS debe:

  1. Contar con un lector de tarjetas sin contacto que cumpla con el estándar ISO 14443 A y B.
  2. Contar con capacidad de alojar mínimo dos (2) SAM.
  3. Ser resistentes al polvo y agua con un índice de protección mínimo nivel IP 54 y tener en cuenta la climatología de la Ciudad de México y en particular de la zona.
  4. Contar con una capacidad de almacenamiento mínimo de 30 días de transacciones, además de los registros de las listas negras, listas blancas y otras Metrobús solicite.
  5. Contar con un display mínimo 480x640 pixeles VGA Color TFT.
  6. Contar con comunicación móvil mínimo 3G.
  7. Contar con una capacidad mínima de alojar un (1) SIM.
  8. Contar con comunicación directa con el sistema central para carga, descarga e intercambio de información.
  9. Contar con un sistema de descarga de datos alternativo para las contingencias vía USB.
  10. Contar con una impresora con corte automático de papel.
  11. Contar con un sistema de seguridad para autenticación de usuario por medio de contraseña.
  12. Contar con una batería de larga duración
  13. Contar con una batería adicional.
  14. Contar con un cargador de escritorio para el equipo y carga simultánea de pila adicional.
  15. Incluir un accesorio para el transporte seguro en la cintura.
  16. Contar con una certificación de compatibilidad con las especificaciones de Calypso Rev 3.1 como mínimo, expedida por una empresa certificadora autorizada por Calypso Network Association (CNA). Este requerimiento es deseable.
  17. Contar con la certificación EMV L1.
  18. Contar con la certificación EMV L2.
  19. Contar con la certificación PCI PTS.
  20. Operar con tiempo de procesamiento de transacción de validación menor a 500 milisegundos.

6.3.1 API para interacción con medios de pago

     Descripción general

La API para interacción con medios de pago debe:

  1. Facilitar la aceptación de los medios de pago del Sistema de Peaje y Control de Acceso.
  2. Estandarizar la interacción de los medios de pago con los siguientes dispositivos:

 

  1. TVMC y TVML
  2. Terminales móviles de supervisión
  3. Validadores
  4. Computadores de los centros de atención al usuario que cuentan con dispositivo de personalización

 

  1. Estandarizar la interacción de estos dispositivos con los niveles superiores para el envío de información transaccional. La API se debe poder instalar en dispositivos de distintos proveedores y referencias técnicas, siempre y cuando estos cumplan con las especificaciones exigidas en este anexo.
  2. Ser desarrollada por “LA EMPRESA”, quien debe entregar el código fuente de dicha API y su documentación técnica a Metrobús para facilitar la evolución del Sistema de Peaje y Control de Acceso, y la futura integración de hardware de distintos proveedores.
  3. Suplir funciones, agrupadas por capas, en uno o más módulos base, en donde se desarrollen las funcionalidades necesarias para llevar a cabo el procesamiento de una transacción realizada con un medio de pago. Cada capa ofrece un conjunto de funcionalidades que se incorporan a la aplicación principal de cada dispositivo. Estas se presentan a continuación.

 

6.3.2     Funcionalidades de la API para interacción con medios de pago

La API para interacción con medios de pago debe:

  1. Incorporar una capa de medio de pago que implemente todos los comandos propios del estándar Calypso para interactuar con los medios de pago, los SAM locales y cuando aplique, también con el SAM remoto. Así mismo, debe realizar el manejo de sesiones seguras y la interacción con las aplicaciones y archivos presentes en el medio de pago.
  2. Incorporar una capa de presentación que implemente funcionalidades que permitan integrar las interfaces de usuario y los periféricos que tenga el dispositivo con el software o aplicación encargado de procesar los medios de pago. Por ejemplo, por medio de esta capa el visor de un dispositivo puede mostrar la tarifa descontada al usuario o habilitar un torniquete.
  3. Incorporar una capa de red que:
  4. Implemente funcionalidades para el manejo de datos a través de protocolos de comunicación que permitan el intercambio de información con niveles superiores. Por ejemplo, esta capa se encarga de efectuar el envío de las transacciones al sistema central, mantener actualizadas las listas negras, entre otros.
  5. Pueda usar librerías de código abierto, siempre y cuando, estas estén respaldadas por entidades o comunidades de software altamente conocidas en el mercado.
  6. Mantenga actualizadas las librerías siguiendo los últimos estándares de la industria en cuanto a seguridad.
  7. Considere para su desarrollo mecanismos para el procesamiento de solicitudes que requieran operaciones de larga duración, tales como el uso de tareas asíncronas y procesos en segundo plano. Esto con el objetivo de no bloquear el flujo normal de las tareas principales que ejecuta la aplicación del dispositivo.
  8. Incorporar una capa de reglas de negocio que implemente funcionalidades para el cumplimiento de las reglas del negocio, las cuales deben permitir obtener la tarifa correcta a descontar al usuario de acuerdo con la estructura tarifaria definida. Por ejemplo, esta capa implementa las reglas de validación, los descuentos en la tarifa por tipo de perfil, las reglas de los transbordos, entre otros.
  9. Incorporar una capa de transacciones que implemente la gestión de los datos para la construcción de transacciones en el formato del sistema central o cualquier otro a petición de Metrobús. Entre los más comunes se encuentran JSON y XML.

6.3.3        Especificaciones técnicas

La API para interacción con medios de pago debe:

 

  1. Ser desarrollada para poder ser incorporada en dispositivos con sistemas operativos Windows, Linux, Android y iOS.
  2. Ser entregada como una serie de librerías precompiladas con sus correspondientes archivos de encabezados, los cuales deben definir el nombre, parámetros y tipo de retorno de las funciones que hacen parte de cada librería.
  3. Incluir el código fuente con su documentación, un manual de usuario y la documentación técnica que describa el uso e implementación de cada una de las capas descritas anteriormente y ejemplos sencillos de esto.
  4. Es deseable que puedan desarrollar los aplicativos por medio de Eclipse Keyple™, el cual es una API de código abierto para la integración y el desarrollo de aplicaciones de peaje, permitiendo que los desarrollos implementados por operadores o integradores se basen en una base homologada, a través de un conjunto de librerías de código abierto implementadas inicialmente en Java y C++, compatibles con cualquier arquitectura de terminales, sea móvil, embebida o distribuida, e interoperables con cualquier lector de tarjetas inteligentes: propietario, estándar, local o remoto.

 

6.4 Sistema central

6.4.1        Descripción general

El sistema central suministrado por “LA EMPRESA” debe:

  1. Proveer toda la información relacionada con las operaciones vinculadas al Sistema de Peaje y Control de Acceso en los tiempos y con las características requeridas para controlar la correcta operación de este, así como hacer seguimiento a las operaciones hechas con la Tarjeta de Movilidad Integrada, asegurando en todo momento la disponibilidad de esta información.
  2. Tener la capacidad de migrar la información almacenada en la base de datos a otros sistemas que Metrobús le solicite.
  3. Permitir a Metrobús el acceso ilimitado y completo a la base de datos.
  4. Cumplir con una alta capacidad de parametrización, misma que se verá reflejada en la operación (venta, recarga, personalización, inspección y validación), los parámetros deben ser modificables desde el sistema central sin tener que pasar por una actualización de los aplicativos de los diferentes dispositivos.
  5. Estar en idioma español latinoamericano.
  6. Estar hospedado en la nube.
  7. Interactuar con el sistema central del Sistema Integrado de Transporte Público de México para el intercambio de información transaccional de peaje y parámetros operacionales del sistema. Metrobús entregará a “LA EMPRESA” la documentación técnica necesaria para lograr la interacción cuando requiera la implementación de esta.

 

6.4.2        Funcionalidades del sistema central

El sistema central debe contar con las siguientes funcionalidades, las cuales se detallan en las siguientes subsecciones:

  1. Manejo de cuentas de usuario: permite la gestión de cuentas para los usuarios de “LA EMPRESA”, de Metrobús y del sistema de transporte público.
  2. Recepción y procesamiento: permite la recepción y procesamiento de la información del sistema de peaje (venta y recarga, validación y control de acceso).
  3. Administración y distribución de parámetros: permite la distribución de distintos parámetros operacionales del sistema.
  4. Gestión de seguridad: permite la gestión de seguridad de la Tarjeta de Movilidad Integrada.
  5. Gestión de SAM local y SAM remoto: permite la gestión de la seguridad de las transacciones mediante SAM local y SAM remoto. Para el caso de SAM remoto no formará parte del alcance inicial, y podrá ser incluido posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” y “METROBÚS” para su implementación.
  6. Gestión de inventario: permite la gestión de inventario de los elementos del sistema.
  7. Monitoreo de transacciones para detección de fraude: permite supervisar el uso de las Tarjetas de Movilidad Integrada y realizar acciones de mitigación de fraude.
  8. Gestión y atención de usuarios: permite la respuesta a las solicitudes de los usuarios.
  9. Generación de reportes: permite la generación de reportes transaccionales, operacionales, financieros y de niveles de servicio.
  10. Gestión de videovigilancia: permite el acceso remoto al NVR y las cámaras de videovigilancia para descarga de videos y visualización en tiempo real, tanto para “LA EMPRESA” como para Metrobús.

 

  • Manejo de cuentas de usuario

 

  1. El sistema central debe permitir la gestión de cuentas de usuario de operadores de “LA EMPRESA” por medio de:

 

  1. Creación de cuentas con un nombre de usuario y contraseña.
  2. Asignación de información del usuario como nombres, apellidos, identificación, rol, entidad, responsabilidades e información de contacto.
  3. Actualización de información de usuario.
  4. Actualización y recuperación de contraseña.
  5. Asignación de funciones dentro del sistema central de acuerdo con el rol asignado, de manera que tenga acceso a las funcionalidades definidas para un rol en particular.
  6. Eliminación de cuentas de usuario.

 

  1. El sistema central debe permitir la gestión de cuentas de usuario de operadores de Metrobús por medio de:

 

  1. Creación de cuentas con un nombre de usuario y contraseña.
  2. Asignación de información del usuario como nombres, apellidos, identificación, rol, entidad, responsabilidades e información de contacto.
  3. Actualización de información de usuario.
  4. Actualización y recuperación de contraseña.
  5. Asignación de funciones dentro del sistema central de acuerdo con el rol asignado, de manera que tenga acceso a las funcionalidades definidas para un rol en particular.
  6. Eliminación de cuentas de usuario.

 

  1. El sistema central debe permitir la gestión de cuentas de usuario de transporte por medio de:

 

  1. Creación de cuentas con un nombre de usuario y contraseña.
  2. Asignación de información del usuario como nombres, apellidos, identificación e información de contacto.
  3. Actualización de información de usuario.
  4. Actualización y recuperación de contraseña.
  5. Eliminación de cuentas de usuario.
  6. Sincronización con datos de peaje del usuario como historial de viajes realizados con los medios de pago e información de saldo de los medios de pago.
  7. Sincronización con datos de respuesta a peticiones, quejas, reclamos y sugerencias interpuestas por el usuario.
  8. Sincronización con cualquier otra información de interés asociada a una cuenta de usuario y que pueda ser consultada a través del sitio web, aplicaciones móviles y chatbot.

 

  1. La funcionalidad de manejo de cuentas de usuario debe permitir la asignación de permisos y restricciones de acceso a la información y el uso de las distintas funcionalidades del sistema central de acuerdo con el tipo de usuario y el rol que este tenga dentro del Sistema de Peaje y Control de Acceso. Estos deben ser acordados con Metrobús.

 

  • Recepción y procesamiento
  1. El sistema central debe recibir, procesar y almacenar las distintas transacciones generadas por el sistema de peaje como:

 

  1. Transacciones de validación de medios de pago.
  2. Transacciones de venta de medios de pago.
  3. Transacciones de recarga de medios de pago generadas por dispositivos en campo o por los diferentes canales de recarga remota, la cual no formará parte del alcance inicial, y podrá ser incluida posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” y “METROBÚS” para su implementación.
  4. Transacciones de emisión de medios de pago.
  5. Transacciones de personalización de medios de pago.
  6. Cualquier otra transacción generada por los dispositivos de campo o cualquier otro sistema como resultado de realizar una operación con cualquier medio de pago.
  7. Se deben transmitir las operaciones efectuadas en cada estación en tiempo real excepto en los casos de contingencia o mantenimiento del sistema central con un tiempo las cuales deben ser transmitidas en un tiempo no mayor de 24 horas.

 

  • Administración y distribución de parámetros

 

El sistema central debe permitir como mínimo la administración y distribución de los siguientes parámetros:

 

  1. Tarifas: debe ser capaz de modificar la estructura tarifaria del Sistema Metrobús con un máximo de tiempo de aviso de 24 horas y distribuir las actualizaciones a los diferentes dispositivos del Sistema de Peaje y Control de Acceso. Incluye la modificación de parámetros operacionales como las tarifas y transbordos por perfil de usuario, línea de transporte, horarios, días, y otros parámetros que sean necesarios para suplir las necesidades tarifarias de los servicios de transporte del Sistema Metrobús.
  2. Fechas y horarios: debe ser capaz de actualizar las fechas y horarios desde el sistema central.
  3. Listas negras: debe ser capaz de manejar listas negras con una capacidad mínima de 100 mil registros individuales o en rangos y distribuir las actualizaciones a los diferentes dispositivos del Sistema de Peaje y Control de Acceso.
  4. Listas blancas: debe ser capaz de manejar listas blancas con una capacidad mínima de 100 mil registros individuales o en rangos y distribuir las actualizaciones a los diferentes dispositivos del Sistema de Peaje y Control de Acceso.
  5. Actualizaciones de software y firmware: debe ser capaz de enviar actualizaciones de software o firmware de los dispositivos y distribuir las actualizaciones a los diferentes dispositivos del Sistema de Peaje y Control de Acceso.

 

El listado propuesto es enunciativo más no limitativo por lo que “LA EMPRESA” debe especificar claramente los parámetros que se pueden modificar desde el sistema central.

 

  • Gestión de seguridad

 

El sistema central debe cumplir con los requerimientos de seguridad definidos en la documentación técnica de la Tarjeta de Movilidad Integrada que será proporcionada por Metrobús. La difusión de esta documentación será sólo bajo un esquema de confidencialidad entre Metrobús y “LA EMPRESA”, mismo que será reflejado por la firma del "Convenio de Confidencialidad" que formará parte integral del contrato de prestación de servicios de peaje y control de acceso, motivo de esta especificación.

 

  • Gestión de SAM local y SAM remoto

 

  1. Los requerimientos de seguridad y funcionamiento de la gestión de SAM local están definidos en la documentación técnica que será proporcionada por Metrobús. La difusión de estos documentos será sólo bajo un esquema de confidencialidad entre Metrobús y “LA EMPRESA”, mismo que será reflejado por la firma del "Convenio de Confidencialidad" que formará parte integral del Contrato de prestación de servicios de peaje y control de acceso, motivo de esta especificación.

 

  1. El sistema central debe estar preparado para permitir la gestión remota de seguridad con el SAM remoto que no formará parte del alcance inicial, y podrá ser incluido posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” y “METROBÚS” para su implementación. Esta funcionalidad debe estar disponible para poder ejecutar transacciones de recarga realizadas en los TVMC, TMS, dispositivo portátil y teléfonos inteligentes con tecnología NFC, y transacciones en los dispositivos de personalización y en los centros de atención al usuario. Este SAM remoto debe:
  2. Contar con la capacidad para escalar y gestionar de forma simultánea las transacciones generadas por los distintos dispositivos y sistemas que usen el SAM remoto, sin que esto implique disminución en la velocidad de la transacción. "LA EMPRESA" debe considerar en el dimensionamiento del SAM remoto la redención de recargas remotas y las recargas a través del dispositivo portátil y la aplicación móvil que pueden ser realizadas sobre la Tarjeta de Movilidad Integrada.
  3. Gestionar de forma segura llaves criptográficas para realizar las distintas transacciones que están disponibles en el Sistema de Peaje y Control de Acceso.
  4. Permitir el uso de contadores para auditar el número de usos de las distintas llaves almacenadas.
  5. Gestionar de forma segura transacciones con medios de pago de tecnología Calypso.
  6. Abrir sesiones seguras para leer y escribir en un medio de pago de tecnología Calypso.
  7. Intercambiar comandos Application Protocol Data Unit (APDU).
  8. Incorporar un software que permita la interacción con los diferentes dispositivos y elementos que requieran el uso del SAM remoto para realizar una transacción.
  9. Contar con al menos un HSM productivo y uno redundante.

 

  1. “LA EMPRESA” es responsable de adquirir las licencias necesarias para la implementación del SAM remoto que no formará parte del alcance inicial, y podrá ser incluido posteriormente, conforme sea la necesidad de “METROBÚS” o de la ciudad, con las negociaciones a que haya lugar entre “LA EMPRESA” y “METROBÚS” para su implementación.

 

  1. En caso de presentarse una disminución en el tiempo de gestión simultánea de las transacciones “LA EMPRESA” debe presentar a Metrobús para aprobación alternativas que permitan disminuir los tiempos de respuesta.

 

  • Gestión de inventario

 

El sistema central debe contar con una herramienta para la gestión de inventario que permita:

 

  1. Gestionar el inventario de todos los dispositivos, elementos, estaciones, terminales, componentes y versiones de software del Sistema de Peaje y Control de Acceso suministrados por “LA EMPRESA”.

 

  1. Realizar la trazabilidad de cada elemento de software y hardware (validadores, torniquetes, terminales de venta y recarga automática, SAM, y demás elementos que componen el Sistema de Peaje y Control de Acceso) desde la instalación hasta su retiro.

 

  1. Agregar, consultar y actualizar un elemento del inventario.

 

  1. Asignar como mínimo a cada elemento:
  2. Un identificador único
  3. Un nombre (por ejemplo, validador, tarjeta, torniquete, TVML, etc.).
  4. Una ubicación (centro de control, Metrobús, terminal, estación, en caso de SAM el ID de identificación del equipo en el cual está instalado, otros).

 

  1. Visualizar el estado operativo de los elementos, de manera que sea posible conocer si se encuentran activos e inactivos, mantenimiento, eliminados, no funcional, etc.

 

  1. Permitir la configuración de una estación como tipo estación de transbordo.

 

  1. Modificar el estado operativo de los elementos.

 

  1. Generar reportes de los elementos que están en el inventario, estado actual, ubicación de equipos (por terminal, estación), para SAM listado con su estado y ubicación, entre otros a petición de Metrobús.

 

  1. Incluir en el inventario para el caso de los dispositivos portátiles, adicional a la información solicitada, el serial, la fecha de compra, la fecha de venta y los datos del usuario final.

 

  • Monitoreo de transacciones para detección de fraude

 

El monitoreo de uso de tarjetas es un mecanismo de mitigación de fraude. Las funcionalidades básicas requeridas son:

 

  1. Supervisar el uso de las Tarjetas de Movilidad Integrada mediante mecanismos de detección de fraude que pueden implementarse utilizando solo la información transaccional correspondiente a las líneas del Sistema Metrobús, con base en la documentación técnica de la Tarjeta de Movilidad Integrada que será proporcionada por Metrobús a “LA EMPRESA”.
  2. Generar automáticamente alertas relacionadas con posibles situaciones de fraude (por ejemplo, un aumento en el saldo sin una recarga correspondiente, usos excesivos en un solo punto de validación).
  3. Permitir a un operador analizar cada una de las alertas el cual determina si existe o no fraude, eliminando la alerta o incluyendo la Tarjetas de Movilidad Integrada en lista negra.
  4. Permitir actualizar las listas negras cuando se detecten casos de uso fraudulento de la Tarjeta de Movilidad Integrada.
  5. Detectar saltos en los contadores de los SAMs.

 

  • Gestión y atención de usuarios

 

  1. El sistema central debe canalizar las peticiones, quejas, reclamos y sugerencias de los usuarios, y generar una respuesta a estas. Esta funcionalidad debe interactuar con las otras que tiene el sistema central para la consulta de información que permita la resolución de las solicitudes de los usuarios, por ejemplo, historial de transacciones.
  2. “LA EMPRESA” debe poner a disposición de Metrobús una herramienta de consulta que le permita monitorear todas las solicitudes de los usuarios y las respuestas a estos.

 

  • Generación de reportes

 

El sistema central debe contar con una herramienta que permita generar reportes personalizados de forma dinámica.

 

La herramienta de generación de reportes debe:

 

  1. Generar los siguientes reportes preconfigurados:

 

  1. Reportes transaccionales de ventas, recargas, recargas remotas, validaciones y control de acceso. Estos deben ser parametrizables teniendo en cuenta el tipo de transacción, rango de fechas, periodos de tiempo (horas, días, semanas, meses y años), el perfil de usuario, canal de recarga y líneas de transporte.
  2. Reportes operacionales con información de la operación como demanda de pasajeros. Estos deben ser parametrizables teniendo en cuenta el tipo de operación, rango de fechas, periodos de tiempo (horas, días, semanas, meses y años) y líneas de transporte.
  3. Reportes financieros con información de los recaudos por las ventas y recargas, recolección de dinero, consignaciones, compensaciones y cualquier otra información financiera de interés. Estos deben ser parametrizables teniendo en cuenta el tipo de transacción, rango de fechas, periodos de tiempo (horas, días, semanas, meses y años) y líneas de transporte.
  4. Reportes de contadores de los SAMs por día, semana y mes.
  5. Reportes mensuales de indicadores de desempeño con el cálculo de los indicadores exigidos a “LA EMPRESA”.
  6. Reportes mensuales con el cálculo del factor de calidad.
  7. Reportes mensuales detallados de las redenciones realizadas en dispositivos portátiles, TVMC
  8. Reporte diario/mensual/bimestral de Tarjetas de Movilidad Integrada con redención y efectivamente utilizadas (validadas) en el sistema Metrobús.        
  9. Reporte por horas/minutos/segundos del uso de redenciones en TVMC.
  10. Reporte de tarjetas con redención y tarjetas efectivamente usadas (validadas) dentro del sistema MB.

 

  1. Calcular mensualmente todos los indicadores de desempeño del sistema y el factor de calidad y entregar un reporte con esta información.

 

  1. Permitir la generación de reportes personalizados de forma dinámica haciendo uso de la información disponible en la base de datos, de tal forma que se puedan crear reportes diferentes a los preconfigurados. La generación de estos reportes puede ser programada (en fechas y horas específicas) o a demanda (cuando se requiera).

 

  1. Contar con una interfaz de usuario a la que puede acceder Metrobús a través de usuarios autorizados de forma irrestricta.

 

  1. Ser compatible con la base de datos.

 

  1. Permitir que al menos cinco usuarios autorizados puedan acceder de forma paralela para su uso.

 

“LA EMPRESA” debe brindar capacitaciones sobre el uso de la herramienta cuando Metrobús lo solicite.

 

  • Gestión de videovigilancia

 

  • Software de gestión de videovigilancia (Sistema central)

 

El sistema central debe incorporar un software de gestión de la videovigilancia. El software de gestión de la videovigilancia debe:

 

  1. Contar con una interfaz intuitiva, comprensible y amigable para el usuario.
  2. Acceder de forma remota al NVR y las cámaras de videovigilancia.
  3. Visualización en tiempo real de los videos generados por el sistema de videovigilancia.
  4. Permitir la consulta y descarga de videos almacenados por minuto y hora, por rangos de minutos y horas, por día, por rango de fechas, por estación y por dispositivo.
  5. Administrar y monitorear en tiempo real los videos generados y almacenados por el sistema de videovigilancia.
  6. Monitorear el estado operativo del sistema de videovigilancia.
  7. Interactuar con el sistema de videovigilancia para el envío de parámetros de configuración.
  8. Agregar y eliminar cámaras de videovigilancia y NVR.

 

  • Software de gestión de videovigilancia (Local)

 

“LA EMPRESA” debe entregar un software on-premises, instalar y configurar en la ubicación que Metrobús determine, para el acceso remoto al sistema de videovigilancia. Este debe permitir la interacción directa con el sistema de videovigilancia. Entre otras cosas este software debe tener como mínimo las siguientes funciones:

 

  1. Contar con una interfaz intuitiva, comprensible y amigable para el usuario.
  2. Acceder de forma remota al NVR y las cámaras de videovigilancia
  3. Visualización en tiempo real de los videos generados por el sistema de videovigilancia.
  4. Permitir la consulta y descarga de videos almacenados por minuto y hora, por rangos de minutos y horas, por día, por rango de fechas, por estación y por dispositivo.
  5. Monitoreo del estado operativo del sistema de videovigilancia.

 

6.4.3        Requerimientos de almacenamiento y procesamiento en nube

El sistema central debe estar alojado en la nube. El diseño del software debe incorporar buenas prácticas para permitir a los sistemas operativos o bases de datos realizar actualizaciones con pruebas mínimas. Adicionalmente, el sistema central debe cumplir con los siguientes requerimientos:

 

  1. Siempre que sea posible, los desarrollos asociados al sistema central deben contemplar implementaciones abiertas.

 

  1. La información se debe almacenar en una base de datos relacional que garantice la trazabilidad de esta. Esta debe tener licencia de uso tipo Centro de Datos, en idioma español e insensible a altas y bajas.

 

  1. Permitir realizar pruebas de actualización de software previo a su implementación.

 

  1. Incorporar mecanismos de seguridad orientados a la prevención de modificaciones accidentales o deliberadas que comprometan la integridad de la información. Estos incluyen:

 

  1. Administración de permisos y control de autenticación.
  2. Chequeos de integridad de la información.
  3. Respaldo de la información.
  4. Versionamiento de la información.

 

  1. Contar con un plan de recuperación ante desastres que permita recuperar la información en caso de eventos que impliquen la pérdida de información o fallas en el sistema central.
  2. Garantizar la existencia de servidores de respaldo donde se pueda redireccionar la información en caso de que los servidores principales fallen. Estos servidores se requiere que se cumpla la regla del 3-2-1 para las copias de seguridad, la cual debe de considerar realizar 3 copias de los datos del organismo en 2 soportes diferentes y alojar la tercera copia en 1 lugar físico distinto.
  3. Contar con hosting profesional en la nube debe estar alojado en un centro de datos certificado bajo los estándares de Uptime Institute Tier III, ICREA Nivel IV, ANSI/TIA 942 Rated III, o cualquier otro equivalente que satisfaga los criterios de diseño eléctrico, mecánico, arquitectónico y de telecomunicaciones presentes en estos estándares, con el fin de cumplir con las condiciones de redundancia y disponibilidad que estos establecen.
  4. Garantizar la transferencia de información por medio de canales de transmisión seguros, haciendo uso de estándares internacionales de seguridad. Se deben considerar como mínimo las siguientes características de seguridad:
  5. Integridad: condición bajo la cual la información corresponde a la totalidad de las transacciones o actividades realizadas.
  6. Auditable: el uso y/o modificación de la información debe ser rastreable a través de logs u otros mecanismos de registro.
  7. Confidencialidad: la información sólo debe ser legible por personas autorizadas.

 

  1. Ser escalable para soportar el crecimiento del volumen transaccional y la expansión del sistema de transporte.

 

  1. Proporcionar capacidad de almacenamiento adicional a demanda.

 

  1. Conocer y restringir la ubicación física de los servidores donde están almacenados los datos.

 

  1. Garantizar que las funcionalidades que almacenen, procesen y transmitan datos personales de los usuarios satisfagan las leyes de protección de datos personales de los Estados Unidos Mexicanos.

 

Contar con un documento que describa la seguridad perimetral y el plan de recuperación de desastre y continuidad de negocio, el cual debe de considerarse alojado en una nube con toda la infraestructura necesaria en esta última, donde el objetivo del diseño de disponibilidad sea de 99.99 % con un tiempo entre la última copia de seguridad creada y el momento del desastre, no mayor a 15 minutos, un objetivo de tiempo de recuperación que determine la cantidad máxima de tiempo tolerable necesario para que todos los sistemas críticos vuelvan a estar en línea no mayor a 8 horas, un tiempo de recuperación del trabajo en el cual se contempla que la cantidad máxima de tiempo tolerable que se necesita para verificar el sistema y / o la integridad de los datos una vez ya operando los sistemas críticos después del desastre sea de no más de 3 horas y un tiempo máximo de inactividad tolerable de máximo 11 horas; de manera tal que bajo estos parámetros pueda recuperarse la operación, en el esquema que designe Metrobús, de acuerdo a la siguiente imágen:

  1. “LA EMPRESA” debe garantizar el almacenamiento de la información histórica disponible de cada línea, es decir, desde el inicio de operación de cada línea.
  2. La información transaccional debe estar disponible durante todo el tiempo de vida del contrato.

 

Para el dimensionamiento de la capacidad de la base datos para almacenar la información, “LA EMPRESA” debe tener en cuenta como referencia la Línea 6 y 7 del Sistema Metrobús presenta un aproximado de 285.000 de transacciones diarias de validación y 80.000 transacciones diarias de recarga. “LA EMPRESA” es responsable de garantizar el aumento de la capacidad de almacenamiento y procesamiento en el sistema central para atender el incremento de transacciones de todas las líneas del Sistema Metrobús durante el contrato.

 

 

6.4.4       Verificación de datos en base de datos

 

  1. La base de datos del sistema central debe contener como mínimo todos los campos establecidos en el mapping de la tarjeta Full Calypso, y todos los que “LA EMPRESA” determine para la operación del Sistema de Peaje y Control de Acceso suministrado. Metrobús realizará la verificación de la inserción de los datos en la base de datos origen.
  2. La base de datos productiva debe mantener el detalle de la información, en caso de que sea necesario realizar tareas de consolidación por mantenimiento, se podrá realizar siempre y cuando exista un respaldo accesible para Metrobús en cualquier momento.

 

6.4.5        Requerimientos de información mínima disponible

 

“LA EMPRESA” debe garantizar la disponibilidad y el acceso como mínimo a la siguiente información:

 

  1. Información de validaciones
  2. Total, de validaciones por estación y autobús.
  3. Total, de validaciones y/o conteos por equipo (validador de torniquete, validador de autobús, puerta de cortesía y torniquete de salida).
  4. Validaciones por tarjeta en estación y validador.
  5. Validaciones por tarjeta (primera y última validación).
  6. Las anteriores por periodo de tiempo.

*Tiempo mínimo de diferenciación en segundos

 

  1. Información de ventas
  2. Total, de ventas.
  3. Total, de ventas por estación.
  4. Total, de ventas por máquina.
  5. Total, de ventas por tipo de transacción (venta o recarga) por referencia geográfica.

*Tiempo mínimo de diferenciación en segundos

 

  1. Información de colectas
  2. Total, de montos recolectados por corte de valores.
  3. Total, de montos recolectados por corte de valores por estación.
  4. Total, de montos recolectados por corte de valores por máquina.
  5. Las anteriores por periodo de tiempo (cortes, días, mes y hasta año).

 

  1. Información de tarjetas
  2. Tarjetas activadas.
  3. Tarjetas activadas por estación.
  4. Tarjetas activadas por máquina.
  5. Las anteriores por periodo de tiempo (desde 15 min., días, mes y hasta año).

 

  1. Historial de tarjetas (desde fecha de venta hasta última recarga)

 

6.4.6       Gestión de información del sistema de peaje y control de accesos en el Sistema Central que Metrobús determine

 

“LA EMPRESA” debe:

 

  1. Consolidar la información transaccional en el Sistema Metrobús y/o en el servidor local o nube que Metrobús determine durante la etapa de instalación y puesta en marcha. Metrobús suministrará la información de la estructura de la base de datos transaccional de los servidores espejo que permita el proceso de consolidación. “LA EMPRESA” debe recolectar la información, procesarla y ordenarla en la base de datos de acuerdo con los requerimientos que proporcione Metrobús. La actualización de información debe hacerse con un desfase no mayor a 24 horas.
  2. Consolidar en el sistema central durante la vigencia del contrato toda la información transaccional del proyecto en el servidor local o nube que Metrobús determine. Metrobús suministrará la información de la estructura de la base de datos transaccional de los servidores espejo que permita el proceso de consolidación. “LA EMPRESA” debe recolectar la información, procesarla y ordenarla en la base de datos de acuerdo con los requerimientos que proporcione Metrobús. La actualización de información debe hacerse con un desfase no mayor a 24 horas.

 

 

6.5 Canales de comunicación

6.5.1        Descripción general

“LA EMPRESA” debe estar preparada para:

 

  1. Implementar un servicio de comunicación de datos a través de ADSL, 4G, 5G, o alguna otra opción que la empresa proponga, la cual debe estar en cada autobús y terminal de la Línea 6 y 7 del Sistema Metrobús que permita la comunicación segura entre:
  2. los dispositivos del Sistema de Peaje y Control de Acceso y el sistema central para transmitir de manera segura y confiable todos los datos de ventas, validaciones y demás operaciones realizadas por estos, e intercambiar información;
  3. el NVR y software de gestión de videovigilancia para transmitir de manera segura y confiable los videos, e intercambiar información;
  4. Implementar un servicio de WiFi al que se pueda acceder, , solo a personal autorizado, desde cualquier punto físico de la estación o terminal. Para esto, “LA EMPRESA” debe suministrar los puntos de acceso inalámbricos necesarios para la comunicación de las Terminales Móviles de Supervisión, definiéndolo cuando menos en las estaciones donde hay un Centro de Atención a Usuarios.
  5. Implementar un servicio de conexión móvil 3G o superior para garantizar la conectividad de los terminales móviles para supervisión en caso de que se presenten fallas en la red WiFi.
  6. Implementar una conexión entre los puestos de trabajo de “LA EMPRESA” y el sistema central.
  7. Implementar una conexión entre los puestos de trabajo de Metrobús y el sistema central.
  8. Implementar una conexión entre los puestos de trabajo de Metrobús y el sistema de videovigilancia en estaciones y terminales.
  9. Implementar una conexión de integración con el sistema central y los servidores espejo que designe Metrobús.
  10. Verificar el estado del cableado estructurado que comunica los dispositivos instalados en las estaciones y terminales con los cuartos para servicios de peaje. “LA EMPRESA” es responsable de realizar las modificaciones necesarias que se requieran para garantizar esta conexión. El cableado actual de L6 y L7, pertenece a Metrobús.
  11. Suministrar e instalar todos los equipos complementarios que sean necesarios para garantizar las comunicaciones en la terminal o estación.

 

 

6.5.2        Especificación técnica

“LA EMPRESA” debe garantizar que:

  1. El ancho de banda para las comunicaciones, lo debe de dimensionar “LA EMPRESA” puede aumentar la capacidad si fuera necesario dependiendo de las características de cada terminal o estación.
  2. En caso de la opción ADSL, las bandas de la red WiFi serán de 2,4GHz y 5GHz.
  3. En caso de que las comunicaciones sean a partir de 4G o superior, deberán establecer el protocolo para comunicar los equipos con el sistema central.
  4. Todo el cableado estructurado satisfaga la norma ISO/IEC 14763-1 o la norma EN 50174-1 y se lleve en concordancia con el estándar ANSI/EIA/TIA-568A y ANSI/EIA/TIA- 568B.
  5. El alcance del proyecto conlleva como uno de los puntos preferentes a evaluar el uso de la fibra óptica, de acuerdo a lo siguiente:
  6. Tramitar los permisos necesarios solicitados por las alcaldías relevantes.
  7. Hacer un diseño de los soportes que van a sostener los cables de fibra óptica y validar que cumplen estructuralmente con las cargas teóricas sin dejar una catenaria muy pronunciada.
  8. Validar que los cables de fibra óptica al ser instalados cumplen con las distancias reglamentarias con las redes eléctricas de alta tensión.
  9. Evitar curvas muy pronunciadas que puedan generar altas atenuaciones y lo puedan romper, pues el cable de fibra óptica es muy delicado.
  10. Mantener alejados los cables de fibra óptica de árboles. Estos al caer los pueden dañar.
  11. Instalar cable de fibra óptica con coraza protectora de roedores en zonas donde hay alta presencia de roedores.
  12. Instalar amortiguadores de vibración para evitar el deterioro del cable en zonas de alto viento y con vanos superiores a 200 metros.
  13. Implementar un plan de manejo vial a fin de que los contratistas y sus cuadrillas den estricto cumplimiento al mismo para minimizar los impactos y riesgos que se puedan generar durante la ejecución de obras en el espacio público.
  14. Realizar los empalmes de fibra óptica con equipos de fusión con alineación de núcleo, los cuales deben estar debidamente calibrados. Los empalmes por fusión consisten básicamente en el corte, enfrentamiento, fusión mediante arco eléctrico y reconstrucción posterior de los extremos de las fibras del cable con pitillos termoencogibles, permitiendo uniones de excelente calidad y muy baja atenuación.
  15. Realizar pruebas bidireccionales con OTDR (Optical Time Domain Reflectometer) y power meter al final del montaje de la fibra óptica. La atenuación debe ser menor que la atenuación teórica total. En las pruebas de OTDR siempre se debe usar una bobina de lanzamiento.

7.  Alcance para pago con código de barras 2D

 

“LA EMPRESA” debe implementar la solución para la lectura y procesamiento de códigos de barras 2D (en adelante, “la solución”). Para esto debe realizar los desarrollos y actualizaciones correspondientes en las TVMC, los validadores, aplicación móvil y sistema central.

 

7.1 TVMC y TVML

 

“LA EMPRESA” debe actualizar las TVMC para incorporar la funcionalidad de generación de códigos de barras 2D en estos dispositivos, de manera que estos puedan llevar a cabo las siguientes funciones:

 

  1. Emitir la opción de compra para acceder al sistema a través de códigos de barras 2D.
  2. Generar códigos de barras 2D los cuales deben de ser únicos para leerse en los validadores de la estación donde las TVMC brinden el servicio.
  3. Los códigos de barras 2D generados a través de las TVMC, caducarán después de 15 minutos de haberse generado, y no podrán volver a ser usados. Dicho tiempo debe de ser parametrizable.
  4. Capacidad de imprimir códigos de barras 2D para poder ser leídos en los validadores de la estación donde las TVMC brinden el servicio.
  5. Implementar los protocolos de comunicación para la transmisión de los datos, utilizar las tramas de datos que deben intercambiarse con el sistema central y aplicar los mecanismos de seguridad propuestos para la transmisión de estos datos en “la solución”.

 

7.2  Validadores

 

“LA EMPRESA” debe actualizar los validadores para incorporar la funcionalidad de aceptación de códigos de barras 2D en estos dispositivos, de manera que estos puedan llevar a cabo las siguientes funciones:

 

  1. Leer, procesar y validar códigos de barras 2D dinámicos y visualizados por una aplicación móvil desde cualquier teléfono móvil, y permitir o denegar el acceso a la estación según los resultados de la validación.
  2. Utilizar el modo de codificación y decodificación de datos definido en “la solución” siguiendo la norma IEC/ISO correspondiente al tipo de código de barras 2D seleccionado.
  3. Aplicar los mecanismos de seguridad definidos en “la solución” para garantizar la confidencialidad e integridad de los datos intercambiados en una transacción entre el medio de pago y el validador.
  4. Interactuar con niveles superiores de conformidad con las especificaciones de “la solución”. Esto implica implementar los protocolos de comunicación para la transmisión de los datos, utilizar las tramas de datos que deben intercambiarse con el sistema central y aplicar los mecanismos de seguridad propuestos para la transmisión de estos datos en “la solución”.

 

Además, en caso de que Metrobús lo solicite, “LA EMPRESA” debe actualizar la API para interacción con medios de pago, de acuerdo con las especificaciones de “la solución”, y entregar versiones actualizadas del código fuente con su documentación, el manual de usuario y la documentación técnica correspondiente. Es deseable que puedan desarrollar los aplicativos por medio de Eclipse Keyple™, el cual es una API de código abierto para la integración y el desarrollo de aplicaciones de peaje, permitiendo que los desarrollos implementados por operadores o integradores se basen en una base homologada, a través de un conjunto de librerías de código abierto implementadas inicialmente en Java y C++, compatibles con cualquier arquitectura de terminales, sea móvil, embebida o distribuida, e interoperables con cualquier lector de tarjetas inteligentes: propietario, estándar, local o remoto.

 

7.3 Sistema central

 

“LA EMPRESA” debe realizar actualizaciones en el sistema central para lograr:

 

  1. Recibir, procesar y almacenar las distintas transacciones generadas por el pago con códigos de barras 2D en el sistema de peaje, de acuerdo con los requerimientos de “la solución”.
  2. Llevar a cabo la interacción entre la aplicación móvil y el sistema central para el procesamiento de transacciones, mediante la interfaz definida en “la solución”.
  3. Llevar a cabo la interacción entre el sistema central y el sistema central del Sistema Integrado de Transporte de la Ciudad de México, en caso de que esta interfaz se encuentre especificada y Metrobús lo solicite.

 

 

8.   Alcance para pago con medios de pago EMV sin contacto

 

“LA EMPRESA” debe implementar, desde el inicio del contrato la solución para la lectura y procesamiento de medios de pago EMV (en adelante, “la solución”), la cual deberá conectarse a la Pasarela que METROBÚS disponga para el procesamiento de los pagos bancarios. Para esto, debe realizar los desarrollos y actualizaciones correspondientes en los validadores, terminales móviles para supervisión y el sistema central. Además, debe:

  1. En el momento en que Metrobús lo solicite, participar con el adquirente que este indique en las pruebas requeridas para lograr las certificaciones EMV de nivel 3 correspondientes a cada bandera de pago aceptada, de conformidad con “la solución”.
  2. Implementar “la solución” teniendo en cuenta los requisitos, recomendaciones y estándares establecidos en las guías de implementación para tránsito elaboradas por cada bandera de pago aceptada en “la solución”.

 

8.1 Validadores

 

“LA EMPRESA” debe actualizar los validadores para incorporar la funcionalidad de aceptación de medios de pago EMV sin contacto en estos dispositivos para la integración a la Pasarela de Pagos que METROBÚS disponga, de manera que estos puedan llevar a cabo las siguientes funciones:

 

  1. Leer los medios de pago EMV sin contacto y procesar las transacciones de pago correspondientes, de conformidad con “la solución”:
  • Hacer los procesos de verificación especificados por las especificaciones EMV de acuerdo con el modelo MTT,
  • Utilizar los parámetros de verificación suministrados por la Pasarela de pagos,
  • Encriptar, antes de cualquier transmisión fuera del lector, los datos confidenciales de la tarjeta con algoritmo y llaves compartidos con la Pasarela de pago,
  • Tener un mecanismo de tokenización en lo cual se genera, antes de cualquier transmisión fuera del lector, un token único irreversible con algoritmo y llaves interoperables que compartirá el proveedor de la Pasarela de pagos,
  1. Interactuar con el sistema central mediante la interfaz definida en “la solución”.
  • Implementar la interfaz (API) que entregará el proveedor de la Pasarela de pagos al inicio del proyecto,
  • Solicitar a la Pasarela de pagos los parámetros bancarios (lista de Bines, llaves públicas EMV, etc.) después del inicio del validador,
  • Después de otorgar el pase, mandar las validaciones bancarias en tiempo real a la Pasarela de pagos para su autorización,
  • Mandar mensajes de vida periódicos a la Pasarela de pagos,
  • Solicitar al máximo cada 15 minutos las actualizaciones de la lista de rechazo de tokens,
  1. Interactuar con otros actores, en caso de ser necesario, de acuerdo con las especificaciones de “la solución”.
  2. Implementar el proceso de integrar tarjetas EMV en listas de rechazo, así como sacar las tarjetas de este tipo de listas:
  • Estas actualizaciones de listas de rechazo de tokens se harán mediante la implementación de la interfaz (API) con la Pasarela de pagos,
  • Las transacciones rechazadas por el validador se deben mandar a la Pasarela de pagos.
  1. Tener mecanismos seguros de gestión de las llaves compartidas con la Pasarela de pagos:
  • Firmar los acuerdos de confidencialidad y de responsabilidad con el proveedor de la Pasarela de pagos.
  • Participar a las debidas ceremonias de llaves organizadas por el proveedor de la Pasarela de pagos, tanto para llaves de encriptación de datos EMV como de tokenización,
  • Utilizar el esquema de gestión de claves DUKPT (Derived Unique Key Per Transaction) para la encriptación de los datos bancarios confidenciales,
  1. Participar con el Proveedor de la Pasarela de pagos y el Adquirente a la certificación de Nivel 3 de la solución completa.

 

8.2 Sistema central

 

“LA EMPRESA” debe actualizar el sistema central para permitir la aceptación de medios de pagos EMV sin contacto en el Sistema de Peaje y Control de Acceso. Para esto debe implementar:

 

“LA EMPRESA” debe realizar actualizaciones en el sistema central para lograr:

  1. Almacenar y procesar transacciones de pago con medios de pago EMV sin contacto, de conformidad con “la solución”. Para este, la Pasarela de pagos transmitirá de manera diaria las validaciones procesadas.
  2. Llevar a cabo la interacción entre el sistema central y el sistema central del Sistema Integrado de Transporte de la Ciudad de México, en caso de que esta interfaz se encuentre especificada y Metrobús lo solicite.

9.   Recaudo y depósito del dinero

9.1 Recolección de valores y depósitos

 

  1. Para la Línea 6 y 7 del Sistema Metrobús, a partir de la firma del acta de inicio de la operación de línea, “LA EMPRESA” es la única responsable de los recursos desde el ingreso en los dispositivos de venta y recarga de la línea hasta el depósito final en la cuenta del Fideicomiso que se le indique. Cualquier eventualidad que se presente en el transcurso correrá a cuenta de “LA EMPRESA”. Esta obligación es indelegable y no negociable.
  2. “LA EMPRESA” debe realizar la recolección diaria y sin excepción de los recursos captados a través de los dispositivos de venta y recarga de la Línea 6 y 7 del Sistema Metrobús, a partir de la firma del acta de inicio de la operación de cada línea.
  3. “LA EMPRESA” debe tener el equipamiento de re-cambio para que se realice sin excepción la recolección de los valores en la Línea 6 y 7 del Sistema Metrobús.

 

9.2 Depósitos al Fideicomiso

 

  1. Los montos recolectados por “LA EMPRESA” en la Línea 6 y 7 del Sistema Metrobús deben ser depositados en su totalidad al día siguiente hábil de haber realizado la recolección.
  2. Se entiende como depósito o transferencia electrónica el hecho de hacer entrega de los recursos recolectados a la cuenta del Fideicomiso que el mismo indique.
  3. Así mismo “LA EMPRESA” debe realizar las gestiones necesarias para que el efectivo recolectado en la Línea 6 y 7 del Sistema Metrobús sea depositado y caiga en firme en la cuenta del Fideicomiso, en el entendido de que será obligación de “LA EMPRESA” formalizar la contratación del servicio que proceda a fin de que el efectivo recolectado sea efectivamente depositado en cada una de las subcuentas del Fideicomiso 6628 de los corredores en cuestión. Por lo tanto, las comisiones y otros gastos que este aspecto originen serán por cuenta y cargo de “LA EMPRESA”. Esto en virtud de que la Institución bancaria (es decir el Fiduciario) ante el cual se constituyó este Fideicomiso no cuenta con el servicio de recepción de efectivo, por lo que únicamente recepciona los recursos del peaje a través de transferencias bancarias.
  4. En el supuesto a que se refiere la cláusula tercera, inciso f, párrafo quinto, del CONTRATO, es decir, cuando por fallas a los equipos los usuarios solo puedan acceder a las estaciones o terminales implicadas a través de la garita sin pago alguno, Metrobús realizará el cálculo de la cantidad que se dejó de percibir por este tipo de eventualidades y “LA EMPRESA” acepta y se obliga a depositar dichas cantidades en la subcuenta del fideicomiso según la estación y/o terminal en la cual se suscita dicha eventualidad.

 

9.3 Recaudo de dinero por canales digitales (Códigos de barra 2D, Tarjeta bancaria y EMV sin contacto).

 

  1. A partir de la firma del acta de inicio de la operación de la primera línea de “LOS CORREDORES”, “LA EMPRESA” es la única responsable de los recursos desde el ingreso en los canales digitales hasta el depósito final en la cuenta del Fideicomiso que se le indique. Cualquier eventualidad que se presente en el transcurso correrá a cuenta de “LA EMPRESA”. Esta obligación es indelegable y no negociable.
  2. Los montos recaudados por canales digitales no deberán ser depositados directamente en la cuenta del Fideicomiso.
  3. Los montos recaudados por canales digitales deben ser depositados en su totalidad al día siguiente hábil de haber realizado el recaudo, después de que “LA EMPRESA” ha hecho una conciliación entre los datos transaccionales y los valores recaudados.
sección previa siguiente sección
Descargar proyecto

Disponible en formato PDF

Pregunta
21 de October 2022 09:25
Visto
ALMA LETICIA
"Garantizar la existencia de servidores de respaldo donde se pueda redireccionar la información en caso de que los servidores principales fallen. Estos servidores se requiere que se cumpla la regla del 3-2-1 para las copias de seguridad, la cual debe de considerar realizar 3 copias de los datos del organismo en 2 soportes diferentes y alojar la tercera copia en 1 lugar físico distinto."

Hay mecanismos de replicación de datos que ofrecen los motores de base de datos de los principales proveedores tecnológicos a nivel mundial que permiten contar con más de una copia de la BD actualizada al momento y que pueden tomar, en un momento dado, la funcionalidad de la BD principal o maestra. ¿Aceptaría Metrobús aprovechar mejor un mecanismo como este en un servidor Espejo y un esquema de respaldos tipo completo en fin de semana y diferencial diario, como opción en lugar de usar respaldos como el mecanismo 3-2-1?

0
Pregunta
21 de October 2022 09:23
Visto
ALMA LETICIA
"Monitoreo de transacciones para detección de fraude: permite supervisar el uso de las Tarjetas de Movilidad Integrada y realizar acciones de mitigación de fraude."

La distribución de las listas negras y listas blancas de tarjetas y SAM (recibidas desde Metrobús) por el sistema central de la empresa hacia los validadores, TVMC y TVML, para su aplicación en cada interacción en estos equipos, son consideradas por Metrobús como acciones de mitigación de fraude?

0
Pregunta
21 de October 2022 09:22
Visto
ALMA LETICIA
"Monitoreo de transacciones para detección de fraude: permite supervisar el uso de las Tarjetas de Movilidad Integrada y realizar acciones de mitigación de fraude."

En caso de que se decida dejar a la empresa parte de este trabajo de detección de fraude, ¿puede Metrobús compartir las reglas e instrucciones que deben de ejecutarse en este software de monitoreo de transacciones que debe implementar la empresa?

0
Pregunta
21 de October 2022 09:21
Visto
ALMA LETICIA
"Monitoreo de transacciones para detección de fraude: permite supervisar el uso de las Tarjetas de Movilidad Integrada y realizar acciones de mitigación de fraude."

Considerando que hay un sistema central de información (Nivel 4) de Metrobús que concentra toda la operación y transacciones de todas las líneas, se infiere que es el nivel o capa donde pueden determinarse si hay brincos en folios de SAM, saldos no justificados, etc. ¿No debería ser en ese Nivel 4 donde debe de realizarse el monitoreo de transacciones y supervisión para detección del fraude, con lo que esta actividad queda fuera del alcance de la empresa?

0
Pregunta
21 de October 2022 09:19
Visto
ALMA LETICIA
"Código de barras 2D: permite el pago de la tarifa para acceder a los servicios del Sistema Metrobús a través de códigos de barras 2D que son generados por una aplicación móvil instalada en dispositivos móviles inteligentes o que son generados en la TVMC y TVML a través de la impresión en un ticket."

¿Puede Metrobús indicar qué mecanismo propone para evitar el uso fraudulento de códigos QR generados en app móviles o impresos, para evitar sean usados simultáneamente en diferentes dispositivos en estaciones o a bordo, considerando la facilidad de que sean capturados en pantalla, fotografiados y compartiros de manera instantánea?

0
Pregunta
21 de October 2022 09:19
Visto
ALMA LETICIA
"Código de barras 2D: permite el pago de la tarifa para acceder a los servicios del Sistema Metrobús a través de códigos de barras 2D que son generados por una aplicación móvil instalada en dispositivos móviles inteligentes o que son generados en la TVMC y TVML a través de la impresión en un ticket."

¿Puede Metrobús indicar qué mecanismo propone para evitar el uso fraudulento de códigos QR generados en app móviles o impresos, para evitar sean usados simultáneamente en diferentes dispositivos en estaciones o a bordo, considerando la facilidad de que sean capturados en pantalla, fotografiados y compartiros de manera instantánea?

0
Pregunta
21 de October 2022 09:01
Visto
ALMA LETICIA
"Servidores espejo:"

Se indica que "Servidores espejo: son servidores que almacenan una copia de la información transaccional de las Líneas 1, 2, 3, 4 y 5 del Sistema Metrobús." ¿Podrían aclararnos que interacción habrá con estos servidores espejo de las demás líneas por parte del sistema central de L6 y L7?

0
Pregunta
21 de October 2022 08:59
Visto
ALMA LETICIA
"Servidores espejo"

Se indica que "Servidores espejo: son servidores que almacenan una copia de la información transaccional de las Líneas 1, 2, 3, 4 y 5 del Sistema Metrobús." ¿Podrían aclararnos quién sumistra estos servidores espejos y qué responsabilidad tiene la empresa con ellos?

0
Pregunta
21 de October 2022 08:58
Visto
ALMA LETICIA
"Sistema central hospedado en la nube o sistema central:"

Indican que "el Sistema Central hospedado en la nube"; ¿Puede Metrobús confirmar si está considerando se ofrezca un solo servidor central para ambas líneas L6 y L7?

0