Ministerio de Transporte

RESOLUCIÓN 546 DE 2018

(Marzo 9)

“Por la cual se adecua la reglamentación del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV), se establecen normas de protección a los usuarios y se dictan otras disposiciones”.

El Ministro de Transporte,

en ejercicio de sus facultades constitucionales y legales, en especial las conferidas por los numerales 6.2, 6.3 y 6.10 del artículo 6º del Decreto 87 de 2011, el parágrafo del artículo 2.5.4.1 y el artículo 2.5.4.3 del título 4 de la parte 5 del libro 2 del Decreto 1079 de 2015, y

CONSIDERANDO:

Que de conformidad con el artículo 78 de la Constitución Política los usuarios y consumidores de los bienes y servicios son sujetos de derechos y de protección por parte de la ley, y las entidades del Estado deben propiciar y hacer respetar los mismos;

Que según lo establecido en el artículo 334 de la Constitución Política, el Estado intervendrá por mandato de la ley, entre otros, en los servicios públicos y privados, con el fin de conseguir el mejoramiento de la calidad de vida de los habitantes, la distribución equitativa de las oportunidades y los beneficios del desarrollo;

Que el artículo 365 de la Constitución Política establece que el Estado mantendrá la regulación, control y vigilancia de los servicios públicos, en procura de garantizar el mejoramiento continuo en la prestación de dichos servicios y la satisfacción del interés social;

Que la Ley 105 de 1993, señala que le corresponde al Estado la planeación, control, regulación y vigilancia del transporte y de las actividades a él vinculadas y en su artículo 2º establece que la seguridad de las personas constituye una prioridad del sistema y el transporte y un elemento básico para la unidad nacional y el desarrollo de todo el territorio colombiano.

Que el artículo 5º ibídem, establece que “Es atribución del Ministerio de Transporte en coordinación con las diferentes entidades sectoriales, la definición de las políticas generales sobre el transporte y el tránsito”;

Que el artículo 84 de la Ley 1450 de 2011, dispuso medidas para el desarrollo de los sistemas inteligentes de transporte, al respecto señala:

“ART. 84.—Sistemas inteligentes de tránsito y transporte (SIT). Los sistemas inteligentes de transporte son un conjunto de soluciones tecnológicas informáticas y de telecomunicaciones que recolectan, almacenan, procesan y distribuyen información, y se deben diseñar para mejorar la operación, la gestión y la seguridad del transporte y el tránsito.

El Gobierno Nacional, con base en estudios y previa consulta con los prestadores de servicio, adoptará los reglamentos técnicos y los estándares y protocolos de tecnología, establecerá el uso de la tecnología en los proyectos SIT y los sistemas de compensación entre operadores.

PAR. 1º—Las autoridades de tránsito y transporte en su respectiva jurisdicción, expedirán los actos administrativos correspondientes para garantizar el funcionamiento de los sistemas de gestión de tránsito y transporte de proyectos SIT, de acuerdo con el marco normativo establecido por el Gobierno Nacional. En aquellos casos en donde existan áreas metropolitanas debidamente constituidas, serán estas las encargadas de expedir dichos actos administrativos.

PAR. 2º—Los sistemas de gestión y control de flota, de recaudo y de semaforización entre otros, hacen parte de los proyectos SIT.

PAR. 3º—El montaje de los sistemas inteligentes de transporte, podrá implicar la concurrencia de más de un operador, lo que significará para el usuario la posibilidad de acceder a diferentes proveedores, en diferentes lugares y tiempo. El Gobierno Nacional, con base en estudios y previa consulta con los prestadores de servicio reglamentará la manera como esos operadores compartirán información, tecnologías o repartirán los recursos que provengan de la tarifa, cuando un mismo usuario utilice servicios de dos operadores diferentes”;

Que la Ley 1480 de 2011, establece los derechos y deberes de los consumidores de bienes y servicio, y en su artículo 2º establece:

“Las normas de esta ley regulan los derechos y las obligaciones surgidas entre los productores, proveedores y consumidores y la responsabilidad de los productores y proveedores tanto sustancial como procesalmente.

Las normas contenidas en esta ley son aplicables en general a las relaciones de consumo y a la responsabilidad de los productores y proveedores frente al consumidor en todos los sectores de la economía respecto de los cuales no exista regulación especial, evento en el cual aplicará la regulación especial y suplementariamente las normas establecidas en esta ley.

Esta ley es aplicable a los productos nacionales e importados”;

Que el Decreto 2846 de 2013, estableció la Norma ISO 18000-63 como el estándar a adoptar en Colombia para el sistema de recaudo electrónico vehicular (REV);

Que el Decreto 1079 de 2015 “por medio del cual se expide el Decreto Único Reglamentario del Sector Transporte”, establece:

“ART. 2.5.4.3.—Interoperabilidad del sistema de recaudo electrónico vehicular (IP/REV). El Ministerio de Transporte, con el objeto de garantizar la interoperabilidad del sistema, regulará las condiciones financieras, técnicas y jurídicas mínimas que debe cumplir una entidad para ejercer el rol de operador, intermediador o cualquier otra función definida por el Ministerio de Transporte en el sistema IP/REV”;

Que mediante la Resolución 4303 de 2015, adicionada por la Resolución 3779 de 2016 ambas expedidas por el Ministerio de Transporte, se reglamentaron los sistemas de recaudo electrónico vehicular y mediante la Resolución 5708 de 2016, se adoptó el “Documento normativo que define los requisitos y procedimientos para la habilitación y certificación de los actores estratégicos del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV) en Colombia”;

Que la citada Resolución 4303 de 2015 define al Colpass como “La marca de interoperabilidad Colpass, es una palabra compuesta por dos (2) sílabas. La primera sílaba COL que representa a Colombia, y la segunda palabra, el anglicismo PASS que representa la palabra PASE. Las sílabas unidas, Colpass, dan el significado de un pase que puede ser utilizado por los peajes en donde se encuentre dicha marca en Colombia. La utilización de la marca es el resultado de la certificación para la prestación del servicio de (IP/REV)”;

Que de conformidad con estimaciones de la Agencia Nacional de Infraestructura el tráfico promedio en las 120 casetas de peaje concesionadas en el territorio nacional, es de alrededor de 660 mil vehículos diarios, que se constituyen en usuarios del sistema vial nacional;

Que el sector transporte debe utilizar las tecnologías de la información y las comunicaciones, como una herramienta que contribuya a la prestación de un servicio competitivo, dinámico, y seguro;

Que el recaudo electrónico vehicular (REV) es un sistema inteligente para la infraestructura, el tránsito y el transporte, que permite a los usuarios pagar mediante una transacción electrónica servicios, mediante la utilización de tecnología de apoyo, instaladas en la infraestructura y en dispositivos a bordo del vehículo, el cual busca mejorar la seguridad y competitividad de las cadenas logísticas, abriendo oportunidades para promover soluciones eficientes e innovadoras, permitiendo el pago electrónico de peajes o de tasas por uso de áreas de alta congestión, de alta contaminación o de infraestructura construida o mejorada para evitar congestión urbana; así como el cobro de otros bienes y servicios relacionados con el uso de la infraestructura de transporte;

Que el Ministerio de Transporte realizó la evaluación del marco normativo del recaudo electrónico vehicular vigente con el fin de implementar ajustes para facilitar su aplicación y expansión de los servicios a lo largo del país y elaboró el documento “Evaluación del modelo de operación para la interoperabilidad de peajes electrónicos IP/REV y esquema propuesto en las resoluciones 4303 de 2015, 3779 de 2016 y 5708 de 2016”;

Que para la implementación de la interoperabilidad nacional de peajes el Ministerio de Transporte desarrolló una plataforma tecnológica o SiGT (sistema de gestión de transacciones), que almacenará la información de la operación de peajes a nivel nacional y servirá de medio para la certificación de los actores, entre otras relacionadas;

Que conforme a las directrices generales de técnica normativa establecidas en el Decreto 1081 de 2015, modificado por el Decreto 1609 de 2015 “Decreto Único Reglamentario del Sector de la Presidencia de la República”, artículo 2.1.2.1.1 Racionalización, regulación integral y seguridad jurídica, que establece que en la preparación de proyectos de resoluciones o cualquier otro acto administrativo de carácter general, se deberá realizar una regulación integral y evitar la dispersión y proliferación normativa, y cuando se vaya a reglamentar una materia o modificar la reglamentación vigente, se deberá verificar que se incluyan todos los aspectos necesarios, para evitar modificaciones o correcciones posteriores que se hubieren podido prever, por lo que, se estima necesario adecuar la reglamentación del sistema para la interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV), establecer los requisitos que deben cumplir los actores estratégicos interesados en obtener y mantener la certificación para la prestación del servicio de recaudo electrónico vehicular (REV), en condiciones de interoperabilidad entre los actores del sistema y adoptar i) Anexo técnico, ii) Anexo de indicadores financieros, iii) Anexo Colpass, iv) anexo de especificaciones técnicas, y v) Anexo oferta básica de interoperabilidad (OBP), consolidando las dos resoluciones existentes realizando una regulación integral que incorpore todas las modificaciones y adiciones que se han efectuado a la referida reglamentación y conforme a ello derogar las resoluciones de modificación o adición de reglamentación vigente contenidas en las resoluciones 4303 de 2015, 3779 de 2016 y la 5708 de 2016, todo con la finalidad de que se adopte un único servicio de recaudo electrónico vehicular (REV) en las carreteras del orden nacional;

Que en virtud de lo dispuesto en el artículo 39 del Decreto-Ley 19 de 2012, se solicitó al Departamento Administrativo de la Función Pública que rindiera concepto sobre el presente acto administrativo, quien mediante Oficio 20175010256591 del 23 de octubre de 2017, manifestó que: “dado que en el proceso de los trámites se establecen claramente los requisitos y condiciones que debe cumplir el usuario, se identifica que no se solicitan requisitos eliminados por las normas trámites, en especial el Decreto-Ley 19 de 2012, y que los trámites se encuentren ajustados a la política de racionalización de trámites, se autoriza la adopción e implementación de dichos trámites”;

Que de conformidad con lo dispuesto en el artículo 7º de la Ley 1340 de 2009, se solicitó a la Superintendencia de Industria y Comercio que rindiera concepto sobre el proyecto de acto administrativo mediante el cual se modifica la reglamentación de las condiciones de interoperabilidad de peajes con recaudo electrónico vehicular, entidad que mediante oficio 17-192645-3.0 del 17 de agosto de 2017 se pronunció sobre el proyecto en mención. Al respecto y en relación con las solicitudes de la Superintendencia de Industria y Comercio en la presente resolución se dispuso que la certificación que obtendrán los interesados se realizará teniendo en cuenta que es una declaración de primera parte que conlleva el lleno de unos requisitos de tipo documental, para el posterior pronunciamiento del Ministerio de Transporte, dejando abierta la posibilidad de verificaciones posteriores sobre las calidades acreditadas. Así mismo, se dispuso de forma textual la obligación de que los TAG RFID antes de ponerse a disposición del público deban cumplir con las normas de calidad y de protección a usuario y/o consumidor actualmente establecidas, y que su desconocimiento sea sujeto de las sanciones dispuestas en la normatividad;

Que de conformidad con lo dispuesto en el artículo 7º de la Ley 1340 de 2009, se solicitó a la Superintendencia de Industria y Comercio que rindiera concepto sobre el proyecto de acto administrativo mediante el cual se reglamentan las condiciones mínimas para garantizar la interoperabilidad de los sistemas de recaudo electrónico vehicular, entidad que mediante Oficio 17-376636-2-0 manifestó: “Al respecto, esta superintendencia no tiene observaciones respecto al proyecto. De cualquier forma es importante que el Ministerio de Transporte se remita al concepto de abogacía respecto del proyecto anterior para lo pertinente”;

Que el contenido de la presente resolución fue publicado en la página web del Ministerio de Transporte, en cumplimiento de lo determinado en el numeral 8º del artículo 8º de la Ley 1437 de 2011, Decreto 270 de 2017 y la Resolución 994 de 2017, con el objeto de recibir opiniones, sugerencias o propuestas alternativas, las cuales fueron debidamente evaluadas y/o acogidas en los casos pertinentes;

Que la oficina asesora de jurídica del Ministerio de Transporte conservará los documentos asociados al proceso de divulgación y participación ciudadana incluidos los cronogramas, actas, comentarios, grabaciones e informes que evidencien la publicidad del proyecto y la participación de los ciudadanos y grupos de interés, así como los estudios, las observaciones presentadas frente al presente acto administrativo y las respuestas dadas. Todo ello en concordancia con las políticas de gestión documental y de archivo de la entidad;

Que en mérito de lo expuesto,

RESUELVE:

TÍTULO I

Disposiciones generales

ART. 1º—Objeto. La presente resolución tiene por objeto adecuar la reglamentación del sistema para la interoperabilidad de peajes con recaudo electrónico vehicular (IP/ REV), establecer los lineamientos para la protección de los usuarios de los sistemas de interoperabilidad de recaudo electrónico vehicular (IP/REV), fijar los requisitos que deben cumplir los actores estratégicos para obtener y mantener la certificación para la prestación del servicio de recaudo electrónico vehicular (REV), en condiciones de interoperabilidad entre los actores del sistema y adoptar los anexos: i) Anexo técnico, ii) Anexo de indicadores financieros, iii) Anexo Colpass, iv) Anexo de especificaciones técnicas, y v) Anexo oferta básica de interoperabilidad (OBIP), los cuales hacen parte integral de la presente resolución.

ART. 2º—Principios. El sistema para la interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV), se desarrollará cumpliendo los principios rectores de los sistemas inteligentes para la infraestructura, el tránsito y el transporte (SIT) definidos en los artículos 2.5.1.1, y 2.5.1.4, del Decreto 1079 de 2015.

ART. 3º—Ámbito de aplicación. Las disposiciones establecidas en la presente resolución se aplicarán a la prestación del servicio de recaudo electrónico vehicular (REV), a los actores estratégicos y a los usuarios y/o consumidores del sistema, de conformidad con lo establecido en la presente resolución.

ART. 4º—Definiciones. Para la interpretación y aplicación de la presente resolución, se tendrán en cuenta además de las contempladas en el artículo 2.5.1.3 del título 1 de la parte 5 del libro 2 del Decreto 1079 de 2015, las siguientes definiciones:

1. Actor estratégico IP/REV: Se entenderán como actores estratégicos el intermediador y el operador del sistema de interoperabilidad con recaudo electrónico vehicular.

2. Anexo 1 técnico: Es el documento que contiene los requisitos que deben cumplir los actores estratégicos para ser certificados por el Ministerio de Transporte, para ejercer un rol en el sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV).

3. Anexo 2 financiero: Es el documento que contiene los requisitos financieros que deben cumplir los actores estratégicos para ser certificados por el Ministerio de Transporte, para ejercer un rol en el sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV) y usar la marca de certificación de interoperabilidad Colpass.

4. Anexo 3 Colpass. Anexo en el que se definen las condiciones para la utilización de la marca de interoperabilidad Colpass por parte de las personas que hagan uso de los servicios de (IP/REV).

5. Carril (o vía) del sistema de interoperabilidad de peajes con recaudo electrónico vehicular o carril IP/REV: Dentro de una estación de peaje o punto de cobro de peaje, es el carril o carriles que tienen la tecnología para realizar el cobro de la tarifa de peaje utilizando medios electrónicos, de conformidad con lo establecido en la presente resolución, o en las normas que las modifiquen, sustituyan o adicionen.

6. Centro de operación de peajes (COP): Lugar(es) físico(s) y/o virtual(es) desde donde se controla, configura, recoge, almacena y procesa la información de una o más estaciones de peaje, incluyendo uno o más carriles con interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV), bajo responsabilidad del operador.

7. Certificación del intermediador del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV): Acto mediante el cual el Ministerio de Transporte, otorga la certificación que aprueba las condiciones de interoperabilidad y permite el derecho de uso de la marca de interoperabilidad Colpass, al intermediador del sistema de interoperabilidad de peajes con recaudo electrónico vehicular.

8. Certificación del operador del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV): Acto mediante el cual el Ministerio de Transporte, otorga la certificación que aprueba las condiciones de interoperabilidad y permite el derecho de uso de la marca de interoperabilidad Colpass, al operador del sistema de interoperabilidad de peajes con recaudo electrónico vehicular.

9. Colpass: La marca de interoperabilidad Colpass, es una palabra compuesta por dos (2) sílabas. La primera sílaba COL que representa a Colombia, y la segunda palabra, el anglicismo PASS que representa la palabra PASE, que unidas forman la palabra Colpass y dan el significado de un pase que puede ser utilizado en los puntos de cobro de peaje en donde se encuentre dicha marca en Colombia.

10. Código EPC: El código electrónico de producto, es un número único diseñado para identificar de manera inequívoca cualquier objeto. Este código es un sistema de identificación y seguimiento de productos en tiempo real. El número se encuentra almacenado en el TAG que puede leerse mediante RFID.

11. Concesionario vial o concesionario: Contratista del Estado, con quien la entidad estatal nacional o territorial adjudicante ha suscrito un contrato de concesión o similar. El concesionario en los casos así previstos es responsable, ante la entidad adjudicante, de la operación del peaje y del recaudo de la tarifa de peaje por el uso de su infraestructura.

12. Cuenta del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV): Servicio ofrecido por los intermediadores asociado a una modalidad y medio de pago, bajo el cual se pueden administrar uno o más usuarios con uno o más vehículos asociados. En la cuenta de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV) se almacena y procesa la información de dicho/s usuario/s, su/s vehículo/s, y todas las transacciones realizadas, que, junto a la demás información asociada, como abonos, saldos, y descuentos entre otros, posibilita cobrar al usuario el valor de la tarifa de peaje por el uso de la infraestructura vial.

13. Intermediador del sistema de interoperabilidad de peajes con recaudo electrónico vehicular o INT IP/REV: Persona natural o jurídica que: i) vincula a los usuarios y/o consumidores, ii) gestiona la entrega, y activa el dispositivo TAG RFID, iii) se encarga de la administración de la información de las cuentas de los usuarios y/o consumidores asociadas a los dispositivos TAG RFID, y iv) gestiona el pago de la tarifa de peaje a los operadores por el uso de su infraestructura vial.

14. 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 (computadoras, medios de comunicación, redes, software y otros componentes de tecnologías de la información).

15. Interoperabilidad de peajes con el sistema de recaudo electrónico vehicular (IP/REV): Es aquel servicio que se presta bajo la responsabilidad de un actor estratégico de los sistemas inteligentes para la infraestructura, el tránsito y el transporte (SIT), debidamente certificado para la prestación del servicio de recaudo electrónico vehicular (REV), de conformidad con las formalidades previstas en la normatividad general y las dispuestas en esta resolución por parte del Ministerio de Transporte, y que posee la capacidad de interactuar e intercambiar datos entre los diferentes actores, para realizar el pago de la tarifa de peaje utilizando un único dispositivo TAG RFID por vehículo.

De conformidad con las condiciones aquí dispuestas los actores estratégicos deberán garantizar la interoperabilidad de sus sistemas para el recaudo de peajes electrónicos.

16. Lista blanca: En el ámbito del sistema de recaudo electrónico vehicular (REV), hace referencia a los reportes de los dispositivos TAG RFID activos.

17. Lista negra: En el ámbito del sistema de recaudo electrónico vehicular (REV), hace referencia a los reportes de los dispositivos TAG RFID invalidados.

18. Marca de certificación de interoperabilidad: Marca de certificación del Ministerio de Transporte Colpass, cuyo uso está limitado a los operadores e intermediadores certificados. Dicha marca de certificación identifica, mediante un signo distintivo, el servicio de interoperabilidad a nivel nacional (IP/REV) prestado por el actor estratégico.

19. Medio de pago: Es el instrumento que se utiliza para realizar un pago, incluye entre otros, efectivo, productos bancarios tales como tarjetas de crédito, cuenta de ahorros, transferencias bancarias, depósitos en cuenta, entre otros.

20. Modalidad de pago: Corresponde al producto que el usuario utiliza para acceder a los servicios de recaudo electrónico de peajes y demás servicios complementarios provistos por el intermediador.

21. Modelo de interoperabilidad de peajes: Define las condiciones requeridas para el recaudo electrónico vehicular (REV), del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV).

22. Operador del sistema de interoperabilidad de peajes con recaudo electrónico vehicular, operador o OP IP/REV: Contratista del Estado, con quien la entidad estatal nacional o territorial ha suscrito un contrato de concesión o similar, y el cual se encuentra debidamente certificado para ser operador IP/REV por el Ministerio de Transporte. Dicho contratista tiene la obligación contractual de llevar a cabo el recaudo (manual, mixto o automático) de los peajes, y, a partir de su certificación, es responsable de operar y garantizar el funcionamiento recaudo de los peajes electrónicos (IP/REV), proporcionando las herramientas, instalaciones y elementos (físicos y humanos) necesarios para su funcionamiento.

a) Para la interoperabilidad de peajes con recaudo electrónico vehicular, el concesionario vial podrá realizar la operación de sus peajes con recaudo electrónico vehicular (REV) de forma directa o mediante la subcontratación de un tercero, siempre y cuando su contrato de concesión así lo permita. En todo caso el sujeto responsable de la operación será aquel que cuente con la certificación en los términos de esta resolución;

b) En los casos en que el Estado sea directamente el operador de la vía, él mismo podrá subcontratar la instalación y funcionamiento de los peajes electrónicos.

23. Paso: Para efectos de la presente resolución, contempla el tránsito satisfactorio de un vehículo por un carril IP/REV o por un carril de pago manual.

24. Punto de cobro de peaje: Área o parte de una vía donde se gestiona el pago del peaje, que corresponde a una tarifa por el uso de la infraestructura. Pueden ser estaciones o plazas de peaje, peaje convencional, que incluye todos los carriles del peaje y el lugar físico donde se controla la información de dichos carriles; o pórticos en sistemas de peaje de flujo libre.

25. Números de TAG o número de códigos: Es el conjunto de códigos EPC que son entregados a un INT IP/REV por el Ministerio de Transporte.

26. Recaudo electrónico vehicular o REV: Para efectos de la presente resolución, se entenderá por Recaudo electrónico vehicular (REV) lo dispuesto en el artículo 2.5.4.1 del título 4, de la parte 5, del libro 2 del Decreto 1079 de 2015.

27. Reportes de TAG RFID: Hace referencia a la información de todos los dispositivos TAG RFID activados para interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV) y que permite la conciliación y posterior compensación financiera, que deberá hacerse en forma directa entre los actores estratégicos.

28. Sistema de gestión de transacciones o SiGT: Subsistema diseñado para la recepción, almacenamiento, administración y explotación de toda la información de recaudo electrónico vehicular (REV) cruzada entre los actores estratégicos. Así mismo, será la plataforma sobre la que se certifiquen los actores estratégicos del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV), y se asignen los números de TAG solicitados, y demás funciones asignadas por el Ministerio de Transporte.

29. Servicios adicionales: Servicios que podrá prestar el intermediador IP/REV a los usuarios y/o consumidores diferentes al pago de peajes con recaudo electrónico vehicular, siempre que tenga las habilitaciones y autorizaciones por parte de las autoridades competentes para su prestación.

30. TAG RFID: Dispositivo electrónico que se emplea para identificación por radiofrecuencia (RFID). Para el caso específico de recaudo electrónico vehicular en peajes, se considera como la etiqueta de radiofrecuencia (TAG RFID) según las condiciones adoptadas en el estándar ISO 18000-63, dispuesto en el artículo 2.5.4.2 del Decreto 1079 de 2015 o la norma que lo modifique, adicione o sustituya.

Los TAG RFID puestos a disposición del público deberán cumplir con las normas de calidad y protección a usuarios y/o consumidores que les sean aplicables, y su desconocimiento será objeto de las sanciones dispuestas en la regulación vigente.

31. Usuarios y/o consumidores del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV): Persona natural o jurídica que suscribe un contrato con un intermediador debidamente certificado por el Ministerio de Transporte en los términos de esta resolución, para la prestación del servicio de Interoperabilidad, con la posibilidad de incluir en dicho contrato uno o más TAG asociados a uno o varios vehículos. En todo caso, el usuario solo podrá tener un TAG RFID por vehículo.

TÍTULO II

Actores estratégicos del sistema IP/REV y certificación

ART. 5º—Actores estratégicos del sistema IP/REV y sus roles. Los actores estratégicos del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV), pueden ejercer los siguientes roles en el sistema, siempre que estén certificados para ejercer cada uno de ellos:

1. Operador del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (OP IP/REV).

2. Intermediador del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (INT IP/REV).

ART. 6º—Certificación como operador del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (OP IP/REV) y/o intermediador del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (INT IP/REV). Es la autorización que otorga el Ministerio de Transporte a las personas naturales o jurídicas interesadas en ejercer un rol dentro del sistema IP/REV, previo cumplimiento de los requisitos exigidos para desempeñar el rol solicitado.

La solicitud de certificación se realizará vía electrónica a través de la página del Ministerio de Transporte www.mintransporte.gov.co.

Durante la vigencia de la certificación los actores estratégicos deberán cumplir con los requisitos técnicos, jurídicos y financieros que determine el Ministerio de Transporte.

PAR. 1º—Ninguna persona natural, jurídica o concesionario del Estado podrá ejercer un rol dentro del sistema de Interoperabilidad sin estar previamente certificado por el Ministerio de Transporte.

PAR. 2º—A través de la solicitud de certificación el actor estratégico expresamente bajo la gravedad del juramento manifiesta su voluntad de: (i) cumplir con la reglamentación de las condiciones de IP/REV establecidas en la presente resolución, (ii) cumplir las condiciones para la prestación del servicio IP/REV que serán establecidas en la presente resolución, y (iii) utilizar la oferta básica de interoperabilidad (OBIP), así como adoptar y cumplir como mínimo con las condiciones que allí se establecen, aceptando así mismo acatar e implementar las condiciones futuras que se requieran para el adecuado funcionamiento del sistema.

ART. 7º—Solicitud de números de TAG previo a la certificación. Las personas naturales o jurídicas que a la fecha de publicación de la presente resolución se encuentren prestando el servicio de recaudo electrónico vehicular (REV) o aquellas personas que pretendan ser Intermediadores y hayan suscrito previamente contratos con operadores que cuenten con un sistema de recaudo electrónico vehicular con TAG RFID según la Norma ISO 18000-63, bajo su propio riesgo podrán solicitar de forma voluntaria, antes de presentar la solicitud de certificación, la asignación de conjuntos de números para la fabricación de TAG RFID al Ministerio de Transporte, previa presentación de los soportes que acrediten su condición.

La asignación de conjuntos de números para la fabricación de TAG RFID de ninguna manera suplirá la obligación de certificarse ante el Ministerio de Transporte que debe cumplir el solicitante para ejercer un rol en el sistema. En caso de que el solicitante no obtenga la certificación al vencimiento del término de transición previsto en la presente resolución, los números de TAG autorizados serán revocados y su asignación quedará sin efecto.

ART. 8º—Migración de TAG en circulación e inventario. Una vez al intermediador le sea otorgado la certificación, este debe migrar dentro del año siguiente a la publicación de la presente resolución los TAG en circulación e inventario, previa solicitud al Ministerio de Transporte y adopción de los formatos y procedimientos definidos por la dirección de infraestructura.

Solo se autorizará la migración de los TAG que cumplan con las condiciones técnicas y de interoperabilidad establecidas en la presente resolución.

ART. 9º—Condiciones y requisitos para obtener la certificación como actor estratégico. Para obtener la certificación que es requisito para prestar el servicio de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV), los solicitantes deberán acreditar los siguientes requisitos que aseguren el cumplimiento del objetivo definido en el artículo 1º de la presente resolución:

1. Operador del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (OP IP/REV):

a) Formulario de solicitud de certificación ante el Ministerio de Transporte suscrito por el interesado o su representante legal. El formulario estará disponible para los interesados en la página web del Ministerio de Transporte a través del aplicativo dispuesto para ello;

b) Registro único tributario (RUT) vigente expedido con una antelación máxima de treinta (30) días hábiles a la fecha de radicación de la solicitud en el Ministerio de Transporte. El RUT del interesado deberá tener dentro de su actividad económica CIIU la sección H división 52, 5221 “Actividades de estaciones, vías y servicios complementarios para el transporte terrestre”;

c) Estar constituido legalmente y debidamente registrado en el registro mercantil de la Cámara de Comercio. Esta condición se verifica por parte del Ministerio de Transporte mediante consulta al sistema RUES;

d) Identificación del domicilio principal y relación de sus oficinas, señalando su dirección de notificación, la cual deberá concordar con lo registrado en el certificado de existencia y representación;

e) Estados financieros de la última vigencia fiscal debidamente certificados, dictaminados y con las notas respectivas, conforme a las normas vigentes aplicables;

f) Acreditar que cuentan con un patrimonio líquido mínimo de tres mil trescientos (3.300) salarios mínimos mensuales legales vigentes (SMMLV). El patrimonio solicitado se verificará con los estados financieros con corte a la última vigencia fiscal, aplicable antes de la presentación de la solicitud de certificación, debidamente aprobados por la asamblea de accionistas, junta de socios o el órgano social competente y deberán encontrarse debidamente auditados y dictaminados;

g) En el caso de sociedades constituidas dentro del año anterior a la fecha de publicación de la presente resolución, los estados financieros con base en los cuales se presenta la información para acreditar el patrimonio líquido corresponderán a los estados financieros del último cierre ordinario si lo hubiere tenido o, en caso contrario, a los estados financieros de apertura al momento de constitución de la sociedad, los cuales deberán estar certificados y/o auditados y dictaminados de acuerdo con la normatividad aplicable y cumplir con el requisito del patrimonio líquido mínimo exigido;

h) Cumplir con las razones financieras establecidas en el anexo 2 financiero, las cuales se calcularán con base en los estados financieros aportados;

i) Certificado expedido por un profesional de la ingeniería de telecomunicaciones o electrónico en la que se acredita, que el interesado cuenta con una infraestructura tecnológica e informática que cumple con las especificaciones establecidas en los anexos 1 técnico, 3 Colpass y 5 Especificaciones de interoperabilidad de la presente resolución. Dicho certificado debe venir acompañado con la copia de la tarjeta profesional del ingeniero que lo suscribe;

j) Certificado expedido por un profesional de la ingeniería de sistemas en la que se acredita, que el interesado cuenta con: (i) un sistema de información para establecer conexiones recurrentes con la totalidad de los intermediarios, y con el SiGT o el sistema designado por el Ministerio de Transporte, y (ii) con un sistema de información de seguimiento de peticiones, quejas, reclamos y resolución de disputas capaz de establecer conexiones bajo demanda con todos los INT IP/REV, quienes recibirán las mismas por parte de sus respectivos usuarios;

k) Acreditar que se realizaron pruebas satisfactorias con el SiGT o con el sistema de información que el Ministerio de Transporte designe. Para este fin, el ministerio habilitará un ambiente de pruebas en el cual el interesado se podrá registrar previo a la obtención de la certificación y realizar las pruebas de los sistemas de información.

2. Intermediador del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (INT IP/REV).

a) El interesado deberá presentar el formulario de solicitud de certificación ante el Ministerio de Transporte suscrito por el representante legal o apoderado. El cual se encuentra disponible en la página web del Ministerio de Transporte a través del aplicativo dispuesto para ello;

b) Registro único tributario (RUT) vigente expedido con una antelación máxima de treinta (30) días hábiles a la fecha de presentación de la solicitud;

c) Estar constituido legalmente y debidamente registrado en el registro mercantil de la Cámara de Comercio, esta condición se verificará por parte del Ministerio de Transporte mediante consulta al sistema RUES;

d) Estados financieros de la última vigencia fiscal debidamente certificados y dictaminados conforme a las normas vigentes aplicables en Colombia, con sus respectivas notas;

e) Acreditar que cuentan con un patrimonio líquido mínimo de siete mil setecientos (7.700) salarios mínimos mensuales legales vigentes (SMMLV). El patrimonio solicitado se verificará con los estados financieros con corte a la última vigencia fiscal, aplicable antes de la presentación de la solicitud de certificación, debidamente aprobados por la asamblea de accionistas, junta de socios o el órgano social competente y deberán encontrarse debidamente auditados y dictaminados;

f) (Modificado).* En el caso de sociedades constituidas dentro del año anterior a la fecha de publicación de la presente resolución, los estados financieros con base en los cuales se presenta la información para acreditar el patrimonio líquido corresponderán a los estados financieros del último cierre ordinario si los hubiere tenido o, en caso contrario, a los estados financieros de apertura al momento de constitución de la sociedad, los cuales deberán estar certificados y/o auditados y dictaminados de acuerdo con la normatividad aplicable en Colombia y cumplir con el requisito del patrimonio líquido mínimo requerido;

*(Nota: Modificado por la Resolución 3254 de 2018 artículo 1° del Ministerio de Transporte)

g) Cumplir con las razones financieras establecidas en el anexo 2 financiero, las cuales se calcularán con base en los estados financieros aportados;

h) Certificado expedido por un profesional de la ingeniería de telecomunicaciones o electrónico en la que se acredita, que el interesado cuenta con una infraestructura tecnológica e informática que cumple con las especificaciones establecidas en los anexos técnico 1, 3 Colpass y 5 Especificaciones de Interoperabilidad de la presente resolución. Dicho certificado debe venir acompañado de copia de la tarjeta profesional del ingeniero de quien lo suscribe;

