Capítulo 2.

Arquitectura y diseño de red IoT

Imagina que un día decides construir una casa. Usted conduce a la

tienda de suministros de construcción local e intenta averiguar qué
materiales necesitará. Usted compra la madera, las uñas y los tornillos,
la mezcla de cemento para la base, los materiales para techos, etc. Un
camión viene y deja todos los materiales en el sitio de su futuro
hogar. Miras los montones de materiales sentados en lo que esperas que
un día se convierta en tu jardín frontal y te des cuenta de que no tienes
idea de dónde empezar. Algo importante falta: ¡no tienes planes
arquitectónicos para la nueva casa! Lamentablemente, sus planes para
construir un nuevo y hermoso hogar tendrán que esperar hasta que
obtenga la ayuda de un arquitecto.
Como la mayoría de los constructores saben, incluso los proyectos de
construcción más simples requieren una planificación cuidadosa y una
arquitectura que se adhiere a ciertos estándares. Cuando los proyectos
se vuelven más complejos, los planes arquitectónicos detallados no solo
son una buena idea, sino que son, en la mayoría de los lugares,
obligatorios por ley.
Para completar con éxito un proyecto de construcción, se requiere
tiempo y esfuerzo para diseñar cada fase, desde la base hasta el
techo. Sus planes deben incluir diseños detallados para los sistemas
eléctricos, de plomería, de calefacción y de seguridad. Se necesitan
fuertes planos arquitectónicos (y la ingeniería requerida para
respaldarlos) en todos los proyectos de construcción, desde los más
simples hasta los más complejos. En el mismo sentido, una red
informática nunca debe construirse sin una planificación cuidadosa,
políticas de seguridad completas y el cumplimiento de prácticas de
diseño bien entendidas. Si no se construye cuidadosamente una red de
acuerdo con los principios de diseño de sonido probablemente resultará
en algo difícil de escalar, administrar, adaptar a los cambios de la
organización y, lo peor de todo, solucionar los problemas cuando las
cosas vayan mal.
La mayoría de los CIO y CTO entienden que la red maneja el negocio. Si
la red falla, las operaciones de la compañía pueden verse seriamente
dañadas. Así como una casa debe diseñarse con la fuerza para resistir
desastres naturales potenciales, como eventos sísmicos y huracanes, los
sistemas de tecnología de la información (TI) deben diseñarse para
resistir los "terremotos de red", como los ataques distribuidos de
denegación de servicio (DDoS). , requisitos de crecimiento futuro, cortes
de red e incluso errores humanos. Para hacer frente a estos desafíos, el
arte de la arquitectura de red ha ganado una gran influencia en las
organizaciones de TI en las últimas dos décadas. De hecho, para
muchas empresas, la responsabilidad de supervisar la arquitectura
de red a menudo se considera una de las posiciones más importantes en
las organizaciones de TI y tecnología operativa (OT). Por ejemplo, el
arquitecto principal jefe de la empresa (CEA) ha ganado tanta influencia
en los últimos años que el puesto se equipara a menudo con las
responsabilidades de un director de tecnología, y en muchos casos, el
CEA informa directamente al director general.
La arquitectura de la red de TI empresarial ha madurado
significativamente en las últimas dos décadas y, en general, se
comprende bien; sin embargo, la disciplina de la arquitectura de red de
IoT es nueva y requiere una nueva perspectiva. Es importante tener en
cuenta que si bien existen algunas similitudes entre las arquitecturas de
TI y de IoT, en su mayor parte, los desafíos y requisitos de los sistemas
de IoT son radicalmente diferentes de los de las redes de TI
tradicionales. La terminología también es diferente al punto donde las
redes IoT a menudo están bajo el paraguas de OT, que es responsable de
la administración y el estado de los sistemas operativos. Por el contrario,
las redes de TI se preocupan principalmente por la infraestructura que
transporta los flujos de datos, independientemente del tipo de datos.
Este capítulo examina algunos de los desafíos únicos planteados por las
redes IoT y cómo estos desafíos han impulsado nuevos modelos
arquitectónicos. Este capítulo explora las siguientes áreas:
Controles detrás de nuevas arquitecturas de red: Las redes
de OT manejan las operaciones comerciales industriales
centrales. Tienen características y restricciones únicas que no son
fácilmente soportadas por las arquitecturas de red de TI tradicionales.
Comparando las arquitecturas IoT: Se han publicado varias
arquitecturas para IoT, incluidas las de ETSI y el IoT World Forum. Esta
sección analiza y compara estas arquitecturas.
Una arquitectura de IoT simplificada: Si bien existen varias
arquitecturas de IoT, en esta sección se presenta un modelo simplificado
para sentar las bases del resto del material tratado en este libro.
La pila funcional Core IoT: La red IoT debe estar diseñada para
soportar sus requisitos y limitaciones únicos. Esta sección proporciona
una descripción general de la pila de red completa, desde los sensores
hasta la capa de aplicaciones.
IoT Data Management y Compute Stack: Esta sección presenta
la gestión de datos, incluidos los modelos de recursos de cómputo y
almacenamiento para IoT, e involucra el borde, la niebla y la
computación en la nube.

CONDUCTORES DETRÁS DE NUEVAS

ARQUITECTURAS DE RED
Este capítulo comienza comparando cómo utilizar un plano
arquitectónico para construir una casa es similar al enfoque que
tomamos al diseñar una red. Ahora imagine a un arquitecto
experimentado que ha construido casas residenciales para toda su
carrera. Es un experto en este campo y sabe exactamente lo que se
necesita para no solo hacer una casa arquitectónicamente atractiva, sino
también para ser funcional y habitable y cumplir con la
construcción códigos ordenados por el gobierno local. Un día, se le pide
a este arquitecto que emprenda un nuevo proyecto: construir un estadio
masivo que será una obra maestra para la ciudad y que apoyará una
variedad de equipos deportivos, conciertos y eventos comunitarios, y
que tiene una capacidad para 60,000 espectadores +.
Si bien el arquitecto tiene una amplia experiencia en el diseño de
viviendas, esas habilidades claramente no serán suficientes para
satisfacer las demandas de este nuevo proyecto. La escala del estadio es
de varias magnitudes más grandes, el uso es completamente diferente, y
el desgaste será a un nivel completamente diferente. El arquitecto
necesita un nuevo enfoque arquitectónico que cumpla con los requisitos
para construir el estadio.
La diferencia entre las redes IT y IoT es muy similar a la diferencia entre
arquitectura residencial y arquitectura de estadios. Si bien las
arquitecturas de red tradicionales para TI nos han sido útiles durante
muchos años, no son adecuadas para los complejos requisitos de
IoT. Capítulo 1 , " ¿Qué es IoT? "Presenta algunas de las diferencias
entre IT y OT, así como algunos de los desafíos inherentes que plantea
IoT. Estas diferencias y desafíos están impulsando arquitecturas
fundamentalmente nuevas para los sistemas de IoT.
La diferencia clave entre IT e IoT es la información. Mientras que los
sistemas de TI se preocupan principalmente por el soporte confiable y
continuo de aplicaciones comerciales como correo electrónico, web,
bases de datos, sistemas CRM, etc., IoT tiene que ver con los datos
generados por los sensores y cómo se usan esos datos. La esencia de las
arquitecturas de IoT implica, pues, cómo se transportan, recopilan,
analizan y, en última instancia, actúan sobre los datos.
Tabla 2-1 echa un vistazo más de cerca a algunas de las diferencias entre
las redes de TI e IoT, con un enfoque en los requisitos de IoT que están
impulsando nuevas arquitecturas de red, y considera qué ajustes son
necesarios.
Desde el punto de vista arquitectónico, los nodos de niebla más cercanos al
borde de la red reciben los datos de los dispositivos IoT. La aplicación IoT
de niebla luego dirige diferentes tipos de datos al lugar óptimo para el
análisis:

Imagen La mayoría de los datos sensibles al tiempo se analizan en el borde

o en el nodo de niebla más cercano a las cosas que generan los datos.

Imagen Los datos que pueden esperar segundos o minutos para la acción
se transfieren a un nodo de agregación para su análisis y acción.

Image Los datos que son menos sensibles al tiempo se envían a la nube
para análisis históricos, análisis de big data y almacenamiento a largo
plazo. Por ejemplo, cada uno de los miles o cientos de miles de nodos de
niebla puede enviar resúmenes periódicos de datos a la nube para su
análisis y almacenamiento histórico.

En resumen, al diseñar una red IoT, debe considerar la cantidad de datos

que se analizarán y la sensibilidad temporal de estos datos. Comprender
estos factores lo ayudará a decidir si la computación en la nube es
suficiente o si la computación de borde o niebla mejorará la eficiencia de
su sistema. La computación de niebla acelera el conocimiento y la
respuesta a los eventos al eliminar un viaje de ida y vuelta a la nube para
su análisis. Evita la necesidad de costosas adiciones de ancho de banda
mediante la descarga de gigabytes de tráfico de red desde la red
central. También protege los datos confidenciales de IoT analizándolo
dentro de los muros de la compañía.
RESUMEN
Los requisitos de los sistemas IoT están impulsando nuevas arquitecturas
que abordan los aspectos de escala, restricciones y gestión de datos de
IoT. Para abordar estas necesidades, han surgido varios modelos de
referencia específicos de IoT, incluidos el modelo oneM2M IoT y el modelo
de referencia IoT del IoT World Forum. Las características comunes entre
estos modelos son la interacción de los dispositivos IoT, la red que los
conecta y las aplicaciones que administran los puntos finales.

Este libro presenta un marco de IoT que utiliza aspectos de estos diversos
modelos y los aplica a casos de uso específicos de la industria. Este
capítulo presenta un modelo basado en conceptos comunes en estas
arquitecturas que rompe las capas de IoT en una arquitectura simplificada
que incorpora dos pilas paralelas: la Pila funcional Core IoT y la Gestión de
datos IoT y la Pila informática. Esta arquitectura establece el formato para
los capítulos que siguen en este libro.

La pila funcional Core IoT tiene tres capas: los sensores y actuadores IoT,
componentes de red y aplicaciones y capas de análisis. Los componentes
de red y las capas de aplicaciones implican varias subcapas que
corresponden a diferentes partes del sistema de IoT en general.

El IoT Data Management y Compute Stack se ocupa de cómo y dónde se

filtran, agregan, almacenan y analizan los datos. En los modelos de TI
tradicionales, esto ocurre en la nube o en el centro de datos. Sin embargo,
debido a los requisitos únicos de IoT, la administración de datos se
distribuye lo más cerca posible del borde, incluidas las capas de borde y
niebla.
Desde el punto de vista arquitectónico, los nodos de niebla más cercanos al
borde de la red reciben los datos de los dispositivos IoT. La aplicación IoT
de niebla luego dirige diferentes tipos de datos al lugar óptimo para el
análisis:

Imagen La mayoría de los datos sensibles al tiempo se analizan en el borde

o en el nodo de niebla más cercano a las cosas que generan los datos.
Imagen Los datos que pueden esperar segundos o minutos para la acción
se transfieren a un nodo de agregación para su análisis y acción.

Image Los datos que son menos sensibles al tiempo se envían a la nube
para análisis históricos, análisis de big data y almacenamiento a largo
plazo. Por ejemplo, cada uno de los miles o cientos de miles de nodos de
niebla puede enviar resúmenes periódicos de datos a la nube para su
análisis y almacenamiento histórico.

En resumen, al diseñar una red IoT, debe considerar la cantidad de datos

que se analizarán y la sensibilidad temporal de estos datos. Comprender
estos factores lo ayudará a decidir si la computación en la nube es
suficiente o si la computación de borde o niebla mejorará la eficiencia de
su sistema. La computación de niebla acelera el conocimiento y la
respuesta a los eventos al eliminar un viaje de ida y vuelta a la nube para
su análisis. Evita la necesidad de costosas adiciones de ancho de banda
mediante la descarga de gigabytes de tráfico de red desde la red
central. También protege los datos confidenciales de IoT analizándolo
dentro de los muros de la compañía.

RESUMEN
Los requisitos de los sistemas IoT están impulsando nuevas arquitecturas
que abordan los aspectos de escala, restricciones y gestión de datos de
IoT. Para abordar estas necesidades, han surgido varios modelos de
referencia específicos de IoT, incluidos el modelo oneM2M IoT y el modelo
de referencia IoT del IoT World Forum. Las características comunes entre
estos modelos son la interacción de los dispositivos IoT, la red que los
conecta y las aplicaciones que administran los puntos finales.

Este libro presenta un marco de IoT que utiliza aspectos de estos diversos
modelos y los aplica a casos de uso específicos de la industria. Este capítulo
presenta un modelo basado en conceptos comunes en estas arquitecturas
que rompe las capas de IoT en una arquitectura simplificada que incorpora
dos pilas paralelas: la Pila funcional Core IoT y la Gestión de datos IoT y la
Pila informática. Esta arquitectura establece el formato para los capítulos
que siguen en este libro.
La pila funcional Core IoT tiene tres capas: los sensores y actuadores IoT,
componentes de red y aplicaciones y capas de análisis. Los componentes
de red y las capas de aplicaciones implican varias subcapas que
corresponden a diferentes partes del sistema de IoT en general.

El IoT Data Management y Compute Stack se ocupa de cómo y dónde se

filtran, agregan, almacenan y analizan los datos. En los modelos de TI
tradicionales, esto ocurre en la nube o en el centro de datos. Sin embargo,
debido a los requisitos únicos de IoT, la administración de datos se
distribuye lo más cerca posible del borde, incluidas las capas de borde y
niebla.
Tabla 2-1 Drivers arquitectónicos IoT
Las siguientes secciones amplían los requisitos que impulsan cambios
arquitectónicos específicos para IoT.

Escala
La escala de una red informática típica es del orden de varios miles de
dispositivos, generalmente impresoras, dispositivos inalámbricos
móviles, computadoras portátiles, servidores, etc. El modelo tradicional
de red de campus de tres capas, que admite acceso, distribución y núcleo
(con subarquitecturas para WAN, Wi-Fi, centro de datos, etc.), es bien
conocido. Pero ahora considere lo que sucede cuando la escala de una
red va de unos pocos miles de puntos finales a unos pocos
millones. ¿Cuántos ingenieros de TI alguna vez diseñaron una red
destinada a admitir millones de puntos terminales IP enrutables? Este
tipo de escala solo ha sido vista previamente por los proveedores de
servicios de Nivel 1. IoT presenta un modelo en el que una empresa de
servicios públicos, una fábrica, un sistema de transporte o una ciudad de
tamaño medio podrían solicitar fácilmente una red de esta
envergadura. En función de los requisitos de escala de este orden, IPv6
es la base natural de la capa de red de IoT.

Seguridad
A menudo se ha dicho que si estalla la Tercera Guerra Mundial, se
peleará en el ciberespacio.Ya hemos visto evidencia de ataques
maliciosos dirigidos usando vulnerabilidades en máquinas en red, como
el estallido del gusano Stuxnet, que afectó específicamente a los sistemas
de controlador lógico programable (PLC) de Siemens.
La frecuencia y el impacto de los ciberataques en los últimos años se han
incrementado dramáticamente. La protección de los datos corporativos
contra intrusos y robos es una de las principales funciones del
departamento de TI. Los departamentos de TI hacen todo lo posible para
proteger los servidores, las aplicaciones y la red, y establecen modelos
de defensa en profundidad con capas de seguridad diseñadas para
proteger las joyas cibernéticas de la corporación. Sin embargo, a pesar
de todos los esfuerzos reunidos para proteger las redes y los datos, los
hackers aún encuentran formas de penetrar en las redes confiables. En
las redes de TI, la primera línea de defensa suele ser el firewall
perimetral. Sería impensable posicionar los puntos finales críticos de TI
fuera del firewall, visibles para cualquiera que se preocupe por mirar. Sin
embargo, los puntos finales IoT a menudo se ubican en redes
inalámbricas de sensores que usan espectro sin licencia y no solo son
visibles para el mundo a través de un analizador de espectro, sino que a
menudo son físicamente accesibles y ampliamente distribuidos en el
campo.
A medida que más sistemas de OT se conectan a las redes de IP, sus
capacidades aumentan, pero también aumenta su vulnerabilidad
potencial. Por ejemplo, a las 3:30 p. M. Del 23 de diciembre de 2015, la
red eléctrica ucraniana experimentó un ciberataque sin precedentes que
afectó aproximadamente a 225,000 clientes. Este ataque no fue llevado
a cabo simplemente por un grupo de ladrones oportunistas; fue un asalto
sofisticado y bien planificado en la red eléctrica ucraniana que tenía
como objetivo el sistema SCADA (control de supervisión y adquisición
de datos), que rige la comunicación a los dispositivos de automatización
de la red.
Los modelos tradicionales de seguridad de TI simplemente no están
diseñados para los nuevos vectores de ataque introducidos por los
sistemas IoT altamente dispersos. Los sistemas de IoT requieren
mecanismos consistentes de autenticación, cifrado y técnicas de
prevención de intrusiones que entiendan el comportamiento de los
protocolos industriales y puedan responder a los ataques a la
infraestructura crítica. Para una seguridad óptima, los sistemas de IoT
deben:
Ser capaz de identificar y autenticar todas las entidades involucradas
en el servicio IoT (es decir, puertas de enlace, dispositivos de punto final,
redes domésticas, redes de itinerancia, plataformas de servicio)
 Asegúrese de que todos los datos de usuario compartidos entre el
dispositivo de punto final y las aplicaciones de fondo estén encriptados
Cumpla con la legislación local de protección de datos para que todos
los datos estén protegidos y almacenados correctamente
Utilice una plataforma de administración de conectividad de IoT y
establezca políticas de seguridad basadas en reglas para tomar medidas
inmediatas si se detecta un comportamiento anómalo de los dispositivos
conectados
Adopte un enfoque holístico a nivel de red para la seguridad
Ver Capítulo 8 , " Asegurar IoT ", para obtener más información sobre
la seguridad de IoT.

Dispositivos y redes restringidos

La mayoría de los sensores IoT están diseñados para un solo trabajo, y
suelen ser pequeños y baratos. Esto significa que a menudo tienen una
potencia, CPU y memoria limitadas, y solo transmiten cuando hay algo
importante. Debido a la escala masiva de estos dispositivos y los
entornos grandes e incontrolados donde generalmente se implementan,
las redes que brindan conectividad también tienden a ser muy con
pérdidas y admiten velocidades de datos muy bajas. Esta es una
situación completamente diferente de las redes de TI, que disfrutan de
velocidades de conexión de varios gigabits y puntos finales con potentes
CPU. Si una red informática tiene limitaciones de rendimiento, la
solución es simple: actualice a una red más rápida. Si hay demasiados
dispositivos en una VLAN que impactan en el rendimiento, puede crear
una nueva VLAN y continuar escalando todo lo que necesite. Sin
embargo, este enfoque no puede cumplir con la naturaleza limitada de
los sistemas de IoT. IoT requiere una nueva generación de tecnologías
de conectividad que cumplan con las limitaciones de escala y
restricción. Para obtener información más detallada sobre dispositivos y
redes restringidos, consulte Capítulo 5 , " IP como la capa de red de
IoT ".

Datos
Los dispositivos de IoT generan una montaña de datos. En general, la
mayoría de las tiendas de informática no se preocupan demasiado por
los datos de conversación no estructurados generados por los
dispositivos en la red. Sin embargo, en IoT, los datos son como oro, ya
que permiten a las empresas ofrecer nuevos servicios de IoT que
mejoran la experiencia del cliente, reducen los costes y ofrecen nuevas
oportunidades de ingresos. Aunque la mayoría de los datos generados
por IoT no están estructurados, los conocimientos que proporciona a
través del análisis pueden revolucionar los procesos y crear nuevos
modelos comerciales.Imagine una ciudad inteligente con unos cientos
de miles de farolas inteligentes, todas conectadas a través de una red
IoT. Aunque la mayoría de la información comunicada entre los
módulos de la red de iluminación y el centro de control es de poco interés
para cualquier persona, los patrones en estos datos pueden arrojar
información extremadamente útil que puede ayudar a predecir cuándo
se deben reemplazar las luces o si se pueden encender o apagar. en
ciertos momentos, lo que ahorra gastos operativos. Sin embargo, cuando
todos estos datos se combinan, puede ser difícil administrarlos y
analizarlos de manera efectiva. Por lo tanto, a diferencia de las redes de
TI, los sistemas de IoT están diseñados para escalonar el consumo de
datos en toda la arquitectura, tanto para filtrar como para reducir datos
innecesarios que van en sentido ascendente y para proporcionar la
respuesta más rápida posible a los dispositivos cuando sea necesario.

Soporte de dispositivo heredado

