IT201900000565A1 - Sistema periferico per una rete iot - Google Patents

Description

SISTEMA PERIFERICO PER UNA RETE IOT

DESCRIZIONE

Settore Tecnico dell’Invenzione

Il campo di applicazione della presente invenzione riguarda l’installazione di dispositivi periferici idonei a realizzare le così dette reti IoT (Internet of Things).

Tali reti IoT consistono in vere e proprie reti di telecomunicazioni, in cui a comunicare non sono i classici dispositivi (detti anche terminali) utilizzati da utenti umani, ma dispositivi autonomi che si scambiano informazioni e comandi.

Tali oggetti, adatti ad essere integrati in una rete IoT per comunicare tra loro, sono comunemente denominati, a livello pressoché mondiale, ricorrendo all’espressione anglofona “smart object”, che è ormai entrata a far parte del linguaggio comune, e che è usata anche nel contesto della presente descrizione.

È previsto che tali reti IoT, in un orizzonte temporale abbastanza prossimo, costituiranno la parte prevalente delle infrastrutture di telecomunicazioni, e le comunicazioni tra oggetti, presumibilmente, prevarranno rispetto alle comunicazioni tra esseri umani.

In ogni caso, indipendentemente dalle previsioni evolutive, lo sviluppo delle così dette reti IoT è uno sviluppo impetuoso che pone una gran quantità di nuovi problemi tecnici. Tra questi, vi sono problemi prettamente informatici legati al corretto trattamento delle grandissime quantità di informazioni che vengono generate da tali reti IoT (i così detti “big data”); tali problemi di natura informatica non affrontati nella presente invenzione. Vi sono poi problemi di tipo elettronico e di telecomunicazione, legati alla necessità di sviluppare nuovi dispositivi, quali sono gli “smart object”, che devono svolgere particolari funzioni in presenza di significativi vincoli legati ad aspetti prettamente “hardware”, come l’alimentazione o la compattezza fisica e meccanica.

Tecnica Nota

Uno dei principali problemi tecnici posti dallo sviluppo delle reti IoT è dato dal mancato affermarsi di uno standard di comunicazione unico che determinerà una varietà non sempre omogenea di infrastrutture di rete. Anche qualora pochi standard di comunicazione finissero per consolidarsi in un tempo breve, la grande varietà di oggetti periferici, o “smart object”, che possono potenzialmente popolare una rete IoT, porrebbe comunque un tema di disomogeneità delle comunicazioni: presumibilmente dovranno essere definiti un gran numero di diversi servizi di rete di base, ciascuno con differenti funzioni per soddisfare differenti esigenze comunicative.

In un tale scenario, l’architettura più tipica di una rete IoT prevede una struttura a stella, in cui un livello centrale concentri le funzioni che richiedono maggiori risorse hardware (intese come potenza di calcolo e risorse di memoria, risorse che possono essere fisicamente concentrate o distribuite, locali o remotizzate), mentre il livello periferico è distribuito nell’ambiente in cui opera, ed è costituito dai così detti “smart object”.

L’architettura a stella prevede che gli “smart object” scambino messaggi con apparati di maggiore complessità che costituiscono il livello centrale, e che questi ultimi possano quindi, in qualche modo, adattarsi alla pluralità crescente di tecnologie che verosimilmente saranno presenti a livello periferico. Al livello centrale, tre le molte cose, sono anche demandate la resilienza del sistema complessivo, che deve essere predisposto per continui aggiornamenti ed adattamenti, e la gestione della sicurezza che pone significativi problemi in ogni rete aperta a frequenti modifiche.

Ai fini della descrizione della presente invenzione, tra le varie funzionalità del livello centrale, che ne giustificano in parte la complessità, si sottolineano l’insieme di funzioni e programmi che consentono di mantenere il più possibile semplici (e ridotte) le funzionalità da implementare a livello degli “smart object” periferici. Tale semplicità del livello periferico, tra gli altri vantaggi (ad es. contenimento dei costi degli apparati periferici che sono più numerosi), consente, in una certa misura, anche di semplificare le procedure di installazione di tali sistemi periferici.

A questo proposito, va sottolineato come la semplicità di installazione sia un requisito decisivo affinché gli scenari IoT si realizzino nella pratica. Infatti, le applicazioni IoT sono normalmente applicazioni concepite ed utilizzate in ambiti non informatici, ed in particolare da tecnici esperti di altri settori, quando non da un mercato “consumer”: devono pertanto essere supportate da oggetti periferici che anche una persona non specializzata deve poter essere in grado di installare all’occorrenza.

Nonostante tale esigenza di semplicità installativa sia esplicita e decisiva, tutte le tecnologie proposte sul mercato prevedono procedure di installazione non banali; e questa è probabilmente una delle principali ragioni che rallentano lo sviluppo delle reti IoT che, in effetti, potrebbero anche svilupparsi a ritmi più rapidi.

