Nella terza parte di questa serie di articoli sull’IoT KNX, Bruno Johnson e Wouter van der Beek spiegano le basi dei dispositivi IoT 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).
Le basi
Per assicurare la retrocompatibilitá con altri dispositivi media KNX (Installazioni Classiche KNX), la specifica KNX IoT nel gruppo delle specifiche di sistema KNX (3_10_5 KNX IoT Point API) descrive:
• Un nuovo livello di trasporto basato su IPv6, ad esempio Wi-Fi, Ethernet e reti basate su filo.
• Un nuovo protocollo di comunicazione/messaggio che consente le seguenti modalità di comunicazione:
- Punto-Multipunto, Senza Connessione (Multicast)
- Punto-Punto, Senza Connessione.
- Punto-Punto, Orientato alla Connessione
Inoltre; il nuovo livello di trasporto dovrebbe usare lo stesso punto dati degli esistenti strati di trasporto KNX come definito nelle specifiche Descrizione dell’Applicazione (Volume 7).
La progettazione del nuovo mezzo di trasporto con questi vincoli non cambierà il modo in cui KNX viene attualmente applicato. L’approccio alla configurazione dei dispositivi è ancora quello dell’ETS e i dispositivi comunicano tra loro attraverso i messaggi in S-mode.
Lo stack tecnologico
I dispositivi devono poter comunicare utilizzando IPv6, a prescindere dallo strato fisico utilizzato, volendo intendere che sono supportati Ethernet (compresi PoE), Wi-Fi e Filo. In effetti a Filo è intrinsecamente basato su IPv6.
Discovery – Ricerca
Per comunicare tramite IP, bisogna conoscere l’indirizzo IP e la porta del dispositivo KNX. Per ottenere questa informazione, vengono utilizzati due diversi meccanismi di ricerca.
1) La ricerca mDNS é un protocollo che utilizza DNS multicast per trovare dispositivi e servici nella rete locale senza sapere il loro indirizzo IP. È conosciuto anche come configurazione zero, Bonjour, o Avahi. È largamente implementato nei dispositivi per case intelligenti, i dispositivi wireless Arduino le stampanti, gli altoparlanti, dispositivi di archiviazione di rete, etc… Funziona inviando pacchetti ad ogni nodo della rete per risolverne ii nomi degli host e richiedere i servizi. Può essere utilizzato con DNS Service Discovery (DNS-SD) per navigare e risolvere i servizi in base al nome host o al servizio. Funziona per il dominio di primo livello (TLD) .local.
la ricerca mDNS permette la ricerca per:
– Numero di serie.
– Indirizzo individuale.
– Modalitá di programmazione.
2) La ricerca The CoAP (Protocollo di Applicazione Vincolato) é una richiesta speciale CoAP, per ricercare risorse di un host conosciuto. Per scoprire l’host, dev’essere utilizzata una richiesta multicast, ma deve essere supportata dal server.
La ricerca CoAP permette la ricerca per:
– Numero di serie.
– Indirizzo individuale.
– Modalitá di programmazione.
– La ricerca di dispositivi che contengono uno specifico punto dati
– La ricerca di un dispositivo che contiene uno specifico blocco funzionale.
Trasporto Telegram
Il livello successivo é la comunicazione tramite IPv6 utilizzando CoAP. Questo é il livello che trasporta i telegrammi KNX dal mittente al destinatario. Ció si ottiene utilizzando URL. Il modo più semplice di vedere CoAP è che sia equivalente a HTTP, implementando l’invio di messaggi utilizzando il paradigma di richiesta e risposta, tra un client (iniziatore) e un server (risponditore). La differenza maggiore tra HTTP e CoAP è che le intestazioni CoAP sono in formato binario e che CoAP funziona su UDP.
I termini per emettere i messaggi sono gli stessi:
- GET – per il recuper dei dati.
- POST – per aggiornamento parziale dei dati.
- PUT – per aggiornamento totale dei dati.
- DELETE – per eliminare una risorsa.
In piú, OBSERVE é una nuova funzione simile al sondaggio lungo – long poll HTTP. L’Observe puó essere utilizzato per ottenere risposte multiple. Ad esempio; quando i dati cambiano, una nuova risposta viene inviata alla richiesta Observe. Per avere la stessa affidabilitá come HTTP su TCP, il protocollo CoAP ha implementato la conferma dei trasferimenti. Pertanto, il reinvio dei pacchetti, quando non vengono riconosciuti, fa parte di CoAP e quindi le richieste confermate da CoAP sono affidabili come HTTP su TCP. Il carico utile di un messaggio è determinato dal tipo di contenuto, vale a dire che possono essere supportati diversi formati, in modo simile a HTTP.
Tipi di carico utile
Le specifiche KNX IoT utilizzano due formati di contenuti, ognuno dei quali ha una diversa funzione. La prima é per gli elenchi di URL (punti dati/blocchi funzionali) con i quali interagisce, e la seconda per l’interazione con gli URL.
Il formato Applicazione-Link
Questo formato di contenuto permette la descrizione delle risorse ospitate, i loro attributi, e altre relazioni tra i link. Sulla base del campo HTTP Link Header definito in RFC 5988, il formato di collegamento Constrained RESTful Environments (CoRE) viene trasportato come carico utile e gli viene assegnato un tipo di media Internet. Un URL noto è definito come un punto di ingresso predefinito per richiedere i link ospitati da un server.
Tipiche risposte
Esempi di tipiche risposte possono essere i seguenti:
Ogni linea contiene:
– L’URL ospitato (tra ).
– Il tipo di risorsa (rt), a designare ció che é.
– Il tipo di contenuto, ad esempio 60 per CBOR e 40 per Fromato Applicazione-Link.
Questo permette al cliente di interagire con il dispositivo su base URL.
Interazione con un dispositivo
L’URL può essere visto come un punto di dati con cui interagire tramite coppie chiave-valore. Le coppie chiave-valore sono descritte tramite Rappresentazione degli Oggetti Binaria Concisa (CBOR). CBOR è un formato di serializzazione dei dati binari basato vagamente su JSON. Come JSON, permette la trasmissione di oggetti di dati che contengono coppie nome-valore, ma in modo conciso. Questo migliora il processamento e la velocitá di trasferimento a costo della leggibilitá all’uomo. Tuttavia, apre la documentazione: definire i carichi utili in JSON per aumentare la leggibilità delle specifiche e avere il formato binario sul filo.
I dati di un messaggio in modalità S possono essere definiti in JSON come segue:
{ “s”: { “st”: “the st value” , “ga”: “the ga value”, “value”: “the value” } }
Le chiavi JSON possono essere sostituite con valori interi per restringere il messaggio ancora di piú nelle dimensioni che segono:
{ 5: { 6: “the st value” , 7: “the ga value”, 1: “the value” } }
Sicurezza
Il protocollo standard OSCORE RFC 8613 (Object Security for Constrained RESTful Environments), che fornisce sicurezza end-to-end per i messaggi CoAP a livello applicativo, cripta i messaggi di richiesta/risposta a livello applicativo tra i terminali. Non solo é il carico utile che contiene il valore associato alla risorsa criptata, ma anche un metodo di richiesta, l’identificatore della risorsa, e il formato del contenuto del carico utile. Ció vuol dire che il dato rilevante dell’applicazione e la semantica della richiesta/risposta possono essere protette in modo disaccoppiato dal trasporto dei messaggi, pur essendo leggeri in termini di sovraccarico.
Oltre a CoAP, OSCORE utilizza anche la Rappresentazione degli Oggetti Binaria Concisa (CBOR) per la codifica compatta e la CBOR Object Signature and Encryption (COSE) per le strutture di crittografia e di derivazione delle chiavi, entrambe progettate per operazioni vincolate sui dispositivi e ulteriormente compresse con OSCORE grazie all’omissione di informazioni ridondanti. OSCORE dispone di identificatori integrati che consentono di effettuare operazioni end-to-end su più percorsi diversi, con o senza IP.
Il sovraccarico del messaggio è minimo, poiché OSCORE protegge solo le informazioni rilevanti del livello applicativo e la quantità di dati che si aggiunge alla dimensione del messaggio CoAP originale può essere di soli 11-13 byte con gli identificatori incorporati. OSCORE é stato determinante nel definire il livello di sovraccarico per la sicurezza delle comunicazioni leggere e rispetta la sicurezza degli strati di trasporto dell’attuale stato dell’arte.
Mettiamo tutto insieme
Ora abbiamo spiegato tutti i meccanismi di comunicazione. Un dispositivo KNX IoT dispone di una serie di URL per elencare i blocchi funzionali e i punti dati implementati e di URL per configurare il dispositivo.
Ad esempio, esistono risorse (punti dati) per configurare il dispositivo. Concetti esistenti come Macchina a Stato di Carico (Load State Machine (LSM)), modalitá di programmazione (PM), indirizzo individuale (IA) e la Tabella degli Oggetti del Gruppo sono modellati con i meccanismi descritti precedentemente.
Con il risultato, che le seguenti specifiche della IETF (Internet Engineering task Force) sono referenziate nelle specifiche KNX IoT Point API.
Sintesi
Il vantaggio di IoT KNX é che la nuova tecnologia é basata su IP e che puó essere appunto utilizzata su reti IT. È 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.
La specifica è stata concepita sulla base dei dispositivi integrati e lo stack open source che implementa KNX IoT si è dimostrato alquanto piccolo, pur funzionando con soltanto 512kB di storage e 96kB di memoria.
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.