i) Certificado expedido por un profesional de la ingeniería de sistemas en la que se acredita que el interesado cuenta con: (i) un sistema de información que permite registrar y administrar las operaciones correspondientes al intermediador del sistema de interoperabilidad de peajes con recaudo electrónico vehicular, (ii) un sistema de información para establecer conexiones recurrentes con la totalidad de los operadores del sistema de interoperabilidad de peajes con recaudo electrónico vehicular, y el SiGT, o sistema o subsistema designado por el Ministerio de Transporte, y (iii) con un sistema de información de seguimiento de peticiones, quejas, reclamos y resolución de disputas, capaz de establecer conexiones bajo demanda con todos los operadores del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (OP IP/REV). Dicho certificado debe venir acompañado con copia de la tarjeta profesional del ingeniero que lo suscribe;

j) Acreditar que se realizaron las pruebas satisfactorias con el SiGT o con el sistema de información que el Ministerio de Transporte designe. Para este fin, el ministerio habilitará un ambiente de pruebas en el cual el interesado se podrá registrar previo a la obtención de la certificación y realizar pruebas de los sistemas de información.

PAR. 1º—La revisión y evaluación de los documentos y calidades exigidas para obtener la certificación se realizará por parte del Ministerio de Transporte.

El Ministerio de Transporte podrá solicitar, de forma previa a la obtención de la certificación, la realización de pruebas entre los actores estratégicos y otras entidades con la finalidad de garantizar la Interoperabilidad.

En caso de que la solicitud esté incompleta o se deba allegar información complementaria o documentación, el Ministerio de Transporte otorgará un término no mayor a un mes contado a partir del envío del requerimiento al solicitante, para atender el requerimiento. En caso de que no se allegue la información en el término antes establecido se entenderá como desistida la solicitud.

PAR. 2º—(Modificado).* Quien por efecto de su contrato de concesión o similar deba prestar los servicios de recaudo, podrá obtener la certificación en el rol de operador con la presentación de una certificación de la interventoría del contrato o de la entidad adjudicataria respecto de su obligación de prestar el servicio y los documentos establecidos en los literales h), i) y j) del numeral 1º del presente artículo. En caso de que se solicite la certificación como intermediador, se deberá presentar toda la información establecida para ese rol.

*(Nota: Modificado por la Resolución 3254 de 2018 artículo 2° del Ministerio de Transporte)

PAR. 3º—Quien por efecto de su contrato de concesión de recaudo de peaje o similar, se encontraba en la obligación de certificarse como operador en los plazos y términos establecidos por la Resolución 4303 de 2015 y el plazo de dicha obligación ya se haya cumplido, contará con un (1) mes calendario contado a partir de la fecha de la publicación de la presente resolución para certificarse como operador y, en consecuencia, prestar a los usuarios y/o consumidores el servicio de interoperabilidad.

ART. 10.—Trámite de la certificación. La certificación se otorgará en un término no superior a sesenta (60) días calendario, contados desde el momento de la fecha de la última radicación con la cual se acredite el cumplimiento de la totalidad de los requisitos establecidos en la presente resolución.

En el acto administrativo a través del cual el grupo de información y seguimiento de la dirección de infraestructura del Ministerio de Transporte, otorga la certificación en la cual se deberá especificar el nombre, razón social o denominación, domicilio principal, correo electrónico y la información mediante la cual se identificará al actor estratégico.

El no otorgamiento de la certificación por parte del Ministerio de Transporte deberá estar motivado, será susceptible de los recursos a que se refiere la Ley 1437 de 2011, ante la dirección de infraestructura del Ministerio de Transporte o viceministerio de infraestructura, según corresponda y no constituye un impedimento para presentar de nuevo la solicitud.

PAR.—El Ministerio de Transporte a través de la dirección de infraestructura mantendrá permanentemente publicados y actualizados en la dirección https://www. mintransporte.gov.co/SiGT los operadores e intermediadores certificados.

ART. 11.—Vigencia de la certificación. La certificación para la prestación de los servicios de IP/REV se mantendrá vigente siempre que el solicitante acredite: (i) que mantiene las condiciones establecidas para el otorgamiento de la certificación, (ii) que cumple con las obligaciones legales que conlleva el uso de la marca de interoperabilidad, y (iii) que cumple con lo dispuesto en la oferta básica de interoperabilidad. Para el efecto, el Ministerio de Transporte y/o las entidades de inspección, vigilancia y control podrán solicitar de oficio, la información que se requiera para la revisión del cumplimiento de dichas condiciones y/o obligaciones.

No obstante lo anterior, el actor estratégico deberá informar al Ministerio de Transporte o a quien este designe, de cualquier cambio que afecte las condiciones que dieron lugar a su certificación, dentro del mes siguiente a su acaecimiento.

PAR. 1º—En el evento en que el operador haya obtenido la certificación en el rol de operador por efecto del contrato de concesión suscrito, mantendrá la certificación siempre que acredite y mantenga las condiciones establecidas para su otorgamiento, entre las cuales se encuentra la vigencia del contrato de concesión y/o similar.

PAR. 2º—La certificación se entregará sujeta a condición suspensiva de entrega de pólizas en los términos y condiciones establecidos en el artículo 31 de la presente resolución. El incumplimiento de lo anterior, acarreará la declaratoria de pérdida de fuerza ejecutoria del acto.

ART. 12.—Actualización de la información de certificación. El actor estratégico al cierre de cada vigencia ordinaria deberá presentar al Ministerio de Transporte o a quien este designe, los estados financieros de la última vigencia fiscal debidamente certificados y dictaminados conforme a las normas vigentes aplicables, con sus respectivas notas.

ART. 13.—Certificación en múltiples roles. Los actores estratégicos del sistema, que pretendan certificarse para ejercer más de un rol en el sistema de recaudo electrónico vehicular IP/REV, deberán acreditar que cuentan con la capacidad legal para el desempeño de esas múltiples actividades y los requisitos de patrimonio líquido mediante la suma de los patrimonios líquidos solicitados para el intermediador y operador descritos en la presente resolución, así como ajustar su funcionamiento, operación y estructura, de conformidad con las condiciones de certificación de cada rol.

Los concesionarios podrán certificarse en varios roles, siempre que se acrediten los requisitos establecidos en el parágrafo 2º del artículo 9º de la presente resolución.

ART. 14.—Solicitud de números de TAG. Mientras mantenga su calidad de certificado el intermediador podrá a través del SiGT obtener los números de TAG, que deberán ser grabados en los TAG entregados a los usuarios, esto con el fin de garantizar un número único por TAG. El procedimiento para su asignación se realizará así:

1. El intermediador solicitará al Ministerio de Transporte la asignación de números de TAG a través del sistema de gestión de transacciones (SiGT).

2. El Ministerio de Transporte realizará el proceso de validación y comunicará por medio del SiGT los números asignados en un plazo máximo de tres (3) días hábiles, posteriores a la solicitud.

TÍTULO III

Marca de interoperabilidad

ART. 15.—Marca de interoperabilidad. Los actores estratégicos que están debidamente certificados para ejercer un rol en el sistema IP/REV deberán utilizar la marca de certificación adoptada en el anexo 3 Colpass de la presente resolución, en un lugar visible del carril IP/REV, así como en forma física o electrónica, para indicar los lugares donde se realicen los pagos y recargas del servicio IP/REV, o en los lugares y en las formas definidas en el anexo 3 Colpass de la presente resolución. Esto con el fin que los usuarios y/o consumidores puedan identificar fácilmente los peajes y los carriles que pertenecen al sistema IP/REV.

ART. 16.—Propiedad. La marca de interoperabilidad Colpass será de ámbito nacional y de propiedad exclusiva de la Nación, bajo la administración del Ministerio de Transporte.

PAR.—El Ministerio de Transporte podrá ejercer directamente o a través de terceros todas aquellas acciones pertinentes para proteger la marca de interoperabilidad Colpass de utilizaciones indebidas, abusivas, fraudulentas, engañosas o no autorizadas, con el fin de preservar su imagen y propender por el cumplimiento de los fines propuestos en esta reglamentación.

ART. 17.—Vigencia del derecho al uso de la marca. El derecho al uso de la marca de interoperabilidad estará condicionada al mantenimiento de la certificación del actor estratégico. En el evento en que el actor estratégico pierda la certificación, este no podrá hacer uso de la marca de interoperabilidad.

TÍTULO IV

Oferta básica de interoperabilidad (OBIP)

ART. 18.—Adóptese el anexo 4 “Oferta básica de interoperabilidad (OBIP)”, el cual hace parte integral de la presente resolución y define el contenido mínimo que debe constar en los acuerdos que logren los actores estratégicos, en aras de asegurar el correcto funcionamiento del sistema IP/REV y la protección de los usuarios que lo utilicen.

Sin perjuicio de lo anterior, los actores estratégicos podrán en desarrollo de la autonomía de la voluntad celebrar acuerdos adicionales o establecer condiciones adicionales, las cuales no podrán contravenir, las condiciones de la oferta básica de interoperabilidad (OBIP), el orden público, la normativa vigente o afectar los derechos de los usuarios y consumidores.

PAR. 1º—El cumplimiento de las condiciones establecidas en el anexo 4 “Oferta básica de interoperabilidad del sistema (IP/REV)” de la presente resolución, serán un requisito para mantener la certificación y la utilización de la marca Colpass. Los intermediadores certificados por el Ministerio de Transporte adquieren la obligación de ser Interoperables con los operadores certificados y viceversa bajo las condiciones mínimas definidas en las normas aplicables, en especial las establecidas en la presente resolución.

TÍTULO V

Condiciones mínimas de prestación de servicio a los usuarios del sistema IP/REV

ART. 19.—Principios aplicables a la relación entre los actores estratégicos y los usuarios de los sistemas de recaudo electrónico vehicular. Las relaciones entre los actores estratégicos y los usuarios de los sistemas de recaudo electrónico vehicular (IP/ REV), deberán velar por la protección de los usuarios y consumidores y se regirán por los siguientes principios:

a) Favorabilidad. Toda duda en la interpretación o aplicación de las normas y de las cláusulas del contrato celebrado entre los actores estratégicos será decidida a favor de los usuarios, de manera que prevalezcan sus derechos;

b) Calidad. Los actores estratégicos prestarán sus servicios en forma continua y eficiente, de conformidad con los parámetros técnicos establecidos en la presente resolución y sus anexos, o las normas que la modifiquen, adicionen o sustituyan;

c) Buena fe. Los diferentes actores estratégicos de los sistemas de recaudo electrónico vehicular (IP/REV), guardarán la buena fe en las relaciones que establezcan;

d) Información. En todo momento de la relación que se establezca entre los operadores y los Intermediarios y entre estos y los usuarios, los primeros deberán suministrar información en forma transparente, comprensible e idónea, necesaria, actualizada y oportuna, suficiente, comprobable, precisa, cierta, completa, gratuita y que no induzca a error, para efectos de que los usuarios tomen decisiones informadas respecto del servicio o servicios ofrecidos o requeridos. Esta información en los términos indicados deberá estar disponible por los operadores e intermediadores, para efectos de la regulación, vigilancia y control del Estado.

La información gratuita al usuario será la necesaria para conocer las condiciones de contratación, la ejecución contractual y las obligaciones y derechos a los que se encuentra sujeto como usuario y/o consumidor del servicio IP/REV;

e) Protección de datos personales. La regulación y tratamiento de los datos personales de los usuarios por parte de los actores estratégicos deberá atender a las disposiciones constitucionales, la Ley 1581 de 2012 y demás normas reglamentarias en la materia, para ello, los actores estratégicos deberán informar a los usuarios al momento de la toma de los servicios sobre el tratamiento de los mismos y el que se les dará durante la relación. Así mismo, los actores deberán obtener las autorizaciones de que trata la Ley 1581 de 2012 y el Decreto 1377 de 2012, compilado por el Decreto 1074 de 2015 y las normas que los modifiquen, adicionen o sustituyan para el almacenamiento y tratamiento de su información personal;

f) Publicidad. Los intermediarios y operadores deberán publicitar a través de medios físicos o virtuales, las características del servicio, los documentos tipo de la relación contractual, las tarifas del servicio y sus modificaciones en forma clara, veraz, oportuna y verificable, sobre las características propias del servicio de IP/ REV. Esto con el fin de permitir y facilitar su comparación y comprensión al usuario.

ART. 20.—Derechos de los usuarios y/o consumidores del sistema de interoperabilidad de recaudo electrónico vehicular (REV). Sin perjuicio de lo dispuesto en la Ley 1480 de 2011, o la norma que la modifique, adicione o sustituya los usuarios y/o consumidores del sistema de interoperabilidad de recaudo electrónico vehicular (IP/REV), tendrán los siguientes derechos:

a) Hacer uso del sistema de recaudo electrónico vehicular de peaje en todo el territorio nacional, en las carreteras que se encuentren habilitadas para ello y a través del servicio que le presten los actores estratégicos correspondientes;

b) Utilizar los servicios de recaudo electrónico vehicular (REV) al suscribir un contrato con un intermediador del sistema de interoperabilidad;

c) Recibir el servicio de recaudo electrónico vehicular que ha contratado de manera continua, sin interrupciones de conformidad con lo establecido en la presente resolución o en aquellas que la modifique, adicione o sustituya;

d) Elegir libremente el intermediador que le proporcionará el servicio de recaudo electrónico vehicular (REV);

e) Tener acceso a toda la información que necesite en relación con el ofrecimiento o prestación de los servicios;

f) Conocer previamente las tarifas aplicables al servicio de recaudo electrónico vehicular, las cuales no podrán ser modificadas sin ser previamente comunicadas al usuario y aceptadas por este, en concordancia con lo previsto en el artículo 26 de la presente resolución. En caso de prestar servicios adicionales, estos se deberán realizar conforme a la normatividad vigente que aplique;

g) Exigir que se mantengan las condiciones acordadas contractualmente, de conformidad con los términos dispuestos en las normas de protección al usuario y/o consumidor;

h) Gozar de la protección de sus datos personales de conformidad con lo dispuesto en la Ley 1581 de 2012 y sus normas reglamentarias. Así mismo los usuarios podrán ejercer el derecho de hábeas data observando los procedimientos dispuestos en los artículos 14, 15 y 16 de la Ley 1581 de 2012. En cualquier momento el usuario podrá solicitar copia de los datos suministrados y obtenidos de la actualización de los mismos;

i) Escoger por lo menos una de las modalidades de pago dispuestas por el intermediador, de conformidad con lo establecido en el artículo 28 de la presente resolución o aquella que la modifique, adicione o sustituya;

j) Terminar la relación contractual en cualquier momento de la prestación del servicio, sujeto al pago de los servicios que se le hayan prestado hasta el momento de la terminación y, en caso de tener saldo pendiente de uso en una cuenta prepago, tener derecho a su íntegra devolución;

k) Obtener la información adicional en los casos en que el intermediador ofrezca servicios adicionales al servicio de recaudo electrónico vehicular (REV) para peajes electrónicos. En este caso, los servicios adicionales serán diferenciados en el contrato de la prestación del servicio de recaudo electrónico vehicular (REV);

l) Recibir el servicio de recaudo electrónico vehicular para peajes electrónicos, aun cuando existan disputas con el intermediador con ocasión de los servicios adicionales prestados por este;

m) Obtener una copia del contrato que se establezca con el INT IP/REV de forma física o electrónica. El formato del contrato que establezca el actor estratégico deberá estar disponible en línea en todo momento, para permitir su consulta sin restricciones;

n) Tener a su disposición un TAG RFID para la utilización de los servicios en condiciones de calidad, durante la vigencia de la relación que se establezca con el intermediador;

o) Presentar de manera respetuosa consultas, peticiones, solicitudes, quejas o reclamos ante el intermediador elegido, referentes a la prestación de los servicios y a la información suministrada y recibir respuesta oportuna a las mismas;

p) Recibir oportunamente el estado de cuenta por la utilización de los servicios y tener acceso a la información de los consumos a través de los canales que el intermediador correspondiente esté obligado a proveer de conformidad con el artículo 23 de la presente resolución o la que la modifique, adicione o sustituya;

q) Acceder a los servicios adicionales de los concesionarios de carreteras, en los términos dispuestos en el contrato de concesión o la normatividad vigente;

r) Los demás derechos reconocidos en la normatividad vigente, en especial lo dispuesto en la Ley 1480 de 2011.

PAR.—Los derechos establecidos en el presente artículo deberán estar contenidos y desarrollados en la relación contractual que establezcan los actores estratégicos con los usuarios, y los mismos deberán constar en las relaciones que establezcan los operadores con los intermediarios, en cuanto a las responsabilidades que para su cumplimiento le competa a cada uno.

ART. 21.—Obligaciones de los usuarios del sistema de recaudo electrónico vehicular (REV). Sin perjuicio de lo dispuesto en la Ley 1480 de 2011, o la norma que la modifique, adicione o sustituya, los usuarios y/o consumidores del sistema de interoperabilidad de recaudo electrónico vehicular (IP/REV), tendrán las siguientes obligaciones mínimas:

a) Tomar todas las medidas necesarias para garantizar que el dispositivo TAG RFID esté debidamente instalado y operativo al momento de su paso, de conformidad con los parámetros que le haya suministrado previamente el intermediador, con la finalidad de garantizar el buen uso del sistema de recaudo electrónico vehicular;

b) Proporcionar información veraz, en especial la relacionada con las condiciones necesarias para la prestación del servicio, así como las características e información del vehículo en que se instalará el TAG RFID;

c) Hacer buen uso del servicio y del TAG RFID entregado para la prestación del mismo de conformidad con lo pactado en la relación que se establezca con el INT IP/REV;

d) No remover el TAG RFID del vehículo para el cual fue asignado;

e) Informar de cualquier daño que se presente en el TAG RFID al INT IP/REV para que a través de este se reemplace el mismo, de conformidad con las cláusulas de garantía aplicables a este producto y en los términos dispuestos en la Ley 1480 de 2011;

f) Hacer uso de la información entregada por el INT IP/REV únicamente para los efectos de la prestación de los servicios;

g) Dar cumplimiento a los pactos contractuales establecidos con el INT IP/REV y dependiendo de la modalidad de pago mantener un saldo suficiente para la efectiva prestación del servicio;

h) Pagar el importe o tasa correspondiente al servicio que se le presta a través del recaudo electrónico vehicular (REV), incluso si el sistema se encontrara fuera de línea al momento del uso de la infraestructura vial, caso en el que el usuario tendrá derecho a pasar por el peaje sin la obligación de aportar otro medio de pago; pero este paso no exime al usuario de tener que realizar el pago de la tarifa de peaje una vez reportado el paso por el operador al intermediador. En todo caso, el operador deberá aportar al intermediador los soportes y/o pruebas del paso de un usuario, si este controvierte el cobro efectuado.

ART. 22.—Obligaciones de los operadores con los usuarios y/o consumidores. Los operadores deberán garantizar las siguientes condiciones a los usuarios y/o consumidores:

a) Permitir en los peajes a su cargo, el uso del servicio de recaudo electrónico vehicular por parte de aquellos usuarios habilitados que cuenten con saldo suficiente en sus cuentas IP/REV;

b) Prestar el servicio de recaudo de peaje electrónico vehicular, en los peajes a su cargo disponiendo para ello al menos un carril por sentido (mixto o exclusivo);

c) Interconectarse con todos los intermediadores certificados, de manera que los usuarios que suscriban contratos con dichos intermediarios puedan hacer uso del servicio de REV en peajes;

d) Prestar el servicio de recaudo electrónico vehicular de manera continua, sin interrupciones de conformidad con lo establecido en la presente resolución y sus anexos o en aquellas resoluciones que las modifiquen, adicionen o sustituyan;

e) Proveer a los intermediadores toda la información de la cobertura del servicio de peajes electrónicos, de modo que el usuario la conozca de manera oportuna;

f) Señalizar con la marca de interoperabilidad “ColPass” los carriles REV, de tal manera que permitan al usuario su fácil identificación;

g) Realizar el pago a los intermediadores por concepto de los servicios prestados por estos, en los términos y condiciones dispuestas en el anexo 4 —OBIP— Condiciones aplicables al operador;

h) Dar respuesta a las solicitudes de información de los intermediadores en los tiempos dispuestos en el anexo 4 - OBIP Condiciones aplicables al operador;

i) Prestar a los usuarios los servicios adicionales dispuestos en el contrato de concesión o la normatividad vigente, aun cuando el pago se realice electrónicamente;

j) Garantizar el paso del usuario IP/REV por el carril IP/REV, en el evento en que se presenten fallas del sistema del intermediador o del operador o en la comunicación entre ellos, en los términos establecidos para ello en el numeral d) y e) de las “Condiciones mutuas a establecerse entre los operadores y los intermediadores” incluidos en el anexo 4 Oferta básica de interoperabilidad (OBIP).

ART. 23.—Obligaciones de los intermediadores en los contratos que suscriba con los usuarios y/o consumidores. Los intermediadores deberán garantizar las siguientes condiciones en los contratos que suscriban con los usuarios y/o consumidores:

a) Activar el dispositivo TAG RFID y/o recargar la cuenta asociada, y el uso del dispositivo TAG RFID para la prestación efectiva del servicio IP/REV en un período máximo de una (1) hora;

b) Establecer las condiciones para la provisión y correcta instalación del dispositivo TAG RFID en el vehículo de los usuarios del sistema IP/REV, de tal manera que se garantice que, al momento de la instalación del mismo, se ajustan a los requisitos técnicos necesarios para su apropiada lectura;

c) Interconectarse con todos los operadores certificados, de manera que sus usuarios con los que suscriba contratos puedan hacer uso del servicio de peajes electrónicos con recaudo electrónico vehicular en los peajes de todos los operadores certificados;

d) Prestar el servicio de recaudo electrónico vehicular de manera continua, sin interrupciones de conformidad con lo establecido en la presente resolución, sus anexos o en aquellas resoluciones que las modifiquen, adicionen o sustituyan;

e) Mantener informados a los usuarios de los peajes sobre las condiciones de prestación del servicio de IP/REV, así como de cualquier cambio que se produjera en dichas condiciones tales como cobertura, tarifas, servicios adicionales, entre otros;

f) Realizar la compensación al operador, en los términos y condiciones dispuestos en el anexo 4 - OBIP;

g) Mantener las condiciones acordadas contractualmente, de conformidad con los términos dispuestos en las normas de protección al usuario y/o consumidor;

h) Tener disponibles al menos dos canales de comunicación para que el usuario pueda consultar el estado de su cuenta y saldo disponible en el sistema IP/REV. El intermediador debe garantizar la disposición de un canal de atención presencial para atender consultas del usuario y/o consumidor en caso de fallas en los canales de atención virtuales. Adicionalmente, el intermediador debe notificar mediante alertas a través de, al menos, dos canales de comunicación, el valor del peaje y el saldo de la cuenta del usuario después de que el usuario utilice el servicio IP/REV;

i) Informar al usuario y/o consumidor los dos canales de comunicación (como mínimo) para instaurar peticiones, quejas y reclamos (PQR) sobre el sistema IP/ REV o su uso;

j) Garantizar la disposición de un canal de atención presencial para atender PQR en caso de fallas en los canales de atención virtuales;

k) Proveer mecanismos ágiles y eficientes para atender y resolver las peticiones, quejas y reclamos, solicitudes y consultas de los usuarios, en un término no superior a 15 días hábiles desde su recibo;

l) Proveer a los usuarios los medios y modalidades de pago de acuerdo con lo dispuesto en el artículo 28 de la presente resolución;

m) Permitir al usuario terminar la relación contractual en cualquier momento de la prestación del servicio, sujeto al pago de los servicios que se le hayan prestado hasta el momento de la terminación y, en caso de tener saldo pendiente de uso en una cuenta prepago, tener derecho a su íntegra devolución;

n) Asegurar la prestación continua del servicio del IP/REV al usuario sin perjuicio de las disputas que se puedan presentar con este con ocasión de la prestación de servicios adicionales;

o) Entregar al usuario una copia del contrato que se establezca con el INT IP/REV de forma física o electrónica. Mantener disponible en todo momento de forma electrónica, el formato del contrato de prestación de servicios IP/REV y permitir al usuario su consulta sin restricciones;

p) Suministrar a los usuarios un TAG RFID que cumplan con las especificaciones técnicas dispuestas en la presente resolución y en especial en el anexo 1 - Anexo técnico, durante la vigencia de su relación contractual;

q) Proveer un sistema de información que muestre la trazabilidad y permita hacer seguimiento a las peticiones, quejas y reclamos, solicitudes y consultas de los usuarios;

r) Dar acceso a la información de los consumos a través de los diferentes canales, de conformidad con lo dispuesto en la presente resolución o la que la modifique, adicione o sustituya;

s) Reconocer a los usuarios los derechos establecidos en la normatividad vigente, en especial lo dispuesto en la Ley 1480 de 2011.

ART. 24.—Contenido mínimo del contrato de prestación de servicios de recaudo electrónico vehicular (REV). Además de las condiciones dispuestas en el artículo 37 de la Ley 1480 de 2011, los contratos de prestación de los servicios que disponga el INT IP/ REV para la vinculación de usuarios deberán contener como mínimo:

a) El nombre o razón social del intermediador y el domicilio de su sede o establecimiento principal;

b) El nombre o razón social y domicilio del usuario que celebró el contrato;

c) Datos del vehículo o vehículos inscritos bajo este contrato a nombre de un usuario;

d) Servicios contratados. En el evento en que se ofrezcan servicios adicionales a los del servicio de recaudo electrónico vehicular deberán informarse y actualizarse durante la ejecución del contrato las condiciones de los mismos en los términos establecidos en la normatividad vigente, en especial las normas de protección al consumidor;

e) Precio y forma de pago del servicio IP/REV, especificando la modalidad de pago escogida por el usuario;

f) Las condiciones de prestación de servicio tanto del operador IP/REV como el intermediador IP/REV acorde a la normatividad vigente;

g) Condiciones para el inicio de la prestación del servicio IP/REV y plazo máximo para que el usuario pueda hacer uso del mismo;

h) Derechos y obligaciones del usuario;

i) Obligaciones del intermediador;

j) Causales y condiciones para la suspensión y trámites obligatorios de notificación en caso de suspensión;

k) Causales y condiciones para la terminación y trámites obligatorios de notificación en caso de terminación;

l) Causales de incumplimiento del usuario;

m) Causales de incumplimiento del intermediador;

n) Consecuencias del incumplimiento de cada una de las partes;

o) Trámite de peticiones, quejas, reclamos, sugerencias y felicitaciones (PQRSF) ante el intermediador de conformidad con lo dispuesto en esta resolución y la normatividad vigente;

p) Información al usuario en materia de protección de los datos personales y tratamiento de la información ante el reporte a operadores de información financiera, comercial y crediticia o centrales de riesgo, caso este último en que también deberá tenerse en cuenta las disposiciones contenidas en la Ley 1266 de 2008, en particular en lo que hace referencia al cumplimiento de los principios y deberes que se consagran en dicha ley.

ART. 25.—Prohibición. Además de las condiciones dispuestas en los artículos 42 y 43 de la Ley 1480 de 2011, en los contratos de prestación de servicios que se pacten entre los usuarios y los intermediadores no se podrán establecer las siguientes cláusulas:

a) Relaciones comerciales o prestación de servicios prohibidos por ley;

b) Las que obliguen al usuario o permitan la renuncia de los mismos de los derechos concedidos por ley y en especial los contenidos en la presente resolución;

c) Las que desconozcan los derechos de los consumidores, respecto de la prestación de los servicios vinculados al recaudo electrónico vehicular de peajes, como también las que desconozcan los derechos de los consumidores de otros servicios afectos a la relación;

d) Cláusulas que limiten la responsabilidad del intermediador por la prestación del servicio, la calidad del TAG RFID, el manejo de los datos de los usuarios o la administración de los recursos entregados por los usuarios;

e) Cláusulas que obliguen a la compra de servicios adicionales o dispositivos adicionales a los requeridos para la prestación del servicio de recaudo electrónico vehicular, como prerrequisito u obligación para la prestación de este o que impongan términos de permanencia mínima contractual a los usuarios;

f) Estipulaciones que otorguen a los INT IP/REV la facultad de terminar unilateralmente el contrato, o suspender su ejecución, por razones distintas al incumplimiento de las obligaciones del usuario, caso fortuito, fuerza mayor y las demás que establezca la ley.

PAR.—La estipulación de alguna de estas cláusulas dará lugar a las sanciones previstas en el artículo 61 de la Ley 1480 de 2011.

ART. 26.—Información de las tarifas, precios y condiciones. Al momento de la oferta y/o de la celebración del contrato y durante la ejecución del mismo, los usuarios deben conocer previamente y en forma expresa, las tarifas, precios y condiciones que se aplicarán al servicio de recaudo electrónico vehicular y cualquier modificación de las mismas deberá ser informada al usuario.

En el evento en que el usuario, no manifieste su inconformidad con la modificación propuesta, dentro del término de cuarenta y cinco (45) días siguientes al recibo de la notificación, se entenderá su aceptación tácita.

El usuario deberá manifestar su inconformidad con la modificación propuesta dentro del término antes establecido al intermediador por cualquiera de los canales habilitados por este, teniendo la opción de rescindir el contrato sin que haya lugar a penalidad o cargo alguno. En todo caso, esta decisión no exime al usuario del pago de los saldos por pagar.

Así mismo, el intermediador (INT IP/REV) deberá mantener en su sitio web una relación de los costos y tarifas cobrados al usuario, lo anterior sin perjuicio de que el intermediador en desarrollo de la relación contractual ofrezca promociones a los usuarios.

TÍTULO VI

Comisiones y modalidades de pago

ART. 27.—Comisión del servicio entre el operador y el intermediador. La comisión por todos los servicios prestados por los intermediadores IP/REV a los operadores IP/ REV del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (OP IP/REV), no debe ser inferior al uno por ciento (1%) ni superior al dos punto cinco por ciento (2,5%) de las tarifas de cada peaje cobradas a los usuarios de las vías, con excepción de los vehículos exentos establecidos en el artículo 21 de la Ley 105 de 1993 modificado por el artículo 1º de la Ley 787 de 2002.

Adicionalmente, el operador deberá asumir los costos transaccionales que se le generen en la relación con los usuarios del sistema por concepto de utilización de medios de pago.

En ningún caso se podrá cobrar al usuario, por el paso por la estación de peaje, un valor superior a la tarifa establecida para el respectivo peaje por la autoridad competente de conformidad con lo dispuesto en el artículo 21 de la Ley 105 de 1993, modificado por la Ley 787 de 2002.

ART. 28.—Modalidades de pago. El intermediador deberá permitir a los usuarios del peaje el pago de la tarifa del mismo o la recarga a la cuenta del usuario para descontar los pagos, como mínimo a través de una cuenta de ahorros y/o mediante el uso de tarjetas de crédito y débito aceptadas en el país. Adicionalmente, deberá ofrecer a los usuarios por lo menos dos (2) de las siguientes modalidades de pago:

a) Prepago simple: El intermediador activa al usuario y/o consumidor un dispositivo TAG RFID, haciendo una recarga mínima utilizando dicho dispositivo hasta que se haga necesario realizar una nueva recarga. La prestación de otros servicios a través de la cuenta de prepago simple estará condicionada al cumplimiento de los requisitos establecidos por la Superintendencia Financiera y a su manejo a través de entidades vigiladas por esa superintendencia;

b) Prepago con cargo recurrente: El intermediador activa al usuario y/o consumidor un dispositivo TAG RFID indicando el medio de pago y el monto que desee recargar con cargo a ese medio de pago. Dicha recarga será automática una vez que el saldo llegue a un valor predeterminado por el usuario y/o consumidor. En este caso el usuario y/o consumidor debe contar con un producto financiero o medio de pago que respalde la activación y el uso del dispositivo TAG RFID. La prestación de otros servicios diferentes a los relacionados con el servicio de pago de peajes electrónicos a través de la cuenta de prepago con cargo recurrente estará condicionada al cumplimiento de los requisitos establecidos por la Superintendencia Financiera y a su manejo a través de entidades vigiladas por esa superintendencia;

c) Pago inmediato: El intermediador activa al usuario un dispositivo TAG RFID cargando inmediatamente el costo de los pasos a su medio de pago, tarjeta de crédito, u otro producto financiero en el momento del paso. En este caso específico, el usuario y/o consumidor debe contar con un producto financiero que respalde la activación y uso del dispositivo TAG RFID;

d) Pospago: El intermediador activa al usuario y/o consumidor un dispositivo TAG RFID cargando el costo de los pasos con posterioridad a la prestación del servicio de recaudo electrónico de peaje o cualquier otro servicio acordado entre el intermediador y el usuario. En este caso específico, el usuario y/o consumidor debe contar con un producto financiero que respalde la activación y uso del dispositivo TAG RFID.

PAR. 1º—El intermediador podrá ofrecer cualquier otra modalidad de pago siempre y cuando se cumpla con la regulación establecida por las autoridades competentes. Los intermediadores que ofrezcan productos del sistema financiero deberán haber obtenido los permisos y habilitaciones pertinentes de conformidad con la normatividad vigente.