El soporte de dispositivos heredados en una organización de TI
generalmente no es un gran problema. Si la computadora o el sistema
operativo de alguien está desactualizado, simplemente se actualiza. Si
alguien está usando un dispositivo móvil con un estándar de Wi-Fi
desactualizado, como 802.11bo 802.11g, simplemente puede denegarle
el acceso a la red inalámbrica y se verá obligado a actualizar. En los
sistemas OT, es probable que los dispositivos finales estén en la red
durante mucho tiempo, a veces décadas. A medida que se implementan
las redes IoT, deben admitir los dispositivos más antiguos que ya están
presentes en la red, así como los dispositivos con nuevas capacidades. En
muchos casos, los dispositivos heredados son tan antiguos que ni
siquiera admiten IP. Por ejemplo, una fábrica puede reemplazar las
máquinas solo una vez cada 20 años, o tal vez incluso más. No quiere
actualizar máquinas multimillonarias solo para poder conectarlas a una
red para una mejor visibilidad y control. Sin embargo, muchas de estas
máquinas heredadas pueden admitir protocolos más antiguos, como
interfaces en serie, y usar RS-232. En este caso, la red IoT debe ser capaz
de algún tipo de traducción de protocolo o utilizar un dispositivo de
puerta de enlace para conectar estos puntos finales heredados a la red
IoT. El Capítulo 6 , " Protocolos de aplicación para IoT ", analiza de
cerca el transporte de los protocolos de IoT heredados.

COMPARANDO ARQUITECTURAS IOT

Los desafíos y requisitos antes mencionados de los sistemas de IoT han
impulsado una disciplina completamente nueva de arquitectura de
red. En los últimos años, han surgido estándares y marcos
arquitectónicos para abordar el desafío de diseñar redes de IoT a gran
escala.
El concepto fundamental en todas estas arquitecturas es el soporte de
datos, procesos y las funciones que realizan los dispositivos de punto
final. Dos de las arquitecturas más conocidas son las compatibles con
oneM2M y el IoT World Forum (IoTWF), que se analizan en las
siguientes secciones.

La arquitectura estandarizada oneM2M IoT

En un esfuerzo por estandarizar el campo de rápido crecimiento de las
comunicaciones de máquina a máquina (M2M), el Instituto Europeo de
Estándares de Telecomunicaciones (ETSI) creó el Comité Técnico de
M2M en 2008. El objetivo de este comité era crear una arquitectura
común que ayudaría acelerar la adopción de aplicaciones y dispositivos
M2M.Con el tiempo, el alcance se ha ampliado para incluir el Internet
de las cosas.
Otros organismos relacionados también comenzaron a crear
arquitecturas M2M similares, y se hizo necesario un estándar común
para M2M. Reconociendo esta necesidad, en 2012 ETSI y otros 13
miembros fundadores lanzaron oneM2M como una iniciativa global
diseñada para promover sistemas eficientes de comunicación M2M e
IoT. El objetivo de oneM2M es crear una capa de servicios común, que
pueda integrarse fácilmente en dispositivos de campo para permitir la
comunicación con los servidores de aplicaciones. El marco de
1

oneM2M se centra en servicios, aplicaciones y plataformas de IoT. Estos

incluyen aplicaciones de medición inteligente, red inteligente,
automatización de ciudad inteligente, e-health y vehículos conectados.
Uno de los mayores desafíos al diseñar una arquitectura de IoT es lidiar
con la heterogeneidad de dispositivos, software y métodos de acceso. Al
desarrollar una arquitectura de plataforma horizontal, oneM2M está
desarrollando estándares que permiten la interoperabilidad en todos los
niveles de la pila de IoT. Por ejemplo, es posible que desee automatizar
su sistema HVAC conectándolo con sensores inalámbricos de
temperatura repartidos por toda su oficina. Usted decide implementar
sensores que usan la tecnología LoRaWAN (discutido en Capítulo 4 ,
"Conexión de objetos inteligentes "). El problema es que la red
LoRaWAN y el sistema BACnet en el que se ejecutan su HVAC y BMS
son sistemas completamente diferentes y no tienen un punto de
conexión natural. Aquí es donde entra en juego la arquitectura de
servicios comunes de oneM2M. El marco horizontal de oneM2M y las
API RESTful permiten que el sistema LoRaWAN interactúe con el
sistema de administración de edificios a través de una red IoT,
promoviendo así las comunicaciones de IoT de manera constante, sin
importar cómo heterogéneas las redes.
La arquitectura oneM2M divide las funciones de IoT en tres dominios
principales: la capa de aplicación, la capa de servicios y la capa de red. Si
bien esta arquitectura puede parecer simple y algo genérica a primera
vista, es muy rica y promueve la interoperabilidad a través de API aptas
para TI y es compatible con una amplia gama de tecnologías
IoT. Examinemos cada uno de estos dominios a su vez:
Capa de aplicaciones: La arquitectura oneM2M le presta mayor
atención a la conectividad entre los dispositivos y sus aplicaciones. Este
dominio incluye los protocolos de la capa de aplicación e intenta
estandarizar las definiciones de la API hacia el norte para la interacción
con los sistemas de inteligencia empresarial (BI). Las aplicaciones
tienden a ser específicas de la industria y tienen sus propios conjuntos
de modelos de datos, por lo que se muestran como entidades verticales.
Capa de servicios: Esta capa se muestra como un marco horizontal
en las aplicaciones industriales verticales. En esta capa, los módulos
horizontales incluyen la red física en la que se ejecutan las aplicaciones
de IoT, los protocolos de administración subyacentes y el hardware. Los
ejemplos incluyen comunicaciones de retroceso por celular, redes MPLS,
VPN, etc. Montar en la parte superior es la capa de servicios
comunes. Esta capa conceptual agrega API y middleware que soportan
servicios y aplicaciones de terceros. Uno de los objetivos declarados de
oneM2M es "desarrollar especificaciones técnicas que aborden la
necesidad de una capa de servicio M2M común que pueda integrarse
fácilmente en varios nodos de hardware y software, y confiar en la
conexión de la gran cantidad de dispositivos en la red de área de campo
a M2M servidores de aplicaciones, que normalmente residen en una
nube o centro de datos. "Un objetivo fundamental de oneM2M es atraer
e involucrar activamente a organizaciones de dominios comerciales
relacionados con M2M, incluyendo telemática y transporte inteligente,
atención médica, servicios públicos, automatización industrial y
aplicaciones de hogares inteligentes , por nombrar unos cuantos. 2

Capa de red: Este es el dominio de comunicación para los

dispositivos y puntos finales de IoT. Incluye los dispositivos en sí y la red
de comunicaciones que los vincula. Las formas de realización de esta
infraestructura de comunicaciones incluyen tecnologías de malla
inalámbrica, como IEEE 802.15.4, y sistemas inalámbricos de punto a
multipunto, como IEEE 801.11ah. También se incluyen las conexiones
de dispositivos cableados, como las comunicaciones de la línea de
alimentación IEEE 1901. Capítulo 4 proporciona más detalles sobre
estas tecnologías de conectividad.
En muchos casos, los dispositivos inteligentes (ya veces no tan
inteligentes) se comunican entre sí. En otros casos, la comunicación
máquina a máquina no es necesaria, y los dispositivos simplemente se
comunican a través de una red de área de campo (FAN) para usar
aplicaciones específicas de casos en el dominio de la aplicación IoT. Por
lo tanto, el dominio del dispositivo también incluye el dispositivo de
puerta de enlace, que proporciona comunicaciones en la red central y
actúa como un punto de demarcación entre el dispositivo y los dominios
de red.
Las especificaciones técnicas y los informes técnicos publicados por
oneM2M que cubren la arquitectura funcional de IoT y otros aspectos se
pueden encontrar en www.onem2m.org .

La arquitectura estandarizada del Foro Mundial de la IO

(IoTWF)
En 2014, el comité de arquitectura de IoTWF (dirigido por Cisco, IBM,
Rockwell Automation y otros) publicó un modelo de referencia de
arquitectura IoT de siete capas. Si bien existen varios modelos de
referencia IoT, el presentado por IoT World Forum ofrece una
perspectiva limpia y simplificada sobre IoT e incluye informática de
punta, almacenamiento de datos y acceso. Proporciona una forma
concisa de visualizar IoT desde una perspectiva técnica. Cada una de las
siete capas se divide en funciones específicas, y la seguridad abarca todo
el modelo. Figura 2-2 detalla el modelo de referencia IoT publicado por
el IoTWF.
Como se muestra en La figura 2-2 , el modelo de referencia IoT define
un conjunto de niveles con control que fluye desde el centro (esto podría
ser un servicio en la nube o un centro de datos dedicado), hasta el borde,
que incluye sensores, dispositivos, máquinas y otros tipos de nodos
finales inteligentes En general, los datos viajan por la pila, se originan
desde el borde y van hacia el norte hacia el centro. Usando este modelo
de referencia, podemos lograr lo siguiente:
Descompón el problema de IoT en partes más pequeñas
Identificar las diferentes tecnologías en cada capa y cómo se
relacionan entre sí
Definir un sistema en el que diferentes proveedores puedan
proporcionar diferentes partes
Tener un proceso de definición de interfaces que conduzca a la
interoperabilidad
Definir un modelo de seguridad escalonado que se aplique en los
puntos de transición entre niveles
Las siguientes secciones miran más de cerca cada una de las siete capas
del Modelo de referencia IoT.

Capa 1: Dispositivos físicos y capa de controladores

La primera capa del Modelo de referencia IoT es la capa de dispositivos
físicos y controladores. Esta capa es el hogar de las "cosas" en el Internet
de las cosas, incluidos los diversos dispositivos terminales y sensores que
envían y reciben información. El tamaño de estas "cosas" puede variar
desde sensores casi microscópicos hasta máquinas gigantes en una
fábrica. Su función principal es generar datos y poder ser consultados y
/ o controlados a través de una red.

Capa 2: Capa de conectividad

En la segunda capa del Modelo de referencia IoT, el foco está en la
conectividad. La función más importante de esta capa de IoT es la
transmisión de datos confiable y oportuna. Más específicamente, esto
incluye transmisiones entre dispositivos de Capa 1 y la red y entre la red
y el procesamiento de información que ocurre en la Capa 3 (la capa de
computación de borde).
Como puede observar, la capa de conectividad abarca todos los
elementos de red de IoT y realmente no distingue entre la red de última
milla (la red entre el sensor / punto final y la puerta de enlace IoT, que
se tratará más adelante en este capítulo), puerta de enlace y backhaul
redes. Las funciones de la capa de conectividad se detallan en Figura 2-
3.

Capa 3: capa de computación Edge

La informática de borde es la función de la Capa 3. La informática de
borde a menudo se denomina capa de "niebla" y se trata en la sección
" Computación de niebla ", más adelante en este capítulo. En esta capa,
se hace hincapié en la reducción de datos y la conversión de flujos de
datos de red en información que está lista para el almacenamiento y
procesamiento por capas superiores. Uno de los principios básicos de
este modelo de referencia es que el procesamiento de la información se
inicia lo antes posible y lo más cerca posible del borde de la red. La
Figura 2-4 resalta las funciones manejadas por la Capa 3 del Modelo de
referencia IoT.
Otra función importante que se produce en la Capa 3 es la evaluación de
los datos para ver si se puede filtrar o agregar antes de enviarlos a una
capa superior. Esto también permite que los datos sean reformateados o
decodificados, facilitando el procesamiento adicional por otros
sistemas. Por lo tanto, una función crítica es evaluar los datos para ver
si se cruzan los umbrales predefinidos y si es necesario enviar cualquier
acción o alerta.

Capas superiores: capas 4-7

Las capas superiores se ocupan de la manipulación y el procesamiento
de los datos de IoT generados por la capa inferior. En aras de la
exhaustividad, las capas 4-7 del modelo de referencia IoT se resumen
en Tabla 2-2 Tabla 2-2 Resumen de las capas 4 a 7 del modelo de referencia
IoTWF
Otra función importante que se produce en la Capa 3 es la evaluación de
los datos para ver si se puede filtrar o agregar antes de enviarlos a una
capa superior. Esto también permite que los datos sean reformateados o
decodificados, facilitando el procesamiento adicional por otros
sistemas. Por lo tanto, una función crítica es evaluar los datos para ver
si se cruzan los umbrales predefinidos y si es necesario enviar cualquier
acción o alerta.

Capas superiores: capas 4-7

Las capas superiores se ocupan de la manipulación y el procesamiento
de los datos de IoT generados por la capa inferior. En aras de la
exhaustividad, las capas 4-7 del modelo de referencia IoT se resumen en
la tabla 2-2.

Imagen
Tabla 2-2 Resumen de las capas 4-7 del modelo de referencia IoTWF

Responsabilidades de TI y OT en el modelo de referencia IoT

Un aspecto interesante de visualizar una arquitectura de IoT de esta
manera es que puede comenzar a organizar responsabilidades a lo largo
de las líneas de TI y OT. La figura 2-5 ilustra un punto de demarcación
natural entre IT y OT en el marco del modelo de referencia IoT.

Responsabilidades de TI y OT en el modelo de referencia IoT

Un aspecto interesante de visualizar una arquitectura de IoT de esta
manera es que puede comenzar a organizar responsabilidades a lo largo
de las líneas de TI y OT. La figura 2-5ilustra un punto de demarcación
natural entre IT y OT en el marco del modelo de referencia IoT.
Como se muestra en la Figura 2-5 , los sistemas de IoT tienen que cruzar
varios límites más allá de las capas funcionales. La parte inferior de la
pila generalmente está en el dominio de OT. Para una industria como el
petróleo y el gas, esto incluye sensores y dispositivos conectados a
tuberías, plataformas petrolíferas, maquinaria de refinería, etc. La parte
superior de la pila está en el área de TI e incluye cosas como servidores,
bases de datos y aplicaciones, todas las cuales se ejecutan en una parte
de la red controlada por TI. En el pasado, OT e IT generalmente eran
muy independientes y tenían poca necesidad de hablar entre ellos. IoT
está cambiando ese paradigma.
En la parte inferior, en las capas OT, los dispositivos generan datos en
tiempo real a su propia velocidad, a veces grandes cantidades a
diario. Esto no solo da como resultado una gran cantidad de datos que
transitan por la red IoT, sino que el gran volumen de datos sugiere que
las aplicaciones en la capa superior podrán ingerir esa cantidad de datos
a la velocidad requerida. Para cumplir con este requisito, los datos deben
almacenarse en búfer o almacenarse en ciertos puntos dentro de la pila
de IoT. La gestión de datos en capas de esta manera en toda la pila ayuda
a las cuatro capas superiores a manejar los datos a su propia velocidad.
Como resultado, los "datos en movimiento" en tiempo real cerca del
borde deben organizarse y almacenarse para que se conviertan en "datos
en reposo" para las aplicaciones en los niveles de TI. Las organizaciones
de TI y OT necesitan trabajar juntas para la administración general de
datos.

Modelos de referencia de IoT adicionales

Además de los dos modelos de referencia de IoT ya presentados en este
capítulo, existen otros modelos de referencia. Estos modelos están
respaldados por varias organizaciones y organismos de normalización y,
a menudo, son específicos de ciertas industrias o aplicaciones de IoT. La
Tabla 2-3 destaca estos modelos adicionales de referencia de IoT.
Como se muestra en la Figura 2-5, los sistemas de IoT tienen que cruzar
varios límites más allá de las capas funcionales. La parte inferior de la pila
generalmente está en el dominio de OT. Para una industria como el
petróleo y el gas, esto incluye sensores y dispositivos conectados a
tuberías, plataformas petrolíferas, maquinaria de refinería, etc. La parte
superior de la pila está en el área de TI e incluye cosas como servidores,
bases de datos y aplicaciones, todas las cuales se ejecutan en una parte de
la red controlada por TI. En el pasado, OT e IT generalmente eran muy
independientes y tenían poca necesidad de hablar entre ellos. IoT está
cambiando ese paradigma.

En la parte inferior, en las capas OT, los dispositivos generan datos en

tiempo real a su propia velocidad, a veces grandes cantidades a diario. Esto
no solo da como resultado una gran cantidad de datos que transitan por la
red IoT, sino que el gran volumen de datos sugiere que las aplicaciones en
la capa superior podrán ingerir esa cantidad de datos a la velocidad
requerida. Para cumplir con este requisito, los datos deben almacenarse en
búfer o almacenarse en ciertos puntos dentro de la pila de IoT. La gestión
de datos en capas de esta manera en toda la pila ayuda a las cuatro capas
superiores a manejar los datos a su propia velocidad.

Como resultado, los "datos en movimiento" en tiempo real cerca del borde
deben organizarse y almacenarse para que se conviertan en "datos en
reposo" para las aplicaciones en los niveles de TI. Las organizaciones de TI
y OT necesitan trabajar juntas para la administración general de datos.

Modelos de referencia de IoT adicionales

Además de los dos modelos de referencia IoT ya presentados en este
capítulo, existen otros modelos de referencia. Estos modelos están
respaldados por varias organizaciones y organismos de normalización y, a
menudo, son específicos de ciertas industrias o aplicaciones de IoT. La
Tabla 2-3 destaca estos modelos adicionales de referencia de IoT.

Imagen
Tabla 2-3 Modelos alternativos de referencia de IoT

UNA ARQUITECTURA IOT SIMPLIFICADA

Aunque existen diferencias considerables entre los modelos de referencia
antes mencionados, cada uno aborda el IoT desde una perspectiva en
capas, lo que permite el desarrollo de tecnología y estándares de forma
independiente en cada nivel o dominio. La característica común entre estos
marcos es que todos reconocen la interconexión de los dispositivos de
punto final de IoT a una red que transporta los datos donde las aplicaciones
los utilizan, ya sea en el centro de datos, en la nube o en varios puntos de
administración en toda la pila .

No es la intención de este libro promover o respaldar un marco

arquitectónico de IoT específico. De hecho, se puede observar que las
arquitecturas de IoT pueden diferir en cierta medida según el caso de uso
de la industria o la tecnología que se implemente, y cada una de ellas tiene
mérito para resolver el problema de heterogeneidad de IoT discutido
anteriormente. Por lo tanto, en este libro presentamos un marco de IoT que
destaca los componentes fundamentales que son comunes a la mayoría de
los sistemas de IoT y que está destinado a ayudarlo a diseñar una red de
IoT. Este marco se presenta como dos pilas paralelas: la gestión de datos
de Io y la pila de cálculo y la pila funcional Core IoT. Reducir el marco a un
par de pilas de tres capas de ninguna manera sugiere que el modelo carece
de los detalles necesarios para desarrollar una estrategia sofisticada de
IoT. Más bien,la intención es simplificar la arquitectura de IoT en sus
bloques de construcción más básicos y luego usarla como base para
comprender los principios clave de diseño e implementación que se aplican
a casos de uso específicos de la industria. Todas las capas de modelos más
complejos todavía están cubiertas, pero se agrupan aquí en bloques
funcionales que son fáciles de entender. La Figura 2-6 ilustra el modelo de
IoT simplificado presentado en este libro.
Tabla 2-3 Modelos alternativos de referencia de IoT

UNA ARQUITECTURA IOT SIMPLIFICADA

Aunque existen diferencias considerables entre los modelos de
referencia antes mencionados, cada uno aborda el IoT desde una
perspectiva en capas, lo que permite el desarrollo de tecnología y
estándares de forma independiente en cada nivel o dominio. La
característica común entre estos marcos es que todos reconocen la
interconexión de los dispositivos de punto final de IoT a una red que
transporta los datos donde las aplicaciones los utilizan, ya sea en el
centro de datos, en la nube o en varios puntos de administración en toda
la pila .
No es la intención de este libro promover o respaldar un marco
arquitectónico de IoT específico. De hecho, se puede observar que las
arquitecturas de IoT pueden diferir en cierta medida según el caso de
uso de la industria o la tecnología que se implemente, y cada una de ellas
tiene mérito para resolver el problema de heterogeneidad de IoT
discutido anteriormente. Por lo tanto, en este libro presentamos un
marco de IoT que destaca los componentes fundamentales que son
comunes a la mayoría de los sistemas de IoT y que está destinado a
ayudarlo a diseñar una red de IoT. Este marco se presenta como dos pilas
paralelas: la gestión de datos de Io y la pila de cálculo y la pila funcional
Core IoT. Reducir el marco a un par de pilas de tres capas de ninguna
manera sugiere que el modelo carece de los detalles necesarios para
desarrollar una estrategia sofisticada de IoT. Más bien,la intención es
simplificar la arquitectura de IoT en sus bloques de construcción más
básicos y luego usarla como base para comprender los principios clave
de diseño e implementación que se aplican a casos de uso específicos de
la industria. Todas las capas de modelos más complejos todavía están
cubiertas, pero se agrupan aquí en bloques funcionales que son fáciles
de entender. La Figura 2-6 ilustra el modelo de IoT simplificado
presentado en este libro.

