Transcript of Sergio Iván Agudelo Santana Protocolo de comunicación para ...
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