inteligent emergency response cars (ierc)

INTELIGENT EMERGENCY RESPONSE CARS (IERC)

1 DE25

Inteligent Emergency Response Cars (IERC)

Juan Felipe García Sergio Sebastián Cristancho Delgado

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA

DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN Bogotá, DC

Noviembre 2015


2 DE25

Inteligent Emergency Response Cars (IERC)

Juan Felipe García Sergio Sebastián Cristancho Delgado

Proyecto de Grado presentado como requisito para optar al título de Ingeniero de Sistemas

Director: Yezid Donoso Meisel, Ph.D.

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA

DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN Bogotá, DC

Noviembre 2015


3 DE25

Tabla de contenido

Abstract ............................................................................................................. 4 Introducción ....................................................................................................... 5 Descripción general ........................................................................................... 6

Objetivos .................................................................................................. 6 Antecedentes ........................................................................................... 6 Identificación del problema y de su importancia ...................................... 7

Diseño y especificaciones ................................................................................. 8

Definición del problema ........................................................................... 8 Especificaciones ...................................................................................... 8 Restricciones ......................................................................................... 10

Implementación ................................................................................................. 11

Descripción de la implementación ......................................................... 11

Diagrama de despliegue ............................................................. 11 Diagrama de Componentes ........................................................ 13

Resultados ........................................................................................................ 20 Conclusiones ..................................................................................................... 22

Discusión ............................................................................................... 22 Trabajo futuro ........................................................................................ 22

Referencias ....................................................................................................... 23 Anexos .............................................................................................................. 24

Manual de despliegue, IERC Demo. ...................................................... 24


4 DE25

ABSTRACT

Even in large and highly advances cities there’s always an emergency, this means that ambulance, policemen and firemen (ERC – Emergency response cars) are in need of a route to get from point A to point B as fast as they can, but traffic gets in their way. As a solution we present a based architecture in which the problem is resolved using main components:

The first one is a M2M (Machine to Machine) communication between ERC and

traffic lights so the lights can be green as soon as these cars approach. The second one, a basic graph based route optimization where ERC can avoid traffic.


5 DE25

INTRODUCCIÓN

Una ciudad es un área urbana compleja. Se espera que la metrópoli provea de servicios de primera necesidad a sus habitantes y que a su vez, haga un manejo eficiente de los bienes públicos, abarcando la mayor cantidad de usuarios al tiempo que usa la menor cantidad de recursos posibles.

Sin embargo, este ideal no se cumple a cabalidad. La naturaleza cambiante de la población y la aptitud de los entes de gobierno para afrontar la demanda de servicios, especialmente en la atención de llamadas de emergencias, demuestra que las ciudades tienen todavía mucho por hacer.

Con la necesidad de disminuir los tiempos de respuesta en la atención de

desastres naturales, los problemas de la ciudad en términos de seguridad y el transporte de usuarios del sistema de salud, nace la idea de introducir comunicación M2M, para mejorar la movilidad del cuerpo de bomberos, la red de ambulancias y la policía metropolitana.

M2M (Machine to Machine) es un concepto genérico que se refiere al

intercambio de datos o comunicación entre maquinas remotas [1]. El intercambio de información se plantea entre los autos y vehículos de atención de emergencias (ERC) y los semáforos para que, con el conocimiento del entorno, los ERC puedan; seleccionar una ruta óptima a su destino con la menor carga vehicular posible y requerir si hace falta, un paso a luz verde evitando los contratiempos.

En el siguiente documento se definen las expectativas del proyecto como

una propuesta de solución para los ERC en la ciudad de Bogotá, se evalúa el estado del arte en torno al uso de sensores como habilitadores para la «movilidad inteligente» y se plantea una propuesta para la ciudad en estudio.

El trabajo termina con la implementación de la propuesta y un análisis de

resultados de la solución, evaluando inconvenientes y posibles mejoras que incrementen la eficiencia de los sistemas de apoyo a emergencias (ERC).


6 DE25

DESCRIPCIÓN GENERAL

OBJETIVOS

Se busca diseñar una plataforma para mejorar el tránsito de los ERC en momentos de emergencia. La idea nace de la problemática en términos de transporte de la ciudad de Bogotá, en donde no se cuenta con políticas de movilidad que den prioridad a los vehículos de emergencia.

