ITS

ANEXO 3

Bogotá D. C., Noviembre de 2019

 Contenido
1 INTRODUCCIÓN ...................................................................................................................................... 1
2 CONTEXTO ITS Y PRESTACIÓN DE SERVICIOS ............................................................................... 3
3 ESPECIFICACIONES TÉCNICAS DE LOS SUBCONJUNTOS TECNOLÓGICOS DE ITS NO SIRCI
Y SU INTEGRACIÓN CON EL CENTRO DE GESTIÓN................................................................................ 4
3.1 Perspectiva de los subconjuntos Tecnológicos de ITS.......................................................... 4
3.1.1 Funcionalidades del STS - Sistema Tecnológico de Seguridad. .......................................... 4
3.1.2 Descripción de los otros subconjuntos tecnológicos que interactúan con el STS .......... 7
3.1.3 Subconjunto tecnológico de ITS basado en la telemetría del Bus. ..................................... 9
3.1.4 Subsistema tecnológico de ITS que comprende otros aditamentos para mejor
interacción con el Usuario .................................................................................................................. 10
3.1.5 Transversalidad de los esquemas de transmisión de datos de los dispositivos ITS en
general..................................................................................................................................................... 13
3.2 Requisitos específicos ................................................................................................................. 13
3.2.1 Sistema de Video Vigilancia....................................................................................................... 14
3.2.2 Sensores de Cabina y de Motor................................................................................................. 36
3.3 Otros aditamentos para mejor interacción con el Usuario ................................................ 49
3.3.1 Ruteros ........................................................................................................................................... 49
3.3.2 Panel de Información al Pasajero (PIP) .................................................................................. 54
3.3.3 Amplificador de Sonido ambiente ........................................................................................... 55
3.3.4 Parlantes ........................................................................................................................................ 56
3.3.5 Sistema Tecnológico para la divulgación de información (STDI) .................................... 57
3.3.6 Pantallas Informativas................................................................................................................ 61
3.3.7 Conectividad ................................................................................................................................. 63
3.3.8 Internet en el BUS ........................................................................................................................ 64
3.3.9 Puertos USB................................................................................................................................... 66
3.3.10 Radio ........................................................................................................................................... 67
3.3.11 Requisitos de cumplimiento de estándares de software ............................................... 67
3.3.12 Requisitos de Forma Transversal........................................................................................ 67
4.1 Cronograma de implementación .................................................................................................... 74
4.2 Plan maestro de implementación................................................................................................... 74
4.3 Protocolo de articulación vigente con otros actores ................................................................. 74
4.4 Garantía ................................................................................................................................................ 74

1
 4.5 Documentación Técnica.................................................................................................................... 75
4.5.1 Diseño de alto nivel .......................................................................................................................... 75
4.5.2 Diseño detallado ............................................................................................................................... 75
4.5.3 Implementación de Software y Hardware ................................................................................. 76
4.5.4. Integración y verificación .......................................................................................................... 76
4.5.5 Despliegue inicial del sistema ....................................................................................................... 77
4.5.6 Validación ........................................................................................................................................... 78
4.5.7 Operación y Mantenimiento / Cambios y Actualizaciones..................................................... 78
5 ESQUEMA DE GESTIÓN ITS CON EL STS ........................................................................................ 79
5.1 Sistema tecnológico de seguridad ........................................................................................... 79
5.1.1 Instalación ..................................................................................................................................... 79
5.2 Interoperabilidad......................................................................................................................... 79
5.3 Operación....................................................................................................................................... 80
5.4 Soporte y mantenimiento .......................................................................................................... 80
6 SEGURIDAD ............................................................................................................................................ 81
6.1 Seguridad de la información ..................................................................................................... 81
6.1.1 Autenticación ................................................................................................................................ 81
6.1.2 Autorización para El STS y el STDI .......................................................................................... 81
6.1.3 Validación de ingreso de datos ................................................................................................. 82
6.1.4 Manejo de error / fuga de información del STS ................................................................... 82
6.1.5 Registro de logs y auditoría del STS ........................................................................................ 82
6.1.6 Criptografía ................................................................................................................................... 82
6.1.7 Ambiente seguro de codificación y despliegue .................................................................... 83
6.1.8 Validación y verificación ............................................................................................................ 83
6.1.9 Protocolos de comunicaciones para El STS ........................................................................... 83
6.1.10 Manejo de sesión ..................................................................................................................... 83
7 VALIDACIÓN DEL SISTEMA ............................................................................................................... 85
8 VERIFICACIÓN DEL SISTEMA ............................................................................................................ 89
8.1 Medidas de verificación para las funcionalidades del sistema ......................................... 89
8.1.1 Funcionalidad "Reconocer al conductor" .............................................................................. 89
8.1.2 Funcionalidad " Detección de comportamientos anómalos" ............................................ 90
8.1.3 Funcionalidad " Reportar imagen del rostro del conductor" ............................................ 90
8.1.4 Funcionalidad " Recibir validación del reconocimiento del conductor" ........................ 91
8.1.5 Funcionalidad " Autoajustable de la cámara del conductor " ........................................... 91

2
8.1.6 Funcionalidad " Envió automático de video e imágenes del CCTV" ................................ 91
8.1.7 Funcionalidad " Grabación de video del CCTV" .................................................................... 92
8.1.8 Funcionalidad " Conteo de pasajeros que ingresan y salen del vehículo" ..................... 92
8.1.9 Funcionalidad " Visualización remota de las imágenes del CCTV" .................................. 93
8.1.10 Funcionalidad " Captura de imágenes al exterior del vehículo" .................................. 93
8.1.11 Funcionalidad " Descarga manual de videos del CCTV " ............................................... 94
8.1.12 Funcionalidad "Captura de datos de cabina al encender el vehículo" ........................ 94
8.1.13 Funcionalidad " Reportar los datos del rendimiento del motor y CANBUS" ............ 94
8.1.14 Funcionalidad " Configuración de los rangos de los dispositivos del STS" ............... 95
8.1.15 Funcionalidad " Parametrizar tipos de alertas" ............................................................... 95
8.1.16 Funcionalidad " Registro de alertas" .................................................................................. 96
8.1.17 Funcionalidad " Identificar obstáculos en las maniobras de reversa" ....................... 96
8.1.18 Funcionalidad “Generar alerta por incremento de temperatura del motor del
vehículo" ................................................................................................................................................. 97
8.1.19 Funcionalidad “Reportar aceleración y velocidad del vehículo" ................................. 97
8.1.20 Funcionalidad “Generar alerta por desgaste de las pastillas de frenos".................... 98
8.1.21 Funcionalidad “Detectar el kilometraje recorrido por el vehículo" ............................ 98
8.1.22 Funcionalidad “Anunciar próximas paradas"................................................................... 98
8.1.23 Funcionalidad “Configurar distribución de las pantallas” ............................................. 99
8.1.24 Funcionalidad “Despliegue de información de pantallas” ............................................. 99
8.1.25 Funcionalidad “Control de Acceso al STDI” ...................................................................... 99
8.1.26 Funcionalidad “Sincronización de tiempo en el STDI” ................................................. 100
8.1.27 Funcionalidad “Despliegue de contenido de entretenimiento pregrabado” .......... 100
8.1.28 Funcionalidad “Acceso a Internet de los usuarios” ....................................................... 101
8.1.29 Funcionalidad “Reportar datos del vehículo” ................................................................. 101
8.1.30 Funcionalidad “Integración de los elementos ITS” ....................................................... 102
8.2 Medidas de verificación para las no funcionales................................................................ 102
8.2.1 Requisito no funcional “Respaldos de información” ......................................................... 102
8.2.2 Requisito no funcional “Capacidad del canal de comunicaciones” ................................ 103
8.2.3 Requisito no funcional “Respaldo de energía”.................................................................... 103
8.2.4 Requisito no funcional “Latencia para transacciones y escritura” ................................ 104
8.2.5 Requisito no funcional “Capacidad de almacenamiento del CCTV”............................... 104
8.2.6 Requisito no funcional “Confiabilidad del CCTV”............................................................... 105
8.2.7 Requisito no funcional “Disponibilidad del CCTV” ............................................................ 105

3
 8.2.8 Requisito no funcional “Claves de las cámaras del CCTV de los vehículos” ................ 105
8.2.9 Requisito no funcional “Ciframiento de la información del CCTV”................................ 106
8.2.10 Requisito no funcional “Protección contra acceso físico al CCTV” ............................ 106
8.2.11 Requisito no funcional “Capacidad de operación del CCTV” ...................................... 107
8.2.12 Requisito no funcional “Control de acceso al STS” ........................................................ 107
8.2.13 Requisito no funcional “Conexiones TLS al STS” ........................................................... 108
8.2.14 Requisito no funcional “Acceso restringido al almacenamiento del STS” ............... 108
8.2.15 Requisito no funcional “Tratamiento de datos personales” ....................................... 109
8.2.16 Requisito no funcional “Transacciones atómicas” ........................................................ 109
8.2.17 Requisito no funcional “Protocolo port knocking” ........................................................ 109
8.2.18 Requisito no funcional “Trazabilidad y auditoría” ........................................................ 110
8.2.19 Requisito no funcional “Confiabilidad de sensores de motor y de conducción del
vehículo” ............................................................................................................................................... 110
8.2.20 Requisito no funcional “Disponibilidad de sensores de motor y de conducción del
vehículo” ............................................................................................................................................... 111
8.2.21 Requisito no funcional “Confiabilidad de sensores de cabina del vehículo” .......... 111
8.2.22 Requisito no funcional “Disponibilidad de sensores de cabina del vehículo” ........ 112
8.2.23 Requisito no funcional “Notificación alerta al Centro de Gestión” ............................ 112
8.2.24 Requisito no funcional “Confiabilidad pantallas STDI” ................................................ 113
9 LUGARES DE ESTACIONAMIENTO DE LOS BUSES .................................................................... 113
10 RENOVACIÓN, INSTALACIÓN Y MANTENIMIENTO DE EQUIPOS .......................................... 114
10.1 Instalación ................................................................................................................................... 114
10.2 Renovación .................................................................................................................................. 115
10.3 Mantenimiento ........................................................................................................................... 115
10.4 Reposición y disposición .......................................................................................................... 115
11 ACUERDOS DE NIVEL DE SERVICIO .............................................................................................. 117
11.1 Administración de Servicio ......................................................................................................... 117
11.2 Alcance del Mantenimiento ......................................................................................................... 117
11.3 Políticas de Mantenimiento ......................................................................................................... 118
11.4 Política general ............................................................................................................................... 118
11.5 Reemplazo de partes..................................................................................................................... 119
11.6 Modificaciones ................................................................................................................................ 119
11.7 Mantenimientos programados ................................................................................................... 120
11.8 Mantenimientos preventivos ...................................................................................................... 122
11.9 Canales de atención ....................................................................................................................... 124

4
 11.10 Tiempos de respuesta y de solución ....................................................................................... 124
11.11 Indicadores de niveles de servicio STS y STDI ..................................................................... 129
11.12 Gestión de incidentes del servicio ........................................................................................... 136
11.13 Entrega de los equipos ............................................................................................................... 136
Glosario y Abreviaturas ............................................................................................................................. 138

5
1 INTRODUCCIÓN

El presente documento aborda el anexo técnico de Sistemas Inteligentes de Transporte o ITS1

y se exponen las características, funcionalidades y requerimientos mínimos de los equipos de
ITS que estarán a bordo de los diversos tipos de buses en aras de prestar servicios a los usuarios
del sistema, es decir, las personas que tienen el rol de pasajeros e incluso para el conductor. Se
evidencia desde la parte técnica que el Concesionario de Provisión y el Concesionario de
Operación, deben articularse de la mejor forma para trabajar armónicamente y
mancomunadamente, y deberán presentar al Ente Gestor dentro de los veinte (20) días hábiles
siguientes a la suscripción del acta de inicio, los documentos explicativos con información
detallada acerca de planes y acuerdos entre el Concesionario de Provisión y el Concesionario
de Operación, donde, se evidencien métodos claros de despliegues de instalación, reinstalación,
reparación, reposición, renovación y mantenimiento de los equipos por tipología de buses a
vincular, así como el plan de pruebas claro que reúna los elementos técnicos suficientes que
generen escenarios de interoperabilidad, compatibilidad e integración bajo esquemas de
servicios. Se resalta que por iniciativa propia de los dos concesionarios deben alcanzar un
escenario de articulación entre ellos. Por otra parte, El Ente Gestor o quien este disponga,
genera escenarios de medición de resultados para los alcances esperados y la ejecución del
proyecto, sin desestimar que existirá una responsabilidad exclusiva del Concesionario de
Provisión para la instalación de los ITS y del Concesionario de Operación para el mantenimiento
y operación del ITS.

En términos técnicos se informa que algunos equipos ITS abordo están conformados por los
dispuestos en el (los) contrato(s) del SIRCI2 o quien haga sus veces y por tanto las definiciones
son las establecidas en los mismos.

Para los equipos ITS NO SIRCI, El Ente Gestor toma de base tres subconjuntos de escenarios
tecnológicos de ITS, (i)el primero está alineado a las nuevas disposiciones del gobierno nacional
en cuanto a lo que expone la ley 1801 de 2016 (Código Nacional de Policía y Convivencia) a
partir del artículo 146 (parágrafo 2) en referencia a contar o disponer de sistemas de video
vigilancia al interior de los buses (denominado esto, como sistema tecnológico de seguridad –
STS3,). (ii) el segundo subconjunto tecnológico de ITS está asociado a los sensores de cabina y a
la telemetría del vehículo (articulado a las variables que pueden ser extraídas de las unidades
de control electrónico del vehículo), (iii) el tercer subconjunto tecnológico de ITS se relaciona
con otros aditamentos para mejorar la interacción con el usuario. De forma transversal un
elemento clave de todo el proyecto es el esquema de transmisión de datos que se abordará en
cada uno de los subconjuntos ITS. Es importante precisar que, aunque se hayan establecido tres
subconjuntos tecnológicos de ITS, estos coexistirán e interoperaran de forma orquestada y

1 ITS: Intelligent Transportation Systems

2 SIRCI: Sistema Integrado de Recaudo, Control e Información y Servicio al Usuario
3 STS: sistema tecnológico de seguridad

1
entre ellos, lo cual debe tenerse en cuenta para los esquemas de funcionamiento de los
elementos ITS – NO SIRCI de los buses.

Por otra parte, se precisa destacar que a partir de lo que se describe en la ley 1801 de 2016, El
Ente Gestor, está alineado a disposiciones técnicas asociadas a la forma de desplegar ITS en el
mundo, por ello, la entidad acoge la norma ISO4 14813-1, en lo que respecta al dominio de
gestión de tráfico y operaciones, al dominio de seguridad nacional y al dominio de sistemas de
transporte público y en este sentido, el STS de los buses no troncales objeto del presente
proceso atenderá inicialmente estos propósitos.

Para llevar a cabo este esquema operacional, se afirma que El Ente Gestor dispondrá de un
Centro de Gestión para recibir y procesar la información proveniente de cada bus en cuanto a
los temas del STS y los demás subconjuntos tecnológicos de ITS descritos.

Se precisa afirmar que tanto el Concesionario de Provisión como el Concesionario de Operación,

deben validar por su cuenta y riesgo los requerimientos aquí definidos y complementar los
elementos que a su criterio considere necesarios, teniendo de referencia la articulación con El
Ente Gestor para que, en función del sistema general, sea posible atender las necesidades
incluyendo los niveles de servicio exigidos en el contrato.

4 ISO: Organización Internacional de Normalización” (“International Organization for Standardization”, en inglés

2
2 CONTEXTO ITS Y PRESTACIÓN DE SERVICIOS

Como se expuso a partir de la introducción, este anexo contiene, las funcionalidades mínimas
de los subconjuntos tecnológicos de ITS – No SIRCI y ha sido construido con base en la
metodología que está fundamentada en el estándar internacional para el desarrollo de
sistemas5 ISO/IEC/IEEE 29148-2011 (Systems and software engineering – Life cycle processes
– Requirements engineering) y en el Modelo de Desarrollo en V propuesto en el documento
“Systems Engineering Guidebook for Intelligent Transportation Systems”. El modelo de desarrollo
en V define no sólo el proceso de especificación-diseño-desarrollo, sino que también incluye los
procedimientos de validación, homologación y verificación de las especificaciones y diseños;
razón por la cual el Concesionario de Provisión y el Concesionario de Operación deberán
cumplir lo establecido en la norma citada, y presentar los soportes técnicos necesarios de
acuerdo con los requerimientos estipulados en este documento, siguiendo los estándares para
el planteamiento adecuado de las soluciones y servicios ITS.

Cuando se expone la palabra prestación de servicios ITS debe establecerse que esto es un
parámetro cuando la solución ITS se ha desplegado y está operativa y tiene la capacidad de
generar información ya sea hacia el propio prestador del servicio como hacia terceros que
deseen usarla. Para lo anterior, se requiere que en los términos de prestación de servicios se
desarrollen y se documenten los end-ponit (Diccionario de datos y demás esquemas de
interoperabilidad con el Centro Gestión) respectivos para que sea viable el tránsito y consumo
de información de un lugar a otro. Es de tener en cuenta, que El Ente Gestor brindará los
lineamentos necesarios respectivos para el consumo de servicios ofrecidos por el sistema ITS.

5 Tomado desde la FHWA (https://ops.fhwa.dot.gov/publications/seitsguide/seguide.pdf)

3
3 ESPECIFICACIONES TÉCNICAS DE LOS SUBCONJUNTOS TECNOLÓGICOS DE ITS NO
SIRCI Y SU INTEGRACIÓN CON EL CENTRO DE GESTIÓN

A continuación, se presentan las necesidades a ser cubiertas por parte de los proponentes en
materia de los subconjuntos de equipos ITS – No SIRCI, subclasificados como (i)Sistema
Tecnológico de Seguridad – STS, (ii) Sensores de cabina, Sensores de Motor, y (iii) otros
aditamentos para mejorar la interacción con el usuario, y su respectivo esquema de transmisión
de datos para cada uno de estos subconjuntos). Adicionalmente, se darán las directrices de
integración con el Centro de Gestión que determine El Ente Gestor para el consumo de servicios
ITS de los equipos.

Cabe resaltar que el Concesionario de Provisión debe asumir esquemas de validación donde
son incluyentes escenarios de: suministro de equipos, instalación, configuración, y como más
relevante, las pruebas individuales y conjuntas entre los distintos equipos y actores a que haya
lugar, todo esto, deberá contar con planes de articulación adecuados, coherentes y medibles,
que deberá ser presentado al Ente Gestor dentro de los veinte (20) días hábiles posteriores a la
firma del acta de inicio, con el fin de tener los elementos de control del proyecto. Por lo anterior,
todo equipo ITS deberá contar con esquemas de validación y pruebas antes de la vinculación y
durante la operación en aras de obtener resultados individuales y resultados en conjunto con
los otros equipos que operen de forma simultánea, esto debe evidenciar la operatividad y el
funcionamiento satisfactorio de los equipos.

3.1 Perspectiva de los subconjuntos Tecnológicos de ITS

Teniendo de referencia los subconjuntos tecnológicos de ITS descritos, a continuación, se

desglosan y se especifica su funcionalidad.

3.1.1 Funcionalidades del STS - Sistema Tecnológico de Seguridad.

El STS está destinado a satisfacer los esquemas de seguridad y calidad del servicio, para ello, se
requiere la incorporación de diversidad de equipos tecnológicos (hardware/Software) a bordo.

3.1.1.1 Interfaces del STS

El STS debe incorporar las siguientes interfaces mostradas en la lista, debe cumplir con el modo
de operación descrito y tener en articulación, la perspectiva que tiene El Ente Gestor con
respecto al Centro de Gestión. Las interfaces y otros elementos para considerar por parte del
STS son:

• Interfaz con el conductor

• Interfaz con el Centro de Gestión que determine El Ente Gestor.
• Interfaz con el hardware/software del vehículo
• Interfaz de Comunicación (esta hace parte del subconjunto tecnológico de ITS
transversal de transmisión de datos)
• Modos de Operación
• Perspectiva del STS y el Centro de Gestión

4
Nota: Se resalta que desde el punto de vista de instrumentación el STS debe estar en la
capacidad de recibir datos desde: los sistemas de video vigilancia, de los sensores de cabina y
sensores de motor (esto puede o no concentrarse en el STS, es decir, puede existir un elemento
de hardware/software alternativo pero debe tener articulación con el STS y enviar la
información al Centro de Gestión); y de otros sistemas que se consideran importantes para la
operación de los buses no troncales que harán parte de la nueva flota de Transmilenio (todos
estos serán descritos más adelante).

A continuación, se describen las interfaces de forma general:

3.1.1.2 Interfaz del conductor

El STS debe de tener una interfaz básica con el conductor, es decir, una interfaz que le permita
articular las funcionalidades de alertas y la de recibir la información cuando el conductor pulse
el botón de pánico, de tal forma que se pueda llevar a cabo la alarma que el conductor considere
dependiendo de la situación presentada al interior del Bus. Adicionalmente, el STS debe estar
en la capacidad de registrar y llevar un historial de eventos cuando sea presionado este botón
y almacenarlo en el STS. Adicionalmente, al habitáculo del conductor se le dispondrá una
cámara en aras de determinar algunos comportamientos de parte del conductor (todos estos,
descritos más adelante). Esta interfaz debe incluir la visualización de la cámara trasera del bus
en aras de que sea posible la realización de maniobras en el bus donde el conductor pueda tener
mayor ángulo visión. Se resalta que el concesionario de provisión podrá articularse con las
pantallas que hacen parte del SIRCI si asi se considerase o haya viabilidad técnica en su defecto,
este deberá desplegar un elemento para la visión de esta cámara de forma que, el conductor
pueda ver adecuadamente lo que sucede en la parte trasera, solo cuando este la reversa
activada.

3.1.1.3 Interfaz con el Centro de Gestión

El STS dadas sus capacidades de comunicación enviará información en tiempo de operación al

Centro de Gestión que determine El Ente Gestor, esto deberá realizarse en un formato de
intercambio de información estándar donde sea claramente parametrizable la trama de datos
para ser usada por diversidad de aplicaciones. Esta trama deberá revisarse con El Ente Gestor
de tal forma que se articulen todos los diccionarios de datos en toda la flota y sin tener
diferencias en la forma de los datos ya que todos deben generar parámetros de integración e
interoperabilidad.

El detalle de la trama será entregado por parte del El Ente Gestor con el acta de inicio,; no
obstante, El Ente Gestor podrá redefinir/modificar/incorporar la trama de datos, en especial,
si hay nuevos elementos en el momento que lo considere El Ente Gestor, siendo de obligatorio
cumplimiento los ajustes pertinentes por parte del concesionario sin costo alguno para El Ente
Gestor. Se resalta que el anexo de trama se articula al esquema de servicios y debe ser posible
la incorporación de nuevos campos y el manejo homogéneo del diccionario de datos.

3.1.1.4 Interfaz con el hardware/software del vehículo

5
Dado que los vehículos presentan diversos sensores (entre ellos: de cabina y de motor) en su
interior y equipamiento de hardware, se debe contar una interfaz para el STS donde se integre
la información para su envió en línea y exacto al momento de ocurrir al Centro de Gestión que
determine El Ente Gestor. Todo esto debe hacerse en una trama común en aras de tener
articulada la data que llega desde el STS y que, servirá para diversos propósitos de gestión al
interior del Ente Gestor.

Igualmente, el STS debe implementar un módulo para realizar los cálculos de la forma de
conducción y activación de mecanismos de control a bordo. Por lo anterior, se deja a discreción
del Concesionario de Provisión, la instalación de un módulo de hardware/software que apoye
exclusivamente estos procesos, aunque esto puede realizarse también de acuerdo con las
características de hardware/software del STS. No obstante, por ningún motivo se debe dejar de
cumplir un esquema de diccionario de datos común, independientemente de lo que sea
instalado y de su forma de operación.

3.1.1.5 Interfaz de Comunicación

El STS debe emplear protocolos y canales seguros para el intercambio de información con otros
actores a través del Centro de Gestión y los usuarios que este autorice, y en el/los sitio/s
autorizados por el Ente Gestor según el plan de implementación presentado por los
Concesionarios de Provisión y Operación).

La forma de intercambio de información con el Centro de Gestión será a través de servicios web
bajo túneles cifrados establecidos mediante protocolos seguros de doble vía.

La forma de intercambio de información con los usuarios del STS que descargan información
de los videos de vigilancia en el sitio e infraestructura del Concesionario de Operación será a
través de túneles cifrados establecidos mediante protocolos seguros de doble vía.

La interfaz debe poseer un esquema de descarga de los videos del sistema de video vigilancia
en el momento que el vehículo llegue a alguno de el(los) punto(s) autorizados por el Ente
Gestor, autorización que se dará en términos de ubicación basado en cumplimiento a la ley
1581 de 2012. La eficiencia de la descarga de la información de forma general (videos y demás
variables o datos) dependerá del dimensionamiento de tráfico de datos (y lo que considere
pertinente el concesionario de provisión y de operación) en el punto autorizado por el ente
gestor, es decir, se debe tener de referencia el tamaño de la flota y la cantidad de horas de video
que se requieran descargar. Por lo anterior, es una responsabilidad exclusiva del concesionario
de provisión y operación garantizar unos niveles de eficiencia en términos de descarga en los
sitios autorizados y en caso de que el vehículo este en operación, esto deberá, en términos de
canal de comunicación, ser suficientes para la transmisión de video en tiempo real desde la flota
hacia el centro de gestión siempre y cuando el botón de pánico sea presionado. Por otra parte,
se recuerda que el STS debe actuar en video transmisión bajo demanda cuando se oprime el
botón de pánico, momento en el cual se debe desplegar en los ruteros, y de forma automática
un mensaje de alerta predefinido por el Ente Gestor.

Por último, el STS deberá contar con un esquema de transmisión en tiempo real cuando exista
alguna alarma de video analítica sobre la cámara que apunta al conductor.

6
3.1.1.6 Modos de operación

El STS, debe estar operativo de forma ininterrumpida mientras el vehículo este encendido y en
operación debe contar con sistemas de respaldo energético. Igualmente, si alguna situación de
desconexión eléctrica llegase a suceder, o pérdida de conexión con el sistema de
comunicaciones, esto debe ser reportado inmediatamente al Centro de Gestión. En este sentido,
el STS debe contar con un sistema en Batch para que, al momento de una pérdida de conexión
del sistema de telecomunicaciones, el STS continúe almacenando información y pueda, en su
caso y si es requerido, enviar la información que almacenó durante ese momento al Centro de
Gestión.

Nota: Restricciones de memoria. Debido a que el STS realiza una moderada transaccionalidad
con diverso equipamiento (sistema de videovigilancia, sensores de cabina y de motor, y otros
equipos ITS), debe contar con una infraestructura de hardware suficiente en términos de
memoria y almacenamiento para articular los procesos que este lleva y las articulaciones con
otros elementos, así como un procesador suficiente para llevar los diversos cálculos o procesos
que se requieran de forma paralela, debe incluir por ejemplo, la atención incluso de múltiples
hilos, al momento de realizar procesos paralelos, por ejemplo, de grabación simultánea.
Igualmente, este procesador debe en paralelo, atender otras funcionalidades o tener la
capacidad de manejar interrupciones por hardware (u otro esquema) donde sea posible
atender otras necesidades, esto último, es dependiente de la solución tecnológica utilizada. Se
resalta independientemente de lo que se realice en hardware/Software, nuevamente, se debe
articular todo mediante diccionarios de datos homogéneos para el envío de información al
Centro de Gestión. Se destaca que el STS debe ser capaz de almacenar toda la información de
forma local (usando memoria de estado sólido tipo flash).

3.1.1.7 Perspectiva del Centro de Gestión

El Centro de Gestión para el STS es la forma de como El Ente Gestor articula la nueva
información que la entidad requiere del nuevo equipamiento ITS del Bus, entre otros equipos
de ITS. El Centro de Gestión estará a cargo del Ente Gestor, o por quien este designe. Dentro de
este esquema, se requiere que los equipos que tienen la funcionalidad de actuar o hacer parte
del STS requieren instalación, configuración y pruebas, por lo que el Concesionario de Provisión
y el Concesionario de Operación deberán articular los procesos derivados de estos esquemas
operativos, y así mismo deberán ser contemplados en los planes de trabajo presentados al Ente
Gestor y donde sean establecidos indicadores claros que arrojen puntos medibles de equipos
instalados, en funcionamiento y probados tanto de forma local como remota hacia el Centro de
Gestión. Se resalta que el corazón del sistema de videovigilancia es el STS por lo que debe estar
siempre operativo y funcionando adecuadamente y exportando los servicios a que haya lugar.

3.1.2 Descripción de los otros subconjuntos tecnológicos que interactúan con el STS

A continuación, se describen los otros subconjuntos tecnológicos de ITS y que son de relevancia
para el esquema de servicios ITS que son requeridos por El Ente Gestor.

Como se describió en la nota referente al apartado de interfaces (3.1.1.1), se destaca que el STS
es un elemento computarizado que articula información de diferentes fuentes, ya sean sensores

7
u otros equipos o incluso, información de instrumentación del vehículo a partir de los sensores
de cabina y sensores de motor, sistema de videovigilancia o posiblemente de otros aditamentos
para interacción con el usuario.

A continuación, se describe más específicamente a que se refiere cada sensor y cada sistema,
así como los aditamentos para la interacción con el usuario.

3.1.2.1 Sistema de Video Vigilancia del STS

El vehículo independientemente de su tipología o tamaño, deberá contar con un sistema de

cámaras para su sistema de video vigilancia (CCTV), como mínimo deberá contar con (i) una
(1) para el conductor (esta cámara debe contar con un algoritmo para identificación de rostro
del conductor, en el momento que el conductor este por iniciar la operación en el bus,
paralelamente, debe tener la capacidad de determinar comportamientos concretos del
conductor tales como: microsueños, detección de uso del celular, detección de que el conductor
esté fumando, detección de que el conductor está distraído y no está mirando al frente).
Igualmente, esta cámara debe operar en todo momento mientras el bus este encendido. (ii) Por
otra parte, se requieren desplegar cámaras suficientes al interior de las diversas tipologías de
buses; estas cámaras deben contar con un ancho de lente suficiente para que pueda verse la
mayor parte del bus de forma nítida y así no tener que instalar gran cantidad de cámaras y tener
de referencia en lo posible, lo mínimo en cuanto a puntos ciegos que lleguen a generarse (El
Ente Gestor deberá aprobar si esto se realiza a satisfacción de acuerdo con el número de
cámaras a instalar por bus, para esto deberán generarse esquemas de pruebas que evidencien
la operación del sistema al interior del bus).

(iii) Adicionalmente se requieren la instalación de dos (2) cámaras para monitoreo de eventos
externos al bus: una ubicada en el panorámico o vidrio frontal (dispuesta para análisis de
colisiones y otros usos que son determinados por El Ente Gestor). La otra cámara debe
instalarse en el panorámico o vidrio trasero. Ambas cámaras deben estar grabando todo el día.
Es importante destacar que la cámara del panorámico o vidrio trasero debe enviar su imagen
hacia la interfaz del conductor, ya sea usando un sensor de reversa o mediante la detección del
cambio a la posición de reversa de la transmisión momento en el cual en la interfaz del
conductor debe desplegarse la imagen en tiempo real de lo que muestre la cámara de atrás.
Para la funcionalidad referente al cambio de reversa, se requiere contar con un sensor capaz de
notificar a la interfaz del conductor la activación de la misma para su despliegue.

El STS debe incorporar un sistema de georreferenciación en aras de satisfacer las necesidades

del sistema de video vigilancia en cuanto a identificar la localización para que los videos que
genera este sistema, cuenten con la información de su ubicación. El Ente Gestor, incluso bajo
demanda debe poder acceder a la posición del vehículo cuando lo estime conveniente, bajo
esquemas de diccionarios homogéneos. Igualmente, se requiere contar con un sistema de
identificación de cámaras propuesto por parte del Concesionario de Provisión, y aprobado por
El Ente Gestor según las especificaciones del Centro de Gestión) y de gestión de video (tipo VMS:
Video Management System – Sistema de Gestión de Video) para poder que, mediante momentos
de demanda, sea posible acceder desde el Centro de Gestión a cualquiera de las cámaras del bus
y para ello, el Concesionario de Provisión deberá contar con esquemas de conectividad que

8
satisfagan la necesidad de transmisión de video. Por lo tanto, la solución de conectividad y
ancho de banda debe ser suficiente para soportar la operación de todas las cámaras a que haya
lugar teniendo de referencia su resolución. Igualmente se resalta que, el sistema de gestión de
video (VMS) deberá ser suficiente para acceder a las cámaras dispuestas bajo demanda e
incorporar esquemas estándares de transmisión de video (partiendo desde ONVIF en
consideración de S y G) para su correcto funcionamiento y no tener dependencias con algún
fabricante en particular. Así mismo el sistema de gestión de video (VMS) debe articularse con
el STS y su sistema de almacenamiento en aras de poder recibir la información de todas las
cámaras que componen el sistema e igualmente almacenarla y obviamente, transmitirla cuando
sea requerido en concordancia con los requerimientos que se exponen en este anexo técnico.
Por otra parte, se resalta que, en términos de almacenamiento, la información debe
almacenarse en el STS en articulación con el VMS durante al menos treinta (30) días y teniendo
en cuenta, los términos de calidad y resolución de video dispuestos a lo largo de este anexo.

3.1.3 Subconjunto tecnológico de ITS basado en la telemetría del Bus.

La información que requiere El Ente Gestor para este subsistema está centrada en elementos
ITS como lo son: sensores de cabina y de motor. Estos elementos ITS deben venir desplegados
a lo largo del bus e interactúan con las unidades de control electrónico (ECUs) normalmente a
través del CANBUS o incluso con otros sensores que también están en el CANBUS. Se resalta que
las diversas tipologías de buses que hacen parte de esta licitación deben contar con esquemas
para conexión de todos estos sensores ya sea con interfaces OBD II, J1939, J1708 u otra
dependiendo del esquema del bus. Este subsistema integra información asociada a diferentes
variables que sean parte de la cabina o en otro caso, del motor del vehículo. Así mismo, se
destaca que para El Ente Gestor es transparente si hay que cruzar una información de un sensor
con otro (ejemplo la aceleración del vehículo y detección de frenadas bruscas) para obtener la
información que se requiere, ya que el Concesionario de Provisión debe de estar en la capacidad
de ofrecer esta información en un enfoque basada en servicios y articulado a los diccionarios
de datos para luego ser enviada al Centro de Gestión.

Este subconjunto tecnológico de ITS se relaciona con el componente STS o en su defecto con
otra unidad de hardware/software que este dedicada a este cometido, o que incluso, puede ser
el mismo STS a partir de su robustez teniendo de referencia que debe tener la memoria
suficiente para atender los diversos casos operativos a que haya lugar (esto puede incorporar
esquemas de multihilos en procesamiento para atender diversidad de procesos). Esta unidad
debe cumplir con los esquemas de integración de información de datos que se establezcan
desde el Centro de Gestión. La información debe ser enviada desde el propio sistema y sin
intermediarios desde el Bus hacia el Centro de Gestión del Ente Gestor, es decir, sin pasar por
ningún esquema de nube o algo en medio, simplemente, debe ser enviada de forma directa y no
en raw data, si no, procesada al elemento que haya lugar y que se adecue a los diccionarios de
datos para poder ser enviada al Centro de Gestión. Este subconjunto tecnológico debe entonces
abordar lo siguiente en articulación con la información que pueda extraerse desde la cabina o
sensores del chasis o carrocería y debe estar articulado al STS o al esquema de
hardware/software a que haya lugar, las variables son las siguientes:

9
 • Los momentos en que el vehículo está en reversa
• La temperatura de la cabina.
• Si el conductor lleva o no el cinturón de seguridad abrochado
• Apertura y cierra de Puertas
• Conteo de Pasajeros al cierre de puertas

En referencia a los sensores del motor del vehículo, el STS o el subsistema tecnológico que
apoye el esquema de telemetría debe recibir información sobre lo siguiente:

• La temperatura del motor del vehículo (temperatura del Refrigerante)

• La Velocidad que lleve el vehículo (con generación de un sistema de alertas al Centro de
Gestión que determine El Ente Gestor y que deberá tener realimentación al conductor)
• Desgaste de las pastillas de Frenos
• Aceleración del vehículo y detección de frenadas bruscas
• Revoluciones del motor
• Kilometraje efectivamente recorrido por el vehículo cuando entre y salga de operación
diaria; por lo tanto, se deberá contar con sincronización y articulación al odómetro del
vehículo y de forma paralela, se debe tener en cuenta la funcionalidad del GPS para
obtener los datos también a partir de este elemento, es decir, se debe contar con ambos
datos kilometraje por odómetro y kilometraje por GPS
• Consumos de combustible del vehículo (dependiente de la tecnología del motor del
vehículo, gas diésel, gasolina), para caso de vehículos eléctricos se debe tener en cuenta
los indicadores de nivel de batería y transmitirlos al equipo hardware/software al que
haya lugar, es decir al STS o al dispositivo o unidad que genere la transmisión de datos
para este esquema y posteriormente y de forma automática, transmitirlo al Centro de
Gestión, cada minuto bajo la trama que considere el ente gestor, es decir, siguiendo sus
diccionarios de datos.
• Por último, se destaca que a partir de las variables que se obtienen desde la telemetría
del vehículo debe poder ser posible organizar tales datos, para analizar parámetros de
tipo ambiental de los buses, esto será organizado a posteriori por el centro de gestión
que determine el Ente Gestor por lo que deberá poderse configurar y visualizar un
cuadro de control con las variables que determine el Ente Gestor para este fin.

Nota: Esto será debidamente detallado en el apartado de requisitos específicos e

independientemente del esquema de hardware/software debe articularse a los diccionarios de
datos a que haya lugar para homogeneidad de información en el Centro de Gestión.

3.1.4 Subsistema tecnológico de ITS que comprende otros aditamentos para mejor
interacción con el Usuario

Este subsistema requiere que el vehículo cuente en su interior con otros sistemas que ayudan
a los usuarios en el momento del viaje, así:

10
• El vehículo debe contar con amplificadores de sonido, sus respectivos parlantes y su
cableado (el del sistema de amplificación y el de los parlantes. La cantidad de estos es
dependiente de la tipología del bus) y deben ser suficientes en términos de la longitud
del bus y deben generar la fidelidad suficiente para que los usuarios puedan escuchar
claramente la información de audio/voz que salga de las pantallas de información al
pasajero Paneles de Información al Pasajero (PIP) o la que haya lugar y la que determine
El Ente Gestor.
• Un aditamento importante para desplegar por cada bus es el Panel de Información al
Pasajero (PIP) y el número de Paneles de Información al Pasajero (PIP), deberá ser
suficiente de acuerdo con la tipología del bus, su ubicación y ángulo de visión. La
interfaz de comunicación de este aditamento deberá poder articularse en términos de
transmisión de datos de forma sencilla y deberá poder recibir información basada en
servicios para no tener dependencias de protocolos propietarios, todo esto a través del
concesionario del SIRCI. Estos Paneles de Información al Pasajero (PIP) deben
desplegar de forma automática, visual y auditiva las próximas paradas que tendrá el
servicio, el destino final, la fecha y la hora actual, y cada vez que se abran las puertas en
una parada, se mencione la parada en la que se encuentra y el destino final; estas
mismas funcionalidades serán para los mensajes que se envíen desde El Ente Gestor o
para información relevante que sea necesaria que los usuarios conozcan.
• Los ruteros deben tener la funcionalidad de programación manual o automática y esto
debe ir articulado al Sistema Tecnológico de Seguridad (STS) o al hardware/software
que corresponda y al SIRCI a fin de informar automáticamente y de forma prioritaria la
ruta a realizar . A nivel visual deberán cumplir con lo establecido en este anexo y en el
manual de imagen y normas gráficas del Ente Gestor.
• Según la propuesta del concesionario, el bus debe contar con al menos una cartelera
digital para disposición de información, publicidad y mercadeo (monitor de
veinticuatro (24) pulgadas con requerimientos energéticos que pueden ser de ciento
diez (110) voltios alternos (VAC) por lo que se requiere adecuar mediante inversor su
alimentación , o el proponente puede incorporar una pantalla para que funcione a 24
VDC, para todo esto, se deben generar los arreglos físicos de instalación a que haya
lugar, teniendo de referencia los esquemas de protección eléctrica pertinentes para
todos los equipos internos). Esta cartelera debe de ir soportada por un dispositivo
Hardware/Software programable y con conexión remota de acceso cliente y
administrador ya que el contenido estará a cargo del Ente Gestor o de quien este
determine para su operación.
Esta plataforma deberá ser parametrizable desde una interfaz Web, generando así,
facilidad de despliegue de la información georreferenciada. De hecho, esta pantalla debe
mostrar la ruta que sigue el bus o la información que determine El Ente Gestor. Así
mismo, para este dispositivo se debe contemplar un esquema de transmisión de
mensajes para situaciones de emergencias (concientización de los usuarios y medidas
para el comportamiento de los usuarios en emergencias, seguridad vial, entre otras que
se pueden realizar para socialización de lo que determine El Ente Gestor) hacia los
pasajeros del bus. Igualmente, este dispositivo debe presentar diversas formas de

11
 parametrización de información que se despliegue en la pantalla, es decir, manejar por
cuadros la pantalla para ubicar información diversa en esta. La pantalla, de hecho,
puede venir protegida por firmware de tal forma que esto limite su hurto y facilite su
aceptación por parte de los usuarios. Este hardware hace parte del Sistema Tecnológico
de Divulgación de Información (STDI), el cual se expondrá más adelante, así como sus
características técnicas. Adicionalmente a este sistema, debe considerarse la conexión
a Internet por parte de los usuarios de los buses no troncales teniendo de referencia
que no se permitirá el streeming de video, para que no haya un consumo excesivo de
ancho de banda. La navegación debe ser a velocidad suficiente para ofrecer a los
usuarios un buen servicio mientras estos viajan a sus destinos, por ejemplo, puede
aceptarse conexiones a redes sociales, Whatsapp o similares y navegación normal en
Internet limitada por Streeming de video (Realizado esto por configuraciones
específicas de los equipos que controlen el tráfico de datos, apertura y cierre de puertos,
firewall u otra configuración), todo esto, para evitar grandes consumos de datos. Lo
anterior permitirá generar mayores servicios al usuario, de hecho, debe ser posible
parametrizar una interfaz de acceso al STDI. Igualmente, este sistema debe contemplar
un esquema de entretenimiento y debe articularse al menos a una aplicación Web con
la que los usuarios podrán interactuar para el acceso a diversos servicios. En este
sentido, este sistema de entretenimiento local debe poder incorporar la difusión de
contenido pregrabado (películas, documentales, series, u otro, o incluso juegos etc.) y a
su vez debe estar en capacidad de manejar múltiples conexiones por parte de los
usuarios. El sistema debe, mediante al menos una aplicación Web, permitir el control
de acceso a los usuarios que usan los servicios de valor agregado, por ejemplo,
conectarse mediante a una red WiFi propia del bus para que sea posible el consumo de
contenidos de entretenimiento o la información que se determine en consonancia con
el Ente Gestor. Paralelamente, el usuario también debe poder acceder a Internet. Para
el sistema de entretenimiento, se requiere en primer lugar, generar un esquema de
contenidos parametrizable y con capacidad de almacenamiento suficiente para su
despliegue considerando opciones multiusuario (todo esto contemplando esquemas de
VOD server o algo similar con la capacidad suficiente– VOD6). Por último, se debe
considerarse el despliegue de conectores USB de al menos uno por cada silla del
pasajero en aras de ofrecer un sistema de carga para los dispositivos móviles que tenga
el usuario. Estos puertos deberán ser ubicados en partes accesibles para el usuario y su
ubicación deberá ser validada por El Ente Gestor. Para esto, el Concesionario de
Provisión deberá considerar qué esquema de infraestructura requiere para las
necesidades descritas, así como su forma de implementación en cada bus. Así mismo, el
Concesionario de Provisión debe ofrecer un canal de transmisión de datos suficiente
para generar estos servicios de forma adecuada.
En cuanto a los requerimientos energéticos para todos estos dispositivos, se requiere
contar con circuitos independientes y protegidos eléctricamente para su
funcionamiento adecuado armonizando todas estas necesidades para tomar en cuenta
todos y cada uno de los elementos que se requieren desplegar.

6 VOD: Video on Demand

12
 • El Concesionario de Provisión deberá tener previsto que El Ente Gestor desplegará un
esquema de centro de emisión radial a lo largo del Sistema Integrado de Transporte
Público, en aras de comunicar novedades, noticias, emergencias, información de
seguridad vial, campañas de concientización o incluso esquemas publicitarios, entre
otros contenidos. Para ello y cuando lo considere El Ente Gestor requerirá que el
Concesionario de Provisión tenga de base este requerimiento en aras de incorporar a
posteriori, un esquema de mini receptor que articule la señal que radiará El Ente Gestor
para este fin a través de portadora o subportadora, como lo considere el ente gestor,
incluyendo las ampliaciones al canal de comunicaciones si fuera necesario y la conexión
al sistema de sonido del bus.

3.1.5 Transversalidad de los esquemas de transmisión de datos de los dispositivos ITS

en general

En cuanto a temas de transmisión de datos, será el Concesionario de Provisión el que estará

encargado de la implementación y despliegue de los equipos ITS quien deberá satisfacer sus
necesidades con canales de comunicación adecuados en ancho de banda y velocidad para que
sus esquemas de hardware/software de todos los elementos aquí descritos de forma inicial
funcionen correctamente. Se reitera que estos canales de comunicación deben ser suficientes
en cobertura y ancho de banda para que permitan la prestación de servicios ITS sin retrasos.
Para poder dimensionar todo esto, se deberán tener en cuenta los tiempos de respuesta de los
equipos que se exponen en los requisitos técnicos específicos y las particularidades de cada uno
de los equipos a utilizar. Además, se debe tener muy en cuenta los tiempos de respuesta para
poder tener sincronías con el Centro de Gestión y los servicios a ofrecer a este, así como sus
servicios bajo demanda.

3.2 Requisitos específicos

En este capítulo se presentan los requisitos específicos identificados para el STS en consonancia
con cada uno de los esquemas de video que deben contemplarse al interior del bus. El STS
deberá ser implementado y desplegado en los vehículos; de acuerdo con los requisitos
específicos de los sistemas abordo con los que interactúa el STS. Se resalta que el STS debe tener
un sistema de georreferenciación de forma general para todo lo que este dispositivo gestionara
y debe tener de base que la información de naturaleza espacial producida por las entidades
públicas y privadas al interior de la nación, es decir, debe cumplir con los estándares y niveles
de precisión establecidos por el ente rector de la información espacial o quién haga sus veces y
que en cuyo caso son el Instituto Geográfico Agustín Codazzi (IGAC) y la Infraestructura de
Datos Espaciales para el Distrito Capital (IDECA) siguiendo los lineamientos establecidos y las
resoluciones y normativas emitidas por dichas entidades.

Se requiere que el Concesionario de Provisión entregue el listado, en su totalidad, de los

servicios web diseñados y que estos sigan las pautas de diccionario de datos que estipule El
Ente Gestor para que toda esta información sea consumida desde el Centro de Gestión de una
manera coherente, para ello, todo esto llevará un esquema de pruebas y verificación.

13
3.2.1 Sistema de Video Vigilancia

En el siguiente apartado se describen los requerimientos funcionales y no funcionales, del

equipamiento ITS relacionado con el sistema de video vigilancia.

Nota: dada la forma de configuración de los CCTV actuales en términos de calidad de imagen, el
sistema CCTV el cual está compuesto por cámaras de video, debe poder ser configurable hasta
30 FPS (frame per second), sin embargo, en este documento aparecen unos mínimos en
términos de operación y esta es la base técnica de los equipos a la cual los proponentes deben
articular sus sistemas. Sin embargo, será a discreción del ente gestor si este desea elevar la
calidad de la imagen, esto será informado y solo se hará en casos especiales que el ente gestor
determine y los sistemas conexos deben estar en la capacidad de soportar esta cantidad de
información, sin que se genere costo adicional para el Ente Gestor. Todo lo anterior, deberá ser
articulado a los sistemas de almacenamiento. Se resalta nuevamente que el sistema debe tener
de base técnica los mínimos pedidos en términos de FPS en los requisitos que se disponen en
este apartado.

A continuación y por términos explicativos se define que es un Punto Ciego, concepto que es
utilizado en este apartado. Un punto ciego se define como un punto sobre un plano horizontal
ubicado a 2,10 m de altura sobre la superficie del piso del vehículo, del cual no se tiene
cobertura visual desde al menos una cámara de CCTV, para efectos del presente anexo que del
mismo se derive, corresponde a un área máxima del 2% conformada por puntos ciegos sobre
dicho plano. Se resalta que el bus de ninguna manera deberá quedarse sin el sistema de video
vigilancia en caso de algún impase, daño o lo que haya lugar, es decir, el sistema no puede estar
conformado por una única cámara y su cantidad estará sujeta a lo que determine la Dirección
Técnica de seguridad de TRANSMILENIO S.A. o quien haga sus veces, con respecto al tamaño
del bus y al mínimo de puntos ciegos (esto es aplicable a todo el contexto del anexo y a las
tipologías de buses que hagan parte de este proceso).

A) Cámara para el Conductor

La cámara del conductor es un elemento de captura de video que permite monitorizar al

conductor del vehículo durante la operación, este video debe ser enviado al Centro de Gestión
cuando suceda alguna incidencia en el bus (por ejemplo: obturación del botón de pánico). El
STS debe almacenar la información en todo momento de lo que suceda en el bus. Igualmente,
esta cámara permite al Centro de Gestión determinar el momento exacto en el que el conductor
inicia y termina su operación, con el fin de regular el tiempo de conducción de cada conductor,
adicionalmente, debe incorporar algoritmos para la detección de rostros, entre otros, sin
depender de acciones directas del operario del vehículo.

Requisitos funcionales

RF001: El STS debe implementar una función para capturar la imagen del rostro del conductor.
Si la cámara no tiene la capacidad de tener el algoritmo de identificación de rostros esta

14
capacidad puede extraerse mediante esquemas de software del STS o puede estar desplegado
esto en el NVR (Network Video Recorder: Grabadora de Video en Red).

RF002: El STS debe implementar una función para determinar los comportamientos anómalos
del conductor tales como: detección de microsueños, detección de uso del celular, detección de
que el conductor está fumando, detección de que el conductor está distraído y no está mirando
al frente.

RF003: El STS debe implementar una función para enviar información al Centro de Gestión,
determinado por El Ente Gestor, y asociada a la imagen del rostro del conductor, tanto al inicio
como al final de la operación. Esta imagen debe ser debidamente procesada y analizada. Para
ello se debe utilizar el procedimiento (servicio web con XML o enfoques REST, ambos con
esquemas de seguridad) establecido por el Centro de Gestión del Ente Gestor para el envío de
esta información. Se resalta que esta información debe seguir los diccionarios de datos
definidos para no tener inconvenientes en términos de interoperabilidad desde los diversos
STS de cada bus perteneciente a la flota zonal.

RF004: El STS debe implementar una función para recibir la validación del reconocimiento del
rostro del conductor por parte del Centro de Gestión asignado por El Ente Gestor. Para esto,
debe utilizar el procedimiento (servicio web con XML o enfoques REST ambos con esquemas
de seguridad) establecido por el Centro de Gestión y tener en cuenta la trama definida para la
recepción de los datos.

RF005: El STS debe implementar una función para realizar la captura de la imagen del
conductor en el momento que se realice el cambio de conductor.

RF006: El STS debe implementar una función para guardar en el dispositivo de almacenamiento
el video e imágenes del conductor cada vez que lo capture mientras el vehículo esté encendido
y cinco (5) minutos más, una vez ha sido apagado.

RF007: El STS debe implementar una función para intentar el reenvío del reporte hasta que sea
exitosa de los datos al Centro de Gestión asignado por El Ente Gestor al momento de presentarse
una falla en las comunicaciones.

RF008: El STS debe seguir el formato XML o esquema REST ambos con seguridad establecido
por el Centro de Gestión asignado por El Ente Gestor para el consumo de los servicios web
destinados para el intercambio de información.

RF009: Las cámaras del conductor deben incorporar un sistema de autoajuste para operación
de día y de noche (visión nocturna) y rango dinámico amplio (WDR) o esquemas minidomo IP
color que atiendan esta necesidad, y de ser necesario, se deberán instalar luces que mejoren la
captura de video.

RF010: El STS debe implementar en el evento que se detecte una cara por un espacio mayor a
un (1) minuto, se requiere que a través de STS se envíe inmediatamente una imagen del rostro
del conductor al Centro de Gestión. Así mismo, el STS debe implementar en el evento de que no
se detecte una cara del conductor, por espacio de un (1) minuto, se debe enviar inmediatamente
una imagen al Centro de Gestión, del puesto del conductor.

15
RF011: La cámara del conductor debe ser ubicada al interior del bus, forma fija para que no
pueda ser manipulada por el conductor mientras este conduce el vehículo.

RF012: La cámara del conductor debe almacenar el video capturado y retenerlo durante al
menos treinta (30) días. Este almacenamiento se debe hacer en el NVR a bordo del bus o como
se considere, pero garantizara en todo momento la cadena de custodia que permita ser fiable
ante una prueba de ley.

RF013: El STS debe implementar una función para enviar al Centro de Gestión asignado por El
Ente Gestor, el video e imágenes del CCTV (esta funcionalidad se incluye también en el apartado
del CCTV) y de la cámara del conductor, sesenta (60) segundos antes del momento en que se
active la alarma de botón de pánico y durante mínimo los siguientes cinco (5) minutos
siguientes (o lo que especifique El Ente Gestor para los dos (2) tiempos mencionados, sin que
en ningún caso implique un costo para el Ente Gestor). Para llevar esto acabo esto, debe utilizar
el procedimiento (servicio web con XML o enfoques REST ambos con esquemas de seguridad)
establecido por el Centro de Gestión del Ente Gestor y enviar la información en la trama definida
por El Ente Gestor. De forma paralela a la transmisión, se deberán rotular las imágenes enviadas
de manera que se pueda preservar la cadena de custodia y de requerirse, que sea posible dar
carácter de prueba de ley. Para casos asociados a seguridad y/o emergencias TMSA se reserva
el derecho de acceder a las cámaras del CCTV y para casos asociados a la calidad del servicio y
operación las solicitudes no excederán una consulta de seis (6) minutos en el quince (15)% de
la flota al mes.

Requisitos no funcionales

• Confiabilidad

RNFS001: Las cámaras del conductor deben tener un tiempo medio entre fallas (MTBF) igual o
superior a sesenta mil (60.000) horas.

RNFS002: El fabricante del NVR deberá haber integrado módulos de hardware con tecnología
4G-LTE que usen bandas y Frecuencias al menos de 3G/4G LTE.

• Usabilidad

RNFS003: Las cámaras del conductor deben operar de forma automática sin intervención
humana mientras el vehículo esté encendido y cinco (5) minutos más una vez el vehículo haya
sido apagado.

• Disponibilidad

RNFS004: Las cámaras del conductor deben tener una disponibilidad diaria de al menos el
noventa y nueve por ciento (99%) durante el tiempo de operación, cumpliendo mínimo los ANS
establecidos en el anexo de niveles de servicio.

RNFS005: El video de la cámara del conductor debe almacenarse en el mismo Video Recorder
(NVR) u otro sistema de almacenamiento con un VMS (Video Management System) del STS del

16
CCTV, con capacidad para treinta (30) días de almacenamiento al menos a 720p o 0.9MP en
color y al menos a 15 FPS (Frames Per Second) con datos de georreferenciación.

RNFS006: Transmisión, si se presiona el botón de pánico, o se presenta una colisión del vehículo
o cuando el Centro de Gestión lo requiera, el video de la cámara del conductor debe ser enviada
al Centro de Gestión con una calidad mínima de 720p y 8 FPS.

Nota: Para garantizar la calidad del canal de comunicaciones, el Concesionario de Provisión

debe realizar un acuerdo estratégico o un contrato de servicio de telecomunicaciones o el(los)
acto(s) que considere pertinente, a fin de brindar las garantías de servicio, con un proveedor
que suministre un canal de comunicaciones con capacidad suficiente (ancho de banda y de
transferencia) para transmitir y recibir de manera permanente los datos requeridos. En este
sentido, es el Concesionario de Provisión, dependiendo del nivel de flota que maneje el
concesionario de operación, quien debe garantizar a partir de la cantidad de sus equipos
instalados en los buses, que el canal de comunicaciones cumpla y es suficiente con lo que se
requiere desde El Ente Gestor (para su Centro de Gestión) y este, es decir El Ente Gestor o quien
este designe, avalará el canal de comunicaciones a partir de algunas pruebas de calidad y
satisfacción de la transmisión de información. El pago del canal de comunicaciones estará a
cargo del Concesionario de Operación. En el caso que se presenten retrasos en la transmisión
y/o recepción de información, es decir, que exista un problema o inconveniente ya que el ancho
de banda no es suficiente u otro problema, El Concesionario de operación bajo las directrices
del Ente Gestor deberá solicitar mejoras al canal de comunicaciones, las cuales deberán
realizarse en menos de seis (6) horas calendario después de la solicitud del Ente Gestor o quien
este designe, de hecho, el concesionario de operación deberá notificar inmediatamente al ente
gestor cuando todo este operativo y se cumpla con el criterio de transmisión y/o recepción de
información lo cual será validado por el ente gestor, y al mismo tiempo, si el canal continua con
inconvenientes, el concesionario de operación deberá estar informado permanentemente la
situación del canal de comunicaciones como mínimo cada 20 minutos y si se recupera el canal
de transmisión o recepción de información antes de los 20 minutos, se debe notificar su estado
inmediatamente al ente gestor. Si el problema persiste más allá de las 6 horas el concesionario
de operación deberá tomar las medidas necesarias para articularse en términos de operación y
hacer uso de la flota de reserva para solucionar el problema, si fuese el caso de algún daño de
hardware. En otro caso si el problema es de la red general de telecomunicaciones se deberán
presentar los soportes para tal fin y será el ente gestor quien determine que directrices seguir
para los términos de operación del sistema.. Así mismo, puede ser posible que el Concesionario
de Provisión cuente con una red virtual propia para enfrentar esta funcionalidad, en cuyo caso,
corresponderá al Concesionario de operación, adelantar las gestiones con el concesionario de
provisión para las mejoras a que haya lugar, antes del tiempo indicado.

Si durante el tiempo que dure la indisponibilidad, existiera algún evento de seguridad, el

concesionario de operación deberá utilizar los otros mecanismos de comunicaciones con los
que dispone el bus para notificar al Ente Gestor o a quien este determine, la situación. Durante
el tiempo que dure la indisponibilidad también se harán las mediciones de los ANS de ITS, los

17
cuales solo serán exonerados aquellos registros de evidencias de seguridad que se puedan
presentar y que el concesionario de operación allegue en un plazo máximo de veinticuatro (24)
horas calendario al Ente Gestor las grabaciones que se pudieron generar durante el suceso
siempre y cuando se haya pulsado el botón de pánico durante ese suceso lo cual estará
registrado en el STS, si esto no ocurre, se aplicaran los descuentos que arrojen las mediciones
del ANS de ITS durante el tiempo que dure la indisponibilidad, sin lugar a objeciones por parte
del Concesionario de Operación, quien responderá ante las autoridades competentes si hay
lugar.RNFS007: El video de la cámara del conductor debe almacenarse en el mismo NVR7 u otro
sistema de almacenamiento con un VMS (Video Management System: Sistema de
Administración de Video) del STS del CCTV, con capacidad para treinta (30) días de
almacenamiento al menos a 720p o 0.9MP en color, y al menos a 15 FPS (Frames Per Second)
con datos de georreferenciación.

• Rendimiento

RNFS008: Se debe contar con Cámaras IP - protocolo IPv4/v6, estándar IEEE 802.3 AF Tipo 1.
Debe ser compatible con ONVIF profile S/G versión 2.0 o superior, incorporar capacidades de
HTTP, HTTPS, SSL, TLS, QoS, FTP, SFTP, SMTP, SNMP, DNS, NTP, TCP, UDP, IGMP, DHCP, SSH,
etc.

• Seguridad

RNFS009: Deshabilitar el sistema de acceso directo a las cámaras a través de la red interna e
interfaz gráfica, permitiendo únicamente el acceso desde el Centro de Gestión a través del túnel
cifrado en dos vías o a quien El Ente Gestor indique para tal fin.

Especificaciones técnicas del equipo

Característica Especificación técnica

Definición Elemento que permite monitorizar al conductor del vehículo durante la
operación
Objetivo Ofrecer imágenes y video del conductor al Centro de Gestión y su
posterior registro. Así mismo, contar con las funcionalidades descritas
sobre los comportamientos listados anteriormente.
Tipo de cámara Cámara IP - protocolo IPv4/v6, estándar IEEE 802.3 AF Tipo 1. Debe ser
compatible con ONVIF profile S/G versión 2.0 o superior, incorporar
capacidades de HTTP, HTTPS, SSL,TLS, QoS, FTP, SFTP, SMTP, SNMP,DNS,
NTP, TCP, UDP, IGMP, DHCP, SSH, etc..
Resolución 720 o superior a 15FPS y con relación de aspecto de al menos 4:3 y 16:9
Temperatura Capacidad de operar con temperaturas entre -5ºC a +50ºC.
Protección Física Las cámaras deben tener características a prueba vandalismo y con
protección física mínima IP56, el NVR deberá estar ubicado dentro del
vehículo en un lugar de acceso seguro, no visible, donde esté minimizado

7 NVR: Network Video Recorder

18
 Característica Especificación técnica
el daño por posible colisión y con acceso restringido por parte de
usuarios no autorizados.
Disposición La cámara del conductor debe ser ubicada al interior de forma que no
pueda ser manipulada por el conductor mientras este conduce el
vehículo.
Compatibilidad Debe cumplir con las normas de compatibilidad electromagnética EMC
electromagnética clase A o su equivalente.
Almacenamiento El video de la cámara del conductor debe almacenarse en el mismo Video
Recorder (NVR) u otro sistema de almacenamiento con un VMS (Video
Management System) del STS del CCTV, con capacidad para treinta (30)
días de almacenamiento al menos a 720p o 0.9MP en color, y al menos a
15 FPS (Frames Per Second) con datos de georreferenciación.
Interfaces Las interfaces de comunicaciones y suministro eléctrico deberán ser
cableadas y los conectores con características FAKRA o ISO 20860 o de
aviación o equivalente. En caso de no ser instalado por el fabricante del
vehículo o de la carrocería, la cámara del conductor debe contar con
sistema eléctrico independiente, incorporando las protecciones
eléctricas respectivas.
Comunicaciones El fabricante del NVR deberá haber integrado módulos de hardware con
tecnología 4G-LTE que usen bandas y Frecuencias al menos de 3G/4G
LTE.
Seguridad Debe cumplir con los comportamientos establecido anteriormente y
conservar la cadena de custodia en caso de requerimientos de ley

Nota: Para el soporte técnico, todas las cámaras desplegadas en los buses deben ser
implementadas con componentes cuyos fabricantes tengan representación legal en Colombia,
soporte técnico veinticuatro (24) horas al día, trescientos y cinco (365) días al año, con
capacidad de suministro de sus partes en menos de veinticuatro (24) horas. En el caso en el que
los fabricantes no tengan representación legal en Colombia, se exige que el Concesionario de
Provisión cuente con representación en Colombia y certifique que realiza soporte técnico
veinticuatro (24) horas al día, trescientos y cinco (365) días al año, con capacidad de suministro
de sus partes en menos de veinticuatro (24) horas; certificado que deberá ser entregado con la
documentación requerida para la vinculación de cada vehículo.

B) Circuito cerrado de TV (CCTV)

El STS deberá disponer de un circuito cerrado de televisión (CCTV) a bordo de los vehículos.
Este circuito cuenta con cámara/s al interior del bus y es El Ente Gestor quien validará la
cantidad de estas de acuerdo al mínimo de puntos ciegos en aras de recopilar información
valiosa para atender eventualidades en la prestación del servicio, conservando la cadena de
custodia en caso de requerimientos de ley. Este sistema debe estar articulado a un botón de
pánico que en el momento de ser presionado envie el video hacia el Centro de Gestión y
desplegar en los ruteros un mensaje de alarma predefinido por el Ente Gestor. Así mismo, desde

19
el Centro de Gestión debe permitirse el acceso por demanda a las cámaras del CCTV e incluso a
la cámara dispuesta para el conductor.

Requisitos funcionales

RF001: El CCTV debe grabar video cubriendo el interior del vehículo, más la cámara frontal y la
cámara trasera.

RF002: El CCTV debe almacenar el video capturado y retenerlo durante al menos treinta (30)
días, a 720p en color y al menos a 15 FPS (Fame Per Second) con datos de georreferenciación.

RF001: El STS o esquema hardware/Software de CCTV debe almacenar el video de las cámaras.
Esto puede llevarse a cabo en un dispositivo como un NVR (Network Video Recorder). La forma
de almacenamiento del video al interior del bus debe ser tipo flash y también para los sistemas
de almacenamiento externo, los lugares para estos sistemas los aprobara El Ente Gestor. Por
otra parte, se requiere también que mientras el vehículo esté encendido debe estar siempre
grabando y debe grabar los cinco (5) minutos posteriores a cuando se apague el vehículo. Se
requiere destacar que en todas estas especificaciones debe contemplarse el manejo de servicios
web en aras de generar esquemas de integración e interoperabilidad siguiendo los diccionarios
de datos que se planteen para todo esto.

RF003: El STS o esquema hardware/Software de CCTV -NVR debe implementar una función
para enviar al Centro de Gestión asignado por El Ente Gestor, el video e imágenes del CCTV y de
la cámara del conductor ya sea, porque se presente una colisión del vehículo o cuando se active
la alarma de botón de pánico. El video que debe ser enviado debe contemplar sesenta (60)
segundos antes del momento en que se oprima el botón de pánico y durante mínimo los
siguientes cinco (5) minutos (o lo que especifique El Ente Gestor para los dos tiempos
mencionados) con una resolución mínima de 8FPS. Para llevar esto acabo, se debe utilizar el
procedimiento (servicio web con XML o enfoques REST ambos con esquemas de seguridad)
establecido por el Centro de Gestión del Ente Gestor y enviar la información en la trama definida
por El Ente Gestor. Por otra parte, de manera paralela a la transmisión, se deberán rotular las
imágenes enviadas y conservar la cadena de custodia para cuando se requiera como prueba
judicial. Por su parte, la cantidad de solicitudes por "demanda", para casos asociados a
seguridad y/o emergencias TMSA se reserva el derecho de acceder a las cámaras del CCTV y
para casos asociados a la calidad del servicio y operación las solicitudes no excederán una
consulta de 6 minutos en el 15% de la flota al mes.

RF004: Las cámaras del CCTV deben incorporar un sistema de autoajuste para operación de día
y de noche (visión nocturna) y rango dinámico amplio (WDR) o esquemas mínidomo IP color
que atiendan esta necesidad.

RF005: El CCTV a bordo de los vehículos debe almacenar el video e imágenes de forma
permanente en el NVR o en el dispositivo que haya lugar y esto debe ser posteriormente
descargado en los sitios que determine El Ente Gestor, aparte del almacenamiento que
considere el concesionario de provisión u operación. El Ente Gestor tendrá acceso físico o
remoto al esquema de solución planteado.

20
RF006: El STS en sí, o esquema que gestiona el CCTV, debe implementar una función para enviar
la alarma de botón de pánico al Centro de Gestión asignado del Ente Gestor y generar esquemas
basados en servicios para que esta información pueda ser utilizada El Ente Gestor o quien este
designe. En esencia, se debe enviar las imágenes producidas por la alarma con una
parametrización de tiempo inicial de sesenta (60) segundos antes de presionar el botón de
pánico instalado en el interior del bus y durante los cinco (5) minutos posteriores, cuyos
tiempos podrán ser parametrizables a fin de que cumplan lo que requiera El Ente Gestor.

RF007: El STS debe implementar una función para observar en tiempo de operación y de
manera remota las imágenes del CCTV de los buses en el Centro de Gestión, esto puede ser ya
sea bajo demanda o cuando lo requiera El Ente Gestor. En este sentido, se debe contemplar un
esquema de VMS para poder tener la visualización de las cámaras (cualquiera que sea) con
criterios de simultaneidad, cuyos costos estarán a cargo del Concesionario de Provisión. En el
momento que algún organismo de control requiera acceso a la información almacenada, será
responsabilidad del Concesionario de Operación dar oportuno trámite y efectiva respuesta,
exonerando al Ente Gestor de cualquier responsabilidad. Así mismo, en caso de que un tercero
desee acceso a esta información deberá ser autorizado por parte del Ente Gestor y, este podrá
o no autorizar.

RF08: El CCTV debe rotular al inicio y fin de la grabación, las imágenes enviadas al Centro de
Gestión en el marco de la atención a la activación del botón de pánico a fin de preservar la
cadena de custodia y su carácter de prueba.

RF09: Las cámaras deben ser ubicadas al interior del vehículo sin que puedan ser manipuladas
por los usuarios de tal forma que se logra la mayor cobertura posible en el interior del bus.

RF010: Se deben instalar las cámaras suficientes para que sea posible ver, en su mayoría, el
interior del vehículo y con un mínimo de punto ciegos, la forma de cubrimiento de la/s
cámara/s del video al interior del bus serán validadas y autorizadas por El Ente Gestor previa
la vinculación del vehículo a la operación y será el Ente Gestor quien acepte la cantidad de
cámaras dispuestas en el bus según la visibilidad que estas expongan y de acuerdo a los criterios
del criterios requeridos por el Ente Gestor.

RF011: El STS debe implementar una función para intentar el reenvío del reporte de los datos
al Centro de Gestión asignado por El Ente Gestor al momento de presentarse una falla en las
comunicaciones, hasta que se verifique él envió del mismo.

Requisitos no funcionales

• Confiabilidad

RNFS001: El CCTV debe tener un tiempo medio entre fallas (MTBF) igual o superior a sesenta
mil (60.000) horas.

RNFS002: El fabricante del NVR deberá haber integrado módulos de hardware con tecnología
4G-LTE que usen bandas y Frecuencias al menos de 3G/4G LTE.

• Usabilidad

21
RNFS003: EL CCTV debe operar de forma automática sin intervención humana mientras el
vehículo este encendido y cinco (5) minutos más una vez haya sido apagado el vehículo.

• Disponibilidad

RNFS004: El CCTV debe operar de forma automática sin intervención humana mientras el
vehículo esté encendido y cinco (5) minutos más una vez ha sido apagado el vehículo.

RNFS005: El CCTV debe tener una disponibilidad diaria de al menos el noventa y nueve por
ciento (99%) durante el tiempo de operación, pero en todo caso deberán cumplir los ANS
establecidos en el anexo de Niveles de Servicio.

RNFS006: El video del CCTV debe almacenarse en un NVR u otro sistema de almacenamiento
con un VMS8 , con capacidad para treinta (30) días de almacenamiento al menos a 720p o 0.9MP
en color, y al menos a 15 FPS (Frames Per Second) con datos de georreferenciación.

RNFS007: Si se presiona el botón de pánico, el video en vivo ya sea de todas las cámaras
instaladas al interior del vehículo o de las que considere El Ente Gestor, debe ser enviado al
Centro de Gestión con una calidad mínima de 720p y 8 FPS.

RNFS008: Se deberá colocar al interior del bus los avisos necesarios que informen a los
pasajeros que están siendo monitorizados y grabados; para ello el diseño de las piezas deberá
ser aprobado por El Ente Gestor y deberá ser instalado antes de la vinculación del bus, en caso
de requerirse un reemplazo de estas piezas esto será responsabilidad del Concesionario de
Operación, quien a su vez asumirá los costos.

Nota: Para garantizar la calidad del canal de comunicaciones, el Concesionario de Provisión

debe realizar un acuerdo estratégico o un contrato de servicio de telecomunicaciones o el acto
que considere pertinente, a fin de brindar las garantías de servicio, con un proveedor que
suministre un canal de comunicaciones con capacidad suficiente (ancho de banda y de
transferencia) para transmitir y recibir de manera permanente los datos requeridos. En este
sentido, es el Concesionario de Provisión, dependiendo del nivel de flota que maneje el
concesionario de operación, es quien debe garantizar a partir de la cantidad de sus equipos
instalados en los buses, que el canal de comunicaciones cumpla y es suficiente con lo que se
requiere desde El Ente Gestor (para su Centro de Gestión) y este, es decir El Ente Gestor o quien
este designe, avalará el canal de comunicaciones a partir de algunas pruebas de calidad y
satisfacción de la transmisión de información. El pago del canal de comunicaciones estará a
cargo del Concesionario de Operación. En el caso que se presenten retrasos en la transmisión
y/o recepción de información, es decir, que exista un problema o inconveniente ya que el ancho
de banda no es suficiente u otro problema, El Concesionario de operación bajo las directrices
del Ente Gestor deberá solicitar mejoras al canal de comunicaciones, las cuales deberán
realizarse en menos de seis (6) horas calendario después de la solicitud del Ente Gestor o quien
este designe, de hecho, el concesionario de operación deberá notificar inmediatamente al ente
gestor cuando todo este operativo y se cumpla con el criterio de transmisión y/o recepción de
información lo cual será validado por el ente gestor, y al mismo tiempo, si el canal continua con
inconvenientes, el concesionario de operación deberá estar informado permanentemente la

8 VMS: Video Management System

22
situación del canal de comunicaciones como mínimo cada 20 minutos y si se recupera el canal
de transmisión o recepción de información antes de los 20 minutos, se debe notificar su estado
inmediatamente al ente gestor. Si el problema persiste más allá de las 6 horas el concesionario
de operación deberá tomar las medidas necesarias para articularse en términos de operación y
hacer uso de la flota de reserva para solucionar el problema, si fuese el caso de algún daño de
hardware. En otro caso si el problema es de la red general de telecomunicaciones se deberán
presentar los soportes para tal fin y será el ente gestor quien determine que directrices seguir
para los términos de operación del sistema. Así mismo, puede ser posible que el Concesionario
de Provisión cuente con una red virtual propia para enfrentar esta funcionalidad, en cuyo caso,
corresponderá al Concesionario de operación, adelantar las gestiones con el concesionario de
provisión para las mejoras a que haya lugar, antes del tiempo indicado.

Si durante el tiempo que dure la indisponibilidad, existiera algún evento de seguridad, el

concesionario de operación deberá utilizar los otros mecanismos de comunicaciones con los
que dispone el bus para notificar al Ente Gestor o a quien este determine, la situación. Durante
el tiempo que dure la indisponibilidad también se harán las mediciones de los ANS de ITS, los
cuales solo serán exonerados aquellos registros de evidencias de seguridad que se puedan
presentar y que el concesionario de operación allegue en un plazo máximo de veinticuatro (24)
horas calendario al Ente Gestor las grabaciones que se pudieron generar durante el suceso
siempre y cuando se haya pulsado el botón de pánico durante ese suceso lo cual estará
registrado en el STS, si esto no ocurre, se aplicaran los descuentos que arrojen las mediciones
del ANS de ITS durante el tiempo que dure la indisponibilidad, sin lugar a objeciones por parte
del Concesionario de Operación, quien responderá ante las autoridades competentes si hay
lugar..

RNFS009: El Concesionario de Provisión debe disponer de un equipo de almacenamiento

externo a los autobuses para la descarga de los videos marcados del CCTV cada vez que llegue
al lugar de estacionamiento como se considera en el anexo de patios. Este equipo de
almacenamiento deberá tener la capacidad de retención de todos los videos marcados durante
30 días para un cien por ciento (100%) de los datos de toda flota que tiene a su cargo,
contemplado para esto, los esquemas de seguridad especificados en este documento. Lo
anterior, sigue requiriendo que el sistema de almacenamiento del CCTV en los buses siga
guardando toda la información por los mismos 30 días. Asimismo, estos videos deberán estar
disponibles, en su totalidad, es decir, lo referente a los videos que se almacenan en los buses en
un máximo de 72 horas para ser entregados al Ente Gestor, tanto los videos no marcados como
los marcados, y esto será a disposición de lo que el Ente Gestor disponga para la entrega de
estos videos. Esto último puede hacerse por conexiones seguras en términos de transmisión de
datos hacia el Ente Gestor, pero si los archivos son muy grandes, deberá suministrarse un
dispositivo de estado sólido (por ejemplo: memoria USB o disco duro) con la información a
lugar en el mismo límite de tiempo, es decir, 72 horas, el tamaño del dispositivo puede variar
en función de la información solicitada, la cual no será mayor en ningún caso a 4TB; después
de extraída la información el dispositivo será devuelto por parte del Ente Gestor al
Concesionario. En todo el proceso descrito, la información debe seguir los esquemas de
custodia a que haya lugar y deberá ser entregado bajo radicado a la Dirección Técnica de
Seguridad de TRANSMILENIO S.A., o a quien haga sus veces, lo anterior significa que esto deberá

23
ser entregado en día hábil o dependiendo de la urgencia deberá ser entregado directamente al
Centro de Gestión (independientemente de la hora), garantizando la cadena de custodia, la cual,
pasará al Ente Gestor en el momento de su entrega.

Sin embargo, los videos marcados con el botón de pánico deben estar disponibles en línea o
tiempo real y si el Ente Gestor los solicita físicamente, deben estar al menos en la entidad en 5
horas máximo después de que el bus llegue al patio, todo esto, con el fin de que sean analizados
por el Ente Gestor. Esto deberá entregarse a la Dirección Técnica de Seguridad de
TRANSMILENIO S.A. o quien haga sus veces, en un dispositivo de estado sólido (memoria USB
u otro dispositivo) para los fines que este designe y se debe garantizar la cadena de custodia de
esta información. Por otra parte, si existe alguna emergencia de acuerdo a lo que considere el
Ente Gestor los videos deben poder ser descargables en línea y para esto el concesionario
deberá disponer de esquema de descarga de videos bajo canales seguros de comunicaciones en
aras de mantener la cadena de custodia de los mismos.

RNFS010: El Concesionario de Provisión, en las zonas que determine para descarga de

información, deberá contar con una red WiFi 802.11n, WiFi 802.11ac o superior, o incluso
puede tener esquemas de redes orientadas al retardo para realizar la recolección de
información de videos e imágenes, así como de los datos generados por los sensores que van en
conexión hacía el STS (esta última funcionalidad corresponde a los temas de telemetría y
también deber ser considerados por el Concesionario de Provisión, esto también se contempla
en el apartado de sensores de cabina y de motor). Si el Concesionario de Provisión considera
pertinente, puede contar con una alternativa de red cableada para realizar la descarga de la
información, teniendo en cuenta que debe desplegar infraestructura suficiente para descargar
la información de todos videos que se generan a partir de los equipos instalados al interior de
los buses.

• Rendimiento

RNFS011: Se debe contar con Cámaras IP - protocolo IPv4/v6, estándar IEEE 802.3 AF Tipo 1.
Debe ser compatible con ONVIF profile S/G versión 2.0 o superior, incorporar capacidades de
HTTP, HTTPS, SSL, TLS, QoS, FTP, SFTP, SMTP, SNMP, DNS, NTP, TCP, UDP, IGMP, DHCP, SSH,
etc.

RNFS012: El CCTV debe estar en capacidad de operar al menos a veinte (20) imágenes por
segundo (Frames Per Second).

RNFS013: el CCTV debe estar en capacidad de operar entre temperaturas entre -10ºC a +50ºC

RNFS0013: El video de la cámara del conductor debe almacenarse en el mismo Video Recorder
(NVR) u otro sistema de almacenamiento con un VMS (Video Management System) con
capacidad para treinta (30) días de almacenamiento al menos a 720p o 0.9MP en color, se debe
almacenar a 15 FPS (Frames Per Second) con datos de georreferenciación.

RNFS014: Las cámaras empleadas en el CCTV deben cumplir normas físicas a prueba de
vandalismo, mínimo IK8, norma EN50155 T3 y con protección IP56. Una forma alternativa de

24
norma a la EN50155 es CEPE/ONU R10 y la norma CEN TS13149, ambas aceptadas también
por la entidad.

RNFS015: El sistema NVR debe cumplir con el estándar MIL-STD-810G procedimiento en modo
operativo contra choques Método 514.6 y Método 516.6, estándar EN50155, norma ISO 7637-
2 perturbaciones eléctricas de conducción y acoplamiento. Se acepta también las normas
CEPE/ONU R10 y la norma CEN TS13149.

RNFS016: el almacenamiento debe ser de estado sólido (SSD) o HDD con protección para uso
vehicular con capacidad para almacenar el video y datos durante el tiempo especificado en este
documento.

• Seguridad

RNFS017: Deshabilitar el sistema de acceso directo a las cámaras a través de la red interna e
interfaz gráfica, permitiendo únicamente el acceso desde el Centro de Gestión a través del túnel
cifrado en dos (2) vías o a quien El Ente Gestor indique para tal fin.

RNFS018: Establecer una política y procedimientos para cambio de las claves de las cámaras
del CCTV de los vehículos, de forma rutinaria, establecida y documentada; evitando el uso de
las claves por defecto.

RNFS019: Los videos del sistema CCTV deben comprimirse y cifrarse en disco y a través del
túnel cifrado TLS durante su transferencia, teniendo en cuenta que la información tratada se
encuentra protegida por normativa de protección de datos personales.

Especificaciones técnicas del equipo

Característica Especificación técnica

Definición Elementos que permiten monitorizar la seguridad de los pasajeros tanto
al interior del vehículo como en la parte frontal y trasera del mismo en
sus rangos de proximidad
Objetivo Mejorar la seguridad de los usuarios el sistema y tener información de
usabilidad del sistema por paradas
Tipo de cámara El CCTV debe operar con cámaras IP con protocolo IPv4/v6, estándar
IEEE 802.3af Type 1 o superior barrido progresivo, Rango Dinámica
Amplio (WDR). La cámara debe ser compatible con ONVIF profile S
versión 2.0 o superior.
Resolución 720p o 0.9MP a 15 FPS y relación de aspecto de al menos 4:3 y 16:9.
Temperatura Capacidad operar con temperaturas entre -10ºC a +50ºC.
Protección Física Las cámaras deben cumplir normas físicas a prueba vandalismo mínimo
IK8, norma EN50155 T3 y con protección IP56. Como alternativa a la
norma EN50155 se aceptan las normas CEPE/ONU R10 y la norma CEN
TS13149.
NVR El sistema NVR debe cumplir con el estándar MIL-STD-810G
procedimiento en modo operativo contra choques Método 514.6 y
Método 516.6, estándar EN50155, norma ISO 7637-2 perturbaciones

25
 Característica Especificación técnica
eléctricas de conducción y acoplamiento. Se acepta también las normas
CEPE/ONU R10 y la norma CEN TS13149.
Deberá estar ubicado dentro del vehículo en un lugar de acceso seguro,
no visible, donde esté minimizado el daño por posible colisión y con
acceso restringido por parte de usuarios no autorizados.
Almacenamiento Debe ser de estado sólido (SSD) o HDD con protección para uso vehicular
del NVR con capacidad para almacenar el video y datos durante el tiempo
especificado en este documento.
Compatibilidad Debe cumplir con las normas de compatibilidad electromagnética EMC
Electromagnética clase A o su equivalente, Certificaciones CE, FCC Class A, E13 y RoHS
Interfaces Las interfaces de comunicaciones y suministro eléctrico para las cámaras
y el NVR deben ser cableadas (IEEE 802.3 y PoE para cámaras IP). Los
conectores deben ser tipo FAKRA o ISO 20860, de aviación o su
equivalente, se posibilita también el uso de conectores tipo M12. El
Concesionario de Provisión debe tener en cuenta que el sistema de CCTV
debe contar con sistema eléctrico independiente, incorporando las
protecciones eléctricas necesarias. Se requiere tener una interfaz con el
sistema de almacenamiento y debe ser compatible con WiFI 802.11n,
WiFI 802.11ac o superior o incluso que se puede articular a esquemas de
redes orientadas al retraso (DTN: Delay Time Network), todo lo anterior,
en aras de permitir la descarga de los videos e imágenes almacenados
por el CCTV. El Concesionario de Provisión, en las zonas para descarga
de información, deberá contar con una red WiFI 802.11n, WiFI 802.11ac
o superior o incluso que se puede articular a esquemas de redes
orientadas al retraso (DTN: Delay Time Network) para realizar la
recolección de información de videos e imágenes, así como de los datos
generados por los sensores del STS, este tipo de redes en términos de
acceso y hotspot debe ser suficientes en velocidad y capacidad para
generar esquemas de descarga en el menor tiempo posible. Si el
Concesionario de Provisión considera pertinente, puede contar con una
alternativa de red cableada para realizar la descarga de la información,
teniendo en cuenta que debe desplegar infraestructura suficiente para
descargar la información de todos los buses, proceso que será validado
de forma permanente por El Ente Gestor o quien este designe..
Seguridad Debe cumplir con los comportamientos establecidos anteriormente y
conservar la cadena de custodia en caso de requerimientos de ley

Nota: Para el soporte técnico, todas las cámaras desplegadas en los buses deben ser
implementadas con componentes cuyos fabricantes tengan representación legal en Colombia,
soporte técnico veinticuatro (24) horas al día, trescientos sesenta y cinco (365) días al año, con
capacidad de suministro de sus partes en menos de veinticuatro (24) horas. En el caso en el que
fabricantes no tengan representación legal en Colombia, se exige que los Concesionarios de

26
Provisión cuenten con una representación en Colombia y certifique que realiza soporte técnico
veinticuatro (24) horas al día, trescientos sesenta y cinco (365) días al año, con capacidad de
suministro de sus partes en menos de veinticuatro (24) horas; certificado que deberá ser
entregado con la documentación requerida para la vinculación de cada vehículo.

C) Cámara frontal y cámara trasera del vehículo

La cámara frontal y la cámara trasera permiten monitorizar la actividad exterior del bus.

Requisitos funcionales

RF001: El STS debe implementar una función para guardar en el dispositivo de

almacenamiento, el video e imágenes de la cámara frontal y la cámara trasera de forma
permanente mientras el vehículo esté encendido y mínimo cinco (5) minutos más, una vez ha
sido apagado el vehículo.

RF002: La cámara frontal debe capturar las actividades del frente exterior del autobús y tener
un ángulo de visión mínimo de 130° (FOV).

RF003: La cámara trasera debe capturar las actividades de la parte posterior exterior del
autobús y tener un ángulo de visión mínimo de 120° (FOV).

RF004: La cámara frontal y la cámara trasera deben almacenar el video capturado y retenerlo
durante al menos treinta (30) días.

RF005: El STS debe implementar una función para enviar al Centro de Gestión del Ente Gestor
el video e imágenes de la cámara frontal y la cámara trasera, por un tiempo inicialmente
parametrizado de sesenta (60) segundos antes del momento en que se active la alarma de botón
de pánico y durante un tiempo inicialmente parametrizable de cinco (5) minutos siguientes,
estos dos tiempos podrán ser superiores según lo que especifique El Ente Gestor. Para esto,
debe utilizar el procedimiento (servicio web con XML o enfoques REST ambos con esquemas
de seguridad) establecido por el Centro de Gestión del Ente Gestor y enviar la información en
la trama definida por El Ente Gestor para el envío de los datos.

RF006: La cámara frontal y la cámara trasera deben incorporar un sistema de autoajuste para
operación pudiendo ser estas cámaras color y con resolución suficiente para situaciones de día
y de noche y rango dinámico amplio (WDR).

RF007: La cámara frontal y la cámara trasera deben estar en capacidad de operar al menos a
15 FPS.

RF008: El STS o en su defecto, el equipo NVR que sea capaz de manejar las cámaras ubicadas en
los panorámicos trasero o delantero, en caso de presionar el botón de pánico, o de llegarse a
presentar alguna colisión del vehículo, o cuando el Centro de Gestión lo requiera, el Video
Management System deberá enviar el video de la cámara frontal y la cámara trasera al Centro
de Gestión con una calidad mínima de 720p y 8 FPS.

Requisitos no funcionales

27
• Usabilidad

RNFS001: la cámara frontal y la cámara trasera deben operar de forma automática y sin
intervención humana mientras el vehículo este encendido y cinco (5) minutos más, una vez se
haya pagado el vehículo

• Confiabilidad

RNFS02: La cámara frontal y la cámara trasera deben tener un tiempo medio entre fallas
(MTBF) igual o superior a sesenta mil (60.000) horas.

• Disponibilidad

RNFS003: El CCTV debe operar de forma automática sin intervención humana mientras el
vehículo esté encendido y cinco (5) minutos más una vez ha sido apagado el vehículo.

RNFS004: El video de la cámara frontal y la cámara trasera deben almacenarse en el mismo

Video Recorder (NVR) u otro sistema de almacenamiento, se debe contemplar un esquema de
VMS (Video Management System) ya sea del CCTV o del dispuesto para esto, con capacidad de
almacenamiento para treinta (30) días de al menos a 720p o 0.9MP en color, y al menos a quince
(15) FPS (Frames Per Second) con datos de georreferenciación.

RNFS005: La cámara frontal y la cámara trasera debe tener una disponibilidad diaria de al
menos el noventa y nueve por ciento (99%) durante el tiempo de operación, pero en todo caso
deberán cumplir los ANS establecidos en el anexo de Niveles de Servicio.

RNFS006: La cámara frontal y la cámara trasera deberán ser ubicadas al interior del vehículo
sin que pueda ser manipuladas por personal no autorizado.

Nota: Para garantizar la calidad del canal de comunicaciones, el Concesionario de

Provisión debe realizar un acuerdo estratégico o un contrato de servicio de
telecomunicaciones o el(los) acto(s) que considere pertinente, a fin de brindar las
garantías de servicio, con un proveedor que suministre un canal de comunicaciones con
capacidad suficiente (ancho de banda y de transferencia) para transmitir y recibir de
manera permanente los datos requeridos. En este sentido, es el Concesionario de
Provisión, dependiendo del nivel de flota que maneje el concesionario de operación,
quien debe garantizar a partir de la cantidad de sus equipos instalados en los buses, que
el canal de comunicaciones cumpla y es suficiente con lo que se requiere desde El Ente
Gestor (para su Centro de Gestión) y este, es decir El Ente Gestor o quien este designe,
avalará el canal de comunicaciones a partir de algunas pruebas de calidad y satisfacción
de la transmisión de información. El pago del canal de comunicaciones estará a cargo
del Concesionario de Operación. En el caso que se presenten retrasos en la transmisión
y/o recepción de información, es decir, que exista un problema o inconveniente ya que
el ancho de banda no es suficiente u otro problema, El Concesionario de operación bajo
las directrices del Ente Gestor deberá solicitar mejoras al canal de comunicaciones, las
cuales deberán realizarse en menos de seis (6) horas calendario después de la solicitud

28
del Ente Gestor o quien este designe, de hecho, el concesionario de operación deberá
notificar inmediatamente al ente gestor cuando todo este operativo y se cumpla con el
criterio de transmisión y/o recepción de información lo cual será validado por el ente
gestor, y al mismo tiempo, si el canal continua con inconvenientes, el concesionario de
operación deberá estar informado permanentemente la situación del canal de
comunicaciones como mínimo cada 20 minutos y si se recupera el canal de transmisión
o recepción de información antes de los 20 minutos, se debe notificar su estado
inmediatamente al ente gestor. Si el problema persiste más allá de las 6 horas el
concesionario de operación deberá tomar las medidas necesarias para articularse en
términos de operación y hacer uso de la flota de reserva para solucionar el problema, si
fuese el caso de algún daño de hardware. En otro caso si el problema es de la red general
de telecomunicaciones se deberán presentar los soportes para tal fin y será el ente
gestor quien determine que directrices seguir para los términos de operación del
sistema. Así mismo, puede ser posible que el Concesionario de Provisión cuente con una
red virtual propia para enfrentar esta funcionalidad, en cuyo caso, corresponderá al
Concesionario de operación, adelantar las gestiones con el concesionario de provisión
para las mejoras a que haya lugar, antes del tiempo indicado.

Si durante el tiempo que dure la indisponibilidad, existiera algún evento de seguridad,

el concesionario de operación deberá utilizar los otros mecanismos de comunicaciones
con los que dispone el bus para notificar al Ente Gestor o a quien este determine, la
situación. Durante el tiempo que dure la indisponibilidad también se harán las
mediciones de los ANS de ITS, los cuales solo serán exonerados aquellos registros de
evidencias de seguridad que se puedan presentar y que el concesionario de operación
allegue en un plazo máximo de veinticuatro (24) horas calendario al Ente Gestor las
grabaciones que se pudieron generar durante el suceso siempre y cuando se haya
pulsado el botón de pánico durante ese suceso lo cual estará registrado en el STS, si esto
no ocurre, se aplicaran los descuentos que arrojen las mediciones del ANS de ITS
durante el tiempo que dure la indisponibilidad, sin lugar a objeciones por parte del
Concesionario de Operación, quien responderá ante las autoridades competentes si hay
lugar.

• Rendimiento

RNFS007 Resolución: Las cámaras frontal y Trasera deben ser cámaras IP para capturar o
almacenar video con resolución mínima de 720p o 0.9Mp con estabilización electrónica de la
imagen y barrido progresivo. Deben ser compatible ONVIF profile S/G versión 2.0 o superior,
incorporar capacidades de HTTP, HTTPS, SSL, TLS, QoS, FTP, SFTP, SMTP, SNMP, DNS, NTP,
TCP, UDP, IGMP, DHCP, SSH, etc.

29
RNFS008 Resolución: Las cámaras del CCTV deben incorporar un sistema de autoajuste para
operación de día y de noche (visión nocturna) y rango dinámico amplio (WDR)

RNFS009: El CCTV debe estar en capacidad de operar hasta un máximo de treinta 30 imágenes
por segundo (Frames Per Second). Es decir, este factor debe ser configurable a petición del Ente
Gestor.

RNFS0010: el CCTV debe estar en capacidad de operar entre temperaturas entre -10ºC a +50ºC

RNFS0011: la cámara frontal y trasera debe tener características a prueba de vandalismo y

protección mínima IP66 y con IK8,.

Especificaciones técnicas del equipo

Característica Especificación técnica

Definición Elementos que permiten monitorizar el entorno del vehículo durante la
operación
Objetivo Ofrecer imágenes y video al exterior del bus durante la operación a fin
de registrar
Tipo de cámara Cámara IP - protocolo IPv4/v6, estándar IEEE 802.3 AF Tipo 1
Resolución 720p o superior a 15FPS y con relación de aspecto de al menos 4:3 y
16:9
Temperatura Capacidad de operar con temperaturas entre -5ºC a +50ºC.
Protección Física Debe tener características a prueba vandalismo y con protección física
mínima IP66
Almacenamiento El video de la cámara frontal y la cámara trasera deben almacenarse en
el mismo Video Recorder (NVR) u otro sistema de almacenamiento con
un VMS (Video Management System) del CCTV, con capacidad para
treinta (30) días de almacenamiento al menos a 720p o 0.9MP en color
y al menos a quince (15) FPS (tramas per second) con datos de
georreferenciación.
Disposición Las cámaras deben ser ubicadas al interior del vehículo, sin que puedan
ser manipuladas por los usuarios, de manera que cubran la totalidad de
la cabina.
Interfases Las interfaces de comunicaciones y suministro eléctrico para las
cámaras y el NVR deben ser cableadas (IEEE 802.3 y PoE para cámaras
IP). Los conectores deben ser tipo FAKRA o ISO 20860, de aviación o su
equivalente. El suministro eléctrico debe ser independiente para estas
cámaras, se posibilita también el uso de conectores tipo M12.
Comunicaciones El fabricante del NVR deberá haber integrado módulos de hardware con
tecnología 4G-LTE que usen al menos bandas y Frecuencias 3G/4G LTE.
Campos Debe cumplir con las normas de compatibilidad electromagnética EMC
Electromagnéticos clase A o su equivalente.

30
Nota: Para el soporte técnico todas las cámaras en general desplegadas en los buses deben ser
implementadas con componentes cuyos fabricantes tengan representación legal en Colombia,
soporte técnico veinticuatro (24) horas al día, trescientos sesenta y cinco (365) días al año, con
capacidad de suministro de sus partes en menos de veinticuatro (24) horas. En el caso en el que
los fabricantes no tengan representación legal en Colombia, se exige que los Concesionarios de
Provisión cuenten con una representación en Colombia y certifique que realiza soporte técnico
veinticuatro (24) horas al día, trescientos sesenta y cinco (365) días al año, con capacidad de
suministro de sus partes en menos de veinticuatro (24) horas; certificado que deberá ser
entregado con la documentación requerida para la vinculación de cada vehículo.

D) Grabador de video en red (NVR)

Componente de hardware encargado de coordinar la interacción con el Centro de Gestión y el

STS del vehículo. Se trata de un dispositivo electrónico capaz de enviar y almacenar los datos
que generan las cámaras del CCTV tanto las interiores como las externas al vehículo. Por otra
parte, para el envió de temas de sensores puede utilizarse otro dispositivo que realizará la
articulación de la información obtenida por el CANBUS o se puede tener un STS más robusto
que pueda apoyar este esta funcionalidad de telemetría hacia el Centro de Gestión.

Requisitos funcionales

RF001: este dispositivo debe contar con un identificador único dentro del sistema integrado de
transporte público. Así mismo, esto también es extensible a cualquier otro dispositivo de
hardware que haga las veces del esquema de telemetría o que se conecte al CANBUS, todo esto
para evitar que este dispositivo rote por todos los vehículos.

RF002: El video de todas las cámaras debe almacenarse en un dispositivo central o NVR
(Network Video Recorder: Grabador de Video en Red) y deberá ser descargado en su medida
en los lugares de almacenamiento que se dispongan para este fin. Las descargas de video
deberán ser almacenadas por el Concesionario de Operación por un período mínimo de treinta
(30) días.

RF003: El dispositivo central del STS o NVR podrá cumplir con las funciones de almacenamiento
o transmisión remota del CCTV y con las variables a que haya lugar dependiendo del esquema
de operación, no obstante, se deben tener muy identificadas las diversas tramas de datos para
cada uno de los subconjuntos de ITS en aras de proveer al Centro de Gestión con la información
requerida usando los esquemas de diccionarios de datos que se dispongan desde el Centro de
Gestión.

RF004: El almacenamiento del sistema NVR debe ser de estado sólido (SSD) o HDD con
protección para uso vehicular con capacidad para almacenar el video y datos

RF005: El sistema NVR debe disponer de un módem o módulo integrado para comunicaciones
de datos con tecnología 4G-LTE que usen al menos bandas y Frecuencias 3G/4G LTE.

RF006: El sistema NVR debe cumplir con el estándar MIL-STD-810G procedimiento en modo
operativo contra choques Método 514.6 y Método 516.6, estándar EN50155, norma ISO 7637-
2 perturbaciones eléctricas de conducción y acoplamiento.

31
RF007: El Dispositivo debe proveer esquemas basados en Servicios web (tipo XML o enfoque
REST ambos con esquemas de seguridad) capaces de facilitar la integración con otro equipo
Hardware/Software que sea capaz de manejar otras variables de integración de la telemetría
del vehículo

RF008: Almacenar y transmitir la información del CCTV y de los sensores al Centro de Gestión
del Ente Gestor, así como la cámara del conductor y de otros sistemas, todo esto, según la
arquitectura empleada, no obstante, se debe seguir a cabalidad los diccionarios de datos que
articule El Ente Gestor.

RF009: El esquema del STS debe contemplar un esquema de descarga manual y automática de
información o de videos.

RF010: El esquema del STS debe contar con un sistema de reporte al momento de encendido
del bus, es decir, al momento de entrar en operación con el fin de que se identifique una trama
inicial (esta debe contener como mínimo la fecha, hora y estado de funcionamiento, y debe
marcarse con el logotipo de trama inicial) de puesta en marcha de operación del STS, esto
mismo, deberá realizar al momento en que el vehículo termine su operación, es decir, cuando
este sea apagado y tal trama deberá marcarse como trama final (esta debe contener como
mínimo la fecha y la hora de fin de operación del bus).

Requisitos no funcionales

• Usabilidad

RNFS001: El Dispositivo central del STS debe operar de forma automática y sin intervención
humana

• Confiabilidad

RNFS001: El sistema NVR debe tener un MTBF igual o mayor a cuarenta mil (40.000) horas

• Disponibilidad

RNFS001: El sistema NVR debe tener una disponibilidad diaria de al menos el noventa y nueve
por ciento (99%) durante el tiempo de operación, pero en todo caso deberán cumplir los ANS
establecidos en el anexo de Niveles de Servicio.

RNFS002: El dispositivo asociado al STS debe estar instalado en un compartimento no accesible

por personal no autorizado.

• Rendimiento

RNFS001: El dispositivo central del STS deberá tener capacidad de procesamiento para atender
los requisitos especificados, así como las funciones de seguridad que haya lugar dependiendo
del esquema o arquitectura que se contemple y deberá ajustarse a los esquemas contemplados
por parte del Ente Gestor.

32
RNFS002: El dispositivo central del STS deberá tener capacidad de almacenamiento para
atender los requisitos especificados.

RNFS003: El fabricante del STS o del NVR deberá haber integrado módulos de hardware con
tecnología 4G-LTE que usen bandas y Frecuencias al menos de 3G/4G LTE.

RNFS004: El dispositivo central del STS debe disponer WiFI 802.11n, WiFI 802.11ac o superior
para realizar la descarga manual o recolección de información de videos e imágenes en los sitios
que tenga aprobados El Ente Gestor para esto. Los esquemas de descarga deben contar con el
numero suficientes de antenas y hotspots para dar un esquema de proceso eficiente al tema de
descargas de video en el menor tiempo posible, también es posible generar esquemas de DTN
(Delay Tolerant Network) o tener una alternativa de red cableada para este fin.

RNFS005: Temperatura. El dispositivo central del STS debe estar en capacidad operar con
temperaturas entre -20ºC a +70ºC y humedad relativa del noventa por ciento (90%) sin
condensación.

RNFS006: El dispositivo central del STS debe tener protección física mínimo IP56.

Nota: Para garantizar la calidad del canal de comunicaciones, el Concesionario de Provisión

debe realizar un acuerdo estratégico o un contrato de servicio de telecomunicaciones o el(los)
acto(s) que considere pertinente, a fin de brindar las garantías de servicio, con un proveedor
que suministre un canal de comunicaciones con capacidad suficiente (ancho de banda y de
transferencia) para transmitir y recibir de manera permanente los datos requeridos. En este
sentido, es el Concesionario de Provisión, dependiendo del nivel de flota que maneje el
concesionario de operación, quien debe garantizar a partir de la cantidad de sus equipos
instalados en los buses, que el canal de comunicaciones cumpla y es suficiente con lo que se
requiere desde El Ente Gestor (para su Centro de Gestión) y este, es decir El Ente Gestor o quien
este designe, avalará el canal de comunicaciones a partir de algunas pruebas de calidad y
satisfacción de la transmisión de información. El pago del canal de comunicaciones estará a
cargo del Concesionario de Operación. En el caso que se presenten retrasos en la transmisión
y/o recepción de información, es decir, que exista un problema o inconveniente ya que el ancho
de banda no es suficiente u otro problema, El Concesionario de operación bajo las directrices
del Ente Gestor deberá solicitar mejoras al canal de comunicaciones, las cuales deberán
realizarse en menos de seis (6) horas calendario después de la solicitud del Ente Gestor o quien
este designe, de hecho, el concesionario de operación deberá notificar inmediatamente al ente
gestor cuando todo este operativo y se cumpla con el criterio de transmisión y/o recepción de
información lo cual será validado por el ente gestor, y al mismo tiempo, si el canal continua con
inconvenientes, el concesionario de operación deberá estar informado permanentemente la
situación del canal de comunicaciones como mínimo cada 20 minutos y si se recupera el canal
de transmisión o recepción de información antes de los 20 minutos, se debe notificar su estado
inmediatamente al ente gestor. Si el problema persiste más allá de las 6 horas el concesionario
de operación deberá tomar las medidas necesarias para articularse en términos de operación y
hacer uso de la flota de reserva para solucionar el problema, si fuese el caso de algún daño de
hardware. En otro caso si el problema es de la red general de telecomunicaciones se deberán

33
presentar los soportes para tal fin y será el ente gestor quien determine que directrices seguir
para los términos de operación del sistema. Así mismo, puede ser posible que el Concesionario
de Provisión cuente con una red virtual propia para enfrentar esta funcionalidad, en cuyo caso,
corresponderá al Concesionario de operación, adelantar las gestiones con el concesionario de
provisión para las mejoras a que haya lugar, antes del tiempo indicado.

Si durante el tiempo que dure la indisponibilidad, existiera algún evento de seguridad, el

concesionario de operación deberá utilizar los otros mecanismos de comunicaciones con los
que dispone el bus para notificar al Ente Gestor o a quien este determine, la situación. Durante
el tiempo que dure la indisponibilidad también se harán las mediciones de los ANS de ITS, los
cuales solo serán exonerados aquellos registros de evidencias de seguridad que se puedan
presentar y que el concesionario de operación allegue en un plazo máximo de veinticuatro (24)
horas calendario al Ente Gestor las grabaciones que se pudieron generar durante el suceso
siempre y cuando se haya pulsado el botón de pánico durante ese suceso lo cual estará
registrado en el STS, si esto no ocurre, se aplicaran los descuentos que arrojen las mediciones
del ANS de ITS durante el tiempo que dure la indisponibilidad, sin lugar a objeciones por parte
del Concesionario de Operación, quien responderá ante las autoridades competentes si hay
lugar.

Especificaciones técnicas del equipo

Característica Especificación técnica

Definición Elemento que permite almacenar y procesar la información NO SIRCI
Objetivo Custodiar y procesar la información emitida por los dispositivos NO
SIRCI a bordo
Comunicaciones Canal de datos suficiente para transmisiones de calidad y oportunas de
la información
Estándares El sistema NVR debe cumplir con el estándar MIL-STD-810G
procedimiento en modo operativo contra choques Método 514.6 y
Método 516.6, estándar EN50155, norma ISO 7637-2 perturbaciones
eléctricas de conducción y acoplamiento.
Protección física Debe tener protección física mínimo IP56. el NVR deberá estar ubicado
dentro del vehículo en un lugar de acceso seguro, no visible, donde esté
minimizado el daño por posible colisión y con acceso restringido por
parte de usuarios no autorizados.
Compatibilidad Debe cumplir con las normas de compatibilidad electromagnética EMC
electromagnética clase A o su equivalente.
Hardware Esquema de computación de altas prestaciones que pueda realizar
Posible funciones de NVR y administrar diversos dispositivos en RS485/RS232,
con soporte esquemas de SAE J1939, J1708 u otro con gestión de potencia
tipo ISO 7637, Esquema Rugged IEC 60529 IP65, MIL-STD-810G

34
Nota: Para el soporte técnico los dispositivos que sean embarcados en los buses deben ser
implementadas con componentes cuyos fabricantes tengan representación legal en Colombia,
soporte técnico veinticuatro (24) horas al día, trescientos sesenta y cinco (365) días al año, con
capacidad de suministro de sus partes en menos de veinticuatro (24) horas. En el caso en el que
los fabricantes no tengan representación legal en Colombia, se exige que los Concesionarios de
Provisión cuenten con una representación en Colombia y certifique que realiza soporte técnico
veinticuatro (24) horas al día, trescientos sesenta y cinco (365) días al año, con capacidad de
suministro de sus partes en menos de veinticuatro (24) horas; certificado que deberá ser
entregado con la documentación requerida para la vinculación de cada vehículo.

E) Botón de pánico

El botón de pánico es un pulsador de contacto seco con dos salidas (una para la unidad lógica
del vehículo y la otra para el NVR o dispositivo central del STS) que debe ser accionado
solamente por el conductor cuando se presenten riesgos de seguridad para él o para los
usuarios tales como hurtos, vandalismos, riñas y agresiones principalmente

Requisitos funcionales

RF001: El botón de pánico debe notificar una emergencia del vehículo o sus pasajeros al Centro
de Gestión del Ente Gestor.

RF002: El botón de pánico debe ser instalado en un lugar discreto al alcance y visibilidad
exclusiva del conductor.

RF003: Una vez obturado el botón de pánico, deberá marcar los videos de todas las cámaras y
hacer el envió de la misma al Centro de Gestión del Ente Gestor

RF004: El botón de pánico deberá abrir el canal de comunicaciones del bus a fin de escuchar en
el centro de control del Ente Gestor lo que está pasando a bordo

RF005: El botón de pánico deberá cumplir con las demás funcionalidades requeridas por el
concesionario del SIRCI

RF006: Al momento de obturar el botón de pánico también deberá desplegarse un mensaje de

emergencia definido por el Ente Gestor, en los ruteros del bus.

Requisitos no funcionales

• Rendimiento

RNFS001: En el evento de activación del botón de pánico se debe notificar al Centro de Gestión
en menos de cinco (5) segundos.

• Disponibilidad

RNFS002: El botón de pánico debe tener una disponibilidad diaria del noventa y nueve por
ciento (99%) durante el tiempo de operación.

• Ubicación

35
RNFS003: El botón de pánico debe estar ubicado en lugar de fácil accionar para el conductor.
No debe interferir con palancas, pedales u otros dispositivos necesarios para la operación del
bus y deberá estar sobre una superficie fija que lo separe del suelo del bus, preferiblemente
cold rolled, con pintura electroestática o acero inoxidable

• Instalación

RNFS004: El punto de instalación debe tener un refuerzo metálico de ancho 100mm, largo 200
mm y una altura de 40 mm desde el piso, y evitar que la zona donde se ubique sea propensa a
acumulación de agua, tierra o humedad para no reducir su vida útil, se debe utilizar dictaría
(coraza) cerrada de 3/4" hasta el habitáculo de equipos SIRCI, esta dictaría debe quedar sujeta
a la carrocería del bus en todo su recorrido, se debe generar una ruta alejada de partes calientes,
partes rugosas, cantos afilados y evitar roce con elementos móviles. La dictaría debe ser
continua con cable guía, la dictaría no debe tener empalmes en su recorrido, no debe estar
obstruida o prensada con las estructuras o carrocería del bus. El ducto no debe exceder
distancia establecida con el concesionario de equipos SIRCI. En todo caso, debe ceñirse a las
demás especificaciones que el(los) concesionario(s) del SIRCI indiquen.

Especificaciones técnicas del equipo

Característica Especificación técnica

Temperatura Entre -10C° a +49C°
Ambiente EN50130-5 Clase II
Humedad Hasta noventa y tres por ciento (93%) sin condensación
relativa

3.2.2 Sensores de Cabina y de Motor.

En este apartado se especifican los requisitos funcionales y no funcionales de cada uno de los
sensores de cabina y de motor, que hacen parte del Sistema de Tecnológico de Seguridad- STS.
Estos elementos tienen en común los siguientes requerimientos:

Nota: Debe contemplarse para todas las variables que se requiere tener en cuenta en este
apartado que la fecha y la hora es información valiosa para almacenar y relacionarla hacia cada
uno de los dispositivos que aquí se contemplen. Por otra parte, los sensores de la pueden ser
adaptables en enfoques CANBUS, RS485 u otro, de hecho, es posible incorporar mediante un
equipo hardware/software que sea capaz de gestionar las transmisiones de información
emanada por la instrumentación de la cabina y que sea requerida por el STS. Se resalta que los
datos deben venir pre-procesados al STS o puede ser posible desarrollar un enfoque de
preprocesamiento en la unidad del de STS de tal forma que las tramas de lectura entregadas al
STS sean fácilmente interpretables. Asimismo, es posible la incorporación de servicios web en
este punto si los equipos manejan enfoques IP y es viable frente al sensor utilizado. Se resalta
que los sensores de motor deben ir en enfoques CANBUS hacia el STS tal como se expone en las
funcionalidades y su información debe ser consumible por el STS.

Requisitos funcionales generales

36
RF001: El STS debe implementar una función para capturar los datos de la cabina 9 al momento
de encender el vehículo. Los datos que debe capturar son:

• Los momentos en que el vehículo está en reversa

• La temperatura de la cabina.
• Si el conductor lleva o no el cinturón de seguridad abrochado
• Apertura y cierra de Puertas
• Conteo de Pasajeros al cierre de puertas

RF002: El STS debe implementar una función para capturar los datos del rendimiento del motor
mediante el CANBUS al momento de encender el vehículo. Los datos que debe capturar son:

Para vehículos con motor de combustión interna:

• La temperatura y presión del aceite del motor del vehículo.

• Las revoluciones del motor del vehículo.
• El estado de desgaste de las pastillas de frenos del vehículo, para buses que equipen
dicho sistema.
• Los kilómetros efectivamente recorridos del vehículo teniendo de referencia el
odómetro.
• Las revoluciones del motor
• La velocidad del vehículo con posición geográfica.
• Aceleración del vehículo.
• El consumo de combustible, tanto en volumen/masa, como específico por unidades de
distancia.
• El nivel del tanque de combustible.
• Giros y frenadas bruscas. (parametrizables a solicitud).
• Otros elementos que informen sobre el estado del vehículo en el tablero de testigos de
la cabina que aporten al enfoque de seguridad vial.

Para vehículos sin motor de combustión interna:

• Las revoluciones del motor del vehículo.

• El estado de desgaste de las pastillas de frenos del vehículo, para buses que equipen
dicho sistema.
• Los kilómetros efectivamente recorridos del vehículo teniendo de referencia el
odómetro.
• Las revoluciones del motor
• La velocidad del vehículo con posición geográfica.
• a aceleración del vehículo.
• El consumo de energía.
• Regeneración de energía
• El nivel restante de energía.

9las variables descritas pueden ser adaptables a enfoques de CANBUS o de esquemas de RS485 u otro y esto puede ser
enviado mediante este tipo de interfaz al STS.

37
 • El porcentaje de energía regenerada.
• Giros y frenadas bruscas. (parametrizables a solicitud).

Nota: Los vehículos que incorporen ambos tipos de motorización (motores de combustión
interna y motores eléctricos o de otro tipo diferente a combustión interna, deben contar con
todos los dispositivos para captar la información asociados a las variables de cabina y motor y,
se requiere tener en cuenta que, para cada tipo de motor, se debe especificar una distinción del
tipo de motor en aras de saber el estado de la flota de acuerdo con su tipología de motor. Se
resalta que para los buses que son eléctricos, se debe tener muy en cuenta que en la trama de
datos que se envía al Centro de Gestión, se debe incorporar los datos asociados a las baterías
del vehículo en aras de verificar su autonomía, esto debe ser articulado según los diccionarios
de datos que tiene la entidad, es decir, como lo disponga El Ente Gestor.

RF003: El STS debe implementar una función para reportar, al Centro de Gestión del Ente
Gestor, los datos capturados, inicialmente cada (1) minuto, tiempo que deberá ser
parametrizable y deberá ajustarse según las solicitudes del Ente Gestor, mientras el vehículo
esté encendido. Para esto, debe utilizar el procedimiento (servicio web con XML o enfoques
REST ambos con esquemas de seguridad) establecido por el Centro de Gestión del Ente Gestor
en aras de enviar la información siguiendo la trama definida por El Ente Gestor. Los datos que
debe reportar son los siguientes:

Para vehículos con motor de combustión interna:

• La temperatura y presión del aceite del motor del vehículo.

• Las revoluciones del motor del vehículo.
• El estado de desgaste de las pastillas de frenos del vehículo, para buses que equipen
dicho sistema.
• Los kilómetros efectivamente recorridos del vehículo teniendo de referencia el
odómetro.
• Las revoluciones del motor
• La velocidad del vehículo con posición geográfica10. Aceleración del vehículo.
• El consumo de combustible, tanto en volumen/masa, como específico por unidades de
distancia.
• El nivel del tanque de combustible.
• Giros y frenadas bruscas. (parametrizables a solicitud).
• Otros elementos que informen sobre el estado del vehículo en el tablero de testigos de
la cabina que aporten al enfoque de seguridad vial.

Para vehículos sin motor de combustión interna:

• Las revoluciones del motor del vehículo.

• El estado de desgaste de las pastillas de frenos del vehículo, para buses que equipen
dicho sistema.

10La frecuencia de envío de la información es la mencionada en el RF003 de los requisitos funcionales generales del
numeral 3.2.2 y la detallada en el literal D) del numeral 3.2.2

38
 • Los kilómetros efectivamente recorridos del vehículo teniendo de referencia el
odómetro.
• Las revoluciones del motor
• La velocidad del vehículo con posición geográfica11. a aceleración del vehículo.
• El consumo de energía.
• Regeneración de energía
• El nivel restante de energía.
• El porcentaje de energía regenerada.
• Giros y frenadas bruscas. (parametrizables a solicitud).

RF004: El STS debe implementar una función para reportar con opción de valor parametrizable
al Centro de Gestión asignado por El Ente Gestor los siguientes datos de la cabina del vehículo
cada vez que el vehículo se detenga en un paradero y abra puertas o lo que especifique El Ente
Gestor mientras el vehículo esté encendido. Para esto, debe utilizar el procedimiento (servicio
web con XML o enfoques REST ambos con esquemas de seguridad) establecido por el Centro
de Gestión y enviar la información en la trama definida por El Ente Gestor para el envío de los
datos. Los datos que debe reportar son los siguientes:

• Los momentos en que el vehículo está en reversa

• .
• La temperatura de la cabina.
• Si el conductor lleva o no el cinturón de seguridad abrochado
• Apertura y cierra de Puertas
• Conteo de Pasajeros al cierre de puertas

RF006: El STS debe seguir el formato XML o enfoques REST, ambos con esquemas de seguridad,
establecido por el Centro de Gestión del Ente Gestor para el consumo de los servicios web
destinados para el intercambio de información.

RF007: El STS debe implementar una función para identificar la fecha/hora del último reporte
de las coordenadas geográficas al Centro de Gestión para realizar el siguiente reporte.

RF008: El STS debe implementar una función para registrar la fecha/hora del reporte de los
datos del rendimiento del motor y CANBUS al Centro de Gestión.

RF009: El STS debe implementar una función para identificar la fecha/hora del último reporte
de los datos del rendimiento del motor y CANBUS al Centro de Gestión, con el fin de identificar
en que instante de tiempo enviar el siguiente reporte.

RF010: El STS debe implementar la función necesaria para configurar los rangos permitidos
para cada uno de los dispositivos de seguridad a partir de la información recibida por parte del
Centro de Gestión del Ente Gestor.

11La frecuencia de envío de la información es la mencionada en el RF003 de los requisitos funcionales generales del
numeral 3.2.2 y la detallada en el literal D) del numeral 3.2.2

39
RF011: El STS o dispositivo a que haya lugar debe implementar la función necesaria para
parametrizar los tipos de alarmas por eventos que se pueden generar al Centro de Gestión del
Ente Gestor a partir de la información de los rangos permitidos para los sensores del STS y
enviada por el Centro de Gestión a los STS. Entre los tipos de alarmas que se deben poder
generar se encuentran:

• Exceso de velocidad
• Aceleraciones y frenadas bruscas
• Ausencia de imagen en alguna de las cámaras del CCTV
• Ausencia de imagen en la cámara del conductor
• Ausencia de imagen en la cámara delantera y/o trasera
• Ausencia de respuesta del sistema de divulgación de información o del esquema de
entretenimiento al interior del bus

Esta parametrización debe realizarse:

• Por primera vez cuando el sistema se implemente.

• Cada vez que se realice un ajuste o cambio en los dispositivos del STS.
• Cada vez que se genere un nuevo tipo de alarma.
• Cada vez que se genere un cambio en la parametrización de los rangos permitidos.

Nota: El STS en conjunción con los diversos sensores de motor y de cabina, deberán exponer
una serie de alarmas que estarán parametrizas y configuradas en el Centro de Gestión. En este
sentido, se requieren definir los umbrales que determinen comportamientos anómalos en
función a los sensores desplegados. Entre las alarmas, pueden considerarse las siguientes y
otras que se definan con el proceder de la implementación: cuando se de reversa en el vehículo,
cuando se suba la temperatura de la cabina o del motor, cuando se exceda la velocidad, cuando
fallen los frenos indicando el espesor de las pastillas, cuando se frene de manera brusca cuando
haya exceso de aceleración y cuando se hagan giros bruscos. Todo lo anterior deberá estar
presente en la trama de datos que se genere desde el bus y deberá estar alineada a los
diccionarios de datos que defina El Ente Gestor.

RF012: El STS debe implementar una función para detectar cuando los dispositivos de
seguridad registren un valor fuera del rango permitido y se genere una alarma al Centro de
Gestión.

RF013: El STS debe implementar una función para registrar los datos de la alarma generada al
Centro de Gestión mínimo con la fecha-hora de su emisión.

Luego de los requerimientos generales, a continuación, se describen los requisitos particulares

de cada uno de los sensores incorporados en la cabina y en el motor:

A) Sensor de reversa

Requisitos funcionales

RF001: El sensor de reversa debe identificar los momentos cuando el vehículo este realizando
maniobras de reversa, es decir, al momento en que el conductor establezca mediante la palanca

40
de cambios “la reversa”. Seguidamente, este sensor de apoyarse en otros sensores de
proximidad traseros y al mismo tiempo, debe entrar el video de la cámara trasera en la interfaz
del conductor para que este, tenga un apoyo visual. Se resalta que para esta última
funcionalidad debe proveerla el concesionario de provisión para ser desplegada en
equipamento ya dispuesto en los buses y que hacen parte del SIRCI, es decir, el dato de este
sensor es el que determinara la entrada de imagen a las pantallas ya dispuestas por el SIRCI.

RF002: El sensor de reversa debe alertar al conductor sobre los obstáculos en las maniobras de
reversa.

RF003: El STS debe implementar una función para guardar en el dispositivo de almacenamiento
los datos capturados desde el sensor de reversa cada (1) minuto mientras el vehículo esté
haciendo esta maniobra. Este intervalo de tiempo debe ser parametrizable a solicitud del Ente
Gestor

RF004: El rango de detección del sensor de reversa debe estar entre 0.3 metros y 2 metros

RF005: Los ángulos de detección deben ser mayores de 60° para horizontal y mayor de 60° para
vertical.

RF006: La protección que debe seguir este sensor es IP67

RF007: Su temperatura de operación debe estar al menos entre -10°C y hasta 70°C

Requisitos no funcionales

• Confiabilidad

RNFS001: El sensor de reversa debe tener un MTBF igual o mayor a cuarenta mil (40.000) horas

• Disponibilidad

RNFS002: El sensor de reversa debe tener una disponibilidad diaria del noventa y nueve por
ciento (99%) durante el tiempo de operación, pero en todo caso deberán cumplir los ANS
establecidos en el anexo de Niveles de Servicio.

• Rendimiento

RNFS003: El tiempo de respuesta del sensor de reversa no debe superar los trescientos (300)
milisegundos.

Especificaciones técnicas del equipo

Característica Especificación técnica

Rango de detección 0.3 a 2.0 metros
Angulo de detección Horizontal > 60° y Vertical > 60°
Temperatura Entre -20C° a +70C°
Protección IP67

41
 Frecuencia de 40Khz
Ultrasonido
Componentes De 4 a 8 sensores de proximidad dependiendo del area del
habitáculo donde se disponen estos sensores

B) Sensor de temperatura

Requisitos funcionales

RF001: El sensor de temperatura debe medir la temperatura del motor del vehículo, teniendo
de referencia su tipología, esto debe articularse a los datos del CANBUS que ofrece el vehículo.

RF002: El sensor de temperatura debe alertar visualmente al conductor del incremento de los
parámetros de la temperatura refrigerante.

Requisitos no funcionales

• Confiabilidad

RNFS001: El sensor de temperatura debe tener un MTBF igual o mayor a cuarenta mil (40.000)
horas

• Disponibilidad

RNFS002: El sensor de temperatura debe tener una disponibilidad diaria del noventa y nueve
por ciento (99%) durante el tiempo de operación, pero en todo caso deberán cumplir los ANS
establecidos en el anexo de Niveles de Servicio.

Especificaciones técnicas del equipo

Característica Especificación técnica

Temperatura Entre -40C° a +210C°
Protección IP68
Estándar IEC 60738-1
Tiempo de Siete (7) segundos
respuesta

C) Sensor de velocidad

Requisitos funcionales

RF001: El sensor de velocidad debe detectar la velocidad que lleva el vehículo cada veinte (20)
segundos.

RF002: El STS debe implementar una función para guardar en el dispositivo de almacenamiento
cada veinte (20) segundos la velocidad y aceleración del vehículo junto con las coordenadas

42
geográficas mientras el vehículo esté encendido. El intervalo debe ser parametrizable a
solicitud del Ente Gestor.

RF003: El STS debe implementar una función para reportar con opción de valor parametrizable
al Centro de Gestión asignado por El Ente Gestor la velocidad y aceleración del vehículo, junto
con las coordenadas geográficas, fecha y hora, cada veinte (20) segundos mientras el vehículo
esté encendido. Para esto, debe utilizar el procedimiento (servicio web con XML o enfoques
REST ambos con esquemas de seguridad) establecido por el Centro de Gestión del Ente Gestor
y enviar la información en la trama definida por El Ente Gestor para el envío de los datos }.

RF004: El STS debe implementar la función necesaria para parametrizar los tipos de alarmas
basadas en eventos que se pueden generar al Centro de Gestión asignado por El Ente Gestor a
partir de la información del rango permitido de velocidad.

RF005: El sensor de velocidad debe generar una alarma visual al conductor, cuando el vehículo
exceda el rango permitido de velocidad.

RF006: El STS debe implementar una función para registrar la fecha-hora del reporte al Centro
de Gestión de la velocidad y aceleración del vehículo junto con las coordenadas geográficas.

Requisitos no funcionales

• Confiabilidad

RNFS001: El sensor de velocidad debe tener un MTBF igual o mayor a cuarenta mil (40.000)
horas

• Disponibilidad

RNFS002: El sensor de velocidad debe tener una disponibilidad diaria del noventa y nueve por
ciento (99%) durante el tiempo de operación, pero en todo caso deberán cumplir los ANS
establecidos en el anexo de Niveles de Servicio.

Especificaciones técnicas del equipo

Característica Especificación técnica

Temperatura Entre -30C° a +75C°
Protección IP54
Rango de voltaje 3 Vdc to 24 Vdc
Rango de 5km/h to 255km/h
velocidad
Precisión +-2%

D) Sensor de frenos

Requisitos funcionales

43
RF001: El sensor de frenos debe detectar el desgaste de las pastillas de frenos

RF002: El sensor de frenos debe alertar visualmente al conductor cuando detecte el desgaste
de las pastillas de frenos.

RF003: El STS debe implementar la función necesaria para parametrizar los tipos de alarmas
que se pueden generar al Centro de Gestión asignado por El Ente Gestor a partir de la
información de desgaste de las pastillas de frenos.

Requisitos no funcionales

• Confiabilidad

RNFS001: El sensor de frenos debe tener un MTBF igual o mayor a cuarenta mil (40.000) horas

• Disponibilidad

RNFS002: El sensor de velocidad debe tener una disponibilidad diaria del cien por ciento (99%)
durante el tiempo de operación.

E) Sensor de aceleración

Requisitos funcionales

RF001: El sensor de aceleración debe detectar la aceleración que lleva el vehículo cada veinte
(20) segundos.

RF002: El sensor de aceleración debe detectar las frenadas bruscas del vehículo.

RF004: El STS debe implementar una función para reportar con opción de valor parametrizable
al Centro de Gestión asignado por El Ente Gestor la aceleración del vehículo junto con las
coordenadas geográficas, fecha y hora, cada veinte (20) segundos mientras el vehículo esté
encendido. Para esto, debe utilizar el procedimiento (servicio web con XML o enfoques REST
ambos con esquemas de seguridad) establecido por el Centro de Gestión y enviar la información
en la trama definida por El Ente Gestor para el envío de los datos

RF005: El STS debe implementar la función necesaria para parametrizar los tipos de alarmas
que se pueden generar al Centro de Gestión asignado por El Ente Gestor, a partir de la
información de los rangos permitidos para las aceleraciones y frenadas bruscas del vehículo.

Requisitos no funcionales

• Confiabilidad

RNFS001: El sensor de aceleración debe tener un MTBF igual o mayor a cuarenta mil (40.000)
horas

• Disponibilidad

RNFS002: El sensor de aceleración debe tener una disponibilidad diaria del noventa y nueve
por ciento (99%) durante el tiempo de operación , pero en todo caso deberán cumplir los ANS
establecidos en el anexo de Niveles de Servicio.

44
Especificaciones técnicas del equipo

Característica Especificación técnica

Temperatura Entre -30C° a +75C°
Protección IP67
Rango de +-0.26g a +- 18g (1g = 9.81 m/s2)
aclaración
Precisión +-0.003g

F) Sensor de kilometraje

Requisitos funcionales

RF001: El sensor de kilometraje debe detectar el kilometraje recorrido por el vehículo, debe
partir de lo que entrega el odómetro y generar su iteración con cada ruta recorrida por el
vehículo tanto en vacío como en operación.

RF002: El STS debe implementar una función para guardar en el dispositivo de almacenamiento
los datos capturados del sensor de kilometraje cada (1) minuto mientras el vehículo esté
encendido. El intervalo debe ser parametrizable a solicitud del Ente Gestor.

Nota: el sensor de kilometraje normalmente es el odómetro, pero también desde el STS se debe
tener la funcionalidad de poder incorporar el dato de distancia en kilometraje obtenido a partir
del GPS y así, enviar ambos datos al STS y posteriormente al centro de gestión.

Especificaciones técnicas del equipo

Característica Especificación técnica

Temperatura Entre -40C° a +85C°
Protección IP68
Choque/Vibración IEC 61373, Cat. 3
EMC EN 50121-3-2

G) Sensor de combustible o del tipo de tecnología (hibrida, eléctrica, gas) que haga sus
veces

Requisitos funcionales

RF001: El sensor de combustible o del tipo de tecnología que haga sus veces debe detectar los
consumos de combustible del vehículo (dependiente de la tecnología del motor del vehículo).

RF002: El STS o dispositivo de integración de la telemetría debe implementar una función para
guardar en el dispositivo de almacenamiento los datos capturados del rendimiento del motor y
el sensor de combustible (dependiente de la tecnología del motor del vehículo) cada un (1)

45
minuto mientras el vehículo esté encendido. El intervalo debe ser parametrizable a solicitud del
Ente Gestor.

Especificaciones técnicas del equipo

Característica Especificación técnica

Temperatura Entre -40C° a +85C°
Protección IP68
Precisión +-1%

Nota: Se requiere que, en el esquema de medición de los sensores expuestos, sean tenidos en
cuenta todos los sensores con que cuenta el vehículo a través de sus diversas ECUs y que tienen
sus valores en el CANBUS del vehículo y que aportan a las variables que contiene este anexo.
Para todo esto, se requiere que el Concesionario de Provisión realice los ajustes requeridos para
llevar esta información al STS teniendo en cuenta que esto es para generar esquemas de
seguridad vial y de servicios para la operación y posiblemente y si El Ente Gestor lo estima
conveniente, se pueden generar información específica para los usuarios. La información de
telemetría del bus debe ser transparente para El Ente Gestor y esta deberá tener los
procesamientos a que haya lugar ya sea para enviar al STS o procesarla en este mismo
dispositivo. Por último, para enviar esta información al Centro de Gestión se debe seguir de
forma homogénea, los diccionarios de datos que El Ente Gestor defina.

H) Sensor de apertura y cierre de puertas

Requisitos funcionales:

RF001: Este sensor debe estar conectado a la unidad lógica del SIRCI y al STS para las
respectivas señales a emitir. Es una señal individual por cada una de las puertas del bus
debidamente identificada en la cual cuando la puerta este abierta, entregue una señal constante
del voltaje nominal del bus (12 o 24 voltios) y cuando la puerta está cerrada, entregue una señal
constante de cero (0) voltios.

RF002: una vez se cierra la puerta deberá emitir al Centro de Gestion la cantidad de pasajeros
que suben y bajan del vehículo

Requisitos no funcionales:

Instalación:

RNF001: La ductería desde cada puerta (coraza) debe ser cerrada de 1” hasta el habitáculo de
equipos SIRCI, esta ductería debe quedar sujeta a la carrocería del bus en todo su recorrido, se
debe generar una ruta alejada de partes calientes, partes rugosas, cantos afilados y evitar roce
con elementos móviles.

RNF002: La ductería debe ser continua con cable guía, tener cajas de inspección intermedias, la
ductería no debe tener empalmes en su recorrido, no debe estar obstruía o prensada con las

46
estructuras o carrocería del bus y no se deben tener más de dos curvas entre cajas de inspección
y se debe garantizar el correcto cierre y encuadre de cada hoja.

I) Sistema de conteo de pasajeros

Este sistema tiene como fin el conteo de las personas que ingresan y salen del vehículo, una vez
las puertas se han cerrado. En esencia el Ente Gestor solamente se focaliza en los datos que
entrega este sistema, que luego de su procesamiento, debe enviar la relación de pasajeros que
entra o sale al momento de cerrar las puertas del bus al Centro de Gestión. Así mismo, el
Concesionario de Provisión deberá hacer las adecuaciones necesarias en términos de que este
sistema funcione adecuadamente. El envío de la información deberá estar acorde con los
diccionarios de datos que establezca El Ente Gestor.

Requisitos funcionales:

RF001: Este sistema debe estar conectado al sistema STS para enviar la información del conteo
de pasajeros al momento de cierre de puertas, tanto los que se suben como los que se bajan.
Estos datos deben asociarse a cada una de las puertas del vehículo y luego deben tenerse datos
compilados por día por bus de los pasajeros que se suben o se bajan, estos datos deben ser
almacenados durante mínimo 30 días .

RF002: El sistema debe garantizar conteo de pasajeros tanto los de subida, como los de bajada
y deberá tener la posibilidad, de acuerdo con cálculos realizados en determinar la cantidad de
pasajeros que quedan. Los datos que entrega este sistema deben ser enviados al Centro de
Gestión cada vez que se cierren las puertas teniendo de referencia el procedimiento (servicio
web con XML o enfoques REST ambos con esquemas de seguridad) establecido por el Centro
de Gestión del Ente Gestor para el envío de esta información.

RF003: El sistema se activará en la apertura y cierre de las puertas, y debe garantizar en

términos de conteo al menos una precisión de los datos del noventa por ciento (90%) en cada
toma de datos. Para llegar a esta precisión, se realizaran y diseñaran pruebas conjuntas con los
oferentes para tener al menos ese umbral y esto debe ser articulado a los lineamientos que
estipule el Ente Gestor.

RF004: El sistema debe articularse a los sensores de cierre de puertas en aras de cumplir con
los requerimientos que se expone El Ente Gestor en el contexto de este sensor o sistema.

RF005: El Concesionario de Provisión se compromete a garantizar las condiciones idóneas

funcionales del sistema de conteo. Dentro de estas condiciones se debe considerar las variables
de iluminación, alistamiento, ubicación, entre otras; sin embargo, esto es dependiente de las
condiciones del sistema a instalar.

Requisitos no funcionales:

Instalación:

47
RNF001: La instalación de la caja de la interfaz del sistema debe ser accesible por los Usuarios
autorizados por el Concesionario de Operación. El usuario no debe estar en la capacidad de
acceder fácilmente al sistema que tenga la descrita funcionalidad previniendo así, posibles
vandalismos o daños indirectos.

RNF002: Los elementos de hardware de este sistema deberán ir acondicionados a la ductería

del vehículo respetando las normas de despliegue de cableado en los buses.

Nota: En caso de que este sistema se apoye en diversos elementos tecnológicos y de ITS, el
Concesionario de Provisión deberá garantizar el suministro eléctrico de su solución e incluso
su interoperabilidad con el STS para él envió posterior de la información al Centro de Gestión,
todo esto, siguiendo los procedimientos (servicio web o esquemas REST ambos con los
esquemas de seguridad que estipule El Ente Gestor) establecidos por El Ente Gestor. Así mismo,
se debe presentar la solución tecnológica al Ente Gestor para que este conozca los elementos
que contiene este sistema y su ubicación deberá ser validada por El Ente Gestor.

J) Planos e información de la carrocería

El Concesionario de Provisión debe entregarle a el(los) concesionario(s) del SIRCI, los planos
correspondientes de la instalación de ducterías y soportería en el bus y descripción de señales
entregadas en el gabinete de los equipos de control de flota.

Los cableados y señales deben estar identificados dentro del habitáculo de equipos SIRCI y en
general de todos los demás

Se deben entregar los planos debidamente acotados correspondientes a los refuerzos o

soportes en la carrocería en donde se van a fijar los equipos SIRCI.

K) Señales y voltajes requeridos para el SIRCI

Las señales y el voltaje de alimentación deben ser las establecidas por el(los) Concesionario(s)
del SIRCI entre los cuales se informa de manera no exclulsiva los siguientes: debe utilizar
conectores de 3x3 de nueve (9) vías dentro del habitáculo de equipos SIRCI con ignición (+15)
constante y con su respectiva protección eléctrica desde carrocería con capacidad de 5
amperios.

El voltaje de alimentación constante para accesorios señal +30 (24V DC), con protección
eléctrica desde la carrocería, con capacidad de una corriente máxima de quince (15) amperios,
exclusivo para los equipos de control de flota y recaudo SIRCI.

Señal de tierra (GND), capacidad de una corriente máxima de quince (15) amperios y con
continuidad a la tierra (GND) de chasis, exclusivo para los equipos de control de flota y recaudo
SIRCI.

Nota: Esto de articularse a lo requerido por el SIRCI

L) Especificaciones, conexiones y demás ajustes requeridos por el SIRCI

48
Estas especificaciones serán entregadas previamente por el(lo) concesionario(s) del SIRCI al
momento previo de la instalación del equipamiento SIRCI a bordo, tal como se establece en el
“Protocolo de Articulación Vigente” y como se informó en el cuarto de datos del presente
proceso.

3.3 Otros aditamentos para mejor interacción con el Usuario

En este apartado se especifican los requisitos funcionales y no funcionales de otros elementos

o aditamentos que permitirán una mejor interacción con el usuario. Estos aditamentos están
centrados en brindar nuevos servicios de gestión para el Ente Gestor y para mejorar la
experiencia de los usuarios mientras estos usan el servicio de transporte público. Se resalta que
para la implementación de los aditamentos pertenecientes al STDI se requiere que el
Concesionario de Operación junto con el Concesionario de Provisión articulen una propuesta
única para su despliegue y esto estará en consonancia con los lineamientos que defina el Ente
gestor, todo esto, en aras de brindar otros servicios de valor agregado o adicionales a los
usuarios.

Entiéndase por “servicios adicionales” o “Negocios Colaterales” todas las actividades lucrativas,
comerciales o institucionales que se reserva de manera exclusiva TRANSMILENIO S.A. y que
pueden desarrollarse dentro del marco de la Ley Aplicable, a partir del valor agregado o de los
usos comerciales alternativos de la infraestructura y de los buses del Sistema, y de los activos o
valores intangibles que se derivan de la actividad ordinaria del SITP, entre ellas la publicidad
en la flota y en los patios. La explotación de los Servicios Adicionales estará regulada en el
contrato que suscriba TRANSMILENIO S.A. con el (los) Concesionario(s) de Operación y en
articulación con el Concesionario de Provisión debido a que ambas partes deben presentar una
propuesta conjunta para este fin. En este sentido, todos los servicios que discurran desde el
STDI, las pantallas y el WIFI (numerales 3.3.5, 3.3.6 y 3.3.8) pueden ser diseñados por los
oferentes y articulados en consonancia con lo que establezca el Ente Gestor en aras de generar
una mejor experiencia de viaje a los usuarios de las respectivas flotas. Se recuerda que para el
STDI y el WIFI deberá diseñarse e implementarse por parte del oferente una aplicación para
acceder a sus servicios la cual deberá tener en cuenta los lineamientos del ente gestor sin
limitaciones ni costos para este Ente Gestor. En esencia, incluso en términos de servicios a
través del STDI es posible generar multiplicidad de servicios de información o comunicación
con el usuario. Para este punto es de resaltar que estos elementos del STDI son obligatorios en
la flota y tienen por objetivo mejorar la interacción con el usuario (Pantallas, router, VOD,
inversores si hay lugar, antenas, etc., sin limitarse a los aquí enunciados).

3.3.1 Ruteros

Equipos utilizados por los buses para desplegar información acerca del destino de cada uno de
los buses, así como su nomenclatura u otros mensajes que determine El Ente Gestor. A nivel
visual deberán cumplir con lo establecido en este anexo y en el manual de imagen y normas
gráficas del Ente Gestor.

RF001: Los ruteros debe permitir la configuración manual (in situ o a través de consola o una
aplicación basada en servicios) o de forma automática sin intervención humana solo leyendo lo

49
que se le ha cargado. Los ruteros deben disponer funcionalmente de un esquema de diccionario
de datos homogéneo para su integración de forma transparente a través de diferentes fuentes
de configuración, sin embargo, la fuente principal de mensajes es el SIRCI y estos mensajes
deberán configurarse incluso antes de la vinculación del bus

RF002: En su configuración alterna, los ruteros deben poder recibir información desde el centro
de control (archivos con programación de rutas) y reflejarla en tiempo real en estos, o ser capaz
de manejar de forma estática la información de programación de las rutas para ser desplegadas
en el rutero (también en esquema de batch si se pierde comunicación con el rutero). Los
Ruteros debe tener esquemas de geolocalización para articular la información que despliega
con el lugar por donde va el bus e indicar y registrar si el bus va fuera de operación (en tránsito
por ejemplo) y tener información de respuesta hacia lo que defina Transmilenio en su centro
de gestión y/o Centro de Control. Este dispositivo debe ser controlado por la unidad lógica del
SIRCI y adicionalmente, debe enviar datos al STS en tramas abiertas y que sean leíbles e
interpretadas desde este dispositivo o es posible utilizar otro recurso Hardware/Software
independiente, pero con conexión al STS. Igualmente, debe ser posible compartir la información
de la geolocalización y de la ruta realizada al Sistema Tecnológico de Divulgación de
información (STDI) mediante una trama diseñada para tal fin que sea abierta, consumible e
interpretable por el STDI o que sea proveniente desde otro equipo hardware/software que
apoye los datos de geolocalización y de la ruta al STDI. Posteriormente del procesamiento de
dicha trama en el STDI, debe ser posible mostrarle a los usuarios la ubicación del bus durante
el recorrido, así como informarle a Transmilenio S.A. si el vehículo se encuentra fuera de
operación con mensajes como ”En Tránsito” u otros definidos y autorizados previamente. Este
dispositivo (rutero frontal, posterior y lateral) deberá poder recibir información a través de la
trama de datos que envía el Centro de Control del SIRCI en aras de configurarlo o hacer envío
de mensajes predefinidos (si así lo determinase el Ente Gestor), asimismo, deberá poderse
monitorizarse para saber si está respondiendo. Sin embargo, se reitera que la fuente de datos
principal de mensajes es el SIRCI.

RF003: Los ruteros deben permitir la configuración de mensajes de alerta para casos de
emergencia. El cual se debe activar de forma automática una vez se obture el pisón de
emergencia o botón de pánico.

RF004: Los ruteros deben tener la capacidad de mostrar pictogramas

RF005: Los ruteros deben ser de diversos tamaños (expuestos estos en los requisitos RF015 y
RF018) o como se determine dependiendo de la tipología del Bus y es, El Ente Gestor quien
avalará su instalación en base a pruebas y calidad de imagen que este produzca y al Manual de
imagen de la entidad.

RF006: Los ruteros deben instalarse en un circuito independiente con las protecciones
eléctricas adecuadas.

RF007: Los ruteros deben estar configurados al momento en que el bus entre en operación de
acuerdo con su ruta.

50
RF008: Los ruteros deberán tener la capacidad de informar mediante un evento al Centro de
control del SIRCI que designe El Ente Gestor que este no está operativo, es decir, debe existir
algún esquema de monitoreo desde alguno de los elementos hardware software que tengan
conexión con este dispositivo.

RF009: los ruteros deben poder desplegar mensajes del tipo “bus en tránsito” o “fuera de ruta”,
en aras de avisar de forma visual un estado del bus. Si se llegase a desplegar un mensaje de este
tipo, se deberá enviar alerta al Ente Gestor con esta condición dado que estos están conectados
en términos de lectura de datos o información al STS.

RF009: Estos dispositivos deben tener la capacidad de ser configurados ya sea vía puerto USB,
IP, o puerto serie RS232/RS485/RS422 (o una combinación de estos) y permitir y/o generar o
tener una interfaz basada en servicios para poder ser configurado transparentemente, y no
manejando protocolos propietarios, todo esto, en aras de que el dispositivo cliente puedas ser
configurado de forma sencilla y rápida. Si no se maneja el enfoque de servicios desde el
dispositivo se requiere la generación de un middleware en el dispositivo de control de fuera
para llegar con facilidad a la configuración del dispositivo.

RF010: Los ruteros deben tener la capacidad de rotar los mensajes de un lado a otro o, de
estabilizar el mensaje. Así mismo, se debe poder disponer del área del rutero para los fines que
determine El Ente Gestor.

RF011: Los ruteros deben contar con baterías de respaldo independientes para su correcto
funcionamiento.

RF012: Los ruteros deben tener la posibilidad de recibir archivos de base de datos actualizada
en remoto (desde el Centro de Control del SIRCI) a toda la flota de vehículos, para ser
desplegados en un tiempo determinado

RF013: Los ruteros deben ser tipo LED con color tipo RGB

RF014: La ubicación de los ruteros es como sigue: uno ubicado en la parte frontal en la zona del
vidrio panorámico delantero; otro que sirva de indicador de destino lateral adyacente a la parte
superior de la primera puerta de servicio (costado derecho del vehículo) y otro que indique el
destino y que sea ubicado en la parte trasera o posterior, ubicado en la parte superior derecha
del vidrio panorámico trasero. En todo caso, será El Ente Gestor quien apruebe su ubicación
final.

RF015: Los ruteros frontales deben generar una buena resolución y como mínimo, su densidad
debe ser de ciento sesenta (160) pixeles de longitud por veinticuatro (24) pixeles de altura
teniendo de referencia que El Ente Gestor avalará la misma o a conveniencia de este para darle
mayores y mejores servicios a los usuarios, al menos, cuando estos están ubicados a una
distancia mínima de cien (100) metros ya sea de día o de noche. La cantidad mínima de
caracteres que debe mostrar el indicador es de 20, y el tamaño mínimo de letra a emplear en
estos ruteros es de 10 pixeles de altura por 6 pixeles de longitud.

RF016: Los ruteros deben tener un sensor lumínico que regule su intensidad de luz a partir de
las condiciones lumínicas del exterior

51
RF017: Los ruteros deben tener una disponibilidad diaria de al menos el noventa y nueve por
ciento (99%) durante el tiempo de operación, pero en todo caso deberán cumplir los ANS
establecidos en el anexo de Niveles de Servicio.

RF018: Los ruteros laterales y posteriores deben generar una buena resolución y como mínimo,
su densidad debe ser de sesenta y cuatro (64) pixeles de longitud por trece (13) pixeles de
altura, sin perjuicio de contar con un diseño que permita la lectura desde una distancia mínima
de 100 metros tanto de día como de noche; teniendo de referencia que El Ente Gestor avalará
la misma o a conveniencia de este para darle mayores y mejores servicios a los usuarios. La
cantidad mínima de caracteres que debe mostrar el indicador es de 10, y el tamaño mínimo de
letra a emplear en estos ruteros es de 10 pixeles de altura por 6 pixeles de longitud.

RF019: Los ruteros deben contar con sistemas de ventilación de tal forma que no se presente
empañamiento, es decir, que este dispositivo incorpore controles de temperatura adecuados
para que no se genere este fenómeno al interior del bus y la información que este aparato
despliegue sea visible y clara para los usuarios.

RF020: Todos los ruteros deben generar la posibilidad de gestionarse desde un único
dispositivo hardware/software (en forma manual y automática) y dado que son diversos
ruteros (lateral, posterior y frontal) deben poder desplegarse en esquemas de red industrial
tipo RS485/RS422 o similar o IP, todo esto, para que sea enviada la información de forma
automática a cada uno de los ruteros (pueden manejarse esquemas maestro/esclavo). Todo
este esquema debe ser articulado a la unidad lógica del SIRCI siguiendo los términos
electrónicos y de software que contemple el SIRCI y que deben ser acogidos por el
concesionario de provisión. Las tramas que sean enviadas al otro equipamiento ITS (STDI, STS)
y que sean de lectura de información deben ser abiertas, consumibles e interpretables para que
estos dispositivos puedan tomar esa información y puedan desarrollar las funcionalidades a
que haya a lugar. El rutero es un equipo requerido por el SIRCI, por lo que se contempla como
integrado, por ello, el concesionario de provisión debe cubrir todos los insumos y demás costos
adicionales que se tengan en cuenta para satisfacer las funcionalidades aquí descritas.

Requisitos no funcionales

RF001: El rutero debe tener un MTBF (Mean Time Between Failure) o tiempo entre fallas de un
mínimo de sesenta mil (60.000) horas.

RF002: Se requiere una compatibilidad electromagnética de siguiendo normativas UN/ECE R10

y con comportamiento cuando hay fuego (puede ser UN/ECE R118, ISO 6941 u otra similar).

RF003: Los ruteros deben tener al menos un ángulo de visión de 120 ° (Horizontal) y 120°
(Vertical)

Especificaciones técnicas del equipo

Característica Especificación técnica

Definición Elemento que permite mostrar información al usuario hacia el exterior
del bus

52
Característica Especificación técnica
Objetivo Ofrecer mensajes de las rutas y otra información que determine El Ente
Gestor. Así mismo, contar con las funcionalidades descritas sobre los
comportamientos listados anteriormente.
Tipo de Rutero y El rutero frontal debe contar con una densidad mínima de ciento
resolución sesenta (160) pixeles de longitud y veinticuatro (24) pixeles de altura y
los ruteros laterales y posteriores deben contar con una densidad
mínima de ciento sesenta y cuatro (64) pixeles de longitud y trece (13)
pixeles de altura. Debe tener la capacidad de ser configurado de forma
manual o remota y tener para ello, al menos, una interfaz para ser
configurado de forma local por quien autorice El Ente Gestor. Debe
tener la capacidad de ser configurado desde hardware externo poseer
interfaces de comunicaciones asociadas a USB, IP o Seriales
(RS232/RS485/RS422) (o una combinación de estas) o las mas
relevantes, debe permitir mostrar distintas combinaciones de colores:
mensajes con letras de color, fondo de color o un área específica
destinada a mostrar el color elegido. Permitir que la información pueda
ser filas con texto fijo o móvil. El rutero tendrá un sensor lumínico que
regule la intensidad de luz del rutero dependiendo de las condiciones
lumínicas del exterior y llegará como mínimo hasta una intensidad de
5.000 Cd/m²

Temperatura Capacidad de operar con temperaturas entre -10ºC a +50ºC.

Protección FísicaDeben tener características a prueba vandalismo y con protección física
al menos IP30 y se deben aportar al ente gestor experiencias de montaje
real (certificado) en sistemas de transporte público. Sin embargo, estos
ruteros deben ir con algún recubrimiento especial para los temas de
humedad o agua a pesar de que el carrocero disponga el espacio para su
instalación
Compatibilidad Debe cumplir con las normas de compatibilidad electromagnética al
electromagnética menos UN ECE R10 y si es posible R118 para el comportamiento cuando
hay fuego
Almacenamiento El sistema de almacenamiento de este sistema de poder al menos guardar
archivos que sean leídos para mostrar los mensajes pertinentes para
cada uno de los ruteros desplegados al interior del bus.
Comunicaciones Debe tener conectividad WiFI, GPS, ethernet
Software Cada Concesionario de Operación debe disponer de su propia aplicación
para desplegar la información que emita El Ente Gestor en los plazos
establecidos y de forma general realizar la administración de la misma.
Debe permitir ajustes de una o dos filas, según la necesidad

53
Nota 1: Se resalta que en términos energéticos el Concesionario de Provisión y el Concesionario
de Operación deben garantizar el funcionamiento de los ruteros en tiempo de operación, todo
esto en conjunto con el SIRCI.

Nota 2: El concepto rutero/s debe ser entendido como Panel electrónico de acuerdo con el
Manual de imagen de la entidad y debe saberse que son tres en términos de cantidad uno
posterior (trasero), lateral y delantero.

3.3.2 Panel de Información al Pasajero (PIP)

Elemento tecnológico ubicado al interior del bus que muestra por defecto y de forma
automática los mensajes de la(s) próxima(s) parada(s), dependiendo de la ruta que tenga
asignada el bus, el destino de la ruta que esta realizando, la fecha y la hora actual. Esto debe
articularse con el SIRCI.

Nota: Como se ha expuesto a lo largo del documento existen varios dispositivos que si bien es cierto
tienen funcionalidades propias y concretas y que aún así, se relacionan en términos de transmisión
de datos entre sí, por lo que se requerirán que entre ellos exista una articulación especial y que, en
términos electrónicos y de software se contemplen las protecciones eléctricas que se requieran.
En esencia, el PIP, simplemente actúa como un panel de mensajería variable que informa al usuario
lo referente a las paradas del bus y demás información contenida en el numeral 3.3.2, además, debe
estar sincronizado con el sistema de audio del bus para que informe las paradas al usuario de
manera auditiva y de acuerdo con los elementos estándares de mensaje que contiene el ente gestor.
Normalmente este panel se integra a través de algún tipo de bus industrial ya sea RS485, RS422,
entre otros y la trama de datos que a este dispositivo llega, debe ser extensible, abierta, consumible
e interpretable por otro esquema de recepción de datos (caso concreto STDI y STS solo para
esquemas de lectura de información). Esta trama no debe manejar protocolos propietarios para
evitar la dependencia de equipos particulares. Estos paneles podrán ser los mismos enunciados
en el 3.3.6 siempre y cuando cumplan con la funcionalidad anteriormente descrita y las
siguientes: .

Requisitos funcionales

RF001: el PIP debe suministrar información visual, leíble y mediante mensajes variables que
van de un lugar a otro informando mediante mensajes de próxima parada, ruta, fecha y hora, y
todo debe estar articulado al SIRCI quien gobierna este aparato y se recuerda que debe tener
interfaces de lectura hacia el STDI y el STS

RF002: El PIP debe tener tamaños de LED entre 4.0 y 5.0 mm

RF003: El área de visualización del PIP debe estar mínimo entre 434 y 575 mm de largo por 30
a 64 mm de Alto y sobre los valores a instalar, se deberá notificar al ente gestor los mismos

RF003: EL tamaño del PIP deberá ser mínimo de 508x87x55 mm

RF004: El Tamaño de los caracteres del PIP deberá estar entre 30mm x 64mm

54
RF005: El PIP deberá funcionar en esquemas de redes industriales asociados a RS485 u otro
RS422 u otro

Requisitos no funcionales

RNF002: En acero con pintura electrostática o aluminio

RNF003: El PIP debe tener un soporte que aguante su peso y que este debidamente anclado a
la carrocería del bus que cumpla con la norma al IP30

RNF004: El PIP debe tener una disponibilidad diaria de al menos el noventa y nueve por ciento
(99%) durante el tiempo de operación, pero en todo caso deberán cumplir los ANS establecidos
en el anexo de Niveles de Servicio.

3.3.3 Amplificador de Sonido ambiente

La señal emitida por el panel de información al usuario no tiene suficiente potencia para que
los altavoces generen el sonido que transmiten, por lo que es necesario aumentarla mediante
unos amplificadores, a fin de aumentar la amplitud de la señal de sonido.

Requisitos funcionales

RF001: El amplificador de sonido debe aumentar la amplitud de la señal de sonido emitida por
el Panel de Información al Pasajero (PIP) principalmente y de otros dispositivos a bordo según
la prioridad dada.

RF002: El amplificador de sonido debe permitir la configuración de la amplitud y potencia a

aumentar.

RF003: El Ente Gestor será quien valide la fidelidad del amplificador y obviamente de la calidad
de sonido en función de las necesidades de los usuarios

RF004: El esquema de amplificación debe poder contar con un selector que conecte de forma
manual o automática diversas fuentes de sonido ya sea la reproducción por voz de los mensajes
que indican los Paneles de Información al usuario asociada a la información de las paradas o
desde el sistema tecnológico de difusión de información (STDI), o del centro de emisión radial
que en su momento El Ente Gestor designe, o de otra fuente alternativa de audio que se
requiera. Se debe contar también con un esquema de selección tipo prioridad para que se
determine por interrupciones qué sistema de audio debe salir a los parlantes teniendo de
referencia la fuente de audio a sonar. Por defecto, el selector debe estar conectado al sistema
de audio de los PIP y podrá ser cambiado de acuerdo a las instrucciones que estipule el Ente
Gestor.

Requisitos no funcionales

• Integración:

55
RNF001: La amplificación de sonido se debe realizarse en función de las necesidades de
difusión de información y con una fidelidad adecuada al interior de cada una de las tipologías
de buses.

• Disponibilidad

RNF002: El amplificador de sonido debe estar disponible como mínimo el noventa y nueve por
ciento (99%) del tiempo de operación diaria, pero en todo caso deberán cumplir los ANS
establecidos en el anexo de Niveles de Servicio.

Especificaciones técnicas del equipo

Característica Especificación técnica

Frecuencia 20Hz ~ 20 KHz
Ruido ≥80dB
THD ≤0 03%
Máxima potencia activa 25 W 4x4
Temperatura Capacidad de operar con temperaturas entre -5ºC a +50ºC.

3.3.4 Parlantes

Los parlantes son componentes que permiten la emisión de sonido dentro del bus, y su principal
funcionalidad, entre otras, es la de anunciar automáticamente las próximas paradas
programadas o reproducir en estos, mensajes sintetizados en la unidad lógica, o por el centro
de emisión radial y el STDI, dando prioridad en el orden descrito anteriormente.

Requisitos funcionales

RF001: Los parlantes deben anunciar de manera automática las próximas dos (2) paradas
programadas y en general lo que se despliegue en los paneles de información al pasajero (PIP)
principalmente y de otros dispositivos a bordo según la prioridad dada..

RF002: Los parlantes deben permitir la divulgación de mensajes sintetizados provenientes del
STS, STDI y por el centro emisión radial.

RF003: Los parlantes deben ser ubicados de tal forma que la fidelidad del sonido sea adecuada
para los usuarios y esto debe contemplarse de acuerdo con cada una de las tipologías de cada
bus.

RF004: la intensidad del sonido se podrá ajustar para que se mantenga en un rango, pero nunca
se podrá apagar.

Requisitos no funcionales

• Integración:

56
RNF001: La emisión de sonido debe realizar en base a las diversas fuentes de sonido descritas
en este documento

• Disponibilidad

RNF002: Los Parlantes de sonido deben estar disponibles como mínimo el noventa y nueve por
ciento (99%) del tiempo de operación diaria, pero en todo caso deberán cumplir los ANS
establecidos en el anexo de Niveles de Servicio.

• Confiabilidad

RNF003: Ante condiciones de máximo uso del vehículo, los parlantes deben permitir que el
audio sea escuchado desde todas las posiciones al interior del bus según normas de calidad de
voz o a la que haya lugar o la que determine El Ente Gestor.

RNF004: La fidelidad del sonido en las diversas tipologías de los buses zonales deberán contar
con la aprobación de un profesional en ingeniería de sonido que determine su fidelidad y en
concordancia con lo que establezca el Ente Gestor.

Especificaciones técnicas del equipo

Característica Especificación técnica

Potencia >= 25 W
Impedancia 4 Ohms
Temperatura Capacidad de operar con temperaturas entre -5ºC a +50ºC.
Frecuencia 20 -60Hz a 16 kHz**
SNR (Relación señal De 75 dB a 90 dB
ruido)
**: Este rango de frecuencia en su parte superior es variable hacia frecuencias mayores a 16KHz,
la mínima es 16KHz. En la cota inferior de frecuencia es posible manejar un rango de inicio que
puede comenzar desde 20 Hz hasta 60Hz pero no ningún otro.

Nota: El amplificador y los parlantes que se dispondrán al interior del bus deben estar
articulados en aras de contar con los parámetros de fidelidad hacia los usuarios y se deberán
articular al sistema selector de sonido dependiendo de la priorización del mismo desde las
diferentes fuentes que pueden usar el canal de audio del bus.

3.3.5 Sistema Tecnológico para la divulgación de información (STDI)

Este sistema tiene como fin la divulgación de información del tipo que considere El Ente Gestor
al interior de cada uno de los buses. Así mismo, el STDI debe tener la capacidad de recibir
información y desplegarla de forma dinámica sobre, al menos, una pantalla de 24 pulgadas
dispuesta al interior del Bus. La generación de los contenidos institucionales estará a cargo del
Ente Gestor o de quien este designe para este fin; sin embargo, el Ente Gestor podrá adelantar
gestiones de publicidad que deberán ser acogidas por el Concesionario de Operación y este a su
vez, podrá presentar las propuestas de contenidos en el que deberá incluir entre otros la

57
frecuencia de cambio, los contenidos, y los posibles acuerdos de negocios colaterales, a fin de
que estos sean aprobados o no por el Ente Gestor., se recuerda que la información desplegada
en este dispositivo debe tener la posibilidad de ser generada por áreas para mayor utilización
de la pantalla a partir de diversos contenidos que se requieran. El STDI en esencia, tiene como
objetivo es controlar y divulgar contenidos de interés a los usuarios o incluso publicidad. En
caso de incluir temas publicitarios se deberán validar con el Ente Gestor las consideraciones en
términos de negocios colaterales que puedan surgir para la entidad. En todo caso, el
responsable de la actualización del contenido en el STDI es el Concesionario de Operación.

Requisitos funcionales

RF001: El STDI debe tener la capacidad de recibir información desde la interfaz del Centro de
Gestión si así lo dispusiese El Ente Gestor, o desde interfaz independiente que determine El Ente
Gestor para enviar los contenidos que al STDI. Por lo anterior, se requiere un esquema de
articulación entre estas plataformas del STDI para poder enviar homogéneamente esta
información. En este sentido las plataformas al interior del bus deberán contar con esquemas
basados en servicios homogéneos para poder publicar la información que se desea desde El
Ente Gestor y deben seguir diccionarios de datos similares para facilitar la interoperabilidad de
las plataformas.

RF002: El STDI debe recibir la información publicitaria e informativa enviada desde El Ente
Gestor o quien este designe previa autorización, a través de servicios web bajo túneles cifrados
establecidos mediante protocolos seguros de doble vía.

RF003: El STDI debe desplegar la información recibida de las diferentes fuentes hacia la/s
pantalla/s integradas en el bus a través de servicios Web.

RF004: El STDI debe incorporar la señal del sensor geográfico del STS o la señal de los ruteros
para que la pantalla también muestre de forma automática al usuario el recorrido del bus en un
mapa cartográfico (este mapa puede estar siempre visible en uno de los cuadros que se estimen
en la pantalla y debe ser parametrizable por El Ente Gestor).

RF005: El STDI debe incorporar un sistema de entretenimiento para la difusión de contenido

pre-grabado (películas, documentales, series, entre otras), con una capacidad mínima de 500
GB y que deberá ser escalable en función de los negocios colaterales que sean desarrollados por
el Concesionario de Operación en articulación con el Concesionario de Provisión y el Ente
Gestor. Los contenidos que se generen desde el STDI deberán ser desplegado a través de una
red WiFi propia del bus.

RF006: El sistema de entretenimiento del STDI debe ser parametrizable y replicable para todos
los buses que tengan incorporada esta funcionalidad a través de la disposición de un sistema
de video bajo demanda o VOD que, de hecho, puede estar a cargo del Centro de Gestión o de
forma paralela, puede estar a cargo de la Subgerencia de Atención al Usuario y Comunicaciones
del Ente Gestor o de quien este determine o por un actor independiente que designe El Ente
Gestor. El sistema de entretenimiento también debe ser parametrizable por enfoques Web. Se
resalta que los esquemas VOD deben estar operativos en el propio Bus, es decir, los contenidos
deben estar almacenados en local para evitar el alto consumo de ancho de banda y esto debe

58
ser parametrizable por lo que indique El Ente Gestor. Se resalta que al estar los contenidos
almacenados en la unidad que controla el STDI son relativamente alcanzados fácilmente por el
usuario, previa identificación del usuario en la aplicación Web que opera en el bus.

RF007: El consumo de la información asociada al STDI debe realizarse al menos desde una
aplicación Web que permita el acceso a los contenidos que sean definidos en consonancia con
el Ente Gestor. La aplicación Web debe seguir los lineamientos de diseño de lo estipulado por
la Subgerencia de Desarrollo de Negocios y/o la Subgerencia de Comunicaciones y Atención al
Usuario o quien haga sus veces , así como los contenidos a que haya lugar. El Front End de la
aplicación web deberá ser homogéneo en toda la flota de buses a modo de no confundir a los
usuarios con diferentes interfaces para el consumo de los servicios al interior de bus. Se resalta
que el STDI debe tener un esquema de administración de la información, y el Concesionario que
presente esta solución deberá sugerir que esquema es posible utilizar para la difusión de
contenidos, sin embargo, es El Ente Gestor es quien aprobará este esquema y los demás
interesados en desplegar el STDI deberán ajustarse a las decisiones del Ente Gestor para que
exista homogeneidad en la transmisión de información para este sistema. Adicionalmente, los
parámetros que son configurables en cuanto a la red Wifi tal como el SSID o nombre, deberán ser acogidos
como lo indique el Ente gestor.

RF008: El STDI debe estar conformado por un esquema computarizado abordo que permita su
gestión de forma remota y para los contenidos que se den a lugar por parte del Ente Gestor.

RF009: El STDI debe tener la suficiencia de al menos poder gestionar dos pantallas.

RF010: El STDI debe entrar siempre en funcionamiento con una configuración mínima de
mensajes que deberá ser articulada por El Ente Gestor, esto al momento de encender el
vehículo. Por último, el STDI deberá apagarse al momento de terminar el recorrido del bus. Este
dispositivo debe configurarse en un tiempo menor a cinco (5) minutos.

RF011: Los lineamientos sobre la periodicidad de actualización del contenido generado por el
Ente Gestor o quien este determine, será informado oportunamente por el Ente Gestor al
Concesionario de Operación para su posterior despliegue; para las sugerencias de contenido
publicitario, el concesionario de operación en conjunto con el Concesionario de Provisión podrá
presentar las propuestas en las que se deben incluir entre otros la frecuencia de cambio, los
contenidos, y los posibles acuerdos de negocios colaterales, a fin de que estos sean aprobados
o no por el Ente Gestor.

Requisitos no funcionales

• Integración:

RNF001: El STDI debe integrar el dato del rutero a partir de la información del
geoposicionamiento y la información de las paradas y desplegarlos sobre el STDI (mediante sus
pantallas de visualización). Así mismo, debe integrar la salida de audio del STDI al sistema de
audio del vehículo para que los mensajes sean escuchados en el sistema de audio a lo largo del
bus.

59
RNF002: El STDI debe estar sincronizado bajo la misma referencia de tiempo del Centro de
Gestión, o del sistema independiente o el que determine El Ente Gestor par la actualización de
contenidos de forma remota. Esto se debe realizar con servidores de tiempo abiertos y
confiables a través del protocolo NTP.

• Disponibilidad

RNF003: El STDI debe estar disponible el noventa y nueve punto nueve por ciento (99.9%) del
tiempo de operación diaria, pero en todo caso deberán cumplir los ANS establecidos en el anexo
de Niveles de Servicio.

• Rendimiento

RNF004: El STDI debe garantizar un tiempo de respuesta (latencia) menor a quince (15)
segundos, para actualizar la información recibida desde El Ente Gestor o desde el SIRCI. Sin
embargo, esto es dependiente del mensaje o imagen que se desee desplegar en el dispositivo.

RNF005: El STDI debe garantizar un tiempo de respuesta (latencia) menor a diez (10) segundos
en el despliegue de información en las pantallas del bus. Esto es dependiente de que tan pesada
es la información para cargar.

• Seguridad

RNF005: Todas las conexiones con el STDI deben establecerse a través de HTTPS, SSH o
equivalente.

Especificaciones técnicas de los equipos

Dentro del STDI deben ser incorporados los siguientes componentes de hardware

Elemento Características técnicas

Inversor de corriente (este 24-30 voltios DC
elemento podría ser 300 watts
incorporado si existe necesidad Fusible de protección
o se despliega una pantalla a
110VAC, también podría
incorporarse pantalla en 24 VDC
la cual no requeriría inversor)
Clavija Hembra 120 voltios
2 polos
Clavija Macho 120 voltios
2 polos
Con abrazadera
Cable encauchado 2 vías
Calibre 12
Relay 24 voltios

60
 10/20 Amperios
Socket Relay 5 pines
Fusible Americano 10 amperios
Cable baja Calibre 10, 16 y 18
Conector Hembra-Macho plano mediano
2 vías
Terminal de Ojo Diámetro de ojo 8 y 10 milímetros
Terminal plana Hembra y Macho mediana
Otros Tornillo, Coraza plástica y abrazadera metálica

3.3.6 Pantallas Informativas

Las pantallas informativas permiten la representación de la información publicitaria e

informativa dentro de los buses.

Requisitos funcionales

RF001: La pantalla informativa (dispositivo que hace parte del STDI) debe conectarse con el
sistema de rutero del bus, este último y como se expuso anteriormente en la sección 3.3.1, debe
proveer la geolocalización del vehículo para ser dispuesta en la pantalla y que sirva de fines de
información hacia el usuario, es decir, en la pantalla deberá ser posible ver en qué punto
específico va el bus (en un mapa). Se recuerda que la pantalla debe tener la capacidad de ser
dividida en segmentos por lo que, un segmento específico, deberá disponer esta información
para los usuarios. .

RF002: La pantalla informativa debe estar conectada con el sistema de audio del bus.

RF003: La pantalla informativa debe tener integrado un computador que permita controlar la
pantalla y sus contenidos tanto local como de forma remota

RF004: La pantalla informativa debe contar con una aplicación ya sea Web o la que se determine
y que deberá avalarla El Ente Gestor para que distribuya la información a la pantalla con
mensajes informativos, preventivos, campañas de sensibilización y/o publicitarios o lo que El
Ente Gestor considere para su cometido, incluyendo información relacionada con acciones de
promoción a la seguridad viales y los riesgos sobre el comportamiento de los actores viales
durante el desplazamiento.

RF005: La transmisión y recepción de datos deberá realizarse en base a servicios Web usando
canales seguros.

RF006: La pantalla informativa debe incluir la funcionalidad de programación manual o

automática y con conexión remota de acceso cliente y administrador.

RF007: Los elementos de conexión de este dispositivo deberán estar muy bien organizados al
interior del Bus y no deben estar al alcance de los usuarios para su manipulación.

Requisitos no funcionales

61
• Confiabilidad:

RNF001: Las pantallas informativas deben tener un tiempo medio entre fallas (MTBF) igual o
superior a cuarenta mil (40.000) horas.

RNF002: Al menos deberá instalarse una pantalla informativa, sin embargo, el sistema deberá
poder atender al menos dos pantallas y se requiere tener en cuenta su ubicación y ángulo para
que el consumo de contenidos por parte de los usuarios pueda darse de forma general.

• Rendimiento

RNF003: Las pantallas informativas deben garantizar un tiempo de despliegue de información

menor a un (1) segundo.

• Disponibilidad

RNF004: Las pantallas informativas deben estar disponible el noventa y nueve por ciento
(99%) del tiempo de operación, pero en todo caso deberán cumplir los ANS establecidos en el
anexo de Niveles de Servicio.

• Seguridad

RNF005: La pantalla debe incluir un firmware que garantice la protección de la pantalla y que
permita limitar sus funcionalidades de acuerdo con las necesidades del Ente Gestor.

Especificaciones técnicas de los equipos

En relación con la pantalla:

Característica Especificación técnica

Tamaño 24 pulgadas
Cantidad Mínimo 1
Comunicaciones USB/IP/RS485/RS232 o una combinación de estos
Resolución Full HD del orden de 1920×1080
Fuente de alimentación Compatible con la funcionalidad de un Bus
Angulo de visión Mínimo 120°
Protección Mínimo IP54
Temperatura Capacidad de operar con temperaturas entre -5ºC a +50ºC.

En relación con el dispositivo computarizado que maneja la pantalla al menos se debe contar
con las siguientes características técnicas:

62
 Característica Especificación técnica
CPU Mínimo un núcleo de 32bits, unidad sin ventilador
Interfaces de Ethernet (RJ45), USB, RS 485, puerta de audio
comunicación
WiFI 802.11n
USB USB 2.0/3.0
Sistema operativo De código abierto

3.3.7 Conectividad

Como parte del STDI, los buses deberán incorporar un punto de conexión inalámbrico para que
los usuarios del bus puedan acceder a distintos servicios entre ellos, Internet.

Requisitos funcionales

RF001: El STDI debe ser capaz de ofrecer un acceso a la aplicación al menos Web que gestionará
los servicios que sean ofrecidos en los buses gestionado y tal aplicación estará a cargo del Ente
Gestor. Con esto, los múltiples usuarios podrán acceder a diversos servicios entre ellos, y
deberá brindar acceso a internet. Se resalta que el STDI no debe permitir el uso de streeming
de video a menos de que sea del VOD interno del bus, lo anterior se genera para que no haya un
consumo muy excesivo de ancho de banda por parte de los usuarios

RF002: El STDI en conjunto con los recursos hardware/software a que haya lugar deberá
permitir restringir o habilitar conexiones al punto inalámbrico, de manera que sea posible
inhabilitar conexiones de Streeming de video.

RF003: La información que se despliegue en el STDI debe poderse administrar en forma remota,
ya sea mediante una aplicación Web o como se defina con El Ente Gestor. El Ente Gestor podrá
sugerir el diseño Web a nivel de estilos que se considere pertinente por parte de la imagen
institucional del Ente Gestor. Lo anterior quiere decir que cualquiera de los contenidos que se
deseen distribuir hacia los buses deberá poderse generar en un escenario remoto y deberán
tener aprobación del Ente Gestor, el escenario de actualización de los contenidos depende del
concesionario de operación.

RF004: El usuario o viajero deberá interactuar con el Sistema Tecnológico de Difusión de

Información STDI mediante, al menos, una aplicación Web, que funcione en varios navegadores
y con esto, el usuario podrá acceder, mediante un previo registro a la plataforma Sistema
Tecnológico de Difusión de Información STDI a los contenidos y servicios ofrecidos por El Ente
Gestor o quien él determine. El esquema de diseño de presentación de la aplicación Web deberá
ser definido y aprobado por el Ente Gestor. Al mismo tiempo, si la plataforma web ofrece un
esquema de registro de datos del usuario, estos deberán estar en completa disposición para el
Ente Gestor, teniendo de base la ley 1581 de 2012 del gobierno nacional y el concesionario de
provisión en conjunto con el concesionario de operación, deberán garantizar que deben
aparecer los mensajes a que haya lugar en función a la menciona ley y el manejo de habeas data.

63
RF005: El Ente Gestor o quien él determine podrá articularse para la orientación de los
contenidos, servicios e información interactiva que se difundirá a los usuarios del sistema a
través del Sistema Tecnológico de Difusión de Información STDI ya sea usando al menos, la
aplicación Web u otro tipo de acceso.

RF006: El STDI debe contar con esquema de registro para el usuario mediante al menos la
aplicación Web en aras de que pueda disfrutar los servicios ofrecidos por el Sistema
Tecnológico de Difusión de Información STDI, es decir, servicios de Video Bajo Demanda o VOD,
Internet u de otros contenidos asociados, o incluso, lo que El Ente Gestor oriente a difundir por
este sistema.

Requisitos no funcionales

• Rendimiento

RNF001: El punto de conexión inalámbrico debe ser capaz de soportar un mínimo de 30

conexiones simultaneas.

RNF002: Se requiere ofrecer hacia los usuarios una velocidad de transmisión de datos
suficiente para poder que el usuario tenga buena calidad de servicio y con niveles de calidad de
la experiencia; dicho servicio será objeto de evaluación mediante las encuestas de satisfacción
al usuario y el monitoreo de su operación diaria.

3.3.8 Internet en el BUS

Para poder soportar la navegación en Internet al interior del bus se requiere como mínimo
tener un dispositivo que contemple las siguientes características. Se destaca que esta
funcionalidad está destinada a ofrecer parámetros diferenciadores en calidad del servicio de
los buses y hacia la experiencia del usuario.

Especificaciones técnicas mínimas del equipo

Conectividad Redes 4G LTE, 3.7G, 3.5G or 3G con enlace WAN

Celular Antenas externas duales que garanticen la potencia y la conectividad
Capacidad de Manejo de Dual SIM
Wi-Fi Radio Dual 802.11n en 2.4 GHz y 5.0 GHz ya sea con antenas mimo
embebidas dando hasta 300 Mbps por radio o, de hecho, se pueden disponer
antenas externas para alcanzar mayor ganancia de la red wifi

Modos autónomo y Universal

Interfaces WAN WAN inalámbrica con multimodos entre velocidades de redes de 4G LTE,
3.7G, 3.5G and 3G

Modo dual Conexiones concurrentes a dos redes celulares de alta confiabilidad

Activo de
interfaces LTE

64
 Interfaz Serial RS-232 DTE, RS-232/RS-485 DCE, soporte de interfaz de CANBUS (Opcional
para este dispositivo)

Interfaz LAN Puertos de 10/100/1000 Ethernet con PoE/PoE+ (IEEE 802.3at) y a 30 W

Seguridad Seguridad Avanzada que comprenda: Control de acceso, Confidencialidad

en la data y privacidad, detección de hilos e integridad de plataforma

Esquema de Ambiente abierto para inteligencia en el flanco de red y eficiencia

Fog computing operacional

Potencia Entrada integrada de 9-32 VDC

Temperatura Temperatura de rango extendido entre -40ºC to +60ºC

Costo para el Este servicio deberá ser gratuito para el usuario.

usuario

Nota: Para garantizar la calidad del canal de comunicaciones, el Concesionario de Provisión

debe realizar un acuerdo estratégico o un contrato de servicio de telecomunicaciones o el acto
que considere pertinente, a fin de brindar las garantías de servicio, con un proveedor que
suministre un canal de comunicaciones con capacidad suficiente (ancho de banda y de
transferencia) para transmitir y recibir de manera permanente los datos requeridos. En este
sentido, es el Concesionario de Provisión, dependiendo del nivel de flota que maneje el
concesionario de operación, quien debe garantizar a partir de la cantidad de sus equipos
instalados en los buses, que el canal de comunicaciones cumpla y es suficiente con lo que se
requiere desde El Ente Gestor (para su Centro de Gestión) y este, es decir El Ente Gestor o quien
este designe, avalará el canal de comunicaciones a partir de algunas pruebas de calidad y
satisfacción de la transmisión de información. El pago del canal de comunicaciones estará a
cargo del Concesionario de Operación. En el caso que se presenten retrasos en la transmisión
y/o recepción de información, es decir, que exista un problema o inconveniente ya que el ancho
de banda no es suficiente u otro problema, El Concesionario de operación bajo las directrices
del Ente Gestor deberá solicitar mejoras al canal de comunicaciones, las cuales deberán
realizarse en menos de seis (6) horas calendario después de la solicitud del Ente Gestor o quien
este designe, de hecho, el concesionario de operación deberá notificar inmediatamente al ente
gestor cuando todo este operativo y se cumpla con el criterio de transmisión y/o recepción de
información lo cual será validado por el ente gestor, y al mismo tiempo, si el canal continua con
inconvenientes, el concesionario de operación deberá estar informado permanentemente la
situación del canal de comunicaciones como mínimo cada 20 minutos y si se recupera el canal
de transmisión o recepción de información antes de los 20 minutos, se debe notificar su estado
inmediatamente al ente gestor. Si el problema persiste más allá de las 6 horas el concesionario
de operación deberá tomar las medidas necesarias para articularse en términos de operación y
hacer uso de la flota de reserva para solucionar el problema, si fuese el caso de algún daño de
hardware. En otro caso si el problema es de la red general de telecomunicaciones se deberán
presentar los soportes para tal fin y será el ente gestor quien determine que directrices seguir

65
para los términos de operación del sistema. Así mismo, puede ser posible que el Concesionario
de Provisión cuente con una red virtual propia para enfrentar esta funcionalidad, en cuyo caso,
corresponderá al Concesionario de operación, adelantar las gestiones con el concesionario de
provisión para las mejoras a que haya lugar, antes del tiempo indicado.

Si durante el tiempo que dure la indisponibilidad, existiera algún evento de seguridad, el

concesionario de operación deberá utilizar los otros mecanismos de comunicaciones con los
que dispone el bus para notificar al Ente Gestor o a quien este determine, la situación. Durante
el tiempo que dure la indisponibilidad también se harán las mediciones de los ANS de ITS, los
cuales solo serán exonerados aquellos registros de evidencias de seguridad que se puedan
presentar y que el concesionario de operación allegue en un plazo máximo de veinticuatro (24)
horas calendario al Ente Gestor las grabaciones que se pudieron generar durante el suceso
siempre y cuando se haya pulsado el botón de pánico durante ese suceso lo cual estará
registrado en el STS, si esto no ocurre, se aplicaran los descuentos que arrojen las mediciones
del ANS de ITS durante el tiempo que dure la indisponibilidad, sin lugar a objeciones por parte
del Concesionario de Operación, quien responderá ante las autoridades competentes si hay
lugar.

3.3.9 Puertos USB

Los puertos USB permiten la conectividad de equipos móviles u otros al bus en aras de
alimentar las baterías de los equipos tecnológicos de los que disponen los usuarios.

Requisitos funcionales

RF001: Los puertos USB deben estar ubicados en una parte visible para el usuario.

RF002: Los puertos USB deben estar dimensionados de acuerdo con número de sillas por
topología para cada uno de los buses a vincular.

RF003: La ubicación de los puertos USB depende de la tipología de los buses y esta será avalada
por parte del Ente Gestor

RF003: La cantidad de corriente de estos puertos USB debe ser al menos de 500 mA y debe
contarse con un sistema de protección eléctrica independiente para este aditamento en aras de
evitar algún posible corto que haya lugar.

RF004: los puertos USB de forma general deben poderse activar o desactivar desde un switch
central ubicado en la cabina del vehículo, todo esto, en aras de ejecutar algunos procesos
internos o para procesos de mantenimiento y que requieran que estos puertos estén
desactivados, en cuyo caso se deberá notificar mediante avisos al interior del bus de dicha
situación.

Especificaciones Técnicas

Tipo de USB tipo A versión 2.0

Conector
Potencia Corriente mínima de 500 mA

66
 Temperatura Temperatura de rango extendido entre -40ºC to +60ºC

Cantidad de Mínimo 1 por cada silla existente.

Puertos USB

3.3.10 Radio

Requisitos funcionales

RF001: El Concesionario de Provisión deberá tener previsto que El Ente Gestor desplegará el
esquema de centro de emisión radial de radio a lo largo del sistema, en aras de masificar a los
usuarios que se transportan la información sobre novedades, noticias, emergencias o incluso
esquemas publicitarios entre otros. Se resalta que el momento de desplegar este dispositivo se
debe contar en el sistema selector de audio con esta entrada para que sea escuchada al interior
del bus en su sistema de audio.

RF002: El Concesionario de Provisión deberán tener de base este requerimiento en aras de

incorporar a posteriori un esquema de mini receptor que articule la señal que radiará El Ente
Gestor para este fin.

3.3.11 Requisitos de cumplimiento de estándares de software

RNFS001: El STS debe estar basado en lo establecido en la serie de estándares internacionales

ISO 24097:2009, los cuales corresponden al uso de servicios web en sistemas ITS o esquemas
REST debidamente aprobados por El Ente Gestor. En términos de diccionario de datos se toma
de referencia la ISO 14817 ya sea en XML o en esquema REST.

3.3.12 Requisitos de Forma Transversal

En esta sección, se presenta el listado de los requisitos identificados para El STS en los
vehículos, agrupados por temáticas.

• Disponibilidad

RNFS001: La información del STS y del STDI debe tener un esquema apropiado de respaldos de
información para evitar su pérdida, cumpliendo con el punto de recuperación objetivo (RPO
por su acrónimo en inglés).

Nota: Los tiempos de respaldo son dependientes por cada equipo y son dependientes de las
contingencias diseñada por el operador y lo contemplado en los acuerdos entre privados para
ser articulados hacia el ente gestor. Todo esto debe tener articulación con los ANS dispuestos
en este documento y en el Anexo de Niveles de Servicio del presente proceso.

• Continuidad

RNFS001: Los componentes de la infraestructura tecnológica del STS y del STDI en los vehículos
deben cumplir los requisitos de continuidad RPO, RTO, MTD y WRT establecidos para cada uno
de estos en la sección hardware del sistema.

67
RNFS002: Los vehículos deben contar con un canal de comunicaciones con la capacidad
suficiente (de ancho de banda y de transferencia) para transmitir y recibir de manera
permanente los datos requeridos. Será obligación del Concesionario de Provisión realizar los
ajustes en el dimensionamiento adicional de este canal para garantizar que se dé cumplimiento
con los requisitos establecidos para la comunicación con el Centro de Gestión, las veces que sea
necesario durante la ejecución del contrato de operación.

RNFS003: El espacio de almacenamiento de los STS de los vehículos debe tener en cuenta una
capacidad mínima para almacenar los vídeos de vigilancia de todas las cámaras del STS y de los
demás datos y los de información correspondientes, al menos treinta (30) días, mínimo a 720p
o 0.9MP en color, y al menos a 15 FPS (Frames Per Second) con datos de georreferenciación.

RNFS004: El sistema de alimentación eléctrica del STS y del STDI debe incluir un mecanismo
(al interior del bus) de respaldo de energía que permita que el sistema pueda alertar en caso de
quedarse sin la fuente de alimentación principal del vehículo (durante la operación, no se tiene
en cuenta si el vehículo se encuentra apagado) y permita una contingencia de un (1) día.
Durante este periodo de tiempo, El STS, únicamente reportarán señales de alarma, posición
geográfica y botón de pánico al STS.

RNF005:Teniendo como base que la información de naturaleza espacial producida por las
entidades públicas y privadas al interior de la nación debe cumplir con los estándares y niveles
de precisión establecidos por el ente rector de la información espacial o quién haga sus veces y
que en cuyo caso son el Instituto Geográfico Agustín Codazzi (IGAC) y la Infraestructura de
Datos Espaciales para el Distrito Capital (IDECA) siguiendo los lineamientos establecidos y las
resoluciones y normativas emitidas por dichas entidades.

• Requisitos de tiempo de respuesta

RNFS001: La infraestructura tecnológica del STS debe garantizar un tiempo de respuesta

(latencia) para transacciones y escritura menor a cinco (5) segundos (con respecto a la
comunicación con el Centro de Gestión del Ente Gestor.

RNFS002: La infraestructura tecnológica del STS debe garantizar tiempo de respuesta

(latencia) para consultas, que corresponde a un tiempo menor a cinco (5) segundos (con
respecto a la comunicación con el Centro de Gestión del Ente Gestor).

• Requisitos de seguridad para el CCTV del STS

RNFS001: Establecer una política y procedimientos para cambio de las claves de las cámaras
del CCTV de los vehículos (en el caso de las cámaras IPs), de forma rutinaria, establecida y
documentada; evitando el uso de las claves por defecto.

RNFS002: Deshabilitar el sistema de acceso directo a las cámaras a través de la red interna e
interfaz gráfica, permitiendo únicamente el acceso desde el Centro de Gestión a través del túnel
cifrado en dos vías o a quien El Ente Gestor indique para tal fin.

68
RNFS003: Establecer políticas para el diseño y topología de la red, evitando que las cámaras de
los vehículos se encuentren en una red compartida o abierta dentro del vehículo y que
implemente el uso de segmentos privados separados o VLAN por cada vehículo.

• Requisitos de seguridad y control de acceso

RNFS001: Los vehículos deben implementar un firewall o sistema equivalente que cierre todos
los puertos de acceso al STS y que permita el acceso únicamente a través del protocolo HTTPS
o SSH (mediante el empleo de un esquema de autenticación) para descargar los videos de cada
vehículo que se requiera. El firewall o sistema equivalente debe analizar los protocolos y tráfico
que se desea enviar a través de los puertos abiertos y bloquear cualquier intento de acceso a
través de otros puertos, así como el envío de tráfico diferente al autorizado a través del puerto
y protocolo permitidos.

RNFS002: Todas las conexiones desde/hacía El STS debe establecerse a través de HTTPS, SSH
o equivalente, sobre un túnel cifrado TLS.

RNFS003: Los videos del sistema CCTV deben comprimirse y cifrarse en disco y a través del
túnel cifrado TLS durante su transferencia, teniendo en cuenta que la información tratada se
encuentra protegida por normativa de protección de datos personales. Para esto, se debe tener
presente que El STS debe utilizar ciframiento de llave pública (bajo un esquema de autoridad
certificadora (CA) cerrada provisto por el Centro de Gestión) y el algoritmo de cifrado que
utilice certificados digitales de doscientos y cincuenta y seis (256) bits como mínimo (ejemplo
AES) y algoritmos de hash no vulnerables actualmente (ejemplo SHA-2). Se aclara que este
mecanismo debe ofrecer tanto confidencialidad como integridad de la fuente a través del
ciframiento y firma digital del video.

RNFS004: Se debe asegurar que las cámaras del sistema CCTV, el cableado, conectores y los
contenedores de los equipos que corresponden al STS se encuentren debidamente protegidos
de acceso físico no autorizado, corte de energía hacía los mismos, así como de la remoción, robo
y daño de sus componentes.

RNFS005: El usuario operativo que realiza las funciones de descarga de la información

registrada en el dispositivo de almacenamiento del STS, tendrá privilegios restringidos para
solo consulta y descarga.

• Requisitos para operaciones de TI e ITS

RNFS001: Se debe implementar una política de actualización de software (sistemas operativos,

aplicativos y firmwares) que tenga en cuenta el tipo de actualizaciones, las indicaciones del
fabricante o proveedor de los sistemas utilizados, la validación de integridad de origen y de
contenido del software de las actualizaciones, parches o nuevas versiones que se van a utilizar
para ser realizadas como parte de las tareas operativas de mantenimiento programadas. Estas
tareas deben incorporar al menos un esquema de actualización distribuido de actualización de
Firmware si es posible bajo esquemas OTA (Over the Air).

RNFS002: Los sistemas (máquinas) en donde se ejecuta y almacena El STS deben estar
sincronizados bajo la misma referencia de tiempo del Centro de Gestión y deben alinearse con

69
el protocolo NTP para esto. Esto se debe realizar con servidores de tiempo abiertos y confiables
a través del protocolo NTP (Network Time Protocol por su acrónimo en inglés), estableciendo
en el servidor como su zona horaria, la oficial para la República de Colombia.

RNFS003: Los elementos de ITS que hacen parte del esquema de ITS (STS, STDI, Cámaras, entre
otros) al interior del Bus deben poder tener una funcionalidad que permita su monitorización
para generar las alertas y alarmas debidas de su operación (por ejemplo, determinar:
temperatura del procesador, disponibilidad de memoria, uso de CPU, entre otros), por ello, se
requiere que esta monitorización se articule al estándar ISO15784 donde se resalta el uso de
protocolos SNMP, protocolo simple de gestión de red, donde es posible que desde el Centro de
Gestión se despliegue una herramienta de gestión de red que permita gestionar las alarmas
frente a este tipo de alertas. Por su parte, se da como alternativa la articulación de este esquema
de monitorización usando esquemas de ISO 20922 pero se requiere seguir los esquemas de
operación expuestos por el Centro de Gestión. Se resalta que todo dispositivo ITS central (STS,
STDI, Sistema de Conteo, Sistema de Telemetría, es último en caso de que este alterno pero
articulado al STS) debe reportar una trama inicial y final que debe ser marcada de este forma
(trama de inicio o trama de fin) todo esto, al momento de la entrada en operación del bus y al
momento de su salida de operación, asimismo, deberá enviar la fecha y la hora de esta para
temas de indicadores que desea El Ente Gestor y que posteriormente se puedan integrar a los
esquemas de bodega de datos que está articulando la entidad.

Por su parte, es imprescindible destacar que, en el caso de incorporación de buses eléctricos o

a gas o diesel, los esquemas de monitorización de gestión de energía (identificando para ello el
tipo de combustible, o tipo de baterías, caso, carros eléctricos) de los buses deben ser
articulados desde los dispositivos o enfoques tecnológicos que se manejen de parte de los
proponentes o desde el mismo vehículo en comunicación al STS, teniendo de referencia que
todo esto debe estar en consonancia con los diccionarios de datos del Ente Gestor, ya sea que
esta información sea obtenida desde el propio bus o desde los esquemas de infraestructura
energéticos desplegados por el Concesionario de Provisión.

RNFS004: El Concesionario de Provisión deberá contar con al menos un stock de repuestos del
2%, como mínimo asociado este, a cualquiera de los equipos ITS NO SIRCI o de TI desplegados
en los buses, el cual será utilizado si alguno de los equipos falla y su instalación o reemplazo
deberá hacerse antes de salir a operar. El concesionario de operación es el único responsable
por el buen funcionamiento de los equipos ITS NO SIRCI y de su correcto mantenimiento, por
tanto, cada concesionario debe mantener el stock de repuestos que considere necesario para
tal fin; el cuál no podrá ser inferior al 2% y cuya estimación deberá ser presentada con la
Metodología en V y anualmente ajustada y presentada con las programaciones de los
mantenimientos.

• Requisitos de protección de datos personales

RNFS001: En cumplimiento del régimen de protección de datos personales (Ley 1581 de 2012,
decretos reglamentarios y la Resolución 393 de 2013 de la Alcaldía de Bogotá por medio de la
cual se adoptan políticas y procedimientos en materia de protección de datos personales para
El Ente Gestor, se debe establecer y aplicar una política de tratamiento de las imágenes de las

70
personas (usuarios del servicio, conductor, y demás terceros) previamente aprobada por el
Centro de Gestión del Ente Gestor que incluya las finalidades del tratamiento, los derechos,
canales de atención y demás requisitos de Ley, la cual debe estar disponible y accesible para los
usuarios dentro de los vehículos y desde la página web informativa del sistema de transporte.

RNFS002: Realizar el tratamiento de los datos personales evitando ponerlos en riesgo de

divulgación y acceso no autorizado, uso para fines no previstos en la política de tratamiento
establecida y no autorizados, dando cumplimiento a la Ley 1581 de 2012, decretos
reglamentarios y a la Resolución 393 de 2013 de la Alcaldía de Bogotá por medio de la cual se
adoptan políticas y procedimientos en materia de protección de datos personales para El Ente
Gestor. En cualquier caso, la responsabilidad frente a terceros es exclusiva del Concesionario
de Operación.

RNFS003: Se debe cifrar la información crítica del sistema (videos del sistema de vigilancia) en
los ambientes de producción, ambientes de respaldo y/o de replicación de dicha información y
a su archivo histórico.

• Requisitos relacionados con la actividad del STS y la comunicación con el Centro de Gestión

RNFS001: Entre el Centro de Gestión y El STS u otros equipos que apoyen la gestión del vehículo
no se establecerá ninguna sesión permanente, cada transacción será atómica y se realizará a
través del túnel cifrado en dos vías establecido por el certificado digital del Centro de Gestión y
El STS del vehículo.

RNFS002: Se utilizará un protocolo de port knocking iniciado por el sistema STS del vehículo,
el cual habilitará el puerto determinado para establecer el túnel TLS en dos vías, para que El
STS del vehículo pueda consumir servicios web del Centro de Gestión.

RNFS003: Para que el Centro de Gestión pueda conectarse con el vehículo para enviarle los
valores de configuración para las alarmas a través de servicios Web, el Centro de Gestión
utilizará el túnel de dos vías establecido por el vehículo para remitirle la nueva configuración.

RNFS004: El STS debe tener trazabilidad y auditoría interna mediante el registro de logs de
todas las actividades realizadas en el sistema, el cual podrá ser requerido por El Ente Gestor en
el momento en que este lo determine, y, por tanto, brindado de manera inmediata por parte del
Concesionario de Operación.

RNFS005: El STS podrá realizar sobre escritura de los videos de vigilancia luego de que se
cumplan los treinta (30) días para salvaguardar la información de manera local en cada
vehículo, y siempre que no se haya recibido ningún requisito de descarga por parte del Centro
de Gestión asignado por parte de El Ente Gestor y no se haya cumplido por parte del
Concesionario de Operación. El Concesionario de Provisión debe adelantar las acciones que
permitan garantizar que el Centro de Gestión del Ente Gestor los videos marcados.

Otros aditamentos:

• Requisitos relacionados con la actividad del STDI y demás sistemas

71
RNFS001: El STDI debe contar con un sistema independiente de alimentación y debe incorporar
todas las protecciones eléctricas a que haya lugar. El STDI debe contar con un sistema de
respaldo en caso de falla.

Nota: Para todos los dispositivos aquí descritos debe garantizarse tanto del Concesionario de
Provisión y del Concesionario de Operación el funcionamiento de todos los dispositivos de
acuerdo con todos los requisitos funcionales y no funcionales aquí descritos, considerando,
incluso, los parámetros energéticos que cada uno de estos dispositivos devengue al interior del
bus, garantizando las adecuaciones eléctricas excepcionales si así lo ameritan de acuerdo a la
cantidad de dispositivos y será transparente para El Ente Gestor el escenario energético de
estos dispositivos, así mismo debe quedar remanente para tener la posibilidad de conectar algo
más a futuro. Por otra parte, los esquemas de cableado de cada uno de estos subsistemas de
ITS deberán tener al interior del bus una designación especial que deberá ser presentada al
Ente Gestor durante su ensamblaje para su previa aprobación sin generar responsabilidad
alguna al Ente Gestor, todo esto, en aras de facilitar los procesos de mantenimiento y/o
renovación de los equipos
Desde el punto de vista de despliegue de equipos, el Concesionario de Provisión con aras de
presentar y evidenciar lo que está instalando en la flota, deberá generar y presentar al Ente
Gestor un escenario funcional de operación de los equipos de ITS o lo que haga sus veces, por
fuera del bus, con todos los elementos y servicios que serán instalados al interior del bus y con
sus cableados y alimentación respectiva, todo esto, en aras de esquematizar el escenario
funcional y de pruebas que se tendrán al momento de instalar todos estos equipos. Los equipos
utilizados en el escenario funcional podrán ser utilizados en algún bus, pero a posteriori de
mostrar toda su interoperabilidad con el Centro de Gestión que determine el Ente Gestor.
Adicionalmente, este apartado deberá ser contemplado en las actividades del plan maestro de
implementación descrito en la sección 4-Ingeniería de detalle, ya sea para el STS, STDI, Sistema
de conteo de pasajeros, telemetría y demás aditamentos a los que haya lugar y que
corresponden al anexo de ITS.

Se aclara que si el concesionario respectivo, de acuerdo a los lineamientos definidos por El Ente
Gestor, puede ofertar sistemas adicionales que representan nuevos servicios de valor agregado
ya sean para peatones, el Ente Gestor, los usuarios de la flota, u otros usuarios y que pueden
tomar de base la información del STS, STDI u otro información combinada de otros sensores o
sistemas que posee o no el bus, esta oferta de servicios deberá articularse a los esquemas de
modelo de negocio que defina El Ente Gestor si así este lo dispusiese.

Nota: Se resalta que los equipos pertenecientes al STS y al STDI deben ser independientes, toda
vez que sus requisitos funcionales y no funcionales son diferentes y están enfocados a apoyar
servicios distintos, por ello, el funcionamiento de cada uno debe correr en hardware/software
aparte y con independencia, sin embargo, estos pueden ser integrables en los casos a que haya
lugar.

El Ente Gestor será quien informe “cuando” se realizará la integración con el centro de gestión
que defina TSMA para esta flota, así como otras condiciones técnicas adicionales de pruebas e
intercambio de información de los equipos ITS a bordo del bus.

72
73
4 INGENIERÍA DE DETALLE

En esta sección se presenta la documentación que deberá entregar el ganador de la licitación a

El Ente Gestor, de acuerdo con lo dispuesto por la metodología de “Modelo en V” y de acuerdo
con requisitos específicos que se mencionan en este anexo técnico.

4.1 Cronograma de implementación

El Concesionario de Provisión deberá entregar el cronograma de implementación del sistema

indicando los tiempos de análisis, fabricación, suministros, entrega, instalación, configuración,
pruebas y puesta en servicio de cada elemento del sistema. En caso de ser varios actores se
deberá presentar los planes de articulación con ellos para que El Ente Gestor los apruebe.

4.2 Plan maestro de implementación

El Concesionario de Provisión deberá entregar el plan maestro de implementación y debe ser

aprobado por El Ente Gestor. Este plan debe contener:

• Descripción detallada de las actividades a realizar y mecanismos de seguimiento

• Cronograma detallado: fechas de instalación y pruebas de cada uno de los componentes
del STS y del STDI
• Deben contemplarse actividades asociadas a la interoperabilidad de los equipos ITS o
los que hagan sus veces instalados en el bus, en función a la conectividad e intercambio
de datos con el centro de gestión que defina en Ente Gestor
• Asignación de recursos Humanos: dedicación por etapas del equipo de trabajo.

Nota: Este plan debe entregarse con todas sus fechas estipuladas de cada una de las actividades
en los primeros veinte (20) días a partir de la firma del acta de inicio, todo esto deberá estar
articulado con lo expuesto en la introducción de este anexo.

4.3 Protocolo de articulación vigente con otros actores

Los Concesionarios de Provisión y Concesionarios de Operación deberán acoger el protocolo de

articulación vigente con el Concesionario del SIRCI e igualmente sin lugar a objeciones, los
demás protocolos o modificaciones que existan con los futuros concesionarios del SIRCI.

Con relación a los demás posibles actores estratégicos de tecnología deberán firmar los
documentos de acuerdo con terceros, y debe contener la descripción de los actores con los que
interactúa y la descripción de las actividades a realizar y mecanismos de seguimiento entre los
diferentes actores involucrados. Así mismo, se requiere tener en cuenta las obligaciones
contractuales dispuestas para este fin y las que generen el escenario de trabajo mancomunado
entre las partes interesadas en torno al equipamiento de ITS NO SIRCI y SIRCI.

4.4 Garantía

El Concesionario de Provisión deberá entregar dentro de los veinte (20) días hábiles siguientes
a la firma del acta de inicio la documentación asociada a las condiciones, alcance y forma de
solicitud acerca de la garantía de cada uno de los Equipos aquí descritos (e.g. términos,

74
duración, entre otros.) que ofrece al Ente Gestor, así como la que se requiera de los demás
equipos a instalar.

4.5 Documentación Técnica

El Concesionario de Provisión deberá entregar dentro de los veinte (20) días hábiles siguientes
a la firma del acta de inicio la documentación técnica requerida de acuerdo con la metodología
de “Modelo en V” para la planeación, diseño e implementación de proyectos de Sistemas
Inteligentes de Transporte (ITS). Las fases y productos de la metodología se presentan a
continuación:

4.5.1 Diseño de alto nivel

El diseño de alto nivel define la arquitectura –a nivel de proyecto– del sistema. Esta arquitectura
define los subsistemas a construir, las interfaces internas y externas a desarrollar, así como los
estándares de interfaz identificados. El diseño de alto nivel es donde se desarrollan los
requisitos de los subsistemas y los principales productos candidatos, que podrían ser utilizados
en el sistema. El diseño de alto nivel es el paso de transición entre lo que el sistema hace
(requisitos de los subsistemas), y el cómo (arquitectura e interfaces) el sistema será
implementado para cumplir con los requisitos.

4.5.1.1 Actividades principales

A continuación, se presentan las dos (2) actividades de descomposición principales para esta
etapa:

• La descomposición funcional: descompone cada función en sus partes más pequeñas.

• La descomposición física: define los elementos físicos necesarios para llevar a cabo la
función.

Como resultado de la ejecución de estas actividades, se requieren como mínimo los siguientes
productos:

• Arquitectura del sistema

• Vista física
• Vista funcional
• Vista técnica
• Vista de información

4.5.2 Diseño detallado

Consiste en el diseño del hardware, software y la selección de productos comerciales y/o

funcionalidades que se serán adquiridos y utilizados. Este es el paso donde se prepara la
documentación necesaria para el desarrollo (codificación) de software. Para el hardware, es el
paso donde los esquemas lógicos y otros diagramas se preparan para la posterior fabricación.
Si se van a utilizar equipos y software OTS (del inglés, off-the-shelf, OTS), es decir, productos
comerciales, en este paso se evalúan y se realiza la selección los productos candidatos.

75
4.5.2.1 Actividades principales

A continuación, se presentan las actividades principales a ejecutar durante esta etapa:

• Generar prototipo de interfaces de usuario

• Generar especificaciones detalladas de los componentes de Hardware y Software
• Selección de productos OTS
• Desarrollar planes de pruebas

Como resultado de la ejecución de estas actividades, se requieren como mínimo los siguientes
productos:

• Diseño de clases
• Diseño de bases de datos o repositorios de información (incluyendo su diseño lógico
inicial y al terminar el diseño final como quedo luego de la articulación con todos los
elementos)

4.5.3 Implementación de Software y Hardware

En este paso del proceso se implementa el software y hardware para el sistema que se ajusta a
la especificación de requisitos y a la documentación de diseño detallado de componentes. Es
esencial revisar el progreso técnico y proporcionar orientación técnica sobre la aplicación de
los requisitos. Estas revisiones proporcionan una alerta temprana en caso de que los requisitos
sean deficientes, o que no se estén cumpliendo en la implementación. De forma concurrente
con esta tarea, se desarrollan procedimientos para realizar pruebas unitarias que serán
utilizadas para verificar que los productos cumplen con el diseño detallado.

4.5.3.1 Actividades principales

A continuación, se presentan las actividades principales a ejecutar durante esta etapa:

• Establecer ambientes de desarrollo

• Implementación del software y hardware
• Realizar pruebas unitarias

Como resultado de la ejecución de estas actividades, se requieren como mínimo los siguientes
productos:

• Software del sistema

• Hardware del sistema
• Pruebas unitarias

4.5.4. Integración y verificación

La integración es el proceso de combinar con éxito los componentes de hardware y software,

subsistemas y sistemas en un todo, completo y funcional. La integración es un proceso iterativo
que implica: Disponer de los componentes de hardware y software; Utilizarlos para conformar

76
elementos completos de subsistemas; Combinar estos elementos en subsistemas combinados
más grandes; Combinar todos los subsistemas en un sistema final.

El proceso de verificación es utilizado por el propietario del sistema y otras partes interesadas
para comprobar que el sistema, subsistemas, y componentes cumplen con todos los requisitos
y con el diseño.

4.5.4.1 Actividades principales

A continuación, se presentan las actividades principales a ejecutar durante esta etapa:

• Desarrollo de planes de integración y verificación

• Ejecución de los planes de integración y verificación

Como resultado de la ejecución de estas actividades, se requieren como mínimo los siguientes
productos:

• Planes de integración y verificación

• Resultados de los planes de integración y verificación

4.5.5 Despliegue inicial del sistema

El proceso de despliegue de los sistemas o subsistemas – probados – es el proceso que los

instala en el entorno previsto para su operación.

La instalación es el paso final de diseño y construcción en el desarrollo de un sistema. La

estrategia de instalación definida debe reflejar el plan para el proyecto. Debe proporcionar un
componente operativo útil del sistema en cada paso del proceso y en cada lugar de despliegue.
La estrategia de instalación puede suponer una única instalación en un solo sitio. O bien puede
tener que abordar múltiples despliegues parciales en varios sitios, durante un período
prolongado de tiempo.

4.5.5.1 Actividades principales

A continuación, se presentan las actividades principales a ejecutar durante esta etapa:

• Desarrollo de planes de instalación y transición

• Implantación del sistema

Como resultado de la ejecución de estas actividades, se requieren como mínimo los siguientes
productos:

• Inventario de hardware y software

• Planes de instalación y transición
• Sistema implementado

77
4.5.6 Validación

La validación es una evaluación del sistema en modo operativo. El proceso de validación

asegura que el sistema cumple con el propósito y las necesidades previstas del propietario del
sistema y de las partes interesadas. En otras palabras, la validación da respuesta a la pregunta
¿se ha construido el sistema apropiado?

El principal producto para esta etapa es “Resultados del plan de validación”.

4.5.7 Operación y Mantenimiento / Cambios y Actualizaciones

En esta fase se evalúa el sistema con respecto a las necesidades identificadas, se pone en
operación, se lleva a cabo el mantenimiento, se implementan los cambios necesarios y se
aplican las actualizaciones disponibles.

Los principales productos para esta etapa son:

• Reportes de rendimiento del sistema

• Logs del sistema
• Registros de los mantenimientos
• Plan de actualización tecnológica

78
5 ESQUEMA DE GESTIÓN ITS CON EL STS

5.1 Sistema tecnológico de seguridad

Las funciones específicas del STS se han presentado en secciones anteriores.

5.1.1 Instalación

El STS debe estar instalado en cada uno de los vehículos que sean puestos a disposición del Ente
Gestor por el Concesionario de Provisión. Cada uno de sus componentes debe ser instalado en
el interior del bus sin la posibilidad de ser manipulado o removido. Para ello, deben cumplir
con normas físicas a prueba de vandalismo. Es importante aclarar que esto también aplica para
el para el STDI y sus diversos componentes.

Además, se deben tener en cuenta los siguientes aspectos:

La provisión e instalación de los sensores del motor, del CANBUS y de la cabina deben ser
suministrados por fabricantes que tengan representación legal en Colombia y brinden soporte
técnico y mantenimiento ante cualquier eventualidad veinticuatro (24) horas al día. En el caso
en el que los fabricantes no tengan representación legal en Colombia, se exige que el agente
integrador (proveedor de servicio de integración tecnológica que proveerá los servicios al
Concesionario de provisión y posteriormente al Concesionario de operación para temas de
mantenimiento) cuente con representación en Colombia y certifique que cuenta con soporte
técnico veinticuatro (24) horas al día, trescientos sesenta y cinco (365) días al año, con
capacidad de suministro de sus partes en menos de veinticuatro (24) horas; certificado que
deberá ser entregado con la documentación requerida para la vinculación de cada vehículo.

La cámara del conductor y las cámaras del CCTV deben ser suministradas por fabricantes que
tengan representación legal en Colombia y brinden soporte técnico y mantenimiento ante
cualquier eventualidad veinticuatro (24) horas al día. En el caso en el que los fabricantes no
tengan representación legal en Colombia, se exige que el agente integrador (proveedor de
servicio de integración tecnológica que proveerá los servicios al Concesionario de provision y
posteriormente al Concesionario de operación para temas de mantenimiento) cuente con
representación en Colombia y certifique que cuenta con soporte técnico veinticuatro (24) horas
al día, trescientos sesenta y cinco (365) días al año, con capacidad de suministro de sus partes
en menos de veinticuatro (24) horas;, certificado que deberá ser entregado con la
documentación requerida para la vinculación de cada vehículo.

La instalación del botón de pánico debe ser en un lugar discreto al alcance solamente del
conductor, en todo caso, será El Ente Gestor quien apruebe su ubicación final.

5.2 Interoperabilidad

Entre las funciones principales del STS se encuentra el intercambio de información de forma
permanente con el Centro de Gestión asignado por El Ente Gestor. Para ello, debe utilizar las
interfaces dispuestas por este centro para recibir la información de configuración y
parametrización de alarmas y de rangos de valores permitidos para los sensores (en las
unidades que El Ente Gestor designe), y para realizar el envío de la información proveniente de

79
la cámara del conductor, de los sensores de la cabina, de los sensores del motor y del CANBUS,
de las cámaras del CCTV y de los demás elementos que lo conforman.

De igual manera, debe contar con una interfaz Web accesible vía WiFI 802.11n, WiFI 802.11ac
o superior o contar con esquemas de redes orientadas en el retraso (este último si es el caso)
para la descarga de los videos e imágenes almacenados por la cámara del conductor y por las
cámaras del CCTV y la descarga de los datos generados por los sensores del STS. El
Concesionario de Provisión, debe contar en los patios o lugares de estacionamiento de buses
con una red WiFI 802.11n, WiFI 802.11ac o superior para realizar la descarga de dichos videos
e imágenes, así como de los datos generados por los sensores del STS. Si el Concesionario de
Provisión considera pertinente, puede contar con una alternativa de red cableada para realizar
la descarga de la información, teniendo en cuenta que debe desplegar infraestructura suficiente
para descargar la información de todos los buses incluyendo los de reserva, objeto de su
contrato que entrega para la operación.

El STS Debe garantizar que todos los sensores, cámaras y demás dispositivos que lo conforman
se encuentren en perfectas condiciones de operación y con la implementación de restricciones
de control de acceso y modificación de la información por parte de personal no autorizado. Esto
aplica para todos y cada uno de los dispositivos embarcados en el(los) bus(es).

5.3 Operación

El Sistema Tecnológico de Seguridad (STS) debe garantizar que todos los sensores, cámaras y
demás dispositivos que lo conforman se encuentren en perfectas condiciones de operación y
con la implementación de restricciones de control de acceso y modificación de la información
por parte de personal no autorizado. Esto aplica para todos y cada uno de los dispositivos
embarcados en el(los) bus(es)

El Sistema Tecnológico de Seguridad (STS) debe operar de forma autónoma mientras el

vehículo se encuentre encendido y cinco (5) minutos más una vez ha sido apagado.

El Sistema Tecnológico de Seguridad (STS) debe asegurar que el usuario operativo que descarga
la información registrada en el dispositivo de almacenamiento tenga privilegios restringidos
para solo consulta y descarga, de este modo, no pueda alterar su contenido

5.4 Soporte y mantenimiento

El proveedor de cada componente del STS y del STDI debe asegurar el soporte técnico 7x24
x365.

El Concesionario de Operación debe ser el responsable de gestionar el mantenimiento

preventivo y correctivo del STS con el proveedor de los componentes del STS.

El Concesionario de Operación debe ser el responsable de gestionar el mantenimiento

preventivo y correctivo del STDI y todos sus componentes, cumpliendo los ANS establecidos en
este documento y en el Anexo de niveles de servicio

80
Cada Concesionario de Operación debe disponer de una herramienta de mesa de ayuda para el
registro de incidentes que detecte El Ente Gestor en alguno de ellos, y para lo cual deberá
cumplir con los ANS establecidos en este documento y en el Anexo de niveles de servicio.

Para los incidentes en los dispositivos SIRCI, el Concesionario de Operación deberá utilizar la
herramienta(s) de mesa de ayuda dispuesta(s) por el(los) concesionario(s) del SIRCI y acatar
las instrucciones dadas en el protocolo de articulación vigente y demás anexos que los soporten.

Para los incidentes con otro equipamiento ITS NO SIRCI, se deben considerar las obligaciones
del presente proceso y se requiere que haya un trabajo mancomunado de las diferentes partes
o actores involucrados.

6 SEGURIDAD

6.1 Seguridad de la información

A continuación, se presentan los controles de seguridad que se deben implementar por parte
de los Concesionarios de Provisión y Concesionario de Operación, y que se encuentran
alineados con algunos objetivos de control de la norma técnica estándar ISO/IEC 27002:2013.

6.1.1 Autenticación

CSIG001: Asegurar que todas las conexiones internas y externas (para usuarios y Centro de
Gestión) se realicen a través de una forma adecuada de autenticación y asegurar que este
control no se pueda evadir.

CSIG002: Validar la identidad de los usuarios a través de los mecanismos de autenticación de

identidad provistos por el sistema.

CSIG003: Establecer el túnel cifrado en dos vías entre el Centro de Gestión y El STS utilizando
certificados digitales de una entidad certificadora (CA) cerrada administrada por el Centro de
Gestión.

CSIG004: Establecer el túnel cifrado en dos vías entre el STDI y el Centro de Gestión o el sistema
a que haya lugar que controle este dispositivo. Así mismo, debe ser posible que este sistema
pueda utilizar certificados digitales de una entidad certificadora (CA) para el despliegue de
información.

6.1.2 Autorización para El STS y el STDI

CSIG004: Autorización limitada a los roles y configuración en el sistema.

CSIG005: Asegurar que en el sistema se hayan definido claramente los tipos de usuarios (roles)
y los privilegios (políticas de acceso).

CSIG006: Asegurar que se apliquen los principios de diseño del mínimo privilegio en la
operación del sistema.

CSIG007: Asegurar que los mecanismos de autorización trabajen correctamente, fallan de

forma segura y no puedan ser evadidos.

81
CSIG008: Asegurar que la autorización sea validada en cada petición y/o transacción.

Nota: Para el STDI se requiere asegurar los tipos de roles que tiene el sistema para poder
desarrollar su funcionalidad en un ambiente seguro para el despliegue de mensajes ya sean
publicitarios o los que estime convenientes El Ente Gestor. Este sistema debe tener control de
logs y demás para garantizar su funcionamiento adecuado.

6.1.3 Validación de ingreso de datos

CSIG09: Asegurar que exista un mecanismo de validación de datos que inicialmente valide la
forma o sintaxis de los datos y que luego realice verificaciones sintácticas de acuerdo con
dominio del dato, correlaciones o similares a las que haya lugar.

CSIG010: Asegurar que todos los datos estén bien formados y contengan sólo los caracteres
permitidos (mientras sea posible) y exigidos por El Ente Gestor.

CSIG011: Asegurar que haya consistencia en las validaciones realizadas.

CSIG012: Todos los datos enviados, sin importar qué tipos de datos sean o a qué correspondan,
siempre deben ser examinados y validados.

6.1.4 Manejo de error / fuga de información del STS

CSIG013: Asegurar que todas las excepciones y las condiciones de error sean manejadas
apropiadamente.

CSIG014: Asegurar que los recursos sean liberados si ocurre algún error y el sistema regrese a
un estado seguro.

6.1.5 Registro de logs y auditoría del STS

CSIG015: Asegurar que no se registre información crítica o protegida en los logs en el evento de
algún error.

CSIG016: Asegurar que no se registre información crítica o protegida en los logs como las
cookies, un método GET de HTTP, credenciales de autenticación de usuario, entre otros.

CSIG017: Asegurar que los errores del sistema y accesos fallidos sean registrados.

CSIG018: Asegurar que el sistema no tenga habilitada la opción de debug, la cual no sólo registra
los logs de debug, sino que también puede permitir ver dicha información en la interfaz de
usuario en impresión por pantalla.

CSIG019: Asegurar que el sistema implemente el principio de separación de funciones, para que
permita hacer seguimiento a los accesos no autorizados a la información o al abuso de los
privilegios administrativos en el sistema.

6.1.6 Criptografía

CSIG020: Asegurar que no se transmita información crítica o que deba ser protegida, de forma
clara o en texto plano, ni interna ni externamente del Centro de Gestión ni del STS y que la

82
opción SecureFlag se encuentre fijada para evitar transmisiones accidentales de forma no
segura. En las conexiones o transmisiones SSL/TLS implementar y permitir únicamente TLS
(Transport Layer Security).

CSIG021: Asegurar que el sistema implemente algoritmos o métodos criptográficamente

seguros de fuente abierta y ampliamente aceptados, no algoritmos criptográficos propios.

CSIG022: Se deben tener varias llaves criptográficas separando la función o uso de cada una de
ellas.

6.1.7 Ambiente seguro de codificación y despliegue

CSIG023: Verificar la estructura de los archivos de código y asegurar que no haya componentes
que puedan ser directamente accedidos que estén disponibles allí para el usuario.

CSIG024: Verificar los mecanismos para las asignaciones de memoria y asegurar que se realice
la liberación de esta.

CSIG025: Asegurar que todas las decisiones lógicas tengan una cláusula o caso por defecto.

CSIG026: Asegurar que no haya ningún kit de ambiente de desarrollo en los directorios ya
desplegados para producción.

CSIG027: Asegurar que las llamadas al sistema operativo o llamadas a archivos tengan
contemplado el manejo de los posibles errores que puedan presentarse.

6.1.8 Validación y verificación

CSIG028: Asegurar que el sistema implemente el principio de separación de funciones con

controles de auditoría, que permitan hacer seguimiento a los accesos no autorizados a la
información o al abuso de los privilegios administrativos en el sistema.

6.1.9 Protocolos de comunicaciones para El STS

CSIG029: Asegurar que El STS no tenga habilitados más puertos físicos ni dispositivos o
protocolos de comunicaciones que aquellos que han sido identificados y dispuestos para
conectarse al Centro de Gestión y a la red del lugar de estacionamiento teniendo de referencia
el anexo de patios (con o sin redundancia en conexión) y para conectar los sensores y CANBUS
del vehículo.

CSIG030: Asegurar que El STS pueda conectarse únicamente a redes WiFi preestablecidas y que
hayan sido agregadas y autorizadas mediante usuarios con privilegios de administrador.

CSIG031: Asegurar que los vehículos cuenten con un canal de comunicaciones con la capacidad
suficiente (de ancho de banda y de transferencia) para transmitir y recibir de manera
permanente los datos requeridos.

6.1.10 Manejo de sesión

CSIG032: Asegurar que el identificador de sesión sea lo suficientemente complejo para cumplir
con los requisitos sobre su solidez.

83
CSIG033: Asegurar que el almacenamiento de los datos del STS cumpla con los parámetros de
seguridad para mantener, caducar las sesiones y para almacenar el identificador de estas. El
tiempo de inactividad debe ser parametrizable y será definido por el Centro de Gestión del Ente
Gestor”.

CSIG034: Asegurar que el sistema haga seguimiento adecuado a las sesiones y que maneje su
estado correctamente.

CSIG035: Validar qué acciones toma la aplicación si se utiliza un identificador de sesión inválido
y asegurar que en ninguna circunstancia se permita el acceso al sistema de esta forma no
autorizada.

CSIG036: Asegurar que se cumpla el procedimiento para invalidar y/o terminar una sesión de
forma adecuada.

CSIG037: Asegurar que no se puedan tener múltiples sesiones abiertas para el mismo usuario
simultáneamente y que la apertura de una nueva sesión genere el cierre de la anterior.

CSIG038: Asegurar que si se cumple el tiempo de inactividad (timeout) se cierre la sesión.

84
7 VALIDACIÓN DEL SISTEMA

Para la validación de los ITS a bordo, el Concesionario de Provisión presentará al Ente Gestor o
a quien este designe, dentro de los veinte (20) días calendarios, contados después del acta de
inicio, la siguiente matriz con la última columna diligenciada y sus respectivos soportes que la
acrediten.La mencionada información deberá igualmente ser enviada al Ente Gestor cada vez
que el Concesionario de Provisión decida realizar un cambio de la tecnología informada
anteriormente.

Categoría Aspecto a tener Elemento que cumple con ¿Cumple?

en cuenta el aspecto identificado
Calidad del Reporte de datos ¿El STS cuenta con Sí / No
servicio de conducción en elementos tecnológicos para
tiempo de capturar los datos de
operación12 conducción del vehículo en
tiempo de operación?
Calidad del Reporte de datos ¿El STS captura con Sí / No
servicio de conducción en precisión los datos de
tiempo de conducción del vehículo en
operación tiempo de operación?
Calidad del Reporte de datos ¿El STS almacena los datos Sí / No
servicio de conducción en de conducción del vehículo,
tiempo de capturados en tiempo de
operación operación?
Calidad del Reporte de datos ¿El STS reporta de forma Sí / No
servicio de conducción en oportuna, al Centro de
tiempo de Gestión asignado, los datos
operación de conducción del vehículo,
capturados en tiempo de
operación?
Calidad del Automatización de ¿El STS realiza la activación Sí / No
servicio mecanismos de de los mecanismos de
control a bordo control de temperatura,
iluminación, y parabrisas de
forma automática?
Calidad de Servicio Despliegue de ¿El STDI cuenta con los Sí / No
Información en las elementos tecnológicos para
pantallas a bordo ofrecer los servicios de
divulgación de información
como se definieron en los
requisitos anteriormente
expuestos?

12 Los datos de conducción que deben ser capturados y enviados al centro de gestión son de acuerdo con las condiciones anteriormente expuestas y se deben considerar
para los diversos tipos de tecnologías que utilice el motor ya sea combustión, interna o hibrida o vehículos eléctricos.

85
 Categoría Aspecto a tener Elemento que cumple con ¿Cumple?
en cuenta el aspecto identificado
Calidad de Servicio Acceso a la red del ¿El bus cuenta con una Sí / No
Bus aplicación para poder
acceder a Internet en el bus o
para ver los contenidos
pregrados en el VOD13 del
bus?
Calidad de Servicio Acceso a Internet y ¿El bus cuenta con acceso a Sí / No
consumo de Internet para la cantidad
contenidos en el mínima de usuarios descrita
bus y posee los esquemas de no
permitir streeming de
video?
Calidad de Servicio Acceso a los ¿El bus cuenta con el sistema Sí / No
contenidos de de video bajo demanda para
entretenimiento que los usuarios puedan ver
del Bus series, películas o juegos al
interior del bus?
Calidad de Servicio Acceso a los ¿El bus cuenta con puertos Sí / No
puertos USB USB accesibles y con el rango
de corriente correcto para
los dispositivos móviles de
los usuarios?
Interoperabilidad Integración entre ¿Se genera y funciona el Sí/No
ruteros, STS y STDI esquema de integración
entre los ruteros y los demás
dispositivos (en términos de
lectura de datos_)?
Interoperabilidad Integración entre ¿Se genera y funciona el Sí/No
PIP, STS y STDI esquema de integración
entre el PIP y los demás
dispositivos (en términos de
lectura de datos_)?
Seguridad física Reconocimiento de ¿El STS realiza el proceso de Sí / No
conductores capturar la imagen del
conductor de forma
automática?
Seguridad física Reconocimiento de ¿El STS se comunica en Sí / No
conductores tiempo de operación con el
Centro de Gestión para

13 Video bajo demanda

86
Categoría Aspecto a tener Elemento que cumple con ¿Cumple?
en cuenta el aspecto identificado
enviar la imagen del
conductor y notificar la
presencia o no del
conductor?
Seguridad física Implementación ¿El vehículo tiene Sí / No
de un CCTV en los implementado un CCTV?
vehículos
Seguridad física Sensores para la ¿El STS cuenta sensores para Sí / No
seguridad de los facilitar la labor de conducir
pasajeros y y minimizar accidentes?
personas en vía
Seguridad física Generación de ¿El STS genera alarmas al Sí / No
alarmas con base Centro de Gestión de forma
en los datos automática a partir de los
generados por los datos capturados del modo
dispositivos de de conducción?
seguridad a bordo
Seguridad de la Política para ¿Se cuentan con los Sí / No
información tratamiento de lineamientos que se deben
datos de usuarios incorporar y/o tener en
cuenta para elaborar una
política de seguridad y de
tratamiento de datos
personales?
Seguridad de la Disponibilidad y ¿Se cuenta con los niveles de Sí / No
información continuidad del servicio y tiempos de
negocio recuperación requeridos
para que el concesionario
implemente su plan de
continuidad del negocio?
Seguridad de la Evitar la ¿Se cuenta con Sí / No
información suplantación funcionalidades para el
sistema de información, que
permitan validar si la
implementación de este
control de autenticación está
evitando la suplantación?
Seguridad de la Carácter ¿Se cuenta con los requisitos Sí / No
información probatorio y establecidos por la Ley 527
validez legal de 1999 para que para los
videos y demás información

87
 Categoría Aspecto a tener Elemento que cumple con ¿Cumple?
en cuenta el aspecto identificado
puedan tener carácter
probatorio y validez
jurídica?
Seguridad de la Canales y ¿Se cuenta con los requisitos Sí / No
información mecanismos no funcionales y de
seguros seguridad para la
información que es
almacenada, transmitida,
canales de comunicaciones,
equipos y medios?
Seguridad de la Controles físicos de ¿Se cuenta con los requisitos Sí / No
información acceso a los de hardware que impidan el
equipos acceso no autorizado a la
información, controles
antivandálicos y
mecanismos para detectar
que la unidad lógica se ha
abierto, se ha desconectado,
entre otros?
Seguridad de la Operación segura y ¿Se cuenta con los Sí / No
información correcta lineamientos para los
manuales de operación y
mantenimiento sobre la
operación segura y correcta,
evitando así incidentes de
seguridad, pérdida de datos,
de integridad, entre otros?

Nota: En el caso referente a vinculación de flota se requerirá cumplir con un mínimo de pruebas
iniciales ya sea de existencia y funcionamiento de los equipos que hacen parte de este anexo,
generación de pruebas locales frente a los datos que generan los sensores y demás
equipamiento. En cuanto a la validación frente al centro de gestión, el Ente Gestor determinará
cuando debe realizarse esta validación y su integración, teniendo en cuenta que debe definirse
la trama de intercambio para el envío de datos siguiendo esto, diccionarios de datos
homogéneos.

Nota: En el contexto de estabilización de todos los ITS NO SIRCI contenidos en este documento
para su validación y verificación, se requiere que todos los equipos funcionen de forma óptima
de acuerdo con los requisitos contemplados en este anexo, es decir, acerca del STS (incluyendo
la parte de telemetría) y del STDI. Por lo anterior, se requiere destacar que los actores
estratégicos (concesionario de Operación, concesionario de provisión y TMSA) en concordancia

88
con las funcionalidades de cada uno de los componentes ITS NO SIRCI y sabiendo que esto
requiere pruebas para su estabilización se dispone de máximo 3 meses para este fin, lo que
significa que al finalizar estos tres meses deberá haber una prueba final que validará el
funcionamiento conjunto del equipamiento ITS NO SIRCI teniendo de referencia sus servicios.
Por otra parte, si el bus logra estabilizarse antes de los tres meses, se deberá notificar por parte
del operador al ente gestor sobre este fin.

8 VERIFICACIÓN DEL SISTEMA

Al momento de instalar y configurar el STS en cada vehículo del Ente Gestor, el Concesionario
de Provisión debe garantizar que se cumple lo dispuesto en los requisitos del sistema, acuerdos
de nivel de servicio y plan de verificación. El Ente Gestor o entidad designada por este debe
determinar que se ha implementado el sistema correctamente siguiendo el plan de verificación
diseñado para este fin junto con los planes maestros de implementación y protocolo(s) de
articulación a que haya lugar o de acuerdo con lo que se estipule en las obligaciones
contractuales de este proceso o en los documentos a que haya lugar, teniendo de referencia
equipamiento ITS NO SIRCI. A continuación, se presenta el plan de verificación diseñado, en el
que se especifican los métodos y procesos propuestos para determinar que se ha implementado
el Sistema correctamente.

8.1 Medidas de verificación para las funcionalidades del sistema

Las medidas de verificación se especifican con el objetivo de tener una herramienta para la
comprobación del correcto funcionamiento del Sistema, teniendo en cuenta las funciones
definidas y presentadas en la sección "Especificaciones técnicas ITS”. A continuación, se
visualizan las medidas de verificación para cada funcionalidad principales del Sistema. El Ente
Gestor o quien este designe, podrá incorporar otras validaciones sin que exista objeción por
parte del Concesionario de Provisión y/o Concesionario de Operación.

8.1.1 Funcionalidad "Reconocer al conductor"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad "Reconocer al

conductor".

Identificador VSTS-001
Nombre Verificar el reconocimiento exitoso del conductor
Descripción Permitir que El Ente Gestor del sistema o ente asignado pueda
verificar que la cámara del STS captura la imagen del rostro
del conductor e identifica si el conductor se encuentra o no en
el volante.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste o cambio en la cámara del
conductor

89
 Método Pruebas
Funcionalidad Reconocer que hay o no conductor en el volante

8.1.2 Funcionalidad " Detección de comportamientos anómalos"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad "Detección de

comportamientos anómalos".

Identificador VSTS-002
Nombre Verificar que la cámara del conductor permita la detección de
comportamientos anómalos
Descripción Permitir que El Ente Gestor del sistema o ente asignado pueda
verificar la exitosa detección de comportamientos anómalos
como: microsueños, detección de uso del celular, detección de
que el conductor está fumando, detección de que el conductor
está distraído y no está mirando al frente.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste o cambio en la cámara del
conductor
Método Pruebas
Funcionalidad Identificar comportamientos anormales en el conductor

8.1.3 Funcionalidad " Reportar imagen del rostro del conductor"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad "Reportar imagen

del rostro del conductor".

Identificador VSTS-003
Nombre Verificar el envío de la imagen del rostro del conductor
Descripción Permitir que El Ente Gestor del sistema o ente asignado pueda
verificar la correcta implementación de la funcionalidad que
permite el envío de información asociada a la imagen del
conductor, al inicio y al final de la operación.
Se debe verificar que el procedimiento de envío cumpla con
los requerimientos definidos por el Centro de Gestión del Ente
Gestor.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste o cambio en la cámara del
conductor
Método Pruebas
Funcionalidad Identificar el envío exitoso de la información asociada a la
imagen del conductor.

90
8.1.4 Funcionalidad " Recibir validación del reconocimiento del conductor"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad " Recibir

validación del reconocimiento del conductor ".

Identificador VSTS-004
Nombre Verificar la recepción de la validación del reconocimiento del
conductor
Descripción Permitir que El Ente Gestor del sistema o ente asignado pueda
verificar la correcta recepción de la validación del
reconocimiento del conductor por parte del Centro de Gestión.
Se debe verificar que el procedimiento de recepción cumpla
con los requerimientos definidos por el Centro de Gestión del
Ente Gestor
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste sobre el STS
Método Pruebas
Funcionalidad Identificar la recepción exitosa de la validación del
reconocimiento del conductor.

8.1.5 Funcionalidad " Autoajustable de la cámara del conductor "

En la siguiente tabla se presenta la medida de verificación de la funcionalidad " Autoajuste de

la cámara del conductor ".

Identificador VSTS-005
Nombre Verificar la funcionalidad de autoajuste de la cámara del
conductor
Descripción Permitir que El Ente Gestor del sistema o ente asignado pueda
verificar la funcionalidad de ajuste automático de la cámara
para la operación de día y noche y del rango dinámico amplio
(WDR) o esquemas minidomo IP.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste sobre la cámara del
conductor
Método Pruebas
Funcionalidad Identificar el autoajuste de la visión nocturna de la cámara del
conductor

8.1.6 Funcionalidad " Envió automático de video e imágenes del CCTV"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad "Envió

automático de video e imágenes del CCTV ".

91
 Identificador VSTS-006
Nombre Verificar la función de envió automático de video e imágenes
del CCTV
Descripción Permitir que El Ente Gestor del sistema o quien este designe
pueda verificar la funcionalidad de envió automático del video
e imágenes del CCTV y de la cámara del conductor al Centro de
Gestión del Ente Gestor cuando se active la alarma del botón
de pánico.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste sobre el CCTV
Método Pruebas
Funcionalidad Identificar el envío automático de video e imágenes del CCTV

8.1.7 Funcionalidad " Grabación de video del CCTV"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad "Grabación de

video del CCTV ".

Identificador VSTS-007
Nombre Verificar la cobertura del video grabado en el CCTV
Descripción Permitir que El Ente Gestor del sistema o quien este designe
pueda verificar que las grabaciones de video del CCTV cubran
todo el interior del vehículo, más la cámara frontal y trasera.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste sobre el CCTV
Método Pruebas
Funcionalidad Validar que el vehículo este cubierto por cámaras de video y
que exista un mínimo de puntos ciegos

8.1.8 Funcionalidad " Conteo de pasajeros que ingresan y salen del vehículo"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad " Conteo de

pasajeros que ingresan y salen del vehículo ".

Identificador VSTS-008
Nombre Verificar el funcionamiento del contador de pasajeros del
vehículo
Descripción Permitir que El Ente Gestor del sistema o quien este designe
pueda verificar el funcionamiento y la precisión de los
sensores para conteo de pasajeros al interior del bus
(pasajeros que se suben y se bajan por las puertas y pasajeros
que permanecen en el bus).
Periodicidad Por primera vez cuando el sistema se implemente.

92
 Identificador VSTS-008
Cada vez que se realice un ajuste sobre el sistema o sensor de
conteo de pasajeros
Método Pruebas
Funcionalidad Conteo de pasajeros que suben y bajan del vehículo y
pasajeros que permanecen en el bus cada vez que se cierran
las puertas

8.1.9 Funcionalidad " Visualización remota de las imágenes del CCTV"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Visualización

remota de las imágenes del CCTV ".

Identificador VSTS-009
Nombre Verificar la función de visualización remota de las imágenes
del CCTV
Descripción Permitir que El Ente Gestor del sistema o quien este designe
pueda verificar la función para observar en tiempo de
operación y de manera remota las imágenes del CCTV cuando
sea requerido.
Periodicidad Semestralmente
Método Pruebas
Funcionalidad Control y visualización de las cámaras del CCTV bajo demanda

8.1.10 Funcionalidad " Captura de imágenes al exterior del vehículo"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Captura de

imágenes al exterior del vehículo".

Identificador VSTS-010
Nombre Verificar la captura de imágenes al exterior del vehículo
Descripción Permitir que El Ente Gestor del sistema o quien este designe
pueda verificar la captura de imágenes desde la cámara frontal
con un ángulo de visión mínimo de 130° y desde la cámara
trasera con un ángulo de visión de mínimo de 120°
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste sobre cámara frontal o
trasera
Método Pruebas
Funcionalidad Captura de imágenes fuera del vehículo

93
8.1.11 Funcionalidad " Descarga manual de videos del CCTV "

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Descarga manual

de videos del CCTV".

Identificador VSTS-011
Nombre Descarga manual de videos del CCTV
Descripción Permitir que El Ente Gestor del sistema o quien este designe
pueda verificar la funcionalidad de descarga manual de videos
del CCTV, cuando sea requerido.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste sobre el CCTV
Método Pruebas
Funcionalidad Captura y almacenamiento de imágenes y video

8.1.12 Funcionalidad "Captura de datos de cabina al encender el vehículo"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Captura de datos

de cabina al encender el vehículo".

Identificador VSTS-012
Nombre Verificar la captura exitosa de los datos de cabina al encender
el vehículo
Descripción Permitir que El Ente Gestor del sistema o quien este designe
pueda verificar la captura exitosa de los datos de cabina al
encender el vehículo tal como se consideró anteriormente y
con respecto a las variables descritas.
Periodicidad Por primera vez cuando el sistema se implemente.
Semestralmente
Método Pruebas
Funcionalidad Trazabilidad y control sobre el estado del vehículo al
momento de encenderlo

8.1.13 Funcionalidad " Reportar los datos del rendimiento del motor y CANBUS"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Reportar los

datos del rendimiento del motor y CANBUS".

Identificador VSTS-013
Nombre Verificar la recepción de los datos del rendimiento del motor
y CANBUS
Descripción Permitir que El Ente Gestor del Sistema o quien este designe
pueda verificar que todos los datos capturados por los
sensores y por las cámaras del CCTV se envíen al Centro de

94
 Identificador VSTS-013
Gestión siguiendo los periodos de tiempo establecidos para
cada tipo de dato y siguiendo la trama definida para el envío
de la información.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste o cambio en las
comunicaciones del STS
Método Pruebas
Funcionalidad Reportar datos del vehículo

8.1.14 Funcionalidad " Configuración de los rangos de los dispositivos del STS"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Configuración

de los rangos de los dispositivos del STS".

Identificador VSTS-014
Nombre Verificar la funcionalidad de configuración de rangos de los
dispositivos del STS
Descripción Permitir que El Ente Gestor del Sistema o quien este designe
pueda verificar que todos los dispositivos del STS permitan
configurar de manera manual y automática los rangos de
medidas asociadas a cada dispositivo.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste o cambio en las
comunicaciones del STS.
Cada vez que se cambie un dispositivo del STS
Método Pruebas
Funcionalidad Configuración de rangos de los dispositivos del STS

8.1.15 Funcionalidad " Parametrizar tipos de alertas"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Parametrizar

tipos de alertas ".

Identificador VSTS-015
Nombre Verificar la funcionalidad de parametrización de alertas
Descripción Permitir que El Ente Gestor del Sistema o quien este designe
pueda verificar que todos los dispositivos del STS permitan
parametrizar alertas hacia el Centro de Gestión del Ente
Gestor a partir de los rangos definidos para cada dispositivo.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste o cambio en los dispositivos
del STS
Cada vez que se genere un nuevo tipo de alerta

95
 Método Pruebas
Funcionalidad Parametrización de alertas hacia el Centro de Gestión

8.1.16 Funcionalidad " Registro de alertas"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Registro de

alertas".

Identificador VSTS-016
Nombre Verificar la generación y registro de una alerta
Descripción Permitir que El Ente Gestor del Sistema o quien este designe
pueda verificar que todos los dispositivos del STS generen una
alerta cuando registren un valor fuera del rango
parametrizado. Al generar una alerta se debe registrar la
fecha, la hora y los datos por los que se emitió la alerta, esto
debe poder visualizar en el Centro de Gestión.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste o cambio en los dispositivos
del STS
Cada vez que se genere un nuevo tipo de alerta
Método Pruebas
Funcionalidad Generación de alertas hacia el Centro de Gestión

8.1.17 Funcionalidad " Identificar obstáculos en las maniobras de reversa"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Identificar

obstáculos en las maniobras de reversa ".

Identificador VSTS-017
Nombre Identificar obstáculos en las maniobras de reversa
Descripción Permitir que El Ente Gestor del Sistema o quien este
designepueda verificar que el sensor de reversa identifique y
alerte al conductor sobre los obstáculos existentes al realizar
las maniobras de reversa.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste o cambio en el sensor de
reversa
Trimestralmente
Método Pruebas
Funcionalidad Identificación de obstáculos en las maniobras de reversa

96
8.1.18 Funcionalidad “Generar alerta por incremento de temperatura del motor del
vehículo"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Generar alerta

por incremento de temperatura del motor del vehículo”

Identificador VSTS-019
Nombre Verificar la generación de una alerta visual por incremento de
temperatura del motor del vehículo
Descripción Permitir que El Ente Gestor del Sistema o quien este designe
pueda verificar la correcta generación de una alerta visual que
le permita identificar el conductor un incremento en la
temperatura del motor del vehículo (teniendo de referencia su
tipología)
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste o cambio en el sensor de
temperatura
Método Pruebas
Funcionalidad Control y trazabilidad sobre la temperatura del motor del
vehículo

8.1.19 Funcionalidad “Reportar aceleración y velocidad del vehículo"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Reportar

aceleración y velocidad del vehículo”

Identificador VSTS-020
Nombre Verificar la recepción de los datos de aceleración y velocidad
Descripción Permitir que El Ente Gestor del Sistema o quien este designe
pueda verificar la recepción de los datos de aceleración y
velocidad del vehículo cada veinte (20) segundos (o el valor
parametrizado por El Ente Gestor) en el Centro de Gestión. La
transmisión de estos datos debe realizarse a través de
servicios web
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste o cambio en el sensor de
velocidad
Cada vez que se realice un ajuste o cambio en las
comunicaciones del STS.
Método Pruebas
Funcionalidad Control y trazabilidad sobre la velocidad y la aceleración del
vehículo

97
8.1.20 Funcionalidad “Generar alerta por desgaste de las pastillas de frenos"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Generar alerta

por desgaste de las pastillas de frenos”

Identificador VSTS-021
Nombre Verificar la generación de una alerta visual por desgaste de las
pastillas de frenos
Descripción Permitir que El Ente Gestor del Sistema o quien este designe
pueda verificar la correcta generación de una alerta visual que
le permita identificar el conductor el desgaste de las pastillas
de frenos
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste o cambio en el sensor de
frenos
Método Pruebas
Funcionalidad Control y trazabilidad sobre las pastillas de frenos

8.1.21 Funcionalidad “Detectar el kilometraje recorrido por el vehículo"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Detectar el

kilometraje recorrido por el vehículo”

Identificador VSTS-022
Nombre Verificar la correcta detección del kilometraje recorrido
Descripción Permitir que El Ente Gestor del Sistema o quien este designe
pueda verificar la correcta detección del kilometraje recorrido
a partir de los datos generados por el odómetro.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste o cambio en el sensor de
kilometraje
Método Pruebas
Funcionalidad Control y trazabilidad sobre los kilómetros recorridos por el
vehículo

8.1.22 Funcionalidad “Anunciar próximas paradas"

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Anunciar

próximas paradas”

Identificador VSTS-023
Nombre Anunciar próximas paradas del bus

98
 Descripción Permitir que El Ente Gestor del sistema o quien este designe
pueda verificar la emisión de audio con las dos (2) próximas
paradas del bus, la posición actual, el destino y la fecha y hora.
Periodicidad Mensualmente
Método Pruebas
Funcionalidad Brindar información oportuna al usuario del Sistema

8.1.23 Funcionalidad “Configurar distribución de las pantallas”

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Configurar

distribución de las pantallas”

Identificador VSTS-024
Nombre Configuración la distribución de espacio de las pantallas
Descripción Permitir que El Ente Gestor del sistema o quien este designe
pueda verificar el proceso de configuración de la distribución
de información en las pantallas
Periodicidad Por primera vez cuando el sistema se implemente y cada vez
que se realice un ajuste en el STDI.
Método Pruebas
Funcionalidad Distribuir la información a desplegar en las pantallas

8.1.24 Funcionalidad “Despliegue de información de pantallas”

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Despliegue de

información de pantallas”

Identificador VSTS-025
Nombre Verificar el despliegue de información en las pantallas
Descripción Permitir que El Ente Gestor del sistema o quien este designe
pueda verificar la visualización de los datos informativos y
publicitarios en la/s pantalla/s integradas al bus.
Periodicidad Por primera vez cuando el sistema se implemente y cada vez
que se realice un ajuste en el STDI.
Método Pruebas
Funcionalidad Brindar información oportuna al usuario del Sistema

8.1.25 Funcionalidad “Control de Acceso al STDI”

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Control de

Acceso al STDI”

Identificador VSTS-026
Nombre Verificar el control de acceso al STDI

99
 Identificador VSTS-026
Descripción Verificar que el STDI permita el acceso únicamente mediante
HTTPS, SSH o equivalente.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Mensualmente
Método Pruebas e inspección
Funcionalidad Seguridad del STDI

8.1.26 Funcionalidad “Sincronización de tiempo en el STDI”

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Sincronización

de tiempo en el STDI”

Identificador VSTS-027
Nombre Verificar la sincronización de tiempo en el STDI
Descripción Verificar que el STDI se encuentre sincronizados bajo la misma
referencia de tiempo del Centro de Gestión a través servidores
de tiempo confiables y precisos (con relojes atómicos)
mediante protocolo NTP (Network Time Protocol por su
acrónimo en inglés), estableciendo en el
servidor como su zona horaria, la oficial para la República de
Colombia.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Mensualmente
Método Pruebas e inspección
Funcionalidad Confiabilidad de la información

8.1.27 Funcionalidad “Despliegue de contenido de entretenimiento pregrabado”

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Despliegue de

contenido de entretenimiento pre-grabado”

Identificador VSTS-028
Nombre Verificar el despliegue de contenido de entretenimiento
pregrabado
Descripción Verificar que el sistema de entretenimiento del STDI permita
la correcta difusión y despliegue del contenido pregrabado a
través de una red WiFi propia del bus.

100
 Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en el STDI
Cada vez que se realice mantenimiento o cambio en el
contenido pregrabado
Método Pruebas
Funcionalidad Despliegue del sistema de entretenimiento en el bus

8.1.28 Funcionalidad “Acceso a Internet de los usuarios”

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Acceso a Internet

de los usuarios”

Identificador VSTS-029
Nombre Verificar el acceso a Internet en los buses zonales
Descripción Verificar que el sistema de entretenimiento del STDI permita
mediante su aplicación Web el acceso a Internet de los
usuarios mínimos expuestos en el documento, para ello, debe
tomar ventaja de la red WiFi desplegada al interior del bus y
debe verificarse que se cuente con las restricciones de
streeming de video en cuanto a navegación web.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en el STDI
Cada vez que se realice mantenimiento o actualización al STDI
Método Pruebas
Funcionalidad Acceso a Internet en el bus

8.1.29 Funcionalidad “Reportar datos del vehículo”

En la siguiente tabla se presenta la medida de verificación de la funcionalidad “Reportar datos

del vehículo”

Identificador VSTS-030
Nombre Verificar el reporte exitoso de los datos del STS al Centro de
Gestión
Descripción Permitir que El Ente Gestor del Sistema o quien este designe
pueda verificar que todos los datos capturados por los
sensores y por las cámaras del CCTV se envíen al Centro de
Gestión siguiendo los periodos de tiempo establecidos para
cada tipo de dato y siguiendo la trama definida para el envío
de la información.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice un ajuste o cambio en las
comunicaciones del STS.
Método Pruebas

101
 Funcionalidad Reportar datos del vehículo

8.1.30 Funcionalidad “Integración de los elementos ITS”

En la siguiente tabla se presenta la medida de verificación del requisito “Integración de los

elementos ITS”

Identificador VSTS-031
Nombre Integración de los elementos ITS
Descripción Las tramas que son enviadas por los ruteros y el PIP deben ser
abiertas, interpretables en términos de lectura
Periodicidad Por primera vez durante el ciclo de desarrollo del sistema.
Cuando el sistema se implemente y pase a producción.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Diariamente y Mensualmente según periodicidad de EMIC y
ETIC
Método Pruebas

8.2 Medidas de verificación para las no funcionales

Las medidas de verificación validan la conformidad respecto a lo establecido como los

requisitos no funcionales del sistema, así:

8.2.1 Requisito no funcional “Respaldos de información”

En la siguiente tabla se presenta la medida de verificación del requisito “Respaldos de

información”

Identificador VSTSNF-001
Nombre Verificar los respaldos de información
Descripción Permitir que El Ente Gestor del Sistema o quien este designe
pueda verificar que existan los respaldos de información que
cumplan con el punto de recuperación objetivo de los
componentes del sistema.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Mensualmente

102
 Identificador VSTSNF-001
Método Pruebas e inspección de los logs de auditoría

8.2.2 Requisito no funcional “Capacidad del canal de comunicaciones”

En la siguiente tabla se presenta la medida de verificación del requisito “Capacidad del canal de
comunicaciones”

Identificador VSTSNF-002
Nombre Verificar la capacidad del canal de comunicaciones
Descripción Verificar que los vehículos cuenten con un canal de
comunicaciones con la capacidad suficiente (ancho de banda y
de transferencia) para transmitir y recibir de manera
permanente los datos requeridos. En este sentido, es el
Concesionario de Provisión dependiendo de su necesidad a
nivel de flota, es quien debe garantizar a partir de la cantidad
de sus equipos instalados en los buses, que el canal de
comunicaciones cumpla y es suficiente con lo que se requiere
desde El Ente Gestor (para su Centro de Gestión) y este, es
decir El Ente Gestor, es quien avalará el canal de
comunicaciones a partir de algunas pruebas de calidad y
satisfacción de la transmisión de información, sin lugar a
objeciones en caso de requerir futuras ampliaciones del
mismo
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Mensual
Método Pruebas e inspección

8.2.3 Requisito no funcional “Respaldo de energía”

En la siguiente tabla se presenta la medida de verificación del requisito “Respaldo de energía”

Identificador VSTSNF-003
Nombre Verificar el respaldo de energía
Descripción Verificar que el sistema de alimentación eléctrica del STS
tenga un mecanismo de respaldo de energía que permita que
el sistema pueda alertar en caso de quedarse sin la fuente de
alimentación principal del vehículo y permita una
contingencia de un (1) día. Durante este periodo de tiempo, el
STS, únicamente reportarán señales de alarma, posición
geográfica y botón de pánico al STS

103
 Identificador VSTSNF-003
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Cuando se presente algún incidente o indisponibilidad de los
componentes o del servicio.
Prueba o simulacro anual.
Método Pruebas e inspección

8.2.4 Requisito no funcional “Latencia para transacciones y escritura”

En la siguiente tabla se presenta la medida de verificación del requisito “Latencia para

transacciones y escritura”

Identificador VSTSNF-004
Nombre Verificar la latencia para transacciones y escritura
Descripción Verificar que la infraestructura tecnológica del STS tenga un
tiempo de respuesta (latencia) para transacciones y escritura
menor a un (1) segundo.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Mensualmente
Método Pruebas e inspección

8.2.5 Requisito no funcional “Capacidad de almacenamiento del CCTV”

En la siguiente tabla se presenta la medida de verificación del requisito “Capacidad de

almacenamiento del CCTV”

Identificador VSTSNF-005
Nombre Verificar la capacidad de almacenamiento del CCTV
Descripción Verificar que el CCTV almacene al menos treinta (30) días de
video de las cámaras que están instaladas al interior del
vehículo a 720p o 0.9MP en color, y al menos a 8 FPS, con
georreferenciación y un identificador de la posición de la
cámara.
Periodicidad Por primera vez durante el ciclo de desarrollo del sistema.
Cuando el sistema se implemente y pase a producción.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.

104
 Identificador VSTSNF-005
Anualmente
Método Pruebas e inspección

8.2.6 Requisito no funcional “Confiabilidad del CCTV”

En la siguiente tabla se presenta la medida de verificación del requisito “Confiabilidad del CCTV”

Identificador VSTSNF-006
Nombre Verificar la confiabilidad del CCTV
Descripción Verificar que los componentes del CCTV tengan un MTBF
superior o igual a sesenta mil (60.000) horas certificado por el
fabricante
Periodicidad Por primera vez durante el ciclo de desarrollo del sistema.
Cuando el sistema se implemente y pase a producción.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Método Pruebas e inspección

8.2.7 Requisito no funcional “Disponibilidad del CCTV”

En la siguiente tabla se presenta la medida de verificación del requisito “Disponibilidad del

CCTV”

Identificador VSTSNF-007
Nombre Verificar la disponibilidad del CCTV
Descripción Verificar que los componentes del CCTV tengan una
disponibilidad de al menos el noventa y nueve por ciento
(99%) durante el tiempo de operación, pero en todo caso
deberán cumplir los ANS establecidos en el anexo de Niveles
de Servicio.
Periodicidad Por primera vez durante el ciclo de desarrollo del sistema.
Cuando el sistema se implemente y pase a producción.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Método Pruebas e inspección

8.2.8 Requisito no funcional “Claves de las cámaras del CCTV de los vehículos”

En la siguiente tabla se presenta la medida de verificación del requisito “Claves de las cámaras
del CCTV de los vehículos”

105
 Identificador VSTSNF-008
Nombre Verificar las claves de las cámaras del CCTV de los vehículos
Descripción Verificar que se tenga una política y el cumplimiento de los
procedimientos correspondientes para el cambio de las claves
de las cámaras del CCTV de los vehículos, de forma rutinaria,
establecida y documentada; y que evite el uso de las claves por
defecto.
Periodicidad Por primera vez cuando el sistema se implemente.
Por primera vez cuando la política se defina.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Cada vez que se actualice la política y procedimientos.
Anualmente
Método Pruebas e inspección

8.2.9 Requisito no funcional “Ciframiento de la información del CCTV”

En la siguiente tabla se presenta la medida de verificación del requisito “Ciframiento de la

información del CCTV”

Identificador VSTSNF-009
Nombre Verificar el ciframiento de la información del CCTV
Descripción Verificar que los videos del sistema CCTV sean almacenados
de manera cifrada en disco y transmitidos a través del túnel
cifrado TLS, teniendo en cuenta que la información tratada se
encuentra protegida por normativa de protección de datos
personales.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Trimestralmente
Método Pruebas e inspección

8.2.10 Requisito no funcional “Protección contra acceso físico al CCTV”

En la siguiente tabla se presenta la medida de verificación del requisito “Protección contra

acceso físico al CCTV”

Identificador VSTSNF-010
Nombre Verificar protección contra acceso físico al CCTV
Descripción Desde fábrica se debe asegurar que las cámaras del sistema
CCTV, el cableado, y los contenedores de los equipos que

106
 Identificador VSTSNF-010
corresponden al STS se encuentren debidamente protegidos
de acceso físico no autorizado, corte de energía hacía los
mismos, así como de la remoción, robo y daño de sus
componentes
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Anualmente
Método Pruebas e inspección

8.2.11 Requisito no funcional “Capacidad de operación del CCTV”

En la siguiente tabla se presenta la medida de verificación del requisito “Capacidad de

operación del CCTV”

Identificador VSTSNF-011
Nombre Verificar la capacidad de operación del CCTV
Descripción Verificar que todos los componentes del CCTV estén en
capacidad de operar al menos a veinte (20) imágenes por
segundo.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Anualmente
Método Pruebas e inspección

8.2.12 Requisito no funcional “Control de acceso al STS”

En la siguiente tabla se presenta la medida de verificación del requisito “Control de acceso al

STS”

Identificador VSTSNF-012
Nombre Verificar el control de acceso al STS
Descripción Verificar que el STS tenga un firewall o sistema equivalente
que cierre todos los puertos de acceso al STS y que permita el
acceso únicamente a través del protocolo SSH (mediante el
empleo de un esquema de autenticación) para descargar los
videos de cada vehículo que se requiera.
Periodicidad Por primera vez cuando el sistema se implemente.

107
 Identificador VSTSNF-012
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Mensualmente
Método Pruebas e inspección

8.2.13 Requisito no funcional “Conexiones TLS al STS”

En la siguiente tabla se presenta la medida de verificación del requisito “Conexiones TLS al STS”

Identificador VSTSNF-013
Nombre Verificar Conexiones TLS al STS
Descripción Verificar que todas las conexiones desde/hacía el STS sean
establecidas a través de HTTPS, SSH o equivalente, sobre un
túnel cifrado TLS.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Trimestralmente
Método Pruebas e inspección

8.2.14 Requisito no funcional “Acceso restringido al almacenamiento del STS”

En la siguiente tabla se presenta la medida de verificación del requisito “Acceso restringido al

almacenamiento del STS”

Identificador VSTSNF-014
Nombre Verificar que el acceso al almacenamiento del STS sea
restringido
Descripción Verificar que el usuario operativo que realiza las funciones de
descarga de la información registrada en el dispositivo de
almacenamiento del STS, tenga privilegios restringidos para
sólo consulta y descarga y que se alinee a la cadena de custodia
establecida por parte del Ente Gestor
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Mensualmente
Método Pruebas e inspección

108
8.2.15 Requisito no funcional “Tratamiento de datos personales”

En la siguiente tabla se presenta la medida de verificación del requisito “Tratamiento de datos

personales”

Identificador VSTSNF-015
Nombre Verificar el adecuado tratamiento de datos personales
Descripción Verificar que se realice el tratamiento de los datos personales
de manera adecuada: evitando ponerlos en riesgo de
divulgación y acceso no autorizado, y evitando que puedan ser
usados para fines no previstos y no autorizados en la política
de tratamiento establecida, dando cumplimiento a la Ley 1581
de 2012 y decretos reglamentarios)
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Mensualmente
Método Pruebas e inspección

8.2.16 Requisito no funcional “Transacciones atómicas”

En la siguiente tabla se presenta la medida de verificación del requisito “Transacciones

atómicas”

Identificador VSTSNF-016
Nombre Verificar transacciones atómicas
Descripción Verificar que entre el Centro de Gestión y el STS del vehículo
no se establezca ninguna sesión permanente y que cada
transacción sea atómica y realizada a través del túnel cifrado
en dos vías establecido por el certificado digital del Centro de
Gestión y el STS del vehículo.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Mensualmente
Método Pruebas e inspección

8.2.17 Requisito no funcional “Protocolo port knocking”

En la siguiente tabla se presenta la medida de verificación del requisito “Protocolo port

knocking”

109
 Identificador VSTSNF-017
Nombre Verificar implementación y uso de protocolo port knocking
Descripción Verificar que el sistema utilice el protocolo de port knocking
iniciado por el sistema STS del vehículo, el cual habilitará el
puerto determinado para establecer el túnel TLS en dos vías,
para que el STS del vehículo pueda consumir servicios web del
Centro de Gestión.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Mensualmente
Método Pruebas e inspección

8.2.18 Requisito no funcional “Trazabilidad y auditoría”

En la siguiente tabla se presenta la medida de verificación del requisito “Trazabilidad y

auditoría”

Identificador VSTSNF-018
Nombre Verificar trazabilidad y auditoría
Descripción Verificar que el STS tenga los logs de trazabilidad y auditoría
interna, mediante el registro de logs de todas las actividades
realizadas en el sistema, tanto las exitosas como los intentos
fallidos.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Diariamente y Mensualmente según periodicidad de EMIC y
ETIC
Método Pruebas e inspección

8.2.19 Requisito no funcional “Confiabilidad de sensores de motor y de conducción del

vehículo”

En la siguiente tabla se presenta la medida de verificación del requisito “Confiabilidad de

sensores de motor y de conducción del vehículo”

Identificador VSTSNF-019
Nombre Verificar la confiabilidad de los sensores del motor y de
conducción del vehículo

110
 Identificador VSTSNF-019
Descripción Verificar que el sistema de sensores del motor y de conducción
del vehículo tengan un MTBF superior o igual a cuarenta mil
(40.000) horas certificados por el fabricante
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Diariamente y Mensualmente según periodicidad de EMIC y
ETIC
Anualmente
Método Pruebas e inspección

8.2.20 Requisito no funcional “Disponibilidad de sensores de motor y de conducción del

vehículo”

En la siguiente tabla se presenta la medida de verificación del requisito “Disponibilidad de

sensores de motor y de conducción del vehículo”

Identificador VSTSNF-020
Nombre Verificar la disponibilidad de los sensores del motor y de
conducción del vehículo
Descripción Verificar que los sensores del motor y de conducción del
vehículo tengan una disponibilidad igual o superior al noventa
y nueve por ciento (99%) en el último año de funcionamiento,
mediante la inspección de los datos almacenados localmente o
reportados al Centro de Gestión
Periodicidad Diariamente y Mensualmente según periodicidad de EMIC y
ETIC
Anualmente
Método Pruebas e inspección

8.2.21 Requisito no funcional “Confiabilidad de sensores de cabina del vehículo”

En la siguiente tabla se presenta la medida de verificación del requisito “Confiabilidad de

sensores de cabina del vehículo”

Identificador VSTSNF-021
Nombre Verificar la confiabilidad de los sensores de la cabina del
vehículo
Descripción Verificar que el sistema de sensores de la cabina del vehículo
tenga un MTBF superior o igual a cuarenta mil (40.000) horas,
certificado por el(los) fabricante(s).
Periodicidad Por primera vez durante el ciclo de desarrollo del sistema.

111
 Identificador VSTSNF-021
Cuando el sistema se implemente y pase a producción.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Diariamente y Mensualmente según periodicidad de EMIC y
ETIC
Método Inspección

8.2.22 Requisito no funcional “Disponibilidad de sensores de cabina del vehículo”

En la siguiente tabla se presenta la medida de verificación del requisito “Disponibilidad de

sensores de cabina del vehículo”

Identificador VSTSNF-022
Nombre Verificar la disponibilidad de los sensores de la cabina del
vehículo
Descripción Verificar que los sensores del motor y de conducción del
vehículo tengan una disponibilidad igual o superior al noventa
y nueve por ciento (99%) en el último año de funcionamiento,
mediante la inspección de los datos almacenados localmente o
reportados al Centro de Gestión.
Periodicidad Diariamente y Mensualmente según periodicidad de EMIC y
ETIC
Anualmente
Método Pruebas e inspección

8.2.23 Requisito no funcional “Notificación alerta al Centro de Gestión”

En la siguiente tabla se presenta la medida de verificación del requisito “Notificación alerta al

Centro de Gestión”

Identificador VSTSNF-023
Nombre Verificar él envió de la notificación de alertar
Descripción Verificar que una vez activado el botón de pánico se notifique
al Centro de Gestión en un tiempo menor a cinco (5) segundos.
Periodicidad Por primera vez cuando el sistema se implemente.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes del botón de
pánico.
Diariamente y Mensualmente según periodicidad de EMIC y
ETIC
Trimestralmente
Método Pruebas e inspección

112
8.2.24 Requisito no funcional “Confiabilidad pantallas STDI”

En la siguiente tabla se presenta la medida de verificación del requisito “Confiabilidad pantallas

STDI”

Identificador VSTSNF-024
Nombre Verificar la confiabilidad de las pantallas del STDI
Descripción Verificar que las pantallas del STDI tengan un MTBF superior
o igual a cuarenta mil (40.000) horas, certificado por el(los)
fabricante(s).
Periodicidad Por primera vez durante el ciclo de desarrollo del sistema.
Cuando el sistema se implemente y pase a producción.
Cada vez que se realice mantenimiento o cambio en
configuración, software y/o los componentes de la
infraestructura tecnológica.
Diariamente y Mensualmente según periodicidad de EMIC y
ETIC
Método Inspección

9 LUGARES DE ESTACIONAMIENTO DE LOS BUSES

Para este apartado se resalta que es El Ente Gestor quien deberá autorizar el despliegue de
equipos tecnológicos que hagan parte de todo los ITS dimensionados en patios por el
Concesionario de Provisión sobre los lugares de estacionamiento y considerados de acuerdo al
anexo de patios. Allí se deberán instalar y desplegar esquemas de redes de telecomunicaciones
que garanticen el esquema de intercambio de información expuesto en este anexo y se deberán
contar con sistemas de almacenamiento para las diversas situaciones y variables a que haya
lugar.

113
Se requiere resaltar que el Concesionario de Operación puede hacer uso ya sea de redes
inalámbricas o cableadas, gestionando con el Concesionario de Provisión lo necesario para
responder ante unos acuerdos de niveles de servicio mínimos que serán expuestos en los
anexos técnicos de este proceso de licitación.

Si se llegase a instalar infraestructura tecnológica de forma temporal se requiere que esta

responda efectivamente tomando de referencia todos los requisitos expuestos en el documento.
Una vez se dispongan de forma definitiva de los lugares de estacionamiento de los buses en
concordancia con el anexo de patios, el Concesionario de Provisión deberá presentar un plan
para adecuar los lugares de estacionamiento a fin de dar continuidad a la operación de todos
los ITS que hacen parte de este proceso de licitación, este plan deberá actualizarse las veces que
se considere pertinente, en función de las necesidades operativas tales como cantidad de
información y/o cantidad de flota y/o en función de las nuevas tendencias tecnológicas. Por su
parte, el despliegue de este plan, el mantenimiento, actualización, y operación de la solución
implementada, será responsabilidad del concesionario de operación

Así mismo, todos los estacionamientos deberán de disponer de un sitio para el mantenimiento
preventivo y correctivo de todos los ITS que se abordan en este documento, y del espacio para
el mantenimiento de los equipos a bordo a cargo del SIRCI de acuerdo a las especificaciones
contenidas en el protocolo de articulación vigente y lo que adicionalmente se incluya en el
contrato actual para este fin.

El espacio de mantenimiento de los equipos a bordo a cargo del SIRCI debe cumplir como
mínimo con las siguientes especificaciones:

• Tener un lugar fijo, demarcado en el piso para parqueo de los buses a intervenir y con
letrero de atención SIRCI (señalizado) en el patio para atención de mantenimientos
SIRCI
• Que este lugar este con piso firme
• Que este lugar cuente con buena iluminación tanto para trabajos de día como de noche
• Que en este lugar se cuente al menos con una toma corriente doble
• Que este lugar este cubierto

10 RENOVACIÓN, INSTALACIÓN Y MANTENIMIENTO DE EQUIPOS

10.1 Instalación

El Concesionario de Provisión deberá instalar todos los equipos referentes a los requerimientos
expuestos en este documento y deberá tener muy en cuenta la parametrización eléctrica de
cada uno de ellos y su independencia para generar esquemas confiables de operación y servicio.

114
10.2 Renovación

El Concesionario de Operación será el responsable de cualquier tipo de daño o pérdida que se

cause a los equipos a bordo de los buses y deberá asumir los costos que sean necesarios para
repararlos y mantenerlos en adecuadas condiciones de presentación y funcionamiento.

Adicionalmente, las garantías que debe constituir el Concesionario de Provisión y el

Concesionario de Operación se encuentran establecidas en las minutas del respectivo contrato
de concesión y deberá ser este mismo, quien solicite, escale y tramite el cumplimiento de estas.

Todos los equipos para renovar por parte de la flota ya sea lo que están dañados o por mal
funcionamiento deberán seguir un esquema de manejo de residuos tecnológicos que deberá ser
presentado por parte del Concesionario de Provisión al Ente Gestor. Así mismo, los equipos que
se estén renovando podrán ser objeto de reutilización en algún programa en aras de la
enseñanza tecnológica o para el aprendizaje de los esquemas de funcionamiento de los equipos,
esto teniendo de base los lineamientos que establezca El Ente Gestor para este fin.

El concesrionario de Provision será el responsable de renovar los equipos ITS No SIRCI y los
requeridos por el SIRCI a cargo del Concesioanrio de Operación establecidos en el protocolo de
articulación, al cumplimiento de su vida útil o por renovación tecnológica.

10.3 Mantenimiento

El mantenimiento de todos los equipos a bordo estará a cargo del Concesionario de Operación
y en caso tal, deberá seguirse el protocolo de articulación vigente a que haya lugar, pero en todo
caso deberá articular todo de la mejor forma teniendo las consideraciones que se expongan por
la posible diversidad de actores tecnológicos que existan. Se reitera que para equipamiento ITS
NO SIRCI, se debe generar un escenario mancomunado de trabajo entre los diversos actores
estratégicos, por ello, deben considerarse las obligaciones contractuales de este proceso.

El mantenimiento se debe realizar por parte del Concesionario de Operación siguiendo el

Manual de Operación y Mantenimiento entregado (por el fabricante a través del concesionario
de provisión) con cada equipo. El estado de los equipos y el mantenimiento periódico de los
mismos exigido por el fabricante debe ser realizado por el Concesionario de Operación y puede
ser verificado en cualquier momento por El Ente Gestor o por quien este designe.

Los casos de vandalismos, hurtos, o malas manipulaciones de los equipos ITS al interior de cada
bus, deberán quedar aclarados en los acuerdos que firmen entre terceros; para los equipos
SIRCI, son los establecidos en el protocolo de articulación vigente, y sus anexos y el acuerdo
entre privados.

10.4 Reposición y disposición

Se debe programar mínimo una revisión anual general de todos los subsistemas ITS de este
anexo de los que se destacan los Equipos del STS no SIRCI y del STDI por parte del Ente Gestor
o por quien este asigne, a fin de determinar la necesidad de reponer algunos equipos por
problemas en su funcionamiento y/o interoperabilidad, en cuyo caso serán reportados en la

115
mesa de ayuda dispuesta por el Concesionario de Operación y deberá cumplir con los ANS
pactados tanto en este anexo como en el anexo de niveles de servicio.

En todo caso, el Concesionario de Provisión deberá realizar la renovación de los Equipos del
STS no SIRCI cada siete punto cinco (7.5) años, exceptuando los sensores que sean provistos de
fábrica por el constructor del vehículo. Así mismo, el Concesionario de Provisión deberá
realizar la reposición de los Equipos del STS no SIRCI y “Equipos requeridos por el SIRCI a cargo
del Concesionario de Operación” establecidos en el protocolo de articulación, que han
presentado más de dos (2) veces en un (1) mes una misma falla en el mismo dispositivo o parte.
Igualmente, deberá reponer tales equipos con su respectivo Manual de Operación y
Mantenimiento, y su correspondiente certificado de funcionamiento.

Al realizar cada uno de los cambios y al finalizar el Contrato pertinente se debe coordinar con
el Concesionario de Provisión y efectuar la disposición final de los Equipos del STS no SIRCI y
equipos SIRCI excepto de aquellos que El Ente Gestor incluya como bienes objeto de reversión.

116
11 ACUERDOS DE NIVEL DE SERVICIO

11.1 Administración de Servicio

En este apartado se precisa mencionar que el anexo técnico de ITS contempla 3 subconjuntos
tecnológicos asociados a diversos subsistemas subconjuntos de equipos ITS – No SIRCI,
subclasificados como (i)Sistema Tecnológico de Seguridad – STS, (ii) Sensores de cabina,
Sensores de Motor, y (iii) otros aditamentos para mejorar la interacción con el usuario, y su
respectivo esquema de transmisión de datos para cada uno de estos subconjuntos. De este
modo, se describe el alcance del mantenimiento y las políticas de las ventanas de
mantenimiento. Durante la operación los equipos del STS y STDI deben estar en condiciones
adecuadas y efectivas de funcionamiento. Los concesionarios de operación deberán mantener
la custodia durante la operación, con el fin de cumplir los objetivos del contrato de concesión.
El Concesionario de Operación es el responsable de mantener en operación, con la integración
y disponibilidad permanente, los diferentes equipos y dispositivos electrónicos para el
cumplimiento de los objetivos dentro del STS y STDI, en condiciones normales de cuidado y
operación. El Concesionario de Operación debe salvaguardar los equipos del STS y STDI de tal
manera que se mantenga su adecuada apariencia y presentación. Adicionalmente, deberá
realizar su limpieza externa y presentarlos en excelentes condiciones cada vez que salga a
operación.

11.2 Alcance del Mantenimiento

11.2.1 Modalidad y tiempos

El Concesionario de Operación debe efectuar, de manera programada y periódica, el

mantenimiento predictivo, preventivo y correctivo a los equipos y dispositivos electrónicos a
bordo de los buses bajo su responsabilidad, costo y riesgo. Le corresponde al Concesionario de
Operación realizar el mantenimiento de los equipos y dispositivos electrónicos del STS y STDI
a bordo del bus y deberá presentar anualmente al Ente Gestor , con dos (2) meses de
anticipación a su ejecución, los programas y planes de mantenimiento preventivo que efectuará
durante el año siguiente, detallando el programa de ejecución, de tal forma se puedan
programar los mantenimientos con antelación, para identificar los momentos en los que los
vehículos no van a prestar servicio, sin que se afecte la programación de la flota para la
operación dentro del Sistema.

11.2.2 Condiciones

Así mismo, el Concesionario de Operación deberá informar al Ente Gestor si se está poniendo
en riesgo la estabilidad de los equipos STS o STDI, o no se está cumpliendo con los planes y
programas de mantenimiento, para lo cual, deberá bajo su responsabilidad, costo y riesgo,
realizar de manera permanente, el seguimiento sobre el cumplimiento de los planes y
programas de mantenimiento presentados e igualmente verificará el estado y la funcionalidad
en que se encuentran los componentes del STS y STDI a bordo del bus.

117
11.3 Políticas de Mantenimiento
11.3.1 Supervisión

Los supervisores designados por el Concesionario de Operación realizarán revisiones regulares

y se generarán informes sobre las actividades de mantenimiento realizadas. El propósito de
estos informes es detectar problemas potenciales, situaciones o fallas recurrentes y determinar
formas de mitigación apropiadas para prevenir o minimizar sus efectos de detrimento en la
operación de los equipos.

11.3.2 Características de la Supervisión

El supervisor identificará la necesidad de acciones correctivas y realizará los reportes

correspondientes sobre su implementación.

11.3.3 Capacitación y entrenamiento

El supervisor proveerá entrenamiento y capacitación para todo el personal del departamento

que trabaje en actividades de mantenimiento.

11.4 Política general

Se debe establecer y seguir un programa de mantenimiento formal y aprobado para
salvaguardar los recursos invertidos en los equipos y optimizar el retorno de dicha inversión.
El propósito de este procedimiento es establecer los estándares y lineamientos que deben ser
seguidos para mantener la flota de vehículos.

11.4.1 Conformidad

Todo el equipamiento de los vehículos debe ser mantenido en conformidad con las
recomendaciones y procedimientos establecidos por los fabricantes OEM (Original Equipment
Manufacturer), las prácticas estándar de la industria generalmente aceptadas y, de manera
consistente con la seguridad, la confiabilidad y la operación bajo el presupuesto del
Concesionario de Operación.

11.4.2 Practicas y Estándares

Se deben seguir prácticas y estándares de mantenimiento apropiados para asegurar la

confiabilidad y seguridad del vehículo y de operación de su equipamiento.

Se debe tener consideración debida sobre las circunstancias particulares en que opera el
equipo, el tipo de equipo, su ubicación y las tareas que desempeña.

11.4.3 Vehículos defectuosos

Se debe evitar a toda costa que vehículos con equipamiento defectuoso, dañado o sin el
mantenimiento apropiado, puedan operar en el sistema de transporte masivo.

11.4.4 Mantenimiento preventivo

Todo el equipamiento de todos los vehículos debe recibir los mantenimientos preventivos
programados con la frecuencia establecida.

118
11.4.5 Lugar de mantenimiento preventivo

Los mantenimientos preventivos deberán ser realizados en los patios teniendo de referencia el
anexo de patios de este proceso, los cuales deberán contar con las instalaciones, personal
idóneo y autorizado para esto, además de estar equipado con los elementos y materiales
necesarios para poder realizar los procedimientos correspondientes.

11.4.6 Costos de daños de reparaciones inapropiadas

El costo de las reparaciones por daños producidos por uso inapropiado, reparaciones
inapropiadas, faltas en el mantenimiento preventivo (frecuencia o realización), vandalismos,
hurtos o malas manipulaciones, serán de responsabilidad del Concesionario de Operación.

11.5 Reemplazo de partes

11.5.1 Partes originales

Para todo lo aplicable, todas las partes utilizadas en la reparación o mantenimiento deben ser
partes originales OEM (Original Equipment Manufacturer) o equivalentes y avaladas.

Reparaciones mayores

Las operaciones mayores se definen como restauraciones o renovaciones significativas como el

reemplazo masivo de componentes.

Extracción y reutilización de partes

Extracción y reutilización de partes de vehículos dados de baja o de equipos que no se

encuentran activos.

Las partes o equipos extraídos harán parte del inventario de equipos disponibles usados y
deberán ser revisadas siguiendo los procedimientos establecidos por el fabricante (OEM).

11.6 Modificaciones
Las alteraciones o modificaciones del equipamiento requieren realizar una solicitud al Ente
Gestor, la cual debe incluir el concepto técnico, jurídico y financiero, para obtener la aprobación
o negativa escrita por parte del Concesionario de Provisión y del Ente Gestor.

Análisis técnico
Los análisis de los fluidos del vehículo, resultados del estado y pruebas de los sensores, análisis
de fallas y otros análisis técnicos serán utilizados de manera acorde con las prácticas estándar
de la industria.

Reparación de daños
Los daños causados por accidentes o el uso inadecuado deben ser reparados solamente cuando
sea rentable realizarlo, lo cual quiere decir, que debe realizarse sólo si el costo de reparar el
daño no supera el valor del elemento que será reparado ya sea con base en su costo de
adquisición como nuevo y/o el valor actual del elemento (luego de uso y depreciación). El área
directiva del Concesionario de Operación deberá analizar y aprobar las reparaciones o dadas
de baja del equipamiento de los vehículos, para los equipos SIRCI, se debe seguir el

119
“Procedimiento de atención de incidentes en equipos SIRCI a bordo de los buses del SITP por
causas ajenas” al concesionario del SIRCI.

11.7 Mantenimientos programados

Se deben cumplir a cabalidad las inspecciones y servicios de mantenimiento en pro de la
seguridad y la confiabilidad de la flota de vehículos, la integridad de la operación y el
cumplimiento del presupuesto de mantenimiento.

Con el propósito de extender la vida en servicio de los equipos, mejorar la disponibilidad y

confiabilidad, reducir la necesidad de reparaciones mayores y gastos de reemplazo, se deben
incluir los siguientes componentes de los servicios de mantenimiento preventivo (se presentan
de forma indicativa):

• La inspección y reparación realizada en los intervalos de tiempo predeterminados

• Servicios de limpieza, lubricación, calibración y mantenimiento realizado en los
intervalos de tiempo predeterminados.
• El Ente Gestor y el área directiva del Concesionario de Operación deben garantizar su
compromiso con el cumplimiento de estos procedimientos.
• Los supervisores de los talleres, los ingenieros y mecánicos deben cumplir los estándares,
procedimientos y frecuencia de los mantenimientos preventivos.
• Los mantenimientos preventivos deberán realizarse en los horarios en que los vehículos
no se encuentran en servicio.
• Las tareas realizadas, la duración y el alcance de los mantenimientos preventivos deberán
adaptarse a los tiempos en que los vehículos no se encuentran en servicio habitualmente.
• La programación de los vehículos debe asegurar que se puedan realizar las tareas de
mantenimiento preventivo, de manera tal que estos tengan tiempo fuera de servicio para
permitir realizar su inspección y servicio de mantenimiento preventivo.
• Los intervalos y procedimientos de los mantenimientos preventivos deberán basarse en
las recomendaciones de los fabricantes de equipo (OEM) y en las prácticas estándar de la
industria.
• Se debe establecer un cronograma predeterminado de servicio e inspecciones para todas
las clases de vehículos y equipamiento disponibles.
• Cada inspección de mantenimiento preventivo consistirá en el servicio simultáneo de
limpieza, lubricación, inspección de medidores, sensores e indicadores, ajustes,
calibraciones y reparaciones menores.
• Las reparaciones mayores que deban realizarse y que sean descubiertos durante los
mantenimientos preventivos serán documentadas y programadas con el taller encargado
para su realización.
• La identificación de las necesidades de reparación o servicio que afecten la operación
segura y confiable de un vehículo requerirá que este sea puesto en estado de fuera de
servicio hasta que el problema sea corregido.

120
• Se deben establecer diferentes niveles para las inspecciones de mantenimiento
preventivo. Ejemplo: Nivel 1, Nivel 2, Nivel 3. De los cuáles el primer nivel comprenderá
las actividades de inspección más básicas y generales y los posteriores incluirán más
tareas, las cuáles además comprenderán más aspectos a profundidad. En todo caso, las
actividades de mantenimiento de todos los elementos de ITS deben estar incorporados
en el plan de mantenimiento que estructure el Concesionario de Operación en
articulación con el concesionario de provision y sus fabricantes.
• Los niveles de mantenimiento deberán diseñarse en una matriz, la cual contendrá en sus
filas todas las tareas de mantenimiento y en las columnas los diferentes niveles. La
selección de las celdas correspondientes a varias tareas de mantenimiento bajo un mismo
nivel de inspección de mantenimiento preventivo indicará que esas son las tareas que
deben realizarse para ese nivel de inspección.
• La programación de los mantenimientos preventivos debe estar relacionada con el nivel
de la inspección de mantenimiento preventivo que deberá ser realizado.
• Los momentos en que se deben realizar las inspecciones estarán basados en intervalos
de tiempo (horas, días, meses), distancia recorrida (kilómetros), datos generados,
almacenados o transmitidos (bytes, bytes por segundo) u otros indicadores que puedan
ser medibles y ajustados para las necesidades específicas de los diferentes tipos de
equipo en los vehículos.
• La frecuencia de cada uno de los niveles de mantenimiento preventivo (y su
modificación) será fijada en una tabla que deberá ser aprobada por la dirección del
Concesionario de Operación y El Ente Gestor.
• Cada una de las tareas de inspección y mantenimiento preventivo (correspondientes a un
nivel de inspección) deberán ser realizadas con base en un manual, que contendrá una
lista de chequeo y los procedimientos relacionados.
• Para iniciar una inspección (luego de haber sido programada) se debe tener una orden
de inspección en la cual se incluirán datos de identificación del vehículo, datos de
identificación de los equipos, las partes, costos, materiales utilizados, técnicos e
ingenieros encargados y las respectivas horas de labor utilizadas para realizar las tareas
correspondientes.
• Las órdenes de inspección y de servicio deberán ser archivadas en las hojas de vida cada
uno de los vehículos y estás deberá encontrarse también en medios digitales a través de
un sistema de información documental con respaldo provisto por el Concesionario de
Operación para evitar su pérdida, la cual deberá reportarse mensualmente al Ente Gestor
• Solamente el personal de mantenimiento autorizado y debidamente entrenado podrá
realizar las inspecciones de mantenimiento preventivo.
• Todo el equipamiento nuevo o repuestos deberá pasar por un proceso de inspección
previo a la entrega y aceptación, antes de ser instalado y/o puesto en servicio. Dicha
inspección deberá ser documentada en un reporte que El Ente Gestor.
• Especifique, el cual debe ser archivado y mantenido también en formato digital a través
de un sistema de información documental con respaldo.
• Cada grupo de equipos o equipamiento deberá tener una hoja de chequeo diseñada para
cumplir con el servicio de mantenimiento y las rutinas de inspección correspondientes.

121
 • El ingeniero, técnico o mecánico que deba realizar las diferentes tareas de limpieza,
lubricación, inspección de medidores, sensores e indicadores, ajustes, calibraciones y
reparaciones menores, registrará cada actividad realizada con sus respectivos
indicadores y resultados una vez se hayan completado.
• La programación de las inspecciones de mantenimiento preventivo será responsabilidad
del director del área de mantenimiento y esta deberá llevarse de manera sistematizada a
través de un sistema de información que facilite su asignación, registro de información y
control.
• El ingeniero, técnico o mecánico que haya realizado las tareas de limpieza, lubricación,
inspección de medidores, sensores e indicadores, ajustes, calibraciones y reparaciones
menores, una vez concluido el proceso de inspección de mantenimiento preventivo,
realizará las pruebas prácticas correspondientes para verificar que los ajustes realizados
estén funcionando de manera adecuada y registrará los resultados en la orden de
inspección.
• Las órdenes de inspección terminadas serán revisadas por el supervisor del taller de
mantenimiento y posteriormente en un informe, por parte del director del
mantenimiento del Concesionario de Operación y serán revisadas por El Ente Gestor.
• En cumplimiento de la normativa respectiva, los vehículos también deberán cumplir con
los niveles de emisiones permitidos y los que no los cumplan deberán ser reparados o
sacados del servicio de manera definitiva como lo estipula la normativa y el contrato del
Concesionario de Operación.

Adicional a los anteriores lineamientos, el Concesionario de Operación deberá acatar y dar

cumplimiento a las recomendaciones y requerimientos planteados por El Ente Gestor. con
relación a los mantenimientos preventivos y por parte se la interventoría designada por El Ente
Gestor a los contratos de concesión.

11.8 Mantenimientos preventivos

11.8.1 Frecuencias de los mantenimientos preventivos del STS.

En la siguiente tabla se establecen las frecuencias de los mantenimientos que deben realizarse
a los siguientes equipos o componentes:

122
 Id Equipo / componente Frecuencia de mantenimiento
Mensual con procedimiento completo
1 Circuito cerrado de televisión CCTV 1 inspección visual al día
1 limpieza exterior al día a las cámaras
Mensual con procedimiento completo
2 Cámara del conductor 1 inspección visual al día
1 limpieza exterior al día la cámara
Sensores del motor y de conducción del
3 La que indique el fabricante
vehículo
4 Sensores de la cabina del vehículo La que indique el fabricante
Sensores de la apertura y cierre de
5 La que indique el fabricante
puertas
6 Sensor de conteo de pasajeros La que indique el fabricante
Trimestral 4 con procedimiento
7 Botón de pánico
completo
8 STS La que indique el fabricante
9 STDI La que indique el fabricante
10 Dispositivo central Mensual con procedimiento completo
Mensual con procedimiento completo
Una inspección visual al día
11 Cámara frontal y cámara trasera
Una limpieza exterior al día a las
cámaras

11.8.2. Niveles de falla y tiempo de solución

Calidad de los equipos del Sistema Tecnológico de Seguridad

Los elementos del Sistema Tecnológico de Seguridad (STS) pueden presentar máximo dos (2)
fallas por elemento en alguno de sus componentes de Hardware. Máximo el dos por ciento (2%)
del total de los elementos del STS instalados en el vehículo pueden fallar. Si un elemento del
STS presenta en más de dos (2) ocasiones en un periodo de treinta (30) días calendario, una
misma falla en el Hardware, el elemento debe ser cambiado por uno de características iguales
o superiores. La periodicidad de mantenimiento señalada en este numeral no es vinculante ni
oponible de cara a las obligaciones del SIRCI,. Se debe garantizar que los mantenimientos de los
equipos STS no interfieran con los programados por el concesionario del SIRCI para los equipos
SIRCI, y que durante los mismos se observen procedimientos orientados a garantizar la
inalterabilidad e invulnerabilidad de los equipos SIRCI o de las instalaciones eléctricas que los
alimentan. Para la atención de incidentes SIRCI se debe seguir el procedimiento establecido por
dicho concesionario para la atención de incidentes.

123
11.9 Canales de atención
11.9.1 Canales

El Concesionario de Operación debe tener a disposición los siguientes canales para atención de
fallas e incidentes de los elementos del Sistema Tecnológico de Seguridad (STS):

• Línea telefónica nacional

• Chat o interfaz web
• Correo electrónico
• Mesa de ayuda

Nota: Si bien existen varios canales, estos deben estar articulados entre sí, generando un único
indicador de incidente; independientemente del canal en donde este sea reportado.

11.10 Tiempos de respuesta y de solución

Como se mencionó anteriormente, el Sistema Tecnológico de Seguridad (STS) debe almacenar
información de algunos de sus componentes en el vehículo. Para garantizar la calidad y
continuidad de este sistema, se deben tener en cuenta las siguientes características:

11.10.1 Tiempo de recuperación objetivo

Es el tiempo máximo que se debe tardar en recuperar la información, recursos o sistemas
interrumpidos, a partir del momento en que se ha reportado una falla.

11.10.2 Punto de recuperación objetivo

Es el tiempo máximo permitido durante el cual se ha perdido información.

11.10.3 Tiempo de respuesta

Es el tiempo máximo permitido sobre el cual el Concesionario de Operación debe responder y
confirmar su conocimiento sobre una falla en el STS, en los dispositivos ITS No SIRCI o en los
dispositivos SIRCI con falla ajena a Recaudo Bogota

11.10.4 Tiempo de Solución

Es el tiempo máximo permitido sobre el cual el Concesionario de Operación debe solucionar la
falla reportada en el STS, en los dispositivos ITS No SIRCI o en los dispositivos SIRCI con falla
ajena a Recaudo Bogota.

11.10.5 Escala de fallas

La escala de fallas hace referencia al impacto de la falla sobre la operación normal del vehículo;
a continuación se describen las cuatro (4) categorías que pertenecen a esta escala:

• Emergencia: Se entiende por emergencia cuando se impacta la operación normal del

vehículo por fallos en el Sistema Tecnológico de Seguridad (STS) o alguno de sus
componentes. El servicio no se presta de manera permanente o la mayor parte del
tiempo, bien sea por afectaciones en el funcionamiento del vehículo o porque no se
cumplen las condiciones mínimas para transitar.
• Alto: Cuando el STS o alguno de sus componentes se encuentra degradado al punto que
afecta de alguna manera la operación normal del vehículo y el servicio se presta de

124
 forma intermitente, bien sea por afectaciones en el funcionamiento del vehículo o
porque no se cumplen las condiciones mínimas para transitar.
• Medio: Cuando algunos componentes del STS no operan de forma intermitente o
permanente y afecta su funcionamiento de manera importante, pero el vehículo puede
prestar el servicio con normalidad.
• Bajo: Cuando un componente del STS no opera de forma intermitente o permanente y
afecta su funcionamiento de manera importante, pero el vehículo puede prestar el
servicio con normalidad

A continuación, se detallan los tiempos de respuesta y de solución para cada uno de los
componentes del Sistema Tecnológico de Seguridad:

11.10.6 Circuito cerrado de televisión CCTV

En la siguiente tabla se presentan los tiempos de respuesta y de resolución del circuito cerrado
de televisión, aclarando que Los tiempos de respuesta y solución se contabilizan a partir de la
apertura del ticket.

Tiempos de respuesta del circuito cerrado de televisión CCTV.

Tiempo de respuesta Tiempo de

Nivel de falla Nivel de Escalamiento
(minutos) Solución (horas)

Emergencia 5 4 Proveedor de la solución

CCTV

Alto 5 6 Experto administrador del

sistema CCTV

Medio 15 24 Mesa de ayuda - Experto

administrador del sistema CCTV

Bajo 15 48 Mesa de ayuda

11.10.7 Cámara del conductor

En la siguiente tabla se presentan los tiempos de respuesta y de resolución de la cámara del
conductor

Tiempos de respuesta de la cámara del conductor.

Tiempo de respuesta Tiempo de

Nivel de falla Nivel de Escalamiento
(minutos) Solución (horas)

Emergencia 5 4 Proveedor de la solución de la

cámara del conductor

Alto 5 6 Experto administrador de la

cámara del conductor

125
 Tiempo de respuesta Tiempo de
Nivel de falla Nivel de Escalamiento
(minutos) Solución (horas)

Medio 15 24 Mesa de ayuda - Experto

administrador de la cámara del
conductor

Bajo 15 48 Mesa de ayuda

11.10.8 Sensores del motor y de conducción

En la siguiente tabla se presentan los tiempos de respuesta y de resolución de los sensores del
motor y de conducción.

Tiempos de respuesta de los sensores del motor y de conducción

Tiempo de respuesta Tiempo de

Nivel de falla Nivel de Escalamiento
(minutos) Solución (horas)

Emergencia 5 4 Proveedor de los sensores del

motor y de conducción

Alto 5 6 Experto administrador de los

sensores del motor y de
conducción

Medio 15 24 Mesa de ayuda - Experto

administrador de los sensores del
motor y de conducción

Bajo 15 48 Mesa de ayuda

11.10.9 Sensores de la cabina del vehículo

En la siguiente tabla se presentan los tiempos de respuesta y de resolución de los sensores de
la cabina

Tiempos de respuesta de los sensores de la cabina.

Tiempo de respuesta Tiempo de

Nivel de falla Nivel de Escalamiento
(minutos) Solución (horas)

Emergencia 5 4 Proveedor de los sensores de

la cabina

Alto 5 6 Experto administrador de los

sensores de la cabina

Medio 15 24 Mesa de ayuda - Experto

administrador de los sensores
de la cabina

Bajo 15 48 Mesa de ayuda

126
11.10.10 Sensores de la apertura y cierre de puertas
En la siguiente tabla se presentan los tiempos de respuesta y de resolución de los sensores de
apertura y cierre de puertas

Tiempos de respuesta de los sensores de apertura y cierre de puertas.

Tiempo de respuesta Tiempo de

Nivel de falla Nivel de Escalamiento
(minutos) Solución (horas)

Emergencia 5 4 Proveedor de los sensores de

apertura y cierres de puertas

Alto 5 6 Experto administrador de los

sensores de apertura y cierre de
puertas

Medio 15 24 Mesa de ayuda - Experto administrador

de apertura y cierre de puertas

Bajo 15 48 Mesa de ayuda

11.10.11 Sensores de conteo de pasajeros

En la siguiente tabla se presentan los tiempos de respuesta y de resolución de los sensores de
conteo de pasajeros

Tiempos de respuesta de los sensores de conteo de pasajeros.

Tiempo de respuesta Tiempo de

Nivel de falla Nivel de Escalamiento
(minutos) Solución (horas)

Emergencia 5 4 Proveedor de los sensores de

conteo de pasajeros

Alto 5 6 Experto administrador de conteo de

pasajeros

Medio 15 24 Mesa de ayuda - Experto

administrador de los sensores de
conteo de pasajeros

Bajo 15 48 Mesa de ayuda

11.10.12 Sistema STDI

En la siguiente tabla se presentan los tiempos de respuesta y de resolución de los sistemas STDI

Tiempos de respuesta de los sistemas STDI.

127
 Tiempo de respuesta Tiempo de
Nivel de falla Nivel de Escalamiento
(minutos) Solución (horas)

Emergencia 5 4 Proveedor del STDI

Alto 5 6 Experto administrador del STDI

Medio 15 24 Mesa de ayuda - Experto

administrador del STDI

Bajo 15 48 Mesa de ayuda

11.10.13 Botón de pánico

En la siguiente tabla se presentan los tiempos de respuesta y de resolución del botón de pánico

Tiempos de respuesta del botón de pánico.

Tiempo de respuesta Tiempo de

Nivel de falla Nivel de Escalamiento
(minutos) Solución (horas)

Emergencia 5 4 Proveedor de los sensores de la

cabina

Alto 5 6 Experto administrador de los

sensores de la cabina

Medio 15 24 Mesa de ayuda - Experto

administrador de los sensores de la
cabina

Bajo 15 48 Mesa de ayuda

11.10.14 Cámara frontal y cámara trasera

En la siguiente tabla se presentan los tiempos de respuesta y de resolución de la cámara frontal
y cámara trasera

Tiempos de respuesta de la cámara frontal y cámara trasera.

Tiempo de respuesta Tiempo de

Nivel de falla Nivel de Escalamiento
(minutos) Solución (horas)

Emergencia 5 4 Proveedor de las cámaras

Alto 5 6 Experto administrador de las

cámaras

Medio 15 24 Mesa de ayuda - Experto

administrador de las cámaras

Bajo 15 48 Mesa de ayuda

128
11.10.15 Dispositivo central
En la siguiente tabla se presentan los tiempos de respuesta y de resolución del dispositivo
central

Tiempo de respuesta Tiempo de

Nivel de falla Nivel de Escalamiento
(minutos) Solución (horas)

Emergencia 5 4 Proveedor del dispositivo

Alto 5 6 Experto en dispositivos similares

Medio 15 24 Mesa de ayuda - Experto

administrador del dispositivo

Bajo 15 48 Mesa de ayuda

11.11 Indicadores de niveles de servicio STS y STDI

Dentro de los acuerdos de niveles de servicio es necesario especificar los indicadores que
medirán los parámetros de calidad y de servicio del STS. Para ello, el Concesionario de
Operación debe tener los mecanismos necesarios para capturar los datos requeridos para
generar los indicadores y debe calcularlos. Sin embargo, El Ente Gestor puede solicitar la
verificación del cálculo de cada uno de los indicadores.

Nota: se requiere tener en cuenta los ANS definidos en este documento y los del proceso global
de esta licitación.

Para los dispositivos SIRCI, serán los tiempos definidos en el contrato de concesión 001 de
2011. A continuación, se describe cada uno de los indicadores para los elementos del STS:

11.11.1 Circuito cerrado de televisión CCTV

En la siguiente tabla se presentan los indicadores de niveles de servicio para el circuito cerrado
de televisión CCTV

Indicador Medida Rangos de Periodo de

aceptación medición

Cumplimiento en la I = 100% x horas de >=99% Diario

función de grabación grabación/horas de
durante el periodo de operación
operación

Cumplimiento de tiempos I = 100% x ∑ Tiempos >90% Mensual

de respuesta a peticiones de respuesta / ∑
de servicios de soporte y tiempos esperados
consulta especificados

I = 100% x solicitudes >=99% Semanal

de envío de

129
 Indicador Medida Rangos de Periodo de
aceptación medición

Disponibilidad video/solicitudes
efectivas de envío de
video

Mantenimiento I = 100% x >=99% Mensual

preventivo Mantenimientos
realizados /
mantenimientos
programados

Cumplimiento de los I = 100% x solicitudes >80% Diario

tiempos de transmisión de envío de
de imágenes y video video/solicitudes
efectivas de tiempos
de envío

11.11.2 Cámara del conductor

En la siguiente tabla se presentan los indicadores de niveles de servicio para la cámara del
conductor.

Indicador Medida Rangos de Periodo de

aceptación medición

Cumplimiento de tiempos Promedio del tiempo >=90% Mensual

de respuesta a peticiones de respuesta/tiempo
de servicios de soporte y esperado
consulta

Disponibilidad Horas de >=99% Semanal

funcionamiento/hora
s de periodo de
operación

Mantenimiento Mantenimientos 100% Mensual

preventivo realizados/mantenimi
entos programados

Cumplimiento de los Promedio del tiempo >80% Diario

tiempos de transmisión enviado / tiempo
de imágenes y video definido

11.11.3 Sensores del motor y de conducción

En la siguiente tabla se presentan los indicadores de niveles de servicio para los sensores del
motor y de conducción Indicador.

130
 Indicador Medida Rangos de Periodo de
aceptación medición

Cumplimiento en la Número de datos >=90% Diario

función de la captura de capturados/ número
los datos consulta de datos esperados

Cumplimiento de los Promedio del tiempo >=90% Mensual

tiempos de respuesta a de respuesta/tiempo
peticiones de servicios de esperado
soporte y consulta

Disponibilidad Horas de >=99% Semanal

funcionamiento/hora
s de periodo de
operación

Mantenimiento Mantenimientos 100% Mensual

preventivo realizados/mantenimi
entos programados

Cumplimiento de los Promedio del tiempo >80% Diario

tiempos de transmisión enviado / tiempo
de imágenes y video definido

11.11.4 Sensores de la cabina del vehículo

En la siguiente tabla se presentan los indicadores de niveles de servicio para los sensores de la
cabina.

Indicador Medida Rangos de Periodo de

aceptación medición

Cumplimiento en la Número de datos >=90% Diario

función de la captura de capturados/ número
los datos consulta de datos esperados

Cumplimiento de los Promedio del tiempo >=90% Mensual

tiempos de respuesta a de respuesta/tiempo
peticiones de servicios de esperado
soporte y consulta

Disponibilidad Horas de >=99% Semanal

funcionamiento/hora
s de periodo de
operación

131
 Indicador Medida Rangos de Periodo de
aceptación medición

Mantenimiento Mantenimientos 100% Mensual

preventivo realizados/mantenimi
entos programados

Cumplimiento de los Promedio del tiempo >80% Diario

tiempos de transmisión enviado / tiempo
de los datos definido

11.11.5 Sensores de la apertura y cierre de puertas

En la siguiente tabla se presentan los indicadores de niveles de servicio para los sensores de la
apertura y cierre de puertas

Indicador Medida Rangos de Periodo de

aceptación medición

Cumplimiento en la Número de datos >=90% Diario

función de la captura de capturados/ número
los datos consulta de datos esperados

Cumplimiento de los Promedio del tiempo >=90% Mensual

tiempos de respuesta a de respuesta/tiempo
peticiones de servicios de esperado
soporte y consulta

Disponibilidad Horas de >=99% Semanal

funcionamiento/hora
s de periodo de
operación

Mantenimiento Mantenimientos 100% Mensual

preventivo realizados/mantenimi
entos programados

Cumplimiento de los Promedio del tiempo >80% Diario

tiempos de transmisión enviado / tiempo
de los datos definido

11.11.6 Sensores de conteo de pasajeros

En la siguiente tabla se presentan los indicadores de niveles de servicio para los sensores de
conteo de pasajeros

132
 Indicador Medida Rangos de Periodo de
aceptación medición

Cumplimiento en la Número de datos >=90% Diario

función de la captura de capturados/ número
los datos consulta de datos esperados

Cumplimiento de los Promedio del tiempo >=90% Mensual

tiempos de respuesta a de respuesta/tiempo
peticiones de servicios de esperado
soporte y consulta

Disponibilidad Horas de >=99% Semanal

funcionamiento/hora
s de periodo de
operación

Mantenimiento Mantenimientos 100% Mensual

preventivo realizados/mantenimi
entos programados

Cumplimiento de los Promedio del tiempo >80% Diario

tiempos de transmisión enviado / tiempo
de los datos definido

11.11.7 Sistema STDI

En la siguiente tabla se presentan los indicadores de niveles de servicio para los sistemas STDI.

Indicador Medida Rangos de Periodo de

aceptación medición

Cumplimiento en la Número de datos >=90% Diario

función de la captura de capturados/ número
los datos consulta de datos esperados

Cumplimiento de los Promedio del tiempo >=90% Mensual

tiempos de respuesta a de respuesta/tiempo
peticiones de servicios de esperado
soporte y consulta

Disponibilidad Horas de >=99% Semanal

funcionamiento/hora
s de periodo de
operación

133
 Indicador Medida Rangos de Periodo de
aceptación medición

Mantenimiento Mantenimientos 100% Mensual

preventivo realizados/mantenimi
entos programados

Cumplimiento de los Promedio del tiempo >80% Diario

tiempos de transmisión enviado / tiempo
de los datos definido

11.11.8 Botón de pánico

En la siguiente tabla se presentan los indicadores de niveles de servicio para el botón de pánico.

Indicador Medida Rangos de Periodo de

aceptación medición

Cumplimiento de tiempos Promedio del tiempo >=90% Mensual

de respuesta a peticiones de respuesta/tiempo
de servicios de soporte y esperado
consulta

Disponibilidad Horas de 100% Semanal

funcionamiento/hora
s de periodo de
operación

Mantenimiento Mantenimientos 100% Mensual

preventivo realizados/mantenimi
entos programados

Generación exitosa de Número de envíos 100% Mensual

alarmas exitosos / número de
intentos

11.11.9 Cámara frontal y cámara trasera

En la siguiente tabla se presentan los indicadores de niveles de servicio para la cámara frontal
y trasera

Indicador Medida Rangos de Periodo de

aceptación medición

Cumplimiento en la I = 100% x horas de >=99% Diario

función de grabación grabación/horas de
operación

134
 Indicador Medida Rangos de Periodo de
aceptación medición

durante el periodo de
operación

Cumplimiento de los I = 100% x ∑ Tiempos >=90% Mensual

tiempos de respuesta a de respuesta / ∑
peticiones de servicios de tiempos esperados
soporte y consulta especificados

Disponibilidad I = 100% x solicitudes >=99% Semanal

de envío de
video/solicitudes
efectivas de envío de
video

Calidad de las imágenes y Porcentaje de la >=99% Mensual

video registrado calidad de las imágenes
y video registrado

Calidad de las imágenes y Porcentaje de la >=90% Diario

video transmitido calidad de las imágenes
y video transmitido

Cumplimiento de los I = 100% x solicitudes >80% Diario

tiempos de transmisión de envío de
de imágenes y video video/solicitudes
efectivas de tiempos
de envío

11.11.10 Dispositivo central

En la siguiente tabla se presentan los indicadores de niveles de servicio para el dispositivo
central

Indicador Medida Rangos de Periodo de

aceptación medición

Cumplimiento en la Número de datos >=90% Diario

función del capturados /número
almacenamiento de los de datos esperados
datos

Cumplimiento de los Promedio del tiempo >=90% Mensual

tiempos de respuesta a de respuesta/tiempo
peticiones de servicios de esperado
soporte y consulta

135
 Indicador Medida Rangos de Periodo de
aceptación medición

Disponibilidad Mantenimientos >=99% Semanal

realizados/mantenimi
entos programados

Mantenimiento Porcentaje de la 100% Mensual

preventivo calidad de las imágenes
y video registrado

Cumplimiento de los Promedio del tiempo >80% Diario

tiempos de transmisión enviado / tiempo
de imágenes, video y definido
datos

11.12 Gestión de incidentes del servicio

El Concesionario de Operación debe contar con dos (2) sistemas para la gestión de incidentes
en el STS:

• Sistema de grabación de llamadas

• Sistema de seguimiento de las solicitudes o incidentes del sistema (mesa de ayuda).

El sistema de grabación de llamadas debe grabar al menos el noventa por ciento (90%) de cada
llamada.

El Concesionario de Operación debe entregar mensualmente a TRANSMILENIO S.A. reportes de

toda la gestión de fallas e incidentes de todos los elementos del Sistema Tecnológico de
Seguridad. Los reportes deben tener mínimo:

• Fecha y hora del reporte del incidente

• Tiempo de atención a las solicitudes por todos los canales
• Relación de todos los incidentes
• Solución a cada incidente
• Lugar de atención de cada incidente
• Acción realizada para la solución
• El/los reporte(s) con formatos y medios que El Ente Gestor defina

11.13 Entrega de los equipos

Sin prejuicio de lo anterior y antes de que el vehículo sea vinculado al servicio según el
cronograma de implementación, el Concesionario de provisión se encarga de la adquisición e
instalación de todos los equipos a bordo que hacen parte del STS de los vehículos,. Los cuales
deberá entregar previo a la vinculación de la flota. De esta forma, se sugiere que los equipos STS
sean instalados al momento del ensamblaje del vehículo. Además, el Concesionario de provisión
debe entregar al Ente Gestor el certificado de funcionamiento de los equipos del STS y STDI y

136
su respectivo Manual de Operación y Mantenimiento, y debe también entregar al concesionario
de operación estos equipos operativos y funcionando con normalidad.

Los equipos deben ser entregados funcionando y debe incluir una tabla de inventario detallado
en cada vehículo que debe ser entregada al Ente Gestor o a quien este designe.

137
Glosario y Abreviaturas

AES Advanced Encryption Standard. Conocido como Rijndael (pronunciado "Rain Doll" en
inglés), es un esquema de cifrado por bloques adoptado como un estándar de cifrado por el
gobierno de los Estados Unidos. Es definido en un algoritmo de cifra basado en una clave
compartida. Utiliza claves de 128, 192 o 256 bits.

ANS Acuerdo de Nivel de Servicio

CA Autoridad Certificadora

Cadena de custodia: proceso que permite asegurar las características originales de los
elementos materia de prueba o evidencias físicas desde su recolección hasta su disposición
final. Aplica a todos los elementos físicos materia de prueba, para garantizar la autenticidad de
los mismos, acreditando su identidad y estado original, las condiciones de recolección,
preservación, embalaje y las personas que intervienen en la recolección, envió, manejo, análisis
y conservación de estos elementos, así mismo, los cambios hechos en ellos por cada custodio.
La cadena de custodia se inicia en el lugar donde se obtiene, encuentre o recaude el elemento
físico de prueba y finaliza por orden de la autoridad competente.

CANBUS Controller Area Network Bus. Es un protocolo de comunicaciones desarrollado por la

firma alemana Robert Bosch GmbH, basado en una topología bus para la transmisión de
mensajes en entornos distribuidos. Además, ofrece una solución a la gestión de la comunicación
entre múltiples CPUs. Aplicado en la industria automotriz, entre otros.

CCTV Closed Circuit TeleVision) es una tecnología de videovigilancia diseñada para

supervisar una diversidad de ambientes y actividades.

CE Conformité Européenne o de Conformidad Europea. Es una marca europea para ciertos

grupos o productos industriales. Se apoya en la Directiva 93/68/CEE. Establecida por la
Comunidad Europea y es la cetificación por parte del fabricante de que su producto cumple con
los mínimos requisitos legales y técnicos definidos en materia de seguridad de los Estados
miembros de la Unión Europea

CEN TS13149 European Committee for Standardization. Technical Specification. Estándar de

la Comunidad Europea que define los linimentos de los sistemas de control y programación de
viajes de vehículos de carraetera

CEPE/ONU La Comisión Económica de las Naciones Unidas para Europa. Se estableció en

1947 para promocionar la cooperación económica entre sus Estados Miembros. Es una de las
cinco comisiones regionales bajo la dirección administrativa de las sedes de las Naciones
Unidas. Tiene 56 Estados Miembros, e informa al Consejo Económico y Social de las Naciones
Unidas (ECOSOC). Además de los países europeos, incluye a EE. UU., Canadá, Israel, Turquía y
las repúblicas de Asia central.

CSIG Convención de Naciones Unidas sobre los Contratos de Compraventa Internacional de

mercaderías (CISG, por sus siglas en inglés) es un tratado constituido en derecho internacional
uniforme para operaciones de compraventa1

138
DCE DCE Data Communications Equipment se refiere a equipos que son puente
comunicación, en esquemas de transmision serial. Corresponde a modems, interfaces
comunicación bridge, entre otros

DHCP Dynamic Host Configuration Protocol, también conocido por sus siglas de DHCP) es un
protocolo de red de tipo cliente/servidor mediante el cual un servidor DHCP asigna
dinámicamente una dirección IP a diferentes hosts (clientes) en una conectividad de red datos

DNS Domain Name System. Es un sistema de nomenclatura jerárquico descentralizado para

dispositivos conectados a redes IP como Internet o una red privada., asociando una información
variada con nombre de dominio asignado a cada uno host que solicitan el servicio.

DTE Data Terminal Equipment. Es un equipo final de comunicación, que corresponde a un

principio y fin de la transmisión. El equipo convierte la información del usuario en señales o
reconvierte las señales recibidas. Estos también pueden ser llamados circuitos de cola

DTN Delay-Tolerant Networking. Consiste en una arquitectura de red de computadoras, la

cual pretende superar los problemas técnicos de las redes heterogéneas que les puede hacer
falta la conectividad continua a la red

ECU Engine Control Unit. Es un dispositivo de control electrónico aplicado en la industria

automotriz que administra varios aspectos de la operación de combustión interna del motor y
aspectos funcionales de un vehiculo. Generalmente se conectan entre sí mediante bus de campo
CANBUS.

EMC Electromagnetic Compatibility. Rama de la tecnología electrónica y de

telecomunicaciones que estudia los mecanismos para eliminar, disminuir y prevenir los efectos
de acoplamiento entre un equipo eléctrico o electrónico y su entorno electromagnético, aún
desde su diseño, basándose en normas y regulaciones asegurando la confiabilidad y seguridad
de todos los tipos de sistemas en el lugar donde sean instalados y bajo un ambiente
electromagnético específico

EN50155 II Estándar que define los requisitos de inmunidad eléctrica y física, definido en
componentes y conectores, aplicado en sistemas de alarma. diseñados para su uso dentro y
alrededor de edificios en entornos residenciales, comerciales, industriales ligeros e
industriales, así como en los sistemas de control de acceso, para aplicaciones de seguridad.

EN50155 T3 Es una norma internacional que define el tipo de chasis y blindaje fisco de los
equipos electrónicos utilizados en la industria automotriz en especial para aplicaciones
ferroviarias. La norma cubre aspectos de este equipo electrónico, incluidos la temperatura, la
humedad, golpes, vibraciones y otros parámetros

FAKRA Fachkreis Automobil. Son conectore defindo en unestandar aleman de grado de la

industria automotriz que pueden operar hasta 6 GHz. Estos conectores están integrados dentro
de una carcasa de plástico con una función de bloqueo.

FCC Federal Communications Commission. Es una agencia estatal independiente de Estados

Unidos, bajo responsabilidad directa del Congreso.

139
FCC Class A La Declaración de conformidad de la FCC o la etiqueta de la FCC o la marca de la
FCC es una marca de certificación utilizada en productos electrónicos fabricados o vendidos en
los Estados Unidos que certifica que la interferencia electromagnética del dispositivo se
encuentra dentro de los límites aprobados por FCC. Así la emisión de clase A de la FCC son
aquellos que se comercializan exclusivamente para uso en entornos comerciales, industriales y
comerciales, no aplicable a entornos residenciales o de hogar.

FOV Field of View. En el caso de instrumentos ópticos o cámaras de visón se refiere al ángulo
abarcable a través del cual un sensor puede detectar la radiación electromagnética que se desee
capturar.

FPS Frames per Second. Es la frecuencia a la que aparecen imágenes consecutivas llamadas
fotogramas en una pantalla. El término se aplica por igual a cámaras de video y video, gráficos
de computadora y sistemas de captura de movimiento. La frecuencia de cuadros también se
puede llamar frecuencia de cuadros y se expresa en Hercios.

FTP File Transfer Protocol. Es un protocolo de red para la transferencia de archivos entre
sistemas conectados a una red TCP (Transmission Control Protocol), basado en la arquitectura
cliente-servidor.

GET Es un método en conexión de cliente servidor en transferencia HTTP, el cual solicita una
representación de un recurso específico. Las peticiones que usan el método GET sólo deben
solicitar datos.

GND Ground. Señal de una conexión eléctrica a tierra

GPS Global Positioning System. Es un sistema de geolocalización que permite determinar en

toda la Tierra la posición de cualquier objeto (una persona, un vehículo) con una precisión de
hasta centímetros (si se utiliza GPS diferencial), aunque lo habitual son unos pocos metros de
precisión. El sistema fue desarrollado, instalado y empleado por el Departamento de Defensa
de los EE. UU. Para determinar las posiciones en el globo. El sistema GPS se sirve de 3 o más
satélites y utiliza la trilateración. En la práctica, normalmente son necesarios 4 o más satélites
para determinar la posición con cierta precisión.

GRANDES CONSUMOS DE DATOS: Término utilizado en el enfoque del STDI para evitar
Streeming de video al momento en que los usuarios utilizan el servicio de internet que debe ser
ofrecido en el bus.

HDD Hard Disk Drive. Es el dispositivo de almacenamiento de datos que emplea un sistema
de grabación magnética para almacenar archivos digitales

HTTP Hypertext Transfer Protocol. Es el protocolo de comunicación que permite las

transferencias de información en la World Wide Web.

HTTPS Hypertext Transfer Protocol Secure. Es un protocolo de aplicación basado en el

protocolo HTTP, destinado a la transferencia segura de datos de Hipertexto, es decir, es la
versión segura de HTTP. Utiliza un cifrado basado en la seguridad de textos SSL/TLS para crear

140
un canal cifrado (cuyo nivel de cifrado depende del servidor remoto y del navegador utilizado
por el cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP

IEC International Electrotechnical Commission. Es una organización de normalización en

los campos: eléctrico, electrónico y tecnologías relacionadas.

IEEE 802.3 AF Se refiere al estandard del comité 802.3 donde se aprobó la cláusula 33 (12 de
junio de 2003). Esta cláusula se titula Energía del equipo terminal de datos (DTE) a través de la
Interfaz dependiente de los medios (MDI) y define las características del Dispositivo
Alimentado (PD) y el Equipo de Suministro de Energía (PSE), definiéndose llevar alimentación
al dispositivo terminal de datos a través de la acometida de datos.

IGMP Internet Group Management Protocol. El protocolo de enrutamiento red IGMP que
define su funcionalidad en el intercambio de información acerca del estado de pertenencia
entre enrutadores IP que admiten la multidifusión y miembros de grupos de multidifusión

IK Impact Kinectic.Sistema de codificación para indicar el grado de protección que resiste

una luminaria contra impactos mecánicos nocivos. Utilizado generalmente en luminarias de
exterior o industriales debido a que son instalados en zonas de constante exposición a golpes o
vandalismo. Los grados de protección IK estan basdaos en la norma europea, equivalente a la
norma internacional IEC 62262 (2002).

IP Protection Ingress Protection.Definido por el estándar internacional IEC 60529, el cual

clasifica el grado de protección de sólidos (como polvo) y líquidos (como agua) que las
luminarias deben tener según su función.

IPv4/v6 Protocol El protocolo fundamental de la Internet. Porta datagramas de la fuente

al destino. El nivel de transporte parte el flujo de datos en datagramas. Durante su transmisión
se puede partir un datagrama en fragmentos que se montan de nuevo en el destino.

ISO International Organization for Standardization. Es una organización para la creación de

estándares internacionales compuesta por diversas organizaciones nacionales de
estandarización.

ITS Intelligent Transportation Systems. Es un conjunto de soluciones tecnológicas de las

telecomunicaciones y la informática (conocida como telemática) diseñadas para mejorar la
operación y seguridad del transporte terrestre, tanto para carreteras urbanas y rurales, como
para ferrocarriles

JPEG Joint Photographic Experts Group. Comite que define un estándar de compresión y
codificación de archivos e imágenes fijas. Este comité fue integrado desde sus inicios por la
fusión de varias agrupaciones en un intento de compartir y desarrollar su experiencia en la
digitalización de imágenes. La ISO, tres años antes (abril de 1983), había iniciado sus
investigaciones en el área.

LAN Local Area Network. Es un grupo de equipos de cómputo y dispositivos asociados que
comparten una línea de comunicación común o un enlace inalámbrico casi siempre con un
servidor. Normalmente, una LAN abarca computadoras y periféricos conectados a un servidor

141
dentro de un área geográfica distinta, como una oficina o un establecimiento comercial. Las
computadoras y otros dispositivos móviles utilizan una conexión LAN para compartir recursos
como una impresora o un almacenamiento en red.

LED RGB Light-Emitting Diode Red Green Blue. Es un dispositivo emisor de luz
constituida por un material semiconductor dotado de dos terminales. Se trata de un diodo de
unión p-n, que emite luz cuando está activado. Si se aplica una tensión adecuada a los
terminales, los electrones se recombinan con los huecos en la región de la unión p-n del
dispositivo, liberando energía en forma de fotones. Un Led RGB (Red, Green, Blue: Rojo, Verde,
Azul) es un tipo de led que combina estos tres colores para formar más de 16 millones de tonos
de luz. De esta forma, dependiendo de la tonalidad pasada como parámetro, podemos emitir un
color de luz u otro.

LTE Long Term Evolution. Hace referencia a la tecnología de banda ancha inalámbrica que
sirve para la transmisión de datos con la finalidad de dar acceso a Internet a los dispositivos
móviles

MIL-STD-810G Es un estándar que ha definido una serie de pruebas diseñadas por los militares
de EE. UU. para probar los límites de sus equipos en diversas condiciones en las que se espera
que se utilicen (medio ambiente) o se transporten (choques). La prueba varía según la
naturaleza, el tamaño y el peso del equipo probado.

MTBF Mean Time Between Failures. Es la media aritmética o promedio del tiempo entre fallos
de un sistema. El MTBF es típicamente parte de un modelo que asume que el sistema fallido se
repara inmediatamente (el tiempo transcurrido es cero), como parte de un proceso de
renovación

MTD Maximum Tolerable period of Disruption. Dentro de la continuidad de negocios, estará

compuesto por un tiempo de recuperación objetivo (RTO o Recovery Time Objective),
parámetro habitualmente de carácter técnico, más un periodo de normalización de las
actividades en el que el personal responsable de la actividad comienza a funcionar.

NTP Network Time Protocol. Es un protocolo de Internet para sincronizar los relojes de los
sistemas informáticos a través del enrutamiento de paquetes en redes con latencia variable.

NTP Network Time Protocol. Es un protocolo de Internet para sincronizar los relojes de los
sistemas informáticos a través del enrutamiento de paquetes en redes con latencia variable.
Utiliza UDP como su capa de transporte, usando el puerto 123. Está diseñado para resistir los
efectos de la latencia variable.

NUBE Cloud Cmputing. Conocida también como servicios en la nube, informática en la nube,
nube de cómputo, nube de conceptos o simplemente "la nube", es un paradigma que permite
ofrecer servicios de computación a través de una red, que usualmente es Internet.

NVR Network Video Recorder. Es un dispositivo físico o un software que se instala en una
computadora que permite la grabación y administración de imágenes digitales las cuales son
enviadas generalmente desde cámaras de tecnología IP.

142
OBD On Board Diagnostics. es un sistema de diagnóstico a bordo en vehículos (coches y
camiones). Actualmente se emplean los estándares OBD-II (Estados Unidos), EOBD (Europa) y
JOBD (Japón) que aportan un monitoreo y control completo del motor y otros dispositivos.

OBD On Board Diagnostics. es un sistema de diagnóstico a bordo en vehículos (coches y

camiones). Actualmente se emplean los estándares OBD-II (Estados Unidos), EOBD (Europa) y
JOBD (Japón) que aportan un monitoreo y control completo del motor y otros dispositivos del
vehículo. Los vehículos pesados poseen una norma diferente, regulada por la SAE, conocida
como J1939

OBD II OBD II es la segunda generación del sistema de diagnóstico a bordo, sucesor de OBD I.
Alerta al conductor cuando el nivel de las emisiones es 1.5 mayor a las diseñadas. A diferencia
de OBD I, OBD II detecta fallos eléctricos, químicos y mecánicos que pueden afectar al nivel de
emisiones del vehículo.

OEM Original Equipment Manufacturer. Se refiere a la empresa que manufactura productos

que luego son comprados por otra y vendidos al por menor bajo la marca de la empresa
compradora, a veces conocida como empresa reenvasadora.

ONVIF Open Network Video Interface Forum. Es un foro global y abierto de la industria que
proporciona, promueve y facilita el desarrollo y uso las interfaces estandarizadas globales para
una interoperabilidad efectiva de productos de vigilancia y seguridad física basados en
conectividad IP. Su propósito es el desarrollar un estándar sobre cómo los productos IP dentro
de la videovigilancia y otras áreas de seguridad física pueden comunicarse entre sí. Fue creada
en 2008 por Axis Communications, Bosch Security Systems y Sony.

OSI Open System Interconnection. Es un modelo de referencia para los protocolos de la red
(no es una arquitectura de red), creado en el año 1980 por la Organización Internacional de
Normalización (ISO). Se ha publicado desde 1983 por la Unión Internacional de
Telecomunicaciones (UIT) y, desde 1984, la Organización Internacional de Normalización (ISO)
también lo publicó con estándar. Su desarrollo comenzó en 1977

OTA Over-the-Air programming. Se refiere a varios métodos de distribución de forma

inalambrica de software nuevo, ajustes de configuración e incluso actualización de claves de
cifrado para dispositivos como teléfonos celulares, decodificadores o equipos de comunicación
de voz seguros (radios de 2 vías cifradas). Una característica importante de OTA es que una
ubicación central puede enviar una actualización a todos los usuarios que no pueden rechazar,
anular o alterar esa actualización, y que la actualización se aplica de inmediato a todos los
usuarios del canal. Un usuario podría "rechazar" la OTA, pero el "administrador de canales"
también podría "expulsarlos" del canal automáticamente.

OTS Commercial off-the-shelf. Es un término del Reglamento Federal de Adquisiciones

(FAR), que define a productos o elementos empaquetados no-desarrollativo (NDI) de
suministro, que es a la vez comercial y que se vende en grandes cantidades en el mercado
comercial, y que puede ser adquirido o utilizado bajo contrato gubernamental de la misma
forma exacta a como está disponible al público en general. Por ejemplo, para los elementos

143
relacionados con la tecnología, tales como programas informáticos, sistemas de hardware o de
software libre con apoyo comercial y materiales de construcción.

PTZ Camera Pan-Tilt-Zoom Camera. Tiene dos usos dentro de la industria de los productos
de seguridad de video y vigilancia. En primer lugar, se puede referir a sólo a las características
de las cámaras de vigilancia específicas. En segundo lugar, «cámaras PTZ» también puede
describir toda una categoría de cámaras con seguimiento automático, en las que el sonido, el
movimiento, los cambios en la huella de calor, o una combinación de estos factores, activando
la cámara, el enfoque y cambios en el campo de visión.

RAM Random Access Memory. Corresponde memoria principal de una computadora,

computador personal PC, microprocesador, sistema embebido donde residen programas y
datos, sobre la que se pueden efectuar operaciones de lectura y escritura.

REST Representational State Transfer. La transferencia de estado representacional es un

estilo de arquitectura software para sistemas hipermedia distribuidos como la World Wide
Web. El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy
Fielding, uno de los principales autores de la especificación del protocolo HTTP y ha pasado a
ser ampliamente utilizado por la comunidad de desarrollo. Originalmente se refirió a un
conjunto de principios de arquitectura, pero en la actualidad se usa en el sentido más amplio
para describir cualquier interfaz entre sistemas que utilice directamente HTTP para obtener
datos o indicar la ejecución de operaciones sobre los datos, en cualquier formato (XML, JSON,
entre otros) sin las abstracciones adicionales de los protocolos basados en patrones de
intercambio de mensajes, como por ejemplo SOAP.

RFID Radio Frequency Identification. Es un sistema de almacenamiento y recuperación de

datos remoto que usa dispositivos denominados etiquetas, tarjetas o transpondedores RFID. El
propósito fundamental de la tecnología RFID es transmitir la identidad de un objeto (similar a
un número de serie único) mediante ondas de radio. Las tecnologías RFID se agrupan dentro de
las denominadas Auto ID (Automatic Identification, o Identificación Automática).

RJ Registered Jack. Son un grupo de estándares para interfaz física, tanto para la
construcción de conectores como para el diseño del cableado, para la conexión de equipos de
telecomunicaciones o de redes datos. Son usados como estándares a nivel internacional y
vienen integrados predeterminadamente en las computadoras.

RoHS Restriction of Hazardous Substances. Se refiere a la directiva 2002/95/CE de

Restricción de ciertas Sustancias Peligrosas en aparatos eléctricos y electrónicos, adoptada en
febrero de 2003 por la Unión Europea

RPO Recovery Point Objetive. Se refiere al tiempo que transcurre entre el momento del
desastre y el último punto de restauración de nuestros datos, es decir, la cantidad de datos que
nuestra empresa va a perder en caso de que se produzca un fallo del sistema.

RS232 Protocolo de transmisión serial punto a punto definido dentro del estándar EIA, con
posibilidad de trabajar modo asíncrono o síncrono.

144
RS485 protocolo de transmisión serial en bus en aplicaciones de instrumentación industrial y
dispositivos de control. Permite la conectividad en bus de diferentes dispositivos de control e
instrumentación, generalmente en redes protocolo industrial.

RTO Recovery Time Objective. Expresa el tiempo durante el cual una organización pueda
tolerar la falta de funcionamiento de sus aplicaciones y la caída de nivel de servicio asociada,
sin afectar a la continuidad del negocio.

SAE Society of Automotive Engineers. Es la organización enfocada en la movilidad de los

profesionales en la ingeniería aeroespacial, automoción, y todas las industrias comerciales
especializadas en la construcción de los vehículos. El principal objetivo de la sociedad es el
desarrollo de los estándares para todos los tipos de vehículos, incluyendo coches, camiones,
barcos, aviones, etc. Cada uno que se interese por los factores humanos y los estándares
ergonómicos, puede ser miembro de esta organización.

SFTP SSH File Transfer Protocol. Permite una serie de operaciones sobre archivos remotos.
SFTP intenta ser más independiente de la plataforma que SCP, por ejemplo, SCP soporta
expansión de comodines especificados por el cliente hasta el servidor, mientras que el diseño
SFTP evita este problema. Aunque SCP se aplica con más frecuencia en plataformas Unix,
existen servidores SFTP en la mayoría de las plataformas.

SHA Secure Hash Algorithm. Es una familia de funciones hash publicadas por el Instituto
Nacional de Normas y Tecnología, INNT (NIST en idioma inglés) de Estados Unidos.

SIM Subscriber Identity Module. Es una tarjeta inteligente desmontable usada en teléfonos
móviles y módems HSPA o LTE que se conectan al dispositivo por medio de una ranura lectora
o lector SIM. Las tarjetas SIN almacenan de forma segura la clave de servicio del suscriptor
usada para identificarse ante la red, de forma que sea posible cambiar la suscripción del cliente
de un terminal a otro simplemente cambiando la tarjeta.

SMTP Simple Mail Transfer Protocol. Es un protocolo de comunicación que permite el envío
de correos electrónicos en Internet.

SNMP Simple Network Management Protocol. Es un protocolo de la capa de aplicación que

facilita el intercambio de información de administración entre dispositivos de red

SSD Solid-State Drive. Es un tipo de dispositivo de almacenamiento de datos que utiliza

memoria no volátil, como la memoria flash, para almacenar datos, en lugar de los platos o discos
magnéticos de las unidades de discos duros (HDD) convencionales.

SSH Secure SHell. Es el nombre de un protocolo y del programa que lo implementa cuya
principal función es el acceso remoto a un servidor por medio de un canal seguro en el que toda
la información está cifrada. Además de la conexión a otros dispositivos, SSH permite copiar
datos de forma segura (tanto archivos sueltos como simular sesiones FTP cifradas), gestionar
claves RSA para no escribir contraseñas al conectar a los dispositivos y pasar los datos de
cualquier otra aplicación por un canal seguro tunelizado mediante SSH y también puede
redirigir el tráfico del (Sistema de Ventanas X) para poder ejecutar programas gráficos
remotamente. El protocolo TCP asignado es el 22

145
SSL Secure Sockets Layer. Son protocolos criptográficos, que proporcionan comunicaciones
seguras por una red, comúnmente Internet.

STDI Sistema Tecnológico de Divulgación de Información. Es un Sistema audiovisual

interactivo al usuario, aplicado en esquemas de ciudades inteligentes o sistemas de transporte
masivo publico tipo Smart. Se caracteriza por reproducir contenidos de divulgación con
temáticas no solo informativas pertenecientes al ente al que pertenece, sino también campañas
de divulgación y sensibilización, datos de orientación, datos de geolocalización y ubicación en
tiempo real, datos normatividad y sanciones, entrenamiento y noticias, consulta a plataformas
informativas, acceso a Internet y redes sociales, entre otros. Para su acceso, gestión y
administración de contenido de se utilizan esquemas de validación en un modelo de servidor
Web o aplicaciones móviles especializadas.

STS Sistema Tecnológico de Seguridad. Es un sistema de seguridad integrado convergente

que por lo general está conformado por vigilancia por video de CCTV, control de acceso, alarmas
de acceso, ente otros.

TC Traffict Control. Es el proceso de administrar, controlar o reducir el tráfico de red, en

particular el ancho de banda de Internet, por ejemplo. por el programador de la red. Lo utilizan
los administradores de red para reducir la congestión, la latencia y la pérdida de paquetes. Esto
es parte de la gestión del ancho de banda. Para utilizar estas herramientas de manera efectiva,
es necesario medir el tráfico de la red para determinar las causas de la congestión de la red y
atacar esos problemas específicamente.

TI Technology of Information Es el área informática donde se utilizan, implementa y

configuran ordenadores y equipos de telecomunicación para almacenar, recuperar, transmitir
y manipular datos. Por lo general es aplicado en el contexto de los negocios u otras empresas

TLS Transport Layer Security. Son protocolos criptográficos, que proporcionan

comunicaciones seguras por una red, comúnmente Internet.

UDP User Datagram Protocol. Es un protocolo mínimo de nivel de transporte orientado a

mensajes documentado en el RFC 768 de la IETF. En la familia de protocolos de Internet UDP
proporciona una sencilla interfaz entre la capa de red y la capa de aplicación. Permite el envío
de datagramas a través de la red sin que se haya establecido previamente una conexión, ya que
el propio datagrama incorpora suficiente información de direccionamiento en su cabecera.

UNCE R10 Regulación con respecto a la adopción de un reglamento técnico armonizado de

las Naciones Unidas para vehículos con ruedas, equipos y piezas que se pueden instalar y / o
utilizar en vehículos con ruedas y las condiciones para el reconocimiento recíproco de
aprobaciones otorgadas en base a estas regulaciones de las Naciones Unidas

UNCE R18 Regulación Sobre la adopción de prescripciones técnicas uniformes para

vehículos con ruedas, equipos y piezas que pueden implementarse y/o usarse en vehículos con
ruedas y las condiciones para el reconocimiento recíproco de las aprobaciones otorgadas sobre
la base de estas prescripciones

146
UNECE United Nations Economic Commission. Se estableció en 1947 para promocionar la
cooperación económica entre sus Estados Miembros. Es una de las cinco comisiones regionales
bajo la dirección administrativa de las sedes de las Naciones Unidas

USB Universal Serial Bus. Es un bus de comunicaciones que sigue un estándar que define los
cables, conectores y protocolos usados en un bus para conectar, comunicar y proveer de
alimentación eléctrica entre computadoras, periféricos y dispositivos electrónicos.

VELOCIDAD SUFICIENTE: Criterio de transmisión y recepción de datos que debe garantizar la

descarga y subida de información en las mejores condiciones, es decir con calidad, velocidad y
ancho de banda; para todos los equipos utilizados en las soluciones de ITS que hacen parte de
este anexo.

VDC Volts Direct Current. Unidad de voltaje en corriente directa

VLAN Virtual Local Area Network. Es un método tecnológico para crear redes lógicas
independientes dentro de una misma red física, y que se utiliza en los dispositivos
conmutadores o switches de red

VMS Video Management System. Es un componente de un sistema de cámaras de seguridad

que realiza las funciones de recopilar video de cámaras y otras fuentes, graba / almacena ese
video en un dispositivo de almacenamiento y proporciona una interfaz para ver el video en vivo
y acceder al video grabado. Puede ser el componente de software de un grabador de video en
red o de un grabador de video digital, aunque en general un VMS tiende a ser más sofisticado y
brinda más opciones y capacidades que un dispositivo NVR.

VOD Video On Demand. Es un sistema de televisión que permite a los usuarios el acceso a
contenidos multimedia de forma personalizada ofreciéndoles, de este modo, la posibilidad de
solicitar y visualizar una película o programa concreto en el momento exacto que el
telespectador lo desee. Existe, por tanto, la posibilidad de visualización en tiempo real o bien
descargándolo en un dispositivo como puede ser una computadora, una grabadora de video
digital (grabadora de video personal) o un reproductor portátil para verlo en cualquier
momento.

WAN Wide Area Network. Es una red de datos que conecta varias redes locales o remotas,
aunque sus miembros no estén todos en una misma ubicación física. Son utilizadas o instaladas
por organizaciones o empresas para su uso privado, otras son instaladas por los proveedores
de Internet (ISP) para proveer conexión a sus clientes.

WDR Wide Dynamic Range. Es una característica avanzada de algunos modelos de cámara
que les permite manejar de una forma mejorada distintas condiciones de luminosidad en una
misma escena.

WiFI Es una marca de la Alianza Wi-Fi, la organización comercial que adopta, prueba y
certifica que los equipos cumplen con los estándares 802.11 relacionados con redes
inalámbricas de área local. En general es una tecnología que permite la interconexión
inalámbrica de dispositivos electrónicos. Los dispositivos habilitados con WiFi (tales como

147
computadoras personales, teléfonos, televisores, videoconsolas, reproductores de música...)
pueden conectarse entre sí o a Internet a través de un punto de acceso de red inalámbrica.

WRT Work Recovery Time. Dentro del contexto de continuidad de negocios y recuperación
de desastres, corresponde al tiempo de recuperación del trabajo, es decir la cantidad máxima
de tiempo tolerable que se necesita para verificar la integridad del sistema y / o los datos.

XML EXtensible Markup Language. es un meta-lenguaje que permite definir lenguajes de

marcas desarrollado por el World Wide Web Consortium (W3C) utilizado para almacenar datos
en forma legible. Proviene del lenguaje SGML y permite definir la gramática de lenguajes
específicos (de la misma manera que HTML. Es a su vez un lenguaje definido por SGML) para
estructurar documentos grandes. A diferencia de otros lenguajes, XML da soporte a bases de
datos, siendo útil cuando varias aplicaciones deben comunicarse entre sí o integrar
información.

148