anexo vi - especificaciones del centro de contro · sistema de conteo automático de pasajeros ......

INFORME FINAL ANEXO VI - Página 1

ESPECIFICACIONES TÉCNICAS DEL

SISTEMA DE CENTRO DE CONTROL


ÍNDICE Abreviaciones y siglas: ...................................................................................................5

1. Introducción.................................................................................................................6

1.1. Arquitectura del Sistema ....................................................................................6

1.1.1 Coordinación con Otras Contrataciones ....................................................8

2. Requerimientos Funcionales del Sistema de Centro de Control..........................9

2.1. Descripción del sistema.......................................................................................9

2.1.1. Requisitos generales.................................................................................10 2.1.2. Localización Automática de Vehículos (LAV) .......................................11

2.2. Sistema de Programación de Itinerarios.........................................................13

2.3. Sistema de Control Central...............................................................................15

2.3.1. Principales Funciones del Sistema de Control...............................................16

2.4. Sistema de Reporte ............................................................................................20

2.4.1. Requerimientos de Acceso de Datos a Protransporte ..............................21

2.5. Opciones de Comunicación..............................................................................22

2.5.1. Descripción de las Comunicaciones en la Línea Troncal de Vehículos ..22 2.5.2. Descripción de las Comunicaciones para las Líneas de Vehículos de Alimentación............................................................................................................23 2.5.3. Opciones de Comunicación .....................................................................24

2.6. Sistema de los Vehículos de la Línea Troncal ................................................24

2.6.1. Registro de Ingreso y Salida del Conductor del Vehículo:............................24 2.6.2. Mensajes de Datos: ........................................................................................24 2.6.3. Alarma de Emergencia:..................................................................................24 2.6.4. Posición del Vehículo y Reporte de Estatus: .................................................25 2.6.5. Seguimiento del Odómetro del Vehículo:......................................................25 2.6.6. Alarmas Mecánicas:.......................................................................................25 2.6.7. Administración de la Comunicación:.............................................................25 2.6.8. Almacenamiento y Recuperación de la Información:....................................25 2.6.9. Interfaz del Conductor: ..................................................................................26

2.7. Sistema de los Vehículos de las Líneas Alimentadoras................................26

2.7.1. Radio Móvil ...................................................................................................26 2.7.2. Equipo Emisor – Receptor de Identificación de los Vehículos .....................26 2.7.3. Sistema de Conteo Automático de Pasajeros.................................................27

2.8. Equipo de Ruta...................................................................................................27

2.8.1. Equipo Emisor – Receptor de Identificación de la Ruta (Baliza)..................28 2.8.2. Comunicaciones.............................................................................................28

2.9. Soporte y servicios ........................................................................................28


2.10 Servicios de Soporte Técnico .......................................................................28

2.10.1. Alcance de trabajo........................................................................................29 2.10.2. Requerimientos. ...........................................................................................30

2.11. Recuperación ante Desastres Naturales........................................................37

2.11.1. Plan de Recuperación de Desastres Naturales .............................................38 2.11.2. Centro de Recuperación de Desastres Naturales .........................................39 2.11.3. Manteniendo los Sistemas de Recuperación de Desastres Naturales y Procedimientos en un Estado de Alerta ...................................................................39 2.11.4. Implementación del Plan de Recuperación de Desastres Naturales ............40

2.12. Seguridad de Documentación del Software.................................................40

2.13. Servicio de Administración de Activos de SCC ..........................................40

2.13.1. Inventario Central de Equipo ......................................................................41 2.13.2. Servicios de Administración de Software...................................................41

2.14. Administración del Sistema Central de SCC ...............................................42

2.14.1 Servicios Misceláneos...................................................................................42 2.14.2. Plan de Sucesión ..........................................................................................42

3. Requerimientos de Desempeño ..............................................................................44

3.1. Disponibilidad....................................................................................................44

3.2. Requerimientos de Desempeño del Sistema de Centro de Control ...........45

3.2.1. Programación de Itinerarios de Operación ....................................................45 3.2.2. Control de Operaciones..................................................................................47 3.2.3. Reporte de Operaciones .................................................................................49

3.3. Requerimientos de Hardware..........................................................................53

3.3.1. Equipos de Lugar Fijo....................................................................................53 3.3.2. Equipos Móviles y de la Ruta ........................................................................55

3.4. Requerimientos de Software y Plataformas Preferidas................................58

3.5. Requerimientos de Desempeño de Servicios.................................................60

3.5.1. Niveles de Servicio del Sistema Central ........................................................60 3.5.2. Requerimientos de Precisión del Sistema Central .........................................61 3.5.3. Niveles de Servicio de Administración de Soporte Técnico .........................61

4. Requerimientos de implementación del sistema.................................................63

4.1. Plan Maestro de Implementación....................................................................64

4.1.1. Alcance del Plan Maestro ..............................................................................64 4.1.2. Revisiones ......................................................................................................65 4.1.3. Plan de Implementación.................................................................................65 4.1.4. Desarrollo de Requerimientos Detallados de Implementación para Operadores de Flota Detallados ...............................................................................65 4.1.5. Instalación del Sistema ..................................................................................66

4.2. Control de Diseño y Configuración ................................................................66


4.2.1. Revisiones de Diseño.....................................................................................66

4.3. Pruebas y Aceptación ........................................................................................70

4.3.1. General ...........................................................................................................70 4.3.2. Planes de Prueba, Procedimientos y Facilidades ...........................................70 4.3.3. Inspección y Pruebas de Dispositivos............................................................71 4.3.4. Inspección y Pruebas de Interfaz e Integración .............................................77 4.3.5. Inspección y Pruebas de Instalación y Aceptación ........................................78

4.4. Administración de Programa, Progreso y Monitoreo de Desempeño.......82

4.4.1. Revisiones de Proyecto ..................................................................................82 4.4.2. Reporte de Status ...........................................................................................82 4.4.3. Reporte de Problemas ....................................................................................83

4.5. Capacitación........................................................................................................84

4.5.1. General ...........................................................................................................84 4.5.2. Programas de Capacitación............................................................................84

4.6. Manuales .............................................................................................................85

4.6.1. Requerimientos Generales .............................................................................85 4.6.2. Componentes Primarios del Sistema .......................................................85 4.6.3. Tipos de Manuales ...................................................................................85 4.6.4. Diseño y Formatos generales .........................................................................87

4.7. Lista de Requerimientos de Datos Contractuales (LRDC)...........................88


ABREVIACIONES Y SIGLAS: AAP: Aceptación Para Proceder

CAP: Contador Automático de Pasajeros

COSAC: Corredor Segregado de Alta Capacidad

DAC: Despacho Asistido por Computadora (del inglés “Computer Aided Dispatching - CAD”)

FAI: Fuente de Alimentación Ininterrumpible (del inglés “Uninterruptible Power Supply - UPS”)

ICPA: Inspección de Configuración de Primeros Artículos

ID: Identificación

LAV: Localización Automática de Vehículos (del inglés “Automatic Vehicle Location - AVL”)

LRDC: Lista de Requerimientos de Datos Contractuales (del inglés “Contract Data Requirements List – CDRL”)

PPA: Prueba de Primeros Artículos

PPH: Permiso Para Hablar (del inglés “Request To Talk - RTT”)

PTEF: Promedio de Transacciones Entre Fallas

PV: Punto de Venta (del inglés “Point of Sales - POS”)

PVE: Punto de Venta en Estación (del inglés “Station Point of Sales”)

RDF: Revisión de Diseño Final

RDP: Revisión de Diseño Preliminar

RF-ID: Identificación por Radiofrecuencia

SR: Sistema de Venta, Recarga y Validación de Medios de Acceso, también llamado de forma abreviada Sistema de Recaudo.

SCC: Sistema de Centro de Control

TEA: Tiempo Esperado de Arribo

TISC: Tarjeta Inteligente Sin Contacto

TMD: Terminal Móvil de Datos

TMEF: Tiempo Medio Entre Fallas


1. INTRODUCCIÓN

Esta sección introductoria identifica servicios y sistemas que el Proveedor del Centro de Control (en adelante el “Proveedor”) debe brindar a Protransporte como parte de la contratación del Sistema de Centro de Control (SCC). El Proveedor será el único responsable por el diseño, implementación, operación y mantenimiento del sistema que se provea para el COSAC.

Se definen a continuación las funciones de negocio y áreas de servicio bajo esta contratación, para el Sistema de Centro de Control (SCC):

Control de Operaciones • Administración de Itinerarios

• Manejo de Incidentes

• Despacho de Flota / Manejo de Demanda

• Enlace con los Operadores de Flota y Garajes

Itinerario de Operación • Optimización de las Operaciones de Flota

• Manejo de Demanda y Oferta

Reporte de Operaciones • Monitoreo

• Cumplimiento Contractual de la Flota

Sistema de Centro de Control (SCC)

• Cumplimiento Contractual de Operaciones

1.1. ARQUITECTURA DEL SISTEMA

La arquitectura general del sistema debe ser construida en base a dos subsistemas principales:

• Sistema de Control y Monitoreo • Sistema de Centro de Control

La Figura a continuación muestra una representación gráfica de la arquitectura sugerida para el Sistema de Centro de Control y la integración requerida con el Sistema de Recaudo (SR).


Figura 1: Arquitectura Conceptual del Sistema


1.1.1 COORDINACIÓN CON OTRAS CONTRATACIONES Existen otras Contrataciones planeadas para la implementación del COSAC. Las siguientes Contrataciones se encuentran en progreso:

a) Sistema de Venta, Recarga y Validación de Medios de Acceso (SR).

b) Vehículos y Servicios de Transporte Público por Operadores (“Operadores de Flota” u “Operadores”).

El Proveedor debe cooperar con Protransporte, el Concesionario del SR y los Operadores en el desarrollo de sus funciones. En particular, será responsable de coordinar la conformidad de los equipos del SCC, cuya adquisición y operación se encargue a otros Operadores.

La coordinación debe incluir, como mínimo, el brindar las especificaciones de interfaz; asegurar que el equipo seleccionado cumpla con las especificaciones y requerimientos de desempeño, seguridad, y auditoría del sistema cuando sean aplicables; atendiendo revisiones de diseño, y las pruebas de equipos requeridas; brindando el soporte de ingeniería en cada etapa del diseño de los componentes del SCC; y brindando acceso a las pruebas del SCC para certificación de equipos, como sea requerido.

Se puede requerir también que el Proveedor pueda proporcionar números de partes y proveedores para componentes específicos del SCC. Si se requiriera, el Proveedor debe proporcionar dicha información para el soporte de las contrataciones de Operadores.

Los protocolas de información del Sistema del Centro de Control deben ser compatibles con los protocolos de información del Sistema de Venta, Recaudo y Validación de medios de Acceso (SR).


2. REQUERIMIENTOS FUNCIONALES DEL SISTEMA DE CENTRO DE CONTROL

2.1. DESCRIPCIÓN DEL SISTEMA El Sistema de Centro de Control debe proporcionar las herramientas necesarias para la correcta organización y planificación del servicio tanto de la ruta troncal como de las rutas alimentadoras, segregando el servicio en grupos lógicos que puedan ser impartidos a los múltiples proveedores que operarán el servicio. Adicionalmente, el Sistema del Centro de Control debe ser capaz de monitorear el estado operacional de la flota de vehículos, comunicarse con los conductores a fin modificar el programa cuando este se encuentre fuera de los límites de tolerancias aceptadas, interactuar con los operadores cuando el aumento de la demanda de pasajeros requiera la implementación de servicios adicionales, y tener las herramientas necesarias para evaluar el desempeño de las flotas y ajustar de los itinerarios a las necesidades de los usuarios.

El desempeño de las flotas que operen en la línea troncal debe ser supervisado de acuerdo al cumplimiento los horarios implementados, del mantenimiento de la ruta y sentido de viaje, de las entradas y salidas atrasadas o adelantadas, de los efectos de algunas condiciones sobre el desempeño de los conductores, y otra información que se considere pertinente. El sistema DAC/LAV deberá cumplir los siguientes requerimientos de rutas e itinerarios:

§ La información sobre la posición de los vehículos debe ser transmitida periódicamente al Centro de Control de Flota (junto con otros datos relacionados) para facilitar una correcta administración y control de ajuste a los itinerarios y progreso de las rutas.

§ La operación de los buses en ruta será monitoreada de tal forma que el despachador pueda inmediatamente monitorear, prever, y aliviar aglomeraciones y otras anomalías en el servicio que puedan afectar el correcto desempeño operacional del sistema.

§ Se deberá proveer toda la información con respecto a las máximas desviaciones de itinerario permitidas, las desviaciones reales de cumplimiento del itinerario, y la desviación promedio para todos los vehículos que operen en una misma ruta o estén a cargo de un mismo operador.

§ En el futuro se puede requerir la función de información a los pasajeros en algunas estaciones clave. Esta información debe incluir, pero no limitarse a: rutas que lleven a y desde la(s) parada(s) seleccionada(s); arribos esperados


(programados) de vehículos en las paradas seleccionadas; y la distancia de los vehículos a las paradas seleccionadas, expresada en tiempo estimado de arribo (TEA).

Otras aplicaciones del DAC

El sistema de DAC /LAV proporcionará funcionalidad para mejorar la comunicación en las siguientes áreas:

§ Seguridad

§ Mensajería de Texto

§ Intercomunicación entre Despachadores

§ Disponibilidad vehicular

2.1.1. REQUISITOS GENERALES El Sistema de Control consta de diferentes sistemas funcionales, entre los que se incluyen:

• El Sistema de Programación de Itinerarios, que permite realizar la programación operativa del sistema de acuerdo con las condiciones de la demanda y los parámetros que defina Protransporte;

• El Sistema de Control de Despacho, que proporciona al sistema la habilidad para despachar conductores de cada concesionario de servicios de operación en el sistema;

• El Sistema de Administración de Flota, con ubicación automática de vehículo (LAV por sus siglas en inglés) que periódicamente recolecta información de la operación y proporciona al despachador un análisis del desempeño de la ruta;

• El Sistema de Comunicaciones por Radio (inalámbrico), que permite la transmisión de voz y datos;

• El Sistema de Reportes.

Cada uno de estos sistemas desempeña funciones específicas. El Sistema de Control administra y controla los otros sistemas a través de una red centralizada que consiste en interfaces y componentes específicos. A continuación están los requerimientos generales para el Sistema de Control:


§ El Sistema de Control debe ser un sistema basado en servidor central, siendo clientes del servidor cada una de las Estaciones de Despacho, de Programación y de Reporte.

§ El Sistema de Control debe informar a las estaciones de trabajo remotas sobre el desarrollo de ciertas funciones sólo para los Concesionarios, tales como la asignación de vehículos y asignación de conductores cuando sean necesarios los relevos.

§ El Sistema de Control DAC también debe de proporcionar una capacidad funcional de transmisión y recepción de datos en instalaciones seleccionadas de los Operadores de Flota, con el fin de proporcionar y controlar la transmisión y recepción de información desde los vehículos dentro de la proximidad inmediata de estas ubicaciones, por ejemplo descargar información de la programación de itinerarios para los vehículos dentro de los garajes.

§ El Sistema de Control DAC debe proporcionar Estaciones de Trabajo Administrativas en las oficinas de Protransporte. Dichas Estaciones deben proporcionar información administrativa y servicios relacionados al personal administrativo o de supervisión de Protransporte.

§ El Sistema de Control DAC también de proporcionar Estaciones de Trabajo para el monitoreo y manejo de las funciones de alarmas inherentes al sistema DAC y sus sistemas de radios conectados.

2.1.2. LOCALIZACIÓN AUTOMÁTICA DE VEHÍCULOS (LAV)

La presente sección trata sobre los requerimientos de Protransporte para la localización automática de los vehículos como una función del Sistema de Control DAC.

2.1.2.1. General

Un sistema LAV es un sistema de reporte de posicionamiento automático, usando una combinación de técnicas de posicionamiento por GPS, posiciones fijas predeterminadas y navegación inercial para obtener la ubicación de cada vehículo equipado con LAV dentro de un área de operación. Nótese que la estación Central subterránea inhibirá la localización si se utiliza sólo GPS. Sin embargo, siempre debe existir un medio de reportar la información de la ubicación obtenida por derivación (inercial) al Centro de Control, este medio debe de ser proporcionado por el sistema DAC/LAV. La información de la ubicación debe de ser etiquetada


junto con el número del vehículo, hora del reporte y cualquier otra información necesaria para la operación del vehículo.

El sistema de radio permite la conectividad y funcionalidad para intercambiar información desde los buses hasta los terminales del DAC localizados en el Centro de Control. El intercambio de datos provee de información necesaria para soportar la función específica del sistema LAV / DAC.

2.1.2.2. Funciones Administrativas del Sistema

Mediante el uso de las Estaciones de Trabajo Administrativas se posibilitará la administración responsable del sistema LAV / DAC. Entre las funcionalidades que presentan estas Estaciones se encuentran: monitoreo de rendimiento y desempeño del sistema, mantenimiento y mejoras de software, asignar y/o reasignar funciones entre los componentes del sistema LAV / DAC , y realización de cualquier otra función necesaria para mantener el sistema LAV / DAC en condición operacional.

Conceptualmente el Sistema de Control es un sistema basado en servidor, cuyas partes integrantes son: un Sistema de Programación de Itinerarios, un Sistema de Administración y Manejo de Información, que realiza funciones lógicas para las operaciones de tiempo real, y una Base de Datos para almacenar los datos operacionales. A continuación se presenta un diagrama de bloques de alto nivel del sistema.


Figura 2.1.2.2: Diagrama de Bloques del Sistema del Centro de Control

Information Manager

Data Repository

Dispatch Workstations



Central Server Software

Reporting Workstations Scheduling

System

Sistema de Administración de Información

Base de Datos

Software del Servidor Central

Sistema de Comunicaciones

Estación de Reporte

Sistema de Programación de Itinerarios

Estaciones de

Despacho

Estaciones de

Despacho

Estaciones de

Despacho

Estaciones de

Despacho

2.2. SISTEMA DE PROGRAMACIÓN DE ITINERARIOS

El sistema de programación debe tener la habilidad de proporcionar un diseño de rutas preciso para todo el servicio esperado. El sistema debe ser capaz de definir patrones múltiples para cada ruta, debe ser capaz de definir y geocodificar las paradas del bus, y tiene que plasmar gráficamente las rutas para que el programador de itinerarios tenga la capacidad de mostrar la información de la ruta en la forma de un mapa. El Sistema de Programación de Itinerarios debe ser capaz de definir los servicios del sistema incluyendo tiempos y paradas a lo largo de cada ruta, y el Sistema de Mapeo debe tener la habilidad de mostrar múltiples rutas en un solo mapa. El Sistema de Programación de Itinerarios debe ser aplicable a las líneas de servicio troncal así como a las rutas de servicio alimentador. El sistema debe de ser capaz de generar automáticamente la programación de rutas para el servicio planeado por un periodo de tiempo determinado, basado en una estructura de ruta establecida, requerimientos de desempeño y tiempo de partida desde un nodo (o punto) determinado.


El sistema debe ser capaz de elaborar un programa de itinerarios capaz de manejar diferentes requerimientos de desempeño para horas de demanda pico y horas valle, desde el comienzo del servicio del día hasta el final del mismo.

El sistema de programación debe ser capaz de ajustarse a los servicios en los días de semana, sábados, domingos y feriados. El sistema debe proporcionar la flexibilidad para poder efectuar modificaciones de los itinerarios programados, incluso después que los vehículos hayan salido de los garajes. Estas modificaciones pueden incluir cambios del estatus de los vehículos, como por ejemplo indicar que de acuerdo a la modificación del itinerario programado, cierto vehículo se encuentra ahora tantos minutos adelantado o retrasado.

Una vez que un itinerario ha sido establecido, el sistema debe tener la habilidad de generar manualmente o de preferencia automáticamente bloques de servicio, con tiempos, rutas y distancias de ingreso al servicio óptimo. Un bloque es definido como el programa de rutas e itinerario de un vehículo desde que este sale hasta que regresa del servicio. El ingreso al servicio es definido como un servicio no comercial desde el punto de salida del vehículo (garaje) hasta el momento que ingresa al servicio comercial (terminal o estación designada de inicio).

