METODOLOGÍA PARA LA DETERMINACIÓN DE PROTOCOLOS DE

COMUNICACIÓN A NIVEL INDUSTRIAL A PARTIR DEL ANCHO DE BANDA

Y TIPO DE SEÑAL ELÉCTRICA

DANIEL PARRA OSPINA

UNIVERSIDAD TECNOLÓGICA DE PEREIRA

PROGRAMA DE ESPECIALIZACIÓN EN ELECTRÓNICA DIGITAL

PEREIRA

2021

METODOLOGÍA PARA LA DETERMINACIÓN DE PROTOCOLOS DE

COMUNICACIÓN A NIVEL INDUSTRIAL A PARTIR DEL ANCHO DE BANDA

Y TIPO DE SEÑAL ELÉCTRICA

DANIEL PARRA OSPINA

Trabajo de investigación de tipo monografía presentado como requisito parcial para aspirar al título de Especialista en Electrónica Digital.

Director M.Sc. Arley Bejarano Martínez.

UNIVERSIDAD TECNOLÓGICA DE PEREIRA

PROGRAMA DE ESPECIALIZACIÓN EN ELECTRÓNICA DIGITAL

PEREIRA

2021

RESUMEN

Con el crecimiento industrial presentado durante las últimas décadas, la necesidad de distintas empresas de implementar la tecnología a sus procesos es cada vez mayor. No solo se trata de una herramienta que les permite optimizar tiempo y recursos, sino también una estrategia para tener mayor control y seguridad de los procesos y datos de las distintas compañías. Allí es donde el Internet de las Cosas (IoT) toma un papel principal; permitiendo la conexión entre dispositivos para compartir y captar información. No obstante, para que esta conexión funcione de la mejor manera, es decir, permita la conexión de gran cantidad de dispositivos, requiera poca capacidad de procesado, presente medidas de seguridad consolidadas, entre otras variables importantes, se necesita incorporar ciertas normas conocidas como Protocolos de Comunicación; estos protocolos son muy variados y la implementación de uno en específico dependerá de la aplicabilidad que quiera dársele. En la presente monografía se expondrán características de distintos protocolos: creación, funcionamiento y aplicabilidad según variables como ancho de banda y tipo de señal eléctrica. Finalmente se propondrá una metodología para elegir el protocolo de comunicación más conveniente según la necesidad del usuario; esto, haciendo uso de las investigaciones previamente realizadas por distintos autores en este campo.

CONTENIDO

PREFACIO ............................................................................................................................. 7 1.1. DEFINICIÓN DEL PROBLEMA. ............................................................................. 7 1.2. JUSTIFICACIÓN ....................................................................................................... 9 1.3. OBJETIVOS ............................................................................................................. 10 1.3.1 OBJETIVO GENERAL ....................................................................................... 10 1.3.2 OBJETIVOS ESPECIFICOS ............................................................................... 10 MARCO REFERENCIAL ................................................................................................... 11 2.1 ESTADO DEL ARTE .............................................................................................. 11 2.1.1 IoT (Internet of Things – Internet de las Cosas) .................................................. 11 2.1.2 Protocolos de comunicación................................................................................. 13 2.2 MARCO CONCEPTUAL ........................................................................................ 14

2.2.1

Internet de las cosas (IoT) .............................................................................. 14

2.2.2

Software para IoT ........................................................................................... 15

2.2.3

Hardware para IoT .......................................................................................... 15

2.2.4

Protocolos de comunicación ........................................................................... 15

2.2.5

Redes de comunicación .................................................................................. 16

2.2.7

Analítica de datos ........................................................................................... 16 2.3 MARCO TEÓRICO ................................................................................................. 17

2.3.1

Aplicaciones IoT industriales ......................................................................... 17

2.3.2

Redes para IoT ................................................................................................ 17

2.3.3

Modelo OSI .................................................................................................... 18

2.3.4

Protocolos de comunicación en la industria ................................................... 23

2.3.5

Plataformas IoT .............................................................................................. 32 METODOLOGÍA ................................................................................................................. 33

2.4 Elección de protocolos de comunicación.................................................................. 33 3.2 Características en las capas de los protocolos de comunicación ................................ 34 3.2.1. MQTT.................................................................................................................. 34 3.2.2. CoAP ................................................................................................................... 35 3.2.3. AMQP ................................................................................................................. 37 3.2.4. HTTP ................................................................................................................... 38 3.2.5. HART .................................................................................................................. 40 3.2.6. Modbus. ............................................................................................................... 42 3.2.7. IPv6 .................................................................................................................... 44 3.2.8. DeviceNet .......................................................................................................... 46 3.2.9. Zigbee .................................................................................................................. 48 3.2.10. Bluetooth Low Energy (BLE) ........................................................................... 50 3.2.11. Z-Wave .............................................................................................................. 52 3.2.12. NFC ................................................................................................................... 54 3.2.13. SigFox ............................................................................................................... 56

APLICACIÓN DE LOS PROTOCOLOS DE COMUNICACIÓN SEGÚN LA

NECESIDAD ....................................................................................................................... 58 RESULTADOS .................................................................................................................... 59 CONCLUSIONES Y TRABAJOS FUTUROS ................................................................... 61 Bibliografía ........................................................................................................................... 63

LISTA DE TABLAS

Tabla 1. Protocolos Usados En Capas Del Modelo OSI. ..................................................... 22 Tabla 2. Comparativa entre capas de modelo OSI y modelo TCP/IP. ................................. 23 Tabla 3. Especificaciones del protocolo MQTT. (Naik N. , 2017) ................................. 35 Tabla 4. Especificaciones del protocolo CoAP. (Naik N. , 2017) ................................... 36 Tabla 5. Especificaciones del protocolo AMQP. (Naik N. , 2017) ................................. 38 Tabla 6. Especificaciones del protocolo HTTP. (Naik N. , 2017) .................................. 39 Tabla 7. Especificaciones del protocolo HART. .............................................................. 41 Tabla 8. Especificaciones del protocolo Modbus. ............................................................ 44 Tabla 9. Especificaciones del protocolo IP. ...................................................................... 46 Tabla 10. Especificaciones del protocolo DeviceNet. ...................................................... 48 Tabla 11. Especificaciones del protocolo Zigbee. ............................................................ 49 Tabla 12. Especificaciones del protocolo BLE. ................................................................ 52 Tabla 13. Especificaciones del protocolo Z-Wave. .......................................................... 53 Tabla 14. Especificaciones del protocolo NFC. ............................................................... 55 Tabla 15. Especificaciones del protocolo SigFox. ........................................................... 57

LISTA DE FIGURAS

Figura 1. Aplicación de los protocoles de comunicación. .................................................... 58

PREFACIO

1.1. DEFINICIÓN DEL PROBLEMA.

Desde la invención del transistor, considerado como el cimiento de las bases de la electrónica moderna, los sistemas de diseño electrónico han avanzado a gran velocidad, lo que ha permitido la elaboración de dispositivos cada vez más pequeños con un bajo costo y consumo energético (Brinkman, 1997), todos estos nuevos desarrollos han conducido a la creación de los de los sistemas embebidos cuyas bases han sido los circuitos integrados y microcontroladores, cuyas características de procesamiento y almacenamiento han permitido el desarrollo de prototipos y dispositivos electrónicos en innumerables aplicaciones que han facilitado las actividades del ser humano (Kramer, Stolze, & Banse, 2009). El gran avance y expansión de esta área del conocimiento, conllevan a la diversificación de estos dispositivos; ofreciendo al usuario equipos, con diferentes características, para las diversas aplicaciones, ya sea a nivel educativo, a nivel industrial, entre otros. Esto ha conducido, de cierta forma, a la necesidad de desarrollar herramientas que le permitan a las personas implementar sistemas más flexibles y de fácil manipulación, llegando así a la idea de una plataforma de prototipos de código abierto con un hardware y software de fácil manipulación; esta idea se puede ver plasmada en lo que hoy se conoce como Arduino (Galadima, 2014) (Barrett, 2020), entre muchos otros dispositivos, tarjetas (Raspberry, Thunderboard, Ultrahaptics, AudioSmart, SensorTile, etc.) y lenguajes de programación que han adoptado esta nueva tendencia de los sistemas embebidos (O. E.Amestica, 2019). Los desarrollos de todas estas tecnologías han dado lugar a un nuevo concepto conocido como Internet de las cosas (IoT), el cual consiste en permitir a los objetos físicos conectarse a internet para intercambiar y almacenar datos en tiempo real en la web u otros dispositivos con un propósito definido, por medio de una integración de sensores, software y otras tecnologías (S. Chaudhary, 2019), logrando de esta manera unir el mundo real con el mundo digital, lo cual ha logrado impulsar un cambio transformador en las industrias, permitiendo el desarrollo de metodologías de trabajo más ágiles, minimizando costos, tiempos de producción, como también permitiendo la manipulación inteligente de las cosas mediante la interconexión de múltiples dispositivos (W. Steiner, 2014).

En las industrias, el avance tecnológico podría resumirse en la etapa de la mecanización de la producción por medio del vapor y el agua (finales del siglo XVIII), la producción en masa con líneas de montaje e introducción de la energía eléctrica (principios del siglo XX), la introducción de la electrónica y la informática para automatizar las líneas de producción (comienzo de los 70) y a lo que hoy se conocen como las industrias 4.0, las cuales convergen en las TIC (Tecnologías de la Información y la Comunicación), sensórica y robótica con sistemas Ciber-físicos, lo cual marca una tendencia en los consumidores por productos cuya experiencia sea más individualizada y actualizada, es decir, añadir software y conectividad a cualquier producto (Val, 2016). Estos desarrollos tecnológicos representan grandes retos para países en vías de desarrollo, como es el caso de Colombia, cuyo enfoque se basa en la importación y no en la preparación de personal para la creación y desarrollo de tecnologías, lo que representa un atraso en los desarrollos propios y un alto costo por concepto de desajuste del bien o servicio importado, al igual que dichas tecnologías no son diseñada propiamente para el contexto de las industrias colombianas (José Daniel Cabrera Cruz), donde el 48.4% de las industrias colombianas para el 2017 empezaron a adoptar estrategias de transformación digital con tecnología importada (David A. Casas Castillo, 2019) (Ruiz, 2014). Con la necesidad de facilitar la transmisión de información entre dos fuentes (emisor y receptor), y buscando optimizar la velocidad y los costos invertidos en estas tareas, se plantea la aplicación de protocolos industriales de comunicación, cuyo propósito no es otro que el intercambio de datos entre dispositivos que forman parte de una red; esto facilita la obtención de información para tomar decisiones tanto en labores sencillas, tareas del día a día, como en proyectos de largo alcance. Los protocolos, sin embargo, aumentan al ritmo de los avances tecnológicos; esto hace que, para elegir el protocolo adecuado en una conexión, deban estudiarse los requerimientos de los dispositivos involucrados (como bajo consumo energético, corto ancho de banda, interoperabilidad o proximidad) (Kozierok, 2005).

1.2. JUSTIFICACIÓN

En la actualidad las industrias y muchos otros sectores enfrentan grandes desafíos debido a los cambios económicos, ambientales y del incremento desmesurado de la población, lo que implica un mayor consumo de recursos, exigiendo una mayor productividad en las industrias, lo que las obliga a avanzar en un ritmo equivalente a los avances tecnológicos. Para brindar soporte en esta necesidad, se implementa el IoT, una salida inteligente y necesaria (Sahu, 2018) que permite una mayor producción debido a la comodidad de la manipulación de objetos a control remoto (sin necesidad de la presencia física de un operario), permitiendo además grandes capacidades y alcances como autoevaluar su funcionamiento y la predicción de problemas potenciales, lo que repercute en minimizar los tiempos de inactividad y aumentar la eficiencia general (Yahaghizadeh, 2018).

Para implementar correctamente el IoT y aplicar los beneficios a diversas áreas de la industria o la domótica, deben tenerse muy presentes las especificaciones requeridas por cada conexión. Las conexiones y La transferencia de datos entre diversos tipos de dispositivos, cuentan con características individuales, que requieren parámetros igualmente individuales. Existen diferentes protocolos en la industria, cada uno óptimo para determinado tipo de conexión, por lo que un análisis de los parámetros a implementar en la misma debe ser llevado a cabo. Esto garantiza que la comunicación sea eficaz y que los datos fluyan eficientemente entre los dispositivos conectados a la misma red. No importa de qué sector se hable; desde la domótica hasta las grandes industrias, cada sector requiere vincular un protocolo de comunicación a sus conexiones.

La diversidad de las industrias y la búsqueda de la implementación digital en estas mediante la implementación de dispositivos IoT, implica definir unos parámetros generales que se podrían clasificar según su aplicación, plataforma de conexión, red de comunicación y objetos controlados, donde se requiere un sistema que permita unificar los diferentes protocolos que se encuentran en la industria y poder enviar la información mediante el dispositivo IoT, lo que permitiría una mejora en la industria de la región y el país. Por ello, buscando facilitar la interconexión entre dispositivos IoT, es necesario realizar una exploración y estudiar a conciencia los protocolos de investigación vigentes, los cuales establecerán las pautas para la transmisión de datos entre dispositivos de manera óptima. Ya

que existen varios tipos, es necesario definir cuál es el más conveniente en aplicaciones que cuentan con ciertas limitaciones como lo son el consumo energético y el ancho de banda. Estos estudios brindarán una ayuda considerable en futuros diseños de dispositivos, pues se brindarán herramientas para escoger convenientemente la forma de transferencia de datos propicia para los mismos según sus requerimientos.

La utilidad de los protocolos de comunicación ha afianzado el orden en las conexiones y las transferencias de datos; sin embargo, no es irrelevante que los mismos deban presentar constantes actualizaciones. Prueba de esto es la nueva versión del protocolo de Internet, que tuvo que aumentar la cantidad de direcciones por el crecimiento de la red a nivel global.

1.3. OBJETIVOS

1.3.1 OBJETIVO GENERAL

Definir una ruta que permita establecer el protocolo industrial de comunicación más adecuado de acuerdo a su ancho de banda y a su tipo de señal.

1.3.2 OBJETIVOS ESPECIFICOS

1. Recopilar bibliografía acerca de los protocolos industriales de comunicación y

realizar una revisión exhaustiva de la misma.

2. Determinar el funcionamiento de cada protocolo de comunicación y conocer las

ventajas que ofrece en distintas aplicaciones.

3. Comparar el rendimiento de los protocolos de comunicación estudiados en la

transmisión de datos según su ancho de banda y su tipo de señal.

4. Establecer una secuencia que permita aplicar los protocolos industriales de

comunicación según su clasificación.

MARCO REFERENCIAL

2.1 ESTADO DEL ARTE

2.1.1 IoT (Internet of Things – Internet de las Cosas)

En los avances de la tecnología y las ciencias de la computación, se han desarrollado diferentes investigaciones sobre la arquitectura IoT y los diferentes protocolos de comunicación utilizados a nivel industrial. A continuación, se presentarán algunos avances y contribuciones hechos al desarrollo de metodologías relacionadas con esta área.

