Tarea
En Synergy Team, diseñamos y fabricamos controladores industriales. Están diseñados para la contabilidad de recursos, la gestión de la energía y otras aplicaciones, que se conocen comúnmente como Internet de las cosas (IoT). A menudo, nuestros clientes no solo necesitan controladores. Necesitan una solución completa que incluya un sistema de control.
Y este sistema debería ser casi óptimo: rápido, ligero y fiable. Pero, según la conocida anécdota, es imposible cumplir simultáneamente todos estos requisitos. Necesitamos buscar un equilibrio en función de la tarea que intentamos hacer.
En esta publicación, nos limitamos a la clase de tareas cuando los controladores de IoT están conectados directamente al sistema de control ( IoT conectado directamente ). Entonces, nuestra tarea es desarrollar un sistema de gestión que debería:
- transferir datos de sensores conectados a controladores,
- enviar eventos (por ejemplo, sobre aumento de temperatura, apertura de puertas, pérdida de comunicación, etc.),
- transmitir comandos de control a los actuadores,
Si el sistema consta de una gran cantidad de objetos y / o realiza tareas importantes, además debe:
- monitorear constantemente la presencia de comunicación con objetos,
- recopilar estadísticas sobre su trabajo,
- actualizar la configuración y el software del controlador (a pedido);
- estar protegido del acceso no autorizado. Para las empresas estatales y grandes privadas, el sistema también debe cumplir con la legislación sobre trabajo con infraestructura de información crítica (CII). En particular, los requisitos de 187-FZ, FSB, FSTEC, órdenes del Ministerio de Telecomunicaciones y Comunicaciones Masivas, etc.
Gestión sin servidor dedicado
Para varios objetos, el problema se resuelve simplemente con el control de la red GSM mediante comandos SMS o llamadas. Este enfoque fue popular a principios de la década de 2010, y sus pros y contras se describen, por ejemplo, aquí . Para los sistemas más serios, este enfoque está perdiendo su relevancia hoy.
Un poco más complicado es el control "manual" de los controladores a través de IP dedicada a través de la WEB o la línea de comandos (CLI). Los controladores deben estar conectados permanentemente a la red, tener direcciones IP estáticas "blancas" o "grises". Alternativamente, puede usar IP dinámica con enlace a nombres de dominio estáticos usando tecnología DynDNS o similar . Esto funciona bien si hay pocos objetos y no hay requisitos especiales de confiabilidad.
Desventajas:
- , WEB () ;
- IP ;
- , NAT;
- IP . , GSM APN ;
- , «»;
- ().
Para demostraciones rápidas, control sobre varios objetos, basta con usar el control por IP, SMS o llamadas telefónicas.
Aquí no consideramos la situación cuando un despachador se ejecuta en la misma computadora y se instala un sistema de control, ya que lo consideramos un caso degenerado del siguiente elemento.
Gestión de servidor dedicado
En los casos restantes, necesita un servidor con una IP dedicada, a través del cual se conectarán controladores, despachadores y sistemas de terceros.
Si los controladores transmiten datos solo en la dirección del servidor, por ejemplo, medidores de agua o los dispositivos de navegación más simples (rastreadores), una conexión unidireccional es suficiente. En este caso, los controladores solo necesitan conocer la IP del servidor.
En nuestra tarea, se requiere un intercambio de datos bidireccional para actualizar el software del controlador y transmitir comandos. Para organizar dicho intercambio, debe:
- lectura periódica de configuraciones o comandos del servidor a iniciativa del controlador (aceptable si no necesita una respuesta rápida a los comandos), o
- usando IP estática o nombres de dominio en los controladores para que el servidor pueda "alcanzarlos" por sí mismo, o
- , . , MQTT, EGTS ( ). IP. , .
Cuando se trata de un sistema de control basado en una solución probada y confiable, SCADA es lo primero que debe recordar. Y esto está plenamente justificado cuando se trata de la automatización de la producción o de una gran instalación energética. En una palabra, cuando el sistema contiene una gran cantidad de sensores y actuadores de varios tipos. Dichos sistemas requieren el desarrollo de diagramas y algoritmos mnemónicos únicos para la interacción de equipos para cada objeto, lo cual está perfectamente pensado en SCADA.
Si necesita monitorear y / o administrar objetos del mismo tipo (como en la tarea propuesta), entonces el uso de SCADA puede hacer que la solución sea demasiado "pesada" debido a la complejidad de la configuración, la laboriosidad de agregar objetos estándar y los mayores requisitos para el rendimiento del servidor. Es mejor utilizar uno de los sistemas de cajas especializados del mercado que sea más adecuado para la tarea. Por ejemplo:
- sistema de control y supervisión de equipos de red - Sistema de gestión de redes (SNMP, TR-069, CLI);
- Sistema de medición automatizado de calor, electricidad, gas, agua. Por brevedad - ASKUE;
- sistema de seguimiento de navegación para objetos móviles con control de sistemas a bordo;
- sistema de control de clima (ventilación, aire acondicionado y calefacción) - HVAC;
- sistema inteligente de hogar / oficina / edificio;
- : , () , ;
- - , ..
Estos sistemas a menudo se superponen entre sí. Por ejemplo, sobre la base de ASKUE es posible implementar el control de la iluminación exterior, y sobre la base de la "Smart House" para controlar el clima y el acceso. La expansión de la funcionalidad de los sistemas "vivos" está en curso. Están surgiendo nuevas API para integrar productos empaquetados en soluciones para clientes, así como soporte para funciones personalizadas en software empaquetados. Una gran ventaja de los productos en caja es el hecho de que se pueden comprar y poner en su servidor, habiendo recibido una solución alienada que funciona en un circuito cerrado de clientes.
Si tiene planes de vender su propio sistema en el mercado libre, debe comprender que mañana puede surgir un competidor del proveedor de software en caja de hoy. Además, el uso de sistemas de caja conlleva riesgos adicionales como:
- aumento del precio de las licencias,
- control débil sobre el sistema (no hay código fuente, incluso si lo hay, es extremadamente difícil de mantener),
- muchos sistemas solo pueden usarse como un servicio en la nube, lo que puede ser inaceptable para proyectos grandes y / o gubernamentales.
Desarrollo basado en plataformas IoT
Si no es posible usar software en caja, sería una buena idea desarrollar en una de las plataformas de IoT más populares . Dichas plataformas contienen módulos universales necesarios en cualquier sistema de IoT para:
- registro y eliminación de dispositivos IoT,
- autenticación segura de dispositivos IoT y mantenimiento de la comunicación con ellos,
- trabajar con datos (bases de datos optimizadas para diferentes tareas),
- registro de usuarios y gestión de derechos de acceso,
- formación de análisis basados en los datos recopilados,
- generar notificaciones para los usuarios (SMS, E-Mail, mensajes push, ...),
- almacenar los datos más recientes leídos desde dispositivos IoT,
- realizar diversas acciones sobre eventos,
- visualización de datos, etc.
La arquitectura de un sistema en una plataforma IoT es prácticamente independiente de su tamaño. Todas las tareas relacionadas con el equilibrio de carga, la eliminación de los "frenos" de la base de datos y las funciones "pesadas" son realizadas por la plataforma. Además, el lado del servidor de la aplicación se ensambla rápidamente a partir de "cubos": microservicios. Se reducen tanto el time to market como el coste de la solución, que depende directamente del pago del trabajo de los programadores.
Un sistema en una plataforma de IoT se puede desarrollar en un tiempo mínimo. Su arquitectura no cambiará mucho con el aumento de tamaño.
Ventajas de desarrollar en una plataforma de IoT basada en la nube:
- . AWS . . .
- , , , MQTT- – . , .
- IoT . ( ) ( IoT ).
- .
- la tarea de desarrollo principal puede subcontratarse. En el futuro, la solución podrá admitir no solo a los desarrolladores del sistema original, como suele ser el caso. Después de todo, las plataformas de IoT cuentan con un poderoso soporte técnico, están bien documentadas y la cantidad de desarrolladores que pueden trabajar con ellas crece constantemente.
Desventajas:
- los componentes de las plataformas de IoT operan solo en las instalaciones de sus propietarios, crean un sistema completamente alienable que funcionará en el centro de datos del cliente, posiblemente en casos excepcionales;
- el costo de usar una plataforma de IoT para proyectos grandes puede ser más alto que el costo de alquilar máquinas virtuales en un centro de datos;
- La migración de una plataforma de IoT a otra implica cambiar una cantidad decente de código. Aunque ahora existe una tendencia hacia la estandarización de API;
- De ninguna manera todas las plataformas de IoT se implementan en centros de datos dentro de Rusia, lo que hace que sea imposible utilizarlas en interés de los clientes gubernamentales.
Desarrollo completamente propio
Si las deficiencias de las soluciones anteriores son críticas, debe desarrollar su propia solución. Y no importa qué tan bueno sea el plan, las primeras versiones del sistema estarán torcidas.
Las soluciones propias a menudo se implementan sobre la base de sistemas de código abierto como ThingsBoard, OpenSCADA, MajorDoMo, Home Assistant, iobroker, Nokia glial. Para proyectos pequeños, pueden ser demasiado "pesados" debido a:
- largo tiempo de desarrollo y los correspondientes costos financieros. Por lo general, el recuento se realiza en años-persona;
- a medida que crece el número de objetos, surgirán cuellos de botella en forma de bases de datos lentas, recolectores, generadores de informes, etc., para cuya resolución será necesario cambiar la arquitectura y complementarla con balanceadores y recursos duplicados;
- costos de administración y soporte técnico continuos.
Al mismo tiempo:
Su desarrollo se justifica ya sea por órdenes gubernamentales, o proyectos con planes ambiciosos y grandes presupuestos, o cuando la independencia y la seguridad son críticas.
Si necesita una demostración rápida ( MVP ), puede hacerlo en una plataforma de IoT o en un software en caja, adoptando enfoques probados en el tiempo, mientras desarrolla su propia gran solución en paralelo.
Conclusión
A partir del análisis de diferentes sistemas, proponemos el siguiente algoritmo de selección del sistema de control.
Para demostraciones y pequeños proyectos de IoT para varios objetos, puede utilizar el control directo sobre IP, SMS o mediante llamadas GSM. De lo contrario, se requiere un sistema de nivel superior. El uso de SCADA está justificado en la automatización industrial y en grandes instalaciones energéticas. Para contabilidad de recursos, gestión de equipos de red, seguimiento, seguridad, "hogar inteligente", etc. es conveniente utilizar una solución en caja de la especialización requerida. Desarrollar sistemas en plataformas IoT es más difícil, pero brinda más perspectiva y flexibilidad. Las soluciones en plataformas de IoT extranjeras están seriamente limitadas en escala y áreas de aplicación en Rusia. Lo más difícil es el desarrollo completamente propio. Y está justificado solo por órdenes gubernamentales y los proyectos más ambiciosos.Al mismo tiempo, para realizar demostraciones rápidas y copiar las mejores prácticas, será útil, en paralelo con su propio desarrollo, realizar un borrador de diseño en la plataforma IoT.
Por último, queremos compartir una pequeña previsión:
- en las plataformas IoT en la nube, vale la pena esperar la aparición de plantillas preconfiguradas para "Smart Home", ASKUE, NMS, ACS, etc. Esto simplificará aún más el uso de las plataformas de IoT y atraerá a una audiencia aún mayor.
- Los desarrolladores tradicionales de SCADA y otras soluciones en caja ofrecerán más herramientas para desarrolladores externos que hayan demostrado su valía en las plataformas de IoT. Es poco probable que las soluciones de caja cerrada resistan la competencia del mercado.
- Las plataformas de IoT nacionales para grandes clientes públicos y privados se desarrollarán aún más activamente.
- Las API de diferentes plataformas de IoT se volverán más similares con el tiempo. Debido a esto, se simplificará la transición de una plataforma de IoT a otra.
En el próximo post, más técnico, hablaremos de nuestro proyecto de monitorización de sistemas de comunicación en la plataforma AWS y controladores GIC .
Asegúrese de escribir en los comentarios si nos perdimos algo importante. Uno de los objetivos de nuestro blog es obtener comentarios constructivos.