ebook 240 © mcelectronics

Hecho el depósito que marca la ley 11.723

pag Todos los derechos reservados.

APLICACIONES DE IOT
INDUSTRIALES
Mucho más que dispositivos
conectados.

| Electroners Magazine ©2022 sponsored by

Aplicaciones de IoT industriales

Ariel Coria. Amelia Balsamo. Fernando Blaha.

Iván Castellucci Vidal. Prólogo de José Tamborenea.

1
 Aplicaciones de IoT industriales / Ariel Jacinto Coria ... [et al.] ; contribuciones
de Mauricio Damian Jancic ; coordinación general de Alejandro Anibal Airoldi ;
prólogo de José Antonio Tamborenea. - 1a ed. - Ciudad Autónoma de Buenos
Aires : Mcelectronics, 2021.
240 p. ; 23 x 16 cm.

ISBN 978-987-3702-12-9

1. Ingeniería Electrónica. 2. Electrónica Aplicada. 3. Control Industrial.

I. Coria, Ariel Jacinto. II. Jancic, Mauricio Damian, colab. III. Airoldi, Alejandro
Anibal, coord. IV. Tamborenea, José Antonio, prolog.

CDD 621.39028

Fecha de catalogación: Marzo de 2021

© mcelectronics

Hecho el depósito que marca la ley 11.723

Todos los derechos reservados.

Ninguna parte de este libro, incluido el diseño de la portada, puede reproducirse,

almacenarse o transmitirse de ninguna forma ni por ningún medio, sea este eléctrico,
químico, mecánico, óptico, de grabación o de fotocopia, sin la previa autorización escrita
por parte de mcelectronics. La infracción de los derechos mencionados puede ser
constitutiva de delito contra la propiedad intelectual.

La editorial no se pronuncia ni expresa implícitamente respecto a la exactitud de la

información contenida en este libro, razón por la cual no puede asumir ningún tipo de
responsabilidad en caso de error u omisión.

Las marcas mencionadas son propiedad exclusiva de sus registradores legales.

Diseño de Portada:
54Designers.com - Comunicación + Innovación

Revisor técnico LoRa:

Mauricio Jancic

Seguinos en las redes sociales /mcelectronics

(C) 2021

2
Este libro está dedicado a todos ustedes, nuestros queridos lectores.

3
4
CONTENIDO

PRÓLOGO 7

INDUSTRIA, IOT Y LA NUBE 13

Comienzo y evolución. Los pilares de IoT: Dispositivos, conectividad y

plataformas. Redes: LAN, LPWAN, Celular y Satelital. Protocolos y
seguridad de la información. Security of things: ¿cómo prevenir que
nuestra solución de IoT se convierta en un backdoor? Convergencia
IT/OT y madurez de IIoT. Edge IoT. Mi primer proyecto de IoT.

MANTENIMIENTO PREDICTIVO DE MÁQUINAS INDUSTRIALES 65

Breve introducción a los tipos de mantenimiento habituales.

Diferencia entre mantenimiento Preventivo y Predictivo. Sensores
para la industria. Usos del Sensor Bosch SCD110. Aplicaciones y
ejemplos prácticos. Compatibilidad con Bosch IoT Suite. Digital Twin
en el mantenimiento industrial.

SEGURIDAD DE LOS TRABAJADORES 107

Obtenga información de los trabajadores en tiempo real para activar

protocolos de rescate o asistencia preventiva. Mediante estos sensores
podemos monitorear la atmósfera a la cual está expuesto el trabajador,
detectar golpes y caídas, rastrear su posición y obtener datos críticos
del entorno. Especificaciones del hardware Bluetooth.
Ejemplos de aplicación.

5
APLICACIONES DE TELEMETRÍA Y SEGUIMIENTO DE ACTIVOS 149

Mediante sensores GPS y redes LTE podemos realizar el seguimiento

de vehículos, personas o activos de cualquier tipo en tiempo real. En este
capítulo veremos las consideraciones necesarias, el hardware disponible
para prototipado y los recursos en la nube para hacer el seguimiento
de manera eficiente, confiable y segura.

LoRaWAN UNA RED PARA IOT 189

Especificaciones del protocolo LoRaWAN, modulación y dispositivos

necesarios. Infraestructura de una red LoRaWAN. Gateways, Network
Server y Application Server. Modos de operación. Buenas prácticas
en la diagramación de las redes. Calidad de servicio.

EL FUTURO DE LAS COMUNICACIONES CON 5G 219

Evolución de la tecnología celular y por qué hoy estamos hablando de

5G. Descripción y alcance. Nuevas aplicaciones. Módulos disponibles.
Caso de éxito. Despliegue actual y roadmap.

BIBLIOGRAFÍA 239

6
Prólogo

Cuando se me convocó a escribir este prólogo me sentí alagado, sorprendido y

desconcertado. Alagado, por ser considerado un referente en el tema, de esas
cosas que uno encuentra sin buscar o que son consecuencia de otras, porque
el foco puesto en Industria 4.0, nace del convencimiento de alentar un camino
de actualización tecnológica en la industria, propuesto por la Unión Industrial
Argentina en la conferencia de 2017, para ser más competitivos a nivel país y
como vector desde la presidencia de CADIEEL, cámara que represento.

Con esto logramos INDtech 4.0, con los Ministerios de Desarrollo Productivo, la
Agencia de I+D+i, ADIMRA Y CADIEEL, una gran plataforma de desarrollo
productivo, que acerque conocimiento, herramientas y un ecosistema donde
confluya demanda y oferta de estas soluciones.

Sorprendido, por ser la primera vez de tener un vínculo con un libro, si paper,
documentos, presentaciones, pero un libro… te hace pensar un poco, el
compromiso es formal, dejas algo que no se borra, y para mi generación (nací
en el ’68) que creció con “tener un hijo, plantar un árbol y escribir un libro”
que nos repetían como la formula!

Siempre lo pense como 2 de 3 o algún día quizá, dado que soy padre de 2 niños
y fana del medio ambiente, solo restaba el libro y si bien esto es apenas un
prólogo, por el momento es lo más cerca de la formula!

Desconcertado, porque lo primero fue, pero hay montones de referentes y

enormes especialistas, no vengo de la electrónica, la robótica el software. De
formación Lic. En Administración, ahí viene la introspección, me digo… yo ya
no soy el que se graduó en el ’92 o cursó el MBA en el ’98, cuánto pasó? Con el
mundo a esta velocidad, eso apenas cuenta, son cimientos? sí; tienen valor?
Seguro; pero lo que vale es lo que aprendiste en los últimos cinco años y
apenas, porque la velocidad del conocimiento se acelera más y mas. Y puedo
decir que como consultor en cadena de abastecimiento, puede ver muchas
industrias, farma, consumo masivo, petróleo, minería, textiles, operadores
logísticos, línea blanca, en todos había que reducir desperdicios, asegurar

7
procesos y calidad, mejorar el servicio todo con ROI positivo, por supuesto y
para eso, todo el despliegue de herramientas disponibles, almacenes
inteligentes, transportes inteligentes, líneas productivas, por supuesto
automatizaciones, robótica, software, modelos matemáticos y luego venían
mis últimos años de fabricante, con productos tecnológicos, luminarias y
caudalímetros inteligentes y todo el ecosistema de ADIMRA/CADIEEL,
compartiendo con mis colegas los problemas y soluciones en 4.0, el donde
vamos, donde estamos y que nos falta. Entonces me di cuenta que frente a mi
desconcierto, lo que tenía, era un concierto de herramientas que explicaban el
porqué.

Alejandro me pidió en todo este contexto, que contara un poco la

problemática regional y las oportunidades, me sedujo del libro, que no era
para especialistas, sino de especialistas para los empresarios, jefe de
producción, implementadores, que quieren aplicar soluciones tecnológicas,
con casos de éxito que pueda reflejar que son cosas alcanzables y sirven de
guía.

Cuando se prepara un proyecto de mejora tecnológica los usuarios y el líder de

proyecto, definen un objetivo a alcanzar y sus ratios de mejora que justifican el
proyecto con su ROI asociado e incluso con sus tasas financieras TIR o VAN.

En los casos de las Pymes que realizan estos saltos tecnológicos a un sinfín de
aristas que surgen en el camino, problemas en la implementación no
proyectados o previstos y oportunidades nuevas o efectos secundarios
positivos, que derraman en otros sectores de la operación.

Recuerdo al implementar un caso de eficiencia energética en un operador

Logístico en argentina (Andreani: Líder de Proyecto: Carlos López, Gerente de
mantenimiento), el objetivo era ahorro de energía 60% y bajar el
mantenimiento al 50%, por cambiar la iluminación a LED. Era relativamente
sencillo, reemplazar luminarias del 300 W de consumo por 120 W para pasillos
de logística de 77 m. de largo y 2,10 m. de ancho, y 13 m. de altura, con 24 hs
de encendido 7 x 24 hs. En la medida que avanzábamos, descubríamos más
funcionalidades para aplicar, primero se nos informó que la nave de logística

8
era de productos de farma, con temperatura controlada de 15° a 25°, esto nos
hacía capturar un ahorro secundario, porque las luminarias anteriores
trabajaban a más de 200° y las de LED en unos 60°, con lo cual los equipos de
frio generaban un ahorro por no pelear contra el calor generado por la
iluminación. También nos dimos cuenta que podíamos encender por demanda,
dado que la luminaria nueva de LED, no tenía ciclo de encendido y apagado,
encendía instantáneamente.

Se definió, colocar sensores de movimiento y timer para dar tiempo al picker

de completar su orden; acá aparecía un nuevo problema si el tiempo era corto,
atrapaba sin luz al operario de pickeo en el pasillo y si el tiempo era largo, se
desperdiciaba energía y generaba calor. El gerente de mantenimiento propuso
2 líneas infrarrojas en las entradas de pasillo con un contador, que al ponerse
en positivo encendida y al quedar en cero, apagaba; esto capturaba alrededor
de otro 5% de eficiencia promedio.

En logística se trabaja con concepto de velocidad de rotación con lo cual hay

pasillo A, B Y C, con distintas frecuencias de visita, con lo cual ahora
extendíamos la vida útil de los activos (luminarias) Igualmente esto quedó para
ser realizado más adelante.

Teníamos otra ventaja las luminarias no tenían driver, eso bajaba le impacto
medioambiental y no tenía disposición final de residuos, con lo cual contribuía
con los objetivos de la Compañía para su balance de huella de Carbono. Ya una
vez hechas las evaluaciones y haber tomado los datos, el ROI se aceleró por
todas las contribuciones adicionales. Para los casos siguientes, encontramos
lentes para la luminaria de LED, que nos permitieron separar las luminarias de
6 a 12 m. y colocar el 50% de los equipos, con la cual se bajaba la inversión y el
mantenimiento, luego esto se puedo extrapolar a otras operaciones y áreas del
CDs, donde se capturaron más ahorros.

Lo destacable de los proyectos mejora o de inserción de tecnología que se

implementan, es que redundan en una serie de beneficios para las empresas,
que no se evalúan de primera mano, aunque luego se perciben en el
funcionamiento normal, aumenta la comunicación entre los sectores, genera
estímulo para desarrollar nuevas cosas, los participantes están más animados,
se trabaja la creatividad, se gana confianza y se adquiere conocimiento.

9
Recomendamos que los resultados sean expuestos a la Dirección, que
participen a la gente que se involucró, etc. Acompañado de la inversión, los
hitos del proyecto, la tabla de tiempos de toda la implementación. Colocar
momentos para la revisión, reservar fondos para contingencias o procesos de
cambios, es posible que se encuentren con potenciales mejoras que se pueden
capturar en el proceso. Si requieren de máquinas, servicios de especialista,
asegurar bien la transferencia tecnológica, todo el conocimiento, seleccionar a
los actores internos que tendrán esa responsabilidad, negociar los esquemas
soportes posteriores si hace falta. Contar con un Sponsor dentro de la
organización.

La búsqueda de la eficiencia, reducción de desperdicios y mejora continua de

la calidad en los procesos de transformación industrial han sido motorizadas
por innumerables prácticas y metodologías de implementación, en las últimas
décadas, estas ahora se encuentran con una batería de soluciones, de
automatización, sensores, robótica, Inteligencia Artificial (AI), internet de las
cosas (IoT) o AIoT, como mezcla de ambas, digitalización de los procesos,
análisis de datos de gran tamaño (Bigdata), asegurados, validados y protegidos
(blockchain), como nunca se había visto, de permanente crecimiento y
evolución, llamada 4ta. Revolución industrial, que ya no da la posibilidad de
desacoplarse de esta ola para la industria más tradicionalista, es subirse o
perecer.

Hay que aprovechar las oportunidades y América Latina, tiene la gran

oportunidad de dar este salto, reforzado por lo que nos esta mostrando una
pandemia (Covid-19), que el tener industria local y soluciones de cercanía fue
crítico para los países, al complicarse la logística internacional y dado que los
pronósticos son que habrá que convivir con estos problemas de largo plazo, en
enfocar la soluciones que demandan transformación industrial, pasa a tener un
carácter estratégico para los países de nuestra región, incluido EEUU que vivió
en años anteriores procesos de desindustrialización en manos de Asia.

Está claro que hay una migración de los RRHH de industria a servicios, pero los
servicios dependen de productos que brindan esos servicios, de los cuales se
espera cada vez más y alguien los tiene que hacer, hasta hoy se ha demostrado

10
que son esos países los que conservan y desarrollan riqueza incremental. Si
una persona quiere llegar más rápido de un lugar a otro y utiliza un servicio
que le direcciona una ruta inteligente y optimizada, es porque la misma esta
congestionada de cierta forma, caso contrario no haría falta utilizar el servicio.

El tema es que esa congestión está dada por una carretera con innumerables
vehículos, que transportan todos tipos de personas y contenidos, todos
enlazados entre sí, lleno de dispositivos capaces de recibir, emitir información
y señales, con cobertura de comunicaciones, todo tipo de procesos donde hay
producto, producto y más producto. Ya hay unos 15 países con leyes al
respecto favoreciendo e incentivando la 4ta. Revolución industrial, es el
momento.

Gracias a Alejandro por hacer consciente lo que el día a día genera, por
invitarme a la reflexión, exponer con experiencias y casos, las necesidades que
tenemos como industria que busca incansablemente ocupar un espacio dentro
de la matriz productiva de América Latina, convencido que es la mejor forma
de generar distribución de la riqueza y un mejor equilibrio social.

José Tamborenea.

11
12
Industria, IoT y la nube

13
14
Comienzo y evolución

Internet of Things (o internet de las cosas por su traducción al español) es un

término que se empezó a utilizar a fines del siglo pasado, allá por 1999. Si bien
no se había presentado como concepto tecnológico como tal, se decía y usaba
comunmente entre los grupos de invertigadores y académicos. Y no fue hasta
el 2009, que fuese presentado al mundo por Kevin Ashton, quien era directivo
de Procter & Gamble (popularmente conocida como P&G) para ese entonces.
Asthon había formado un equipo de investigación con el Instituto Tecnológico
de Massachussets (MIT) sobre la la utilización de tecnología de identificación
por radiofrecuencia (RFID) y sensores, y fue él quien de esa forma se convirtió
en la primera persona en presentar en público el concepto de “Internet of
Things” y le dió su definición más simple y por lo tanto más aceptada: IoT es la
posibilidad de conectar una infidad de objetos a internet y obtener
información a partir de ellos (vamos a volver a esta frase durante el capítulo,
no se la olviden). Poco tiempo después, y como consecuencia del avance en el
desarrollo de dispositivos de sensorazación, redes de telecomunicaciones y
formas de recoleción y explotación de los datos, la compañía de
telecomunicaciones Cisco destacó ese año como el surgimiento de Internet of
Things, y no era un momento histórico elegido al azar; era el momento en que
ya eran más las “cosas” conectadas a internet que personas en el mundo.

¿Sabías que? La primera cosa conectada a internet fue una heladera de

Coca Cola. En 1982, el Departamento de Computer Science del Carnegie
Mellon conectó una máquina de CocaCola al servidor departamental
mediante una serie de microswitches. De esta forma, antes de ir a buscar
una gaseosa, podías comprobar no sólo si había, sino que cuán frías
estaban. Historia completa en
http://www.cs.cmu.edu/~coke/history_long.txt

En cierto modo, IoT surge como el encuentro y unión de dos grandes e

irrefrenables corrientes: la evolución de la industria hacia su próxima

15
 revolución y el avance tecnológico. Cada una de ellas, en paralelo y
sostenidamente, acortaron el tiempo que les tomaba marcar un hito en la
historia. Cuanto más se mezcla una con la otra, más rápido evolucionan. Y es
por esto también que son tan importantes, para los lectores de este libro, las
comunidades makers y los espacios de co-creación, para compartir
conocimiento y emprender juntos, y finalmente impulsar así la innovación.
Ahora, analicemos cada una en más profundidad:

La evolución de la industria

Podríamos contar muchas historias al respecto. Por ahora, vamos a centrarnos

en lo que más llama la atención, que es la velocidad con la que se produjeron
las revoluciones industriales: entre la primera y la segunda, y luego entre la
segunda y la tercera han pasado casi 100 años hasta dar el salto. Sin embargo,
ya entre la tercera y la cuarta pasaron sólo 30 años (si tomamos como
comienzo el surgimiento de IoT en los 2000s). ¿Por qué creen que pasó eso?
¿Porqué en tan sólo 30 años estamos ya en una nueva revolución? (Y no quiero
generarles ansiedad, pero ya nos estamos adentrando a la 5ta, la de la
colaboración máquina-humano). Lo que dio origen a la 4ta revolución
industrial, fue la incorporación de dispositivos inteligentes a la industria, a los

16
procesos productivos, de control y manufactura. Es la revolución que incorpora
el mundo digital al de las máquinas y las personas. La tecnología, aparece
como un tercer jugador que acelera, con su propia velocidad, la evolución de
los otros dos y los potencia. Pero ¿Qué pasó con la tecnología mientras tanto?

El avance tecnológico

La segunda corriente de la que hablábamos, responsable del surgimiento de

IoT, es sobre la que más podemos intuir y con la que convivimos a diario. Pero
si de responsables debemos hablar, no podemos dejar de mencionar al
corazón de IoT: internet. La revolución de internet empezó entre los 60’s y los
70’s con el descubrimiento de las primeras redes y protocolos de comunicación
(ARPANET y TCP/IP). Si bien eran redes que permitían comunicar entidades
gubernamentales y académicas, ARPANET encontró rápidamente su límite
cuando las redes desplegadas, por el hecho de estar aisladas, se volvían cada
vez más incompatibles entre si. En los 90’s y con la creación de la WWW
(world wide net) esto no sólo se resolvió, sino que dio comienzo a la revolución
de internet y con ella la capacidad de conectar personas y objetos en todo el
mundo.

Y esto nos trae hasta hoy, donde la tendencia a conectar más cosas del mundo
real, además de ser novedoso e innovador, genera eficiencias y optimizaciones
en el uso de los recursos y además grandes ventajas competitivas. Este
movimiento, impulsado por la creativdad y agilidad de las startups y las
comunidades makers y el apoyo tecnológico y financiero de incubadoras y
grandes corporaciones, lograron sumar a IoT a la ola de la “Era Digital”.

En lo cotidiano, sabemos que cada vez hay dispositivos móviles como

smartphones, computadoras portátiles e incluso smartwatchs, que
rápidamente se vuelven más compactos, tiene mayores funcionalidades y
capacidad de cómputo. En los últimos años, no sólo avanzó la electrónica sino
también la informática y surgieron técnicas como la inteligencia artificial, big
data y blockchain y más recientemente la computación cuántica. Y para no ser
menos, también avanzaron las redes de comunicación y conectividad: fibra,

17
satelital, de baja frecuencia, para celulares, para IoT, la siempre fiel
radiofrecuencia y el controversial 5G. Y no nos olviedemos de la nube (Cloud
Computing), que tuvo su auge también en los 2000s y facilitó el desarrollo de
aplicaciones, el acceso a servicios y plataformas y de esa forma habilitó la
explosión del mundo digital como hoy lo conocemos. Microchips, redes,
plataformas. Cada una empujando a la otra. El avance de una fuerza al del
resto. Cuanta más tecnología tiene la industria, más acelerada se ve su
evolución también. Todo este mega-universo va combinándose y disparando
casos de uso que aún no se nos ocurrieron. Y pareciera que hoy tenemos más
tecnología disponible que formas de usarla. Por eso este libro, para conocer
sobre IoT y que no nos agarre desprevenidos.

Entonces ¿Qué es IoT?

IoT es la posibilidad de conectar una infidad de objetos a internet y obtener

información a partir de ellos. ¿Se acuerdan? En esta frase encontramos
palabras claves que diferencian lo que es IoT de lo que no. Y también, detrás
de esas palabras hay otras tácitas que vamos a desenmascarar. Pero vamos por
partes: Tenemos “posibilidad”, “objetos”, “conectar, “internet” e
“información”.

La posibilidad está dada por el hecho de que no nos falten los otros cuatro. Los
objetos, pueden ser cualquier “cosa” del mundo real, e inclusive del mundo
virtual. Pueden ya estar preparados para conectarse a internet, como algunos
electrodomésticos, vehículos, maquinaria industrial, weareables (dispositivos
que podemos llevar puestos). O bien tendremos que desarrollar un dispositivo
para que el objeto pueda conectarse a internet. Entonces, en realidad, el aire
acondionado (el objeto) va a seguir siendo eso a menos que lo volvamos
“inteligente” con un módulo wifi o bluetooth (redes) para conectarlo a
internet, con sensores que midan la temperatura ambiente (dispositivos) y
desarrollando una app donde podamos visualizar la información y controlar el
aparato (plataforma). Ahí tenemos las 4 palabras, entonces acá tenemos IoT. Y
debajo de esas 4, hay otras 3 que son las que voy a usar todo el capítulo y son,
para mi, los fundamentos de IoT: Dispositivos, conectividad y plataformas.

18
¿Qué NO es IoT?

Para que podamos identificar qué es IoT, tenemos que conocer también qué
configuraciones no lo son. La diferencia fundamental entre IoT y no IoT es el
hecho de poder obtener información del estado de un objeto o su entorno de
forma remota: es decir, a través de internet. Otra diferencia que nos puede
ayudar saber que el simple hecho de que un objeto esté conectado a internet,
no lo hace inteligente. También IoT puede ser fácilmente confundido con la
automatización o con la domótica. Los sistemas de automatización están entre
nosotros desde ya hace mucho más tiempo que IoT, y están prensentes el
ámbito industrial a través de sensores, actuadores, PLCs (Controladores
Lógicos Programables), RTUs (Unidades Terminales Remotas) y sistemas
SCADA. ¿Y por qué no es IoT? Lo sería si conectamos el concentrador o el
sistema SCADA a internet, a una plataforma como la nube, cruzaramos la
información con la de otros sistemas o APIs, como por ejemplo de clima o de
modelos analíticos, y así como tantas integraciones se nos ocurran, hasta llegar
a un tablero de visualización online sobre el que podamos ver no sólo el estado
de una fábrica, sino la de todas en todo el mundo.

Pongamos un ejemplo simple: supongamos que quiero irme de vacaciones y

me preocupa el riego de mi jardín. Como escribí este libro, aprendí lo que es
IoT y armo un sistema de riego automatizado, con sensores de humedad para
la tierra, que se conectan por bluetooth a un arduino programado y a este lo
programo para que, si la humedad baja del 20% se active el sistema de riego.
¿Ustedes que piensan? ¿Me puedo ir tranquila? Más allá de lo que vaya a
pasar con mis plantas, hay una cosa que es cierta: no aprendí lo que era IoT. Lo
que faltó, fue el componente de internet. La forma para que yo pueda decir
que tengo IoT en mi jardín es conectar ese arduino a internet, ya sea con un
módulo wifi o con una tarjeta de telefonía móvil, y mande los datos por
internet a una plataforma (que puede ser la nube) que los concentre y que yo
los pueda visualizar de forma remota desde mi celular o mi pc donde sea que
me encuentre, e incluso interacuar con mis dispositivos si hiciera falta.

19
La diferencia fundamental, como en tantos otros ámbitos, es la comunicación:
IoT es una conversación, no un monólogo. IoT se puede resumir entonces
como las personas conversando, en un ida y vuelta de información valiosa para
ambos, con la tecnología por medio de internet.

Los pilares de IoT: Dispositivos, conectividad y plataformas.

Antes de comenzar cualquier proyecto de IoT, hay dos preguntas obligadas que
nos tenemos que hacer y esa son: ¿Qué queremos medir? y ¿Para qué? Una
vez que tenemos claro el objetivo de nuestro proyecto, hay tres componentes
que no nos pueden faltar para diseñar una solución: dispositivos, conectividad
y plataforma. Los dispositivos para medir, la conectividad para transferir los
datos y la plataforma para trabajar y así recibir los datos de distintas fuentes,
unificarlos y organizarlos y finalmente poder visulizar los resultados. Estos tres
componentes son imprescindibles en cualquier proyecto y por eso vamos a
describirlos en mayor detalle.

Dispositivos

El desarrollo de microchips cada vez más sofisticados, más potentes y

compactos masifica el acceso a dispositivos inteligentes tanto de uso industrial
como personal o doméstico. Sensores de todo tipo para medir variables como:
luz, polvo, humedad, gases, todo tipo de partícula en suspención, velocidad,
aceleración, presión, sonido, peso y la lista puede continuar. Lo interesante de
esto, es que podemos empezar a probar y medir algunas de estas variables en
un conexto hogareño y escalarlo luego a un caso de uso industrial. Si podemos
medir la temperatura en casa, también podemos medir la de un horno de
secado de ladrillos, escalando el dispotivo a uno que pueda medir y soportar
altas temperaturas. La amplia variedad de dispositivos resulta en que los casos
de uso sean tantos como ideas y necesidades surgan y así cada vez son más las
“cosas” conectadas.

20
Hagamos un ejercicio. ¿Cuántos dispositivos tenés conectados a internet?
Yo en este momento tengo 4: el celular, el reloj, la computadora y un
medidor de consumo eléctrico que instalamos en casa, en la térmica
general. ¿Cuántos más creés que podría tener? A mi me gustaría tener un
sensor que mida la presión de las ruedas de mi bici, para saber si la tengo
que inflar cuando la quiera usar. ¿Ya se te ocurrió cómo hacerlo? También
me gustaría saber si mis plantas tienen la tierra lo suficientemente húmeda,
para saber cuándo regar. Seguro ya te imaginaste cómo medirlo. Así, vamos
incorporando cada vez más dispositivos conectados a nuestra rutina y es
esto por que se estima para el 2021 que cada persona persona tenga al
menos 3.5 dispositivos conectados a internet. Estos sumados a los de uso
industrial, nos da una suma de 25 billones de dispositivos conectados en el
mundo, de acuerdo con las cifras de Statista1. Y ese número va a seguir
creciendo.

Como vimos en el ejemplo, rápidamente, una sóla persona, puede pasar de

tener 4 dispositivos a por lo menos 20, si medimos la presión en las dos
ruedas de la bici y todas mis plantas (si, tengo muchas). Y es por eso por lo
que se espera para el 2030, en tan sólo 9 años, que la cantidad de
dispositivos conectados a internet sea 50 billones. Así que hay que estar
preparados para ese momento, ya que detrás de todos esos dispositivos
hay infinidades de oportunidades para el mundo de las startups y los
makers. Y para eso es este libro.

Cuando hablamos de dispositivos en IoT, nos referimos particularmente a

aquellos que vamos a usar para medir, monitorear, controlar y conectar un
objeto del mundo real. Los hay para desarrollar pruebas de concepto o
pequeños proyectos, ideales para educadores, makers y las startups como
punto de partida, como también los de uso industrial y que está diseñados
para condiciones ambientas extremas o desfavorables.

21
¿Qué debemos tener en cuenta a la hora de elegir los dispositivos para
nuestro proyecto?

Cuando pensamos en IoT no podemos evitar pensar en sensores, de todo tipo.

Y como decíamos antes, las variables pueden repertirse en los casos de uso, sin
embargo, las condiciones en las que se miden son las que determinan el tipo
de dispositivo que vamos a usar. No debemos olvidarnos también como fuente
de datos podemos contar con imágenes y sonidos, así que sumaremos a los
sensores además cámaras, micrófonos e incluso smartfones como
“dispositivos”

Si estamos empezando un proyecto, y queremos realizar un protipado rápido,

probablemente querramos empezar con Arduino, por su simpleza, popularidad
y disponibilidad de estos dispositivos. Arduino es una compañía de hardware y
software de código abierto, y sus placas son una de las más elegidas por
educadores y emprendedores. Es muy popular por su practicidad para el
prototipado rápido. Al ser una plataforma estandarizada, abierta y modular,
permite a sus usarios crear desarrollos a medida con el soporte de una
comunidad activa y participativa. Las Arduino son microcontroladores
integrados en una única placa. Esta plataforma cuenta con las versiones Nano,
Micro, Uno y Mega, que varían principalmente en el chipset, la cantidad de
pines analógicos y digitales para I/O, su capacidad en SRAM y EEPROM.
También Arduino cuenta con un segmento MKR, destinado al prototipado
rápido de proyectos de IoT y que poseen módulos de conectividad integrados.
Estos permiten a emprendedores acelerar el time to market y acortar los
tiempos para los ingenieros en poner proyectos en producción.

Existen otras alternativas a Arduino en el mercado para prototipado y

aprendizaje de programación de microcontroladores, como es el caso del
tablero Teensy de la compañía americana PJRC, que ofrece igual potencia en
un tamaño más reducido o el tablero LaunchPad de la empresa Texas
Instruments que posee la particularidad de tener un microcontrolador de señal
mixta (MSP340), diseñado para implementaciones de sistemas embebidos que
requieran muy bajo consumo de energía, entre muchas otras compañías que
ofrecen placas de protitipado con y sin conectivadad integrada.

22
Por otro lado, los dispositivos industriales pueden estar divididos en dos
grandes grupos: los desarrollos custom que startups y pequeñas y grandes
empresas desarrollan para casos de uso específico. Esto les brinda flexibilidad
a los desarrollos, escalabilidad en las funcionalidades y prestaciones del
servicio y la capacidad de evolucionar a medida que lo hace el proyecto y la
adopción de tecnología por parte de sus clientes. Estas empresas deciden qué
componentes y módulos, qué sensores y qué conectividad integrar en sus
PCBs. En el segundo grupo encontramos dispositivos como los de las
compañías Bosch, Scheinder Electric, General Electric, y muchas otras, que
tienen sus propios diseños para cada tipo de implementación y a la vez
también comercializan sus propias plataformas y soluciones o consultoria. En
este caso, los emprendedores se ven en un contexto en el que no deben
desarrollar, testear, certificar su hardware, pero sacrifican flexibilidad en la
integración con soluciones custom, dispositivos o software de distintos
provedores. Otro de los grandes jugadores en la industria de dispositivos IoT y
componentes para el desarrollo de soluciones IoT son Microchip, Intel,
Advantech, Libelium, Arm, Dell, Lenovo y Nvidia, entre otras importantes
marcas.

Son muchos los fabricantes de dispositivos para IoT y durante este libro van a
conocer a muchos de ellos y los usos de estos. Desde estaciones
meteorológicas, pasando por minería conectada hasta las cosas más cotidianas
como la gestión del tránsito y optimización de la recolección de residuos en
una ciudad, los casos de uso son infinitos.

Conectividad

El segundo componente fundamental de una solución de IoT es la

conectividad. Cada vez más son las opciones disponibles, tanto en hardware
como en prestaciones de servicio de las operadoras. Además de la gran
promesa de 5G que se espera que sea el punto de inflexión y disparador de la
adopción masificada de IoT tanto en las industrias, como en las ciudades y
hogares. Lentamente empieza a desplegarse en distintas partes del mundo y
mientras tanto, tenemos muchas más opciones que dependerán de las redes

23
que tengamos disponibles en nuestra localidad, del hardware al que podamos
acceder o que podamos desarrollar y las dependencias que tenga nuestro caso
de uso en términos de transferencia de datos y la flexibilidad que tengamos
een cuanto a la captura y velocidad del procesamiento de los datos. ¿Cómo
tomar la decisión entonces? Conozcamos las redes, los protocolos y las
variables que influyen en nuestra decisión.

¿Cómo definir la comunicación?

Cuanto más alejados estén nuestros dispositivos de una fuente de

alimentación o bien de nosotros mismos, menor tendrá que ser el consumo de
batería de nuestros integrados. Pensemos por ejemplo en una implementación
de IoT en la industria agropecuaria para medir la humedad de cientas de
hectáreas de un cultivo. Sería extremadamente laborioso e ineficiente tener
que cambiar las baterías constantemente. Deberemos tener en cuenta
cuestiones como la frecuencia con que se toma la medición y con la que se
envían los mensajes, además del tamaño de estos. Cada medición, captura de
señal y envío de mensaje consume energía. Por eso, nuestros dispositivos
tendrán que ser eficientes en el consumo y eso tiene implicancia directa no
sólo el procesamiento (si lo hará en el edge o sólo transmitirá las capturas de
datos, que requerirá mayor consumo) sino también en el medio de
comunicación que elijamos, ya que algunas redes son más eficientes y estás
más preparadas para cada en específico. Por el caso inverso, cuanto más cerca
estén nuestros dispositivos a una fuente continua de alimentación, más
flexibilidad tendremos con el método de comunicación que elijamos. Vamos a
conocer cada caso en mayor detalle.

Redes: LAN, LPWAN, Celular y Satelital

Cuando se trata de redes, las opciones también son amplias. Sin embargo,
vamos a conocer algunos parámetros que nos van a guiar en la elección: el
volumen de datos a transmitir, la cercanía del dispositivo a una fuente de
alimentación y la ubicación donde serán instalados los dispositivos. Cada una
de las architecturas de redes que se listaron en el título de esta sección tienen
características que las hacen más apropiadas para un contexto determinado.

