CTC Centralized Traffic Control

Red de semáforos inteligentes para el control activo de trafico

Especificación detallada del proyecto final Sistemas embebidos para tiempo real

Autores

Diego Mazzuco

Ignacio Brugnoli

Thomas Rokicki

Tutores Julián Oreggioni

Santiago Radi

25/04/2018

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Resumen Este proyecto se encuentra inspirado en la problemática causada por el aumento del tráfico vehicular en ciudades cuyo sistema de control de tráfico se encuentra descentralizado, generando demoras en la implementacion de politicas de ingenieria de trafico.

Con esto en mente, este proyecto pretende introducir una transición sencilla y de bajo costo entre un sistema desactualizado (que no permite configuraciones remotas) y un sistema completamente automatizado y por tanto complejo y costoso.

Para ello, se diseño un sistema que permite controlar semaforos segun distintas configuraciones enviadas de forma remota a través de LoRa, un protocolo de comunicacion inalambrica de largo alcance y libre de gastos operativos.

Las configuraciones permiten configurar los diferentes tiempos asociados a los estados de los semaforos, asi como la configuracion de modos de funcionamiento normales y de ceda el paso.

La red implementada se encuentra constituida por un Gateway conectado a una PC a traves de un puerto UART, haciendo de traductor entre la PC y el canal de comunicacion inalambrico sobre el protocolo LoRa y un conjunto de nodos de la red (controladores de semaforos) que se comunican con el gateway a traves de este canal.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Tabla de Contenido 1- Glosario

2- Introducción

3- Descripción del problema

3- Alcance

3- objetivo

4- Arquitectura de la red

5- Diseño del sistema

10- Pruebas

11-Conclusiones

12- Referencias

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Glosario

LoRa : Es un protocolo de comunicación Wireless, banda libre, de bajo consumo y larga distancia.

RADIO : Circuito integrado SX1278 que implementa la capa física de la comunicación LoRa.

GATEWAY: Centralizador a donde todos los nodos se comunicarán.

NODO: Circuito integrado por una Radio, un micro AT328P y un controlador de luces.

CONFIGURACIÓN: Se refiere al conjunto de datos del modo operación del semáforo y los tiempos de cada luz del semáforo. Donde existen 5 modos:

Modo 0: El estándar donde se definen los tiempos de la luz verde, amarilla y roja de cada semáforo.

Modo 1 y 2: Que son modos de ceda el paso donde uno de los semáforos parpadea la luz amarrilla y el otro la roja.

Modo 3: Es similar al modo 0, con la diferencia que los tiempos ya están definidos en la EEPROM del Nodo, este modo se utiliza en la inicialización del nodo y se mantiene hasta que el nodo obtenga la hora actual del Gateway.

Modo 4: Equivalente modo 0 pero pensado para testeo por ello se aceptan tiempos de luz que en modo 0 no se aceptan.

CALLBACKFUNCTION: En este proyecto se llaman callbackfuntion a todas las funciones que son ejecutados por interrupciones, ya sean del módulo de la interrupción o no.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Introducción El continuo aumento de la población en ciudades trae consigo un aumento en la cantidad de vehículos que circulan. En los últimos años, la cantidad de vehículos que se encuentran en circulación ha aumentado significativamente (Ilustración 1).

Como se puede ver en [2], este problema termina afectando de forma significativa las velocidades y tiempos de circulación: lugares donde se permitía circular a velocidades de 60 o 75 km/h, en la realidad se circula a 25 o 30 km/h.

Este enlentecimiento del tráfico termina provocando una acumulación de vehículos en ciertas horas del día (llamadas “horas pico”).

Este continuo aumento en la cantidad de vehículos circulando impone la necesidad de tener formas eficientes de controlar este tráfico. A lo largo de los años, han aparecido distintas estrategias para solucionar este problema, siendo la más conocida de todos los semáforos. Sin embargo, con el paso del tiempo, el uso de grandes cantidades de estos dispositivos implicó un reto para realizar las configuraciones de forma manual.

En este contexto, sistemas como el presentado en esta propuesta se hacen cada vez más imprescindibles.

El objetivo de este proyecto es la implementación de una herramienta que permita ejecutar estrategias de control de tráfico en tiempo real y de forma remota, facilitando la puesta en marcha de las políticas de ruteo de tráfico.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

1- Descripción El principal problema que fue abordado en este proyecto es la posibilidad de reconfigurar los tiempos asociados a cada estado de los semáforos de una esquina, de forma remota y centralizada, simplificando la puesta en marcha de políticas de ruteo de vehículos.

2- Objetivo El objetivo del proyecto es diseñar e implementar un sistema que sea capaz de generar comandos de control de tráfico de forma centralizada y distribuirlas en toda la red de semáforos de forma automática. Agregado a esto, el sistema permitirá realizar distintas políticas de control según el momento del día en el que se encuentre y, por tanto, se podrán considerar distintas políticas en las horas pico que en las horas de tráfico en régimen.