Dado que el tiempo es un factor importante para que los ERC ofrezcan un servicio adecuado, la arquitectura debe ser eficiente, con tiempos de respuesta reducidos frente a la demanda de información de los ERC y al análisis de los datos provistos por los actuadores en el entorno.

ANTECEDENTES

En el campo de la movilidad existen a día de hoy, varias propuestas encaminadas a resolver los problemas cotidianos de transporte a través de internet de las cosas (IoT por sus siglas en inglés). IoT es un concepto que se refiere a la conexión digital de objetos cotidianos con internet. Las herramientas que ofrece este mundo de interconexión son potentes y de gran utilidad para la toma de decisiones. Gracias al uso de activadores o sensores que cuantifican el entorno, es posible por medio de estos datos aumentar la eficiencia de un sistema o automatizar los procesos que antes requerían de intervención humana para su desarrollo. Damian Black [2], propone en la Strata Conference una solución enfocada a la administración del tráfico en tiempo real por medio de una red de sensores. Con la aplicación SmartCity StreamApp es capaz de ofrecer a un amplio rango de sistemas de transporte; información sobre el tráfico (junto con alertas de congestión), integración con redes sociales (Twitter), manejo en tiempo real de los sistemas operacionales de la infraestructura vial (Ej: señales de velocidad) y capacidad de interacción con otras aplicaciones del sector.

En [3] se plantea un modelo de optimización sobre el balanceo de carga de la congestión de la infraestructura vial, para la comunicación entre dispositivos V2V (Vehículo a vehículo) y V2I (vehículo a infraestructura) para mejorar la movilidad de un ciudad, a partir de tomas de decisiones dinámicas sobre el estado de la infraestructura.

A diferencia de las dos anteriores, en [4] se busca una solución para el

óptimo uso de los sitios de parqueo de motociclistas en la ciudad de Milton Keynes, Inglaterra. Esta propuesta busca al administrar de manera adecuada los sitios de estacionamiento y gracias a la información en tiempo real del estado de


7 DE25

ocupación de dichos lugares, reducir costos en tiempo y combustible de sus usuarios.

A nivel de infraestructura de comunicación, en [5] se plantea el desafío de integración entre las redes inalámbricas de sensores (WSNs) y la red celular LTE como un medio para la interacción, distinta a la celular, entre los dispositivos IoT. Finalmente, en [6] se propone una técnica de detección de anomalías en el tráfico, basado en inferencias de lógica difusa que puede ser implementado en redes de internet de la cosas como insumo para la toma de decisiones a partir de la información procesada por la técnica de detección de atascos vehiculares.

IDENTIFICACIÓN DEL PROBLEMA Y DE SU IMPORTANCIA

En ciudades de gran densidad poblacional es necesario tener servicios de atención al ciudadano que sean eficientes en el uso de los recursos que dispone el gobierno y también, en el tiempo sobre todo si se trata de servicios de atención a emergencias.

Los vehículos de atención de desastres (bomberos y defensa civil),

seguridad ciudadana (policía ciudadana, CTI fiscalía) y salud, no poseen en Colombia y también, políticas de transito que les permitan prestar un mejor servicio.

De acuerdo al Artículo 64 del Código de Tránsito y Transporte, la ley exige

que «Todo conductor debe ceder el paso a los vehículos de ambulancias, cuerpos de bomberos, vehículos de socorro o emergencia y de la policía o ejército, orillándose al costado derecho de la calzada o carril y deteniendo el movimiento del vehículo cuando anuncien su presencia por medio de luces, sirenas, campanas o cualquier señal óptica o audible» [7].

Aunque la ley es clara, no especifica los derechos y deberes de los

conductores de carros particulares y los conductores de vehículos de atención de emergencias (ERC), dando pie a diferentes interpretaciones, dudas y omisiones.

Peor aún, son las acciones que ponen en peligro la vida de los peatones y

los conductores, a falta de una reglamentación que explique el proceso a seguir cuando un ERC tras un semáforo en rojo, pide el paso.

No basta que el ERC obtenga vía libre para reducir su tiempo de trayecto. A

falta de información que describa el estado actual en las vías de la ciudad, los vehículos de atención a emergencias no cuentan con un método que les permita seleccionar el trayecto más corto. En las calles de la ciudad, no es extraño encontrarse con ERC’s detenidos en una vía congestionada.


8 DE25

DISEÑO Y ESPECIFICACIONES

DEFINICIÓN DEL PROBLEMA