24
LAN: Las redes LAN (Local Area Network) no son una novedad. Se trata de una
configuración que interconecta dispositivos (de cualquier tipo) a misma red
localizada y limitada a un cierto rango espacial. En implementaciones IoT este
tipo de configuración se vuelve muy apropiada para contextos en los que los
dispositivos están distribuidos en un mismo espacio físico, como puede ser un
edificio inteligente o una linea de manufactura conectada. Los dispositivos
están vinculados a una misma red, y por medio de esta se comunican y
comparten información entre dispositivos, nodos, clusters y servidores. Al
tratarse de redes centralizadas, contamos con la cercanía de los dispositivos y
por ende estos a fuentes de alimentación continuas, por lo que en estos casos
podemos utilizar tecnologías inalánbricas como Bluethoot para dispositivos
móviles o en movimiento (como por ejemplo wearables), WiFi para
dispositivos tanto móviles como fijos o semifijos (sensores en general) o
Ethernet para instalaciones fijas. Entre las ventajas de este tipo de redes
encontramos la variedad de hardware, ya que la mayoría de los fabricantes de
microcontroladores producen primero integrados para Bluethoot o WiFi. Al
haber más oferta, son más económicos y fáciles de conseguir en cualquier
parte del mundo. Por otro lado, las redes WiFi nos permiten no limitarnos en
la cantidad de datos que mandamos desde los dispositivos. Encontraremos
mayor facilidad en la programación y por tratarse de una red localizada
tampoco habremos de preocuparnos por una limitación de energía. Si bien
siempre trataremos de optimizar el uso de los recursos, no representan una
limitación para nuestro proyecto. Si el contexto es distinto, tendremos que
explorar otras opciones, como las redes de bajo consumo o LPWAN.

LPWAN: Como mencionabamos antes, las condiciones pueden no ser las

ideales para nuestro proyecto de IoT, y tengamos que hacer implementaciones
en lugares abiertos, donde los dipositivos están a grandes distancias unos de
otros y nos vemos en la necesidad de optimizar al máximo el consumo de
energía de nuestro hardware. Las redes de bajo consumo LPWAN (Low Power
Wide Area Network) están diseñadas para grandes areas de covertura en zonas
urbanas o rurales, ya que ofrencen excelente propagación de señal. No de la
misma manera para lugares cerrados o bajo tierra. También están diseñadas

25
para operar con un bajísimo consumo energético, característica que le dan a
las baterias una durabilidad y disponibilidad de hasta 10 años. Los mayores
contribuyentes al consumo de energía son los transmisores de datos, por eso
es importante configurar ciclos de envío de datos, y apagar estos transmisores
cuando no estén siendo utilizados. A este estado se le llama en reposo o “Idle”
o “Power Save Mode”. Esto optimiza el consumo y extiende la vida de nuestras
baterías, además de que optimiza también el tráfico de la red. Dentro del
grupo LPWAN, encontramos como a las más más populares a las redes LoRa y
su protocolo abierto LoRaWAN patentado por LoRa Alliance, LTE-M (o Cat M1)
y NB-IoT (Narrowband IoT) desarrollados por 3GPP (3rd Generation
Partnership Project) y finalmente SigFox, la compañía francesa con su red
wireless ultra narrowband (de muy bajo consumo). Estas cuatro, si bien tienen
prestaciones diferentes, operan en distintas frecuencias y son operadas por
distintas empresas alrededor del mundo, comparten la similitud de ser las
redes ideales para implementaciones en industrias como el agro o la industria
petrolera, la medición de calidad de aire y agua en ciudades inteligentes, en la
industria de las telecomunicaciones y el mantenimiento de sus antenas, y en la
energía y el control de los generadores, paneles o élices según la fuente. Para
las cuatro hay una amplia gama de hardware y software. La elección
dependerá, como siempre, del caso de uso. El primer diferenciador es la
cobertura de cada red en los distintos países. SigFox presenta mayor
despliegue en el continente europeo mientras que LoRa, LTE-M y NB-IoT tiene
presencia también a lo largo de todo America. En America del Sur nos
encontramos con WND Group como proveedor de SigFox mientras que LoRa es
ofrecida por companías como Yeap, y LTE-M y NB-IoT son operadas por la
famosas empresas de redes móviles Claro y Telefónica. No es casualidad que
mencionemos juntas a LTE-M y NB-IoT, ya que ambas están basadas en el
estándar LTE, con la diferencia que la primera, al compartir características con
la telefonía movil, permite roaming y establece conexiones rápidamente,
mientras que NB-IoT está diseñada para soluciones estacionarias en donde la
red se configura y los dispositivos se registran una vez y no sufre mayores
cambios en el tiempo. Otra diferencia entre estas dos es que NB-IoT adminte
protocolos de comunicación no basados en TCP/IP o “non-IP protocols” lo que
lo hace aún más liviano y admite la conexión de muchos más dispositivos. En
cuanto a LoRa y SigFox, los competidores del momento, podemos decir que
LoRa es realmente bidireccional por su característica simétrica y esto la hace

26
más propicia para implementaciones en las que se espera interacción con los
dispositivos (como el control remoto de estos), mientras que SigFox es
asimétrica lo que la hace más apropiada para conextos en que los dispositivos
envían información (como puede ser medición de humedad y temperatura de
una plantación). Otra diferencia es el costo del hardware y el servicio de cada
red. Como conclusión, las redes LPWAN son ideales para cubrir largas
distancias, enviar pequeñas cantidades de datos y generar un muy bajo
consumo de energía.

Celular: Quizás la más conocida ya que cada uno de nosotros cuenta con al
menos un teléfono inteligente. Las redes celulares han ido evolucionando a
medida que también lo hicieron la demanda de los usuarios.
Fundamentalmente lo que cambia generación a generación es su ancho de
banda y la cantidad de conexiones simultaneas que tolera la red. Desde 2G,
pasando 3G, H y H+, LTE, 4G y la recientemente incorporada 5G, todas estas
redes comparten la misma característica de hardware: un microchip (tarjeta) y
un operador que nos habilita el uso de esa red. Cada una de ellas fue
habilitando mayor velocidad y estabilidad en las conexiones. Las redes
celulares, y más particularmente con la llegada de 5G, admiten una
transferencia de datos mucho mayor a los métodos que vimos anteriormente y
nos dan movilidad, por lo que en general estas se usan en implementaciones
de Edge Computing, donde en el dispositivo tenemos además algún nivel de
procesamiento de la información previa a ser enviada, o bien no sólo
mandamos objetos de texto plano sino también audio o imágenes, pero lo que
estamos midiendo o controlado no está fijo o en un espacio delimitado y una
LAN con WiFi no es posible. Probablemente sea la más sencilla de implementar
luego del WiFi, ya que es un tipo de red con el que interactuamos
habitualmente. Pero sin dudas, lo que mayormente marca la diferencia versus
las opciones anteriores es la cantidad de conexiones que admite de forma
simultanea, sincrónica y simétrica. Operadoras como Telefónica, Claro,
Verizon, Vodafone y AT&T, entre otras grandes marcas, representan el
segmento de telefonía movil no sólo para celulares sino para IoT. La inversión
pasa principalmente por la suscripción al servicio de red ya que los dispositivos
son simples y no debemos hacernos mayor problema por instalación y
administración de la red ya que lo hace el operador. Esta red es la que más ha

27
crecido en los últimos años y es la más prometedora de las redes para IoT con
5G, ya que esta permite transferencias de hasta 1Gb por segundo y admite
hasta 1 millón de dispositivos por metro cuadrado. Desde mi punto de vista y
luego del análisis de cada una, es la que encuentro más justa en relación al
costo-benefinicio y la que está siendo explotada con mayor velocidad e
inversión desde las empresas de telecomunicaciones. El hecho que sea una red
que también se utiliza para los celulares, facilita enormemente la integración
con aplicaciones móviles y para utilizar los mismos celulares como fuentes de
datos o sensores. Vamos a conocer más sobre el futuro de 5G y las redes
moviles durante este libro en próximos capítulos.

Fuente: https://theconversation.com/5g-mas-conexiones-mas-rapidas-y-con-mayor-cobertura-149577

Satelital: Quizás esta sea la opción menos elegida por el momento para los
desarrolladores de soluciones y servicios IoT, al menos para el mundo maker. Esto
tiene que ver con los dispositivos que se necesitan para instalar la red, el costo del
servicio y el conocimiento de campo que se necesita para desarrollar sobre este tipo
de redes. Actualmente, ocupa una pequeña porción del mercado de conexiones IoT,
aunque es un mercado en crecimiento. Los dispositivos de IoT satelital se han vuelto
más económicos, más simples y pequeños con el tiempo y si bien no son los más
populares, las conexiones satelitales tienen características únicas que lo hacen el
mejor candidato para casos de uso como la industria aerospeacial y aeronáutica. Entre
estas está la cobertura global de esta red, complemtamente independiente de la

28
geografía donde decidamos instalar nuestra solición. Otra es la disponibilidad y
fiabilidad de la red que puede ser superior al 99,9% y la robustez y seguridad que
ofrece por ser generalmente un entorno cerrado y privado. Y cabe mencionar también,
que la conectividad satelital puede ser nuestro aliado para acelerar nuestro time-to-
market. ¿Cómo? Quizás para el momento que hagamos nuestro proyecto de IoT, en la
zona en que queremos desplegarlo no contamos con ninguna red disposible celular ni
LPWAN disponible “aún”. Y resaltamos el aún, ya que mientras estas redes se
extienden, podemos contratar un servicio de conectividad satelital y avanzamos con
nuestr proyecto hasta que haya otra red o servicio disponible. Empresas como
Tesacom, Globalsat y Telezpacio tienen presencia en nuestra región y cuentan con
servicios específicos para “Industrial Internet of Things” (IoT orientado a la industria).

En la tabla a continuación encontrará una comparación de las prestaciones de

cada una para tomar la decisión de la conectividad que utilizaremos para
nuestro proyecto. Las variables que tendremos en cuenta van a ser: costo,
consumo de energía, transmición de datos y alcance:

Tecnología Arquitectura Mobilidad Alcance Pico de Velocidad Costo

máximo corriente (Tx)
Bluethoot LAN Baja <100m 10mA 2 Mbps $$
V5.2 (BLE)

WiFi LAN Media <70m 170mA (b) 100Mbps $

ESP8266 WAN 140mA (g)
802.11b/g/n 120mA (n)

Ethernet LAN Baja <100m 150mA 10/100 Mbps $

(Cat 5) WAN
LoRa LPWAN Media <20Km ~34 mA 0.3-50 Kbps $$

SigFox LPWAN Media <10Kms ~54mA 0.3-27 Kbps $$

NB-IoT LPWAN Baja <10Kms ~190mA 50 Kbps↓ $$

70 Kbps ↑
LTE-M LPWAN Media <10Kms ~235mA 300 Kbps ↓ $$
(Cat M1) 375 Kbps ↑

29
Dispositivos conectados para 2025 por tipo de tecnología.

Finalmente, para cerrar esta sección de conectividad, resta mencionar la

topología de red MESH: la estrella de las topologías IoT. Cabe resaltarla entre
el resto de las topologías de red porque es la más utilizada en IoT, ya que esta
permite a los nodos interactuar, transferise datos y darse instrucciones entre
ellos, como también con uno o más concentradores. La tradicional topología
estrella habilita la comunicación desde los nodos hacia el Gateway. Este tipo
de estructura hace que todo dependa de un solo punto y sea más propensa a
fallos, además de que cada no desconoce el estado del otro. En la topología
MESH, cada nodo recibe y envía información, los gateways interacturan con los
nodos y además con internet. Esta es una característica muy importante en IoT
porque la clave es que los dispositivos se conecten a internet para mandar
información. Pero en lugares donde no hay conectividad disponible, una red
MESH puede hacer que los nodos repliquen entre ellos hasta llegar al Gateway
que si está dentro de un área de cobertura y envíe los datos por el resto. Los
repetidores cumplen la función de retransmitir la información además de
llevar internet al resto de la red. Estas redes son útiles porque perminen
detectar fallos dentro de la misma red y que esta tenga la capacidad de
recomponerse. Si un nodo falla, la ruta de envío puede reconfigurarse y pasar
por otro camino de nodos. Si la falla es de software, un nodo puede reparar a

30
otro por medio de scripts y rutinas de monitoreo y auto-reparación. Ante la
instalación de un nuevo nodo, el resto puede auto-configurar al nuevo. Y al no
necesitar de disponer internet en toda la red, sino en los Gateway, el costo es
mucho menor tanto en hardware como en servicio de conectividad. Claro que,
así como tiene ventajas, también tienen desventajas. Una de ellas es la
latencia. Un nodo enviando a otro y ese a otro puede resultar en que la
recepción de datos sea muy lenta, por lo que no son recomendables para
entornos en que necesitemos inmediates en los datos. De la misma forma,
tampoco son recomendables para la transferencia de grandes volúmenes
como pueden ser las imágenes y los archivos de audio, que pueden hacer
colapsar estas redes o bloquear caminos.

Fuente: https://boosthigh.com/mesh-network-for-iot-devices/

En conclusión, la topología MESH es una excelente opción para entornos

donde no tengamos servicios de conectividad, donde el tiempo de entrega del
dato no sea crítico o bien donde querramos tener una gran cobertura y
minimizar nuestro costo de implementación, como en las ciudades o bien en el
campo.

31
Protocolos

Los protocolos son mecanismos, configurados por una serie de reglas, que
permiten la comunicación entre dos entidades y trasmitir información entre
ellas de modo que estas se “entiendan”. Hay protocolos para distintos usos,
como HTTP para páginas web, FTP para transferencia de archivos o DNS para
los servicios de nombres de dominios. En el univers de IoT también hay una
serie de protocolos que permiten la comunicación entre dispositivos y
plataformas. El más comúnmente utilizado es MQTT (Message Queuing
Telemetry Transport), aunque también existen otros protocolos de utilidades
específicas que vamos a descrubrir a continuación.

• MQTT, según su define en MQTT.org, es un protocolo OASIS

(Organization for the Advancement of Structured Information
Standards) de mensajería estándar para Internet of Things diseñado
por IBM a fines de los 90’s . Este protocolo está diseñado para ser
ultra-liviano, ideal para los casos en que tenemos poco ancho de
banda o escasa conectividad y debamos enviar pequeños paquetes de
información. En su nombre usa la palabra “Telemetry” y es justamente
porque se utiliza principalmente para transportar mensajes con
mediciones de parámetros de un dispositivo o maquinaria a un
concentrador. Utiliza un modelo de cola de mensajes en la que los
dispositivos publican sus mediciones y se suscriben para recibir
mensajes de otros dispositivos o centros de monitoreo de los cuales
recibir órdenes de ejecución.
• El protocolo AMQP (Advanced Messege Queuing Protocol), a
diferencia de MQTT, es de código abierto y su arquitectura es centrada
principalmente en operaciones y transacciones. Este protocolo se
originó en la industria bancaria como protocolo transaccional y se
utilizaba como mensajero entre servidores, ya que puede procesar
grandes volúmenes de transacciones de forma confiable y segura. Y
con confiable nos referimos a que está diseñado para no perder
mensajes ya que estos trasladaban transacciones financieras críticas
para las entidades bancarias y sus clientes. Es por eso que, si bien no
fue diseñado para IoT, tiene grandes benerficios en el control de

32
 dispositivos y al operar al nivel de aplicaciones es un mensajero muy
útil para aplicaciones IoT.
• DDS (Data Distributed Service) es un protocolo utilizado
principalmente para sistemas de tiempo real. Es un estándar de M2M
(machine to machine) cuyo propósito es el intercambio de información
en sistemas de alto rendimiento y alta interoperabilidad. Fue diseñado
para entornos muy específicos que tiene un intercambio de mensajes
intenso y crítico como los vehículos autónomos, disposivos médicos,
control aéreo y otros sistemas complejos. Es el más eficiente en la
distribución de mensajes, ya que puede enviar millones por segundo
con gran exactitud en cómo los distrubuye.
• El ex-Jabber y ahora llamdado XMPP (Extensible Messaging and
Presence Protocol), es un protocolo con la particularidad de ser basado
en XML y diseñado para sistemas escalables, de crecimiento sostenido.
Su principal propósito era la mensajería instantánea entre personas.
Esta característica es por la que se lo relaciona directamente con el
monitoreo de personas, y últimamente tiene grandes usos en la
industria de los videojuegos para la realidad aumentada. Su software
es libre y de código abierto.
• Finalmente, el protocolo CoAP (Constrained Application Protocol) el
cual fue diseñado para “dispositivos limitados” o “constrained
devices”. Y por limitados nos referimos a los recursos con los que
cuenta, ya sea procesamiento, memoria, power o conectividad. Este
tipo de dispositivos que se encuentran en contextos difíciles para
operar o que están conectados a redes muy inestables en las que la
información se puede perder, utilizan este protocolo para
comunicarse. Se emplean paquetes mucho más pequeños que los
protocolos descriptos anteriormente y este corre sobre UDP a
diferencia del resto que lo hace sobre TCP, aunque está preparado
para operar con HTTP y APIs REST por medio de la configuración de
proxies.

33
 Protocolo Características Usos
MQTT • Liviano • Ancho de banda limitado
• Modelo Publish- • Envío de paquetes o
Subscribe códigos pequeños
• Bajo consumo de • Dispositivos simples y
recursos pequeños
(procesamiento, • Princilpamente utilizado
memoria, para telemetría o
alimentación) monitoreo remoto de
• OASIS Standard activos
• Parte de la familia • Utilizado a un nivel de
TCP hardware y en sistemas
• El más utilizado en embebidos
plataformas de nube
como Azure, AWS,
IBM o Google.
• Centrado en los
dispositivos
AMPQ • De código abierto • Utilizado a un nivel de
• Modelo punto-a- aplicaciones y en
punto o Publish- sistemas de control.
Subscribe. • Orientado a la
• Altamente comunicación entre
compatible con servidores.
mensajería de • Los “dispositivos” pueden
aplicaciones ser frecuentemente
• Soporta encriptación teléfonos móviles
de los mensajes end-
to-end
• Centrado en las
aplicaciones
DDS • Modelo Publish- • Sistemas complejos y de
subscribe tiempo real
• Comunicación directa • Industrias específicas
entre dispositivos como la aeroespacial,
• Bus de integración de aeronáutica, automotríz,
alto rendimiento para servicios de energía entre
maquinaria otras.
inteligente • Sistemas embebidos de
• Centrado en los datos alto rendimiento

XMPP • Basado en XML • Sistemas casi tiempo real

• Parte de la familia • Sistemas donde los
TPC dispositivos están
• Intercambio de datos dispersos y no tienen

34
 estructurados relación entre si
• Punto-a-punto o • Orientado a aplicaciones
persona-a-persona de consumidores finales y
• Arquitectura cliente- el control remoto de
servidor dispositivos en tiempo casi
• Centrado en las real (como
personas electrodomésticos desde
un celular o por control de
voz)

CoAP • Opera sobre UDP • Diseñado para dispositivos

• Permite conexiones limitados en recursos
entre dispositivos y (constrained devices)
entre nodos para • Popularmente utilizado en
distribuirse la automatización de
información. edificios inteligentes y
• Arquitectura cliente- control de consumo de
servidor energía.
• Centrado en la
transferencia de
datos
Fuente y más detalles: https://build5nines.com/top-iot-messaging-
protocols/

Plataformas

Las plataformas son el tercer componente fundamental en las

soluciones de IoT. Ya conocimos los dispositivos y las redes que
podemos utilizar para las implementaciones dependiendo el contexto
de nuestro caso de uso. La elección de nuestra plataforma tendrá
relación con muchos factores y la oferta también es amplia. Cuando
hagamos nuestra investigación, tendremos que tener en cuenta las
prestaciones de cada una, nuestro nivel de conocimiento de desarrollo,
la capacidad de integración con otros sistemas, los protocolos que
tiene definidos (si los tiene) y otras APIs que haya en ella y el costo por
su uso, que es un factor crítico a medida que nuestra solución escala.

35
 Empecemos por describir de qué hablamos cuando nos referimos a
plataformas. Estas son la base escencial para el desarrollo de
aplicaciones y servicios, ya que nos brindan un entorno en el que
poder crear nuestros proyectos. Según lo define Link-Labs3, las
plataformas son un software de soporte para conectar dispositivos,
puntos de acceso y redes de datos a otros puntos de la cadena de
valor. Quisiera resaltar la mención sobre la cadena de valor en la
definición, ya que son justamente los resultados y la información que
obtengamos por medio de la plataforma los que utilizaremos
probablemente como fuente de datos valiosos para sistemas de
gestión de como SAP, Maximo, fracttal, Oracle, Salesforce u otros del
mercado. Es importante mencionar que los servicios de mensajería no
son suficientes para incluirlos como plataformas de IoT, como es el
caso de Twillio o RabitMQ, sino que una plataforma nos debe
proporcionar capacidades de desarrollo de aplicaciones e integración.

Al utilizar una plataforma, tendremos resueltas dificultades con las que

nos podemos encontrar cuando estamos empezando a aprender y
emprender, como es la configuración de servidores, bases de datos,
definición de protocolos y estándares y seguridad. Todo esto se puede
simplificar significativamente con la decisión que tomemos sobre la
plataforma que utilizar.

Mientras estamos en una etapa de prototipado, esto puede parecer

poco importante. Sin embargo, puede cambiar completamente la
dirección de nuestro proyecto, comprometer nuestro time-to-market
(tiempo en que está lista la solución para comercializarse) y
presupuesto. El sólo hecho de cambiar de plataforma puede
significarnos gastos no planificados como contratar nuevos recursos o
dedicar tiempo a aprender sobre la nueva plataforma
(comprometiendo así nuestros tiempos de entrega), como también
generar retrasos por el re-coding, migración y adaptación de nuestra
solución en el nuevo entorno.

36
¿Qué debemos tener en cuenta para elegir la
plataforma?

En primer lugar debemos evaluar nuestro nivel de conocimiento o el

de nuestro equipo de trabajo. Si estamos en una etapa inicial de
aprendizaje, y no tenemos un profundo conocimiento sobre
programación de componentes o definición de protocolos, lo mejor
que podemos hacer es iniciar con una plataforma que nos facilite estos
recursos. Podemos empezar de cero en una plataforma de
programación modular o en bloque que tenga la mayor cantidad de
componentes pre-definidos y que estos sean facilmente integrables.
Comunmente este tipo de plataformas las encontramos en los
proveedores de nube más populares, que además de la plataforma de
IoT, en la que podemos dar de alta nuestros dispositivos y access
points y definir las estructuras de datos facilmente, también cuentan
con otros microservicios que podemos iniciar e integrar a nuestro
proyecto de IoT con tan sólo algunos clicks. Es importante mencionar
que cuanto más básica sea la plataforma, menos costosa pero a su vez
nos requerirá mayor esfuerzo de desarrollo y es significa mayor
inversión en tiempo o profesionales con mayor conocimiento. Por
ejemplo, AWS IoT es una opción muy económica para iniciar, sin
embargo sus funcionalidades son limitadas, ya que funciona más bien
como un servicio de mensajería del estilo de Twilio. Esto significa que
deberemos desarrollar nuestros tableros, programar reglas, crear y
relacionar bases de datos etc. En cambio, plataformas como
ThingWorx tienen resuelto en un único lugar, o bien IBM IoT Platform
que cuenta con un entorno en el que prácticamente no necesitamos
escribir código para tener nuestro prototipo funcionando. Los grandes
proveedores de nubes como Google, AWS, Microsoft e IBM son
además quienes cuentan con servicios de inteligencia artificial,
mensajería, edge computing, blockchain así como también
infraestrucutura, plataformas y software como servicio. Esto significa
que además podemos conectar nuestro proyecto de IoT a aplicaciones
o servicios cloud-native y crear nuestros propios tableros de

37
 visualización, todo en un único entorno en el que vayamos a
administrar nuestros recursos.

Si ya identificamos nuestras capacidad de desarrollo, ahora debemos

definir nuestro modelo de negocio. Esto significa determinar de qué
manera vamos a comercializar nuestra solución. En IoT podemos
encontrarnos con dos tipos de soluciones: las que son principalmente
enfocadas en un alto despliegue de hardware y las que el valor de la
solución está alrededor de los datos y nuestros clientes se suscriben al
acceso a estos. La primera generalmente cuenta con hardware
complejo y costoso que se desarrolla ad-hoc (a medida). Por ejemplo,
una solución de logística, donde tendremos vehículos conectados para
monitorear la eficiencia en el manejo, el uso del combustible y la
optimización de rutas, probablemente nuestro modelo de negocio sea
por vehículo, y de esta forma incluieremos el costo de la plataforma en
cada dispositivo instalado. En este escenario podemos utilizar
plataformas como la de la compañía Bosch, y así tendremos mayor
integración de protocolos y estándares industriales ya pre-
establecidos. En cambio, en el caso de una solución para la agricultura,
podemos encontrarnos con dispositivos más sensillos. Entonces la
complejidad y por ende valor estará en los datos recolectados, la
forma en que los disponibilizamos (visualización) y la integración con
otros servicios como APIs de clima o inteligencia artificial. Este
escenario nos puede llevar a un modelo de negocio por suscripción y
entonces nuestra plataforma deberá ser una que nos facilite estas
integraciones como las de los grandes proveedores de nube que
mencionamos anteriormente.

Con el modelo de negocio definido y el nivel de complejidad en

términos de programación y conocimiento que podemos manejar,
estamos en condiciones de elegir nuestra plataforma. En la siguiente
tabla se resume qué plataformas utilizar en cada caso:

38
Security of things: ¿cómo prevenir que nuestra solución de
IoT se convierta en un backdoor?
La seguridad es y debe ser, ante todo, una prioridad dentro de cualquier
organización por muchos motivos. Veracidad, trazabilidad, autenticidad e
integridad son palabras que se nos vienen a la mente cuando pensamos en qué
cosas son importantes al momento de proteger los datos que manipulamos.
Esto no es distinto cuando hablamos de Internet of Things, ya que justamente
se trata de recolectar tantos datos del entorno como sean posibles y a su vez
actuar directamente sobre objetos del mundo real. Pensemos por un
momento en la Internet of Medical Things (IoMT): dispositivos médicos de
cuidado de pacientes conectados a internet. ¿Qué pasaría si estos sufren un
ciberataque? Si pensaron que pueden poner en riesgo la vida de los pacientes,
están en lo correcto. ¿Y qué pasaría si vehículos conectados fueran atacados?
Mismo descenlance. Incluso la industria en general, que lentamente se
sumerge en la industria 4.0, se enfrenta a también a los desafíos de la
seguridad en toda la cadena. Y con cadena nos referimos a los tres grandes
pilares que definimos en la sección anterior: dispositivos (sensores,
actuadores, endpoints, etc), redes y plataformas, que en este caso vamos a
ampliarlo a “software” en general, ya que el problema se extiende no sólo a las
plataformas sino al firmware de los dispositivos, el software de otros sistemas
de la red y más que vamos a descrubir en esta sección. A la vez que aparecen
más casos de uso y la tecnología se expande y se instala, también más son los
puntos de vulnerabilidad que pueden ser explotados por ciberatacantes. Según
Irfan Saif, Advisory Leader en Deloitte, “Más información crea más
posibilidades de crear valor: esta es la promesa de IoT”. Además, asegura que
“el manejo de la ciberseguridad y de la innovación deben ser tomados con la
misma relevancia”. Y eso es completamente cierto: IoT puede ser un arma de
doble filo, puede crear oportunidades de innovación para las empresas, pero
también oportunidades para ciberatacantes para robar datos, crear
denegaciones de servicio masivas, vulnerar las redes, adulterar información y
violar la privacidad de una organización. Pero no debemos entrar en pánico. Si
bien aún no hay aún un estándar global de manejo de los riesgos en IoT, hay
buenas prácticas que podemos aplicar. Al momento de crear un nuevo uso de
la tecnología, debemos poner máxima atención en cada eslavón de la cadena y
que la seguridad sea debidamente tenida en cuenta.

39
Algunos datos interesantes:
• La compañía de seguridad SonicWall, que se encarga de bloquear 26
millones de ataques de malware por día, asegura que en los últimos 3
meses de 2020 se registró un incremento del 40% en los ataques con
el creciente número de dispostivos conectados.
• Unit42 publicó en su reporte del 2020 sobre amenazas a sistemas IoT
que el 98% del tráfico de datos generados por dispositivos IoT no está
encriptado. El mismo reporte arroja que el 57% de los dispositivos son
vulnerables a ciberataques de severidades medias y altas, y el 41% de
los ataques explotan las vulnerabilidades de los dispositivos.
• Una encuesta a 630 ejecutivos realizada por el Ponemon Instutute
reveló que 9 de 10 empresas esperan un ciberataque en sus entornos
de IoT.

Potenciales riesgos de seguridad en cada parte de una solución de IoT:

Fuente: IoT Analytics

40
Seguridad física o hardware security: el primer eslavón de la cadena son los
dispositivos. Estos son incluso el eslavón más débil, porque no sólo el hecho de
ser vulneradoscompromete los datos y la operación de una industria, sino que
también por su interacción con el mundo real pueden generar grandes
pérdidas económicas y poner en riesgo la vida de los usuarios. Las soluciones
de IoT involucran, indefectiblemente, dispositivos que en muchos casos están
dispersos en áreas remotas y aisladas. Esto se vuelve una ventana de
oportunidad para ciberatacantes para adulterar y vulnerar los dispositivos y así
acceder a nuestro entorno.

Y hablamos de adulterar el hardware porque los ataques se han vuelto cada

vez más sofisticados. Ya no alcanza con hacer seguro el firmware para ese
hardware, ni agregar capacidad de cómputo a nuestras placas para instalar
medidas criptográficas. Tenemos que proteger el silicio mismo. Como es en el
caso de los “Rowhammer attacks” en las memorias DRAM. A medida que los
componentes se vuelven más pequeños y hay un mayor número de
transistores por nanómetro, estos transistores pueden generar interferencias
entre ellos mismos. Claro que esto está controlado por los fabricantes de
hardware, aunque también es un efecto inevitable por la limitación física de
estos componentes. Pero ¿qué pasaría si explotamos esa interferencia
controlada y la descontrolamos? Los ciberatacantes pueden corromper o
borrar celdas de memoria y manipular el boot de nuestro dispositivo. Otro tipo
de ataque físico es el llamado “Side-Channel Attack”. Estos explotan el
funcionamiento mismo del dispositivo para comprenderlo y así manipular su
comportamiento. Podemos dar un ejemplo de Side-Channel Attack
comparándolo con la forma en que se trataban de abrir las cajas fuertes en las
películas: una persona escuchando con un estetoscopio el mecanismo de la
caja fuerte, y ante el cambio en el patrón del sonido, podía descifrar la clave.
En el mundo de IoT o de la informática en general, funciona de la misma
manera sólo que lo que se observa es el comportamiento de los
microcontroladores y variables como el tiempo que puede tomar ejecutar un
proceso, la energía que consume el envío de un dato respecto de otras
funciones y el sonido de los componentes. También son conocidos los ataques
de manipulación o “Tampering” de los datos físicos del hardware, en los que el

41
ciberatacante tiene acceso a este, y lo adultera para insertar código malicioso
en celdal de memoria o en el envío de los datos.

Para mitigar las vulnerabildiades físicas de los microcontroladores, tenemos

que introducir un concepto que es la “Raiz de la Confianza” o “Root of Trust”
en inglés, de ahora en adelante RoT. Estas son la base de la securidad para los
SoC (system on chips), microcontroladores y microprocesadores. La RoT
contiene las claves de las funciones criptográficas de los SoC y son las que
permiten un arranque (booteo) seguro e inmutable. Su diseño es basado en la
seguridad del hardware, y estas RoT pueden ser un módulo independiente de
seguridad (físico) o bien puede programarse dentro de un procesador.

Dentro de la primera opción encontramos pequeños controladores que

ejecutan funciones específicas de seguridad como encriptación, validación de
certificados y administración de claves. Aunque puedan ser más seguros por la
complejidad de su encapsulmiento, estos son componentes fijos y eso puede
verse como una desventaja frente a los programables que pueden actualizarse
constantemente y estar al día con las nuevas amenazas. Las arquitecturas de
procesadores que soportan RoT son específicas a ese caso de uso. La compañía
de microcontroladores ARM comercializa un sistema embebido llamado ARM
TrustZone que divide el hardware en dos para crear un entorno seguro y uno
“no-seguro”. Contienen un Trusted OS, que permite a los fabricantes de
hardware IoT desarollar dispositivos seguros que puedan interoperar con
sistemas o entornos no segurizados. ARM llama “Trusted Execution
Environment” (TEE) a esta convinación de Trusted OS sumado al RoT. Intel por
su parte, desarrolló Intel Boot Guard, un mecanismo de seguridad basado en
hardware que utiliza técnicas criptográficas en los bloques de booteo para
asegurar que este sea auténtico y que el firmware que corre en los
procesadores también lo sea.

Ahora bien, cuando hablamos de RoT programables, nos encontramos con una
mayor variedad en cuanto al hardware y además estas pueden actualizarse, de
forma que estaría menos expuestos a vulnerabilidades nuevas. Otra ventaja de
las RoT programables es que podemos extender la seguridad no sólo al
hardware sino también al firmware e incluso a las aplicaciones que se ejecutan
sobre el dispositivo. Los ciberatancantes están constantemente buscando

42
nuevas formas de vulnerar nuestros entornos, por lo que la posibilidad de
actualizar permanentemente nuestra RoT en un escenario tan dinámico resulta
mucho más efectivo para estar protegidos. Algunas RoT vienen diseñadas con
protecciones Anti-Tamper y contra ataques Side Channel.

Ya hablamos de memorias y criptochips. Ahora debemos sumar dentro del

