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
4
9
274
0
Proyecto de contratación
El proyecto de contratación aquí presentado es preliminar. Su contenido no es definitivo ni vinculatorio.
Este proyecto se hace de conocimiento público con el fin de ser discutido de forma abierta y transparente.
Selecciona la sección que deseas consultar
Disponible en formato PDF
¿La Geolocalicacion debe considerarse dentro de la solución de Recaudo o se refiere solamente a la integración con el Centro de Control para el aviso a los usuarios?
¿O solo implica la identificación de las transacciones de validación a bordo de los autobuses?
¿Implica instalación de GPS como equipo adicional?
¿Puede confirmar Metrobús que el único código fuente que entregará la empresa es del componente API y que es la API el único componente de software que desarrolla y entrega la empresa del cual Metrobús conserva la propiedad intelectual?
En el anexo 4 se hace diferenciación de la API, como un módulo o subsistema propio y universal, del resto del software o código de los equipos donde se incluye (validadores de todos los equipos donde se puede interactuar con la tarjeta). ¿Es válido suponer que el único código que está solicitando Metrobús se entregue es el de la API?
Pregunta para toda la sección
¿Las estaciones de ambas líneas cuentan con la ducteria para recibir fibra óptica?
Respecto a los canales de comunicación, ¿Puede Metrobús confirmar si se cuenta con infraestructura parcial o total de fibra óptica (iluminada y con sus equipos activos) en las estaciones y terminales que pueda aprovechar?
Se indica "Requerimientos de información mínima disponible - “LA EMPRESA” debe garantizar la disponibilidad y el acceso como mínimo a la siguiente
información:" y se listan los mínimos para validaciones, ventas, colectas, tarjetas e historial de tarjetas. ¿Aceptaría Metrobús la propuesta de que se entregue un Servidor Espejo (que se refresque por evento), para que cuente Metrobús con un acceso permanente a toda la información (más allá de la mínima listada) de manera que el volumen de operación, alta transaccionalidad o posibles tiempos elevados de consulta que se presenten en el servidor principal por la consolidación de mantenimiento?
Actualmente los proveedores líderes en la nube a nivel mundial (Amazon, Azure, Google Cloud) se rigen po estándares propios no homologados como TIER del Uptime Institute, pero que exceden los criterios tradicionales de datacenters privados y por supuesto los del Uptime Institute y que cumplen con estándares como CSA STAR, ISO/IEC 27001:2013 y NISTP SP 800-53, por mencionar algunos. ¿Acepta Metrobús la posibilidad de ofrecer hosting profesional en la nube con estos proveedores líderes como Amazon, Microsoft Azure y Google Cloud?
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?
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?