IoT e progettazione di sistemi di Home Automation: un caso ... · mai datata e economicamente...

ALMA MATER STUDIORUM – UNIVERSITÀ DI BOLOGNACAMPUS DI CESENA

SCUOLA DI INGEGNERIA E ARCHITETTURA

CORSO DI LAUREA MAGISTRALE IN INGEGNERIA DEI SISTEMIE DELLE TECNOLOGIE DELL'INFORMAZIONE

IoT e progettazione di Sistemi di Home Automation: un caso di studio reale basato su framework e standard open.

Tesi inSistemi Intelligenti Distribuiti LS

Relatore Presentata da

Prof. Alessandro Ricci Danilo Candiotti

Sessione III

Anno Accademico 2014-2015

Indice

1 Introduzione 1

2 Internet of Things 5

2.1 Definizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Principali standard . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Protocolli a livello applicativo . . . . . . . . . . . . . . . . . . . 192.4 IoT e WoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Home Automation, Domotica e Smart Home 29

3.1 Passato, presente e futuro. . . . . . . . . . . . . . . . . . . . . . 303.2 Domotica e Home Automation . . . . . . . . . . . . . . . . . . . 34

Ambiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . 36Protocolli principali . . . . . . . . . . . . . . . . . . . . . . . . . 43Confronto tra i vari sistemi in Italia . . . . . . . . . . . . . . . . 51

3.3 IoT e Smart Home . . . . . . . . . . . . . . . . . . . . . . . . . 55Apple HomeKit . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Google Brillo e Weave . . . . . . . . . . . . . . . . . . . . . . . 59Samsung SmartThings e gli altri . . . . . . . . . . . . . . . . . . 64Eclipse SmartHome framework . . . . . . . . . . . . . . . . . . . 65Considerazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4 Caso di Studio 71

4.1 Sistema domotico HomePLC . . . . . . . . . . . . . . . . . . . . 73HomePLC.Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 73

i

Indice

4.2 Sistema domotico di test . . . . . . . . . . . . . . . . . . . . . . 76Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . 79Analisi del problema . . . . . . . . . . . . . . . . . . . . . . . . 85Analisi dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . 92Piano di collaudo . . . . . . . . . . . . . . . . . . . . . . . . . . 94Piano di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Progetto del sistema . . . . . . . . . . . . . . . . . . . . . . . . 95Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.3 openHAB come sistema di automazione . . . . . . . . . . . . . . 113Refactoring di EventGenerator in OSGi bundle . . . . . . . . . 125Struttura openHAB e HomePLCBinding . . . . . . . . . . . . . 126

4.4 Ambiente di prova e valutazioni . . . . . . . . . . . . . . . . . . 131

5 Conclusioni 139

Bibliografia 141

ii

Elenco delle figure

2.1 Nascita dell’internet delle cose . . . . . . . . . . . . . . . . . . . 52.2 Gartner Hype Cycle . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Gartner Hype Cycle of technology 2015 . . . . . . . . . . . . . . 82.4 IoT come unione di più visioni . . . . . . . . . . . . . . . . . . . 92.5 Stack IP e 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . 132.6 Topologie per 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . 152.7 Stack HTTP e CoAP . . . . . . . . . . . . . . . . . . . . . . . . 192.8 Formato dei messaggi CoAP . . . . . . . . . . . . . . . . . . . . 202.9 Tipi di messaggi CoAP . . . . . . . . . . . . . . . . . . . . . . . 212.10 Cross-Proxy CoAP . . . . . . . . . . . . . . . . . . . . . . . . . 222.11 Stack MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.12 Trasferimento dati con MQTT . . . . . . . . . . . . . . . . . . . 242.13 Formato messaggio MQTT . . . . . . . . . . . . . . . . . . . . . 252.14 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.15 Confronto tra WS-* e REST . . . . . . . . . . . . . . . . . . . . 28

3.1 Cablaggio di tipico impianto domotico . . . . . . . . . . . . . . 353.2 Esempio di rete BACnet [21] . . . . . . . . . . . . . . . . . . . 453.3 Topologia sistema KNX [21] . . . . . . . . . . . . . . . . . . . . 473.4 Schema di rete Lonworks [21] . . . . . . . . . . . . . . . . . . . 503.5 Logo OpenWebNet . . . . . . . . . . . . . . . . . . . . . . . . . 513.6 Logo Konnex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.7 Logo NetBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.8 Logo di Apple HomeKit . . . . . . . . . . . . . . . . . . . . . . 573.9 Weave API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

iii

Elenco delle figure

3.10 Brillo stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.11 Architettura di Eclipse SmartHome . . . . . . . . . . . . . . . . 66

4.1 i.Core M53 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.2 Ciclo di esecuzione del PLC . . . . . . . . . . . . . . . . . . . . 744.3 Use case model . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.4 Domain Object Model . . . . . . . . . . . . . . . . . . . . . . . 804.5 Comportameto dell’Event Generator . . . . . . . . . . . . . . . 864.6 Aggiunta di Event Dispatcher . . . . . . . . . . . . . . . . . . . 874.7 Architettura rilevamento eventi e azionamento . . . . . . . . . . 884.8 State Diagram logica passo-passo . . . . . . . . . . . . . . . . . 894.9 Light Bulb Analysis Model . . . . . . . . . . . . . . . . . . . . . 904.10 State Diagram logica Blind . . . . . . . . . . . . . . . . . . . . . 904.11 Roller Shutter Analysis Model . . . . . . . . . . . . . . . . . . . 914.12 Interazione Roller Shutter . . . . . . . . . . . . . . . . . . . . . 934.13 HomePLCEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . 964.14 EventGenerator interfaces . . . . . . . . . . . . . . . . . . . . . 974.15 Struttura Event Generator . . . . . . . . . . . . . . . . . . . . . 984.16 Event Generator Observer Pattern . . . . . . . . . . . . . . . . 1004.17 Dispatcher interface . . . . . . . . . . . . . . . . . . . . . . . . . 1004.18 Vista dei packages . . . . . . . . . . . . . . . . . . . . . . . . . 1014.19 Esempio di programma Java e libreria nativa originale. . . . . . 1024.20 Diagramma con Meta Livello nel caso di Reflection . . . . . . . 1044.21 Utilizzo della Reflection. . . . . . . . . . . . . . . . . . . . . . . 1054.22 Relazioni tra packages e subsystem. . . . . . . . . . . . . . . . . 1064.23 Smart Object Activity Diagram . . . . . . . . . . . . . . . . . . 1074.24 Event Generator Loop . . . . . . . . . . . . . . . . . . . . . . . 1094.25 Event Dispatcher Activity Diagram . . . . . . . . . . . . . . . . 1114.26 Procedimento per generare la native library . . . . . . . . . . . 1124.27 Nuova composizione della libreria nativa. . . . . . . . . . . . . . 1134.28 Esempio di chiamata a metodo nativo senza Java reflection . . . 1144.29 openHAB event bus . . . . . . . . . . . . . . . . . . . . . . . . . 115

iv

Elenco delle figure

4.30 openHAB Architecture Overview . . . . . . . . . . . . . . . . . 1164.31 openHAB Items Model . . . . . . . . . . . . . . . . . . . . . . . 1174.32 openHAB Types Model . . . . . . . . . . . . . . . . . . . . . . . 1194.33 openHAB Component Diagram . . . . . . . . . . . . . . . . . . 1214.34 openHAB link with OSGi EventAdmin Service . . . . . . . . . . 1234.35 ItemRegistry structure Model . . . . . . . . . . . . . . . . . . . 1234.36 ItemProvider structure Model . . . . . . . . . . . . . . . . . . . 1254.37 BindingConfigReader Model . . . . . . . . . . . . . . . . . . . . 1254.38 Componente OSGi . . . . . . . . . . . . . . . . . . . . . . . . . 1264.39 Relazioni tra EventGenerator e Binding HomePLC . . . . . . . 1284.40 Sistema in uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314.41 Protocolli IoT e openHAB . . . . . . . . . . . . . . . . . . . . . 1324.42 Alcune parti dell’interfaccia Android . . . . . . . . . . . . . . . 1334.43 Esempio di grafico di umidità . . . . . . . . . . . . . . . . . . . 133

v

Elenco delle tabelle

4.1 Glossario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.1 Glossario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.2 Turn on/off Light Bulb use case . . . . . . . . . . . . . . . . . . 824.3 Move up/down Blind use case . . . . . . . . . . . . . . . . . . . 834.4 Sense Device Contacts use case . . . . . . . . . . . . . . . . . . 854.5 Control Device Relais . . . . . . . . . . . . . . . . . . . . . . . . 854.6 Registri Ragnetto Temperatura e Umidità . . . . . . . . . . . . 994.7 Item per HomePLCBinding . . . . . . . . . . . . . . . . . . . . 127

vii

Elenco degli algoritmi

4.1 static initializer . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034.2 SmartObject code . . . . . . . . . . . . . . . . . . . . . . . . . . 1084.3 GenericItem implemetation . . . . . . . . . . . . . . . . . . . . 1184.4 SwitchItem static initialization . . . . . . . . . . . . . . . . . . . 1204.5 openHAB EventPublisher internals . . . . . . . . . . . . . . . . 122

ix

1 Introduzione

La Home Automation è un ambito in cui la Internet of Things è in gradodi fornire strumenti capaci di garantire nuove funzionalità che una visione or-mai datata e economicamente svantaggiosa di questi sistemi ne sta limitandol’adozione presso un vasto pubblico di potenziali acquirenti. La chiusura dicerti sistemi rispetto a nuovi protocolli sviluppati per favorire l’integrazione ea nuovi dispositivi recentemente comparsi sul mercato, ne relegano l’impiegoesclusivamente agli ambiti per i quali sono stati pensati inizialmente e quindidifficilmente ampliabili in futuro.In questo contesto hanno fatto comparsa, ormai da tempo, dispositivi dotati didiscrete capacità di calcolo e di connettività in grado di fornire nuovi servizi enuove possibilità di utilizzo che erano impensabili precedentemente. Nonostan-te queste nuove caratteristiche, le soluzioni proposte dalle aziende rappresen-tano applicazioni verticali che, sebbene utilizzino alcune delle tecnologie dellaIoT per aumentarne le funzionalità, risultano isolate le une rispetto alle al-tre limitandone nuovamente i possibili utilizzi solamente ai casi previsti in faseprogettuale.A questo proposito diverse aziende hanno realizzato propri hub in grado diintegrare sotto un unico ecosistema svariati oggetti, dotati di connettività e diun sistema di controllo proprietario, consentendo di ampliarne le funzionalitàe la possibilità di creare nuovi scenari non previsti inizialmente dal singolocostruttore.Anche grossi nomi come Apple e Google hanno recentemente fatto il loro in-gresso in questo mercato presentando architetture realizzate su una loro ideadi IoT e spinti sicuramente anche dalle previsioni economiche molto favorevoli.

1

1 Introduzione

Il loro approccio, sebbene fornendo tutti gli strumenti di sviluppo necessari,è incentrato nel fornire sia un protocollo che servizi basati sulla presenza diun ecosistema cloud a cui gli altri produttori, interessati ad adottare la lorotecnologia, saranno costretti ad adeguarsi.In questo contesto e contrariamente a questo modo di pensare, tecnologie open-source come Eclipse SmartHome, danno la possibilità di superare lo scoglioiniziale nella scelta di quale tecnologia adottare, quale eventuale sistema diautomazione installare in una abitazione e, capacità di programmazione per-mettendo, anche di implementare la propria integrazione come è stato fatto nelcaso di studio presentato in questo testo.Il caso di studio, pensato e realizzato con lo scopo di poterlo realmente utilizzarein ambiente domestico, cerca di raccogliere i problemi e le soluzioni adottateper giungere a quella ambita integrazione, tra sistemi e dispositivi, che la IoTpromuove tentando di fornire a un sistema di Home Automation tradizionalel’apertura di cui purtroppo è carente.Lo scopo di questo progetto è stato quello di fornire uno strumento che potesseda un lato avvicinare alla Home Automation quelle persone che ancora sonopiuttosto restie ad adottare una tecnologia per loro ritenuta ancora complessa ecostosa e dall’altro far comprendere ai fornitori di sistemi domotici che, adottarele nuove tecnologie della IoT e l’apertura che ne può derivare, può portare unreale giovamento a un mercato che ancora manca di una ampia adozione daparte del pubblico.

Dopo questa breve introduzione vediamo come è stato suddiviso il testo per for-nire un quadro generale che possa aiutare la lettura e la ricerca di un eventualeargomento.La prima sezione riguarda Internet of Things dove verranno date le definizionidel termine e si prenderanno in esame gli standard e i protocolli che risultanodi notevole importanza in questo contesto. Verranno inoltre forniti alcuni dati

2

interessanti per cercare di dare una idea delle dimensioni di questo fenomeno ecome venga percepito dall’industria.Nella seconda sezione, riguardante il settore della Home Automation, ne pre-senta il percorso nel tempo e i problemi che ne limitano l’adozione da parte deiproprietari di appartamenti. Vengono illustrati alcuni degli standard che vengo-no utilizzati in questo ambito e i principali sistemi che possono essere acquistatiin Italia esponendone le principali caratteristiche. Per concludere vengono pre-sentate alcune soluzioni che si sono affacciate recentemente su questo mercatoche sfruttano le tecnologie proprie della IoT.L’ultima sezione, la più corposa di tutte, è riservata alla progettazione di unsistema di Home Automation che riuscisse a sfruttare le tecnologie della IoTper ampliare le funzionalità di un reale sistema domotico in un reale conte-sto abitativo. Viene presentato in parte il percorso seguito per raggiungere gliobiettivi, superando alcune difficoltà incontrate, fino ad ottenere un sistemacompletamente funzionante e realmente utilizzato che presenti buone caratte-ristiche di apertura, flessibilità e performance. A conclusione vengono espostealcune valutazione su quanto realizzato.

3

2 Internet of Things

Probabilmente la prima volta che comparve il termine Internet of Things fu inuna presentazione fatta da Kevin Ashton1 nel 1999. Kevin Ashton è stato ilcofondatore e direttore esecutivo dell’Auto-ID Center, un gruppo del Massachu-setts Institute of Technology (MIT), che fu fondato nell’intento di sviluppareun sistema, basato su tecnologia RFID, per sostituire l’ormai datato UPC BarCode2.

Figura 2.1: Nascita dell’internet delle cose

Secondo una stima di Cisco IBSG (Internet Business Solutions Group) la Inter-net of Things sarebbe “nata” tra il 2008 e il 2009 quando il numero di dispositiviconnessi ad internet ha superato il numero della popolazione mondiale[11]. Nel

1http://www.rfidjournal.com/articles/view?49862https://en.wikipedia.org/wiki/Barcode

5


2010 il boom di smartphone e tablet ha portato il numero di dispositivi connessia internet a 12,5 miliardi mentre la popolazione mondiale è salita a 6,8 miliar-di quindi, il numero di dispositivi connessi per persona, ha raggiunto il valore1,843. Come si può vedere dalla figura 2.1 la stima di Cisco IBSG proseguivaipotizzando che i dispositivi connessi ad internet sarebbero diventati 25 miliardinel 2015 e avrebbero raggiunto i 50 miliardi entro il 2020.Gartner, multinazionale leader nella consulenza strategica, ricerca e analisi nelcampo dell’Information Technology, stila annualmente documenti e rapportie, tra i numerosi dati, compare anche una rappresentazione grafica sviluppa-ta e utilizzata per indicare la maturità, adozione e applicazione di specifichetecnologie.

Figura 2.2: Gartner Hype Cycle

L’Hype Cycle (vedi figura 2.2) è suddiviso in cinque fasi chiave il cui insiemedescrive il ciclo di vita a cui è destinata una tecnologia:

3Fonti: Cisco IBSG, 2010; U.S. Census Bureau, 2010.

6

Technology Trigger. Una tecnologia potenzialmente innovativa ha inizio. Pri-mi tentativi di progetto e l’interesse dei media genera significativadivulgazione. Spesso non esistono prodotti utilizzabili e la fattibilitàper la commercializzazione non è certificata.

Peak of Inflated Expectations. L’iniziale divulgazione produce un certo nu-mero di casi di successo - spesso accompagnati da molteplici falli-menti. Alcune aziende vi prendono parte; molte evitano.

Trough of Disillusionment. L’interesse diminuisce così come gli esperimentie le implementazioni non vengono realizzate. Fornitori della tecno-logia si ridimensionano o falliscono. Gli investimenti continuanosolo se i fornitori sopravvissuti migliorano i loro prodotti per lasoddisfazione dei primi acquirenti.

Slope of Enlightenment. Maggiori esempi di come le aziende possono be-neficiare della tecnologia cominciano a cristallizzarsi e iniziano adessere capite maggiormente. Seconda e terza generazione di pro-dotti appaiono dai fornitori di tecnologia. Più aziende finanzianoesperimenti; ditte più conservative rimangono caute.

Plateau of Productivity. L’adozione su larga scala inizia a decollare. Peri fornitori sono definiti più chiaramente i criteri per valutarne lafattibilità. Un ampio mercato per l’applicabilità della tecnologiasta chiaramente dando risultati.

Interpretando la curva di Gartner possiamo notare che quando “nasce” unanuova tecnologia molte aziende e start-up hanno forti aspettative e fanno in-vestimenti nel settore. Quando si arriva al top delle aspettative però questeaziende non iniziano subito a raccoglierne i frutti ma cadono in una fase incui molte start-up e progetti falliscono perchè non rievono ordini. Nel tempoperò, le aziende rimaste, attraverso una ulteriore fase, raggiungono il plateaudi produttività dove finalmente cominciano a fatturare e dove si crea il realemercato.

7


Figura 2.3: Gartner Hype Cycle of technology 2015

Dalla figura 2.3 si nota come l’internet delle cose attualmente sia nella fase incui sta creando maggiori aspettative e nella legenda si può ricavare la stima deltempo che impiegherà questa tecnologia a raggiungere la fase in cui diventeràproduttiva.Nel presente capitolo si cercherà di dare una definizione di Internet of Things edi illustrare le principali tecnologie e standard adottati in questo contesto.

2.1 Definizione

Inizialmente, in letteratura, potevano essere ritrovate molteplici definizioni deltermine Internet of Things e questo non era altro che il risultato del forteinteresse che la comunità di ricerca rivestiva in questo nuovo concetto e dallavivacità dei dibattiti su di esso [2]. La confusione era prodotta dal terminestesso e dalle parole da cui è composto.

8

2.1 Definizione

Differenti visioni (vedi figura 2.4) dipesero da come enti di ricerca, standardiz-zazione e alleanze commerciali approcciarono il problema: solitamente in baseai loro interessi, finalità e background.

Figura 2.4: IoT come unione di più visioni

La prima definizione di IoT, come abbiamo visto all’inizio del capitolo, derivada una prospettiva “Thing oriented” dovuta allo sviluppo di semplici ogget-ti: i tag Radio-Frequency IDentification (RFID). Il termine IoT però implicauna visione più ampia rispetto alla semplice identificazione degli oggetti co-me, ad esempio, gli Smart Item, dotati di memoria, capacità di elaborazione ecomunicazione wireless. L’abilità di connettere questi dispositivi, permetternela comunicazione tra loro e internet, garantendo la possibilità di nuovi serviziper le persone, rappresentava la congiunzione tra la visione “Thing oriented” ela visione “Internet oriented” [2], che promuoveva Internet Protocol (IP) cometecnologia per connettere tutti gli Smart Object del mondo.A lato, non meno importante delle prime due, c’era la visione “Semantic orien-ted” maturata dalla consapevolezza che in questa futura internet il problema

9


sarebbe stato l’enorme mole di informazione che avrebbe creato un numero cosìelevato di oggetti abilitati a comunicare.Per comprendere meglio la portata di questa innovazione cerchiamo di elencarei principali elementi che sono in grado di generare le funzionalità della IoT [1]:

Identification: bisogna distinguere tra identificazione e indirizzamento. Seb-bene ci siano diversi modi per identificare un oggetto, come ad esempiotramite Electronic Product Code (EPC), i metodi di identificazione pos-sono non essere univoci globalmente. Quindi si rende necessario utilizzareanche un ulteriore metodo di indirizzamento per identificare con certezzaun oggetto (ad esempio tramite IPv6).

Sensing: si intende ottenere informazione dagli oggetti di una rete per unasuccessiva elaborazione. In questo caso si tratta sia di sensori che di at-tuatori ma anche di Single Board Computer (SBC) tipicamente utilizzatiper realizzare prodotti della IoT.

Communication: l’insieme delle tecnologie per collegare tra loro gli oggetti inmodo da fornire i servizi a loro richiesti.

Computation: comprende sia le piattaforme hardware che quelle software. Trale piattaforme software vengono considerati anche i sistemi operativi in-clusi nei vari device. Per finire si aggiungono le piattaforme cloud e iframework per realizzare servizi IoT.

Service: Al-Fuqaha [1] suddivide i servizi forniti dalla IoT in quattro classi.

Identity-Related si tratta di servizi la cui importanza è tale da risulta-re come base per tutti gli altri tipi di servizi. Qualsiasi ap-plicazione ha bisogno di identificare gli oggetti con cui develavorare.

Information Aggregation il cui scopo è quello di collezionare i dati ricevutidalle misure effettuate dai sensori.

10

2.2 Principali standard

Collaborative-Aware sfruttando il servizio Information Aggregation e idati da esso forniti sono in grado di fornire supporto alle deci-sioni e compiere azioni opportune. Ricadono, ad esempio, inquesta categoria le applicazioni per Smart Home & Building.

Ubiquitous consentono di fornire i servizi della classe Collaboratie-Awarea chiunque, in qualunque momento e dovunque. Un esempiodi questo tipo di servizi è ciò che viene chiamato Smart City.

Semantic: modellare, riconoscere e analizzare le informazioni per fornire sup-porto alle decisioni. Rappresenta la mente della IoT.

Vediamo ora i principali standard e le tecnologie sviluppate a supporto dellaInternet of Things.


Il termine Internet of Things (IoT) si riferisce a una rete globale di reti checomprendono miliardi di dispositivi differenti chiamati “smart object” oppure“thing”. Si tratta di dispositivi con risorse limitate, limitata capacità di calcoloe memoria, tipicamente alimentati a batteria, con interfaccia radio e forniti disensori e attuatori. Le limitazioni non sono semplicemente hardware ma, permantenere efficienza energetica i protocolli di comunicazione e i sistemi operatividevono essere progettati attentamente e implementati in modo da minimizzare ilconsumo di energia. Generalmente questi Smart Object operano in reti wirelessa bassa potenza e con molte perdite di conseguenza fanno uso del protocolloIEEE 802.15.4 nato e progettato proprio per questo scenario.Questa enorme quantità di dispositivi richiede la possibilità di integrarsi e in-teragire con la rete internet tradizionale e questo richiede politiche di indirizza-mento efficaci che il protocollo IPv4, con i suoi indirizzi da 4 byte, non è in gradodi fornire. Mediante l’introduzione di IPv6, grazie ai suoi 128 bit, si è in gradodi definire fino a 1038 indirizzi il che dovrebbe essere sufficiente a identificarequalsiasi oggetto al quale fossimo interessati ad assegnare un indirizzo.

11


RFID e NFC.

Agli inizi del 2000 l’RFID era considerata la tecnologia più promettente a for-nire un’accelerazione alla formazione della IoT. Fu realizzato anche un nuovostandard chiamato UHF RFID in grado di automatizzare la lettura dei tag auna distanza di 8-10 metri in modo da sostituire l’utilizzo dei Barcode ma, inpratica, problemi nella rilevazione dovuti a un errato posizionamento del tag/-prodotto limitarono l’adozione di questo nuovo standard da parte di grossistidel calibro di Walmart e Tesco.La Near-Field Communication (NFC) è una forma di RFID che ha fornito aquesto sistema un’ulteriore possibilità soprattutto legata al supporto dei pa-gamenti elettronici. Sebbene non tutti gli smartphone comprendono questatecnologia grandi aziende come Apple (e la diffusione dei loro sistemi di pa-gamento come ApplePay) potrebbe fornire una ulteriore spinta all’adozione diquesta tecnologia anche come abilitante per la IoT.

Optical tag e Quick Response Codes.

Il successo del Quick Response Code (QRCode) è legato direttamnete alla dif-fusione dell’applicazoine che fa utilizzo della fotocamera ad alta risoluzione cheè possibile trovare oramai in tutti gli smartphone più recenti.Sebbene si possano trovare esempi di QRcode in giornali, riviste, depliant, ecc.la sua adozione è rallentata da una tiepida risposta da parte degli utenti. Ilmotivo si può ricercare proprio nella necessità di pre-installare l’applicazione ri-chiesta per leggere i QRcode e nella difficoltà di posizionamento della fotocameraper la messa a fuoco e la decodifica accurata dell’immagine.

6LoWPAN

Si tratta di un protocollo nato per permettere ai pacchetti IPv6 di viaggiaresu reti wireless a bassa potenza (in particolare IEEE 802.15.4). La nascita èdovuta all’idea di voler applicare il protocollo internet anche ai più piccoli dei

12


Figura 2.5: Stack IP e 6LoWPAN

dispositivi ma in grado di gestire i requisiti per IPv6, come il maggior spazio diindirizzamento e l’MTU di 1280 byte.Il protocollo IPv6 over Low power Wireless Personal Area Networks (6LoW-PAN) prevede l’incapsulamento e meccanismi di compressione degli header chepermettono di in inviare e ricevere pacchetti IPv6 tra dispositivi con risorselimitate.Dalla figura 2.5 si può notare la presenza di un livello di adattamento tra illivello data link e quello IP. Il livello di adattamento è il componente che con-sente di inserire pacchetti IPv6 all’interno del payload dei frame IEEE 802.15.4.Ad esempio l’header IPv6 è formato da 40 byte e senza compressione sarebbeimpossibile trasmettere un qualsiasi payload con un livello data link come quel-lo di IEEE 802.15.4 che ha una dimensione massima del pacchetto di solo 128byte. Un altro caso è il Maximum Transmission Unit (MTU) che nel caso diIPv6 può raggiungere i 1280 byte mentre IEEE 802.15.4 supporta al massimo128 byte [32].Per connettere una Personal Area Network (PAN) a internet è possibile uti-lizzare edge router il cui ruolo è quello di instradare i pacchetti IP da e perl’esterno oltre che gestire i dispositivi interni tramite discovery e distribuzionedel prefisso IPv6.

Ethernet o IEEE 802.3

Ethernet (anche noto come IEEE 802.3) è lo standard risultato vincitore per larealizzazione di LAN domestiche e aziendali, per cui può sembrare appropriato

13


un suo utilizzo anche per collegare periferiche in ambito domotico, in quanto loscopo di Ethernet è quello di collegare tra loro in modo semplice ed efficientedispositivi e risorse di rete. Il grande vantaggio di questo protocollo è la suaenorme diffusione, che ne ha permesso l’evoluzione negli anni. Il mezzo dicomunicazione è il cavo, o coassiale (in disuso), o doppino di categoria 5 e 6(il più utilizzato) o la fibra ottica e le possibili velocità di trasmissione varianodi un ordine di grandezza da 1 Mbps a 1 Gbps. Il sistema di indirizzamento èstatico, in quanto a ogni periferica viene assegnato un indirizzo (MAC address)a tempo di fabbricazione e la comunicazione avviene in broadcast. Il protocolloviene comunemente integrato nello stack TCP/IP. Per le sue caratteristiche,Ethernet può essere utilizzato per la realizzazione di alcune funzioni domoticheall’interno di un’abitazione, ma la sua diffusione massiccia è fortemente frenatadal fatto di essere legata strettamente alla cablatura, che ne scoraggia l’uso.

Wi-Fi o IEEE 802.11

La scelta più ovvia come tecnologia di networking per un dispositivo per l’IoTè il Wi-Fi perchè è molto diffuso. Purtroppo il Wi-Fi richiede una discretaquantità di potenza che non tutti i dispositivi possono permettersi, ad esempio,sensori posizionati in luoghi difficili da raggiungere dall’alimentazione di rete.

IEEE 802.15.4

Rilasciato nel 2003 lo standard radio IEEE 802.15.4 è una delle maggiori tecno-logie abilitanti per l’IoT ed è stato concepito per regolamentare il livello livellofisico (PHY) per Low-Rate Wireless Private Area Network (LR-WPAN) ed illivello Medium Access Control (MAC) di reti in area personale (massimo 30metri) e che lavorano con basse velocità di trasferimento dati.Grazie alle sue caratteristiche come basso consumo di potenza, bassi data-rate,prezzo basso e alto throughput è utilizzato da IoT, M2M e Wireless SensorNetwork (WSN). È in grado di fornire una comunicazione affidabile e può gestireun elevato numero di nodi (circa 65k). Garantisce inoltre un alto livello di

14


sicurezza, cifratura e servizi di autenticazione sebbene non fornisca garanzie diQoS [1].A seconda del canale di frequenza usato il livello fisico trasmette/riceve i daticon tre data-rate diversi: 250 kbps @ 2.4 GHz, 40 kbps @ 915 MHz e 20 kbpsa 868 MHz. Per ridurre le collisioni IEEE 802.15.4 MAC utilizza il protocolloCSMA/CA.

