Hace unos días leí un excelente artículo, "El Manifiesto del Desarrollador de Sistemas Inteligentes: 15 Principios"

Decidí compartir mis pensamientos sobre la capa a continuación, es decir, los principios básicos de la arquitectura, que básicamente se corresponderían con los principios propuestos.

Debido a la naturaleza del ayuno, será aún más subjetivo que el Manifiesto.

Primero, tratemos con varios términos, por ejemplo, desarrollador y usuario de sistemas inteligentes. ¿Quién es este y dónde tiene lugar la separación?

Hay 2 extremos obvios: el fabricante del interruptor inteligente comprado y mi esposa, que enciende la luz. Pero, ¿a quién me llevo a mí o a mi hijo, que ocasionalmente toman y obtienen un ESP32 para soldar un par de sensores, botones y otras tiras de LED, que también interactúan con el mismo interruptor?

Pero incluso si miramos al vendedor, tampoco queda del todo claro. Te lo explicaré. Extremo obvio: todos los dispositivos del mismo fabricante, el hub también es suyo, la aplicación en sus teléfonos inteligentes es el desarrollador de un sistema inteligente. Pero, ¿qué pasa si varios proveedores en la misma red? Pero, ¿qué pasa si el centro central de uno, el dispositivo de otro y la nube con la que interactúo, por ejemplo, Siri, es Apple? ¿A cuál de ellos se dirige el Manifiesto, cuál de ellos es el mismo desarrollador? Creo que descender justo por debajo del nivel de las abstracciones globales del Manifiesto, que, por cierto, comparto casi por completo, debería introducir una separación funcional más profunda, de lo contrario, la responsabilidad colectiva por la experiencia del usuario dará como resultado la irresponsabilidad colectiva que ahora estamos observando en un grado u otro, o en un recinto rígido de ecosistemas con integración a nivel de usuario: ¿cuál de ustedes tiene más de una aplicación para administrar una casa inteligente en su teléfono?

Propongo la siguiente separación de objetos: dispositivos finales, concentradores, puertas de enlace, nubes de datos, servicios de integración, interfaces de usuario.

Los temas (como roles), por ejemplo, usuarios, personalizadores, desarrolladores, fabricantes o proveedores, existen en el contexto de estos objetos.

Juntos crean y constituyen un sistema que, a través del intercambio de datos, proporciona sus funciones.

Con un poco más de detalle en esta publicación, me centraré solo en los objetos.

Dispositivos finales

Sí, y aquí hay una pregunta bastante divertida. ¿Cuál es el dispositivo final, es decir, la "cosa" misma de Internet de las cosas?

Con una aspiradora inteligente, todo está claro: sacaron de la caja y enchufaron su base a una toma de corriente, se vistió, se fue e hizo una superposición de alfombras blancas con la creatividad gratuita de sus mascotas y se fue a cargar. Pero ya con una bombilla, por extraño que parezca, no es tan simple.

Ahora miro mi lámpara con varias lámparas, que enciendo con 3 interruptores diferentes (por separado, y no como una activación de ojivas nucleares), de hecho, el atenuador en el riel DIN en el panel funciona. Aquí, por "cosa", parecería, nos referimos al actuador final, pero lo curioso es que este atenuador es multicanal y ni siquiera recuerdo cuál de los otros candelabros también controla, así que aquí está el dispositivo, pero no todos, sino solo una parte. Pero al mismo tiempo, la frase de la esposa "enciende la luz" es intuitiva.

Aconsejo a los lectores que encuentren la "cosa" en otro paquete: un controlador de habitación (termostato), que controla los cabezales del radiador (calefacción) a través de 1 canal del PWM de 8 canales, y enfría a través de 1 de los canales 4 del actuador de canal 0-10V, que ya establece la configuración para el obturador constante flujo de aire en el conducto.

Pensé en toparme con una cruel cancillería e introducir una definición exacta de "cosas" en este contexto, pero hablemos de los dispositivos finales en términos de su función , y cuántos de ellos y cómo interactúan quedarán fuera de los paréntesis por ahora.

Entonces, el intuitivo "hacerlo más cálido" o "activar el modo económico cuando nos vamos" es bastante obvio.

Hubs

