modelamiento de un sistema de comunicaciÓn para …
TRANSCRIPT
MODELAMIENTO DE UN SISTEMA DE COMUNICACIÓN PARA GESTION DEL RIESGO EN TUNELES VIALES DE COLOMBIA
JUAN SEBASTIÁN ROCHA OSPINA
GERARDO JIMENEZ GALINDO
UNIVERSIDAD PILOTO DE COLOMBIA
FACULTAD DE INGENIERÍAS INGENIERIA DE TELECOMUNICACIONES
BOGOTÁ 2019
MODELAMIENTO DE UN SISTEMA DE COMUNICACIÓN PARA GESTION DEL RIESGO EN TUNELES VIALES DE COLOMBIA
PROYECTO FINAL DE GRADO PARA OBTENER TITULO PROFESIONAL EN INGENIERIA DE TELECOMUNICACIONES
Presentado por:
JUAN SEBASTIÁN ROCHA OSPINA GERARDO JIMENEZ GALINDO
Docente Tutor:
DIANA CAROLINA CONTRERAS JUAREGUI
UNIVERSIDAD PILOTO DE COLOMBIA
FACULTAD DE INGENIERÍAS INGENIERIA DE TELECOMUNICACIONES
BOGOTÁ 2019
ii
Tabla de Contenido Resumen .......................................................................................................................................... 1
Introducción .................................................................................................................................... 2
Estado del Arte: Sistemas de comunicación para túneles ............................................................... 3
Sistemas ITS ................................................................................................................................ 3
Instrumentación de túneles utilizando ITS: ................................................................................. 5
Capítulo 1 ...................................................................................................................................... 12
Características de Transmisión Bluetooth .................................................................................... 12
Capa Física ................................................................................................................................ 12
Estructura del protocolo ............................................................................................................ 13
Baseband ................................................................................................................................... 13
Estados de operación ................................................................................................................. 15
LM (Link Manager) .................................................................................................................. 16
HCI (Host Controller Interface) ................................................................................................ 17
L2CAP (Logical Link Control and Adaptation Protocol) ......................................................... 17
Perfiles de Bluetooth ................................................................................................................. 18
Perfil de acceso genérico (GAP). .......................................................................................... 18
Perfil de intercambio genérico (GOEP). ............................................................................... 19
Perfil de transferencia de archivos (FTP). ............................................................................ 19
Perfil de puerto serial (SPP). ................................................................................................. 19
Perfil de acceso al descubrimiento del servicio (SDAP). ..................................................... 19
Perfil de gestión de redes por vía telefónica (DUN). ............................................................ 20
Perfil de envío de objeto (OPP). ........................................................................................... 20
Perfil de sincronización (SYNC). ......................................................................................... 20
Retardo de Transmisión ............................................................................................................ 21
Propagación de señales bluetooth ............................................................................................. 23
Infraestructura de un túnel ......................................................................................................... 24
Propagación de señales en un túnel ........................................................................................... 26
Retardo de transmisión en túneles ............................................................................................. 30
Gestión del Riesgo .................................................................................................................... 32
Capítulo 2 ...................................................................................................................................... 35
Planteamiento de Parámetros para la construcción de la solución ............................................... 35
Topología Bluetooth .................................................................................................................. 36
iii
Integración de protocolos y perfiles .......................................................................................... 38
Infraestructura TI ....................................................................................................................... 40
Canales de comunicación .......................................................................................................... 42
Bases de Datos .......................................................................................................................... 44
Gestión de la Información ......................................................................................................... 45
Parámetros influyentes en la gestión del riesgo ........................................................................ 46
Capítulo 3 ...................................................................................................................................... 48
Diseño lógico funcional ................................................................................................................ 48
Funcionamiento de nodos bluetooth ......................................................................................... 48
Esquema de Funcionamiento del Sistema ................................................................................. 50
Registro de Usuarios ................................................................................................................. 51
Captura y registro de información ............................................................................................. 52
Sincronización con plataforma de gestión ................................................................................ 53
Canal de comunicación GSM .................................................................................................... 54
Servidores .................................................................................................................................. 54
Topología aplicada .................................................................................................................... 55
Flujo de información ................................................................................................................. 57
Lógica aplicada al nodo cliente/servidor ................................................................................... 57
Proceso establecimiento canal de comunicación GSM: ....................................................... 59
Proceso de búsqueda nodo alterno como redundancia ......................................................... 60
Plataforma de Gestión ............................................................................................................... 61
Servidor Web ............................................................................................................................. 62
Backend para la obtención de datos desde los dispositivos remotos ........................................ 63
Frontend para visualización de datos ........................................................................................ 64
Diseño del DOM ....................................................................................................................... 64
Información de relevancia para la gestión del riesgo ................................................................ 67
Capítulo 4 ...................................................................................................................................... 68
Evaluación del sistema de gestión ................................................................................................ 68
Descripción ambiente simulado ................................................................................................ 69
Potencia de transmisión bluetooth en condiciones estáticas ..................................................... 73
Potencia de transmisión bluetooth a distintas velocidades ........................................................ 76
Pruebas a 30 Km/h ................................................................................................................ 77
Pruebas a 40Km/h ................................................................................................................. 78
Pruebas a 60km/h .................................................................................................................. 79
iv
Pruebas respuesta de servidor al envío de mensajes ................................................................. 79
Pruebas de usuarios simultáneos ............................................................................................... 82
Metodología de prueba ......................................................................................................... 82
Capítulo 5 ...................................................................................................................................... 85
Análisis de resultados obtenidos ................................................................................................... 85
Transmisión ............................................................................................................................... 85
Recepción .................................................................................................................................. 86
Presentación de los Datos .......................................................................................................... 87
Conclusiones y Recomendaciones ................................................................................................ 89
Conclusiones ............................................................................................................................. 89
Recomendaciones ...................................................................................................................... 90
Referencias .................................................................................................................................... 92
1
Resumen
Este proyecto plantea el desarrollo de un prototipo funcional basado en tecnologías
inalámbricas de bajo consumo energético, que permitan establecer un canal de comunicación entre
dispositivos de usuario tales como: Smartphone, tablets, pc personales y la plataforma de gestión
del sistema para la atención y prevención del riesgo en infraestructuras confinadas como túneles
viales.
Se examinaron parámetros técnicos de funcionalidad del sistema como son: potencia de
transmisión de emisores bluetooth para evaluar las distancias y comportamiento de señales,
perdidas de la señal digital emitida, los tiempos de respuesta y tasas de error durante el envío de
información entre usuario y máquina.
Adicionalmente los datos recolectados en la plataforma de gestión web del sistema describen
el tiempo de conexión del usuario, el ID de los nodos de conexión activos, cantidad de alertas
generadas en cada registro, tipo de evento recibido y posicionamiento geográfico de los nodos a
través de triangulación vía GSM.
Al evaluar el comportamiento del sistema en un ambiente de pruebas, se logró establecer
comunicación entre 4 dispositivos para el envío de tramas de texto entre un usuario y la plataforma
de gestión web. El sistema durante el tiempo transcurrido en la prueba permitió capturar datos
básicos de 15 usuarios, sin registro de perdidas, retardos o desconexión de los dispositivos
2
Introducción
Las estructuras confinadas que actualmente se están desplegando en Colombia, tales
como: minas y túneles, representan riesgos críticos para la vida humana, debido a las condiciones
de inseguridad implícitas en este tipo de ambientes agresivos, por lo cual se hace necesario
sustentarse en el desarrollo tecnológico para mitigar el riesgo de exposición de las personas que
transitan o laboran en estas construcciones, ante cualquier situación de emergencia generada por
causas naturales o asociadas a actividades humanas.
Según cifras de accidentalidad incluidas en los informes del fondo nacional de prevención
vial, FASECOLDA (Federación de Aseguradores Colombianos) y Medicina Legal, se evidencia
el aumento año tras año en las tasas de siniestros relacionados a estos incidentes, alcanzando tan
solo en el sector minero y de transporte cifras alarmantes del 12.90% (accidentes de trabajo en
Colombia en cifras,2018).
El papel de las telecomunicaciones en la gestión y control de riesgos es pilar fundamental
para el diseño de nuevos mecanismos que permitan la inmediatez en la atención o mitigación de
accidentes durante situaciones de emergencias (Direccion de Gestion y desempeño institucional,
2018). La falta de canales de comunicación desarrollados sobre plataformas tecnológicas que
soporten y brinden mecanismos de reacción inmediata y eficiencia del canal durante eventos de
emergencias, aportan cada vez más al aumento significativo de estas tasas.
En base en las tecnologías inalámbricas de transmisión Bluetooth (BLE Bluetooth Low
Energy), que permiten obtener un bajo consumo de energía, se pueden establecer canales
bidireccionales de comunicación aptos para este tipo de ambientes con un bajo costo de
implementación.
3
Estado del Arte: Sistemas de comunicación para túneles
Desde hace algunas décadas los sistemas de comunicación han tenido una inmensa
transformación, con el desarrollo de tecnologías de información y la globalización en las
telecomunicaciones los sistemas de comunicación se han visto afectados de una forma generosa
para los usuarios de las diferentes plataformas, en este caso se explicará el uso de estas nuevas
tecnologías en la implementación de túneles donde se pueden aprovechar mejor los beneficios de
estos sistemas en aras de una movilidad más segura sostenible, eficiente y confortable.
Sistemas ITS
Son la pieza clave para ofrecer soluciones inteligentes (aplicaciones) a infraestructura de
transporte, estos sistemas aplican tecnologías de la información y las comunicaciones con la
finalidad de brindar beneficios a la gestión y control del tráfico y la movilidad.
Es importante tener en cuenta que el término ITS se puede interpretar de varias maneras y puede
abarcar todas las tecnologías que tiene el transporte.
La esencia de ITS es la información, ya sean con datos estáticos o en tiempo real, ya sea en
espacios públicos como en internet y se basa en la recolección, procesamiento, integración y
provisión de dicha información para la toma de decisiones en forma inteligente. (Russomanno,
2012)
4
Los elementos que se utilizan en estos sistemas de información enfocados en el transporte son:
Fig. 1. Elementos de un sistema de información,
Fuente: Suarez Florez, M. (2001). Los sistemas inteligentes de transporte ITS . Ciencia e Ingeniería Neogranadina 2001 (10), 42.
A continuación, en la Figura 2 se puede visualizar la arquitectura de un ITS para túneles, donde
se describe los niveles de forma jerárquica para el diseño e implementación en:
Fig. 2. Arquitectura ITS Túneles. Fuente: Russomanno, I. D. (Septiembre de 2012). http://www.aates.org.ar. Obtenido de
http://www.aates.org.ar/images/eventos/2012-jor2/pdf/10-Daniel-Russomanno.pdf
Los sistemas ITS en túneles son de gran variedad y a su vez importantes para la seguridad y el
buen manejo de la información a su vez también existen subsistemas los cuales se pueden
observar en la Figura 3:
5
Fig. 3. Sistemas y subsistemas ITS en Túneles. Fuente: Vidal, D. A. (s.f.). https://es.slideshare.net/diegoamv/presentacion-isa-its-
final. Obtenido de https://es.slideshare.net/diegoamv/presentacion-isa-its-final
Instrumentación de túneles utilizando ITS:
1. Gestión e integración: Hoy en día no se puede percibir estos sistemas como se hacía
antiguamente, es decir, como subsistemas independientes puesto que no se tiene un control
coordinado de toda la instalación desde una única interface del usuario, permitiendo tener
el operador una visión general y global (monitoreo, alarmas) lo que permite un control
completo de la instalación.
Este control se debe hacer centralizado por medio de un centro de control como se puede
observar en la Figura 4, el cual puede estar ubicado en un edificio o instalación propia para
estos trabajos, igualmente en la Figura 5 se observa los servicios a los cuales el centro de
control realiza gestión centralizada.
6
Fig. 4. Ejemplo centro de control de calle 30 Fuente: Russomanno, I. D. (Septiembre de 2012). http://www.aates.org.ar. Obtenido de http://www.aates.org.ar/images/eventos/2012-jor2/pdf/10-Daniel-Russomanno.pdf
Fig. 5. Ejemplo se servicios a los cuales el centro de control realiza gestión y monitoreo. Fuente: Russomanno, I. D.
(Septiembre de 2012). http://www.aates.org.ar. Obtenido de http://www.aates.org.ar/images/eventos/2012-jor2/pdf/10-Daniel-Russomanno.pdf
2. Detección de incendios: Un ejemplo es el uso de cable Sensor fibrolaser el cual determina
la detección precisa del fuego, este elemento entrega información de aumento específico
de temperatura, dirección de propagación, extensión y evolución del incendio y ofrece la
posibilidad de sectorizar.
7
Tiene cubierta LSZH y tubo de acero inoxidable, no es contaminante y provee inmunidad
contra influencias ambientales como los son la humedad, calor frio, interferencia
electromagnética, etc.
Es libre de mantenimientos, tiene un controlador que abarca hasta 4000m.
El sistema de control también opera por superación de límites de seguridad en otras variables
como la opacidad, concentración CO y tiente en cuenta las cámaras del CCTV.
Fig. 6. Ejemplo de cables detectores de incendios: Fuente: Russomanno, I. D. (Septiembre de 2012).
http://www.aates.org.ar. Obtenido de http://www.aates.org.ar/images/eventos/2012-jor2/pdf/10-Daniel-Russomanno.pdf
3. CCTV: El uso de circuitos cerrados de televisión brinda una supervisión a través de un
puesto del operador donde se puede hacer la verificación de cualquier accidente o incidente
que ocurra en el túnel o fuera de él.
Se emplean tecnologías de procesamiento digital de señal de video como DAI que es la
Detección Automática de Incidentes.
Para este tipo de circuitos se usan equipos de última tecnología y con protección adecuada
para cualquier tipo de ambiente.
Fig. 7. Ejemplo detección e accidentes por CCTV: Fuente: Russomanno, I. D. (Septiembre de 2012).
http://www.aates.org.ar. Obtenido de http://www.aates.org.ar/images/eventos/2012-jor2/pdf/10-Daniel-Russomanno.pdf
8
4. Llamadas por altavoz (megafonía): Comunicación entre el personal que opera la sala de
control con los usuarios del túnel, esto con el fin de dar instrucciones para evacuaciones,
congestión o emergencias.
Igualmente, en la figura 8 se puede observar la arquitectura de un sistema de megafonía
utilizado en implementación des ITS para tunéeles en Argentina:
Fig. 8. Subsistema Megafonía en túneles. Fuente: Russomanno, I. D. (Septiembre de 2012). http://www.aates.org.ar.
Obtenido de http://www.aates.org.ar/images/eventos/2012-jor2/pdf/10-Daniel-Russomanno.pdf
5. Telefonía de emergencia (SOS): Atiende las necesidades de comunicación que se generan
en el interior de los túneles entre usuario y centro de control, el operador es quien toma la
decisión de con qué sistema de seguridad (bomberos, policía, etc.) comunicarse de acuerdo
a la falla o eventualidad que se presente en el túnel.
En la figura 9 Se puede observar un ejemplo de subsistema SOS empleado en Argentina en el
cual podemos visualizar la arquitectura y distribución de equipos y elementos:
9
Fig. 9. Ejemplo ITS: Subsistema SOS para túneles. Fuente: Russomanno, I. D. (Septiembre de 2012).
http://www.aates.org.ar. Obtenido de http://www.aates.org.ar/images/eventos/2012-jor2/pdf/10-Daniel-Russomanno.pdf
6. Telefonía corporativa: Atiende la comunicación que se necesite entre personal
administrativo en las instalaciones de los túneles y la red conmutada y viceversa, siendo
estos sistemas telefónicos independientes uno del otro.
7. Radiocomunicaciones: Es el que permite la comunicación de señal radiofrecuencia entre
el centro de control, servicios de carretera, unidades de seguridad y mantenimiento.
También brinda servicios informativos a estas unidades, como también brindan
información al usuario el cual debe sintonizar la frecuencia respectiva para que exista
comunicación.
10
En la figura 10 se puede visualizar los subsistemas de radiocomunicaciones:
Fig. 10.Subsistemas de radiocomunicaciones ITS para túneles: Fuente: Russomanno, I. D. (Septiembre de 2012). http://www.aates.org.ar. Obtenido de http://www.aates.org.ar/images/eventos/2012-jor2/pdf/10-Daniel-
Russomanno.pdf
8. Monitoreo de trafico: Entrega por cada carril de circulación lo siguiente:
- Medición de velocidad.
- Ocupación.
- Número de vehículos por unidad de tiempo.
- Clasificación de vehículos.
9. Subsistema de posicionamiento geográfico: Receptor GPS que captara tantas posiciones
diferentes como antenas interior/exterior existan a lo largo del túnel, como se puede
observar en la figura 11.
11
Fig. 11. Ejemplo Subsistema GPS en túneles. Fuente: Russomanno, I. D. (Septiembre de 2012).
http://www.aates.org.ar. Obtenido de http://www.aates.org.ar/images/eventos/2012-jor2/pdf/10-Daniel-Russomanno.pdf
10. Sistema de señalización variable y semáforos: Apoya la circulación de vehículos y brida
información a los usuarios de las condiciones de los túneles, se puede observar un ejemplo
en la Figura 12.
Fig. 12. Ejemplo señalización ITS en túneles. Fuente: FCC Industrial. (11 de Julio de 2016).
http://www.fccindustrial.com. Obtenido de http://www.fccindustrial.com/es/-/fcc-industrial-instalara-los-sistemas-de-seguridad-e-iluminacion-del-tunel-la-aldea#
Lo anterior combinado con sistemas de control y ventilación ofrecen mayor seguridad al usuario
en el túnel.
12
Capítulo 1
Características de Transmisión Bluetooth
La tecnología Bluetooth consiste en la transferencia de datos y voz entre dispositivos (teléfonos
celulares, computadores, impresoras, módems, etc.) a corta distancia. Bluetooth se rige por el
estándar IEEE 802.11 para LAN inalámbrica y 802.15 para caracterización propia de la tecnología,
recibe y transmite en la frecuencia de 2,4 GHz en saltos de 1 MHz disponible en todo el mundo.
Capa Física
Para la transmisión de información esta tecnología emplea la modulación GFSK (Gaussian
Frequency Shift Keying) la cual otorga velocidades de transmisión del orden de 1Mbps. Utilizando
la modulación GFSK donde el código binario 1 representa la desviación positiva de la portadora
de la frecuencia y el 0 la desviación negativa, al ser enviado cada paquete, los dispositivos hacen
una re-sincronización con el fin de saltar de canal en canal, de esta forma los dispositivos Bluetooth
utilizan toda la banda de 2,4 GHz reduciendo la interferencia entre canales.
La transmisión por medio de saltos de frecuencia (FHSS o frequency hopping) donde el canal
se divide en intervalos de 625μs denominado slots, da lugar a un salto de frecuencia de 1600
veces/seg, donde los paquetes de datos ocupan un slot para emisión y otro para recepción.
El consumo de potencia está especificado por diferentes clases relacionadas en la siguiente tabla:
Clases de dispositivos bluetooth
Clase Potencia Alcance
1 100mW (20dBm) 100m 2 2,5mW (4dBm) 10m 3 1mW (0dBm) 10cm – 1m
Tabla 1.1 Clases de dispositivos Bluetooth
13
Estructura del protocolo
La definición y arquitectura del protocolo, de acuerdo a la estandarización IEEE 802.15 se
define en dos grandes estructuras para el funcionamiento de la tecnología bluetooth. Cada una de
ellas detalla los componentes físicos y los protocolos de bajo y alto nivel.
Figura 1.1 Asignación protocolo Bluetooth dentro del Modelo OSI (Fuente estándar 802.15 IEEE)
Baseband
Define y estructura el modelamiento y procesamiento de los datos entre las capas superiores
y la capa inferior, es decir, el nivel del protocolo Baseband o BB se encarga de segmentar la
información o tramas de datos que vienen de los protocolos superiores como L2CAP o
RFCOMM en tramas ajustables a los slots de tiempos definidos. De igual manera gestiona y
sincroniza los diferentes tipos de conexiones generadas entre dispositivos bluetooth a nivel de
saltos de frecuencia, tamaño de tramas a enviar o recibir y mecanismos de control de errores.
Los tipos de conexiones generadas entre dispositivos bluetooth pueden ser: punto a punto
o punto a multipunto, estas últimas definidas como piconets requieren de un sincronismo
controlado a través de frecuencias (Garcia, 2017) donde un dispositivo actúa como maestro,
14
administrando las frecuencias utilizadas y el reloj, mientras que los demás dispositivos actúan
como esclavos que solamente reciben y adaptan .
Figura 1.2 Sincronización maestro – esclavo Fuente: García, Alejandro. 2017. Bluetooth.
Como se observa en la Figura 1.2 al ser asignado un salto de frecuencia por el maestro, los
esclavos sincronizan al dispositivo maestro en tiempo y frecuencia siguiendo la frecuencia de
saltos del dispositivo maestro (Garcia, 2017).
En la parte física de la sincronización, los dispositivos utilizan TDD (Time división dúplex)
como técnica de acceso al medio, para compartir los mensajes entre dispositivos. Cada mensaje
utiliza un slot de tiempo asignado a uno de los 79 canales disponibles dentro del rango de
frecuencia 2.4Ghz.
Los enlaces lógicos generados en este nivel del protocolo, obedecen a dos grandes grupos: SCO
(Synchronous Connection-Oriented) y ACL (Asynchronous Connection-Less)
- SCO: Define enlaces punto a punto orientados a la conexión de manera síncrona,
normalmente definidos para canales de voz con tasas de transmisión de 64 Kbps
- ACL: Generalmente utilizado para enlaces punto a multipunto en redes tipo piconets, se
conoce como una red de conmutación de paquetes de asíncrona aprovechando de mejor
manera los time slots logrando tasas de transmisión mucho más altas.
15
- Para las piconets, el establecimiento de enlaces de manera asíncrona permite crear
conexiones SCO entre los dispositivos, teniendo un total de 3 SCO y 1 ACL entre maestro
y cada esclavo.
Estados de operación
Dentro de la misma capa BB (Baseband) los dispositivos bluetooth manejan una serie de
estados que les permiten interactuar entre ellos independientemente del enlace generado o la
topología de conexión.
Podemos denotar dos estados principales: Standby y Connection (Moron Fernadez, 2008)
donde cada uno de ellos se subdivide en otra serie de estados que cumplen tareas específicas en el
establecimiento de una conexión.
Standby es un estado de espera de bajo consumo energético en el cual el dispositivo solo está
escuchando hasta recibir el cambio de estado o instrucción de otro dispositivo. Para salir de este
estado y pasar a modo Connection se utilizan los subestados inquiry, inquiry scan, page, page
scan, slave response y master response. De esta manera, el subestado inquiry desencadena la
búsqueda de otros dispositivos dentro del alcance junto con la solicitud de datos necesarios para
generar el establecimiento de la conexión así otro dispositivo debería ajustarse en el subestado
inquiry scan para recibir la solicitud de cambio de estado desde un dispositivo remoto.
El resto de estados cumplen la función de intercambiar información necesaria como las
direcciones físicas de cada dispositivo o la sincronía del reloj, en el momento en que estos
procedimientos se completan el dispositivo que inicio las solicitudes pasa a ser el maestro y el otro
dispositivo el esclavo, utilizando entonces los subestados master response y slave response
respectivamente.
16
Dentro del estado Connection se destacan 3 subestados más que atañen al funcionamiento
propio de la comunicación bluetooth.
- Active: Gestión de la información entre maestro y esclavo intercambiando constantemente
las direcciones físicas y agregándolas a la cabecera de la trama enviada, se gestiona también
la utilización de slots y frecuencias disponibles.
- Sniff: Es un mecanismo para reducir el tiempo de escucha entre maestro-esclavo, clave en
el consumo de energía innecesaria. El maestro es quien establece el tiempo de escucha de
cada uno de los esclavos utilizando slots ligeramente espaciados
- Hold: Se utiliza como complemento al estado sniff, donde se interrumpe
momentáneamente el envío de paquetes con el fin de optimizar el consumo y
procesamiento del maestro.
Existen una serie de estados más que apoyan en la creación y unión de varias piconets, este
concepto se conoce como scatternet, sin embargo, este concepto no se desarrollara por el momento
en la investigación.
LM (Link Manager)
La siguiente capa estipula el funcionamiento y control de los enlaces SCO y ACL creados en
la capa anterior de manera que está proporciona control a nivel de latencia, ancho de banda y
tiempo de comunicación entre maestro y esclavo enviando información necesaria a la siguiente
capa de aplicación L2CAP.
En esta capa se encuentra factores como el RSSI o Tpoll, factores que ayudan a la
determinación de cualidades como el nivel mínimo de señal para recepción (RSSI Received Signal
Strength Indicator) o el tiempo exacto que tiene cada maestro para comunicarse con un esclavo en
17
un tiempo de operación normal (Tpoll). Estos conceptos se desarrollarán más a profundidad en
apartados siguientes a este capítulo.
HCI (Host Controller Interface)
Esta es una capa de nivel superior y agrupa protocolos como L2CAP o los diferentes perfiles
existentes en bluetooth. Proporciona una serie de comandos de acceso a las demás capas para
administrar las cualidades de un controlador. Se pueden encontrar comandos para el registro,
obtención de información, determinar el tipo de enlace o tramas enviadas (ACL, SCO),
vinculación y desvinculación de dispositivos.
Dependiendo del equipo que actué como controller bluetooth el acceso y cualidades del HCI
controller cambia. Para la manipulación y gestión de cualquier proceso bluetooth, este es el pilar
o punto de partida a nivel de configuración o administración de interfaces bluetooth (Moron
Fernadez, 2008)
L2CAP (Logical Link Control and Adaptation Protocol)
Protocolo de más alto nivel dentro de la estructura bluetooth, se encarga de la gestión,
administración y operación de la información de cara a la capa de aplicación del funcionamiento
de la tecnología inalámbrica. Provee parámetros que son negociables con las capas inferiores o
con la misma capa en un dispositivo adyacente.
Entre sus principales funciones se encuentra:
- Multiplicación de protocolos y perfiles
- Segmentación de información en tramas
- Gestión de grupos de nivel superior para piconets.
- Calidad de servicio en el intercambio de información entre dos capas L2CAP.
18
La gestión más destacable del protocolo es la de la calidad de servicio QoS, donde se estipulan
ciertos parámetros necesarios para la transmisión de información como:
- Tipo de servicio
- Tasa de envío en bytes por segundo
- Tamaño de buffers en bytes
- Límite de velocidades de transmisión
- Latencia
- Retardos
Estos parámetros se configuran en función de la información obtenida en capas inferiores, sin
embargo, algunos de ellos como la latencia o los retardos en transmisión son parámetros que van
más definidos por la capa física que por aspectos configurables de un controlador.
Perfiles de Bluetooth
Los perfiles son parte esencial de la tecnología Bluetooth, ya que aseguran la interoperabilidad
entre las aplicaciones y dispositivos externos, definen roles y capacidades sobre las aplicaciones.
Por normatividad, todos los dispositivos Bluetooth deben soportar el perfil GAP (Perfil de acceso
genérico) como mínimo recurso dado que se encarga de encontrar y descubrir dispositivos,
procedimientos de conexión y de niveles de seguridad.
Perfil de acceso genérico (GAP). El perfil GAP custodia la base de los perfiles de Bluetooth y
define los medios que determinan el eslabón existente entre la banda base y los dispositivos
Bluetooth, de igual forma define también:
- Características generales de Bluetooth.
- Procedimientos para descubrir y enlazar dispositivos Bluetooth.
19
El propósito del perfil GAP es asegurar intercambio de información sin tener en cuenta el
fabricante o la aplicación.
Perfil de intercambio genérico (GOEP). El perfil GOEP permite la transferencia de objetos entre
dispositivos (fotos, documentos, audio, etc.). Cuenta con dos papeles definidos, un servidor, el
cual define la situación de envió de un objeto y un cliente que comienza la interacción del
servicio. Este perfil tiene dependencia del perfil SPP.
En esencia, el perfil es inexistente, sin embargo, describe cómo las aplicaciones definen los
objetos que se van a transmitir y cómo se debe llevar a cabo el procedimiento, esto se hace
mediante los perfiles dependientes, es decir, OPP (Perfil de envío de objetos), FTP (Perfil de
transferencia de archivos) y SYNC (Perfil de sincronización).
Perfil de transferencia de archivos (FTP). El perfil FTP tiene la capacidad de transferir datos por
medio de un dispositivo celular, PDA’s, etc., estos datos pueden ser .xls, ppt, jpg, etc.
Perfil de puerto serial (SPP). Define la estructura de los puertos seriales virtuales y conecta
varios dispositivos Bluetooth, se basa principalmente en la especificación ETSI TS07.10 y
emplea el protocolo RFCOMM. Es capaz de mantener un reemplazo inalámbrico para el puerto
de serie RS-232. La transmisión de información bajo este protocolo ofrece ventajas de operación
y administración que otros perfiles no ofrecen.
Perfil de acceso al descubrimiento del servicio (SDAP). Descubre servicios desde un dispositivo
remoto, con el fin de que cualquier dispositivo tenga conocimiento de la disponibilidad de los
servicios que desee adquirir.
Emplea una búsqueda para conocer y especificar los servicios por medio de un sistema de envío
y recibo de preguntas entre dispositivos.
20
Perfil de gestión de redes por vía telefónica (DUN). Este perfil proporciona acceso a Internet y
otros servicios que requieran del uso de vía telefónica, por ejemplo, el acceso mediante una
laptop o un modem. Se basa en SPP e incluye el comando AT dictaminado en ETSI 07.07 y PPP.
Este perfil describe dos papeles, el Gateway, quien mantiene el acceso de la red al dispositivo y
los dispositivos terminales.
Perfil de envío de objeto (OPP). Define los papeles de envío del servidor y el cliente, los cuales
son análogos y se deben inter operar con el servidor y el cliente.
Perfil de sincronización (SYNC). Es empleado junto con GOEP para sincronizar el calendario y
la información de dirección entre dispositivos Bluetooth. Es mayormente utilizado para
intercambiar datos entre un PDA y una computadora, por último, este perfil define los clientes y
especifica los roles del servidor (Garcia, 2017).
La utilización de un perfil u otro depende únicamente del propósito que se le vaya a dar a las
interfaces bluetooth, de manera que, en función del dispositivo, tipo de información y condiciones
generales del ambiente se determinara el perfil o perfiles a utilizar. Aunque típicamente algunas
soluciones e interfaces Bluetooth ya estipularon los perfiles necesarios para el funcionamiento, por
ejemplo, los mandos a distancia, consolas y dispositivos de audio, estos ya definen los perfiles
específicos necesarios para su funcionamiento. Solo en caso de nuevas soluciones o enfoques
alternativos a los ya previstos es necesario determinar el perfil adecuado a implementar.
21
Retardo de Transmisión
Para el funcionamiento de dispositivos bluetooth y en específico para su aplicación es necesario
validar tanto la atenuación como el retardo de transmisión. En aplicaciones en las que estos factores
sean vitales para la calidad de la aplicación, se expone la metodología existente para el cálculo del
retardo de transmisión, puesto que, para la atenuación y dada las condiciones y cualidades físicas
de la transmisión, esta se puede calcular de manera sencilla a través de las diferentes clases
Bluetooth expuestas anteriormente.
En el momento de realizarse una transmisión entre dispositivos Bluetooth es común que existan
retardos en caso de que el flujo de información transmitida sea de maestro a esclavo. El siguiente
método se calcula únicamente para el retardo de transmisión hasta la capa BB. Dependiendo de la
cantidad de bytes u octetos se debe definir los componentes del retardo, es decir, tACK(N), que
corresponde al tiempo de transmisión y confirmación de cada paquete necesario para enviar N
octetos de datos y es calculado mediante la siguiente expresión (Moron Fernadez, 2008):
𝑡𝑡𝐴𝐴𝐴𝐴𝐴𝐴(𝑁𝑁) =
⎩⎪⎪⎨
⎪⎪⎧
0 𝑁𝑁 = 02 ∙ 𝑇𝑇𝑆𝑆 0 < 𝑁𝑁 ≤ 𝐿𝐿14 ∙ 𝑇𝑇𝑆𝑆 𝐿𝐿1 < 𝑁𝑁 ≤ 𝐿𝐿36 ∙ 𝑇𝑇𝑆𝑆 𝐿𝐿3 < 𝑁𝑁 ≤ 𝐿𝐿5
6 ∙ 𝑇𝑇𝑆𝑆 ∙ �𝑁𝑁𝐿𝐿5� + 𝑁𝑁 > 𝐿𝐿5
+𝑡𝑡𝐴𝐴𝐴𝐴𝐴𝐴(𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝐿𝐿5)
Donde,
Ts es la duración de un slot Bluetooth (625 μs).
L1, L3 y L5 son las longitudes máximas del payload de un paquete de 1, 3 o 5 slots, es decir,
27, 183 y 339 octetos respectivamente.
22
tTX(N), corresponde al tiempo de transmisión de N octetos obviando el tiempo de confirmación
del último paquete en el cual va transportado el ultimo fragmento del mensaje. Es posible
determinarlo mediante la siguiente ecuación:
𝑡𝑡𝑇𝑇𝑇𝑇(𝑁𝑁) =
⎩⎪⎨
⎪⎧
0 𝑁𝑁 = 0𝑛𝑛𝑏𝑏(𝑁𝑁) ∙ 𝑡𝑡𝑏𝑏 0 < 𝑁𝑁 ≤ 𝐿𝐿5
𝑡𝑡𝐴𝐴𝐴𝐴𝐴𝐴(𝐿𝐿5) ∙ �𝑁𝑁𝐿𝐿5� + 𝑁𝑁 > 𝐿𝐿5
+𝑡𝑡𝑇𝑇𝑇𝑇(𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝐿𝐿5)
Donde,
tb es el tiempo de transmisión de un bit, 1μs (debido a la transmisión de 1Mbps).
nb(N) es el número de bits transmitidos en el último fragmento.
nb(N) puede expresarse de la siguiente manera:
𝑛𝑛𝑏𝑏(𝑁𝑁) = 𝑛𝑛𝑑𝑑(𝑁𝑁) + 𝐶𝐶𝐵𝐵𝐵𝐵
Donde,
CBB es la suma de los bits de cabecera del paquete.
nd(N) es el número de bits del campo de datos.
nd(N) puede expresarse de la siguiente manera:
𝑛𝑛𝑑𝑑(𝑁𝑁) = �𝑁𝑁 + 𝐶𝐶𝑑𝑑𝑑𝑑(𝑁𝑁) + 2� ∙ 8
Donde,
Cdf(N) es el número de octetos correspondiente a la cabecera del payload según la siguiente
expresión:
𝐶𝐶𝑑𝑑𝑑𝑑(𝑁𝑁) = �1 𝑁𝑁 ≤ 𝐿𝐿12 𝐿𝐿1 < 𝑁𝑁 ≤ 𝐿𝐿5
Analizando las expresiones matemáticas e identificando que la mayoría de ellas tienen que ver
con la cantidad de octetos representados por N y de los slots de tiempo utilizados, para el cálculo
de retardo en transmisiones donde no se ocupe más de un slot y el tamaño de los octetos no supere
23
el establecido, el retador será igual al tiempo de slot que es 625us por lo que el retardo para una
transmisión de dos slots el retardo seria de 1,25ms.
Propagación de señales bluetooth
Dependiendo del dispositivo bluetooth, este tendrá diferentes tipos de antena que a su vez tienen
diferentes tipos o modos de propagación de la señal, hablando netamente del factor físico de esta.
La potencia de estas viene estrictamente especificada en la tabla 1.1 Clases de dispositivos
bluetooth donde dependiendo de la clase elegida, la potencia varía entre 0 dBm hasta 24 dBm. La
propagación de su señal funciona de manera similar a cualquier tecnología de propagación en
especio libre, susceptible a atenuaciones por distancia, potencia o interferencias en línea de vista
si hablamos de conexiones punto a punto.
Las pérdidas por propagación en espacio libre están determinadas por la siguiente ecuación
(UIT-R P.525-2, 1994):
𝑙𝑙𝑙𝑙𝑙𝑙 = 32, 4 + 20𝑙𝑙𝑁𝑁𝑙𝑙𝑙𝑙 + 20𝑙𝑙𝑁𝑁𝑙𝑙𝑁𝑁
Donde,
lfs = perdida por espacio libre en dB
f = frecuencia en MHz
d = distancia en Km
Sin embargo, las especificaciones de bluetooth ya indican las distancias máximas tolerables a
atenuaciones según las clases de bluetooth, entonces, para efectos de calcular interferencias
causadas por ambientes externos se realiza un proceso de determinación a través del cálculo del
BER (Bit error rate) o el cálculo del coeficiente de interferencia de señal (SIR)
24
El protocolo bluetooth tiene mecanismos que ya actúan en función de evitar la pérdida de
paquetes y la disminución del SIR, esto debido a que por la frecuencia en la que opera, es
vulnerable a muchas interferencias de otras tecnologías que funcionan sobre la misma frecuencia,
como el WLAN (Wireless Local Area Network) definida en el estándar 802.11 de la IEEE.
Infraestructura de un túnel
La infraestructura por la que se constituye un túnel no está determinada de una manera concisa,
por lo cual su figura no se puede determinar con una representación geométrica normal como un
cubo o cilindro, sin embargo, la geométrica que describiría de manera correcta la infraestructura
de un túnel es la del arco, ya que este soporta fuerzas desde todas las direcciones según describe
(Aranciba, 2011)
Figura 2.1 Representación Geométrica Túnel tipo arco
(Fuente: Deguaque Pierre, Molina-García-Pardo José, Wireless Communication in tunnels) Su construcción consta básicamente de concreto reforzado semi-perforado como material
principal de construcción, además de vigas soportes y subsistemas civiles (Arias & Diaz, 2016) de
soporte que no son objetos de estudio para esta investigación, sin embargo, el concreto con el que
se construye un túnel si es materia de estudio debido a sus cualidades de absorción de señales o
potencia eléctrica, tradicionalmente descritas como permeabilidad eléctrica o conductividad propia
del material.
25
Para determinar la permeabilidad o conductividad de un material no común como en este caso el
concreto que está compuesto de varios materiales, el proceso debe realizarse experimentalmente,
a través de la teoría de la permeabilidad del vacío expresada por el valor
𝑇𝑇𝑁𝑁/𝐴𝐴 A través de una sonda de hall, un teslametro y entendiendo la teoría de comportamiento de campos
electromagnéticos se puede determinar un coeficiente para el material dada la fórmula:
𝑢𝑢𝑢𝑢 =𝑢𝑢𝑢𝑢0
Donde,
Ur = permeabilidad relativa del material
U = Permeabilidad medida
U0 = permeabilidad del vacío
Se determina si el material pertenece a una de las siguientes ramas:
Ferromagnéticos: Si ur es mayor o superior a 1
Paramagnéticos: Si ur es igual o aproximadamente igual a 1
Diamagnéticos: Si ur es menor o inferior a 1
Sin embargo, para efectos de comprobación se toman datos relativos dados en estudios
anteriores para el comportamiento de señales dentro de túneles determinados de la siguiente
manera (Degauque & Molina-Garcia-Pardo, 2012):
Ur = permeabilidad relativa de túneles en concreto equivalente al coeficiente 5
ɸ = Conductividad en túneles de concreto equivalente a 10exp-2 S/m
26
Propagación de señales en un túnel
Tanto como la infraestructura de un túnel y el comportamiento normal de una señal inalámbrica
tienen factores adicionales que complementan la propagación de una señal a través de un túnel,
como se expresa en (Degauque & Molina-Garcia-Pardo, 2012) existen varios modelamientos para
el estudio de propagación de una señal inalámbrica en este tipo de infraestructuras, la teoría modal
y la teoría de rayos ofrecen dos alternativas a la descripción de una señal dentro de un túnel.
El estudio realizado en (Degauque & Molina-Garcia-Pardo, 2012) compara la infraestructura
de un túnel con la forma de una guía de onda, razonamiento principal utilizado para el estudio de
señales, sin embargo, la composición estructural de un túnel como su sección transversal o corte
longitudinal distan mucho de la cualidades de una guía de onda como su material dieléctrico o
impedancia característica, factores claves en la propagación de una señal y que afectan
directamente la energía transmitida, los modos de propagación y la atenuación de una señal
(Loranca Ramos, 2003)
La propagación de una señal vista desde el punto de la atenuación, difracción o reflexión de la
misma, requiere del cálculo de estas variables determinando factores propios del ambiente donde
se propague, factores como:
• Frecuencia de operación o longitud de onda
• Permeabilidad y Conductividad del medio
• Distancia entre Tx y Rx
• Modos para campo eléctrico y magnético
• Polaridad
Y para el caso de estudio específico de un túnel, se deben tener en cuenta factores como:
• Sección transversal
27
• Altura y anchura
• Permeabilidad o conductividad del material de construcción
De acuerdo a los estudios realizados por (Degauque & Molina-Garcia-Pardo, 2012) se describe
una ecuación general para el cálculo de la atenuación en túneles que se indica a continuación:
𝛼𝛼𝑚𝑚𝑚𝑚 = 2𝑎𝑎
�𝑁𝑁𝑚𝑚2𝑎𝑎
�2
�1
√𝑈𝑈𝑢𝑢 − 1� +
2𝑏𝑏�𝑛𝑛𝑚𝑚2𝑏𝑏�2
�𝑢𝑢𝑢𝑢
√𝑈𝑈𝑢𝑢 − 1�
Donde,
a = anchura de la infraestructura del túnel
b = altura de la infraestructura del túnel
m= modo eléctrico
n = modo magnético
λ = Longitud de onda
Ur = Permeabilidad del material
La ecuación nace del análisis de la longitud de onda de una señal analizada en cada uno de sus
modos por las dimensiones de un túnel y cada uno de estos factores multiplicados por la
permeabilidad del material de un túnel. La distancia no se tiene en cuenta aun, pues la ecuación
intenta describir el comportamiento de los modos de propagación en condiciones específicas
dadas.
Según las condiciones de permeabilidad y conductividad mencionadas anteriormente y
tomando como medidas de estudio un túnel de anchura a = 4.5m y alto b = 4m y una frecuencia
de muestreo de 2.4Ghz donde las antenas de Tx y Rx tienen una separación de 1Km y están
ubicadas en la mitad de la sección transversal de un túnel, la aplicación de la ecuación permite
demostrar la perdida de una señal según su modo en dB/Km, para lo cual se obtuvo:
28
Atenuación para varios modos de propagación n = 1 n = 2 n = 3
m = 1 4.6 dB 17 dB 38 dB m = 2 6 dB 18 dB 40 dB m = 3 8 dB 21 dB 42 dB
f = 2.4 GHz Tabla 1.2 atenuación para varios modos de propagación híbridos
fuente: Degauque & Molina-García-Pardo “Wireless Communication in Tunnels”, 2012 Solo se expresan los 3 primeros nodos, al ser considerados como ortogonales (Lienard, Molina-
Garcia-Pardo, & Degauque, 2006) serán los únicos modos que tendrán participación en el total de
la señal recibida, sin embargo, los 60 primeros modos también son considerados como ortogonales
o simétricos entre sí, lo cual para efectos de calidad de la señal, afecta al modo de propagación.
De estos resultados podemos concluir que en los 3 primeros modos como atenuación máxima
obtenemos un nivel de 42dB sobre un kilómetro longitudinal. La estructura del túnel en sí, sin
tener en cuenta las fuentes de ruido, reflexión o difracción como los vehículos que transitan, no
afecta los modos de propagación de gran manera, permitiendo que estos resultados sean avalados
como funcionales dentro del estudio de propagación.
La infraestructura de un túnel no siempre es exacta, por lo cual la aplicación de las ecuaciones
tiende a variar dependiendo, la anchura, altura o sección transversal, al igual que la ubicación de
las antenas. No es objeto de este estudio determinar el cálculo de todas las variables en todos los
casos de aplicación.
Para sistemas bluetooth, donde dadas las diferentes clases el alcance máximo de una señal esta
por el orden de los 100m para bluetooth clase 1 sobre estándar 4.0 con una potencia máxima de
20dBm, se habla de una sensibilidad máxima de -70dBm para un BER del 0.1% (Franco, 2007)
por lo cual con el modelo anterior y una perdida máxima de 42dBm, los dispositivos siguen
teniendo línea de vista electromagnética, sin embargo, el estándar 802.15 IEEE establece una
29
distancia máxima de 100m dadas las características de transmisión de un dispositivo convencional,
que en la mayoría de los casos, no llega a los 20dBm de potencia.
La siguiente grafica tomada del estudio realizado en (Degauque & Molina-Garcia-Pardo, 2012)
muestra la atenuación en función de la distancia, pero esta vez agregan el ruido generado por
diferentes fuentes como los vehículos que transitan a diario en un túnel.
Figura 2.2 Grafica atenuación vs distancia sobre teoría de rayos para la propagación en un túnel
(Fuente: Liernard & Deguaque “Propagation in wide tunnels at 2 GHz”, 1998) La grafica representa valores arbitrarios de atenuación sobre una distancia determinada,
expuestos a factores de reflexión o difracción comparado con una gráfica “b” que corresponde al
modelo de propagación sobre un espacio libre.
Si bien el estudio es detallado, arroja como conclusiones que las medición y modelos
matemáticos realizados sobre un túnel, son imprecisos, en la medida que se quiera determinar de
la manera más exacta el cálculo de las variables, siempre habrá factores externos como: la
infraestructura de un túnel en específico. la cantidad de tráfico o el tipo y polarización de la antena
que afecten y modifiquen el comportamiento de una señal.
30
Retardo de transmisión en túneles
Del apartado retardo de transmisión, descrito anteriormente, se explica que el retardo está en
función del tiempo de duración de cada slot de información enviada o recibida, de esta manera el
retardo de un paquete viene dado únicamente por la cantidad de slot usados para su transmisión.
Para el desarrollo sobre túneles cambia la forma de cálculo para un retardo, puesto que en estos
casos donde factores externos a una comunicación maestro-esclavo como la atenuación o ruido
generado en un túnel, el cálculo se determina a través de la probabilidad de error de bit por medio
del cálculo de la relación SNR (Signal Noise Relation) o relación señal a ruido.
Así el cálculo del SNR aplicado a las fórmulas de probabilidad de error de bits permiten
determinar el retardo en una transmisión evidenciando la cantidad de paquetes que deben ser
retransmitidas y sumando la totalidad de slots requeridos para corregir la señal.
En este apartado cabe mencionar que la tecnología bluetooth tiene mecanismos propios para la
corrección de errores en transmisión sin afectar de gran manera el tiempo de la misma, una relación
de 1/3 FEC (Forward Error Correction) o en algunos casos de 2/3 FEC dependiendo del fabricante,
permite a los dispositivos bluetooth autocorregir sus transmisiones. Se analiza el retardo de esta
manera en función de dispositivos Tx y Rx ubicado en un túnel vial.
La relación SNR en sistemas de transmisión con pocas interferencias o aplicación de ruido se
calcula con la fórmula:
𝑆𝑆𝑁𝑁𝑆𝑆 = 𝑃𝑃𝑟𝑟
𝑁𝑁0 ∗ 𝐵𝐵
Donde,
𝑃𝑃𝑟𝑟= La potencia de la señal recibida en el receptor, se expresa en W (watios)
𝑁𝑁0= El ruido añadido por el canal en W/Hz Power spectral Density)
B = El ancho de banda de recepción considerado, dado en Hz
31
Calculada la relación SNR, esta debe ser aplicada al BER dependiendo de la modulación utilizada,
por lo cual para el caso de bluetooth con modulación GFSK se utiliza la ecuación:
𝑃𝑃𝑏𝑏 = 12
exp �−𝛾𝛾𝑏𝑏2�
Donde,
𝑃𝑃𝑏𝑏 = Probabilidad de perdida de bits
𝛾𝛾𝑏𝑏 = Relación SNR
Estas expresiones matemáticas obvian algunos factores importantes en sistemas inalámbricos
como la detección coherente de errores o la interferencia entre símbolos, pues los sistemas
bluetooth al ser de bajo coste no aplican estos mecanismos sobre los moduladores de un canal de
comunicación como se menciona en (Luque Giráldez, 2010).
Ahora bien, en paquetes de datos de bluetooth, las fórmulas para determinar la probabilidad de
que se pierda un paquete se calcula multiplicando las probabilidades de que se pierda tanto la
cabecera como en el campo de datos, por lo que la formula a utilizar seria:
𝑃𝑃𝑙𝑙(𝑥𝑥) = 1 − 𝑃𝑃𝑚𝑚𝑙𝑙(𝑥𝑥) Donde,
𝑃𝑃𝑙𝑙 = probabilidad de pérdida de un paquete
𝑃𝑃𝑚𝑚𝑙𝑙 = probabilidad de un error irrecuperable en cabecera o campo de datos
De forma recursiva la probabilidad de que se produzca un error irrecuperable se calcula de la
siguiente manera:
𝑃𝑃𝑚𝑚𝑙𝑙 = { 𝑃𝑃𝑑𝑑(𝑋𝑋) ∗ 𝑃𝑃𝐻𝐻} Donde,
𝑃𝑃𝑑𝑑= Probabilidad de perdida en campo de datos
𝑃𝑃𝐻𝐻= Probabilidad de perdida en la cabecera
32
En el trabajo realizado por (Luque Giráldez, 2010) se detalla de manera específica el cálculo
de la perdida de cada una de las secciones de un paquete de datos bluetooth inclusive desde el
punto de vista de otras modulaciones o tolerancia de errores, sin embargo, no es alcance de esta
investigación demostrar cada una de esas teorías.
De esta forma el cálculo del tiempo total de transmisión en función de la cantidad de
retransmisiones y la transmisión en general, se calcula de la siguiente manera
𝑡𝑡𝐴𝐴𝐴𝐴𝐴𝐴𝑙𝑙������ = (𝑁𝑁𝑇𝑇𝑇𝑇����� − 1) ∗ 𝑡𝑡𝑅𝑅𝑇𝑇𝑇𝑇(𝑥𝑥) + 𝑡𝑡𝐴𝐴𝐴𝐴𝐴𝐴(𝑥𝑥) Donde,
𝑡𝑡𝐴𝐴𝐴𝐴𝐴𝐴𝑙𝑙������ = Tiempo medio de transmisión
𝑁𝑁𝑇𝑇𝑇𝑇����� = Cantidad media de veces de retransmisión de un paquete
𝑡𝑡𝑅𝑅𝑇𝑇𝑇𝑇 = Tiempo de retransmisión
𝑡𝑡𝐴𝐴𝐴𝐴𝐴𝐴 = Tiempo de transmisión
El tiempo 𝑡𝑡𝐴𝐴𝐴𝐴𝐴𝐴 se especificó en el apartado anterior, por lo cual la deducción de la ecuación es
multiplicar el número de veces en que un paquete es retransmitido por su tiempo de transmisión
más la transmisión general del paquete en sí, así, se especifica el tiempo medio de retardo generado
en una transmisión basados en el BER obtenido de una relación SNR como se indica en la
investigación (Luque Giráldez, 2010).
Gestión del Riesgo
La implementación de sistemas de control y automatización en los túneles tiene su
fundamentación en el control y prevención de accidentes o emergencias de cualquier índole,
accidentes previos alrededor del mundo impulsaron cada vez más el desarrollo de sistemas cada
vez más completos. Aun así, la gestión del riesgo encarga de modelar o desarrollar los procesos y
protocolos de seguridad en caso de emergencias por lo general no tienen en cuenta muchos de los
33
factores, en su mayoría humanos, que afectan indirectamente los protocolos de seguridad
existentes.
Desde el punto de vista tecnológico a través del cual se ha intentado dar solución a la infinidad
de factores de riesgo existentes en túneles, se hace cada vez más importante la implementación de
nuevas herramientas que complementen los actuales sistemas de control y supervisión, que si bien
brindan una posibilidad de atención ante estos eventos, pueden llegar a ser muy complejos y poco
eficientes, ya que requieren plantear al administrador de riegos escenarios de gestión cada vez más
sofisticados.
Modelo normativo para la gestión del riesgo
Los diferentes gobiernos del mundo se han encargado de crear documentos estableciendo
procedimientos para la gestión de un túnel, desde la planificación del proyecto hasta la gestión de
operatividad del mismo, históricamente Europa ha sido uno de los continentes con mayores
accidentes en túneles del mundo, razón por la cual se considera su normativa en gestión del riesgo
para túneles como una de las más precisas del mundo.
La directiva 2004/54/CE del parlamento Europeo de 29 de abril de 2004, mediante la cual se
establecen las condiciones de seguridad en túneles de carretera, para los países pertenecientes a la
Unión Europea, es el documento de cumplimiento obligatorio que prescribe los requisitos mínimos
que deben cumplirse con el fin de garantizar la seguridad de los usuarios, siendo de aplicación para
los túneles de longitud mayor de 500m y pertenecientes a la red de carreteras transeuropeas
(Parlamento Europeo, 2004)
El artículo que detalla la gestión del análisis del riesgo recomienda además de la creación de
metodologías generales para todos los países, enfocarse primordialmente en la gestión de los
siguientes factores de riesgo:
34
- Condiciones de trafico
- Tipo de trafico
- Geometría del túnel
- Numero previsto de vehículos por día
En relación a la gestión del riesgo únicamente, puesto que los lineamientos de control dentro
de un túnel se especifican en otros documentos. Los factores de riesgo implícitos en la utilización
de un túnel se pueden también identificar de acuerdo otras condiciones como:
- Zona Geográfica del túnel
- Condiciones meteorológicas
- Infraestructura automotriz de los usuarios
- Personal operador del túnel
- Falla en los sistemas de control
Como se detalla en la directiva estos factores no son considerados en la gestión y análisis del
riesgo previo a la utilización del túnel ni en la operación habitual del mismo.
35
Capítulo 2
Planteamiento de Parámetros para la construcción de la solución
El capítulo anterior evidenció los requerimientos básicos de funcionalidad para la solución
propuesta desde los puntos de vista de: comportamiento de señales, infraestructura de túneles y el
componente de gestión del riesgo presenten en este tipo de infraestructura. Describiendo estos
requerimientos y entendiendo su naturaleza se desarrollarán los parámetros concretos de
funcionamiento de manera que está incorpore correctamente los conceptos anteriormente descritos
en función de obtener un servicio.
El sistema que establece un canal de comunicación entre nodos bluetooth que, montado sobre
una infraestructura irregular en su geometría, presenta una serie de inconvenientes que son
previsibles desde los sistemas de comunicación ya existentes y que son comunes en cualquier
sistema de comunicación.
Desde la perspectiva de un sistema de comunicación básico como el siguiente:
EMISOR RECEPTORMedio de comunicaciónEMISOR RECEPTOR
Fig. 2.1 sistema básico de comunicación
Fuente: Autores Los 3 sectores habituales en la comunicación: emisor, medio y receptor tienen puntos de falla
que en un proceso normal afectarían la comunicación. Desde el emisor los principales son:
- Fallas en el hardware
- Fallas de energía
Desde el medio de comunicación (aludiendo al hecho de que se utilizara un medio inalámbrico):
- Interferencias
- Redundancias
36
- Corte en líneas de transmisión.
Y desde la perspectiva del receptor es igual a la del emisor, entonces, para solventar este tipo
de problemas se definen parámetros de control para un sistema de comunicación, los cuales son:
- Integridad y continuidad en la operación de los dispositivos transmisores y receptores
- Funcionamiento del canal de comunicación a través de redundancia en transmisiones o
equipos.
- Aseguramiento de transmisión de datos.
Dados estos parámetros, lo primero es determinar el tipo de topología de red inalámbrica a utilizar.
Topología Bluetooth
El comportamiento de las señales bluetooth según se describió en el primer capítulo, obedece
a muchas variables que dependiendo de la infraestructura de un túnel, de la distancia máxima de
propagación de la cantidad de información transmitida, cambia de muchas manera, tanto que en la
mayoría de la investigaciones la conclusión general es que no hay posibilidad de obtener un
escenario especifico donde las señales se comporten todas de la misma manera (Degauque &
Molina-Garcia-Pardo, 2012).
La propagación inalámbrica a pesar de las múltiples interferencias a las que es susceptible posee
una diferencia relevante para la investigación a comparación de los medios de transmisión físicos,
a diferencia de estos el canal no es exclusivo, es decir, en caso de cortes del material físico sería
necesaria la implementación de redes alternas que actúen como redundancia. La transmisión
inalámbrica se puede aprovechar por las múltiples propagaciones que genera, específicamente
hablando de la solución a través de la lógica de implementación y de la manera en que se administre
la señal los problemas o falla en comunicación se trasladarían únicamente al equipamiento activo.
37
La transmisión bluetooth como se explicó en el apartado anterior experimenta los efectos
normales de propagación de casi todas las señales inalámbricas que operen en la banda de 2.4Ghz.
Para evitar problemas en la transmisión y dado que la mayoría de estos tendrán su raíz en el equipo
activo que haga la transmisión se definió una arquitectura simple de red tipo cliente-servidor
descrita de la siguiente manera:
CLIENTE/ SERVIDOR
CLIENTE/SERVIDOR
Transmisión Bluetooth
Fig. 2.2 Arquitectura básica de la solución
Fuente: Autores Donde cada nodo de transmisión efectuara la función de cliente y servidor para su nodo
inmediatamente anterior o siguiente en la línea de comunicación.
La razón primordial para determinar este tipo de topología, es la versatilidad que se puede
ofrecer al momento de presentar una falla en alguno de los nodos de comunicación, desde el
proceso lógico de funcionamiento, la acción a tomar cuando se presente una falla en un transmisor
o receptor es redirigir la señal hasta un nodo siguiente dentro de la cobertura general de la
transmisión sin que la misma o la integridad de la información se vea afectada.
CLIENTE/ SERVIDOR
CLIENTE/SERVIDOR
CLIENTE/ SERVIDOR
Transmisión Bluetooth
Nodo Afectado
XNodo Operativo
✔Nodo Operativo
✔
Fig. 2.3 Fallo arquitectura Fuente: Autores
Por supuesto este tipo de funcionamiento tienen una limitantes y variables que contemplar para
una correcta implementación. Factores como la distancia máxima que abarcara una señal hasta que
38
sea considerada obsoleta para la comunicación o la manera en que el equipo activo determinara
que un nodo ha fallado, en el proceso de diseño de la solución se contemplaran estos factores y su
respectiva validación en una simulación controlada.
Integración de protocolos y perfiles
Para la integración de la tecnología bluetooth en el canal de comunicación y entendiendo según
lo descrito en apartados anteriores, existen una serie de protocolos de pila y perfiles para la
tecnología, sin embargo, el establecimiento de un canal de comunicación no requiere de la
utilización de todos los perfiles como tampoco requiere de todos los protocolos que hay.
De cara a los perfiles y debido a la naturaleza de su funcionamiento y versatilidad en su
aplicación el perfil serial de transmisión de la tecnología bluetooth ofrece la mayor cantidad de
cualidades por sobre otros perfiles, estas características que no se encuentran en otros perfiles
como en el perfil de envío de objetos o el perfil de transferencia de archivos son:
- Emulación de puertos de comunicación utilizando estándares para el control de errores y
optimización de tramas en envío de información
- Establecimiento de 60 canales de comunicación simultáneos bajo el protocolo RS-232
- Fácil administración y configuración a través de protocolos como RFCOMM y L2CAP
De acuerdo al estándar ETSI TS 07.10 (ETSI) y a la gestión que ofrece el protocolo RFCOMM
en particular, tanto la administración y configuración de la interfaz de control de host (HCI) quien
provee la interfaz de comandos utilizables sobre la tecnología, la utilización del protocolo SPP
(serial port profile) es bastante más sencilla, pues según García (Garcia, 2017) la integración del
HCI por medio del RFCOMM permite un mejor rendimiento y optimización en retardos de
transmisión por sobre el protocolo L2CAP que a pesar de ofrecer las mismas cualidades en una
capa inferior al RFCOMM no tiene una optimización pre configurada para el perfil SPP.
39
De esta manera utilizando el perfil SPP junto con RFCOMM se establecerá el canal lógico de
comunicación entre clientes y servidores y entre usuarios y clientes, de igual manera tener 60
canales disponibles para utilizar, la cantidad de canales por nodo es alta y así proveer fiabilidad al
canal de comunicación en general.
La organización y utilización de estos canales es materia de desarrollo en el apartado de diseño
de la solución, por lo cual no se ahondará mucho por el momento en la descripción.
Tiempos de respuesta
La latencia o tiempo de respuesta siempre es primordial en la configuración e implementación
un sistema de comunicaciones, aunque si bien, para cada tipo de sistema y dependiendo de su
funcionalidad el valor de la latencia siempre es el mismo, existen valores mínimos que aseguraran
la efectividad y productividad de los mismos.
En base a la descripción de los retardos de transmisión explicados en el apartado anterior y
tomando como referencia la arquitectura planteada, se estipulan los valores mínimos de retardo
para la solución propuesta como los valores mínimos especificados en la tecnología, de acuerdo a
Moron (Moron Fernadez, 2008) el tiempo mínimo de transmisión de un paquete bluetooth en
cualquiera de sus clases y con la longitud máxima que caracteriza a cada una de ellas es de Tpoll
= 1,25ms o 2 Slots de transmisión, mientras que como tolerancia máxima el retardo es de 40 Slots
o 25ms. Esto claro para transmisiones en las que solo se vean implicados maestro-esclavo o como
para esta solución denominamos cliente-servidor.
El aseguramiento de estos retardos se ve comprometido cuando los diversos factores externos
que puedan presentarse en un túnel afecten la propagación de las señales. Las pruebas de medición
y comprobación de tiempos de retardo y productividad del canal se enuncian en literal de diseño
y evaluación de la solución.
40
Infraestructura TI
La necesidad de soportar arquitecturas enfocadas a ofrecer servicios exige ciertos lineamientos
de calidad y operatividad como parte de un plan nacional de gestión para servicios tecnológicos
desarrollado por el Ministerio de Tecnologías de la Información y Comunicaciones (MinTIC,
2014), siguiendo estos lineamientos las principales cualidades que debe cumplir una
infraestructura de comunicaciones son:
- Gestión de los servicios tecnológicos
- Alta disponibilidad de los servicios tecnológicos
- Acuerdos de nivel de servicio
- Soporte a servicios tecnológicos
- Planes de mantenimiento
- Seguridad informática
- Disposición de residuos tecnológicos
Entre muchos otros que complementan la gestión y administración de plataformas tecnológicas.
De esta manera enfocar la infraestructura de servicios para la solución propuesta hacia las
arquitecturas propuestas por el Gobierno Nacional exige primordialmente que la infraestructura
sea de alta disponibilidad, soportada en todos los aspectos y que contenga acuerdos de nivel de
servicio en función de la operatividad necesaria.
El componente tecnológico requerido para la puesta en marcha de la solución desde el punto
de vista backend y frontend, no difiere en mucho de una típica solución de comunicaciones o de
los sistemas ya instalados en un túnel vial. Los principales elementos requeridos son:
- Servidores de operación en la nube o en sitio
- Canales de comunicación hacia internet
41
- Bases de datos de alta disponibilidad
El componente operacional y de soporte no es tenido en cuenta en esta investigación por ser
un componente específicamente humano, donde estas dos cualidades serian administradas por
personas especializadas en la gestión, operación y mantenimiento de la plataforma, sin embargo,
la participación del personal y que cualidades deberían tener es materia de otra investigación o
desarrollo de modelo de negocio.
Servidores
La estimación de los servidores en función de si deberían o no estar en la nube obedece al
estudio de aplicación de tecnologías como IaaS (Infraestructura como servicio), SaaS (Software
como servicio) o PaaS (plataforma como servicio), si bien el componente que más influye en la
toma de decisión de tener los servicios On premise (en sitio) es el costo CAPEX y OPEX que
demande su instalación y puesta en servicio, en caso de escoger la variante de los servicios en la
nube es necesario entender cada una de las tecnologías mencionadas anteriormente.
- IaaS: La infraestructura como servicio es la aplicación bajo demanda de equipamiento activo
como servidores o máquinas virtuales que soporten la operación de una empresa, se
caracteriza por proveer servicios de infraestructura mientras el usuario demanda, pudiendo
bajar o aumentar las características de los equipos contratados cuando sea necesario.
(Santos, 2015)
- SaaS: El software como servicio es el valor estratégico que ofrece la administración, gestión
y actualización de un software provisto por una externa, la cual ofrece software a la medida
sin necesidad de alojarlo en servidores propios. La principal ventaja es el coste OPEX y
CAPEX de la implementación o desarrollo de software a la medida. (Santos, 2015)
42
- PaaS: La plataforma como servicio es la integración de los dos conceptos anteriores donde
la combinación de un software junto con equipos activos en función de proveer servicios
especializados es el concepto clave de la computación en la nube. (Santos, 2015)
Una de las principales características que la solución plantea como factor diferenciador es la
optimización de recursos bajo modelos minimalistas tanto de software como de infraestructura,
razón por la cual, la infraestructura orientada a satisfacer los lineamientos de calidad expuestos
anteriormente será de tipo PaaS sobre la plataforma en la nube de Google (Google Inc., s.f.) donde
la utilización de servidores para el almacenamiento de plataformas web y bases de datos no
relacionales (NoSQL) serán las principales herramientas usadas de la plataforma.
Fig. 2.4 Diagrama plataforma PaaS google cloud
Fuente: https://www.conceptdraw.com/solution-park/computer-networks-google-cloud-platform La figura 2.4 muestra la arquitectura de la solución en la nube utilizada para la solución,
apoyándose únicamente en la plataforma de bases de datos NoSQL Firebase y los App Engines
que soportaran las plataformas de administración.
Canales de comunicación
La ubicación geográfica de los túneles viales por lo general dificulta el acceso a redes de banda
ancha e internet, para lo cual se utilizan medios específicos de comunicación como antenas punto
43
a punto o radios celulares para crear la comunicación al interior del túnel con los diferentes
sistemas de control existentes (Russomanno, 2012). Debido a la alta presencia de señales celulares
por todo el país, utilizar esta tecnología soportada en pequeños módulos GSM acoplados a los
nodos finales de comunicación permitirán la comunicación entre el sistema de gestión y las redes
de internet y computación en la nube.
La comunicación se generará a través del operador Telefónica, quien bajo el programa de
desarrollo de soluciones IoT soportado en protocolos M2M (Machine 2 Machine) creo una
infraestructura de comunicaciones específica para aplicaciones de este tipo (Telefonica, s.f.)
A través de SIM (suscriber identity module) diseñadas para equipos IoT, estos pueden
conectarse a las diferentes redes celulares GPRS, 3G, LTE 4G del operador telefónica quien a
través de plataformas web permiten la administración de las tarjetas SIM, así como de asignar los
recursos de comunicaciones necesarios para cada equipo en particular.
Fig. 2.5 Diagrama de conectividad telefónica IoT
Fuente: https://iot.telefonica.com/es/solutions/connect/things-ready-link/
44
Los módulos GSM a utilizar son los SIM5320A con las siguientes características: Características módulo GSM SIM5320A Característica Descripción Banda de Operación Quadband 850,900,1800 y 1900Mhz GPS PM8015 integrado con 16 canales de localización,
sensibilidad -157dBm Conectividad Protocolos de datos TCP/IP HTTP Soporte AT Comandos AT a tasas de 300,600, 1200,
9600,19200,115200, 3.2Mbps y 4Mbps Alimentación 3.7V al menos 500mA Antenas Conectores uFL para antenas externas GSM y GPS
Tabla 2.1 Características módulo GSM Fuente: https://www.adafruit.com/product/3147
Las SIM de configuración global, por lo cual funcionan en cualquier parte del mundo
habilitando la función de roaming en el equipo GSM; posee tecnologías de transacción segura y
geolocalización así como control de consumos y conectividad (Telefonica, s.f.)
Fig. 2.6 SIM M2M solution telefónica movistar
Fuente: http://www.telefonicaempresas.com.ar/iot/global-sim-vivo-o2-movistar/global-sim-vivo-o2-movistar
Bases de Datos
Desde la gestión de la infraestructura, donde ya se definió la utilización de tecnologías en la
nube, la aplicación e implementación de bases de datos administrables desde plataforma web
evitan el uso de infraestructura en sitio siguiendo los lineamientos de optimización de la solución.
La utilización de bases de datos NoSQL como firebase, optimizan el tratamiento de datos no
estructurados y garantiza la operatividad en casos de volúmenes muy grandes de estos, razón por
la cual se determina la utilización de la tecnología.
45
A través de estructuras de datos semánticos tipo JSON desde la programación lógica de la
solución los mensajes almacenados tendrán la siguiente forma:
Database { "fecha": "fecha", "mensaje": "", "nodo": "numero nodo", "usuario": "nombre" };
La utilización de esta semántica estructura los datos de manera que la información se pueda
categorizar y tratar de manera correcta.
Los métodos de inserción, consulta, modificación y eliminación serán detallados en el
apartado de diseño de la solución, donde se muestre la implementación de la base de datos junto
con sus llaves de registro.
Gestión de la Información
Los parámetros especificados para la gestión de la información capturada por la herramienta
van alineados de igual manera con los parámetros exigidos por el ministerio. La información se
utilizará como herramienta para responder a las necesidades de la gestión de riesgo.
Como parte de las funcionalidades principales de la solución, para apoyar la toma de decisiones
o acciones por parte del personal encargado de la gestión del riesgo y con el apoyo de la
información recibida, esta fomentara la capacidad de análisis de las personas que determinan las
políticas, estrategias o mecanismos de control en caso de emergencias (MinTIC, 2014) para lo cual
la plataforma de gestión entrega herramientas de presentación de la información capturada, que
entre otras son:
- Datos en tiempo real, último dato o mensaje recibido.
- Histórico de mensajes recibidos, mensajes de control o mensajes de usuario.
46
- Graficas de usuarios conectados.
- Tabla de aproximación mayores mensajes recibidos.
De igual manera la plataforma asegurara factores relevantes en la gestión de la información
como: fuentes fiables de información o calidad de la misma, completitud y utilidad.
La solución entonces provee la premisas principales en un sistema de gestión de información
que según el Ministerio de las tecnologías de la información y comunicaciones (MinTIC, 2014) se
establecen para sacar la mayor utilidad posible de herramientas de comunicación como medios
para la obtención de información.
- Recolección
- Validación
- Consolidación para análisis
- Publicación de información
El almacenaje de la información esta soportado sobre la base de datos descrita en el literal
anterior, mientras que para los backups de información y redundancia del sistema se utilizara
infraestructura ya existente en un túnel para soportar la operación.
Parámetros influyentes en la gestión del riesgo
Dentro de los parámetros a desarrollar, y basados en los actuales aspectos de seguridad que
permitan el establecimiento y desarrollo de reglamentos internacionales (Parlamento Europeo,
2004), recomendaciones y directivas, se precisa un marco regulatorio en el que se tengan en cuenta
los siguientes aspectos de seguridad para un túnel:
- Nivel de seguridad (reglamentos y recomendaciones)
- Infraestructura y medidas de control
- Socio-económico y análisis costo-beneficio
47
- Evaluación de la seguridad (análisis y evaluación de seguridad)
- Condiciones de utilización
- Fase de la vida del sistema (planificación, proyecto, construcción, puesta en servicio,
explotación, renovación, actualización).
- Condiciones de los sistemas
Desde la perspectiva de la solución y tomando como base estos parámetros, la información
captura de los usuarios que en condiciones de riesgo o eventualidades proveerán información que
ningún sistema de control actual puede generar exponiendo un canal de comunicación más abierto.
48
Capítulo 3
Diseño lógico funcional
La metodología de funcionalidad que se necesita para la solución propuesta se define de la
siguiente manera:
Se establece un canal de comunicaciones entre diferentes nodos bluetooth que a su vez crearan
distintos canales de iguales características con dispositivos bluetooth típicos como Smartphone o
smartwatch con el fin de proveer un medio para el envío de mensajes que informen o prevengan
situaciones de riesgo o emergencia para transeúntes. Esta información se subirá a un medio de
administración o plataforma web para que el personal encargado de la gestión del riesgo y
emergencias de un túnel vial obtenga la información necesaria para la toma de decisión en caso de
emergencia.
El detalle de la construcción de la solución se enmarca en la creación de software que soporte
la operación de hardware especifico, el montaje o implementación de infraestructura tecnológica
y de comunicaciones y el diseño de una herramienta de gestión sobre web.
Funcionamiento de nodos bluetooth
Los nodos de comunicación se componen por sistemas embebidos y transmisores de bajo
consumo con capacidad de procesamiento lógico propio y con una serie de módulos e interfaces
que facilitarán el manejo, programación y estructuración de la funcionalidad
El sistema Embebido escogido para el desarrollo es la Raspberry preferiblemente en su versión
Pi 3 debido a sus características de hardware y software mientras que el transmisor de bajo
consumo escogido es el beacon Estimote UWB cuyas características se enuncian a continuación:
49
Características Beacon UWB Característica Descripción Antena bluetooth Bluetooth 4.2 – 5.0 Tiempo de batería 5 años Rango de transmisión 200 metros (rango máximo aproximado) Características físicas Largo: 75mm, ancho: 50mm, peso: 98g espesor: 27mm Lenguajes Soportados Swift, Python, java, kotlin, Objective-C Paquetes bluetooth IBeacon, EddyStone, URL, UID, RFCOMM Sensores incorporados Acelerómetro, temperatura, presión Tecnologías adicionales NFC, GPIO, EEPROM
Tabla 3.1 características beacon estimarte UWB Fuente: https://estimote.com/products
Raspberry Pi
Es un sistema embebido el cual contiene los principales equipamientos de un equipo de
cómputo general pero adaptado para funcionar con bajos niveles de potencia
Una raspberry cuenta con diferentes módulos que integrados permiten el funcionamiento de varias
aplicaciones y servicios. El panel GPIO o pines de entrada/salida sirven como medio para conectar
el mundo físico con el mundo digital. Las características se enuncian a continuación:
Características Raspberry pi 3 Model B+ Características Descripción Procesador Broadcom BCM2837B0 64 bits 1.4Ghz Memoria 1 Gb LPDDR2 Conectividad Wifi dual band, Bluetooth 4.2, BLE Acceso 40 pins GPIO SD support Micro SD card Alimentación 5V/2.5A vía micro USB connector Temperatura de trabajo 0 – 50 °C
Tabla 1.3 Características raspberry Pi 3 B+ Fuente: https://static.raspberrypi.org/files/product-briefs/Raspberry-Pi-Model-Bplus-Product-Brief.pdf
La integración con el software va de la mano con sistemas GNU/Linux donde se adaptaron
distribuciones como Debian para el control del hardware, estos sistemas operativos poseen los
componentes necesarios para manipular el GPIO y los módulos bajo lenguajes de programación
como Python o C.
50
Esquema de Funcionamiento del Sistema
El sistema propuesto como se mencionó anteriormente se conformará de nodos interconectados
que transmitirán mensajes e información a lo largo del túnel como se muestra en la siguiente figura
CLIENTE/ SERVIDOR
CLIENTE/SERVIDOR
CLIENTE/ SERVIDOR
Transmisión Bluetooth
SPP Ports SPP Ports SPP Ports
Google Cloud P.
Firebase
Plataforma web
Fig. 3.1 Esquema de funcionamiento solución
Fuente: Autores Cada nodo generara 60 canales SPP bluetooth de los cuales 4 se utilizarán para comunicación
entre nodos y 56 quedaran habilitados para los usuarios y sus dispositivos.
La comunicación entre nodo usuario funciona estableciendo un canal tipo servidor en el nodo,
mientras que una aplicación móvil creara los paquetes RFCOMM que serán enviados a través del
perfil SPP
CLIENTE/ SERVIDOR
SPP Channel Server
SPP Channel Client
RFCOMM Message
Fig. 3.2 Interconexión nodos y equipos terminales
Fuente: Autores
El establecimiento de la conexión no involucrará ninguno de los perfiles referentes a la
sincronización y autenticación de parte del protocolo de pila bluetooth, la autenticación se hará en
51
el backend de la solución autenticando las MAC´s de los dispositivos. Aun así, la conexión
bluetooth entre dispositivo móvil y transmisor se efectuará inclusive si el usuario no está
autenticado puesto que desde la pila de protocolos la autenticación y paridad de dispositivos estará
deshabilitada; los canales ocupados por los dispositivos serán desde el 5 hacia adelante.
En la conexión entre nodos, el proceso se realiza bajo todo el funcionamiento de la pila de
protocolos, por lo cual la autenticación y la paridad de dispositivos se efectuará normalmente,
luego de generar la conexión habitual entre nodos, se abrirán los canales SPP de cliente-servidor
para el envío de la información. Los canales habilitados para la recepción y envío entre nodos
siguientes y anteriores serán del 1 hasta el 4
CLIENTE/ SERVIDOR
CLIENTE/ SERVIDOR
SyncGOEP
ADDRMACService UIID
SPP Channel ServerSPP Channel Cliente
Fig. 3.3 Sincronización entre nodos Fuente: autores
Los parámetros ADDRMAC y Service UIID son identificadores propios del protocolo
bluetooth, donde en una interconexión los dispositivos sincronizan la MAC y los servicios
configurados en cada uno de ellos.
Registro de Usuarios
El registro de usuarios sobre la herramienta no será de carácter obligatorio ni imposibilitara al
usuario no registrados el usar la herramienta, la principal razón es que en caso de eventualidades
los usuarios que no se encuentren registrados podrán optar por el uso del canal. Sin embargo, el
proceso de registro se realizar para tener un control y aseguramiento de la plataforma en cuanto a
52
calidad de información, para lo cual se planea una estrategia de marketing que ponga en contexto
a los usuarios sobre las cualidades, ventajas y los casos de uso del canal.
El sistema registrara los datos de los usuarios en una base de datos NoSQL ya soportada para
la mensajería. La autenticación se generará por medio de un nombre de usuario donde la aplicación
móvil enviará la Mac del dispositivo del usuario y en caso de no encontrarse registrada, esta será
guardada en la base de datos. El algoritmo detectara cuando un usuario está o no está registrado
mostrando la alternativa en la plataforma de gestión.
Captura y registro de información
El establecimiento de canales seriales permite el envío de mensajes de texto sobre el canal
bluetooth, la aplicación móvil luego de generar la conexión con la red de nodos, permitirá el envío
de cadenas de texto de hasta un máximo de 339 octetos por slot lo cual indicaría la utilización de
2712 caracteres. La estimación para los 339 octetos viene dada por las condiciones ideales en el
manejo de retardos de señal definidas en el capítulo de planteamiento de parámetros.
Una vez la aplicación esté conectada al nodo y el usuario envíe la cadena de texto, la aplicación
encapsulara el mensaje en una trama de datos del protocolo RFCOMM, a este se le agregara la
ADDRMAC de destino y de origen, y un octeto de control de errores. El envío toma según la teoría
de transmisión de datos especificada anteriormente por (Moron Fernadez, 2008) 1,25ms para los
octetos enviados entre sincronización, ajuste, envío y verificación de trama. (véase apartado
retardo de transmisión), se espera un peso estimado de 2.7kbps por mensaje.
Una vez el dato es recibido por el nodo, este inicia la conexión con el nodo inmediatamente
siguiente para establecer la cadena de comunicación. Mediante el establecimiento del canal SPP
(bien sea el 1, 2, 3 o 4) el encapsulamiento RFCOMM es realizado nuevamente por el nodo para
la retransmisión del mensaje, este encapsulamiento lo realiza el HCI por medio de la capa de
53
gestión L2CAP por lo cual el tiempo que toma el encapsulamiento no es tenido en cuenta en el
tiempo de transmisión al requerir procesamiento interno del equipo activo, las sumas de tiempo de
procesamiento y tiempo de transmisión se validaran nuevamente de manera experimental en la
evaluación del sistema.
El proceso continua hasta llegar al nodo que tenga una conexión activa a la red, pues este
mensaje es retransmitido a los sistemas de almacenamiento en la nube.
Sincronización con plataforma de gestión
El esquema de red de la solución contendrá equipos específicos capaces de conectarse a internet
con el fin de que los datos transmitidos alcancen las bases de datos en la nube y esta permita la
sincronización de los mensajes con la plataforma de gestión.
Los dispositivos equipados con los módulos GSM para la conexión a red tendrán una subrutina
de programación que valida la salida a internet, para que en el momento en el que el programa en
general valida la salida, este envíe el paquete directamente a la red.
En particular para estos equipos si debe existir un mecanismo de redundancia que asegure el
envío del paquete encapsulado puesto que la redundancia explicada en el capítulo anterior no aplica
de la misma manera para este tipo de señales, en cuyo caso, el sistema de redundancia se plantea
de la siguiente manera:
NODO / MODULO GSM
NODOS ANTERIORES
NODO RESPALDO /
MODULO GSM
NODO RESPALDO /
MODULO GSMPowerEdge
6300
Fig. 3.4 Arquitectura de respaldo para nodos de salida a internet
54
Fuente: Autores
La utilización de fibra óptica o algún canal de comunicación cableado dependerá únicamente
de la disponibilidad de los sistemas de control existentes, sin embargo, para el caso en el que no
exista, el respaldo se realizaría hacia los nodos redundantes.
Cuando el servidor detecte el envío de un mismo mensaje de diferentes direcciones MAC, se
descartarán los demás mensajes duplicados con el fin de asegurar la calidad de la información y la
no saturación de la base de datos.
Canal de comunicación GSM
De acuerdo al anterior capitulo donde se especificó los parámetros del canal GSM que se
manejara a través del operador Telefónica, el estudio de la transmisión y de la cobertura de este
operador de cara al aseguramiento del canal de comunicaciones, no es materia de estudio de esta
investigación, independientemente de ello, el operador asegura la estabilidad y operatividad de los
canales GSM en base a su infraestructura, sin embargo, si es materia de estudio de esta
investigación la relación de parámetros necesarios para que el canal soporte la densidad de tráfico
de la solución.
Como la tecnología M2M hace parte de una estrategia comercial que alude a la adquisición de
planes de datos, a continuación, se especifican los planes disponibles para utilización.
Planes de datos M2M IoT Telefónica Plan Duración Trafico Soportado 3 Megas 1 Mes 1106 mensajes de 2.17Kbps 5 Megas 1 Mes 1843 mensajes de 2.17Kbps 10 Megas 1 Mes 3687 mensajes de 2.17Kbps
Tabla 3.3 Relación de planes de datos y trafico soportado Fuente: Autores, https://iot.telefonica.com/es/iot-partner-programme/
Servidores
La sincronización hasta los servidores en la nube solo requiere de la comunicación entre el
dispositivo terminal del canal y las direcciones IP asignadas. Los dispositivos deben relacionar el
55
envío de la información hacia el servidor por medio de llaves de sincronización específicas que
otorga la plataforma en la nube para que esta por medio de balanceadores de carga y
encapsulamiento MQTT (Message Queue Telemetry Transport) redirija los mensajes hacia los
servidores que alojan la plataforma de gestión.
MQTT es un protocolo M2M también diseñado para aplicaciones IoT debido a su optimización
para envío de mensajes o paquetes de datos pequeños.
De parte del servidor un programa escrito en Python tomara los datos recibos por el protocolo
y los cargara a la base de datos por medio de códigos diseñados por la misma plataforma cloud,
esto de parte del backend. Luego de estar sincronizados en la base de datos otro programa escrito
en JavaScript presentara los datos a la plataforma de gestión y los organizara en los diferentes
módulos diseñados para la gestión de la información.
Topología aplicada
La arquitectura de red para una conexión tipo cliente servidor no está especificada
concretamente más que como una conexión punto para el caso de dispositivos bluetooth, la
esquematización de la solución propone conexiones directas entre dispositivos y no el uso de
arquitecturas como piconets o scatternets, aun así, para los túneles viales de largas distancias la
topología debe aplicarse de alguna manera.
Las clases de bluetooth mencionadas al principio de la investigación indican que la distancia
máxima de propagación bluetooth es de 100 metros, sin embargo, según las especificaciones
técnicas de los equipos activos a utilizar esta distancia puede extenderse hasta 200 metros. Para
asegurar la disponibilidad y teniendo en cuenta que los factores que implican atenuación o ruido
de la señal no son fáciles de calcular y no corresponden a un modelo especifico, se establece una
distancia entre nodos de 30 metros, así, los mecanismos de redundancia entre nodos cuando el
56
fallo de alguno suponga el corte en la línea de transmisión, tengan un rango de tolerancia mayor
en alcance de propagación hasta una distancia de 60 metros.
CLIENTE/ SERVIDOR
CLIENTE/SERVIDOR
CLIENTE/ SERVIDOR
Transmisión Bluetooth
30 metros 30 metros
Distancia en caso de fallos = 60 metros
Fig. 3.5 Distancias soportadas para sistema de redundancia
Fuente: Autores Para situaciones en las que dos o más nodos pierdan operatividad se propone la utilización de dos
líneas de comunicación en un mismo túnel redundantes y operativas entre sí.
CLIENTE/ SERVIDOR
CLIENTE/SERVIDOR
CLIENTE/ SERVIDOR
30 metros 30 metros
Línea 1 de comunicación
CLIENTE/SERVIDOR
CLIENTE/SERVIDOR
CLIENTE/SERVIDOR
30 metros 30 metros
Línea 2 de comunicación Fig. 3.6 redundancia para casos agresivos
Fuente: Autores El programa en general identifica cada equipo como perteneciente a una línea de comunicación
en general, para evitar loop en la comunicación, en caso de generarse una falla en alguno nodo de
la línea y en el siguiente por igual, el programa generara la validación hacia la segunda línea de
comunicación.
Los efectos en retardos de transmisión se calculan sumando la totalidad de tiempo requerido
para sincronizar y enviar el paquete por cada nueva conexión necesaria, así el tiempo de
57
transmisión Ts, se multiplicará por la cantidad de conexiones adicionales que tenga que hacer el
nodo, el tiempo de transmisión básico es de 1,25ms.
Como conclusión para la topología aplicada, la cantidad de nodos requerida por túnel se calculará
de la siguiente manera
𝐶𝐶𝑛𝑛 = �𝑙𝑙
30� ∗ 2
Donde,
Cn = cantidad de nodos
L = longitud del túnel en metros
Así los nodos necesarios para un túnel vial con longitud de 1Km estaría dado por:
𝐶𝐶𝑛𝑛 = �1000𝑁𝑁
30� ∗ 2 → 𝐶𝐶𝑛𝑛 = 65, 66
El resultado debe aproximarse a la cifra superior siguiente dando como resultado 66 nodos de
comunicación distribuidos en 33 nodos por línea de comunicaciones. Es necesario aclarar que este
cálculo no incluye los nodos necesarios para la redundancia de equipos que requieren salida a
internet.
Flujo de información
El flujo de la información recorre un solo sentido, independientemente del flujo del trafico los
mensajes serán redirigidos hacia la salida del túnel que mejor señal celular tenga en comparación
al otro extremo, aun así, en caso de un derrumbe en el que los equipos queden inhabilitados, el
programa tendrá un tiempo de espera en el que de no existir respuesta cambiara por completo el
flujo de la información hacia la otra salida.
Lógica aplicada al nodo cliente/servidor
La funcionalidad del nodo a nivel lógico de programación en relación a la comunicación entre
nodos, se sustenta sobre el siguiente algoritmo procedimental:
58
Apertura de Socket RFCOMM
Mientras
Cliente, Mac = Socket RFCOMM aceptado
Si mac = mac en base de datos
“Dispositivo Aceptado”
Dispositivo no registrado
Guardar MAC
Consulta en Base de datos MAC
Guardar Usuario
Si Usuario corresponde a
MAC
Si
No
Intentar
Mientras
Guardar tiempo Inicial
Mensaje = Mensaje.Cliente
Si mensaje = 0Enviar mensaje, Usuario y mac al siguiente nodo
Guardar tiempo tiempo
final
Tiempo total = a tiempo final – tiempo inicial
“Tiempo de ejecución”
Capturar Error
Proc
eso
cont
inuo
par
a ca
ptur
a de
dat
os e
ntra
ntes
Proc
eso
cont
inuo
de
escu
cha
para
soc
ket b
luet
ooth
Si
No
Fig. 3.7 Algoritmo rol servidor nodos bluetooth
Fuente: Autores
El proceso lógico se resume en 2 procesos continuos que permanentemente están tanto
escuchando nuevas conexiones como permanentemente esperando un mensaje que enviar a un
nodo siguiente, el proceso es similar del lado del servidor cuando la conexión se hace entre un
dispositivo y un nodo de conexión.
La pila de protocolos RFCOMM si detecta una conexión sobre el Canal 1 inmediatamente
cambia el canal de búsqueda al 2 y así sucesivamente por lo cual a medida que los usuarios se
vayan conectado los canales se irán ocupando automáticamente, el algoritmo no tiene en cuenta la
gestión de estos canales.
El algoritmo de envío de mensajes es relativamente mucho más pequeño y se ejecuta desde el
mismo nodo que escucha las peticiones, por lo cual el siguiente es el proceso que indican el rol de
cliente de un nodo.
59
Creacion de Socket
Consultar nodo inmediatamente
siguiente
Inquiry basado en nivel de
señal
Conectar con nodo Socket RFCOMM,
mac, puerto
“Enviando..”
Mensaje a enviar
Si mensaje = 0 “Sin mensaje”
Socket envia mensaje a nodo
conectado
Cierre de socket
“Mensaje enviado”
Fin
SI
NO
Fig. 3.8 Algoritmo rol cliente nodo bluetooth
Fuente: Autores
Estos algoritmos hacen parte del backend de la solución, sin embargo, la metodología para la
comunicación con red o el establecimiento de los canales redundantes se describirá de la siguiente
manera:
Proceso establecimiento canal de comunicación GSM:
- Comandos AT necesario para la validación de conexión
AT+CREG = registro en red celular
AT+CSQ = Calidad de la señal hasta la BTS
AT+GACTT = Conexión a redes de datos 2G, 3G y 4G
AT+CIICR = Establecimiento de perfil de conexión de datos a internet
AT+CIFSR = obtención de dirección IP
60
AT+CIPPING = ping request
Estos comandos se ejecutan en ese orden dentro de una instrucción iterativa continua. De tener
una respuesta negativa del comando AT+CIPPING el tiempo de espera asignado para enviar la
información a otro nodo es de 2 segundos, cumplidos estos dos segundos el mensaje que se recibió
de todo el canal de comunicación pasa a otro nodo ejecutando el algoritmo de rol cliente buscando
el nodo siguiente.
De no existir fallas el mensaje se envía a través de un procedimiento totalmente aparte donde
se crean sockets MQTT se autentican con la llave única de registro de la aplicación en la nube y
son direccionados a la IP del servidor, el proceso solo entra funcionamiento si la respuesta del
comando AT+CIPPING es positiva para más de 4 paquetes enviados.
Proceso de búsqueda nodo alterno como redundancia El proceso se basa en una acción ejecutada por la capa BB (BaseBand) llamado inquiry, donde
el dispositivo se autoajusta en modo Discoverable y todos los dispositivos cercanos envían sus
datos de control como MAC y servicios disponibles, el equipo lista los dispositivos cercanos y
obtiene factores como el RSSI (Received Signal Strength Indicator). Este es un valor que
determina la intensidad de la señal y se usa a través del comando hcitool rssi “mac del dispositivo
remoto” la subrutina escanea todos los valores posibles y ejecuta el proceso de rol de servidor para
conectar con el nodo que reporte el rssi más cercano a 0, la última validación se realiza en función
de determinar a qué nodo pertenece el dispositivo, esto se logra modificando la capa de servicios
del HCI de cada dispositivo agregando una variable que indica 1 o 2 dependiendo del canal de
comunicación.
61
Plataforma de Gestión
La visualización de la información obtenida es el último proceso en la cadena de funcionalidad
de la solución propuesta, la plataforma propuesta está basada en web y procesos de backend que
manejan y presentan la información de formas que permitan a los usuarios o administradores de
gestión del riesgo tomar decisiones o acciones correctivas en casos de emergencia como ya se ha
mencionado antes.
La plataforma web, al igual que la base de datos estará contenida en un servicio de aplicaciones
e infraestructura en la nube de Google, desde allí será accesible desde cualquier terminal o
navegador.
La construcción de la solución en la nube, al ser escalable se puede configurar de la manera
más básica e ir subiendo las prestaciones de las máquinas virtuales que alojen el servicio web, así,
las características iniciales para la máquina virtual son:
Tabla 3.4 Características servidor en la nube Fuente: Google Cloud Platform
Al ser aprovisionamiento desde la nube, proceso de soporte y mantenimiento OPEX que tengan
que ver con los servidores contratados no son parte de la operación habitual de la solución, sin
embargo, las configuraciones del servidor sin son realizadas desde el punto de vista de
implementación, las configuraciones necesarias son:
- Usuarios de administración del sistema operativo
- Actualización constante de paquetes y librerías
- Configuración de servidores web
Características necesarias máquinas virtuales Google Cloud Característica Valor Procesador Intel Xeon e5-2600 v4 Memoria 4Gb DDR4 Almacenamiento 512Gb SSD Conectividad IPv4
62
- Alojamiento de página web
- Construcción de código para extracción de datos de dispositivos bluetooth
- Construcción de backend para sincronización de mensajes con bases de datos y pagina
web.
- Construcción del frontend del sitio web.
De los parámetros anteriores solo es relevante para la investigación desde la configuración del
servidor web.
Servidor Web
Programa encargado de la creación, administración, alojamiento y gestión de los diferentes
servicios web y de servir aplicaciones HTML a través de URL. La importancia del servidor radica
en su efectividad para soportar diferentes peticiones de la red y la manera en que está construido,
esto ya que en la implementación la versatilidad de los módulos y de los lenguajes de programación
que soporte serán claves en la integración del backend y del frontend.
El servidor web escogido para el montaje de la plataforma web es Nginx (NGINX INC., s.f.),
básicamente la razón por la cual se escoge por encima de otros servidores como Apache o Node.Js
es que la administración y balanceo de carga en Nginx es superior al de los demás, esto asegura
fiabilidad para aplicaciones IoT donde el consumo de tráfico no es alto en función de cantidad de
información sino en cantidad de usuarios simultáneos.
Una vez configurado el servidor Nginx sobre la máquina virtual, se configuran los módulos y
las carpetas raíz que direccionaran las peticiones al puerto 80 (típicamente el puerto utilizado para
el protocolo web HTTP) a la página principal de la herramienta de gestión.
63
Backend para la obtención de datos desde los dispositivos remotos
Una de las ventajas de la utilización de herramientas en la nube es la autogestión y la
reconfiguración que ya viene instalada de tal forma que el administrador de la plataforma solo
tiene que instalar llaves de sincronización tanto en los dispositivos remotos como en el servidor,
para que todo el tráfico que viaje por internet sea almacenado y direccionado.
El proceso que se lleva a cabo en esta subrutina es el siguiente:
- Validación de llaves de sincronización
- Apertura de Sockets TCP/UDP y MQTT
- Extracción del mensaje
- Presentación del mensaje sobre frontend
El código se escribió sobre Python y su framework para administración de servicios web
Django (Django Software foundation, s.f.)
Fig. 3.9 Arquitectura en la nube Fuente: Google Cloud Platform
64
Establecimiento de conexión a internet
Validación de llaves de
sincronización
Extraccion de mensaje,
usuario y mac
Sincronización a firebase, metodo
push.child
Funcion Snapshot, envia datos de
firebase a sitio web
Visualización de información
Mensaje recibido de la misma MAC
Eliminar Total mensajes - 1
Mientras se reciba mensaje
MQTT
Framework Django JavaScript Fig. 3.10 Diagrama de proceso backend servidor
Fuente: Autores La figura 3.16 detalla el proceso lógico que ejecuta el servidor en un bucle continuo mediante
la instrucción while que se encarga siempre de escuchar los mensajes MQTT que reciba el
servidor.
Frontend para visualización de datos
Como se expresó en capítulos anteriores, la gestión de la información es uno de los pilares de
funcionamiento de la solución propuesta, el Ministerio de Comunicaciones establece unos
lineamientos a seguir en la presentación de la información obtenida, siguiendo estos lineamientos
se diseñó una plataforma de gestión tipo Dashboard donde se visualiza la información de manera
clara y simple para que de esta manera el personal encargado de la gestión de alertas desarrolle las
habilidades necesarias para obtener el mayor provecho de la información presentada.
Diseño del DOM
El DOM o Document Object Model es la interfaz que permite la configuración de todos los
objetos presentados en un página web a través del lenguaje de etiquetas HTML (Hipertext Markup
Lenguage), el modelado del DOM es parte de las mejores prácticas de programación de sitios web,
pues permite esquematizar de manera ordenada toda la información así como explotar la
cualidades de los navegadores web (Gauchat, 2012).
El diseño DOM realizado para la plataforma de gestión al ser de tipo dashboard cumple con la
apariencia física típica de una plataforma de esta índole, como ejemplo, la interfaz gráfica del
65
dashboard diseñado por telefónica para la administración de tarjetas SIM para su tecnología M2M
en IoT tiene la siguiente apariencia.
Fig. 3.11 Dashboard Kite Platform
Fuente: https://m2m-movistar-cl.telefonica.com/#/
Según el diseño, la distribución de los contenedores de información para la plataforma de
gestión de la solución se planteó de la siguiente manera:
ENCABEZADO
MENULabels Informativos
Mensajes en Tiempo Real
Total Alertas Usuarios Nuevos Usuarios Conectados
Alertas Históricas
Fig. 3.12 Diseño DOM plataforma de gestión
Fuente: Autores
66
La metodología de desarrollo web es la misma que para cualquier sitio web que existe, a través
de HTML escribimos la información del esquema de la página web, por medio de CSS (Cascade
Style Sheet) y JavaScript se da el componente de diseño y estilos a la página web, mientras que el
componente de interactividad y comunicación con los procesos de backend se realiza a través de
JavaScript.
El resultado del diseño y de los componentes de interactividad para la creación del sitio web
fue el siguiente:
Fig. 3.13 Plataforma de Gestión Web
Fuente: Autores
Algunos componentes como el nodo o el estado del usuario se obtienen del proceso de envío
de mensaje, obteniendo las macs de los dispositivos que enviaron el mensaje y del tiempo total
transcurrido se determina su estado y el nodo del cual se envió el mensaje.
En materia de funcionalidad hay ciertos componentes que aún no se trabajaron sobre la
plataforma de gestión, como la obtención de los parámetros de funcionalidad y operatividad de
todos los nodos, o la capacidad de automatizar tareas como actualizaciones y cambios de firmware.
67
Estos parámetros se llevarán a una segunda fase de desarrollo donde se consolida la plataforma de
gestión como una plataforma única de administración para toda la solución.
Información de relevancia para la gestión del riesgo
La gestión de la seguridad supone un desafío específico en los túneles de carretera, donde, los
riesgos de los vehículos en movimiento son mayores, y el comportamiento humano, que es difícil
de prever, afectan significativamente en el resultado de los incidentes graves.
Como resultado del análisis de estos factores, junto con la información que provea el sistema de
gestión se espera que la experticia y entrenamiento de los gestores de riesgo en túneles viales sean
capaces de tomar decisiones de manera que se prevengan o minimice los siguientes parámetros:
- Acontecimientos críticos.
- consecuencias durante situaciones de emergencia.
Lo anterior permite enfocar los sistemas de gestión del riesgo, al control de las situaciones de
emergencia, para brindar canales de comunicación más confiables ante situaciones de riesgo
inminente. No es materia de esta investigación validar el conocimiento de los gestores de riesgo y
de proceder ante situaciones de emergencia.
68
Capítulo 4
Evaluación del sistema de gestión
Según estudios previos realizados como “Comunicaciones inalámbricas en un túnel” de
Degauque y Molina-García-Pardo (Degauque & Molina-Garcia-Pardo, 2012) o “Propagación de
ondas en un túnel” de Lienard, Deguaque, Molina-García-Pardo y Martine (Lienard, Molina-
Garcia-Pardo, & Degauque, 2006) la conclusión general cuando se habla de evaluar sistemas de
comunicación de cualquier tipo, es que independientemente de la segmentación del problema o de
la definición de objetivos claros para la realización de pruebas, las condiciones volátiles de un
túnel no son precisas para determinar de manera exacta un procedimiento que permita obtener
resultados certeros más que por aproximación.
La mayoría de pruebas se realizan en ambientes controlados y que miden los resultados según
aproximaciones que sirven como factor de comprobación para los estudios realizados.
La metodología de pruebas para la solución diseña consistirá de una serie de pasos que validen los
parámetros de diseño propuestos en ambientes y condiciones aproximadas a túneles viales reales.
Los pasos a seguir son los siguientes:
- Potencia de los transmisores bluetooth en condiciones estáticas para un usuario que se
conecte a la solución.
- Potencia de los transmisores bluetooth en condiciones de movimiento para diferentes
velocidades que se asemejen a las velocidades permitidas al interior de un túnel.
- Tiempos de respuesta entre nodos y clientes.
- Cantidad de usuarios simultáneos conectados al sistema
- Registro de eventos y mensajes por parte de la plataforma web en cada uno de los casos
descritos anteriormente.
69
Descripción ambiente simulado
El ambiente que se utilizara para emular la mayor parte de las condiciones normales de un túnel
es un túnel peatonal y para bicicletas ubicado en la ciudad de Bogotá entre calles 91 y 90 con
avenida ciudad de Cali.
Las condiciones de este túnel se asemejan en materiales de construcción, geometría de la
infraestructura, concurrencia de usuarios y longitud.
- Materiales de construcción: Concreto reforzado
- Longitud: 45metros
- Geometría de la infraestructura: Corte transversal de entrada tipo rectangular
- Concurrencia de usuarios: de 20 a 30 usuarios por hora en días hábiles.
Ubicación del túnel:
Ubicación Relativa Bogotá:
Segmento de túnel entre calles 90 y 91 con av. Ciudad de Cali
72
Vista de las entradas del túnel junto con el interior del mismo:
Fig. 4.3 Interior túnel peatonal Bogotá/Colombia
Fuente: Autores
Fig. 4.4 Entrada a túnel peatonal Bogotá Colombia
Fuente: Autores
73
El procedimiento de pruebas de la solucion según lo especificado tuvieron el siguiente resultado
Potencia de transmisión bluetooth en condiciones estáticas
Según los parámetros de diseño la ubicación de los nodos se realiza a 30 metros cada uno, sin
embargo, dadas las condiciones del ambiente de pruebas de los 45 metros en total se ubicarán 4
nodos cada 20 metros en ambos costados del túnel, el usuario conectado estará a una distancia de
20 metros del túnel de igual manera
Los nodos se ubicaron a 50cm del cielo razón del túnel, las mediciones tienen una variación de
5 metros por cada medida.
Por medio del comando hcitool se realizó la medición de la intensidad de señales para cada uno
de los casos:
Cuando el valor RSSI devuelto es 0, equivale a una señal de recepción perfecta cuando la clase
del controlador bluetooth es 1 y su potencia de transmisión es de 20dBm, así mismo el valor
máximo devuelto por el comando RSSI es -100 lo cual indica el nivel de sensibilidad máximo que
en este caso es de -70dBm. Cabe aclarar que la medición del RSSI es algo propio de cada fabricante
por lo que el valor devuelto por el comando cambia dependiendo del dispositivo, en este caso el
valor 0 indican el nivel de recepción más alto y el -100 el nivel de potencia recibida más bajo
Las mediciones para una variación de 5 metros empezando desde 10 metros de distancia hasta
el nodo fueron:
74
Tabla 4.1 Valores factor RSSI Fuente: Autores
Para el cálculo de la sensibilidad en dBm solo basta con hacer una interpolación de los valores
tomando como referencia los valores máximos y mínimos
Ejemplo para una distancia de 10 metros del resultado del comando:
Fig. 4.5 relación RSSI / dBm
Fuente: Autores Por lo que los valores obtenidos de medición son de:
Tabla 4.2 Valores RSSI y sensibilidad de recepción
Fuente: Autores
-80
-70
-60
-50
-40
-30
-20
-10
0-120 -100 -80 -60 -40 -20 0
Relacion RSSI / dBm
Valores medidos Factor RSSI Distancia Valor RSS
10 -22 15 -26 20 -31 25 -37 30 -42
Equivalencia RSSI en dBM Distancia Valor RSSI Sensibilidad 10 -22 -15,4dBm 15 -26 -18,2dBm 20 -31 -21,7dBm 25 -37 -25,9dBm 30 -42 -29,4dBm
75
Fig. 4.6 relación Sensibilidad / Distancia Fuente: Autores
Fuente: Autores
Simulando la desconexión del nodo central, ejecutamos las pruebas de conexión desde el
dispositivo terminal de usuario hasta el nodo siguiente con una distancia máxima de 60 metros
cambiando la posición del usuario para lo cual los resultados fueron los siguientes:
Tabla 4.3 Valores de sensibilidad para caso de redundancia
Fuente: Autores
-35
-30
-25
-20
-15
-10
-5
010 15 20 25 30
Sensibilidad / Distancia
Valores sensibilidad para caso de redundancia Distancia Sensibilidad 0 0 4 -6 10 -15,4 15 -18,2 20 -21,7 25 -25,9 30 -29,4 60 -43,4
76
Fig. 4.7 relación Sensibilidad / Distancia
Fuente: Autores
Los picos de caída en la señal se indican cuando el nodo intermedio pierde conexión y el emisor
debe conectarse hasta el nodo siguiente ubicado al doble de la distancia.
Con una distancia máxima de 60 metros entre nodos la sensibilidad percibida es de -43,4dBm
lo cual está todavía dentro del margen propuesto de -70dBm, en este punto el nodo es capaz de
reconocer los valores de energía de los bits transmitidos y demodular una señal entrante sin ningún
problema.
Potencia de transmisión bluetooth a distintas velocidades
De acuerdo a las normativas vigentes en Colombia para túneles viales, la velocidad máxima
permitida es de 60Km/h y la velocidad mínima para evitar colisiones es de 30Km/h (Gobierno de
la Republica de Colombia, 2016) se tomaran mediciones en velocidades que comprenda este rango,
las condiciones de las pruebas siguen siendo las misma y la metodología es la misma:
Teniendo en cuenta que el túnel es de acceso peatonal y de bicicletas para rangos de velocidades
30, 40 y 60Km/h se utiliza un ciclomotor marca Auteco starker E3 (Auteco, s.f.) que alcanza
velocidades de 60Km/h con un conducto de peso 55Kg.
-50
-45
-40
-35
-30
-25
-20
-15
-10
-5
00 10 20 30 40 50 60 70
Sensibilidad / Distancia
77
Pruebas a 30 Km/h Las pruebas de conexión a diferentes velocidades describirán de una manera más real el
funcionamiento normal de la solución propuesta por lo que en esta prueba además de medir el
nivel de señal captado por un nodo, también se medirá el tiempo de transmisión hasta el nodo
siguiente:
Valores RSSI para velocidades de 30Km/h Velocidad Km/h Valor RSSI Sensibilidad 30 -41 -28,7dBm 30 -29 -20,3dBm 30 -31 -21,7dBm 30 -56 -39,2dBm 30 -35 -24,5dBm Promedio -38,4 -26,88
Tabla 4.4 Valores RSSI para una velocidad de 30Km/h Fuente: Autores
Se realizaron 5 mediciones a la misma velocidad obteniendo un promedio de niveles de señal
y RSSI aun aptos para funcionar.
El tiempo transcurrido en toda la operación entre transmisiones y procesamiento interno de
cada nodo en la solución propuesta se mide en el programa que corre en el backend sumando los
tiempos de operación de cada instrucción obteniendo los siguientes resultados:
El tiempo es medido en ms, por lo cual al sistema compuesto por 4 nodos le tomo 8,87ms
enviar el mensaje a la plataforma de gestión:
78
Latencia promedio para una velocidad de 30Km/h Velocidad Km/h Tiempo en ms 30 8,87 30 12 30 22,41 30 9,53 30 13,86 Promedio 13,33
Tabla 4.5 Tiempo de respuesta promedio para una velocidad de 30Km/h Fuente: Autores
Pruebas a 40Km/h
Valores RSSI para una velocidad de 40Km/h Velocidad Km/h Valor RSSI Sensibilidad
40 -22 -15,4dBm 40 -35 -24,5dBm 40 -48 -33,6dBm 40 -42 -29,4dBm 40 -50 -35dBm
Promedio -39,4 -27,58 Tabla 4.6 Valores RSSI para una velocidad de 40Km/h
Fuente: Autores
Mientras que los tiempos de respuesta fueron:
Latencia promedio para 40Km/h Velocidad Km/h Tiempo en ms 30 8,92 30 8,56 30 9,41 30 15,2 30 11,87 Promedio 10,792
Tabla 4.7 Tiempo de respuesta promedio para una velocidad de 40Km/h Fuente: Autores
79
Pruebas a 60km/h Los resultados en medición de señal y factor RSSI fueron:
Valores RSSI para una velocidad de 60Km/h Velocidad Km/h Valor RSSI Sensibilidad 60 -14 -9,8dBm 60 -31 -21,7dBm 60 -29 -20,3dBm 60 -20 -14dBm 60 -24 -16,8dBm Promedio -23,6 -16,52
Tabla 4.8 Valores RSSI para una velocidad de 60Km/h Fuente: Autores
Resultados para tiempos de respuesta:
Tabla 4.9 Tiempos de respuesta promedio para una velocidad de 60Km/h Fuente: Autores
Pruebas respuesta de servidor al envío de mensajes
Los mensajes son subidos a la plataforma de gestión por medio de los dispositivos que tienen
acceso a la red, estos dispositivos se les adapto un módulo GSM conectado a la red del operador
Telefónica por medio una SIM IoT M2M, las pruebas de conectividad se evidencian en la
plataforma de gestión Kite. Una vez el equipo se encuentre conectado a la red el proceso de gestión
interno de la plataforma cloud enviar los mensajes.
Latencia Promedio para 60Km/h Velocidad Km/h Tiempo en ms 30 15,4 30 21,5 30 17,3 30 18,1 30 9,87 Promedio 16,434
80
Los tiempos de latencia reportados desde la plataforma de google cloud no superan los 17ms
para la configuración actual de pruebas. A este tiempo de latencia se le suman los tiempos de
transmisión reportados anteriormente y se obtienen los siguientes resultados:
Promedio tiempos de respuesta configuración de pruebas Velocidad Latencia entre
nodos Latencia de servidor
Cantidad nodos
Total Transmisión
30 Km/h 13,33 ms 25ms 4 30,33ms 40Km/h 10,72 ms 25ms 4 27,72ms 60Km/h 16,434 ms 25ms 4 33,434ms
Tabla 4.10 Promedio tiempos de respuesta configuración de pruebas Fuente: Autores
La configuración física de los nodos junto con los módulos GSM ya instalados utilizados para
las pruebas fueron los siguientes:
Fig. 4.8 Nodo bluetooth / Modulo GSM
Fuente: Autores
El código utilizado para sincronizar los datos con la base de datos se construyó en JavaScript y
HTML, sin embargo, como HTML solo indica el contexto de la información sobre la página web,
se hace referencia únicamente al código en JavaScript utilizado:
81
/* creación de objeto tipo Firebase*/ var rootRef = new Firebase('https://practica-iot.firebaseio.com'); /* Creación de variables de HTML*/ var lblCurrentMessage = document.getElementById('lblcurrentMessage'); /* Vínculo entre variables de HTML y referencias en Base de datos*/ var currentMessageRef = rootRef.child('Nombre'); var currentMessageRef2 = rootRef.child('fecha'); var currentMessageRef3 = rootRef.child('nodo'); var currentMessageRef4 = rootRef.child('usuario'); /*Función Extracción de datos*/ btUpdateMessage.addEventListener('click',function(){ currentMessageRef.set(txtNewMessage.value); currentMessageRef2.set(txtNewMessage2.value); currentMessageRef3.set(txtNewMessage3.value); currentMessageRef4.set(txtNewMessage4.value); }); /*Funciones impresión de datos*/ currentMessageRef.on('value', function(snapshot) { lblCurrentMessage.innerText = snapshot.val(); })
Fig. 4.3 Código sincronización de datos en firebase Fuente: Autores
Los mensajes en la plataforma web son visualizados de dos maneras: En el cuadro de reporte
en tiempo real y en el histórico de mensajes. Se realizó la prueba con dos usuarios y diferentes
perfiles para crear un histórico.
Fig. 4.9 Mensaje en Tiempo Real
Fuente: Autores
Mensaje en tiempo real
82
Fig. 4.3 Mensaje en Tiempo Real
Fuente: Autores
Pruebas de usuarios simultáneos
Para estas pruebas se utilizaron una cantidad de equipos simultáneos que emularon la misma
cantidad de usuarios con el fin de medir los tiempos de respuesta de la solución completa, es decir,
hasta que el mensaje llegue al servidor.
Los resultados de pruebas de tiempos de respuesta para dos usuarios simultáneos ya fueron
registrados, así que, se hicieron dos mediciones más con 5,10, 15 usuarios simultáneos.
Metodología de prueba Los usuarios se repartieron en conexiones entre los 4 nodos del esquema montado para las
pruebas, cada equipo enviaba 2 mensajes de prueba de manera simultánea mientras permanecía
estático, obteniéndose los siguientes resultados:
Tiempos de Respuesta con usuarios simultáneos Qty equipos
Latencia entre nodos
Latencia de servidor
Cantidad nodos
Total Transmisión
5 15,84ms 25ms 4 40,84 10 19,17ms 25ms 4 44,17 15 28,17ms 25ms 4 53,17
Tabla 4.11 Resultado tiempo de respuesta con usuarios simultáneos Fuente: Autores
83
El tiempo de respuesta en comparación con los datos obtenidos anteriormente para dos usuarios
aumentan drásticamente, esto se debe a que el procesamiento interno de cada nodo aumenta al
procesar más usuarios y más mensajes, como ejemplo se evidencia el tiempo de respuesta tomando
para un usuario en un nodo con 6 equipos más conectados.
Fig. 4.10 Tiempo de respuesta para nodo con carga de 6 equipos
Fuente: Autores Si se toman todos los valores obtenidos el comportamiento en tiempos de respuesta es el
siguiente:
Fig. 4.11 Tendencia tiempo de transmisión para múltiples usuarios
Fuente: Autores Los tiempos de respuesta base para una conexión a un servidor en la red se sitúan alrededor de
52ms, con los resultados obtenidos para un total de 15 equipos simultaneas el tiempo de respuesta
0
10
20
30
40
50
60
0 2 4 6 8 10 12 14 16
Total Transmision / Nodos conectados
84
promedio del servidor hasta la plataforma de gestión es de 53,17ms lo cual indican un tiempo de
respuesta prudente.
85
Capítulo 5
Análisis de resultados obtenidos
Luego de la evaluación de la solución en un ambiente controlado y similar en características
de un túnel, el análisis de los resultados determina la efectividad de la solución propuesta.
La metodología de pruebas modela a nivel de transmisión, recepción y presentación de datos el
diseño propuesto, sin embargo, es de vital importancia realizar la validación en función de los
sistemas de comunicación que ya existen en los túneles, para esto se analizaron cada uno de los
puntos mencionados de manera independiente.
Transmisión
La fiabilidad de las comunicaciones inalámbricas, por más que la tecnología avance en calidad
de información, alcance y mecanismos de protección para la propagación de la señal, aun se debate
su confiabilidad en comparación con los sistemas cableados tradicionales. Las fuentes de
interferencia en un túnel son difíciles de calcular sumando a la poca tolerancia de las señales
inalámbricas a este tipo de problemas debaten aún más su utilización.
El diseño de la solución pretendió mitigar en un porcentaje muy alto el factor de interferencia
de comunicación entre los nodos, más aún en tecnologías bluetooth que utilizan bandas de
frecuencia altas y por ende más susceptibles a factores como perdidas por espacio libre o
atenuación por inyección de ruido de fuentes externas, aun así la topología bluetooth aplicada crea
canales directos de comunicación de una distancia muy inferior a la normalizada por los fabricantes
con el fin de que las interferencia, que por supuesto existen, no afecten de manera radical.
La forma en que se midió la efectividad de manera funcional fue con los tiempos de respuesta,
el cálculo de atenuaciones y perdidas esta sobre estimado cuando el corazón de las soluciones
actuales es digital, por ende el tiempo de repuesta asegura una tasa BER mínima (como se
86
menciona al principio de la investigación) brindando una fiabilidad por encima de otras soluciones
inalámbricas, sin mencionar que la configuración de las redundancias genera un área de cobertura
más que una línea de comunicación tradicional.
Las mediciones en tiempos de respuesta en función de la cantidad de usuarios arrojan resultados
útiles que, aunque no se asemejen a las condiciones normales de un túnel en factores como cantidad
de usuarios o situaciones de emergencia, si brinda una herramienta que aplicándole una
extrapolación a los datos obtenidos es posible estimar los resultados con una cantidad de usuarios
mayor.
Recepción
El valor agregado al canal de comunicación es su plataforma de gestión de la información, la
recepción e integridad de la información generada desde los usuarios es quizá el factor de medición
más importante de todo el esquema al igual que con la transmisión, el tiempo de respuesta es vital,
las arquitecturas web típicas exigen niveles de respuesta de entre 15ms a 72ms (Urbano Lopez,
2015). Los resultados de respuesta inclusive con usuarios simultáneos demuestran un tiempo de
respuesta dentro del rango permitido para las aplicaciones web.
Desde el Canal de comunicación, el funcionamiento se delega al operador de telefonía celular
que, en la venta de sus servicios M2M e IoT asegura una cobertura necesaria para la comunicación
de cualquier dispositivo IoT a lo largo del territorio nacional. Cuando se trata de aplicaciones para
IoT, los requerimientos en ancho de banda no son tan exigentes como para otro tipo de
aplicaciones, esto asegura que incluso en territorios muy apartados donde las conexiones celulares
solo alcancen el 2G, será suficiente para una comunicación bidireccional.
87
Del lado de los servidores y su eficacia en procesamiento, las ventajas de una solución en la
nube son su escalabilidad, por ende, del lado de la solución, la infraestructura IT está cubierta
desde todos los ángulos posibles como la disponibilidad, el procesamiento, y la conectividad.
Presentación de los Datos
Al ser los datos el corazón de la solución, no existe valor agregado si la presentación y
administración de los datos no se hace de manera efectiva. Una de las cualidades de las plataformas
tipo dashboard es la efectividad en presentación de datos junto con optimizaciones en espacio,
gráficas y administración de los sitios web y la información contenida.
Los sistemas tradicionales como SCADA, proveen una interfaz de control ceñida a los
parámetros con lo que se diseñó, si existe algún factor externo que no pueda ser medido o no se
haya contemplado en el diseño de la solución esta pierde valor, sin embargo, la razón de esta
solución no es la de reemplazar sistemas como SCADA, sino la de complementar el control y
operación de un túnel a través de herramientas de gestión del riesgo que proveen de información
a los administradores de un túnel.
Si bien la presentación de los datos no tiene ningún tratamiento adicional como proyecciones o
cálculo de tendencia, si presenta la información necesaria de lo que sucede en un túnel y no se
puede medir con precisión. Es importante aclarar que la herramienta por sí misma no ofrece
asesoramiento en toma de decisiones ni en control o automatización de elementos externos a ella,
el trabajo de interpretación y acción está dado por el personal.
Es correcto decir que mientras no se realicen pruebas de tipo real, en túneles reales y en
operatividad normal, no es posible determinar la viabilidad de la solución al 100%, sin embargo,
si es posible determinar la viabilidad de la tecnología escogida como soporte al diseño propuesto
que sirve a la obtención de los parámetros iniciales planteados al inicio de la investigación pues
88
de manera experimental todos estos factores fueron comprados validando el diseño en pequeña
escala.
89
Conclusiones y Recomendaciones
Conclusiones
- Si bien existen infinidad de protocolos, recomendaciones y directivas que promueven la
seguridad, el mantenimiento y operación de un túnel, que se sustentan en hechos
catastróficos del pasado, y que por supuesto la aceptación de los mismos indica un
consenso general en políticas y metodologías, aún existen muchos criterios no tenidos en
cuenta al momento de estos protocolos dejando excluidos factores que a futuro pueden
evitar situaciones críticas, de emergencia o catastróficas en los túneles de Colombia y el
mundo.
- La determinación de todos los parámetros que incidan en la seguridad personal, vial y de
infraestructura no es posible de realizar de manera exacta de modo que la creación de
protocolos de seguridad aseguren y prevengan las diferentes situaciones o adversidades
que se puedan llegar a presentar, el estudio de este tipo de casos arroja la conclusión de
que no es el camino tratar de determinar y plasmar en una ley o directiva los procedimientos
o requisitos mínimos de implementación para un túnel, sino que deben existir herramientas
que sean capaces informar en tiempo real las diversas situaciones presentan en ambientes
tan caóticos como este.
- El papel de las telecomunicaciones y su impacto en la mayoría de aspectos de la vida
cotidiana, así como su constante evolución desde todos los puntos de vista de un sistema
informático, apoya de gran manera a la creación de tecnologías para el apoyo y no la
automatización de tareas que las maquinas aun no pueden calcular de manera tan precisa
como se quisiera. La finalidad de las herramientas de comunicación es soportar la
90
operación humana y apoyar la toma de decisiones en casos adverso o de dificultad que
imposibiliten a una persona a actuar.
- La evolución de las tecnologías inalámbricas ha llevado a su utilización en muchos más
escenarios que los indoor, el bluetooth por su parte creció de manera exponencial en redes
de área personal (WPAN) sin embargo, el resultado de la investigación indica que la
utilización de esta tecnología permite la creación de soluciones outdoor que exploten las
facultades de operación de la mayoría de dispositivos móviles existentes que cuentan con
esta tecnología.
- Los resultados obtenidos por medio del análisis experimental del diseño propuesto, arrojan
las bases necesarias para el desarrollo de mejores cualidades de funcionamiento que
permitan extrapolar los resultados de la investigación en túneles viales a lo largo del país
y así ofrecer una alternativa a los inmensos y bastante costos sistemas de control y
automatización para túneles, que actualmente son orgullo de la tecnología moderna pero
que dejan de lado el factor humano que intercede en la operación diaria de este tipo de
infraestructuras.
Recomendaciones
- En la medida que las tecnologías de transmisión vayan evolucionando y mejorando
características como alcance de transmisión, potencias y ganancias de las antenas,
procesamiento de señales digitales, es necesario cambiar la tecnología que los nodos
propuestos ofrecen puesto que al ser la tecnología una ciencia en constante cambio, el
desarrollo de soluciones puede verse estancando de no actualizar componentes.
91
- La integración de tecnologías emergentes como el Machine Learning, Inteligencia de
negocios o incluso la misma inteligencia artificial aumentaría las capacidades de una
herramienta como la propuesta de manera exponencial ya no solo capturando información
sino generando proyecciones y estimando tendencias que automaticen en un cierto
porcentaje la toma de decisiones.
- La integración de herramientas de gestión enfocadas a generar valor de manera
bidireccional tanto al usuario como al administrador de la infraestructura, ofrecería un valor
agregado a los sistemas de control actuales, permitiendo expandir las oportunidades de
sistemas como SCADA en implementaciones existentes o futuras.
92
Referencias
Aranciba, F. (1 de febrero de 2011). Construcción de Túneles. Obtenido de Ingenieria y
Construccion: http://facingyconst.blogspot.com/2011/02/construccion-de-tuneles.html
Arias , D., & Diaz, W. (2016). Diseño y Construccion Túneles de ladera:Colombia. Bogotá:
Universidad Santo Tomas.
Auteco. (s.f.). Auteco. Obtenido de STARKER E3 : https://www.auteco.com.co/moto-electrica-
starker-e3/p
Bluetooth Extension Module. (13 de Junio de 2017). (GitHub) Recuperado el 22 de Octubre de
2017, de https://github.com/karulis/pybluez
Degauque, P., & Molina-Garcia-Pardo, J.-M. (2012). Wireless Communication in Tunnels.
Research Gate.
Django Software foundation. (s.f.). Django. Obtenido de The web framework for perfectionist
with deadlines: https://www.djangoproject.com/
ETSI. (s.f.). ETSI TS 07.10 Technical Specification RS-232.
FCC Industrial. (11 de Julio de 2016). http://www.fccindustrial.com. Obtenido de
http://www.fccindustrial.com/es/-/fcc-industrial-instalara-los-sistemas-de-seguridad-e-
iluminacion-del-tunel-la-aldea#
Franco, D. (2007). Comunicaciones Inalámbricas Bluetooth. Obtenido de revistas.utp.ac.pa:
https://revistas.utp.ac.pa/index.php/prisma/article/view/412/html
Garcia, A. (2017). Bluetooth. Madrid: Hidalgo.
Gauchat, J. (2012). El gran libro de HTML5, CSS3 y JavaScript. Barcelona: Marcombo S.A.
93
Gobierno de la Republica de Colombia. (2016). Estudios, Diseños, Construccion, Operacion,
Mantenimiento, Gestion Social, Predial y Ambienta para Tunel doble Calzada Bogota-
Girardot. Ministerio de Transporte.
Google Inc. (s.f.). Google Cloud Platform. Obtenido de https://cloud.google.com/
Ley 1581. (2012). Ley 1581 de 2012. Ley de proteccion de datos personales.
Lienard, M., Molina-Garcia-Pardo, J.-M., & Degauque, P. (2006). Wave propagation in tunnels
in a MIMO context - A theorical and experimental study. Research Gates.
Loranca Ramos, Y. A. (2003). Lineas de Transmisión y guias de onda. Puebla, Mexico:
Universidad de las Americas.
Luque Giráldez, J. (2010). Modelo del retardo de transmision en Bluetooth 2.0 + EDR. Málaga:
Universidad de Málaga.
MinTIC. (30 de Diciembre de 2014). Ministerio de las Tecnologias de la Informacion. Obtenido
de Arquitectura TI Colombia: https://www.mintic.gov.co/arquitecturati/630/w3-
propertyvalue-8094.html
Moron Fernadez, M. J. (2008). Estudio del rendimiento de perfiles Bluetooth en redes de área
personal. Málaga: Universidad de Málaga (Tesis Doctoral).
NGINX INC. (s.f.). Nginx. Obtenido de https://www.nginx.com
Parlamento Europeo. (30 de 4 de 2004). Directiva 2004/54/CE requisitos minimos de seguridad
para tuneles de la red transeuropea. Diario Oficial de la Union Europea, págs. 54-55.
Russomanno, I. D. (Septiembre de 2012). http://www.aates.org.ar. Obtenido de
http://www.aates.org.ar/images/eventos/2012-jor2/pdf/10-Daniel-Russomanno.pdf
Santos, M. (2015). SAAS, IAAS Y PAAS: ¿Para que son, Como usarlos y Para que? Enter.com.
94
Suarez Florez, M. (2001). Los sistemas inteligentes de transporte ITS . Ciencia e Ingeniería
Neogranadina 2001 (10), 42.
Telefonica. (s.f.). Telefonica, Internet of Things. Obtenido de https://iot.telefonica.com
Urbano Lopez, M. (2015). UF1272: Administracion y auditoria de los servicios Web. Málaga:
IC Editorial.
Vidal, D. A. (s.f.). https://es.slideshare.net/diegoamv/presentacion-isa-its-final. Obtenido de
https://es.slideshare.net/diegoamv/presentacion-isa-its-final