Casi todos los modelos de IoT publicados incluyen capas centrales

similares a las que se muestran en el lado izquierdo de la Figura 2-6 , que
incluyen "cosas", una red de comunicaciones y aplicaciones. Sin
embargo, a diferencia de otros modelos, el marco presentado aquí separa
el IoT central y la administración de datos en pilas paralelas y alineadas,
lo que le permite examinar cuidadosamente las funciones de la red y las
aplicaciones en cada etapa de un complejo sistema de IoT. Esta
separación le brinda una mejor visibilidad de las funciones de cada capa.
La presentación de la pila funcional Core IoT en tres capas pretende
simplificar su comprensión de la arquitectura IoT en sus componentes
más fundamentales. Por supuesto, una arquitectura tan simple necesita
expandirse. La capa de comunicaciones de red de la pila de IoT en sí
implica una gran cantidad de detalles e incorpora una amplia gama de
tecnologías. Considere por un momento la heterogeneidad de los
sensores de IoT y las muchas formas diferentes que existen para
conectarlos a una red. La capa de comunicaciones de red necesita
consolidarlas juntas, ofrecer tecnologías de puerta de enlace y backhaul,
y finalmente llevar los datos a una ubicación central para su análisis y
procesamiento.
Muchas de las tecnologías de última milla utilizadas en IoT se eligen para
cumplir los requisitos específicos de los puntos finales y es poco probable
que se vean en el dominio de TI. Sin embargo, la red entre la puerta de
enlace y el centro de datos se compone principalmente de tecnologías
tradicionales que los profesionales de TI con experiencia reconocerían
rápidamente. Estos incluyen tecnologías de túnel y VPN, calidad de
servicio basada en IP (QoS), protocolos de enrutamiento convencionales
Layer 3 como BGP e IP-PIM, y capacidades de seguridad tales como
encriptación, listas de control de acceso (ACL) y firewalls.
A diferencia de la mayoría de las redes de TI, la capa de aplicaciones y
análisis de IoT no existe necesariamente solo en el centro de datos o en
la nube. Debido a los desafíos y requisitos únicos de IoT, a menudo es
necesario implementar aplicaciones y administración de datos en toda
la arquitectura en un enfoque por niveles, lo que permite la recopilación
de datos, el análisis y los controles inteligentes en varios puntos del
sistema IoT. En el modelo presentado en este libro, la administración de
datos se alinea con cada una de las tres capas de la Pila funcional Core
IoT. Las tres capas de gestión de datos son la capa límite (gestión de
datos dentro de los sensores), la capa de niebla (gestión de datos en las
puertas de enlace y la red de tránsito) y la capa de nubes (gestión de
datos en la nube o centro de datos central).La gestión de datos de IoT y
la pila de cálculo se examinan con mayor detalle más adelante en este
capítulo. La Figura 2-7 resalta una vista ampliada de la arquitectura IoT
presentada en este libro.
Figura 2-7 Vista ampliada de la arquitectura IoT simplificada
Como se muestra en La Figura 2-7 , la pila funcional Core IoT se puede
expandir en subcapas que contienen mayores detalles y funciones de red
específicas. Por ejemplo, la capa de comunicaciones se divide en cuatro
subcapas separadas: la red de acceso, las puertas de enlace y la red de
retorno, el transporte de IP y las subcapas de operaciones y
administración.
La capa de aplicaciones de las redes IoT es bastante diferente de la capa
de aplicaciones de una red empresarial típica. En lugar de simplemente
usar aplicaciones comerciales, IoT a menudo implica un fuerte
componente de análisis de datos grandes. Un mensaje que se destaca a
lo largo de este libro es que IoT no se trata solo del control de los
dispositivos IoT sino, más bien, de los conocimientos útiles obtenidos de
los datos generados por esos dispositivos. Por lo tanto, la capa de
aplicaciones generalmente tiene analíticos y componentes del sistema de
control de IoT específicos de la industria.
Desde un punto de vista arquitectónico, los nodos de niebla más
cercanos al borde de la red reciben los datos de los dispositivos IoT. La
aplicación IoT de niebla luego dirige diferentes tipos de datos al lugar
óptimo para el análisis:

Imagen La mayoría de los datos sensibles al tiempo se analizan en el

borde o en el nodo de niebla más cercano a las cosas que generan los
datos.

Imagen Los datos que pueden esperar segundos o minutos para la acción
se transfieren a un nodo de agregación para su análisis y acción.

Image Los datos que son menos sensibles al tiempo se envían a la nube
para análisis históricos, análisis de big data y almacenamiento a largo
plazo. Por ejemplo, cada uno de los miles o cientos de miles de nodos de
niebla puede enviar resúmenes periódicos de datos a la nube para su
análisis y almacenamiento histórico.
En resumen, al diseñar una red IoT, debe considerar la cantidad de datos
que se analizarán y la sensibilidad temporal de estos datos. Comprender
estos factores lo ayudará a decidir si la computación en la nube es
suficiente o si la computación de borde o niebla mejorará la eficiencia de
su sistema. La computación de niebla acelera el conocimiento y la
respuesta a los eventos al eliminar un viaje de ida y vuelta a la nube para
su análisis. Evita la necesidad de costosas adiciones de ancho de banda
mediante la descarga de gigabytes de tráfico de red desde la red central.
También protege los datos confidenciales de IoT analizándolo dentro de
las paredes de la empresa.

RESUMEN
Los requisitos de los sistemas IoT están impulsando nuevas
arquitecturas que abordan los aspectos de escala, restricciones y gestión
de datos de IoT. Para abordar estas necesidades, han surgido varios
modelos de referencia específicos de IoT, incluidos el modelo oneM2M
IoT y el modelo de referencia IoT del IoT World Forum. Las
características comunes entre estos modelos son la interacción de los
dispositivos IoT, la red que los conecta y las aplicaciones que
administran los puntos finales.

Este libro presenta un marco de IoT que utiliza aspectos de estos

diversos modelos y los aplica a casos de uso específicos de la
industria. Este capítulo presenta un modelo basado en conceptos
comunes en estas arquitecturas que rompe las capas de IoT en una
arquitectura simplificada que incorpora dos pilas paralelas: la Pila
funcional Core IoT y la Gestión de datos IoT y la Pila informática. Esta
arquitectura establece el formato para los capítulos que siguen en este
libro.

La pila funcional Core IoT tiene tres capas: los sensores y actuadores IoT,
componentes de red y aplicaciones y capas de análisis. Los componentes
de red y las capas de aplicaciones implican varias subcapas que
corresponden a diferentes partes del sistema de IoT en general.

El IoT Data Management y Compute Stack se ocupa de cómo y dónde se

filtran, agregan, almacenan y analizan los datos. En los modelos de TI
tradicionales, esto ocurre en la nube o en el centro de datos. Sin
embargo, debido a los requisitos únicos de IoT, la administración de
datos se distribuye lo más cerca posible del borde, incluidas las capas de
borde y niebla.
Notará que la seguridad es central en toda la arquitectura, tanto desde
la conectividad de la red como desde las perspectivas de administración
de datos. Los capítulos de la Parte II , " Redes de IoT de ingeniería ",
discuten la seguridad en cada capa. El Capítulo 8 está dedicado al tema
de asegurar los sistemas de IoT. Los capítulos de la industria en la Parte
III , " IoT en la industria ", destacan cómo las lecciones aprendidas en
la Parte I , " Introducción a la IO " y II pueden aplicarse a industrias
específicas. Cada una de las Los capítulos de la Parte
III examinan la cuestión de la seguridad de la IO para un sector en
particular.
El marco arquitectónico presentado en la Figura 2-7 refleja el flujo de los
capítulos de este libro. Para ayudar a navegar a través de este libro, los
números de los capítulos se resaltan al lado de las diversas capas de la
pila.
El resto de este capítulo proporciona un examen de alto nivel de cada
capa de este modelo y sienta las bases para un examen detallado de las
tecnologías involucradas en cada capa presentada en la Parte II , y le
brinda las herramientas que necesita para comprender cómo estas
tecnologías se aplican en industrias clave en la Parte III .

LA PILA FUNCIONAL PRINCIPAL IOT

Las redes IoT se basan en el concepto de "cosas" u objetos inteligentes
que realizan funciones y entregan nuevos servicios conectados. Estos
objetos son "inteligentes" porque usan una combinación de información
contextual y objetivos configurados para realizar acciones. Estas
acciones pueden ser autónomas (es decir, el objeto inteligente no
depende de sistemas externos para sus acciones); sin embargo, en la
mayoría de los casos, la "cosa" interactúa con un sistema externo para
informar la información que el objeto inteligente recopila, para
intercambiar con otros objetos o para interactuar con una plataforma de
gestión. En este caso, la plataforma de gestión puede utilizarse para
procesar datos recopilados del objeto inteligente y también para guiar el
comportamiento del objeto inteligente. Desde el punto de vista
arquitectónico, varios componentes deben trabajar juntos para que una
red IoT sea operativa:
 Capa de "cosas": en esta capa, los dispositivos físicos deben
ajustarse a las limitaciones del entorno en el que se implementan y, al
mismo tiempo, proporcionar la información necesaria.
Capa de red de comunicaciones: cuando los objetos inteligentes
no son autónomos, necesitan comunicarse con un sistema externo. En
muchos casos, esta comunicación utiliza una tecnología
inalámbrica. Esta capa tiene cuatro subcapas:
Subcapa de acceso a la red: la última milla de la red IoT es la red
de acceso. Esto generalmente se compone de tecnologías inalámbricas
como 802.11ah, 802.15.4g y LoRa. Los sensores conectados a la red de
acceso también pueden estar cableados.
Subcapa de puerta de enlace y backhaul: un sistema de
comunicación común organiza múltiples objetos inteligentes en un área
determinada alrededor de una puerta de enlace común. La puerta de
enlace se comunica directamente con los objetos inteligentes. La función
de la puerta de enlace es reenviar la información recopilada a través de
un medio de rango más largo (llamado backhaul) a una estación central
de la cabecera donde se procesa la información. Este intercambio de
información es una función de Capa 7 (aplicación), que es la razón por la
cual a este objeto se lo llama una puerta de enlace. En redes IP, esta
puerta de enlace también reenvía paquetes de una red IP a otra y, por lo
tanto, actúa como un enrutador.
Subcapa de transporte de red: para que la comunicación sea
exitosa, los protocolos de red y de capa de transporte como IP y UDP
deben implementarse para admitir la variedad de dispositivos a conectar
y los medios a usar.
Subcapa de administración de red de IoT: deben existir
protocolos adicionales para permitir que las aplicaciones de cabecera
intercambien datos con los sensores. Los ejemplos incluyen CoAP y
MQTT.
Capa de aplicación y análisis: en la capa superior, una aplicación
necesita procesar los datos recopilados, no solo para controlar los
objetos inteligentes cuando sea necesario, sino para tomar decisiones
inteligentes basadas en la información recopilada y, a su vez, instruir las
"cosas" o otros sistemas para adaptarse a las condiciones analizadas y
cambiar sus comportamientos o parámetros.
Las siguientes secciones examinan estos elementos y lo ayudan a diseñar
su red de comunicación IoT.
Capa 1: Cosas: Capa de sensores y actuadores
La mayoría de las redes IoT comienzan desde el objeto, o "cosa", que
debe estar conectado. El Capítulo 3 , " Objetos inteligentes: las 'Cosas' en
IoT ," proporciona información más detallada sobre objetos
inteligentes. Desde un punto de vista arquitectónico, la variedad de tipos
de objetos inteligentes, formas y necesidades manejan la variedad de
protocolos y arquitecturas IoT. Hay innumerables formas de clasificar
objetos inteligentes. Una clasificación arquitectónica podría ser:
Con o sin batería: esta clasificación se basa en si el objeto lleva su
propio suministro de energía o si recibe energía continua de una fuente
de alimentación externa. Las cosas que funcionan con batería se pueden
mover más fácilmente que los objetos alimentados por línea. Sin
embargo, las baterías limitan la vida útil y la cantidad de energía que el
objeto puede consumir, lo que impulsa el rango de transmisión y la
frecuencia.
Móvil o estático: esta clasificación se basa en si la "cosa" debería
moverse o permanecer siempre en el mismo lugar. Un sensor puede ser
móvil porque se mueve de un objeto a otro (por ejemplo, un sensor de
viscosidad movido de un lote a otro en una planta química) o porque está
unido a un objeto en movimiento (por ejemplo, un sensor de ubicación
en bienes en movimiento) en un almacén o piso de fábrica). La
frecuencia del movimiento también puede variar, de ocasional a
permanente. El rango de movilidad (desde unos pocos centímetros hasta
millas de distancia) a menudo impulsa la posible fuente de energía.
Frecuencia de informes baja o alta: esta clasificación se basa en
la frecuencia con la que el objeto debe informar los parámetros
monitoreados. Un sensor de óxido puede informar los valores una vez al
mes. Un sensor de movimiento puede informar la aceleración varios
cientos de veces por segundo. Las frecuencias más altas generan un
mayor consumo de energía, lo que puede crear restricciones en la posible
fuente de alimentación (y, por lo tanto, en la movilidad del objeto) y el
alcance de la transmisión.
Datos simples o ricos: esta clasificación se basa en la cantidad de
datos intercambiados en cada ciclo de informe. Un sensor de humedad
en un campo puede informar un valor de índice diario simple (en una
escala binaria de 0 a 255), mientras que un sensor de motor puede
informar cientos de parámetros, de temperatura a presión, velocidad del
gas, velocidad de compresión, índice de carbono y muchos otros. Los
datos más ricos generalmente generan un mayor consumo de energía.
Esta clasificación a menudo se combina con la anterior para determinar
el rendimiento de datos del objeto (bajo rendimiento a alto
rendimiento). Es posible que desee tener en cuenta que el rendimiento
es una medida combinada. Un objeto de mediano rendimiento puede
enviar datos simples a una frecuencia bastante alta (en cuyo caso la
estructura de flujo parece continua), o puede enviar datos enriquecidos
a una frecuencia bastante baja (en cuyo caso la estructura de flujo se ve
con ráfagas).
Rango de informes: esta clasificación se basa en la distancia a la
que se encuentra la puerta de enlace. Por ejemplo, para que su banda de
ejercicios se comunique con su teléfono, debe ubicarse a unos pocos
metros como máximo. La suposición es que su teléfono debe estar a una
distancia visual para que pueda consultar los datos informados en la
pantalla del teléfono. Si el teléfono está lejos, normalmente no lo usa y
no es necesario informar los datos de la banda al teléfono. Por el
contrario, un sensor de humedad en el asfalto de una carretera puede
necesitar comunicarse con su lector a varios cientos de metros o incluso
kilómetros de distancia.
Densidad del objeto por celda: esta clasificación se basa en la
cantidad de objetos inteligentes (con una necesidad similar de
comunicarse) en un área determinada, conectados a la misma puerta de
enlace. Un oleoducto puede utilizar un solo sensor en ubicaciones clave
cada pocas millas. Por el contrario, telescopios como el telescopio SETI
Colossus en el Observatorio Whipple despliegan cientos, ya veces miles,
de espejos sobre un área pequeña, cada uno con múltiples giroscopios,
gravedad y sensores de vibración.
Desde el punto de vista arquitectónico de la red, su tarea inicial es
determinar qué tecnología se debe usar para permitir que los objetos
inteligentes se comuniquen. Esta determinación depende de la forma en
que se clasifican las "cosas". Sin embargo, algunas industrias (como la
fabricación y las utilidades) pueden incluir objetos en diversas
categorías, que coincidan con las diferentes necesidades. La Figura 2-
8 proporciona algunos ejemplos de aplicaciones que coinciden con la
combinación de requisitos de movilidad y rendimiento.
Las categorías utilizadas para clasificar cosas pueden influir en otros
parámetros y también pueden influir entre sí. Por ejemplo, un objeto
altamente móvil que funciona con batería (como un monitor de ritmo
cardíaco, por ejemplo) probablemente tenga un factor de forma
pequeño. Un sensor pequeño es más fácil de mover o integrar en su
entorno. Al mismo tiempo, es poco probable que un objeto inteligente
pequeño y altamente móvil requiera una antena grande y una poderosa
fuente de alimentación. Esta restricción limitará el rango de transmisión
y, por lo tanto, el tipo de protocolo de red disponible para sus
conexiones. La criticidad de los datos también puede influir en el factor
de forma y, por lo tanto, en la arquitectura. por ejemplo, un informe
mensual faltante de un sensor de humedad de asfalto simplemente
puede marcar un indicador de reemplazo del sensor (o batería). Un
informe de giroscopio de varios espejos faltante durante más de 100 ms
puede hacer que todo el sistema sea inestable o inutilizable. Estos
sensores deben tener una fuente de energía constante (lo que da como
resultado una movilidad limitada) o deben ser fácilmente accesibles para
el reemplazo de la batería (lo que da como resultado un rango de
transmisión limitado). Un primer paso en el diseño de una red IoT es
examinar los requisitos en términos de movilidad y transmisión de datos
(cuántos datos, con qué frecuencia).

Capa 2: capa de red de comunicaciones

Una vez que ha determinado la influencia del factor de forma del objeto
inteligente sobre sus capacidades de transmisión (rango de transmisión,
volumen y frecuencia de datos, densidad del sensor y movilidad), está
listo para conectar el objeto y comunicarse.
Los recursos informáticos y de red utilizados en IoT pueden ser muy
diferentes a los de los entornos de TI. La diferencia en los factores de
forma física entre los dispositivos utilizados por IT y OT es obvia incluso
para los observadores más casuales. Lo que generalmente impulsa esto
es el entorno físico en el que se implementan los dispositivos. Lo que
puede no ser tan intrínsecamente obvio, sin embargo, son sus
diferencias operativas. Las diferencias operacionales deben entenderse
para aplicar el manejo correcto para asegurar los activos objetivo.
Las variaciones de temperatura son una medida fácilmente
comprensible. La causa de la variación se atribuye fácilmente a las
fuerzas meteorológicas externas y las condiciones internas de operación.
Las ubicaciones remotas externas, como las asociadas con la extracción
de minerales o los equipos de tuberías, pueden abarcar desde el calor del
Golfo Arábigo hasta el frío de la Vertiente Norte de Alaska. Los controles
cerca de los hornos de una acería obviamente requieren tolerancia al
calor, y los controles para el almacenamiento de alimentos fríos
requieren lo contrario. En algunos casos, estos controles también deben
manejar fluctuaciones extremas. Estos extremos se pueden ver en una
sola implementación. Por ejemplo, porciones de los parques eólicos de
Tehachapi, California se encuentran en el desierto de Mojave, mientras
que otros se encuentran a una altitud de 1800 m en las montañas
circundantes. Como puedes imaginar,la amplia variación en la
temperatura requiere una pieza especial de hardware que es capaz de
resistir entornos tan hostiles.
Las fluctuaciones de humedad también pueden afectar el éxito a largo
plazo de un sistema. Las cabezas de pozo que residen en el delta del río
Níger verán condiciones muy diferentes de las que se encuentran en el
medio del desierto de Arabia. En algunas condiciones, los sistemas
podrían estar expuestos al contacto directo con líquidos, como los que se
pueden encontrar con los dispositivos inalámbricos externos o las
implementaciones de condiciones marinas.
Menos obvios son los extremos operativos relacionados con las fuerzas
cinéticas. Las necesidades de choque y vibración varían según el
escenario de implementación. En algunos casos, la atención se centra en
la baja amplitud pero las vibraciones constantes, como se puede esperar
en un sistema de fabricación montado en bujes. En otros casos, podría
ser una aceleración o desaceleración repentina, como la que se puede
experimentar en la aceleración máxima del terreno de un terremoto o un
impacto en un sistema móvil como el tren de alta velocidad o el equipo
de movimiento de tierras de servicio pesado.
Las partículas sólidas también pueden afectar el engranaje. La mayoría
de los entornos de TI deben lidiar con la acumulación de polvo que puede
llegar a ser muy concentrada debido al efecto de los ventiladores de
refrigeración. En entornos de TI menos controlados, ese fenómeno
puede acelerarse debido a concentraciones más altas de partículas. Un
impedimento para la acumulación de partículas es el uso de
refrigeración sin ventilador, que necesita una mayor área de superficie,
como es el caso de las aletas de transferencia de calor.
El diseño de ubicación peligrosa también puede causar un impacto
corrosivo en el equipo. Los materiales cáusticos pueden afectar las
conexiones sobre las cuales viajan la energía o las
comunicaciones. Además, pueden dar como resultado una eficiencia
térmica reducida al revestir potencialmente las superficies de
transferencia de calor.
En algunos escenarios, la preocupación no es cómo el medio ambiente
puede afectar el equipo, sino cómo el equipo puede afectar el medio
ambiente. Por ejemplo, en un escenario en el que pueden estar presentes
gases volátiles, la supresión de chispas es un criterio de diseño crítico.
Existe otra clase de diferenciadores de dispositivos relacionados con la
conectividad externa del dispositivo para el montaje o la función
industrial. El montaje del dispositivo es una diferencia obvia entre
entornos OT y TI. Si bien existen entornos de montaje en rack en algunos
espacios industriales, con mayor frecuencia se encuentran entre los
activos de tipo de TI. Dentro de los entornos industriales, muchos
activos de computación y comunicación se colocan dentro de un espacio
cerrado, como un armario de control donde se montarán verticalmente
en un riel DIN (Deutsches Institut für Normung) en su interior. En otros
escenarios, los dispositivos pueden montarse horizontalmente
directamente en una pared o en una cerca.
A diferencia de la mayoría de los sistemas basados en TI, los sistemas
informáticos industriales a menudo transmiten su estado o reciben
entradas de dispositivos externos a través de un canal de alarma. Estos
pueden conducir una luz indicadora (luces de la pila) para mostrar el
estado de un elemento de proceso desde lejos. Este mismo elemento
también puede recibir entradas para iniciar acciones dentro del sistema
mismo.
Las fuentes de alimentación en los sistemas OT también suelen ser
diferentes de las que se ven comúnmente en los equipos informáticos
estándar. Una gama más amplia de variaciones de potencia son atributos
comunes de los componentes informáticos industriales. Las fuentes de
alimentación de CC también son comunes en muchos entornos. Dada la
criticidad de muchos sistemas, a menudo se requiere el suministro de
fuentes de alimentación redundantes en el dispositivo. Las fuentes de
alimentación externas, especialmente las que no están montadas
inherentemente, están mal vistas, dado el potencial de desenchufar
accidentalmente. En algunos casos de servicios públicos, el sistema debe
ser capaz de manejar breves cortes de energía y aún así continuar
operando.