En vista de los pensamientos previos sobre qué son las cosas, los centros son esencialmente una fábrica de cosas aún más virtuales. Es el centro que puede crear un termostato cuando ya hay sensores de temperatura y cabezales en los radiadores. Puede crear un dispositivo "todo el mundo", que se puede apagar. Es divertido, pero el concentrador puede ser absolutamente virtual, por ejemplo, en EIB o KNX, el concepto básico es una dirección de grupo: el sensor le envía datos y el actuador recibe una o más direcciones de grupo para cada función. Por lo tanto, si a la salida del apartamento tiene un interruptor que envía a un estado 1/1/1 0, y en cada uno de los actuadores responsables de la luz está presente (junto con más individual, digamos, 1/0 / 11, 1/0/12, etc.) tendrá ese dispositivo "apaga el mundo entero" sin dispositivos físicos adicionales.

En este ejemplo, el concentrador es la red misma, en otros casos, el concentrador a menudo existe en el mundo físico como un dispositivo físico separado, pero puede dar otro buen ejemplo de un concentrador "no muy físico": este es Node-RED.

Le pido que preste especial atención al hecho de que intencionalmente no digo cómo los flujos de datos de dispositivos ya existentes ingresan a este mismo centro y cómo fluyen de él a otras partes del sistema. Otros objetos del sistema (puertas de enlace) son responsables de esta función.

Pasarelas

Dio la casualidad de que en los últimos 40-50 años, se han creado muchas redes que son diferentes en topología y nivel de abstracción (con sus propios protocolos), que de una forma u otra pueden ser parte del sistema de Internet de las cosas. Para conectar 2 redes, se crea un nodo de intercambio de tráfico, si dicho nodo empaqueta todos los datos de un protocolo en otro, es habitual llamarlo un túnel, ya que, por otro lado, puede hacer que todo el flujo funcione como si fuera local, si se produce un reemplazo. abstracciones, entonces dicho nodo se llama puerta de enlace.

Dado que tenemos bastante fluidez en la terminología en esta publicación, usemos el término puerta de enlace y dediquemos un poco más de tiempo a analizar desde dónde y dónde los dispositivos realmente existentes realmente la puerta de enlace. Todos los que trabajaron con sistemas de control de procesos tarde o temprano ampliaron las redes "centrales" con otras adicionales, por ejemplo, muchos medidores se conectaron a Profibus en Modbus.

Este es un caso bastante resuelto y no puede detenerse demasiado, pero ¿a dónde se bloquea la puerta de enlace multifuncional Xiaomi Mijia? Me gustaría decir que desde ZigBee hasta Wi-Fi, pero esto no es del todo cierto. Sí, en un lado de la puerta de enlace hay una red ZigBee, pero incluso si conecta un dispositivo de terceros, no podrá acceder a ella a través de esta puerta de enlace. Hay Wi-Fi en el otro lado de la puerta de enlace, pero la puerta de enlace no solo proporciona comunicaciones de red de área local utilizando el protocolo (que los hackers llamaron protocolo miIO), sino también con la nube Xiaomi, que garantiza el funcionamiento de la aplicación Mi Home cuando abandonas la red local. Otra puerta de enlace muy interesante es Samsung SmartThings, pero hay dificultades.

Si antes había una pregunta de por qué Groovy con toda su diversidad, ahora llamaría a la dificultad de la oferta a la nubosidad.

Explicaré mi posición, con la esperanza de estar equivocado. Al crear un nuevo dispositivo compatible con el ecosistema Samsung SmartThings, puede elegir 2 opciones: conectarse a un concentrador, o directamente a la nube, si desea crear automatización, el que mencioné anteriormente como el dispositivo generado por el concentrador, se movió a la nube. El punto Es decir, hay una violación del Manifiesto. No encenderá la luz en el inodoro si Internet no funciona para usted, ya sea a través de la aplicación (aparentemente no hay más esperanzas localmente, según el diagrama en el artículo IoT y Tizen IoT ), ni localmente desde el sensor de movimiento de otra red, porque necesita integrar el dispositivo y no una red, de lo contrario a través de la nube.

Aquellos que lograron trabajar con Tizen IoT, corríjanme, por favor.

Una situación similar es con Logitech Harmony, que rompió la automatización local después de la actualización.

