Archivi categoria: IoT

Gestione di una rete IoT basta su LoRaWAN tramite The Things Network

Facebooktwittergoogle_plusredditlinkedin

La gestione di una rete IoT basata su LoRaWAN necessita ovviamente di un’infrastruttura di gestione su cui gestire centralmente i vari dispositivi e i dati inviati, uno dei primi progetti che ha avuto questo obbiettivo è The Things Network nato nell’agosto 2015 con una prima sperimentazione ad Amsterdam in un progetto per la cura e la gestione delle imbarcazioni nei canali. The Things Network (TTN) si è poi consolidato attraverso una serie numerosa di altre esperienze che ha permesso al progetto di crescere a livello internazionale e ad oggi abbraccia varie città nel mondo fra cui alcune città italiane (a riguardo si veda la pagina dedicata alle Communities).

Per approfondire l’architettura di rete del progetto The Things Network è possibile fare riferimento alla sezione Manage your Applications and Devices or even run parts of the network on your own servers in cui viene illustrato come in una tipica rete IoT il gateway funga da ponte tra specifici protocolli radio e Internet inoltrando i pacchetti IP provenienti dai dispositivi, nel caso in cui questi supportino lo stack IP. Nel caso in cui i dispositivi utilizzino protocolli non IP, come LoRaWAN, è necessaria una qualche forma di routing ed elaborazione prima che i messaggi possano essere consegnati a un’applicazione. The Things Network è posizionato tra i gateway e le applicazioni e si occupa di gestire il routing e l’elaborazione necessarie.

Scendendo nel dettaglio dell’architettura la visione di The Things Network è quella di eseguire tutte le funzioni di routing in modo decentralizzato e distribuito. In questo modo ogni implementazione è in grado di creare la propria rete e la propria parte del back-end e al contempo può partecipare alla rete della comunità globale.

I Device trasmettono messaggi LoRaWAN, tramite il protocollo radio LoRa, i device possono inviare dati sporadicamente (classe A), ricevere dati regolarmente (classe B) o essere in ricezione continua (classe C). Il Gateway è un dispositivo che riceve messaggi LoRa e li inoltra verso il router. Il Router è un microservizio responsabile della gestione dello stato del gateway e della programmazione delle trasmissioni. A sua volta ogni router è connesso a uno o più Broker che rappresentano la parte centrale di The Things Network, il broker è un microservizio che identifica il device, deduplica il traffico e invia il pacchetto all’handler su cui l’applicazione è registrata. I broker si occupano di associare un dispositivo a un’applicazione e di inoltrare i messaggi di uplink all’applicazione corretta e di inoltrare i messaggi di downlink al router corretto che a sua volta li inoltra a un gateway. Un Handler è un microservizio responsabile della gestione dei dati di una o più applicazioni e per svolgere tale compito si connette a un Broker in cui registra applicazioni e dispositivi. L’Handler è anche il punto in cui i dati vengono crittografati o decrittografati.

In base al traffico di rete sarà necessario valutare quanti gateway utilizzare per garantire scalabilità e ridondanza. Con più gateway infatti è possibile ridurre la distanza rispetto ai device e quindi aumentare la velocità di trasferimento dati e quindi ridurre il tempo di trasmissione e l’utilizzo del canale, con un effetto esponenziale sulla capacità della rete grazie all’utilizzo dell’algoritmo ADR (Adaptive Data Rate) che esegue lo scaling automatico.

Oltre ai componenti di rete l’architettura è composta anche dal Network Server su cui è mantenuto il device registry e tiene traccia degli stati dei device, mentre il Discovery Server tiene traccia dei vari componenti che sono registrati nella rete.

The Things Network Foundation ospita questi componenti che possono essere utilizzati da chiunque gratuitamente, mentre i partners possono contribuire affiancando ai componenti open source dei componenti aggiuntivi rispetto a quelli open source per migliorare la gestione, la sicurezza e fornire integrazioni aggiuntive. L’obiettivo di The Things Network è quello di essere molto flessibile in termini di opzioni di implementazione e di connettersi preferibilmente alla rete di comunità pubblica ospitata da The Things Network Foundation, o dai suoi partner, e solitamente l’applicazione si connette ad un Public Community Network Handler utilizzando l’API MQTT.

I microservizi (router, broker e handler) sono scalati orizzontalmente in tutto il mondo per aumentare la ridondanza e mantenere i dati il più vicino possibile ai gateway e alle applicazioni, inoltre nelle regioni geografiche a maggior traffico i microservizi vengono anche ridondati verticalmente. Things Network Foundation lavora con i partner della comunità per distribuire il traffico sull’infrastruttura di rete donata e rispettare i regolamenti che prevedono che in determinati stati i dati non debbano essere portati al di fuori di determinate regioni geografiche.

Come indicato nell’articolo The Things Network Architecture e nella sezione Network Architecture
sarà anche possibile distribuire i componenti su reti private per non memorizzare i dati Internet, ma in questo tipo di scenari occorre utilizzare l’account server di TTN per gestire autenticazione e autorizzazioni. I servizi di routing possono essere eseguiti in reti private e si sta lavorando affinché questi possano scambiare dati con la rete della comunità pubblica, ma è comunque possibile configurare i componenti in modo tale che i pacchetti di dati non lascino mai la rete privata. In questo modo sarà possibile creare una piattaforma in cui i microservizi sono in hosting presso una rete privata e continuare a sfruttare la rete globale.

