Notas dun provedor de IoT. Tecnoloxía e economía de LoRaWAN na iluminación urbana

No último episodio...

Fai aproximadamente un ano eu escribiu sobre a xestión da iluminación urbana nunha das nosas cidades. Alí todo era moi sinxelo: segundo unha programación, a enerxía das lámpadas acendeuse e apagaba a través de SHUNO (armario de control de iluminación externa). Había un relevo no SHUNO, a cuxa orde se acendeu a cadea de luces. Quizais o único interesante é que isto se fixo a través de LoRaWAN.

Como lembrades, inicialmente construímos módulos SI-12 (Fig. 1) da empresa Vega. Incluso na fase piloto, inmediatamente tivemos problemas.

Notas dun provedor de IoT. Tecnoloxía e economía de LoRaWAN na iluminación urbana
Figura 1. — Módulo SI-12

  1. Dependiamos da rede LoRaWAN. Interferencias graves no aire ou fallo do servidor e temos un problema coa iluminación da cidade. Improbable, pero posible.
  2. SI-12 só ten unha entrada de pulso. Podes conectarlle un contador eléctrico e ler as lecturas de corrente. Pero nun curto período de tempo (5-10 minutos) é imposible rastrexar o salto de consumo que se produce despois de acender as luces. A continuación explicarei por que isto é importante.
  3. O problema é máis grave. Os módulos SI-12 mantivéronse conxelados. Aproximadamente unha vez cada 20 operacións. En conxunto con Veiga, tentamos eliminar a causa. Durante o piloto lanzáronse dous novos firmware de módulo e unha nova versión do servidor, onde se solucionaron varios problemas graves. Ao final, os módulos deixaron de colgar. E aínda así afastámonos deles.

E agora...

De momento construímos un proxecto moito máis avanzado.

Está baseado en módulos IS-Industria (Fig. 2). O hardware foi desenvolvido polo noso subcontratista, o firmware escribiuno nós mesmos. Este é un módulo moi intelixente. Dependendo do firmware que se cargue nel, pode controlar a iluminación ou interrogar dispositivos de medición cun gran conxunto de parámetros. Por exemplo, contadores de calor ou contadores de electricidade trifásicos.
Unhas palabras sobre o que se implantou.

Notas dun provedor de IoT. Tecnoloxía e economía de LoRaWAN na iluminación urbana
Figura 2. — Módulo IS-Industria

1. A partir de agora, IS-Industria ten a súa propia memoria. Co firmware lixeiro, as chamadas estratexias cárganse remotamente nesta memoria. En esencia, este é un horario para acender e apagar SHUNO durante un período determinado. Xa non dependemos da canle de radio á hora de acender e apagar. Dentro do módulo hai un horario segundo o cal funciona independentemente de calquera cousa. Cada execución vai necesariamente acompañada dun comando ao servidor. O servidor debe saber que o noso estado cambiou.

2. O mesmo módulo pode interrogar o contador de electricidade en SHUNO. Cada hora recíbense del paquetes con consumo e unha morea de parámetros que pode producir o contador.
Pero ese non é o punto. Dous minutos despois do cambio de estado, envíase un comando extraordinario con lecturas instantáneas do contador. A partir deles podemos xulgar que a luz realmente se acendeu ou se apagou. Ou algo saíu mal. Hai dous indicadores na interface. O interruptor mostra o estado actual do módulo. A bombilla está ligada á ausencia ou presenza de consumo. Se estes estados se contradín (o módulo está apagado, pero o consumo está en marcha e viceversa), entón a liña con SHUNO resáltase en vermello e créase unha alarma (Fig. 3). No outono, tal sistema axudounos a atopar un relé de arranque atascado. De feito, o problema non é noso, o noso módulo funcionou correctamente. Pero traballamos no interese do cliente. Por iso, deben amosarlle os accidentes que poidan causar problemas de iluminación.

Notas dun provedor de IoT. Tecnoloxía e economía de LoRaWAN na iluminación urbana
Figura 3. — O consumo contradí o estado do relé. É por iso que a liña está resaltada en vermello

Os gráficos constrúense en base a lecturas horarias.