En 2013 Maria Rita Palattella et al, platearon usar una arquitectura IoT IEEE/IETF estandarizada con un algoritmo de estandarización datacentrico llamado Traffic Aware Scheduling Algorithm (TASA). Con esta arquitectura logran optimizar y obtener los límites en el número mínimo de ranuras activas necesarias (que afectan los retrasos de extremo a extremo) y el ciclo de trabajo de la red (que afecta toda la vida). Demuestran la enorme superioridad de TASA sobre los enfoques tradicionales IEEE802.15.4 / ZigBee en términos de eficiencia energética (Palattella, 2013).

Qingping Ch, et al, en 2014, hacen referencia a las restricciones de los dispositivos en cuanto al número de conexión actual, la frecuencia de muestreo y los tipos de señal de los sensores, para solucionar estas restricciones respecto a las aplicaciones IoT proponen un método para diseñar una interfaz de sensor inteligente reconfigurable para WSN industrial en un entorno de IoT, en el que se adopta un dispositivo lógico programable complejo (CPLD) como controlador central, por lo que puede leer datos en paralelo y en tiempo real con alta velocidad en múltiples datos de sensores diferentes (Chi, 2014). En 2017 Shahid Mumtaz et al, hace una descripción general del desarrollo y las estandarizaciones de las soluciones de conectividad para habilitar el Internet de las cosas industrial (IIoT), destacan las tecnologías y plataformas clave de conectividad IIoT. Además, abordan los principales desafíos del IIoT, como lograr una conectividad segura

y administrar un ecosistema de soluciones y plataformas de conectividad. Finalmente, los desafíos de conectividad IIoT se ilustran con el ejemplo de la futura automatización de edificios (Mumtaz, 2017).

Martin Wollschlaeger, Thilo Sauter, y Jürgen Jasperneite, en 2017, se centran en las aplicaciones IoT para la automatización industrial, revisan el impacto de IoT y CPS en la automatización industrial desde una perspectiva de la industria 4.0, analizan el estado actual del trabajo en las redes Ethernet sensibles al tiempo (TSN) (Wollschlaeger, 2017). Hongyu Pei Breivold y Kristian Sandström, en 2015, aclaran las restricciones específicas de los atributos de calidad dentro de la automatización industrial y discuten los desafíos que presenta el IoT para la automatización industrial como: Seguridad de datos y servicios, Confianza, integridad de datos y privacidad de la información, escalabilidad, interoperabilidad. Los retos presentados por el IIoT están enfocados en Criticidad mixta, latencia, tolerancia a fallos, escalabilidad con respecto a los ciclos de actualización de datos, colaboración escalable, seguridad funcional, desafío de seguridad específico de la industria, sistemas industriales de larga duración heredados. Adicionalmente proponen una forma de gerenciar los restos de IoT (Breivold, 2015).

Hui Suoa, Jiafu Wana,b, Caifeng Zoua y Jianqi Liua, en el 2012, estudian la seguridad y la privacidad como los problemas clave presentados por las aplicaciones de IoT a la industria. Expresan que en cuanto a la seguridad los desafíos que se presentan son debidos a la red de conexiones de sensores y actuadores al internet lo que provoca que surjan problemas de privacidad. Por medio de este artículo se puede identificar los requerimiento de seguridad en una aplicación IoT, como mecanismos de encriptación, seguridad de comunicación (Protocolos TLS / SSL o IPSec), protección de datos del sensor y algoritmo criptográficos como: Advanced encryption standard (AES) para la confiabilidad, Rivest shamir adelman (RSA)/ Elliptic curve cryptography (ECC) para proporcionar claves de firmas digitales, Diffie-hellman (DH) para claves y SHA-1/SHA- 256 para la integridad de datos (Suo, 2012).

2.1.2 Protocolos de comunicación.

La industrialización y las guerras a lo largo de los años han obligado a la humanidad a adaptar nuevas estrategias para la transmisión de información, y el manejo y adquisición de los recursos provenientes de diversos sectores; las fábricas y otras compañías pasaron de controlar sus procesos manualmente a implementar sistemas de control, y cuando estos sistemas eran demasiado grandes y costosos para manejar la cantidad de dispositivos asociados a ellos, aparecieron los microcontroladores, que optimizaron no solo costos sino el rendimiento de estos equipos en sus respectivos procesos. Claramente surgieron otras limitaciones con el paso del tiempo, estos dispositivos debían utilizar información de otros, y a su vez, estar disponibles para transmitirla en el momento que fuese necesario; allí se marcó la importancia de establecer ciertas normas que permitieran la comunicación de los equipos y la transferencia de datos entre ellos, estas normas fueron llamadas protocolos de comunicación. Aun cuando los fabricantes de dispositivos comenzaron a implementar estas normas en cada uno de sus modelos, los protocolos creados por ellos eran propios; es decir, solo eran aplicables a sistemas y equipos del mismo fabricante, las otras marcas tenían su propio protocolo y esto imposibilitaba la transferencia de datos entre un dispositivo y otro. Conociendo que esta restricción representaba un aumento en costos y tiempos de producción en distintas compañías, además de otros sectores como el académico y el gubernamental, era evidente que debían crearse protocolos abiertos, que permitieran la comunicación y transferencia de datos entre equipos sin importar su fabricante o marca. Para el año 1969 se estableció ARPANET (Advanced Research Projects Agency Network), la primera red de comunicación entre dispositivos sin la existencia de un nodo central, es decir, un dispositivo que tuviese que recibir la información de otros dispositivos, almacenarla y transmitirla a los demás. Por medio de ARPANET, los dispositivos podían transmitir información unos a otros sin intermediarios, lo que era muy conveniente frente a las comunicaciones anteriores, en las que, si el dispositivo central sufría algún daño, se presentaban significativas pérdidas de información (esto era considerado sobre todo por el periodo que se estaba viviendo: la Guerra Fría; periodo en el que captar información de gobiernos enemigos era una tarea diaria) (Lukasik, 2010). Los investigadores, encabezados por el científico del MIT (Massachusetts Institute of Technology) John Licklider, desarrollaron desde 1962 esta

idea, y para cuando esta fue implementada, ya se había concebido también su protocolo de comunicación; este recibió el nombre de NCP (Network Control Protocol). A partir de allí, distintos protocolos han sido creados, como el HDLC (High-Level Data Link Control) en 1970 bajo el modelo OSI (Open Systems Interconnection), el IP (Internet Protocol) en 1973 bajo este mismo modelo; este último ha tenido muchas mejoras, siendo estás implementadas en cada nueva versión que se ofrece. La última versión IP es la IPv6, creada por Steve Deering, quien comenzó su desarrollo en 1998; esta versión buscaba sustituir a la anterior (IPv4) por la limitación que comenzó a presentar a la hora de proveer direcciones de red admisibles (lo que generaba un estancamiento en el objetivo de globalizar Internet) (Kozierok, 2005). Los Protocolos siguieron creándose, por lo que actualmente se tiene a disposición muchos de ellos; la elección de uno en específico recae sobre la necesidad del usuario y un análisis de los beneficios y las limitaciones que trae cada uno de ellos. Algunos protocolos encontrados son abiertos; es decir, aplicables a la conexión de dispositivos sin necesidad de solicitar permisos o autorizaciones; otros son de propietario, por lo que su uso se restringe a la disposición y autorización del creador o fabricante.

2.2 MARCO CONCEPTUAL

2.2.1 Internet de las cosas (IoT)

IoT es una infraestructura de red global, compuesta de una gran cantidad de dispositivos conectados que están censando y por medio de redes y tecnologías de procesamiento de información permite analizar que se consume en el mundo y conocer que dispositivos se encuentran apagados o encendidos (L. Da Xu, 2014). De esta forma se permite que los objetos cotidianos sean más inteligentes, y que se puedan controlar desde computadores, celulares, tabletas, en general, cualquier dispositivo que tenga acceso a internet.

El IoT se refiere a la interconexión de objetos comunes a la internet, por medio de microcontroladores y transceptores (G. M. L. Atzori, 2010). El IoT tiene como objetivo facilitar la interacción con objetos como vehículos, electrodomésticos, sensores y actuadores, lo que posibilita la recolección de una gran cantidad de datos,

que posteriormente serán analizados para proporcionar nuevos servicios a los usuarios y empresas. El IoT encuentra aplicación en campos como la medicina, deporte, monitoreo ambiental, automatización del hogar y la automatización industrial, entre otros.

2.2.2 Software para IoT

Los softwares para IoT permiten recibir, almacenar, analizar y visualizar datos de forma directa desde la nube. Algunos de ellos permiten ejecutar código para analizar y procesar datos (computación en la nube). Algunos softwares son ThinkSpeak, Altair SmartCore, Electric Imp, Spark Works, Blaulabs, Thinking things, Zatar, Amazon Web Services IoT, Azure IoT Hub, Oracle Internet of Things, Watson IoT, Xively – Google Cloud IoT, Samsung Artik, Adafruit IO, Ubidot, My Devices Cayenne y Macchina IO (Martínez Moreno, 2019).

2.2.3 Hardware para IoT

El Hardware para IoT consiste en dispositivos como microcontroladores, chips o sistemas, encargados de recibir la información de los sensores y enviarla por medio de una red de comunicación a la nube, también, son los encargados de accionar los actuadores dependiendo del resultado del análisis de los datos. Algunos hardware utilizados en IoT son Raspberry Pi, Arduino, Waspmote, Spark (Apache Spark), Intel Galileo y Zigbee (Martínez Moreno, 2019).

2.2.4 Protocolos de comunicación

Los protocolos de comunicación permiten que dos sistemas o más transmitan información y sea entendible para el receptor. Son un conjunto de reglas que definen la sintaxis, semántica y sincronización, también incluyen los métodos de recuperación de errores (Vargas, 2016). Los protocolos de comunicación también establecen la forma de transmisión de datos, como se deben procesar y como se identifican en la red. Los protocolos de comunicación pueden ser empleados a nivel de hardware o software.

2.2.5 Redes de comunicación

Las redes de comunicación hacen referencia al medio por el cual se transmite la información y el alcance que esta tiene, en forma de ondas electromagnéticas, ya sea en materiales como la fibra óptica, cobre o vacío. Las redes según su alcance se clasifican en red de área personal (PAN - Personal Area Networks), red de área local (LAN - Local Area Networks), red de área metropolitana (MAN - Metropolitan Area Networks), red de área amplia (WAN - Wide Area Networks) y red de área global (GAN - Global Area Networks) (Mahmud, 2005).

2.2.6 Interoperabilidad

La interoperabilidad es la capacidad de dos o más sistemas de intercambiar datos y utilizar la información (Vargas, 2016). Implica que ambos sistemas puedan recibir y enviar información con el objetivo de compartir conocimiento.

2.2.7 Analítica de datos

En la actualidad se tiene acceso a una cantidad abrumadora de datos, los cuales pueden ser muy variados; sin embargo, aún sigue determinándose la mejor forma de usar esos datos para generar conocimiento práctico y hacerlo comprensible para quienes van a usarlo, la analítica de datos aparece como una respuesta a esta situación (Serrano-Cobos, 2014).

Es importante determinar la relevancia de los datos cuando se van a procesar, con el propósito de disminuir el costo computacional y evitar analizar datos que no aportan informacional proceso.

2.3 MARCO TEÓRICO

2.3.1 Aplicaciones IoT industriales

Las aplicaciones IoT se han discutido e implementado en muchos dominios de la industria como ciudades inteligentes, energía inteligente, salud, alimentos y agua, automatización, seguimiento, logística y venta minorista, y transporte (Breivold,

2015).

2.3.2 Redes para IoT

Las redes más comúnmente usadas en aplicaciones IoT son: sistemas de transporte cibernético (CTS), sistemas ciberfísicos (CPS) y comunicaciones de máquina a máquina (M2M) (Suo, 2012).

 CTS Transporte cibernético: El transporte cibernético consiste en la transmisión de información por medio de internet, y se usa para analizar datos en la nube y entregar un análisis más rápidamente para proceder entregar la información ya procesada al usuario final (Suo, 2012) (Adel W. Sadek, 2016).  CPS Sistemas ciber físicos: La comunicación ciber física es aquella que se da entre los dispositivos móviles de comunicación, como celulares inteligentes y portátiles, esta comunicación se refiere a la interconectividad entre dispositivos físicos y recursos computacionales (Adel W. Sadek, 2016).  M2M comunicaciones máquina a máquina: Es la comunicación entre computadoras, procesadores integrados, sensores inteligentes, actuadores inteligentes y dispositivos terminales móviles. La comunicación M2M se basa en que una máquina conectada a la red, puede aportar más que si se encuentra aislada. Cuando existe una interconectividad efectiva se pueden generar aplicaciones IoT, autónomas e inteligentes, sin necesidad que el humano intervenga en gran medida (Wan, 2013).

2.3.3 Modelo OSI

Este modelo conocido como “Interconexión de sistemas abiertos” (Open Systems Interconnection), es un modelo de referencia para los protocolos de comunicación de redes informáticas. Fue creado por la ISO (International Organization for Standarization – Organización Internacional de Normalización) durante la década de

1980 con el fin de unificar lo mejor posible las comunicaciones en internet, ya que

por su tamaño creciente y los diferentes fabricantes de dispositivos en el mercado (con sus propios protocolos de comunicación), era difícil mantener un control y orden en la transferencia de datos e interconexiones. Este modelo se organiza en siete capas, las cuales describen las etapas que facilitan la comunicación y transferencia de datos entre distintos dispositivos, siendo estas capas ordenadas de manera jerárquica, es decir, las superiores (capa seis, por ejemplo) pueden acceder a información o datos de las inferiores (capa dos, por ejemplo); las funciones de cada capa están claramente establecidas y se desarrollan de manera independiente, pudiendo aplicar cada una cierto protocolo sin interferir en el desempeño de las demás. Las capas inferiores (de la uno a la cuatro) son denominadas de transporte, mientras que las superiores (de la cinco a la siete) son denominadas capas orientadas a la aplicación (Briscoe, 2000).

La primera es conocida como la capa física (Physical layer) y es la más profunda dentro del modelo OSI; esta define características mecánicas y eléctricas de la red, con el fin de que en esta pueda controlarse la conectividad entre dispositivos. Las interacciones en ella son llevadas a cabo por medio de una secuencia de bits que están contenidos en la capa de enlace (bits que representan los niveles eléctricos en la misma, siendo 1 cuando existe voltaje y 0 cuando el voltaje es nulo en esa conexión); esta se encarga de convertir lo anterior en una señal que puede ser percibida por el dispositivo o medio final en la cadena de transmisión de datos estipulada previamente. La señal generada dependerá del medio de red elegido, siendo los tres principales el cable de cobre, la fibra y el inalámbrico; y las señales generadas, pulsos eléctricos, patrones de luz, y patrones de transmisiones de radio respectivamente (Stallings, Comunicaciones y redes de computadores, 2000).

La segunda es llamada capa de enlace de datos (Data link), esta, en conjunto con la anterior capa, permite el acceso a la red TCP/IP. La capa de enlace de datos permite el intercambio de tramas entre nodos establecidos en un medio físico (definiendo a las tramas como la unidad de envío de datos representada en una secuencia de bits organizados de forma cíclica (WEBSARROLLADORES, 2019)), estas tramas constan de cabecera (que contiene campos de control de protocolo), datos (que contienen la información que quiere transmitirse al dispositivo receptor), y finalmente cola (que comúnmente verifique que no existan errores para la transmisión); el tamaño de la tramas depende, entre otras cosas, de la tecnología y el protocolo de comunicación que se vaya a utilizar.