grupo de la seguridad física al almacenamiento. A veces quizás algo tan simplre
como por ejemplo las tarjetas de almacenamiento. Nuestro sistema puede ser
seguro, tener contraseña de acceso y estar dentro de una red protegida. Pero
si el almacenamiento es un hardware removible (como un disco externo o una
SD) y no está encriptado, simplemente con removerlo y contectarlo a otro
sistema podemos acceder a los datos, corromperlos y reinsertar este
almacenamiento en el dispositivo atacado. Es muy probable que los
dispositivos o incluso en el gateway tengan algún volumen de almacenamiento
persistente. Para los dispositivos edge esto es inevitable ya que los necesitan
para procesar en el lugar y guardar los resultados. La seguridad del
almacenamiento es entonces un imperativo para prevenir que sea vulnerados
con malware o bien que la información sea robada o destruida. La mayoría de
los fabricantes de tarjetas de memoria o discos desarrollan también modelos
que incluyen tecnología de encriptación y seguridad, ya que existe una
regulación (la FIPS 140-2) con distintos niveles de seguridad sobre el
almacenamiento. Y también es importante hacer la destrucción segura de los
datos cuando damos de baja los dispistivos de almacenamiento para que esta
no pueda ser recuperada y robada.

Seguridad de redes: la conectividad es un órgano vital para IoT. Sin internet,

deja de ser IoT como tal. Y por lo tanto, también se vuelve un punto tentador
para los atacantes. Los ataques más frecuentemente reportados hacia las
redes y los protocos son la denegación distribuida de servicio (DDoS por sus
siglas en inglés) y el spoofing. En el primero, los atacantes colapsan las redes
para derribar la aplicación o sistema, mientras que, en el segundo, el atacante
se hace pasar por un miembro más de la red y así se infiltra para dañarla o
robar información. Los dispositivos IoT, por naturaleza, están siempre
conectados, siempre visibles o esperando información, y eso los hace más

43
propensos a ser bombardeados por los atacantes y a que esa información que
esperan no sea la deseada y contenga algún tipo de malware o datos
corruptos. Y los atacantes además se están viendo beneficiados por la cantidad
de puntos abiertos. En 2016, el código fuente del malware Mirai fue difundido
para que hasta el hacker más inexperto pudiese provocar un DDoS. Este
buscaba dispositivos IoT que esté utilizando contraseñas predeterminadas
(débiles), acceden e introducen botnets que lanzan el DoS. Ese año se reportó
el DDoS más grande de la historia. Su objetivo final era el proveedor de
internet Dyn y el ataque consistía en pedidos de DNS desde decenas de
millones de direcciones IP. El ataque ocurrió a través de 100.000 dispositivos
IoT, entre cámaras IP, DVRs, impresoras y otros dispositivos. En su pico, Mirai
resultó en 400,000 bots bombardeando con más de 1.2TBps de tráfico en la
red, y como consecuencia plataformas como Nextflix, Amazon, Twitter, PayPal,
Airbnb y otras estuvieron inaccesibles por varias horas en todo el mundo.

Pero, como siempre, no hay que temer, sino prevenir. Y por suerte, hay varias
formas de anteponerse a estos ataques. También afortunadamente, lo mismo
que aplicaba para el mundo de IT, también es válido para el mundo de IoT, por
lo menos cuando nos referimos a redes:

• Software para el monitoreo del tráfico en la red.

• Crear redes exclusivas para nuestros dispositivos (VLANs)
• Desactivar las configuraciones Pliug&Play de los dispositivos
• Utilizar protocolos estándares. Deshabilitar la administración remota
de access points o routers por medio del protocolo Telnet y evitar
protocolos “custom”.
• Actualizar frecuentemente el firmware con sus parches de seguridad a
todos los dispositivos de nuestra red.
• Prevenir la conexión de dispositivos falsos a nuestra red (spoofing) por
medio de la utilización de proxies y jump hosts para ser más eficientes
en el monitoreo del tráfico.

Muchos dispositivos de IoT se contectan via wireless. Las redes Wireless

empresariales requieren WPA2-Enterprise y, usualmente, los dispositivos no
soportan este estándar. Por ese motivo, pueden crearse redes separadas sólo
para esos dispositivos y aplicar las medidas de seguridad apropiadas para ellas.

44
De esa forma se puede utilizar el mismo hardware de red para crear una red
para nuestros dispositivos.

Como conclusión, todos los proyectos y soluciones de IoT deben ser integrados
y evaluados como parte de la cadena de suministro de datos de las
organizaciones: cada participante de la cadena, administradores, proveedores,
asociados y clientes, todos deben ser considerados para aplicar las políticas de
seguridad.

Seguridad en el software: como venimos leyendo, uno de los principales

desafiós a los que se enfrentan las soluciones de IoT y lo que las retiene de
explotar al máximo en la industria es la seguridad. Pero esta no tiene sólo que
ver con la seguridad de las soluciones de IoT exclusivamente, sino del entorno
en el que se van a desplegar y con los sistemas que van a interactuar, que
pueden ser entornos inseguros o vulnerables. En un estudio de la compañía de
ciberseguridad para redes Palo Alto, en el que analizaron el tráfico de red de
1.2 millones de dispositivos IoT por medio de su software Zingbox, arrojó por
ejemplo que el 86% de los sistemas de imágenes de la industria de la salud
están operando con versiones no soportadas de Windows, lo que representa
un gran número cuando hablamos de datos médicos sensibles o incluso
ataques directos sobre los dispositivos. Ampliándolo al resto de las industrias,
descubriendo que el 98% del tráfico de IIoT no está encriptado, exponiendo así
los datos de las organizaciones. También analizaron el tipo de ataques más
frecuentes y entre ellos encontraron entre los porcentajes más altos, el
escaneo de redes, mal manejo de contraseñas y malware en todas sus formas:
botnets para provocar caídas del servicio (DDoS), Ransomware para
extorsionar a los propietarios de los datos, gusanos y trojanos para infectar
nuestros entornos y sabotearlos.

45
https://unit42.paloaltonetworks.com/iot-threat-report-2020/

Por otro lado, la falta de buenas prácticas de seguridad en los fabricantes de

dispositivos puede resultar en aplicaciones que expongan nuestra seguridad y
la de nuestros sistemas. Electrodomésticos inteligentes o wearables pueden
volverse un backdoor cuando hablamos de IoT. Pensemos por un momento en
un smartwatch que tiene su bluetooth encedido y visible constantemente. Por
otro lado, un refrigerador inteligente puede mostrar las claves de nuestro mail
personal y estas accederse desde un gestor de huellas que, si le damos la
misma MAC que a nuestro reloj, podemos obtener fácilmente. Es por eso que
al momento de desarrollar aplicaciones para soluciones de IoT debemos tener
en cuenta:

• Requerir claves seguras o contemplar doble factor de autenticación

• Mantener como las versiones de sistema operativo en versiones con
soporte activo
• Monitorear y actualizar el firmware de todos los dispositivos de
nuestra red: desde los dispositivos inteligentes hasta las impresoras,
todos pueden transformarse en un backdoor.

46
 • Proteger el almacenamiento con software de encriptación
• Prevenir manipulación directa del hardware.
• Capacitar al personal y adoptar una cultura de riesgo.

Otra posible via de ataque para los sistemas de IoT en cuanto al software, es la
privacidad y seguridad de los datos. Microsoft asegura que la seguridad de IoT
todavía se ve demorada en su evolución ya que el 60% de los empleados de
una compañía utilizan los dispositivos de la organización para usos personales
y más del 80% admite instalar aplicaciones no autorizadas. Esto resulta en que
los ataques resulten en 75% motivo del robo de credenciales y con ellos más
de 1.5 millones de logins fraudulentos por día.

La seguridad en una organización debe tenerse en cuenta en todo el entorno

de IT y todo el tiempo, no sólo al momento de adquirir nuevas soluciones.

En cuanto a la seguridad del software de IoT estrictamente, hay varios

mecanismos y buenas prácticas que podemos adoptar. Una de ellas es la
autenticación multiple (multiple-factor authetication). Cuantos más pasos se
necesiten (sin volverlo tedioso por ello), más seguro puede volverse nuestro
sistema. La utiliazación de multiples vías de autenticación con información
única y personal puede desincentivar esta vía de ataque. Esta forma es muy
recomendada en sistemas de automóviles inteligentes, oficinas y hogares,
donde lo más sensible y lo que más debemos a cuidar y asegurar es la
identidad del usuario. Otro método es el manejo de llaves públicas y privadas.
Estas permiten a los usuarios hacer comunicaciones seguras, intercambio de
información y de dinero. Este sistema no es nuevo a las aplicaciones de IT en
general y se apata perfectamente a las soluciones de IoT, permitendo pagos
virtuales en terminales remotas, acceso a sistemas de gestión y monitoreo
remoto y trasferencia segura de datos sobre mediciones de nuestros entornos.

Finalmente, el uso de inteligencia artificial puede sumarse a los recursos

disponibles para brindar mayor seguridad. Analizando patrones de
comportamiento en el dispositivo y en las aplicaciones, recolectando datos y
co-relacionando eventos podemos identificar potenciales amenzas, prevenir
las conocidas e incluso detectar nuevas.

47
IIOT & AIOT
Ahora que sabemos más sobre sensores, plataformas y redes y lo importante
de la seguridad, podemos empezar a hablar las distintas combinaciones y usos.
Así como la tecnología en general sigue en constante evolución, también lo
hace IoT y las nuevas integraciones que empiezan a ser posibles. Y con cada
integración, es que IoT empieza a segmentarse y a tener campos específicos de
aplicación. Los que vamos a describir a continuación son IIoT (Industrial
Internet of Things) como el segmento dedidado específicamente al uso
industrial, y AIoT (Artificial Intelligence of Things). Y estos pueden combinarse
ya que para el uso industrial muchas veces vamos a aplicar el uso de
inteligencia artificial.

En el caso de IIoT, este consiste pricipalmente en la interconexión de

maquinaria industrial para los procesos de manufactura, cadena de sumistro y
sistemas de gestión. Tradicionalmente, en el ámbito industrial, se hablada de
OT (Operational Technology) al hardware y software dedicado al monitoreo y
control de la maquinaria de una industria y, por otro lado, del conocido IT
(Information Technology) para gestión de toda la información digital que se
administra dentro de una organización. En la situación actual, OT/IT comienzan
a converger y a tomar cada vez más la forma de IIoT, donde además de
gestionar, controlar y monitorear la maquinaria, podemos tener un mayor
conocimiento sobre el rendimiento y operaciónde. Así, vamos a enteder no
sólo el comportamiento de la maquinaria, sino también su entorno, y a partir
de la recolección y el análisis de datos los datos hacer más eficientes los
procesos y prevenir de antemano situaciones no deseadas y reducir las
inesperdas. El objetivo es poder cambiar el paradigma, de una OT/IT reactiva,
que utiliza la tecnología para poder reaccionar al momento de la detección de
un problema, a una IIoT preventiva se anticipe a los problemas y que además
unifique y simplifique el acceso a la información de la operación para mejorar
el proceso de toma de decisiones basadas en datos relevantes.

48
https://www.ge.com/digital/sites/default/files/download_assets/lns_smartco
nnectedoperations_ge.pdf (página 10)

Convergencia IT/OT y madurez de IIoT

Por otro lado, AIoT puede ser estar destinado tanto en el ámbito industrial
como hacia los usuarios finales. “Artificial Itelligence of Things” es la rama de
IoT en la que sumamos a nuestra solución la utlización de inteligencia artificial.
Esta puede tener como objetivo hacer mantenimiento prescriptivo, ser un
asistente virtual en campo, o hacer análisis de calidad en una línea de
producción por medio de imánges. También, podemos pensar como AIoT
soluciones de ciudades inteligentes para prevenir congestiones de tránsito,
alertar situaciones delictivas o peligrosas para los ciudadanos u optimizar las
rutas de recolección de residuos. Son muchos los casos de uso y los más
populares en AIoT son los de analítica de video y de audio. Las imágenes y
videos se utilizan principalmente cuando desarrollamos una solución de

49
videoanalítica como, por ejemplo, para analizar calidad en una línea de
producción o bien controlar que los operarios de una planta cuenten con todos
sus elementos de seguridad para sus tareas. El caso del audio se utiliza
comunmente identificar patrones y cambios en el funcionamiento de un
equipo. Como usuarios, nos ha pasado más de una vez la situación de estar
manejando nuestro vehículo y “escuchar un ruidito”. Ese ruido, distinto al
esperado, en el mundo del mantenimiento predictivo se detecta con una red
neuronal (machine learning) entrenada con frecuencias catalogadas como
buen funcionamiento del equipo, y al detectarse una diferente, se la registra
como anomalía y podemos así prevenir que el equipo falle o se deteriore.

Si sos maker, estás empezando a emprender, o parte de una coporación o líder

de operación y estás sumergiéndote en el mundo de la industria conectada o
Industria 4.0, voy a describirte algunos de los términos con los que puedas
encontrarte en el ámbito del IIoT. Cada uno de ellos está conectado al otro y
pueden ir sumándose de manera incremental y evolutiva en el proceso de
llevar a la industria al su objetivo final: la excelencia operacional.

El camino a la excelencia operacional:

Si bien no sólo depende de las “operaciones conectadas”, como vamos a

descubrir a continuación, está fuertemente ligada a las buenas prácticas y a la
máxima eficiencia operativa, el compromiso con la seguridad de las personas y
con la calidad, la seguridad en los procesos, el buen liderazgo y la ética,
capacitación constante y la innovación como cultura de la organización. Y todo
esto puede estar apalancado por una estrategia de transformación digital que
genere como resultado un desarrollo sostenible de los objetivos de la empresa
y en el desempeño a todos los niveles de la compañía. Analicemos cada una de
las prácticas que las industrias pueden adoptar para optimizar sus procesos
productivos.

50
Fuente: https://www.fostec.com/en/competences/digitalisation-
strategy/digital-operational-excellence/

• Mantenimiento Predictivo: probablemente el más popular en el

mundo industrial. Y es el más popular, porque si bien hay algo más
nuevo que es el mantenimiento prescriptivo, es el que hoy es de más
fácil implementación y despliegue. Hay 4 tipos de mantenimiento para
el equipamento y maquinaria de una planta. Empezando por el más
antiguo, tenemos el mantenimiento correctivo, que sucede cuando la
falla ya ocurrió (pos-evento). En este escenario, la producción ya se vió
afectada y detenida por la falla de la maquinaria o bien porque se
hayan dado condiciones desfavorables no detectadas a tiempo, y el
operario la corrige o repara una vez sucedida la interrepción. El
segundo es el preventivo, que son escencialmente mantenimientos
planificados de rutina, ya sea por períodos recomendados por los
fabricantes o bien basadas en la experiencia de los operarios. Este
resulta muy útil (y lo sigue siendo en algunos casos) pero produce
también muchas ineficiencias. Imaginen una cuadrilla que va a cambiar
un medidor de caudal de gas a una boca de pozo de forma preventiva.
Para esto se destinan recursos (personas, combustible, tiempo y
repuestos), lo que se traduce en dinero mal invertido y el resultado
puede ser desfavorable, ya que probablemente no sólo ese
caudalímetro tenga mayor vida útil, sino que al mismo tiempo y a
decenas de kilómetros puede haber un caudalímetro fallando,

51
 arrojando mediciones erróneas y a punto de romperse y no nos
enteramos hasta que sucede. O bien que seamos notificados de una
fuga, pero sin saber qué parte está fallando, llevamos todo tipo de
repuestos o hacemos más de un viaje, lo cual es muy ineficiente. Y es
esto último lo que el mantenimiento predictivo viene a corregir. Al
desplegar una arquitectura de IoT y aplicando Big Data y Machine
Learning, podemos empezar a precedir un suceso antes de que ocurra.
Esto no es por arte de magia: los sensores están constantemente
midiendo variales de contexto y caputurando los parámetros de los
dispositivos. Esto nos permite crear modelos que identifiquen
patrones de comportamiento y que entonces el mantenimiento lo
hagamos cuando el equipo empieza a mostrar signos de deterioro, es
decir, su comportamiento cambia. Volvamos al caudalímetro de gas: si
a este podemos conectarlo a internet, ya sea porque tenemos
cobertura o bien porque armamos una arquitectura de red MESH y
capturar sus mediciones. Adicionalmente entrenamos un modelo de
machine learning para identificar cambios en el patrón de
comportamiento y definimos reglas para los cambios esperables y los
que no lo son y podemos saber qué está sucediendo en el pozo sin
estar físicamente en él. Y no sólo vamos a conocer el estado del
caudalímetro en si, sino de todo el pozo. Si creamos las reglas
adecuadas, podemos prevenir situaciones, por ejemplo, si el
caudalímetro arroja mediociones erráticas, pero los demás en el
mismo pozo se mantienen dentro de los valores esperables, el
problema estará en el caudalímetro. Si todos los caudalímetros están
arrojando valores no esperamos, el problema estará en el pozo y así
seguimos entrenando nuestro modelo con todos esos patrones de
comportamiento que vamos identificando para anticipar nuevas
ocurrencias. Y es así como llegamos al último tipo de mantenimiento,
el más reciente y por el momento (aunque es cuestión de tiempo) el
más complejo, El mantenimiento prescriptivo, es como el preventido y
se le suma el factor de inteligencia artificial. En este tipo de
mantenimiento, no sólo prevenimos, sino que además el sistema
recomienda cuándo y en qué condiciones es más favorable y por ende
conveniente hacer el mantenimiento. Ahora no sólo vamos a saber
que el caudalímetro está empezando a mostrar signos de deterioro,

52
 sino que también vamos a saber qué día vamos a tener stock del
repuesto (porque lo integramos a nuestra cadena de suministro), si el
clima va a ser bueno para salir con la cuadrilla (porque lo integramos
con una API de clima) y tener la capacidad coordinar con otras tareas
de mantenimiento por la zona. Además, el mantenimiento prescriptivo
recomienda y sugiere acciones para evitar que se den las condiciones
que puedan producir una falla. En este vamos a necesitar no sólo un
gran despliegue tecnológico sino, antes de eso, un alto nivel de
digitalización, de integración en los sistemas de gestión y de
disponibilidad de datos históricos homogéneos. Es un trabajo primero
de estandarización y digitalización para empezar el camino hacia este
tipo de mantenimiento y es hacia lo que apunta la industria 4.0.

• Edge Computing (computación al “borde”): de las definiciones

formales, la que más me gusta es la que comparte la compañía
Gigabyte, que dice (traducido) “Edge Computing es un tipo de
arquitectura de red computacional, donde el cómputo se coloca lo más
cerca posible de la fuente de datos, para reducir la latencia y el tráfico
de datos”2. Lo que se logra, fundamentalmente, es que los datos que
se colectan sean procesados lo más cerca posible (“al borde”) de quien
los produce, y así el tiempo de respuesta sea mucho mayor o incluso
en tiempo real. Además de optimizar el uso de las redes y permitirnos
así hacer implementaciones de mayor despliegue. Este tipo de
arquitecturas se utilizan, por ejemplo, en implementaciones de video
analítica, donde los datos que se analizan son imágenes y
generalmente el resultado de ese análisis debe verse en tiempo real.
Pensemos por ejemplo en una línea de manufactura de vehículos. El
análisis de calidad puede realizarse con una solución de video analítica,
modelos de machine learning entrenados para detectar golpes,
rayones, fallas de color, etc. Pero para eso, necesitaríamos que la o las
cámaras estén conectadas a internet y mandar esos videos por la red a
la nube para procesar las imágenes y producir los resultados. ¿Qué
estamos comprometiendo? Por un lado, lo que estamos
compromentiendo es la capacidad de la red, ya que deberíamos
transferir videos de buena calidad, ya que, en una fábrica, no
tendríamos una línea de producción sino muchas. Y esta fuese

53
 suficiente, también tenemos la limitación en la subida de datos a la
nube. Y por otro lado, estamos comprometiendo el tiempo de
respuesta de la solución, dado que lo esperable sería hacer el análisis
de calidad en tiempo real. Esto se simplifica si ponemos la capacidad
de procesamiento en el “edge”, donde podemos desplegar las cámaras
y un servidor con la capacidad de cómputo suficiente para correr los
modelos de machine learning necesarios para analizar esas imágenes y
detectar las fallas sobre los cuales la hayamos entrenado. Lo que
vamos a enviar desde el “edge” hacia la central de control serán los
resultados de esa evaluación de calidad.

• Digital Twins (gemelos digitales): en los últimos años, se popularizó el

uso de Digital Twins en el mundo industria, aunque aún no ha llegado a
masificarse ya que su desarrollo demanda una gran cantidad de
recursos tecnológicos y conocimiento especializado sobre modelos
matemáticos y explotación de datos. Estos son replicas virtuales de
objetos del mundo real o incluso de sistemas y procesos. Esta
tecnología tuvo sus comienzos en la NASA, con el objetivo de
monitorear, reparar y actualizar cápsulas espaciales fuera de órbita, lo
que resulta físicamente imposible. Por medio de un Digital Twin de las
cápsulas y las simulaciones necesarias, se podía obtener diagnósticos
de estado y potenciales problemas en órbita, lo que fue de vital
importancia durante la fallida misión Apollo 13 para realizar las
reparaciones y correcciones necesarias y así traer a los astronautas a
salvo a la tierra. Con el paso de los años, más industrias empezaron a
emplear esta tecnología, principalmente dentro de los procesos de
manufactura. Tener un Digital Twin significa poder diseñar un objeto,
sistema o proceso y a la vez diseñar también las simulaciones que
permitan testearlo en el ambiente y bajo las condiciones que vaya a
existir finalmente. El objetivo final del uso de esta tecnología en
ingeniería es poder optimizar el ciclo de vida del desarrollo. Imaginen
el Digital Twin de un edificio: cuando lo diseñamos en alguna
herramienta digital, ya tenemos el primer acercamiento a un DT, pero
con las medidas no nos alcanza, necesitamos simular también todo lo
que vivirá o interactuará con él: el flujo y consumo de electricidad,

54
 agua y gas, la luz natural que recibe durante el día y de dónde la recibe
para hacerlo más eficiente, qué temperatura hay en cada piso, simular
emergencias para evaluar si las áreas de circulación y evacuación están
bien diseñadas. En definitiva, le vamos dando “vida” a nuestro edificio
virtual para que sea lo más similar al real, pero no sólo el edificio como
objeto material sino también todos los estímulos externos que este
objeto recibe. Así mismo, los Digital Twins pueden ser sistemas y estos
nos permitirán entender cómo funcionará en la integración con otros
sistemas, o bien procesos pueden ser digitalizados y evaluados antes
de ser implementados.

• Connected Operations: una “operación conectada” puede contar con

todos los artefactos tecnológicos que describíamos anteriormente, con
algunos o incluso otros. Para que lo sea, estamos hablando de un nivel
de integración OT/IT avanzado, donde nuestros sistemas de gestión de
activos, de gestión de calidad, cadena de suministro, aplicaciones de
uso empresarial y de usuarios finales, y todos los recursos de IT están
estandarizados y securizados, y estos son accesibles para cualquier
operario o responsable de toma de decisiones. En todos los niveles de
la organización, los diferentes “stakeholders” (interesados) tienen en
sus manos, accesible de forma digital, la información que es relevante
para ellos en el momento que es requerida. La operación conectada
lleva de la mano un cambio estrucutural a nivel organización y un
compromiso con un proyecto a mediano largo plazo que es el de la
Tranformación de Negocio Digital (Digital Business Transformation).
Esta transformación no sólo implica el uso de tecnología, hardware y
software, como medio de optimización y eficiencia sino también del
modelo de negocio de las empresas. La sofisticación del IT de nuestra
empresa debe ser un medio, no un fin. El fin es entregar el mayor valor
para nuestros clientes y eso puede alcanzarme por medio de una
fuerte estrategia digital que lo soporte. Un ejemplo de transformación
de negocio digital (DBT) es el caso de Starbucks, que en los 2000s
experimentaba fuertes caídas en sus ventas y tuvo que cerrar muchas
de sus tiendas por el bajo rendimiento. El nivel de digitalización de
Starbucks para ese momento era tan bajo que los gerentes de tienda
siquiera tienían correo corporativo. Fue en 2008 que, después de que

55
 las acciones de Starbucks se desplomaran, que la compañía incorporó
a su staff ejecutivo un vicepresidente para negocios digitales. El
entonces CIO de Starbucks Stephen Gillet decidió que negocios
digitales necesitaba su propio vertical, y eso cambió la estrategia
corporativa y dirección de negocio de la empresa. Incorporaron wifi
gratuito en las tiendas, una tarjeta de fidelidad e invitieron en
campañas digitales por medio de redes sociales (Facebook en ese
momento). Sumaron a la estrategia el pago por medio de móviles,
billeteras digitales e hicieron del feedback de los clientes una fuente de
información para mejorar sus procesos internos y la experiencia de los
consumidores. ¡Al quitar 10 segundos de la transacción de pago por
medio de los medios digitales, redujeron el tiempo de espera en las
filas 900.000 horas al año!4

Un poco más de 10 años después, lo que nos trae a hoy, no es novedad la

posibilidad de realizar pagos por medios digitales. Sin embargo, el nivel de
digitalización de la operación y de los modelos de negocio de las empresas
sigue en pleno desarrollo.

Fuente:
https://www.ge.com/digital/sites/default/files/download_assets/lns_smartco
nnectedoperations_ge.pdf (Página 11)

56
La adopción de técnicas de IoT y la digitalización de la industria si bien se está
dando de manera conservardora, está sucediendo y es un mecanismo que
indudablemente acompaña optmización en el uso de los recursos, bajas en los
costos operativos y mejora la experiencia de los clientes. Es por esto por lo que
este libro se propone compartir las posibilidades de crear soluciones alrededor
de IoT tanto como emprendedores autónomos o dentro de una corporación. Y
es este último caso el que me inició en IoT y a continuación les comparto mi
historia.

Mi primer proyecto de IoT

Habiendo hecho esta amplia introducción al mundo de Internet of Things, y
teniendo la certeza de que este será el punto de inicio para muchos de los
lectores en el desarrollo de soluciones IoT, voy a contarles cuál fue mi
experiencia personal con el tema y cómo me llevó a aprender todo lo que está
escrito en este libro y mucho más. Mi vida laboral profesional comenzó en IBM
y es allí donde me formé como especialista y luego arquitecta, siendo esta
última la profesión que hizo relucir una de mis actividades favoritas: solucionar
problemas. Mi primer proyecto de IoT fue mientras era arquitecta de
infraestructura, pero mi inquietud en lo laboral y en el apredizaje me a esta
historia que les voy a contar. Es la historia sobre la iniciativa de un grupo de
compañeros un poco locos, pero con muchas ganas de hacer las cosas de una
manera diferente. Es la historia de cómo fui parte de este grupo y juntos con
nuestra fuerza de trabajo y entusiasmo nos encomendamos a la tarea de
emprender dentro de una corporación y fomentar la cultura de la
colaboración. Es la historia de la importancia de los espacios de ideación y
colaboración dentro de las empresas para dejar volar la creatividad y sobre un
equipo de liderazgo que nos apoyara para ejecurtarlas y lograr el impacto
positivo que tuvieron dentro del equipo, en nuestros colegas alrededor del
mundo, como también en socios y clientes.

La idea: Todo proyecto tiene su génesis en una idea. Y esa idea muchas veces
está en las cosas simples, cotidianas, alrededor de situaciones que siempre
fueron de una manera o acciones que inmutablemente se repiten día tras día,

57
hasta que descubrimos algo en ellas que podría ser diferente. Cuando notamos
esto, significa que tenemos una idea. Pero no basta con sólo con tenerla, como
asegura el autor británico Ashleigh Brilliant “Las buenas ideas son comunes, lo
que no es común es que las personas trabajen en ellas para realizarlas”. Y para
esta historia no podría estar más de acuerdo. En 2017 era parte de un equipo
de innovación muy inquieto y apasionado, dos razones por las que
constantemente aprendíamos cosas nuevas. Estábamos iniciandonos sobre
inteligencia articial, asistentes virtuales, explotación de datos, interpretación
de imágenes y creación de modelos y redes neuronales. Nos empezábamos a
sumergir en todas las capacidades de Watson (la marca por la cual IBM se
refiere a sus productos y soluciones de inteligencia artificial) y queríamos hacer
algo con eso. Hasta que, después de haber pasado por la misma puerta día tras
día, decidimos que queríamos cambiar nuestra experiencia al ingresar al
edificio. Algo tan simple y rutinario se convirtió en la principal motivación para
nuestro proyecto: queríamos construir un robot (si, un ROBOT) que nos
recibiera en la entrada de nuestras oficinas.

La motivación: Esta loca idea podría haberse difuminado en unas cuantas risas
y haber sido una anécdota en un after-office, pero fue mucho más que eso.
Queríamos ser el primer equipo en construir y desarrollar un robot asistente
impreso en 3D capáz de dialogar en español (inevitablemente con modismos
argentinos). Ese era nuestro norte, aunque había muchas incertidumbres en
esa única oración. “Construir un robot” por un lado, cosa que no teníamos idea
de cómo hacer, y “que nos recibiera” era un objetivo tan poco acotado como
suena. ¿Por dónde íbamos a empezar? Antes que nada, teníamos que
encontrar un sponsor para nuestro aun no planificado y e indefinido proyecto.
Nuestro equipo, al ser de innovación, era el lugar ideal para este tipo de
proyectos y, después de varias sesiones de trabajo y el armado de la propuesta
apropiados, tuvimos el apoyo de nuestros líderes para seguir construnir con
nuestro robot asistente. Tienen que saber también que no fue un camino llano
y felíz: no tenemos que olvidarnos que las corporaciones tienen
procedimientos, marcos regulatorios, roles y esquemas de trabajo
estrictamente definidos y en una empresa de 360.000 empleados y más de 100
años de historia no podíamos evitar encontrarnos con barreras,
cuestionamientos y reticencias, además de muchas, muchas autorizaciones. Y
si bien los ánimos y el entusiasmo inicial pudieron verse corroídos por la
burocracia corportativa, contamos con algo que toda corporación debe tener:

58
Líderes y no jefes. Líderes con capacidad de comunicar, de motivar y contener.
Líderes de talento innato en empatía e integridad. Esos líderes teníamos
nosotros y así nació y cobró vida nuestro equipo.

El equipo: Todavía recuerdo la primera reunión. 8 personas en una sala,

nuestro gerente incluído, lanzando ideas al aire y escribiéndolas en una
pizarra. En esta etapa de ideación, surgieron las ideas más divertidas y un poco
bizarras que puedan imaginarse. ¿Ya pensaron algunas? ¿Vieron que fácil es
volar con la imaginación? La idea del robot asistente, antes de ser innovadora y
revolucionaria, era aterradora para cualquier Project Manager, con tanta
incertidumbre los riesgos del proyecto podían ser muchos. Entre este pequeño
grupo estaba yo, con mis recientes conocimientos de inteligencia artificial y mi
ingeniería en sistemas en progreso, tratando de acotar los casos de uso. El
grupo era variopinto y no teníamos todos los conocimientos que el proyecto
necesitaba. Lo que no sabíamos era que iba a generar tanto entusiasmo que
terminaríamos siendo más de 50 personas trabajando en él. Teníamos de todo:
ingenieros electrónicos, desarolladores, diseñadores, project managers y hasta
un director de cine y una apasionada por las artes que hicieron un video
fantástico sobre esta historia. El equipo fue fundamental no sólo para hacer,
sino para mantenerse unido a si mismo, para motivarse, contenerse ante las
frustraciones y apoyarse en el cansacio. El equipo funcionaba como una
entidad en si misma, con su propia identidad y fuerza, que era la de todos los
que queríamos ver a este robot en la puerta del edificio dándonos la
bienvenida.

El conocimiento: ¿Cómo explicarles que no teníamos idea por dónde empezar?

Queríamos hacer un robot impreso en 3D que hablara con nosotros,
entendiera lenguaje natural (en dialecto argentino/porteño que no es cosa
menor) y nos diera instrucciones. No voy a negar que hubo muchísimas ideas
más dando vueltas, como por ejemplo que juege al truco, que nos diga el clima
y nos sirviera café. Spoiler alert: ninguna de esas pasó; teníamos que acotar el
proyecto para terminar al menos el mismo año. Si bien teníamos claro el
objetivo final, teníamos mucho que aprender en poco tiempo para llegar hasta
ahí. Y aunque nos estábamos capacitando en algunas cosas, nos faltaba

59
conocimiento sobre tantas otras. Fue así como armamos una matríz en la que
pusismos nuestros nombres en un eje y los conocimientos que necesitábamos
para el proyecto en el otro, y fuimos completandola para descrubir que
teníamos aún muchos espacios vacios. Entonces, las personas que querían
ayudar y aún no sabían cómo se comprometieron a ganar esos conocimientos
para poner su grano de arena. Para hacer el robot, necesitábamos
conocimientos de electrónica, de robótica (ROS y C), inteligencia artificial,
desarrollo de APIs, backend y frontend además de la capacidad de planificar
los hitos, los sprints, las tareas, liderar y documentar todo el proyecto. Todo en
tan sólo 6 meses.

El tiempo: 6 meses parecía un tiempo razonable cuando no teníamos noción

