Sergio Iván Agudelo Santana
Proyecto trabajo de grado
Empresa: GRUPO JAMPIG
1 Planteamiento del Problema 4
2 Justificación 5 2.1 Ambiental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Económico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Académico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 Social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5 Personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Objetivos 7 3.1 Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 Desarrollo Fase I 8 4.1 Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1 ITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.2 Segmentos . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.3 Intersecciones . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.4 Flujo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.5 Velocidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.6 Tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.7 Ocupación . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.8 Densidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.9 Funcionalidad de un semáforo . . . . . . . . . . . . . . . . 9
4.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1 Protocolos de comunicación enfocados al transporte . . . . 10 4.2.2 Protocolo ZIGBEE . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3.1 Antena GPRS . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3.2 Detectores de tráfico . . . . . . . . . . . . . . . . . . . . . 19
5 Desarrollo Fase II 24 5.1 Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2 Capa de Transporte . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.1 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.2.2 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Capa de aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.3.1 Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.3.2 Soluciones planteadas . . . . . . . . . . . . . . . . . . . . 27
5.4 Capa de información . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.4.1 Árbol de objetos . . . . . . . . . . . . . . . . . . . . . . . 35 5.4.2 Conexión con base de datos . . . . . . . . . . . . . . . . . 47 5.4.3 Protección de datos . . . . . . . . . . . . . . . . . . . . . 48
1
5.5 Implementación completa . . . . . . . . . . . . . . . . . . . . . . 49 5.5.1 Parte uno . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.5.2 Parte dos . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6 Desarrollo Fase III 54
7 Desarrollo Fase IV 55 7.1 Módulo RF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 7.2 Módulo Potencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.2.1 Panel solar . . . . . . . . . . . . . . . . . . . . . . . . . . 56 7.2.2 Batería . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.2.3 Controlador de carga . . . . . . . . . . . . . . . . . . . . . 58 7.2.4 Cálculos necesarios . . . . . . . . . . . . . . . . . . . . . . 58
7.3 Módulo LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8 Desarrollo Fase V 61 8.1 Script desarrollado . . . . . . . . . . . . . . . . . . . . . . . . . . 61 8.2 Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9 Conclusiones 65
2
Introducción En el presente trabajo se abordará la temática de sistemas de transporte in- teligente, mas precisamente relacionados a los semáforos inteligentes, donde estos dispositivos han tenido una acelerada evolución en los últimos años, ayudando a mejorar la movilidad en los puntos donde se han ubicado. A partir de ello el presente documento se centrará en un sistema de semáforos ya implementado por el GRUPO JAMPIG, al cual se le adaptó una base de datos local manejada desde una RASPBERRY pi 3 y dicho dispositivo se comunicará a través de un módem con GPRS y haciendo uso de alguno de los protocolos existentes para dicho tipo de sistema( los protocolos a estudiar serán el NTCIP, OCIT, SCATS. Cada uno de estos estándares fueron incorporados en sus lugares de procedencia y cada cual tiene unas ventajas y desventajas, por lo tanto se hace necesario el análisis de estos sistemas), los cuales también se analizarán dentro del documento para así adoptar uno e implementarlo en el sistema planteado por la compañía.
3
1. Planteamiento del Problema En los últimos años, se ha presentado un fenómeno de crecimiento poblacional a un ritmo exorbitante y muy desordenado, lo que trae consigo que las ciudades exis- tentes se expandan y que algunas áreas rurales se urbanicen, además es necesario una red de infraestructura vial capaz de soportar un conjunto de automóviles, motocicletas, peatones, y demás formas de transporte. Ya que un aspecto es consecuencia del otro, la cantidad de automóviles por así generalizar todo el par- que automotor colombiano, se ha elevado a razón del crecimiento poblacional y a la facilidad de acceder a los mismos, aunque Colombia tiene un parque au- tomotor grande aun no es considerable con los de otros lugares del planeta[1], aparte de esto Colombia tiene un grave problema latente, el cual consiste en la poca planeación y la no realización de un estudio a futuro para la viabilidad del mismo, lo que quiere decir que la malla vial de Colombia no fue diseñada para manejar los volúmenes de masa (entiéndase masa por cada individuo o automóvil que transita a una hora y lugar específico)a los cuales se ve enfrentado a diario. La problemática al cual el siguiente proyecto hace referencia es al mal fun- cionamiento de la semaforización existente en el país, enfocándose al área de trabajo del grupo JAMPIG, un empresa especialista en las ITS (sistema de trans- porte inteligente por sus siglas en inglés)[2], los semáforos son dispositivos eléc- tricos que controlan el tráfico vehicular, bajo una configuración de tres luces, una roja para detenerse, una amarilla intermedia y una verde para avanzar[3], aunque dichos dispositivos nacieron para controlar el tráfico actualmente no re- suelven del todo el problema, debido a la mala sincronización entre semáforos y a que los sistemas actuales no toman en cuenta el flujo de autos y de peatones, es decir no son sistemas adaptativos, por dar un ejemplo al momento en que el sistema se cae, este no tiene una contingencia rápida, sino hasta que los operarios de la compañía lleguen a realizar el mantenimiento o la reparación, además el controlador requiere toda una infraestructura física y una programación. Así que ¿Cómo incorporar un protocolo de comunicación orientado a las ITS sin realizar mayores cambios al módulo semafórico tipo maestro del GRUPO JAMPIG y con capacidad de conectarse a las grandes centrales de gestión semafórica existentes en Colombia?
4
2. Justificación 2.1 Ambiental Ambientalmente este proyecto está enfocado a reducir el consumo de energía eléctrica, dado que la alimentación requerida consiste en energía solar, la cual no tiene un impacto sobre el medio ambiente, puesto que en Colombia las princi- pales generadoras de energía son de tipo hidráulica (aprovecha la energía poten- cial del agua) y calorífica (además de la combustión de carbón también requiere volúmenes de agua). Por otro lado se ve involucrado el hecho que entre menos tiempo un automóvil permanezca detenido y encendido su motor, disminuiría la emisión de CO2.
2.2 Económico Económicamente este proyecto tiende a automatizar algunos aspectos en el pro- ceso de semaforizar un cruce o una serie de cruces, así que el personal empleado para tal tarea disminuirá, uno de los aspectos por los que este fenómeno ocur- rirá es que la programación, monitoreo y control preventivo de los semáforos se realizara de forma remota. Teniendo en cuenta que el sistema tiene como ali- mentación paneles fotovoltaicos, el consumo de la red nacional de energía es nulo, por lo tanto no existe tal costo.
2.3 Académico Académicamente el sistema genera toda una investigación, los sistemas de trasporte inteligente en Colombia no es un tema del diario vivir, por lo tanto el proyecto intenta cambiar algunos estándares y adaptarlos a las condiciones colombianas, uno de estos retos es el manejo en los protocolos (NTCIP, SCOOTS, SCATS, OCIT, ETC…) de comunicación enfocados al transporte.
2.4 Social Se habla por aspecto social el reducir los tiempos de espera en un cruce y mejorar la movilidad, que es un aspecto que hoy por hoy es nuestro dolor de cabeza, en Bogotá por colocar un ejemplo los accidentes viales son a diario, un estudio de la universidad distrital hace referencia a los accidentes por localidad [4], en el cual se evidencia que los puntos focales de accidentes están asociados a conges- tiones de automóviles, dando como principales causas, las condiciones de la vía, imprudencia de la gente y por último y en lo que se enfoca este documento mal funcionamiento de los semáforos[5]
5
Figure 2.1: Estadística promedio de fallas del sistema de semaforización de Bogotá D.C. [5]
2.5 Personal A nivel personal es un reto cumplir con las especificaciones solicitadas por la compañía, al igual cumplir con este proyecto significa mejorar la movilidad en los puntos en los cuales está enfocado el grupo JAMPIG.
6
3. Objetivos 3.1 Objetivo General Implementar uno de los protocolos de comunicación enfocados a las ITS (NTCIP, OCIT, SCATS) en uno de los módulos semafóricos tipo maestro del GRUPO JAMPIG, capaz de conectarse a través del espectro electromagnético para su monitorización y control a una central semafórica que posea el protocolo selec- cionado.
3.2 Objetivos Específicos 3.2.1 Analizar, estudiar y evaluar los protocolos de comunicación orientados a las ITS. 3.2.2 Seleccionar e implementar el estándar a utilizar. 3.2.3 Actualizar el firmware de la central de control para dar paso al protocolo seleccionado. 3.2.4 Verificar, ajustar e integrar los módulos existentes del dispositivo semafórico tipo maestro junto con el protocolo incorporado. 3.2.5 Validar la conexión del módulo semafórico tipo maestro del grupo JAMPIG a una central de control semafórica que trabaja bajo el protocolo utilizado.
7
4. Desarrollo Fase I Para desarrollar la primera fase, la cual esta orientada al estudio de las ITS y acerca de los protocolos de gestión de semáforos existentes, es necesario empezar por la definicion de cada uno de estos aspectos.
4.1 Generalidades 4.1.1 ITS Los sistemas inteligentes de transporte pueden ser definidos como el matrimonio entre los avances en tecnologías de información y sistemas de comunicación con los vehículos y redes de caminos que forman parte del sistema de transporte. También pueden definirse como la optimización de las funciones propias de los elementos básicos del Tránsito – Infraestructura Vial (calles y caminos) y Vehícu- los – mediante la aplicación de tecnologías avanzadas que interrelacionan tales elementos. Existen dos elementos fundamentales en los Sistemas Inteligentes de Transporte el primero es la capa lógica compuesta por las funciones y los procesos y el segundo es la capa física donde se encuentran los sistemas y las tecnologías. En ambos casos existe una coherencia con la definición de los servicios o aplica- ciones ITS que se asocia a un marco normativo de referencia [6].
Figure 4.1: Estructura basica de los ITS. [5]
4.1.2 Segmentos Caracterizados por su longitud, número de carriles, elemento de la red en el que comienza y elemento en el que finaliza. Sólo se considera un sentido de tráfico por segmento, por lo que una calle puede estar constituida por varios segmentos, tanto para expresar los dos sentidos de circulación (cuando ambos estén presentes) como las intersecciones que atraviesan [7].
8
4.1.3 Intersecciones Son los elementos que principalmente definen los comienzos y finales de los seg- mentos, y está determinado por la unión de dos o más segmentos. Es aquí donde será necesario definir el derecho de paso de unos sentidos o direcciones respecto de otros, permitiendo realizar los cambios de dirección en el flujo de tráfico de una forma eficiente y segura[7].
4.1.4 Flujo Es la cantidad de vehículos por unidad de tiempo en un determinado segmento[7].
4.1.5 Velocidad Distancia recorrida por unidad de tiempo. La velocidad a la que circulan los vehículos es un dato importante para medir el nivel de congestión que existe[7].
4.1.6 Tiempo Es el tiempo de viaje sobre un segmento del camino conocido. Esta medida es obtenida dividiendo el largo de la calle entre la velocidad media en recorrer la calle, en el caso de los vehículos, o en atravesarla, en el caso de los peatones[7].
4.1.7 Ocupación Es el porcentaje de tiempo que en un segmento de una ruta es ocupado por vehículos[7].
4.1.8 Densidad Es la cantidad de vehículos por unidad de distancia, en un periodo de tiempo[7].
4.1.9 Funcionalidad de un semáforo 4.1.9.1 Operación constante
Las indicaciones de rojo y verde son temporizadas a valores constantes calculados mediante el análisis del comportamiento histórico del tráfico en la intersección. Este tipo de operación asume que los patrones de tráfico pueden predecirse según sea la hora del día y, por lo tanto, no precisa de detectores de tráfico en la inter- sección que regulan. Este tipo de operación sólo suele ser utilizada cuando no se dispone de un presupuesto suficiente para implementar una operación flexible[8].
4.1.9.2 Operación Flexible
Las intersecciones que operan de esta manera consisten de controladores de tráfico y detectores de vehículos colocados en las vías próximas a la intersección. En una operación flexible se tiene que calcular la duración de los intervalos de verde. Los intervalos de verde pueden finalizar en una de las siguientes cuatro formas[9].
9
4.1.9.2.1 Alcance del tiempo máximo de tiempo verde (timing out) El intervalo se acaba cuando se alcanza un tiempo máximo de verde previamente establecido[9].
4.1.9.2.2 Disminución sensible del flujo de tráfico en las proximidades de la intersección (gapping out) Cuando se presenta un flujo ligero de tráfico que es menor que un cierto valor umbral previamente establecido[9].
4.1.9.2.3 Finalización por orden del sistema (force-off) Cuando un sis- tema de semáforos es parte de un sistema coordinado, el sistema mantiene la señal en espera con la operación indicada[9].
4.1.9.2.4 La señal es expulsada Cuando un vehículo prioritario, por ejem- plo una ambulancia o un coche de bomberos, se aproxima a la intersección, los intervalos de verde asociados a movimientos no prioritarios deben de terminar en favor de los que están asociados a esos movimientos prioritarios[9].
4.2 Software 4.2.1 Protocolos de comunicación enfocados al transporte 4.2.1.1 NTCIP (Estados Unidos)
El NTCIP es un proyecto de estandarización conjunta de la AASHTO, ITE, y NEMA, Oficina del Secretario Adjunto de Investigación y Tecnología. NTCIP es una familia de estándares de comunicación para transmitir datos y mensajes entre el ordenador sistemas utilizados en los Sistemas de Transporte Inteligente (ITS). Un estándar de comunicaciones especifica un conjunto de reglas para los mensajes de cómo se codifican y se transmiten entre los dispositivos electrónicos. El equipo en cada final de una transmisión de datos utiliza la misma especifi- cación para comunicarse con éxito. Es un poco como las lenguas del ser humano dado que tienen unas reglas para el alfabeto, vocabulario y gramática para un idioma especifico [10]. Dicho sistema cuenta con varias versiones sobre el mismo desarrollo, fue implementado por compañías estadounidenses, dentro del mismo país, este sistema cuenta con varias características:
4.2.1.1.1 Interoperabilidad La interoperatividad refleja la capacidad de múlti- ples sistemas y dispositivos de diferentes tipos de centros de intercambio informa- ción para un propósito común. La interoperabilidad permite que los componentes del sistema de diferentes proveedores para comunicarse entre sí para proporcionar las funciones del sistema y para trabajar juntos como un sistema completo. Por ejemplo, utilizando la infraestructura mismas comunicaciones para interconectar un sistema de gestión con el tráfico controladores de señal, señales de mensajes dinámicos, controles de vigilancia de vídeo y otros dispositivos para gestionar el tráfico refleja un ejemplo real mundo de interoperabilidad.
10
4.2.1.1.2 Intercambiabilidad La intercambiabilidad refleja la capacidad de intercambiar dispositivos del mismo tipo en la misma canal de comunicaciones y que dichos dispositivos interactuar con otros dispositivos del mismo tipo que utiliza funciones basadas en estándares. Con capacidad de intercambio, los com- ponentes del sistema pueden modificarse a cabo (conmutada) con componentes similares de diferentes fabricantes, ya que poseen común funcional y física car- acterísticas. Un ejemplo de intercambiabilidad es un controlador de señales de diferentes fabricantes que interactúan entre sí para proporcionar la coordinación de señales de tráfico a lo largo de un camino pasante arterial[16].
4.2.1.1.3 Centro de Campo (C2F) Comunicaciones NTCIP proporciona estándares de comunicaciones de dos tipos diferentes para sus comunicaciones. El primer tipo es entre un sistema central y múltiples dispositivos de control o de vigilancia gestionado por la central. Un ejemplo de un sistema central es un orde- nador en el seguimiento y el control de la operación de controladores basados en microprocesadores de carretera para las señales de tráfico dentro de una ciudad. El sistema central puede enviar instrucciones a los controladores de semáforos para cambiar configuraciones de cronometraje, las condiciones de circulación y el envio de información de los estados del tráfico a la computadora. Otros ejemplos de este tipo de comunicaciones incluyen.
• Un sistema de transporte a bordo del vehículo se comunica con un disposi- tivo de señales de tráfico para facilitar la prioridad de tránsito.
• Un sistema de gestión de la autopista que comunica con los detectores y medidores de rampa en las autopistas.
• El control de sistema de gestión de tráfico de un camino de iluminación, circuito cerrado de televisión (CCTV), las señales de mensajes dinámicos, transmisores de radio de asesoramiento, sensores ambientales y estaciones de volumen de tráfico en las carreteras.
Como la mayoría de aplicaciones de este tipo implican un sistema de centro de la comunicación con varios dispositivos en la carretera o en los vehículos de la agencia, este tipo de comunicación se denomina ”centro de campo” (C2F). Los protocolos NTCIP destinados a esta aplicación se utiliza a menudo en un entorno donde un sistema de centro, rutinariamente encuesta cada dispositivo de campo, como en el caso más común de múltiples dispositivos de campo, se suele compartir un canal de comunicaciones.
4.2.1.1.4 Centro de Centro de Comunicaciones (C2C) El segundo tipo de comunicación implica los mensajes enviados entre dos o más sistemas de cen- tro. Este tipo de comunicación se denomina centro a centro de comunicaciones (C2C), aunque dos o más de los diversos sistemas pueden de hecho, estar situados dentro de la misma ”central” o edificio, son lógicamente separados. C2C implica comunicaciones de igual a igual entre cualquier número de sistemas de centros en un muchos a muchos de una red. Este tipo de comunicación es similar a la Internet, en que cualquier centro puede solicitar información de, o proporcionar información a, cualquier número de otros centros. Un ejemplo de las comunica- ciones C2C es de dos centros de gestión de tráfico que intercambian en tiempo
11
real información sobre el inventario y el estado de los dispositivos de control de tráfico. Esto permite que cada sistema de centro sabe qué plan de tiempo, por ejemplo, el otro sistema central está en marcha para permitir la coordinación de señales de tráfico allá de las fronteras geográficas del centro [17].
Figure 4.2: Propiedades e imteroperatividad e intercambiabilidad de NTCIP[10]
Figure 4.3: NTCIP Framework [10]
12
4.2.1.2 SCATS (Australia)
SCATS no requiere la intervención del operador para su funcionamiento del día a día. Sin embargo, los operadores tienen acceso instantáneo a la información de flujo de tráfico, estado del sistema y fallos hasta el nivel de una sola lámpara fundida. SCATS se adapta a las exigencias de cambio de los flujos de tráfico. Por ejemplo, se puede adoptar una estrategia para eliminar las cargas de tráfico repentino e impredecible, tales como los cambios de clima, deportes y eventos públicos y conciertos.También supervisa las condiciones cambiantes de tráfico que se producen en el tráfico normal o especialmente cuando hay una avería, accidente u obras viales o condiciones meteorológicas adversas.Se ajusta contin- uamente a cambios de tiempo en la señal para optimizar el flujo por medición de la densidad de vehículos en cada carril [11]. Se compone de tres niveles, un computador central para realizar la monitorización del sistema global, computa- dores regionales remotos o locales y controladores locales de señales de tráfico. Su objetivo es la reducción de paradas y retraso, mejorando los tiempos de las rutas. El computador central permite el acceso a los computadores regionales para la recogida de datos de tráfico, datos de entrada y acciones de monitorización.[16].
4.2.1.3 OCIT (Alemania)
Significa interfaz abierta de sistemas de control de comunicación de tráfico, cen- tro a centro. OCIT cubre las funciones para la comunicación entre los sistemas centrales de control de tráfico y el encaminamiento del tráfico, OCIT está orien- tado a las necesidades prácticas. Debido a los bajos costos de implementación, su uso también es adecuado para soluciones con presupuestos limitados [12]. Para el sistema OCIT el cual fue incorporado en algunas ciudades de Alemania, se tienen las siguientes características:
• Protocolo de conversión basado en el estándar SOAP con un simple pa- trón de petición-respuesta en la comunicación (recuperación directa de los
13
Figure 4.6: Esquema Básico del protocolo SCATS [19]
datos).
• Definición de un modelo de datos global en la región de datos de proceso que abarca todas las ramas del sistema de enrutamiento de control de tráfico y el tráfico, el uso de la OCIT-I modelo de datos para los SAT. La funcionalidad del modelo de datos de la OCIT-I es retratado en su totalidad.
• Integración de sistemas y los ajustes deseados se regulan previamente como parte de la planificación del proyecto.
• Pruebas de conformidad del protocolo se llevan a cabo en un entorno de prueba que se proporciona el uso de OCIT. Las pruebas de todas las im- plementaciones de protocolo (contenido y datos) se llevan a cabo sobre una base de proyecto por proyecto.
• Las actualizaciones incluyen componentes de DATEX II pueden ser posibles dependiendo de retomar proyecto de requisitos.
14
• Las actualizaciones incluyen componentes de DATEX II pueden ser posibles dependiendo de retomar proyecto de requisitos.
La interfaz de comunicación debe aplicarse de la misma manera en todas las unidades centrales. Para ello, el protocolo SOAP se utiliza como una interfaz de comunicación de nivel superior, a través de la cual toda la comunicación se lleva a cabo. La forma descrita aquí se designa como un protocolo OCIT-C. Esta interfaz OCIT-C está abierta y se puede utilizar en diversos sistemas, en su mayor parte en el área de los sistemas de control de tráfico. Es el propósito de este documento para describir el protocolo OCIT-C y su uso. No se va a describir los datos estructurales de los datos a transmitir. Esto se describe en el documento ”OCIT- C de datos”. Este sistema se incorpora bajo el siguiente esquema de conexión y de interactividad [18]. El siguiente gráfico muestra como se comunica los servidores
Figure 4.7: Esquema general de OCIT-C [12]
con los clientes, siendo una interactividad de tipo bidireccional. En resumidas cuentas y palabras el protocolo se describe como 4 capas, al estilo del protocolo OSI[18].
4.2.1.4 El sistema SCOOT
(Técnica de Optimización de los valores de Desplazamiento, Ciclo y Giro) se fundamenta en la experiencia aportada por la Red de Tráfico TRANSYT. Lo positivo de este sistema es que realiza una optimización a tres niveles: giro, ciclo y desplazamiento. Utiliza los datos de los detectores de desplazamiento, normalmente detectores de lazo enterrados en el pavimento. Mide el tráfico en tiempo real y desarrolla un modelo de flujo de demanda a cada intersección. Esta secuencia se contrasta con el flujo de salida y de vehículos encolados. Los ajustes temporales son pequeños y no se adaptan a los picos de tráfico, salvo que sea un aumento continuo. Este modelo es utilizado en grandes urbes como Toronto, Madrid, Reino Unido, y para el caso colombiano en Cartagena[16].
15
Figure 4.9: Capas cliente- servidor OCIT-C [18]
4.2.2 Protocolo ZIGBEE ZigBee es un estándar de comunicaciones inalámbricas diseñado por la ZigBee Alliance. Es un conjunto estandarizado de soluciones que pueden ser implemen- tadas por cualquier fabricante. ZigBee está basado en el estándar IEEE 802.15.4 de redes inalámbricas de área personal (wireless personal área Newark, WPAN) y tiene como objetivo las aplicaciones que requieren comunicaciones seguras con baja tasa de envío de datos y maximización de la vida útil de sus baterías[13]. ZigBee, también conocido como ”HomeRF Lite”, es una tecnología inalámbrica con velocidades comprendidas entre 20 kB/s y 250 kB/s.· Los rangos de alcance son de 10 m a 75 m[13].
• Puede usar las bandas libres ISM (6) de 2,4 GHz (Mundial), 868 MHz (Europa) y 915 MHz (EEUU).
• Una red ZigBee puede estar formada por 255 nodos los cuales tienen la
16
Figure 4.10: aplicaciones de la tecnologia ZIGBEE [13]
mayor parte del tiempo el transceiver ZigBee dormido con objeto de con- sumir menos energía que otras tecnologías inalámbricas.
• Un sensor equipado con un transceiver ZigBee pueda ser alimentado con dos pilas AA durante al menos 6 meses y hasta 2 años.
• La fabricación de un transmisor ZigBee consta de menos circuitos analógicos de los que se necesitan habitualmente.
• Diferentes tipos de topologías como estrella, punto a punto, malla, árbol.
• Acceso de canal mediante CSMA/CA(7) (acceso múltiple por detección de portadora con evasión de colisiones).
• Escalabilidad de red – Un mejor soporte para las redes más grandes, ofre- ciendo más opciones de gestión, flexibilidad y desempeño.
• Fragmentación – Nueva capacidad para dividir mensajes más largos y per- mitir la interacción con otros protocolos y sistemas.
• Agilidad de frecuencia – Redes cambian los canales en forma dinámica en caso que ocurran interferencias.
• Gestión automatizada de direcciones de dispositivos.
• El conjunto fue optimizado para grandes redes con gestión de red agregada y herramientas de configuración.
• Localización grupal – Ofrece una optimización adicional de tráfico necesaria para las grandes redes.
17
• Instalación de servicio inalámbrico – El modulo fue mejorado con capaci- dades para poner en marcha el servicio inalámbrico.
• Recolección centralizada de datos – El modulo fue sintonizado específica- mente para optimizar el flujo de información en las grandes redes.
4.2.2.1 Ventajas
• Ideal para conexiones punto a punto y punto a multipunto.
• Diseñado para el direccionamiento de información y la actualización de la red.
• Opera en la banda libre de ISM 2.4 Ghz para conexiones inalámbricas.
• Óptimo para redes de baja tasa de transferencia de datos.
• Alojamiento de 16 bits a 64 bits de dirección extendida.
• Reduce tiempos de espera en el envío y recepción de paquetes.
• Detección de Energía (ED).
• Ciclo de trabajo mínimo - Proporciona larga duración de la batería.
• Soporte para múltiples topologías de red: Estática, dinámica, estrella y malla.
• Hasta 65.000 nodos en una red.
• Cifrado AES de 128-bit - Provee conexiones seguras entre dispositivos.
• Son más baratos y de construcción más sencilla.
4.2.2.2 Desventajas
• Solo manipula textos pequeños comparados con otras tecnologías.
• Zigbee trabaja de manera que no puede ser compatible con bluetooth en to- dos sus aspectos porque no llegan a tener las mismas tasas de transferencia, ni la misma capacidad de soporte para nodos.
• Tiene menor cobertura porque pertenece a redes inalámbricas de tipo WPAN[13].
18
Figure 4.11: Estructura ZIGBEE [13]
4.3 Hardware 4.3.1 Antena GPRS Las siglas GPRS vienes de las palabras inglesas General Packet Radio Service( Servicio general de paquetes vía radio en castellano), la cual permite comunicarse vía satélite, sin necesidad de cables ni conexión física a dos terminales móviles. El GPRS permite pagar solo por la información enviada/recibida. Se basa en mandar la información en pequeños paquetes, es decir no enviar todo al mismo tiempo sino por tramas y únicamente cuando el canal estuviese libre, aprovechando así los huecos del mismo. Si la red está muy cargada, la trasmisión podría demorarse bastante[14].
4.3.2 Detectores de tráfico 4.3.2.1 Detectores de presión
Consisten en una plancha de caucho en cuyo interior se sitúan dos láminas metáli- cas, muy cercanas entre sí, que establecen contacto cuando pasa un vehículo que supera un cierto peso umbral sobre la plancha. Todo este mecanismo está ubicado en la parte superior de una plataforma de hormigón o metálica que se empotra
19
Figure 4.12: Esquema de antena GPRS envío y recepción de información [14]
en el pavimento. Puede conseguirse una detección direccional si en vez de las dos láminas se ponen cuatro, enfrentadas dos a dos [15].
4.3.2.2 Detectores magnéticos
Detectan la distorsión del campo magnético producida por el paso sobre ellos de una masa metálica. Están formados por un tubo metálico en cuyo interior hay un núcleo de hierro con una bobina conectada a un amplificador. Los detectores más habituales que emplean esta tecnología no son capaces de detectar la dirección del movimiento, por lo que se fueron incorporando mejoras en su diseño dando lugar a los llamados detectores magnéticos compensados, formados por cuatro núcleos, que permiten distinguir el sentido de la marcha de la masa metálica que circula sobre ellos[15].
4.3.2.3 Detectores de lazo
Constituyen el tipo de detector más utilizado en las vías públicas actuales. Su principio de funcionamiento se basa en emplear las características de un lazo magnético situado sobre la superficie de la carretera y las fluctuaciones eléctricas producidas por la aproximación de un objeto metálico (que en este caso es un vehículo) para detectar su presencia y su paso. Efectivamente, mientras circula una corriente alterna por el lazo metálico situado sobre la carretera, se crea un campo magnético de la misma frecuencia cerca de la superficie de la carretera. Si un objeto metálico entra en este campo magnético, entonces la inducción mag- nética causa corrientes sobre el objeto metálico y como resultado se produce una variación en la impedancia a la salida del lazo magnético. Cuando se detecta un cambio de impedancia se detecta un vehículo. El cambio de inductancia
20
provocado por el paso de vehículos varía según el tipo de vehículo. Este tipo de detectores son más sensitivos a vehículos pequeños que a vehículos de gran volu- men. Entre las medidas que este tipo de detector de tráfico puede proporcionar destacan las siguientes:
• Presencia de un vehículo.
• Tipo de vehículo (mediante el empleo de técnicas de reconocimiento de patrones es posible diferenciar entre seis o más tipos de vehículos).
• Velocidad del vehículo (mediante el uso de lazos dobles).
• Ocupación de los lazos.
4.3.2.4 Detectores de Radar.
Constan de un aparato emisor y otro receptor de ondas electromagnéticas y gen- eralmente se suspenden sobre la vía o se colocan lateralmente a ella. En la actualidad se emplean dos tipos de detectores de radar de microondas en las apli- caciones de gestión del tráfico. El primero transmite energía electromagnética a una frecuencia constante midiendo la velocidad de los vehículos dentro de su campo de visión usando el principio Dopler, en el que la diferencia de frecuencia entre las señales transmitidas y recibidas es proporcional a la velocidad del ve- hículo. Por lo tanto, la detección de una variación en la frecuencia denota el paso de un vehículo. Este tipo de sensor no puede detectar vehículos parados y, por lo tanto, no es adecuado para aplicaciones que precisan detectar la presencia de vehículos tales como regulación de semáforos o líneas de parada obligatoria. El segundo tipo de detector de radar de microondas transmite una onda en forma de diente de sierra, también denominada onda continua modulada en frecuencia, que varía la frecuencia transmitida de forma continua en el tiempo. Los vehícu- los parados se detectan midiendo el rango desde el detector hasta el vehículo y también calculando la velocidad del vehículo midiendo el tiempo que le lleva al vehículo viajar entre dos marcas internas que representan distancias conocidas para el radar. Al disponer de la característica de detección de vehículos parados, este detector suele denomina se radar de microondas de presencia real[15].
4.3.2.5 Detector pasivo de infrarrojo
Este tipo de dispositivo es capaz de detectar el paso y la presencia de vehículos, pero no su velocidad. Su método de funcionamiento se basa en un detector sen- sitivo a la energía de fotones colocado en un plano focal para medir la energía infrarroja emitida por los objetos en el campo de visión del detector. Los detec- tores pasivos no transmiten energía por si mismos. Cuando un vehículo entra en la zona de detección produce un cambio en la energía medida normalmente desde la superficie de la vía en la ausencia de vehículos. El cambio en la energía es pro- porcional a la temperatura absoluta del vehículo y la emisividad de la superficie metálica del vehículo (la emisividad es el cociente de la energía emitida respecto al radiante perfecto de energía a la misma temperatura). La diferencia de energía
21
que es capaz de detectar este detector se reduce ante condiciones meteorológicas adversas (lluvia, nieve, niebla,...)[15].
4.3.2.6 Detector activo de infrarrojo
Su funcionamiento es similar al de los detectores de radar por microondas. Los más comunes utilizan un diodo láser para emitir energía en el espectro cercano al infrarrojo, una porción del cual vuelve al receptor del detector desde el vehículo de su campo de visión. Los detectores basados en el radar láser pueden suministrar la presencia, el paso y la velocidad de vehículos. La medición de la velocidad se realiza anotando el tiempo que le lleva a un vehículo cruzar dos haces de infrarro- jos que están ubicados a una distancia conocida. Algunos de estos detectores son capaces de clasificar los vehículos contrastando las mediciones con unos ficheros modelos [15].
4.3.2.7 Detectores de ultrasonido
Los detectores ultrasónicos emiten sonidos a una frecuencia entre los 25 kHz a los 50 kHz (según sea el fabricante). Estas frecuencias no están en la franja audible. Una porción de la energía transmitida se refleja desde la carretera o la superficie del vehículo de nuevo al detector y se procesa para dar el paso y presencia de vehículos. Un detector típico de presencia ultrasónico emite energía ultrasónica en forma de pulsos. El tiempo que le lleva al pulso dejar el detector, chocar contra la superficie y regresar al detector es proporcional al rango del detector a la superficie. Cuando un vehículo se introduce en su campo de visión se mide el rango desde el detector hasta el vehículo, obteniéndose un rango menor que el producido sobre la vía lo que produce en el detector una señal de detección de vehículo [15].
4.3.2.8 Detectores acústicos pasivos
El tráfico de vehículos produce una energía acústica o sonido audible desde una variedad de fuentes dentro del vehículo y desde la interacción de los neumáticos del vehículo con la superficie de la vía. Cuando un vehículo pasa por la zona de detección, el algoritmo de procesado de señales detecta un incremento respecto a la energía del sonido y se genera una señal de presencia de vehículo. Cuando el vehículo abandona la zona de detección, la energía del sonido decrece hasta por debajo de un nivel de detección umbral terminando la señal de presencia de vehículo[15].
4.3.2.9 Procesadores de imágenes de video
Estos detectores identifican los vehículos y sus parámetros de flujo de tráfico aso- ciados mediante el análisis de las imágenes suministradas por cámaras de vídeo. Estas imágenes se digitalizan y se analizan para identificar los cambios observ- ables entre imágenes sucesivas, es decir, los cambios de los niveles de contraste entre píxeles adyacentes. Por lo tanto estos detectores pueden suministrar in- formación sobre el paso, presencia, velocidad, longitud y cambios de carriles de vehículos según sea el tipo de técnica de procesado de imágenes utilizada[15].
22
Figure 4.13: Configuración típica de gestión de tráfico. Conexión del centro de control con una intersección semaforizada para Bogotá D.C. [5]
23
5. Desarrollo Fase II De acuerdo con la investigación realizada se decidió implementar el protocolo NTCIP, además de algunos cambios, como el hecho que se trabajaría sobre una base de datos, ya con esto se comienza con definir que camino se utilizará, es decir que item de cada capa se usará.
En este caso se utilizo el siguiente camino:
Figure 5.1: Framework NTCIP
Al igual es necesario ver que requerimientos pide el protocolo para ser incor- porado
5.1 Requerimientos • Los diálogos o secuencias de mensajes personalizados deben rastrear cor-
rectamente los objetos NTCIP estándar. La agencia debe identificar las relaciones entre los objetos NTCIP utilizados para administrar los objetos NTCIP estándar (incluyendo bloque y dinámico).
• La agencia no podrá responder a mas de un dispositivo a la vez.
• Cada objeto se envía en una trama independiente.
• Existen señales que tienen relevancia dentro del sistema, estas señales son las de emergencia, para informar a la agencia algún cambio repentino en la rutina preprogramada.
• La sincronización se realiza una vez y luego solo informa los cambios únicos que se presentan.
• Existen objetos libres donde se puede desarrollar items propios de la com- pañía
24
Figure 5.2: Requerimientos [19]
En esta imagen se presenta los requerimientos que el protocolo sugiere ya que la capa física y de red no es necesario tocarlas estas no se desarrollan
en el trabajo, se inicio con la capa de transporte, luego la de aplicación y por ultimo la de información en ese orden de ideas se tiene.
5.2 Capa de Transporte 5.2.1 TCP Para esta parte se realizó un script en python de forma tal que desde la RASP- BERRY como cliente se conectara a través de este protocolo (TCP/IP) a un servidor, para el caso es necesario configurar la IP de ambos dispositivos para que la operación fuese directa; aparte es necesario un puerto de enlace.
25
Figure 5.3: Servidor TCP
Figure 5.4: Cliente TCP
5.2.2 UDP Como el protocolo establece la posibilidad de conexión tanto en TCP como en UDP por lo tanto se hace necesario un script en python que se encargue de la tarea de comunicación a través de este segundo protocolo, de igual forma que para el TCP se hace necesario un IP y un puerto de enlace predeterminados
26
Figure 5.5: Servidor UDP
Figure 5.6: Cliente UDP
5.3 Capa de aplicación En esta capa se trabajo con el protocolo SNMP, el cual significa Protocolo simple de administración de red y es un protocolo que les permite a los administradores de red administrar dispositivos de red y diagnosticar problemas en la red[22]. Entre las operaciones que puede realizar esta SET para escribir y están WALK, GET,GET NEXT para lectura, y un sistema de alertas denominado TRAPS.
5.3.1 Problemas Al generar un petición desde la central al agente, y teniendo la trama según los lineamientos del protocolo, no generaba la respuesta en la central. En pocas palabras no se podía generar la trama de response, por lo que se proponen varias soluciones que se describen a continuación.
5.3.2 Soluciones planteadas En primer lugar se intento realizar la captura de tramas en windows y al ver que no se solucionaba el problema se decidió realizar la implementación netamente en linux.
27
5.3.2.1 Captura de tramas
Con este método se planeo saber en que parte se cometía el error y corregirlo y se procedió de la siguiente manera.
5.3.2.1.1 En windows En este sistema operativo se hizo uso de dos software para la tarea, MIB-BROWSER para trabajar el protocolo SNMP, y HÉRCULES para escuchar y visualizar las tramas y a la vez enviar la trama construida. Se procedió de la siguiente manera: realizando peticiones con las operaciones básicas hacia el sistema propio, es decir se redirige al puerto 161 del local host que es el puerto predilecto para el protocolo SNMP.
1. Se genera una petición del MIB-BROWSER al software Hércules
Figure 5.7: Petición desde MIB-BROWSER hacia HERCULES
2. Con la trama que entrego, se envía al puerto 161 del localhost
Figure 5.8: Petición desde HERCULES al puerto 161
28
3. Ahora la trama que devuelve el sistema se envía de nuevo a MIB BROWSER
Figure 5.9: Respuesta desde HERCULES hacia MIB-BROWSER
Pero aun así el sistema no lo reconoce.
4. Si se envía directamente del MIB-BROWSER al puerto 161
Figure 5.10: Petición GET desde MIB-BROWSER al puerto 161
5.3.2.1.2 En linux Al igual que en windows se trabajó con MIB-BROWSER para corroborar las tramas usadas, y en vez de utilizar un software para la misma tarea que HÉRCULES, se uso los script en python previamente desarrollados para la misma función; aunque fue necesario realizar unos pequeños cambios para revisar puntualmente la trama.
29
1. Configurando el Script en python de UDP para escuchar y enviar las tramas correspondientes en hexadecimal
Figure 5.11: Programar script UDP para ver tramas en hexadecimal
2. Enviando desde el software MIB-BROWSER al puerto propio de SNMP es decir al 161 obtiene lo siguiente, sin embargo no se comunica asi.
Figure 5.12: Petición GET desde MIB-BROWSER al puerto 161
30
3. Ahora enviando la misma petición al Script de python
Figure 5.13: Petición GET desde MIB-BROWSER al script de python
4. Con dicha instrucción se envía al puerto 161, sin embargo no genera re- spuesta, y hasta este punto llega la prueba realizada.
Figure 5.14: Envio de la petición desde el script de python hacia el puerto 161
5.3.2.2 Librerías python
Una solución que se desarrollo fue la búsqueda de una librería en python capaz de manejar el protocolo SNMP, dando como resultado dos librerías, estas fueron PYSNMP y NET-SNMP que se desarrollan a continuación.
5.3.2.2.1 Instalación PYSNMP Siguiendo el procedimiento sugerido en la pagina de ”pysnmp.org”, se tiene el siguiente resultado
31
Figure 5.15: Instalación PYSNMP
posteriormente se importa la librería en python para ver que no generara errores
Figure 5.16: Verificación de PYSNMP
5.3.2.2.2 Instalación NET-SNMP De igual forma se uso la información encontrada en ”net− snmp.org”
32
Figure 5.19: Instalación NET-SNMP
5.3.2.3 Pruebas de funcionamiento
5.3.2.3.1 PYSNMP Utilizando unos de los script de ejemplo y ajustado a la prueba se obtuvo que en efecto funcionaba para la tarea solicitada.
Figure 5.20: Script de ejemplo de la librería PYSNMP
Al ejecutar el script solicitando un OID de un host de prueba y a través del puerto 161 dio como resultado
34
Figure 5.21: Prueba de la librería
5.3.2.3.2 NET-SNMP Esta librería aunque se instaló exitosamente no fue posible invocarla, por lo que esta solución no fue viable.
5.4 Capa de información 5.4.1 Árbol de objetos En el desarrollo propio del protocolo NTCIP es necesario definir el árbol de objetos que se va a manejar, que básicamente es la primera encapsulación que se va a realizar.
Por lo tanto cada objeto a definir cumple con realizar la identificación de la sección del sistema a trabajar, es decir con los conceptos que se manejan en la semaforización se realiza una explicación mas detallada de cada item, por lo tanto el árbol en una forma plana quedaría de la siguiente forma.
0 ccitt 0.0 null 1 iso 1.3 org 1.3.6 dod 1.3.6.1 internet 1.3.6.1.1 directory 1.3.6.1.2 mgmt 1.3.6.1.2.1 mib-2 1.3.6.1.2.1.1 system 1.3.6.1.2.1.1.1 sysDescr 1.3.6.1.2.1.1.2 sysObjectID 1.3.6.1.2.1.1.3 sysUpTime 1.3.6.1.2.1.1.4 sysContact 1.3.6.1.2.1.1.5 sysName 1.3.6.1.2.1.1.6 sysLocation 1.3.6.1.2.1.1.7 sysServices 1.3.6.1.2.1.3 at 1.3.6.1.2.1.3.1 atTable 1.3.6.1.2.1.3.1.1 atEntry 1.3.6.1.2.1.3.1.1.1 atIfIndex 1.3.6.1.2.1.3.1.1.2 atPhysAddress 1.3.6.1.2.1.3.1.1.3 atNetAddress 1.3.6.1.2.1.10 transmission 1.3.6.1.2.1.10.16 lapb
35
1.3.6.1.4.1.1206.4.2.6.3.3.5.1 timeBaseDayPlanEntry 1.3.6.1.4.1.1206.4.2.6.3.3.5.1.1 dayPlanNumber 1.3.6.1.4.1.1206.4.2.6.3.3.5.1.2 dayPlanEventNumber 1.3.6.1.4.1.1206.4.2.6.3.3.5.1.3 dayPlanHour 1.3.6.1.4.1.1206.4.2.6.3.3.5.1.4 dayPlanMinute 1.3.6.1.4.1.1206.4.2.6.3.3.5.1.5 dayPlanActionNumberOID 1.3.6.1.4.1.1206.4.2.6.3.3.6 dayPlanStatus 1.3.6.1.4.1.1206.4.2.6.3.4 globalLocalTimeDifferential 1.3.6.1.4.1.1206.4.2.6.4 globalReport 1.3.6.1.4.1.1206.4.2.6.4.1 maxEventLogConfigs 1.3.6.1.4.1.1206.4.2.6.4.2 eventLogConfigTable 1.3.6.1.4.1.1206.4.2.6.4.2.1 eventLogConfigEntry 1.3.6.1.4.1.1206.4.2.6.4.2.1.1 eventConfigID 1.3.6.1.4.1.1206.4.2.6.4.2.1.2 eventConfigClass 1.3.6.1.4.1.1206.4.2.6.4.2.1.3 eventConfigMode 1.3.6.1.4.1.1206.4.2.6.4.2.1.4 eventConfigCompareValue 1.3.6.1.4.1.1206.4.2.6.4.2.1.5 eventConfigCompareValue2 1.3.6.1.4.1.1206.4.2.6.4.2.1.6 eventConfigCompareOID 1.3.6.1.4.1.1206.4.2.6.4.2.1.7 eventConfigLogOID 1.3.6.1.4.1.1206.4.2.6.4.2.1.8 eventConfigAction 1.3.6.1.4.1.1206.4.2.6.4.3 maxEventLogSize 1.3.6.1.4.1.1206.4.2.6.4.4 eventLogTable 1.3.6.1.4.1.1206.4.2.6.4.4.1 eventLogEntry 1.3.6.1.4.1.1206.4.2.6.4.4.1.1 eventLogClass 1.3.6.1.4.1.1206.4.2.6.4.4.1.2 eventLogNumber 1.3.6.1.4.1.1206.4.2.6.4.4.1.3 eventLogID 1.3.6.1.4.1.1206.4.2.6.4.4.1.4 eventLogTime 1.3.6.1.4.1.1206.4.2.6.4.4.1.5 eventLogValue 1.3.6.1.4.1.1206.4.2.6.4.5 maxEventClasses 1.3.6.1.4.1.1206.4.2.6.4.6 eventClassTable 1.3.6.1.4.1.1206.4.2.6.4.6.1 eventClassEntry 1.3.6.1.4.1.1206.4.2.6.4.6.1.1 eventClassNumber 1.3.6.1.4.1.1206.4.2.6.4.6.1.2 eventClassLimit 1.3.6.1.4.1.1206.4.2.6.4.6.1.3 eventClassClearTime 1.3.6.1.4.1.1206.4.2.6.4.6.1.4 eventClassDescription 1.3.6.1.4.1.1206.4.2.6.4.6.1.5 eventClassNumRowsInLog 1.3.6.1.4.1.1206.4.2.6.5 security 1.3.6.1.4.1.1206.4.2.6.5.1 communityNameAdmin 1.3.6.1.4.1.1206.4.2.6.5.2 communityNamesMax 1.3.6.1.4.1.1206.4.2.6.5.3 communityNameTable 1.3.6.1.4.1.1206.4.2.6.5.3.1 communityNameTableEntry 1.3.6.1.4.1.1206.4.2.6.5.3.1.1 communityNameIndex 1.3.6.1.4.1.1206.4.2.6.5.3.1.2 communityNameUser 1.3.6.1.4.1.1206.4.2.6.5.3.1.3 communityNameAccessMask
Para efectos prácticos se creo un texto plano tal que cada objeto es consider- ado una constante, y el valor de la contante es el identificador de objeto(OID), de tal forma que cuando se desee saber que objeto es el mencionado se realice una
42
iteración sobre este número e ir discriminando por rama y no uno a uno, la idea es que el diccionario de objetos fluya en armonía como un árbol. Por otro lado cada objeto propio del estándar y que de una u otra forma será el que enmarcara la información, tiene un tipo de valor que puede recibir, en algunos casos es de tipo numérico y designa el rango, por lo que el sistema estará delimitado por una serie de condiciones para no incumplir con las condiciones del tipo de variable. De igual manera hay objetos que no se podrán modificar, o incluso serán trans- parentes en la operación, por lo que desde un principio ha de ser configurado de una manera limpia.
Figure 5.22: Texto plano propuesto
43
Para minimizar el peso de la información, se hace uso de un sistema de codi- ficación para cada uno de las señales que se pueden generar tanto en envio como en recepción. El estado del objeto : dynObjStatus 4
• valid 1
• createRequest 2
• underCreation 3
• invalid 4
• other 1
• hardware 2
• software 3
• normal 1
• transaction 2
• verifying 3
• updating 4
• error 5
• done 6
• startCmd 7
• commitCmd 8
• abortCmd 9
• completeCmd 10
• tooBig 1
• noSuchName 2
• badValue 3
• readOnly 4
powerSource 7
• other 1
• powerShutdown 2
• noSignPower 3
• acLine 4
• generator 5
• solar 6
• battery 7
5.4.2 Conexión con base de datos Teniendo la base de datos de forma física dentro de la memoria de la RASP- BERRY se realizó un script en python para acceder a ella, claro esta con el servidor de mysql, la prueba se realizó con ayuda de phpmyadmin como gestor, en principio se agrego unos campos en la base de datos para que posteriormente el script los devolviera.
Figure 5.23: Conexión base de datos y generar una consulta
47
Figure 5.25: Generación de la consulta en python
5.4.3 Protección de datos Puesto que los script de python no se encuentran protegidos es necesario realizar una encriptación a los mismos para que en dado caso de que tengan acceso al archivo no lo puedan modificar, ver o eliminar; para la tarea se hace uso de PGP, una herramienta libre para encriptar los datos y solo tener acceso a ellos a través de una contraseña
En las siguientes imágenes se muestra el archivo con y sin encriptar, cabe resaltar que para poder ver el archivo original es necesario escribir una contraseña.
Figure 5.26: Archivo encriptado
Figure 5.27: Archivo original
5.5 Implementación completa En esta parte se encuentra un problema puesto que el protocolo propio de la compañía se creo bajo la filosofía de pasos, mientras el NTCIP lo maneja por fases, asi que se plantea una primera parte donde se envían registros de la base de datos sin coherencia, es decir sin ser la información solicitada por la ”Central” solo cumpliendo con el tipo de dato manejado por el objeto, y una segunda parte integrando un tipo de traductor bidireccional entre los dos protocolos.
5.5.1 Parte uno 5.5.1.1 Corroboración código
Se comprobó algunos métodos de la librería PYSNMP necesarios para el de- sarrollo del proyecto, dado que el dispositivo que se está configurando es un AGENTE, es necesario que éste intérprete información vía TRAPS y que sea capaz de responder a los comandos propios del protocolo SNMP, como son GET, GET NEXT, BULK y WALK. Por lo que el código que nos proporciona pys- nmp.sourceforge.net para la tarea seria:
49
Figure 5.28: Código para un AGENTE
El cual está configurado para trabajar en LOCALHOST y haciendo uso del puerto 3022. Ahora con ayuda de MIB-BROWSER se realiza la solicitud de las operaciones básicas.
1. Respuesta a Get:
2. Respuesta a Get-next:
3. Respuesta a Walk:
4. Respuesta a Get-Bulk:
5.5.1.2 Prueba LOCALHOST
Al realizar la prueba con el árbol creado y valores sin concordancia, se probo a nivel de LOCALHOST, dando como resultado:
51
5.5.1.3 Prueba a nivel WLAN
Haciendo uso del código probado en primer lugar se realizó una prueba fuera del LOCALHOST, consiste en cargar el código en la raspberry y desde un ordenador conectado a la misma red y desde el programa MIB-BROWSER se hizo uso de las operaciones básicas, obteniendo los siguientes resultados.
Figure 5.34: Búsqueda de la IP del agente
52
Figure 5.35: Configuración del script python para generar la comunicación
Figure 5.36: Respuesta generada en MIB-BROWSER
5.5.2 Parte dos No fue posible concluir este aspecto por tiempo, por otro lado se propone un sistema en el cual se configure el traductor según las necesidades, es decir no generar un traductor configurado para cualquier caso, sino que sea configurable a las especificaciones solicitadas.
53
6. Desarrollo Fase III Para el desarrollo de la central semafórica la compañía decidió contratar una firma externa que se encargará de la tarea correspondiente, dando como resultado una alternativa al proyecto, ahora el protocolo NTCIP no iría desde el microcontro- lador(dispositivo) a la central sino desde una base de datos local ubicada en una RASPBERRY hacia una base de datos ubicada en los servidores de la central. La base de datos creada cumple con el protocolo interno de la empresa, el cual cuenta con varias tablas para la realización de la tarea, éstas son: configuración de los planes, de las semanas, de los días especiales, el reconocimiento de los cruces y demás items que consideraron pertinentes, de estas tablas se extraería los datos pertinentes con los objetos del protocolo NTCIP. Por dicha razón esta fase no se desarrolló dentro del presente documento, y aunque se hizo uso de la base de datos creada por la compañía externa, el código que de- vuelve los valores se muestra en el capítulo correspondiente a la implementación del protocolo.
Figure 6.1: Base de Datos con la que se trabajó, desarrollado por IDECO
54
7. Desarrollo Fase IV En esta fase se pretendía hacer la verificación de los módulos que integran un controlador tipo maestro, por lo que se tiene 3 módulos en este caso, uno de RF para la comunicación a través de internet, que en ultimas fue la adaptación de un módem usb conectada a una RASPBERRY, un modulo denominado LAN puesto que se trata de comunicar los controladores maestro y esclavos a la RAPBERRY a través de una red local con ayuda de la tecnología ZIGBEE, y uno de potencia puesto que el sistema es alimentado con paneles solares.
7.1 Módulo RF Para este módulo fue necesario conectar un modem usb a la RAPBERRY, por lo que fue necesario investigar un poco sobre estos dispositivos. El módem USB es un sistema que permite conectar un portátil o PC a Internet desde cualquier sitio, sin instalaciones y, en algunos casos. Sin embargo este tipo de conexión tiene sus pros y sus contras[20]. Ventajas A pesar de sus puntos negativos, el módem USB puede ser una gran solución si necesitas conectarte de forma temporal a Internet. Entre sus grandes ventajas están:
• Algunos operadores ofrecen tarifas para tener Internet móvil con un módem USB sin necesidad de contratar un plan de voz. Por lo que sólo se tendrá que pagar por el tiempo que se navegue.
• Entre las diferentes opciones que ofrecen los operadores, se encuentra al- gunas ofertas de módem USB sin compromiso de permanencia ni consumo mínimo.
• Su instalación es rápida y sencilla. Los módem USB son auto-instalables.
• Los módem USB multi-banda solucionan en gran parte el problema de la cobertura, ya que son capaces saltar de una red a otra buscando la mejor cobertura.
Para la conexión a la RASPBERRY se realizo el siguiente procedimiento ex- traído de diverteka[21]
1. Conectar el módem USB a la RASPBERRY
2. Confirmar que este conectado
3. Instalar en caso de que no este el programa Sakis 3G con el que es posible la configuración del módem.
4. Configurar el módem a través de Sakis
5. Se comprueba la conexión
55
7.2 Módulo Potencia Como todo es alimentado a través de energía solar, es necesario aclarar que en este montaje es necesario de 3 partes, una con respecto al panel solar, otro a la batería y otro al controlador de carga
7.2.1 Panel solar Para transformar la energía proveniente del sol en energía que se pueda aplicar a la vida diaria, se necesita una célula fotoeléctrica, la cual es un dispositivo electrónico que permite transformar la energía luminosa en energía eléctrica, me- diante el aprovechamiento de un proceso llamado efecto fotoeléctrico.
7.2.1.1 ¿Cómo funciona un panel solar?
El funcionamiento de los paneles solares se basan en el efecto fotovoltaico, que se produce cuando, sobre materiales semiconductores convenientemente tratados, incide la radiación solar produciendo electricidad tal y como ya he mencionado anteriormente.
En el momento en que queda expuesto a la radiación solar, los diferentes contenidos en la luz transmiten su energía a los electrones de los materiales semi- conductores que, entonces, pueden romper la barrera de potencial de la unión P-N, y salir así del semiconductor a través de un circuito exterior
Estas células fotovoltaicas se combinan de muy diversas formas para lograr tanto el voltaje como la potencia deseados y de este modo poder conseguir que la energía solar se acabe convirtiendo en energía que poder consumir.
7.2.1.2 Tipos de paneles solares
7.2.1.2.1 Paneles Solares Fotovoltaicos: Éstos son los que hemos expli- cado anteriormente y pueden generar suficiente energía para abastecer las necesi- dades de nuestros hogares. Estos paneles necesitan además del panel, inversores cargadores fotovoltaicos que se utilizan para pasar la corriente continua de 12V 24V o 48V que generan los paneles a una corriente alterna de 220V que es la que se usa para las viviendas.
7.2.1.2.2 Paneles Solares Térmicos: Estos paneles se recomienda usarlos en viviendas que tengan recepción directa del Sol con altas temperaturas y que tengan un espacio suficiente para colocarlos ya que son mayores que los anteriores porque si no, no serían eficientes. Actúan de la misma forma que los fotovoltaicos pero aparte contienen un liquido que absorbe el calor. Estos paneles convierten la energía del Sol en energía térmica en el líquido y transportan esta energía térmica hacia nuestros hogares.
7.2.1.2.3 Paneles Solares Termodinámicos: Éstos últimos son los que se están utilizando cada vez más en nuestros hogares debido a que son más eficientes, más baratos y se pueden utilizar aparte para muchas más cosas. Su principal ventaja es que pueden absorber energía a pesar de que llueva o esté nublado o sea de noche, etc. Estos paneles se basan en los principios fundamentales de
56
la termodinámica, es decir, que pueden absorber cualquier tipo de energía de cualquier ambiente siempre y cuando la temperatura exterior no baje de los 0 grados. Están fabricados de aluminio y contienen unos canales por donde circula un liquido refrigerante, es decir, un liquido de bajo punto de ebullición que es capaz de absorber grandes cantidades de calor al producirse en él un cambio de estado (gas, líquido o sólido).
7.2.1.3 Ventajas
• La principal ventaja de utilizar paneles solares es que producen energía limpia y renovable, sin tener que recurrir a los recursos fósiles y energía nuclear. Afortunadamente la era del petróleo está llegando a su fin. La energía solar no produce apenas contaminación y, sin embargo, el uso de recursos fósiles libera grandes cantidades de gases tóxicos hacia nuestra atmósfera.
• Los paneles solares también ayudan a ahorrar energía e instalar un sistema renovable en casa es bastante rápido, aparte que el mantenimiento de estos paneles solares es mínimo y su vida es bastante larga. Aunque al principio puedan resultar algo caros, en cuestión de años habremos recuperado la inversión inicial y estaremos recibiendo energía solar en nuestros hogares de forma gratuita, cosa que no pasa con los combustibles fósiles.
• Otra gran ventaja es la de por fin poder liberarnos del monopolio de las em- presas que nos suministran energía. Nosotros mismos podemos ser nuestros propios suministradores de energía gracias a los paneles solares.
7.2.1.4 Desventajas
• Los paneles solares proporcionan energía limpia, sin embargo, su fabricación aún depende de energías no limpias. (El silicio o arseniuro de galio tienen que extraerse de la Tierra y luego son transformados en diferentes procesos para poder colocarlos en el panel, aparte de otros materiales que componen el panel).
• Otra desventaja de los paneles solares, sobre todo los Fotovoltaicos es que dependen del clima. Si antes habíamos dicho que cuanta más luz reciban mejor, si vivimos en un clima escaso de Sol los paneles solares fotovoltaicos no nos serian muy útiles. Por eso es más habitual ver paneles solares en zonas de climas secos y cálidos que fríos y húmedos.
• El espacio es otra de las desventajas, ya que para que los paneles solares funcionen con eficiencia necesitan cubrir bastante espacio. Por ejemplo, para una casa pequeña, el espacio que necesitan los paneles solares sería desproporcionado en comparación con la propia casa y sus elementos.
7.2.2 Batería La imagen anterior muestra las diferentes tecnologías de baterías comparando sus capacidades en relación a su peso (eje vertical) y su volumen (eje horizontal).
57
Las baterías de ion de litio como las usadas en celulares y computadoras tienen características superiores.
7.2.3 Controlador de carga Los colectores de carga solares aprovechan y recogen cada partícula del calor, ya que la energía que el sol produce es incesable. La sobrecarga de energía en este tipo de sistemas es posible, en este caso se recurre a lo que los técnicos llaman regulador de carga. Este dispositivo eléctrico protege a las baterías y el sistema de solar fotovoltaico en general, manteniendo la tensión adecuada de la carga que se almacenan. El controlador de carga trabaja en función de varios factores, uno de ellos es su tamaño ya que al encontrar el tamaño ideal de este dispositivo eléctrico se debe tener en cuenta el número de paneles solares que el sistema utiliza además de las baterías.
7.2.3.1 Ciclo de trabajo
1. El regulador de carga solar hace posible la entrada de corriente de carga sin interrupción a las baterías que se encuentran vacías, el voltaje se eleva al máximo mientras la batería consume toda la energía posible.
2. En esta fase, la tensión de la carga que se mantiene a lo largo de una hora (aproximadamente) termina, es cuando el regulador interrumpe la carga gradualmente y la batería alcanza el 90 % de su capacidad.
3. Aquí se completa la carga final. Una vez que los acumuladores de energía ya están cargados y el panel solar sigue haciendo su trabajo, absorbiendo el calor solar, es cuando el regulador acciona el circuito de control automático para detener la carga a la batería.
4. Finalmente, la batería está descargada y se encuentra en su mínima capaci- dad, entrando al proceso de igualación que se refiere cuando la carga de los acumuladores de energía ha sido baja tras un determinado periodo de tiempo. Aquí se acciona de nuevo el circuito del regulador para permitir la entrada de energía e iniciar de nuevo el ciclo.
7.2.4 Cálculos necesarios Según la tarea a desarrollar es necesario dimensionar los componentes de la in- stalación solar.
1. Primer paso: Cálculo de consumos estimados, es decir la potencia requerida por la carga, aquí se especifica cuanto tiempo estará en uso, para describir la potencia hora que es necesaria, y es necesario aplicar la eficiencia típica de la instalación.
Totalenergianecesaria(Ten) = Totalconsumospordia
0, 75 [Wh/dia] (7.1)
2. Segundo paso: Radiación solar disponible, para obtener la radiación solar incidente, se pueden utilizar tablas con estimaciones ya existentes según la
58
ubicación. De forma que dimensionaremos la instalación para las condi- ciones mensuales más desfavorables de insolación, y así se asegura que se cubre la demanda durante todo el año. Una vez se conoce la radiación solar incidente, se divide entre la radiación solar incidente que se utiliza para calibrar los módulos. (1 kW/m2), y así se obtiene la cantidad de horas sol pico (HSP).
HSP = radiacionsolartablas
3. Tercer paso: Cálculo de placas o paneles solares necesarios
Numerodemodulos = (energianecesaria)
4. Cuarto paso: Capacidad de los acumuladores
Capacidaddelabateria = (energianecesaria ∗ diasdeautonomia)
(V oltaje ∗ profundidaddedescargadelabateria) (7.4)
La profundidad de descarga depende del tipo de batería elegido. Estos valores oscilan entre 0,5 a 0,8. Se puede consultar estos valores en las características técnicas para cada modelo y fabricante
Capacidaddeacumulacion = Totalenergianecesaria ∗ 3 24 ∗ profundidaddedescarga
(7.5)
Icontrol = Numerodepaneles ∗ corrientedelpanel (7.6)
7.3 Módulo LAN La configuración de los módulos xbee se realizó de la siguiente manera:
1. Lo primero que debemos de hacer es instalar los drivers del XBee Explorer USB, el cual nos permitirá configurar y operar el módem Xbee desde nue- stro PC. Simplemente debemos poner el modem ”XBee Serie 1” en el ”Xbee Explorer USB” y enchufar el puerto USB a nuestro computador, para las versiones de Windows Vista y anteriores, los drivers serán instalados de manera automática. Para Windows 7 debemos realizar el proceso de insta- lación de los drivers de manera manual desde el administrador de disposi- tivos.
2. Para realizar la configuración de los módulos, abrimos el software XCTU y seleccionamos la opción “Discover Radio”.
3. Debemos seleccionar el puerto COM que se le asignó al XBee Explorer USB (nos generó el puerto 70).
59
4. En el caso de un módulo que viene de fábrica los parámetros son los que aparecen en la imagen, luego presionamos el botón “Finish” y comenzará a buscar el dispositivo
5. El software comenzará a buscar el módulo.
6. Cuando encuentra el dispositivo, presionamos el botón “Add selected de- vices”.
7. Teniendo el dispositivo asignado, podemos revisar los parámetros de con- figuración presionando sobre el dispositivo.
8. En esta etapa podemos modificar los parámetros y guardar los cambios.
9. En las siguientes tablas, podemos encontrar la descripción de los campos y los valores que debemos asignar a cada uno de ellos para configurar los Xbee Serie 1 en “modo transparente” o en una conexión punto a punto.
10. Si deseamos conectar 3 nodos, podemos optar por una forma fácil donde todos se escuchen entre ellos, algo que es similar a una red tipo bus. Para ello, optaremos por hacer un broadcast desde cada uno de los Xbee Serie 1 configurándolos de la siguiente forma:
Table 7.1: Configuración 3 nodos
XBee A XBee B Xbee C (o cualquier otro) DH 0 DH 0 DH 0 DL FFFF DL FFFF DL FFFF MY 0 MY 0 MY 0 PAN ID 8888 PAN ID 8888 PAN ID 8888 SH (viene por defecto) SH (viene por defecto) SH (viene por defecto) SL (viene por defecto) SL (viene por defecto) SL (viene por defecto) CE 1 -Coordinator CE 0 -End Device CE 0 -End Device
60
8. Desarrollo Fase V Por el retraso no previsto en la fase dos a causa de la implementación del protocolo SNMP y luego en la adquisición de los datos a la base de datos no se pudo completar todo el protocolo en función de la necesidad de la empresa, a este punto se integro NTCIP de forma manual, es decir el valor del objeto era escrito al momento que se realizaba la solicitud, por estos inconvenientes el proyecto quedo hasta la validación vía MIB Browser.
8.1 Script desarrollado Para empezar con el script que se está desarrollando es necesario importar las librerías y/o los componentes necesarios para cada una de las tareas propuestas
Figure 8.1: Librerías python de PYSNMP
Luego y puesto que se va a manejar una base de datos para tomar los datos de allí se realiza la configuración respectiva, en el caso de MYSQL es necesario los siguientes parámetros (usuario, contraseña, servidor y nombre de la base de datos)
Figure 8.2: Configuración para base de datos
De igual forma se había propuesto que el sistema del árbol de objetos se desarrollaría en un archivo plano, el cual contiene por un lado el OID, el nombre del objeto, el tipo de dato que maneja, una pequeña descripción y el acceso que contiene. Así que dentro del script se importa cada columna para realizar una tabulación del mismo, en donde cada vector es del mismo índole, por ejemplo la primera columna son los identificadores de objeto (OID) y se ubican en un mismo vector.
61
Figure 8.3: Carga del árbol a la ejecución
Ahora en la siguiente imagen se evidencia como es la configuración para el envió de los datos a través del protocolo UDP, haciendo uso de una IP y un puerto, para este caso son la IP propia y el puerto con el que se trabajará. Aquí se encuentra una IP que está en uso para la realización de las pruebas, sin embargo se encuentra la forma el dispositivo actualizará la IP, puesto que esta es de tipo publico la cual no es estática.
Figure 8.4: Configuración del protocolo UDP
Dentro del protocolo SNMP se tiene que configurar, parámetros tales como versión, tipo de usuario, tipo de protección, y se importan los símbolos a utilizar (hágase referencia a como se invoca los parámetros del árbol)
62
Figure 8.5: Demás parámetros SNMP
Se implementó una función para que esta generara la petición a la base de datos
Figure 8.6: Método para gestión de la base de datos
Proceso continuo fue generar la trama para el envío de los datos a través del siguiente código.
Figure 8.7: Sistema que envía información
8.2 Pruebas Aquí se puede ver que la operación WALK funciona con el OID que se está trabajando, se ve dado que el valor enviado es proporcionado por una petición
63
a la base de datos, en el caso el valor que se envía es el mismo para todos y no corresponde a los objetos que se están manejando.
Figure 8.8: Respuesta en MIB-BROWSER con árbol completo
64
9. Conclusiones • La gestión de los sistemas de tráfico deben tener una orientación fundamen-
tal al usuario, capaz de adaptarse fácilmente a los cambios rutinarios y a los cambios imprevistos, así poder ayudar a vehículos de emergencia en su labor, de igual forma esto va encaminado con una proceso tecno-político, es decir el estado es quien fundamenta este tipo de desarrollo.
• La solución debe ser acorde con las necesidades actuales, pero su arquitec- tura debe ser modular, para ampliarse de acuerdo a requerimientos futuros. En la modularidad, el fallo en uno de los componentes del sistema no im- plica que colapse toda la estructura.
• La problemática de movilidad y de contaminación por polución necesitan de nuevas soluciones, que hagan del transporte un sistema sostenible. La aplicación de nuevas tecnologías de la información a los transportes ayudan notablemente con este objetivo,además de no excluir la implementación de otras medidas complementarias.
• Mientras el protocolo NTCIP es un protocolo abierto y toda empresa que este asociada al área de transporte puede hacer uso del mismo y aportar para mejorarlo, el protocolo OCIT es de tipo cerrado puesto que en uno de los niveles de gestión un protocolo es propietario.
• NTCIP es un protocolo abierto que ofrece grandes beneficios para las ciu- dades colombianas, su estructura es capaz de adaptarse a las necesidades de las mismas de forma adecuada. Al ser un estándar abierto no hay depen- dencia de proveedores y contribuye con la interoperabilidad de los sistemas ITS que se implementen.
• El protocolo NTCIP consiste según el dispositivo a desarrollar tan solo en el solapamiento de otros protocolos, para el caso especifico de los semáforos, es hacer uso del protocolo SNMP que va sobre el protocolo UDP/IP, lo que hace especial a este sistema y lo diferencia de cualquier otro aparato es el árbol de objetos, éste tiene un OID que es un identificador propio, un nombre, un tipo de dato y rango sobre el mismo, un estado y permisos de escritura.
• No existe comisión u organismo que avale o certifique si un dispositivo funciona bajo el protocolo NTCIP, sin embargo existen varios métodos que sirven para testear la funcionalidad del dispositivo depositados dentro de los documentos que provee la organización del NTCIP.
• El protocolo SNMP presento varios problemas cuando se quiso trabajar las operaciones propias del protocolo, aunque se corroboro la forma en que se estaba generando la trama, fue necesario realizar otro tipo de pruebas menos ortodoxas para corroborar las tramas utilizadas, por una parte se uso de dos software(MIB Browser y Hercules) para simular la conexión entre dispositivo y agente, y a través de WIRESHARK capturar los datos enviados.
65
• La existencia de librerías para Python que realizan la tarea del protocolo SNMP fue fundamental para continuar con la implementación del proyecto, sin embargo la librería en uso tenia una licencia, la cual consistía en dar los créditos a los creadores, en pocas palabras en el código colocar la informa- ción pertinente.
• El protocolo NTCIP desarrolla un estándar por cada uno de los disposi- tivos en los que ha trabajado, así que cada documento desarrolla el MIB correspondiente al controlador en cuestión.
• Cuando se desarrolló un sistema capaz de enviar y recibir información sobre el protocolo UDP y éste no tuviese una IP pública fue necesario, en el servidor capturar la dirección de envió y a través de la misma responder, es decir crear un sistema orientado a la conexión sobre UDP.
• La compañía maneja un protocolo propio y este tiene una filosofía que caracteriza un cruce semafórico a través de pasos, mientras que el protocolo NTCIP tiene un sistema por fases, cuando se iba a realizar un traductor bidireccional entre los dos sistemas se encontró impedimentos en cuanto al direccionamiento de los datos en la base de datos.
66
Bibliografia [1] Delgado Castaño, Juan Guillermo. Presente y futuro: ¿Cómo está el
parque automotor en Colombia?. Extraído 28 de Julio de 2017. http:// revistadelogistica.com
[2] Sayeg Phil, Charles Phil. Traducción Pardo Carlos. Sistemas de transporte inteligente. Bogotá junio 2006, extraído 28 de Julio de 2017. http://www. sutp.org
[3] Secretaria de movilidad de Medellín, capitulo 7, semáforos. Extraído 28 de Julio de 2017.. https://www.medellin.gov.co
[4] Vargas Wilson, Mozo Edison, Herrera Edwin, Análisis de los puntos más críticos de accidentes de tránsito de Bogotá. Extraído 28 de Julio de 2017. http://revistas.udistrital.edu.co
[5] Plan Maestro de Movilidad para Bogotá Distrito Capital. Extraído 28 de Julio de 2017. http://www.movilidadbogota.gov.co
[6] CEPAL Nuevas tecnologías de información y telecomunicaciones en el sector transporte. Edición nº 177. Mayo 2001.
[7] Secretaria de Infraestructura Orden circular 32/2012. Extraído 28 de Octubre de 2016. http://www.carreteros.org
[8] Ministerio de Transporte Manual de señalización vial, 2015. Extraído 28 de Julio de 2017.. http:/www.mintransporte.gov.co/documentos.php? id=29
[9] Unidad Operativa de Control de Tránsito, modalidades de fun- cionamiento de los semáforos. Extraído 28 de Julio de 2017. http://www. uoct.cl
[10] NTCIP guide v04. Julio 2009, recuperado 28 de Julio de 2017. www.ntcip. org
[11] SCATS, recuperado 28 de Julio de 2017. http://www.tyco-its.com
[12] OCIT-C center to center transport protoco v1.1l. recuperado 28 de Julio de 2017. www.ocit.org
[13] Glen Marla, Moreno Julian ZIGBEE. 23 mayo 2012, recuperado 28 de Julio de 2017. https://sx-de-tx.wikispaces.com/ZIGBEE
[14] Master Magazine . Recuperado 28 de Julio de 2017. http://www. mastermagazine.info/termino/5172.php
[15] Comisión Electrotécnica Alemana Norma DIN y la Asociación Elec- trotécnica Alemana (Verband Deutscher Elektrotechniker - VDE). 0832 para sistemas de señalización del tráfico. . Marzo de 1990.
[16] Emma Holgado Estudio de regulación del tránsito de vehículos y peatones en los alrededores de la Avenida Portugal de Salamanca. Septiembre 2012
[17] NTCIP guide v1.1. Julio 2009, recuperado 28 de Julio de 2017. www.ntcip. org
[18] OCIT-C center to center transport protocol v2.0. Recuperado 28 de Julio de 2017. www.ocit.org
[19] TransCore SCATS. Recuperado 28 de Julio de 2017. www.transcore.com
[20] ¿Qué es el módem USB? Pros, contras y ofertas. Recuperado 28 de Julio de 2017. https://www.comparaiso.es
[21] 3G en Raspberry . Recuperado 28 de Julio de 2017. http://www.diverteka. com
[22] Protocolo SNMP . Julio 2017, recuperado 28 de Julio de 2017. http://es. ccm.net
Protocolo ZIGBEE
Protección de datos