3- Alcance El sistema está pensado para esquinas con 4 semáforos y 3 tipos de luces. En cada nodo se pueden guardar varias configuraciones diarias y una configuración por defecto. Se cuenta además con cotas para los tiempos de configuración como una forma básica de evitar algunas de ellas que puedan ser peligrosas para el tráfico. Esta implementación también cuenta con una capa de abstracción para facilitar la creación y uso de los módulos de software.

La arquitectura del software es una cola de funciones, donde existe la posibilidad de darles prioridad a las funciones que al principio se pensó en usar, pero que no se usó en la última versión.

El proyecto incluye la construcción de una red en estrella de dos nodos y un gateway, basados en el microcontrolador ATmega328P y el módulo LoRa SX1278. Donde la comunicación con el módulo LoRa y el micro se realiza a través de SPI.

La sincronización y configuración de tiempos de los nodos se realiza escribiendo comandos en una PC a través de un sencillo programa de python el cual usa la UART para comunicarse con el Gateway.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

4- Descripción del sistema El sistema está conformado por una red en estrella. Desde una PC se manda las configuraciones al Gateway, el cual las retransmite al nodo pertinente, luego este nodo configura los tiempos de cada luz del semáforo según la información recibida.

Ilustración 2 - Arquitectura de la red

Cada nodo controla una esquina con cuatro semáforos, la cuenta de un reloj y almacena la configuración diaria y por defecto en memoria EEPROM.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

5- Diseño del sistema 5.1- Plataforma de Hardware A continuación, se presenta el diagrama de bloques de conexión del hardware de los nodos. En cuanto a la alimentación, se considera que el consumo de los propios semáforos resulta mucho mayor que el del sistema, por lo que no tiene sentido implementar funcionalidades de bajo consumo.

El módulo LoRa y el micro ATmega328P se conectan entre sí con el puerto SPI y 3 puertos de entrada y salida.

Ilustración 3 - Hardware del sistema

Los controles de dirección 1 y 2 son dos multiplexores conectados a los pines del Atmega328p., que a su vez se conecta a las luces del semáforo.

Hay que destacar que la única diferencia importante entre el hardware del nodo y Gateway es que este último no cuenta con los controles de dirección y los semáforos.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

5.2- Arquitectura de Software La arquitectura del software es una cola de funciones. Como se ve en la Ilustración 4 el sistema está separado en capas: Hardware, capa Abstracción de Hardware, Software y Lógica principal

Ilustración 4 - Diagrama de capas del sistema

En verde está lo implementado por nosotros mientras que en rojo lo implementado por terceros.

Las responsabilidades de cada una de las capas son:

Hardware: Ya se describió anteriormente es la capa física que aporta el módulo comunicación LoRa Sx1278 y el microprocesador atmega328P

Capa de abstracción de Hardware: Se encarga de dar herramientas para controlar los registros pines, interrupciones, la comunicación UART, SPI, controlar el reloj, además implementa funciones de buffer circular y para control de colas de funciones.

Capa de software: Se encarga de dar herramientas para comunicarse LoRa, además del control de la configuraciones y despliegue de las mismas en los semáforos

Lógica principal: Esta capa se encarga de la inicialización del dispositivo, y procesamiento a la hora de recibir un mensaje.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Capa de abstracción La siguiente ilustración muestra los módulos de la capa abstracción

Ilustración 5 - Capa de abstracción

A continuación se hablara de cada uno de los módulos de esta capa:

UART

Este módulo fue creado para que la computadora pueda transmitirle información al Gateway y así poder configurar la red. Este módulo es parecido al creado en el laboratorio. Las principales diferencias entre ellos radican en que los registros cambian por ser otro microprocesador, el baud rate es configurable externamente y se agregaron funciones para poder transmitir y recibir strings.

SPI

La librería para el manejo de la radio sx1278 utilizaba un puerto SPI definido por software. Se modificó esta librería para utilizar el puerto SPI hardware del microcontrolador. Sin embargo, es importante resaltar que el manejo del puerto se realizó utilizando una lógica de Polling.

La razón de esto es que, las funciones de manejo de SPI deben ejecutarse dentro de una función de atención a interrupción (La interrupción generada al recibir un mensaje por LoRa) y por tanto no existe posibilidad de “paralelizar” tareas.

Reloj

El módulo fue creado para llevar el tiempo actual en el nodo y el gateway y así conocer la configuración actual del semáforo. Al igual que la Uart se tomó como base lo realizado en el laboratorio. Las funcionalidades agregadas fueron:

● Una función de delay. ● La posibilidad de guardar una función externa al módulo y ejecutarla cada vez que

cambie la hora, el minuto o el segundo. ● Setear una función la cual se llama por un timer con interrupciones de tiempo

configurables entre 1 ms a 8 seg. Esta funcionalidad se usa en el control de luces cada 500 ms para verificar si el estado actual de las luces es correcto.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

