“Sistema de control aplicado - UNP
139
“Sistema de control aplicado a comunas rurales aisladas y su vinculación con Internet de las cosas (IoT)” WALTER DANIEL ETCHART - ANDRES EZEQUIEL MARTINOVIC Director de Tesina: Mg. Ing. Ricardo A. López Tesina presentada a la Facultad de Ingeniería de la Universidad Nacional de la Patagonia San Juan Bosco como parte de los requisitos para la obtención del título de Licenciado en Sistemas (Or. Planificación, Gestión y Control de Proyectos Informáticos) Trelew, marzo de 2018 Facultad de Ingeniería - Sede Trelew Universidad Nacional de la Patagonia San Juan Bosco
Transcript of “Sistema de control aplicado - UNP
“Sistema de control aplicado a comunas rurales aisladas y su vinculación con Internet
de las cosas (IoT)”
WALTER DANIEL ETCHART - ANDRES EZEQUIEL
MARTINOVIC
Director de Tesina: Mg. Ing. Ricardo A. López
Tesina presentada a la Facultad de Ingeniería de la Universidad Nacional de la Patagonia San
Juan Bosco como parte de los requisitos para la obtención del título de Licenciado en
Sistemas (Or. Planificación, Gestión y Control de Proyectos Informáticos)
Trelew, marzo de 2018
Facultad de Ingeniería - Sede Trelew
Universidad Nacional de la Patagonia San Juan Bosco
pág. 2
AGRADECIMIENTOS De Andres:
A todas aquellas personas que con su ayuda han colaborado en la realización del presente
trabajo, en especial a aquellas personas que diariamente me han dado su apoyo incondicional
para poder avanzar a lo largo de todo este camino.
Me gustaría dedicar un agradecimiento especial a la Lic. Marta S. Saenz Lopez, que fue quien
me alentó a continuar por este camino de formación.
Además quisiera hacer extensiva mi gratitud a mis compañeros y profesores del
Departamento de Informática por su apoyo y acompañamiento a lo largo de estos años.
Un agradecimiento muy especial para mi familia y amigos por su paciencia, ánimos,
comprensión y principalmente por estar incondicionalmente conmigo durante estos años. Y
gracias a los que ya no están hoy conmigo, pero que siempre me acompañan.
De Walter:
A mis padres por su aliento continuo, que hace posible la concreción de este gran proyecto.
A mi pareja por su infinita paciencia y sosiego.
A mis hermanos por ser parte de mí.
De Andres y Walter:
A Ricardo, por su guía, recomendaciones y sugerencias durante el desarrollo de esta tesina,
pero sobre todo por la motivación y el apoyo recibido.
A Gastón, compañero y amigo, por aportarnos su experiencia y sapiencia a lo largo de la
carrera.
Andres E. Martinovic
Walter D. Etchart
pág. 3
RESUMEN El mundo de las Comunidades Rurales Aisladas es muy amplio y diverso. Para los objetivos
de esta tesina no resulta necesario entrar en el análisis de su diversidad, sino más bien en el
de los elementos que las unen, fundamentalmente, la ausencia de infraestructuras básicas
(recursos energéticos básicos), vital para alcanzar unos niveles de bienestar y desarrollo
razonables. Esta problemática, en principio, es afrontada por organismos gubernamentales
mediante el uso de equipos que utilizan energías renovables o alternativas. Dada la poca
frecuencia con que se realizan las salidas por mantenimiento, muchas veces suele ocurrir que
las baterías de los equipos se desgastan más rápido de lo previsto o que los equipos sufren
fallas inesperadas.
En la actualidad, no existen mecanismos implementados para llevar un control más preciso de
estos equipos, por lo que los mantenimientos son estipulados cada ciertos intervalos regulares
de tiempo, basados en la experiencia de los técnicos. Sin embargo, si estos equipos contarán
con la capacidad de informar su estado (por ejemplo, si pudieran transmitir la corriente que
están generando) se podría determinar si el equipo está funcionando adecuadamente y así
tener un control más preciso del funcionamiento de los mismos.
Esta problemática permite tener una base interesante y comprometida socialmente para
ahondar en conceptos en pleno auge como es el caso de Internet de las Cosas.
A partir de la problemática planteada y del concepto de partida mencionado, se satisface con
el objetivo principal de este trabajo, el cual es:
● Estudiar e investigar el concepto de IoT y de diferentes protocolos de comunicación
entre sistemas, como marco de trabajo orientado a la colaboración y compartimiento
de información entre diferentes aplicaciones. Estudiar e investigar los distintos tipos
de sensores aplicables a este proyecto. Estudiar e implementar el patrón de diseño
publish/subscribe como herramienta que sirve para mejorar la eficiencia en la
comunicación e interoperabilidad entre aplicaciones.
El principal resultado de esta tesina es el desarrollo de un sistema de control que incluye
diversos conceptos a partir de lo mencionado en el objetivo principal y que está dirigido a
aportar en la problemática de las Comunas Rurales Aisladas.
pág. 4
ÍNDICE AGRADECIMIENTOS _______________________________________________________________________________ 2
RESUMEN ____________________________________________________________________________________________ 3
CAPÍTULO 1: INTRODUCCIÓN _______________________________________________________________ 7
1 Definición del problema ___________________________________________________________________________ 7
2 Objetivos ____________________________________________________________________________________________ 8
2.1 Objetivo principal ________________________________________________________________________________________ 8 2.2 Objetivo secundario ______________________________________________________________________________________ 8
3 Fundamentos _______________________________________________________________________________________ 8 3.1 Interés que despierta esta línea de investigación _______________________________________________________ 9
4 Conceptos _________________________________________________________________________________________ 10 4.1 Sistema de control ______________________________________________________________________________________ 10 4.2 Internet de las Cosas ___________________________________________________________________________________ 11
5 Organización de la tesina ________________________________________________________________________ 12
5.1 CAPÍTULO 1: Introducción___________________________________________________________________________ 12 5.2 CAPÍTULO 2: Definiendo Internet de las Cosas ____________________________________________________ 12 5.3 CAPÍTULO 3: Aspectos relevantes en torno a Internet de las Cosas ______________________________ 13 5.4 CAPÍTULO 4: Modelos de comunicación ____________________________________________________________ 13 5.5 CAPÍTULO 5: Protocolos de comunicación__________________________________________________________ 13 5.6 CAPÍTULO 6: Redes de comunicación inalámbricas y sensores ___________________________________ 13 5.7 CAPÍTULO 7: Entorno de aplicación del sistema ___________________________________________________ 14 5.8 CAPÍTULO 8: Visualización de datos ________________________________________________________________ 14 5.9 CAPÍTULO 9: Conclusiones __________________________________________________________________________ 14
CAPÍTULO 2: DEFINIENDO INTERNET DE LAS COSAS _______________________________ 15
1 Orígenes, Impulsores y Aplicaciones ___________________________________________________________ 15 1.1 Entornos para aplicaciones de IoT ______________________________________________________________________ 17
2 Buscando una Definición de IoT ________________________________________________________________ 18
3 Patrones de Comunicación ______________________________________________________________________ 20 3.1 Modelo de comunicación de dispositivo a dispositivo __________________________________________________ 20 3.2 Modelo de comunicación de dispositivo a nube ________________________________________________________ 21 3.3 Modelo de comunicación de dispositivo a puerta de enlace ____________________________________________ 22 3.4 Modelo de comunicación de intercambio de datos a través del back-end ______________________________ 24
CAPÍTULO 3: ASPECTOS RELEVANTES EN TORNO A INTERNET DE LAS COSAS ________ 26
1 Temas que se plantean en torno a Internet de las Cosas ______________________________________ 26 1.1 La Seguridad en IoT _____________________________________________________________________________________ 26
1.1.1 Consideraciones de seguridad en los dispositivos de IoT __________________________________________ 27 1.1.1.1 Desafíos de seguridad de los dispositivos de IoT _____________________________________________ 28
1.1.2 Interrogantes acerca de la seguridad en IoT ________________________________________________________ 30 1.2 La Privacidad en IoT ____________________________________________________________________________________ 32
1.2.1 Aspectos relacionados con la privacidad pertenecientes sólo a IoT _______________________________ 33 1.2.2 Interrogantes acerca de la privacidad en IoT _______________________________________________________ 34
1.3 Interoperabilidad / Normas en IoT ______________________________________________________________________ 36
pág. 5
1.3.1 Consideraciones clave y desafíos en la Interoperabilidad / Estándares de IoT ____________________ 37 1.3.2 Interrogantes acerca de la interoperabilidad en IoT ________________________________________________ 39
1.4 Aspectos reglamentarios, legales y de derechos en IoT _________________________________________________ 40 1.4.1 Protección de datos y flujos transfronterizos _______________________________________________________ 40 1.4.2 Discriminación de los datos de IoT _________________________________________________________________ 41 1.4.3 Los dispositivos de IoT utilizados como ayudas para las agencias de aplicación de la ley y la
seguridad pública _________________________________________________________________________________________ 43 1.4.4 Responsabilidad por los dispositivos de IoT _______________________________________________________ 44 1.4.5 Proliferación de dispositivos de IoT utilizados en acciones legales _______________________________ 45
1.5 Cuestiones relacionadas con las economías emergentes y el desarrollo ________________________________ 46 1.5.1 Oportunidades económicas y de desarrollo ________________________________________________________ 46 1.5.2 Aprovechar IoT para el desarrollo global __________________________________________________________ 47 1.5.3 Interrogantes acerca de IoT y su relación con las economías emergentes y su desarrollo _________ 48
CAPÍTULO 4: MODELOS DE COMUNICACIÓN _________________________________________________ 50
1 Introducción ______________________________________________________________________________________ 50
2 Los modelos Cliente/Servidor y Publicador/Suscriptor _______________________________________ 50 2.1 Modelo Cliente/Servidor ________________________________________________________________________________ 50
2.1.1 Características ______________________________________________________________________________________ 51 2.1.2 Ventajas _____________________________________________________________________________________________ 53 2.1.3 Desventajas _________________________________________________________________________________________ 54
2.2 Modelo Publicador/Suscriptor ___________________________________________________________________________ 54 2.2.1 Filtrado de mensajes ________________________________________________________________________________ 54 2.2.2 Topologías __________________________________________________________________________________________ 55 2.2.3 Ventajas _____________________________________________________________________________________________ 56 2.2.4 Desventajas _________________________________________________________________________________________ 56
2.3 Cliente/Servidor vs. Publicador/Subscriptor ____________________________________________________________ 57
CAPÍTULO 5: PROTOCOLOS DE COMUNICACIÓN ____________________________________________ 58
1 Introducción ______________________________________________________________________________________ 58
2 Protocolos _________________________________________________________________________________________ 58 2.1 OPC ______________________________________________________________________________________________________ 58
2.1.1 OPC UA ____________________________________________________________________________________________ 64 2.2 HTTP (REST/JSON) ____________________________________________________________________________________ 64 2.3 MQTT ____________________________________________________________________________________________________ 66
2.3.1 QoS para MQTT ____________________________________________________________________________________ 69 2.3.1.1 Degradación del QoS para MQTT _____________________________________________________________ 70 2.3.1.2 Niveles QoS para MQTT ______________________________________________________________________ 71
2.3.2 Conclusión __________________________________________________________________________________________ 74 2.4 CoAP _____________________________________________________________________________________________________ 75
2.4.1 Funcionalidades del Protocolo CoAP ______________________________________________________________ 77 2.4.2 Tipos de Mensajes __________________________________________________________________________________ 77 2.4.3 Soluciones Existentes _______________________________________________________________________________ 78
2.5 DDS ______________________________________________________________________________________________________ 79 2.5.1 Arquitectura _________________________________________________________________________________________ 79
2.6 AMQP ___________________________________________________________________________________________________ 80 2.6.1 Modelo AMQP _____________________________________________________________________________________ 80
2.6.1.1 Intercambiadores _______________________________________________________________________________ 82 2.6.1.2 Colas ___________________________________________________________________________________________ 82 2.6.1.3 Mensajes _______________________________________________________________________________________ 83
pág. 6
2.6.1.4 Vinculaciones __________________________________________________________________________________ 83 2.6.1.5 Tipos de intercambiadores y el efecto de las vinculaciones ___________________________________ 84
CAPÍTULO 6: REDES DE COMUNICACIÓN INALÁMBRICAS Y SENSORES _________________ 86
1 Introducción ______________________________________________________________________________________ 86
2 Redes Inalámbricas ______________________________________________________________________________ 89
3 Sensores ___________________________________________________________________________________________ 91 3.1 Características ___________________________________________________________________________________________ 91 3.2 Resolución y Precisión __________________________________________________________________________________ 92
4 Conclusión ________________________________________________________________________________________ 93
CAPÍTULO 7: ENTORNO DE APLICACIÓN DEL SISTEMA _____________________________ 95
1 Introducción ______________________________________________________________________________________ 95
2 Sistema propuesto ________________________________________________________________________________ 95 2.1 Tipo de sistema planteado _______________________________________________________________________________ 96
3 Ambiente de simulación _________________________________________________________________________ 98
4 Punto de partida del desarrollo propuesto ____________________________________________________ 107 4.1 Funcionalidades del Software __________________________________________________________________________ 110 4.2 Componentes Hardware ________________________________________________________________________________ 111
5 Manejo de datos _________________________________________________________________________________ 111 5.1 Broker ___________________________________________________________________________________________________ 115 5.2 Plataforma Web _________________________________________________________________________________________ 116 5.3 Persistencia de los datos ________________________________________________________________________________ 117
CAPÍTULO 8: VISUALIZACIÓN DE DATOS ______________________________________________ 120
1 Introducción _____________________________________________________________________________________ 120
2 Herramientas aplicables y sus características ________________________________________________ 120 2.1 Graphene ________________________________________________________________________________________________ 121 2.2 Emoncms _______________________________________________________________________________________________ 121 2.3 Freeboard _______________________________________________________________________________________________ 121 2.4 Tecnología elegida para el muestreo de datos __________________________________________________________ 122 2.5 Distintos tipos de accesos y visualización de la información __________________________________________ 131
CAPÍTULO 9: CONCLUSIONES _____________________________________________________________ 135
1 Introducción _____________________________________________________________________________________ 135
2 Aportes ___________________________________________________________________________________________ 136
3 Investigaciones futuras y mejoras sugeridas por la presente tesina _________________________ 136
BIBLIOGRAFÍA _________________________________________________________________________________ 138
pág. 7
CAPÍTULO 1:
INTRODUCCIÓN
1 Definición del problema
La provisión de energía en las zonas rurales y de baja densidad de población constituye un
problema de difícil solución técnica-económica-institucional desde el punto de vista
convencional de los sistemas centralizados. Es por ello que se están empleando soluciones
parciales de esta problemática a través de sistemas descentralizados, basados en fuentes de
energía locales y renovables, y gerenciados mediante sistemas institucionales innovativos
(privatizaciones, concesiones, subsidios parciales, etc.).
En esta situación se encuentran las comunidades rurales aisladas (CRA) donde la ausencia de
infraestructuras básicas (recursos energéticos básicos) impiden que se alcancen niveles de
bienestar y desarrollo razonables.
En el caso de los asentamientos rurales de la provincia de Chubut, éstos se caracterizan por su
dispersión en cuanto a su ubicación geográfica o al agrupamiento en pequeñas aldeas. Las
distancias que los separan entre sí con los centros urbanos, la falta de rápidos medios de
comunicación y las condiciones socioeconómicas, sumado a las características climáticas
rigurosas del invierno patagónico, crean una situación donde el abastecimiento energético
resulta fundamental para evitar situaciones de marginación.
Esta problemática, en principio, es afrontada por organismos gubernamentales mediante el
uso de energías renovables o alternativas y grupos electrógenos para la generación de energía
eléctrica. Estos organismos son los encargados, en la mayoría de los casos, de proveer los
equipos así como el mantenimiento de los mismos. Normalmente se programan viajes cada
ciertos períodos de tiempo, con el fin de realizar el mantenimiento y reabastecimiento de los
equipos. Sin embargo, las distancias y las dificultades para acceder a algunas de estas zonas
hacen que estos períodos de mantenimiento sean más prolongados, dejando a las comunas
rurales sin abastecimiento de energía, lo cual es un gran problema para las personas que allí
habitan.
Si bien los grupos electrógenos para la generación de energía parecen una solución a la
problemática de abastecimiento energético, todavía está el problema de los tiempos de
mantenimiento y reabastecimiento de combustible para que estos equipos funcionen. Es por
ello que se impulsó en diferentes provincias del país el proyecto de electrificación rural con
utilización de fuentes renovables, denominado “PERMER”. El mismo estuvo dirigido a
viviendas y establecimientos de servicios públicos rurales dispersos (escuelas, puestos
sanitarios, centros comunitarios, puestos de parques nacionales, provinciales, puestos de
gendarmería, etc.) que no disponían de la posibilidad de acceder al servicio eléctrico a través
del sistema interconectado de electricidad. Este proyecto consistió, en una primera instancia,
en la adquisición e instalación de molinos de baja potencia para la generación de energía
pág. 8
eléctrica y, en una segunda instancia, se incorporaron sistemas fotovoltaicos basados en
paneles solares para la generación de energía eléctrica destinada a iluminación y sistemas de
calentamiento de agua y calefacción, mediante termotanques solares.
Estos sistemas, basados en molinos y paneles, proporcionan un medio para el suministro de
energía a través de fuentes renovables. Sin embargo, como ocurre con los grupos
electrógenos, éstos no están exentos de fallas o averías por lo que requieren de un constante
mantenimiento. Por ejemplo, en el caso de los molinos de baja potencia, un problema
frecuente es que éstos tienden a dañarse fácilmente cuando las ráfagas de viento son muy
intensas; esto es debido a que no cuentan con sistemas automáticos de orientación de aspas
para adaptarse a los fuertes vientos y si bien cuentan con sistemas de control de freno, estos
resultan insuficientes ante velocidades de viento excesivas y variables, como es el caso de la
provincia del Chubut; dando como resultado que el rotor del molino se embale y se dañe al
punto de quedar inutilizable. En el caso de los paneles, puede ocurrir que algunas de las
celdas se dañen o entren en cortocircuito, haciendo que no entregue la cantidad de energía
suficiente para alimentar el banco de baterías.
2 Objetivos
Se han determinado una serie de objetivos a lograr con esta tesina que a continuación se
detallan:
2.1 Objetivo principal
Estudiar e investigar el concepto de IoT y diferentes protocolos de comunicación entre
sistemas, como marco de trabajo orientado a la colaboración y compartimiento de
información entre diferentes aplicaciones. Estudiar e investigar los distintos tipos de sensores
aplicables a este proyecto. Estudiar e implementar el patrón de diseño publish/subscribe
como herramienta que sirve para mejorar la eficiencia en la comunicación e interoperabilidad
entre aplicaciones.
2.2 Objetivo secundario
Desarrollar un sistema de control y comunicación que permita el tratamiento de diferentes
variables generadas en el campo de aplicación. Aplicar los conocimientos adquiridos durante
la carrera en la implementación de los módulos necesarios.
3 Fundamentos
Dada la poca frecuencia con que se realizan las salidas por mantenimiento, muchas veces
suele ocurrir que las baterías de los equipos se desgastan más rápido de lo previsto o que los
equipos sufren fallas inesperadas.
pág. 9
En la actualidad, no existen mecanismos implementados para llevar un control más preciso de
estos equipos, por lo que los mantenimientos son estipulados cada ciertos intervalos regulares
de tiempo, basados en la experiencia de los técnicos. Sin embargo, si estos equipos contarán
con la capacidad de informar su estado (por ejemplo, si pudieran transmitir la corriente que
están generando) se podría determinar si el equipo está funcionando adecuadamente y así
tener un control más preciso del funcionamiento de los mismos. Esto no solo permitiría
organizar salidas mejor programadas sino que también se podrían obtener datos relevantes
para diferentes estudios (por ejemplo, duración promedio de las baterías, vida útil de las
diferentes marcas de paneles, promedio de fallas, estudios de factibilidad de instalación de
parques eólicos, entre otros). Estos datos podrían ser de interés no solo para los organismos
responsables de los equipos sino también para otros organismos relacionados (tales como el
Ministerio de Salud de la provincia de Chubut, el Ministerio de Familia y Promoción Social
de la provincia de Chubut, entre otros) o para diferentes usuarios interesados, lo que
emparenta este desarrollo con el concepto de Internet de las Cosas.
3.1 Interés que despierta esta línea de investigación
Internet de las Cosas (IoT) es un concepto que en la actualidad está en pleno auge,
particularmente en el país no ha tenido un desarrollo considerable en comparación con otros
países que son pioneros en el tema, pero a nivel mundial cada vez se está dando mayor interés
a esta temática.
Este proyecto nos permite incursionar en el concepto de IoT para entenderlo mejor y realizar
un primer acercamiento a él y a los elementos que se requieren para su aplicación, como los
protocolos de comunicación entre sistemas. Por otro lado, hay una necesidad de fondo de
aplicar lo investigado al respecto sobre alguna idea particular que nos dé una base de
desarrollo.
La arquitectura de los sistemas de control, junto al patrón de diseño publish/subscribe, nos
proveen la base justa para llevar a cabo un desarrollo que involucre el componente IoT.
El desarrollo propuesto sobre el conjunto de conceptos mencionados (IoT y sistema de
control) nos permite, a su vez, aportar sobre una problemática que está presente en la
provincia de Chubut, particularmente, y en otras partes del país a nivel general. Esta
problemática se refiere a las comunas rurales aisladas y su dificultad tanto para adquirir
recursos energéticos como para obtener mantenimiento de los equipos que les proveen estos
recursos.
Este proyecto nos permitirá ahondar en los conceptos mencionados para aportar en la
problemática indicada aplicando distintos conceptos adquiridos a lo largo del cursado de la
carrera Licenciatura en Sistemas, lo que nos otorgará mayor experiencia y conocimiento.
pág. 10
4 Conceptos
A continuación se detallan los conceptos principales de esta tesina, los cuales dan el punto de
partida tanto del desarrollo propuesto como de otros conceptos abarcados que serán
explicados a lo largo del documento.
4.1 Sistema de control
Un sistema dinámico puede definirse conceptualmente como un ente que recibe unas
acciones externas o variables de entrada, y cuya respuesta a estas acciones externas son las
denominadas variables de salida.
Las acciones externas al sistema se dividen en dos grupos, variables de control, que se
pueden manipular, y perturbaciones sobre las que no es posible ningún tipo de control.
Dentro de los sistemas se encuentra el concepto de sistema de control. Un sistema de control
es un tipo de sistema que se caracteriza por la presencia de una serie de elementos que
permiten influir en el funcionamiento del sistema. La finalidad de un sistema de control es
conseguir, mediante la manipulación de las variables de control, un dominio sobre las
variables de salida, de modo que estas alcancen unos valores prefijados (consigna).
Un sistema de control ideal debe ser capaz de conseguir su objetivo cumpliendo los
siguientes requisitos:
1. Garantizar la estabilidad y, particularmente, ser robusto frente a perturbaciones y
errores en los modelos.
2. Ser tan eficiente como sea posible, según un criterio preestablecido. Normalmente
este criterio consiste en que la acción de control sobre las variables de entrada sea
realizable, evitando comportamientos bruscos e irreales.
3. Ser fácilmente implementable y cómodo de operar en tiempo real con ayuda de una
computadora.
Los elementos básicos que forman parte de un sistema de control y permiten su manipulación
son los siguientes:
pág. 11
● Sensores: Permiten conocer los valores de las variables medidas del sistema.
● Controlador: Utilizando los valores determinados por los sensores y la consigna
impuesta, calcula la acción que debe aplicarse para modificar las variables de control
en base a cierta estrategia.
● Actuador: Es el mecanismo que ejecuta la acción calculada por el controlador y que
modifica las variables de control.
Existen dos clases comunes de sistemas de control, sistemas de lazo abierto y sistemas de
lazo cerrado. En los sistemas de control de lazo abierto la salida se genera dependiendo de la
entrada; mientras que en los sistemas de lazo cerrado la salida depende de las consideraciones
y correcciones realizadas por la realimentación.
El sistema que se plantea en esta tesis es un sistema de lazo cerrado, dado que cada estrategia
de control/corrección se manifiesta a partir del valor entregado por los sensores disponibles,
según corresponda el caso. Este concepto se ampliará en un posterior capítulo de esta tesina.
4.2 Internet de las Cosas
A pesar de ser un tema en pleno auge y del cual muchas empresas de diferentes industrias se
están haciendo eco tratando de explotar su capacidad, no existe una definición consensuada
y/o aceptada por todos los involucrados. A continuación veremos algunas definiciones:
El Consejo de Arquitectura de Internet (Internet Architecture Board, IAB) comienza la RFC
7452,33 “Architectural Considerations in Smart Object Networking’’, con esta definición:
“El término “Internet de las Cosas” (IoT) denota una tendencia en que un gran número de
dispositivos embebidos utilizan los servicios de comunicación que ofrecen los protocolos de
Internet. A estos dispositivos suelen llamarlos “objetos inteligentes’’ y no son operados
pág. 12
directamente por un ser humano, sino que existen como componentes en edificios o
vehículos o están distribuidos en el entorno.”
Oxford Dictionaries ofrece una definición concisa que invoca a Internet como un elemento de
IoT:
“Internet de las Cosas (sustantivo): Interconexión a través de Internet de dispositivos de
computación integrados en objetos cotidianos, que les permite enviar y recibir datos.”
El Instituto de Ingeniería Eléctrica y Electrónica (Institute of Electrical and Electronics
Engineers, IEEE) está intentando generar una definición que abarque todos los aspectos
relacionados con Internet de las Cosas, en este sentido, establece una definición que aún a día
de hoy sigue abierta a cualquier colaboración que pueda producirse para mejorarla:
“En términos generales, Internet de las Cosas (IoT) es un sistema que consiste en redes de
sensores, actuadores y objetos inteligentes cuyo objetivo es interconectar "todas" las cosas,
incluyendo objetos cotidianos e industriales, de tal manera que sean inteligentes,
programables y más capaces de interactuar con los seres humanos y entre sí.”
Existen múltiples definiciones que parten de diferentes puntos de vista. Las diferentes
definiciones de IoT no necesariamente son contradictorias, sino que más bien enfatizan
diferentes aspectos del fenómeno desde diferentes puntos de vista y casos de uso.
El concepto de Internet de las Cosas se ampliará en capítulos siguientes de este documento y
se unificará un concepto en pos de abarcar los objetivos y casos de uso de este trabajo.
5 Organización de la tesina
Esta tesina se divide en los 8 capítulos que se describen a continuación:
5.1 CAPÍTULO 1: Introducción
Aquí se describe la presentación de la problemática, los objetivos perseguidos con el
desarrollo de la tesina, los conceptos centrales a investigar y exponer, y el interés que
despierta esta línea de investigación a las desarrolladores de esta tesina en particular.
5.2 CAPÍTULO 2: Definiendo Internet de las Cosas
En este capítulo se realiza una introducción y un acercamiento histórico al concepto de
Internet de las Cosas. Se detallan los entornos en donde el concepto es aplicable, ya que éstos
son diversos y se refieren a distintas industrias.
No existe una definición consensuada de Internet de las Cosas con lo cual en este capítulo
también se muestran las definiciones más relevantes y diversas, y el equipo de desarrollo de
esta tesina intenta armar, a partir de éstas, una definición lo más abarcativa posible.
pág. 13
Por último se describen los patrones de comunicación existentes para Internet de las Cosas.
5.3 CAPÍTULO 3: Aspectos relevantes en torno a Internet de las
Cosas
Los temas relacionados con Internet de las Cosas forman un amplio espectro que es difícil
abarcar, sin embargo, entre estos temas pueden destacarse resumidamente cinco, a los cuales
se hace referencia en este capítulo. Estos temas son: la seguridad; la privacidad; la
interoperabilidad y los estándares; aspectos legales, reglamentarios y de derechos; y las
economías emergentes y el desarrollo.
5.4 CAPÍTULO 4: Modelos de comunicación
En este capítulo se plantea la interoperabilidad como el gran desafío que enfrenta la
aplicación del concepto de Internet de las Cosas. Se plantean y se definen los modelos de
protocolos Cliente/Servidor y Publicador/Suscriptor como modelos globales de protocolos a
aplicar en los sistemas de Internet de las Cosas, se definen las ventajas y desventajas de cada
modelo y se realiza una comparación de ambos.
5.5 CAPÍTULO 5: Protocolos de comunicación
En el presente capítulo, se realiza un estudio de los distintos protocolos de comunicación,
tanto privados como de estándares abiertos, aplicables al desarrollo propuesto en esta tesina.
Se procede con la descripción, características, ventajas, limitaciones y funcionamiento que
presenta cada uno.
5.6 CAPÍTULO 6: Redes de comunicación inalámbricas y
sensores
Este capítulo abarca la arquitectura de Internet de las Cosas teniendo en cuenta los principales
componentes de la misma (dispositivos u objetos, infraestructura de comunicación e
infraestructura de computación). Dentro de los dispositivos se tienen en cuenta aquellos que
tienen la capacidad para interactuar con los usuarios obteniendo información mediante
sensores y actuando, mediante relés y puertos digitales, sobre su entorno. La infraestructura
de comunicación está formada a partir de redes inalámbricas, en su mayoría, que permiten el
envío de los datos recopilados por los distintos dispositivos; este capítulo define los distintos
tipos de redes inalámbricas que se pueden utilizar en un entorno de IoT.
Luego, se define un sensor como cualquier dispositivo que detecta o mide una magnitud
física y entrega una valoración de la misma, normalmente en forma de un valor digital, es
decir un valor utilizable en el “cibermundo”. A su vez, en este capítulo se mencionan los
distintos tipos de sensores de los cuales se puede hacer uso.
pág. 14
5.7 CAPÍTULO 7: Entorno de aplicación del sistema
En este capítulo se realiza una descripción de la arquitectura y de los elementos que
componen el sistema propuesto para el desarrollo mencionado para esta tesina.
Se clasifica el sistema descrito, ya que dependiendo de su funcionamiento puede ser de lazo
cerrado o de lazo abierto; en este caso, se trata de un sistema de lazo cerrado. Dentro del
capítulo se describe estos conceptos.
También se detalla el ambiente de simulación para el sistema desarrollado; en este apartado
se realiza una descripción del alcance del ambiente de simulación, el cual está acotado ya
que, por naturaleza son muchas y diversas las variables que se pueden considerar en un
sistema de este tipo.
Otro punto importante de este capítulo es la definición del manejo de los datos a relevar por
los distintos dispositivos planteados; se explica la interconexión de los elementos que abarcan
este ítem y el protocolo que éstos utilizan para cumplir con la tarea.
5.8 CAPÍTULO 8: Visualización de datos
Este capítulo contempla los distintos medios de visualización de datos, aplicables a este
desarrollo. Se plantean los diversos requerimientos que debe satisfacer la interfaz del
aplicativo para un adecuado muestreo de datos, se describen distintas soluciones disponibles
en el mercado, analizando sus ventajas y desventajas, como también las diferentes posturas
utilizadas para la elección utilizada.
Otro punto contemplado en este capítulo, es la posibilidad que brinda el aplicativo para poder
hacer uso de distintos paneles de muestreo (aparte del utilizado para este desarrollo), con el
objetivo de brindar distintos tipos de accesos para la visualización de la información que se
ajusten a las diferentes necesidades. Se realiza hincapié principalmente a paneles de muestreo
disponibles en diversas plataformas, como Android.
5.9 CAPÍTULO 9: Conclusiones
En este capítulo se realiza una integración de conceptos principales que se desean rescatar, se
hace mención a los aportes que efectúa esta tesina y se dan ideas de futuras líneas de
investigación, como de posibles mejoras a implementar que se desprenden a partir de este
trabajo.
pág. 15
CAPÍTULO 2:
DEFINIENDO INTERNET DE LAS
COSAS
1 Orígenes, Impulsores y Aplicaciones
El término “Internet de las Cosas” (IoT) fue empleado por primera vez en 1999 por el
pionero británico Kevin Ashton para describir un sistema en el cual los objetos del mundo
físico se podían conectar a Internet por medio de sensores. Ashton acuñó este término para
ilustrar el poder de conectar a Internet las etiquetas de identificación por radiofrecuencia
(RFID) que se utilizaban en las cadenas de suministro corporativas para contar y realizar un
seguimiento de las mercancías sin necesidad de intervención humana. Hoy en día, el término
Internet de las Cosas se ha popularizado para describir escenarios en los que la conectividad a
Internet y la capacidad de cómputo se extienden a una variedad de objetos, dispositivos,
sensores y artículos de uso diario.
Aunque el término “Internet de las Cosas” es relativamente nuevo, el concepto de combinar
computadoras y redes para monitorear y controlar diferentes dispositivos ha existido durante
décadas. Por ejemplo, a fines de la década de 1970 ya había en el mercado sistemas
disponibles para monitorear los medidores conectados a la red eléctrica de forma remota a
través de las líneas telefónicas. En la década de 1990, los avances en la tecnología
inalámbrica permitieron la difusión de soluciones corporativas e industriales “máquina a
máquina” (M2M) para monitorear y operar diferentes equipos. Sin embargo, muchas de estas
primeras soluciones M2M se basaban en redes dedicadas especialmente construidas para este
propósito y en estándares propietarios o específicos de la industria, no en redes basadas en el
Protocolo de Internet (IP) y los estándares de Internet.
El uso del protocolo IP para conectar a Internet dispositivos que no son computadoras no es
una idea nueva. El primer “dispositivo” para Internet, una tostadora conectada vía IP que se
podía encender y apagar a través de Internet, se presentó en una conferencia sobre Internet
realizada en 1990. Durante los años siguientes se fueron conectando otras “cosas” vía IP,
entre ellas una máquina de refrescos en la Universidad Carnegie Mellon en Estados Unidos y
una cafetera en el Trojan Room de la Universidad de Cambridge en el Reino Unido (que
permaneció conectada a Internet hasta 2001). Luego de estos inicios, una robusta área de
investigación y desarrollo dedicada a las “redes de objetos inteligentes” ayudó a sentar las
bases de Internet de las Cosas como la conocemos hoy.
Si la idea de conectar objetos entre sí y a Internet no es nueva, es razonable preguntar por qué
Internet de las Cosas es un tema que hoy en día está ganando popularidad.
pág. 16
Desde una perspectiva amplia, la confluencia de diferentes tendencias tecnológicas y de
mercado está permitiendo interconectar dispositivos más pequeños de forma económica y
sencilla:
● Conectividad Ubicua. La conectividad generalizada, de bajo costo y alta velocidad,
sobre todo a través de servicios y tecnología inalámbrica con y sin licencia, hace que
casi todo sea “conectable“.
● Adopción generalizada de redes basadas en el protocolo IP. El protocolo IP se ha
convertido en el estándar dominante para la creación de redes y ofrece una plataforma
bien definida y ampliamente implementada en software y herramientas que se pueden
incorporar en una variedad de dispositivos de forma fácil y económica.
● Economías en la capacidad de cómputo. Impulsada por las inversiones de la
industria en las áreas de investigación, desarrollo y fabricación, la Ley de Moore1
continúa ofreciendo mayor potencia de cálculo a precios más bajos y con menor
consumo de energía.
● Miniaturización. Los avances logrados en la fabricación permiten incorporar
tecnología de cómputo y comunicaciones de vanguardia en objetos muy pequeños2.
Junto con una mayor economía en la capacidad de cómputo, esto ha impulsado el
desarrollo de sensores pequeños y de bajo costo que a su vez impulsan muchas
aplicaciones de IoT.
● Avances en el análisis de datos. La existencia de nuevos algoritmos y el rápido
aumento de la potencia de cálculo, el almacenamiento de datos y los servicios en la
nube permiten agregar, correlacionar y analizar grandes cantidades de datos. Estos
conjuntos de datos grandes y dinámicos ofrecen nuevas oportunidades para extraer
información y conocimiento.
● Surgimiento de la computación en la nube. La computación en la nube aprovecha
recursos informáticos remotos conectados en red para procesar, gestionar y almacenar
datos. Este paradigma permite que dispositivos pequeños y distribuidos interactúen
con potentes sistemas de soporte que brindan capacidades analíticas y de control.
Desde este punto de vista, IoT representa la convergencia de una variedad de tendencias en
las áreas de la computación y la conectividad que se vienen dando desde hace muchas
décadas. En la actualidad, una amplia gama de sectores de la industria (entre ellos el sector
automotriz, de salud, de manufactura, la electrónica de consumo y para el hogar) están
1 La Ley de Moore tomó su nombre de Gordon Moore, pionero en el estudio de los semiconductores, quien observó que en los
circuitos integrados el número de transistores por pulgada cuadrada se duplica aproximadamente cada dos años, lo que
permite colocar mayor potencia de cálculo en chips cada vez más pequeños.
2 Además de otros avances técnicos, la miniaturización de los dispositivos electrónicos también es impulsada por la ley de
Moore.
pág. 17
analizando el potencial de incorporar la tecnología de IoT en sus productos, servicios y
operaciones, e incluso, algunos de ellos, ya la han incorporado.
Muchas organizaciones han desarrollado sus propias taxonomías y clasificaciones de las
aplicaciones de IoT y sus casos de uso. Por ejemplo, “IoT industrial” es un término
ampliamente utilizado por empresas y asociaciones para describir aplicaciones de IoT que se
relacionan con la producción de bienes y servicios, por ejemplo, en la industria
manufacturera y los servicios públicos. Otros discuten IoT según el tipo de dispositivo, por
ejemplo, dispositivos para vestir y electrodomésticos. Aún otros abordan IoT en el contexto
de implementaciones integradas basadas en su ubicación, por ejemplo “hogares inteligentes”
o “ciudades inteligentes’’. Sea cual fuera la aplicación, es evidente que los casos de uso de
IoT se podrían extender a casi todos los aspectos de nuestras vidas.
A medida que crece el número de dispositivos conectados a Internet, se espera que la
cantidad de tráfico que generan aumente significativamente. Por ejemplo, Cisco estima que el
tráfico generado por dispositivos que no son computadoras personales aumentará del 40% en
2014 a casi el 70% en 2019. También pronostica que el número de conexiones M2M
(incluyendo las aplicaciones industriales, residenciales, para el cuidado de la salud,
automotrices y otros mercados verticales de IoT) aumentará del 24% de todos los dispositivos
conectados en 2014 al 43% en 2019.
Una consecuencia de esta tendencia podría ser un cambio en la relación usuario-Internet, que
podría estar desembocando en una interacción más pasiva de los usuarios y más activa de los
dispositivos; estos dispositivos envían y reciben datos en nombre del usuario, con poca
intervención humana e incluso sin que nadie tenga conciencia de lo que está ocurriendo.
La potencial realización de este resultado (un “mundo hiperconectado”) es una prueba de la
naturaleza de propósito general de la arquitectura de Internet, que no impone limitaciones
inherentes a las aplicaciones o servicios que pueden hacer uso de la tecnología3.
1.1 Entornos para aplicaciones de IoT
● Cuerpo humano. Dispositivos unidos al cuerpo humano o colocados dentro del
mismo. Por ejemplo, dispositivos (para ingerir o ingeribles) para monitorear y
mantener la salud y el bienestar de las personas, manejar enfermedades, aumentar la
aptitud física y la productividad.
● Hogar. Edificios de viviendas. Por ejemplo, controladores y sistemas de seguridad
para el hogar.
● Puntos de ventas. Espacios comerciales. Por ejemplo, tiendas, bancos, restaurantes,
estadios, cualquier lugar donde los consumidores consideren y compren; sistemas de
autopago, ofertas en compras presenciales, optimización del inventario.
3 Si desea leer una discusión más detallada sobre las características fundamentales de Internet y su arquitectura, consulte el
trabajo de la Internet Society titulado “Internet Invariants: What Really Matters,” disponible en http://www.internetsociety.org/internet-invariants-what-really-matters
pág. 18
● Oficinas. Espacios donde trabajan trabajadores del conocimiento. Por ejemplo,
gestión de la energía y la seguridad en los edificios de oficinas; mejora de la
productividad, incluso para los empleados móviles.
● Vehículos. Sistemas dentro de vehículos en movimiento. Vehículos, incluyendo
automóviles, camiones, barcos, aviones y trenes; mantenimiento basado en la
condición, diseño, uso, análisis de preventa.
● Ciudades. Entornos urbanos. Espacios públicos e infraestructura en entornos urbanos;
sistemas de control adaptativo de tráfico, contadores inteligentes, monitoreo
ambiental, gestión de recursos.
● Exteriores. Entre entornos urbanos (y fuera de otros entornos). Los usos exteriores
incluyen las vías de ferrocarril, los vehículos autónomos (fuera de los centros
urbanos) y la navegación aérea; el enrutamiento en tiempo real, la navegación
conectada, el seguimiento de envíos.
2 Buscando una Definición de IoT
A pesar de ser un tema en pleno auge y del cual muchas empresas de diferentes industrias se
están haciendo eco tratando de explotar su capacidad, no existe una definición consensuada
y/o aceptada por todos los involucrados. Incluso, algunas definiciones involucran el concepto
de Internet y el Protocolo de Internet (IP) y otras no. A continuación veremos algunas
definiciones:
El Consejo de Arquitectura de Internet (Internet Architecture Board, IAB) comienza la RFC
7452,33 “Architectural Considerations in Smart Object Networking’’, con esta definición:
“El término “Internet de las Cosas” (IoT) denota una tendencia en que un gran número de
dispositivos embebidos utilizan los servicios de comunicación que ofrecen los protocolos de
Internet. A estos dispositivos suelen llamarlos “objetos inteligentes’’ y no son operados
directamente por un ser humano, sino que existen como componentes en edificios o
vehículos o están distribuidos en el entorno.”
La Recomendación ITU–T Y.2060 que publicó la Unión Internacional de
Telecomunicaciones (UIT) en 2012, Overview of the Internet of things, discute el concepto
de interconectividad, pero no vincula a IoT específicamente con Internet:
“3.2.2 Internet de las Cosas (IoT): Infraestructura mundial para la sociedad de la
información que propicia la prestación de servicios avanzados mediante la interconexión
de objetos (físicos y virtuales) gracias a la interoperatividad de tecnologías de la
información y la comunicación presentes y futuras.
Nota 1 — Gracias a la identificación, la adquisición y el procesamiento de datos y a las
capacidades de comunicación, IoT hace pleno uso de los objetos para ofrecer servicios a
pág. 19
todo tipo de aplicaciones, garantizando a su vez el cumplimiento íntegro de los requisitos
de seguridad y privacidad.
Nota 2 — Desde una perspectiva más amplia, IoT puede considerarse una noción con
repercusiones tecnológicas y sociales.”
Esta definición incluida en una convocatoria de trabajos para una edición de la IEEE
Communications Magazine 17
vincula a IoT con los servicios en la nube:
“La Internet de las Cosas (IoT) es un marco en el que todas las cosas tienen una
representación y una presencia en Internet. Más específicamente, la Internet de las Cosas
tiene como objetivo ofrecer nuevas aplicaciones y servicios que sirvan de puente entre el
mundo físico y el virtual, en que las comunicaciones ‘máquina a máquina’ (M2M)
representan la comunicación básica que permite las interacciones entre las cosas y las
aplicaciones en la nube.”
Oxford Dictionaries ofrece una definición concisa que invoca a Internet como un elemento de
IoT:
“Internet de las Cosas (sustantivo): Interconexión a través de Internet de dispositivos de
computación integrados en objetos cotidianos, que les permite enviar y recibir datos.”
El Instituto de Ingeniería Eléctrica y Electrónica (Institute of Electrical and Electronics
Engineers, IEEE) está intentando generar una definición que abarque todos los aspectos
relacionados con Internet de las Cosas, en este sentido, establece una definición que aún a día
de hoy sigue abierta a cualquier colaboración que pueda producirse para mejorarla:
“En términos generales, Internet de las Cosas (IoT) es un sistema que consiste en redes de
sensores, actuadores y objetos inteligentes cuyo objetivo es interconectar "todas" las cosas,
incluyendo objetos cotidianos e industriales, de tal manera que sean inteligentes,
programables y más capaces de interactuar con los seres humanos y entre sí.”
El sitio whatis.com posee su propia definición acerca de Internet de las Cosas:
“Es un escenario en el cual se le proveen identificadores únicos y la habilidad de transferir
datos sobre una red sin requerir interacción humano-humano o humano-computadora a:
objetos, animales o personas, …”.
Todas las definiciones describen escenarios en los que la conectividad de red y la capacidad
de cómputo se extienden a una constelación de objetos, dispositivos, sensores y artículos de
uso diario que habitualmente no se consideran “computadoras”. Las diferentes definiciones
de IoT no necesariamente son contradictorias, sino que más bien enfatizan diferentes aspectos
del fenómeno desde diferentes puntos de vista y casos de uso.
Sin embargo, la variedad de definiciones podría ser una fuente de confusión en el diálogo
sobre cuestiones de IoT, sobre todo en las discusiones entre grupos de partes interesadas o
segmentos de la industria. Probablemente sea necesario desarrollar una definición única de
pág. 20
IoT, pero, a su vez, se debe reconocer que en las discusiones es necesario tener en cuenta los
diferentes puntos de vista existentes.
Para los propósitos de este trabajo, los términos “Internet de las cosas” e “IoT” en líneas
generales se refieren a la ampliación de la conectividad de red y la capacidad de cómputo a
objetos, dispositivos, sensores y elementos que habitualmente no se consideran
computadoras. Estos “objetos inteligentes” requieren una mínima intervención humana para
generar, intercambiar y consumir datos.
3 Patrones de Comunicación
Los patrones de comunicación para Internet de las Cosas son referencias que describen cómo
se distribuyen e interactúan los diferentes protagonistas que forman una red de varios
dispositivos conectados.
En marzo de 2015, el Comité de Arquitectura de Internet (IAB) dio a conocer un documento
para guiar la creación de redes de objetos inteligentes (RFC 7452), que describe un marco de
cuatro modelos de comunicación comunes que utilizan los dispositivos de IoT. Según el
mencionado documento, es posible que más de un patrón se pueda aplicar al mismo tiempo
en un producto.
A continuación se detalla cada uno de los modelos de comunicación definidos por el IAB.
3.1 Modelo de comunicación de dispositivo a dispositivo
El modelo de comunicación dispositivo a dispositivo representa dos o más dispositivos que se
conectan y se comunican directamente entre sí y no a través de un servidor de aplicaciones
intermediario. Estos dispositivos se comunican sobre muchos tipos de redes, entre ellas las
redes IP o la Internet. Sin embargo, para establecer comunicaciones directas de dispositivo a
dispositivo, muchas veces se utilizan protocolos como Bluetooth, Z-Wave o ZigBee.
Estas redes permiten que los dispositivos puedan, comunicarse e intercambiar mensajes,
adhiriéndose a un determinado protocolo de comunicación, para así lograr su función. Por lo
general, este modelo de comunicación se utiliza en aplicaciones como sistemas de
automatización del hogar, que habitualmente utilizan pequeños paquetes de datos para la
comunicación entre dispositivos con requisitos relativamente bajos en términos de la tasa de
transmisión. Los dispositivos para IoT residenciales (luminarias, interruptores, termostatos y
pág. 21
cerraduras) normalmente envían pequeñas cantidades de información (por ejemplo, un
mensaje del estado de bloqueo de una puerta o un comando para encender una luz) en un
escenario de automatización del hogar.
Según lo describe un artículo del IETF Journal, “muchas veces estos dispositivos se
relacionan en forma directa, en general tienen [mecanismos de] seguridad y confianza
integrados; además, utilizan modelos de datos específicos para cada dispositivo que
requieren esfuerzos de desarrollo redundantes [por parte los fabricantes de dispositivos]”.
Esto significa que los fabricantes deben invertir en desarrollar la forma de implementar
formatos de datos específicos de diferentes dispositivos antes que métodos abiertos que
permitan el uso de formatos de datos estándares.
Desde el punto de vista de los usuarios, esto significa que los protocolos de comunicación
dispositivo a dispositivo subyacentes no son compatibles, lo que los obliga a seleccionar una
familia de dispositivos que emplean un protocolo común. Por ejemplo, la familia de
dispositivos que utilizan el protocolo Z-Wave no es compatible de forma nativa con la familia
de dispositivos ZigBee. Si bien estas incompatibilidades limitan la capacidad de elección de
los usuarios a los dispositivos de una determinada familia de protocolos, los usuarios también
saben que los productos de una familia determinada tienden a comunicarse bien.
3.2 Modelo de comunicación de dispositivo a nube
En un modelo de comunicación de dispositivo a la nube, el dispositivo de IoT se conecta
directamente a un servicio en la nube, como por ejemplo un proveedor de servicios de
aplicaciones para intercambiar datos y controlar el tráfico de mensajes. Este enfoque suele
aprovechar los mecanismos de comunicación existentes (por ejemplo, las conexiones Wi-Fi o
Ethernet cableadas tradicionales) para establecer una conexión entre el dispositivo y la red IP,
que luego se conecta con el servicio en la nube.
Este modelo de comunicación es empleado por algunos dispositivos electrónicos de consumo
para IoT, entre ellos el Learning Thermostat de Nest Labs y el SmartTV de Samsung. En el
caso del Learning Thermostat, el dispositivo transmite los datos a una base de datos en la
nube donde se pueden usar para analizar el consumo de energía en el hogar. Además, esta
conexión a la nube permite que el usuario acceda a su termostato en forma remota, a través de
pág. 22
un teléfono inteligente o una interfaz web, y también soporta las actualizaciones del software
del termostato. Algo similar ocurre con la tecnología SmartTV de Samsung, el televisor
utiliza una conexión a Internet para transmitir información a Samsung para su análisis y para
activar las funciones interactivas de reconocimiento de voz. En estos casos, el modelo
dispositivo a la nube agrega valor para el usuario final, ya que amplía las capacidades del
dispositivo más allá de sus características nativas. No obstante, al intentar integrar
dispositivos de diferentes fabricantes pueden surgir problemas de interoperabilidad. Muchas
veces el dispositivo y el servicio en la nube son del mismo proveedor de tecnología. Si entre
el dispositivo y el servicio en la nube se utilizan protocolos de datos propietarios, el dueño
del dispositivo o el usuario podrían quedar atados a un servicio en la nube específico, lo que
limitaría o impediría el uso de proveedores de servicios alternativos. Esto generalmente se
conoce como “dependencia de un proveedor’’ (vendor lock-in), un término que abarca otras
facetas de la relación con el proveedor, como por ejemplo la propiedad y el acceso a los
datos. A la vez, los usuarios generalmente pueden confiar en que los dispositivos diseñados
para su plataforma específica se podrán integrar.
3.3 Modelo de comunicación de dispositivo a puerta de enlace
En el modelo dispositivo a puerta de enlace, o más generalmente el modelo dispositivo a
puerta de enlace de capa de aplicación (Application Layer Gateway, ALG), el dispositivo de
IoT se conecta a través de un servicio ALG como una forma de llegar a un servicio en la
nube. Dicho de otra manera, esto significa que hay un software de aplicación corriendo en un
dispositivo de puerta de enlace local, que actúa como intermediario entre el dispositivo y el
servicio en la nube y provee seguridad y otras funcionalidades tales como traducción de
protocolos o datos.
En los dispositivos de consumo se utilizan diferentes formas de este modelo. En muchos
casos, el dispositivo de puerta de enlace local es un teléfono inteligente con una aplicación
pág. 23
para comunicarse con un dispositivo y transmitir datos a un servicio en la nube. Esto suele ser
el modelo empleado con los artículos de consumo populares como los dispositivos utilizados
para llevar registro de la actividad física. Estos dispositivos no tienen capacidad nativa para
conectarse directamente a un servicio en la nube, por lo que muchas veces utilizan una
aplicación para teléfono inteligente como puerta de enlace intermedia.
Otra forma de este modelo tipo dispositivo a puerta de enlace es la aparición de dispositivos
“hub” en las aplicaciones de automatización del hogar. Se trata de dispositivos que sirven de
puerta de enlace local entre los dispositivos individuales de IoT y un servicio en la nube, pero
que también pueden reducir los problemas de interoperabilidad entre los propios dispositivos.
Por ejemplo, el hub SmartThings es un dispositivo de puerta de enlace independiente que
tiene instalados transceptores Z-Wave y Zigbee para comunicarse con ambas familias de
dispositivos. Luego se conecta al servicio en la nube SmartThings y permite que el usuario
acceda a los dispositivos usando una aplicación para teléfono inteligente y una conexión a
Internet.
Desde una perspectiva técnica más amplia, el artículo del IETF Journal explica las ventajas
del enfoque dispositivo a puerta de enlace:
“Este modelo de comunicación se usa en situaciones donde los objetos pequeños deben
interoperar con dispositivos que no utilizan el protocolo de Internet. A veces se adopta este
enfoque para integrar dispositivos que solo soportan IPv6, lo que significa que se necesita
una puerta de enlace para los dispositivos y servicios existentes que solo soportan IPv4.”
En otras palabras, este modelo de comunicación se suele utilizar para integrar nuevos
dispositivos inteligentes en un sistema heredado con dispositivos que no son interoperables
de forma nativa. Una desventaja de este enfoque es el costo y la complejidad que implican el
desarrollo del software y el sistema para la puerta de enlace de capa de aplicación.
La RFC 7452 del IAB sugiere una perspectiva para este modelo:
“Se anticipa que en el futuro se desplegarán más puertas de enlace genéricas con menores
costos e infraestructura menos compleja para los consumidores finales, las empresas y los
entornos industriales. La existencia de tales puertas de enlace será más probable si el diseño
de los dispositivos de IoT utiliza protocolos de Internet genéricos y no requiere puertas de
enlace de capa de aplicación para traducir un protocolo de capa de aplicación a otro. En
general, el uso de puertas de enlace de capa de aplicación llevará a un despliegue más
frágil, como ya se ha observado en el pasado….”
Los sistemas que utilizan el modelo de comunicación dispositivo a puerta de enlace y su
papel más amplio en el abordaje de los problemas de interoperabilidad entre dispositivos de
IoT todavía están evolucionando.
pág. 24
3.4 Modelo de comunicación de intercambio de datos a través del
back-end
El modelo de intercambio de datos a través del back-end se refiere a una arquitectura de
comunicación que permite que los usuarios exporten y analicen datos de objetos inteligentes
de un servicio en la nube en combinación con datos de otras fuentes. Esta arquitectura soporta
“el deseo del usuario de permitir que terceros accedan a los datos subidos por sus sensores”.
Este enfoque es una extensión del modelo de comunicación tipo ‘dispositivo único a la nube’,
que puede llevar a la existencia de silos de datos donde “los dispositivos de IoT suben datos a
un único proveedor de servicios de aplicaciones’’. Una arquitectura de intercambio de datos a
través del back-end permite agregar y analizar los datos recogidos de flujos obtenidos de un
solo dispositivo de IoT. Por ejemplo, a un usuario corporativo a cargo de un complejo de
oficinas le interesaría consolidar y analizar los datos de consumo de energía y otros servicios
que producen todos los sensores de IoT y los correspondientes sistemas habilitados para
Internet disponibles en las instalaciones. En el modelo ‘dispositivo único a la nube’, muchas
veces los datos que produce cada sensor o sistema de IoT queda en un silo de datos
independiente. Una arquitectura eficaz de intercambio de datos a través del back-end
permitiría que la empresa acceda y analice fácilmente, en la nube, los datos producidos por
toda la gama de dispositivos instalados en el edificio. Además, este tipo de arquitectura
facilita la portabilidad de los datos. Las arquitecturas eficaces de intercambio de datos a
través del back-end permiten que los usuarios muevan sus datos al cambiar de servicio de
IoT, rompiendo así las barreras tradicionales de los silos de datos.
El modelo de intercambio de datos a través del back-end sugiere que, para lograr la
interoperabilidad de los datos de dispositivos inteligentes alojados en la nube, se requiere un
enfoque de servicios federados4 o interfaces de programación de aplicaciones (APIs) en la
nube.
Este modelo de arquitectura es un enfoque para lograr interoperabilidad entre estos sistemas
de back-end. Como sugiere el IETF Journal, “los protocolos estándares pueden ayudar, pero
4 Un enfoque de servicios federados en la nube es aquel que combina los recursos de diferentes proveedores de servicios de
nube para satisfacer una necesidad de negocio más amplia.
pág. 25
no son suficientes para eliminar los silos de datos dado que entre proveedores son necesarios
modelos de información comunes”. En otras palabras, este modelo de comunicación es
apenas tan eficaz como los diseños de los sistemas subyacentes de IoT. Las arquitecturas de
intercambio de datos a través del back-end no pueden superar completamente los diseños de
los sistemas cerrados.
pág. 26
CAPÍTULO 3:
ASPECTOS RELEVANTES EN
TORNO A INTERNET DE LAS
COSAS
1 Temas que se plantean en torno a Internet de las
Cosas
El abanico de temas relacionados con Internet de las Cosas forma un amplio espectro que es
difícil abarcar, sin embargo, entre estos temas pueden destacarse, resumidamente, cinco de
los cuales se ofrece un desarrollo a continuación. Estos temas son: la seguridad; la
privacidad; la interoperabilidad y los estándares; aspectos legales, reglamentarios y de
derechos; y las economías emergentes y el desarrollo.
1.1 La Seguridad en IoT
Como usuarios de Internet, tenemos que tener un alto grado de confianza en que Internet, sus
aplicaciones y los dispositivos conectados a la red son lo suficientemente seguros como para
realizar en línea toda la gama de actividades que deseamos en relación con la tolerancia al
riesgo asociado con tales actividades. En este sentido, Internet de las Cosas no es diferente y
la seguridad de IoT está fundamentalmente relacionada con la capacidad de los usuarios de
confiar en su entorno. Si los usuarios no creen que los dispositivos que tienen conectados y su
información están razonablemente seguros contra el mal uso o los daños, la erosión de la
confianza resultante provoca una renuencia a usar Internet.
En efecto, para garantizar la seguridad en los productos y servicios de IoT, el sector debe
considerar la seguridad como una de sus máximas prioridades.
A medida que conectamos cada vez más dispositivos a Internet, surgen nuevas oportunidades
para explotar potenciales vulnerabilidades de seguridad. Los dispositivos de IoT mal
asegurados sirven como puntos de entrada para ciberataques, permitiendo que personas
malintencionadas reprogramen un dispositivo o perjudiquen su funcionamiento.
Los dispositivos de IoT mal diseñados pueden exponer los datos de los usuarios a robos,
dejando los flujos de usuarios sin una protección adecuada. Los dispositivos defectuosos o
que no funcionan bien también pueden crear vulnerabilidades. Estos problemas son tanto o
más graves en el caso de los dispositivos inteligentes pequeños, baratos y ubicuos en Internet
de las Cosas que en el caso de los equipos que tradicionalmente han sido los puntos extremos
de la conectividad a Internet. Los desafíos que imponen la competitividad de los costos y las
pág. 27
limitaciones técnicas de IoT hacen que para los fabricantes de dispositivos no sea fácil
diseñar funciones de seguridad adecuadas, potencialmente generando, a largo plazo,
vulnerabilidades en la seguridad y dificultades en el mantenimiento, superiores a las
computadoras tradicionales.
Junto con posibles deficiencias en el diseño de la seguridad, el enorme aumento del número y
la variedad de los dispositivos de IoT podría aumentar las oportunidades de ataque. Sumado a
la naturaleza altamente interconectada de los dispositivos de IoT, cada dispositivo mal
asegurado conectado en línea potencialmente afecta la seguridad y la resistencia de Internet a
nivel global, no sólo a nivel local. Por ejemplo, una heladera o un televisor sin protección
infectado con malware que se encuentra en Argentina pueden enviar miles de correos
electrónicos no deseados dañinos a destinatarios de todo el mundo usando la conexión Wi-Fi
de la casa.5
En un mundo hiperconectado, nuestra capacidad de funcionar diariamente sin dispositivos o
sistemas conectados a Internet probablemente disminuirá. De hecho, es cada vez más difícil
comprar ciertos dispositivos sin conexión a Internet, ya que algunos fabricantes solo ofrecen
productos conectados. Dependiendo el dispositivo conectado, si se ve comprometido en un
ataque cibernético, quizá podríamos desenchufarlo, pero no es tan fácil apagar un medidor
inteligente de energía eléctrica, un sistema de control de tráfico o un marcapasos si estos
dispositivos son víctimas de un ataque malicioso. Por esta razón, la seguridad de los
dispositivos y servicios de IoT debe ser un importante punto de discusión y un tema crítico.
1.1.1 Consideraciones de seguridad en los dispositivos de IoT
La seguridad de los dispositivos de IoT no es una proposición binaria del tipo
seguro/inseguro, por el contrario, resulta útil conceptualizar la seguridad de IoT como un
espectro de vulnerabilidad de los dispositivos. El espectro parte desde dispositivos totalmente
desprotegidos sin ninguna función de seguridad hasta sistemas muy seguros con múltiples
capas de elementos de seguridad.
La seguridad general y la resiliencia de Internet de las Cosas dependen de cómo se evalúen y
gestionen los riesgos de seguridad. La seguridad de un dispositivo se define en función del
riesgo de que un dispositivo se vea comprometido, del daño que tal compromiso provocaría y
del tiempo y los recursos necesarios para lograr cierto nivel de protección. Si un usuario no
puede tolerar un alto nivel de riesgo (por ejemplo, un operador de un sistema de control de
tráfico o una persona a quien se le ha implantado un dispositivo médico que está conectado a
Internet), puede que dicho usuario sienta que se justifica gastar una cantidad considerable de
recursos para proteger el sistema o el dispositivo contra un ataque. Del mismo modo, si a la
persona no le preocupa que su heladera pueda ser hackeada y utilizada para enviar spam,
puede que no se sienta obligada a pagar por un modelo que tenga un diseño de seguridad más
sofisticado si esto hace que el dispositivo sea más costoso o complicado.
5
Starr, Michelle. “Fridge Caught Sending Spam Emails in Botnet Attack - CNET.” CNET, 19 de enero de 2014.
http://www.cnet.com/news/fridge-caught-sending-spam-emails-in-botnet-attack/
pág. 28
En esta evaluación y cálculo de la mitigación de los riesgos influyen una comprensión clara
de los riesgos de seguridad actuales y posibles riesgos futuros, la estimación de los costos
económicos y otros tipos de daño si los riesgos se hacen realidad, y el costo estimado de la
mitigación de los riesgos6. Si bien este tipo de concesiones de seguridad muchas veces se
realizan desde la perspectiva de los usuarios individuales y las organizaciones, también es
importante tener en cuenta la interrelación de los dispositivos de IoT como parte de un
ecosistema mayor. La conectividad en red de los dispositivos de IoT significa que las
decisiones de seguridad que se toman a nivel local con respecto a un dispositivo pueden tener
impactos globales sobre otros dispositivos.
Como cuestión de principio, quienes desarrollan objetos inteligentes para Internet de las
Cosas tienen la obligación de garantizar que estos dispositivos no expongan los bienes de sus
propios usuarios ni de otras personas a potenciales daños. Como cuestión de negocios y de
economía, los fabricantes desean reducir sus costos, su complejidad y su tiempo de
comercialización. Por ejemplo, son comunes los dispositivos de IoT de alto volumen y bajo
margen de ganancia que representan un costo adicional para los productos en los que están
embebidos; añadir más memoria y un procesador más rápido para implementar medidas de
seguridad podría hacer que el producto ya no fuera competitivo.
En términos económicos, el resultado de la falta de seguridad en los dispositivos de IoT es
una externalidad negativa, donde una o más partes imponen un costo sobre otras. Un ejemplo
clásico es la contaminación del medio ambiente, donde los costos de los daños y la limpieza
(externalidades negativas) resultantes de las acciones de quien contamina son asumidos por
otras partes.
De acuerdo con Bruce Schneier7, en el caso de la seguridad de información surge una
externalidad cuando el proveedor que crea el producto no corre con los costos que ocasionan
las potenciales inseguridades; en este caso, una ley de responsabilidad puede convencer a los
vendedores para que tomen en cuenta la externalidad y desarrollen más productos de
seguridad.
Estas consideraciones de seguridad no son nuevas en el contexto de la tecnología de la
información, pero la magnitud de los desafíos que pueden surgir en las implementaciones de
IoT las vuelve extremadamente significativas. Estos desafíos se describen a continuación.
1.1.1.1 Desafíos de seguridad de los dispositivos de IoT
Muchos dispositivos de Internet de las Cosas (por ejemplo, los sensores y los artículos de
consumo) están diseñados para ser desplegados a una escala masiva que es varios órdenes de
magnitud superior a la de los dispositivos tradicionalmente conectados a Internet. Por
consiguiente, la potencial cantidad de enlaces interconectados entre estos dispositivos no
6
Varias organizaciones han desarrollado guías para la evaluación de riesgos. Por ejemplo, la Organización Internacional de
Normalización (ISO) y la Comisión Electrotécnica Internacional (IEC) publicaron la norma ISO/IEC 31010:2009 “Gestión de riesgos – Técnicas de evaluación de riesgos”. http://www.iso.org/iso/catalogue_detail?csnumber=51073
7 El artículo de Bruce Scheiner está disponible en el siguiente enlace:
https://www.schneider.com/essays/archives/2007/01/information_security_1.html
pág. 29
tiene precedentes. Además, muchos de estos dispositivos podrán establecer enlaces y
comunicarse con otros dispositivos por sí mismos, de manera impredecible y dinámica. Por lo
tanto, puede ser necesario considerar nuevamente las herramientas, métodos y estrategias
existentes asociadas con la seguridad de IoT.
Muchos despliegues de IoT consistirán en colecciones de dispositivos idénticos o
prácticamente idénticos. Esta homogeneidad amplifica el potencial impacto de cualquier
vulnerabilidad de seguridad simplemente por la gran cantidad de dispositivos que tienen las
mismas características. Por ejemplo, una vulnerabilidad en el protocolo de comunicación de
una marca de luminarias conectadas a Internet se podría extender a todas las marcas y
modelos de dispositivos que utilizan el mismo protocolo o que comparten características
clave de diseño o fabricación.
Muchos de los dispositivos de la Internet las Cosas que se van a desplegar tendrán una vida
útil anticipada muy superior a la que típicamente se espera para los equipos de alta
tecnología. Además, estos dispositivos se podrían desplegar en circunstancias que los harían
difíciles o imposibles de re configurar o actualizar; o bien estos dispositivos podrían
sobrevivir a la empresa que los creó, lo que los dejaría huérfanos y sin apoyo a largo plazo.
Estos escenarios ilustran que los mecanismos de seguridad que son adecuados en el momento
del despliegue podrían no ser adecuados durante toda la vida útil del dispositivo y a medida
que las amenazas a la seguridad evolucionen. Esta situación podría crear vulnerabilidades que
podrían persistir por mucho tiempo. El apoyo y la gestión a largo plazo de los dispositivos de
IoT representa un importante reto de seguridad.
Muchos dispositivos de IoT estén diseñados intencionadamente sin ninguna posibilidad de
actualización; en otros, el proceso de actualización es engorroso o poco práctico. Por
ejemplo, consideremos el retiro de 1.4 millones de automóviles Fiat Chrysler 2015 para
arreglar una vulnerabilidad que potencialmente permitiría hackear el vehículo en forma
inalámbrica. Estos vehículos se deben llevar a un concesionario Fiat Chrysler para que les
realicen una actualización manual del software, o bien los propietarios deben actualizar el
software por sí mismos usando una memoria USB. La realidad es que un alto porcentaje de
estos automóviles probablemente no se actualizará porque el proceso de actualización
representa un inconveniente para los propietarios, y esto los deja permanentemente
vulnerables a las amenazas de seguridad cibernética, sobre todo porque el automóvil parece
estar funcionando muy bien.
Muchos dispositivos de IoT funcionan de modo que es escasa o nula la visibilidad que tiene
el usuario de su funcionamiento interno o de los flujos de datos que producen. Si un usuario
cree que un dispositivo está ejecutando ciertas funciones pero en realidad está ejecutando
funciones no deseadas o recogiendo más información que lo que el usuario desea, se crea una
vulnerabilidad. Las funciones del dispositivo también podrían cambiar sin previo aviso
cuando el fabricante ofrece una actualización, lo que deja al usuario vulnerable a cualquier
cambio que realice el fabricante.
pág. 30
Al igual que muchos sensores ambientales, algunos dispositivos de IoT han sido diseñados
para ser integrados discretamente en su entorno, donde los usuarios apenas se den cuenta de
su presencia o monitoreen su funcionamiento. Además, los dispositivos pueden no tener una
forma clara de alertar al usuario cuando surge un problema de seguridad, por lo que es difícil
para un usuario saber que la seguridad de un dispositivo de IoT ha sido vulnerada. Esta
situación podría persistir por mucho tiempo antes de ser detectada y corregida; incluso podría
darse el caso de que no fuera posible o práctico implementar una corrección o mitigación. Del
mismo modo, el usuario podría no ser consciente de que existe un sensor en su entorno, por
lo que potencialmente un fallo de seguridad podría persistir por mucho tiempo sin ser
detectado.
También podrían darse los casos en que sea imposible asegurar los dispositivos de forma
física por estar desplegados en lugares a los que sea muy difícil acceder; y, además, es
preciso considerar el caso en el que un desarrollador o un grupo de desarrolladores
construyan su propia Internet de las Cosas, donde estos despliegues podrían no aplicar los
estándares de mejores prácticas de seguridad de la industria.
1.1.2 Interrogantes acerca de la seguridad en IoT
La seguridad plantea un escenario confuso y repleto de dudas a partir de los problemas que
pueden surgir al implementar una red de dispositivos masiva como se proyecta con el
concepto de IoT. La importancia de poder resolver estos interrogantes radica en la magnitud
de despliegue de los dispositivos conectados.
Se pueden mencionar distintos temas con sus respectivos interrogantes:
● Buenas prácticas de diseño. Se plantean dudas acerca de cuáles son las mejores
prácticas que se deben utilizar al diseñar la seguridad de los dispositivos; como se
transmiten la información, recursos y lecciones aprendidas a la comunidad creciente
de desarrolladores e ingenieros participantes de IoT.
● Equilibrio entre costo y seguridad. Preguntas sobre los métodos para cuantificar y
evaluar los riesgos de la seguridad; la fuente de motivación de los fabricantes para
aceptar las responsabilidades de sus decisiones de seguridad al fabricar los
dispositivos; las condiciones para que la seguridad permita la explotación de
oportunidades de innovación, sociales y de crecimiento económico.
● Estándares e indicadores. El papel de los estándares técnicos y operativos en el
desarrollo de dispositivos seguros; la forma de identificación y medición de las
características de seguridad; el aseguramiento de la implementación de mejores
prácticas; etc.
● Confidencialidad de los datos, autenticación y control de acceso. Se expone la
duda acerca del papel óptimo del cifrado de datos al intentar dar una solución a los
potenciales intentos de espionaje y control de flujos de datos; cual es la mejor
tecnología de cifrado y autenticación aplicable a los dispositivos de IoT teniendo en
pág. 31
cuenta costos, tamaños y velocidad de procesamiento de los mismos; que procesos
son los suficientemente seguros para ser utilizados por el usuario típico.
● Capacidad de actualización en campo. Se plantea la duda acerca de cómo se
procederá para realizar la actualización de los dispositivos in situ, dado que se espera
de ellos una larga durabilidad. El interrogante también pasa por si existe la posibilidad
de hacer uso de un agente integrado de gestión, para instalar y configurar nuevo
software, sin elevar excesivamente los costos y la complejidad teniendo en cuenta que
se trata de la aplicación de estos agentes en dispositivos de uso masivo.
● Responsabilidad compartida. ¿Es posible la responsabilidad compartida y la
colaboración de todas las partes interesadas en pos de la seguridad de IoT?
● Regulación. Dudas acerca de si es posible aplicar sanciones a fabricantes y
diseñadores de dispositivos por fallos de seguridad conocidos y desconocidos;
ampliación o adaptación de leyes para que abarquen las externalidades negativas de
los dispositivos de IoT; en vista de la evolución de la tecnología de IoT y de las
amenazas de seguridad, se plantea el interrogante acerca de si la regulación podrá
seguir la misma línea de evolución.
● Obsolescencia de los dispositivos. De qué forma se debe tratar a los dispositivos que,
a medida que Internet evoluciona, quedan obsoletos; ¿Es posible incluir una
funcionalidad que inactive dichos dispositivos? Y en este caso, ¿Cuáles serían las
implicaciones de su desactivación?
La amplitud de estas preguntas es representativa de la variedad de las consideraciones de
seguridad asociadas con los dispositivos de Internet de las Cosas. En este sentido, y teniendo
en cuenta que cualquier dispositivo conectado a Internet forma parte de Internet, es necesario
considerar un enfoque colaborativo de parte de todos los involucrados para lograr soluciones
de seguridad eficaces y apropiadas.
Tanto entre la industria como entre los gobiernos y las autoridades públicas, el modelo
colaborativo aparece como un enfoque eficaz para ayudar a asegurar a Internet y al
ciberespacio, incluso a Internet de las Cosas. Este modelo incluye una serie de prácticas y
herramientas que incluyen el intercambio de información bidireccional y voluntario,
herramientas de aplicación eficaces, preparación para incidentes y ejercicios cibernéticos,
creación de conciencia y capacitación, acuerdo sobre las normas de comportamiento
internacionales, y desarrollo y reconocimiento de prácticas y estándares internacionales. Es
necesario continuar trabajando para que sigan evolucionando los enfoques colaborativos y
basados en la gestión de riesgos, de manera de lograr que se adapten bien a la escala y la
complejidad de los desafíos de seguridad de los dispositivo de Internet de las Cosas del
futuro.
pág. 32
1.2 La Privacidad en IoT
El respeto por las expectativas y los derechos de privacidad es fundamental para asegurar la
confianza en Internet; además, también afecta la capacidad de las personas de hablar,
conectarse y escoger de formas significativas. Estos derechos y expectativas se suelen
enmarcar en términos del manejo ético de los datos, que hace hincapié en la importancia de
respetar las expectativas de privacidad del individuo y el uso legítimo de sus datos. Internet
de las Cosas puede desafiar estas tradicionales expectativas de privacidad.
IoT suele referirse a una amplia red de dispositivos con sensores diseñados para recopilar
datos acerca de su entorno, que muchas veces incluyen datos relacionados con las personas.
Estos datos presumiblemente proporcionan un beneficio al fabricante o proveedor. La
recopilación y el uso de los datos se convierte en una consideración de privacidad cuando las
expectativas de privacidad de quienes son observados por los dispositivos de IoT difieren de
las de quienes recogerán y usarán estos datos.
También hay combinaciones de flujos de datos de IoT aparentemente inocentes que también
pueden poner en riesgo la privacidad. Cuando se combinan o correlacionan flujos de datos
individuales, el retrato digital que se obtiene de las personas suele ser más invasivo que el
que se puede obtener a partir de un flujo de datos individual. Por ejemplo, un cepillo de
dientes con conexión a Internet puede recoger y transmitir información sobre los hábitos de
cepillado de una persona, algo bastante inocuo. En cambio, si la heladera de este mismo
usuario informa el listado de alimentos que consume, y si además el dispositivo que el
usuario utiliza para llevar cuenta de su actividad física también informa los datos
correspondientes, la combinación de estos flujos de datos presenta una descripción mucho
más detallada y privada de la salud general de la persona. Este efecto de agregación de los
datos puede ser particularmente potente en el caso de los dispositivos de IoT, dado que
muchos producen otros metadatos como por ejemplo marcas de tiempo e información de
geolocalización, lo que aumenta aún más la especificidad del usuario.
En otras situaciones, el usuario puede no ser consciente de que un dispositivo está recogiendo
datos sobre su persona y potencialmente compartiéndolos con terceros. Este tipo de
recolección de datos es cada vez más frecuente en los dispositivos de consumo, como por
ejemplo en los televisores inteligentes y las consolas de videojuegos. Este tipo de productos
tienen características de reconocimiento de voz o de visualización que permanentemente
escuchan las conversaciones u observan la actividad en una habitación y selectivamente
transmiten los datos recogidos a un servicio en la nube para su procesamiento, donde a veces
participa un tercero. Una persona podría estar en presencia de este tipo de dispositivos sin
saber que sus conversaciones o actividades están siendo monitoreadas o que sus datos están
siendo registrados. Estos tipos de características pueden ser un beneficio para un usuario
informado, pero pueden plantear un problema de privacidad para quienes no son conscientes
de la presencia de estos dispositivos y no pueden influir significativamente sobre la forma en
que se utiliza la información recogida.
pág. 33
Es fundamental abordar estos tipos de problemas de privacidad, dado que tienen
implicaciones sobre nuestros derechos básicos y nuestra capacidad colectiva de confiar en
Internet.
1.2.1 Aspectos relacionados con la privacidad pertenecientes sólo a IoT
En general, la forma en que Internet de las Cosas aumenta la viabilidad y el alcance de la
vigilancia y el seguimiento amplifica las preocupaciones relativas a la privacidad. Las
características de los dispositivos de IoT y las formas en que se utilizan redefinen el debate
sobre los temas de privacidad, ya que modifican drásticamente cómo se recogen, analizan,
utilizan y protegen los datos personales.
El modelo tradicional de privacidad de “notificación y consentimiento” en que los usuarios
hacen valer sus preferencias de privacidad interactuando, deja de funcionar cuando los
sistemas no le ofrecen al usuario ningún mecanismo de interacción. Muchas veces los
dispositivos de IoT no tienen una interfaz de usuario para configurar las preferencias de
privacidad, y en muchas configuraciones los usuarios no tienen conocimiento ni controlan la
forma en que se recogen y utilizan sus datos personales. Si consideran que los datos
recopilados no son datos personales, es posible que los proveedores de dispositivos de IoT se
sientan menos incentivados a ofrecer a los usuarios un mecanismo para que expresen sus
preferencias de privacidad. Sin embargo, la experiencia demuestra que, en realidad, los datos
que tradicionalmente no se consideran personales podrían ser o convertirse en datos
personales si se combinan con otros.
Suponiendo que se pudiera desarrollar un mecanismo eficaz que permitiera que un usuario
expresara de manera informada sus preferencias de privacidad, este mecanismo debería poder
manejar la gran cantidad de dispositivos de IoT que debe controlar cada usuario. No es
realista pensar que un usuario interactuará directamente con cada uno de los dispositivos con
que se encuentre a lo largo del día para expresar sus preferencias de privacidad. Por el
contrario, las interfaces de privacidad se deben poder escalar de acuerdo con el tamaño del
problema, sin dejar de ser completas y prácticas desde la perspectiva del usuario.
Las normas sociales y expectativas de privacidad difieren en los espacios públicos. Por
ejemplo, las tecnologías de vigilancia que utiliza IoT como las cámaras de seguridad o los
sistemas de trazabilidad de ubicación que normalmente funcionan en espacios públicos están
migrando hacia espacios tradicionalmente privados como el hogar o los vehículos
particulares, donde nuestras expectativas de privacidad son muy diferentes. Al hacerlo,
desafían lo que muchas sociedades reconocen como el derecho a la privacidad en el hogar o
los espacios privados.
Muchas veces los dispositivos de IoT funcionan en contextos donde la proximidad expone a
múltiples personas a una misma actividad de recolección de datos. Por ejemplo, el sensor de
seguimiento por geolocalización de un automóvil podría registrar los datos de localización de
todos los ocupantes del vehículo, sin importar si estas personas desean que lo haga o no.
Incluso podría realizar un seguimiento de las personas que viajan en otros vehículos cercanos.
pág. 34
En este tipo de situaciones podría ser difícil o imposible distinguir -mucho menos respetar-
las preferencias de privacidad individuales.
Los dispositivos de IoT pueden recoger información personal con un grado de especificidad y
penetración sin precedente; agregar y correlacionar estos datos permite crear perfiles
personales detallados que generan un potencial para la discriminación y otros daños. La
sofisticación de esta tecnología puede crear situaciones que expongan al individuo a daños
físicos, penales, financieros o de reputación.
La ubicuidad, familiaridad y aceptación social de muchos dispositivos de IoT pueden crear
una falsa sensación de seguridad y alentar a las personas a divulgar información confidencial
o privada sin pleno conocimiento o apreciación de las posibles consecuencias.
1.2.2 Interrogantes acerca de la privacidad en IoT
Estas preguntas referidas a la privacidad serían un desafío incluso si estuvieran bien alineados
los intereses y motivaciones de todas las partes involucradas en el ecosistema de IoT. Sin
embargo, sabemos que las relaciones y los intereses de quienes están expuestos a la
recolección de sus datos personales y quienes agregan, analizan y utilizan los datos pueden
ser desequilibrados o injustos. La fuente de datos puede ver una intrusión no deseada a su
espacio privado, muchas veces sin consentimiento, control, elección o incluso consciencia.
No obstante, quien recoge los datos podría considerarlos un recurso beneficioso que puede
añadir valor a sus productos y servicios y proporcionar nuevas fuentes de ingresos.
Dado que Internet de las Cosas desafía nuestras nociones de privacidad de formas nunca
antes vistas, al reevaluar los modelos de privacidad en línea en el contexto de IoT es
necesario responder ciertas preguntas clave.
Se pueden mencionar distintos temas con sus respectivos interrogantes:
● Legitimidad en la recopilación y el uso de los datos. En el contexto de IoT, ¿cómo
se resuelve la relación de mercado entre las fuentes de los datos y quienes los
recogen? Los datos personales tienen un valor personal y comercial diferente según se
consideren desde el punto de vista de las fuentes o de los recolectores, tanto
individualmente como en su conjunto; por lo tanto, ambas partes tienen intereses
legítimos que podrían estar en conflicto. ¿Cómo se pueden expresar estos diferentes
intereses de una manera que conduzca a reglas en materia de acceso, control,
transparencia y protección que sean justas y consistentes, tanto para las fuentes como
para los recolectores?
● Transparencia, expresión y cumplimiento de las preferencias de privacidad.
¿Cómo se puede hacer que las políticas y prácticas de privacidad sean de fácil acceso
y comprensibles en el contexto de IoT? ¿Cuáles son las alternativas al modelo
tradicional de privacidad de “notificación y consentimiento” que podrían abordar los
aspectos únicos de Internet de las Cosas? ¿Cuál sería un modelo eficaz para expresar,
aplicar y hacer cumplir las preferencias de privacidad individuales y las preferencias
pág. 35
multipartitas? ¿Se podría construir un modelo multipartito de este tipo? De ser así,
¿qué aspecto tendría? ¿Cómo se podría aplicar a circunstancias concretas que
impliquen las preferencias de privacidad individuales? ¿Existe un mercado para
tercerizar la gestión de la configuración de la privacidad a servicios comerciales
diseñados para implementar las preferencias de los usuarios? ¿Es necesario que exista
un proxy de privacidad que exprese y haga cumplir las preferencias del usuario a
través de una serie de dispositivos, al tiempo que elimine la necesidad de interacción
directa con cada uno de ellos?
● Gran variedad de expectativas de privacidad. Las normas y expectativas de
privacidad están estrechamente relacionadas con el contexto social y cultural del
usuario, que puede variar de una nación o de un grupo a otro. Muchos escenarios de
IoT implican el despliegue de dispositivos y actividades de recopilación de datos de
alcance multinacional o global que atraviesan fronteras sociales y culturales. ¿Qué
implicará esto para el desarrollo de un modelo de protección de la privacidad que se
pueda aplicar ampliamente a Internet de las Cosas? ¿Cómo se pueden adaptar los
dispositivos y sistemas de IoT para que reconozcan y respeten la variedad de
expectativas de privacidad de los usuarios y las diferentes legislaciones?
● Privacidad por diseño. ¿Cómo se puede animar a los fabricantes de dispositivos de
IoT para que incorporen los principios de la privacidad por diseño a sus valores
fundamentales? ¿Cómo se puede fomentar la inclusión de consideraciones sobre la
privacidad de los consumidores en todas las fases de desarrollo y operación de los
productos? ¿Cómo se pueden conciliar los requisitos de funcionalidad y privacidad?
En principio, los fabricantes deberían anticipar que, a largo plazo, los productos y las
prácticas que respeten la privacidad se ganarán la confianza y la satisfacción de los
clientes y generarán lealtad hacia la marca. ¿Es esta motivación suficiente para
competir con los deseos de simplicidad en el diseño y velocidad al mercado? ¿Los
dispositivos se deberían diseñar con una configuración predeterminada para el modo
de recopilación de datos más conservador (es decir, no recopilación de datos por
defecto)?
● Identificación. ¿Cómo debemos proteger los datos recogidos por IoT que parecieran
no ser personales donde se recogen o que han sido “des identificados”, pero que en
algún momento futuro podrían llegar a ser datos personales (por ejemplo, porque
podrían ser re-identificados o combinados con otros datos)?
Internet de las cosas genera desafíos únicos para la privacidad que van más allá de los
problemas que existen en la actualidad. Es necesario desarrollar estrategias para respetar las
opciones de privacidad individuales considerando un amplio espectro de expectativas, sin
dejar de fomentar la innovación en nuevas tecnologías para IoT.
pág. 36
1.3 Interoperabilidad / Normas en IoT
En la Internet tradicional, la interoperabilidad es el valor central más básico; el primer
requisito de la conectividad a Internet es que los sistemas “conectados” deben poder “hablar
el mismo idioma” en cuanto a protocolos y codificaciones. Además, es el objetivo explícito
de todo el aparato de estandarización de Internet concentrado en el Grupo de Trabajo en
Ingeniería de Internet (IRTF).
La interoperabilidad es también una de las piedras angulares de la Internet abierta. Las
barreras erigidas para obstruir el intercambio de información pueden afectar la capacidad de
los usuarios de Internet de conectarse, hablar, compartir e innovar, que son los cuatro
principios fundamentales de ISOC8. También llamadas “jardines vallados”, las plataformas
cerradas en las que los usuarios solo pueden interactuar con un subconjunto seleccionados de
sitios y servicios pueden disminuir considerablemente los beneficios sociales, políticos y
económicos que permite el acceso a la totalidad de Internet.
En un entorno totalmente interoperable, cualquier dispositivo de IoT se podría conectar a
cualquier otro dispositivo o sistema e intercambiar información si así lo desean. En la
práctica, la interoperabilidad es mucho más compleja. La interoperabilidad entre los
dispositivos y sistemas de IoT ocurre en diferentes grados en diferentes capas dentro de la
pila de protocolos de comunicación entre los dispositivos. Además, no siempre es posible,
necesario o deseable lograr la interoperabilidad plena en todos los aspectos de un producto
técnico y, de ser impuesta artificialmente (por ejemplo, a través de un mandato
gubernamental), podría desincentivar la inversión y la innovación. La estandarización y la
adopción de protocolos que especifican estos detalles de la comunicación, en particular
cuando resulta óptimo tener estándares, están en el centro de la discusión sobre la
interoperabilidad para IoT.
Más allá de los aspectos técnicos, la interoperabilidad tiene una importante influencia sobre el
potencial impacto económico de IoT. La interoperabilidad eficaz y bien definida de los
dispositivos puede fomentar la innovación u ofrecer eficiencias a quienes fabrican
dispositivos, aumentando así el valor económico total del mercado. Por otra parte, la
implementación de los estándares existentes y el desarrollo de nuevos estándares abiertos
cuando estos son necesarios ayudan a reducir las barreras de entrada, facilitan nuevos
modelos de negocio y construyen economías de escala.
Además la interoperabilidad es valiosa tanto desde el punto de vista del consumidor
individual como de las organizaciones que utilizan estos dispositivos. Facilita la capacidad de
escoger los dispositivos con las mejores características y al mejor precio e integrarlos de
manera que funcionen juntos. Los compradores podrían vacilar a hora de adquirir productos y
servicios de IoT si no existe flexibilidad en cuanto a su integración, si su propiedad es
compleja, si existe preocupación con respecto a una potencial dependencia del proveedor o en
caso de temor a su obsolescencia debido al cambio de estándares.
8 Internet Society. Ver “Values and Principles” Principles. Internet Society, 2015. http://www.internetsociety.org/who-we-
are/mission/values-and-principles
pág. 37
1.3.1 Consideraciones clave y desafíos en la Interoperabilidad / Estándares de
IoT
Sin ser exhaustiva, la lista de consideraciones y desafíos clave incluye:
● Los ecosistemas propietarios y la elección del consumidor. Algunos fabricantes de
dispositivos ven una ventaja competitiva en la creación de un ecosistema de productos
propietarios compatibles -a veces llamados “jardines vallados”- que limiten la
interoperabilidad a los dispositivos y componentes de una misma marca. Estos
fabricantes pueden generar dependencias (lock-in) en el ecosistema de sus
dispositivos, aumentando los costos en que deben incurrir los consumidores para
cambiar a otra marca o utilizar componentes de otros proveedores. Por ejemplo, en el
mercado de la domótica, las luminarias de un proveedor podrían no ser interoperables
con un sistema de interruptores de otro.
Los partidarios de la interoperabilidad consideran que estas prácticas impiden la
elección del usuario, dado que evitan que los usuarios se cambien a productos
alternativos. También consideran que estas prácticas representan una barrera para la
innovación y la competencia, ya que limitan la capacidad de los competidores de crear
nuevos productos basados en la infraestructura en la cual se sustenta el ecosistema.
Sin embargo, algunos fabricantes de dispositivos consideran que el enfoque del
ecosistema cerrado beneficia a los usuarios porque les proporciona un protocolo que
se puede adaptar con mayor rapidez y facilidad cada vez que las exigencias técnicas o
de mercado requieran un cambio.
Las consideraciones con respecto a interoperabilidad también se extienden a los datos
que recogen y procesan los servicios de IoT. Uno de los principales atractivos de los
dispositivos conectados es su capacidad de transmitir y recibir datos de los servicios
“en la nube”, que a su vez proporcionan valiosos servicios o información sobre la
base de esos datos. Si bien esto es extremadamente útil, también puede presentar
desafíos en caso que un usuario desee pasar a un servicio competidor. Incluso si el
acceso a los datos generados por los dispositivos se pone a disposición de los
usuarios, obtener los datos no servirá de nada si están en un formato propietario. Un
usuario solo podrá cambiarse a otro proveedor de servicios o analizar los datos por su
cuenta si los datos fuente están libremente disponibles para los usuarios que los
originan y en un formato abierto estándar.
● Limitaciones técnicas y de costos. A medida que los fabricantes desarrollan
dispositivos de IoT van surgiendo limitaciones técnicas, de tiempo al mercado y de
costos que hay que tener en cuenta a la hora de decidir sobre su interoperabilidad y su
diseño. Algunos dispositivos se ven limitados por factores técnicos como los recursos
de procesamiento disponibles, la memoria o las demandas de energía. Del mismo
modo, los fabricantes se ven presionados para reducir el costo unitario de los
dispositivos, reduciendo al mínimo los costos de diseño de los productos y las piezas.
Los fabricantes realizan análisis de costo-beneficio para decidir si los mayores costos
pág. 38
y las potenciales reducciones del rendimiento de los productos justifican los
beneficios adicionales que tendría la implementación de los estándares. A corto plazo,
puede ser más costoso diseñar e incluir características de interoperabilidad en un
producto y probar su conformidad con la especificación de una norma. En ciertos
contextos, el camino más económico al mercado podría ser el uso de protocolos y
sistemas propietarios. Sin embargo, esto se debe comparar con las ganancias que se
obtendrían durante el ciclo de vida a largo plazo gracias a la interoperabilidad del
producto.
● Riesgos asociados con los tiempos de mercado. En un mercado competitivo y
global, quien saca un producto y establece una cuota de mercado más rápidamente
suele tener una ventaja. Esto ciertamente se aplica a los fabricantes de dispositivos de
IoT. El problema surge cuando el cronograma de diseño del fabricante se adelanta a la
disponibilidad de los estándares de interoperabilidad. Un fabricante de dispositivos
ansioso por sacar un producto al mercado puede considerar que la falta de certeza en
cuanto a los tiempos y los procesos de desarrollo de los estándares constituye un
riesgo comercial que se debe minimizar o evitar. Esto puede hacer que las alternativas
de diseño que no contemplan estándares de interoperabilidad abiertos sean más
atractivas, especialmente a corto plazo.
● Riesgos técnicos. Como parte del proceso de desarrollo, quien fábrica o utiliza
dispositivos para Internet de las Cosas debe evaluar los riesgos técnicos de diseño de
los protocolos. Incorporar estándares existentes y comprobados en el diseño de
sistemas y productos puede implicar un riesgo técnico menor que desarrollar y utilizar
protocolos propietarios. El uso de estándares genéricos, abiertos y ampliamente
disponibles (como la familia de protocolos de Internet) como componentes de los
dispositivos y servicios puede aportar otros beneficios, como el acceso a una mayor
cantidad de talento técnico, software y una reducción de los costos de desarrollo.
● Dispositivos mal comportados. El impacto de la falta de estándares y mejores
prácticas documentadas va más allá de la limitación del potencial de los dispositivos
de IoT. De una manera pasiva, la ausencia de estas normas puede permitir el mal
comportamiento de los dispositivos. En otras palabras, sin estándares que sirvan de
guía para los fabricantes, quienes desarrollan estos dispositivos suelen diseñar
productos cuyo funcionamiento perjudica a Internet sin prestar demasiada atención al
impacto que pueden llegar a tener. Estos dispositivos son peores que aquellos que
simplemente no son interoperables. Si están mal diseñados y configurados, pueden
afectar a los recursos de red que conectan a Internet e incluso a la propia Internet.
● Sistemas heredados. La estandarización de la interoperabilidad representa un desafío
para los nuevos dispositivos de IoT que deben interactuar con los sistemas que ya
están desplegados y en funcionamiento.
pág. 39
Esto es relevante para muchos entornos específicos de ciertas industrias y
aplicaciones que ya cuentan con redes de dispositivos establecidas9. Los ingenieros
que trabajan en IoT deben llegar a un compromiso entre un diseño que mantenga la
compatibilidad con los sistemas heredados y su intención de lograr una mayor
interoperabilidad con otros dispositivos mediante la utilización de estándares.
● Configuración. Los usuarios enfrentarán cada vez mayores desafíos a medida que
aumente la cantidad de dispositivos de IoT que deban manejar.
Uno de estos desafíos es la necesidad de modificar rápida y fácilmente la
configuración de múltiples dispositivos en una red.
A la hora de enfrentar la configuración de cientos de dispositivos individuales, será
fundamental que las herramientas, métodos e interfaces a utilizar hayan sido
cuidadosamente diseñadas y estandarizadas.
● Proliferación de los esfuerzos de estandarización. Además de los tradicionales
organismos de normalización, han surgido múltiples coaliciones de la industria cuyo
objetivo es ayudar a evaluar, desarrollar, modificar o armonizar los estándares y los
protocolos relacionados con IoT. Esto incluye, por ejemplo, organismos de
normalización de larga data como el IETF, la ITU y el IEEE, además de iniciativas
comparativamente nuevas como el Industrial Internet Consortium, el Open
Interconnection Consortium, ZigBee Alliance y AllSeen Alliance, entre muchas otras.
1.3.2 Interrogantes acerca de la interoperabilidad en IoT
La interoperabilidad y los estándares plantean desafíos y preguntas que será necesario
responder para el futuro de los dispositivos de IoT. Algunos de los interrogantes que surgen
son:
● ¿En qué áreas son más necesarias y deseables las normas de interoperabilidad? ¿Son
suficientemente similares o diferentes en toda la gama de posibles aplicaciones y
casos de uso de IoT (por ejemplo, bienes de consumo, aplicaciones industriales y
aparatos médicos)? ¿Cuáles normas genéricas y ampliamente disponibles (como por
ejemplo la familia de protocolos de Internet) se podrían utilizar como componentes de
los dispositivos y servicios de IoT? ¿Cómo afectaría la falta de interoperabilidad la
capacidad de los usuarios de conectarse, hablar, compartir e innovar?
● ¿Qué funciones deben cumplir los organismos de normalización, los consorcios de la
industria y los grupos de partes interesadas en el desarrollo de estándares para IoT?
¿Qué potencial tendría reunir a la amplia gama de grupos que están trabajando en
implementaciones técnicas de IoT para una discusión más amplia sobre la
interoperabilidad y la implementación de estándares? ¿Se pueden evitar la existencia
de estándares que compitan entre sí, la duplicación de esfuerzos y los conflictos que
9 Son ejemplos de protocolos de sistemas legados: el protocolo SCADA (Supervisory Control and Data Acquisition), que se
utiliza para la comunicación de dispositivos industriales, y los protocolos CAN Bus (Control Area Network) para sensores vehiculares e industriales.
pág. 40
surgen cuando diferentes organismos y consorcios de normalización abordan temas
similares o coincidentes sin que los gastos de coordinación se vuelvan excesivos? En
términos más prácticos, ¿cómo pueden los actores de la industria y otras partes
interesadas mantenerse al tanto de todo lo que ocurre en este amplio espacio?
● ¿Cuál es el mejor enfoque para involucrar y educar a las comunidades de usuarios y
desarrolladores sobre los problemas que generan los dispositivos de IoT que no se
comportan bien y la falta de implementación de los estándares? Dada la amplia
variedad de aplicaciones y casos de uso de IoT, ¿qué tipos de mejores prácticas o
modelos de referencia de implementación serían eficaces?
● ¿Cómo afectará la Internet de las Cosas el consumo de ancho de banda y otros
recursos? ¿En qué medida será necesario modificar los estándares para dar soporte a
las necesidades cambiantes? Dada la importancia que tienen los servicios basados en
la nube para Internet de las Cosas, ¿qué desafíos plantea la interoperabilidad entre
nubes?
● En términos generales, no se puede negar la importancia de la interoperabilidad y los
estándares de IoT para el mercado y para los consumidores. En última instancia, es
fundamental incorporar el desafío de desarrollar y emplear estándares de
interoperabilidad en la discusión sobre la innovación, la competencia y la elección de
los servicios por parte del usuario, todos temas que forman parte de los básicos de
ISOC.
1.4 Aspectos reglamentarios, legales y de derechos en IoT
1.4.1 Protección de datos y flujos transfronterizos
No se puede evitar que los datos que recogen los dispositivos de IoT se envíen a través de los
límites jurisdiccionales. Estos dispositivos utilizan Internet para comunicarse e Internet
atraviesa límites jurisdiccionales a todo nivel. Los dispositivos de IoT pueden recoger datos
sobre las personas en una jurisdicción y transmitirlos a otra para su almacenamiento o
procesamiento, muchas veces sin mayores obstáculos técnicos. Esto puede convertirse
rápidamente en un problema legal, por ejemplo, si los datos recogidos se consideran datos
personales o datos sensibles y están sujetos a las leyes de protección de datos de múltiples
jurisdicciones. Para complicar aún más las cosas, las leyes de protección de datos en la
jurisdicción donde residen el dispositivo y el titular de los datos podría ser inconsistente o
incompatible con las leyes de la jurisdicción donde los datos se almacenan y procesan.
Estas situaciones se describen como flujos de datos transfronterizos y plantean preguntas con
respecto al alcance jurídico de las normas que podrían ser aplicables. En otras palabras, ¿cuál
régimen legal regula el dispositivo que recoge los datos y cuál regula el almacenamiento y el
uso de los datos recogidos? Este escenario también plantea preguntas normativas. ¿Se pueden
modificar estas leyes para reducir el grado de fragmentación de Internet que provocan y, a la
vez, proteger los derechos de los usuarios? Si una jurisdicción tiene leyes de protección de
pág. 41
datos más restrictivas en cuanto al manejo y la transmisión de determinados datos
provenientes de IoT, ¿estos requisitos legales se deberían poder proyectar a otras
jurisdicciones?
Si bien muchas de estas preguntas sobre los flujos de datos transfronterizos ya se han
planteado y abordado en el marco del tráfico de datos de la Internet tradicional, con la
inclusión de marcos regionales e internacionales (por ejemplo, las directrices de la OCDE que
regulan la protección de la privacidad, el Convenio No.108 del Consejo de Europa, el Marco
de Privacidad de APEC) y disposiciones especiales (por ejemplo, el sistema de Reglas de
Privacidad Transfronterizas de APEC, las Normas Corporativas Vinculantes de UE), los
dispositivos de IoT plantean un nuevo desafío en este sentido. Cada vez más, estos
dispositivos podrán conectarse automáticamente a otros dispositivos y sistemas y transmitir
información a través de las fronteras sin el conocimiento del usuario. Esto podría crear
situaciones en las que un usuario se podría convertir en responsable de cumplir con los
requisitos aplicables a los flujos de datos transfronterizos, incluso sin saber que esto está
ocurriendo. Estos son temas complejos y lo serán cada vez más, ya que la tecnología sigue
avanzando más rápido que las políticas.
1.4.2 Discriminación de los datos de IoT
Los datos recogidos por los dispositivos de IoT permiten formar una imagen detallada de las
personas con que interactúan y estos datos pueden ser utilizados tanto para fines beneficiosos
como para fines discriminatorios. Consideremos el caso de los dispositivos que se utilizan
para llevar registro de la actividad física. Muchas veces una persona lleva uno de estos
dispositivos de forma permanente durante un período de días o semanas; durante todo este
tiempo, el dispositivo recoge información muy detallada sobre los movimientos de la persona
y otros datos biométricos. Una aplicación analiza estos datos para determinar el estado físico
de la persona, estimar las calorías que quema, llevar un registro de las horas de sueño y
caracterizar la calidad del sueño. Este análisis es claramente beneficioso para el usuario, ya
que le ofrece una manera de cuantificar su actividad física mientras intenta alcanzar un
objetivo de pérdida de peso o aptitud física.
Pero estos mismos datos se pueden utilizar en formas potencialmente discriminatorias. En
Estados Unidos, algunos planes de seguro médico están incentivando a los participantes para
que permitan que el asegurador acceda a los datos del dispositivo a cambio de primas de
seguro más bajas10
. Esta práctica puede ser vista como positiva: ofrecer precios preferenciales
a quienes estén dispuestos a entregar sus datos biométricos a cambio de un descuento. Por
otra parte, potencialmente podría ser discriminatoria, en especial para quienes se encuentran
en desventaja económica. Los incentivos financieros para permitir que las aseguradoras y
10
“Big Doctor Is Watching”. Slate, 27 de febrero de 2015.
http://www.slate.com/articles/technology/future_tense/2015/02/how_data_from_fitness_trackers_medical_devices_could_affect_health_insurance.html
pág. 42
otros interesados accedan a la información sobre su salud podrían llegar a ser tan
convincentes que “escoger” participar sería la única opción viable11
.
Además, la calidad, la especificidad y el volumen de los datos producidos por IoT podrían
magnificar el potencial de que se generen prácticas de precios discriminatorias y servicios
ilegítimos. Con frecuencia los datos de IoT se pueden etiquetar con metadatos (marcas de
fecha y de tiempo, etiquetas de geolocalización) que aumentan dramáticamente la calidad de
los datos desde el punto de vista de su análisis. Además, los sensores de IoT suelen realizar
muy pocas funciones. Esto significa que los datos de los sensores suelen asociarse con una
situación operativa específica, que permite un alto grado de especificidad a la hora de
correlacionar los datos con una persona o con un grupo de personas. De hecho, el dispositivo
se podría llegar a asociar con la persona en la que está implantado, como en el caso de un
marcapasos o una bomba de insulina conectados a Internet.
Por último, estos dispositivos crean importantes flujos de datos continuos sin intervención
humana. La combinación de estas cualidades hace que los análisis de los datos de IoT sean
muy descriptivos y útiles para la investigación, el desarrollo de productos y también en otras
áreas. Los algoritmos de Big Data pueden examinar cantidades enormes de datos y buscar
correlaciones estadísticas y semánticas para así determinar grupos de usuarios con
características afines. A su vez, estos algoritmos podrían categorizar injustamente a los
usuarios y explotar sus características.
Este tipo de usos de los datos de IoT plantea cuestiones prácticas, legales y reglamentarios.
En primer lugar, ¿cómo podemos detectar las prácticas discriminatorias o injustas contra los
usuarios? ¿Existen prácticas discriminatorias virtualmente imposibles de detectar? ¿Existe
alguna diferencia legal en caso que la decisión de discriminar sea tomada por una persona o
por una máquina? El desarrollo de herramientas para detectar prácticas algorítmicas injustas
es un desafío para la investigación académica, sobre todo porque la mayoría de los algoritmos
de análisis de datos son secretos empresariales y no son del dominio público. ¿Cómo
podemos equilibrar los enormes beneficios comerciales y sociales del análisis de datos de IoT
con la probabilidad de que se generen prácticas discriminatorias contra los usuarios? ¿Cómo
podemos fomentar la adopción de los principios de la innovación sin pedir permiso
(permissionless innovation) en el ámbito de IoT y a la vez proteger a los usuarios contra las
prácticas ilegítimas? ¿Cómo podemos mejorar la transparencia? ¿Las leyes de privacidad y de
protección del consumidor existentes, alcanzan para hacer frente a este escenario? ¿Qué
recursos deberían estar disponibles en caso de discriminación? ¿Los dispositivos de IoT se
deberían categorizar y regular en función de la naturaleza de los datos que producen,
especialmente cuando los datos son propensos a ser mal utilizados?
11
Ibid.
pág. 43
1.4.3 Los dispositivos de IoT utilizados como ayudas para las agencias de
aplicación de la ley y la seguridad pública
Indudablemente, los dispositivos de IoT y los datos que generan pueden ser utilizados como
herramientas eficaces para luchar contra el crimen. Muchos comercios minoristas han
instalado cámaras de seguridad para recoger imágenes de video y realizar un seguimiento de
la actividad de los compradores, algo que ha resultado de gran valor como prueba en los
procesos penales y como elemento de disuasión de la delincuencia12
. Más recientemente, On-
Star Corporation, una subsidiaria de General Motors, puede proporcionar datos de los
sensores que se encuentran en el automóvil de la policía para ayudar en la recuperación de
vehículos robados y puede desactivar de forma remota un vehículo robado13
. El
Departamento de Policía del Condado de Nassau (Nueva York) utiliza una red de sensores de
sonido llamada ShotSpotter que permite detectar y localizar la fuente exacta de un disparo en
los barrios donde han sido desplegados14
. Todos estos son ejemplos de los beneficios que la
tecnología de Internet de las Cosas puede ofrecer a la policía para combatir la delincuencia y
mejorar la seguridad pública.
Sin embargo, el despliegue y uso de este tipo de tecnologías provocan preocupación entre
algunos defensores de los derechos civiles y otras personas. Entre las posibles causas de
preocupación se incluyen la omnipresencia de las actividades de monitoreo de los datos, las
políticas sobre su conservación y destrucción, los usos secundarios que los gobiernos pueden
darles, así como la potencial exposición accidental de los datos a actores maliciosos. Además,
se deben considerar cuidadosamente los efectos potencialmente negativos sobre las
actividades beneficiosas de las comunidades y sociedades monitoreadas.
Otras situaciones de orden y seguridad públicos son más complejas. Por ejemplo, al lanzar el
iPhone 6 y su sistema operativo iOS 8, Apple Corporation eliminó un método de acceso tipo
“puerta trasera” que existía en versiones anteriores de su teléfono. La función de puerta
trasera permitía a la policía acceder a los datos que se encontraban en el teléfono de un
usuario. Apple eliminó esta característica en el nuevo iPhone y ahora encripta el contenido
interno del teléfono de una manera difícil de vulnerar y para la cual Apple no tiene las claves,
por lo cual no tiene forma de permitir el acceso15
. Esto hace que solo el propietario del
teléfono pueda acceder a su contenido. Las agencias federales de seguridad sostienen que esto
hace que sea más difícil procesar los comportamientos criminales16
, mientras que los
partidarios de los derechos civiles ven en esto una victoria para la protección de la privacidad
12
Goforth Gregory, Jennifer. “5 Ways Tech Is Stopping Theft.” Entrepreneur, 7 de noviembre de 2013.
http://www.entrepreneur.com/article/229674 13
Bond, Jr., Vince. “Lawyers Reaching for In-car Data.” Automotive News, 14 de septiembre de 2014.
http://www.autonews.com/article/20140914/OEM11/309159952/lawyers-reaching-for-in-car-data 14
Weis, Todd R. “Cool Cop Tech: 5 New Technologies Helping Police Fight Crime.” Computerworld. N.p., 16 de febrero de
2012. http://www.computerworld.com/article/2501178/government-it/cool-cop-tech--5-new-technologies-helping-police-fight-crime.html?page=2 15
Timm, Trevor. “Your IPhone Is Now Encrypted. The FBI Says It’ll Help Kidnappers. Who Do You Believe?” The Guardian, 30
de septiembre de 2014. http://www.theguardian.com/commentisfree/2014/sep/30/iphone-6-encrypted-phone-data-default 16
Ibid.
pág. 44
de los datos de los usuarios17
. Esta controversia con respecto al cifrado de los dispositivos
también se aplica a otros dispositivos de IoT. ¿Qué papel debe desempeñar el cifrado de los
dispositivos en la protección de los dispositivos de IoT contra los ataques criminales? ¿Cómo
se puede equilibrar esto con el legítimo acceso a los datos del usuario en interés de la
aplicación de la ley y la seguridad pública?
1.4.4 Responsabilidad por los dispositivos de IoT
Los dispositivos de IoT plantean interrogantes con respecto a la responsabilidad desde el
punto legal que invitan a la reflexión. Una de las preguntas fundamentales subyacentes en lo
que respecta a los dispositivos de IoT es la siguiente: Si alguien se ve perjudicado como
consecuencia de la acción u omisión de un dispositivo de IoT, ¿quién es el responsable?
Teniendo en cuenta la complejidad que plantean los dispositivos de IoT, una complejidad
muy por encima de la que plantea cualquier dispositivo convencional, es necesario pensar
ciertos escenarios, por ejemplo:
● Puede que los dispositivos de IoT sean utilizados en formas nunca previstas por su
fabricante. No es razonable suponer que un fabricante de dispositivos pueda realizar
pruebas de control de calidad para todos los potenciales casos de uso de los
dispositivos de la IoT.
● Quizás los dispositivos de IoT se conecten e interactúen con otros de formas no
anticipadas y para las cuales no se realizaron pruebas. A medida que aumente la
interoperabilidad, estos dispositivos podrán formar entre sí conexiones de red ad hoc.
Por lo tanto, antes de desplegar estos dispositivos, es difícil para un fabricante o
usuario tener en cuenta todos los escenarios potencialmente perjudiciales que podrían
llegar a surgir.
● Una vez instalados, estos dispositivos pueden tener una larga vida útil y serán
susceptibles a futuras amenazas a la seguridad que hoy en día son desconocidas. Esto
significa que estos dispositivos podrían verse comprometidos y ser reprogramados
maliciosamente para dañarse a sí mismos o a otros dispositivos, o bien para revelar
información sensible en forma no intencionada e inadvertida.
● Los dispositivos de IoT se integrarán en sistemas autónomos (por ejemplo,
automóviles sin conductor) que incorporan algoritmos de aprendizaje adaptativo para
controlar su comportamiento sobre la base de la información aportada por los sensores
de tales dispositivos. Es imposible conocer y probar con anticipación las acciones de
estos sistemas.
Si uno de estos escenarios genera daños, ¿las leyes de responsabilidad existentes abordan
adecuadamente la culpabilidad legal y aclaran la responsabilidad de las partes involucradas?
¿Es necesario repensar las leyes de responsabilidad para los dispositivos inteligentes de IoT
17
Timberg, Craig. “Apple Will No Longer Unlock Most IPhones, IPads for Police, Even with Search Warrants.” Washington
Post. The Washington Post, 18 de septiembre de 2014. http://wapo.st/XGGwDi
pág. 45
que aprenden de su entorno y se modifican a sí mismos a medida que pasa el tiempo? Si un
sistema autónomo recibe instrucciones del usuario y no de sus algoritmos internos, ¿qué pasa
en caso de error del usuario? ¿Los dispositivos de IoT deberían ser lo suficientemente
inteligentes como para tener una instrucción de tipo “haz lo que quise decir”? ¿En qué
medida se pueden ampliar las leyes de responsabilidad que existen para los productos
convencionales de manera que abarquen los productos que se van conectando a Internet?
Como comunidad, ¿qué podemos hacer para informar mejor a los legisladores y a los
formuladores de políticas de modo que no sean tan susceptibles frente a la enorme cantidad
de información errónea y consejos sesgados que reciben? ¿Qué podemos hacer para informar
mejor a los usuarios y compradores de estos dispositivos de modo que entiendan todos los
factores que afectan su uso?
1.4.5 Proliferación de dispositivos de IoT utilizados en acciones legales
Los datos que recogen los dispositivos de IoT muchas veces pueden servir como prueba en
una variedad de procedimientos legales. A medida que estos datos se vuelvan más frecuentes,
es probable que se utilicen cada vez más en este tipo de procedimientos. Por ejemplo, algunos
abogados en Estados Unidos han utilizado durante un juicio de divorcio los datos de hora y
localización obtenidos de los dispositivos de peaje electrónico instalados en los automóviles
para demostrar que un cónyuge engañaba al otro18
. En 2014, una mujer canadiense utilizó los
datos de su propio dispositivo de actividad física en apoyo de su reclamo en una demanda por
lesiones personales19
.
En cuanto a usos más deliberadas de los dispositivos de IoT para procedimientos legales, en
los automóviles se pueden instalar dispositivos conectados a Internet de manera que actúen
como garantía en caso de incumplimiento de las obligaciones de pago. Si un conductor no
paga el crédito de su automóvil, el arrendatario o prestamista puede inactivar el vehículo de
forma remota usando el dispositivo instalado hasta que se realice el pago20
. Estos dispositivos
ya se han instalado en más de dos millones de automóviles en Estados Unidos21
.
Este tipo de escenarios plantean nuevas preguntas legales y reglamentarias con respecto a los
dispositivos de IoT. ¿Deberían los fabricantes de dispositivos incluir en estos dispositivos
tecnologías como el cifrado para restringir el acceso a los flujos de datos como lo ha hecho
Apple en el iPhone? A la inversa, ¿deberían los fabricantes estar diseñando dispositivos de
IoT que faciliten el uso de los datos en un procedimiento judicial? ¿Es necesario desarrollar
estándares que especifiquen requisitos de diseño para que los datos de IoT soporten la cadena
de custodia de los datos en los procesos judiciales? ¿Se deberían establecer regulaciones que
protejan al consumidor de ciertos dispositivos de IoT?
18
Newmarker, Chris. “E-ZPass Records out Cheaters in Divorce Court.” Msnbc.com. NBC News.com, 10 de agosto de 2007.
http://www.nbcnews.com/id/20216302/ns/technology_and_science-tech_and_gadgets/t/e-zpass-records-out-cheaters-divorce-court/#.WpsLPudG3IU 19
Olson, Parmy. “Fitbit Data Now Being Used In The Courtroom.” Forbes. Forbes Magazine, 16 de noviembre 2014.
http://www.forbes.com/sites/parmyolson/2014/11/16/fitbit-data-court-room-personal-injury-claim/ 20
Picchi, Aimee. “Why the Repo Man Can Remotely Shut off Your Car Engine.” CBS News, 25 de septiembre de 2014.
http://www.cbsnews.com/news/why-the-repo-man-can-remotely-shut-off-your-car-engine/ 21
Corkery, Michael, and Jessica Silver-Greenberg. “Miss a Payment? Good Luck Moving That Car.” New York Times, 24 de
septiembre de 2014. http://dealbook.nytimes.com/2014/09/24/miss-a-payment-good-luck-moving-that-car/
pág. 46
1.5 Cuestiones relacionadas con las economías emergentes y el
desarrollo
1.5.1 Oportunidades económicas y de desarrollo
Con respecto a las oportunidades, el McKinsey Global Institute señala que la tecnología de
IoT tiene gran potencial en las economías en desarrollo. Se proyecta que en 2025 hasta un
38% del impacto económico anual de las aplicaciones de IoT provendrá de las regiones
menos desarrolladas22
. Desde una perspectiva económica, se anticipa que las tendencias tanto
demográficas como de mercado impulsarán las oportunidades. Por ejemplo, los países en
desarrollo tienen un elevado número de potenciales usuarios de IoT (especialmente China), el
crecimiento económico mundial se está desplazando hacia las economías en desarrollo y se
espera que las aplicaciones industriales de IoT (por ejemplo, en las fábricas, los lugares de
trabajo y el transporte) impulsarán la creación de valor económico23
.
Si se materializan las expectativas con respecto a la innovación y la aplicación de la
tecnología, las implementaciones de IoT podrían encerrar una gran promesa como
habilitadoras del desarrollo social, incluyendo el logro de los Objetivos de las Naciones
Unidas para el Desarrollo Sostenible24
. Los Objetivos de la ONU para el Desarrollo
Sostenible son un conjunto de treinta y siete objetivos que abarcan más de cien metas y que
apuntan a guiar los esfuerzos para lograr dignidad, bienestar e igualdad para todas las
personas del mundo —especialmente las personas pobres y marginadas—. Abarcan una
amplia gama de desafíos de desarrollo fundamentales, entre ellos la agricultura sostenible, la
energía, la disponibilidad de agua, la industrialización y la gestión de los recursos terrestres y
marítimos.
Al considerar el potencial de que la tecnología de los objetos inteligentes y de Internet de las
Cosas aborde los desafíos del desarrollo de manera significativa, las oportunidades parecen
ser convincentes. Por ejemplo, la aplicación de redes de sensores a diferentes desafíos
ambientales —la calidad y el uso del agua, el saneamiento, la salud y las enfermedades, el
cambio climático y el monitoreo de los recursos naturales— podría tener un fuerte impacto
más allá de la gestión de los recursos. Los datos obtenidos de este tipo de aplicaciones
también se podrían utilizar en contextos de investigación y ayudar a los científicos y a las
universidades locales a realizar contribuciones únicas al cuerpo de conocimiento científico
global e incentivar a los talentos académicos locales de manera que permanezcan en el país y
se dediquen a la investigación.
La creciente población mundial —especialmente en las economías emergentes— y los
desafíos relacionados con el acceso a alimentos de calidad, seguros y asequibles, se anticipa
22
Manyika, James, et. al., The Internet of Things: Mapping the Value beyond the Hype. McKinsey Global Institute, junio de
2015. p. 4. http://www.mckinsey.com/insights/business_technology/the_internet_of_things_the_value_of_digitizing_the_physical_world 23
Manyika, James, et. al., p. 4-5. 24
La lista de Objetivos y metas de Desarrollo Sostenible de las Naciones Unidas se puede consultar en
https://sustainabledevelopment.un.org/topics.
pág. 47
que, aumentarán con el tiempo. El potencial uso de IoT para combatir el hambre y promover
una agricultura sostenible ha recibido especial atención, quizás más que cualquier otro
problema relacionado con el desarrollo25
. Desde la gestión de los ciclos de producción
agrícola, las amenazas de enfermedades y el aumento de las materias primas gracias a la
automatización de las cosechas, la logística aplicada a la distribución y el control de la
calidad, se anticipa que las técnicas de “agricultura inteligente” basadas en IoT se
incorporarán a toda la cadena de valor para mejorar la sostenibilidad y la productividad de la
oferta de alimentos26
.
1.5.2 Aprovechar IoT para el desarrollo global
Internet de las Cosas (IoT) se está desplegando alrededor del mundo para resolver algunos de
los problemas de desarrollo más urgentes a nivel global. Se están usando tecnologías
conectadas para mejorar la prestación de servicios y los resultados del desarrollo en múltiples
áreas, desde el alivio de la pobreza hasta la mejora de la gestión sostenible del agua y el
saneamiento.
Impulsada por los costos cada vez menores de los sensores y microprocesadores y la
creciente variedad de tecnologías de conectividad asequibles, IoT representa la próxima
frontera para las tecnologías de la información y la comunicación (TIC) para el desarrollo
(ICT4D por sus siglas en inglés). Mientras que más del 90% de la población mundial tiene
cobertura de las redes celulares móviles y dos tercios tienen acceso a señales 3G que
permiten una comunicación de datos robusta, también hay otras tecnologías de corto y largo
alcance que ofrecen una amplia gama de opciones de conectividad de datos. A medida que
los dispositivos y servicios continúen volviéndose más asequibles, crecerán las
intervenciones de IoT en el desarrollo (IoT4D). Por ejemplo, hoy en día, se cuentan con
sensores para monitorear la temperatura y la ubicación, las cadenas de frío —especialmente
las que facilitan el transporte y la distribución de las vacunas esenciales— son más seguras y
eficientes, por lo que un porcentaje mayor de los envíos llegan a destino sin echarse a perder.
En África oriental, se están desplegando bombas de agua manuales equipadas con sensores de
flujo con módulos SMS 2G que pueden informar a los municipios locales, a las oficinas
gubernamentales y a las comunidades de donantes sobre la tasa de uso del agua y el tiempo
de inactividad debido a un mal funcionamiento de las bombas.
El sector agrícola también se ha beneficiado de IoT. Ahora es posible alimentar y monitorear
el ganado de forma más específica por medio de etiquetas de nombre/número que contienen
información en un chip de identificación por radiofrecuencia (RFID). Se pueden enterrar
sensores electroquímicos para medir la exposición a la luz solar, así como los niveles de
saturación de agua y la presencia de nutrientes esenciales como el fósforo y el nitrógeno.
Además, las familias de bajos ingresos que viven en regiones remotas o en zonas urbanas sin
25
Los miembros de la Internet Society han formado un Grupo de Interés Especial para investigar específicamente los
problemas que surgen en la intersección de la Internet, IoT y el sector de los alimentos. Para obtener más información sobre el Grupo de Interés Especial de ISOC sobre Alimentos, diríjase a http://internet-of-food.org/ 26
“Digital Farm Set for Internet’s next Wave .” The Guardian, 20 de septiembre de 2015, sec. connecting the future.
http://www.theguardian.com/connecting-the-future/2015/sep/21/digital-farm-set-for-internets-next-wave
pág. 48
acceso a la red eléctrica formal están utilizando tecnologías de IoT junto con células solares
para proveer de energía a sus hogares. Los costos del capital inicial de las unidades solares se
amortizan y se pagan a través de servicios de dinero móvil; las células solares comunican el
nivel y la utilización de las baterías en forma regular a través de comunicaciones de datos.
Estos son apenas algunos ejemplos que ponen de relieve el impacto de IoT como herramienta
para alcanzar los Objetivos de Desarrollo del Milenio de las Naciones Unidas (ODM) y los
Objetivos de Desarrollo Sostenible (ODS) que pronto estarán disponibles. Sin embargo,
todavía existen desafíos, especialmente en lo que respecta a la infraestructura, la capacidad
técnica y la promoción de entornos regulatorios que le den la bienvenida a las intervenciones
de IoT. Una mayor atención al potencial de IoT4D ayudará a aumentar su impacto y su
eficacia en la lucha contra algunos de los desafíos de desarrollo más importantes de nuestro
tiempo.
1.5.3 Interrogantes acerca de IoT y su relación con las economías emergentes y
su desarrollo
Los asuntos discutidos en las secciones anteriores no son exclusivos de los países
industrializados y se deben considerar aplicables a los mercados en desarrollo. Sin embargo,
las circunstancias únicas que suelen encontrarse en las economías emergentes plantean
algunas otras preguntas con respecto a la maximización de los beneficios y la gestión de los
desafíos de IoT. Aunque este listado no es en absoluto exhaustivo, algunas áreas a considerar
incluyen las siguientes:
● Recursos de Infraestructura. La infraestructura de Internet y las comunicaciones se
han propagado rápidamente por todo el mundo en desarrollo, aunque en muchos
países todavía existen lugares donde no es posible asegurar un acceso confiable, de
alta velocidad y asequible, incluso para uso comercial y de negocios. ¿En qué medida
Internet de las Cosas ejercerá presión sobre la infraestructura y los recursos de
Internet y las telecomunicaciones? ¿Los desafíos actuales frenarán las oportunidades
de IoT en las regiones emergentes? ¿O será IoT un generador de demanda que
impulsará la construcción de más infraestructura? ¿Es necesario prestar especial
atención a la gestión del espectro, teniendo en cuenta que muchas implementaciones
de IoT se sustentan en la tecnología inalámbrica? A medida que los servicios en la
nube y los análisis de datos relacionados incorporen valor en muchos servicios de IoT,
¿la relativa escasez de infraestructura de centros de datos en las economías
emergentes representará un obstáculo para el despliegue?
● Inversión. En los países industrializados, la inversión en investigación y desarrollo de
productos para IoT está siendo impulsado por las oportunidades de mercado para
diferentes productos y servicios. ¿Hasta qué punto el mercado impulsará la inversión
en implementaciones de IoT en los países en desarrollo, sobre todo más allá de las
aplicaciones en industrias y entornos con una clara perspectiva de retorno a corto
plazo? Por el contrario, ¿los despliegues de IoT en las economías emergentes serán
más eficientes y rentables? Dada la menor cantidad de sistemas heredados que suelen
pág. 49
existir en estas economías, ¿podrán saltearse la generación tecnológica que está en
uso en el resto del mundo? ¿Los gobiernos deberían incentivar el desarrollo de
soluciones técnicas innovadoras por parte de los investigadores y las industrias
locales?
● Desarrollo técnico y de la industria. ¿En qué medida están participando
investigadores y emprendedores de los países emergentes en el desarrollo técnico y el
despliegue de IoT? ¿Qué se debe hacer para fomentar su participación en el desarrollo
de soluciones técnicas y aplicaciones que satisfagan las necesidades y oportunidades
de estos mercados, que a la vez sean respetuosas de las normas culturales y que
construyan niveles adecuados de seguridad y protección de la privacidad? ¿Qué
nuevas habilidades pueden ser necesarias en las economías emergentes para construir,
desplegar y gestionar sistemas de IoT? ¿Las industrias en las economías emergentes
están listas para aprovechar la tecnología de IoT? ¿Quedarán rezagadas o estarán en
mejores condiciones de saltearse las tecnologías industriales más antiguas? ¿Cómo
pueden los investigadores y las industrias de los países con economías emergentes
posicionarse para desarrollar soluciones a los desafíos económicos y sociales locales
que tienen un impacto directo en sus sociedades?
● Coordinación regulatoria y de políticas. En los últimos diez años, los formuladores
de políticas y reguladores de las economías emergentes han logrado avances
significativos en cuanto al desarrollo y la adaptación de las políticas y regulaciones
existentes para fomentar el crecimiento de Internet y hacer frente a los desafíos
relacionados. En las economías emergentes, los formuladores de políticas
tecnológicas deben enfrentar importantes exigencias, especialmente en vista de la
velocidad de los desarrollos y las limitaciones de los recursos. Aunque IoT promete
nuevas oportunidades, también agregará una nueva dimensión de complejidad. ¿Qué
información y recursos necesitan ahora los formuladores de políticas de las economías
emergentes para tener en cuenta las exigencias de políticas y otras preguntas que
surgirán con el crecimiento de IoT?
pág. 50
CAPÍTULO 4:
MODELOS DE COMUNICACIÓN
1 Introducción
Uno de los grandes desafíos de IoT es la interoperabilidad. En una encuesta reciente de
Nexus, el setenta y siete por ciento (77%) de los entrevistados consideró que la
interoperabilidad es el mayor desafío de IoT.
Para lograr interoperabilidad entre sistemas o aplicaciones se debe establecer el modelo de
comunicación que dará lugar a la estructura de la solución para lograr este objetivo. El
modelo de comunicación elegido no sólo es importante porque define la estructura del
sistema general resultante sino también porque delimita los protocolos de comunicación
posibles de aplicar.
2 Los modelos Cliente/Servidor y Publicador/Suscriptor
2.1 Modelo Cliente/Servidor
Es un modelo de aplicación distribuida en el que las tareas se reparten entre los programas
proveedores de recursos o servicios, llamados servidores, y los programas demandantes,
llamados clientes. Un cliente realiza peticiones (requests, solicitudes) a un servidor, el cual
procesa dicha petición y retorna los resultados al cliente apropiado. Esta idea también se
puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más
ventajosa en un sistema operativo multiusuario distribuido a través de una red de
computadoras.
La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no
se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa.
Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los
servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la
arquitectura básica seguirá siendo la misma.
La red cliente/servidor es una red de comunicaciones en la cual los clientes están conectados
a un servidor, en el que se centralizan los diversos recursos y servicios con que se cuenta; y
que los pone a disposición de los clientes cada vez que estos son solicitados. Esto significa
que todas las gestiones que se realizan se concentran en el servidor, de manera que en él se
disponen los requerimientos provenientes de los clientes que tienen prioridad, los archivos
que son de uso público y los que son de uso restringido, los archivos que son de sólo lectura y
los que, por el contrario, pueden ser modificados, etc. Este tipo de red puede utilizarse
conjuntamente en caso de que se esté utilizando en una red mixta.
pág. 51
Este modelo es utilizado por servicios como el intercambio de emails, el acceso a páginas
web, el acceso a bases de datos, y muchos otros protocolos de internet se basan en este
concepto (HTTP, SMTP, Telnet, DNS), etc. La mayoría de los servicios de Internet son tipo
de cliente-servidor. La acción de visitar un sitio web requiere una arquitectura cliente-
servidor, ya que el servidor web sirve las páginas web al navegador (al cliente). Otro ejemplo
podría ser el funcionamiento de un juego online: si existen dos servidores de juego, cuando
un usuario lo descarga y lo instala en su computadora pasa a ser un cliente. Si tres personas
juegan en un solo computador existirían dos servidores, un cliente y tres usuarios. Si cada
usuario instala el juego en su propia computadora existirían dos servidores, tres clientes y tres
usuarios.
2.1.1 Características
En la arquitectura cliente/servidor el remitente de una solicitud es conocido como cliente. Sus
características son:
● Es quien inicia las solicitudes o peticiones, tienen por tanto un papel activo en la
comunicación (dispositivo maestro o amo).
● Espera y recibe las respuestas del servidor.
● Por lo general, puede conectarse a varios servidores a la vez.
● Normalmente interactúa directamente con los usuarios finales mediante una interfaz
gráfica de usuario.
Al receptor de la solicitud enviada por el cliente se conoce como servidor. Sus características
son:
● Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces
un papel pasivo en la comunicación (dispositivo esclavo).
● Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente.
● Por lo general, acepta las conexiones de un gran número de clientes (en ciertos casos
el número máximo de peticiones puede estar limitado).
Las características generales de la arquitectura cliente/servidor son:
● Protocolos asimétricos: hay una relación muchos a uno entre los clientes y un
servidor. Los Clientes siempre inician un diálogo mediante la solicitud de un
servicio/recurso. Los Servidores esperan pasivamente por las solicitudes de los
clientes.
● Encapsulamiento de servicios: el servidor es un especialista, cuando se le entrega un
mensaje solicitando un servicio, él determina cómo hacer el trabajo. Los servidores se
pueden actualizar sin afectar a los clientes en tanto que la interfaz pública de mensajes
que se utilice, por ambos lados, permanezca sin cambiar.
pág. 52
● Integridad: el código y los datos de un servidor se mantienen centralizados, lo que
origina que el mantenimiento sea más barato y sostiene la protección de la integridad
de datos compartidos. Al mismo tiempo, los clientes conservan su independencia y
“personalidad”.
● Transparencia de localización: el servidor es un proceso que puede residir en la
misma máquina que el cliente u otra máquina diferente de la red. El software
cliente/servidor (middleware) habitualmente oculta la localización de un servidor a los
clientes mediante la redirección de servicios. Un programa puede actuar como cliente,
como servidor o como cliente y servidor simultáneamente.
● Intercambios basados en mensajes: los clientes y servidores son procesos
débilmente acoplados que pueden intercambiar solicitudes de servicios y respuestas
utilizando mensajes.
● Modularidad, diseño extensible: el diseño modular de una aplicación
cliente/servidor permite que la aplicación sea tolerante a fallos:
○ En sistemas tolerantes a fallos, los fallos pueden ocurrir sin causar la caída de
la aplicación completa.
○ En una aplicación cliente/servidor tolerante a fallos, uno o más servidores
pueden fallar sin parar el sistema total mientras que los servicios
proporcionados por los servidores caídos estén disponibles en otros servidores
activos.
○ Otra ventaja de la modularidad es que una aplicación cliente/servidor puede
responder automáticamente al incremento o decremento de la carga del
sistema mediante la incorporación o eliminación de uno o más servicios o
servidores.
● Independencia de la plataforma: el software cliente/servidor “ideal” es
independiente del hardware o sistemas operativos, permitiendo al programador
mezclar plataformas de clientes y servidores. El entorno de explotación de clientes y
servidores puede ser sobre diferentes plataformas, con el fin de optimizar el tipo de
trabajo que cada uno desempeña.
● Código reutilizable: la implementación de un servicio puede utilizarse en varios
servidores.
● Escalabilidad: los sistemas cliente/servidor pueden ser escalados horizontal o
verticalmente:
○ El escalado horizontal significa añadir o eliminar estaciones clientes con un
ligero impacto en el rendimiento.
pág. 53
○ El escalado vertical significa la migración a una máquina servidora más
grande y rápida o la incorporación de nuevas máquinas servidoras.
● Separación de la funcionalidad del cliente/servidor: el modelo cliente/servidor es
una relación entre procesos que se ejecutan en la misma máquina o en máquinas
separadas. Un proceso servidor es un proveedor de servicios. Un cliente es un
consumidor de servicios. El modelo cliente servidor proporciona una clara separación
de funciones.
● Recursos compartidos: un servidor puede proporcionar servicios a muchos clientes
al mismo tiempo, y regular el acceso de éstos a un conjunto de recursos compartidos.
Los servidores pueden ser sin estado (stateless) o con estado (stateful). Un servidor stateless
no guarda ninguna información entre las peticiones. Un servidor stateful puede recordar la
información entre las peticiones. El alcance de esta información puede ser global o sesión-
específico. Un servidor del protocolo HTTP para las páginas estáticas HTML es un ejemplo
de un servidor sin estado, mientras que Apache Tomcat es un ejemplo de un servidor stateful.
La interacción entre el cliente y el servidor se describe a menudo usando diagramas de
secuencia. Los diagramas de secuencia se estandarizan en UML. Es importante que los
clientes no interactúen entre sí ni que lo hagan clientes de capas bajas hacia otros de capas
más altas, por eso todo tiene que pasar por el servidor.
2.1.2 Ventajas
El modelo cliente/servidor se recomienda, en particular, para redes que requieran un alto
grado de fiabilidad. Las principales ventajas son:
● Recursos centralizados: debido a que el servidor es el centro de la red, puede
administrar los recursos que son comunes a todos los usuarios, por ejemplo una base
de datos centralizada se utilizaría para evitar problemas provocados por datos
contradictorios y redundantes.
● Seguridad mejorada: debido a que la cantidad de puntos de entrada que permite el
acceso a los datos no es importante.
● Administración al nivel del servidor: dado que los clientes no juegan un papel
importante en este modelo, requieren menos administración.
● Red escalable: gracias a esta arquitectura, es posible quitar o agregar clientes sin
afectar el funcionamiento de la red y sin la necesidad de realizar mayores
modificaciones.
pág. 54
2.1.3 Desventajas
La arquitectura cliente/servidor también tiene las siguientes desventajas:
● Costo elevado: debido a la complejidad técnica del servidor.
● Un eslabón débil: el servidor es el único eslabón débil en la red de cliente/servidor,
debido a que toda la red está construida en torno a él. Afortunadamente, el servidor es
altamente tolerante a los fallos (principalmente gracias al sistema RAID).
2.2 Modelo Publicador/Suscriptor
El sistema publicador/suscriptor es un paradigma de mensajes asíncronos donde los que
envían mensajes (publicadores) no están programados para enviar sus mensajes a receptores
específicos (suscriptores), sino que se envían a algún tipo de servidor. Los mensajes
publicados se caracterizan por clases, sin tener constancia de los suscriptores que pueda
haber. Los suscriptores expresan interés en una o más clases, y solo reciben mensajes de ese
mismo interés, sin tener constancia de qué publicadores hay. Esta relación independiente
entre publicadores y subscriptores puede permitir una mayor escalabilidad.
El sistema publicador/suscriptor está muy ligado al paradigma de las colas de mensajes
(Message Queue). Muchos de los sistemas de mensajería soportan en su API los dos modelos,
publicador/suscriptor y el modelo de mensajes en cola.
2.2.1 Filtrado de mensajes
En el modelo publicador/suscriptor, los suscriptores normalmente tan solo reciben un
subconjunto del total de mensajes publicados. El proceso de selección de mensajes para su
recepción y su procesamiento es llamado ‘Filtrado de mensajes’ (filtering). Existen dos
maneras de filtrar mensajes: por tópicos o por el contenido de estos. Cuando hablamos de
filtrado por tópicos, decimos que los mensajes son publicados por “temas” o canales. Los
suscriptores en un sistema de filtrado por tópicos recibirán todos los mensajes publicados, de
aquellos tópicos o temas en los cuales se hayan subscrito. Son los publicadores, los
responsables de definir los diferentes tipos de temas o tópicos a los cuales se suscribirán los
suscriptores.
pág. 55
Esquema de sistema publicador/subscriptor
Por otro lado, cuando hablamos de filtrado por el contenido de los mensajes, decimos que los
mensajes son enviados a los subscriptores solo si el contenido de estos coincide con las
preferencias que los suscriptores se hayan definido. El suscriptor es responsable de clasificar
los mensajes.
Algunos sistemas soportan una mezcla de los dos; los publicadores envían mensajes a
algunos tópicos o temas mientras que los suscriptores reciben solo algunos mensajes de cada
tópico según su contenido.
2.2.2 Topologías
En muchos sistemas publicador/suscriptor, los publicadores envían los mensajes a un servidor
intermediario (broker) y los suscriptores hacen sus suscripciones con este servidor
intermediario (broker), permitiendo a este servidor encargarse del filtrado de los mensajes.
Dicho servidor normalmente se encarga del almacenamiento de los mensajes y a su vez de la
gestión de dichos mensajes hacia los suscriptores.
Otros sistemas publicador/suscriptor eliminan este servidor intermediario (broker) y
distribuyen las funciones de gestión y filtrado entre los publicadores y suscriptores, algunas
veces con ayuda de “daemons”.
Otra opción más especializada involucra mapear todas las IP de los suscriptores y
organizarlas en grupos según sus tópicos o temas, de esta forma los mensajes podrían
enviarse directamente desde los publicadores a los suscriptores con un único mensaje. El
filtrado por contenido puede entonces llevarse a cabo en el suscriptor antes de que los
mensajes pasen a la capa superior de la aplicación en sí.
pág. 56
2.2.3 Ventajas
Tanto los publicadores como los suscriptores no necesitan saber uno del otro. Siendo el
tópico o tema el objetivo, publicadores y suscriptores pueden permanecer al margen de la
topología del sistema. Cada uno puede operar con normalidad independientemente del otro.
Cosa que no pasaba con el paradigma tradicional cliente/servidor, donde el cliente no puede
mandar mensajes al servidor mientras el servidor no está en marcha, y éste último no puede
recibir mensajes a no ser que el cliente también esté en marcha.
Para instalaciones relativamente pequeñas, el sistema publicador/suscriptor da la oportunidad
de una mejor escalabilidad que los tradicionales sistemas cliente/servidor, mediante
operaciones en paralelo, caché de mensajes, etc. No obstante, a medida que un sistema
aumenta hasta el punto de convertirse en un centro de datos con miles de servidores
compartiendo la infraestructura publicador/suscriptor, este beneficio normalmente, se pierde;
de hecho, la escalabilidad para sistemas publicador/suscriptor bajo una gran carga es todavía
un desafío.
2.2.4 Desventajas
El problema más importante con los sistemas publicador/suscriptor es, en contrapuesta, su
principal ventaja: la independencia entre el publicador y el suscriptor. El problema está en
que es muy complicado especificar propiedades más fuertes que podrían ser útiles.
Como primer ejemplo, muchos sistemas publicador/suscriptor intentan enviar mensajes
durante un período corto de tiempo y después se detienen. Si una aplicación, por el motivo
que fuese, necesitase una garantía más fuerte (como podría ser: los mensajes serán siempre
enviados y en caso contrario se tendrá que informar al publicador del hecho), el sistema
publicador/subscriptor probablemente no tendría manera de satisfacer esta garantía.
Otro ejemplo sería cuando un publicador “asume” que un suscriptor está escuchando.
Supongamos que utilizamos un sistema publicador/subscriptor para capturar mensajes de
error en una fábrica: cualquier aplicación que produzca un error publicará un apropiado
mensaje, y los mensajes serán puestos en la pantalla de la consola por el servicio (‘daemon’),
el cual está suscrito al tópico “errores”. Si el encargado de capturar las excepciones se
detiene, los publicadores no serán capaces de darse cuenta, con lo cual todos los mensajes de
error desaparecerán y no se verán por la consola.
Los sistemas publicador/subscriptor se comportan bien con instalaciones pequeñas, en cuanto
escalabilidad se refiere, pero cuando nos encontramos con instalaciones más grandes su
comportamiento empieza a decaer. Y esto se manifiesta con inestabilidades como, largos
periodos de espera, retardos en cuanto más y más aplicaciones empiezan a usar el sistema
(incluso si se están comunicando en tópicos distintos), al punto de saturar una red local con el
tráfico de mensajes.
En cuanto a los sistemas que utilizan servidores (brokers), estos pueden ser objeto de
problemas de seguridad. Pueden ser hackeados para enviar notificaciones a un cliente
pág. 57
erróneo, creando una denegación de servicio hacia dicho cliente. Los servidores pueden
sobrecargarse a medida que van almacenando y gestionando grandes cantidades de mensajes.
Incluso con sistemas que no dependen de servidores intermedios, un suscriptor podría ser
capaz de recibir información que no le está autorizada. Un publicador no autorizado podría
ser capaz de introducir mensajes incorrectos o dañinos en el sistema publicador/suscriptor.
Esto ocurre especialmente en sistemas que envían todos sus mensajes a todos sus
suscriptores. La encriptación (ej. SSL/TLS) puede ser la única vía de defensa contra accesos
no autorizados.
2.3 Cliente/Servidor vs. Publicador/Subscriptor
Un protocolo cliente/servidor requiere que el cliente se conecte al servidor y realice
solicitudes. En este modelo, el servidor tiene los datos y responde a los pedidos del cliente,
por ejemplo, el cliente quizá lee una temperatura, esto requiere que sepa acerca del servidor
de antemano y sea capaz de conectarse.
Los protocolos publicador/suscriptor requieren que los dispositivos se conecten a un “tópico”
de un gestor intermediario y publiquen la información. Los consumidores se pueden conectar
al gestor y suscribirse a los datos del tópico. Por ejemplo, un dispositivo puede medir la
temperatura cada minuto y publicarlo una vez por hora. Una aplicación suscripta a dicha
información recibirá una vez por hora un compendio horario de las muestras tomadas cada
minuto. Este modelo desacopla al productor de datos del consumidor de datos.
Los sistemas cliente/servidor se utilizan mejor cuando uno conoce su propia infraestructura.
Por ejemplo, uno sabe que su servidor en campo tiene una dirección IP (Internet Protocol,
protocolo de Internet’) de 55.55.55.55, en un puerto 1234. El cliente se puede conectar y
realizar requerimientos.
Los sistemas publicador/suscriptor son mejores cuando la infraestructura propia es
desconocida. Por ejemplo, si un dispositivo remoto cambia de redes o tiene una conectividad
intermitente, es más fácil para el dispositivo comunicarse cuando se pone en línea y publicar
su información.
En términos de pros y contras, los protocolos cliente/servidor son más compatibles y seguros
porque están basados en conexiones punto a punto. Sin embargo, son menos escalables
porque las conexiones punto a punto son más difíciles de manejar y demandan mayor
cantidad de recursos. Por el contrario, los protocolos publicador/suscriptor son más escalables
porque el separar a productores de consumidores permite que cada uno se agregue y se quite
de forma independiente; sin embargo, como se especificó en el apartado anterior, este
beneficio se pierde cuando la cantidad de dispositivos participantes aumenta en demasía.
Además, asegurar este tipo de protocolos es más complejo porque involucra más piezas.
También pueden aparecer cuestiones de compatibilidad dada la separación entre productor y
consumidor. Por ejemplo, cambiar el formato del mensaje que envía el productor requiere
que todos los consumidores se adapten al nuevo formato.
pág. 58
CAPÍTULO 5:
PROTOCOLOS DE COMUNICACIÓN
1 Introducción
Conectar dispositivos industriales con tecnologías de información y plataformas IoT es un
tema considerable. Existen varios protocolos para cumplimentar esto, algunos que son
privados y otros que son estándares abiertos, todos están compitiendo para convertirse en el
protocolo único de IoT pero es claro que eso no será una realidad. Estos protocolos
coexistirán (cada uno con sus propias fortalezas y debilidades) y dependerá de nosotros
comprender dónde y cuándo usarlos.
Los protocolos que se estudian a continuación tienen el potencial de conectar dispositivos
industriales con plataformas IoT. Un caso común que puede ocurrir es que dos aplicaciones
soporten, por ejemplo, HTTP como protocolo de comunicación; en este caso, lo más
razonable sería intentar utilizar HTTP antes que cualquier otro para realizar la comunicación,
y si eso no funciona o si el medio no lo tolera, se podrá optar por otro protocolo que cubra las
necesidades requeridas.
2 Protocolos
2.1 OPC
El OPC (Object Linking and Embedding for Process Control) no es un protocolo, sino más
bien es un estándar de comunicación en el campo del control y supervisión de procesos
industriales, basado en tecnología Microsoft, que ofrece una interfaz común para
comunicación que permite que componentes software individuales interactúen y compartan
datos. La comunicación OPC se realiza a través de una arquitectura cliente-servidor. El
servidor OPC es la fuente de datos y cualquier aplicación basada en OPC puede acceder a
dicho servidor para leer/escribir cualquier variable que ofrezca el servidor. Es una solución
abierta y flexible al clásico problema de los drivers propietarios. Prácticamente todos los
mayores fabricantes de sistemas de control, instrumentación y de procesos han incluido OPC
en sus productos.
Las aplicaciones necesitan una manera común de acceder a los datos de cualquier fuente,
como un dispositivo o una base de datos.
pág. 59
Las ventajas que proporciona este estándar es que los fabricantes de hardware sólo tienen que
hacer un conjunto de componentes de programa para que los clientes los utilicen en sus
aplicaciones. Además los fabricantes de software no tienen que adaptar los drivers ante
cambios de hardware.
Un cliente OPC se puede conectar a servidores OPC proporcionados por más de un
"proveedor". Esto resulta útil para trabajar con más de dos OPC sin necesidad de seguir el
mismo protocolo.
Es un estándar utilizado para responder a uno de los mayores retos de la industria de la
automatización: cómo comunicar dispositivos, controladores y/o aplicaciones sin caer en los
problemas habituales de las conexiones basadas en protocolos propietarios.
El éxito de OPC en crear comunicaciones auténticamente independientes del fabricante, se
debe a que abstrae, de los detalles de la implementación, a la Fuentes de Datos (esto es, PLC)
y a los Clientes de Datos (es decir, HMI/ SCADA), con lo que los datos se pueden
intercambiar entre ellos sin que tengan que saber nada de sus respectivos protocolos de
Cliente OPC
Servidor OPC
Proveed
Servidor OPC
Proveed
Servidor OPC
Proveed
pág. 60
comunicación nativos y de la organización interna de sus datos. Esto, en clara oposición a la
aproximación basada en crear aplicaciones que funcionan con protocolos propietarios que,
por definición, son requeridos para comunicar, de forma nativa, la Fuente de Datos con el
Cliente de Datos.
La arquitectura Cliente/Servidor OPC – Una mejor vista del funcionamiento OPC nos revela dos componentes:
el Cliente OPC y el Servidor OPC. La especificación OPC define el mensaje entre estos dos componentes.
La “abstracción de dispositivos” de OPC se consigue utilizando dos componentes
especializados llamados Cliente OPC y Servidor OPC. Es importante resaltar que el hecho de
que la fuente de datos y el cliente de datos se puedan comunicar entre sí mediante OPC no
significa que sus respectivos protocolos nativos dejen de ser necesarios o hayan sido
reemplazados por OPC. Al contrario, estos protocolos y/o interfaces nativos siguen
existiendo, pero sólo comunican con uno de los dos componentes del software OPC. Y son
los componentes OPC los que intercambian información entre sí, cerrando así el círculo. La
información puede viajar de la aplicación al dispositivo sin que éstos tengan que hablar
directamente entre sí.
pág. 61
Los Servidores OPC se muestran como un nivel intermedio entre la fuente de datos y el cliente de datos,
habilitando la intercomunicación sin que ningún lado conozca el protocolo nativo del otro.
El servidor OPC es una aplicación de software; un driver “estandarizado” desarrollado
específicamente para cumplir con una o más especificaciones OPC. La palabra “servidor” en
“Servidor OPC” no hace referencia en absoluto a la computadora donde este software se
estará ejecutando, sino que hace referencia a la relación con el cliente OPC.
Los servidores OPC son conectores que se pueden asimilar a traductores entre el mundo OPC
y los protocolos nativos de una fuente de datos. OPC es bidireccional, esto es, los servidores
OPC pueden leer de y escribir en una fuente de datos. La relación servidor OPC/cliente OPC
es de tipo maestro/esclavo, lo que significa que un Servidor OPC sólo transferirá datos de/a
una fuente de datos si un cliente OPC así se lo pide.
Los servidores OPC pueden comunicar prácticamente con cualquier fuente de datos cuyos
datos puedan ser leídos o escritos por medios electrónicos. Una breve lista de posibles fuentes
de datos incluye: dispositivos, PLCs, DCSs, RTUs, instrumentos de medición, bases de datos,
historiadores, software de cualquier tipo (por ejemplo, Excel), páginas web e incluso archivos
CSV (texto separado por comas) de actualización automática. Para comunicar con cualquiera
de estos dispositivos se requiere únicamente el uso de un servidor OPC que utilice el
protocolo o interfaz nativo apropiado. Una vez que se ha configurado dicho servidor,
cualquier aplicación cliente que utilice OPC (y tenga los permisos adecuados) puede empezar
a comunicar con la fuente de datos sin que importe la forma en que esta comunica de forma
nativa.
pág. 62
Aunque los usuarios no necesitan saber nada acerca de los servidores OPC para poder
utilizarlos, se debe tener en cuenta que la calidad y el rendimiento de los servidores OPC
puede variar enormemente en distintos suministradores.
Conceptualmente un servidor OPC funciona:
● Módulo de comunicaciones OPC. Esta es la parte del servidor OPC responsable de
comunicar adecuadamente con un cliente OPC. Los servidores OPC bien diseñados
deben ser plenamente compatibles con las especificaciones OPC que implementen,
para asegurar que comunican correctamente con cualquier cliente OPC.
● Módulo de comunicaciones nativas. El servidor OPC debe emplear el método de
comunicación más eficiente con la fuente de datos. En algunos casos, esto implica
comunicar con la fuente mediante su protocolo propietario de datos, mientras que en
otros casos, esto significa comunicar a través de una interfaz de programación de la
aplicación (API). Cuanto más experiencia se tenga con el dispositivo, mejor se
utilizará las posibilidades de comunicación que ofrece.
● Módulo de traducción/mapeado. La función de este módulo es interpretar de forma
adecuada las peticiones OPC entrantes de un cliente OPC, convirtiéndolas en
peticiones nativas que se envían a la fuente de datos y viceversa. Si esto se hace
eficientemente, se puede mantener al mínimo la carga sobre la fuente de datos
mientras se maximiza la capacidad de transmisión de datos.
Por otro lado tenemos el cliente OPC, el cual es una pieza de software creada para comunicar
con servidores OPC. Utiliza mensajería definida por una especificación concreta de la OPC
Foundation.
pág. 63
Conceptualmente un cliente OPC representa un destino de datos. Inician y controlan la
comunicación con los servidores OPC basados en las peticiones recibidas desde la aplicación
en la que están embebidos. Los clientes traducen las peticiones de comunicación provenientes
de una aplicación dada en la petición OPC equivalente y la envían al servidor OPC adecuado
para que la procese. A cambio, cuando los datos OPC vuelven del servidor, el cliente los
traduce al formato nativo de la aplicación para que ésta pueda trabajar de forma adecuada con
los datos.
Desde una perspectiva técnica los clientes OPC no son más que módulos de software
utilizados por una aplicación para poder comunicarse con cualquier servidor OPC compatible
visible en la red. Típicamente, los clientes están embebidos en aplicaciones como HMIs,
SCADAs, graficadores, historiadores o generadores de informes, convirtiéndolos en
aplicaciones compatibles OPC. Es muy común referirse a la aplicación que contiene un
cliente OPC embebido como “Cliente OPC”.
Al igual que con los servidores OPC, un cliente OPC se puede dividir conceptualmente en
tres módulos:
● Módulo de comunicaciones OPC. Aunque no tan involucrado como en el servidor
OPC (en los servidores OPC esta parte es más compleja) es crucial para que el cliente
se comporte como debe al conectarse a un servidor, intercambiar datos con él y
desconectarse sin desestabilizarlo.
● Módulo de comunicaciones con la aplicación. El cliente OPC típicamente está
diseñado para trabajar en una aplicación específica, por lo que, para permitir que la
información pase de la aplicación al servidor OPC pasando por el cliente, realiza una
serie de llamadas al interfaz para la programación de la aplicación (API). También es
posible que un cliente genérico comunique con una aplicación mediante un protocolo
en lugar de con llamadas al API siempre que la aplicación soporte este protocolo.
pág. 64
● Módulo de traducción/mapeado. Una de las funciones clave del cliente OPC es la
de traducir de forma bidireccional la información que su aplicación necesita leer de o
escribir al dispositivo o fuente de datos.
Un aspecto que cabe destacar es que en OPC las comunicaciones Cliente-Cliente no están
definidas. Sólo se soporta la arquitectura cliente/servidor. Por ello, si una aplicación debe
proveer datos OPC a otros clientes, necesita tener su propio servidor OPC. Este servidor
permitirá a otros clientes de otras aplicaciones utilizar esta aplicación como fuente de datos.
2.1.1 OPC UA
OPC UA (Unified Architecture, Arquitectura Unificada) es el estándar de nueva generación
que le sigue a OPC Foundation. El estándar OPC clásico es bien conocido en la industria y
provee una interfaz estándar para comunicarse con los PLC (Programmable Logic Controller,
Controlador Lógico Programable). El estándar OPC UA pretende expandir la compatibilidad
de OPC a nivel de los dispositivos y empresas. Este es un protocolo cliente/servidor, en el
que los clientes se conectan, navegan, leen y escriben al equipamiento industrial. UA define
la comunicación desde la aplicación hacia la capa de transporte, lo que lo hace compatible
entre vendedores. También es muy seguro, y usa mensajes bidireccionales firmados y
encriptación de transporte.
OPC UA tiene una amplia base instalada en el mundo industrial. Es una buena solución para
conectar información de sensores y PLC en aplicaciones industriales ya existentes como
sistemas MES (Manufacturing Execution System, Sistema de Ejecución de Manufactura) y
SCADA (Supervisory Control and Data Acquisition, Supervisión, Control y Adquisición de
Datos), en donde la conectividad OPC y OPC UA ya están disponibles.
Sin embargo, OPC UA es nuevo para las tecnologías de información. Algunas personas de
TIC (Tecnologías de la Información y Comunicación) se asustan ante la complejidad de UA
en comparación con otros protocolos TIC. Mucha de esta complejidad reside en el hecho de
que OPC UA sea un protocolo industrial, pero esta percepción ha llevado a ralentizar su
adopción para plataformas IoT y la comunidad de código abierto. Sin embargo, la situación
está cambiando, hace muy poco OPC Foundation abrió el código del estándar OPC UA para
hacerlo más accesible y colaborar a que se incremente su adopción.
Por ahora, el uso de OPC UA es cuando se necesite información del sensor y de PLC dentro
de las soluciones MES y SCADA ya existentes.
2.2 HTTP (REST/JSON)
HTTP (Hypertext Transfer Protocol, Protocolo de Transferencia de Hipertexto) es un
protocolo cliente/servidor sin conexión, ubicuo en TIC y en la web. Dado que existen
incontables herramientas de código abierto que usan HTTP, y que todo lenguaje de
codificación tiene bibliotecas HTTP, es muy accesible. Este es uno de los protocolos basados
en IP, utilizados en IoT.
pág. 65
El foco de HTTP en IoT gira en torno a REST (Representational State Transfer,
Transferencia de Estado Representacional) que es un modelo sin estados previos donde los
clientes pueden acceder a recursos en el servidor a través de pedidos. En la mayoría de los
casos, un recurso es un dispositivo y la información que tal dispositivo contiene.
Este protocolo provee transporte pero no define la presentación de la información. Así, un
requerimiento HTTP puede contener HTML, JavaScript, JSON (JavaScript Object Notation,
Notación de Objeto JavaScript), XML, etc. En la mayoría de los casos, IoT está
estandarizando JSON para HTTP, que es una representación similar a XML pero sin la
sobrecarga ni esquema de validación por lo que es más liviano y flexible. También es
soportado por la mayoría de las herramientas y lenguajes de programación.
La industria cuenta con algo de experiencia usando HTTP para la configuración de productos
y dispositivos, pero no para el acceso a datos. De este modo, muchas plataformas TIC e IoT
aceptan HTTP para proveer y recibir información, pero no así las plataformas industriales.
Esto está cambiando a medida que cada vez más puertos y PLC agregan HTTP nativo.
En las plataformas industriales el método más seguro de implementar HTTP en un
dispositivo de IoT es incluir solo un cliente, no un servidor. En otras palabras, es más seguro
si el dispositivo de IoT puede iniciar conexiones a un servidor Web, pero no de recibir
solicitudes de conexión. Después de todo, lo que se quiere evitar es que máquinas externas
tengan acceso a la red local donde se encuentran instalados los dispositivos de IoT.
El uso de HTTP es útil para enviar grandes cantidades de información, como lecturas de
temperatura minuto a minuto cada hora. Aunque no es recomendable utilizarlo para enviar
información de video de alta velocidad. Este protocolo puede operar en un rango temporal
por debajo del segundo pero actualizaciones de cien milisegundos (100 ms) con HTTP son
difíciles de realizar. Debido a la arquitectura en capas que posee este protocolo, implica
bastante sobrecarga por mensaje, así que enviar mensajes pequeños es ineficiente. Y siempre
es aconsejable asegurarse la comunicación con HTTPS, la sobrecarga de agregar seguridad
al protocolo HTTP básico es mínima.
En cuestiones de interoperabilidad, se debe estar seguro al utilizar productos que se basen en
HTTP. Solo porque dos productos soporten HTTP, REST y JSON no significa que estén
listos para usarlos. Muy a menudo, los formatos JSON son diferentes entre distintos
productos y requieren de una mínima integración para que las cosas funcionen.
pág. 66
2.3 MQTT
MQTT (Message Queuing Telemetry Transport, Transporte de Telemetría de Cola de
Mensajes) es un protocolo publicador/suscriptor de código abierto desarrollado y optimizado
para SCADA, redes remotas, dispositivos restringidos y redes de bajo ancho de banda, alta
latencia o poco confiables. Es extremadamente ligero e ideal para conectar dispositivos
pequeños a redes con ancho de banda mínimo. Es un protocolo simple para la transmisión de
mensajes cortos de telemetría y de control desde/hacía una red de sensores/actuadores que
tenga limitaciones evidentes en cuanto al consumo, velocidad de transmisión y
procesamiento.
El protocolo MQTT se localiza en las capas superiores del modelo OSI, y normalmente se
apoya en TCP/IP. Esto significa que los participantes de una aplicación MQTT deben tener
una pila TCP/IP.
Protocolo MQTT dentro del modelo OSI
pág. 67
El protocolo MQTT es eficiente en términos de ancho de banda, independiente de los datos y
tiene reconocimiento de sesión continua, debido a que hace uso del protocolo TCP/IP. Se
centra en un mínimo encabezado (dos bytes de tamaño) y comunicaciones confiables.
También es muy simple, tal como HTTP, la carga MQTT es específica para la aplicación y la
mayoría de las implementaciones usan un formato JSON personalizado o binario. Tiene la
finalidad de minimizar los requerimientos de recursos del dispositivo y, a la vez, tratar de
asegurar la confiabilidad y cierto grado de seguridad de entrega con calidad del servicio. Es
muy utilizado en la comunicación de sensores, dado sus escasos requerimientos de recursos.
Un ejemplo de uso de este protocolo es la aplicación de Facebook, Messenger, tanto para el
sistema operativo Android como para iOS.
MQTT se orienta a grandes redes de dispositivos pequeños que necesitan la supervisión o el
control de un servidor de back-end en Internet. No está diseñado para la transferencia de
dispositivo a dispositivo. Tampoco está diseñado para realizar "multidifusión" de datos a
muchos receptores. MQTT es simple y ofrece pocas opciones de control. Las aplicaciones
que usan MQTT, por lo general, son lentas en el sentido de que la definición de "tiempo real"
en este caso se mide habitualmente en segundos.
La arquitectura de MQTT sigue una topología de estrella, con un nodo central que hace de
servidor (broker) con una capacidad de hasta 10000 clientes. El broker es el encargado de
gestionar la red y de transmitir los mensajes, para mantener activo el canal, los clientes
mandan periódicamente un paquete (PINGREQ) y esperan la respuesta del broker
(PINGRESP). La comunicación puede ser cifrada entre otras muchas opciones.
La comunicación se basa en unos "topics" o tópicos (temas o canales de información) que el
cliente que publica el mensaje crea y los nodos que deseen recibirlo deben subscribirse a él.
La comunicación puede ser de uno a uno, o de uno a muchos. Un tópico se representa
pág. 68
mediante una cadena y tiene una estructura jerárquica. Cada jerarquía se separa con '/'. Por
ejemplo:
"edificio1/planta5/sala1/raspberry2/temperatura"
"/edificio3/planta0/sala3/arduino4/ruido"
De esta forma se pueden crear jerarquías de clientes que publican y reciben datos, y un
cliente puede subscribirse a un tópico concreto
("edificio1/planta2/sala0/arduino0/temperatura") o a varios ("edificio1/planta2/#"), como
podemos ver en la imagen:
MQTT es un protocolo muy adecuado en los casos en los que la entrega de mensajes debe de
ser confiable, pero no se disponen de conexiones de red fiables. Algunas de sus principales
aplicaciones son:
● Telemetría.
● Domótica.
● Monitorización de energía.
● Aplicaciones de chat.
● Servicios de notificación.
● Comunicación Publicador/Suscriptor.
En esta forma de comunicación se desacoplan los clientes que publican (Publisher) de los que
consumen los datos (Subscribers). Eso significa que los clientes no se conocen entre ellos,
unos publican la información y otros la consumen, el único requisito es que todos tienen que
conocer al message broker. El desacoplamiento se produce en tres dimensiones; en el espacio
donde el publicador y el suscriptor no tienen por qué conocerse; en el tiempo donde el
pág. 69
publicador y el suscriptor no tienen por qué estar conectados en el mismo momento y en la
sincronización ya que las operaciones en cualquiera de los dos componentes no quedan
interrumpidas mientras se publican o se reciben mensajes.
El servidor, llamado broker, recopila los datos que los publishers le transmiten. Determinados
datos recopilados por el broker se enviarán a determinados subscribers/publishers
(publicadores que se suscriben a otros publicadores) que previamente así se lo hayan
solicitado al broker.
El principio de intercambio se parece mucho al de Twitter. Los publishers envían los
mensajes a un canal llamado tópico. Los subscribers (suscriptores) pueden leer esos
mensajes. Los tópicos pueden estar distribuidos jerárquicamente de forma que se puedan
seleccionar exactamente los que se desean. Los mensajes enviados por los objetos
comunicantes pueden ser de todo tipo pero no pueden superar los 256 Mb.
MQTT posee 14 tipos de mensajes aunque normalmente un usuario sólo utiliza los
siguientes:
● Connect
● Publish
● Subscribe
● Unsubscribe
MQTT no es tan ampliamente utilizado como HTTP, pero aún tiene una gran participación en
el mercado de las TIC. Existen muchos ejemplos, proyectos, clientes/productores de código
abierto en cada lenguaje. Muchas plataformas IoT soportan HTTP y MQTT como los
primeros dos protocolos de entrada de información.
En caso que una aplicación no soporte MQTT, existen varias herramientas de código abierto
para incluir información de MQTT en las bases de datos y otros formatos como HTTP. Que
dos aplicaciones soporten MQTT no quiere decir que puedan operar entre sí. El topic y los
formatos JSON quizá necesiten ajustarse para que dos productos puedan operar entre sí.
En cuanto a los aspectos de seguridad los datos de IoT intercambiados pueden resultar muy
críticos, por lo que es posible garantizar la seguridad de los intercambios en varios niveles:
● Capa de Transporte en SSL/TLS.
● Autenticación mediante certificados SSL/TLS.
● Autenticación mediante usuario y contraseña.
2.3.1 QoS para MQTT
Quality of Service, en general, es un método que se utiliza para medir o clasificar la
capacidad que tiene una red para establecer prioridades en la transmisión de sus datos, en
aquellos puntos donde se puedan producir cuellos de botella importantes.
pág. 70
Básicamente se especifican una serie de criterios sobre los cuales se decide qué mensaje es
importante y sobre el cual se deberían proporcionar mecanismos adicionales para garantizar
su entrega. Estos criterios se proporcionan en forma de niveles, de forma que a mayor nivel,
mayor garantía de entrega de los mensajes.
El nivel máximo que es necesario implementar en una red dependerá mucho de las
necesidades de la aplicación en cuestión y de las consecuencias que pueda tener el hecho de
que un mensaje no llegue a su destino.
Existen tres niveles Quality of Service para MQTT (0, 1 y 2) y cada valor determina cómo
será entregado cada mensaje. Es decir, cada mensaje transmitido debe de estar marcado con
un nivel QoS 0, 1 o 2 y este nivel indica si ese mensaje es importante y si se tiene que
garantizar su entrega.
En este caso, el bróker MQTT es el que tiene gran parte de la responsabilidad de entrega
según el nivel QoS indicado en el mensaje. Por eso, es muy importante elegir el valor
adecuado de QoS para cada mensaje, porque este determina cómo el cliente y el bróker van a
actuar para entregar el mensaje.
Se trata de una de las principales ventajas que aporta MQTT a Internet de las Cosas, ya que
permite la retransmisión de mensajes y asegura su entrega en redes poco robustas y propensas
a las pérdidas de datos, como las redes inalámbricas tipo Bluetooth, Wifi o aquellas del
estándar 802.15.4, que se despliegan en el corazón mismo de Internet de las Cosas.
2.3.1.1 Degradación del QoS para MQTT
Desde el punto de vista de QoS para MQTT, el envío de un mensaje consta siempre de dos
fases:
● El cliente envía (publica) el mensaje hacia el bróker.
● El bróker recibe el mensaje y lo reenvía al cliente/s suscrito/s.
Y en cada fase, el nivel QoS del mensaje puede ser diferente. En la primera fase, el nivel de
Quality of Service de un mensaje particular publicado, es configurado por el cliente que
publica dicho mensaje. Sin embargo, cuando el bróker reenvía ese mismo mensaje a un
cliente suscrito, utiliza el QoS que configuró ese cliente cuando se subscribió. (Aprende aquí
cómo suscribir mensajes MQTT).
Es decir, en cada suscripción, el cliente le dice al bróker cual es el QoS máximo con el cual
quiere recibir mensajes. Ahora bien, cualquier mensaje para esa subscripción que venga con
un QoS mayor que ese, será degradado para que ese cliente pueda recibir también el mensaje.
Vale aclarar que la degradación que se lleva a cabo es particular para el cliente en cuestión, es
decir que no afecta al resto de los clientes.
A continuación se muestran todas las combinaciones que se pueden dar:
pág. 71
● El cliente A se ha suscrito a un tópico con un QoS 0.
○ El cliente B publica con un QoS 0, por lo tanto, el mensaje llegará (o no, pues
no hay ninguna garantía) al cliente A como máximo una vez con un QoS 0, sin
tener ninguna garantía de entrega.
○ El cliente B publica con un QoS 1. El bróker degrada el mensaje a QoS 0 y por
lo tanto, el mensaje llegará (o no) al cliente A como máximo una vez con un
QoS 0, sin tener ninguna garantía de entrega.
○ El cliente B publica con un QoS 2. El bróker degrada el mensaje a QoS 0 y por
lo tanto, el mensaje llegará (o no) al cliente A como máximo una vez con un
QoS 0, sin tener ninguna garantía de entrega.
● El cliente A se ha subscrito a un tópico con un QoS 1.
○ El cliente B publica con un QoS 0. No hay degradación y por lo tanto, el
mensaje llegará (o no) al cliente A como máximo una vez con un QoS 0, sin
tener ninguna garantía de entrega.
○ El cliente B publica con un QoS 1. No hay degradación y por lo tanto, el
mensaje llegará al cliente A como mínimo una vez con un QoS 1.
○ El cliente B publica con un QoS 2. El bróker degrada el mensaje a QoS 1 y por
lo tanto, el mensaje llegará al cliente A como mínimo una vez con un QoS 1.
● El cliente A se ha subscrito a un tópico con un QoS 2.
○ El cliente B publica con un QoS 0. No hay degradación y por lo tanto, el
mensaje llegará (o no) al cliente A como máximo una vez con un QoS 0, sin
tener ninguna garantía de entrega.
○ El cliente B publica con un QoS 1. No hay degradación y por lo tanto, el
mensaje llegará al cliente A como mínimo una vez con un QoS 1.
○ El cliente B publica con un QoS 2. No hay degradación y por lo tanto, el
mensaje llegará al cliente A exactamente una vez con un QoS 2.
2.3.1.2 Niveles QoS para MQTT
QoS 0 – At Most Once (Se entrega como máximo una vez)
Quality of Service para MQTT – QoS 0
Es el nivel mínimo y se describe como “at most once message delivery”, es decir, el mensaje
o bien llega al bróker o cliente receptor como máximo una vez o no llega jamás.
pág. 72
En este nivel, básicamente se confía en los mecanismos de la capa TCP/IP de la red para que
el mensaje llegue y llegue en condiciones.
MQTT no implementa ningún mecanismo adicional para asegurarse la entrega. El cliente o el
bróker intentan enviar el mensaje sin esperar ninguna confirmación de recepción del mismo.
No hay retrasmisión por parte del transmisor del mensaje en caso de fallo. Por eso se dice que
el mensaje llega una vez o se pierde en el limbo para siempre.
Si el servidor falla o el cliente se desconecta de la red, cualquier mensaje QoS 0 se perderá.
Por otro lado, este nivel requiere pocos recursos de la red, por lo que es el nivel ideal si se
quiere enviar mensajes rápidamente sin preocuparse de su entrega.
En el nivel QoS 0, la secuencia de acciones es la siguiente:
1. Un cliente envía un mensaje PUBLISH con los campos QoS = 0 y DUP = 0.
2. El bróker recibe el mensaje QoS 0 y lo reenvía a los suscriptores del topic, o bien el
mensaje no llega nunca.
Una vez que termina esta secuencia, finaliza la comunicación, es decir, no hay mensaje de
confirmación de entrega PUBACK ni nada que se le parezca.
QoS 1 – At Least Once (Se entrega como mínimo una vez)
Quality of Service para MQTT – QoS 1
En este nivel, se garantiza que el mensaje será entregado al menos una vez al receptor. Al
menos una vez significa que si el receptor del mensaje no confirma su entrega, el transmisor
podría volver a enviar el mensaje.
Aquí, la recepción del mensaje se confirma enviando un mensaje PUBACK.
En caso de que se detecte algún fallo en la comunicación o el mensaje PUBACK no se reciba
dentro de un periodo de tiempo especificado, se vuelve a enviar el mensaje PUBLISH y el
flag DUP a ‘true’, indicando que es un mensaje duplicado.
El bróker entonces recibe el mensaje duplicado, lo reenvía de nuevo a los subscriptores y
envía al cliente otro mensaje de confirmación PUBACK.
pág. 73
El cliente además almacena todos los mensajes QoS 1, mientras estos no estén confirmados.
Esto es otra característica de MQTT que se denomina persistencia en cliente.
En el nivel QoS 1, la secuencia de acciones es la siguiente:
1. En el lado emisor (puede ser un cliente o el bróker)
1. El emisor envía un mensaje PUBLISH con un nuevo identificador de paquete
(packetId) que no esté en uso, un QoS = 1 y un DUP = 0.
2. El emisor sabe que debe recibir una confirmación mediante un mensaje
PUBACK con el mismo packetId.
3. El emisor podría enviar nuevos mensajes PUBLISH con nuevos packetId
mientras espera por las confirmaciones.
4. Si el emisor no recibe PUBACK en un tiempo preestablecido, volverá a enviar
el mensaje PUBLISH, esta vez con el flag DUP = 1.
Nota: los packetId estarán de nuevo disponibles para su uso cuando se reciben sus
correspondientes mensajes PUBACK.
2. En el lado receptor (puede ser un cliente o el bróker)
1. El receptor recibe el mensaje con un QoS 1 y lo procesa de inmediato. Si el
receptor es el bróker, este enviará el mensaje a todos los clientes suscriptores
del mensaje y lo almacenará en una base de datos, por ejemplo.
2. El receptor responde a un PUBLISH con un mensaje PUBACK que tiene el
mismo identificador de paquete.
3. Después de enviar el mensaje PUBACK, el receptor debe tratar cualquier otro
mensaje PUBLISH que le llegue con el mismo identificador de paquete como
si fuera un nuevo mensaje, independientemente de si el flag DUP está a ‘true’.
Considera que ya ha hecho su trabajo y ya es problema del cliente el recibir el
mensaje PUBACK.
QoS 2 – Exactly Once Delivery (Se entrega exactamente una vez)
Quality of Service para MQTT – QoS 2
Es el nivel QoS más alto implementado para MQTT y garantiza que los mensajes duplicados
no son enviados al receptor. Es decir, el mensaje se entrega solamente una sola vez.
pág. 74
Es el nivel más seguro pero también es el más lento y el que más tráfico genera, debido a que
utiliza un doble flujo de comandos para asegurarse de que el mensaje sólo llega una vez al
receptor.
El flujo de mensajes es el siguiente:
1. El receptor recibe un mensaje mediante un PUBLISH con un QoS 2 y un packetId
para ese mensaje. Procesa el mensaje (acciones internas para extraer el packetId, lo
almacena en la capa de persistencia si procede, etc…) y almacena una referencia del
packetId para evitar volver a procesar el mismo mensaje posteriormente.
2. El receptor envía una confirmación con PUBREC al emisor del mensaje con el mismo
packetId.
3. Cuando el emisor recibe el PUBREC, deshecha ya el mensaje original porque sabe
que el receptor lo ha recibido.
4. El emisor guarda el mensaje PUBREC y envía un mensaje PUBREL, de nuevo con el
mismo packetId utilizado durante todo el intercambio.
5. Cuando el receptor recibe el mensaje PUBREL, ya puede desechar cualquier estado
anterior almacenado sobre el mensaje y transmitir el mensaje a los clientes
suscriptores. Además envía un mensaje PUBCOMP al emisor, en respuesta a
PUBREL.
6. El emisor desecha cualquier estado anterior del mensaje cuando recibe el PUBCOMP.
Cuando se completa la secuencia, ambos participantes saben que el mensaje ha sido
entregado.
Si cualquiera de estos paquetes se pierde, el emisor (que puede ser un cliente o un bróker
MQTT) es responsable de volver a enviar el último comando antes de un periodo de tiempo
preestablecido. Del mismo modo, el receptor es responsable de responder a cada comando.
2.3.2 Conclusión
A pesar de sus características, MQTT puede suponer un problema para algunos dispositivos
muy restrictivos, por el hecho de ir sobre TCP y de manejar nombres de tópicos largos. Esto
se soluciona con la variante MQTT-SN que utiliza UDP y soporta indexación de nombres de
tópicos.
Este protocolo es uno de los que más estrechamente ligado se encuentra a Internet de las
Cosas. MQTT presenta una serie de características que lo hacen especialmente atractivo para
el mundo Internet de las Cosas:
● Es open source, con lo cual es fácilmente integrable al universo de tecnologías,
protocolos y aplicaciones de Internet de las Cosas.
● Puesto que se basa en el modelo publicador/suscriptor de mensajes, no se necesita
saber para quién van los mensajes o de donde vienen, reduciendo mucho la
complejidad de la red.
pág. 75
● Debido al inciso anterior, es un protocolo ligero (cabeceras muy reducidas,
comunicación bajo demanda, etc.) con lo cual se ajusta a redes y dispositivos con
pocos recursos y baja velocidad de transmisión, como una típica red de sensores.
● Se basa en comandos muy sencillos y varios modos de gestión de mensajes, y además,
no necesita que el contenido del mensaje esté en un formato específico.
● Tiene mecanismos para garantizar una comunicación fiable, retransmitiendo o
guardando para más tarde los mensajes cuando se pierda la conexión entre servidor y
cliente. Para esto implementa hasta tres niveles de QoS, lo que permite garantizar la
entrega de los mensajes más importantes.
● Permite unir fácilmente el mundo del Business Intelligence (Inteligencia de Negocios)
y el Big Data (macro datos, datos masivos, inteligencia de datos o datos a gran escala)
con las fuentes de datos, pero también es ideal para la conexión machine-to-machine
(M2M).
2.4 CoAP
CoAP (Constrained Application Protocol, 'Protocolo de Aplicación Restringida') fue creado
por IETF (Internet Engineering Task Force, 'Grupo de Trabajo de Ingeniería de Internet') para
proveer la compatibilidad de HTTP con una mínima carga. CoAP es similar a HTTP, pero
usa UDP/multicast en lugar de TCP. Además, simplifica el encabezado HTTP y reduce el
tamaño de cada requerimiento. Este es un protocolo software a nivel de aplicación pensado
para ser usado en dispositivos electrónicos simples permitiendo que puedan comunicarse
sobre Internet.
Este protocolo es utilizado en dispositivos y redes restrictivas en donde HTTP sería
demandante de recursos, y a menudo, las plataformas de IoT lo utilizan como tercer
protocolo, después de HTTP y MQTT. Similar a HTTPS, CoAP usa DTLS (Datagram
Transport Layer Security) para proteger las comunicaciones. CoAP es utilizado
principalmente para trabajar en entornos restringidos. El uso de este protocolo se hace
necesario para conectar pequeños dispositivos a internet, ya que estos normalmente operan en
redes LowPAN con muchas pérdidas de mensajes y el uso de HTTP sería ineficiente. Su
adopción en el mercado no está tan extendida como HTTP, de modo que se limitan las
opciones de software y hardware. Existen soluciones para convertir mensajes CoAP desde y
hacia HTTP que pueden hacer a las soluciones CoAP más interoperables.
A diferencia de MQTT, CoAP es UDP y los paquetes son mucho más pequeños, pero
mantiene la misma arquitectura cliente/servidor y soporta las operaciones GET, PUT, POST
y DELETE. Además extiende el modelo de request añadiendo la función “observe” que
permite al cliente seguir recibiendo cambios de un recurso solicitado al servidor.
De manera similar a MQTT, en CoAP se puede controlar la QoS marcando los mensajes
como “confirmable” o “nonconfirmable” lo que indica si el receptor debe devolver un “ack”
o no.
pág. 76
Otras características de CoAP son que soporta negociación de contenido (Content-Type) y
que proporciona un mecanismo de descubrimiento de recursos.
CoAP mantiene el modelo REST y las operaciones básicas de HTTP, para facilitar una
conexión entre los dos protocolos.
En la siguiente ilustración puede verse una comparativa entre los modelos HTTP-REST sobre
TCP/IP y CoAP sobre UDP.
Con el protocolo CoAP se retransmiten un número mucho menor de bytes y en mucho menos
tiempo, lo que supone una ventaja para su uso en pequeños dispositivos con poca memoria de
almacenamiento.
En una red restringida, los sensores actúan como servidores CoAP que ofrecen servicios. A la
información de estos servidores se podrá acceder mediante el protocolo CoAP o a través de
un proxy HTTP-CoAP, a su vez, de esta forma cualquier aplicación podrá acceder a la
información del dispositivo.
pág. 77
También es posible que estos sensores se conecten a recursos HTTP mediante un proxy
CoAP-HTTP.
2.4.1 Funcionalidades del Protocolo CoAP
Las funcionalidades más importantes del protocolo CoAP son las siguientes:
● Diseño REST que facilita el mapeo con el protocolo HTTP.
● Soporta el uso de las opciones URI y Content-type.
● Soporte para el descubrimiento de los recursos proporcionados por los servicios de
CoAP conocidos. Uso del método DISCOVER.
● Suscripción simple para un recurso con recepción de mensajes cuando éste cambia.
Uso del método OBSERVE.
2.4.2 Tipos de Mensajes
CoAP hace uso de dos tipos de mensajes, peticiones y respuestas. Las cabeceras de los
mensajes se codifican en binario, comenzando por un encabezado base y seguido de una serie
de opciones. El resto del mensaje tras la cabecera, se considera el cuerpo del mensaje.
pág. 78
En la ilustración se observa el modelo del mensaje CoAP. Se puede ver la cabecera con los
valores versión, tipo, longitud del token, código, id del mensaje y Token. Tras esto aparecen
las opciones y finalmente el cuerpo del mensaje.
Para mapear las peticiones con las respuestas se utilizan el Token y el identificador del
mensaje. El Token es una cadena de bytes generada en la petición. Si la respuesta se envía
contestando al mensaje de la petición, el Token debe ser el mismo. En caso de que la
respuesta sea independiente de la petición, el Token será diferente.
No ocurre lo mismo con el identificador del mensaje, ya que una petición y su respuesta
tendrán siempre el mismo identificador.
2.4.3 Soluciones Existentes
En la actualidad existen diversas implementaciones del protocolo CoAP que pueden
clasificarse en función de las funcionalidades ofrecidas o del lenguaje de programación
utilizado para su implementación. A continuación se mostrarán las características de algunas
de las más utilizadas:
● Libcoap:
○ Desarrollada en C, lo que supone posibilidades de uso en infinidad de
dispositivos.
○ Permite el uso de cliente y servidor.
○ Licencia libre.
○ Implementa la opción OBSERVE.
● Californum:
○ Desarrollado en JAVA y ampliamente extendido.
○ Permite el uso de cliente y servidor.
○ Licencia libre.
○ Implementa la opción OBSERVE.
○ Incluye una capa DTLS (Datagram Transport Layer Security) de seguridad.
○ En su última versión permite el uso de proxy.
● txThings:
○ Desarrollado en Python
○ Permite el uso de cliente y servidor.
○ Licencia libre.
○ Implementa la opción OBSERVE de forma parcial.
● ETRI CoAP:
○ Desarrollado en C.
○ Permite el uso de cliente y servidor.
○ Licencia comercial.
○ Implementa la opción OBSERVE.
pág. 79
2.5 DDS
DDS (Data Distribution Service, ‘servicio de distribución de datos’) es un protocolo
publicador/suscriptor que se focaliza en el borde de la comunicación en la red. DDS es un
estándar abierto operado por OMG (Object Management Group, ‘Grupo de Gestión de
Objetos’). A diferencia de MQTT, que requiere de un agente centralizado, DDS está
descentralizado. Los nodos de DDS se comunican directamente punto a punto a través de
UDP/multidifusión (multicast). Esto hace que no sea necesaria una gestión centralizada de la
red y que DDS sea un protocolo más veloz, con una resolución por debajo del milisegundo.
DDS es una buena solución para la entrega de información de forma confiable y en tiempo
real. Se utiliza para comunicaciones rápidas M2M (machine to machine, ‘máquina a
máquina’).
Se trata de un protocolo que se utiliza principalmente para comunicaciones dispositivo-a-
dispositivo en tiempo real. DDS cuenta con una arquitectura centralizada y se lo ha
optimizado para procesamiento distribuido. Si bien es muy útil, tiene algunas limitaciones en
términos de flexibilidad cuando hay que seleccionar la funcionalidad que exponen los
dispositivos. También su escalabilidad es limitada y no cuenta con soporte para compresión
de datos. Otra limitación es la de no poder utilizar multicasting en forma libre.
2.5.1 Arquitectura
La especificación DDS describe dos niveles de interfaces:
● Una DCPS (Data-Centric Publish-Subscribe) a nivel inferior que tiene por objeto
hacer un reparto de la información de forma eficiente a los receptores apropiados.
● Una capa superior opcional DLRL (Data Local Reconstruction Layer) que permite
una integración simple de DDS en la capa de aplicaciones.
pág. 80
Ventajas de su empleo:
● Disminución del acoplamiento entre entidades - debido en parte al empleo de la
filosofía publicador/suscriptor.
● Arquitectura flexible y adaptable - gracias al empleo del 'discovery' automático
(RPTS).
● Eficiencia - debido a la comunicación directa entre el publicador y el suscriptor.
● Determinismo - en la consigna de los datos.
● Escalabilidad - debido en parte a la disminución del acoplamiento entre entidades.
● Calidad de servicio - altamente parametrizable
● Independencia de la plataforma - debido al empleo de estándares como IDL, lenguaje
de descripción de interfaz.
2.6 AMQP
AMQP (Advanced Message Queuing Protocol) es otro protocolo tipo publicador/suscriptor
que proviene del sector de servicios financieros. Tiene su presencia en TIC pero bastante
limitada en la industria.
El mayor beneficio de AMQP es su modelo robusto de comunicaciones que soporta
transacciones. A diferencia de MQTT, AMQP puede garantizar transacciones completas (lo
cual, aunque útil, no siempre es algo que requieran la aplicaciones IoT).
AMQP se agrupa a menudo con protocolos IoT pero su mayor contra es que se trata de un
protocolo pesado. Fue destinado para sistemas TIC, y no para redes limitadas.
Las características que definen al protocolo AMQP son la orientación a mensajes,
encolamiento (queuing), enrutamiento (tanto punto-a-punto como publicación-subscripción),
exactitud y seguridad.
AMQP estipula el comportamiento tanto del servidor que provee los mensajes como del
cliente hasta el punto de que las implementaciones de diferentes proveedores son
verdaderamente interoperables, de la misma manera que los protocolos SMTP, HTTP, FTP y
análogos han creado sistemas interoperables.
En síntesis, el protocolo AMQP está enfocado en no perder mensajes, trabaja sobre TCP y
proporciona una conexión punto a punto fiable. Se utiliza sobre todo en funciones de análisis
basados en servidores. Dos de las razones para utilizar este protocolo es la confiabilidad y la
interoperabilidad.
2.6.1 Modelo AMQP
AMQP define un conjunto de entidades. Desde la perspectiva de la interconexión las más
relevantes son:
pág. 81
● El corredor de mensajes: un servidor al que los clientes AMQP se conectan usando el
protocolo AMQP. Los corredores de mensajes pueden ejecutarse en un entorno
distribuido, pero esta capacidad es específica de la implementación y no está cubierta
por la especificación.
● Usuario: un usuario es una entidad que, mediante la presentación de credenciales tales
como una contraseña, puede ser autorizado o no a conectarse a un corredor.
● Conexión: conexión física usando, por ejemplo, TCP/IP o SCTP. Una conexión está
ligada a un usuario.
● Canal: una conexión lógica que está unida a una conexión. Así, la comunicación a
través de un canal posee un estado. Aquellos clientes que realicen operaciones
concurrentes mediante una misma conexión deben mantener un canal distinto para
cada una de ellas. Aquellos clientes que usen un modelo basado en hilos para la
concurrencia pueden, por ejemplo, encapsular la declaración del canal en una variable
local de cada hilo.
Las entidades utilizadas para el envío y recepción de mensajes en concreto son todas
declaradas dentro de un canal. Una declaración garantiza, al cliente que la realiza, que la
entidad existe (o fue previamente declarada por otro cliente). Cualquier intento de declarar
una entidad nombrada con propiedades diferentes de las que poseía cuando fue declarada
resulta en un error. Para poder cambiar las propiedades de una entidad nombrada, debe ser
primero borrada con anterioridad a su nueva creación.
Algunas de estas entidades están nombradas. Su denominación debe ser única dentro del
alcance de la entidad y de su corredor. Dado que los clientes habitualmente no tienen los
pág. 82
medios para obtener una lista de todas las entidades nombradas disponibles (al menos no hay
una operación tal definida dentro de la especificación AMQP), es el conocimiento del nombre
de una entidad lo que permite al cliente realizar operaciones sobre ésta.
Los nombres que usan la codificación UTF-8, deben tener una longitud de entre 1 y 255
caracteres y deben empezar por un dígito, una letra o un guion bajo.
2.6.1.1 Intercambiadores
Los intercambiadores son las entidades a las que se envía los mensajes. Tienen un nombre, un
tipo y ciertas propiedades tales como:
● Pasivo: el intercambiador no será declarado pero ocurrirá un error si no existe.
● Perdurable: el intercambiador sobrevivirá a un reinicio del intercambiador.
● Auto borrado: el intercambiador será borrado tan pronto como ya no queden colas
vinculadas a él. Aquellos intercambiadores que nunca hayan tenido colas vinculadas
nunca serán auto borrados.
2.6.1.2 Colas
Las colas son las entidades que reciben mensajes. Tienen un nombre y propiedades pero no
tienen tipo. Los clientes pueden suscribirse a las colas, con el efecto de que el corredor de
mensajes les entregará (mediante un mecanismo de push, es decir, de forma activa por parte
del corredor) a los clientes, los contenidos de la cola. Alternativamente los clientes pueden
hacer saltar activamente mensajes de la cola como crean conveniente (mecanismo de pull).
La cola garantiza que los mensajes son entregados en el mismo orden en que llegaron a la
cola; esta ordenación se conoce habitualmente como FIFO. En algunos casos de re
enrutamiento (por ejemplo debido a un fallo que implique un reinicio del corredor) este orden
no se garantiza.
Las propiedades de las colas incluyen:
● Intercambiador alternativo: cuando un mensaje es rechazado por un suscriptor o
queda huérfano debido a la destrucción de una cola, estos son re enrutados a un
intercambiador alternativo y borrados de esta cola.
● Pasiva: la cola no será declarada pero ocurrirá un error si no existe.
● Perdurable: la cola sobrevivirá a un reinicio del corredor.
● Exclusiva: sólo puede haber un cliente para esta cola específica.
● Auto borrado: la cola será borrada tan pronto como no queden suscripciones activas
para ella. Esta propiedad comparte la misma limitación que la propiedad de auto
borrado para los intercambiadores: si ninguna subscripción ha estado jamás activa
para esta cola, no será auto borrada. Una cola exclusiva, sin embargo, siempre será
auto borrada cuando el cliente cierre la sesión.
pág. 83
2.6.1.3 Mensajes
Los mensajes no tienen nombre y son publicados en un intercambiador. Consisten en un
encabezamiento y un cuerpo de contenido. Mientras que el cuerpo contiene datos opacos, el
encabezamiento contiene una serie de propiedades opcionales:
● Clave de enrutamiento (routing-key): este campo se usa de diferentes formas
dependiendo del tipo de intercambiador.
● Inmediato: el mensaje será tratado como imposible de enrutar si al menos una de las
colas que deberían recibir el mensaje no tiene ninguna suscripción.
● Modo de entrega: indica que un mensaje puede necesitar perdurabilidad. Sólo para
este tipo de mensajes puede el corredor hacer un intento (best-effort) para impedir la
pérdida del mensaje antes de que sea consumido. Si hay alguna incertidumbre del lado
del corredor sobre la recepción correcta del mensaje (por ejemplo en caso de errores),
puede opcionalmente entregar un mismo mensaje más de una vez. Los modos de
entrega no persistentes no muestran este tipo de comportamiento.
● Prioridad: un indicador (en el rango entre 0 y 9) de que un mensaje tiene precedencia
sobre otros.
● Vencimiento (expiration): la duración en milisegundos antes de que el corredor pueda
tratar el mensaje como imposible de enrutar.
2.6.1.4 Vinculaciones
Una vinculación (binding) es una relación entre una cola y un intercambiador que especifica
cómo fluyen los mensajes desde el intercambiador a la cola. Las propiedades de la
vinculación concuerdan con el algoritmo de enrutamiento que se usa en los intercambiadores.
Las vinculaciones (y los algoritmos de los intercambiadores) pueden ser ordenados en una
escala de menor a mayor complejidad:
● Incondicional: la vinculación no tiene propiedades y reclama todos los mensajes del
intercambiador.
● Condicional con una cadena fija: la vinculación tiene una propiedad, la clave de
enrutamiento y reclama todos los mensajes que tengan una clave de enrutamiento
idéntica.
● Condicional con un patrón de reconocimiento: la vinculación tiene una propiedad, la
clave de enrutamiento y reclama todos los mensajes que sean detectados por un
algoritmo de reconocimiento de patrones. Se puede usar cualquier sintaxis arbitraria
de patrones. AMQP implementa el reconocimiento de temas.
● Condicional con múltiples cadenas fijas: la vinculación tiene una tabla de
propiedades, los argumentos, y reclama todos los mensajes cuyos encabezamientos se
correspondan con estos argumentos, usando operaciones lógicas AND o OR para
combinar las diferentes correspondencias.
● Condicional con una comparación algorítmica: la vinculación tiene una expresión
algorítmica (como una cláusula WHERE en una sentencia SELECT en SQL) y
pág. 84
reclama todos los mensajes cuyos encabezamientos se correspondan con esta
expresión.
● Condicional con inspección del contenido: la vinculación específica criterios
arbitrarios que sólo pueden ser resueltos mediante la inspección del contenido
concreto del mensaje.
No todas estas vinculaciones son implementadas de manera estándar, o por todas las
implementaciones.
2.6.1.5 Tipos de intercambiadores y el efecto de las vinculaciones
Estas cuatro entidades forman el modelo básico de AMQP. La clave para entender cómo un
mensaje es pasado a una cola reside en la relación entre el tipo de intercambiador y la
interpretación resultante de la clave de enrutamiento.
Un intercambiador entregará como máximo una copia de un mensaje dado a una cola si la
clave de enrutamiento en el mensaje se corresponde a una vinculación (otras vinculaciones
posteriores semánticamente idénticas no pueden resultar en copias duplicadas del mismo
mensaje). Lo que constituye una correspondencia, por contra, es exclusivamente dependiente
del tipo de intercambiador:
● Un intercambiador directo considera que hay correspondencia cuando la clave de
enrutamiento y la clave de la vinculación son idénticas.
● Un intercambiador de abanico (fanout) siempre considera que hay correspondencia,
incluso con vinculaciones sin clave.
● Un intercambiador con un tema definido (topic exchange) considera que hay
correspondencia si la propiedad de clave de enrutamiento de un mensaje coincide con
las palabras claves de una vinculación. Estas palabras son cadenas de caracteres
separadas por puntos. Dos caracteres adicionales son también válidos: el asterisco "*",
que crea una correspondencia con 1 palabra, y la almohadilla "#", que crea una
correspondencia con 0 a N palabras. Por ejemplo, *.stock.# tendrá una
correspondencia con las claves usd.stock y eur.stock.db, pero no con stock.nasdaq.
● Un intercambiador de encabezamientos considera que hay correspondencia en
presencia tanto de claves como de pares clave-valor que pueden ser concatenadas con
conexiones lógicas AND y OR en el encabezamiento de un mensaje. En este caso, la
clave enrutamiento no es un criterio de correspondencia que sea considerado por el
intercambiador. Ni tampoco contiene la vinculación una única clave de enrutamiento,
sino un formato especial que contiene claves de encabezamiento y/o pares clave-valor
que crean una correspondencia al estar presente la clave del encabezamiento o al estar
presente la clave del encabezamiento y el valor ser el mismo, respectivamente.
Otros tipos de intercambiadores, por ejemplo específicos del suministrador, son permitidos
explícitamente por la especificación.
pág. 85
El concepto de vincular colas denominadas con intercambiadores denominados tiene
propiedades poderosas (mientras que la vinculación mantiene ambas entidades
independientes entre sí). Es posible, por ejemplo, vincular una única cola mediante
vinculaciones múltiples a un único intercambiador, o a varios. O múltiples consumidores
pueden compartir el nombre de una cola y vincularse a ella con los mismos parámetros,
obteniendo por tanto sólo los mensajes que los otros consumidores no hayan consumido. O
múltiples consumidores pueden declarar colas independientes pero compartir las mismas
vinculaciones y obtener por tanto todos ellos el mensaje que otro consumidor hubiera
obtenido en el intercambiador vinculado con estas vinculaciones.
pág. 86
CAPÍTULO 6:
REDES DE COMUNICACIÓN
INALÁMBRICAS Y SENSORES
1 Introducción
Entre los componentes más importantes que componen la arquitectura de IoT se encuentran
los dispositivos (objetos que se conectan a una red), la infraestructura de comunicación
(tecnologías de red que posibilitan la conexión de los dispositivos) y la infraestructura de
computación (herramientas que consumen los datos enviados desde los dispositivos).
En los últimos años el concepto de IoT ha ganado interés por parte de las empresas más
reconocidas mundialmente, universidades y la comunidad de desarrolladores alrededor del
mundo. Esta popularidad se debe a diversos actores que han influido en ella:
Nuevos sensores y dispositivos. Se han creado nuevos sensores con menor consumo
de energía y coste, lo que ha supuesto su uso masivo en todo el mundo; además han
aparecido nuevas plataformas hardware que se pueden combinar con estos sensores,
como el caso de Raspberry Pi o Arduino.
La aparición del cloud computing. La creación del concepto de computación en la
nube ha supuesto la puesta en marcha de nuevos servicios basados en la red.
La popularidad de los teléfonos inteligentes. Estos productos aprovechan los avances
en las comunicaciones (Internet + Wi-Fi) para ofrecer la posibilidad de llevar una
dirección IP en el bolsillo.
Y por último el crecimiento de las redes inalámbricas.
IoT se apoya en un montón de “cosas” que recopilan datos mediante sensores y se conectan
para enviar esa información a algún repositorio desde el que serán utilizados para diversas
aplicaciones.
Cuando hablamos de las “cosas”, estamos hablando de dispositivos y objetos del día a día,
desde los más pequeños (relojes, teléfonos) hasta los más grandes (televisores, coches,
edificios, etc.). Estos dispositivos tienen la capacidad de interactuar con los usuarios
obteniendo información mediante sensores, y actuando mediante relés y puertos digitales,
sobre su entorno.
Los dispositivos de IoT deben tener ciertas características especiales que permitan su
utilización para este propósito:
Recoger y transmitir información: el dispositivo puede percibir el entorno (por
ejemplo una casa o el mismo cuerpo humano), recoger la información relacionada con
pág. 87
él (ejemplo, la temperatura o humedad) y transmitirla a diferentes dispositivos (puede
ser un dispositivo móvil) o a Internet (a un servidor web, por ejemplo).
Dispositivos actuadores: pueden ser programados para actuar sobre otros dispositivos
basándose en las condiciones establecidas. Por ejemplo, se puede programar un
dispositivo que encienda las luces cuando se oscurece una habitación.
Recibir información: una característica única de los dispositivos de IoT es que solo
pueden recibir información de la red a la que pertenecen (por ejemplo, de otros
dispositivos) o a través de Internet (por ejemplo, información de nuevos eventos,
nuevo estado de operación y, en algunos casos, nuevas funcionalidades). Queda
excluida la manipulación manual.
Estos dispositivos captan o recopilan datos mediante sensores. Un sensor es cualquier
dispositivo que detecta o mide una magnitud física y entrega una valoración de la misma,
normalmente en forma de un valor digital, es decir un valor utilizable en el “cibermundo”. Un
termostato inteligente en una casa incluye un sensor que mide la temperatura de la habitación
y entrega un valor en grados centígrados que podrá ser mostrado en una pantalla, enviado a la
nube, o recibido en el Smartphone del dueño.
Nuestros celulares, con sus receptores GPS, acelerómetros y giróscopos rastrean nuestros
movimientos a lo largo y ancho del globo terráqueo. Ese mismo tipo de sensores incluidos en
autobuses urbanos o interurbanos, camiones de transporte o flotas de vehículos de alquiler,
permiten una gestión eficiente de los recursos, a la vez que se da un servicio de calidad a los
usuarios.
Otra serie de sensores detectan la presencia o proximidad de objetos o personas en un lugar
determinado. Sensores inductivos u ópticos recogen información sobre los lugares ocupados
en un estacionamiento o en las calles de la ciudad para poder dirigir a los conductores a los
espacios disponibles. Detectores de movimiento permiten encender las luces, la calefacción o
las alarmas cuando una persona aparece en una zona determinada de un edificio.
Hay sensores para recoger información ambiental, como temperatura o humedad, que
permiten controlar el clima en un invernadero o en nuestra casa, como hace el célebre
termostato inteligente NEST de Google; o información visual, como los sensores de
luminosidad repartidos por la ciudad para decidir cuándo activar las luminarias, lo mismo que
en un edificio inteligente para encender luces y bajar persianas. También se pueden utilizar
las cámaras en aplicaciones de seguridad en aeropuertos y centros comerciales, o para que
podamos ver desde el supermercado si en nuestro nuevo frigorífico inteligente falta fruta.
Más complejos son los que incorporan visión artificial: cámaras en vehículos que son capaces
de identificar señales de tráfico, vigilar las líneas de la calzada para ver si nos salimos del
carril y los ojos del conductor para saber si se está durmiendo; cámaras en la entrada y salida
del estacionamiento que leen la matrícula de los vehículos; o cámaras fotográficas capaces de
detectar caras en la escena e, incluso, de ver si esa cara está sonriendo para capturar justo el
momento.
pág. 88
Los datos recopilados hay que enviarlos. Casi no quedan lugares en entornos urbanos, y
pocos en entornos rurales de países industrializados, donde no exista o esté accesible algún
tipo de red de comunicaciones inalámbrica. Sea Wi-Fi en interiores, 3G, 4G, o WiMax en
exteriores.
Gracias a esta ubicuidad de las redes de comunicaciones y al cada vez más bajo costo de uso,
hoy se pueden conectar sensores de forma accesible en lugares hasta hace poco impensables.
En IoT, por lo general, se necesita enviar pocos datos con el menor esfuerzo energético
posible, ya que a menudo funcionan con baterías. Estándares como 4G, de gran ancho de
banda e importante consumo, no son los más adecuados.
Con la aparición de los nuevos estándares de bajo consumo y poco alcance como Bluetooth
Low Energy, además de las nuevas tecnologías LPWA (Low Power Wide Area) se están
acaparando la atención de los grandes operadores de comunicaciones.
Esta interconexión e independencia de los sensores (o dispositivos en general) hace que sea
necesario el empleo de diferentes tecnologías. Un caso particular, y se destaca particular
porque aún a día de hoy no es una tecnología aplicada en todo el mundo o está aplicada
parcialmente, es el empleo del protocolo IPv6. Hace algunos años se estableció que las
direcciones IPv4 se habían acabado por la cantidad de dispositivos conectados alrededor del
planeta. Para solventar dicha problemática se han usado algunos “trucos” técnicos como la
utilización de IP privadas bajo el protocolo NAT (traducción de direcciones de red del inglés
Network Address Translation), que funciona, pero no es lo ideal y que, entre otros, reduce la
velocidad de las conexiones (usualmente imperceptible, pero siempre habrá una degradación
de la conexión con el mecanismo NAT). Por ello es que se ha implementado el estándar IPv6,
el cual es una versión actual del protocolo IP del modelo TCP/IP, diseñado para reemplazar a
la versión 4 que tiene problemas con la cantidad de direcciones que posee (232 direcciones),
lo que limita el crecimiento y uso de internet. Por otro lado la versión 6 del protocolo IP
posee una cantidad de direcciones inmensa (2128 direcciones), esto implica que tendremos
alrededor de 6.7x1017 (670 mil billones) de direcciones por milímetro cuadrado de la
superficie del planeta. Aunque se estima que demorará casi 100 años, según los cálculos, en
acabarse. Las características principales que presenta IPv6 son la capacidad de
direccionamiento extendido, simplificación del formato de cabecera y soporte mejorado para
las extensiones y opciones.
Dado que IoT se trata de poder sumar o incorporar todos los dispositivos posibles a Internet,
implica una relación directa con una gran cantidad de direcciones IP, es decir con IPv6. Es
por ello que IPv6 es la única (en la actualidad) tecnología posible para conectar los “miles de
millones de dispositivos a Internet” y construir IoT. Si establecemos que miles de millones de
dispositivos se conectarán a internet en el futuro y además reconocemos que las direcciones
de IPv4 se están agotando, es lógico que IoT deba implementarse sobre IPv6. De hecho el
pág. 89
Internet Engineering Task Force (IETF) ha estandarizado el stack de IoT por medio de un
protocolo denominado 6lowPAN (RFC 494427
).
Para el caso de las redes de sensores (Wireless Sensor Networks, abreviadamente WSN) su
integración con Internet y los protocolos TCP/IP, amplían su ámbito de aplicación, pero aún
se requiere de un trabajo de integración significativo.
El uso del protocolo IP en WSN, permite la interoperabilidad con otras redes existentes, de
esta forma un nodo, podrá ser alcanzado desde cualquier lugar, dejando de ser un dispositivo
aislado, y también podrá realizar algunas tareas que serían imposibles para otros dispositivos.
Además, los mecanismos de autenticidad, integridad y confidencialidad de los datos
transmitidos por las WSN pueden ser desarrollados más fácilmente cuando están dotadas del
protocolo IPv6. Cabe destacar que IPv6 permite que las redes de sensores sean escalables,
permitiendo incorporar nuevos nodos (en caso de necesidad), donde tanto el hardware como
el software son escalables y capaces de soportar un mayor número de nodos y sensores. De
allí la importancia de su aplicación para entornos IoT y, en general, a futuro en cualquier
entorno.
2 Redes Inalámbricas
La conexión inalámbrica es una de las responsables del impulso que ha tenido IoT en los
últimos años. Gracias a los progresos de la conectividad inalámbrica, IoT ha evolucionado:
de estar al principio enfocada a la tecnología RFID a poder adoptar varias tecnologías para
poder conectar diferentes dispositivos. Para poder entrar más en detalle en los tipos de redes
inalámbricos se deben separar las redes según su rango de comunicación:
WAN (Wide Area Network): las redes que están dentro de esta categoría son aquellas
que recorren grandes distancias, entre diferentes ciudades o países, esto es, se tratan
de redes que se extienden sobre un área geográfica extensa. Por ello muchas veces
suelen ser redes que utilizan porciones de redes de varias compañías diferentes.
MAN (Metropolitan Area Network): se trata de redes que trabajan con mayor alcance
que las redes locales dentro de una misma ciudad o entre varias ciudades cercanas.
LAN (Local Area Network): estas redes de área local son redes de propiedad privada
con pocos kilómetros de extensión. Suelen utilizarse en redes dentro de una empresa o
en el hogar.
PAN (Personal Area Network): son redes de corto alcance, de una extensión máxima
de unos pocos metros.
Los siguientes tipos de redes inalámbricas son con los que la mayoría de aplicaciones de IoT
están relacionadas:
27
http://www.rfc-base.org/rfc-4944.html
pág. 90
Wi-Fi: se trata de una red de datos inalámbrica que utiliza los estándares IEEE
802.11. Se enfoca dentro del tipo LAN y opera sobre las frecuencias de 2,4 GHZ y 5
GHz. Se diferencia de las demás redes por su compatibilidad nativa para redes IP, lo
cual es muy importante dentro del ámbito del IoT, pero es una red que consume una
cantidad de energía relativamente alta y la distancia de recepción de la señal es
limitada, sobre unos 100 metros en espacio abierto y 20 en espacios cerrados.
Bluetooth: esta red se enfoca dentro del tipo PAN y se creó para la transmisión de
servicios multimedia. A partir de esta tecnología se han creado otras y entre éstas se
encuentra el Bluetooth Low Energy (BLE). Esta nueva tecnología se enfoca en la
reducción del consumo y en minimizar la potencia de transmisión. Los dispositivos
wearables se basan sobre todo en este estándar.
Z-Wave: es un protocolo de comunicación dentro del tipo de red LAN que se enfoca
en la domótica. Trabaja en la banda de 908.42MHz evitando las emisoras de la banda
2,4GHz. Su principal característica es la poca necesidad de energía y ancho de banda
para transmitir.
Zigbee: es una tecnología que se enfoca dentro del estándar IEE 802.15.4 y está
orientado a redes PAN para comunicar dispositivos de bajo coste y velocidad. Se
utiliza en el control remoto y su uso se ha generalizado en la domótica, ya que se
transmiten cantidades de información pequeñas y proporciona una larga duración de
batería.
6LoWPAN: es un estándar que permite a las redes basadas en el estándar IEEE
802.15.4 el uso de IPv6, logrando que dispositivos que están conectadas a una red
inalámbrica puedan comunicarse con dispositivos IP.
RFID: se trata de un estándar de identificación por frecuencia radial y se utiliza
principalmente para identificar objetos a una distancia muy corta, de unos pocos
metros, y la detección se hace mediante un lector estacionario que se comunica de
manera inalámbrica con pequeñas etiquetas que están pegadas a los objetos. Estas
etiquetas serán unas pequeñas baterías transpondedoras.
Entre todas estas redes, las consideradas más importantes en el ámbito del IoT se encuentran
las redes Wi-Fi, BLE y los 802.15.4 (Zigbee y 6LoPAN). En la siguiente tabla se observa una
comparativa entre estas tres redes.
Wi-Fi BLE Zigbee
Estándar 802.11 802.15.1 802.15.4
Alcance máximo 100 metros. 10 metros. 75 metros.
Principal
característica Alta velocidad. Bajo coste y potencia.
Alta escalabilidad
y el bajo coste.
Uso
En aplicaciones que
requieran la transmisión de
datos.
Transmisión de contenido
multimedia.
Domótica y el
control remoto.
pág. 91
3 Sensores
Un sensor es un objeto capaz de detectar magnitudes físicas o químicas, llamadas variables
de instrumentación, y transformarlas en variables eléctricas. Las variables de instrumentación
pueden ser por ejemplo: intensidad lumínica, temperatura, distancia, aceleración, inclinación,
presión, desplazamiento, fuerza, torsión, humedad, movimiento, tensión, corriente, potencia,
pH, etc. Una variable eléctrica puede ser una resistencia eléctrica, una capacidad eléctrica
(como en un sensor de humedad), una tensión eléctrica, una corriente eléctrica, etc.
Un sensor es diferente a un transductor, donde el transductor transforma o convierte una
determinada manifestación de energía de entrada en otra diferente manifestación de salida,
como por ejemplo un micrófono el cual es un transductor electroacústico que convierte la
energía acústica (vibraciones sonoras: oscilaciones en la presión del aire) en energía eléctrica
(variaciones de voltaje). El sensor sin embargo, está siempre en contacto con la variable de
instrumentación con lo que puede decirse también que es un dispositivo que aprovecha una
de sus propiedades con el fin de adaptar la señal que mide para que la pueda interpretar otro
dispositivo. Por ejemplo el termómetro de mercurio que aprovecha la propiedad que posee el
mercurio de dilatarse o contraerse por la acción de la temperatura. Un sensor también puede
decirse que es un dispositivo que convierte una forma de energía en otra.
Las áreas de aplicación de los sensores son diversas, algunas de ellas son: la Industria
automotriz, robótica, industria aeroespacial, medicina, industria de manufactura, etc.
Los sensores pueden estar conectados a un computador para obtener ventajas como son el
acceso a la toma de valores desde el sensor, una base de datos, etc.
Este proceso que realiza el sensor, de convertir magnitudes en valores medibles de dicha
magnitud, se realiza en tres fases:
Un fenómeno físico/químico al ser medido es captado por un sensor y muestra en su
salida una señal eléctrica dependiente del valor de la variable física/química.
La señal eléctrica es modificada por un sistema de acondicionamiento de señal, cuya
salida es un voltaje.
El sensor dispone de un mecanismo (por ejemplo, un circuito) que transforma y/o
amplifica la tensión de salida, la cual pasa a un conversor A/D, conectado a un PC. El
convertidor A/D transforma la señal de tensión continua en una señal discreta.
3.1 Características
Las características más relevantes de los sensores son:
Rango de medida: dominio en la magnitud medida en el que puede aplicarse el sensor.
Precisión: es el error de medida máximo esperado.
pág. 92
Offset o desviación de cero: valor de la variable de salida cuando la variable de
entrada es nula. Si el rango de medida no llega a valores nulos de la variable de
entrada, habitualmente se establece otro punto de referencia para definir el offset.
Linealidad o correlación lineal.
Sensibilidad de un sensor: suponiendo que es de entrada a salida y la variación de la
magnitud de entrada.
Resolución: mínima variación de la magnitud de entrada que puede detectarse a la
salida.
Rapidez de respuesta: puede ser un tiempo fijo o depender de cuánto varíe la
magnitud a medir. Depende de la capacidad del sistema para seguir las variaciones de
la magnitud de entrada.
Derivas: son otras magnitudes, aparte de la medida como magnitud de entrada, que
influyen en la variable de salida. Por ejemplo, pueden ser condiciones ambientales,
como la humedad, la temperatura u otras como el envejecimiento (oxidación,
desgaste, etc.) del sensor.
Repetitividad: error esperado al repetir varias veces la misma medida.
Un sensor es un tipo de transductor que transforma la magnitud que se quiere medir o
controlar en otra que facilita su medida. Pueden ser de indicación directa (ejemplo, un
termómetro de mercurio) o pueden estar conectados a un indicador (posiblemente a través de
un convertidor analógico a digital, un computador y un visualizador) de modo que los valores
detectados puedan ser leídos por una persona.
Por lo general, la señal de salida de estos sensores no es apta para su lectura directa y a veces
tampoco para su procesado, por lo que se usa un circuito de acondicionamiento, por ejemplo
un puente de Wheatstone, amplificadores y filtros electrónicos que adaptan la señal a los
niveles apropiados para el resto de los circuitos.
3.2 Resolución y Precisión
La resolución de un sensor es el menor cambio en la magnitud de entrada que se aprecia en la
magnitud de salida. Sin embargo, la precisión es el máximo error esperado en la medida.
La resolución puede ser de menor valor que la precisión. Por ejemplo, si al medir una
distancia la resolución es de 0,01 mm, pero la precisión es de 1 mm, entonces pueden
apreciarse variaciones en la distancia medida de 0,01 mm, pero no puede asegurarse que haya
un error de medición menor a 1 mm. En la mayoría de los casos este exceso de resolución
conlleva a un exceso innecesario en el coste del sistema. No obstante, en estos sistemas, si el
error en la medida sigue una distribución normal o similar, lo cual es frecuente en errores
accidentales, es decir no sistemáticos, la repetitividad podría ser de un valor inferior a la
precisión.
pág. 93
Sin embargo, la precisión no puede ser de un valor inferior a la resolución, pues no puede
asegurarse que el error en la medida sea menor a la mínima variación en la magnitud de
entrada que puede observarse en la magnitud de salida.
4 Conclusión
Las nuevas tecnologías y el avance en las redes de comunicación están facilitando que cada
vez haya más sensores en nuestro entorno, capaces de procesar enormes cantidades de datos
para ayudar a mejorar el funcionamiento de las fábricas, el control de los procesos
productivos, el mantenimiento de las cosechas, detectar terremotos o hasta aspectos de
nuestra vida diaria.
Los sensores son cada vez más comunes en nuestra vida cotidiana. Un coche, por ejemplo,
utiliza docenas de ellos para permitirnos controlar sus funciones básicas. Sin embargo, este
tipo de sensores están muy limitados puesto que, colocados estáticamente en un lugar,
carecen de la capacidad de analizar o actuar sobre los datos que detectan y simplemente su
misión se limita a enviar las mediciones que han registrado a un procesador central.
En definitiva, los sensores todavía podrían dar mucho más de sí. Así lo cree toda una
industria tecnológica que está detrás de ellos, y son cada vez más las empresas y los equipos
de investigadores que trabajan en el desarrollo de este tipo de dispositivos. En este sentido,
compañías como la cadena de supermercados británicos Tesco o la compañía petrolífera Shell
han instalado sistemas de primera generación para controlar y chequear el estado de los
expendedores de gasolina en sus estaciones de servicio.
La multinacional de los microprocesadores Intel tiene abiertas varias líneas de
experimentación, como por ejemplo, la creación de sistemas en centros de atención médica
para ayudar a pacientes con problemas de memoria y avisarles así del momento en el que
tienen que alimentarse.
En la primavera de 2002, el laboratorio de investigación de Intel en Berkeley, en
colaboración con el Colegio del Atlántico en Bar Harbor y la Universidad de California
comenzaron en la isla de Great Duck, en la costa norteamericana de Maine, un proyecto que
utilizaba redes de sensores para controlar los microclimas y los nidos de un tipo de ave
conocido como petrel de las tormentas y conocer, entre otras cuestiones, por qué prefieren
esta isla y no otras. De esta manera, los investigadores tratan de controlar el comportamiento
de estos animales sin irrumpir de manera agresiva en su hábitat.
En los jardines botánicos Huntington, en San Marino, California, donde se conservan unas
quince mil especies de plantas raras, investigadores del Laboratorio de Propulsión a Chorro
(JPL) de la NASA trabajan con una red de sensores web para controlar el calor, la humedad o
el estado del suelo en el que viven las cícadas, un tipo de planta que necesita unas
condiciones muy específicas. Cada pocos minutos, los sensores se actualizan entre ellos,
enviando toda la información a los responsables de las plantas.
pág. 94
Como podemos apreciar, las posibilidades que proponen los sensores, en el marco evolutivo
de las redes de comunicación, son enormes y ofrecen grandes argumentos para ser incluidos
en proyectos de IoT.
pág. 95
CAPÍTULO 7:
ENTORNO DE APLICACIÓN DEL
SISTEMA
1 Introducción
Dada la problemática expuesta a comienzos de este trabajo, se ha planteado la resolución de
la misma mediante la inclusión de tecnologías electrónicas y de comunicaciones, que elegidas
sobre la base del concepto de Internet de las Cosas (IoT), nos permitiera implementar un
sistema con características colaborativas que pueda monitorear y recabar los datos tomados
por diferentes sensores y publicarlos en un entorno web que provea acceso a los diferentes
interesados.
2 Sistema propuesto
El sistema propuesto dispone de diferentes elementos tanto a nivel hardware como software.
La primera parte del sistema está constituida en su mayoría de elementos hardware, los cuales
consisten de un conjunto de sensores y actuadores conectados a diferentes placas que se
encargan de comunicar los datos relevados por los mismos. El nodo central del sistema está
formado por un servidor, denominado Broker, que es el encargado de transmitir los mensajes
entre los que publican la información (placas) y los que se encuentran suscritos a ella
(plataforma web). Como elemento final del sistema, se encuentra una plataforma web la cual
se encarga de la visualización de la información recopilada por las diferentes placas. En el
siguiente diagrama se puede observar el esquema general del sistema.
pág. 96
En el diagrama se puede ver que el flujo de datos comienza con los sensores. Estos son los
que realizan las mediciones de los datos que vamos a estar tratando a lo largo de todo el
sistema. Las placas Arduino son las encargadas de solicitar la información a los diferentes
sensores a los que estén conectadas. Estas placas permiten diferentes métodos de
comunicación y, a su vez, tienen un módulo de conexión WI-FI que les permite transmitir los
datos de forma inalámbrica, además ofrecen compatibilidad entre los diferentes elementos
hardware y software. Otra de sus ventajas es que son de bajo costo, las placas Arduino son
más accesibles comparadas con otras plataformas de microcontroladores.
Toda la información recopilada es recibida por el broker, el cual está en constante ejecución.
Cabe destacar que el sistema descrito en el párrafo anterior se puede escalar hasta N veces,
esto permite poder monitorizar tantos dispositivos como sean necesarios. Este broker
redistribuye la información para que llegue a quien desee recibirla, en este caso particular es
la aplicación web la que recibe dicha información y se encarga de darle el formato adecuado.
Además, por medio de la mencionada aplicación web, la información es almacenada en una
base de datos MongoDB debido a la necesidad de persistencia de los datos.
2.1 Tipo de sistema planteado
Existen dos clases comunes de sistemas de control, sistemas de lazo abierto y sistemas de
lazo cerrado. En los sistemas de control de lazo abierto la salida se genera dependiendo de la
entrada; mientras que en los sistemas de lazo cerrado la salida depende de las consideraciones
y correcciones realizadas por la realimentación. Un sistema de lazo cerrado es llamado
también sistema de control con realimentación.
pág. 97
El sistema que se plantea en esta tesis es claramente un sistema de lazo cerrado, dado que
cada estrategia de control/corrección se manifiesta a partir del valor entregado por los
sensores disponibles, según corresponda el caso.
En los sistemas de lazo cerrado la acción de control está en función de la señal de salida. Los
sistemas de circuito cerrado usan la retroalimentación desde un resultado final para ajustar la
acción de control en consecuencia.
El control en lazo cerrado es imprescindible cuando se da alguna de las siguientes
circunstancias:
● Cuando un proceso no es posible de regular por el hombre.
● Una producción a gran escala que exige grandes instalaciones y el hombre no es capaz
de manejar.
● Vigilar un proceso es especialmente difícil en algunos casos y requiere una atención
que el hombre puede perder fácilmente por cansancio o porque la velocidad de
reacción que requiere el proceso, del orden de milisegundos, es inalcanzable para el
humano, con los consiguientes riesgos que ello pueda ocasionar al trabajador y al
proceso.
Sus características son:
● Ser complejos pero amplios en cantidad de parámetros.
● La salida se compara con la entrada y le afecta para el control del sistema.
● Su propiedad de retroalimentación.
● Ser más estable a perturbaciones y variaciones internas.
Un ejemplo de un sistema de control de lazo cerrado sería un termotanque de agua.
Otro ejemplo sería un regulador de nivel de gran sensibilidad de un depósito. El movimiento
de la boya produce más o menos obstrucción en un chorro de aire o gas a baja presión. Esto
se traduce en cambios de presión que afectan a la membrana de la válvula de paso, haciendo
que se abra más cuanto más cerca se encuentre del nivel máximo.
pág. 98
3 Ambiente de simulación
Para el desarrollo de un ambiente propicio para la inclusión de la tecnología propuesta, se
harán una serie de definiciones y fijarán ciertas premisas, que permitan fijar un marco de
aplicación y alcance.
En primer lugar se identificarán aquellos datos o variables de interés. A las que consideramos
de mayor relevancia, se las puede agrupar en dos grupos bien definidos: aquellas orientadas a
las condiciones climáticas y las orientadas al consumo y generación de energía. A su vez,
podemos realizar una segunda distinción que es de acuerdo al equipo que se esté evaluando.
Se considerarán dos equipos, los molinos de baja potencia y los sistemas fotovoltaicos y de
calentamiento de agua basados en paneles.
Dado que el conjunto total de variables y por ende de placas y sensores necesarios para la
recolección de datos, es considerablemente amplio tanto en cantidad como diversidad, es que
se optó por simular los diferentes tipos de sensores tanto por elementos hardware (pulsadores,
potenciómetros, relés, LDR, etc.) como por software (rutinas de ejecución).
Para la instalación de generadores eólicos, se deben tener en cuenta 2 variables, el consumo
promedio de energía y la velocidad media del viento en la zona. Una estimación aproximada
de la cantidad de energía que generará una turbina puede hacerse utilizando los datos del
fabricante del generador y la velocidad media anual del viento. Cada generador tiene una
curva de potencia y de cantidad de energía generada que relaciona la potencia entregada o la
energía generada en función de la velocidad media del viento. Conociendo la velocidad
media del viento, tendremos una idea de la potencia media que entregará el generador. Lo
que cabe resaltar es la importancia de la media del viento, se estima por normativa para estos
equipos, contar con una media anual mayor a 6 m/s para tener una generación energética
aceptable. Normalmente, antes de iniciar la instalación de un generador eólico, se debe
realizar mediciones y estudios climáticos para determinar el tipo de generador y la viabilidad
de la instalación del equipo. Sin embargo, muchas veces estos estudios son demasiado
costosos por lo que no se justifica su realización; en su lugar se utilizan datos disponibles,
como el mapa de velocidades medias de viento. Aunque estos datos mayormente son
estimados o ponderados en base a otros valores por lo que no muestran una visión real de la
situación. Esta situación descripta resalta la importancia de contar con datos actuales, ya que
permitirían realizar estudios más precisos.
Por ejemplo muchas veces la instalación de un molino de baja potencia se determina en base
a que se estima que se alcanzan las velocidades de vientos nominales para su funcionamiento.
Sin embargo, debido a la falta de datos actuales o de mayor precisión, se pueden obviar
alternativas como la instalación de equipos de mayor capacidad o incluso la posibilidad de
instalar un parque eólico de pequeñas dimensiones.
Para este desarrollo consideraremos que los equipos eólicos de baja potencia ya se encuentran
instalados y, como hemos mencionado, el hecho de poder contar con datos climáticos de
mayor precisión y actuales, permite poder llevar adelante estudios y análisis para futuros
pág. 99
proyectos. Si a esto agregamos la posibilidad de obtener mediciones en tiempo real a través
de Internet, no sólo se podrían realizar estudios más precisos sino que también se reducirían
los costos de adquisición de datos.
Principalmente estos estudios y análisis hacen uso de variables como las velocidades de
viento, la dirección, presión atmosférica y temperatura. Todas ellas son relevadas por
sensores colocados a diferentes alturas en unas torres especiales dedicadas para medición o
en caso de ya contar con los equipos instalados, se instalan en las torres de los molinos, con el
fin de poder contar con datos históricos para futuros ensayos. Las alturas utilizadas para las
tomas de datos, varían de acuerdo a las torres instaladas para su adquisición, normalmente se
toman a 20, 30, 60 y 90 metros de altura. Para cada una de ellas se instalan grupos de
sensores, entre los que se encuentran anemómetros (velocidad del viento), veletas (dirección),
barómetros (presión atmosférica) y termómetros (temperatura) conectados a DataLoggers u
otros dispositivos similares que se encargan de recolectar los valores. Los generadores
eólicos para baja potencia se suelen instalar en torres que varían entre los 24 y los 43 metros
de altura, por lo que posibilita la recolección de datos a 20 y 30 metros. Para la simulación
consideraremos que las torres poseen una altura de 40 metros, por lo que, para fines prácticos,
estableceremos una altura de medición a 30 metros. Para los sensores utilizaremos dos
potenciómetros, uno para simular los anemómetros y otro para simular a las veletas, donde la
variación del voltaje del potenciómetro nos permitirá simular, de forma dinámica, las
variaciones que presentan estas dos variables. Estas son las más representativas y las que
poseen una relación directa con la generación de energía del equipo. Consideramos que los
valores recolectados por los anemómetros estarán comprendidos entre los 0 m/s y los 100 m/s
(360 Km/h), cuyo tope máximo es un aproximado a la máxima velocidad de viento registrada
(371 Km/h o 103.056 mts/s) mientras que los valores de las veletas estarán entre 0° y 360°.
Los datos tomados por los sensores restantes serán representados mediante arreglos de
valores aleatorios, donde cada sensor se corresponderá con un único arreglo de datos. Esta
información será relevada por una rutina de ejecución, la cual cada 30 segundos recolectará
los datos de los sensores y los transmitirá a un servidor (broker).
Como mencionamos anteriormente, el principal problema de los molinos eólicos de baja
potencia es que ante la presencia de velocidades de vientos elevadas, al no contar con
sistemas automáticos de orientación de aspas como en el caso de los grandes equipos eólicos,
los rotores se embalan provocando que queden inoperables. Si bien estos equipos cuentan con
sistemas de control que permiten detener el rotor ante la presencia de vientos fuertes, estos
pueden fallar debido a excesos de viento bajo carga constante o por descensos bruscos en la
carga. Estos casos son muy comunes en la zona, donde las velocidades del viento son muy
cambiantes. Cabe mencionar que además del sistema de control mencionado, estos equipos
cuentan con frenos manuales, utilizados mayormente para mantenimiento, los cuales pueden
ser utilizados para casos de vientos excesivos, sin embargo dependería del tiempo de reacción
de los encargados, por lo que no lo hace una opción viable. Es por ello que como medida de
prevención se podría utilizar un actuador que active un freno mecánico o eléctrico para evitar
que el rotor sufra daños debido a las excesivas revoluciones. Esto se puede implementar de 2
formas: activando el actuador cuando los anemómetros registren valores superiores a un valor
pág. 100
máximo de umbral o mediante el uso de un tacómetro que al superar un valor máximo de
revoluciones (r.p.m.) lo active. Para nuestro caso de estudio y con el fin de evitar incrementar
innecesariamente el número de dispositivos de relevamiento, nos apoyaremos en el uso de los
anemómetros para establecer el momento de activación del freno. El valor umbral de
activación dependerá del tipo de aerogenerador instalado, dicho valor usualmente se
especifica en la descripción del equipo. Como se trabajara en un ambiente simulado, con
equipos que imitan a los reales, dicho valor se determinará en base a la capacidad elegida
para el aerogenerador; mayormente para equipos de estas características se estima que la
velocidad de parada o desconexión ronda los 25 m/s. Como se verá más adelante en la
sección de “visualización de datos”, un operario o encargado de monitorear estos equipos,
puede visualizar cuando se activa dicho mecanismo de freno, y evaluar en base a los datos
climáticos (principalmente la velocidad del viento), el momento más oportuno para volver a
poner en funcionamiento el equipo, y así prolongar su vida útil.
El conjunto de datos descriptos hasta el momento, los podemos clasificar en nuestro primer
grupo, correspondiente a aquellos orientados a las condiciones climáticas, relevados por
dispositivos eólicos. Si bien estos datos son de utilidad para diferentes análisis de índole
climático, también disponemos de aquellos valores relacionados a la energía. Principalmente
nos enfocaremos en la tensión (Voltaje) del banco de baterías y de la corriente (Amperaje)
consumida, para ello utilizaremos dos sensores adicionales: un voltímetro y un amperímetro
respectivamente. Estos valores son de gran relevancia para determinar los consumos
promedios (Watts) de las comunas rurales que hacen uso de estos equipos. Además, con
dichos datos se pueden realizar diferentes estudios de consumos energéticos como también de
evaluación del funcionamiento de los equipos de generación de energías alternativas.
Si adicionalmente incluimos un wattimetro entre el equipo y el regulador de carga (en cual se
encuentra conectado antes de la entrada al banco de baterías), con el fin de obtener la
potencia entregada por el aerogenerador, sumado a las velocidades promedio de viento y las
características propias de los equipos, permitiría obtener la curva de potencia de los
aerogeneradores, posibilitando observar el rendimiento de los diferentes equipos. Estos datos
son muy importantes, dado que se podría determinar qué equipos poseen un mejor
rendimiento en relación a las zonas en donde se encuentran instalados y así poder determinar
qué equipos se adaptan mejor a las necesidades de los usuarios. Es por ello que el panel de
visualización, el cual se detalla más adelante en la sección de “visualización de datos”,
permitirá visualizar estas variables en tiempo real de forma que se pueda observar con mayor
facilidad la relación entre la velocidad del viento y la potencia generada.
Como en el caso anterior, los datos relevados por estos sensores los simularemos por
software mediante arreglos de valores, los cuales serán relevados cada 30 segundos como se
mencionó en párrafos anteriores.
Si bien el auge de los molinos eólicos tuvo un fuerte impacto en la zona, hoy en día la
utilización de sistemas fotovoltaicos es cada vez mayor. Al igual que los sistemas eólicos, los
sistemas fotovoltaicos hacen uso de un banco de baterías, en donde almacenan la energía
recolectada por las celdas o células fotovoltaicas. A estos se le agrega un inversor de
pág. 101
corriente, que es el que permite transformar la corriente continua almacenada en las baterías,
en corriente alterna.
Los paneles fotovoltaicos, como así también los paneles solares, al momento de ser instalados
son orientados a diferentes ángulos de acuerdo diversos factores. Esto se efectúa con el
propósito de obtener el máximo aprovechamiento de la radiación solar de acuerdo a las
estaciones del año y la ubicación geográfica. El ángulo de inclinación depende del momento
del día (amanecer, mediodía y noche), las diferentes estaciones del año (primavera, verano,
otoño e invierno) y la ubicación donde se instalarán los paneles (altitud, longitud y latitud) ya
que se basa en la trayectoria del sol y la orientación relativa del dispositivo solar.
A modo de aclaración existe una variante entre los hemisferios norte y sur de la tierra al
instalar un panel solar, esto es debido al primer aspecto mencionado en el párrafo anterior: la
rotación de la tierra, que marca la hora del día en cada parte del mundo. Ya que en el
hemisferio norte puede ser de mañana, mientras que en el sur está anocheciendo. Por esta
razón se recomienda que los módulos solares en el hemisferio norte, que comprende a
Norteamérica, el Ártico, parte de África, Europa y Asia, estén dirigidos hacia el sur. Mientras
que en las regiones de Sudamérica, el sur de África, Australia y Oceanía, que son parte del
hemisferio sur, se recomienda que los paneles solares se encuentren dirigidos al norte. Cabe
destacar que es un estimativo a grandes rasgos de la orientación más óptima, hay varios otros
factores que influyen como la posibilidad de generación de sombras no contempladas durante
el proceso de instalación. Con respecto al grado de inclinación, se estipula que es igual al
grado de latitud en donde se encuentra ubicado geográficamente. Por ejemplo, para la ciudad
de Trelew que se encuentra en las coordenadas 43º 14´ de latitud sur y es parte del hemisferio
sur, se debe instalar los paneles mirando hacia el norte con un ángulo de inclinación de 43°
14´ respecto a la horizontal en el terreno donde se encuentra. Además de lo planteado, se
debe tener en cuenta la estación del año en que se encuentre ya que altera moderadamente el
ángulo de inclinación inicial. Si bien parece que estos datos carecen de importancia para
nuestro caso de estudio, en verdad son datos relevantes para la determinación del rendimiento
de los equipos, ya que no es lo mismo un panel orientado en una dirección desfavorable o de
poco aprovechamiento que otro que hace uso de la mayor cantidad de radiación solar.
Obviamente, no siempre es posible instalarlos en el lugar más apropiado, por lo que el
rendimiento no será el mismo a lo esperado. Es por ello que cada uno de estos equipos se
monta sobre una base especial, la cual permite ajustar el ángulo de inclinación para establecer
el más provechoso de acuerdo a las condiciones establecidas anteriormente. Algunos equipos,
sobre todo aquellos instalados en parques solares, cuentan con sistemas automatizados
basados en conjuntos de sensores y motores manejados por PLCs que permiten ajustar la
orientación de las celdas en la dirección de mayor radiación solar. También existen otros
dispositivos, llamados seguidores solares o trackers, que permiten que los paneles giren sobre
sí mismos, es decir, permiten seguir la trayectoria del sol desde el amanecer hasta el
atardecer. La principal desventaja es que estos sistemas no son baratos, por lo que los costos
de inversión comparados con la ganancia energética, los hace poco viables para instalaciones
pequeñas como lo son las comunas rurales.
pág. 102
En los casos de instalaciones pequeñas, al momento de la instalación de los paneles, se optan
por 2 alternativas:
● La primera consiste en montarlos en bases fijas, las cuales son orientadas tomando
como referencia las premisas enunciadas en párrafos anteriores; estas bases son
utilizadas principalmente para instalaciones pequeñas de paneles, como por ejemplo
en puestos de guarda faunas o puesteros y para la fijación de calentadores de agua
solares, basados en colectores.
● La segunda implica instalarlos en bases fijas en las cuales, si bien la orientación será
siempre la misma, permiten ajustar el ángulo de inclinación de las celdas. El objetivo
es poder adaptar el sistema de acuerdo a las estaciones del año para tener un mejor
aprovechamiento. Estas consisten en un brazo móvil, ajustado por pernos, donde se
ofrece desde tres hasta cuatro puntos de ajuste. Su desventaja radica en que este
sistema solo permite ángulos de inclinación preestablecidos y deben ajustarse de
forma manual.
Dada la importancia que tiene, tanto la orientación como la inclinación de los paneles
(fotovoltaicos y solares), no solo para un mejor aprovechamiento sino también para estudios
de rendimiento de diferentes equipos y marcas comerciales, es que se considera para este
trabajo importante relevarlos. Sin embargo, dado que muchas de las bases son fijas, hacen
que los datos de orientación no sufran alteraciones mayores, por lo que no se considerarán
como parte del conjunto de datos a recolectar. Por otro lado, el ángulo de inclinación respecto
a la horizontal del terreno si es un dato de interés, sobre todo en aquellos equipos montados
sobre bases ajustables, donde el dato es variante a lo largo del año. Si bien los valores se
encuentran acotados a la cantidad de puntos de ajuste que proporcionan las bases (de tres a
cuatro), en la práctica dado que estos ajustes son manuales, no siempre se realizan en los
tiempos correspondientes o simplemente no se realizan, provocando que sea difícil predecir
estos cambios. Este dato en conjunto con la radiación solar captada, permiten determinar la
cantidad de radiación máxima que puede obtenerse a lo largo del tiempo. Por esta razón es
que ambos valores se agruparán en la misma clasificación, correspondiente a aquellos
orientados a las condiciones climáticas, relevados por equipos solares, pese a que el ángulo
de inclinación no esté directamente relacionado al clima.
En base a la problemática que genera el ajuste manual de la inclinación de los dispositivos, se
podrían incorporar actuadores que ajusten automáticamente los dispositivos de acuerdo a los
cambio de estación, brindándoles a estos sistemas mayor autonomía. De esta forma se
obtendrán sistemas similares a los trackers. Para este caso particular utilizaremos un
servomotor, el cual es un pequeño motor de corriente continua, que será regulado mediante
una señal PWM de Arduino. Los servos, como se mencionó, son también motores de
corriente continua, pero en lugar de diseñarse para obtener un giro continuo que podamos
aprovechar (para mover una rueda por ejemplo), se diseñan para que se muevan en un ángulo
fijo en respuesta a una señal de control, y se mantengan fijos en esa posición. Es por ello que
los hace una de las mejores alternativas para simular los pares de motores que controlan la
inclinación de los paneles fotovoltaicos. Para nuestro caso de simulación el servomotor, se
pág. 103
ajustará de acuerdo a los cambios de estación del año. Los ángulos establecidos serán fijos,
uno por cada estación del año (cuatro).
La toma del valor de inclinación, se puede realizar mediante un sensor llamado inclinómetro
conectado a una placa Arduino, con el fin de obtener con mayor precisión la inclinación del
panel. Sin embargo para nuestro caso de simulación planteado anteriormente, dado que el
ángulo lo fijamos de manera predeterminada de acuerdo al momento del año, tomaremos los
valores utilizados para ajustar el servomotor como datos de inclinación de los paneles
fotovoltaicos. Dado que dicha variable presenta una baja tasa de alteración, la misma será
relevada solo cuando se produce el ajuste de inclinación, como un evento del sistema.
Dependiendo de qué dispositivo se está relevando, panel fotovoltaico o solar, las variables de
interés de índole climático varían. En el caso de los paneles fotovoltaicos, la radiación solar
incidente en la superficie del equipo es de suma importancia para la determinación del
rendimiento de los diferentes equipos. La radiación solar es el conjunto de radiaciones
electromagnéticas emitidas por el sol, se mide mediante un instrumento llamado piranómetro
(también llamado solarímetro y actinómetro), el cual mide la densidad del flujo de radiación
solar (kilovatios por metro cuadrado) en un campo de 180 grados. Se debe tener en cuenta
que para diversos estudios relacionados a la generación fotovoltaica, se consideran tres tipos
de radiación:
● Radiación solar directa: es la radiación que incide directamente del sol.
● Radiación solar difusa: es la radiación dispersada por los agentes atmosféricos (nubes,
polvo, etc.)
● Radiación solar reflejada (albedo): es la radiación reflejada por el suelo o por los
objetos cercanos.
Para la obtención de cada tipo de radiación se emplean diversas técnicas, una de ellas por
ejemplo consiste en tapar el sensor de radiación del piranómetro mediante una pantalla
parasol, con el fin de obtener la radiación difusa. Sin embargo también existen distintos tipos
de piranómetros especializados para la captación de cada tipo de radiación. Para nuestros
fines prácticos se considerará solamente la radiación solar directa, que será la que incide
directamente sobre el equipo. Como la corriente de cortocircuito (con carga nula) de la celda
es directamente proporcional a la radiación captada, se hará uso de un potenciómetro para
simular el piranómetro y de una variable para representar la corriente generada, la cual tendrá
variaciones acordes a los valores entregados por el potenciómetro. Por otro lado al igual que
la corriente, la tensión generada se simulará mediante una variable que se incrementará o
disminuirá de acuerdo a la intensidad de corriente, dado que la misma es dependiente en
cierta forma de ella. Cabe destacar que la tensión de circuito abierto (máximo valor de
tensión en los extremos de la celda con carga nula) varía poco con la radiación, aunque
también decrece, pero a efectos prácticos se la puede considerar constante. A fines prácticos y
con la intención de evitar incrementar innecesariamente el número de variables, se utilizara
una sola variable que representará la potencia generada por el dispositivo.
pág. 104
Otro dato relevante que influye de forma directa en el rendimiento de un panel fotovoltaico es
la temperatura. Las células fotovoltaicas, como se mencionó anteriormente, se comportan
como un generador de corriente eléctrica, cuyo funcionamiento es en función de tres
variables fundamentales: intensidad de la radiación solar, temperatura y área de la celda. La
temperatura de la celda posee un efecto importante sobre el valor de la tensión en circuito
abierto (Voc), provocando que esta disminuya en el orden de unos pocos mili voltios por cada
grado centígrado que aumenta la temperatura. Además, como consecuencia de esta variación
de Voc, a medida que aumenta la temperatura, provoca a su vez, que la eficiencia de la celda
haga lo mismo (se reduce en promedio entre el 0,4 y 0,5 % por º C). Por esta razón es de
suma importancia la obtención de este dato, el cual será representado por un arreglo de
valores que serán tomados cada 30 segundos.
La posibilidad de poder acceder a esta información tiene una especial relevancia sobre todo
para aquellas personas encargadas de mantener estos equipos. Ya que permitiría, de manera
inmediata detectar si los equipos presentan fallas o desperfectos. Uno de los casos más
comunes de mal funcionamiento es provocado por la excesiva cantidad de suciedad en las
celdas solares, provocando que estas no entreguen la cantidad de corriente necesaria para la
carga del banco de baterías. Esto puede solucionarse fácilmente limpiando cuidadosamente
las celdas. Sin embargo hay otros tipos de fallas que requieren de personal técnico capacitado
para su atención, una de las fallas típicas es cuando alguna de las celdas que componen el
panel entra en cortocircuito. Esta no es fácil de detectar a simple vista, la forma más rápida de
darse cuenta es observando los valores de radiación solar, intensidad de corriente (I) y tensión
(V) entregados. Si los valores de radiación no son nulos, pero los valores de I y V lo son,
estamos ante un caso de cortocircuito en alguna de las celdas. Dado que para poder reparar
una de estas fallas, se requiere de herramientas y repuestos específicos, el poder contar con
estos datos en una plataforma web permite a los responsables de su reparación programar
salidas de mantenimiento más provechosas y eficientes de acuerdo a las problemáticas
detectadas y con un mejor tiempo de respuesta en comparación a las salidas rutinarias. Es por
ello que, al igual que en el caso de los aerogeneradores, el panel de visualización
implementado permitirá observar las variables de radiación solar y cantidad de energía
generada en tiempo real, con el fin de lograr dicho objetivo.
En contraste a los paneles fotovoltaicos, los colectores solares no generan energía eléctrica,
sino que utilizan la radiación solar para generar calor, es por ello que uno de sus principales
usos es para el calentamiento de agua para usos sanitarios mediante termotanques solares. Al
igual que los sistemas fotovoltaicos, los colectores solares también hacen uso de la energía
radiada por el sol para producir energía (térmica), sin embargo, a diferencia de los primeros,
este dato no es de relevancia. Para estos dispositivos, los datos que presentan mayor interés
son las temperaturas, tanto la del interior del depósito, como la exterior. El rendimiento de los
colectores mejora cuanto menor sea el salto térmico, es decir, la diferencia de temperatura
entre este y el exterior. Por lo tanto, la eficiencia disminuye al aumentar la temperatura de
trabajo, y al disminuir la temperatura exterior. Si tomamos en cuenta los termotanques
solares, que son los usualmente usados en las CRA, estos cuentan con un sensor térmico
ubicado cerca de la salida de agua del colector con el fin de obtener la temperatura máxima.
pág. 105
Este sensor puede ser reemplazado por cualquier tipo de sensor de temperatura; por ejemplo,
para nuestro caso, por uno con la capacidad de comunicar los datos relevados al broker. A
esto se incorporará un segundo sensor de temperatura con el fin de obtener la temperatura del
exterior o ambiente. Para fines prácticos ambos sensores serán simulados por una rutina de
ejecución, la cual tomará los datos de un arreglo de valores, cada 30 segundos.
Mediante la contrastación de temperaturas, se podría determinar si los equipos están
funcionando de manera adecuada o si requieren mantenimiento, ya que si la temperatura del
exterior no se encuentra por debajo de los 0 °C, la temperatura interna del dispositivo no debe
ser inferior a los 45 °C, que es el mínimo estipulado en invierno. Si la temperatura del interior
del depósito es inferior al valor umbral mínimo y la temperatura exterior no alcanzan valores
por debajo de los 0 °C, significa que el equipo no está funcionando de manera adecuada, ya
sea porque los colectores están dañados o con exceso de suciedad. A sí mismo, si se detecta
que no se mantienen las temperaturas mínimas estipuladas, las cuales varían entre los 45 °C y
55 °C de acuerdo al fabricante, en el interior del depósito durante los períodos mínimos
establecidos de tiempo (entre 60 a 72 hs) también se podría estar en frente a un caso de mal
funcionamiento. En resumen observando estos datos es posible determinar si los colectores se
encuentran funcionando adecuadamente o si requieren ser reemplazados.
Habiendo establecido los equipos más utilizados en la generación de energías alternativas,
sus usos y aquellos datos considerados de interés por los diferentes interesados,
procederemos a establecer un caso de simulación, considerando aquellos más comunes en la
zona.
Tanto equipos eólicos como solares, son instalados principalmente para el abastecimiento de
energía en albergues, escuelas, centros de salud y estancias de puesteros de comunas rurales.
A modo de disponer de un escenario lo más cercano a casos reales, estableceremos un
aerogenerador de baja potencia de 1000 W ubicado en una torre de 40 mts, como se
mencionó en párrafos anteriores, que proporcionará energía a una escuela, principalmente
para iluminación y elementos de primera necesidad conectados al circuito de tomas. Además
contemplaremos dos paneles fotovoltaicos de 260 W de Pmax; uno que proveerá energía a un
centro de salud, como en el caso anterior para iluminación y elementos de primera necesidad
y el segundo proporcionará alimentación a una bomba de agua para el aprovisionamiento de
agua dentro de la comuna rural. En ambos casos referidos a iluminación, estipulamos que se
utilizan luminarias LED de 6 W 24 Vcc. Finalmente, se considerará un termotanque solar
para el calentamiento de agua; el mismo consta de un depósito de 300 litros de volumen y de
30 colectores de 58x1800mm, brindando un área útil de captación de 4,142 m². Cabe destacar
que estamos planteando un caso hipotético que permita tener una visión más clara del
escenario que será objeto de este trabajo. En cuanto al conjunto de sensores encargados de la
recolección de los diferentes datos, se simularán de acuerdo a lo planteado en cada uno de los
casos analizados anteriormente.
El poder adquirir estos datos y accederlos desde una plataforma web, es decir que estén
vinculados a Internet, proporciona no sólo un medio rápido de recolección de datos sino que,
además, permite el análisis de los mismos por diferentes tipos de profesionales en el tema,
pág. 106
como también facilita a los responsables de los mantenimientos de estos equipos, la detección
de forma inmediata cuando alguno de éstos presenta alguna anormalidad en su
funcionamiento. Pudiendo de esta forma coordinar de manera rápida y eficaz las comisiones
por mantenimiento. Además, el hecho de poder suscribirse a aquellos datos de interés
(tópicos) permite que los diferentes interesados se centren en los temas de su predilección.
Por ejemplo, muchas veces los organismos encargados de los aerogeneradores no son los
mismos que el de los paneles, de esta forma se posibilita que cada organismos se centre solo
en aquellos equipos de su jurisdicción.
Finalmente, el poder contar con estos datos en la web permitirá, no solo que profesionales de
diferentes áreas realicen estudios de factibilidad y rendimiento con datos reales y actuales,
sino que también posibilita que cualquier persona pueda disponer de ellos, impulsando de
esta forma el uso de energías alternativas para el ahorro de consumos energéticos.
A continuación se otorga una tabla resumen de las variables mencionadas a partir del
ambiente descrito.
# Variable Tipo Excursión Unidad Alarma
1 Sensor de velocidad media de viento AI 0 - 100 m/s No
2 Actuador de conexión de resistencias de
embalamiento DO - - SI
3 Sensor de dirección del viento AI 0 - 360 ° No
4 Sensor de presión atmosférica AI 870 - 1100 hPa No
5 Sensor de temperatura (Torre del aerogenerador) AI -20 - 60 °C No
6 Sensor de tensión del banco de baterías del
aerogenerador AI 0 - 48 V No
7 Sensor de potencia generada (Aerogenerador) AI 0 - 1000 W No
8 Sensor de corriente consumida (Aerogenerador) AI 0 - 100 A No
9 Sensor de radiación solar (Panel fotovoltaico) AI 0 - 324 Kw/m² No
10 Actuador de inclinación del panel fotovoltaico DO - - SI
11 Sensor de temperatura (Panel fotovoltaico) AI -20 - 60 °C No
12 Sensor de tensión del banco de baterías del panel
fotovoltaico AI 0 - 24 V No
13 Sensor de potencia generada (Panel fotovoltaico) AI 0 - 260 W No
14 Sensor de corriente consumida (Panel fotovoltaico) AI 0 - 100 A No
15 Sensor de temperatura (Panel solar) AI -20 - 60 °C No
16 Sensor de temperatura (Interior del depósito) AI -20 - 100 °C No
Se debe considerar que algunos de los valores definidos están sujetos a variaciones, sobre
todo aquellos relacionados con la potencia generada por los equipos generadores. La potencia
dependerá de las características del dispositivo, es por ello que se deben considerar dichas
características a la hora de contrastar con los valores relevados por los sensores.
Del conjunto de variables descripto tomaremos un conjunto reducido del mismo para el
desarrollo del sistema, ya que para los fines prácticos de este trabajo se considera que no
pág. 107
afecta a los objetivos del mismo. Por lo cual solo consideraremos las variables de mayor
relevancia en relación a la generación de energía y funcionamiento de los equipos. A
continuación se presenta la tabla de variables seleccionadas.
# Variable Tipo Excursión Unidad Alarma
1 Sensor de velocidad media de viento AI 0 - 100 m/s No
2 Actuador de conexión de resistencias de
embalamiento DO - - SI
3 Sensor de dirección del viento AI 0 - 360 ° No
4 Sensor de temperatura (Torre del aerogenerador) AI -20 - 60 °C No
5 Sensor de tensión del banco de baterías del
aerogenerador AI 0 - 48 V No
6 Sensor de potencia generada (Aerogenerador) AI 0 - 1000 W No
7 Sensor de corriente consumida (Aerogenerador) AI 0 - 100 A No
8 Sensor de radiación solar (Panel fotovoltaico) AI 0 - 324 Kw/m² No
9 Actuador de inclinación del panel fotovoltaico DO - - SI
10 Sensor de temperatura (Panel fotovoltaico) AI -20 - 60 °C No
11 Sensor de tensión del banco de baterías del panel
fotovoltaico AI 0 - 24 V No
12 Sensor de potencia generada (Panel fotovoltaico) AI 0 - 260 W No
13 Sensor de corriente consumida (Panel fotovoltaico) AI 0 - 100 A No
4 Punto de partida del desarrollo propuesto
En este apartado estudiaremos más a fondo la forma de obtención de los datos. A su vez,
coincide con la primera etapa de desarrollo del sistema. Principalmente nos centraremos en el
Servidor Mara o Mara Server - el cual es un servidor que ha sido tomado de un proyecto de
investigación anterior, ya que queda fuera del alcance de esta tesis -, que ha sido
implementado sobre Arduino y compatibles y ha sido utilizado para poder recabar los datos
tomados por los diferentes dispositivos de sensado y medición.
Mara server reúne un conjunto de funcionalidades básicas:
● Recoge sistemáticamente datos de distintas variables de campo en una modalidad
Round Robin28
con un periodo de tiempo configurable, es decir que trabaja con el
concepto de quantum o intervalo de tiempo. A cada dispositivo se le asigna un
periodo de ejecución para poder transmitir o recibir información mediante el canal de
comunicación. A su vez se va dejando una tabla de estados actualizada a efectos de
responder a los requerimientos de los clientes o efectuar publicaciones a Brokers
sobre la base del Protocolo de Aplicación Mara1-v4.
28
https://es.wikipedia.org/wiki/Planificaci%C3%B3n_Round-robin
pág. 108
● Admite conexión física de múltiples formas por parte de clientes. Entre las cuales se
destacan como Servidor de datos o como Publicador/Suscriptor.
● Efectúa un proceso que reúne características de multitarea colaborativa en su Loop
principal. El loop principal no es bloqueante y dependiendo del procesador y su reloj,
la rutina Loop() se ejecuta en el orden de 100 mil veces/seg.
● Posee sincronización global desde un servidor de tiempo en Broadcast (Mara)
específico o por NTP29
.
Las funcionalidades enunciadas, se situaron en una única aplicación sobre un hardware,
denominado CoMaster. Su nombre proviene de la conjunción de sus dos funciones
principales como son, por un lado, la de ser Concentrador (gateway) de estados y mediciones
de campo para su comunicación a Internet, intercambiando capa física y el protocolo de
adquisición en la red local del campo, al normalizado para funcionar en Internet (TCP/IP).
Por otro lado, la función de Master (Unidad Maestra) de adquisición de las unidades en la red
local, situadas en distintos dispositivos, como los sensores mencionados anteriormente, que
permiten la extracción de sus datos con su modalidad específica.
La red local pueden ser en realidad un conjunto de subredes trabajando en protocolos Serie
RS-485, UTP, I²C u otras.
En síntesis, el CoMaster es un hardware que contiene los dispositivos de conectividad hacia
Internet, que permiten la adquisición y concentración de datos dispuestos en las borneras
frontera del campo y de los que provienen de las subredes locales.
También se debe definir un Centro de Control (CC), que contiene una Aplicación Cliente
(Poll) que efectúa conexión automática con cada CoMaster a efectos de recabar las tramas de
datos de campo o, en comunicación indirecta a través de publicaciones del CoMaster;
mediante un Broker de mensajes se alimenta al CC en un modo suscriptor. En este CC,
normalmente reside la Base de Datos (BDD), que mantienen la información de tiempo real e
histórica del sistema y el Servidor WEB (WS). En comunicación Indirecta, el CC puede
contener el Broker y alimentar las distintas Apps para presentación de los datos.
Entonces la aplicación consiste en un software desarrollado en Arduino, que es esencialmente
el ciclo principal Loop(), el que reúne características de multitarea colaborativa. Como ya se
mencionara, la preponderancia de su función CoMaster, está motivada porque se trata de un
dispositivo que funciona en varias capas o módulos:
● Como IED o UC local: Adquiere en un loop regular de scan, los valores de estado y
medidas que se dispongan en la bornera frontera con el campo.
● Como Master: Dentro del ciclo de adquisición, se envían mensajes en modo
HalfDuplex30
, a la red RS-48531
o UDP conformada por los IEDs situados en distintos
dispositivos transductores que admitan los protocolos.
29
https://es.wikipedia.org/wiki/Network_Time_Protocol
pág. 109
● Como Publicador: Dentro del loop principal se prevé la publicación de datos de
estado y eventos, ya sea en un modo sistemático regulado por una temporización o en
un modo de excepción ante ocurrencia de eventos.
● Como Concentrador: La información recabada, como se especificó arriba, es
dispuesta en distintas tablas de datos según su tipo:
○ Variables de estado del sistema (VarSys): Son aquellas que indican el
estado de comunicaciones, sincronización y otras de cada uno de los IEDs
(tanto del IED local como los situados en el campo en las subredes).
○ Variables digitales de entrada: Son aquellas que indican el estado de los
dispositivos de campo con entrada directa a pines específicos del CoMaster.
○ Variables analógicas de entrada: Valores de mediciones (por ejemplo:
presión atmosférica, temperatura, tensión, corriente y potencia eléctricas) con
entrada directa a pines específicos del CoMaster.
○ Eventos de campo y comunicaciones: Con discriminación de 1/32 de
segundo.
● Como Puente: Entre el Centro de Control y Adquisición y los IEDs de campo (para
diagnóstico y/o configuración a distancia).
En su función como master, la aplicación emite cíclicamente y en modo round-robin un
pooling a cada uno de los IEDs que se definen en su tabla de configuración. Esta consulta se
efectúa típicamente cada 500 ms, teniendo en cuenta un compromiso entre la velocidad de la
red, el máximo tamaño de un paquete y otras consideraciones de ruido de ambiente. Teniendo
en cuenta la existencia típica de una docena de IEDs en las subredes locales, se tienen un
refresco de medición del orden de 6 segundos, lo cual se considera suficiente acorde a las
especificaciones estándar.
Existen otras funciones adicionales complementarias como son las de llevar un reloj de
tiempo real de buena precisión en base a un timer situado en el loop principal. Con un cristal
de 32768 Hz que le otorga una granularidad de 1/32768 seg pueden lograrse precisiones en
Time-Stamp de eventos de +/- 1 ms. Dicha función resulta indispensable para poder llevar
control del tiempo en que los datos son relevados, dado que muchos estudios estadísticas se
basan en la relación de variable-tiempo. Además permite conocer con mayor exactitud los
tiempos de ocurrencia de los diferentes eventos que puedan ocurrir.
Los receptores de una trama de datos enviada por el CoMaster (ya sea por
adquisición/respuesta o por publicación), deben hacer un parsing de la trama recibida
interpretando la misma en protocolo de aplicación MARA-1 v4. La lectura se efectúa hasta el
largo efectivo (lo hace leyendo Qty) de la trama. El CoMaster elabora trama completa desde
30
Transmite y recibe en ambas direcciones, pero sólo ocurre una transmisión a la vez, es decir, no hay comunicación bidireccional simultáneamente. 31
Sistema de bus diferencial multipunto, es ideal para transmitir a altas velocidades sobre largas
distancias (10 Mbit/s hasta 12 metros y 100 kbit/s en 1200 metros) y a través de canales ruidosos, ya que el par trenzado reduce los ruidos que se inducen en la línea de transmisión.
pág. 110
el SOF (Start of Frame) hasta los bytes que ofician de BCC (Block Check Character). Esta
trama se encapsula luego en TCP/IP y es enviado al Broker que posee una dirección IP
conocida y fijada en una tabla del CoMaster. Pueden existir varios CoMasters en una red
LAN/WAN manteniendo abierto un Server Socket de modo que el CC abre tantas conexiones
cliente persistentes, como CoMasters existan en la red. El CoMaster también es responsable
de establecer la conexión como cliente al Broker en caso de comunicación indirecta. En
ambas situaciones: funcionando tanto como Servidor y como Cliente para las distintas
modalidades de comunicación, pueden mantenerse en forma concurrente simplemente fijando
las modalidades en la tabla de configuración del CoMaster. El tratamiento sobre el lado
TCP/IP desde el punto de vista de la fragmentación de paquetes, queda librado al
funcionamiento que establece el fabricante para el Stack TCP del hardware compatible con
Arduino, sin mayores previsiones que las que se establecen por defecto.
Sobre el lado de la red local multipunto, especialmente en la red serie RS-485, la situación no
es la misma, pues allí es crucial el envío “atómico” del paquete. Esto adquiere mayor
relevancia con la necesidad de que cada paquete tenga un tiempo de envío lo suficientemente
constante y predecible en la emisión de la PeH (Puesta en Hora) en Broadcast. Para cumplir
esta funcionalidad, el CoMaster periódicamente (típicamente entre 10 y 20 segundos) emite
un paquete de PeH. Ese paquete es emitido en broadcast y para asegurar el éxito de llegada a
todos los IEDs de la subred, el canal RS-485 debe silenciarse. Para ello, el Concentrador
asume un tiempo de silenciamiento del canal que en las pruebas se lo fijó en 500 ms. Ahora
bien, al suspender con este mecanismo las consultas a la red multipunto, se debe garantizar
que la eventual consulta que estuviere en tránsito, se resuelva en un tiempo menor a 500 ms.
El tiempo máximo aproximado se obtiene como las suma de los tiempos de transmisión de
los bytes de la consulta y su respuesta respectiva en el caso peor. Por ejemplo en 9600 bps,
para un total de 250 bytes como peor condición, el periodo de silenciamiento debiera ser de
alrededor de 250 ms. Como puede observarse, existe una relación de compromiso para el
tiempo asignado a la PeH, que le quita eficiencia al canal por encima de la ya comprometida
situación que se tiene con un canal Half-Duplex y de baja velocidad. Se debe entonces tener
en cuenta la velocidad, la frecuencia con que se emite la PeH y el largo máximo de los
paquetes esperables en la red, sumando la consulta y su respectiva respuesta para evaluar la
eficiencia. Emitida la PeH, luego del periodo de silenciamiento, el CoMaster reanuda la
consulta en round-robin de los IEDs, hasta una nueva PeH y así sucesivamente.
4.1 Funcionalidades del Software
El código fuente del CoMaster es un programa con una etapa preliminar de inicialización de
variables y dispositivos, con un bucle principal infinito, característica de los sistemas
dedicados. Para las comunicaciones sobre Ethernet se utiliza la pila TCP/IP la cual es libre y
de código abierto, desarrollada por los fabricantes que dan compatibilidad a Arduino. Esta
pila brinda una API de alto nivel que cubre las funciones básicas de comunicación, como la
creación y uso de sockets.
pág. 111
Para las comunicaciones sobre la red RS-485 se utiliza el protocolo MARA-1 v4. Este
protocolo posee un variado set de funciones o comandos para funciones genéricas de
comunicación y a su vez permite crear libremente otros específicos.
Como el CoMaster tiene que cumplir con varias funciones y para cumplirlas debe atender a
varias tareas, por lo general independientes entre sí, es que se requirió de una estructura
adecuada para el software y se optó por utilizar una técnica de programación denominada de
multitareas colaborativas. Por lo tanto, la estructura de software del CoMaster es en
esencia, la de un programa en C, con un único hilo de ejecución, que invoca secuencialmente
las diferentes tareas (colaborativas) en un ciclo infinito. Las tareas colaboran con un fin
común resolviendo su trabajo en un tiempo apropiado (no demasiado extenso). De esta forma
se asegura que todas las tareas tendrán oportunidad de ejecutarse y que no habrá situaciones
de bloqueo.
4.2 Componentes Hardware
Para nuestro caso de simulación hemos hecho uso de una placa WEMOS D1, la cual contiene
una placa Wifi que nos brinda una mayor facilidad de comunicación con el resto de los
elementos del sistema. La misma está gobernada por un ESP8266 que se encarga de las tareas
de procesamiento y del control de Wifi.
Las características principales de esta placa son:
● 11 entradas / salidas digitales.
● 1 entrada analógica.
● Conector micro USB.
● Distribución de pines tipo Arduino UNO.
Una de las ventajas de esta placa es que se programa utilizando el IDE de Arduino en
lenguaje C y C++. Por lo tanto, podemos aprovechar el código realizado para Arduino y
llevarlo a esta tarjeta de manera muy sencilla. De hecho, un buen número de librerías
diseñadas para tarjetas Arduino basadas en AVR ya han sido actualizadas para soportar
tarjetas basadas en el ESP8266 como la WEMOS D1.
5 Manejo de datos
Habiendo definido las distintas variables y métodos de relevamiento, procederemos a ampliar
la forma de comunicación de los datos, desde que son recolectados por las placas, hasta su
llegada a los correspondientes destinos. En concreto, hablaremos del protocolo MQTT, el
cual es el elegido de entre los protocolos mencionados en capítulos anteriores de este trabajo,
del broker utilizado y del manejo y visualización de los datos.
Se pueden contemplar otras formas de comunicación, como HTTP, pero no son tan rápidos,
ni ligeros como MQTT. Dado que el consumo energético es un factor importante en nuestro
proyecto y que las condiciones del lugar geográfico en donde se encuentran son
pág. 112
desfavorables, en relación a ancho de banda, hacen que MQTT sea uno de los que mejor se
adapte a estas situaciones.
Como se mencionó, MQTT es un protocolo de comunicaciones dispositivo-a-dispositivo. Su
objetivo es ofrecer una plataforma de comunicación ligera basada en publicación/suscripción.
Esto permite que dispositivos de muy poca potencia o con ancho de banda mínimo puedan
comunicarse de manera rápida y ligera. Para el funcionamiento del sistema, es necesario la
existencia de un broker. Los mensajes publicados a través de MQTT están compuestos por
dos partes principales: Tópico (o Tema) y Mensaje.
El broker es el software encargado de hacer llegar a los clientes los mensajes de los tópicos a
los que se han suscrito. Una vez establecida la conexión con el broker, es posible publicar o
suscribirse a los distintos tópicos disponibles. Por ello, para poder recibir las publicaciones
deseadas, se ha de conocer el Tema con el que van a marcarse los mensajes asociados.
Para el diseño de nuestro sistema hemos establecidos los siguientes Tópicos, basados en el
conjunto de variables descritas:
Referencias:
● C[0-9]+: Comuna identificada por Id.
● Ag[0-9]+: Aerogenerador identificado por Id dentro de una comuna.
● Ps[0-9]+: Panel solar identificado por Id dentro de una comuna.
● C: Variables de índole climático.
● P: Variables de índole energético.
● Ef: Evento de freno eléctrico del aerogenerador.
● Ei: Evento de inclinación del panel.
● T: Variable de temperatura.
● Vm: Variable de velocidad del viento.
● Dv: Variable de dirección del viento.
● Vbb: Variable de tensión del banco de baterías.
● Pg: Variable de potencia generada.
● Ac: Variable de corriente consumida.
● Rs: Variable de radiación solar.
pág. 113
Este esquema posibilita poder seguir incorporando nuevos equipos de generación, como
también la posibilidad de seguir agregando diferentes tipos de sensores y actuadores. Además
brinda la posibilidad de aplicar diversos filtros que permitan que los suscriptores, por
ejemplo, solo reciban datos de determinados sensores.
Como se estipulo en secciones anteriores, la plataforma web será la que reciba la información
publicada por las placas, para ello es necesario que la misma se suscriba a todos los tópicos,
es decir, que debe suscribirse al nodo raíz del árbol de tópicos. A su vez la aplicación web
hace uso de un esquema de tópicos más reducido, en el cual se agrupan varios de los temas,
en tópicos más abarcativos. A continuación se presenta una descripción de los tópicos
utilizados por la aplicación:
● /aerogenerador/clima: Este tópico es el establecido para el envío de los datos
relevados por los sensores instalados en la torre del aerogenerador de baja potencia,
referentes al clima (velocidad de viento, presión atmosférica, etc.).
● /aerogenerador/energia: Este tópico corresponde a los datos relacionados a la
energía (potencia) producida por el aerogenerador, y al estado de carga del banco de
baterías (tensión) y de la corriente consumida por la comuna.
● /fotovoltaica/clima: Correspondiente a aquellos datos de índole climático, relevados
por los sensores en el panel fotovoltaico y solar (radiación solar, inclinación y
temperatura).
● /fotovoltaica/energia: Este tema es análogo al tópico del “aerogenerador/energia”
pero referente a la energía producida y consumida por los paneles.
Si bien se pueden implementar filtros más específicos, como se comentó anteriormente, se
considera que para un sistema dedicado a la monitorización de aldeas rurales, no tiene mayor
relevancia establecer un abanico más amplio de filtros. Aunque esto no implica que no se
puedan establecer en futuras versiones de esta plataforma.
A continuación presentamos la tabla de variables utilizadas en la simulación, descriptas en el
capítulo anterior, con sus respectivos tópicos asociados:
pág. 114
# Variable Tipo Excursión Unidad Alarma Tópico TAG Dir
1 Sensor de velocidad media de viento AI 0 - 100 m/s No Ci/Agi/C/Vm /aerogenerador/clima 14
2 Actuador de conexión de resistencias de
embalamiento DO 0-1 - Si Ci/Agi/Ef /aerogenerador/clima 2
3 Sensor de dirección del viento AI 0 - 360 ° No Ci/Agi/C/Dv /aerogenerador/clima 15
4 Sensor de temperatura (Torre del
aerogenerador) AI -20 - +60 °C No Ci/Agi/C/T /aerogenerador/clima 16
5 Sensor de tensión del banco de baterías del
aerogenerador AI 0 - +60 V Si Ci/Agi/P/Vbb /aerogenerador/energia 17
6 Sensor de potencia generada (Aerogenerador) AI 0 - 1000 W No Ci/Agi/P/Pg /aerogenerador/energia
7 Sensor de corriente consumida
(Aerogenerador) AI 0 - 100 A No Ci/Agi/P/Ac /aerogenerador/energia 18
8 Sensor de radiación solar (Panel fotovoltaico) AI 0 - 324 Kw/m² No Ci/Psi/C/Rs /fotovoltaica/clima 19
9 Actuador de inclinación del panel fotovoltaico DO 0-1-2-3 - SI Ci/Psi/Ei /fotovoltaica/clima 3
10 Sensor de temperatura (Panel fotovoltaico) AI -20 - +60 °C No Ci/Psi/C/T /fotovoltaica/clima 20
11 Sensor de tensión del banco de baterías del
panel fotovoltaico AI 0 - +60 V Si Ci/Psi/P/Vbb /fotovoltaica/energia 21
12 Sensor de potencia generada (Panel
fotovoltaico) AI 0 - +260 W No Ci/Psi/P/Pg /fotovoltaica/energia 22
13 Sensor de corriente consumida (Panel
fotovoltaico) AI 0 - +100 A No Ci/Psi/P/Ac /fotovoltaica/energia 23
pág. 115
5.1 Broker
Como se mencionó antes, el broker es el encargado de redirigir las diferentes publicaciones a
sus correspondientes suscriptores, en nuestro caso a una aplicación web. La forma de
conexión a un broker consiste simplemente en conocer en qué dirección y puerto está
escuchando y solicitar una conexión para empezar a publicar en un tópico y/o suscribirse a él;
considerando que no requiera de autenticación de usuarios, de lo contrario se deberán
proporcionar las credenciales correspondientes. Para este trabajo se experimentó con dos
tipos de broker:
● Mosca: Este broker de código libre escrito en JavaScript, basado en NodeJS, permite
la creación de un broker como servidor unitario (standalone) o como parte de una
aplicación más grande. Este broker ofrece una gran comodidad para visualización de
mensajes aunque es recomendable añadir una herramienta llamada ‘bunyan’ para
observar los mensajes de depuración; este módulo, en unión con mosca, permite
observar toda la información de paso de mensajes con un código de colores asociado
para facilitar su lectura. Mosca puede ser protegido con usuario y contraseña, también
es posible cambiar los puertos de escucha y no tiene soporte para MQTT QOS 2.
● Mosquitto: Este broker es una aplicación de código libre desarrollada por el proyecto
Eclipse, está escrito en C y puede compilarse para ejecutarse en dispositivos muy
pequeños. Su instalación en linux es muy simple dado que el propio gestor de
paquetes lo tiene incorporado sin embargo, para poder utilizarlo en nuestro sistema, se
requirió instalar un complemento adicional que contiene las librerías de desarrollo
incorporadas en el módulo de ‘libmosquitto-dev’. A diferencia del anterior, Mosquitto
si posee soporte para MQTT QOS 2.
Luego de varias pruebas se optó por utilizar Mosquitto, dado que ofrece mayores
características y capacidades que Mosca32
. Además el hecho de que no sea necesario
incorporar la funcionalidad del broker en nuestra aplicación web, facilitó la elección del
mismo. Como punto adicional, cabe destacar que la instalación y configuración de Mosca
como servicio MQTT requiere de una mayor cantidad de procedimientos y librerías que
Mosquitto.
El broker es una de las piezas principales del sistema ya que sin MQTT no tendríamos una
forma eficiente de comunicación. Se constata a su vez la sencillez con la que se puede
instalar el sistema y tenerlo funcionando de forma instantánea. El broker utilizado escucha
por el puerto por defecto, el 1883 y no está configurado para el manejo de autenticación de
usuarios. Sin embargo es posible implementarlo, como mejora para una versión futura, dado
que Mosquitto posee soporte para su manejo. En caso de querer hacer uso de su
implementación solo basta con incorporar la opción de allow_anonymous en false dentro de
nuestro archivo de configuración de Mosquitto y crear un usuario y contraseña para cada
cliente o grupo de clientes. Una vez hecho esto, tanto los publicadores como los suscriptores
32
https://github.com/mqtt/mqtt.github.io/wiki/server-support
pág. 116
deberán presentar las credenciales correspondientes para establecer la conexión con el broker,
brindando una capa más de seguridad.
5.2 Plataforma Web
Como último punto a tratar, procederemos a describir la aplicación encargada de la
visualización del contenido relevado por los sensores a través de una interfaz web. La
aplicación web será el suscriptor de nuestro sistema, es decir, será la que se suscriba a todos
los Tópicos establecidos. En pocas palabras la aplicación se suscribirá al broker para poder
recibir los datos publicados por las placas.
La aplicación web está programada en NodeJS, utilizando el framework Express, para la
parte del back-end. Para la conexión con el broker se utilizó la librería desarrollada en
JavaScript MQTT.js33
, la cual proporciona el módulo cliente para el protocolo MQTT.
Mediante ella se creó un módulo especial, que permite conectar, suscribir y recibir los
mensajes del broker.
Para lograr una interacción más dinámica y fluida con el cliente, se utilizó la tecnología de
WebSockets. Los WebSockets proporcionan un canal de comunicación bidireccional y full-
duplex, es decir, son capaces de mantener una comunicación bidireccional, enviando y
recibiendo mensajes de forma simultánea sobre un único socket TCP. Esto nos posibilita
establecer una conexión continua entre el cliente y el servidor. La API de WebSocket está
disponible para JavaScript cuyo alcance DOM sea un objeto Window o cualquier objeto
implementando WorkerUtils. Las comunicaciones se realizan a través de los mismos puertos
que utiliza HTTP con el fin de ofrecer compatibilidad con el software HTTP del lado del
servidor ya existente. El protocolo se divide en dos partes: la negociación y la transferencia
de datos. Como este coexiste con HTTP, la primera comunicación debe realizarse
necesariamente a través de una petición HTTP. Por ello, la negociación de apertura comienza
con una petición upgrade por parte del cliente y, si no ocurre ningún error, el servidor
responde con un estado 101 (switching protocols). Una vez que el cliente y el servidor han
cumplido con su parte de la negociación, y únicamente si no ha ocurrido ningún error,
comienza la transferencia de información. A partir de ese momento cada parte puede enviar
información sin depender de la otra, lo cual es imposible de hacer con HTTP, AJAX, las
tecnologías push en general o técnicas más específicas como long polling. En la siguiente
figura, podemos apreciar el proceso de intercambio de mensajes.
33
https://www.npmjs.com/package/mqtt
pág. 117
De esta forma cuando un cliente solicita visualizar la información, se establece un canal de
comunicación persistente entre el cliente (en este caso el browser) y el servidor (nuestra
aplicación), de tal forma que cuando el servidor recibe información actualizada por parte del
broker, éste puede comunicar por el canal los cambios y, sin necesidad de tener que recargar
nuevamente la página (front-end de nuestra aplicación), el cliente puede mostrar de manera
inmediata la actualización.
Por otro lado, al estar basado en HTTP, es posible implementar una capa de seguridad
(utilizando HTTPS) sin utilizar puertos extraños (aunque es posible, pero se puede utilizar el
mismo puerto 80) y sin necesidad de enviar demasiada información adicional ya que la
negociación y petición se hace sólo una vez al principio o cuando ocurra una desconexión y
reconexión, que puede ser cada varios minutos, en caso de producirse. Esto se podría
implementar como una mejora en futuras versiones.
5.3 Persistencia de los datos
Ya habiendo explicado el funcionamiento del sistema, en este apartado nos centraremos en la
descripción del mecanismo de almacenamiento de datos. El objetivo es disponer de un
conjunto de datos históricos que se puedan utilizar para diferentes estudios de índole
meteorológicos y energéticos por diferentes tipos de profesionales.
pág. 118
Antes de establecer el tipo de base de datos a utilizar, se definió el lugar dentro del sistema en
donde se alojan los datos. El almacenamiento podría haber sido en una de las tres partes
principales que lo componen:
1. En la primera parte del sistema no es conveniente, ya que no tendría sentido que las
placas almacenen los datos crudos sin ser tratados. Además el consumo de la placa
aumentaría sustancialmente, haciendo que el sistema consumiese más de lo debido.
La razón principal para no utilizarlo en esta instancia, fue por el hecho de que esta
parte del sistema es la que se replica para poder monitorizar cuantos dispositivos
queramos.
2. La parte del sistema que contiene el broker es una buena opción para ser el encargado
del almacenamiento de los datos. El broker tiene la capacidad de persistencia a
múltiples bases de datos, el problema de esta alternativa se encontraba en la limpieza
de los datos, es decir, el broker recibe más mensajes de los que se desea resguardar,
desde los keepalive hasta los mensajes de envío. Éstos aumentan en gran cantidad el
número de mensajes almacenados, dificultando futuras búsquedas en caso de
presentarse problemas. Además se limitaría el sistema al almacenamiento de datos
crudos, dejando de lado datos calculados que puedan surgir a partir de los primeros.
3. Por último, la aplicación para el muestreo de datos fue la opción con las mejores
prestaciones para el resguardo de los datos recopilados por los sensores, dado que
permite disponer de datos estructurados, disponibilidad para el uso de múltiples y
diferentes tipos de bases de datos y no genera aumentos en el consumo del sistema.
Además es el principal punto de convergencia de los diferentes datos relevados a
mostrar al usuario.
Una vez definido que la aplicación para el muestreo de datos iba a ser la encargada del
almacenamiento en la base de datos, se estudió y evaluó diferentes tipos de bases de datos
con el fin de determinar la que mejor se adapte a las necesidades del sistema. Dado que el
software hace uso, en gran parte, del formato JSON para el manejo de datos, se optó por
MongoDB ya que es la que mejor se adapta a este tipo de formato.
MongoDB es una base de datos documental, esto significa que todas las entradas se
almacenan en documentos, en este caso en formato JSON. Además es una base de datos
basada en colecciones, cada una de ellas almacena datos que normalmente tienen una relación
entre ellos como las tablas de una base de datos relacional.
Otra de las características importantes que ofrece MongoDB es la de no necesitar un esquema
previo. Esto permite poder introducir en una misma colección, datos que aun estando
relacionados tengan diferentes campos entre ellos.
Para nuestro sistema, ofrece la posibilidad de modificar el formato de datos recibidos sin
necesidad de preocuparnos por alterar la base de datos.
En nuestro sistema hemos utilizado diferentes colecciones, primeramente se estableció el
esquema de datos de las comunas, en la cual se registran algunos datos básicos como:
pág. 119
nombre, localidad, departamento, cantidad de pobladores, responsable a cargo, etc., y los
datos de georeferenciamiento, latitud y longitud respectivamente, los cuales nos permitirán
poder georreferenciar a las comunas en un mapa web. Luego se procedió con la definición del
esquema de los equipos generadores, en donde se registra, el tipo de equipo (aerogenerador o
panel fotovoltaico), la comuna a la que pertenece y un arreglo de características técnicas de
dicho equipo (potencia nominal, dimensiones, fabricante, modelo, etc.). De esta forma es
posible seguir incorporando nuevas características a los equipos (en caso de ser necesario),
con un mínimo de modificaciones.
Finalmente para el resguardo de los datos recibidos por el broker se estableció una colección
en la cual se almacenan las diferentes variables, en la cual se resguarda: el valor tomado, la
unidad del valor, el tópico del cual fue publicado, la marca de tiempo en el que fue relevado
por las placas, el equipo generador del cual fue tomado, el tipo de variable (temperatura,
velocidad, radiación, tensión, etc.) y la etiqueta o TAG al que pertenece dentro de la
plataforma (tópico interno de la aplicación web).
pág. 120
CAPÍTULO 8:
VISUALIZACIÓN DE DATOS
1 Introducción
En este capítulo se explica la visualización de los datos obtenidos de las placas (WEMOS
D1) que se reciben a través del broker. También se explican las diferentes formas estudiadas
para el muestreo de los datos y las diferentes posturas utilizadas para la elección utilizada.
2 Herramientas aplicables y sus características
Con el fin de mostrar los datos debemos saber exactamente los requisitos necesarios para que
la interfaz funcione correctamente. Dichos requisitos que necesitamos que cumpla la interfaz
son los siguientes:
● En principio es una interfaz que permita de manera cómoda la recepción de los datos
en tiempo real. Los datos que recibiría serían los recogidos por las placas WEMOS
D1. Toda página web puede ser codificada para que reciba datos en tiempo real pero
requiere un desarrollo específico adaptado a la aplicación.
● Otro de los requisitos, es que proporcione una visualización rápida y fácil de
interpretar por parte de los usuarios. Esto es de suma importancia, ya que afectaría el
tiempo de respuesta por parte de los usuarios, en caso de ocurrencia de algún evento o
valores anómalos.
● Otros de los requisitos en nuestra aplicación es la seguridad. Es conveniente proteger
el acceso a la aplicación a través de la creación de un usuario y contraseña y, a su vez,
mediante perfiles de usuarios; en nuestro caso, se identifican dos perfiles:
administrador, que es quien puede dar de alta equipos generadores y editar sus datos,
y perfil usuario que sólo puede suscribirse a los distintos tópicos y ver la información
relacionada. Es por ello que la plataforma provee mecanismos de registro y
autenticación.
Con los requisitos bien especificados, se realizó una búsqueda de aplicaciones o elementos ya
desarrollados que los satisfagan. Se encontraron aplicaciones que permiten armar de manera
rápida paneles de visualización destinados a IoT, como por ejemplo Emoncms34
, Graphene35
y Freeboard36
. Estas aplicaciones presentan diferentes capacidades y están desarrolladas en
distintas tecnologías. Ahora procederemos a hacer una mención de estas herramientas y de su
proceso de selección.
34
https://emoncms.org 35
http://jondot.github.io/graphene/ 36
https://freeboard.io/
pág. 121
A partir de ahora nos referiremos a la aplicación de muestreo de datos como Dashboard
(Panel de instrumentos). Los diferentes dashboards que nos encontramos en Internet
presentan una serie de capacidades comunes, como la visualización de datos en tiempo real.
2.1 Graphene
Este Dashboard desarrollado por jondot37
está codificado en Ruby. La plataforma tiene
potencial ya que Ruby permite una gran variedad de mejoras en todos los campos web. El
mayor problema que presenta es la necesidad de tener un gran conocimiento de Ruby,
sumado a la falta de tiempo, de soporte, y que no existe una comunidad detrás de este
proyecto. Finalmente, luego de realizar pruebas con esta tecnología, se optó por descartar esta
opción.
2.2 Emoncms
Este dashboard pertenece a Emon, una empresa que tiene por objetivo crear una plataforma
propietaria que permita monitorizar toda la información de los sensores que uno puede
colocar en una casa. La empresa proporciona todo lo necesario para la creación del sistema,
ya sea Hardware o Software. Toda la información que los diferentes elementos generan son
redirigidos a Emoncms Dashboard.
Este dashboard nos permite la creación de diferentes formas de representación de datos.
Posee una muy buena reputación de representación de datos relacionados con consumo
energético. Permite la creación de plugins personalizados, para ello utilizamos PahoMQTT
que es una librería que ofrece un cliente MQTT a través de WebSockets. Éste conectado a
Emoncms, permite la suscripción del dashboard a los Temas deseados.
Con este dashboard se realizaron algunas pruebas para comprobar su adaptabilidad en nuestro
sistema, sin embargo no alcanzó nuestros estándares; si bien el sistema es funcional, generaba
una serie de problemas como pérdida de algunos datos en tiempo real.
Otro de los grandes problemas que vimos fue que la comunidad que daba soporte a este
dashboard estaba completamente centrada en los dispositivos de Emon y esto generaba una
gran dificultad a la hora de solucionar problemas de compatibilidad con sistemas externos,
como lo es la WEMOS D1.
Además este sistema presenta vulnerabilidades de seguridad, dado que no ofrece ninguna
forma de protección del dashboard en sí ni de los flujos de datos entrantes.
2.3 Freeboard
Este dashboard desarrollado en JavaScript ofrece una plataforma de muestreo de datos en
código libre y a su vez permite acceder a través de su página web para que sea accesible a
través de Internet. Este dashboard acepta la creación de nuevos plugins con los que permite
37
https://github.com/jondot
pág. 122
mejorar la forma de muestreo de datos o la forma de recibirlos. Lo único que no ofrece es la
creación de usuarios y la protección del dashboard completo.
Además de poder acceder a esta plataforma por medio de su página web, también es posible
clonar dicho proyecto para poder hacer pruebas locales. Durante la realización de las pruebas
comprobamos un gran retardo entre el envío de los datos desde el broker y su recepción en
Freeborad.
Otro problema que presenta es que cualquier persona con acceso al dashboard puede acceder
al panel de configuración, y como consecuencia podrían borrarse las entradas y sería
necesario volver a configurarlas.
2.4 Tecnología elegida para el muestreo de datos
Si bien los dashboard descritos, proporcionan una forma rápida y sencilla de disponer de un
panel de muestreo de datos, éstos resultan insuficientes para los objetivos de este trabajo, ya
que sólo nos permitían la visualización en tiempo real, dejando de lado el resguardo de datos
y consultas de históricos. Es por ello que se decidió desarrollar nuestro propio dashboard, en
dónde no sólo permita la visualización de datos en tiempo real sino también que incorpore el
resto de las funcionalidades mencionadas. Otro aspecto importante que consideramos, es la
posibilidad de registrar los datos técnicos de los equipos de generación, de forma que se
puedan contrastar los valores registrados por las placas con las especificaciones de dichos
equipos.
Para la elaboración de nuestro dashboard, principalmente para el diseño de los medidores
(Gauges), hemos hecho uso de la librería Highcharts38
escrita en JavaScript. Ésta presenta un
enorme abanico de diferentes tipos de gauges y gráficos que podemos utilizar.
Para cada gauge utilizado se creó un archivo JavaScript que contiene una colección de
elementos de configuración que son los que nos permiten definirlo. Esto abarca desde el
tamaño, color, valores de inicialización, rangos de valores soportados, etc. De esta forma
cuando se renderiza la vista del dashboard, se pasan aquellos gauges a utilizar. Cabe destacar
que dependiendo el tipo de dispositivo a visualizar, los gauges utilizados varían,
especialmente en la sección de datos climáticos.
El dashboard implementado consta de cuatro pestañas: la primera se corresponde con las
características técnicas del dispositivo de generación a visualizar y del banco de baterías
instalado, también incluye información de los sensores instalados y de sus unidades de
medidas. En la siguiente imagen podemos apreciar los datos correspondientes a un
aerogenerador de 1000 W:
38
https://www.highcharts.com/
pág. 123
El objetivo es poder contar con los datos técnicos del equipo, para poseer un punto de
referencia a la hora de visualizar los datos, como también conocer el tipo de generador que se
encuentra instalado.
La segunda es la vista de tiempo real, donde se pueden visualizar los distintos gauges,
agrupados de acuerdo a la clasificación planteada anteriormente a lo largo de este trabajo
(datos climáticos y energéticos). Aquí se pueden observar los últimos datos relevados por las
placas, es decir se ven en tiempo real los valores tomados. También es en esta pestaña donde
se realiza la conexión por WebSocket, de modo que se puedan transmitir los nuevos valores,
en caso de que estos cambien. En la siguiente captura podemos observar los gauges
correspondientes a los sensores climáticos, instalados en aerogeneradores.
pág. 124
Para el caso de los paneles fotovoltaicos, se presentan los siguientes gauges:
Como se mencionó anteriormente, la inclinación que presenta el panel es un aspecto
importante a la hora de evaluar su rendimiento, ya que no es lo mismo un panel ajustado
siempre en la misma posición durante todo el año, que uno que se ajusta con los cambios de
estación; por esa razón junto al gauge de radiación se dispone de un indicador de inclinación
El mismo se ajusta cada vez que los servomotores ajustan el ángulo del panel, los cuales lo
hacen cuatro veces por año, una por cada cambio de estación.
La otra mitad de esta pestaña presenta los gauges correspondientes a los sensores para
medición de energía. Dado que no se presentan cambios significativos, tanto para los
aerogeneradores como para los paneles fotovoltaicos, se muestran los mismos medidores.
pág. 125
Aquí no solo podemos visualizar el consumo y la energía generada, sino que también
podemos ver el estado de carga del banco de baterías. Como este depende de las
características propias de las baterías, cantidad y tipo de conexión, la cantidad de energía que
pueden almacenar es variante. Por dicho motivo es que el gauge ubicado en la sección
inferior izquierda, se ajusta de acuerdo a las características mencionadas, mostrando el estado
de carga en valores porcentuales.
En la tercer pestaña se pueden realizar consultas de datos en un rango de tiempo, a su vez, se
puede visualizar el comportamiento de las variables en gráficos cartesianos que facilitan su
interpretación; el objetivo es que éstos datos puedan ser utilizados para estudios de
comportamiento climático y de rendimiento de los diferentes equipos instalados. En la
siguiente imagen se puede observar la vista del panel de históricos proporcionado para un
aerogenerador.
Se deben seleccionar las variables deseadas y establecer el rango de tiempo a consultar. Al
oprimir el botón “Mostrar” se obtendrán gráficos parecidos a los siguientes:
Grafica de Rosa de vientos.
pág. 126
Gráfico de Línea para muestreo de potencia y registro de eventos.
Dependiendo del tipo de variable a consultar, se generarán distintos tipos de gráficos que
permitan visualizar los datos de la manera más representativa.
Finalmente la cuarta pestaña proporciona un medio para obtener las credenciales y datos
necesarios para el uso de otros dashboards o plataformas de muestreo de datos. Este tema se
profundizará en detalle en la siguiente sección de este capítulo.
Se debe tener en cuenta que el panel descrito y las características mencionadas se
corresponden a un equipo de generación. Para cada equipo se carga un panel diferente que se
adapta a las características del mismo. Por ejemplo la diferencia mostrada entre los gauges de
variables climáticas entre paneles fotovoltaicos y aerogeneradores, cada equipo presenta sus
propias características y el dashboard responde a dichas características. Otro aspecto
importante que se debe considerar son los actuadores, los aerogeneradores y los paneles
fotovoltaicos presentan diferentes actuadores. En el caso de los paneles, se cuentan con
servomotores que ajustan su ángulo de inclinación para mejorar al máximo el
aprovechamiento de radiación solar con los cambios de estación. Estos cambios son
visualizados mediante el gauge de inclinación mostrado en párrafos anteriores. En cambio los
aerogeneradores cuentan con un mecanismo de freno de emergencia que se activa al registrar
velocidades de viento excesivas. Con el objetivo de proteger dicho equipo, el freno se activa
automáticamente cuando los sensores registran estos tipos de valores. Este tipo de evento
presenta un grado de importancia elevado, ya que mientras el freno este activado no se estará
generando energía para alimentar las baterías, provocando que con el tiempo se interrumpa el
pág. 127
suministro de energía. Este tipo de evento se puede apreciar tal como se muestra en la
siguiente captura:
Como se puede apreciar el gauge de potencia generada se desactiva y se prende un indicador
de color naranja en la parte superior del panel.
Dado que una comuna puede tener uno o más equipos de generación, se implementó un mapa
web que permite visualizar cada establecimiento registrado, los cuales se encuentran
georeferenciados. En la siguiente imagen podemos apreciar dicho mapa:
pág. 128
Al posicionarse sobre uno de estos puntos se desplegará una ventana modal, la cual
proporciona los datos del establecimiento, los equipos que tiene instalados actualmente y un
pequeño registro de últimos eventos ocurridos.
Es aquí donde se puede optar por el dispositivo de generación que se quiere observar. Luego,
dependiendo de los tópicos (propios de la plataforma) a los que esté suscripto el usuario,
podrá visualizar los datos correspondientes.
Un aspecto a resaltar es que ante la ocurrencia de algunos de los eventos mencionados, el
indicador de la comuna cambiara de color, dependiendo del tipo de evento ocurrido. Por
ejemplo en caso de activarse el freno del aerogenerador, el indicador de la comuna cambiara
a color naranja, indicando que ha ocurrido un tipo de evento de importancia elevada.
pág. 129
Mapa Web - Evento de freno activado.
Ventana modal del Mapa Web - Evento de freno activado.
pág. 130
En el caso de los paneles, dado que el evento de ajuste no representa un tipo de evento crítico,
el indicador de la comuna cambia a un color amarillo.
Mapa Web - Evento de ajuste del panel fotovoltaico.
Ventana modal del Mapa Web - Evento de ajuste del panel fotovoltaico.
pág. 131
2.5 Distintos tipos de accesos y visualización de la información
Como se analizó en el apartado anterior, se establecieron ciertas premisas que nuestro
dashboard debía satisfacer para nuestro sistema de control, durante su estudio se evaluaron
diferentes soluciones existentes en el mercado, estableciendo ventajas y desventajas de las
mismas. Dicho análisis, concluyó con la necesidad de desarrollar un dashboard propio que
satisfaga dicho requerimientos. Sin embargo esto no implica que los paneles de control vistos
u otros disponibles no puedan ser utilizados. Para ello y tomando en cuenta las características
de nuestro sistema (colaborativo), es que este brinda la posibilidad de poder hacer usos de
dichos dashboard, de forma tal de disponer de otros tipos y formas de visualización.
La plataforma desarrollada lleva a cabo la re-publicación de los datos recolectados y
procesados, de modo que los usuarios dispongan de otras alternativas para la visualización de
la información. De esta forma, se ofrece la posibilidad de utilizar otros dashboards web o
utilizar otros disponibles en otras plataformas, como el caso de Android. El objetivo es poder
ampliar el rango de uso de los datos a través de diversas plataformas que permitan configurar
un panel de muestreo de datos, como también proporcionar alternativas que permitan
adaptarse a las necesidades de diversos usuarios. Es aquí donde se puede apreciar con mayor
énfasis su vinculación con IoT, donde con una mínima intervención de los usuarios es posible
generar o recolectar datos mediante diferentes sensores instalados, publicarlos o compartirlos
por medio de Internet y que estos puedan ser consumidos por diferentes usuarios a través de
múltiples plataformas.
En el momento en que se establecen los equipos de generación en la plataforma,
automáticamente se realiza la configuración para que los datos recibidos sean nuevamente
publicados. Cabe resaltar que éstos datos son los que recolectan las placas y procesa la
plataforma, de modo que los usuarios reciben los datos preparados para su visualización. Si
bien, por defecto todos los datos son publicados nuevamente, es posible cambiar esta opción
mediante el panel de administrador, en el cual se brinda un detalle de los mismos, en qué
tópico publican y si se desea que éstos sean publicados o no. Esto lo podemos apreciar en la
siguiente captura:
pág. 132
Panel de características de un equipo aerogenerador (Vista solo para administradores).
Los tópicos utilizados para re-publicar los datos son diferentes a los usados internamente por
el sistema. Los mismos son establecidos de forma automática por la plataforma, basándose en
las comunas, los generadores y el tipo de dato que se esté trabajando. Dichos tópicos pueden
ser visualizados desde la plataforma, tanto desde el panel administrador (solo para usuarios
administradores), como también a través del dashboard desarrollado (todo tipo de usuarios).
A continuación podemos observar el esquema de tópicos que utiliza el sistema para la re-
publicación de datos:
pág. 133
Referencias:
● C[0-9]+: Comuna identificada por Id.
● Ag[0-9]+: Aerogenerador identificado por Id dentro de una comuna.
● Ps[0-9]+: Panel solar identificado por Id dentro de una comuna.
● velocidad: Variable de velocidad del viento.
● direccionViento: Variable de dirección del viento.
● temperatura: Variable de temperatura.
● tensionBaterias: Variable de tensión del banco de baterías.
● energiaGenerada: Variable de potencia generada.
● consumo: Variable de potencia consumida (Watt).
De esta forma y conociendo los respectivos tópicos, cualquier usuario puede configurar un
dashboard y elegir el medio de visualización que más se adapte a sus necesidades e intereses.
Con el fin de experimentar con diferentes plataformas se probaron diferentes dashboards para
Android disponibles en el mercado. Algunos ejemplos que podemos encontrar en la tienda (o
Play Store) de Google:
● MQTTDash.
● IoT MQTT Dashboard.
● IoT MQTT Panel.
● MyMQTT.
● MQTT Snooper.
Estos se pueden descargar de manera gratuita e instalar en cualquier dispositivo Android
compatible (celulares, Tablet, etc.). Si bien no ahondaremos en detalles de cada uno, ya que
son relativamente sencillos de configurar y utilizar, si nos centraremos en las características
que estos presentan. Primeramente todos hacen uso del protocolo MQTT, lo que va a permitir
que se conecten a nuestro Broker y puedan recibir la información. Para ello, una vez instalado
el dashboard deseado, es necesario realizar las configuraciones de conexión las cuales
consisten en establecer la dirección del Broker, su puerto de escucha y si requiere
autenticación por usuario/contraseña. Como mencionamos en el capítulo anterior, en la
sección de “Manejo de Datos - Broker”, este trabajo no se centra en la parte de autenticación
por parte del Broker y de los clientes que se conectan, por lo que no es necesario establecer
los datos de autenticación al momento de realizar la conexión. Sin embargo, como ya se
mencionó es posible implementarlo, en dicho caso el sistema otorgaría al usuario las
pág. 134
credenciales correspondientes para poder conectarse. En la siguiente captura podemos
visualizar el panel implementado para realizar la solicitud de los datos de conexión, como así
también ver los sensores habilitados para publicar y sus respectivos tópicos de publicación.
Pestaña de solicitud de credenciales - dashboard de un aerogenerador.
Habiendo establecido la conexión con el Broker, sólo resta suscribirse a los tópicos deseados,
proporcionados por la plataforma web, y elegir la forma de visualización deseada. Las
aplicaciones mencionadas permiten visualizar los datos, desde simples etiquetas de texto
hasta con gauges similares a los implementados en nuestra aplicación web. Las mismas
permiten incorporar tantos gauges como sean necesarios ya sean para distintas suscripciones
o para una misma suscripción. De esta forma los clientes pueden configurar su dashboard,
como mejor se ajuste a sus necesidades e intereses.
En la siguiente imagen podemos apreciar el dashboard “MQTTDash”, el cual fue instalado y
configurado en un dispositivo Android, para recibir los valores climáticos (temperatura,
velocidad y dirección de viento) y la tensión del banco de baterías de un aerogenerador, los
cuales fueron tratados previamente por nuestro sistema.
pág. 135
CAPÍTULO 9:
CONCLUSIONES
1 Introducción
Como hemos dicho a lo largo de este trabajo, la problemática del abastecimiento y control
energético en las comunas rurales representa una serie de inconvenientes que afecta el
bienestar de los habitantes que habitan en esas condiciones. Dadas las distancias y dispersión
que éstas presentan, hacen difícil que se cuente con acceso al interconectado eléctrico para el
abastecimiento continuo de energía. Como se comentó a lo largo de esta tesina, estos
problemas son afrontados mediante las instalaciones de equipos generadores que utilizan
tanto energías renovables como alternativas, como el caso de los grupos electrógenos, pero el
mantenimiento de estos equipos sigue siendo dificultoso.
En este trabajo hemos hecho énfasis en los equipos generadores a partir de energías
renovables, puntualmente en aerogeneradores y paneles fotovoltaicos cuyo uso se mantiene
en auge.
La poca frecuencia en el mantenimiento de estos equipos conlleva a que la vida útil de los
mismos se reduzca considerablemente, afectando el bienestar de las personas que dependen
de ellos y conllevando, a su vez, grandes escollos económicos. La falta de sistemas que
permitan poder llevar un control regular de estos generadores provoca que las salidas por
mantenimientos sean erráticas o poco frecuentes, lo que provoca, en el peor de los casos, que
los establecimientos queden sin suministro eléctrico.
Esta problemática estableció la base para ahondar en el concepto de Internet de las Cosas
(IoT), es decir, que constituyó el ambiente propicio para la inclusión de las tecnologías
aplicables a los entornos IoT. A lo largo de esta tesina se ha logrado profundizar el tema de
IoT y de cómo puede contribuir a la problemática planteada. Durante su investigación se
evaluaron distintos protocolos y modelos de comunicación que permitieron establecer un
amplio abanico de formas posibles de llegar una solución. Dicho estudio dio como resultado
un sistema de control tipo SCADA, que no solo permite la monitorización de los equipos,
sino que también promueve los principios de IoT, donde la generación y compartición de
datos a través de internet es su principal premisa. Es decir, el sistema no solo provee un
medio para que aquellos encargados de mantener estos equipos puedan verificar el estado de
los generadores sino que también estos datos pueden ser estudiados por otros organismos
relacionados (tales como el Ministerio de Salud de la provincia de Chubut, el Ministerio de
Familia y Promoción Social de la provincia de Chubut, entre otros) o para diferentes usuarios
interesados.
Se ha de destacar que durante la etapa de investigación y desarrollo se estudiaron y
determinaron aquellos tipos de datos que resultan necesarios para la verificación y el control
de los equipos, los cuales culminaron en la clasificación que se ha venido planteando a lo
largo de este trabajo (datos de índole climático y energético). Dichos datos no solo aportan al
control y determinación del funcionamiento de los equipos sino que también aportan a
diferentes tipos estudios relacionados (por ejemplo, a partir de la información recabada sobre
el entorno climático se puede estudiar la implantación de un parque eólico en la zona donde
está establecida la comuna).
pág. 136
2 Aportes
Si bien a lo largo de esta tesina se ha trabajado sobre un ambiente acotado, se ha llegado a la
conclusión de que el sistema resultante es una herramienta para poder llevar un mejor control
de los equipos de generación como así también aporta la posibilidad de poder contar con
diferentes y diversos datos que sostengan diferentes tipos de estudios relacionados al clima,
consumos energéticos, análisis de factibilidad de instalación de equipos similares, etc. De
esta forma se ofrece un medio que contribuye a la solución del problema planteado,
permitiendo llevar un mejor control y brindando la posibilidad de organizar salidas de
mantenimiento más precisas y eficientes para así prolongar la durabilidad y continuidad del
funcionamiento de los equipos.
En este punto, podemos afirmar que el objetivo principal de la tesina ha sido alcanzado, dado
que hemos logrado incursionar en profundidad en el concepto de IoT, como así también en
los diferentes protocolos, modelos de comunicaciones y elementos aplicables a ella. A su vez,
hemos logrado alcanzar el objetivo secundario planteado, el cual fue el desarrollo de un
sistema de control para comunas rurales aisladas, el cual a diferencia de los sistemas
SCADAs convencionales, este no se encuentra acotado a un entorno cerrado de control sino
que presenta características colaborativas que permite poder compartir la información a
través de Internet.
A su vez, hemos de resaltar que este sistema aporta a la multiplataforma ofreciendo la
posibilidad de utilizar diferentes tipos de dashboard para el muestreo de datos, es decir que no
limita a los usuarios a utilizar únicamente el panel desarrollado en este proyecto sino que
también es posible utilizar otros tipos de dashboard disponibles en otras plataformas (ej.
Android) y comunicarlos con el servidor implementado, ajustándose a las diferentes
necesidades de los potenciales usuarios.
3 Investigaciones futuras y mejoras sugeridas por la
presente tesina
Durante el desarrollo de la presente tesina han surgido ideas para futuras líneas de trabajo,
como así también de posibles mejoras a implementar:
Profundizar e implementar mecanismos de autenticación de usuarios por parte del
Broker, lo que lleva a disponer de un sistema con mejores prestaciones en lo referente
a la seguridad.
Implementar dashboard correspondiente a los paneles solares, como así también de
los gauges de los sensores excluidos del conjunto inicial de variables; de forma tal que
se disponga de un dashboard más completo y un set de datos más abarcativo.
Incluir conjunto de funcionalidades para el manejo de los actuadores de forma remota
(Solo para usuarios administradores).
Evaluar e investigar otras alternativas para el uso de WebSockets o de posibles
mejoras en relación a la seguridad en su uso; como por ejemplo, encriptar los
mensajes intercambiados entre el servidor y el front-end de la aplicación (HTTPS).
pág. 137
Incursionar en estudios meteorológicos con el objetivo de poder incorporar al sistema
no sólo visualización de datos en tiempo real, sino que además, a partir de los datos
recolectados puedan realizarse análisis predictivos.
pág. 138
BIBLIOGRAFÍA
1. “Radio-Frequency Identification.” Wikipedia, the Free Encyclopedia, 6 de septiembre
de 2015. https://en.wikipedia.org/wiki/Radio-frequency_identification.
2. “The “Only” Coke Machine on the Internet.” Carnegie Mellon University Computer
Science Department, n.d. Web. 6 de septiembre de 2015.
https://www.cs.cmu.edu/~coke/history_long.txt
3. Stafford-Fraser, Quentin. “The Trojan Room Coffee Pot.” N.p., mayo de 1995. Web. 6
de septiembre 2015. http://www.cl.cam.ac.uk/coffee/qsf/coffee.html
4. RFC 7452, “Architectural Considerations in Smart Object Networking” (marzo de
2015), https://tools.ietf.org/html/rfc7452
5. Cicciari, Matt. “What’s Missing from the Industrial Internet of Things Conversation?
Software.” Wired. http://www.wired.com/insights/2014/11/industrial-internet-of-
things-software/
6. “Internet of Things: Wearables.” Application Developers Alliance.
http://www.appdevelopersalliance.org/internet-of-things/wearables/.
7. Baguley, Richard, and Colin McDonald. “Appliance Science: The Internet of Toasters
(and Other Things).” CNET, 2 de marzo de 2015.
http://www.cnet.com/news/appliance-science-the-internet-of-toasters-and-other-
things/
8. “IEEE Smart Cities.” IEEE, 2015. Web. 6 de septiembre de 2015.
http://smartcities.ieee.org/
9. “Cisco Visual Networking Index: Forecast and Methodology, 2014-2019.” Cisco, 27
de mayo de 2015. http://www.cisco.com/c/en/us/solutions/collateral/service-
provider/ip-ngn-ip-next-generation-network/white_paper_c11-481360.pdf
10. “Overview of the Internet of Things.” ITU, 15 de junio de 2012.
http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=Y.2060
11. “Internet of Things.” Oxford Dictionaries, n.d. Web. 6 de septiembre de 2015.
http://www.oxforddictionaries.com/us/definition/american_english/Internet-of-things
12. Tschofenig, H., et. al., Architectural Considerations in Smart Object Networking.
Tech. no. RFC 7452. Internet Architecture Board, marzo de 2015. Web.
https://www.rfc-editor.org/rfc/rfc7452.txt
13. Ver http://whatis.techtarget.com/definition/Internet-of-Things
pág. 139
14. Tschofenig, H., et. al., Architectural Considerations in Smart Object Networking.
Tech. no. RFC 7452. Internet Architecture Board, marzo de 2015. Web.
https://www.rfc-editor.org/rfc/rfc7452.txt
15. Duffy Marsan, Carolyn. “IAB Releases Guidelines for Internet-of-Things
Developers.” IETF Journal 11.1 (2015): 6-8. Internet Engineering Task Force, julio de
2015. Web. https://www.internetsociety.org/sites/default/files/Journal_11.1.pdf
16. “Meet the Nest Thermostat | Nest.” Nest Labs. Web. 31 de agosto de 2015.
https://nest.com/thermostat/meet-nest-thermostat
17. “Samsung Privacy Policy--SmartTV Supplement.” Samsung Corp. Web. 29 de
septiembre de 2015. http://www.samsung.com/sg/info/privacy/smarttv.html
18. Duffy Marsan, Carolyn. “IAB Releases Guidelines for Internet-of-Things
Developers.” IETF Journal 11.1 (2015): 6-8. Internet Engineering Task Force, julio de
2015. Web. https://www.internetsociety.org/sites/default/files/Journal_11.1.pdf
19. “How It Works.” SmartThings, 2015. http://www.smartthings.com/how-it-works
20. Duffy Marsan, Carolyn. “IAB Releases Guidelines for Internet-of-Things
Developers.” IETF Journal 11.1 (2015): 6-8. Internet Engineering Task Force, julio de
2015. Web. https://www.internetsociety.org/sites/default/files/Journal_11.1.pdf
21. Wilton, Robin. CREDS 2014 - Position Paper: Four Ethical Issues in Online Trust.
Issue brief no. CREDS-PP-2.0. Internet Society, 2014.
https://www.internetsociety.org/wp-content/uploads/2017/08/Ethical20Data-
handling20-20v2.0.pdf
22. Rolling Plan for ICT Standardisation (Plan Progresivo de Normalización de las TIC),
2017, European Commission ( Comisión Europea). Ver https://ec.europa.eu/digital-
agenda/en/rolling-plan-ict-standardisation
23. Botterman, Maarten. Policy Paper on IoT Future Technologies: Opening towards a New
Reality. Issue brief no. D5.2. http://www.smart-action.eu/fileadmin/smart-
action/publications/Policy_Paper_on_IoT_Future_Technologies.pdf