Una vez que el programa es dividido en bloques de programas, el Centro de Control agrupará estos bloques en paquetes de bloques para que cada proveedor de servicio (Operador de Flota) proporcione vehículos para operar en el servicio de cada día. Un paquete de programación de itinerarios semanal (se debe entregar a los Operadores de Flota con una semana de anticipación, todos los días Viernes a las 8 am, el Operador tendrá plazo hasta el día Miércoles, a las 8 am, de la semana siguiente a la entrega del paquete de programación de itinerarios para devolver al Centro de Control el paquete con la asignación de vehículos y conductores para cada ruta y servicio programados en el itinerario. El sistema debe tener un módulo para que cada proveedor ingrese el número de identificación del vehículo cada día, antes que el vehículo entre en servicio en el bloque al que esta asignado. Esta función proporciona al Centro de Control los mecanismos necesarios para monitorear a los vehículos de acuerdo al bloque asignado a cada uno.

También debe programarse en forma semestral las rutas que brindarán el servicio, si no existiesen cambios significativos antes de este plazo que afecten la operación del servicio (como por ejemplo la ampliación del servicio), estas rutas estarán diseñadas para maximizar los beneficios a los usuarios y a los Operadores de Flota.


2.3. SISTEMA DE CONTROL CENTRAL

Las características del sistema de control están dirigidas a: mejorar la puntualidad y la regularidad del servicio, la detección temprana de problemas en el servicio y una permanente mejora en la programación de itinerarios con la utilización de estadísticas que pueden ser usadas por los programadores.

El sistema de control debe proporcionar la coordinación y el monitoreo central de los vehículos que estén en operación en la línea troncal. El Sistema de Control debe estar en comunicación con cada vehículo vía el sistema de radio (como mínimo cada dos (2) minutos, si no ocurriese algún evento que inicie la comunicación antes de los dos (2) minutos) para obtener la ubicación actual y el cumplimiento del itinerario programado. El Sistema de Control luego procesará la información y ésta será distribuida a las Estaciones de Trabajo de Despacho relevantes, donde es mostrada en formas de presentación apropiadas, como son los diagramas de ruta y las secciones de información tabulares. El Sistema de Control también debe guardar la información de la flota en forma lógica para soportar los requerimientos del Sistema de Reportes.

El Sistema de Control debe recolectar información de los vehículos de las líneas alimentadoras usando un equipo transmisor - receptor de corto alcance y bajo costo, fijado a cada vehículo y que este en comunicación con otros dos equipos de transmisión – recepción, uno montado en la estación terminal de la línea troncal, y el otro en algún otro punto de la ruta alimentadora, como puede ser el punto de retorno de cada ruta al interior de la zona de alimentación. Un sistema de radio deberá ser instalado junto con cada equipo transmisor – receptor de la ruta, es decir en la estación terminal y en el otro punto de la ruta. El propósito de este sistema de radio es reportar al Centro de Control el ID del vehículo y el tiempo de cruce para cada vehículo que cruza el equipo transmisor - receptor, y guardar la información en la Base de Datos. Esta información será usada por el Sistema de Reportes para obtener los indicadores de desempeño por rutas de cada una de las líneas alimentadoras.


2.3.1. PRINCIPALES FUNCIONES DEL SISTEMA DE CONTROL

2.3.1.1. Control de comunicaciones:

El sistema debe proporcionar una función de Permiso Para Hablar (PPH) para que los conductores de los vehículos en la línea troncal puedan enviar un mensaje al Despachador requiriendo acceso a un canal de voz. A través del Sistema de Control, el despachador debe otorgar el acceso del conductor a la comunicación por voz. Adicionalmente, el Despachador debe de tener la capacidad de comunicarse individualmente con un vehículo, todos los vehículos de la ruta y todos lo vehículos en la flota.

2.3.1.2. Comunicaciones por Texto:

El sistema debe brindar a los despachadores la habilidad para enviar mensajes de texto, de hasta 240 caracteres, a un vehículo troncal en particular, todos los vehículos troncales en una ruta o todos los vehículos troncales en una flota. El mensaje debe ser enviado una vez, con indicación de direccionamiento al vehículo que es dirigido. El equipo embarcado a bordo de los vehículos troncales debe tener la habilidad de reconocer, si el mensajes está destinado a ese vehículo, basado en la información de rutas asignadas.

2.3.1.3. Sincronización de Tiempo:

El Sistema de Control debe servir de reloj maestro contra el que sincronizarán todas las estaciones de trabajo, equipos de los garajes, equipos de la ruta y los vehículos operando en el sistema de línea troncal. La máxima desviación temporal permisible es de 5 segundos respecto del reloj maestro.

2.3.1.4. Determinación de la Posición:

El equipamiento a bordo del vehículo troncal debe de tener la habilidad de determinar, de forma autónoma, su posición actual en relación con la ruta asignada al vehículo. La programación de itinerarios para los vehículos debe ser guardada en cada vehículo, y usando un GPS y otras herramientas de navegación, debe de ser capaz de determinar con precisión la ubicación actual, y si el vehículo esta dentro o fuera de la ruta, sentido de viaje y adelantado o retrasado respecto al itinerario programado.


2.3.1.5. Registro de ingreso/salida de los vehículos:

Se requiere un sistema de 2 pasos para el registro de ingreso y salida del vehículo al sistema. El primer paso es el registro de ingreso/salida del vehículo. El registro de ingreso de vehículo ocurre cuando el vehículo es encendido, momento en el que el sistema debe registrar el vehículo en el Sistema de Control y ser capaz de contactarse con el vehículo. El segundo paso es el registro de entrada del conductor. El conductor debe ser capaz de registrar su ingreso utilizando identificación de conductor y una identificación de bloque de ruta para registrar apropiadamente la asignación del vehículo en el Sistema de Control.

2.3.1.6. Mensajería:

En el caso de los vehículos troncales, el sistema de mensajes del vehículo debe incluir los mensajes iniciados por el conductor, y mensajes iniciados por el vehículo. Los mensajes iniciados por el conductor deben constar de una lista de tres (3) mensajes predeterminados que el conductor pueda seleccionar. Estos mensajes pueden ser usados para reportar condiciones que no pueden ser percibidas por el sistema embarcado en el vehículo. Los mensajes iniciados por el vehículo están diseñados para ser alarmas automáticas de indicadores críticos de desempeño del vehículo. El sistema debe estar conectado con los sensores del vehículo para percibir como mínimo: Temperatura del motor, nivel de aceite bajo, puertas abiertas o cerradas, sobrecarga (número máximo de pasajeros sobrepasado, calculado en base a pasajeros con peso promedio de 68 Kg.) y baja de presión de aire (nótese que se puede necesitar filtrado de estos datos y alarmas durante el arranque, durante el período en el que el sistema de freno de aire es cargado).

2.3.1.7. Requerimientos de Visualización del Despachador:

El monitor (pantalla) del despachador debe de tener capacidad de visualización con monitor dual que permita la visualización de múltiples ventanas, y configurable para permitir al despachador modificar el tamaño de cualquier ventana en el área de visualización.

Tres tipos de visualización deben de estar disponibles para el despachador. La primera es una visualización en forma tabular que proporcione identificación para eventos que sean originados por el conductor, por el vehículo o por el sistema, por ejemplo: un vehículo que este operando fuera de la tolerancia de itinerario predefinido. La segunda es una presentación gráfica de un mapa mostrando la localización actual y el estatus de cada vehículo y por último, una presentación del diagrama de ruta que es capaz de mostrar cada ruta en un formato de línea recta.


Visualizaciones tabulares múltiples deben estar disponibles para el despachador:

§ Visualización de eventos: Una visualización mostrando todos los eventos activos en el sistema. Esta es la visualización principal, a través de la que el despachador interactuará con el sistema. Cada evento debe de ser manejado por el despachador y documentado con una nota de que diga como fue resuelta la incidencia. Una vez que el evento haya sido resuelto será removido de la visualización del despachador.

Las siguientes presentaciones tabulares proporcionan al despachador características de desempeño de la flota presentes y pasadas (recientes), junto con otra información relevante para ser usada en decisiones operacionales:

§ Visualización de ruta: Una presentación que muestre los tiempos de recorrido planeados y reales para la ruta en el día de operación.

§ Visualización de bloque de ruta: Presentación que muestre los tiempos de recorrido planeados y reales de un programa de bloques seleccionado (visualización de un solo vehículo).

§ Disponibilidad de vehículos adicionales: Una visualización que muestra vehículos que están disponibles para servicio en cada concesionario, y visualización de conductores disponibles para servicio extra en cada concesionario.

Visualización gráfica de mapa:

La visualización gráfica de mapa debe de proporcionar un mapa de base geográfica mostrando todas las calles y los cruces de calles en los cuales el sistema este prestando servicio. La presentación también debe de ser capaz de mostrar la superposición de capas de rutas para cada ruta en el sistema. El despachador debe de tener la habilidad para adicionar o quitar individualmente cada una de las capas que forman el plano de ruta. Los vehículos deben de ser mostrados en sus ubicaciones actuales y codificados en color según su estatus, por ejemplo temprano con verde, a retraso con amarillo, adelanto con azul, emergencia con rojo, etc. Los íconos de vehículos se deben mover a su ubicación más reciente cada vez que su posición es actualizada por el sistema de LAV.


El despachador debe de tener la habilidad de mover y agrandar el mapa para tener la habilidad de ver ciertas áreas en detalle, como aglomeración en una estación. El zoom-out máximo debe de acoplarse al área de servicio, el máximo zoom-in debe de ser de 100 m.

El sistema DAC/LAV debe cumplir con los siguientes requerimientos funcionales y de capacidad de LAV para los vehículos troncales:

§ Localización de paradas de bus, garajes, terminales, puntos de regreso y puntos de transferencia.

§ Posición actual de cada vehículo y la información de cumplimiento del itinerario programado.

§ Dentro o fuera de la ruta.

§ El estado del itinerario programado para cada vehículo.

§ Progreso para cada vehículo.

§ Dirección de viaje de cada vehículo.

§ Estatus operacional para cada vehículo, por ejemplo alarmas mecánicas.

§ Visualización única para cada vehículo con una alarma de emergencia activada.

§ Visualización única de cualquier vehículo fuera de la ruta.

§ Método simple de visualización múltiple y simultánea del área de servicio, por ejemplo múltiples páginas de mapas.

El sistema DAC/LAV debe cumplir con los siguientes requerimientos funcionales y de capacidad de LAV para los vehículos alimentadores:

§ Localización de garajes, terminales y puntos de regreso.

§ Información de cumplimiento del itinerario programado por ruta, flota de Operador y vehículo particular.

§ Progreso para cada vehículo.

§ Método simple de visualización múltiple y simultánea del área de servicio, por ejemplo múltiples páginas de mapas.

Visualización del diagrama de ruta:

La visualización del diagrama de ruta debe de ser diseñada para mostrar cada ruta y dirección como una línea recta. Cada diagrama de ruta debe identificar y colocar cada estación en el punto apropiado del diagrama de tal manera que las distancias


entre las estaciones sean proporcionales en la visualización. El sistema debe tener ambas direcciones de la ruta si fuera aplicable a la ruta en un estilo escalonado. El sistema debe mostrar la localización actual de cada vehículo en la ruta y también identificar en el escalonamiento la ubicación en que el vehículo debería de estar si estuviera dentro del itinerario. Los iconos de vehículo deberían estar codificados en color para identificar si encuentran a tiempo, tarde, adelante o más allá de un umbral predefinido del sistema

2.4. SISTEMA DE REPORTE El sistema debe contar con capacidad para reporte de desempeño de la flota, para asegurar el desempeño de la flota contra el programa planeado, y para asegurar el cumplimiento de contrato por parte de los operadores que proveen servicio para las programaciones. Es importante que las herramientas de reporte usadas se apeguen al itinerario de servicio programado, de tal manera el desempeño de cada vehículo pueda ser claramente comparado contra el programa planeado con el que se debiera estar cumpliendo.

El Sistema de Conteo Automático de Pasajeros (CAP), instalado en los vehículos alimentadores, deberá tener integración con el Sistema de Reportes del Centro de Control, con fines de comparación. Si bien no se espera que los sistemas provean una información exacta, si se contará con la habilidad de identificar anomalías y tendencias.

De igual manera, el Sistema de Reporte debe tener acceso a información del Sistema de Recaudo (SR) respecto de los ingresos y salidas de los pasajeros del sistema relacionados a las estaciones y terminales, así como también las horas en que ocurren los ingresos y salidas. Esta información permitirá al Sistema del Centro de Control (SCC) calcular datos operacionales como son el Índice de Pasajeros por Kilómetro (IPK) y el Índice de Ocupación, entre otros. Éstos índices son de gran importancia ya que es deber del SCC realizar una programación que optimice beneficios para los pasajeros y los Operadores de Flota.

Las estaciones de reporte deben de ser capaces como mínimo de crear reportes para mostrar:

§ Km actuales en operación en cada línea troncal: Reporte detallado de la distancia comercial y no comercial acumulada en los viajes para la línea


troncal, adicionalmente, la habilidad de agrupar la distancia por concesionario, y por vehículo.

§ Número de viajes en cada línea alimentadora: Número acumulado de viajes en cada línea alimentadora por día, adicionalmente la habilidad del agrupar los viajes por concesionario y por vehículo.

§ Número de viajes por día y por vehículos: Tanto para líneas troncal y alimentadora, el número de viajes por día y por vehículo, para cada concesionario y comparable con la programación de cada concesionario.

§ Número de viajes por ruta y por día: Número acumulado de viajes comparado con el número de viajes programados para cada concesionario.

§ Número de viajes por operador: Viajes acumulados diarios por cada operador.

§ Número de eventos: Cantidad acumulada y tipo de cada evento para un día de servicio.

§ Número de eventos por operador: Cantidad acumulada y tipo de cada evento para un día de servicio, detallado por cada operador.

§ Número de eventos por despachador: Cantidad acumulada y tipo de cada evento para un día de servicio, detallado por evento de cada despachador.

§ Estadísticas del Sistema de Comunicación: Número de transmisiones exitosas vs. no exitosas.

§ Comparación de los datos del CAP con los datos de Recaudo: Para cada vehículo alimentador.

§ Análisis de pasajeros: Por cada ruta alimentadora y troncal, el número de pasajeros que suben y bajan en cada estación o vehículo asociado a un determinado horario de servicio.

§ Índice de Pasajeros por Kilómetro (IPK): Por cada ruta alimentadora independientemente, así como un IPK agregado para el sistema troncal. En el caso del IPK troncal, se puede calcular un IPK promedio para todas las flotas troncales.

§ Índice de Ocupación: Por cada ruta alimentadora independientemente, así como un Índice de Ocupación agregado para el sistema troncal. En el caso del IPK troncal, se puede calcular un índice promedio para todas las flotas troncales.

2.4.1. REQUERIMIENTOS DE ACCESO DE DATOS A PROTRANSPORTE Protransporte debe tener acceso a los datos operativos y de desempeño diarios de los Operadores de Flota y del SCC. Estos datos deben ser enviados a través de una


conexión segura a correo electrónico o Intranet, en un formato estándar que será definido durante la fase de diseño. Esta función deberá permitir a Protransporte verificar los registros con propósitos de auditoría. También se tendrá acceso directo a esta información a través de las estaciones de reportes.

2.5. OPCIONES DE COMUNICACIÓN Las opciones de comunicación para el Centro de Control, deben basarse en tecnologías que sean disponibles en el mercado peruano y escalables. Todas las opciones involucran un enlace inalámbrico debido a la naturaleza del sistema de comunicación: móvil.

2.5.1. DESCRIPCIÓN DE LAS COMUNICACIONES EN LA LÍNEA TRONCAL DE VEHÍCULOS

Las comunicaciones para los vehículos troncales deben tener capacidad soporte de voz y de datos. Los paquetes de información transmitidos entre los vehículos y el Centro de Control consisten esencialmente en información de ubicación, estado de la programación (itinerarios), alarmas mecánicas (u otros eventos), y mensajes de texto predefinidos. Estos paquetes de información son automáticamente generados y trasmitidos por la computadora a bordo del vehículo, o manualmente generados y transmitidos por el conductor al servidor de comunicaciones en el Centro de Control. Hay algunos otros paquetes de información o “eventos” que pueden ser generados y transmitidos manual o automáticamente. Algunos ejemplos de los eventos que como mínimo deben incluirse son:

§ Vehículo retrasado: Más de 2 minutos (automático).

§ Vehículo adelantado: Más de 2 minutos (automático).

§ Alarma de progreso: Menos del 90% de progreso en lo programado (automático).

§ Fuera de ruta: Más de 25 metros (automático).

§ Alarma mecánica: Detectada desde el vehículo (automático o manual).

§ Mensaje de texto predefinido: Mensaje del conductor (manual).

§ Alarma de emergencia: Situación hostil, accidente u otra falla no contemplada (manual).

§ Pedido Para Hablar (PPH): Permiso para cambiar a enlace de conversación de voz (manual).

§ Llegada y salida a estación, terminal o garaje: Se envían los datos de posición y estátus de progreso cada vez que se llegue y salga de algúna estación,


terminal o garaje. De esta manera se pueden medir con exactitud el Índice de Puntualidad y el Índice de Regularidad.

Los vehículos troncales también deberán contar con comunicación de voz con el Centro de Control. Para hablar será necesario solicitar autorización a través de un evento de “Pedido para hablar”. Este evento es enviado al centro de control como paquete de datos. Después de que este evento sea recibido en el Centro de Control y si el despachador responsable por el vehículo diera permiso para hablar, una conversación de voz puede comenzar, cambiando el enlace de comunicación de datos a voz, y cuando la conversación termine el enlace retornará al tipo de datos. Si una conversación por voz fuera establecida desde el Centro de Control hacia uno o un grupo de vehículos entonces no hay necesidad de una acción de Permiso Para Hablar PPH. En lugar de esto el enlace de comunicación es cambiado automáticamente a voz hasta que la conversación termine o el despachador designado cambie el enlace de nuevo a datos. El despachador debe contar con la posibilidad de realizar comunicaciones de voz con un vehículo en particular, un grupo de vehículos, todos los vehículos de una ruta, línea, o todos los vehículos del sistema.

2.5.2. DESCRIPCIÓN DE LAS COMUNICACIONES PARA LAS LÍNEAS DE VEHÍCULOS DE ALIMENTACIÓN

Las líneas de vehículos de alimentación estarán bajo un régimen menos estricto de control. La principal razón para este hecho será que las mencionadas líneas no tendrán disponible infraestructura de vías exclusiva o prioritaria. En vez de eso, los vehículos alimentadores tendrán que compartir las vías con el resto del tráfico automotor, por lo que estarán sujetos a mayores interferencias operativas y cambios en las condiciones de tránsito.

Los vehículos alimentadores deben de tener capacidad de comunicación de voz que les permitiría reportar el estado de su travesía de manera flexible, cualquier evento o emergencia; y al Centro de Control monitorear el cumplimiento del contrato y planear el despacho de vehículos de vehículos alimentadores.

Los vehículos alimentadores deben tener comunicación de voz con el Centro de Control. Los despachadores del Centro de Control deben contar con la posibilidad de realizar comunicaciones de voz con un vehículo en particular, un grupo de vehículos, todos los vehículos de una ruta, línea, o todos los vehículos del sistema.


2.5.3. OPCIONES DE COMUNICACIÓN Las opciones de comunicación incluyen, más no están limitadas a Sistema de Trunking propietario digital, tecnología Integrated Digital Enhanced Network (iDEN) y telefonía celular (CDMA o GSM). El operador del sistema del centro de control seleccionará la tecnología más apropiada para dar cumplimiento a los requerimientos y funciones a su cargo. El operador podrá usar cualquiera de estas tres alternativas o una distinta, siempre y cuando provea a satisfacción de Protransporte, condiciones iguales o mejores de comunicación.

2.6. SISTEMA DE LOS VEHÍCULOS DE LA LÍNEA TRONCAL Los vehículos de la línea troncal requieren una unidad de control del vehículo (Unidad Lógica) y un Terminal Móvil de Datos (TMD) para proporcionar un control total de la flota de la línea troncal. El sistema de vehículos debe de proporcionar las siguientes funciones primarias:

2.6.1. REGISTRO DE INGRESO Y SALIDA DEL CONDUCTOR DEL VEHÍCULO: El sistema debe proporcionar medios para que el vehículo registre su ingreso en el TMD móvil usando un número único de identificación de conductor e ID de bloque de programación para permitir al sistema sincronizar el vehículo al programa adecuado. Debe de haber también medios para que un conductor de relevo libre registre su entrada al vehículo cuando releva a un conductor en operación comercial.

2.6.2. MENSAJES DE DATOS: El sistema debe proveer medios para que un conductor mande una petición para hablar (PPH), y tenga la habilidad potencial de enviar mensajes de texto predefinidos en situaciones de ocurrencia rutinaria.

2.6.3. ALARMA DE EMERGENCIA: El sistema debe de proveer una alarma de emergencia usando un interruptor escondido que esta normalmente abierto, para no ser afecto a falsos contactos por la vibración, para permitir que el conductor notifique a despacho de una situación de emergencia u hostil en el vehículo sin que se enteren los pasajeros.


2.6.4. POSICIÓN DEL VEHÍCULO Y REPORTE DE ESTATUS: § El sistema del vehículo debe informar al despachador cual es la ubicación

obtenida del GPS del vehículo y su cumplimiento de la programación como mínimo cada dos (2) minutos. De igual manera debe enviar estos datos siempre que llegue y salga de una estación y terminal, u ocurra algún evento predefinido, como por ejemplo alarma de emergencia, alarma mecánica, fuera de ruta, vehículo retrasado, vehículo adelantado o alarma de progreso

2.6.5. SEGUIMIENTO DEL ODÓMETRO DEL VEHÍCULO: El sistema del vehículo debería de rastrear y actualizar el sistema de control central con su lectura actual de odómetro como parte de la posición del vehículo y reporte de estatus. Esto permite al sistema sincronizar el kilometraje comercial y no comercial.

2.6.6. ALARMAS MECÁNICAS: El sistema debe de estar conectado con los sensores del vehículo para percibir como mínimo: Temperatura del motor, nivel de aceite bajo, puertas abiertas/cerradas y baja de presión de aire (nótese que se puede necesitar filtrado durante el arranque, mientras que el sistema de freno de aire es cargado).

2.6.7. ADMINISTRACIÓN DE LA COMUNICACIÓN: El sistema del vehículo, una vez recibida la llamada de voz del despacho a el vehículo, debe de ser capaz de notificar al conductor, mediante señal visible y de audio que ha recibido una llamada del despacho, y dirigir el audio al dispositivo adecuado (dispositivo manual o altoparlante) para que el conductor se comunique con el despachador del Centro de Control.

2.6.8. ALMACENAMIENTO Y RECUPERACIÓN DE LA INFORMACIÓN: El sistema del vehículo debe de ser capaz de almacenar la programación por un mínimo de un día, adicionalmente, si por alguna circunstancia imprevista, el sistema de comunicación no esté en funcionamiento, el sistema embarcado debe de tener la capacidad de almacenamiento para retener información operacional hasta que el vehículo regrese al deposito para que sea descargada del vehículo usando un STID. No debe existir posibilidad que la información sea cargada manualmente.


2.6.9. INTERFAZ DEL CONDUCTOR: El Terminal Móvil de Datos (TMD) debe de ser la interfaz primaria del sistema para el conductor. La interfaz debe ser resistente y diseñada para el ambiente de operación. Las características principales del TMD deben de incluir una visualización con la capacidad de mostrar la programación actual y el cumplimiento de la ruta de cada vehículo, así como tener la capacidad de mostrar información de ruta tal como la próxima estación y punto de parada para el conductor. El TMD debe de tener un teclado resistente con números y teclas de función dedicadas para la petición para hablar (PPH) y otras funciones operacionales.

2.7. SISTEMA DE LOS VEHÍCULOS DE LAS LÍNEAS ALIMENTADORAS

Los vehículos de las líneas alimentadoras deberán estar equipados con dos sistemas; uno de radio para voz, o de un teléfono inalámbrico celular instalado en la infraestructura embarcada, y otro equipo de transmisión y recepción que use tecnología de identificación por Radio Frecuencia (RF-ID), infrarroja, o algún medio similar para comunicar la identificación del vehículo al equipo emisor - receptor instalado en como mínimo dos puntos clave a lo largo de cada una de las rutas alimentadoras, como por ejemplo, el inicio de la ruta y el fin de la ruta (estación terminal de troncal).

2.7.1. RADIO MÓVIL El radio móvil, o el teléfono inalámbrico celular, dependiendo de la arquitectura del sistema instalado tendrá un enlace de comunicación inalámbrica directa al Centro de Control. El despachador deberá tener la habilidad de llamar a un solo conductor, o a todos los conductores de la ruta, de la zona de alimentación, o del sistema.

2.7.2. EQUIPO EMISOR – RECEPTOR DE IDENTIFICACIÓN DE LOS VEHÍCULOS

El equipo de transmisión y recepción deberá ser un mecanismo comercial que utilice RF-ID, infrarrojo o una tecnología similar de comunicación sobre el rango de 5-15 metros. Este equipo debe ser instalado sobre los vehículos alimentadores, y servirá para validar que cada vehículo realice el viaje por la ruta completa, esto es posible mediante el registro de identificación del vehículo cada vez que pase por


los puntos de chequeo, esta información es asociada a una marca de tiempo, que indica el momento de cruce del vehículo por el punto de identificación.

2.7.3. SISTEMA DE CONTEO AUTOMÁTICO DE PASAJEROS Cada vehículo alimentador deberá estar equipado con un Sistema de Conteo Automático de Pasajeros (CAP) para brindar una doble validación de los pasajes validados por el sistema de recaudo. Debido a que los conductores de los vehículos no perciben un incentivo directo por la cantidad de pasajeros transportados, será necesario contar con otros medios para minimizar la evasión de las pasajes.

El sistema CAP deberá monitorear el flujo de los pasajeros en cada puerta del vehículo. El sistema deberá ser del tipo de múltiples sensores infrarrojos (activos, pasivos o una combinación de ambos) con disposición vertical u horizontal. El sistema deberá ser capaz de determinar con más del 95% de precisión el número de pasajeros que subieron y bajaron en cada parada.

El Sistema CAP deberá estar integrado con el Sistema de Venta, Validación y Recarga de Medios de Acceso o contar con su propios medios para almacenar sus datos operativos y transmitirlos en forma inalámbrica en los garajes cuando el vehículo termina el día de servicio.

2.8. EQUIPO DE RUTA El equipo de Ruta debe incluir una unidad transmisora y receptora de datos (baliza) para recibir la transmisión de identificación de cada vehículo, y una radio para comunicar la transacción a las aplicaciones del Centro de Control. No se requiere un control en tiempo real del sistema alimentador, pero el Centro de Control debe ser capaz de identificar qué vehículos van de salida contra cuales de entrada con los datos obtenidos en tiempo real en puntos específicos de control estratégicamente colocados a lo largo de la ruta. El objetivo de recoger estos datos es la comparación de los viajes y horarios reales de cada vehículo alimentador con los viajes y horarios programados, y así poder generar reportes de cumplimiento contractual.


2.8.1. EQUIPO EMISOR – RECEPTOR DE IDENTIFICACIÓN DE LA RUTA (BALIZA)

El receptor de la baliza deberá comunicarse con cada vehículo alimentador, también equipado con un equipo de emisión y transmisión de identificación, cuando éste cruce el plano de comunicación con la baliza. El receptor debe ser montado de manera que se comunique con el vehículo cuando éste se acerque los puntos de identificación distribuidos en la ruta, como pueden ser: al fin de la ruta (en la estación terminal), y al inicio de cada ruta alimentadora.

2.8.2. COMUNICACIONES

Las comunicaciones para los equipos de ruta deben utilizar la misma red de comunicaciones de datos que las del resto de la flota. El equipo de ruta deberá transmitir la identificación del vehículo al centro de control, donde el sistema marcará la hora del mensaje. Si el diseño del sistema introdujera retrasos en la transmisión, el equipo de ruta deberá generar la marca de hora de manera tal que el retraso en la transmisión no afecte los datos.

2.9. SOPORTE Y SERVICIOS

2.10 SERVICIOS DE SOPORTE TÉCNICO

El soporte Técnico para el SCC debe de incluir:

a. Monitoreo de la red y los dispositivos de lugar fijo. b. Mantenimiento de dispositivos embarcados. c. Mantenimiento de las instalaciones informáticas y de la

comunicación inalámbrica d. Mantenimiento de Software e. Mantenimiento de la Página Web del SCC f. Soporte Telefónico del Sistema COSAC g. Seguridad del Sistema e Integración de Datos h. Recuperación de Desastres Naturales i. Entrenamiento del personal de Operadores de Flota en el

mantenimiento de primera línea j. Manuales


2.10.1. ALCANCE DE TRABAJO El alcance de trabajo del Proveedor del SCC por servicios de soporte técnico debe de incluir, pero no estar limitado a:

a) Desarrollo de todos los procesos y procedimientos requeridos para proveer soporte técnico al SCC.