Si descartamos las puertas de enlace del tipo "red de automatización - red de automatización", entonces lo más importante en el funcionamiento de la puerta de enlace es la abstracción objetivo, en la que traduce la presentación de dispositivos desde la red central, y esto ya está determinado por las nubes de datos.

Nubes de datos

Este es el objeto más obvio y no obvio del sistema al mismo tiempo. Sus funciones y su necesidad son obvias, pero la forma exacta en que se implementa este componente es la menos obvia y no depende de los deseos del usuario final.

Por lo tanto, prefiero completar esta parte de mi lista de deseos y pensamientos personales.

Es bueno cuando hay una API comprensible y simple, es aún mejor cuando esta API está abierta y es fácil conectarse a ella.

Aquí haré una reserva sobre la simplicidad. La simplicidad, si no se habla de matemáticas, es subjetiva en principio. Mi opinión personal se basa en mi experiencia y mis deseos. Por supuesto, para una empresa que lanzará un determinado producto por la cantidad de varios cientos de miles de simplicidades es completamente diferente.

Quiero que pueda tejer los resultados de mi pasatiempo en el mundo que me rodea. ¿Qué se requiere para esto?

El principal recurso limitante es el tiempo, el segundo es el conocimiento, el tercero es el dinero. Si no puedo hacer un dispositivo que de alguna manera funcione a través de la nube en un día, se hará "más tarde", siempre que sea sinónimo de "Mayy Chumorrow" y "Magnyana". Ahora, si funciona de alguna manera, luego de un par de días libres, tal vez funcione como debería. IoT es de naturaleza interdisciplinaria, y aquí debe crear un servidor OAuth2, agregar certificados, implementar la API, y todo esto se hace para hacer mi pequeño microcontrolador casero con asistente de voz, sobre el que escribiré en la próxima parte.

Los pensamientos anteriores eran más sobre "¿Cómo?", Pero el problema no menos importante (esto no es un desafío, es decir, el problema) reside en "¿Qué?".

Dividiría todas las nubes de datos principales que se pueden usar para IoT en dos clases: puntos de datos y capacidades.

Nube de puntos de datos . Esta es una evolución paralela con el mundo SCADA o un descendiente directo.

Aquí tienes las lecturas del sensor de temperatura, bueno, escribámoslo en algún lugar de la nube, donde el que necesita leerlo. El sensor de temperatura está en la batería, lo que significa que aún necesita mantener el nivel de carga; no importa, vea más arriba. Hay clases enteras de nubes que te permiten hacer esto. Se pueden reconocer fácilmente si el protocolo principal es MQTT (pero puede ser CoAP y STOMP). Una cosa maravillosa: yo mismo lo uso y no solo en IoT, llamándolo el "triunfo de la libertad sobre el sentido común". Es solo que los protocolos son tan flexibles que todos resuelven el mismo problema a su manera.

Una nube de datos en forma de oportunidades . Admito, hace unos 8-9 años, cuando estaba escribiendo la próxima versión de mi plataforma de inicio, quería tomar y clasificar objetos en el sistema. Para que el sistema entienda que se trata de una bombilla, y esto es un interruptor, y esto es una válvula. La primera iteración obvia: una lista de tipos (pero de hecho clases, porque OOP es lo mismo). Luego aparece un interruptor, pero en la batería el poder de OOP está en acción, por lo que heredamos y obtuvimos uno nuevo. Y luego resultó que la batería podría ser cualquier cosa. Entonces fue necesario cortar no en un árbol de clases de dispositivos, sino dividir en las "capacidades" de los dispositivos, combinando lo que obtenemos un interruptor.

Así es como funcionan Apple HomeKit, Alexa, Google y otros ecosistemas en la nube de hogares inteligentes. Parecería que es la felicidad.

Pero, como dije anteriormente, usé este enfoque hace 8-9 años. Y yo mismo determiné estas características, quería agregar una cámara IP o Asterisk PBX. Genial Terminé y trabaja.

Pero aquí está la desgracia, los ecosistemas de nubes de los hogares inteligentes enumerados anteriormente son en realidad ecosistemas no de IoT, sino ecosistemas de asistentes de voz, cuyas capacidades deberían ser universales para todo el mundo y para todos los dispositivos. Agregar nuevas funciones al proceso es significativamente diferente de mi "Agregado y funciona". Todos recordamos cómo en los albores de estos ecosistemas tuvieron que "encender la puerta". La situación es similar con SmartThings.