PAR. 2º—El intermediador que no esté habilitado para prestar servicios de intermediación financiera o no lo haga a través de un contrato, asociación, o convenio con una entidad financiera para que sea esta última la que realice el recaudo de recursos de los usuarios y/o consumidores en la modalidad prepago simple y prepago recurrente, solamente podrá ofrecer aquellas modalidades de pago para las que se encuentre habilitado legalmente. En dicho caso, los recursos recaudados por concepto del pago electrónico del peaje deberán ser garantizados a través de encargos fiduciarios o cualquier otro mecanismo que asegure que los recursos recaudados por concepto del pago electrónico del peaje no podrán ser utilizados o destinados por el intermediador para realizar pagos diferentes a esa destinación.

El esquema fiduciario de administración aquí previsto no aplicará para aquellos casos en que el intermediador sea una entidad bancaria u otro tipo de establecimiento de crédito definido en el artículo 2º del estatuto orgánico del sistema financiero (D. 663/93 y sus modificaciones).

TÍTULO VII

Inspección, vigilancia y control

ART. 29.—De la inspección, vigilancia y control. En relación con el régimen de protección a los usuarios y/o consumidores, la protección de la competencia y los derechos de las personas asociadas al manejo de bases de datos, así como las otras competencias relativas a la cadena de distribución, comercialización y utilización para el uso de los servicios de peajes electrónicos, la entidad competente para la inspección, vigilancia y control de estas actividades es la Superintendencia de Industria y Comercio en los términos de la Ley 1480 de 2011 y del Decreto 4886 de 2011, o las normas que las modifiquen, adicionen o sustituyan.

Así mismo, los actores estratégicos que intervengan en la cadena se encontrarán sujetos a sus propios regímenes, reglas legales y contractuales y a las entidades de inspección, vigilancia, control y regulación que les sean obligatorias.

TÍTULO VIII

Otras disposiciones

ART. 30.—Suministro de información. Los actores estratégicos que están debidamente certificados para ejercer un rol en el sistema de recaudo electrónico vehicular IP/REV, deberán tener permanentemente a disposición de las entidades de inspección, vigilancia y control, el Ministerio de Transporte, entidades que ejerzan como concedentes y demás autoridades de control, las estadísticas, libros, documentos, bases de datos generadas en la operación del sistema y demás elementos que permitan validar y verificar los requisitos e información suministrada. Aquellas informaciones sujetas a confidencialidad de conformidad con las normas vigentes seguirán las reglas allí establecidas para su tratamiento.

ART. 31.—Garantías de responsabilidad civil. Los actores estratégicos que estén debidamente certificados para ejercer un rol en el sistema de recaudo electrónico vehicular IP/REV, deben tomar por cuenta propia con una compañía de seguros autorizada para operar en Colombia, pólizas de seguro de responsabilidad civil que amparen los riesgos inherentes a la actividad de cada actor estratégico, de conformidad con el rol que ejerza, la cual deberá cubrir al menos los siguientes riesgos:

a) Operador IP/REV (OP IP/REV): Seguro de responsabilidad civil que ampare los daños y perjuicios que se causen a terceros, entendiéndose también por terceros los usuarios y/o cualquier vehículo o sus pasajeros, como consecuencia de su actividad como operador IP/REV. Este seguro debe cubrir un monto mínimo de mil quinientos salarios mínimos mensuales legales vigentes (1.500 smmlv) y debe contar con el amparo de gastos médicos, quirúrgicos, farmacéuticos y hospitalarios. En caso de ya poseer pólizas de seguros, que cubran estas responsabilidades, el solicitante deberá presentar una certificación en la que consten las coberturas y los montos exigidos.

Cuando el operador sea el mismo concesionario vial, el requisito de este seguro podrá ser acreditado a través del seguro de responsabilidad civil que debe tomar en el contrato de concesión en los términos del artículo 2.2.1.2.3.1.8 del Decreto 1082 de 2015 o de la norma que lo modifique, adicione o sustituya, siempre y cuando en el seguro se ampare de manera expresa la responsabilidad derivada de su actividad como operador IP/REV.

El OP IP/REV debe mantener vigente este seguro durante el período de su certificación como operador y dos (2) años más;

b) Intermediador IP/REV (INT IP/REV): Seguro de responsabilidad civil que ampare los daños y perjuicios que se causen a los usuarios y/o consumidor como consecuencia de su actividad como intermediador IP/REV por un monto mínimo de quinientos salarios mínimos mensuales legales vigentes (500 SMMLV).

Adicionalmente, debe adquirir una póliza de seguros de infidelidad y riesgos financieros que cubra los actos dolosos de sus empleados que se conviertan en pérdidas económicas para el asegurado, por un monto mínimo de mil quinientos salarios mínimos mensuales legales vigentes (1.500 smmlv).

El INT IP/REV debe mantener vigente estos seguros durante el período de su certificación como operador.

PAR. 1º—Las garantías mencionadas en el presente artículo así como aquella establecida en el parágrafo 2º del artículo 28, deberán ser constituidas y entregadas al Ministerio de Transporte dentro de los treinta (30) días calendario siguientes a la fecha en que el operador y/o Intermediario sea certificado. Las garantías deberán constituirse teniendo como asegurado y beneficiario al Ministerio de Transporte, en los términos y condiciones establecidos para el rol al que fue certificado el operador/ intermediador.

ART. 32.—Servicios de intermediación. Los intermediadores podrán ofrecer servicios de integración y/o conectividad a otros participantes del sistema IP/REV que no deseen conectarse de forma directa con todos los operadores. En este caso, serán los intermediadores que presten los servicios de integración y/o conectividad los que responderán por la prestación del servicio de REV en las condiciones definidas en la presente resolución para el intermediador que provee el servicio.

ART. 33.—Régimen de transición. Todos los concesionarios viales tendrán un plazo máximo de un 1 año para implementar el sistema IP/REV y obtener su certificación como operador, contados a partir del día siguiente de la publicación de la presente resolución.

En todo caso los concesionarios viales deberán adelantar ante la entidad concedente, todos los trámites necesarios para la migración e implementación del sistema IP/REV, según sea el caso.

Vencido el término del régimen de transición aquí previsto, el servicio de recaudo electrónico vehicular (REV) de peajes electrónicos solo podrá ser prestado por los actores estratégicos que estén debidamente certificados por el Ministerio de Transporte y cumplan las condiciones establecidas en esta resolución.

PAR.—Para aquellos peajes que reviertan al Invías con posterioridad a la fecha de expedición de la presente resolución y antes de la finalización del plazo previsto en el presente artículo, el plazo máximo de un (1) año será contado a partir del día siguiente a la fecha en que se legalice la reversión.

ART. 34.—Vigencia. La presente resolución rige a partir de su publicación en el Diario Oficial y deroga las resoluciones 4303 de 2015, 3779 y 5708 de 2016.

Publíquese y cúmplase.

Dada en Bogotá, D.C., a 9 de marzo de 2018.

Anexo técnico 1

Sistema de interoperabilidad de peajes y recaudo electrónico vehicular (IP/REV) para Colombia

I. Lista de abreviaturas

ANI: acrónimo de Agencia Nacional de Infraestructura.

ConOps: acrónimo de concepto de operación.

COP: acrónimo de centro de operación del peaje.

DB: del inglés Data Base. En español, Base de Datos.

Ditra: acrónimo de Dirección de Tránsito y Transportes de la Policía Nacional.

EFC: del inglés Electronic Fee Collection, Recaudo Electrónico

EMC: del inglés Electromagnetic Compatibility, Compatibilidad Electromagnética

EPC: del inglés Electronic Product Code. Código de producto Electrónico

FIPS: del inglés Federal Information Processing Standard, estándar de procesamiento de información federal

INVÍAS: acrónimo de Instituto Nacional de Vías.

ITS: del inglés Intelligent Transportation Systems.

IP/REV: Interoperabilidad de Peajes con Recaudo electrónico vehicular.

ISO: del inglés International Standard Organization.

JSON: del inglés javascript object notation, formato ligero de intercambio de datos

MT: Ministerio de Transporte de Colombia.

MTBF: del inglés Mean Time Between Failures o Media Aritmética de Tiempo entre Fallas.

NTC: Norma Técnica Colombiana

NTP: del inglés Network Time Protocol. Protocolo de Sincronización de tiempo

OBU: del inglés On Board Unit o Unidad a Bordo.

PQR: Peticiones, quejas y reclamos

RETIE: Reglamente técnico de instalaciones eléctricas

REV: acrónimo de recaudo electrónico vehicular.

RFID: del inglés Radio-Frequency Identification. Identificación por radiofrecuencia.

RUNT: acrónimo de registro único nacional de tránsito.

SI: acrónimo de sistema de información.

SiGT: Subsistema para la gestión de transacciones a través de RFID.

SINITT: acrónimo de sistema inteligente nacional para la infraestructura, el tránsito y el transporte.

SIT: acrónimo de sistemas inteligentes para la infraestructura, el tránsito y el transporte.

SUPERFINANCIERA: Superintendencia Financiera de Colombia.

SUPERINDUSTRIA: Superintendencia de Industria y Comercio.

SUPERTRANSPORTE: Superintendencia de Puertos y Transporte.

TAG: véase TAG RFID.

TAG RFID: en español etiqueta de RFID

TID: del inglés Tag ID, Identificador de la etiqueta RFID.

TIE: acrónimo de tarjeta de identificación electrónica.

II. Definiciones

ConOps: Concepto de operación del sistema. Es una definición inicial del sistema a partir de las necesidades, expectativas y requerimientos de los actores estratégicos. Documenta cómo el sistema previsto va a operar y cómo el sistema cumplirá con las necesidades y expectativas de las partes interesadas.

Clonación de TAG: duplicación indebida de un dispositivo TAG RFID tomando toda la información de otro dispositivo TAG RFID legalmente expedido.

Dispositivo a bordo: del inglés On Board Unit (OBU). Es el equipo electrónico instalado en un vehículo, utilizado para interactuar con los sistemas inteligentes para la infraestructura, el tránsito y el transporte o con los subsistemas de información para la gestión. Para el caso específico de peajes electrónicos en Colombia se considera el dispositivo a bordo como la etiqueta de radiofrecuencia (TAG RFID) según el estándar ISO 18000-63.

Emulación de TAG: activación indebida de la información de un dispositivo TAG RFID legalmente expedido, utilizando un medio electrónico diferente a los dispositivos TAG RFID.

Falsificación de TAG: acción o efecto de falsificar, que consiste en alterar o simular la verdad respecto del origen e interoperatibilidad del TAG con fines contravensionales.

Peaje IP/REV: peaje que cuenta con uno o más carriles IP/REV.

SIT: acrónimo de sistemas inteligentes para la infraestructura, el tránsito y el transporte. Internacionalmente se le denomina Intelligent Transportation Systems (ITS) e involucran todos los sistemas inteligentes para la infraestructura, el tránsito y el transporte.

Son un conjunto de soluciones tecnológicas, diseñadas para hacer más eficiente, seguro, cómodo y sostenible la infraestructura, el tránsito, el transporte y la movilidad en general.

TID: Es el número único que se le asigna a cada etiqueta RFID en el momento de su fabricación.

Introducción

El sistema de interoperabilidad de peajes con recaudo electrónico vehicular IP/ REV contempla una serie de tecnologías inalámbricas y cableadas para el intercambio de información, entre un dispositivo instalado a bordo del vehículo y un elemento de infraestructura fija instalado en un pórtico, de manera que, el usuario IP/REV no debe detener completamente su vehículo para realizar el pago de la tarifa de peaje.

Para lograr esto, el presente anexo tiene requisitos que deben ser cumplidos por los intermediadores IP/REV y operadores IP/REV, para obtener y mantener la certificación.

CAPÍTULO 1

Concepto de operación

1.1. Generalidades.

El presente capítulo describe el concepto de operación (ConOps) del sistema para la interoperabilidad de peajes y el recaudo electrónico vehicular (IP/REV). El ConOps es una definición inicial del sistema a partir de las necesidades, expectativas y requerimientos de los actores estratégicos. En el desarrollo de esta tarea se documenta el mecanismo actual de funcionamiento del sistema de peajes en Colombia, se establece el modelo de operación del sistema IP/REV a 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.

1.2. Objetivo general del sistema de interoperabilidad de recaudo electrónico vehicular IP/REV.

Implementar un mecanismo a nivel nacional que permita a cualquier usuario con un contrato de prestación de servicio, pagar electrónicamente la tarifa de peaje sin la demora asociada al pago en efectivo en carriles manuales; y permitir a cualquier operador, recibir el pago correspondiente sin importar el intermediador con el que el usuario del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV) tenga suscrito el contrato.

1.2.1. Objetivos específicos del sistema.

• Disminuir el tiempo de paso de los vehículos por los peajes y los tiempos de viaje.

• Ahorro de costos CAPEX y OPEX a los operadores del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (OP IP/REV), tanto en infraestructura civil como tecnológica, al permitir una operación más ágil y segura.

• Facilitar las actividades de supervisión de las condiciones acordadas dentro del contrato de concesión de vías.

• Mejorar el servicio al cliente de los usuarios de la red de peajes.

• Optimizar el proceso de cobro de tarifa de peaje y reducir el costo de operación a través del uso de la tecnología.

• Implementar un mecanismo de interoperabilidad basado en la aplicación de estándares ITS internacionales a la operación del sistema de IP/REV, entre ellos ISO 17573:2010, ISO 17575:2011, e ISO 16410:2012.

• Garantizar que los concesionarios viales perciban de manera oportuna y segura todos los pagos de tipo IP/REV ocasionados en sus peajes.

• Disminuir el manejo de dinero en efectivo para el pago de las tasas de peaje.

1.3. Alcance.

Este capítulo describe las características del sistema IP/REV, identificando los principales actores estratégicos, sus roles y responsabilidades asociadas. Asimismo, aquí se presentan los componentes principales, las interacciones entre los actores estratégicos y estos componentes; y el flujo de información correspondiente.

1.3.1. Descripción general del sistema.

En el desarrollo de este capítulo se presenta el sistema de recaudo electrónico vehicular (IP/REV), mediante el cual un usuario IP/REV de la red vial podrá circular por todo el territorio nacional, pasando por los diferentes peajes que se encuentren dentro de la red de interoperabilidad, sin detenerse por completo y con un único dispositivo en su vehículo. Teniendo en cuenta que en las diferentes regiones del país los peajes son operados, directa o indirectamente, por diferentes concesiones viales; lo anterior requerirá un modelo de funcionamiento que garantice la interoperabilidad. Este modelo, que permitirá lo que en adelante llamaremos sistema interoperabilidad de peajes con recaudo electrónico (IP/ REV), también será descrito en el presente capítulo.

1.3.2. Visión y objetivos del sistema.

A continuación, se presenta la visión del sistema de IP/REV

1.3.2.1. Visión del sistema.

El Ministerio de Transporte proyecta que todos los peajes sean interoperables y cualquier usuario IP/REV tenga la posibilidad de pagar electrónicamente la tarifa de peaje en cualquier parte del territorio nacional, con un único dispositivo RFID a bordo y asociado a una figura contractual que se adopte el intermediador IP/REV.

Para tal efecto, el usuario suscribirá un contrato con un Intermediador IP/REV del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (INT IP/REV), debidamente certificado para este fin.

Para todos los medios de pago el intermediador deberá informar periódicamente al usuario de las condiciones, tarifas y demás relacionados con los servicios prestados, acorde a lo establecido en el cuerpo de la resolución.

Para la suscripción del contrato, el intermediador deberá verificar en el SiGT o el sistema que el Ministerio de Transporte destine a tal fin, que el vehículo no tenga un TAG RFID activo asociado.

Una vez suscrito el contrato, el intermediador entregará al usuario del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV) una etiqueta RFID adhesiva, que será pegada en el parabrisas del vehículo del usuario por este mismo siguiendo las indicaciones dispuestas por el intermediador, o por personal del mismo, siendo en todo caso responsabilidad del intermediador que quede correctamente instalado. Al pasar por un carril del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV), el lector RFID instalado en la infraestructura de dicho carril detectará el número del TAG RFID y con base en esta información, y en la configuración del vehículo detectada por tecnologías de apoyo, se determinará la categoría del vehículo, y por lo tanto, la tarifa de peaje a cobrar. Dicha tarifa de peaje a cobrar por el operador será reportada al intermediador del dispositivo TAG RFID, que actualizará y gestionará el saldo de la cuenta asociada a la misma, y transferirá la tarifa de peaje al patrimonio autónomo del operador correspondiente, y cobrará la comisión acordada al operador y los costes transaccionales asociados al proceso.

1.4. Documentos de referencia.

En esta sección se exponen los estándares de tecnología y telemática que se aplican en el contexto y análisis del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV). Además, se presentan documentos adicionales que están relacionados con la identificación de la arquitectura del sistema, identificación de actores estratégicos y roles y la evaluación del sistema.

1.4.1. ISO 18000-63/2013: Information Technology - Radio Frequency Identification for item management.

El Gobierno Nacional, a través del Decreto 2846 de 2013 adoptó el estándar norma ISO/IEC 18000-63 (Parameters for air interface communications at 860 MHz to 960 MHz Type C). Por tal motivo, los equipos basados en tecnología RFID empleados para la detección de vehículos en sistemas de recaudo electrónico deberán cumplir con este estándar.

1.4.2. ISO 17573/2010: Electronic Fee Collection (EFC) - systems architecture for vehicle-related tolling.

El estándar ISO 17573:2010 involucra las nuevas arquitecturas desarrolladas para peajes en proyectos europeos, y por otro lado, sirve como referencia para los estándares relacionados con REV (del inglés EFC). Utiliza los conceptos y términos del estándar Open Distributed Processing (ODP ISO 10746), el cual provee la terminología y las herramientas necesarias para el modelado de sistemas EFC incluyendo equipos, protocolos, interfaces y roles asociados. Es así como, la norma define la arquitectura de un sistema de peaje del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV), de tal forma que un usuario pueda utilizar su vehículo en una variedad de dominios de peaje con un operador diferente en cada dominio.

1.4.3. ISO 17575/2011: Electronic Fee Collection (EFC) - application interface definition for autonomous systems.

Este estándar cumple con la arquitectura de negocios definida en ISO 17573:2010. Define el intercambio de información entre front-end y back-end del sistema IP/REV basado en equipos autónomos a bordo. A continuación, se presentan las partes componentes del estándar:

• ISO 17575-1: cobro. Define los atributos para la transferencia de datos utilizados entre el front-end hacia el back-end. Los atributos requeridos variarán de un peaje a otro. Por lo tanto, se deberán contemplar todos los requisitos, que van desde los datos de localización (para ubicación geográfica) a las transacciones de peaje con los precios previamente estipulados.

• ISO 17575-2: comunicación y conexión con las capas inferiores. Define los servicios básicos de comunicación para la transferencia de datos a través del enlace aéreo, o entre front-end y back-end.

• ISO 17575-3: contexto de datos. Define los datos que se utilizan para obtener una descripción de los sistemas de cobro individuales en términos de objetos de ubicación geográfica, además de las reglas para el cobro y presentación de reportes. Para el caso de todos los operadores del sistema, los atributos definidos en la parte 3 se utilizan para transferir datos al front-end con el fin de definir los datos que se recogen y los reportados.

• ISO 17575-4: roaming. Define los detalles funcionales y elementos de datos necesarios para operar más de un IP/REV en paralelo. Los dominios de estos regímenes IP/REV pueden o no superponerse. Las reglas de carga de datos de diferentes regímenes IP/REV superpuestas pueden estar vinculadas, es decir, pueden incluir normas que rijan para un área superpuesta al peaje de toda la vía, y deberá considerar si ya efectuó el pago por ese derecho de paso.

1.4.4. ISO 16410/2012: Electronic Fee Collection (EFC) - evaluation of equipment for conformity to ISO/TS 17575-3.

El objetivo de este estándar es proporcionar una base para realizar las pruebas en el front-end y en el back-end, en el sistema IP/REV soportado por equipos autónomos a bordo, de conformidad con ISO/TS 17575-3 y permitiendo la interoperabilidad entre diferentes equipos suministrados por diferentes fabricantes.

1.4.5. ISO/TR 12859/2009 - Intelligent Transport Systems - system architecture - Privacy aspects in ITS standards and systems.

Esta norma parte de la presunción de que los sistemas inteligentes para la infraestructura, el tránsito y el transporte están ligados al movimiento e intercambio de información. En algunos casos puede incluir información personal del usuario.

De esta forma, la norma se debe analizar en el contexto del ordenamiento positivo colombiano y la jurisprudencia vigente en materia del habeas data, habida cuenta que el reporte técnico como tal se originó en discusiones sobre el ISO/TC 204 y en CEN TC 278 (con los subsecuentes estudios legales realizados en Austria), en lo concerniente al uso de la información personal en materia de ITS.

En este sentido, la norma menciona aspectos que se deben considerar al momento de implementar un ITS:

• Brindar atención al procesamiento, transmisión y almacenamiento de la información sin autorización del usuario al acceso de la misma teniendo en cuenta el potencial flujo de información a entidades externas que pueden resultar implicadas en el procesamiento mismo de la información.

• Consentimiento expreso del usuario de los términos y condiciones, con conocimiento de los riesgos de seguridad implícitos y los posibles tratamientos de la privacidad.

• Seguir el lineamiento del manejo de seguridad de la información establecido en el ISO/IEC 27000:2014, con especial referencia al ISO/IEC 27002:2013.

• Determinación explícita del tiempo de permanencia de la información recolectada por el sistema, cumpliendo exclusivamente con los propósitos del mismo. Anotando, a su vez, que toda la información recolectada debe ser adecuada, relevante y no debe exceder el propósito mismo del sistema para el cual está siendo procesada. De tal manera que esta información no puede ponerse a disposición de otros propósitos o usuarios que no cumplan el objeto mismo de su recolección.

1.4.6. ISO/TS 12855:2012 Electronic Fee Collection (EFC) - Information exchange between service provision and toll charging.

La norma ISO 12855:2012 especifica las interfaces entre sistemas para vehículos relacionados con servicios de transporte, como son los usuarios de peajes y control de acceso a parqueaderos. No contempla interfaces en sistemas de transporte público.

Provee las bases para cualquier servicio de peaje y para cualquier tecnología utilizada en el recaudo, por ejemplo, RFID, sistemas automáticos de reconocimiento de placas, entre otros. Se define como un estándar de transacciones y mensajes que pueden ser utilizados para los propósitos asignados.

1.4.7. GSD+: “Evaluación y definición del modelo de interoperabilidad comercial de la herramienta SIT de recaudo electrónico vehicular en apoyo a las políticas de logística y carga”.

En este documento se realiza una evaluación multicriterio de diferentes modelos de interoperabilidad comercial para proyectos IP/REV en Colombia. Como conclusión de esta evaluación, GSD+ recomienda al Gobierno Nacional optar por la implementación de la alternativa “Modelo de operación y prestación de servicios de peaje a cargo de diferentes actores estratégicos/organismos, y compensación de información tipo uno a uno”, en donde cada par recaudador-concesionario efectúa las transacciones necesarias para realizar los cobros/pagos sin que exista una cámara de compensación centralizada.

Este modelo general de interoperabilidad fue adoptado por el Ministerio de Transporte y es el punto de partida para el sistema IP/REV de Colombia, especificado en el presente documento.

1.5. Descripción general del sistema actual.

Esta sección presenta el sistema actual de peajes en Colombia contemplando la normativa vigente por la cual se rige, así como los actores estratégicos relacionados con el sistema.

1.5.1. Funcionamiento actual.

En esta sección se presenta de forma general el funcionamiento actual del entorno de operación de peajes en Colombia.

1.5.1.1. Diagrama representativo del funcionamiento actual.

De acuerdo a la normatividad vigente, el Ministerio de Transporte (MT) define las políticas de operación de peajes, Invías, ANI y las entidades territoriales son las encargadas de adoptar estas políticas y realizar la supervisión de la operación de sus peajes. Por otro lado, los usuarios utilizan la infraestructura vial y, a cambio, pagan una tarifa de peaje. En la figura 1 Esquema de funcionamiento actual de peajes en Colombia se presenta el esquema de funcionamiento actual de los peajes en Colombia, representando gráficamente las relaciones entre los actores estratégicos involucrados.

xxxxxxx

Figura 1. Esquema de funcionamiento actual de peajes en Colombia

Como complemento a la figura 1 Esquema de funcionamiento actual de peajes en Colombia, se incluye la tabla 1 Relaciones del esquema de funcionamiento actual de peajes, en la cual se presentan las relaciones existentes entre un actor A y un actor B del esquema de funcionamiento actual de peajes en Colombia.

# Actor A Actor B Conexión
1 MT Invías (1) Establece políticas. (2) Define reglas de operación. (3) Emite conceptos vinculantes para la localización de peajes.
ANI
2 Invías ANI (1) Invías envía listado de vehículos exentos del pago de tarifa a la ANI. (2) Solicita información de volúmenes y recaudo.
3 ANI INVÍAS (1) Realiza reversión de tramos concesionados. (2) Solicita información de volúmenes y recaudo.
4 ANI Concesionario de la ANI (1) Recibe información de volúmenes y recaudo. (2) Establece las condiciones del contrato de concesión.
5 Invías Concesionario de la ANI (1) Recibe información de volúmenes y recaudo. (2) Establece las condiciones del contrato de concesión.
6 Usuario ANI (1) Realiza peticiones, quejas y reclamos. (2) Solicita el beneficio de tarifa especial para una estación de peaje del concedente.
INVÍAS
7 Usuario Concesionario del Invías 1) Realiza peticiones, quejas y reclamos relacionados con la prestación del servicio. (2) Realiza el pago en las estaciones de peaje.
Concesionario de la ANI
8 Invías Usuario (1) Otorga permisos de circulación para vehículos de carga extra dimensionados o extra pesados. (2) Otorga exención del pago de la tarifa de peajes a nivel nacional. (3) Otorga tarifa especial a un ciudadano que cumpla con lo establecido por la Resolución 228 de 2013.
9 Supertransporte Concesionario de la ANI (1) Realiza inspección, vigilancia y control a la prestación del servicio de peaje. (2) Realiza inspección, vigilancia y control a los términos del contrato de concesión.
Concesionario del Invías
10 Ditra RUNT (1) Consulta información vehicular
11 Invías RUNT (1) Consulta información del RUNT para validar los requisitos para tarifas especiales y exención de tarifas.

# Actor A Actor B Conexión
12 Concesionario de la ANI Supertransporte (1) Reporta irregularidades.
Concesionario del Invías
13 Concesionario del InvíasDitra (1) Realiza convenio para control operativo del tramo concesionado y de las estaciones de peaje. (2) Suministra material de apoyo a la Ditra para desempeñar el control operativo.
Concesionario de la ANI
14 Usuario Supertransporte (1) Reporta irregularidades
15 Ditra Secretaría de TYT (1) Reporta las infracciones al Código Nacional de Tránsito Terrestre cometidas. (2) Reporta las órdenes de comparendo expedidas a los infractores.
16 Interventor de contrato de la ANI Concesionario de la ANI (1) Verifica, mide y comprueba el cumplimiento de las condiciones del contrato de concesión firmado entre la ANI y sus concesionarios.
17 Interventor de contrato del Invías Concesionario del Invías (1) Verifica, mide y comprueba el cumplimiento de las condiciones del contrato de concesión firmado entre el INVÍAS y su concesionario.

Tabla 1. Relaciones del esquema de funcionamiento actual de peajes.

1.5.1.2. Procesos operacionales actuales.

A continuación, se presentan algunos procesos operacionales actuales más relevantes dentro de la operación de peajes.

Peticiones, quejas y reclamos (PQR). El usuario de un peaje, como su nombre lo indica, al ser usuario de un servicio (pago) cuenta con canales y entidades encargadas de atenderlo y responderle sus inquietudes y observaciones. De esta forma, si al usuario se le presenta alguna irregularidad con el servicio o la tarifa cobrada, o simplemente tiene alguna duda con algún procedimiento, puede ir ante las siguientes entidades y realizar PQR (Peticiones, quejas y reclamos):

• ANI, INVÍAS, ET.

• Concesionarios u OP IP/REV (ANI, INVÍAS, ET).

• INT IP/REV

• Superintendencia de Puertos y Transporte.

Inspección, vigilancia y control a la prestación del servicio de peaje. La Superintendencia de Puertos y Transporte es la entidad encargada de realizar los procesos de inspección, control y vigilancia en los concesionarios de Invías, ANI y ET. Para ello, realiza la supervisión de los contratos de concesiones viales, supervisa el estado y la calidad de la infraestructura de las concesiones viales, supervisa la formación y constitución de las empresas a las que se otorgan las concesiones viales; y supervisa el desarrollo legal en el tiempo de las concesiones viales. Adicionalmente, la Superintendencia de Puertos y Transporte recibe las PQR de los usuarios y concesionarios.

Control operativo Ditra. La Ditra suscribe convenios con el Invías y la ANI, para realizar el control operativo de sus tramos concesionados y de sus estaciones de peaje. En el marco de esos convenios, el INVÍAS y la ANI suministran material de apoyo a la Ditra para desempeñar esta función. La Ditra reporta a las secretarías de tránsito y transporte las infracciones al Código Nacional de Tránsito Terrestre cometidas por los usuarios. De igual manera, reporta las órdenes de comparendo expedidas a los infractores.

1.6. Requerimientos operacionales del sistema IP/REV.

A continuación se presentan los requerimientos operacionales del Sistema IP/REV, que deberán ser cumplidos a cabalidad por los actores estratégicos del Sistema IP/REV.

1.6.1.1. Esquema de color de los dispositivos TAG RFID.

Los TAG RFID deberán ser de color blanco o transparentes, con el logotipo de la marca COLPASS registrado en la Superintendencia de Industria y Comercio (SIC), bajo la Resolución 100236 de 2015, impreso en la cara anterior (lado visible al interior del vehículo), con un tamaño no menor al 20% del ancho del TAG RFID, acorde con la orientación con que se debe instalar al interior del vehículo. Igualmente, deberá tener impreso un teléfono de contacto del intermediador y el código EPC grabado en el TAG, la descripción y uso de la marca se establecen en el anexo 3 de la presente resolución.

1.6.1.2. Validación offline de los dispositivos TAG RFID.

Al ser el dispositivo TAG RFID un dispositivo pasivo y no estar obligado a portar más información que un número de identificación, la validación de la información adicional (p.e., estado, tipo de contrato, saldo) se debe hacer mediante una conexión a los diferentes INT IP/REV.

Previendo una eventual intermitencia en el canal de comunicación o una conexión con alto tiempo de latencia, se debe mantener en cada COP (y plaza de peaje con sus carriles IP/REV) una copia de la lista consolidada de dispositivos TAG RFID enviada por los diferentes INT IP/REV certificados, de tal forma que se pueda decidir oportunamente si un vehículo puede pasar por el carril del sistema de interoperabilidad de peajes con recaudo electrónico vehicular IP/REV. Sin embargo, si por causas imputables a los operadores IP/REV o las conexión entre este y los intermediadores IP/REV no es posible identificar el TAG del usuario IP/REV, se deberá implementar un mecanismo de identificación que permita el paso del usuario IP/REV siguiente las condiciones establecidas en el anexo 5 - Oferta básica de interoperabilidad, y por consiguiente en los contratos entre los usuarios y los intermediadores se deberá contemplar el pago de la tarifa de peaje cuando el sistema se encuentre desactualizado u offline.

1.6.1.3. Certificación de servicios de información al usuario IP/REV.

Se identifica la necesidad de que el OP IP/REV implemente en el carril IP/REV, paneles de mensajería variable como sistema de notificación a los usuarios IP/REV del peaje para informar el valor de la tarifa cobrada e información de saldo bajo en caso de que esta se presente.

Además, el INT IP/REV deberá habilitar una interfaz (página web, aplicación móvil o cualquier otro servicio de consulta) para que el usuario IP/REV pueda consultar su saldo y el historial de pagos realizados, acorde a los especificado en el cuerpo de la resolución, incluyendo otros servicios de información que considere el Ministerio de Transporte que deban ser certificados por parte del intermediador.

1.6.1.4. Sistema de clasificación de vehículos y cámaras de reconocimiento de placas.

El OP IP/REV deberá disponer de un sistema de clasificación de vehículos que permita determinar la categoría a la que pertenece un vehículo en el momento de transitar por el carril IP/REV. Esta información deberá ser contrastada con la información del vehículo que fue descargada desde los INT IP/REV. También debe disponer de un sistema de reconocimiento de placas en cada uno de los carriles IP/REV. Los caracteres reconocidos deben igualmente ser comparados con la información del vehículo que haya sido descargada desde los INT IP/REV.

1.6.1.5. Acceso a la información de los centros de control.

Los OP IP/REV y los INT IP/REV deberán enviar copia o pondrán a disposición del SiGT o sistema designado por el Ministerio de Transporte, toda la información que produzcan e intercambien entre ellos, listas blancas, listas negras, transacciones realizadas, etc.

1.6.1.6. Selección de combinación de métodos de pago por vía.

La decisión del diseño y configuración óptima del número y tipo de vías de una estación de peaje de acuerdo a los parámetros de tráfico esperado durante el tiempo de concesión es del concesionario.