b) El desarrollo de manuales de soporte técnico detallando todos los requerimientos, procesos y procedimientos requeridos para el soporte técnico del SCC.

c) La actualización de los manuales de soporte técnico durante la duración del contrato.

d) Desarrollo de una estructura de organización requerida para el soporte técnico, identificación de roles y responsabilidades, y niveles de habilidad y experiencia requerida para cumplir esos roles.

e) Reclutamiento, contratación, capacitación y administración de personal.

f) La especificación y desarrollo de todos los cursos de capacitación y material de capacitación para el capacitación del personal del PROTRANSPORTE requerido para la entrega de servicios de soporte técnico.

g) Actualizar el material de capacitación del personal de PROTRANSPORTE durante la duración del contrato.

h) Planificación y conducción de cursos de capacitación para personal del PROTRASPORTE a lo largo de la duración del contrato, incluyendo cursos de capacitación progresivos.

i) La especificación, desarrollo y actualización de todos los cursos y materiales de capacitación del personal de los Operadores de Flota que realicen el mantenimiento de primera línea y el mantenimiento preventivo.

j) La adquisición, entrega y utilización de cualquiera y todos los materiales requeridos para el Taller Central de Reparación, incluyendo partes de dispositivos de repuesto y consumibles.

k) La provisión de lugares requeridos para servicios de soporte técnico. l) La provisión de cualquier vehículo requerido para servicio de soporte

técnico. m) La provisión de servicio de soporte técnico para el SCC por la duración

del contrato de concesión.


2.10.2. REQUERIMIENTOS. Los servicios de soporte técnico deben de incluir el desarrollo y la entrega de todas las tareas, funciones o actividades, ya sea especificado explícitamente o requerido implícitamente para desarrollar, implementar, manejar y proveer Soporte Técnico para el SCC. Los servicios de soporte técnico deben de incluir los siguientes requerimientos específicos:

2.10.2.1. Monitoreo del dispositivo y la red de comunicaciones

El Sistema debe monitorear la condición de todas las redes del SCC, incluyendo todos sus dispositivos y sistemas para facilitar la identificación inmediata y registro de los problemas, defectos y errores e iniciar las respectivas rectificaciones.

El monitoreo de las redes y los dispositivos debe de incluir:

a) Monitorear cualquier alarma y alerta generada por cualquier dispositivo en línea o computadora en tiempo real (incluyendo intrusiones/alarmas de seguridad), o de cualquier dispositivo fuera de línea.

b) Reportar las alarmas o alertas inmediatamente al Operador de Flota, cuando esto sea necesario, para que prepare el mantenimiento de primera línea a los equipos de SCC o si el equipo embarcado hubiera detectado una alarma mecánica de funcionamiento del bus ,

c) Monitorear la red de comunicación del SCC para asegurar que está operando de manera satisfactoria, y corregir cualquier error que requiera rectificación

d) Registrar todos los dispositivos en línea y fallas de la red en una Base de Datos de errores incluyendo aquellos que se generan automáticamente o son reportados por los Operadores de Flota mediante el soporte telefónico.

e) Grabar todas las fallas de dispositivos fuera de línea en una Base de Datos de errores incluyendo aquellos que son generados automáticamente o son reportados por los Operadores de Flota mediante el soporte telefónico.

f) Registrar todos los defectos del reportados por los agentes de inspección.

g) Definir la naturaleza del defecto en términos de quien debería rectificarla (el personal de operación de bus, técnicos de mantenimiento por llamada, personal de mantenimiento de reemplazo de unidades).

h) Priorizar trabajos de mantenimiento por llamada bajo criterios pre-acordados que generen especial preocupación del Operador de Flota.


i) Despacho y control de técnicos para realizar servicios de mantenimiento por llamadas.

j) Monitorear el estado de todos los dispositivos, computadoras y reparación de redes.

k) Liquidar defectos y registrar la terminación del mantenimiento por llamada y del trabajo de mantenimiento por reemplazo de unidades.

Todos los defectos deben de ser registrados y la siguiente (mínima) información debe de ser recogida para propósitos de reporte y auditoria.

a) Dispositivo o computadora y ubicación ya sea se encuentre embarcado o sea de lugar fijo.

b) Fecha y hora del comienzo del defecto (no necesariamente el mismo tiempo en que el defecto es archivado).

c) Código de defecto reportado automáticamente por dispositivo o computadora y/o descripción del defecto realizada por la persona reportándolo.

d) Para los servicios de mantenimiento por llamada, la identidad del técnico atendiendo el sitio del defecto, la fecha y hora en que el técnico llega al sitio y la fecha y hora en que el defecto es corregido.

e) Para el servicio de mantenimiento por reemplazo de unidades, la fecha y hora en que el dispositivo defectuoso es recibido en el depósito de reparación central y en que es reparado y devuelto al proveedor del servicio.

f) Medidas tomadas para rectificar el defecto.

g) Código de resolución del defecto.

El Sistema debe de proveer a los Operadores de Flota la capacidad de monitorear el estado de los dispositivos y redes a través de un sitio de Internet seguro, para apoyar la iniciación del mantenimiento de la primera línea por el Operador de Flota correspondiente.

El monitoreo de los dispositivos y redes y servicios de soporte telefónico del operador de bus pueden estar co-ubicados (e incluso compartir personal).

2.10.2.1.1. Horas de operación de monitoreo de los dispositivos y de las redes.

El monitoreo de los dispositivos automáticos y de las redes debería de operar 24 horas al día, 7 días a la semana. En el acontecimiento de una alarma, un mensaje será enviado automáticamente a través de correo electrónico, u otro medio como buscapersonas o mensaje corto de texto a dispositivo celular (SMS), al personal del Operador de Flota relevante. El personal de mantenimiento del Operador de Flota


será responsable de realizar el mantenimiento de la primera línea para corregir el problema.

2.10.2.2. Mantenimiento de Dispositivos

Los dispositivos deben de ser mantenidos mediante una combinación de servicios de mantenimiento, incluyendo:

a) Mantenimiento de primera línea, comprometiendo revisiones de rutina de los dispositivos, resolución de problemas operacionales menores y limpieza externa de los dispositivos, que es efectuada por el personal del Operador de Flota. El mantenimiento de primera línea también incluye la eliminación de dispositivos defectuosos en el campo por el personal proveedor del servicio sin herramientas o conocimiento especializado. El dispositivo defectuoso debe de ser remplazado por un dispositivo en buenas condiciones, proveniente del inventario de dispositivos de repuesto, y enviado (con un reporte de defecto) a un depósito de reparación central para el arreglo pertinente.

b) Mantenimientos preventivos, que comprendan mantenimiento de rutina de los dispositivos para prevenir fallas, realizados por el personal del operador de bus.

c) Mantenimiento de reemplazo de unidades realizado por el Proveedor de SCC, que comprenda la reparación de dispositivos defectuosos en el depósito central de mantenimiento y la devolución de los mismos a los Operadores de Flota para ser colocados en el inventario de repuestos de dispositivos.

d) Mantenimiento por llamada incluyendo asistencia técnica en el sitio del defecto, provisto por el Proveedor.

El servicio de mantenimiento de los dispositivos provistos por el Proveedor debe de incluir:

a) Soporte a Operadores de Flota para permitirles realizar mantenimiento de primera línea.

b) Mantenimiento de reemplazo de unidades (en depósito central de reparaciones)

c) Mantenimiento de llamada (en el sitio del defecto)

d) Reparación de dispositivos vandalizados.

e) Provisión y administración de partes de repuesto.

f) Abastecimiento de Consumibles

g) Abastecimiento de equipos de prueba y diagnóstico, y herramientas especiales.

h) Reporte de mantenimiento de dispositivos.


El Proveedor debe de proveer servicio de mantenimiento de dispositivos para cada Operador de Flota, para todos los dispositivos y sistemas de cómputo como se indica en el cuadro 2.10.2.2.

Cuadro 2.10.2.2.: Mantenimiento de Dispositivos

Dispositivo, computador

a o red

Manteni-miento de primera línea

soporte de manteni-miento de primera línea

Manteni-miento Preventivo

Servicios de reemplazo de Unidad

Servicios de manteni-miento por llamada

Unidad Lógica de a bordo

Operador de Flota Troncal

Proveedor Operador de Flota Troncal

Proveedor Proveedor

Terminal Móvil de Datos (TMD)

Operador de Flota Troncal

Proveedor Operador de Flota Troncal

Proveedor Proveedor

Sistemas de Comunicación Móvil de a bordo

Operador de Flota Troncal y Alimentador

Proveedor Operador de Flota Troncal y Alimentador

Proveedor Proveedor

Equipo Emisor –Receptor de Identificación de los Vehículos

Operador de Flota de

Alimentación

Proveedor Operador de Flota de

Alimentación

Proveedor Proveedor

Equipos de la Ruta

Proveedor Proveedor Proveedor Proveedor Proveedor

Sistema Inalámbrico de Transmisión de Datos (SITD)


Computadora de garaje


Sistema de Comunicaciones del SCC


Sistema de Centro de Control



2.10.2.3. Mantenimiento del Hardware Computacional y las redes

El Sistema debe de monitorear y mantener todos los sistemas de hardware del SCC, periféricos (como impresoras, pantallas de computadora y teclados) y redes de comunicación, incluyendo el Sistema de Reportes, Sistema de Programación de Itinerarios, Sistema de Control Central, Base de Datos, comunicaciones móviles y SITD.

2.10.2.3. Mantenimiento del Software y Administración de la Configuración

El Proveedor debe de mantener el software en todos los dispositivos del SCC, redes y computadoras (incluyendo el Sistema de Reportes, Sistema de Programación de Itinerarios, Sistema de Control Central y Bases de Datos) y administrar la configuración de ese software, incluyendo, pero no limitado por:

a) El software para la aplicación del SCC.

b) El software instalado en sistemas dentro del sistema de control central, incluyendo el software para las páginas Web y el centro de llamadas.

c) Los sistemas operativos, software de aplicación software contra virus y protección firewall para la administración de bases de datos y software de todos los dispositivos y equipos embarcados y de la ruta.

d) El Software y servicios de soporte para generar y mantener la amplia información de configuración del sistema.

e) Documentación publicada, actualizaciones y/o re-publicaciones de documentación técnica y procesos asociados de garantía de la calidad

Mantenimiento del software debe de incluir: a) La rectificación de los defectos del software y de configuración. b) El desarrollo y despliegue de mejoras de software y modificaciones requeridas

para enfrentar problemas con la operación de los dispositivos del SCC, redes y computadoras.

Mantenimiento del software no incluye cambio de software debido a variaciones de contrato. La configuración del software debería de incluir procesos para administrar:

a) Control de versión de software b) Validación de Software (validación de la instalación correcta e instalación de

paquetes de software aprobados y fijos) c) Inicialización de software d) Recuperación de software


El Proveedor de SCC debe de seguir y grabar las aplicaciones del software, sistemas operativos e información de configuración en uso en el SCC (incluyendo niveles de inicialización de todo el software) en una Base de Datos automatizada accesible por Protransporte.

El Proveedor debe de programar y distribuir la inicialización de software a ser instalados en todos los sistemas de computadora (Sistema de Reportes, Sistema de Programación de Itinerarios, Sistema de Control Central y Bases de Datos), dispositivos, sitios de Internet y sistemas externos para interconexión de sistemas. El Cronograma y la distribución de toda la inicialización de software deberían de ser automatizados y controlados centralmente. El Proveedor debe de ser responsable de la instalación de software en todos los niveles del SCC. Esto incluye la instalación de actualizaciones o parches de software y arreglos estándares para afrontar problemas encontrados o riesgos de seguridad.

Todos los servicios de mantenimiento del software, procesos y procedimientos deben de cumplir con el Plan de Garantía de Calidad (LRDC 28) y el Plan de Administración de Configuración del Sistema.

2.10.2.4. Mantenimiento del sitio Web

El Proveedor debe de ser responsable de todos los mantenimientos (y costos asociados) de los sitios Web del SCC (incluyendo la página Web del servicio al consumidor, si la opción se pone en práctica). Estos servicios deben de incluir, pero no se limitan a:

a) Mantener toda la información de las páginas Web actualizada y anunciar adecuadamente nuevas actualizaciones proporcionadas por Protransporte.

b) Actualizar la información de registro URL (de ser aplicable).

c) Realizar mantenimiento de rutina en el servidor de alojamiento de la página Web durante las horas no puntas de uso.

d) Seguir estadísticas relevantes de otras paginas Web para proporcionarlas a Protransporte en caso sean requeridas.

2.10.2.5. Soporte Telefónico del Proveedor de Servicio

El Proveedor debería de proveer soporte técnico vía telefónica a los Operadores de Flota. El soporte técnico debe de incluir administración del sistema, procesos operacionales, y todos los dispositivos SCC para los cuales los Operadores de Flota tienen la responsabilidad de realizar mantenimiento de primera línea y mantenimientos preventivos.