Figura 2.6: Topologie per 802.15.4

Supporta due tipi di nodi di rete: Full e Reduced Function Device (FFD e RFD).Un FFD può servire come coordinatore di una Personal Area Network (PAN)o anche come nodo normale. Un coordinatore è responsabile della creazione,controllo e gestione della rete. Gli RFD invece sono nodi molto semplici conrisorse limitate.Si ottiene una rete quando due o più device comunicano sullo stesso canalefisico. Per costruire una rete è necessario avere almeno un dispositivo FFD cheagisca come PAN Coordinator. Il PAN Coordinator oltre a iniziare e terminare

15


la comunicazione (come un RFD) può anche instradare la comunicazione sullarete. Generalmente il coordinatore è alimentato da rete e non a batterie.

ZigBee

Il protocollo ZigBee, basato sullo standard 802.15.4 e sviluppato dalla ZigBeeAlliance, è stato definito nel 2003 allo scopo di supportare reti di oggetti a costie consumi energetici molto minori rispetto ad altri più noti protocolli wireless;per questo è appropriato ad essere utilizzato per reti di sensori, ma le suecaratteristiche possono essere sfruttate da qualsiasi dispositivo. Il protocollo èwireless e lavora tra le bande di 2,4 GHz, 902-928 MHz e 868,3 MHz, mentrel’accesso al mezzo è gestito tramite CSMA/CA. I componenti di una rete ZigBeesono:

• ZigBee Coordinator: l’apparato con maggiore memoria e capacità di cal-colo, in quanto deve avere una conoscenza completa della rete e devegestirla. Ogni rete ne deve avere uno;

• ZigBee Routers: dispositivi che implementano tutte le funzionalità delprotocollo 802.11.4 e che sono tipicamente usati per gestire un gruppo diZigBee End Devices e instradare i messaggi allo ZigBee Coordinator. Retisemplici, ad esempio con tipologia a stella con il Coordinator in posizionecentrale, possono non essere dotate di ZigBee Routers;

• ZigBee End Devices: dispositivi a ridotte funzionalità al fine di ridurnela complessità ed il consumo energetico; tipicamente sono i sensori allaperiferia della rete.

La rete ZigBee è autoconfigurante e offre interessanti caratteristiche di sicurezza.Il throughput di 224 Kbps è sufficiente per le normali funzioni di automazionedomestica escluse quelle per la gestione dei flussi audio/video. Essendo una reteconforme agli standard IEEE 802, ZigBee può essere collegata tramite bridgead altre reti IEEE 802 come Ethernet. E’ quindi possibile controllare una reteZigBee da un personal computer, controllato a sua volta tramite Internet.

16


Z-Wave

Realizzato dalla Zensys e dalla Z-Wave alliance, Z-Wave è un protocollo perrealizzare reti wireless di oggetti di semplici a basso consumo energetico. Moltosimile a ZigBee per scopi e vincoli progettuali. Le sue differenze da ZigBeepossono essere così riassunte:

• non lavora alla frequenza di 2,4 GHz;

• le reti Z-Wave sono tipicamente reti mesh senza un’entità centrale dicontrollo, la comunicazione tra dispositivi tra loro fuori portata avvienetramite la ripetizione del segnale dei nodi intermedi;

• ZigBee è stato realizzato dall’unione di grandi industrie (Philips, Moto-rola, Mitsubishi, Honeywell, ecc.) e ha ottenuto la standardizzazione dal-l’IEEE, Z-Wave è stato realizzato dalla Z-Wave alliance (Zensys, Leviton,Danfoss, ecc.).

Bluetooth

Lo standard Bluetooth è stato realizzato nel 1998 dai maggiori produttori diapparecchiature telefoniche. Inizialmente è stato pensato per realizzare PAN(Personal Area Network) e fondamentalmente per collegare senza bisogno di filil’auricolare al telefono cellulare (lo standard prevede meccanismi particolari perla gestione di audio); successivamente lo standard è stato sfruttato per svariatitipi di uso e non si esclude un suo possibile utilizzo in domotica, nonostante lesue caratteristiche non si addicano pienamente a tale scopo. Lo standard è wi-reless ed è basato su Frequency Hopping Spread Spectrum (FHSS) con frequenzacentrale attorno ai 2,4 GHz (e quindi sulle frequenze libere, le stesse usate perle WLAN 802.11b). I vantaggi nell’uso di Bluetooth nelle applicazioni domo-tiche derivano solamente dal fatto che è uno standard wireless (e quindi nonnecessita di interventi manuali sulle abitazioni esistenti) e che è uno standardconosciuto e abbastanza diffuso. Gli svantaggi tuttavia sono molto maggiori;infatti Bluetooth è stato concepito per reti a corto raggio, una decina di me-tri circa, (caratteristica migliorata con l’introduzione di Bluetooth 2) e per lo

17


scambio di grosse quantità di dati con frequenza molto sporadica (situazioneperfetta per la comunicazione tra auricolare e telefono cellulare). Le applicazio-ni domotiche hanno difficoltà a rimanere nei raggi d’azione di Bluetooth (ancheper la presenza di ostacoli come muri o mobili tra i dispositivi) e tipicamentenecessitano di scambiarsi piccole quantità di dati o semplici comandi in ma-niera più frequente. Ogni singola rete Bluetooth, detta piconet, è dinamica egestisce autonomamente l’ingresso e l’abbandono delle periferiche, ma ha unastruttura master-slave che impone la presenza di un’entità centrale, il master,con il compito di gestire le altre periferiche. In una piconet non possono esserepresenti più di sette slave attivi per ogni istante di tempo (esistono meccanismiper il cambio di stato degli slave da ready a parked). Se si vuole quindi crea-re una rete con più di otto dispositivi attivi contemporaneamente è necessariounire più piconet, creando una scatternet, ad esempio creando una gerarchia dimaster o facendo condividere a due o più masters uno stesso slave.

Bluetooth Low Energy.

Rispetto alla precedente versione sfrutta una comunicazione radio a corto raggio(massimo 100 metri) con una quantità minima di potenza in modo da poterlavorare per tempi più lunghi. BLE può lavorare con potenze di trasmissionetra i 0.01 mW e i 10 mW e risulta essere un buon candidato per le applicazioniIoT [1].Confrontato a ZigBee è più efficiente in termini di energia consumata e nelrapporto tra energia trasmessa e bit. Permette ai dispositivi di lavorare comemaster o come slave in una topologia a stella. Dotato di meccanismo di discoverygli slave inviano annunci su uno o più canali dedicati a questo meccanismoche vengono scannerizzati dal dispositivo master. A parte quando avviene loscambio dei dati rimangono in modalità sleep per il resto del tempo.

18

2.3 Protocolli a livello applicativo


Ci sono due paradigmi che possono essere utilizzati per la comunicazione traapplicazioni: request/response (polling) e publish/subscribe (push-based). Nelprimo caso il client richiede esplicitamente alcune informazioni a un server che ri-sponde con le informazioni richieste. Nel secondo un nodo pubblica del contenu-to che è successivamente consegnato a uno o più subscriber attraverso un brokeroppure direttamente. HTTP, ad esempio, implementa il modello a polling.

CoAP

Come progetto del gruppo IETF Constrained RESTful Environments (CoRE)il protocollo Constrained Application Protocol (CoAP) è stato progettato perportare il paradigma REpresentational State Transfer (REST), originariamenteconcepito per applicazioni basate su HTTP, verso applicazioni IoT notoriamenteaffette da molti vincoli di risorse.

Figura 2.7: Stack HTTP e CoAP

CoAP è un protocollo binario che sfrutta il trasporto UDP, basato su un model-lo di comunicazione del tipo request/response simile al modello client/server diHTTP ed è in grado di effettuare comunicazioni multicast. Il protocollo HTTP,basato su trasporto TCP, ha problemi con ambienti dalle risorse limitate in par-ticolare con comunicazioni wireless a bassa potenza mentre il nuovo protocollorealizzato da IETF può operare anche su reti IP tradizionali; ma il meglio di selo da su reti vincolate da risorse limitate come reti wireless di sensori dove cisono vincoli di potenza, memoria e di calcolo.

19


Per gestire il packet loss e successive ritrasmissioni, le applicazioni che lavoranoin questi ambienti devono inviare la quantità di dati più piccola possibile. Iprotocolli per il livello di applicazione devono essere progettati in modo da te-nere in considerazione il requisito di basso overhead richiesto dai livelli inferiori.CoAP è un protocollo binario molto leggero che può essere mappato facilmentein HTTP e quindi può integrarsi con il Web ma fornisce anche capacità ulterioriquali multicast, resource observing e service discovery [10].CoAP implementa un modello request/response sopra UDP e l’utilizzo di UDPal posto di TCP ha le sue ragioni: è un protocollo di trasporto con un headerdi soli 8 byte, non richiede di impostare una connessione tra gli endpoint dicomunicazione ed è compatibile con dispositivi che richiedono di “cadere” insleep mode per lunghi periodi di tempo (e che quindi non potrebbero mantenereattiva una connessione).

Figura 2.8: Formato dei messaggi CoAP

CoAP utilizza un formato molto semplice e contenuto per codificare i messaggi.Una prima parte fissa di 4 byte rappresenta l’header. Ci può essere anche untoken la cui lunghezza può variare da zero a 8 byte e che aiuta a correlare lerichieste e le risposte. Seguono campi opzionali per option e payload. Un tipicomessaggio CoAP può variare tra 10 e i 20 byte e i campi presenti nella figura 2.8hanno i seguenti significati: Ver è la versione di CoAP, T è il tipo di transazione,OC sta per Option count e Code rappresenta il metodo della richiesta (1-10) oil codice della risposta (40-255). Ad esempio 1, 2, 3 e 4 stanno rispettivamenteper GET, POST, PUT e DELETE. Message ID è un identificativo per farematch con la risposta [1].La natura di UDP però introduce alcune limitazioni (invece automaticamen-te gestite da TCP) che devono essere risolte al livello di applicazione come adesempio le ritrasmissioni e il request/response matching. CoAP risolve il proble-

20


Figura 2.9: Tipi di messaggi CoAP

ma dell’affidabilità mediante l’utilizzo di messaggi Confirmable (CON). Quandouna richiesta CON viene inviata il client si aspetta di ricevere un messaggio diAcknowledgement (ACK) dal server per confermare l’avvenuta consegna del-la richiesta. Se questo non avviene il client ritrasmette la richiesta al server.Allo stesso modo il server quando deve rispondere a una richiesta CON lo fatrasmettendo la risposta in un ulteriore messaggio CON attendendo in questomodo un messaggio di ACK a confermare la consegna con successo della rispo-sta. Sia client che server utilizzano un timeout di ritrasmissione con exponentialback-off.CoAP è stato progettato per fornire una integrazione trasparente con il Web.Un “cross-proxy” è un elemento della rete che fornisce funzionalità di protocoltranslation per permettere l’integrazione tra endpoint HTTP e CoAP. I Cross-proxy garantiscono la massima interoperabilità tra internet e internet of thingrappresentando il punto di contatto tra di loro. Altri vantaggi sono la possi-bilità di nascondere dettagli della rete interna (fornendo anche meccanismi dicaching), migliorare la sicurezza e ridurre il consumo di energia[10, 1].Tra le opzioni c’è la modalità Observe con la quale viene introdotto un modellodi comunicazione nuovo che differisce dal tradizionale request/response (pol-ling). Quando un client vuole “osservare” una risorsa inoltra una richiesta GETe include la Observe option. Il server invia la risposta e registra il client comedestinatario di notifiche qualora avvengano cambiamenti nello stato della risor-sa. Quindi, una singola richiesta può risultare in più risposte, implementando

21


Figura 2.10: Cross-Proxy CoAP

un modello publish/subscribe [10, 32].

MQTT