del esfuerzo real que nos tomaría el proyecto. Es la agridulce incertidumbre de
hacer algo por primera vez; todo se construye en función de estimaciones. El
tiempo es una de esas cosas que pueden ponerle lo pelos de punta a la
persona más calma. Un mal manejo podía comprometer el éxito de nuestro
proyecto. Pueden imaginarse que era muy fácil irse por las ramas y empezar a
volar en ideas. Las charlas después de hora siempre nos dejaban algún nuevo
“easter egg”. Estabamos construyendo un robot, y los casos de uso no paraban
de aparecer en nuestra imaginación y interferir en nuestra planificación.
También aprender lleva tiempo y ponerlo en práctica de inmediato agregaba
una presión extra ya que cualquier paso en falso representaba más demoras.
Prueba tras prueba, nuestro robot iba cobrando vida. Cada equipo iba a su
ritmo, el de hardware iba probando la integración de todos los componentes;
el de software desarrollaba el backend y las APIs; el de inteligencia artificial los
casos de uso, diálogos e interacciones con el asistente virtual, y cada uno
confiaba en el avance y compromiso del otro. Pero aún nos faltaba algo, y algo
importante. El robot se iba a imprimir en 3D, para lo que necesitábamos una
impresora. Sin ninguna de estas cosas los demás equipos habían llegado a un
punto crítico para hacer sus pruebas. La tensión en el equipo se empezaba a
notar y la frustración y el cansancio se sumaban al malestar. Y los 6 meses se
hicieron 9.

60
La impresora más grande del mundo: Permítanme ser reiterativa en eso: que
queríamos “imprimir en 3D” el robot, con una impresora que no teníamos.
Entonces la idea fue construir una, y de pronto tuvimos un segundo proyecto
dentro del primero. La impresora se convirtió en un proyecto en si mismo, con
las complejidades de que ésta sería de 1m3 (con 700cm3 de volumen
imprimible). La impresora se basó en un modelo Open Source, escalado a 1m3
y lo interesante fue que muchas de las piezas que utilizamos fueron
recuperadas de brazos robóticos de viejas librerías de cintas (algo que quizás
no conozcan pero que se usó y en algunos casos se sigue utilizando para hacer
backups de servidores y hardware de almacenamiento). Cuando tuvimos la
impresora, muchas impresiones fallaron, las piezas en algunos casos tardaban
días y luego debía pasar por un trabajo de taller de pulido, masillado y pintura
(todo hecho a mano). Los detalles llevaban tiempo, y este nos empezaba a
pesar a medida que nos acercábamos a la fecha de entrega. Aunque eso
después sería sólo una anécdota. Con el robot ya impreso y el proyecto siendo
popular dentro de la compañía a nivel global, nos enteramos de que esta
impresora 3D que habíamos construido con nuestras manos era la más grande
que IBM tendría en su historia alrededor del mundo y la única construida
desde cero por IBMers (como nos gusta llamarnos).

EMMA: así se llamaría nuestra robot. Pueden ser siglas o el nombre de una
persona, les dejo que imaginen por un momento el por qué de el nombre y se
los cuento al final. EMMA tenía nombre antes de tener forma. Cada pieza
impresa en 3D nos acercaba a la imagen final que teníamos de ella. Cada parte
ensamblada era un logro imposible de cuantificar, y verla funcionando,
ensamblarse con otra y seguir creciendo nos producía un entusiasmo
frenético. Compuesta de arduinos, Raspberry Pi, muchos sensores, cámaras,
micrófonos, parlantes y luces, muchas luces, EMMA fue nuestro sueño
materializado. Fue lo que por nueve meses nos quitó el sueño y a la vez nos
hacía soñar despiertos. Fue lo que nos unió como equipo como nada lo había
hecho hasta entonces. EMMA podía escuchar y respondernos, recibirnos en la
puerta y darnos la bienvenida, guiarnos dentro del edificio y ayudarnos a
contactar a alguien dentro de la empresa. Eso creíamos nosotros, o para eso la
habíamos diseñado, pero EMMA pudo hacer mucho más. Pudo darles sonrisas
a niños asombrados por la robot frente a ellos, pudo hacer sentir orgullosos a

61
cada uno de esos IBMer que la vieron desarrollarse y conocen su historia, pudo
abrirle un mundo de posibilidades profesionales a un equipo y llevarlos a
conocer personas de todo el mundo, incluso al liderazgo ejecutivo más alto de
la empresa. EMMA salió en diarios y revistas, visitó escuelas y eventos
multitudinarios y está ahora en este libro contando esta historia conmigo.
EMMA fue mi primer proyecto de IoT y después de ella vinieron muchos más
que espero contarles en un próximo libro.

Ah, y EMMA fue sólo un nombre que nos gustó mucho en ese momento.
Invertimos varias horas del proyecto en encontrarle algún significado poético o
un acrónimo, sin mucho éxito. Nos gusta explicar que fue un nombre que
sentimos, con la misma simpleza con la que sentimos crearla.

Les contaba al principio que es esta era una historia de emprendedurismo. Y es

así ya que después de EMMA, tuvimos nuestro propio laboratorio de Internet
of Things dentro de IBM, en el que desarrollamos prototipos y pruebas de
concepto para clientes. Muchos nuevos proyectos y oportunidades de negocio
surgieron a partir de nuestro laboratorio. El IoT Lab, como lo llamamos “entre
casa”, recibía ideas de cualquier persona que se acercara a compartirla y
repetíamos la historia de EMMA para que todos tengan la oportunidad de
explotar su creatividad y ver su sueño hacerse realidad.

Con nuestro laboratorio, comprobamos la importancia de los espacios de

innovación en las corporaciones ya que internamente fomentan la
colaboración entre pares, afianza las relaciones interpersonales, promueve el
desarrollo de nuevos talentos y mejoran el sentido de pertenencia y
compromiso con la empresa. Hacia el ecosistema y los clientes, estos espacios
abiertos de co-creación invitan a la colaboración con comunidades desarrollo y
entidades educativas, amplifican la divulgación tecnológica, además de que
habilitan nuevas oportunidades de negocio a partir del diálogo constructivo
con nuestros clientes. Decenas de actividades se llevan a cabo año tras año con
escuelas, universidades, startups, comunidades y pequeñas, medianas y
grandes empresas de todos los segmentos industriales.

62
Mi mayor deseo es que ustedes, lectores, puedan generar y contagiar una
cultura de innovación colaborativa entre colegas y líderes en sus
organizaciones, ya sea que pertenezcan a una o estén construyendo la
propia, con una única motivación por delante: crear el futuro que desean
para ustedes y para el mundo.

63
64
Mantenimiento predictivo de
máquinas industriales

65
66
Introducción

En este capítulo estudiaremos una solución basada en el Internet de las Cosas

(IoT en sus siglas en ingles – Internet of Things) para realizar el
mantenimiento preventivo de las Maquinas en el campo de la industria. En los
últimos años ha ganado mucha fuerza una idea que revoluciona el
mantenimiento de las maquinas y le permiten a las industrias tomar ventaja en
su ciclo de producción minimizando el tiempo de inactividad por el
mantenimiento de las mismas. Esta necesidad de mantener el mayor tiempo
posible la cadena de producción activa ha llevado que con el paso de los años
se desarrollen nuevos métodos que permitan planificar los mantenimientos de
las maquinas en la industria. Para poder llevar a cabo estas tareas es
importante llevar un registro de los mantenimientos y como mayor medida de
información, realizar el monitoreo de los activos en la planta industrial a fin de
anticiparse a las fallas imprevistas que pueden detener la producción en
algunos casos, más de un día.

67
Actualmente la Industria está viviendo una nueva transformación digital, en
donde los datos y la información se vuelven una pieza fundamental para el
planeamiento estratégico de las industrias en un mediano y largo plazo. Es por
eso que las nuevas nociones como Big Data, Machine Learning y el mismo
internet de las cosas empiezan a formar parte del nuevo vocabulario en el
ambiente industrial y el mantenimiento preventivo aprovechará estas nuevas
ideas, para tomar de ellas nuevas herramientas que permiten gestionar de
manera más eficientes los mantenimientos de la empresa. En este capítulo
aprenderemos a realizar de una manera sencilla el monitoreo de condiciones
de una maquina industrial para poder llevar a cabo una planificación eficiente
que minimice los tiempos de inactividad de la cadena de producción.

Tipos de Mantenimiento

Un proceso de mantenimiento es fundamental en una industria, ya que se

evitan tener paradas en la producción de manera imprevista, lo cual puede
ahorrar mucho dinero, por eso la importancia de este. Y según sea el caso que
se requiera, existen tres tipos de mantenimiento en los cuales se puede optar
por uno de ello:

• Correctivo: El que repara el equipo cuando se daña

• Preventivo: El que se realiza para que no se dañe el equipo.
• Predictivo: El que predice cuando se va a dañar el equipo para
anticipar la reparación.

Estos tres tipos de mantenimientos son sumamente importantes en la rutina

diaria de una organización o industria, por lo que se debe tomar al
mantenimiento como una inversión y no como un gasto. A la hora de
desarrollar un proceso de mantenimiento, es recomendable tomar en cuenta
los tres tipos, de acuerdo a la clase de avería que se presente en la maquinaria
o en el sistema.

68
Ventajas del mantenimiento

Realizar un mantenimiento sobre los activos de la organización puede

traernos algunas ventajas. Si realizamos un programa de revisión continua de
equipos, maquinas, componentes y sistemas podemos obtener los siguientes
beneficios:

• Reducir fallas imprevistas.

• Minimizar costos de reparación adicionales.
• Evitar la paralización de los procesos de producción.
• Ahorrar el pago de presupuestos inesperados por repuestos.
• Prevenir accidentes laborales.

Para evitar que estos contratiempos no sean frecuentes, lo recomendable es

poner en práctica un mantenimiento preventivo como primera opción.

¿Qué es el Mantenimiento Preventivo?

El proceso de revisión que se lleva cabo con anticipación en una maquinaria

es el Mantenimiento Preventivo. Esté mantenimiento se encarga de la
conservación en optimas condiciones de funcionamiento de las maquinas de
producción mediante la planificación de revisiones y tareas de mantenimiento
sobre las mismas.

El modo de programar los tiempos de mantenimiento puede ser distintos,

creando así diferentes modos de mantenimiento preventivo que discutiremos
más adelante.

Un proceso de mantenimiento normalmente implica la inspección, limpieza y

tareas de mantención sobre la maquina (Como cambio de filtros, aceites, etc.).
Una buena planificación de las tareas de mantenimiento puede reducir el
tiempo de inactividad por fallas que ocurren de manera repentina, ya que
podemos adelantarnos a estas y planificar su reparación en el momento que
menos impacto tenga sobre la producción.

69
Tipos de Mantenimiento Preventivo.
La planificación de las tareas de mantenimiento pueden ser programados en
función del tiempo o del uso.

Mantenimiento Preventivo basado en el tiempo

Un ejemplo de un mantenimiento basado en el tiempo puede ser la
planificación de las tareas de inspección periódica sobre una maquina o pieza
critica del equipo.

Mantenimiento Preventivo basado en el uso

En este caso las tareas de mantenimiento se planifican por el uso de las
maquinas, ya sea expresado en horas, kilómetros o ciclos de trabajo. El
ejemplo más claro es el motor de un vehículo, que podría ser programado para
entrar en servicio cada 10.000 km.

Mantenimiento Correctivo
Este tipo de mantenimiento es el que se realiza después ocurrida la falla, ya
que por diversas circunstancias no puede evitarse o retrasarse, ni
planificarse en el tiempo.

70
Este tipo de mantenimiento requiere un presupuesto especial, ya que para
ejecutar su proceso de reparación, se presentan costos por repuestos, aceites,
piezas, según sea el caso. Así como la paralización de la producción durante un
lapso de tiempo, que a veces es difícil determinar. Casi siempre, esa situación
genera pérdidas de trabajo y dinero por los gastos que requiere para la
reparación.

Una definición más sencilla señala que el Mantenimiento Correctivo es el que

se dedica a reponer el equipo a su normal funcionamiento. Es decir, se trata de
reparar lo que se rompe.

Mantenimiento Predictivo

El mantenimiento predictivo utiliza una serie de herramientas y técnicas que

supervisan el estado de las maquinas y equipos para predecir cuándo será el
momento en que se puede producir una falla mediante la identificación de los
indicadores de desgaste y otros problemas.

71
En este tipo de mantenimiento es en donde la intervención humana ya no es
tan necesaria para la inspección o la detección de las averías, ya que estos
trabajos pueden ser llevados a cabo por sensores que recolectan los datos y un
sistema de gestión permite visualizarlos. Por lo tanto, no es sorprendente que
el mantenimiento predictivo se haya convertido rápidamente en uno de los
principales casos de uso de la Industria 4.0 para los fabricantes y los gestores
de equipos. La aplicación de tecnologías de IoT industriales (IIoT para las siglas
en Ingles) para vigilar la salud de los activos, optimizar los programas de
mantenimiento y obtener alertas en tiempo real de los riesgos operacionales,
permite a los fabricantes reducir los costos de servicio, maximizar el tiempo de
actividad y mejorar el rendimiento de la producción.

Diferencia entre Mantenimiento Preventivo y Predictivo

Si bien ambos conceptos parecen iguales, existe una diferencia sustancial entre
ambos conceptos por lo que no deben confundirse entre ellos. La principal
diferencia es que el Mantenimiento Preventivo establece una serie de registros
o inspecciones visuales de manera rutinaria, con el fin de obtener el estado en
que se encuentra esa máquina o el sistema. Con estos datos, el personal puede
revisar y reparar esa máquina para evitar fallos futuros.

En cambio, el Mantenimiento Predictivo basa sus inspecciones en revisiones

exhaustivas, detallas y técnicas de cada componente de la maquina. Esta
información es procesada, para permitir pronosticar posibles fallas y que
pueden ser reparadas incluso sin paralizaciones en la producción.

72
Herramientas del mantenimiento Predictivo
Para que el mantenimiento Predictivo funcione, se necesitan de algunos
componentes básicos, los cuales permiten generar un sistema eficiente de
mantenimiento. Estos componentes básicos son:

• Sensores: sensores que recogen datos instalados en el producto o

máquina física
• Comunicación de datos: el sistema de comunicación que permite que
los datos fluyan de forma segura entre el activo supervisado y el
almacén central de datos
• Almacén central de datos: el centro de datos central en el que se
almacenan, procesan y analizan los datos de los activos y los datos de
la empresa; ya sea en las instalaciones o en la nube.
• Análisis predictivo: algoritmos de análisis predictivo aplicados a los
datos agregados para reconocer patrones y generar conocimientos en
forma de cuadros de mando y alertas.
• Análisis de la causa de la falla: herramientas de análisis de datos
utilizadas por los ingenieros de mantenimiento y procesos para

73
 investigar los conocimientos y determinar las medidas correctivas que
se deben llevar a cabo.

Los datos generados por los sensores son transmitidos a un almacenamiento

central mediante un protocolo de comunicación. Estos datos, juntos con los de
la empresa pueden ser integrados en un almacenamiento central de datos,
para darles un contexto a los mismos. Luego se pueden aplicar algoritmos de
análisis predictivo para proporcionar información que reduzca el tiempo de
inactividad y analizar las causas de fallas.

Las herramientas para poder llevar a cabo las tareas del mantenimiento
predictivo necesitan de una plataforma industrial IoT que permita modelar y
detectar análisis de conductas a fin de poder tomar las medidas correctivas
sobre los activos. Las herramientas de las distintas categorías se
complementan de la siguiente manera:

• Los sensores generan datos

• Las herramientas de análisis y monitoreo ayudan a mejorar y analizar
esos datos
• Los instrumentos de programación coordinan a los equipos sobre el
terreno guiándolos para llevar a cabo actividades de mantenimiento

Sensores de IoT
Los sensores son parte fundamental de cualquier plan de mantenimiento,
porque permiten monitorear los cambios de estado sobre la maquinaria y
realizar los ajustes necesarios para evitar que este se convierta en un
problema. Contar con múltiples sensores diferentes monitoreando diferentes
parámetros puede ser clave para obtener un mejor rendimiento del plan de
mantenimiento.

Según sea el tipo de sensor, el mantenimiento predictivo tiene varias técnicas

que permiten analizar los distintos parámetros que pueden ayudar a mejorar la
eficiencia de un plan de mantenimiento. A continuación se discute algunas de
ellas.

Sensores de vibración
Los equipos rotativos (compresores, bombas, motores…), cuando están en
funcionamiento poseen un cierto grado de vibración. A medida que se

74
degradan, o se salen de la alineación, la cantidad de vibración aumenta. En
definitiva, los sensores de vibración se utilizan para detectar cuando la
vibración está por encima de los valores óptimos.

Las vibraciones pueden ocurrir debido a diferentes factores. Los rodamientos o

soportes de una máquina pueden empezar a perder su fuerza tangible.

Sensores de temperatura
El calor excesivo no es bueno para los metales, los componentes electrónicos o
los motores eléctricos, por eso es una preocupación básica del mantenimiento
en cualquier industria. Es importante contar con la adecuada cantidad de
sensores de temperatura que registren las zonas claves de cualquier
maquinaria.

Sensores de aceite y lubricante

El análisis del aceite puede determinar muchos factores del rendimiento de la
maquinaria. La viscosidad del aceite frente a la esperada puede mostrar cómo
un equipo evita la oxidación, la dilución, la humedad, etc. Así mismo, los
fragmentos de metal en el aceite pueden alertar a los técnicos sobre piezas
que se están puliendo y que podrían ralentizar o romper una máquina. Por
consiguiente, los sensores que calculan la dinámica de los fluidos pueden
ayudar a exponer una fuga o un conector defectuoso.

75
Monitoreo de condiciones

Debido a la transformación digital del mantenimiento industrial, en los últimos

años aparece una nueva forma de definir una estrategia de mantenimiento
basado en la condición. En el mantenimiento basado en la condición (CBM) se
monitorea la condición en tiempo real de una maquinaria o un activo para
determinar el mantenimiento que debe realizarse. Esto es algo que se
diferencia del mantenimiento planificado a intervalos de tiempo, ya que el
CBM establece que el mantenimiento sólo debe realizarse cuando ciertos
indicadores muestran signos de disminución del rendimiento o un fallo
inminente. Esto aumenta el tiempo entre las reparaciones de mantenimiento,
porque el mantenimiento se realiza según las necesidades.

Sensores Bosch para la Industria 4.0

Ya vimos el papel fundamental que poseen los sensores en esta nueva
revolución Industrial y el uso que podemos dar de ellos en el mantenimiento
de los equipos. Por esta razón la empresa Bosch ha diseñado una serie de
sensores cuya función es monitorear el estado de una maquinaria industrial
midiendo distintas magnitudes, ya que poseen internamente varios sensores
que nos permiten analizar, vibraciones, inclinaciones, choques, temperatura,
campo magnético y luz ambiental. Estos datos son enviados de manera
inalámbrica mediante protocolos de comunicación como Bluetooth, Wifi y
algunos hasta pueden utilizar Lora.

76
Esta serie de sensores son los SCD, CISS, XDK, IVAS y Traci los cuales están
diseñados para medir distintas magnitudes que permiten ver el estado de un
activo y transmitirlas por una comunicación inalámbrica. Todos ellos se
caracterizan en la sencillez de su instalación en el activo, ya que no son
sensores invasivos, solo necesitan acoplarse a la maquinaria a monitorear y
empezar a obtener los valores de medición.

En este libro vamos a ver en detalle el sensor SCD110, el cual es pequeño y

muy sencillo de utilizar, ideal para iniciarse en el mundo del mantenimiento en
la nueva era de la industria 4.0.

Sensor SCD110
El SCD110 es un dispositivo IoT con múltiples sensores que permiten medir
aceleración, campo magnético, temperatura y nivel de luz. Su empaque
robusto, el diseño compacto y la fácil instalación lo hacen perfectamente
adecuado para aplicaciones de modernización industrial, como monitoreo de
condición y mantenimiento predictivo. La configuración del dispositivo
permite al usuario utilizarlo una amplia variedad de casos de uso.

77
Características.
El SCD110 es un dispositivo diseñado para ser utilizado en la industria 4.0,
permitiendo modernizar los procesos de mantenimiento de una manera muy
simple pero a la vez muy efectiva. A continuación se detallan las características
más destacables de este dispositivo.

• Dispositivo compacto con múltiples sensores ideal para la industria

4.0.
• Fácil de instalar y listo para usar. No requiere de programación.
• Dimensiones: 70,9 mm x 62mm x 11,3mm.
• Peso: 21g.
• Clase de protección de la cubierta externa: IP67.
• Sensores
o Acelerómetro.
o Magnetómetro.
o Temperatura.
o Luz.
• Rango de Mediciones
o Acelerómetro: ± 200 g.
o Magnetómetro: ± 1300 µT (Ejes X-Y) ± 2500 µT (Eje Z).
o Temperatura: 0ºC a 85ºC.
o Luz: 0 a 188000 Lux.
• Comunicación inalámbrica por Bluetooth de Bajo Consumo (BLE).
• Rango de la comunicación: Puede alcanzar los 40 m (Dependiendo del
lugar).
• Interfaz de usuario: “SCD Sensor App”.
• Duración de la batería: hasta 2 años dependiendo de la configuración.

78
Usos del Sensor SCD110
El principal uso de este sensor es la de proveer de una manera rápida y fácil la
capacidad de monitoreo de un activo en la industria, permitiendo realizar las
técnicas y prácticas que discutimos anteriormente en el mantenimiento
Predictivo o el monitoreo por Condición. Además permite modernizar las
aplicaciones para la industria, ya que provee registros del funcionamiento de
las maquinarias, como el tiempo de trabajo, además de monitorear el estado
del mismo.

Gracias a su cobertura plástica externa del tipo IP67, el sensor SCD110 puede
ser utilizado en ambientes industriales con un mínimo mantenimiento.

Interfaz de comunicación.
El sensor SCD110 cuenta con Bluetooth de bajo Consumo v4.2 (BLE v4.2) para
su interfaz de comunicación inalámbrica. Esto le permite al sensor comunicarse
con otros dispositivos que utilicen la misma tecnología, como smartphones,
tablets y gateways.

La interfaz BLE es utilizada por un Gateway o una aplicación móvil para realizar
la configuración del dispositivo o la transferencia de datos.

Práctica 1: Instalación y Configuración

Como primer practica del uso de este sensor vamos a ver cómo realizar la
instalación y la configuración del SCD110 a través de una aplicación móvil. Los
elementos necesarios para esta práctica son:

• 1 Sensor SDC110.
• 1 Smartphone con Bluetooth 4.2
• 1 Equipo o superficie de monitoreo.
• 1 PC con Sistema operativo Windows, Linux o Mac

Paso 1: Montaje del SCD110

Antes de Instalar el Sensor, debemos asegurarnos que la superficie en donde

se va a instalar el sensor se encuentre lo más limpio y seco posible. Por otra
parte debemos encontrar una zona lisa donde colocarlo.

79
El Montaje Puede hacerse por:

• Por medio del adhesivo.

• Por medio de los tornillos

Paso 2: Descargar la aplicación “SCD Sensor App”. Puede escanear el código

QR o buscar desde el la tienda de aplicaciones de su Smartphone la palabras
“Bosch SCD”.

Paso 3: Activar el Bluetooth del Smartphone y correr la aplicación. Si lo

instalamos por primera vez, debemos aceptar los términos y condiciones.
Luego nos aparece la pantalla de bienvenida.

80
Paso 4: Una vez iniciado la aplicación, nos encontramos con la pantalla de
conexión al dispositivo. En ese momento debemos estar carca del dispositivo al
que queremos acceder, sobre todo si contamos con más de un dispositivo. En
ese momento debemos oprimir una sola vez el pulsador del sensor SCD110
para encender el modulo Bluetooth del dispositivo. Luego en la aplicación
apretamos el botón “Search for Devices”.

Paso 5: Seleccionar de la lista de dispositivo a aquel al cual nos queremos

conectar. Si posee varios dispositivos, póngase lo más cercano posible al
dispositivo al cual quiere acceder.

81
Luego hay que aceptar la conexión por Bluetooth.

Paso 6: Una vez que nos conectamos, tendremos la pantalla principal de la

aplicación, donde veremos una foto como muestra del dispositivo y una serie
de controles.

82
En el margen izquierdo podemos ver las mediciones de cada uno de los
sensores en tiempo real, que al correr la aplicación por primera vez estos no
van a tener valores que mostrar. En el margen inferior podemos encontrar
algunos iconos con las siguientes Funcionalidades:

• Help: Muestra pantallas de ayudas relacionadas con la funcionalidad

en la cual se encuentra actualmente.
• Disconnect: Presionar en este icono para desconectarse del dispositivo
actual.
• Settings: Aquí podemos configurar el nombre del dispositivo y los
valores umbrales de los sensores que pueden activar una alarma.
• View: Inicia o detiene el streaming de los datos del sensor para
mostrarlo en pantalla.
• Diagram: Muestra los valores obtenidos de los distintos sensores en un
diagrama.
• Logging: Pantalla donde se configura la captura de datos en crudo de
los sensores en una memoria interna, para luego analizarlos en una PC.

Paso 7: Vamos a realizar algunas configuraciones sobre el dispositivo. Para ello

seleccionar el icono de ‘Settings’ y nos aparecerá la siguiente imagen.

Paso 8: Comenzamos con cambiar el nombre del dispositivo, para que sea fácil
su identificación. Para ello presionamos sobre el lápiz que se encuentra sobre
el costado superior derecho, al lado del nombre actual y allí escribimos el
nuevo nombre. Es posible que el dispositivo se desconecte al realizar esta

83
acción, vuelva a conectarse siguiendo los pasos para seguir con la
configuración

Paso 9: Luego de configurar el nombre del dispositivo, configuramos los

valores umbrales de cada sensor. Estos valores umbrales indican un límite por
el cual los parámetros no deben sobrepasar, si esto ocurre, el dispositivo
enviará una alarma vía Bluetooth. En el caso de que uno de los parámetros
supere los valores umbrales, entonces ese sensor se mostrará de color rojo. Lo
mismo si vamos a conectarnos al dispositivo, en la lista de dispositivos,
veremos el color rojo sobre el dispositivo que reporta una violación sobre los
valores umbrales.

84
Los valores umbrales de cada sensor va a depender de la aplicación que se le
quiera dar. Además, podemos dejar magnitudes sin valores umbrales,
deshabilitando la alarma para esos parámetros.

Con esta práctica ya tenemos instalado el sensor SCD110 y le hicimos las

primeras configuraciones. Ahora veremos cómo realizar mediciones con este
dispositivo.

Práctica 2: Monitoreo y Streaming

En esta práctica comenzaremos a trabajar sobre el SCD110 en el modo de
monitoreo de las magnitudes de cada uno de los sensores que incorpora el
módulo. Una vez que el modulo se encuentra instalado y ya se realizó la
configuración inicial, podemos comenzar a operar con él para obtener los
valores reportados por sus sensores.

Paso 1: Volver a conectarse al dispositivo como se realizó en la práctica

anterior. Al tener la pantalla principal, vamos a poder activar el modo de
Streaming en el botón superior izquierdo. Al activarlo, veremos que la
aplicación comenzará a mostrar los valores que se obtienen de de los sensores
del SCD110.

En esta pantalla veremos el valor en color rojo de las magnitudes que hayan
superado los umbrales configurados en la práctica anterior. Los sensores de los
cuales tendremos información son la Temperatura, Nivel de Luz,
Magnetómetro y Acelerómetro.

85
Paso 2: ¿Como analizar los datos entregados por el sensor SCD110?

Este sensor es capaz de entregar los valores de temperatura, aceleración,

intensidad magnética e intensidad de luz de un equipo. El monitoreo de estos
valores es fundamental para determinar el estado de un equipo, poder realizar
un análisis basados en modelos y determinar si se necesita o no la aplicación
de un mantenimiento correctivo. Cuando algún parámetro excede el valor de
umbral definido, es necesario en ese caso planificar una acción correctiva
sobre la maquinaria. De esto surge que es necesario analizar qué valores
umbrales configurar en el dispositivo y detectar si estos fueron sobrepasados.
Para ello es necesario saber que podemos analizar con los valores que nos
entrega el sensor.

En los siguientes pasos veremos la utilidad de la medición de cada magnitud

que provee este sensor.

Paso 3:

Temperatura: Uno de los primeros síntomas de envejecimiento de una

maquinaria puede ser el aumento de la temperatura, ya que el desgaste de las
piezas puede incrementar el calor generado por el equipo. La medición de la
temperatura puede ser usada para detectar fallas en piezas rotativas o el mal
funcionamiento de los sistemas de refrigeración. Su unidad de medida es en
[ºC].

Paso 4:

Acelerómetro: Con este sensor podemos medir la Vibración de un equipo. La

vibración es el movimiento u oscilación mecánica alrededor de una posición de
equilibrio de una máquina o componente. Puede ser periódico o aleatorio. En
el monitoreo de condiciones, las mediciones de vibraciones se utilizan para
indicar el estado de la maquinaria giratoria, como compresores, motores o
bombas. Estas máquinas tienen una variedad de partes, y cada parte aporta un

86
patrón de vibración único. Al determinar la tendencia de diferentes patrones
de vibración a lo largo del tiempo, se puede predecir cuándo fallará una
máquina y programar adecuadamente el mantenimiento. El sensor devuelve la
aceleración promedio en los tres ejes en unidades [g] y la variación de cada eje
en [g2].

Paso 5:

Magnetómetro: El auge de estos sensores en el último tiempo ofrece un

prometedor enfoque para el monitoreo de motores, ya que al igual que el
análisis de vibración, la medición es sin contacto. Para la detección de fallas, el
campo magnético parásito debe medirse tanto en la dirección axial (paralela al
eje del motor) como en la dirección radial (en ángulo recto con el eje del
motor). Mediante el tratamiento digital de señales en el espacio de la
frecuencia, como la FFT se utiliza para el monitoreo de condiciones de motores
eléctricos basado en campos magnéticos. El análisis espectral (en el dominio
de la frecuencia), proporciona información sobre la componente fundamental
y sobre los armónicos presentes en la variable, cada máquina tendrá un
contenido espectral específico, cambios en este contenido espectral será el
indicador que revelará fallas en el funcionamiento del motor. La unidad de
medida mostrada en la aplicación es el [µTesla] para los tres ejes.

Paso 6:

Intensidad lumínica: Es importante para la seguridad de la planta trabajar con

una adecuada iluminación. Dependiendo del tipo de maquinaria y su trabajo es
que se necesita mayor o menor intensidad lumínica. También afecta a la

87
seguridad las irregularidades que puede haber en la iluminación, como
centelleos, parpadeos o contrastes inadecuados. El Sensor entrega el valor en
Iluminancia o nivel de iluminación por superficie cuadrada, cuya unidad es el
LUX o lumen por metro cuadrado.

Paso 7: También tenemos la opción de visualizar los datos que vamos

recibiendo del streaming en un diagrama. Para ello oprimimos en el icono
‘Diagram’ para dirigirnos a una pantalla coma la que se muestra en la siguiente
imagen.

Paso 8: Podemos agregar la visualización de los valores de un sensor

seleccionando el mismo desde el panel izquierdo, como por ejemplo,
seleccionamos el sensor de temperatura en la siguiente imagen.

88
Paso 9: En la siguiente imagen podemos ver una descripción de los controles
del diagrama.

A. Refresh: Restablece al tamaño original si el usuario realizo un zoom del

diagrama
B. Habilita el Scrolling en el diagrama, para visualizar todos los valores en
X.
C. Habilita el auto escala en el eje Y del grafico.
D. Start/Stop Chart: Inicia o congela el muestreo de datos en el grafico.
E. Start/Stop record: Inicia o detiene la grabación de los datos que se
muestran en el diagrama.

89
 F. Share record: Permite exportar el archivo “*.csv” que se generó en la
última sesión de grabación.

Paso10: Iniciar una sesión de grabación de los datos que se obtienen del
SCD110. Para ello oprimir en el botón Start record. Como ejemplo, podemos
medir la intensidad de luz y modificarla, en el grafico vamos a poder ver dicha
variación capturada por el sensor. Una vez finalizado, detener la grabación
oprimiendo el botón Stop record.

Paso 11: Exportar el archivo creado hacia una PC, puede ser por email o
enviarlo a una carpeta en la nube. Una vez descargado el archivo *.csv abrirlo
con el programa Excel. Si los datos no aparecen en columnas, lo que se debe
hacer es seleccionar toda la columna de datos e ir a Datos y seleccionar Texto
en columnas.

90
Paso 12: En la pantalla del Asistente para convertir texto en columna
seleccionamos la opción Delimitados. Luego presionar Siguiente.

Paso 13: En la siguiente imagen del Asistente seleccionar la coma “,” como
delimitador de las columnas, tal como lo muestra la siguiente imagen, luego
oprimir en el botón Finalizar. Luego de hacer esto, vamos a tener los valores
separados por columnas, lo cual hace mucho más fácil el procesamiento de los
datos.

91
Paso 14: Una vez que contamos con los datos separados en columnas,
podemos utilizar esta herramienta para procesar los resultados y dibujar
además una grafica de los datos que entrego el sensor.

Práctica 3: Logging
Hasta el momento pudimos configurar y obtener los valores de cada sensor en
tiempo real. Ahora veremos una de las funcionalidades del Sensor SCD110, la
captura de los datos para almacenarlos en una memoria de Log. Se debe
aclarar que el uso del Log permite obtener los valores en crudo de los

92
sensores, lo cual será de utilidad en el análisis de los mismos. Los valores en
crudo son convenientes para un mejor análisis, como los test de vibraciones o
magnetómetro, donde sometemos los datos a procesamiento en el espectro
de la frecuencia, con el uso de las FFT. En esta práctica veremos cómo
podemos obtener estos datos mediante la funcionalidad de Logging.

Paso 1: Nuevamente nos conectamos al sensor SCD110 y entramos a la sección

Logging, para ello en la ventana principal oprimimos el icono que dice
“Logging”. En esta sección tendremos una pantalla como la que se muestra en
la siguiente imagen. Para esta práctica vamos a simular una caída libre del
dispositivo y vamos a capturar los datos del acelerómetro a modo de ejemplo.
Recordemos que los datos que obtendremos en esta práctica serán los datos
en crudo del sensor almacenados en la memoria interna del SCD110.

Paso 2: Seleccionar el tiempo de muestreo del acelerómetro, por ejemplo,