La tercera es conocida como capa de red (Network layer), esta es la encargada de funciones como el control en el flujo de datos y el direccionamiento de estos a los dispositivos finales, el encapsulamiento de la información (que consiste en etiquetar a la misma con las direcciones tanto de origen como de destino), el enrutamiento (que implica el uso de un servicio que entrega la ruta más rápida y eficaz para transportar la información hacia su destino final), y el desencapsulamiento (función encargada de realizar la verificación de destino), que se encarga de desencriptar el mensaje, leer su encabezado y corroborar que la dirección de destino coincida con la que le pertenece como dispositivo receptor; si no es el caso, y bajo la misma función de desencapsulamiento, se encripta nuevamente el mensaje y se envía al destino final verificado por medio de una ruta conocida. Para realizar estas funciones, la presente capa se vale comúnmente del IP (Internet Protocol – Protocolo de internet), que posibilita la comunicación entre el enrutador de la capa e internet, y de esta forma permite la transmisión de la información; ya que la comunicación se ha globalizado cada vez más, las direcciones establecidas para este protocolo no fueron suficientes, y esto hizo necesaria la creación de una nueva versión que contara con la vinculación de nuevas direcciones (paso de IPv4 a IPv6), aunque esto conlleva limitaciones, pues la transición de dispositivos de una versión a otra requiere de una cantidad de tiempo para nada despreciable (Todo de redes, s.f.).

La cuarta es llamada capa de transporte (Transport layer), esta es la responsable de regular el flujo de información desde el punto de origen hasta que esta se encuentre en su destino. La capa de transporte, en conjunto con las tres anteriores, se encarga de transportar los datos de un punto a otro y de la manera más óptima. Las funciones desempeñadas por esta capa son: segmentación, en la que divide los datos que ha recibido en partes más pequeñas o segmentos, para que su manejo sea mucho más sencillo, seguro y óptimo; reensamblaje, en la que cada segmento denotado por la función anterior recibe un encabezado, con el fin de que estos segmentos puedan ser unidos de forma correcta posteriormente, entre la codificación establecida para sus encabezados, los segmentos contienen la numeración de los puertos de origen y destino respectivamente; multiplexación de conversaciones, en la que los datos ensamblados (es decir, los segmentos correctamente reagrupados) son trasladados a la aplicación correcta por medio de la numeración de los puertos de origen y destino (contenida y verificada en la función anterior); identificación de las conversaciones entre los hosts (conocidos como el conjunto de nodos que facilita obtención de datos a los dispositivos que se encuentran conectados en esta red); finalmente determinación del protocolo conveniente para un correcto envío de los mensajes (Al- Sarawi S. A., 2017).

La quinta es conocida como capa de sesión (Session layer), esta proporciona la posibilidad de que dos hosts, o servidores, se comuniquen entre ellos y puedan intercambiar o transmitir información según sea el caso. Para la interacción entre estos dos servidores, la capa de sesión lleva a cabo una función conocida como control de diálogo, con ella se busca que la información o los datos compartidos entre los servidores sean ordenados y que no se presenten interrupciones que afecten la conexión o la clara recepción de la información. Aquí entonces, para las diferentes acciones llevadas a cabo en la red (entre las que pueden encontrarse las compras virtuales, por ejemplo), es importante que cada sesión sea delimitada; esto con el fin de que la información contenida en la misma, o suministrada por el cliente, no sea adjudicada a otro servidor e imposibilite la intención final propuesta para la

comunicación. Además de esto, la capa de sesión también es responsable de iniciar la conexión y transferencia de datos, estipulando de esta forma las condiciones que deben respetarse y llevarse a cabo durante la transmisión o el intercambio de la información entre servidores o dispositivos. También esta capa se encarga de verificar la correcta transmisión de la información, además de los datos contenidos durante esta; de tal forma que, a pesar de que se presente un fallo durante el procedimiento, se puedan recuperar o deshacer (según sea el caso) las acciones llevadas a cabo previamente (Briscoe, 2000).

La sexta es denominada capa de presentación (Presentation layer), la cual se ocupa de diseñar la forma de presentación de la información. Esta capa recolecta la información manejada desde las capas anteriores y la transforma de tal manera que cumplan la función deseada en la aplicación (por ejemplo, convertir una secuencia de caracteres en el formato conveniente según se requiera). Por lo anterior, esta capa también se describe como un puente entre el formato de red y el de aplicación, de manera que parafrasee las directrices entregadas en cualquiera de los lenguajes de estos formatos, creando así un formato estándar que sea interpretado correctamente de un dispositivo a otro. Además de lo anterior, la capa de presentación permite comprimir los datos o la información, de manera que, durante su transporte y al llegar al dispositivo de destino, el peso de los datos sea menor y brinde agilidad en el funcionamiento de la operación (es importante aclarar que esta capa podrá llevar a cabo la función de descompresión una vez que la información haya llegado al destino estipulado previamente); la información también puede ser encriptada en su punto de origen, y desencriptada una vez que llegue al destino, esto garantiza la seguridad de la operación y por consiguiente de la información.

La superior, o de último nivel, es conocida como capa de aplicación (Application layer), y en ella se llevan a cabo la entrada y salida de datos presentes en las aplicaciones. Esta capa proporciona la interfaz entre las aplicaciones utilizadas para compartir, intercambiar y/o transmitir información; hace uso, como las demás capas, de protocolos de comunicación, en esta capa en particular, los protocolos

proporcionan el intercambio de información entre un servidor y otro, la capa se encarga de que la visualización de estos datos en las aplicaciones se genere de manera correcta. Puede evidenciarse entonces que esta capa, como deja ver el que sea la capa superior, es la más cercana al usuario, y por tanto debe contener la información de manera entendible para cualquiera que acceda a ella (tal es el caso de los navegadores web o de los programas de correo electrónico bastamente utilizados, en los que el usuario puede ingresar caracteres de búsqueda que serán captados y transmitidos desde esta capa hacia las demás, entregándole al servidor la solicitud de información requerida).

Como se mencionó anteriormente, cada capa posee ciertos protocolos para llevar a cabo sus funciones de interoperabilidad y transferir la información de un dispositivo a otro correctamente. Los protocolos comúnmente utilizados en cada capa o nivel se muestran en la tabla 1 (debe tenerse en cuenta que la tabla se presenta desde la capa superior hasta la inferior).

Capa del modelo OSI Algunos protocolos utilizados Capa de aplicación (capa 7)

HTTP, MQTT, COAP, AMQP.

Capa de presentación (capa 6)

NFC, AFP

Capa de sesión (capa 5) NetBIOS, ISNS, FTP, SAP Capa de transporte (capa 4)

UDP, TCP

Capa de red (capa 3)

IP, IGP, RIP, IPX

Capa de enlace de datos (capa 2) Ethernet, FDDI, ARP, PPP Capa física (capa 1)

DLS, ISDN, ADSL, USB

Tabla 1. Protocolos Usados En Capas Del Modelo OSI.

Existen otros modelos, entre los que se encuentra el modelo TCP/IP que se establece igualmente por capas o niveles; en este último, las capas son establecidas con base en el modelo OSI (ciertas capas OSI se agrupan en una capa TCP/IP). En la tabla 2, pueden evidenciarse las equivalencias entre capas de un modelo a otro:

CAPAS DEL MODELO OSI

CAPAS DEL MODELO TCP/IP

Capa de aplicación Capa de aplicación Capa de presentación Capa de sesión Capa de transporte Capa de transporte Capa de red Capa de red (Internet) Capa de enlace de datos Capa de acceso al medio Capa física Tabla 2. Comparativa entre capas de modelo OSI y modelo TCP/IP.

2.3.4 Protocolos de comunicación en la industria

La comunicación estándar y en tiempo real es necesaria para tener un buen rendimiento al aplicar el IoT, los protocolos de comunicación dependen de la aplicación y los requisitos de la mensajería, pero no es viable estar adaptando la comunicación para cada aplicación IoT. Los protocolos más comunes son MQTT, CoAP, AMQP y HTTP (Naik N. , 2017). Los protocolos de comunicación, además, deben ser seguros para transportar la información y evitar ataques maliciosos. Existen formas estandarizadas de transmitir la comunicación y organismos que se encargan de esto como IEEE e IETF, y alianzas industriales, como NFC Forum, ZigBee Alliance, Thread Group y LoRa Alliance (Dragomir, 2016).

Otros protocolos conocidos de comunicación, también usados en aplicaciones IoT, son el protocolo de Internet versión 6 (IPv6), ZigBee, Bluetooth de baja energía (BLE), Z-Wave, Near Field Communication (NFC), SigFox y Cellular (Al-Sarawi S. A., 2017). Cabe destacar que los protocolos de comunicación están en constante evolución, pues las necesidades de la industria varían con el paso del tiempo. Algunos

de los protocolos más recientes se han diseñado a partir de las demandas de interconexión en distintos equipos, y para el IoT, al ser un concepto relativamente nuevo y en auge, estas demandas o requerimientos se actualizan y acoplan a los entornos en que sean aplicadas. Su utilidad en la industria, sin embargo, no disminuye, por lo que su estudio es altamente necesario. A continuación, se definirán los protocolos más usados en la industria por factores entre los que se encuentran su facilidad de aplicación, su consumo de energía y su flexibilidad.

• MQTT (Message Queing Telemetry Transport): Es un protocolo de

comunicación M2M creado por el Dr. Andy Stanford-Clark y Arlen Nipper (Stanford-Clark, Truong, & Hunkeler, 2008), pensado como un mecanismo que permitiera conectar dispositivos de la industria petrolera. Este protocolo se basa en el modelo “Publish/Subscribe”, catalogado así porque el emisor no remite un mensaje para un receptor en específico, sino que lo envía a algún servidor que se encarga de caracterizarlo por medio de una clase; de esta manera, el suscriptor puede interesarse por una o más clases y recibir solo información de su interés. Por lo anterior, no hay una relación directa e individual entre un emisor y receptor del mensaje, sino que se comparte la información de manera generalizada para aquellas personas que así lo deseen (Fidler, Jacobsen, Li, & Mankovski, 2005). Cabe destacar que este protocolo permite jerarquizar la información, es decir, la información obtenida por un usuario acerca de determinada clase puede ser tan general o tan específica como este lo desee; de esta forma, el suscriptor no tendrá que recibir toda la información acerca de la clase de su interés, sino solo aquella que le es más relevante para su tarea. Este protocolo ofrece además diversos parámetros que permiten al usuario realizar acciones como suscripción, retorno, limpiar sesión o continuar en ella, indicar la calidad del servicio, cancelar suscripción, entre otros. Es un protocolo binario usado a menudo en IoT gracias a que es un protocolo muy liviano que permite un óptimo funcionamiento. En cuanto a la seguridad, el protocolo MQTT provee usuario y contraseña para la autenticación de sus clientes, además de otras características que son implementadas dependiendo del servidor o bróker; una limitación, sin embargo, es la no priorización de los mensajes o la información recibida, por lo que el cliente o usuario debe enviar los mensajes en orden de importancia para que estos sean

recibidos de la misma manera. A pesar de esto, por su simplicidad y ligereza, el protocolo MQTT se ha convertido en uno de los protocolos de comunicación más usados en diversos entornos y campos vinculados con el IoT (Soni & Makwana,

2017).

• CoAP (Constrained Application Protocol): Es un protocolo de aplicación creado

con el fin de transportar el modelo HTTP a dispositivos y redes restrictivas. Este protocolo cumple con los requerimientos M2M para entornos limitados (Bormann, Castellani, & Shelby, 2012). Su funcionamiento comparte muchas similitudes con el protocolo HTTP (HyperText Transfer Protocol); la diferencia radica en que este último presenta deficiencias a la hora de ser implementado de máquina a máquina, pues es relativamente costoso y de difícil funcionamiento en dispositivos pequeños (por el gran peso que le generan sus características, que se han ido incrementando con el paso de los años). En entornos reducidos, son solo necesarios ciertos parámetros de funcionamiento y no todos los elementos extra que el protocolo HTTP posee. El protocolo CoAP está basado, al igual que HTTP, en la arquitectura REST (Representational State Transfer) que dispone la información como recursos identificados por URIs (Uniform Resource Identifier); esto le permite ser usado como un protocolo de transferencia que ofrece los diseños básicos de los mismos con un diseño más minimalista que le permite ser mucho más liviano; característica que es esencial en los protocolos de comunicación que involucran dispositivos pequeños o con ciertos tipos de limitaciones en su conectividad. CoAP opera con un modelo Request/Response (Cliente/Servidor), en él los clientes solicitan y los servidores ofrecen; el protocolo se encarga de unir correctamente la solicitud específica del cliente con una de las ofertas realizadas por el servidor por medio de mensajes en código binario; cabe destacar que una de las funciones ofrecidas por este protocolo le permite al cliente recibir y visualizar los cambios de la información o recurso solicitados al servidor previamente, algo que facilita la captación de estos recursos (Arvind & Anantha Narayanan, 2019).

• AMQP (Advanced Message Queing Protocol): Es un protocolo liviano M2M

diseñado por John O’Hara en Londres (Reino Unido) para el año 2003. Este protocolo pretende ofrecer buenas funciones de seguridad e interoperabilidad con un peso muy ligero (Naik N. , 2017). Este protocolo soporta los modelos Publish/Suscribe y Request/Response; el AMQP requiere que tanto el cliente como el servidor hagan un intercambio por medio de un nombre establecido, con este nombre, el cliente puede descubrir ofertantes y viceversa. Es un protocolo binario que soporta desde pequeñas hasta grandes cargas útiles en sus mensajes dependiendo de factores como el bróker (o servidor) o de la tecnología de programación; además de esto, los mensajes son almacenados hasta que se envían al receptor. Sus características le permiten manejar y comunicar mensajes de diversa complejidad (Bezerra, Roque Aschoff, Szabo, & Hadj Sadok, 2018). Actualmente este protocolo es usado en entornos financieros y comerciales, gracias a la gran escalabilidad que proporciona; soporta además distintos lenguajes de programación y funciona en distintas clases de dispositivos. El AMQP es un protocolo que brinda alta seguridad en la protección de información y transmisión de mensajes, teniendo en cuenta posibles fallas o interrupciones en la conexión; sin embargo, la eficacia de este protocolo es discutida en entornos limitados y aplicaciones en tiempo real, puesto que, a pesar de ser liviano, presenta dificultades en el soporte de dispositivos reducidos (pudiendo deberse a la amplia gama de opciones que permite en la carga útil de sus mensajes) (Yassein & Shatnawi, 2016).

• HTTP (Hypertext Transfer Protocol): Es un protocolo de transferencia usado en

sistemas de distribución de información; este ha sido utilizado por la red global WWW (World-Wide Web) desde el año 1990 para captar, transferir y difundir información de diversos entornos (Fielding, y otros, 1999). Este protocolo funciona muy bien en diversos entornos; sin embargo, presenta limitaciones cuando se aplica a dispositivos reducidos en parámetros como procesamiento, consumo eléctrico o memoria; ya que los sistemas IoT requieren un desempeño óptimo en entornos limitados, este protocolo no es de los más utilizados, aunque algunas de sus mejores características fueron tomadas para el diseño de nuevos protocolos mucho más sencillos y livianos que cumplieran con el requisito anteriormente mencionado. Entre