MQTT è un protocollo per il trasporto di messaggi per client e server del tipopublish/subscribe. È leggero, aperto, semplice e progettato in modo da esseresemplice da implementare. Queste caratteristiche lo rendono ideale per l’utilizzoin molti casi, incluso in contesti vincolati come per le comunicazioni Machineto Machine (M2M e IoT dove è richiesto un footprint ridotto del codice e/o laquantità di banda è limitata 4.MQTT è stato inventato da Andy Stanford-Clark (IBM) e Arlen Nipper (Ar-com, ora Eurotech) nel 1999 quando lo scopo era quello di creare un protocolloper ridotte capacità di banda e consumi di batteria per collegare tubazioni dipetrolio su connessione satellitare.MQTT non ha un significato ufficiale anche se per ragioni storiche si potrebbeusare l’acronimo di MQ Telemetry Transport dove per MQ potrebbe far rife-

4specifiche MQTT 3.1.1 - http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html

22


rimento a un prodotto di IBM che supportava MQTT. Spesso viene chiamatoMessage Queue protocol ma non è corretto in quanto non esistono code comenelle soluzioni tradizionali di message queuing.In alternativa al modello client/server dove un client comunica direttamentecon un endpoint il pattern publish/subscribe disaccoppia un client (chiamatopublisher), che invia un messaggio, da un altro client (chiamato subscriber),che lo riceve. C’è una terza entità chiamata broker che mette in comunicazionei due client, filtra i messaggi in arrivo e li distribuisce in modo opportuno.Oltre ai principali aspetti del modello pub/sub il disaccoppiamento tra publishere subscriber può essere riferito anche ad altre dimensioni:

• nello spazio - publisher e subscriber non devono conoscersi tra loro

• nel tempo - publisher e subscriber non devono essere presenti allo stessoistante

• comunicazione asincrona - le operazioni in entrambi i componenti nonsono in attesa durante il trasferimento dei dati.

MQTT incarna completamente il modello appena esposto e disaccoppia lo spa-zio di publisher e subscriber ed è in grado di conservare i messaggi di client chenon sono online. La maggior parte delle librerie client lavorano in modo asincro-no e sono basate su callback permettendo al client di non bloccarsi nell’attesadi un messaggio o nel caso di invio.Il Broker MQTT è in grado di ricevere tutti i messaggi, filtrarli e decidere tratutti i client a lui registrati chi deve ricevere un particolare messaggio.

Figura 2.11: Stack MQTT

23


Il protocollo MQTT è costruito sopra TCP/IP e di conseguenza entrambi, traclient e broker, devono implementare uno stack TCP/IP. La connessione avvienesempre tra client e broker in quanto non è possibile trovare client connessidirettamente ad altri client. Una connessione inizia quando un client invia unmessaggio di tipo CONNECT al broker. Il broker risponde con un CONNACK euno staus code. Il broker mantiene aperta la connessione fino a quando il clientnon invia un comando di disconnessione o si perde la connessione. Dato che laconnessione inizia sempre lato client non ci sono problemi nel caso di NetworkAddress Translation (NAT) e il broker ha solitamente un indirizzo pubblico.

Figura 2.12: Trasferimento dati con MQTT

Dopo che un client si è connesso al broker può pubblicare i messaggi. Datoche il broker basa le sue regole di filtraggio su un soggetto ogni messaggio devecontenere un topic, che sarà utilizzato dal broker per inoltrare il messaggioai client interessati, più il payload da trasmettere. MQTT è completamenteindifferente al contenuto del payload che quindi dipende completamente dalpublisher.Per ricevere un messaggio è necessario inviare una messaggio di tipo SUBSCRI-BE al broker. Questo tipo di messaggio è molto semplice e richiede solo la listadi topic a cui si è interessati.Un topic non è altro che una stringa espressa in formato UTF-8 espressa in livelliseparati da un carattere speciale (forward slash). Quando un client sottoscriveun topic per la ricezione di un messaggio può utilizzare la stringa esatta o puòsottoscrivere più topic alla volta utilizzando le wildcards. Si tratta di simboliparticolari inseriti a un certo livello del topic.

24

2.4 IoT e WoT

Figura 2.13: Formato messaggio MQTT

Una delle caratteristiche di MQTT è che è in grado di rendere più semplici lecomunicazioni su reti inaffidabili perchè il protocollo gestisce le ritrasmissionie garantisce la consegna dei messaggi. Inoltre permette ai client di scegliere illivello di QoS in base all’affidabilità della rete e alla logica di applicazione. QoSin MQTT è implementato a livelli:

• QoS 0 - at most once è il livello minimo che garantisce una consegna conminor sforzo. Il ricevitore non darà un ACK ed è chiamato spesso “fireand forget”

• QoS 1 - at least once garantisce che il messaggio sarà consegnato almenouna volta al ricevitore. Ma potrebbe essere consegnato anche più volte.Chi invia il messaggio lo memorizza fino a quando non riceve un ACKnella forma di PUBACK dal ricevitore. Il publisher reinvierà il messaggio(con flag DUP) se non riceverà un PUBACK in un tempo ragionevole.

• QoS 2 - garantisce che ogni messaggio sia ricevuto solo una volta. È illivello più sicuro ma anche il più lento.

2.4 IoT e WoT

Inizialmente col termine Internet of Things non ci si riferiva altro che a unainterconnessione tra dispositivi [13]. Il termine non si riferiva a qualche tecno-logia particolare o a una qualche struttura di rete ma semplicemente all’ideadi connettere oggetti così come si potevano connettere i computer a internet.

25


Qualche dettaglio in più può essere ricavato da Atzori [2] che spiega come moltienti di standardizzazione e ricerca erano coinvolti nell’attività di sviluppo perrealizzare una maggiore interoperabilità possibile tra dispositivi fornendogli unalto grado di adattamento e autonomia garantendo comunque sicurezza e pri-vacy. Ad ogni modo era ancora difficile comprendere cosa si intendeva con iltermine IoT e il problema nasceva proprio dalle parole da cui era composto; dif-ferenti visioni nacquero dal modo in cui enti di ricerca e alleanze commerciali,basandosi sui propri interessi, finalità e background approcciavano il termine.Per chi utilizzava una prospettiva “Internet oriented”, piuttosto che “Thingoriented”, il web era diventato il principale mezzo di comunicazione in inter-net e sempre più servizi erano forniti tramite applicazioni web[32]. L’idea diaccedere a dispositivi nelle immediate vicinanze tramite applicazioni web vennechiamata Web of Thing [13].Per applicare i concetti della Web of Thing occorre riuscire a inserire dei webserver in dispositivi con solo qualche centinaia di byte di RAM e pochi kbytedi EEPROM. Fortunatamente, e diversamente dai web server per internet, nonè richiesto di gestire migliaia di richieste e connessioni simultanee, inoltre moltisforzi sono stati fatti per ridurre la dimensione dello stack TCP/IP riducendolofino a richiedere pochi kbyte di RAM [13, 32].Per integrare questi Smart Thing nel web si possono seguire due strade: Directe Indirect Integration. Tramite Direct Integration occorre che i dispositivi sianoindirizzabili e quindi che posseggano un indirizzo IP. Deve possedere un webserver in modo da consentire che una thing possa accedere e comunicare conun’altra attraverso operazioni web stardard come, ad esempio GET e POST.Non tutti i dispositivi però sono in grado di integrare un web server per colpadelle ridotte risorse di cui dispone e, a dire il vero, non è necessario integraredirettamente tutte le smart thing nel web (ad esempio i sensori di una sensornetwork). In questo caso di Indirect Integration sono utilizzati degli Intermedia-te Proxy posizionati tra le smart thing e il web. Questi proxy sono solitamentechiamati Smart Gateway in quanto astraggono i protocolli proprietari o le APInative offrendo un accesso uniforme tramite web API [32].

26

2.4 IoT e WoT

Dopo aver integrato differenti dispositivi, con varie capacità, nel web il passosuccessivo è quello di astrarre questi dispositivi in web services anzichè forniresemplicemente delle pagine statiche o dinamiche. I Web Service, definiti dalWorld Wide Web Consortium (W3C) come un sistema software progettato persupportare le comunicazioniMachine to Machine (M2M), seguono due maggioriparadigmi.

Figura 2.14: Web Service

Ci si riferisce ad architetture di tipo WS-* quando si parla di web service cheutilizzano messaggi Simple Object Access Protocol (SOAP) con payload di ti-po Extensible Markup Language (XML) e forniscono Remote Procedure Call(RPC) tra client e server tramite un protocollo di trasporto basato su HTTP.Il problema è che questo tipo di architettura è realmente molto pesante e nonsi adatta particolarmente bene al contesto della IoT.Molto più snella è invece l’architettura REpresentational State Transfer (REST-ful) considerata la reale architettura del Web. Il concetto di fondo di REST èche ad ogni risorsa è associato un Universal Resource Identifier (URI) in modotale che ogni client possa identificare univocamente tale risorsa. HTTP nonviene utilizzato come protocollo di trasporto come in WS-* ma come livello diapplicazione quindi le risorse possono essere manipolate usando verbi di HTTPcome PUT, GET, POST e DELETE. L’architettura RESTful risulta preferibileper la WoT principalmente per la bassa complessità e l’interazione stateless che

27


Figura 2.15: Confronto tra WS-* e REST

garantisce il loose-coupling tra gli oggetti [32]. Queste caratteristiche consento-no di integrare l’architettura in dispositivi dalle risorse limitate e facilitano lacomposizione di web service (mashup).

28

3 Home Automation, Domotica

e Smart Home

Il termine Domotica deriva dall’importazione del neologismo francese Domo-tique, a sua volta contrazione della parola greca Domos e di Informatique erappresenta la disciplina che si occupa dell’integrazione dei dispositivi elettro-nici, degli elettrodomestici e dei sistemi di comunicazione e di controllo chesi trovano nelle nostre abitazioni. Le origini risalgono intorno agli anni ‘70quando si vennero a sviluppare i primi progetti concreti di automatismi legatialla gestione di impianti di allarme o altre funzionalità come l’accensione, lospegnimento e la temporizzazione delle luci [25, 29].Se vogliamo essere più precisi possiamo distinguere diversi termini: Home &Building Automation, Domotica e Smart Home. L’automazione di un edificiopuò consistere sia nell’automatizzare funzioni relative ad impianti elettrici etecnologici sia nell’automazione di azioni normalmente eseguite dall’uomo: ac-censione delle luci comandate da sensori anzichè pulsanti/interruttori oppureregolazione automatica di elettrovalvole per il controllo di temperature ambien-te. Nel caso residenziale si parla di Domotica o Home Automation ad indicarela misura più domestica nella gestione della casa mediante automatismi e tec-nologie in grado, ad esempio, di migliorare il livello della qualità della vitaoppure riuscendo ad avere un impatto sui consumi e di conseguenza sull’econo-mia domestica. Il termine Smart Home invece sta ad indicare lo svecchiamentodel termine ormai obsoleto di domotica per indicare la presenza di tecnologie(specialmente della IoT) in grado di interfacciarsi con la casa come involucro ecome sistema impiantistico e la spinta a sviluppare ulteriori tecnologie in grado

29

3 Home Automation, Domotica e Smart Home

di adeguare il comfort percepito basandosi sui bisogni, più o meno reali, di unabitante.

3.1 Passato, presente e futuro.

Nel ventesimo secolo si è assistito a una sensibile rivoluzione nella tecnologiadomestica, una rivoluzione culminata verso la fine del secolo con il sorgere delconcetto di Smart Home. La tecnologia domestica presente all’inizio del ven-tesimo secolo poteva essere tranquillamente riconosciuta e utilizzata da indivi-dui dei secoli precedenti mentre quella disponibile alla fine del secolo sarebberisultata incomprensibile per chiunque [19].Il primo impulso per questi cambiamenti è stato senz’altro l’introduzione nelprimo quarto di secolo dell’elettricità nelle case che ha permesso la comparsadi nuovi elettrodomestici. Il secondo fu sicuramente l’introduzione delle tecno-logie informatiche nell’ultimo quarto di secolo che ha permesso lo scambio diinformazioni tra le persone, tra sistemi e dispositivi nelle abitazioni e oltre allemura domestiche.Nella sua analisi storica Frances K. Aldrich [19] raccoglie, tra avvenimenti easpetti sociali, i motivi per l’adozione delle nuove tecnologie in ambito domesti-co. Soprattutto fa una distinzione tra prodotti che “fanno risparmiare tempo”e prodotti che “occupano il tempo”. I prodotti che “fanno risparmiare tempo”sono quelli che lasciano più tempo a disposizione riducendo il tempo richiestoper completare un particolare compito - ad esempio una lavatrice. I prodottiche “occupano il tempo” sono quelli che riducono il tempo a disposizione ma neaumentano la qualità percepita - ad esempio la televisione. Quello che vienefatto notare sono i tempi con cui si sono diffusi questi tipi di prodotti: lava-trice, aspirapolvere, frigorifero hanno impiegato decadi per essere adottati e laloro diffusione è dipesa dal reddito familiare mentre, ad esempio, televisione eradio hanno raggiunto pari livelli di diffusione in pochi anni e con un legamemolto meno marcato al reddito familiare. Inoltre si può notare come il temporisparmiato grazie agli elettrodomestici è stato prontamente occupato dalla te-

30


levisione e, in particolare verso la fine del secolo, attraverso la connessione didispositivi e computer verso informazioni e servizi esterni rispetto all’abitazione.Nonostante il concetto di “Smart House” fosse ben presente e dalla metà del1970 cominciavano a comparire i primi protocolli per la Home Automation solouna piccola parte di installazioni vennero costruite e vendute contrariamentealle previsioni favorevoli iniziali. Tra i motivi suggeriti da Gann [15] i principaliostacoli erano dovuti a:

• un grosso investimento iniziale richiesto al compratore limitando quindi ilmercato a famiglie con reddito elevato. E i potenziali acquirenti dovevanoessere prima convinti dei possibili benefici che potevano trarne

• specialmente in Europa, vista la diffusione di case già costruite, dovevanoessere trovate soluzioni per modificare case già esistenti (che è più costosoche predisporla al momento della costruzione)

• mancanza di un protocollo unico e di conseguenza, sempre in Europa,l’industria tendeva a focalizzarsi su semplici sistemi di controllo remoto diaccensione/spegnimento che non richiedevano installazioni di particolarireti

• i fornitori avevano adottato un approccio del tipo “technology push” senzaprestare bene attenzione nell’ascoltare le necessità degli utenti. In parti-colar modo mancava di superare l’accettazione da parte delle donne allequali ancora rimaneva gran parte dei compiti domestici

• il grado di formazione richiesto prima di poter utilizzare i sistemi proposti

Ci sono analogie tra l’adozione dei primi elettrodomestici e l’accettazione daparte degli utenti di nuovi sistemi di automazione. A parte le ovvie caratteri-stiche di semplicità di gestione, robustezza, flessibilità, aggiornamento, sempli-cità di installazione e soprattutto economicità, occorre superare le paure sullasicurezza e i rischi a cui si va incontro da parte dei possibili compratori.Anche l’ambito della ricerca non era particolarmente attratto dalla Home Au-tomation e le ragioni andavano ricercate nella mancanza di motivazione ad

31


aumentare la produttività nel lavoro domestico. In effetti le decisioni sui pro-dotti da acquistare in ambito lavorativo sono determinate da argomentazioniriguardanti la produttività mentre i proprietari delle abitazioni sono interessatiall’estetica, alla moda e alla volontà di apparire e in una famiglia le decisionivengono prese in modo differente rispetto a una azienda.Inoltre i progettisti ritenevano la tecnologia domestica non particolarmente at-traente e continuavano a concentrare i loro sforzi sui singoli elettrodomesti-ci dotandoli di maggiori funzionalità, magari aggiungendo connettività versol’esterno, e spesso anche solo per ragioni di marketing.In una ricerca effettuata da un punto di vista delle scienze sociali Berg notacome nonostante i lavori ripetitivi, che occupano più tempo in una abitazio-ne, sono quelli non retribuiti ed effettuati dalle donne cucinare, lavare, pulire,riordinare sono molto spesso lavori trascurati da chi realizza prototipi per leSmart House. Questo studio, sebbene realizzato ormai molti anni fa (ma tuttosommato ancora attuale), ha portato alla conclusione come ancora una volta siricade in un caso di “technology push” anzichè quello di “consumer pull” ed èdovuto principalmente ad ostinarsi al realizzare ciò che è tecnicamente possibileanzichè quello che è desiderabile.Negli ultimi anni si è assistito a un cambiamento negli attori del mercato delletecnologie per la Home Automation. Inizialmente erano i fornitori di prodottie materiale elettrico che guidavano il mercato fornendo i loro sistemi proprie-tari, aperti o meno all’integrazione con altri sistemi, mentre più recentementesempre più produttori di dispositivi elettronici fanno ingresso spingendo i loroelettrodomestici, dispositivi e sistemi affiancando al prodotto il termine “Smart”a indicare funzionalità evolute. Si parla di nomi del calibro di Samsung ed LGche offrono sistemi acquistabili direttamente sul mercato consumer.Anche i fornitori di servizi, come per l’energia elettrica, si sono affacciati almondo della domotica proponendo soluzioni in collaborazione con produttoridi elettrodomestici o di sistemi di Home Automation. Ad esempio Enel conil sistema Energy@home, avviato nel 2009 in collaborazione con Electrolux,Indesit Company e Telecom Italia con l’obiettivo di sviluppare prodotti e servizi

32


basati sull’interoperabilità e la collaborazione degli elettrodomestici oppure Enicon prodotti e soluzioni di Acotel Net per la domotica e in particolare per ilrisparmio energetico.Alle nuove tecnologie invece spetta il compito di risolvere alcuni dei problemiche inizialmente limitavano l’adozione di domotica da parte delle famiglie:

• tecnologie a radio frequenza come il Wi-Fi, Bluetooth, ZigBee e altre perrisolvere il problema di non poter modificare impianti già preesistenti odifficoltà nell’eseguire opere murarie nelle abitazioni già costruite

• hub elettronici per superare l’ostacolo dovuto a un protocollo comune diinteroperabilità tra apparecchiature di produttori differenti

• riduzione dei costi grazie a un mercato sempre più ricco di dispositivi elet-tronici a costi sempre minori e sistemi con un grado maggiore di modula-rità in modo da far crescere nel tempo il sistema anche successivamenteall’acquisto iniziale

Possono rimanere problemi legati all’usabilità dei prodotti e una attenzionemaggiore ai bisogni dell’utenza. Ad ogni modo la diffusione degli smartphone,tablet ma soprattutto di internet e la diffusione dei social network ha in qualchemodo abituato gli utenti a scontrarsi con le nuove tecnologie e a diventarepiù smaliziati nell’approcciarsi ad esse e a “spendere tempo” nel tentativo diutilizzarle.Ma quand’è che si può parlare di Smart Home?Già Aldrich [19] più di dieci anni fa affermava che il termine era applicato inmodo poco stringente e qualsiasi cosa da una casa con un sistema a circuitochiuso di videosorveglianza a installazioni molto complesse che comprendeva-no computer, elettrodomestici, sistemi di sicurezza, sensori di luminosità e ditemperatura venivano definite Smart Home.Questa affermazione potrebbe anche essere applicata tutt’ora in quando difficil-mente potrebbe essere trovato un qualcosa che rivoluzioni radicalmente il mododi vivere.Sempre Aldrich [19] propone una gerarchia di possibili Smart Home:

33


1. Homes which contain intelligent objects - che contengono cioè elettro-domestici, dispositivi e oggetti che sono in grado di lavorare in manieraintelligente

2. Homes which contain intelligent, communicating objects - che contengonoelettrodomestici, dispositivi e oggetti che non solo lavorano autonoma-mente in maniera intelligente ma che scambiano informazioni gli uni congli altri per incrementare le funzionalità

3. Connected Homes - che hanno reti interne ed esterne che permettono uncontrollo remoto e interattivo così come l’accesso a servizi all’interno eall’esterno dell’abitazione

4. Learning homes - in cui pattern di attività nella casa sono percepite,memorizzate e analizzate in modo da anticipare i bisogni dell’utente e ingrado di controllare la tecnologia della casa.

5. Attentive homes - in cui l’attività e la posizione delle persone e gli oggettiall’interno della casa sono costantemente registrate e questa informazioneè utilizzata per anticipare nuovamente i bisogni degli occupanti.

Sicuramente se un cambio di paradigma deve avvenire nel modo in cui vienevissuta la tecnologia domestica questo dovrà avvenire sicuramente considerandoil livello assegnato alla Attentive Home che presenta potenziali qualità di flessi-blità, proattività e reattività in modo da offrire un ambiente qualitativamentedifferente ai suoi abitanti.

3.2 Domotica e Home Automation

La differenza fondamentale tra un impianto elettrico tradizionale e un sistemadi Home Automation deriva essenzialmente dal livello di integrazione. Nellaprogettazione tradizionale i vari servizi potrebbero essere assicurati da impiantidiversi ed indipendenti che però non riuscirebbero a interagire fra loro; inoltre la

34


Figura 3.1: Cablaggio di tipico impianto domotico

loro coordinazione porterebbe a costi d’implementazione rilevanti e soprattuttoad una minor efficacia nel garantire possibili modifiche nel tempo [29].Al contrario i sistemi d’automazione vengono progettati proprio per far integrarevari sottoinsiemi ognuno con la propria funzionalità. Facendo parte dello stessosistema essi sono perfettamente in grado di colloquiare ed interagire con tuttigli altri. Ciò significa che, grazie a questo livello di integrazione, si riescono adottenere risultati che gli impianti tradizionali non sono in grado di offrire.Ad esempio in un impianto elettrico tradizionale la linea di alimentazione colle-ga il pulsante (o interruttore) direttamente al carico, ad esempio una lampada.Per gestire questo carico di conseguenza occorre collegare ad esso tutti i suoidispositivi di comando quindi, ad ogni variazione o aggiunta di funzioni, oc-corre modificare il cablaggio. In un impianto domotico, invece, a seguito dellapressione di un pulsante viene generato un evento e la presenza di un circuitologico permette di inviare l’informazione a uno o più attuatori che eseguirannol’azione richiesta [29].Questa complicazione per accendere semplicemente una luce potrebbe sembra-re eccessiva ma se pensiamo a impianti particolarmente estesi sicuramente ilnumero di componenti e connessioni si ridurrebbe sensibilmente. Inoltre nel-l’evenienza di dover modificare o estendere alcune funzioni il più delle voltesi riconduce a una riprogrammazione della logica di funzionamento riducendo

35


sicuramente i costi di manutenzione.

Ambiti funzionali

Dai vari manuali di domotica dei vari produttori di dispositivi o di elettroni-ca per impianti elettrici è possibile ricavare molte informazioni su quelli chevengono ritenuti da questi fornitori gli ambiti di applicazione di automatismiappartenenti al contesto della home automation.

Illuminazione

L’illuminazione è la risultante dell’effetto dell’utilizzo dei flussi luminosi natu-rali (mediati da elementi architettonici) o emessi da sorgenti artificiali (appa-recchiature generalmente elettriche) allo scopo di ottenere determinati livellidi luce (illuminamenti); la relativa tecnica si chiama illuminotecnica. Ulterioriscopi dell’illuminazione possono essere: creare effetti scenografici o di accentooppure fare arredo. Molto spesso il termine illuminazione è anche usato comesemplificazione di “impianto di illuminazione”.

Aperture motorizzate

Il sistema domotico permette di comandare le aperture motorizzate di qualsiasigenere (avvolgibili, tende da sole, oscuranti ecc. ecc.) sia singolarmente che inmaniera coordinata con tutte le altre apparecchiature di casa. Un caso moltofrequente nelle abitazioni di nuova costruzione, sono le tapparelle automatiz-zate con motori con alimentazione a 230 Vca. Il cosiddetto “attuatore” è unmotoriduttore installato dentro o a lato del rullo sul quale si avvolge la tappa-rella e generalmente il comando è dato con un semplice deviatore che commutadirettamente la tensione di rete.

Riscaldamento/Raffrescamento

Con il termine “comfort ambientale” si definisce quella particolare condizionedi benessere determinata, in funzione delle percezioni sensoriali di un indivi-

36


duo in un ambiente, da temperatura, umidità dell’aria e livello di rumorosità eluminosità rilevati all’interno dello stesso: è quindi possibile distinguere tra be-nessere termo-igrometrico, benessere acustico e benessere luminoso. Il comfortambientale si identifica con il benessere psicofisico delle persone che vivono unambiente (casa, ufficio) ed è una sensazione dipendente da determinate condi-zioni che sono in gran parte pianificabili e quindi rientranti nella responsabilitàdel progettista (ad esempio nelle fasi di progettazione, realizzazione e gestio-ne di un “green building”). Il benessere termo-igrometrico (thermal comfortin inglese) è definito dall’American Society of Heating Ventilation and Air-conditioning Engineers (ASHRAE) come quel particolare stato della mente cheesprime soddisfazione con l’ambiente circostante.Le variabili ambientali da cui dipendono le condizioni climatiche esterne edinterne all’edificio e che influenzano il benessere termo-igrometrico sono:

• Temperatura dell’aria: si misura in °C o °F.

• Umidità relativa dell’aria interna: indica il rapporto tra la quantità divapore contenuto da una massa d’aria e la quantità massima che ne puòcontenere quella massa d’aria nelle stesse condizioni di temperatura epressione. Si misura, quindi, in percentuale (%).

• Temperatura media radiante: espressa in °C o °F, è la media delle tem-perature delle pareti interne all’ambiente, compresi soffitto e pavimento.

• Velocità dell’aria: espressa in m/s.

Temporizzazioni

In genere tutti i sistemi domotici consentono di attivare le funzioni previsteattraverso cosiddette “interfacce uomo macchina” (Human Machine Interface ininglese) più o meno convenzionali quali pulsanti, interruttori, pannelli touch-screen, telecomandi ecc... che sottintendono l’intervento manuale dell’utiliz-zatore. Una delle caratteristiche fondamentali di un sistema “intelligente” è

37


consentire il controllo anche senza la presenza fisica dell’utilizzatore: ad esem-pio accendere il riscaldamento o disattivare l’impianto d’irrigazione senza esserein casa oppure eseguire un’azione in momenti della giornata in cui si è impos-sibilitati ad attivarla manualmente (ad es. mentre si sta dormendo). In tuttiquesti casi, una gestione “a tempo” delle funzioni di sistema, risulta utile ai finidi ottenere in modo semplice un vero “comfort”.

Scenari

Un sistema domotico può essere usato per eseguire una singola azione, (adesempio accendere una lampada o impostare una temperatura) o per esegui-re automaticamente una sequenza ripetitiva di operazioni in diversi momentidella giornata o provvedere autonomamente ad attivare le funzioni conseguentiall’accadimento di un certo evento: questa “sequenza di operazioni” viene nor-malmente definita “scenario”. Ad esempio si potrà programmare uno scenario“buongiorno” contenente tutte le azioni che normalmente vengono eseguite al ri-sveglio mattutino (accensione luci, riscaldamento, disinserimento allarme, ecc.).Riguardo alle modalità di attivazione si possono distinguere:

• scenari in cui le operazioni sono programmate a tempo e devono essereeseguite in un determinato momento del giorno o di tutti i giorni;

• scenari in cui le operazioni vengono attivate dall’accadere di determinatieventi rilevati da sensori (di presenza, di temperatura ecc...);

• scenari in cui le operazioni vengono eseguite a seguito di un comandodell’utente sia “in locale” tramite pulsanti o terminali che “da remoto”tramite comunicatore GSM.

Un impianto domotico mette a disposizione una serie di funzioni innovative chenascono dall’integrazione di diversi sistemi; non si tratta dunque di migliorieapplicate ad un singolo dispositivo, ma funzionalità disponibili solo ed esclusi-vamente con la gestione efficiente e contemporanea di più sistemi. Un esempiosono i cosiddetti “scenari” domotici, cioè la possibilità di attivare in modo coordi-nato luci, attuazioni motorizzate, temporizzazioni, impianto di anti-intrusione,

38


di termoregolazione, di irrigazione ecc... con un unico comando manuale. Op-pure, in modo automatico, si può pensare di attivare uno scenario in base alleindicazioni date da un sensore di intensità luminosa, da un anemometro, da unigrometro ecc... o mediante la combinazione di comandi a pulsante oppure daun comando dato dal sistema anti-intrusione. Le possibili combinazione per gli“scenari” sono limitate solo dal numero e dal tipo di carichi comandati dall’im-pianto domotico, per cui è possibile personalizzare qualsiasi “scenario” domoticoin base alle esigenze dell’utente finale. Gli scenari possono essere attivati ancheda remoto per esempio attraverso un semplice SMS; allo stesso modo il sistemadomotico può inviare le informazioni riguardanti lo stato dell’impianto in temporeale, così da avere un controllo completo in qualsiasi situazione.

Videocitofonia

La citofonia, concepita in Italia nei primi anni ’60, costituì sin da subito un realemiglioramento della qualità della vita nelle abitazioni. Fino a quel momento,le chiamate si effettuavano con semplici pulsantiere ed un campanello internocostringendo il proprietario ad aprire la porta per poter verificare l’identità delvisitatore.Con l’avvento dell’elettronica, sono stati inseriti all’interno delle pulsantiere icosiddetti “gruppi fonici” (costituiti da microfono ed altoparlante) e sono staticreati i primi “derivati citofonici” con i quali poter effettuare, stando all’internodell’abitazione, la conversazione con il posto esterno.La successiva implementazione funzionale fu quella del comando per l’elettro-serratura al fine di agevolare l’accesso soprattutto negli stabili condominiali. Inultimo, la richiesta di avere un derivato citofonico in più stanze dell’abitazio-ne, consentì lo sviluppo della funzione di “intercomunicazione”. Ancora oggi, adistanza di decenni, le funzioni “base” di un impianto citofonico sono rimastesostanzialmente immutate.Negli anni ’80, l’avvento di telecamere e tubi catodici di dimensioni ridottee di costo contenuto, ha portato alla conseguente aggiunta nel posto esternodella telecamera stessa, ed alla realizzazione di derivati interni videocitofonici

39


(inizialmente viva-voce o parla-ascolta) con ulteriore miglioramento della sicu-rezza grazie alla possibilità di identificare correttamente il chiamante anche incondizioni di audio disturbato.

Irrigazione

L’irrigazione è l’insieme delle conoscenze tecniche finalizzate all’incremento dellaproduttività di un terreno e all’ottimizzazione dell’utilizzo dell’acqua ad essonecessaria. L’irrigazione può anche essere vista come fattore di incremento dellaqualità e tutela ambientale vista la rilevanza del “verde” nel paesaggio urbano.Il giardino o il parterre fiorito della piazza urbana risultano essenziali al livellodi gradimento: tanto maggiore è il valore estetico della componente verde diun’area tanto maggiore sarà il suo valore economico. Per mantenere il prato, lasiepe o l’aiuola fiorita al massimo del suo splendore è necessario irrigare tenendoconto che la scelta di una certa varietà botanica o tipologia colturale comporteràfabbisogni irrigui specifici: la piena consapevolezza di queste implicazioni èessenziale alla riuscita di un progetto. L’irrigazione può, essere vista anche comelimitatore dei costi di reimpianto contribuendo ad evitare nuovi investimenti almutare della stagionalità.

Controllo dei carichi e dei consumi elettrici

La funzione “controllo dei carichi” impedisce lo scatto dell’interruttore generaleper superamento dell’assorbimento massimo mediante la disinserzione preven-tiva di uno o più carichi elettrici controllati. Questa funzione è particolarmenteimportante nelle abitazioni che hanno contratti con il fornitore di energia elet-trica per potenze nominali molto inferiori al potenziale consumo di picco: adesempio difficilmente un boiler elettrico può funzionare contemporaneamentea frigo, congelatore e lavatrice senza che l’interruttore generale intervenga. Ingenerale il dimensionamento della potenza richiesta da un impianto elettrico sieffettua sommando le potenze richieste dai carichi elettrici più importanti intermini di consumo e moltiplicando tale somma per il “fattore di contempora-neità” (che normalmente oscilla fra 30% e 70%) il quale dipende dall’utilizzo

40


previsto: il “controllo carichi” permette di abbassare notevolmente questo “fat-tore di contemporaneità” e quindi consente di “risparmiare” la potenza richiestadall’impianto. In un mondo in cui i costi dell’energia sono in continua e co-stante crescita diventa essenziale avere un sistema che aiuti a evitare sprechiinutili senza inficiare il livello di benessere e comfort quotidiano. Al puro “con-trollo carichi” spesso vengono attribuite funzioni di “risparmio energetico” chenon possono essere soddisfatte a pieno da una semplice lista di priorità di di-sinserzione. La funzione che garantisce il vero e proprio risparmio energetico èil “controllo dei consumi”.

Sicurezza Antintrusione

La crescente diffusione della microcriminalità fa sì che la sicurezza antintrusionedebba essere, inclusa nelle funzionalità di “base” di un impianto domotico al finedi sorvegliare i propri beni ma di proteggere le persone. Anche in questo campo,l’evoluzione tecnologica ha reso possibile la realizzazione di sistemi di allarmesemplici nell’uso, adeguatamente affidabili e poco invasivi in termini “estetici”;si può facilmente prevedere che la disponibilità di microprocessori sempre piùpotenti che consentiranno l’adozione di software più raffinati e l’utilizzo di nuo-vi principi fisici nelle tecniche di rilevazione porteranno nei prossimi anni adulteriori significativi progressi. Ci sono molte scelte che si possono fare per as-sicurare la tranquillità e la sicurezza, una di queste è proteggere la propria casadai possibili furti, installando un impianto antifurto innovativo, affidabile e dialta qualità. Data la natura intrinseca della funzione svolta, il “sotto-sistema”di antintrusione non deve in nessun caso essere soggetto a “fuori servizio” e ilsuo funzionamento non deve essere in alcun modo impedito o parzialmente li-mitato da guasti o malfunzionamenti che dovessero occasionalmente verificarsinel resto dell’impianto (per esempio a seguito di un semplice black-out). Perquesto motivo e per l’ottemperanza alle specifiche norme di prodotto italia-ne ed europee, il “sotto-sistema” di antintrusione deve essere separato da unpunto di vista installativo: pertanto l’unità centrale del sotto-sistema svolge isuoi compiti specifici in modo autonomo e non influenzabile dal resto dell’im-

41


pianto domotico ed il “bus di comunicazione” è cablato separatamente con gliaccorgimenti “anti-manomissione” del caso per garantire il massimo livello disicurezza previsto dalle normative vigenti. Ma le precedenti ineludibili necessi-tà installative non debbono avere alcun impatto nella semplicità di utilizzo delsotto-sistema di antintrusione da parte dell’utilizzatore finale che anzi moltospesso è restio all’adozione di simili sistemi di protezione proprio a causa degliostici strumenti di interfaccia messi generalmente a disposizione.

Controllo da remoto

La maggior parte degli individui trascorre gran parte della giornata al di fuoridelle mura domestiche sia per impegni di lavoro che per attività di “tempolibero”. È quindi indispensabile che un sistema domotico sia dotato di strumentitramite i quali l’utilizzatore possa intervenire anche non essendo fisicamentepresente sull’impianto. La soluzione più semplice a questo tipo di esigenza,è dare la possibilità di interagire con la propria abitazione tramite i telefonicellulari su rete GSM.

Gestione efficiente delle risorse energetiche

Risparmio energetico significa risparmio economico: basta semplicemente predi-sporre un impiantistica in grado di ottimizzare l’utilizzo dei carichi per ridurrenotevolmente l’importo della bolletta sulla quale, in maniera non marginale,incidono gli sprechi dovuti a un utilizzo inefficiente degli impianti (luci dimen-ticate accese, riscaldamento continuo di stanze utilizzate raramente ecc...). Lagestione efficiente delle risorse energetiche mediante la Domotica permette an-che di evitare il superamento dei limiti contrattuali dell’erogazione dell’energiaelettrica e il conseguente black out: è possibile infatti fare in modo che gli elet-trodomestici funzionino consumando solo il livello di energia prestabilito perquella fascia oraria, eventualmente disattivando uno o più carichi secondo unapriorità assegnabile in base al tipo del carico, al giorno della settimana e all’oradel giorno. Infine non va mai dimenticato che risparmiare vuol dire anche rea-lizzare oggi lavori che, in futuro, si renderanno necessari per fruire di tecnologie

42


che presto potrebbero diventare alla portata di tutti. Predisporre oggi significaavere la consapevolezza che le necessità di chi usufruisci dell’abitazione varianonel tempo e che realizzare o adeguare gli impianti in futuro potrebbe essereimpossibile o diventare complicato e soprattutto molto costoso.

Protocolli principali

X-10

Il protocollo X-10, nato nel 1976, è lo standard storico della domotica. X-10 èbasato su una semplice architettura centralizzata, in cui un singolo dispositivodi controllo può controllare fino a 256 tipi di periferiche (è possibile assegnareuno stesso indirizzo a più periferiche per far eseguire a tutte gli stessi comandi).È inoltre possibile controllare i vari dispositivi sfruttando dei telecomandi aonde radio. Il dispositivo di controllo è gestibile anche mediante un personalcomputer. Per consentire la diffusione del protocollo sono state scelte comemezzo di comunicazione le power-line. Il protocollo è molto semplice e prevedeche a ogni periferica venga assegnato un indirizzo statico di 8 bit (i primi quattrotipicamente rappresentati da una lettera da A a P e i secondi quattro da unnumero da 1 a 16) a tempo di installazione. L’invio di un comando da parte delcontrollore o di un telecomando prevede l’invio in broadcast sul bus utilizzatodi 12 bit, i primi 8 rappresentanti l’indirizzo della periferica che deve eseguireil comando, e i restanti 4 rappresentanti il comando stesso. È evidente quindicome tramite X-10 sia possibile l’automazione solamente di semplici funzionalitàdomestiche. L’estrema semplicità e il basso costo di installazione e realizzazionedi prodotti compatibili hanno fatto sì che le aziende realizzassero molti prodottiidonei allo standard e quindi, ancora oggi, lo X-10 è molto diffuso.

BACnet

Lo sviluppo del Building Automation and Control Networking Protocol (BAC-net) è iniziato nel 1987 quando l’ASHRAE (American Society of Heating, Refri-gerating and Air-Conditioning Engineers) non riusciva a trovare un protocollo

43


adatto a soddisfare tutti i requisiti necessari per uno standard di comunicazio-ne di building automation. Lo sviluppo terminò nel 1995 quando BACnet fupubblicato come standard ANSI/ASHRAE e nel 2003 è stato adottato comesandard ISO e utilizzato in UE, Russia, Korea, Cina e Giappone [21].Prima dello sviluppo di BACnet, tutti i dispositivi di controllo erano connessitra loro attraverso protocolli proprietari. Ogni produttore aveva un suo proto-collo di comunicazione. Era così necessaria la creazione di reti diverse, una perogni produttore, con costi di integrazione particolarmente ingenti. Mettere incomunicazione dispositivi di produttori diversi diventava quindi un’operazioneonerosa.I messaggi BACnet possono essere veicolati su qualsiasi tipo di rete (Ethernet,ARCNET, Master-Salve/Token-Passing, LonTalk e Point-to-Point) ma il pro-tocollo IP è stato ritenuto particolarmente utile e quindi è stato formalizzatoil BACnet/IP. Quindi le reti IP sono supportate nativamente dallo strato direte di BACnet che permette ai propri dispositivi di comunicare direttamenteutilizzando IP anzichè sfruttare router per il tunneling.L’elemento base della topologia di rete BACnet è il segment. I segment possonoessere connessi tramite repeater e bridge per formare una rete. Le reti BAC-net (solitamente composte da mezzi di trasmissione differenti) sono connesse darouter per formare una internetwork ma solo un percorso può esistere tra duedispositivi qualsiasi di una internetwork. Un indirizzo consiste di 2-byte per ilnumero di rete e un indirizzo locale composto al massimo di 255 byte. L’indi-rizzo locale è specifico al metodo utilizzato per il collegamento, ad esempio, unindirizzo IP nel caso di BACnet/IP oppure un MAC address per una LAN.Le modifiche più recenti descrivono la possibilità di utilizzare XML e Web Ser-vice per l’integrazione di BAC con altri sistemi di gestione a livello enterprise(BACnet/WS). La figura 3.2 mostra un esempio di una configurazione con BAC-net/IP con l’utilizzo di un Web server per l’interfaccia grafica e Web service euna workstation che utilizza una applicazione client tradizionale.Il protocollo BACnet definisce un insieme di servizi per il discovery di device eobject. Sono definiti 25 tipi differenti di object. Ci sono semplici object come

44


Figura 3.2: Esempio di rete BACnet [21]

Analog Input e Output, Binary Input e Output, Multi-State input ma anchediversi object più complessi e l’object device stesso. Ogni BACnet object è unacollezione di data element che si riferistono a una particolare funzione. I sin-goli data element sono chiamate le property dell’object, ad esempio, un objectAnalog Input che fornisce la temperatura di una stanza avrà una property peril valore corrente e altre property per descriere il tipo di sensore, i valori minimoe massimo accettati, la risoluzione e l’unità con cui esprimere il valore. Ognidevice può avere zero, uno o più tipi di object fatta eccezione del device objectche deve essere presente in ogni device. Quindi ogni device a ogni livello dichiarale proprie grandezze e funzionalità ai dispositivi che ne fanno richiesta. Mentregli object forniscono una rappresentazione del device nel sistema di automa-zione i BACnet service forniscono messaggi per accedere e manipolare questeinformazioni. Le comunicazioni avvengono secondo un modello client/server esono definiti 40 servizi raggruppati in cinque categorie tra cui allarmi ed eventi.BACnet rappresenta attualmente la più completa astrazione di comunicazionetra dispositivi per la building automation.

45


KNX/Konnex

KNX è nato in seguito alla fondazione dell’associazione Konnex, avvenuta nelmaggio del 1999 da parte di EIBA (European Installation Bus Association), BCI(Batibus Club International) ed EHSA (European Home System Association)con lo scopo di realizzare e promuovere uno standard unico per applicazionidi Home e Building Automation. Konnex è l’evoluzione dello standard EIB(col quale rimane completamente compatibile) nato grazie all’aggiunta dellefunzionalità e il supporto ai mezzi di comunicazione degli standard BatiBuse EHS. Il nuovo standard KNX cerca di combinare i loro aspetti migliori percreare un unico standard Europeo per sistemi di Home & Building Automation[29, 21].Lo standard Konnex prevede l’utilizzo di alcuni mezzi trasmissivi che possonoessere combinati tra loro:

• cavo twistato in rame tramite di tipo TP-0 e TP-1: il primo di derivazioneBatiBUS che può raggiungere la bitrate di 4800 bit/s e il secondo derivatoda EIB che può raggiungere le velocità di trasmissione di 9600 bit/s.

• onde radio nella banda degli 868 MHz, frequenza interna alla banda ISM(Industrial Scientific Medical) con velocità di 16,38 kbit/s. I dispositiviKNX RF dialogano in maniera peer to peer.

• Power Line utilizzando la tecnologia PL-110 di derivazione EIB con velo-cità di 1200 bit/s e PL-132 di derivazione EHS con velocità di 2400 bit/sriferite a linee di potenza con 230 Vac e 50 Hz.

• infrarosso

• KNX può utilizzare anche connessioni ethernet mediante tunneling su reteIP. Lo standard utilizza il tunneling su frame IP per la gestione remotadi installazioni KNX e tramite tecniche di routing è possibile connetteretramite backbone diverse installazioni KNX.

La rete KNX è a logica distribuita e quindi non è presente un dispositivo cen-trale di decisione; ogni nodo possiede un indirizzo a 16 bit per cui è possibile

46


Figura 3.3: Topologia sistema KNX [21]

47


in teoria indirizzare fino a 65536 dispositivi. Sono ammesse tutte le possibilicombinazioni di topologie tra quelle a stella, ad albero e a bus, ma non quellaad anello. La rete è strutturata in line contenenti al massimo 256 dispositivi euna singola line può essere composta di un massimo di 4 segmenti che possonoraggiungere 1000 metri l’uno. Per concatenare i quattro segmenti possono esse-re utilizzati opportuni bridge (chiamati line repeater). L’insieme di 15 line puòessere raggruppata in quello che viene definita zone e una linea particolare chia-mata backbone line può raggruppare fino a 15 zone. Ne deriva una strutturagerarchica (vedi figura 3.3).Ad ogni nodo di una rete KNX viene assegnato un indirizzo univoco che corri-sponde alla sua posizione all’interno della struttura topologica della rete (zone/-line/device). Questo indirizzo viene utilizzato esclusivamente per comunicazionidi tipo unicast mentre viene utilizzato anche un indirizzamento di tipo multicastimplementato al livello due dello standard OSI (livello data link) dove ad ogninodo viene assegnato anche un ulteriore indirizzo di gruppo [29]. Gli indirizzidi gruppo seguono la seguente gerarchia a tre livelli:

1. gruppo principale o livello di sistema (es. illuminazione, termoregolazione,ecc.)

2. gruppo centrale per la funzione particolare del livello considerato (es. in-terruttore o dimmer per il livello di illuminazione, automazione tapparelle,ecc.)

3. sottogruppo per i dispositivi che eseguono la stessa funzione (es. lucesalotto, finestra bagno, ecc.)

I tre campi sono separati dal carattere slash (/) e possono essere assegnati apiacimento (gruppo principale/gruppo centrale/sottogruppo).Lo standard è completamente aperto e dispone di funzionalità Plug & Play e diun efficace metodo di correzione degli errori, allo scopo di assicurare un’alta af-fidabilità al sistema. Il sistema è inoltre in grado di autoconfigurarsi eliminandoautonomamente apparecchi non funzionanti o inserendone di nuovi.

48


Lo standard KNX prevede diversi metodi di configurazione: i principali sonola Easy-Mode e la System-Mode. La scelta del tipo di configurazione dipendedalla complessità dell’impianto e delle funzioni che si vogliono implementare. Idispositivi compatibili Easy-Mode sono già programmati con un set limitato difunzioni e se questa scelta da un lato limita le possibilità dall’altro semplificanotevolmente la messa in servizio dell’impianto [29, 25].Nella configurazione System-Mode tutti gli elementi della rete vengono con-figurati mediante l’ausilio di un unico tool software, denominato ETS (En-gineering Tool Software), che permette di definire la struttura dell’impianto.Ogni costruttore di dispositivi compatibili Konnex deve rendere disponibili gra-tuitamente il software per i propri dispositivi che un utente deve mantenereaggiornati e inseriti all’interno di ETS. Una volta terminata la progettazionedell’impianto il software scarica la logica di funzionamento nei dispositivi stessirendendo l’impianto funzionante in autonomia.

Lonworks

La tecnologia LonWorks, creata da Echelon Corporation, costituisce una piatta-forma completa, aperta e indipendente dal tipo di media scelto per la gestionedi dispositivi connessi in rete ed è stato progettato come sistema di control-lo event-triggered [25, 21]. Il protocollo di comunicazione utilizzato è il Lon-Talk (sviluppato dalla stessa Echelon Corporation), un protocollo aperto cheoffre una vasta quantità di funzionalità di controllo per l’automazione di casa,edifici e fabbriche che è stato pubblicato come standard formale denominatoANSI/EIA-709.L’implementazione del protocollo è stata realizzata su un singolo chip da Mo-torola e Toshiba, detto Neuron Chip. Per realizzare un sistema LonWorks mi-nimale sono sufficienti due Neuron Chips e un mezzo di comunicazione; questodimostra l’elevato interesse degli sviluppatori alla semplicità di installazione emanutenzione e al basso costo di installazione. Supporta una grande varie-tà di mezzi trasmissivi e diverse topologie di collegamento: sono inclusi i cavitwisted-pair, la power-line, fibra ottica e anche soluzioni a radio frequenza [21].

49


Figura 3.4: Schema di rete Lonworks [21]

Il protocollo di comunicazione LonTalk è indipendente dal mezzo trasmissivo el’intero spazio indirizzabile è chiamato domain. I domain sono suddivisi fino a255 subnet con un massimo di 127 nodi ognuna. Quindi è prevista la presenzadi un massimo di 32.385 periferiche all’interno di un unico domain. Una subnetcorrisponde a un singolo canale fisico sebbene la configurazione sia molto fles-sibile rendendo possibile collegare più canali fisici in una subnet tramite bridgeo repeater ma anche permettere che più subnet possano coesistere nello stessocanale fisico. Il routing tra differenti subnet è reso possibile da opportuni nodigateway (vedi figura 3.4). È possibile l’invio di messaggi in unicast, multicat obroadcast.L’architettura LonWorks fornisce anche un sistema per il collegamento tra larete LonTalk e la rete TCP/IP per la gestione delle periferiche da parte dipersonal computer. Ciò è garantito dal LNS (LonWorks Network Services), unsistema operativo che fornisce le API per l’installazione, la configurazione e ilmonitoraggio della rete domestica. LNS è basato su una parte server, realizzatasu un apposito dispositivo in grado di implementare sia il protocollo LonTalkche il protocollo TCP/IP e che funge da gateway per l’accesso alla rete domoticadall’esterno, e da una parte client realizzata tramite un software installabile su

50


ogni piattaforma (PC, MAC, UNIX, embedded, ecc.).

Confronto tra i vari sistemi in Italia

bTicino MyHome

Figura 3.5: Logo OpenWebNet

MyHome rappresenta forse il sistemapiù diffuso sul mercato italiano. Ba-sato sul protocollo proprietario SCSil sistema ha dei componenti che nonpossono comunicare nativamente conprodotti non appartenenti al sistemaMyHome. Per ovviare a questo limitenel tempo è stato introdotto il proto-collo aperto OpenWebNet attraversoil quale il sistema bTicino può comu-nicare con altri dispositivi attraversoun gateway [28].Il catalogo di prodotti MyHome è uno dei più completi, il che rende possibilerealizzare quasi tutte le funzionalità della home automation solo con prodottiMyHome. Inoltre grazie a OpenWebNet e l’attività di una community di svilup-patori indipendenti supportati da bTicino, il livello di integrabilità del sistema ècostantemente aumentato nel tempo. Risulta difficile comunque superare limitistrutturali di un sistema nato inizialmente chiuso: rispetto ad altre soluzionidomotiche l’integrabilità riesta comunque bassa.I prodotti MyHome non sono completamente programmabili dove, in realtà,la programmazione consiste nel selezionare uno tra i vari preset predefiniti difabbrica. La programmazione reale viene effettuata a livello di supervisione conil server scenari e il webserver. L’introduzione di questi dispositivi “program-mabili” ha migliorato notevolmente la flessibilità del sistema ma al prezzo diuna forte centralizzazione dell’intelligenza del sistema domotico. Più le funzio-

51


ni richieste dall’impianto sono evolute e complesse più l’impianto dipenderà dalserver scenari.

Konnex

Figura 3.6: Logo Konnex

Di filosofia completamente opposta ri-spetto a MyHome è il sistema Kon-nex [28]. È un sistema plurimarca(attualmente partecipano al consorziopiù di 300 produttori). Diverse azien-de adottano una lingua comune perconsentire ai propri dispositivi di dia-logare con quelli di altre aziende. Il

protocollo di comunicazione è aperto (il che non significa che sia gratuito), percui chiunque può sviluppare prodotti e software per il Konnex.Il konnex è nativamente integrabile in qualsiasi altro sistema domotico. È oggiuno degli standard per la domotica più diffusi al mondo, e di sicuro è lo standardaperto più diffuso in Europa, ragion per cui esistono interfacce per consentirel’integrazione con qualsiasi altro prodotto/sistema.L’affidabilità del Konnex è elevatissima. Anche qui parliamo di un sistemadomotico che ha diversi anni di onorata carriera. La programmazione dei com-ponenti Konnex, qualsiasi sia il produttore, viene eseguita con un tool unicoche si chiama ETS. Questo consente al system integrator di programmare unimpianto indipendentemente dai prodotti installati. La programmazione avvie-ne sempre nell’ambito di parametri definiti dal produttori, ma la flessibilità èelevata, anche perché molti dispositivi integrano funzioni logiche evolute, finoa veri e propri mini-PLC.L’espandibilità futura dell’impianto è assoluta. Un impianto può essere aumen-tato nelle funzioni e nelle dimensioni quasi senza limiti. Con il konnex si puòrealizzare un monolocale come un aeroporto. L’elevato numero di produttori el’intercambiabilità dei prodotti tra un’azienda e l’altra, rende abbastanza sicuridella disponibilità di ricambi e di supporto in futuro.

52


Vimar e Gewiss

Aziende che si sono inserite nel mercato successivamente, come le italiane Vimaro Gewiss, hanno provato ad adottare una terza via, che potremo definire inter-media, tra le due: l’easy-konnex [28]. Il konnex infatti è nato in due versioni,lo standard mode, quello di cui abbiamo parlato sopra e che si programma conETS, e l’easy mode, una versione semplificata in cui la programmazione dei di-spositivi avviene attraverso una centralina dedicata. Questa soluzione dovrebbeunire i vantaggi del protocollo aperto konnex con il minor costo di un sistemaproprietario come bTicino. Inoltre, non essendo necessaria la programmazionecon ETS, non c’é il costo a parte del programmatore.Entrambe le aziende citate, Gewiss e Vimar, hanno poi affiancato a questa li-nea di prodotti una più ristretta gamma di prodotti in Konnex “puro”. L’idea èquella di poter realizzare un impianto domotico a minor costo, che possa esserepoi “upgradato” in un sistema konnex completo. Sembrerebbe la quadraturadel cerchio, ma l’upgrade non è del tutto scontato anche perchè al momentodi realizzarlo sarà necessario riprogrammare in ETS anche i componenti ini-zialmente programmati in easy mode. Inoltre contemporaneamente i prezzi deicomponenti Konnex standard scendono, e i sistemi easy sentono la concorrenzadei loro cugini evoluti.

Net Building Automation HomePLC.

Figura 3.7: Logo NetBA

I PLC sono stati utilizzati nei piùsvariati settori, tra cui quelli prin-cipali delle macchine, del terziario enell’Industriale.Sviluppato inizialmente per sostitui-re grandi quantità di relè e cablaggi,si è evoluto poi con varie tipologie diinterfacce, riducendo progressivamen-te le dimensioni. Negli ultimi anni ilconcetto di PLC si è evoluto notevol-

53


mente occupando la stragrande maggioranza di settori dell’automazione e laconsueta forma che lo contraddistingueva si è in parte modificata secondo lenecessità e i settori d’impiego.L’unico settore di produzione che ancora non aveva recepito appieno l’uso diPLC era la Domotica e per questo si è pensato di sviluppare HomePLC ovveroil primo PLC Domotico con caratteristiche tecnico/costruttive specifiche per ilsettore Domotico.Lo strumento utilizzato per definire la logica di funzionamento di HomePLC èLadderHOME che è un programma per lo sviluppo di Applicazioni Domotichee non. LadderHOME è differrente dagli altri sistemi di programmazione perhardware domotici perchè utilizza nativamente linguaggi grafici conformi allasimbologia EN CEI/IEC-61131-3.Questo significa che sarà possibile utilizzare LadderHOME con una minimaesperienza di schemi elettrici in quanto utilizza la terminologia, icone e concet-ti familiari ad elettrotecnici e tecnici di settore: simboli grafici piuttosto chelinguaggi testuali per descrivere azioni di programmazione.I programmi sviluppati con LadderHOME sono denominati Ladder Diagram eil loro aspetto e funzioni simulano i circuiti elettrici. Tuttavia, sono analoghialle funzioni presenti nei convenzionali linguaggi di programmazione testuali.Ognuno dei possibili elementi della libreria di componenti rappresenta un mo-dulo del programma. Quando l’utente seleziona ed inserisce un nuovo coponentenell’attuale layout del progetto, connettendolo per mezzo di linee al circuito, au-tomaticamente effettua un link fra i moduli di programma correlati al progettoche sta sviluppando.Durante la fase di compilazione il LD viene tradotto in un programma compa-tibile con HomePLC, adatto quindi ad essere inviato e memorizzato su questoPLC Domotico.Nella logica a LADDER il programmatore accede direttamente a questa zonadi memoria specificando, in formato IEC, l’indirizzo in cui è presente il datoda leggere o da modificare. In questo modo è lasciato completamente al pro-grammatore verificare la correttezza di tale indirizzo che può essere desunto

54

3.3 IoT e Smart Home

da una opportuna tabella che mette in corrispondenza l’indirizzamento logicodei device con l’indirizzamento in standard IEC. Il programma, inoltre, vieneeseguito in maniera sequenziale da sinistra verso destra, dall’alto verso il basso,rendendo necessaria un certa pratica per evitare comportamenti anomali nelleattuazioni in quanto potrei inizialmente attivare una uscita e, successivamente,disattivarla inavvertitamente.L’utilizzo dei linguaggi dello standard IEC-EN 61131-3 rende sicuramente possi-bile l’approccio alla domotica da parte di professionisti che non hanno conoscen-ze relative allo sviluppo di software anche se purtroppo risulta carente rispettoal trend attuale di integrazione e interazione tra sistemi diversi e altamenteconnessi.L’uscita del controllore HomePLC.Linux ha consentito al fornitore dei dispositi-vi di aprirsi a un pubblico diverso da quello normalmente servito. Ovviamentenon stiamo parlando di utilizzatore finale del prodotto ma di una figura in-termedia che ha intenzione di realizzare il proprio sistema domotico sia perragioni personali sia nella speranza di realizzare un prodotto destinato allacommercializzazione.


Come abbiamo visto ci sono molti sistemi di Home Automation e standardaffermati ma fino ad oggi hanno riguardato singole aziende che hanno prodottotecnologie proprietarie e tra loro incompatibili. E questo ha inevitabilmenteportato ad atteggiamenti spesso protettivi (riguardo alle proprie tecnologie) odi chiusura (rispetto ad altri sistemi) e prezzi piuttosto alti.La nuova generazione di sistemi, spinti da una integrazione e una capacità dicalcolo sempre più elevata e dalle possibilità create da una connettività semprepiù estesa offre, punta sul connettere qualsiasi cosa, a “tutto il resto”, nellamaniera più semplice e più economica possibile.Questi nuovi sistemi per la Smart Home spesso richiedono un dispositivo chelavori come hub sebbene alcuni siano esclusivamente software. Questi hub so-

55


litamente sono nella forma di piccole scatole al cui interno sono implementatidiversi apparati radio che trasmettono a specifiche frequenze utilizzando va-ri protocolli oppure connettori per ulteriori standard in modo da connettereulteriori dispositivi. Includono tra possibili nuovi standard: Zigbee, Z-wave,Bluetooth, Bluetooth Low Energy, WiFi e molti altri.Gli approcci di questi nuovi sistemi si possono riassumere in due categorie. Daun lato chi realizza un tale sistema tenta di incorpare il più possibile dispositividi altri produttori sfruttando i loro protocolli di connessione (se aperti) oppureutilizzando protocolli web ed eventuali gateway nel caso di protocolli proprietari.Dall’altro grandi nomi dell’ICT tentano di realizzare una propria infrastrutturae nuovi protocolli che altri produttori saranno obbligati ad utilizzare per inte-grare i loro dispositivi nella speranza di maggior visibilità garantita di grossinomi come Apple e Google e dal fatto che già un grosso pubblico utilizza i loroprodotti.Tra tutti i produttori Apple ha fissato i propri criteri per come la Smart HomeAutomation dovrebbe lavorare spesso vincolando chi desidera far parte del lorosistema. Apple HomeKit richiede che i dispositivi lavorino esclusivamente conBluetooth o Wi-Fi tralasciando gli altri protocolli ma richiede anche forti requi-siti di cifratura (per fornire un ambiente sicuro) e particolari requisiti hardware(specialmente per ottenere la sua certificazione).HomeKit di Apple e Brillo di Google sono piattaforme nuove e l’idea di fondo èquella di acquistare un certo numero di dispositivi compatibili, aggiungerli allapropria rete e controllarli con il proprio smartphone.Per entrambi sarà possibile anche includere dispositivi non supportati diretta-mente utilizzando dei bridge, che si occuperanno di tradurre tra HomeKit/Brilloe dispositivi non compatibili.Gli Hub sono invece elementi essenziali per aziende come Wink o SmartThingsdi Samsung dato che il loro scopo è quello di incorpare dispositivi differenti cheutilizzano standard differenti.

Apple HomeKit

56


Figura 3.8: Logo di Apple HomeKit

“HomeKit Securely control your ho-me. Right from the palm of yourhand.” è lo slogan presente allapagina di riferimento di Apple1.HomeKit è un framework che permet-te di mettere in comunicazione e con-trollare accessori per la Home Auto-mation che supportano il protocolloHomeKit Accessory e i dispositivi iOSdi Apple. Lo scopo è di promuove-re un protocollo comune per i dispositivi della home automation e delle APIpubbliche per configurare e comunicare con questi dispositivi.Lo scopo di HomeKit è quello di mettere in comunicazione tutti i vari dispositivitramite una unica interfaccia oppure per impostarli in modo che eseguano azioniassieme in certi orari o al verificarsi di particolari eventi. Senza HomeKit ilcontrollo di questi dispositivi avverrebbe con app individuali e a lungo andarela cosa diventerebbe abbastanza scomoda.I costruttori possono implementare HomeKit all’interno dei loro prodotti ren-dendoli facili da controllare (anche tramite Siri), garantendone lo scambio didati in modo sicuro e in grado di lavorare con iPhone e iPad.HomeKit permette ad app sviluppate da terze parti di compiere tre funzioniprincipali:

1. Rilevare accessori e aggiungerli a un db denominato cross-device homeconfiguration database

2. Visualizzare, modificare e eseguire azioni sui dati presenti nel db

3. Comunicare con gli accessori e i servizi per eseguire comandi

L’home configuration database è utilizzato anche da Siri che permette di riceverecomandi vocali da parte degli utenti. Se gli utenti creano configurazioni rag-

1www.apple.com/ios/homekit

57


gruppando logicamente accessori, servizi e comandi Siri è in grado di eseguiresofisticate operazioni tramite controllo vocale.Se non si vuole utilizzare continuamente i comandi vocali di Siri è possibileimpostare gli Accessory per rispondere ad altri trigger come la propria posizione,il tempo o un altro Accessory. Così, nel caso della posizione, puoi impostare chequando viene aperta la porta del garage si accenda la luce all’interno ma soloper dati orari. Se si vuole accedere ad una interfaccia touch invece ci si deveancora affidare alle app individuali di ogni singolo dispositivo e per accederealle loro funzionalità complete.HomeKit vede una casa come una collezione di accessori per la home automa-tion e le informazioni vengono organizzate in modo gerarchico definendo Home,Room, Accessory, Service e Zone. Le Home possono essere opzionalmente par-tizionate tramite Room e Zone mentre gli Accessory vengono assegnati alleRoom. Un singolo Accessory può permenttere il controllo di più Service daparte dell’utente; ad esempio il dispositivo per l’apertura della porta del garagepuò avere un servizio per aprire e chiudere la porta ma anche un servizio pergestire la luce del dispositivo di apertura.Diversamente da altre piattaforme Apple non offre un dispositivo che svolge ilruolo di hub centrale ma basa il proprio ecosistema sul fatto che l’utente abbiagià un dispositivo basato su iOS. Si potrebbe pensare che il proprio dispositivoiOS diventi l’hub centrale per HomeKit. Sono state create specifiche con lequali i dispositivi possono comunicare gli uni con gli altri e HomeKit è il filoconduttore che lega tutti questi dispositivi assieme2.Inizialmente era possibile accedere al proprio sistema di Home Automation daremoto solo se si aveva a disposizione una Apple TV (almeno di terza generazio-ne) ma è possibile controllare gli Accessory anche con l’Apple Watch. Ora Appleoffre anche un HomeKit “Cloud” e in questo caso i dispositivi Wi-Fi possonolavorare anche se il proprio smartphone non è presente. iCloud già salva oggetticome i contatti, documenti e altri dati e la stessa cosa può avvenire mantenendoun database localmente che conserva tutti i dati HomeKit. Cove questi davi

2http://www.pocket-lint.com/news/129922-apple-homekit-explained-is-it-available-yet-and-how-does-it-work

58


vengono modificati lo smartphone li sincronizza con iCloud così che, in ognimomento, tutti i propri dispositivi abbiano le stesse informazioni degli altri.Tutti i dispositivi iOS accoppiati allo stesso account iCloud vedranno gli stessidati HomeKit e avranno la stessa abilità di controllare gli stessi dispositivi.Riguardo la sicurezza HomeKit obbliga alla cifratura end-to-end tra gli SmartAccessory e i dispositivi iOS e ad ogni sessione di lavoro viene utilizzata unachiave diversa di cifratura. In questo modo risulta particolarmente difficilerubare informazioni, inserirsi nelle comunicazioni e prendere il controllo dellapropria home automation.Realizzare un prodotto compatibile con HomeKit Apple richiede ai produttori disottoscrivere l’MFI Program per poter accedere alle risorse dedicate a chi vuoleintegrare la tecnologia HomeKit per il proprio hardware. Assieme alle specifichetecniche viene ricevuto il logo MFi e il diritto ad apporlo sulle proprie confezionie un supporto tecnico dedicato all’hardware.HomeKit è stato presentato inizialmente alla Worldwide Developers Conferen-ce (WWDC) nel 2014 ma con il rilascio degli aggiornamenti del sistema iOSvengono introdotte sempre nuove funzionalità che ne fanno quindi un sistemasempre in evoluzione.

Google Brillo e Weave

Nel 2014, al tempo in cui Apple presentò HomeKit, Google annunciò un pro-gramma di sviluppo per la divisione Nest. Era chiamato “Works with Nest” eforniva un set di API che i produttori potevano includere nei loro smart devicein modo da poterli collegare e integrare con Nest e altri prodotti Google.Come affermato da Todd Henderson3 Brillo è un nuovo sistema operativo basatosu Android utilizzato per lo sviluppo di sistemi embedded - in particolare perla IoT e per dispositivi low-power come anche dispositivi quali Raspberry Pi oIntel Edison.

3https://www.getstructure.io/blog/everything-i-learned-about-googles-brillo-and-weave-at-ubiquity-dev-summit

59


Local APIs

Cloud APIs

Figura 3.9: Weave API

Brillo attualmente utilizza esclusivamente c/c++ per lo sviluppo ma supporteràaltri linguaggi in futuro e, anche per Google, la sicurezza viene riconosciuta comepriorità per le applicazioni orientate alla IoT. Una particolarità interessante è lapossibilità di ottenere aggiornamenti OTA senza che sia necessario un accountGoogle.Mentre Brillo è un sistema operativo Google Weave è una piattaforma di comu-nicazione tra dispositivi basata su JSON e comprende anche servizi cloud perprovisioning, discovery, authentication, ecc.E’ da notare che il protocollo proprietario Weave di Nest è una cosa differenterispetto a quello di Google ma sicuramente questo inizialmente ha causato qual-che confusione. Ad ogni modo le due teconologie sono compatibili e condividonogli stessi obiettivi: semplicemente lo fanno in modi differenti.In un articolo su Forbes4 viene dettagliato che Brillo è una piattaforma IoTformata da tre elementi: un Embedded OS basato su Android, una piattaformaper servizi di base e un kit di sviluppo. Brillo può essere compilato dai sor-genti per architetture ARM, Intel e MIPS. Il sistema operativo può avviarsi sudispositivi con almeno 64 MByte di storage e 32 MByte di RAM e Google sta

4http://www.forbes.com/sites/janakirammsv/2015/10/29/google-brillo-vs-apple-homekit-the-battleground-shifts-to-iot/

60


Hardware Abstraction Layer

Linux Kernel

Bootloader

Runtime

Application Framework

Native Services

Core Application

Figura 3.10: Brillo stack

lavorando con i partner per certificare le schede compatibili con Brillo: saran-no schede verificate e testate per lavorare con le versioni correnti e future delsistema operativo.I servizi principali della piattaforma includono Weave che permette ai dispo-sitivi di connettersi in sicurezza alla rete. I dispositivi che utilizzano Weavepossono scambiare dati tra loro. Il componente Metrics fa parte dei servizi dibase e colleziona i dati di utilizzo del dispositivo in base ai permessi impostatidall’utente.Ogni dispositivo che utilizza Weave è automaticamente connesso ai servizi cloude i dispositivi che non appartengono alla stessa rete utilizzano il cloud percomunicare con tuti gli altri. Non è ancora chiaro se Weave sarà in grado dilavorare con gli standard già esistenti come BACNet, Bluetooth Low Energy,ZigBee, and Z-Wave.Come esposto al DevFest MN 20165 da Dave Smith nello stack software diBrillo tutto ciò che era legato a Java nell’Android stack non c’è più. Nientepiù Application Framework e Core Applications e anche nei Native Services

5https://www.youtube.com/watch?v=ig9GKAFzDxQ

61


parte degli elementi sono stati rimossi: elementi necessari per supportare ilJava Framework. Android non è l’unica piattaforma inclusa in Brillo: c’è ancheparte del codice di Chrome OS all’interno del pacchetto Native Services in mododa fornire alcuni servizi per la connettività e altri elementi che le applicazionipossono utilizzare per lavorare in quanto non dipendono dal Java Runtime.Anche gran parte del Bootloader è stato preso da Chrome OS.Weave è un protocollo di comunicazione tra device e non è specifico per Brilloed è stato pensato per essere implementato su un vasto numero di device; Brillocomunque ha Weave al suo interno di default. Weave fornisce alcuni mobile sdkche permettono Android, iOS e Web Device di interagire con embedded device,fornisce apposite librerie per embedded device (di cui quelle incluse con Brillosono una possibilità - ma non l’unica) e fornisce uno strato di servizi Cloud perconnettere dispositivi remoti a dispositivi locali. Queste librerie consentono chetutto accada automaticamente e nella maniera più sicura e sono disposibili siaper le Cloud API che per le Local API.Per quanto riguarda i dispositivi Weave è disponibile in due versioni: libweavedisponibile per dispositivi MMU-Enabled, cioè processori o SoC (system onchip) in grado di supportare Linux (con presenza di Brillo o meno) e libuweaveper dispositivi pensati direttamente per la Iot in cui Linux non può essereinstallato o per microcontroller tipo Cortex o altro. Queste librerie sono giàdisponibili e anche se non si vuole partecipare al programma ufficiale di supporto(ad invito) sono completamente opensource e liberamente scaricabili per fare ipropri esperimenti6.Quando viene realizzato un dispositivo che utilizza Weave è necessario che vengadefinito uno schema di quello che lo stato del dispositivo rappresenta, dichiararei comandi accettati e gli stati in cui può trovarsi un dispositivo: per i pulsantilo stato può essere ON e OFF, oppure ON, OFF e Brightness per le lampadine.Lo schema di un dispositivo può essere utilizzato da altri dispositivi per scoprirele funzionalità del primo.Weave automaticamente si preoccupa che lo stato di un dispositivo sia sincro-

6https://weave.googlesource.com/

62


nizzato e propagato a tuti gli altri dispositivi connessi e il concetto è che i varidispositivi possono registrarsi gli uni con gli altri.Brillo fornisce, oltre a Weave, altri servizi ereditati da Chrome OS come Metrics& Crash Report che fornisce informazioni sui dispositivi che sono stati posizio-nati in campo, quale versione del firmware hanno e quali comandi gli ha inviatol’utente. Inoltre restituisce informazioni sullo stato di salute dei dispositivi inmodo da poterli riparare o controllare per primi se c’è qualcosa che non va. Idati possono essere visualizzati e analizzati nella console per capire i pattern diutilizzo. Possono anche essere analizzati i crash report per effettuare il debugdei dispositivi impiegati sul campo.OTA è un altro servizio di Brillo che consente di preparare una nuova immagine,postarla sulla Google Developer Console e automaticamente di essere propagataa tutti i dispositivi connessi. Anche questa funzione è stata ereditata da ChromeOS e la procedura di update avviene in background senza arrestare il serviziodel dispositivo. Per evitare che il dispositivo si blocchi nella fase di installazionee riavvio viene sfruttata la struttura del bootloader di Chrome OS che possiededue porzioni parallele del sistema in esecuzione nello stesso momento e mentreuna sta eseguendo il suo compito la seconda è disponibile sulla quale si puòapplicare un aggiornamento. Quando l’update è pronto per essere mandato inesecuzione l’unica cosa che rimane da fare è il reboot del dispositivo e il tempodi disservizio del dispositivo è ridotto al minimo. Inoltre è l’utente che puòscegliere quando è più opportuno applicare l’update.Per quanto riguarda la sicurezza Google ha fatto notevoli sforzi per applicarlaa tutti i livelli. Su Brillo sono presenti elementi come sandboxing e processisolation che gli sviluppatori già utilizzano quando sviluppano app per Androide quindi tutte le separazioni per i processi utilizzate per evitare che un processopossa causare problemi all’intero sistema. E’ presente anche un meccanismonel bootloader che assicura che le immagini scaricate siano firmate in modoopportuno e che non possano essere state manomesse; in questo modo se qualcheproblema viene rilevato il sistema semplicemente non lo carica in memoria mariavvia la vecchia versione del firmware. E nella developer console è possibile

63


essere avvisati di quanto è accaduto per risolvere nel modo opportuno i variproblemi.La sicurezza è presente anche ai livelli di comunicazione così che quando houn dispositivo abilitato da Weave l’accesso a tale dispositivo è gestito da unaccount Google così che tutti i meccanismi di sicurezza forniti da Google sianopresenti ed è fornito un maggior controllo su chi può vedere lo stato, chi puòaggiornarlo, ecc. Inoltre tutto il traffico dati che viene inviato tra due devicee tra device e cloud è criptato su TLS e anche i dati che sono presenti su undispositivo o sul Cloud sono criptati.Google ha presentato Brillo e Weave al Google I/O nel giugno del 2015.

Samsung SmartThings e gli altri

Mentre Apple e Google pensano di attirare produttori di oggetti per la IoT conun proprio protocollo di comunicazione e con servizi per abilitare e integraredispositivi di terzi nel loro ecosistema Samsung e altri produttori hanno sceltouna strada differente.La scelta è stata quella di realizzare un hub centrale e connesso alla propria retedomestica in grado di sfruttare tanti protocolli di comunicazione differenti alloscopo di integrare quanti più dispositivi per la IoT possibili.Samsung da un lato ha un grosso potenziale in quanto azienda costruttrice dimolti dispositivi domestici: dalle lavatrici ai condizionatori, da prodotti perla cucina a prodotti per l’intrattenimento, ecc. SmartThings oltre a diversidispositivi della stessa serie riesce ad integrare prodotti di altre marche qualiHoneywell, Osram, D-Link, Yale e altri dedicati ai compiti più disparati.Wink ha a catalogo un crescente numero di dispositivi di marche molto conosciu-te quali Philips per l’illuminazione, Nest per videosorveglianza e riscaldamento,Lutron come controller per l’illuminazione, Honeywell, Ecobee, Amazon e moltialtri.Mentre SmartThing richiede di connettere il proprio Hub con un cavo di rete alproprio router, Wink utilizza il WiFi. Wink per funzionare richiede che la con-nessione internet sia funzionante in quanto l’hub risulterebbe non raggiungibile

64


dallo smartphone: infatti entrambi si mettono in comunicazione passando tra-mite il Wink cloud service. Samsung invece, con la seconda versione del propriohub, permette di effettuare alcune automazioni anche in assenza di connessioneinternet con il vantaggio di migliorare le performace e ridurre i tempi di latenza.Ovviamente in questo caso è precluso l’accesso da remoto.Wink supporta Bluetooth LE, Wi-Fi, ZigBee, Z-Wave, Lutron ClearConnecte Kidde e, come indicato sul loro sito, a parte la comprensibile comodità deiprimi, ClearConnect e Kidde vengono utilizzati in quanto partner del sistemaWink e anche perchè (sempre per quanto scritto sul sito) creano dei buoni pro-dotti. L’app per Android e iOS viene utilizzata per controllare tutti gli oggetticonnessi all’hub quindi se la connessione ad internet viene interrotta l’unicomodo per accedere ai dispositivi è manualmente oppure via l’app proprietaria(se presente).Samsung supporta ZigBee e Z-Wave e in futuro potrebbe integrare anche ilprotocollo Bluetooth. Nel caso venga meno l’alimentazione l’hub v2 ha a di-sposizione anche 4 batterie del tipo AA che garantiscono un pò di autonomia(anche fino a 10 ore).

Eclipse SmartHome framework

Eclipse SmartHome non è un prodotto finito ma un framework su cui costruiresoluzioni per l’utente finale. Ad ogni modo sono presenti già delle soluzioni giàpronte basate su questo framework come openHAB (che ne è la release ufficiale)e altre.Il motivo di esistere per SmartHome può essere ricercato nella necessità di unapiattaforma che permetta l’integrazione di differenti sistemi, protocolli o stan-dard e che fornisca una interfaccia uniforme per l’utente e servizi di alto livello.Il progetto è stato pensato per essere utilizzato su ogni tipo di sistema che siain grado di eseguire uno stack OSGi: sia un server multi-core, un residentialgateway o anche un Raspberry Pi.Inizialmente fu creato openHAB (dopo una serie di tentativi) realizzato da Kai

65


Figura 3.11: Architettura di Eclipse SmartHome

Kreuzer7, un software Architect and Home Automation Professional così comeindicato nel suo blog. Nel luglio del 2007 si innamora di OSGi e dopo qualcheesperimento con MisterHouse (un software opensource focalizzato su tecnologiaKNX) nel novembre del 2009 pensa di realizzare SmartKNX un sistema dalui descritto “so modular and extensible that any other domostics standard canbe supported as well”. Nel febbraio del 2010 finalmente nasce openHAB. Ilnome del progetto iniziale fu cambiato probabilmente per evitare violazionisul copyright di altri software. Da allora il sistema è cresciuto e ampliatoda una nutrita comunità di utenti e sviluppatori. Nel giugno del 2014 Kaidecide di cedere il core Framework di openHAB alla Eclipse Foundation chedarà vita al progetto Eclipse SmartHome. SmartHome è un progetto che faparte di un ecosistema più ampio dedicato alla IoT che comprende frameworke protocolli, tutti rigorosamente opensource. L’idea alla base di questo nuovoprogetto è permettere a chi sia interessato di realizzare la propria soluzionedomotica partendo da componenti software già disponibili e fornendo anche

7http://kaikreuzer.blogspot.it/

66


un quadro chiaro sugli aspetti legali che l’utilizzo di software di terze partiimplica. Attualmente la prima versione di openHAB è arrivata alla release1.8.x che si prevede sia l’ultima della sua serie mentre è in sviluppo la versione2, attualmente giunta alla fase di beta release, che introduce alcune novità emigliorie.La filosofia dietro al progetto openHAB/SmartHome nasce dalla constatazioneche esistono già sul mercato molte soluzioni di home automation e dispositiviper l’Internet of Things e che tutte hanno sicuramente una loro utilità presesingolarmente. Tutti i sistemi di automazione e i dispositivi per la IoT hannoun proprio modo di installazione e configurazione e sono ben progettate pergli usi per i quali sono state pensate ma il problema è che spesso un utentevorrebbe utilizzare questi dispositivi in un modo totalmente nuovo sfruttandol’interazione con sistemi differenti che non era stato previsto inizialmente dalcostruttore. Qui entra in gioco SmartHome che viene concepito come punto diintegrazione permettendo ai vari sistemi di dialogare l’uno con l’altro superandoi confini imposti da costruttori o protocolli.Gli elementi principali su cui si basa il framework SmartHome8 sono le Thing,gli Item e i Channel.SmartHome definisce Thing come quelle entità che fisicamente aggiunte al si-stema possono potenzialmente fornire nuove funzionalità. Le Thing non devonoessere per forza dispositivi ma anche web service o qualsiasi altra sorgente diinformazioni e funzionalità. Bridge è un tipo particolare di Thing che è neces-saria quando è richiesto che l’entità permetta l’accesso ad altre Thing connessead essa. Un esempio tipico è un IP gateway per un sistema di automazione cheinternamente non è basato su IP ma su protocollo proprietario.Diversi invece sono gli Item, entità dotate di stato che rappresentano funziona-lità usate all’interno dell’applicazione (generalmente per popolare le interfacce ela logica di attuazione) e, dato il loro ruolo, possono ricevere update e generareeventi.Tra le Thing e gli Item ci sono i Channel che rappresentano le funzionalità

8http://www.eclipse.org/smarthome/documentation/index.html

67


fornite dalle Thing e connesse agli Item. I Channel, che vengono percorsi daglieventi del sistema di automazione, rappresentano il collante tra il livello fisico,rappresentato dalle Thing, e il livello virtuale dove risiedono gli Item.Il cuore del framework SmartHome è formato da un event bus per la comunica-zione tra i componenti. Gli eventi, che vengono veicolati all’interno dell’eventbus, possono essere inviati e ricevuti in maniera asincrona e sono raggruppati indiverse categorie: Core Event, Item Event, Thing Event e altri secondo a qualeentità si riferisce l’evento. Queste categorie di eventi sono tutte osservabili inmodo da poter generare comportamenti e scenari anche molto complessi.

Considerazioni

Uno dei pericoli maggiori con queste nuove tecnologie è quello di rimanere legatie spesso abbracciare un particolare standard significa rimanere vincolati adesso per sempre; è poco probabile che Apple investa nello sforzo di renderecompatibili standard di altre ditte con HomeKit - ad esempio lasciando chealtri dispositivi si possano connettere tramite WiFi, citando possibili problemidi sicurezza. Questo sicuramente manterrà intatta la visione di Apple ma èprobabile che manterrà alti i prezzi e limiterà le possibili scelte.C’è anche da considerare la privacy. Apple ha un forti politiche orientate allaprivacy dei propri utenti ma Google ha basato il proprio business sul data miningmentre su altri produttori non ci sono molte informazioni su questi aspetti.Inoltre molto spesso occorre necessariamente connettere il proprio ecosistemaad internet, aspetto che non libera questi nuovi prodotti da possibili attacchi,e più dispositivi sono connessi e più punti da difendere ci saranno.Un vantaggio dei sistemi di Apple e di Google è quello riservato a chi ha inten-zione di creare un nuovo dispositivo o un nuovo software per le loro piattaforme.Si tratta di documentazione e linee guida ben realizzate e molto spesso di par-ti intere di codice a disposizione da prendere come spunto e che consente diridurre, e non di poco, il tempo necessario a rilasciare un nuovo prodotto.Eclipse SmartHome è un sistema software e quindi non comprende la necessitàdi sottoscrivere contratti per la realizzazione di prodotti compatibili. Dato che

68


chiunque può realizzare un componente per integrare sistemi di altri produttoric’è sempre il rischio che l’utilizzo di parti di codice siano sotto vincoli di brevetto.Per ridurre questi rischi si è reso necessario avere una rigida gestione dellaproprietà intellettuale e una guida molto chiara per i chi volesse contribuire coni propri progetti. La documentazione è estesa e la generazione degli artefatti edegli scheletri per i nuovi binding è automatizzata. L’ambiente di sviluppo nonpoteva che essere quello di Eclipse.Nel prossimo capitolo verrà mostrato come è stato possibile integrare più si-stemi attraverso l’implementazione ufficiale di Eclipse SmartHome, chiamataopenHAB, e il progetto di una libreria di integrazione per un sistema domoticocommerciale. Verranno esposti i passi principali che sono stati necessari perarrivare a un prodotto utilizzato realmente in ambito domestico.

69

4 Caso di Studio

Come è stato scritto più volte l’Home Automation fa parte dell’ecosistema IoTe il caso di studio riguarda proprio la costruzione di un sistema di HA apertoe non proprietario. Con aperto si vuole intendere la possibilità nel futuro dipoter espandere il sistema integrando nuove tecnologie e dispositivi in gradodi aggiungere funzionalità, mentre con non proprietario si vuole evitare il piùpossibile di legarsi a protocolli o sistemi ai quali non si possa all’occorrenzaapportare modifiche; proprio per non rimanere vincolati ad una particolaretecnologia.L’utilizzo di framework e protocolli opensource ha permesso di ridurre il tempodi sviluppo di una soluzione software in grado di controllare l’intera abitazionema soprattutto di risparmiare sui costi di acquisto in prodotti di aziende ingrado di fornire le stesse funzionalità. Non tutti i sistemi domotici hanno acatalogo prodotti che lasciano all’utente la possibilità di intervenire sulla logi-ca di controllo limitando di fatto a una semplice configurazione dei dispositivil’operazione finale dell’installazione. Men che meno hanno la fornitura di undispositivo programmabile con linguaggi di alto livello e in grado di persona-lizzare fino nel minimo dettaglio il controllo dell’intero sistema di automazio-ne. Spesso viene fornito un dispositivo che posizionato a bordo del sistemane espone in parte la programmabilità trasformando il protocollo proprietariodi comunicazione interno in uno esterno di tipo aperto; si tratta generalmentedi gateway che forniscono un accesso tramite rete ethernet e protocolli web alsistema domotico.Come vedremo un dispositivo completamente programmabile ma privo di qual-siasi logica di funzionamento preinstallata richiede che uno sviluppatore debba

71

4 Caso di Studio

progettare e costruire tutti i meccanismi e i servizi di base in grado di rilevareil verificarsi di un particolare evento all’interno del sistema; una volta acquisitol’evento è possibile applicare la logica di controllo che poi porterà a opportuneattuazioni nei dispositivi in campo.Programmare una logica di controllo con linguaggi di alto livello, sebbene per-metta una personalizzazione completa del comportamento del sistema, ponealcuni problemi nel caso si voglia modificare o aggiungere altre funzionalità chemagari non si erano previste inizialmente; questi aspetti verranno affrontati suc-cessivamente integrando gli artefatti del sistema di test iniziale in un progettopiù ampio che tenterà di risolverli mediante l’uso di framework opensource.Per permettere questa integrazione vedremo come realizzare un particolare com-ponente software che sfrutti gli elementi precedentemente realizzati e parte deiservizi resi disponibili dal framework al fine di garantire all’utente la possibilitàdi riprogrammare a runtime la logica di controllo e anche la possibilità di ag-giungere o rimuovere nuovi dispositivi senza dover riavviare completamente ilsistema.Dato che la ristrutturazione ha riguardato l’intero appartamento si è pensatodi predisporre in modo opportuno, fin dalla posa dei corrugati e delle scatoledi derivazione, i vari sottosistemi: impianto elettrico, impianto multimediale,impianto di comunicazione. Si è deciso per una posa delle canalizzazioni perl’impianto elettrico in modo tale che, in caso di necessità, fosse stato possibiletornare ad una posa quasi tradizionale dei cavi tramite l’utilizzo di normalissimirelè e pulsanti.Ad esempio un impianto di illuminazione tradizionale prevede la posa di un in-terruttore nella tratta del cavo che dal quadro elettrico porta al punto luce. Nelnostro caso invece il comando e il punto luce hanno tratte differenti raggiunteentrambe da una derivazione di zona o dal quadro generale. In alcuni casi sonostate collegate tra loro più scatole dei pulsanti qualora avessimo passato il cavobus tra l’una e l’altra.Il tipo di posa delle canalizzazioni sebbene, come abbiamo visto, sufficientemen-te flessibile ha determinato in parte anche il tipo di hardware domotico su cui si

72

4.1 Sistema domotico HomePLC

è scelto di orientarsi in quanto non tutti i sistemi sul mercato accettano una posadistribuita per tutto l’appartamento obbligando a centralizzare completamentela logica di controllo in un unico punto. Sebbene per chi deve intraprendere gliinterventi di manutenzione possa essere visto come un vantaggio per il tecnicoche deve effettuare la posa delle canalizzazioni non è sicuramente un compitosemplice.


Il sistema HomePLC fornisce due controller: uno programmabile con standardIEC-EN 61131-3 e un secondo programmabile con linguaggi di alto livello qualic/c++, php, python e Java.Entrambi i controller condividono una parte di hardware chiamata processoredomotico che fondamentalmente si comporta come un PLC classico.

HomePLC.Linux

L’HomePLC.Linux è un embedded formato da processore e scheda di espansio-ne. Il modulo principale è realizzato dalla Engicam e si tratta di un moduloSODIMM basato sul processore i.MX53 della Freescale™ il cui core è un ARMCortex™-A8 la cui frequenza raggiunge 1GHz.

Figura 4.1: i.Core M53

73

4 Caso di Studio

La scheda di espansione fornisce diversi connettori: alimentazione, 2 porteRS-485 per il collegamento con i device HomePLC, una coppia condivisa RS-485/RS-232 per la connessione a dispositivi esterni (ad es. Energy Meter conprotocollo modbus rtu), una seriale RS-232, una presa console, una presa USBe una presa ethernet 10/100Mbit.Questo dispositivo è corredato da diverse librerie: la libreria XComm nativa delKernel Linux e le librerie di integrazione per i linguaggi c/c++, php, python eJava.

Lettura e scrittura degli I/O

Figura 4.2: Ciclo di esecuzione del PLC

Non sono disponibili specifiche dettagliate di come il protocollo XComm++lavori su bus RS485 però alla base del funzionamento del processore domotico c’èun ciclo continuo di operazioni così come avviene per qualunque altro dispositivoPLC classico.Quello che cambia è semplicemente che HomePLC non ha accesso diretto ai variI/O ma i tempi per l’accesso ai vari moduli sono regolati in base al trasferimentoche avviene su bus e quindi con una logica diversa da quella industriale. Sebbene

74


il periodo del ciclo principale sia fissato a 100 msec i tempi con cui arrivano leinformazioni al controller dipendono dal particolare device e su quale area sonomappate le sue risorse. Abbiamo quindi:

• un’area “real-time” per gli ingressi e le uscite digitali con periodo diaggiornamento di 150 msec

• le restanti area generalmente con periodo tra i 400 e i 600 msec

In questo contesto i tempi di lavoro, sebbene non adatti a un contesto dicontrollo numerico, sono da considerarsi normali per il settore specifico delladomotica.

Caratteristiche

• Memoria Programma utente 15 KByte

• Memoria Utente 8 KByte

• Memoria Processore Domotico 8 KByte

• RTC Real Time Clock on Chip

• Capacità di elaborazione Ladder 10 MIPS

• Capacità di elaborazione Domotica 7,2 MIPS

• Ciclo di programma 100msec fisso

L’HomePLC è dotato di funzionalità Plug&Play che permette di configurareautomaticamente ogni tipo di dispositivo, mappare il dispositivo nella corret-ta area IEC per la programmazione oltre che tabulare il modello di dispositi-vo secondo le sue funzioni caratteristiche per il corretto utilizzo da parte delsistema.Il plug&play non esegue però l’indirizzamento automatico dei device per cui èrichiesto che i vari dispositivi, prima di eseguire questa funzione, siano corret-tamente indirizzati sui vari livelli del sistema secondo la corretta mappatura diprogetto, che viene normalmente stilato sulla tabella delle Risorse di Sistema.

75

4 Caso di Studio

L’indirizzamento dei device avviene su livelli:

Livello 1 Supervisione/Multimaster (indirizzi 1..999)

Livello 2 dedicato alle varie tipologie di master (indirizzi 1..46)

Livello 3 dedicato alle varie tipologie di dispositivi slave.In base al master di livello 2 si può avere:

• caso Master I/O (indirizzi 1..46)

• caso Master DMX (indirizzi 1..512)

• caso Master DALI (indirizzi 1..128)

Ligica distribuita

Nonostante la logica di programma sia contenuta nell’HomePLC alcuni moduliprevedono la possibilità di svolgere una serie di funzioni sia in combinazionecon la logica dell’HomePLC sia in autonomia: come nel caso il PLC sia in stopoppure sia caduta la comunicazione per qualche motivo.Questa è una particolarità molto utile di questo sistema domotico in quantoha permesso di installare il sistema e cominciare a utilizzarlo senza prima averrealizzato il sistema software di controllo.Molte delle funzionalità di genstione luci, tapparelle, comprese temporizzazionie altro sono già disposibili tramite configurazione dei moduli che quindi per-mettono di diventare produttivi molto velocemente e garantiscono uno scenariodi utilizzo in sicurezza se dovesse accadere qualcosa di spiacevole al controllerprincipale o alle connesioni bus.

4.2 Sistema domotico di test

Prima di affrontare l’integrazione del controller HomePLC nel sistema open-HAB è stato necessario realizzare un componente software in grado di rilevarecambiamenti di stato che avvengono nella tabella dei registri HomePLC; que-ste variazioni, ad esempio, avvengono alla pressione di pulsanti, al variare delle

76


condizioni dei relè di uscita o quando un qualsiasi parametro, dei dispositivi con-nessi al sistema, subisce una variazione (il caso più semplice è una variazione ditemperatura).Come spunto per iniziare realizzare un primo sistema domotico di test ho consi-derato le logiche già presenti all’interno dei moduli HomePLC. Come abbiamogià avuto modo di illustrare alcuni moduli del sistema HomePLC sono dotatidi micro programmazione consentendo ad essi di operare anche in caso di pro-blemi sul bus o quando si interrompe la comunicazione con il modulo di livellosuperiore.Ad esempio i moduli adibiti all’input/output digitale sono mappati nella parteiniziale della tabella dei registri di HomePLC di conseguenza alla variazione diun ingresso vedrò variare un bit in una delle word (da 16bit) nella zona checomprende i primi 400 registri. I moduli da guida din gestiscono internamentelogiche passo-passo tra ingressi e uscite e almeno una logica tapparelle che sipreoccupa di interfacciare due ingressi e due uscite gestendo anche il caso diinterblocco fra le due uscite.

Descrizione del problema

Il problema in esame, sebbene di ridotte dimensioni, può essere ricondotto a unesempio tipico di automazione che agisce su l’impianto elettrico di una stanza diappartamento residenziale; dotata di luce elettrica (emessa da una lampadina),una finestra dotata di tapparella con avvolgibile elettrico e tre pulsanti dedicatial controllo dell’illuminazione e della movimentazione della tapparella.L’impianto elettrico tradizionale è stato sostituito da un sistema domotico Ho-mePLC basato su bus di campo e, per quanto riguarda lo specifico esempio,composto da:

• un modulo di controllo sul quale andrà programmato il sistema

• un modulo di espansione in grado di rilevare la pressione dei pulsanti eil controllo di relè di attuazione per il lampadario e per il motore dellatapparella.

77

4 Caso di Studio

L’utilizzatore tipico di un tale sistema è il proprietario dell’abitazione che, entra-to nella stanza, preme i pulsanti relativi all’accensione della luce della lampadinae all’azionamento del motore della tapparella.L’azione di pressione del pulsante associato alla lampadina chiude e apre uncontatto tramite il meccanismo basculante del pulsante e invia un segnale elet-trico al contatto di ingresso del modulo di espansione che traduce in eventi logicila pressione e il rilascio del pulsante. Nell’istante in cui questi eventi vengonorilevati il modulo di espansione invia tali eventi al modulo di controllo trami-te bus che memorizza questa successione di eventi in una tabella di memoriacontenuta al suo interno.La tabella di memoria del controller HomePLC è dotata di numerosi registrida 16bit. Una particolare area di questa tabella corrisponde a tutti i possibilidispositivi di espansione, dotati in ingressi e uscite digitali, che possono essereconnessi al controller tramite bus. Questa area viene suddivisa ulteriormentenella parte riservata agli input e una parte riservata agli output, la distinzioneè che la parte riservata agli input può essere solo letta mentre la parte adibitaagli output può essere letta e scritta.Quando l’utente premerà il pulsante a parete, tutto il meccanismo fin qui de-scritto, modificherà un bit della tabella di memoria impostandolo a 1 mentrequando l’utente rilascerà il pulsante lo stesso bit precedente verrà reimpostatoa 0.Il meccanismo di comando funziona in maniera opposta alla precedente descri-zione modificando i valori impostati nella tabella del controller e propagando ilvalore logico impostato fino al modulo di espansione che agirà sul comando delrelè contenuto al suo interno aprendo e chiudendo il contatto e di conseguenzaabilitando o inibendo il flusso di corrente nel cavo ad esso collegato.La ditta costruttrice del sistema domotico fornisce il controllore corredato di unalibreria software di interfaccia verso la tabella dei registri dotata di istruzioniper l’inizializzazione, per la lettura e per la scrittura dei registri o parte di essi.Questa libreria, scritta in c, permette anche di utilizzare il sistema domoticotramite il linguaggio Java.

78


Quello che si vuole realizzare è la logica di controllo di accensione della lampa-dina e della movimentazione della tapparella.Il lampadario può essere acceso o spento e la sequenza di accensione e spegni-mento è descritta da una logica di tipo passo-passo (nome utilizzato anche dairelè tradizionali solitamente impiegati in questo caso) che in una situazione diriposo mantiene lo stato ma che cambia di stato ogni volta che viene premuto(e successivamente rilasciato) il relativo pulsante.La tapparella ha due direzioni di movimentazione determinate da quale cavodel motore è percorso dalla corrente e la logica tapparella rileva gli stati attualidei due relè connessi ai due cavi delle fasi del motore adibito alla movimenta-zione della tapparella. Se entrambi i relè sono disattivati la tapparella risultaferma in quanto nei cavi delle due fasi non scorre corrente. Ognuno dei duepulsanti, e di conseguenza ognuno dei due relè, corrisponde a una delle duedirezioni in cui la tapparella può essere movimentata. Quando l’utente premeil pulsante corrispondente al movimento di salita la logica tapparella attiva ilrelè corrispondente fino a quando non è trascorso un tempo Tup che disattivaautomaticamente il relè di uscita. La stessa logica di controllo avviene per ilsecondo pulsante ma con il secondo relè, un tempo Tdown e il movimento di di-scesa della tapparella. Qualora l’utente prema nuovamente un pulsante primadella scadenza dei tempi Tup o Tdown la tapparella si deve arrestare.

Analisi dei requisiti

Use Case Model

In base a quanto esposto nella descrizione del problema si possono identifica-re due casi d’uso principali legati rispettivamente all’accensione e spegnimentodi una lampadina e alla movimentazione di una tapparella motorizzata. Con-tinuando a leggere la descrizione del problema si può notare come il sistemaHomePLC consenta tramite i suoi dispositivi di percepire la pressione di unpulsante e comandare l’apertura e chiusura di un relè ma soprattutto come per-

79

4 Caso di Studio

System

Turn on/off

Lights

Move up/down

Rollershutter

Sense Device

Contacts

Control Device

Relais

User

<<Include>>

<<Include>><<Include>>

<<Include>>

Figura 4.3: Use case model

metta di astrarre completamente da questi meccanismi e ridurre tutto a statilogici contenuti nella tabella dei registri del controller domotico.

Domain Object Model

Contact Relay

HomePLC Device

Registers Table

1

0..16

1

0..16

HomePLC Controller 11

0..11..*

Light Bulb

state: LightBulbState

Roller Shutter

state: RollerShutterState

«enumeration»Light Bulb state

WAITMOVE_UPMOVE_DOWN

«enumeration»Roller Shutter state

ONOFF

11

1 1

2

1

2

1

Figura 4.4: Domain Object Model

Come si può vedere dal modello il controller HomePLC può disporre di più

80


dispositivi esterni. Quelli che ci interessano in questo momento sono i dispositividedicati agli ingressi e alle uscite digitali. Questo tipo di dispositivi può esseredotato da un minimo di 4 a un massimo di 16 ingressi e uscite; sono disponibilidiversi dispositivi tra cui gli 8in, gli 8out, i 4in+4out e i 16in+16out.Dal modello risulta che per il comando di una lampadina occorre un solo pul-sante mentre per la tapparella sono richiesti due pulsanti: uno per direzionedi movimento. Analogamente sia la lampadina che la tapparella richiedono unnumero di relè corrispondenti al numero di pulsanti appena considerati.Nel modello sono stati indicati anche gli stati in cui possono trovarsi i dueoggetti che dobbiamo comandare nel sistema.

Glossario

Tabella 4.1: GlossarioNome Descrizione

Light Bulb Fonte luminosa artificiale che può essere basata su tecnologie

molto diverse tra loro. Collegata all’impianto elettrico di un

appartamento produce luce quando alimentata da corrente elettrica.

Roller Shutter Tipo di porta o finestra formata da barre orizzontali unite tra

loro. Nel nostro caso è dotato di motore elettrico che permette di

movimentarla in una direzione o nell’altra aprendo o chiudendo il

varco dove è montata.

Switch Pulsante basculante montato in scatole a parete. Premuto chiude un

contatto elettrico presente al suo interno e una volta rilasciato

torna nel suo stato di riposo aprendo il contatto presente al suo

interno.

Relay Dispositivo elettrico comandabile che apre e chiude un contatto in

grado di abilitare o inibire il flusso di corrente in un cavo a cui

è connesso. Il comando avviene facendo scorrere corrente in una

spirare che producendo un campo magnetico aziona il contatto

principale.

Contact Sensore di ingresso che rileva quando viene fatta scorrere corrente

nel cavo ad esso collegato. Solitamente utilizzato congiuntamente

con uno Switch.

81

4 Caso di Studio

Tabella 4.1: GlossarioNome Descrizione

Controller Dispositivo del sistema HomePLC dotato di processore, RAM e flash

memory in cui memorizzare il software di controllo del sistema di

automazione. Abilitato a ricevere i segnali dei Device a lui

collegati memorizza le informazioni in una tabella dei registri

contenuta al suo interno. Tramite opportuni segnali inoltra

comandi ai Device che dovranno preoccuparsi degli azionamenti.

Device Dispositivo del sistema HomePLC connesso tramite bus al Controller

e dotato di un certo numero di Contact e Relay. Funziona come

sensore per i Contact e sia da sensore che attuatore con i Relay.

Ogni volta che viene rilevata una variazione ai suoi ingressi o

alle sue uscite inoltra opportuni segnali al Controller.

Register Table Contenuta all’interno del controller HomePLC mantiene lo stato

aggiornato di tutto il sistema domotico. La correttezza delle

informazioni in essa contenute rispetto allo stato reale in campo è

dovuto alla microprogrammazione contenuta all’interno dei singoli

moduli che compongono il sistema HomePLC.

Scenari

Dettagliamo di seguito gli scenari associati agli use case precedenti.Inizialmente vediamo il caso d’uso legato all’accensione e spegnimento dellaluce in una stanza. In questo caso si possono notare lo scenario principale e loscenario alternativo nel caso in cui la lampadina fosse già accesa. Come si puònotare sono stati inseriti i rami di inclusione verso altri use case. Si può notarecome l’elevato numero di inclusioni indichi una forte dipendenza di questo usecase dagli altri due.

Tabella 4.2: Turn on/off Light Bulb use caseUse Case: Turn on/off Light Bulb

Attori L’utente

Precondizioni Il sistema è avviato e non ci sono errori di comunicazione tradispositivo e controller .

Il LightBult è in stato di OFF.

Scenario principale

82


L’utente entra nella stanza e osserva la quantità di luce presente. Notando che laquantità non è sufficiente e la lampadina è spenta preme e rilascia il pulsante aparete.--> include(Sense Device Contacts)Il sistema, rilevato l’evento di pressione del pulsante, applica la logicapasso-passo e invia i comandi per far chiudere i contatti del relè corrispondente alcavo di alimentazione della lampadina.--> include(Control Device Relais)Il dispositivo effettua le azioni corrispondenti ai comandi richiesti.

Il dispositivo completata l’azione di comando aggiorna di conseguenza lo stato logico

interno della lampadina.

Scenario alternativo

L’utente nota che la luce nella stanza è sufficiente e la lampadina è accesa. Premee rilascia il pulsante a parete.--> include(Sense Device Contacts)Il sistema, rilevato l’evento di pressione del pulsante, applica la logicapasso-passo inviando i comandi per far aprire i contatti del relè corrispondente alcavo di alimentazione della lampadina.--> include(Control Device Relais)Il dispositivo effettua le azioni corrispondenti ai comandi richiesti.


interno della lampadina.

Il secondo caso d’uso considerato è quello relativo alla movimentazione dellatapparella. Non sono stati dettagliati tutti gli scenari alternativi per brevitàma semplicemente i due più rappresentativi di questo use case. Ciò che si ètralasciato è il caso opposto a quello considerato in cui venga alzata la tapparellae il caso in cui per arrestare la tapparella in movimento viene premuto il pulsantedel verso di movimentazione opposto. In questo ultimo caso il comportamentoè identico allo scenario alternativo indicato di seguito. Anche in questo caso c’èuna forte dipendenza dai due use case restanti.

Tabella 4.3: Move up/down Blind use caseUse Case: Move up/down Roller Shutter

Attori L’utente

Precondizioni Il sistema è avviato e non ci sono errori di comunicazione tradispositivo e controlle.

La RollerShutter è in stato di wait.

Scenario principale

83

4 Caso di Studio

L’utente entra nella stanza e osserva la posizione della tapparella. Notando che latapparella è alzata decide di abbassarla e preme e rilascia il pulsante a parete checomanda l’abbassamento.--> include(Sense Device Contacts)Il sistema, rilevato l’evento di pressione del pulsante di abbassamento e applicandola logica Blind invia i comandi per fare abbassare la tapparella.--> include(Control Device Relais)Il dispositivo effettua le azioni corrispondenti ai comandi richiesti.Il sistema completata l’azione di comando aggiorna di conseguenza lo stato logicodella Tapparella.Subito dopo attiva un timer per il tempo Tdown impostato.Trascorso il tempo Tdown la logica Blind invia i comandi per togliere l’alimentazioneal motore della tapparella.--> include(Control Device Relais)Il dispositivo effettua le azioni corrispondenti ai comandi richiesti.


della Tapparella.

Scenario alternativo

L’utente entra nella stanza e osserva la posizione della tapparella. Notando che latapparella è alzata decide di abbassarla e preme e rilascia il pulsante a parete checomanda l’abbassamento.--> include(Sense Device Contacts)Il sistema, rilevato l’evento di pressione del pulsante di abbassamento e applicandola logica Blind invia i comandi per fare abbassare la tapparella.--> include(Control Device Relais)Il dispositivo effettua le azioni corrispondenti ai comandi richiesti.Il dispositivo completata l’azione di comando aggiorna di conseguenza lo stato logicodella Tapparella.Subito dopo attiva un timer per il tempo Tdown impostato.L’utente non attende il completamento del tempo Tdown e preme e rilascia nuovamenteil pulsante a parete.--> include(Sense Device Contacts)Il sistema, rilevato l’evento di pressione del pulsante di abbassamento applica lalogica Blind e invia i comandi per far arrestare la tapparella.--> include(Control Device Relais)Il dispositivo azzera timer Tdown precedentemente impostato.Il dispositivo effettua le azioni corrispondenti ai comandi richiesti.


della Tapparella.

I due casi d’uso seguenti, sebbene non vengano avviati dall’interazione con l’u-tente, sono di fondamentale importanza per il corretto avanzamento degli scena-ri precedenti. Senza questi due casi d’uso le azioni dell’utente non potrebberoessere rilevate dal sistema e non sarebbe possibile effetturare gli azionamentidelle logiche appena descritte.Come vedremo più avanti, anche se lo scenario indicato risulta molto breve,molte saranno le implicazioni che una corretta progettazione e implementazioneavranno sull’intero sistema.

84


Tabella 4.4: Sense Device Contacts use caseUse case: Sense Device Contacts

Attori

Precondizioni Il sistema è avviato e non ci sono errori di comunicazione tra

dispositivo e controller.

Scenario principale

Il sistema effettua una lettura completa della tabella dei registri utilizzando lefunzioni rese disponibili dalla libreria nativa.Tutti i registri letti vengono salvati in una zona di memoria e confrontati con ivalori letti al passo precedente.

Nel caso venga rilevata una differenza tra il vecchio valore e il nuovo valore viene

generato un evento e inviato internamente al sistema in modo che chiunque fosse

interessato possa riceverlo e compiere le azioni necessarie.

Seque anche l’ultimo caso d’uso che riguarda gli azionamenti effettuati dallalogica di controllo.

Tabella 4.5: Control Device RelaisUse case: Control Device Relais

Attori

Precondizioni Il sistema è avviato e non ci sono errori di comunicazione tra

dispositivo e controller.

Scenario principale

Il sistema riceve i comandi dalle logiche di controllo e li elabora richiamando le

funzioni rese disponibili dalla libreria nativa che andranno a modificare i valori

nella tabella dei registri.

Analisi del problema

Dalla descrizione degli scenari risultano molto importanti i casi d’uso relativialla rilevazione dei segnali di ingresso e delle attuazioni in uscita. Visto l’aspettofondamentale che rivestono si decide di analizzare per primi questi argomenti.Il sistema HomePLC fornisce una serie di strumenti software per consentire agliutilizzatori di realizzare il proprio sistema domotico utilizzando linguaggi di alto

85

4 Caso di Studio

livello. Questo si traduce nella possibilità di utilizzare librerie per l’accesso allerisorse della tabella dei registri HomePLC.Anziché accedere mediante polling le singole risorse nella tabella dei registririsulta preferibile realizzare un componente dedicato in grado di rilevare ognipossibile variazione nelle risorse HomePLC e notificare in modo opportuno ilsistema; questo per evitare che il sistema resti impegnato inutilmente nel casonulla di importante accada nell’ambiente o nessuna richiesta venga effettuatada parte dell’utente.Chiameremo Event Generator il componente che leggerà la tabella dei regi-stri e in base alle variazioni rilevate confezionerà un oggetto contenete tutte leinformazioni necessarie a risalire all’occorrenza che è avvenuta nel sistema.

: Event Generator : HomePLC interface

loop

[end of table = false]

: old Value Data

opt[result=true]

1 : readRegister

2 : registerValue

3 : compareValue

4 : result

5 : sendEvent

Figura 4.5: Comportameto dell’Event Generator

Dato che l’evento deve essere consegnato ad un arbitrario numero di osservato-ri è conveniente introdurre una ulteriore entità che permetterà di alleggerire icompiti dell’Event Generator. Introdurre un Event Dispatcher nel sistema con-sente all’Event Generator di concentrarsi esclusivamente sul rilevamento e lagenerazione degli eventi riducendo al minimo il tempo necessario a consegnare

86


l’evento al dispatcher. L’Event Dispatcher riceverà uno di seguito all’altro glieventi che il generatore gli invierà accodandoli in una struttura al suo interno egestirà in autonomia la consegna a tutti gli interessati di una copia del singoloevento prelevandolo, quando disponibile, dalla coda.

: Event Generator : Event Dispatcher

loop

[more observer?]

loop

[has more events?]

par

1 : sentEvent

2 : get Event

3 : toObserver

Figura 4.6: Aggiunta di Event Dispatcher

Vediamo di comprendere a chi vengono inviati questi eventi.Abbiamo visto che, per il momento, siamo interessati esclusivamente a variazionisul singolo ingresso e quindi stiamo parlando di un elemento che resterà inascolto dell’evento per lui importante. Sarà un oggetto che dovrà registrarsipresso l’event dispatcher indicando la risorsa di suo interesse e una volta ricevutol’evento potrà trattarlo nella maniera più opportuna.Possiamo distinguere due casi. Il primo elemento, che possiamo chiamare Di-gitalInput, è legato ai segnali di ingresso: ricevuti, ad esempio, alla pressionedei pulsanti. In genere l’azionamento di un pulsate è un’operazione abbastanzarapida che prevede l’invio di due eventi: il primo alla pressione e il secondo alrilascio. Senza complicare troppo la gestione di un ingresso considereremo solo

87

4 Caso di Studio

il fronte di salita al momento della pressione trascurando il fronte di discesa alsuccessivo rilascio. Nella realtà però non è detto che a un ingresso sia collegatoun pulsante e soprattutto non è detto che sia interessato solo al fronte di salitadel segnale; potrei voler rilevare solo il fronte di discesa oppure entrambi, senzaconsiderare il caso in cui potrei avere un ingresso “normalmente chiuso” in cuii due fronti sono invertiti.Il secondo elemento, chiamato DigitalOutput, è legato ai comandi in uscitache gli vengono impartiti dalle logiche di controllo. Nonostante il suo compitoprincipale sia quello di propagare i comandi ricevuti verso la libreria nativarisulta comodo inserire al suo interno anche la logica di funzionamento delDigitalInput. In questo modo ogni volta che un relè di uscita cambia statoDigitalOutput viene notificato dall’Event Dispatcher. Nel caso delle uscite sivogliono rilevare entrambi i fronti del segnale di uscita in quanto generalmentele variazioni non sono così rapide come i segnali di ingresso e poi perchè l’utilizzoche se ne fa può essere legato alla conferma dell’avvenuto azionamento.

Digital Input

Event Dispatcher

Digital Output

Event Generator

HomePLC interface

old Value Data

Figura 4.7: Architettura rilevamento eventi e azionamento

È giusto notare che anche in questo caso abbiamo considerato solo una piccolaparte delle specifiche che può avere un DigitalOutput; l’azionamento di un Di-gitalOutput potrebbe essere ritardato mediante un opportuno Tdelay, avere untempo massimo Toff dopo il quale resettarsi e, in entrambi i casi, ricominciare il

88


conteggio se dovesse ricevere un segnale opportuno o annullarne l’azionamento.Analogamente al DigitalInput l’uscita potrebbe invertire gli stati se impostatocome “normalmente chiuso”.

Logica Passo-Passo

OFF ON

pressed

pressed

Figura 4.8: State Diagram logica passo-passo

La logica passo-passo è di per se molto semplice in quanto la macchina a statifiniti che la descrive ha due soli stati e il passaggio da uno stato all’altro avvienetramite l’unico segnale di ingresso accettato.Rispetto alla logica Blind non sono presenti timer ma, come abbiamo vistoper gli elementi DigitalInput e DigitalOutput, potrebbero esserci casi in cuivenga richiesto di disabilitare l’uscita dopo un certo periodo (ad es. l’uscitatemporizzata della luce scale) così come anche un ritardo di attivazione (ades. l’attivazione di una sirena di allarme). In questo caso viene presentata solol’architettura logica mentre per il diagramma di interazione si rimanda la quellodella logica Blind che risulta un pò più complesso.

Logica Blind

Nella logica blind, leggermente più complessa della passo-passo, gli ingressi sonodue e compaiono anche Tup e Tdown che sono rispettivamente i tempi di salita ei tempi di discesa che indicano dopo quanto tempo va tolta l’alimentazione al

89

4 Caso di Studio

Digital Input

Light Bulb state

Digital Output

HomePLC interface

Event GeneratorEvent Dispatcher

PP logic

Switch Handler Relay Handler

old Value Data

Figura 4.9: Light Bulb Analysis Model

WAIT MOVE_UP

MOVE_DOWN

updown

Tdown | up | down

Tup | up | down

Figura 4.10: State Diagram logica Blind

motore di movimentazione. Va notato anche che qualsiasi pressione di pulsanteprovoca l’arresto della tapparella. Questo comportamento è necessario e viene

90


chiamato interblocco. Si rende necessario in quanto alimentare il motore permovimentare la tapparella in entrambe le direzioni potrebbe causare guasti almotore.La logica Blind è una macchina a stati finiti che reagisce a una coppia di se-gnali in ingresso e genera una coppia di segnali in uscita. Quando un evento èpresente alla coppia di ingresso relativa ai pulsanti elabora il comportamentoda intraprendere e produce il segnale opportuno in uscita.L’interazione con i DigitalInput e i DigitalOutput viene realizzata introducendodegli opportuni handler che hanno il compito di riceve i segnali ricevuti in inpute inoltrare i comandi ritenuti necessari dalla logica Blind.

Event Dispatcher Event Generator

HomePLC interface

Digital Input Up

Digital Input Down

Digital Output Up

Digital Output Down

DODown Handler

DOUp Handler

DIDown Handler

DIUp Handler

Blind LogicRoller Shutter state

old Value Data

Figura 4.11: Roller Shutter Analysis Model

Vediamo di mostrare ora la dinamica dello scenario principale relativo allamovimentazione della tapparella verso il basso.

91

4 Caso di Studio

In questo scenario tra gli eventi che il sistema invia al DigitalInput viene sceltodi inoltrare all’handler solo quello relativo alla pressione del pulsante trascuran-do il successivo rilascio. L’handler informa la logica Blind che è stato premutoil pulsante down. La logica Blind in base allo stato interno invia la richie-sta all’handler relativo alla movimentazione di abilitare la chiusura del relècorrispondente per il motore della tapparella.Quando DigitalOutput risponde alla logica di controllo tramite l’handler rela-tivo, la logica Blind aggiorna lo stato interno in accordo al comando inviato.Nel caso l’evento sia quello relativo a una delle due movimentazioni viene atti-vato un timer, al termine del quale, la logica Blind (previo controllo dello statointerno) invia il segnale di aprire il relè corrispondente alla movimentazione inatto.Questo scenario mostra come la logica Blind attenda un tempo Tdown prima ditogliere alimentazione al relè. Lo scenario alternativo, ma ce ne sarebbero altri,prevede che l’utente prema nuovamente il pulsante prima del tempo di arresto;in questo caso ci sarebbe un altro ramo parallelo al timer in cui, una volta che lalogica Blind ha ricevuto l’informazione che è stato ripremuto il pulsante, vienecancellato il timer ma viene comunque inoltrata la richiesta di aprire il contattodel relè per arrestare la tapparella.

Analisi dei rischi

Analizzando l’architettura logica del sistema si può notare come la parte piùcritica risulta essere quella che si occupa della generazione degli eventi. Lecriticità che emergono sono dovute all’alto numero di confronti che potrebberoessere richiesti se un numero elevato di variazioni avvenissero in un certo istantedi tempo. Un alto numero di confronti potrebbero causare un notevole ritardoal tempo richiesto per completare la lettura di tutti i registri della tabella Ho-mePLC obbligando a posticipare l’inizio del ciclo successivo oltre il limite delperiodo che si è deciso di adottare.Questo sicuramente si tradurrebbe nel percepire il sistema come non sufficien-temente reattivo e il ritardo dalla pressione di un pulsante al corrispondente

92


: Blind Logic: Digital Input Down : DODown Handler: DIDown Handler : Roller Shutter state : Digital Output Down

pressedsignal(pressed)

execute(down)get

released

wait

signal(enable)

enable

update

get

moving_down

signal(disable)disable

update

{ t .. t + Tdown }

Figura 4.12: Interazione Roller Shutter

azionamento sarebbe non accettabile, risultando in una pessima sensazione daparte dell’utente.Inoltre incrementando troppo il periodo per il ciclo di lettura, per permetteredi gestire un numero molto elevato di eventi, si potrebbe generare la contro-indicazione di non rilevare affatto un evento nel sistema causando la perditadi comandi se non addirittura l’esecuzione di comandi completamente erratirispetto a quanto realmente richiesto dall’utente.I DigitalInput e i DigitalOutput, come abbiamo visto, ricevono eventi dall’E-ventDispatcher per poi avviare le logiche di controllo alle quali sono collegati. Sela logica di controllo dovesse impiegare troppo per essere completata l’EventDi-spatcher rischierebbe di rimanere bloccato e non riuscire a gestire con rapiditàla consegna degli eventi a tutti gli elementi che lo richiedono. Presumibilmen-te anche DigitalInput e DigitalOutput potrebbero richiedere un proprio flusso

93

4 Caso di Studio

di controllo e una coda di eventi dalla quale estrarre l’evento da gestire. Allastessa maniera come è stato pensato per l’EventDispatcher e l’EventGenerator.Il problema che potrebbe sorgere in questo caso è legato all’alto numero di ele-menti digitali che corrisponderebbe a un alto numero di thread nel sistema. Lagestione multi-thread da parte di un sistema potrebbe richiedere lo spreco dimolte risorse e nuovamente subire rallentamenti inattesi. Se il dispositivo cheospita il sistema inoltre è dotato di un unico processore l’utilizzo di un elevatonumero di thread contemporaneamente potrebbe far degradare le prestazioni.

Piano di collaudo

Per collaudare i componenti software che verranno realizzati contestualmente alprogetto del sistema verrà sfruttato anche l’ambiente domestico in cui è instal-lato il sistema domotico. Fortunatamente avendo già installato i componentiprincipali e collegati i carichi ai rispettivi relè di azionamento si potrà sfrutta-re l’osservazione diretta del comportamento del sistema per avere una idea deitempi e della correttezza della logica di controllo. Un risultato più dettagliatasi può ottenere sfruttando opportune istruzioni di debug che generino outputverso la console del sistema HomePLC in moda da ricavare i tempi reali diazionamento e di esecuzione di alcune logiche.La parte più importante da collaudare è indubbiamente il sistema di genera-zione degli eventi in quanto se non opportunamente ottimizzato può causarefastidiosi rallentamenti di tutto il sistema causando una fastidiosa sensazionedi inefficienza.Ci si aspetta che i tempi richiesti per la scansione di tutti i registri della tabellaHomePLC non siano particolarmente rapidi di conseguenza sarà probabilmentenecessario trovare un opportuno metodo di ottimizzazione se non addiritturaprevedere, in caso di miglioramenti modesti, di impiegare parte del tempo amodificare la libreria nativa.

94


Piano di lavoro

Le fasi di progetto seguiranno la seguente sequenza dovuta alla priorità rilevatenella precedente analisi:

1. uso della Java Reflection per la soluzione al problema del default package.L’introduzione di questo punto nel piano di lavoro è stato reso necessarioa seguito di quanto emerso in fase progettuale e implementativa.

2. realizzazione di un generatore di eventi basato su polling delle risorse dellatabella di sistema

3. realizzazione dell’event dispatcher per la distribuzione degli eventi a piùosservatori liberando il generatore di eventi dal peso della loro consegna

4. modifica della native library per rimuovere l’overhead dell’impiego del-la Java Reflection. L’introduzione di questo punto nel piano di lavoroè stato reso necessario a seguito di quanto emerso in fase progettuale eimplementativa.

5. implementazione in codice nativo del generatore di eventi riducendo note-volmente il tempo impiegato per la generazione di eventi. L’introduzionedi questo punto nel piano di lavoro è stato reso necessario a seguito diquanto emerso in fase progettuale e implementativa.

6. realizzazione componenti di gestione degli eventi e comando. Questo puntonon verrà trattato in quanto si passerà a illustrare altri argomenti peri quali sono sufficienti quanto realizzato per il generatore degli eventi el’interfaccia verso la libreria nativa.

Progetto del sistema

Dalla descrizione del problema risulta che il sistema HomePLC mantiene ag-giornata una tabella di registri in cui sono mappati i dispositivi esterni. Perquello che riguarda i nostri casi di studio ci limiteremo a considerare gli ingres-si e le uscite digitali. Per accedere a questa area di memoria viene utilizzata

95

4 Caso di Studio

una libreria scritta in linguaggio nativo ma della quale esistono diverse versioni:una per ogni linguaggio di programmazione che il progettista potrebbe utiliz-zare. In questa fase quindi è possibile fare i nostri ragionamenti mantenendocisufficientemente distanti da aspetti implementativi.Mediante la libreria nativa è possibile richiedere il valore di un particolare regi-stro tramite una istruzione opportuna. Il valore restituito dipenderà dallo statodei bit da cui e composto e quindi dallo stato degli ingressi a cui fanno riferi-mento quei bit. Un registro HomePLC è formato da 16 bit e quindi tramite unsolo accesso sono in grado di leggere lo stato di 16 ingressi oppure 16 uscite.A questo punto una possibilità è quella di leggere i registri della tabella esuccessivamente rilevare quali di questi registri sono variati rispetto al passoprecedente.Tra un ciclo di lettura e l’altro dobbiamo provvedere a valutare quali bit sonovariati rispetto all’ultima lettura. Valutare bit per bit tutta la tabella potrebberichiedere un tempo eccessivamente lungo quindi si decide di valutare registroper registro le possibili variazioni. Nel momento in cui avviene una variazionesu un registro viene generato quello che nel sistema verrà chiamato evento.

HomePLCEvent

+time {readOnly}+register {readOnly}+newValue {readOnly}+oldValue {readOnly}

Figura 4.13: HomePLCEvent

Per il nostro scopo considereremo evento la creazione di un particolare elementocontenente diverse variabili di stato. Questo particolare oggetto è formato daquattro variabili:

• l’indicazione del tempo in cui è stata rilevata la variazione del registro

• l’indirizzo del registro

96


• il vecchio valore

• il nuovo valore

Inserire tale contenuto informativo in questo elemento porta il vantaggio di poterinoltrare direttamente all’osservatore i dati di cui ha bisogno per effettuare lesue operazioni.

Generatore di eventi

«interface»EventGenerator

+start()+stop()+setGeneratorListener(listener)+removeGeneratorListener(listener)

«interface»GeneratorListener

+onGeneratorEvent(event)

HomePLCEvent


Figura 4.14: EventGenerator interfaces

Per ogni processore domotico sono definite diverse aree di memoria che rappre-sentano la mappatura delle risorse del sistema HomePLC: in particolare areaI/O, area System Flag, area Extended Address, System area ed altre. Quan-do un utente preme un pulsante il modulo a cui è connesso fisicamente rilevala pressione e inoltra l’informazione, risalendo l’architettura HomePLC, finoal modulo principale che la registra come variazione in un bit di un registrocorrispondente al modulo rilevatore. Quanti registri sono associati a ciascunmodulo dipende dal suo numero di ingressi, dalle uscite, dai sensori connessio dalle attuazioni per cui è predisposto; inoltre ogni modulo viene impostatocon un indirizzo univoco che quindi determina l’indirizzo del registro all’internodella tabella.Per realizzare il nostro generatore di eventi non dobbiamo far altro che rilevarei cambiamenti all’interno della tabella delle risorse in quanto siamo sicuri cherispecchia costantemente lo stato dei moduli in campo: questa certezza è data

97

4 Caso di Studio

dalla particolare architettura del sistema HomePLC e dal protocollo XComm++utilizzato su bus RS485.

Figura 4.15: Struttura Event Generator

I registri delle zone real-time ed estesa della tabella di memoria del sistemadomotico sono divisi in due sottoinsiemi: registri in ingresso e registri di uscita.I registri di ingresso possono solamente essere letti tramite le istruzioni dellalibreria nativa e ogni tentativo di scrittura non porta ad alcuna variazione delloro contenuto. I registri di uscita, oltre ad essere letti, possono anche esseremodificati generando di conseguenza opportuni azionamenti in campo.L’unico modo per poter accedere al contenuto della tabella dei registri è tramitele istruzioni della libreria nativa e di conseguenza occorre risolvere il problemadi accesso alla libreria nativa da un package qualunque. Si rimanda alla sezioneimplementativa per la soluzione a questo problema.

98


Ingressi Funzioni Note

Registro suindirizzo dinodo

Misura ditemperatura T1

Sonda connettore verde

Registroesteso 1

Misura ditemperatura T2

Sonda connettore nero

Registroesteso 2

Misura diumidità RH%

(1/10)

Registroesteso 3 HighByte

Funzionalitàevolute

Bit 15 = Valore byte low in negativoBit 14 = Blocco per raggiungimento soglia punto dirugiada anticipato per offset temperatura (Temp. -offset)Bit 13 = Avviso prossimo raggiungimento blocco (Temp. -(offset + 1 grado))Bit 12 = Guasto sonda umiditàBit 11 = Guasto sonda Temp. 1 (usata per il blocco)Bit 10 = Guasto sonda Temp. 2

Registroesteso 3 LowByte

Punto dirugiada

Tabella 4.6: Registri Ragnetto Temperatura e Umidità

Una volta risolto il problema del default package possiamo finalmente progettareun generatore di eventi basato sul componente di interfaccia con la librerianativa che è stato appena realizzato.Utilizzando l’attuale componente di interfaccia possiamo leggere solamente unregistro alla volta quindi l’unica possibilità è quella di realizzare un opportu-no loop per leggere tutta una lista di registri e inoltrare l’evento qualora siaavvenuta una variazione nel registro corrente.Resa da considerare come consegnare gli eventi generati e il Pattern Observerpare la scelta naturale dato che in questo momento non vengono fatte consi-derazioni legate ad una possibile natura distribuita del sistema e nemmeno ri-spetto alla possibilità che l’EventDispatcher possa entrare o uscire dal sistemadinamicamente.

Event Dispatcher

Come abbiamo visto, l’introduzione di un nuovo componente, si rende necessarioper permettere al generatore di eventi di rimanere libero da ritardi dovuti allaconsegna dell’evento a un numero molto elevato di osservatori.

99

4 Caso di Studio

GeneratorProxy

+getInstance()+setGeneratorListener(listener)+removeGeneratorListener(listener)+start()+stop()

EventGenerator

TestEventGenerator2


GeneratorListener

0..1

Figura 4.16: Event Generator Observer Pattern

«interface»EventDispatcher

+start()+stop()+addDispatcherListener(register, listener)+removeDispatcherListener(listener)

«interface»DispatcherListener

+onDispatcherEvent(event)

HomePLCEvent




Figura 4.17: Dispatcher interface

Un passo verso una migliore razionalizzazione delle risorse è quella di aggiungereil componente Event Dispatcher che risulta essere observer rispetto al generatoredi eventi ma source rispetto alla totalità degli observers: che si registreranno (overranno registrati) presso il dispatcher specificando anche a quale registro sonointeressati. L’indicazione del registro è utile al dispatcher per ridurre il trafficogenerato dalla consegna degli eventi; in questo modo anzichè realizzare unacomunicazione broadcast dove tutti i ricevitori indistintamente riceveranno unacopia dell’evento si preferirà realizzare una comunicazione multicast dove l’inviodell’evento avverrà a insiemi di observer dipendenti dal particolare registro incui è avvenuto un evento.L’event dispatcher è basato sul Producer-Consumer design pattern ed è in grado

100


Figura 4.18: Vista dei packages

di semplificare lo sviluppo in quanto permette di rimuovere le dipendenze trale classi di producer e consumer e inoltre disaccoppia le attività che produconoo elaborano le informazioni con una rapidità variabile o differente.

Implementazione

In base a quanto analizzato risulta che la libreria di interfaccia fornita assiemeal controller HomePLC può essere acceduta esclusivamente dal default packagedi Java e questo pone diverse limitazioni al suo utilizzo. Inoltre non presenta disuo un meccanismo in grado di generare eventi al variare dei valori dei registridella tabella di sistema.Prima di poter realizzare le logiche di più alto livello associate agli use casesdel nostro caso di studio siamo costretti a risolvere questi limiti implementativi;dapprima sfruttando il meccanismo Java della Reflection e successivamente mo-dificando in maniera più consistente la libreria nativa di interfaccia aggiungendoparte del codice per la generazione degli eventi.In particolare uso della Java Reflection per la soluzione al problema del defaultpackage è una delle priorità senza la quale il progetto non può proseguire e quindirichiede una variazione del piano di lavoro per includere questo argomento.

101

4 Caso di Studio

Il Default Package

Il dispositivo viene fornito con alcuni esempi di applicazione. Nel caso dilinguaggio Java la struttura di un programma è la seguente:

Figura 4.19: Esempio di programma Java e libreria nativa originale.

Come è possibile vedere la classe java di interfaccia con la libreria nativa èformata da tutti metodi statici e pubblici in modo da consentire di utilizzarnei metodi senza bisogno di istanziare la classe. Per caricare a runtime la librerianativa è stato utilizzato uno static initializer:Il difetto di questo approccio è che si viene obbligati a realizzare l’intero pro-gramma che andrà a gestire la logica di controllo nell’unico package utilizzabile:il default package. Il problema nasce perchè, sebbena la classe Hplc sia pubbli-ca (e così anche i suoi metodi statici), tutte le ulteriori classi che si inserirannoa progetto dovranno necessariamente appartenere al default package. Pena la

102


Algoritmo 4.1 static initializer

static {System.out.println("Loading JNI lib");System.loadLibrary("homeplclib");System.out.println("Done ...");

}

non visibilità della classe Hplc. Questo limite è dovuto direttamente alle Javalanguage specifications che testualmente asseriscono «It is a compile time errorto import a type from the unnamed package».Il motivo di questo approccio probabilmente è da ricercarsi nella mentalità ma-turata nell’utilizzo del linguaggio grafico di programmazione chiamato LadderDiagram (standard internazionale IEC 61131-3) impiegato da tutti gli installa-tori del sistema HomePLC. Il linguaggio Ladder, come abbiamo visto, utilizzaun sistema grafico per definire un programma di controllo sequenziale e, sebbe-ne siano presenti qualche forme di controllo di flusso, sicuramente non ha quellaespressività che ha un linguaggio di programmazione di alto livello come Java.L’idea di chi ha rilasciato questi esempi di programmazione era sicuramentequella di definire un unico loop principale dove, una volta rilevate determinatecondizioni, venivano intraprese azioni più o meno elaborate a seconda delloscopo che si voleva ottenere. L’approccio è molto simile quindi a quello, rulebased, utilizzato anche dal linguaggio Ladder.L’idea, fin da subito, è stata quella di risolvere questo vincolo iniziale per con-sentire di realizzare sistemi software dotati di una struttura più complessa. Gliapprocci utilizzabili erano la Java Reflection e la riscrittura della libreria nati-va. La riscrittura della libreria nativa inizialmente è stata scartata in quantola difficoltà non era tanto nel tempo dedicato a ripassare un linguaggio qualeil c/c++ ma la necessità di predisporre tutto l’ambiente di sviluppo adattoalla cross compilazione di software per processori ARM quali quelli installatinell’embedded in nostro possesso.

103

4 Caso di Studio

Utilizzo di Java Reflection

Le Classi appartenenti al Default Package non possono essere importate da unPackage differente.Sebbene prima della J2SE 1.4 si potevano importare tali classi grazie a unparticolare import syntax ora non è più permesso: pena un compile-time error.Visto che non è possibile accedere direttamente alle classi del Default Package,se non essendo all’interno dello stesso, è stato possibile utilizzare un metodoalternativo sfruttando le Reflections API.

Figura 4.20: Diagramma con Meta Livello nel caso di Reflection

Il trucco, se così si può definire, è quello di caricare dinamicamente a runtime laClasse contenente il riferimento ai metodi nativi. Il metodo Class.forName(StringclassName) permette di inizializzare la classe className quindi può essere uti-lizzato per caricare a runtime la classe Hplc purchè presente nel classpath. Una

104


volta ottenuto il Class Object i metodi resi disponibili permettono di estrarreMethod Object, Field Object e altro.Dall’immagine, nonostante la notazione UML non proprio standard, possiamovedere come l’utilizzo di oggetti del meta livello (livello ottenuto grazie all’in-trospezione fornita dalla Java Reflection) riescano ad accedere alla Classe diinterfaccia con il codice nativo.Di conseguenza le Reflection API e la Dynaminc ClassLoading consentono dirisolvere alcune limitazioni dovute alla realizzazione dell’interfaccia nativa perl’accesso alle risorse domotiche.

Figura 4.21: Utilizzo della Reflection.

Dalla figura si può vedere il meccanismo utilizzato per chiamare un metodo del-la classe Hplc: dopo una parte iniziale in cui vengono creati gli oggeti dal fra-mework Reflection ogni successiva richiesta viene soddisfatta chiamando il me-todo invoke() dell’oggetto rappresentativo associato al rispettivo metodo dellaclasse Hplc.

105

4 Caso di Studio

Un componente di interfaccia verso la libreria nativa

Un Subsystem è una risorsa riutilizzabile che altri componenti all’interno delnostro sistema può utilizzare. Gli altri componenti, comunque, sono legati auna interfaccia ben precisa che il Subsystem espone in modo che sia possibilealterarne l’implementazione senza dover modificare tutti i componenti che nedipendono.

Figura 4.22: Relazioni tra packages e subsystem.

L’interfaccia del subsystem ha lo scopo di servire come contratto tra il subsy-stem e il mondo esterno. Qualsiasi interazione con il subsystem deve avvenireattraverso questa interfaccia. Ovviamente la Factory Class deve poter acce-dere ad almeno un elemento interno, che poi altro non è che la classe Proxy,implementazione dell’interfaccia.

106


Un tipo di subsystem così concepito ha delle forti implicazioni sulle dipendenzeche si creano: mentre non ci sono particolari vincoli sulle dipendenze in uscitale restrizioni sulle dipendenze in entrata consentono di sostituire all’occorrenzauna implementazione con un’altra e garantiscono un’alta riusabilità del codice.

Event Generator

S tart A c tivity Inner A c tivity

<<structured>>

Loop

Setup

Test

S top A c tivity

Body

Send Interrupt

Check

condition

Work ActivityInterrupted

Reassert

interrupt flag

Start Request

Set

condition

Set

Condition

Stop Request

<<datastore>>

done

continue

[done]

true

false

Figura 4.23: Smart Object Activity Diagram

L’elemento esteso dalla classe EventGenerator è uno SmartObject: un oggettodotato di proprio flusso di controllo che può essere attivato e terminato a piacere.Dalla versione JDK1.2 il metodo stop() della classe Thread è stato deprecatoin quanto terminava l’esecuzione del Thread in maniera molto secca e questonon dava tempo di eseguire procedure di clean-up causando possibili corruzionidi dati. Inoltre l’arresto repentino del Thread era seguito anche dal rilascio ditutti i lock eventualmente acquisiti lasciando eventuali dati in alcuni oggetti inuno stato inconsistente.

107

4 Caso di Studio

Algoritmo 4.2 SmartObject code

public abstract class SmartObject implements Runnable {private Thread internalThread;private volatile boolean stopRequested;

protected SmartObject () {stopRequested = false;

}

public final void run() {while (! stopRequested) {

try {runWork ();

} catch (InterruptedException x) {// Reassert interrupt so that remaining code// sees that an interrupt has been requested.Thread.currentThread ().interrupt ();// Reevaluate while condition --probably// false now.continue;

}}

}

protected abstract void runWork () throws InterruptedException;

public void startRequest () {stopRequested = false;if (internalThread == null) {

internalThread = new Thread(this);internalThread.start ();

}}

public void stopRequest () {stopRequested = true;if (internalThread != null) {

internalThread.interrupt ();internalThread = null;

}}

protected boolean isAlive () {return internalThread != null ? internalThread.isAlive () : false;

}}

Un metodo per arrestare un thread è quello di utilizzare una variable booleanacome indicatore del fatto che il thread debba continuare il suo lavoro oppure sedebba terminare. Quindi anzichè continuare all’infinito il metodo run() esaminalo stato della variabile ad ogni loop ed esce quando il flag viene impostato.Questo meccanismo è un semplice sistema di sincronizzazione tra due thread edè necessario che il thread che deve essere arrestato veda un valore aggiornato

108


per la variabile flag: evenienza non certa dato che Java permette ai thread dimantenere i valori delle variabili in una memoria locale e inoltre può avvenereanche nel caso di macchine con più processori. Per essere sicuri di questo unapossibile soluzione è di dichiarare volatile la variabile booleana assicurando althread di leggere il dato sempre aggiornato.

E ventG enerator A c tivity

<<structured>>

Loop

Setup

Test

Body

has next

Send HomePLC

Event

Interruption

Check if value

changed

Store new value

Request Register

Value activity

Get Registers

List

<<datastore>>

Registers List

Inizialie old V alues

A c tivity

<<datastore>>

Old Registers

table

Initialize Values

Table

Request all

Registers values

activity

Initialize R egis ters A c tivity

Initialize

Registers List

Set Registers List Every 150 msec

continue

[not changed]

[changed]

Figura 4.24: Event Generator Loop

Il precedente metodo ha il leggero difetto di poter subire ritardi prima che lostato del flag venga nuovamente valutato e nel caso il task eseguito dal threadsia molto lungo può portare a tempi di attesa troppo lunghi. Per terminarerapidamente l’esecuzione del task quello che si può utilizzare è il metodo in-

109

4 Caso di Studio

terrupt() della classe Thread. Il metodo interrupt() ha due effetti: il primo èquello per cui i metodi bloccanti tipo sleep() e wait() generano una Interrup-tedException e il secondo è quello di impostare un flag all’interno dell’oggettoche indica che il thread è stato interrotto. Tale flag può essere interrogato conil metodo isInterrupted().E’ possibile quindi sostiture il controllo tramite variabile volatile con una chia-mata al metodo interrupt() e un controllo tramite il metodo isInterrupted().Ancora però potremmo subire ritardi in quanto se il medoto interrupt() vienerichiamato subito dopo il controllo tramite isInterrupted() il medoto bloccantenon si arresta e occorre attendere fino al termine del loop corrente e a una nuovaverifica. In pratica un caso di race condition.Si può però unire i due metodi precedenti in modo da combinare i privilegiderivati da entrambi: effettuo un controllo su una variabile booleana di tipovolatile per terminare il loop quando richiesto mentre controllo se viene gene-rata una InterruptedException per rilevare il prima possibile l’interruzione earrestare l’esecuzione del task. E’ buona norma riasserire l’interrupt flag subitodopo aver rilevato l’eccezione.

Event Dispatcher

Lo strumento in grado di agevolare la realizzazione di questo pattern è sicura-mente la Blocking Queue. Il produttore inserisce elementi nella coda appenarisultano disponibili mentre il consumatore estrae elementi dalla coda quandoè pronto ad elaborare i dati.Come per il generatore di eventi la classe EventDispatcher estende la clas-se SmartObject quindi eredita i metodi startRequest() e stopRequest() cheavviano e arrestano il dispatcher.

Refactoring della libreria nativa

Come abbiamo potuto vedere l’utilizzo di Java per realizzare il loop generatoredi eventi e del framework Reflection richiede un tempo abbastanza elevato perelaborare tutto quello che è richiesto. Inoltre, inevitabilmente, all’aumentare del

110


Dis patc her A c tivity

<<structured>>

Loop

Setup

Test

Body

Get listeners

of Event

has next

Send Event

to listener

Interrupted

R ec eive E vent A c tivity

Take Event

from Queue

A dd L is tener A c tivity

Receive Event

R emove L is tener A c tivity

Add Event Listener

Remove Event Listener

<<datastore>>

Listeners Map

Event

{Blocking Queue}

Figura 4.25: Event Dispatcher Activity Diagram

numero di eventi generati (caso in cui sia avvenuta una variazione nel contenutodei registri) il ritardo dovuto al dispatch dell’evento potrebbe comprometterela reattività di tutto il sistema.Per ottimizzare questa parte di codice abbastanza onerosa l’idea è quella direalizzare l’intero generatore di eventi in codice nativo inoltrando il risultato deiconfronti verso opportuni metodi callback di una classe Java e successivamenteeseguire il dispaching dell’evento come sempre fatto. Oltre ad aumentare leperformances l’idea è anche quella di eliminare completamente la noia dovutaall’accesso al default package consentendo l’eliminazione della Java Reflectionper accedere alle classi, e ai rispettivi metodi, contenute al suo interno.Uno degli aspetti critici di questa operazione è la necessità di cross-compilaretutto il codice nativo: cosa che richiede di avere sulla propria macchina tutta una

111

4 Caso di Studio

serie di tools opportunamente configurati per generare eseguibili e librerie per iltarget system. Purtroppo non viene fornita indicazione di come realizzare unastazione predisposta a questo scopo e quindi c’è voluto molto tempo, compostoda vari tentativi, per ottenere una configurazione valida e adatta allo scopo.Fortunatamente è possibile installare, tramite il gestore a pacchetti Debian,arm-linux-gnueabi-gcc.

Figura 4.26: Procedimento per generare la native library

Come mostrato in figura Java permette di generare gli header file per le classiche contengono dichiarazioni di metodi nativi.Viene mantenuto il file sorgente originale per garantire compatibilità con levecchie implementazioni ma vengono aggiunti gli header file e i sorgenti per lenuove classi Java contenute nel subpackage privato al bundle.La classe di test ottiene il riferimento all’implementazione dell’interfaccia Ho-mePLC mentre la classe HomePLCProxy si preoccupa di caricare in memoriala classe Hplc con i metodi nativi e la shared library nativa con i file necessari.

112

4.3 openHAB come sistema di automazione

Figura 4.27: Nuova composizione della libreria nativa.


“Welcome to openHAB - a vendor and technology agnostic open source auto-mation software for your home. Build your smart home in no time!”Questo è quello che si può leggere nella prima pagina del sito dedicato all’im-plementazione opensource di riferimento di quello che nel tempo è diventa-to il framework SmartHome: progetto per la Home Automation che fa partedell’ecosistema dedicato alla IoT della Eclipse Foundation. Ma andiamo conordine.openHAB è un insieme di bundle installati su di un framework OSGi (Equinox).E’ una soluzione realizzata interamente in Java e che di conseguenza richiedeuna JVM per essere avviato. Essendo basato su OSGi l’architettura è forte-mente modulare e permette di aggiungere o rimuovere funzionalità mentre è in

113

4 Caso di Studio

Figura 4.28: Esempio di chiamata a metodo nativo senza Java reflection

esecuzione senza arrestare i restanti servizi.L’event bus è il servizio principale di openHAB e tutti i bundles possono uti-lizzarlo per informare altri mediante emissione di propri eventi o ricevere in-formazioni da altri bundle mediante ricezione di eventi esterni. Ci sono duetipi di evento: command che avviano una azione o un cambiamento di stato diqualche Item/Device e status update che modificano lo stato di qualche Item/-Device (spesso in risposta ad un command). Tutti i binding (che realizzano ilcollegamento con i dispositivi hardware) dovrebbero comunicare tramite l’eventbus in modo da rendere l’accoppiamento tra di essi molto debole e di conse-guenza assecondare la natura fortemente dinamica di openHAB. Tecnicamenteper realizzare l’event bus viene utilizzato l’OSGi EventAdmin Service che altronon è che una implementazione di una architettura publish-subscribe che svolgeperfettamente il suo compito.

114


Figura 4.29: openHAB event bus

Spesso è necessario accedere allo stato corrente degli Item come nel caso dellalogica di automazione e dell’interfaccia grafica che deve mostrare all’utente sem-pre lo stato aggiornato degli Item. Il componente che svolge questo compitò èl’openHAB Repository che è anch’esso connesso all’event bus e tiene traccia ditutti i cambiamenti di stato degli Item. L’utilizzo di questo componente dedi-cato evita che ogni binding debba mantenere internamente una cache degli statia cui è interessanto per un suo proprio utilizzo e automaticamente mantenendosincronizzati e disponibili questi stati per tutti i restanti bundle.

Items

Uno dei concetti principali di openHAB è quello di Item. Un Item è un mattoneimportante alla base del sistema che basa la sua natura sul concetto di dato e nonè legato a un particolare dispositivo fisico, una sorgente virtuale quale potrebbe

115

4 Caso di Studio

Figura 4.30: openHAB Architecture Overview

essere un web service o il risultato di qualche calcolo. Tutte le funzionalità diopenHAB sono basate sull’astrazione di Item e, ad esempio, non si troverà mainessun riferimento a informazioni specifiche tipo indirizzi IP, Id, etc. nelle Rules,nella definizione della UI e così via. Questo consente in qualunque momento disostituire una tecnologia con un’altra senza modificare Rules o UI.Un Item è definito dalla omonima interfaccia alla quale è associata una classeastratta chiamata GenericItem che ne realizza una prima implementazione. E’un oggetto dotato di stato interno e quando questo stato viene modificato invianotifiche a una lista di listeners che si sono registrati presso di lui.L’oggetto di tipo StateChangeListener accetta due tipi di notifica:

• stateUpdated ogni volta che viene chiesto di aggiornare lo stato dell’Itemtramite il metodo setState

• stateChanged nel caso il valore associato allo stato dell’Item è realmentecambiato

Da notare che se uno StateChangeListener riceve una notifica di stateChangedriceverà anche una notifica di tipo stateUpdated.

116


«interface»Item

+getState(): State+getStateAs(typeClass: Class): State+getName(): String+getAcceptedDataTypes(): Class[*]+getAcceptedCommandTypes(): Class[*]+getGroupNames(): String[*]

GenericItem

«constructor»+GenericItem(name: String)+getState(): State+getStateAs(typeClass: Class): State+initialize(): void+dispose(): void+getName(): String+getGroupNames(): String[*]+setEventPublisher(eventPublisher: EventPublisher): void+setState(state: State): void+toString(): String+addStateChangeListener(listener: StateChangeListener): void+removeStateChangeListener(listener: StateChangeListener): void+hashCode(): int+equals(obj: Object): boolean

«interface»State

«interface»EventPublisher

+sendCommand(itemName: String, command: Command): void+postCommand(itemName: String, command: Command): void+postUpdate(itemName: String, newState: State): void

«interface»StateChangeListener

+stateChanged(item: Item, oldState: State, newState: State): void+stateUpdated(item: Item, state: State): void

*

SwitchItem StringItemRollershutterItemNumberItemLocationItemDateTimeItemContactItem

DimmerItem ColorItem

«interface»Command

Type

Figura 4.31: openHAB Items Model

L’Item può anche pubblicare comandi sull’event bus sempre che un oggetto ditipo EventPublisher venga registrato all’Item.Stranamente il motodo internalSend() non è richiamato da tutte le implementa-zioni di Item. Solo SwitchItem, DimmerItem, ContactItem e ColorItem imple-mentano il metodo send() che internamente richiama internalSend(). Il metodosend() non appartiene ad alcuna interfaccia implementata dagli Item così èprobabile che sia una parte di codice che è stata dimenticata e mai revisionata.Prima di dettagliare i tipi di Item definiti in openHAB è giusto introdurrel’entità Type e tutte le classi derivate in modo da comprendere come vengagestito lo stato interno di ogni Item.

Types

Il modello dei Types è composto sia da interfacce che fungono da markers siada classi concrete.

117

4 Caso di Studio

Algoritmo 4.3 GenericItem implemetation

protected void internalSend(Command command) {// try to send the command to the busif(eventPublisher !=null) {

eventPublisher.sendCommand(this.getName (), command);}

}