Sin embargo, para asegurar el esquema de interoperabilidad de peaje de recaudo electrónico vehicular IP/REV, se exige como mínimo un carril mixto IP/REV por sentido que sea capaz de procesar todas las categorías de vehículos.

De igual manera, es responsabilidad del concesionario u OP IP/REV el seleccionar la configuración más eficiente de cada vía de una estación de peaje teniendo en cuenta los niveles de servicio que se fijarán mediante resolución por parte del Ministerio de Transporte.

Lo anterior sin perjuicio del cumplimiento de las condiciones de prestación del REV establecidas en algunos contratos de concesión para el diseño de las plazas de peajes.

Como proyección a mediano plazo, cuando la penetración en el mercado del dispositivo TAG RFID haya alcanzado un nivel suficiente, el concesionario u OP IP/REV podrá considerar bajo su responsabilidad nuevos y más eficientes diseños de los peajes existentes, o alternativas de peaje con tecnología Multi Lane Free Flow —MLFF— (Flujo Libre Multi carril).

1.6.1.7. (Modificado).* Definición del tiempo de retención de la información.

La información que se almacena en los sistemas inteligentes, además de tener potencial para la supervisión y conocimiento del sector, así como soportar la generación de políticas, puede ser empleada como prueba o material de apoyo en caso de procesos judiciales (investigación de accidentes de tránsito, hurtos, entre otros).

El Ministerio de Transporte define como termino de retención de la información el término de cinco (5) años para el almacenamiento de información, imágenes, videos, entre otros.

*(Nota: Modificado por la Resolución 3254 de 2018 artículo 3° del Ministerio de Transporte)

1.6.1.8. Protocolo de pasos con pago por otros medios.

Existe la posibilidad de que se presenten situaciones en las que el usuario IP/REV no pueda completar el pago electrónico por situaciones ajenas al OP IP/REV:

— Falta de saldo.

— Errores en la lectura del dispositivo TAG RFID, incluyendo un posible mal funcionamiento del mismo.

En ambos casos, el vehículo será desviado a un carril de pago manual y el paso será procesado como paso regular con la correspondiente modalidad de pago.

El OP IP/REV debe tener forma de asegurar que no se está produciendo un fallo en el lector de carril IP/REV con, al menos, otro lector instalado en otra vía, un lector portátil, o cualquier otro método, de lo contrario deberá dejar pasar al usuario, que puede no tener —o querer utilizar— otro medio de pago para satisfacer la tarifa de peaje.

1.6.1.9. Asignación de códigos únicos de identificación de plazas y carriles IP/REV.

La asignación de los códigos de identificación únicos para plazas y carriles IP/REV se hace necesaria para la asociación del paso de un vehículo por una determinada estación de peaje.

El Ministerio de Transporte efectuará la asignación de estos códigos de identificación para las diferentes plazas de peaje y de sus carriles IP/REV, previo a la entrada en funcionamiento del sistema IP/REV.

1.7. Descripción general del sistema IP/REV.

Esta sección describe el funcionamiento del sistema para la interoperabilidad de peajes y recaudo electrónico vehicular (IP/REV), el cual permitirá cumplir con la visión y los objetivos planteados. De esta forma, se seguirá manteniendo los procesos administrativos y operativos existentes, a la vez que se incorporan nuevos procesos y actores estratégicos para el funcionamiento del sistema IP/REV, de acuerdo a lo que se presenta en esta sección.

Para el funcionamiento del sistema de la interoperabilidad en modalidad IP/REV es necesario asegurar el intercambio de la información relevante entre los principales actores estratégicos, en particular, entre OP IP/REV de peaje (información de cobro por uso de la vía) y los Intermediarios (información de pagos —pre o post— por tarifa de peaje).

Confidencialidad de la información: el criterio seguido para garantizar la privacidad de la información (habeas data) del usuario IP/REV, es el de separar la información personal del usuario IP/REV y la información del dispositivo TAG RFID que se instala en el vehículo, de igual manera se deben cumplir las condiciones establecidas en el cuerpo de la presente resolución.

Compatibilidad con la tecnología en uso: El Decreto 2846 de 2013 adopto el estándar internacional ISO 18000-63, es por esto que las soluciones tecnológicas que se implementen deberán garantizar la compatibilidad de las antenas, TAG, etc.

Escalabilidad: con base en el crecimiento del parque automotor colombiano previsto por el Ministerio de Transporte, y la adopción proyectada del sistema IP/REV, el modelo de funcionamiento considerara la escalabilidad del sistema de tal forma que garantice la calidad del servicio.

1.7.1. Funcionamiento del sistema.

A continuación, se presenta la secuencia regular de actividades para el funcionamiento del sistema IP/REV:

• El usuario adquiere un TAG mediante un contrato asociándolo a una modalidad y medio de pago con un intermediador IP/REV. Cuando un usuario se registra ante un intermediador del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (INT IP/REV), debe proveer la información relacionada al vehículo.

• La entidad intermediadora del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (INT IP/REV) valida la información del vehículo con los documentos aportados por el usuario y realiza la activación del dispositivo TAG RFID ligada a un único vehículo usando su número de placa.

• Una vez se instale correctamente el dispositivo TAG RFID en el vehículo, el usuario queda en capacidad de transitar por los peajes con carriles del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV).

• Cada intermediador IP/REV envía a todos los operadores IP/REV, y al SiGT, o sistema o subsistema designado por el Ministerio de Transporte, la información de los dispositivos TAG RFID activados, los tipos de contrato correspondientes, los saldos asociados, número de placa, categoría del vehículo, y demás información que se necesaria para la operación de los peajes.

• Los OP IP/REV actualizan la información de los usuarios IP/REV y sus dispositivos TAG RFID en su base de datos a partir de la información descargada de todos los intermediadores del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (INT IP/REV).

• Cuando un vehículo se acerca a un carril IP/REV se realiza la lectura del dispositivo TAG RFID. Se consulta la base de datos de carril del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV), y se comprueba si el TAG esté en la lista de habilitados (lista blanca) y no esté en lista negra, y si es pre o pospago, y caso de ser prepago, si tiene saldo para pagar la tarifa con que viene registrado dicho TAG. Los periféricos del carril anotan la placa del vehículo y detectan la categoría del mismo (bien con pre con post clasificación), y de acuerdo a ésta, define la tarifa a cobrar. La plaza de peaje envía al COP la información de los pasos realizados. El sistema de peaje del operador de interoperabilidad de peajes con recaudo electrónico vehicular (OP IP/REV) resuelve las posibles discrepancias de categoría y determina las tarifas correspondientes a cada paso. Cada operador envía a cada Intermediador el reporte de los pasos realizados y las tarifas asociadas a sus clientes TAG RFID.

• Los intermediadores IP/REV actualizan la información relacionada con los pasos y tarifas reportadas por los operadores IP/REV (y que corresponden a dispositivo TAG RFID activados por la entidad) y actualizan los saldos de las cuentas asociadas a cada TID reportado.

• Los usuarios del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV) pueden realizar recargas (contrato prepago) o pagos (contrato pago inmediato o pospago) de la cuenta asociada al dispositivo TAG RFID a través de los canales definidos por los intermediadores acorde a las condiciones establecidas en el cuerpo de la presente resolución (personales, electrónicos).

• Los intermediadores actualizan las listas de saldos y las envían a todos los OP IP/ REV, y al SiGT, o sistema o subsistema designado por el Ministerio de Transporte, junto con las novedades relacionadas (activación de nuevos dispositivos TAG RFID, dispositivos TAG RFID inactivos).

• Los operadores IP/REV e intermediadores IP/REV realizarán los pagos y compensaciones económicas acorde a las condiciones establecida para ello en la OBIP.

1.7.2. Roles.

En la tabla 2. Rol actual y a ejercer de los actores internos del sistema y tabla 3 Rol actual y futuro de los actores estratégicos externos del sistema se presentan los roles actuales y a ejercer de los actores del sistema de peajes. Estos actores se dividen en internos y externos. Los actores internos son aquellos que están directamente relacionados con el funcionamiento IP/REV. Los actores externos son aquellos que tienen asociadas labores de supervisión y control.

ACTORES INTERNOS ROL ACTUAL ROL A EJERCER
MINISTERIO DE TRANSPORTE ADMINISTRADOR ADMINISTRADOR
INVÍAS CONCEDENTE CONCEDENTE
CONCESIONARIO DE INVÍAS OPERADOR
RECAUDADOR
OPERADOR IP/REV
ANI CONCEDENTE CONCEDENTE
CONCESIONARIO DE ANI(1)OPERADOR
RECAUDADOR
(OP IP/REV)
ENTIDADES TERRITORIALES (ET) CONCEDENTE CONCEDENTE
CONCESIONARIO DE ET(2)OPERADOR
RECAUDADOR
OPERADOR IP/REV
ENTIDAD INTERMEDIADORA INTERMEDIADOR
USUARIO USUARIO USUARIO
SISTEMA DE GESTIÓN DE TRANSACCIONES (SiGT) o sistema o subsistema designado por el Ministerio de Transporte SISTEMA DE INFORMACIÓN ADMINISTRADO POR EL MINISTERIO DE TRANSPORTE
RUNT SISTEMA DE INFORMACIÓN SISTEMA DE INFORMACIÓN

Tabla 2. Rol actual y a ejercer de los actores internos del sistema.

ACTORES EXTERNOS ROL ACTUAL ROL A EJERCER
INTERVENTOR CONTRATO DE INVÍAS INTERVENTOR INTERVENTOR
INTERVENTOR CONTRATO DE ANI INTERVENTOR INTERVENTOR
INTERVENTOR CONTRATO DE ET INTERVENTOR INTERVENTOR
Ditra(3)APOYO APOYO
SUPERTRANSPORTE(4)INSPECCIÓN, VIGILANCIA Y CONTROL INSPECCIÓN, VIGILANCIA Y CONTROL
SUPERINDUSTRIA INSPECCIÓN, VIGILANCIA Y CONTROL(5)
SUPERFINANCIERA INSPECCIÓN, VIGILANCIA Y CONTROL
SECRETARÍAS DE TRÁNSITO Y TRANSPORTE (MOVILIDAD) SANCIONADOR SANCIONADOR

Tabla 3. Rol actual y futuro de los actores estratégicos externos del sistema.

A continuación, se definen cada uno de los roles dentro del IP/REV, de acuerdo con lo establecido en el estándar ISO-17573:

Cabe aclarar que los actores pueden ejercer más de un rol dentro del sistema de recaudo electrónico IP/REV(1)(2)(3)(4)(5).

1.7.2.1. Administrador.

Rol que ejerce el Ministerio de Transporte de Colombia, en concordancia con lo establecido en la Ley 1450 del 16 de junio del 2011, así como las demás disposiciones que la modifiquen o adicionen.

1.7.2.2. Operador IP/REV (OP IP/REV).

Véase definición en documento normativo.

1.7.2.3. Intermediador IP/REV (INT IP/REV).

Véase definición en documento normativo.

1.7.2.4. Usuario IP/REV.

Véase definición en documento normativo.

1.7.2.5. Inspección, vigilancia y control

Entidad pública que ejerza las labores de protección al usuario, supervisión, vigilancia y control de los actores estratégicos del sistema de recaudo electrónico vehicular —IP/ REV—. De forma adicional, se presenta una descripción de los siguientes roles, que no se encuentran definidos dentro del estándar ISO-17573, pero que hacen parte integral del esquema de funcionamiento IP/REV.

1.7.2.6. Concedente.

Entidad que funge como contratante en el desarrollo de contrato de concesión(6).

1.7.2.7. Interventor.

Persona natural o jurídica encargada de asegurar el cumplimiento técnico, financiero y administrativo del contrato durante su ejecución.

1.7.2.8. Sistema de información.

Corresponden a herramientas computacionales de apoyo para garantizar el funcionamiento del sistema de IP/REV. De acuerdo con el estándar ISO-17573 no se consideran como un rol pero se incluye en la tabla 3 debido a que gestiona la información.

1.7.2.9. Supervisor.

Persona designada por el concedente para realizar el seguimiento técnico, financiero y administrativo del contrato durante su ejecución hasta la liquidación del mismo.

1.7.2.10. Arquitectura IP/REV.

La arquitectura IP/REV tipo malla, con relaciones “peer-to-peer” entre todos los operadores IP/REV y los intermediadores IP/REV.

El SiGT, o sistema o subsistema designado por el Ministerio de Transporte, contendrá una base de datos que recibirá toda la información intercambiada entre operadores e intermediadores IP/REV.

Los OP IP/REV deberán mantener actualizada una base de datos local a partir de la información recibida de todos los intermediadores IP/REV. Asimismo, los OP IP/REV enviarán periódicamente a todos los INT IP/REV, y al SiGT, o sistema o subsistema designado por el Ministerio de Transporte, las transacciones de usuarios de IP/REV que han pasado por el peaje y la tarifa correspondiente aplicada. La lista contendrá la tarifa aplicada y las novedades asociadas al paso: por ejemplo, cobro regular, cobro con discrepancia, o cobro con inconsistencia, y demás que sean necesarias.

Es de notar que el SiGT, o sistema o subsistema designado por el Ministerio de Transporte, no realizará ninguna de las siguientes funciones:

• No será cámara de compensación.

• No realiza autorización de transacciones.

• No realiza el cobro, ni el recaudo de la tarifa de peaje.

El SiGT, o sistema o subsistema designado por el Ministerio de Transporte, realizará las siguientes operaciones:

• Proveer la funcionalidad para que las entidades OP IP/REV e INT IP/REV se certifiquen en el entorno de interoperabilidad de peajes de recaudo electrónico vehicular (IP/REV)

• Proveer el servicio REST (o mecanismo similar) para que las entidades INT IP/ REV (IP/REV) soliciten una colección de identificaciones únicas de TAGs para la activación de nuevos dispositivos RFID.

• Proveer un servicio REST (o mecanismo similar) para que los INT (IP/REV) reporten los TAGs activos, los TAGs incluidos en listas negras, y demás información que intercambien entre INT (IP/REV) y OP (IP/REV).

• Proveer un servicio REST (o mecanismo similar) para que los OP IP/REV reporten los pasos con las tarifas aplicadas, y demás información (como novedades) que intercambien entre OP (IP/REV) e INT (IP/REV).

• Garantizar la seguridad y confidencialidad de la información almacenada.

1.7.3. Diagrama de relaciones del sistema IP/REV.

En esta sección se presentan las relaciones entre los actores estratégicos del sistema IP/ REV en relación con los procesos de administración, operación, recaudo y supervisión. Se incluye la tabla 4, en la que se presentan las relaciones existentes entre un actor A y un actor B del esquema de funcionamiento IP/REV en Colombia.

#Actor AActor BConexión
1 MT ANI(1) Establece políticas. (2) Define las reglas. (3) Emite conceptos vinculantes para la localización de peajes.
INVÍAS
INT IP/REV(1) Define criterios de certificación
ANIMT (1) Adopta políticas. (2) Respeta las reglas establecidas. (3) Supervisa el cumplimiento de las reglas por parte de sus concesionarios u operadores de peajes.
 INVÍAS
# Actor A Actor B Conexión
2 MT SiGT, o sistema o subsistema designado por el Ministerio de Transporte. (1) Realiza consulta de información disponible en el SiGT, o sistema o subsistema designado por el Ministerio de Transporte.
3 INVÍAS CONCESIONARIO DE INVÍAS (1) Recibe información de volúmenes y recaudo. (2) Establece las condiciones del contrato de concesión. (3) Supervisar el cumplimiento de las reglas por parte de sus concesionarios.
4 INVÍAS OP IP/REV (1) Enviará la lista de los usuarios exentos.
5 ANI CONCESIONARIO DE LA ANI (1) Recibe información de volúmenes y recaudo. (2) Establece las condiciones del contrato de concesión. (3) Supervisar el cumplimiento de las reglas por parte de sus concesionarios.
6 CONCESIONARIO DE LA ANI OP IP/REV DEL CONCESIONARIO DE LA ANI (1) Realiza contrato de operación del peaje IP/REV.
7,8 OP IP/REV O CONCESIONARIO DE LA ANIINT IP/REV (1) Realiza convenio para recaudo.
OP IP/REV O CONCESIONARIO DEL INVÍAS
9, 10 USUARIO INT IP/REV (1) Suscribe un contrato de adhesión para poder realizar el pago electrónico de la tarifa de peaje por medio de un dispositivo TAG RFID. (2) Realiza peticiones, quejas y reclamos relacionados con el contrato de adhesión. (3) Emplea el dispositivo TAG RFID para realizar el pago electrónico en las estaciones de peaje que cuentan con tecnología de IP/REV.
11 USUARIO INVÍAS (1) Solicita el beneficio de tarifa especial para una estación de peaje del Invías. (2) Solicita la exención del pago de la tarifa de peajes a nivel nacional.
12 INTERMEDIADOR INT IP/ REV OP IP/REV (1) Envía listas de Usuarios IP/ REV y saldos. (2) Descarga la lista de pasos y tarifas.
12’ OPERADOR OP IP/REV INT IP/REV (1) Consolida la lista de pasos y tarifas. (2) Recibe listas de usuarios IP/REV y saldos. (3) Envía la lista de pasos y tarifas.
13 OP IP/REV O CONCESIONARIO DEL INVÍASINT IP/REV (1) Envía listas de pasos. (2) Descarga la lista de dispositivo TAG RFID y saldos.
OP IP/REV O CONCESIONARIO DE LA ANI
13’ INTERMEDIADOR INT IP/ REV OP IP/REV O CONCESIONARIO DEL INVÍAS (1) Consolida la lista de usuarios y saldos. (2) Recibe listas de pasos y tarifas. (3) Envía la lista de usuarios IP/REV y saldos.
OP IP/REV DEL CONCESIONARIO DE ANI
14 Ditra SiGT, o sistema o subsistema designado por el Ministerio de Transporte. Consulta información vehicular
15 CONCESIONARIO DE LA ANIDitra (1) Realiza convenio para control operativo del tramo concesionado y de las estaciones de peaje. (2) Suministra material de apoyo a la Ditra para desempeñar el control operativo.
CONCESIONARIO DE INVÍAS
16 Ditra SECRETARÍAS DE TyT (1) Reporta las infracciones al Código Nacional de Tránsito Terrestre cometidas. (2) Reporta las órdenes de comparendo expedidas a los infractores.
17 SUPERTRANSPORTE CONCESIONARIO DE LA ANI (1) Realiza inspección, vigilancia y control a la prestación del servicio público. (2) Realiza inspección, vigilancia y control a los términos del contrato de concesión.
CONCESIONARIO DEL INVÍAS
18 USUARIO SUPERINDUSTRIA (1) Realiza peticiones, quejas y reclamos relacionados con la actividad comercial.
19 SUPERTRANSPORTE SiGT, o sistema o subsistema designado por el Ministerio de Transporte. (1) Descargar información para realizar sus funciones.
SUPERINDUSTRIA

# Actor A Actor B Conexión
20 SECRETARÍAS DE TyT USUARIO (1) Sanciona a los infractores.
21 INTERVENTOR DE CONTRATO DE LA ANI CONCESIONARIO DE LA ANI (1) Verifica, mide y comprueba el cumplimiento de las condiciones del contrato de concesión firmado entre la ANI y sus concesionarios.
22 INTERVENTOR DE CONTRATO DEL INVÍAS CONCESIONARIO DE INVÍAS (1) Verifica, mide y comprueba el cumplimiento de las condiciones del contrato de concesión firmado entre el Invías y su concesionario.

Tabla 4. Relaciones del esquema de funcionamiento IP/REV.

1.8. Entorno operacional y de soporte.

En esta sección se presenta el entorno operacional y de soporte del sistema IP/REV, realizando una descripción general de las funcionalidades y equipos necesarios para el funcionamiento del mismo.

1.8.1. Descripción de las funcionalidades del software.

A continuación, se presentan las funcionalidades del software y componentes de comunicaciones que son necesarios para el funcionamiento del sistema IP/REV.

1.8.1.1. Sistema de gestión de transacciones, SiGT.

El software y componentes de comunicaciones necesarios:

• Sistema de Información que recibe copia de la información de transacciones de cobros y recaudos (SiGT), o sistema o subsistema designado por el Ministerio de Transporte.

1.8.1.2. OP IP/REV.

Las funcionalidades del software y componentes de comunicaciones necesarios para el OP IP/REV son:

• Sistemas de información para la gestión de la base de datos local (COP) y operación del peaje (carriles IP/REV).

• Sistema de información para la actualización de la base de datos local del COP desde los intermediadores (INT IP/REV) y para el envío de información desde la base de datos local del COP a los intermediadores (INT IP/REV) y al SiGT o sistema o subsistema designado por el Ministerio de Transporte.

• Sistema de información para el intercambio (consulta y envío) de información entre la base de datos local de cada carril IP/REV de la(s) plaza(s) de peajes y el COP.

1.8.1.3. INT IP/REV.

Las funcionalidades del software y componentes de comunicaciones necesarios para el intermediador son:

• Sistema de información para la gestión de la base de datos local del INT IP/REV con información de usuarios IP/REV, dispositivos TAG RFID activados y saldos asociados y para el envío de información desde la base de datos local al SiGT o sistema o subsistema designado por el Ministerio de Transporte.

• Sistema de información para la actualización de la base de datos local del INT IP/REV desde los operadores OP (IP/REV) y para el envío de información desde la base de datos local del INT IP/REV a los operadores OP (IP/REV) y al SiGT o sistema o subsistema designado por el Ministerio de Transporte.

1.8.2. Descripción del hardware necesario.

A continuación, se presentan los componentes más importantes del FRONT-END. La descripción detallada de estos componentes:

• Lectores RFID, según estándar ISO 18000-63.

• Sistema para reconocimiento de número de placa.

• Cámaras del número de ejes.

• Cámaras de seguridad.

• Sensores para determinar la categoría del vehículo.

• Sistema para gestión de información de carril IP/REV.

• Red de transmisión de datos entre carril IP/REV y centro de control de la plaza de peaje.

• Barrera de salida automática.

• Semáforos.

• Paneles de señalización variable.

• Señalización e iluminación en las vías.

• Sistema de respaldo eléctrico.

Se debe garantizar la existencia de equipos de hardware que provean soporte a las siguientes actividades:

• Recopilación de la información de monitoreo y supervisión. Se deberá contar con equipos para el almacenamiento y consulta remota de imágenes de seguridad desde los COP sobre la actividad general del peaje.

• Identificación de placas. Se deberá contar con equipos de hardware dedicados al procesamiento de imágenes que permitan la identificación de placas de todos los vehículos que transitan por todos los carriles IP/REV del peaje. El resultado de dicho reconocimiento deberá ser contrastado con los datos almacenados en la base de datos, campo seleccionado según el número de identificación del dispositivo TAG RFID (TID).

• Recolección de información de tráfico. Se dispondrá de equipos para el almacenamiento de información acerca del flujo vehicular, discriminando las categorías que fueron detectadas y las tarifas aplicadas.

• Gestión de discrepancias. Se dispondrá de equipos de cómputo y de software para la gestión de posibles discrepancias. Los videos y/o imágenes que hagan parte de la prueba del paso de un vehículo por un carril IP/REV, deberán estar disponibles desde el COP para ser enviados a las entidades intermediadoras en caso de que éstas los soliciten.

• Información de intermediador. Se deberá disponer de equipos de cómputo para gestionar las bases de datos que se obtengan desde los diferentes operadores OP (IP/REV). Estos se encargarán de gestionar la coherencia entre dicha base de datos y la que se dispone en cada computador a nivel de carril IP/REV.

• Información de configuración. Se dispondrá de equipos de cómputo para la configuración de tarifas, gestión de listas, gestión de operadores IP/REV (OP IP/REV) (service management) y otro tipo de posibles configuraciones que se deriven para la correcta ejecución del sistema IP/REV.

En lo relacionado al BACK-END, en un sistema IP/REV es necesario contar con un centro de operación de peajes (COP) para la recolección de información de todas las plazas de peajes que pertenezcan al sistema. Entre las funciones que debe cumplir un centro se encuentran:

• Informar las discrepancias (detección de ejes que define el valor a cobrar, sistema para el reconocimiento de número de placa vs. placa almacenada en la DB, etc.).

• Monitorear las plazas y carriles IP/REV de peaje.

• Mantener una interfaz con BACK-OFFICE.

• Información de intermediador: base de datos para gestionar los cobros.

• Información de configuración: información de tarifas, listas, y demás (service management).

1.9. Escenarios operacionales.

En esta sección se describen los escenarios operacionales del sistema para IP/REV, haciendo énfasis en la interacción de los sistemas de información de los OP IP/REV (verificación de saldos y notificación de cobros) y de los INT IP/REV (dispositivos TAG RFID certificados o deshabilitados, dispositivo TAG RFID con tarifa especial y saldos).

1.9.1. Escenarios de intercambio de información para la operación de peajes.

A continuación, se presentan los escenarios en los cuales ocurre intercambio de información entre los diferentes actores estratégicos y con el sistema de gestión de transacciones del ministerio (SiGT), o sistema o subsistema designado por el Ministerio de Transporte. De acuerdo con cada escenario, se mencionan a los actores involucrados en el escenario y la descripción del escenario.

1.9.1.1. Actualización de la base de datos de los COP.

Con el fin de realizar la correcta operación del entorno del peaje, el OP IP/REV debe mantener actualizada la información en cada una de sus plazas y carriles IP/REV de peaje. Para ello, el INT IP/REV deberá enviar la información (relacionada con los dispositivos TAG RFID activados) a todos los OP IP/REV, para que estos la almacenen en su base de datos y generen la versión de lista blanca a utilizar en el sistema de peaje.

1.9.1.2. Notificación de novedades desde los COP.

Con el objetivo de realizar la actualización y consolidación de la información relacionada con los cobros, el OP IP/REV debe enviar periódicamente a todos los INT IP/REV las novedades ocurridas en cierto período de tiempo previamente determinado. Para esto, el OP IP/REV debe estar autorizado para establecer comunicación con los INT IP/REV y habilitado para enviarle información a través del canal de comunicaciones establecido. De esta forma, al momento de cumplirse el período de tiempo determinado desde el COP se realizará el envío de las novedades a los INT IP/REV, está información también deberá ser enviada al SiGT o sistema o subsistema designado por el Ministerio de Transporte.

Este intercambio de información implica también el manejo de disputas, el cual requiere que los operadores OP IP/REV y los intermediadores INT IP/REV establezcan mecanismos para la solución de aquellas que sean reportadas como cobros y que requieran su posterior revisión.

1.9.1.3. Actualización de la base de datos de las entidades INT IP/REV.

Con el propósito de garantizar el sistema IP/REV, toda entidad INT IP/REV recibirá periódicamente desde los OP IP/REV, las novedades relacionadas con el paso de vehículos con dispositivos TAG RFID asociados a sus usuarios IP/REV y almacenará esta información en su base de datos. Con base en esta información, y la información de recargas y pagos, las entidades INT IP/REV procederán a actualizar los saldos correspondientes y reportarlos a los OP (IP/REV).

1.9.1.4. Notificación de novedades desde las entidades INT IP/REV.

Con el objetivo de realizar la actualización y consolidación de la información, toda entidad intermediadora del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (INT IP/REV) deberá enviar periódicamente a los operadores y al SiGT o sistema o subsistema designado por el Ministerio de Transporte las actualizaciones que haya realizado en un determinado período de tiempo las novedades que se produzcan.

Para esto, la entidad Intermediadora debe estar autorizada para establecer comunicaciones con los operadores y habilitado para enviarles información a través de los canales de comunicaciones especificados.

1.9.1.5. Notificación de novedades al SiGT.

Tanto los operadores, como los intermediadores enviarán copia idéntica de toda la información que intercambien entre ellos al SiGT, o sistema o subsistema designado por el Ministerio de Transporte.

1.9.1.6. Notificación de dispositivos TAG RFID exentos.

Un usuario con calidad de exento otorgada por el Invías de conformidad con la Ley 787 de 2002, deberán presentar la solicitud de adquisición del TAG RFID ante el intermediador de su elección, siguiendo los procedimientos conforme la normatividad vigente y los lineamientos del Invías.

El Ministerio de Transporte prevé un período de transición hasta el uso exclusivo del dispositivo TAG RFID para el proceso de los pasos de vehículos exentos, durante el cual el usuario exento podrá hacer uso de ambas tecnologías (TIE y dispositivo TAG RFID) de acuerdo a sus necesidades.

1.9.1.7. Gestión de tarifas especiales.

El interesado debe realizar una solicitud ante el concedente de la plaza de peaje (ANI, Invías o entidad territorial), y justificar que cumple con las condiciones para hacerse acreedor del beneficio (esto es, que reside en la vecindad, entre otras).

En la actualidad, un usuario que obtiene el beneficio de una tarifa especial en un punto de peaje se identifica en el carril manual por medio de una TIE o tarjeta inteligente, o cualquier otro medio expedido por el concedente respectivo, o por su concesionario, en caso de que así se haya acordado.

Con el sistema IP/REV, no se hará necesario el uso de una TIE por parte de los usuarios, sino que estos al obtener el beneficio de tarifa especial emitido por el concedente respectivo, deberán ir al OP IP/REV de la plaza de peaje de interés y notificarle el beneficio recibido mediante una resolución que portará el usuario y que deberá ser acogida por el OP IP/REV. En ese momento, el OP IP/REV deberá asociar en su base de datos local al usuario con la tarifa especial, y al momento en que este transite por la respectiva plaza de peaje, el OP IP/REV debe reportar al INT IP/REV el tipo de cobro “tarifa especial”

NOTA: cuando un concedente otorgue el beneficio de tarifa especial a un usuario que no tenga (y no suscriba) un contrato IP/REV, el usuario deberá portar un TIE o similar en su vehículo, igual que en la actualidad. El concedente notificará a sus concesionarios la lista de Usuarios con tarifa especial, que no cuentan con sistema IP/REV.

1.9.1.8. Gestión de inconsistencias en la información.

A continuación, se presenta una serie de obligaciones a cargo de cada uno de los actores estratégicos del sistema IP/REV, las cuales deberán cumplirse con el objetivo de evitar inconsistencias:

• La entidad INT IP/REV debe recibir los cobros reportados por los OP IP/REV con la periodicidad especificada por el Ministerio de Transporte en el anexo 5 - Especificaciones de Interoperabilidad.

• La entidad INT IP/REV debe emitir las novedades de saldos, con la periodicidad especificada por el Ministerio de Transporte en el anexo 5 - Especificaciones de Interoperabilidad.

• El OP IP/REV debe recibir las novedades de saldos con la periodicidad especificada por el Ministerio de Transporte en el anexo 5 - Especificaciones de Interoperabilidad.

• El OP IP/REV debe emitir las novedades de los cobros realizados por sus carriles IP/REV, con la periodicidad especificada por el Ministerio de Transporte en el anexo 5 - Especificaciones de Interoperabilidad.

• Tanto el INT IP/REV como el OP IP/REV, deben garantizar la comunicación entre ellos a través de la redundancia en sus sistemas de información y canales de comunicación INT IP/REV - OP IP/REV.

• Tanto el INT IP/REV como el OP IP/REV, deben garantizar la comunicación con el SiGT, o sistema o subsistema designado por el Ministerio de Transporte, a través de la redundancia en sus sistemas de información y canales de comunicación OP/INT IP/REV-SiGT.

• El OP IP/REV debe garantizar la comunicación del COP con la plaza de peaje y cada carril IP/REV.

En caso de que se incumpla alguna de las condiciones anteriores, debido a la caída de alguno de los sistemas de información involucrados o a fallas en los canales de comunicación; es posible que un OP IP/REV no cuente en el COP con información actualizada al momento de permitir o no, el paso de un vehículo por un carril IP/REV (exclusivo o mixto), esto constituirá una inconsistencia. En la figura 2. Cuatro escenarios posibles en la gestión de inconsistencias se presentan los cuatro escenarios posibles.

xxxxxxxzzzz
 

Figura 2. Cuatro escenarios posibles en la gestión de inconsistencias.

1.9.1.9. Gestión de discrepancias en el cobro de la tarifa de peaje.

Cuando un vehículo hace uso de un carril IP/REV, es posible que la configuración del vehículo detectada por los sensores ubicados en la plaza de peaje y la categoría consultada a partir de la lectura del dispositivo TAG RFID en la base de datos, sean diferentes. En este caso se presenta una discrepancia en el valor a cobrar por la tarifa de peaje.

❖ Error de lectura de placa. Dadas las posibilidades de error en el sistema de reconocimiento de placa se puede dar la situación en la que se realice la lectura del dispositivo TAG RFID, basándose en el TID y/o EPC del dispositivo TAG RFID se consulta su placa asociada desde la DB del COP, pero no es posible validar - automáticamente, al menos– que ésta coincida con la placa del vehículo. En este caso, el OP IP/REV deberá reportar el cobro con discrepancia y será el encargado de verificar manualmente la placa mediante revisión de la imagen. Si a partir de la revisión, el OP IP/REV determina que la placa efectivamente coincide con la asociada al dispositivo TAG RFID, entonces deberá reportar la novedad de Resolución de la discrepancia (sin cambio en el valor cobrado). La entidad intermediadora del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (INT IP/REV), dentro de los contratos para la prestación del servicio IP/REV a los usuarios, debe incluir cláusulas que contemplen sanciones por el uso indebido del dispositivo TAG RFID por parte del usuario IP/REV.