Subcapa de red de acceso

Existe una relación directa entre la tecnología de red IoT que elija y el
tipo de topología de conectividad que permite esta tecnología. Cada
tecnología se diseñó con un cierto número de casos de uso en mente (qué
conectar, dónde conectarse, cuántos datos transportar a qué intervalo y
a qué distancia). Estos casos de uso determinaron la banda de frecuencia
que se esperaba que fuera más adecuada, la estructura de cuadro que
coincidía con el patrón de datos esperado (tamaño de paquete e
intervalos de comunicación) y las posibles topologías que ilustran estos
casos de uso.
A medida que IoT continúa creciendo exponencialmente, encontrará
una gran variedad de aplicaciones y casos de uso especiales. Para cada
uno de ellos, se requerirá una tecnología de acceso. IoT a veces reutiliza
las tecnologías de acceso existentes cuyas características coinciden más
o menos con los requisitos del caso de uso de IoT. Mientras que algunas
tecnologías de acceso se desarrollaron específicamente para casos de uso
de IoT, otras no.
Un parámetro clave que determina la elección de la tecnología de acceso
es el rango entre el objeto inteligente y el recopilador de información. La
Figura 2-9 enumera algunas tecnologías de acceso que puede encontrar
en el mundo de IoT y las distancias de transmisión previstas.
Tenga en cuenta que los rangos en la Figura 2-9 son inclusivos. Por
ejemplo, celular está indicado para transmisiones de más de 5 km, pero
se puede lograr una transmisión celular exitosa a un rango más corto
(por ejemplo, 100 m). Por el contrario, se espera que ZigBee sea eficiente
en un rango de algunas decenas de metros, pero no se esperaría una
transmisión ZigBee exitosa en un rango de 10 km.
Las estimaciones de rango se agrupan por nombres de categoría que
ilustran el entorno o la vertical donde se espera la recopilación de datos
en ese rango. Los grupos comunes son los siguientes:
PAN (red de área personal): Escala de unos pocos metros. Este es
el espacio personal alrededor de una persona. Una tecnología
inalámbrica común para esta escala es Bluetooth.
HAN (red de área local): escala de algunas decenas de metros. En
esta escala, las tecnologías inalámbricas comunes para IoT incluyen
ZigBee y Bluetooth Low Energy (BLE).
NAN (red de área del vecindario): escala de unos pocos cientos
de metros. El término NAN a menudo se usa para referirse a un grupo
de unidades de la casa de donde se recogen los datos.
VENTILADOR (red de área de campo): escala de varias decenas
de metros a varios cientos de metros. FAN generalmente se refiere a un
área al aire libre más grande que un solo grupo de unidades de la casa.
El VENTILADOR se ve a menudo como "espacio abierto" (y por lo tanto
no asegurado y no controlado). Un VENTILADOR a veces se ve como un
grupo de NAN, pero algunos verticales ven al VENTILADOR como un
grupo de HAN o un grupo de células al aire libre más pequeñas. Como
puede ver, FAN y NAN a veces se pueden usar indistintamente. En la
mayoría de los casos, el contexto vertical es lo suficientemente claro
como para determinar la jerarquía de agrupación.
LAN (red de área local): escala de hasta 100 m. Este término es
muy común en las redes y, por lo tanto, también se usa comúnmente en
el espacio IoT cuando se utilizan tecnologías de red estándar (como
Ethernet o IEEE 802.11). Otras clasificaciones de redes, como MAN (red
de área metropolitana, con un alcance de hasta unos pocos kilómetros)
y WAN (red de área amplia, con un alcance de más de unos pocos
kilómetros), también se utilizan comúnmente.
Tenga en cuenta que para todos estos lugares en la red IoT, se puede
agregar una "W" para indicar específicamente las tecnologías
inalámbricas utilizadas en ese espacio. Por ejemplo, HomePlug es una
tecnología cableada que se encuentra en un entorno HAN, pero una HAN
suele denominarse WHAN (red de área doméstica inalámbrica) cuando
se utiliza una tecnología inalámbrica, como ZigBee, en ese espacio.
Distancias alcanzables similares no significan protocolos similares y
características similares. Cada protocolo utiliza un formato de cuadro
específico y una técnica de transmisión sobre una frecuencia (o banda)
específica. Estas características introducen diferencias adicionales.Por
ejemplo, La Figura 2-10 muestra cuatro tecnologías que representan
rangos WHAN a WLAN y compara el rendimiento y el rango que se
puede lograr en cada caso. La Figura 2-10supone que el sensor usa el
mismo tamaño de cuadro , potencia de transmisión y ganancia de
antena. La pendiente de la degradación del rendimiento a medida que
aumenta la distancia varía enormemente de una tecnología a otra. Esta
diferencia limita la cantidad de rendimiento de datos que puede alcanzar
cada tecnología a medida que aumenta la distancia desde el sensor hasta
el receptor.
Aumentar el rendimiento y la distancia alcanzable generalmente viene
con un aumento en el consumo de energía. Por lo tanto, después de
determinar los requisitos del objeto inteligente (en términos de
movilidad y transferencia de datos), un segundo paso es determinar la
cantidad objetivo de objetos en una única celda de recolección, en
función del rango de transmisión y el rendimiento requerido. Este
parámetro a su vez determina el tamaño de la celda.
Puede ser tentador simplemente elegir la tecnología con el rango más
largo y el más alto rendimiento. Sin embargo, el costo de la tecnología es
un tercer factor determinante. La Figura 2-11 combina el costo, el rango,
el consumo de energía y el ancho de banda típico disponible para
tecnologías de acceso a IoT comunes.
La cantidad de datos para transportar durante un período de tiempo
dado junto con el consumo de energía correlacionado (limitaciones de
conducción posibles en la movilidad y el rango) determina el tamaño y
la estructura de la celda inalámbrica.
Rangos similares tampoco significan topologías similares. Algunas
tecnologías ofrecen una estructura de conectividad flexible para ampliar
las posibilidades de comunicación:
Topologías de punto a punto: estas topologías permiten que un
punto se comunique con otro punto. Esta topología en su sentido más
estricto es poco común para el acceso IoT, ya que implicaría que un solo
objeto puede comunicarse solo con una única puerta de enlace. Sin
embargo, varias tecnologías se conocen como "punto a punto" cuando
cada objeto establece una sesión individual con la puerta de enlace. El
concepto "punto a punto", en ese caso, a menudo se refiere a la
estructura de comunicación más que a la topología física.
Topologías punto a multipunto: estas topologías permiten que
un punto se comunique con más de otro punto. La mayoría de las
tecnologías IoT en las que una o más pasarelas se comunican con
múltiples objetos inteligentes se incluyen en esta categoría. Sin embargo,
dependiendo de las características disponibles en cada modo de
comunicación, se deben considerar varios subtipos. Una particularidad
de las redes IoT es que algunos nodos (por ejemplo, sensores) admiten
las funciones de recopilación y reenvío de datos, mientras que otros (por
ejemplo, algunas pasarelas) recopilan los datos del objeto inteligente, a
veces indican al sensor que realice operaciones específicas , y también se
conecta con otras redes o posiblemente otras puertas de enlace. Por esta
razón, algunas tecnologías categorizan los nodos según las funciones
(descritas por un protocolo) que implementan.
Un ejemplo de una tecnología que categoriza nodos según su función es
IEEE 802.15.4, que se trata en profundidad en el Capítulo 4 . Aunque
802.15.4 se utiliza como ejemplo en esta sección, los mismos principios
se pueden aplicar a muchas otras tecnologías. Las aplicaciones que
aprovechan IEEE 802.15.4 comúnmente se basan en el concepto de un
dispositivo final (un sensor) que recopila datos y los transmite a un
colector. Los sensores deben ser pequeños y, a menudo, móviles (o
móviles). Cuando son móviles, estos sensores comúnmente son
accionados por baterías.
Para formar una red, un dispositivo necesita conectarse con otro
dispositivo. Cuando ambos dispositivos implementan completamente
las funciones de pila de protocolo, pueden formar una red de igual a
igual. Sin embargo, en muchos casos, uno de los dispositivos recopila
datos de los demás. Por ejemplo, en una casa, los sensores de
temperatura pueden desplegarse en cada habitación o en cada zona de
la casa, y pueden comunicarse con un punto central donde se muestra y
controla la temperatura. Un sensor de sala no necesita comunicarse con
otro sensor de sala. En ese caso, el punto de control está en el centro de
la red. La red forma una topología en estrella, con el punto de control en
el centro y los sensores en los radios.
En tal configuración, el punto central puede estar a cargo de la
coordinación general de la red, teniendo cuidado de las transmisiones de
la baliza y la conexión a cada sensor. En el estándar IEEE 802.15.4, el
punto central se llama coordinador para la red Con este tipo de
despliegue, cada sensor no tiene la intención de hacer otra cosa que
comunicarse con el coordinador en una relación de tipo maestro /
esclavo. El sensor puede implementar un subconjunto de funciones de
protocolo para realizar solo una parte especializada (comunicación con
el coordinador). Tal dispositivo se llama dispositivo de función reducida
(RFD). Un RFD no puede ser un coordinador. Un RFD tampoco puede
implementar comunicaciones directas a otro RFD.
El coordinador que implementa las funciones de red completas se llama,
por el contrario, un dispositivo de función completa (FFD). Una FFD
puede comunicarse directamente con otra FFD o con más de una FFD,
formando múltiples conexiones de igual a igual. Las topologías donde
cada FFD tiene una ruta única a otra FFD se llaman topologías de árbol
de clúster. Las FFD en el árbol de clúster pueden tener RFD, lo que da
como resultado una topología de estrella de clúster. La Figura 2-
12 ilustra estas topologías.
Otras tecnologías de punto a multipunto permiten que un nodo tenga
más de una ruta a otro nodo, formando una topología de malla. Esta
redundancia significa que cada nodo puede comunicarse con más de un
solo nodo. Esta comunicación se puede usar para intercambiar
directamente información entre nodos (el receptor consume
directamente la información recibida) o para ampliar el alcance del
enlace de comunicación. En este caso, un nodo intermedio actúa como
un relé entre otros dos nodos. Estos otros dos nodos no podrían
comunicarse con éxito directamente respetando las restricciones de
potencia y modulación dictadas por el protocolo de capa PHY. La
extensión de rango generalmente tiene el precio de comunicaciones más
lentas (ya que los nodos intermedios necesitan pasar tiempo
transmitiendo los mensajes de otros nodos).Un ejemplo de una
tecnología que implementa una topología de malla es la malla Wi-Fi.
Otra propiedad de las redes de malla es la redundancia. La desaparición
de un nodo no necesariamente interrumpe las comunicaciones de
red. Es posible que los datos se transmitan a través de otros nodos para
llegar al destino deseado.
La Figura 2-13 muestra una topología de malla. Los nodos A y D están
muy separados para comunicarse directamente. En este caso, la
comunicación se puede retransmitir a través de los nodos B o C. El nodo
B se puede usar como el relevador primario. Sin embargo, la pérdida del
nodo B no impide la comunicación entre los nodos A y D. Aquí, la
comunicación se redirige a través de otro nodo, el nodo C.
Nota
La Figura 2-13 muestra una topología de malla parcial, donde un nodo puede
comunicarse con más de otro nodo, pero no todos los nodos se comunican
directamente con todos los demás nodos. En una topología de malla completa,
cada nodo se comunica con cada otro nodo. En la topología que se muestra en
la Figura 2-13 , que tiene 17 nodos, una estructura de malla completa significa
que cada nodo tendrá 16 conexiones (una para cada otro nodo). Las estructuras
de malla completa son computacionalmente costosas (ya que cada nodo necesita
mantener una conexión con cada otro nodo). En el espacio de IoT, las
implementaciones de malla completa son poco comunes. En la mayoría de los
casos, la información debe viajar a un destino objetivo en lugar de distribuirse
directamente a todos los otros nodos. Las topologías de malla completa también
limitan la distancia aceptable entre nodos (ya que todos los nodos deben estar en
el rango de todos los otros nodos).
Nota
No confundas la topología y rango . La topología describe la organización de
los nodos, mientras que el rango viene dictado por factores tales como la
frecuencia u operación, la estructura de la señal y el ancho de banda
operacional. Por ejemplo, tanto IEEE 802.15.4 como LoRaWAN implementan
topologías en estrella, pero el rango de IEEE 802.15.4 es de algunas decenas de
metros, mientras que LoRaWAN puede lograr una señal exitosa en
muchos kilómetros. El ancho de banda y la estructura de la señal (modulación)
son muy diferentes. La Figura 2-11 le ayuda a comparar los casos de uso y las
consideraciones de implementación (rango, costo, ancho de banda disponible)
para tecnologías de acceso a IoT comunes. Capítulo 4 describe en detalle
IEEE 802.15.4, LTE, LoRaWAN y otras tecnologías de IoT competidoras. Sin
embargo, tenga en cuenta que muchas tecnologías que no fueron diseñadas
inicialmente para el uso de IoT pueden ser aprovechadas por aplicaciones
específicas. Por ejemplo, es posible que los sitios remotos necesiten aprovechar
las comunicaciones satelitales cuando las tecnologías inalámbricas estándar IoT
no pueden alcanzar el rango requerido. Además, la adopción de tecnología puede
variar ampliamente con el tiempo, según los casos de uso, la madurez tecnológica
y otros factores. Por ejemplo, las tecnologías celulares se diseñaron inicialmente
para comunicaciones de voz. El estallido del tráfico de datos que acompañó la
explosión de dispositivos móviles a principios de la década de 2000 trajo consigo
el desarrollo de estándares mejorados para las comunicaciones celulares (con
LTE). A su vez, esta mejora permitió que LTE creciera rápidamente como una
tecnología de conexión importante para FAN.

Gateways y Backhaul Sublayer

Los datos recopilados de un objeto inteligente pueden necesitar ser
enviados a una estación central donde se procesan los datos. Como esta
estación está a menudo en una ubicación diferente del objeto inteligente,
los datos recibidos directamente del sensor a través de una tecnología de
acceso deben ser enviados a otro medio (la red de retorno) y
transportados a la estación central. La puerta de enlace está a cargo de
esta comunicación entre medios.
En la mayoría de los casos, los objetos inteligentes son estáticos o
móviles dentro de un área limitada. La puerta de enlace a menudo es
estática. Sin embargo, algunas tecnologías IoT no aplican este
modelo. Por ejemplo, la comunicación dedicada de corto alcance
(DSRC) permite la comunicación de vehículo a vehículo y de vehículo a
infraestructura. En este modelo, la posición del objeto inteligente con
respecto a la puerta de enlace es estática. El auto incluye sensores y una
puerta de enlace. La comunicación entre los sensores y la puerta de
enlace puede involucrar tecnologías cableadas o inalámbricas. Los
sensores también pueden integrarse en la infraestructura vial y
conectarse a través de una tecnología cableada o inalámbrica a una
puerta de enlace al costado de la carretera. Una tecnología inalámbrica
(DSRC opera en el rango superior de 5 GHz) se utiliza para la
comunicación de retroceso, comunicación punto a punto o en malla
entre vehículos.
En el caso DSRC, todo el "campo sensor" se está moviendo junto con la
puerta de enlace, pero los principios generales de la red IoT siguen
siendo los mismos. El rango en el que DSRC puede comunicarse es
limitado. De manera similar, para todas las demás arquitecturas de IoT,
la elección de una tecnología de backhaul depende de la distancia de
comunicación y también de la cantidad de datos que se deben reenviar.
Cuando el funcionamiento del objeto inteligente se controla desde sitio
local, y cuando el entorno es estable (por ejemplo, fábrica o campo de
petróleo y gas), Ethernet se puede utilizar como una red de retorno. En
entornos inestables o cambiantes (por ejemplo, minas abiertas) donde
los cables no se pueden ejecutar con seguridad, se utiliza una tecnología
inalámbrica. El Wi-Fi es común en este caso, a menudo con múltiples
saltos entre el campo del sensor y el centro de operación. Mesh es una
topología común para permitir la flexibilidad de comunicación en este
tipo de entorno dinámico.
Sin embargo, el rendimiento disminuye a medida que aumenta la
distancia entre nodos, y también disminuye a medida que aumenta el
número de saltos. En una red de malla Wi-Fi típica, mitades de
rendimiento para cada salto adicional. Algunas tecnologías, como
802.11ah, implementan Wi-Fi en una banda inferior (inferior a 1 GHz en
lugar de 2.4 GHz / 5 GHz para Wi-Fi clásico) con disposiciones
especiales adaptadas a IoT, para lograr un alcance más largo (hasta
aproximadamente 2 km). Más allá de ese rango, se necesitan otras
tecnologías.
WiMAX (802.16) es un ejemplo de una tecnología de mayor alcance.
WiMAX puede alcanzar rangos de hasta 50 kilómetros con tasas de hasta
70 Mbps. Obviamente, no puede alcanzar la velocidad máxima en el
rango máximo; podría esperar hasta 70 Mbps a corto alcance y de 2 a 3
Mbps en el rango máximo. 802.16d (también llamado WiMAX fijo)
describe la implementación de backhaul del protocolo. Se han publicado
mejoras en este aspecto (802.16.1), pero la mayoría de las redes WiMAX
todavía implementan una variación de 802.16d. 802.16 puede operar en
bandas sin licencia, pero su función de backhaul a menudo se
implementa en bandas con licencia más confiables, donde las
interferencias de otros sistemas están mejor controladas.
Como las bandas con licencia implican el pago de una tarifa de
usabilidad, otras tecnologías celulares también crecieron como
soluciones competitivas para la parte de backhaul para lograr un rango
similar. La elección de WiMAX o una tecnología celular depende de la
vertical y la ubicación (preferencias locales, costos locales). El Capítulo
4 ofrece una visión en profundidad de los protocolos implementados
más comúnmente para este segmento, y la Tabla 2-4 compara las
soluciones principales desde un ángulo arquitectónico.

Tabla 2-4 Consideraciones arquitectónicas para WiMAX y tecnologías celulares

Subcapa de transporte de red