public void setState(State state) {State oldState = this.state;this.state = state;notifyListeners(oldState , state);

}

private void notifyListeners(State oldState , State newState) {// if nothing has changed , we send update notificationsSet <StateChangeListener > clonedListeners = null;clonedListeners = new CopyOnWriteArraySet <StateChangeListener >( listeners);

for(StateChangeListener listener : clonedListeners) {listener.stateUpdated(this , newState);

}

if(! oldState.equals(newState)) {for(StateChangeListener listener : clonedListeners) {

listener.stateChanged(this , oldState , newState);}

}}

Ci sono casi in cui lo stato degli Item non possiede un valore definito e puòaccadere perchè non sono ancora stati inizializzati (non hanno ancora ricevutoun update dello stato) oppure perchè è ambiguo (una luce dimmerabile trattatacome Switch Item e impostata a un valore ad esempio del 50%) e quindi, perquesti casi viene definito UnDefType che può avere due valori UNDEF e NULL(non ancora inizializzato).La quasi interezza dei Type definiti appartengono alla categoria dei Primiti-veType tra i quali ci sono classi enum che possono accettare solo due valori(OnOffType, OpenClosetype, UpDownType e StopMoveType) e altre più com-plesse come DecimalType, derivata dalla classe Java Number e Comparable,che internamente utilizza un Java BigDecimal e quindi può essere utilizzataindistintamente per valori integer, long e di tipo floating point.Direttamente da DecimalType deriva PercentType (utilizzata ad esempio peresprimere grandezze tipo il volume di uno stereo) che può assumere valori tra 0 e