Los ERC’s necesitan prestar el servicio en el menor tiempo posible. A la fecha actual, los vehículos de atención a emergencia no son eficientes en el manejo del tiempo, que concierne al transporte de su cuerpo de acción desde el centro de logística, al lugar de atención de la emergencia. Finalmente y en lo que respecta a la aplicación de las normas de tránsito, no existe una reglamentación clara sobre el comportamiento de los vehículos particulares y los ERC’s frente a luces de parada, por lo que se presenta no solo un problema de manejo del tiempo sino también, de seguridad ciudadana.

ESPECIFICACIONES

De la eficiencia de los vehículos de atención de emergencia depende el tiempo de repuesta de los sistemas de atención de desastres, salud y seguridad pública. Teniendo en cuenta que de esta prontitud depende la vida de muchos individuos, a continuación se describen los requerimientos críticos que se espera, cumpla la solución al problema propuesto:

Requerimiento R1 Tipo Funcional Prioridad Alta

Atributo de Calidad Latencia

Justificación El sistema debe habilitar la luz verde para los vehículos de atención a emergencias (ERC)

Fuente ERC

Estimulo Un ERC se encuentra detrás de un semáforo en luz roja y este le envía el tiempo que requiere para llegar a la intersección.

Artefacto Sistema

Ambiente Ejecución normal del sistema

Respuesta

El sistema cambia los ciclos semafóricos de la intersección de modo que el ERC tiene vía libre para cruzar el semáforo de forma segura, el tiempo que ha sido solicitado por el vehículo.

Medida de la Respuesta

El tiempo que tarda el sistema en cambiar la luz desde que el vehículo envía la petición, no es mayor a 1s.

Tabla 1. Requerimiento I


9 DE25


Atributo de Calidad Latencia

Justificación El sistema le provee al vehículo, la ruta más óptima en términos de tiempo para que el usuario pueda llegar a destino.

Fuente ERC

Estimulo Un ERC recibe una solicitud de servicio y este desea llegar al lugar donde es solicitado.

Artefacto Sistema

Ambiente Ejecución normal del sistema

Respuesta

El sistema le envía al vehículo, la ruta con el tiempo más corto desde el punto en el que se encuentra al lugar donde desea llegar, teniendo a consideración la distancia del trayecto y la congestión del mismo.


El sistema envía la información requerida por el usuario en un tiempo inferior a 5s

Tabla 2. Requerimiento II


Atributo de Calidad Escalabilidad

Justificación

La solución responde adecuadamente a los requerimientos del usuario, aun cuando existen peticiones simultáneas de diferentes vehículos de atención de emergencias en la ciudad.

Fuente ERC

Estimulo Varios usuarios requieren de manera simultánea, de alguno de los servicios prestados por el sistema.

Artefacto Sistema

Ambiente Ejecución estándar del sistema

Respuesta El sistema responde adecuadamente a la petición hecha por el vehículo IERC, sin presentar demoras apreciables.


El sistema es capaz de responder cincuenta peticiones con una separación máxima de 30s entre ellas, sin disminuir los tiempos de respuesta.

Tabla 3. Requerimiento III

Requerimiento R4 Tipo No Funcional Prioridad Alta

Atributo de Calidad Seguridad (Manejo de intersecciones)

Justificación La aplicación debe estar en la capacidad de manejar dos peticiones de cambio de semáforo sobre una misma intersección.


10 DE25

Fuente ERC

Estimulo Dos usuarios desean cruzar una intersección y piden de manera simultánea, luz verde para cruzar

Artefacto Sistema

Ambiente Ejecución estándar del sistema

Respuesta

El sistema ofrece el cambio de luces a dos o más vehículos IERC que esperan en una intersección, de tal forma que no haya más de un grupo semafórico simultáneo en verde.


Los vehículos pueden cruzar la intersección en el menor tiempo posible, sin poner en peligro la vida de los actores involucrados en el 100% de las veces.

Tabla 4. Requerimiento IV

RESTRICCIONES

Para la realización del proyecto debemos tener en cuenta que el tiempo de desarrollo debe ser inferior a un semestre y además, que los costos de su implementación en relación a los problemas de movilidad al momento de realizar la instalación sean bajos sino, nulos.