❖ Discrepancia por diferencia de placa. Dadas las posibilidades de error en el reconocimiento de placa, se puede dar la situación en la que se realice la lectura del dispositivo TAG RFID, y con base en el TID y/o EPC del dispositivo TAG RFID se consulta su placa asociada desde la DB del COP. En el caso de que el OP IP/ REV después de un proceso de verificación determine que la placa leída no coincide con la asociada al dispositivo TAG RFID, deberá reportar la inconsistencia INT IP/REV correspondiente, para que se incluya dicho dispositivo TAG RFID en la lista negra (véase definición al inicio del documento) y no se permita el paso del vehículo en otros carriles IP/REV.

CAPÍTULO 2

Requisitos funcionales de hardware y software IP/REV

requisitos funcionales de software IP/REV

2.1. Generalidades.

De acuerdo a la visión descrita en el capítulo 1 “Concepto de operación” del presente documento y con el objetivo de aprovechar al máximo la información de la interoperabilidad de peajes y el recaudo electrónico vehicular, el Ministerio de Transporte implementó de un sistema que recibirá toda la información que se intercambia entre los actores estratégicos (OP e INT IP/REV), y la analizará mediante aplicaciones y herramientas de forma que proporcione datos, tendencias, etc.

De esta forma, los OP IP/REV deberán reportar los pasos por carriles IP/REV y los INT IP/REV, a su vez, deberán reportar las novedades (alta y estado de los dispositivos TAG RFID, actualización de saldos, etc.) de las cuentas asociadas a los dispositivos TAG RFID a bordo de los vehículos.

De igual manera, el anexo 5 - Especificaciones de Interoperabilidad incluye condiciones y especificaciones que deberán ser cumplidas a cabalidad por los actores estratégicos.

2.2. Alcance del capítulo.

El propósito de este capítulo es presentar la especificación de los requisitos del sistema “Interoperabilidad de peajes y recaudo electrónico vehicular (IP/REV)”, el cual tiene como actores principales al sistema de gestión de transacciones (SiGT), o sistema o subsistema designado por el Ministerio de Transporte, los SI de los INT IP/REV y los SI de los OP IP/REV. Se presentan también las relaciones existentes entre los actores que componen el sistema IP/REV.

2.3. Alcance de los requisitos.

El alcance de los requisitos funcionales que se especifican en este capítulo y en el anexo 5 - especificaciones de interoperabilidad corresponde a los necesarios para garantizar la interoperabilidad de peajes.

Se especifican los requisitos relacionados con la consolidación de la información de recaudo (reportada por los INT IP/REV) y los cobros por tarifa de peaje (reportados por los OP IP/REV) y aquellos relacionados con poner esta información a disposición de los actores estratégicos del sistema. De igual manera, se presentan los requisitos relacionados con los OP IP/REV y los INT IP/REV para que el sistema funcione de forma efectiva y eficiente.

2.4. Perspectiva del sistema IP/REV.

A continuación, se presentan las características principales del sistema IP/REV, sus interfaces con los sistemas de información —SI— y sus modos de operación.

2.4.1. Interfaces con el SI del Ministerio de Transporte.

El SiGT, o sistema o subsistema designado por el Ministerio de Transporte, contará con la interfaz necesaria para comunicarse con otros sistemas de información.

2.4.2. Interfaces con otros SI.

Para el correcto funcionamiento del sistema IP/REV, el SiGT, o sistema o subsistema designado por el Ministerio de Transporte, y los SI de los OP IP/REV e INT IP/REV deben proveer los mecanismos de integración necesarios para que los diferentes SI de las entidades participantes puedan consultar la información requerida para su operación, así como para la notificación de novedades.

2.4.3. Funciones del SiGT.

Las funciones principales del SiGT serán las siguientes:

• Realizar el registro de las transacciones intercambiadas entre OP IP/REV e INT IP/REV.

• Gestionar la base de datos con información de los dispositivos TAG RFID activados y las placas de los vehículos asignados.

• Proveer una funcionalidad para que los miembros de las entidades relacionadas con el sistema IP/REV (ANI, Invías, ET, Supertransporte, Superindustria Ditra, y MT) puedan consultar información (estadísticas, indicadores, etc.) relacionada con el sistema IP/REV, necesaria para el cumplimiento de sus respectivas funciones.

2.4.4. Funciones del sistema de información de los OP IP/REV(7).

Además de las tareas propias de la operación del peaje, las funciones relacionadas con IP/REV del SI de los OP IP/REV, serán las siguientes:

• Administrar la base de datos local del OP IP/REV con información de los dispositivos TAG RFID en uso, listas de exentos, listas negras y vehículos especiales, categoría de los vehículos, tarifas de cada categoría, entre otros; y toda información que considere necesaria cada administrador de OP IP/REV.

• Proveer la funcionalidad necesaria para notificar a los INT IP/REV los cobros realizados por concepto de tarifa de peaje y demás situaciones especiales (p.e. discrepancias).

• Proveer la funcionalidad necesaria para notificar al SiGT, o sistema o subsistema designado por el Ministerio de Transporte los pasos y tarifas cobradas.

• Procesar, almacenar y proveer acceso a la información de imágenes, videos y sensores relacionados con la operación del peaje.

2.4.5. Funciones del sistema de información de los INT IP/REV(8).

Además de las tareas propias de la operación del Back-Office, las funciones relacionadas con IP/REV del SI de los de los INT IP/REV serán las siguientes:

• Proveer la funcionalidad necesaria para actualizar su base de datos local (estados y saldos) con la información de los cobros realizados por los diferentes operadores, que se relacionan con dispositivos TAG RFID de sus usuarios.

• Proveer la funcionalidad necesaria para notificar a los operadores y al SiGT, o sistema o subsistema designado por el Ministerio de Transporte, la activación de nuevos dispositivos TAG RFID, así como la activación/desactivación de los mismos, la placa y el tipo de contrato de pago asociado a cada dispositivo TAG RFID, y en caso de contratos tipo prepago, los saldos correspondientes. En el caso de los contratos de tipo pospago los INT IP/REV deben reportar el estado del dispositivo TAG RFID.

• Proveer la funcionalidad capaz de facturar al usuario IP/REV las transacciones recibidas de los diferentes OP IP/REV correspondientes a su TAG.

• Proveer un sistema completo de CRM (Customer Relation Management) capaz de soportar la interacción con toda su base de datos de clientes IP/REV, cumpliendo los acuerdos de servicios mínimos establecidos en los ANS definidos por el Ministerio de Transporte.

2.4.6. Consideraciones Invías.

A continuación, se presentan las restricciones que incidirán directamente en el diseño e implementación del sistema IP/REV:

2.4.7. Operación en paralelo.

El SI de los OP IP/REV y el SI de los INT IP/REV, deben ser diseñados e implementados de tal forma que soporten la operación normal (atención de usuarios y otros sistemas) y para que en paralelo puedan actualizar una instancia replicada de la base de datos en producción.

2.4.8. Funciones de control.

El SiGT, o sistema o subsistema designado por el Ministerio de Transporte, el SI de los OP IP/REV y el SI de los INT IP/REV, deben contar con funcionalidades de control establecidas que garanticen el correcto funcionamiento del sistema. Estas se encuentran relacionadas con la integridad de los datos que cada entidad maneja y que el acceso sea restringido de acuerdo a los roles y privilegios definidos.

2.4.9. Criticidad de la aplicación.

Los SI de los operadores e intermediadores del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (OP IP/REV e INT IP/REV) deben garantizar el nivel de disponibilidad descrito en la OBIP, teniendo en cuenta que su funcionamiento incide directamente en el funcionamiento del sistema de interoperabilidad de peajes con recaudo electrónico vehicular (IP/REV).

2.4.10. Consideraciones relacionadas con seguridad física y lógica.

Las consideraciones relacionadas con seguridad física y lógica son las especificadas en las normas 17799:2005 y 27001:2013, según se documenta en la sección de referencias. En particular, se deben tener en cuenta todos los aspectos relacionados con el cifrado de las diferentes bases de datos del SiGT, o sistema o subsistema designado por el Ministerio de Transporte, del OP IP/REV e INT IP/REV (versiones de servicio, replicación, respaldo, y archivo histórico), y las especificaciones establecidas en el anexo 5 - Especificaciones de interoperabilidad.

2.5. Supuestos y dependencias.

A continuación, se describen algunos requisitos generales identificados para la correcta operación del sistema IP/REV, y que por consiguiente deben ser cumplidos por los actores estratégicos:

• El operador está en capacidad de establecer conexiones recurrentes con el SiGT, o sistema o subsistema designado por el Ministerio de Transporte, y con los diferentes INT IP/REV.

• El operador cuenta con una base de datos local con toda la información asociada al TID de los dispositivos TAG RFID.

• El operador tiene una base de datos local con información (propia) relacionada con la operación del peaje, por ejemplo: categorías de los vehículos, valor de la tarifa de peaje por categoría, usuarios con tarifa especial y demás información relevante para el operador.

• Los intermediadores cuentan con un SI donde se registra la información relacionada con los dispositivos TAG RFID que han sido dadas de alta/baja, los abonos realizados a las cuentas tipo prepago (con sus respectivos saldos) y el estado (activo/inactivo) de los dispositivos TAG RFID asociados a cuentas de tipo pospago; y demás información relacionada con sus Usuarios y contratos respectivos.

• Los intermediadores están en capacidad de reportar de forma periódica a los OP IP/REV y al SIGT, o sistema o subsistema designado por el Ministerio de Transporte, la información relacionada con los dispositivos TAG RFID activados (estado, saldo, etc.).

• Los operadores e intermediadores gestionarán un esquema de seguridad que permita garantizar el no repudio de las transacciones realizadas entre ellos.

• El SiGT, o sistema o subsistema designado por el Ministerio de Transporte, contará con la infraestructura de hardware (energía, servidores, comunicaciones, y redundancia) y de software (en particular, un motor de base de datos, así como la replicación de la misma), que permitan operar el módulo de IP/REV.

2.6. Referencias.

El contenido del presente capitulo se basa en los documentos que se listan a continuación:

• Norma internacional ISO/IEC/IEEE 29148:2011, Systems and software engineering - Life cycle processes - Requirements engineering, Sección 9.5 Software requirements specification (SRS) document. https://standards.ieee.org/findstds/ standard/29148-2011.html

• Norma internacional ISO/IEC 17799:2005, Information technology - Security techniques - Code of practice for information security management.

http://www.iso.org/iso/catalogue_detail?csnumber=39612

• Norma internacional 27001:2013, Information technology - Security techniques - Information security management systems - Requirements. http://www.iso. org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=54534

• Norma internacional ISO/TS 17575, Electronic fee collection - Application interface definition for autonomous systems - Part 1: Charging.

• Concepto de operación del sistema (capítulo 2 “Concepto de operación”).

• RFC-6797, HTTP Strict Transport Security (HSTS). http://tools.ietf.org/html

Requisitos funcionales de hardware

2.7. (Modificado).* Generalidades.

De acuerdo a la visión descrita en el capítulo 1 “Concepto de operación” del presente documento, con el objetivo de lograr la interoperabilidad de peajes y el recaudo electrónico vehicular (IP/REV), se requiere especificar algunas funcionalidades clave, el hardware y el software necesario por los OP IP/REV y los INT IP/REV para garantizar el funcionamiento del sistema IP/REV.

El presente capítulo identifica las partes fundamentales del sistema de recaudo electrónico vehicular (IP/REV). Para cada parte, se describen las funcionalidades, y los elementos de Hardware y software necesarios para garantizar la interoperabilidad de peajes del sistema IP/REV en Colombia. De igual manera, los requisitos (funcionales, de uso, de confiabilidad, de rendimiento, entre otros) que debe tener cada elemento de software y hardware son presentados.

Lo anterior, esto sin desconocer que estos actores deberán proveer y operar los componentes adicionales que consideren para garantizar el correcto funcionamiento del sistema de peajes IP/REV y todo lo relacionado para cumplir a cabalidad con el objetivo y la visión del sistema IP/REV.

De igual manera, el operador IP/REV o el intermediador IP/REV podrán en el ejercicio de las mejores prácticas instalar elementos de igual o mejores características, siempre que cumplan con los estándares aquí establecidos.

2.7.1. Alcance de los requisitos.

A continuación, se presentan los requisitos funcionales para el funcionamiento del sistema de recaudo electrónico vehicular (IP/REV) en Colombia. Expone los aspectos generales de la estructura del sistema desde el punto de vista lógico atendiendo a su funcionalidad, los elementos de software y hardware que lo componen y los requisitos de cada uno. Los requisitos presentados están fijados para las operaciones elementales del sistema IP/REV en Colombia, teniendo en cuenta estándares ISO (Estándar ISO 18000-63, ISO/IEC 17575, ISO/IEC 17573, ISO/IEC 16410) de dicha área.

2.7.2. Referencias.

Este documento se basa en las siguientes referencias:

• INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 18000-63:2013. Information technology - Radio frequency identification for item management. 2013.

• INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 17575. Electronic fee collection - Application interface definition for autonomous systems. 2010.

• INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 17573. Electronic fee collection - Application interface definition for autonomous systems. 2010.

• INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 16410. Electronic fee collection - Evaluation of equipment for conformity to ISO/TS 17575. 2011.

• COLOMBIA. MINISTERIO DE TRANSPORTE. Resolución 4100 (dic. 28/2004). Por la cual se adoptan los límites de pesos y dimensiones en los vehículos de transporte terrestre automotor de carga por carretera, para su operación normal en la red vial a nivel nacional.

• COLOMBIA. MINISTERIO DE TRANSPORTE. Manual de señalización vial 2015.

• INSTITUTE OF ELECTRICAL AND ELECTRONIC ENGINEERS. IEEE 1012. Standard for System and Software Verification and Validation. 2012.

*(Nota: Modificado por la Resolución 3254 de 2018 artículo 4° del Ministerio de Transporte)

2.8. TAG RFID ISO 18000-63 (ON BOARD UNIT - OBU).

A continuación, se describen las especificaciones mínimas de los TAGs que deberán proveer los INT IP/REV a los usuarios IP/REV.

En los sistemas de recaudo electrónico se realiza una transferencia de datos entre el vehículo, que cuenta con un dispositivo TAG RFID ISO 18000-63 (OBU) y los equipos instalados en la infraestructura vial (RSU o Roadside Unit).

TipoDescripción
Funcional • El TAG RFID debe ser intransferible (una vez correctamente adherido al parabrisas) y compatible con estándar ISO/IEC 18000-63, con campo TID único y longitud de 96 bits.
• Los dispositivos TAG RFID deben tener un campo EPC con codificación estándar para identificar a los dispositivos TAG RFID que pertenecen al dominio de peajes IP/REV.
• Los números de la codificación asignada para los TAG RFID que distribuya un Intermediador, deberán ser solicitados al Ministerio de Transporte o a quien este designe, quien hará las veces de administrador de los números de dicha codificación y establecerá el procedimiento de codificación que garantice la autenticidad del TAG RFID mitigando cualquier riesgo de clonación.
Tipo Descripción
Usabilidad • La orientación de la instalación del TAG RFID será la que el proveedor o fabricante le indique al INT IP/REV, a fin de garantizar su correcta lectura en cualquier plaza de peaje. Entendiendo que las antenas lectoras cuentan con una polarización horizontal.
• El intermediador deberá suministrar un manual de instalación al usuario, donde se indique claramente la forma en que éste debe instalar el TAG RFID en su vehículo, o bien instalarlo directamente, ya que la responsabilidad de la correcta instalación del mismo recae en el propio Intermediador.
• De igual manera, deberá contar con al menos dos canales de comunicación, al menos uno web, para dar soporte técnico al usuario acerca de la instalación del TAG RFID, en caso que sea dicho usuario delegado en su instalación.
Confiabilidad • Los TAG RFID ISO 18000-63 deberán contener protección UV y estar construido con materiales y protecciones de calidad suficiente para garantizar su durabilidad por un periodo de al menos 5 años apropiado para la exposición a las condiciones dadas en vidrios panorámicos de los vehículos, o en exteriores para el caso de vehículos blindados.
• Los TAG RFID deberán contener protección IR.
• La temperatura de operación debe estar comprendida entre -20ºC y 60ºC.
• El INT IP/REV deberá garantizar que el TAG RFID funcione de acuerdo a los parámetros establecidos.
Seguridad y rendimiento • El TAG RFID deberá tener capacidad de operar con el sistema de lectura, a una distancia suficiente para ser detectada al ingresar al peaje.
• El TAG RFID debe ser a prueba de manipulaciones (tamper proof), por lo cual deberá quedar inservible al momento de intentar manipularlo o desprenderlo del lugar en que fue instalado.
• El TAG RFID debe estar protegido contra escritura, y contra KILL.
• EL TAG RFID debe tener una resistencia a la descarga electrostática (ESD) determinada.
Soporte • Los TAG RFID ISO 18000-63 deberán contar con soporte y representación en el país, por defectos de fabricación, por parte del proveedor o fabricante a través del INT IP/REV, en caso que el usuario lo solicite.
Interfaces para intercambio de datos • Inalámbrica, especificada por la norma ISO 18000-63.

2.9. Elementos del sistema IP/REV DEL OP IP/REV.

Un sistema de peaje típico incluye los siguientes tres niveles lógicos:

• Nivel 1: Nivel de vía,

• Nivel 2: Nivel de plaza,

• Nivel 3: Centro de operación de peajes.

El sistema de peaje es IP/REV cuando es capaz de procesar transacciones de vehículos identificados con un TAG RFID, leídos por periféricos —antenas— en el nivel 1. Dichas transacciones llegan al nivel 3, donde son tratadas como “eventos de cobro”, y enviadas a un nivel lógico 4, o backoffice, donde se resuelven recaudando la tarifa de peaje correspondiente al cliente dueño del TAG RFID. Este nivel 4 se realizará por parte de los INT IP/REV.

Los niveles 1 y 2 de un sistema de peaje IP/REV pueden ser tanto una plaza de peaje, como una infraestructura tecnológica que cumpliera funciones análogas y permitiera el cobro por sistema de peaje de flujo libre multicarril (MLFF).

A continuación, se presentan los requisitos para el funcionamiento de un peaje con IP/ REV a nivel de vía y plaza, detallando los componentes que integran la vía IP/REV y el centro de control de la plaza.

2.9.1. FRONT-END-Infraestructura para servicio a nivel de vía IP/REV.

A continuación, se describen los componentes mínimos que deberán tener o proveer los OP IP/REV para un carril IP/REV y plaza de peaje.

2.9.1.1. Unidad de lectura de dispositivo TAG RFID.

El sistema de lectura de dispositivo TAG RFID, es el encargado de detectar el vehículo cuando ingresa al carril IP/REV del peaje, mediante la tecnología RFID ISO 18000-63.

A continuación, se describen los requisitos para este componente.

TipoDescripción
Funcional • Lectura de campos EPC de dispositivo TAG RFID ISO 18000-63 y campo TID de aquellos que pertenezcan al dominio de peajes.
• Verificación de integridad de la información: la unidad de lectura debe contar con un sistema de verificación de integridad de la información de los dispositivos RFID ISO 18000-63 leídos, igual o mejor que el CRC16.
Usabilidad • Las unidades de lectura deben ser aptas para operación en pórticos y en condiciones de intemperie. Deberán cumplir con el estándar IP66.
Confiabilidad • La unidad de lectura de dispositivo TAG RFID ISO 18000-63, deberá garantizar una tasa de lecturas efectivas de al menos el 98% con dispositivos TAG RFID bien instalados y en buen estado de conservación.
• La unidad de lectura debe tener una disponibilidad del 99.5%, con una media de tiempo entre fallas (MTBF) no menor a 26280 horas.
• La confiabilidad de los datos leídos de un dispositivo TAG RFID ISO 18000-63 debe ser superior al 99.9%.
Rendimiento • La unidad de lectura debe realizar al menos 100 lecturas por segundo de múltiples dispositivos TAG RFID ISO 18000-63 en movimiento a una velocidad máxima de 60 Km/h respecto al lector.
• La potencia máxima radiada por el sistema de lectura de dispositivos TAG RFID debe ser la estipulada por el estándar ISO 18000-63 y en ningún caso debe exceder la especificada en la normatividad colombiana emitida por la Agencia Nacional del Espectro (ANE).

TipoDescripción
 • Las frecuencias de operación estarán en la banda de 900MHz y serán las que permita la Agencia Nacional del Espectro para este tipo de aplicación.
Soporte • Las unidades de lectura deben contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje.
Interfaces para transmisión de datos • Interfaces físicas para transmisión de datos RS232 o Ethernet IEEE 802.3.

2.9.1.2. Sistema para reconocimiento de número de placa.

La detección de placas vehiculares es una parte fundamental en los sistemas inteligentes de transporte. En el caso de los sistemas IP/REV, estas tecnologías permiten contrastar la información recogida a partir del TID del dispositivo TAG RFID con la información obtenida por los sistemas de lectura de placa a nivel del carril IP/REV.

A continuación, se describen los requisitos para este componente.

TipoDescripción
Funcional • El sistema para reconocimiento de número de placa debe reconocer la placa del vehículo que ingresa al carril IP/REV de forma automática y los caracteres detectados deben ser almacenados junto con las evidencias de paso del vehículo por el carril IP/REV del peaje.
Usabilidad • Reconocimiento de placas de vehículos en cada uno de los carriles IP/REV del peaje.
Confiabilidad • El sistema de reconocimiento de placas debe tener una disponibilidad del 99.5%, con una media de tiempo entre fallas (MTBF) no menor a 17.000 horas.
Rendimiento • El sistema de reconocimiento de placas debe tener una efectividad igual o superior al 95%, para placas en buen estado de conservación y limpieza.
• El sistema de reconocimiento de placas debe tener un tiempo de respuesta inferior a 2 segundos desde el momento en que se realiza la fotografía hasta que se obtiene el texto de la placa del vehículo.
• La cámara empleada para este sistema debe tener un grado de protección IP66.
Soporte • El sistema de reconocimiento de placas debe contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje. En el caso de que el proveedor no sea el fabricante, este debe contar con personal certificado por el fabricante para dar soporte y servicio a los equipos.
Interfaces para transmisión de datos • Interfaces físicas para la transmisión de datos RS232 o Ethernet IEEE 802.3.

2.9.1.3. Cámaras para grabación de los ejes de los vehículos.

La cámara para grabación de los ejes de un vehículo sirve para obtener evidencias acerca del número de ejes en caso que se requiera para la solución de discrepancias.

A continuación, se describen los requisitos para este componente.

TipoDescripción
Funcional • La cámara debe grabar vídeo o secuencias de imágenes; y al menos, una imagen debe ser evidencia del número ejes del vehículo.
• Dicha(s) imagen(es) o vídeo deben ser almacenadas junto con la placa detectada.
Usabilidad • Se debe realizar grabación en vídeo o secuencia de imágenes del número de ejes de los vehículos en cada uno de los carriles del peaje IP/REV, sin importar las condiciones climáticas, de iluminación o temperatura que estén en el peaje.
Confiabilidad • Las cámaras para la grabación de ejes de los vehículos deben tener una disponibilidad del 99.5%, con una media de tiempo entre fallas (MTBF) no menor a 17.000 horas.
Rendimiento • Las cámaras para la grabación de ejes deben entregar su información de forma inmediata al centro de control de la plaza de peaje.
• Este tipo de cámara debe tener un grado de protección IP66.
Soporte • Las cámaras para la grabación de ejes y placa deben contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje.
Interfaces para transmisión de datos • Interfaces físicas Ethernet IEEE 802.3.

2.9.1.4. Cámaras de seguridad.

Con fines de control de flujo vehicular, colas en la plaza (y demás ANS y condiciones establecidas para obtener y mantener la certificación), y seguridad se debe contar con al menos una cámara panorámica en cada sentido y cámara(s) que permitan la vigilancia de las áreas de servicio.

A continuación, se describen los requisitos para este componente.

TipoDescripción
Funcional • Se debe instalar una cámara panorámica por cada sentido del peaje (entrada, salida) tipo PTZ, controlables de forma remota. Asimismo, deben existir cámaras que cubran por completo las áreas de servicio.
• Las cámaras operarán al menos a 15 fps, con zoom óptico de 32X con una sensibilidad mínima de 0.2 lux, compatibles con formatos H.264 y MPEG-4; y cumplir con el estándar ONVIF.
• Las cámaras deben ser funcionales en diferentes condiciones de clima y temperatura, por lo que, de ser necesario, contarán con sistema calefactor propio.
• Se debe contar con un switch de video, que permita seleccionar desde el COP a cualquiera de las cámaras de seguridad del peaje para el envío de las imágenes a dicho centro.
Usabilidad • Las imágenes de las cámaras serán transmitidas al centro de control de la plaza de peaje. Allí serán almacenadas de forma cifrada empleando AES 256.
Confiabilidad • Las cámaras deberán tener cada una disponibilidad del 99.9%, con una media de tiempo entre fallas (MTBF) no menor a 26.000 horas.
TipoDescripción
Rendimiento • Cada cámara deberá tener una resolución mínima de 1920x1080 píxeles.
• Este tipo de cámara deberá tener un grado de protección IP66.
Soporte • Las cámaras deberán contar con soporte técnico y capacidad de suministro por parte del fabricante o proveedor durante el tiempo de funcionamiento en el peaje.
Interfaces para transmisión de datos • Interfaz física Ethernet IEEE 802.3 u otro medio cableado para la transmisión de datos.

2.9.1.5. Sensores de detección automática de la categoría del vehículo.

Cada vía del peaje debe contar con los sensores necesarios para realizar de forma automática la categorización del vehículo. Los requisitos para dichos sensores son los siguientes:

TipoDescripción
Funcional • Se deberá instalar el número y tipo de sensores que determinen la categoría del vehículo, por ejemplo, mediante la medición de variables como número de llantas, ancho de la llanta, altura, entre otras.
• Los sensores deben ser capaces de determinar la categoría del vehículo en movimiento a una velocidad de hasta de 60 km/h, con vehículos transitando a 40 centímetros de separación.
Usabilidad • Los sensores serán aptos para ser empleados en ambientes industriales y de aplicación en sistemas de peajes.
• Los sensores instalados no deben afectar la velocidad con la que el vehículo ingresa al carril del peaje.
Soporte • El sistema de sensores debe contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje.
Interfaces para transmisión de datos • Interfaces físicas para la transmisión de datos RS232/RS485 o Ethernet IEEE 802.3 u otras no inalámbricas de carácter industrial.

2.9.1.6. Barrera o talanquera de salida automática.

Los carriles IP/REV deben contar con una barrera automática que controle el paso de vehículos. Los requisitos para esto son los siguientes.

TipoDescripción
Funcional • Talanqueras automáticas de alta velocidad en cada vía IP/REV del peaje que permitan el paso de los vehículos una vez se haya confirmado el cobro de la tarifa correspondiente.
Usabilidad • La talanquera deberá tener apertura y cierre automático.
• La composición física y estética de las barreras deberá ser conforme con el manual de señalización vial 2015 (capítulo 5 Otros dispositivos para la regulación de tránsito, sección 5.11. Señalización de estaciones de peaje, apartado 4 Barreras de control), adoptado por el Ministerio de Transporte.
Confiabilidad • Las talanqueras deben tener un MTBF no menor a 1 año con características para trabajo pesado.
Rendimiento • El tiempo de respuesta para subida y para bajada de dicha barrera debe ser igual o inferior a 0.7 segundos(9) en cada caso.
Soporte • Las barreras automáticas deben contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje.
Interfaces • Interfaz de control RS 232, Ethernet IEEE 802.3 u otras de uso industrial.

2.9.1.7. Semáforos.

Los carriles IP/REV se deben tener dos tipos de semáforos LED: los que indican al usuario el estado del carril IP/REV (abierto o cerrado), y los que indican la autorización para continuar el paso por el peaje.

Los requisitos para esto son los siguientes.

TipoDescripción
Funcional • Se deben instalar elementos de señalización visibles antes del peaje, “semáforos de marquesina”, que indiquen al usuario IP/REV el estado del carril IP/REV (abierto, cerrado) de conformidad con el manual de señalización vial 2015 (capítulo 5 Otros dispositivos para la regulación de tránsito, sección 5.11. Señalización de estaciones de peaje, apartado 5, Semáforos e indicadores de forma de pago), adoptado por el Ministerio de Transporte.
• De igual forma, se deben instalar “semáforos de paso”, ubicados en el carril IP/ REV, informando al usuario IP/REV acerca de si está autorizado o no para continuar su paso por el peaje. Estos elementos deberán cumplir con las normas presentadas en el manual de señalización vial 2015 (capítulo 7 Semáforos), adoptado por el Ministerio de Transporte.
Usabilidad • Los “semáforos de marquesina” que indican el estado del carril IP/REV debe ser visibles a una distancia tal que permita al usuario cambiar de carril en caso de que el carril IP/REV se encuentre cerrado o en caso de que el usuario no disponga de los medios para realizar el pago electrónico.
• Los “semáforos de paso” que indican la autorización para continuar el paso por el carril IP/REV del peaje deben ser adecuadamente visibles por el usuario de acuerdo a la operación de dicho carril.
Confiabilidad • Los semáforos empleados deberán tener un nivel de disponibilidad superior al 99%, con un MTBF superior a 5 años.
Rendimiento • Los semáforos empleados deberán tener características de visibilidad, tamaño, colores y demás características especificadas en el manual de señalización vial 2015 capítulo 5 Otros dispositivos para la regulación de tránsito, sección 5.11. Señalización de estaciones de peaje, apartado 5 Semáforos e indicadores de forma de pago y Capítulo 7 Semáforos.
Soporte • Los semáforos deberán contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje.

TipoDescripción
 • El mantenimiento realizado a los semáforos y a sus elementos asociados deberá realizarse, en concordancia con el manual de señalización vial 2015 (capítulo 7 Semáforos, sección 7.4. Mantenimiento), adoptado por el Ministerio de Transporte.
Interfaces • Interfaz física cableada de uso industrial.

2.9.1.8. Paneles de señalización variable.

Los carriles IP/REV del peaje deben contar con pantallas de información alfanuméricas LED.

Los requisitos para esto son los siguientes, sin perjuicio de que las mismas deberán tener un tamaño que permita al usuario la fácil lectura de la información.

TipoDescripción
Funcional • Las pantallas de información alfanumérica informarán al usuario IP/REV el valor del pago realizado y alguno de los siguientes mensajes según aplique: Saldo bajo, saldo insuficiente o dispositivo TAG no reconocido.
Usabilidad • Los paneles de señalización variable deberán ser visibles desde el punto de entrada al carril IP/REV desde la ubicación del conductor del vehículo, sin importar su categoría.
 • Estos paneles deben estar ubicados debajo del semáforo que indica la autorización para continuar el paso por el peaje, a fin de garantizar un único punto de vista a los usuarios IP/REV, cumpliendo con 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).
 • De igual manera, deben cumplir con las consideraciones de diseño; 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), adoptado por el Ministerio de Transporte.
Confiabilidad • Los PMV deben tener un nivel de disponibilidad superior al 99% y un MTBF superior o igual a 5 años.
Rendimiento • Los PMV deberán tener características de visibilidad, tamaño, colores y demás características especificadas en el manual de señalización vial 2015 (capítulo 2, sección 2.7 Señales de mensaje variable).
Soporte • Los PMV deben contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje.
Interfaces • Interfaz física cableada de uso industrial.

ccccccc2
 

Figura 3. Estación de peaje: ubicación de semáforos, paneles de señalización variable y de la barrera automática de salida.

2.9.1.9. Señalización en los carriles IP/REV.

En los carriles IP/REV deberá existir una señalización vertical y horizontal para indicar los carriles a usar y las cabinas habilitadas para recibir cada forma de pago, cumpliendo los aspectos contemplados en el manual de señalización vial 2015 (capítulo 5 Otros dispositivos para la regulación del tránsito, sección 5.11 Señalización de estaciones de peaje), adoptado por el Ministerio de Transporte, sin perjuicio de lo anterior la señalización y por consiguiente su tamaño y ubicación debe permitir al usuario la fácil identificación de los carriles habilitados para el pago electrónico del sistema IP/REV.

Los requisitos para esto son los siguientes.

TipoDescripción
Funcional • Se deberán instalar elementos como:
— Reductores de velocidad: se instalarán elementos para realizar la transición de la velocidad del vehículo en carretera, a la requerida para la realización del cobro electrónico. Dichos reductores se instalarán de acuerdo a los aspectos contemplados en el manual de señalización vial 2015 (capítulo 5. Otros dispositivos para la regulación del tránsito, sección 5.8 Reductores de velocidad).
— Delineadores de piso: deberán contar con delineadores de piso que guíen al conductor en la circulación en la zona que pertenece al peaje, de acuerdo a los aspectos contemplados en el manual de señalización vial 2015 (capítulo 5 Otros dispositivos para la regulación del tránsito, sección 5.4 Delineadores de piso o elevados).
Usabilidad • Estos elementos tendrán los colores, tamaños y demás características especificadas en el manual de señalización vial 2015 (capítulo 5 Otros dispositivos para la regulación del tránsito y, sección 5.4 Delineadores de piso o elevados y sección 5.8 Reductores de velocidad).

