Notas del proveedor de IoT: nueve números de Internet de las cosas, o por qué no es bueno en Rusia

Hola queridos amantes de Internet de las cosas!

Este artículo es diferente de los anteriores. No se trata de decisiones y casos. Escribí sobre nueve problemas de IoT que arruinan nuestras vidas.

Propongo unir mis pensamientos y juntos predecir el futuro de Internet de las cosas.




Colas viejas


El progreso es a pasos agigantados. Pagamos un alto precio por la velocidad, especialmente por errores.

Por ejemplo, los programadores escriben código. Según este código, se crea una biblioteca o firmware que se adapta a diferentes tareas. El mismo código se usa cada vez en diferentes proyectos. Como resultado, quedan "colas": los restos del código que vagan del dispositivo al dispositivo.

Tolerante si estos funcionan "colas". Y es realmente malo si hay un agujero de seguridad.

Ejemplo : lanzamiento desde el vehículo de lanzamiento del puerto espacial Vostochny Soyuz-2.1b. Entonces el bloque de refuerzo Frigate se comportó de manera anormal. En su programa de hace 20 años, todos los lanzamientos estaban vinculados a Baikonur. No esperaba un comienzo de Vostochny. Entonces hubo un incidente.

Me atrevo a sugerir que estas mismas "colas de hace 20 años" arruinarán la vida cada vez más. Porque caen en nuevos programas. Y ese es el problema.



Copiar y pegar


La falta de calificaciones es algo común. Pero con el advenimiento de Internet, se ha convertido en un problema. El ingeniero dejó de pensar con la cabeza, está buscando una solución llave en mano en Google. Como resultado, obtenemos un enfoque superficial y errores.

Ejemplo : algunos "constructores" de redes LoRa han leído folletos y esperan decenas de kilómetros de la estación base con una antena muerta, que colocaron en un apartamento cerca de Kulibin.

Es bueno si simplemente no funcionó. Y si se negaba, ¿cuándo comenzaron a explotar?

Marketing agresivo


A Marketing le encanta involucrarse donde lo pidan. Por un lado, esto es comprensible. El producto necesita ser vendido. Por otro lado, las fronteras deben mantenerse. El marketing no tiene nada que ver en la documentación técnica. De lo contrario, se convierte en un folleto publicitario (leer, algo inútil).

Tenemos una regla en el Centro de Internet industrial: no utilice lo que no se ha probado para su rendimiento.

Montañas de bienes de consumo pasaron a través de nosotros, a veces incluso con las placas de identificación de compañías serias que ni siquiera muestran remotamente las características del pasaporte.

Ejemplo : redacción "do" en las descripciones de LoRa. Por ejemplo: "nuestro equipo tiene una velocidad de hasta 50 kilobits / segundo y funciona hasta 15 kilómetros". Por supuesto, nadie menciona que estos son "hacer" diferentes y al mismo tiempo no funcionan. Cualquiera de velocidad o rango.

Propiedad


Escribí en detalle sobre esto aquí - Propietario . Seré breve aquí.

Muchos sueñan con crear un producto popular que solo ellos puedan vender. Por lo tanto, nacen estándares y dispositivos propietarios e incompatibles.

Incluso si el desarrollo lo llevan a cabo especialistas competentes y el producto no está decorado con oropel. De todos modos, cuando trabajas con un equipo reducido, puedes perderte algo.

Los estándares abiertos generalmente se reúnen alrededor de una comunidad de entusiastas. Bajo un microscopio, estudian todas las ventajas y desventajas, buscan agujeros y errores. El resultado es una comprensión de los problemas del proyecto y su solución.

En el caso de la tecnología patentada se hierve en un círculo limitado de personas. Y definitivamente extrañarán algo.

Ejemplo : estándar NB-Fi que no está protegido contra ataques de repetición.

Barreras administrativas


Este problema es especialmente grave en las comunicaciones por radio.

La mayoría de nuestros dispositivos IoT están restringidos por restricciones administrativas, no técnicas. No podemos exceder el nivel de radiación permitido; no podemos usar algunas frecuencias sin una licencia.

Los dispositivos IoT también sufren un vago marco regulatorio. No todos los proveedores están dispuestos a invertir en una red IoT que requiere una asociación con el operador móvil cuatro (soluciones NB-IoT) o tiene un estatus legal poco claro.

Ejemplo 1 : recuperación de frecuencias en Yota en Kazán en 2010, cuando ya se había construido un piloto de red 4g.

Ejemplo 2 : proyecto de decisión SCRF de utilizar estaciones base LPWAN solo de producción rusa. Por lo tanto, las redes ya construidas o las redes durante el proceso de construcción pueden ser prohibidas. Después de todo, el equipo ya ha sido comprado para ellos.



Villanos expertos


A diferencia de los ingenieros de copy-pasteur, estamos haciendo crecer una comunidad de personas a las que les gusta romper algo. Algunos de ellos lo hacen egoístamente. Por ejemplo, pirateado en un sistema de pago: robó dinero. A otros les encanta buscar vulnerabilidades.