118


temp


«interface»ComplexType

+getConstituents(): SortedMap

«enumeration»EventType

«interface»PrimitiveType «interface»

State

«interface»Type

+format(pattern: String): String

«enumeration»UnDefType

«enumeration»OnOffType

«enumeration»OpenClosedType

«enumeration»UpDownType

«enumeration»StopMoveType

DecimalType

StringType

DateTimeType

PointType

PercentTypeHSBType

Number

Comparable

Figura 4.32: openHAB Types Model

100 e una ulteriore classe, di tipo ComplexType, chiamata HSBType utilizzataper esprimere i colori (Hue-Saturation-Brightness). Proprio perchè HSBType èuna ComplexType la grandezza che esprime può essere scomposta in più valorie allora si capisce come questo tipo può essere espresso con un valore che va da0 a 360 per Hue e da 0 a 100 per Saturation e Brightness.A parte, rispetto a tutto questo discorso, si trova la classe EventType. Tale clas-se è stata introdotto in quanto alcuni Type possono essere indifferentemente siaState che Command e allora, quando un messaggio viene pubblicato sull’eventbus, è necessario un modo per distinguere i significato del messaggio: quando

119

4 Caso di Studio

osservo “<item> ON” intendo che il suo stato è cambiato in ON oppure chedeve essere azionato a ON? Per decidere si invia questa informazione aggiuntivasull’event bus per ogni messaggio.