In sintesi, si può affermare che, allo stato dell’arte, le così dette applicazioni IoT (ossia applicazioni che si basano su reti IoT) sono basate su sistemi con architettura a stella in cui è previsto un livello centrale, spesso costituito da un server di dimensioni anche significative, e da una rete di “smart object” periferici e diffusi nell’ambiente in cui operano. Tali “smart object” trasmettono informazioni al livello centrale (quando gli “smart object” svolgono la funzione di sensore), o ricevono comandi dal livello centrale (quando gli “smart object” svolgono la funzione di attuatore), o fanno entrambe le cose nei casi più complessi. Lo stato dell’arte propone “smart object” in cui si cerca di contenere la complessità di installazione soprattutto mediante il ricorso alle seguenti prerogative, che caratterizzano un gran numero di “smart object” secondo l’arte nota:

✓ si tratta normalmente di “Smart object” molto specializzati (che quindi fanno relativamente “poche” cose) e, soprattutto,

✓ sono oggetti predisposti per operare in associazione ad un ben predefinito livello centrale (ovvero ridotta flessibilità nella scelta degli “smart object”).

Si osserva infine che, in casi più complessi ed articolati, e soprattutto in presenza di reti IoT particolarmente grandi, la comunicazione tra “smart object” e livello centrale è spesso intermediata da opportuni nodi di “gateway”.

Il principale limite delle soluzioni IoT secondo l’arte nota consiste nel fatto che, per quanto ridotta, è comunque necessaria un’attività di configurazione per installare gli “smart object”, e per mantenere su livelli accettabili la complessità installativa, è normalmente necessario ricorrere a sistemi omogenei per realizzare la rete IoT. La necessità, spesso ineludibile, di ricorrere a sistemi in grado di preservare l’omogeneità, si trasforma in un limite abbastanza significativo rispetto alla possibilità di far crescere ed evolvere nel tempo le reti IoT esistenti. Un superamento dei problemi sopra menzionati, potrebbe essere conseguito aumentando la potenza di calcolo e la disponibilità di memoria presente nei singoli “smart object”. In tal modo, uno “smart object” potrebbe aggiungersi ad una rete “IoT” cercando il server centrale cui collegarsi, presentandosi autonomamente (senza bisogno di configurazioni) e provvedendo ad una sua autoconfigurazione appropriata. Questa strada, è poco perseguita perché comporterebbe una eccessiva complessità degli “smart object” che, unitamente alla notevole varietà di “smart object” che possono essere immaginati, richiederebbe un impegno, di tipo anche economico, che non appare sostenibile.

Affinché sia sostenibile la produzione e la diffusione di “smart object” dotati di sufficienti risorse hardware (intese come potenza di calcolo e memoria) tali da consentire una autoconfigurazione in una rete IoT in funzione dell’ambiente in cui essi sono aggiunti, e tali da offrire un gamma di opzioni capace di coprire le più diverse esigenze, sarebbe necessario concepire degli “smart object” molto compatti ma altamente modulari. Tali “smart objects” dovrebbero essere configurati in modo tale che i singoli moduli possano essere prodotti in quantità sufficienti a realizzare adeguate economie di scala, e possano essere assemblati con assoluta flessibilità in numerose combinazioni, in modo tale da coprire la più ampia varietà di necessità che possono palesarsi nell’implementazione di un’applicazione IoT.

Descrizione dell’Invenzione

Lo scopo principale della presente invenzione, pertanto, è quello di indicare una tipologia generale di “smart object” dotati, tutti, di una significativa potenza di calcolo e memoria, e che siano realizzabili con forti criteri di modularità, in modo tale da ottenere singoli “smart object” di tutti i tipi (sia sensori che attuatori) e con tutte le funzionalità che è realisticamente prevedibile che siano necessarie in una generica rete IoT.

Più precisamente, le risorse hardware presenti nello “smart object” secondo l’invenzione (intese come potenza di calcolo e risorse di memoria) devono poter essere sufficienti all’esecuzione di programmi atti a riconoscere tutti i moduli che compongono lo “smart object”, qualsiasi sia il modo o la configurazione con cui esso venga assemblato.

Infatti, ulteriore scopo dell’invenzione è quello di indicare una tipologia di “smart object” che preveda la possibilità di realizzare singoli “smart object” assemblando moduli elementari semplici, tipicamente concepiti per eseguire un’unica funzione, e tale assemblaggio non preveda operazioni di configurazione.

Ulteriore scopo dell’invenzione, è quello di concepire una meccanica di assemblaggio affidabile e che permetta di ottenere “smart object” assemblati compatti, solidi e di facile composizione.

Tali scopi sono conseguibili mediante un sistema modulare che implementa un generico dispositivo periferico atto a collegarsi ad una rete di telecomunicazioni per scambiare informazioni e/o comandi con almeno un altro dispositivo collegato alla medesima rete di telecomunicazioni; e detto dispositivo periferico è caratterizzato dal fatto di essere composto da moduli elementari selezionati da un insieme di moduli elementari più numeroso, e detti moduli elementari selezionati sono assemblati meccanicamente in serie, ossia:

✓ il primo modulo è un modulo di alimentazione e presenta un’interfaccia di connessione per un solo ulteriore modulo;

✓ ogni modulo aggiuntivo che viene assemblato presenta, a sua volta, ed eccetto l’ultimo modulo, un’interfaccia di connessione per un ulteriore modulo successivo, e si connette al modulo precedentemente selezionato mediante un’interfaccia di connessione atta ad accoppiarsi con detta interfaccia di connessione per il modulo successivo che è presente nel modulo precedente;

✓ il modulo aggiuntivo finale, può essere selezionato tra moduli che non presentano interfacce per ulteriori moduli aggiuntivi.

Tra i moduli è necessario che vi sia un modulo di controllo che comprenda mezzi di elaborazione informatica e di memorizzazione di dati informatici.

Tra i moduli è necessario che vi sia anche un modulo che svolge la funzione di comunicazione per assicurare il collegamento del dispositivo assemblato ad una rete di telecomunicazioni e per scambiare informazioni e/o comandi con almeno un altro dispositivo collegato alla stessa rete di telecomunicazioni.

Il primo modulo di alimentazione presenta anche un connettore per essere agganciato ad una sorgente di alimentazione, o una coppia di contatti elettrici per essere collegato ad una sorgente di energia elettrica.

L’ordine con cui sono assemblati i singoli moduli interni (esclusi il primo e l’ultimo) è libero.

Breve Descrizione dei Disegni

Il principale vantaggio della presente invenzione consiste nel fatto che un qualsiasi sistema modulare che implementa un generico dispositivo periferico di una rete IoT, realizzato secondo gli insegnamenti della presente invenzione, soddisfa tutti i principali requisiti per cui è stato concepito.

Inoltre, questa invenzione presenta anche ulteriori vantaggi, che risulteranno più evidenti dalla descrizione seguente, da alcuni esempi di realizzazioni pratiche che illustrano ulteriori dettagli, dalle rivendicazioni allegate che formano parte integrante della presente descrizione, e dalle figure allegate in cui:

✓ Le Figura 1mostra un’immagine di principio del sistema periferico per reti IoT, secondo l’invenzione;

✓ Figura 2 mostra un esempio di uno “smart object” assemblato secondo gli insegnamenti della presente invenzione;

✓ Figura 3 mostra un modulo che svolge la funzione di illuminazione in uno “smart object” assemblato secondo l’invenzione;

✓ Figura 4a e 4b mostrano due moduli che svolgono la funzione di alimentazione di uno “smart object” assemblato secondo l’invenzione;

✓ Figure 5a e 5b mostrano un modulo costituito da mezzi di elaborazione informatica e di memorizzazione di dati informatici secondo l’invenzione;

✓ Figura 6 mostra un modulo che svolge la funzione di diffusione audio in uno “smart object” assemblato secondo l’invenzione;

✓ Figura 7 mostra un modulo che svolge la funzione di ricezione audio in uno “smart object” assemblato secondo l’invenzione;

✓ Figura 8 mostra uno schema a blocchi unifilare semplificato di uno “smart object” assemblato secondo l’invenzione.

Descrizione Dettagliata

Figura 1 mostra un’immagine di principio che illustra una conformazione tipica di uno “smart object” modulare assemblato secondo gli insegnamenti dell’invenzione: lo “smart object” è indicato nel suo complesso con il numero 100.

In Figura 1 i singoli moduli che compongono tale “smart object” 100 sono posti impilati uno sopra all’altro, e sono in numero variabile.

Come è intuibile da Figura 1, l’assemblaggio dello “smart object” 100 è molto semplice, essendo sufficiente agganciare i moduli in sequenza l’uno sull’altro, sfruttando per il loro fissaggio un opportuno meccanismo di aggancio, che sarà ulteriormente illustrato anche con l’ausilio delle figure seguenti.

Come detto, il numero dei moduli ed il loro ordine sono sostanzialmente liberi, avendo solo l’accortezza di inserire alcuni moduli essenziali.

Il primo modulo in basso è indicato con il numero 110, ed ha la funzione di garantire l’alimentazione all’intero “smart object” 100. Il modulo di alimentazione 110 riceve a sua volta l’alimentazione da una sorgente esterna e pertanto, a seconda della sorgente di energia che viene sfruttata, devono essere previsti diversi moduli di alimentazione 110 opzionali, ciascuno predisposto per gestire una diversa sorgente di energia. Nel caso esemplificato in Figura 1, detto modulo di alimentazione 110 presenta un connettore a vite, indicato con il numero 111, adatto per essere alimentato da un portalampade.

