Digamos que está en la fase de planificación de un proyecto de IoT. Tienes que tomar muchas decisiones y quizás no estés seguro de por dónde empezar. En este artículo, nos enfocamos en un marco de trabajo para pensar sobre este problema de estándares, protocolos y radios. 

El marco, por supuesto, depende de si su implementación será interna, como en una fábrica, o externa, como un producto de consumo. En esta conversación, nos centraremos en los productos que se están lanzando externamente a un público más amplio de clientes, y para eso, tenemos mucho que considerar.

Veamos el estado de IoT en este momento: en resumen,  no hay un estándar tan prolífico o significativo que esté cometiendo un error al no usarlo . Lo que queremos hacer, entonces, es elegir lo que resuelva el problema que tenemos lo más cerca posible y que tenga costos aceptables para implementar y escalar, y no preocuparnos demasiado por la adivinación de la popularidad futura de ese estándar.  

Entonces, primero se reduce a limitaciones técnicas:

     - ¿Cuáles son los requisitos de rango y ancho de banda? 

     - ¿Cuántos nodos se admitirán en la red?

     - ¿Cuál es el costo de la radio? 

Esa elección de radio tiene un gran impacto: no solo es una línea de pedido considerable en su lista de materiales por sí sola, sino que también determinará los recursos que necesita el dispositivo. Por ejemplo, si tiene una radio Wi-Fi al final, hay expectativas considerables de CPU y memoria, mientras que si tenemos BLE o alguna red de malla, necesitará mucho menos. También hay que considerar los costos de escalamiento de la infraestructura. Si vamos a Wi-Fi: ¿Ya existe una infraestructura de Wi-Fi en el lugar donde se está implementando? ¿Qué tan confiable es? Si comenzamos desde cero, ¿cuál es el plan para cubrir un área grande? Eso puede llegar a ser muy costoso, especialmente si está utilizando puntos de acceso de grado industrial, por lo que es importante tener en cuenta estos efectos posteriores a su decisión.

Acercarse a estándares específicos

En nuestra opinión, el error más grande que encontramos es: "¿No habrá un estándar para gobernarlos a todos?" No hay futuro en eso, y no es solo porque nunca vamos a estar todos de acuerdo en una industria. es porque en muchos casos diferentes estándares no resuelven los mismos problemas de manera diferente, sino que resuelven problemas diferentes. Entonces, al comprender eso, ahora podemos ver qué intenta resolver cada protocolo y dónde viven en el modelo OSI, o "la pila".

MQTT

Algunos sugerirían que es un protocolo completo para comunicarse desde un dispositivo a un servidor, pero no es exactamente eso. MQTT se usa como formato de datos para comunicarse con algo, y esa carga útil se puede enviar a través de cualquier transporte, ya sea Wi-Fi, malla o algún protocolo de socket. Lo que intenta resolver es definir una forma de manipular los atributos de algo. Se centra en las propiedades de lectura y escritura, que se presta muy bien a un problema de IoT. Sin duda, ahorra tiempo de desarrollo en algunos aspectos, pero dependiendo de cuán estrictamente esté tratando de implementarlo, puede costarle más tiempo de desarrollo. Tan pronto como seleccione una parte, debe documentarlo muy bien y, en algún momento, se acerca a un factor de tiempo y costo en el que implementar su propio esquema de carga útil puede ser una mejor opción.

¿Es lo suficientemente prolífico como para usarlo absolutamente? 

No, no ha alcanzado ese nivel, y probablemente no alcanzará ese nivel. Lo que es en este momento es un estándar conveniente para el dispositivo directo a la nube, donde no controlamos ambos extremos porque proporciona una medida de un lenguaje común en el que podemos estar de acuerdo; Sin embargo, lo que hay que tener en cuenta es que la mayoría de las veces, de hecho, necesita documentación adicional, qué propiedades se leen / escriben y cómo se ve la implementación exacta, en última instancia, no está saliendo de mucho de trabajo usando MQTT.

Zigbee y onda Z

También comenzando en la capa de red, Zigbee y Z-wave son los grandes titulares que a todos les gustan para las redes de malla. Intentan resolver dos problemas: proporcionar una especificación razonable para mover paquetes de un lugar a otro en una red de malla, y en realidad sugieren cómo deben estructurarse esos paquetes; entonces, ambos alcanzan más alto en la pila. Y esa es la parte que dificulta su futuro.  Por ejemplo, Zigbee utiliza un sistema llamado perfiles, que son conjuntos de capacidades, como el perfil de energía inteligente o el perfil de automatización del hogar. Cuando un protocolo se vuelve tan específico como para decir 'esto es lo que hace una bombilla', es bastante difícil implementar dispositivos que no están incluidos en el perfil. Si bien existen disposiciones para los datos personalizados, en ese momento no está utilizando una especificación compatible con la compatibilidad: básicamente está fuera del estándar tan pronto como trabaja con un dispositivo no definido en el perfil.  