Gli Item, i Type e lo State

Tornando al discorso precedentemente interrotto sugli Item si nota come tuttauna serie di classi derivi da una base comune astratta data da GenericItem.Tutti i tipi di Item contengono definita staticamente al loro interno la listadi State e Command che possono accettare ovvero quali tipi di informazionipossono essere salvate al loro interno e quali comandi possono essere inviati dalparticolare Item.Allora ad esempio uno SwitchItem accetta dei dati di tipo OnOffType e Un-DefType mentre può inviare comandi del tipo OnOffType.

Algoritmo 4.4 SwitchItem static initialization

private stat ic List<Class <? extends State>> acceptedDataTypes =new ArrayList<Class <? extends State >>() ;

private stat ic List<Class <? extends Command>> acceptedCommandTypes =new ArrayList<Class <? extends Command>>() ;

stat ic {acceptedDataTypes . add (OnOffType . class ) ;acceptedDataTypes . add (UnDefType . class ) ;acceptedCommandTypes . add (OnOffType . class ) ;

}

Quindi, sebbene sembri quasi che ad ogni particolare Item sia associato unparticolare Type, in realtà la situazione è un pò più articolata e si può notarecome lo stato di un Item possa variare liberamente in un range di valori definitodal particolare Type associato al valore che si intende memorizzare.