para este caso vamos a tomar los 400Hz, es decir unas 400 muestras por
segundo. Recordar que el almacenamiento del sensor no es ilimitado, por
ejemplo, estás son unas referencias de cuanto se demora en llenar la memoria
interna del sensor.

• Acelerómetro @6.4kHz (1 axis) se llenará la memoria en 60 segundos.

• Acelerómetro @3.2kHz (3 axis) se llenará la memoria en 40 segundos.
• Acelerómetro @1.6 kHz (3 axis) se llenará la memoria en 80 segundos.
• La temperatura solamente llenará la memoria en 21 días.

93
Vamos a configurar las muestras del Acelerómetro en 400 Hz y los demás
sensores los deshabilitamos para esta prueba. Comenzar el logging oprimiendo
el botón Start logging.

Paso 3: Debemos confirmar que estamos dispuestos a realizar el logging y que

el dispositivo capturará los valores de los sensores hasta que se llene la
memoria de Log. Oprimimos el botón “OK” y comenzará el proceso de Log de
los datos.

Paso 4: Una vez que comienza el proceso de Log de los datos del sensor,
podemos simular la caída del dispositivo para ver las variaciones en los datos
del sensor del Acelerómetro. Luego cuando lo terminamos la simulación,

94
podemos finalizar el proceso de logging, en ese momento oprimimos el botón
Stop logging.

Paso 5: Luego de parar el proceso de Log, ya estamos listo para descargar los
datos. Para ello debemos oprimir en el botón Download. En cambio, si
queremos volver a realizar el proceso de Log nuevamente, primero debemos
borrar los datos y volver a comenzar. Si no es el caso, ya podemos descargar
los datos desde el dispositivo hacia nuestro Smartphone.

Paso 6: En este momento debemos esperar la descarga de los datos en el

teléfono, este puede durar varios minutos, dependiendo de la cantidad de
datos que se deben transferir. Es posible que la transferencia se detenga, si
sucede eso, conectarse nuevamente y volverlo a intentar.

95
Paso 7: Una vez que termina la descarga de los datos, podemos enviar el
archivo *.csv a una PC oprimiendo en el botón Share. Se puede exportar el
archivo por distintos medios, como bluetooth, mail o un disco en la nube.

Paso 8: El archivo generado es del tipo *.csv (comma separated value) en

donde el nombre del archivo se puede encontrar el time stamp y cuando fue
descargado.

El formato del archivo es como el que se muestra en la siguiente figura, en

donde se ve el encabezado que incluye diferentes informaciones sobre el
dispositivo, el sensor y la configuración. Para cada sensor podemos ver el
rango de medición, la frecuencia de muestreo y las unidades de medida.

96
Paso 9: Debemos recordar que los datos que contiene este archivos son los
valores en crudo de los sensores almacenados en la memoria del SCD110. En la
siguiente imagen tenemos una grafica de los valores capturados del acelerador
en sus tres ejes en el momento de realizar el logging, donde se simuló una
caída libre del dispositivo.

97
Compatibilidad con Bosch IoT Suite
El sensor SCD110 es compatible con la Suite de servicios que ofrece la empresa
Bosch para dispositivos IOT. Uno de los verdaderos pilares de la revolución
industrial es contar con servicios localizados en la Nube para poder procesar y
analizar los datos que se monitorean en la planta. En esta sección veremos que
es la suite IOT de Bosch y que servicios nos ofrece para conectar nuestros
activos en la nube, como así también una de las funcionalidades más atrayente
en este último tiempo, los gemelos digitales o Digital Twins.

¿Qué es Bosch IoT Suite?

Como dijimos hace un momento, uno de los fundamentos más importantes de
la Industria 4.0 es contar con Servicios que permiten procesar los datos que se
recolectan de todos los sensores. Estos datos de telemetría se utilizan para una
amplia gama de casos de uso en el mundo de IoT, como el monitoreo remoto,
la detección de presencia y el seguimiento de sensores. Además de esta
comunicación de los dispositivos a la nube, cada vez más casos de uso de IoT
también requieren cambiar la configuración de dichos dispositivos y activar
acciones en los mismos de manera remota (comando y control).

En este sentido, Bosch IoT Suite for Asset Communication es un paquete de

servicios dedicado a la recolección escalable y segura de grandes volúmenes de
datos de sensores y dispositivos, y admite el control remoto de sus activos.

98
Servicios de Bosch IoT Suite
Bosch IoT Suite está comprendida por dos servicios generales, que permiten
administrar nuestros dispositivos de manera Remota, estos son el Bosch IoT
Suite for Device Management y Bosch IoT Suite for Asset Communication.

• Bosch IoT Suite for Device Management es una solución integrada

flexible y rica en funciones para la gestión de dispositivos y la gestión
de actualizaciones de software durante todo el ciclo de vida del
dispositivo.
• Bosch IoT Suite for Asset Communication admite la recolección
escalable y segura de grandes volúmenes de datos de sensores y
activos para luego ser procesados.

En este capítulo haremos especial foco en Bosch IoT Suite for Asset
Communication ya que nos provee los servicios necesarios para monitorear
nuestros activos en la planta y nos permite modelar los datos utilizando el
gemelo digital.

Bosch IoT Suite for Asset Communication

El Bosch IoT Suite for Asset Communications es un paquete de servicios que
nos permite gestionar y almacenar los datos de monitoreo y telemetría que
generan nuestros dispositivos o activos, ya sea en una planta industrial o en
una flota de camiones. Está compuesto por tres paquetes de servicios:

• Bosch IoT Hub: se ocupa de la conectividad de los dispositivos a gran

escala.
• Bosch IoT Things: gestiona la representación digital (gemelos digitales)
de sus dispositivos físicos.
• Bosch IoT Edge: Se ocupa de los servicios de borde, como la conexión
con los dispositivos, los protocolos de comunicación y la gestión de los
Gateways.

99
Comunicación Dispositivo a la Nube
La suite de servicios de Bosch IoT permite la comunicación de los dispositivos y
sensores a la Nube por medio de diferentes protocolos, lo cual lo hace flexible
a la utilización de distintos equipos o plataformas.

Los dispositivos pueden conectarse de manera directa a la Nube, accediendo a

los servicios de la capa Bosch IoT Hub o pueden hacerlo de manera indirecta,
por medio de un Gateway. Este último modo es ideal para pequeños
dispositivos como sensores, los cuales no cuentan con un alto poder de
procesamiento.

En la siguiente imagen se tiene un diagrama de la conexión directa de un

dispositivo a los servicios de Bosch IoT.

100
Los protocolos de comunicación entre el dispositivo y la capa de conexión y
autenticación pueden ser HTTP, MQTT y LoRaWAN. En este caso los equipos se
conectan directamente al servicio Bosch IoT Hub el cual es el componente
principal responsable de conectar los dispositivos IoT a la infraestructura de la
nube.

En esta capa de software, cada uno de sus dispositivos físicos se representa

como un módulo, con un ID de dispositivo y sus respectivas credenciales.

En cambio si el dispositivo es un sensor o un pequeño Hardware el cual no

posee el suficiente poder de procesamiento para una conexión directa con la
infraestructura de la nube, se puede agregar un Gateway que administre las
conexiones y los mensajes que llegan de estos dispositivos.

En la siguiente imagen se ve un diagrama de una conexión mediante un

Gateway.

101
Un Gateway permite extender los tipos de dispositivos que pueden conectarse
a la infraestructura de la nube, ya que extiende los protocolos de
comunicación entre el sensor y el Gateway. Estos protocolos pueden ser
ZigBee, Z-Wave, Bluetooth LE, KNX, UPnP, HomeConnect, Modbus, EEBus SHIP,
EEBus SPINE, BACnet. En especial, para nuestro sensor SCD110 necesitaremos
un Gateway que realice el puente entre Bluetooth LE y la comunicación MQTT
con la nube. Para esta solución podemos utilizar el servicio de Bosch IoT Edge
que es el componente básico, que lleva la conectividad y la inteligencia al
límite a pequeños dispositivos, uniformizando la interfaz con la nube,
independientemente del protocolo que manejen los dispositivos.

Digital Twin (Gemelo Digital)

Digital Twin o gemelo digital, se refiere la representación virtual de un activo

físico. Los beneficios de un gemelo digital es proporcionar una capa de
abstracción que permite que las aplicaciones interactúen con un dispositivo o
dispositivos de manera simple y coherente. El objetivo de un gemelo digital es
la de predecir y monitorear el ciclo de vida de un dispositivo y los datos
asociados con él. Los gemelos digitales permiten realizar funciones como la
simulación de dispositivos durante el desarrollo, la integración de análisis y el
aprendizaje automático durante la implementación.

El principal beneficio de los gemelos digitales en IoT es que no tiene que

preocuparse por conectarse al activo para extraer y transmitir datos. En su

102
lugar, simplemente puede implementar aplicaciones en una sandbox en la
nube.

Este enfoque de espacio aislado reduce los riesgos de seguridad porque las
aplicaciones no se implementan en el activo, sino solo en la nube. En última
instancia, los costos de desarrollo se reducen, lo que significa que las
aplicaciones de IoT se pueden desarrollar más rápido. Por lo tanto, los gemelos
digitales en la nube ofrecen el potencial de abrir muchas funciones y
soluciones nuevas.

Casos de usos de Digital Twin

Los campos de aplicación de los gemelos digitales son múltiples y no se limitan

a una industria o área específica. Se pueden utilizar para una amplia gama de
escenarios. Por ejemplo, hay gemelos digitales que simplemente modelan y
representan un solo sensor dentro de un dispositivo. Por otro lado, hay
gemelos digitales que representan muchos aspectos de todo un campus de
edificios, que incluyen energía, topología, etc.

Los gemelos digitales se pueden implementar en el ámbito que estudiamos en

este capítulo, en el campo del Internet de las cosas industriales (IIoT). Un
ejemplo es el proceso de fabricación. Al equipar las máquinas con sensores, se
puede recolectar una gran variedad de datos operativos, no solo los
relacionados con el comportamiento de la máquina en sí, sino también con las
condiciones de la fábrica en su conjunto. Al usar un gemelo digital, puede
consolidar y analizar estos conjuntos de datos, así como replicar procesos de
producción en el mundo virtual. Con el tiempo, si se hacen evidentes las
desviaciones en el rendimiento, los fabricantes pueden tomar medidas para
optimizar sus procesos de producción.

103
Digital Twin en Bosch IoT

La solución de gemelo digital de Bosch se llama Bosch IoT Things. Bosch tiene
documentación técnica bastante detallada, que incluye guías para
desarrolladores, aplicaciones de demostración y un Dashboard.

Con Bosch IoT Things podemos gestionar nuestros modelos de gemelos

digitales durante todo su ciclo de vida, podemos crear un modelo, realizar
lecturas, actualizarlo, realizar búsquedas y también eliminarlo. Además
podemos sincronizar la información recibida por los dispositivos y aplicaciones,
el sistema se encarga automáticamente de rutear la información a los
dispositivos subscriptos. Otra característica que permite la infraestructura de
Bosch IoT Things es que Siempre estará disponible el estado del activo, ya que
se puede buscar el estado más reciente de su dispositivo incluso si el
dispositivo no está en línea en el momento en que solicita los datos.

Recursos de Digital Twin en código abierto

La única solución de gemelo digital de código abierto que se puede encontrar

es Eclipse Ditto, el cual es un proyecto creado por Bosch y que contiene la
tecnología utilizada por la solución Bosch IoT Things. El sitio web de Eclipse
Ditto tiene una amplia documentación y un servidor sandbox. También hay un
seminario web técnico detallado que explica sobre el uso Eclipse Ditto.

104
Cuando se trabaja con gemelos digitales en Bosch IoT Suite, se declaran
modelos que deben cumplir las mismas características que sus instancias de
gemelos digitales. En este sentido, Eclipse Ditto proporciona un Framework
que le permite trabajar y administrar el estado de los gemelos digitales. En
otras palabras, construye el puente entre los dispositivos IoT del mundo real y
sus gemelos digitales.

Para tener una mayor información acerca de Digital Twin en Bosch IoT Things,
recomendamos leer la página para desarrolladores de la plataforma Bosch Iot
Suite.

105
106
Seguridad de los trabajadores

107
108
Introducción

En este capítulo estudiaremos la seguridad de los trabajadores utilizando

soluciones basadas en el Internet de las Cosas (IoT en sus siglas en ingles –
Internet of Things). Una de los principales aportes de esta nueva revolución
industrial, el de la Industria 4.0, es el de poder obtener información no solo de
los activos y maquinarias de la industria, también es una herramienta muy útil
para aumentar la seguridad de un trabajador, ya sea en una planta industrial,
en la construcción o trabajadores expuestos a químicos peligrosos y disminuir
el impacto que puede causar los accidentes laborales.

Siempre fue una necesidad de la industria el mantener a sus empleados

seguros, alejados de accidentes, donde los protocolos de seguridad, las
inspecciones periódicas y la estructura de los lugares de trabajo juegan
actualmente un papel importante en ese aspecto.

Pero en esta nueva Industria, donde se busca mejorar la eficiencia de cada

tarea, se agrega una nueva herramienta en materia de seguridad gracias a
dispositivos que pueden monitorear no solo la ubicación de un trabajador, sino
que también es posible monitorear sus signos vitales y el entorno en el que
trabaja.

Con toda esta información es posible analizar y anticiparse a cualquier riesgo

laboral que pueda sufrir el trabajador.

109
En este capítulo entonces veremos un poco sobre algunos de los temas que
debemos saber en materia de seguridad de los trabajadores y como las nuevas
tecnologías nos ofrecen nuevas soluciones a este problema. Además,
realizaremos los primeros pasos para desarrollar pequeños dispositivos que
permiten monitorear algunas magnitudes de interés en la seguridad de los
trabajadores, trabajando con la placa PIC-BLE de Microchip.

Incremento en la seguridad de los procesos industriales

Utilizar las nuevas tecnologías en el campo de la industria no solo permite
mejorar la eficiencia de cada proceso a realizar, sino que también se
incrementa la seguridad de los trabajadores en esos procesos. Es que los
accidentes laborales tienen un gran coste en la productividad, sin mencionar
los costes sanitarios, de calidad de vida, de administración y seguros. Como
referencia, en Estados Unidos, el Global Wellness Institute estima que cada
año se pierden 2.200 millones de dólares (alrededor de un 10% del PIB del
país) por causa de una prevención deficiente de los accidentes laborales.

Estos accidentes suceden por multitud de razones, muchas de ellas intrínsecas

a la propia industria. Pero, en líneas generales, la mayoría se deben a fallos
humanos, falta de información para desempeñar la tarea, negligencias a la

110
hora de cumplir los protocolos de seguridad, condiciones de baja atención
(trabajador enfermo o poco descansado) y falta de preparación o formación.

Es en este sentido es que vemos como actualmente son cada vez más las
compañías que se apoyan en el uso de la tecnología IoT para optimizar
procesos y contribuir a la reducción de accidentes laborales. Actualmente se
buscan soluciones innovadoras para reducir los accidentes laborales.

Gracias a la tecnología del Internet de las cosas hoy es posible aplicar

soluciones alternativas en cuanto a la seguridad de los empleados, por
ejemplo, además de poder detectar la caída de un operario, también es posible
monitorear los signos vitales utilizando algún dispositivo o prenda que permita
obtener la frecuencia cardiaca, la temperatura, fatiga o niveles de oxigeno.

Una de las principales causas de accidente laboral en la industria es la colisión

entre el hombre y la máquina. Prohibir el acceso al empleado en ciertas áreas
puede resultar beneficioso, pero al conectar las máquinas con la tecnología
IoT, se contribuye además a reducir las lesiones.

También son importantes los factores relacionados con el medioambiente.

Monitorear el estado del ambiente en el que se encuentra el empleado, como
por ejemplo, la medición de presencia de gases nocivos o la medición de la

111
temperatura exterior, nos permite realizar intervención inmediata si un
empleado se ve expuesto a agentes químicos imprevistos. La combinación de
estos sensores con el control de los datos vitales del trabajador puede resultar
clave para salvar vidas.

Ejemplos de Sistemas IoT para la seguridad de los Trabajadores.

Actualmente existen muchos ejemplos de cómo aplicar la tecnología IoT en
materia de seguridad de los empleados, por lo que podemos listar algunas de
estas para ver como las soluciones innovadoras permiten mejorar la calidad del
trabajo y la seguridad del mismo.

1. Predecir el movimiento de los trabajadores

Las tecnologías de IoT pueden rastrear, medir y predecir los patrones de
movimiento de los trabajadores en la fábrica, identificando riesgos que
podrían resultar en daños o lesiones. Los datos recopilados por dispositivos
portátiles, como cascos, chaquetas y relojes equipados con sensores, pueden
mostrar cómo los trabajadores interactúan con sus entornos. Por ejemplo,
cuando el GPS se integra con esquemas para las áreas del lugar de trabajo, los
trabajadores pueden ubicarse y notificarse fácilmente sobre situaciones
peligrosas o evitar que ingresen a zonas en las cuales carecen de autorización.

112
 2. Salud del trabajador
Los sensores que miden los indicadores de salud personal, como los latidos del
corazón, la temperatura, los niveles de oxígeno en la sangre y la fatiga, pueden
identificar a los empleados que están comenzando a mostrar tensión u otro
problema físico, ante estos factores, se puede actuar de manera preventiva
para evitar accidentes. Los dispositivos que contienen sensores pueden
monitorear condiciones físicas como frecuencia cardíaca, fatiga, temperatura,
niveles de oxígeno y otras tensiones.

3. Monitorear condiciones ambientales

La tecnología IoT puede monitorear peligros potenciales dentro del entorno de
trabajo, como niveles de monóxido de carbono, temperatura, vibración,
humedad, niveles de ruido y eventos climáticos. Los sistemas de IoT también
pueden prevenir liberaciones de gas no planificadas respondiendo
rápidamente a cambios de temperatura o variaciones en los niveles de gas,
enviando alertas automáticas cuando ocurren problemas. La capacidad de
monitorear contenedores y otros equipos de manera remota puede proteger a
los trabajadores al evitar que realicen inspecciones en entornos peligrosos.

4. Análisis predictivo
La combinación entre la recolección de datos de IoT en tiempo real con la
inteligencia artificial y análisis avanzados de patrones, permite establecer
importantes tendencias de rendimiento que pueden identificar las posibles
variaciones tan pronto como comienzan a suceder. Esto permite ajustar estas
variaciones, antes de que se vuelvan potencialmente peligrosos (por ejemplo,

113
una fuga de gas lenta o un equipo que se sobrecalienta). El IoT se usa
comúnmente para mantener el rendimiento seguro de los equipos mediante el
mantenimiento predictivo. Además, al usar algoritmos de aprendizaje
automático, se pueden analizar los datos en los lugares de trabajo para
detectar patrones que pueden predecir problemas potenciales antes de que
afecten a los trabajadores.

5. Activar sistemas de seguridad

Los sistemas de IoT pueden monitorear las acciones de los trabajadores y
alertarlos si no están usando los elementos de seguridad y los protocolos
adecuados. Además de reducir las lesiones, esto también mejora el
cumplimiento de los trabajadores con la seguridad.

6. Rapidez en la operación de rescate

En caso de ocurra un desastre en la planta o una lesión grave, los datos críticos
de IoT están disponibles de inmediato en tiempo real para ayudar al personal
médico o al equipo de rescate a comprender la situación rápidamente y tomar
decisiones informadas con respecto a la implementación del mejor plan de
respuesta posible. Los sistemas GPS pueden identificar de inmediato la
ubicación de los empleados lesionados o atrapados y también identificar las
rutas de evacuación de los trabajadores, por ejemplo, después de una
explosión o una liberación de productos químicos no planificada.

114
Simples aplicaciones que podemos desarrollar
A lo largo de este capítulo, veremos en profundidad el uso de una de las placas
de Microchip para el desarrollo de dispositivos IoT que utilizan como protocolo
de comunicación Bluetooth de bajo consumo o BLE. Por ello es que vamos a
nombrar algunas aplicaciones posibles para desarrollar con este dispositivo en
el entorno de la seguridad de los trabajadores. Vamos a nombrar y describir
brevemente tres aplicaciones posibles a desarrollar utilizando esta placa.

Alarma de Hombre caído

El término "hombre caído" (o el más reciente "trabajador caído") se utiliza para
describir a cualquier persona que esté operando por su cuenta y requiera
algún tipo de asistencia después de un incidente en particular. Las situaciones
de hombre caído son más comunes de lo que pensamos, y los resbalones,
tropiezos y caídas siguen siendo la principal causa de accidentes laborales en
muchas industrias. Estos pueden ocurrir en cualquier momento y son aún más
peligrosos cuando le ocurre a un trabajador solitario, que no tiene apoyo para
asistir o pedir ayuda de emergencia. Los tipos comunes de accidentes laborales
que resultan en un hombre caído incluyen:

• Resbalones, tropiezos y caídas

• Choques y colisiones de vehículos
• Cortadas y moretones
• Inhalar humos tóxicos
• Golpearse por un objeto que cae
• Lesiones por equipos defectuosos

Se dice que las lesiones causadas por personas caídas representan el 49% de
todos los incidentes laborales no fatales, por lo que es aún más importante
que las organizaciones proporcionen a sus empleados la protección adecuada
en caso de que les ocurra algo mientras trabajan solos.

115
El desarrollo de una alarma de “Hombre caído” implica la utilización de
acelerómetros que midan cuando se produce un impacto en la persona o un
cambio de posición o la falta de movimiento que esta persona produzca. En
situaciones donde los sensores de medición entreguen valores que pueden
identificarse como un impacto o cambio de posición y luego le siga una total
perdida de movimiento, se puede ajustar al dispositivo para que genere una
alarma, ya que esto podría indicar que un trabajador solitario necesita ayuda
de emergencia, tal vez después de una caída o incidente mientras trabajaba.

116
Localización Indoor

La localización indoor es una práctica cada vez más consolidada y en el

mercado nos encontramos con dispositivos capaces de alcanzar precisiones de
hasta 50 centímetros.

Esta técnica requiere de la distribución de puertas de enlace (o Gateways) y

localizadores en toda la infraestructura de la empresa para aplicar el algoritmo
de posición de la mejor manera posible. En función del número de
localizadores y puertas de enlace, la precisión puede aumentar o reducirse.

Los trabajadores a monitorear requieren una sola antena, pueden ser de baja
potencia y utilizan la transmisión BLE (Bluetooth de baja energía).

Los localizadores requieren arreglos de antenas más grandes, de 3 x 3 o 4 x 4.

Los Gateways procesan las lecturas de ángulo y las envían al sistema de
monitoreo de activos en la nube para determinar su ubicación.

Todos los empleados necesitarán tener un pequeño dispositivo que pueden

llevar incorporado a la altura del cinturón, y que integra además un sensor
acelerómetro. Por un lado, este sensor reduce el consumo de batería, ya que si

117
la persona está parada deja de transmitir la señal de localización. Por otro,
puede detectar el “hombre caído”, por lo que, combinando ambas
informaciones, es posible intervenir inmediatamente y minimizar los
accidentes.

Acceso a Zonas restringidas

El acceso a personas no autorizadas a zonas restringidas puede causar
accidentes laborales, incluso si no visten con la vestimenta o elementos de
protección necesaria. Haciendo uso de la Localización Indoor mediante el uso
de tecnologías como BLE, permite alertar si una persona se encuentra en una
zona restringida o prohibida para ella. Esto puede generar una alarma
indicando la posición ilegal de un trabajador.

También es posible generar permisos a zonas restringidas, por ejemplo, si un

trabajador esta por ingresar a una zona restringida, podemos identificar si
tiene acceso o no a ese sector mediante la lectura de un nivel de permiso que
puede ser transmitido por el dispositivo que lleva cada empleado. Si el
trabajador posee un nivel de permiso que no le permite esta en ese sector se
le puede prohibir el ingreso o notificarle mediante alguna alarma sonora la
posición ilegal.

Placa de desarrollo para dispositivos BLE.

Ya hemos estudiado algunos de los desarrollos y proyectos que existen en la
industria para la seguridad de los trabajadores, ahora nos abocaremos al
estudio del desarrollo de pequeños dispositivos que nos permitirán
implementar estas soluciones. En especial utilizaremos la tecnología Bluetooth
de bajo consumo, porque nos ofrece muchas ventajas en comunicaciones de
entorno cerrado, es simple y nos permite ahorrar en consumo, lo cual es una
necesidad para dispositivos pequeños alimentados a pila o batería.

Al momento de implementar un dispositivo IoT debemos tener en cuenta tres

bloques fundamentales desde el cual iniciar nuestros desarrollos, estos
bloques son:

• Lógica o Inteligencia (Smart)

• Seguridad (Secure)
• Conexión (Connected)

118
Un dispositivo necesita de inteligencia para poder procesar las señales que
obtiene de los sensores y enviarla al bloque de conexión, también debe
inicializar el hardware y los periféricos. Este bloque está representado
normalmente por uno o más microcontroladores. El bloque de conexión se
encarga de transmitir los datos que le provee la Lógica al exterior, la
transmisión suele ser inalámbrica, por medio de WiFi, Bluetooth, ZigBee, NFC o
redes de bajo consumo como LoRa o SigFox. Por último, un bloque importante
a tener en cuenta es el de seguridad, para cifrar los datos, ya que los datos se
transmiten en el espectro inalámbrico y cualquiera puede acceder a los datos,
por eso la importancia de cifrar los mensajes.

Placa PIC-BLE de Microchip

La placa PIC-BLE es la solución que nos provee Microchip para desarrollar un

dispositivo IoT con comunicación BLE que contiene los tres bloques de diseño
que mencionamos anteriormente.

• Lógica o inteligencia: Representado por el PIC16LF18456.

• Seguridad: Representado por el ATECC608A.
• Conexión: Representado por el modulo Bluetooth RN4870.

119
Esta placa además cuenta con un programador USB integrado llamado PKoB
nano, el cual nos puede proveer una interfaz de programación al estilo ‘Drag
and Drop’ en donde el programador se comporta como un disco externo
masivo en el cual podemos enviar el archivo .hex del microcontrolador. El
programador además soporta los entornos de desarrollo para programación y
depuración del MPLAB® X IDE.

La placa viene con un firmware precargado con una demostración que se

conecta a una aplicación llamada LightBlue®. Además cuenta con una interfaz
de conexión mikroBus™ en la cual podemos agregar más de 450 sensores y
actuadores a la placa de desarrollo.

Layout de la placa.
En la siguiente imagen podemos ver una vista de la placa PIC-BLE en donde
podemos encontrar un detalle de los bloques y dispositivos que se encuentran
en ellas.

120
En la izquierda de la imagen y de la placa podemos ver la zona del
programador PKoB nano, el cual cuenta con un conector USB para la
comunicación con la PC. En la zona derecha nos encontramos con la placa de
desarrollo en sí, en donde nos encontramos con el microcontrolador
PIC16LF18456, el dispositivo de Crypto Autenticación ATECC608A y el
Transceiver de Bluetooth RN4870.

Además en la placa de desarrollo encontramos otros dispositivos periféricos

como LED’s indicadores del estado de la conexión y el envió de datos, un
pulsador o switch que nos permiten ingresar acciones por parte del usuario, un
acelerómetro y un sensor de temperatura que son variables con las que
podemos trabajar y enviar los datos al Gateway de conexión.

En la parte posterior de la placa nos vamos a encontrar con el portapilas para

baterías del tipo CR2032, el cual nos va a permitir alimentar la placa. También
contaremos con el acceso a un pin de propósito general GPIO del modulo
RN4870, que veremos en detalle más adelante.

121
Diagrama en bloques de la placa PIC-BLE
En la siguiente imagen tenemos un diagrama en bloques de los componentes
que forman parte de la placa PIC-BLE.

En el diagrama en bloques podemos visualizar además de cada uno de los

bloques, como es la comunicación de cada uno de ellos con el micro

122
PIC16LF18456. Si comenzamos con los componentes que se encuentran a la
izquierda de la imagen, tenemos el sensor de aceleración BMA253 de la
empresa Bosch, que se comunica con el micro por medio de una comunicación
I2C. Luego tenemos el integrado de Crypto Autenticación ATECC608A y el
sensor de temperatura MCP9844, los cuales se comunican por I2C al PIC
compartiendo el BUS de comunicaciones junto con el sensor de aceleración. A
la derecha tenemos el Transceiver de Bluetooth RN4870, cuya comunicación es
por UART y utiliza algunos pines GPIO también. Este Transceiver es el que nos
permite enviar los paquetes de datos por medio de la comunicación
inalámbrica. Luego tenemos algunos componentes que nos permiten
interactuar con el microcontrolador PIC, tenemos tres LED’s en los cuales
podemos ver el estado de la conexión Bluetooth o si se produjo un error y el
ultimo LED se encuentra conectado al microcontrolador en un GPIO que
además puede ser utilizado para PWM. También encontramos un pulsador o
switch, para ingresar eventos al micro.

En la zona inferior de la imagen podemos ver los cuadros de bloques

pertenecientes al programador PKoB nano, a la fuente de alimentación
provista por el regulador MIC33050 y la fuente de tensión proporcionada por
una batería del tipo CR2032.

Componentes del Hardware

Luego de ver el diagrama en bloques de cada sección de la placa de desarrollo,
haremos un breve repaso por cada uno de los componentes que se encuentra
en la placa.

PIC16LF18456
Este microcontrolador de Microchip pertenece a la familia PIC16(L)F184XX la
cual es una familia diseñada para trabajar con sensores, ya que posee filtros
realizados en Hardware para utilizarlos como interfaces en los sensores.
Cuenta con una ADC de alta resolución de 12 bits. Como mejoras en su
arquitectura posee una partición de acceso a memoria (Memory Access
Partition – MAP) que es un área de memoria flash personalizable que permite
la protección contra escritura del bootloader para evitar la sobreescritura
accidental, lo cual protege de datos almacenados allí. También cuenta con un
área de información del dispositivo (Device Information Area - DIA) que ofrece
almacenamiento protegido para almacenar el ID del dispositivo y

123
adicionalmente contiene datos de calibración para el módulo del sensor de
temperatura interno y la lectura de referencia de voltaje fijo (Fixed Voltage
Reference - FVR).

Estas son las principales características de este microcontrolador:

• Núcleo de rango medio mejorado con 48 instrucciones, 16 niveles de

stack
• Memoria de programa Flash de 28KB, SRAM de 2.048B y EEPROM de
256 bytes.
• Conversor ADC de 12 bits con bloque computacional (ADC2)
• Partición de acceso a memoria (MAP)
• Área de información del dispositivo (DIA)
• Periféricos de comunicación digital: 2-UART, 2-SPI, 2-I2C
• Convertidor de digital a analógico (DAC) de 5 bits
• 2 comparadores
• 2 x PWM de 10 bits
• 5 x Módulos de Captura, Comparación, PWM (CCP)
• Peripheral Module Disable (PMD)
• Peripheral Pin Select (PPS)
• Enhanced Power-On/Off-Reset
• Low-Power Brown-Out Reset (LPBOR)
• Programmable Brown-Out Reset (BOR)
• In Circuit Serial Programming (ICSP)
• Rango de temperatura de -40 ° C a + 125 ° C
• Rangos de voltaje de funcionamiento:
o PIC16LF18456 @ 1.8V a 3.6V

124
 o PIC16F18456 @ 2.3V a 5.5V
• 28 pines

En la siguiente imagen tenemos un resumen de las funcionalidades del

PIC16LF18456 donde cada bloque enumera una característica y un periférico
de este dispositivo. Una de las ventajas de este micro es que contamos con dos
puertos EUSART por hardware, lo que permite una comunicación entre el
micro y el modulo Bluetooth y al mismo tiempo con el programador para
realizar pruebas o definir un menú por serie.

RN4870
El RN4870 es un módulo Bluetooth Low Energy diseñado para una amplia
gama de aplicaciones. Soporta BLE 5 que ofrece una mejora del rendimiento
de hasta 2,5 veces y conexiones más seguras en comparación con los
productos basados en Bluetooth 4.1. Los desarrolladores pueden interactuar
fácilmente con el dispositivo a través de una interfaz UART estándar,
disponible en la mayoría de los microcontroladores y procesadores.

El RN4870 posee un stack Bluetooth por software completamente integrada y

certificada donde además viene con antena incorporada. Con este módulo no
hace falta lidiar con las complejidades del software Bluetooth y el diseño de

125
RF. Este módulo es perfecto para aplicaciones de IoT (Internet de las cosas),
cuando se conecta a un smartphone con Bluetooth BLE o un Gateway de
Bluetooth a internet, las aplicaciones se pueden monitorear, controlar y
actualizar desde cualquier parte del mundo.

Estas son las características del módulo RN4870:

• Certificado Bluetooth 5.
• Interfaz de comando ASCII fácil de usar para la comunicación con el
microcontrolador host.
• Aplicación móvil compatible con Microchip Bluetooth Data (MBD).
• Última revisión de firmware: 1.40.
• Soporta LE Secure Connections niveles 1-3.
• Funciones Scripting para permitir el funcionamiento sin un
microcontrolador host.
• Admite cargas útiles de hasta 151 bytes con extensiones de longitud
de datos.
• Capacidad de configuración remota.
• Antena: Antena de chip de cerámica o conexión de antena externa.
• Rango de la antena: Hasta 50m.

Interfaz de comunicación con el host

La interfaz de comunicación entre el microcontrolador y el módulo es por
medio de la comunicación UART y algunos pines de status y control. La
siguiente imagen ilustra la interfaz básica entre el microcontrolador y el
módulo RN4870. La interfaz mínima consta de líneas UART-TX/RX y UART-

126
CTS/RTS. Esto permite que el microcontrolador se comunique con el módulo
RN4870 usando la API de comando ASCII.

El diagrama anterior describe las funciones predeterminadas de los pines del

