Zigbee e LoRaWAN risolvono problemi radio diversi. Zigbee trasporta letture frequenti da molti dispositivi concentrati in un edificio. LoRaWAN trasporta poche letture brevi all'ora da dispositivi distribuiti su un'area vasta. Molti siti energetici usano entrambi: sottocontatori fitti presso i quadri di distribuzione e pochi contatori di gas, acqua o serbatoi lontani dall'alimentazione e dalla rete.
In un sistema EpiSensor, i dispositivi Zigbee si uniscono alla rete mesh del Gateway ZGW-20 ed Edge sul Gateway memorizza le letture. I dispositivi LoRaWAN comunicano con un gateway LoRaWAN e un network server. Il network server decodifica ogni uplink e passa le letture a Edge tramite MQTT o HTTPS. Edge conserva quindi i due gruppi di letture in un unico modello dati. Non sostituisce il network server.
Scegliere in base ai requisiti
| Requisito del progetto | Punto di partenza | Da verificare |
|---|---|---|
| Letture da ogni pochi secondi a ogni pochi minuti da molti punti in un edificio | Rete mesh Zigbee | Posizione dei router, piano dei canali Wi-Fi, numero di dispositivi per Gateway |
| Poche letture all'ora da dispositivi a batteria distribuiti | LoRaWAN | Copertura rilevata sul posto, spreading factor nella posizione reale del contatore, tempo di trasmissione e budget della batteria |
| Entrambi i casi nello stesso sito | Entrambe le reti | Chi gestisce il network server, quale timestamp conserva ogni lettura, come allineare le due risoluzioni |
| Controllo di apparecchiature con una scadenza di risposta | Nessuno dei due per impostazione predefinita | Latenza end-to-end, stato dopo un messaggio perso e protezioni proprie dell'apparecchiatura |
Un protocollo wireless non è una funzione di sicurezza. Definisci con il fornitore lo stato sicuro dell'apparecchiatura controllata, indipendentemente dalla radio che trasporta il comando.
Zigbee sul sito
Zigbee funziona su IEEE 802.15.4 a 2,4 GHz. La banda ha 16 canali, numerati da 11 a 26, con frequenze centrali distanti 5 MHz da 2405 MHz a 2480 MHz. La velocità radio è 250 kbit/s e un frame contiene al massimo 127 byte, intestazioni comprese.
La rete ha un coordinatore, che in un sistema EpiSensor è lo ZGW-20. I router ritrasmettono i frame per altri dispositivi. Gli end device inviano e ricevono solo tramite un router genitore. Un end device dormiente si sveglia, interroga il genitore per i messaggi trattenuti e torna a dormire. Un dispositivo alimentato dalla rete elettrica non è sempre un router: controlla il tipo di nodo nella scheda tecnica (vedi le definizioni dei tipi di nodo di Silicon Labs). Ogni dispositivo EpiSensor alimentato dalla rete instrada i messaggi. Ciascuno raggiunge fino a 50 m al chiuso e 300 m all'aperto e aggiunge mediamente circa 1.000 m² di copertura in un edificio commerciale. Uno ZGW-20 gestisce fino a 250 dispositivi e 1.000 sensori.
Ogni hop ritrasmette il frame sullo stesso canale. Una lettura a tre hop dal Gateway usa quindi il canale tre volte. Catene profonde di router lungo un corridoio occupano il canale più rapidamente di una rete mesh piatta con più percorsi verso il Gateway.
Pianificare i canali rispetto al Wi-Fi
Un canale Wi-Fi da 20 MHz copre ±10 MHz attorno alla frequenza centrale. I canali Wi-Fi 1, 6 e 11 sono centrati su 2412, 2437 e 2462 MHz. Coprono da 2402 a 2422, da 2427 a 2447 e da 2452 a 2472 MHz: si sovrappongono ai canali Zigbee da 11 a 14, da 16 a 19 e da 21 a 24. I canali Zigbee 15 (2425 MHz), 20 (2450 MHz), 25 (2475 MHz) e 26 (2480 MHz) si trovano negli spazi intermedi. Silicon Labs ha misurato che le sue radio 802.15.4 tollerano un segnale Wi-Fi fino a 20 dB più forte quando le due frequenze sono molto distanti rispetto a quando sono adiacenti.
Due casi compromettono questo piano. In Europa il canale Wi-Fi 13 (2472 MHz) è consentito e copre i canali Zigbee 25 e 26. Un canale Wi-Fi da 40 MHz è largo il doppio di uno da 20 MHz. Rileva i canali Wi-Fi in uso prima di scegliere il canale Zigbee e ripeti la rilevazione quando il sito aggiunge access point.
Modalità di guasto di Zigbee
- Un router viene spento, isolato per manutenzione o rimosso. I suoi end device devono trovare un nuovo genitore. Se non c'è un altro router nel raggio, smettono di trasmettere fino al ritorno del router.
- Un dispositivo si trova in un involucro d'acciaio o in un locale tecnico con una porta d'acciaio. Il collegamento al router più vicino scende sotto un livello utilizzabile. Metti un router fuori dall'involucro oppure sposta l'antenna.
- Un nuovo access point Wi-Fi si attiva su un canale che si sovrappone a quello Zigbee. I rapporti dal bordo più lontano della rete mesh arrivano in ritardo o non arrivano.
Tutti e tre compaiono allo stesso modo nei dati: l'ultimo rapporto di un dispositivo è più vecchio di due intervalli di trasmissione. Genera un allarme per questa condizione, per ogni dispositivo, fin dalla messa in servizio.
LoRaWAN sul sito
LoRaWAN usa la modulazione LoRa in bande inferiori a 1 GHz: da 863 a 870 MHz in Europa (EU868) e da 902 a 928 MHz in Nord America (US915). I dispositivi non ritrasmettono l'uno per l'altro. Ogni uplink arriva direttamente a ogni gateway LoRaWAN nel raggio e i gateway lo inoltrano a un network server. Il network server elimina i duplicati, controlla il frame e lo passa all'applicazione.
La velocità dei dati dipende dallo spreading factor (SF). Un SF più alto raggiunge distanze maggiori e resiste a più attenuazione, ma ogni incremento raddoppia all'incirca il tempo di trasmissione. I parametri regionali EU868 stabiliscono questi limiti per i canali da 125 kHz:
| Velocità dati | Spreading factor | Velocità in bit | Payload applicativo massimo |
|---|---|---|---|
| DR0 | SF12 | 250 bit/s | 51 byte |
| DR1 | SF11 | 440 bit/s | 51 byte |
| DR2 | SF10 | 980 bit/s | 51 byte |
| DR3 | SF9 | 1.760 bit/s | 115 byte |
| DR4 | SF8 | 3.125 bit/s | 222 byte |
| DR5 | SF7 | 5.470 bit/s | 222 byte |
Ogni dispositivo EU868 deve usare 868,1, 868,3 e 868,5 MHz. Tutti e tre rientrano nella sottobanda da 868,0 a 868,6 MHz, per cui ETSI limita il duty cycle all'1% con 25 mW ERP. Il Sandbox pubblico di The Things Network aggiunge un limite di utilizzo corretto di 30 s di tempo di uplink e 10 downlink per dispositivo al giorno. Un network server privato non ha quel limite di utilizzo, ma il duty cycle continua ad applicarsi.
La portata dipende dall'altezza dell'antenna, dal terreno, dagli edifici e dallo SF. Un gateway su un palo può raggiungere dispositivi a diversi chilometri in campo aperto. All'interno di edifici e seminterrati, aspettati alcune centinaia di metri. Modella la copertura, poi provala con un dispositivo nella posizione reale del contatore.
Esempio calcolato del tempo di trasmissione
Un contatore invia un payload applicativo di 20 byte. LoRaWAN aggiunge 13 byte di intestazione e controllo d'integrità, quindi la radio invia 33 byte. Con preambolo di 8 simboli, coding rate 4/5 e CRC attivo, il tempo in aria è:
| Spreading factor | Tempo in aria | Intervallo minimo con duty cycle dell'1% | Uplink al giorno entro 30 s | Intervallo più breve entro 30 s al giorno |
|---|---|---|---|---|
| SF7 | 72 ms | 7 s | 417 | 3,5 minuti |
| SF9 | 247 ms | 24 s | 121 | 12 minuti |
| SF10 | 453 ms | 45 s | 66 | 22 minuti |
| SF12 | 1.810 ms | 179 s | 16 | 90 minuti |
Un intervallo di 15 minuti corrisponde a 96 uplink al giorno. Rientra nel limite di utilizzo corretto del Sandbox da SF7 a SF9, ma non da SF10 in su. Un contatore in una camera interrata che si collega solo a SF12 può inviare circa una volta ogni 90 minuti sul Sandbox. Lo stesso contatore usa anche circa 25 volte l'energia di trasmissione per lettura che userebbe a SF7: la stima della batteria deve quindi usare lo SF effettivamente raggiunto.
Esamina il calcolo della durata del pacchetto con il payload radio completo da 33 byte di questo esempio. Cambiare lo spreading factor modifica il tempo in aria; il risultato non dimostra la conformità a una regola regionale di accesso ai canali o a una politica di utilizzo corretto della rete.
Classi dei dispositivi e comandi
Tutte e tre le classi di dispositivi possono ricevere downlink. Un dispositivo di Classe A ascolta solo in due brevi finestre di ricezione dopo ciascun uplink. Un comando a un contatore di Classe A che trasmette ogni ora può quindi attendere fino a un'ora. La Classe B aggiunge intervalli di ricezione programmati dai beacon dei gateway. La Classe C ascolta continuamente salvo quando trasmette: è adatta ad attuatori alimentati dalla rete ma consuma troppa energia per la maggior parte dei dispositivi a batteria. Nessuna classe garantisce un tempo di consegna end-to-end (vedi classi dei dispositivi LoRaWAN).
Modalità di guasto di LoRaWAN
- Un uplink non confermato non riceve una conferma, ma può essere ripetuto secondo NbTrans. LoRaWAN L2 1.0.4 prevede NbTrans trasmissioni per uplink confermati e non confermati; le ripetizioni non confermate si interrompono quando arriva un downlink valido in una finestra di ricezione di Classe A. Se nessun gateway riceve alcuna trasmissione, la lettura è persa. Includi le ripetizioni configurate nel budget del tempo in aria e della batteria. Scegli dispositivi che inviano con ogni uplink un registro cumulativo, per esempio kWh totali o m³ totali. Un uplink perso riduce allora la risoluzione temporale, non l'energia.
- Gli uplink confermati fanno inviare al network server una conferma downlink per ciascuno. Un dispositivo che conferma ogni lettura da 15 minuti richiede 96 downlink al giorno, molto oltre il limite di 10 del Sandbox, e ogni downlink impedisce al gateway di ricevere mentre trasmette. Usa la conferma solo se una lettura persa conta più del tempo di trasmissione.
- L'adaptive data rate (ADR) porta un dispositivo a uno SF minore quando il margine del collegamento è buono. Se il collegamento peggiora, il dispositivo risale verso SF12. Un dispositivo che si sposta, oppure uno dietro una porta generalmente aperta, può passare a SF12 e consumare la batteria molto più in fretta del previsto. Monitora lo SF che ogni dispositivo comunica al network server.
- Un dispositivo attivato tramite personalizzazione (ABP) mantiene chiavi di sessione fisse. Se dopo un riavvio azzera il contatore dei frame, il network server ignora ogni uplink con contatore inferiore all'ultimo visto. Il dispositivo continua a trasmettere normalmente, ma non arriva nulla. Usa l'attivazione over-the-air (OTAA), che imposta nuove chiavi di sessione e contatori a ogni join.
- Un gateway LoRaWAN perde il collegamento a monte. Verifica se conserva gli uplink mentre il collegamento non funziona. Se li inoltra solo in tempo reale, le letture di quel periodo sono perse.
Esempi di siti ibridi
Campus con contatori remoti
Un campus universitario ha 20 edifici. In ciascuno, i monitor elettrici sui quadri di distribuzione trasmettono ogni minuto o più spesso: è un compito per Zigbee. Ogni edificio con più di 250 dispositivi, o privo di percorso radio verso quelli vicini, riceve un Gateway proprio.
Nel campus ci sono anche contatori d'acqua in camere interrate, contatori del gas al confine e stazioni meteo sui tetti. Trasmettono ogni 15–60 minuti e non hanno alimentazione o Ethernet nelle vicinanze. LoRaWAN è adatto. Posiziona i gateway LoRaWAN sulla base di una rilevazione della copertura, con un dispositivo di prova calato nella camera più profonda, invece di supporre che un gateway sul tetto copra tutto il campus.
Portafoglio multisito
Un proprietario immobiliare monitora 50 edifici commerciali. Ogni edificio grande ha un Gateway e una rete mesh Zigbee per il monitoraggio a livello di circuito. I siti piccoli, come parcheggi e locali tecnici non presidiati, richiedono solo la lettura del contatore principale e una temperatura. In questi siti, un dispositivo LoRaWAN a batteria per impulsi o temperatura che comunica con un network server esistente evita un intervento per installare un Gateway in ogni sito. Verifica prima il budget del tempo in aria se il network server è pubblico.
Stabilimento con utenze esterne
Uno stabilimento alimentare usa Zigbee per monitorare la potenza di ogni linea di produzione. All'esterno, i dispositivi LoRaWAN leggono il contatore del gas, quello dell'acqua di pozzo e il livello di un serbatoio di gasolio. Con entrambi i gruppi di letture in Edge, gas, acqua ed elettricità per turno condividono una sequenza temporale e il sito può calcolare l'energia per tonnellata di prodotto.
Architettura d'integrazione
Percorso Zigbee. Dispositivo Zigbee, coordinatore ZGW-20, Edge sul Gateway. Edge conserva le letture localmente e continua a funzionare quando il collegamento a monte è interrotto.
Percorso LoRaWAN. Dispositivo LoRaWAN, gateway LoRaWAN, network server con decoder del payload del dispositivo, integrazione MQTT o HTTPS, Edge. Il network server può essere privato o pubblico e appartenere al sito o a un altro team. Concorda chi possiede l'account del network server, le chiavi dei dispositivi e la versione del decoder prima di collegarlo. L'elenco dei dispositivi LoRaWAN e l'elenco dei dispositivi Zigbee nella Directory dispositivi mostrano come si collega ogni modello di terzi e quali letture documenta.
Un sito può anche evitare Edge per LoRaWAN e inviare entrambe le serie direttamente alla propria piattaforma: letture Zigbee dal Gateway e letture LoRaWAN dal network server. Le stesse regole su tempo e risoluzione si applicano allora alla piattaforma.
Timestamp
Un rapporto degli attributi Zigbee e un uplink LoRaWAN non trasportano l'ora della misura a livello di protocollo, a meno che il dispositivo non la inserisca nel payload. Il destinatario assegna il timestamp a ogni lettura. Per Zigbee è il Gateway, a uno o pochi hop dal dispositivo. Per LoRaWAN, il network server registra l'ora in cui ha ricevuto l'uplink e l'integrazione può consegnare quel messaggio secondi o, dopo un'interruzione, ore più tardi. Associa alla lettura l'ora di ricezione del network server, non quella in cui il messaggio è arrivato a Edge. Altrimenti i dati arretrati ritrasmessi appaiono come un picco di letture nel momento in cui il collegamento ritorna.
Aggiornamenti del firmware
Entrambe le reti possono aggiornare il firmware dei dispositivi via radio, a velocità molto diverse. La guida agli aggiornamenti OTA confronta il cluster OTA di Zigbee con LoRaWAN FUOTA e spiega come pianificare una campagna di aggiornamento.
Risoluzioni diverse
Le letture Zigbee ogni minuto e quelle LoRaWAN ogni 30 minuti non si allineano automaticamente. Per i consumi, calcola la differenza del registro cumulativo fra i confini degli intervalli. Non sommare valori istantanei di potenza. In un rapporto su un intervallo comune, per esempio 30 minuti, confronta i contatori soltanto su quell'intervallo. Mostra l'età della lettura accanto a ogni valore, affinché una lettura LoRaWAN vecchia di un'ora non sembri attuale quanto una Zigbee vecchia di un minuto.
Sicurezza
Zigbee cifra il traffico di rete con una chiave di rete AES a 128 bit condivisa da ogni dispositivo della rete. Il coordinatore funge da trust centre e invia la chiave di rete a ogni dispositivo quando entra. I dispositivi Zigbee 3.0 devono supportare gli install code. Un install code fornisce a ogni dispositivo una chiave di collegamento univoca che protegge la chiave di rete durante l'ingresso. In sua assenza, la chiave di rete viene inviata sotto una chiave di collegamento predefinita e pubblicamente nota, così chi ascolta durante la finestra di ingresso può acquisirla. Apri la rete all'ingresso solo durante la messa in servizio e usa gli install code dove i dispositivi li supportano.
LoRaWAN 1.0.x usa una AppKey radice per dispositivo per OTAA. Da questa, ogni join deriva una chiave di sessione di rete (NwkSKey), che il network server usa per verificare l'integrità del messaggio, e una chiave di sessione applicativa (AppSKey), che cifra il payload fra dispositivo e application server. LoRaWAN 1.1 separa la chiave radice in NwkKey e AppKey e usa chiavi di sessione di rete distinte. Su un network server pubblico, l'operatore può detenere tutte queste chiavi. Registra chi detiene ciascuna e come cambiare le chiavi di un dispositivo quando passa a un altro network server.
Proteggi il collegamento dal network server a Edge con TLS e credenziali, come per ogni integrazione MQTT o HTTPS. Vedi MQTTS: MQTT su TLS per le prove di messa in servizio.
Verifiche prima della distribuzione
Esegui un progetto pilota che includa le posizioni più difficili dei contatori, non solo i punti vicini a un gateway. Concorda queste prove di accettazione con l'installatore e il team della piattaforma:
- Registra identità del dispositivo, firmware, unità, fattore di scala e intervallo di trasmissione per ogni punto. Per LoRaWAN registra anche lo SF a cui ciascun dispositivo si stabilizza.
- Confronta i valori ricevuti con il display del contatore o con uno strumento di riferimento. Conserva i registri cumulativi separatamente dai consumi calcolati.
- Verifica che la piattaforma mostri una lettura mancante come mancante, non come zero.
- Interrompi a turno il collegamento radio, l'alimentazione del Gateway e la connessione a monte. Registra quale componente conserva i dati e quali vuoti non sono recuperabili.
- Per i comandi, verifica lo stato misurato dell'apparecchiatura, non soltanto la conferma dell'applicazione.
- Trasferisci la responsabilità di chiavi, account del network server, dispositivi di ricambio e contatti di assistenza prima di ripetere il progetto su altri siti.
Per le decisioni successive, leggi archiviazione e architettura dei dati IoT e piattaforme di gestione dell'energia. Se hai un piano del sito e un elenco dei punti, contatta EpiSensor per esaminare i requisiti di rilevazione e connettività.