A lóxica é a mesma que a última vez. Vixiamos o feito de acenderse aumentando o consumo eléctrico. Seguimos o consumo medio. O consumo por debaixo da media significa que algunhas das luces queimáronse, por riba significa que se está roubando electricidade do poste.

3. Paquetes estándar con información sobre o consumo e que o módulo está en regra. Veñen en diferentes momentos e non crean multitude no aire.

4. Como antes, podemos obrigar a SHUNO a acender ou apagar en calquera momento. É necesario, por exemplo, que un equipo de emerxencia busque unha lámpada queimada nunha cadea.

Tales melloras aumentan significativamente a tolerancia a fallos.
Este modelo de xestión é agora quizais o máis popular en Rusia.

E tamén...

Camiñamos máis aló.

O feito é que podes afastarte completamente de SHUNO no sentido clásico e controlar cada lámpada individualmente.

Para iso, é necesario que a lanterna admita o protocolo de atenuación (0-10, DALI ou algún outro) e dispoña dun conector Nemo-socket.

Nemo-socket é un conector estándar de 7 pinos (na figura 4), que se usa a miúdo na iluminación pública. Os contactos de enerxía e interface saen dende a lanterna a este conector.

Notas dun provedor de IoT. Tecnoloxía e economía de LoRaWAN na iluminación urbana
Figura 4. — Nemo-socket

0-10 é un protocolo de control de iluminación moi coñecido. Xa non novo, pero ben probado. Grazas aos comandos que utilizan este protocolo, non só podemos acender e apagar a lámpada, senón tamén cambiala ao modo de atenuación. Simplemente, atenua as luces sen apagalas por completo. Podemos atenualo nun determinado valor porcentual. 30 ou 70 ou 43.

Funciona así. O noso módulo de control está instalado encima do enchufe Nemo. Este módulo admite o protocolo 0-10. Os comandos chegan a través de LoRaWAN a través dunha canle de radio (Fig. 5).

Notas dun provedor de IoT. Tecnoloxía e economía de LoRaWAN na iluminación urbana
Figura 5. — Lanterna con módulo de control

Que pode facer este módulo?

Pode acender e apagar a lámpada, atenuala a unha certa cantidade. E tamén pode rastrexar o consumo da lámpada. No caso da atenuación, prodúcese unha baixada no consumo de corrente.

Agora non só estamos rastrexando unha serie de lanternas, senón que xestionamos e rastrexamos TODAS as lanternas. E, por suposto, para cada unha das luces podemos obter un certo erro.

Ademais, pode complicar significativamente a lóxica das estratexias.

Ex. Dicímoslle á lámpada número 5 que debe acenderse ás 18-00, ás 3-00 atenuar nun 50 por cento ata o 4-50, despois acenderse de novo ao cen por cento e apagarse ás 9-20. Todo isto configurase facilmente na nosa interface e confórmase nunha estratexia de funcionamento comprensible para a lámpada. Esta estratexia súbese á lámpada e funciona segundo ela ata que chegan outros comandos.

Como no caso do módulo para SHUNO, non temos problemas coa perda da comunicación por radio. Aínda que ocorra algo crítico, a iluminación seguirá funcionando. Ademais, non hai présa no aire no momento no que é necesario acender, por exemplo, cen lámpadas. Podemos percorrelos facilmente un por un, facendo lecturas e axustando estratexias. Ademais, os paquetes de sinalización están configurados a determinados intervalos que indican que o dispositivo está activo e listo para comunicarse.
O acceso non programado só se producirá en caso de emerxencia. Afortunadamente, neste caso temos o luxo da comida constante e podemos permitirnos a clase C.

Unha cuestión importante que volverei a plantexar. Cada vez que presentamos o noso sistema, pregúntanme: e o relé fotográfico? Pódese atornillar alí un relé de fotos?

Técnicamente, non hai problemas. Pero todos os clientes cos que nos estamos comunicando actualmente néganse categóricamente a tomar información dos sensores fotográficos. Pídenlle que opere só cun horario e fórmulas astronómicas. Aínda así, a iluminación urbana é fundamental e importante.

E agora o máis importante. Economía.