Se le distribuzioni ibride saranno invece possibili in futuro in alternativa, al momento, The Things Network consente di eseguire solo l’Handler nelle rete privata e non tutti i microservizi, in questo modo la crittografia e la decrittografia dei payload delle applicazioni viene eseguita nella rete privata.

La public community network è gratuita è ha dimostrato di essere stabile, ma occorre tenere presente viene fornita senza alcuna garanzia. Per ottenere livelli di servizio garantiti, manutenzione e supporto è possibile rivolgersi, ad esempio, a The Things Industries che fornisce tali servizi sia come installazione on-premises sia secondo il modello fully hosted pay-as-you-go, scendendo nel dettaglio The Things Industries può offrire un LoRaWAN Network Server e Hardware (Gateway LoRaWAN, LoRa Modem e Device LoRA con sensori e attuatori). Per approfondimenti sulle modalità di deploy offerta da TheThings Industries la sezione dedicata al Network Server, di seguito alcune FAQ:

Can I create a private LoRaWAN network with your software?
Yes, this is exactly what the Professional and Enterprise pack allow you to do. You can run it on Amazon Web Services or Microsoft Azure having the ability to host it on premises or by us.

Can I run the Network Server on a Raspberry PI like computer?
Yes, you can run the entire stack on a small computer, supporting gateways on premises without connecting them to the internet.

Can I connect this to existing Internet of Things platforms?
Yes, we invested heavily in hooks and integrations with existing platforms so we can focus on our strength, providing the last mile. Platforms like AWS IoT, Azure IoT, Cayenne and many more are supported out of the box.

I would like to leverage the global network (The Things Network) with my private network, can I do that?
Yes, you can opt in to collaborate with the community but only if you also contribute to The Things Network.

Is it possible to use both the community network and my private network in parallel?
We intend to make it possible to securely exchange data by federating the public network (The Things Network) and your private network. However this feature is not supported yet.

Per maggiori dettagli sull’architettura di rete e sul funzionamento di TTN si veda la sezione Network Architecture, mentre nella sezione Build applications on The Things Network viene invece illustrato come aggiungere un’applicazione alla console, come costruire un’applicazione tramite le APIs, l’SDK o tramite integrazione. Nel repository su GitHub The Things Network Azure IoT Hub Integration viene fornito un esempio di integrazione di TTN con Azure IoT Hub.

Per quanto riguarda la sicurezza, come indicato nella sezione Network Security, TTN è una rete pubblica che supporta la crittografia end-to-end, mitigazioni di vari attacchi di tipo man-in-the-middle e offre il supporto per diverse chiavi di crittografia a 128 bit per ogni singolo dispositivo. Inoltre LoRaWAN impone l’utilizzo di controlli di integrità dei messaggi AES a 128 bit e crittografia del payload che sono completamente crittografati tra il nodo e il componente Handler del back-end. I componenti Router e Broker instradano i dati in base ai metadati pubblici e non possono decrittografare il payload. Come già accennato precedentemente per utilizzare TTN public community network è necessario un account identificato da un nome utente o indirizzo e-mail, protetto da una password che è memorizzato sull’ account server.

Prospettive per la sicurezza: come i nostri partner considerano l’approccio alla sicurezza in un mondo che cambia radicalmente

Facebooktwittergoogle_plusredditlinkedin

Il modo in cui facciamo business sta cambiando, ma questo che impatto ha sulla sicurezza IT? Alcuni Partner VMware come IBM, Computacenter, Softcat e OVH raccontano il proprio punto di vista su un settore che ha bisogno di un ripensamento

 

Con più cloud, più dispositivi e più applicazioni che cambiano continuamente il nostro modo di lavorare, possiamo affermare con sicurezza che il business sta cambiando radicalmente. I rischi per la sicurezza derivanti da questo cambiamento sono elevati per le aziende di ogni settore, quindi la protezione delle applicazioni e dei dati sta diventando sempre più importante. Ciò solleva la questione se i tradizionali approcci di sicurezza che implicano il tentativo di proteggere il perimetro della rete e il monitoraggio di malware noti siano ancora adatti.

La crescente frequenza e il costo degli incidenti di sicurezza – nonostante l’aumento di budget IT generalmente spesi per la sicurezza – indicano un difetto fondamentale nei modelli di sicurezza esistenti che si concentrano esclusivamente sulla gestione delle minacce note.

I team IT necessitano di nuove tecnologie e soluzioni che consentano loro di proteggere le interazioni tra utenti, applicazioni e dati in un ambiente molto più dinamico, complesso ed esteso. Per realizzare questo cambiamento, i partner di Canale – di tutte le forme e dimensioni – devono dare il proprio contributo. Ma quali sono le loro prospettive sui modelli di sicurezza passati e presenti? Volevamo sentirlo direttamente dalle persone che hanno a che fare con i clienti giorno dopo giorno. Per questo, VMware ha posto alcune domande ad Adam Louca, Chief Technologist – Security, Softcat; Helen Kelisky, VP, Cloud, IBM UK & Ireland, Francois Loiseau, Private Cloud Technical Director, OVH e Colin Williams, Chief Technologist – Networking, Security & Unified Communications, Computacenter per avere un’idea del loro approccio alla sicurezza IT e cosa secondo loro deve cambiare per garantire una protezione veramente efficace da violazioni e attacchi in atto.

1. Dalla micro-segmentazione per limitare la capacità di un hacker di muoversi all’interno della rete, alla crittografia a livello di dati e alla sicurezza focalizzata strettamente sulle applicazioni stesse, per far rispettare il “bene conosciuto” piuttosto che tentare inutilmente di rilevare il “male sconosciuto” la sicurezza viene radicalmente ridefinita. Qual è la tua risposta a questa fotografia dello stato attuale della sicurezza IT?