estos protocolos, el más destacado en cuanto a similitud con HTTP es el protocolo CoAP, comúnmente utilizado en sistemas IoT (Aizuddin Daud & Haji Suhaili, 2016).

• IPv6 (Internet Protocol version 6): Este protocolo es una versión o generación

mejorada del anterior IP (Internet Protocol), este último era usado eficazmente hasta que el crecimiento del Internet se magnificó y globalizó; de esta manera, el protocolo se tornó obsoleto al no cumplir con los requerimientos de la comunicación de redes, estos requerimientos eran, entre otros, el soporte de tráfico en la red en tiempo real, la flexibilización y el control de la congestión de redes, y características de seguridad (Stallings, IPv6: the new internet protocol, 1996). En el Internet de las Cosas, este protocolo también se ha hecho presente, buscando que todo dispositivo que cuente con la posibilidad de acceder a internet, se encuentre conectado a la red y de esta forma capte y comparta información con otros dispositivos o elementos que también se encuentren vinculados a la red, sin importar su localización. La implementación de este protocolo al IoT es considerada positivamente ya que cuenta con la respuesta a varios requisitos de estos sistemas, entre los que se encuentran la escalabilidad e interoperabilidad ofrecida por el protocolo de comunicación; este es valorado además por su capacidad de adaptación a los cambios frecuentes del entorno (Dunkels, y otros, 2012).

• HART (Highway Addressable Remote Transducer): Es un protocolo creado en

la década de los ochenta en el que se incluyen dos canales de comunicación; analógico y digital; donde la señal que contiene la información recibida por el servidor, a través de dispositivos digitales y por ende digital, es codificada y superpuesta en una señal analógica que es interpretada por este. El protocolo HART actualmente abierto (pocos años después de su creación pasó de ser de propietario a abierto) es normalmente usado en sistemas de control aplicando la configuración remota de distintos dispositivos. Los dispositivos son conectados mediante un lazo de corriente 4-20 Ma para ser configurados bajo distintos parámetros. Para este protocolo pueden ser implementados métodos que permitan realizar un control de procesos a dispositivos inalámbricos; esto a través de la asociación de una dirección única mediante un esquema de direccionamiento del protocolo cableado a cada uno de los dispositivos

inalámbricos que operan en el entorno, formando así una red inalámbrica (US Patente nº 8,570,922, 2013).

• Modbus: Es un protocolo de comunicación abierto creado por Modicon

(actualmente Schneider Electric) para la década de los setenta y con el fin de posibilitar la comunicación entre PCLs (controladores lógicos programables). Debido a que su uso está libre de derechos, es comúnmente utilizado por fabricantes para sus equipos o dispositivos, ya que no están sujetos a pagar derechos de autor (Aula21, s.f.). Este protocolo de comunicación es usado para transmitir señales e información desde los dispositivos de control hasta un sistema de recolección de datos (SCADA

– Supervisory Control and Data Acquisition). El protocolo Modbus usa un modelo

Maestro / Esclavo (Master / Slave) para controlar el acceso a la línea de conexión compartida y prevenir las colisiones de mensajes. La comunicación es iniciada por el dispositivo maestro o controlador, el cual le transmite sus requerimientos al dispositivo esclavo; este se encarga de acceder al bus y captar la información que transmitirá como respuesta al dispositivo maestro. Es importante recalcar que los dispositivos esclavos no pueden comunicarse entre ellos ni transmitir información a menos de que esta sea solicitada por el dispositivo maestro; este último, sin embargo, sí puede comunicarse con varios dispositivos esclavos de forma simultánea y realizar de esta manera varias solicitudes (Dutertre, 2007). Existen distintas versiones del protocolo Modbus (entre ellas Modbus RTU, Modbus TCP, Modbus ASCII y Modbus Plus), la utilización de una en particular dependerá de las especificaciones contenidas en el sistema industrial que aplicará el protocolo.

• DeviceNet: Es un protocolo abierto desarrollado por la compañía estadounidense

Allen-Bradley que funciona por medio de Bus CAN (Controller Area Network), un protocolo de comunicación basado en la transmisión de datos mediante el modelo de bus, esto con el fin de contar con un protocolo de bajo costo que posibilite la comunicación entre diferentes dispositivos y equipos industriales (Noonen, Siegel, & Maloney, 1994). A diferencia de otros protocolos (en los que el cliente no puede llevar a cabo tareas de priorización en sus mensajes), DeviceNet permite especificar la prioridad del mensaje a transportar por medio del campo de arbitraje destinado en

sus bits; esto garantiza un adecuado control en el retardo de la transmisión de los mensajes con mayor prioridad (Lian, Moyne, & Tilbury, 2001). Este protocolo, sin embargo, cuenta con ciertas limitaciones entre las que se encuentra la baja velocidad en transmisiones de datos; además, el contenido de los mensajes se encuentra estrechamente limitado, desventaja que solo puede sortearse mediante la fragmentación del mensaje. Al igual que Modbus, DeviceNet opera con la arquitectura Maestro / Esclavo, y permite el intercambio de dispositivos mientras la red se encuentra funcionando; esto por medio de la funcionalidad QuickConnect (company, s.f.)

• ZigBee: Es un conjunto de protocolos de comunicación establecido en los inicios

de los 2000 y oficialmente nombrado en el año 2001, este ha permitido la conexión inalámbrica de más de 64.000 dispositivos a una misma red y funciona con una arquitectura basada en el modelo de interconexión de sistemas abiertos OSI (Open System Interconnection); es usado en campos tanto industriales como comerciales por su simplicidad en el manejo y su capacidad de funcionamiento en dispositivos que requieran un bajo consumo eléctrico y que tengan ciertas limitaciones en cuanto a la banda ancha, además, su costo es relativamente bajo para los beneficios que ofrece a sus consumidores (Ashok Somani & Patel, 2012) Su capa física (construida bajo el estándar IEEE 802.15.4) se encuentra cercana al hardware, y es esta la que desarrolla tareas que dan acceso al mismo; entre estas tareas se encuentran las siguientes: inicialización del hardware, selección del canal, estimación de la calidad de conexión, medición en la detección de energía y evaluación clara del canal para seleccionar el que mejor se acople a las necesidades del consumidor (Muthu Ramya, Shanmugaraj, & Prabakaran, 2011). Su limitada velocidad en la transmisión de datos, hace apto a este conjunto de protocolos para ser utilizado en aplicaciones que no requieran altas especificaciones; de lo contrario, este conjunto no brinda un funcionamiento adecuado y sería conveniente decantarse por otro protocolo de comunicación que sí cumpla estos requerimientos.

• Bluetooth de baja energía – BLE (Bluetooth Low Energy): Es un protocolo de

comunicación basado en el protocolo Bluetooth ya existente, pero adaptado para que el consumo de energía durante la transferencia de datos sea mucho más bajo que el de su antecesor. El protocolo de comunicación Bluetooth había sido una gran mejora tecnológica al desaparecer la necesidad de una conexión por cables entre dispositivos o el requerimiento de alta cercanía entre los mismos para transferir cualquier tipo de información; sin embargo, el IoT ha afirmado la necesidad de reducir el consumo de energía en sus dispositivos y permitir que los mismos se encuentren interconectados aún bajo condiciones muy restrictivas como una limitación en su banda ancha. Es allí donde aparece esta variante del Bluetooth habitual, el protocolo Bluetooth Low Energy, trabajando bajo estas limitaciones y ofreciendo la interconexión entre pequeños dispositivos. Cabe destacar que estos protocolos presentan diferencias considerables entre ellos, entre las que se encuentra el tipo de comunicación que ofrecen: mientras que el Bluetooth clásico permite una comunicación entre un dispositivo y otro, el BLE permite una entre un dispositivo y muchos otros; esto por medio de un elemento conocido como Beacon (este dispositivo de transmisión de tamaño pequeño puede transmitir información o datos a distintos dispositivos mediante un código de identificación para cada uno de ellos; de esta manera, se asegura de que la seguridad de los dispositivos se encuentre protegida y que la información deseada llegue a su destino confiablemente. Esta comunicación es unilateral, es decir, solo el Beacon puede transferir información a los dispositivos conectados con él por medio de Bluetooth de bajo consumo; estos serán receptores más nunca emisores) (Jeon, She, Soonsawad, & Chet Ng, 2018).

• Z-Wave: Este protocolo de comunicación inalámbrica es comúnmente utilizado

para la automatización de hogares y de distintos establecimientos, ya que permite la interconexión de dispositivos por medio de las ondas de radio viajando a través de su red en malla. Al igual que otros protocolos, Z-Wave permite la comunicación entre dispositivos con un bajo costo energético y el rango de alcance de la conexión es mucho mayor que el de otras redes. La comunicación se da por medio de una arquitectura Controlador / Esclavo; es decir, un dispositivo será el encargado de enviar los requerimientos a los dispositivos esclavos, estos solo podrán ejecutar los

comandos necesarios para cumplir con estos requerimientos y responder con mensajes a los mismos, pero no podrán iniciar la transmisión de mensajes ni la comunicación entre ellos sin que esto seas requerido por el dispositivo controlador (Al-Sarawi, Anbar, Alleyan, & Alzubaidi, 2017), esto buscando mantener un bajo consumo de energía y un óptimo rendimiento en cuanto a comunicación. La seguridad, sin embargo, ha sido uno de los problemas más grandes para este protocolo, ya que sus primeras versiones lo dejaban expuesto a múltiples ataques en la red (como era común en los primeros protocolos de red inalámbrica) (Badenhop, Graham, Ramsey, Mullins, & Maillowx, 2017).

• Near Field Communication (NFC): Este protocolo de comunicación fue

desarrollado durante el año 2002 por Philips y Sony, con el fin de permitir, como tantos otros protocolos, la comunicación entre varios dispositivos de manera remota y bajo pautas seguras y de fácil aplicación. A pesar de que el protocolo cumple con uno de los requisitos más solicitados en el Internet de las Cosas, que es el bajo consumo de energía y la interconectividad limitada en dispositivos pequeños, el rango de alcance de la red es bastante limitado al compararlo con otros protocolos de comunicación, los cuales pueden operar con dispositivos que se encuentran a metros de distancia, mientras NFC solo puede enlazar dispositivos que se encuentren ubicados a centímetros uno del otro; aun así, es un protocolo altamente flexible y personalizable, en el que el usuario puede adaptar ciertas opciones a la aplicación que desee (Coskun, Ozdenizci, & Ok, 2013). El protocolo permite a los dispositivos conectados establecer dos modos de comunicación: el primero es el modo activo, en el que los dos dispositivos establecen una comunicación bidireccional, por lo que ambos podrán intercambiar información son limitaciones; el segundo modo es conocido como pasivo, ya que solo uno de los dispositivos podrá transmitir información al otro (este último se limitará a ser el receptor de la comunicación). Para evitar que la información compartida por medio de este protocolo pueda ser visualizada, robada o alterada por terceros, NFC hace uso de un entorno protegido; se trata de la memoria del elemento seguro (Secure Element - SE), este conjunto de hardware, software y diversas interfaces y protocolos permite garantizar al usuario

protección a su información y un almacenamiento seguro (Nelson, Qiao, & Carpenter,

2013).

• SigFox: Este protocolo de comunicación, cuya tecnología pertenece a las redes

LPWAN (Low Power Wide Area Networks) que ha sido comúnmente empleada en redes IoT; básicamente, este protocolo es capaz de comunicar o transmitir datos con un rango de velocidad aceptable y un consumo de energía muy por debajo de la media, es decir, al compararlo con otros protocolos, optimizando de esta forma los costos a la hora de su aplicación; sin embargo, los mensajes transmitidos no pueden tener un gran tamaño (Lavric, Petrariu, & Popa, 2019). Su conectividad hace uso de una infraestructura propia, constituida por antenas y estaciones de base, cabe destacar que las mismas son totalmente independientes de la infraestructura utilizada por redes móviles, Wifi, entre otras ya conocidas. No obstante, este protocolo no ha podido ser implementado en todos los dispositivos conectados a IoT, por lo que no sería efectivo para algunos; con los dispositivos compatibles, la única variación necesaria para implementar en ellos este protocolo es la implantación de un chip propio. Entre las ventajas ofrecidas por este protocolo se encuentran: eficiencia energética (que conlleva en el alargamiento de vida útil en la batería de ciertos dispositivos), uso de frecuencias libres (lo que lo hace resistente a las interferencias), es un protocolo abierto (por lo que se evitará la solicitud de permisos y demás trámites legales para su uso), control de la totalidad de dispositivos conectados a la red basada en la gestión de datos sencilla y almacenamiento en la nube (Cabello, 2016).

2.3.5 Plataformas IoT

Las plataformas IoT permiten recibir, almacenar, analizar y visualizar datos. Algunos softwares son ThinkSpeak, Altair SmartCore, Electric Imp, Spark Works, Blaulabs, Thinking things, Zatar, Amazon Web Services IoT, Azure IoT Hub, Oracle Internet of Things, Watson IoT, Xively – Google Cloud IoT, Samsung Artik, Adafruit IO, Ubidot, My Devices Cayenne y Macchina IO. En cuestión de hardware, algunos utilizados en IoT son Raspberry Pi, Arduino, Waspmote, Spark (Apache Spark), Intel Galileo y Zigbee (Martínez Moreno, 2019).

METODOLOGÍA

2.4 Elección de protocolos de comunicación

La lista de protocolos de comunicación es bastante amplia y variada, todos ellos ofreciendo cierto tipo de ventajas y, como no puede ser de otra manera, con ciertas limitaciones que el usuario debe tener en cuenta a la hora de escoger el protocolo que más se ajuste a sus necesidades. Es importante que, a la hora de implementar un protocolo de comunicación en el diseño de alguna operación con un dispositivo y su posterior interconexión con otros, el usuario tenga presente si este dispositivo cuenta con algún protocolo de base, es decir, existen algunos dispositivos en los que los protocolos implementados no son abiertos sino de propietario (la implementación de protocolos abiertos en este tipo de dispositivos generará problemas a la hora de realizar la conexión mediante redes con otros equipos); si es el caso, el usuario deberá trabajar con estos protocolos (de propietario), conociendo de manera clara su funcionamiento y realizando transferencia de datos con equipos o dispositivos que manejen este mismo protocolo, sin olvidar solicitar los permisos pertinentes para su uso en caso de ser necesario. Por otra parte, si se cuenta con la libertad de escoger el protocolo acorde para el dispositivo, o si el dispositivo será diseñado enteramente por el usuario, este último podrá acceder a los protocolos abiertos de comunicación; entre todos los ofrecidos, el usuario deberá evaluar sus características. y tener claro qué es lo que busca en su dispositivo y cuáles son las especificaciones de conexión que desea. Para conocer las características de estos protocolos de comunicación, es necesario conocer las capas en las que estos operan y las especificaciones de ellas en los mismos; por ejemplo, existen protocolos que manejan todas las capas del modelo OSI, mientras que otros solo operan en las capas superiores (conocidas como capas de aplicación) o en las inferiores (conocidas como capas de transporte). Teniendo esto en cuenta, el usuario podrá elegir a conveniencia el protocolo de comunicación que requiera (basándose no solo en las opiniones de terceros frente a cuál es el mejor, sino en las ventajas que este le ofrece tanto en velocidad como en consumo eléctrico, costos y otros factores).