En lo concerniente al tiempo, se opta por el uso de Python [8] como lenguaje de programación para minimizar la curva de aprendizaje y poder ofrecer un ciclo de trabajo, en términos de entregables, de mayor fluidez. El hecho de que Python sea un lenguaje Open Source permite abaratar los costos si se piensa en poner esta propuesta a producción y, si se desea hacer una integración con otras plataformas e infraestructuras, Python es una elección adecuada por la ausencia de gastos en la adquisición de licencias.

En este punto hay que tener en cuenta que la elección de Python sobre otros lenguajes, supone un costo en eficiencia y escalabilidad de la solución al tratarse de un entorno no compilado sino, interpretado.

Para saldar este problema, se hace necesario proponer un sistema descentralizado en donde las peticiones a servicios de la plataforma, correspondan a un porcentaje del total de los usuarios distribuidos en toda la ciudad. La instalación de los dispositivos que permiten modificar el tiempo de los ciclos semafóricos no debe ser intrusiva y la elección de la infraestructura de despliegue debe ser tal que no se comprometa la movilidad de la ciudad. Es decir, que no sea necesario realizar cierres parciales de las vías.


11 DE25

IMPLEMENTACIÓN

La implementación parte, dado que no se cuenta con todos los recursos físicos; de un modelo simulado en el que por un lado, se tienen los dispositivos físicos correspondiente al vehículo IERC y al terminal encargado de controlar los semáforos en una intersección y por otro, en el ambiente supuesto, una ciudad con vías y grado de ocupación específico para cada uno de las mismas.

Aunque la solución se plantea para que pueda ser desplegada en un

ambiente de ejecución real, las pruebas, así como el análisis de resultados se evalúan en un ecosistema simulado.

DESCRIPCIÓN DE LA IMPLEMENTACIÓN

El desarrollo busca como primera medida, revolver el problema en relación a la latencia y escalabilidad del sistema. Para ello, se reduce la demanda que podría presentar un nodo central, a múltiples nodos distribuidos en la ciudad de manera equitativa.

En la ciudad de estudio, Bogotá, existe una división administrativa llamada

distrito o localidad cuyo fin, es el de proveer a los ciudadanos; redes de servicios públicos y abastecimiento de productos.

Cada localidad, aunque está regida bajo unos lineamientos administrativos

de la alcaldía mayor, es independiente y cuenta con centros de atención al ciudadano, central de cuerpo de bomberos, CAI (Centro de Atención Inmediato) de la policía y centros de salud, encargados de velar por las necesidades de sus habitantes en el área de cobertura.

Diagrama de despliegue

A continuación se muestra el diagrama de despliegue a grandes rasgos, en donde se define, por localidades un punto de control de IERC.


12 DE25

Ilustración 1. Diagrama de despliegue, General

Cada una de estas centrales, es un servidor que, cuyo único objetivo, es el de calcular la ruta más óptima a partir del lugar de origen y de destino del vehículo IERC, encerrado en el área de cobertura de la localidad. Dada la distribución administrativa de las localidades, un vehículo de atención de emergencias no necesitara cruzar las fronteras de la localidad para atender una llamada por lo que las centrales se manejarán de manera independiente.

Ilustración 2. Diagrama de despliegue, específico

En la imagen de despliegue por localidad, tenemos los tres tipos de dispositivos que conforman la infraestructura propuesta a saber:

Central IERC: se comunica con los dispositivos IERC al inicio del trayecto para establecer la ruta óptima y en caso de que el vehículo requiera una


13 DE25

actualización del estado de las vías, en un instante posterior a la movilización del carro.

Dispositivo IERC: es el usuario del sistema, encargado de hacer las peticiones a la central para el cálculo de ruta y a las intersecciones, para modificar los ciclos semafóricos a conveniencia.

Intersección semafórica: dada una petición del usuario, cambia, si lo cree necesario, el ciclo del grupo de semáforos de tal manera que el IERC pueda cruzar la intersección sin necesidad de detenerse.

Cada uno de los dispositivos involucrados en el ecosistema se comunica con los demás entes del sistema mediante una conexión inalámbrica a internet IP. Para el modelo planteado, no se tiene en consideración la comunicación entre dispositivos IERC, pues no aporta ningún valor agregado a la solución del problema planteado.

Diagrama de Componentes

El problema desde el punto de vista de componentes, se aborda teniendo en cuenta los módulos que se requieren para la simulación.

En un entorno de ejecución real, tenemos por parte del dispositivo IERC un

componente IERC, para la intersección semafórica un objeto encargado de recibir