Softcat: Abbiamo bisogno di più fornitori che ritengano la costruzione di un’infrastruttura sicura come una necessità e non una possibilità . I principi di sicurezza di privilegi minimi, segmentazione della rete e whitelist esistono da tempo come best practice accademiche, ma sono sempre stati troppo difficili da implementare per la maggior parte delle organizzazioni. Il problema per i clienti è operativo e il “carico” di sicurezza può essere ridotto integrando la sicurezza nelle piattaforme che già utilizzano. Ciò significa che i clienti non devono scegliere tra le migliori pratiche di sicurezza o l’efficienza operativa; possono avere entrambi.

IBM: Abbiamo bisogno di evolvere il modo in cui affrontiamo la sicurezza tradizionalmente per un futuro basato sul cloud, cercando di ottenere gli stessi risultati per diversi ambienti. Poiché i dati riguardano ogni aspetto del business, è necessario un approccio omogeneo per garantire la sicurezza in tutte le aree. La sicurezza del cloud non è solo realizzabile, ma è ora un’opportunità per guidare il business, migliorare le difese e ridurre i rischi. Trasformando le pratiche di sicurezza che sono manuali, statiche e reattive in un approccio più standardizzato, automatizzato ed elastico, si può stare al passo con le minacce in un ambiente cloud.

Computacenter: Attualmente esiste uno stato di confusione nello spazio di sicurezza IT aziendale e il tradizionale approccio “perimetro fisico” è certamente in discussione. Ma qualsiasi soluzione completa deve risolvere tutti gli aspetti legati alla salvaguardia di un ambiente – prevenzione, rilevamento, riparazione e risposta post-violazione – con le diverse tecnologie per gestire queste cose tutte strettamente integrate.

OVH: La sicurezza è il nostro primo pensiero in ogni nuova soluzione sviluppata. La nostra progettazione delle infrastrutture inizia con la sicurezza e poi continuiamo a guardare come possiamo rendere l’intero patrimonio sempre più sicuro ogni giorno. In effetti, le normative di settore come ISO, SOC e PCIDSS erano fondamentali per garantire che tutte le aziende rispettassero gli standard di sicurezza globali. Ma, mentre costruivamo le soluzioni per soddisfarle, abbiamo imparato molto sulla creazione di soluzioni innovative il più possibile sicure mentre i clienti costruiscono i loro cloud on-premise. Alcuni anni fa, i vantaggi del cloud, (OpEx, time to market, scalabilità) sono stati fondamentali per le aziende che si sono allontanate dal proprio set-up legacy. Oggi vendiamo effettivamente soluzioni cloud ai clienti in base al livello di sicurezza che porteranno alla loro organizzazione.

2. Le conversazioni che si stanno avendo con i clienti sulla loro sicurezza IT stanno cambiando? Se si, come?

Softcat: Negli ultimi dodici mesi abbiamo visto clienti dividersi in due categorie differenti; il primo gruppo si sta davvero rendendo conto che è necessario fare un serio investimento nei loro programmi di sicurezza informatica per raggiungere un livello base di resilienza – e abbiamo riscontrato un maggiore interesse da parte dei team dirigenziali all’interno di queste organizzazioni; Questa è una fantastica notizia. Il secondo gruppo è leggermente diverso. Hanno effettuato investimenti significativi in una vasta gamma di strumenti, ma stanno ancora vivendo incidenti di sicurezza. Il risultato è un livello di malessere all’interno di queste organizzazioni, che percepiscono la sicurezza informatica come un investimento infruttuoso. Questi sono i team su cui siamo particolarmente concentrati, assicurandoci che semplifichino il proprio approccio, gettando le basi corrette e costruendo la complessità solo quando richiesto.

IBM: I nostri clienti vogliono approfittare dei vantaggi aziendali derivanti dalla transizione al cloud, ma sono ben consapevoli di dover fare i conti con l’impatto sulla loro sicurezza. Gli approcci si stanno spostando dal mero obiettivo perimetrale, per esaminare i prodotti che possono sostituire gli aspetti della sicurezza forniti da router, firewall e altri dispositivi di confine a favore di servizi basati sul cloud come Cloud Access Security Brokers e Cloud Identity Services.

Computacenter: Le conversazioni sulla sicurezza stanno cambiando. Stiamo assistendo a un passaggio da una discussione storica sull’implementazione dei “prodotti point” per risolvere problemi discreti e ci stiamo spostando verso business allineati, impegni di consulenza architettonica. Le organizzazioni si stanno rendendo conto che hanno bisogno di una maggiore visibilità delle potenziali minacce o delle violazioni effettive, ma che ciò comporterà una semplificazione e un’integrazione più stretta delle soluzioni, se vogliono raggiungere questo obiettivo.

OVH: Considerando che un paio di anni fa avremmo venduto una soluzione di backup come opzione, il disaster recovery è oggi considerato intrinseco in qualsiasi soluzione. Anche l’ecosistema della sicurezza sta cambiando. In questo nuovo mondo, in cui tutto è proposto come servizio o qualsiasi cosa può essere installata con un click, i clienti non vogliono passare settimane o mesi per domare un firewall complesso o configurare un Load Balancer. Vogliono creare trigger o intelligenza nei sistemi che mantengano lo stesso livello di sicurezza su un’infrastruttura dinamica.

