Standard & Internet delle cose

In questo articolo si spazia dalla definizione di cosa distingua l’Internet delle cose dal Machine to Machine, per addentrarsi in una veloce carrellata sul mondo dell’evoluzione degli standand, base per l’innovazione delle piattaforme di service enablement.

 

1 - Introduzione

È sufficiente navigare sul web per verificare che c’è molta confusione sui concetti di IoT e M2M (inclusa la variante IoE) e sul fatto che ciascuno tende a dare definizioni precise che sono corrette solo se applicate al contesto specifico preso in considerazione, o così generali da non essere significative.
Questo corrisponde alla generale complessità di modellare un sistema che deve rappresentare oggetti reali e virtuali, a volte molto semplici a volte estremamente complessi, esseri viventi e tutte le loro interazioni, inclusa la mole delle informazioni condivise e la loro persistenza nella rete.
Nel contesto degli standard per le piattaforme di service enablement i termini diventano sostanzialmente equivalenti. Semplificando, un sistema IoT/M2M è costituito da tre componenti:

  • un insieme di mezzi di comunicazione che includono molteplici reti e protocolli, e.g. una rete Wi-fi connessa ad una rete radiomobile che a sua volta colloquia con la “big internet”;
  • un insieme di semantiche ed ontologie che modellano il significato dell’insieme delle informazioni scambiate (e.g. SAREF ne caso delle smart appliances);
  • un insieme di servizi ed applicazioni che permettono al sistema di interagire con il mondo reale, sia quello umano sia quello artificiale delle “cose”.

Tradizionalmente i sistemi sono sostanzialmente omogenei (o quasi) e fanno uso di protocolli di comunicazione specifici del loro settore industriale e di semantiche spesso proprietarie,  come nei sistemi più semplici di telecontrollo ed automazione presenti da decenni, dove lo scambio di informazioni fra le diverse “isole” tecnologiche è limitato.
Basti pensare alla difficoltà nel realizzare progetti anche nel caso relativamente semplice della domotica: ad oggi la casa intelligente è un progetto di integrazione costoso che spesso richiede una certa creatività per mettere insieme sistemi diversi.
La sfida per l’attuale IoT/M2M è proprio quella di abilitare la condivisione fra questi conglomerati di sistemi diversi, creando nuovi servizi basati sull’interazione fra più servizi e fra più sorgenti di informazione.
Arriviamo alla definizione di IoT come un sistema che supporta la condivisione e/o l’interlavoro delle semantiche e delle ontologie, abilitando la condivisione di informazioni (siano essi dati o istruzioni), anche quando i protocolli usati da chi mette a disposizione l’informazione e da chi ne fruisce sono diversi.

 

2 - OneM2M

Se consideriamo gli standard propriamente detti (standard de jure) l’unica iniziativa consolidata e globale per il supporto per IoT e M2M relativamente al service layer è rappresentata da oneM2M [1].
OneM2M è un progetto di partnership fra i maggiori enti di standardizzazione regionali di telecomunicazioni ispirata al modello del 3GPP.  ETSI (Europa), TTA (Corea), TTC e ARIB (Giappone) TIA e ATIS (Nord America), CCSA (Cina),TSDSI (India) sono i partner principali [2], mentre OMA, BBF,HGI, Continua, GlobalPlatform, New Generation M2M Consortium sono partner associati [2]. Circa 200 aziende sono membri [3] di oneM2M, principalmente, ma non solo, del settore IT e Telecomunicazioni.
Tutti i documenti oneM2M sono accessibili liberamente via FTP [4], le specifiche pubblicate sono disponibili anche sul portale web di oneM2M [5].
Per approfondimenti sono disponibili alcuni webinar introduttivi a oneM2M [6].

2.1- Origini di oneM2M

L’obiettivo iniziale dichiarato di oneM2M è di creare uno standard globale per una piattaforma di servizio per IoT e M2M , flessibile e interoperabile con i sistemi esistenti, in grado di combinare le soluzioni attuali e future in unico framework applicativo.
OneM2M rappresenta la globalizzazione dei lavori sviluppati inizialmente in ETSI M2M, oggi SmartM2M  [7], in particolare della Release 2 delle specifiche ETSI M2M, di cui riprende l’approccio e le soluzioni. E’ essenzialmente focalizzato al riuso di quanto disponibile e sul colmare i gap che impediscono al mercato IoT di decollare, cercando di trovare una soluzione al problema della frammentazione e semplificando interfacce verso le applicazioni ed il loro interlavoro, in particolare relativamente ai servizi e reti di comunicazione, riusandone i servizi in modo trasparente per il mondo applicativo.

2.2 - Lo standard oneM2M

