Resumen de lo más importante
En 2017, apareció en Habr un artículo “”. En 2018, el comité técnico “Sistemas Ciberfísicos” :
GOST R “Tecnologías de la Información. Internet de las Cosas. Términos y definiciones”,
GOST R “Tecnologías de la Información. Internet de las Cosas. Arquitectura de referencia para Internet de las cosas e Internet industrial”, GOST R “Tecnologías de la Información. Internet de las Cosas. Protocolo de intercambio para el Internet de las cosas en espectro estrecho (NB-FI)”.
En febrero de 2019 el PNT-2019 “Tecnologías de la Información. Internet de las Cosas. Protocolo de transmisión de datos inalámbrica basada en modulación de radio de espectro estrecho NB-Fi”. Desde el 1 de abril de 2019, entró en vigor y finalizará el 1 de abril de 2022. Durante sus tres años de vigencia, la norma preliminar debe ser probada en la práctica, su potencial de mercado debe ser evaluado y se deben preparar enmiendas a la norma.
En los medios de comunicación, el documento se posiciona activamente como “la primera norma nacional de IoT de Rusia, con la perspectiva de convertirse en norma internacional” y se menciona como ejemplo el proyecto “VAVIO” .
Ufh. Cuántos enlaces hay en un texto tan corto. Aquí está — al texto de la norma preliminar en su primera edición para quienes no quieran buscar en Google. Las especificaciones del estándar es mejor consultarlas en este documento; en el artículo no las mencionaremos.
Sobre las normas de transmisión de datos de IoT
Se pueden encontrar alrededor de 300 protocolos/tecnologías de transmisión de datos entre dispositivos que se pueden relacionar con IoT. Vivimos en Rusia, trabajamos en B2B, así que en esta publicación solo tocaremos algunos temas:
- NB-IoT
Estándar de comunicación móvil para dispositivos de telemetría. Uno de los tres que se implementan en redes LTE Advanced — NB-IoT, eMTC y EC-GSM-IoT. Los tres grandes operadores móviles de Rusia en 2017-2018 desplegaron secciones de redes que operan con NB-IoT. Los operadores no olvidan eMTC y EC-GSM-IoT, pero no los resaltaremos por ahora.
- LoRa
Opera en frecuencias no licenciadas. Se ha hablado bien del estándar en un artículo a finales de 2017 “Qué es LoRaWan” en Habr. Funciona con chipsets de Semtech.
- “Strizh”
Opera en frecuencias no licenciadas. Proveedor nacional de soluciones para el sector de vivienda y servicios públicos y otras industrias. Utiliza su propio protocolo XNB. Se habla de producción en Rusia, pero prometen asegurar la producción masiva de chips en Rusia solo en 2020, mientras tanto dependen de ON Semiconductor (ON Semiconductor AX8052F143).
- Nuevo NB-Fi
Opera en frecuencias no licenciadas. Utiliza el mismo chip ON Semiconductor AX8052F143 que el 'Strizh', las especificaciones son similares, también hay anuncios de producción de chips propios en Rusia. En general, hay una conexión evidente. El protocolo es abierto.
Sobre la integración con sistemas de facturación
Para aquellos que han intentado crear una 'casa inteligente', se vuelve evidente que el uso de sensores de diferentes fabricantes complica significativamente las cosas. Incluso si en dos dispositivos vemos la misma mención de la tecnología de comunicación, resulta que no quieren comunicarse entre sí.
En el segmento B2B, la situación es similar. Los desarrolladores de protocolos y chips quieren ganar dinero. Al comenzar un proyecto con LoRa, en cualquier caso, será necesario comprar equipo que utilice chips de Semtech. Al prestar atención a un fabricante nacional, se puede recibir como carga la compra de servicios y estaciones base, y en el futuro, con el exitoso lanzamiento de la producción de chips en Rusia, potencialmente se podrá adquirir equipo/base de componentes solo de un número limitado de proveedores.
Trabajamos con equipos de telecomunicaciones y para nosotros es habitual recibir datos de telemetría del equipo, agregarlos, normalizarlos y enviarlos a diversos sistemas de información. Este bloque de trabajo es responsabilidad de Forward TI (Traffic Integrator). En un caso estándar, se ve así:
En caso de que se amplíen las necesidades del cliente para la recopilación de datos, se conectan módulos adicionales:
La velocidad de crecimiento estimada del mercado de dispositivos IoT es del 18-22% anual a nivel mundial y hasta un 25% en Rusia. En abril, durante el IoT Tech Spring 2019 en Moscú, Andrey Kolesnikov, director de la Asociación de Internet de las Cosas, mencionó un crecimiento anual del 15-17%, pero hay información diversa circulando en la red. En el RIF en abril de 2019, en las diapositivas se mostraron datos sobre el crecimiento anual del mercado ruso de Internet de las Cosas en un 18% hasta 2022, y también se indicó el volumen del mercado ruso en 2018 — $3.67 mil millones. Curiosamente, en esa misma diapositiva se mencionó el motivo de este artículo: “Se aprobó el primer documento ruso sobre la estandarización en el ámbito del IoT…”. En nuestra opinión, ya ha surgido una necesidad real de integrar de manera habitual las estaciones base UNB/LPWAN y los servidores de telecomunicaciones en los sistemas de facturación.
Reflexiones
Primera línea
El protocolo de transmisión de datos o incluso la implementación de una función de transporte no tendrán una gran importancia (esto lo reiteramos, IoT no es solo una plancha conectada a Internet, sino una infraestructura o ecosistema). Los datos se recopilarán de dispositivos completamente diferentes y la carga útil también será diversa. Es poco probable que una empresa proveedora de electricidad construya una única red de recopilación de datos, que un proveedor de gas haga su propia segunda red, que los servicios de saneamiento establezcan una tercera, etc. No es racional y parece poco probable.
Esto significa que en una ubicación hipotética se organizará una red según un solo principio y acumulará datos una sola organización. Llamaremos a esta organización operador-agregador de datos.
El operador-agregador puede ser un servicio que se dedica únicamente a la transmisión de datos, o un intermediario completo que asume todas las complejidades relacionadas con la tarificación, organización del pago por los servicios prestados, interacción con los clientes finales y proveedores de servicios.
He visto muchas veces cómo la gente saca de su correo cinco recibos mensualmente, y a mí también me resulta familiar esta situación. Un recibo para el gas, otro para la electricidad, otro para el mantenimiento, otro para el agua y otro para el servicio del hogar. Sin contar con los pagos de las cuentas mensuales que solo existen en línea, como la factura de internet, los teléfonos móviles, y las suscripciones a diversos servicios de contenido. En algunos casos, se puede configurar un pago automático, en otros, no. Pero la situación general es que se ha vuelto una tradición sentarse una vez al mes y pagar todas las cuentas; el proceso puede alargarse durante media hora a una hora, y si alguna vez algo falla en los sistemas informáticos de los proveedores, hay que posponer parte de los pagos para otro día. Preferiría interactuar con un solo proveedor de servicios para todos los asuntos, en lugar de dividir mi atención entre un montón de facturas y sitios web. Los bancos modernos facilitan la vida, pero no por completo.
Así que la recopilación automática de datos sobre los servicios consumidos y la transferencia de pagos para el cliente final a una única "ventana" es una gran ventaja. La mencionada recopilación de datos a través del tráfico por integradores, como nuestro Forward TI, es solo la punta del iceberg. El integrador de tráfico representa la primera línea a través de la cual se recopilarán datos de telemetría y carga útil, y a diferencia de los proveedores, para quienes es importante el volumen de tráfico por sí mismo, en IoT, se dará prioridad a la carga útil.
Tomemos un ejemplo cercano de telecomunicaciones para ver qué hace la primera línea. Hay un operador que proporciona servicios de comunicación. Se realiza una llamada con una duración de 30 minutos. 15 minutos de la llamada caen en un día y 15 en otro. La central telefónica al final del día dividió la llamada y la registró en 2 CDRs, en esencia transformó una llamada en dos. El TI, utilizando signos indirectos, unirá esa llamada y pasará a la base de tarifas los datos de una sola llamada, aunque los datos provengan del equipo sobre dos. En el nivel de recopilación de datos, debe haber un sistema capaz de resolver tales colisiones. Y el siguiente sistema debe recibir datos ya normalizados.
La información en el integrador de tráfico no solo se normaliza, sino que también se enriquece. Otro ejemplo: los datos de la central telefónica no llegan para la tarificación zonal, pero sabemos desde qué ubicación se realizó la llamada y el TI agrega información sobre las zonas geográficas de tarificación en los datos que se envían al siguiente sistema informático. De manera similar, se pueden asignar cualquier parámetro calculado. Este es un ejemplo de zonificación simple o enriquecimiento de datos.
Otra función del integrador de tráfico es la agregación de datos. Por ejemplo: el equipo envía datos cada minuto, pero el sistema de contabilidad TI entrega los datos por hora. En el sistema de contabilidad solo quedan los datos necesarios para la tarificación y la facturación, en lugar de 60 registros se genera solo uno. Al mismo tiempo, se realiza una copia de seguridad de los datos 'crudos' por si es necesario procesarlos.
Segunda línea
Continuaremos desarrollando la idea del agregador, que se ha convertido en un intermediario completo. Tal operador gestionará una red de recopilación de datos y separará la telemetría y la carga útil. La telemetría se utilizará para necesidades propias, manteniendo la red de recopilación de datos en buen estado, mientras que la carga útil se procesará, enriquecerá, normalizará y se enviará a los proveedores de servicios.
Un momento de autopromoción, porque es más fácil ilustrar con mi propio software que inventar ejemplos abstractos.
En esta línea, el agregador utiliza en su inventario:
- Facturación, considerando los ingresos de los datos preparados del TI, vinculándolos a los consumidores registrados (suscriptores), tarificación correcta de estos datos de acuerdo con el plan tarifario utilizado, generación de facturas y recibos, recepción de fondos de los suscriptores y su distribución en las cuentas y saldos correspondientes.
- PC (Catálogo de Productos) para crear ofertas de paquetes complejos y gestionar los servicios dentro de esos paquetes, estableciendo reglas para la conexión de servicios adicionales.
- BMS (Balance Manager), este sistema debe ser multibalance, se requerirá una gestión flexible de los cargos por diferentes servicios, además, permitirá el uso de varios sistemas de facturación especializados que atienden servicios individuales y la agregación de los cálculos obtenidos de ellos en relación con el balance total del abonado.
- eShop para interactuar con los consumidores finales, crear una vitrina pública de servicios, proporcionando acceso al área personal con todas las características modernas como estadísticas de uso de servicios, activación de servicios en línea y solicitudes de nuevos servicios.
- BPM (Business Process) automatización de los procesos de negocio del agregador dirigidos tanto al servicio de abonados como a la interacción con proveedores de servicios.
Tercera línea
Aquí es donde empieza lo más interesante desde mi punto de vista.
Primero, surge la necesidad de sistemas de clase PRM (Partner Management System), que permitirán gestionar de manera flexible los esquemas de agentes y socios. Sin tal sistema, será complicado gestionar el trabajo de socios y proveedores.
En segundo lugar, aparece la necesidad de un DWH (Data Warehouse) para análisis. Aquí hay mucho espacio para Big Data basado en datos de telemetría y carga útil, así como la creación de vitrinas para herramientas de BI y análisis de diversos niveles.
En tercer lugar, como cereza del pastel, se puede complementar el conjunto con un sistema de previsión tipo Forward Forecast. Este sistema permitirá entrenar un modelo matemático que subyace al sistema, segmentar la base de abonados, y generar predicciones de consumo y comportamiento de los abonados.
En conjunto, se perfila una arquitectura de información bastante compleja para el operador-agregador.
¿Por qué destacamos tres líneas en el artículo y no las fusionamos? La razón es que para un sistema de negocios generalmente son importantes varios parámetros agregados. Lo demás es necesario para monitoreo, mantenimiento, análisis de informes y previsión. La información detallada es necesaria para la seguridad y Big Data, porque a menudo no sabemos qué parámetros y qué criterios se analizarán en los análisis de Big Data, por lo que en el DWH se transmiten todos los datos en su forma original.
En los sistemas de negocio con funciones de gestión, como facturación y PRM, ya no son necesarios algunos parámetros que venían del hardware, como la telemetría. Por ello, filtramos y eliminamos los campos innecesarios. Si es necesario, enriquecemos los datos según ciertas reglas, los agregamos y, al final, los normalizamos para su envío a los sistemas de negocio.
Así, la primera línea recopila datos en bruto para la tercera línea y los adapta para la segunda. La segunda trabaja con datos normalizados y asegura la operativa del negocio. La tercera permite identificar puntos de crecimiento a partir de datos en bruto.
Qué esperamos en el futuro y sobre la economía de los proyectos IoT
Empecemos con la economía. En la sección anterior hablamos sobre el tamaño del mercado. Parece que ya se están invirtiendo sumas significativas. Sin embargo, hemos visto cómo la economía de proyectos que intentamos realizar con nuestra ayuda, o para los cuales nos invitaron a evaluar, no se sostenía. Por ejemplo, calculamos la creación de un MVNO para M2M utilizando tarjetas SIM para recoger telemetría de un tipo específico de hardware. El proyecto no se llevó a cabo porque el modelo económico resultó insostenible.
Las grandes organizaciones de telecomunicaciones están entrando en el mercado IoT, ya que poseen infraestructuras y tecnologías listas. El número de nuevos abonados humanos en Rusia es bastante bajo. Pero el mercado de IoT ofrece excelentes oportunidades para el crecimiento y la obtención de ingresos adicionales a partir de sus redes. Mientras se prueba un estándar nacional preliminar y pequeñas empresas entusiastas exploran diferentes opciones para implementar UNB/LPWAN, las grandes empresas invertirán recursos para captar el mercado.
Creemos que, con el tiempo, un solo estándar/protocolo de transmisión de datos comenzará a dominar, como ocurrió con la telefonía móvil. Después de eso, los riesgos disminuirán y el hardware se volverá más accesible. Sin embargo, para entonces, el mercado podría estar ya medio captado.
Las personas comunes se están acostumbrando al servicio, les resulta conveniente cuando los dispositivos automatizados contabilizan agua, gas, electricidad, internet, saneamiento, calefacción, y garantizan el funcionamiento de sistemas de alarma de incendios y de seguridad, botones de emergencia y videovigilancia. La gente madurará hacia el uso masivo de IoT en el sector de servicios públicos en un horizonte de 2 a 5 años. Pasará un poco más de tiempo para confiarles a los robots el frigorífico y la plancha, pero ese momento también está cerca.
Preocupaciones
Sobre el estándar nacional preliminar NB-Fi se ha hablado en voz alta como un candidato para el reconocimiento internacional. Entre los beneficios se menciona el bajo costo de los transmisores de radio para dispositivos y la posibilidad de fabricarlos en Rusia. Ya en 2017, en el mencionado artículo en Habr, se anunció:
La estación base del estándar NB-FI costará entre 100,000 y 150,000 rublos, el módulo de radio para conectar el dispositivo a la red — alrededor de 800 rublos, el costo de los controladores para recoger y transmitir información desde el contador — hasta 200 rublos, el costo de la batería — de 50 a 100 rublos.
Pero por ahora, son solo planes y, de hecho, una parte importante de la base de componentes para los dispositivos se produce en el extranjero. En el mismo PNST se menciona explícitamente el ON Semiconductor AX8052F143.
Esperamos que el protocolo NB-Fi sea realmente abierto y accesible, sin especulaciones sobre la sustitución de importaciones y imposiciones. Se convertirá en un producto competitivo.
IoT es la nueva moda. Pero hay que recordar que, ante todo, el “internet de las cosas” no se trata de agregar funcionalidades y enviar datos a la nube desde todo lo que se pueda. El “internet de las cosas” se centra en la infraestructura y la optimización de Machine-to-Machine. La recolección inalámbrica de datos de contadores de electricidad no es en sí misma IoT. Sin embargo, la distribución automatizada de electricidad a los consumidores desde varias fuentes — gubernamentales, proveedores privados — para toda la localidad ya se asemeja a la idea original del internet de las cosas.
¿Sobre qué estándar construiría su red de recolección de datos? ¿Dirige alguna esperanza hacia NB-Fi, vale la pena invertir en el desarrollo de sistemas de facturación para la recolección de datos de dispositivos de este estándar? ¿Quizás ha participado en la implementación de proyectos de IoT? Comparta su experiencia en los comentarios.
¡Y buena suerte!
Fuente: habr.com