las peticiones del Client, Intersection, y un conjunto de los semáforos que

pertenecen a esta intersección, Semaphore.

Ilustración 3. Diagrama de clases, Componente Intersection


14 DE25

Para efectuar la comunicación entre las dos entidades se hace uso de un simulador, simulator, que tiene como una de sus funciones principales, conocer

todos los clientes e intersecciones que hacen parte de la subred. Para un ambiente de despliegue la comunicación se realiza sin

intermediarios y, es el Cliente el que se comunica con la intersección para cambiar su estado.

A continuación se muestra el diagrama de clases para el componente en la

Central IERC. En esta ocasión, la clase IERC es un vehículo de atención a

emergencias, y Graph, es el encargado de mantener el grafo que representa la

infraestructura vial de la localidad. Los objetos como el Container y la clase

Simulation, son únicamente ilustrativos para el desarrollo de pruebas.

Ilustración 4. Diagrama de clases, Componente Central IERC

Por ejemplo, la labor que desempeña simulation en el componente (vehículo) IERC, permite representar los parámetros del estado del carro como la velocidad, tiempo y la distancia que ha recorrido en el nodo. Estos datos, posteriormente, serán usados como parámetro en los métodos ofrecidos por la intersección, para modificar los ciclos semafóricos.

Como métodos de importancia en las clases descritas debemos resaltar:


15 DE25

Clase Método Funcionalidad

Intersection

changeSemaphore

Cambia el semáforo pedido por el IERC en la intersección. Recibe como parámetro el identificador del semáforo y el tiempo de trayecto hasta el mismo. Si lo requiere, se modifican los ciclos semafóricos para que el usuario pueda cruzar la intersección de manera segura. Este cambio se realiza siempre y cuando un vehículo IERC no haya requerido el cambio de luz. Si existen dos dispositivos IERC en conflicto de intereses, el último que haya hecho la petición entra en una cola de espera y será atendido después de que pase el primero

getOccupancy

Le informa al IERC, el estado de ocupación de la vía. Con esta información y la velocidad del vehículo, el IERC puede determinar el tiempo requerido hasta la intersección.

IERC is_red Le pide a la intersección, el cambio de luz del semáforo.

Graph shortest_path

Este método es usado por el dispositivo IERC cuando se conecta al sistema y permite, dado el punto de partida y llegada, calcular el trayecto de menor costo.

Para ser consecuentes con el diagrama de despliegue, la simulación se

realiza en tres dispositivos diferentes. Por un lado, tenemos un computador que sirve como servidor y simulador

del estado de cada uno los vehículos y por otro, en lo que concierne a los elementos que hacen parte de la infraestructura vial, la intersección y el vehículo IERC, la aplicación se despliega en dos Rapsberry Pi [9].

A continuación se muestra el código implementado para: La clase intersección: Esta clase maneja un pool de Threads que

representan los semáforos, cada uno de ellos con un contador inicializado al comienzo de cada cambio de estado. Este temporizador es utilizado para calcular los nuevos ciclos semafóricos cuando se reciba una petición por parte del IERC.

import threading as t import time import random

Tiempo de espera de los semáforos.


16 DE25

delay=4

Una intersección tiene un grupo de semáforos cada uno con su estado. El semáforo se encuentra en el nodo de destino y existe uno por cada arco que tenga conexión con el nodo origen.

class Intersection(t.Thread): def __init__(self, idNodo, semaphores, simulador): t.Thread.__init__(self) self.idNodo=idNodo self.semaphores=semaphores self.waitTime=delay self.cond=t.Condition() self.noChange=0 self.sim = simulador

OneCicle permite regresar al delay inicial de los semáforos, una vez que

se ha cambiado abruptamente el tiempo del ciclo semafórico por el paso de un ERC. Después de que el ERC ha pasado el semáforo, regresa al tiempo normal de espera en rojo.

def run(self): oneCicle=0 while True: if oneCicle>1: self.waitTime=delay oneCicle=0 self.timeI=time.time() self.cond.acquire() self.cond.wait(self.waitTime) self.timeF=time.time() self.semaphoricCicle() if self.waitTime!=delay: oneCicle+=1 def semaphoricCicle(self): if not self.noChange: for idSem, s in self.semaphores.iteritems(): if s.state==1: self.semaphores[idSem].state=0 self.semaphores[idSem].occupancy=random.uniform(0.3,

0.9) else: self.semaphores[idSem].state=1 self.semaphores[idSem].occupancy=random.uniform(0.2,

0.6) self.sim.updateState(self.semaphores[idSem].origen,

self.semaphores[idSem].destino, self.semaphores[idSem].state) self.noChange=0 self.cond.release()