EventPublisher

L’architettura di openHAB viene connessa all’Event Bus tramite due interfacceappartenenti al framework OSGi: EventAdmin e EventHandler. EventAdmin èun servizio col quale, una volta registrati, viene permesso di pubblicare eventisia in modo sincrono che asincrono mentre EventHandler consente, agli oggetti

120


org.openhab.model.sitemap

org.openhab.core

org.openhab.model.rule

org.openhab.core.library

org.openhab.model.item

org.openhab.model.core

FolderObserverModelRepositoryImplManagedService

GenericBindingProvider

EventAdminItemRegistryImpl

EventHandler

CoreItemFactory

ItemRegistry

EventPublisher

RuleEngine

ItemFactory

ItemUpdater

ModelRepository

ItemProvider

SitemapProviderImpl

SitemapProvider

BindingConfigReader

org.openhab.binding.homeplc

HomePLCBindingHomePLCGenericBindingProvider

HomePLCBindingProvider

EventPublisherImpl

EventHandler

EventHandler

OSGi

Figura 4.33: openHAB Component Diagram

che implementano tale interfaccia e si registrano al Framework service registry,di ricevere notifiche con un Event object quando tale evento è stato inviato.openHAB estende queste interfacce includendo i concetti di State e Commandche abbiamo visto in precedenza.Come avevamo visto occorre distinguere il tipo di openHAB Event da inviaresul bus altrimenti non saprei come trattare un evento: come comando o comeaggiornamento di stato.Per risolvere questo problema prima di inviare un evento la classe EventPubli-sher prepara il tipo di evento e lo confeziona componendo il parametro Topicdell’Evento OSGi con opportune stringhe di testo. Ovviamente due sono i casipossibili:

• openhab/command/<item-name>

121

4 Caso di Studio

Algoritmo 4.5 openHAB EventPublisher internals

public interface EventConstants {public static final String TOPIC_PREFIX = "openhab";public static final String TOPIC_SEPERATOR = "/";

}

public class EventPublisherImpl implements EventPublisher {

//...

private Event createUpdateEvent(String itemName , State newState) {Dictionary <String , Object > properties = new Hashtable <String , Object >();properties.put("item", itemName);properties.put("state", newState);return new Event(createTopic(EventType.UPDATE , itemName), properties);

}

private Event createCommandEvent(String itemName , Command command) {Dictionary <String , Object > properties = new Hashtable <String , Object >();properties.put("item", itemName);properties.put("command", command);return new Event(createTopic(EventType.COMMAND , itemName) , properties);

}

private String createTopic(EventType type , String itemName) {return TOPIC_PREFIX + TOPIC_SEPERATOR + type + TOPIC_SEPERATOR + itemName;

}}

• openhab/update/<item-name>

Inserendo sia il tipo di evento che il nome dell’Item che ha generato il comando(o a cui è destinato l’aggiornamento di stato) è facile immaginare che, da qualcheparte, ci sia del codice che applica opportune regole di filtraggio.

ItemRegistry

L’ItemRegistry è il luogo centrale in cui gli Item vengono memorizzati e il lorostato viene continuamente monitorato. Qualsiasi parte di codice che richiede lostato corrente di un Item dovrebbe utilizzare questo servizio anzichè mantenereuna propria copia locale.I vari Item vengono registrati tramite gli ItemProvider, elemento che può gene-rarli ricavandoli da una una opportuna sorgente (ad es. un file esterno) e inoltrepossono aggiungerli e rimuoverli dinamicamente dall’ItemRegistry.

122


AbstractEventSubscriber

+handleEvent(event: Event): void+receiveCommand(itemName: String, command: Command): void+receiveUpdate(itemName: String, newState: State): void

«interface»EventConstants

+TOPIC_PREFIX: String = "openhab" {readOnly}+TOPIC_SEPERATOR: String = "/" {readOnly}



«interface»EventSubscriber

+receiveCommand(itemName: String, command: Command): void+receiveUpdate(itemName: String, newStatus: State): void

EventPublisherImpl

+setEventAdmin(eventAdmin: EventAdmin): void+unsetEventAdmin(eventAdmin: EventAdmin): void+sendCommand(itemName: String, command: Command): void+postCommand(itemName: String, command: Command): void+postUpdate(itemName: String, newState: State): void

«interface»EventHandler

«interface»EventAdmin

Figura 4.34: openHAB link with OSGi EventAdmin Service

L’ItemRegistry aggiunge il riferimento all’EventPublisher ad ogni Item che vieneinserito al suo interno.

ItemRegistryImpl

+activate(componentContext: ComponentContext): void+deactivate(componentContext: ComponentContext): void+getItem(name: String): Item+getItemByPattern(name: String): Item+getItems(): Item[*]+getItems(pattern: String): Item[*]+addItemProvider(itemProvider: ItemProvider): void+isValidItemName(name: String): boolean+removeItemProvider(itemProvider: ItemProvider): void+setEventPublisher(eventPublisher: EventPublisher): void+unsetEventPublisher(eventPublisher: EventPublisher): void+allItemsChanged(provider: ItemProvider, oldItemNames: String[*]): void+itemAdded(provider: ItemProvider, item: Item): void+itemRemoved(provider: ItemProvider, item: Item): void+addItemRegistryChangeListener(listener: ItemRegistryChangeListener): void+removeItemRegistryChangeListener(listener: ItemRegistryChangeListener): void

«interface»ItemRegistry

+getItem(name: String): Item+getItemByPattern(name: String): Item+getItems(): Item[*]+getItems(pattern: String): Item[*]+isValidItemName(itemName: String): boolean+addItemRegistryChangeListener(listener: ItemRegistryChangeListener): void+removeItemRegistryChangeListener(listener: ItemRegistryChangeListener): void

«interface»ItemsChangeListener

+allItemsChanged(provider: ItemProvider, oldItemNames: String[*]): void+itemAdded(provider: ItemProvider, item: Item): void+itemRemoved(provider: ItemProvider, item: Item): void

«interface»ItemProvider

+addItemChangeListener(listener: ItemsChangeListener): void+removeItemChangeListener(listener: ItemsChangeListener): void

*



«interface»ItemRegistryChangeListener

+allItemsChanged(oldItemNames: String[*]): void+itemAdded(item: Item): void+itemRemoved(item: Item): void

*

Figura 4.35: ItemRegistry structure Model

123

4 Caso di Studio

ItemProvider

openHAB permette di definire gli Item in file di testo contenuti all’interno diuna particolare directory del runtime. In tali file sono contenute le definizionidegli Item e la stringa di configurazione del binding che si vuole integrare conopenHAB. Queste definizioni devono rispettare le specifiche definite da dellegrammatiche espresse in EMF.La classe GenericItemProvider realizza l’interfaccia ItemProvider.Quando tramite il servizio ConfigAdmin di OSGi viene rilevato che uno dei file*.items è stato modificato il contenuto del ModelRepository viene aggiornatoe successivamente viene inviata una notifica alla classe GenericItemProviderper ogni modello che è stato modificato. Come modello si intende l’intero file*.items.Ricevuto il nome del modello che è stato modificato GenericItemProvider rimuo-ve le configurazioni contenute nel modello da tutti i BindingConfigReader checonosce e successivamente genera dal nuovo modello preso dal ModelRepositoryuna nuova istanza di tutti gli Item.Creati i nuovi Item, per ognuno di essi, viene chiesto ai BindingConfigReadercorrispondenti di validare il tipo di Item e processarne la configurazione. Nelcaso che venga rilevato qualche problema di incompatibilità o di configurazionel’Item viene scartato.Per concludere vengono notificati tutti gli ItemChangeListener. Tra i listenerovviamente c’è ItemRegistry che provvede a rimuovere tutti gli Item vecchiinseriti dall’ItemProvider e li sostituisce con tutti quelli nuovi appena processati.Si conclude notificando tutti gli ItemRegistryChangeListener.

BindingConfigReader

BindingConfigReader è una interfaccia che viene implementata dai vari Bin-dingProvider che possono essere realizzati da chiunque voglia integrare il propriosistema in openHAB.

124


«interface»ItemProvider

+addItemChangeListener(listener: ItemsChangeListener): void+removeItemChangeListener(listener: ItemsChangeListener): void

GenericItemProvider

«constructor»+GenericItemProvider()+setModelRepository(modelRepository: ModelRepository): void+unsetModelRepository(modelRepository: ModelRepository): void+addItemFactory(factory: ItemFactory): void+removeItemFactory(factory: ItemFactory): void+addBindingConfigReader(reader: BindingConfigReader): void+removeBindingConfigReader(reader: BindingConfigReader): void+getItems(): Item[*]+addItemChangeListener(listener: ItemsChangeListener): void+removeItemChangeListener(listener: ItemsChangeListener): void+modelChanged(modelName: String, type: EventType): void

«interface»BindingConfigReader