RN4870. Sin embargo, los pines GPIO del módulo se pueden configurar para
diferentes funciones usando la interfaz de comando ASCII. Algunas de las
funciones configurables incluyen:

• Notificación de batería baja

• Indicador de intensidad de señal recibida (RSSI)
• Indicación de RF activa
• Clave de emparejamiento
• Indicación UART RX
• Caída de enlace

ATECC608A
El ATECC608A es un dispositivo de seguridad que provee autenticación y
cifrado mediante algoritmos de curva elíptica ECDSA. Este dispositivo es ideal
para agregar seguridad a los desarrollos IoT utilizando algoritmos de cifrado
ECDH y ECDSA que comienzan a ser muy utilizados últimamente. Gracias a este
dispositivo podemos proveer de varias funcionalidades de seguridad como la
confidencialidad, integridad de los datos y autenticación. Como todos los
productos de Cripto autenticación de Microchip, el ATECC608A emplea el
guardado de claves criptográficas dentro del hardware de manera segura. Las
claves se mantienen en el dispositivo y no puede accederse para lectura,

127
incluso está construido para ser resistentes a ataques de canales laterales, los
cuales pueden inferir la clave por medios alternativos.

Como herramientas adicionales tenemos que esté integrado de seguridad

ofrece un acelerador por hardware de algoritmos de Encriptación estándar
(AES) lo que permite ayudar a pequeños microcontroladores a agregar
seguridad basado en hardware en protocolos como LoRaWAN.

El dispositivo ATECC608A fue diseñado para almacenar de manera segura la

clave dentro de una zona restringida por los algoritmos de cifrado, de manera
tal que nunca exista la posibilidad de sacarla del dispositivo. Esto supone lo
siguiente:

• Las claves son generadas por el dispositivo, nunca al revés.

• Todo algoritmo criptográfico se ejecuta dentro de la zona de Hardware
de seguridad reforzada.
• Aislación estricta de la clave en el Software de aplicación

128
Memoria Flash SST25PF040CT
El SST25PF040CT es una memoria flash serie de 4 Mbit con un rango extendido
de voltaje de operación y bajo consumo de energía. Esta memoria Flash se
conecta al microcontrolador a través de una comunicación SPI.

BMA253 – Acelerómetro
El BMA253 es un sensor de aceleración de tres ejes, low-g y salida digital para
aplicaciones de consumo y dispositivos móviles. El BMA253 cuenta con un
controlador de interrupciones en chip que permite aplicaciones basadas en
movimiento sin un microcontrolador. El BMA253 detecta la inclinación, el
movimiento, la inactividad y la vibración de los golpes en teléfonos celulares,
dispositivos portátiles, periféricos de computadora, interfaces hombre-
máquina, funciones de realidad virtual y controladores de juegos.

Estas son las interrupciones que pueden generar el BMA253 y las

funcionalidades que se le pueden dar.

• Data-ready (Listo para datos, se puede usar para la sincronización del

procesador)
• Any-motion (slope) detection (Detección de cualquier movimiento, se
puede usar para realizar un Wake-up)
• Tap sensing (Detección de toques, se puede usar para control de
interfaz de usuario sensible a un toque)
• Orientation change recognition (Reconocimiento de cambio de
orientación, se puede usar para cambio entre retrato/paisaje)

129
 • Flat detection (Detección plana, se puede usar para cambio sensible a
la posición)
• Low-g/high-g detection (Detección de baja/alta gravedad, se puede
usar para detección de golpes y caída libre)
• No-motion (Sin movimiento, se puede usar para ahorrar energía)

MCP 9844
El MCP9844 es un sensor de temperatura que trabaja en el rango de los -40ºC
a 125ºC y que tiene una exactitud típica de 0,2ºC (1ºC es la exactitud máxima).
Además el sensor de temperatura se conecta al microcontrolador por medio
de la interfaz de comunicación serie I2C. También podemos programar alertas
si la temperatura medida excede de los valores programados como límites.

Fuente de Alimentación
La placa PIC-BLE se puede alimentar a través del puerto USB o con una batería
del tipo CR2032. La fuente de alimentación cambiará automáticamente a la
batería si la alimentación USB no está disponible. Mientras se alimenta a través
de USB, la placa genera 3.3V para el debugger, el PIC16LF18456 y los
periféricos. Durante el funcionamiento con batería, el PIC16LF18456 y los
periféricos funcionan directamente con el voltaje de la batería, mientras que el
depurador no está encendido, para evitar el consumo excesivo de la batería.

130
Recursos de la placa PIC-BLE

Esta placa cuenta con algunos recursos que permiten el desarrollo y la

depuración de nuestros proyectos de manera simple y efectiva. Además del
programador incorporado, contamos con otras herramientas de utilidad al
momento de depurar código o testear alguna zona del circuito digital. Todos
estos recursos que posee la placa y que vamos a ver a continuación hacen que
esta placa sea ideal para comenzar a desarrollar un prototipo IoT con
tecnología Bluetooth de bajo consumo.

On-Board Debugger
La placa PIC-BLE contiene un debugger USB integrado para programación y
depuración. Este debugger cuenta con varios recursos muy útiles y que
debemos conocer en el momento de desarrollar nuestro código, consta de
varias interfaces:

• Un debugger que puede programar y depurar el PIC16LF18456 en

MPLAB® X IDE.
• Un dispositivo de almacenamiento masivo que permite la
programación al estilo Drag&Drop (Arrastrar y soltar) del
PIC16LF18456
• Un puerto serial virtual (CDC) que está conectado a la UART del
PIC16LF18456, y proporciona una manera fácil de comunicarse con la
aplicación de destino a través de un software terminal.
• Una interfaz de puerta de enlace de datos (Data Gateway Interface -
DGI) utilizado como analizador lógico para depurar pines GPIO.

Virtual Serial Port

El debugger integrado implementa un dispositivo USB compuesto que incluye
una interfaz estándar de clase de dispositivo de comunicaciones (CDC), que
aparece en la PC como un puerto serie virtual. El CDC se puede utilizar para
transmitir datos en ambas direcciones entre la computadora y la placa: todos
los caracteres enviados a través del puerto serie virtual en la computadora se
transmitirán como UART en el pin CDC TX del depurador, y los caracteres UART
capturados en el pin CDC RX, serán redirigidos a la computadora a través del
puerto serie virtual, como se ve en la siguiente figura.

131
Limitaciones
No todas las funciones de UART están implementadas en el depurador
integrado CDC. Existen algunas restricciones que se describen aquí:

• Baud Rate: debe estar en el rango de 1200 bps a 500 kbps. Cualquier
Baud Rate fuera de este rango se ajustará al límite más cercano, sin
previo aviso. El Baud Rate se puede cambiar sobre la marcha.
• Formato de caracteres: solo se admiten caracteres de 8 bits.
• Paridad: puede ser impar, par o ninguna.
• Control de flujo de hardware: no soportado.
• Bits de Stop: se admiten uno o dos bits.

Mass Storage Device

Al conectar el programador a la PC por medio de un cable USB, el dispositivo se
lista como si fuese un dispositivo de almacenamiento masivo, pero en realidad
este dispositivo no cumple con todas la funcionalidades que puede tener un
disco de estos, sino que este comportamiento es intencional y solo para
realizar las siguientes operaciones sobre la placa el programador:

• Acceso de solo lectura a archivos HTML y de texto básicos para

obtener información detallada sobre el kit.
• Acceso de escritura para programar archivos con formato Intel® HEX
en la memoria del dispositivo de destino.
• Acceso de escritura para archivos de texto simples con fines de
utilidad.

La unidad CURIOSITY contiene aproximadamente 1MB de espacio libre, y esto

no refleja el tamaño del Flash del dispositivo de destino de ninguna manera. Al
programar un archivo Intel® HEX, el nombre del archivo puede aparecer en la
lista del directorio del disco. Esta es simplemente la vista del directorio del
sistema operativo, que en realidad, no se ha actualizado. No es posible leer el
contenido de ese archivo. Al quitar y volver a enchufar la placa devolverá el

132
sistema de archivos a su estado original, pero el micro ya se encontrará
programado.

De forma predeterminada, la unidad CURIOSITY contiene varios archivos de

solo lectura para informar el estado y enlaces a más información:

• AUTORUN.ICO: archivo de icono para el logotipo de Microchip.

• AUTORUN.INF: archivo de sistema necesario para que el Explorador de
Windows muestre el archivo de icono.
• CLICK-ME.HTM: redirige a la aplicación de demostración web PIC-BLE.
• KIT-INFO.HTM: redirige al sitio web de la placa de desarrollo.
• KIT-INFO.TXT: un archivo de texto que contiene detalles sobre la
versión de firmware del depurador de la placa, el nombre de la placa,
el número de serie USB, el dispositivo y la compatibilidad con arrastrar
y soltar.
• STATUS.TXT: un archivo de texto que contiene el estado de
programación de la placa.

One Debug GPIO Channel

La interfaz de puerta de enlace de datos (Data Gateway Interface - DGI) es una
interfaz USB para transportar datos sin procesar y con una marca de tiempo
entre el debugger incorporado y el visualizador de datos de MPLAB, llamado
MPLAB Data Visualizer. Este visualizador se utiliza en la computadora para
mostrar los datos de los GPIO de depuración. El visualizador está disponible
como un plug-in para MPLAB X IDE. En particular la placa PIC-BLE incluye en
esta interfaz un canal lógico de depuración llamado One debug GPIO Channel.
Este depurador se utiliza normalmente para graficar eventos que no tienen
una alta frecuencia en un eje de tiempo, por ejemplo, la siguiente figura
muestra la monitorización del estado digital de un switch mecánico conectado
a un GPIO de depuración en MPLAB Data Visualizer.

133
Socket mikroBUS™
La placa PIC-BLE cuenta con un conector mikroBUS para ampliar las
funcionalidades de la placa de desarrollo utilizando placas Click de
MikroElektronika. En la siguiente imagen se puede ver la disposición de los
pines en este socket.

134
PRACTICAS CON LA PLACA PIC-BLE

Requerimientos

Software
Para realizar las siguientes prácticas es necesario contar con los siguientes
Software:

• MPLAB® X IDE v 5.30 o mayor

• XC8 Compiler v2.10 o mayor
• Terminal Tera Term v4.101
• Aplicación LightBlue® en un Smartphone con Bluetooth v4

Hardware
El hardware necesario para realizar las práctica son:

• PIC-BLE Board (DT100112)

Instalación del Software

Realizar los pasos de la instalación normal de lo siguientes software:

• MPLAB X IDE
• XC8 Compiler
• Tera Term

PRÁCTICA 1: Actualización y conexión a LightBlue

Con esta primer practica realizaremos una actualización de software de

nuestra placa PIC-BLE y luego para probar la demo cargada en el micro
usaremos la aplicación LightBlue® para conectarnos a la placa, recibir los datos
de los sensores y controlar los LEDs.

Paso 1: Conectamos la placa PIC-BLE a la PC por medio de un cable USB. Al

conectarlo, en la PC nos aparecerá un nuevo dispositivo de almacenamiento
masivo llamado CURIOSITY. Abrir este dispositivo y hacer doble click en el

135
archivo CLICK-ME.htm. Esto nos desplegará un browser de internet
redirigiéndonos a la página de GitHub del proyecto Demo de la placa.

Paso 2: En la página de GitHub nos dirigimos a la sección Releases y buscamos

el archivo “.hex” de la última versión disponible. Lo descargamos en nuestra PC
y abrimos con un explorador la carpeta donde se descarga ese archivo.

Paso 3: Arrastrar y soltar el archivo “.hex” en el disco CURIOSITY para

programar el dispositivo. Una vez terminado, la placa habrá quedado
actualizada a la última versión disponible.

136
Paso 4: Descargar la aplicación LightBlue® desde la tienda de aplicaciones de
su Smartphone (Google Play Store o Apple App Store). Una vez instalada la
aplicación, debemos abrirla y asegurarnos que tenemos la placa PIC-BLE
encendida (puede ser por batería o por el mismo cable USB). Escanear con la
aplicación el espectro de Bluetooth y nos debe reconocer nuestro dispositivo,
cuyo nombre será PIC-BLE_XXXX donde los XXXX son los últimos 4 caracteres
de la dirección del dispositivo RN4870.

Paso 5: Al conectar la aplicación se puede observar en una pantalla grafica el

estado de los LEDs y el pulsador. También podemos ver en tiempo real la
medición de la temperatura y los tres ejes del acelerómetro de la placa.
También vemos un cuadro de texto donde podemos enviar y recibir datos por

137
el puerto serie. Desde la aplicación podemos controlar el encendido o apagado
de los LEDs verde y rojo de la placa.

Paso 6: Para probar la comunicación serie de la aplicación debemos tener

conectado la placa PIC-BLE a la PC mediante un cable USB y además debemos
tener instalado un software terminal, que en nuestro caso haremos uso del
Teraterm. Para saber el número de puerto COM Virtual que le asigna el
Sistema operativo a la placa, debemos abrir el Administrador de dispositivos y
seleccionar el icono de Puertos (COM y LPT).

138
 Nota: Al instalar el MPLAB X IDE se instalan los drivers necesarios para
que el dispositivo se reconozca como un puerto COM Virtual.

Paso7: Con el número de COM virtual, abrimos el Teraterm y configuramos el

puerto serie con los siguientes parámetros de comunicación.

• BaudRate: 9600 Baudios

• Bits de Datos: 8bits.
• Paridad: Ninguno
• Bit de Stop: 1.
• Control de Flujo: Ninguno.

139
Activar además el Echo Local, para poder ver los caracteres que escribimos a la
consola.

Paso 8: Una vez que estamos conectados a la terminal, ir a la aplicación

LightBlue en el Smartphone y en la sección Serial Data escribir un mensaje en
el cuadro de texto más pequeño y oprimir el botón Write. Ese mensaje se debe
visualizar en el terminal.

Paso 9: Realizar el mismo procedimiento, pero esta vez escribimos desde el

terminal para recibirlo en la aplicación. Al finalizar la escritura del mensaje
debemos oprimir Enter en el teclado para enviarlo.

Paso 10: Una funcionalidad más que tenemos con el terminal es la posibilidad
de comunicarnos con el módulo RN4870 cuando no estamos conectados a la
aplicación LightBlue. Para ello nos desconectamos de la aplicación y podemos
comenzar a enviar comandos al módulo RN4870.

140
Protocolo de comunicación LIGHTBLUE
Existe un protocolo de comunicación entre la aplicación LightBlue y la placa
PIC-BLE basado en una secuencia de caracteres ASCII. La secuencia de datos es
como la que se muestra en la siguiente tabla:

Start Byte Sequence Packet ID Payload Termination

Payload (n)
(1) Number (1) (1) Size (2) Byte (1)

Ver
'[' '0' - 'F' Packet ID '0' - 'F' ']'
Ejemplos

Comienza con un “[“para indicar el inicio del paquete, luego le sigue un

número de secuencia, para ir enumerando los paquetes y saber su orden. El
Packet ID es un carácter y nos dice que tipo de mensaje enviamos, estas son las
posibilidades:

Packet ID Description

'V' Protocol Version

'L' LED State

'P' Button State

'T' Temperature Data

'X' Accelerometer Data

'S' Serial Data

141
 'R' Error Code

'U' UI Configuration Data

Luego el Payload y su tamaño dependerán del tipo de paquete. El tamaño

utiliza dos caracteres, van de 00 a FF. A continuación mostramos un ejemplo
de Payload para paquetes del tipo LED State, donde van dos caracteres, uno
para indicar el LED y otro su estado.

LED ID LED State

LED1 '1' OFF '0'

LED1 '1' ON '1'

LED0 '0' OFF '0'

LED0 '0' ON '1'

Por ejemplo, a continuación se escribe el paquete que informa el estado del 1.

[ 0 L 02 1 0 ]” : Sequence 0, packet “LED”, size:02, select LED1, state: OFF

Payload del estado de los botones

Button ID Button State

BTN1 '1' Not Pressed '0'

BTN1 '1' Pressed '1'

Ejemplo:

[ 2 P 02 0 0 ]” : Sequence 2, packet “Push Button”, select BTN1, state: Not

Pressed

Payload de Serial Data

Serial Data (0-128)

Hex or ASCII, Data Strings Displayed as ‘0’ - ‘F’ ASCII)

142
Ejemplo:

[ 5 S 0A 68 65 6C 6C 6F ]” : Sequence 5, packet “Serial”, string: “hello”

En todos los casos, para los empaquetados de enteros de más de un byte se

usa el orden Little-endian, es decir el byte menos significativo primero, veamos
un ejemplo con la temperatura. Su payload es el siguiente:

Temperature Data Math

16-bit Temperature Reading in ̊ Celsius. LSB First (=Tamb<<4 + sign<<12)

Ejemplo:

[ 3 T 04 9C 01 ]” : Sequence 3, packet Temperature, valor: 0x019C = 25.75C

Para más información del protocolo LigthBlue, ver la pagina de GitHub del
código fuente.

Práctica 2: Modificar el código Fuente

En esta práctica utilizaremos el MPLAB X IDE para abrir el proyecto demo que
viene con la placa y poder realizar modificaciones a fin de familiarizarnos con
el código y poder realizar futuras modificaciones. En esta práctica veremos los
pasos para obtener el código fuente, modificarlo, compilarlo y probarlo en la
aplicación.

Paso 1: Conectarse a la placa PIC-BLE por medio del cable USB y abrir el
dispositivo de almacenamiento masivo que tiene el nombre CURIOSITY. Hacer
click en el archivo CLICK-ME.htm el cual nos va a redireccionar a la página de
GitHub de la demo. Debemos descargar el proyecto y descomprimirlo en
nuestra PC.

143
Paso 2: Abrir el MPLAB X IDE, si tenemos la placa PIC-BLE conectada a la PC,
veremos una pantalla como la que se muestra en la siguiente imagen.

Paso 3: Abrir el proyecto presionando el icono - Open Project y buscamos

en la ruta donde descomprimimos el proyecto. Podemos abrir el archivo
main.c para ver la estructura del programa y el código fuente. Luego
oprimimos el botón - Build Project para compilar el proyecto. Si no hay

144
errores, en la ventana Output debe mostrar el mensaje de que la compilación
se realizó satisfactoriamente.

Paso 4: Procedemos a modificar el código para enviar un mensaje de alerta

por el Serial Data si la temperatura supera un determinado valor de umbral
límite. Para enviar el mensaje de alerta por los datos serie a la aplicación
debemos utilizar un método llamado “LIGHTBLUE_SendSerialData()”. El lugar
donde vamos a modificar el código para poner nuestro controlador de alerta
por overflow de temperatura será en el método que se encarga de leer la
temperatura de manera periódica del sensor, esto se realiza en la función
“LIGHTBLUE_TemperatureSensor()” que se encuentra dentro del archivo
LIGHTBLUE_service.c. Allí modificamos la función para que se vea como lo
muestra la siguiente imagen.

145
Paso 5: Compilar el código y cargar el archivo .hex generado. Si tenemos el
MPLAB X IDE abierto y la placa conectada, podemos hacerlo directamente
desde allí oprimiendo el botón -Make and Program Target. Si no podemos
hacerlo realizando un Drag&Drop.

Paso 6: Al encender la aplicación LightBlue y conectarse a la placa observar el

Serial Data cuando la temperatura supera el umbral límite configurado en el
código.

146
Si esto ocurre, debe escribir el mensaje de alerta que colocamos en el código.
Fin de la práctica.

147
148
Aplicaciones de telemetría y
seguimiento de activos

149
150
Telemetría y seguimiento de activos

Conectividad inalámbrica con LTE

Una de las tecnologías que prometían un mayor futuro en la comunicación
inalámbrica de largo alcance para los dispositivos IoT era la Red celular 4G o
LTE, ya que es una red en auge y con una amplia cobertura mundial, pero para
dispositivos IoT los cuales necesitan, en la mayoría de los casos, un bajo
consumo para mantener su autonomía el mayor tiempo posible, el uso de las
redes celulares se volvían impracticables, ya que estas redes necesitan de un
alto consumo para las comunicaciones.

Ante el auge de las nuevas redes inalámbricas para dispositivos IoT como lo
son LoRa y SigFox, obligaron a las redes celulares tradicionales a replantearse
la estrategia de mercado que llevaban a cabo para los dispositivos IoT. Esto
llevó a que se definieran nuevas categorías en la tecnología de redes celulares
que estuvieran abocadas a los dispositivos IoT, que tienen como características
un bajo nivel procesamiento y también un bajo nivel de consumo Energético.

Por esta razón aparecen las nuevas tecnologías LTE/4G adaptadas a los
dispositivos IoT los cuales fueron llamados LTE Cat M1 o Cat M y LTE Cat NB o
NB-IoT. En la siguiente imagen se puden ver las categorías enlas tecnología
LTE y explicaremos de manera breve de que se tratan las nuevas redes LTE-M y
NB-IoT.

151
¿Qué es LTE-Cat M1?

LTE Cat M1 es una nueva tecnología celular diseñada específicamente para las
necesidades que tienen los dispositivos IoT. Es una tecnología LPWA (Low
Power Wide Area) que permite además comunicaciones M2M (Machine To
Machine) que puede alcanzar un data rate de 1MBits/s. Además está diseñado
para que los dispositivos mantengan un bajo consumo, a la vez que provee una
excelente cobertura incluso dentro de los edificios. Estas son algunas de las
características del LTE Cat M1:

• Soporta de transmisión de voz utilizando VoLTE

• Soporta movilidad y aplicaciones en tiempo real.
• Bajo consumo.
• Cobertura extendida y amplia penetración en construcciones y
edificios

152
Aplicaciones con LTE Cat M1
Debido a las características de esta tecnología, existen aplicaciones en donde
esta red inalámbrica se adapta mejor, estas aplicaciones se enumeran a
continuación:

Automotrices y transportes
La tecnología LTE Cat M1 soporta la conexión entre redes celulares para un
vehiculo en movimiento, lo que lo hace apropiado para el uso de aplicaciones
de movilidad, con una velocidad moderada de envío de datos. Ejemplo de
estas aplicaciones son el seguimiento de un vehículo, telemetría o manejo de
flotas.

153
Aplicaciones de Salud
Debido a que la tecnología LTE Cat M1 tiene una amplia cobertura, incluso
dentro de los edificios, además de la movilidad y a posibilidad de enviar voz
por la red, esto lo hace una gran candidata en las aplicaciones que monitorean
la salud de un paciente.

Edificios y ciudades inteligentes

Por las características de la Red, la de tener una amplia cobertura, incluso en
lugares cerrados, poder enviar gran cantidad de datos y enviar voz via VoLTE,
permite que se puedan diseñar sistemas de alarmas para hogares, como
también el manejo de las luces de la ciudad, monitoreo del trafico, etc.

¿Qué es Narrowband IoT?

Narrowband IoT, también conocido como LTE Cat NB1, es una tecnología
LPWA, diseñada para trabajar con dispositivos IoT por medio de la Red celular.
Además logra una conexión simple y eficiente de los dispositivos dentro de la
red celular. LTE Cat NB1 está especialmente diseñada para dispositivos que
requieren de una baja cantidad de datos a transmitir, a través de largos
periodos de tiempo y en lugares de difícil acceso. Estas son algunas de las
características del LTE Cat NB1:

• Muy bajo consumo energético.

• Excelente cobertura de la señal tanto dentro como fuera de los
edificios.
• Fácil desarrollo en la arquitectura existente de la red celular.
• Red segura y confiable.
• Bajo costo en los componentes.

154
Aplicaciones con NB-IoT

Debido a las características de esta tecnología, existen aplicaciones en donde

esta red inalámbrica se adapta mejor, estas aplicaciones se enumeran a
continuación:

155
Mediciones Inteligentes
Debido a la amplia cobertura de la red, tanto en lugares cerrado como en
lugares abiertos y que no se requieren de grandes cantidades de datos a
transmitir, esta red es ideal para la medición de parámetros y de las
condiciones del entorno.

Agricultura y medio ambiente

Esta red posee una gran cobertura, incluso en lugares difíciles de acceder, lo
que lo hace excelente para obtener las condiciones ambientales de entorno
para la agricultura, como también permite el seguimiento de animales, que
necesita de una baja cantidad de datos a transmitir.

156
LOGISTICA IOT CON RED CELULAR

Introducción

En este capítulo estudiaremos una solución de logística IoT para redes

celulares en el mundo real utilizando una placa de la empresa Nordic
Semiconductores llamada Nordic Thingy:91 la cual veremos que nos provee de
conectividad inalámbrica a través de la red celular IoT.

La serie nRF91 es la primera familia de semiconductores de la empresa Nordic

de dispositivos celulares de bajo consumo para Internet de las cosas. Han sido
diseñados desde el inicio para funcionar con los más altos estándares posibles
de eficiencia energética y seguridad, al tiempo que brindan un rendimiento y
posibilidades de realizar aplicaciones avanzadas para celular IoT (IoT en la Red
Celular). Con un nivel de integración sin precedentes que incorpora LTE-M, NB-
IoT, GPS, RFFE y administración de energía todo en un dispositivo muy
pequeño.

Que es Nordic Thingy:91?

Nordic Thingy:91 ™ es una plataforma de desarrollo de prototipos que
funciona con baterías para diseños que utilicen la red celular IoT, certificada
para operar en todo el mundo. Es ideal para el desarrollo rápido de prototipos
para sistemas celulares IoT y es especialmente adecuado para aplicaciones de
seguimiento de activos y monitoreo ambiental. Nordic Thingy: 91 incluye
sensores que recopilan datos sobre sus propios movimientos y el entorno
circundante. Los datos de temperatura, humedad, calidad del aire, presión del
aire, color y luz se pueden extraer fácilmente para análisis de los ambientes
locales o remotos. Como primera interfaz de entrada, el Nordic Thingy: 91
ofrece un botón programable por el usuario.

157
Estas son algunas características del Nordic Thingy:91

• Plataforma de prototipo rápido para la red celular IoT.

• Soporta las tecnologías LTE-M y NB-IoT.
• Se envía con una tarjeta SIM de alcance Mundial
• Cuenta con Bluetooth de Baja Energía (BLE).
• Contiene una gran cantidad de sensores.
• Viene con una aplicación pregrabada lista para usar
• Cuenta con herramientas de desarrollo

Envergadura de los proyectos IoT

Los proyectos de IoT son grandes y cubren varias áreas o disciplinas en toda la
cadena de pasos necesarios para leer los datos de un sensor hasta que llega al
usuario final. Las áreas que nos encontramos en una cadena de transmisión IoT
van desde la lectura de magnitudes utilizando sensores, el dispositivo
embebido, la conectividad y la nube y luego el análisis de los datos y la
visualización o el agregado de valor de esos datos.

158
Con la ayuda de la plataforma de desarrollo Nordic Thingy:91 podemos cubrir
todas estas áreas para crear prototipos o demostraciones que validen las ideas
originales y permitan demostrar la factibilidad de las aplicaciones en un tiempo
de desarrollo acotado.

POC y Prototipos.
El termino de POC o Prueba de Concepto es un proyecto destinado únicamente
a probar si una idea es viable de realizar o no. Esto se realiza en una etapa muy
temprana del desarrollo, por lo que no se tiene en cuenta aun la usabilidad o el
diseño, sino que simplemente se enfoca en demostrar la funcionalidad. Las
pruebas de concepto son ideales para determinar cuál es la magnitud del
proyecto y estimar tiempos de desarrollos.

En cambio los prototipos es una fase más adelante en la línea de desarrollo,

porque ya nos muestran un modelo más cercano al producto final, mostrando
el diseño y la usabilidad de las aplicaciones desarrolladas.

La placa Nordic Thingy:91 nos ofrece la posibilidad de realizar prototipos y

Pruebas de conceptos en un tiempo muy corto de desarrollo y nos da la
flexibilidad de poder realizar cambios a futuros para mejoras. La placa Nordic
Thingy:91 cubre las áreas de los sensores, el sistema embebido y la
conectividad.

Kit de tecnologías en el Nordic Thingy:91

La placa Nordic Thingy:91 cuenta con varias tecnologías de comunicación
inalámbricas. Esta especialmente diseñado para trabajar con la red celular IoT
ya que cuenta con el nRF9160 que soporta LTE Categoría M , NarrowBand IoT y
sistema de posicionamiento global GPS. Además la placa cuenta con el
dispositivo nRF52840 que es un SoC (System on Chip) con tecnología Bluetooth
Low Energy (BLE) y Near Field Communication (NFC).

159
Nordic Thingy: 91 tiene una antena compatible con GPS, LTE-M y NB-IoT que le
permite soportar un gran rango de bandas LTE. Tiene dos antenas conectadas
al nRF52840: una antena de 2.4 GHz para Bluetooth LE y una antena NFC. Para
conectarse a la red celular, la placa Nordic Thingy: 91 tiene una ranura para
tarjeta SIM nano/4FF y viene con una tarjeta SIM de iBasis precargada con 10
MB de datos para utilizar.

Características completas del Nordic Thingy:91

• Soporta las bandas de frecuencia LTE 700-960 MHz + 1710-2200MHz

(bandas: 2, 3, 4, 8, 12, 13, 20 y 28).
• Esta certificada bajo las normas: CE y FCC.
• Posee Antenas integradas para LTE-M/NB-IoT/GPS, Bluetooth LE y NFC.
• Cuenta con un slot para tarjeta SIM nano.
• Botón y LED RGB programable por el usuario

160
 • Posee sensores de ambiente para temperatura, humedad, calidad de
aire y presión.
• Sensor de Luz y de colores
• Acelerómetros de bajo consumo y High-G
• Buzzer
• 4 transistores N-MOS para motores DC externos o LEDs
• Batería Li-Po de 1400mA recargable por USB.
• Conexión a PC a través del USB.
• Rango de temperatura de operación normal: 5ºC ~ 35ºC

Hardware del Nordic Thingy:91

La placa Nordic Thingy:91 cuenta con una gran cantidad de sensores, todos
interconectados al nRF9160 el cual es el dispositivo principal de la placa.

161
En el diagrama en bloques podemos ver la interacción de las distintas
funcionalidades de la placa con el nRF9160. Todos los sensores se conectan a
este dispositivo para entregar sus valores. A su vez, el nRF9160 necesita de los
bloques de circuitos que adaptan la señal a las antenas para transmitir los
datos. También podemos ver que de manera auxiliar el nRF52840 sirve como
ayuda para agregar conectividad Bluetooth, asistiendo al dispositivo principal
que en este caso es el nRF9160. Esto nos permite configurar el dispositivo de
manera remota utilizando la comunicación Bluetooth, como así también,
agregar esta tecnología a nuestros proyectos.

162
Por último contamos con el tercer bloque más importante de la placa es el
power management IC (PMIC) que es el integrado dedicado a manejar de
manera eficiente la alimentación de todo el sistema, además de administrar la
energía necesaria para la recarga de la batería desde el USB. A continuación
explicaremos algunos de los componentes que forman la placa Nordic
Thingy:91.

163
nRF9160 SIP para cIoT.

El nRF9160 es el dispositivo principal de Nordic Thingy: 91. Es un compacto y

altamente integrado sistema SIP (System In Package) que utiliza la última
tecnología LTE de baja potencia. Tiene capacidades de procesamiento
avanzadas y cuenta con características de seguridad. También tiene la
accesibilidad y flexibilidad para ser utilizado con una amplia gama de
aplicaciones de IoT en redes celulares de baja potencia de un solo dispositivo.

Características del nRF9160

• Radio/Modem
o LTE-M y NB-IoT
o Potencia de salida de 23dBm
o GPS
o Modos de bajo consumo: DRX, eDRX y PSM.
• Procesador para aplicaciones.
o ARM Cortex-M33 trabajando a 64MHz

164
 o 1MB de memoria Flash y 256KB de RAM.
o Arm TrustZone
o Arm CryptoCell 310 para aplicaciones de Seguridad.
o 4 x SPI/UART/TWI, PDM, I2S, PWM, ADC.
• Bloques Integrados
o PMIC (Power Manager Integrated Circuit)
o RFFE (RF FrontEND)
o Un gran set de Periféricos.

Modem LTE-M/NB-IoT

El nRF9160 posee un módem LTE completo compatible con los estándares

3GPP LTE versión 13 Cat-M1 y Cat-NB1, y 3GPP LTE versión 14 Cat-NB1 y Cat-
NB2. El módem LTE integra un transceiver muy flexible que en hardware
admite un rango de frecuencia de 700 a 2200 MHz (a través de un solo pin de
antena de 50 Ω), y un procesador de banda base que maneja los protocolo LTE
Cat-M1/NB1/NB2 de capas L1-L3, así como Capas superiores IP que ofrecen
API de socket con seguridad para las aplicaciones que lo requieran. En la
siguiente tabla vemos un resumen del Modem LTE.

165
ARM Cortex-M33

El nRF91 posee el ARM Cortex-M33 como un procesador de aplicaciones

dedicado. Tiene 1 MB de memoria flash y 256 KB de RAM con una amplia gama
de periféricos. El procesador ARM Cortex-M33 tiene un conjunto de
instrucciones de 32 bits (tecnología Thumb-2) que implementa un
superconjunto de instrucciones de 16 y 32 bits para maximizar la densidad y el
rendimiento del código.

Este procesador implementa varias características que permiten realizar el

cálculo aritmético de manera eficiente con respecto a la energía y el
procesamiento de señales de alto rendimiento, que incluyen:

• Instrucciones de procesamiento de señal digital (DSP).

• Instrucciones de multiplicación y acumulación de un solo ciclo (MAC)
• División por hardware.

166
 • Posee instrucciones simples de 8 y 16 bits e instrucciones de múltiples
datos (SIMD).
• Unidad de punto flotante de precisión simple (FPU).
• Unidad de protección de memoria (MPU).
• ARM® TrustZone® para ARMv8-M.

ARM Trust Zone