3.2 Características en las capas de los protocolos de comunicación

Como se mencionó anteriormente, es importante conocer las características de los protocolos de comunicación basados en las capas en las que estos operan, para tener así un mejor panorama a la hora de elegir el más conveniente. A continuación, se presentan los protocolos de comunicación más utilizados en la industria para dispositivos IoT y sus características, ventajas y limitaciones.

3.2.1. MQTT

Este protocolo es ampliamente utilizado en las industrias automotriz, petrolera y de telecomunicaciones; aunque por su facilidad, puede ser utilizado por cualquier usuario que desee conectar su dispositivo con otros IoT. Ofrece una gran escalabilidad, además de seguridad a la hora de enviar y recibir mensajes (ofrece tres niveles de calidad de servicio: 0, at most once, en la que el mensaje es enviado a lo sumo una vez, puede ser usado en conexiones en las que la pérdida de un mensaje no altere significativamente el funcionamiento de la operación; 1, at least once, en la que el mensaje es enviado al menos una vez, en este nivel se asegura la entrega de todos los mensajes, aunque no se garantiza ausencia de duplicidad en los mensajes; 2, exactly once, en la que se garantiza que los mensajes sean enviados una única vez, utilizado sobre todo en operaciones de pago, en las que los otros dos niveles representarían un gran problema). Este protocolo, sin embargo, no opera en todas las capas del modelo OSI, sino que se limita a las capas de aplicación, por lo que debe ser apoyado por un protocolo como TCP e IP en las capas inferiores (para la capa de transporte y la capa de red respectivamente). A continuación, se presentan las características del protocolo MQTT.

Especificaciones Protocolo MQTT Año de creación

1999

Arquitectura Publicación / Suscripción Tamaño del encabezado

2 Bytes

Tamaño del mensaje Corto (con un tamaño de 256 MB máximo) Semántica Conectar, desconectar, publicar, suscribirse, cancelar suscripción, cerrar.

Calidad del servicio (Quality of Service) QoS 0 - At most once QoS 1 – At least once QoS 2 – Exactly once Protocolo para capas de transporte

TCP, UDP.

Protocolo para capa de red IP Formato de codificación Binario Estado de licencia Abierta Consumo eléctrico Bajo Ancho de banda Bajo Tabla 3. Especificaciones del protocolo MQTT. (Naik N. , 2017)

3.2.2. CoAP

Este protocolo es similar en varias características al protocolo MQTT; al igual que el anterior, este solo puede operar en las capas de aplicación y necesita de un protocolo base para las capas inferiores (tanto para la capa de transporte como para la capa de red). Algo muy valioso en este protocolo es que puede soportar diversos formatos de datos (al igual que HTTP) entre los que se encuentran XML, JSON, CBOR, entre otros. Este protocolo es usado comúnmente por su bajo consumo de energía y su capacidad de operación bajo anchos de banda bastante limitados; es, por ejemplo, usado en aplicaciones móviles y otros dispositivos (como sensores) que requieran una conexión inalámbrica. Se pueden presentar dos tipos de mensajes para acciones de petición (Request) y otros dos para acciones de respuesta (Response). Para las peticiones o requerimientos se presentan los siguientes mensajes: 0, confirmable, que espera un nuevo mensaje de confirmación; 1, non-confirmable, que no espera ninguna

confirmación mediante un nuevo mensaje. Para las respuestas se presentan los siguientes mensjaes: 2, acknowledgement, que es la respuesta de reconocimiento a un mensaje que requiere confirmación; 3, reset, que indica que el mensaje pendiente de confirmación fue recibido por el servidor, pero que este no pudo ser procesado y por lo tanto procesado. Cabe resaltar que este protocolo es muy semejante al HTTP, solo que está diseñado para operar bajo condiciones más limitantes en cuanto a consumo de energía, ancho de banda e interoperabilidad, características muy aconsejables en protocolos aplicados a dispositivos que deseen ser vinculados al Internet de las Cosas (IoT)A continuación, se presentan las características del protocolo de comunicación CoAP.

Especificaciones Protocolo CoAP Año de creación

2010

Arquitectura Requerimiento / Respuesta (Request / Response) Tamaño del encabezado

4 Bytes

Tamaño del mensaje Corto (con el tamaño máximo permitido por el protocolo de red IP) Semántica Obtener, postear, colocar, eliminar, cerrar.

Calidad del servicio (Quality of Service)

0 – Confirmable message

1 – Non.confirmable message

2 – Acknowledgement

3 - Reset

Protocolo para capas de transporte

UDP, SCTP

Protocolo para capa de red IP Formato de codificación Binario Estado de licencia Abierta Consumo eléctrico Muy bajo Ancho de banda Muy bajo Tabla 4. Especificaciones del protocolo CoAP. (Naik N. , 2017)

3.2.3. AMQP

La creación de este protocolo de comunicación fue pensada por una compañía

estadounidense del sector financiero (JPMorgan Chase); lo que buscaban era crear un

protocolo que optimizara al máximo el tiempo, puesto que las operaciones financieras

requieren de este para tener éxito, Se buscaba además contar con un protocolo que

permitiera los mensajes en cola, de esta manera los dispositivos de requerimiento y

respuesta no deberían actuar a la misma velocidad (podrían recibir mensajes y

archivarlos para contestarlos uno por uno sin perder la oportunidad de recibir nuevas

peticiones). Este protocolo también permite diversos lenguajes de programación y

esto permite que distintos dispositivos puedan conectarse a la red deseada, por medio

de este protocolo, sin ningún problema (nivel aceptable de interoperabilidad). Como se mencionó previamente, y siendo este el motivo central de la creación de este

protocolo, la velocidad de transmisión de datos en AMQP es muy alta, pero esto

implica que su consumo de energía y el ancho de banda requerido para la misma sea

más alto. A continuación, se presentan las características del protocolo de

comunicación AMQP.

Especificaciones Protocolo AMQP Año de creación

2003

Arquitectura Publicación/Suscripción (Publish/Response); Requerimiento/Respuesta (Request/Response) Tamaño del encabezado

8 Bytes

Tamaño del mensaje Según los requerimientos del usuario (no tiene un tamaño definido) Semántica Consumir, entregar, publicar, obtener, seleccionar, reconocer, eliminar, no reconocer, recuperar, rechazar, abrir, cerrar.

Calidad del servicio (Quality of Service)

0 – Settle format (Como máximo una

vez)

1 – Unsettle format (Exactamente una

vez) Protocolo para capas de transporte

TCP, SCTP

Protocolo para capa de red IP Formato de codificación Binario Estado de licencia Abierta Consumo eléctrico Medio-alto Ancho de banda Medio-alto Tabla 5. Especificaciones del protocolo AMQP. (Naik N. , 2017)

3.2.4. HTTP

Ester protocolo se base en una arquitectura cliente / servidor, en la que el primero solicita cierta información o acción, y el segundo entrega una respuesta a esta solicitud (ya sea favorable o negativa), por eso es el protocolo estrella de la web. Este protocolo, sin embargo, representa un incremento considerable en el consumo de energía y en el ancho de banda utilizado; por eso no es común su uso en dispositivos y conexiones IoT, y se prefiere optar por otros protocolos como CoAP (que brinda la mayoría de los beneficios ofrecidos por HTTP, consumiendo poca energía y con un ancho de banda limitado). Al igual que otros protocolos de comunicación, HTTP necesita de protocolos base para las capas del modelo OSI por debajo de la aplicación; de esta manera, el protocolo se apoya de un protocolo de transporte de datos y otro de red. Por lo anterior, las especificaciones de conectividad son delimitadas por otros protocolos, aunque este maneje cierta independencia al ser implementado en la capa correspondiente (capa de aplicación). Es un protocolo de uso sencillo pero pesado como se mencionó anteriormente, aunque es importante tomarlo en consideración cuando uno de los aspectos principales que busque el usuario en la transferencia de e intercambio de datos (o información) sea la interoperabilidad; de hecho, su nivel de interoperabilidad es el más alto comparándolo con los protocolos anteriormente

mencionados. A continuación, se presentan las características del protocolo de comunicación HTTP.

Especificaciones Protocolo HTTP Año de creación

1997

Arquitectura Cliente/Servidor (Client/Server); Requerimiento/Respuesta (Request/Response) Tamaño del encabezado Indefinido Tamaño del mensaje Largo y establecido por el servidor web o la tecnología de programación (no tiene un tamaño definido) Semántica Obtener, postear, encabezar, colocar, organizar conexiones, gestionar opciones, conectar, eliminar Calidad del servicio (Quality of Service) La calidad del servicio está delimitada por el protocolo de transporte usado en las capas inferiores; es decir, no se cuenta con autonomía para precisar u ofertar una calidad de servicio determinada. Protocolo para capas de transporte

TCP

Protocolo para capa de red IP Formato de codificación Binario Estado de licencia Abierta Consumo eléctrico Muy alto Ancho de banda Muy alto Tabla 6. Especificaciones del protocolo HTTP. (Naik N. , 2017)

3.2.5. HART

Este protocolo, a diferencia de los anteriores, opera en distintas capas del modelo OSI, entre las que se encuentran la capa física, la capa de enlace de datos, la de red, la de transporte de datos y la de aplicación (capas 1, 2, 3, 4 y 7). Este protocolo está basado en el estándar de comunicación telefónica Bell 202 y funciona con un enlace de datos basado en la arquitectura maestro/esclavo; en esta, los dispositivos maestros se valen de señales de voltaje para la comunicación, mientras los dispositivos esclavos hacen uso de señales de corriente para formar parte de esta misma comunicación, para la interacción de estas dos señales, es necesario realizar en ellas una conversión, esto se lleva a cabo por medio de una resistencia de carga que es implementada durante la conexión (esto quiere decir que el protocolo permite superponer las señales para realizar una lectura adecuada de las mismas). La conexión entre dispositivos puede llevarse a cabo de dos maneras: la primera es punto a punto, en la que la conexión permite únicamente la comunicación entre un maestro y un esclavo; está también la conexión multipunto, en la que se permite la interacción o comunicación entre un maestro y múltiples esclavos. El dispositivo maestro genera una petición mediante un mensaje digital que, después de ser procesado y convertido a un mensaje analógico, es interpretado por el dispositivo esclavo; finalmente, el dispositivo maestro extrae el mensaje de la señal analógica y lo procesa (si el mensaje fue una respuesta correcta a su requerimiento, la conexión se da por terminada en caso de que no se requiera algo adicional; si, por el contrario, la petición no fue solucionada exitosamente, se hará un nuevo requerimiento al dispositivo esclavo). Este protocolo HART no estaba diseñado para ser inalámbrico; sin embargo, y dado el crecimiento de la industria tecnológica, las conexiones debían hacerse entre dispositivos que se encontraban cada vez más lejanos; buscando optimizar las conexiones, y no perder competitividad frente a otros tipos de protocolos, HART diseñó una variable inalámbrica conocida como “WirelessHART”, este puede ser aplicado a dispositivos ya vinculados con el protocolo HART previo solo por medio de un adaptador; de esta manera, puede ser aplicado en distintos campos de la industria siendo elegido por su facilidad de manejo y por lo extendido que el protocolo HART (en su versión previa) se encontraba en

ciertos dispositivos. A continuación, se presentan las características del protocolo de comunicación HART.

Especificaciones Protocolo HART Año de creación Desde la década de los 80 Arquitectura Maestro/Esclavo (Master/Slave) Intervalo de la señal 4-20 mA Opciones de conexión Punto a punto (un maestro y un esclavo) Multipunto (un maestro y múltiples esclavos) Capa física Opera en frecuencias de señal de 1200 Hz y 2200 Hz (que representan un 1 y un 0 binario respectivamente) Capa de enlace de datos Definición de arquitectura maestro/Esclavo, en la que se pueden hacer dos tipos de conexiones. En la conexión multipunto, pueden enlazarse hasta 15 dispositivos.

Protocolo para capas de transporte Él mismo (Protocolo

HART),

asegurándose de que la comunicación funcione correctamente de punto a punto de la conexión.

Protocolo para capa de red Él mismo (protocolo HART) Formato de codificación Binario Estado de licencia Abierta Consumo eléctrico Bajo Ancho de banda Alto Tabla 7. Especificaciones del protocolo HART.

Es importante destacar que existe una nueva versión del protocolo Hart. En ella, la conexión es inalámbrica, lo que optimiza la comunicación entre los dispositivos. Aunque guarda muchas similitudes con su antecesor, la nueva versión del protocolo, conocida como Wireless Hart (implementada en 2007), opera mediante las estaciones radiales por una red de malla plana. Cada estación representa una red, por lo que la información es enviada desde la red de origen hasta su vecina más próxima, que la reenvía a la siguiente. Lo anterior representa la posibilidad de brindar mayor cobertura a menor costo, por lo que es uno de los protocolos con el rango de alcance más amplio en la industria.

3.2.6. Modbus.

Este protocolo de comunicación implementado por Modicon (actualmente Schneider Electric) en la década de los setenta, al igual que el protocolo anterior, opera en distintas capas del modelo OSI; entre estas se encuentran las capas 1, 2 y 7 (capa física, capa de enlace de datos y capa de aplicación respectivamente), lo que le brinda cierta autonomía. Siendo uno de los protocolos más antiguos en la industria, Modbus ha sido implementado en diversos dispositivos y para diversas conexiones a lo largo de los años. Las principales razones para su uso son su diseño (pues fue pensado especialmente para aplicaciones industriales), la facilidad de manejo en los dispositivos vinculados a él, y que su licencia es pública y gratuita, es decir, cualquiera puede acceder a él e implementarlo sin solicitar permisos u otro tipo de autorizaciones. Como el protocolo HART, Modbus fue diseñado con una arquitectura Maestro/Esclavo, o con una arquitectura Cliente/Servidor. A cada dispositivo se le asigna una dirección única; la solicitud realizada por el dispositivo maestro contiene la dirección del dispositivo esclavo que debe ejecutarla; por lo tanto, a pesar de que todos los dispositivos esclavos reciben el mensaje, solo el dispositivo esclavo escogido puede llevar a cabo la ejecución y transferir un mensaje de respuesta al dispositivo maestro. A diferencia de otros protocolos que implementan la arquitectura Maestro/Esclavo, en el protocolo Modbus pueden vincularse a la conexión hasta 247 dispositivos esclavos, los cuales pueden interactuar con el dispositivo maestro de la manera mencionada anteriormente (esto evidencia un soporte de gran cantidad de

dispositivos, pero hace que la conexión sea un poco más pesada). Existen diferentes versiones de Modbus, cada una ofreciendo ciertas especificaciones que el usuario deberá considerar a la hora de elegir la que más se ajuste a sus necesidades de conexión y de transferencia de datos. Algunas de las versiones de este protocolo no pueden implementarse en todas las capas del modelo OSI, por lo que debe implementarse un protocolo como IP O TCP para las capas inferiores (como la capa de red y la capa de transporte). A continuación, se presentan las especificaciones del protocolo Modbus.

Especificaciones Protocolo Modbus Año de creación

1979