El soporte telefónico del Proveedor debe de asistir al personal del Operador de Flota con actividades diarias de administración y operación del sistema, y la ejecución de actividades de mantenimiento preventivo y de primera línea. Estos servicios deben ser aumentados a través del uso de manuales proporcionados por el Proveedor. El personal del Proveedor debe de tener la habilidad y los recursos necesarios para dirigir al personal del operador de bus de alimentación a través del proceso asociado con estas actividades.

El Proveedor debe proveer personal de soporte telefónico con suficiente experiencia técnica para resolver cualquier asunto relacionado a la administración del sistema, a la operación, al mantenimiento preventivo o de primera línea que podría ser encontrado por el personal del operador de bus de alimentación. Ante cualquier defecto o eventualidad que no pueda ser resuelto a través del servicio de soporte telefónico el Operador de Flota debería de ser asistido vía Internet por el Proveedor si así lo requiriese.

El soporte telefónico del Proveedor debe ser el punto de contacto a través del cual los Operadores deben:

a) Reportar defectos en los dispositivos, computadoras o redes.

b) Revisar el estado de cualquier dispositivo sujeto a los servicios de reemplazo de unidad.

c) Revisar el estado de cualquier computadora o red sujeta a servicios de mantenimiento por llamada.

d) Solicitar al Proveedor del SCC el abastecimiento de consumibles.

e) Recibir las recomendaciones del Proveedor del SCC para confirmar la situación de cualquier dispositivo en línea como si fuera en cualquier momento dentro de los tiempos configurables (configurados inicialmente a las 48 horas precedentes). Tal consejo puede ser solicitado por dispositivo o por una localización específica y debe de ser confirmada de forma escrita de ser requerida por el Operador de Flota.

El soporte telefónico a los Operadores de Flota debe de ser provisto por personal en tiempo real. Las Respuestas de Voz Interactivas (RVI) deben de proveer información después de las horas de oficina y puede ser utilizado para dirigir las llamadas al personal apropiado.

2.10.2.5.1. Horas de operación del soporte telefónico al Operador de Flota

El soporte telefónico al Operador de Flota debe de operar para las siguientes horas: a) Personal en tiempo real

i. Lunes a jueves 7:00am a 7:00pm


ii. Sábados, domingos y feriados públicos de 9:00am a 5:00pm. b) Grabadora de voz -24 horas al día, 7 días a la semana.

2.10.2.6. Seguridad del sistema e integración de la información

El Proveedor debe de ser responsable de monitorear, administrar y controlar todos los aspectos de la Seguridad del sistema y mantener la integridad de la información del SCC, incluyendo pero no limitándose a:

a) Control de acceso

b) Sistemas de identificación y autentificación

c) Funcionalidad de auditoria

d) Validación y archivo de transacciones o paquetes de transacciones

e) Mantenimiento de la integridad de la información en el sistema

f) Sincronización de fecha y hora

g) Control de acceso de información

h) Administración de llaves de seguridad

i) Investigar cualquier uso fraudulento o inapropiado del SCC

j) El Proveedor debe de desarrollar un plan de seguridad de sistema completo que identifique los elementos del sistema que requieran protección, e identifique mecanismos, procedimientos y procesos para contrarrestar amenazas de seguridad contra esos elementos.

Los Operadores de Flota deben de ser responsables de proveer una ubicación segura y mantener un acceso físico seguro a computadoras y dispositivos que se ubican en sus instalaciones o a bordo de los buses.

2.11. RECUPERACIÓN ANTE DESASTRES NATURALES

El Proveedor debe de proveer servicios de recuperación ante desastres para el SCC, como parte del servicio de soporte técnico. Los servicios de recuperación ante desastres debe de incluir:

a) El desarrollo de un plan de recuperación ante desastres b) Acceso a un centro de recuperación ante desastres c) Acceso a un a red central de recuperación ante desastres


d) Mantener el sistema de recuperación ante desastres y procedimientos en un estado listo para operar.

e) En el evento de un accidente, la implementación de un plan de recuperación de desastre.

2.11.1. PLAN DE RECUPERACIÓN DE DESASTRES NATURALES El Proveedor debe de ser responsable del desarrollo y la implementación de un plan de recuperación de desastres naturales. Los objetivos del plan de recuperación de desastres naturales deben asegurar la operación del SCC (incluyendo la entrega de todos los servicios) y la recolección y la integridad de la información en el caso de:

a) Sabotaje por cualquier grupo b) Falla total o parcial de cualquier función, subsistema, sistema, computadora,

dispositivo o red de contacto. c) Pérdida de todo o parte de la red de comunicación d) Falla o destrucción del Sistema Central de Control e) Falla prolongada en el abastecimiento de energía f) Infracción en la seguridad g) Cualquier otro evento, incidente o situación (incluyendo acción industrial) que

amenace o tenga un impacto en la operación del SCC

El Plan de recuperación de desastres naturales debe de abarcar todos los aspectos del sistema en forma detallada y completa, y debe incluir:

a) Procedimiento a seguir en caso de accidentes b) Puntos de contacto y procedimientos de recuperación de negocios para seguir

en el caso de varios tipos de incidentes y distintos tiempos de recuperación. c) Provisión de computadoras de resguardo ,computadoras en sitios alternos,

simulacros de práctica y de prueba d) Auditoria de resultados de prueba de planes de recuperación de desastres

naturales e) Provisión y almacenamiento de datos de resguardo en lugares alternos

El plan de recuperación de desastres naturales debe ser objeto de revisiones para minimizar el impacto de cualquier incidente posible de la operación del SCC. Un comité conjunto incluyendo a representantes de los Operadores de Flota , Protransporte y el Proveedor debe de ser formado para este propósito.

El Proveedor debe asegurar:


a) Que el plan de recuperación de desastres naturales sea mantenido bajo control de versión y la fácil determinación de la última versión.

b) La lista actualizada y apropiada de contactos de emergencia. Esta lista debe ser reemplazada en todas sus ubicaciones dentro de las 24 horas siguientes de cualquier cambio aprobado en la lista.

c) Un seguimiento de auditoria de la distribución de la información actualizada.

2.11.2. CENTRO DE RECUPERACIÓN DE DESASTRES NATURALES El Proveedor debe de proveer acceso a un centro de recuperación de desastres naturales.

El centro de recuperación de desastres naturales debe de ser ubicado en un lugar seguro y geográficamente remoto de la ubicación del Sistema de Centro de Control. La ubicación del centro de recuperación de desastres naturales deberá de ser valorado bajo la base de la ubicación propuesta considerando “un impacto potencial mínimo” a la operación del SCC en el caso que un desastre natural geográfico de gran expansión afecte el Sistema de Control Central.

El centro de recuperación de desastres naturales debe de incluir sistemas que son requeridos para el proceso de recuperación de negocios del Sistema Central, incluyendo servidores, estaciones de trabajo, conexión de redes secundarias, respaldos secundarios y arreglos de recuperación, abastecimiento de energía ininterrumpible (UPS) y equipo adicional.

2.11.2.1. Red de Comunicación del Centro de Recuperación de Desastres

Naturales

El Proveedor debe de proveer acceso a las redes de comunicación del centro de recuperación de desastres naturales.

La red de comunicación del centro de recuperación de desastres naturales debe de permitir al centro de recuperación de desastres naturales ser transmitido o redireccionado a todos los destinos finales del sistema independientemente de cualquier infraestructura del Sistema Central de Control.

2.11.3. MANTENIENDO LOS SISTEMAS DE RECUPERACIÓN DE DESASTRES NATURALES Y PROCEDIMIENTOS EN UN ESTADO DE ALERTA

El Proveedor debe de mantener el plan de recuperación de desastres naturales, el centro de recuperación de desastres naturales y la red de recuperación de desastres naturales en un estado de alerta y listo para actuar en todo momento.


El Proveedor debe de llevar a cabo simulacros de práctica sobre bases predefinidas para verificar que todo el equipo de recuperación de desastres naturales, sistemas y procedimientos están listos para actuar.

2.11.4. IMPLEMENTACIÓN DEL PLAN DE RECUPERACIÓN DE DESASTRES NATURALES

El Proveedor debe de ser responsable por la implementación del plan de recuperación de desastres naturales en caso ocurra un incidente.

El plan de recuperación de desastres naturales y el centro de recuperación de desastres naturales deben de estar listos para la re-implementación inmediata después de una caída del Sistema Central de Control en el sitio principal.

Después de cualquier implementación del plan de recuperación de desastres naturales, el Proveedor debería emitir un reporte a Protransporte repasando el incidente y la efectividad del plan de recuperación de desastres naturales, incluyendo la transición al centro de recuperación de desastres naturales y la transición de regreso al sitio principal.

2.12. SEGURIDAD DE DOCUMENTACIÓN DEL SOFTWARE

El Proveedor debe mantener cualquier software de SCC, manuales de software o códigos fuentes en garantía, de manera segura como lo acordado en el contrato. Para ello dispondrá de un sitio de depósito seguro de estos elementos.

El Proveedor debe actualizar cualquier software de SCC, manuales de software o códigos fuentes mantenidas en el depósito seguro dentro de los 5 días de la implementación de cualquier cambio en el software del sistema de producción.

Cualquier software de SCC, manual de software o códigos fuente mantenidos en el depósito seguro debe de ser validado por un tercer equipo y auditado después de cualquier implementación de actualización.

2.13. SERVICIO DE ADMINISTRACIÓN DE ACTIVOS DE SCC

El Proveedor debe de proveer servicios de administración de activos de SCC por el cual debe administrar y seguir el estado y ubicación de todo el software y hardware de los sistemas del SCC. Este sistema debe de utilizar un sistema de control de activos e inventario y una Base de Datos que cumpla como mínimo las siguientes capacidades:


a) Seguridad en el acceso de la información con controles de integridad como claves de múltiples niveles (con diferentes usuarios y contraseñas) y registros de quien entra y utiliza la información. El Proveedor debe ser totalmente responsable por la seguridad de la información del sistema.

b) Registro y seguimiento de todos los sistemas y sub-sistemas por un número de serie. Los componentes deben ser mantenidos en la Base de Datos durante su vida útil, sin importar su ubicación.

c) Controles de envió, como el registro de los destinos, fechas de envió, y un apropiado recibo en sus destinos.

d) Seguimiento de ítems a lo largo del proceso de mantenimiento en el taller ., y a archivos del historial de reparación de ítems.

a) Seguimiento de las razones de fallas reportadas, para permitir mejoras de diseño y reforzamiento de las especificaciones de confiabilidad de los equipos del contrato.

2.13.1. INVENTARIO CENTRAL DE EQUIPO El Proveedor debe de controlar y administrar cualquier inventario central de equipos y repuestos pertenecientes a Protransporte. El inventario debe ser guardado en un lugar acordado mutuamente por el Proveedor y Protransporte.

2.13.2. SERVICIOS DE ADMINISTRACIÓN DE SOFTWARE El Proveedor debe de administrar el software instalado en los dispositivos del SCC. Como parte de este proceso, el Proveedor debe crear y mantener una Base de Datos automatizada la configuración del software y las versiones de todos los subsistemas en el SCC. El Proveedor debe programar y distribuir todos las versiones de software a ser instalados en los dispositivos del SCC. La programación y distribución deben de ser automatizados, controlados centralmente y usar el formato de mensajes y procesos definidos y remitidos a Protransporte como parte de un “Mensaje de Especificación de Formato”. El Proveedor debe de ser responsable de la instalación de software en todos los niveles del sistema, a menos que el Operador o sus equipos acuerden en asumir la responsabilidad para la instalación de los sistemas instalados en sus instalaciones o en sus vehículos y que Protransporte este de acuerdo con esa transmisión de responsabilidad.


2.14. ADMINISTRACIÓN DEL SISTEMA CENTRAL DE SCC

El Proveedor debe proveer y administrar el Sistema Central de SCC. El Proveedor debe de ser totalmente responsable de todos los aspectos del Sistema Central. El Sistema Central de Control debe de contar con todos los requisitos directa e indirectamente especificados para el mismo a lo largo del contrato.

2.14.1 SERVICIOS MISCELÁNEOS 2.14.1.1. Auditoria del Sistema Central de Control

El Proveedor debe apoyar una auditoria anual e independiente del Sistema Central de Control, para validar la precisión de todos los sistemas de Programación de Itinerarios, Sistemas de Comunicaciones, Sistemas de Reportes y desempeño del Sistema Central de Control. La auditoria independiente anual del Sistema debe ser organizada, pagada y reportada por Protransporte.

Protransporte tendrá el derecho de auditar el rendimiento del Sistema Central de Control y cualquier equipo del Sistema Central de Control, como son: sistemas, bases de datos y operaciones, en cualquier momento, ya sea directamente o utilizando un equipo de auditores, sujeto a acuerdos de confidencialidad. El Proveedor debe apoyar cualquier auditoria del sistema requerida.

El apoyo provisto por el Proveedor para la auditoria del sistema debe de incluir, pero no limitarse a, garantizar el acceso a las instalaciones, equipos, sistemas, bases de datos y registros, asistir al personal de auditoria en el entendimiento y uso del sistema de auditoria del Sistema Central de Control y abastecer de cualquier reporte producido por el Sistema Central de Control.

2.14.2. PLAN DE SUCESIÓN El Proveedor debe proveer un plan de sucesión operacional del SCC, el cual tiene el propósito de proveer la operación continua en la situación en que el contrato con el Proveedor sea terminado de acuerdo con las condiciones establecidas en el contrato. Protransporte y los operadores de bus requieren que las operaciones del sistema central continúen sin interrupción bajo cualquier circunstancia.

En el plan de sucesión operacional del SCC los activos del SCC pasarán a Protransporte o a quién Protransporte designe. Los activos corresponden a todos los dispositivos sistemas de computadoras, hardware y software. Protransporte tendrá el derecho inmediato y automático para asumir o utilizar cualquier elemento requerido para el funcionamiento interrumpido del SCC (por ejemplo asignación de alquiler de las instalaciones, programas y software que se


encuentren en operación, etc.). El plan de sucesión operacional del SCC debe de incluir precios y procedimientos para transferir propiedad de cualquier elemento del sistema central requerido para la operación del sistema no perteneciente a Protransporte, incluyendo redes de comunicación, equipos de computadoras, equipos instalados en las flotas, equipos de la ruta y software, equipos de oficina e instalaciones arrendadas del Proveedor a Protransporte.

El plan de sucesión operacional del SCC debe describir cómo las operaciones de procesamiento de información del Proveedor deben continuar bajo el control de Protransporte, cómo todos los aspectos de los servicios de soporte de los clientes y Operadores de Flota deben ser entregados y cómo debe ser entregada la información de cuentas a Protransporte o su sucesor designado. Como mínimo el plan debe de cubrir las siguientes áreas:

• Transferencia de activos, incluyendo dispositivos, equipos, inventarios y otros materiales y abastecimientos.

• Transferencia de sistemas de hardware y software • Identificación de cualquier acuerdo contractual que son asumidos por

Protransporte, incluyendo pero no limitado a arriendos, acuerdos de mantenimiento.

• Personal y capacitación requeridos para lograr la sucesión • Comunicación del cliente considerando cambios en política, procedimientos y

formularios.


3. REQUERIMIENTOS DE DESEMPEÑO

3.1. DISPONIBILIDAD

La disponibilidad se define como el porcentaje de tiempo que un dispositivo esta operando normalmente, esto es, dentro de la intención de diseño y funcionalidad. Los cuatro componentes que determinan la disponibilidad son: i) horas requeridas de operación = tiempo que se requiere que el equipo este

disponible para conducir transacciones y otras actividades asociadas con la operación

ii) horas de mantenimiento programadas fuera de horario de servicio = tiempo requerido para realizar actividades programadas como lo son el mantenimiento de equipo y sistemas, actividades de servicio y reemplazo de consumibles. Las horas de servicio se programarán para el horario nocturno en el que el sistema esté fuera de operación. Las horas de servicio que se programen de esta manera no afectarán al cálculo de la disponibilidad.

iii) horas de mantenimiento programadas dentro de horario de servicio = Si fuera necesario programar horas de mantenimiento durante el horario de funcionamiento del sistema, éstas horas sí afectarán el cálculo de la disponibilidad.

iv) horas con sistema fuera de servicio = tiempo que un dispositivo o sistema relevante no está disponible para conducir transacciones en el calendario establecido.

La disponibilidad se debe calcular como se muestra a continuación:

Disponibilidad = (horas de op. efectivas) – (horas con sistema fuera de servicio)

(horas de op. efectivas)

donde:

Horas de Operación Efectivas = (Horas de operación requeridas – horas de mantenimiento programadas dentro de horario de servicio)


3.2. REQUERIMIENTOS DE DESEMPEÑO DEL SISTEMA DE

CENTRO DE CONTROL

El Sistema del Centro de Control brinda tres servicios principales: Control de Operaciones, Programación de Itinerarios de Operación y Reporte de Operaciones.

El Control de Operaciones consiste en la administración de los vehículos de las líneas Troncales y Alimentadoras, asegurando que la regularidad del itinerario sea mantenida, que los incidentes sean manejados de manera que se minimice su impacto en el servicio y que la seguridad del sistema sea mantenida.

Las tareas de Programación de Itinerarios de Operación incluyen el manejo de los itinerarios públicos provistos por Protransporte, repartición de estos itinerarios públicos en itinerarios para cada uno de los vehículos y el empaquetamiento de estos itinerarios vehiculares en itinerarios de flotas que se puedan asignar a los Concesionarios de Flota para que brinden el servicio.

El servicio de Reporte de Operaciones debe ser un servicio automático que mida el desempeño real de cada flota de vehículos con los itinerarios que le fueron asignados. Adicionalmente, el Reporte de Operaciones debe proveer la administración de reportes sobre el desempeño del Sistema del Centro de Control.

3.2.1. PROGRAMACIÓN DE ITINERARIOS DE OPERACIÓN La función de Programación de Itinerarios de Operación debe tomar el itinerario público de servicio requerido tanto para las líneas troncales como alimentadoras como los datos primarios contra los que la operación de flota será medida.

Basándose en el itinerario público, el sistema de Programación de Itinerarios de Operación debe ser capaz de optimizar los itinerarios de flota para que operen los buses en cada ruta en los horarios programados.

Los itinerarios de flota deben detallar todas las actividades de los vehículos desde la salida del garaje para comenzar el servicio hasta su regreso al garaje al término del día de servicio. Esto puede incluir periodos de estacionamiento intermedio durante el día.

El sistema de Programación de Itinerarios de Operación debe ser capaz de agrupar los itinerarios de los vehículos en bloques que puedan ser asignados a los operadores de flotas.


El sistema de Programación de Itinerarios de Operación debe ser lo suficientemente flexible como para permitir cambios periódicos en los itinerarios públicos y de los vehículos, así como también cambios de concesionarios y otros.

3.2.1.1. Itinerario Público

Es la tabla de horarios comunicada al público conteniendo, por ejemplo, los arribos de los vehículos a las estaciones o paraderos, o las frecuencias establecidas para distintos periodos del día y día de la semana. Debe tenerse en cuenta que existirán múltiples rutas en servicio, algunas que recorrerán las todas las estaciones y otras expresas que sólo harán paradas en algunas estaciones predeterminadas.

3.2.1.2. Itinerario de Vehículo

Se refiere a las actividades que debe realizar un vehículo desde el momento que entra en servicio, detallando todas las rutas y paradas que el vehículo debe realizar hasta el momento en que el vehículo sale de servicio retornando al garaje. Este itinerario vehicular debe ser usado por el sistema del Centro de Control para controlar el desempeño. El sistema de Itinerarios debe optimizar los itinerarios de cada vehículo para minimizar la flota y garantizar el cumplimiento de los niveles e indicadores de servicio definidos por Protransporte. Estos niveles e indicadores de servicio son básicamente: el mantenimiento o mejora del Índice de Pasajeros por Kilómetro (IPK), mantenimiento del Índice de Ocupación (que no deberá superar el 100% de ocupación en los 15 minutos más cargados del tramo crítico), el requerimiento de un máximo intervalo entre vehículos y la minimización del Kilometraje muerto. El itinerario también debe tener en cuenta las necesidades de relevos de conductores y la autonomía del vehículo (Kilómetros que puede recorrer con el tanque lleno de combustible más un margen de seguridad).

3.2.1.3 Control de Itinerarios

El sistema debe tener la capacidad de proveer los itinerarios actuales, así como la capacidad de crear itinerarios para servicios futuros y permitir la optimización de itinerarios y tablas de horarios basándose en el crecimiento en la demanda y carga de pasajeros que ocurra en el sistema, y mejoras operacionales como introducción o modificación de servicios expresos, y generación de recorridos de media vuelta (bucles o loops). El sistema debe asegurar que los itinerarios apropiados sean transferidos a los vehículos en cada garaje de flota así como también asegurar que todos los vehículos que operan en la línea troncal se encuentren asignados al itinerario apropiado.


3.2.1.4. Modificación de Itinerarios