Arm TrustZone es una tecnología de seguridad integrada en los procesadores

Cortex que comienza en el nivel de hardware creando dos entornos que
pueden ejecutarse simultáneamente en un solo núcleo: un entorno seguro y
un entorno no tan seguro. Cada vez más, los desarrolladores necesitan
proteger los sistemas comenzando en los niveles más bajos del hardware, en la
capa física, que incluye además el proceso de arranque, ya que este proceso
también es sensible al acceso de intrusos.

167
Los procesadores Arm Cortex con TrustZone ejecutan un sistema operativo
(SO) seguro y un Sistema Operativo normal simultáneamente desde un solo
núcleo. TrustZone puede asegurar una biblioteca de software o un sistema
operativo completo para ejecutar en el área segura. El software no seguro
tiene bloqueado el acceso al lado seguro y a los recursos que residen allí. De
esta manera TrustZone le da al diseñador de chips los medios para crear dos
entornos completamente separados que se ejecutan en el mismo procesador.
Esta disposición permite un desarrollo de software más seguro y simple,
reduciendo la complejidad del desarrollo del producto final. Usando TrustZone,
el dispositivo está diseñado para proteger el software, los periféricos, la
identificación del dispositivo, las claves de seguridad y cifrado y todos los
activos de este tipo sin el permiso correspondiente.

nRF52840

Para conectividad USB, Bluetooth y NFC, la placa Nordic Thingy: 91 utiliza el

dispositivo nRF52840. Es un SoC (System On Chip) potente, altamente flexible y
de ultra baja potencia que incorpora un radio Bluetooth de baja energía (BLE) y
un Procesador Arm Cortex-M4F de 32 bits.

168
Características del nRF52840
• Soporta Bluetooth 5/802.15.4
• Procesador ARM Cortex-M4F
• 1MB de Flash y 256KB de RAM
• Soporta NFC.
• USB.

Sensores
La placa Nordic Thingy:91 cuenta con varios sensores que permiten medir el
entorno del dispositivo, por lo que es posible medir la temperatura, humedad,
presión, aceleración, etc. En esta sección describiremos algunos de los
sensores que utiliza la placa.

Bosch Sensortec BM680

El sensor BM680 permite realizar mediciones de de presión Barométrica,
altitud, humedad relativa, temperatura y gases como compuestos orgánicos
volátiles. Está diseñado para trabajar en modo bajo consumo y con largos
periodos de estabilidad. El sensor es totalmente digital y las mediciones son
almacenadas en registros internos.

169
Acelerómetro ADXL362
El ADXL362 es un acelerómetro de 3 ejes de Analog Devices de muy bajo
consumo, construido sobre tecnología MEMS. El ADXL362 proporciona una
resolución de salida de 12 bits. Están disponibles en rango de ±2g, ±4g y ±8g y
su comunicación con el Microcontrolador es por SPI.

170
Acelerómetro ADXL372
El ADXL372 es un acelerómetro de 3 ejes de ±200g capaz de identificar
impactos debido al gran rango de medición que posee. Está construido sobre
tecnología MEMS y cuenta con una FIFO de salida y varios modos de detección
de actividad.

Sensor de color BH1749

El BH1749 es un sensor de color digital de 16bits de resolución fabricado por la
empresa ROHM Semiconductores. Este sensor es capaz de detectar los colores
rojo, verde, azul (RGB) y el infrarrojo también, que luego lo convierte en
valores digitales y los entrega por medio de una comunicación I2C.

171
La Red Celular

La inclusión de LTE-M y NB-IoT a las redes celulares 4G está estableciendo el

estándar para IoT en redes de amplio rango y que se desplegará a gran escala
en los próximos años. Ambos protocolos están diseñados para un
funcionamiento confiable, seguro y de baja potencia, haciendo de estos
estándares, junto con la cobertura de la red celular en la mayor parte del
mundo, ofrecen una opción incomparable para la conectividad IoT en redes
LPWAN.

172
LTE-M y NB-IoT son estándares abiertos desarrollados y administrados por el
Proyecto de Asociación de 3ra Generación (3GPP). Esto garantiza la
interoperabilidad y la fiabilidad de la operación en todo el mundo.

LTE-M

LTE-M (también conocido como eMTC o Cat-M1) está diseñado para

aplicaciones de bajo consumo que requieren un rendimiento medio. Tiene un
ancho de banda de 1.4 MHz, lo cual es más estrecho en comparación con los
20 MHz del LTE regular, lo que brinda un mayor alcance, pero menos
throughput. El throughput de un enlace de bajada es de 375 kbps y en un
enlace de subida es de 300 kbps, lo que proporciona un rendimiento de
aplicación de aproximadamente 100 kbps con IP. Es adecuado para conexiones
seguras de extremo a extremo TCP / TLS. La movilidad es totalmente
compatible, utilizando las mismas características de transferencia de células
que se realiza en LTE normal. Actualmente es posible realizar el roaming con
LTE-M, lo que significa que es adecuado para aplicaciones que operarán en

173
múltiples regiones. La latencia está en el rango de milisegundos por lo que
ofrece comunicación en tiempo real para aplicaciones de tiempo crítico.

LTE-M es perfecto para aplicaciones de rendimiento medio que requieren baja

potencia, baja latencia y / o movilidad, como aplicaciones de seguimiento de
activos, dispositivos portátiles, médicos, puntos de venta y seguridad del
hogar.

NB-IoT
NB-IoT (también conocido como Cat-NB1) es un estándar de tecnología de
banda estrecha que no utiliza una capa física LTE tradicional, pero está
diseñado para operar dentro o alrededor de las bandas LTE y coexistir junto
con otros dispositivos LTE. Tiene un ancho de banda de 200 kHz, lo que le
otorga un mayor alcance y un bajo rendimiento en comparación con LTE-M y
LTE. El throughput de un enlace descendente es de 60 kbps y un enlace
ascendente de 30 kbps. Es adecuado para aplicaciones estáticas de baja
potencia que requieren bajo rendimiento.

NB-IoT es perfecto para aplicaciones estáticas de bajo rendimiento que

requieren bajo consumo y largo alcance, como la telemetría inteligente, la
agricultura inteligente y las aplicaciones de ciudad inteligente.

174
Demo: Asset-Tracker

La placa Nordic Thingy:91 viene con un firmware pregrabado el cual es una

demostración llamado Asset Tracker el cual nos permite reconocer la ubicación
de un objeto o móvil y los valores ambientales del entorno enviando estos
datos a través de la Red de telefonía celular.

La aplicación utiliza los drivers de control LTE para así establecer una conexión
con la Red. Luego recolecta los valores ambientales del entorno y los transmite
a la nube de Nordic, llamado nRF Cloud. Los datos se pueden visualizar en la
interfaz web de la nube de Nordic.

Los datos que se transmiten a la Nube son los de posición utilizando el GPS
(Opcional), lectura del acelerómetro (orientación física del dispositivo) y los
datos de los sensores de ambiente.

Pasos para conectarse a nRF Cloud

Para realizar los pasos de esta práctica necesitamos la placa Nordic Thingy:91,
la cual es posible comprarla desde Mouser Electronics® ingresando a la página
http://www.mouser.com

175
 1) Para comenzar, debemos tener una cuenta en nRF Cloud, para eso
abrimos un explorador web y nos dirigimos a la página
http://nrfcloud.com. Si no tenemos una cuenta, debemos crear una.
2)

176
 Debemos indicar una dirección de mail y una contraseña para generar
la cuenta.

3) Una vez ingresado la dirección de email y la contraseña, se debe

esperar a recibir un correo electrónico con una clave de 6 dígitos, una
vez recibido, colocar los 6 dígitos en el recuadro para acceder a la
cuenta.

177
 4) Cuando se encuentre activada la cuenta, podemos acceder a ella.
Dentro de nuestra cuenta de nRF Connect for Cloud nos dirigimos a la
barra izquierda y oprimimos el botón de agregar un nuevo dispositivo.

178
5) En la siguiente ventana, seleccionamos agregar un dispositivo LTE.

179
 6) En la siguiente ventana nos pide verificar y activar la SIM, para ello
necesitamos ingresar el SIM ICCID y el Personal Unblocking Key (PUK).

180
7) El SIM ICCID y el PUK lo podemos encontrar en la tarjeta donde se
encuentra el chip, colocamos esos datos en la web para activar nuestra
tarjeta SIM.

8) Una vez que agregamos los datos de la tarjeta SIM, procedemos a

agregarlo a la placa, retiramos la SIM de la tarjeta (Nos debemos
quedar con la SIM más chica, es decir la nano SIM). Luego tomar la
placa Nordic, quitar la goma protectora e insertar la tarjeta SIM en el
conector. Por último, encendemos la placa con la perilla que se
encuentra al costado izquierdo del conector USB

181
 9) Una vez que la placa enciende, esperar a que el LED se ponga de color
amarillo. Esto significa que la placa está esperando para asociarse a un
usuario. En la siguiente tabla podemos ver el estado de la placa según
el color del LED RGB.

Color LED Estado

Blanco Conectando a la Red
Cian Conectando a nRF Cloud
Amarillo Esperando para asociarse a un usuario
Azul Conectado, enviando datos de entorno
Morado Buscando Satélites GPS
Verde GPS fijado, enviando GPS y datos de
entorno
Rojo Error

10) Una vez que el led se pone amarillo, estamos listo para asociar la placa
a la cuenta de usuario. Para esto se debe ingresar el IMEI y el pin en la
siguiente ventana. Para armar el ID del dispositivo, se debe anteponer

182
 al número de IMEI del dispositivo la palabra “nrf-“, por ejemplo: nrf-
123456789123456

11) El IMEI y el pin del dispositivo lo obtenemos de la etiqueta que se

encuentra en la placa Nordic Thingy:91.

183
 12) Una vez que terminamos de asociar el dispositivo LTE a nuestra cuenta
de usuario, vamos a la sección Devices de la página web de nRF Cloud
y veremos que se nos agrega un nuevo dispositivo en nuestra cuenta
de usuario.

184
13) Al terminar de asociar la placa, debemos esperar a que el LED se ponga
de color Azul, lo cual podemos ver según la tabla de código de colores
del LED que el dispositivo está asociado y transmitiendo los datos de
entorno.

14) Por defecto el GPS viene deshabilitado en la demo. Para habilitarlo

debemos presionar y mantener apretado por alrededor de 10
segundos el botón SW3 de la placa Nordic Thingy:91, nos daremos
cuenta que el GPS se enciende porque el LED RGB se enciende de color
morado y se mantiene de este color hasta que logre asociarse a los
satélites GPS. Una vez que se fija la posición del dispositivo en el GPS,
el LED pasa a encenderse de color verde.

15) Cuando el equipo está asociado y transmitiendo datos, vamos a la

página web del nRF Cloud y vamos a la sección Devices y
seleccionamos el dispositivo que acabamos de agregar. Allí nos debe
mostrar en distintos gráficos los datos que se envían desde la placa
Nordic, como los datos de ambiente, la temperatura, presión,
humedad y movimiento, más precisamente la orientación y en un
mapa podemos observar la posición del dispositivo si se están
transmitiendo los datos de GPS.

185
Conectarse a Link Monitor

Link Monitor es una herramienta de Software que nos permite conectarnos a

la interfaz serie de la placa Nordic Thingy:91 y poder monitorear el estado del
modem y de la Red LTE mediante el envío de comandos AT.

Antes de comenzar, debemos tener instalado el Software nRF Connect for

Desktop que lo podemos descargar desde la página web del fabricante Nordic
Semiconductores. Una vez descargado, ejecutamos el instalador para tener el
software nRF Connect for Desktop instalado en nuestra PC, luego podemos
continuar con los siguientes pasos.

1) En el Software nRF Connect for Desktop, buscar e instalar el LTE

Monitor para ejecutarlo.
2) Conectar la placa Nordic en la PC mediante un cable USB.
3) Asegurarse de que la placa Thingy:91 se encuentre encendida.
4) En la pantalla del LTE Link Monitor hacemos click en Select Device y
seleccionamos nuestro dispositivo en la lista que se despliega.
5) Verificar la conexión con el modem del Nordic Thingy:91 enviando el
comando AT desde la ventana Terminal del Software LTE Link Monitor
y debemos observar que el modem nos responde con la palabra OK.
6)

186
Desde la ventana del Terminal podemos ver mensajes Debug emitidos por la
placa y podemos probar el envío de comandos AT al modem.

187
188
LoRaWAN una red para IoT

189
190
COMUNICACIONES INALAMBRICAS
LoRaWAN

¿Qué es LoRa?
LoRa o LoRaWAN es una tecnología utilizada para la comunicación inalámbrica
entre pequeños dispositivos, como pueden ser los dispositivos IoT. LoRaWAN
es una especificación para redes de baja potencia, pero que cubren una gran
área de comunicaciones, estas redes se denominan LPWAN, que proviene de
las siglas en ingles de LowPower Wide Area Network. Este protocolo de
comunicación define la capa de nivel 2(red) en los niveles OSI, lo que se
conoce como MAC (Media Access Control). Entonces podemos decir que
LoRaWAN es el protocolo que se encarga de unir diferentes dispositivos LoRa,
gestionando sus canales de comunicación, sus parámetros de conexión, ancho
de banda, cifrado de datos, etc.

En el nivel 1 de capa OSI, el nivel físico, encontramos la tecnología LoRa de

comunicación, el cual permite el envío y recepción de información punto a
punto. Una de las características principales de un dispositivo LoRa es su largo
alcance para la comunicación, aun en dispositivos pequeños. Para lograr esto,
LoRa emplea la técnica de espectro ensanchado, en donde la señal a enviar
utiliza más ancho de banda que el que necesita, pero que permite una
recepción de múltiples señales a la vez que tengan distintas velocidades.

La empresa que desarrolló LoRa y posee su patente se llama Semtech.

Actualmente la fundación LoRa Alliance es la encargada del desarrollo del
estándar y su evolución. Otra empresa que apuesta de manera fuerte a esta
tecnología es Microchip, la cual desarrolla módulos que poseen todo lo
necesario para la comunicación y también ha implementado redes privadas en
distintas ciudades.

Comunicaciones de largo alcance

Una de las virtudes de la comunicación LoRa es su largo alcance en las
comunicaciones, ya que bajo ciertas condiciones favorables, estamos hablando
de alcances que pueden llegar a los 20Km. Podemos decir además, que LoRa es
la abreviación de Long Range, que significa, largo alcance.

191
Las frecuencias de comunicaciones que LoRa utiliza son principalmente las de
las bandas ISM, que son bandas de frecuencias de uso no comercial, para las
áreas industriales, científicas y médicas. Aunque la tecnología puede operar en
cualquier frecuencia por debajo de 1GHz. El uso de estas frecuencias se debe a
que mientras se respete los valores de emisión, cualquier persona o empresa
puede hacer uso de ella sin necesidad de licencia.

Las bandas de frecuencia que utiliza LoRa son las de 433MHz, 868MHz y
915MHz, esta última, solo se utiliza en América, ya que en Europa no se puede
usar la 915MHz.

Como Funciona
La tecnología LoRa especifica los formatos de modulación de radio para lograr
largos alcances en las comunicaciones. Estos alcances se logran mediante el
uso de técnicas de espectro ensanchado y el uso de corrección de errores. Algo
interesante para destacar es que debido a la ortogonalidad de la modulación y
el uso de espectro ensanchado, se puede decodificar múltiples señales en una
misma frecuencia. Esta característica permite definir en LoRa unos canales de
comunicación llamados “canales virtuales”.

Los parámetros que posee un canal de comunicación LoRa son:

• Canal: Identifica los canales que se utilizarán dentro de la banda de

frecuencia.
• Spreading factor (SF): define el número de bits usado para codificar un
símbolo. A mayor SF, menor velocidad de transferencia tendremos
pero una mayor inmunidad a las interferencias.
• Coding Rate (CR): Indica la forma de codificar para la corrección de
errores. Es decir, según la técnica especificada, añade simbolos de
control para saber si los datos son correctos o no e incluso poder
determinar los valores correctos.
• Bandwidth (BW): Indica el ancho de banda que se va a utilizar en la
comunicación.

Establecer una comunicación punto-a-punto con LoRa es relativamente

sencillo. A distancias muy cortas, menos de 1 Km, no suele haber muchos
problemas, simplemente se establecen valores a los parámetros
anteriormente mencionados.

192
La cosa se complica para distancias más grandes. Porque además de usar
antenas con mayor ganancia y que sean visibles directamente unas a las otras
sin obstáculos de por medio, es necesario una correcta configuración de los
parámetros de la comunicación, como el canal, la velocidad, el coding rate, etc.

Es por ello que la capa de LoRaWAN aparece en escena para ayudar a

simplificar el uso de esta Red, ya que esta capa se encarga de cifrar los datos,
para que personas ajenas no hagan uso de ellas, haciendo un uso seguro de
estas redes. Para que estas operaciones de cifrados se lleven a cabo, solo
debemos preocuparnos por registrar nuestro dispositivo en la red e
identificarlo de manera única. Cabe destacar que, al ser LoRaWAN una red
bidireccional, existen 2 tipos de mensajes:

UPLINK o UL >> son mensajes originados en el device y enviados al servidor

(por medio de los gateways)

DOWNLINK o DL>> son mensajes originados en el servidor y enviados al device

(por medio de los gateways)

Estructura de una Red LoRa

Una red LoRa utiliza una topología de conexión del tipo estrella, en donde cada
nodo puede enviar mensajes hacia múltiples gateways que se encuentren
distribuidos en la Red. Estos gateways se encuentran conectados con
servidores de Red mediante un enlace IP. Esto se puede visualizar en la imagen
que se muestra de la arquitectura de una red LoRa. Algo que se debe
mencionar es que desde un dispositivo o nodo final, no es posible enviar un
mensaje a un determinado Gateway, o que un dispositivo pertenezca a un
Gateway, sino que los mensajes que se envían desde los nodos son recibidos
por todos los gateways en la zona de cobertura o alcance de ese nodo.

193
Los dispositivos que conforman una Red LoRa son los siguientes

• End Device: son los dispositivos finales de la Red LoRa, se utilizan para
enviar pequeñas cantidades de datos a una baja frecuencia, para
alcanzar grandes distancias. Estos dispositivos suelen ser sensores que
envían información constante a los Gateways.
• LoRa Gateway: Un Gateway en la Red LoRa recibe los paquetes que se
envían desde los nodos finales. Cuando un Gateway recibe un
mensaje, este lo envía al servidor de Red para su procesamiento
utilizando un enlace IP o por medio de conexiones 3G/4G
• Network Server: El servidor de Red es el encargado de gestiona toda la
red entera. Cuando recibe un paquete, se encarga de remover toda la
redundancia y realiza los chequeos de seguridad para verificar la
integridad del mensaje. Luego determina cual es el Gateway mejor
posicionado para enviar la respuesta de acknowledge.
• Application Server: Un servidor de aplicaciones es el lugar donde se
procesan todos los datos enviados por los dispositivos finales y toma
las acciones necesarias de acuerdo a esos mensajes.

Seguridad en LoRa
En todo desarrollo IoT es muy importante la seguridad para mantener la
integridad de los datos y no puedan ser utilizados por terceros. LoRa utiliza dos
capas de seguridad para sus aplicaciones, una que trabaja en la capa de red y
otra que trabaja en la capa de aplicación. Estas dos capas de seguridad tienen

194
sus funciones bien definidas, la capa de seguridad de Red se utiliza para
autenticar el nodo que envío la información mientras que la capa de seguridad
de Aplicación no permite que un operador de la Red pueda tener acceso a los
datos de aplicación final del usuario. Entonces en LoRa existen dos niveles de
claves.

• Una clave única de 128-bits para autenticarse en la Red. Esta clave se

denomina Network Session Key
• Una clave única de 128-bits para asegurar la llegada de los datos desde
un dispositivo o nodo a la aplicación. Esta clave se denomina
Application Session Key.

De esta manera, los datos en una Red LoRa son encriptados dos veces;
primero los datos del sensor es encriptado por el nodo y luego es encriptado
otra vez por el protocolo de acceso al medio LoRaWAN. Luego de estos
procesos de encriptación, los datos son enviados al Gateway, que los envía al
Servidor de Red por medio de un enlace IP o 3G/4G.

El servidor de Red cuenta con la clave de Red (NwkSkey) y desencripta los

datos, los cuales luego lo pasa a la aplicación, el cual termina por desencriptar
completamente los datos utilizando la clave de aplicación (AppSKey). Esto es
importante saberlo, debido a como es la estructura de una Red Lora, porque
los Gateways reciben mensajes desde todos los nodos cercanos y por ello es
importante que el Gateway no pueda desencriptarlo.

195
Acceso a la Red
Para que un dispositivo pueda conectarse a la red, este necesita tener una
serie de parámetros compartidos con el servidor:

- Network Session Key (nwkskey)

- ApplicationSession Key (appskey)
- DeviceAdress (devaddr)

Además de esto, cada dispositivo tiene un Indentificador de dispositivo

(devEUI) y puede o no tener un appEUI, o identificador de aplicación.

La clave de una conexión exitosa y, por sobre todas las cosas, segura, es que
los 3 parametro litados arriba sean transferidos al dispositivo de manera
confiable, sin que sean posible interceptar los mensajes y que, en caso de que
un mensaje sean interceptado, no se compromenta la integridad de la red.

Por este motivo, existen fundamentalmente 2 maneras de conectarse a la red:

OTAA – Over The Air Activation

En esta modalidad, se usa una clave “temporal” e idealmente única

para cada dispositivo, como medio de encripción de los paquetes. De esa
manera, el proceso tiene, mas o menos, esta forma:

Device Sentido Network

JoinRequest
(enviadevEUI y appEUI UPLINK
sin encriptar)
JoinAccept (enviadevadr,
nwkskey y appskey,
DOWNLINK encriptados con el
appkey, que es
compartido)
Desencripda los
parámetros y cambia
estado a “joined”
Dispositivo en línea

196
ABP – Activation By Personalization

Bajo esta modalidad de conexión, en el momento de fabricar o

configurar el end-device, se le provee las claves de conexión (devadr, nwkskey,
appskey), de forma tal que no requiere pedir autorización a la red para
conectarse.

Si bien esta forma es mas simple y requiere menos ancho de banda,

presenta grandes problemas de seguridad y se recomienda no utilizarla en
redes comerciales.

Tipos de dispositivos

En las redes LoRaWAN, la especificación dictamina la existencia de 3

tipos de dispositivos en función de su capacidad de conexión:

a) Dispositivos Clase A
Estos dispositivos son equipos que normalmente estarán apagados (o
en modo “SLEEP”) y transmiten a la red un UL (UpLink) cuando ellos lo
consideren apropiado, lo que básicamente depende de la aplicación en
la que estén siendo utilizados.
Un ejemplo típico de un equipo Clase A es un sensor de temperatura,
que transmite una alarma cuando la temperatura excede el valor pre-
determinado por el usuario.

Así, nuestro equipo está normalmente apagado y se enciende

periódicamente para medir la temperatura. Si esta no hubiera
excedido el valor, vuelve a dormir. Si el valor es mayor al deseado,
transmite una alarma a la red.

Supongamos ahora que queremos cambiar el valor de esa alarma, de

25°C a 30°C… ¿Cómo lo hacemos si el equipo está normalmente
dormido?

197
 Pues el estándar prevee esto, habilitando 2 ventanas de tiempo en las
cuales el nodo o enddevice está en modo recepción ANTES de volver a
dormir:

De esta manera, es posible sincronizar los Downlinks (DL) del servidor

con los momentos en los que (asincrónicamente) se despiertan los
dispositivos.

El motivo por el cual existen 2 ventanas de recepción es un tema de

redundancia y se vuelve muy útil en casos donde la red tiene mucha
latencia, sobre toda asociada a la conexión de los gateways con el
servidor, y que se realiza a través de Ethernet o celular.

b) Dispositivos Clase B

Los dispositivos Clase B permiten disminuir un poco la latencia,

comparado con equipos Clase A, al programar un periodo de escucha
en un tiempo o intervalo conocido.

198
 El concepto de Clase B es que, la red, le pide al dispositivo pasar a
Clase B. Luego de esto, el dispostivo abre una ventana de recepción
periódicamente dentro de la cual puede recibir datos, un pedido de
ping o un beacon, que sirve para sincronizar constantemente a los
diversos dispositivos.

El objetivo de este sistema es optimizar el consumo de batería del

dispositivo y permitir disminuir la latencia sin un impacto considerable
en la duración de la misma.

c) Dispositivos Clase C

Los dispositivos clase C equipos preparados para minimizar la latencia

de los mensajes, ya que están la mayor parte del tiempo esperando
recibir un downlink.

Estos equipos, luego de efectuar la trasmicion, ingresan en modo

recepción y puede recibir DLs en cualquier momento.

En el caso del RN2903A, al recibir un downlink en modo clase C

veremos que imprime un mensaje por la UART similar al siguiente:
‘macrx5 8888’, siendo ‘5’ un puerto de ejemplo y ‘8888’ el hipotético
dato enviado.

199
 Estructura de Canales

En LoRaWAN existe una estructura de canales pre-acordada y definida

en el estándarde la norma (ver Apéndice 1 “LoRaWAN Regional
Parameters”, Sección 2.5.2). En ese documento, se especifican los canales
que se usan para UL y DL:

Frecuencias de AU915-928

Como se observa en la Figura X, los canales verdes son los de UL con ancho
de banda de 125 kHz, los celestes son los de UL de 500 kHz y los naranjas
son los de DL.

Esta especificación tiene:

- UL >> 64 canales del 0 al 63, de 125 kHz de ancho de banda,

comenzando en 915.2 MHz y espaciados 200 kHz
- UL >> 8 canales del 64 al 71, de 500 kHz de ancho de banda,
comenzando en 915.9 MHz y espaciados 1.6MHz
- DL >> 8 canales del 0 al 7, de 500 kHz de ancho de banda, comenzando
en 923.3 MHz y espaciados 600kHz

Si dividimos los 64 canales en grupos de 8, podemos ver que hay 8 octetos.

Esto es importante porque la norma especifica que, los UL que se
transmiten en el primer octeto, serán respondidos por el 1er canal de
Downlink (DL), los que se transmiten en el 2nd octeto, son repondidos en
el 2nd canal de DL y así sucesivamente para cada canal.

200
 Recomendamos leer detenidamente la sección 2.5 del apéndice 1 de la
web del libro que explica exactamente como se diagramó LoRaWAN para
AU915-928 ANTES de continuar leyendo este libro. Son sólo 4 páginas y los
datos ahí contenidos se considerarán como conocidos de ahora en
adelante.

¿Qué canales uso?

Al seleccional los canales en un gateway, es posible seleccional

cualquiera de los octetos. Cabe destacar, que existen gateways de 8 canales,
de 16, 32, 64, etc, con lo cual en algunos modelos es posible utilizar mas de un
octeto a la vez, lo que le agrega capacidad al gateway.

Cuando se usa una red pública, el operador de la red puede

informarnos que canales usa dicha red.

Dicho esto, vamos a hablar ahora de la selección automática de

canales y cómo LoRaWAN soluciona esta problemática.

Selección automática de canales

La especificación de LoRaWAN resuelve la selección de canales muy

fácilmente, utilizando un comando MAC que indica al enddevices qué canales
debe usar. Así, en una red adecuadamente configurada, la operatoria es la
siguiente (suponemos una red que opera en el 2do octeto):

1) El enddeviceenvia un JoinRequest (OTAA)

a. Por norma, el envio se tiene que enviar en cualquiera de los 71
canales de UL aleatoriamente
b. Eventualmente, va a transmitir por uno de los 8 canales que
usa nuestra red.
2) Al recibir el JoinRequest OTAA, la red responde con “JoinAccept” y le
indica, en el mismo mensaje, qué canales tiene que usar el dispositivo
a partir de ese momento (en este caso, pedirá usar el 2do octeto
3) Las próximas transmisiones van a ser realizadas únicamente en lo
canales permitido.

201
 Por estos motivos, NO se recomienda:

- Usar Join ABP

- Seleccionar manualmente y de manera fija los canales
- Usar gateways caseros, tipo Raspberry Pi, que tienen sólo 1 canal

Comandos MAC

Se mencionaron en párrafos anteriores los “Comandos MAC”. El listado

completo de comandos MAC pueden consultarlo (lo recomiendo!!) en el
apéndice 2, sección 5 “MAC Commands”.

Alli podrán encontrar la lista que sigue, y obviamente, la descripción de

cada comando:

Comandos MAC

202
No vamos a ahondar en todos los comandos, pero si mencionar algunos muy
importantes:

LinkADRReq y LinkADRAns
Estos comandos son los que transmiten 3 importantes datos:

- Configuración de canales (qué octetos van a usar)

- Configuración del Data Rate en caso de que el Adaptive Data Rate
(ADR) esté habilitado
- Confirmacion de paquetes transmitidos (si fuera solicitada la
confirmación)
- Potencia deseada: El networkserver tiene tambien la potestad de
seleccionar la potencia máxima de los dispositivos, con este comando
puede seleccionarla dinámicamente.

Tamaño de los Payloads: ¿Cuántos datos puedo transmitir?

Nuevamente vamos a hacer referencia a la especificación de
LoRaWAN. Ver la especificación regional, sección 2.5, punto 2.5.6 (que ya
deberías haber leído!). Ahí pueden encontrar esta tabla:

Payload size

El tamaño que, como usuarios nos interesa es el de la columna N, que va

desde 11 bytes hasta 242 bytes.

El tamaño varía según el DATA RATE utilizado en la comunicación y el

usuario deberá ser responsable por “partir” el mensaje en bloques que
quepan dentro del máximo permitido por el datarate.

203
 Sobre los puertos y los canales
En LoRa, como en otros lugares de la tecnología, hay dos conceptos
que a veces se mezclan.
Los canales son las frecuencias que se usan para transmitir los datos.
Según la especificación LoRaWAN se debe cambiar aleatoriamente entre
todos los canales habilitados al momento de hacer cada transmisión.
Los puertos, en cambio, son algo totalmente diferente y librado a lo
que el usuario quiera hacer.

El puerto, es un numero lógico que uno selecciona libremente al

transmitir un mensaje (puede ser desde 1 hasta 223, ya que los otros están
reservados). Así, los puertos son una herramienta muy importante para
ahorrar datos y ser mas efectivos u ordenados para enviar la información.
Por ejemplo, si quiero enviar los valores de temperatura, humedad y CO de
una habitación, puedo hacerlo de 2 formas:

Opción tradicional:

Byte 1 2 3 4
STATUS TEMP HUM CO

Opción usando puertos:

Port 10
Info TEMP

Port 11
Info HUM

Port 12
Info CO

Port 99
Info STATUS

204
De esta manera, lo que puedo lograr es una periodicidad diferente en cada
uno de los datos (por ejemplo cuando tienen una variación del 1%) pero
sin tener que transmitir los datos que no hayan cambiado.

Algunas preguntas importantes:

a) ¿Puedo poner siempre DataRate 3 y transmitir siempre 242 bytes?

El DR es un parámetro que, luego de muchas consideraciones,

termina estando directamente relacionado con el ALCANCE
que tiene la señal, por decirlo de una manera práctica y fácil de
comprender. Con DR 0 tengo el mayor alcance, y con DR 4 el
menor.

Así, si un usuario decide usar únicamente DR 3 estaría

reduciendo significativamente el alcance del equipo.

Como anteriormente recomendamos usar siempre el Adaptive

Data Rate (ADR) recomendamos que el usuario consulte el DR
al módulo de transmisión y, en base a eso, transmita sólo los
bytes disponibles (quizás dividiendo el mensaje en varias
trasmiciones).

b) Entonces…. ¿Pongo siempre DR0 y así tengo siempre el mayor

alcance?

Si dejamos el DR0 y siempre usamos esa configuración,

estaríamos haciendo un uso no óptimo del espectro, ya que los
mensajes en DR0 tienen un datarate de 300 baudios contrac 12500
baudios en DR4. Es normal que los operadores exijan tener diversidad
de DataRates para tener un buen uso del espectro y los canales que
tienenasignados.

c) ¿El módulo se encarga de dividir el mensaje sólo?

NO. El módulo no se encarga de esto. Si uno intenta transmitir

mas bytes de los transmitidos, el módulo dará un error
(‘invalid_data_len’).

205
 Problemas más comunes:

El comando Join OTAA responde siempre “Denied”

En estos casos, verificar las siguientes cosas:
- Verificar si el equipo está dado de alta en el servidor con las mismas
claves que fue confuigurado el hardware
- Verificar que el hardware sea del mismo plan de frecuencias que el
networkserver y el gateway (por ejemplo, que ambos sean AU915). El
módulo Microchip (RN2903A-I/RM103) viene grabado de fábrica con la
frecuencia US915 y debe ser actualizado su firmware.
- Verificar que el equipo esté dentro del área de cobertura del gateway.
Si bien uno normalmente habla de 15km de cobertura existen factores
que pueden atenuar mucho este alcance.
- Los módulos RN2903A versiones 1.0.3 o 1.0.5 usan la especificación
LoRa Regional versión 1.0.2 Rev A, verificar que elnetworkserver sea
compatible con dicha versión.

Mensaje de error: “Invalid data len”

Este error e produce cuando el mensaje a transmitir excede la

capacidad del buffer de transmisión y puede tener 2 orígenes:

- Verificar que el tamaño del mensaje no exceda el tamaño máximo

correspondiente al payload actual del módulo
- En caso que lo anterior este bien, es posible que usando DR0 el
módulo siga dando el error. Esto se debe a que el módulo puede estar
queriendo contestar algun comando MAC (configuración de canales,
confirmaciones, etc) y esos datos MAC ocupan lugar del payload. Ante
estas situaciones, se recomienda hacer una transmisión “dummy” de
un byte que no tenga importancia para poder liberar el buffer y
trasmitir las respuestas MAC. El comando sería, por ejemplo,
‘mactxuncnf 8 00’ (transmite un mensaje sin confirmación en el puerto
8. El dato es 0x00).