Un secondo modulo che deve necessariamente essere sempre presente in uno “smart object” 100, assemblato secondo gli insegnamenti della presente invenzione, è il modulo di controllo, indicato con il numero 120, e costituito da mezzi di elaborazione informatica, risorse di memoria informatica, e da opportuni programmi informatici, di cui si illustrerà meglio il funzionamento nel seguito. Detto modulo di controllo 120 è essenziale in quanto, tra le altre cose, esegue un programma che permette al sistema costituito dallo “smart object” 100, quando assemblato, di acquisire automaticamente la propria struttura. Tale acquisizione automatizzata permette di effettuare l’assemblaggio senza dover fare alcuna operazione di configurazione, visto che la struttura dell’assemblato viene rilevata per mezzo di un apposito programma. Un altro programma essenziale, che viene anch’esso eseguito da detta unità di controllo 120, acquisisce anche la rete IoT in cui detto “smart object” 100 viene inserito, effettua le necessarie configurazioni di rete e provvede a comunicare la propria struttura al livello centrale della rete IoT. Queste ultime informazioni trasmesse al livello centrale permettono ai programmi centrali di gestire (e configurare da remoto) il singolo “smart object” così acquisito.

Un terzo modulo che, in principio, deve sempre essere presente in uno “smart object” 100, assemblato secondo gli insegnamenti della presente invenzione, è il modulo di comunicazione, indicato con il numero 130, la cui funzione è quella assicurare la connessione con la rete IoT nella quale lo “smart object” 100 viene inserito.

Detto modulo 130 è controllato dal modulo di controllo 120 ed in alcuni casi, peraltro abbastanza frequenti, può risultare integrato nel modulo di controllo 120 stesso. Infatti, qualora la rete IoT sia supportata, a livello di comunicazioni, da tecnologia “WiFi” o “Bluetooth” (tecnologie molto diffuse che costituiscono degli standard di fatto nel mondo IoT), un’interfaccia “WiFi” e “Bluetooth” è convenientemente integrabile nella scheda del modulo di controllo 120. Di fatto, quasi tutte le schede a microprocessore utilizzabili allo scopo di realizzare detto modulo di controllo 120 sono già fornite delle suddette interfacce che, pertanto, possono essere utilizzate senza la necessità di assemblare un modulo 130 distinto per supportare le funzioni di comunicazione.

Detto modulo di comunicazione 130 va invece inserito per integrare lo “smart object” 100 in reti IoT di altro tipo.

Va detto che il sistema periferico (o “smart object”) secondo l’invenzione deve necessariamente sempre operare in un contesto di rete a stella in cui è presente un livello centrale, di cui non si tratta in questa sede, ai fini della descrizione della presente invenzione. Ma detto livello centrale è essenziale in quanto fornisce ai singoli “smart object” 100, che sono attivi nella rete IoT, tutte le informazioni relative alle applicazioni IoT che devono essere eseguite per mezzo di essi.

Pertanto ogni “smart object” 100 è in grado di operare al fine di supportare ogni generica applicazione IoT senza la necessità di configurazione alcuna, in quanto le configurazioni di base (che riguardano la struttura dello “smart object” stesso e la sua interconnessione avvengono automaticamente), mentre le configurazioni che riguardano le specifiche applicazioni IoT sono totalmente a carico dei programmi del livello centrale.

In alcuni scenari particolarmente evoluti ed interessanti, i programmi del livello centrale sono programmi che si basano su architetture software cognitive e su tecniche di “machine learning”. Questo permetterà di sfruttare la disponibilità di nuovi “smart object” che via via popoleranno la rete, senza la necessità di sviluppare pezzi di software “ad hoc” per ogni “smart object” acquisito nella rete IoT, perché l’applicazione IoT può essere resa adattiva e capace di incamerare e sfruttare tutti gli “smart object” che l’ambiente (la rete IoT) mette a disposizione, anche in modo dinamico.

Non ci si dilunga su questi aspetti, che peraltro sono un oggetto di ricerca molto avanzata, ed attuale, presso i più importanti ambienti accademici; la presente invenzione si pone solo lo specifico problema di realizzare degli “smart object” che possano essere assemblati con assoluta flessibilità, e che possano essere integrati in una rete IoT con la massima facilità: in particolare, senza richiedere alcuna operazione di configurazione.

In Figura 1 sono infine mostrati altri moduli, a significare che lo “smart object” 100 deve poi svolgere delle specifiche funzioni. Queste possono essere tanto funzioni di attuazione di qualche operazione (in tal caso si fa ricorso a moduli attuatori), quanto di rilevazione di dati (in quest’altro caso si fa ricorso a moduli sensori), per rilevare dati ambientali da trasmettere al livello centrale, a beneficio di una generica applicazione IoT che ne faccia uso. Il Modulo indicato con il numero 140 è un modulo intermedio, ossia un modulo provvisto di un meccanismo di connessione fisica al modulo precedente e anche di un meccanismo di connessione fisica che lo predispone alla connessione di un modulo successivo con un’altra funzione.