El sistema debe tener la capacidad de modificar los itinerarios en tiempo real en caso ocurran interrupciones en el servicio. Adicionalmente, el sistema debe contar con un mecanismo que permita la inserción de un vehículo al itinerario programado, por ejemplo para aliviar a un vehículo sobrecargado. También debe tener la capacidad de recortar el servicio de un vehículo para permitir el mejor manejo del servicio en el sistema. Se debe tener la capacidad de requerir a un determinado vehículo sobrepase a otro que se encuentre sirviendo la misma ruta, como medida para solucionar problemas de apiñamiento.

3.2.2. CONTROL DE OPERACIONES El sistema de Control de Operaciones consistirá principalmente del equipo del Centro de Control, los despachadores y supervisores de ruta. Los despachadores deben manejar hasta 80 vehículos troncales o 200 vehículos alimentadores al mismo tiempo, por lo que el número de despachadores podrá variar dependiendo del período del día de servicio (hora Pico AM, PM u hora Valle). Como mínimo se requieren cuatro despachadores para los vehículos troncales (por cada turno) y dos para las rutas alimentadoras (por cada turno) para atender los períodos de máxima demanda. Los Supervisores de Ruta trabajarán en forma conjunta con los despachadores troncales y serán los encargados de observar y manejar las operaciones en las estaciones. Se prevé que serán necesarios aproximadamente ocho Supervisores de Ruta, quienes rondarán las estaciones asistiendo a los despachadores con los incidentes y otros asuntos operacionales como seguridad del sistema.

3.2.2.1. Funciones Principales

Las funciones principales del Sistema del Centro de Control son el manejo de las flotas, manejo de incidentes, proveer seguridad operacional y supervisar las operaciones.

3.2.2.1.1. Manejo de Flota

Los requerimientos primarios de las funciones de manejo de flota son el mantenimiento de los itinerarios públicos, asegurar que los vehículos operen a tiempo y desarrollando las tareas específicamente asignadas según itinerario a ellos. Adicionalmente, la función de manejo de flota debe trabajar conjuntamente


con los concesionarios de flotas cuando se presenten interrupciones en el servicio, incidentes, la demanda de pasajeros exceda la capacidad programada u otras necesidades operacionales para mantener el itinerario y provisión de vehículos necesarios para cubrir la demanda y flujo de pasajeros.

El sistema de manejo de flota debe trabajar para optimizar las operaciones de la flota, cubriendo las necesidades de volumen de pasajeros, en un balance entre el tiempo de espera de los pasajeros, la ocupación de los vehículos y los costos de brindar el servicio dentro de márgenes aceptables.

Las funciones del sistema de manejo de flota deben capturar como mínimo los datos mostrados en la tabla 3.2.2.1.1. de forma que sea posible establecer la adherencia contractual.

Tabla 3.2.2.1.1.: Datos requeridos para manejo de la flota

Datos Operacionales Exactitud del Dato

Método de Recolección del

Dato

Procedimiento de Validación del

Dato Identidad del

Conductor 100% Sistema DAC/LAV Fiscalización aleatoria

Identificación del Vehículo 100% Sistema DAC/LAV Fiscalización

aleatoria Identificación de la

Ruta 100% Sistema DAC/LAV Fiscalización aleatoria

Identificación de la Flota 100% Sistema DAC/LAV Fiscalización

aleatoria Identificación del

Servicio 100% Sistema DAC/LAV Fiscalización aleatoria

Localización del Vehículo +/- 25 metros Sistema DAC/LAV Fiscalización

aleatoria Medida del

desempeño respecto a la puntualidad en

cumplimiento horario

+/- 30 segundos Sistema DAC/LAV Fiscalización

aleatoria

Intervalo de vehículos troncales dentro del 20% del itinerario

programado

90% de la flota Sistema DAC/LAV Fiscalización aleatoria


3.2.2.1.2. Manejo de Incidentes

El Sistema del Centro de Control debe brindar la función de manejo de incidentes para el sistema. Debe trabajar con oficiales de seguridad pública locales para cubrir las necesidades de seguridad, pero será la única responsable por el manejo de la adecuación y cambio de rutas para el manejo de incidentes en las líneas troncales y alimentadoras. Debe contar con la habilidad de recortar el servicio de vehículos y devolverlos al garaje en casos en que la oferta de vehículos exceda la demanda de pasajeros. Adicionalmente, el Sistema del Centro de Control debe incluir en los itinerarios la necesidad de contar con vehículos de reserva que puedan ser insertados a servicio cuando la demanda supere a la oferta. El Sistema del Centro de Control debe proveer la administración oportuna de los vehículos de reserva para optimizar los costos de servicio, el tiempo de espera y la ocupación del sistema. El Sistema del Centro de Control debe administrar las necesidades de vehículos de reserva para minimizar los costos de operación.

3.2.2.1.3. Seguridad Operacional y Supervisión

El Sistema del Centro de Control debe brindar seguridad operacional básica y supervisión del sistema. Debe trabajar con oficiales de seguridad pública locales para cubrir las necesidades de seguridad, pero será la única responsable por asegurar que el sistema opere con seguridad. Debe brindar administración y manejo de riesgos para asegurar que el sistema opere en cumplimiento con los requerimientos de la industria y los locales. Puede requerirse integración de las operaciones con sistemas de control semafórico para una porción de la ruta.

3.2.3. REPORTE DE OPERACIONES La función de Reporte de Operaciones debe proveer reportes de desempeño del sistema que permitan el controlar el cumplimiento contractual de los Concesionarios de Flotas y del Sistema del Centro de Control. El sistema debe brindar estadísticas diarias, semanales y mensuales sobre la puntualidad de cada vehículo en servicio operando en las líneas troncales.

Para las líneas alimentadoras, el sistema debe capturar la hora de cruce de cada uno de los vehículos alimentadores por los puntos de control instalados en por lo menos dos puntos de cada ruta, como por ejemplo en la entrada de las estaciones y al fin de cada ruta, para permitir medir el desempeño de las rutas alimentadoras. Adicionalmente, el sistema debe usar los datos provenientes del sistema Contador Automático de Pasajeros (CAP) para comparar los datos de recaudo con las cuentas de pasajeros, de tal manera que se cuente con un nivel de confianza acerca del correcto recaudo a bordo de los vehículos alimentadores.


3.2.3.1. Soporte y Mantenimiento Técnico

El Proveedor del Sistema del Centro de Control es también responsable por el mantenimiento de los sistemas del Centro de Control incluyendo el equipo distribuido en lugares remotos, garajes e instalado en los vehículos. El Proveedor debe proporcionar los repuestos, realizar mantenimientos periódicos, alineamiento de sistema, y calibración necesaria para asegurar que el sistema opere dentro de márgenes de tolerancia aceptables. El Sistema debe determinar el Tiempo Medio Entre Fallas (TMEF) y mantener una disponibilidad mínima de 98% para el SCC. Se requiere que el Proveedor mantenga suficientes repuestos y practicas de mantenimiento adecuadas que permitan cumplir y mantener el requerimiento de disponibilidad.

El Proveedor es responsable por el entrenamiento de los Concesionarios de Flota en actividades de mantenimiento de primera línea. Este mantenimiento debe incluir:

§ Revisiones rutinarias de equipos

§ Resolución de problemas operacionales menores

§ Limpieza externa de equipos

§ Limpieza y lubricación de componentes internos (si fuera necesario)

§ Ejecución de pruebas de diagnóstico

§ Retiro y reemplazo de dispositivos y módulos de mantenimiento del depósito

§ Reemplazo programado de dispositivos y módulos

El Proveedor debe proveer de todos los módulos de repuesto e insumos necesarios para que los Concesionarios de Flota mantengan el equipo. Esto no incluye sólo los equipos y dispositivos de repuesto, sino que también los equipos de diagnóstico, ítems adicionales e imprevistos requeridos para realizar el mantenimiento de primera línea. Los Concesionarios de Flota no repararán los módulos o componentes ni ejecutarán reparaciones a nivel de tarjetas electrónicas, ni alguna reparación que requiera la manipulación de los componentes internos de los equipos.


El Proveedor debe operar el programa de mantenimiento de depósito como se indica a continuación:

a) El Proveedor debe proveer a los Concesionarios de Flota inventarios de dispositivos y módulos de repuesto que puedan mantener en sus instalaciones. El Proveedor debe mantener un inventario central de estos dispositivos y módulos para reforzar el inventario mantenido por el Concesionario de Flota. El Proveedor debe determinar y mantener en el inventario central cantidades de seguridad necesarias de repuestos que aseguren que siempre se contará con unidades de reemplazo para el inventario del Concesionario de Flota, evitando los costos innecesarios de inventario. Los niveles planeados de inventario deben ser documentados en un Plan de Mantenimiento.

b) En caso de falla o daño de algún componente, el personal del Concesionario de Flota llevará a cabo pruebas de campo para determinar cual es el componente o módulo defectuoso. El Proveedor brindará los procedimientos de pruebas de campo y los criterios de evaluación para cada dispositivo y módulo en el programa de mantenimiento. Una vez que la falla sea determinada, el personal del Concesionario de Flota reemplazará el dispositivo o módulo defectuoso con uno funcional equivalente de los repuestos de su inventario. Se enviará el dispositivo o módulo defectuoso a las instalaciones de reparación del Proveedor, adjuntando un reporte de falla.

c) Un dispositivo o módulo de reemplazo se enviará al Concesionario de Flota desde el inventario central para completar su inventario de repuestos, y los registros asociados con este dispositivo o módulo deberán ser actualizados para reflejar estas transferencias.

d) Las instalaciones de reparación deberán archivar el recibo de los dispositivos o módulos dañados o defectuosos, repararlos y devolverlos al inventario central adjuntando reportes indicando la naturaleza de la reparación, si es que hubiera alguna. Los archivos de la Base de Datos de activos debe ser actualizada con la información de la reparación. Se deberá brindar a Protransporte un reporte mensual resumen de seguimiento de fallas.

El Proveedor debe proveer suficientes dispositivos y módulos de repuestos para cubrir los requerimientos de desempeño del sistema. El inventario de repuestos debe ser un componente clave para las estrategias de mantenimiento en taller. Los repuestos deben ser intercambiables con sus dispositivos y módulos


correspondientes. Todos los repuestos deben ser reconfigurados a la última revisión durante el período de garantía.

El Proveedor debe remitir una lista de repuestos recomendados como parte de su plan de mantenimiento. Una lista final de repuestos debe ser entregada en la fecha de entrega de los repuestos de equipos, junto con recomendaciones que deben incluir lo siguiente:

e) Subsistema dentro del que se agrupa, diagnóstico, equipos de prueba y herramientas especiales, para identificación de stock.

f) Nombre genérico, nombre de marca, descripción, capacidad, precisión, número de parte del Proveedor, número de parte del fabricantes, referencias gráficas y correlación con los manuales de mantenimiento.

g) Correlación de las cantidades recomendadas con requerimientos de confiabilidad y tiempo para entrega de los equipos basándose en las siguientes clasificaciones:

§ Desgastables: Componentes que se espera sean cambiados regularmente bajo itinerarios de mantenimiento regulares, tales como partes mecánicas sujetas a operación continua.

§ Consumibles: Componentes con una vida esperada de menos de cinco años, como lámparas indicadoras.

§ Un sólo uso: Componentes que requieren reemplazo normalmente después de un solo uso, como fusibles.

§ Tiempo largo de entrega: Componentes que no son rápida o fácilmente adquiribles de los fabricantes (dentro de los 30 días), como componentes especialmente desarrollados.

§ Módulos Intercambiables: Componentes que reemplazarán a otros defectuosos (o que no responden correctamente) y que deben ser inventariados como ensambles completos.

h) Un sistema de referencia cruzada y un sistema de indexación para el reemplazo de componentes comunes a más de un subsistema.


3.3. REQUERIMIENTOS DE HARDWARE En esta sección se presentan los equipos requeridos para obtener las funcionalidades del sistema descritas previamente en esta sección. En esta sección específica, se describirán los requisitos de hardware necesarios para el desarrollo de un sistema a prueba de fallas, que garantice a los operadores del sistema, administradores y usuarios finales seguridad de uso confiabilidad de manejo, transferencia y gestión de la información. Con miras a alcanzar estos objetivos, muchos de los elementos centrales del sistema deberán ser diseñados con redundancia y capacidad de recuperación ante fallas. También será necesario tener en cuenta los factores ambientales que afecten el funcionamiento de cada uno de los elementos, subsistemas y sistema en general.

3.3.1. EQUIPOS DE LUGAR FIJO

Por equipo de lugar fijo se entiende al equipo instalado en el Centro de Control y en los garajes.

Se debe tener en cuenta los factores ambientales en el momento de seleccionar los equipos de lugar fijo, garantizando que cumplan con los estándares y normas internacionales y nacionales aplicables, respecto a los máximos rangos permitidos de emisiones de radiación, temperaturas de funcionamiento, seguridad, humedad ambiental, etc. Es importante tomar en cuenta las condiciones de Lima y adoptar las medidas de protección necesarias, tales como la adaptación de ambiente controlados para los equipos fijos, que asegure porcentajes de humedad relativas no mayores a 80% y temperaturas controladas menores a 20º Celsius en todo momento.

3.3.1.1. Equipos del Centro de Control

El equipo principal del Centro de Control es el servidor. El servidor es una computadora con grandes capacidades de proceso, sobre la que las funciones de comunicaciones, las bases de datos, los programas de administración de información y el software de programación de itinerarios funcionarán. La configuración recomendada para el servidor es un clúster. Un clúster de servidores es un arreglo de por lo menos de dos computadoras (servidores) cada uno con la capacidad para realizar todas las tareas requeridas por el sistema, de modo que si una de ellos falla el otro pueda asumir el control de las necesidades de cómputo de todo el sistema.


Un arreglo de discos duros redundantes (RAID por sus siglas en inglés) también se recomienda para la seguridad de almacenaje de datos, debido a que en la Base de Datos serán almacenados datos de gran importancia para el control de la flota y el análisis posterior tales como posiciones de los vehículos, tiempos de recorrido, estado de los viajes, acontecimientos, alarmas, estadísticas de las comunicaciones, cumplimiento contractual, etc. Esta arquitectura permite que el sistema sea a prueba de fallas y contenga una gran capacidad de recuperación.

Las estaciones de trabajo de los despachadores son computadoras a través de las que los despachadores tienen acceso información de la porción de la flota asignada para monitoreo y control a cada uno de ellos. Estas computadoras trabajan generalmente en un ambiente Windows NT, o equivalente a satisfacción de Protransporte, que permite que se comuniquen con el servidor y que recopilen la información necesaria. Como la cantidad de información visual que se debe manejar por el despachador es considerablemente grande, es común equipar cada sitio de trabajo con dos monitores (17 pulgadas de mínimo).

El último elemento a ser considerado es el hardware de comunicaciones, éste es el equipo de comunicaciones por radio que permitirá la recolección de información de todos los vehículos que sirven las diversas rutas troncales así como el establecimiento de una comunicación por voz con cada uno de los vehículos en líneas troncales y alimentadoras.

Adicionalmente a los elementos arriba descritos, una Fuente de Alimentación Ininterrumpible (UPS) se debe considerar para el Centro de Control, con capacidad mínima de 1 hora. En forma paralela a la FAI (UPS) se deberá instalar un grupo electrógeno para abastecer de energía eléctrica a todo el edificio donde opere el Centro de Control (las instalaciones de Protransporte). El grupo electrógeno se debe activar como máximo 15 minutos después de ocurrido el apagón, de modo que la FAI (UPS) cumpla su cometido y la energía se restaure antes de que las baterías de la FAI (UPS) se descarguen.

3.3.1.2. Equipos de los Garajes

Los vehículos pasarán una cantidad significativa de tiempo en los garajes, donde - entre otras tareas – se realizará la carga del itinerario y la descarga de los datos y estadísticas diarias de funcionamiento. Para cumplir con este requisito los garajes deberán estar equipados con un enlace de comunicaciones de alta velocidad, este enlace podría ser infrarrojo, con conexión física o por radio.

Si el enlace de comunicación es con conexión física, se prefiere una conexión a red Ethernet de 10/100 Mbps. Cada lugar de estacionamiento deberá tener un punto de conexión y se prefiere que los vehículos cuenten con una extensión del puerto de conexión Ethernet de la Unidad Lógica en la parte externa de la carrocería. Esta


extensión debe estar apropiadamente protegida de la exposición al medio ambiente, lluvia, polvo y humedad.

Si las comunicaciones son por Infrarrojo, cada lugar de estacionamiento deberá tener un punto de conexión y el puerto de comunicaciones de la Unidad Lógica debe contar con una extensión hasta la parte externa del vehículo. Esta extensión debe estar apropiadamente protegida de la exposición al medio ambiente, lluvia, polvo y humedad. La velocidad de comunicación debe ser 9600 bps como mínimo.

Si el enlace de comunicaciones es inalámbrico por radio, cada Unidad Lógica deberá contar con una interfaz de red de tipo WI-FI (IEEE 802.11), o similar superior. El garaje deberá contar con un Router de conexión inalámbrico con capacidad de comunicación con toda la flota en forma simultánea y con un rango de cobertura de todo el garaje.

En todos los casos mencionados los garajes deben contar con un pequeño servidor que sirva como concentrador de la información y un enlace para el envío de estos datos al Centro de Control. Este enlace puede ser por radio o con conexión física.

3.3.2. EQUIPOS MÓVILES Y DE LA RUTA

3.3.2.1. Equipos Móviles

Todo el equipo a bordo debe poder funcionar con energía obtenida desde los 12-24 Voltios estándares del vehículo y soportar caídas del voltaje de hasta 0 voltios por varios segundos - durante el período arranque – así como picos del voltaje sin que estos afecten sus operaciones normales. Después de una pérdida de energía, es aceptable que el equipo se reinicie parcialmente, luego de lo que retornará a su estado de funcionamiento normal, sin perder la información del conductor y la ruta.

El equipo embarcado también deberá estar protegido contra sobre-voltajes de hasta 200 Voltios e incluso la inversión de del sentido de alimentación de energía durante las operaciones de mantenimiento. Los equipos y las conexiones deberán ser protegidos contra cualquier daño que resulte descargas estáticas.

Todo el equipo de a bordo deberá poder funcionar bajo exigentes condiciones ambientales como polvo, exposición directa a luz solar, alta humedad relativa y EMI/RFI. También estar protegidas contra la exposición y salpicaduras de agua durante operaciones de limpieza y de mantenimiento.

Todo el equipo embarcado que deba estar en contacto directo intencional con cualquier persona a bordo, sean chóferes, pasajeros, personal de limpieza o mantenimiento deberá ser resistente a la abrasión y desgaste por uso, así como


estar diseñado de manera que no represente peligro de ningún tipo para las personas que los rodean.

Adicionalmente, todo el equipo embarcado deberá ser capaz de mantener funcionamiento normal bajo condiciones de vibración con una aceleración no menor a 2,5 g RMS en el rango de 0 – 2000 Hz y resistir un pulso de impacto mínimo de 20 g por 10 ms.

3.3.2.1.1 La Unidad Lógica:

La Unidad Lógica es el equipo principal de a bordo, siendo responsable del manejo de todos los subsistemas embarcados que han sido descritos con anterioridad. La Unidad Lógica es un equipo que tiene la capacidad de realizar tareas de cómputo- Puede ser un equipo basado en microprocesador o un equipos basado en PC industrial. La Unidad Lógica debe incluir cuatro componentes principales: Unidad Central de Procesamiento (CPU), memoria, puertos de comunicación y adaptador de fuente de alimentación. La diferencia principal entre la PC industrial y el equipo basado microprocesador es que la PC industrial es estandardizado y extensible ya que puede utilizarse para diversas tareas (como por ejemplo en automatización industrial), mientras que el equipo basado en microprocesador ha sido desarrollado solamente para esta aplicación.

Todas las tareas de cálculo computacional son ejecutadas por el CPU y todas las entradas y salidas de datos son almacenados en la memoria.

Los puertos brindan a la Unidad Lógica la capacidad de comunicación con otros equipos dentro y fuera del vehículo. Los puertos de comunicaciones básicos son: el puerto serial (UART por sus siglas en inglés), la interfaz de monitor estándar, la interfaz de teclado estándar. El monitor y el teclado son llamados Interfaces Hombre Máquina (HMI por sus siglas en inglés) y son las interfaces mínimas requeridas para el ingreso de instrucciones a la Unidad Lógica y salida de la Unidad Lógica al operador de la unidad. El UART se utiliza para comunicarse con otros equipos de a bordo tal como el módem de comunicaciones, el equipo recaudo, el GPS, etc.

Además de estos puertos básicos se recomienda, un puerto paralelo, puerto Ethernet estándar, bus serial universal (USB) y entradas y salidas lógicas optoacopladas.

Los requerimientos mínimos necesarios para la Unidad Lógica son:

§ Microprocesador Intel Pentium o similar superior.

§ 4 MB RAM o superior.

§ 2MB Flash EEPROM o superior.


La unidad lógica deberá ser equipada con un sistema de alimentación que le permita mantenerse en estado funcional por un periodo de tiempo después de que el vehículo ha sido apagado. Este período de tiempo debe ser definible por usuario y debe asegurar que como mínimo el sistema embarcado haya terminado de transmitir todos los datos necesarios al Centro de Control. Si el vehículo es encendido nuevamente dentro de un período de tempo, también definido por usuario, no deberá ser necesario que el chofer re-ingrese su identificación y se re-conecte al sistema.

3.3.2.1.2 El Terminal Móvil de Datos (TMD):

En algunos casos el TMD del conductor vendrá incorporado con el resto de la Unidad Lógica (generalmente en los casos de Unidades Lógicas basadas en Microprocesador), mientras que en otros casos serán dos equipos por separado. Este TMD debe ser montado de forma que sea siempre posible su correcta visualización y lectura así como su fácil manejo por parte del conductor. El TMD es un HMI ya que permite al chofer acceder a información enviada por el Centro de Control al vehículo así como también enviar información ingresada por el chofer al Centro de Control.

El TMD proveerá al conductor el acceso fácil a algunas funciones usadas comúnmente a través de teclas de software con funciones que cambian de acuerdo al contexto presentado en pantalla. Las funciones de estas teclas deben ser definibles por el usuario. Debe haber por lo menos 6 de tales teclas. Además se debe incluir un arreglo de teclas para ingreso alfanumérico. Es importante que todo el etiquetado de las teclas sea resistente al desgaste causado por el uso frecuente del botón.

El TMD debe ser capaz de mostrar un mínimo de 80 caracteres a la vez, cada uno de estos caracteres debe ser fácilmente legible por el conductor en una posición sentada normal.

Otra consideración importante es que el TMD debe ser fácilmente legible en condiciones de luz y de oscuridad, por lo que debe ser iluminado desde la parte posterior y la superficie delantera de la no debe reflejar demasiado brillo.

3.3.2.2. Equipos de la Ruta

Algunos puntos de la ruta, especialmente las estaciones terminales de las rutas alimentadoras, deben ser equipados con balizas que validen el paso de los diferentes vehículos por puntos determinados de chequeo. Estas balizas deberán contar con capacidad de comunicación para transmitir la información recolectada al Centro de Control. De esta manera, el Centro de Control incorporará herramientas de monitoreo para poder controlar el cumplimiento contractual de


los vehículos de las líneas alimentadoras, no en términos de su posición exacta en cada instante de tiempo, sino en términos de monitoreo del número de viajes diarios por vehículo por cada ruta y el número de viajes en una ventana de tiempo (pie. periodo punta, hora del día).

La información intercambiada entre los vehículos y las balizas consiste esencialmente de un número de identificación único en el sistema para cada vehículo. Se deduce de esto que la cantidad de datos transmitida es pequeña en comparación con los datos manejados por los buses troncales. La transferencia de esta información deberá ser lo suficientemente rápida y el rango de comunicaciones lo suficientemente grande como para permitir que el vehículo no requiera realizar una parada especial para cada transferencia. El rango de comunicación no deberá ser menor a 5 metros ni mayor a 15 metros para asegurar que a cada momento se encuentre sólo un vehículo dentro del rango de comunicación.

Este enlace de comunicación puede ser infrarrojo o por radio. Las balizas deben ser resistentes y poder soportar condiciones ambientales como la lluvia, humedad, polvo y incidencia directa de luz solar.

3.4. REQUERIMIENTOS DE SOFTWARE Y PLATAFORMAS PREFERIDAS

De manera general, todo el software del sistema y subsistemas deberá ser de preferencia estandarizado y de funcionamiento comprobado en el campo. Todo el software deberá cumplir o exceder las normas y estándares nacionales e internacionales aplicables y deberán correr bajo un sistema operativo disponible, estandarizado y comercial.

Todo el software deberá ser diseñado de manera modular, de manera que se asegure que cualquier cambio del código se lleve a cabo de manera rápida y sin afectar al resto de los módulos del programa. El diseño del software deberá llevarse a cabo utilizando lenguajes de programación estándares, entre los que se prefiere a los orientados a objetos.

Todo el software deberá ser fácilmente expandible de acuerdo a los requerimientos de crecimiento del sistema. Tanto la modularidad como la expandibilidad son conceptos claves a tenerse en cuenta para el diseño y selección del software que sea utilizado en el sistema.


El software de aplicación para el Centro de Control deberá contar con capacidad de trabajo en red, ya que la capacidad de comunicación de datos entre los sistemas y equipos tanto internos como externos del Centro de Control son requeridas.

El sistema operativo preferido para los servidores del Centro de Control y para las estaciones de trabajo será seleccionado por el Concesionario del Servicio del Centro de Control. Son aceptables sistema Linux o Windows NT, o superior a satisfacción de Protransporte. El software de manejo de bases de datos será seleccionado por el Concesionario del Servicio del Centro de Control. Son aceptables Oracle, SQL, Informix o similares, a satisfacción de Protransporte.

Se deberá instalar un programa de supervisión que permita monitorear el funcionamiento y rendimiento del hardware y otro software corriendo en el sistema, así como detectar errores. El programa de supervisión generará datos y estadísticas del desempeño del sistema, con los que el Administrador del sistema podrá obtener realimentación del estado general del sistema y tomar medidas correctivas y/o preventivas para mejorar la funcionalidad del sistema.


3.5. REQUERIMIENTOS DE DESEMPEÑO DE SERVICIOS

3.5.1. NIVELES DE SERVICIO DEL SISTEMA CENTRAL 3.5.1.1. Administración de Transmisión de Datos de Equipos Embarcados y de la

Ruta

a) Como mínimo, todos los datos de operación recolectados deben transmitirse al SCC una vez cada 24 horas.

b) Las interfaces en línea deben tener una disponibilidad mínima de 99%, 24 horas al día y 7 días a la semana.

c) Las interfaces de tipo “Batch” (de transferencias de paquetes) deben tener una disponibilidad mínima de 99%, 24 horas al día y 7 días a la semana

3.5.1.6. Reportes

• Los reportes diarios deben estar disponibles antes de las 8 a.m. del siguiente día laboral.

• Los reportes mensuales deben estar disponibles para el último día laboral del mes al que corresponde el reporte.

• Los reportes semestrales deben estar disponibles para el último día laboral del mes perteneciente al semestre al que corresponde el reporte.

• Los reportes especializados que se deban entregar al SR y a Protransporte para sustentar la conciliación y distribución de ingresos deben estar disponibles para las 8 am del tercer día desde el cierre para conciliación y distribución.

• Los reportes personalizados que hayan sido acordados con el Concesionario y que no superen un cierto nivel de complejidad definido, deben estar disponibles dentro de los cinco minutos desde que fueran solicitados.

• Reportes personalizados que excedan este nivel de complejidad deben ser entregados a Protransporte dentro de las 3 horas desde que fueran solicitados.

• Reportes personalizados que utilicen datos que tengan que ser recuperados de archivos debe ser entregada dentro de 8 horas desde su solicitud.

a) Los Sitios Web del SCC para atención a los Operadores de Flota deben estar disponibles más del 99.955% del día, 7 días a la semana.

b) No debe programarse mantenimiento del sitio Web entre las 6 a.m. y las 11p.m. c) El Sitio Web del SCC para atención a los Operadores de Flota debe ser capaz de

soportar 500 usuarios individuales ingresando el Sitio Web y realizando simultáneamente una variedad de funciones incluyendo navegar, envío de


comentarios, ejecución de funciones de administración y descargando datos y reportes.

3.5.2. REQUERIMIENTOS DE PRECISIÓN DEL SISTEMA CENTRAL 3.5.2.1. Tiempo en los Dispositivos

El tiempo del sistema en todos los dispositivos, sistemas y otros puntos finales debe tener una máxima desviación de 5 segundos respecto de la fecha y hora patrones mantenidos por el Sistema Central

3.5.2.5. Administración de Activos

a) El registro y rastreo de todos los dispositivos y sistemas debe ser 100% preciso y completo en todo momento.

b) El rastreo de los dispositivos y módulos a través del Servicio de Reemplazo de Unidad debe ser 100% preciso y completo en todo momento.

c) Los registros de configuración y versión de software en todos los elementos del SCC deben ser 100% precisos en todo momento.

3.5.3. NIVELES DE SERVICIO DE ADMINISTRACIÓN DE SOPORTE TÉCNICO 3.5.3.1. Monitoreo de Dispositivos y Red

a) Todas las fallas reportadas al personal de soporte técnico por teléfono o correo electrónico, deben ser registradas y archivadas dentro de los diez (10) minutos desde que se recibió el reporte de falla, durante las horas establecidas de atención.

b) Las fallas detectadas por el sistema de monitoreo del sistema, deben ser registradas automáticamente. Las alarmas generadas por las fallas detectadas del sistema deben ser reconocidas para atención en menos de cinco (5) minutos desde que se recibió el reporte de falla, durante las horas establecidas de atención.

c) Las fallas detectadas deben ser comunicadas al Operador de Flota correspondiente dentro de los diez (10) minutos desde que la falla fuera detectada por el sistema de monitoreo.

3.5.3.2. Taller de Reparación Central

a) Debe entregarse a los Operadores de Flota una cotización de trabajo de reparación o reemplazo de Módulos o Dispositivos que presenten una falla no atribuible a los Operadores de Flota dentro de un día laboral desde la recepción del dispositivo a módulo en el Taller Central de Reparación.


b) Un Dispositivo o Módulo de reemplazo debe ser enviado al Operador de Flota dentro de los cinco días laborales desde que fuera recibido el Dispositivo o Módulo defectuoso en el Taller Central de Reparación

3.5.3.3. Servicios de Mantenimiento por Llamada

Los técnicos de mantenimiento por llamada deben llegar al sitio debido para el mantenimiento dentro de los siguientes tiempos desde que se notificara al Concesionario de la falla de algún dispositivo, ya sea a través del Soporte Telefónico a los Operadores de Flota o a través de una alerta automática:

a) 3 horas en el 95% de los casos

b) 5 horas para el restante 5% de los casos

3.5.3.4. Repuestos y Consumibles

a) Los Consumibles deben ser entregados a los Operadores de Flota dentro de las 24 horas desde la solicitud de reemplazo del stock de consumibles.

b) No debe existir casos de ninguna reparación de dispositivos (realizada bajo Reemplazo de Unidad o Servicio de Mantenimiento por Llamada) que se retrase debido a falta de repuestos o consumibles.

3.5.3.5. Soporte Técnico Telefónico al Operador de Flota

a) Todas las llamadas entrantes deben ser respondidas dentro de cuatro timbradas b) La tasa de abandono de llamadas debe ser menor al 2% c) El tiempo promedio de espera para hablar con una operadora debe ser menor a 1

minuto.

3.5.3.6. Reportes de Mantenimiento del Operador de Flota

El Concesionario debe entregar un reporte de actividad de mantenimiento a cada Operador de Flota, con respecto a su operación dentro de los cinco días previos al fin de cada mes.

3.5.3.7. Recuperación Ante Desastres Naturales

Después de algún incidente y activación del Centro de Recobro Ante Desastres Naturales:


§ Todas los Sistemas Principales deben recobrarse a su capacidad completa dentro de 48 horas desde el incidente.

§ Todos los sistemas secundarios deben recobrarse a su capacidad completa dentro de 120 horas desde el incidente.

§ El Sistema de Centro de Control debe encontrarse completamente recuperado a su condición preexistente dentro de los 30 días desde la implementación del Plan de Recuperación Ante Desastres Naturales.

Los Sistemas Principales abarcan:

• Dispositivos

• Redes de Comunicaciones

Los Sistemas Secundarios abarcan:

• Recolección de datos desde los dispositivos

• Funcionalidad de Sitio Web

3.5.3.8. Registros del Sistema Central

Los detalles de todas las actividades de Soporte Técnico registradas en el Sistema Central de Control deben ser 100% precisas y completas en todo momento. Esto incluye, pero no se limita a lo siguiente:

a) Inventario de repuestos, dispositivos, módulos y consumibles. b) Registro de todos los incidentes detectados por o reportados al Soporte Técnico. c) Registro de todas las fallas encontradas con identificación de hardware, software y

de configuración. d) Registro de todos los dispositivos o módulos que hayan sido registrados como

defectuosos, y el estado de la reparación. e) Registro de todas las reparaciones realizadas, con reparación de fallas, costo,

materiales consumidos y tiempo de reparación.

4. REQUERIMIENTOS DE IMPLEMENTACIÓN DEL SISTEMA En esta sección se define:

§ Plan de implementación de los Sistemas y Servicios del Sistema de Centro de Control.


§ Control de Diseño y Configuración.

§ Pruebas y Aceptación.

§ Administración del Proyecto.

§ Capacitación

§ Manuales

§ Lista de Requerimientos de Datos Contractuales (LRDC)

4.1. PLAN MAESTRO DE IMPLEMENTACIÓN

4.1.1. ALCANCE DEL PLAN MAESTRO El Concesionario debe desarrollar un Plan Maestro de Implementación (LRDC 1), que será revisado y aprobado por Protransporte, definiendo acciones que deben ser emprendidas para el logro de la implantación y funcionamiento de los sistemas, como se implementarán estas acciones y el Cronograma de entregas. El Plan Maestro debe identificar los puntos críticos que afecten al cronograma y asignar responsabilidades para los componentes clave de los Sistemas y Servicios. Estos componentes claves deben incluir requerimientos funcionales, operacionales y técnicos, así como temas de coordinación de itinerarios e integración de sistemas. El Plan Maestro debe identificar y definir, como mínimo, los siguientes componentes.

a) Instalaciones donde se realizarán las operaciones designadas para cada fase de implementación del Plan.

b) Requerimientos de la Arquitectura del Sistema, incluyendo funcionalidades requeridas, métodos de transferencia de datos, auditoria y almacenamiento de datos, y establecimiento y operación del Sistema Central de Control.

c) Requerimientos de equipo, incluyendo hardware, software y necesidades de red. Los requerimientos de equipos deben ser agrupadas por fase, operador y localización (donde sea aplicable).

d) Cronograma para diseño de equipos y prototipos, pruebas, producción y tareas de instalación. Se deben identificar las rutas críticas y las dependencias para cada fase.

e) Los roles y responsabilidades de Protransporte, los operadores participantes, proveedores externos y cualquier otro involucrado en el programa para el COSAC.


El Plan Maestro debe incorporar y ser consistente con los itinerarios que manejan ciertas tareas o grupos de tareas o fases del proyecto, tales como diseño, pruebas, instalación y operaciones.

El Plan Maestro estará sujeto a la revisión y aprobación de Protransporte. Este Plan Maestro se constituirá como compromiso formal de cronograma y será utilizado para monitorear y controlar la implementación del proyecto.

4.1.2. REVISIONES El objetivo del Plan Maestro es brindar guías para la implementación de los sistemas y servicios. El Plan Maestro debe ser revisado cada tres meses durante la implementación del sistema o cuando ocurran cambios significativos en los procesos de implementación. Todas las revisiones estarán sujetas a la aprobación de Protransporte.

4.1.3. PLAN DE IMPLEMENTACIÓN El Concesionario debe implementar el SCC de acuerdo con las dos fases iniciales actualmente planeadas para el COSAC. La Fase I incluirá aproximadamente una tercera parte de los vehículos y su operación se limitará a la parte Sur; mientras que la Fase II, con aproximadamente dos tercios de la flota, completarán el sistema de COSAC inicial. Probablemente exista un período corto de promoción y ajuste de los sistemas, brindando servicio gratuito, que se limitará a la zona Sur. Protransporte debe aprobar el Plan de Implementación del Sistema, Servicios y Funcionalidades para ambas fases.

El Concesionario debe tener un papel de consultor para Protransporte en las iniciativas de información pública y de marketing para el programa del COSAC.

4.1.4. DESARROLLO DE REQUERIMIENTOS DETALLADOS DE IMPLEMENTACIÓN PARA OPERADORES DE FLOTA DETALLADOS

a) El Concesionario debe visitar las instalaciones de cada uno de los Operadores de Flota que participen para de esta manera desarrollar un conocimiento completo de los requerimientos específicos de implementación de cada Operador.

b) El Concesionario debe trabajar individualmente con los Operadores de Flota para precisar y finalizar los detalles de cada implementación en particular. Esto incluye llegar a un acuerdo final acerca del lugar físico donde será instalado todo el equipo tanto en las instalaciones del Operador de Flota como a bordo de los vehículos.

c) Este acuerdo final debe ser aprobado por Protransporte.


4.1.5. INSTALACIÓN DEL SISTEMA a) El Concesionario del Sistema del Centro de Control debe ser responsable por la

instalación física de todo el equipo en las facilidades del Operador de Flota así como a bordo de los vehículos.

b) El Concesionario del SCC debe especificar los requerimientos para la instalación física de los dispositivos, incluyendo fuentes de alimentación eléctrica y de telecomunicaciones en cada punto.

c) La responsabilidad del Concesionario del SCC por la instalación debe incluir el anclaje de equipos, conexión a fuentes de alimentación eléctrica y líneas de comunicación previamente instaladas, así como la instalación de equipos de pruebas para asegurar que los equipos instalados se encuentren bajo correcto funcionamiento.

4.2. CONTROL DE DISEÑO Y CONFIGURACIÓN El programa del Concesionario para el control del diseño y configuración de los sistemas y servicios debe cumplir los siguientes requerimientos.

4.2.1. REVISIONES DE DISEÑO Se deben realizar revisiones formales de diseño para evaluar el progreso así como asegurar que se cuente con la capacidad funcional y de programación suficiente para el diseño de acuerdo con los requerimientos de desempeño contractuales. Adicionalmente a las revisiones formales de diseño, se llevarán a cabo reuniones informales para tratar temas claves siempre que sea necesario. Antes de cada revisión, se debe entregar un paquete de revisión de diseño que incluya documentos del LRDC y otros componentes requeridos para la revisión. Dichos paquetes de revisión deben ser entregados por lo menos 20 días laborales antes de que la revisión se lleve a cabo.

Las revisiones de diseño consistirán de las siguientes actividades:

a) El paquete de revisión de diseño será revisado por Protransporte.

b) Como resultado de la revisión, se entregará al Concesionario por lo menos una semana antes de la reunión de revisión de diseño una lista de temas en los que se esté en desacuerdo.

c) Participarán en la reunión o serie de reuniones de revisión de diseño el Protransporte, el Concesionario, y los Operadores de Flota, y en ellas el Concesionario debe explicar su diseño mientras que los Operadores confirman sus requerimientos. Cuando sea posible los puntos de desacuerdo serán resueltos durante estas reuniones.


d) Los puntos de desacuerdo que no sean resueltos durante las reuniones deben ser identificados y documentados. Teniendo en cuenta el punto de avance en que se encuentre el proyecto, Protransporte determinará la acción apropiada para resolver las diferencias y desacuerdos, lo que puede requerir en algunos casos la nueva entrega de algunos puntos de revisión de diseño.

e) Una vez que no existan más puntos de desacuerdo sin resolver con la entrega de revisión de diseño del Concesionario, se aprobará dicha entrega.

El Concesionario del SCC debe conducir por lo menos las siguientes dos revisiones formales de diseño.

4.2.1.1. Revisión de Diseño Preliminar (RDP)

El objetivo del RDP es revisar el diseño de equipo propuesto por el Concesionario del SCC y determinar que modificaciones son requeridas y posibles para cubrir los requerimientos de desempeño de dispositivos descritos en esta sección. La RPD debe representar aproximadamente el 50% del total de los trabajos de ingeniería y diseño. La RDP debe cubrir lo siguiente:

a) Revisión de cumplimiento de cronogramas y discusión de variaciones o demoras.

b) Brindar diagramas de bloques funcionales del sistema y equipo.

c) Descripciones técnicas detalladas de los mayores componentes de los dispositivos de control y comunicaciones.

d) Descripción detallada de Interfaz, incluyendo arreglos de montaje y métodos de instalación.

e) Diagramas de alimentación eléctrica de una sola línea (“Single-line power diagrams”) y diagramas de bloques funcionales para cada dispositivo, incluyendo una descripción general del funcionamiento, y descripción de como cada dispositivo o subcomponente sale de servicio.

f) Interfaces de comunicaciones

g) Lista de todos los formatos de archivos en el Servidor de Datos de SCC y sus duplicados.

h) Lista de herramientas especiales para cada dispositivo y equipo.

i) Descripción de compatibilidad física y operacional con equipos existentes y equipos instalados.

j) Resultados detallados de los factores humanos de ingeniería.

k) Diseño del acceso de control para a) el equipo y b) los menús de software.

