En el último episodio...
Hace aproximadamente un año yo sobre la gestión del alumbrado urbano en una de nuestras ciudades. Allí todo era muy sencillo: según un horario, la alimentación de las lámparas se encendía y apagaba a través de SHUNO (gabinete de control de iluminación externo). Había un relevo en el SHUNO, tras cuya orden se encendía la cadena de luces. Quizás lo único interesante es que esto se hizo a través de LoRaWAN.
Como recordarás, inicialmente nos basamos en módulos SI-12 (Fig. 1) de la empresa Vega. Ya en la fase piloto tuvimos problemas inmediatamente.
Figura 1. — Módulo SI-12
- Dependíamos de la red LoRaWAN. Una interferencia grave en el aire o una caída del servidor y tenemos un problema con la iluminación de la ciudad. Improbable, pero posible.
- SI-12 sólo tiene una entrada de impulsos. Puede conectarle un medidor eléctrico y leer las lecturas actuales. Pero en un corto período de tiempo (5-10 minutos) es imposible rastrear el salto en el consumo que se produce después de encender las luces. A continuación explicaré por qué esto es importante.
- El problema es más grave. Los módulos SI-12 seguían congelados. Aproximadamente una vez cada 20 operaciones. Junto con Vega, intentamos eliminar la causa. Durante el piloto, se lanzaron dos nuevos firmware de módulo y una nueva versión del servidor, donde se solucionaron varios problemas graves. Al final, los módulos dejaron de colgarse. Y, sin embargo, nos alejamos de ellos.
Y ahora...
De momento hemos construido un proyecto mucho más avanzado.
Se basa en módulos IS-Industry (Fig. 2). El hardware fue desarrollado por nuestro subcontratista, el firmware lo escribimos nosotros mismos. Este es un módulo muy inteligente. Dependiendo del firmware que tenga cargado, puede controlar la iluminación o interrogar a los dispositivos de medición con un gran conjunto de parámetros. Por ejemplo, contadores de calor o contadores de electricidad trifásicos.
Algunas palabras sobre lo que se ha implementado.
Figura 2. — Módulo IS-Industry
1. A partir de ahora IS-Industry tiene su propia memoria. En el firmware ligero se cargan de forma remota las llamadas estrategias en esta memoria. En esencia, este es un cronograma para encender y apagar SHUNO durante un período determinado. Ya no dependemos del canal de radio a la hora de encenderla y apagarla. Dentro del módulo hay un horario según el cual funciona independientemente de cualquier cosa. Cada ejecución va necesariamente acompañada de un comando al servidor. El servidor debe saber que nuestro estado ha cambiado.
2. El mismo módulo puede interrogar el medidor de electricidad en SHUNO. Cada hora se reciben paquetes con el consumo y un montón de parámetros que puede generar el contador.
Pero ese no es el punto. Dos minutos después del cambio de estado, se envía un comando extraordinario con lecturas instantáneas del contador. A partir de ellos podemos juzgar si la luz realmente se encendió o apagó. O algo salió mal. La interfaz tiene dos indicadores. El interruptor muestra el estado actual del módulo. La bombilla está ligada a la ausencia o presencia de consumo. Si estos estados se contradicen (el módulo está apagado, pero el consumo continúa y viceversa), entonces la línea con SHUNO se resalta en rojo y se crea una alarma (Fig. 3). En otoño, un sistema de este tipo nos ayudó a encontrar un relé de arranque atascado. De hecho, el problema no es nuestro, nuestro módulo funcionó correctamente. Pero trabajamos en interés del cliente. Por ello, deben mostrarle cualquier accidente que pueda provocar problemas con la iluminación.
Figura 3. — El consumo contradice el estado del relé. Por eso la línea está resaltada en rojo.
Los gráficos se construyen en base a lecturas horarias.
La lógica es la misma que la última vez. Vigilamos el hecho del encendido aumentando el consumo eléctrico. Realizamos un seguimiento del consumo medio. Un consumo por debajo de la mediana significa que algunas luces se han quemado, y por encima significa que se está robando electricidad del poste.
3. Paquetes estándar con información sobre el consumo y que el módulo se encuentra en regla. Vienen en diferentes horarios y no crean aglomeración en el aire.
4. Como antes, podemos forzar el encendido o apagado de SHUNO en cualquier momento. Es necesario, por ejemplo, que un equipo de emergencia busque en una cadena una lámpara fundida.
Estas mejoras aumentan significativamente la tolerancia a fallos.
Este modelo de gestión es quizás ahora el más popular en Rusia.
Y también...
Caminamos más.
El hecho es que puedes alejarte completamente de SHUNO en el sentido clásico y controlar cada lámpara individualmente.
Para ello es necesario que la linterna admita el protocolo de atenuación (0-10, DALI o algún otro) y disponga de conector Nemo-socket.
Nemo-socket es un conector estándar de 7 pines (en la Fig. 4), que se utiliza a menudo en el alumbrado público. Los contactos de alimentación y de interfaz salen de la linterna a este conector.
Figura 4. — Zócalo Nemo
0-10 es un protocolo de control de iluminación bien conocido. Ya no es joven, pero está bien probado. Gracias a los comandos que utilizan este protocolo, no sólo podemos encender y apagar la lámpara, sino también ponerla en modo atenuación. En pocas palabras, atenúe las luces sin apagarlas por completo. Podemos atenuarlo en un determinado valor porcentual. 30 o 70 o 43.
Funciona así. Nuestro módulo de control está instalado encima del enchufe Nemo. Este módulo admite protocolo 0-10. Los comandos llegan vía LoRaWAN a través de un canal de radio (Fig. 5).
Figura 5. — Linterna con módulo de control
¿Qué puede hacer este módulo?
Puede encender y apagar la lámpara, atenuarla hasta cierta cantidad. Y también puede realizar un seguimiento del consumo de la lámpara. En el caso de la regulación se produce una caída del consumo actual.
Ahora no solo estamos rastreando una serie de linternas, estamos administrando y rastreando CADA linterna. Y, por supuesto, para cada una de las luces podemos obtener un error determinado.
Además, puedes complicar significativamente la lógica de las estrategias.
P.ej. Le decimos a la lámpara número 5 que debe encenderse a las 18:00, a las 3:00 atenuarla en un 50 por ciento a 4-50, luego encenderla nuevamente al cien por ciento y apagarla a las 9:20. Todo esto se configura fácilmente en nuestra interfaz y se plasma en una estrategia operativa comprensible para la lámpara. Esta estrategia se carga en la lámpara y funciona según ella hasta que llegan otros comandos.
Como en el caso del módulo para SHUNO, no tenemos problemas de pérdida de comunicación por radio. Incluso si le sucede algo crítico, la iluminación seguirá funcionando. Además, no hay prisa en el aire en el momento en que es necesario encender, digamos, cien lámparas. Podemos recorrerlos fácilmente uno a uno, tomando lecturas y ajustando estrategias. Además, se configuran paquetes de señalización a ciertos intervalos que indican que el dispositivo está activo y listo para comunicarse.
El acceso no programado sólo se producirá en caso de emergencia. Afortunadamente, en este caso tenemos el lujo de una alimentación constante y podemos permitirnos la clase C.
Una pregunta importante que volveré a plantear. Cada vez que presentamos nuestro sistema, me preguntan: ¿qué pasa con el relevo fotográfico? ¿Se puede atornillar allí un relé fotográfico?
Desde el punto de vista puramente técnico, no hay problemas. Pero todos los clientes con los que nos comunicamos actualmente se niegan categóricamente a recibir información de fotosensores. Piden operar sólo con un horario y fórmulas astronómicas. Aún así, la iluminación urbana es crítica e importante.
Y ahora lo más importante. Economía.
Trabajar con SHUNO a través de un módulo de radio tiene claras ventajas y un coste relativamente bajo. Aumenta el control sobre las luminarias y simplifica el mantenimiento. Aquí todo está claro y los beneficios económicos son evidentes.
Pero con el control de cada lámpara se vuelve cada vez más difícil.
En Rusia hay varios proyectos similares terminados. Sus integradores informan con orgullo que lograron ahorrar energía mediante la regulación y, por lo tanto, pagaron el proyecto.
Nuestra experiencia demuestra que no todo es tan sencillo.
A continuación proporciono una tabla que calcula el retorno de la inversión por atenuación en rublos por año y en meses por lámpara (Fig. 6).
Figura 6. — Cálculo de ahorros por atenuación
Muestra cuántas horas al día están encendidas las luces, en promedio por mes. Creemos que aproximadamente el 30 por ciento de este tiempo la lámpara brilla al 50 por ciento de potencia y otro 30 por ciento al 30 por ciento de potencia. El resto está a pleno rendimiento. Redondeado a la décima más cercana.
Para simplificar, considero que en el modo de 50 por ciento de potencia la luz consume la mitad de lo que consume en el 100 por ciento. Esto también es un poco incorrecto, porque hay un consumo del conductor, que es constante. Aquellos. Nuestros ahorros reales serán menores que en la tabla. Pero para facilitar la comprensión, que así sea.
Supongamos que el precio del kilovatio de electricidad es de 5 rublos, el precio medio para las personas jurídicas.
En total, en un año puedes ahorrar de 313 rublos a 1409 rublos en una lámpara. Como puedes ver, en dispositivos de bajo consumo el beneficio es muy pequeño; con iluminadores potentes es más interesante.
¿Qué pasa con los costos?
El aumento de precio de cada linterna, al añadirle un módulo LoRaWAN, es de unos 5500 rublos. Allí, el módulo en sí cuesta alrededor de 3000, más el costo del Nemo-Socket en la lámpara es de otros 1500 rublos, más el trabajo de instalación y configuración. Todavía no tengo en cuenta que para este tipo de lámparas hay que pagar una cuota de suscripción al propietario de la red.
Resulta que la recuperación del sistema en el mejor de los casos (con la lámpara más potente) es de poco menos de cuatro años. Recuperación de la inversión. Por mucho tiempo.
Pero incluso en este caso, todo quedará anulado por la tarifa de suscripción. Y sin él, el coste seguirá incluyendo el mantenimiento de la red LoRaWAN, que tampoco es barato.
También se consiguen pequeños ahorros en el trabajo de los equipos de emergencia, que ahora planifican su trabajo de forma mucho más óptima. Pero ella no salvará.
¿Resulta que todo es en vano?
No. De hecho, la respuesta correcta aquí es esta.
Controlar cada alumbrado público es parte de una ciudad inteligente. Esa parte que realmente no ahorra dinero, y por la que incluso hay que pagar un poco más. Pero a cambio recibimos algo importante. En tal arquitectura, tenemos energía constante garantizada en cada polo las XNUMX horas del día. No sólo de noche.
Casi todos los proveedores se han encontrado con el problema. Necesitamos instalar wifi en la plaza principal. O videovigilancia en el parque. La administración da luz verde y asigna apoyos. Pero el problema es que hay postes de iluminación y allí sólo hay electricidad por la noche. Tenemos que hacer algo complicado, llevar energía adicional a lo largo de los soportes, instalar baterías y otras cosas extrañas.
En el caso de controlar cada farol, podemos fácilmente colgar algo más en el poste con el farol y hacerlo “inteligente”.
Y aquí nuevamente surge una cuestión de economía y aplicabilidad. En algún lugar de las afueras de la ciudad, SHUNO es suficiente para la vista. En el centro tiene sentido construir algo más complejo y manejable.
Lo principal es que estos cálculos contienen números reales y no sueños sobre el Internet de las cosas.
PS A lo largo de este año, pude comunicarme con muchos ingenieros involucrados en la industria de la iluminación. Y algunos me demostraron que todavía hay economía en el manejo de cada lámpara. Estoy abierto a la discusión, se dan mis cálculos. Si puedes demostrar lo contrario, definitivamente escribiré sobre ello.
Fuente: habr.com