+getBindingType(): String+validateItemType(item: Item, bindingConfig: String): void+processBindingConfiguration(context: String, item: Item, bindingConfig: String): void+removeConfigurations(context: String): void

*

«interface»ItemFactory

+createItem(itemTypeName: String, itemName: String): GenericItem+getSupportedItemTypes(): String[*]

*

«interface»ModelRepository

+getModel(name: String): EObject+addOrRefreshModel(name: String, inputStream: InputStream): boolean+removeModel(name: String): boolean+getAllModelNamesOfType(modelType: String): Iterable+addModelRepositoryChangeListener(listener: ModelRepositoryChangeListener): void+removeModelRepositoryChangeListener(listener: ModelRepositoryChangeListener): void

«interface»ItemsChangeListener

+allItemsChanged(provider: ItemProvider, oldItemNames: String[*]): void+itemAdded(provider: ItemProvider, item: Item): void+itemRemoved(provider: ItemProvider, item: Item): void

*

«interface»ModelRepositoryChangeListener

+modelChanged(modelName: String, type: EventType): void

Figura 4.36: ItemProvider structure Model


+getBindingType(): String+validateItemType(item: Item, bindingConfig: String): void+processBindingConfiguration(context: String, item: Item, bindingConfig: String): void+removeConfigurations(context: String): void

Figura 4.37: BindingConfigReader Model

Refactoring di EventGenerator in OSGi bundle

A questo punto abbiamo a disposizione una libreria in grado di interfacciare unipotetico sistema software, scritto in linguaggio Java, con l’hardware domoticofornito dall’azienda NET Building Automation. Due sono le interfacce fornite:la prima, ereditata dal pacchetto originale e lasciata pressochè identica, in gradodi abilitare il driver del dispositivo domotico e di leggere e scrivere i registri diHomePLC e la seconda, progettata ex novo, in grado di generare eventi ogniqualvolta un registro di HomePLC subisce una variazione.

125

4 Caso di Studio

com.netba.homeplc

HomePLC

EventGenerator

Figura 4.38: Componente OSGi

Nell’ottica di un futuro sviluppo per componenti si è voluto aggiungere unafunzionalità in più alla libreria a nostra disposizione inserendo meccanismi ingrado di abilitare il suo utilizzo anche con i framework OSGi.Due sono i servizi forniti dal bundle e corrispondono alle interfacce Java presentinei rispettivi packages. OSGi necessita anche delle classi che implementano idue servizi in quanto il bundle fa anche la parte di service provider.Per permettere ad OSGi di caricare in memoria questi servizi è stato utilizzatoil meccanismo dei Declarative Services: in particolare la definizione del compo-nente per il generatore di eventi è stato impostato in modo tale da richiederela presenza di un servizio HomePLC in modo tale da stabilire una priorità nel-la sequenza di caricamento. Entrambi i componenti vengono immediatamenteattivati.

Struttura openHAB e HomePLCBinding

Col termine Binding si intende il componente di tutta l’architettura open-HAB che viene realizzato per integrare all’interno del sistema un particolaredispositivo, un servizio internet o fino a un intero sistema di home automation.Nell’ottica di realizzare il binding per il sistema HomePLC occorre, come primacosa, considerare quali tipi di informazioni vengono scambiate con openHAB:da questi elementi principali poi si sviluppa tutto il resto del componente.Come abbiamo visto nella descrizione del sistema HomePLC tutti i dispositiviin campo vengono mappati in una tabella di registri contenuta all’interno delcontroller. I dispositivi per gli I/O digitali (contatti optoisolati e relè di co-

126


mando) occupano un bit all’interno dei registri ed ecco spiegato perchè si puòarrivare ad avere Master o Slave I/O anche da 16 ingressi e 16 uscite.

Item state command

ContactItem UnDefType

OpenCloseType

SwitchItem UnDefType

OnOffType

OnOffType

NumberItem UnDefType

DecimalType

DecimalType

DimmerItem UnDefType

OnOffType

PercentType

OnOffType

IncreaseDecreaseType

PercentType

RollershutterItem UnDefType

UpDownType

PercentType

UpDownType

StopMoveType

PercentType

Tabella 4.7: Item per HomePLCBinding

Master speciali e slave analogici possono partizionare le loro aree di input e dioutput in maniera più elaborata: posso avere grandezze esprimibili con valoribooleani ma anche valori interi oppure valori appartenenti a grandezze realie quindi dotate di valori decimali. Ogni dispositivo viene fornito completo ditabella di mappatura dalla quale è possibile ricavare con quanti bit esprimereun valore intero o uno reale opportunamente scalato per farlo rientrare in quellospazio di memoria.Visti i tipi di dato che possono essere elaborati con HomePLC è stato scelto diutilizzare queste corrispondenze:

• Per i valori binari avremo sia i ContactItem che gli SwitchItem

• Per i valori numerici NumberItem e DimmerItem.

Il bundle org.openhab.binding.homeplc è composto da due componenti prin-cipali che consentono di interfacciare il sistema openHAB con il sistema diautomazione HomePLC.

127

4 Caso di Studio

OSGiorg.openhab.binding.homeplc

com.netba.homeplc

HomePLCBinding

EventPublisher

EventHandler

EventPublisherImpl

EventAdmin

HomePLCImpl

HomePLC

EventGeneratorImpl

EventGenerator

HomePLCGenericBindingProvider

BindingConfigReader

HomePLCBindingProvider

Figura 4.39: Relazioni tra EventGenerator e Binding HomePLC

Il componente HomePLCBinding è quello che mantiene il legame vero e propriocon il sistema di automazione e, tramite le interfacce che abbiamo costruito pre-cedentemente, riesce a inoltrare i comandi che provengono dal sistema openHABtrasformandoli in richieste verso l’interfaccia di HomePLC. HomePLCBindingsi comporta anche da observer per il generatore di eventi trasformando tutti glieventi ricevuti in stateUpdate per gli Item; per inoltrare all’Item l’update vienesfruttato l’EventPublisherImpl e l’event bus che abbiamo visto essere il cuoredi tutto openHAB.La classe HomePLCGenericBindingProvider invece implementa l’interfaccia Bin-dingConfigReader e come abbiamo visto in precedenza permette di gestire laconfigurazione dei singoli Item appartenenti al binding HomePLC. Una voltache openHAB rileva una modifica nei file *.items HomePLCGenericBindingPro-

128


vider cerca di validare tutti gli Item per il binding homeplc e successivamentememorizza la configurazione di ognuno. Questa configurazione è importantis-sima per il componente HomePLCBinding perchè determina con esattezza letrasformazioni che vengono applicate sui Command e sugli Update da e per ilbinding homeplc.Quando verrà inviato un Command verso il sistema di automazione tra i para-metri comparirà anche lo stato che vogliamo attivare per quel particolare Item.Il tipo di Item, il tipo del nuovo Stato richiesto e la configurazione ricavata dal-l’HomePLCBindingProvider determineranno le operazioni fatte sull’interfacciaHomePLC.Analogamente quando viene ricevuto un nuovo evento gli Item dell’HomePLC-BindingProvider interessati a quel particolare evento riceveranno uno stateUp-date con un valore determinato dalla particolare natura dell’Item stesso e dalleinformazioni ricavate dalla configurazione ottenuta sempre da HomePLCBin-dingProvider.

129

4 Caso di Studio

org.openhab.core.eventsorg.openhab.core.types

«interface»EventSubscriber

+receiveCommand()+receiveUpdate()

«interface»Type

+format()

«interface»State


org.osgi.service.event

org.openhab.core.binding

«interface»BindingChangeListener

+bindingChanged()+allBindingsChanged()

«interface»BindingProvider

+addBindingChangeListener()+removeBindingChangeListener()+providesBindingFor()+providesBinding()+getItemNames()

AbstractActiveBinding

+execute()

«interface»EventHandler

+handleEvent()

Event

+getTopic()+getProperty()+matches()

org.openhab.binding.homeplc

org.openhab.model.item.binding

HomePLCGenericBindingProvider

HomePLCBinding

+bindHomePLC()+unbindHomePLC()+bindEventGenerator()+unbindEventGenerator()

AbstractGenericBindingProvider

org.oenhab.core.items

«interface»Item

+getState()+getStateAs()+getName()+getAcceptedDataTypes()+getAcceptedCommandTypes()+getGroupNames()


+sendCommand()+postCommand()+postUpdate()

AbstractEventSubscriber

AbstractBinding

+setEventPublisher()+unsetEventPublisher()+activate()+deactivate()+addBindingProvider()+removeBindingProvider()+bindingsExist()

«interface»HomePLCBindingProvider

+getHomePLCResource()

HomePLCBindingConfig


+getBindingType()+validateItemType()+processBindingConfiguration()+removeConfigurations()

«interface»BindingConfig

EventProperties

+...()

com.netbuildingautomation.homeplc

«interface»HomePLC

+initPicDrv()+closePicDrv()+getRunningStatus()+setRunningStatus()+...()

«interface»EventGenerator

+setGeneratorListener()+removeGeneratorListener()+start()+stop()+getEventsStatus()


+onGeneratorEvent()

HomePLCEvent

130

4.4 Ambiente di prova e valutazioni


Figura 4.40: Sistema in uso

Per dare un idea più chiara del risultato ottenuto vediamo di illustrare unaparte del sistema in uso come indicato nella figura.Un router centrale all’abitazione fornisce connettività TCP/IP su cavo ethernete Wi-Fi a diversi dispositivi sparsi per la casa. A questo router sono collega-ti con cavo ethernet l’HomePLC (per il sistema domotico), un Raspberry Pie l’Hub Philips HUE. Sul Raspberry Pi è installato openHAB che controlleràtutto l’impianto di Home Automation mentre l’Hub Philips HUE fa da bridgetramite rete ZigBee per alcune luci sparse nelle varie stanze. Il controller Home-PLC è connesso con bus proprietario a tutti i dispositivi attualmente acquistatiche permettono di rilevare le pressioni dei pulsanti, il comando della tappa-rella, il comando della Ventilazione Meccanica Controllata (Wolf CWL-F-150excellent), le sonde di temperatura e umidità, il dimmer per alcune luci.

131

4 Caso di Studio

Tramite rete wireless sono connessi un ulteriore Raspberry Pi con una in-stallazione di Mosquitto MQTT Broker e alcuni dispositivi Particle Photonprogrammati per la rilevazione di temperatura e umidità tramite sonde DHT22.Sia l’impiando domotico su rete proprietaria HomePLC che il bridge Philipssono integrati in openHAB mediante i binding relativi di cui quello per Home-PLC sviluppato in precedenza. Il broker Mosquitto serve per connettere tramiteprotocollo MQTT i due Photon che rilevano la temperature in alcuni punti adopenHAB su cui è installato un bundle apposito con client MQTT.Inizialmente questa era la configurazione utilizzata in cui openHAB e l’Home-PLC.Linux erano connessi tramite protocollo CoAP in quanto la memoria flashsul dispositivo era limitata e c’erano alcuni problemi ad eseguire openHAB suldispositivo stesso.Tutto l’impianto è comandabile tramite i pulsanti a parete oppure tramite bro-wser web che con app per smartphone e tablet (android e iOS) connessi tramiteWi-Fi oppure da remoto su rete cellulare.

Figura 4.41: Protocolli IoT e openHAB

Inizialmente pensato per un utilizzo personale il progetto ha riscosso un certointeresse in alcuni forum italiani dedicati alla Home Automation favorendonel’adozione anche ad altri interessati.

132


Figura 4.42: Alcune parti dell’interfaccia Android

Figura 4.43: Esempio di grafico di umidità

133

4 Caso di Studio

Attualmente vengono mantenute e distribuite due versioni pensate rispettiva-mente per controller Linux e per Master Web dedicato a installazioni tradizionaliper dispositivi programmabili in standard IEC 1131-3.

Valutazioni

Prima di scegliere il fornitore dell’impianto domotico è stata fatta una disami-na dei sistemi di Home Automation presenti sul mercato e disponibili pressoi fornitori di zona. La prima cosa che val la pena di notare è che quasi tuttigli elettricisti contattati hanno opposto una certa resistenza all’installazione diun impianto domotico. Questo purtroppo rappresenta una situazione ancoraabbastanza diffusa in quanto gli artigiani, che normalmente realizzano impiantielettrici, difficilmente investono parte del loro poco, e prezioso, tempo a dispo-sizione per questo tipo di aggiornamento. Il motivo è da ricercare anche nellaridotta domanda di questo genere di installazioni sintomo, come abbiamo vi-sto, di una certa diffidenza da parte dei proprietari degli appartamenti e moltospesso dei costi generalmente molto elevati.La scelta, alla fine ricaduta sul sistema HomePLC, è dovuta alle particolaricaratteristiche che questo sistema domotico fornisce e, non da ultimo, per larealtà interamente italiana di questa azienda. Il sistema HomePLC garantisce,oltre ai dispositivi programmabili in standard IEC 1131-3, anche un controllerembedded con sistema operativo Linux sufficientemente potente da far giraresenza problemi una macchina virtuale Java.Peculiarità del sistema HomePLC è la possibilità di molti moduli slave di la-vorare autonomamente dovesse mai interrompersi la connessione su bus RS485oppure dovesse bloccarsi il sistema sul controller Linux. Grazie al microcodiceprogrammabile la logica locale del modulo entra in funzione appena rilevatal’interruzione e, se viene mantenuta una cerca corrispondenza fra la cablaturae la programmazione sul controller, permette di raggiungere una modalità disicurezza tale da garantire quasi una funzionalità completa.

134


Sistema Operativo e hardware

Il dispositivo è un embedded con processore i.mx53 ARMv7 della Frescale sucui è installata una versione dedicata di Linux versione 2.6.35.3. Prevedendoche lo sviluppo di software Java avrebbe richiesto qualche risorsa in più è statoacquistata la versione con 1GByte di RAM; purtroppo è sfuggito il dettagliodella memoria flash per sistema operativo e programmi limitata a 256Mbyte.L’idea iniziale era quella di installare il sistema openHAB direttamente sull’em-bedded ma essendo basato su una target release di Equinox abbastanza corposanon c’era sufficiente spazio per contenerlo.Fortunatamente l’embedded è dotato di slot microSD di espansione e successi-vamente è stato possibile aggiungere una notevole quantità di memoria anchese più lenta della flash interna.

Installazione di openHAB

L’installazione di openHAB è molto semplice: è sufficiente scompattare il filedi runtime in una directory. Dopo di che si procede con la programmazione econ l’aggiunta degli addon.Il problema è stato che la versione originale di openHAB dava dei problemi inavvio e quindi si è reso necessario modificare parte dei pacchetti della targetrelease per eliminare alcuni errori che impedivano al sistema di avviarsi. Comeprima cosa occorre scompattare l’archivio con il comando...

tar xzf openhab -2.0.0. alpha2 -runtime.tar.gz

successivamente si devono sostituire i bundles dei pacchetti slf4j e logback

per evitare l’errore...07:03:38 ,130 |-ERROR in ch.qos.logback.core.util.ContextUtil@83df40b - Failed

to get local hostname java.net.UnknownHostException: sdpro: sdpro:

nodename nor servname provided , or not known at java.net.

UnknownHostException :...

Per risolvere l’errore si devono utilizzare le versioni 1.0.13 di logback e 1.7.5 dislf4j.

135

4 Caso di Studio

Solo sostituendo i pacchetti con le versioni più aggiornate non è sufficiente, oc-corre far capire al framework OSGi equinox che sono stati sostituiti dei bundles.Per fare questo non resta che modificare i files

<openhab_dir >/ runtime/server/artifacts.xml

<openhab_dir >/ runtime/server/configuration/config.ini

cancellando le voci relative alle vecchie versioni di logback e di slf4j sosti-tuendole con le nuove

<artifacts size=’140’>

...

<artifact classifier=’osgi.bundle ’ id=’slf4j -api ’ version =’1.7.5’ />

<artifact classifier=’osgi.bundle ’ id=’logback -classic ’ version =’1.0.13 ’ />

<artifact classifier=’osgi.bundle ’ id=’logback -core ’ version =’1.0.13’ />

<artifact classifier=’osgi.bundle ’ id=’jul -to -slf4j ’ version =’1.7.5’ />

<artifact classifier=’osgi.bundle ’ id=’log4j -over -slf4j ’ version =’1.7.5’ />

<artifact classifier=’osgi.bundle ’ id=’jcl -over -slf4j ’ version =’1.7.5’ />

...

</artifact >

dove il parametro size deve essere modificato da 141 a 140 in quanto le librerielogback di versione 1.0.13 non comprendono più il bundlech.qos.logback.slf4j_1.0.13 e

...

osgi.bundles=reference \:file\:logback -classic_1 .0.13. jar@1\:start ,reference \:

file\:logback -core_1 .0.13. jar@1 \:start ,..., reference \:file\:slf4j -api_1

.7.5. jar@4 ,reference \:file\:jcl -over -slf4j_1 .7.5. jar@4 ,reference \:file\:

jul -to -slf4j_1 .7.5. jar@4 ,reference \:file\:log4j -over -slf4j_1 .7.5. jar.

jar@4

...

dove i punti di sospensione indicano che potrebbero esserci altre righe di codice(trascurabili).

Problemi iniziali

La libreria nativa per l’interazione del linguaggio Java con il sistema domoticopresentava una limitazione dovuta probabilmente alla poca dimestichezza conquesto linguaggio in quanto l’unica possibilità di richiamare i metodi natividella classe di interfaccia era inserendo tutte le classi nel default package.

136


Come è possibile notare dal progetto si è dovuto ricorrere allo strumento dellaJava Reflection per accedere alle classi del default package e creare una classeproxy per nascondere il problema al resto del sistema che finalmente potevaessere strutturato al meglio.

Generatore di eventi

La tabella delle risorse HomePLC contiene 8000 registri da 16 bit e l’unicometodo disponibile di default e quello che permette di leggere un registro allavolta.Per generare quello che abbiamo chiamato eventi la libreria inizialmente, ancheper testare i tempi richiesti, effettuava una lettura di tutti e 8000 i registriimpiegando generalmente tra i 50 e i 60 msec (compresi i confronti registro perregistro).Bisogna ammettere che il tempo richiesto non è molto confortante soprattuttoperchè in questi 50 msec il tempo impiegato non comprendeva che pochi eventirealmente emessi. Infatti i test riguardavano la pressione di un paio di pulsantie, nonostante i pochi eventi, il carico della cpu raggiungeva tranquillamente il50% di picco. Inoltre il periodo di lettura era stato impostato a 100 msec quindirimaneva veramente poco tempo per l’inoltro degli eventuali eventi col rischioritardi sul ciclo di lettura successivo.Per ottimizzare le prestazioni del generatore si è ridotto la lettura degli 8000registri alle due aree realmente necessarie: l’area real-time e l’area estesa. Vi-sto che nel sistema HomePLC non erano presenti particolari dispositivi cherichiedevano altre aree a disposizione l’ottimizzazione è risultata assolutamenteidonea.Così facendo il tempo di lettura di questi nuovi 1000 registri richiedeva untempo che oscillava tra i 6 e i 15 msec e un carico del processore limitato al 2%.Tutti questi test inoltre sono stati effettuati con una cpu da 1 GHz quindi conprocessori meno potenti i risultati potrebbero essere ancora più sconfortanti.

137

4 Caso di Studio

Ottimizzazione con codice nativo

Occorreva quindi trovare una soluzione a questa situazione altrimenti tutto ilprogetto si sarebbe fermato. L’unica alternativa era ottimizzare il codice dellagenerazione degli eventi realizzandolo in C successivamente richiamare metodidi callback in Java per la consegna degli eventi.Il problema è stato predisporre l’intero ambiente di produzione con tutto ilnecessario per la cross-compilazione in quanto non fornito ufficialmente dalladitta. C’è voluto molto tempo per impostare un progetto eclipse CDT conle giuste librerie e i parametri per il tipo di cpu ma alla fine, mediante unamacchina Linux con ubuntu e i pacchetti gcc-arm-linux-gnueabi, si è riuscito agenerare il primo eseguibile per l’embedded in questione.Dai primi test effettuati la lettura dei 1000 registri e il relativo confronto im-piegava ora 200usec, esattamente due ordini di grandezza in meno, mantenendoun carico della cpu al 1%.Visto che è stato messo mano al codice nativo tanto valeva fare in modo da eli-minare l’accesso tramite Java Reflection e quindi ottimizzare ancora di più l’ac-cesso al codice nativo. Con questa ulteriore ottimizzazione la lettura e confrontodei 1000 registri impiegava in media 60usec con picchi sporadici sui 100usec. Lachiamata al metodo di callback Java si attestava sui 500usec ognuna.

138

5 Conclusioni

Lo scopo di questo lavoro è stato quello di sfruttare concretamente le tecnologieche ha reso disponibili lo sviluppo della IoT calate in un contesto reale di HomeAutomation.Uno dei problemi che hanno sempre mostrato i sistemi di Home Automation, eche ne hanno sempre limitato l’adozione, é sicuramente l’alto costo di acquistoe installazione unito ai successivi costi di manutenzione nel caso di problemi odi aggiornamenti.La spinta che la IoT ha fornito al mercato dei dispositivi per il confort, la sicu-rezza e la gestione degli automatismi in ambito residenziale ha permesso la com-parsa di numerosi dispositivi, dal prezzo più contenuto, dotati di connessionead internet e di relativi servizi basati su cloud.Queste soluzioni però creano applicazioni verticali che poco hanno a che vederecon gli scenari di integrazione orizzontale che la IoT promette di raggiungere.Al fine di dotare la propria abitazione di un sistema domotico aperto, program-mabile, espandibile e dai bassi costi di manutenzione si è pensato di realizza-re un personale sistema di Home Automation basato interamente su softwareopensource e quindi limitando alle sole componenti hardware i costi sostenuti.Dopo una iniziale realizzazione di un sistema domotico di test, per valutarela bontà dell’implementazione ottenuta modificando le librerie di base fornitedal sistema domotico proprietario, si è realizzato il vero componente di inte-grazione tra il sistema di Home Automation tradizionale e openHAB; siste-ma di integrazione indipendente dalla particolare piattaforma e protocollo dicomunicazione.L’utilizzo di openHAB, del framework OSGi e i sorgenti delle librerie che il

139

5 Conclusioni

controller del sistema di automazione rende disponibili ha consentito di rag-giungere un risultato di integrazione dotato di notevole flessibilità. Se da unlato è possibile controllare ogni piccolo dettaglio del sistema domotico proprie-tario dall’altro è possibile anche integrare uno qualunque dei sistemi presenti acatalogo del sistema openHAB. Il fatto notevole, che deriva direttamente dallepotenzialità di OSGi, è di avere a disposizione un sistema modulare e apertoin cui servizi, dispositivi e interi sistemi possono entrare e uscire liberamentemostrando chiaramente la flessibilità fornita da queste tecnologie.Il sistema così realizzato è stato installato nella propria abitazione e da diversimesi è in funzione regolarmente senza interruzione ricevendo comandi in localee da remoto tramite le app per i principali sistemi mobile. Inoltre sono statiintegrati più dispositivi e apparecchiature di fornitori differenti sfruttando ilsistema openHAB e le tecnologie peculiari della IoT.A riprova del risultato ottenuto e le particolarità di questa soluzione di HomeAutomation, il produttore del sistema domotico utilizzato come piattaformahardware, ne ha espresso la sua valutazione favorevole e il suo interesse autoriz-zando a fornire una qualche forma di supporto, sui forum di assistenza ufficiali,a chiunque sia intenzionato a installare tale prodotto sui dispositivi dell’azienda.Ciò che manca in questa trattazione, che rimane comunque di fondamentaleimportanza, è l’aspetto trasversale della sicurezza nella IoT e nelle relativeapplicazioni. Ad ogni modo la soluzione realizzata sfrutta gli strumenti fornitidal sistema openHAB e gli strumenti adottati dai dispositivi che fornisconoconnettività all’intera abitazione ma manca un’analisi dettagliata degli aspettirelativi alla sicurezza di questo sistema.Inoltre sarebbe stato interessante mostrare i vantaggi che si possono ottenereadottando una soluzione di questo tipo analizzando e valutando scenari in cui,dati alla mano, risulti un reale vantaggio in termini di risparmio economicooppure di consumo.

140

Bibliografia

[1] Ala Al-Fuqaha, Mohsen Guizani, Mehdi Mohammadi, Mohammed Ale-dhari, and Moussa Ayyash. Internet of Things: A Survey on EnablingTechnologies, Protocols and Applications. IEEE Communications Surveys& Tutorials, PP(99):1–1, 2015.

[2] Luigi Atzori, Antonio Iera, and Giacomo Morabito. The Internet of Things:A survey. Computer Networks, 54(15):2787–2805, 2010.

[3] N Bartlett. OSGi In Practice. Bd January, 11:229, 2009.

[4] Len Bass, Paul Clements, and Rick Kazman. Software Architecture inPractice Third Edition. Addison-Wesley Professional, 2012.

[5] Simon Bennet, John Skelton, and Ken Lunn. UML. McGraw-HillEducation, 2001.

[6] Joshua Bloch. Effective Java? Addison-Wesley Professional, 2008.

[7] Frank Buschmann, Kevlin Henney, and Douglas C. Schmidt. Pattern-Oriented Software Architecture, Volume 4: A Pattern Language forDistributed Computing. Number 1. John Wiley & Sons, 2014.

[8] F Bushmann, Regine Meunier, Hans Rohnert, Frank Buschmann, RegineMeunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. Pattern-oriented software architecture: A system of patterns, volume Vol. 1. JohnWiley & Sons, 1996.

[9] Kirk Chen and Li Gong. Programming Open Service Gateways with JavaEmbedded Server(TM) Technology. Addison-Wesley Professional, 2001.

141

Bibliografia

[10] S Cirani, M Picone, and L Veltri. mjCoAP: an open-source lightweightJava CoAP library for internet of things applications. . . . and Open-SourceSolutions for the Internet of . . . , 2015.

[11] Cisco and Dave Evans. Internet of Things L ’ Internet delle cose Tuttocambierà con la prossima era di Internet. 2011.

[12] Ian Darwin. Java Cookbook, 3rd Edition. O’Reilly Media, Inc., 2014.

[13] Simon Duquennoy, Gilles Grimaud, Jean-jacques Vandewalle, and Jean-jacques Vandewalle The. The Web of Things : interconnecting devices withhigh usability and performance To cite this version : The Web of Things :interconnecting devices with high usability and performance. 2009.

[14] Ira R. Forman, Nate Forman, Dr John Vlissides Ibm, Ira R. Forman, andNate Forman. Java Reflection in Action. Manning Pubns Co, 2004.

[15] David Gann, James Barlow, and Tim Venables. Digital Futures: makinghomes smarter. 1999.

[16] Brian Göetz and Addison Wesley Professional. Java Concurrency InPractice, volume 39. Addison-Wesley Professional, 2006.

[17] Software Guide. Java NIO, volume 8. O’Reilly Media, Inc., 2009.

[18] Dominique Guinard, Vlad Trifa, Friedemann Mattern, and Erik Wilde.5 From the Internet of Things to the Web of Things : Resource OrientedArchitecture and Best Practices. Architecting the Internet of Things, pages97–129, 2011.

[19] R Harper. Inside the Smart Home, volume 5. 2003.

[20] I Jacobson, M Christerson, P Jonsson, and G Overgaard. Object-OrientedSoftware Engineering: A Use Case Driven Approach. In HarlowEssexEngland Addison, volume 2640, page 552. Addison-Wesley Pub (Sd), 1992.

142

Bibliografia

[21] Wolfgang Kastner, Georg Neugschwandtner, Stefan Soucek, and H. Mi-chael Newman. Communication systems for building automation andcontrol. In Proceedings of the IEEE, volume 93, pages 1178–1203, 2005.

[22] Kirk Knoernschild. Java Design: Objects, UML, and Process. Addison-Wesley Professional, 2001.

[23] C Larman. Applying {UML} and Patterns: An Introduction to Object-Oriented Analysis and Design. Prentice Hall, 2001.

[24] Sheng Liang. Java Native Interface: Programmer’s Guide andSpecification, The. Addison-Wesley Professional, 1999.

[25] Francesco Luciani. Analisi delle tecnologie di supporto alla domotica e allalocalizzazione in un contesto di utenti mobili, 2006.

[26] Jeff McAffer, Paul VanderLei, and Simon Archer. OSGi And Equinox.Addison-Wesley Professional, 2010.

[27] Antonio Natali. Costruire sistemi software: dai modelli al codice.Esculapio, 2012.

[28] Luca Ricci. Mettiamo i sistemi domotici a confronto.

[29] Pietro Antonio Scarpino. Domotica e Building Automation.

[30] Robert Simmons. Hardcore Java. Number 0. O’Reilly Media, Inc., 2004.

[31] Luca Vetti Tagliati. UML. Tecniche Nuove, 2003.

[32] Deze Zeng, Song Guo, and Zixue Cheng. The Web of Things: A Survey(Invited Paper). Journal of Communications, 6(6):424–438, 2011.

143

IoT e progettazione di sistemi di Home Automation: un caso ... · mai datata e economicamente...

Documents

Transcript of IoT e progettazione di sistemi di Home Automation: un caso ... · mai datata e economicamente...