La sección anterior describe una arquitectura de comunicación
jerárquica en la que una serie de objetos inteligentes informan a una
puerta de enlace que transmite los datos informados a través de otro
medio y hasta una central
Nota
La Figura 2-13 muestra una topología de malla parcial, donde un nodo
puede comunicarse con más de otro nodo, pero no todos los nodos se
comunican directamente con todos los demás nodos. En una topología
de malla completa, cada nodo se comunica con cada otro nodo. En la
topología que se muestra en la Figura 2-13, que tiene 17 nodos, una
estructura de malla completa significa que cada nodo tendrá 16
conexiones (una para cada otro nodo). Las estructuras de malla
completa son computacionalmente costosas (ya que cada nodo necesita
mantener una conexión con cada otro nodo). En el espacio de IoT, las
implementaciones de malla completa son poco comunes. En la mayoría
de los casos, la información debe viajar a un destino objetivo en lugar de
distribuirse directamente a todos los otros nodos. Las topologías de
malla completa también limitan la distancia aceptable entre nodos (ya
que todos los nodos deben estar en el rango de todos los otros nodos).
Nota
No confundas topología y rango. La topología describe la organización
de los nodos, mientras que el rango viene dictado por factores tales como
la frecuencia u operación, la estructura de la señal y el ancho de banda
operacional. Por ejemplo, tanto IEEE 802.15.4 como LoRaWAN
implementan topologías en estrella, pero el rango de IEEE 802.15.4 es
de algunas decenas de metros, mientras que LoRaWAN puede lograr una
señal exitosa en muchos kilómetros. El ancho de banda y la estructura
de la señal (modulación) son muy diferentes. La Figura 2-11 le ayuda a
comparar los casos de uso y las consideraciones de implementación
(rango, costo, ancho de banda disponible) para tecnologías de acceso a
IoT comunes. El Capítulo 4 describe en detalle IEEE 802.15.4, LTE,
LoRaWAN y otras tecnologías de IoT competidoras. Sin embargo, tenga
en cuenta que muchas tecnologías que no fueron diseñadas inicialmente
para el uso de IoT pueden ser aprovechadas por aplicaciones
específicas.Por ejemplo, es posible que los sitios remotos necesiten
aprovechar las comunicaciones satelitales cuando las tecnologías
inalámbricas estándar IoT no pueden alcanzar el rango requerido.
Además, la adopción de tecnología puede variar ampliamente con el
tiempo, según los casos de uso, la madurez tecnológica y otros factores.
Por ejemplo, las tecnologías celulares se diseñaron inicialmente para
comunicaciones de voz. El estallido del tráfico de datos que acompañó la
explosión de dispositivos móviles a principios de la década de 2000 trajo
consigo el desarrollo de estándares mejorados para las comunicaciones
celulares (con LTE). A su vez, esta mejora permitió que LTE creciera
rápidamente como una tecnología de conexión importante para
FAN.madurez tecnológica y otros factores. Por ejemplo, las tecnologías
celulares se diseñaron inicialmente para comunicaciones de voz. El
estallido del tráfico de datos que acompañó la explosión de dispositivos
móviles a principios de la década de 2000 trajo consigo el desarrollo de
estándares mejorados para las comunicaciones celulares (con LTE). A su
vez, esta mejora permitió que LTE creciera rápidamente como una
tecnología de conexión importante para FAN.madurez tecnológica y
otros factores. Por ejemplo, las tecnologías celulares se diseñaron
inicialmente para comunicaciones de voz. El estallido del tráfico de datos
que acompañó la explosión de dispositivos móviles a principios de la
década de 2000 trajo consigo el desarrollo de estándares mejorados para
las comunicaciones celulares (con LTE). A su vez, esta mejora permitió
que LTE creciera rápidamente como una tecnología de conexión
importante para FAN.
Gateways y Backhaul Sublayer
Los datos recopilados de un objeto inteligente pueden necesitar ser
enviados a una estación central donde se procesan los datos. Como esta
estación está a menudo en una ubicación diferente del objeto inteligente,
los datos recibidos directamente del sensor a través de una tecnología de
acceso deben ser enviados a otro medio (la red de retorno) y
transportados a la estación central. La puerta de enlace está a cargo de
esta comunicación entre medios.
En la mayoría de los casos, los objetos inteligentes son estáticos o
móviles dentro de un área limitada. La puerta de enlace a menudo es
estática. Sin embargo, algunas tecnologías IoT no aplican este modelo.
Por ejemplo, la comunicación dedicada de corto alcance (DSRC) permite
la comunicación de vehículo a vehículo y de vehículo a infraestructura.
En este modelo, la posición del objeto inteligente con respecto a la puerta
de enlace es estática. El auto incluye sensores y una puerta de enlace. La
comunicación entre los sensores y la puerta de enlace puede involucrar
tecnologías cableadas o inalámbricas. Los sensores también pueden
integrarse en la infraestructura vial y conectarse a través de una
tecnología cableada o inalámbrica a una puerta de enlace al costado de
la carretera. Una tecnología inalámbrica (DSRC opera en el rango
superior de 5 GHz) se utiliza para la comunicación de retroceso,
comunicación punto a punto o en malla entre vehículos.
En el caso DSRC, todo el "campo sensor" se está moviendo junto con la
puerta de enlace, pero los principios generales de la red IoT siguen
siendo los mismos. El rango en el que DSRC puede comunicarse es
limitado. De manera similar, para todas las demás arquitecturas de IoT,
la elección de una tecnología de backhaul depende de la distancia de
comunicación y también de la cantidad de datos que se deben reenviar.
Cuando el funcionamiento del objeto inteligente se controla desde un
sitio local, y cuando el entorno es estable (por ejemplo, fábrica o campo
de petróleo y gas), Ethernet se puede utilizar como una red de retorno.
En entornos inestables o cambiantes (por ejemplo, minas abiertas)
donde los cables no se pueden ejecutar con seguridad, se utiliza una
tecnología inalámbrica. El Wi-Fi es común en este caso, a menudo con
múltiples saltos entre el campo del sensor y el centro de operación.Mesh
es una topología común para permitir la flexibilidad de comunicación en
este tipo de entorno dinámico.
Sin embargo, el rendimiento disminuye a medida que aumenta la
distancia entre nodos, y también disminuye a medida que aumenta el
número de saltos. En una red de malla Wi-Fi típica, mitades de
rendimiento para cada salto adicional. Algunas tecnologías, como
802.11ah, implementan Wi-Fi en una banda inferior (inferior a 1 GHz en
lugar de 2.4 GHz / 5 GHz para Wi-Fi clásico) con disposiciones
especiales adaptadas a IoT, para lograr un alcance más largo (hasta
aproximadamente 2 km). Más allá de ese rango, se necesitan otras
tecnologías.
WiMAX (802.16) es un ejemplo de una tecnología de mayor alcance.
WiMAX puede alcanzar rangos de hasta 50 kilómetros con tasas de hasta
70 Mbps. Obviamente, no puede alcanzar la velocidad máxima en el
rango máximo; podría esperar hasta 70 Mbps a corto alcance y de 2 a 3
Mbps en el rango máximo. 802.16d (también llamado WiMAX fijo)
describe la implementación de backhaul del protocolo. Se han publicado
mejoras en este aspecto (802.16.1), pero la mayoría de las redes WiMAX
todavía implementan una variación de 802.16d. 802.16 puede operar en
bandas sin licencia, pero su función de backhaul a menudo se
implementa en bandas con licencia más confiables, donde las
interferencias de otros sistemas están mejor controladas.
Como las bandas con licencia implican el pago de una tarifa de
usabilidad, otras tecnologías celulares también crecieron como
soluciones competitivas para la parte de backhaul para lograr un rango
similar. La elección de WiMAX o una tecnología celular depende de la
vertical y la ubicación (preferencias locales, costos locales). El Capítulo
4 ofrece una visión en profundidad de los protocolos implementados
más comúnmente para este segmento, y la Tabla 2-4 compara las
soluciones principales desde un ángulo arquitectónico.

Tabla 2-4 Consideraciones arquitectónicas para WiMAX y tecnologías