def changeStateERC(self, dest, tim): self.timeF=time.time() timePassed=self.timeF-self.timeI


17 DE25

key = self.idNodo+"-"+dest print "key:", key state = self.semaphores[key].state print "key ", key, " OK" if state == 0: self.cond.acquire() self.cond.notify() self.waitTime = tim self.cond.release()

Si el tiempo que queda en verde no alcanza para que el ERC cruce el

semáforo, se establece el tiempo de espera que haría falta para que la ambulancia pasará indicando que no se debe cambiar el estado del semáforo.

elif state == 1 and tim >(delay-timePassed): self.waitTime = tim-(delay-timePassed) self.noChange = 1

def getOccupancy(self,dest): semaphore=self.semaphores[self.idNodo+"-"+dest] timeInState=(self.timeI-time.time())/delay if semaphore.state: temp=semaphore.occupancy*(1+timeInState*.7) if temp>1: semaphore.occupancy=1 else: semaphore.occupancy=temp else: temp=semaphore.occupancy*(1-timeInState*0.7) if temp<0: semaphore.occupancy=0 else: semaphore.occupancy=temp return semaphore.occupancy class Semaphore: def __init__(self, state, ocuppancy, origen, destino): self.state=state self.occupancy = ocuppancy self.origen = origen self.destino = destino

El componente en el IERC. Que contiene la representación del mapa de la localidad por medio de un grafo y las funciones necesarias para hacer las peticiones a la intersección.

from MyGraphs import Graph from random import randint from threading import Thread import time import sys


18 DE25

class MainClass(Thread): def __init__(self, nodo1, nodo2): self.nodo1 = nodo1 self.nodo2 = nodo2 self.gra = Graph() text_file = open("grafo1.txt") lines = text_file.readlines() nods = lines.pop(0).split(",") for i in nods: to_add = i.strip() self.gra.add_node_to_graph(int(to_add)) for i in lines: data = i.split("#") data2 = data[1].split(":") self.gra.add_edge_to_graph(int(data[0]), int(data2[0]),

int(data[2]), float(data[3]) , data2[1]) self.car = IERC(nodo1, nodo2, self.gra, self) time.sleep(1) self.semServer = InfoSender(self.car) self.server = Sender(self.car)

def changeSemaphoreState(self, origen, destino, time): update = "UPDATE#" + str(origen) + "#" + str(destino)+ "#" +

str(time) self.semServer.send(update) def run(self): print "New Car Sent Form: ", self.nodo1, " To: ", self.nodo2

Y, la clase usada para el mapa.

import networkx as nx

networkx [10], es una biblioteca para Python que incluye herramientas para

la creación, manipulación y estudio de estructuras dinámicas de redes complejas. Este paquete incluye algoritmos para el recorrido y optimización de búsquedas en el mismo.

class Graph: def __init__(self): self.G = nx.DiGraph()

def add_node_to_graph(self, node): self.G.add_node(node) def add_edge_to_graph(self, edge1, edge2, edge_weight, cost, light): self.G.add_edge(edge1, edge2, weight=edge_weight, cost=cost,

light=light) def shortest_path(self, node1, node2): path = nx.dijkstra_path(self.G, node1, node2)


19 DE25

resp = [] for i in range (0, len(path) -1): data = self.get_cost(path[i], path[i+1]) to_add = (path[i],path[i+1],data['weight']) resp.append(to_add) return resp def get_cost(self, from_node, to_node): temp = self.G.get_edge_data(int(from_node), int(to_node)) return temp def is_light_green(self,from_node, to_node): data = self.G.get_edge_data(from_node, to_node) luz = data['light'] if luz == 1: return False return True def change_light(self,node1, node2): arc = self.G.get_edge_data(node1, node2) arc['light'] = 0 def get_all_edges(self): return self.G.edges() def get_all_nodes(self): return self.G.nodes()


20 DE25

RESULTADOS

La simulación de la infraestructura vial (estado de las vías y semáforos) y la de los vehículos en ella (IERC’s y vehículos no IERC) se cargó a la aplicación a partir de valores aleatorios y después, conforme al comportamiento de la red, se modificó para que representara la situación en un entorno real de la siguiente manera:

Para los semáforos, se definió un tiempo de ciclo semafórico constante de 30s que solo se modificaba tras una petición del IERC.

La ocupación de las vías es una función lineal en relación al tiempo de actividad de una luz verde o roja en el semáforo. Si el semáforo está en verde, la ocupación disminuye por un factor aleatorio entre 1 y 0 y si esta en rojo, la ocupación aumenta en una misma relación.

Para el control de los Raspberry Pi se empleó SSH y un router con servicio DHCP para obtener las direcciones IP’s de los dispositivos.

Ilustración 5. Control de dispositivos por SSH

Aquí pi@raspberrypi1 es la maquina donde se ejecuta la implementación

de la intersección y en pi@raspberrypi2, la del IERC.

A continuación, un IERC desea ir del nodo 4 al nodo cinco. Para esto, es necesario modificar el ciclo de la intersección de tal modo que el semáforo con identificador 4-5 tenga un tiempo en luz verde igual a 13,39s


21 DE25

Ilustración 6. Actualización del semáforo en tiempo de ejecución

Que, de acuerdo a la información simulada por el servidor, es el tiempo requerido por el vehículo de atención a emergencias para recorrer una distancia de 267,9 unidades.

Ilustración 7. Actualización del estado del vehículo en tiempo de ejecución

Para una selección aleatoria de rutas hecha por cuatro vehículos como se muestra a continuación, todos los vehículos pudieron llegar a su destino y sin necesidad de disminuir el tiempo de marcha promedio.

Ilustración 8. Estado de ruta para los cuatro primeros vehículos

En contraposición a un ambiente en el cual no existen ciclos semafóricos prioritarios, la demora en el trayecto de un auto de atención a emergencias asociada a la espera en una luz roja, se ve reducida en un 290%

Ilustración 9. Tiempo promedio de espera.

0

0,5

1

1,5

2

2,5

3

3,5

Tiem

po

pro

med

io [

min

]

Sin cambio de ciclosemafórico

Con cambio de ciclosemafórico


22 DE25

CONCLUSIONES

DISCUSIÓN

La propuesta implementada se presenta como una buena solución a la problemática planteada.

Aunque no se realizaron pruebas físicas, la simulación; que tuvo en cuenta la aleatoriedad en las condiciones de la vía y el estado del vehículo a cada instante del trayecto, hizo posible corroborar el alcance de los requerimientos funcionales.

La manera en la cual se implementó el cambio de los ciclos semafóricos en las intersecciones, hizo posible que no hubiera tiempo de espera por parte de los IERC. Aun cuando las pruebas respondían a ambientes de estrés para los cuales, el sistema tenía un nuevo usuario cada 30 segundos, la solución fue capaz de responder al 100% de las peticiones, asegurando el arribo del vehículo.

La partición de la infraestructura vial de la ciudad en subgrafos de menor tamaño hizo posible que el sistema tuviera una respuesta inferior a las restricciones de tiempo y desempeño, planteadas para los requerimientos funcionales de escalabilidad y latencia.

TRABAJO FUTURO

La implementación de soluciones Ad hoc no cuenta con un gran alcance en la comunidad tecnológica, porque su desarrollo no responde a ningún estándar en particular y dificulta la adaptabilidad y el proceso de despliegue en otros ambientes de ejecución.

La selección de un estándar que haga más accesible la solución, es patente desde la primera etapa de implementación y la elección de Python sobre otros lenguajes se realiza, desde un inicio, con miras a adaptar la propuesta a la infraestructura para la comunicación de dispositivos IoT, Open MTC.

En el proceso de validación y ajuste de la propuesta se trabajó con información que no representaba completamente la realidad del problema. Por ejemplo, no se consideraron eventos críticos como el atasco de un vehículo IERC por un accidente no registrado en el estado de las vías o la necesidad de usar móviles de atención a emergencias ajenos a la localidad.

Para solucionar estos dos problemas se debe implementar un mecanismo que permita al IERC despejar una vía alterna (aunque aquí, el mayor problema no correspondería a la implementación si no a la legislación de transito) e interconectar la centrales IERC que antes estaban aisladas, para poder ofrecer una ruta optima más allá de la frontera administrativa que cubre la localidad.


23 DE25

REFERENCIAS

[1] Gartener, «Machine-To-Machine (M2M) Communications,» 2013. [En línea]. Available: http://www.gartner.com/it-glossary/machine-to-machine-m2m-communications.