Arquitectura Cliente/Servidor (Client/Server); Maestro/Esclavo (Master/Slave) Versiones del protocolo Modbus Modbus RTU, Modbus ASCII, Modbus TCP/IP, Modbus sobre UDP, Modbus Plus, Pemex Modbus, Enron Modbus Tamaño del mensaje Largo y establecido por el servidor web o la tecnología de programación (no tiene un tamaño definido) Formato de la trama Encabezado (que contiene la dirección del dispositivo esclavo que deberá realizar la acción), datos del mensaje (cuyo tamaño dependerá de su tipo) y cola (en la que se realiza la comprobación de errores) Número límite de dispositivos vinculados Pueden estar vinculados

254

dispositivos como máximo, a excepción de las versiones del protocolo que usen protocolos de base como TCP e IP, en cuyo caso, el limite estará estipulado por estos últimos.

Protocolo para capas de transporte

TCP

Protocolo para capa de red IP Formato de codificación Binario Estado de licencia Abierta Consumo eléctrico Medio Ancho de banda Medio-Alto Tabla 8. Especificaciones del protocolo Modbus.

3.2.7. IPv6

Este protocolo es una versión del protocolo de internet (IP – Internet Protocol), que es el protocolo base de las conexiones a internet; este protocolo ha tenido varias versiones, siendo IPv6 su sexta versión (las actualizaciones de este protocolo se dan porque la versión anterior se queda corta, en cuanto a alguna especificación, para realizar las conexiones con los dispositivos requeridos). Este protocolo opera en la capa de red establecida en el modelo OSI, por lo que sirve de protocolo base para distintos protocolos que operan solo en las capas superiores (como en la capa de aplicación). IP envía datos a través de paquetes que se conocen como datagramas, los cuales, basándose en la dirección (tanto de origen como de destino de los dispositivos que interactúan) que el protocolo asigna, conocida como dirección IP, viajan por medio de una de las rutas establecidas; este proceso, sin embargo, no garantiza que la información o los datos lleguen a su destino final (o que lleguen correctamente), lo que se convierte en una de las limitaciones que buscan mejorarse con cada versión. La versión de protocolo de internet anterior (IPv4) contaba con una base de direcciones de origen y destino de 32 bits, pero el crecimiento y la globalización del internet hicieron que estas posibles direcciones se agotaran y que nuevos dispositivos no pudieran vincularse (una limitación bastante considerable en un protocolo que buscaba operar en una red global); por esta razón, y teniendo en cuenta las necesidades de la época y de años futuros, se creó una nueva versión conocida como IPv6, en ella las posibles direcciones para origen y destino de los dispositivos vinculados para la transmisión de datos aumentaba de 32 a 128 bits (Un valor mucho

más acorde para realizar conexiones globales, sobre todo en países o regiones con gran extensión o con una cantidad de población para nada despreciable). El tamaño de los datos a transmitir por este protocolo es negociable, dependiendo de la red utilizada; aunque la unidad máxima de transferencia (Maximum Transmission Unit - MUT) establece un valor límite de 64 kilobytes en este protocolo, esta limitación varía si la tecnología así lo establece. Normalmente el tamaño del paquete de datos de IP se establece en 576 bits; si los datos que deben enviarse superan este tamaño, el paquete o datagrama se dividirá en partes más pequeñas que permitan un correcto envío de los mismos, al llegar a su destino, estos son unidos nuevamente. A continuación, se presentan las características del protocolo de comunicación IP en su cuarta y sexta versión (IPv4 - IPv6 respectivamente).

Especificaciones Protocolo IPv6 Año de creación

1999

Arquitectura Cliente/Servidor (Client/Server); Requerimiento/Respuesta (Request/Response) Tamaño del encabezado

8 bits

Tamaño del mensaje Negociable (definido por la red en la que esté operando el protocolo, comúnmente paquetes de datos de 576 bits con un máximo de 64 kb) Número de dispositivos vinculados

32 bits en IPv4

128 bits en IPv6

Protocolo en capas de aplicación Existen diferentes protocolos aplicables con IP como base; entre ellos se encuentran: MQTT, CoAP, AMQP, HTTP, entre otros.

Protocolo para capas de transporte

TCP

Protocolo para capa de red Él mismo (IP) Formato de codificación Códec

Estado de licencia Abierta Consumo eléctrico Medio Ancho de banda Medio Tabla 9. Especificaciones del protocolo IP.

3.2.8. DeviceNet

Este protocolo de comunicación, producido por Allen-Bradley durante la década de los 90, es de bajo nivel de aplicación y se usa principalmente en áreas industriales como la automatización. Este protocolo permite enlazar o conectar dispositivos simples con otros de nivel superior (por ejemplo: sensores y actuadores con diversos sistemas de control). Este protocolo de comunicación opera bajo el hardware CAN (Controller Area Networking), que facilita la interacción de dispositivos a baja frecuencia y optimizando su consumo eléctrico, algo destacable en dispositivos pequeños y de manejo sencillo: su interfaz también está diseñada de esta manera, lo que lo hace una muy buena opción para este tipo de conexiones e intercambio de datos. Cada una de las redes que implementa el protocolo de comunicación DeviceNet cuenta con la posibilidad de conectar hasta 64 modos; Este tipo de conexión ofrecida por el protocolo, lo hace una buena opción por su simplicidad, además de que permite la vinculación de dispositivos de distintos fabricantes (o distintas marcas) gracias a su licencia abierta y su buen nivel de interoperabilidad. Su alimentación a través de un bus de conexiones permite dejar atrás problemas o limitaciones de conexión mediante cableado, lo que es una ventaja para su implementación en compañías industriales con varios equipos colocados no tan cerca unos de otros. La arquitectura de este protocolo es, como otros protocolos, Maestro/Esclavo; esta arquitectura puede configurarse de forma tal que se realice una conexión entre un dispositivo maestro y un único esclavo, o que el dispositivo maestro pueda comunicarse simultáneamente con múltiples dispositivos o equipos esclavos, la elección dependerá del uso que deba darle el usuario. Para las capas de aplicación, el protocolo DeviceNet hace uso de CIP (Common Industrial Protocol – protocolo de comunicación industrial), con el cual se realiza una capa de aplicación común para diferentes dispositivos vinculados a la red para mejorar los procesos de transferencia de datos incluso en dispositivos con

especificaciones muy diferentes (desde fabricante hasta niveles de alimentación). Este protocolo permite al usuario un diagnóstico del sistema y de todos los dispositivos vinculados a este, esto por medio de las configuraciones realizadas mediante la conexión a la red. Todo lo anterior lo hace un protocolo fuertemente aplicable a nivel industrial; sin embargo, en entornos que requieran limitar el consumo energético durante la conexión, y que tengan limitaciones en cuanto al ancho de banda para la misma, es aconsejable hacer uso de otros protocolos de comunicación, ya que DeviceNet ofrece una velocidad de transferencia de datos muy alta, y esto requiere que las los valores para las variables anteriormente mencionadas se incrementen considerablemente. A continuación, se presentan las características para el protocolo de comunicación DeviceNet.

Especificaciones Protocolo DeviceNet Año de creación

1994 (Allen-Bradley)

Transferencia a

ODVA

(Open DeviceNet Vendor Association) en

1995

Arquitectura Maestro/Esclavo (Master/Slave) Tipo de conexión Maestro/Esclavo Maestro/Múltiples esclavos Tamaño del encabezado Indefinido Tamaño del mensaje Largo y establecido por el servidor web o la tecnología de programación (no tiene un tamaño definido) Capa física Hace uso del estándar de comunicaciones CAN (Controller Area Networking) Capa de aplicación Hace uso del protocolo de comunicación CIP (Common Industrial protocol) Capas de transporte

CAN

Formato de codificación Binario

Estado de licencia Abierta Consumo eléctrico Muy alto Ancho de banda Muy alto Tabla 10. Especificaciones del protocolo DeviceNet.

3.2.9. Zigbee

Este protocolo de comunicaciones inalámbricas (diseñado mediante una alianza entre compañías como Samsung, Motorola, Siemens, Philips, entre otras) tiene como objetivo ofrecer a los usuarios la posibilidad de realizar un constante monitoreo y transferencia de datos entre sus dispositivos mediante una conexión lo más segura posible, intentando reducir el consumo eléctrico de la misma y optimizar recursos entre los que se encuentran los costos de diseño y operación. La licencia ofrecida por este protocolo de comunicación es abierta, por lo que cualquier usuario puede hacer uso de este para implementarlo en sus dispositivos y posibilitar así la conexión entre él y dispositivos de otros fabricantes, creando un entorno de interoperabilidad que actualmente es buscado en una industria tecnológica en constante crecimiento y desarrollo. A la hora de diseñar este protocolo, se buscó que el mismo ofreciera beneficios tanto en velocidad de transmisión de datos como en alcance de su señal. Zigbee provee un identificador de red individual a las redes vinculadas a este protocolo, lo que conlleva a que la transmisión de los datos y el acceso a la información sean enviados por diferentes rutas e incremente la confiabilidad y la seguridad de la información recibida (desde su punto de origen hasta su punto de destino). Zigbee define tres tipos de dispositivos en su conexión: coordinador, ruteador y dispositivo final; cada uno de ellos con una función o con acciones determinadas durante toda la conexión. Un dispositivo coordinador consiste en aquel dispositivo que inicia la red, almacena la información a transmitir (así como los datos de seguridad de la operación) y puede ser consultado durante toda la conexión, siendo una especie de soporte para los demás dispositivos vinculados en la comunicación. El dispositivo ruteador hace de puente entre los dispositivos, verificando que la conexión sea segura y que la información a transmitir esté correcta durante todo el viaje en la ruta establecida previamente. Finalmente, los dispositivos finales son aquellos a los

que va destinada la información, son los receptores de la misma y quienes, a partir de ella, ejecutan las acciones requeridas y por las que se estableció la conexión en primer lugar; a pesar de esto, es importante aclarar que los dispositivos finales no pueden interactuar entre sí, es decir, solo se comunican con el dispositivo coordinador y transmiten datos únicamente cuando se les solicita (logrando así una optimización de la batería en ellos). El protocolo opera en diversas capas del modelo OSI basándose en estándares previamente establecidos. Esto le permite manejar cierta independencia y optimizar su rendimiento. A continuación, se presentan las características del protocolo de comunicación Zigbee.

Especificaciones Protocolo Zigbee Año de creación

2004 (Zigbee Alliance)

Arquitectura Coordinador/Ruteador/Dispositivo Final Tipo de conexión Por medio de nodos, pudiendo alcanzar un máximo de 65535 dependiendo de la configuración de red utilizada Tamaño del encabezado Indefinido Tamaño del mensaje Largo y establecido por el servidor web o la tecnología de programación (no tiene un tamaño definido) Capa física Hace uso del estándar de comunicaciones IEEE 802.15.4 Capa de aplicación Él mismo (protocolo Zigbee) Velocidad de transmisión de datos Baja Formato de codificación Binario Estado de licencia Abierta Consumo eléctrico Bajo Ancho de banda Bajo-medio Tabla 11. Especificaciones del protocolo Zigbee.

3.2.10. Bluetooth Low Energy (BLE)

Este protocolo de comunicación es una variación del Bluetooth 4.0, el cual a su vez es la cuarta versión del Bluetooth diseñado e implementado en 2001. Las versiones posteriores a su primera versión han hecho que Bluetooth sea capaz de transferir archivos mucho más pesados a una velocidad muy adecuada para lo requerido por distintos dispositivos (tanto industriales como pertenecientes a la tecnología móvil que sigue innovando con el paso del tiempo). Estas versiones, sin embargo, requieren un consumo de energía muy alto, lo que se ha convertido en un problema para llevar a cabo las conexiones con dispositivos de batería baja o con algunas otras limitaciones; pensando en una forma de optimizar las conexiones con este tipo de dispositivos, se crea la variable BLE (Bluetooth Low Energy – Bluetooth de baja energía). Este protocolo opera basándose en distintas capas del modelo OSI, como en la capa física (en la que se prepara contra las interferencias por medio de saltos aleatorios de frecuencia establecidos en sus canales), o la capa de enlace (en la que define sus vinculaciones por medio de la arquitectura Maestro/Esclavo, ya implementada por muchos otros protocolos y que les ha permitido un buen desempeño); implementa una capa conocida como L2CAP (Logical Link and Control Adaptation Protocol), la cual permite realizar una correcta agrupación de la información que requiere ser enviada, es decir, agrupa los datos en paquetes para reducir el peso de los mismos y facilitar su envío, y posteriormente envía estos paquetes en su orden correcto hacia las capas superiores. Existen capas superiores como la SM (Security Manager, encargada de proteger las conexiones y el intercambio de información), la capa GAP (Generic Access Profile, que maneja las conexiones), la ATT (Attribute Protocol, en la que se estipulan las configuraciones para emitir y recibir la información), y la capa Generic Attribute Profile (en la que los paquetes de datos mencionados en la capa L2CAP son organizados e interpretados para una correcta respuesta a la información proporcionada por los mismos). A diferencia del Bluetooth clásico, la variante BLE permite la optimización de energía mediante la suspensión de dispositivos mientras no hayan sido solicitados para una acción; es decir, si el dispositivo maestro hace una solicitud a uno de los dispositivos esclavos vinculados, el resto de los dispositivos estará suspendido para evitar un alto

consumo energético (un comportamiento similar al del protocolo de comunicación Zigbee), cabe destacar que el consumo de energía también tendrá que ver con el tamaño de los datos que serán enviados y, por consiguiente, el tiempo de conexión requerido entre los dispositivos. A continuación, se presentan las características del protocolo de comunicación Bluetooth Low Energy.

Especificaciones Protocolo Bluetooth Low Energy

(BLE)

Año de creación

2006

Arquitectura Maestro/Esclavo (Master/Slave) Tipo de conexión Banda ISM de 2.4 GHz Tamaño del encabezado Indefinido Tamaño del mensaje Corto (en caso de excederse su tamaño límite, pasan a crearse paquetes que agrupan los datos a ser transportados hasta el dispositivo final) Tipos de dispositivos vinculados Dispositivos centrales (solicitan datos, como medidas, procesan los datos recibidos.

Ejemplo:

teléfonos inteligentes) Dispositivos periféricos (Ejecutan las acciones solicitadas por dispositivos centrales, toman datos y los envían para su procesamiento a los primeros dispositivos. Ejemplo: sensores de temperatura) Capa de aplicación Él mismo, por medio de las capas ATT y Generic Attribute Profile. Velocidad de transmisión de datos Baja Formato de codificación Binario Estado de licencia Abierta

Consumo eléctrico Bajo Ancho de banda Bajo Tabla 12. Especificaciones del protocolo BLE.

3.2.11. Z-Wave