celulares
Subcapa de transporte de red
La sección anterior describe una arquitectura de comunicación
jerárquica en la que una serie de objetos inteligentes informan a una
puerta de enlace que transmite los datos informados a través de otro
medio y hasta una estación central. Sin embargo, las implementaciones
prácticas a menudo son flexibles, con múltiples rutas de comunicación
transversales. Por ejemplo, considere el caso de IoT para la red de
energía. Su casa puede tener un medidor que informa el consumo de
energía a una puerta de enlace a través de una tecnología inalámbrica.
Otras casas en su vecindario (NAN) hacen el mismo informe,
probablemente a una o varias puertas de enlace. Los datos que se
transportan son pequeños y el intervalo es grande (por ejemplo, cuatro
veces por hora), lo que da como resultado un tipo de estructura de datos
de baja movilidad y bajo rendimiento, con distancias de transmisión de
hasta una milla. Varias tecnologías (como 802.11ah, 802.15.4,o LPWA)
se puede utilizar para este segmento de colección. Otros vecindarios
también pueden conectarse de la misma manera, formando así un
VENTILADOR.
Por ejemplo, el servidor de aplicación de cabecera de la utilidad de
energía puede ser regional, y la puerta de enlace puede retransmitirse a
una tecnología de backhaul cableada o inalámbrica. La estructura parece
ser jerárquica. Prácticamente, sin embargo, este sistema de IoT puede
lograr más que un informe básico inicial. Si su consumo de energía se
vuelve inusualmente alto, el servidor de aplicaciones de la cabecera de la
utilidad puede necesitar informes bajo demanda de su medidor a
intervalos cortos para seguir la tendencia de consumo. A partir de un
modelo de inserción vertical estándar, la estructura de transporte
cambia y se vuelve bidireccional (modelo de extracción en sentido
descendente en lugar de empuje ascendente).
La automatización de la distribución (DA) también permite que su
medidor se comunique con medidores vecinos u otros dispositivos en la
red de distribución eléctrica. Con tal comunicación, el equilibrio de carga
de consumo puede optimizarse. Por ejemplo, su aire acondicionado
impulsa aire fresco a intervalos regulares. Con DA, la CA de tu vecino
comienza a pulsar cuando el sistema hace una pausa; de esta manera, el
aire en ambas casas se mantiene fresco, pero la energía consumida por
la red es estable en lugar de subir y bajar con puntos de inicio y parada
descoordinados. Aquí nuevamente, el modelo de transporte cambia.
Desde una estructura vertical, ahora está cambiando a una posible
estructura de malla con múltiples intercambios de igual a igual.
Del mismo modo, su medidor inteligente puede comunicarse con los
electrodomésticos para evaluar su tipo y la demanda de energía. Con este
esquema, su lavadora puede encenderse en momentos de menor
consumo de otros sistemas, como por la noche, mientras que la energía
de su sistema de teatro en casa nunca se verá privada, siempre encendido
cuando lo necesite. Una vez que el sistema aprende su patrón de
consumo, la carga de su automóvil eléctrico puede comenzar y detenerse
a intervalos para lograr la misma carga durante la noche sin crear picos
en la demanda de energía. Cuando aparecen estas funciones, el modelo
de transporte cambia de nuevo. Un sistema de malla puede aparecer en
la escala de la casa. Más comúnmente, aparece una malla parcial, con
algunos nodos centrales que se conectan a otros muchos nodos. Los
datos pueden fluir localmenteo puede tener que ser orquestado por una
aplicación central para coordinar el presupuesto de energía entre las
casas.
En este sistema inteligente, el sistema de carga de su automóvil está
conectado a su cuenta de energía. A medida que se conecta a una
estación de carga pública, su auto inicia sesión en el sistema para
identificarse y vincularse de manera única a su cuenta. A intervalos
regulares, el sistema central puede necesitar consultar todas las
estaciones de carga para la actualización del estado. La estructura de
transporte pierde su organización vertical un poco más en este modelo,
ya que puede conectarse desde cualquier lugar. En un entorno
administrado, el sistema de cabecera necesita actualizar el software en
su medidor, al igual que los proveedores de dispositivos pueden
necesitar actualizar el software de energía inteligente de su horno o
lavadora. A partir de un flujo de transporte de datos ascendente, ahora
implementa flujos de datos descendentes.
Por lo tanto, esta estructura de comunicación puede implicar punto a
punto (por ejemplo, metro a metro), punto a punto (metro a estación de
cabecera), punto a multipunto (puerta de enlace o extremo a varios
metros), unidifusión y comunicaciones de multidifusión (actualización
de software para uno o múltiples sistemas). En un entorno multiusuario
(por ejemplo, administración de consumo de electricidad y gas),
diferentes sistemas pueden usar las mismas vías de comunicación. Esta
comunicación ocurre a través de múltiples medios (por ejemplo, líneas
eléctricas dentro de su hogar o un sistema inalámbrico de corto alcance
como Wi-Fi interior y / o ZigBee), un sistema inalámbrico de mayor
alcance a la puerta de enlace y otro medio inalámbrico o cableado para
transmisión de retroceso
Para permitir dicha estructura de comunicación, es necesario
implementar un protocolo de red con características específicas. El
protocolo debe ser abierto y estar basado en estándares para adaptarse
a múltiples industrias y múltiples medios. La escalabilidad (para
acomodar miles o millones de sensores en una sola red) y la seguridad
también son requisitos comunes. IP es un protocolo que coincide con
todos estos requisitos. Las ventajas de la propiedad intelectual se tratan
en profundidad en el Capítulo 5.
La flexibilidad de IP permite que este protocolo se integre en objetos de
naturalezas muy diferentes, intercambiando información a través de
medios muy diferentes, incluidas redes de baja potencia, con pérdida y
de bajo ancho de banda. Por ejemplo, RFC 2464 describe cómo un
paquete IPv6 se encapsula en un marco Ethernet y también se utiliza
para Wi-Fi IEEE 802.11. De forma similar, el grupo de trabajo IETF
6LoWPAN especifica cómo los paquetes IPv6 se transportan de manera
eficiente a través de redes con pérdida, formando una "capa de
adaptación" para IPv6, principalmente para redes IoT. El Capítulo 4
proporciona más detalles sobre 6LoWPAN y sus capacidades.
Finalmente, los protocolos de capa de transporte construidos sobre IP
(UDP y TCP) pueden aprovecharse fácilmente para decidir si la red debe
controlar la entrega del paquete de datos (con TCP) o si la tarea de
control debe dejarse a la aplicación (UDP). UDP es un protocolo mucho
más ligero y más rápido que TCP. Sin embargo, no garantiza la entrega
de paquetes. Tanto TCP como UDP pueden protegerse con TLS / SSL
(TCP) o DTLS (UDP). El Capítulo 6 examina de cerca TCP y UDP para
redes IoT.
Subcapa de gestión de red IoT
IP, TCP y UDP brindan conectividad a las redes de IoT. Los protocolos
de capa superior deben encargarse de la transmisión de datos entre los
objetos inteligentes y otros sistemas. Se han aprovechado o creado
múltiples protocolos para resolver problemas de comunicación de datos
de IoT. Algunas redes dependen de un modelo de inserción (es decir, un
sensor informa a intervalos regulares o de un activador local), mientras
que otras dependen de un modelo de extracción (es decir, una aplicación
consulta el sensor a través de la red) y múltiples híbridos enfoques
también son posibles.
Siguiendo la lógica de IP, algunos implementadores de IoT han sugerido
HTTP para la fase de transferencia de datos. Después de todo, HTTP
tiene un componente de cliente y servidor. El sensor podría usar la parte
del cliente para establecer una conexión con la aplicación central de IoT
(el servidor), y luego se pueden intercambiar datos. Puede encontrar
HTTP en algunas aplicaciones de IoT, pero HTTP es algo así como un
protocolo gordo y no fue diseñado para operar en entornos restringidos
con poca memoria, baja potencia, bajo ancho de banda y una alta tasa de
falla de paquetes. A pesar de estas limitaciones, se han sugerido otros
protocolos derivados de la web para el espacio IoT. Un ejemplo es
WebSocket. WebSocket forma parte de la especificación HTML5 y
proporciona una conexión bidireccional simple a través de una única
conexión. Algunas soluciones IoT usan WebSocket para administrar la
conexión entre el objeto inteligente y una aplicación externa.WebSocket
a menudo se combina con otros protocolos, como MQTT (descrito en
breve) para manejar la parte específica de IoT de la comunicación.
Con la misma lógica de reutilización de métodos conocidos, se creó el
protocolo extensible Messaging and Presence Protocol (XMPP). XMPP
se basa en mensajería instantánea y presencia. Permite el intercambio
de datos entre dos o más sistemas y admite el mantenimiento de la
presencia y la lista de contactos. También puede manejar publicar /
suscribir, por lo que es una buena opción para la distribución de
información a múltiples dispositivos. Una limitación de XMPP es su
dependencia de TCP, que puede obligar a los suscriptores a mantener
sesiones abiertas a otros sistemas y puede ser una limitación para
objetos con memoria limitada.
Para responder a los límites de los protocolos web, otro protocolo fue
creado por el grupo de trabajo Entornos restringidos restringidos
(CoRE) de IETF: Protocolo de aplicación restringida (CoP). CoAP utiliza
algunos métodos similares a los de HTTP (como Get, Post, Put y Delete)
pero implementa una lista más corta, lo que limita el tamaño del
encabezado. CoAP también se ejecuta en UDP (mientras que HTTP
generalmente usa TCP). CoAP también agrega una característica que
falta en HTTP y muy útil para IoT: observación. La observación permite
la transmisión de cambios de estado a medida que ocurren, sin que el
receptor tenga que consultar estos cambios.
Otro protocolo común de IoT utilizado en estas capas intermedias y
superiores es Message Queue Telemetry Transport (MQTT). MQTT usa
una arquitectura basada en intermediarios. El sensor se puede
configurar para que sea un editor MQTT (publica una información), la
aplicación que necesita recibir la información se puede establecer como
el suscriptor MQTT, y cualquier sistema intermediario se puede
configurar como un intermediario para transmitir la información entre
el editor y el (los) suscriptor (es). MQTT se ejecuta sobre TCP. Una
consecuencia de la dependencia de TCP es que un cliente MQTT
generalmente mantiene una conexión abierta al intermediario en todo
momento. Esto puede ser un factor limitante en entornos donde la
pérdida es alta o donde los recursos informáticos son limitados.
El Capítulo 6 examina con más detalle los diversos protocolos de
aplicación de IoT, incluidos CoAP y MQTT. Desde el punto de vista
arquitectónico, debe determinar los requisitos de su protocolo de
aplicación. Confiar en TCP implica mantener sesiones entre puntos
finales. La ventaja de la confiabilidad viene con el costo de la memoria y
los recursos de procesamiento consumidos para el conocimiento de la
sesión. Depender de UDP delega el control en las capas
superiores. También necesita determinar los requisitos de QoS con
diferentes niveles de prioridad entre los diversos mensajes. Finalmente,
debe evaluar la seguridad del protocolo de la aplicación IoT para
equilibrar el nivel de seguridad proporcionado con los gastos generales
requeridos. El Capítulo 8 describe cómo evaluar el aspecto de seguridad
de las redes IoT.
Capa 3: Aplicaciones y capa de análisis
Una vez conectado a una red, sus objetos inteligentes intercambian
información con otros sistemas. Tan pronto como su red IoT abarque
más que unos pocos sensores, la potencia de Internet of Things aparece
en las aplicaciones que hacen uso de la información intercambiada con
los objetos inteligentes.
Aplicaciones de análisis versus control
Múltiples aplicaciones pueden ayudar a aumentar la eficiencia de una
red IoT. Cada aplicación recopila datos y proporciona una gama de
funciones basadas en el análisis de los datos recopilados. Puede ser
difícil comparar las características ofrecidas. El Capítulo 7, "Datos y
análisis para IoT", proporciona un análisis en profundidad de las
diversas familias de aplicaciones. Desde el punto de vista arquitectónico,
una clasificación básica puede ser la siguiente:
Aplicación de análisis: este tipo de aplicación recopila datos de múltiples
objetos inteligentes, procesa los datos recopilados y muestra
información resultante de los datos que se procesaron. La pantalla puede
referirse a cualquier aspecto de la red IoT, desde informes históricos,
estadísticas o tendencias hasta estados del sistema individuales. El
aspecto importante es que la aplicación procesa los datos para transmitir
una vista de la red que no se puede obtener simplemente mirando la
información que muestra un solo objeto inteligente.
Aplicación de control: este tipo de aplicación controla el
comportamiento del objeto inteligente o el comportamiento de un objeto
relacionado con el objeto inteligente. Por ejemplo, un sensor de presión
se puede conectar a una bomba. Una aplicación de control aumenta la
velocidad de la bomba cuando el sensor conectado detecta una caída en
la presión. Las aplicaciones de control son muy útiles para controlar
aspectos complejos de una red IoT con una lógica que no se puede
programar dentro de un único objeto IoT, ya sea porque los cambios
configurados son demasiado complejos para adaptarse al sistema local o
porque los cambios configurados dependen de parámetros que incluyen
elementos fuera del objeto IoT.
Un ejemplo de arquitectura de sistema de control es SCADA. SCADA fue
desarrollado como un método universal para acceder a sistemas remotos
y enviar instrucciones. Un ejemplo en el que SCADA se utiliza
ampliamente es en el control y la supervisión de unidades terminales
remotas (RTU) en la red de distribución eléctrica.
Muchas aplicaciones avanzadas de IoT incluyen tanto análisis como
módulos de control. En la mayoría de los casos, los datos se recopilan de
los objetos inteligentes y se procesan en el módulo de análisis. El
resultado de este procesamiento se puede usar para modificar el
comportamiento de los objetos inteligentes o sistemas relacionados con
los objetos inteligentes. El módulo de control se utiliza para transmitir
las instrucciones de cambios de comportamiento. Al evaluar
una aplicación de datos y análisis de IoT , debe determinar la
profundidad relativa de la parte de control necesaria para su caso de uso
y compararla con el tipo de análisis provisto.
Datos versus análisis de red
Analytics es un término general que describe el procesamiento de
información para dar sentido a los datos recopilados. En el mundo de
IoT, una posible clasificación de la función de análisis es la siguiente:
Análisis de datos: este tipo de análisis procesa los datos recopilados por
objetos inteligentes y los combina para proporcionar una vista
inteligente relacionada con el sistema IoT. En un nivel muy básico, un
tablero de instrumentos puede mostrar una alarma cuando un sensor de
peso detecta que un estante está vacío en una tienda. En un caso más
complejo, la temperatura, presión, viento, humedad y niveles de luz
recolectados de miles de sensores pueden combinarse y luego procesarse
para determinar la probabilidad de una tormenta y su posible camino.
En este caso, el procesamiento de datos puede ser muy complejo y puede
combinar múltiples valores cambiantes sobre algoritmos complejos. El
análisis de datos también puede monitorear el sistema de IoT en sí
mismo. Por ejemplo, una máquina o robot en una fábrica puede
informar datos sobre sus propios movimientos. Esta información puede
ser utilizada por una aplicación de análisis para informar la degradación
en las velocidades de movimiento,que puede ser indicativo de una
necesidad de dar servicio al robot antes de que se rompa una parte.
Análisis de red: la mayoría de los sistemas IoT se basan en objetos
inteligentes conectados a la red. Una pérdida o degradación en la
conectividad es probable que afecte la eficiencia del sistema. Tal pérdida
puede tener efectos dramáticos. Por ejemplo, las minas abiertas usan
redes inalámbricas para pilotear automáticamente camiones de volteo.
Una pérdida duradera de conectividad puede ocasionar un accidente o
una degradación de la eficiencia de las operaciones (los camiones
volquete automáticos suelen detenerse por la pérdida de conectividad).
En una escala menor, la pérdida de conectividad significa que los datos
dejan de alimentar su plataforma de análisis de datos y el sistema deja
de realizar análisis inteligentes del sistema de IoT. Una consecuencia
similar es que el módulo de control ya no puede modificar el
comportamiento de los objetos locales.
La mayoría de las aplicaciones analíticas emplean módulos de análisis
de datos y de red. Al diseñar un sistema de IoT, debe evaluar la necesidad
de cada uno. El análisis de red es necesario para los sistemas conectados.
Sin embargo, la profundidad del análisis depende de sus casos de uso.
Una vista de conectividad básica puede ser suficiente si los objetos
inteligentes informan un estado ocasional, sin expectativa de acción
inmediata basada en este informe. Se necesitan análisis detallados y
tendencias sobre el rendimiento de la red si se espera que la aplicación
central piloto en sistemas conectados casi en tiempo real.
El análisis de datos es un espacio más amplio con un área gris más
grande (en términos de necesidades) que el análisis de red. Los análisis
de sistemas básicos pueden proporcionar vistas del estado del sistema y
del análisis de tendencias del estado. Los sistemas más avanzados
pueden refinar el tipo de datos recopilados y mostrar información
adicional sobre el sistema. El tipo de datos y procesos recopilados varía
ampliamente con el caso de uso.
Data Analytics Versus Business Benefits
El análisis de datos es sin duda un campo donde el valor de IoT está en
auge. Se puede conectar casi cualquier objeto y se pueden instalar
múltiples tipos de sensores en un objeto determinado. La recopilación e
interpretación de los datos generados por estos dispositivos es donde se
realiza el valor de IoT.
Desde un punto de vista arquitectónico, puede definir redes de IoT
estáticas donde se determina una lista clara de elementos para
monitorear y analizar. Dichos sistemas estáticos son comunes en
entornos industriales en los que la Carta Io trata de proporcionar una
visión clara del estado de la operación. Sin embargo, una opción
arquitectónica más inteligente puede ser permitir un sistema abierto en
el que la red esté diseñada para ser lo suficientemente flexible como para
que otros sensores puedan agregarse en el futuro, y donde se permitan
tanto las operaciones ascendentes como descendentes. Esta flexibilidad
permite el procesamiento adicional de los sensores existentes y también
una interacción más profunda y más eficiente con los objetos
conectados. Este procesamiento de datos mejorado puede generar un
nuevo valor agregado para las empresas que no están previstas en el
momento en que el sistema se implementó inicialmente.
Un ejemplo de una aplicación de análisis y control flexible es Cisco
Jasper, que proporciona una plataforma llave en mano para la
administración y monetización de IoT. Considere el caso de las
máquinas expendedoras desplegadas en toda la ciudad. En un nivel
básico, estas máquinas se pueden conectar, y los sensores se pueden
implementar para informar cuando una máquina está en un estado de
error. Se puede enviar una persona de reparación para abordar el
problema cuando se identifica dicho estado. Este tipo de alerta es un
ahorro de tiempo y evita la necesidad de que el equipo de reparación
recorra todas las máquinas alternadamente cuando solo una puede estar
funcionando mal.
Este sistema de alerta también puede evitar el retraso entre el momento
en que una máquina entra en el estado de error y el momento en que un
equipo de reparación visita la ubicación de la máquina. Con una
plataforma estática, este caso de uso está limitado a este tipo de alerta.
Con una plataforma flexible como Cisco Jasper, se pueden imaginar y
desarrollar nuevas aplicaciones a lo largo del tiempo. Por ejemplo, los
sensores de la máquina se pueden mejorar para informar también
cuando se vende un artículo. La aplicación central se puede mejorar para
procesar esta información y analizar qué elemento se vende más, en qué
ubicación y en qué momentos. Esta nueva vista de las máquinas puede
permitir una optimización de los artículos para vender en máquinas en
un área determinada. Se pueden implementar sistemas para adaptar los
bienes a la hora, la temporada o la ubicación, o muchos otros parámetros
que pueden haberse analizado. En breve,la arquitectura de sistemas
abiertos abre la posibilidad de nuevas aplicaciones.
Servicios inteligentes
La capacidad de usar IoT para mejorar las operaciones a menudo se
denomina "servicios inteligentes". Este término es genérico, y en
muchos casos se usa el término, pero su significado a menudo se amplía
para incluir una forma de servicio u otro donde se requiere un nivel
adicional de inteligencia. previsto.
Fundamentalmente, los servicios inteligentes usan IoT y apuntan a la
eficiencia. Por ejemplo, se pueden instalar sensores en el equipo para
garantizar el cumplimiento continuo de las normativas o los requisitos
de seguridad. Este ángulo de eficiencia puede tomar múltiples formas,
desde sensores de presencia en áreas peligrosas hasta detectores de
violación de umbral de peso en camiones.
Los servicios inteligentes también se pueden usar para medir la
eficiencia de las máquinas detectando la salida de la máquina, la
velocidad u otras formas de evaluación de uso. Se pueden optimizar
todas las operaciones con IoT. En hospitalidad, por ejemplo, los sensores
de presencia y movimiento pueden evaluar el número de invitados en un
lobby y redirigir al personal en consecuencia. El mismo tipo de acción se
puede tomar en una tienda donde se detecta que un cliente se queda más
tiempo que la cantidad de tiempo típica frente a un estante. El personal
puede ser desplegado para proporcionar asistencia. Se puede analizar el
movimiento de personas y objetos en las plantas de las fábricas para
optimizar el flujo de producción.
Los servicios inteligentes se pueden integrar en un sistema de IoT. Por
ejemplo, los sensores pueden integrarse en una bombilla. Un sensor
puede encender o apagar una luz según la presencia de un humano en la
habitación. Un sistema incluso más inteligente puede comunicarse con
otros sistemas en la casa, aprender el patrón de movimiento humano y
anticipar la presencia de un ser humano, encender la luz justo antes de
que la persona entre en la habitación. Un sistema incluso más inteligente
puede usar sensores más inteligentes que analizan múltiples parámetros
para detectar el estado de ánimo humano y modificar consecuentemente
el color de la luz para adaptarse a las preferencias aprendidas, o para
transmitir un entorno más relajante o más dinámico.
Las bombillas son un simple ejemplo. Al conectarse a otros sistemas en
la casa, las eficiencias se pueden coordinar. Por ejemplo, el sistema de
alarma de entrada a la casa o el sistema de calefacción pueden
coordinarse con el detector de presencia en una bombilla para adaptarse
a los cambios detectados. El sistema de alarma puede desactivar las
alarmas de movimiento volumétrico en las zonas donde se detecta una
persona conocida. El sistema de calefacción puede adaptar la
temperatura a la presencia humana o detectar preferencias personales.
Una eficiencia similar se puede extender a sistemas más grandes que una
casa. Por ejemplo, las aplicaciones de red inteligente pueden coordinar
el consumo de energía entre las casas para regular la demanda de energía
de la red. Ya mencionamos que su lavadora puede encenderse por la
noche cuando la demanda de energía para calefacción y refrigeración es
menor. Así como los pulsos de su aire acondicionado se pueden
coordinar con los de su vecino, los ciclos de su lavadora pueden
coordinarse con los electrodomésticos de su casa y del vecindario para
suavizar los picos de demanda de energía en la red.
La eficiencia también se aplica a las comunicaciones M2M. En entornos
de minería, los vehículos pueden comunicarse para regular los flujos
entre taladros, dragalinas, excavadoras y volquetes, por ejemplo,
asegurándose de que un camión volquete esté siempre disponible
cuando un bulldozer lo necesita. En las ciudades inteligentes, los
vehículos se comunican. El transporte público detecta y anticipa
automáticamente un atasco y el sistema puede redireccionar
temporalmente los autobuses o regular el número de autobuses que
atienden una línea específica en función del tráfico y la cantidad de
clientes, instantáneos o aprendidos sobre la tendencia.
La Parte III de este libro proporciona ejemplos detallados de cómo IoT
está dando forma a industrias específicas. Las lecciones aprendidas son
siempre que la arquitectura de sistemas abiertos de IoT permite una
mayor eficiencia en el tiempo. Nuevas aplicaciones y posibilidades para
un sistema de IoT aparecerán en los próximos años. Al construir una red
IoT, debe asegurarse de mantener el sistema abierto para la posibilidad
de nuevos objetos inteligentes y más tráfico en el sistema.
GESTIÓN DE DATOS DE IOT Y PILA DE COMPUTO
Uno de los mensajes clave en los dos primeros capítulos de este libro es
que la escala masiva de las redes IoT está impulsando
fundamentalmente nuevas arquitecturas. Por ejemplo, la Figura 1-2 en
el Capítulo 1 ilustra cómo las "cosas" conectadas a Internet continúan
creciendo exponencialmente, con una predicción de Cisco de que para
2020 habrá más de 50 mil millones de dispositivos conectados a algún
tipo de red IP. . Claramente, las redes de TI tradicionales no están
preparadas para esta magnitud de dispositivos de red. Sin embargo, más
allá de la propia arquitectura de red, considere los datos que generan
estos dispositivos. Si la cantidad de dispositivos supera los números
convencionales, seguramente los datos generados por estos dispositivos
también deben ser motivo de gran preocupación.
De hecho, los datos generados por los sensores IoT son uno de los
desafíos más importantes en la construcción de un sistema IoT. En el
caso de las redes de TI modernas, los datos obtenidos de una
computadora o servidor generalmente se generan mediante el modelo
de comunicaciones cliente / servidor, y satisfacen las necesidades de la
aplicación. En las redes de sensores, la gran mayoría de los datos
generados no están estructurados y tienen muy poco uso por sí solos. Por
ejemplo, la mayoría de los datos generados por un medidor inteligente
no son más que datos de sondeo; el sistema de comunicaciones
simplemente determina si una conexión de red al medidor todavía está
activa. Esta información en sí misma tiene muy poco valor. El valor real
de un medidor inteligente es la información de medición leída por el
sistema de administración del medidor (MMS). Sin embargo, si nos
fijamos en los datos de sondeo sin procesar desde una perspectiva
diferente, la información puede ser muy útil.Por ejemplo, una utilidad
puede tener millones de metros cubriendo toda su área de servicio. Si
secciones enteras de la red inteligente comienzan a mostrar una
interrupción de la conectividad a los medidores, estos datos pueden
analizarse y combinarse con otras fuentes de datos, como los informes
meteorológicos y la demanda eléctrica en la red, para proporcionar una
imagen completa de lo que es sucediendo. Esta información puede
ayudar a determinar si la pérdida de conexión a los medidores es
realmente una pérdida de potencia o si se ha desarrollado algún otro
problema en la red. Por otra parte, el análisis de estos datos puedecomo
los informes meteorológicos y la demanda eléctrica en la red, para
proporcionar una imagen completa de lo que está sucediendo. Esta
información puede ayudar a determinar si la pérdida de conexión a los
medidores es realmente una pérdida de potencia o si se ha desarrollado
algún otro problema en la red. Por otra parte, el análisis de estos datos
puedecomo los informes meteorológicos y la demanda eléctrica en la red,
para proporcionar una imagen completa de lo que está sucediendo. Esta
información puede ayudar a determinar si la pérdida de conexión a los
medidores es realmente una pérdida de potencia o si se ha desarrollado
algún otro problema en la red. Por otra parte, el análisis de estos datos
puedeayude a la empresa a determinar rápidamente el alcance de la
interrupción del servicio y reparar la interrupción de manera oportuna.
En la mayoría de los casos, la ubicación de procesamiento está fuera del
objeto inteligente. Una ubicación natural para esta actividad de
procesamiento es la nube. Los objetos inteligentes deben conectarse a la
nube y el procesamiento de datos está centralizado. Una ventaja de este
modelo es la simplicidad. Los objetos solo necesitan conectarse a una
aplicación de nube central. Esa aplicación tiene visibilidad sobre todos
los nodos de IoT y puede procesar todos los análisis necesarios hoy y en
el futuro.
Sin embargo, este modelo también tiene limitaciones. A medida que
aumenta el volumen de datos, la variedad de objetos que se conectan a
la red y la necesidad de una mayor eficiencia, aparecen nuevos
requisitos, y esos requisitos tienden a acercar la necesidad del análisis
de datos al sistema IoT. Estos nuevos requisitos incluyen lo siguiente:
Minimización de la latencia: los milisegundos son importantes para
muchos tipos de sistemas industriales, como cuando intenta evitar
paradas en la línea de producción o restaurar el servicio eléctrico. El
análisis de datos cerca del dispositivo que recopiló los datos puede
marcar la diferencia entre evitar el desastre y una falla del sistema en
cascada.
Conservación del ancho de banda de la red: las plataformas petrolíferas
marinas generan 500 GB de datos semanalmente. Los aviones
comerciales generan 10 TB por cada 30 minutos de vuelo. No es práctico
transportar grandes cantidades de datos de miles o cientos de miles de
dispositivos de borde a la nube. Tampoco es necesario porque muchos
análisis críticos no requieren el procesamiento y almacenamiento a
escala de nube.
Aumento de la eficiencia local: recopilar y asegurar datos en una amplia
área geográfica con diferentes condiciones ambientales puede no ser
útil. Las condiciones ambientales en un área desencadenarán una
respuesta local independiente de las condiciones de otro sitio a cientos
de millas de distancia. Analizar ambas áreas en el mismo sistema de
nube puede no ser necesario para una eficiencia inmediata.
Una consideración de diseño importante, por lo tanto, es cómo diseñar
una red IoT para administrar este volumen de datos de una manera
eficiente, de modo que los datos puedan analizarse rápidamente y
generar beneficios comerciales. El volumen de datos generados por
dispositivos IoT puede ser tan grande que puede sobrepasar fácilmente
las capacidades del sistema headend en el centro de datos o la nube. Por
ejemplo, se ha observado que una red de medidores inteligentes de
tamaño moderado de 1 millón de metros generará cerca de mil millones
de puntos de datos por día (incluidas lecturas de medidores y otros datos
de instrumentación), lo que generará 1 TB de datos. Para una
organización de TI que no está preparada para lidiar con este volumen
de almacenamiento de datos y análisis en tiempo real, esto crea un
desafío completamente nuevo.
El volumen de datos también introduce preguntas sobre la
administración del ancho de banda. A medida que la cantidad masiva de
datos de IoT comienza a canalizarse hacia el centro de datos, ¿la red tiene
la capacidad de mantener este volumen de tráfico? ¿El servidor de
aplicaciones tiene la capacidad de ingerir, almacenar y analizar la gran
cantidad de datos que ingresan? Esto a veces se denomina "falta de
coincidencia de impedancia" de los datos generados por el sistema de
IoT y la capacidad de la aplicación de gestión para tratar con esos datos.
Como se ilustra en la Figura 2-14, la administración de datos en sistemas
de TI tradicionales es muy simple. Los puntos finales (laptops,
impresoras, teléfonos IP, etc.) se comunican a través de una red central
de IP a los servidores en el centro de datos o en la nube. Los datos
generalmente se almacenan en el centro de datos, y los enlaces físicos
desde el acceso al núcleo son típicamente de gran ancho de banda, lo que
significa que el acceso a los datos de TI es rápido.

estación. Sin embargo, las implementaciones prácticas a menudo son

flexibles, con múltiples rutas de comunicación transversales. Por
ejemplo, considere el caso de IoT para la red de energía. Su casa puede
tener un medidor que informa el consumo de energía a una puerta de
enlace a través de una tecnología inalámbrica. Otras casas en su
vecindario (NAN) hacen el mismo informe, probablemente a una o
varias puertas de enlace. Los datos que se transportan son pequeños y el
intervalo es grande (por ejemplo, cuatro veces por hora), lo que da como
resultado un tipo de estructura de datos de baja movilidad y bajo
rendimiento, con distancias de transmisión de hasta una milla. Se
pueden usar varias tecnologías (como 802.11ah, 802.15.4 o LPWA) para
este segmento de recopilación. Otros vecindarios también pueden
conectarse de la misma manera, formando así un VENTILADOR.
Por ejemplo, el servidor de aplicación de cabecera de la utilidad de
energía puede ser regional, y la puerta de enlace puede retransmitirse a
una tecnología de backhaul cableada o inalámbrica. La estructura parece
ser jerárquica. Prácticamente, sin embargo, este sistema de IoT puede
lograr más que un informe básico inicial. Si su consumo de energía es
anormalmente alta, el servidor de aplicaciones cabecera utilidad puede
necesitar a la carta informando desde el medidor a intervalos cortos de
seguir la tendencia del consumo. A partir de un modelo de inserción
vertical estándar, la estructura de transporte cambia y se vuelve
bidireccional (modelo de extracción en sentido descendente en lugar de
empuje ascendente).
La automatización de la distribución (DA) también permite que su
medidor se comunique con medidores vecinos u otros dispositivos en la
red de distribución eléctrica. Con tal comunicación, el equilibrio de carga
de consumo puede optimizarse. Por ejemplo, su aire acondicionado
impulsa aire fresco a intervalos regulares. Con DA, la CA de tu vecino
comienza a pulsar cuando el sistema hace una pausa; de esta manera, el
aire en ambas casas se mantiene fresco, pero la energía consumida por
la red es estable en lugar de subir y bajar con puntos de inicio y parada
descoordinados. Aquí nuevamente, el modelo de transporte cambia.
Desde una estructura vertical, ahora está cambiando a una posible
estructura de malla con múltiples intercambios de igual a igual.
Del mismo modo, su medidor inteligente puede comunicarse con los
electrodomésticos para evaluar su tipo y la demanda de energía. Con este
esquema, su lavadora puede encenderse en momentos de menor
consumo de otros sistemas, como por la noche, mientras que la energía
de su sistema de teatro en casa nunca se verá privada, siempre encendido
cuando lo necesite. Una vez que el sistema aprende su patrón de
consumo, la carga de su automóvil eléctrico puede comenzar y detenerse
a intervalos para lograr la misma carga durante la noche sin crear picos
en la demanda de energía. Cuando aparecen estas funciones, el modelo
de transporte cambia de nuevo. Un sistema de malla puede aparecer en
la escala de la casa. Más comúnmente, aparece una malla parcial, con
algunos nodos centrales que se conectan a otros muchos nodos. Los
datos pueden fluir localmenteo puede tener que ser orquestado por una
aplicación central para coordinar el presupuesto de energía entre las
casas.
En este sistema inteligente, el sistema de carga de su automóvil está
conectado a su cuenta de energía. A medida que se conecta a una
estación de carga pública, su auto inicia sesión en el sistema para
identificarse y vincularse de manera única a su cuenta. A intervalos
regulares, el sistema central puede necesitar consultar todas las
estaciones de carga para la actualización del estado. La estructura de
transporte pierde su organización vertical un poco más en este modelo,
ya que puede conectarse desde cualquier lugar. En un entorno
administrado, el sistema de cabecera necesita actualizar el software en
su medidor, al igual que los proveedores de dispositivos pueden
necesitar actualizar el software de energía inteligente de su horno o
lavadora. A partir de un flujo de transporte de datos ascendente, ahora
implementa flujos de datos descendentes.
Por lo tanto, esta estructura de comunicación puede implicar punto a
punto (por ejemplo, metro a metro), punto a punto (metro a estación de
cabecera), punto a multipunto (puerta de enlace o extremo a varios
metros), unidifusión y comunicaciones de multidifusión (actualización
de software para uno o múltiples sistemas). En un entorno multiusuario
(por ejemplo, administración de consumo de electricidad y gas),
diferentes sistemas pueden usar las mismas vías de comunicación. Esta
comunicación ocurre a través de múltiples medios (por ejemplo, líneas
eléctricas dentro de su hogar o un sistema inalámbrico de corto alcance
como Wi-Fi interior y / o ZigBee), un sistema inalámbrico de mayor
alcance a la puerta de enlace y otro medio inalámbrico o cableado para
transmisión de retroceso
Para permitir dicha estructura de comunicación, es necesario
implementar un protocolo de red con características específicas. El
protocolo debe ser abierto y estar basado en estándares para adaptarse
a múltiples industrias y múltiples medios. La escalabilidad (para
acomodar miles o millones de sensores en una sola red) y la seguridad
también son requisitos comunes. IP es un protocolo que coincide con
todos estos requisitos. Las ventajas de la propiedad intelectual se tratan
en profundidad en el Capítulo 5 .
La flexibilidad de IP permite que este protocolo se integre en objetos de
naturalezas muy diferentes, intercambiando información a través de
medios muy diferentes, incluidas redes de baja potencia, con pérdida y
de bajo ancho de banda. Por ejemplo, RFC 2464 describe cómo un
paquete IPv6 se encapsula en un marco Ethernet y también se utiliza
para Wi-Fi IEEE 802.11. De forma similar, el grupo de trabajo IETF
6LoWPAN especifica cómo los paquetes IPv6 se transportan de manera
eficiente a través de redes con pérdida, formando una "capa de
adaptación" para IPv6, principalmente para redes IoT. El Capítulo
4 proporciona más detalles sobre 6LoWPAN y sus capacidades.
Finalmente, los protocolos de capa de transporte construidos sobre IP
(UDP y TCP) pueden aprovecharse fácilmente para decidir si la red debe
controlar la entrega del paquete de datos (con TCP) o si la tarea de
control debe dejarse a la aplicación (UDP). UDP es un protocolo mucho
más ligero y más rápido que TCP. Sin embargo, no garantiza la entrega
de paquetes. Tanto TCP como UDP pueden protegerse con TLS / SSL
(TCP) o DTLS (UDP). Capítulo 6 echa un vistazo más de cerca a TCP y
UDP para redes IoT.