Infine, con il numero 150 è indicato un modulo terminale provvisto solamente di un meccanismo di connessione fisica al modulo precedente, non predisposto per accogliere l’assemblaggio di altri moduli. Detto modulo terminale 150 può essere sia un modulo che svolge una funzione, come anche un semplice modulo di chiusura con il solo scopo di fungere da coperchio, e di proteggere il meccanismo di connessione del modulo precedente che risulterà, in tal caso, l’ultimo modulo funzionale.

Figura 2 presenta un esempio di uno “smart-object” secondo l’invenzione, in una combinazione assolutamente realistica, che può essere realizzato ed impiegato nel contesto di un’applicazione IoT per la domotica.

Lo “smart object” dell’esempio di Figura 2, è pensato per essere installato al posto di una lampadina in un portalampade presente in un ambiente domestico. Esso è pertanto composto da un modulo di alimentazione dotato di connettore a vite, per essere appunto avvitato in un normale portalampade. E’ poi presente il modulo di controllo che, come già spiegato è essenziale e che, nel caso specifico supporta anche la funzionalità di comunicazione in quanto si assume che nell’ambiente considerato sia presente una copertura WiFi. Oltre a tali moduli, che sono necessari per qualsiasi “smart object” assemblato secondo gli insegnamenti dell’invenzione, sono presenti altri due moduli funzionali, entrambi moduli attuatori (ossia moduli che fanno qualcosa): un modulo che serve ad emettere luce (illuminare l’ambiente), ed un modulo che serve a riprodurre un segnale audio (ad esempio della musica).

Sostituendo una normale lampadina con lo “smart object” descritto in esempio, è quindi possibile implementare molto facilmente una tipica applicazione IoT di domotica. Ad esempio, assumendo la disponibilità e la dislocazione di altri sensori capaci di rilevare la presenza di persone, una prima operazione potrebbe essere quella di accendere la luce, o di spegnerla, quando le persone entrano nell’ambiente in questione, o lo lasciano. Potrebbe poi essere predisposto un programma che oltre ad accendere la luce, diffonde anche della musica, e se la rilevazione delle persone disponesse anche di informazioni in grado di conoscere l’identità delle persone stesse, potrebbe essere anche selezionata una particolare tipologia di musica particolarmente gradita alla persona riconosciuta; oppure, l’audio selezionato potrebbe anche variare a seconda dell’orario, potrebbe quindi essere usato il modulo di diffusione audio per riprodurre un notiziario al mattino, o altre informazioni di potenziale interesse per la persona che entra nell’ambiente considerato.

Al di là del particolare interesse che può rivestire un’applicazione IoT, basata sull’oggetto mostrato in Figura 2, è importante sottolineare come tale applicazione possa essere gestita confinando tutta la complessità a livello centrale. Per quanto riguarda l’installazione dello” smart object”, l’utente deve solo assemblare i moduli sopra citati, rimuovere la vecchia lampadina ed avvitare il nuovo sistema assemblato come detto: nessuna operazione di configurazione gli è richiesta.

Figura 3 mostra il modulo illuminante usato nell’esempio di Figura 2. Tale modulo è particolare in quanto, per motivi fisici e geometrici, richiede una superficie libera che sia il più possibile estesa. Si presta pertanto ad essere concepito come modulo terminale, per poter disporre di tutta la superfice che, se fosse un modulo intermedio, sarebbe inutilizzabile per l’emissione di luce, in quanto coperta dall’accoppiamento con il modulo successivo. Nell’esempio di Figura 3, tutta la superficie superiore, invece, è occupata da piccoli “led” (Light Emitting Diode); è così possibile realizzare un modulo per “smart object”, assemblato secondo gli insegnamenti della presente invenzione, che integra la funzionalità di lampada, e che è idoneo a produrre una luce abbastanza intensa, grazie alla superfice illuminante che può essere sfruttata.

Figure 4a e 4b mostrano due possibili esempi per il modulo di alimentazione 110. In Figura 4a è mostrato il modulo di alimentazione impiegato nell’esempio di Figura 2, adatto ad essere collegato ad un portalampade. La visione di tale modulo di alimentazione staccato dallo “smart object” assemblato, permette di evidenziare, nella parte superiore del modulo stesso, una protuberanza atta a fornire un meccanismo di aggancio meccanico, indicato con il numero 121 per il modulo superiore.

La scelta di concepire un sistema in cui i moduli sono collegati serialmente, uno sull’altro, permette di riservare una superfice di contatto ampia (e standardizzabile) tra le coppie di moduli che si devono collegare tra loro, questo permette di realizzare meccanismi di aggancio relativamente grandi, e quindi facili da manovrare e decisamente solidi.