[2] D. Black, «SmartCity StreamApp: An Internet of Things Service for Real-time Traffic Management,» Strata +Hadoop WORLD, 17 Octubre 2014. [En línea]. Available: http://conferences.oreilly.com/strata/stratany2014/public/schedule/detail/36506. [Último acceso: 12 Septiembre 2015].

[3] Y. Donoso y N. Parrado , Congestion Based Mechanism for Route Discovery in a V2I-V2V System Applying Smart Devices and Io, Bogota, 2015.

[4] A. Scroxton, «Milton Keynes to get open access internet of things network,» Computer Weekly, 22 Mayo 2014. [En línea]. Available: http://www.computerweekly.com/news/2240221176/Milton-Keynes-to-get-open-access-Internet-of-Things-network. [Último acceso: 15 Noviembre 2015].

[5] Y. Gadallah y H. El-Hennawy, WSN Application Traffic Characterization for, Cairo: IEEE 9th International Conference on Mobile Ad-hoc and Sensor Networks, 2013.

[6] S. Ageev, Y. Kopchak, I. Kotenko y I. Saenko, Abnormal Traffic Detection in Networks of the Internet of Things Based on Fuzzy Logical Inference, IEEE, 2015.

[7] Ministerio de Transporte, Código Nacional de Tránsito Terrestre, Bogotá, 2002.

[8] P. S. Foundation, «Getting Satarted,» 10 Noviembre 2015. [En línea]. Available: https://www.python.org/about/gettingstarted/.

[9] «Rapsberry Pi,» [En línea]. Available: https://www.raspberrypi.org/. [Último acceso: 19 Noviembre 2015].

[10] «NetworkX,» NetworkX developer team, 27 Octubre 2015. [En línea]. Available: https://networkx.github.io/. [Último acceso: 29 Noviembre 2015].


24 DE25

ANEXOS

MANUAL DE DESPLIEGUE IERC DEMO.

Para correr el demo se deben tener 3 nodos principales con lo siguiente:

1. Raspberry pi 1: a. En este es necesario tener montada la imagen «Image1» en una

tarjeta SD de 16GB . Sobre esta se ejecutarán los Semáforos. b. La IP que se le asignó fue 192.168.1.125

2. Raspberry pi 2: a. Montar la «Image2» en una tarjeta SD de 16GB; tarjeta sobre la cual

se desplegarán los IERC. b. La IP que se le asigno fue 192.168.1.130

3. Un PC Linux: a. Este tiene que tener con el código fuente del simulador que se

encuentra en la carpeta de código fuente en la ruta: TesisMTC/Simulator/

b. La Clase que se correrá será: IERCState.py c. Tiene que tener una IP estática No: 192.168.1.101

Es necesario tener conectadas las dos Raspberry con cable Ethernet a un Router y el PC puede ser de forma inalámbrica o con cable Ethernet. El Router debe tener red 192.168.1.0/24 Las dos Raspberry Pi tiene usuario «pi» con clave «tesismtc». Para escribir las imágenes en las SD se recomienda usar ApplePi-Baker para Mac

Las imágenes se encuentran en este link:

https://mega.nz/#F!6VRy2axD!kENOOFGXgzulh9EYeczOZQ

Pasos para correr el demo:

1. Primero es necesario correr el simulador, para esto, es necesario estar en la ruta dentro de código fuente: TesisMTC/Simulator/ y ejecutar:

sudo python IERCState.py

2. Luego de correr el simulador se conectan las dos Raspberry Pi con las dos tarjetas SD y una vez encendidas, abrir dos terminales en el PC y hacer acceso SSH con el siguiente código:

SSH –v [email protected] SSH – v [email protected]


25 DE25

La opción -v se hace con el objetivo de saber el estado de la comunicación durante el establecimiento de la conexión. Cuando se pide clave, se usa: «tesismtc».

3. Luego se ejecutan los semáforos en la Raspberry Pi con IP 192.168.1.125.

esto se hace corriendo el archivo go.sh que está en /home/pi, con el siguiente comando:

sudo ./go.sh

4. Luego se corren los IREC en la Raspberry Pi con IP 192.168.1.130

corriendo el mismo archivo go.sh que se encuentra en /home/pi 5. Finalmente se puede ver todo tal como está definido en el documento.

inteligent emergency response cars (ierc)

Documents