La otra consideración con estos dos es que ambos son redes de malla enrutadas. Usamos un nodo para comunicarnos con otro nodo usando nodos intermedios. En otras palabras, podemos enviar un mensaje de A a B a C a D, pero en la práctica, hemos enviado un mensaje de A a D.  Como mallas enrutadas, cada nodo comprende la ruta que debe seguir el mensaje, y eso tiene un costo en memoria asociado a él. Mientras que Z-wave y Zigbee tienen un límite teórico de 65.535 nodos en una red (el espacio de direcciones es un entero de 16 bits), el límite práctico está más cerca de unos pocos cientos de nodos, porque estos dispositivos suelen ser dispositivos de baja potencia y baja memoria. El enrutamiento también tiene un costo de tiempo, por lo que una red de malla grande puede manifestar una latencia inaceptable para su caso de uso. Otra consideración, especialmente si está lanzando un producto de consumo controlado en la nube, es que estas redes de malla no pueden conectarse directamente a Internet; requieren un puente intermedio (también conocido como puerta de enlace, concentrador, servidor perimetral) para comunicarse con la nube.   

Una advertencia final es que Z-wave es un proveedor de fuente única: las radios son fabricadas y vendidas por Zensys, por lo que debe comprarlas. Zigbee tiene un proceso de certificación, y hay múltiples proveedores de la radio, desde Atmel hasta TI.

Bluetooth

Realmente no puedes competir con la cantidad de silicio que se envía en base a Bluetooth. se lanzaron 10.000 SKU únicos en Bluetooth en 2014. Aparte de Wi-Fi, no hay nada que se compare en términos de adopción. Bluetooth fue diseñado originalmente para "redes de área personal", con el estándar original que admite 7 dispositivos concurrentes. Y ahora tenemos Bluetoot de baja energía (BLUE), que tiene un límite teórico infinito. BLE hizo mucho para optimizar los desafíos de IoT. Observaron mucho la cantidad de energía requerida para apoyar la comunicación. Consideraron todas las facetas de la "baja energía", no solo la radio: analizaron el formato de datos, el tamaño del paquete, cuánto tiempo debía estar encendida la radio para transmitir esos paquetes, cuánta memoria se requería para soportarla, cuál era el costo de energía fue para esa memoria, y lo que el protocolo espera de la CPU, todo teniendo en cuenta los costos generales de la lista de materiales. Por ejemplo, descubrieron que la radio solo debería estar encendida durante 1,5 ms a la vez. Ese es un punto óptimo: si transmite durante más tiempo, los componentes se calientan y, por lo tanto, requieren más potencia. También descubrieron que las baterías de celda de botón son mejores para suministrar energía en ráfagas cortas en lugar de continuamente. Promover, Y luego   apareció CSR e implementó un estándar de malla a través de Bluetooth. Aproveche todas las ventajas que ofrece BLE y luego obtenga todos los beneficios de una red de malla. La malla Bluetooth es una malla de inundación, lo que significa que en lugar de enrutamiento específico a los nodos, se envía un mensaje indiscriminadamente a través de todos los nodos. Esto se escala mejor que la malla enrutada porque no hay restricciones de memoria. Es una buena solución para muchos problemas en el IoT y, a escala, probablemente será el costo más bajo de implementación. 

Hilo