● Agregar una variable epoch que lleva el registro del tiempo pero en milisegundos.

Esta librería es muy usada por los otros módulos ya que define la estructura para llevar el tiempo actual, por ello es principalmente usada por el control de luces y la agenda.

Function queues El objetivo de este módulo es brindar funciones para el control de la arquitectura del software. Las funciones permiten crear una de cola de funciones con prioridad, que cuenta con 5 prioridades; 0 la más alta y 4 la más baja. “Function queues” permite verificar si la cola de funciones está llena o vacía, guardar funciones y extraerlas.

Buffer circular

Muchas de las aplicaciones usan buffers circulares para guardar datos temporales. Por ello se decidió centralizar las funciones para crear buffers circulares de tipo de dato y tamaño configurables. Se implementan funciones para crear un buffer circular; para guardar, extraer, eliminar, copiar, datos del buffer y comprobar si está vacío o lleno.

En caso de que el buffer circular este lleno, si guarda un dato, el más antiguo se elimina, por ello es necesario usar la funcion isFullCircularFIFOBuffer para verificar si el buffer esta lleno.

Para guardar un dato tipo genérico lo que se hace es guardar un array de unsigned char porque cualquier tipo de dato que usamos es divisible por este y de esta forma guardar en la estructura del buffer circular el tamaño del dato. Con eso el módulo se encarga de recorrer el buffer sin causar errores.

Ports

Ports implementa funciones para configurar y setear los pines digitales del atmega328p , de forma de poder setear si el pin se usará de entrada o salida, también poder leer el pin o setear un voltaje en el mismo, y además implementa un modo en caso que se usen pull UP.

Este módulo es básico para el sistema ya que permite a muchos otros módulos comunicarse con el exterior. Por ejemplo, SPI, UART, Comunicación, Control de luces, entre otros.

External Interrupts

External Interrupts contiene funciones para poder recibir las interrupciones externas generadas por la radio sx1278. Las interrupciones externas están implementadas en los pines 2 y 3 y cada una de ellas permite asociar funciones que se llamara en caso de una interrupción. También

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

permite configurar qué tipo de cambio lógico en el voltaje se considera como una interrupción: por bajo nivel, por cualquier cambio lógico o por caídas o subidas de voltaje.

EEPROM

Debido que uno de los objetivos de este proyecto es guardar una configuración por defecto en memoria no volátil y que sea modificable por el gateway, tomamos la decisión de usar la eeprom interna del microprocesador.

Este módulo cuenta con funciones para guardar o leer 1 o 2 bytes en la memoria. Para ello usa un buffer circular e interrupciones a la hora de guardar un dato.

Este módulo es únicamente usado por Agenda para guardar las configuraciones, los otros módulos proceden a consultar Agenda en caso de necesitar algo de la EEPROM.

Avr io, avr common y avr interrupt

Son librerías realizadas por terceros lo cual definen ciertos registros, pines, vectores de interrupción del micro atmega328p.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Capa de software

Capa de software

Ilustración 6 - Capa de software

Módulo de control de Luces

Este módulo tiene como objetivo es controlar la transición de estados de los semáforos que pertenecen a cada nodo. Esto se obtendrá al recibir del main la configuración actual. Haciendo uso de un segundo timer del microcontrolador proveniente del módulo reloj, que genera interrupciones cada 500 ms con el objetivo de verificar el estado actual del semáforo. Si bien, se podría utilizar el tiempo proporcionado por el módulo reloj, el tener una rutina de atención a interrupciones propia con una frecuencia mucho menor exige menos al sistema. También verifica que las configuraciones se encuentre entre ciertos márgenes definidos en systemTypeDefinition para evitar ciertos errores de configuración. Por último el sistema hace uso de los puertos digitales para encender la luz del semáforo correspondiente en su tiempo.

Módulo de agenda

Este módulo se encarga de guardar y devolver las configuraciones diarias las cuales se solicitan cuando se inicia el nodo, se setea una configuración desde el gateway o se revisa si la configuración actual cambio, esto último sucede cada un minuto.

También cuenta con una configuración por defecto que es modificable por el gateway la cual se usa cuando no se tiene conocimiento de la hora actual, ya que si el gateway no tiene un reloj externo para llevar la hora.

Las configuraciones diarias y la por defecto se guardan en la EEPROM ya que deben ser modificables pero no perderse debido que el nodo se apague. Por ello Agenda guarda organiza las direcciones de la eeprom para guardarlas.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Para fijar la última idea la siguiente tabla es un ejemplo donde se guarda una configuración por defecto y dos configuraciones una normal y la siguiente un ceda el paso, se indica las direcciones de la eeprom como el contenido de las mismas

Dirección en la EEPROM

Contenido Comentarios

0 Un byte con la cantidad de configuraciones guardadas

1 al 13 Tiempos de las luces de la configuración por defecto