Subcapa de gestión de red IoT

IP, TCP y UDP brindan conectividad a las redes de IoT. Los protocolos
de capa superior deben encargarse de la transmisión de datos entre los
objetos inteligentes y otros sistemas. Se han aprovechado
o creado múltiples protocolos para resolver problemas de comunicación
de datos de IoT. Algunas redes dependen de un modelo de inserción (es
decir, un sensor informa a intervalos regulares o de un activador local),
mientras que otras dependen de un modelo de extracción (es decir, una
aplicación consulta el sensor a través de la red) y múltiples híbridos
enfoques también son posibles.
Siguiendo la lógica de IP, algunos implementadores de IoT han sugerido
HTTP para la fase de transferencia de datos. Después de todo, HTTP
tiene un componente de cliente y servidor. El sensor podría usar la parte
del cliente para establecer una conexión con la aplicación central de IoT
(el servidor), y luego se pueden intercambiar datos. Puede encontrar
HTTP en algunas aplicaciones de IoT, pero HTTP es algo así como un
protocolo gordo y no fue diseñado para operar en entornos restringidos
con poca memoria, baja potencia, bajo ancho de banda y una alta tasa de
falla de paquetes. A pesar de estas limitaciones, se han sugerido otros
protocolos derivados de la web para el espacio IoT. Un ejemplo es
WebSocket. WebSocket forma parte de la especificación HTML5 y
proporciona una conexión bidireccional simple a través de una única
conexión. Algunas soluciones IoT usan WebSocket para administrar la
conexión entre el objeto inteligente y una aplicación externa.WebSocket
a menudo se combina con otros protocolos, como MQTT (descrito en
breve) para manejar la parte específica de IoT de la comunicación.
Con la misma lógica de reutilización de métodos conocidos, se creó el
protocolo extensible Messaging and Presence Protocol (XMPP). XMPP
se basa en mensajería instantánea y presencia. Permite el intercambio
de datos entre dos o más sistemas y admite el mantenimiento de la
presencia y la lista de contactos. También puede manejar publicar /
suscribir, por lo que es una buena opción para la distribución de
información a múltiples dispositivos. Una limitación de XMPP es su
dependencia de TCP, que puede obligar a los suscriptores a mantener
sesiones abiertas a otros sistemas y puede ser una limitación para
objetos con memoria limitada.
Para responder a los límites de los protocolos web, otro protocolo fue
creado por el grupo de trabajo Entornos restringidos restringidos
(CoRE) de IETF: Protocolo de aplicación restringida (CoP). CoAP utiliza
algunos métodos similares a los de HTTP (como Get, Post, Put y Delete)
pero implementa una lista más corta, lo que limita el tamaño del
encabezado. CoAP también se ejecuta en UDP (mientras que HTTP
generalmente usa TCP). CoAP también agrega una característica que
falta en HTTP y muy útil para IoT: observación. La observación permite
la transmisión de cambios de estado a medida que ocurren, sin que el
receptor tenga que consultar estos cambios.
Otro protocolo común de IoT utilizado en estas capas intermedias y
superiores es Message Queue Telemetry Transport (MQTT). MQTT usa
una arquitectura basada en intermediarios. El sensor se puede
configurar para que sea un editor MQTT (publica una información), la
aplicación que necesita recibir la información se puede establecer como
el suscriptor MQTT, y cualquier sistema intermediario se puede
configurar como un intermediario para transmitir la información entre
el editor y el (los) suscriptor (es). MQTT se ejecuta sobre TCP. Una
consecuencia de la dependencia de TCP es que un cliente MQTT
generalmente mantiene una conexión abierta al intermediario en todo
momento. Esto puede ser un factor limitante en entornos donde la
pérdida es alta o donde los recursos informáticos son limitados.
Capítulo 6 examina con más detalle los diversos protocolos de
aplicación de IoT, incluidos CoAP y MQTT. Desde el punto de vista
arquitectónico, debe determinar los requisitos de su protocolo de
aplicación. Confiar en TCP implica mantener sesiones entre puntos
finales. La ventaja de la confiabilidad viene con el costo de la memoria y
los recursos de procesamiento consumidos para el conocimiento de la
sesión. Depender de UDP delega el control en las capas
superiores. También necesita determinar los requisitos de QoS con
diferentes niveles de prioridad entre los diversos mensajes. Finalmente,
debe evaluar la seguridad del protocolo de la aplicación IoT para
equilibrar el nivel de seguridad proporcionado con los gastos generales
requeridos. El Capítulo 8 describe cómo evaluar el aspecto de seguridad
de las redes IoT.

Capa 3: Aplicaciones y capa de análisis

Una vez conectado a una red, sus objetos inteligentes intercambian
información con otros sistemas. Tan pronto como su red IoT abarque
más que unos pocos sensores, la potencia de Internet of Things aparece
en las aplicaciones que hacen uso de la información intercambiada con
los objetos inteligentes.

Aplicaciones de análisis versus control

Múltiples aplicaciones pueden ayudar a aumentar la eficiencia de una
red IoT. Cada aplicación recopila datos y proporciona una gama de
funciones basadas en el análisis de los datos recopilados. Puede ser
difícil comparar las características ofrecidas. El Capítulo 7 , " Datos y
análisis para IoT ", proporciona un análisis en profundidad de las
diversas familias de aplicaciones. Desde el punto de vista arquitectónico,
una clasificación básica puede ser la siguiente:
Aplicación de análisis: este tipo de aplicación recopila datos de
múltiples objetos inteligentes, procesa los datos recopilados y muestra
información resultante de los datos que se procesaron. La pantalla
puede referirse a cualquier aspecto de la red IoT, desde informes
históricos, estadísticas o tendencias hasta estados del sistema
individuales. El aspecto importante es que la aplicación procesa los datos
para transmitir una vista de la red que no se puede obtener simplemente
mirando la información que muestra un solo objeto inteligente.
Aplicación de control: este tipo de aplicación controla el
comportamiento del objeto inteligente o el comportamiento de un objeto
relacionado con el objeto inteligente. Por ejemplo, un sensor de presión
se puede conectar a una bomba. Una aplicación de control aumenta la
velocidad de la bomba cuando el sensor conectado detecta una caída en
la presión. Las aplicaciones de control son muy útiles para controlar
aspectos complejos de una red IoT con una lógica que no se puede
programar dentro de un único objeto IoT, ya sea porque los cambios
configurados son demasiado complejos para adaptarse al sistema local o
porque los cambios configurados dependen de parámetros que incluyen
elementos fuera del objeto IoT.
Un ejemplo de arquitectura de sistema de control es SCADA. SCADA fue
desarrollado como un método universal para acceder a sistemas remotos
y enviar instrucciones. Un ejemplo en el que SCADA se utiliza
ampliamente es en el control y la supervisión de unidades terminales
remotas (RTU) en la red de distribución eléctrica.
Muchas aplicaciones avanzadas de IoT incluyen tanto análisis como
módulos de control. En la mayoría de los casos, los datos se recopilan de
los objetos inteligentes y se procesan en el módulo de análisis. El
resultado de este procesamiento se puede usar para modificar el
comportamiento de los objetos inteligentes o sistemas relacionados con
los objetos inteligentes. El módulo de control se utiliza para transmitir
las instrucciones de cambios de comportamiento. Al evaluar una
aplicación de datos y análisis de IoT, debe determinar la profundidad
relativa de la parte de control necesaria para su caso de uso y compararla
con el tipo de análisis provisto.

Datos versus análisis de red

Analytics es un término general que describe el procesamiento de
información para dar sentido a los datos recopilados. En el mundo de
IoT, una posible clasificación de la función de análisis es la siguiente:
Análisis de datos: este tipo de análisis procesa los datos recopilados
por objetos inteligentes y los combina para proporcionar una vista
inteligente relacionada con el sistema IoT. En un nivel muy básico, un
tablero de instrumentos puede mostrar una alarma cuando un sensor de
peso detecta que un estante está vacío en una tienda. En un caso más
complejo, temperatura, presión, viento, humedad y niveles de
luz recolectados de miles de sensores pueden combinarse y luego
procesarse para determinar la probabilidad de una tormenta y su posible
camino. En este caso, el procesamiento de datos puede ser muy complejo
y puede combinar múltiples valores cambiantes sobre algoritmos
complejos. El análisis de datos también puede monitorear el sistema de
IoT en sí mismo. Por ejemplo, una máquina o robot en una fábrica puede
informar datos sobre sus propios movimientos. Esta información puede
ser utilizada por una aplicación de análisis para informar la degradación
en las velocidades de movimiento, lo que puede indicar la necesidad de
dar servicio al robot antes de que se rompa una pieza.
Análisis de red: la mayoría de los sistemas IoT se basan en objetos
inteligentes conectados a la red. Una pérdida o degradación en la
conectividad es probable que afecte la eficiencia del sistema. Tal pérdida
puede tener efectos dramáticos. Por ejemplo, las minas abiertas usan
redes inalámbricas para pilotear automáticamente camiones de volteo.
Una pérdida duradera de conectividad puede ocasionar un accidente o
una degradación de la eficiencia de las operaciones (los camiones
volquete automáticos suelen detenerse por la pérdida de conectividad).
En una escala menor, la pérdida de conectividad significa que los datos
dejan de alimentar su plataforma de análisis de datos y el sistema deja
de realizar análisis inteligentes del sistema de IoT. Una consecuencia
similar es que el módulo de control ya no puede modificar el
comportamiento de los objetos locales.
La mayoría de las aplicaciones analíticas emplean módulos de análisis
de datos y de red. Al diseñar un sistema de IoT, debe evaluar la necesidad
de cada uno. El análisis de red es necesario para los sistemas conectados.
Sin embargo, la profundidad del análisis depende de sus casos de uso.
Una vista de conectividad básica puede ser suficiente si los objetos
inteligentes informan un estado ocasional, sin expectativa de acción
inmediata basada en este informe. Se necesitan análisis detallados y
tendencias sobre el rendimiento de la red si se espera que la aplicación
central piloto en sistemas conectados casi en tiempo real.
El análisis de datos es un espacio más amplio con un área gris más
grande (en términos de necesidades) que el análisis de red. Los análisis
de sistemas básicos pueden proporcionar vistas del estado del sistema y
del análisis de tendencias del estado. Los sistemas más avanzados
pueden refinar el tipo de datos recopilados y mostrar información
adicional sobre el sistema. El tipo de datos y procesos recopilados varía
ampliamente con el caso de uso.

Data Analytics Versus Business Benefits

El análisis de datos es sin duda un campo donde el valor de IoT está en
auge. Se puede conectar casi cualquier objeto y se pueden
instalar múltiples tipos de sensores en un objeto determinado. La
recopilación e interpretación de los datos generados por estos
dispositivos es donde se realiza el valor de IoT.
Desde un punto de vista arquitectónico, puede definir redes de IoT
estáticas donde se determina una lista clara de elementos para
monitorear y analizar. Dichos sistemas estáticos son comunes en
entornos industriales en los que la Carta Io trata de proporcionar una
visión clara del estado de la operación. Sin embargo, una opción
arquitectónica más inteligente puede ser permitir un sistema abierto en
el que la red esté diseñada para ser lo suficientemente flexible como para
que otros sensores puedan agregarse en el futuro, y donde se permitan
tanto las operaciones ascendentes como descendentes. Esta flexibilidad
permite el procesamiento adicional de los sensores existentes y también
una interacción más profunda y más eficiente con los objetos
conectados. Este procesamiento de datos mejorado puede generar un
nuevo valor agregado para las empresas que no están previstas en el
momento en que el sistema se implementó inicialmente.
Un ejemplo de una aplicación de análisis y control flexible es Cisco
Jasper, que proporciona una plataforma llave en mano para la
administración y monetización de IoT. Considere el caso de las
máquinas expendedoras desplegadas en toda la ciudad. En un nivel
básico, estas máquinas se pueden conectar, y los sensores se pueden
implementar para informar cuando una máquina está en un estado de
error. Se puede enviar una persona de reparación para abordar el
problema cuando se identifica dicho estado. Este tipo de alerta es un
ahorro de tiempo y evita la necesidad de que el equipo de reparación
recorra todas las máquinas alternadamente cuando solo una puede estar
funcionando mal.
Este sistema de alerta también puede evitar el retraso entre el momento
en que una máquina entra en el estado de error y el momento en que un
equipo de reparación visita la ubicación de la máquina. Con una
plataforma estática, este caso de uso está limitado a este tipo de
alerta. Con una plataforma flexible como Cisco Jasper, se pueden
imaginar y desarrollar nuevas aplicaciones a lo largo del tiempo. Por
ejemplo, el los sensores de la máquina se pueden mejorar para
informar también cuando se vende un artículo. La aplicación central se
puede mejorar para procesar esta información y analizar qué elemento
se vende más, en qué ubicación y en qué momentos. Esta nueva vista de
las máquinas puede permitir una optimización de los artículos para
vender en máquinas en un área determinada. Se pueden implementar
sistemas para adaptar los bienes a la hora, la temporada o la ubicación,
o muchos otros parámetros que pueden haberse analizado. En resumen,
la arquitectura de sistemas abiertos abre la posibilidad de nuevas
aplicaciones.

Servicios inteligentes
La capacidad de usar IoT para mejorar las operaciones a menudo se
denomina "servicios inteligentes". Este término es genérico, y en
muchos casos se usa el término, pero su significado a menudo se amplía
para incluir una forma de servicio u otro donde se requiere un nivel
adicional de inteligencia. previsto.
Fundamentalmente, los servicios inteligentes usan IoT y apuntan a la
eficiencia. Por ejemplo, se pueden instalar sensores en el equipo para
garantizar el cumplimiento continuo de las normativas o los requisitos
de seguridad. Este ángulo de eficiencia puede tomar múltiples formas,
desde sensores de presencia en áreas peligrosas hasta detectores de
violación de umbral de peso en camiones.
Los servicios inteligentes también se pueden usar para medir la
eficiencia de las máquinas detectando la salida de la máquina, la
velocidad u otras formas de evaluación de uso. Se pueden optimizar
todas las operaciones con IoT. En hospitalidad, por ejemplo, los sensores
de presencia y movimiento pueden evaluar el número de invitados en un
lobby y redirigir al personal en consecuencia. El mismo tipo de acción se
puede tomar en una tienda donde se detecta que un cliente se queda más
tiempo que la cantidad de tiempo típica frente a un estante. El personal
puede ser desplegado para proporcionar asistencia. Se puede analizar el
movimiento de personas y objetos en las plantas de las fábricas para
optimizar el flujo de producción.
Los servicios inteligentes se pueden integrar en un sistema de IoT. Por
ejemplo, los sensores pueden integrarse en una bombilla. Un sensor
puede encender o apagar una luz según la presencia de un humano en la
habitación. Un sistema incluso más inteligente puede comunicarse con
otros sistemas en la casa, aprender el patrón de movimiento humano y
anticipar la presencia de un ser humano, encender la luz justo antes de
que la persona entre en la habitación. Un sistema incluso más inteligente
puede usar sensores más inteligentes que analizan múltiples parámetros
para detectar el estado de ánimo humano y modificar consecuentemente
el color de la luz para adaptarse a las preferencias aprendidas, o para
transmitir un entorno más relajante o más dinámico.
Las bombillas son un simple ejemplo. Al conectarse a otros sistemas en
la casa, las eficiencias se pueden coordinar. Por ejemplo, el sistema de
alarma de entrada a la casa o el sistema de calefacción pueden
coordinarse con el detector de presencia en una bombilla para adaptarse
a los cambios detectados. El sistema de alarma puede desactivar las
alarmas de movimiento volumétrico en las zonas donde se detecta una
persona conocida. El sistema de calefacción puede adaptar la
temperatura a la presencia humana o detectar preferencias personales.
Una eficiencia similar se puede extender a sistemas más grandes que una
casa. Por ejemplo, las aplicaciones de red inteligente pueden coordinar
el consumo de energía entre las casas para regular la demanda de energía
de la red. Ya mencionamos que su lavadora puede encenderse por la
noche cuando la demanda de energía para calefacción y refrigeración es
menor. Así como los pulsos de su aire acondicionado se pueden
coordinar con los de su vecino, los ciclos de su lavadora pueden
coordinarse con los electrodomésticos de su casa y del vecindario para
suavizar los picos de demanda de energía en la red.
La eficiencia también se aplica a las comunicaciones M2M. En entornos
de minería, los vehículos pueden comunicarse para regular los flujos
entre taladros, dragalinas, excavadoras y volquetes, por ejemplo,
asegurándose de que un camión volquete esté siempre disponible
cuando un bulldozer lo necesita. En las ciudades inteligentes, los
vehículos se comunican. El transporte público detecta y anticipa
automáticamente un atasco y el sistema puede redireccionar
temporalmente los autobuses o regular el número de autobuses que
atienden una línea específica en función del tráfico y la cantidad de
clientes, instantáneos o aprendidos sobre la tendencia.
La Parte III de este libro proporciona ejemplos detallados de cómo IoT
está dando forma a industrias específicas. Las lecciones aprendidas son
siempre que la arquitectura de sistemas abiertos de IoT permite una
mayor eficiencia en el tiempo. Nuevas aplicaciones y posibilidades para
un sistema de IoT aparecerán en los próximos años. Al construir una red
IoT, debe asegurarse de mantener el sistema abierto para la posibilidad
de nuevos objetos inteligentes y más tráfico en el sistema.

GESTIÓN DE DATOS DE IOT Y PILA DE