Figura 4b, ha lo scopo di portare un ulteriore esempio di modulo di alimentazione, in cui non è presente uno specifico connettore, ma sono presenti due cavetti di contatto, che consentono di realizzare un collegamento elettrico generico ad una rete di alimentazione. Non ci si dilunga, a questo punto, ad elencare la grandissima varietà di possibili sorgenti di alimentazione che, evidentemente, possono, e devono, essere supportate, per rendere la presente invenzione veramente versatile, ad adattabile al maggior numero possibile di contesti. Ciò che conta sottolineare è l’importanza della modularità spinta dell’invenzione, che permette di gestire al meglio la necessità di supportare tutta la grande varietà di alimentazioni che possono essere sfruttate per lo “smart object” secondo l’invenzione. Figure 5a e 5b mostrano due esempi per il modulo di controllo 120. In particolare, Figura 5a presenta una vista assonometrica del modulo 120 staccato dallo “smart object” assemblato, in cui è ben visibile la parte superiore del modulo stesso. Figura 5a permette, ancora una volta, di apprezzare come la conformazione fisica dei moduli, in cui è previso un assemblaggio seriale, permetta di realizzare meccanismi di aggancio semplici, robusti, affidabili e di dimensioni tali da non comportare difficoltà di assemblaggio, anche da parte di un utente inesperto o poco propenso ad attività manuali. Con il numero 122 è indicato il meccanismo di aggancio fisico, mentre con il numero121 sono indicati i punti di contatto elettrico. L’esemplificazione di Figura 5a fornisce solo un esempio dei numerosissimi possibili agganci che possono essere concepiti per realizzare uno “smart object” modulare assemblato secondo gli insegnamenti dell’invenzione.

Figura 5b (come del resto anche Figura 5a) è estratta da un progetto reale di un prototipo che implementa l’invenzione, e mostra una sezione del modulo di controllo 120 in cui si vede l’elettronica interna. Figura 5b è l’occasione per ribadire, pur senza entrare nei dettagli della progettazione elettronica, che una delle caratteristiche importanti della presente invenzione consiste proprio nel fatto che gli “smart object” assemblati secondo la presente invenzione comprendono mezzi di elaborazione informatica significativi, tali da poter supportare programmi generali, idonei a supportare tutte le possibili combinazioni modulari. Il modulo 120 di controllo pertanto è indipendente dallo specifico “smart object” in cui deve essere assemblato. Tale caratteristica induce almeno due importanti vantaggi:

✓ può essere concepito in modo da non richiedere una configurazione specifica da parte dell’utente ed,

✓ essendo utilizzabile tale e quale, sostanzialmente in tutti gli “smart object” assemblati, può beneficiare al massimo delle economie di scala: a tal proposito, si ricorda che la questione legata ai costi è una questione chiave nel mondo IoT, e questo modulo è uno di quelli potenzialmente più critici dal punto di vista dei costi.

Figure 6 e 7 mostrano altri due esempi di moduli funzionali che possono essere assemblati in uno dei tanti possibili “smart object” che possono essere combinati secondo gli insegnamenti dell’invenzione.

In Figura 6 è mostrato un diffusore audio come quello inserito nell’esempio di Figura 2, mentre in Figura 7 è mostrato un modulo di ricezione audio, ossia un microfono. Ad esempio, se l’utente che aveva installato lo “smart object” presentato in Figura 2, in un secondo tempo, ad installazione già avvenuta, maturasse il desiderio, o l’esigenza, di impartire dei comandi vocali, supportati da un’applicazione IoT gestita dal livello centrale della sua rete IoT, gli basterebbe acquistare un modulo di rilevazione audio come quello mostrato in Figura 7, smontare dal portalampade lo “smart object” di Figura 2, inserire il nuovo modulo in un punto qualsiasi dello ”smart object” e rimontarlo nel portalampade, il tutto con poche e semplici operazioni manuali ed intuitive, senza alcuna configurazione a livello periferico.

Infine, Figura 8 mostra uno schema unifilare semplificato di alcuni collegamenti essenziali che si compongono quando uno “smart object”, indicato nel suo complesso con il numero 100, viene assemblato secondo gli insegnamenti della presente invenzione. In Figura 8 sono rappresentati: il modulo di alimentazione, indicato, al solito con il numero 110, il modulo di comunicazione, sempre indicato con il numero 130, altri generici moduli intermedi indicati con il numero 140, ed il modulo terminale indicato con il numero 150, che per semplicità illustrativa, è immaginato come un modulo non funzionale che funge solo da coperchio dello “smart object” 100.

Il modulo di alimentazione 110 è estremamente semplice, in quanto l’alimentazione è fornita tramite una batteria, indicata con il numero 113, che si suppone adattata e correttamente dimensionata per alimentare direttamente i vari moduli dello “smart object” 100; nel caso generale, tuttavia, nulla cambierebbe ai fini di questa spiegazione, in quanto adattamenti, conversioni e regolazioni varie verrebbero implementati da un’apposita circuiteria del modulo di alimentazione 110 stesso. La linea di alimentazione è indicata con il numero 114 e percorre tutti i moduli soprastanti, prendendo alimentazione dalla batteria 113, e fornendo alimentazione a tutti i moduli dello “smart object” 100.