3. Sei d’accordo sul fatto che la sicurezza IT debba subire un ripensamento radicale?

Softcat: Credo che si tratti di un ritorno alle radici della sicurezza IT. Quello che penso stia cambiando è che stiamo vedendo gli strumenti rimettersi al passo con i modelli di sicurezza che sono esistiti sin dai primi anni ’90.

IBM: La sicurezza deve essere considerata insieme allo sviluppo e alle operations ed essere parte dei processi di Agile DevOps che stanno diventando sempre più popolari. Trattare la sicurezza allo stesso modo e definire la sicurezza come codice, riunisce i team, porta la sicurezza in primo piano per garantire che sia fondamentale quanto il Development e le Operation.

Computacenter: Il ripensamento radicale è già in corso, ma non è ancora abbastanza. L’incessante rilascio di nuovi prodotti da parte di vendor emergenti continua a indicare nuovi approcci alla sicurezza. Tuttavia, comprendere le basi correttamente e influenzare i giusti controlli di sicurezza prima di intraprendere un’altra ondata di acquisti deve essere una priorità per le organizzazioni.

OVH: L’esternalizzazione del carico di lavoro, la progettazione ibrida e il Cloud in generale hanno cambiato le regole del gioco. Parliamo spesso dell’implementazione “Cloud Native” e la sicurezza deve passare dall’essere, diciamo così, un mattone aggiuntivo all’ambiente per diventare “Cloud Native”. Ma, per essere Cloud Native, la sicurezza deve essere adattiva, conforme, evolutiva, semplice e (molto presto) senza soluzione di continuità quando implementata sotto un approccio multi-cloud.

4. In che modo portare la sicurezza IT nella rete o a livello di applicazione aiuta i tuoi clienti a raggiungere i propri obiettivi digitali?

Softcat: La digital transformation può avvenire solo in un ambiente sicuro. La trasformazione richiede investimenti dall’organizzazione e questo avverrà solo se saremo in grado di gestire il rischio. Una grande parte di questo è il rischio di breach. Integrare la sicurezza nella piattaforma di un’organizzazione aiuta a personalizzare i requisiti di sicurezza di ciascuna applicazione e servizio, in base al rischio e all’impatto della violazione. Ciò consente un deployment più rapido e più sicuro in quanto la sicurezza è integrata nel processo, piuttosto che inserita in un secondo momento.

IBM: È importante considerare il contesto e il valore dei controlli di sicurezza che sono in atto. Le organizzazioni trarranno vantaggio da un maggiore controllo, una granularità dell’accesso alla rete e una sicurezza integrata come la crittografia.

Computacenter: La rete nell’era digitale “vede tutto” e, legandosi strettamente con il layer applicativo, può essere raggiunto un grado di comprensione contestuale. La sicurezza IT a livello di rete da sola non risolve tutto, deve esistere in modo guidato dalle policy / integrato per tutto lo stack architettonico.

OVH: Il time-to-market è intrinsecamente legato all’IT aziendale. Ciò significa che spetta ai reparti IT creare una struttura che acceleri il time to market dell’organizzazione, anziché agire da collo di bottiglia. A tal fine, abbiamo visto molti clienti scegliere di divenire software-defined, con NSX a livello di rete, creando un approccio sicuro e automatizzato che consente ai dipartimenti IT di risparmiare tempo nei loro diversi lanci di piattaforme.

5. Puoi fare un esempio di un cliente che ha trasformato la propria sicurezza IT? Cosa ha fatto diversamente?

Softcat: Abbiamo lavorato con una grande organizzazione per aiutarla a trasformare il suo ambiente di sicurezza IT da un modello legacy di sicurezza aggiuntiva a un approccio zero-trust. L’azienda è passata da un’organizzazione che in passato avrebbe inseguito le minacce a una che comprendesse il rischio, l’esposizione e le mitigazioni della propria organizzazione. Li abbiamo aiutati a creare una strategia di architettura che fornisse protezioni stratificate a prescindere dal tipo di minaccia. Il tutto senza investire nella complessità degli strumenti. È incredibile quello che puoi fare quando ti fermi e torni alle origini.

IBM:  La maggior parte dei clienti che trasformano con successo la propria sicurezza IT lo fa trasformando la cultura della propria attività. È necessario che entri nella mentalità che la sicurezza è lì per abilitare il business. Se l’azienda prende sul serio la sicurezza nel suo complesso, questa diventa molto più facile da preparare, implementare e gestire.

 

Riflessioni finali

Queste osservazioni puntano tutte verso una convinzione: la necessità di stabilire una fonte comune di verità tra le soluzioni di sicurezza odierne e l’ambiente aziendale in evoluzione che deve essere protetto. I modelli di business continueranno a trasformarsi e le persone e i dispositivi continueranno a diventare più connessi, poiché le organizzazioni si trovano a cavallo tra il mondo fisico e quello digitale. Ora stiamo vedendo le aziende superare davvero i limiti verso le nuove tecnologie, dall’IoT all’apprendimento automatico fino all’intelligenza artificiale vera e propria, per rimanere competitivi.

Questo presenta interessanti opportunità, ma anche un ambiente più complesso ed esteso che mai, con più potenziali vulnerabilità, che necessitano di protezione. Tuttavia, stabilendo una “verità” maggiore – attraverso nuovi livelli di visibilità e una maggiore comprensione del contesto – le aziende saranno maggiormente in grado di dare un senso al loro sempre più frammentato e complesso footprint IT per offrire protezione alla velocità richiesta – per garantire, abilitare, innovare e, in ultima analisi, guidare le prestazioni aziendali.