COMPUTO
Uno de los mensajes clave en los dos primeros capítulos de este libro es
que la escala masiva de las redes IoT está impulsando
fundamentalmente nuevas arquitecturas. Por ejemplo, Figura 1-
2 en El Capítulo 1 ilustra cómo las "cosas" conectadas a Internet
continúan creciendo exponencialmente, con una predicción de Cisco de
que para 2020 habrá más de 50 mil millones de dispositivos conectados
a alguna forma de red IP. Claramente, las redes de TI tradicionales no
están preparadas para esta magnitud de dispositivos de red. Sin
embargo, más allá de la propia arquitectura de red, considere los datos
que generan estos dispositivos. Si la cantidad de dispositivos supera los
números convencionales, seguramente los datos generados por estos
dispositivos también deben ser motivo de gran preocupación.
De hecho, los datos generados por los sensores IoT son uno de los
desafíos más importantes en la construcción de un sistema IoT. En el
caso de las redes de TI modernas, los datos que se obtienen de una
computadora o servidor normalmente se generan modelo de
comunicaciones cliente / servidor, y satisface las necesidades de la
aplicación. En las redes de sensores, la gran mayoría de los datos
generados no están estructurados y tienen muy poco uso por sí solos. Por
ejemplo, la mayoría de los datos generados por un medidor inteligente
no son más que datos de sondeo; el sistema de comunicaciones
simplemente determina si una conexión de red al medidor todavía está
activa. Esta información en sí misma tiene muy poco valor. El valor real
de un medidor inteligente es la información de medición leída por el
sistema de administración del medidor (MMS). Sin embargo, si nos
fijamos en los datos de sondeo sin procesar desde una perspectiva
diferente, la información puede ser muy útil. Por ejemplo, una utilidad
puede tener millones de metros cubriendo toda su área de servicio. Si
secciones enteras de la red inteligente comienzan a mostrar una
interrupción de la conectividad a los medidores,estos datos se pueden
analizar y combinar con otras fuentes de datos, como los informes
meteorológicos y la demanda eléctrica en la red, para proporcionar una
imagen completa de lo que está sucediendo. Esta información puede
ayudar a determinar si la pérdida de conexión a los medidores es
realmente una pérdida de potencia o si se ha desarrollado algún otro
problema en la red. Además, el análisis de estos datos puede ayudar a la
empresa a determinar rápidamente el alcance de la interrupción del
servicio y reparar la interrupción de manera oportuna.El análisis de
estos datos puede ayudar a la empresa a determinar rápidamente el
alcance de la interrupción del servicio y reparar la interrupción de
manera oportuna.El análisis de estos datos puede ayudar a la empresa a
determinar rápidamente el alcance de la interrupción del servicio y
reparar la interrupción de manera oportuna.
En la mayoría de los casos, la ubicación de procesamiento está fuera del
objeto inteligente. Una ubicación natural para esta actividad de
procesamiento es la nube. Los objetos inteligentes deben conectarse a la
nube y el procesamiento de datos está centralizado. Una ventaja de este
modelo es la simplicidad. Los objetos solo necesitan conectarse a una
aplicación de nube central. Esa aplicación tiene visibilidad sobre todos
los nodos de IoT y puede procesar todos los análisis necesarios hoy y en
el futuro.
Sin embargo, este modelo también tiene limitaciones. A medida que
aumenta el volumen de datos, la variedad de objetos que se conectan a
la red y la necesidad de una mayor eficiencia, aparecen nuevos
requisitos, y esos requisitos tienden a acercar la necesidad del análisis
de datos al sistema IoT. Estos nuevos requisitos incluyen lo siguiente:
Minimización de la latencia: los milisegundos son importantes
para muchos tipos de sistemas industriales, como cuando intenta evitar
paradas en la línea de producción o restaurar el servicio eléctrico. El
análisis de datos cerca del dispositivo que recopiló los datos puede
marcar la diferencia entre evitar el desastre y una falla del sistema en
cascada.
Conservación del ancho de banda de la red: las plataformas
petrolíferas marinas generan 500 GB de datos semanalmente. Los
aviones comerciales generan 10 TB por cada 30 minutos de vuelo. No es
práctico transportar grandes cantidades de datos de miles o cientos de
miles de dispositivos de borde a la nube. Tampoco es necesario porque
muchos análisis críticos no requieren el procesamiento y
almacenamiento a escala de nube.
Aumento de la eficiencia local: recopilar y asegurar datos en una
amplia área geográfica con diferentes condiciones ambientales puede no
ser útil. Las condiciones ambientales en un área desencadenarán una
respuesta local independiente de las condiciones de otro sitio a cientos
de millas de distancia. Analizar ambas áreas en el mismo sistema de
nube puede no ser necesario para una eficiencia inmediata.
Una consideración de diseño importante, por lo tanto, es cómo diseñar
una red IoT para administrar este volumen de datos de una manera
eficiente, de modo que los datos puedan analizarse rápidamente y
generar beneficios comerciales. El volumen de datos generados por
dispositivos IoT puede ser tan grande que puede sobrepasar fácilmente
las capacidades del sistema de cabecera en el centro de datos o en la
nube. Por ejemplo, se ha observado que una red de medidores
inteligentes de tamaño moderado de 1 millón de metros generará cerca
de mil millones de puntos de datos por día (incluidas lecturas de
medidores y otros datos de instrumentación), lo que generará 1 TB de
datos. Para una organización de TI que no está preparada para lidiar con
este volumen de almacenamiento de datos y análisis en tiempo real, esto
crea un desafío completamente nuevo.
El volumen de datos también introduce preguntas sobre la
administración del ancho de banda. A medida que la cantidad masiva de
datos de IoT comienza a canalizarse hacia el centro de datos, ¿la red tiene
la capacidad de mantener este volumen de tráfico? ¿El servidor de
aplicaciones tiene la capacidad de ingerir, almacenar y analizar la gran
cantidad de datos que ingresan? Esto a veces se denomina "falta de
coincidencia de impedancia" de los datos generados por el sistema de
IoT y la capacidad de la aplicación de gestión para tratar con esos datos.
Como se ilustra en la Figura 2-14 , la administración de datos en
sistemas de TI tradicionales es muy simple. Los puntos finales (laptops,
impresoras, teléfonos IP, etc.) se comunican a través de una red central
de IP a los servidores en el centro de datos o en la nube. Los datos
generalmente se almacenan en el centro de datos, y los enlaces físicos
desde el acceso al núcleo son típicamente de gran ancho de banda, lo que
significa que el acceso a los datos de TI es rápido.
Los sistemas de IoT funcionan de manera diferente. Varios problemas
relacionados con los datos deben abordarse:
El ancho de banda en las redes de IoT de última milla es muy
limitado. Cuando se trata de miles / millones de dispositivos, el ancho
de banda disponible puede estar en orden de decenas de Kbps por
dispositivo o incluso menos.
 La latencia puede ser muy alta. En lugar de ocuparse de la latencia en
el rango de milisegundos, las redes de IoT grandes a menudo introducen
latencia de cientos a miles de milisegundos.
La red de retorno desde la puerta de enlace puede ser poco fiable y, a
menudo, depende de 3G / LTE o incluso enlaces satelitales. Los enlaces
backhaul también pueden ser costosos si es necesario un modelo de uso
de datos por byte.
El volumen de datos transmitidos a través de la red de retorno puede
ser alto, y gran parte de los datos pueden no ser tan interesantes (como
los simples mensajes de sondeo).
Big Data es cada vez más grande. El concepto de almacenar y analizar
todos los datos del sensor en la nube no es práctico. El gran volumen de
datos generados hace que el análisis en tiempo real y la respuesta a los
datos sean casi imposibles.

Computación de Niebla
La solución a los desafíos mencionados en la sección anterior es
distribuir la administración de datos en todo el sistema IoT, lo más cerca
posible del borde de la red IP. La realización más conocida de los
servicios de borde en IoT es la computación de niebla. Cualquier
dispositivo con computación, almacenamiento y conectividad de red
puede ser un nodo de niebla. Los ejemplos incluyen controladores
industriales, conmutadores, enrutadores, servidores integrados y
puertas de enlace IoT. El análisis de los datos de IoT cerca de donde se
recopila minimiza la latencia, descarga gigabytes del tráfico de red de la
red central y mantiene los datos confidenciales dentro de la red local.
Nota
El concepto de niebla fue desarrollado primero por Flavio Bonomi y Rodolfo
Milito de Cisco Systems. En el mundo de IoT, la niebla recibe su nombre de una
comparación relativa a la computación en la capa de nubes. Así como las nubes
existen en el cielo, la niebla descansa cerca del suelo. De la misma manera, la
intención de la computación de niebla es colocar los recursos lo más cerca posible
del suelo, es decir, los dispositivos de IoT, como sea posible. Una nota interesante
es que el término "niebla" en realidad fue acuñado por Ginny Nichols, la esposa
de Rodolfo. Aunque no trabajaba directamente en IoT, tenía una comprensión
excelente de lo que su esposo estaba desarrollando y fue capaz de dibujar
rápidamente la comparación entre la computación en la nube y el borde. Un día
ella sugirió simplemente llamarlo la "capa de niebla". El nombre quedó atascado.
Una ventaja de esta estructura es que el nodo de niebla permite la
recopilación de inteligencia (como el análisis) y el control desde el punto
más cercano posible, y al hacerlo, permite un mejor rendimiento en
redes restringidas. En cierto sentido, esto introduce una nueva capa al
modelo informático de TI tradicional, que a menudo se denomina "capa
de niebla". La Figura 2-15 muestra la ubicación de la capa de niebla en la
Gestión de Datos de IoT y la Pila de Computo.
Los servicios de niebla normalmente se llevan a cabo muy cerca del
dispositivo de borde, sentados tan cerca de los puntos finales de IoT
como sea posible. Una ventaja significativa de esto es que el nodo de
niebla tiene conocimiento contextual de los sensores que está
administrando debido a su proximidad geográfica con esos sensores. Por
ejemplo, puede haber un enrutador de niebla en una torre de perforación
de petróleo que esté monitoreando toda la actividad del sensor en esa
ubicación. Porque el nodo de niebla es capaz de analizar información de
todos los sensores en esa torre de perforación, puede proporcionar un
análisis contextual de los mensajes que está recibiendo y puede decidir
enviar solo la información relevante a través de la red de retroceso a la
nube. De esta forma, está realizando análisis distribuidos de manera que
el volumen de datos enviados en sentido ascendente se reduce
considerablemente y es mucho más útil para los servidores de
aplicaciones y análisis que residen en la nube.
Además, tener conciencia contextual les da a los nodos niebla la
capacidad de reaccionar a los eventos en la red IoT mucho más
rápidamente que en el modelo informático tradicional de TI, que
probablemente incurriría en una mayor latencia y tendría tiempos de
respuesta más lentos. La capa de niebla proporciona así una capacidad
de bucle de control de borde distribuido, donde los dispositivos pueden
ser monitoreados, controlados y analizados en tiempo real sin la
necesidad de esperar la comunicación del análisis central y los servidores
de aplicaciones en la nube.
El valor de este modelo es claro. Por ejemplo, los sensores de presión de
los neumáticos en un camión grande en una mina a cielo abierto podrían
informar mediciones continuamente durante todo el día. Puede haber
solo pequeños cambios de presión que se encuentren dentro de los
límites de tolerancia, lo que hace innecesarios los informes continuos a
la nube. ¿Es realmente útil enviar continuamente esos datos a la nube a
través de una conexión de backhaul potencialmente costosa? Con un
nodo de niebla en el camión, es posible no solo medir la presión de todos
los neumáticos a la vez, sino también combinar estos datos con la
información proveniente de otros sensores en el motor, el sistema
hidráulico, etc. Con este enfoque, el nodo de niebla envía datos de alerta
aguas arriba solo si un problema real está comenzando a ocurrir en el
camión que afecta la eficiencia operacional.
La computación de niebla de IoT permite que los datos sean
preprocesados y correlacionados con otras entradas para producir
información relevante. Esta información se puede usar como
conocimiento procesable en tiempo real mediante aplicaciones
habilitadas para IoT. A más largo plazo, estos datos se pueden utilizar
para obtener una comprensión más profunda del comportamiento y los
sistemas de la red con el fin de desarrollar políticas, procesos y
respuestas proactivos.
Las aplicaciones de niebla son tan diversas como el Internet de las
Cosas. Lo que tienen en común es la reducción de datos: monitorear o
analizar datos en tiempo real de cosas conectadas a la red y luego iniciar
una acción, como cerrar una puerta, cambiar los ajustes del equipo,
aplicar los frenos en un tren, acercar o alejar una cámara de video, abrir
una válvula en respuesta a una lectura de presión, la creación de un
gráfico de barras o el envío de una alerta a un técnico para realizar una
reparación preventiva.
La característica definitoria de la computación de niebla es la siguiente:
Dominio de la ubicación contextual y baja latencia: el nodo de
niebla se encuentra lo más cerca posible del punto final de la IoT para
ofrecer computación distribuida.
Distribución geográfica: en marcado contraste con la nube más
centralizada, los servicios y aplicaciones a los que se dirigen los nodos de
niebla requieren implementaciones ampliamente distribuidas.
Despliegue cerca de los puntos finales IoT: los nodos de niebla
normalmente se implementan en presencia de una gran cantidad de
puntos finales IoT. Por ejemplo, las implementaciones de medición
típicas a menudo ven 3000 a 4000 nodos por enrutador de puerta de
enlace, que también funciona como nodo de computación de niebla.
Comunicación inalámbrica entre la niebla y el punto final
IoT: aunque es posible conectar nodos cableados, las ventajas de la
niebla son mayores cuando se trata de una gran cantidad de puntos
finales, y el acceso inalámbrico es la forma más fácil de lograr dicha
escala.
Uso para interacciones en tiempo real: las aplicaciones de
niebla importantes implican interacciones en tiempo real en lugar de
procesamiento por lotes. El preprocesamiento de datos en los nodos de
niebla permite que las aplicaciones de capa superior realicen el
procesamiento por lotes en un subconjunto de los datos.

Computación Edge
Muchos sectores están adoptando soluciones de computación en niebla,
y los esfuerzos para desarrollar aplicaciones distribuidas y herramientas
analíticas se están introduciendo a un ritmo acelerado. El lugar natural
para un nodo de neblina se encuentra en el dispositivo de red que se
encuentra más cerca de los puntos finales de IoT, y estos nodos suelen
estar distribuidos en una red IoT. Sin embargo, en los últimos años, el
concepto de cómputo IoT se ha empujado aún más al límite, y en algunos
casos ahora reside directamente en los sensores y dispositivos IoT.
Nota
La informática de borde también se denomina a veces computación "niebla". Si
existen nubes en el cielo y la niebla está cerca del suelo, entonces la niebla es lo
que realmente se sienta en el suelo. Por lo tanto, el concepto de niebla consiste
en extender la niebla hasta el punto más alejado posible, directamente en el
dispositivo de punto final de IoT.
Los dispositivos y sensores de IoT a menudo tienen recursos limitados,
sin embargo, a medida que aumentan las capacidades de cómputo.
Algunas nuevas clases de puntos finales IoT tienen capacidades
informáticas suficientes para realizar al menos análisis y filtrado de bajo
nivel para tomar decisiones básicas. Por ejemplo, considere un sensor de
agua en una boca de incendios. Mientras que un nodo de niebla sentado
en un poste eléctrico en la red de distribución puede tener una excelente
vista de todas las bocas de incendio en un vecindario local, un nodo en
cada boca de riego tendría una visión clara de una caída de presión de
agua en su propia línea y podría para generar rápidamente una alerta de
un problema localizado. El nodo de niebla, por otro lado, tendría una
vista más amplia y podría determinar si el problema estaba más que solo
localizado, pero estaba afectando a toda el área. Otro ejemplo es en el
uso de medidores inteligentes.Los medidores con capacidad
computacional Edge pueden comunicarse entre sí para compartir
información en pequeños subconjuntos de la red eléctrica de
distribución para monitorear la calidad de energía localizada y el
consumo, y pueden informar a un nodo de niebla de eventos que pueden
pertenecer solo a pequeñas secciones de la red . Modelos como estos
ayudan a garantizar la más alta calidad de entrega de energía a los
clientes.
La jerarquía de Edge, Niebla y Nube
Es importante enfatizar que la computación de borde o niebla de
ninguna manera reemplaza a la nube. Por el contrario, se complementan
entre sí, y muchos casos de uso en realidad requieren una fuerte
cooperación entre las capas. De la misma manera que los tribunales
inferiores no reemplazan a la corte suprema de un país, las capas de
computación de borde y niebla simplemente actúan como una primera
línea de defensa para filtrar, analizar y administrar puntos finales de
datos. Esto evita que la nube sea consultada por cada nodo para cada
evento.
Este modelo sugiere una organización jerárquica de recursos de
almacenamiento de datos, computación y red. En cada etapa, los datos
se recopilan, analizan y responden cuando es necesario, de acuerdo con
las capacidades de los recursos en cada capa. Como los datos deben
enviarse a la nube, la latencia aumenta. La ventaja de esta jerarquía es
que la respuesta a los eventos de los recursos cercanos al dispositivo final
es rápida y puede generar beneficios inmediatos, a la vez que se tienen
recursos informáticos más profundos disponibles en la nube cuando es
necesario.
Es importante tener en cuenta que la heterogeneidad de los dispositivos
IoT también significa una heterogeneidad de los recursos informáticos
de borde y niebla. Aunque se espera que los recursos en la nube sean
homogéneos, es justo esperar que en muchos casos los recursos de borde
y niebla utilicen diferentes sistemas operativos, tengan diferentes
capacidades de almacenamiento de datos y CPU, y tengan diferentes
perfiles de consumo de energía. El borde y la niebla requieren una capa
de abstracción que permite que las aplicaciones se comuniquen entre sí.
La capa de abstracción expone un conjunto común de API para
supervisar, aprovisionar y controlar los recursos físicos de forma
estandarizada. La capa de abstracción también requiere un mecanismo
para admitir la virtualización,con la capacidad de ejecutar múltiples
sistemas operativos o contenedores de servicio en dispositivos físicos
para admitir multipropiedad y coherencia de aplicaciones en todo el
sistema de IoT. La definición de un marco común de servicios de
comunicaciones está siendo abordada por grupos como oneM2M,
discutido anteriormente. La Figura 2-16 ilustra la naturaleza jerárquica
de la computación en el borde, la niebla y la nube en un sistema IoT.
Desde un punto de vista arquitectónico, los nodos de niebla más
cercanos al borde de la red reciben los datos de los dispositivos IoT. La
aplicación IoT de niebla luego dirige diferentes tipos de datos al lugar
óptimo para el análisis:
La mayoría de los datos sensibles al tiempo se analizan en el borde o
en el nodo de niebla más cercano a las cosas que generan los datos.
Los datos que pueden esperar segundos o minutos para la acción se
transfieren a un nodo de agregación para su análisis y acción.
Los datos que son menos sensibles al tiempo se envían a la nube para
análisis históricos, análisis de big data y almacenamiento a largo
plazo. Por ejemplo, cada uno de los miles o cientos de miles de nodos de
niebla puede enviar resúmenes periódicos de datos a la nube para su
análisis y almacenamiento histórico.
En resumen, al diseñar una red IoT, debe considerar la cantidad de datos
que se analizarán y la sensibilidad temporal de estos datos. Comprender
estos factores lo ayudará a decidir si la computación en la nube es
suficiente o si la computación de borde o niebla mejorará la eficiencia de
su sistema. La computación de niebla acelera el conocimiento y la
respuesta a los eventos al eliminar un viaje de ida y vuelta a la nube para
su análisis. Evita la necesidad de costosas adiciones de ancho de banda
mediante la descarga de gigabytes de tráfico de red desde la red central.
También protege los datos confidenciales de IoT analizándolo dentro de
las paredes de la empresa.

RESUMEN
Los requisitos de los sistemas IoT están impulsando nuevas
arquitecturas que abordan los aspectos de escala, restricciones y gestión
de datos de IoT. Para abordar estas necesidades, han surgido varios
modelos de referencia específicos de IoT, incluidos el modelo oneM2M
IoT y el modelo de referencia IoT del IoT World Forum. Las
características comunes entre estos modelos son la interacción de los
dispositivos IoT, la red que los conecta y las aplicaciones que
administran los puntos finales.
Este libro presenta un marco de IoT que utiliza aspectos de estos
diversos modelos y los aplica a casos de uso específicos de la
industria. Este capítulo presenta un modelo basado en conceptos
comunes en estas arquitecturas que rompe las capas de IoT en una
arquitectura simplificada que incorpora dos pilas paralelas: la Pila
funcional Core IoT y la Gestión de datos IoT y la Pila informática. Esta
arquitectura establece el formato para los capítulos que siguen en este
libro .
La pila funcional Core IoT tiene tres capas: los sensores y actuadores IoT,
componentes de red y aplicaciones y capas de análisis. Los componentes
de red y las capas de aplicaciones implican varias subcapas que
corresponden a diferentes partes del sistema de IoT en general.
El IoT Data Management y Compute Stack se ocupa de cómo y dónde se
filtran, agregan, almacenan y analizan los datos. En los modelos de TI
tradicionales, esto ocurre en la nube o en el centro de datos. Sin
embargo, debido a los requisitos únicos de IoT, la administración de
datos se distribuye lo más cerca posible del borde, incluidas las capas de
borde y niebla.