El modo por defecto cuenta con 6 tiempos que ocupan 2 bytes cada uno

15 El modo de la configuración 0

16 al 27 Tiempos de las luces de la configuración 0

El modo 0 cuenta con 6 tiempos que ocupan 2 bytes cada uno

28 El modo de la configuración 1

29 al 32 Tiempos de las luces de la configuración 1

El modo 1 cuenta con 2 tiempos que ocupan 2 bytes cada uno

Tabla 1 - Ejemplo de memoria EEPROM

Módulo de comunicación

Este módulo se encarga de configurar y controlar la radio SX1278 para enviar y recibir cadenas de bytes usando el protocolo LoRa a través de una arquitectura de interrupciones.

Es decir, la radio se configurará para que, en cuanto reciba un paquete completo en su buffer de recepción interno, se genere una interrupción que modifique el estado de uno de sus puertos I/O conectado a su vez a uno de los puertos I/O del microcontrolador. Este puerto del microcontrolador se encuentra configurado para generar una interrupcion en el mismo cuando el estado del puerto se modifique. Esta interrupción es generada una vez que se finaliza de enviar o de recibir un paquete a través de la radio.

En el caso de que la interrupcion se genere cuando se reciba un mensaje, el micro hace uso del puerto SPI para leer el mensaje en la memoria de la radio sx1278, se fija si el mismo es para su direccion en la red y en caso de serlo lo almacena en el buffer de recepcion.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Lógica principal La Lógica principal realiza la inicialización del dispositivo, la comunicación a alto nivel de la computadora al gateway y luego a los nodos y el procesamiento de los comandos. Los comandos del sistema son:

● GT(Get Time): Se le pide al nodo que mande la hora que tiene guardada. ● ST(Set Time): Setea el tiempo de un nodo ● GC(Get Conf): Se le pide al nodo la configuración diaria guardada. ● SC(Set Conf): Resetea la configuración diaria de un nodo

Para simplificar de los comandos se realizó un programa en python que se comunica con el gateway por la UART y va pidiendo los datos correspondientes para poder realizar el comando

‘

Ilustración 7 - Logica principal

Se decidió separar la Lógica principal en 4 módulos por un tema de orden. Ahora detallaremos cada uno de estos:

Type Definitions

Centraliza ciertas definiciones así como typedef que se usan la Lógica principal y en capa de software, entre ellas se encuentran las estructura de una configuración y de una configuración diaria, como los tiempos máximos y mínimos para que puede estar encendida las luces de los semáforos según su modo.

Callbackfuction

Guarda las callbackfunction que le competen a la lógica principal, las cuales son: el procesado de un mensaje cuando se recibe por LoRa o la UART, avisar que un mensaje fue transmitido con éxito usando Lora y revisar si los tiempos del semáforo corresponde con esa hora del lo cual se realiza cada minuto.

Mainfunction

Cuenta con funcionalidades de alto nivel como son funciones de procesar mensajes de la UART o LoRa, función para sendIamLive, comprobar si la clave del mensaje es correcta.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Main

Se encarga de inicializar el nodo o Gateway correspondiente lo cual quedará claro con el siguiente diagrama flujo y luego de terminar con la inicialización revisa si hay funciones en la cola de funciones para ejecutar.

Diagrama de flujo de la inicialización del nodo

Ilustración 8 - Diagrama de Flujo inicialización del nodo

El nodo a prenderse inicializa el Hardware, el buffer, la configuración por defecto la setea en las luces del semáforo, luego intenta conectarse con el gateway cuando recibe el mensaje del gateway verifica si la configuración actual es correcta y la cambia de ser necesario luego entra en loop principal donde espera recibir algún comando.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Diagrama de flujo de la inicialización del nodo

Ilustración 9 - Diagrama de Flujo procesamiento de un comando

Acá se puede el procesamiento de un comando del sistema .El cual consiste en la identificación del mismo, en caso de setear se guarda los datos pedidos y en caso de ser un Get se leerán los datos guardados, luego todos los comandos devuelven un mensaje por el mismo canal que lo recibieron ya sea eeprom o UART.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Diagrama de flujo de las interrupciones

Ilustración 10 - Diagrama de Flujo procesamiento de un mensaje de la UART

Diagrama de flujo de la UART el cual a grandes rasgos coincide en la forma que se realizo en el laboratorio

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Ilustración 11 - Diagrama de Flujo de la interrupción de la EEPROM para guar un dato

Solo se describe el funcionamiento al guardar ya que la lectura se realiza con polling.

En la EEProm es necesario deshabilitar todas las interrupciones ya que los registros deben cumplir ciertos tiempos de ciclo o puede dar error, y es una práctica aconsejada por el manual del micro.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

6- Pruebas a realizadas Se logró realizar una comunicación LoRa correctamente a una distancia de 120 metros dentro de la facultad y a 600 metros entorno urbano en estas condiciones el tiempo para recibir un mensaje fue en promedio de 3 segundos.