ProjectThings: il framework open per l’IoT

Facebooktwittergoogle_plusredditlinkedin

L’Internet Of Things sta prendendo sempre più piede nelle nostre vite, da semplici lampadine o termostati che possiamo facilmente acquistare per la nostra casa, a veri e propri sistemi integrati che ci permettono, da qualsiasi parte del mondo, di controllare i nostri oggetti fisici.

Uno dei problemi più grossi di queste tecnologie, però, è sempre stata l’interoperabilità: l’assenza di uno standard fa si che ognuno adotti le proprie soluzioni, più o meno aperte, e che gli oramai famosi “accentratori” che permettono di far interagire dispositivi diversi con dialetti diversi (ad esempio, IFTTT o il sistema Echo di Amazon) facciano sempre più fatica a stare dietro alle centinaia di logiche eterogenee presenti sul mercato.

Nell’ottica della standardizzazione si è buttata la famosa azienda Mozilla che, recentemente, ha annunciato “Project Things”, un framework standard ed open per far dialogare i dispositivi su internet.

L’idea, tramite questo framework, è che chiunque lo possa utilizzare per creare il proprio Gateway Things per poter controllare i diversi dispositivi presenti nella nostra rete direttamente da internet. I vantaggi sono non solo quelli di poter standardizzare l’accesso a dispositivi differenti, ma anche la possibilità di mantenere un gestore di apparati IoT privato invece di averne diversi accessibili pubblicamente.

Certo, il fatto di doversi implementare da soli rendere il tutto poco accessibile alle persone non troppo interessate a mettere le mani sui computer, ma grazie ad un semplice tutorial che forniscono per l’installazione su un Raspberry-Pi ed ad una serie di integrazioni già presenti out-of-the-box, il tutto è più semplice di quanto ci si possa aspettare.

Le feature presenti in questa prima release sono già parecchie e degne di nota tra cui:

  • La possibilità di utilizzare il microfono del proprio computer per impartire comandi vocali al sistema
  • Una serie di interfacce che permettono di creare veri e propri workflow basati sulla logica “Se succede questo, fai quest’altro”
  • Un sistema per disegnare la planimetria della nostra casa e associare i dispositivi ad aree specifiche dell’immobile

Oltre a questo, l’autenticazione tramite OAuth e un sistema di add-on completano il tutto rendendolo adattabile all’evoluzione dello stesso ed ai nuovi dispositivi che potremmo inserire, sia in termini di funzionalità che di controllo dello stesso sistema.

Le basi sono state buttate, dunque, resta solo da vedere se il progetto riscuoterà il successo che si spera, e che aiuti i produttori di dispositivi a rendersi conto che, in questo periodo di continui cambiamenti, gettare le basi di uno standard non può che portare benefici sul lungo periodo.

IoT: basta “fai da te”, si passa all’industrializzazione.

Facebooktwittergoogle_plusredditlinkedin

di Alberto Bullani, Country Manager VMware Italia

Innumerevoli report di analisti evidenziano l’aumento del numero di oggetti connessi (IoT) e l’incredibile potenziale economico che tale fenomeno porta con sé. Per certi versi, l’IoT completa la tecnologia digitale fornendo alle aziende le “cellule nervose” addette alla trasmissione delle informazioni. Un grande vantaggio per le aziende che saranno pronte al cambiamento. L’entusiasmo è legittimo, tuttavia occorre prestare attenzione alle possibili delusioni. Come tutti i più rivoluzionari trend tecnologici, anche questo, dopo una fase iniziale di euforia, prevede naturalmente il ritorno alla realtà: un preludio all’industrializzazione.

 L’IoT sposta il valore e lo amplifica. Questo profondo cambiamento ha conseguenze importanti per i modelli di business. Le aziende dovranno valorizzare e monetizzare la gigantesca massa di dati generati da miliardi di oggetti connessi. Alcune aziende hanno compreso perfettamente questa necessità. Una di queste è GE, che si è fatta strada tra i pionieri dell’Industrial Internet of Things (IIoT). Oltre ai processi esistenti, che subiranno un miglioramento, emergerà una moltitudine di nuovi servizi basati sull’analisi dei dati. I responsabili devono comprendere il significato delle tecnologie e prevedere l’impatto che queste avranno sulle aziende e sull’infrastruttura tecnica. L’IoT sta ridisegnando tutto il panorama concorrenziale e creando nuovi ecosistemi. La sfida per le aziende è rappresentata dalla necessità non solo di mantenere la propria posizione all’interno della catena del valore, ma anche di migliorarla. Molte aziende sono ancora in fase di progetto pilota o addirittura di R&D. Per andare avanti, è necessario risolvere la questione della complessità insita nell’IoT.

Non solo complessità. L’IoT, sicuramente più che i Big Data e il cloud, è caratterizzato da un’architettura complessa. Nell’attuale panorama industriale, esistono sensori di molti tipi diversi che sono in grado di misurare praticamente qualsiasi cosa, oltre che di controllare e pilotare apparecchiature o processi industriali. Finora questi sistemi sono tuttavia rimasti isolati, senza alcun collegamento con i sistemi informatici centrali, impedendo così l’utilizzo incrociato di tutti i dati generati. Grazie alla connessione degli oggetti a Internet si ha la convergenza tra i sistemi industriali e quelli informatici, per cui i team devono imparare a collaborare per superare divergenze e abitudini differenti.