OneM2M è prima di tutto un framework di interlavoro fra servizi e deployment di tecnologie diverse.
Fin dai primi passi in ETSI è stato riconosciuto che una moltitudine delle soluzioni per M2M/IoT sarebbero continuate ad esistere per motivi di legacy e di ottimizzazione specifiche dei vari settori industriali, senza contare la settorialità dei vari business collegati. Questo sia riguardo a soluzioni proprietarie, sia a soluzioni standard (e.g. ITS).
Al riguardo la sfida è non era tanto sulla parte protocollare, quando sul come condividere le informazioni, anche a livello semantico, fra soluzioni e settori diversi. Il tutto al fianco di un’opportunità di uso nativo delle API specifiche di oneM2M, con l’intenzione di ridurre la frammentazione ove possibile e nei tempi opportuni.
Inoltre, aspirando a supportare almeno in linea di principio tutti servizi IoT/M2M, il sistema doveva essere necessariamente flessibile e supportare diversi modelli di deployment e di business,  gestendo diversi gradi di complessità dei servizi nonché le eventuali limitazioni nei device e nei gateways.
Ne è risultata un piattaforma distribuita, in grado di distribuire complessità a livello di device, gateway e server centrali, così come di concentrarla in rete nel caso di constrained devices/gateways.
Dalla Figura 1 si evince come tutto ruoti su un elemento funzionale denominato CSE (Capability Service Entity) in grado di offrire una API (Mca) alle applicazioni (Application Entity) sia locali che remote e di comunicare con altre CSE tramite un’altra API definita (Mcc). Queste API sono sostanzialmente invarianti alla configurazione e non richiedono una conoscenza della configurazione e delle reti usate per supportare la comunicazione. Le CSE di per sé assumono la forma di una piattaforma nel caso dei server in rete, di client relativamente complessi quando istanziata su device e gateways. La API Mcn è invece caratterizzata diversamente a seconda del tipo di rete sottostante usata.

 

Figura 1 - L’architettura della CSE (Capability Service Entity)

2.3 - Le caratteristiche peculiari di oneM2M

Il sistema presenta alcune scelte tecnologiche, quali:

  • l’uso di un sistema di identificazione degli elementi basato su URI;
  • un indirizzamento basato su URL;
  • l’uso di IP (indipendentemente dalla versione, IPv4 o IPv6) almeno nella tratta di lunga distanza, lasciando libertà nelle parti di Area network;
  • la scelta di uno stile REST per le API, dove tutti gli aspetti del mondo reale sono modellati tramite il concetto di risorsa [8].

Queste sono semplicemente scelte implementative e non rappresentano gli aspetti più caratterizzanti di oneM2M.
Le peculiarità profonde di oneM2M, oltre alle già citate flessibilità del deployment e orientamento all’interlavoro con altre tecnologie, sono legate ad alcune funzionalità specifiche, fra le principali:

  • Store and share: il meccanismo di comunicazione usa un paradigma di comunicazione che si basa sul condividere l’informazione senza necessariamente consumarla. L’origine di questa scelta è legata proprio alla necessità di creare una certa persistenza delle informazioni nel sistema per permetterne una fruizione da parte di più applicazioni, non necessariamente sempre connesse ed alla necessità di agevolarne la traduzione ove necessaria nelle semantiche specifiche usate dalle diverse applicazioni. Uno degli effetti collaterali è che non è necessario indirizzare l’applicazione (o le applicazioni) target, l’informazione verrà infatti inviata attraverso un meccanismo di notifiche alle applicazioni che ne hanno fatto richiesta.
    La persistenza richiesta è legata al tipo di informazione e quindi all’ uso che le applicazioni prevedono di farne. Il sistema oneM2M è in grado di mantenere le informazioni e le serie storiche, basandosi su database dedicati o integrati con quelli usati per eventuali servizi cloud.
  • Separazione fra Security e Privacy: tutte le comunicazioni fra gli elementi del sistema sono ovviamente protette, riusando meccanismi già esistenti e/o sfruttando la sicurezza offerta dalla rete sottostante (e.g. su tratte cellulari). La privacy è garantita invece dalla piattaforma in se stessa che permette l’accesso a ciascuna informazione solo a chi è esplicitamente autorizzato a farlo. Il meccanismo è quello di associare a ciascuna informazione delle policy, che sostanzialmente definiscono chi può leggere, scrivere, rimuovere e modificare le informazioni, incluse alcune condizioni opzionali (orario su cui operare, posizione geografica chi opera, ruolo, etc.). Le applicazioni che controllano ciascuna informazione decidono come modificare queste policy estendo e restringendo dinamicamente l’accesso.
    Le stesse policy sono soggette a un meccanismo simile, facendo sì che il permesso di leggere o manipolare l’informazione possa essere dato dinamicamente direttamente dalle applicazioni e che questi diritti possano essere anche affidati ad applicazioni diverse da quella che ha generato l’informazione. Non esiste direttamente il concetto di “ownership” dell’informazione, il sistema traccia chi crea l’informazione e a chi è stato dato il permesso di leggerla e manipolarla. Il risultato è un meccanismo snello, molto flessibile, che supporta svariate modalità di accesso, in grado di modellare diversi modelli di ownership e controllo dell’accesso ai dati, permettendo di limitare il costo della gestione della privacy delle informazioni relative sia a cose sia a persone e di gestirle in modo integrato.
  • Riuso e indipendenza dalle funzionalità di rete: il sistema oneM2M da un lato rende indipendenti le applicazioni dalle reti di comunicazione usate, dall’altro ne mantiene piena coscienza, in modo da riusarne pienamente capacità e funzionalità. Alcuni esempi rilevanti sono:
    • il riuso dei servizi di gestione dei terminali con l’integrazione con i sistemi di gestione basati su OMA Lightweight M2M (per idettagli si rimanda all’inserto specifico), OMA DM [9] e BBF TR 069 [10];
    • la capacità di oneM2M di agire come SCEF (Service Capability Exposure Function) [11] delle reti 3GPP verso il mondo applicativo;
    • l’integrazione con i servizi di localizzazione;
    • l’integrazione con i sistemi di gestione delle sottoscrizioni, sia di servizio che di terminale;
    • l’integrazione con i sistemi di tariffazione.