Ningún fabricante puede proporcionar una lista clara y exhaustiva de capacidades para los dispositivos que se pueden lanzar y formar parte del ecosistema de IoT. Es por eso que los sistemas como el porcentaje de grasa visceral, azúcar en la sangre o acetona no tienen la capacidad de saber qué. ¿Por qué la casa no puede apoyarte con ilusiones alegres cuando todo está bien o llamar tu atención cuando algo sale mal?

Por otro lado, ¿cómo crear interfaces de usuario sin comprender lo que puede hacer un dispositivo? El enfoque del punto de datos en SCADA fue conveniente para ocultar las características topológicas y de protocolo. Para recibir datos (lista horizontal) con algunas propiedades adicionales, por ejemplo, confiabilidad (si hubo una desconexión en el camino) o niveles de acceso, pero su presentación principal fue en forma de diagramas mnemónicos.

Pero los usuarios de IoT viven en la era posterior a la PC y los circuitos mnemónicos son inconvenientes en las pantallas de los teléfonos, y su configuración es imperdonablemente larga.

Creo que debería haber una cierta hibridación. Primero, el sistema debe saber qué es el dispositivo y debe tener puntos de datos. Sin embargo, no menos importante es que también debe haber metainformación adicional que se debe entregar a una nube especializada, por ejemplo, su asistente de voz favorito. Dicha información, en particular, puede incluir tanto el perfil (conjunto de capacidades) del dispositivo, en la comprensión de la nube externa, como sus identificadores.

La función del fabricante del dispositivo será describir, entre otras cosas, las prestaciones deseadas para este producto tanto para las interfaces visuales como para otros tipos: interacción de voz, AR / VR y similares. Pero, incluso si el fabricante no hizo esto, a regañadientes y abrumado por la pereza, el usuario aún puede elegir lo que este dispositivo de Google puede conocer a partir de ahora como "Smart Home Kettle" y ahora tiene tales características: TemperatureControl, OnOff, Modes y Palancas Sí, dejé caer action.devices.traits por compacidad.

Eso es para asegurar que la interoperabilidad ya debe integrar los servicios.

Servicios de integracion

Esta es la misma puerta de entrada, pero entre las nubes. Algunas abstracciones deben ser reemplazadas por otras.

La base de la interacción es un evento. Hay modelos de consulta y publicaciones. El tema es tan vasto que puede caer en la trampa de Bollywood al describirlo. Allí, como saben, se producen más películas por año de las que físicamente una persona puede ver,
por lo tanto, al final del artículo estaré aún más lejos de la realidad que en el momento en que comienza la descripción.

Ya mencioné muchos sistemas domésticos, puede recordar LoRaWAN (y TheThingsNetwork), IFTTT, OpenStreetMap, AWS IoT, Azure IoT, servicios meteorológicos, sí, de hecho, casi cualquier servicio de Internet o Intranet (¿hay algún otro término?), Si los datos del dispositivo debe entrar en los sistemas corporativos.

Interfaces de usuario

No describiré profundamente esta parte, pero quiero lamentarme, inmerecidamente en mi opinión, eludida por los sistemas domésticos de IoT, los escritorios. Solo en Mojave HomeKit finalmente salió, para mí esto es desconcertante. ¿Por qué el hervidor es más complicado que las hojas de cálculo en las que puedo calcular el flujo de efectivo de alguna empresa? Después de todo, con Numbers puedo trabajar en un navegador, pero no tengo que apagar una plancha olvidada, en el entendimiento de Apple. En resumen, ¡dale PWA!

Las interfaces de usuario son principalmente conmutadores físicos convenientes, pero son imperdonablemente pocos.

AR, VR, Realidad mixta, asistentes de voz, televisores inteligentes, aplicaciones para teléfonos inteligentes y tabletas, las interfaces neuronales EEG son cerezas en el pastel, con las que somos muy divertidos.

Epílogo

Parece, ¿qué tienen que ver Docker y los microservicios? Si será interesante para los lectores, con gusto compartiré mis pensamientos y desarrollos en la implementación de la arquitectura del sistema IoT basada en esta clasificación de objetos.

Lo uso yo mismo.