Los casos de ataques sin un objetivo específico se han vuelto más frecuentes. Da miedo que las calificaciones de estos muchachos estén por encima del promedio. Y entonces las leyes de Murphy ahora son doblemente relevantes.

Ejemplo : el virus Mirai que ha infectado a decenas de miles de dispositivos. Al buscar la contraseña de inicio de sesión, obtuvo acceso a los dispositivos en la configuración predeterminada o casi predeterminada. Además, los dispositivos infectados se usaron para ataques DDoS.

La seguridad requiere recursos adicionales y afecta el precio. Pero no hay opciones.

Callejón sin salida tecnológico


El problema de escalabilidad es el más grave, en mi opinión, para el IoT moderno.

Está surgiendo una tecnología que está ganando popularidad rápidamente. La tecnología tiene limitaciones que retrasan su desarrollo. Pero debido a la simplicidad, funcionalidad o cualquier otra razón, todos comienzan a hacerlo.

Por lo tanto, nos encontramos rápidamente con marcos que son extremadamente difíciles de dejar.

Ejemplo : enrutadores Wi-Fi de 2,4 GHz desenfrenados. Sí, el "waffle" es fácil de usar, confiable y está diseñado para la operación simultánea de varios dispositivos independientes. Pero cuando 60 enrutadores se cortan en el zócalo a la vez, nos encontramos con la capacidad de éter.

Por la noche, la velocidad de los suscriptores cae, porque las frecuencias no son de goma. La solución aquí es una desviación radical a 5 GHz con un gran margen de capacidad y una longitud de onda más corta.

Compatibilidad con versiones anteriores


Este problema es similar al anterior, pero tiene otras razones.

A menudo, las nuevas tecnologías se ven obligadas a trabajar con dispositivos o estándares antiguos. Como resultado, la tarea técnica de los ingenieros contiene condiciones extrañas. Lo que sin embargo debe ser observado.

Ejemplo : ancho de banda estándar de televisión digital DVB-T2 en Rusia. Es de 8 MHz. ¿Por qué no 5 o 10? Muy simple 8 MHz es el ancho de banda del canal analógico del estándar SECAM en el que hemos estado sentados durante el medio siglo anterior.

Esta solución se utilizó para proporcionar la transmisión conjunta de números analógicos y sin violar la lógica OIRT. Sin embargo, este año el análogo se desconectará y quedarán 8 MHz.

Altas expectativas


En mi opinión, uno de los principales problemas de IoT.

El progreso requiere soluciones rápidas. La fiabilidad es probada por el tiempo. Hoy, el progreso es líder, y la tecnología en bruto está emergiendo en lo productivo. Algunos de ellos no soportan la prueba del tiempo: se rompen, no toleran la escala o simplemente son inútiles.

El mercado está votando dinero. Y a menudo hay casos en los que nadie necesita una tecnología patentada, porque es inconveniente, poco confiable o inútil. Estos últimos son particularmente culpables de nuevas empresas que desarrollan soluciones complejas, interesantes e inútiles.

Ejemplo : regularmente nos encontramos con proyectos de programación abandonados.

Uno de los casos ilustrativos es una encuesta de medidores GSM. Implementamos una zona piloto en varios sótanos, todo funcionó. Transmitieron la solución a cien sótanos; tuvieron problemas.

Al principio resultó que la conexión no es estable en todas partes. Luego descubrieron que las baterías duran un máximo de un año, mientras que el período promedio es de 6 meses. El servicio en el proyecto no está establecido. Como resultado, se arrojaron cien cajas con púlsares, baterías y antenas. Resultó ser más fácil tomar lecturas a la antigua usanza que mantener dicha red.

En mi opinión, son estos nueve problemas los que retrasan el desarrollo de IoT y arruinan nuestras vidas.

¿Por qué no considero que la batalla de los estándares sea un problema?


En mi opinión, no puedes aportar un montón de tecnologías con un perfil excelente. Por ejemplo, Z-Wave y LoRaWAN inicialmente tienen diferentes tareas y, por lo tanto, es incorrecto compararlas.

Intentar arrastrar LoRaWAN RS-485 en modo transparente o crear soluciones de largo alcance en Z-Wave es un ejemplo del uso de herramientas para otros fines. No culpes a los alicates de que son incómodos para apretar los tornillos. Aunque es posible, es inconveniente y extremadamente extraño.

Agradecería comentarios en los comentarios. Con qué de acuerdo, con qué, no. Tal vez me perdí algo en mi crítica.

Archivo de artículos anteriores:

# 1 Introducción# 2. Cobertura# 3. Dispositivos de medición del zoológico# 4. Propiedad# 5. Activación y seguridad en LoraWAN# 6. LoRaWAN y RS-485# 7. Dispositivos y ofertas externas# 8. Un poco sobre las frecuencias# 9. Caso: creamos una red LoRa para un dispensador de combustible en Chelyabinsk# 10. ¿Cómo crear una red LoRa en una ciudad sin red en un día?# 11. Notas del proveedor de IoT: deje que haya luz o el historial del primer pedido de estado por LoRa

Source: https://habr.com/ru/post/438924/


All Articles