TipoDescripción
Confiabilidad • Características especificadas en el manual de señalización vial 2015 (capítulo 5 Otros dispositivos para la regulación del tránsito, sección 5.4 Delineadores de piso o elevados y sección 5.8 Reductores de velocidad).
Rendimiento • La señalización de estaciones de peaje deberá garantizar que los usuarios seleccionen correctamente los carriles certificados para recibir cada forma de pago.
Soporte • Es necesario prever mantenimientos preventivos y/o correctivos de la señalización vertical y horizontal, durante el tiempo de funcionamiento en el peaje.
Interfaces • N.A.

2.9.1.10. Sistema para gestión de información de carril IP/REV.

Por cada carril IP/REV se deberá instalar en el peaje un dispositivo de cómputo integrado en el controlador de vía para recibir las lecturas procedentes de la unidad de lectura de dispositivos RFID. El dispositivo deberá soportar la ejecución de las siguientes tareas:

• Recepción de hasta 100 datos de dispositivos TAG RFID ISO 18000-63 por segundo provenientes de la unidad de lectura de dispositivos TAG RFID ISO 18000-63.

• Gestión de la base de datos local del carril IP/REV de los dispositivos TAG RFID. Lo anterior con el fin de acelerar el proceso de consulta durante el paso de un vehículo por un carril IP/REV del peaje. Los cambios realizados en la base de datos serán replicados al centro de control de la plaza de peaje. Esta arquitectura garantiza la independencia técnica entre carriles IP/REV previniendo la propagación de un fallo a los demás.

• Monitoreo del estado de funcionamiento de los elementos de la plaza de peaje, así como la capacidad de recibir de forma remota desde el COP los datos para alterar su funcionamiento.

• Controlar el funcionamiento de la barrera de salida o talanquera.

• Realizar el cifrado y descifrado de datos transferidos entre el centro de control de la plaza de peaje y el computador del carril IP/REV.

Los requisitos para dicho elemento son los siguientes.

TipoDescripción
Funcional • Deberá contar con características técnicas suficientes para ejecutar las tareas especificadas anteriormente.
 • La base de datos debe cumplir con los requisitos de base de datos definidos en el capítulo 2 “Especificación de Requisitos de Software”.
 • Deberá contar con sistemas de protección contra fallas en la red eléctrica.
 • Deberá contar con seguridad física para evitar actos vandálicos.
 • Deberá cumplir con el estándar IP66 de protección si está expuesto a la intemperie o IP54 si está protegido en un ambiente cerrado garantizando su operación entre -5ºC a +45ºC.
 • Los equipos deben cumplir con las exigencias del estándar FIPS 140-2 nivel 2 y las normas de compatibilidad electromagnética EMC clase A o su equivalente.
 • El reloj del equipo debe estar ajustado a la hora UTC-5 mediante protocolo NTP.
Confiabilidad • Componentes para gestión de la información de grado industrial y trabajo pesado.
Soporte • El sistema de cómputo para la gestión de información de carril IP/REV deberá contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje.
Interfaces • Interfaces físicas para la transmisión de datos RS232, Ethernet IEEE 802.3 con cable STP o con fibra óptica.

2.9.1.11. Red de transmisión de datos entre carril IP/REV (nivel 1) y centro de control de la plaza de peaje (nivel 2).

Los sistemas instalados en el carril IP/REV deberán comunicarse con el centro de control de la plaza de peaje a través de una red de comunicaciones Ethernet IEEE 802.3 que garantice la velocidad, integridad y seguridad de la información.

Los requisitos para este componente son los siguientes.

TipoDescripción
Funcional • Comunicaciones mediante canales con un ancho de banda que permita la transferencia de los datos entre los carriles IP/REV y el centro de control de la plaza de peaje; vídeo o secuencia de imágenes de la/s cámara/s para grabación de placa y ejes, reportes de transacciones, información de soporte para discrepancias y reportes de estado de funcionamiento de los equipos de carril IP/REV.
Usabilidad • Elementos de red entre unidad de gestión de información de carril IP/REV y centro de control de la plaza de peaje con protección de tipo industrial.
Confiabilidad • Los elementos empleados para la red deberán tener cada uno una disponibilidad del 99.9%, con una media de tiempo entre fallas (MTBF) no menor a 5 años.
Rendimiento • Capacidad de transmisión de datos de toda la información del carril IP/REV (video, imágenes, datos).
Soporte • Los elementos de red deben contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje.
Interfaces • Interfaces para la transmisión de datos IEEE 802.3 con medios de cobre o fibra óptica.

2.9.1.12. Red de transmisión de datos entre el centro de control de la plaza de peaje (nivel 2) y el COP (nivel 3).

La plaza de peaje debe disponer de un sistema de comunicaciones que le permita transferir al COP, la siguiente información:

• Vídeo de las cámaras de seguridad instaladas en el peaje, seleccionadas desde el COP.

• Reportes de estado de funcionamiento del peaje.

• Cobros realizados a los usuarios IP/REV del peaje.

• Reportes de discrepancias con evidencias (imágenes y/o vídeo).

Los requisitos para esto son los siguientes.

TipoDescripción
Funcional • Comunicaciones basadas en tecnología satelital y/o fibra óptica y/o microondas punto a punto, licenciadas y siempre que disponga de canales dedicados y privados con un ancho de banda que permita la transferencia de los datos requeridos de la plaza de peaje al COP.
• La información transferida deberá estar cifrada con un estándar igual o mejor al AES-256 a fin de garantizar la confidencialidad de dicha información.
Usabilidad • Los elementos de red de la plaza de peaje deberán contar con protección eléctrica de tipo industrial.
Confiabilidad • Los elementos empleados para la red deben tener una disponibilidad del 99%, con una media de tiempo entre fallas (MTBF) no menor a 5 años.
Rendimiento • Capacidad de transmisión de datos enumerados anteriormente.
Soporte • Los elementos de red deben contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje.
Interfaces • Dependiente del medio de transmisión ya sea para red interna o externa.

2.9.1.13. Instalaciones eléctricas.

Las instalaciones eléctricas son un elemento crítico del sistema IP/REV, puesto que estas alimentan a todos los equipos eléctricos presentes a nivel de carril IP/REV de los peajes.

Los requisitos para las instalaciones eléctricas son los siguientes:

TipoDescripción
Funcional • Todas las instalaciones eléctricas deben realizarse de acuerdo con lo establecido en las normas nacionales para tal fin, es decir, cumplir con la norma NTC 2050 y RETIE.
• De igual manera, todos los equipos eléctricos presentes a nivel de carril IP/REV de los peajes, deberán contar con las protecciones eléctricas a nivel de sobretensiones y cortocircuito.
Usabilidad • Se debe contar con un sistema de protección independiente para cada elemento electrónico a nivel de carril IP/REV.
Confiabilidad • Los componentes de las instalaciones eléctricas deben tener un MTBF igual o superior a 5 años.
Rendimiento • Las capacidades de los componentes del sistema eléctrico deberán estar en concordancia con las normas NTC 2050 y RETIE vigentes en Colombia y dimensionados para cada uno de los elementos que componen el carril IP/REV.
Soporte • Se deberá prever mantenimientos preventivos y/o correctivos de la infraestructura eléctrica, durante el tiempo de funcionamiento en el peaje.
Interfaces Interfaces físicas de tipo industrial.

2.9.1.14. Sistema de respaldo eléctrico.

Un sistema de respaldo eléctrico debe entrar en operación, en el evento de un fallo en el suministro de energía eléctrica.

Los requisitos para dicho sistema, son los siguientes.

TipoDescripción
Funcional • Se debe contar con un sistema de respaldo de energía eléctrica que permita la continuidad de las operaciones del puesto del carril IP/REV, en el evento de fallas en la red de suministro eléctrico, garantizando el pleno funcionamiento de todos los carriles IP/REV del peaje.
Usabilidad • El sistema debe activarse de forma automática, una vez detectada una falla en la red de suministro eléctrico.
Confiabilidad • El sistema de respaldo eléctrico debe tener un MTBF igual o superior a 5 años.
Rendimiento • El respaldo debe contar con una protección primaria a partir de fuentes ininterrumpidas de potencia con un soporte de mínimo 30 minutos y una fuente de respaldo secundario, mediante grupo electrógeno, con capacidad de respaldo de mínimo 24 horas.
Soporte • Es necesario prever mantenimientos preventivos y/o correctivos del sistema de respaldo de energía eléctrica, durante el tiempo de funcionamiento en el peaje.
Interfaces • Interfaces físicas cableadas de uso industrial.

2.9.1.15. Equipos de monitoreo meteorológico.

Se recomienda contar con equipos de monitoreo meteorológico que informen sobre las condiciones climatológicas. Los requisitos para estos equipos son los siguientes:

TipoDescripción
Funcional Se recomienda contar con equipos de monitoreo meteorológico que informen a los usuarios acerca del estado del viento, lluvia, neblina y temperatura. Los equipos de monitoreo meteorológico podrán ser los mismos que hayan sido instalados cumpliendo con los requisitos del contrato de concesión vial.
Usabilidad Equipos de monitoreo meteorológico de uso industrial y adecuado para las posibles condiciones de viento, lluvia, neblina y temperatura del territorio colombiano.
Confiabilidad Los equipos de monitoreo meteorológico deben tener un nivel de disponibilidad superior al 99% y un MTBF superior a 2 años.
Tipo Descripción
Rendimiento La información meteorológica debe ser enviada cada 5 minutos al centro de control de la plaza de peaje.
Soporte Los equipos de monitoreo meteorológico deben contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje.
Interfaces Interfaces físicas cableadas de uso industrial.

2.9.2. FRONT-END - Infraestructura para el servicio a nivel del centro de control de la plaza de peaje.

La función del centro de control de la plaza de peaje es recoger información de los carriles IP/REV del peaje para almacenar, validar y transmitir información recopilada al COP. De igual forma, deberá recibir información desde el COP para efectos de configurar la plaza de peaje. Se deberá garantizar la existencia de equipos de hardware y aplicaciones de software para soportar las siguientes funcionalidades:

2.9.2.1. Recopilación de la información de monitoreo y supervisión.

Se deberá garantizar la gestión, almacenamiento, consulta local y remota de imágenes y video de seguridad sobre la actividad general del peaje. Se debe también dar soporte para la recolección de información acerca del estado de funcionamiento de al menos: la unidad de lectura de dispositivos TAG RFID ISO 18000-63, sistema de reconocimiento de número de placa, cámaras de grabación de número de ejes, cámaras de seguridad, sensores de detección automática de la categoría del vehículo, equipos para pesaje automático de vehículos de carga (en caso de estar instalado), sistema para gestión de información de carril IP/REV (computador de carril IP/REV) y barrera de salida automática.

Los requisitos para el equipo de cómputo que realice esta tarea son:

TipoDescripción
Funcional • El equipo de cómputo debe garantizar el almacenamiento y visualización de toda la información de monitoreo y supervisión del peaje (videos, imágenes). El equipo debe contar con interfaces para la consulta remota desde el COP de toda la información de monitoreo y supervisión almacenada a nivel de la plaza de peaje.
• El equipo deberá contar con sistemas de protección contra fallas en la red eléctrica de forma independiente. De igual manera, deberá contar con seguridad física para evitar que actos vandálicos interfieran.
• Los equipos deberán cumplir con las exigencias del estándar FIPS 140-2 nivel 2 y las normas de compatibilidad electromagnética (EMC) clase A, o su equivalente.
• El reloj del equipo debe estar ajustado a la hora UTC-5 mediante protocolo NTP.
Usabilidad • El equipo de cómputo debe recibir información de monitoreo y supervisión del peaje (vídeos, imágenes) de toda la plaza de peaje y ser visualizados mediante el uso de pantallas dedicadas.
Confiabilidad • El equipo deberá contar con un esquema de redundancia que permita garantizar una disponibilidad de, al menos, el 99.9% de los equipos de cómputo que soporten estas tareas.
Rendimiento • El equipo deberá contar con procesador, memoria RAM y disco duro suficientes para el procesamiento, almacenamiento y visualización de toda la información de monitoreo y supervisión del peaje (vídeos, imágenes). Se recomienda gestionar las tareas descritas en equipos de cómputo separados de aquellos que realizan otras tareas en el centro de control de la plaza de peaje.
Soporte • El sistema de cómputo deberá contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje.
Interfaces • Interfaces físicas para la transmisión de datos Ethernet IEEE 802.3 con cable STP, o con fibra óptica.

2.9.2.2. Recopilación de información de volumen de tráfico y del paso de vehículos que transitan por el peaje con sus soportes.

El centro de control de la plaza de peaje deberá disponer de un sistema de cómputo que soporte la gestión para el procesamiento, almacenamiento y visualización de la información mencionada.

Los requisitos para los elementos de cómputo que realicen cada una de las tareas descritas son los siguientes:

TipoDescripción
Funcional • El equipo de cómputo deberá soportar el procesamiento, almacenamiento y visualización de toda la información de volumen de tráfico y cada paso de vehículos registrado con sus soportes (imágenes y video).
• El equipo deberá contar con interfaces para la consulta remota desde el COP de toda la información de volumen de tráfico y cada paso de vehículos registrado con sus soportes a nivel de plaza de peaje (imágenes y video).
• El equipo deberá contar con sistemas de protección contra fallas en la red eléctrica de forma independiente.
• El equipo deberá contar con seguridad física para evitar que actos vandálicos interfieran.
• Los equipos deberán cumplir con las exigencias del estándar FIPS 140-2 nivel 2 y las normas de compatibilidad electromagnética EMC clase A, o su equivalente.
• El reloj del equipo debe estar ajustado a la hora UTC-5 mediante protocolo NTP.
Usabilidad Los equipos de cómputo deben recibir toda la información descrita y ser visualizada mediante el uso de pantallas dedicadas.
Confiabilidad Los equipos de cómputo deben contar con un esquema de redundancia que permita garantizar una disponibilidad de, al menos, el 99.9% de los equipos de cómputo que soporten estas tareas.
Tipo Descripción
Rendimiento El equipo deberá contar con procesador, memoria RAM y disco duro suficientes para el procesamiento, almacenamiento y visualización de toda la información de volumen de tráfico, pesaje y cada paso de vehículos registrado con sus soportes (imágenes y video). Se recomienda gestionar las tareas descritas en equipos de cómputo separados de aquellos que realizan otras tareas en el centro de control de la plaza de peaje.
Soporte El sistema de cómputo deberá contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje.
Interfaces Interfaces físicas para la transmisión de datos Ethernet IEEE 802.3 con cable STP, o con fibra óptica.

2.9.2.3. Gestión de discrepancias.

El centro de control de la plaza de peaje deberá disponer de equipos de cómputo para gestionar las posibles discrepancias generadas en la plaza de peaje. Esta función también se podrá realizar a nivel de centro de operación de peajes (COP), centralizando a ese nivel la gestión de discrepancias de la concesión.

Los requisitos para los elementos de cómputo que realicen la gestión de discrepancias deben ser los siguientes:

TipoDescripción
Funcional • El equipo de cómputo debe soportar el procesamiento, almacenamiento y visualización para gestionar las posibles discrepancias generadas en la plaza de peaje.
• Deberán contar con interfaces para la consulta remota desde el COP de toda la información de las discrepancias generadas en la plaza de peaje.
• Deberá contar con sistemas de protección contra fallas de suministro en la red eléctrica de forma independiente.
• Deberá contar con seguridad física para evitar que actos vandálicos interfieran.
• Los equipos deben cumplir con las exigencias del estándar FIPS 140-2 nivel 2 y las normas de compatibilidad electromagnética EMC, clase A, o su equivalente.
• El reloj del equipo deberá estar ajustado a la hora UTC-5 mediante protocolo NTP.
Usabilidad • Los equipos de cómputo deberán ofrecer la posibilidad de gestionar las posibles discrepancias generadas en la plaza de peaje.
Confiabilidad • Deberán contar con un esquema de redundancia que permita garantizar una disponibilidad de al menos el 99.9% de los equipos de cómputo que soporten estas tareas.
Rendimiento • Deberá contar con procesador, memoria RAM y disco duro suficientes para el procesamiento, almacenamiento y visualización de las discrepancias generadas en la plaza de peaje. Se recomienda gestionar las tareas descritas en equipos de cómputo separados de aquellos que realizan otras tareas en el centro de control de la plaza de peaje.
Soporte • El sistema de cómputo deberá contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje.
Interfaces • Interfaces físicas para la transmisión de datos Ethernet IEEE 802.3 con cable STP, o con fibra óptica.

2.9.2.4. Gestión de la base de datos con información de los dispositivos TAG RFID activados.

El centro de control de la plaza de peaje deberá disponer de equipos de cómputo para garantizar la gestión de la base de datos de dispositivos TAG RFID activados. Los requisitos para los elementos de cómputo los cuales realicen cada una de las tareas descritas son los siguientes:

TipoDescripción
Funcional • El equipo de cómputo deberá soportar el procesamiento, almacenamiento y visualización para garantizar la gestión de la base de datos de dispositivos TAG RFID activados y que ha sido descargada desde los INT IP/REV. La base de datos de los dispositivos TAG RFID activados deberá estar cifrada con un algoritmo AES-256, o mejor.
• El equipo deberá contar con sistemas de protección contra fallas en la red eléctrica de forma independiente.
• El equipo deberá contar con seguridad física para evitar que actos vandálicos interfieran.
• El equipo deberá cumplir con las exigencias del estándar FIPS 140-2 nivel 2 y las normas de compatibilidad electromagnética EMC clase A o, su equivalente.
• El reloj del equipo deberá estar ajustado a la hora UTC-5 mediante protocolo NTP.
Usabilidad • El equipo de cómputo deberá garantizar la gestión de la base de datos de los dispositivos TAG RFID activados.
Confiabilidad • Se deberá contar con un esquema de redundancia el cual permita garantizar una disponibilidad de, al menos, el 99.9% de los equipos de cómputo que soporten estas tareas.
Rendimiento • El equipo deberá contar con procesador, memoria RAM y disco duro suficientes para procesamiento, almacenamiento para la gestión de la base de datos de dispositivos TAG RFID activados. Se recomienda gestionar las tareas descritas en equipos de cómputo separados de aquellos que realizan otras tareas en el centro de control de la plaza de peaje.
Soporte • El equipo de cómputo deberá contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje.
Interfaces • Interfaces físicas para la transmisión de datos Ethernet IEEE 802.3 con cable STP, o con fibra óptica.

2.9.2.5. Información de configuración de la plaza de peaje o punto de cobro.

El centro de control de la plaza de peaje deberá disponer de equipos de cómputo para la recepción desde el COP de información de tarifas y otro tipo de posibles configuraciones que se deriven para la correcta ejecución del sistema IP/REV de peajes.

Los requisitos para los elementos de cómputo que realicen cada una de las tareas descritas deben cumplir con los siguientes requisitos:

TipoDescripción
Funcional • El equipo de cómputo deberá soportar el procesamiento, almacenamiento y visualización para la recepción de tarifas y otro tipo de posibles configuraciones que se deriven para la correcta ejecución del sistema IP/REV.
• El equipo deberá contar con sistemas de protección contra fallas en la red eléctrica de forma independiente.
• El equipo deberá contar con seguridad física para evitar que actos vandálicos interfieran.
• El equipo deberá cumplir con las exigencias del estándar FIPS 140-2 nivel 2 y las normas de compatibilidad electromagnética EMC clase A o, su equivalente.
• El reloj del equipo deberá estar ajustado a la hora UTC-5 mediante protocolo NTP.
Usabilidad • El equipo deberá garantizar la recepción de tarifas y otro tipo de posibles configuraciones que se deriven para la correcta ejecución del sistema IP/REV de peajes.
Confiabilidad • Se deberá contar con un esquema de redundancia que permita garantizar una disponibilidad de, al menos, el 99.9% del equipo de cómputo que soporte estas tareas.
Rendimiento • El equipo deberá contar con procesador, memoria RAM y disco duro suficientes para la recepción de tarifas y otro tipo de posibles configuraciones que se deriven. Se recomienda gestionar las tareas descritas en un equipo de cómputo separado de aquellos que realizan otras tareas en el centro de control de la plaza de peaje.
Soporte • El sistema de cómputo deberá contar con soporte técnico y capacidad de suministro por parte del fabricante y/o proveedor durante el tiempo de funcionamiento en el peaje.
Interfaces • Interfaces físicas para la transmisión de datos Ethernet IEEE 802.3 con cable STP, o con fibra óptica.

2.9.2.6. Sistema de respaldo eléctrico.

El centro de control de la plaza de peaje deberá contar con un sistema de respaldo de energía eléctrica que permita la continuidad de todas las operaciones del centro de control de la plaza de peaje, en el evento de fallas en el suministro de energía eléctrica, garantizando el pleno funcionamiento de todas sus funciones. Los requisitos para dicho sistema son los siguientes:

TipoDescripción
Funcional • Se deberá contar con un sistema de respaldo de energía eléctrica que permita la continuidad de las operaciones del centro de control de la plaza de peaje, en el evento de fallas en el suministro de la red eléctrica garantizando el pleno funcionamiento de todos los carriles IP/REV del peaje.
Usabilidad • El sistema deberá activarse de forma automática, una vez detectada una falla en el suministro de la red eléctrica.
Confiabilidad • El sistema de respaldo eléctrico deberá tener un MTBF, igual o superior a 5 años.
Rendimiento • El respaldo deberá contar con una protección primaria a partir de fuentes ininterrumpidas de potencia con un soporte de mínimo 5 minutos y un conmutador automático de respaldo secundario, mediante grupo electrógeno con capacidad de respaldo de mínimo 24 horas.
Soporte • Se deberá prever mantenimientos preventivos y/o correctivos del sistema de respaldo de energía eléctrica, durante el tiempo de funcionamiento en el peaje.
Interfaces • Interfaces físicas cableadas de uso industrial.

Elementos del sistema IP/REV DEL INT IP/REV

Un sistema de BackOffice típico define el cuarto nivel lógico donde se resuelven las transacciones recibidas dando como resultado el recaudo de la tarifa de peaje al cliente dueño del TAG RFID correspondiente.

• Nivel 4: BackOffice.

El BackOffice se divide en BackOffice Operacional y BackOffice Comercial.

BackOffice Operacional del INT IP/REV

Es el software o conjunto de programas donde se reciben las transacciones de los distintos OP IP/REV y se agrupan en los correspondientes TAG RFID.

El BackOffice Operacional debe ser capaz de resolver, entre otras, las siguientes funciones:

• Consolidación automática y manual de transacciones,

• Realizar la gestión de posibles excepciones.

BackOffice Comercial del INT IP/REV

Es el software o conjunto de programas donde se recibe el conjunto de transacciones consolidadas por TAG RFID, y se produce el cobro mediante la asignación de dichas transacciones al cliente correspondiente, considerando el tipo de cobro que ha elegido y con el que está registrado en la base de datos del INT IP/REV.

El BackOffice Comercial debe ser capaz de resolver, entre otras, las siguientes funciones:

• Administración de las cuentas de los clientes IP/REV.

• Facturación de los tránsitos, según la periodicidad requerida por el medio de pago con que el cliente IP/REV está registrado.

• Manejo de las interfaces externas que requiera, por ejemplo, acceso a bancos, tarjetas de crédito y débito, fondos depositados como prepagos, etc.

• Administración de deudores.

• Generación de reportes financieros.

• Comunicación con el cliente IP/REV a través de un CRM (Customer Relation Management), que incluya como mínimo:

a) Portal web;

b) Centro de contacto de atención personalizada y telefónica (IVR, CTI, etc.).

Módulo de logística, que administre para los TAG RFID:

a) Proveedores;

b) Stock y almacenaje;

c) Administración del ciclo de vida del TAG RFID.

• Gestión documental,

• Gestión de discrepancias recibidas por los clientes IP/REV, que deben ser resueltas accediendo a las pruebas de imagen y/o video correspondientes a la transacción en disputa, que residen en la BBDD del OP IP/REV que ha sido origen de la transacción,

• Conexión con los programas financieros del INT IP/REV.

• Business Intelligence.

Adicionalmente, el INT IP/REV puede contar con aplicativos que le permitan explotar su base de datos de clientes en otros negocios, aprovechando la plataforma tecnológica que le ofrece este nuevo medio de identificación vehicular asociado a un medio de pago.

Procedimientos relativos al TAG RFID en el sistema IP/REV.

Dentro del desarrollo de su gestión el INT IP/REV deberá informar al sistema de gestión la activación y desactivación de los TAG.

Procedimiento para la adquisición de un TAG.

Para el proceso de adquisición de un TAG RFID, el usuario deberá presentar al INT IP/REV como mínimo su documento de identidad, la tarjeta de propiedad del vehículo vigente en el que se instalará el TAG RFID. El intermediador deberá garantizar la lectura del TAG RFID para todo tipo de vehículo.

(Nota: Modificado el procedimiento para la adquisición de un TAG por la Resolución 3254 de 2018 artículo 5° del Ministerio de Transporte)

Procedimiento para reposición de un TAG.

En el evento de un daño o pérdida del TAG RFID, el usuario deberá notificar al intermediador sobre la novedad, mediante cualquiera de los canales dispuestos por el mismo, a fin de que este último lo desactive y le suministre uno nuevo de acuerdo a las condiciones acordadas en el contrato entre las partes.

Anexo financiero 2

Liquidez: Activo corriente sobre pasivo corriente.

El índice de liquidez del actor estratégico debe ser igual o superior 1.2 veces

Para estos efectos el actor estratégico deberá diligenciar el siguiente formato:

Indicador de liquidez
Activo corriente a 31 de diciembre del año inmediatamente anterior  
Pasivo corriente a 31 de diciembre del año inmediatamente anterior  
Indicador de liquidez  

Para calcular este indicador en los actores estratégicos con múltiples roles se sumarán los activos corrientes de los líderes y se dividirá ese resultado por la sumatoria de sus pasivos corrientes.

Nivel de endeudamiento: Pasivo total sobre activo total

El nivel de endeudamiento del actor estratégico debe ser igual o inferior al 70%.

Para estos efectos el actor estratégico deberá diligenciar el siguiente formato:

Indicador de endeudamiento
Pasivo total a 31 de diciembre del año inmediatamente anterior 
Activo total a 31 del año inmediatamente anterior. 
Indicador de endeudamiento. 

Para calcular este indicador en los actores estratégicos con múltiples roles se sumarán los pasivos totales de los líderes y se dividirá el resultado de la sumatoria de sus activos totales.

Razón de cobertura de intereses: EBITDA / Gastos de intereses

La razón de cobertura del actor estratégico debe ser igual o superior a 1.3 veces

Para estos efectos el actor estratégico deberá diligenciar el siguiente formato:

Razón de cobertura de intereses
EBITDA a 31 de diciembre del año inmediatamente anterior 
Gastos de intereses a 31 de diciembre del año inmediatamente anterior 
Razón de cobertura de intereses 

Para los actores estratégicos con múltiples roles será el resultado de la sumatoria de la utilidad operaciones de los líderes dividida por la sumatoria de sus gastos de intereses. En caso de que el resultado de este cálculo para un actor estratégico con roles únicos o múltiples presente este indicador sea indeterminado porque no tuvo gastos de intereses, el actor estratégico será certificado.

Nota: El presente indicador deberá ser cumplido de manera individual por la totalidad de los integrantes de las estructuras plurales.

Rentabilidad sobre activos: EBITDA sobre total activos

La rentabilidad sobre activos del actor estratégico debe ser mayor o igual a 3%

Para estos efectos el actor estratégico deberá diligenciar el siguiente formato:

Indicador rentabilidad sobre activos
EBITDA a 31 de diciembre del año inmediatamente anterior 
Activo total a 31 de diciembre del año inmediatamente anterior 
Indicador rentabilidad sobre activos 

Nota: El presente indicador deberá ser cumplido de manera individual por la totalidad de los integrantes de las estructuras plurales.

Rentabilidad sobre patrimonio: Utilidad operacional sobre el patrimonio.

La rentabilidad sobre patrimonio del actor estratégico debe ser mayor o igual a 3%.

Para estos efectos el actor estratégico deberá diligenciar el siguiente formato:

Indicador rentabilidad sobre patrimonio
EBITDA a 31 de diciembre del año inmediatamente anterior 
Patrimonio a 31 de diciembre del año inmediatamente anterior 
Indicador rentabilidad sobre patrimonio 

NOTA: El presente indicador deberá ser cumplido de manera individual por la totalidad de los integrantes de las estructuras plurales.

Anexo Colpass 3

La utilización de la marca de interoperabilidad COLPASS en papelería, avisos, TAG, o en cualquier medio de comunicación digital o físico de una actividad o servicio determinado y la publicidad alusiva al mismo que se haga por parte de los actores estratégicos, debe hacerse cumpliendo con las condiciones que se describen a continuación y la imagen de la marca de interoperabilidad COLPASS, que se describe en la presente resolución.

Estas condiciones aplican para todo uso que un INT IP/REV vaya a hacer con el TAG, bien sea dentro del sistema IP/REV, como para cualquier otro servicio de valor añadido que un INT IP/REV, quiera proporcionar a sus usuarios.

Descripción y color

El logo COLPASS, en su sílaba COL es de color naranja, color que representa al Ministerio de Transporte. La sílaba PASS es de color azul y presenta una modificación que transmite agilidad y velocidad.

A continuación, se establecen las equivalencias del color de la Marca.

ccccccc3
 

Tipografía

La sílaba COL está elaborada con la tipografía Franklin Gothic Heavy Italic y la sílaba PASS con variaciones de la tipología Museo Sans 900 y modificaciones que indican velocidad. Todas las letras de la marca de interoperabilidad COLPASS deben ir en letra mayúscula.

ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
0123456789!@#$%^&*()01234567890!@#$%^&*()
Franklin Gothic Heavy ItalicMuseo Sans 900 Italic

Proporciones de tamaño

La marca de interoperabilidad COLPASS debe cumplir con las siguientes proporciones:

• La altura (h1) de las letras C, O, L, A y S serán 0.167 veces el ancho (w) de la palabra COLPASS

• La altura (h2) de la letra P en la sílaba PASS será 0.18 veces el ancho (w) de la palabra COLPASS

ccccccc4
 

— A manera de ejemplo se ilustra el siguiente diseño, guardando las proporciones de tamaño entre el ancho y el alto permitidas.

ccccccc5
 

Versiones de color

Dentro de las opciones de aplicación de la marca, está el uso en blanco, en negro y en gris, y su uso se limita a papelería. Estas son sus equivalencias:

ccccccc6
 

Área de seguridad

Se ha creado un espacio de protección para la marca con el objetivo de evitar que sea invadida por elementos que le son ajenos. Este espacio equivale a la letra C de “COL” y se distribuye por todos sus costados, como lo ilustra la gráfica. Ningún texto, elemento o imagen debe invadir el área de seguridad. Se establece una medida de seguridad para conservar su lectura en medios impresos o digitales.

ccccccc7
 

Tamaño mínimo de reducción

Para los casos en los que se deba reducir el logo para ser utilizado en papelería, su tamaño mínimo será de 3.0 cm de ancho incluyendo su área de seguridad (el alto se dará guardando las proporciones estipuladas en el presente decreto); sin embargo, podría tener un tamaño de 2.5 cm x 0.6 cm (incluyendo áreas de seguridad si se desea incluir el logo del intermediador).

ccccccc8
 

Aplicación sobre fondos

El único color autorizado para ser utilizado como fondo es el color blanco.

Usos incorrectos

Cualquier reproducción se guiará de forma disciplinada en las aplicaciones de la Marca, según las especificaciones de la presente resolución. De manera ilustrativa se muestran diseños incorrectos:

ccccccc9
 

Exhibición de la marca de interoperabilidad COLPASS

El OP IP/REV certificado deberá exhibir la marca de interoperabilidad ColPass en las vías IP/REV, de la misma manera tanto el OP IP/REV como el INT IP/REV deberán exhibir la marca en los medios y papelería publicitarios relacionados al uso de los peajes electrónicos IP/REV.

Las vías de peaje IP/REV deben tener el logo de COLPASS situado en la marquesina, solo y de tamaño visible, para que los usuarios identifiquen inequívocamente que esa vía es parte de la red de IP/REV.

Exclusividad del texto

La marca de interoperabilidad, utilizada por las personas certificadas por el Ministerio de Transporte y autorizadas para el uso de la marca, no podrá ir acompañada de ningún texto diferente al permitido en esta reglamentación.

Texto

Al interior de la marca de interoperabilidad y en su espacio de seguridad, no podrá incluir ningún tipo de información diferente a los diseños reglamentados en la presente resolución.

Publicidad

La publicidad hecha por los usuarios deberá responder igualmente a los diseños reglamentados en la presente resolución.

Anexo 4

Oferta básica de interoperabilidad del sistema (IP/REV)

Aspectos generales

(Descripción de la empresa intermediador u operador). En esta parte del documento el intermediador y/u operador deberá describir de forma detallada el nombre de la empresa, razón social, NIT, dirección, teléfono de comunicaciones, correo electrónico, así como los datos del actor estratégico serán publicadas en un medio de difusión físico o electrónico a escogencia del actor, pero que en todo caso se encuentre disponible para su consulta en todo momento por parte de los interesados.

Objeto