Al tempo stesso è in grado di replicare tali funzionalità a livello di piattaforma, nel caso che la rete sottostante non le renda disponibili. Di fatto il requisito minimo è di disporre di una connettività IP fra gli elementi di piattaforma e di una qualsiasi connettività generica di area network nel caso di costrained devices.

2.4 - OneM2M come framework di interlavoro

Come introdotto precedentemente, oneM2M è prima di tutto un framework di interlavoro fra tecnologie.
L’approccio seguito è stato quello di usare le API (Mca e Mcc) e di definire delle applicazioni dedicate (AE interworking proxy) capaci di mappare le specifiche tecnologie ed i relative data model (siano essi standard o proprietari) sulle risorse base standardizzate da oneM2M, che, essendo generiche, hanno un limitato contenuto semantico.
Questo fa sì che le attività di interlavoro siano eseguite al bordo del sistema e che oneM2M supporti una moltitudine di scenari di interlavoro con vari livelli di condivisione dei protocolli e delle semantiche. Di fatto si possono avere semantiche condivise solo ai bordi del sistema senza interlavoro, sia come mappaggi su semantiche comuni capaci di agire come “lingua franca” fra tecnologie diverse (come per il citato caso di SAREF per le smart appliances).
A titolo semplificativo dell’approccio seguito, la Figura 2 riporta un tipico caso di comunicazione fra tecnologie diverse in oneM2M.

 

Figura 2 - Esempio di interlavoro

3 - Stato delle specifiche ETSI e prime implementazioni

Attualmente è disponibile la Release 1 delle specifiche rilasciata a gennaio 2015 che copre tutti gli aspetti descritti e che è significativamente stabile essendo basata sulle precedenti specifiche oneM2M. La release 2, che estende le funzionalità, in particolare  portando a completamento quelle di interlavoro semantico è prevista al 1Q 2016. La lista delle funzionalità completa è descritta nel work program di oneM2M [12].
Le implementazioni di demo e trials hanno finora dimostrato la capacità delle specifiche tecniche di standardizzazione di supportare un’ampia varietà di servizi, con l’eccezione di un unico use case non supportato relativo a sistemi di controllo e automazione industriale  con stringenti requisiti di “real-time” (dell’ordine di pochi millisicondi).
Un’idea a riguardo di alcune demo di servizio è disponibile sul sito oneM2M [13].
Da segnalare inoltre l’attività congiunta di ETSI con le organizzazioni DG connect e DG Energy della Commissione Europea rivolta alla standardizzazione della comunicazione per le Smart Appliances [14] gli apparati domestici nelle case) che fa un riuso diretto delle specifiche oneM2M, integrandole con aspetti di semantica e ontologia specifici [15].
Una prima implementazione commercialedella Release 1 di oneM2M è stata resa disponibile in Corea 16] ed è prevista in Giappone [17].

 

Conclusioni

I sistemi attualmente sul mercato per M2M sono espressione di settori industriali specifici o di molteplici consorzi caratterizzati da soluzioni sviluppate da aziende specifiche, spesso in sovrapposizione e competizione.
I problemi di frammentazione delle soluzioni rappresentano un limite per lo sviluppo del mercato IoT/M2M, in quanto obbligano alla gestione di piattaforme di servizio multiple e impediscono economie di scala.
Risulta cosi estremamente difficoltosa la costruzione dei servizi complessi basati sulla condivisione di informazione e l’interazione di servizi più semplici (e.g. Smart Cities). Il passaggio ad IoT richiede la costruzione di framework più complessi, in grado sia di semplificare la frammentazione, sia di integrare sistemi dedicati ove opportuno.
In questo contesto oneM2M rappresenta il tentativo più significativo (forse l’unico ad oggi) di creare uno standard di piattaforma orizzontale e multiservizio per IoT, in grado di interlavorare con le soluzioni esistenti e al tempo stesso di incentivare la riduzione della frammentazione.
Il numero e la tipologia delle organizzazioni aderenti, se pur con una predominanza dei settori IT e TLC e la prospettiva di implementazioni commerciali a breve, assicurano una buona confidenza nella capacità di oneM2M di accelerare la convergenza su IoT, soprattutto attraverso l’integrazione di soluzioni esistenti e il riuso di componenti e tecnologie standard già disponibili.

 

comments powered by Disqus