Thread es un estándar prometedor construido sobre el mismo silicio que alimenta la radio Zigbee. Resuelve el problema de que los nodos de malla no puedan comunicarse directamente con la nube al agregar compatibilidad con IPv6, lo que significa que los nodos en la red pueden realizar solicitudes de Internet completamente calificadas. Hay mucho peso detrás de este estándar. Google parece pensar que es lo suficientemente interesante como para crear su propio protocolo (conocido como "Weave"). y luego está Nest Weave, que es otra versión de Google Weave. Tal como están las cosas, toma mucho tiempo para que un estándar realmente se arraigue: puede ver de inmediato cómo la historia con Thread es un poco más turbia, lo que no ayudará a su adopción. También está resolviendo un problema que simplemente no parece que tengan muchos dispositivos. Tomemos los sensores como ejemplo. ¿Estos dispositivos de baja potencia, peso ligero, bajo costo, baja memoria, bajo procesamiento y bastante tontos NECESITAN hacer solicitudes de Internet directamente? Con Thread, cada nodo ahora sabe mucho más sobre el mundo: dónde están sus servidores, por ejemplo, y tal vez no deberían preocuparse por esas cosas, porque no solo aumentan los requisitos del dispositivo, sino también la probabilidad y la frecuencia de tener que actualizarlos en el campo aumenta mucho. Cuando se trata de los sensores reales y otros puntos finales, Cuando Thread anunció su certificación de producto el año pasado, solo se presentaron 30 productos. Otra cosa a tener en cuenta sobre la adopción de Thread es que el problema de la malla IPv6 se ha resuelto antes: en realidad, hay una especificación en Bluetooth 4.2 que agrega el enrutamiento IPv6 a Bluetooth, pero muy pocas personas lo están utilizando. Aunque Nordic Semiconductor pensó que iba a ser un gran problema y siguió adelante y lo implementó primero, simplemente no ha surgido mucho en la industria.

Una cosa que Thread tiene a su favor es que deja de definir cómo los dispositivos se comunican entre sí y cómo los dispositivos formatean sus datos, lo que lo hace a prueba de futuro. Aquí es donde entra Weave, porque supone cómo deben estructurarse los datos. Básicamente, una forma de verlo es que Weave + Thread = competidor directo de Zigbee / Z-wave. No hemos visto a nadie fuera de Google que realmente tome una iniciativa en Weave, aparte de Nest, que ha hecho un buen esfuerzo de marketing para hacer que parezca que están obteniendo tracción.

AllJoyn

Otros protocolos viven más arriba en la pila y permanecen agnósticos en la capa de red. El más conocido de estos es probablemente el esfuerzo Alljoyn de Qualcomm . Tienen la Alianza Allseen, aunque su marca es un poco turbia: Allplay, AllShare, etc. Hemos visto cierta tracción con ella, pero no una tonelada; la mayor preocupación de que esté luchando es que es un protocolo realmente abierto, Lo suficientemente definido como para no construir realmente algo totalmente interoperable con todo lo demás. Ese es un gran riesgo para los equipos de productos. Si no hay suficientes dispositivos en el mundo que hablen ese idioma, ¿por qué necesito hablarlo? Dicho eso, LIFX lo implementó y funcionó realmente bien para ellos, especialmente desde que Windows también lo implementó. Ahora, es parte de Windows 10: hay una capa específicamente para las cosas de AllJoyn y parece funcionar bien. Hay evidencia con AllJoyn de que puede traer dispositivos a la mesa que no saben nada el uno del otro y obtener algún tipo de interoperabilidad duradera. Sin embargo, de un vistazo, parece complicado: la forma en que se trata la autorización y la forma en que los dispositivos deben negociarse entre sí. realmente no hay adopción desbocada.

Wi-Fi de IEEE

Wi-Fi de IEEE: han gobernado el gallinero con su serie 802.11. B luego G y luego A, y ahora tenemos AC. 802.11 ha sido realmente bueno para ser simple de configurar y tener un gran ancho de banda. No le importa el consumo de energía, está más preocupado por el rendimiento porque está destinado a ser un reemplazo de los cables. Hace casi 2 años, anunciaron 802.11 AH, que han calificado como HaLow, que intenta abordar las preocupaciones sobre el poder, el alcance y el emparejamiento del WiFi clásico. La mayoría de los dispositivos Wi-Fi no tienen cabeza ("sin cabeza", sin pantalla u otra entrada), tienen una interfaz de usuario rica, lo que significa que podemos iniciar sesión y configurarlos para conectarse a WiFi. El emparejamiento de dispositivos sin cabeza ha sido un proceso muy tedioso. Con HaLow, están resolviendo dos problemas: cómo hacemos que las cosas sean más fáciles y cómo disminuimos las expectativas (particularmente la potencia) del dispositivo que ejecuta la radio. Es demasiado pronto para saber qué tipo de tracción obtendrá, pero IEEE tiene un excelente historial en la adopción de estándares.

LoRa y SIGFOX

Más como: LoRa vs SIGFOX. Con estos protocolos, estamos viendo cómo conectar cosas a distancias bastante largas, como en aplicaciones de ciudades inteligentes. LoRaWAN es un protocolo abierto que sigue una estrategia de adopción ascendente. SIGFOX está construyendo la infraestructura de arriba hacia abajo y entregando API a sus clientes. De esa manera, SIGFOX es más como un servicio. Será interesante ver el baile entre estos dos a medida que el IoT se adopte en estas aplicaciones de tipo más público.