La presente oferta básica de interoperabilidad (OBIP), constituye las condiciones mínimas que deben regir la relación entre los actores estratégicos quienes la pondrán en conocimiento general y que contiene los elementos esenciales para lograr la interoperabilidad entre (nombre del operador o intermediador) y otros actores estratégicos.

Normas aplicables

Son aplicables a la presente oferta básica de interoperabilidad (OBIP), las condiciones dispuestas entre otras de forma general en el Código Civil Colombiano, el Código de Comercio Colombiano, para efectos de la relación contractual. En especial y para las condiciones de Interoperabilidad las dispuestas en el artículo 84 de la Ley 1450 de 2011, la Ley 1480 de 2011, el Decreto 2060 de 2015 y la presente resolución o las normas que las modifiquen, adicionen o sustituyan.

Vigencia de la oferta

La presente oferta básica de interoperabilidad (OBIP), se mantendrá vigente entre las partes durante el término dispuesto en la certificación emitida por el Ministerio de Transporte para la utilización de la marca COLPASS. El retiro del sistema de IP/REV por parte de un actor estratégico certificado deberá realizarse en los términos y condiciones dispuestas en la normatividad vigente y las disposiciones de esta oferta y en todo caso con previo aviso a la parte contraria.

Condiciones básicas aplicables a las relaciones contractuales de los actores estratégicos

Como una forma de garantizar la Interoperabilidad del sistema y en pro de la protección de los usuarios de los sistemas de recaudo electrónico de peajes los actores estratégicos deberán como mínimo establecer en sus relaciones contractuales los aspectos que se definen a continuación:

Condiciones aplicables al operador

Los niveles de servicio para la prestación del servicio de recaudo electrónico vehicular de peajes, que debe cumplir el operador como mínimo deberán garantizar:

ÍtemDescripciónValor de AceptaciónFrecuencia de Medida
1Colas: El operador IP/REV deberá permitir el tránsito de por lo menos trescientos (300) vehículos/hora/carril, sin que se presenten acumulaciones en un mismo carril de vehículos que detienen su marcha de manera simultánea, para pagar la tasa de peaje superiores a diez (10) vehículos para la categoría primera y de cinco (5) vehículos para las demás categorías que se encuentran en servicio, por un periodo igual o mayor a sesenta (60) minutos. Tránsito de vehículos: vehículos/hora/carril >= 300
Vehículos en Cola: Categoría I <= 10 y
Categorías II, III, IV, V y demás <= 5
Cada vez que se presenten colas.

ÍtemDescripciónValor de AceptaciónFrecuencia de Medida
2Disponibilidad del sistema dispuesto para la operación del (IP/REV): Es la habilidad del sistema para realizar las siguientes funciones acordadas cuando sean requeridas: gestionar las transacciones que se originen en las plazas de peajes y así como la actualización de las listas de usuarios, y demás propias del operador IP/REV. 99% es la disponibilidad mensual del servicio en %, con una cifra decimal. Mensual
3Compensación al intermediador: Consignación de los costos de intermediación. Se aclara que, en caso de disputas, sólo se dejará de pagar el dinero que se encuentre en controversia, lo demás deberá ser garantizado por el operador IP/REV al intermediador IP/REV.
En caso contrario el intermediador podrá hacer efectivas las garantías acordadas.
Máximo 30 días desde la consignación de la tasa de peaje el 100% del costo de intermediación Mensual
4Tiempo de envío de documentación al intermediador respecto de PQRSF presentadas 3 días hábiles a partir de la solicitud del intermediador Con cada evento de PQR

Las anteriores condiciones de niveles de servicio se establecen como un factor mínimo de cumplimiento para los operadores. Sin embargo, los operadores deberán cumplir con los niveles de servicio establecidos en los respectivos contratos de concesión y aquellos deberán estar reflejados en las relaciones contractuales que establezcan con los intermediadores IP/REV.

En la relación contractual que establezca el intermediador IP/REV y el operador IP/REV deberá definirse que el traslado de recursos del intermediador IP/REV hacia el operador IP/REV por concepto recaudo electrónico vehicular de las tarifas de peaje deberá darse en los términos dispuestos por el respectivo contrato de concesión.

Condiciones aplicables al intermediador

Como mínimo en la prestación del servicio de recaudo electrónico vehicular de Peaje el intermediador deberá garantizar para la gestión de los datos de la operación las condiciones establecidas en el anexo 5 - Especificaciones de Interoperabilidad de la presente resolución.

Así mismo deberá cumplir con:

ÍtemDescripciónValor de aceptaciónFrecuencia de medida
1Disponibilidad del sistema dispuesto para la operación del (IP/REV):
Es la habilidad del sistema para realizar las siguientes funciones acordadas cuando sean requeridas:
(i) Apertura de la cuenta IP/ REV, (ii) Asociación de los vehículos a las cuentas creadas, (iii) Recarga en las modalidades y medios de pago reglamentadas, (iv) actualización y envío de las listas a las bases de datos, y (v) demás propias del intermediador IP/REV.
99% es la disponibilidad mensual del servicio en %, con una cifra decimal. Mensual
2Compensación operador: Consignación de la tasa de peaje por concesión, en las condiciones pactadas en los contratos de concesión o en el patrimonio autónomo del proyecto de concesión según aplique. Dentro de las condiciones pactadas en los contratos de concesión y en caso de no existir el 100% del recaudo electrónico vehicular por concesión, en un término no superior a los tres (3) días hábiles siguientes desde el tránsito del vehículo por la plaza de peaje. Mensual

Condiciones mutuas a establecerse entre los operadores y los intermediadores

a) Los actores estratégicos establecerán las condiciones y reglas bajo las cuales se prestarán el servicio de IP/REV, con estricta sujeción a las condiciones establecidas por el Ministerio de Transporte. En dicho acuerdo las partes señalarán sus obligaciones, los protocolos y plazos para el cumplimiento, el régimen de responsabilidad y distribución de riesgo, entre otras;

b) A efectos de proteger a los usuarios del servicio de IP/REV y evitar la interrupción del servicio prestado a estos, ningún actor estratégico salvo por condiciones de fuerza mayor o caso fortuito, podrá dejar de prestar su servicio de IP/REV definitivamente a los otros actores o hacerlo unilateralmente sin haber tomado las medidas del caso respecto de los usuarios, los intermediadores o los operadores vinculados. La parte interesada en la cesación del servicio deberá avisar a las otras Partes incluido el Ministerio de Transporte con al menos sesenta (60) días anteriores a la cesación definitiva.

La interrupción del servicio de IP/REV por falta de pago de la compensación tanto a los operadores IP/REV, como a los intermediadores IP/REV, deberá ser autorizada por el mecanismo de resolución de disputas que se haya establecido por las partes, o en su defecto por la autoridad jurisdiccional competente. Lo anterior, sin perjuicio de la ejecución de las garantías acordadas por las partes, para respaldar el cumplimiento de sus obligaciones. La interrupción del servicio por falta de pago declarada por la autoridad jurisdiccional competente será causal de pérdida de la certificación y, por consiguiente, la utilización del derecho al uso de la marca COLPASS;

c) Cuando por condiciones técnicas los actores estratégicos IP/REV deban realizar ventanas de mantenimiento parciales, el respectivo actor estratégico deberá informar con al menos tres (3) días calendario de anticipación a sus actor(es) contraparte(s) del suceso, con la finalidad que estas tomen las acciones del caso. El actor estratégico acordará con su contraparte la duración de la ventana de mantenimiento que se vaya a realizar. En ningún caso los intermediadores y/u operadores podrán dejar de prestar el servicio e intercambiar las listas o transacciones con sus contrapartes. En caso de cesar las actividades que se desprenden de la certificación como actor estratégico deberá tomar las medidas correspondientes con una anticipación no menor a sesenta (60) días hábiles antes del día del cese definitivo respecto de los demás actores estratégicos;

d) Los actores Estratégicos serán responsables y deberán asumir los costos, daños y perjuicios que ocasionen a sus contrapartes y/o a los usuarios del sistema IP/REV por el incumplimiento de sus obligaciones, en particular, las relacionadas con la actualización de las listas de usuarios y transacciones. El actor estratégico que no actualice las listas de usuarios o de transacciones o las utilice desactualizadas será responsable de las transacciones que no sean reconocidas por los usuarios;

e) En caso de que el operador IP/REV, por razones que le sean imputables, no pueda verificar el TAG del usuario, podrá habilitar mecanismos de contingencia para realizar la identificación del usuario, o su vehículo previo a la autorización de su Paso. Posteriormente, trasmitirá al respectivo Intermediador la información de la transacción, a fin de que este gestione su cobro. En el evento, que la transacción no sea reconocida por el usuario y este niegue el pago, el operador IP/REV será el responsable del mismo;

f) Aquellas dispuestas en el anexo 5 - Especificaciones de interoperabilidad de la presente resolución.

Cronograma de labores para el desarrollo de la interoperabilidad

Con la finalidad de establecer la interoperabilidad del sistema IP/REV, los actores estratégicos deberán establecer un cronograma de actividades que como mínimo contenga los siguientes hitos:

1. Pruebas técnicas internas para cada actor estratégico previamente a la certificación.

2. Pruebas con el SiGT previamente a la certificación.

3. Acordar un plan de pruebas entre operadores e intermediadores conforme a los requerimientos del sistema IP/REV.

4. Realizar pruebas piloto de intercambio de información entre operadores e intermediadores una vez certificados en un plazo máximo de 10 días calendario.

Acuerdo de confidencialidad

Los operadores IP/REV e intermediadores IP/REV deberán acordar las condiciones de manejo de información confidencial, cuando aquella esté dispuesta en la ley, así como la necesaria para la protección de datos de los usuarios y/o consumidores, cuando a ello hubiere lugar.

Resolución de controversias

En este aparte de la oferta básica de interoperabilidad (OBIP), las partes deberán establecer los mecanismos e instancias que mejor convengan para la solución de sus controversias, en caso de no establecerlas, la resolución de controversias estará sujeta a las reglas ordinarias para la solución de controversias entre particulares.

Cesión de los efectos de la oferta básica de interoperabilidad (OBIP)

Ninguna de las partes podrá ceder total o parcialmente los derechos que se deriven de la presente oferta, salvo autorización previa, expresa y escrita de la otra parte. La parte que reciba la solicitud de cesión deberá dar respuesta a la otra en un término no mayor a quince (15) días hábiles. En caso de que alguna de las partes cambie su naturaleza jurídica, se transforme, fusione o escinda, se entenderá que el contrato continuará su ejecución y que los derechos y obligaciones contractuales quedarán en cabeza de la persona jurídica que como consecuencia de la transformación, fusión, escisión o cambio de naturaleza jurídica deba asumirlos.

En todo caso la cesión de los efectos contractuales no se podrá realizar en una persona que no se encuentre certificada como actor estratégico del sistema en los términos de la Resolución XX de 2017.

Garantías

Para asegurar el pago de obligaciones entre el intermediador IP/REV y el operador IP/REV y viceversa, los actores estratégicos deberán establecer garantías entre ellos de conformidad con unos montos mínimos de las operaciones que se prevean y en consideración a su modelo de negocio. Esas garantías deberán adicionalmente prever los perjuicios que puedan causarse y deban repararse o indemnizarse con ocasión del incumplimiento de alguno de los actores estratégicos.

Como mínimo los actores estratégicos deberán establecer:

1. Garantías por incumplimiento de sus obligaciones como intermediador y/o operador dependiendo el rol ejercido tales como seguros de cumplimiento. Cuando se ejerzan ambos roles se deberá determinar un monto mínimo de aseguramiento.

2. Garantías por incumplimiento en el pago de las obligaciones dinerarias de cada uno de los actores estratégicos, calculadas en un volumen mínimo de transacciones informadas por el operador, tales como una cuenta de fondo de reserva en los fideicomisos que se utilicen como vehículo para prestar el servicio IP/REV, depósitos en garantía en establecimientos de crédito, otras garantías que puedan estructurarse en consideración al patrimonio de los deudores y el modelo de negocio.

3. Garantías por daños a terceros y de responsabilidad civil, tales como seguros de responsabilidad civil extracontractual.

Las garantías que se constituyan para respaldar el cumplimiento de las obligaciones dinerarias de los actores estratégicos no podrán consistir ni recaer sobre los recursos administrados y destinados específicamente por los usuarios al pago electrónico de peajes REV.

Perfeccionamiento

Una vez cruzada la primera lista entre un intermediador y un operador a través del sistema de IP/REV se entenderán perfeccionadas las condiciones mínimas de la oferta básica de interoperabilidad (OBIP).

Impuestos y derechos

Los impuestos, tasas, derechos y contribuciones que se causen con ocasión de la celebración, ejecución, modificaciones, prórrogas, liquidación o terminación de la relación contractual o la aceptación de las condiciones, estarán a cargo y deberán ser cancelados por la parte que esté obligada a ello por disposición de la ley, respetando en todo caso lo establecido sobre el particular en las normas tributarias de carácter obligatorio que sean aplicables. En caso de que en virtud de la presente oferta haya lugar al pago del impuesto de timbre, este será asumido por partes iguales entre los contratantes y en cumplimiento del estatuto tributario vigente a la fecha de la liquidación del mismo.

Anexo 5

Especificaciones de interoperabilidad

V1.0

1. Introducción.

1.1. Objetivo.

Esta especificación de integración para interoperabilidad de recaudo electrónico de peajes (IP/REV) describe los mecanismos y requerimientos para el intercambio de información que deben seguir los actores INT-OP/REV y OP-IP/REV para conformar el requerimiento de interoperabilidad nacional a través de integraciones punto a punto.

Algunas de las integraciones expuestas en el presente documento podrán ser utilizadas para las conexiones obligatorias que los actores OP-IP/REV e INT-IP/REV deben realizar con el sistema SIGT del Ministerio de Transporte o el sistema de información designado por el Ministerio de Transporte.

1.2. Terminología.

Para facilidad del entendimiento de este documento, se establece la siguiente terminología de uso común, subconjunto del glosario de terminología establecido para el sistema IP/REV.

Término / AbreviaturaDescripción
TAG Dispositivo electrónico de identificación que almacena información única relacionada a una cuenta de usuario y que posee un número único de identificación.
USUARIO Persona natural o jurídica, que utiliza el sistema de telepeaje, al transitar con un vehículo y un TAG por un carril dinámico
En este documento, un usuario equivale a 1 TAG y 1 vehículo inscrito en 1 intermediador
INT IP/REV (Intermediador) Concesión o entidad propietario original del TAG, y que mantiene el control de la cuenta del usuario. En el contexto de esta aplicación, el INT-IP/REV es responsable de: i)Entrega y activación del dispositivo; ii) Gestionar las recargas y/o cobros al usuario; iii) mantener el saldo de la cuenta del usuario; iv) Actualizar la información del dispositivo
Término / AbreviaturaDescripción
OP IP/REV (Operador) Concesión u operador de una red de peajes, que bajo un acuerdo de interoperabilidad, permite el paso de usuarios de un usuario adscrito a un INT-IP/REV por sus peajes. Es responsable de: i) Operar el peaje IP/REV; ii) Garantizar el funcionamiento del peaje IP/REV
TRANSACCIÓN DE PASO Se considera una transacción de paso aquella correspondiente al cobro por el paso por un peaje
TRANSACCIÓN DE AJUSTE Se considera una transacción de ajustes la corrección de cobro a un paso por peaje emitida por el OP IP/REV. Un ajuste puede ser por mayor o menor valor
SALDO Es el valor de la cuenta para usuarios tipo prepago
SALDO BAJO Es una convención entre el usuario y su intermediador. El saldo bajo ocurre cuando el valor del saldo está por debajo de un umbral convenido, expresado como valor. El INT IP/REV es quien determina que una cuenta está con saldo bajo, y no el OP IP/REV
TRANSACCIÓN VENCIDA Es una transacción recibida en el INT IP/REV con una diferencia de tiempo con respecto a la fecha real de ocurrencia mayor a 30 minutos.
TRANSACCIÓN EXTEMPORÁNEA Es una transacción de paso o ajuste que se recibe posterior al cierre y conciliación del recaudo del día.
ANS Acuerdo de Nivel de Servicio. Son los compromisos aceptados para la prestación de un servicio. En el contexto del IP/REV definirán aspectos como tiempos mínimos y máximos de envío de información, disponibilidades de canales de comunicación, entre otros
IU Procesos de intercambio de información de usuarios
IT Procesos de intercambio de información de transacciones

1.3. Convenciones.

En los diagramas:

— El color azul indica procesos o servicios del INT IP/REV.

— El color verde indica procesos o servicios del OP IP/REV.

1.4. Referencias.

Los siguientes documentos están referenciados en este documento:

• Resolución con la cual se reglamenta la Interoperabilidad de Peajes con Recaudo electrónico vehicular (IP/REV).

2. Planteamiento general y consideraciones.

2.1. Intercambios de información.

La información que intercambian los actores OP IP/REV e INT IP/REV se pude agrupar en diferentes contextos de información:

2.1.1. Información sobre usuarios.

Dentro de este contexto, la información que los actores intercambiarán podrá estar compuesta de:

— Listas completas de usuarios activos.

— Listas de usuarios inactivos.

— Listas parciales de novedades sobre los usuarios incluyendo.

• Cambios de estados, saldos u otra información relevante.

• Inscripciones de nuevos usuarios.

• Bajas permanentes de usuarios.

— Notificaciones de actualizaciones de listas.

— Notificaciones de errores al procesar información de los usuarios.

— Información sobre las listas generadas en un periodo determinado.

2.1.2. Información sobre transacciones.

Dentro de este contexto, la información que los actores intercambiarán podrá estar compuesta de:

— Transacciones de paso por peajes.

— Transacciones de ajuste a cobros imputados.

— Confirmaciones de aceptación de transacciones de paso o de ajuste.

— Listados periódicos acumulados de transacciones.

— Notificación de errores al procesar información de transacciones.

2.1.3. Información sobre disputas.

Dentro de este contexto, la información que los actores intercambiarán podrá estar compuesta de:

— Registro de transacciones en disputa.

— Evidencia fotográfica de tránsitos.

— Informes de transacciones con evidencias.

— Otros (por definir).

2.1.4. Información sobre conciliaciones.

El alcance de esta primera versión de especificación no da cobertura a los procesos de conciliación entre OP IP/REV e INT IP/REV mediante integración, sin embargo, hace parte de los objetivos de siguientes versiones de este documento.

2.2. Flujos generales y responsabilidades.

La integración entre OP IP/REV e INT IP/REV tiene los siguientes planteamientos base al respecto de los flujos de información y las responsabilidades sobre los mismos.

— El INT IP/REV deberá generar listas totales (blancas y negras) y listas parciales de usuarios con la periodicidad, nomenclatura y contenido definidos en el presente documento.

— El INT IP/REV deberá notificar a los OP IP/REV la existencia de nuevas listas de actualización disponibles a través de los servicios definidos.

— El OP IP/REV deberá solicitar las listas al INT IP/REV a través de los servicios definidos y llevar un registro ordenado de la obtención y procesamiento de las mismas.

— El OP IP/REV deberá respetar unas reglas de secuencialidad a la hora de obtener y procesar las listas obtenidas del INT IP/REV.

— El OP IP/REV deberá reportar al INT IP/REV cuando no sea posible procesar algunos de los usuarios reportados por este último.

— El OP IP/REV deberá reportar al INT IP/REV las negaciones de autorización de paso que ocurran en la vía sobre sus usuarios.

— El OP IP/REV debe permitir el paso de los usuarios notificados por el INT-IP/ REV. Siempre que las condiciones de saldo y estado lo permitan.

— El OP IP/REV es responsable de notificar al INT IP/REV las transacciones y/o ajustes que ocurran en el peaje, según la periodicidad definida para la recepción y envío de información entre OP IP/REV e INT IP/REV y los ANS.

— El INT IP/REV deberá confirmar el recibo y procesamiento (exitoso o no) al OP IP/REV, de las transacciones recibidas por parte del OP IP/REV.

— El OP IP/REV deberá generar diariamente una lista acumulada de registros que contenga todas las transacciones de cobro y/o ajuste generadas el día anterior (día peaje) que serán la base para realizar conciliaciones técnicas entre los actores. El INT IP/REV será responsable de cotejar esta información con su sistema de información.

— Sobre los diferentes procesos de intercambio de información se estructurarán una serie de ANS para garantizar el mejor funcionamiento posible del Sistema IP/ REV.

2.3. Consideraciones al modelo prepago y la asincronía del sistema IP/REV.

El modelo actual de interoperabilidad tiene contemplado la existencia de contratos prepago entre los usuarios y los INT-IP/REV.

El modelo planteado en la actualidad, no exige a los usuarios que adopten el modelo prepago, contar con un mecanismo de respaldo en caso de sobregiros, pero tampoco asigna la responsabilidad de asumir este riesgo al INT-IP/REV.

En la práctica, incluso en una situación de perfecto funcionamiento del sistema IP/ REV, se pueden presentar problemas de sobregiro en las cuentas de prepago, derivadas de la asincronía natural del sistema o de las comunicaciones.

Esta situación se considera de alto riesgo ya que puede ir en detrimento de los actores y de la credibilidad del sistema.

Por otro lado, se ha considerado que no ofrecer un modelo de prepago puro, puede impactar la capacidad de masificación del sistema, con lo cual hay una intención de minimizar técnicamente la ocurrencia de estos casos, y tener establecidos mecanismos de resolución de disputas entre los INT IP/REV y los OP IP/REV cuando se presenten estos casos.

Es claro también para soportar la pretensión de habilitar peajes tipo Free-Flow en zonas urbanas, este modelo prepago puro no sería posible, por lo cual se prevé que a futuro sería necesaria una transición del modelo de relación usuario-intermediador y la entrada de reglamentación coercitiva para el cobro de la evasión de peaje.

Como fue descrito anteriormente, la naturaleza asíncrona y distribuida del sistema de peaje electrónico, es susceptible de generar situaciones de inconsistencia en la información de usuarios entre diferentes nodos. Las siguientes situaciones están identificadas como inductores de inconsistencias:

Desfase en la habilitación de usuario: Una recarga o activación que se hace en el INT-IP/REV tiene un tiempo de propagación hasta los carriles del OP-IP/REV. Durante este periodo de propagación, se puede producir que un usuario se vea bloqueado al intentar circular por un peaje del OP-IP/REV, generando una situación de interrupción de servicio.

Desfase en actualización de saldo insuficiente: Una pasada de un usuario causante de que su saldo vaya a un saldo insuficiente, tiene un tiempo de propagación alrededor de todos los sistemas. Durante este periodo de propagación, el usuario podría pasar por más de un peaje aun cuando su saldo real no lo permita. En este caso cuando se liquiden el total de las pasadas, su saldo en cuenta será negativo.

Desfase en la inhabilitación de un usuario: La inhabilitación de un usuario por parte de un INT IP/REV tiene un tiempo de propagación alrededor de todos los sistemas. Durante este periodo de propagación, el usuario podría pasar por más de un peaje aun cuando esta situación sea indeseada. En este caso cuando se liquiden las transacciones se tiene el riesgo de tener un usuario inactivo en el sistema.

Desfase en la recepción de transacciones por parte del INT IP/REV: Este desfase se puede causar por la interrupción de las comunicaciones o daño de los equipos en el momento del paso del vehículo por una estación de peaje, ocasionando que el saldo o estado no sea actualizado en el INT IPREV y este cambio no se propague a nivel nacional.

Dadas las implicaciones del modelo prepago puro en interoperabilidad, es recomendable que se establezcan políticas en la relación INT IP/REV y usuario, de forma que el usuario pueda garantizar los pagos de los peajes así sean estos liquidados con un retraso.

Es importante definir un marco conceptual para asignar responsabilidades entre los INT IP/REV y los OP IP/REV para el caso de transacciones que por demoras en su notificación y procesamiento, queden sin cobertura por parte de los medios de pago disponibles para ese usuario.

Así mismo es deseable establecer expectativas adecuadas de niveles de servicio hacia los usuarios en cuanto a los tiempos de propagación en los sistemas de habilitaciones e inhabilitaciones, que sean realistas y consistentes entre los actores.

2.4. Gestión local del saldo.

Dada la naturaleza distribuida de la integración entre sistemas, se pueden presentar casos de intermitencia en la comunicación. La latencia en la comunicación causará que existan inconsistencias entre el saldo de un usuario en el INT IP/REV y el saldo del mismo usuario en el OP-IP/REV. De esta manera, si el OP-IP/REV espera siempre un mensaje del INT IP/REV para actualizar su saldo entonces puede ocurrir que un vehículo con poco saldo pase muchas veces por los peajes del OP IP/REV antes de detectar que su saldo se ha agotado.

Para mitigar el caso anteriormente descrito, cada OP IP/REV puede opcionalmente implementar en su sistema un manejo local del saldo por cada usuario del que irá descontando las pasadas realizadas.

A pesar de que está técnica disminuye el impacto de la problemática, no la desaparece puesto que este saldo local también es inconsistente.

Dado que la fuente autoritativa de los saldos es el INT-IP/REV, los saldos locales serán reemplazados cada vez que se el INT IP/REV notifique actualizaciones sobre un usuario.

En caso de querer el OP IP/REV aplicar este mecanismo, deberá poner en sobre aviso a los INT IP/REV para su conocimiento.

2.5. Consideraciones sobre disputas y ajustes extemporáneos.

El pago electrónico está sujeto a reclamaciones por parte de los usuarios acerca de los cobros y ajustes realizados en su cuenta, que pueden darse en el tiempo, con posterioridad al paso por el peaje y al cierre de los informes de recaudo de los operadores.

Se deben establecer una serie de lineamientos para garantizar un manejo adecuado frente a estas disputas que preserve los derechos de reclamación de los usuarios. En general están identificadas:

— La retención de datos por parte de los INT IP/REV y OP IP/REV

— Los ANS en tiempos de respuesta alrededor de una disputa.

— La capacidad de los OP IP/REV de hacer ajustes a los ingresos reportados con anterioridad, mediante la inclusión en sus informes de recaudo de secciones especiales que reporten ajustes de mayor o menor ingreso debido a reclamaciones extemporáneas. Este último punto debe ser especificado y concertado con los entes reguladores, interventorías y concesionarios.

3. Aspectos técnicos y de seguridad.

3.1. Encriptación de la información.

En los procesos de comunicación entre los actores la información se encriptará conforme al protocolo HTTPS (HTTP + TLS v1.2) con las siguientes características.

• Suites de cifrado: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256- SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128- SHA256:ECDHE-RSA-AES128-SHA256.

• Tipo de certificado: ECDSA.

• Tamaño mínimo de la llave del certificado de comunicación segura: 2048.

• Algoritmo de firma del certificado de comunicación: sha256WithRSAEncryption, ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512.

En el almacenamiento se debe encriptar toda la información usando alguno de los siguientes esquemas:

• Encriptación por aplicación

• Encriptación de disco y/o archivos

• Encriptación por base de datos

3.2. Interacción segura.

El proceso de habilitación de los intermediadores y operadores les genera una entrada en la plataforma de SIGT, con su correspondiente usuario para consumo de los servicios expuestos por la misma. Este modelo permitirá que los actores puedan:

• Utilizar el esquema de seguridad para la autenticación y verificación mediante un Token Endpoint definido por el SIGT, utilizando el protocolo OpenID Connect.

• Uso de Tokens basados en el estándar JWT (JSON Web Token) que brindará información sobre fechas de creación, uso y vencimiento del mismo, entre otros.

• La verificación de los Tokens deberá realizarse contra el Token Endpoint.

• El siguiente es un diagrama general de interacción:

ccccccc10
 

• Se limitarán las comunicaciones entrantes mediante el registro de las direcciones IP origen, autorizadas utilizando el Firewall disponible.

Los servicios expuestos por el SIGT están sobre plataformas que cumplen con los siguientes estándares de seguridad:

• PCI DCS 3.2

• ISO/IEC 27001 e ISO/IEC 27018.

Garantizando la confiabilidad del modelo de seguridad ofrecido sobre estándares de mercado maduros y usados ampliamente a nivel global.

El modelo se actualiza constantemente según los reportes de vulnerabilidades hechos por entes internacionales como mitre.org, Microsoft, Oracle, Google, Red Hat, Apache Software Foundation y demás integrantes de la iniciativa CVE® para que sean subsanadas y se mantengan vigentes según las mejores prácticas del mercado.

3.3. Formato de comunicación.

• Protocolo de aplicación: REST-Based Web Service (API Web).

• Formato de intercambio de datos en el contenido del mensaje: JSON.

• Formato de codificación en el contenido del mensaje: UTF-8.

• Formato de datos de tipo Datetime: Los datos de tipo datetime (fecha y hora) se deben enviar usando el estándar ISO 8601, en formato YYYY-MM-DDThh:mm:ss. sss (con precisión hasta milésimas de segundos), usando la hora local colombiana (para facilitar los procesos de comparación de fechas). Ejemplo, 2017-07- 16T19:20:30.984.

3.4. Confiabilidad en la entrega de los mensajes.

Para garantizar confiabilidad en el intercambio de datos. Se usará una estrategia en dos pasos:

1. Confirmación de la recepción: Un sistema envía una petición. El receptor debe confirmar inmediatamente la recepción de la petición. Al confirmar la recepción, se da por hecho que el mensaje ha sido persistido en el receptor.

2. Confirmación del procesamiento: Para algunas peticiones y según se especifique, una vez la petición ha sido procesada en el receptor, el receptor debe enviar un mensaje de confirmación de procesamiento a quien envió la petición mediante otra interfaz en sentido inverso.

Para llevar a cabo de manera exitosa este proceso, todas las peticiones HTTP deben incluir los siguientes encabezados:

• Solicitante: Código del operador/intermediador del generador de la petición (entregado por el Ministerio de Transporte en la habilitación).

• CodigoCorrelación: Identificador único de la petición. Este código deberá ser único e irrepetible en todo momento para el actor que inicia la petición. Su estructura es: CODACTOR_CODIGOUNICO, donde CODACTOR corresponde al código del operador o intermediador solicitante según sea el caso.

• FechaHoraServidor: fecha y hora que reporta el servidor al que se realiza el request en formato ISO 8601, por ejemplo YYYY-MM-DDThh:mm:ss 2017-07- 16T19:20:30

Las respuestas de confirmación a las peticiones deben incluir los siguientes encabezados HTTP:

• Solicitante: Código del operador/intermediador del generador de la petición (entregado por el Ministerio de Transporte en la habilitación). Debe ser el mismo código especificado en la petición.

• Respondedor: Código del operador/intermediador que responde la petición (entregado por el Ministerio de Transporte en la habilitación).

• CodigoCorrelacion: Identificador único que identifica mensajes relacionados. Debe ser el mismo código especificado en la petición.

• FechaHoraServidor: Fecha y hora que reporta el servidor al que se realiza el request en formato ISO 8601, por ejemplo YYYY-MM-DDThh:mm:ss 2015- 07-16T19:20:30.

Se rechazará automáticamente los mensajes con código 400 (petición inválida) si:

• Los requerimientos de HEADER no se cumplen

• El valor enviado en el HEADER FechaHoraServidor se evalúa en el servidor receptor garantizando que no tenga un desfase de 10 minutos (adelante o atrás).

• Las respuestas o mensajes de confirmación que no tienen correspondencia exacta en: Cantidad de registros de la lista = Cantidad de registros aceptados + Cantidad de registros rechazados

3.5. Confirmación de la recepción.

El servicio que recibe la petición envía una respuesta HTTP al cliente. Los posibles códigos de respuesta HTTP son:

• 200 - Petición recibida exitosamente. Pendiente de procesamiento.

• 204 - Para cuando no hay contenido (específicamente para peticiones tipo GET)

• 400 - Petición invalida (ErrorResponse - especificación técnica Swagger - es el objeto estándar para especificar la causa del rechazo y deberá ser entregada en el cuerpo de la respuesta).

• 401 - No se puede autenticar la petición.

• 429 - Demasiadas peticiones. Por favor reintente más tarde.

• 500 - Error interno de servidor.

• 503 - Servicio no disponible. Reintente tarde.

• 504 - La solicitud del servicio tiene un desfase mayor o menor a 10 minutos.

La confirmación de la recepción NO implica que la petición ha sido procesada.

3.6. Excepciones no controladas.

Aquellos errores que no puedan ser gestionados por el código, serán reportados como excepciones no controladas. El modelo propuesto es retornar un error 500 usando el objeto ErrorResponse —especificación técnica Swagger— en el cuerpo para especificar la causa del error.

3.7. Pre-procesamiento y validación de paquetes de información.

Las transacciones o paquetes de pasadas, ajustes y sus correspondientes respuestas se rechazan completos cuando no cumple la “forma” especificada, es decir, si algún elemento del paquete viene con datos inválidos en longitud, tipo de dato y dominio.

3.8. Confirmación del procesamiento.

Tal como se describe anteriormente, para ciertas integraciones según se defina en el documento, una vez un mensaje ha sido procesado en el sistema receptor, se debe enviar una confirmación. La confirmación implica que el mensaje ha sido procesado en el COP IP/REV del sistema destino. La confirmación de procesamiento del mensaje se envía a una URL predefinida. Cada tipo de mensaje tiene un tipo de respuesta diferente que será especificada en la descripción de los servicios.

3.9. Trazabilidad.