Para probar el retraso de las configuración del semáforo, se grabó por 3 minutos los LEDS del nodo y usando una computadora se midieron los tiempos de retraso el mayor de ellos fue de 700 ms.

Por último todas las funciones de todos los módulos fueron probadas tanto por separado como en conjunto, pero no se pudo realizar las pruebas de borde deseadas para este sistema.

Conclusiones • Se pudo realizar el proyecto con los objetivos prometido, incluso desarrollar algunas

herramientas que al principio no estaban previstas.

• Los tiempos de retraso son del orden de décimas de segundo

• La comunicación LoRa tiene un rango de 800 metros.

• Se logró un sistema escalable

• Creemos que hemos aprendido mucho en este proyecto, ya que han utilizado la varias de las herramientas del curso además de otras.

• Que un proyecto de esta magnitud es un tarea multidisciplinaria

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Referencias

[1] “ Daniel Martínez: “Hay casi tres veces más vehículos de lo que había hace 10 o 12

años”” [online]. Uruguay: Uycheck, 2015 Disponible en: http://uycheck.com/daniel-martinez-hay-casi-tres-veces-mas-vehiculos-de-lo-que-habia-hace-10-o-12-anos/

[2] “ En horas pico, en avenida Italia autos circulan a 25 km/h” [online]. Uruguay: El Observador, 2016. Disponible en: https://www.elobservador.com.uy/en-horas-pico-avenida-italia-autos-circulan-25-kmh-n974936

[3] “ Casi 3.000 automóviles transitan por la rambla en una hora "pico"” [online]. Uruguay: El País, 2016. Disponible en: https://www.elpais.com.uy/informacion/automoviles-transitan-rambla-hora-pico.html

[4] Ruhaizan F., Fadhlan H., Shamry M “Smart traffic light for congestion monitoring using

LoRaWAN” [online]. Malasia: El Observador, 2017 Disponible en: https://ieeexplore.ieee.org/document/8070582/

[5] João Pedro Piteira da Cunha, “Wireless Communication System for Traffic Management

and Control” [online], Tesis, Instituto Superior Técnico, Universidad de Lisboa, Lisboa, 2016. Disponible en: https://fenix.tecnico.ulisboa.pt/downloadFile/1407770020545402/resumo.pdf

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Anexo

Conceptos aplicados en el curso En este proyecto se usó un encolado de funciones porque uno de los objetivos del mismo era realizar un sistema escalable y ordenado. Se aplicaron los conceptos de modularización la cuales fueron muy útiles para realizar un sistema de varias capas.

También se realizo el uso de los registros de un sistema para poder modificar los módulos UART y Reloj del laboratorio del curso. Se usaron interrupciones y se tuvo en cuenta el tema de los datos compartidos ya que las configuraciones y tiempos del reloj se usan en varios módulos.

Otros detalles son que se realizó una interrupción basada en un timer con tiempo configurable, controles de pines para poder: realizar la comunicación SPI, el control de los LEDS, y la comunicación con el módulo SX1278

Planificación del proyecto Uno de los mayores contratiempos del proyecto fue la realización del hardware mismo ya que consumió más tiempo del esperado, también que agregar el hecho de realizar la capa abstracción con algunas funcionalidades que luego no se implementaron. Todo aquello produjo que el tiempo dedicado por semana estuviera entorno a las 14 horas y no las 8 como estaba previsto. Pese a todos estos contratiempos logramos realizar un proyecto que cumplia con casi todos los alcances prometidos menos la sincronización automática de los relojes del Gateway y los nodos y la realización de pruebas rigurosas para el sistema.

Especificación de proyecto

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

CTC Centralized Traffic Control

Red de semáforos inteligentes para el control activo de trafico

Especificación detallada del proyecto final Sistemas embebidos para tiempo real

Autores

Diego Mazzuco

Ignacio Brugnoli

Thomas Rokicki

Tutores

Julián Oreggioni

Santiago Radi

25/04/2018

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Ilustración 1- Cantidad de autos circulando en la ciudad de Montevideo a lo largo de los años [1]

Introducción El continuo aumento de la población en ciudades trae consigo un aumento en la cantidad de vehículos

que circulan. En los últimos años, la cantidad de vehículos que se encuentran en circulación ha

aumentado significativamente (Ilustración 1).

Como se puede ver en [2], este problema termina afectando de forma significativa las velocidades y

tiempos de circulación: lugares donde se permitía circular a velocidades de 60 o 75 km/h, en la realidad

se circula a 25 o 30 km/h.

Este enlentecimiento del tráfico termina provocando una acumulación de vehículos en ciertas horas del

día (llamadas “horas pico”).

Este continuo aumento en la cantidad de vehículos circulando impone la necesidad de tener formas

eficientes de controlar este tráfico. A lo largo de los años, han aparecido distintas estrategias para

