Perché IP To The End Node in SSL è il gioco finale

Perché l'IP per il nodo finale in SSL è il gioco finale

Viviamo in tempi entusiasmanti - La connettività Internet si è già evoluta da dispositivi fissi a interfacce miniaturizzate in tasca, con tutto ciò che ci circonda presto a cui collegarsi entrando nell'era dell'Internet of Things (IoT). Si potrebbe obiettare che i prodotti abilitati a IoT sono ora disponibili, poiché possiamo già controllare le nostre luci, i termostati, le sfumature e altre "cose" su Internet. Oggi possiamo raccogliere dati sensoriali da dispositivi come tracker di attività, bilance collegate e contatori di energia per analisi che offrono ai consumatori nuovi servizi a valore aggiunto. Inoltre, la domanda di edifici intelligenti sta intensificando la domanda di illuminazione intelligente. L'illuminazione professionale, pervasiva, alimentata e connessa, svolge un ruolo chiave nella creazione dell'infrastruttura per l'implementazione delle applicazioni IoT. In qualità di specialista in componenti e sistemi di illuminazione professionali, Tridonic ritiene che il mercato si stia muovendo rapidamente per richiedere l'integrazione di illuminazione di alta qualità con controlli e sensori in sistemi di edifici intelligenti e automatizzati, in quanto proprietari di edifici, gestori di strutture e occupanti diventano più consapevoli del valore che questi sistemi offrono. Rimangono tuttavia delle domande su come i sistemi di illuminazione a stato solido (SSL) saranno collegati in modo interoperabile, sebbene alla fine prevarranno le comunicazioni basate su IP (Internet Protocol) verso il nodo finale.

Interessato a articoli e annunci su reti IP e illuminazione intelligente?

Una rete mesh wireless a bassa potenza combinata con opzioni cablate come Power over Ethernet (PoE) consente connessioni Internet Protocol (IP) a nodi finali nella piattaforma di illuminazione intelligente net4more.

I blocchi stradali di IoT pongono sfide

Le soluzioni IoT all'avanguardia offrono alcuni importanti ostacoli che devono essere affrontati prima di poter abbracciare appieno le reti di dispositivi IoT oltre a gadget proprietari e ecosistemi chiusi integrati verticalmente. Questo è particolarmente importante per il mercato dell'illuminazione professionale.

La parte "cose" della visione IoT in genere comprende dispositivi piccoli e vincolati che hanno uno scopo limitato, con un'interfaccia limitata o assente. Questi potrebbero essere qualsiasi cosa, dalle lampadine con connettività wireless per i controlli ai monitor a battito cardiaco alimentati a batteria collegati al polso. Il termine IoT può essere abbastanza recente, ma gli utenti che desiderano connettere le loro cose non sono una novità. Negli anni '70, le persone utilizzavano il protocollo X10 per controllare le luci in remoto usando semplici segnali modulati analogici sui loro cavi di alimentazione. Quindi il controllo a infrarossi (IR) divenne popolare e, alla fine, radiofrequenza (RF).

Z-Wave è stato uno dei primi protocolli moderni ad acquisire una significativa trazione con centinaia di prodotti interoperabili disponibili sul mercato a partire dal 2005, da fornitori che includevano General Electric, Leviton, Cooper, Jasco e altri. Z-Wave Alliance ha specificato e standardizzato uno strato di rete sub-gigahertz (GHz) basato su mesh con pochi oggetti applicativi che sono cresciuti nel tempo per adattarsi a nuovi dispositivi e funzionalità.

ZigBee era un follower veloce, con uno strato di rete a 2,4 GHz basato anche sul routing della mesh. Tuttavia, gli strati applicativi di ZigBee sono stati classificati in bucket per diversi settori, creando una frammentazione del mercato elevata con un'interoperabilità minima o nulle. Di conseguenza, ZigBee impiegò anni per diventare un player riconosciuto nel mercato consumer, ma le sue capacità di personalizzazione ne accelerarono l'adozione per le applicazioni aziendali. I rivali più recenti includono il protocollo Thread in rapida crescita e Bluetooth Low Energy (BLE) basato su rete mesh .

Gateway, o no?

Un altro problema meno visibile con i dispositivi e i protocolli IoT allo stato dell'arte è la necessità di gateway per interfacciarsi con i dispositivi finali. I telefoni dei consumatori sono in genere utilizzati come gateway per colmare il divario tra un dispositivo consumer e un servizio Internet, ma questo non è l'ideale per le imprese. In altri casi, l'utilizzo di energia viene monitorato da contatori intelligenti raggruppati in piccole reti (ad esempio, 200 famiglie / contatori intelligenti per gruppo), che si interfacciano con un gateway installato in strada per colmare il divario con un server cloud tramite una rete cellulare. Tuttavia, in un edificio per uffici, ci possono essere centinaia di gateway che si interfacciano con migliaia di sensori e luci; quindi, il collegamento delle isole non è un'opzione praticabile.