Para los procesos de auditoría, cada sistema debe almacenar como mínimo 92 días los eventos que especifica el sistema. Esto incluye todos los datos de los usuarios, las pasadas y/o ajustes. Esto también incluye los tiempos de recepción y confirmación de los datos.

Se recomienda además almacenar los mensajes originales. También, se sugiere que los sistemas manejen indicadores para saber el tiempo medio de aplicación de procesamiento de los mensajes.

3.10. Otras notas de seguridad.

El cliente debe estar sincronizado con el servicio. Cualquier petición cuya fecha esté desfasada en más de 10 minutos con la fecha del servidor será rechazada.

4. Procesos de intercambio de información de usuarios.

4.1. Antecedentes.

En el modelo de interoperabilidad, el INT IP/REV cumple el rol de gestionar una base de datos de usuarios adscritos al servicio de pago electrónico ofrecido por este INT IP/ REV.

Los usuarios inscritos en el INT IP/REV y las novedades relacionadas con estos deben ser oportunamente comunicados a los actores OP IP/REV y procesados por estos para permitir un buen funcionamiento del sistema IP/REV.

El esquema de comunicación de usuarios entre INT IP/REV y OP IP/REV estará compuesto por una serie de servicios y mecanismos de intercambio de información que permitirán abordar los escenarios de funcionamiento normal, así como los escenarios de fallas y situaciones de excepción de una forma sistematizada y organizada.

Para la definición de los procesos de intercambio de información se especifican en este documento:

— Los servicios que deben ser expuestos y consumidos por cada actor.

— Los requerimientos de generación, consumo y procesamiento de la información.

— Los diferentes objetos de información que se deben intercambiar según el servicio.

— Los procesos normales y los procesos de restauración de saldos desde una lista total de usuarios.

4.2. Escenarios contemplados.

Los siguientes escenarios de uso están contemplados en la presente especificación:

— Uso normal del sistema

— Pérdidas de enlace y recuperación de información desfasada

— Restauración completa de la información por falla en el operador o el intermediador del IP/REV.

— Notificación de errores.

4.3. Resumen de servicios web asociados a usuarios.

4.3.1. Servicios expuestos por el INT IP/REV.

CódigoNombre del ServicioURLDescripción
UI1Consulta de listas Método GET
https://URL-Intermediador/ v1/listasUsuarios/{codigoListaUsuario}
Permite al OP IP/REV obtener la lista correspondiente al códigoListaUsuario, ya sea una lista total, parcial, negra o de saldo.
UI2Consulta de Resumen de Listas Generadas Método GET
https://URL-Intermediador/ v1/listasUsuarios/{codigoListaUsuario}/listasPosteriores
Permite al OP IP/REV obtener el resumen de las listas generadas de forma posterior al codigoListaUsuario, es decir, una relación de códigos de listas disponibles.
UI3Notificar errores de procesamiento de una lista. Método PUT
https://URL-Intermediador/ v1/listasUsuarios/{codigoListaUsuario}/notificarErroresProcesamiento
Permite al OP IP/REV notificar los errores de procesamiento de una lista obtenida del INT IP/REV.
UI4Recibo de pruebas de transacción Método PUT
https://URL-Intermediador/ v1/pasos/{codigoPaso}/ pruebas
Permite al OP IP/REV entregar registro fotográfico de una transacción de peaje especificada en la solicitud para un código de Paso.
UI5Consulta de Listas para un día. Método GET
https://URL-Intermediador/ v1/listasUsuarios
Permite al OP IP/REV obtener las listas correspondientes a un día, ya sea una lista parcial o total.

4.3.2. Servicios expuestos por el OP.

CódigoNombre del ServicioURLDescripción
UO1Notificación de nueva lista disponible Método PUT
https://URL-Operador/v1/ listasUsuarios
Permite al INT IP/REV notificar la existencia de una nueva lista disponible.
UO2Solicitud de prueba de transacción Método PUT
https://URL-Operador/v1/ pasos/{codigoPaso}/solicitarPruebas
Solicita al OP IP/REV información general del tránsito + las pruebas fotográficas sobre una transacción específica de paso.
UO3Consulta de una prueba de paso Método GET
https://URL-Operador/ /v1/ pasos/{codigoPaso}/pruebas/{codigoPrueba}
Descargar una prueba específica (fotografía) de las disponibles para un paso.

4.3.3. Servicios expuestos por el SIGT.

CódigoNombre del ServicioURLDescripción
US1 Consulta estado de asignación placa a un TAG vigente. Método GET
https://URL-SIGT/ /v1/placas/{placa}/asignada
Permite al INT IP/REV consultar si una placa se encuentra asignada a un TAG vigente.

4.4. Descripción del proceso “Normal” de intercambio de información.

En el escenario normal de funcionamiento, INT IP/REV y OP IP/REV intercambiarán información de acuerdo al siguiente flujo de procesos

ccccccc11
 

ccccccc12
 

4.4.1. Generación de listas de información por parte del INT (paso 1).

El INT IP/REV deberá generar listas de información de sus usuarios a partir de las actualizaciones que se produzcan sobre los mismos y que generen la necesidad de notificación hacia los OP IP/REV.

Periodicidad: 2-5 minutos

Cada 2 minutos como mínimo y cada 5 minutos como máximo

ccccccc13
 

4.4.1.1. Tipos de listas.

Existen tres tipos de listas que serán generadas

Listas totales (blancas): Las listas totales incluirán todos los usuarios del INT IP/ REV matriculados de acuerdo al formato de mensaje de usuario que se especifica en este documento.

Listas negras: Las listas negras incluirán todos los usuarios que han sido des-matriculados de un INT IP/REV en los últimos 30 días y no han vuelto a ser matriculados en ese INT IP/REV. Estas listas son soporte del proceso de migración de usuarios entre Intermediadores.

Listas parciales: Las listas parciales incluirán todos los usuarios modificados desde la última lista parcial o total de acuerdo al formato de mensaje de usuario que se especifica en este documento.

4.4.1.2. Nomenclatura de listas.

La nomenclatura de las listas corresponderá al esquema.

CODIGOINTERMEDIADOR_YYYYMMDD_NNNNN[X]

En donde

CODIGOINTERMEDIADOR: Corresponde al código asignado por el Ministerio de Transporte.

YYYYMMDD: Corresponde al día de acuerdo al horario GMT-5 en los servidores del intermediador NNNNN: corresponde al número de la lista. Las listas se nombrarán 00001, 00002, 00003 y así sucesivamente, hasta el cambio de día

[X] corresponde al carácter “T” para las listas totales, “N” para las listas negras, “P” para las listas parciales

De este modo, tomando como ejemplo 2 días consecutivos el INT IP/REV generará listas de la siguiente forma:

10012_20170801_00001P

10012_20170801_00002P

10012_20170801_00003P

10012_20170801_00004T

10012_20170801_00005N

10012_20170801_00006P

..

..

..

10012_20170801_00288P

10012_20170802_00001P

10012_20170802_00002P

10012_20170802_00003P

10012_20170802_00004T

10012_20170801_00005N

10012_20170801_00006P

..

4.4.1.3. Proceso de generación de listas.

El proceso de generación de listas transcurrirá de la siguiente forma:

• El INT IP/REV evaluará cada N minutos (según periodicidad) si su base de datos contiene modificaciones a usuarios desde la última lista generada, para generar una nueva lista parcial de modificaciones.

• Si existen modificaciones, el INT IP/REV generará una o varias listas para registrar en ellas las novedades encontradas.

• El máximo número de registros por lista parcial podrá ser de 1.000 registros y el mínimo 1.

• En caso de tener el INT IP/REV más de 1000 novedades, deberá generar tantas listas como sea necesario.

• Las listas serán numeradas en orden consecutivo de acuerdo a la lista anterior y al día

• El identificador de lista será siempre secuencial y creciente.

• No está permitido para el INT IP/REV generar listas no secuenciales en su sistema

Adicional a este proceso:

• Todos los días, a una hora definida (ejemplo 1AM), el INT IP/REV generará una lista de todos los usuarios, que tendrá un código que continúe la secuencia y el carácter “T” al final del código.

• La lista “TOTAL” no tendrá restricción de tamaño.

• Posteriores actualizaciones serán consignadas en las subsiguientes listas parciales.

• Un OP IP/REV que haya procesado todas las listas parciales, podrá ignorar la lista total, y no tendrá necesidad de solicitarla ni procesarla.

• La lista total podrá ser utilizada como punto cercano de restauración de saldos para un OP IP/REV que tenga esta necesidad.

• No se espera que la lista total sea utilizada por los OP IP/REV en el funcionamiento normal del sistema, debido al posible tamaño que esta tendrá en el tiempo en la medida que los INT IP/REV acumulen un volumen importante de usuarios.

• Adicionalmente, el INT IP/REV generará una lista negra diaria, preferiblemente a continuación de la lista total, que incluirá los usuarios des-matriculados de su sistema en los últimos 30 días.

4.4.2. Notificación de nueva lista al OP (paso 2).

En la medida que el INT IP/REV genere nuevas listas de usuarios totales o parciales, deberá notificar al OP IP/REV de la existencia de las mismas.

Para esto, comunicará al OP IP/REV mediante el consumo de un servicio del nuevo código de lista.

Periodicidad: Inmediatamente finaliza el proceso de creación de listas

ccccccc14
 

Esta notificación no contiene la lista, únicamente el nombre de la misma

El mensaje será de la siguiente forma:

4.4.2.1. Petición.

Comando HTTP: PUT /v1/listasUsuarios
Contenido: ListaUsuario
Emite: INT-IP/REV
Recibe: OP-IP/REV
Objetos: ListaUsuario

Nota: La definición de los objetos se encuentra en el anexo técnico del swagger del servicio.

4.4.2.2. Consideraciones.

• El OP IP/REV deberá confirmar la petición de forma sincrónica mediante una respuesta HTTP 200.

• El OP IP/REV deberá almacenar este código de lista (ya que posteriormente deberá consumir el servicio expuesto por el intermediador “Consulta de listas” para obtener esta lista y procesarla en su COP).

• El INT IP/REV deberá reintentar el despacho del mensaje en caso de no recibir respuesta o recibir respuesta errada por parte del OP IP/REV.

• Si el OP IP/REV determina que requiere listas anteriores a la recién notificada, podrá solicitar estas listas al intermediador consumiendo el servicio de “Consulta de listas” con los códigos de lista que requiera.

• Será responsabilidad del OP IP/REV llevar un registro de las listas parciales obtenidas y procesadas de acuerdo a la nomenclatura y secuencialidad de las mismas.

• Será responsabilidad del OP IP/REV procesar las listas respetando la secuencialidad definida, para evitar problemas de información.

• El OP IP/REV no requiere solicitar ni procesar las listas totales si ha procesado correctamente todas las listas parciales. Las listas totales se usarán en caso de ser necesaria una restauración de la información en el OP IP/REV.

• El registro de cada usuario contiene un campo de versión que es único e incremental en cada modificación que se produzca por parte del INT IP/REV (ver especificación del mensaje de usuario).

• Será responsabilidad del OP IP/REV no actualizar un registro de usuario en su base de datos en el caso de que el código de versión de ese registro sea inferior al código que ya tenga almacenado en su base de datos.

• Posteriormente, al reportar las transacciones al INT IP/REV, el OP IP/REV deberá incluir este código de versión en el registro de la transacción para permitir la auditoría en casos de disputa. (Ver proceso de intercambio de transacciones).

4.4.3. Solicitud de listas por parte del OP-IP/REV (paso 3).

ccccccc15
 

Una vez el OP IP/REV ha sido notificado de la existencia de nuevas listas, debe revisar su registro de listas y determinar qué listas necesita solicitar y procesar en su sistema.

Para solicitar las listas, deberá consumir el servicio expuesto por el INT IP/REV

4.4.3.1. Petición.

Comando HTTP: GET /v1/listasUsuarios/{codigoListaUsuario}/detalles
Respuesta: Lista<Usuario>
Solicita: OP-IP/REV
Emite: INT-IP/REV
Objetos: Usuario

Identificación del recurso (ejemplo)
Recurso solicitadoURL del recurso
Lista 10014_20170411_0003/v1/listasUsuarios/10014_20170411_0003/detalles

El consumo de este servicio retorna una lista de objetos de tipo usuario.

Nota: La definición de los objetos se encuentra en el anexo técnico del swagger del servicio.

4.4.3.2. Procesamiento.

Una vez el OP IP/REV ha obtenido la lista debe proceder a:

— Marcar la lista como recibida en su control de listas

— Procesar los registros en el COP

— Distribuir las actualizaciones de usuarios hacia estaciones y carriles

El OP IP/REV deberá observar los siguientes lineamientos:

— Debe procesar las listas de forma secuencial, de la misma forma que son generadas por el INT IP/REV.

— Antes de actualizar el registro de un usuario deberá observar que el campo “versión” del registro del usuario actualizado, no es inferior al valor del campo “versión” que tiene almacenado. En este caso de no ser así, ignorará el registro.

— Registrar la fecha y hora de actualización de cada registro en el OP IP/REV.

— El operador tendrá máximo una hora para reportar el procesamiento de una lista.

4.5. Solicitud de prueba de transacción.

Un INT IP/REV podrá realizar una solicitud de prueba de transacción a un OP IP/REV en el evento que requiera obtener el registro fotográfico de un tránsito para la resolución de una disputa o reclamación de usuario.

Método: https://URL-Operador/v1/pasos/{codigoPaso}/solicitarPruebas

Comando HTTP: PUT /v1/pasos/{codigoPaso}/solicitarPruebas
Contenido: codigoPaso
Resultado: Ticket
Emite: INT-IP/REV
Recibe: OP-IP/REV
Objetos: Ticket

codigoPaso (Parámetro Path).
NombreTipo DatoTamañoObligatorioDescripción
codigoPasostring38SCódigo único de la transacción

Nota: La definición de los objetos se encuentra en el anexo técnico del swagger del servicio.

4.6. Descargue de prueba de transacción.

Un INT IP/REV podrá realizar el descargue de prueba de transacción a un OP IP/REV. Esta prueba corresponde a una sola fotografía y el codigoPrueba referencia uno de los códigos de prueba entregados por el operador cuando confirma la disponibilidad de las pruebas de un paso.

Método: https://URL-Operador/v1/pasos/{codigoPaso}/pruebas/{codigoPrueba}

Comando HTTP: GET v1/pasos/{codigoPaso}/pruebas/{codigoPrueba}
Contenido: codigoPaso, codigoPrueba
Resultado: String
Emite: INT-IP/REV
Recibe: OP-IP/REV
Objetos: String

codigoPaso (Parámetro Path).
NombreTipo DatoTamañoObligatorioDescripción
codigoPasostring38SCódigo único de la transacción
codigoPruebastring SID único de la prueba. Debe estar conformado por OPERADOR_IDPRUEBA donde OPERADOR representa el código del operador asignado por el Ministerio de Transporte y el IDPRUEBA es el identificador único generado por el operador para la prueba.

Nota: La definición de los objetos se encuentra en el anexo técnico del swagger del servicio.

4.7. Recibo de prueba de transacción.

Los operadores que previamente recibieron una solicitud de prueba de transacción, deberán obtener las fotografías correspondientes al tránsito solicitado y las deberán reportar al INT IP/REV utilizando el método dispuesto para esta operación. Este método entrega las listas de pruebas usando el objeto PruebasPaso pero no el contenido de las mismas.

Método: https://URL-Intermediador/v1/pasos/{codigoPaso}/pruebas

Comando HTTP: PUT /v1/pasos/{codigoPaso}/pruebas
Contenido: PruebasPaso
Emite: OP-IP/REV
Recibe: INT-IP/REV
Objetos: PruebasPaso, Ticket

Nota: La definición de los objetos se encuentra en el anexo técnico swagger del servicio

codigoPaso (Parámetro Path).
NombreTipo DatoTamañoObligatorioDescripción
codigoPasostring38SCódigo único de la transacción

4.7.1. Comportamiento esperado en el OP IP/REV según los valores de estados.

El siguiente es el comportamiento esperado frente a la habilitación del paso en el OP IP/REV según las características del mensaje de usuario enviado por el INT IP/REVç

estadoestadoSaldocomportamiento esperado en el OP IP/REV
Cancelado (Inactivo) cualquier estado no debe pasar bajo ningún concepto
SEÑALES:
semáforos: “rojo”
display: “Inactivo”
suspendido cualquier estado no debe pasar bajo ningún concepto
(* Excepto usuarios con convenio de exención, siendo este, diferente al definido por la L. 787)
SEÑALES:
semáforos: “rojo”
display: “no hábil”
activo “con saldo” deja pasar siempre al vehículo
nunca muestra el saldo en el display
evalúo el atributo de saldo bajo
ilumina el semáforo amarillo o no, dependiendo del atributo
SEÑALES:
semáforos: “verde” o “amarillo”
display: “buen viaje, saldo bajo, etc..”
activo “sin saldo” si tarifa peaje > 0, no lo deja pasar
• nunca muestra el saldo en el display
• ignora el atributo de saldo bajo
SEÑALES:
semáforos: “rojo”
display: “sin saldo”
si tarifa peaje = 0, lo deja pasar
• ignoro el atributo de saldo
• nunca muestra el saldo en el display
• ignora el atributo de saldo bajo
• no enciende el semáforo amarillo
SEÑALES:
semáforos: “verde”
display: “buen viaje”
activo “use saldo” si tarifa peaje > saldo, no lo deja pasar
• compara el saldo para tomar la decisión
• NO muestra el saldo en el display
• no enciende el semáforo amarillo
SEÑALES:
semáforos: “rojo”
display: “sin saldo”
si tarifa peaje <= saldo, lo deja pasar
• compara el saldo para tomar la decisión
• NO muestra el saldo en el display
• evalúa el atributo de saldo escaso
• enciende el semáforo amarillo si aplica (saldoBajo = true)
SEÑALES:
semáforos: “verde o verde-amarillo”
display: “buen viaje”

4.7.2. Tabla de conversión de señalización en vía al usuario.

ccccccc16
 

4.7.3. Consideraciones a la generación de actualizaciones y manejo del saldo y saldo bajo.

Con el objetivo de racionalizar la cantidad de actualizaciones generadas en el sistema y evitar el crecimiento excesivo de la comunicación entre INT IP/REV y OP IP/REV, se recomienda seguir los siguientes lineamientos para usuarios con tipo de contrato prepago que no posean la funcionalidad de recarga automática (usuarios de prepago puro)

○ Cuando un usuario tiene un saldo suficientemente alto (es decir, superior al del valor máximo de un peaje de su categoría, se recomienda al INT IP/REV utilizar el estado “CON SALDO” y no enviar el saldo al OP IP/REV.

○ En la medida en que el usuario consuma peajes y su saldo disminuya, el INT IP/REV no deberá actualizar el mensaje del usuario a los OP IP/REV hasta que llegue al umbral definido por cada INT IP/REV que determina que el saldo es bajo.

○ Cuando el saldo del usuario llegue al umbral en el que es igual o menor al valor más alto de un peaje de su categoría, el INT IP/REV puede cambiar el estado a 3 “USE SALDO”, y notificar el valor del saldo en el mensaje.

○ Mientras el usuario se mantenga en valores iguales o inferiores al valor más caro de un peaje de su categoría, el INT IP/REV deberá actualizar el saldo y notificar a los OP IP/REV de forma constante cada cambio de saldo que ocurra.

○ Cuando el OP IP/REV detecte que el dispositivo se encuentra en saldo bajo, deberá validar el saldo registrado en la base de datos, para determinar si se permite el paso del vehículo de acuerdo a la tarifa del peaje.

De esta manera se pretende disminuir la cantidad de notificaciones para usuarios prepago que se pueden generar. El siguiente diagrama ilustra la situación mediante un ejemplo:

ccccccc17
 

4.8. Servicio para reportar errores de usuarios.

Cuando un OP, al procesar una lista de usuarios encuentre un error en un registro, deberá seguir procesando el resto de los registros sin importar el error.

Posteriormente, deberá reportar el error al intermediador a través del consumo del servicio expuesto para tal fin.

ccccccc18
 

4.8.1. Petición.

Comando HTTP: PUT /v1/listasUsuarios/{codigoListaUsuario}/notificarErroresProcesamiento
Contenido: NotificacionErrorProcesamientoListas
Emite: OP-IP/REV
Recibe: INT-IP/REV
Objetos: NotificacionErrorProcesamientoListas, ErroresProcesamientoLista, ErrorUsuario

Nota: La definición de los objetos se encuentra en el anexo técnico del swagger del servicio.

El error 1003 corresponde al caso en el que el OP IP-REV ya tiene registrado el tag o la placa en estado activo y asociado a un Intermediador diferente. En este caso, la descripción del error debe informar el código de intermediador que tiene asociado el vehículo en la base de datos del OP IP/REV.

Un OP IP/REV no puede tener la misma placa o el mismo tag asociado a dos INT IP/ REV diferentes, activos en su sistema el mismo tiempo.

Un OP IP/REV no puede tener en su sistema dos registros de tags diferentes pero con la misma placa activos en su sistema al mismo tiempo.

4.9. Resumen de listas generadas.

A través de este servicio, el OP IP/REV podrá consultar con el INT IP/REV los secuenciales de listas generadas para un día determinado.

El propósito de este servicio es dar al OP IP/REV una herramienta adicional de consulta para verificación de la concordancia de su control de listas

4.9.1. Petición.

Comando HTTP: GET /v1/listasUsuarios
Respuesta: Lista<ListaUsuario>
Parámetros: DIA en formato YYYYMMDD
Solicita: OP-IP/REV
Emite: INT-IP/REV
Objetos: ListaUsuario

Nota: La definición de los objetos se encuentra en el anexo técnico del swagger del servicio.

Ejemplo de uso

Petición:

(GET) …/v1/listasUsuarios?dia=20170417

Respuesta (detalle):

ccccccc19
 

4.10. Consulta estado asignación placa a TAG.

Los intermediadores requieren verificar para la asignación de un TAG, que la placa correspondiente no tenga ningún TAG vigente. Este método permite consultar si la placa se encuentra asignada a un TAG activo. Este método solo podrá ser consumido por intermediadores.

Método: https://URL-SIGT/v1/placas/{placa}/asignada

Comando HTTP: GET /v1/placas/{placa}/asignada
Contenido: EstadoAsignacionPlaca
Emite: SIGT
Recibe: INT-IP/REV
Objetos: EstadoAsignacionPlaca

Nota: La definición de los objetos se encuentra en el anexo técnico del Swagger del servicio API SIGT.

placa (Parámetro Path).
NombreTipo DatoTamañoObligatorioDescripción
PlacaString6-10SPlaca del vehículo a consultar.

4.11. Consideraciones sobre retención de información.

El INT IP/REV deberá permitir las consultas en línea de las listas de usuarios por parte del OP IP/REV por un periodo de 10 días como mínimo.

Posterior a esto, el INT IP/REV podrá eliminar los recursos expuestos hacia el OP IP/ REV de forma que la consulta de una lista con más de 10 días de antigüedad podrá retornar un mensaje HTTP 204 (No hay contenido). Se aclara que esta retención de información se refiere a la disponibilidad local de la misma.

Esto no elimina la obligación del INT IP/REV de almacenar la información de listas en sus bases de datos.

5. Procesos de intercambio de información de transacciones.

5.1. Antecedentes.

En el modelo de interoperabilidad, los pasos de usuario del sistema por los peajes producen transacciones de paso por el sistema.

La posterior revisión de algunas transacciones puede generar ajustes al cobro realizado en primera instancia.

El esquema de comunicación de usuarios entre INT IP/REV y OP IP/REV estará compuesto por una serie de servicios y mecanismos de intercambio de información que permitirán abordar los escenarios de funcionamiento normal, así como los escenarios de fallas y situaciones de excepción de una forma sistematizada y organizada.

Para la definición de los procesos de intercambio de información se especifican en este documento:

— Los servicios que deben ser expuestos y consumidos por cada actor.

— Los requerimientos de generación, consumo y procesamiento de la información.

— Los diferentes objetos de información que se deben intercambiar según el servicio.

— Los procesos normales de intercambio de información.

5.2. Escenarios contemplados.

Los siguientes escenarios de uso están contemplados en la presente especificación:

— Uso normal del sistema.

— Notificación de errores.

— Pérdidas de enlace y recuperación de información desfasada.

— Envío de transacciones acumuladas en el OP IP/REV por pérdidas de enlace u otros.

5.3. Comunicación de transacciones y ajustes.

La notificación temprana de transacciones entre OP IP/REV e INT IP/REV es fundamental para minimizar los problemas derivados de la naturaleza distribuida y asíncrona del sistema IP/REV.

De este modo los actores deben seguir los siguientes lineamientos:

— La notificación de transacciones hacia el INT IP/REV debe ser la más inmediata posible, estando permitido notificar listas de 1 o varios registros.

— Los ANS de tiempos mínimos y máximos deben ser definidos en este documento. Se espera un comportamiento con promedios inferiores a los 30 segundos desde el paso de un usuario por un carril hasta su notificación al INT IP/REV.

— El OP IP/REV deben reportar las transacciones aun cuando estas presenten discrepancias. Si la revisión posterior arroja ajustes al cobro, estos serán notificados a través de la interfaz de ajustes.

— El INT IP/REV debe reportar las confirmaciones de aceptación o rechazo de pasos y ajustes de forma temprana, para permitir a los operadores conciliar su recaudo dentro de los tiempos de operación normales. El tiempo promedio de confirmación o rechazo de paso no debe ser superior a 30 minutos.

5.4. Resumen de servicios Web que hacen parte de los procesos de transacciones y ajustes.

5.4.1. Servicios expuestos por el INT.

CódigoNombre del ServicioURLDescripción
TI-1Registro de transacciones de paso Método POST
https://URL-Intermediador/ v1/pasos
Permite al OP IP/REV registrar en el INT IP/REV las transacciones de paso de peaje
TI-2Registro de transacciones de Ajuste Método POST
https://URL-Intermediador/ v1/ajustes
Permite al OP IP/REV registrar en el INT IP/REV las transacciones de ajuste a cobros
TI-3Notificación de intento de paso fallido Método POST
https://URL-Intermediador/ v1/negacionesPasos
Permite al OP IP/REV notificar la no autorización de paso de un usuario de un INT IP/ REV

5.4.2. Servicios expuestos por el OP

CódigoNombre del ServicioURLDescripción
TO-1Confirmación de transacciones de paso Método PUT
https://URL-Operador/v1/ pasos/{codigoPaso}/confirmarProcesamiento
Permite al INT IP/REV confirmar al OP IP/REV la aceptación y procesamiento de las transacciones de paso.
TO-2Confirmación de transacciones de ajuste Método PUT
https://URL-Operador /v1/ confirmacionesAjustes
https://URL-Operador/v1/ ajustes/{CodigoAjuste}/confirmarProcesamiento
Permite al INT IP/REV confirmar al OP IP/REV la aceptación y procesamiento de una transacción de ajuste

5.5. Registro de transacciones de paso.

El OP-IP/REV envía pasadas al INT IP/REV a través de esta interfaz

ccccccc20
 

5.5.1. Petición.

Comando HTTP: POST /v1/pasos
Contenido: Lista<Paso>
Emite: OP-IP/REV
Recibe: INT-IP/REV
Objetos: Paso

Nota: La definición de los objetos se encuentra en el anexo técnico del swagger del servicio.

5.6. Confirmación de transacciones de paso.

La confirmación del procesamiento exitoso o errado de las transacciones reportadas por el OP IP/REV es reportado con posterioridad por parte del INT IP/REV al OP IP/REV

ccccccc21
 

5.6.1. Petición.

Comando HTTP: PUT /v1/confirmacionesPasos/
Contenido: List<ConfirmacionProcesamientoPaso>
Emite: INT-IP/REV
Recibe: OP-IP/REV
Objetos: ConfirmacionProcesamientoPaso

Nota: La definición de los objetos se encuentra en el anexo técnico del swagger del servicio.

5.7. Registro de ajustes.

El OP IP/REV envía ajustes al INT IP/REV a través de esta interfaz.

ccccccc22
 

5.7.1. Petición.

Comando HTTP: POST /v1/ajustes
Contenido: Lista<Ajuste>
Emite: OP-IP/REV
Recibe: INT-IP/REV
Objetos: Ajuste

Nota: La definición de los objetos se encuentra en el anexo técnico del swagger del servicio.

5.8. Confirmación de ajustes.

La confirmación del procesamiento exitoso o errado de las transacciones reportadas por el OP IP/REV es reportado con posterioridad por parte del INT IP/REV al OP IP/REV

ccccccc23
 

5.8.1. Petición.

Comando HTTP: PUT /v1/confirmacionesAjustes
Contenido: Lista<ConfirmacionProcesamientoAjuste>
Emite: INT-IP/REV
Recibe: OP-IP/REV
Objetos: ConfirmacionProcesamientoAjuste

Nota: La definición de los objetos se encuentra en el anexo técnico del swagger del servicio.

5.9. Registro de negación de autorización de paso.

Mediante esta interfaz el OP-IP/REV envía las ocurrencias de negaciones de paso de usuarios al INT IP/REV correspondiente, de modo que este pueda realizar gestiones asociadas a la atención de este evento.

ccccccc24
 

5.9.1. Petición.

Comando HTTP: POST /v1/negacionesPasos
Contenido: Lista<NegacionPaso>
Emite: OP-IP/REV
Recibe: INT-IP/REV
Objetos: NegacionPaso

Nota: La definición de los objetos se encuentra en el anexo técnico del swagger del servicio.

6. Integraciones hacia el SIGT.

El SIGT brindará la implementación de las operaciones PUT y POST para:

• Notificación de listas(10).

• Notificación de errores en el procesamiento de listas.

• Notificaciones y confirmaciones de paso.

• Notificaciones y confirmaciones de ajuste.

• Negaciones de paso.

• Actualización de saldos.

• Solicitud y entrega de pruebas.

Los servicios estarán disponibles para que tanto los operadores como los intermediadores repliquen todos los llamados (PUT y POST) al SIGT en el mismo momento y frecuencia con que son intercambiados los mensajes.

Igualmente, el SIGT realizará la notificación de los procesamientos y confirmaciones conforme a los requerimientos especificados previamente en este documento.

Adicionalmente, el SIGT proveerá servicios propios.

6.1. Servicios expuestos por el SIGT.

CódigoNombre del ServicioURLDescripción
SI-1Consulta estado asignación placa /v1/placas/{placa}/asignada Permite al INT IP/REV consultar si una placa tiene o no asignado un TAG activo.

6.1.1. Consulta del estado asignación de una placa.

El INT IP/REV podrá consultar el estado de asignación de una placa. Esta información será entregada conforme al último registro procesado por el SIGT de actualización de listas.

Petición

Comando HTTP: GET /v1/placas/{placa}/asignada
Contenido: EstadoAsignacionPlaca
Solicita: INT-IP/REV
Recibe: SIGT
Objetos: EstadoAsignacionPlaca

Nota: La definición de los objetos se encuentra en el anexo técnico del swagger del servicio.

6.2. Pruebas de interoperabilidad.

El SIGT ofrecerá un mecanismo automatizado y autogestionado dentro del proceso de certificación para que el OP-IP/REV y INT-OP/REV pueda verificar el cumplimiento de su sistema de información.

El procedimiento de pruebas de interoperabilidad será habilitado una vez se realice con éxito la actividad de registro y verificación de antecedentes dentro del proceso de certificación, tal como se presenta en el siguiente diagrama:

ccccccc25
ccccccc25
 

1. Proceso general de certificación.

El procedimiento permitirá al OP-IP/REV y INT-OP/REV descargar el “set” de pruebas, registrar y auditar los intentos de pruebas, facilitando la repetición de los mismos hasta que el resultado sea exitoso. De no serlo, permitirá consultar las inconsistencias presentadas para que puedan ser subsanadas.

Finalmente, el SIGT generará la aceptación de interoperabilidad tecnológica para proceder a la habilitación condicionado a la verificación exitosa de las pruebas.

Los aspectos evaluados por la prueba de interoperabilidad son:

• Autenticación.

• Utilización de tokens de seguridad.

• Uso de las taxonomías.

• Consumo de servicios en escenarios exitosos y fallidos.

• Uso de códigos de respuestas HTTP.

• Manejo de los encabezados.

1.7.2.4. Usuario IP/REV.

1 También incluye a quien delegue o subcontrate.

2 También incluye a quien delegue o subcontrate.

3 Ver sección 2.2.4.

4 Ver sección 2.2.4.

5 La Superindustria supervisa la prestación del servicio desde el punto de vista del consumidor, y el eventual abuso de la posición dominante, fallas del producto, baja calidad del mismo. Fuente: Superindustria, ¿Qué es la protección al consumidor? Consultado el 05/05/2015. Página web: http:// www.sic.gov.co/drupal/que-es-la-protección-al-consumidor.

6 Para efectos del presente capítulo, se refiere exclusivamente a concesiones de infraestructura vial.

7 Relacionado con el funcionamiento del sistema IP/REV.

8 E Relación con el funcionamiento del sistema IP/REV.

9 De acuerdo al valor solicitado por los contratos de concesión actuales 4G.

10 Para el procedimiento de pruebas de interoperabilidad, los cuales se basan en un “set” de pruebas, se ofrecerán también las interfaces GET de consulta.