solucionar este problema, siendo la más conocida de todos los semáforos. Sin embargo, con el paso del

tiempo, el uso de grandes cantidades de estos dispositivos implicó un reto para realizar las

configuraciones de forma manual.

En este contexto, sistemas como el presentado en esta propuesta se hacen cada vez más

imprescindibles.

El objetivo de este proyecto es la implementación de una herramienta que permita ejecutar estrategias

de control de tráfico en tiempo real y de forma remota, facilitando la puesta en marcha de las políticas

de ruteo de tráfico.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

1- Descripción El principal problema que será abordado en este proyecto es la posibilidad de reconfigurar los tiempos

asociados a cada estado de los semáforos de una esquina, de forma remota y centralizada, simplificando

la puesta en marcha de políticas de ruteo de vehículos.

2- Antecedentes Ya se han realizado numerosas investigaciones sobre el alcance y rendimiento del protocolo Lora en la

ciudad, y algunos de ellos son con respecto al control de tráfico. Entre ellos, queremos destacar el

siguiente:

2.1- Smart traffic light for congestion monitoring using LoRaWAN [4]

Autores: Ruhaizan F. A., Fadhlan H. K. Shamry M

En este artículo los autores estudian la posibilidad de usar el protocolo LoRa para realizar un sistema de

control de tráfico, que consiste en medir la cantidad de vehículos en un cruce y con esto estimar cuáles

son las vías más ocupadas y al utilizar un control de los semáforos poder mejorar el tráfico en la ciudad.

Además, se comparan los resultados con otros sistemas parecidos los cuales tienen una menor cantidad

de sensores.

El artículo es interesante ya que propone una forma de medir el tráfico en una ciudad y poder reaccionar

al respecto. Se remarca que el objetivo de este proyecto no es la realización de un control en loop cerrado

haciendo uso de sensores, sino que el control queda a cargo del usuario del sistema.

2.2 - Wireless Communication System for Traffic Management and Control[5] Autor: João Pedro Piteira da Cunha

Este articulo presenta un sistema de control de semáforos a través de dos protocolos de comunicación

distintos: ZigBee para comunicación a corta distancia y LoRa para la comunicación a larga distancia.

El sistema de control puede ser con sensores o solamente con un protocolo predefinido. Además, el

articulo presenta las ventajas y desventajas de algunos protocolos de comunicación sin cable y presenta

tests de algunos casos.

Este articulo resulta similar al nuestro en que utiliza el mismo protocolo de comunicación para controlar

los semáforos. Sin embargo, la arquitectura propuesta difiere.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

3- Objetivo El objetivo del proyecto es diseñar e implementar un sistema que sea capaz de generar órdenes de

control de tráfico de forma centralizada y distribuirlas en toda la red de semáforos de forma automática.

Agregado a esto, el sistema permitirá realizar distintas políticas de control según el momento del día en

el que se encuentre y, por tanto, se podrán considerar distintas políticas en las horas pico que en las

horas de tráfico en régimen.

4- Alcance Se armará una red de cuatro nodos y un gateway, basados en el microcontrolador ATmega328P y el

módulo LoRa SX1278. Se deberá resolver la comunicación SPI con el módulo LoRa para configurarlo

correctamente y enviar y recibir paquetes. Se deberá resolver el correcto control de cada semáforo

perteneciente a una esquina, asegurando configuraciones que no pongan en riesgo la seguridad de la vía

publica. Se deberá resolver la sincronización periódica de tiempos de todos los nodos de la red.

5- Descripción del sistema El sistema estará conformado por una red en estrella. Desde una PC se mandará las configuraciones al

Gateway, el cual las retrasmitirá al nodo pertinente, luego este nodo configurará los tiempos de cada luz

del semáforo según la información recibida.

Cada nodo controlará una esquina con cuatro semáforos, llevará la cuenta de un reloj el cual se

sincronizará periódicamente con el Gateway para evitar retrasos en la hora.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

6- Requerimientos y restricciones

6.1- Procesamiento y memoria El microcontrolador utilizado tendrá una frecuencia de reloj de 8 MHz, una memoria dinámica

disponible de 2 kBytes y una memoria no volátil de 1kByte. El sistema diseñado deberá tener en cuenta

estas restricciones como máximos absolutos para que el mismo funcione correctamente.

6.2- Tiempos de respuesta Se considera que únicamente dos tareas imponen una restricción relativamente importante de

cumplimiento de tiempos. Estas tareas son la sincronización del reloj a través del gateway y el control de

estados de los semáforos pertinentes.

En cuanto a la primera tarea, la restricción impuesta resulta ser del orden del segundo. Como se

menciona en la sección 8.2, una de las pruebas más importantes a realizar es la realización de una

estadística sobre los tiempos que transcurren entre que el gateway comienza un proceso de

sincronización con un nodo y este último setea la hora recibida. Este estudio permitirá agregar

constantes experimentales que permitan reducir los errores de retardo en las sincronizaciones.