l) Diagramas de flujo de software de nivel de sistema.


m) Procedimientos de backup y recuperación de datos

n) Descripciones de diseño de software

o) Sistema de control de configuración y versión de software.

El Concesionario del SCC puede categorizar la información de las RDP en tópicos lógicos. Las RDP pueden ser conducidas como una serie de reuniones para discusión de tópicos relevantes . Diez (10) copias de las entregas específicas deben ser entregadas con anterioridad al RDP.

4.2.1.2. Revisión de Diseño Final (RDF)

La RDF debe ser conducida cuando los diseños detallados estén completos y los planos de producción estén listos para su remisión. El objetivo de la RDF es establecer si los diseños detallados serán capaces de satisfacer los requerimientos de diseño establecidos en el Contrato. Los datos entregados en la RDP deben ser actualizados a un nivel de detalle que sea consistente con el diseño completo y presentados para el RDF. El RDF debe cubrir lo siguiente:

a) Revisión de cumplimiento de cronogramas y discusión de variaciones o demoras.

b) Últimas revisiones de los diagramas, planos y documentación presentada con la RDP.

c) Secuencias de Encendido y Apagado.

d) Diagramas de ensamble detallando hasta el último nivel reemplazos de unidades.

e) Diagramas esquemáticos eléctricos.

f) Diagramas de flujo o de estructura que brinden una descripción del software del procesador.

g) Documentación de software.

h) Definiciones de ingreso de datos

i) Definiciones de salida de datos

j) Definición de la estructura de interrupción

k) Parámetros de programa

l) Rutinas de diagnóstico para prueba automática del procesador y los subsistemas.

m) Rutinas de manejo de errores.

n) Diccionario de datos


Diez (10) copias de las entregas específicas deben ser entregadas con anterioridad a la RDF. Protransporte debe tener acceso a diagramas y otra información de fabricación y diseño relacionada a todos los dispositivos, incluyendo los códigos fuente de los microprocesadores y otros datos técnicos propietarios. El Concesionario puede establecer acuerdos de confidencialidad convenientes.


4.3. PRUEBAS Y ACEPTACIÓN

4.3.1. GENERAL Todos los componentes, subsistemas y procesos de sistema que constituyen el sistema de Protransporte deben ser probados individualmente y en conjunto para asegurar que cumplan los requerimientos contractuales y que se entregue un sistema propiamente funcional. El trabajo en esta sección debe incluir todas las tareas, materiales, y servicios de soporte requeridos para inspeccionar y probar completamente todo el hardware y software. Las pruebas deben ser conducidas en tres niveles:

a) Operaciones de dispositivos: Las pruebas de los dispositivos especificados incluyendo Unidad Lógica, Terminal de Datos Móvil y DAC/LAV;

b) Integración e interfaz de componentes: Pruebas de redes, software e integración de interfaces de los dispositivos.;

c) Instalación y operaciones: Instalación y pruebas de aceptación, incluyendo la interfaz de Operador.

Todas las pruebas e inspecciones deben ser monitoreadas y aprobadas por Protransporte y documentadas por el Concesionario. Cualquier y todo hardware y software que no pase las inspecciones y/o pruebas y que no cuente con la aprobación de Protransporte debe ser reparado, reemplazado y/o corregido por el Concesionario y reprogramarse una nueva inspección y prueba.

4.3.2. PLANES DE PRUEBA, PROCEDIMIENTOS Y FACILIDADES El Concesionario debe entregar un Plan de Pruebas e Inspección General (LRDC 29) para la revisión y aprobación de Protransporte, que será utilizado como documento de control para las inspecciones y pruebas. La información proveída para cada inspección debe incluir pero no limitarse a lo siguiente:

a) Título de la Inspección / Prueba;

b) Referencia a la(s) sección(es) del Contrato que requieren tal inspección / prueba.;

c) Organización responsable por la realización de la inspección/prueba;

d) Lugar de la inspección/prueba;

e) Objetivos de la inspección/prueba;

f) Criterios de paso o fallo de la inspección/prueba;

g) Itinerario de la inspección/prueba que presente la siguiente información como mínimo:


i) Entrega de procedimientos de inspección/prueba ii) Fecha de inicio de inspección/prueba iii) duración de la inspección/prueba iv) Entrega de reporte/certificación de inspección/prueba.

El Plan de Pruebas debe cubrir todas las inspecciones y pruebas a ser realizadas por el Concesionario, el Proveedor y el Subcontratista; incluyendo aquéllas que se lleven a cabo bajo el Plan de Garantía de la Calidad del Proveedor. Los resultados de las inspecciones y pruebas se entregarán para revisión a Protransporte dentro de los 30 días desde la finalización de la inspección o prueba.

4.3.3. INSPECCIÓN Y PRUEBAS DE DISPOSITIVOS Esta sección define los requerimientos para la inspección y prueba global de dispositivos, como es especificado aquí, incluyendo lo siguiente:

a) Sistemas de transmisión de datos inalámbricos

b) Unidades Lógicas del Vehículo

c) Terminales de Datos Móviles

d) Radios

e) Radio Modems

Una combinación de inspecciones, pruebas de calificación de diseño, pruebas de primeros artículos y pruebas de aceptación deben ser usadas para establecer la integridad del diseño y fabricación de los dispositivos y componentes para el SCC.

Las principales inspecciones y pruebas que se realizarán, así como los requerimientos mínimos para cada inspección se presentan a continuación.

a) Pruebas de Calificación de Diseño;

b) Inspección de Configuración de Primeros Artículos (ICPA);

c) Prueba de Primeros Artículos (PPA);

d) Inspección y pruebas de Producción

4.3.3.1. Pruebas de Calificación de Diseño

El Proveedor debe demostrar que cada componente o subsistema de los dispositivos entregados cumple o excede los requerimientos de esta especificación. En casos en los que el componente o subsistema sea sustancialmente similar a en diseño y aplicación a equipo previamente utilizado en una aplicación similar, el diseño puede ser calificado a través de la presentación de datos de servicio activo y comercial, sujeta a la aprobación de Protransporte.


En cualquier otro caso, se requerirá al Proveedor llevar a cabo pruebas de diseño que demuestren que todos los requerimientos de esta especificación sean cumplidos. No será necesario repetir estas pruebas una vez que sean exitosamente cumplidas y atestiguadas. Si se falla una prueba, el Proveedor debe realizar cualquier modificación necesaria al equipo y repetir la prueba hasta que sea cumplida exitosamente. El alcance de las pruebas de calificación de diseño debe ser descrito en el Plan de Pruebas.

4.3.3.1.1. Pruebas de Calificación Mediante Análisis

Si las pruebas que fueran requeridas para demostrar el cumplimiento de ciertos requerimientos fueran potencialmente poco concluyentes, se puede lograr la aprobación de Protransporte para la eliminación de requerimientos de algunas pruebas de calificación de diseño. El proceso de calificación mediante análisis es el siguiente:

a) Presentación de petición de eliminación de requisito de prueba que detalle los atributos de diseño específicos que serán calificados de esta manera;

b) Obtener la aprobación;

c) Presentar análisis apropiados junto con documentos de revisiones de diseño;

d) Obtener aprobación durante el proceso de revisión de diseño.

4.3.3.1.2. Eliminación de Requisitos para Equipo Probado

Si el componente o subsistema en cuestión es considerado por Protransporte como sustancialmente idéntico en diseño a equipo previamente instalado en otras aplicaciones de transporte público, las pruebas de calificación de diseño aplicables a este equipo podrían ser no aplicables. Para eliminar este requisito de prueba, el Proveedor debe proporcionar la siguiente información:

a) Lista de los lugares y cantidades de los equipos actualmente instalados, incluyendo la duración de la actividad de los servicios;

b) Descripción de todas las diferencias relevantes entre las otras instalaciones y los requerimientos de la especificación;

c) Descripción de todas las diferencias entre los equipos actualmente instalados y el equipo presentado para el presente Contrato;

d) Los resultados de alguna prueba de calificación de diseño relevante que haya sido realizada al equipo.

Con base en la información presentada, Protransporte determinará si los requerimientos para las pruebas de calificación de diseño pueden ser eliminadas para el componente certificado. Los requerimientos específicos de cada pieza de equipo serán consideradas individualmente y será posible eliminar algunos requisitos de prueba mientras que


otros serán conservados. La eliminación de requisitos de prueba de componentes individuales no satisface la prueba de componentes integrados.

4.3.3.2. Inspección de Configuración de Primeros Artículos (ICPA)

La Inspección de Configuración de Primeros Artículos (ICPA) tendrá lugar en el punto de ensamblaje, luego de completarse la producción de los primeros dispositivos listados previamente. Protransporte deberá ser notificado con una anterioridad mayor a diez (10) días laborales a la fecha de ICPA. Subsecuentemente, se le notificará al Proveedor la asistencia de Protransporte.

LA ICPA debe verificar que el hardware de producción cumpla con la configuración y diagramas de diseño como fue acordado durante la Revisión de Diseño Final, o la última revisión que haya tenido lugar desde ésta. Se debe tener acceso a los resultados de las pruebas de calificación de diseño durante la ICPA. Protransporte puede requerir una repetición de cualquier parte o la integridad de la prueba de calificación de diseño durante la ICPA, si los resultados de la inspección inicial fueran insatisfactorios.

4.3.3.3. Prueba de Primeros Artículos (PPA)

Los equipos de Control que serán probados en la Prueba de Primeros Artículos (PPA) deben estar compuestos por unidades de la primera producción para cada dispositivo de los identificados anteriormente. La Prueba de Primeros Artículos (PPA) debe ser llevada a cabo con posterioridad al término exitoso de la ICPA.

La PPA debe ser llevada a cabo por el Proveedor sus instalaciones. Protransporte puede designar personal para auditar periódicamente el progreso de las PPA. Todos los reportes de las PPA estarán sujetos a la aprobación de Protransporte. Cada una de las siguientes pruebas deben completarse para cada una de las unidades:

a) Pruebas funcionales y de Ciclo;

b) Pruebas de Factores Humanos;

c) Pruebas Ambientales;

d) Pruebas de Mantenibilidad.

En este nivel de pruebas, los equipos presentados como primeros artículos, deben ser representativos de los equipos de producción final. El propósito de estas pruebas debe ser el de demostrar que todos los equipos fabricados bajo este contrato, cumplan con los requerimientos de esta especificación.

Si en algún momento posterior a que se acepten los resultados de las PPA, se realiza algún cambio, se debe demostrar el desempeño del equipo modificado a conformidad


con los requerimientos contractuales, y los resultados de las nuevas pruebas estarán sujetos a la aprobación de Protransporte.

El término exitoso de las PPA constituye un prerrequisito para la fabricación del equipo de producción. Todos los insumos necesarios para las PPA deben ser proveídos por el Proveedor.

5.3.3.3.1. Pruebas Funcionales y de Ciclo

Las pruebas funcionales y las pruebas de ciclo pueden llevarse a cabo en simultáneo. El propósito de las pruebas funcionales es demostrar que las funciones especificadas en este documento, incluyendo todas las condiciones limitantes o extremas, hayan sido alcanzadas para cada tipo de dispositivo. El objetivo de las pruebas de ciclo es determinar con un grado de certeza razonable que cada dispositivo y subsistema, o componente de ese dispositivo, son capaces de cumplir con los requerimientos de confiabilidad aquí especificados. Las condiciones ambientales de prueba (temperatura y humedad) deben ser medidas y documentadas por lo menos dos veces durante cada día de pruebas.

Durante las pruebas funcionales y de ciclo, se debe proveer una de cada una de las configuraciones y tipos de dispositivos. Estos dispositivos deben ser representativos de aquellos que serán operados. El equipo usado en las pruebas de funcionamiento y de ciclo debe simular el equipo instalado en el sistema, sin tomar en cuenta las conexiones de red a las instalaciones de Control. Las transacciones que se realicen durante las pruebas funcionales y de ciclo deben ser llevadas a cabo por las personas que conduzcan las pruebas, yendo de dispositivo en dispositivo en secuencias variantes. Todas las posibles combinaciones de transferencias entre los dispositivos varios deben ser probadas.

En los Procedimientos Detallados de Pruebas para las pruebas funcionales, el Proveedor debe identificar y listar todas las características del dispositivo, incluyendo todas las condiciones extremas y los procedimientos para el manejo del mantenimiento y funciones de servicio, que serán probadas en las pruebas funcionales. Los Procedimientos también deben identificar todas las transferencias que serán probadas. Cada dispositivo debe ejecutar todas las funciones de software y hardware, para las varias condiciones especificadas. Todos los modos de operación, como el modo de mantenimiento, deben ser incluidos en las pruebas. Las pruebas también deben incluir todas las condiciones extremas que se puedan anticipar debido a acciones incorrectas de los usuarios, o equipo defectuoso. Cada función puesta a prueba debe ser repetida por un mínimo de diez (10) veces correctamente para que la prueba funcional se considere exitosa. No debe existir falla en los equipos de prueba durante las pruebas funcionales. Se debe repetir la prueba funcional si ocurriera una falla del dispositivo. El Proveedor también debe demostrar la capacidad del control de software para cambiar los tipos y parámetros, incluyendo las condiciones extremas permitidas en cada dispositivo.


Para las pruebas de ciclo de los dispositivos con componentes ingresados por usuarios, se requiere un mínimo de 10,000 transacciones por cada dispositivo. Estos dispositivos incluyen Terminales Móviles de Datos, Radios, Radio Modems, así como cualquier otro que contenga un teclado que requiera que el usuario ingrese datos. Para cada dispositivo, estas transacciones deben ser divididas igualmente entre todas las posibles transacciones. Información detallada acerca de los tipos de transacción a ser usados en las pruebas de ciclo deben ser incluidas en los Procedimientos Detallados de Prueba (LRDC 30) y estar sujetos a la aprobación de Protransporte.

La confiabilidad de cada dispositivo y cada subsistema, o subcomponente principal deben ser monitoreados y documentados (grabados) durante las pruebas de ciclo. Cualquier falla que no sea atribuible a cada dispositivo y cada subsistema, o subcomponente principal en si mismo debe ser documentada como falla.

Se debe permitir un máximo de ocho (8) horas para el mantenimiento preventivo durante la ejecución de las pruebas funcionales y de ciclo.

4.3.3.3.2. Pruebas de Factores Humanos

El propósito de esta prueba es verificar que aquellas características operativas que afectan al usuario en su uso del dispositivo sean fáciles de comprender, fáciles de usar y de rápida respuesta a las acciones del usuario. La prueba debe ser diseñada para evaluar tópicos como los siguientes:

a) Gráficos, pantalla y mensajes de audio;

b) La relación de tiempo entre que el mensaje es mostrado y/o el audio es emitido y la acción de la máquina;

c) Relación de tiempo de respuesta entre las acciones de la máquina, mensajes mostrados y sonidos emitidos ante las acciones de usuarios;

d) Tiempo para realizar una transacción;

e) Tiempo entre transacciones sucesivas permitidas;

f) Tiempo entre varias instrucciones de máquina;

g) Tiempo de cambio entre varios modos de operación;

Las metas y objetivos de estas pruebas son asegurar que los dispositivos hayan sido diseñados con enfoque a la ergonomía y eficiencia.

4.3.3.3.3. Pruebas Ambientales

Estas pruebas deben validar que los terminales activados por los usuarios cumplan con los requerimientos ambientales. Estas pruebas deben ser llevadas a cabo en


instalaciones que sean capaces de simular el rango de condiciones operacionales y ambientales.

Durante las pruebas ambientales no deben ocurrir más de dos fallas en los dispositivos. Las pruebas ambientales deben confirmar que los dispositivos funcionarán bajo las condiciones ambientales consideradas como el peor de los casos, incluyendo temperatura, humedad, viento, polvo y lluvia. El Proveedor debe detallar las condiciones de pruebas ambientales en el Plan de Pruebas y detallar los procesos para cada prueba en los Procedimientos Detallados de Prueba. (LRDC 30).

4.3.3.3.4. Pruebas de Mantenibilidad

Una vez terminadas las pruebas ambientales de forma exitosa, el Proveedor debe llevar a cabo pruebas de verificación de mantenibilidad del equipo. El propósito de estas pruebas será el determinar si el equipo cumple con los requerimientos de mantenibilidad especificados en este documento. Estas pruebas se llevarán a cabo mediante la introducción de fallas en los equipos y luego midiendo el tiempo que requiere el técnico de mantenimiento del Proveedor en corregir la falla.

Las pruebas de mantenibilidad se llevarán a cabo en los primeros equipos de producción de la siguiente manera:

a) El Proveedor debe introducir componentes defectuosos, desajustes y configuraciones incorrectas. Las fallas simuladas deben ser introducidas en proporción con los indicadores de falla esperados;

b) Se asignará personal del Proveedor a reparar el equipo; el personal no deberá conocer de antemano las fallas simuladas introducidas;

c) Los tiempos de reparación deben ser medidos y se calcularán los tiempos medios de restauración y de reemplazo.

El Proveedor debe identificar las bases de selección de falla por módulo o subensamblaje y el tiempo razonable para el reemplazo o restauración de los módulos o subensamblajes en los Planes de Prueba y Procedimientos Detallados de Prueba. Las pruebas que deban llevarse a cabo y los tiempos que se consideren aceptables estarán sujetos a la aprobación de Protransporte.

4.3.3.4. Inspecciones y Pruebas de Producción

Las inspecciones y pruebas de producción deben ser conducidas por el Proveedor en cada equipo que sea producido como parte integrante de su programa de garantía de la calidad. Estas inspecciones y pruebas deben verificar que todos los equipos contengan los materiales correctos, sean ensamblados correctamente, y funcionen correctamente.


Protransporte puede observar, conducir, auditar o repetir las pruebas sobre cualquier ítem para confirmar la validez de los procedimientos y resultados del Proveedor.

Las inspecciones y pruebas de producción se llevarán a cabo en las instalaciones del fabricante en todos los subsistemas y en cada dispositivo completo de manera previa a su envío a destino. Estas inspecciones deben verificar que cada unidad sea producida con un nivel de calidad igual o mejor que el de las unidades presentadas para la ICPA y PPA.

Los procedimientos de inspección y prueba deben ser actualizados basados en la experiencia adquirida mediante las pruebas subsecuentes u operación de los equipos. Los procedimientos de prueba deben ser expandidos para enfocarse en áreas que se compruebe sean, o hayan sido históricamente, problemáticas. Las pruebas pueden ser simplificadas en áreas donde se tenga un gran nivel de confianza, sólo si se cuenta con la aprobación de Protransporte.

Se deben mantener registros completos de todas las inspecciones y pruebas realizadas. Se debe registrar cualquier falla y subsiguiente medida correctiva. Estos registros deben estar disponibles a Protransporte si así lo requiriera. El exitoso término de las inspecciones y pruebas de producción son requisito para la instalación del equipo.

4.3.4. INSPECCIÓN Y PRUEBAS DE INTERFAZ E INTEGRACIÓN El objetivo de este nivel de pruebas es asegurar que los diferentes componentes unitarios del sistema se integren de la manera descrita en los requerimientos contractuales. Estas pruebas deben combinar los diferentes componentes del sistema de manera que simule los ambientes de los sistemas instalados de SCC. Todas las unidades deben estar completamente integradas. Esto debe incluir provisiones de comunicación para integrar todos los dispositivos, todos los servidores de datos y sistemas centrales. Las pruebas de interfaz e integración también deben cubrir las interfaces de los componentes de SCC con equipos de los Operadores de Flota existentes o que sean adquiridos por fuera de este Contrato.

Todas las conexiones de interfaz deben ser inspeccionadas para asegurar una correcta instalación. Para cada componente en el sistema, todas las funciones que requieran interfaz a otro componente, incluyendo todas las condiciones extremas y provisiones de seguridad, deben ser probadas. Estas funciones deben incluir pero no estar limitadas por lo siguiente:

a) Transmisión de alarmas y todas las funciones de monitoreo de dispositivos y/o componentes;

b) Transmisión de datos a los servidores de datos y al Sistema Central de Control;

c) Transmisiones de datos, incluyendo todas las funciones de control, provenientes del Sistema Central de Control y servidores de datos autorizados;


d) Funciones del sistema LAV;

e) Generación de reportes.

El Proveedor debe identificar cada función integrada en los Procedimientos Detallados de Prueba, incluyendo las condiciones límites y provisiones de seguridad para cada uno. Los límites y provisiones de seguridad a ser probados para asegurar el cumplimiento de los requerimientos contractuales deben incluir pero no estar limitados por lo siguiente:

a) Rangos de operación para cada tipo de componente/dispositivo remoto;

b) Tiempos de desempeño de funciones;

c) Encriptación de datos y provisiones de seguridad para cada tipo de transferencia de datos;

d) Provisiones anti-colisión de datos para cada tipo de transferencia de datos aplicable.