Traballar con SHUNO a través dun módulo de radio ten claras vantaxes e un custo relativamente baixo. Aumenta o control das luminarias e simplifica o mantemento. Aquí está todo claro e os beneficios económicos son evidentes.

Pero co control de cada lámpada faise cada vez máis difícil.

Hai varios proxectos similares completados en Rusia. Os seus integradores informan con orgullo de que conseguiron un aforro enerxético a través da regulación e así pagaron o proxecto.

A nosa experiencia demostra que non todo é tan sinxelo.

A continuación ofrécenos unha táboa que calcula o retorno de atenuación en rublos por ano e en meses por lámpada (Fig. 6).

Notas dun provedor de IoT. Tecnoloxía e economía de LoRaWAN na iluminación urbana
Figura 6. — Cálculo do aforro pola regulación

Mostra cantas horas ao día están acesas as luces, media por mes. Cremos que aproximadamente o 30 por cento deste tempo a lámpada brilla ao 50 por cento de potencia e outro 30 por cento ao 30 por cento de potencia. O resto está a pleno rendemento. Redondeado á décima máis próxima.
Para simplificar, considero que no modo de potencia do 50 por cento a luz consome a metade do que fai ao 100 por cento. Isto tamén é un pouco incorrecto, porque hai un consumo de condutor, que é constante. Eses. O noso aforro real será inferior ao da táboa. Pero para facilitar a comprensión, que sexa así.

Consideremos que o prezo por quilowatt de electricidade é de 5 rublos, o prezo medio das persoas xurídicas.

En total, nun ano podes aforrar de 313 rublos a 1409 rublos nunha lámpada. Como podes ver, nos dispositivos de baixa potencia o beneficio é moi pequeno; con iluminadores potentes é máis interesante.

Que pasa cos custos?

O aumento do prezo de cada lanterna, ao engadirlle un módulo LoRaWAN, é duns 5500 rublos. Alí, o módulo en si é duns 3000, ademais do custo do Nemo-Socket na lámpada é doutros 1500 rublos, ademais do traballo de instalación e configuración. Aínda non teño en conta que para tales lámpadas hai que pagar unha taxa de subscrición ao propietario da rede.

Resulta que a amortización do sistema no mellor dos casos (coa lámpada máis potente) é algo menos de catro anos. Recuperación. Por moito tempo.

Pero mesmo neste caso, todo será negado pola taxa de subscrición. E sen el, o custo aínda terá que incluír o mantemento da rede LoRaWAN, que tampouco é barata.

Tamén hai un pequeno aforro no traballo dos equipos de emerxencia, que agora planifican o seu traballo de forma moito máis óptima. Pero ela non vai salvar.

Acontece que todo é en balde?

Non. De feito, a resposta correcta aquí é esta.

Controlar cada farola é parte dunha cidade intelixente. Esa parte que realmente non aforra diñeiro, e pola que ata hai que pagar un pouco máis. Pero a cambio temos algo importante. Nesta arquitectura, temos unha enerxía constante garantida en cada poste durante todo o día. Non só pola noite.

Case todos os provedores atoparon o problema. Necesitamos instalar wifi na praza principal. Ou videovixilancia no parque. A administración dá o visto e prace e asigna apoios. Pero o problema é que hai postes de iluminación e alí só hai electricidade de noite. Temos que facer algo complicado, tirar enerxía adicional ao longo dos soportes, instalar baterías e outras cousas estrañas.

No caso de controlar cada lanterna, podemos colgar facilmente outra cousa no poste coa lanterna e facelo "intelixente".

E aquí de novo hai unha cuestión de economía e aplicabilidade. Nalgún lugar dos arredores da cidade, SHUNO é suficiente para os ollos. No centro ten sentido construír algo máis complexo e manexable.

O principal é que estes cálculos conteñen números reais e non soños sobre a Internet das cousas.

PS Ao longo deste ano, puiden comunicarme con moitos enxeñeiros implicados na industria da iluminación. E algúns demostráronme que aínda hai economía na xestión de cada lámpada. Estou aberto á discusión, os meus cálculos están dados. Se pode demostrar o contrario, definitivamente escribirei sobre iso.

Fonte: www.habr.com

Engadir un comentario