En cuanto a la segunda tarea, es importante recordar que los elementos a controlar tienen una

interacción directa con los seres humanos y, por tanto, esta tarea también impone restricciones de

tiempo del orden del segundo. Sin embargo, se considera una tarea de prioridad alta y, por tanto, a la

hora de realizar el desarrollo se considerará una implementación a través de interrupción.

7- Diseño preliminar

7.1- Plataforma de Hardware A continuación, presentamos el diagrama de bloques de conexión del hardware de los nodos. En cuanto

a la alimentación, se considera que el consumo de los propios semáforos resulta mucho mayor que el

del sistema, por lo que no tiene sentido implementar funcionalidades de bajo consumo.

El módulo LoRa y el micro ATmega328P se conectan entre si con el puerto SPI y 3 puertos de entrada y

salida.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

7.1.1- Hardware disponible Al momento de presentación de este documento, este equipo ya cuenta con la cantidad mínima

suficiente de módulos sx1278 para realizar el desarrollo del proyecto. A su vez, se dispone de

microcontroladores ATmega328P suficientes como para realizar la implementación sin necesidad de

realizar alguna compra extra.

La cantidad mínima que se estima necesaria para realizar el proyecto es de 5 módulos en total,

representando 4 esquinas a configurar y un nodo central que realice las configuraciones pertinentes.

Por último, se cuenta con un programador/debugger, AVR Dragon

7.1.2- Hardware faltante Una última parte del sistema es lo referido a la implementación de los semáforos propiamente dichos.

Estos se realizarán con un conjunto de 3 leds a ser manejados por el controlador externo.

7.2- Arquitectura de Software Se realizará una arquitectura de software estilo Round Robin con interrupciones hibrida. A continuación,

se presentan los principales módulos involucrados en el sistema.

5.3.1- Módulo IO El objetivo de esta librería es implementar una capa de abstracción al microcontrolador a través de

definiciones y funciones simplificadas.

5.3.2- Módulo reloj En este módulo se desarrollarán todas las estructuras y funcionalidades necesarias para llevar un

registro de la hora actual. Parte de este módulo implica la utilización de un timer del micro para generar

interrupciones que actualicen de forma adecuada el reloj. En la sección de planificación este módulo se

define como “Reloj”.

5.3.3- Módulo de control de semáforos Este módulo tiene como objetivo agregar una capa de abstracción sobre la transición de estados de los

semáforos que pertenecen a cada nodo. Esto se obtendrá al recibir desde los demás módulos, la

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

configuración deseada. Haciendo uso de un segundo timer del microcontrolador, este modulo generara

interrupciones con el objetivo de tener el conocimiento del tiempo transcurrido en cada estado. Si bien,

se podría utilizar el tiempo proporcionado por el modulo reloj, el tener una rutina de atención a

interrupciones propia garantiza que el estado de los semáforos será modificado en el momento en que

sea necesario. Es importante observar que, si bien con la frecuencia de reloj que se trabajará (8 MHz) no

es posible generar interrupciones cada un tiempo largo (Por ejemplo 5 minutos), la frecuencia de

interrupciones será menor que para el reloj, cediendo al programa principal mayor tiempo de

procesamiento.

En la sección de planificación este módulo se define como “Control de luces”.

5.3.4- Módulo de agenda Este módulo se encargará de guardar y recuperar la información de configuraciones en la memoria no

volátil del micro. Además, en función de la hora actual deberá ser capaz de definir la configuración

actual. En la sección de planificación este módulo se define como “Agenda”.

5.3.5- Módulo de comunicación Este módulo se encargará de configurar la radio SX1278 para enviar y recibir cadenas de bytes usando el

protocolo LoRa. Inicialmente se consideró que este módulo debía incluir una rutina de atención a

interrupciones para manejar los mensajes recibidos por la radio, ya que potencialmente permitiría una

menor perdida de mensajes (En el momento que llega un mensaje, es encolado en un buffer y la radio

comienza a escuchar cuanto antes).

Sin embargo, el protocolo de comunicación elegido incluye la respuesta de un “ACK” ante una llegada de

un nuevo mensaje. Esto se traduce en la necesidad de un buffer de mensajes para transmisión. Si bien

esto agrega un nivel de complejidad solucionable, el hecho de mantener estos dos buffers de mensajes

en la arquitectura de hardware elegida resulta muy restrictivo en términos de memoria dinámica.

La solución propuesta para solucionar este problema es la utilización de la arquitectura polling. Es decir,

la radio se configurará para que, en cuanto reciba un paquete completo en su buffer de recepción

interno, se genere una interrupción (Dentro de la radio) que modifique el estado de uno de sus puertos

I/O conectado a su vez a uno de los puertos I/O del microcontrolador. En el programa principal de este

último, se consultará el estado de dicho puerto realizando el procesamiento necesario en caso de haber

recibido un paquete.