La continuità della linea di alimentazione può essere facilmente assicurata predisponendo nel meccanismo di aggancio tra modulo e modulo un opportuno contatto. Cosicché, mammano che lo “smart object” 100 viene assemblato, la linea di alimentazione 114 si allunga ed attraversa tutti i singoli moduli intermedi 140; il modulo terminale, altro non deve fare se non terminare la linea ed isolare dall’ambiente esterno i contatti di alimentazione in tensione resi accessibili dall’ultimo elemento intermedio 140.

Accanto alla linea di alimentazione 114, lo “smart object” 100 dispone anche di un “bus” dati che, anch’esso, attraversa e raggiunge tutti i moduli dello “smart object” 100 assemblato, e che in Figura 8 è indicato con il numero 132. Anche detto “bus” dati 132 si compone mammano che lo “smart object” 100 viene assemblato, secondo lo principio previsto per la linea di alimentazione 113: infatti, nel meccanismo di aggancio tra due moduli consecutivi, sono previsti anche dei contatti per la trasmissione dei dati, che si toccano quando viene assicurato l’aggancio meccanico. In questo modo tutti i moduli risultano connessi al “bus” dati 132, e possono comunicare tra di loro ed in particolare con il modulo di controllo che gestisce tutto lo “smart object” 100.

Ovviamente, lo “smart object” 100 deve anche comunicare con l’ambiente esterno: questa comunicazione è assicurata dal modulo di comunicazione 130, la cui funzione peculiare consiste proprio nel gestire un canale di comunicazione con l’ambiente costituito dalla rete IoT; detto canale di comunicazione è indicato in Figura 8 con il numero 131.

In definitiva, con l’ausilio di Figura 8, è possibile sintetizzare un’ulteriore caratteristica importante che riguarda il meccanismo di aggancio dei vari moduli che compongono lo “smart object” 100 assemblato. L’aggancio così detto “in serie” dei vari moduli, non solo consente un assemblaggio semplice e sicuro dal punto di vista meccanico, ma permette anche di collegare efficacemente ciascun modulo ad un “bus” dati 132 e ad una linea di alimentazione 114; e detta linea di alimentazione 114 e detto “bus” dati 132 si compongono in modo appropriato durante l’assemblaggio del dispositivo stesso, sfruttando gli opportuni contatti associati al meccanismo di aggancio previsto per l’assemblaggio del dispositivo periferico 100 per una rete IoT, realizzato secondo gli insegnamenti della presente l’invenzione.

In generale, lo “smart object” 100 secondo la presente invenzione ha il pregio di poter essere assemblato con facilità e, praticamente, senza la necessità di seguire alcuna istruzione. Semplicemente basta agganciare i moduli che corrispondono alle funzioni che si desidera vengano svolte dal dispositivo stesso.

Inoltre, essendo il modulo di controllo generale, ed il medesimo per tutte le tipologie di “smart object”, esso può essere prodotto in quantità significative, e può beneficiare di buone economie di scala che ne contengono il costo e che permettono di dotarlo di capacità di calcolo adeguata. Tale dotazione hardware permette quindi l’esecuzione di programmi di una certa complessità che consentono di rendere completamente trasparente ogni attività di configurazione all’utente che installa il dispositivo.

Un tale dispositivo appare poi abbastanza immune da problemi di obsolescenza, infatti, per quanto riguarda il suo impiego nel contesto di specifiche applicazioni IoT, è completamente aggiornabile e riconfigurabile da un ulteriore livello centrale della rete IoT nella quale è inserito.

La sua riconfigurabilità è pertanto molto accentuata e sostanzialmente completa, sia dal punto di vista degli aggiornamenti software (effettuati dal livello centrale che può contare su adeguate risorse di potenza di calcolo), e sia dal punto di vista dei moduli componenti: infatti, in ogni momento è sempre possibile aggiungere o togliere moduli funzionali, modificando anche la funzione stessa del dispositivo.

E’ chiaro che l’invenzione si presta a numerose varianti di implementazione; infatti, possono essere concepiti molti meccanismi di aggancio tra i moduli ed i contatti che si debbono formare possono essere ricavati in moti modi.

Inoltre, l’insieme dei moduli elementari, che costituiscono l’insieme di moduli su cui avviene la selezione dei moduli impiegati per l’assemblaggio di ogni singolo “smart object”, possono essere soggetti a continua evoluzione in termini di prestazioni, consumi, dimensioni (peso), affidabilità e costo.