Todas las transmisiones de datos deben ser inspeccionadas respecto a su exactitud. Las transmisiones de datos no exactas se registrarán como falla de la prueba particular para el que se realizó la transmisión. El Proveedor debe tomar cualquier acción correctiva que sea necesaria para asegurar el correcto desempeño de todas las funciones probadas bajo las pruebas de interfaz e integración El exitoso término de las inspecciones y pruebas de interfaz e integración son requisito para la instalación del equipo.

4.3.5. INSPECCIÓN Y PRUEBAS DE INSTALACIÓN Y ACEPTACIÓN Esta sección describe los requerimientos de inspección y prueba asociados con la instalación y aceptación del sistema.

4.3.5.1. Inspección y Pruebas de Instalación

La instalación del equipo puede comenzar después de la exitosa finalización de las pruebas de interfaz e integración de sistemas. Los Procedimientos Detallados de Pruebas para la inspección y pruebas de instalación deben incluir listas de verificación (“checklists”) que identifiquen los equipos, software y las configuraciones de instalación y otras características aplicables a los procesos y parámetros de instalación. Los Procedimientos también deben identificar y describir todos las pruebas necesarias para verificar la correcta instalación y enlace de los equipos con sistemas en otras instalaciones. Las listas de verificación y procedimientos de prueba deben ser entregados a Protransporte con anterioridad a la inspección y pruebas programadas y estarán sujetas a la aprobación de Protransporte.


Después de la correcta instalación del equipo, el Proveedor debe realizar una prueba operacional completa. Todas las características operacionales del equipo instalado en cada lugar deben ser probadas para asegurar el que el funcionamiento se adecue al especificado, incluyendo las interfaces entre los equipos de Control y recojo de datos. Una vez terminada la instalación, todos los componentes incluyendo los servidores de datos y el sistema central, deben ser probados como un sistema integrado. Todas las interfaces y funciones de integración deben ser probadas para verificar la correcta operación del sistema instalado como un todo.

El Proveedor debe informar a Protransporte, por escrito, de cualquier falla o condiciones inaceptables durante las pruebas de instalación. Todas las fallas detectadas durante el período de aceptación deben ser analizadas por el Proveedor. El Proveedor debe ser responsable de tomar las acciones correctivas que aseguren el correcto funcionamiento del sistema integrado.

El Proveedor debe informar a Protransporte acerca de la programación de alguna prueba o inspección en algún sitio en particular con una anticipación mínima de 72 horas. Protransporte se reserva el derecho de especificar y/o realizar inspecciones y pruebas de instalación adicionales a las identificadas por el Proveedor en el Plan de Pruebas y Procedimientos. Los reportes de inspección y pruebas deben ser aprobados por Protransporte. La finalización de esta etapa de pruebas es requisito para pasar al servicio activo y remunerado.

4.3.5.2 Pruebas de Aceptación

El período de pruebas de aceptación comenzará al inicio de las operaciones de servicio activo y remunerado. Las Pruebas de Aceptación deben ser conducidas por el Proveedor y estarán sujetas a la aprobación de Protransporte.

Las pruebas de aceptación deben ser realizadas a nivel de sistema, después del comienzo del servicio activo y remunerado, con todos los componentes y subsistemas completamente funcionales, operacionales, en línea y en servicio. El Proveedor debe brindar a Protransporte un Plan de Pruebas de Aceptación de Sistema (LRDC 33). El Plan debe ser un documento detallado y con contenido referente a todas las partes componentes del sistema, en el que se describa los procesos de administración, monitoreo, reporte y almacenamiento de datos que determinarán el período de pruebas de aceptación. El Plan de Pruebas de Aceptación debe ser remitido para aprobación a Protransporte con anterioridad al comienzo del período de Pruebas de Aceptación. Protransporte se reserva el derecho de realizar cambios a este documento como sea requerido o juzgado necesario para alcanzar y evaluar los objetivos de desempeño.


4.3.5.2.1. Requerimientos de Sistema

Durante los tres períodos de pruebas de aceptación se deben monitorear las funciones de transferencia de datos y la exactitud e integridad de datos. El sistema debe cumplir con los requerimientos de exactitud y disponibilidad definidos en el presente documento. Protransporte debe ser informado, por escrito, de cualquier falla en el cumplimiento de estos requerimientos. El Proveedor debe tomar acciones correctivas para solucionar tales fallas. Cualquier falla del sistema o condiciones que no se ajusten a los requerimientos de exactitud y disponibilidad del Contrato y/o que no sean reportados por el Proveedor estarán sujetos al reinicio del período de pruebas de aceptación.

4.3.5.2.2. Requerimientos de los Dispositivos

Puesto que el sistema COSAC será puesto en marcha en un mínimo de dos fases, las pruebas de aceptación de los dispositivos también deberá ser llevada a cabo en fases. El Proveedor puede elegir agrupar los dispositivos por Operadores, por tipos de dispositivos de todo el sistema, o algún otro agrupamiento, previamente aprobado por Protransporte, para propósitos de realización de pruebas. Los cálculos de confiabilidad para un tipo de dispositivos en particular debe incluir a todos los dispositivos de un tipo particular en ese grupo durante el período de pruebas d aceptación. La agrupación de los dispositivos para las pruebas de aceptación debe ser descrita en detalle en el Plan de Pruebas de Aceptación (LRDC 33) del Proveedor, y estará sujeta a la aprobación de Protransporte. Cada grupo debe estar sujeto a los siguientes requerimientos para las pruebas de aceptación.

Al final del período de establecimiento, el Promedio de Transacciones Entre Fallas (PTEF) para dispositivos del mismo tipo y grupo con capacidad de procesar un alto volumen de transacciones debe ser no menos que el 40% del PTEF presentado durante la etapa de diseño para cada dispositivo, equipo o subsistema a ser probado. Si una vez terminado el tiempo de establecimiento no se alcanza el criterio de PTEF antes mencionado se debe monitorear la confiabilidad del equipo hasta que se cumplan los criterios PTEF por 30 días consecutivos. Las pruebas de aceptación no deben comenzar hasta que estos requerimientos hayan sido cumplidos.

Al finalizar el período de establecimiento, las pruebas de aceptación deben empezar y ser desarrolladas por un mínimo de 180 días bajo condiciones de servicio actual y remunerado.

Los requerimientos de PTEF y las horas promedio de operación durante las pruebas de aceptación deben ser incrementadas gradualmente desde los valores del período de establecimiento en períodos consecutivos de 60 días, como sigue:


0-60 días: 60% del PTEF y horas promedio de operación entre fallas especificadas

61-120 días: 80% del PTEF y horas promedio de operación entre fallas especificadas.

121-180 días: 100% del PTEF y horas promedio de operación entre fallas especificadas.

Para cualquier grupo en particular, si después de 60 días consecutivos el PTEF y horas promedio de operación entre fallas para ese período no han sido cumplidas las pruebas de aceptación deben continuar por otros 60 días consecutivos hasta que el equipo alcance los requisitos aplicables de confiabilidad.

Si el equipo no cumpliera con los requisitos especificados previamente, el Proveedor debe realizar cualquier mejora necesaria para alcanzar los requerimientos. El Proveedor debe continuar realizando mejoras hasta que se alcancen los requisitos contractuales.

El cumplimiento de las pruebas de aceptación debe ser prerrequisito para la aceptación final. Protransporte se reserva el derecho de ser el único juez en la determinación de que los requisitos de pruebas de aceptación cumplan con los requerimientos y objetivos del sistema.


4.4. ADMINISTRACIÓN DE PROGRAMA, PROGRESO Y MONITOREO DE DESEMPEÑO

El Proveedor debe brindar un Plan de Gestión del Programa (LDRC 35) que describa como se gestionará, administrará y controlará el programa de SCC.

4.4.1. REVISIONES DE PROYECTO a) El Proveedor debe participar en revisiones regulares de ingeniería y status con

Protransporte y sus consultores, y debe proveer reportes detallados del progreso del proyecto, comenzando con la concesión del Contrato y a lo largo de las fases de Operación y Mantenimiento del Contrato.

b) Estas revisiones deben ser llevadas a cabo mensualmente o tan seguido como sean juzgadas necesarias por Protransporte, dependiendo de la fase y progreso del proyecto.

4.4.2. REPORTE DE STATUS El formato final de un reporte de status que agrega las entradas de todas las partes involucradas, debe ser acordado entre Protransporte y el Proveedor, inmediatamente después de la concesión del Contrato. EL Proveedor debe entregar reportes de status mensuales a Protransporte. A continuación se presenta un ejemplo de tal reporte.

Status Actual General:

Ítems Entregados

Ítems Sobresalientes

Progreso versus Plan de Implementación

Puntos críticos y Solución:

Técnica

Administrativa

Financiera

Contractual

Otras Legales

Personal

Terceras Partes

Usuario

Otras


4.4.3. REPORTE DE PROBLEMAS a) Adicionalmente a los reportes de status emitidos durante el transcurso del

proyecto, el Proveedor debe implementar un sistema separado de rastreo, solución y reporte de problemas. Se debe proporcionar a Protransporte un registro de rastreo y resolución de problemas como parte de los Reportes de Status. Debe incluir por lo menos lo siguiente:

i) Numeración de los problemas cuando sean reportados, para facilitar el rastreo preciso.

ii) Cada problema debe ser registrado en el día que fue reportado.

iii) El registro debe ser actualizado cuando el status del problema cambie, por ejemplo:

(1) Solución anticipada

(2) Se brindará una fecha de solución

(3) Se brinda una fecha para solución

(4) Fecha en que se probó la solución.

(5) Resultados de la prueba

b) Los problemas no deben ser cerrados hasta que se haya alcanzado una solución que haya sido exitosamente probada y aprobada por la entidad de reportes y otra que sea responsable, como puede ser el Administrador del Proyecto (Protransporte).


4.5. CAPACITACIÓN

4.5.1. GENERAL El Proveedor debe desarrollar y conducir programas para la capacitación del Proveedor, Protransporte, Operadores de Flotas, y otro personal necesario en todos los aspectos relacionados con el equipo, el hardware, equipos de soporte y diagnóstico y software procurado bajo este Contrato. La capacitación debe proporcionar al personal las habilidades necesarias para la operación, mantenimiento y soporte del equipo al nivel más bajo de reemplazo de componentes, y para operar y administrar el SCC.

El Proveedor debe ser responsable por el desarrollo de un programa de entrenamiento que cubra todas las áreas de administración del servicio, habilidades y procedimientos para la operación y mantenimiento para diferente personal del Proveedor. Los parámetros, el enfoque y los materiales para el entrenamiento de personal del Proveedor deben estar sujetos a la aprobación de Protransporte.

Los manuales de capacitación deben referenciar y/o incorporar contenido de los manuales de Operación y Mantenimiento donde sea apropiado. El Proveedor debe ser responsable por el planeamiento, propuesta de fechas y horarios, y conducción de los programas de capacitación para el personal durante la duración del proyecto, incluyendo cursos de capacitación y mejora continua.

Todas las clases de capacitación de Protransporte/Operador no deben tener lugar más de dos semanas previas a la entrega del equipo. Protransporte se reserva el derecho de grabar en video las sesiones de entrenamiento llevadas a cabo por el Proveedor, para su revisión y uso futuro.

4.5.2. PROGRAMAS DE CAPACITACIÓN El Proveedor debe desarrollar y entregar para aprobación de Protransporte un Programa de Capacitación (LRDC 37) comprendiendo tres partes: cursos diseñados para el personal de Protransporte, cursos diseñados para el personal del Proveedor y cursos diseñados para el personal de los Operadores. Los programas de capacitación deben entregarse para aprobación a Protransporte, no después de 15 días de la aprobación del Diseño Final. El Proveedor debe brindar una lista de materiales de capacitación requeridos para cada curso que se incluya en el Programa de Capacitación.


4.6. MANUALES 4.6.1. REQUERIMIENTOS GENERALES El Proveedor deberá abastecer por completo la totalidad de manuales y la documentación requerida para la capacitación en la operación y mantenimiento de todos los sistemas de los Operadores y personal de Protransporte. Todos deberán ser aprobados por Protransporte y serán preparados en el idioma español. El contenido de los manuales deberá cubrir tanto el software y hardware asociado con cada sistema. El Proveedor deberá actualizar los manuales conforme se le requiera durante la vida del Contrato para reflejar todas las configuraciones operacionales en el campo. Los manuales se crearán como documentos “Controlados” y cada manual y versión deberá contener un número único.

4.6.2. COMPONENTES PRIMARIOS DEL SISTEMA El Proveedor deberá proveer, como mínimo, manuales para cada uno de los componentes de los sistemas primarios. Estos incluyen los siguientes:

a) Unidad Lógica

b) Terminal Móvil de Datos

c) Servidores de Datos

d) Unidades de Transmisión Inalámbrica

e) Radios y Radio Modems

f) Sistemas de Cómputo de Garaje

g) Emisores y Receptores de Identificación de Vehículo y Balizas

h) Dispositivos de Control y Monitoreo

4.6.3. TIPOS DE MANUALES Los siguientes manuales tendrán que producirse para los sistemas del SCC.

4.6.3.1. Manual de Operación y Reportes

El Proveedor deberá crear un manual completo para el Manual de Operaciones y Reportes para cada uno de los componentes del sistema. Dichos manuales deberán contener instrucciones y procedimientos detallados para el equipo y sistema de operaciones para el uso de personal de mantenimiento y de operación incluyendo monitoreo y reportes de datos. La información contenida en los manuales deberá ser capaz de mostrar la forma de operación cada uno de los dispositivos y sistemas de manera clara y entendible. Estos manuales están destinados para ser usados por las


diferentes figuras con interacción ya sea con clientes o equipo (i.e., agentes de estación, operadores de sistemas y supervisores de personal.

4.6.3.2. Manuales de Software

El Proveedor deberá proveer manuales de Software para cada elemento del sistema de Protransporte que requiera software, incluyendo el sistema central. La información sensible que no deba ser difundida de manera general deberá ser designada como tal, y entregada en un manual rotulado como “Confidencial”. Los manuales de software deberán cumplir los siguientes requerimientos:

a) Incluir descripciones detalladas, y, diagramas de flujo de proceso del sistema de operaciones si aplica.

b) Proveer procedimientos detallados de los sistemas computacionales, incluyendo diagramas de flujo de sistemas, si aplican, para operaciones como lo son:

i) Arranque del Sistema ii) Activación Base de Datos iii) Búsqueda de información en las Bases de Datos iv) Administración del Sistema v) Seguridad del Sistema vi) Cierre del Sistema vii) Archivos de Base de Datos viii) Generación de Reportes ix) Mantenimiento de Base de Datos x) Restauración el Sistema xi) Carga y descargas de archivos

c) La información debe ser presentada en términos no especializados; la documentación no deberá ser escrita como un documento de programadores.

d) Todos los procesos deberán ser explicados por completo. La descripción de los procesos deberá incluir pantallas de ejemplo y menús de referencia; el resultado esperado de cada proceso; y que parámetros dentro del proceso pueden ser ajustados y el efecto que se puede esperar al modificar variables ajustables.

e) Se deberá proveer un listado de errores, incluyendo la explicación detallada de cada uno. También se deberá detallar el procedimientos necesario para corregir cada error, describiendo los pasos a tomar y el resultado esperado en cada acción.

f) Se deberán proveer ejemplos de los reportes y búsquedas. Los ejemplos deberán estar rotulados y acompañados de un texto explicatorio que incluya, pero no se limite, al propósito, frecuencia, definiciones de campos, valores de código, y cálculos internos.


4.6.3.3. Otros Manuales Requeridos

Los manuales también tendrán que ser preparados y entregados a Protransporte para su aprobación:

• Manual de Diagnóstico & Evaluación del Equipamiento & Manual de Herramientas Especiales

• Catálogo Ilustrado de Partes

4.6.4. DISEÑO Y FORMATOS GENERALES Los Manuales, incluyendo esquemas, diagramas de flujo, y procedimientos de solución de problemas deberán estar escritos de manera clara y deberán ser fáciles de interpretar. Los diagramas, vistas explotadas, ilustraciones y dibujos esquemáticos junto con los pasos en los procedimientos deberán ser usados en los manuales para dar descripciones de los componentes y relaciones entre diversos sistemas, subsistemas, montajes, submontajes, y partes.

El Proveedor deberá ofrecer los manuales en medio electrónico en un procesador de texto y formatos de dibujos estándar (i.e. última versión de Microsoft Word o equivalente). Los Manuales para sistemas y aplicaciones soportados en cómputo podrán estar disponibles en línea en dichos sistemas. El Proveedor se deberá responsabilizar por implementar las medidas de seguridad adecuadas para restringir el acceso a documentación contenida en la red, como se considere necesario.

El Proveedor será responsable de la actualización de los manuales a los parámetros vigentes de Protransporte en la eventualidad de que se realicen cambios a los procedimientos operativos y de sistema. Los manuales serán actualizados y recibirán mantenimientos por parte del Proveedor a lo largo de la vigencia del Contrato, y entregarán a Protransporte en tiempo razonable en los formatos especificados anteriormente. Al término del contrato, todos el material, incluyendo las aplicaciones/ documentos basados en red serán propiedad de Protransporte.


4.7. LISTA DE REQUERIMIENTOS DE DATOS CONTRACTUALES (LRDC)

El Proveedor deberá entregar calendarios, reportes, planes, certificados y demás datos listados en el documento de especificación como la LRDC. El Proveedor deberá entregar (10) copias de cada documento LRDC. La aceptación de los documentos LRDC están sujetos a la revisión y aprobación de Protransporte. Los LRDC’s no se considerarán completas hasta que cuenten con la aprobación completa y formal por parte de Protransporte.

Además de los documentos impresos, todas las LRDC’s, incluyendo a los Paquetes de revisión de Datos y material de apoyo, deberán ser entregados en medio electrónico en la última versión de Microsoft Word/Excel o su equivalente.

La Tabla 4.7., ofrece una lista de las LRDC’s requeridas. En la tabla, la columna llamada “Fecha Compromiso” muestra las fechas en que se deben entregar las LRDC’s.

Protransporte permitirá cambios en las fechas compromiso si el Proveedor puede demostrar que la fecha no es consistente con el plan de trabajo. El plan de trabajo propuesto por el Proveedor está sujeto a la revisión y aprobación de Protransporte.


Tabla 4.7. Lista de Requerimientos de Datos Contractuales (LRDC)

LRDC Descripción de Presentación Fecha Compromiso

(Días)

1 Plan Maestro de Implementación del Programa CDR-90

2 Paquete Revisión de Diseño Preliminar (RDP) RDP-30

3 Paquete Revisión de Diseño Final (RDF) RDF-30

5 Plan de Medición del Desempeño del SCC Mensual

8 Plan de Administración de la Red de Dispositivos RDF+30

10 Procesos de Soporte al Usuario RDF+60

11 Medición y Estadísticas sobre el Desempeño del Servicio de Soporte a los Usuarios

Mensual

12 Plan de Mantenimiento RDF+30

13 Procedimiento del Operador de Soporte Telefónico RDF+30

14 Medición y Estadística del Desempeño del Servicio del Operador de Soporte Telefónico

Mensual

15 Especificaciones de Formato de Mensajes y Datos RDF+30

16 Interfaz de Comunicación RDF+30

17 Plan de Proceso de Respaldo de Datos RDF+30

18 Plan de Transmisión Inalámbrica de Datos RDF+30

19 Determinación de Plan de corridas y rutas RDF

21 Reporte de Compatibilidad Electromagnética RDF+60

23 Formatos de Reportes RDF

24 Metodología de Medición de Disponibilidad del Sistema

RDF+30

27 Reporte de Aceptación y Pruebas A petición


LRDC Descripción de Presentación Fecha Compromiso

(Días)

28 Plan del Programa de Garantía de la Calidad APP+30

29 Plan de Pruebas e Inspección General RDF

30 Procedimientos Detallados de Pruebas RDF

31 Documentación de la Inspección de la Configuración del Primer Artículo (ICPA)

PPA-30

32 Reportes de Prueba de Primeros Artículos (PPA) APP+360

33 Plan de Prueba de Aceptación de Sistema RDF+30

34 Proceso de Pruebas de Revisión de Fallas RDF

35 Plan de Gestión del Programa APP+30

36 Reporte Mensual de Progreso o Estatus Mensual

37 Plan de Programa de Capacitación RDF+15

38 Calendario de Manuales Requeridos RDP

39 Manuales de Operaciones y Reportes APP+430

40 Manuales de Reparación y Mantenimiento APP+430

42 Catálogo Ilustrado de Partes APP+430

43 Manuales de Diagnóstico, Prueba de Equipos & Herramientas Especiales

APP+430

44 Manuales de Software APP+430

49 Material de Entrenamiento Fecha del Curso-15

anexo vi - especificaciones del centro de contro · sistema de conteo automático de pasajeros ......

Documents