Notas del proveedor de IoT. Propiedad

Continuación de la serie de artículos. Inicio:

Me gustaría dedicar mi cuarto artículo a un pensamiento importante. Fui motivado por numerosos comentarios y mensajes en PM.

El Internet de las cosas todavía es muy joven. Lentamente está eliminando cada vez más esferas y se está utilizando en áreas cada vez más grandes. Sin embargo, como cualquier tecnología nueva, ahora IoT solo está en pie. De hecho, las primeras reglas y recomendaciones apenas aparecen, cómo y sobre la base de qué tecnología implementar la red. Y nadie sabe la respuesta exacta a la pregunta de qué estándar "volará" y cuál se hundirá en el olvido. Y no lo se. Solo puedo asumir, según el análisis de mercado, los pros o los contras de las tecnologías individuales.

Entonces, ¿por qué lo mismo LoRaWAN?

En mi primer artículo, defendí: hay un espectro sin licencia, ahorro de batería y alta inmunidad al ruido. Pero, en un grado u otro, otros estándares también tienen esto. También saben cómo vivir con una batería durante mucho tiempo, también funcionan en 868. Tal vez no miremos allí en absoluto, ¿la topología de estrella no se arraigará y será reemplazada por redes de malla?

Todo es posible Sin embargo, LoRa tiene una ventaja importante que no todos conocen. Este no es un estándar propietario. Es decir, no está enfocado en una empresa, en un solo proveedor. Es más o menos abierto, y es producido por muchos fabricantes.

No disimulemos, la pelota sigue gobernada por el desarrollador, la empresa francesa Semtech. Solo ella hace cristales para chips. Y su influencia se siente en la Alianza LoRa. Sin embargo, los franceses eligieron un modelo de negocio exitoso. La producción de chips en sí está a merced de varias otras compañías, la especificación es de dominio público y la producción de terminales LoRa ahora se puede establecer en el sótano.

Y lo más importante, todo lo que honestamente admite LoRaWAN es compatible entre sí.
¿Por qué es esto importante?

Cualquier estándar, cerrado en un fabricante-desarrollador conlleva un riesgo obvio. El fabricante puede desaparecer y todavía tendrá un montón de hierro comprado, pero no útil en sus manos. Esta amenaza aumentará si el software se implementa no en sus servidores, sino en la nube del fabricante. Es por eso que inmediatamente descartamos, por ejemplo, "Swift". Puede ser diez veces mejor en características, ni siquiera discutiré sobre este tema. Es exclusivo de principio a fin. Si lo eliges como tecnología, te unes con lazos tangibles con Swift Telematics. La compañía es maravillosa, su director es un ingeniero muy agradable y extremadamente entusiasta. Sin embargo, dependiendo de sus decisiones es de alguna manera miope.

Similar a Vaviot con su NB-Fi. Ya es más interesante, Vaviot decidió abrir y publicar el código fuente en Github. Inmediatamente, muchos notaron que era sospechosamente similar a SigFox, solo ligeramente dopado, pero no era el punto. Tan pronto como varias compañías independientes inicien la producción de NB-Fi, ya puede considerarse para proyectos reales. Por supuesto, NB-Fi con seguridad es muy triste, porque realmente se produjo un ataque repetido. Pero ahora estamos discutiendo el concepto, no los detalles.

Creo que el momento con un solo proveedor es obvio para muchos. Sin embargo, hay una cosa más que no todos entienden. Es por eso que las soluciones de código abierto son tan populares. Cuando un desarrollador abre y pone la documentación en exhibición pública, cuando entrega la producción a docenas de compañías, y cientos de compañías implementan redes sin su participación, solo entonces los errores realmente desaparecen. Una gran comunidad está estudiando la tecnología bajo un microscopio, algunos están entusiasmados, otros trabajan por razones. Todas estas personas piensan de manera diferente, hablan diferentes idiomas, tienen diferentes niveles de habilidad. Y lo encontrarán. Encontrarán todo lo que sea posible.

LoRaWAN a menudo se llama el estándar con fugas para numerosos defectos. Aquí, las claves de sesión pueden durar varios meses (hablaremos de esto en el tema de seguridad), no es el uso más eficiente del espectro, hay trucos sobre cómo introducir una terminación en un estupor.

Sí, lo es, es estúpido negarlo. Pero todo esto lo sabemos solo porque LoRa está muy bien estudiado por las mismas personas que tuvieron acceso a él.
Otros estándares tienen exactamente los mismos problemas. Solo que no siempre sabemos sobre ellos. Quizás alguien dirá: la cercanía también es protección. En parte así. Pero, según la ley de Murphy, si los problemas son posibles, sucederán en algún lugar.

Con LoRaWAN, al menos sabemos dónde mirar y qué temer. Con los propietarios esto no funcionará. Sus problemas saldrán en el momento más inoportuno. Y nosotros, en virtud de nuestra ignorancia, ni siquiera entendemos lo que sucedió.

Y LoRa tiene una alianza completa que continúa desarrollándose. En octubre, se lanzó la especificación 1.1. Tiene poco uso en la práctica, en cualquier caso, no he visto dispositivos con soporte para nuevos elementos. Pero si profundiza en ello, queda claro: entre otras cosas, se han solucionado muchos errores. Cuando los ingenieros se sentaron en el trabajo, ya sabían en qué trabajar primero.

¿Cómo desarrollarán los propietarios su estándar (si es que lo hacen)? Obviamente, modifique y mejore, sin darse cuenta de que un error crítico ha migrado a la versión actualizada.

Hagámoslo de nuevo. No hay dogmas en Internet de las cosas; estamos escribiendo una historia aquí y ahora. Les doy mis argumentos, y no son tanto para LoRa como para el código abierto en general. El artículo resultó ser un poco filosófico, pero quiero aclarar la posición sobre la pregunta: "¿Por qué no usas esto, es mejor?" Puede ser mejor, pero se considerará seriamente solo en el caso de apertura, compatibilidad y múltiples proveedores. En el próximo número de Notes, hablaremos sobre seguridad y volveremos a sumergirnos en la tecnología. No soy partidario del razonamiento extenso, pero es mejor indicar la posición de forma inmediata y en general, que en partes en los comentarios.

PD: Cuando hablé sobre la compatibilidad de dispositivos de diferentes fabricantes, quise decir que puede colgar diferentes estaciones base en nuestro servidor y poner fin a diferentes fabricantes en la red. Pero si el primero se implementa en nuestro país (ahora las BS de tres proveedores están trabajando en la red), entonces el segundo me pareció un futuro muy lejano. Un año, tal vez dos, antes de que los clientes nos visiten con sus equipos.

Pero el futuro ha llegado más rápido. El cliente nos contactó con su final, de hecho, nos quita una red de alquiler. Me tomó un poco de tiempo adaptar el formato del paquete y funcionó.

C. Compatibilidad.

PPS Seré coherente y a todo el artículo agregaré el término olvidado en mi humilde opinión.