Tali varianti possono offrire ulteriori vantaggi rispetto a quelli già menzionati, e possono essere implementate dall’uomo esperto del ramo senza per questo fuoriuscire dallo scopo dell’invenzione come emerge dalla presente descrizione e dalle rivendicazioni allegate. Inoltre, lo “smart object” 100 si presta ad essere parte di una più complessa piattaforma IoT con architettura a stella, in cui il livello centrale può supportare numerose tecniche di controllo, alcune anche molto evolute ed idonee ad implementare tecniche di controllo basate su software cognitivo, e sempre più in grado di auto-configurarsi, in modo da gestire piattaforme IoT in costante evoluzione, e suscettibili di assumere dimensioni potenzialmente molto grandi, tali che una loro configurazione manuale diventerebbe presto ingestibile.

Possibili ulteriori varianti possono quindi dipendere tali da aspetti tecnologici che coinvolgono l’interazione con il così detto livello centrale della rete IoT su cui i dispositivi periferici, che sono l’oggetto della presente invenzione, sono integrati.

L’invenzione si presta quindi ad incorporare e supportare ulteriori sforzi evolutivi, capaci di migliorare sia le prestazioni dei sistemi periferici (comprendendo anche aspetti di installazione e/o di manutenzione) e sia le prestazioni e l’efficacia delle piattaforme IoT nel loro complesso. Tali sviluppi, qualora non compresi nella presente descrizione, possono essere oggetto di ulteriori domande di brevetto associate alla presente invenzione.

Claims (7)

1. RIVENDICAZIONI 1. Un dispositivo periferico modulare (100) atto a collegarsi ad una rete di telecomunicazioni per scambiare informazioni e/o comandi con almeno un altro dispositivo collegato alla medesima rete di telecomunicazioni; e detto dispositivo periferico (100) è caratterizzato dal fatto di essere composto da moduli elementari, selezionati da un insieme di moduli elementari più numeroso, e detti moduli elementari selezionati sono assemblati meccanicamente come segue: a. il primo modulo è un modulo di alimentazione (110) e presenta un’interfaccia di connessione per agganciarsi ad un solo ulteriore modulo successivo; b. ogni modulo aggiuntivo che viene assemblato presenta, a sua volta, ed eccetto l’ultimo modulo, un’interfaccia di connessione per un ulteriore modulo successivo, e si connette al modulo precedentemente selezionato mediante un’interfaccia di connessione atta ad accoppiarsi con detta interfaccia di connessione per il modulo successivo che è presente nel modulo precedente; inoltre, tra i moduli assemblati è necessario che vi sia: c. un modulo di controllo (120) comprendente mezzi di elaborazione informatica e di memorizzazione di dati informatici; d. un modulo di comunicazione (130) adatto ad assicurare il collegamento del dispositivo assemblato ad una rete di telecomunicazioni per scambiare informazioni e/o comandi con almeno un altro dispositivo collegato alla stessa rete di telecomunicazioni.
2. 2. Un dispositivo periferico modulare atto a collegarsi ad una rete di telecomunicazioni secondo la rivendicazione 1 in cui il modulo aggiuntivo finale (150), è selezionato tra moduli che non presentano interfacce per ulteriori moduli aggiuntivi.
3. 3. Un dispositivo periferico modulare atto a collegarsi ad una rete di telecomunicazioni secondo la rivendicazione 1 in cui detto modulo aggiuntivo finale (150) non supporta alcuna funzione, e funge solo da coperchio per chiudere detta interfaccia di connessione per il modulo successivo che è presente nel modulo precedente.
4. 4. Un dispositivo periferico modulare atto a collegarsi ad una rete di telecomunicazioni secondo la rivendicazione 1 in cui detto primo modulo di alimentazione presenta anche un connettore idoneo ad essere agganciato ad una sorgente di alimentazione, o una coppia di contatti elettrici idonei ad essere collegati ad una sorgente di energia elettrica.
5. 5. Un dispositivo periferico modulare atto a collegarsi ad una rete di telecomunicazioni secondo la rivendicazione precedente in cui l’ordine con cui sono assemblati i singoli moduli interni (esclusi il primo e l’ultimo) non è predeterminato prima delle operazioni di assemblaggio, ed è modificabile.
6. 6. Un dispositivo periferico modulare atto a collegarsi ad una rete di telecomunicazioni secondo la rivendicazione precedente in cui, in ogni generico modulo interno (140), l’interfaccia di connessione con il modulo successivo prevede un meccanismo di aggancio meccanico che offre un contatto elettrico per fornire l’alimentazione al modulo successivo, e l’interfaccia di connessione con il modulo precedente prevede un meccanismo di aggancio meccanico in cui sia garantito un contatto elettrico tale da garantire a detto generico modulo interno (140) la propria alimentazione, prelevandola dal modulo precedente a cui è collegato.
7. 7. Un dispositivo periferico modulare (100) atto a collegarsi ad una rete di telecomunicazioni secondo la rivendicazione precedente in cui, in ogni generico modulo interno (140), tra l’interfaccia di connessione con il modulo precedente e l’interfaccia di connessione con il modulo successivo, è presente un segmento di un “bus dati” tale che, quando detto dispositivo periferico modulare (100) è assemblato, tutti i moduli sono collegati tra loro tramite detto “bus dati”.