206
No puedo recibir el joinaccept o los downlinks

- Verificar que el servidor tenga habilitado los downlinks para el

devicecon el que se está trabajando
- Verificar que el gateway no esté muy cerca (en la misma habitación)
que el device. Si esto ocurre, es posible que el gateway esté recibiendo
el mismo mensaje en múltiples canales al mismo tiempo (interferencia
o crosstalk), generando el DL de respuesta en el canal incorrecto. Es
bueno que el GW esté correctamente instalado en una terraza o, por
lo menos, instalado en otra habitación, diferente a la del device.

207
¿CÓMO DAR DE ALTA UN EQUIPO EN UNA RED LORAWAN REAL?

A continuación, ilustraremos el proceso típico para dar de alta un

dispositivo en una red LoRaWAN comercial, en este caso utilizando como
network server el producto de la empresa Orbiwise, que es implementado por
la red YEAP! en Sudamérica.

Supuestos:

- Tenemos un dispositivo LoRaWAN compatible con la banda AU915 (en

este caso vamos a usar un RN2903A)
- Estamos en la zona de cobertura de la red

Paso 1. Ingreso al DASS (Data Access Sub-System)

Si accedemos al menú “devices” podremos crear o dar de alta un nuevo

dispositivo.

208
Al hacer click en el botón “AddDevice”, nos aparece la ventana de alta:

Dentro de esta primera ventana, vamos a cargar el devEUI del equipo, así
como tambien asignarle un nombre que nos permita luego identificarlo
rápidamente.

Luego se elije un deviceprofile y un Service profile, información que

normalmente es provista por el operador, y especifica si nuestro plan acepta o
no cosas como Clase C, ADR, etc.

Al completar los datos, nos vamos a la segunda parte, “keys”

209
En esta sección vamos a cargar la clase de nuestro equipo (en este caso es
Clase C) y su application Key (ver sección aparte sobre el applicationkey).

Una vez completados estos pasos, nuestro dispositivo ya está dado de alta y
podemos ir a ver los datos que está transmitiendo.

La página que muestra los datos los presenta encolumnados, en formato HEX,
y con algunas informaciones importantes sobre los mismos:

210
 - Direction: Indica si el mensaje es un uplink o downlink
- Fecha y time stamp
- FCNT: Framecounter del mensaje
- Port: Puerto utilizado
- Data Rate: datarate utilizado para el envio del mensaje
- RSSI del mensaje recibido
- Datos

Sobre las llaves (keys) y la seguridad

La seguridad en LoRa tiene que ser un aspecto importante a la hora de

planear un sistema IoT. Muchas veces uno como desarrollador deja la
seguridad para el último momento y esto termina afectando la seguridad de
nuestro desarrollo. Por esos motivos, las recomendaciones son las siguientes:

- Definir el esquema de seguridad a usar desde el primer momento del

proyecto
- Usar ‘appkey’ diferentes para cada equipo, para evitar que los devices
sean clonables
- Si es posible, usar una solución de hardware para la seguridad, como el
ATECC608 de Microchip

211
 Este IC, o soluciones similares, evitan tener que tener archivos
con listas de llaves que hacen que nuestro sistema sea
vulnerable

- En lo posible, y en proyectos grandes, usar un joinserver remoto, de

forma tal que podamos administrar las llaves por fuera del operador
de red y manteniendo control sobre las diferentes etapas del proceso

212
BUENAS PRÁCTICAS EN LA DIAGRAMACIÓN DE LAS REDES LORAWAN

A lo largo de los años que llevo trabajando con LoRaWAN, hemos podido
observar el crecimiento de estas redes y la popularización de estas en diversos
ámbitos. En esta pequeña sección, quisiera compartir con ustedes nuestras
experiencias y problemas mas comunes que encontramos, algunas serán
técnicas y otras de sentido común o comerciales.

LORA VS LORAWAN – “PARECIDO NO ES LO MISMO”

Hemos observado algunos clientes decepcionados cuando se dan cuenta que

compraron equipos “LoRa” en lugar de LoRaWAN.

Al adquirir productos para redes LoRaWAN es bueno corroborar que sean

efectivamente LoRaWAN, la mejor forma de hacer esto, es indicar al proveedor
que van a usar su propio Gateway y Network server.

Algunos fabricantes que intentan imponer sus productos ofrecen “empezar a

probar” con sus gateways propios y, cuando uno está adelantado en el
proyecto se da cuenta que en realidad los equipos usan la modulación LoRa
pero un protocolo propietario del fabricante en lugar del LoRaWAN.

213
COBERTURA DE LOS GATEWAYS

Mucho se puede decir y escribir sobre la cobertura de los gateways. ¿Llega

realmente a 15 km? ¿Qué cobertura me da en la ciudad?

Esas preguntas son las primeras que uno recibe cuando ofrece un gateway a un
cliente, pero lamentablemente no existe una respuesta única.

La verdad es que,si bien “RF” es una ciencia exacta y es posible calcular

exactamente la cobertura de un gateway, para lograrlo satisfactoriamente es
necesario tener muchísima información que, la mayoría de las veces, no
poseemos.

Por ejemplo, necesitamos conocer la atenuación que sufrirá la señal desde el

device hasta la antena. Como en la vida real no nos será posible obtener esta
información de manera precisa, lo mas práctico es considerar una cobertura en
función de la experiencia práctica adquirida en el campo, que ronda los
siguientes valores:

- 2km de radio de cobertura en ciudades densas

- 5km en lugaresurbanos
- 15km-20km en el campo

Obviamente, estos parámetros son aproximados y consideran una instalación

correcta de las anteanas, a un mínimo de 30m, con dispositivos que tambien
tengan una buena antena.

Luego entonces, al diagramar una red, se ejecuta el plan de despliegue con

esas coberturas y una vez realizado se mide el resultado obtenido.
Indefectiblemente se producirán áreas sin cobertura, en las cuales deberemos
agregar algungateway para obtener mejores resultados.

214
CALIDAD DE SERVICIO

Para saber si hay o no cobertura en un sitio, es necesario definir primero a qué

llamamos “cobertura”.

Una forma incorrectapero habitual de medir la cobertura es usando el nivel de

señal, o RSSI (o SNR). Confieso que lo he hecho durante un tiempo y realmente
no refleja la realidad ya que por la frecuencia en que trabaja LoRa existe
multipath (los mensajes llegan al gateway por diversos caminos) y es necesario
considerar este factor al momento de evaluar la cobertura.

El multipath provoca que, con un device y un gateway fijos, se midan valores

de RSSI diferentes, con una variación de entre 20 dBm y 30 dBm en muchos
casos. Lo que sucede es que la señal toma algunos caminos que hacen
imposible que sea demodulada por el gateway ya que llega con una intensidad
muy baja, esto provoca que, por ejempo, un mensaje se reciba con -120 dBm
de señal y el próximo no se reciba.

La manera que actualmente utilizamos para valorar la cobertura es contabilizar

la pérdida de paquetes, conmumente referida como frame error rate o FER en
los servidores comerciales. Un valor esperado y razonable está en 10% de
paquetes perdidos y es un valor que un networkserver profesional informa
como parámetro estadístico normalmente.

215
El procedimiento es, entonces, recorrer el sitio donde se desea verificar la
cobertura y hacer N transmisiones en cada lugar. Luego, verifica el FER en cada
punto y determinar si cumple o no con nuestro requerimiento.

Un factor importante para considerar es lo que mencionamos antes sobre el

multipath. Como el multipath nos genera pérdidas de mensajes,
recomendamos enfátcamente usar mas de un gateway en las instalaciones,
idealmente 3 dando cobertura a un sitio.

En una prueba que realizamos recientemente, logramos mejorar la tasa de

error de 60% de mensajes perdidos a 0% con el agregado de 2 gateways, para
tener 3 en total. Lo interesante de la prueba es que en esta configuración, cada
uno de los 3 Gateways tenía una tasa de error del 50%-60%, pero en conjunto
los 3 lograban llegar al 0% de error.

Veamos un ejemplo de esto:

En la imagen superior, cada línea representa un gateway recibiendo paquetes

de un único dispositivo.

216
Podemos ver ahí, que el FER en cada gateway (para ese dispositivo específico)
varía entre 0.8% y 99%, con niveles de señal y SNR muy variados.

Ahora bien, si vemos el dispositivo en si, el resultado es el siguiente:

Como podemos ver ahí, el equipo recibe TODOS los paquetes, sin que se
pierda ninguno.

En este caso en particular, posiblemente no se necesita tener 9 gateways, con

3 o 4 deberia ser suficiente.

217
218
El futuro de las comunicaciones
con 5G

219
220
Evolución de la tecnología celular y por qué hoy estamos
hablando de 5G

Introducción
Estamos transitando un momento en donde las nuevas tecnologías celulares
están cumpliendo el rol de habilitadoras de nuevas aplicaciones: gracias a
ellas, éstas se podrán implementar, cosa que con otras tecnologías hubiera
sido imposible o solo lograble de manera limitada o con ciertas restricciones.
Esto sucede con LPWA celular -tanto NBIoT como LTE-M-, y sucede con 5G
también desde luego. El objetivo de este capítulo es ofrecer un panorama
general de la tecnología 5G, para poner en conocimiento del lector
principalmente sus características técnicas, lo que diferencia a 5G de sus
predecesoras, y mencionar en base a todo esto algunas de esas aplicaciones
target que se habilitan. Así intentaremos mostrar por qué se habla de 5G no
tan solo como una evolución de las redes celulares, sino como una verdadera
revolución en la era digital.

Breve repaso de la evolución de las redes celulares para M2M

Históricamente, M2M celular (machine-to-machine, o sea un dispositivo
electrónico con capacidad de comunicación al exterior mediante el uso de las
redes celulares), se implementó utilizando una tecnología que había sido
pensada y concebida principalmente para comunicaciones telefónicas, es decir
para llamadas de audio. Con el arribo de LTE esto comienza a cambiar, y la
tecnología celular se orienta fuertemente hacia el uso de datos, incluso para
las llamadas telefónicas (a través de VoLTE, Voice over LTE). Desde el punto de
vista del usuario, los teléfonos son cada vez más usados para acceder a
Internet -a través de distintas aplicaciones, de mensajería, redes sociales,
portales de contenidos multimedia, navegadores, etc.- que para comunicarse a
través de llamadas telefónicas. Los teléfonos, así, fueron los primeros en
demandar cada vez más ancho de banda.

También aparecen y se definen por primera vez dos segmentos de tecnologías

claramente diferenciados: aquellas tecnologías pensadas para un conjunto de
aplicaciones de Internet de las Cosas (IoT), con sus aplicaciones y
requerimientos específicos (bajo consumo, ancho de banda medio o bajo,
cobertura ampliada, reducción de costos); y aquellas otras pensadas para
dispositivos donde el alto ancho de banda/baja latencia sea un requisito
fundamental: terminales móviles (telefonía e Internet), y claro, a su vez otro
conjunto de nuevas aplicaciones IoT. En las primeras encontramos las jóvenes

221
 redes LPWA -LTE-M y NBIoT-, mientras que en las últimas se encuentran las
redes LTE de categorías altas y las nuevas redes 5G que paulatinamente se van
desplegando en el mundo, con aplicaciones para telefonía y también para IoT.

Descripción y alcance de la tecnología 5G

Al hablar de 5G no nos referimos únicamente a una tecnología de acceso como

suele pasar con las previas generaciones de redes celulares sino que nos
referimos a una plataforma completa pensada para la unificación e integración
a largo plazo de nuevas tecnologías. De esta manera, estamos hablando no
solo de tecnologías de radio nuevas pensadas para maximizar el ancho de
banda minimizando latencias, sino también a muchos otros avances como son
Dynamic Spectrum Sharing (DSS) y Beam Forming que abarcan desde
compatibilidad con las actuales redes de LTE y mejora de calidad del servicio
hasta la integración de alta densidad en M2M. La idea central alrededor de 5G
es permitir la evolución a lo largo del tiempo y la habilitación de nuevas
verticales como veremos más adelante.

Podemos resaltar en la siguiente tabla las principales características de cada

tecnología, las cuales servirán para entender cuál es el foco de cada una, y a su
vez servir como un selector de tecnología. Conociendo la prioridad de los
requerimientos de una determinada aplicación, podemos determinar la
tecnología que logre el mejor equilibrio de estos. Por ejemplo, si estamos
buscando una aplicación alimentada exclusivamente a baterías, que debe
tener una autonomía larga en el tiempo, NBIoT será la tecnología que mejor
cumpla ese aspecto técnico. Dependiendo de otros requerimientos -como ser
por ejemplo ancho de banda, disponibilidad de redes, costo- se puede
terminar de decidir si es esa la tecnología adecuada, o si se debe optar por
otra.

Ancho de
Rango de Costo
Tecnolo Banda Cantidad
Consumo Frecuencias Alcance Relativo del
gía (DL/UL) de Bandas
[MHz] Módulo
[Mbps]
0.296/0.236 Moderado 800-900;
2G 4 Moderado $
1 – Alto 1800-1900
3G 42/5.76 2 Moderado 800-900; 5 Moderado $$$

1
Con EDGE
2
Con HSPA+, cuya implementación no es uniforme en el mundo

222
 – Alto 1800-2100
LTE 4G Moderado Moderado –
150/50 3 700-3000 20 4 $$$$
Cat4 – Bajo Alto
LTE-A
4G 1200/150 5 Alto 700-3000 20 6 Moderado 6 $$$$$
Cat18
5G Sub Moderado –
2100/900 7 Alto 700-6000 26 8 $$$...$$$
6GHz Bajo
5G
26.500-
mmWav 7000/3000 Alto 13 9 Bajo $$$...$$$
43.500
e
LTE-M 0.58/1.11 Bajo 700-3000 17 4 Elevado $$
Muy
NBIoT 0.12/0.15 10 Muy bajo 700-3000 17 4 $
Elevado

Sub-6 vs mmWave
La necesidad de integración y planeamiento a futuro provoca que el uso y
asignación del espectro utilizado para los enlaces 5G sea de alta importancia.
Por un lado, el uso eficiente se hace crítico para la integración masiva de
dispositivos y por otro, la creciente demanda en tasas de transferencia
requiere la disponibilidad de canales con elevado ancho de banda.

Distintos escenarios se adaptarán mejor a distintas frecuencias y por lo tanto

aparece una diferencia en las frecuencias de radio por debajo de 6GHz (Sub-6)
que se divide a su vez en dos bandas: entre 500MHz y 3GHz (Low-Band) y 3 a
6GHz (Mid Band) y, por otro lado, frecuencias superiores a 24GHz (mmWave).

Cada una de las bandas presenta distintas características, por lo que a la hora
de hacer un despliegue se podrá hacer uso de la más indicada para la
aplicación. En general, a frecuencias mas bajas se logra un mayor alcance y por
lo tanto mayor cobertura mientras que frecuencias más altas ofrecen anchos
de banda más elevados y por lo tanto velocidades mas altas y menores
latencias. Por otro lado, el uso de frecuencias más altas puede requerir el uso
de técnicas especiales (Beam Forming, Massive MIMO, etc) que aumentan la
complejidad de la infraestructura de red y del dispositivo.

3
LTE-FDD
4
Para un dispositivo con cobertura global
5
LTE-FDD + CA
6
Requerimientos únicamente de cobertura. No asegura throughtput
7
Cifras para 5G SA.
8
Según deployments actuales.
9
Según deployments actuales
10
NBIoT2 (3GPP R14)

223
Según las características podemos comparar las bandas de la siguiente
manera:

Sub 6 GHz mmWave

Alcance y Cobertura Moderado/Alto Bajo/Moderado
Reutilización de Espectro de LTE Si No
Tasa de Transferencia Alta Muy alta
Latencia Baja Muy baja / Ultra baja
Complejidad Moderada Alta

Espacios de uso
Indoor: mmWave puede permitir anchos de banda elevados para Uplink y
Downlink así como latencias ultra bajas y conmutación entre subida y bajada
muy rápida. Esto lo hace especialmente atractivo para distribución de
conexiones wideband pudiendo incluso reemplazar enlaces de fibra.

Outdoor mediano alcance: Tanto Sub-6 GHz como mmWave proveen elevados
anchos de banda y movilidad mejorada para distancias cortas/medias. La
reutilización del espectro de LTE hace especialmente atractivo el uso de Sub-
6GHz. Las técnicas de Beam Forming y Massive MIMO permiten un uso
eficiente y una calidad de servicio elevada donde la densidad de celdas sea
elevada (ej: zonas urbanas).

Outdoor alto alcance: La utilización de espectro en Low Band permite alcances

mayores para despliegues en zonas donde la densidad de celdas no sea tan
elevada.

Beamforming
Mediante la utilización de paneles irradiantes compuestos por hasta 256
antenas radiobase irradiar de manera direccional (en forma de haz o ‘beam’)
dirigido hacia un dispositivo en particular. La utilización de esta técnica
permite mayor tolerancia a factores que puedan afectar la señal. Está pensada
para dispositivos de altas tazas de transferencia.

Con la adición de tecnologías como beamtracking entre otros avances, es

posible utilizar esta ténica incluso en escenarios NLOS (Non Line of Sight).

Tecnologías IoT
La adopción de 5G tiene como principal objetivo la evolución de LTE hacia un
ecosistema completo. Si bien las tecnologías IoT como NBIoT y eMTC (CatM o

224
LTE-M) son previas al standard de 5G son también parte de LTE y soportadas
por 5G.

Estas están también destinadas a evolucionar mediante la implementación de

nuevas características descriptas en siguientes stándares de la 3GPP. Algunas
de estas son Massive IoT (3GPP Rel-16) y NR-Light (3GPP Rel-17).

Despliegues Stand Alone y Non-Stand Alone

Es posible no solo la coexistencia de 5G con despliegues LTE preexistentes, sino

también la utilización de estos despliegues tanto para mejorar la performance
como para hacer uso eficiente del espectro. Es por esto que surgen tecnologías
como Dynamic Spectrum Sharing (DSS) y despliegues Stand Alone (SA) y Non-
Stand Alone (NSA).

DSS es una tecnología que permite la reutilización del espectro de LTE (Sub-6
Low band y Mid band) con bajo overhead entre ambas. Mediante DSS una
radiobase puede identificar la tecnología mas adecuada para el acceso de un
dispositivo de manera que en una misma zona geográfica, los dispositivos que
soporten 5G puedan recibir servicio bajo 5G y los que solo soporten LTE lo
hagan por esta red, ambas con una única antena. A demás, DSS beneficia a los
dispositivos LTE ya que el uso de 5G genera una descongestión de las redes
LTE.

Los despliegues pueden ser también de tipo Stand Alone donde la red 5G es
autocontenida de manera que la infraestructura completa es de 5G o Non-
Stand Alone donde parte de la infraestructura de 5G se realiza sobre
infraestructura LTE. Mediante utilización de las redes LTE -cuando haya
disponibilidad- se logra aumentar el ancho de banda disponible para 5G y
aprovechar la infraestructura existente. Cuando se hable de redes nuevas sin
previa existencia de LTE, el mismo resultado puede lograrse con 5G a través de
la utilización de la banda baja (Low Band).

225
Nuevas aplicaciones que se habilitan
Del análisis de las características de las tecnologías que hemos hecho,
encontramos dos nuevas familias de aplicaciones que se habilitan con 5G:
aquellas que requieren principalmente muy alto ancho de banda (ejemplo,
CPEs para internet domiciliaria/oficina, sistemas de transmisión de video de
alta definición en tiempo real, etc.), y aquellas otras aplicaciones que
requieren muy baja latencia (principalmente hoy podemos pensar en el
vehículo conectado, con el vehículo autónomo al final de ese roadmap).

Hogar y home-office
• CPE, router celular
Para brindar conexión de alta velocidad a Internet a través de
Wifi/Ethernet dentro del hogar o la oficina.
• Gaming, streaming de alta definición (4K, 8K)
A través del acceso a Internet de alta velocidad en el hogar, permitir el
streaming de video en alta resolución a través de las múltiples
plataformas existentes en la actualidad. Es importante también
resaltar con la importancia de la baja latencia en lo que respecta a
gaming online o servicios de video llamada/conferencia.

Smart City
• Video vigilancia
Múltiples cámaras transmitiendo video en alta resolución hacia un
servidor remoto, con proceso en tiempo real -ya sea local o del lado
del servidor – para extraer información de los mismos.

CV2X, el vehículo conectado y el vehículo autónomo

• Vehículo conectado, vehículo autónomo
CV2X (Cellular Vehicle to Everything) es una aplicación típica donde la
baja latencia es un requerimiento clave para que la aplicación pueda
desarrollarse en su máximo potencial. Imaginemos que un vehículo a
alta velocidad deba ser informado que hubo un choque en su camino
200 metros adelante: mientras más rápido este vehículo sepa de esto,
antes podrá reaccionar. El vehículo autónomo (sin conductor)
podemos encontrarlo en el final del roadmap del vehículo conectado
(con asistencia al conductor).

226
Otras
• Realidad Aumentada
La realidad aumentada consiste básicamente en, sobre un video
obtenido (lo “visto”, la “realidad”) superponer información tal como
imágenes, video o texto (lo “aumentado”). Para que esto sea fluido,
hace falta poder procesar velozmente el video online, acceder a
determinadas bases de datos y obtener la información a agregar. Esto
requiere ambos, gran ancho de banda y baja latencia para que la
experiencia sea satisfactoria.

Módulos de comunicación
Quectel RM500Q-GL

El RM500Q-GL es un módulo 5G Sub6GHz de la marca Quectel con factor de

forma M2 (52 x 30mm), basado en el chipset Qualcomm Snapdragon X55.
Soporta tanto SA como NSA y es una versión considerada global, cubriendo

227
prácticamente todas las frecuencias de los deployments actualmente
anunciados. Tiene además fallback a 4G (LTE Cat 20) y a 3G, y cuenta también
con GNSS embebido.

Sumando a las especificaciones técnicas mencionadas, la disponibilidad de

drivers USB/PCIe para los distintos sistemas operativos (Windows, Linux,
Android), Quectel permite con este módulo el acceso al ecosistema 5G de
manera rápida a los productos más demandantes.

Diagrama en bloques

Diagrama en bloques del módulo 5G Quectel RM500Q

Al analizar un módulo 5G podemos encontrar una estructura similar a la de

cualquier módulo de comunicación celular compuesto por los siguientes
sistemas:

Baseband (Baseband Processor o BP) que se encarga de controlar todas las

funciones de radio. Este es el responsable de implementar los protocolos de
acceso y de cumplir los estándares y regulaciones.

228
PMIC (Power Management IC) cuya función es proveer de energía a los
distintos sistemas del módulo. Cada uno de estos puede tener requerimientos
distintos en cuanto a niveles de voltaje y corriente y pueden funcionar de
manera independiente.

Transceiver o transmisor-receptor que se encarga de controlar las antenas.

Bloques de Tx/Rx compuestos por componentes de acondicionamiento de

señal así como de transmisores, receptores y switches de RF.

Interfáz con Host que tiene que permite integrar al módulo a un sistema
utilizando una interfaz conocida y estandarizada. Este debe poder proveer el
ancho de banda suficiente para no generar un cuello de botella.

Caso de Uso: 5G + Edge Computing+ Inteligencia Artificial

para control de tránsito a partir de video monitoreo
(Santiago, Chile)

Hoy en día, el servicio de transporte en las grandes ciudades de Latinoamérica

se ve complicado debido al crecimiento constante del parque automotor. En
Chile, según datos del Instituto Nacional de Estadísticas (INE), solo en el
período 2009-2019 el parque vehicular tuvo un crecimiento de alrededor del
70%, para alcanzar un total de unos 5.6 millones de vehículos con permiso de
circulación. Esto desde luego trae consecuencias, impactando por ejemplo de
manera directa en los tiempos de traslado y calidad de vida de los ciudadanos
y generando nuevos desafíos en lo que respecta a la planificación territorial.
Para ello, la autoridad gubernamental genera políticas públicas para mejorar la
gestión de tránsito, siendo una de ellas la captura de datos para la mejor toma
de decisiones en cuanto al control de los semáforos.

La Unidad Operativa de Control de Tránsito (UOCT), se dedica a optimizar la

gestión de tránsito en las principales ciudades del país, a través de la
administración y operación de sistemas inteligentes de transporte y el

229
mejoramiento de los sistemas de información a los usuarios, con el objetivo de
optimizar las condiciones de desplazamiento de las personas. Para tal fin,
cuenta con un parque de cámaras instaladas (tanto analógicas como IP), donde
operadores en distintas centrales de monitoreo están encargados de, en base
a lo observado en estas, optimizar el tráfico en la ciudad a través de la gestión
dinámica de los semáforos.

Uno de los desafíos es el de brindar nuevas y mejores herramientas

tecnológicas que no solo faciliten esta tarea, sino que también permitan
mejores resultados, a su vez buscando aprovechar en la medida de lo posible la
infraestructura ya instalada. En ese sentido y como ya dijimos, 5G es una
tecnología capaz de revolucionar las comunicaciones debido a sus
características de ancho de banda y latencia, permitiendo para el caso puntual
de aplicaciones de video-análisis, reducir los costos de instalación de nueva
infraestructura con la posibilidad además de poder adaptar a esta tecnología el
parque instalado. Por otro lado, con la utilización de inteligencia artificial y
edge computing en este sistema integral, se logra un gran aporte en la medida
de generar de manera automatizada información respecto de la detección de
vehículos (tipo de vehículos, sentido y velocidad de circulación, entre otros
datos) y conocer el estado de las distintas arterias de las ciudades, obteniendo
así información detallada y en tiempo real que permitirá una más eficiente
toma de decisiones en las centrales de monitoreo destinadas a tal fin.

El piloto
Una de las principales empresas de telecomunicaciones de Chile lanzó a
principios de 2021 una zona de cobertura experimental 5G (en dos comunas de
la región metropolitana de Santiago de Chile), con el objetivo de habilitar
pruebas de la tecnología tanto para el mundo público como el privado.

VSaaS, además de utilizar su plataforma de video analytics, implementó un

dispositivo electrónico de edge computing con conectividad 5G, utilizando un
módulo Quectel RM500Q trabajando en la banda N78 desplegada, con el fin de
conectar un determinado número de cámaras de la Unidad de control de
tránsito del Ministerio de Transporte.

230
Descripción grafica del trabajo de campo implementado. Comuna de las Condes,
Santiago de Chile.

Un tema importante radicó en la capacidad de detección de la tecnología de

VSaaS para capturar imagen proveniente de una cámara analógica y
desarrollar analítica de detección de objetos en condiciones reales (contraluz).
Esto se puede visualizar en la figura inferior.

Comparación modelos de detecciones. Imagen izquierda; un modelo de detección

tradicional. imagen derecha; modelo desarrollado por VSaaS (en ambiente Edge), con
imagen de baja resolución y condiciones pobres de luz.

Finalmente se entregaron los siguientes resultados a los usuarios del sistema:

1. Tráfico vehicular oriente/poniente/norte/sur clasificado según

tipo de vehículo

2. Reportes de conteo según tipo de vehículos por

hora/día/semana

231
 3. Identificación de patrones que generan la congestión vehicular

a. Horas en particular en el día

b. Zonas donde se produce mayor congestión.

c. Detección de semáforos y comparar con el

comportamiento del tráfico durante las horas de congestión.

Dashboard de analítica de tráfico en tiempo real ( BI apoyado con integración

transpara.com)

A continuación, se presenta una seria de dashboard sobre analítica de tránsito.

Dashboard de resumen semanal de comportamiento de conteo de tipo de vehículos y

su dirección.

232
Dashboard de resumen de comportamiento de conteo de tipo de vehículos por semana,
con diferenciación por día de la semana (arriba), y por hora según días hábiles (inferior
izquierdo) y fines de semana (inferior derecho) .

Tabla tipo heatmap para analizar comportamiento de trayectos versus días de la

semana, para poder identificar patrones según horario y tipo de vehículo.

233
Alertas por aglomeración y/o esperas prolongadas de peatones.

Alertas por congestión vehicular.

234
Obstrucción de Intersecciones

Estas herramientas permiten a la UOCT poder realizar correcciones y mejoras

en los programas de control de tránsito, contando con feedback en tiempo real
a través de la plataforma VSaaS y sus diversas herramientas de analítica a
través de la red 5G.

Por otro lado, para futuro desarrollo se solicitan nuevas capacidades tanto en
torno a la gestión de tráfico como a la seguridad vial, tales como:

1. Análisis de comportamiento de tráfico de múltiples cámaras, indicando

el tipo de vehículos que están en las vías.
2. Detección de patentes y uso de vías exclusivas (alta resolución de
cámaras)
3. Sincronización en la plataforma de nuevas fuentes de datos
a. Semáforos
b. Apis de otros sistemas de gestión de tránsito

235
 4. Análisis forense sobre:
a. Imágenes de autos y/o patentes
b. Alarmas de zonas
c. Congestión de tránsito.

Despliegue actual y roadmap

Mientras escribimos este texto, en Febrero 2021, Telecom en Argentina

anunció el encendido de los primeros sitios trabajando en DSS en la Ciudad de
Buenos Aires y Rosario 11. Chile abrió las licitaciones para adjudicar espectro
para 5G, y tiene sitios de prueba iluminando parte de Santiago en Sub 6GHz 12.
Distintas operadoras de otros países de LATAM se encuentran en caminos
similares, cada una con distinto nivel de avance, pero con un roadmap en el
mismo sentido de aprovechamiento transitorio de la infraestructura LTE,
esperando la definición y posterior licitación de nuevo espectro. Telefónica
trabaja buscando replicar la experiencia en Europa 13, Claro se encuentra
trabajando fuerte particularmente en Brasil, al igual que Antel en Uruguay, que
ya cuenta con distintos nodos funcionando en mmWave siendo aprovechados
en soluciones de videovigilancia por parte de empresas de logística y gobierno.

A nivel global, al día de hoy tenemos unos 303 despliegues anunciados de 5G a

través de 20 operadores, siendo principalmente China, Corea, EE. UU., Europa
y Australia los que lideran esos despliegues, contando ya en muchos casos con
servicio comercial disponible 14.

11
https://www.clarin.com/economia/telecom-habilito-primeros-sitios-5g-buenos-
aires-rosario_0_O-4523Gft.html
12
https://www.efe.com/efe/america/economia/chile-inaugura-la-primera-zona-5g-de-
prueba-latinoamerica/20000011-4444107
13
https://www.telefonica.com/es/web/sala-de-prensa/-/telefonica-supera-sus-
objetivos-de-despliegue-de-5g-en-espana-y-alcanza-una-cobertura-del-76-de-la-
poblacion
14
https://www.gsma.com/membership/resources/ooklas-new-5g-map-tracks-5g-
rollouts-across-the-globe/

236
Síntesis: la revolución del 5G

En el corto y mediano plazo, dependiendo la región, 5G pasará a dar vida a un

ecosistema tecnológico y productivo, en el cuál conviviremos de manera
cotidiana nosotros, las personas, con las cosas del IoT. Hasta ahora teníamos la
capacidad y el poder de procesamiento para aplicaciones sumamente
complejas, pero faltaba un canal de comunicación acorde que haga llegar la
información desde cualquier punto remoto hacia ese centro de procesamiento,
y poder obtener un resultado en tiempo real. 5G nos da esa posibilidad de
tiempo real para aplicaciones de alto ancho de banda -como ser, por ejemplo,
aquellas donde hay video de alta resolución involucrado-, o aquellas donde el
tiempo de respuesta -latencia- sea crítico -tan crítico como lo es para un
vehículo autónomo-.

Agradecemos a Santiago Fontan Balestra -Director de Ventas de Qualcomm en

Argentina-, y a Francisco Soto -cofundador y CEO del producto VsaaS, Chile-,
que colaboraron con material, y sobre todo con su tiempo, para aportar al
contenido de este texto.

Sobre los autores

Fernando Arian Blaha, Gerente de Ventas de Quectel en Argentina:

https://www.linkedin.com/in/fblaha/
fernando.blaha@quectel.com

Iván Castelucci Vidal, FAE de Quectel en Argentina:

https://www.linkedin.com/in/icvidal/
ivan.vidal@quectel.com

237
238
 Referencias y fuentes

Cifras de la consultora Statista: https://www.statista.com/statistics/802690/worldwide-

connected-devices-by-access-technology/

What is Edge Computing? Por la empresa de tecnología Gygabite

https://www.gigabyte.com/Glossary/edge-computing

https://www.link-labs.com/blog/what-is-an-iot-platform

Historia de Starbucks: https://www.imd.org/research-knowledge/articles/digital-business-

transformation/

“Blogografia” security of things:

https://www.arrow.com/en/research-and-events/articles/understanding-the-importance-of-
hardware-security

https://www.embedded.com/iot-security-physical-and-hardware-security/

https://sharedassessments.org/blog/a-new-roadmap-for-third-party-iot-risk-management/

https://www.rambus.com/blogs/hardware-root-of-trust/

Datasheet del Microchip AC164160 Wi-Fi

https://www.microchip.com/DevelopmentTools/ProductDetails/ac164160

Nordic Thingy 52, datasheet y notas de aplicación

https://www.nordicsemi.com/Software-and-tools/Prototyping-platforms/Nordic-Thingy-52

Nordic Thingy 91, datasheet, videos y notas de aplicación:

https://www.nordicsemi.com/Software-and-tools/Prototyping-platforms/Nordic-Thingy-91

LoRaWAN
https://lora-alliance.org/
https://www.microchip.com/wwwproducts/en/RN2903
https://www.mikroe.com/lora-2-click

239
 Se terminó de imprimir
en Junio de 2021
en Rolta, (4865-7337),
Ecuador 334, Buenos Aires.
www.rolta.com.ar

240