Este protocolo de comunicación es de estándar propietario diseñado por la compañía danesa Zen-Sys, cedido a la empresa Sigma Designs y manejado posteriormente por la compañía Z-Wave alliance. Z-Wave opera bajo conexión inalámbrica que tiene su aplicación principal en el campo de la domótica, en el que le permite al usuario controlar diversos electrodomésticos y dispositivos utilizados en el hogar. Para llevar a cabo la unificación a la misma red de todos estos dispositivos electrónicos, Z-Wave debe requerir niveles de potencia muy bajos, que permitan que cualquier dispositivo del hogar pueda vincularse por medio del protocolo y optimice tiempo y dinero para los usuarios. La conexión Z-Wave ve su mayor competencia (en el área de la domótica) en conexiones como Wi-Fi; esta última, sin embargo, opera a una frecuencia más alta que Z-Wave (2.4 GHz vs 900 MHz respectivamente), esto hace que este protocolo presente menos inconvenientes en cuanto a interferencias y brinde una conexión mejor en todos los lugares del hogar, por ejemplo. Con el paso de los años, y basándose en las constante innovaciones en el mercado tecnológico, Z-Wave ha realizado mejoras para ser compatible con un gran número de dispositivos pertenecientes a marcas como Samsung, D-Link, Logitech, entre otras; en caso de que el usuario tenga algún equipo en su hogar que no sea compatible con este protocolo, puede vincularlo a la red establecida por este con el uso de un módulo de accesorios diseñado propiamente por Z-Wave. Lo anterior lo convierte en un protocolo de comunicación que ofrece interoperabilidad al usuario; además, le permite al usuario modificar el número de dispositivos conectados, pudiendo añadir nuevos equipos o eliminar alguno de los existentes (El número máximo de dispositivos conectados a una red Z-Wave puede llegar a 232). Para optimizar el consumo eléctrico, y buscando un mejor rendimiento en la conexión, Z-Wave transmite datos agrupados en paquetes de un tamaño muy reducido. A pesar de esto, es un protocolo que brinda beneficios a

aquellos usuarios que requieran interacciones entre dispositivos sin necesidad de enviar gran cantidad de información o datos que se hagan muy pesados para la red (sensores y otros dispositivos de corto alcance). A continuación, se presentan las características del protocolo de comunicación Z-Wave.

Especificaciones Protocolo Z-Wave Año de creación Déca de los 2000 Arquitectura Red de malla Tipo de conexión Inalámbrica, pudiendo vincularse a la red hasta 232 dispositivos (entre más equipos se encuentren conectados, más fuerte será la red) Tamaño del encabezado Indefinido Tamaño del mensaje Pequeño, organizado en paquetes de datos para no saturar la red con pesos elevados.

Capa física Opera a una frecuencia muy baja (900 M Hz) comparada con otros protocolos. Capa de aplicación Él mismo (protocolo Z-Wave) Velocidad de transmisión de datos Baja-Media Formato de codificación Binario Estado de licencia Propietario Consumo eléctrico Bajo Ancho de banda Bajo Tabla 13. Especificaciones del protocolo Z-Wave.

3.2.12. NFC

El protocolo NFC (Near Field Communication – Comunicación de campo cercano), diseñado conjuntamente entre Philips y Sony, permite una serie de conexiones entre dispositivos que, como su nombre lo indica, deben encontrarse ubicados muy cerca unos de otros (es decir, a solo centímetros de distancia); aunque esto parece ser una gran limitación al comparar a NFC con otros protocolos con conexiones inalámbrica que permiten intercambios de datos a metros de distancia, este tiene aplicaciones que para muchos no son nada despreciables, como el hecho de poder crear pegatinas con la tecnología incorporada a este protocolo que pueden ser leídas por distintos dispositivos, como teléfonos celulares, para realizar determinada acción. El hecho de que la conexión entre dispositivos sea de corto alcance brinda a los usuarios que usan este protocolo una manera de intercambiar datos con seguridad relativamente alta, y garantiza en mayor medida que la información obtenida por el dispositivo final sea la correcta. La frecuencia a la que opera este protocolo de comunicación es muy baja (aproximadamente de 13.56 MHz), lo que también se debe al corto alcance de la comunicación; esto hace que, a pesar de no contar con altos niveles de frecuencia, la velocidad de transmisión de los datos sea muy aceptable (teniendo como base el envío de archivos comunes como imágenes, documentos, música, entre otros; cabe recalcar que NFC no está pensado para transmitir datos en gran cantidad y con un peso muy significativo, a diferencia de otros protocolos operados por distintas redes como Bluetooth o Wi-Fi); el que el nivel de frecuencia sea bajo también garantiza una interferencia mínima durante la conexión (ya que es común que la mayoría de redes ofrezcan una transmisión bajo la frecuencia estándar de 2.4 GHz). La arquitectura del protocolo es muy similar a la manejada por otros anteriormente mencionados; el protocolo cuenta con dos tipos de dispositivos: el iniciador y el destino. El primero es aquel dispositivo encargado de realizar la solicitud o petición al segundo dispositivo, el cual, a partir de la misma, responde enviando la información pertinente al iniciador; una vez ocurre esto, el iniciador puede realizar una nueva petición al destino (a lo anterior se le denomina diálogo). Los modos de conexión pueden variar de activo a pasivo según se requiera, siendo el primero cuando tanto el dispositivo iniciador como el destino requieren su propia fuente de alimentación para producir individualmente

un campo electromagnético (esto garantiza la interacción prolongada entre los dispositivos, pero también un consumo eléctrico más significativo); por otra parte, el segundo modo (pasivo) denota que el único dispositivo conectado a una fuente de alimentación es el dispositivo iniciador, por lo que el destino debe obtener su alimentación a partir del campo magnético generado por este (en este modo, las interacciones se limitan a los momentos en que el iniciador realice una petición, solo de esta manera el dispositivo destino podrá transmitir información). A continuación, se presentan las características del protocolo de comunicación NFC.

Especificaciones Protocolo NFC Año de creación

2004

Arquitectura Iniciador/Destino Tipo de conexión Inalámbrica, de corto alcance (a centímetros de distancia), con frecuencia de 13.56 MHz.

Tamaño del encabezado Indefinido Tamaño del mensaje Corto, no es posible transferir datos de forma masiva o con un peso relativamente alto Capa física Hace uso del estándar de comunicaciones ISO/IEC 14443 Capa de aplicación Él mismo (protocolo NFC) Velocidad de transmisión de datos Baja-Media Formato de codificación Binario Estado de licencia Abierta Consumo eléctrico Bajo-Medio (dependiendo del modo de conexión establecido) Ancho de banda Bajo Tabla 14. Especificaciones del protocolo NFC.

3.2.13. SigFox

Este protocolo de comunicación se presenta en una red alternativa al Wi-Fi comúnmente usado en diferentes partes del mundo; cuando este último comienza a presentar fallos por diversas razones como la deficiencia de señal o infraestructura, SigFox se convierte en una alternativa para los usuarios. Producido en 2009 por la compañía francesa con la que comparte nombre, SigFox ofrece servicios de conexión a redes de bajo consumo, algo que es buscado comúnmente en dispositivos vinculados al IoT, esto lo logra por medio de antenas y estaciones establecidas con total independencia de las redes existentes en el mercado tecnológico. Con el fin de tener una cobertura de largo alcance (la conexión a una de sus redes puede darse en dispositivos ubicados hasta a 50 kilómetros de distancia), este protocolo ofrece la opción de transferir datos en anchos de banda muy pequeños y limitados; esto no solo optimiza la cobertura de la conexión y evita interferencias con otras redes, sino que brinda la oportunidad de vincular a ella dispositivos muy sencillos entre los que se encuentran los sensores que requieren de baterías con limitaciones energéticas considerables. Para cubrir las necesidades de conexión segura de los usuarios, SigFox brinda a cada dispositivo un código de identificación, esto protege a la red de ataques provenientes de terceros (dispositivos que no se encuentran vinculados a la comunicación). Uno de los beneficios que ofrece SigFox es que, además de transferir información o datos mediante mensajes entre un dispositivo y otro, brinda la posibilidad de almacenar información en la nube, lo que es un servicio realmente útil en esta nueva era de las comunicaciones, donde la información requiere ser respaldada de manera segura, ya no solo por las empresas y las grandes industrias. SigFox puede interactuar con otras formas de comunicación como las ofrecidas por Bluetooth, redes de telefonía móvil y GPS, además de conectar distintos dispositivos, lo que lo convierte en una opción a tener en cuenta cuando la interoperabilidad es uno de los factores clave en la conexión y transferencia de información que se quiere realizar; las conexiones ofertadas pueden ser unidireccionales o bidireccionales, donde todo depende del uso que se le deba dar a los dispositivos (unidireccional podría ser cuando se está tomando una lista de datos por medio de algún dispositivo como un sensor; para los casos bidireccionales, el dispositivo puede enviar una lista de datos y a su

vez recibir solicitudes o sugerencias del dispositivo controlador). Su aplicación aún no es global, ya que no está presente en todos los países; esto hace que distintas compañías aún no la vean como una fuerte opción para sus conexiones y que distintas redes, operadas bajo distintos protocolos, sigan ganándole un lugar en el mercado. A continuación, se presentan las características del protocolo de comunicación SigFox.

Especificaciones Protocolo SigFox Año de creación

2009

Arquitectura Petición / Respuesta (Request / Response) Tipo de conexión Inalámbrica, con bandas de frecuencia que van desde 868 MHz (América) hasta 902 MHz (Europa) Tamaño del encabezado Indefinido Tamaño del mensaje Largo, dependiendo también de la ubicación en la que se realizará la conexión.

Capa física Él mismo (SigFox) Capa de aplicación Puede utilizar el protocolo HTTP. Velocidad de transmisión de datos Baja Formato de codificación Binario Estado de licencia Abierta Consumo eléctrico Bajo Ancho de banda Bajo-medio Tabla 15. Especificaciones del protocolo SigFox.

APLICACIÓN DE LOS PROTOCOLOS DE COMUNICACIÓN SEGÚN LA

NECESIDAD

Debido a la cantidad de protocolos de comunicación existentes en la industria, la elección de uno de ellos debe hacerse de acuerdo a las necesidades o los requerimientos propuestos por el usuario. A continuación, se presenta un diagrama de flujo que plantea los posibles requerimientos de los usuarios y el protocolo de comunicación que mejor se ajusta a cada uno de ellos.

Figura 1. Aplicación de los protocoles de comunicación.

Es importante destacar que los protocolos de comunicación envían información a los diferentes dispositivos vinculados a la red por medio de señales de corriente o voltaje (sin limitarse a una en particular); sin embargo, el protocolo Hart, que convierte las señales análogas a digitales y viceversa (para transmitir la información desde distintos dispositivos a la fuente de control), debe operar bajo cierto rango de corriente, estimado entre los 4 y los 20 mA, es decir, no admite transmisión de información por señales de tensión.

RESULTADOS

Al analizar las características de los protocolos de comunicación expuestos, puede evidenciarse que todos ofrecen beneficios en alguna aplicación particular (ya sea mayor cobertura, menor consumo eléctrico, menor ancho de banda requerido, mayor velocidad, menor frecuencia, entre otros), por lo que la elección de un protocolo específico es dejada únicamente a consideración del usuario; es decir, si se requiere realizar una transferencia de datos de forma rápida, y se cuenta con dispositivos con altos niveles de alimentación eléctrica, puede escogerse un protocolo que priorice lo primero aunque presente limitaciones en cuanto al ahorro energético. Aquí, sin embargo, se realizó un análisis del rendimiento de los protocolos más usados en la industria del Internet de las Cosas (IoT), estos son MQTT, CoAP, AMQP y HTTP; este análisis se hará bajo dos criterios: el primero es el consumo energético (siendo valorado el que menos consumo requiera y descartado el que lo intensifique); el segundo es el ancho de banda (valorando aquel que opere en bajos niveles y para dispositivos con limitaciones en este aspecto, y descartando aquel que necesite anchos de banda muy elevados).

Iniciando con el protocolo HTTP, puede evidenciarse que entre sus características destacan el alto consumo energético y la utilización de anchos de banda de tamaño considerable, a pesar de que ofrece la posibilidad de enviar datos muy pesados (cosa en la que otros protocolos se quedan cortos); por ello, para los criterios que se evalúan en el presente documento, este protocolo queda descartado.

Continuando con el protocolo AMQP, puede observarse que entre sus características destacan su nivel de interoperabilidad y la seguridad que ofrece en sus conexiones (algo de lo que carecen muchos protocolos, arriesgando la información transmitida de un dispositivo a otro); sin embargo, su consumo energético no es bajo, al igual que el ancho de banda que requiere. Esto quiere decir que, tomando como base los criterios a analizar en el presente documento, que este protocolo queda descartado.

Cuando se analizó el protocolo MQTT, pudo evidenciarse múltiples ventajas, entre las que se encuentran su sencillez en la comunicación y las posibilidades ofrecidas por un protocolo

con arquitectura Publish/Subscribe; aunque su consumo de energía no es alto, y el ancho de banda requerido no es de gran tamaño, sigue pudiendo mejorar su rendimiento bajo estas dos condiciones. Por lo anterior, y tomando como base los criterios anteriores, este protocolo no sería la primera opción a considerar cuando se habla de conectar a la red dispositivos con estas limitaciones; cabe resaltar que ofrece muchos beneficios y no debe descartarse siempre que se cuente con la posibilidad de ofrecer cierta permisividad en estos aspectos (consumo eléctrico y ancho de banda) durante la comunicación.

Finalmente se evalúa el protocolo CoAP, el cual ofrece un gran número de beneficios contenidos en el protocolo HTTP (como su gran nivel de interoperabilidad), disminuyendo sus especificaciones para requerir menos consumo eléctrico y un ancho de banda reducido. Claramente posee limitaciones y desventajas, como la calidad del servicio (QoS), que es el fuerte de otros protocolos, o los niveles de seguridad que ofrece durante las conexiones. No obstante, y tomando como base los criterios analizados por este documento, CoAP es el protocolo de comunicación más ventajoso cuando se requiere comunicar equipos con limitaciones en estas características (por ejemplo, si se requiere una conexión entre un sensor y un controlador). Por lo anterior, es preciso mencionar que este es el primer protocolo a tener en cuenta cuando se requiere poco consumo de energía y ancho de banda reducido.

CONCLUSIONES Y TRABAJOS FUTUROS

Los protocolos de comunicación brindan una utilidad considerable en las conexiones y la transferencia de datos entre dispositivos (incluso considerando únicamente aquellos vinculados a IoT), por lo que una correcta elección de protocolo puede optimizar distintos aspectos en la comunicación. Entre diversas opciones existentes, la forma más idónea para elegir un protocolo es analizar la aplicación que se va a llevar a cabo; es decir, si se habla de un dispositivo que constantemente debe intercambiar información por medio de mensajes con muchos otros dispositivos, es conveniente utilizar un protocolo vinculado a la publicación/suscripción; si se requiere una conexión con muy altos niveles de seguridad (por ejemplo, redes bancarias), es conveniente utilizar un protocolo como AMQP; y si se requiere realizar búsquedas o peticiones frecuentes entre un dispositivo y otro, CoAP y HTTP podrían ser opciones muy valiosas. Así que no puede listarse un protocolo como el mejor de todos sin tener en cuenta la aplicación que se le va a dar. Además de esto, es importante recalcar que se definió CoAP como el mejor protocolo tomando como base un entorno con dispositivos limitados tanto energéticamente como en ancho de banda; bajo la hipótesis anterior, CoAP resulta ser el protocolo que más optimiza recursos para mejorar la conectividad.