A prima vista, questo potrebbe non sembrare un problema in quanto più livelli di traduzione tra diversi protocolli possono fare il lavoro , in teoria. Ma immagina che un apparecchio di illuminazione o un sensore collegato dovesse diventare un supporto dati che serve Internet ad altri dispositivi nella sua linea di vista utilizzando Wi-Fi, Li-Fi o altre forme di comunicazione wireless ad alta velocità. In questo caso, la traduzione di pacchetti in un gateway non sarebbe un'opzione. In un altro scenario, in cui nuovi sensori o applicazioni devono essere supportati con l'infrastruttura esistente, tutto il firmware del gateway richiederebbe un aggiornamento costante per supportare wrapper e traduzioni per nuove chiamate di funzione. Gestire il firmware e l'interoperabilità e, allo stesso tempo, rispettare gli standard diventerebbe un incubo. Come un'analogia, immagina di dover aggiornare il router Wi-Fi ogni volta che Microsoft ha rilasciato una nuova versione di Office o ogni volta che hai aggiunto un nuovo dispositivo alla tua rete Wi-Fi. Non è una bella immagine, vero?

Il problema con l'utilizzo dei gateway non è solo il supporto di un wrapper / livello di traduzione, ma le cose potrebbero andare perse nella traduzione (ad esempio, le chiamate API [Interfaccia di programmazione dell'applicazione] potrebbero essere interpretate in modi leggermente diversi da gateway a gateway). Nelle reti di grandi dimensioni, potrebbe anche causare gravi condizioni di gara, causando un guasto del sistema se non è possibile garantire l'integrità dello stato su ciascun lato del gateway. Infine, terminare una chiamata di applicazione nel gateway prima che il nodo finale possa lasciare porte aperte agli hacker per eseguire attacchi man-in-the-middle , in quanto il dispositivo finale non è in grado di garantire l'integrità del messaggio.

In molti casi, i gateway con protocolli leggeri sono preferiti, poiché i dispositivi IoT sono in genere limitati con capacità di elaborazione, memoria e capacità di crittografia limitate. I dispositivi sono spesso alimentati dalla batteria o dalla raccolta di energia, quindi la gestione dell'alimentazione è fondamentale. Tutto ciò rende difficile supportare una connessione diretta con il livello appropriato di sicurezza.

IoT e illuminazione professionale

Il settore dell'illuminazione professionale sta abbracciando l'IoT e svolgerà un ruolo significativo nel diventare la spina dorsale IoT. Perché? Poiché l'illuminazione rappresenta la più grande rete di dispositivi alimentati al mondo, e con il passaggio all'illuminazione a LED, questa rete è ora digitale, consentendo un facile accesso alla potenza e alla connettività per sensori e fari. Incorporando sensori e ricetrasmettitori di vario genere nel design degli apparecchi d'illuminazione, è possibile ottenere nuovi servizi oltre la luce, come la gestione dello spazio, la gestione dell'energia, il tracciamento delle scorte, il monitoraggio dell'inventario / dei materiali di consumo e altre capacità che dobbiamo ancora immaginare.

La soluzione più ovvia è quella di basare i dispositivi IoT sull'IP, consentendo loro di comunicare come i nostri laptop e telefoni. I microcontrollori e gli IC system-on-chip (SoC) si sono evoluti rapidamente, pertanto i requisiti di memoria, elaborazione e sicurezza stanno diventando meno problematici.

Nuovi protocolli come Thread consentono la comunicazione IP direttamente ai dispositivi finali utilizzando 6LoWPAN (IPv6 su rete personale wireless a bassa potenza) per dispositivi a bassa potenza. La figura mostra un esempio di tale rete, la piattaforma net4more di Tridonic. Questo è uno sviluppo promettente e molto necessario per la standardizzazione. A mio parere, il gruppo Thread ha preso una decisione brillante nel lasciare i livelli MAC (controllo accesso ai media), PHY (livello fisico) e Applicazione fuori dai requisiti del thread per consentire la massima flessibilità e concentrarsi sul problema principale. Se si lascia MAC / PHY opzionale, in teoria si consente a Thread di funzionare su qualsiasi supporto di rete wireless o cablato, come Bluetooth, Wi-Fi, cellulare, Ethernet, PLC, MoCA (connessioni multimediali via cavo o cavo domestico) e altri, sebbene stanno iniziando con il wireless 802.15.4 MAC / PHY utilizzato anche da ZigBee.

Lasciare il livello dell'applicazione fuori dalle specifiche consente un modello a oggetti di scelta, che è flessibile ma non aiuta il problema di interoperabilità. Alcune opzioni stanno emergendo, tuttavia, per aiutare a risolvere questo problema. Uno è lo standard DotDot recentemente annunciato da ZigBee Alliance che riutilizza il modello di oggetti esistente o la Libreria di cluster di ZigBee sulla base di anni di contributi di diversi leader del settore. In breve, questo consente alle esistenti ZigBee Cluster Libraries di funzionare su qualsiasi livello di rete e integrerebbe gli standard di rete come Thread. I progressi in questo settore dovrebbero continuare a essere monitorati.

Conclusione

È inevitabile che le reti IoT professionali finiranno per diventare IP per il nodo finale. Tuttavia, ci vorrà del tempo prima di poter vedere i reali vantaggi delle soluzioni IoT completamente scalabili e integrate orizzontalmente poiché la tecnologia e gli standard sono ancora in evoluzione. La chiave è quella di approcciare un'architettura IoT con la giusta visione, ma consentire fasi di progettazione pragmatiche per raggiungere l'obiettivo finale; le scorciatoie per accelerare l'adozione del mercato dovrebbero quindi essere affrontate con cautela. La mentalità chiave deve essere quella di seguire standard che condividono la visione di comunicare direttamente al nodo finale senza wrapper e livelli di traduzione per garantire sicurezza, affidabilità, efficienza operativa e, alla fine - e più importante - vero beneficio e soddisfazione del cliente.