Se observa que, en este caso el mensaje de respuesta “ACK” es transmitido cuanto antes. Si bien se

podría argumentar que la arquitectura elegida tiene el potencial de perder paquetes, ya que la radio se

encuentra en un estado de no escucha mientras el microcontrolador no pueda atenderla, el protocolo

de comunicación elegido hará un reintento de transmisión hasta que se reciba el “ACK”

correspondiente.

En las ilustraciones este módulo se define como “Comm”.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

8- Planificación

8.1- Distribución de tareas a realizar

8.2- Pruebas a realizar Para verificar el correcto funcionamiento del sistema se realizarán las siguientes pruebas

Prueba de Módulo IO

Se probará que el módulo configure correctamente los puertos de entrada y salida para ello se creara

una función que copie el voltaje de un pin en otro y externamente se impondrán y medirán los voltajes

de los pines.

Prueba de Módulo Reloj

Se comprobará que la configuración del timer sea correcta, que el tiempo entre cada interrupción sea de

1ms y que el retardo máximo y la desincronización del reloj en una hora no sean mayores a un 1%.

Prueba de Módulo comunicación

Se confirmará que tanto el Gateway como el nodo pueden recibir y enviar información sin perdida

información o retrasos mayores a segundos.

Prueba de Control de luces

Se verificará que el módulo programa correctamente los semáforos para ello se usaran leds para

visualizar el funcionamiento. En esta prueba sobre todo hay que asegurar es imposible poner una

configuración que ponga en riesgo la seguridad vial, por ejemplo, todos los semáforos en verde,

semáforos no sincronizados o tiempos demasiado cortos o largos.

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Testing General

Se comprobará el funcionamiento completo de la red desde el Gateway pasando por los nodos hasta los

leds que simularan a los semáforos.

8.3- Hitos intermedios Se observa que al momento de presentar el Hito 1, el respetar correctamente el cronograma de trabajo

mostrado en la sección 8.4, implicaría que el sistema se encuentre desarrollado y testeado, haciendo

falta únicamente realizar la documentación y la maqueta final del proyecto.

8.4- Cronograma

A observar:

➢ En el plan de trabajo presentado, se incluyen implícitamente testing sobre cada uno de los

módulos de forma individual, dentro del tiempo en que se pretende su desarrollo. El bloque

agregado como “Testing General” implica la integración y depuración del conjunto de todos los

módulos.

➢ Se agrega un buffer partido en dos sub-bloques las implementaciones de los módulos Control de

luces y Agenda. Este buffer tiene como objetivo agregar posibles funcionalidades a la librería

ATmega328P que hayan faltado desarrollar.

➢ El módulo de comunicación a través del transceptor sx1278 ya se encuentra implementado y

testeado:

o Se ha realizado una librería capaz de realizar las configuraciones pertinentes a la

transmisión y recepción de mensajes, a través del SPI del módulo sx1278.

o Como será detallado en futuras versiones de este documento, la librería implementa

una capa de enlace de datos (Data link layer) sobre el módulo sx1278, definiendo entre

otras cosas, direcciones únicas para el encaminamiento de las tramas.

o Resaltamos que, si bien este módulo de comunicación ya implementado depende de la

librería “Arduino.h”, ya que hace uso de las funciones “pinMode”, “digitalRead”,

“digitalWrite”, uno de los objetivos del proyecto es la sustitución de esta librería por la

librería a desarrollar “modulo IO”

Instituto de Ingeniería Eléctrica – Facultad de Ingeniería – Universidad de la República

Bibliografía

[1] “Daniel Martínez: “Hay casi tres veces más vehículos de lo que había hace 10 o 12 años””

[online]. Uruguay: Uycheck, 2015 Disponible en: http://uycheck.com/daniel-martinez-hay-casi-

tres-veces-mas-vehiculos-de-lo-que-habia-hace-10-o-12-anos/

[2] “En horas pico, en avenida Italia autos circulan a 25 km/h” [online]. Uruguay: El Observador,

2016. Disponible en: https://www.elobservador.com.uy/en-horas-pico-avenida-italia-autos-

circulan-25-kmh-n974936

[3] “Casi 3.000 automóviles transitan por la rambla en una hora "pico"” [online]. Uruguay: El País,

2016. Disponible en: https://www.elpais.com.uy/informacion/automoviles-transitan-rambla-

hora-pico.html

[4] Ruhaizan F., Fadhlan H., Shamry M “Smart traffic light for congestion monitoring using

LoRaWAN” [online]. Malasia: El Observador, 2017 Disponible en:

https://ieeexplore.ieee.org/document/8070582/

[5] João Pedro Piteira da Cunha, “Wireless Communication System for Traffic Management and

Control” [online], Tesis, Instituto Superior Técnico, Universidad de Lisboa, Lisboa, 2016.

Disponible en: https://fenix.tecnico.ulisboa.pt/downloadFile/1407770020545402/resumo.pdf