L’uso dei sensori è ormai esteso a tutte le aree di attività. La natura eterogena di questi strumenti consente di impiegarli per apportare intelligenza a veicoli, negozi, città, sistemi sanitari e processi di logistica, supervisione o manutenzione. La proliferazione di oggetti connessi sta mettendo a dura prova i principi stessi della sicurezza. Ogni oggetto connesso è come una falla nelle pareti dei data center. È necessario prendere atto di questo problema e ripensare la sicurezza di conseguenza. Attacchi recenti hanno mostrato, ad esempio, come le videocamere connesse possono essere sabotate per causare malfunzionamenti di tipo Denial of Service (DoS) e bloccare tutte le attività aziendali.

Con l’IoT, le aziende creano un vero e proprio “sistema nervoso”. Le informazioni vengono trasmesse dalla “cellula nervosa” (il sensore) al “cervello” (il data center e il cloud). Alcune azioni conseguenti saranno “involontarie” (eseguite automaticamente dalle apparecchiature connesse), mentre altre saranno “volontarie” (risultanti dal processo di elaborazione avvenuto nel data center o nel cloud). La sfida consiste nel connettere in modo semplice e sicuro questa enorme quantità di oggetti alla rete aziendale, portando i dati giusti nei data center. Entrano così in gioco molti fattori. Operation accurate e sicure richiedono una perfetta coordinazione. Questo sarà proprio il compito delle piattaforme IoT. Alcune trasporteranno i flussi di dati (le informazioni dei sensori) e le relative analisi, mentre altre si occuperanno delle infrastrutture (i “sistemi nervosi”) e della sicurezza. L’offerta VMware è logicamente incentrata sulla piattaforma dell’infrastruttura, come annunciato il 9 maggio 2017: VMware Pulse IoT Center. Questa soluzione di gestione dell’infrastruttura IoT mira a ridurre le complessità, migliorare l’affidabilità, accelerare il ritorno dell’investimento e, naturalmente, garantire la protezione necessaria. In questo breve video Ray O’Farell, CTO di VMware e più recentemente capo della divisione IQT di Dell, spiega i principi alla base della soluzione VMware Pulse IoT Center.

Diversamente da molte soluzioni basate soprattutto sul software, l’IoT (e ancor più l’IIoT) include elementi hardware i cui investimenti si posizionano su cicli a lungo termine. Fin dalla fase di progettazione delle soluzioni, è necessario anticipare l’evoluzione di tutti questi componenti e fornire strumenti per automatizzare l’aggiornamento dei relativi microcodici. Tutt’altro che una moda passeggera, l’IoT è ormai una certezza. È quindi giunto il momento di passare alla fase di implementazione industriale per poter distribuire le soluzioni in modo funzionale e sicuro, e quindi cogliere i vantaggi previsti.

Insecurity of Things

Facebooktwittergoogle_plusredditlinkedin

Oltre a sovrappopolare il pianeta stiamo sovrappopolando internet. Mentre scrivo questo poche righe mi guardo attorno, nel mio studio, e vedo un solo laptop e altri NOVE devices connessi alla rete… NAS, SmartTV, IP-cam, tablet, stampanti (come rinunciare al piacere di stampare a casa dalla Cappadocia), ecc. Tutti questi oggetti hanno un sistema operativo e un indirizzo IP, ovvero … Leggi tutto “Insecurity of Things”

Monitoraggio Remoto di Sensori con Azure IOT Suite Parte 2 di 2

Facebooktwittergoogle_plusredditlinkedin

Nella prima parte della guida Monitoraggio Remoto di Sensori con Azure IOT Suite abbiamo visto come utilizzare Azure IoT Suite per mettere in piedi, in pochi semplici passaggi, un’infrastruttura cloud alla quale connettere i nostri sensori.

IoT_Giulio

In questa guida utilizzeremo una board Intel Edison e un sensore di temperatura per realizzare la connessione con i servizi di Azure.

La board Intel Edison permette l’esecuzione di programmi scritti in JavaScript attraverso l’ambiente Node.js.

Per prima cosa, è necessario installare sulla board una Base Shield. Attaccheremo al pin A0 di quest’ultima il nostro sensore di temperatura.

Nel passo successivo, ci collegheremo alla board via SSH e scaricheremo due file eseguendo i seguenti comandi:

wget https://raw.githubusercontent.com/Azure-Samples/iot-hub-node-intel-edison-getstartedkit/master/remote_monitoring/remote_monitoring.js

wget https://raw.githubusercontent.com/Azure-Samples/iot-hub-node-intel-edison-getstartedkit/master/remote_monitoring/package.json

Editeremo il primo file attraverso il comando:

vi remote_monitoring.js

In particolare, è necessario individuare all’interno del file le seguenti righe per la connessione:

var hostName = '<IOTHUB_HOST_NAME>';

var deviceId = '<DEVICE_ID>';

var sharedAccessKey = '<SHARED_ACCESS_KEY>';

Per effettuare la connessione, andremo a sostituire <IOTHUB_HOST_NAME>, <DEVICE_ID>, <SHARED_ACCESS_KEY> con le tre stringhe che avevamo generano nella precedente guida ossia Nome host hub IoT, ID dispositivo e Chiave dispositivo.

Possiamo inoltre personalizzare alcune informazioni sulla nostra scheda e sul nostro sensore andando ad editare i seguenti metadati:

// Send device meta data
var deviceMetaData = {
'ObjectType': 'DeviceInfo',
'IsSimulatedDevice': 0,
'Version': '1.0',
'DeviceProperties': {
'DeviceID': deviceId,
'HubEnabledState': 1,
'CreatedTime': '2015-09-21T20:28:55.5448990Z',
'DeviceState': 'normal',
'UpdatedTime': null,
'Manufacturer': 'Intel',
'ModelNumber': 'Edison',
'SerialNumber': '12345678',
'FirmwareVersion': '159',
'Platform': 'node.js',
'Processor': 'Intel',
'InstalledRAM': '64 MB',
'Latitude': 47.617025,
'Longitude': -122.191285
}

Per avviare la connessione con Azure e iniziare il monitoraggio, lanciamo:

npm install per risolvere eventuali dipendenze

node remote_monitoring.js per avviare il programma attraverso Node.js.

Collegandoci ad www.azureiotsuite.com vedremo sul grafico il monitoraggio in tempo reale della temperatura dell’ambiente.

Con questa guida abbiamo dimostrato l’apertura di Azure verso sistemi terze parti: in particolare non siamo vincolati a l’utilizzo di board certificate dal programma Windows IoT (https://developer.microsoft.com/it-it/windows/iot) ma è possibile connettere board eterogenee e utilizzare linguaggi differenti come JavaScript attraverso l’ambiente Node.js.

Monitoraggio Remoto con Azure IOT Suite Parte 1 di 2

Facebooktwittergoogle_plusredditlinkedin

Microsoft Azure mette a disposizione una serie di strumenti per gestire le soluzioni basate sull’Internet of Things. Per gli utenti meno esperti, sono presenti servizi preconfigurati che permettono in semplici passaggi di creare un’infrastruttura di base per il Monitoraggio Remoto dei Sensori.

Vediamo i passi da seguire per creare una soluzione:

  1. Per prima cosa è necessario collegarsi al portale https://www.azureiotsuite.com nel quale ci verrà chiesto di autenticarci con il Microsoft Account.
    azureiot1
  2. Clicchiamo su Creare una nuova soluzioneazureiot2
  3. Selezioniamo Monitoraggio Remotoazureiot3
  4. Digitiamo un Nome soluzione, selezioniamo l’Area in cui Azure allocherà il nostro servizio e selezioniamo la nostra Sottoscrizione di Azure. Il nome della soluzione identificherà successivamente tutta l’infrastruttura alla quale ci collegheremo successivamente.azureiot4
  5. Inizierà la fase di Provisioning che potrà durare circa 10 minuti. Possiamo controllarne l’avanzamento cliccando su Dettagli.azureiot5
  6. Quando il provisioning sarà completo la soluzione mostrerà lo stato Pronto. Non ci resta che avviare la soluzione cliccando su Avvia.azureiot6
  7. Se il nostro Microsoft Account non è stato riconosciuto correttamente sul tenant, potrebbe richiederci nuovamente l’Accesso.azureiot7
  8. Per completare l’autenticazione è necessario Accettare la richiesta di autorizzazione.azureiot8
  9. Ci apparirà la dashboard di Azure IotSuite. Clicchiamo in basso a sinistra su Aggiungi.azureiot9
  10. Selezionare Dispositivo personalizzato.azureiot10
  11. Selezionare Desidero definire il mio ID dispositivo. Inserire un ID per il Dispositivo e Verificare che sia disponibileazureiot11
  12. Nella schermata vengono mostrati l’ID dispositivo, il Nome Host Hub Iot e la Chiave del dispositivo. Prendiamo nota di questi tre elementi che permetteranno la connessione delle board e dei sensori all’Hub Iot.azureiot12
  13. Dopo aver cliccato su Fatto, verrà mostrata la lista dei sensori. Il sensore appena creato mostrerà lo stato In Sospeso.azureiot13

Abbiamo appena creato la nostra infrastruttura per l’Internet of Things. Nella seconda parte della guida verrà mostrato come connettere una board e i sensori all’infrastruttura.

LoRaWAN

Facebooktwittergoogle_plusredditlinkedin

Una delle componenti fondamentali per l’implementazione dell’IoT e dello sviluppo di soluzioni IoE è una rete a cui i vari sensori sono connessi che risponda a requisiti di elevata penetrazione, elevata copertura e ridotti consumi. Per contro le caratteristiche dell’IoT che non necessita di monitoraggi realt-time, ma solo a fronte di variazioni delle grandezze misurate, non richiede di elevati bitrate.

Di seguito una schematizzazione dei requisiti dei sevizi di rete dell’IoT:

La risposta a questi requisiti sono le tecnologie LPWA (Low power wide area) che vengono appunto utilizzate per connettere sensori e sono caratterizzate da basse velocità, scambio di poche decine o centinaia di bit, elevata durata delle batterie anche maggiori di 10 anni.

Al momento si stanno diffondendo due soluzioni concorrenti: la tecnologia LoRa (Long Range) WAN, nata dal contributo di varie aziende unitesi nella LoRa Alliance, e i servizi erogati da SIGFOX con tecnologia proprietaria.

Di seguito una comparazioni tra LoRa, SIGFOX e altre tecnologie di trasmissione via radio pubblicate sulla White Paper Nokia LTE-M – Optimizing LTE for the Internet of Things del 2015:

Da cui si nota come le soluzioni SIGFOX e LoRa abbiano il pregio di sfruttare frequenze libere, inoltre dal confronto pubblicato nel seguente articolo Low Power, Wide Area A Survey of Longer-Range IoT Wireless Protocols del 7 settembre 2015 risulta evidente come le tecnologie basate su LPWA ben si sposano con i requisiti dell’IoT.

Il confronto che rende però più evidente come LPWA sia decisamente interessante in contesti IoT e IoE è quello disponibile nella presentazione LPWAN LOW POWER WIDE AREA NETWORK OVERVIEW OF EMERGING TECHNOLOGIES FOR LOW POWER WIDE AREA NETWORKS IN INTERNET OF THINGS AND M2M SCENARIOS di Peter R. Egli (indigoo.com) del 2015 in cui appare evidente come tale tecnologia consenta una grande copertura a fronte di costi e consumi energetici ridotti.

Nell’articolo Low power wide-area networking alternatives for the IoT del 15 settembre 20145 è invece possibile trovare un confronto tra le varie tecnologie Low-Power WAN da cui è possibile valutare le differenze tecniche tra LoRaWAN e SIGFOX

Lo sviluppo e la standardizzazione di LoRa WAN tramite la LoRa Alliance è stata annunciata da IBM Research e Semtech il 17 Marzo 2015 nel comunicato stampa La tecnologia di rete a basso consumo di IBM e Semtech aiuta le aziende di telecomunicazione a lanciare nuovi servizi per l’Internet of Things in cui la nuova tecnologia basata su wide-area network a basso consumo (LPWAN) viene proposta come la risposta alle difficoltà tecniche dell’ Internet of Things (IoT) descrivendone i punti di forza e i vantaggi rispetto alle reti cellulari e wifi per le comunicazioni machine to machine (M2M).

“Per anni, l’enorme potenziale dell’Internet of Things (IoT) per le aziende – raccolta dati da diversi dispositivi, la loro analisi ed elaborazione per un processo decisionale più rapido e veloce – è stato frenato da difficoltà tecniche quali una durata limitata della batteria, distanze di comunicazione brevi, costi elevati e mancanza di regole.”

“La tecnologia chiamata LoRaWAN (Long Range wide-area network), risolve questi problemi. Basata su nuova specifica e protocollo per le reti wide-area a basso consumo che utilizzano uno spettro wireless senza licenza, la tecnologia è in grado di collegare i sensori sulle lunghe distanze, offrendo nel contempo una durata ottimale della batteria e richiedendo un’infrastruttura minima. Questo consente di offrire vantaggi quali mobilità, sicurezza, bi-direzionalità e localizzazione/posizionamento migliorati, oltre a costi più bassi.”

“I sensori LoRaWAN sono in grado di comunicare a distanze superiori ai 100 km (62 miglia) in ambienti favorevoli, 15 km (9 miglia) in ambienti semi-rurali e a più di 2 km (1,2 miglia) in ambienti urbani densamente popolati ad una velocità di dati da 300 bit a 100 kbit. Questo li rende adatti all’invio di quantità di dati contenute, come le coordinate GPS e le letture del clima che la banda larga non è in grado di raggiungere. I sensori richiedono inoltre pochissima energia, la maggior parte di loro può funzionare per più di 10 anni con una sola batteria AA e, inoltre, le chiavi AES128 rendono praticamente impossibile l’intercettazione e la manomissione delle comunicazioni.”

La LoRa Alliance è un’associazione aperta, non-profit ha come mission lo sviluppo e la standardizzazione delle Low Power Wide Area Networks (LPWAN) implementate in tutto il mondo per l’attivazione di Internet of Things (IoT),

Scendendo nel dettaglio l’architettura di una rete LoRaWAN prevede una tipologia a stella di stelle in cui il Gateway è un bridge trasparente per i messaggi tra Devices e il Network Server. I Gateway sono connessi al Network server tramite una connessione basata sollo standard IP, mentre i Device utilizzando una comunicazione wireless single-hop verso uno o più Gateway. La comunicazione verso i Device è in generale bidirezionale, ma può anche supportare il muticast per gestire l’aggiornamento o la distribuzione massiva di messaggi per ridurre i tempi di comunicazione.

Per aumentare la sicurezza delle trasmissioni LoRaWAN prevede tre layer di crifratura:

  • Una Unique Network key (EUI64) per garantire la sicurezza a livello di rete
  • Unique Application key (EUI64) per garantire la sicurezza a livello applicativo
  • Una Device specific key (EUI128)

LoRaWan prevede tre classi di Device per gestire le differenti necessità delle applicazioni IoT:

  • Bi-directional end-devices (Class A) che consentono la comunicazione bidirezionale in cui ogni trasmissione da parte del Device è seguita da due brevi finestre di ricezione.
  • Bi-directional end-devices with scheduled receive slots (Class B) che consentono la comunicazione bidirezionale come in Device in classe A, ma in aggiunta prevedono una finestra di ricezione casuale.
  • Bi-directional end-devices with maximal receive slots (Class C) che prevedono una finestra di ricezione costantemente aperta tranne durante la tramissione.

LoRaWAN è stata scelta come infrastruttura di rete su cui sviluppare The Things Network, il progetto che si propone di realizzare una rete di dati IoT creata dalle persone, libera e a disposizione di tutti. La prima rete The Things Network è stata realizzata ad Amsterdam tramite 10 Gateway LoRaWAN in sole 6 settimane e sonom poi seguite reti in altre città varie altre citta del modo comprese alcune città Italiane come ad esempio Roma, Milano e Torino e molte altre. Per la mappa completa delle community The Things Network si veda il link https://thethingsnetwork.org/map.

Per maggiori informazioni si vedano le LoRaWAN White Papers pubblicate sul sito della LoRa Alliance dove è anche possibile visualizzare la lista dei membri dell’alleanza suddivisa per Sponsor, Contributor, Adopter e Institutional.