El estudio del desempeño de CoAP bajo otras limitantes, o para distintas aplicaciones, puede ser el camino a seguir. Si se realiza una investigación de los protocolos de comunicación bajo distintas aplicaciones, podría encontrarse aquel que reúna mayor rendimiento en múltiples campos; y de esta manera, podría contarse con la posibilidad de escoger un protocolo de comunicación con un rendimiento generalmente eficaz. De igual forma, el uso de conceptos vinculados al Internet de las Cosas (IoT) sigue incrementando con el paso del tiempo, por lo que muchos trabajos pueden realizarse a partir de ello. Puede tenerse en cuenta, por ejemplo, la oportunidad de estudiar (a detalle) las capas de distintos modelos (sin limitarse al modelo OSI) y las mejoras que ofrecen al ser implementadas en las conexiones a diversas redes. El constante estudio de estos conceptos podrá representar una alternativa a los métodos de conexión actualmente usados, que generan cada vez más limitaciones dado el incremento de dispositivos a nivel global; el uso de nuevas tecnologías optimizaría los procesos en distintos

ámbitos, tanto industriales como domésticos, por lo que la investigación de este tipo de temas nunca estará demás y siempre representará un punto de partida para nuevos avances tecnológicos que mejorarán no solo la comunicación y la interacción de las personas, sino otros factores como su calidad de vida.

Bibliografía [1]. Adel W. Sadek, B. “. (2016). Special Issue on Cyber Transportation Systems and Connected Vehicle Research. Journal of Intelligent Transportation Systems, 20(1), 1-

3.

[2]. Aizuddin Daud, M., & Haji Suhaili, W. (2016). Internet of Things (IoT) with CoAP and HTTP protocol: A study on which protocol suits IoT in terms of performance. International Conference on Computational Intelligence in Information System, 165-

174.

[3]. Al-Sarawi, S. A. (2017). Internet of Things (IoT) communication protocols. IEEE, 685-

690.

[4]. Al-Sarawi, S., Anbar, M., Alleyan, K., & Alzubaidi, M. (2017). Internet of Things (IoT) communication protocols. 2017 8th International conforence on information technology (ICIT), 685-690.

[5]. Arvind, S., & Anantha Narayanan, V. (2019). An Overview of Security in CoAP: Attack and Analysis. 2019 5th International Conference on Advanced Computing and Communication Systems (ICACCS).

[6]. Ashok Somani, N., & Patel, Y. (2012). Zigbee: A low power wireless technology for industrial applications. International Journal of Control Theory and Computer modelling (IJCTCM), 2(3), 27-33.

[7]. Aula21. (s.f.). Aula 21 Formación para la industria. Recuperado el 2020, de https://www.cursosaula21.com/modbus-que-es-y-comofunciona/#:~:text=Modbus%20es%20un%20protocolo%20de,en%20serie%20entre% 20dispositivos%20electrónicos.&text=En%20realidad%2C%20esto%20significa%20 que,a%20que%20se%20le%20pida [8]. Badenhop, C. W., Graham, S. R., Ramsey, B. W., Mullins, B. E., & Maillowx, L. O. (2017). The Z-Wave routing protocol and its security implications. Computers & Security , 68, 112-129.

[9]. Barrett, S. F. (2020). Arduino I: Getting Started. Morgan & Claypool, Synthesis Lectures on Digital Circuits and Systems.

doi:10.2200/S01001ED1V01Y202003DCS058

[10]. Bezerra, D., Roque Aschoff, R., Szabo, G., & Hadj Sadok, D. F. (2018). An IoT protocol evaluation in a smart factory environment. 2018 Latin American Robotic Symposium, 2018 Brazilian Symposium on Robotics (SBR) and 2018 Workshop on Robotics in Education (WRE) , 118-123.

[11]. Bormann, C., Castellani, A. P., & Shelby, Z. (2012). Coap: An application protocol for billions of tiny internet nodes. IEEE Internet Computing, 16(2), 62-67. [12]. Breivold, H. P. (2015). Internet of things for industrial automation-challenges and technical solutions. IEEE International Conference on Data Science and Data Intensive Systems, 532-539.

[13]. Brinkman, W. H. (1997). A history of the invention of the transistor and where it will lead us. IEEE Journal of Solid-State Circuits, 32(12), 1858-1865. [14]. Briscoe, N. (2000). Understanding the OSI 7-layer model. PC Network Advisor,

120(2), 13-15.

[15]. Cabello, C. (01 de 03 de 2016). Nobbot (Tecnología para las personas). Obtenido de https://www.nobbot.com/redes/sigfox-la-red-para-el-internet-de-las-cosas/ [16]. Chaudhary H., V. N. (2018). Information and Communication Technology for Sustainable Development (Vol. 9). Singapore: Springer.

[17]. Chi, Q. Y. (2014). A reconfigurable smart sensor interface for industrial WSN in IoT environment. IEEE transactions on industrial informatics, 10(2), 1417-1425. [18]. Cloud Computing.

(s.f.).

Recuperado el

12

de

05

de

2020,

de https://www.nist.gov/programs-projects/nist-cloud-computing-program-nccp [19]. Cloud, O. (s.f.). Internet of Things (IoT): Una ventaja copetitiva. (Orancle) Recuperado el 14 de 05 de 2020, de https://www.oracle.com/co/internet-of-things/ [20]. company, E. (s.f.). Emerson. Recuperado el 2020, de https://www.emerson.com/eses/automation/measurement-instrumentation/rosemount/about-communicationprotocols [21]. Coskun, V., Ozdenizci, B., & Ok, K. (2013). A survey on near field communication (NFC) technology. Wireless personal communications, 71(3), 2259-2294. [22]. David A. Casas Castillo, D. E. (2019). La Revolución de la Industria 4.0 en España y su tendencia en Colombia. Bogotá D.C.: Universidad Santo Tomas.

[23]. Dragomir, D. G. (2016). A survey on secure communication protocols for IoT systems. IEEE, 47-62.

[24]. Dunkels, A., Eriksson, J., Finne, N., Österlind, F., Tsiftes, N., Abeillé, J., & Durvy, M. (2012). Low-Power IPv6 for the internet of things. 2012 Ninth International Conference on Networked Sensing (INSS), 1-6.

[25]. Dutertre, B. (2007). Formal modeling and analysis of the Modbus protocol. International Conference on Critical Infrastructure Protection. [26]. El taller del bit.

(s.f.).

Obtenido de https://www.google.com/amp/s/eltallerdelbit.com/capa-4-osi-capa-de-transporte/amp/ [27]. Fidler, E., Jacobsen, H., Li, G., & Mankovski, S. (2005). Publish/Subscribe System. Feauture Interactions in Telecommunications and Software Systems VIII. [28]. Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., & Berners- Lee, T. (1999). RFC2616: Hypertext Transfer Protocol-HTTP/1.1. RFC Editor. [29]. G. M. L. Atzori, A. I. (2010). The internet of things: A survey. Comput. Networks,

54(15), 2787-2805.

[30]. Galadima, A. A. (2014). Arduino as a learning tool. IEEE, 11th International Conference on Electronics, Computer and Computation (ICECCO), 1-4. doi:10.1109 [31]. Ge, J.-M. L.-L. (2010). Study on wireless HART network layer. IEEE, The 2010 International Conference on Apperceiving Computing and Intelligence Analysis Proceeding, Chengdu, 187-189.

[32]. Infocenter, A. (2006). Cortex-M3 Technical Reference Manual. [33]. IO, A. (s.f.). The internet of things for everyone: The easiest way to stream, log, and interact with your data. Recuperado el 14 de 05 de 2020, de https://io.adafruit.com/ [34]. Jeon, K. E., She, J., Soonsawad, P., & Chet Ng, P. (2018). Ble beacons for internet of things applications: Survey, challenges and opportunities. IEEE Internet of Things Journal, 5(2), 811-828.

[35]. José Daniel Cabrera Cruz, C. D. (s.f.). Dificultades de la innovación tecnológica en Colombia. Bucaramanga, Colombia.

[36]. Kozierok, C. M. (2005). The TCP/IP guide: a comprehensive, illlustrated Internet protocols reference. No Starch Press.

[37]. Kramer, K.-D., Stolze, T., & Banse, T. (2009). Benchmarks to find the optimal Microcontroller-Architecture. IEEE, World Congress on Computer Science and Information Engineering, 102-103. doi:10.1109/CSIE.2009.928 [38]. L. Da Xu, W. H. (2014). Internet of things in industries: A survey. IEEE, 10(4), 2233-

2243.

[39]. Lavric, A., Petrariu, A., & Popa, V. (2019). Long range sigfox communication protocol scability analysis under large-scale, high density conditions. IEEE Access 7,

35816-35825.

[40]. Learn about Arduino. (s.f.). Recuperado el 12 de 05 de 2020, de https://www.arduino.cc/ [41]. Lian, F.-L., Moyne, J. R., & Tilbury, D. M. (2001). Performance evaluation of control networks: Ethernet, ControlNet, and DeviceNet. IEEE control systems magazine,

21(1), 66-83.

[42]. Lukasik, S. (2010). Why the ARPANET was built. IEEE Annals of the History of Computing, 33(3), 4-21.

[43]. Mahmud, K. I. (2005). Energy consumption measurement of wireless interfaces in multi-service user terminals for heterogeneous wireless networks. IEICE transactions on communications, 88(3), 1097-1110.

[44]. Martínez Moreno, F. J. (2019). Diseño e implementación de un sistema de alarma IoT basada en tecnologías Open Source.

[45]. Moreno, F. J. (2019). Diseño e implementación de un sistema de alarma IoT basada en tecnologías Open Source. Universidad Politécnica de Cartagena . [46]. Mumtaz, S. A. (2017). Massive Internet of Things for industrial applications: Addressing wireless IIoT connectivity. IEEE Industrial Electronics Magazine, 11(1),

28-33.

[47]. Muthu Ramya, C., Shanmugaraj, M., & Prabakaran, R. (2011). Study on ZigBee technology . 2011 3rd International Conference on Electronics Computer Technology,

6, 297-301.

[48]. Naik, N. (2017). Choice of effective messaging protocols for IoT systems: MQTT, CoAP, AMQP and HTTP. IEEE international systems engineering symposium (ISSE),

1-7.

[49]. Naik, N. (2017). Choice of effective messaging protocols for IoT systems: MQTT, CoAP, AMQP and HTTP. 2017 IEEE international systems engineering, 1-7. [50]. Nelson, D., Qiao, M., & Carpenter, A. (2013). Security of the near field communication protocol: an overview. Journal of Computing Sciences in Colleges,

29(2), 94-104.

[51]. Noonen, D., Siegel, S., & Maloney, P. (1994). DeviceNetTM Application Protocol. 1st International CAN Conference. Mainz, Germany.

[52]. O. E.Amestica, P. M.-F. (2019). An Experimental Comparison of Arduino IDE Compatible Platforms for Digital Control and Data Acquisition Applications. IEEE, 1-

6.

[53]. P., S. (2017). Modbus. In: Building Arduino PLCs. Apress. Berkeley, California: Apress.

[54]. Palattella, M. R. (2013). On optimal scheduling in duty-cycled industrial IoT applications using IEEE802. 15.4 e TSCH. IEEE Sensors Journal. [55]. Pratt, W. A., Nixon, M. J., Rotvold, E. D., Pramanik, R. S., & Lennvall, T. P. (2013). US Patente nº 8,570,922.

[56]. Ruiz, C. A. (2014). Inclusión de las TIC en la empresa colombiana. ELSEVIER

DOYMA, 5(10), 29-33.

[57]. S. Chaudhary, R. J. (2019). CRAIoT: Concept, Review and Application(s) of IoT. IEEE, 4th International Conference on Internet of Things: Smart Innovation and Usages (IoT-SIU), 1-4.

[58]. Sahu, C. M. (2018). Performance Assessment of Companies Under IIoT Architectures: Application of Grey Relational Analysis Technique. IEEE, 1350-1354. doi:10.1109/ICIRCA.2018.8597285 [59]. Serrano-Cobos, J. (2014). Big data y analítica web. Estudiar las corrientes y pescar en un océano de datos. El profesional de la información, 23(6), 561-565. [60]. Services, A. W. (s.f.). AWS IoT. (Amazon) Recuperado el 14 de 0.5 de 2020, de https://aws.amazon.com/es/iot/ [61]. Soni, D., & Makwana, A. (2017). A survey on mqtt: a protocol of internet of things (iot). International Conference On Telecommunication, Power Analysis and Computing Techniques (ICTPACT-2017).

[62]. Stallings, W. (1996). IPv6: the new internet protocol. IEEE Communications Magazine, 34(7), 96-108.

[63]. Stallings, W. (2000). Comunicaciones y redes de computadores. Madrid: Pearson Education, Prentice Hall.

[64]. Stanford-Clark, A., Truong, H.-L., & Hunkeler, U. (2008). MQTT-S - A Publish/Subscribe Protocol For Wireless Sensor Networks. 2008 3rd International Conference on Communication Systems Software and Middleware and Workshops (COMSWARE'08) (págs. 791-798). IEEE.

[65]. Suo, H. W. (2012). Security in the internet of things: a review. In 2012 international conference on computer science and electronics engineering. IEEE, 3, 648-651. [66]. Todo de redes. (s.f.). Obtenido de https://tododeredes.com/modelo-osi/capa- 3/#:~:text=La%20capa%20de%20red%20es,selección%20de%20ruta%20y%20direcc ionamiento.

[67]. Val, J. L. (18 de 03 de 2016). Deusto, Facultad de ingeniería, Industrias 4.0: La transformación digital de la industria. Recuperado el 14 de 05 de 2020, de https://revistaingenieria.deusto.es/tag/industria-4-0/ [68]. Vargas, D. C. (2016). Smart IoT gateway for heterogeneous devices interoperability. IEEE Latin America Transactions, 14(8), 3900-3906.

[69]. W. Steiner, F. B. (2014). Towards synchronous deterministic channels for the Internet of Things. IEEE, World Forum on Internet of Things (WF-IoT), 433-436. [70]. Wan, J. C. (2013). From machine-to-machine communications towards cyberphysical systems. Computer Science and Information Systems, 10(3), 1105-1128.

[71]. WEBSARROLLADORES.

(24

de

05

de

2019).

Obtenido de https://websarrolladores.com/2019/05/24/trama-de-red/ [72]. WEG . (s.f.). Manual de Comunicación Device Net. Recuperado el 12 de 05 de 2020, de https://static.weg.net/medias/downloadcenter/h09/hfe/WEG-ssw07-manual-de-lacomunicacion-devicenet-10000046974-manual-espanol.pdf [73]. Wollschlaeger, M. S. (2017). The future of industrial communication: Automation networks in the era of the internet of things and industry 4.0. IEEE industrial electronics magazine, 11(1), 17-27.

[74]. Yahaghizadeh, S. D. (2018). Efficient event prediction in an IOT environment based on LDA model and support vector machine. IEEE, 6th Iranian Joint Congress on Fuzzy and Intelligent Systems (CFIS), 135-138.

[75]. Yassein, M. B., & Shatnawi, M. Q. (2016). Application layer protocols for the Internet of Things: A survey. 2016 International Conference on Engineering & MIS (ICEMIS)

, 1-4.

[76]. Zhang, Z. H. (2015). Spark: una plataforma de procesamiento de Big Data basada en la computación de memoria. IEEE, 172-176. doi:10.1109 /PAAP.2015.41 [77]. Zhu, R. Z. (2015). Energy efficient reliable decision transmission for intelligent cooperative spectrum sensing in industrial IoT. IEEE.