ANEXO TÉCNICO DEL PROYECTO DE

ADOPCIÓN DE REQUISITOS FUNCIONALES Y

TÉCNICOS DE LOS PÁNELES DE MENSAJE
VARIABLE PARA EL PAÍS

MINISTERIO DE TRANSPORTE
JUNIO DE 2017

Anexo Técnico de la Resolución XXXXX de XXXX, De acuerdo al artículo 2.5.3.2. Subsistemas del Sinitt
del Título 3 del Decreto 1079 de 2015

1
 CONTENIDO
CAPÍTULO 1 - DISPOSICIONES GENERALES .......................................................... 6
1. OBJETO............................................................................................................ 6
2. ÁMBITO DE APLICACIÓN ................................................................................ 6
3. DEFINICIONES, SIGLAS Y SÍMBOLOS ........................................................... 6
3.1. LISTA DE ABREVIATURAS .............................................................................. 6
CAPÍTULO 2 - CONCEPTO JURÍDICO ..................................................................... 15
4. MECANISMO PARA LA IMPLEMENTACIÓN ................................................. 15
5. CONTENIDO DEL ACTO ADMINISTRATIVO ................................................. 17
5.1. CARACTERÍSTICAS TÉCNICAS Y FUNCIONALES DE LOS PANELES DE
MENSAJERÍA VARIABLE ...................................................................................... 17
5.2. PLATAFORMA TECNOLÓGICA.................................................................. 17
5.3. MENSAJERÍA .............................................................................................. 18
5.4. GESTIÓN Y SEGUIMIENTO ....................................................................... 18
6. REGIMEN SANCIONATORIO ......................................................................... 19
CAPÍTULO 3 - CONCEPTO DE OPERACIÓN........................................................... 19
7. GENERALIDADES .......................................................................................... 19
8. DOCUMENTOS DE REFERENCIA ................................................................. 20
9. CONTEXTO .................................................................................................... 27
10. ALCANCE ....................................................................................................... 27
10.1. DESCRIPCIÓN GENERAL DEL DOCUMENTO ............................................. 27
10.2. DESCRIPCIÓN GENERAL DEL SUBSISTEMA ITS DE SEÑALES DE
MENSAJE VARIABLE ............................................................................................... 28
10.2.1 Visión .............................................................................................................. 28
10.2.2 Objetivo General ............................................................................................. 28
10.2.3 Objetivos Específicos ...................................................................................... 28
11. ESTADO ACTUAL .......................................................................................... 29
11.1. NORMATIVA, POLÍTICAS OPERACIONALES Y RESTRICCIONES .............. 29
11.1.1.Infraestructura Vial Nacional ........................................................................... 31
11.1.2.Infraestructura Vial de Entidades Territoriales ................................................. 32
11.2. DESCRIPCIÓN ............................................................................................... 33
11.2.1.Perfiles de Actores .......................................................................................... 36
11.2.2.Interacción entre Actores ................................................................................ 37
11.2.3.Otros Involucrados .......................................................................................... 40
12. FUNDAMENTOS DEL SERVICIOS ITS DE SEÑALES DE MENSAJE
VARIABLE ................................................................................................................. 40
12.1. CLASIFICACIÓN............................................................................................. 41
12.1.1.Clasificación VMS respecto a su infraestructura ............................................. 41
12.1.2.Clasificación VMS respecto a tipo de señal..................................................... 41
12.1.3.Clasificación VMS respecto a forma de despliegue de mensaje ..................... 41

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

2
12.2. Descripción de las Necesidades actuales para el país en términos de Señales
de Mensaje Variable .................................................................................................. 42
12.2.1.Definir un Diccionario de Mensajes Estandarizado ......................................... 42
12.2.2......... Establecer criterios técnicos de selección de equipos VMS en función de la
tipología vial y de la condición de operación a informar ............................................. 43
12.2.3........... Especificar requisitos de hardware y software de la solución tecnológica a
implementar por parte de los administradores viales y entidades territoriales a cargo
de la infraestructura vial ............................................................................................. 43
12.2.4.Definir un mecanismo de Interoperabilidad basado en servicios ..................... 44
12.2.5.Definir un mecanismo de enlace simultáneo ................................................... 44
13. POLÍTICAS OPERACIONALES Y RESTRICCIONES ..................................... 45
14. DESCRIPCIÓN DEL MÓDULO ITS PROPUESTO ......................................... 46
14.1. DICCIONARIO DE MENSAJE ESTANDARIZADO .......................................... 46
14.1.1.......... Esquema de Interoperabilidad basado en Servicios para la Administración
Remota de equipos VMS ........................................................................................... 46
14.1.2.Especificaciones Técnicas Mínimas de Equipos VMS, Administración local,
especificaciones técnicas mínimas del CCO, especificaciones mínimas de
comunicaciones con el CCO y el Ministerio de Transporte ........................................ 47
14.1.3.Plataforma SiGVMS ........................................................................................ 47
14.1.4.Integración SINITT .......................................................................................... 48
14.1.5.Diagrama de Solución Propuesta .................................................................... 48
14.2. MODOS DE OPERACIÓN .............................................................................. 50
14.2.1.Respecto del Módulo ITS SiGVMS ................................................................. 50
14.2.2.Respecto de la operación en los CCO ............................................................ 51
14.3. ACTORES Y OTROS INVOLUCRADOS......................................................... 51
14.3.1.Estructura Organizacional ............................................................................... 52
14.3.2.Interacción entre Actores ................................................................................ 53
14.3.3.Otros Involucrados .......................................................................................... 57
14.4. ENTORNO DE SOPORTE .............................................................................. 57
14.4.1.Componentes de Software .............................................................................. 57
14.4.2.Componentes de Hardware ............................................................................ 57
14.4.3.Componentes de Seguridad............................................................................ 57
15. ESCENARIOS OPERACIONALES ................................................................. 57
15.1. DESPLIEGUE EQUIPO VMS .......................................................................... 57
15.1.1.Adquisición e Instalación Física ...................................................................... 58
15.1.2.Instalación y Configuración de la Plataforma de Gestión CCO ........................ 58
15.1.3.Instalación y Configuración Conectividad con el CCO..................................... 58
15.2. ADMINISTRACIÓN REMOTA DE EQUIPOS VMS.......................................... 58
15.2.1.Configuración Banco de Mensajes y Pictogramas .......................................... 58
15.2.2.Gestionar Equipos VMS .................................................................................. 58
15.2.3.Gestionar Estado Operativo Equipos VMS ...................................................... 59

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

3
15.2.4.Gestionar Mantenimientos Preventivos y Correctivos ..................................... 59
15.2.5.Reportar datos Equipos VMS a SiGVMS ........................................................ 59
15.3. ADMINISTRACIÓN LOCAL EQUIPO VMS ..................................................... 59
15.3.1.Realizar Instalación y Configuración ............................................................... 60
15.3.2.Realizar Mantenimiento .................................................................................. 60
15.3.3.Realizar Traslado Físico ................................................................................. 60
15.4. DIFUSIÓN DE MENSAJE DE INTERÉS NACIONAL ...................................... 60
15.5. CONSULTA INFORMACIÓN OPERACIÓN VMS EN COLOMBIA .................. 61
16. DESCRIPCIÓN DE LOS REQUISITOS DE HARDWARE ............................... 62
16.1. SEÑALES DE MENSAJE VARIABLE FIJAS (VMS) ........................................ 62
16.2. SEÑALES DE MENSAJE VARIABLE PORTÁTILES (PVMS) ......................... 71
17. DESCRIPCIÓN DE LOS REQUISITOS DE SOFTWARE ................................ 81
17.1. REQUISITOS GENERALES ........................................................................... 81
17.2. REQUISITOS PARA EL ADMINISTRADOR VIAL ........................................... 82
17.2.1.DESCRIPCIÓN GLOBAL DEL PRODUCTO SOFTWARE .............................. 82
17.2.1.1.Perspectiva del producto .............................................................................. 82
17.2.1.2.Funciones del producto ................................................................................ 84
17.2.1.3.Características de los usuarios .................................................................... 86
17.2.1.4.Restricciones ............................................................................................... 86
17.2.1.5.Supuestos y dependencias .......................................................................... 87
17.2.2.REQUISITOS ESPECÍFICOS ......................................................................... 87
17.2.2.1. Plataforma de Gestión Remota de Equipos VMS ........................................ 87
17.2.2.2.Plataforma de Gestión Local de Equipos VMS ............................................. 97
17.2.2.3.Componente para Interoperabilidad de Equipos VMS ................................ 100
17.3. MINISTERIO DE TRANSPORTE .................................................................. 102
17.3.1.DESCRIPCIÓN GLOBAL DEL PRODUCTO SOFTWARE ............................ 102
17.3.1.1.Perspectiva del producto ............................................................................ 102
17.3.1.2.Funciones del producto .............................................................................. 105
17.3.1.3.Características de los usuarios .................................................................. 105
17.3.1.4.Restricciones ............................................................................................. 106
17.3.1.5.Supuestos y dependencias ........................................................................ 108
17.3.2.REQUISITOS ESPECÍFICOS ....................................................................... 108
17.3.2.1.Plataforma SiGVMS ................................................................................... 108
17.3.2.2.Especificación para Interoperabilidad con Equipos VMS ............................ 119
18. VERIFICACIÓN............................................................................................. 133
18.1. CARACTERÍSTICAS DEL SISTEMA ............................................................ 133
18.1.1.PERSPECTIVA ............................................................................................. 133
18.2. ELEMENTOS OBJETIVOS ........................................................................... 134
18.3. PANORAMA DE PRUEBAS .......................................................................... 135

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

4
18.3.1.PRUEBAS INCLUIDAS ................................................................................. 135
18.3.2.OTRAS CANDIDATAS PARA SER POTENCIALMENTE INCLUIDAS .......... 137
18.3.3.EXCLUSIONES DE LAS PRUEBAS ............................................................. 137
18.4. NECESIDADES DEL ENTORNO .................................................................. 138
18.4.1.REQUISITOS DE HARDWARE .................................................................... 138
18.4.2.REQUISITOS DE SOFTWARE ..................................................................... 138
18.4.3.REQUISITOS DE CONFIGURACIÓN ........................................................... 138
18.4.4.HERRAMIENTAS DE PRODUCTIVIDAD Y SOPORTE ................................ 138
18.4.5.ENTREGABLES ........................................................................................... 138
18.5. DESCRIPCIÓN DE LAS PRUEBAS .............................................................. 139
18.5.1.Verificar el registro de datos en SiGMapas ................................................... 139
18.5.2.Verificar el registra de datos de Equipos VMS .............................................. 139
18.5.3.Verificar la consulta de Equipos VMS ........................................................... 139
18.5.4.Verificar la gestión de Pictogramas ............................................................... 139
18.5.5.Verificar la gestión de Tipos de Mensajes ..................................................... 139
18.5.6.Verificar la gestión de Mensajes.................................................................... 139
18.5.7.Verificar el envío de petición a Equipo VMS en CCO .................................... 140
18.5.8. Verificar la activación de un Mensaje de Interés Nacional en Equipos VMS 140
18.5.9.Verificar la consulta de la Configuración Estándar para Equipo VMS ............ 140
18.5.10.Verificar la gestión de Tipos de Fuentes ..................................................... 140
18.5.11.Verificar la gestión de Parámetros del Sistema ........................................... 140
19. MODELO DE DOMINIO ................................................................................ 140
19.1. ALCANCE DEL MODELO DE DOMINIO....................................................... 140
19.2. ESPECIFICACIÓN MODELO DE DOMINIO ................................................. 141
19.2.1.1.Modelo Información Dinámica .................................................................... 141
19.2.1.2.Modelo Información Estática ...................................................................... 149
19.2.1.3.Modelo Información Genérica .................................................................... 150
19.3. DICCIONARIO DE DATOS ........................................................................... 154
19.3.1.Descripción del Modelo de dominio............................................................... 154
19.3.1.1.Modelo Información dinámica .................................................................... 154
19.3.1.2.Modelo Información estática ...................................................................... 161
19.3.1.3.Modelo Información genérica ..................................................................... 163
19.4. TIPOS DE DATOS PARA EL MODELO DE DOMINIO .................................. 165
19.4.1.ENUMERACIONES PARA EL MODELO DE DOMINIO ................................ 166
19.5. GUÍA DE MENSAJES PARA VMS ................................................................ 170
19.5.1.Lista Textos para inclusión en Mensajes ....................................................... 171
19.5.2.Lista de pictogramas para inclusión en Mensajes ......................................... 175
20. BIBLIOGRAFÍA ............................................................................................. 176

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

5
 CAPÍTULO 1 - DISPOSICIONES GENERALES

1. OBJETO
Establecer las características y requerimientos de hardware y software para los
paneles de mensajería variable VMS.

2. ÁMBITO DE APLICACIÓN

Las disposiciones contenidas en esta sección del documento, se aplicarán a los

actores xxxxxxxxxxxx.

3. DEFINICIONES, SIGLAS Y SÍMBOLOS

Definiciones. Para efectos de la presente reglamentación, se tendrán en cuenta las

siguientes definiciones y abreviaturas específicas:

3.1. LISTA DE ABREVIATURAS

 ANI: Acrónimo de Agencia Nacional de Infraestructura.

 ANSI: American National Standards Institute.
 CICOTT: Centro Inteligente de Control para el Tránsito y el Transporte.
 ConOps: Concepto de Operación.
 DB: Del inglés Data Base. Base de Datos.
 DMZ: Del inglés Demilitarized Zone. Zona Desmilitarizada.
 DNP: Departamento Nacional de Planeación
 HW: Del inglés Hardware.
 IaaS: Del inglés Infraestructure as a Services. Infraestructura como Servicio
 IEC: International Electrotechnical Commission.
 IEEE: Institute of Electrical and Electronics Engineers.
 INVIAS: Instituto Nacional de Vías.
 ISO: International Standard Organization.
 IPS: Del inglés Intrusion Prevention System. Sistema de Prevención de
intrusos
 ITS: Del inglés Intelligent Transport Systems. Sistemas Inteligentes de
Transporte.
 LAN: Del inglés Local Area Network. Red de Área Local.
 LED: Del inglés Light Emitting Diode. Diodo Emisor de Luz, en español led.
 MT: Ministerio de Transporte de Colombia.
 MTBF: Del inglés Mean Time Between Failures. Tiempo Medio Entre Fallas
 NTC: Norma Técnica Colombiana
 NTP: Del inglés Network Time Protocol. Protocolo de Tiempo de Red
 OAP: Oficina Asesora de Planeación del Ministerio de Transporte
 PaaS: Del inglés Platform as a Services. Plataforma como Servicio
 PVMS: Del inglés Portable Variable Message Signs.
 PND: Plan Nacional de Desarrollo
 PQRS: Peticiones, Quejas, Reclamos, Sugerencias, Denuncias y Opiniones
 RAM: Del inglés Random Access Memory. Memoria de Acceso Aleatorio
 RDP: Del inglés Remote Desktop Protocol. Protocolo de Escritorio Remoto
 SaaS: Del inglés Software as a Services. Software como Servicio
 SGSI: Acrónimo de Sistema de Gestión de Seguridad de la Información.
 SiGAAE: Subsistema de información para la Gestión de Autenticación de
Actores Estratégicos de ITS

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

6
  SiGTRAZABILIDAD: Subsistema para la Gestión de la Trazabilidad.
 SiGUDDI: Subsistema para la Gestión del Registro UDDI.
 SINITT: Sistema inteligente Nacional para la Infraestructura, el Tránsito y el
Transporte.
 SIT: Acrónimo de Sistemas Inteligentes de Transporte
 SSH: Del inglés Security Shell. Intérprete de Ordenes Seguro
 STP: Del inglés Shielded Twisted Pair. Cable par trenzado apantallado
 SW: Del inglés Software.
 TC: Del inglés Technical Committees. Comités Técnicos.
 TI: Tecnologías de la Información.
 TIA: Del inglés Telecomunications Industry Association.
 TLS: Del inglés Transport Layer Security. Seguridad en Capa de Transporte
 UDDI: Del inglés Universal Description, Discovery and Integration
 UPS: Del inglés Uninterruptible Power Supply. Sistema de alimentación
ininterrumpida.
 UTC: Del inglés Coordinated Universal Time. Tiempo Universal Coordinado
 UTP: Del inglés Unshielded twisted pair. Cable par trenzado no blindado
 VPN: Del inglés Virtual Private Network. Red Privada Virtual.
 VLAN: Del inglés Virtual Local Area Network. Red de Área Local Virtual
 VMS: Del inglés Variable Message Signs. Señales de Mensaje Variable
 WLAN: Del inglés Wireless Local Area Network. Red de Área Local
Inalámbrica

3.2. DEFINICIONES

 Ancho de haz: Ángulos medidos desde un eje de referencia de forma

horizontal y vertical. 1

 Análisis de vulnerabilidades: Pruebas técnicas realizadas a los sistemas

con el objetivo de identificar posibles brechas de seguridad para remediarlas antes de
que sean utilizadas en un ataque o intento del mismo. Estas pruebas suponen un
análisis completo de la infraestructura de hardware y software con todos los accesos y
sin restricciones o controles para que el análisis sea completo y veraz. Se diferencia
de la pruebas de penetración en que no busca tratar de vulnerar y explotar un
sistema.

 Canal dedicado o Conexión dedicada: Conexión que permite a las

organizaciones estar conectadas permanentemente a una red o a Internet (24 horas
del día, los 365 días del año), sin requerir el uso de línea telefónica, es una conexión
que se mantiene activa, de alta calidad, confiable y segura. Este tipo de conexión
facilita el acceso a Internet a los usuarios y a los especialistas a los recursos de
cómputo como redes locales, servidores y aplicaciones. 2

 Concepto de Operación del sistema (ConOps): Un Concepto de

Operaciones es un documento orientado al usuario que "describe las características
del sistema para el sistema propuesto desde el punto de vista de los usuarios. El
documento ConOps es usado para comunicar las características generales
cualitativas y cuantitativas al usuario, comprador, desarrollador y otros elementos
organizacionales (por ejemplo: capacitación, instalaciones, personal y
mantenimiento). Es usado para describir la organización, la misión y objetivos
organizacionales desde el punto de vista de sistemas integrados". 3

1
UNE EN 12966
2
Recuperado de: http://www.grupointerclan.com/internet/enlaces_dedicados.pdf
3
IEEE Computer Society. 2007. Recuperado de: https://standards.ieee.org/findstds/standard/1362-

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

7
  Concesionario Vial: Persona natural o jurídica adjudicataria en un proceso de
selección, con quien la entidad estatal adjudicante ha suscrito un contrato de
concesión vial. El concesionario vial es responsable, ante la entidad estatal
adjudicante, de la operación del corredor vial.

 Cromaticidad: Es la propiedad psicofísica de un color y se compone de dos

atributos: el tono y la pureza (también llamado croma). Es el grado de diferencia
existente entre un color y un gris de su misma luminosidad y claridad, que se
corresponde con la saturación del color percibido. 4

 Datex II: En el sector vial, la norma DATEX fue desarrollada para el

intercambio de información entre centros de gestión de tráfico, centros de información
de tráfico y proveedores de servicios y constituye la referencia para aplicaciones
desarrolladas en los últimos 10 años. La segunda generación de especificaciones
DATEX II ahora también empuja la puerta abierta para todos los actores en el tráfico y
el sector de información de viajes.

 Diccionario de Datos: Describe un conjunto de metadatos con las

características lógicas de los datos de un sistema, tales como: nombre, alias,
descripción, tipo de dato, longitud, valor por defecto y origen. Lista todos los
elementos que forman parte del flujo de datos en todo el sistema.

 Fotometría: Ciencia encargada de estudia la capacidad que tiene la radiación

electromagnética, solamente dentro del rango visible del espectro, para estimular al
ojo humano. Es decir, se encarga de medir la intensidad de la luz. 5

 Georreferenciación: La georreferenciación es el uso de coordenadas de

mapa para asignar una ubicación espacial a entidades cartográficas. Todos los
elementos de una capa de mapa tienen una ubicación geográfica y una extensión
específicas que permiten situarlos en la superficie de la Tierra o cerca de ella. La
capacidad de localizar de manera precisa las entidades geográficas es fundamental
tanto en la representación cartográfica como en SIG. 6
 Gobierno en línea (GEL): Es el nombre que recibe la estrategia de gobierno
electrónico (e-government) en Colombia, que busca construir un Estado más eficiente,
más transparente y más participativo gracias a las TIC. Esto significa que el Gobierno:
- Prestará los mejores servicios en línea al ciudadano
- Logrará la excelencia en la gestión
- Empoderará y generará confianza en los ciudadanos
- Impulsará y facilitará las acciones requeridas para avanzar en los
Objetivos de Desarrollo Sostenible -ODS, facilitando el goce efectivo de
derechos a través del uso de TIC

 Equipo/dispositivo de Cómputo: Se refiere a los mecanismos y al material

de computación que puede incluir computadoras personales, servidores de mediana
escala, ordenadores centrales, dispositivos de almacenaje.

 Firewall: Un firewall es un dispositivo de seguridad de la red que monitorea el

tráfico de red -entrante y saliente- y decide si permite o bloquea tráfico específico en
función de un conjunto definido de reglas de seguridad. Los firewalls han constituido

1998.html.
4
Recuperado de: http://www.parro.com.ar/definicion-de-cromaticidad
5
Recuperado de: http://grlum.dpe.upc.edu/manual/sistemasIluminacion-fotometria.php
6
ArcGis Resources. 2016. Recuperado de:

http://resources.arcgis.com/es/help/getting-started/articles/026n0000000s000000.htm

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

8
una primera línea de defensa en seguridad de la red durante más de 25 años.
Establecen una barrera entre las redes internas protegidas y controladas en las que
se puede confiar y redes externas que no son de confianza, como Internet. Un firewall
puede ser hardware, software o ambos. 7

 Hardware (HW): Parte física de un computador, sistema informático o aparato

electrónico, está formado por los componentes eléctricos, electrónicos,
electromecánicos y mecánicos, tales como circuitos de cables y circuitos de luz,
placas y cualquier otro material, en estado físico, que sea necesario para hacer que el
equipo funcione. El término viene del inglés, significa partes duras. El hardware no
se limita a los ordenadores personales, también se dispone en los automóviles,
teléfonos móviles, cámaras, robots.

 Infraestructura como Servicio (Infrastructure as a Services - IaaS):

Computación, almacenamiento, redes y otros elementos (herramientas de seguridad),
proporcionadas por un proveedor de IaaS, a través de Internet, VPN o conexión
dedicada. Los usuarios tienen acceso y gestionan de forma remota los recursos de
sistemas operativos, aplicaciones e información que se ejecutan en la infraestructura,
y pagan por su uso. 9

 Interoperabilidad: “Es la interacción e intercambio de datos de acuerdo con

un método definido a través de la integración de tecnología y regulación normativa,
entre dos o más sistemas (computadores, medios de comunicación, redes, software y
otros componentes de tecnología de la información). La Norma Internacional
ISO19101:2002 define la interoperabilidad como “la capacidad de los sistemas o
componentes de intercambiar información y de poder controlar el procesamiento
cooperativo entre aplicaciones. Para ello se precisan: capacidades de localización de
la información y las herramientas de proceso; entender y usar la información y las
herramientas descubiertas; poder desarrollar entornos de proceso para uso comercial
sin restricciones de la oferta única en el mercado; poder desarrollar infraestructuras
de información y procesamiento para servir a los distintos tipos de mercado y
promover un mercado libre de competencia entre los consumidores”. 10

 Keyhole Markup Language (KML): KML es un lenguaje XML centrado en la

visualización geográfica, incluyendo la anotación de mapas e imágenes. Visualización
geográfica incluye no sólo la presentación de datos gráficos en el mundo, sino
también el control de la navegación del usuario en el sentido de a dónde ir y dónde
buscar.

 Lenguaje de definición de esquemas (XDS): Ofrece facilidades para describir

la estructura y restringir el contenido de documentos XML, incluidos aquellos que
explotan el espacio de nombres XML. El lenguaje de esquema, que está representado
en un vocabulario XML y utiliza espacios de nombres, reconstruye y amplía
considerablemente las capacidades encontradas en las definiciones de tipos de
documentos XML.

 Lenguaje de marcas Extensible (XML): XML es un Lenguaje de Etiquetado

Extensible muy simple, pero estricto que juega un papel fundamental en el
intercambio de una gran variedad de datos. Es un lenguaje muy similar a HTML pero
su función principal es describir datos y no mostrarlos como es el caso de HTML. XML
es un formato que permite la lectura de datos a través de diferentes aplicaciones. Las
tecnologías XML son un conjunto de módulos que ofrecen servicios útiles a las
demandas más frecuentes por parte de los usuarios. XML sirve para estructurar,

7
Grupo Educare. 2011. Recuperado de:
http://www.cisco.com/c/es_mx/products/security/firewalls/what-is-a-firewall.html
9
Recuperado de: https://www.emc.com/corporate/glossary/cloud-computing-services.htm
10
Decreto Nacional 2060 de 2015, Numeral 5 Artículo 2513

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

9
almacenar e intercambiar información.

Luminancia: En Fotometría, la luminancia se define como la densidad angular y

superficial de flujo luminoso que incide, atraviesa o emerge de una superficie
siguiendo una dirección determinada. Alternativamente, también se puede definir
como la densidad superficial de intensidad luminosa en una dirección dada.

 Niveles de conformidad A, AA y AAA: Las páginas web pueden tener

diferentes niveles de cumplimiento de la NTC 5854, de acuerdo con el número de
requisitos que hayan implementado. Estos niveles indican el mayor o menor grado de
accesibilidad y se denominan como niveles de conformidad. De acuerdo con la
norma, existen tres posibilidades: A, AA y AAA.

 Oficina Asesora de Planeación del Ministerio de Transporte (OAP): Oficina

encargada de Asesorar al Ministro y Viceministros en la definición, coordinación y
adopción de las políticas sectoriales, estrategias, planes, programas y proyectos para
garantizar el cumplimiento de los objetivos sectoriales; entre otras funciones
especificadas en el Decreto número 087 de 2011. 11

 Organismo de Tránsito y Transporte: Son unidades administrativas

municipales distritales o departamentales que tienen por reglamento la función de
organizar y dirigir lo relacionado con el tránsito y transporte en su respectiva
jurisdicción.

 Organización Internacional para la Estandarización (ISO): Es una

organización internacional independiente, no gubernamental, con una membresía de
163 organismos nacionales de normalización. A través de sus miembros reúne a
expertos para compartir conocimiento voluntario y desarrollar estrategias basadas en
el consenso así como el mercado de Normas Internacionales relevantes que apoyan
la innovación y aporten soluciones a retos globales. 12

 Plataforma como Servicio (Platform as a Services - PaaS): Todo el

software y hardware necesario para construir y operará las aplicaciones basadas en la
nube son proporcionadas por el proveedor de PaaS, a través de Internet, VPN o
conexión de red dedicada. Los usuarios pagan mediante el uso de la plataforma y
controlan como se utilizan las aplicaciones a los largo de su ciclo de vida. 13

 Protocolo nacional para la comunicación del transporte inteligente

(NTCIP): Es una familia de estándares abiertos que define los protocolos de
comunicación comunes y las definiciones de datos para transmitir datos y mensajes
entre sistemas de computadora y sistemas de transporte inteligente.

 Protocolo de transferencia de hipertexto (HTTP): Cada vez que enviamos

información a Internet estamos utilizando el protocolo que es conocido como HTTP,
siglas que en inglés significan Hypertext Transfer Protocol, cuyo equivalente en
nuestro idioma sería el de Protocolo de Transferencia de Hipertexto, lo que nos
permite navegar cómodamente por la red sin necesidad de memorizar grandes cifras
o textos más que complicados. Lo que permite este protocolo es justamente gestionar
el Acceso a un punto remoto, brindando entonces una especie de atajo, para lo cual
tendremos asignado una Vía de Comunicación determinada, que se otorga por el
contenido de Hipertexto, es decir, la asignación de un texto específico para poder
hallar rápidamente un destino en la Web.

11
Decreto 0087 de 2011. Artículo 7
12
ISO. 2016. Recuperado de: http://www.iso.org/iso/home/about.htm
13
Recuperado de: https://www.emc.com/corporate/glossary/cloud-computing-services.htm

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

10
  Proveedor: Persona Natural o Jurídica que con base en especificaciones de
alcance, tiempo y costos, suministra elementos constitutivos de los sistemas o
subsistemas de ITS

 Recovery Point Objective (RPO): RPO se refiere al volumen de datos en

riesgo de pérdida que la organización considera tolerable. Las transacciones de
cuánto tiempo se está dispuesto a perder, o a tener que reintroducir al sistema
depende del volumen de transacciones por unidad de tiempo, y de los mecanismos de
backup, pero siempre aumenta el volumen de datos ‘huérfanos’ a medida que pasa el
tiempo desde la última copia de seguridad. El RPO determina el objetivo de posible
pérdida máxima de datos introducidos desde el último backup, hasta la caída del
sistema, y no depende del tiempo de recuperación. 15

 Recovery Time Objective (RTO): 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. La respuesta
dependerá de la criticidad de cada aplicación. 16

 Relación de Luminancia: Es el equilibrio entre la salida de la luz y la reflexión

de la señal. 17

 Señales de Mensajes Variables (VMS): Señales de mensaje variable (VMS)

son dispositivos de control de tráfico utilizados para proporcionar en ruta información
al viajero. La información se muestra en tiempo real y puede ser controlada ya sea
desde un lugar remoto centralizado o localmente en el sitio. Los VMS están diseñados
para afectar el comportamiento del conductor y para mejorar la fluidez del tráfico y
operaciones. Ejemplos de información al viajero incluyen:
- Los tiempos de viaje entre los destinos conocidos
- Las condiciones de congestión a lo largo de un corredor de la autopista
- Avisos de Construcción
- Aviso de eventos especiales e instrucciones
- Horario de las operaciones de mantenimiento
- Notificación de Incidentes 18

 Servicios de Computación en la Nube (Cloud Computing Services):

Proporcionan tecnología de la información (TI) como un servicio a través de Internet o
red dedicada, con entrega bajo demanda y pago basado en el uso. Los servicios de
computación en nube van desde aplicaciones completas y plataformas de desarrollo
hasta servidores, almacenamiento y escritorios virtuales. Entre los tipos de servicio
de computación en la nube entregados internamente o por proveedores de servicios
de terceros, los más comunes son: Software como Servicio (SaaS), Infraestructura
como Servicio (IaaS) y Plataforma como Servicio (PaaS). 19

 SIG: es un software específico que permite a los usuarios crear consultas

Interactivas, integrar, analizar y representar de una forma eficiente cualquier tipo de
información geográfica referenciada asociada a un territorio, conectando mapas con
bases de datos.

15 Recuperado de: https://www.swgreenhouse.com/conceptos-de-continuidad-de-negocio/rto-rpo

16 Recuperado de: https://www.swgreenhouse.com/conceptos-de-continuidad-de-negocio/rto-rpo

17
UNE EN 12966
18
Wisconsin Department of Transportation. 2000. Recuperado de:
http://www4.uwm.edu/cuts/itsdm/chap6.pdf

19
Recuperado de: https://www.emc.com/corporate/glossary/cloud-computing-services.htm

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

11
  SiGAAE: Subsistema perteneciente al SINITT, para la Gestión de la
Autenticación de Actores Estratégicos de ITS, cuyo objetivo principal es permitir a los
actores debidamente habilitados el acceso al SINITT y a los subsistemas de gestión
de ITS.

 SiGSI: Acrónimo de Sistema de Gestión de la Seguridad de la Información. Se

refiere al proceso sistemático, documentado y conocido al interior de una
organización, con el fin de garantizar la Seguridad de la Información. De acuerdo con
el ISO 27001:2013, la Seguridad de la Información consiste en la preservación de su
confidencialidad, integridad y disponibilidad, así como de los sistemas implicados en
su tratamiento, dentro de una organización.

 SiGTrazabilidad: Subsistema para la Gestión de la Trazabilidad, el cual

almacena la información relacionada con las transacciones realizadas por los actores
estratégicos en el SiGT, SiGD y SiGUDDI.

 SiGUDDI: El SiGUDDI corresponde a la implementación de una plataforma

central que permita la consolidación de un catálogo de servicios web ofrecidos por los
diferentes subsistemas, para mejorar el acceso y consumo de los mismos por parte
de los usuarios.

 Simple Object Access Protocol (SOAP): Es un protocolo de mensaje que

permite que los programas que se ejecutan en sistemas operativos dispares (como
Windows y Linux) puedan comunicarse mediante el Protocolo de transferencia de
hipertexto (HTTP) y lenguaje de marcado extensible (XML).

 Sistema de Gestión de Seguridad de la Información (SGSI): Es un conjunto

de políticas de administración de la información. El término se denomina en inglés
"Information Security Management System" (ISMS).
El concepto clave de un SGSI es el diseño, implantación y mantenimiento de un
conjunto de procesos para gestionar eficientemente la accesibilidad de la información,
buscando asegurar la confidencialidad, integridad y disponibilidad de los activos de
información minimizando a la vez los riesgos de seguridad de la información. Como
todo proceso de gestión, un SGSI debe seguir siendo eficiente durante un largo
tiempo, adaptándose a los cambios internos de la organización así como los externos
del entorno. 20

 Sistema inteligente Nacional para la Infraestructura, el Tránsito y el

Transporte (SINITT): El objetivo del SINITT será consolidar y proveer la información
que suministren los subsistemas de gestión que lo integren, así como la
interoperabilidad de los ITS que se implementen a nivel Nacional, cumpliendo con los
principios de excelencia en el servicio al ciudadano, apertura y reutilización de datos
públicos, estandarización, interoperabilidad, neutralidad tecnológica, innovación y
colaboración, de conformidad con el Capítulo 1 del Título 9 de la Parte 2 del Decreto
1078 de 2015, así como las demás disposiciones que lo modifiquen, adicionen o
sustituyan.21

 Sistemas Inteligentes de Transporte (SIT): “Son un conjunto de soluciones

tecnológicas, informáticas y de telecomunicaciones que se encuentran en dispositivos
portátiles o móviles, dispositivos a bordo o en equipos instalados en la infraestructura,
diseñadas para apoyar la organización, eficiencia, seguridad, comodidad,
accesibilidad y sostenibilidad de la infraestructura, el tránsito, el transporte y la
movilidad en general.” 22

20
2013. Recuperado de: http://blog.firma-e.com/que-es-un-sgsi-sistema-de-gestion-de-seguridad-de-la-
informacion/
21
Decreto Nacional 079 de 2015. Numeral 6 Artículo 2513
22
Decreto Nacional 2060 de 2015, Numeral 7 Artículo 2513

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

12
  Sistema Ininterrumpido de potencia (UPS): Del inglés Uninterruptible Power
Supply. Para mantener un alto nivel de calidad de energía eléctrica ininterrumpible la
fuente de alimentación (UPS) ha surgido como una alternativa potencial, la cual fue
también ampliamente aplicada para mitigar las perturbaciones inesperadas durante
las últimas Décadas. Principalmente, el UPS emplea el convertidor estático de
potencia como batería para suministrar la carga crítica. 23

 Security Assertion Markup Language (SAML): Es un estándar basado en

XML para el navegador web de sesión única y se define por el Comité Técnico de
Servicios de Seguridad de OASIS. La norma existe desde 2002, pero la mayoría de la
gente no sabe mucho acerca de ella y con razón pues SAML es complejo e
históricamente sólo las grandes empresas podrían justificar la implementación
costosa de SAML.
Todo esto está cambiando con la aparición de la computación en nube y con
proveedores de gestión de identidades basadas en la nube como OneLogin, ahora
todo el mundo puede permitirse su uso. 24

 Sistema de Gestión de Seguridad de la Información (SGSI): es un conjunto

de políticas de administración de la información. El término se denomina en inglés
"Information Security Management System" (ISMS).

 Software (SW): Se forma por el conjunto de instrucciones o programas. Los

programas son una secuencia de órdenes que se le dan a la computadora para que
haga algo. Todos los juegos de video, sistemas operativos y programas de aplicación
-como procesadores de palabras o programas para Internet son software. 25

 Software como Servicio (Software as a Services - SaaS): Software que se

ejecuta y gestiona en computadoras de propiedad de un proveedor de SaaS, al cual
tienen acceso los usuarios de forma remota, a través de Internet pública o canales
dedicados, y generalmente se ofrece en una suscripción mensual o anual. 26

 Tecnologías de la Información (TI): "El conjunto de procesos y productos

derivados de las nuevas herramientas (hardware y software), soportes de la
información y canales de comunicación relacionados con el almacenamiento,
procesamiento y transmisión digitalizados de la información" (González Gisbert).

Si nos ceñimos a la definición de tecnología que hacen Harvey Brooks y Daniel Bell:
"el uso de un conocimiento científico para especificar modos de hacer cosas de un
modo reproducible", podríamos decir que las Tecnologías de Información, más que
herramientas generadoras de productos finales, son procesos científicos cuyo
principal objetivo son la generación de conocimientos, que a la postre incidirán en los
modos de vida de las sociedades, no sólo en un ámbito técnico o especializado, sino
principalmente en la creación de nuevas formas de comunicación y convivencia
global. 27

 Transporte Intermodal: Es aquel que utiliza la combinación de dos o más

medios de transporte. En virtud de un contrato de transporte intermodal, desde un
lugar situado en un país en el que operador de transporte intermodal toma las

23 Recuperado de: IEEE transactions on power electronics, vol. 21, no. 1, january 2006
24Recuperado de: https://www.onelogin.com/saml
25
Grupo Educare. 2011. Recuperado de:
https://computacioncpc.files.wordpress.com/2011/06/teorc3ada-hardware-y-software.pdf
26
Recuperado de: https://www.emc.com/corporate/glossary/cloud-computing-services.htm
27
Tecnología al Instante. 2007. Recuperado de:
http://tecnologiahechapalabra.com/tecnologia/glosario_tecnico/articulo.asp?i=875

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

13
mercancías bajo su custodia hasta otro lugar designado para su entrega situado en un
país diferente.
El transporte intermodal permite la combinación de los regímenes de carga completa
y grupaje, con el objetivo de ofrecer a los cargadores una mayor posibilidad de
combinaciones. Con ello se consigue atender la demanda de aquellos exportadores
que no necesitan de la totalidad de espacio de un contenedor.

 Transportation Research Board (TRB): La misión de la Transportation

Research Board (TRB) es promover la innovación y el progreso en el transporte a
través de la investigación. En un establecimiento de objetivos e interdisciplinario, TRB
facilita el intercambio de información sobre la práctica y la política de transporte por
investigadores y profesionales; estimula servicios de gestión de investigación de
investigación y ofertas que promueven la excelencia técnica; proporciona
asesoramiento sobre políticas y programas de transporte; y difunde los resultados en
términos generales y alentó a su aplicación. 28

 Touch Screen: Pantalla táctil es una pantalla que también sirve como un
dispositivo de entrada. Algunas pantallas táctiles requieren una pluma patentada para
la entrada, aunque la mayoría de las pantallas táctiles modernas detectan el tacto
humano. Dado que los dispositivos con pantalla táctil aceptan la entrada directamente
a través de la pantalla, que no requieren dispositivos de entrada externos, tales como
ratones y teclados. Esto hace que las pantallas táctiles ideal para cabinas con
computadoras, así como dispositivos portátiles, tales como tabletas y teléfonos
inteligentes. 29

 Unidad Terminal Remota (RTU): Es un dispositivo multifuncional utilizado

para el seguimiento y control de diversos dispositivos y sistemas para la
automatización remota. Por lo general se implementa en un entorno industrial y sirve
a un propósito similar a los circuitos lógicos programables (PLCs) pero en un grado
más alto. La RTU se considera un equipo autónomo ya que tiene todas las piezas
básicas que, en conjunto, definen un ordenador: un procesador, memoria y
almacenamiento. Debido a esto, se puede utilizar como un controlador inteligente o
controlador maestro para otros dispositivos que, juntos, automatizar un proceso tal
como una parte de una línea de montaje. 30

 Universal Description, Discovery, and Integration (UDDI): Es un registro

basado en XML de la lista de negocios en internet. Su objetivo es simplificar las
transacciones en línea, permitiendo a las empresas encontrarse unas a otras en la
Web y hacer que sus sistemas sean interoperables para el comercio electrónico.
UDDI es a menudo comparado con las páginas blancas, amarillas y verdes de una
guía telefónica. El proyecto permite a las empresas la lista por nombre, producto,
ubicación, o los servicios web que ofrecen. 31

 Validación: “Proceso de evaluación de productos que se realiza al final de la

etapa de desarrollo para determinar si el producto cumple con las expectativas y
requisitos del propietario del sistema”32 el propietario del sistema debe cumplir con las
expectativas y requisitos del Ministerio de Transporte plasmada en el siguiente
documento.

 Verificación: “Proceso de evaluación de productos que se realiza durante la

etapa de desarrollo o construcción para determinar si el producto cumple con los
requisitos especificados”3.

28
US Travel Association. 2016. Recuperado de: http://www.trb.org/AboutTRB/AboutTRB.aspx

29 TechTerms. 2016. Recuperado de: http://techterms.com/definition/touchscreen

30
Techopedia. 2016. Recuperado de: https://www.techopedia.com/definition/1033/remote-terminal-unit-rtu
31
Recuperado de: http://searchsoa.techtarget.com/definition/UDDI
32
"Systems Engineering for Intelligent Transportation Systems". Publicado por el US Department of Transportation en
2007.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

14
  Virtualización: La virtualización es el proceso de crear una representación
basada en software (o virtual), en lugar de una física. La virtualización se puede
aplicar a servidores, aplicaciones, almacenamiento y redes, y es la manera más eficaz
de reducir los costos de TI y aumentar la eficiencia y la agilidad de los negocios de
cualquier tamaño. 33

 Web Services Interoperatibility (WS-I): Define buenas prácticas para grupos

seleccionados de normas, a través de plataformas, sistemas operativos y lenguajes
de programación. WS-I comprende una comunidad diversa de líderes de servicios
Web a partir de una amplia gama de organizaciones. Los perfiles y las herramientas
de prueba están disponibles para su uso por la comunidad para ayudar en el
desarrollo y despliegue de servicios Web interoperables. 34

 Web Services Description Language (WSDL): Es un formato XML para

describir servicios de red como un conjunto de puntos finales operando sobre
mensajes que contienen ya sea información orientada a documentos o información
orientada al procedimiento. Las operaciones y los mensajes se describen de forma
abstracta y, a continuación, se enlazan a un protocolo concreto de red y un formato de
mensaje para definir un punto final. 35

 Web Services Security Maintenance (WSS-M): Describe las mejoras a los

mensajes de SOAP con el fin de proporcionar una calidad de protección a través de
integridad de mensajes y autenticación de mensajes individual. Estos mecanismos se
pueden utilizar para adaptarse a una amplia variedad de modelos de seguridad y
tecnologías de cifrado. 36

CAPÍTULO 2 - CONCEPTO JURÍDICO

4. MECANISMO PARA LA IMPLEMENTACIÓN

El Ministerio de Transporte, como máxima autoridad en materia de tránsito y

transporte en el país (Ley 105 de 1993), es responsable de expedir la regulación del

33
Recuperado de: http://www.vmware.com/latam/solutions/virtualization.html

34
Recuperado de: http://www.oasis-ws-i.org/about
35
Recuperado de: https://www.w3.org/TR/wsdl
36
Recuperado de: http://www.service-architecture.com/articles/web-services/web_services_security_wss.html

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

15
sector y en virtud de lo dispuesto en el Decreto 87 de 2011, es competente para
coordinar con las entidades del sector y demás entidades pertinentes, las políticas
públicas, estrategias y la recomendación de los ajustes necesarios. De igual forma el
artículo 288 de la constitución política dispone que las competencias atribuidas a los
distintos entes territoriales serán conforme a los principios de coordinación,
concurrencia y subsidiaridad en los términos que establezca la ley, de igual forma y
teniendo en cuenta el fallo 6245 del 2001 donde el consejo de estado dispuso lo
siguiente: “que si bien es cierto que las entidades territoriales tienen autonomía frente
al manejo de los temas de su interés ello no impide que tienen que estar sujetos al
cumplimiento de requerimientos orientados a facilitar la ejecución de políticas que
sobre el tránsito y seguridad vial fije el Ministerio de Transporte dada la competencia
que le otorga la ley en tal sentido.”

El artículo tercero de la ley 769 de 2002 define como autoridad de tránsito en su orden
las siguientes:

 El Ministerio de Transporte
 Los Gobernadores y Alcaldes
 Los organismos de tránsito de carácter departamental, municipal y distrital.
 La Policía Nacional en sus cuerpos especializados de policía de tránsito
urbano y policía de carreteras
 Los inspectores de policía, transito, corregidores o quien haga sus veces
 La superintendencia de Puertos y Transporte
 Las fuerzas militares
 Los agentes de tránsito y transporte

Por lo anterior, el Ministerio de Transporte es competente para emitir una regulación

como la que nos ocupa, frente a todas las autoridades señaladas.

En el caso de las entidades nacionales adscritas al Ministerio de Transporte,

involucraras en el módulo ITS, esto es la Agencia Nacional de Infraestructura, INVIAS
y la Agencia Nacional de Seguridad Vial. La obligación de acatamiento de las
directrices dadas por el Ministerio de Transporte es aún mayor, si se tiene en cuenta
que dichas entidades, además, están sometidas a un control de tutela, en los términos
expuestos en la Ley 489 de 1998.

El artículo 44 y el 61 de la Ley 489, dispone de la orientación en las funciones a cargo

de las entidades que conforman el sector administrativo.

Estas competencias, acompañadas de las otorgadas por el Decreto 2060 de 2015, en

materia de regulación de sistemas inteligentes de tránsito y transporte en el país, le
permiten al Ministerio de Transporte fijar, mediante un acto administrativo, los
requisitos mínimos para la adquisición y operación de las señales de mensajería
variable, a nivel nacional y local, así como los mecanismos de gestión y seguimiento,
para garantizar el máximo aprovechamiento de este tipo de tecnología en la seguridad
vial.

Por lo expuesto, se considera que el Ministerio de Transporte está facultado para

establecer las características técnicas y funcionales de las señales de mensajería
variable, en el marco de los sistemas inteligentes de transporte, y en tal sentido el
mecanismo jurídico idóneo para garantizar el cumplimiento de los objetivos del
módulo es el acto administrativo, toda vez que, a través de éste, se puede expresar la
voluntad del Ministerio de Transporte, tendiente a generar obligaciones a cargo de las
entidades del sector, tanto nacionales como territoriales37.

En ese orden de ideas, el mecanismo jurídico para la implementación del módulo ITS
de señales de mensajería variable es un acto administrativo, concretamente una

37 La Corte Constitucional, en la Sentencia C-1436 de 2000, define el acto administrativo como

“la manifestación de la voluntad de la administración, tendiente a producir efectos jurídicos (…)”

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

16
Resolución expedida por el Ministerio de Transporte, la cual sería aplicable a todas
las autoridades de tránsito del país, que operen o adquieran, directa o indirectamente
equipos VMS; así como a la Agencia Nacional de Seguridad Vial, la Agencia Nacional
de Infraestructura, al Instituto Nacional de Vías, a las dependencias del Ministerio de
Transporte y a las secretarías de infraestructura y tránsito o sus equivalentes en los
Departamentos, Distritos y municipios del país, así como a cualquier administrador de
la red vial nacional, departamental o municipal.

5. CONTENIDO DEL ACTO ADMINISTRATIVO

El acto administrativo debe plantear tres grandes aspectos:

 Características técnicas y funcionales de los paneles de mensajería variable.

 Establecer una plataforma que fortalezca el nivel de información del gobierno
nacional frente a todos los equipos existentes y su gestión.
 Fijar un mecanismo de estandarización de los mensajes que se desplieguen
en la vía.

De igual forma, este contenido debe llevar un mecanismo de seguimiento al

cumplimiento de las obligaciones que lo harán en conjunto entre el Ministerio del
Transporte y la Agencia Nacional de Seguridad Vial.

5.1. CARACTERÍSTICAS TÉCNICAS Y FUNCIONALES DE LOS PANELES DE

MENSAJERÍA VARIABLE

Para superar dicha problemática, el proyecto de Resolución propuesto define y unifica

las características técnicas y funcionales de los paneles de mensajería variable, en
función de las necesidades del corredor vial y de las condiciones de operación a
informar. Dichas características se incorporan al acto administrativo mediante anexos
técnicos que hacen parte integral del documento.

Siendo el Ministerio de Transporte competente para establecer requisitos técnicos en

materia de señalización vial y de Sistemas Inteligentes de Transporte “ITS” siendo
jurídicamente valida la fijación de políticas públicas en tal sentido.

5.2. PLATAFORMA TECNOLÓGICA

El ministerio deberá contar con una plataforma tecnológica que permita registrar los
paneles de mensajería variable y la mensajería que garanticen un enlace simultáneo
de equipos VMS y la recepción de datos en la red vial. Esta plataforma deberá estar
articulada con las definiciones funcionales y técnicas del SINITT.

Las entidades deberán registrar los equipos y su mensajería en la plataforma

dispuesta por el Ministerio de Transporte. Antes de iniciar su operación, ya sea
directamente o a través de sus concesionarios viales, en los casos en que aplique.
Así mismo deberán reportar información periódica sobre los equipos y disponer del
esquema de interoperabilidad basado en servicios para envío simultáneo de mensajes
de interés nacional propuesto.

En los contratos de suministro e instalación de equipos VMS que se suscriban en

adelante, se deberá incorporar obligaciones que permitan su integración e
interoperabilidad con la plataforma que se desarrolle en el marco del SiGVMS y por
consiguiente del SINITT.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

17
Lo anterior permite que el Ministerio de Transporte pueda requerir el registro de los
equipos de mensajería variable y reporte de información asociada, no solo por
tratarse de temas que son de su competencia, sino también en virtud de un mandato
constitucional de carácter general citado.

Así las cosas, y teniendo en cuenta que esta exigencia plantea actividades
adicionales para las entidades y proveedores, se propone que sea una obligación solo
para los equipos adquiridos a partir de la adopción del acto administrativo. Los
equipos que se hayan adquirido previamente, podrán migrar paulatinamente y su
registro será obligatorio solo en los casos en que la entidad propietaria desee acceder
a los servicios del SINITT.

Por otra parte, las entidades que necesiten realizar gestión de equipos VMS desde un
Centro de Control “CCO” deberán cumplir con las especificaciones técnicas mínimas
de una plataforma de software para la gestión remota de equipos VMS, según los
requisitos establecidos en un tercer anexo técnico, con el fin de garantizar una
estandarización mínima.

5.3. MENSAJERÍA

Según el Manual de Señalización Vial, Resolución 1885 de 2015, las señales de

mensajería variable se definen como un “dispositivo de control de tránsito cuyo
mensaje puede ser cambiado manual, eléctrica, mecánica o electrónicamente, con el
fin de proporcionar a los conductores, en tiempo real, información pertinente a su
viaje”.

Los mensajes a desplegar en los paneles de mensajería variable, deben cumplir con
los lineamientos contemplados en dicho Manual.

En este punto vale la pena mencionar que se entenderá por evento de carácter
nacional o regional, el contemplado como de afectación grave en la Resolución 0761
de 2013, “Por la cual se crea el Comité Interinstitucional para la adopción y ejecución
del Plan Estratégico Integral de Seguridad y Movilidad” expedida por el Ministerio de
Transporte, la cual dispone lo siguiente: “Novedad afectación extensa que imposibilita
el tránsito en la vía durante un período extenso. Igualmente cuando su magnitud e
impacto en relación a la cantidad de víctimas, las pérdidas materiales y los problemas
de orden público, que son o pueden llegar a ser de enorme magnitud, lo cual hace
necesaria la organización, coordinación, y asignación de los recursos a gran escala y
en forma inmediata de las instituciones de atención de emergencias y entidades del
estado”

5.4. GESTIÓN Y SEGUIMIENTO

Para facilitar la gestión y seguimiento del módulo ITS de mensajería variable, se

propone un trabajo conjunto entre el Ministerio de Transporte y la Agencia Nacional
de Seguridad Vial, la cual, según lo dispuesto en el Decreto 1702 de 2013, es la
máxima autoridad para la aplicación de las políticas y medidas de seguridad vial
nacional y su misión es prevenir y reducir los accidentes de tránsito.

De conformidad con lo señalado en el Decreto 1702 de 2013, la Agencia tiene como

objeto, la planificación, articulación y gestión de la seguridad vial del país y ser el
soporte institucional y de coordinación para la ejecución.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

18
6. REGIMEN SANCIONATORIO

Frente a comportamientos contrarios al marco jurídico vigente se propone hacer uso

de las sanciones ya existentes frente a dos casos concretos:

El primer comportamiento a sancionar seria en la falta de suministro, o suministro

inoportuno o inadecuado de la información requerida y el segundo un tratamiento
dañino al sistema de información para el primer caso el artículo 31 de la ley 1755 de
2015 establece la falta de atención a las peticiones y a los términos para resolver
constituyen una falta disciplinaria al servidor público y dará lugar a las sanciones
como lo dispone la ley 734 del 2000.

Sobre el cumplimiento del deber de suministrar información impone como obligación

de los destinatarios del acto administrativo propuesto, que la información requerida
por el Ministerio de Transporte en el registro de equipos VMS se efectúen en los
términos allí establecidos.

En caso de desatención de las obligaciones establecidas en el acto administrativo, el

Ministerio de Transporte o la Agencia de Seguridad vial, deberán informar a la entidad
competente. Lo anterior, en virtud de lo previsto en el artículo 70 de la Ley 734 de
2000. La determinación de la competencia, se efectúa teniendo en cuenta la calidad
del sujeto disciplinable, la naturaleza del hecho, el territorio donde se cometió la falta,
el factor funcional y el de conexidad, según los criterios establecidos en el Título
segundo de la Ley 734.

Las sanciones aquí señaladas, se efectuarían sin perjuicio de las demás que pudieran
imponerse, de conformidad con la gravedad del hecho detectado, como por ejemplo
las existentes en materia penal, en lo relativo a falsedad, utilización indebida de
información, violación de comunicaciones y acceso abusivo a sistemas informáticos.

CAPÍTULO 3 - CONCEPTO DE OPERACIÓN

7. GENERALIDADES

En el marco de las estrategias del Plan Nacional de Desarrollo “Todos por un Nuevo
País” 2014-2018, el Ministerio de Transporte es la entidad encargada de formular la
política pública de los Sistemas Inteligentes para la Infraestructura, el Tránsito y el
Transporte y de regular su procedimiento e implementación; en este contexto, el
equipo de trabajo de Sistemas Inteligentes de Transporte del Ministerio, adelanta la
los procesos generales de despliegue de política pública de elementos tecnológicos
de ITS y servicios ITS y que para este caso, son los Sistemas de Señales de Mensaje
Variable.

Este documento presenta el anexo técnico que aborda los aspectos tecnológicos del
elemento ITS denominado Sistema de Mensaje variable y que tiene como fin, desde
el punto de vista de la norma ISO 14813-1 de 2015 centrada en dominios de servicios
ITS, el despliegue y difusión de información en campo, es decir, a lo largo de la
infraestructura de transporte. Este elemento ITS puede apoyar diversos servicios ITS
ya sea con información general antes del viaje, en el viaje y después del viaje, todo
esto, ayuda a mejorar, planear y gestionar de manera más adecuada y ágil las
estrategias de movilidad en las ciudades o a lo largo de las vías.

El presente documento está dividido en cuatro capítulos. Cada uno tiene su propia
organización, incluyendo las generalidades, cuerpo y la descripción de su validación o

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

19
verificación, según corresponda por capítulo. El primer capítulo contempla el
Concepto de Operación del sistema y para el elemento ITS objeto de este anexo, es
decir, Sistema de Mensaje Variable. El segundo capítulo expone la Especificación de
Requisitos de Hardware (ERH) y tiene inmerso el plan de verificación. El tercer
capítulo aborda la Especificación de requisitos de software y tiene inmerso el plan de
verificación de los requisitos definidos, así como el componente de seguridad. Este
documento presenta también la definición del sistema SIGVMS, Sistema de
información de gestión de Sistemas de Mensajería Variable y los requisitos que deben
tener este para su despliegue e interoperabilidad a nivel nacional.

Se destaca que la metodología utilizada en la realización de este documento tiene de

base el estándar internacional para el desarrollo de sistemas 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 v3.0” producido por el
Departamento de Transporte (DoT, Federal Highway Administration) de Estados
Unidos. Este modelo ha sido utilizado por diferentes autoridades de tránsito a nivel
internacional.
8. DOCUMENTOS DE REFERENCIA

El Ministerio de Transporte en el proceso de desarrollo de los Sistemas Inteligentes

de Transporte contemplados a partir del artículo 84 de la ley 1450 de 2011 y de
acuerdo a lo contemplado en su Plan de Tecnologías y Comunicaciones define
lineamientos básicos para lograr el despliegue de los diferentes sistemas que se
implementen de una manera coordinada, armoniosa, eficiente e integrada. Para ello,
se tiene de referencia el comité técnico (TC) 204 de Sistemas Inteligentes de
transporte de la ISO, el cual es responsable de la estandarización de información,
comunicaciones y sistemas de control en el campo de transporte terrestre urbano y
rural, incluyendo aspectos intermodal y multimodal de los mismos, información al
viajero, gestión de tráfico, transporte público, transporte comercial, servicios de
emergencia y servicios comerciales en el campo de los sistemas inteligente de
transporte (ITS). Asimismo, con base en el levantamiento de información llevado a
cabo en materia de VMS por parte del Ministerio de Transporte, así como también con
la identificación de las mejores prácticas aplicadas por las implementaciones de
referencias internacionales, se describen entre otros algunos estándares y normas
internacionales que de alguna forma también impactan y apoyan la construcción de
esta política pública.

 EN 12966:2015, Señalización vertical en carretera, Paneles de Mensaje

Variable38
Norma europea que ofrece especificaciones para dos tipos de Paneles de Mensaje
Variable PMV: continuos y discontinuos. Los PMV continuos muestran señales del
tipo de señales fijas definidas en la Norma EN 12899. Los PMV discontinuos usan
elementos luminosos para mostrar mensajes diferentes en una sola cara de la señal.
Esta norma europea cubre PMV móviles, temporales y permanentes instalados y
usados en áreas de circulación, de la red pública y privada, incluyendo túneles, guía,
advertencia y/o dirección del tráfico. Los módulos de ensayo se utilizan para
demostrar el cumplimiento de los requisitos.

38UNE-EN 12966, Señalización vertical en carretera, Paneles de mensaje variable, UNE-EN 12966
2015.pdf

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

20
Esta norma europea especifica características visuales y físicas de los PMV, así como
sus aspectos de durabilidad. También proporciona los requisitos pertinentes y
métodos de ensayo, evaluación y verificación de constancia de las prestaciones
(EVCP) y marcado.
Esta norma europea no cubre:
o Los pórticos, banderolas y cimientos de las señales;
o Las cabezas de semáforo;
o El tamaño y la forma de los mensajes de las señales de mensaje
variable;
o Las unidades de control y seguimiento a menos que estén dentro del
módulo de ensayo;
o El control de la luminancia de la señal.


ISO 14813-1:2015 Modelo de Referencia para arquitecturas del sector
ITS39, apartado 1 dominio de servicios ITS, grupos de servicios y
servicios
Proporciona una definición de los dominios de servicios ITS que pueden desplegarse
en un país y siendo el caso puntual para los Sistemas de Mensaje Variable que son
parte del Dominio de información al viajero ITS”.


ISO 14813-5:2010 Modelo de Referencia para arquitecturas del sector
ITS40, apartado 5 requisitos para describir una arquitectura ITS
Proporciona los requisitos para el diseño y documentación de la arquitectura de los
sistemas inteligentes de transporte, este estándar se toma de referencia por el enlace
de este subsistema con el Sistema Inteligente Nacional para la Infraestructura,
Tránsito y Transporte ya que en su contexto el estándar da las definiciones de los
términos que deben ser usados cuando se documente o referencie aspectos de
descripción de arquitectura en esos estándares.


ISO 15784-2:2015 Intercambio de datos que involucran módulos de
comunicaciones ubicados en la vía, apartado 2 comunicaciones
dispositivo en campo a Centro de Control usando SNMP41
Esta parte de la norma ISO 15784 especifica un mecanismo para intercambiar datos y
mensajes en los siguientes casos:
o Entre un centro de gestión de tráfico y los módulos de carretera para la
gestión del tráfico;
o Entre los módulos de carretera utilizados para la gestión del tráfico.

Es complementaria a la norma ISO 15784-3, pero utiliza una capa de aplicación

diferente para los intercambios de información para configurar, controlar y supervisar
los módulos de control de tráfico en carretera de campo. Así como la norma
ISO15784-3 está basada en los estándares de DATEX (esquema de intercambio de
información).

Se resalta que esta norma se apoya en esquemas utilizados para neutralidad

tecnológica por lo que es similar a la norma NTCIP 2301. Esta parte del estándar

39 Catálogo de estándares del Comité Técnico 204 de la ISO, 2016. Recuperado de:

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc_browse.htm?commid=54706
40 Ibídem
41Estándar Internacional ISO 15784 Intercambio de datos que involucran módulos de comunicaciones
ubicados en la vía, 12.5.1 Apartado 2 comunicación dispositivo en campo a Centro de Control usando
SNMP, ISO 15784-2 2015 first ed.pdf

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

21
15784 permitirá el despliegue de sistemas abiertos usando dispositivos de muchos
fabricantes y proporcionado una gran variedad de servicios en un ambiente de red
compartida. Con la utilización de este estándar, los módulos ubicados a lo largo de la
carretera tienden a ser interoperables entre vendedores y variedad de vendedores.

 Especificación Técnica CEN 16157-4:2014 DATEX II Especificaciones de

intercambio de datos para información y gestión de tráfico, apartado 4
Publicación VMS42
Define los componentes de facetas que soportan el intercambio y el uso compartido
de datos e información en lo que respecta al tráfico y al viajero. Los componentes
facets incluyen el marco y el contexto para el intercambio, el enfoque de modelado, el
contenido de los datos, la estructura de datos y sus relaciones y la especificación de
Comunicaciones. El estándar recoge especificaciones que son aplicables a:
información de tráfico y al viajero que es relevante para las redes de carreteras (no
urbano y urbano); información de transporte público que es de interés directo para el
uso de una red de carreteras (por ejemplo, enlace por carretera a través de tren o
ferry). Esta especificación técnica establece para el intercambio de datos entre dos
instancias de los siguientes actores: Centros de Información de Tráfico (TIC); Centros
de Control de Tráfico (TCCs); proveedores de servicios (SP). El uso de esta
especificación técnica puede ser aplicable para su uso por otros actores. En esencia
el estándar recoge los siguientes tipos de contenido de información:
o Información de eventos de tráfico por carretera, situaciones
programadas e imprevistas, tanto en la red de carreteras y en el medio
ambiente circundante; acciones iniciadas por el operador; datos de
medición de tráfico, datos de estado y tiempo de viaje; información
relevante para los usuarios de la carretera, incluyendo el clima y el
medio ambiente de los viajes; Información de gestión del tráfico por
carretera y las instrucciones relacionadas al uso de la red de
carreteras.

Esta parte de la serie CEN / TS 16157 especifica las estructuras de información,

relaciones, funciones, atributos y tipos de datos asociados necesarios para la
publicación de información de la muestra del mensaje variable dentro del marco Datex
II. Esto se especifica en dos partes, un sub modelo publicación VMS DATEX II que
apoya el intercambio de contenido gráfico y textual de uno o varios VMS más
cualquier información sobre el estado de la configuración de equipos que ayudan a la
comprensión del contenido informativo; y un sub modelo de tabla de publicación VMS
que apoya el intercambio ocasional de tablas que contienen información de referencia
general estática sobre el VMS desplegado que permiten tener referencias posteriores
a los VMS. Estas publicaciones no estén destinadas a apoyar el control o la
configuración de los equipos VMS.

 Especificación Técnica ISO/TS 14823, Información de tráfico y Viaje –

Mensajes a través de los medios de difusión estacionaria independiente
– diccionario de dato gráfico para sistemas de difusión de información
antes y durante el viaje

Estándar asociado a sistema de códigos estandarizados para señales existentes y

pictogramas usados para entregar información al viajero y de tráfico. El sistema de
codificación puede ser usado para establecer mensajes a ser manejados por los
42 Especificación Técnica CEN 16157 DATEX II Especificaciones de intercambio de datos para
información y gestión de tráfico, Apartado 4 Publicación VMS, Ratificación de documentos europeos
Junio de 2014 CENTS 16157-4 2.pdf

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

22
respectivos sistemas de medios, mensajes gráficos en unidades a bordo, e
información del sistema de medios en sistemas de difusión de información de tráfico y
al viajero.

 NTCIP 1201:2005, Definición de objetos globales43

Los mensajes entre el Centro de Gestión de Transporte CGT y los dispositivos de
campo se lleva a cabo mediante el uso de los servicios de la capa de aplicación
NTCIP para transmitir las solicitudes de acceso o modificar los valores almacenados
en un dispositivo dado; estos valores se conocen como objetos. El propósito de esta
publicación es identificar y definir estas definiciones de objetos que pueden ser
soportados por múltiples tipos de dispositivos (por ejemplo, controladores de señal de
accionamiento y señales de mensaje variable). La agrupación de objetos de un tipo de
dispositivo dado se lleva a cabo en el estándar de definición de objetos de dispositivo
específico.

NTCIP 1203:2011, Definición de objetos para señales de mensaje

dinámico (DMS)44
NTCIP 1203 v03 especifica la interfaz lógica entre las señales de Mensaje dinámico
(DMS) y el sistema host que las controlan (denominado comúnmente como sistema
central). NTCIP 1203 describe la funcionalidad DMS soportada en términos de
necesidades y requisitos de los usuarios; sin embargo, la naturaleza de la interfaz
está determinada en parte por el carácter operativo de los dispositivos que están
siendo controlado, por lo tanto NTCIP 1203 v03 aborda en algunos casos estas
cuestiones operativas.

NTCIP 1203 asume un modelo de operación de DMS en la que los controladores de

DMS poseen inteligencia y los datos utilizados para el despliegue de mensajes y la
configuración de señales reside en el controlador del DMS. En particular, los
elementos de datos tales como fuentes, gráficos, texto del mensaje, calendarios
basados en el tiempo, y así sucesivamente pueden residir en el controlador del DMS,
y el controlador presenta los mensajes en la pantalla de la señal con base en estos
datos. Se hace referencia al estado del controlador de DMS, el control, y los datos de
configuración como base de datos del controlador; NTCIP 1203 especifica las
interfaces mediante las cuales estos datos pueden ser manipulados desde el sistema
central. No hay comandos imperativos como “Despliegue un mensaje” o “Informe el
estado”; el sistema central controla el comportamiento de la DMS simplemente a
través de las consultas y los cambios a la base de datos del controlador utilizando un
conjunto de protocolos de comunicación apropiados para la infraestructura de
comunicaciones subyacente.

 NEMA TS 4-2005
El estándar define las normas de hardware para Señales de mensajes variables, con
requisitos NTCIP, el cual fue desarrollado como guía en el diseño y la aplicación de
equipos de mensaje dinámica de tráfico, para que puedan ser instalados con
seguridad y con características operativas basado en la tecnología actualizada. La
publicación de Normas TS 4 tiene por objeto reducir los riesgos para las personas y

43 NTCIP 1201:2005, Definición de objetos globales, Recuperado de:

https://www.ntcip.org/library/documents/pdf/1201v0232f.pdf
44 NTCIP 1203, Definición de objetos para señales de mensaje dinámico (DMS). 2011. Recuperado de:

http://www.ntcip.org/library/documents/pdf/1203v03-04_part_1_dms2011.pdf

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

23
los bienes partiendo de un equipo de tráfico de mensaje correctamente seleccionado
e instalado de conformidad con los requisitos del documento.

Un objetivo de la norma es proporcionar al usuario equipos de mensajes variables

seguros, fiables, funcionales y de fácil mantenimiento. Los requisitos de la norma se
han desarrollado por consenso de la industria, teniendo en cuenta las necesidades
actuales de los usuarios, las tecnologías comerciales disponibles, la investigación en
ingeniería, las aplicaciones de ingeniería de tráfico, los factores de la ingeniería
humana, y los criterios de ingeniería.

Además, también define el hardware mínimo y las características funcionales de

Señalización variable controladas electrónicamente utilizados para la presentación de
mensajes para la visualización de los viajeros. Los apartes principales de la norma
son los siguientes: Requerimientos medioambientales, Construcción mecánica de la
señal, Interface de control de la señal, Propiedades de la pantalla, Componentes
ópticos, Gabinete de control de la Señal de Mensajes Variables, Electrónica y
electricidad, Monitoreo del rendimiento, Requerimientos de energía.

 ANSI/IEC 60529:2004 Grados de protección de recintos (Código IP)

Esta norma describe un sistema para clasificación de los grados de protección
proporcionada por un equipo eléctrico dentro de un recinto bajo dos condiciones:
primero la protección de las personas contra el acceso a partes peligrosas y
protección del material contra la penetración de cuerpos sólidos extraños como el
polvo y segundo la entrada de agua. El grado de protección frente a estas dos
condiciones se denomina como el código IP.

 NEMA 250-2014 – Clasificación de recinto45

Esta norma cubre las envolventes de dispositivos eléctricos con mediciones no
superiores a 1000 voltios y destinado a ser instalado, la Asociación Nacional de
Fabricantes Eléctricos (NEMA) define los estándares utilizados en América del Norte
para las diferentes calidades de los recintos eléctricos que se utilizan generalmente
en aplicaciones industriales. Cada clasificación tiene un índice de protección contra el
acceso peligroso, condiciones ambientales. Un gabinete con índices NEMA podría ser
calificado para proporcionar protección contra los riesgos ambientales como el agua,
el polvo, aceite o refrigerante, agentes corrosivos como el acetileno o la gasolina. A
continuación se presenta la lista de los recintos definidos en la clasificación NEMA:

 Lugares no peligrosos (sin clasificar):

o Recintos para lugares interiores, tipos 1, 2, 5, 12, 12 K y 13; y,

o Recintos para lugares interiores y exteriores, tipos 3, 3X, 3R, 3RX, 3S, 3SX, 4,
4X, 6, y 6P.
 Lugares peligrosos (clasificados):

o Recintos para lugares interiores, tipos 7 y 9;

o Recintos para lugares interiores y exteriores, tipos 8; y,
o Recintos para aplicaciones de minería, tipo 10.

TIPO NEMA DEFINICIÓN

1 Propósito general. Protege contra el polvo, la luz y las salpicaduras

45 Norma NEMA 250-2014, recuperado de:

https://www.nema.org/Standards/ComplimentaryDocuments/NEMA%20250-2014-contents-and-scope.pdf

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

24
 indirectas, utilizar en interiores y en condiciones atmosféricas
normales.
2 Hermético. Similar al tipo 1, pero con la adición de escudos de goteo.
Resistente al clima. Protege contra suciedad y el polvo arrastrado por
el viento, contra los riesgos meteorológicos como la lluvia, el
3 aguanieve y la nieve, y no está dañado por la formación de hielo. Se
usa al aire libre en barcos, muelles, en los trabajos de construcción, y
en los túneles y pasos subterráneos.
Como 3, pero omite la protección contra el polvo arrastrado por el
3R
viento.
3S Como 3, pero también operable cuando hay carga de hielo.
X indica protección contra la corrosión; comúnmente usado cerca del
3X, 3RX, 3SX
agua salada.
Estanco. Debe excluir al menos 65 GPM de agua de 1
pulgada. Boquilla de entrega desde una distancia no inferior a 10 pies
4 y 4X durante 5 minutos. Se usa al aire libre en muelles de barcos, en las
lecherías y en cervecerías. X (como 4X) indica resistencia a la
corrosión adicional.
Estanco de polvo. Provista de juntas o equivalente para excluir el
5
polvo; utilizado en fábricas de acero y plantas de cemento.
Sumergible. Diseño depende de las condiciones específicas de
presión y el tiempo; sumergible en agua o aceite; utilizados en las
6 y 6P canteras, minas y pozos de registro. 6 está temporalmente
sumergible, resistencia 6P para inmersión ocasional prolongada. No
están destinadas a la inmersión continua.
Certificado y etiquetado para su uso en áreas con condiciones
peligrosas específicas: para uso en interiores en la Clase I, Grupos A,
7
B, C, D y entornos como se define en las normas de la NFPA como el
NEC.
Certificado y etiquetado para su uso en áreas con condiciones
peligrosas específicas: para uso en interiores y al aire libre en lugares
8
clasificados como Clase I, Grupos A, B, C, y D como se define en las
normas de la NFPA como el NEC.
Certificado y etiquetado para su uso en áreas con condiciones
peligrosas específicas: para uso en interiores y al aire libre en lugares
9
clasificados como Clase II, Grupos E, F o G como se define en las
normas de la NFPA como el NEC.
MSHA. Cumple con los requisitos de la Administración de Seguridad y
10
Salud en las Minas, 30 CFR Parte 18 (1978).
Propósito general. Protege contra los efectos corrosivos de líquidos y
11 gases. Cumple con las pruebas de goteo y la resistencia a la
corrosión.
Propósito general. Para uso en interiores, proporciona cierta
protección contra el polvo, la suciedad, y el goteo de líquidos no
12 y 12K
corrosivos. Se reúne por goteo, el polvo y las pruebas de resistencia a
la roya.
Propósito general. Se utiliza principalmente para proporcionar
13 protección contra el polvo, pulverización de agua y refrigerantes no
corrosivos.
Tabla 1 NEMA 250-2014, Nivel De Protección Contra Agua
Fuente: https://www.nema.org/Products/Documents

 Especificación SOAP
SOAP es un protocolo ligero destinado a intercambiar información estructurada en un
entorno descentralizado y distribuido. Utiliza tecnologías XML para definir un marco
extensible de mensaje que proporciona una construcción de mensajes que pueden
ser intercambiados a través de una variedad de protocolos subyacentes. Este es
utilizado por el enfoque DATEX II y es independiente de la plataforma a utilizar.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

25
  Especificación Web Services Description Language (WSDL)
Especificación basada en XML para describir servicios web como un conjunto de
puntos finales que operan en mensajes que contienen ya sea información orientada al
procedimiento u orientada al documento.

 Especificación UDDI
Los servicios web sólo tienen sentido si los usuarios potenciales pueden encontrar
información suficiente para permitir su ejecución. El foco de Universal Description
Discovery & Integration (UDDI) es la definición de un conjunto de servicios de apoyo a
la descripción y descubrimiento


Comité Técnico OASIS para mantenimiento de Web Services Security
(WSS-M)
El objetivo de este comité técnico es llevar a cabo el mantenimiento continuo de las
Normas oasis de seguridad de servicios web y los perfiles de tokens producidos por el
comité técnico de seguridad de servicios web (WSS), que ahora está cerrado. WS-
Security es uno de los estándares de servicios web más ampliamente se utiliza junto
con SOAP.46

 Especificación Web Services Policy

WS-Policy proporciona una gramática flexible y extensible para la expresión de las
capacidades, los requisitos y las características generales de las entidades en un
sistema basado en servicios Web XML. WS-Policy define un marco y un modelo para
la expresión de estas propiedades como políticas.47


NTC-ISO-IEC 27001:2013, Tecnología de la información. Técnicas de
seguridad. Sistemas de gestión de la seguridad de la información (SGSI).
Esta norma ha sido elaborada para brindar un modelo para el establecimiento,
implementación, operación, seguimiento, revisión, mantenimiento y mejora de un
sistema de gestión de la seguridad de la información (SGSI).

ISO/IEC 27017:2015, Tecnología de la Información. Técnicas de

seguridad. Codificación de prácticas para los controles de la seguridad
de la información basados en la norma ISO/IEC 27002 para servicios en la
nube
Esta norma brinda guías para los controles de la seguridad de la información
aplicables a la prestación y uso de servicios en la nube, a través de: guías de
implementación adicionales para los controles relevantes especificados en la norma
ISO/IEC 270002; controles adicionales con guías de implementación que son
relacionadas específicamente a los servicios en la nube.

 Decreto 2573 de 2014, nuevo Decreto de Gobierno en línea GEL

Define los lineamientos, instrumentos y plazos de la estrategia de Gobierno en Línea
para garantizar el máximo aprovechamiento de las Tecnologías de la Información y
las Comunicaciones, con el fin de contribuir con la construcción de un Estado abierto,
más eficiente, más transparente y más participativo y que preste mejores servicios
con la colaboración de toda la sociedad.48

46 Comité Técnico de OASIS para mantenimiento de WSS, recuperado de: https://www.oasis-

open.org/committees/tc_home.php?wg_abbrev=wss-m
47 Especificación Web Services Policy, recuperado de: https://www.w3.org/Submission/WS-Policy/
48 Decreto 2573 de 2014. Recuperado de:

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

26
  Manual Estrategia Gobierno en línea V3.1
Este documento determina los lineamientos que deben seguir las entidades públicas y
los particulares que desempeñan funciones públicas en la implementación de la
Estrategia de Gobierno en línea en Colombia.49

 ANSI/TIA-942. Estándar de Calidad para Centros de Datos

El ANSI / TIA-942 es un estándar de calidad para centros de datos. La norma
especifica los requisitos para los centros de datos, incluidos los centros de datos
empresariales como usuario único y los centros de datos de alojamiento de Internet
con múltiples usuarios.

9. CONTEXTO
El presente capítulo describe el Concepto de Operación (ConOps) del Sistema de
Información para los Sistemas de Mensaje Variable SIGVMS. El ConOps es una
definición inicial del sistema a partir de las necesidades, expectativas y requerimientos
de los actores estratégicos (stakeholders). En el desarrollo de esta labor se
documenta la utilidad de los Sistemas de Mensaje Variable y su funcionamiento ya
que son propicios para el despliegue de información en campo en las condiciones
antes del viaje, en el viaje y después del viaje lo que se concibe, como servicios ITS
de información al viajero. Para poder partir de la normatividad existente y de los
planes y políticas de los actores estratégicos gubernamentales; y se especifica la
forma en la que el sistema cumplirá con las necesidades y expectativas de los actores
estratégicos, a su vez, el documento contempla más adelante los parámetros técnicos
mínimos que se deben tener en encueta para su despliegue.

10. ALCANCE
Esta sección describe el alcance del documento, el cual contiene la especificación de
requisitos de hardware y software del módulo ITS de Señales de Mensaje Variable
(SiGVMS), y realiza una descripción general del SIGVMS propuesto en función de su
visión y objetivos.

10.1. DESCRIPCIÓN GENERAL DEL DOCUMENTO

Dado que este documento se enmarca en el decreto 2060 de 2015 en referencia al

Sistema Inteligente Nacional para la Infraestructura, Tránsito y Transporte (SINITT), el
SIGVMS es considerado como uno de los subsistemas ITS del SINITT y por ello, este
documento ofrece un entendimiento claro del subsistema en lo que respecta a su
implementación, operación y mantenimiento, esto expresado en una descripción de:
su estado actual, quiénes son los actores involucrados, cuáles son los elementos y las
capacidades de alto nivel, cuál es la extensión física y geográfica cubierta, cuáles son
las secuencias de actividades que deben ser realizadas, así como en la identificación
de alto nivel de las necesidades y restricciones de actores involucrados. Por su parte,
incluye más adelante a nivel técnico los requisitos técnicos para el elemento ITS
denominado Sistema de Mensaje Variable (VMS).

http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=60596
49 Manual Estrategia Gobierno en línea. Recuperado de:

http://programa.gobiernoenlinea.gov.co/apc-aa-files/eb0df10529195223c011ca6762bfe39e/manual-
3.1.pdf

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

27
Por lo anterior y dados los estudios que ha realizado el Ministerio de Transporte en
referencia a los Sistema de Mensaje Variable aborda mediante este documento y de
manera ejecutiva, la descripción de normas y estándares internacionales que
impactan o afectan las definiciones de este subsistema ITS tanto desde el SIGVMS
como de los elementos VMS desplegados en campo. Por su parte también se da a
conocer el escenario actual que enfrentan los VMS en Colombia en función de
necesidades de actores, deficiencia y limitaciones del esquema de operación actual.
Adicionalmente, el documento aborda una perspectiva del SIGVMS y como desde los
actores estratégicos del sistema se debe operar e interactuar bajo ciertas
circunstancias.

Posteriormente contiene la especificación de los requisitos de hardware y software

que componen el módulo ITS para las Señales de Mensaje Variable (VMS). El
contenido del mismo está presentado en los siguientes apartados:
● Requisitos de Hardware
○ Para dispositivos Fijos
○ Para dispositivos portátiles

● Requisitos de Software
○ Requisitos generales del administrador vial y el ministerio de transporte
○ Requisitos para el administrador vial
○ Requisitos para el Ministerio de transporte.

10.2. DESCRIPCIÓN GENERAL DEL SUBSISTEMA ITS DE SEÑALES DE

MENSAJE VARIABLE

10.2.1. Visión

El Ministerio de Transporte (MT) planea en los próximos años, mejorar el escenario

nacional de prestación de servicios ITS a lo largo de la infraestructura de transporte
por ello se apunta al mejoramiento del servicio de suministro de información
estandarizada al viajero, desplegada en los dispositivos de Señales de Mensaje
Variables, aumentando la confianza y la seguridad de los usuarios de la Red Vial
Nacional en todos sus niveles.

10.2.2. Objetivo General

Desarrollar la Política Pública Nacional para la prestación de servicios ITS de

información al usuario, a través de Señales de Mensaje Variable, sobre el estado del
tráfico y las condiciones prevalecientes de la vía, de manera oportuna, veraz,
confiable, íntegra y estandarizada.

10.2.3. Objetivos Específicos

 Establecer las especificaciones técnicas mínimas, que debe considerar un

ente territorial u operador vial para la adquisición e instalación de equipos de
VMS, en función de las características de los corredores viales.
 Unificar, adoptar y proveer un diccionario para Señales de Mensajes Variables
en el País, los casos de uso y el esquema de activación de estos, en función
de los eventos identificados en la operación vial
 Especificar los requisitos de hardware y software de una solución tecnológica
que permita al administrador vial o al Ente Territorial, gestionar (planificar,
implementar, operar, controlar, monitorear y mantener) de forma remota y local
los paneles bajo su jurisdicción.
 Definir un mecanismo de interoperabilidad basado en servicios, que permita la
validación de estado y de configuración de las características de operación de

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

28
 los dispositivos de VMS frente al SINITT y a los operadores viales.
 Registrar en el módulo ITS SIGMapas la información georeferenciada de todos
los dispositivos de VMS (Móviles, Fijos y estacionarios) desplegados en las
carreteras de la Red Vial Nacional, así como sus atributos relevantes.
 Definir el mecanismo a adoptar para el enlace simultáneo de todos los VMS,
para despliegue de mensajes de interés nacional en tiempo real.
 Recomendar la adopción de especificaciones técnicas, que deben acoger las
entidades territoriales y los administradores viales, para la definición de los
puntos y sectores para la instalación de los subsistemas de Señales de
Mensaje Variables.
 Establecer un marco normativo que permita la implementación y uso de
equipos estandarizados, que sean interoperables, por parte de las autoridades
de tránsito.
 Elaborar el proceso de certificación de los equipos, garantizando su
neutralidad tecnológica, interoperabilidad, apertura de datos, mantenimiento y
calibración.

11. ESTADO ACTUAL

Esta sección presenta el estado actual de los esquemas de Señalización de Mensajes
Variables en Colombia contemplando la normativa vigente por la cual se rige, así
como los actores relacionados con el Módulo.

11.1. NORMATIVA, POLÍTICAS OPERACIONALES Y RESTRICCIONES

En primera instancia es necesario resaltar que el marco jurídico que regula la
operación de los paneles de mensaje variable en el país, tiene fundamentalmente dos
fuentes normativas. La primera, proveniente del Código Nacional de Tránsito,
concretada en el Manual de Señalización Vial y obligatoria para todo el país, y la
segunda, de tipo contractual, generada en las regulaciones particulares que realiza
cada entidad al adquirir los equipos.

Con relación a la primera fuente normativa, es importante señalar que en virtud de la

competencia asignada al Ministerio de Transporte en el Código Nacional de Tránsito,
en materia de reglamentación de las características técnicas de la señalización de
toda la infraestructura vial del país, dicha entidad expidió la Resolución 1885 de 2015
por medio de la cual se adopta el “Manual de señalización vial - Dispositivos
uniformes para la regulación del tránsito en calles, carreteras y ciclorutas de
Colombia”. La Resolución define las especificaciones de cada elemento de
señalización, incluyendo los paneles o señales de mensaje variable, lo cual facilita la
aplicación de sanciones en caso de inobservancia a los contenidos allí dispuestos, en
los términos contemplados en el Código Nacional de Tránsito Terrestre y la
Resolución 3027 de 2010.

Los paneles de mensaje variable, según el Manual de Señalización Vial, se entienden

como un “dispositivo de control de tránsito cuyo mensaje puede ser cambiado manual,
eléctrica, mecánica o electrónicamente, con el fin de proporcionar a los conductores,
en tiempo real, información pertinente a su viaje”.

Finalmente, con relación a las restricciones jurídicas frente a la operación de las

señales de mensaje variables, se puede concluir que a nivel nacional son las
consagradas en el Código Nacional de Tránsito y el Manual de Señalización Vial.
Estas pueden sintetizarse así:

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

29
  Las señales de mensaje variable deben ser instaladas por la autoridad de
tránsito competente o por la entidad en quien ésta delegue dicha función.

 El dispositivo debe transmitir un mensaje inequívoco al usuario del sistema

vial, lo que se logra a través de símbolos y/o leyendas.

 Los mensajes o leyendas deben estar compuestas por palabras y/o números,
que deben respetar tipografía establecida en el Manual.

 Los dispositivos de mensaje variable deben permanecer siempre prendidas.

 Las señales deben mostrar siempre mensajes pre-programados y rutinarios,

para lo cual se sugiere tener en cuenta la librería de mensajes establecida en
el mismo Manual.

 Los mensajes a transmitir se restringen a temas relacionados con la seguridad

vial y la fluidez del tráfico.

 Está prohibido que las señales de mensaje variable sean utilizadas para
publicidad, propaganda política o cualquier otro fin ajeno a la operación segura
y eficiente en la vía, aunque se permite incorporar mensajes de carácter
general, como la hora del día o la fecha.

 En cuanto al diseño de los mensajes, cada mensaje consistirá en no más de

dos aspectos o fases independientes, los cuales tendrán, cada uno, como
máximo 3 líneas de información y estar centrados en cada línea.

 El diseño de los mensajes debe considerar las indicaciones establecidas en el

Manual, en materia de tiempos de despliegue, tiempo máximo del ciclo de un
mensaje, alternancia, entre otros.

 Es importante tener en cuenta que las restricciones, prohibiciones y

obligaciones que se impongan a los distintos actores de la vía en las señales
de mensaje variable, empleando símbolos o pictogramas no previstos en el
Manual de señalización, carecen de valor legal.

 Los usos dados a este tipo de señales son variados, se encuentran temas
informativos generales, advertencias en la vía, contingencias, entre otros.

 Los siguientes usos son considerados servicios ITS:

o Manejo de incidentes y desvíos de rutas.
o Advertencia de situaciones de condiciones ambientales adversas como
lluvia, neblina, tempestad.
o Información de precios de peaje.
o Información de tiempos de viaje.
o Advertencias especiales, como derrumbes o bloqueo de carriles.
o Regulaciones de tránsito especiales.
o Control de velocidad.
o Uso de carriles y/o rampas de acceso o salida.
o Situaciones de control policial.
o Recomendaciones de seguridad vial, como “use cinturón de seguridad”,
“encienda luces”, etc.
o Condiciones de operación en puentes, túneles o rutas”.

Con relación a la segunda fuente normativa, la contractual, se puede señalar que es

bastante limitada, toda vez que se restringe a definir aspectos técnicos generales de
los equipos que transmiten los mensajes variables, sin entrar a regular el tipo de
mensajes a suministrar, requisitos de interoperabilidad, protocolos de conexión o
instructivos para el diseño o transmisión de mensajes. No obstante, es importante
mencionarla porque define los mecanismos jurídicos que vienen siendo empleados

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

30
para la adquisición y operación de los paneles de mensaje variable en el país, los
cuales se pueden agrupar así:

11.1.1. Infraestructura Vial Nacional

La adquisición de los páneles de mensajería variable en este tipo de infraestructura,

se efectúa en el marco de la facultad que el parágrafo 2 del artículo 6 del Código
Nacional de Tránsito, impone a la Policía Nacional en su cuerpo especializado de
carreteras, sobre el control de las normas de tránsito y la aplicación del Código en
todas las carreteras nacionales por fuera del perímetro urbano de los municipios y
distritos. Para el ejercicio de su función, esta entidad cuenta con los equipos
señalados, los cuales son adquiridos a través de dos mecanismos:

a. Concesionarios Viales

La Dirección de Tránsito y Transporte de la Policía Nacional “DITRA”, solicita a las

entidades estatales que contratan la realización de una obra de infraestructura vial,
incluir como una obligación a cargo de los contratistas, el suministro de paneles de
mensaje variable, buscando una mayor prevención de accidentalidad, mejorar la
información a los actores viales y la creación de conciencia en ciudadanía sobre la
problemática de la seguridad vial. Las condiciones técnicas de los equipos son
establecidas por la Policía Nacional.

Lo anterior en concordancia con la obligación dispuesta en el Código Nacional de

tránsito, según la cual, en todo contrato de construcción, pavimentación o
rehabilitación de una vía urbana o rural, será obligatorio incluir la demarcación vial
correspondiente, so pena de incurrir el responsable, en causal de mala conducta.

En la historia reciente del país el desarrollo de la infraestructura vial se ha realizado a

través de lo que se conoce como concesiones de primera, segunda, tercera y cuarta
generación. Las concesiones de primera generación, segunda y tercera generación se
basaron en las estipulaciones establecidas en la Ley 80 de 1993, norma que permite
a las entidades públicas contratar con particulares la realización de obras de
infraestructura a cambio de una remuneración que puede consistir en la explotación
económica de la misma obra construida. Así, dado que la Ley 105 de 1993 permite
que las obras de infraestructura vial se puedan financiar con cargo a peajes, tasas,
valorización, entre otros mecanismos, el costo del suministro y mantenimiento de los
paneles de mensaje variable es asumido por el concesionario. En el caso de los
paneles fijos, la responsabilidad de la operación también es asumida por el
concesionario.

Se trata de un apoyo logístico que se suministra a la Policía para el desarrollo de su

función de control vial, por lo cual, una vez suscrito el respectivo contrato de
concesión vial, la Policía Nacional, a través de su cuerpo especializado la Dirección
de Tránsito y Transporte DITRA, suscribe un convenio de cooperación con el
concesionario, en el cual se definen protocolos de entrega, mantenimiento y
operación de los equipos móviles.

b. Operación directa
La Policía Nacional también adquiere directamente páneles de mensaje variable para
el ejercicio de su función, especialmente en aquellas vías que no están
concesionadas.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

31
En este esquema, se efectúan contratos de suministro para la adquisición de los
equipos, con cargo a los recursos de la Policía Nacional, y las condiciones técnicas de
los equipos son definidas autónomamente por dicha entidad.

11.1.2. Infraestructura Vial de Entidades Territoriales

La adquisición de las señales o páneles de mensajería variable para la infraestructura
vial de los Departamentos, Distritos y municipios, se soporta en la facultad que el
artículo 115 del Código Nacional de Tránsito establece para cada organismo de
tránsito, al señalar que éste responderá en su jurisdicción por la colocación y el
mantenimiento de todas y cada una de las señales necesarias para un adecuado
control de tránsito, para lo cual deberá efectuar un estudio, en el cual se determinan
las necesidades y el inventario general de la señalización en cada jurisdicción.

Para este tipo de infraestructura, existen cuatro formas de adquisición, suministro y

operación de los equipos:

a. Convenio con la Policía Nacional

Pese a que las autoridades locales son las competentes para definir los temas
relacionados con la instalación de señales en su jurisdicción, algunos entes
territoriales han delegado ciertas facultades de autoridad de tránsito a la Policía
Nacional, mediante convenio interadministrativo.
En virtud de lo anterior, si bien los entes territoriales adquieren los equipos de
mensaje variable para facilitar el tránsito en su jurisdicción, en la práctica es la Policía
Nacional quien define sus condiciones técnicas, dado que es dicho organismos quien
se responsabiliza de la operación de los equipos.

b. Concesionarios Viales
Al igual que en la infraestructura nacional, existen concesionarios viales
departamentales, a quienes se asigna la obligación de suministrar y mantener paneles
de mensaje variable, con base en los requerimientos técnicos establecidos por la
Policía Nacional.
En estos casos, existe también un convenio interadministrativo suscrito entre la
entidad territorial y la Policía Nacional, en el cual se delegan ciertas facultades de
facultad de autoridad de tránsito, para que pueda ejercer la función de control de
tránsito en la jurisdicción.
Así, los paneles de mensaje variable son entregados por los concesionarios viales a
la Policía Nacional, previa suscripción de convenios, en los cuales se establece las
condiciones de operación y mantenimiento de los equipos.

c. Contratación de terceros
En este esquema la autoridad local vincula a una entidad de carácter público o
privado, para el suministro de ayudas tecnológicas, las cuales permiten una mejor
gestión de la infraestructura de tránsito y transporte de la jurisdicción.
Las figuras jurídicas empleadas para la adquisición de los equipos son los contratos
de suministro, los contratos de concesión y los convenios. Estas dos últimas figuras,
incluyen además la operación y mantenimiento de los equipos.

d. Operación directa
En este esquema las entidades seleccionan, mediante licitación pública, el contratista
que efectuará el suministro y mantenimiento de los páneles de mensajería variables,
los cuales, una vez adquiridos, pasan a ser operados y administrados por personal de
la respectiva entidad territorial.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

32
11.2. DESCRIPCIÓN
El despliegue actual de equipos para el suministro de información en Señales de
mensaje variable puede enfocarse desde los diferentes niveles territoriales que
administran la Infraestructura Vial.

A continuación, se hará una descripción de manera genérica de la gestión realizada a

la fecha y se detallarán las singularidades en cada nivel territorial:

1. A nivel nacional el Congreso de la República es la corporación encargada de la

aprobación de la reglamentación de carácter general. A nivel territorial, las
corporaciones públicas son las encargadas de aprobar los planes, programas,
proyectos y presupuestos, así como la adopción de normatividad de tránsito de
carácter temporal en los territorios bajo su jurisdicción.

2. En el nivel nacional, el Ministerio de Transporte como entidad cabeza de sector es

la encargada de formular las políticas del Gobierno Nacional en materia de
transporte, tránsito y la infraestructura de los modos de su competencia.
Asimismo, es el encargado de formular de manera específica, la regulación
técnica en materia de tránsito y transporte del modo carretero y le corresponde la
coordinación de los planes, programas y proyectos a desarrollar por el sector. A
nivel territorial, el Ministerio es la entidad encargada de dictar la política en cuanto
a la red de carreteras y tiene dentro de sus funciones la adopción de Manuales y
Especificaciones Técnicas en los temas de su competencia.

3. Las entidades adscritas INVIAS y ANI y las entidades territoriales desarrollan los
proyectos a través de contratos, o por esquemas de asociaciones público privadas
APP de iniciativa pública o privada. La instalación de elementos que contribuyan
con una mejor gestión de tránsito, se incorporan en la fase de diseño de los
proyectos, y en algunos casos en etapas posteriores (operación y mantenimiento)
con la finalidad de mejorar condiciones de seguridad. Dentro de estos elementos
se encuentran los dispositivos para la emisión de mensajes variables de carácter
fijo o temporal. VMS.

A continuación se detalla para cada entidad y nivel territorial el proceso a través

del cual se despliegan los dispositivos de VMS:
o La ANI desde la primera generación de Concesiones, incorporó dentro de sus
contratos la obligatoriedad para que los Concesionarios suministraran equipos
para la emisión de señales de mensajes variables. Estos primeros equipos de
tipología móvil, son operados por personal del cuerpo Especializado de la
Policía Nacional, Dirección de Tránsito y Transporte DITRA en las vías bajo
Concesión. En las últimas generaciones de concesiones tercera y cuarta,
además de estos dispositivos, se han incorporado equipos fijos que son
previstos desde la etapa de Diseño para las concesiones de cuarta generación
y como elementos adicionales para mejorar la seguridad en la operación, en
las concesiones de primera, segunda y tercera generación en el marco de las
extensiones en alcance y tiempo que se han hecho para los corredores de
estas generaciones.

o Para el caso del Instituto Nacional de vías INVIAS y las entidades territoriales,
no es habitual que se haga uso de elementos de este tipo, siendo excepcional
su implementación para el caso de corredores interurbanos. Esta limitación
está asociada principalmente a un aspecto presupuestal.

o En el caso de corredores urbanos en ciudades como Medellín, Cali, Bogotá,

entre otras, el despliegue de estos elementos puede encontrarse asociado a
procesos de contratación vía concesión o convenio, o a procesos de
contratación vía licitación. En el caso de Medellín, Cali, Pasto y Barranquilla

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

33
 entre otras, se adicionan a otros Servicios ITS, tales como los esquemas de
foto detección, la instalación de elementos de Señales de Mensaje Variables
(VMS).

o El cuerpo especializado de la Policía Nacional, Dirección de Tránsito y

Transporte, que tiene competencia para regulación y control en vías de Orden
Nacional, Departamental y Municipal de carácter rural e interurbano y en
algunos casos mediante convenio en vías urbanas, también ha adquirido
equipos móviles de VMS para el suministro de información y mensajes.

o Generalmente los equipos tanto fijos como móviles son suministrados por
operadores tecnológicos, incluyendo los mecanismos de interoperabilidad
hacía los Centros de Control y Operación, así como la operación en remoto y
local para los dispositivos.

o En el caso de la ANI, para los proyectos de cuarta generación, se hace

exigible una evaluación desde el punto de vista operacional y de seguridad vial
desde la fase de diseño, que integre los dispositivos a desplegar bajo un ITS
de carácter regional, por cada corredor a operar.

o El despliegue de los mensajes, la periodicidad de estos, así como los casos de

uso, corresponden a prácticas locales (Desarrolladas en cada ente territorial),
que acogen la normatividad vigente del Manual de Señalización de Calles y
Carreteras adoptado en 2015.

4. El despliegue de los mensajes por VMS se suma a otros canales de información a

usuarios como el #767, redes sociales y canales de radio.

5. Los usuarios de la Red Vial visualizan los mensajes variables a través de los
equipos VMS dispuestos a lo largo de la red.

6. Los usuarios utilizan los canales disponibles dispuestos por los administradores
viales para reportar incidentes acontecidos en la vía.

7. A través del operador #767, se suministra la información de los eventos en la red

vial a los administradores viales y otras entidades responsables de la red vial para
retroalimentar al usuario a través de los equipos VMS y otros canales, acerca de
las condiciones de la vía.
8. La Superintendencia de Puertos y Transporte solicita el reporte de las cifras de
accidentalidad en la vía a los concesionarios viales, así mismo, les advierte
riesgos identificados sobre la misma. No se evidenció información sobre registros
o solicitudes de record de mensajes desplegados.

9. En los reportes suministrados por los Concesionarios a la Superintendencia de

Puertos y Transporte, además de la información sobre accidentalidad, se refiere el
uso de estos dispositivos, así como su ubicación (equipos fijos), y suelen hacerse
recomendaciones para incidir sobre todo en puntos de recurrencia de
accidentalidad.

10. La Superintendencia de Puertos y Transporte supervisa y controla la

implementación de las políticas públicas reguladas por el Ministerio de Transporte.

En el diagrama siguiente se representa la relación entre los actores descrita

previamente:

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

34
 Figura 1. Diagrama de Relación de Actores - Descripción Situación Actual para Sistemas de Mensaje Variable (VMS)

Anexo Técnico de la Resolución XXXXX de XXXX, De acuerdo al artículo 2.5.3.2. Subsistemas del Sinitt del Título 3 del Decreto 1079 de 2015

35
11.2.1. Perfiles de Actores

Los actores relevantes para el módulo de Señales de Mensaje Variables (VMS) con el
marco legal del sector transporte y los lineamientos institucionales del Plan Nacional
de Seguridad Vial 2011-202150, son en primera instancia el Ministerio de Transporte
quien es la cabeza de sector; sus roles en el marco del módulo VMS son la
planeación y la definición de políticas para el sector. Por otra parte, la ANI y el INVIAS
tienen el rol de ejecutar y operar la infraestructura de carreteras a su cargo y también
tienen funciones de planeación y definición de políticas. La Agencia Nacional de
Seguridad Vial ANSV tiene dentro de sus funciones la planificación, articulación y
gestión de la seguridad vial del país. Finalmente, los municipios y departamentos que
tienen el rol de planeación y de ejecutar y operar de manera segura y eficiente la
infraestructura de carreteras a su cargo.

a. Ministerio de Transporte
Es el ente regulador de la Política Pública. Tiene dentro de sus funciones formular y
adoptar las políticas, planes, programas, proyectos y regulación económica en
materia de transporte, tránsito e infraestructura de los modos de transporte carretero,
marítimo, fluvial, férreo y aéreo; y la regulación técnica en materia de transporte y
tránsito de los modos carretero, marítimo, fluvial, férreo y aéreo del país.

b. ANI
Es una de las entidades ejecutoras de Infraestructura en el País, adscrita al Ministerio
de Transporte. Tiene dentro de sus funciones: Planear, coordinar, estructurar,
contratar, ejecutar, administrar y evaluar proyectos de concesiones y otras formas de
Asociación Público Privada, para el diseño, construcción, mantenimiento, operación,
administración y/o explotación de la infraestructura pública de transporte en todos sus
modos y de los servicios conexos o relacionados y el desarrollo de proyectos de
asociación público privada para otro tipo de infraestructura pública cuando así lo
determine expresamente el Gobierno Nacional.

c. INVIAS
Es la entidad encargada de Ejecutar las políticas, estrategias, planes, programas y
proyectos de la infraestructura no concesionada de la Red Vial Nacional de carreteras
primaria y terciaria, férrea, fluvial y de la infraestructura marítima, de acuerdo con los
lineamientos dados por el Ministerio de Transporte.

d. Dirección de Tránsito y transporte DITRA

Cuerpo especializado de la Policía Nacional, que tiene como funciones: Ejercer
control de las normas de tránsito y brindar seguridad y tranquilidad a los usuarios de
la red vial nacional de Colombia tanto Urbana como Rural. Además de mantener el
orden en puertos marítimos, aeropuertos, vías férreas, terminales de transporte,
peajes, entre otros.

e. ANSV Agencia Nacional de Seguridad Vial

Es la entidad encargada de la planificación, articulación y gestión de la seguridad vial
del país. Tiene a cargo ser el soporte institucional y de coordinación para la ejecución,

50Plan Nacional de Seguridad Vial adoptado mediante la Resolución 2273 de 2014 del Ministerio de
Transporte.

Anexo Técnico de la Resolución XXXXX de XXXX, De acuerdo al artículo 2.5.3.2. Subsistemas del Sinitt
del Título 3 del Decreto 1079 de 2015

36
el seguimiento y el control de las estrategias, los planes y las acciones dirigidos a dar
cumplimiento a los objetivos de las políticas de seguridad vial del Gobierno Nacional
en todo el territorio Nacional

f. Entidades Territoriales
Personas jurídicas, de derecho público, que componen la división político-
administrativa del Estado, gozando de autonomía en la gestión de sus intereses. Son
entidades territoriales los departamentos, municipios, distritos y los territorios
indígenas y eventualmente, las regiones y provincias.

g. Organismos de Tránsito
Se definen como unidades administrativas que se encargan de organizar y dirigir lo
concerniente al tema de Tránsito y Transporte en un lugar determinado, haciendo
cumplir los lineamientos plasmados en el Código Nacional de Tránsito terrestre.

h. Operadores y/o proveedores Tecnológicos

Entidades públicas o privadas que mediante procesos licitatorios o esquemas de
convenio, diseñan, gestionan, operan, suministran y mantienen la infraestructura
tecnológica el apoyo técnico y logístico, el soporte legal y la provisión de insumos,
equipos y personal calificado, de manera integral o desagregada.

i. Concesionarios
Persona Natural o jurídica que mediante la suscripción de un contrato se obliga a
riesgo propio en la operación, explotación, prestación, organización o gestión de un
servicio público, bien sea de manera parcial o total recibido a manera de delegación,
de una persona jurídica -generalmente una entidad del Estado- denominada
concedente.

j. Usuarios
Persona natural o jurídica que hace uso de la infraestructura vial y de transporte
pública o privada que conforma la red vial Nacional en cualquiera de sus
modalidades.

11.2.2. Interacción entre Actores

Se describen las interacciones entre los distintos actores que participan en el módulo
ITS actual. Las interacciones que se producen entre los actores principales del
sistema, y entre usuarios y no usuarios del sistema, visto desde una perspectiva
misional del módulo ITS. También son descritas las interacciones formales, así como
las informales.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

37
Anexo Técnico de la Resolución XXXXX de XXXX, De acuerdo al artículo 2.5.3.2. Subsistemas del Sinitt del Título 3 del Decreto 1079 de 2015

38
Tabla 2 Matriz de Relación de Actores - Descripción Situación Actual VMS

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

39
11.2.3. Otros Involucrados

A continuación se incluyen otros actores de diferentes niveles, que tienen incidencia

con este módulo y que dado su rol, pueden afectar el Concepto y reglas de operación
para el despliegue del servicio de Señales de Mensaje Variable.

a. Congreso
Según lo dispuesto en la Constitución Política de Colombia, Corresponde al Congreso
de la República reformar la Constitución, hacer las leyes y ejercer control político
sobre el gobierno y la administración, así mismo es el responsable de estudiar y
aprobar el proyecto de presupuesto de rentas y gastos presentado por el Gobierno
nacional.

b. Corporaciones públicas
La Constitución Política de Colombia establece que corresponde a las Asambleas
Departamentales, por medio de ordenanzas, expedir las normas orgánicas del
presupuesto departamental y el presupuesto anual de rentas y gastos. Igualmente
tienen competencia para dictar las normas de policía en todo aquello que no sea
materia de disposición legal y adoptar los planes y programas de desarrollo
económico y social y los de obras públicas, con la determinación de las inversiones y
medidas que se consideren necesarias para impulsar su ejecución y asegurar su
cumplimiento.

Corresponde también a las Asambleas disponer, a iniciativa del Gobernador la

ejecución y conservación de obras públicas en el ramo de vías de comunicación,
mediante el sistema de concesión de obras públicas.
Así mismo, corresponde a los Concejos, a través de acuerdos municipales o
distritales, dictar las normas orgánicas del presupuesto y expedir anualmente el
presupuesto de rentas y gastos.

12. FUNDAMENTOS DEL SERVICIOS ITS DE SEÑALES DE MENSAJE

VARIABLE
Las Señales de Mensaje Variable (VMS) son dispositivos de control de tráfico
utilizados para proporcionar en ruta información al viajero; la información puede ser
mostrada en tiempo real y ser gestionada y controlada ya sea desde un centro de
operaciones remoto o localmente en el lugar donde se encuentre instalado el equipo
de señalización variable haciendo uso de un equipo de cómputo portátil. Los VMS
están diseñados para influir en el comportamiento del conductor, para mejorar la
fluidez del tráfico y facilitar las operaciones de tránsito. Ejemplos de información al
viajero incluyen, entre otros:

 Los tiempos de viaje entre los destinos conocidos

 Las condiciones de congestión a lo largo de un corredor vial
 Avisos de Construcción
 Aviso de eventos especiales e instrucciones
 Horario de las operaciones de mantenimiento
 Notificación de Incidentes ambientales
 Datos de fecha y hora actuales

Anexo Técnico de la Resolución XXXXX de XXXX, De acuerdo al artículo 2.5.3.2. Subsistemas del Sinitt
del Título 3 del Decreto 1079 de 2015

40
12.1. CLASIFICACIÓN

12.1.1. Clasificación VMS respecto a su infraestructura

Acorde a la infraestructura requerida para su instalación, su tamaño y el tiempo de
uso en sitio, los equipos VMS pueden ser categorizados como: VMS Fijos o VMS
portátiles.

VMS Fijos

Son aquellos equipos que permanecen en una misma ubicación debido a que por sus
características físicas, en especial el tamaño, siempre son instalados de manera
suspendida sobre la vía, en estructuras metálicas que pueden ser de tipo bandera o
de pórtico.

Llamados a veces VMS permanentes se utilizan generalmente para advertir a los

usuarios de la carretera de los riesgos de tránsito, incidentes, cierre de carril, trabajos
en la carretera, guía de rutas, información de emergencia, niveles de congestión en
tiempo real, límites de velocidad variables, condiciones de tráfico relacionadas con el
tiempo y tiempos de viaje en tiempo real.

VMS Portátiles

Son equipos que en su totalidad se encuentran instalados en un tráiler y ésta

disposición permite que puedan ser desplazados en cualquier instante de tiempo a
lugares diferentes, en eventos especiales como son semanas de vacaciones o en
planes de retorno, pueden permanecer por varios días en un mismo sitio.

Conocidos también como VMS móviles se pueden mover a un lugar según sea
necesario, movidos en remolques u otro vehículo y se usan en aquellos sitios en
donde no existe un VMS permanente.

Una variedad de estos VMS móviles o portátiles son aquellos conocidos como VMS
montados en vehículos que se pueden llevar en el frente, la parte posterior o el tejado
de la mayoría de los vehículos; se utilizan en trabajos de las carreteras, para los
trabajos móviles de la vía, por la policía y por vehículos de los servicios de
emergencia.

12.1.2. Clasificación VMS respecto a tipo de señal

Los equipos de señales de mensajes también pueden ser clasificados de acuerdo al

tipo de señal, de acuerdo con la EN 12966 en sus diferentes numerales, las señales
de mensaje se catalogan en dos grupos:

1) Señales continuas: son similares a señales fijas con una diferencia en que estas
realizan los cambios de mensajes por medios electromecánicos y/o mecánicos

2) Señales discontinuas: crean mensajes haciendo uso de componentes

individuales discontinuos y pueden presentar diferentes mensajes en la misma cara
de la señal de mensaje variable. En los apartados 7.1.1.1 y 7.1.1.2, se tratarán los
requisitos de las señales de mensaje variable fijas y portátiles de tipo discontinuas.

12.1.3. Clasificación VMS respecto a forma de despliegue de mensaje

Con respecto a la forma en que se hace el despliegue de los mensajes o gráficos se
clasifican principalmente en tres tipos:

 VMS de 2 líneas, con capacidad de mostrar entre 8 y 16 caracteres por línea.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

41
 Figura 2. VMS de 2 Líneas, 12 caracteres
Fuente: Elaboración propia

 VMS de 3 líneas y pictogramas, con capacidad de despliegue de 3 líneas y

entre 12 y 16 caracteres por línea, adicionalmente a los lados de las líneas
traen espacio para uno o dos pictogramas, uno a cada lado.

Figura 3. VMS de 3 Líneas y Pictograma

Fuente: Elaboración propia

 VMS de matriz completa (Full Matrix), en esta clase de señales no hay

restricción en la presentación de la cantidad de líneas, caracteres o tamaño de
los pictogramas, pueden ser presentados en diferentes tamaños y facilitan los
caracteres especiales.

Figura 4. VMS de Matriz Completa (Full Matrix).

Adicionalmente se precisa mencionar que para mejorar la efectividad de los Sistemas

de Señales Variable, se deben incorporar tres factores clave como son visibilidad,
legibilidad y comprensión.

12.2. Descripción de las Necesidades actuales para el país en términos

de Señales de Mensaje Variable

A continuación, se resumen las capacidades, funciones, procesos, interfaces y otros

cambios que son necesarios para responder a los factores identificados en el alcance.
Estas necesidades están basadas en las características de funcionamiento actual.

12.2.1. Definir un Diccionario de Mensajes Estandarizado

Establecer un mecanismo que permita unificar a nivel nacional el lenguaje utilizado en
el despliegue de mensajes, complementando los parámetros incorporados en el

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

42
Manual de Señalización Vial en Calles y Carreteras de 2015. (Permite adaptar
Diccionarios Internacionales a Condiciones Locales)

Esta adaptación recoge la implementación y los casos de uso locales que se han
adoptado a partir de la aplicación en Calles y Carreteras del Manual de Señalización
vigente, que permite generar los diferentes tipos de mensaje, los cuales deben estar
asociado a dos características de operación:

1. Suministro de información para eventos en operación normal de los corredores

viales.
2. Suministro de información para eventos en operación de vías bajo
construcción o rehabilitación.

12.2.2. Establecer criterios técnicos de selección de equipos VMS en

función de la tipología vial y de la condición de operación a
informar
Definir la especificación técnica de los equipos VMS en función de las necesidades
del administrador vial o ente territorial. Esta caracterización debe obedecer a criterios
asociados a la tipología vial de los corredores viales en administración por parte de la
entidad Territorial o la Red Vial Nacional. La base para esta caracterización es el
Manual de Señalización Vial en Calles y Carreteras adoptado en 2015:
 Contar con las especificaciones técnicas adecuadas de los equipos VMS de
acuerdo a su uso y ubicación en vía.
 Definir la capacidad adecuada de almacenamiento local en los elementos de
despliegue de Mensaje Variable VMS
 Especificar las características técnicas de los elementos de Despliegue de
Mensaje Variable VMS con base en los requisitos funcionales del
administrador vial o ente territorial.

12.2.3. Especificar requisitos de hardware y software de la solución

tecnológica a implementar por parte de los administradores viales
y entidades territoriales a cargo de la infraestructura vial
Los administradores viales y entes territoriales contarán con especificaciones de
componentes de hardware y de software necesarias para implementar una plataforma
tecnológica que permita la operación óptima de los equipos de Señales de Mensaje
Variable, la especificación debe incluir como mínimo lo siguiente:

 Registro de Eventos de Operación, registrar todos los eventos de operación de

los dispositivos, entre otros: actualización de mensaje o pictograma, horario de
funcionamiento.

 Actualización del mensaje y Pictograma, modificar el mensaje o pictograma.

 Gestión de base de datos de mensajes y pictogramas, administrar una base

de datos de los mensajes estándares definidos por el diccionarios de mensajes
propuesto, se hace uso de la base de datos al momento de actualizar los mensajes
acorde a necesidades.

 Registro de Eventos sobre Elementos de Despliegue de Mensaje Variable

VMS, registrar en una bitácora los eventos de instalación, operación y mantenimiento
de cada uno de los dispositivos. (Trazabilidad)

 Registro de soporte de incidentes sobre el dispositivo, mantener almacenados

los registros de todos los eventos de soporte a equipos VMS y la solución a los
mismos.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

43
  Consulta del Estado y disponibilidad de los equipos, permitir la visualización
del estado operativo de cada uno de los equipos y hacer seguimiento a los eventos de
estado.

 Gestión de la información generada por los equipos, definir un proceso que

registre y almacene la información gestionada por cada uno de los dispositivos

 Servicios de Operador (Activar/Desactivar), contar con las funcionalidades que

permitan activar o desactivar los equipos.

 Registro y Georeferenciación de los Equipos, registrar información referente a

identificación y georeferenciación de cada uno de los equipos VMS instalados bajo su
jurisdicción.

 Centro de control, contar con un sitio físico, Centro de Control , en donde se

monitorice y se gestione la operación de los VMS, sitio que debe contar con las
siguientes características:

o Instalaciones físicas adecuadas en cuanto a espacio y disposición de las

áreas de trabajo y ubicación de las soluciones tecnológicas necesarias,
que permitan visualizar mediante herramientas de software estado de los
equipos VMS y los eventos operativos de los mismos.

o Disposición de los recursos de hardware, software necesario para una

óptima visualización y gestión de los equipos VMS.

o Instalaciones que cuenten con los subsistemas necesarios y mínimos, de

soporte eléctrico y ambiental (Aire Acondicionado y Equipos de Extinción
de incendios) que garanticen la operación del centro de control y la
seguridad del personal operativo.

o Subsistemas de comunicaciones y redes de datos adecuadas para la

gestión y el tráfico de información en doble vía.

o Sistemas de respaldo de infraestructuras de cómputo, soluciones de

copias de seguridad de los datos y herramientas de seguridad de la
información que minimicen los riesgos de pérdida de activos informáticos.

o Garantizar mediante la implementación de procesos y procedimientos, la

disponibilidad, confiabilidad, oportunidad e integridad de la Información
generada por el sistema.

o Definir los tiempos de retención de la información generada por el sistema.

12.2.4. Definir un mecanismo de Interoperabilidad basado en servicios

Definir un mecanismo de comunicación e interoperabilidad Centro de control
Operacional y Equipos VMS que sea basado en servicios, y permita manipular desde
el centro de control características de operación de los equipos VMS: fuentes,
gráficos, texto del mensaje, calendarios basados en el tiempo, así como estados de
operación y recuperación de alertas o mensajes de diagnóstico del mismo.
12.2.5. Definir un mecanismo de enlace simultáneo
Definir un mecanismo a adoptar por parte del Ministerio de Transporte que permita la
conexión de forma simultánea con todos los VMS instalados en el país o en alguna
zona (Departamento o municipio) o región particular, para el despliegue de mensajes
predefinidos y catalogados de alta prioridad y de interés nacional, los cuales deben

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

44
ser mostrados en todas las señales de mensaje variable contenidas en el área
indicada y en tiempo real.

13. POLÍTICAS OPERACIONALES Y RESTRICCIONES

Este apartado describe las políticas de operación y restricciones que aplican al
módulo de VMS que el Ministerio considera para la prestación de servicios ITS. A
continuación de se describen las políticas operacionales:

 Las definiciones de la solución propuesta amplían las responsabilidades de los

administradores viales y entes territoriales descritas en el apartado Normativa,
Políticas operacionales y Restricciones en virtud del modelo de operación y
soporte tecnológico incluidas así:

o Cualquier administrador vial o entes territoriales que despliegue VMS como

parte de la solución de seguridad vial sobre la infraestructura vial a su cargo
estará en la obligación de reportar información referente a los equipos
instalados, y asimismo, deberá disponer el esquema de interoperabilidad
basado en servicios para envío simultáneo de mensajes de interés nacional
propuesto.

o Las Entidades adscritas y Entes Territoriales deberán integrar exigencias al

suministro e instalación de equipos VMS para los operadores tecnológicos y
los proveedores de estos equipos, en la medida que permitan su integración e
interoperabilidad con la plataforma que se desarrolle en el marco del SiGVMS
y por consiguiente del SINITT.

o Fortalece el papel de coordinación que desde el Ministerio debe darse para la

gestión de información y suministro de mensajes por demanda en los
diferentes niveles y provee herramientas para mejorar la operación,
interoperabilidad y flujo de información de este servicio a los usuarios.

 El sistema contará con una funcionalidad de registro por demanda – basado en

peticiones realizadas del MT – para la entrada en operación de VMS que deberá
ser de obligatorio cumplimiento, para suministro de información e integración de
otros servicios ITS en el marco de Interoperabilidad que establece el MT. Esto se
dará cuando el Ministerio de Transporte despliegue el SIGVMS y para ello se
informará a las partes interesadas al momento de su entrada en operación con el
fin de que haya intercambio de información y pueda ser posible la
interoperabilidad de equipos.

 Los equipos VMS deberán ser adecuados tecnológicamente para soportar el

esquema de interoperabilidad basado en servicios.

 Los requisitos mínimos que se propongan tendrán un carácter vinculante para los
nuevos equipos que se suministren, y serán opcionales para la migración de los
equipos de VMS que ya están en funcionamiento.

 La implementación del registro será paulatina y requiere un período de

gradualidad para su integración completa.

Las restricciones claves identificadas a continuación:

o Todos los componentes de software y hardware propuestos en la solución
deberán estar articulados con las definiciones del SINITT definidas en el
decreto 2060. Para el momento de creación de SIGVMS se solicitará el
mecanismo técnico mediante servicios web al ente quien gestione el VMS para
que intercambie información con el SIGVMS que pertenecerá al Ministerio de
Transporte.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

45
 o Los equipos VMS únicamente pueden estar conectados a una red interna que
sea accesible por el administrador Vial, significado esto, que este elemento
ITS pueda ser únicamente visible y accedido desde el CCO o mediante el
mecanismo que el proveedor tecnológico aporte, teniendo de referencia las
características mínimas de seguridad, e incluyendo los servicios para su
administración remota. Cualquier acceso que se requiera por un actor externo
al administrador vial deberá ser realizado a través de una capa intermedia de
software dispuesta para tal fin. No obstante, si el Administrador vial tiene su
propia red de telecomunicaciones podrá usarla para la conexión de los VMS.

14. DESCRIPCIÓN DEL MÓDULO ITS PROPUESTO

Con base en las políticas de operaciones y a partir de las necesidades identificadas,
el Ministerio de Transporte considera que la solución ITS debe ir acompañada de:

14.1. DICCIONARIO DE MENSAJE ESTANDARIZADO

Se toma como referencia la recomendación adoptada por el Manual de Señalización
en Calles y Carreteras vigente. Sección 2,7,10., tanto para mensajes y para
pictogramas, para verla mirar la sección 19.5.

14.1.1. Esquema de Interoperabilidad basado en Servicios para la

Administración Remota de equipos VMS
El Ministerio de Transporte considera que se debe que La propuesta de solución
introduce la especificación de un mecanismo y lenguaje de comunicación o interfaz
lógica que debe ser utilizada para la interoperabilidad entre: 1) los equipos VMS
dispuestos en la vía y el CCO que las controla, y 2) el CCO y la solución tecnológica
de software Subsistema para la Gestión de Señales de Mensaje Variable, SiGVMS,
dispuesto en el Ministerio de Transporte. Esta especificación será basada en servicios
Web y permitirá administrar remotamente desde el CCO o SiGVMS características de
operación de los equipos VMS: fuentes, gráficos, texto del mensaje, calendarios
basados en el tiempo, así como estados de operación y recuperación de alertas o
mensajes de diagnóstico del mismo.

Para la especificación se tendrán en cuenta los siguientes principios o restricciones:

 La naturaleza de la interfaz está determinada en parte por el carácter operativo de
los dispositivos que están siendo controlado.
 Se asume un modelo de operación de VMS en donde los controladores de VMS
poseen cierto grado de inteligencia y los datos utilizados para el despliegue de
mensajes y la configuración de señales reside en el controlador del VMS. Las
características tales como fuentes, gráficos, texto del mensaje, calendarios
basados en el tiempo, y así sucesivamente pueden residir en el controlador del
VMS, y el controlador presenta los mensajes en la pantalla de la señal con base
en estos datos.
 Existe una base de datos en el controlador del VMS desde donde se puede
adquirir información acerca del estado del controlador de VMS, el control, y los
datos de configuración.
 El mecanismo especifica las interfaces mediante las cuales se puede consultar y
afectar la base de datos del controlador del VMS desde el CCO o SiGVMS. No
habrán comandos imperativos como “Despliegue un mensaje” o “Informe el
estado”.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

46
 El conjunto de servicios y correspondientes funciones configuran una capa de
abstracción a nivel de aplicaciones, con protocolo de comunicaciones TCP/IP
subyacente.
 El proveedor y/o fabricante tecnológico incluirá en los equipos VMS los
componentes de hardware y software necesarios para interpretar las peticiones y
el lenguaje basado en servicios web propuesto.

14.1.2. Especificaciones Técnicas Mínimas de Equipos VMS,

Administración local, especificaciones técnicas mínimas del CCO,
especificaciones mínimas de comunicaciones con el CCO y el
Ministerio de Transporte
En la sección 16 se abordará lo referente a especificaciones de requisitos de
Hardware, y en la 17 los requisitos de Software.

Nota: El Ministerio de Transporte toma de referencia el Manual de Señalización vial

vigente, donde se definen más específicamente características de visibilidad, estas se
encuentran expuestas en los requerimientos de hardware sección 16.

14.1.3. Plataforma SiGVMS

El Ministerio de Transporte dispondrá de una plataforma tecnológica que permitirá: 1)
recolectar los datos básicos de los equipos VMS dispuestos por los distintos
administradores viales y entes territoriales a lo largo de la red vial nacional, y 2)
permitir el envío simultáneo de un mensaje de interés nacional a un grupo de equipos
VMS contenidos en una zona geográfica específica. A continuación se describen los
dos componentes que permitirán estas funcionalidades:

a. Registro de Datos de equipos VMS y de su operación

Se dispondrá en el Ministerio de Transporte una plataforma tecnológica basada en un
conjunto de servicios Web que permitirá la interoperabilidad con el SIGVMS y los
VMS pertenecientes a cada CCO. Esto se hará a partir de un conjunto de funciones
de negocio que serán expuestas por el Ministerio, los administradores viales y entes
territoriales a través de implementaciones de software en el CCO deberán reportar
información de gestión acerca de los equipos VMS de su jurisdicción, entre otros
atributos se deberá reportar: ubicación geográfica, tipo, marca, estado operacional,
mensaje desplegado. La plataforma tecnológica tendrá la responsabilidad de
mantener actualizada los datos de los equipos en el SiGMapas, esto en la medida de
sus capacidades (estructura de datos), tanto de la plataforma como de SiGMapas.

b. Enlace Simultáneo Ministerio de Transporte, CCO y equipos VMS

Se dispondrá en el Ministerio de Transporte una plataforma tecnológica para lograr el
enlace simultáneo de equipos VMS dispuestos en las vías de la nación o una zona
geográfica particular, esto a través de la implementación de dos componentes: 1) Una
Plataforma Web o la que se considere a través de la cual un actor estratégico del
Despacho del Ministro pueda identificar y seleccionar el grupo de equipos VMS
objetivo para difusión del mensaje, y 2) la implementación del esquema de
interoperabilidad basado en servicios Web para la administración remota de los
equipos VMS que permita lograr el envío del mensaje de interés nacional al grupo de
equipos VMS seleccionados desde la plataforma Web.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

47
14.1.4. Integración SINITT
Tanto la plataforma tecnológica del CCO, como la plataforma de enlace simultáneo
equipos VMS del Ministerio de Transporte deberán estar articuladas con las
definiciones funcionales y técnicas del SINITT así:
 Articulado con SiGAAE, Subsistema para la Gestión y Autenticación de
Actores Estratégicos, como la única plataforma de autenticación de los distintos
módulos ITS asociados al SINITT y cuyo objetivo principal es permitir que los
usuarios, que interactúan con el sistema, puedan autenticar su identidad, recibir la
autorización para el ingreso a los módulos a los que tiene acceso y, realizar la
administración del ciclo de vida de dichos usuarios.
 Articulado con SiGTrazabilidad, Subsistema para la Gestión de la Trazabilidad
el cual almacena la información relacionada con las transacciones realizadas por los
actores estratégicos.
 Articulado con SiGUDDI, Subsistema para la Gestión del Registro UDDI el cual
corresponde a la implementación de una plataforma central que permita la
consolidación de un catálogo de servicios web ofrecidos por los diferentes
subsistemas, para mejorar el acceso y consumo de los mismos por parte de los
usuarios.
 Articulado con SiGMapas, Subsistema para la gestión de Información
Geográfica y Publicación de Mapas en el cual es registrada toda la información
geográfica asociada a los ITS y su posterior publicación en forma de mapas.
Adicionalmente en esta plataforma se articulará con la información de inventario vial.
En esta plataforma debe ser definida la capa geográfica correspondiente a los
equipos VMS y en la cual será registrada los datos referentes al equipo.
 Todos los acápites de integración dependen en su medida de la madurez con
que se vaya desplegando el SINITT, por ello, el Ministerio de Transporte en aras de
continuar con el despliegue de estos equipos a nivel nacional establecerá las
conexiones con los subsistemas mencionados. Lo anterior no afecta al despliegue de
equipos ya que estos tendrán la capacidad desde sus CCO de articulación en el
momento del despliegue de servicios ITS a nivel local.

14.1.5. Diagrama de Solución Propuesta

En el diagrama siguiente se representa la relación entre los actores estratégicos, así
como con las plataformas, incluidos en la solución propuesta y descrita previamente:

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

48
 Figura 5. Diagrama de Relación de actores – Descripción Módulo ITS Propuesto VMS
Fuente: Elaboración Propia

Anexo Técnico de la Resolución XXXXX de XXXX, De acuerdo al artículo 2.5.3.2. Subsistemas del Sinitt del Título 3 del Decreto 1079 de 2015

49
Tal como en la situación actual de VMS, la solución propuesta puede enfocarse desde
los diferentes niveles territoriales que administran la Infraestructura Vial; la solución
propuesta se presenta para la nación, administradores viales y las entidades
territoriales así:

De manera sintética el concepto de operación es el siguiente:

 Las especificaciones sobre los equipos VMS son determinados por el Ministerio de
Transporte.
 La recomendación sobre el tipo de mensajes y los eventos que pueden requerir
despliegue en vía a través de VMS son provistos y actualizados con base en el
Manual de Señalización Vial vigente del Ministerio de Transporte. De requerirse
incorporar nuevos mensajes, esta actividad podría estar a cargo del INVIAS o de
la Agencia Nacional de Seguridad Vial, a partir de la actualización del Manual.
 Las Entidades ejecutoras del Orden Nacional (ANI e INVIAS) y de los niveles
territoriales (Secretarías de Infraestructura o Institutos Descentralizados del orden
Municipal o Departamental), proveen los equipos con las especificaciones
mínimas establecidas por el Ministerio, para dotar la infraestructura vial de los
dispositivos de VMS fijos y móviles, junto con los CCO y los mecanismos de
mantenimiento y operación requeridos.
 En el nivel local se despliegan por los operadores locales los mensajes
estandarizados que permiten una información confiable y oportuna a los usuarios
de la red Vial en los diferentes niveles.
 En función de los mensajes de alerta que defina el Ministerio de Transporte, y los
eventos que detonen dicho despliegue, se activa el enlace simultáneo de carácter
nacional, regional, o subregional que debe vincular los corredores y equipos que el
Ministerio determine para cada contingencia particular.
 Se consideran eventos de carácter nacional o regional que ameriten el despliegue
del enlace, los establecidos con niveles de afectación grave, determinado por la
Resolución 0761 del Ministerio de Transporte y que se definen como: “Novedad
afectación extensa que imposibilita el tránsito en la vía durante un período
extenso. Igualmente cuando su magnitud e impacto en relación a la cantidad de
víctimas, las pérdidas materiales y los problemas de orden público, que son o
pueden llegar a ser de enorme magnitud, lo cual hace necesaria la organización,
coordinación, y asignación de los recursos a gran escala y en forma inmediata de
las instituciones de atención de emergencias y entidades del estado”

14.2. MODOS DE OPERACIÓN

14.2.1. Respecto del Módulo ITS SiGVMS

Como parte de las definiciones de la solución propuesta para el módulo ITS SiGVMS
se ha dado alta importancia al proceso de respaldo y disponibilidad de los datos; se
propone incluir el servicio de alta disponibilidad de datos como requisito fundamental
en la operación normal de la plataforma, de manera que, con la inclusión de, por
ejemplo, un esquema de ejecución paralela o basada en clústeres en el servicio, se
logre una alta tolerancia a fallas tanto del hardware como del software, así como,
adicionar flexibilidad y eficiencia de costos en la planificación de la capacidad,
permitiendo la fácil escalabilidad acorde a las necesidades y condiciones desempeño
que surjan; serán planteadas políticas de respaldo de datos que permitan protegerlos
contra la pérdida, el deterioro, las catástrofes (naturales u obra del hombre) y demás
problemas que puedan surgir, tomando en consideración que:

Anexo Técnico de la Resolución XXXXX de XXXX, De acuerdo al artículo 2.5.3.2. Subsistemas del Sinitt
del Título 3 del Decreto 1079 de 2015

50
  Este módulo ITS dada su funcionalidad no incluye comportamientos de alta
transaccionalidad, ni de misión crítica.

 Han sido incluidos mecanismos que mitiguen riesgos sobre los datos, como se
describió previamente.

 El registro de datos por parte de los administradores viales y entes territoriales

se realiza en periodos altos de tiempo, y en la medida de los cambios en equipos
VMS.

Se concluye que tanto el riesgo como el volumen de pérdida de datos es

relativamente bajo, en caso de una situación de catástrofe de los servicios de
software y/o hardware propuestos, eso permite al ministerio tolerar temporalmente la
falta de funcionamiento y la caída de nivel de servicio asociada al módulo ITS de
SiGVMS; se concluye también que no es crítico, ni prioritaria la inclusión de planes de
operación alterna, ni de medidas de contingencia; en su reemplazo, con la definición
de un plan de recuperación, que incluya RTO y RPO precisos se puede controlar la
situación de desastre.

14.2.2. Respecto de la operación en los CCO

Con respecto a la operación de los CCO en los administradores viales y entes
territoriales, la especificación técnica mínima para la implantación deberá tenerse en
cuenta en los proceso de: instalación de hardware, configuraciones de tolerancia a
fallos, contingencia y de respaldo, que permita mantener la solución en alta
disponibilidad; para esto se propone contar con lo siguiente:

 Tecnologías de alta disponibilidad para el procesamiento, como por ejemplo,

sistemas de procesamiento paralelo, basados en clúster.

 Sistemas de arreglos en espejo (RAID) para la instalación del software y el

almacenamiento de la información considerada como primordial

 Equipos de cómputo con fuentes de energía redundantes.

 Medios de comunicación redundantes entre los equipos y las redes locales

redundantes. Para conexiones por medio físico, contar con más de una tarjeta de red
por equipo y en el caso de conexiones inalámbricas, disponer de otros medios en
caso de fallas de comunicación de los medios principales.

 En cuanto a las instalaciones donde se mantendrán los equipos de cómputo,

deben contar con los subsistemas necesarios y mínimos, de control de acceso,
monitoreo CCTV, soporte eléctrico y ambiental (Aire Acondicionado y Equipos de
Extinción de incendios) que garanticen la operación del centro de control y la
seguridad del personal operativo y cableado estructurado para las redes de datos.

14.3. ACTORES Y OTROS INVOLUCRADOS

En este contexto, un actor es cualquier persona o entidad que interactúa con el
módulo ITS existente. Los factores que distinguen a un actor incluyen las
responsabilidades comunes, niveles de habilidad, las actividades de trabajo y modos
de interacción con el sistema. Los diferentes actores pueden tener distintos
escenarios operacionales para sus interacciones con el sistema. Para todo esto se
consideran los esquemas de datos abiertos propuesto por MINTIC.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

51
14.3.1. Estructura Organizacional
Las definiciones realizadas por el módulo ITS propuesto en cuanto al Esquema
Institucional Sector Transporte no generan cambios, razón por la cual su estructura se
mantiene tal como se encuentra definido en la situación actual; las entidades adscritas
ANI e INVIAS, así como las secretarías de infraestructura y de movilidad o Tránsito de
los entes territoriales a pesar de no ver afectada su estructura organizacional si se
impactan operativamente en la medida del cambio del mecanismo de registro de
instalación de equipos de VMS al Ministerio de Transporte, otorgando nuevas
responsabilidades que pueden ser asumidas por las oficinas técnicas encargadas de
los procesos de suministro de información, o a quienes están deleguen vía
concesiones o contratos.

a. Ministerio de Transporte
El Ministerio de Transporte no ve impactada su estructura organizacional en la medida
que la inclusión de las funcionalidades requeridas para la operación de este módulo
de ITS va a estar integrado al SINITT e interactúa con otros módulos de la
arquitectura dispuesta para el suministro de servicios.

b. ANI
En el Concepto de Operación propuesto, se deben incorporar ajustes en los procesos
que ejecuta la ANI, en la medida que los Concesionarios deberán adelantar el registro
de los equipos en operación, así como para los nuevos equipos que se vayan a
suministrar, tanto fijos como móviles. Así mismo, deberán ajustarse las
especificaciones y reglas de operación, con la inclusión de la funcionalidad de
interoperabilidad entre los mensajes que requiera desplegar el Ministerio en el Nivel
Nacional, Regional o Subregional.

c. INVIAS
Aunque actualmente el INVIAS no despliega información vía VMS, el Concepto de
Operación posibilitará que los equipos que vayan a integrar a futuro cumplan los
objetivos de la política pública.

d. Dirección de Tránsito y transporte DITRA

Cuerpo especializado de la Policía Nacional, que tiene como funciones: Ejercer
control de las normas de tránsito y brindar seguridad y tranquilidad a los usuarios de
la red vial nacional de Colombia tanto Urbana como Rural. Además de mantener el
orden en puertos marítimos, aeropuertos, vías férreas, terminales de transporte,
peajes, entre otros.

El Concepto de Operación implica una modificación a las condiciones con las que
actualmente la DITRA desarrolla sus funciones en relación con el despliegue y
utilización de los elementos de VMS. En primer lugar, se debe integrar en el nivel
Nacional o Regional de un CCO que permita la centralización de la operación de los
distintos equipos que se encuentran en operación y que no están vinculados a
Convenios con Concesionarios ANI o de niveles territoriales.

Asimismo, deberán promoverse ajustes en cuanto a especificaciones de los equipos,

para garantizar interoperabilidad, uniformidad y estandarización en el suministro de
mensajes y la disponibilidad para interconexión desde la funcionalidad centralizada
para despliegue de mensajes que desarrollará este módulo ITS.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

52
En cuanto al registro de los equipos, deberá integrarse un proceso para los equipos
existentes con el incentivo suficiente para que migren al registro. (pej, la posibilidad de
consumir otros servicios del SINITT). Para los nuevos debe ser una exigencia previa a
su puesta en funcionamiento.

e. ANSV Agencia Nacional de Seguridad Vial

Es la entidad encargada de la planificación, articulación y gestión de la seguridad vial
del país. Tiene a cargo ser el soporte institucional y de coordinación para la ejecución,
el seguimiento y el control de las estrategias, los planes y las acciones dirigidos a dar
cumplimiento a los objetivos de las políticas de seguridad vial del Gobierno Nacional
en todo el territorio Nacional.
En la medida que los mensajes a desplegar deben tener un carácter unificado y que
no obstante, la existencia del Manual, no existe un registro que documente el
cumplimiento y acatamiento de lo establecido por el Manual, corresponde a la ANSV y
al INVIAS la actualización y complementación del diccionario de mensajes
especializado, así como la revisión de características locales que justifiquen posibles
ajustes. El control de uso y acatamiento, debe ser auditado por las Interventorias y de
manera general por la Superintendencia de Puertos y Transporte.

f. Entidades Territoriales
Deberán promover ajustes en cuanto a las especificaciones de los equipos, para
garantizar interoperabilidad, uniformidad y estandarización en el suministro de
mensajes y la disponibilidad para interconexión desde la funcionalidad centralizada
para despliegue de mensajes que desarrollará este módulo ITS.
En cuanto al registro de los equipos, deberá integrarse un proceso para los equipos
existentes con el incentivo suficiente para que migren al registro. (pej, la posibilidad de
consumir otros servciios dei SINIT). Para los nuevos debe ser una exigencia previa a
su puesta en funcionamiento.

g. Operadores Tecnológicos
Los operadores tecnológicos deberán ajustar los dispositivos (hardware y software) a
los nuevos requerimientos definidos en el Concepto de Operación.

h. Concesionarios
Para los concesionarios, se presentan ajustes en los esquemas de operación que
actualmente tienen. En primer lugar, el registro de los equipos. Así mismo, la
integración a la funcionalidad por demanda que activará el ministerio de carácter
Nacional, Regional y Subregional para informar a los usuarios sobre los eventos que
se consideren de nivel de afectación grave.

i. Usuarios
Persona natural o jurídica que hace uso de la infraestructura vial y de transporte,
pública o privada que conforma la red vial Nacional en cualquiera de sus
modalidades.

14.3.2. Interacción entre Actores

Se describen las interacciones entre los distintos actores que participan en el módulo
ITS propuesto. Las interacciones que se producen entre los actores principales del
sistema, y entre usuarios y no usuarios del sistema, visto desde una perspectiva
misional del módulo ITS. También son descritas las interacciones formales, así como
las informales.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

53
 ENTIDADES CORPORACIONES MINISTERIO DE
CONTRATISTAS CONCESIONARIOS INTERVENTOR INVIAS ANI ANSV DITRA CONGRESO
TERRITORIALES PUBLICAS TRANSPORTE
CONTRATO /
CONCESIÓN

Suministrar
á Administran Insumos y
Corredores viales en Estudios a
· Definen Política de
á Suministran Equipos Concesión. ANSV sobre
ENTIDADES Movilidad y Seguridad Vial. á Reportan
de VMS . Deben activar Seguridad
TERRITORIALES Construyen Planes y Avance Metas
despliegue de Vial. Linea
Proyectos
mensajes por Base, Planes,
Demanda de MT Programas y
Proyectos

CORPORACIONES á Aprueban Planes

PÚBLICAS Regionales y Municipales
Registran equipos
Actuales de VMS
Registran Nuevos
á Documentan Equipos VMS
Estadisticas de Integran
accidentalidad, funcionalidades
CONTRATISTAS Eventos en Vias y por Servicios en
desarrollan dispositivos.
Estudios Técnicos Activan Mensajes
e Instalación de a partir de
VMS. funcionalidad
activada por MT.

á Documentan
Estadisticas de
accidentalidad,
Eventos en Vias y
desarrollan
CONCESIONARIOS Estudios Técnicos
e Instalación de
VMS.
Activan Mensajes
a partir de
Funcionalidad de
MT.

á Reportan á Reportan
á Reportan Ejecución Físico Ejecución Ejecución
INTERVENTOR
Financiera Físico Físico
Financiera Financiera
CONTRATO /
CONCESIÓN

Anexo Técnico de la Resolución XXXXX de XXXX, De acuerdo al artículo 2.5.3.2. Subsistemas del Sinitt del Título 3 del Decreto 1079 de 2015

54
 ENTIDADES CORPORACIONES MINISTERIO DE
CONTRATISTAS CONCESIONARIOS INTERVENTOR INVIAS ANI ANSV DITRA CONGRESO
TERRITORIALES PUBLICAS TRANSPORTE
CONTRATO /
CONCESIÓN

á Realizan Contratos
de Obras. No suele
incluir componente de
VMS.
Registrar equipos de á Reportan
VMS
Avance Metas
Integrar VMS que
implemente en CCO
Despliega Mensaje a
partir de funcionalidad
activada por MT.
INVIAS

á Realizan Contratos
de Concesión.
Incluyen Estudios,
Implementación y
Mantenimiento de
VMS bajo esquema á Reportan
ANI
ITS Local por Avance Metas
Concesión.
Debe Supervisar que
se registren los
equipos de VMS
Existentes y Nuevos

· Construyen Planes PNSV,

Proyectos. Definen Política
Pública para Seguridad Vial á Reportan
ANSV
de carácter Vinculante. Avance Metas

· Apoya
mediante
convenios
á Apoya mediante Control en
· Apoya mediante
convenios Control en Vías. Vías
convenios Control en
Proveer CCO para Concesionada
Vías Concesionadas.
administrar Dispositivos s.
DITRA Desplegar mensajes a
desplegados Registrar
partir de activación
Desplegar mensajes a partir equipos
funcionalidad MT
de activación funcionalidad asignados por
MT Convenio. En
operación y
Nuevos.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

55
 ENTIDADES CORPORACIONES MINISTERIO DE
CONTRATISTAS CONCESIONARIOS INTERVENTOR INVIAS ANI ANSV DITRA CONGRESO
TERRITORIALES PUBLICAS TRANSPORTE
CONTRATO /
CONCESIÓN

á Construyen á Construyen á Construyen

Planes PNSV, Planes PNSV, Planes PNSV,
á Construyen Planes. Plan Proyectos. Proyectos. Proyectos.
Nacional de Seguridad Vial. Definen Definen Definen
Plan Maestro de Transporte Política Política Política
MINISTERIO DE Intermodal PMTI. Pública Pública Pública á Aprueba
TRANSPORTE Proyectos. Definen Política Sectorial y Sectorial y Sectorial y
PND
Pública Sectorial y adoptan adoptan adoptan adoptan
especificaciones para especificacion especificacion especificacion
Señalización y Demarcación, es para es para es para
incluido VMS. Señalización y Señalización y Señalización y
Demarcación, Demarcación, Demarcación,
incluido VMS. incluido VMS. incluido VMS.

· Establece Legislación de
Carácter General en Materia
CONGRESO de Tránsito y Transporte

Tabla 3 Matriz de Relación de Actores - Descripción Módulo ITS VMS Propuesto

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

56
14.3.3. Otros Involucrados
No se presentan cambios para los otros involucrados cuerpos colegiados Congreso,
Asambleas Departamentales y Concejos Municipales.

14.4. ENTORNO DE SOPORTE

En esta sección se presenta el entorno operacional y de soporte del sistema, realizando una
descripción general en función de componentes de software y de hardware necesarios para
el funcionamiento del mismo.

14.4.1. Componentes de Software

Se describen los componentes de software que conforman la solución del módulo ITS
propuesto y serán vistos más adelante en la sección 17 Requisitos de Software

14.4.2. Componentes de Hardware

Se describen los componentes de hardware que conforman la solución del módulo ITS
propuesto y serán vistos más adelante en la sección 16 Requisitos de Hardware

14.4.3. Componentes de Seguridad

Se debe tener en cuenta los requerimientos de seguridad para los tres componentes de la
solución, estos complementan los requerimientos de software, hardware y comunicaciones
y son abordados y están inmersos en los requisitos tanto de hardware como de software
propuestos.

15. ESCENARIOS OPERACIONALES

En esta sección se describen los escenarios operacionales propuestos para la gestión de
equipos VMS en la red vial y en sus distintas categorías, un escenario es una descripción
del paso a paso de cómo el módulo ITS de VMS debe ser operado e interactuar con sus
actores y cualquier otra interface externa u otros sistemas bajo ciertas circunstancias.
Los escenarios están presentados en apartados, cada uno describiendo a manera de
secuencia el rol asumido por el módulo ITS propuesto y sus interacciones con los usuarios y
otros sistemas, se incluyen los eventos, las acciones e información de manera apropiada
para proveer una correcta comprensión de los aspectos operacionales del módulo ITS.

15.1. DESPLIEGUE EQUIPO VMS

La operación de Señales de Mensaje Variable implica claramente el despliegue de equipos
VMS en la vía y su correspondiente proceso de administración, para lograr este cometido la
primera actividad es la adquisición e instalación física de los equipos, se continúa con la

Anexo Técnico de la Resolución XXXXX de XXXX, De acuerdo al artículo 2.5.3.2. Subsistemas del Sinitt del
Título 3 del Decreto 1079 de 2015

57
instalación y configuración de una plataforma en un CCO y su correspondiente esquema de
comunicaciones que permita su administración remota.

15.1.1. Adquisición e Instalación Física

Con base en las especificaciones técnicas mínimas descritas por el módulo ITS propuesto,
los actores administradores viales y entes territoriales deben llevar a cabo sus procesos de
adquisición de equipos VMS con las características de diseño y físicas apropiadas y que
respondan a las exigencias dictadas por la especificación. La instalación física de los
equipos debe ser realizada aplicando los criterios unificados sobre su localización teniendo
en cuenta características técnicas mínimas para instalación, ubicación, señalización y
demarcación.

15.1.2. Instalación y Configuración de la Plataforma de Gestión CCO

Los actores administradores viales y entes territoriales deben realizar la construcción física
de su CCO y con base en las especificaciones técnicas mínimas descritas por el módulo
ITS propuesta, llevar a cabo el proceso de instalación y configuración de la plataforma para
la gestión remota de los equipos VMS.

15.1.3. Instalación y Configuración Conectividad con el CCO

Los actores administradores viales y entes territoriales deben realizar la instalación y
posterior validación de la conectividad con cada uno de los equipos VMS dispuestos a lo
largo de la vía de su jurisdicción, de manera que desde el CCO se pueda acceder a su
configuración y monitorear su estado.

15.2. ADMINISTRACIÓN REMOTA DE EQUIPOS VMS

Uno de los fundamentos del módulo ITS propuesto es que los administradores viales y
entes territoriales tengan la capacidad de administración de los equipos VMS desde un
centro de control operacional CCO remoto, brindando funcionalidad y capacidad de acción
instantánea sobre todos los equipos ubicados a lo largo de las vías de su jurisdicción. En
este sub apartado se describen los escenarios de operación que deben poder efectuarse en
el CCO por un actor operador.

15.2.1. Configuración Banco de Mensajes y Pictogramas

Con base en el diccionario de mensajes estandarizado propuesto por este módulo ITS y
perfeccionado por la ANSV el operador del CCO debe realizar la configuración de un banco
de mensajes y pictogramas apropiado, el cual debe estar disponibles para la operación
diaria de la vía. A partir de los escenarios de uso propuestos deberá seleccionar el mensaje
y pictograma (cuando sea necesario o aplicable) correspondiente a la situación presentada
en la operación.

15.2.2. Gestionar Equipos VMS

El operador a través de una funcionalidad de la plataforma de gestión podrá realizar la
gestión funcional de los equipos VMS, significando esto que, acorde a situaciones propias
de la operación de la vía o cuando sea meritorio deberá actualizar el mensaje y/o

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

58
pictograma en un(os) equipo(s) VMS en específico(s), para lo cual, deberá mediante esta
funcionalidad seleccionar por ubicación geográfica o nombre un equipo VMS en particular,
seleccionar un mensaje de la base de datos o banco de mensajes y pictogramas apoyado
de un árbol de decisión, y enviar la solicitud de actualización de configuración del equipo, la
plataforma se encarga de enviar la petición de modificación del mensaje al equipo VMS
físico respectivo.

15.2.3. Gestionar Estado Operativo Equipos VMS

Mediante una funcionalidad de tablero de control el operador del CCO deberá monitorear
constantemente y acorde a una programación realizada para el CCO el estado de los
equipos VMS dispuestos en la vía. En el tablero el operador podrá consultar en un mapa
geográfico el estado operativo de cada uno de los equipos VMS, así como los detalles
propios del equipo: Mensaje, Pictograma, Alarmas y otros datos relevantes.

15.2.4. Gestionar Mantenimientos Preventivos y Correctivos

El operador del CCO mediante una funcionalidad de la plataforma de gestión podrá realizar
la programación de mantenimientos preventivos a los equipos VMS dispuestos en la vía,
tomando como base las recomendaciones de operación sugeridas por este módulo ITS. La
plataforma de gestión acorde a la programación realizada envía notificaciones recordatorias
por correo electrónico o cualquier otro medio que cumpla dicha función, al operador o
personal responsable del mantenimiento. Mediante una funcionalidad el operador del CCO
o personal responsable del mantenimiento deberá registrar el informe de las acciones
aplicadas al equipo VMS. Adicionalmente, en caso de alguna falla detectada mediante el
tablero de control el operador del CCO deberá lanzar una programación de mantenimiento
correctivo del equipo VMS, esta deberá llevarse a cabo tal cual la operación de un
mantenimiento preventivo.

15.2.5. Reportar datos Equipos VMS a SiGVMS

La plataforma de gestión del CCO deberá estar en capacidades de enviar de manera
automática al SiGVMS datos acerca de los equipos VMS dispuestos en la vía y que se
encuentren en estado operativo funcional, esto deberá ser realizado en las siguientes
situaciones:
1. al instalar y colocar en funcionamiento un nuevo equipo VMS,
2. cuando un equipo VMS operativo y funcional salga de operación por razones
atribuibles a mantenimientos o fallas técnicas,
3. cuando un equipo VMS sea colocado en completa operación posterior a un
mantenimiento correctivo.

En cualquiera de los casos deberán ser enviados los datos básicos del equipo: Identificador,
ubicación geográfica – en coordenadas geográficas –, proveedor, estado, último mensaje y
pictograma desplegado, tipo de equipo, marca, tamaño y otras características físicas y
técnicas necesarias.

15.3. ADMINISTRACIÓN LOCAL EQUIPO VMS

Un actor operario deberá tener las capacidades para realizar los procesos de
mantenimientos preventivos y correctivos de los equipos VMS, así como cualquier otra

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

59
operación que sea necesaria realizar directamente sobre el equipo; este actor deberá tener
pleno conocimiento acerca de las reglas de uso y condiciones de operación de los equipos
VMS recomendadas por este módulo ITS. A continuación las actividades fundamentales:

15.3.1. Realizar Instalación y Configuración

El actor operario soportado en la plataforma de gestión local conectada en el equipo VMS a
través de los puertos locales podrá realizar la configuración y adecuación necesaria en el
equipo, los procesos realizados deberán ser reportadas a la plataforma de gestión del CCO
de manera automática una vez el equipo VMS entre en completa operación.
15.3.2. Realizar Mantenimiento
Con base en una programación de mantenimiento preventivo o correctivo el operario de
mantenimientos se acerca a un equipo VMS que así lo requiera, se conecta mediante los
puestos locales disponibles y realiza las operaciones de configuración y adecuación
necesarias en el equipo, los procesos realizados deberán ser reportadas a la plataforma de
gestión del CCO de manera automática una vez el equipo VMS entre en completa
operación. En caso que el equipo posterior al mantenimiento quede fuera de línea, el
operador deberá realizar un informe de mantenimiento correspondiente en la plataforma de
gestión en el CCO.

15.3.3. Realizar Traslado Físico

Los dispositivos móviles o estacionarios dada su definición, podrán ser traslados a distintas
ubicaciones geográficas y con base en la operación diaria de la vía, un actor operario y
responsable de los traslados, deberá contar con el conocimiento, capacidades y
mecanismos necesarios para dicho fin, soportado en las recomendaciones suministradas
por este módulo ITS en lo que respecta a movimientos y traslados de equipos VMS.
Por otra parte, es deber del Ministerio de Transporte mencionar que teniendo de referencia
el estándar ISO 14813.1, existen servicios ITS de seguridad nacional y de manejo de
emergencias, por ello, a continuación, se presenta un requerimiento adicional que debe ser
considerado por los actores estratégicos que estén involucrados en el despliegue, operación
de Sistemas de Mensaje variable.

15.4. DIFUSIÓN DE MENSAJE DE INTERÉS NACIONAL

El despacho del Ministro o el funcionario o entidad que él considere responsable contará
con una funcionalidad que le permita realizar la difusión de un mensaje de interés nacional
de manera automática a todos los equipos VMS de una misma zona geográfica, o en el
mayor de los casos, de todo el país. La funcionalidad estará disponible en la plataforma
SiGVMS del SINITT y para su correcto uso el actor deberá ejecutar los siguientes pasos:

1. Ingresar a la funcionalidad en la plataforma SIGVMS, únicamente está disponible

para el actor despacho del Ministro u otro actor autorizado por el Ministro.
2. Seleccionar la zona geográfica de interés, contando con distintos filtros que permitan
seleccionar departamentos, municipios, cabeceras municipales o tramos viales
necesarios para difusión del mensaje.
3. Visualizar el listado de equipos VMS cubiertos por la zona seleccionada. En el
listado se deberá visualizar como mínimo el tipo de VMS, administrador vial o ente
territorial responsable y ubicación geográfica.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

60
 4. Seleccionar de una base de mensajes y pictogramas el mensaje apropiado acorde a
la situación, se desplegará un árbol de decisión para definir el mensaje más
apropiado.
5. La plataforma SiGVMS envía la petición a todos los CCO desde donde se
administran los equipos VMS seleccionados e involucrados en el proceso.
6. La Plataforma de gestión de cada CCO transmite la petición directamente a cada
equipo VMS desplegado en campo.
7. El mediador implementado en cada Equipo VMS recibe la petición y actualiza la
configuración del equipo, desplegándose así el mensaje y pictograma indicado.
15.5. CONSULTA INFORMACIÓN OPERACIÓN VMS EN COLOMBIA
El despacho del Ministro o el funcionario o entidad que él considere responsable contará
una funcionalidad que le permita consultar la información de la operación de equipos VMS
en todo el país, podrá mediante un mapa geográfico visualizar la ubicación de los distintos
equipos VMS, sus datos básicos y su condición de funcionamiento e información
desplegada. La funcionalidad estará disponible en la plataforma SiGVMS del SINITT y para
su correcto uso el actor deberá ejecutar los siguientes pasos:
1. Ingresar a la funcionalidad en la plataforma SIGVMS, únicamente está disponible
para el actor despacho del Ministro u otro actor autorizado por el Ministro.
2. Seleccionar la zona geográfica de interés, contando con distintos filtros que permitan
seleccionar departamentos, municipios, cabeceras municipales o tramos viales
necesarios para difusión del mensaje.
3. Visualizar el listado de equipos VMS cubiertos por la zona seleccionada. En el
listado se deberá visualizar como mínimo:
a. el tipo de VMS,
b. El administrador vial o ente territorial responsable,
c. Datos de ubicación geográfica,
d. Datos básicos característicos del VMS,
e. Última información de operación reportada: Mensaje, Pictograma y Estado
operativo.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

61
16. DESCRIPCIÓN DE LOS REQUISITOS DE HARDWARE

Para el alcance del presente documento, los requisitos de hardware utilizarán la

clasificación de localización de los equipos, como VMS Fijos o VMS portátiles.

16.1. SEÑALES DE MENSAJE VARIABLE FIJAS (VMS)

Se han clasificado estos requisitos en: Requisitos Funcionales, Requisitos de Usabilidad,
Requisitos de Confiabilidad, Requisitos de Rendimiento, Requisitos de Soporte, Requisitos
de Mantenimiento, Requisitos para las Interfaces de comunicaciones y Requisitos de
Seguridad. La clasificación presentada se establece con el fin de que sea posible concentrar
en grupos específicos las exigencias de cumplimiento a que deben ser sometidos todos los
VMS, independientemente del fabricante, país de origen e incluso estándar nacional o
internacional bajo el cual se diseñe o integre el ITS del que hagan parte estas señales.

Varios de los requisitos presentados pueden ser parte de más de una de las categorías
presentadas independientemente de la norma o estándar que quiera adoptar el comprador.
A continuación se describen los requisitos de los módulos o componentes de visualización
de elementos led del VMS asociados con prestaciones visuales de los elementos led del
VMS.

a. Requisitos de prestaciones visuales de VMS

 RHF001: El equipo VMS debe permitir la visualización de mensajes y señales de

tránsito exclusivamente.

 RHF002: El equipo VMS debe estar clasificado de acuerdo con parámetros fotométricos
(parámetros de prestaciones visuales) de color, luminancia, relación de luminancia y
ancho (amplitud o anchura) de haz establecidos en el numeral 4.4 de la norma EN
12966. Los parámetros de fotometría deben ser exigidos en concordancia con el tipo de
uso o aplicación específica de la señal, a las condiciones de infraestructura de la vía y a
las condiciones ambientales en las cuales se desplegará el equipo.

 RHF003: Las características de cromaticidad de las pantallas VMS debe corresponder a

las recomendaciones de color según se define en la sección 4.4.2 de la norma EN
12966.

 RHF004: El fabricante debe garantizar que sus equipos cumplen con recomendaciones
de Colorimetría de publicaciones especializadas tales como la Publicación CIE Nº 15.2
Colorimetría, Publicación CIE No. 17.4 Vocabulario internacional de iluminación y/o CIE
Norma No. S 004 / E Colores de señales luminosas. Deberán ser contempladas
características de cromaticidad para Señales de mensaje variable con y sin inversión de
color.

 RHF005: Las características de luminancia de las pantallas VMS debe corresponder a

las recomendaciones que se definen en la sección luminancia, numeral 4.4.3 de la
norma EN 12966, las cuales deberán ser contrastadas con el tipo de aplicación o uso, y
con las condiciones externas de iluminación provenientes de fuentes naturales o
artificiales en las cuales se desplegarán las señales.
Para uso en túneles se deben considerar las recomendaciones que para tal fin entrega
la norma EN 12966 en el numeral 4.4.3 para este parámetro fotométrico.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

62
 RHF006: El equipo VMS debe contar con características tipo matricial que permita el
despliegue de múltiples líneas de mensajes de texto y de pictogramas de forma
simultánea. Las dimensiones de letras, la relación de altura y anchura y el
espaciamiento de caracteres debe estar acorde a lo que establece el Manual de
señalización, las especificaciones de la norma EN 12966 en su anexo N y las
condiciones de uso que se le dará al equipo VMS en la vía.

 RHF007: El ancho del haz debe ajustarse a la clasificación que para tal parámetro
especifique la norma en el numeral 4.4.5, acorde con el uso o aplicación de la señal,
adicionalmente se deben realizar los ensayos de los componentes de acuerdo las tablas
24 a 27 del numeral 5.5.2. (ángulos de ensayo). Así por ejemplo en la norma EN 12966
un ancho de haz de clasificación B7 es el más recomendable para aplicaciones
especiales donde se requieren anchos de haz horizontal y vertical muy amplios, como
en áreas urbanas en donde la velocidad de aproximación es lenta y la distancia de
legibilidad es corta para usuarios como ciclistas o peatones.
La medición del ancho de haz se realiza de conformidad con la sección 5.5.5 de la
norma EN 12966.

 RHF008: Las condiciones de uniformidad de las pantallas VMS deben corresponder a

las recomendaciones que se definen en la sección 5.4.6 de la norma EN 12966.
La uniformidad de la intensidad luminosa se aplicará a cada color separado, teniendo en
cuenta consideraciones de iluminación, anchura del haz.

 RHF009: No debe ser visible ningún parpadeo en las pantallas PVMS de acuerdo con lo
considerado en la sección 4.4.7 de la norma EN 12966.
La medición del parpadeo visible se realiza de conformidad con la sección 5.5.7 de la
norma EN 12966.

 RHF010: Los módulos de visualización led serán totalmente intercambiables. Un módulo

de visualización de led puede consistir en una o dos placas de circuito. Los módulos
deben ser de fácil extracción, haciendo uso de herramientas genéricas y los led deben
estar montados individualmente directamente en una placa de circuito impreso.

 RHF011: La matriz de led debe estar compuesta de múltiples pixeles y cada pixel debe
estar conformado por 4 led. Cada píxel consistirá de un mínimo de una serie
independiente de led discretos para cada color

 RHF012: El fallo de un píxel no causará el fallo de los demás píxeles en el VMS.

La extracción o falla de un módulo de led no debe afectar el funcionamiento de ningún
otro módulo de led. La remoción de uno o más módulos led y no afectará la integridad
estructural de ninguna parte de la señal.

 RHF0013: Cada píxel deberá contener la cantidad de led discretos necesarios para
emitir luz con una intensidad luminosa que debe corresponder a las recomendaciones
que se definen en la sección 4.4.3 de la norma EN 12966. La intensidad luminosa debe
ajustarse de acuerdo a resultados de estudios en campo según la zona geográfica, las
condiciones climáticas y de intensidad de luminosidad externa en el que este expuesto
el equipo.

 RHF014: Los paquetes de led deben fabricarse de epoxi, resistente a la luz UV. Los led
también deben estar protegidos de las condiciones ambientales externas, incluyendo la
humedad, el viento, el polvo, la arena y la suciedad.

 RHF015: Cada placa de control de led debe comunicarse con la unidad de control del

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

63
 VMS utilizando un protocolo de red direccionable.

 RHF016: La unidad de control del VMS medirá y monitoreará continuamente todas las
tensiones de la fuente de alimentación del módulo de led y proporcionará las lecturas de
voltaje a la unidad de control del VMS o al equipo portátil de administración local.

 RHF017: La medición de la luminancia y la relación de luminancia se realizará de

conformidad con la sección 5.5.4 de la norma EN 12966.

 RHF018: El diseño del VMS debe tener en cuenta el impacto sobre las prestaciones
visuales, causadas por el tiempo de uso del VMS (envejecimiento del equipo), las
prestaciones visuales deben ser revisadas durante la vida útil del equipo. Las
consideraciones de diseño en cuanto a este tema deben estar acordes a lo contemplado
en el numeral 4.4.8 de la norma EN 12966.

 RHF019: El VMS debe soportar las vibraciones generadas en la vía de acuerdo con lo
establecido en la sección 4.5.2.5.5 y mediante ensayos de los componentes del VMS de
acuerdo la tabla 19 (Ensayos de vibraciones) del numeral 5.4.3 de la norma EN 12966.
Dichas vibraciones no deben afectar la vida útil del VMS.

b. Requisitos Funcionales de Caracteres, Fuentes y Color

En este literal se describen los requisitos asociados con caracteres, fuentes y color con que
deben contar las señales de mensaje variable fijas.
 RHF020: Teniendo en cuenta la amplia gama de aplicaciones y tecnologías, la gama de
tamaños y los diversos requisitos de caracteres y símbolos, en cada caso se deberán
especificar las necesidades y tipologías de fuentes, caracteres y colores requeridos por
el comprador. Las consideraciones de caracteres, fuentes y requisitos de color del
estándar EN 12966 están dadas en los numerales 4.4.2.

 RHF021: Las definiciones correspondientes a las dimensiones, la forma, parámetros

físicos, el tamaño de los caracteres, las tolerancias y el espaciamiento de los caracteres
deben ser los requeridos por el comprador, teniendo en cuenta las consideraciones del
numeral 4.1 de la norma EN 12966 y el Anexo A (Área Equivalente). Las dimensiones
de los caracteres y símbolos deberán ser definidas utilizando una estrategia de área
equivalente, que haga posible comparar tecnologías. Para el diseño de los mensajes
que se presentan en un VMS se debe tener en cuenta, adicional al área equivalente, las
consideraciones de diseño de mensajes del Anexo P (Indicaciones para el diseño de
mensajes de un PMV) de la norma EN 12966.

 RHF022: Para la especificación de las dimensiones del mensaje VMS se utilizarán las
dimensiones equivalentes en lugar de las dimensiones físicas. Las dimensiones de texto
más importantes, es decir, la altura de los caracteres, el ancho de los caracteres, el
largo de la línea, el espaciado de los caracteres, el espaciado de las palabras y el
espaciado de línea, se deberán especificar usando dimensiones equivalentes.

 RHF023: El área de visualización de texto del VMS debe estar en capacidad de soportar
las dimensiones de caracteres, la relación de altura y anchura y espaciamiento de
caracteres como se describe en el Manual de Señalización vigente para el País.
Adicionalmente se deben tener en cuenta las indicaciones de los anexos M
(indicaciones sobre gráficos de señales emisoras de luz discontinua) y N (indicaciones
sobre las dimensiones, luminancia, anchura de haz, legibilidad y eficiencia para PMV
discontinuos) de la norma EN 12966.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

64
 RHF024: El equipo VMS debe estar en la capacidad de mostrar los caracteres desde el
32 al 126 del Código Estándar Americano para el Intercambio de Información (ASCII),
incluyendo todas las letras mayúsculas y minúsculas y los dígitos de 0 a 9, en cualquier
lugar del área de visualización.

 RHF025: El VMS deberá poder mostrar pictogramas, señales de tránsito, conforme a las
especificaciones de dimensiones, colores, entre otras, dadas en el Manual de
Señalización vigente para el país y las indicaciones de los anexos M (indicaciones sobre
gráficos de señales emisoras de luz discontinua) y N (indicaciones sobre las
dimensiones, luminancia, anchura de haz, legibilidad y eficiencia para PMV
discontinuos) de la norma EN 12966.

 RHF026: Las fuentes preinstaladas en el equipo VMS tendrán dimensiones de

caracteres que cumplan las especificaciones del Manual de Señalización vigente para el
País. El ancho de la señal, y por lo tanto el número de caracteres por línea, debe cubrir
todo el ancho de los carriles de la calzada en el lugar que se vaya a instalar.

 RHF027: Un VMS matricial en el área de pictograma, tendrá definidos los colores que le
permitan presentar las señales de tránsito del Manual de Señalización vigente para el
País, así como los requisitos particulares de la aplicación en que deban ser utilizados.

 RHF028: La designación de clase del parámetro fotométrico de color (C1/C2), debe

estar a cargo del proveedor del equipo. Los colores emitidos por los led deben ajustarse
a lo indicado en la sección 4.4.2 de la norma EN 12966.

 RHF029: Las pruebas de los colores de los led deben ser llevadas a cabo de acuerdo
con lo establecido en la sección 5.5.3 de la norma EN 12966.

 RHF030: Los mensajes de texto que no correspondan a señales reglamentarias o

preventivas, presentados en el equipo VMS deberán ser mostrados en color ámbar, tal
como lo establece el Manual de Señalización Vial vigente para el país.

c. Requisitos de la Unidad de Control del VMS

A continuación serán descritos los requisitos con que debe contar la Unidad de Control de
los equipos VMS.
 RHF031: Los VMS deben incorporar puertos de consola que permitan conectar de
forma local el equipo de administración para labores de mantenimiento y pruebas del
sistema.

 RHF032: La unidad de control del VMS deberá ser un sistema autónomo basado en
microprocesador que permite gestionar el VMS, la cual no requiere de comunicación
continua con el software de gestión central ubicado en el CCO.

 RHF033: La unidad de control del VMS debe tener la capacidad en disco para
almacenar la totalidad de los mensajes ya sean cambiables o permanentes, las
programaciones y otros archivos necesarios para el funcionamiento de equipo de
monitoreo y gestión de los VMS.

d. Requisitos de Usabilidad

 RHF034: La unidad de control del VMS debe Incluir una interface de usuario en una

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

65
 pantalla LCD gráfica o una interfaz portátil, como mínimo, que permita la gestión del
funcionamiento, la parametrización y el diagnóstico local.

 RHF035: La Unidad de Control del VMS debe tener la capacidad de mostrar los
mensajes en formato de texto enviados de forma remota desde el CCO.

 RHF036: La unidad de control debe contar con software embebido, el cual debe estar
en capacidad de interpretar todos los comandos y los parámetros enviados desde el
aplicativo de gestión remota al VMS y realizar el control de los módulos de visualización
y reajustarlos, monitorear los sensores internos y externos del VMS y las interfaces de
comunicación.

 RHF037: Desde el CCO se debe tener la capacidad a través de la unidad de control del
VMS de modificar remotamente parámetros fotométricos de la matriz de visualización
led de forma manual o automática en función de las condiciones de iluminación
ambiental.

 RHF038: La unidad de control del VMS debe tener la capacidad de permitir la

modificación local o remota del brillo de la matriz de visualización led, ya sea de forma
manual o automática en función de las condiciones de iluminación ambiental.

 RHF039: La unidad de control del VMS debe ser capaz de monitorear y presentar en la
pantalla LCD o de forma remota en el CCO, el mensaje actualmente activo incluyendo
los pictogramas. Esta pantalla debe ser una representación de la pantalla VMS física.

 RHF040: La unidad de control del VMS debe estar en la capacidad de detectar

automáticamente y en tiempo real el estado de cada uno de los píxeles de la pantalla y
reportar su estado de encendido / apagado.

 RHF041: La unidad de control del VMS deberá supervisar e informar del estado de
todos los componentes, monitorear las señales generadas por los sensores de luz,
temperatura y humedad instalados en el gabinete del VMS, así como también de la
operación de los ventiladores y estado de las fuentes de alimentación. Para el caso de
los sensores de temperatura interna del VMS, debe estar en capacidad de apagará
automáticamente el VMS si la temperatura interna del gabinete excede un umbral de
seguridad, el cual puede tener un valor por defecto de + 60º centígrados y que puede
ser parametrizable según sean las condiciones ambientales.

 RHF042: La unidad de control del VMS debe ser capaz de informar automáticamente al
operario (a través del panel LCD local) y el software del CCO, sobre la ocurrencia de
eventos importantes, detecte que se ha apagado automáticamente, reiniciado de forma
manual o cualquier condición de error incluidos fallos de alimentación.

e. Requisitos Estructurales

En el presente literal se describen los requisitos asociados a prestaciones mecánicas con

que deben contar los equipos VMS.
 RHF043: El rendimiento mecánico incluidos sus soportes y fijaciones - excluyendo los
voladizos y los pórticos - debe ser conforme a acorde a lo establecido en el numeral
4.5.2.5 de la norma EN 12966.
El VMS deberá estar diseñado para asegurar una transferencia fiable de todas las
fuerzas estáticas y dinámicas a las estructuras de fijación y montaje. Las paredes en el
gabinete deben estar diseñadas para satisfacer los requisitos estáticos.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

66
 RHF044: El equipo deberá contar con la Resistencia apropiada a cargas horizontales tal
como se menciona en la norma EN 12899-1. Igual consideración para las Deflexiones y
la vibración a que puede ser sometido el VMS.

 RHF045: Se debe garantizar la resistencia a los impactos de acuerdo con la sección

4.5.2.5.4, y mediante ensayos de los componentes del VMS de acuerdo con la tabla 18
(Ensayo de impacto) del numeral 5.4.3 de la norma EN 12966.

 RHF046: La resistencia eléctrica y de componentes electrónicos del VMS deben cumplir

las normas de polución acorde al numeral 4.5.2.2 de la norma EN 12966 y a la norma
IEC 60664-1

 RHF047: El VMS debe contar con prestaciones de resistencia a la corrosión acorde a lo

que establece el numeral 4.5.2.3 y la tabla 20 (Ensayo de corrosión) de la norma EN
12966.

 RHF048: Los materiales y acabados utilizados para la construcción del VMS serán
adecuados para un diseño con mínimo mantenimiento y para garantizar la vida útil del
VMS.

 RHF049: El gabinete del VMS debe incluir pequeños orificios de drenaje para permitir la
salida de agua (por ejemplo, acumulación debido a condensación) o polvo, de acuerdo a
lo establecido por la norma IEC 60529 en cuanto a protección de polvo y agua. Los
orificios deberán ser tamizados para evitar la entrada de animales e insectos en el
recinto.

 RHF050: Para evitar los daños del VMS durante las actividades de transporte y
maniobras propias del proceso de instalación, en el gabinete del VMS debe contar con
suficientes mecanismos de alzado o elevación para permitir una instalación segura.

 RHF051: El hardware de montaje estructural de VMS (es decir, tuercas, pernos, tornillos
y arandelas de bloqueo) debe ser en acero inoxidable o acero galvanizado A325 de alta
resistencia.

 RHF052: El acceso al gabinete del VMS se realizará a través de una puerta de acceso
en el lado del gabinete. La puerta de acceso no deberá comprometer la clasificación del
Índice de Protección (IP) del VMS.

 RHF053: El gabinete del VMS debe proporcionar un mínimo de tres (3) tomas
eléctricas. Estos elementos se instalarán de acuerdo con lo establecido en el Código
Eléctrico Colombiano (NTC 2050) y Reglamento Técnico de Instalaciones Eléctricas
(RETIE).

 RHF054: El alojamiento debe incluir una iluminación de emergencia que ilumine

automáticamente el interior en caso de un corte de energía. La iluminación de
emergencia debe ser capaz de funcionar sin alimentación durante un mínimo de 90
minutos.

 RHF055: El área de visualización del VMS deberá cumplir los requisitos de la norma EN
12966. El área de visualización se construirá con múltiples paneles rígidos, cada uno de
los cuales soportan y protege una sección de altura completa de la matriz de
visualización de diodos emisores de luz (led).

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

67
 RHF056: La orla de contraste o bordes del área de visualización del VMS (superior,
inferior, izquierdo y derecho), que rodean los paneles de la cara frontal y la matriz de la
pantalla led se pintarán en negro para maximizar el contraste y la legibilidad de la
pantalla. Los bordes deberán tener unas dimensiones acorde a lo que establece la
norma EN 12966.

 RHF057: Para el control de las condiciones ambientales internas, el equipo VMS deberá
contar con un sistema de refrigeración dentro del gabinete que mantenga la temperatura
a 21 ° C (+/- 2 ° C), y mantener una humedad relativa que esté entre 20 y 100%, sin que
se genere condensación.

 RHF058: En la puerta de acceso al gabinete del VMS, debe estar ubicado un interruptor
manual temporizado para activar manualmente el sistema de ventilación.

 RHF059: El equipo VMS contendrá un sistema automático que caliente la cara frontal
del VMS cuando la humedad relativa interna está cerca de los niveles de condensación.
Este sistema mantendrá la cara frontal del VMS libre de niebla y condensación. El
aumento de temperatura generado por este sistema no debe dañar ninguna parte del
VMS.

 RHF060: El gabinete del VMS debe incluir un sensor de luz ambiental que proporcione
a la unidad de control del VMS información exacta sobre la condición de la luz ambiental
y así realizar el ajuste automático de la intensidad de la luz. La unidad de control del
VMS monitoreará de forma continua dicho sensor y ajustará la intensidad de luz de la
pantalla al nivel en el que el mensaje sea legible en la cara del VMS.

 RHF061: El VMS debe incluir sensores de temperatura externos e internos. Se instalará

como mínimo un sensor de temperatura externo en la pared trasera del gabinete del
VMS, el cual se debe instalar donde no esté en contacto directo con la luz del sol.
Adicionalmente el VMS deberá contener como mínimo un sensor interno de
temperatura, que medirá la temperatura interna del aire. La unidad de control del VMS
deberá medir y monitorear continuamente los sensores de temperatura en el gabinete,
los datos de estas mediciones deben ser enviadas o leídas por el equipo de
administración local o por el sistema de gestión remota ubicado en el CCO.

 RHF062: La unidad de control del VMS deberá medir y monitorear continuamente la

humedad relativa en el gabinete del VMS, el cual debe incluir como mínimo un sensor
de humedad. El (los) sensor(es) de humedad deben detectar y operar entre 0 y 100% de
humedad relativa, los incrementos mínimos deberán ser de un 1%.

f. Requisitos de Instalación

Los equipos VMS deben contar con los siguientes requisitos en el proceso de instalación:

Existen normas específicas de instalación y Seguridad pasiva de las estructuras de soporte

para equipos de carretera como la EN 12767 que deben cumplir los VMS para su
instalación. Es responsabilidad del fabricante o proveedor suministrarlas al comprador.

El fabricante deberá proporcionar instrucciones documentales y de seguridad que detallarán

todos los procedimientos de instalación y operación necesarios.

 RHF063: El fabricante deberá facilitar la siguiente información: instrucciones para el

montaje y desmontaje del VMS; los detalles de cualquier limitación de localización o
uso; instrucciones para la manipulación, mantenimiento y limpieza del letrero, incluido el

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

68
 reemplazo de componentes; las instrucciones de seguridad y medioambientales y sus
medidas de precaución eventualmente derivadas en relación con el funcionamiento, la
instalación, el mantenimiento, el transporte o el almacenamiento del producto. La
información del producto relacionada con la seguridad deberá ser en un idioma que sea
aceptable para el país.

 RHF064: Todos los componentes internos del VMS se deben conectar a la carcasa del
mismo de manera segura, teniendo en cuenta las consideraciones que se presentan en
el Anexo O (Cuestiones específicas de diseño) de la norma En 12966.

 RHF065: Las Señales de Mensaje Variable deben ser instaladas como se muestra en
los manuales de instalación de cada equipo VMS, los cuales deben ser entregados por
parte del proveedor junto con el VMS. Los manuales deben contener como mínimo lo
considerado en el Anexo Q (Documentación técnica) de la norma EN 12966.

 RHF066: El equipo VMS debe ser instalado una vez se asegure que el servicio de
electricidad esté disponible en el sitio de instalación.

g. Requerimientos de Usabilidad

 RHF067: De acuerdo con lo adoptado por el Ministerio de Transporte del país, las
Señales de Mensaje Variable deben ser ubicadas en vía, cumpliendo con lo establecido
en las consideraciones de localización presentadas en el Manual de Señalización vial
2015 (Capítulo 2, Sección 2.1 Generalidades de las señales verticales, apartado 4
ubicación). Adicionalmente se deben cumplir con las consideraciones de distancia
mínima de visibilidad y lectura presentadas en el Manual de Señalización Vial 2015,
(Capítulo 2, Sección 2.7 Señales de mensaje variable). Se deben considerar para su
instalación, condiciones adecuadas de visibilidad, estudios específicos para la
instalación que evalúen el entorno y las características geométricas de la vía, tanto en el
alineamiento horizontal como en el vertical.

h. Requerimientos de Confiabilidad

 RHF068: Todos los equipos VMS deben estar diseñados para tener una vida útil como
mínimo de 5 años a partir del momento en que quede instalado en vía.
No obstante lo anterior, la vida útil en función del análisis técnico correspondiente podrá
llegar hasta 15 años teniendo en cuenta lo que recomienda la experiencia internacional.
Para ello se requiere documentar los procesos de mantenimiento y garantizar el
cumplimiento de las recomendaciones de los fabricantes y un análisis sobre la
conveniencia técnica y económica de ampliar el período de vida útil.

 RHF069: Los led del VMS deben tener un tiempo de vida útil de por lo menos 100.000
horas en funcionamiento continuo, manteniendo un brillo mínimo del 70% con respecto
al inicial. Este requisito debe ser certificado por el fabricante del VMS.

i. Requisitos de Rendimiento

Para un correcto desempeño físico de los VMS se deberán tener en cuenta los requisitos de
rendimiento físico de la sección 4.5 de la norma EN 12966, correspondientes a:

 RHF070: El equipo VMS debe contar prestaciones de temperatura de acuerdo al

numeral 4.5.2.1 y a la tabla 23 (Ensayo de temperatura) de la norma EN 12966.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

69
 RHF071: El equipo debe contar con protección contra el ingreso perjudicial de agua y
polvo y así evitar que se afecte la operación del VMS y su vida útil, de acuerdo a lo
establecido en el numeral 4.5.2.4., y las tablas 21 (Ensayo de penetración de agua) y 22
(Ensayo de penetración de polvo) de la norma EN 12966 y los índices de protección
establecidos en la norma IEC 60529.

 RHF072: Rendimiento eléctrico del equipo VMS debe estar acorde a lo establecido en el
numeral 4.5.3 de la norma EN 12966.

 RHF073: El cumplimiento electromagnético de la VMS se ajustará a la sección 4.5.4 de

la norma EN 12966 y a lo establecido en la norma EN 50293.

j. Requisitos de Soporte

 RHF074: La Señal de Mensaje Variable debe disponer de contratos de mantenimiento y

soporte técnico, que incluyan suministro y cambios de partes originales, por parte del
fabricante y/o proveedor durante la vida útil del equipo.

k. Requisitos de Mantenimiento

 RHF075: El equipo debe ser diseñado de tal forma que el intervalo recomendado para
las rutinas de mantenimiento no debe ser inferior a los 6 meses.

 RHF076: Con el fin de prevenir accidentes o caídas, los equipos VMS deben tener
instalados puntos de anclaje de seguridad que permitan en las labores de
mantenimiento preventivo o correctivo, que los operadores puedan asegurarse mediante
un arnés de seguridad.

l. Requisitos de Interfaces de Comunicaciones

 RHF077: El equipo debe contar con conexión a través de medios físicos de transmisión
de datos Ethernet (IEEE 802.3) haciendo uso de cable par trenzado (UTP) o fibra óptica,
tecnologías de conexión inalámbrica Wifi (IEEE 802.11), Bluetooth o comunicación a
través de los operadores de redes de transmisión celular con los respectivos planes de
datos existentes en el país o canales dedicados.

 RHF078: El VMS debe contar con dispositivo GPS que le permitan a la unidad de
control del equipo enviar la información de ubicación geográfica (longitud y latitud).

 RHF079: En cuanto a interfaces de comunicación la unidad de control del VMS debe

contar con puertos de comunicación serial, Ethernet con conector RJ45 0 interfaces
inalámbricas como Wifi y Bluetooth.

m. Requisitos de Seguridad

 RHF080: Los equipos VMS deberán contar con sistemas de protección física que limiten
el acceso a los puertos físicos de conexión únicamente a quienes tengan el mecanismo
de control de acceso.

 RHF081: Los equipos VMS deberán soportar protocolos de cifrado en comunicaciones

para garantizar que la información en tránsito sea inaccesible. El protocolo de cifrado en
la capa de transporte deberá ser protocolo TLS (Transport Layer Security) en su versión

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

70
 1.2 o su actualización más reciente (ya sea una nueva versión o un nuevo protocolo que
lo remplace si TLS pasa a ser considerado como obsoleto o vulnerable).

 RHF082: El software embebido del sistema debe ser actualizado periódicamente

teniendo en cuenta que las actualizaciones críticas de seguridad deben aplicarse en
máximo un mes de su liberación.

16.2. SEÑALES DE MENSAJE VARIABLE PORTÁTILES (PVMS)

Las señales de Mensaje Variable portátiles están conformadas por la señal propiamente
dicha, el controlador del PVMS, el soporte de energía por paneles solares y el remolque que
se utiliza para el transporte del equipo. Los requisitos para los equipos PVMS son los
siguientes:

Requisitos Funcionales

A continuación se describen los requisitos funcionales de las señales de mensaje variable

portátiles, los cuales serán abordados en el siguiente orden:
 Requisitos de los módulos o Componentes de visualización de elementos led del PVMS.
 Requisitos de Caracteres, Fuentes y Color.
 Requisitos de la Unidad de Control del PVMS.
 Requisitos Estructurales
 Requisitos de Soporte por Energía Solar
 Requisitos de Transporte (Remolque/Trailer)

a. Requisitos para los módulos de visualización de elementos led del PVMS

A continuación se describen los requisitos asociados con prestaciones visuales de los

elementos led de los equipos PVMS.
 RHP001: La matriz de led debe estar compuesta de múltiples pixeles y cada pixel debe
estar conformado por 4 led.

 RHP002: El equipo PVMS debe permitir la visualización de mensajes y señales de

tránsito exclusivamente.

 RHP003: El PVMS debe tener una resolución mínima de 64 x 96 pixeles. Al incrementar

la resolución del equipo y realizar el cálculo correspondiente, hay que tener en cuenta
el incremento en el consumo de energía y por lo tanto el impacto en la autonomía.

 RHP004: El PVMS debe permitir la rotación de como mínimo 180° en cualquier

dirección sobre su eje de soporte.

 RHP005: El PVMS debe contar con dimensiones exteriores como mínimo de 300
centímetros de ancho por 200 centímetros de altura. El tamaño y la ubicación del PVMS
debe ser acorde a la condiciones de las vías, a los entornos de visualización para el
usuario de la misma y estar en concordancia a lo establecido en el Manual de
Señalización vigente para el País.

 RHP006: El equipo PVMS debe estar clasificado de acuerdo con parámetros

fotométricos (parámetros de prestaciones visuales) de color, luminancia, relación de

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

71
 luminancia y ancho (amplitud o anchura) de haz establecidos en el numeral 4.4 de la
norma EN 12966. Los parámetros de fotometría deben ser exigidos en concordancia
con el tipo de uso o aplicación específica de la señal, a las condiciones de
infraestructura de la vía y a las condiciones ambientales en las cuales se desplegará el
equipo.

El fabricante de PVMS deberá declarar la Clasificación de cada uno de los parámetros

de su equipo; no obstante, es importante indicar que existen combinaciones entre estos
parámetros que no son posibles o no son efectivas para el uso o aplicación que se le
quiera dar. En todos los casos es necesaria la exigencia de las mejores prestaciones en
color, luminancia y amplitud del haz posible para un uso apropiado.

Las combinaciones de clases entre los parámetros fotométricos deben estar claramente
establecidas y documentadas por el fabricante.

Todos los parámetros fotométricos deben ser probados como parte del proceso de
adquisición de un PVMS. En la mayoría de los casos, el fabricante deberá proporcionar
laboratorios, módulos de prueba y procedimientos claramente establecidos y
documentados que hagan posible la simulación de las condiciones a que serán
sometidos los equipos.

 RHP007: Las características de cromaticidad de las pantallas PVMS debe corresponder

a las recomendaciones de color según se define en la sección 4.4.2 de la norma EN
12966.

 RHP008: El fabricante debe garantizar que sus equipos cumplen con recomendaciones
de Colorimetría de publicaciones especializadas tales como la Publicación CIE Nº 15.2
Colorimetría, Publicación CIE No. 17.4 Vocabulario internacional de iluminación y/o CIE
Norma No. S 004 / E Colores de señales luminosas.
Deberán ser contempladas características de cromaticidad para Señales de mensaje
variable con y sin inversión de color.

 RHP009: Las características de luminancia de las pantallas PVMS debe corresponder a

las recomendaciones que se definen en la sección luminancia, numeral 4.4.3 de la
norma EN 12966, las cuales deberán ser contrastadas con el tipo de aplicación o uso, y
con las condiciones externas de iluminación provenientes de fuentes naturales o
artificiales en las cuales se desplegarán las señales.

 RHP010: Los parámetros fotométricos de luminancia y relación de luminancia, deben

ser seleccionadas tomando en cuenta las características de la vía, las necesidades de
los usuarios de la vía y la posibilidad de condiciones ambientales desfavorables (mucha
o poca luz, visibilidad escasa, lluvia, niebla); sin embargo, otras combinaciones de clase
de luminancia / razón de luminancia podrían ser apropiadas cuando se toman en
consideración los requisitos de ancho de haz.

 RHP011: El ancho del haz debe ajustarse a la clasificación que para tal parámetro
especifique la norma en el numeral 4.4.5, acorde con el uso o aplicación de la señal,
adicionalmente se deben realizar los ensayos de los componentes de acuerdo las tablas
24 a 27 del numeral 5.5.2. (ángulos de ensayo). Así por ejemplo en la norma EN 12966
un ancho de haz de clasificación B7 es el más recomendable para aplicaciones
especiales donde se requieren anchos de haz horizontal y vertical muy amplios, como
en áreas urbanas en donde la velocidad de aproximación es lenta y la distancia de
legibilidad es corta para usuarios como ciclistas o peatones.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

72
 Para el rendimiento visual habrá una diferencia entre la instalación en autopistas - con
buena visibilidad de distancia y ancho de haz estrecho - y la instalación en ciudades,
donde sólo hay una corta distancia de legibilidad y cuando un haz más amplio puede ser
necesario.

La exigencia del ancho de haz de lectura debe estar supeditado a variables como:
velocidad de la vía, cantidad de carriles de circulación, cantidad de carriles de
seguridad, ubicación lateral o sobre la vía de la señal, área urbana o autopistas.

 RHP012: Las condiciones de uniformidad de las pantallas PVMS debe corresponder a

las recomendaciones que se definen en la sección 4.4.6 de la norma EN 12966.
Los fabricantes deben detallar las medidas que toman para asegurar la apariencia
homogénea del PVMS completo, con especial atención a la superficie de la pantalla.

 RHP013: No debe ser visible ningún parpadeo en las pantallas PVMS de acuerdo con lo
considerado en la sección 4.4.7 de la norma EN 12966.

 RHP014: El equipo PVMS debe contar con características tipo matricial que permita el
despliegue de múltiples líneas de mensajes de texto. Las dimensiones de letras, la
relación de altura y anchura y el espaciamiento de caracteres debe estar acorde a lo
que establece el Manual de señalización, las especificaciones de la norma EN 12966 en
su anexo N y las condiciones de uso que se le dará al equipo PVMS en la vía.

 RHP015: Los módulos de visualización led serán totalmente intercambiables. Un

módulo de visualización de led puede consistir en una o dos placas de circuito. Los
módulos deben ser de fácil extracción, haciendo uso de herramienta genérica.

 RHP016: Los módulos de visualización PVMS deben controlar los datos de los píxeles y
leer el estado de los mismos.

 RHP017: Los led deben estar montados individualmente directamente en una placa de
circuito impreso.

 RHP018: Cada píxel consistirá de un mínimo de una serie independiente de led

discretos de color ámbar. El fallo de un píxel no causará el fallo de los demás píxeles en
el PVMS.

 RHP019: Cada píxel deberá contener la cantidad de led discretos necesarios para emitir
luz con una intensidad luminosa que debe corresponder a las recomendaciones que se
definen en la sección 4.4.3 de la norma EN 12966. La intensidad luminosa debe
ajustarse de acuerdo a resultados de estudios en campo según la zona geográfica, las
condiciones climáticas y de intensidad de luminosidad externa en el que este expuesto
el equipo.

 RHP020: Cada placa de control de led debe comunicarse con la unidad de control del
PVMS utilizando un protocolo de red direccionable.

 RHP021: La unidad de Control PVMS medirá y monitoreará continuamente todas las

tensiones de la fuente de alimentación del módulo de led y proporcionará las lecturas de
voltaje a la unidad de control del PVMS o al equipo portátil de administración local.

 RHP022: Los paquetes de led deben fabricarse de epoxi, resistentes a la luz UV. Los
led también deben estar protegidos de las condiciones ambientales externas, incluyendo
la humedad, el viento, el polvo, la arena y la suciedad.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

73
 RHP023: Los led del PVMS deben tener un tiempo de vida útil de por lo menos 55.000
horas en funcionamiento continuo, manteniendo un brillo mínimo del 70% con respecto
al inicial. Este requisito debe ser certificado por el fabricante del VMS.

 RHP024: La extracción o falla de un módulo de led no debe afectar el funcionamiento de

ningún otro módulo de led. La remoción de uno o más módulos led no afectará la
integridad estructural de ninguna parte de la señal.

 RHP025: La medición de la luminancia y la relación de luminancia se realiza de

conformidad con la sección 5.5.4 de la norma EN 12966.

 RHP026: La medición del ancho de haz se realiza de conformidad con la sección 5.5.5
de la norma EN 12966.

 RHP027: La medición de la uniformidad lumínica se realiza de conformidad con la

sección 5.5.6 de la norma EN 12966.

 RHP028: La medición del parpadeo visible se realiza de conformidad con la sección

5.5.7 de la norma EN 12966.

 RHP029: El diseño del PVMS debe tener en cuenta el impacto sobre las prestaciones
visuales, causadas por el tiempo de uso del PVMS (envejecimiento del equipo), las
prestaciones visuales deben ser revisadas durante la vida útil del equipo. Las
consideraciones de diseño en cuanto a este tema deben estar acordes a lo contemplado
en el numeral 4.4.8 de la norma EN 12966.

b. Requisitos para Caracteres, Fuentes y Color

En este literal se describen los requisitos asociados con caracteres, fuentes y color con que
deben contar las señales de mensaje variable portátiles.

 RHP030: El equipo PVMS portátil debe estar compuesto por una pantalla con led
ámbar.

 RHP031: Las definiciones correspondientes a las dimensiones, la forma, parámetros

físicos, el tamaño de los caracteres, las tolerancias y el espaciamiento de los caracteres
deben ser los requeridos por el comprador, teniendo en cuenta las consideraciones del
numeral 4.1 de la norma EN 12966 y el Anexo A (Área Equivalente). Las dimensiones
de los caracteres y símbolos deberán ser definidas utilizando una estrategia de área
equivalente, que haga posible comparar tecnologías. Para el diseño de los mensajes
que se presentan en un PVMS se debe tener en cuenta, adicional al área equivalente,
las consideraciones de diseño de mensajes del Anexo P (Indicaciones para el diseño de
mensajes de un PMV) de la norma EN 12966.

 RHP032: Para la especificación de las dimensiones del mensaje en el PVMS se

utilizarán las dimensiones equivalentes en lugar de las dimensiones físicas. Las
dimensiones de texto más importantes, es decir, la altura de los caracteres, el ancho de
los caracteres, el largo de la línea, el espaciado de los caracteres, el espaciado de las
palabras y el espaciado de línea, se deberán especificar usando dimensiones
equivalentes.

 RHP033: El área de visualización de texto del PVMS debe estar en capacidad de

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

74
 soportar las dimensiones de caracteres, la relación de altura y anchura y espaciamiento
de caracteres como se describe en el Manual de Señalización vigente para el País.
Adicionalmente se deben tener en cuenta las indicaciones de los anexos M
(indicaciones sobre gráficos de señales emisoras de luz discontinua) y N (indicaciones
sobre las dimensiones, luminancia, anchura de haz, legibilidad y eficiencia para PMV
discontinuos) de la norma EN 12966.

 RHP034: El equipo PVMS debe estar en la capacidad de mostrar los caracteres desde
el 32 al 126 del Código Estándar Americano para el Intercambio de Información (ASCII),
incluyendo todas las letras mayúsculas y minúsculas y los dígitos de 0 a 9, en cualquier
lugar del área de visualización.

 RHP035: Las fuentes preinstaladas en el equipo PVMS tendrán dimensiones de

caracteres que cumplan las especificaciones del Manual de Señalización vigente para el
País.

c. Requisitos de la Unidad Control del PVMS

A continuación serán descritos los requisitos con que debe contar la Unidad de Control de
las señales de mensaje variable portátiles.
 RHP036: La unidad de control del PVMS deberá ser un sistema autónomo basado en
microprocesador que permite gestionar el PVMS, la cual no requiere de comunicación
continua con el software de gestión central ubicado en el CCO.

 RHP037: Debe incluir una interfaz para visualización por parte del operario del PVMS
tipo pantalla LCD gráfica, para llevar a cabo los procesos de parametrización y gestión
del funcionamiento local.

 RHP038: Los PVMS deben incorporar puertos de consola que permitan conectar de
forma local el equipo de administración para labores de mantenimiento y pruebas del
sistema.

 RHP039: La unidad de control debe ser alojada en un recinto seguro dispuesto en el

remolque. El recinto debe tener un índice de protección mínimo de IP 56 de acuerdo a lo
establecido en la norma IEC 60529.

 RHP040: La unidad de control del PVMS debe contar con múltiples niveles de seguridad
por contraseña para evitar que usuarios no autorizados modifiquen mensajes o
configuraciones.

 RHP041: Debe contar con una unidad de almacenamiento local con capacidad para
almacenar la totalidad de los mensajes, programaciones y otros archivos necesarios
para su funcionamiento.

 RHP042: La unidad de control debe contar con software embebido, el cual debe estar
en capacidad de interpretar todos los comandos y los parámetros enviados desde el
aplicativo de gestión remota al PVMS y realizar el control de los módulos de
visualización y reajustarlos, monitorear los sensores internos y externos del PVMS y las
interfaces de comunicación.

 RHP043: La unidad de control del PVMS debe ser capaz de monitorear y presentar en
la pantalla LCD o de forma remota en el CCO, el mensaje actualmente activo incluyendo
los pictogramas. Esta pantalla debe ser una representación de la pantalla PVMS física.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

75
 RHP044: En cuanto a interfaces de comunicación, la unidad de control debe contar con
puertos de comunicación serial y Ethernet con conector RJ45.

 RHP045: Desde el CCO se debe tener la capacidad a través de la unidad de control del
PVMS de modificar remotamente parámetros fotométricos de la matriz de visualización
led de forma manual o automática en función de las condiciones de iluminación
ambiental.

 RHP046: La unidad de control del PVMS debe tener la capacidad de permitir la

modificación local o remota del brillo de la matriz de visualización led, ya sea de forma
manual o automática en función de las condiciones de iluminación ambiental.

 RHP047: La unidad de control del PVMS debe estar en la capacidad de detectar

automáticamente y en tiempo real el estado de cada uno de los píxeles de la pantalla y
reportar su estado de encendido / apagado.

 RHP048: La unidad de control del PVMS deberá supervisar e informar del estado de
todos los componentes, monitorear las señales generadas por los sensores de luz,
temperatura y humedad instalados en el gabinete del PVMS, así como también de la
operación de los ventiladores y estado de las fuentes de alimentación. Para el caso de
los sensores de temperatura interna del PVMS, debe estar en capacidad de apagará
automáticamente el PVMS si la temperatura interna del gabinete excede un umbral de
seguridad, el cual puede tener un valor por defecto de + 60º centígrados y que puede
ser parametrizable según sean las condiciones ambientales.

 RHP049: Si la temperatura se aproxima el umbral de seguridad parametrizado en la

unidad de control, se reducirá el brillo de la cara frontal del PVMS de forma automática.
El PVMS permanecerá sin mensajes hasta que la temperatura descienda, a medida que
la temperatura disminuye, la unidad de control aumentará gradualmente el brillo del
PVMS mostrando el mensaje, hasta llegar al parámetro de brillo normal para las
condiciones de visibilidad externas que se estén presentando.

 RHP050: La unidad de control del PVMS debe ser capaz de informar automáticamente
al operario por medio de la pantalla LCD local y reportar a la plataforma de gestión
remota del CCO, las condiciones de falla de alimentación, eventos en los componentes
internos, reinicios y otros eventos que se programen como críticos.

 RHP051: La unidad de control del PVMS debe monitorear continuamente los sensores
de luz y ajustar la intensidad de matriz de pantalla led a un nivel que genere un mensaje
legible en la pantalla del PVMS.

 RHP052: En caso de pérdida de la red de comunicaciones, la unidad de control dejará

automáticamente en blanco la cara del equipo PVMS.

d. Requisitos Estructurales

En el presente literal se describen los requisitos asociados a prestaciones mecánicas con

que deben contar los PVMS.

 RHP053: El rendimiento mecánico del PMVS debe ser acorde a lo establecido en el

numeral 4.5.2.5 de la norma EN 12966.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

76
 RHP054: Resistencia eléctrica y de componentes electrónicos a los efectos de la
polución acorde al numeral 4.5.2.2 de la norma EN 12966 y a la norma IEC 60664-1.

 RHP055: El PVMS debe contar con prestaciones de resistencia a la corrosión acorde a

lo que establece el numeral 4.5.2.3 y la tabla 20 (Ensayo de corrosión) de la norma EN
12966.

 RHP056: Debe contar con una estructura robusta y ser fabricado con materiales que no
permitir la corrosión.

 RHP057: El gabinete del PVMS debe incluir pequeños orificios de drenaje para permitir
la salida de agua (por ejemplo, acumulación debido a condensación) o polvo, teniendo
en cuenta lo establecido por la norma IEC 60529 en cuanto a la protección de polvo y
agua. Los orificios deberán ser tamizados para evitar la entrada de animales e insectos
en el recinto.

 RHP058: La orla de contraste o bordes de contraste del PVMS (superior, inferior,

izquierdo y derecho) que rodean los paneles de la cara frontal y la matriz de la pantalla
led deberán ser de color negro mate para maximizar el contraste, minimizar la reflexión
de la luz día y aumentar la legibilidad de la pantalla.

 RHP059: Se debe garantizar la resistencia a los impactos de acuerdo con la sección

4.5.2.5.4, y mediante ensayos de los componentes del PVMS de acuerdo con la tabla 18
(Ensayo de impacto) del numeral 5.4.3 de la norma EN 12966.

 RHP060: Para el control de las condiciones ambientales internas, el equipo PVMS

deberá contar con un sistema de refrigeración dentro del gabinete que mantenga la
temperatura a 21 ° C (+/- 2 ° C), y mantener una humedad relativa que esté entre 20 y
100%, sin que se genere condensación.

 RHP061: El gabinete del PVMS debe incluir un sensor de luz ambiental que
proporcione a la unidad de control del PVMS información exacta sobre la condición de la
luz ambiental y así realizar el ajuste automático de la intensidad de la luz. La unidad de
control del PVMS monitoreará de forma continua dicho sensor y ajustará la intensidad
de luz de la pantalla al nivel en el que el mensaje sea legible en la cara del PVMS.

 RHP062: El PVMS debe incluir sensores de temperatura externos e internos. Se

instalará como mínimo un sensor de temperatura externo en la pared trasera del
gabinete del PVMS, el cual se debe instalar donde no esté en contacto directo con la luz
del sol. Adicionalmente el PVMS deberá contener como mínimo un sensor interno de
temperatura, que medirá la temperatura interna del aire. La unidad de control del PVMS
deberá medir y monitorear continuamente los sensores de temperatura en el gabinete,
los datos de estas mediciones deben ser enviadas o leídas por el equipo de
administración local o por el sistema de gestión remota ubicado en el CCO.

 RHP063: La unidad de control del PVMS deberá medir y monitorear continuamente la

humedad relativa en el gabinete del PVMS, el cual debe incluir como mínimo un sensor
de humedad. El (los) sensor(es) de humedad deben detectar y operar entre 0 y 100% de
humedad relativa, los incrementos mínimos deberán ser de un 1%.

 RHP064: Todos los componentes internos del PVMS se deben conectar a la carcasa del
mismo de manera segura, teniendo en cuenta las consideraciones que se presentan en
el Anexo O (Cuestiones específicas de diseño) de la norma En 12966.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

77
 RHP065: El PVMS debe soportar las vibraciones generadas en la vía de acuerdo con lo
establecido en la sección 4.5.2.5.5 y mediante ensayos de los componentes del PVMS
de acuerdo la tabla 19 (Ensayos de vibraciones) del numeral 5.4.3 de la norma EN
12966. Dichas vibraciones no deben afectar la vida útil del PVMS. Para el caso de los
PVMS debe tenerse en cuenta las vibraciones generadas por el desplazamiento en el
remolque.

 RHP066: Las Señales de Mensaje Variable Portátiles deben ser manipuladas e

instaladas como se muestra en los manuales respectivos de cada equipo, los cuales
deben ser entregados por parte del proveedor junto con el PVMS. Los manuales deben
contener como mínimo lo considerado en el Anexo Q (Documentación técnica) de la
norma EN 12966.

e. Requisitos de Soporte por Energía Solar

Los equipos PVMS deben contar con los siguientes requisitos asociados al soporte de
energía a través del uso de paneles de energía solar:

 RHP067: El PVMS portátil debe tener la capacidad de ser conectado a la red de servicio
eléctrico.

 RHP068: El sistema de energía solar debe incluir los paneles solares, baterías,
hardware de montaje y controlador de energía solar.

 RHP069: Los paneles solares deberán cargar automáticamente las baterías.

 RHP070: El tamaño de los paneles solares deben ser dimensionados de tal forma que
se garantice la operación del PVMS y la recarga de las baterías al mismo tiempo.

 RHP071: El PVMS debe ser capaz de detener la carga de baterías solares cuando
están completamente cargadas.

 RHP072: El gabinete donde se almacenan las baterías debe incluir un ventilador para
mantener una temperatura adecuada para proteger y mantener operando en
condiciones óptimas los componentes del sistema.

 RHP073: El equipo PVMS debe funcionar durante veinticuatro (24) horas al día durante
3 días consecutivos sin interrupción del servicio y sin necesidad de fuentes de energía
auxiliares, mostrando en 3 líneas de texto un mensaje de 8 caracteres por línea.

f. Requisitos de Transporte (Remolque)

Se debe garantizar la seguridad en el transporte de los PVMS mediante el uso de un

sistema remolque, el cual deberá cumplir con los requisitos técnicos y condiciones de
seguridad que establezca para el efecto el Gobierno Nacional. Adicional a lo anterior, se
recomienda tener en cuenta las siguientes consideraciones:
 RHP074: El remolque debe cumplir con la normatividad Colombiana relacionada con la
operación de remolque en vías del país.

 RHP075: El remolque debe permitir el transporte de un equipo PVMS y toda su

estructura estará diseñada para soportar el peso del equipo y de los accesorios del
remolque.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

78
 RHP076: El remolque debe contar con una estructura robusta y ser fabricado con
materiales que no permitir la corrosión.

 RHP077: El sistema de frenos del remolque debe ser de tipo inercial o disponer de los
conectores para permitir su integración al sistema de frenos del vehículo que lo
transportará.

 RHP078: El remolque debe disponer de luces traseras con las funcionalidades

correspondientes.

 RHP079: El remolque deberá permitir el recorrido ilimitado en carretera a una velocidad

máxima de 60 kilómetros por hora.

 RHP080: El remolque debe contar con un mástil hidráulico que facilite el la elevación,
estabilización y nivelación en el montaje en la carretera, al igual que su desmontaje para
el traslado.

 RHP081: El remolque con sus equipos (PVMS y demás componentes de soporte

eléctrico) deberá estar diseñado para soportar una velocidad de ráfagas de viento de
hasta 120 kilómetros por hora, cuando esté siendo transportado o detenido.

 RHP082: El remolque debe contar con freno de mano, para ser desmontado para la
operación en vías con pendientes de hasta 10%

 RHP083: El remolque debe contar con bases estabilizadoras para montar su estructura
sobre la superficie de la carretera.

 RHP084: El remolque debe contar con caja de almacenamiento de equipo eléctrico,

baterías de soporte del PVMS y equipo controlador, la cual debe cumplir como mínimo
con un Índice de Protección (IP56) de acuerdo a lo definido en el estándar IEC 60529.

 RHP085: El remolque debe contar con esquemas de seguridad física que minimicen los
riesgos de actos vandálicos o la manipulación del mástil hidráulico o de las bases
estabilizadoras por parte de personal no calificado, lo que puedan llegar a ocasionar
accidentes o afectar el funcionamiento de los componentes del sistema de transporte.

 RHP086: El remolque debe contar con contratos de mantenimiento y soporte técnico,

que incluyan suministro y cambios de partes originales, por parte del fabricante y/o
proveedor durante la vida útil del equipo.

g. Requisitos de Usabilidad

 RHP087: De acuerdo a lo adoptado por el Ministerio de Transporte, las Señales de

Mensaje Variable deben ser ubicadas en vía, cumpliendo con lo establecido en las
consideraciones de localización presentadas en el Manual de Señalización vial 2015
(Capítulo 2, Sección 2.1 Generalidades de las señales verticales, apartado 4 ubicación).
Adicionalmente se deben cumplir con las consideraciones de distancia mínima de
visibilidad y lectura presentadas en el Manual de Señalización Vial 2015, (Capítulo 2,
Sección 2.7 Señales de mensaje variable, numeral 2.7.6.4 SMV Tipo Portátil).

h. Requisitos de Confiabilidad

 RHP088: Todos los equipos PVMS deben estar diseñados para tener una vida útil como

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

79
 mínimo de 5 años a partir del momento en que quede instalado en vía

No obstante lo anterior, la vida útil en función del análisis técnico correspondiente podrá
llegar hasta 15 años teniendo en cuenta lo que recomienda la experiencia internacional.
Para ello se requiere documentar los procesos de mantenimiento y garantizar el
cumplimiento de las recomendaciones de los fabricantes y un análisis sobre la
conveniencia técnica y económica de ampliar el período de vida útil.

i. Requisitos de Rendimiento

Para un correcto desempeño físico de los PVMS se deberán tener en cuenta los requisitos
de rendimiento físico de la sección 4.5 de la norma EN 12966, correspondientes a:

 RHP089: El equipo PVMS debe contar prestaciones de temperatura de acuerdo al

numeral 4.5.2.1 y a la tabla 23 (Ensayo de temperatura) de la norma EN 12966.

 RHP090: El equipo debe contar con protección contra el ingreso perjudicial de agua y
polvo y así evitar que se afecte la operación del PVMS y su vida útil, de acuerdo a lo
establecido en el numeral 4.5.2.4., y las tablas 21 (Ensayo de penetración de agua) y 22
(Ensayo de penetración de polvo) de la norma EN 12966 y los índices de protección
establecidos en la norma IEC 60529.

 RHP091: Rendimiento eléctrico acorde a lo establecido en el numeral 4.5.3 de la norma

EN 12966.

 RHP092: El cumplimiento electromagnético de la PVMS se ajustará a la sección 4.5.4

de la norma EN 12966 y a lo establecido en la norma EN 50293.

j. Requisitos de Soporte

 RHP090: La Señal de Mensaje Variable Portátil debe disponer de contratos de

mantenimiento y soporte técnico, que incluyan suministro y cambios de partes
originales, por parte del fabricante y/o proveedor durante la vida útil del equipo.

k. Requisitos de Mantenimiento

 RHP100: El equipo debe ser diseñado de tal forma que el intervalo recomendado para
las rutinas de mantenimiento no debe ser inferior a los 6 meses.

 RHP101: Todos los equipos PVMS deben tener instalados puntos de anclaje de
seguridad que permitan en las labores de mantenimiento preventivo o correctivo, que los
operadores puedan asegurarse mediante un arnés de seguridad esto con el fin de
prevenir de caídas y accidentes.

l. Requisitos de Interfaces de Comunicaciones

 RHP102: El equipo debe contar con conexión a través de medios físicos de transmisión
de datos Ethernet (IEEE 802.3) haciendo uso de cable par trenzado (UTP) o fibra óptica,
tecnologías de conexión inalámbrica Wifi (IEEE 802.11), Bluetooth o comunicación a
través de los operadores de redes de transmisión celular con los respectivos planes de
datos existentes en el país o canales dedicados.

 RHP103: El PVMS debe contar con dispositivo GPS que le permitan a la unidad de

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

80
 control del equipo enviar la información de ubicación geográfica (longitud, latitud y
dirección de desplazamiento).

m. Requisitos de Seguridad

 RHP104: Los equipos PVMS deberán contar con sistemas de protección física que
limiten el acceso a los puertos físicos de conexión únicamente a quienes tengan el
mecanismo de control de acceso.

 RHP105: Los equipos PVMS deberán soportar protocolos de cifrado en comunicaciones

para garantizar que la información en tránsito sea inaccesible. El protocolo de cifrado en
la capa de transporte deberá ser protocolo TLS (Transport Layer Security) en su versión
1.2 o su actualización más reciente (ya sea una nueva versión o un nuevo protocolo que
lo remplace si TLS pasa a ser considerado como obsoleto o vulnerable).

 RHP106: El software embebido debe ser actualizado periódicamente teniendo en

cuenta que las actualizaciones críticas de seguridad deben aplicarse en máximo un mes
de su liberación.

17. DESCRIPCIÓN DE LOS REQUISITOS DE SOFTWARE

Para el alcance del presente documento, a continuación se hace una descripción de los
productos de software acorde al actor responsable de su implementación, en un primer
bloque se describen los Requisitos Generales que aplicarán para los dos actores
mencionados, seguidos por los del Administrador Vial y finalmente los correspondientes al
Ministerio de Transporte.

17.1. REQUISITOS GENERALES

A continuación se describen los requisitos de software generales que aplicarán a la
Plataforma de Gestión Remota de Equipos VMS, Plataforma de Gestión Local de Equipos
VMS y al Componente para Interoperabilidad de Equipos VMS que corresponden al actor
estratégico Administrador Vial, y a la Plataforma SIGVMS del Ministerio de transporte:

a. Requisitos de disponibilidad

 RSG001: Tolerancia a Fallos. Deberá tener la capacidad de mantener el nivel

especificado de rendimiento en casos de fallos del software. Como mecanismo de
control e identificación del fallo se deberá permitir el manejo estándar de mensajes de
error, mensajes de ayuda y mensajes de confirmación en la ejecución de procesos.

 RSG002: Tolerancia a Fallos. Los mensajes de error deben estar codificados y

presentarse al usuario en idioma español.

b. Requisitos de Robustez

 RSG003: Madurez. Todos los productos deberán basarse en la utilización de

componentes base o herramientas utilizadas para el diseño, construcción, pruebas e
implementación reconocidas que tengan más de 3 años en el mercado, que tengan
soporte por parte del fabricante, que exista un fabricante reconocido y con trayectoria y
que exista el desarrollo continuo de cada herramienta que permita el mejoramiento y

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

81
 acceso a nuevas versiones de acuerdo con la evolución de las plataformas.

c. Requisitos de Usabilidad

 RSG004: Tiempo de Ejecución. Deberá contener componentes que permitan la rápida

navegación entre funcionalidades, así mismo, cada una de las opciones deberán ser
implementadas con el mínimo de pasos necesarios para una correcta funcionalidad.

d. Requisitos de Extensibilidad
 RSG005: Documentación. Deberá especificarse la definición y el manejo de la
documentación técnica (manuales técnicos y de instalación) y funcional (manuales de
administración, configuración y de usuario final) del sistema.

 RSG006: Documentación. Manual del Técnico del sistema. Deberá contener como
mínimo la arquitectura del sistema, el diagrama de procesos, el diagrama de flujos de
información, el modelo de Entidad Relación, la descripción de los programas fuentes, la
descripción de mensajes y errores del sistema, el procedimiento de instalación del
sistema desarrollado, descripción general de la nueva base de datos integrada,
descripción de las interfaces, flujos de información de los nuevos desarrollos realizados,
descripción técnica de todos los módulos desarrollados.

 RSG007: Documentación. Manual de Administración y Operación, deberá contener

como mínimo el manejo de seguridad, auditoría, perfiles de usuarios, tablas básicas del
sistema, parametrización, proceso de administración de todos los módulos del sistema
desarrollado.

 RSG008: Documentación. Manual del usuario, deberá contener como mínimo una
descripción del funcionamiento de todos los módulos.

17.2. REQUISITOS PARA EL ADMINISTRADOR VIAL

17.2.1. DESCRIPCIÓN GLOBAL DEL PRODUCTO SOFTWARE

17.2.1.1. Perspectiva del producto

Se visualiza la plataforma de software para la gestión del Administrador Vial en perspectiva
con otras plataformas de software externas, pero con las cuales se mantiene una relación.
Para lograr una visión más acertada, se visualizarán las distintas sub plataformas
constitutivas – Plataforma de Gestión Remota y Software en equipos VMS – como una
unidad compacta. A continuación se expresan como la solución de software opera bajo
ciertas restricciones de entorno.

a. Interfaces del Sistema

Se listan y describen las interfaces del sistema de gestión del administrador vial y se

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

82
identifican las funcionalidades de software que dan cumplimiento a los requisitos de
interoperabilidad, de manera que la Plataforma de Gestión Remota permita:

- El envío a SiGVMS de los datos de los equipos VMS gestionados por el

administrador vial y su correspondiente operación.
- Servir de mediador entre la plataforma SiGVMS y los equipos VMS dispuestos por el
administrador vial, permitiendo el acceso a un equipo específico desde el SiGVMS:
recibe las peticiones desde el SiGVMS y luego las traslada al equipo VMS real y
dispuesto al interior de la red interna.

b. Interfaces de Usuario

Se listan y describen las interfaces de usuario requeridas por la solución, indicando las
características lógicas de las distintas interfaces entre el producto de software y el usuario:
incluyendo características de configuración y características de usabilidad que soporten la
facilidad de uso del software.

- Diseño de interfaces de Usuario altamente usables.

- Despliegue de formularios de manera óptima y Ayuda en Línea que permitan al
usuario un apropiado uso de las interfaces.
- Opcional Soporte sobre las tecnologías actualizadas de despliegue de interfaces
basadas en páginas HTML y soporte CCS, dado que la aplicación únicamente es
usada por un usuario en el CCO, no se requiere estrictamente una funcionalidad con
interfaces Web.
- Tiempo de Ejecución aceptables y acorde a los requisitos de rendimiento.
- Conectividad y Acceso.

c. Interfaces de Hardware

La Plataforma de Gestión Remota del administrador vial deberá implementar los

componentes necesarios para interactuar con los equipos VMS dispuestos en la vía. La
interfaz deberá ser implementada a partir de la especificación técnica suministrada por el
Ministerio de Transporte para dicho fin y que ha sido descrita en este documento, apartado
17.2.2.3 Especificación para Interoperabilidad con Equipos VMS.

d. Interfaces de Software

Se listan y especifican las interfaces de software requeridas por la solución.

- Clientes de servicios Web para la interoperabilidad con equipos VMS dispuestos en

la vía.
- Servicio Web que exponga las funciones de negocio requeridas para interoperar con
la plataforma SiGVMS soporte para la funcionalidad de difusión simultánea de
mensajes de interés nacional.
- Clientes de servicios Web para la interoperabilidad con la plataforma SiGVMS para
envió de datos de equipos VMS y su operación, gestionados por el administrador
vial.

e. Interfaces de Comunicaciones

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

83
Se listan y especifican las interfaces de comunicaciones requeridas por la Plataforma de
Gestión Remota.

- Interfaces de comunicaciones para interoperabilidad con otros sistemas externos,

para soportar su interoperabilidad con el SiGVMS del Ministerio de Transporte.
- Interfaces de comunicaciones para interoperabilidad con equipos VMS dispuestos en
la vía, requiere acceso a la red de transmisión de datos interna del Administrador
Vial para soportar su interoperabilidad con los equipos VMS dispuestos en la vía.

f. Modos de Operación

Para la Plataforma de Gestión Remota del administrador vial deberá tenerse en cuenta en
los proceso de: instalación de hardware, configuraciones de tolerancia a fallos, contingencia
y de respaldo, que permita mantener la solución en alta disponibilidad; para esto se propone
contar con lo siguiente:

- Tecnologías de alta disponibilidad para el procesamiento, como por ejemplo

sistemas de procesamiento paralelo, basados en clúster o de manera alternativa
como servicios en la nube que lo soporten. Dicha solución de Alta Disponibilidad
debe ser probada, documentada y gestionada para garantizar que funcione
adecuadamente y en los tiempos requeridos.
- Sistemas de arreglos en espejo (RAID) para la instalación del software y el
almacenamiento de la información considerada como primordial o esquema de
almacenamiento en la nube que ofrezca el nivel de servicio equivalente.
- Equipos de cómputo con fuentes de energía redundantes.
- Medios de comunicación redundantes entre los equipos y las redes locales
redundantes. Para conexiones por medio físico, contar con más de una tarjeta de
red por equipo y en el caso de conexiones inalámbricas, disponer de otros medios
en caso de fallas de comunicación de los medios principales.
- En cuanto a las instalaciones donde se mantendrán los equipos de cómputo, deben
contar con los subsistemas necesarios y mínimos, de control de acceso, monitoreo
CCTV, soporte eléctrico y ambiental (Aire Acondicionado y Equipos de Extinción de
incendios) que garanticen la operación del centro de control y la seguridad del
personal operativo y cableado estructurado para las redes de datos.

17.2.1.2. Funciones del producto

A continuación un resumen de las funciones principales que deberán ser provistas por el
producto a implementar por el administrador vial. Se ha agrupado la lista de funciones en
los componentes de software definidos para el Producto.

a. Funciones de la plataforma de Gestión Remota de Equipos VMS en el CCO

Corresponde al software central de la solución, se despliega y es usado en el CCO por un

actor operador, permite interactuar de manera remota con los equipos VMS. Las
características fundamentales son:

- Configuración del Banco de mensajes y Pictogramas, proporciona una herramienta

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

84
 que permite al operador del CCO realizar la configuración de un banco de mensajes
y pictogramas apropiado y basado en el diccionario de mensajes estandarizado
propuesto por este módulo ITS y perfeccionado por la ANSV.
- Gestión de equipos VMS, proporciona una herramienta que permite al operador del
CCO realizar la gestión funcional de los equipos VMS, significando esto que, acorde
a situaciones propias de la operación de la vía o cuando sea meritorio deberá
actualizar el mensaje y/o pictograma en un(os) equipo(s) VMS en específico(s),
previo la plataforma deberá permitir la configuración de los equipos VMS instalados
en la vía.
- Gestión de estado operativo de equipos VMS, proporciona una herramienta que
permite al operador del CCO monitorear constantemente y acorde a una
programación realizada para el CCO el estado de los equipos VMS dispuestos en la
vía.
- Gestión de mantenimientos preventivos y correctivos, proporciona una herramienta
que permite al operador del CCO realizar la programación de mantenimientos
preventivos a los equipos VMS dispuestos en la vía, tomando como base las
recomendaciones de operación sugeridas por este módulo ITS. Adicionalmente, en
caso de alguna falla detectada mediante el tablero de control el operador del CCO
deberá lanzar una programación de mantenimiento correctivo del equipo VMS
correspondiente.
- Reporte de Datos de Equipos VMS a SiGVMS, proporciona una herramienta que
deberá enviar de manera automática a la plataforma SiGVMS del Ministerio de
Transporte datos acerca de los equipos VMS dispuestos en la vía y que se
encuentren en estado operativo funcional.
- Recepción de petición de difusión de mensaje de interés nacional, proporciona una
herramienta que deberá permitir el acceso a un equipo VMS específico desde el
SiGVMS, recibe las peticiones desde el SiGVMS y luego las traslada al equipo VMS
real y dispuesto al interior de la red interna.

b. Funciones de la plataforma de Gestión Local de Equipos VMS

Corresponde al componente de software para la administración de un equipo VMS que es

ejecutado de manera local, sobre un equipo de cómputo integrado a la infraestructura física
del equipo VMS o independiente y conectado por sus puertos disponibles. Las
características fundamentales son:

- Gestión del Equipo VMS, proporciona una herramienta que permite al operador de
mantenimiento realizar la gestión funcional de los equipos VMS, significando esto
que, acorde a situaciones propias de la operación de la vía o cuando sea meritorio
deberá en un(os) equipo(s) VMS en específico(s) y conectado directamente
actualizar el mensaje y/o pictograma, así mismo, deberá permitir la configuración y
adecuación necesaria en el equipo en caso de mantenimientos. Los procesos
realizados deberán ser reportadas a la Plataforma de Gestión Remota del CCO de
manera automática una vez el equipo VMS entre en completa operación.

c. Funciones del componente de software para Interoperabilidad en el equipo

VMS

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

85
Corresponde al componente de software desplegado directamente sobre el equipo VMS
que implementa el mecanismo de interoperabilidad basado en servicios Web especificado
por el Ministerio de Transporte, su función principal es recibir las peticiones de gestión del
equipo enviadas desde la Plataforma de Gestión Remota en el CCO y trasladarlo a
peticiones sobre la controladora del equipo VMS para realizar el envío de información o
cambios de configuración solicitados.

17.2.1.3. Características de los usuarios

Se describen las características generales de los usuarios que utilizarán los componentes
de software en el administrador vial

- Operador de CCO, representa el rol encargado de la gestión remota de los Equipos

VMS en el CCO, conoce las funcionalidades de operación de la Plataforma de
Gestión Remota y del banco de mensajes y pictogramas. Debe conocer el
diccionario de mensajes propuesto.

- Operario de instalación, mantenimientos y traslados, representa el rol encargado

de las actividades de instalación, mantenimientos y traslados de los equipos VMS.
Conoce las funcionalidades de operación de la plataforma de gestión local y cuenta
con conocimiento, capacidades y mecanismos necesarios para instalación,
mantenimiento y traslados de equipos.

17.2.1.4. Restricciones

Se listan y describen de manera general cualquier condición que limite la implementación

del producto.

- Las funcionalidades que contengan contexto geográfico deberán contener las

funcionalidades mínimas de un Visor Geográfico estándar: Acercar, Alejar,
Desplazamientos e Identificación de elementos.
- Las decisiones de diseño de datos alfanuméricos y geográficos deberán respetar y
asimilar toda la normatividad vigente aplicable y las mejores prácticas del diseño de
bases de datos.
- Todos los componentes de software propuestos deberán ser portable, de manera
que pueda funcionar con independencia del sistema operativo subyacente.
- La interoperabilidad entre la plataforma de Gestión Remota en el CCO y los equipos
VMS remotos deberá realizarse mediante la implementación del esquema de
interoperabilidad propuesto por el Ministerio de Transporte.
- La interoperabilidad entre la plataforma de Gestión Remota en el CCO y la
plataforma SiGVMS deberá realizarse mediante la implementación de los servicios
Web propuestos con base en esta especificación, para lo cual deberán ser definidos
los archivos WSDL y XSD requeridos para la implementación del administrador vial.
- Todos los requisitos no funcionales especificados en este documento deben de ser
considerados como parte de las restricciones del producto de software.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

86
17.2.1.5. Supuestos y dependencias

Se listan y describen de manera general cualquier condición cuya mínima variación afecta o
impacta el estado de algún requisito. No son considerados restricciones de diseño, pero,
cualquier cambio puede afectar los requisitos del producto.

- Arquitectura SiGVMS, todos los esquemas de interoperabilidad necesarios con el

SiGVMS, serán implementados con las definiciones de los servicios Web de la
plataforma propuestos en su especificación.

17.2.2. REQUISITOS ESPECÍFICOS

17.2.2.1. Plataforma de Gestión Remota de Equipos VMS

A continuación se detallan los Requisitos del producto de software a desplegar en un CCO,

para la administración Remota de equipos VMS, el cual permitirá a los administradores
viales gestionar remotamente los equipos VMS dispuestos en las vías de su jurisdicción. Así
mismo, este producto, se convierte el punto intermedio o de comunicación para la
administración de los equipos VMS de forma remota desde la plataforma SiGVMS dispuesto
por el Ministerio de Transporte.

17.2.2.1.1. Interfaces Externas

 RSA001: Interfaz Plataforma SiGVMS, Reportar Datos de Equipos VMS. Esta

plataforma deberá reportar a través de los servicios Web expuestos por la Plataforma
SiGVMS los datos de Equipos VMS dispuestos por el administrador vial y gestionados
por esta plataforma cada que un equipo VMS es instalado o reconfigurado.

 RSA002: Interfaz Plataforma SiGVMS, Recibir Petición de Difusión de Mensaje Interés

Nacional. Esta plataforma deberá suministrar los Servicios Web necesarios para que el
Ministerio de Transporte mediante la plataforma SiGVMS pueda modificar remotamente
el mensaje y pictograma de alguno de sus equipos VMS gestionados.

 RSA003: Interfaz Equipos VMS en Campo, Gestionar Equipos VMS desplegados en

campo. Esta plataforma deberá implementar el esquema de interoperabilidad propuesto
por el Ministerio de Transporte, el cual permite realizar la administración y obtención de
datos de la operación de los equipos VMS instalados por el administrador vial en las
vías de su jurisdicción.

17.2.2.1.2. Funciones

a. Gestión de Base de Mensajes y Pictogramas

 RSA004: Gestionar la base de datos de Mensajes y Pictogramas. El usuario Operador

de CCO deberá contar con una interfaz de usuario final que le permita gestionar – crear,
modificar, eliminar – los distintos mensajes y pictogramas estandarizados propuesto por
este módulo ITS en diccionario de mensajes y perfeccionado por la ANSV.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

87
 RSA005: Gestionar Pictogramas. El usuario Operador de CCO deberá contar con una
interfaz de usuario final que le permita gestionar – importar y eliminar – distintos
pictogramas que serán almacenados en la base de datos.

 RSA006: Gestionar la Taxonomía o Tipología de Mensajes. El usuario Operador de

CCO deberá contar con una interfaz de usuario final que le permita gestionar – crear,
modificar, eliminar – una taxonomía de los mensajes y pictogramas en la base de datos,
logrando crear una estructura de árbol con los tipos de mensajes acorde a los casos de
aplicación o uso.

 RSA007: Disponer de Campos Dinámicos. la plataforma deberá contar con un grupo de

campos dinámicos que podrán ser incluidos en el contenido de un mensaje en particular
y permita obtener de manera dinámica textos.

 RSA008: Gestionar Mensajes. El usuario Operador de CCO deberá contar con una
interfaz de usuario final que le permita gestionar – crear, modificar, eliminar – los
distintos mensajes que serán almacenados en la base de datos.

b. Interoperabilidad con Equipos VMS

 RSA009: Interoperar con Equipos VMS Desplegados en la vía. La plataforma de

Gestión Remota deberá contar con una interfaz basada en un Cliente Web que permita
la conectividad con cada uno de los equipos VMS desplegados en las vías de
jurisdicción del administrador vial.

c. Gestión de equipos VMS

 RSA010: Gestionar Equipos VMS y sus Capacidades. El usuario Operador de CCO

deberá contar con una interfaz de usuario final que le permita gestionar – crear,
modificar, eliminar – los distintos equipos VMS que han sido desplegados en el campo y
se encuentran conectados a la red interna y disponibles para ser configurados y
gestionados desde la Plataforma de Gestión Remota.

 RSA011: Gestionar los Tipos de Fuente disponibles en un Equipo VMS. El usuario

Operador de CCO deberá contar con una interfaz de usuario final que le permita
gestionar los tipos de fuentes soportadas y disponibles en un equipo VMS específico
para despliegue del mensaje.

 RSA012: Gestionar un Mensaje Preconfigurado en un Equipo VMS. El usuario Operador

de CCO deberá contar con una interfaz de usuario final que le permita activar un
mensaje preconfigurado en un equipo VMS específico, para lo cual deberá permitir
seleccionar un mensaje específico de la base de datos de mensajes y pictogramas.

 RSA013: Gestionar un Mensaje Nuevo en un Equipo VMS. El usuario Operador de CCO

deberá contar con una interfaz de usuario final que le permita activar un mensaje nuevo
en un equipo VMS específico, para lo cual deberá permitir crear un mensaje particular
nuevo.

 RSA014: Gestionar un Mensaje vacío en un Equipo VMS. El usuario Operador de CCO

deberá contar con una interfaz de usuario final que le permita activar un mensaje vacío

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

88
 en un equipo VMS específico.

 RS0A15: Restablecer un Equipo VMS a configuración de fabricante. El usuario

Operador de CCO deberá contar con una interfaz de usuario final que le permita
restablecer un Equipo VMS con los parámetros de configuración inicial suministrados
por el fabricante.

 RSA016: Habilitar la administración local para un Equipo VMS. El usuario Operador de

CCO deberá contar con una interfaz de usuario final que le permita establecer si el
equipo VMS va a ser gestionado de manera local o remotamente desde el CCO.

 RSA017: Programar el despliegue de mensajes preconfigurados en un Equipo VMS. El

usuario Operador de CCO deberá contar con una interfaz de usuario final que le permita
definir una programación de despliegue de mensajes específicos acorde a ciertos
periodos del día y con una variación mínima permitida de un minuto; deberá permitir
seleccionar un mensaje específico de la base de datos de mensajes y pictogramas.

 RSA018: Programar el despliegue de mensajes nuevos en un Equipo VMS. El usuario

Operador de CCO deberá contar con una interfaz de usuario final que le permita definir
una programación de despliegue de mensajes específicos acorde a ciertos periodos del
día y con una variación mínima permitida de un minuto; deberá permitir crear un
mensaje particular nuevo.

 RSA019: Gestionar Mensajes Activados en un Equipo VMS ante la ocurrencia de

eventos. El usuario Operador de CCO deberá contar con una interfaz de usuario final
que le permita configurar los mensajes que deberán ser desplegados en un equipo VMS
ante la ocurrencia de eventos.

 RSA020: Gestionar el Brillo de un Equipo VMS, Consultar las lecturas de la fotocelda. El

usuario Operador de CCO deberá contar con una interfaz de usuario final que le permita
a partir del mensaje desplegado en un equipo VMS consultar las lecturas de la fotocelda
del equipo.

 RSA021: Gestionar el Brillo de un Equipo VMS, Seleccionar manualmente el nivel de

brillo. El usuario Operador de CCO deberá contar con una interfaz de usuario final que
le permita seleccionar manualmente el nivel de brillo aplicado al mensaje desplegado en
un equipo VMS.

 RSA022: Configurar el Tipo de Control de Brillo de un Equipo VMS. El usuario Operador

de CCO deberá contar con una interfaz de usuario final que le permita configurar el tipo
de control de brillo de manual a automático.

 RSA023: Actualizar la configuración en la Plataforma a partir de configuración real del

Equipo VMS. El usuario Operador de CCO deberá contar con una interfaz de usuario
final que le permita actualizar toda o parcialmente la configuración de un equipo VMS en
esta plataforma, a partir de los datos de configuración leídos directamente desde el
equipo VMS en la vía.

d. Gestión Operativa y Mantenimientos de Equipos VMS

 RSA024: Monitorear el Estado Operacional de Equipos VMS. La plataforma remota

deberá contar con un mecanismo de monitoreo que permita obtener información
constante y directamente desde el equipo VMS configurado y en estado operativo
activo.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

89
 RSA025: Desplegar un Tablero de Control de Equipos VMS. El usuario Operador de
CCO deberá contar con una interfaz de usuario final que le permita visualizar el estado
operativo de cada uno de los equipos y hacer seguimiento a los eventos de estado con
cierta periodicidad.

 RSA026: Realizar Prueba de Estado Operacional de Lámparas de Equipos VMS. El

usuario Operador de CCO deberá contar con una interfaz de usuario final que le permita
activar una prueba del estado operacional de lámparas de un equipo VMS específico.

 RSA027: Realizar Prueba de Estado Operacional de Píxeles de Equipos VMS. El

usuario Operador de CCO deberá contar con una interfaz de usuario final que le permita
activar una prueba del estado operacional de Píxeles de un equipo VMS específico.

 RSA028: Realizar Prueba de Estado Operacional de Dispositivos de Climatización de

Equipos VMS. El usuario Operador de CCO deberá contar con una interfaz de usuario
final que le permita activar una prueba del estado operacional del Dispositivo de
Climatización de un equipo VMS específico.

 RSA029: Programar Mantenimientos Preventivos. El usuario Operador de CCO deberá

contar con una interfaz de usuario final que le permita realizar la programación de
mantenimientos preventivos a los equipos VMS dispuestos en la vía.

 RSA030: Programar Mantenimientos Correctivos. El usuario Operador de CCO deberá

contar con una interfaz de usuario final que le permita realizar la programación de
mantenimiento correctivo desde el tablero de control a los equipo VMS que así lo
requieran.

 RSA031: Enviar Notificaciones Automáticas. Esta plataforma acorde a la programación

de mantenimientos preventivos y correctivos realizada, deberá enviar notificaciones
recordatorias por correo electrónico o cualquier otro medio que cumpla dicha función, al
operador o personal responsable del mantenimiento.

 RSA032: Registrar Informe Técnico. El usuario Operario de Instalación, Mantenimientos

y Traslados deberá contar con una interfaz de usuario final que le permita registrar el
informe de las acciones aplicadas al equipo VMS, siendo estos, mantenimientos
correctivos o preventivos o traslados, este último, deberá actualizar las coordenadas
geográficas configurada para el equipo VMS.

 RSA033: Generar Reporte Datos de Equipo VMS. El usuario Operador de CCO deberá
contar con una interfaz de usuario final que le permita generar un informe de los datos
operativos de uno o varios equipos VMS.

e. Reporte de Datos Equipos VMS a SiGVMS

 RSA034: Enviar Datos de los Equipos VMS Gestionados. Esta plataforma deberá contar
con una interfaz para el reporte a SiGVMS de los datos de los equipos VMS que fueron
desplegados por el Administrador Vial, esta herramienta deberá ejecutarse de manera

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

90
 automática cada que es configurado y puesto en operación un nuevo equipo VMS o
cuando se genera un cambio en el estado operativo de algún equipo VMS.

f. Recepción Peticiones Difusión Mensaje Interés Nacional

 RSA035: Recibir peticiones de difusión de mensaje de Interés Nacional. Esta plataforma

deberá contar con una interfaz que permita recibir y procesar las peticiones de difusión
de un mensaje de interés Nacional desde la Plataforma SiGVMS del Ministerio de
Transporte.

g. Configuración General

 RSA036: Gestionar Tipos de Fuentes. El usuario Operador de CCO deberá contar con
una interfaz de usuario final que le permita gestionar (importar, crear, modificar,
eliminar) la definición de los distintos tipos de fuentes habilitadas para configuración en
los mensajes.

 RSA037: Soportar Esquemas de colores. La plataforma deberá contar con soporte y

permitir la utilización de los esquemas de colores definidos por la especificación.

 RSA038: Gestionar Datos Paramétricos o de Dominio. El usuario Operador de CCO

deberá contar con una interfaz de usuario final que le permita gestionar (crear,
modificar, eliminar) los datos paramétricos o de configuración relacionados a las
características y capacidades tecnológicas de los VMS o cualquier otro dato de
configuración de la plataforma. Se debe permitir almacenar como mínimo: Tipos de
equipos VMS, Tecnologías, Proveedores, Marcas.

 RSA039: Consultar Configuración Estándar de Equipos VMS para Mensajes de Interés

Nacional. El usuario Operador de CCO deberá contar con una interfaz de usuario final
que le permita consultar los parámetros de configuración del equipo VMS para la
aplicación del formato estándar del mensaje de Interés Nacional.

h. Requisitos de Rendimiento

 RSA040: Tiempo de Respuesta. El sistema deberá garantizar que el tiempo de

respuesta no será en medida promedio superior a 10 segundos.

 RSA041: Tiempo de Respuesta. Los tiempos de respuesta relacionados con formularios

de manejo de información adición, modificación, consulta de registros, autenticación y
emisión de avisos y confirmaciones por parte del usuario no debe ser superior a 5
segundos, los informes y consultas que presenten una complejidad alta no deberá
exceder el tiempo de 10 segundos.

 RSA042: Concurrencia. El sistema deberá estar en capacidad de prestar el servicio con

unos niveles aceptables de desempeño, para esto, se debe tener en cuenta la población
estimada de clientes y una concurrencia esperada de usuarios, así como las
proyecciones de crecimiento basada en los servicios que prestará el sistema,
asegurando su escalabilidad. En la tabla siguiente se describen estas características:

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

91
 Usuario Plataforma No. Usuarios

Usuarios Potenciales 152, discriminados así:

 1 usuario operador del CCO

 1 usuario Operario de Instalación, Mantenimientos y Traslados
 150 equipos VMS a ser administrados

Usuarios Concurrentes 4, asumiendo que:El tiempo de refrescamiento configurado para

actualización del estado operativo de los 150 equipos VMS es de 60
segundos.

Tabla 1 usuarios Potenciales y Concurrentes Plataforma de Gestión Remota

Fuente: Elaboración propia

17.2.2.1.3. Atributos del Sistema

a. Requisitos de Seguridad

 RSA043: Acceso Restringido. El sistema deberá restringir el acceso por medio de uso
de claves asignadas a cada uno de los usuarios. Sólo podrán ingresar al sistema las
personas que estén registradas y autorizadas, estos usuarios serán clasificados por
roles con acceso a las funcionalidades definidas para cada rol.

 RSA044: Acceso Restringido. Deberán existir procedimientos de autorización y registro

de usuarios del sistema, propios y de terceros, que definan claramente las condiciones
por las cuales se podrá autorizar el acceso al sistema, las condiciones de permanencia
y las condiciones de remoción de los accesos, así como los controles periódicos de
validación y auditoría de los mismos.

 RSA045: Acceso Restringido. Se mantendrá documentada y actualizada la matriz de

usuarios, la matriz de roles y perfiles y las evidencias de las autorizaciones para cada
usuario.

 RSA046: Autenticación. El sistema deberá contar con un mecanismo de autenticación

autónomo que permita asegurar el inicio de una sesión de usuario mediante el
suministro de sus credenciales.

 RSA047: Certificado Digital para Autenticación a Servicio Web. Deberá implementar el

proceso de autenticación de la petición con base en certificados digitales. Los
certificados deben contar con mínimo una llave RSA de 2048 bits, algoritmo de firma
sha256RSA y algoritmo de hash SHA256.

 RSA048: Datos de Usuario. El sistema deberá permitir incluir y modificar la información

general del usuario que sea requerida.

 RSA049: Autorización. El sistema deberá permitir el establecimiento, revisión y

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

92
 actualización de roles de usuario, por medio de los cuales se define la capacidad de
actuación de cada usuario con el sistema y su relación con las funcionalidades.

 RSA050: Validación de autorización. El sistema deberá verificar en cada actuación del

usuario que tenga los permisos requeridos en su perfil para ejecutar dicha acción. En
caso de no tenerlos deberá informar al usuario, denegar la acción y generar un registro
de auditoría o log relacionado.

 RSA051: Certificado Digital en Aplicación Web. Deberá permitir las conexiones por
medio del protocolo HTTPS, para transacciones que involucren información sensible.

 RSA052: El protocolo de cifrado en la capa de transporte debe ser protocolo TLS

(Transport Layer Security) en su versión 1.2 o su actualización más reciente (ya sea una
nueva versión o un nuevo protocolo que lo remplace si TLS pasa a ser considerado
como obsoleto o vulnerable).

 RSA053: El certificado digital deberá ser expedido por una Entidad Certificadora (CA)
específicamente para el sitio y con una vigencia máxima de tres (3) años. No deberán
utilizarse certificados autofirmados o de tipo wildcard.

 RSA054: Aseguramiento de Esquemas de Interoperabilidad. Deberá tener la capacidad

de cifrar los canales de conexión mediante protocolos seguros para aquellos procesos
de interoperabilidad con otras entidades o equipos VMS.

 RSA055: Expiración de Sesiones de Usuario. Deberá tener la capacidad de configurar

un tiempo límite para la expiración de sesión de los usuarios si no se detecta actividad.

 RSA056: Sesiones concurrentes de Usuario. El sistema deberá tener la capacidad de

configurar un número máximo de sesiones concurrentes de los usuarios y evitar el inicio
de sesión si se ha alcanzado dicho número.

 RSA057: Accesos de Terceros. Se debe considerar que parte de la infraestructura

presenta un esquema basado en redes seguras en donde se dispone de Firewalls
(Esquema de seguridad) mediante los cuales el manejo de puertos y protocolos son
administrados desde este punto, y no desde los sistemas de información.

 RSA058: El esquema de seguridad deberá validar la invocación al servidor de

aplicaciones únicamente por los servidores web habilitados.

 RSA059: El esquema de seguridad deberá registrar los intentos de conexión IP de

Usuarios de Aplicaciones.

 RSA060: El esquema de seguridad deberá validar que se realicen llamado a la base de

datos únicamente por los servidores de aplicaciones y que no se realicen consultas
directas por otras aplicaciones.

b. Requisitos de Auditabilidad

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

93
 RSA061: Trazabilidad de las acciones de Usuario. Deberá tener la capacidad de
mantener registrados datos de transacciones realizadas por los usuarios, como mínimo
deberá registrar fecha y hora, operaciones de: visualización, consulta, modificación,
ingreso al sistema, salida del sistema, intento fallido o exitoso de autenticación,
modificaciones de cualquier tipo y en cualquier módulo que afecte al sistema.

 RSA062: Trazabilidad de las Transacciones. Deberá tener la capacidad de mantener

registrada datos de todas las transacciones realizadas sobre el sistema; se debe
registrar datos de consultas, creación, modificación, edición, eliminación de registros,
para modificación o eliminación de registro se debe reportar el dato previo y posterior al
proceso. Debe registrarse: IP, fecha, tipo de transacción, funcionalidad, usuario.

 RSA063: Trazabilidad del Estado Operativo de Equipos VMS Gestionados. Deberá

tener la capacidad de mantener registrados datos de todos los estados operativos de los
equipos VMS que estén configurados en la plataforma y en operación, esta tarea se
lleva a partir de la funcionalidad de monitor de equipo VMS; Debe registrarse: Equipo
VMS, fecha, estado, alertas generadas, usuario en turno.

c. Requisitos de Compatibilidad

 RSA064: Interoperabilidad con Tecnología Servicios Web. Deberá estar en la capacidad

de interactuar con los sistemas existentes y definidos por cada plataforma usando
tecnologías de interoperabilidad basada en servicios web con las especificaciones: ISO
24097, SOAP, WSDL, UDDI, WSS-M, WS-I Basic Profile, Web Services Policy.

d. Requisitos de Disponibilidad

 RSA065: Disponibilidad continúa. El sistema deberá soportar una operación con

disponibilidad continua, 24 horas del día por 7 días de la semana; con base en la baja
criticidad de los servicios ofrecidos por la plataforma, se permite presentar puntos de
fallo o interrupciones que no superen los 30 minutos fuera de operación.

e. Requisitos de Robustez

 RSA066: Tolerancia a Mal Uso. El producto deberá responder de manera correcta y

mantener su operatividad, sin la presencia de bloqueos, ni negaciones del servicio a
posibles entradas inválidas que se puedan presentar. Todos los aspectos concernientes
a valores, reglas de validación, cálculos, comunicaciones, deberán quedar definidos de
tal manera que con el producto de software se logren aplicar, aún en condiciones
anormales.

f. Requisitos de Usabilidad

 RSA067: Diseño de Interfaces de Usuario. Permitir su uso en las diferentes plataformas

(Windows, IOS, Linux). Se establecerá un solo diseño gráfico con los colores estilos
distribuciones gráficas por medio de plantillas.

 RSA068: Despliegue. Los formularios y demás herramientas de apoyo deben ser

intuitivos, su despliegue frente al usuario debe ser rápida, autoajustable a cualquier

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

94
 tamaño y resolución de pantalla, utilizar imágenes optimizadas y componentes de
diseño que permitan mostrar la información de manera dinámica, ágil y estética.

 RSA069: Ayuda en Línea. Los formularios y demás herramientas de apoyo deben

presentar ayudas en línea. Cada uno de los módulos deberá contar con un video tutorial
donde se describe de manera clara cómo se utiliza el módulo, así mismo deberá contar
con audio con la explicación. En cada pantalla deberá aparecer un link para ingresar a
su correspondiente tutorial.
 RSA070: Gestión de errores y mensajes de error. El sistema deberá mostrar mensajes
e informes de error de manera codificada evitando mostrar información propia del
sistema o sus componentes.

 RSA071: Conectividad y Acceso. Las interfaces de comunicación deben contener los

estándares Web y fundamentalmente se deben basar en protocolos HTTP y HTTPS
para la comunicación con usuarios finales y para desarrollo de servicios de
interoperabilidad en caso de ser necesarios para las interfaces entre diferentes
aplicaciones y/o entidades.

g. Requisitos de Extensibilidad

 RSA072: Adherencia a Normas. Deberá presentar directa coherencia con la aplicación

de la normatividad establecida por el Ministerio de Transporte en lo que respecta a
Equipos VMS y su gestión, teniendo en cuenta la flexibilidad que debe tener el sistema
para el cambio de variables importantes que puedan ser ajustadas en el tiempo y que no
impliquen cambios estructurales o de ajuste al código de la aplicación desarrollada. Por
lo que el sistema debe tener un alto nivel de parametrización para garantizarlo.

h. Requisitos de Escalabilidad

 RSA073: Flexibilidad. Deberá tener la capacidad de modificar la configuración de los

parámetros de instalación sin requerir modificaciones al código fuente de la aplicación.
Debe ser totalmente independiente de la topología de red utilizada, es decir, el sistema
debe poder funcionar en múltiples esquemas de comunicación, tanto para equipos
conectados remotamente, como para equipos conectados por una red LAN, WAN o
Internet y todas las combinaciones anteriormente descritas.

 RSA074: Crecimiento de Infraestructura. Deberá tener escalabilidad Horizontal

(aumentando el número de servidores) y Vertical (aumentando la memoria de los
servidores y CPU). Así mismo, los componentes implementados a la medida deben ser
construidos sobre la base de un desarrollo incremental, de manera tal que nuevas
funcionalidades y requerimientos relacionados puedan ser incorporados afectando el
código existente de la menor manera posible.

i. Requisitos de Portabilidad

 RSA075: Soporte Arquitectura 32 y 64 Bits. Deberá tener la capacidad de ser ejecutado

sobre servidores de aplicaciones desplegados sobre infraestructura de hardware con
procesadores de 32 y 64 bits.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

95
 RSA076: Portabilidad en plataformas subyacentes. El sistema diseñado y sus
componentes deberán ser portables entre plataformas Unix, GNU/Linux y Windows, las
plataformas de aplicaciones conexas no deberán utilizar componentes propietarios o
que carezcan de sostenibilidad y evolución tecnológica.

17.2.2.1.4. Otros Requisitos

 RSA077: Mecanismo de Aseguramiento de Configuración Estándar en todos los

Equipos VMS para mensaje de Interés Nacional. La plataforma deberá implementar un
mecanismo automático que garantice la aplicación de la configuración estándar para
mensaje de interés nacional en todos los equipos VMS cuando son registrados por
primera vez en el sistema.

 RSA078: Desarrollo seguro de software. El sistema y sus componentes deben

construirse bajo buenas prácticas de desarrollo seguro, teniendo en cuenta los análisis
de código de la aplicación (análisis tipo SAST - Static Application Security Testing),
donde se analizan vulnerabilidades conocidas en código, teniendo en cuenta como
mínimo aquellas aplicables a código xml y web services dentro del top 10 del OWASP
vigente y el top 25 de la SANS y cualquier otra vulnerabilidad que sea posible detectar
por medio de herramientas de análisis estático de código.

 RSA079: Desarrollo seguro de software. El sistema y sus componentes deben

construirse bajo buenas prácticas de desarrollo seguro realizando análisis de pruebas
dinámicas autenticadas de aplicación tipo DAST (Dynamic Application Security Testing)

 RSA080: Consideraciones del Software Base o Subyacente. Todo el software

subyacente que permita la ejecución del servicio Web deberá contar con
parametrización que permita disminuir la probabilidad de ataques de denegación de
servicio, configuraciones como la restricción de sesiones simultáneas o cantidad de
sesiones simultáneas, vencimiento de sesión, entre otros controles que disminuyan la
efectividad de este tipo de ataques.

 RSA081: Consideraciones del Software Base o Subyacente. Todo el software

subyacente que permita la ejecución del servicio Web deberá contar con una
configuración de aseguramiento de sistema operativo, firmware y/o de cualquier otro
servicio expuesto por medio de un puerto de comunicaciones, este debe restringir
protocolos considerados como no seguros, tales como telnet, snmp, http, escritorio
remoto sin cifrado o cualquier otro servicio sin que se cuente con autenticación y cifrado
fuerte.

 RSA082: Consideraciones del Software Base o Subyacente. Todo el software

subyacente que permita la ejecución del servicio Web deberá contar r con
actualizaciones de firmware, sistema operativo y otros software que se encuentren
instalados en el mismo dispositivo, bajo un procedimiento de parchado y actualizaciones
de seguridad, dando un máximo de 30 días calendario para la instalación de parches o
actualizaciones críticas o de impacto alto a nivel de seguridad.

 RSA083: Consideraciones del Software Base o Subyacente. En caso de existir un

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

96
 sistema antivirus o antimalware instalado, debe estar implementado y configurado
apropiadamente y debe ser actualizado y gestionado según lo permita la arquitectura de
comunicaciones.

17.2.2.2. Plataforma de Gestión Local de Equipos VMS

A continuación se detallan los requisitos de los productos de software a desplegar

localmente en los equipos VMS: un primer componente que permitirá al equipo VMS
implementar la especificación para interoperabilidad con equipos VMS, tomando sus
definiciones e implementar un Servicio Web con las funciones de negocio y tipos de datos
descritos para la consulta y afectación de la características operativas del equipo VMS de
manera remota. Un segundo componente de software ejecutado de manera local para la
administración de un equipo VMS, con equipo de cómputo de manera integrada a su
infraestructura física o mediante conexión por los puertos disponibles por el equipo VMS.

17.2.2.2.1. Interfaces Externas

 RSA084: Interfaz Equipos VMS en Campo, Gestionar Localmente Equipos VMS

desplegados en campo. Esta plataforma deberá implementar un esquema de
interoperabilidad local y a discreción del operador, con el fin de permitir realizar la
administración y obtener datos de la operación del equipo VMS conectado.

17.2.2.2.2. Funciones

a. Gestión de equipos VMS

 RSA085: Consultar Características del Equipo VMS y sus Capacidades. El usuario

Operario de instalación, mantenimientos y traslados, deberá contar con una interfaz de
usuario final que le permita consultar las características y capacidades técnicas del
equipo VMS conectado.

 RSA086: Gestionar los Tipos de Fuente disponibles en un Equipo VMS. El usuario

Operario de instalación, mantenimientos y traslados, deberá contar con una interfaz de
usuario final que le permita gestionar los tipos de fuentes soportadas y disponibles en un
equipo VMS específico para despliegue del mensaje.

 RSA087: Gestionar un Mensaje en un Equipo VMS. El usuario Operario de instalación,

mantenimientos y traslados, deberá contar con una interfaz de usuario final que le
permita activar un mensaje en un equipo VMS específico, para lo cual deberá permitir
crear un mensaje particular nuevo o colocar un mensaje vacío.

 RSA088: Restablecer un Equipo VMS a configuración de fabricante. El usuario Operario

de instalación, mantenimientos y traslados, deberá contar con una interfaz de usuario
final que le permita restablecer un Equipo VMS con los parámetros de configuración
inicial suministrados por el fabricante.

 RSA089: Habilitar la administración local para un Equipo VMS. El usuario Operario de

instalación, mantenimientos y traslados, deberá contar con una interfaz de usuario final
que le permita establecer si el equipo VMS va a ser gestionado de manera local o

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

97
 remotamente desde el CCO.

 RSA090: Gestionar el Brillo de un Equipo VMS. El usuario Operario de instalación,

mantenimientos y traslados, deberá contar con una interfaz de usuario final que le
permita controlar el brillo del mensaje desplegado en un equipo VMS.

 RSA091: Monitorear el Estado Operacional de Equipos VMS. Esta plataforma deberá

contar con un mecanismo de monitoreo que permita obtener información constante y
directamente desde el equipo VMS configurado y en estado operativo activo.

 RSA092: Realizar Prueba de Estado Operacional de Lámpara de Equipos VMS. El

usuario Operario de instalación, mantenimientos y traslados, deberá contar con una
interfaz de usuario final que le permita activar una prueba del estado operacional de
Lámpara de un equipo VMS específico.

 RSA093: Realizar Prueba de Estado Operacional de Píxeles de Equipos VMS. El

usuario Operario de instalación, mantenimientos y traslados, deberá contar con una
interfaz de usuario final que le permita activar una prueba del estado operacional de
Píxeles de un equipo VMS específico.

 RSA094: Realizar Prueba de Estado Operacional de Dispositivo de Climatización de

Equipos VMS. El usuario Operario de instalación, mantenimientos y traslados, deberá
contar con una interfaz de usuario final que le permita activar una prueba del estado
operacional de Dispositivo de Climatización de un equipo VMS específico.

b. Requisitos de Rendimiento

 RSA095: Tiempo de Respuesta. El sistema deberá garantizar que el tiempo de

respuesta no será en medida promedio superior a 10 segundos.

 RSA096: Tiempo de Respuesta. Los tiempos de respuesta relacionados con formularios

de manejo de información adición, modificación, consulta de registros, autenticación y
emisión de avisos y confirmaciones por parte del usuario no debe ser superior a 5
segundos, los informes y consultas que presenten una complejidad alta no deberá
exceder el tiempo de 10 segundos.

 RSA097: Concurrencia. El sistema deberá estar en capacidad de prestar el servicio con

unos niveles aceptables de desempeño, para esto, se debe tener en cuenta la población
estimada de clientes y una concurrencia esperada de usuarios, así como las
proyecciones de crecimiento, basados en los servicios que prestará el sistema,
asegurando su escalabilidad. En la tabla siguiente se describen estas características:

Usuario Plataforma No. Usuarios

Usuarios Potenciales 1 usuario Operario de Instalación, Mantenimientos y Traslados

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

98
 Usuarios Concurrentes 1 usuario Operario de Instalación, Mantenimientos y Traslados

Tabla 2 usuarios Potenciales y Concurrentes Plataforma de Gestión Local

Fuente: Elaboración propia

17.2.2.2.3. Atributos del Sistema

a. Requisitos de Robustez

 RSA098: Tolerancia a Mal Uso. El producto deberá responder de manera correcta y

mantener su operatividad, sin la presencia de bloqueos, ni negaciones del servicio a
posibles entradas inválidas que se puedan presentar. Todos los aspectos concernientes
a valores, reglas de validación, cálculos, comunicaciones, deberán quedar definidos de
tal manera que con el producto de software se logren aplicar, aún en condiciones
anormales.

b. Requisitos de usabilidad

 RSA099: Interoperabilidad, Conectividad y Acceso a Equipo VMS. Deberá realizarse

mediante las interfaces físicas de comunicaciones dispuestas y disponibles en el
Equipos VMS, pudiendo ser estas: WiFi IEEE 802.11, Ethernet IEEE 802.3, Serial
RS232, o cualquier otra especificación realizada en el documento de Requisitos de
Hardware anexo a este documento.

 RSA100: Diseño de Interfaces de Usuario. Permitir su uso en las diferentes plataformas

(Windows, IOS, Linux). Se establecerá un solo diseño gráfico con los colores estilos
distribuciones gráficas por medio de plantillas

 RSA101: Despliegue. Los formularios y demás herramientas de apoyo deben ser

intuitivos al usuario, su despliegue frente al usuario debe ser rápida, autoajustable a
cualquier tamaño y resolución de pantalla del usuario, utilizar imágenes optimizadas y
componentes de diseño que permitan mostrar la información de manera dinámica, ágil y
estética.

 RSA102: Ayuda en Línea. Los formularios y demás herramientas de apoyo deben

presentar ayudas en línea, cada uno de los módulos deberá contar con un video tutorial
donde se describe de manera clara como se utiliza el módulo, así mismo deberá contar
con audio con la explicación. En cada pantalla deberá aparecer un link para ingresar a
su correspondiente tutorial.

c. Requisitos de Portabilidad

 RSA103: Soporte Arquitectura 32 y 64 Bits. Deberá tener la capacidad de ser ejecutado

sobre servidores de aplicaciones desplegados sobre infraestructura de hardware con
procesadores de 32 y 64 bits.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

99
17.2.2.3. Componente para Interoperabilidad de Equipos VMS

17.2.2.3.1. Interfaces Externas

 RSA104: Interfaz Plataforma de Gestión Remota en CCO. Este componente deberá

permitir realizar la gestión remota del equipo VMS desde el CCO. Implementa el
esquema de interoperabilidad propuesto por el Ministerio de Transporte.

17.2.2.3.2. Funciones

 RSA105: Gestionar Equipos VMS desde el CCO. Este componente deberá contar con
una interfaz que permita al equipo VMS recibir y procesar las peticiones desde la
Plataforma de Gestión Remota dispuesta en el CCO del Administrador Vial, habilitando
la afectación de su propia configuración y la publicación de las características de su
estado operativo.

a. Requisitos de Rendimiento

 RSA106: Tiempo de Respuesta. El componente deberá garantizar que el tiempo de

respuesta de las peticiones recibidas no será en medida promedio superior a 5
segundos.

 RSA107: Concurrencia. El sistema deberá estar en capacidad de prestar el servicio con

unos niveles aceptables de desempeño acorde al tiempo de respuesta requerido, para
esto, se debe tener en cuenta la población estimada de clientes y una concurrencia
esperada de usuarios, así como las proyecciones de crecimiento, basados en los
servicios que prestará el sistema, asegurando su escalabilidad. En la tabla siguiente se
describen estas características:

Usuario Plataforma No. Usuarios

Usuarios Potenciales 1 Plataforma de Gestión Remota en el CCO

Usuarios Concurrentes 1 Plataforma de Gestión Remota en el CCO, con peticiones de consulta

de estado operativo mínimo cada 60 segundos.

Tabla 3 usuarios Potenciales y Concurrentes Componente para Interoperabilidad de Equipos VMS

Fuente: Elaboración propia

17.2.2.3.3. Atributos del Sistema

a. Requisitos de Seguridad

 RSA108: Certificado Digital para Autenticación. Deberá implementar el proceso de

autenticación de la petición con base en certificados digitales. Los certificados deben
contar con mínimo una llave RSA de 2048 bits, algoritmo de firma sha256RSA y

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

100
 algoritmo de hash SHA256. Estos certificados podrán ser emitidos por una entidad
certificadora (CA) o podrán ser autofirmados siempre que garanticen las condiciones de
seguridad solicitadas.

 RSA109: Aseguramiento de Esquemas de Interoperabilidad. Deberá tener la capacidad

de cifrar los canales de conexión mediante protocolos seguros para aquellos procesos
de interoperabilidad con otras entidades.

b. Requisitos de Auditabilidad

 RSA110: Trazabilidad de las Transacciones. Deberá tener la capacidad de mantener

registrada datos de todas las transacciones realizadas sobre el sistema; se debe
registrar datos de consultas, creación, modificación, edición, eliminación de registros,
para modificación o eliminación de registro se debe reportar el dato previo y posterior al
proceso. Debe registrarse: IP, fecha, tipo de transacción, funcionalidad, usuario.

c. Requisitos de Compatibilidad

 RSA111: Interoperabilidad con Tecnología Servicios Web. Deberá estar en la capacidad

de interactuar con los sistemas existentes y definidos por cada plataforma usando
tecnologías de interoperabilidad basada en servicios web con las especificaciones:
ISO24097, SOAP, WSDL, UDDI, WSS-M, WS-I Basic Profile, Web Services Policy.

d. Requisitos de Disponibilidad

 RSA112: Disponibilidad continúa. El sistema deberá soportar una operación con

disponibilidad continua, 24 horas del día por 7 días de la semana; con base en la baja
criticidad de los servicios ofrecidos por la plataforma, se permite presentar puntos de
fallo o interrupciones que no superen los 5 minutos fuera de operación o el tiempo
máximo que tome el reinicio del servicio.

e. Requisitos de Robustez

 RSA113: Tolerancia a Mal Uso. Deberá responder de manera correcta a posibles

entradas inválidas que se puedan presentar. Todos los aspectos concernientes a
valores, reglas de validación, cálculos, comunicaciones, deberán quedar definidos de tal
manera que con el producto de software se logren aplicar, aún en condiciones
anormales.

f. Requisitos de Usabilidad

 RSA114: Conectividad y Acceso. Las interfaces de comunicación deben contener los

estándares Web y fundamentalmente se deben basar en protocolo HTTPS para
desarrollo de servicios de interoperabilidad en caso de ser necesarios para las
interfaces entre Equipos VMS y la plataforma de Gestión Remota.

 RSA115: Adherencia a Normas. Deberá presentar directa coherencia con la aplicación

de la normatividad establecida por el Ministerio de Transporte en lo que respecta a
Equipos VMS y su gestión, teniendo en cuenta la flexibilidad que debe tener el sistema
para el cambio de variables importantes que puedan ser ajustas en el tiempo y que no

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

101
 impliquen cambios estructurales o de ajuste al código de la aplicación desarrollada. Por
lo que el sistema debe tener un alto nivel de parametrización para garantizarlo.

g. Requisitos de Escalabilidad

 RSA116: Flexibilidad. Deberá tener la capacidad de modificar la configuración de los

parámetros de instalación sin requerir modificaciones al código fuente de la aplicación.
Debe ser totalmente independiente de la topología de red utilizada, es decir, el sistema
debe poder funcionar en múltiples esquemas de comunicación, tanto para equipos
conectados remotamente, como para equipos conectados por una red LAN, WAN o
Internet y todas las combinaciones anteriormente descritas.

17.2.2.3.4. Otros Requisitos

 RSA117: Consideraciones del Software Base o Subyacente. Todo el software

subyacente que permita la ejecución del servicio Web deberá contar con
parametrización que permita disminuir la probabilidad de ataques de denegación de
servicio, configuraciones como la restricción de sesiones simultáneas o cantidad de
sesiones simultáneas, vencimiento de sesión, entre otros controles que disminuyan la
efectividad de este tipo de ataques.

 RSA118: Consideraciones del Software Base o Subyacente. Todo el software

subyacente que permita la ejecución del servicio Web deberá contar con una
configuración de aseguramiento de sistema operativo, firmware y/o de cualquier otro
servicio expuesto por medio de un puerto de comunicaciones, este debe restringir
protocolos considerados como no seguros, tales como telnet, snmp, http, escritorio
remoto sin cifrado o cualquier otro servicio sin que se cuente con autenticación y cifrado
fuerte.

 RSA119: Consideraciones del Software Base o Subyacente. Todo el software

subyacente que permita la ejecución del servicio Web deberá contar con actualizaciones
de firmware, sistema operativo y otros software que se encuentren instalados en el
mismo dispositivo, bajo un procedimiento de parchado y actualizaciones de seguridad,
dando un máximo de 30 días calendario para la instalación de parches o actualizaciones
críticas o de impacto alto a nivel de seguridad.

 RSA120: Consideraciones del Software Base o Subyacente. En caso de existir un

sistema antivirus o antimalware instalado, debe estar implementado y configurado
apropiadamente y debe ser actualizado y gestionado según lo permita la arquitectura de
comunicaciones.

17.3. MINISTERIO DE TRANSPORTE

17.3.1. DESCRIPCIÓN GLOBAL DEL PRODUCTO SOFTWARE

17.3.1.1. Perspectiva del producto

Se coloca la plataforma de software SiGVMS en perspectiva con otras plataformas de
software externas a este módulo ITS pero con las cuales se mantiene una relación. A

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

102
continuación se expresa como la solución de software opera bajo ciertas restricciones de
entorno.

a. Interfaces de Sistema
Se listan y describen las interfaces del sistema SiGVMS y se identifican las funcionalidades
de software que dan cumplimiento a los requisitos de interoperabilidad.

Interoperabilidad SINITT, el decreto 2060 de 2015 reglamenta el Sistema inteligente

Nacional para la Infraestructura, el Tránsito y el Transporte, SINITT, administrado por el
Ministerio de Transporte, con sus respectivos subsistemas, y cuyo fin es garantizar la
centralización de la información y por ende la interoperabilidad de los diferentes sistemas.
Por definición y reglamentación el SiGVMS se convierte en un subsistema del SINITT y se
encuentra en la obligación de interoperar con los diferentes subsistemas existentes en el
SINITT y acorde a sus funcionalidades expuestas así:

- SiGAAE, subsistema para la Gestión y Autenticación de Actores Estratégicos, de

manera que los actores de la plataforma Web Empresarial puedan autenticar su
identidad, recibir la autorización para el ingreso a los módulos a los que tiene
acceso. Este componente permite la administración del ciclo de vida de dichos
usuarios.SiGTrazabilidad, subsistema para la Gestión de la Trazabilidad, para
almacenar la información relacionada con las transacciones realizadas por los
actores estratégicos dentro del SiGVMS.
- SiGMapas, subsistema para la gestión de Información Geográfica y Publicación de
Mapas; permite la verificación de la calidad y completitud de los datos reportados
versus la información geográfica de inventario vial.
- SiGUDDI, subsistema para la Gestión del Registro UDDI el cual corresponde a la
implementación de una plataforma central que permita la consolidación de un
catálogo de servicios web ofrecidos por los diferentes subsistemas, para mejorar el
acceso y consumo de los mismos por parte de los usuarios.

Interoperabilidad con los distintas plataformas de gestión de los CCO, implementados por
administradores viales del país, para el reporte de su información en los formatos aquí
establecidos y acceso directo a los equipos VMS dispuestos en la vía por ellos.

b. Interfaces de Usuario

Se listan y describen las interfaces de usuario requeridas por la solución, indicando las
características lógicas de las distintas interfaces entre el producto de software y el usuario,
incluyendo características de configuración y características de usabilidad que soporten la
facilidad de uso del software.
El SiGVMS propone una plataforma de software que deberá cumplir los siguientes
requisitos:

- Diseño de interfaces de usuario altamente usables.

- Despliegue de formularios de manera óptima y Ayuda en Línea que permitan al
usuario un apropiado uso de las interfaces.
- Compatibilidad con Dispositivos Móviles.
- Soporte a las tecnologías actualizadas de despliegue de interfaces basadas en
páginas HTML y soporte CCS.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

103
 - Tiempo de Ejecución aceptables y acorde a los requisitos de rendimiento.
- Conectividad y Acceso.

c. Interfaces de Hardware

En las definiciones realizadas para SiGVMS no existe funcionalidad alguna que requiera
una interoperabilidad directa con elementos de hardware específicos, diferentes al
subyacente y requerido para la ejecución del software propuesto.

d. Interfaces de Software

Se listan y especifican las interfaces de software requeridas por la solución.

- Clientes de los servicios Web para la interoperabilidad con SINITT y cada uno de
sus subsistemas requeridos: SiGTrazabilidad, SiGAAE, SiGMapas, SiGUDDI.
- Servicios Web que expongan las funciones de negocio necesarias para el reporte de
datos de equipos VMS y su operación por parte de los administradores viales.
- Cliente del Servicio Web expuesto por cada CCO implementado por los
administradores viales, soporte para la funcionalidad de difusión simultánea de
mensajes de interés nacional.

e. Interfaces de Comunicaciones

Se listan y especifican las interfaces de comunicaciones requeridas por la solución.

- Interfaces de comunicaciones para interoperabilidad con otros sistemas externos,

SiGVMS requiere acceso a la red de transmisión de datos pública (Internet) para
soportar su interoperabilidad con las plataformas de gestión de los CCO
implementados por los administradores viales del país. Del mismo modo, el acceso a
Internet es utilizado para exponer las funcionalidades Web de la Plataforma que
requieran ser accedidas por actores de consulta externos al Ministerio.
- Interfaces de comunicaciones para interoperabilidad con SINITT, SiGVMS requiere
acceso a la red de transmisión de datos interna del Ministerio de Transporte para
soportar su interoperabilidad con los subsistemas del SINITT estipulados.

f. Modos de Operación

En las definiciones de SiGVMS se ha dado alta importancia al proceso de respaldo y

disponibilidad de los datos, esto en coherencia con el significado de los mismos para el
sistema. Se propone incluir el servicio de alta disponibilidad de los datos como requisito
fundamental en la operación normal de la plataforma, de manera que, con la inclusión de,
por ejemplo, esquemas de ejecución paralela o basada en clústeres en el servicio clúster o
de manera alternativa como servicios en la nube, se logre una alta tolerancia a fallas del
software, así como, una mejor flexibilidad y eficiencia de costos en la planificación de la
capacidad del sistema, que permita escalabilidad acorde a las necesidades y condiciones
desempeño que surjan; serán planteadas políticas de respaldo de datos que permitan
protegerlos contra la pérdida, el deterioro, las catástrofes (naturales u obra del hombre) y
demás problemas que puedan surgir.

Tomando en consideración que:

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

104
 - Este módulo ITS dada su funcionalidad no incluye comportamientos de Alta
transaccionalidad, ni de misión crítica.
- Han sido incluidos mecanismos que mitiguen riesgos sobre los datos, como se
describió previamente.
- El registro de datos por parte de los administradores viales y entes territoriales se
realiza en intervalos separados en el tiempo, y en la medida de los cambios en
equipos VMS, los cuales son poco frecuentes.

Se concluye que el riesgo de pérdida de datos es relativamente bajo en caso de una

situación de catástrofe de los servicios de software y/o hardware propuestos, eso permite al
ministerio tolerar temporalmente la falta de funcionamiento y la caída de nivel de servicio
asociada al módulo ITS de SiGVMS. No es crítica, ni prioritaria la inclusión de planes de
operación alterna, ni de medidas de contingencia; en su reemplazo, con la definición de un
plan de recuperación, que incluya RTO y RPO precisos se puede controlar la situación de
desastre.

17.3.1.2. Funciones del producto

A continuación se proporciona un resumen de las funciones principales que SiGVMS
proveerá:

- Consulta de Información de la Operación de Equipos VMS en Colombia, proporciona

una herramienta que mediante un mapa geográfico permite visualizar la ubicación de
los distintos equipos VMS, sus datos básicos y su condición de funcionamiento. Es
utilizada por el despacho del Ministro o el funcionario o entidad que él considere
responsable.
- Actualización Datos Equipos VMS, proporciona una herramienta que permite a los
administradores viales reportar los datos de los equipos VMS que han instalado para
la operación de las vías de su jurisdicción, estos datos se actualizan
automáticamente a las capas geográficas correspondientes en el SiGMapas del
SINITT.
- Configuración del Banco de mensajes de Interés Nacional, proporciona una
herramienta que permite al despacho del Ministro o el funcionario o entidad que él
considere responsable realizar la configuración de un banco de mensajes y
pictogramas apropiado y basado en el diccionario de mensajes estandarizado
propuesto por este módulo ITS y perfeccionado por la ANSV, este banco de
mensajes únicamente está orientado a los mensajes de interés nacional.
- Difusión de Mensaje de Interés Nacional, proporciona una herramienta que permite
al despacho del Ministro o el funcionario o entidad que él considere responsable,
realizar la difusión de un mensaje de interés nacional de manera automática a todos
los equipos VMS de una misma zona geográfica, o en el más amplio de los casos,
de todo el país.

17.3.1.3. Características de los usuarios

Se describen las características generales de los usuarios que utilizarán el producto.

- Usuario Administrador del Sistema, representa el rol responsable de la

administración de la plataforma, conoce los procesos funcionales y de

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

105
 administración técnica, administra usuarios y otorga privilegios. Debe pertenecer a la
Dirección de Transporte o ser funcionario de la entidad que él Despacho del Ministro
considere pertinente.

- Usuario para Difusión de Mensaje de Interés Nacional, representa el rol

responsable de la funcionalidad de difusión de mensaje de interés nacional, el perfil
se otorga al despacho del Ministro o el funcionario o entidad que él considere
responsable.

- Usuario Consulta de Equipos VMS, representa el rol de la Oficina de Despacho

del Ministro de Transporte, la Oficina de Despacho del Viceministro de Transporte, la
Agencia Nacional de Seguridad Vial, o cualquier otra entidad externa que el Ministro
considere, que puede realizar la consulta sobre el estado de los Equipos VMS
desplegados en las vías del país, conoce el manejo de aplicaciones con interfaces
Web estándares y las funcionalidades básicas de consulta sobre la plataforma.

17.3.1.4. Restricciones

Se listan y describen de manera general cualquier condición que limite la implementación

del producto.

 Arquitectura SINITT, SiGVMS deberá respetar y asimilar las políticas de arquitectura del
SINITT y los subsistemas que se hayan detectado sean necesarios involucrar en su
operación.
- Interoperabilidad SiGAEE, SiGVMS deberá utilizar los mecanismos propuestos para
la gestión de usuarios y procesos de autenticación.
- Interoperabilidad SiGMapas, SiGVMS deberá utilizar los mecanismos propuestos
para la publicación de datos geográficos.
- Interoperabilidad SiGTrazabilidad, SiGVMS deberá utilizar los mecanismos
propuestos para el registro de eventos de sistema que impliquen afectación de datos
por parte de actores externos al Ministerio de Transporte.
- Interoperabilidad SiGUDDI, SiGVMS deberá utilizar los mecanismos propuestos para
la publicación, documentación y prestación de los servicios web expuesto por el
sistema.
- Interoperabilidad del sistema soportada en Servicios Web aplicando las siguientes
tecnología: SOAP, WSDL, UDDI, WSS-M, WS-I Basic Profile, Web Services Policy.

 Actualización de datos en tiempo real, la actualización de la información deberá ser en

línea, facilitando a los usuarios finales de la plataforma, la consulta inmediata de los
datos de equipos VMS reportados por los administradores viales.

 El SiGMapas es la plataforma GIS oficial del Ministerio de Transporte, en ella se

gestiona la información geográfica de equipos VMS.

 Para la formulación del esquema de interoperabilidad basado en servicios para la

administración remota de equipos VMS se deberán respetar los siguientes principios:

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

106
 - La naturaleza de la interfaz está determinada en parte por el carácter operativo de
los dispositivos que están siendo controlado.
- Se asume un modelo de operación de VMS en donde los controladores de VMS
poseen cierto grado de inteligencia y los datos utilizados para el despliegue de
mensajes y la configuración de señales reside en el controlador del VMS. Las
características tales como fuentes, gráficos, texto del mensaje, calendarios basados
en el tiempo, y así sucesivamente pueden residir en el controlador del VMS, y el
controlador presenta los mensajes en la pantalla de la señal con base en estos
datos.
- Existe un repositorio en el controlador del VMS desde donde se puede adquirir
información acerca del estado del controlador de VMS, el control, y los datos de
configuración.
- El mecanismo especifica las interfaces y/o peticiones Web mediante las cuales se
puede consultar y afectar el repositorio del controlador del VMS desde el CCO o
SiGVMS. No habrán comandos imperativos como “Despliegue un mensaje” o
“Informe el estado”, sino, por el contrario, existirá una petición a un servicio Web y
los atributos asociados a ella.
- El conjunto de servicios y correspondientes funciones configuran una capa de
abstracción a nivel de aplicaciones, con protocolo de comunicaciones TCP/IP
subyacente.
- El proveedor y/o fabricante tecnológico incluirá en los equipos VMS los componentes
de hardware y software necesarios para interpretar las peticiones y el lenguaje de
interoperabilidad basado en servicios web propuesto.

 Las funcionalidades que contengan contexto geográfico deberán contener las

funcionalidades mínimas de un Visor Geográfico estándar: Acercar, Alejar,
Desplazamientos e Identificación de elementos.

 Los componentes ampliamente distribuidos geográficamente deberán ser ejecutada en

su totalidad a través de un navegador de internet, con implementación de tecnología
Web, que no requiera Plug-Ins ni complementos adicionales, deberá contar con soporte
a las versiones más recientes de los distintos navegadores del mercado.

 Los componentes de software que contengan un diseño basado en Web deberán

presentar la apariencia institucional del Ministerio de transporte, acorde al portal web del
mismo y a los lineamientos del Manual de imagen corporativa, en su versión vigente.

 Las decisiones de diseño deberán respetar y asimilar los lineamientos del decreto 2573
de 2014, nuevo decreto de Gobierno en Línea - GEL.

 Todo el esquema de interoperabilidad propuesto y aquellas funcionalidades y servicios

que sean expuestos, deberán cumplir la especificación WS-Security, Web Services
Policy y la RFC 6797 HTTP Strict Transport Security.

 Las decisiones de diseño de datos alfanuméricos y geográficos deberán respetar y

asimilar toda la normatividad vigente aplicable y las mejores prácticas del diseño de
bases de datos.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

107
 Los productos de software aquí definidos, cuyos requisitos no logren ser cubiertos por
aplicaciones comerciales existentes, y sea necesario la construcción de soluciones a la
medida, deberán hacer uso en su proceso de implementación de estándares abiertos, y
no debe contemplarse el uso de componentes, framework, ni librerías comerciales que
requieran la adquisición de licencias adicionales.

 Todos los componentes del SiGVMS que así lo requieran, deberán ofrecer interfaces de
usuario que permita la administración de los datos de configuración y parametrización.

 Todos los componentes de software propuestos deberán ser portable, de manera que
pueda funcionar con independencia del sistema operativo subyacente.

 Todos los requisitos no funcionales especificados en este documento deben de ser

considerados como parte de las restricciones del producto de software.

17.3.1.5. Supuestos y dependencias

Se listan y describen de manera general cualquier condición cuya mínima variación afecta o
impacta el estado de algún requisito. No son considerados restricciones de diseño, pero,
cualquier cambio puede afectar los requisitos del producto.

- Arquitectura SINITT, todos los esquemas de interoperabilidad necesarios con el

SINITT, serán implementados con las definiciones actuales de la plataforma y sus
subsistemas.
- La funcionalidad de la herramienta que implique la ubicación geográfica de los
equipos VMS, dependerá directamente de la calidad de los datos registrados en el
SiGMapas.
- Existen procesos de registro y actualización de datos geográficos en el SiGMapas
que permiten mantener vigente la información de inventario vial referente a equipos
VMS.
- El SiGMapas expondrá los servicios de mapas con datos de equipos VMS y otros
asociados necesarios para SiGVMS y cualquier otro servicio que sea necesario en lo
que respecta a las funcionalidades con alcance geográfico.

17.3.2. REQUISITOS ESPECÍFICOS

17.3.2.1. Plataforma SiGVMS

A continuación se detallan los Requisitos del producto de software Plataforma SiGVMS, la
cual será desplegada por el Ministerio de Transporte y permitirá: 1) recolectar los datos
básicos de los equipos VMS dispuestos por los distintos administradores viales y entes
territoriales a lo largo de la red vial nacional y mantenerlos sincronizados con su
representación geográfica en el SiGMapas, y 2) permitir el envío simultáneo de un mensaje
de interés nacional a un grupo de equipos VMS contenidos en una zona geográfica
específica.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

108
17.3.2.1.1. Interfaces Externas

 RSM001: Interfaz SIGAEE, Gestionar Usuarios y Autenticación. Los usuarios de la

plataforma deberán ser administrados en el SIGAEE, esto incluye la gestión de
credenciales, el proceso de autenticación deberá ser realizado mediante los
mecanismos ofrecidos por SIGAEE para dicho cometido.

 RSM002: Interfaz SiGTrazabilidad, Registrar Eventos de Sistema. Las operaciones de

negocio realizada por los usuarios de la plataforma por cualquiera de sus interfaces –
interfaz de usuario web o servicios web – deberán quedar registradas en el
SiGTrazabilidad como un evento de sistema, para lo cual se deberán usar los servicios
expuestos por SiGTrazabilidad para dicho cometido.

 RSM003: Interfaz SiGUDDI, Describir y Descubrir Servicios Web. Los servicios Web
expuestos por esta plataforma deberán estar registrados y mantenerse actualizados en
el sistema SiGUDDI, el descubrimiento de los servicios por parte de los actores
entidades adscritas y entes territoriales se realizará a través de las funcionalidades
dispuestas en SiGUDDI para dicho cometido.
 RSM004, Interfaz SiGMapas, Actualizar los Datos de Equipos VMS. El proceso de
reporte de los datos de los equipos VMS gestionados por algún administrador vial y su
consecuente registro en la base de datos geográfica de SiGMapas deberán ser
efectuados a través de servicios de mapas WMS o WFS expuestos en SiGMapas para
dicho cometido.

 RSM005, Interfaz SiGMapas, Publicar Mapas. Las imágenes de mapas y

funcionalidades geográficas expuestas por la plataforma para las consultas o
funcionalidad de difusión de mensaje de interés nacional deberá ser realizada mediante
servicios WMS o WFS expuestos en SiGMapas para dicho cometido.

17.3.2.1.2. Funciones

a. Reporte de Datos de Equipos VMS mediante Interfaces de Servicio Web

Cualquier entidad en el país que funja como administrador vial de cualesquiera sean las
vías, tendrán la obligación de reportar al Ministerio de Transporte la información acerca de
los dispositivos VMS desplegados en ellas, para lo cual, tendrán disponible un conjunto de
funciones de negocio expuestas en un servicio Web para realizar el reporte de datos de
forma automática, mediante la implementación de clientes de los servicios Web
correspondientes.

 RSM006, Registrar Datos en SiGMapas. Deberá ser expuesto un servicio de

geoproceso en SiGMapas que permita registrar de manera automática los datos de
Equipos VMS en su base de datos geográfica subyacente.

 RSM007, Reportar Datos de Equipos VMS mediante servicio Web. Deberá ser expuesta
una función de negocio mediante un servicio Web que permita a las entidades reportar
los datos de cada uno de los equipos VMS que han sido desplegados en las vías de su
jurisdicción. Las características del Equipo VMS a reportar son las siguientes y deben

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

109
 ser suministrado en lenguaje natural y sin ningún tipo de codificación propia del
administrador vial:
· Administrador Vial.
· Tipo de Señal.
· Tecnología.
· Marca.
· Referencia.
· Proveedor.
· Dirección IP Interna.
· Dirección IP Pública o de acceso a la Plataforma de Gestión Remota.
· Coordenadas geográficas.
· Área disponible para desplegar el mensaje, Alto y Ancho en Píxeles.
· Espaciado de Píxel, también conocido como Pitch.
· Número de páginas permitidas.
· Longitud máxima del mensaje.
· Esquemas de colores soportados.
· Juegos de caracteres soportados.
· Tamaño máximo del carácter.
· Número máximo de pictogramas soportados en un mensaje.
· Tamaño máximo soportado para un pictograma.
· Estado Operativo.

b. Consulta de Equipos VMS

 RSM008, Consultar Equipos VMS. El usuario Consulta de Equipos VMS deberá contar
con una interfaz Web de usuario final que le permita visualizar en un mapa geográfico
los equipos VMS desplegados en la red vial del país. Deberá ser desplegada la
información del inventario vial del país disponible en SiGMapas o cualquier otro servicio
de información geográfica que esté disponible y que enriquezca la consulta. De los
equipos VMS únicamente se deberá permitir consultar las siguientes características:
· Administrador Vial.
· Tipo de Señal.
· Tecnología.
· Marca.
· Referencia.
· Coordenadas geográficas.
· Estado Operativo.

c. Gestión de Base de Mensajes y Pictogramas

 RSM009, Gestionar la base de datos de Mensajes y Pictogramas. El rol Administrador

del Sistema deberá contar con una interfaz Web de usuario final que le permita
gestionar – crear, modificar, eliminar – los distintos mensajes y pictogramas
estandarizados propuesto por este módulo ITS en diccionario de mensajes y
perfeccionado por la ANSV que deben ser usados en situaciones de interés nacional.

 RSM010, Gestionar Pictogramas. El rol Administrador del Sistema deberá contar con
una interfaz Web de usuario final que le permita gestionar – importar y eliminar –

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

110
 distintos pictogramas que serán almacenados en la base de datos.

 RSM011, Gestionar la Taxonomía o Tipología de Mensajes. El rol Administrador del

Sistema deberá contar con una interfaz Web de usuario final que le permita gestionar –
crear, modificar, eliminar – una taxonomía de los mensajes y pictogramas en la base de
datos, logrando crear una estructura de árbol con los tipos de mensajes acorde a los
casos de aplicación o uso.

 RSM012, Disponer de Campos Dinámicos. la plataforma deberá contar con un grupo de

campos dinámicos que podrán ser incluidos en el contenido de un mensaje en particular
y permita obtener de manera dinámica textos.

 RSM013, Gestionar Mensajes. El usuario Administrador del Sistema deberá contar con
una interfaz Web de usuario final que le permita gestionar – crear, modificar, eliminar –
los distintos mensajes que serán almacenados en la base de datos.

 RSM014, Validar Mensajes con Formato Estándar. El usuario Administrador del Sistema
deberá contar con una interfaz Web de usuario final que le permita validar que el
mensaje gestionado cumple con las características del formato estándar configurado en
la plataforma.

d. Difusión de Mensaje de Interés Nacional

 RSM015, Enviar la Activación de un Mensaje de Interés Nacional. Esta plataforma

deberá contar con una interfaz que permita el envío del mensaje de interés nacional a
un equipo VMS específico gestionado por un administrador vial particular.

 RSM016, Activar un Mensaje de Interés Nacional en Equipos VMS. El Usuario para

Difusión de Mensaje de Interés Nacional deberá contar con una interfaz Web de usuario
final que le permita activar un mensaje específico en un grupo de equipos VMS
específico.

e. Configuración General

 RSM017, Consultar la Configuración Estándar de Equipos VMS para Despliegue de

Mensajes de Interés Nacional. Deberá ser expuesta una función de negocio mediante
un servicio Web que permita a las entidades consultar los parámetros de configuración
estándar del mensaje de interés nacional.

 RSM018, Gestionar Tipos de Fuentes. El usuario Administrador del Sistema deberá

contar con una interfaz Web de usuario final que le permita gestionar – importar, crear,
modificar, eliminar – la definición de los distintos tipos de fuentes habilitadas para
configuración en los mensajes.

 RSM019, Seleccionar Fuente de la Configuración Estándar. El usuario Administrador del

Sistema deberá contar con una interfaz Web de usuario final que le permita establecer
un tipo de Fuente específica como la fuente estándar a utilizar para el mensaje de
Interés Nacional.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

111
 RSM020, Soportar Esquemas de colores. La plataforma deberá contar con soporte y
permitir la utilización de los esquemas de colores soportados por la especificación.

 RSM021, Seleccionar Esquema de Colores para la Configuración Estándar. El usuario

Administrador del Sistema deberá contar con una interfaz Web de usuario final que le
permita establecer un esquema de colores específico como el esquema de colores
estándar a utilizar para el mensaje de Interés Nacional.

 RSM022, Gestión de Datos Paramétricos o de Dominio. El usuario Administrador del

Sistema deberá contar con una interfaz Web de usuario final que le permita gestionar –
crear, modificar, eliminar – los datos paramétricos o de configuración necesarios por la
plataforma.

f. Requisitos de Rendimiento

 RSM023, Tiempo de Respuesta. La plataforma deberá garantizar que cuando haya

usuarios accediendo simultáneamente a él, su tiempo de respuesta no será en medida
promedio superior a 10 segundos.

 RSM024, Tiempo de Respuesta. La plataforma deberá garantizar que los tiempos de

respuesta relacionados con formularios de manejo de información adición, modificación,
consulta de registros, autenticación y emisión de avisos y confirmaciones por parte del
usuario no debe ser superior a 5 segundos, los informes y consultas que presenten una
complejidad alta no deberá exceder el tiempo de 10 segundos.

 RSM025, Concurrencia. La plataforma deberá estar en capacidad de prestar el servicio

con unos niveles aceptables de desempeño, para esto, se debe tener en cuenta la
población estimada y concurrencia esperada de usuarios. Para esto, se debe tener en
cuenta la población estimada de clientes y una concurrencia esperada de usuarios, así
como las proyecciones de crecimiento, basados en los servicios que prestará el sistema,
asegurando su escalabilidad. En la tabla siguiente se describen estas características:

Usuario Plataforma No. Usuarios

Usuarios Potenciales 206, discriminados así:

 1 Usuario para Difusión de Mensaje de Interés Nacional.

 5 Usuarios Consulta de Equipos VMS.
 o 200 Clientes Servicios Web Administradores Viales

Usuario Concurrentes 5, teniendo en cuenta que el despliegue de equipos VMS es muy

poco frecuente y el estado operativo de los equipos no varía mucho
en el tiempo.

Tabla 4 usuarios Potenciales y Concurrentes Plataforma SiGVMS

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

112
 Fuente: Elaboración propia

17.3.2.1.3. Atributos del Sistema

a. Requisitos de Seguridad

 RSM026, Acceso Restringido. El sistema deberá restringir el acceso por medio de uso
de claves asignadas a cada uno de los usuarios. Sólo podrán ingresar al sistema las
personas que estén registradas y autorizadas, estos usuarios serán clasificados por
perfiles con acceso a las opciones definidas para cada perfil.

 RSM027, Acceso Restringido. Deberán existir procedimientos de autorización y registro

de usuarios del sistema, propios y de terceros, que definan claramente las condiciones
por las cuales se podrá autorizar el acceso al sistema, las condiciones de permanencia
y las condiciones de remoción de los accesos, así como los controles periódicos de
validación y auditoría de los mismos.

 RSM028, Acceso Restringido. Se mantendrá documentada y actualizada la matriz de

usuarios, la matriz de roles y perfiles y las evidencias de las autorizaciones para cada
usuario.

 RSM029, Autenticación en Aplicación Web. El sistema deberá contar con un mecanismo

de autenticación soportado en el SiGAEE, deberá cumplir con las exigencias de
funcionalidad, seguridad y autenticación dispuestas por este Subsistema del SINITT.

 RSM030, Certificado Digital y Credenciales para Autenticación a Servicio Web. Deberá

implementar el proceso de autenticación de la petición con un mecanismo de doble
aseguramiento: 1) con base en certificados digitales; Los certificados deben contar con
mínimo una llave RSA de 2048 bits, algoritmo de firma sha256RSA y algoritmo de hash
SHA256. Y 2) con autenticación soportado en credenciales gestionadas en el SiGAEE,
deberá cumplir con las exigencias de funcionalidad, seguridad y autenticación
dispuestas por este Subsistema del SINITT.

 RSM031, Datos de Usuario. El sistema deberá permitir incluir y modificar la información

general del usuario que sea requerida por SiGVMS y no está contemplada dentro del
alcance de SiGAEE.

 RSM032, Autorización. El sistema deberá permitir el establecimiento, revisión y

actualización de roles de usuario, por medio de los cuales se define la capacidad de
actuación de cada usuario con el sistema y su relación con las funcionalidades.

 RSM033, Validación de autorización. El sistema deberá verificar en cada actuación del

usuario que tenga los permisos requeridos en su perfil para ejecutar dicha acción. En
caso de no tenerlos deberá informar al usuario, denegar la acción y generar un registro
de auditoría o log relacionado.

 RSM034, Certificado Digital en Aplicación Web. Deberá permitir las conexiones por
medio del protocolo HTTPS, para transacciones que involucren información sensible,

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

113
 por ejemplo, contraseñas.

 RSM035 , Certificado Digital en Aplicación Web.El protocolo de cifrado en la capa de

transporte debe ser protocolo TLS (Transport Layer Security) en su versión 1.2 o su
actualización más reciente (ya sea una nueva versión o un nuevo protocolo que lo
remplace si TLS pasa a ser considerado como obsoleto o vulnerable).

 RSM036, Certificado Digital en Aplicación Web.El certificado digital deberá ser expedido
por una Entidad Certificadora (CA) específicamente para el sitio y con una vigencia
máxima de tres (3) años. No deberán utilizarse certificados autofirmados o de tipo
wildcard.

 RSM037: Aseguramiento de Esquemas de Interoperabilidad. Deberá tener la capacidad

de cifrar los canales de conexión mediante protocolos seguros para aquellos procesos
de interoperabilidad con otras entidades.

 RSM038, Expiración de Sesiones de Usuario. Deberá tener la capacidad de configurar

un tiempo límite para la expiración de sesión de los usuarios si no se detecta actividad.

 RSM039, Sesiones concurrentes de Usuario. El sistema deberá tener la capacidad de

configurar un número máximo de sesiones concurrentes de los usuarios y evitar el inicio
de sesión si se ha alcanzado dicho número.

 RSM040, Accesos de Terceros. Se debe considerar que parte de la infraestructura

presenta un esquema basado en redes seguras en donde se dispone de Firewalls
(esquema de seguridad) mediante los cuales el manejo de puertos y protocolos son
administrados desde este punto, y no desde los sistemas de información.

 RSM041, Accesos de Terceros. El esquema de seguridad debe validar la invocación al

servidor de aplicaciones únicamente por solo los servidores web habilitados.

 RSM042: Accesos de Terceros. El esquema de seguridad debe registrar los intentos de

conexión IP de Usuarios de Aplicaciones.

 RSM043: Accesos de Terceros. El esquema de seguridad debe validar que se realicen

llamado a la base de datos únicamente por los servidores de aplicaciones y que no se
realicen consultas directas por otras aplicaciones.

b. Requisitos de Auditabilidad

 RSM044, Trazabilidad de la Configuración de la Autorización. Deberá tener la capacidad

de mantener registrados datos de usuarios y roles del sistema, así como los perfiles
asignados a usuarios y toda la trazabilidad que pueda surgir a partir de los cambios en
esta configuración. Esta capacidad deberá ser delegada al SiGTrazabilidad cumpliendo
con las exigencias de funcionalidad y seguridad dispuestas por este Subsistema del
SINITT.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

114
 RSM045, Trazabilidad de las acciones de Usuario. Deberá tener la capacidad de
mantener registrados datos de transacciones realizadas por los usuarios, como mínimo
deberá registrar fecha y hora, operaciones de: visualización, consulta, modificación,
ingreso al sistema, salida del sistema, intento fallido o exitoso de autenticación,
modificaciones de cualquier tipo y en cualquier modulo que afecte al sistema. Esta
capacidad deberá ser delegada al SiGTrazabilidad cumpliendo con las exigencias de
funcionalidad y seguridad dispuestas por este Subsistema del SINITT.

 RSM046: Trazabilidad de las Transacciones. Deberá tener la capacidad de mantener

registrada datos de todas las transacciones realizadas sobre el sistema; se debe
registrar datos de consultas, creación, modificación, edición, eliminación de registros,
para modificación o eliminación de registro se debe reportar el dato previo y posterior al
proceso. Debe registrarse: IP, fecha, tipo de transacción, funcionalidad, usuario, versión
del documento. Esta capacidad deberá ser delegada al SiGTrazabilidad cumpliendo con
las exigencias de funcionalidad y seguridad dispuestas por este Subsistema del SINITT.

c. Requisitos de Compatibilidad

 RSM047, Interoperabilidad con Tecnología Servicios Web. Deberá estar en la capacidad

de interactuar con los sistemas existentes y definidos por cada plataforma usando
tecnologías de interoperabilidad basada en servicios web con las especificaciones:
SOAP, WSDL, UDDI, WSS-M, WS-I Basic Profile, Web Services Policy.

d. Requisitos de Robustez

 RSM048: Tolerancia a Mal Uso. Deberá responder de manera correcta a posibles

entradas inválidas que se puedan presentar. Todos los aspectos concernientes a
valores, reglas de validación, cálculos, comunicaciones, deberán quedar definidos de tal
manera que con el producto de software se logren aplicar, aún en condiciones
anormales.

e. Requisitos de Usabilidad

 RSM049: Diseño de Interfaces de Usuario. Dado que son múltiples herramientas que
conformarán el sistema, se debe contemplar el diseño basado en Web que debe
presentar la apariencia institucional del Ministerio de Transporte, acorde al portal web
del mismo y a los lineamientos del Manual de imagen corporativa, en su versión vigente.

 RSM050, Despliegue. Los formularios y demás herramientas de apoyo deben ser

intuitivos al usuario, su despliegue frente al usuario debe ser rápida.

 RSM051: Ayuda en Línea. Los formularios y demás herramientas de apoyo deben

presentar ayudas en línea, cada uno de los módulos deberá contar con un video tutorial
donde se describe de manera clara como se utiliza el modulo, así mismo deberá contar
con audio con la explicación. En cada pantalla deberá aparecer un link para ingresar a
su correspondiente tutorial.
 RSM052: Soportar distintos Navegadores. Los componentes que requieran acceso
Web, deberán permitir su navegación a través de los exploradores más comunes como

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

115
 Mozilla, Chrome, Edge y Safari y en las diferentes plataformas (Windows, Mac, Linux),
autoajustable a cualquier tamaño y resolución de pantalla del usuario, utilizar imágenes
optimizadas y componentes de diseño que permitan mostrar la información de manera
dinámica, ágil y estética.

 RSM053: Soportar distintos Navegadores. El navegador no debe requerir ninguna

modificación o instalación de plug-in, applets, o similares para que el software funcione,
ni requerir soporte técnico al usuario para poder operar la aplicación.

 RSM054: Compatibilidad Dispositivos Móviles. Se debe considerar que el diseño de

interfaces tenga soporte para visualizaciones en dispositivos móviles (Smartphones y
tabletas), de conformidad con los estándares establecidos en la W3C, los cuales
corresponden a los publicados en el sitio http://www.w3.org/standards/webdesign/mobil/
y http://www.w3.org/TR/mobile-bp.

 RSM055: Soporte Tecnologías de Interface de Usuario basadas en Páginas Web HTML

versión actualizada. Los componentes que requieran acceso Web, deberán contar con
formularios web construidos en las tecnologías actualizadas de interfaces de usuario
tipo HTML.

 RSM056: Modularidad. La solución diseñada deberá está conformada por un único

sistema que tendrá los diversos módulos requeridos para cada una de las áreas
involucradas según su definición funcional y acorde a perfiles de usuarios.

 RSM057: Soporte CSS versión Actualizada. Se establecerá un solo diseño gráfico con
los colores, estilos y distribuciones gráficas por medio de plantillas y soportados sobre
las versiones más recientes de CSS. Adicionalmente se deberá tener un encabezado y
pie que será compartido por todos los formularios web.

 RSM058: Gestión de errores y mensajes de error. El sistema deberá mostrar mensajes

e informes de error de manera codificada evitando mostrar información propia del
sistema o sus componentes.

 RSM059: Conectividad y Acceso. Las interfaces de comunicación deben contener los

estándares Web y fundamentalmente se deben basar en protocolos HTTP y HTTPS
para la comunicación con usuarios finales y para desarrollo de servicios de
interoperabilidad en caso de ser necesarios para las interfaces entre diferentes
aplicaciones y/o entidades.

f. Requisitos de Extensibilidad

 RSM060: Implementación Reutilizable. Los componentes implementados a la medida

deberán ser construidos de manera que cualquier codificación de la aplicación debe
incluir el concepto de reusabilidad de los componentes de programación.

 RSM061, Implementación Modular. Deberá ser diseñado mediante componentes o

módulos independientes integrados, que permita evolucionar módulos por separado.
Adicionalmente, que sustente tecnológicamente la posibilidad de integración de la

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

116
 plataforma con otros aplicativos.

 RSM062, Cesión de Derechos y licenciamiento. Para los componentes implementados a

la medida se requiere la Cesión de Derechos de uso y patrimonio sobre el software. El
resultado del desarrollo del aplicativo deberá ser licenciado a nombre del Ministerio de
Transporte. Igualmente deberá ser entregado el código fuente, los ejecutables derivados
y los artefactos que soportan su implementación.

 RSM063: Adherencia a Normas. Deberá presentar directa coherencia con la aplicación

de la normatividad establecida, teniendo en cuenta la flexibilidad que debe tener el
sistema para el cambio de variables importantes que puedan ser ajustas en el tiempo y
que no impliquen cambios estructurales o de ajuste al código de la aplicación
desarrollada. Por lo que el sistema debe tener un alto nivel de parametrización para
garantizarlo.

 RSM064: Componentes, Librerías, API y Frameworks de Terceros. La integración de

cualquier tipo de componente o librerías de aplicativo, por ejemplo Frameworks, API,
DLL, ya sean de terceros o propios deben estar incluidos y licenciados en la solución sin
coste adicional, en caso de ser desarrollo a la medida deberá ser entregado el código
fuente a la entidad.

g. Requisitos de Escalabilidad

 RSM065, Flexibilidad. Deberá tener la capacidad de modificar la configuración de los

parámetros de instalación sin requerir modificaciones al código fuente de la aplicación.
Debe ser totalmente independiente de la topología de red utilizada, es decir, el sistema
debe poder funcionar en múltiples esquemas de comunicación, tanto para equipos
conectados remotamente, como para equipos conectados por una red LAN, WAN o
Internet y todas las combinaciones anteriormente descritas.

 RSM066: Crecimiento de Infraestructura. Deberá tener escalabilidad Horizontal

(aumentando el número de servidores) y Vertical (aumentando la memoria de los
servidores y CPU). Así mismo, los componentes implementados a la medida deben ser
construido sobre la base de un desarrollo incremental, de manera tal que nuevas
funcionalidades y requerimientos relacionados puedan ser incorporados afectando el
código existente de la menor manera posible.

h. Requisitos de Portabilidad

 RSM067: Soporte Arquitectura 32 y 64 Bits. Deberá tener la capacidad de ser ejecutado

sobre servidores de aplicaciones desplegados sobre infraestructura de hardware con
procesadores de 32 y 64 bits.

 RSM068: Portabilidad en plataformas subyacentes. El sistema diseñado y sus

componentes deberán ser portables entre plataformas Unix, GNU/Linux y Windows, las
plataformas de aplicaciones conexas no deberán utilizar componentes propietarios o
que carezcan de sostenibilidad y evolución tecnológica.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

117
17.3.2.1.4. Otros Requisitos

 RSM069, Definición e Implementación de la capa geográfica de Equipos VMS en

SiGMapas. Deberá ser definida e implementada en SiGMapas una estructura de datos
que permita catalogar de forma ordenada los datos de equipos VMS reportados por los
administradores viales.

 RSM070: Desarrollo seguro de software. El sistema y sus componentes deben

construirse bajo buenas prácticas de desarrollo seguro, teniendo en cuenta los análisis
de código de la aplicación (análisis tipo SAST - Static application security testing), donde
se analizan vulnerabilidades conocidas en código, teniendo en cuenta como mínimo
aquellas aplicables a código xml y web services dentro del top 10 del OWASP vigente y
el top 25 de la SANS y cualquier otra vulnerabilidad que sea posible detectar por medio
de herramientas de análisis estático de código.

 RSM071: Desarrollo seguro de software. El sistema y sus componentes deben

construirse bajo buenas prácticas de desarrollo seguro realizando análisis de pruebas
dinámicas autenticadas de aplicación tipo DAST (Dynamic Application Security Testing).
 RSM072: Consideraciones del Software Base o Subyacente. Todo el software
subyacente que permita la ejecución del servicio Web deberá contar con
parametrización que permita disminuir la probabilidad de ataques de denegación de
servicio, configuraciones como la restricción de sesiones simultáneas o cantidad de
sesiones simultáneas, vencimiento de sesión, entre otros controles que disminuyan la
efectividad de este tipo de ataques.

 RSM073: Consideraciones del Software Base o Subyacente. Todo el software

subyacente que permita la ejecución del servicio Web deberá contar con una
configuración de aseguramiento de sistema operativo, firmware y/o de cualquier otro
servicio expuesto por medio de un puerto de comunicaciones, este debe restringir
protocolos considerados como no seguros, tales como telnet, snmp, http, escritorio
remoto sin cifrado o cualquier otro servicio sin que se cuente con autenticación y cifrado
fuerte.

 RSM074: Consideraciones del Software Base o Subyacente. Todo el software

subyacente que permita la ejecución del servicio Web deberá contar con actualizaciones
de firmware, sistema operativo y otros software que se encuentren instalados en el
mismo dispositivo, bajo un procedimiento de parchado y actualizaciones de seguridad,
dando un máximo de 30 días calendario para la instalación de parches o actualizaciones
críticas o de impacto alto a nivel de seguridad.

 RSM075: Consideraciones del Software Base o Subyacente. En caso de existir un

sistema antivirus o antimalware instalado, debe estar implementado y configurado
apropiadamente y debe ser actualizado y gestionado según lo permita la arquitectura de
comunicaciones.

 RSM076: Consideraciones del Software Base o Subyacente. Los Web Services

utilizados para la interacción entre componentes del Subsistema SiGVMS o para la

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

118
 interacción con otros sistemas externos deberán estar basados en los protocolos SOAP
y WS-Security. Cada servicio debe estar expuesto únicamente por un puerto con
seguridad a nivel de transporte por medio de TLS (Transport Layer Security) en su
versión 1.2 o su actualización más reciente (ya sea a una nueva versión o a un nuevo
protocolo que lo remplace si TLS pasa a ser considerado como obsoleto o vulnerable).

17.3.2.2. Especificación para Interoperabilidad con Equipos VMS

A continuación se detallan los Requisitos de la Especificación para Interoperabilidad con
Equipos VMS, la cual Implementa un cliente de servicio Web para transformar las peticiones
realizadas desde las diferentes funcionalidades del componente de gestión en CCO a
peticiones XML que deben ser enviadas al equipo VMS indicado.
17.3.2.2.1. Gestión de la Configuración del Equipo VMS

a. Identificación del Equipo VMS

 RSM077: Determinar el Tipo de señal y tecnología. El Equipo VMS deberá permitir a la
Plataforma de Gestión Remota determinar su tipo y su tecnología.

b. Capacidades de Despliegue del Mensaje

 RSM078: Determinar tamaño del panel en píxeles. El Equipo VMS deberá permitir a la
Plataforma de Gestión Remota determinar el Tamaño de la señal en píxeles, el alto y el
ancho del panel.

 RSM079: Determinar tamaño del borde de la señal. El Equipo VMS deberá permitir a la
Plataforma de Gestión Remota determinar el Tamaño del borde de la señal, tamaño del
borde horizontal y vertical alrededor del panel.

 RSM080, Determinar tipo de Faro. El Equipo VMS deberá permitir a la Plataforma de

Gestión Remota determinar el Tipo de Dispositivo de Guía o Faro, Cualquier Dispositivo
de Guía o Faro conectado al equipo, Si este es el caso.

 RSM081: Determinar señal de acceso y leyenda. El Equipo VMS deberá permitir a la

Plataforma de Gestión Remota determinar el Mecanismo de acceso y leyenda,
mecanismo de acceso a los componentes internos de la señal y si tiene leyenda.

 RSM082: Determinar tamaño del panel en píxeles. El Equipo VMS deberá permitir a la
Plataforma de Gestión Remota determinar el Tamaño de la señal en píxeles, el alto y el
ancho de la matriz de despliegue.

 RSM083: Determinar tamaño del carácter en píxeles. El Equipo VMS deberá permitir a
la Plataforma de Gestión Remota determinar el Tamaño del carácter en píxeles, el alto y
el ancho de un carácter en píxeles.

 RSM084, Determinar espaciado en píxeles. El Equipo VMS deberá permitir a la

Plataforma de Gestión Remota determinar el Espaciado en píxeles, espaciado de
píxeles o también llamado pitch.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

119
 RSM085: Determinar máximo número de páginas. El Equipo VMS deberá permitir a la
Plataforma de Gestión Remota determinar el Máximo número de páginas, máximo
número de páginas que pueden ser incluidas en un mensaje sencillo.

 RSM086: Determinar la longitud máxima del mensaje. El Equipo VMS deberá permitir a
la Plataforma de Gestión Remota determinar la Longitud máxima del mensaje, longitud
máxima para un mensaje descargable.

 RSM087: Determinar los esquemas de color soportados. El Equipo VMS deberá permitir
a la Plataforma de Gestión Remota determinar el Esquema de color soportados, o si el
equipo VMS soporta un esquema de color distinto al esquema de color monocromático o
de un (1) bit soportado por defecto por todos los equipos VMS.

 RSM088: Determinar las Capacidad de Eliminación de todos los mensajes de un Tipo

particular. El Equipo VMS deberá permitir a la Plataforma de Gestión Remota determinar
si tiene la capacidad de eliminar todos los mensajes de un Tipo particular con una sola
instrucción.

c. Gestión de Fuentes
 RSM089: Determinar el Máximo Número de Fuentes soportadas. El Equipo VMS deberá
permitir a la Plataforma de Gestión Remota determinar el número máximo de fuentes
que pueden ser definidas y el número que están definidas en el Equipo VMS.

 RSM090: Determinar el Tamaño Máximo de Carácter. El Equipo VMS deberá permitir a

la Plataforma de Gestión Remota determinar el tamaño máximo en bytes que el equipo
VMS permite por cada mapa de bits de un carácter.

 RSM091: Determinar el Máximo Número de Caracteres por Fuente. El Equipo VMS

deberá permitir a la Plataforma de Gestión Remota determinar el máximo número de
caracteres que el equipo VMS permite para una fuente particular.

 RSM092: Recuperar la Definición de una Fuente. El Equipo VMS deberá permitir a la

Plataforma de Gestión Remota cargar las fuentes definidas en el equipo VMS.

 RSM093: Configurar una fuente. El Equipo VMS deberá permitir a la Plataforma de

Gestión Remota modificar o crear la definición de una fuente en el equipo VMS.

 RSM094: Borrar una fuente. El Equipo VMS deberá permitir a la Plataforma de Gestión
Remota borrar la definición de una fuente en el equipo VMS.

 RSM095: Validar una fuente. El Equipo VMS deberá permitir a la Plataforma de Gestión
Remota validar cualquier fuente almacenada dentro del equipo VMS para asegurar que
la especificación de la fuente es la esperada y no ha sido corrupta durante la descarga o
carga desde la última vez de uso.

d. Gestión de Pictogramas

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

120
 RSM096: Determinar el Máximo Número de Pictogramas. El Equipo VMS deberá
permitir a la Plataforma de Gestión determinar el número de Pictogramas definidos y el
número máximo que pueden ser definido dentro del equipo VMS.

 RSM097: Determinar el Tamaño Máximo del Pictograma. El Equipo VMS deberá

permitir a la Plataforma de Gestión Remota determinar el tamaño máximo en bytes que
el equipo VMS permite para cada pictograma.

 RSM098: Determinar la Memoria disponible para Pictogramas. El Equipo VMS deberá

permitir a la Plataforma de Gestión Remota determinar la memoria máxima disponible
para el almacenamiento de pictogramas.

 RSM099: Recuperar la definición de un Pictograma. El Equipo VMS deberá permitir a la

Plataforma de Gestión Remota obtener los Pictogramas definidos en el equipo VMS.

 RSM100: Configurar un Pictograma. El Equipo VMS deberá permitir a la Plataforma de

Gestión Remota modificar o crear la definición de un Pictograma en el equipo VMS.

 RSM101: Borrar un Pictograma. El Equipo VMS deberá permitir a la Plataforma de

Gestión Remota borrar la definición de un Pictograma en el equipo VMS.

 RSM102: Validar un Pictograma. El Equipo VMS deberá permitir a la Plataforma de

Gestión Remota validar cualquier Pictograma almacenado dentro del equipo VMS para
asegurar que el Pictograma es la esperado y no ha sido corrupto durante la descarga o
carga desde la última vez de uso.

e. Configuración del Brillo

 RSM103: Determinar el Máximo Número de Niveles del Sensor de luz. El Equipo VMS
deberá permitir a la Plataforma de Gestión determinar el número de niveles de detección
de luz ambiente soportados por los sensores de luz.

 RSM104: Configurar el Algoritmo de Salida de Luz. El Equipo VMS deberá permitir a la

Plataforma de Gestión Remota determinar y/o configurar las relaciones entre la
detección de luz ambiente – lectura de entrada sensor de luz – y el nivel de brillo de la
señal – luz de salida –.

17.3.2.2.2. Gestión del Equipo VMS

a. Gestión del Equipo VMS

 RSM105: Determinar Control Remoto o Local del Equipo VMS. El Equipo VMS deberá
permitir indicar si su administración se va a realizar de forma local o remota.

 RSM106: Reiniciar el Equipo VMS. El Equipo VMS deberá permitir a la Plataforma de

Gestión Remota reiniciarlo.

b. Activación de Mensajes

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

121
 RSM107: Activar un Mensaje. El Equipo VMS deberá permitir a la Plataforma de
Gestión Remota desplegar un mensaje en el panel, así:
- Cualquier mensaje permanente soportado por el equipo VMS
- Cualquier mensaje definido previamente
- Un mensaje en blanco de cualquier prioridad de tiempo de ejecución
- Un mensaje basado en calendarización.

c. Gestión de Parámetros de Visualización de Mensaje

 RSM108: Determinar los Parámetros de Visualización de Mensaje. El Equipo VMS

deberá permitir a la Plataforma de Gestión Remota determinar la configuración actual de
la visualización de mensaje en el equipo VMS, las características son:
- colores de fondo y primer plano predeterminado.
- Fuente predeterminada.
- Tiempos de Destello / Parpadeo predeterminado.
- Justificación de línea predeterminada.
- Justificación de página predeterminada.
- Tiempo predeterminado de despliegue para cada página.
- Juego de caracteres predeterminado.

 RSM109: Configurar los Colores de Fondo y Primer plano predeterminados. El Equipo

VMS deberá permitir a la Plataforma de Gestión Remota configurar el color de fondo y
de primer plano predeterminado para un mensaje en el panel a cualquier color
soportado por el equipo VMS.

 RSM110: Configurar la Fuente predeterminada. El Equipo VMS deberá permitir a la

Plataforma de Gestión Remota configurar la Fuente predeterminada del equipo VMS,
que deberá ser utilizada para despliegue de los textos del mensaje.

 RSM111: Configurar el Tiempo de Destello / Parpadeo predeterminado. El Equipo VMS

deberá permitir a la Plataforma de Gestión Remota configurar el Tiempo de Destello /
Parpadeo (Encendido – Apagado) predeterminado para textos o pictogramas de un
mensaje en el panel.

 RSM112: Configurar la Justificación de línea predeterminada. El Equipo VMS deberá

permitir a la Plataforma de Gestión Remota configurar Justificación de línea
predeterminada para una línea a cualquier valor de los soportados por el equipo VMS.

 RSM113: Configurar la Justificación de página predeterminada. El Equipo VMS deberá

permitir a la Plataforma de Gestión Remota configurar Justificación vertical
predeterminada de una página de texto en el panel a cualquier valor de los soportados
por el equipo VMS.

 RSM114: Configurar el Tiempo de despliegue para cada página. El Equipo VMS deberá
permitir a la Plataforma de Gestión Remota configurar el Tiempo por defecto de
despliegue para cada página de un mensaje multi página de un mensaje en el panel.

 RSM115: Configurar el Juego de caracteres predeterminado. El Equipo VMS deberá

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

122
 permitir a la Plataforma de Gestión Remota configurar el Juego de caracteres
predeterminado a ser usado cuando se visualice un mensaje a cualquier valor soportado
por el equipo VMS.

d. Gestión de Biblioteca de Mensajes

 RSM116: Determinar la Memoria de Almacenamiento de Mensajes. El Equipo VMS

deberá permitir a la Plataforma de Gestión Remota determinar el número de mensajes
que están actualmente almacenados y el espacio disponible dentro de la biblioteca de
mensajes del equipo VMS.

 RSM117: Definir un Mensaje. El Equipo VMS deberá permitir a la Plataforma de Gestión

Remota descargar un mensaje para almacenarlo dentro de la biblioteca de mensajes del
equipo VMS.

 RSM118: Verificar el Contenido de un Mensaje. El Equipo VMS deberá permitir a la

Plataforma de Gestión Remota verificar rápidamente que el contenido del mensaje sea
el esperado mediante el uso de un código relativamente único dentro de la biblioteca de
mensajes del equipo VMS.

 RSM119: Recuperar un Mensaje. El Equipo VMS deberá permitir a la Plataforma de

Gestión Remota cargar la definición de un mensaje desde la biblioteca de mensajes del
equipo VMS.

e. Programación de mensajes

 RSM120: Recuperar una programación. El Equipo VMS deberá permitir a la Plataforma

de Gestión Remota recuperar la programación de mensajes almacenada dentro del
equipo VMS.

 RSM121: Definir una programación. El Equipo VMS deberá permitir a la Plataforma de

Gestión Remota definir la programación de uno o más mensajes permanentes o
previamente definidos en el equipo VMS, debe ser con una resolución de tiempo de un
minuto.

f. Gestión de Mensajes basados en Eventos

 RSM122: Configurar mensaje para un evento de Recuperación después de una pérdida

de energía de corta duración. El Equipo VMS deberá permitir a la Plataforma de Gestión
Remota configurar cual es el mensajes a desplegar para una Recuperación después de
un pérdida de energía de corta duración.

 RSM123: Configurar mensaje para un evento de Recuperación después de una pérdida

de energía de larga duración. El Equipo VMS deberá permitir a la Plataforma de Gestión
Remota configurar cual es el mensajes a desplegar para una Recuperación después de
un pérdida de energía de larga duración.

 RSM124: Configurar mensaje para un evento de Pérdida de Energía. El Equipo VMS

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

123
 deberá permitir a la Plataforma de Gestión Remota configurar cual es el mensajes a
desplegar después de la recuperación luego de una pérdida de Energía

 RSM125: Configurar mensaje para un evento de Restablecimiento de la configuración

de fabricante. El Equipo VMS deberá permitir a la Plataforma de Gestión Remota
configurar cual es el mensajes a desplegar después del Restablecimiento de la
configuración de fabricante.

 RSM126: Configurar mensaje para un evento de Pérdida de comunicaciones con el

CCO. El Equipo VMS deberá permitir a la Plataforma de Gestión Remota configurar cual
es el mensajes a desplegar cuando suceda una Pérdida de comunicaciones con el
CCO.

 RSM127: Configurar mensaje para un evento de Vencimiento de la Duración de

despliegue de mensaje. El Equipo VMS deberá permitir a la Plataforma de Gestión
Remota configurar cual es el mensajes a desplegar para una Duración de despliegue de
mensaje cumplida.

g. Gestión de Dispositivos Externos

 RSM128: Determinar la Configuración Base de Puertos de Dispositivos Externos. El

Equipo VMS deberá permitir a la Plataforma de Gestión Remota determinar la
configuración de características básicas de cualquiera de los puertos pre configurados
controlando dispositivos externos soportados por el equipo VMS. Estas características
de configuración deberían ser:
- Tipo de puerto - digital o análogo
- Número de puerto
- Resolución del puerto - el número de bits usados para un puerto controlando un
dispositivo externo
- Dirección del puerto - entrada, salida, o bidireccional
- Descripción del puerto.

 RSM129: Definir más Puertos. El Equipo VMS deberá permitir a la Plataforma de

Gestión Remota establecer la descripción de puerto del parámetro de configuración de
dispositivo externo para definir y / o describir el propósito de los puertos soportados.

 RSM130: Soportar un Número de Dispositivos Externos. El Equipo VMS deberá

soportar un número mínimo de dispositivos externos.

 RSM131: Recuperar Datos de Dispositivos Externos. El Equipo VMS deberá permitir a

la Plataforma de Gestión Remota recuperar datos desde un dispositivo externo vía
cualquier puerto configurado 'as input' - puertos configurados para soportar monitoreo
de dispositivos externos.

 RSM132: Transmitir Datos a Dispositivos Externos. El Equipo VMS deberá permitir a la

Plataforma de Gestión Remota enviar datos a un dispositivo externo configurado como
'as output' - puertos configurados para soportar control de dispositivos externos.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

124
 RSM133: Determinar el Estado de Dispositivos Externos. El Equipo VMS deberá
permitir a la Plataforma de Gestión determinar el último estado enviado al dispositivo
externo a través de los puertos de salida configurados.

 RSM134: Recuperar datos desde un dispositivo externo. El Equipo VMS deberá permitir
a la Plataforma de Gestión recuperar datos desde un dispositivo externo configurados
los puertos bidireccionalmente para soportar el control de dispositivo externo.

 RSM135: Determinar el estado de dispositivo externo. El Equipo VMS deberá permitir a

la Plataforma de Gestión determinar el último estado enviado al dispositivo externo vía
puertos bidireccionales configurados.

h. Gestión del Brillo

 RSM136: Determinar el Número de Niveles de Brillo. El Equipo VMS deberá permitir a la

Plataforma de Gestión determinar el número máximo de niveles de brillo configurables.

 RSM137: Determinar las Lecturas Actuales de la Fotocelda. El Equipo VMS deberá

permitir a la Plataforma de Gestión determinar las lecturas actuales de la fotocelda.

 RSM138: Controlar Manualmente el Brillo. El Equipo VMS deberá permitir a la

Plataforma de Gestión controlar manualmente la luz de salida del panel.

 RSM139: Cambiar Modos de Control de Brillo. El Equipo VMS deberá permitir a la

Plataforma de Gestión cambiar entre los modos de control de brillo.

17.3.2.2.3. Gestión Operativa del Equipo VMS

a. Diagnóstico de Desempeño

 RSM140: Ejecutar prueba de la lámpara. El Equipo VMS deberá permitir a la Plataforma

de Gestión iniciar una prueba de la Lámpara.

 RSM141, Activar prueba de píxeles. El Equipo VMS deberá permitir a la Plataforma de

Gestión iniciar una prueba de píxel.

 RSM142, Ejecución de pruebas de equipos de control climático. El Equipo VMS deberá

permitir a la Plataforma de Gestión iniciar una prueba del equipo de control climático.

 RSM143, Proporcionar Información General sobre el Estado de Error. El Equipo VMS

deberá permitir a la Plataforma de Gestión recuperar una visión general de alto nivel del
estado operacional del Equipo VMS que incluye una indicación de las siguientes
condiciones de error y advertencia:
- Error de comunicaciones
- Error de suministro energía
- Error de dispositivo adjunto, sí hay dispositivos conectados presentes
- Error de la lámpara, sí la tecnología de lámpara es usada
- Error de píxel, sí es usada matriz de píxel

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

125
 - Error de luz de sensor, sí sensores de luz están presentes
- Mensaje de error
- Error de controlador
- Advertencia de temperatura, sí sensores de temperatura están presentes en
la carcasa del letrero o en el armario del controlador
- Error de sistema de control climático, sí hay un sistema de control climático
- Error crítico de temperatura, sí sensores de temperatura están presentes en
la carcasa del letrero o en el armario del controlador
- Error de señal del disco (drum), sí es usada la tecnología drum
- Advertencia de puerta abierta, sí existen sensores de puerta
- Advertencia por humedad, sí existen sensores de humedad

 RSM144: Monitorear errores de suministro de energía. El Equipo VMS deberá permitir a

la Plataforma de Gestión determinar el estado de cada fuente de suministro energía (sin
fallo, con fallo). El equipo potencial incluye fuentes de alimentación AC, fuentes de
alimentación DC, UPS, fuente de suministro energía solar y baterías.

 RSM145: Monitorear Errores de Lámpara. El Equipo VMS deberá permitir a la

Plataforma de Gestión determinar el estado de cada lámpara (sin fallo, bloqueada, sin
bloqueo).

 RSM146: Monitorear errores de píxel. El Equipo VMS deberá permitir a la Plataforma de

Gestión determinar el estado de cada píxel (sin fallo, bloqueada, sin bloqueo)

 RSM147: Monitorear errores de sensor de luz. El Equipo VMS deberá permitir a la

Plataforma de Gestión determinar el estado de cada sensor (sin fallo, con fallo).

 RSM148: Monitorear el controlador de operaciones de software. El Equipo VMS deberá

permitir a la Plataforma de Gestión determinar el estado del controlador de hardware y
software del equipo VMS.

 RSM149: Monitorear errores del sistema de control climático. El Equipo VMS deberá
permitir a la Plataforma de Gestión determinar el estado de cada sistema de control
climático tales como ventiladores o calentadores (sin fallo, con fallo).

 RSM150: Monitorear advertencias de temperatura. El Equipo VMS deberá permitir a la

Plataforma de Gestión determinar si la temperatura está dentro de límites aceptables, en
un rango de advertencia (ej. Advertencia de temperatura), o fuera de límites aceptables
(ej. Alarma crítica de temperatura).

 RSM151: Monitorear advertencias de humedad. El Equipo VMS deberá permitir a la

Plataforma de Gestión determinar si cada sensor de humedad está reportando
advertencia de humedad.

 RSM152: Monitorear de errores del rotor del disco. El Equipo VMS deberá permitir a la
Plataforma de determinar el estado de cada rotor de disco, si aplica.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

126
 RSM153: Monitorear el estado de la puerta. El Equipo VMS deberá permitir a la
Plataforma de determinar si la puerta del Equipo está abierta o cerrada.

 RSM154: Monitorear detalles de error en el suministro de energía. El Equipo VMS

deberá permitir a la Plataforma de Gestión establecer información detallada o de bajo
nivel de cualquier error e información asociada con cada fuente de suministro de
energía.

 RSM155: Monitorear detalles de error de la lámpara. El Equipo VMS deberá permitir a la

Plataforma de Gestión establecer información detallada o de bajo nivel de cualquier fallo
de lámpara, incluyendo:
- Descripción de la lámpara.
- Estado de la lámpara.
- Ubicación de la fila superior de píxeles servida por la lámpara.
- Ubicación de la columna de la izquierda de píxeles servida por la lámpara.
- Ubicación de la fila más inferior de píxeles servida por la lámpara.
- Ubicación de la columna de la derecha de píxeles servida por la lámpara.

 RSM156: Monitorear detalles de error de píxeles. El Equipo VMS deberá permitir a la

Plataforma de Gestión establecer información detallada o de bajo nivel para cualquier
píxel que no esté operacional, incluyendo:
- Ubicación horizontal del píxel.
- Ubicación vertical del píxel.
- El tipo de fallo (encendido / apagado, error por color, error eléctrico, error
mecánico, error que afecte todas o alguna configuración del píxel.

 RSM157: Monitorear detalles de error de la luz del sensor. El Equipo VMS deberá
permitir a la Plataforma de Gestión establecer información detallada o de bajo nivel de
cualquier sensor de luz.

 RSM158: Monitorear detalles de error de activación de mensajes. El Equipo VMS

deberá permitir a la Plataforma de Gestión establecer información detallada o de bajo
nivel sobre el éxito o el fracaso de la activación del último mensaje, incluyendo detalles
relacionados con cualquier error de contenido del mensaje.

 RSM159: Monitorear detalles de error del sistema de control Climático. El Equipo VMS
deberá permitir a la Plataforma de Gestión establecer información detallada o de bajo
nivel de cualquier sistema de control de clima como ventiladores, calentadores o
deshumidificadores.

 RSM160: Monitorear temperatura de la carcasa. El Equipo VMS deberá permitir a la

Plataforma de Gestión establecer información detallada o de bajo nivel de la
temperatura máxima y mínima de la carcasa del panel.

 RSM161: Monitorear humedad de la carcasa. El Equipo VMS deberá permitir a la

Plataforma de Gestión establecer información detallada o de bajo nivel de las lecturas
de humedad mínima y máxima dentro del panel.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

127
 RSM162: Monitorear detalles del error del rotor del rótulo del monitor. El Equipo VMS
deberá permitir a la Plataforma de Gestión establecer información detallada o de bajo
nivel del error particular asociado con un rotor de disco fallido.

 RSM163: Monitorear la temperatura del gabinete de control. El Equipo VMS deberá

permitir a la Plataforma de Gestión establecer información detallada o de bajo nivel de la
temperatura máxima y mínima del gabinete de control.

 RSM164: Monitorear la humedad del gabinete de control. El Equipo VMS deberá

permitir a la Plataforma de Gestión establecer información detallada o de bajo nivel de
las lecturas de humedad mínima y máxima dentro del gabinete.

 RSM165: Monitorear la fuente de Control, Remoto o Local. El Equipo VMS deberá

permitir a la Plataforma de Gestión determinar cuál es la fuente de control actual.

 RSM166: Monitorear origen del suministro de energía. El Equipo VMS deberá permitir a
la Plataforma de Gestión determinar el origen actual del suministro de energía. Los
posibles orígenes incluyen:
- Energía de Apagado
- Línea AC
- Generador
- Solar
- Batería – UPS
- Otro origen de suministro de energía

 RSM167: Monitorear el voltaje del suministro de energía. El Equipo VMS deberá permitir
a la Plataforma de Gestión determinar información del voltaje actual de la fuente de
energía utilizada. Esto podría significar voltaje de línea AC y/o voltaje de la batería.

 RSM168: Monitorear nivel de combustible actual. El Equipo VMS deberá permitir a la

Plataforma de Gestión determinar el nivel de combustible actual dentro del tanque
conectado al Equipo VMS.

 RSM169: Monitorear las RPM actuales del motor. El Equipo VMS deberá permitir a la
Plataforma de Gestión determinar las RPM actuales del motor conectado al Equipo
VMS.

 RSM170: Monitorear el Entorno Ambiental. El Equipo VMS deberá permitir a la

Plataforma de Gestión determinar la mínima y máxima temperatura del entorno
ambiental (ej. Fuera de la carcasa y del gabinete).

 RSM171: Determinar el Umbral de Temperatura Crítica. El Equipo VMS deberá permitir

a la Plataforma de Gestión determinar la temperatura crítica del fabricante, la cual, si se
excede en la carcasa o en el gabinete del controlador, generará una alarma de
temperatura crítica y hará que se apague el Equipo VMS.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

128
 b. Monitoreo del Mensaje Actual

 RSM172: Monitorear la información sobre el mensaje actualmente desplegado. El

Equipo VMS deberá permitir a la Plataforma de Gestión monitorear detalles sobre el
mensaje actual, incluyendo:
- El contenido del mensaje.
- El número de mensaje almacenado utilizado para activar el mensaje actual
- El tiempo restante de visualización del mensaje.
- El proceso o fuente que activó el mensaje
- El nivel de brillo actual del mensaje, si el brillo es soportado por el Equipo VMS.
- El estado del Dispositivo de Guía o Faro, si está presente.
- El estado de servicio de píxel, si es soportado por el Equipo VMS.

 RSM173: Monitorear los valores de campos dinámicos. El Equipo VMS deberá permitir
a la Plataforma de Gestión monitorear el valor(es) que actualmente está siendo
desplegado dentro de campos dinámicos del mensaje actual.

c. Monitoreo de Estado de las Funciones de Control

 RSM174: Monitorear el Mensaje de recuperación de energía después de una pérdida de

alimentación corta. El Equipo VMS deberá permitir a la Plataforma de Gestión
determinar cuál mensaje está actualmente configurado para ser desplegado en
respuesta a un evento de recuperación de energía después de una pérdida de
alimentación corta.

 RSM175: Monitorear el Mensaje de recuperación de energía después de una pérdida de

alimentación larga. El Equipo VMS deberá permitir a la Plataforma de Gestión
determinar cuál mensaje está actualmente configurado para ser desplegado en
respuesta a un evento de recuperación de energía después de una pérdida de
alimentación larga.

 RSM176: Monitorear el Mensaje de pérdida de energía. El Equipo VMS deberá permitir

a la Plataforma de Gestión determinar cuál mensaje está actualmente configurado para
ser desplegado durante una pérdida de energía.

 RSM177: Monitorear el Mensaje de reinicio eventual de software o hardware. El Equipo

VMS deberá permitir a la Plataforma de Gestión determinar cuál mensaje está
actualmente configurado para ser desplegado durante un reinicio eventual de software o
hardware.

 RSM178: Monitorear el Mensaje de pérdida de comunicaciones. El Equipo VMS deberá

permitir a la Plataforma de Gestión determinar cuál mensaje está actualmente
configurado para ser desplegado si las comunicaciones con la Plataforma Remota de
Gestión se pierden por un periodo de tiempo definido por el usuario.

 RSM179: Monitorear el Mensaje de fin de duración del mensaje. El Equipo VMS deberá
permitir a la Plataforma de Gestión determinar cuál mensaje está actualmente
configurado para ser desplegado al finalizar la duración actual del mensaje.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

129
17.3.2.2.4. Otros Requisitos

a. Requisitos de Interoperabilidad

 RSM180: Recuperar Datos desde Equipo VMS. El Equipo VMS deberá exponer un
conjunto de funciones de negocio mediante un servicio Web que le permita a la
Plataforma de Gestión Remota recuperar datos del Equipo VMS.

 RSM181: Suministrar Datos a Equipo VMS. El Equipo VMS deberá exponer un conjunto
de funciones de negocio mediante un servicio Web que le permita a la Plataforma de
Gestión Remota suministrar datos al Equipo VMS.

 RSM182: Determinar Capacidades de Equipo VMS. El Equipo VMS deberá exponer un

mecanismo que le permita a la Plataforma de Gestión Remota conocer las
características de los datos – Estructuras y tipos – soportados por el Equipo VMS, así
como de las funciones de negocio.

 RSM183: Gestionar Excepciones y Mensajes de Error. El Equipo VMS deberá permitir a

la Plataforma de Gestión Remota conocer las razones por las cuales una petición no
pudo ejecutarse correctamente. Deberá cumplir con el esquema propuesto por el
estándar SOAP para la gestión de excepciones y lanzamiento de errores.

 RSM184: Certificado Digital Autofirmado para Autenticación. Deberá implementar el

proceso de autenticación de la petición con base en certificados digitales autofirmados.
Los certificados deben contar con mínimo una llave RSA de 2048 bits, algoritmo de
firma sha256RSA y algoritmo de hash SHA256.

b. Eventos de Sucesos en el Equipo VMS

 RSM185: Configurar los Eventos a Registrar. El Equipo VMS deberá permitir a la

Plataforma de Gestión Remota establecer la configuración del servicio de registro de
eventos, pudiendo indicar que clase y que tipos de eventos se deben registrar y con qué
antigüedad se deben mantener.

 RSM186: Consultar la Configuración del Servicio de Registro de Eventos. El Equipo

VMS deberá permitir a la Plataforma de Gestión Remota consultar la configuración del
servicio de registro de eventos.

 RSM187: Consultar los Eventos Registrados. El Equipo VMS deberá permitir a la

Plataforma de Gestión Remota consultar los eventos registrados:
- Número total de eventos.
- Datos detallados de los eventos.

 RSM188: Consultar las Capacidades del Servicio de Registro de Eventos. El Equipo

VMS deberá permitir a la Plataforma de Gestión Remota consultar las capacidades del
servicio de registro de eventos, pudiendo conocer el número de clases, número de tipos
de eventos y número de eventos que pueden ser soportados por el Equipo VMS.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

130
 RSM189: Eliminar los Eventos Registrados. El Equipo VMS deberá permitir a la
Plataforma de Gestión Remota eliminar todos o un grupo de eventos registrados
filtrados por periodo de tiempo.

 RSM190: Eliminar los Eventos Registrados vencidos. El Equipo VMS deberá permitir a
la Plataforma de Gestión Remota, eliminar de manera automática todos o un grupo de
eventos registrados que no cumplan con las condiciones de mantención definidas.

c. Del Contenido del Mensaje

 RSM191: Identificar Mensaje a Definir. Cada mensaje almacenado en el Equipo VMS

deberá estar asociado con un único identificador.

 RSM192: Soportar Mensajes Multipágina. Se deberá permitir que el mensaje contenga

el número de distintas páginas a mostrar según se define en la especificación. Si la
especificación no define el número de pantallas de páginas distintas que deben ser
soportadas, el Equipo VMS soportará al menos una página por mensaje.

 RSM193: Soportar Justificación de Página. Se deberá permitir que para el mensaje se

especifique una justificación vertical, la cual podrá ser aplicada individualmente a cada
página del mensaje o una única a todas las páginas del mensaje. Los valores que la
justificación podrá tomar son:
- Arriba
- Al Medio
- Abajo

 RSM194: Soportar Mensajes Multilínea. Se deberá permitir que cada página del
mensaje contenga hasta el número de líneas como se define en la especificación. Si la
especificación no define el número de líneas que deben ser soportadas, el Equipo VMS
debe soportar al menos una línea por página.

 RSM195: Soportar Justificación de Línea. Se deberá permitir que para el mensaje se

especifique una justificación de línea, la cual podrá ser aplicada: a todo el mensaje, a
toda una página, o a una línea específica. Los valores que la justificación podrá tomar
son:
- Izquierda
- Centro
- Derecha
- Justificado o de línea completa.

 RSM196: Soportar Combinación de Colores. Se deberá permitir que para el mensaje se

especifique un solo color de primer plano y un solo color de fondo, la cual podrá ser
aplicada: a todo el mensaje, a toda una página, o a un carácter particular.

 RSM197: Soportar Color Rectangular. Se deberá permitir que el contenido del mensaje
especifique un área del panel para mostrar un color seleccionado.

 RSM198: Soportar Definición de una Fuente. Se deberá permitir que el contenido del

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

131
 mensaje especifique una sola fuente, la cual podrá ser aplicada: a todo el mensaje, a
toda una página, o a un carácter particular.

 RSM199: Soportar Espaciado de Caracteres. Se deberá permitir que el contenido del

mensaje especifique el espaciado entre caracteres en una cadena de texto o entre texto
y un gráfico carácter por carácter. Si se admite esta función, todos los parámetros
configurables de esta función deberán estar completamente soportados.

 RSM200: Soportar Tiempos de Visualización de Página Personalizables en un Mensaje.

Se deberá permitir especificar el momento de mostrar cada página y el momento de
borrar el panel entre cada página al mostrar un mensaje de varias páginas.

 RSM201: Soportar Intermitencia. Se deberá permitir que el contenido del mensaje

identifique porciones de texto (y / o gráficos) para ser intermitente, la cual podrá ser
aplicada: carácter por carácter, línea por línea o página por página.

 RSM202: Soportar Tiempos de Intermitencia Personalizables dentro de un Mensaje. Se

deberá permitir que para el contenido del mensaje se especifique la hora de
visualización y el tiempo de borrado de cada sección del texto intermitente.

 RSM203: Soportar Campos Dinámicos de datos del mensaje. Se deberá permitir que
para el contenido del mensaje se especifiquen campos que incluyan en el texto un dato
dinámico, acorde a lo siguiente:
- Hora actual en formato militar
- Hora actual en formato AM/PM en minúsculas o mayúsculas.
- Temperatura actual
- Día de la semana actual, en números o textos
- Día del mes actual
- Mes del año actual
- Año actual
- Cualquier Atributo con un valor estático que requiera ser parametrizado por el
usuario Operador del CCO.

 RSM204: Soportar Determinar la Frecuencia de Actualización del campo Dinámico. Se

deberá permitir determinar cómo se debe actualizar cada campo a una frecuencia de
actualización. Si la especificación no indica la frecuencia de actualización, el Equipo
VMS actualizará los campos al menos cada 60 segundos.

 RSM205: Soportar Gráficos. Se deberá permitir que para el contenido del mensaje se
incluya cero o más gráficos en cualquier lugar del mensaje.

 RSM206: Especificar la Ubicación de los Mensajes a Visualizar. Se deberá permitir que

el contenido del mensaje especifique la posición inicial del texto y los gráficos en la
señal a una resolución de un píxel.

 RSM207: Soportar Contenido Textual. Se deberá permitir que el contenido del mensaje
incluya cualquier carácter soportado por el Equipo VMS en cualquier orden, a menos

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

132
 que la especificación lo restrinja de otra manera.

 RSM208: Soportar Longitudes de Mensaje Compatibles con el Panel. Se deberá permitir

que el contenido del mensaje contenga cualquier número de caracteres por página para
cada página, hasta los límites físicos del panel.

 RSM209: Soportar Esquema de sombras de 256. Se deberá soportar el esquema de

colores monocromático de 8 bit, donde cada píxel puede ser definido usando una paleta
de escala de grises con 256 sombras que van desde 0 hasta 255.

 RSM210: Soportar Esquema clásico de colores. Se deberá soportar el esquema clásico

de colores, con los colores: negro, rojo, amarillo, verde, cian, azul, magenta, blanco,
naranja, ámbar.

 RSM211: Soportar Esquema colores de 24 Bits. Se deberá soportar el Esquema colores

de 24 Bits, donde cada píxel podrá ser definido por tres bytes, uno para rojo, otro para el
verde y un último para azul.

 RSM212: Soportar Esquema Único color. Se deberá soportar el Esquema Único color,
soporte para el color negro (o apagado) y al menos cualquier otro color.

18. VERIFICACIÓN
El plan de verificación documenta la estrategia que se utilizará para verificar y asegurar que
un producto o sistema cumple con sus requisitos. Se desarrolla en dos etapas: inicialmente
se diseña el esfuerzo de verificación, luego se detalla el procedimiento que describe los
pasos específicos y detallados que se deben seguir para realizar las actividades de
verificación. Siguiendo la metodología V en esta documentación se incluye la primera etapa
del proceso.

18.1. CARACTERÍSTICAS DEL SISTEMA

18.1.1. PERSPECTIVA

a. Interfaces
Se coloca la plataforma de software SiGVMS en perspectiva con otras plataformas de
software externas a este módulo ITS pero con las cuales se mantiene una relación. A
continuación se describen las interfaces a través de las cuales interopera con otros
sistemas:

 Clientes de los servicios Web para la interoperabilidad con SINITT y cada uno de los
subsistemas requeridos: SiGTrazabilidad, SiGAAE, SiGMapas, SiGUDDI.
 Servicios Web que expone las funciones de negocio necesarias para el reporte
automático de datos de equipos VMS por parte de las entidades administradoras
viales.
 Cliente del Servicio Web expuesto por los administradores viales en su plataforma
de Gestión Remota del CCO para la activación del mensaje de interés nacional

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

133
 desde el SiGVMS.

b. Arquitectura
El SiGVMS se soportará en una plataforma tecnológica robusta conformada por una
Plataforma Web Empresarial responsabilidad del Ministerio de Transporte y desarrollada a
la medida, que permite recolectar los datos básicos de los equipos VMS dispuestos por los
distintos administradores viales a lo largo de la red vial nacional y mantenerlos
sincronizados con su representación geográfica en el SiGMapas, adicionalmente permite el
envío simultáneo de un mensaje de interés nacional a un grupo de equipos VMS contenidos
en una zona geográfica específica.

Adicionalmente a la plataforma se define una especificación técnica de componentes de

software que deberán ser implementados por los administradores viales y que soporte el
proceso de adquisición de equipos VMS y consecuentemente su administración. Los
componentes son:

 Plataforma de Gestión Remota de Equipos VMS, para la administración desde un

CCO de los equipos VMS dispuesto en la vía, así mismo, es el punto intermedio o de
comunicación para la administración de los equipos VMS de forma remota desde la
plataforma SiGVMS dispuesta por el Ministerio de Transporte.
 Componente de Interoperabilidad desplegado sobre el equipo VMS el cual se
soporta en el esquema de interoperabilidad basado en Servicios para su
Administración Remota desde el CCO.
 Componente de Administración local del Equipo VMS, el cual corresponde a una
implementación de software que permite conocer el estado y configuración del
equipo VMS desde una interfaces de computo conectada directamente sobre él.

18.2. ELEMENTOS OBJETIVOS

La siguiente es una lista de alto nivel de los elementos a probar – requisitos funcionales y
no funcionales, implementados en software, hardware y otros elementos de soporte del
producto –, que han sido identificados como objetivos de las pruebas. Esta lista representa
los elementos qué serán probados. Los detalles de cada prueba serán determinados
posteriormente en los set de pruebas con sus respectivos casos de pruebas.

 La autenticación al sistema con esquema interoperado con SINITT, SiGAAE.

 La consulta de Información de la operación de Equipos VMS en Colombia, mediante
un mapa geográfico se visualiza la ubicación de los distintos equipos VMS, sus
datos básicos y su condición de funcionamiento.
 La actualización de los datos de Equipos VMS, mediante servicio Web e
interoperabilidad con SINITT, SiGMapas.
 La configuración del Banco de mensajes de Interés Nacional.
 La difusión de un Mensaje de Interés Nacional, a través de la selección de un equipo
VMS y el envío de un mensaje seleccionado desde el banco de mensajes.
 La trazabilidad de eventos del sistema con esquema interoperado con SINITT,
SiGTrazabilidad.
 El despliegue de funcionalidades con contexto geográfico del sistema con esquema
interoperado con SINITT, SiGMapas.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

134
18.3. PANORAMA DE PRUEBAS
Esta sección provee una panorámica general de las pruebas que deberán ser ejecutadas.
El marco en esta sección representa una panorámica de alto nivel de las pruebas que
deberán ser ejecutadas y las que no.

18.3.1. PRUEBAS INCLUIDAS

Se describe una panorámica de alto nivel de las más importantes pruebas incluidas y
planeadas para el sistema.

a. Pruebas Funcionales

 Verifica y asegura el comportamiento apropiado de los requisitos funcionales

descritos en cada caso de uso.
 Verificar la navegación del sistema para que cumpla con lo descrito en el caso de
uso.
 Verificar la entrada de datos para que cumple con lo descrito en el caso de uso.
 Verificar el procesamiento y la obtención de los resultados que cumple con lo
descrito en el caso de uso.
 Verificar la interacción con las distintas aplicaciones y que cumpla con los resultados
descritos en el caso de uso y los esquemas de interoperabilidad definidos.
 Verificar funcionalidad de cada uno de los casos de uso u otra especificación técnica
incluida.

b. Pruebas Interfaces Gráficas de Usuario

 Verificar los esquemas de navegación entre ventanas.

 Verificar que todos los controles de interfaz gráfica de usuario están correctamente
diseñado y cumplen con los estándares de presentación definidos.
 Verificar que la navegación refleje las funcionalidades del negocio y requisitos.
 Verificar la navegación ventana por ventana usando diferentes modos de acceso –
tabuladores, movimientos del ratón, teclas rápidas, entre otras –.
 Verificar los objetos de la ventana y características, tales como menús, medidas,
posiciones, estados y focos se verifican conforme a los estándares.
 Verificar el soporte de navegación a través de los exploradores más comunes como
Mozilla, Chrome, Edge y Safari y en las diferentes plataformas (Windows, Mac,
Linux).
 Verificar la compatibilidad con dispositivos móviles.

c. Pruebas Usabilidad

 Verificar diseño y presentación del sistema que cumpla con el estándar y diseño de
presentación definido.
 Verificar que los mensajes de alerta, error, datos numéricos, datos de fecha, datos
porcentuales, sean uniformes y cumplan con el estándar y diseño de presentación
definido.
 Verificar que las fechas y datos numéricos sean uniformes y cumplan con el
estándar y diseño de presentación definido.
 Verificar la alineación y distribución en pantalla y listados del sistema de información.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

135
 Verificar que los formularios y demás herramientas de apoyo presentan ayudas en
línea, con un video tutorial y audio con la explicación.

d. Pruebas de Sistema

 Verificar el acceso a la aplicación, inicio de sesión y cierre de sesión.

 Verificar que los esquemas de interoperabilidad cumplen con lo especificado.
 Verificar que la interoperabilidad con los sistemas existentes y definidos por cada
plataforma usan tecnologías basada en servicios web.

e. Pruebas de Seguridad

 Verificar el funcionamiento correcto de los controles de seguridad.

 Verificar el acceso a la aplicación, inicio de sesión y cierre de sesión con roles
válidos e inválidos.
 Verificar la funcionalidad de cada caso de uso con roles válidos e inválidos.
 Verificar la parametrización del tiempo máximo de inactividad.
 Verificar que el tiempo máximo de inactividad dentro del sistema se cumpla y expira
la sesión del usuario, informándole que la sesión fue expirada por inactividad y debe
conectarse nuevamente a la aplicación.
 Verificar la parametrización de un número máximo de intentos para el ingreso a la
aplicación.
 Verificar el número máximo de intentos de ingreso al sistema por parte del usuario
por error en contraseña, donde se bloqueé el ingreso al sistema para el usuario y
adicionalmente envía un correo electrónico describiendo lo ocurrido.
 Verificar que NO existen conexiones directas entre los usuarios y la base de datos.
 Verificar las conexiones por medio del protocolo HTTPS/TLS mediante la
implementación de un protocolo de cifrado en la capa de transporte considerado
seguro o no vulnerable.

f. Pruebas de Registro de Eventos del Sistema y Auditoría

 Verificar los eventos y transacciones en el sistema.

 Verificar los registros de movimientos y navegación a través del sistema.
 Verificar que el registro de evento en el sistema contiene datos de usuario, fecha,
hora, acción, evento realizado, descripción de campos modificados o actualizados.
 Verificar que el registro de evento en el sistema contiene la dirección IP de la
máquina desde la cual se realizó la acción.

g. Pruebas de Integridad de datos

 Verificar que los datos han sido grabados apropiadamente en las bases de datos.
 Verificar la correcta obtención de datos actualizados.

h. Pruebas de Rendimiento, Carga y Stress

 Verificar el tiempo de respuesta para los casos de uso bajo diferentes condiciones
de carga y acorde a los requisitos de desempeño indicados.
 Verificar el tiempo de respuesta del sistema donde los usuarios ingresen simultánea

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

136
 o progresivamente y acorde a los requisitos de desempeño indicados.

18.3.2. OTRAS CANDIDATAS PARA SER POTENCIALMENTE INCLUIDAS

Se describe una panorámica de alto nivel de las pruebas que no serán incluidas pero dada
ciertas condiciones podrían serlo.

a. Interoperabilidad Sistemas Externos

 Verificar interoperabilidad con sistemas externos de entidades administradores

viales para el reporte de datos de equipos VMS mediante servicio Web, esto
depende de la existencia del sistema externo y la implementación del cliente
respectivo, así como, la existencia de ambientes de calidad o pruebas apropiados.
 Verificar interoperabilidad con sistemas externos de entidades administradores
viales para envío del mensaje de interés nacional cuya ejecución depende de la
implementación en la Plataforma de Gestión Remota del administrador vial del
servicio web diseñado, así como del esquema de interoperabilidad con equipos VMS
propuesto y su posterior despliegue en un ambiente de calidad o pruebas apropiado.
 Verificar la implementación del esquema de interoperabilidad basado en servicios
Web propuesto por el Ministerio de Transporte, lo cual depende de la
implementación e implantación en un equipo VMS por parte del administrador vial
del esquema y su correspondientes proveedor, así mismo se requiere la
implementación de la plataforma de Gestión Remota en su CCO, y que esta cumpla
con los requisitos suministrados.

18.3.3. EXCLUSIONES DE LAS PRUEBAS

Se describe un panorama de alto nivel de las pruebas potenciales que pudieran haber sido
realizadas pero se han excluido explícitamente.

a. Pruebas Unitarias e Integrales

Estas pruebas deben ser ejecutadas por el equipo implementador de los componentes de
software, hardware u otras herramientas de soporte.

b. Pruebas de arquitectura e Inspección de código

Este tipo de pruebas deben ser ejecutadas por el arquitecto o líder técnico del equipo
implementador de los componentes de software, hardware u otras herramientas de soporte.

c. Pruebas de configuración, instalación, recuperación y tolerancia a fallos

Estas pruebas deben ser ejecutadas por el equipo TI al interior del Ministerio de Transporte
designado a la administración del sistema.

d. Pruebas de Migración
La puesta en marcha del sistema no incluye un proceso inicial de carga de datos ni de
migración desde otros sistemas.

e. Pruebas sobre componentes Externos al Ministerio de Transporte

Todos los componentes descritos y requeridos en la especificación del sistema que sean
construidos en el extremo de interoperabilidad externo y opuesto al Ministerio de Transporte
deberán ser verificados por el equipo implementador de los componentes de software,

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

137
hardware y otras herramientas de soporte dispuesto por las entidades administradoras
viales.

18.4. NECESIDADES DEL ENTORNO

Se describen los recursos no humanos que son requeridos para llevar a cabo el proceso de
verificación.

18.4.1. REQUISITOS DE HARDWARE

Para cada integrante del equipo de verificación se requiere disponer de un equipo de
cómputo de escritorio de alto procesamiento y espacio en disco disponible, el cual tenga
acceso a:

 Servidor de Aplicaciones de la Plataforma SiGVMS.

 Servidor de Base de Datos subyacente a la Plataforma SiGVMS.

18.4.2. REQUISITOS DE SOFTWARE

En los equipos de cómputo de escritorio dispuestos para el equipo de verificación se
requiere instalar el siguiente software:

 Navegadores de Internet del mercado más usados y soportados por las plataformas.

18.4.3. REQUISITOS DE CONFIGURACIÓN

El equipo de verificación deberá contar con todos los parámetros de configuración
necesarios para:

 Autenticarse sobre la base de datos de la plataforma SiGVMS.

 Acceder con privilegios de consulta sobre los distintos objetos que ellas contienen.
 Acceder a la parametrización de usuarios y roles de la plataforma.

18.4.4. HERRAMIENTAS DE PRODUCTIVIDAD Y SOPORTE

En los equipos de cómputo de escritorio dispuestos para el equipo de verificación se
requiere instalar el siguiente software, el cual no hace parte del funcionamiento del sistema
pero apoya el proceso de verificación:

 Herramienta de gestión de incidencias identificadas en la verificación.

 Herramientas de automatización de pruebas funcionales.
 Herramientas de automatización de capa de presentación.
 Herramientas de automatización de pruebas de rendimiento, carga y estrés.
 Herramienta de Ofimática.
 Herramientas de gestión de conexión y manipulación de datos en la base de datos.

18.4.5. ENTREGABLES
Se listan los diferentes artefactos que deberán ser creados por el esfuerzo de verificación y
que son entregables útiles para los diferentes interesados. No se listan todos los productos
de trabajo; solamente aquellos que dan un beneficio directo y tangible a los interesados y
aquellos mediante los cuales se quiere medir el éxito de la verificación. Constituyen
formatos documentales que reúnen la evidencia de los procedimientos y sus resultados.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

138
 Matriz de Requerimientos y su respectiva trazabilidad de verificación para cada
requerimiento.
 Especificaciones de casos de usos.
 Reglas de negocio claras en cada caso de uso.
 Casos y set de pruebas funcionales y técnicos planeados.
 Casos y set de pruebas diligenciados con sus respectivas evidencias durante las
pruebas integrales, las cuáles debieron ser realizadas en un ambiente de calidad.
 Datos de prueba incluidos en los set de pruebas. Estos datos tienen formato libre y
dependerán de lo requerido por el set de pruebas.

18.5. DESCRIPCIÓN DE LAS PRUEBAS

Este apartado provee una descripción de las pruebas funcionales que deben ser llevadas a
cabo. Para cada una de ellas deberán ser elaborados los casos de pruebas y cada
escenario posible con el detalle de: Configuración del sistema requerida, Datos de prueba,
Datos de entrada, Datos de salida esperados, Mensajes de alerta esperados, procedimiento
de prueba, así mismo deberán ser detallados los requisitos no funcionales a verificar y que
están asociados a cada caso de prueba.

18.5.1. Verificar el registro de datos en SiGMapas

La prueba debe verificar la interfaz que permite invocar y ejecutar el servicio web de
SiGMapas que registra o modifica los datos de un equipo VMS en su base de datos
geográfica.

18.5.2. Verificar el registra de datos de Equipos VMS

La prueba debe verificar el registro o modificación mediante servicio web de los datos de un
equipo VMS gestionado por un administrador vial.

18.5.3. Verificar la consulta de Equipos VMS

La prueba debe verificar el despliegue geográfico de los equipos VMS registrados por los
administradores viales.

18.5.4. Verificar la gestión de Pictogramas

La prueba debe verificar la gestión de los pictogramas en la base de datos y a partir de la
importación de archivos de imagen.

18.5.5. Verificar la gestión de Tipos de Mensajes

La prueba debe verificar la definición de taxonomías de mensajes en la base de datos.

18.5.6. Verificar la gestión de Mensajes

La prueba debe verificar la creación, modificación y eliminación de un mensaje en la base
de datos, la gestión del mensaje debe permitir:

 Soportar todas las características definidas en la especificación de interoperabilidad con

Equipos VMS.
 Incluir campos dinámicos.
 Cumplir con las características del formato estándar configurado.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

139
18.5.7. Verificar el envío de petición a Equipo VMS en CCO
La prueba debe verificar que es invocado un servicio web de difusión de un mensaje de
interés nacional con los parámetros correspondiente de un mensaje de interés nacional.

18.5.8. Verificar la activación de un Mensaje de Interés Nacional en Equipos VMS

La prueba debe verificar el envío de un mensaje de interés nacional a un equipo VMS
mediante la interfaz web correspondiente.

18.5.9. Verificar la consulta de la Configuración Estándar para Equipo VMS

La prueba debe verificar la consulta mediante servicio web de los parámetros de
configuración estándar del mensaje de interés nacional.

18.5.10. Verificar la gestión de Tipos de Fuentes

La prueba debe verificar la creación, modificación y eliminación de un tipo de fuentes
habilitada para la configuración de mensajes.

18.5.11. Verificar la gestión de Parámetros del Sistema

La prueba debe verificar la creación, modificación y eliminación de los parámetros de
configuración del sistema.

19. MODELO DE DOMINIO

Este apartado técnico define y describe el modelo de dominio que soporta el esquema de
interoperabilidad de gestión de equipos VMS con los actores del sistema. Su objetivo
principal es mantener la homogeneidad y permitir la fácil integración y comunicación de los
equipos VMS con las plataformas de gestión remota y local de dichos equipos; a través de
la definición de un esquema de intercambio de datos basado en el modelo de dominio.
El modelo de dominio definido incluye el modelo de entidad/ relación descrito con la
notación del lenguaje unificado para modelos (UML) de conformidad con las
especificaciones definidas en la ISO/IEC 19501. El modelo de dominio esta soportado por
un diccionario de datos que describe los atributos del modelo de dominio.

Este apartado está estructurado de la siguiente manera: en la Sección 19.2 se presenta la

especificación del modelo, a nivel de información dinámica, estática y genérica. En la
Sección 19.3 se presenta el diccionario de datos, que complementa el modelo de dominio y
en la Sección 19.5 se incluye la lista de mensajes propuesto para la transmisión desde los
equipos VMS.

19.1. ALCANCE DEL MODELO DE DOMINIO

El modelo de dominio describe un formato estandarizado para el intercambio de información
y publicación de mensajes en los equipos VMS, a partir de este se puede generar el
esquema de definición XML (XSD), que define los atributos o datos que deben ser
intercambiados. Este modelo también se puede considerar como una guía recomendada
para la implementación del esquema de interoperabilidad, pero es importante hacer énfasis
en que el cumplimiento del esquema de definición XML es de carácter obligatorio, con el
objetivo de asegurar la interoperabilidad.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

140
19.2. ESPECIFICACIÓN MODELO DE DOMINIO
Esta Sección, propone el diagrama de clases que representa los conceptos propios del
esquema de interoperabilidad de gestión de equipos VMS con las entidades claves, este
ofrece a los diseñadores el fundamento para la construcción, en fase de diseño posterior, de
los modelos de entidad relación y de base de datos, así como una herramienta que permita
un mejor entendimiento del alcance del esquema de interoperabilidad y los datos que por él
se transportan. El modelo de dominio propuesto está basado en la norma técnica Europea
CEN/TS 16157-4, que soporta las especificaciones técnicas de DATEX II para el
intercambio de información de tráfico para las señales de mensajería variable.

A continuación se puede encontrar la descripción del modelo de domino desde la

perspectiva de la información dinámica, estática y genérica que será intercambiada por los
equipos VMS; así mismo cada perspectiva incluirá los paquetes de clases cuya
funcionalidad es agrupar las entidades del modelo.

19.2.1.1. Modelo Información Dinámica

Esta Sección incluye los paquetes y clases que especifican los datos cuya frecuencia de
intercambio es alta. Principalmente, hace referencia al envió y despliegue de mensajes en
los paneles VMS, así como la configuración de dichos mensajes (texto o pictogramas).

a. Paquete “PublicacionVms”
El paquete "PublicacionVms" estará inmediatamente subordinado al paquete
"PublicacionGenerico" y comprenderá el sub modelo para la definición de publicaciones que
identifiquen el contenido visual y textual desplegado en VMS individuales y el estado de la
configuración de esos VMS, en donde cada VMS es controlado por un equipo VMS
asociado.

class PublicacionVms

Publicacion
PublicacionVms

1..*

EquipoVms::EquipoVms

+ referenciaEquipoVms: VersionedReference
+ referenciaTablaEquipoVms: VersionedReference

Figura X. Clases Paquete PublicacionVms

Fuente: Elaboración Propia

 Clase PublicacionVms

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

141
La clase PublicacionVms será la clase base para contener la información dinámica sobre
VMS.

b. Paquete “EquipoVms”
El paquete "EquipoVms" comprenderá un sub modelo para definir la información acerca de
la configuración, el estado, y las características de los equipos VMS y sus componentes
VMS los cuales son desplegados en la red vial.

Cada Equipo VMS controla uno o más VMS, donde un VMS puede desplegar un mensaje o
una secuencia de mensajes, cada uno comprendido por una combinación de información de
tipo: textos, símbolos o pictogramas. Cada VMS puede desplegar sólo un mensaje a la vez,
en donde cada mensaje individual comprenderá ninguno o varios componente de textos y
ninguno o varios componentes pictogramas.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

142
class EquipoVms

Falla
EquipoVms
Falla::FallaEquipoVms
+ referenciaEquipoVms: VersionedReference
+ fallaEquipoVms: FallaVmsEnum 0..* 1 + indiceVms = 1..n
referenciaTablaEquipoVms: VersionedReference
cada VMS asociado a un equipo VMS es referenciados por su
indiceVms indiceVms.
1
Falla El indiceVms tambien provee una referencia a las caracteristicas
especificas del Vms (definidas en la PublicacionTablaVms) que
Falla::FallaVms
son pertinentes para el VMS el cual es controlado por el Equipo
+ fallaVms: FallaVmsEnum VMS referenciado

0..*

1 1..*
GrupoUbicaciones
Vms CapacidadesDespliegueDinamicasVms
GrupoUbicaciones::Ubicacion +ubicacionVmsReemplaza
+ vmsTrabajando: Boolean + numeroAreasDespliegue: NonNegativeInteger [0..1]
0..1 1 - intervaloSecuenciaMensaje: Seconds [0..1] 1 0..1

indiceMensaje indiceAreaDespliegue indiceAreaDespliegue

1 1 1
indiceMensaje = 1..n
indiceAreaDespliegue = 1..n
El indiceMensaje provee el ordenamiento de una
secuencia de mensajes desplegables. El VMS despliega Cada area de despliegue sobre un VMS es
cada mensaje acorde al orden indicado por el referenciada por su "indiceAreaDespliegue" y los
indiceMensaje. La secuencia de mensajes desplegados detalles de su posición relativa o absoluta puede ser
es continuamente ciclica. provista en CapacidadesDespliegueVms.
1

CapacidadVms::CapacidadesDespliegueVms

+ identificadorListaCodigos: String [0..1]

1 1 + maxNumeroElementosSecuenciales: NonNegativeInteger [0..1]
+ maxNivelLuminancia: NonNegativeInteger [0..1]
Mensaj eVms::Mensaj eVms ConfiguracionAreaDespliegueVms + alturaDespligue: MetersAsFloat [0..1]
+ codigoRazonParaConfiguracion: CodigoRazonParaConfiguracionMensajeEnum [0..1] + AnchuraDespliegue: MetersAsFloat [0..1]
+ tieneLinternaEncendida: Boolean [0..1]
+ numeroColores: NonNegativeInteger [0..1]
+ distanciaASituacionRegistrada: MetersAsFloat [0..1] + nivelSensorLuz: NonNegativeInteger [0..1]
+ condiguradoPor: String [0..1] + pixelesVerticales: NonNegativeInteger [0..1]
+ algoritmoSalidaLuz: String [0..1]
+ pixelesHorizontales: NonNegativeInteger [0..1]
+ esConfiguracionPrimaria: Boolean [0..1] + nivelLuminancia: NivelLuminanciaVmsEnum [0..1]
+ razonParaConfiguracion: String [0..1] + tieneCapacidadSecuencial: Boolean [0..1]
+ tieneLuminanciaAutomaticaAnulado: Boolean [0..1]
+ solicitadoPor: String [0..1] + tieneLinternas: Boolean [0..1]
+ esConfiguradoPorSistema: Boolean [0..1] + posicionAbsoluta: PosicionAbsolutaEnum [0..1]
+ intervaloSecuenciaPagina: Seconds [0..1] + posicionX: MetersAsFloat [0..1]
+ tiempoUltimaConfiguracion: DateTime + posicionY: MetersAsFloat [0..1]
+ tipoInformacionMensaje: TipoInformacionMensajeVmsEnum [0..*]

Figura X. Clases Paquete EquipoVms

Anexo Técnico de la Resolución XXXXX de XXXX, De acuerdo al artículo 2.5.3.2. Subsistemas del Sinitt del Título 3 del Decreto 1079 de 2015

143
 Fuente: Elaboración Propia

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

144
 Clase CapacidadesDespliegueDinamicasVms
Una instancia de la clase CapacidadesDespliegueDinamicasVms permite a un proveedor
asociar características dinámicas con un VMS.

 Clase ConfiguracionAreaDespliegueVms
Una instancia de la clase ConfiguracionAreaDespliegueVms permite al proveedor identificar
los ajustes actuales aplicables a un área de visualización.
Estos son ajustes tales como el nivel de luminancia y si las linternas están encendidas.

 Clase EquipoVms
Representa un Equipo VMS, este permitirá a un proveedor de información definir qué
leyenda textual y pictogramas se muestran, sus características dinámicas / configuración y
cualquier estado de fallo actual del VMS.
Un VMS puede ser configurado para mostrar una secuencia de mensajes en un orden
definido donde cada mensaje comprende una combinación de páginas de texto y
pictogramas. En este caso, se utilizará el calificador indiceMensaje para distinguir los
mensajes individuales y su orden de visualización.

 Clase Vms
Representa un único panel VMS y permite suministrar información acerca del texto y
pictograma que es desplegado, además de sus características dinámicas y de configuración
y cualquier estado de falla del panel VMS.

c. Paquete “MensajeVms”
El paquete "MensajeVms" comprenderá un sub modelo para definir información acerca de
los mensajes individuales desplegados en un VMS. Los mensajes individuales desplegados
en un momento dado pueden estar modelados como una composición de ninguno o varios
componentes de texto y ninguno o varios componentes de pictogramas, en donde cada
componente es desplegado en un área de despliegue sobre un VMS.
Cada componente de Texto se comprenderá de una o más páginas de textos, y múltiples
páginas de texto pueden ser secuenciadas. Cada componente pictograma puede
comprender uno o más pictogramas secuenciados. Múltiples páginas de texto y pictogramas
serán secuenciadas en un orden específico y a unos intervalos específicos, todo controlado
o contenido dentro de una página.

Anexo Técnico de la Resolución XXXXX de XXXX, De acuerdo al artículo 2.5.3.2. Subsistemas del Sinitt del
Título 3 del Decreto 1079 de 2015

145
class Mensaj eVms

Mensaj eVms

+ codigoRazonParaConfiguracion: CodigoRazonParaConfiguracionMensajeEnum [0..1]

+ distanciaASituacionRegistrada: MetersAsFloat [0..1]
+ condiguradoPor: String [0..1]
+ esConfiguracionPrimaria: Boolean [0..1]
+ razonParaConfiguracion: String [0..1]
+ solicitadoPor: String [0..1]
+ esConfiguradoPorSistema: Boolean [0..1]
+ intervaloSecuenciaPagina: Seconds [0..1]
+ tiempoUltimaConfiguracion: DateTime
+ tipoInformacionMensaje: TipoInformacionMensajeVmsEnum [0..*]

1..*

PaginaVms

indiceAreaDespliegue indiceAreaDespliegue

1
1
1
1
AreaDespliegueTextoVms
AreaDesplieguePictogramaVms

indiceAreaDespliegue = 1..n

Cada area de despliegue sobre un VMS es 1

1 referenciada por su "indiceAreaDespliegue" y los
detalles de su posición relativa o absoluta pueden
ser provistos en CapacidadesDespliegueVms. 1
1
TextoVms
PictogramaVms + codigo: String

+ descripcionAdicional: String [0..1]

+ codigo: String [0..1]
indiceLinea
+ descripcion: String [0..1] 1
indiceLinea = 1..n
+ tieneColorInvertido: Boolean [0..1] 1
+ url: String [0..1]
Cuando son definidas multiples lineas de texto AparienciaVms::EstiloTextoVms
+ tieneTrianguloRojo: String 1
cada una es referenciada por su calificador
"indiceLinea" y a su orden respectivo 1 + colorPrimerPlano: String [0..1]
1 + colorFondo: String [0..1]
LineaTextoVms + esIntermitente: Boolean [0..1]
+ intervaloIntermitencia: Seconds [0..1]
1
1 1 + justificacionVertical: JustificacionVerticalEnum [0..1]
+ justificacionHorizontal: JustificacionHorizontalEnum [0..1]
AparienciaVms::EstiloPictogramaVms
+ codigoFuente: String [0..1]
indiceContenido
+ esIntermitente: Boolean [0..1] + altoFuente: MetersAsFloat [0..1]
+ intervaloIntermitencia: Seconds [0..1] indiceContenido = 1..n 1 + espaciado: MetersAsFloat [0..1]
+ posicionX: MetersAsFloat [0..1]
Cuando son definidos multiples contenidos de 1
+ posicionY: MetersAsFloat [0..1]
+ posicionAbsoluta: PosicionAbsolutaEnum [0..1] texto en una linea cada uno es referenciado por
su calificador "indiceContenido" y a su orden 1..*
respectivo
ContenidoLineaTextoVms 1

CaracterTextoVms
CadenaTextoVms
+ caracter: Character [0..1]
+ cadena: String [0..1]

Figura 17. Clases Paquete MensajeVms

Fuente: Elaboración Propia

 Clase AreaDesplieguePictogramaVms
Una instancia de la clase AreaDesplieguePictogramaVms permitirá a un proveedor asociar
un pictograma o secuencia de pictogramas que se muestran con un área de visualización
de pictogramas específica en el VMS.

 Clase areaDespliegueTextoVms
Una instancia de la clase AreaDespliegueTextoVms permitirá a un proveedor asociar un
texto o secuencia de textos que se muestran con un área de visualización de texto
específica en el VMS.

 Clase CadenaTextoVms
Una instancia de la clase CadenaTextoVms permitirá a un proveedor identificar una cadena
de caracteres específica, mostrada en una línea específica en el área de visualización de
texto.

 Clase CaracterTextoVms

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

146
Una instancia de la clase CaracterTextoVms permitirá a un proveedor identificar qué un
carácter específico mostrado en una línea específica en el área de visualización de texto.

 Clase ContenidoLineaTextoVms
Una instancia de la clase ContenidoLineaTextoVms permitirá a un proveedor identificar qué
tipo de contenido se muestra en una sola línea en el área de visualización de texto.
También permite especificar el color de la línea de texto y Si está destellando o tiene
cualquier formato especial aplicado a él. Los tipos de contenido pueden ser una cadena de
caracteres o un carácter específico.

 Clase LineaTextoVms
Una instancia de la clase LineaTextoVms permitirá a un proveedor identificar qué texto se
muestra en una sola línea en el área de visualización de texto. También permite especificar
el color de la línea de texto y Si está destellando o tiene cualquier formato especial aplicado
a él.

 Clase MensajeVms
Una instancia de la clase MensajeVms a la que hace referencia su calificador indiceMensaje
permitirá que un proveedor de información identifique los detalles del mensaje que se
muestra actualmente en el área de visualización de texto del VMS, las diversas áreas de
visualización del pictograma.

 Clase PaginaVms
Una instancia de la clase PaginaVms permitirá a un proveedor identificar el contenido de
una página del mensaje, de tipo texto o pictogramas.

 Clase PictogramaVms
Una instancia de la clase PictogramaVms permite a un proveedor identificar el pictograma
que se muestra actualmente o que está en una secuencia de pictogramas que se muestran
actualmente en el área de visualización de pictogramas especificada en el VMS.

 Clase TextoVms
Una instancia de la clase TextoVms permitirá a un proveedor de información identificar qué
texto se muestra en el área de visualización de texto y cómo se ve en el VMS.

d. Paquete “AparienciaVms”
El paquete "AprienciaVms" comprenderá un sub modelo para definir información acerca del
formato que debe ser aplicado al Pictograma o Texto en referencia al contenido del Mensaje
y sus características.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

147
class AparienciaVms

EstiloTextoVms EstiloPictogramaVms

+ colorPrimerPlano: String [0..1] + esIntermitente: Boolean [0..1]

+ colorFondo: String [0..1] + intervaloIntermitencia: Seconds [0..1]
+ esIntermitente: Boolean [0..1] + posicionX: MetersAsFloat [0..1]
+ intervaloIntermitencia: Seconds [0..1] + posicionY: MetersAsFloat [0..1]
+ justificacionVertical: JustificacionVerticalEnum [0..1] + posicionAbsoluta: PosicionAbsolutaEnum [0..1]
+ justificacionHorizontal: JustificacionHorizontalEnum [0..1]
+ codigoFuente: String [0..1]
+ altoFuente: MetersAsFloat [0..1]
+ espaciado: MetersAsFloat [0..1]

Figura 6. Clases Paquete AparienciaVms

Fuente: Elaboración Propia

 Clase EstiloPictogramaVms
Una instancia de la clase EstiloPictogramaVms permitirá que un proveedor identifique las
características visuales del pictograma que se usan actualmente en el VMS que, si se
proporcionan, anularán las definidas en el registro referenciado de
CapacidadesDesplieguePictogramaVms.

 Clase EstiloTextoVms
Una instancia de la clase EstiloTextoVms permitirá que un proveedor identifique las
características visuales del texto que se usan actualmente en el VMS que, si se
proporcionan, anularán las definidas en el registro referenciado de
CapacidadesDespliegueTextoVms.

e. Paquete “CapacidadVms”
El paquete "CapacidadVms" comprenderá un sub modelo para definir información acerca de
las características y capacidades de los equipos VMS y sus componentes VMS los cuales
son desplegados en la red vial.
class CapacidadVms

CapacidadesDespliegueVms

+ identificadorListaCodigos: String [0..1]

+ maxNumeroElementosSecuenciales: NonNegativeInteger [0..1]
+ maxNivelLuminancia: NonNegativeInteger [0..1]
+ alturaDespligue: MetersAsFloat [0..1]
+ AnchuraDespliegue: MetersAsFloat [0..1]
+ numeroColores: NonNegativeInteger [0..1]
+ pixelesVerticales: NonNegativeInteger [0..1]
+ pixelesHorizontales: NonNegativeInteger [0..1]
+ tieneCapacidadSecuencial: Boolean [0..1]
+ tieneLinternas: Boolean [0..1]
+ posicionAbsoluta: PosicionAbsolutaEnum [0..1]
+ posicionX: MetersAsFloat [0..1]
+ posicionY: MetersAsFloat [0..1]

CapacidadesDesplieguePictogramaVms
CapacidadesDespliegueTextoVms
+ numeroColores: NonNegativeInteger [0..1]
+ maxAlturaFuente: NonNegativeInteger [0..1]
+ maxEspaciadoFuente: NonNegativeInteger [0..1]
+ maxAnchuraFuente: NonNegativeInteger [0..1]
+ maxNumeroCaracteres: NonNegativeInteger [0..1]
+ maxNumeroFilas: NonNegativeInteger [0..1]
+ minAlturaFuente: NonNegativeInteger [0..1]
+ minEspaciadoFuente: NonNegativeInteger [0..1]
+ minAnchuraFuente: NonNegativeInteger [0..1]

Figura 7. Clases Paquete CapacidadVms

Fuente: Elaboración Propia

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

148
 Clase CapacidadesDesplieguePictogramaVms
Una instancia de la clase CapacidadesDesplieguePictogramaVms permitirá a un proveedor
identificar las características de visualización de pictogramas que se utilizan actualmente en
el VMS dentro de un área de visualización particular que, si se proporciona, anulará las
definidas en el registro referenciado del RegistroEquipoVms.
Las características del área de visualización del pictograma incluyen las dimensiones del
área (en píxeles y métricas), detalles del posicionamiento del área en el panel VMS y el
nivel máximo de luminancia.

 Clase CapacidadesDespliegueTextoVms
Una instancia de la clase CapacidadesDespliegueTextoVms permitirá que un proveedor
identifique las características del área de visualización de texto que se usan actualmente en
el VMS que, si se proporcionan, anularán las definidas en el registro referenciado del
RegistroEquipoVms.
Las características del área de visualización de texto incluyen opcionalmente dimensiones
de área (en píxeles y métricas), tamaños de fuente, número de caracteres y filas, detalles
del posicionamiento del área de texto en el panel VMS y el nivel máximo de luminancia.

 Clase CapacidadesDespliegueVms
Define una clase abstracta CapacidadesDespliegueVms que permitirá que un proveedor
identifique las características del área de visualización común a texto y pictogramas que se
usan actualmente en el VMS que, si se proporcionan, anularán las definidas en el registro
referenciado del RegistroEquipoVms.
Las características del área de visualización de texto incluyen opcionalmente dimensiones
de área (en píxeles y métricas), tamaños de fuente, número de caracteres y filas, detalles
del posicionamiento del área de texto en el panel VMS y el nivel máximo de luminancia.

19.2.1.2. Modelo Información Estática

Esta sección describe los paquetes y clases que hacen referencia a los datos cuya
frecuencia de intercambio es bajo, principalmente incluye el registro de los paneles VMS.

a. Paquete “PublicacionTablaVms”
El paquete "PublicacionTablaVms" estará inmediatamente subordinado al paquete
"PublicacionGenerico" y comprenderá el sub modelo para la definición de tablas de equipos
VMS publicables, las cuales comprenden registros que normalmente contienen información
estática relacionada a los equipos VMS desplegados y los VMS que controlan. Cada
publicación puede contener una o más tablas, permitiendo el particionamiento lógico de
información estática de los VMS y según juicio del proveedor acorde a lo más apropiado
para quienes reciben la información de los VMS.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

149
class PublicacionTablaVms

Publicacion
PublicacionTablaVms

1..*

TablaEquipoVms

+ Identificacion: String [0..1]

1..* indiceAreaDespliegue = 1..n

RegistroEquipoVms Cada area de despliegue sobre un VMS es referenciada por su

GrupoUbicaciones::
+ubicacionVms "indiceAreaDespliegue" y los detalles de su posición relativa o
GrupoUbicaciones + numeroDeVms: NonNegativeInteger [0..1] absoluta pueden ser provistos en CapacidadesDespliegueVms.
0..1 1 + direccionElectronica: String [0..1]
+ identificador: String [0..1]
+ direccionIP: String [0..1]
indiceVms

1
indiceVms = 1..n

El indiceVms proporciona los medios para que la información

(en PublicacionVms) sea referenciada a las caracteristicas del 1
VMS pertinente en el Equipo VMS. CapacidadVms::CapacidadesDespliegueVms

RegistroVms + identificadorListaCodigos: String [0..1]

+ maxNumeroElementosSecuenciales: NonNegativeInteger [0..1]
+ tieneConfiguracionDinamicaAreasDespliegue: Boolean [0..1]
+ maxNivelLuminancia: NonNegativeInteger [0..1]
+ numeroAreaDespliegue: NonNegativeInteger [0..1]
+ alturaDespligue: MetersAsFloat [0..1]
+ descripcion: String [0..1]
+ AnchuraDespliegue: MetersAsFloat [0..1]
+ alturaDespliegue: MetersAsFloat [0..1]
indiceAreaDespliegue + numeroColores: NonNegativeInteger [0..1]
+ anchuraDespliegue: MetersAsFloat [0..1] 1 1 + pixelesVerticales: NonNegativeInteger [0..1]
+ alturaSobreVia: MetersAsFloat [0..1]
+ pixelesHorizontales: NonNegativeInteger [0..1]
+ propietario: String [0..1]
+ tieneCapacidadSecuencial: Boolean [0..1]
+ montajeFisico: MontajeFisicoVmsEnum [0..1]
+ tieneLinternas: Boolean [0..1]
+ tipoVms: TipoVmsEnum [0..1]
+ posicionAbsoluta: PosicionAbsolutaEnum [0..1]
+ codigoTipoVms: String [0..1]
+ posicionX: MetersAsFloat [0..1]
+ posicionY: MetersAsFloat [0..1]

Figura 19. Clases Paquete PublicacionTablaVms

Fuente: Elaboración Propia

 Clase PublicacionTablaVms
La clase PublicacionTablaVms será la clase base para contener las tablas de unidades
VMS publicadas

 Clase RegistroEquipoVms
Una instancia versionada identificable de la clase RegistroEquipoVms deberá contener la
información de características relativa a una unidad VMS específica. Cada registro tendrá
uno o más sub-registros RegistroVms indexados para contener las características de los
VMS individuales que son controlados por la unidad VMS.

 Clase RegistroVms
Una instancia de la clase RegistroVms permitirá a un proveedor identificar las
características estáticas de un VMS. La ubicación del VMS se puede especificar a través de
la agregación GrupoUbicaciones.

 Clase TablaEquipoVms
Una instancia versionada identificable de la clase TablaEquipoVms debe contener cualquier
colección lógica de RegistroEquipoVms. Un proveedor puede optar por proporcionar un
identificador textual para un particular TablaEquipoVms para aclarar la colección lógica de
RegistroEquipoVms.

19.2.1.3. Modelo Información Genérica

Esta sección describe los paquetes y clases que hacen referencia a los datos transversales
a todo el modelo de domino y que pueden ser usados para el intercambio de información

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

150
dinámico o estático, principalmente incluye la información sobre fallas y la ubicación de los
paneles VMS; así mismo incluye los tipos de datos y las enumeraciones del modelo de
dominio.

a. Paquete “General”
El paquete “General” contiene los paquetes principales y genéricos a todo el modelo de
dominio. Incluyendo, tipos de datos, enumeraciones y las clases reutilizables

Figura X. Clases Paquete General

Fuente: Elaboración Propia

b. Paquete “PayloadEnumerations”
El paquete “PayloadEnumerations” contiene todas las enumeraciones que pueden ser
usadas en el modelo de dominio.

class PayloadEnumerations

«enumeration» «enumeration» «enumeration» «enumeration»

PosicionAbsolutaEnum Sev eridadEnum FallaVmsEnum Montaj eFisicoVmsEnum
aLaIzquierda masAlta fallaComunicaciones montadoEnReserva
aLaDerecha alta mensajeIncorrectoDesplegado montadoPortico
enElTope media pictogramaIncorrectoDesplegado montadoCabezalPuente
enElFondo baja fueraDeServicio montadoCantileverVia
masBaja fallaEnergia montadoVia
ninguna fallaLimpiezaMensaje montadoRemolque
desconocida desconocido montadoEntradaTunel
otro montadoVehiculo

«enumeration»
CodigoRazonParaConfiguracionMensaj eEnum «enumeration»
Niv elLuminanciaVmsEnum
campania
gestionTrafico apagado
creadoPorOperador pruebas
situacion nocturno «enumeration»
tiempoViaje nublado TipoInformacionMensaj eVmsEnum
defecto luzDiaAmplia mensajeCampania
solEnOjos
fechaHora
solEnEspalda
informacionFutura
diaNublado instruccionesOMensajes
nocheNublada
situacionAdvertencia
«enumeration» «enumeration»
temperatura
JustificacionVerticalEnum JustificacionHorizontalEnum
gestionTrafico
arriba izquierda «enumeration» tiempoViaje
medio centro TipoVmsEnum
abajo derecho
completa graficoColor
senialContinua
graficoMonocromatico
senialMatriz
otra

Figura 14. Clases Paquete PayloadEnumerations

Fuente: Elaboración Propia

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

151
 c. Paquete “DataTypes”
El paquete “DataTypes” contiene los paquetes de los tipos de datos específicos y genéricos
que son aplicables a todo el modelo de dominio.

Figura X. Clases Paquete DataTypes

Fuente: Elaboración Propia

d. Paquete “GrupoUbicaciones”
El paquete “GrupoUbicaciones” comprendera un submodelo para definir la información que
permite describir la ubicación de los dispositivos VMS, a través de un sistema de
coordenadas y puntos; o un sistema de referenciación externa.

class GrupoUbicaciones

GrupoUbicaciones

Ubicacion ReferenciacionExterna

+ codigoUbicacionExterna: String
1 0..* + sistemaReferenciacionExterna: String

0..1

CoordenadasPunto

+ longitud: Float
+ latitud: Float

Figura 13. Clases Paquete GrupoUbicaciones

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

152
 Fuente: Elaboración Propia

 Clase CoordenadasPunto
Esta clase permite representar la ubicación de un elemento del sistema a través de la
definición de una instancia “CoordenadasPunto”; específicamente de una latitud y una
longitud.

 Clase ReferenciaExterna
La clase “ReferenciaExterna” permite representar la ubicación de un elemento del sistema a
través de un sistema de referencia externo y código de ubicación externa.

e. Paquete “Falla”
El paquete "Falla" fue introducido para gestionar clases reusables que provean información
relacionada las fallas generadas en equipos y dispositivos. Las clases relacionadas a los
VMS son FallaEquipoVms y FallaVms.

class Falla

Falla

+ tiempoCreacion: DateTime [0..1]

+ descripcion: String [0..1]
+ identificador: String [0..1]
+ tiempoUltimaActualiza: DateTime
+ severidadEnum: SeveridadEnum [0..1]

FallaEquipoVms FallaVms

+ fallaEquipoVms: FallaVmsEnum + fallaVms: FallaVmsEnum

Figura 16. Clases Paquete Falla

Fuente: Elaboración Propia

 Clase Falla
La Clase Falla es usada para suministrar información acerca de una falla relacionada a una
pieza o equipo específico de un proceso. Provee información acerca del momento de inicio
de la falla, su identificación, una descripción y su severidad.

 FallaEquipoVms
La clase FallaEquipoVms es usada para suministrar información sobre fallas relacionadas a
un EquipoVMS.

 Clase FallaVms
La clase FallaVms es usada para suministrar información de fallas relacionadas a un panel
VMS

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

153
19.3. DICCIONARIO DE DATOS
El diccionario de datos identifica las definiciones y características de las diferentes clases,
atributos, tipos de datos y enumeraciones que aparecen en el modelo de domino. El
diccionario de datos está especificado en tres partes: descripción del modelo de dominio,
tipos de datos y enumeraciones.

19.3.1. Descripción del Modelo de dominio

En esta Sección serán descritos los atributos que abarcan el modelo de dominio, la
descripción se realizara a través de una tabla que incluye las siguientes columnas:

a. Nombre de la clase: Nombre identificador de un elemento del modelo, que se deriva de

una abstracción de la realidad.
b. Nombre del atributo: Nombre identificador que describe una característica particular de
una clase.
c. Definición: Descripción de un atributo.
d. Multiplicidad: Característica que permite o no la multiplicidad de un atributo en una
clase.
e. Tipo de dato: Proporciona un tipo de dato definido relacionado con el atributo.

19.3.1.1. Modelo Información dinámica

A continuación se presenta la especificación descripción de los atributos relacionados a las
clases y paquetes del dominio de información dinámica.

a. Paquete “EquipoVms”
A continuación se describen los atributos de las clases que pertenecen al paquete
EquipoVms.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

154
Clase Atributo Definición Multiplicidad Tipo de dato

CapacidadesDespliegueDinamicasVms numeroAreasDespliegue Número de zonas de visualización de pictogramas / textos que [0..1] NonNegativeInteger
contiene el VMS

ConfiguracionAreaDespliegueVms tieneLinternaEncendida Indica si las linternas están activadas o desactivadas para el área de [0..1] Boolean
visualización

nivelSensorLuz Indica el número de niveles de detección de luz ambiente soportados [0..1] NonNegativeInteger
por los sensores de luz

algoritmoSalidaLuz Indica y/o configurar el algoritmo que establece las relaciones entre [0..1] String
la detección de luz ambiente – lectura de entrada sensor de luz – y el
nivel de brillo de la señal – luz de salida –

nivelLuminancia Nivel de luminancia, expresado como un entero, que se establece [0..1] NivelLuminanciaVmsEnum
para el área de visualización del VMS. Esto puede ser ajustado
automáticamente por el VMS o por el operador.

tieneLuminanciaAutomaticaAnulado Indica si el nivel de luminancia automático del VMS para el área de [0..1] Boolean
visualización está siendo sobre escrito (es decir, por un nivel
establecido por el operador u operador).

EquipoVms referenciaEquipoVms Una referencia a un registro de unidad VMS versionado en una tabla [0..1] VersionedReference
de unidad VMS que define las características de la unidad VMS.

referenciaTablaEquipoVms Una referencia a una tabla de unidades VMS versionada. [0..1] VersionedReference

Anexo Técnico de la Resolución XXXXX de XXXX, De acuerdo al artículo 2.5.3.2. Subsistemas del Sinitt del Título 3 del Decreto 1079 de 2015

155
Vms vmsTrabajando Indica si el VMS es utilizable. Tener en cuenta que todavía puede ser [0..1] Boolean
utilizable con fallas menores.

intervaloSecuenciaMensaje La duración de tiempo que cada mensaje se muestra antes de que el [0..1] Seconds
VMS muestre el siguiente mensaje en la secuencia.

Tabla 4. Atributos Paquete EquipoVms

b. Paquete “AparienciaVms”
A continuación se describen los atributos de las clases que pertenecen al paquete AparienciaVms

Clase Atributo Definición Multiplicidad Tipo de dato

EstiloPictogramaVms esIntermitente Indica si el pictograma desplegado está parpadeando [0..1] Boolean

intervaloIntermitencia Tiempo en segundos de la duración de la intermitencia del [0..1] Seconds

pictograma

posicionX La posición de la coordenada X (horizontal) del área en la que se [0..1] MetersAsFloat

muestra el pictograma, medida desde la parte inferior izquierda de la
señal.

posicionY La posición de la coordenada Y (vertical) del área en la que se [0..1] MetersAsFloat

muestra el pictograma, medida desde la parte inferior izquierda de la
señal.

posicionAbsoluta La posición del área en la que se muestra el pictograma, es decir, a [0..1] PosicionAbsolutaEnum
la izquierda, derecha, arriba o abajo de la pantalla VMS.

EstiloTextoVms colorPrimerPlano color del primer plano del texto desplegado [0..1] String

colorFondo color del fondo del texto desplegado [0..1] String

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

156
 esIntermitente Indica si el texto desplegado está parpadeando [0..1] Boolean

intervaloIntermitencia Tiempo en segundos de la duración de la intermitencia del texto [0..1] Seconds

justificacionVertical Justificación vertical del texto [0..1] JustificacionVerticalEnum

justificacionHorizontal Justificación horizontal del texto [0..1] JustificacionHorizontalEnum

codigoFuente Código de la fuente aplicada al texto [0..1] String

altoFuente Alto de la fuente del texto [0..1] MetersAsFloat

espaciado Espaciado entre los caracteres del texto [0..1] MetersAsFloat

TablaX. Atributos Paquete Apariencia Vms

c. Paquete “CapacidadVms”

A continuación se describen los atributos de las clases que pertenecen al paquete CapacidadVms

Clase Atributo Definición Multiplicidad Tipo de dato

CapacidadesDesplieguePictogramaV numeroColores El número de colores que el área de visualización del pictograma es [0..1]: NonNegativeInteger
ms capaz de representar

CapacidadesDespliegueTextoVms maxAlturaFuente Altura máxima de la fuente en píxeles [0..1] NonNegativeInteger

maxEspaciadoFuente Espaciado máximo de la fuente en píxeles [0..1] NonNegativeInteger

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

157
 maxAnchuraFuente Ancho máximo de la fuente en píxeles [0..1] NonNegativeInteger

maxNumeroCaracteres Número máximo de caracteres desplegados en una sola línea en el [0..1] NonNegativeInteger
área de visualización textual del VMS.

maxNumeroFilas Número máximo de filas de caracteres desplegables en el área de [0..1] NonNegativeInteger

visualización textual del VMS

minAlturaFuente Altura mínima de fuente en píxeles [0..1] NonNegativeInteger

minEspaciadoFuente Espaciado mínimo de fuente en píxeles. [0..1] NonNegativeInteger

minAnchuraFuente Ancho mínimo de la fuente en píxeles [0..1] NonNegativeInteger

CapacidadesDespliegueVms identificadorListaCodigos Indica qué lista de códigos de elementos se hace referencia [0..1] String

maxNumeroElementosSecuenciales El número máximo de pictogramas / texto que pueden secuenciarse [0..1] NonNegativeInteger
en el área de visualización

maxNivelLuminancia Nivel máximo de luminancia entero disponible en el área de [0..1] NonNegativeInteger

visualización del elemento del VMS.

alturaDespligue La altura vertical medida en metros del área específica de [0..1] MetersAsFloat
visualización del elemento.

AnchuraDespliegue El ancho horizontal medido en metros del área de visualización del [0..1] MetersAsFloat
elemento específico.

numeroColores El número de colores que el área de visualización del elemento es [0..1] NonNegativeInteger
capaz de representar

pixelesVerticales Número de píxeles verticalmente en el área de visualización del [0..1] NonNegativeInteger

VMS

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

158
 pixelesHorizontales Número de píxeles horizontalmente a través del área de [0..1] NonNegativeInteger
visualización del VMS

tieneCapacidadSecuencial Indica si el área de visualización del elemento en el VMS es capaz [0..1] Boolean
de secuenciar a través de múltiples elementos

tieneLinternas Indica si el VMS está equipado con linternas parpadeantes [0..1] Boolean
asociadas con el área de visualización del elemento.

posicionAbsoluta La posición del área en la que se muestra el elemento, es decir, a la [0..1] PosicionAbsolutaEnum
izquierda, derecha, arriba o abajo de la pantalla VMS

posicionX La posición de coordenada X (horizontal) del área en la que se [0..1] MetersAsFloat

muestra el elemento medida desde la parte inferior izquierda del
área de visualización general del signo a la parte inferior izquierda
del área de visualización del elemento específico

posicionY La posición coordenada Y (vertical) del área en la que se muestra el [0..1] MetersAsFloat
elemento medida desde la parte inferior izquierda del área de
visualización general del signo a la parte inferior izquierda del área
de visualización del elemento específico

TablaX. Atributos Paquete CapacidadVms

d. Paquete “MensajeVms”

A continuación se describen los atributos de las clases que pertenecen al paquete MensajeVms.

Clase Atributo Definición Multiplicidad Tipo de dato

CadenaTextoVms cadena Cadena de caracteres especifica desplegada [0..1] String

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

159
CaracterTextoVms caracter Carácter específico desplegado [0..1] Character

MensajeVms codigoRazonParaConfiguracion La razón, en términos de una clasificación codificada de alto nivel, [0..1] CodigoRazonParaConfigura
por qué se ha establecido el mensaje cionMensajeEnum

distanciaASituacionRegistrada Distancia del VMS desde la ubicación del registro / elemento de [0..1] MetersAsFloat
situación relacionado. Si el VMS se encuentra dentro de la extensión
del registro / elemento de situación, éste debe ser puesto a cero

configuradoPor La organización o la autoridad que establecen el mensaje que se [0..1] String

muestra actualmente.

esConfiguracionPrimaria Identifica si la configuración del mensaje es primaria (solicitada [0..1] Boolean

explícitamente) o secundaria (derivada según un algoritmo como
resultado de establecer otros signos)

razonParaConfiguracion La razón por la que se ha establecido el mensaje. [0..1] String

solicitadoPor La autoridad, organización o sistema que solicitó la configuración del [0..1] String
mensaje. Esto puede ser diferente de la autoridad o sistema que
realmente estableció el mensaje en nombre del solicitante.

esConfiguradoPorSistema Indica si el sistema ha configurado automáticamente el mensaje. [0..1] Boolean

intervaloSecuenciaPagina La duración en la que se visualiza cada página de texto o [0..1] Seconds

pictograma dentro de un mensaje antes de que el VMS muestre la
siguiente página de texto y / o pictograma en el mensaje

tiempoUltimaConfiguracion La fecha / hora en que se estableció el último mensaje. [0..1] DateTime

tipoInformacionMensaje Tipo de Información desplegada en el mensaje [0..*] TipoInformacionMensajeVm

sEnum

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

160
 PictogramaVms descripcionAdicional Descripción adicional del pictograma. [0..1] String

codigo El código del pictograma de la lista de códigos de pictogramas se [0..1] String

hace referencia en las capacidades de
CapacidadesDesplieguePictogramaVms para el VMS que se
identifica en la tabla correspondiente de la unidad VMS.

descripcion Descripción del pictograma (principal) [0..1] String

tieneColorInvertido El pictograma se muestra en color inverso (es decir, los colores son [0..1] Boolean
la inversa de lo normal)

url Referencia a una URL desde donde se puede obtener una imagen [0..1] String
del pictograma visualizado

tieneTrianguloRojo Indicación de la presencia de un triángulo rojo alrededor del [0..1] String

pictograma, a menudo utilizado para indicar la inminencia,
típicamente dentro de 2 km, de peligro firmado.

TextoVms codigo El código de la leyenda / texto de la lista de códigos de leyenda que [0..1] String
se hace referencia en las capacidades de
CapacidadesDespliegueTextoVms

TablaX. Atributos Paquete MensajeVms

19.3.1.2. Modelo Información estática

A continuación se presenta la especificación descripción de los atributos relacionados a las clases y paquetes del dominio de
información estática.

a. Paquete “PublicacionTablaVms”

A continuación se describen los atributos de las clases que pertenecen al paquete PublicacionTablaVms.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

161
Clase Atributo Definición Multiplicidad Tipo de dato

RegistroEquipoVms numeroDeVms Número de señales de mensaje variable controlados por la unidad [0..1] NonNegativeInteger

direccionElectronica Dirección electrónica de la unidad VMS (si no es direccionable por [0..1] String
IP)

identificador Identificación de una unidad VMS utilizada por el proveedor o [0..1] String
sistemas de consumo.

direccionIP Dirección de red IP de la unidad VMS [0..1] String

RegistroVms tieneConfiguracionDinamicaAreasDe Identifica (cuando es cierto) que el VMS tiene un área de [0..1] Boolean
spliegue visualización que puede configurarse dinámicamente para mostrar
diferentes combinaciones de texto y áreas de pictogramas. La
configuración actual se dará normalmente con cada configuración de
VMS actual publicada.

numeroAreaDespliegue Número de zonas de visualización que contiene el VMS [0..1] NonNegativeInteger

descripcion La descripción del VMS (posiblemente dando una descripción de su [0..1] String
ubicación o su uso normal).

alturaDespliegue Altura en metros del área de visualización general de la señal [0..1] MetersAsFloat

anchuraDespliegue Ancho en metros del área de visualización general del letrero. [0..1] MetersAsFloat

alturaSobreVia Altura en metros del letrero montado sobre la calzada, medida en la [0..1] MetersAsFloat
parte inferior del área de visualización

propietario Propietario (autoridad u organización) del VMS. Esto no [0..1] String

necesariamente puede ser el mismo que la autoridad u organización
que actualmente está controlando el VMS.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

162
 montajeFisico Descripción de cómo el VMS está físicamente montado o [0..1] MontajeFisicoVmsEnum
desplegado en la carretera

tipoVms Clasificación amplia del tipo de la señal de mensaje variable. [0..1] TipoVmsEnum

codigoTipoVms Especificación del tipo de VMS definido por un código, normalmente [0..1] String
país o incluso específico del fabricante (por ejemplo, MS4).

TablaEquipoVms Identificacion Una identificación alfanumérica para la tabla de unidades VMS, [0..1] String
posiblemente legible por humanos.

TablaX. Atributos Paquete PublicacionTablaVms

19.3.1.3. Modelo Información genérica

A continuación se presenta la especificación descripción de los atributos relacionados a las clases y paquetes de la información
transversal a todo el modelo de dominio.

a. Paquete “GrupoUbicacionesVms”

A continuación se describen los atributos de las clases que pertenecen al paquete GrupoUbicacionesVms

Clase Atributo Definición Multiplicidad Tipo de dato

CoordenadasPunto longitud Longitud en grados decimales [0..1] Float

latitud Latitud en grados decimales [0..1] Float

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

163
ReferenciaExterna codigoUbicacionExterna Un código en el sistema de referencia externa que define la [0..1] String
ubicación.

sistemaReferenciacionExterna Identificación del sistema de referencia de ubicación externo / otro. [0..1] String

TablaX. Atributos Paquete GrupoUbicacionesVms

b. Paquete “Falla”
A continuación se describen los atributos de las clases que pertenecen al paquete Falla

Clase Atributo Definición Multiplicidad Tipo de dato

Falla tiempoCreacion La fecha y hora en que el fallo fue originalmente registrado / [0..1] DateTime
reportado.

descripcion Descripción textual de la falla [0..1] String

identificador Identificador [0..1] String

tiempoUltimaActualiza La fecha y hora en que se actualizó por última vez la información de [0..1] DateTime
fallo especificada en esta instancia.

severidadEnum La gravedad de la falla en términos de cómo afecta la usabilidad del [0..1] SeveridadEnum
equipo o la fiabilidad de los datos generados por el equipo.

FallaEquipoVms fallaEquipoVms El tipo de fallo que se informa para la unidad VMS. [0..1] FallaVmsEnum

FallaVms fallaVms El tipo de fallo que se informa para el panel de signo de mensaje [0..1] FallaVmsEnum
variable especificado.

TablaX. Atributos Paquete Falla

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

164
19.4. TIPOS DE DATOS PARA EL MODELO DE DOMINIO
Esta Sección contiene las definiciones de todos los tipos de datos usados en el modelo de
dominio

 Boolean
El tipo de dato Booleano, tiene el espacio de valor requerido para soportar el concepto
matemático de lógica binaria: {verdadero, falso}.

 Character
Almacena información de texto simple que no puede ser usada en cálculos matemáticos.
Contiene un único elemento carácter.

 Date
Una combinación de propiedades de valor entero de un año, mes y día más una propiedad
opcional de zona horaria. Representa un intervalo de exactamente un día, comenzando en
el primer momento del día en la zona horaria, es decir, '00: 00: 00' hasta pero no incluyendo
'24: 00: 00'.

 DateTime
Una combinación de propiedades de año entero, mes, día, hora, minuto, una segunda
propiedad de valor decimal y una propiedad de zona horaria desde la cual es posible
determinar la hora local, la hora UTC equivalente y la zona horaria desplazada de UTC.

 Float
Número de coma flotante cuyo espacio de valor consiste en los valores m × 2 ^ e, donde m
es un entero cuyo valor absoluto es menor que 2 ^ 24, y e es un número entero entre -149 y
104, inclusive.

 Integer
Un número entero cuyo valor es el conjunto {-2147483648, -2147483647, -2147483646, ..., -
2, -1, 0, 1, 2, ..., 2147483645, 2147483646, 2147483647}.

 Language
Tipo de dato Lenguaje, que hace referencia a un lenguaje especificado por un código ISO
639-1.

 NonNegativeInteger
Un número entero cuyo espacio de valor es el conjunto {0, 1, 2, ..., 2147483645,
2147483646, 2147483647}.

 Reference
Una referencia a un objeto gestionado identificable en el que el identificador es único.
Comprende un identificador (por ejemplo, GUID) y una cadena que identifica la clase del
objeto referenciado
ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX
“por la cual se reglamenta el título 4 de la parte 5 del libro 2 del decreto 1079 de 2015 referente a módulo de
mensaje de señales variable”

165
 String
Una cadena de caracteres cuyo espacio de valores es el conjunto de secuencias de
caracteres de longitud finita. Cada carácter tiene un punto de código de conjunto de
caracteres universal correspondiente (como se define en ISO / IEC 10646), que es un
número entero.

 Time
Un instante de tiempo que se repite cada día. El espacio de valor de tiempo es el espacio
de valores de tiempo de día como se define en el § 5.3 de [ISO 8601]. Específicamente, es
un conjunto de instancias de tiempo diarias de duración cero.

 Url
Una dirección Uniform Resource Locator (URL) que comprende una cadena compacta de
caracteres para un recurso disponible en Internet.

 VersionedReference
Una referencia a un objeto gestionado de versión identificable en el que la combinación del
identificador y la versión es única. Comprende un identificador (por ejemplo, GUID), una
versión (NonNegativeInteger) y una cadena que identifica la clase del objeto referenciado.

 Seconds
Tipo de dato que permite la definición del tiempo en segundos.

 MetersAsFloat
Una medida de distancia definida en metros en un formato de coma flotante.

19.4.1. ENUMERACIONES PARA EL MODELO DE DOMINIO

En esta Sección serán descritos los atributos que abarcan las enumeraciones del modelo de
dominio, la descripción se realizara a través de una tabla que incluye las siguientes
columnas:

 Valor Enumeración: Valor especifico que puede tomar la enumeración.

 Definición: Descripción de un valor especifico de la enumeración.

a. CodigoRazonParaConfiguracionMensajeEnum

Valor Enumeración Definición

campania El VMS está actualmente seleccionado para desplegar un mensaje de campaña

gestionTrafico El VMS está actualmente seleccionado para desplegar un mensaje seleccionado como
parte de la implementación de una acción de gestión de tráfico.

creadoPorOperador Mensaje seleccionado por el operador como el resultado de un evento o situación no

gestionada.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

166
 situacion Mensaje seleccionado como el resultado de una situación que ocurre por dentro o al
costado de la vía y que puede afectar a los usuarios de la vía.

tiempoViaje El VMS está actualmente seleccionado para desplegar tiempos de viaje.

defecto El VMS está actualmente seleccionado para desplegar información defecto, por ejemplo la
hora y fecha, o temperatura.

TablaX. Valor enumeración CodigoRazonParaConfiguracionMensajeEnum

b. FallaVmsEnum

Valor Enumeración Definición

fallaComunicaciones Fallas de Comunicaciones que afectan al VMS

mensajeIncorrectoDesplegado Un mensaje incorrecto está siendo desplegado

pictogramaIncorrectoDesplegado Un pictograma incorrecto está siendo desplegado

fueraDeServicio Actualmente fuera de servicio (por ejemplo: intencionalmente desconectado o apagado

durante trabajos en la vía)

fallaEnergia La energía del VMS ha fallado

fallaLimpiezaMensaje Imposible limpiar el mensaje desplegado en el VMS

desconocido Falla desconocido en el VMS

otro Cualquier otro no definido en esta enumeración

TablaX. Valor enumeración FallaVmsEnum

c. JustificacionHorizontalEnum

Valor Enumeración Definición

izquierda Alineación en la parte izquierda del espacio asignado

centro Alineación en la parte central del espacio asignado

derecho Alineación en la parte derecha del espacio asignado

completa Alineación de los lados derecho e izquierdo del espacio asignado

TablaX. Valor enumeración JustificacionHorizontalEnum

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

167
d. JustificacionVerticalEnum

Valor Enumeración Definición

arriba En la parte superior del espacio asignado.

medio En la parte media del espacio asignado

abajo En la parte inferior del espacio asignado

TablaX. Valor enumeración JustificacionVerticalEnum

e. MontajeVmsFisicoEnum

Valor Enumeración Definición

montadoEnReserva Equipo montado en la reserva central.

montadoPortico Equipo montado en un pórtico de arriba a través de la carretera.

montadoCabezalPuente Equipo montado sobre la cabeza en una estructura de puente.

montadoCantileverVia Equipo montado en un voladizo desde la carretera

montadoVia Equipo montado en la carretera

montadoRemolque Equipo montado en un remolque móvil.

montadoEntradaTunel Equipo montado en la entrada de un túnel.

montadoVehiculo Equipo montado en un vehículo.

TablaX. Valor enumeración MontajeVmsFisicoEnum

f. NivelLuminanciaVmsEnum

Valor Enumeración Definición

apagado El nivel de luminancia es cero cuando la fuente de luz está apagada.

pruebas La luminancia se ajusta al nivel de prueba.

nocturno La luminancia se ajusta en el nivel definido para la noche

nublado La luminancia se establece en el nivel definido para las condiciones de tiempo de día nublado o
gris

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

168
 luzDiaAmplia La luminancia se ajusta en el nivel definido para las condiciones normales de luz de día amplio

solEnOjos La luminancia se establece en el nivel definido para las condiciones en las que los conductores
tendrán sol en sus ojos.

solEnEspalda La luminancia se establece en el nivel definido para las condiciones donde los conductores
tendrán sol detrás de ellos

diaNublado La luminancia se establece en el nivel definido para las condiciones de día de niebla

nocheNublada La luminancia se establece en el nivel definido para las condiciones nocturnas de niebla

TablaX. Valor enumeración NivelIluminanciaEnum

g. PosicionAbsolutaEnum

Valor Enumeración Definición

aLaIzquierda A la izquierda del espacio asignado.

aLaDerecha A la derecha del espacio asignado.

enElTope En la parte superior del espacio asignado

enElFondo En la parte inferior del espacio asignado.

TablaX. Valor enumeración PosicionAbsolutaEnum

h. SeveridadEnum

Valor Enumeración Definición

masAlta Percibido por el proveedor como el de mayor nivel.

alta Percibido por el proveedor como de alto nivel.

media Percibido por el proveedor como de medio nivel.

baja Percibido por el proveedor como de bajo nivel.

masBaja Percibido por el proveedor como siendo del nivel discernible más bajo.

ninguna Percibido por el proveedor como teniendo una clasificación de gravedad de ninguno.

desconocida Percibido por el proveedor como de un nivel desconocido.

TablaX. Valor enumeración SeveridadEnum

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

169
 i. TipoInformacionMensajeVmsEnum

Valor Enumeración Definición

mensajeCampania Información de tipo de campaña que no es específica en el tiempo y que puede requerir ciertas
acciones (por ejemplo, "no beba ni conduzca") o que tenga la intención de influir en el
comportamiento de los conductores

fechaHora Información de fecha y / o hora actual

informacionFutura Información que puede informar a los usuarios sobre situaciones futuras que potencialmente
pueden causar congestión o influir en futuros planes de viaje (por ejemplo, obras viales futuras,
cierres, eventos deportivos, conciertos públicos, suspensión de servicios de tren o ferry).

instruccionesOMensajes Instrucciones o mensajes a los usuarios de la carretera que sean relevantes en la hora actual
(por ejemplo, "no arrojar objetos quemados" o un mensaje de alerta Ámbar).

situacionAdvertencia Información de advertencia de una situación actual que puede afectar el tráfico en la carretera.

temperatura Información de temperatura

gestionTrafico Información que contiene instrucciones de gestión de tráfico

tiempoViaje Información sobre el tiempo de viaje

TablaX. Valor enumeración TipoInformacionMensajeVmsEnum

j. TipoVmsEnum

Valor Enumeración Definición

graficoColor Una pantalla grafica en color

senialContinua Una señal que implementa mensajes fijos que son seleccionados por medios electromecánicos

graficoMonocromatico Una pantalla de gráfica monocromática

senialMatriz Pantalla simple compuesta por un una matriz de píxeles fija (por ejemplo juego de ledes o luces)
capaz de desplegar un juego de aspectos limitados o matriz de imágenes

otra Cualquier otra no definida en esta enumeración

TablaX. Valor enumeración TipoVmsEnum

19.5. GUÍA DE MENSAJES PARA VMS

En esta Sección, se presenta una guía para la definición y transmisión de mensajes
en los paneles VMS. Esto incluye una lista de textos y una lista de pictogramas a
incluir.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

170
19.5.1. Lista Textos para inclusión en Mensajes
Se toma como referencia la recomendación adoptada por el Manual de Señalización en
Calles y Carreteras de 2015. Sección 2,7,10 y 2.7.11.

TIPO MENSAJE SUB TIPO CODIGO TEXTO

INFORMATIVO CONGESTIÓN 2.7.10.1.1.A TIEMPO DE VIAJE

2.7.10.1.1.B DEMORA X MINS

2.7.10.1.1.C CONGESTIÓN

INCIDENTES 2.7.10.1.2.A INCIDENTE

2.7.10.1.2.B PEATONES

2.7.10.1.2.C GRAVILLA SUELTA

2.7.10.1.2.D VEHÍCULO SENTIDO CONTRARIO

2.7.10.1.2.E VISIBILIDAD REDUCIDA

2.7.10.1.2.F PAVIMENTO RESBALADIZO

2.7.10.1.2.G NIEBLA

2.7.10.1.2.H NEBLINA

2.7.10.1.2.I ANIMALES SUELTOS

2.7.10.1.2.J INUNDACIÓN

2.7.10.1.2.K VEHÍCULO DETENIDO

2.7.10.1.2.L VEHÍCULO LENTO

2.7.10.1.2.M DERRUMBE

2.7.10.1.2.N VIENTO LATERAL

ACCIDENTES 2.7.10.1.3.A ACCIDENTE

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

171
TRABAJOS EN LA VÍA 2.7.10.1.4.A TRABAJOS EN LA VÍA

2.7.10.1.4.B DESVÍO

2.7.10.1.4.C FIN OBRAS

2.7.10.1.4.D BANDERERO

2.7.10.1.4.E TRABAJOS MÓVILES

2.7.10.1.4.F VEHÍCULO LENTO

2.7.10.1.4.G ANGOSTAMIENTO

2.7.10.1.4.H ENSANCHAMIENTO

COMPLEMENTOS DE 2.7.10.1.5.A A LA DERECHA

INFORMATIVOS

2.7.10.1.5.B A LA IZQUIERDA

2.7.10.1.5.C CARRIL DERECHO

2.7.10.1.5.D CARRIL IZQUIERDO

2.7.10.1.5.E CARRIL CENTRAL

2.7.10.1.5.F PRÓXIMA SALIDA

2.7.10.1.5.G PUENTE

2.7.10.1.5.H TUNEL

2.7.10.1.5.I ESTACIONAMIENTO

2.7.10.1.5.J AxM

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

172
 2.7.10.1.5.K A x KM

2.7.10.1.5.L TRÁNSITO SUSPENDIDO

2.7.10.1.5.M DETENCIÓN OBLIGADA

INSTRUCTIVOS 2.7.10.2.A PREFIERA RUTAS ALTERNATIVAS

2.7.10.2.B ABANDONE VÍA

2.7.10.2.C MANTENGA CARRIL

2.7.10.2.D USE CARRIL IZQUIERDO

2.7.10.2.E USE CARRIL IZQUIERDO Y CENTRAL

2.7.10.2.F USE CARRIL IZQUIERDO Y DERECHO

2.7.10.2.G USE CARRIL DERECHO

2.7.10.2.H USE CARRIL DERECHO Y CENTRAL

DE PRUEBA 2.7.10.3.A SEÑAL EN PRUEBA

2.7.10.3.B MENSAJE DE PRUEBA

ABREVIATURAS ALTERNATIVA 2.7.11.A ALT

AVENIDA 2.7.11.B AV

DERECHO 2.7.11.C DER

HORAS 2.7.11.D HRS

CALLE 2.7.11.E CL

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

173
 CARRERA 2.7.11.F CR

DIAGONAL 2.7.11.G DG

IZQUIERDO 2.7.11.H IZQ

KILOMETROS POR HORA 2.7.11.I KM/H

KILOMETROS 2.7.11.J KM

MAXIMA 2.7.11.K MÁX

METROS 2.7.11.L m

MINIMO O MINIMA 2.7.11.M MIN

PROVINCIA 2.7.11.N PROV

PUENTE 2.7.11.O PTE

SENTIDO 2.7.11.P STDO

TELEFONO 2.7.11.Q TEL

CELULAR 2.7.11.R CEL

TRANSITO 2.7.11.S TTO

TRANSVERSAL 2.7.11.T TR

VEHICULOS 2.7.11.U VEH

VELOCIDAD 2.7.11.V VEL

Tabla X Lista de Textos recomendados para incluir en mensajes

Fuente: Elaboración propia

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

174
19.5.2. Lista de pictogramas para inclusión en Mensajes
Las referencias asociadas a los pictogramas, en función del tipo de mensaje que se
requiere transmitir, deben consultarse en los numerales 2,2; 2,3; 2,4; 2,5; 2,6; 2,7; y 4, 6 del
Manual de Señalización Vial Vigente (Resolución 1885 de 2015) o el documento que haga
sus veces.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

175
20. BIBLIOGRAFÍA

 Informe 2 - Línea Base de Información Módulo de Señales de Mensaje Variable.

Septiembre 2016. Db-System LTDA
 Decreto Nacional 2060 de 2015. Numeral 1 Artículo 2513.
 Washington State Department of Transportation. Assessing the benefits of traveler
and transportation information systems. 2005.
http://www.wsdot.wa.gov/research/reports/fullreports/597.1.pdf
 IEEE Computer Society. 2007. https://standards.ieee.org/findstds/standard/1362-
1998.html
 ArcGis Resources. 2016. http://resources.arcgis.com/es/help/getting-
started/articles/026n0000000s000000.htm
 http://estrategia.gobiernoenlinea.gov.co/623/w3-propertyvalue-7650.html
 Grupo Educare. 2011
https://computacioncpc.files.wordpress.com/2011/06/teorc3ada-hardware-y-
software.pdf
 Decreto Nacional 2060 de 2015, Numeral 5 Artículo 2513
 OpenGeoSpatial. 2016. http://www.opengeospatial.org/standards/kml
 http://www.w3c.es/Divulgacion/GuiasBreves/TecnologiasXML
 http://ntc5854.accesibilidadweb.co/index.php/beneficios/niveles-de-conformidad
 Decreto 0087 de 2011. Artículo 7
 ISO. 2016. http://www.iso.org/iso/home/about.htm
 http://www.mastermagazine.info/termino/5288.php
 https://www.swgreenhouse.com/conceptos-de-continuidad-de-negocio/rto-rpo
 https://www.swgreenhouse.com/conceptos-de-continuidad-de-negocio/rto-rpo
 Wisconsin Department of Transportation. 2000.
http://www4.uwm.edu/cuts/itsdm/chap6.pdf
 http://searchsoa.techtarget.com/definition/SOAP
 Decreto Nacional 079 de 2015. Numeral 6 Artículo 2513
 Decreto Nacional 2060 de 2015, Numeral 7 Artículo 2513
 Grupo Educare. 2011.
 https://computacioncpc.files.wordpress.com/2011/06/teorc3ada-hardware-y-
software.pdf
 https://www.onelogin.com/saml
 http://blog.firma-e.com/que-es-un-sgsi-sistema-de-gestion-de-seguridad-de-la-
informacion/
 Tecnología al Instante. 2007.
http://tecnologiahechapalabra.com/tecnologia/glosario_tecnico/articulo.asp?i=875
 Comercio-exterior.es. 2016.
http://www.comercio-exterior.es/es/action-articulos.articulos+art-73+cat-
12/Articulos+de+comercio+exterior/Transporte+internacional/Las+ventajas+del+tran
sporte+intermodal.htm
 US Travel Association. 2016. http://www.trb.org/AboutTRB/AboutTRB.aspx
 TechTerms. 2016. http://techterms.com/definition/touchscreen
 http://searchsoa.techtarget.com/definition/UDDI
 Techopedia. 2016.
https://www.techopedia.com/definition/1033/remote-terminal-unit-rtu
 Pcmagazin. 2016. http://www.pcmag.com/encyclopedia/term/53509/ups
 "Systems Engineering for Intelligent Transportation Systems". Publicado por el US
Department of Transportation en 2007.
 OpenGeoSpatial. 2016.
http://docs.opengeospatial.org/is/09-025r2/09-025r2.html#1

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

176
 OpenGeoSpatial. 2016.
http://www.opengeospatial.org/standards/wms
 http://www.oasis-ws-i.org/about
 https://www.w3.org/TR/wsdl
 http://www.service-architecture.com/articles/web-
services/web_services_security_wss.html
 Concept de Operations, Systems Engineering or Intelligent Transportation Systems,
An Introduction for Transportation Professionals.
 Concept of Operations, ANSI / AIAA-G-043-1992 Guide to the Preparation of
Operational Concept Documents.
 NTCIP 1201:2005, Definición de objetos globales,
https://www.ntcip.org/library/documents/pdf/1201v0232f.pdf
 NTCIP 1203, Definición de objetos para señales de mensaje dinámico (DMS). 2011.
http://www.ntcip.org/library/documents/pdf/1203v03-04_part_1_dms2011.pdf
 UNE-EN 12966, Señalización vertical en carretera, Paneles de mensaje variable,
UNE-EN 12966 2015.pdf
 Catálogo de estándares del Comité Técnico 204 de la ISO, 2016.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc_browse.htm?commid
=54706
 Estándar Internacional ISO 15784 Intercambio de datos que involucran módulos de
comunicaciones ubicados en la vía, 12.5.1 Apartado 2 comunicación dispositivo en
campo a Centro de Control usando SNMP, ISO 15784-2 2015 first ed.pdf
 Especificación Técnica CEN 16157 DATEX II Especificaciones de intercambio de
datos para información y gestión de tráfico, Apartado 4 Publicación VMS,
Ratificación de documentos europeos Junio de 2014 CENTS 16157-4 2.pdf
 Norma NEMA 250-2014,
https://www.nema.org/Standards/ComplimentaryDocuments/NEMA%20250-2014-
contents-and-scope.pdf
 Especificación SOAP, https://www.w3.org/TR/soap/
 Especificación WSDL, https://www.w3.org/TR/wsdl
 Especificación UDDI, http://www.uddi.org/pubs/uddi_v3.htm
 Comité Técnico de OASIS para mantenimiento de WSS, https://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=wss-m
 Especificación WS-I Basic Profile,
http://ws-i.org/Profiles/BasicProfile-2.0-2010-11-09.html
 Especificación Web Services Policy, https://www.w3.org/Submission/WS-Policy/
 Norma Técnica Colombiana NTC-ISO/IEC 27001
 Decreto 2573 de 2014.
http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=60596
 Manual Estrategia Gobierno en línea.
http://programa.gobiernoenlinea.gov.co/apc-aa-
files/eb0df10529195223c011ca6762bfe39e/manual-3.1.pdf
 Decreto 2364 de 2012.
http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=50583
 Plan Nacional de Seguridad Vial adoptado mediante la Resolución 2273 de 2014 del
Ministerio de Transporte.

ANEXO TÉCNICO DE LA RESOLUCIÓN XXXXX DE XXXX

177