Nella quarta parte di questa serie sull’IoT di KNX, Bruno Johnson e Wouter van der Beek spiegano l’architettura dei dispositivi IoT KNX e mostrano come l’IoT KNX sia compatibile con i sistemi Classici KNX.
La trasformazione digitale é stata uno dei maggiori argomenti strategici delle riunioni in agenda dell’esecutivo dell’azienda negli ultimi anni. L’opportunitá di sviluppare servizi digitali a partire da applicazioni basate su cloud richiede connessioni di rete basate su protocollo Internet (IPv6) verso i dispositivi di contorno che diventano interfaccia utente. Aziende di ogni forma e dimensione nell’automazione degli edifici commerciale hanno richiesto soluzioni wireless IoT per renderlo possibile, e l’Associazione KNX ha risposto rilasciando KNX IoT Point API (KNX IoT).
Il flusso di alto livello
Per assicurare la compatibilitá in entrambe le direzioni con i sistemi KNX Classici (ad esempio TP KNX – Twisted Pair), le specifiche dell’IoT KNX hanno due meccanismi fondamentali di implementazione che sono semanticamente equivalenti con TP KNX: questi meccanismi sono la configurazione dei dispositivi e il comportamento in tempo reale. Inoltre, il flusso di configurazione in un Client di Gestione (MAC; ovvero ETS) segue gli stessi passi che gli installatori giá intraprendono. I risultato é che per gli installatori, non c’é differenza tra l’utilizzo di TP KNX e i dispositivi IoT KNX. Il flusso che si segue per utilizzare i nuovi dispositivi IoT KNX é raffgurato nella Fig. 1
Per configurare i dispositivi KNX IoT si utilizzano le stesse informazioni per i dispositivi di sicurezza TP KNX, che chiamiamo:
• Mappatura dei numeri seriali per indirizzi individuali.
• Scaricamento configurazione dell’indirizzo di gruppo.
• Utilizzo di una password, simile alla Chiave di Impostazione Predefinita di Fabbrica (FDSK) per impostare la sicurezza.
Insieme a questi, é stato implementato un altro aspetto, detto Identificazione dell’Installazione (iid). Questo ci permette di far lavorare installazioni multiple sulla stessa rete IT. Quando il dispositivo sará in esecuzione (cioé con lo stato ‘caricato’), scambierá messaggi s-mode utilizzando le informazioni di configurazione. Questo é mostrato nella Fig. 2
Si noti che la comunicazione in esecuzione puó essere stavilita tra N dispositivi mittenti a M dispositivi riceventi, come per TP KNX.
Architettura del dispositivo
Gli indirizzi web, ovvero gli URL, vengono implementati nei dispositivi. Ogni URL che il dispositivo espone, fornisce informazioni simili ad un serve HTTP, e ogni URL ha diversi scopi. Gli URL sono definiti nelle specifiche e le specifiche definiscono cosa fa l’URL nel sistema. Fig. 3 mostra gli URL piú comuni in un dispositivo.
Gli URL hanno diversi scopi all’interno di un sistema. In ogni caso, tramite URL vengono immagazzinate le stesse informazioni di TP KNX.
Fig. 3 mostra gli URL ai vari livelli del dispositivo, che convogliano dati come:
• Numero di serie del dispositivo.
• Modalitá di Programmazione (on o off).
• Identificazione dell’Installazione.
• Caricamento dello stato della macchina (‘caricata’, ‘non caricata’, ‘in caricamento’), e azione per cambiare lo stato (‘scarica’, ‘inizia caricamento’,.’caricamento completato’).
• Impronta digitale dello stato caricato, per verificare se qualcosa è cambiato.
La configurazione dell’URL
Le Tabelle sono utilizzate per configurare la comunicazione in tempo reale, ad esempio per trasmettere la mappatura tra l’indirizzo di gruppo, i flag di comunicazione, il punto dati (URL), le chiavi di sicurezza e l’indirizzo multicast IPv6 per la comunicazione di gruppo.
Vengono utilizzate le seguenti Tabelle
• Tabella degli Oggetti del Gruppo – contiene la mappatura dell’URL del punto dati all’indirizzo del gruppo, compresi i flag di comunicazione.
• Tabella destinatari – contiene la mappatura dell’indirizzo del gruppo e dell’id del gruppo; l’id del gruppo viene utilizzato come parte dell’indirizzo multicast della comunicazione in modalità s o per elencare l’indirizzo individuale come destinazione.
(Comunicazione verso l’esterno)
• Tavella Editore – contiene l’indirizzo di gruppo per la mappatura del gruppo id. L’id del gruppo viene utilizzato come parte dell’indirizzo multicast della comunicazione s-mode.
(Comunicazione verso l’interno)
• Tabella di Sicurezza – contiene le chiavi di sicurezza OSCORE contenenti le informazioni OSCORE (‘osc’) e la mappatura in KNX per la comunicazione di gruppo, ad esempio l’elenco degli indirizzi di gruppo o gli ambiti di accesso unicast identificati dall’elenco delle interfacce.
Gestione tabelle
I nuovi inserimenti vengono effettuati con un protocollo applicativo Internet per dispositivi vincolati, noto come Constrained Application Protocol (CoAP). Un esempio potrebbe essere un CoAP POST sull’URL della tabella utilizzando CoAP POST ‘/fp/g’ per la tabella degli oggetti del gruppo. I valori devono definire un ingresso corretto: Questo ‘id’ utilizzato sará parte dell’URL del nuovo ingresso. Ad esempio, utilizzando id = ‘item_1’ risulterá un nuovo ingresso con un URL inferiore, ovvero ‘/fp/g/item_1’. Pertanto, il MAC ha il controllo della definizione degli URL di ingresso.
L’URL creato viene elencato con una CoAP GET su ‘/fp/g’ come voce di formato di collegamento nella risposta. La voce può essere ispezionata emettendo un CoAP GET su ‘/fp/g/item_1’. La risposta fornisce i valori come da specifiche. Una voce può essere rimossa emettendo un CoAP Delete su ‘/fp/g/item_1’. Questo ha l’effetto di rimuovere la voce dal dispositivo, quindi in un successivo CoAP GET su ‘/fp/g’ non sarà più elencata. Si noti che la gestione delle tabelle per la comunicazione di gruppo è possibile solo nello stato di “caricamento”.
L’URL per la comunicazione in tempo reale
L’URL ‘/.knx’ viene utilizzato per la comunicazione dei messaggi in s-mode. I messaggi in s-mode contengono le seguenti informazioni:
• Indirizzo del gruppo (‘ga’)
• Indirizzo del mittente individuale (‘sia’)
• Tipo di servizio (‘st’)
L’esempio di flusso s-mode mostrato in Fig. 5 in basso consiste di un minimo di 2 dispositivi, nominativamente uno che crea un messaggio s-mode, e l’altro che riceve il messaggio s-mode. Il dispositivo che invia ha un Immissione nell’Oggetto del Gruppo con un indirizzo di gruppo 5 e un URL che rappresenta/contiene il valore
Comunicazione multicast s-mode
Anche le tabelle destinatario ed editore avranno nuove immissioni. Queste voci regolano l’indirizzo multicast utilizzato. Ad esempio, un immissione con ga = 5 e grpid = 1 risulteranno nel valore grpid = 1, essendo parte dell’indirizzo multicast del mittente o del destinatario. Pertanto, le voci in tabella dei destinatari e degli editori per lo stesso indirizzo di gruppo devono corrispondere, altrimenti il mittente potrebbe utilizzare un indirizzo multicast diverso da quello del destinatario.
Comunicazione unicast s-mode – nuova per IoT KNX
La comunicazione unicast è diversa perchè le nuove voci sono differenti dal lato del mittente. Il mittente ha un indirizzo individuale di destinazione (‘ia’). L’indirizzo individuale deve essere risolto da un indirizzo vero IPv6. Può essere fatto tramite normale protocollo IT come il CoAP discovery o il DNS multicast (mDNS). Poi il vero indirizzo IPv6 può essere utilizzato per comunicazioni in tempo reale.
Informazioni Semantiche: blocchi funzionali e punti dati (Nuovi per IoT KNX)
TP e ETS di KNX funzionano sulla lunghezza dei dati. Pertanto, le informazioni semantiche contenute nei messaggi in s-mode non vengono trasferite. In ogni caso, con IoT KNX, ciò è stato aggiunto a livello del Dispositivo, ovvero, i punti dati utilizzati per recuperare o impostare il valore hanno un URL (punto dati). L’URL (punto dati) può essere utilizzato per ottenere il valore ‘dpt’ inviando un GET CoAP con il parametro di query ‘?m=*’. Accanto a questo, la risorsa /f elenca tutti i blocchi funzionali, ad esempio CoAP GET su /f fornisce un elenco di tutti i blocchi funzionali implementati in formato link. L’URL di ciascuna voce del blocco funzionale fornirà i punti dati implementati sul blocco stesso.
Come di vede nella Fig. 6 in cima, questa informazione da l’informazione semantica nello stesso formato di TP KNX.
Sintesi
Il vantaggio dell’IoT KNX è che è perfettamente interoperabile con le infrastrutture esistenti KNX, e rimangono basate su IP. Per questo, molte installazioni possono essere gestite simultaneamente con la stessa rete (IT), utilizzando infrastrutture con cavi (Ethernet/PoE) oppure senza cavi (Filo/WiFi/cellulari). È stato sviluppato con la garanzia di interoperabilità con la tecnologia KNX esistente e utilizza le più recenti tecnologie basate su Internet nelle sue specifiche, rendendo così KNX IoT sicuro da progetto.
Bruno Johnson e Wouter van der Beek sono rispettivamente CEO e COO di Cascoda Limited. Cascoda è un’azienda di comunicazioni che produce radio e moduli semiconduttori sicuri per l’IoT e guida lo sviluppo di standard di comunicazione IoT sicuri per gli edifici e le città intelligenti. I suoi prodotti risolvono i problemi di portata, affidabilità, sicurezza, potenza e scalabilità per l’IoT industriale e commerciale grazie a innovazioni brevettate e ai più recenti standard di sicurezza, tutti integrati in moduli IoT economici a bassissimo consumo.
