Facoltà di Ingegneria dell'Informazione - elite.polito.itelite.polito.it/files/thesis/fulltext/cetad.pdf · 2.4.2 Web Server 49 2.4.2.1 Software forniti da Bticino 52 2 ... Schema

POLITECNICO DI TORINO

Facoltà di Ingegneria dell'Informazione

TESI DI LAUREA

Architetture ed applicazioni per servizi domotici su piattaforma TV digitale

Relatori: Prof. Fulvio Corno Prof. Giovanni Malnati Prof. Davide Quaglia Candidati: Amen Mauro Arena Pasquale Brizzi Paolo

Aprile 2004

Ringraziamenti

Si desidera porgere un ringraziamento a tutte le persone che hanno

messo a disposizione il loro tempo per rendere possibile la realizzazione di

questo progetto, una fra tutte il prof. Fulvio Corno, per i consigli illumi-

nanti, la pazienza e la cortesia dimostrate nel corso dello svolgimento di

questa tesi.

Indice

INDICE DELLE FIGURE 5 INTRODUZIONE 9 CAPITOLO 1 LA CASA DOMOTICA 16

1.1 COS’È LA DOMOTICA 16 1.2 L’EVOLUZIONE DELLA DOMOTICA 18 1.3 L’IMPORTANZA DELL’AUTONOMIA 21 1.4 DESTINATARI 23 1.5 2003: ANNO EUROPEO DELLE PERSONE DISABILI 23

1.5.1 L’impegno europeo 25 1.6 REALTÀ E PREGIUDIZI 27 1.7 IL C.E.T.A.D. 27

1.7.1 Obiettivi 28 1.7.2 Servizi 29 1.7.3 Attività 30 1.7.4 Casa intelligente dimostrativa 31

CAPITOLO 2

SISTEMA D’AUTOMAZIONE DOMESTICA 33 2.1 L’IMPIANTO MYHOME BTICINO 33 2.2 PRINCIPIO DI FUNZIONAMENTO 36

2.2.1 Configurazione dei dispositivi 39 2.2.2 Vantaggi dell’impianto a BUS 43

2.3 GESTIONE LOCALE DELL’IMPIANTO TRAMITE PERSONAL COMPUTER 43 2.4 GESTIONE REMOTA DELL’IMPIANTO 45

2.4.1 Gestione da telefono 46 2.4.1.1 PABX 46 2.4.1.2 Comunicatore telefonico 46

2.4.2 Web Server 49 2.4.2.1 Software forniti da Bticino 52

2.5 IL PROTOCOLLO “OPEN” 54 2.6 TECNOLOGIE DI AUTOMAZIONE DOMESTICA ALTERNATIVE 58

2.6.1 Tecnologia LONWORKS® di Echelon 58 2.6.2 Il sistema CONTATTO di DUEMMEGI 60

Indice

CAPITOLO 3 TV DIGITALE TERRESTRE 62

3.1 LA TV DIGITALE TERRESTRE 62 3.1.1 La situazione Europea 64 3.1.2 Digitale terrestre in Italia 65

3.2 DVB – DIGITAL VIDEO BROADCASTING 67 3.3 LA PIATTAFORMA MHP 69 3.4 TECNOLOGIE DI DISTRIBUZIONE DVB-T 70

3.4.1 Playout 73 3.4.2 Rete di distribuzione 74 3.4.3 Rete di diffusione 75

3.4.3.1 Hardware delle reti di diffusione 75 3.4.3.2 SFN 76 3.4.3.3 MFN 78 3.4.3.4 k-SFN 79

3.4.4 Sistemi di ricezione d’utente 79 3.5 ARCHITETTURA BASE DELLA PIATTAFORMA MHP 80

3.5.1 Applicazioni 81 3.5.2 Software di sistema 83 3.5.3 Risorse e periferiche 84 3.5.4 API - Java TV 84 3.5.5 Plug–in 87

3.6 PROFILI 87 3.6.1 Enhanced Broadcast – Livello 1 88 3.6.2 Interactive Broadcast – Livello 1 89 3.6.3 Internet Access – Livello 1 91

3.7 SET TOP BOX 93 3.7.1 Architettura 93

3.7.1.1 Funzionalità hardware e firmware 95 3.7.1.2 Front-end 95 3.7.1.3 Demultiplexer MPEG-2 96 3.7.1.4 Video Decoder MPEG–2 96 3.7.1.5 Decoder audio 97 3.7.1.6 Sincronismo audio video 97 3.7.1.7 Unità di controllo 97 3.7.1.8 Bootloader 98 3.7.1.9 Funzionalità grafiche 98 3.7.1.10 Interfacce e livelli di segnale 99 3.7.1.11 Software e servizi 100 3.7.1.12 Navigatore 100 3.7.1.13 Requisiti minimi 100

3.8 TELECOMANDO 101 3.9 APPLICAZIONE MHP – DVB J 102

3.9.1 Service Context – Lifecycle 103 3.9.2 Xlet – modello applicazioni 103

Indice

CAPITOLO 4 REALIZZAZIONE DI UN’INTERFACCIA DOMESTICA SU PC 111

4.1 OBIETTIVI 111 4.1.1 Accessibilità ed usabilità 112

4.2 SCELTE PROGETTUALI 114 4.3 SIMULATORE SISTEMA TELEVISIVO 116 4.4 INTERFACCIA UTENTE 118

4.4.1 Requisiti 118 4.4.2 Messaggi pilota 118 4.4.3 Immagine televisiva 120 4.4.4 Menu 120

4.4.4.1 Massima semplicità 120 4.4.4.2 Struttura su due livelli 121 4.4.4.3 Voci del menù 121 4.4.4.4 Icone 122

4.5 REALIZZAZIONE DEL SIMULATORE 124 4.6 REALIZZAZIONE DELL’INTERFACCIA UTENTE 127

4.6.1 Layout 127 4.6.2 Layout del menù 131 4.6.3 Personalizzazione 133 4.6.4 Ascoltatori del telecomando 136

4.6.4.1 Superclasse Gestore_action 137 4.6.4.2 Sottoclassi di ascolto 140

CAPITOLO 5 INTERAZIONE DELL’INTERFACCIA CON L’IMPIANTO DOMOTICO 143

5.1 PREMESSA 143 5.2 OBIETTIVI 144 5.3 SCELTE PROGETTUALI 144

5.3.1 Connessione HTTP 146 5.4 CONNESSIONE TCP 148

5.4.1 Procedura di login 149 5.4.2 Gestione della connessione 150 5.4.3 Interrogazioni 151 5.4.4 Comandi 157 5.4.5 Analisi dei tempi 160

CAPITOLO 6 REALIZZAZIONE DELL’INTERFACCIA DOMESTICA SU SET TOP BOX 163

6.1 INTRODUZIONE 163 6.2 AUTHORING TOOL 164

6.2.1 Cardinal Studio 165

Indice

6.3 CREAZIONE DELL’APPLICAZIONE – XLET 166 6.3.1 Descrizione degli act 166

6.3.1.1 Application – Master Act 166 6.3.1.2 Act 1 (Immagine televisiva con piccola finestra di comunicazione) 167 6.3.1.3 Act 2 (Menù principale) 169 6.3.1.4 Act 3 (Cucina) 170 6.3.1.5 Act 4 – Act 5 – Act 6 – Act 7 171 6.3.1.6 Act 8 (Scenari) 173 6.3.1.7 Visualizzazione dell’applicazione mediante emulatore 173

6.4 PROBLEMI RISCONTRATI E RISOLTI 176 6.5 TRASMISSIONE DELL’APPLICAZIONE SU STB 177

6.5.1 STB - prestazioni 181

CAPITOLO 7 VALUTAZIONI TECNICHE E CONSIDERAZIONI 182

7.1 REALIZZAZIONE DELL’APPLICAZIONE E TRASFERIMENTO SU STB 182 7.2 CONNESSIONE STB – IMPIANTO DOMOTICO 183 7.3 CONFIGURAZIONE DELL’APPLICAZIONE 184

CONCLUSIONI 185

APPENDICE

BIBLIOGRAFIA

Indice delle figure Figura 1 Schema di principio dell’obiettivo finale 12

Figura 1.1. Requisiti della casa intelligente 17

Figura 1.2. Ambienti funzionali della domotica 20

Figura 1.3. Piano operativo – Domotica 22

Figura 1.4. Casa intelligente dimostrativa – Cucina 32

Figura 1.5. Casa intelligente dimostrativa – Bagno 32

Figura 2.1. Impianto tradizionale 34

Figura 2.2. Impianto tipo BUS 35

Figura 2.3. Dispositivo di comando 36

Figura 2.4. Dispositivo attuatore 37

Figura 2.5. Schema funzionale di un impianto di tipo BUS 37

Figura 2.5. Schema funzionale di un impianto di tipo BUS 38

Figura 2.7. Sistemi di comando dell’impianto 39

Figura 2.8. Esempio di configuratori 40

Figura 2.9. Configurazione 41

Figura 2.10. Collegamento diretto tra PC e BUS 44

Figura 2.11. Sinottico della casa – dettaglio della cucina 45

Figura 2.12. Gestione remota della casa mediante centralino

telefonico

47

Figura 2.13. Esempio di impiego – Gestione allarmi 48

Figura 2.14. Esempio di impiego – Allarme tecnico 48

Figura 2.15. Gestione tramite web-server 49

Figura 2.16. Sequenza operazioni da effettuare 51

Figura 2.17. TiWeb, applicativo per la configurazione del

web server

52

Indice delle figure

Figura 2.18. SCS Virtual Switch 53

Figura 2.19. Gestione di più impianti My Home diversi - uti-

lità dell’applicativo SCS Action Server

54

Figura 2.20. Passi per l’accesso e la comunicazione con

l’impianto SCS

56

Figura 2.21. Comunicatore telefonico – Accesso all’impiant 57

Figura 2.22. Web Server – Accesso all’impianto 57

Figura 3.1. Aspetti tecnologici che concorrono nella piatta-

forma digitale

69

Figura 3.2. Protocolli supportati per il canale broadcast 71

Figura 3.3. Modello di architettura di una rete DVB-T 73

Figura 3.4. Schema generale del Playout 74

Figura 3.5. Modello di diffusione SFN 77

Figura 3.6. Modello di diffusione MFN 77

Figura 3.7. Architettura funzionale del terminale MHP 81

Figura 3.8. Interfacce tra applicazioni MHP ed il sistema 82

Figura 3.9. Architettura del software di sistema 83

Figura 3.10. Livelli architetturali del Java TV 86

Figura 3.11. Plug-in previsti dalla specifica MHP 88

Figura 3.12. Profili e livelli MHP 89

Figura 3.13. Protocolli supportati per il canale interattivo 91

Figura 3.14. Architettura del set-top-box 93

Figura 3.15. Architettura del set-top-box - dettagli 94

Figura 3.16. Macchina a stati di una Xlet 110

Figura 4.1. Definizione di interfaccia utente 116

Figura 4.2. Simulatore sistema televisivo 117

Figura 4.3. Messaggi pilota 119

Figura 4.4. Struttura gerarchica dell’interfaccia 122

Figura 4.5. Menù – primo livello 123

Figura 4.6. Menù – secondo livello – ambiente cucina 124

Indice delle figure

Figura 4.7. Menù – icone 124

Figura 4.8. Simulatore televisivo - layout schermo 128

Figura 4.9. Struttura dell’oggetto Video_room 132

Figura 4.10. Struttura della base dati 134

Figura 4.11. Versione dell’applicazione per persone con di-

sturbi di percezione cromatica

136

Figura 4.12. Associazione dinamica tasto – operazione 137

Figura 4.13. Macchina a stati degli ascoltatori 141

Figura 4.14. Tapparelle- selezione 142

Figura 4.15. Tapparelle- comando UP 142

Figura 5.1. Interazione tra interfaccia e impianto 145

Figura 5.2. Relazione ascoltatori / processo 152

Figura 5.3. Evoluzione del processo Alert 159

Figura 5.4. Web Server TEST – ciclo di comandi 161

Figura 6.1. Master Act 167

Figura 6.2. Act 1 168








Figura 6.10. Emulazione- prima schermata 174

Figura 6.11. Emulazione- seconda schermata 174

Figura 6.12. Emulazione- terza schermata 175

Figura 6.13. Emulazione- settima schermata 175

Figura 6.14. Caricamento dell’applicazione su STB 177

Figura 6.15. Avvio applicazione 178

Figura 6.16. Menù ottenuto alla pressione del tasto rosso 178

Indice delle figure

Figura 6.17. Menù cucina 179

Figura 6.18. Menù bagno 179

Figura 6.19. Menù camera 180

Figura 6.20. Menù scenari 180

Introduzione La tecnologia è sempre più parte integrante della vita quotidiana ma l’idea della “casa intelligente” sembra non suscitare il riscontro che da an-ni si attende. Eppure, il fascino che l’innovazione tecnologica produce sul consumatore è indubbio: è sufficiente analizzare il grado di diffusione del cellulare, la tendenza ad acquistare prodotti sempre più innovativi e a do-tarsi di soluzioni che agevolano le azioni del vivere comune. I sistemi di automazione domestica introducono una concezione nuova dello spazio abitativo alla quale deve corrispondere la capacità del sistema di modificarsi ed evolvere a fronte delle mutate esigenze dell’utente o di nuove/diverse necessità impiantistiche. Obiettivo della domotica è rendere semplice l’utilizzo di tecnologie complesse; un esempio chiave è lo sviluppo di quelle realizzazioni che of-frono un notevole miglioramento alle condizioni di vita di anziani e disabi-li, tra le quali rientrano applicazioni riguardanti la sicurezza antintrusiona-le e ambientale, il comfort, la gestione dell’impianto elettrico e molto al-tro. Gli strumenti presenti attualmente sul mercato, nella maggior parte dei casi, sfruttano l’intelligenza di un personal computer; questo rappre-senta una limitazione, in quanto oggetto invasivo e di difficile utilizzo nel caso di utenti particolari con problematiche specifiche; un modo plausibile

Introduzione

Politecnico di Torino 10

per risolvere il problema dell’interfaccia domotica potrebbe essere l’utilizzo della televisione, oggetto estremamente familiare, di facile utiliz-zo e presente in tutte le abitazioni. La concezione del televisore finora avu-ta è quella di oggetto passivo, privo di intelligenza, adattabilità, integrabi-lità. Da pochi anni questa idea non corrisponde più al vero, in quanto, con la distribuzione della nuova tecnologia digitale terrestre il televisore può potenzialmente rappresentare uno strumento simile al personal computer in termini di funzionalità. Sin dalla seconda metà degli anni novanta, in particolare con la mi-grazione dall’analogico al digitale, l’industria televisiva ha iniziato una convergenza verso obiettivi comuni a quelli dell’industria informatica; questo processo ha fatto sì che sorgessero alcune problematiche comuni, inducendo i rispettivi addetti ai lavori a parlare linguaggi tra loro più simi-li. Il Consorzio DVB (Digital Video Broadcasting), nel 1997, ha dato inizio ad un progetto che si occupasse di tale problema, individuandone la soluzione nella realizzazione della specifica MHP (febbraio 2000). Tale specifica è stata assunta come standard ETSI, focalizzandosi sui servizi digitali, terrestri e satellitari, e sui Set-Top-Box quale prima implementa-zione pratica del terminale domestico. L’MHP (Multimedia Home Platform), tradotto letteralmente come piattaforma domestica multimediale, permette l’accesso a servizi multime-diali di nuova generazione; la sua caratteristica peculiare è quella della versatilità intesa non solo come capacità di adempiere in modo adeguato alle funzionalità per cui è stato implementato, ma anche come predisposi-zione ad evolvere di pari passo con quelli che saranno i requisiti futuri (mediante aggiornamenti software piuttosto che hardware). Il terminale fi-sico è il Set-Top-Box o decoder digitale terrestre (o iDTV, integrated Di-gital Television); esso può essere inteso come uno strumento in grado di offrire ed arricchire le funzionalità dell’odierna televisione ma, allo stesso tempo, di integrare molte tra le potenzialità del personal computer. Il STB è un apparecchio che non si discosta molto dai decoder digi-tali satellitari, da tempo presenti sul mercato, ai quali aggiunge il concetto di interattività, potenzialità in grado di rendere il semplice televisore uno strumento bidirezionale. In generale l’MHP viene utilizzato indifferentemente sia per indica-re questo nuovo “elettrodomestico”, che entrerà presto nelle nostre case, sia lo standard internazionale, più in sintesi qualcosa che nella storia della

Introduzione


televisione è paragonabile all’introduzione del colore. Questa piattaforma è caratterizzata da una architettura su tre livelli: applicazioni, software di sistema e risorse o periferiche. Le applicazioni sono realizzazioni funzionali di un servizio interat-tivo e si distinguono in: residenti, installabili e scaricabili; la prima esula dalle direttive dello standard (è libertà dei produttori differenziare l’articolo), mentre le seconde hanno in comune la qualità di poter essere offerte agli utenti da soggetti diversi dai costruttori dei terminali. Le applicazioni fruibili da un utente attraverso la televisione digitale terrestre sono orientate principalmente verso due diversi tipi di interattivi-tà:

Poiché lo standard è caratterizzato dal fatto di essere aperto all’utilizzo di qualsivoglia interessato, e sulla base del fatto che, per quan-to visto in precedenza, la domotica è potenzialmente integrabile in questo contesto, si è pensato di realizzare un tipo di interattività diversa:

Un’interattività di questo tipo si colloca nell’ambito della realizza-zione di una interfaccia tra la persona e un impianto domestico intelligen-te, attraverso un mezzo (Set-Top-Box) caratterizzato dal fatto di non esse-re invasivo quanto un PC. L’utente può di conseguenza utilizzare il televi-sore come strumento polifunzionale, senza che la complessità d’uso dello stesso aumenti radicalmente. Lo scopo di questa tesi è realizzare un’applicazione per la piatta-forma digitale televisiva atta ad interagire con un impianto domotico, per espletare le funzionalità avanzate dello stesso che sarebbero sfruttabili solo

Introduzione


mediante l’uso di un personal computer. Si vuole permettere, in pratica, di effettuare azioni del vivere quotidiano (accensione luci, gestione elettro-domestici, videocontrollo,...) standosene comodamente seduti in poltrona guardando la televisione (cfr.Figura 1).

Figura 1 – Schema di principio dell’obiettivo finale Il progetto si è sviluppato in due fasi: nella prima è stata realizzata su PC una simulazione del sistema televisivo comunicante con un impian-to domotico Bticino della “casa intelligente” del CETAD; nella seconda fase si è provveduto, presso il Centro Ricerche della Rai, al trasferimento dell’applicazione su ricevitore digitale terrestre. Nell’ottica di realizzare una casa intelligente con una interfaccia u-ser friendly si è prestata particolare attenzione ad alcune tipologie di uten-za, nel caso specifico quella anziana e/o disabile. L’utenza anziana più di altre può trarre vantaggio dall’utilizzo di una interfaccia molto familiare quale il televisore può essere; l’utenza disabile invece può essere favorita dalla natura aperta del sistema, essendo esso caratterizzato dalla possibilità di venire implementato in modi differenti a seconda delle diverse disabilità

Introduzione


(le applicazioni conservano sempre la stessa funzionalità, ma viene lascia-ta all’utente disabile la possibilità di usufruire di quella che soddisfa al meglio le proprie esigenze). Nella realizzazione di questo progetto è nata una collaborazione tra il Politecnico di Torino e tre aziende che hanno messo a disposizione il proprio background di conoscenze e le proprie strutture:

Il C.E.T.A.D. è una società il cui scopo è quello di proporre lo svi-luppo e la diffusione di tecnologie per la riabilitazione di anziani e disabili; all’interno delle sue strutture è stato realizzato un appartamento pilota completamente domotizzato, dotato di ausili all’avanguardia e di un im-pianto elettrico di nuova generazione della serie MyHome della Bticino, in grado di offrire servizi domestici automatizzati. Ai fini stessi del progetto il C.E.T.A.D. ha messo a disposizione i locali della casa intelligente, nonché le competenze specifiche del proprio personale (psicologi, consulenti, esperti di ausili …); inoltre sono stati or-ganizzati incontri con utenti rappresentanti diverse disabilità, che hanno permesso di verificare e migliorare la funzionalità del lavoro in corso d’opera. La collaborazione con Bticino è stata ugualmente importante, sa-rebbe altrimenti stato impossibile realizzare la congiunzione tra la casa domotica ed il decoder digitale; è stato messo a disposizione, attraverso

Introduzione


opportuni accordi di riservatezza, tutto il materiale necessario per com-prendere ed utilizzare l’impianto da loro stessi cablato (materiale informa-tivo, software di gestione e protocolli proprietari). Il Centro Ricerche della RAI ha ampiamente collaborato alla fase finale del progetto, mettendo a disposizione, oltre al ricevitore digitale ter-restre, le competenze tecniche del proprio personale di ricerca. Il progetto sin qui descritto è stato tradotto in realtà da un lavoro di gruppo, mediante la collaborazione di tre studenti, completando congiun-tamente una grossa parte dello stesso e suddividendo di volta in volta compiti più specifici. Sebbene sia riduttivo attribuire ad un singolo meriti (o demeriti!) particolari, si può brevemente schematizzare il ruolo di cia-scuno:

Amen Mauro Studio approfondito dell’architettura MyHome, rea-lizzazione delle linee guida di progetto a livello hardware

Arena Pasquale Integrazione hardware/software. Analisi delle com-plessità di interfacciamento STB e impianto domotico intelligente

Brizzi Paolo Progetto e implementazione delle applicazioni sof-tware attraverso l’analisi delle restrizioni imposte dal-lo Standard MHP

Nei capitoli che seguiranno, la descrizione del lavoro svolto verrà esposta nel modo seguente: ü Capitolo 1 – La casa domotica. Vengono introdotti i concetti chiave

sulla domotica ed in particolare viene fatta una panoramica sul CETAD e sulla casa intelligente dimostrativa.

ü Capitolo 2 – Sistema di automazione domestica. Viene descritto il

tipo di impianto cablato da Bticino all’interno della struttura del CETAD; sono dati inoltre alcuni cenni riguardo altri sistemi di au-tomazione presenti sul mercato.

Introduzione


ü Capitolo 3 – Televisione digitale terrestre. Si introducono i concetti fondamentali per comprendere il funzionamento della piattaforma digitale terrestre MHP; si approfondisce il concetto di applicazione MHP fornendo una descrizione del principio di funzionamento di una Xlet.

ü Capitolo 4 – Realizzazione di una interfaccia domestica su PC. Si

illustrano le fasi di creazione e sviluppo della realizzazione su PC di un simulatore televisivo per l’interfaccia domestica; vengono spie-gati i criteri utilizzati per rendere l’applicazione adatta a specifici tipi di utenza (anziana e/o disabile).

ü Capitolo 5 – Integrazione dell’interfaccia con l’impianto domotico.

In questo capitolo si descrivono i passi effettuati per stabilire una connessione tra l’interfaccia descritta nel capitolo precedente e il si-stema di automazione domestica illustrato nel capitolo 2; connes-sione effettuata tramite protocollo TCP interpretando i comandi del protocollo OPEN Bticino.

ü Capitolo 6 – Realizzazione dell’interfaccia domestica su Set Top

Box. Viene descritto come è stato possibile trasferire l’interfaccia utente di cui al capitolo 4 su un ricevitore digitale terrestre mediante l’utilizzo dell’Authoring Tool Cardinal Studio, lavoro svolto presso il centro ricerche della RAI.

ü Conclusioni. Vengono espresse considerazioni finali sul lavoro

svolto e suggerimenti per un’eventuale proseguimento della ricerca nell’ambito fin qui descritto.

ü Appendice A. In appendice viene riportata la parte di codice relati-

va al lavoro descritto nei capitoli 4 e 5. Si coglie l’occasione per ringraziare la dott.sa Mosso, la dott.sa Ve-neziani, l’i.b. Melchiorre e tutto il personale del CETAD, l’ing. Bernasco-ni di Bticino, l’ing. Cane e l’ing. Vecchiattini del CRIT della Rai per la lo-ro gentile disponibilità e cortesia.

Capitolo 1 La casa domotica 1.1 Cos’è la domotica Domotica, forse ancora non si conosce bene, però con la sua intro-duzione e attuazione incuriosisce, attrae e piace. E’ qualcosa d’innovativo, rivoluzionario che incanta con il fascino della tecnologia e la seduzione dell’elettronica. Il termine domotica è un neologismo, di recente maggior impiego in Italia e storicamente derivato dal francese Domotique (dal latino Domus = Casa e Informatique = Informatica), aggettivo indicante l’insieme delle scienze e delle tecniche connesse con l’elaborazione delle informazioni, tramite i più comuni strumenti tecnologici, utilizzabili all’interno dell’ambiente di vita, nei suoi molteplici aspetti quotidiani, e di lavoro; ambiente “Casa” dunque, nel senso più ampio del termine utilizzato dai nostri antenati latini. Potremmo definirla “casa intelligente”, casa automa-tica, casa dotata di meccanismi automatici in grado di svolgere determina-

Cap. 1 - La casa domotica


te azioni…può una casa essere intelligente? Può essa ragionare? Quali meccanismi la rendono tale? Una casa automatica può essere intelligente se è messa a servizio dell’uomo, se riesce davvero a migliorare la qualità della vita e se il costo per la sua attuazione e gestione ci offre per contro delle soluzioni effettivamente utili. Si deve quindi mettere da parte la seduzione tecnologica e il fascino della moda per comprendere quali sono realmente le potenzialità che oggi la tecnologia può offrire, ossia quali sono le possibilità d’impiego intelli-genti. L’enorme diffusione dei mezzi di comunicazione e delle tecnologie legate alla smart house microelettronica hanno favorito, in questi ultimi anni, l’introduzione sul mercato di dispositivi domestici di varia natura (di controllo, automazione, monitoraggio, sicurezza, telecomunicazione), le-gati a varie esigenze dell’utente ed integrati in misura sempre crescente nella realtà abitativa. L’intero concetto d’abitazione è stato ripensato in seguito allo spostarsi delle attenzioni dalla casa (intesa come complesso di strutture) all’uomo (inteso come oggetto primario della progettazione ma anche committente sempre più esigente e severo). In conformità a questo nuovo concetto, l’intera abitazione è considerata come un complesso orga-nico di strutture e servizi, integrati in modo razionale ed efficiente, e ri-spondenti a specifici requisiti d’uso.

Figura 1.1. Requisiti della casa intelligente



Mai come in questo caso l’insieme delle parti non costituisce il tut-to, per questo – pur essendo le costituenti basi da anni disponibili – l’integrazione di tali dispositivi è ben lungi dall’essere realizzabile in mo-do semplice. Alla luce di quanto detto, viene dunque naturale definire casa intel-ligente una casa, un edificio, o un complesso abitativo, in cui i problemi dell’integrazione delle funzioni e dei servizi sono stati affrontati e risolti con successo, sia pure, come spesso accade, in modo solo parziale.

1.2 L’evoluzione della domotica Fin qui la definizione, tuttavia è facile accorgersi di come la lettera-tura specializzata faccia uso di termini molto diversi, tra cui ‘home auto-mation’, ‘smart house’, ‘home systems’, ‘building automation’, ‘computer integrated building’, e via dicendo. Spesso si tratta di distinzioni spurie, ma almeno una si impone: quella relativa allo spazio disponibile. Ogni funzione della casa intelligen-te trova, infatti, il suo senso in relazione ad uno specifico spazio vitale, il quale può essere servito, isolato o collegato ad altri simili spazi in modo indipendente dai requisiti d’utente. La scala in base alla quale l’integrazione si realizza definisce alme-no tre livelli di casa intelligente: la singola entità abitativa, il condominio (gruppo di case di modesta entità), il centro residenziale (dall’edificio di rilevanti dimensioni al quartiere). Ai servizi integrati del primo livello ci si riferisce usualmente con il termine ‘home systems’ o ‘smart house’. A quelli del terzo livello di ‘building automation’, ‘computer integrated building’ e simili. Il secondo livello, intermedio, presenta caratteristiche in qualche misura comuni al primo, dal punto di vista tecnologico/realizzativo, ma concettualmente do-vrebbe essere ascritto al terzo tipo. Lo studio presente si muove principalmente nell’ambito dei sistemi di primo livello, relativi a singoli appartamenti. Il motivo è legato alla na-tura dello studio stesso: la presenza di una persona disabile in un apparta-mento implica l’applicabilità di requisiti di tipo diverso a livello locale, mentre fuori della casa tale diversità non si propaga (se non in modo limi-tato).



Il caso di condomini o quartieri interamente popolati da persone con limitazioni funzionali appartiene all’archeologia sociologica. Innegabil-mente tale soluzione presenterebbe una serie notevole di interessanti van-taggi (possibilità di centralizzare servizi troppo onerosi per il singolo, ot-timizzazione di risorse specifiche, e simili), ma presterebbe il fianco ad una discreta serie di obiezioni, essenzialmente di tipo etico-sociale (tecno-logizzazione delle unità di abitazione per un velato scopo di ghettizzazione delle stesse). Il concetto di casa intelligente comincia a formarsi e a produrre ri-cadute di tipo pratico (tecnologico – implementative) per effetto di alcune circostanze tra loro scollegate, ma molto sinergiche. Tra i fattori chiave le-gati all’uomo possono essere citati: ü L’accresciuto benessere generale della popolazione, e la conse-

guente capacità di investire in beni di non primaria necessità; ü L’accresciuta domanda di protezione nei confronti dell’esterno, de-

terminata dallo stesso benessere; ü L’accresciuta domanda di isolamento, conseguente al fenomeno del

decentramento di grandi masse della popolazione; ü La maggiore attenzione prestata a requisiti generali di comfort e di

comodati d’utilizzo, oltre che di prestazioni; ü L’accresciuto bisogno di economia d’uso e razionalità di esercizio,

conseguenza di crisi energetiche di varia natura. Quali fattori tecnologici determinanti possono invece essere invoca-ti i seguenti: ü L’enorme ricaduta commerciale conseguente allo sviluppo della

tecnologia microelettronica e dei sistemi a microprocessore; ü La tendenza a produrre sistemi rispondenti a standard riconosciuti,

specialmente nel settore delle telecomunicazioni; ü La disponibilità, a bassissimo costo per l'utente finale, di prodotti e

sistemi di elevata flessibilità ed integrabilità. Negli ultimi decenni sono stati sviluppati componenti che sono poi entrati a far parte della comune dotazione di molti appartamenti. Solo per citarne alcuni:



ü I sistemi di sorveglianza ad infrarossi ü I sistemi di regolazione intelligente dei consumi energetici ü I televisori e i videoregistratori con telecomando ad infrarosso ü I telefoni cordless o viva voce ü I personal computer ü I sistemi televideo ü Le segreterie telefoniche ü I citofoni e/o videocitofoni ü I sistemi integrati per l'ascolto musicale ü I modem

e così di seguito. Il passo successivo, molto naturale, è stato chiedersi se non fosse in qualche modo possibile ottimizzare l'uso di tali dispositivi rendendoli compatibili, comunicanti, complementari, evitando inutili cablaggi e col-legamenti ridondati, in modo da ottenere, almeno, una riduzione dei costi di installazione e manutenzione. A questo punto, si è cercato di andare oltre, sfruttando il controllo contemporaneo di tutti i servizi. Si è associata la chiusura di un’elettrovalvola alla rilevazione di una fuga di gas, la regolazione di una portata d'acqua al monitoraggio di una temperatura d'ambiente, l'esecuzio-ne di una telefonata d'emergenza al tradizionale allarme antintrusione.

Figura 1.2. Ambienti funzionali della domotica



Insomma, si è tentato di ottenere quel valore aggiunto che è il fine

vero di tutti gli home system, vale a dire quella serie particolare di funzio-ni complesse che più sistemi semplici possono realizzare solo se messi in-sieme in modo intelligente e razionale. L'Innovation Technology si manifesta in tutte le attività della no-stra vita quotidiana, da una parte facilitando i processi di comunicazione, semplificando i processi di conduzione degli impianti tecnologici, miglio-rando la qualità dei servizi, dall'altra aumentando la richiesta di comfort, sicurezza e desiderio di vivere in ambienti ecologicamente puliti.

1.3 L’importanza dell’autonomia La ricerca di soluzioni ideali ha intrecciato da anni il suo percorso con la tecnologia nella realizzazione di soluzioni che avvicinano la perso-na disabile all’ambiente a lei circostante, oppure creando la possibilità di estendere le abilità della persona attraverso opportuni ausili. La domotica è intesa come integrazione di prodotti e servizi per la gestione ed il controllo della casa. Grazie ad essa, possiamo abitare case intelligenti, più sicure e confortevoli, che risparmiano energia; spazi abita-tivi dove l’impianto elettrico, termoidraulico, telefonico, di sicurezza fan-no capo ad un unico sistema che può gestire anche automazioni di porte e finestre. Per una persona con disabilità le apparecchiature tecnologiche non hanno senso “isolate” dal contesto della casa. Disporre di un “sistema uni-co” che possa comprendere tutte le funzioni di comunicazione ed autono-mia che la persona ha bisogno, è l’obiettivo della domotica. Per questo motivo la scelta della tecnologia più corretta può richiedere valutazioni approfondite, con l’aiuto di persone esperte in tema di disabilità. Attraverso l’approccio alla domotica da parte di persone disabili si innescherà un processo attraverso il quale l’utente imparerà a comprendere i propri bisogni, ed a stabilire obiettivi in relazione ad essi, a formulare progetti mirati al raggiungimento di tali obiettivi e di prendere poi l’iniziativa per realizzarli. Scopo degli addetti ai lavori è diffondere la cultura dell’ambiente creato a misura d’uomo, sia per il soggetto in grado di utilizzare tutte le proprie risorse fisiche e mentali sia per chi può contare solo su parte di



queste. E’ il momento di fronteggiare la disabilità in modo attivo, con mezzi che il futuro ci offre ogni giorno. Inizia a prendere forma il sogno di poter utilizzare nuovi punti di vi-sta per la progettazione:

Persona/Ambiente Edificio/Impianto Le necessità che sono manifestate dalle persone nel proprio ambien-te circostante come comunicazione, sicurezza, comfort ed intrattenimento, devono trovare riscontro nei servizi che i vari impianti tecnologici sono in grado di fornire. L’ambiente in cui la persona vive e svolge le proprie attività neces-sita una fase di progettazione che permetta di evidenziare l’insieme delle funzioni, che la persona potrà svolgere in piena autonomia e con l’ausilio del personale di supporto.

Figura 1.3. Piano operativo - Domotica

Bisogna considerare la persona disabile come elemento attivo all’interno di una struttura immobiliare, le strutture con cui l’utente entra in contatto devono poter interagire e permettere un grado di autonomia alla persona stessa.



1.4 Destinatari Accessibilità, autonomia, riabilitazione, reinserimento sociale, so-cializzazione: sono temi che toccano le persone con bisogni speciali ed il loro contesto sociale, dalla famiglia agli operatori, ai servizi di supporto. Abitazione “intelligente” ed ergonomia della casa, sono i concetti su cui si basa la domotica, che si propone di dare una risposta alle esigenze diversificate soprattutto di anziani e disabili. Per realizzare questo scopo sono chiamate in causa figure professionali che, dal progetto alla realizza-zione pratica, siano in grado di interagire con le stesse finalità, dimostran-do competenze all’avanguardia: ingegneri, architetti e designer, ma anche geometri, tecnici ambientali, imprese edili, periti, elettricisti, installatori. Tutti possono perseguire l’obiettivo comune di migliorare la qualità della vita, realizzando la “casa intelligente”vissuta come ambiente abitativo e nodo di molteplici sistemi. Gli utenti, nel caso specifico, sono, infatti, per-sone anziane, disabili e loro familiari.

1.5 2003: Anno Europeo delle persone disabili Il 2003 è stato l’anno europeo delle persone disabili, nel quale si sanciva l’impegno dell’Unione per la determinazione e la salvaguardia dei diritti delle persone disabili e per il sostegno delle politiche comunitarie a favore della disabilità. Politiche che sono realizzate da diversi organismi a livello europeo. Secondo le stime ufficiali, le persone disabili che vivono negli stati dell’Unione Europea sono circa 38 milioni. Una percentuale pari al 10 % dell’intera popolazione, una fetta consistente di cittadini europei che vivo-no in condizioni diverse secondo gli Stati di appartenenza, accomunati pe-rò dalle medesime esigenze e necessità. Una delle tappe fondamentali per il riconoscimento delle persone disabili in ambito europeo è avvenuta nel luglio del 1996 con il documento della Commissione «Una nuova strategia della Comunità Europea nei con-fronti delle persone disabili» da cui prese il via l’iter per la risoluzione del Consiglio del dicembre 96. Si tratta di un documento che pone le basi per una reale politica d’integrazione, e per il passaggio dal concetto di adatta-



bilità a quello di integrazione delle persone disabili in tutti gli ambiti della vita sociale. Nel 1999 con il trattato di Amsterdam, la disabilità è ufficialmente entrata nelle disposizioni dell’Unione con le dichiarazioni contenute nell’articolo 13 del Trattato dell’Unione che prevedono tra le forme di di-scriminazione da combattere anche quelle per motivi di disabilità. Sono stati, inoltre, sanciti i diritti dei lavoratori disabili e le condizioni per il loro rispetto. All’interno dell’Unione operano numerose associazioni che rappre-sentano le persone disabili; per coordinare l’attività dei singoli Stati è nato, nel 1996, il Forum Europeo per la Disabilità (Edf). L’Organizzazione è formata dai Consigli nazionali della disabilità dei 15 Paesi dell’UE, a cui vanno aggiunti anche rappresentanti di Norvegia e Islanda. E’ stato anche grazie al lavoro dell’Edf che il 3 dicembre del 2001 la Commissione Euro-pea ha indetto l’Anno Europeo per le Persone Disabili tenutosi nel 2003. Nel Parlamento Europeo esistono rappresentanti che si occupano specificatamente delle politiche che riguardano la disabilità. Si tratta dell’Intergruppo Disabilità che ha lo scopo di presentare, all’interno dei lavori del Parlamento e delle varie commissioni permanenti, emendamenti, suggerimenti, proposte e mozioni che riguardino le persone disabili, i loro diritti e le loro necessità. Formato da un nucleo trasversale di centocin-quanta parlamentari europei; fra questi una quarantina opera attivamente e costantemente, l’Intergruppo Disabilità, nato nel 1980, preseduto dall’inglese Richard Howitt e opera in stretto contatto con il Forum Euro-peo sulla Disabilità. L’Intergruppo lavora per proteggere i diritti delle persone disabili in un’opera d’informazione e proposizione politica, anche tramite un rappor-to diretto fra le realtà dei singoli Stati, i cittadini e il potere legislativo in ambito comunitario. Le riunioni dell’Intergruppo si tengono a Strasburgo ogni due mesi, e durante le stesse si discutono le questioni che riguardano le persone disabili, i gruppi di disabili e le istituzioni dell’UE. L’Intergruppo lavora per promuovere direttive comunitarie sugli ar-gomenti che più interessano il mondo della disabilità, come ad esempio il lavoro e l’integrazione. Nell’UE si trovano, ancora in discussione, proposte per emanare di-sposizioni e direttive sull’accessibilità e l’abbattimento delle barriere ar-chitettoniche, sono state anche recentemente licenziate indicazioni sui si-stemi di trasporto accessibili negli Stati membri e ogni anno è realizzato



un report sullo stato delle politiche sociali, dove sono inclusi capitoli sulla condizione e la situazione delle persone disabili in Europa.

1.5.1 L’impegno europeo Il 2003, Anno Europeo delle Persone Disabili, il cui motto è stato «Niente su di noi, senza di noi», ha rappresentato un’opportunità per au-mentare la consapevolezza dei cittadini europei nei riguardi delle disabilità e per creare una vera cultura dell’integrazione. Integrazione e coscienza del ruolo, che le persone disabili in ogni modo, svolgono all’interno della società, sono i principali atteggiamenti per un maggiore riconoscimento, rispetto e consapevolezza dei diritti e doveri fondamentali spettanti ad ogni cittadino in quanto tale, indipenden-temente dal suo stato psico-fisico. L’obiettivo dell’Anno, concluso in Italia nel dicembre 2003, è stato il riconoscimento di pari diritti per le persone disabili che vogliono partecipare in prima persona, o attraverso le loro as-sociazioni, ai processi decisionali che li riguardano, tutto ciò per garantire il principio della non discriminazione. Durante i vari eventi è emersa la necessità di avere uguali opportunità, senza dover ricorrere solamente ai sussidi e agli aiuti che spesso inducono nell’opinione pubblica quella vi-sione pietistica delle persone disabili che invece, a livello europeo, si sta cercando fortemente di modificare. Il percorso da seguire è fatto di lavoro ed emancipazione, di mag-gior visibilità e non di ghettizzazione in modo che le persone disabili pos-sano fornire il loro contributo alla vita sociale anche raggiungendo tra-guardi importanti come la vita indipendente, l’eliminazione di ogni forma di barriera e la rappresentanza politica. Nonostante i progressi finora compiuti, restano ancora numerosi miglioramenti da apportare. La legislazione, anche quella più attenta, sarà inadeguata se la volontà politica non viene sufficientemente sostenuta da poter essere convertita in attività a lungo termine e se essa non ha un am-pio supporto popolare; dunque, poiché si vuole mantenere l’impegno nelle pari opportunità per le persone disabili occorre uno sforzo maggiormente coordinato per promuovere una maggiore comprensione della disabilità. Gli atteggiamenti non cambiano automaticamente o spontaneamente, si tratta di un processo complesso che richiede strategie coordinate e integra-te a tutti i livelli della società per produrre una maggiore sensibilità ed e-



liminare ostacoli sociali ed ambientali, permettendo nel contempo il coin-volgimento delle persone con disabilità. Da un lato se la responsabilità di base incombe agli Stati membri, dall'altro è chiaro che l'Unione europea potrebbe impartire l'impulso e for-nire l’ambiente suscettibile di rendere più agevole il conseguimento di tali obiettivi. Una piattaforma di concertazione paneuropea possiede le poten-zialità per attirare considerevole attenzione su questioni di cittadinanza ai livelli europeo e nazionale e stimolare attività che non potrebbero avere luogo altrimenti. L'Anno europeo potrebbe inoltre costituire il fondamento di ulteriori progressi sostenibili informando e formando le persone e a-prendo la via a nuovi sviluppi giuridici e politici. Gli obiettivi dell'Anno europeo delle persone con disabilità saranno pertanto: ü sensibilizzare al diritto delle persone con disabilità di essere tutelate

dalla discriminazione e di beneficiare di pieni e pari diritti come prescritto, tra l'altro, negli articoli della Carta dei diritti fondamenta-li dell'Unione europea;

ü incoraggiare la riflessione e la discussione delle misure richieste per promuovere pari opportunità per le persone con disabilità in Euro-pa;

ü promuovere lo scambio di esperienze in materia di prassi corrette e strategie efficaci elaborate a livello locale, nazionale ed europeo;

ü potenziare la cooperazione fra tutte le istanze interessate – governo a tutti i livelli, settore privato, comunità, parti sociali, ricerca, grup-pi volontari, persone con disabilità e loro familiari;

ü illustrare il contributo positivo che le persone con disabilità danno alla società;

ü sensibilizzare il pubblico mostrando l'eterogeneità delle persone con disabilità e la discriminazione multipla cui queste sono esposte.

I provvedimenti intesi a raggiungere tali obiettivi possono comprendere: ü organizzazione di incontri e manifestazioni, compresa l'inaugura-

zione e la chiusura di seminari; ü campagne di informazione e promozionali per la produzione di stru-

menti e ausili accessibili alle persone con disabilità in tutta la Comunità; cooperazione con i mezzi d'informazione;

ü indagini e rapporti;



ü eventi per fornire informazioni, in particolare in merito ad esempi di prassi corrette;

ü sostegno finanziari di iniziative di livello transnazionale, nazionale, regionale e locale per promuovere gli obiettivi dell'Anno europeo delle persone con disabilità.

1.6 Realtà e pregiudizi Molto spesso accade che quando la tecnologia non trova il modo per proporre le ultime soluzioni innovative, ci si rifugia in rimedi tecnolo-gici alquanto “diabolici”, i cui “destinatari ottimali” risultano essere anzia-ni e disabili, non per effettivo scopo altruistico, ma solo per un interesse pubblicitario del prodotto in sé. Sono investite risorse rilevanti sulla ricerca del prodotto e sulle sue possibilità d’utilizzo per l’uomo, anche in condizioni di disabilità. Ciò non accade per i nuovi. Usualmente per le aziende e principalmente per lo ste-reotipo dell’immaginario collettivo, i “disabili”, che sono le persone in carrozzina, più o meno stilizzata dal simbolo internazionale, rimangono inermi, nell’attesa di avere un telecomando in mano per poter agire. Dal punto di vista di chi conosce profondamente i bisogni di un uomo, che vive e lotta quotidianamente con la diversità, cresce l’interesse verso questi nuovi prodotti, il cui obiettivo è poter, realmente, aumentare l’autonomia della persona disabile. In conclusione, pertanto, è necessario che questi due mondi, a volte alla prima impressione molto distanti, riescano a trovare una convergenza d’obiettivi e perciò un punto di contatto per precisare le soluzioni giuste per le diverse disabilità. Una fra le realtà del mondo italiano che in un certo qual modo cerca di portare avanti il suddetto progetto è il CETAD.

1.7 Il C.E.T.A.D. Il C.E.T.A.D., Centro di Eccellenza nelle Tecnologie per Anziani e Disabili, è il primo esempio in Europa di Parco Scientifico e Tecnologico dedicato alla promozione, allo sviluppo e alla diffusione di tecnologie e



servizi innovativi per la riabilitazione e l’integrazione sociale di anziani e disabili. E’ una società composta da Finpiemonte, Provincia di Torino, Co-mune di Torino e Pro Juventute Don Carlo Gnocchi Servizi S.r.l. , loca-lizzata a Torino nella stessa area dove sorge Environment Park, parco scientifico e tecnologico dedicato all’ambiente, e occupa circa 1500 m2 tra area espositiva, ambulatorio di riabilitazione specialistica connessa all’utilizzo di ausili, sale formazione, laboratori e uffici. Scopo del C.E.T.A.D. è quello di proporre lo sviluppo e la diffusio-ne di tecnologie per la riabilitazione d’anziani e disabili sotto tre profili: ü supporto allo sviluppo ed al trasferimento tecnologico; ü miglioramento della qualità della vita degli utenti finali; ü riduzione dei costi sociali.

Si tratta di un progetto mirato a valorizzare tutte le risorse esistenti sul territorio regionale e non solo, mettendo in collegamento competenze distribuite tra soggetti diversi: ü Enti Pubblici; ü Settore della ricerca tecnologica e medico; ü Università e Politecnico; ü Imprese; ü “Galassia” del sociale.

1.7.1 Obiettivi Uno tra gli obiettivi che si propone è quello di proporsi nel territorio come centro di riferimento tecnologico regionale per l’informazione, la consulenza, la valutazione e la ricerca sui servizi e sulle tecnologie innova-tive al servizio di anziani e disabili. Parallelamente il C.E.T.A.D. si offre come centro regionale di rac-colta di informazioni e competenze sugli ausili e sulle problemati-che/opportunità connesse al loro uso, in costante aggiornamento, allo sco-po di generare ricadute positive verso:



ü Istituzioni; ü Aziende produttrici di ausili o, indirettamente, di prodotti e servizi

utilizzabili da anziani e disabili; ü Operatori specializzati negli ambiti della riabilitazione, della scuola

e del sociale; ü Persone disabili o anziane e le loro famiglie; ü Centri di formazione; ü Realtà della ricerca e del mercato degli ausili; ü Realtà dell’informazione di promozione culturale.

Il centro, inoltre, mira a stimolare progetti di ricerca competitiva e produttiva, consolidando occasioni di scambio e collaborazione con la ri-cerca e le esperienze analoghe su scala europea, e a offrire opportunità di riqualificazione e aggiornamento, di diverso livello, ad operatori ed utenti.

1.7.2 Servizi Al fine di riuscire nel raggiungimento di una vita indipendente e di una residenzialità attiva per le persone con bisogni speciali, il C.E.T.A.D offre: ü Informazione, diffusione e progettazione di “ausili e soluzioni di vi-

ta intelligente autonoma” presso centri residenziali, pubbliche pri-vate;

ü Progettazione di soluzioni abitative e residenziali domotizzate, pri-ve di barriere architettoniche;

ü Studio e sviluppo di servizi personalizzati per la soddisfazione di bisogni specifici, elaborazione di studi per il miglioramento delle ri-sorse e per il risparmio dei costi sanitari e assistenziali.

Altresì, per facilitare un inserimento mirato di disabili motori o sen-soriali sono disponibili consulenze alle imprese per l’eliminazione delle barriere, architettoniche e culturali, e per l’adattamento del posto di lavoro; fornendo un servizio di elaborazione ed attivazione di percorsi/tirocini di formazione personalizzata, anche a distanza. Il C.E.T.A.D. assicura il confronto continuo tra utenti e imprese e, soprattutto, tra ricerca-produzione e utenza finale grazie all’utilizzo del la-



boratorio domotizzato creato all’interno del Centro; inoltre, sollecita la sperimentazione, l’utilizzo e l’eventuale produzione di ausili e soluzioni tecnologiche al servizio di anziani e disabili non ancora presenti sul mer-cato in sinergia con il SIVA (Servizio Informazione e Valutazione Ausili) coordinato dalla Fondazione Don Gnocchi e in stretta collaborazione con il Ministero del Welfare per il mantenimento della banca dati. Laddove sia necessario per il disabile/anziano prendere visione di un ausilio specifico, è a disposizione il Centro ausili e la banca dati gestita in collaborazione con la Fondazione Don Carlo Gnocchi Onlus. A tal pro-posito, sarà priorità assoluta del Centro, assicurare la presenza di ausili più innovativi e tecnologicamente avanzati e informare periodicamente tutte le realtà collegate al settore della riabilitazione sugli ausili disponibili presso il C.E.T.A.D. e sulle novità presenti in commercio, accessibili via banca dati. Sono offerte l’opportunità di sviluppare attività di consulenza per quanto riguarda le certificazioni dei servizi sanitari e le apparecchiature e-lettro-medicali, un servizio di monitoraggio e osservatorio sulle applica-zioni e prospettive di sviluppo nel campo delle tecnologie al servizio della disabilità, in Italia e all’estero. Il C.E.T.A.D., inoltre, è in grado di offrire consulenze e collabora-zioni nell’ambito di progetti europei di formazione, informazione/scambio di buone prassi di ricerca e di suggerire iniziative locali a sostegno della stessa in questo settore. Tra i tanti servizi offerti si possono menzionare la possibilità di or-ganizzare seminari e convegni inerenti al tema della tecnologia al servizio delle persone con bisogni speciali, l’opportunità di predisporre attività di formazione continua nel campo degli ausili indirizzate a scuole, operatori, famiglie, volontariato e fornire una vetrina informativa ad enti pubblici e privati. Infine obiettivo del C.E.T.A.D. è fungere da osservatorio della si-tuazione epidemiologica e dei servizi presenti sul territorio negli ambiti delle persone con bisogni speciali.

1.7.3 Attività Il Centro, in merito agli obiettivi mirati, ha attivato un laboratorio pilota per la sperimentazione del lavoro a distanza e della formazione con



l’ausilio di software e hardware specifici per disabili, collegato ad un Cen-tro servizi alle imprese per l’applicazione della legge 68/99 sul colloca-mento mirato dei disabili in collaborazione con INAIL, Politecnico di To-rino e ASPHI Onlus; sta inoltre elaborando progetti di ricerca nazionale e internazionale nell’area dei servizi e degli ausili innovativi destinati ad an-ziani e disabili. Il C.E.T.A.D. è stato coinvolto da soggetti pubblici per l’elaborazione di studi di fattibilità e progetti nell’ambito di analisi dei re-quisiti tecnologici per l’utenza anziana e studio di servizi innovativi a di-stanza. In più, il Centro ha realizzato un’area espositiva/laboratorio, sotto forma di casa intelligente, comprensiva di ausili tecnologici innovativi e soluzioni di domotica.

1.7.4 Casa intelligente dimostrativa Il C.E.T.A.D., all’interno dei finanziamenti destinati specificata-mente ai Parchi Scientifici e Tecnologici dell’Assessorato all’Industria della Regione Piemonte e conseguentemente ad un progetto sperimentale sul tema “Domiciliarità innovativa” inserito nel programma CO.S.MO. della Regione Piemonte – Assessorato alle Politiche Sociali e della Fami-glia, ha realizzato presso la sua sede un appartamento pilota completamen-te domotizzato, dotato di ausili ad alto costo quali sollevatori, servo scala ed elevatore, ed arredato secondo criteri di accessibilità e usabilità (cucina accessibile per anziani e disabili, bagno comprensivo di ausili, stanza da letto per persona allettata). Tale appartamento, realizzato per attività di consulenza, dimostra-zione e sperimentazioni, è dotato di un impianto elettrico di nuova genera-zione della serie MyHome della Bticino, in grado di offrire servizi dome-stici automatizzati, e di elettrodomestici dotati di una propria intelligenza. L’impianto MyHome della Bticino è un sistema, trattato nel partico-lare al capitolo successivo, che, mediante le nuove tecnologie digitali, permette di sostituire alle apparecchiature tradizionali dei dispositivi intel-ligenti in grado di comunicare tra loro; essi, infatti, provvedono sia all’elaborazione che all’invio dell’informazione agli altri dispositivi trami-te un BUS, quale mezzo fisico di collegamento.



Figura 1.4. Casa intelligente dimostrativa - Cucina

Figura 1.5. Casa intelligente dimostrativa - Bagno

Capitolo 2 Sistema d’automazione domestica 2.1 L’impianto MyHome BTicino

Da tempo gli impianti elettrici sono in una fase di profonda e conti-nua trasformazione sotto la spinta dell’esigenza di una maggior automa-zione ed integrazione di sistemi diversi; già dai primi anni ’70 l’introduzione dell’informatica ha evidenziato la necessità di realizzare punti di derivazione e di comando caratterizzati da un’elevata flessibilità. Nell’ambito domestico la trasformazione dell’impianto elettrico ri-flette invece il concetto di qualità della vita inteso come maggior sicurezza e possibilità di vivere nel modo più confortevole. Tutto questo implica la realizzazione di impianti elettrici facilmente configurabili ed espandibili in funzione delle molteplici esigenze dell’utente.

Un impianto tradizionale, utilizzato per svolgere tutte le funzioni sopra descritte, sarà indubbiamente caratterizzato da un’elevata complessi-

Cap. 2 - Sistema d’ automazione domestica


tà circuitale e strutturato in modo che ogni funzione faccia riferimento ad un cablaggio separato e dedicato. Ciò comporta chiaramente un notevole aumento del tempo di installazione nonché una limitazione per modificare o aggiungere nuove funzioni qualora si debba intervenire su impianti preesistenti.

Figura 2.1. Impianto tradizionale

La soluzione ai problemi impiantistici descritti è rappresentata dalle nuove tecnologie digitali che permettono di sostituire le apparecchiature tradizionali con dei “dispositivi intelligenti” in grado di comunicare tra lo-ro. Ogni dispositivo, in qualche modo, provvede sia all’elaborazione dell’informazione che all’invio della stessa agli altri dispositivi. La casa domotica cablata da BTicino si basa sul sistema di automa-zione domestica My Home; caratteristica comune di tutti i dispositivi è l’utilizzo della tecnologia impiantistica basata su bus digitale sul quale vengono trasmessi, attraverso opportuni comandi, dei segnali che rispet-tano il protocollo OPEN di BTicino.



Figura 2.2. Impianto tipo BUS

Tali dispositivi sono facilmente integrabili tra loro, la loro installa-zione è modulare in modo da poter ottimizzare i costi scegliendo quale so-luzione adottare immediatamente e come migliorarla nel futuro. Questo sistema permette di pilotare un qualunque carico della casa (illuminazione, automatismi, allarmi, ecc.) in due modi: da un punto qual-siasi della casa (locale) o da cellulare, telefono fisso, personal computer (remoto). Il principio di funzionamento è simile in entrambe i casi a livello fi-sico; le differenze sostanziali si incontrano quando si analizza in quale modo viene inviato il comando. In un edificio realizzato con cablaggio tradizionale il comando di due diversi carichi da punti differenti implica la posa di un considerevole numero di conduttori. L'aggiunta di un nuovo punto di comando all'interno della stessa scatola aumenta notevolmente la complessità di cablaggio e riduce lo spa-zio all'interno della scatola stessa (cfr. Figura 2.1.).



Un ambiente realizzato con cablaggio a BUS consente di ottenere la medesima funzionalità operativa, ma con un notevole risparmio di condut-tori (solo un doppino telefonico). La modifica dei punti di comando o delle modalità operative non comporta la modifica del cablaggio ma una nuova configurazione del dispositivo stesso (cfr. Figura 2.2.).

2.2 Principio di funzionamento

Il mezzo di trasmissione delle informazioni tra i vari dispositivi è de-nominato BUS; esso è costituito da un doppino telefonico intrecciato che provvede contemporaneamente all’alimentazione e allo scambio delle in-formazioni tra i vari dispositivi connessi in parallelo. Il sistema si articola in due componenti base:

ü Dispositivi di comando (assimilabili ai tradizionali interruttori), col-legati unicamente al BUS (cfr. Figura 2.3);

ü Dispositivi attuatori (assimilabili ai tradizionali relè) per il comando dei carichi connessi, collegati sia al BUS che alla linea di alimenta-zione del carico comandato (cfr. Figura 2.4).

Figura 2.3. Dispositivo di comando

Nel dispositivo di comando non è presente il collegamento diretto alla linea di potenza, ma la sola connessione al bus.



Il dispositivo attuatore è anch’esso connesso al bus come il disposi-tivo di comando; la cosa da notare è la presenza dell’alimentazione: l’utente non entrerà mai in contatto con dispositivi alimentati con tensioni elevate, dovendo interagire direttamente solo con dispositivi di comando.

Figura 2.4. Dispositivo attuatore

Schematicamente un impianto di tipo BUS si presenta come nella Figura 2.6.

Ogni dispositivo connesso al sistema è dotato di circuito d’interfaccia e di una propria intelligenza (costituita da un microprocesso-re programmato) per mezzo del quale è in grado di riconoscere l’informazione a lui destinata ed elaborarla per realizzare la funzione desi-derata.

Figura 2.5. Schema funzionale di un impianto di tipo BUS



Figura 2.6. Impianto di tipo BUS

Dal punto di vista fisico e funzionale però i dispositivi a BUS non si differenziano dai dispositivi tradizionali; uno schema esemplificativo è mostrato in Figura 2.5. L’utente per accendere una lampada dovrà agire sempre su un tasto per fare sì che il carico venga alimentato; ci si chiede dunque cosa spinga gli impiantisti ad orientarsi verso strutture di questo tipo (cfr. Par. 2.2.2). Affinché ciascun dispositivo in un sistema a BUS svolga corretta-mente la funzione preposta, deve essere opportunamente programmato as-segnando il rispettivo identificativo e la modalità di funzionamento (cfr. Par. 2.2.1).

Poiché la gestione del sistema ruota intorno al sistema BUS – attua-tori si arriva alla conclusione che il sistema è “aperto” in quanto è in grado di ricevere comandi da fonti differenti.

Finora è stato ampiamente presentato l’uso della struttura a BUS secondo una sua “gestione locale”; è possibile inviare informazioni sul BUS, non solo comandi ma anche operazioni di monitoraggio ed altro an-cora, con metodi diversi dalla semplice pressione di un tasto, sia da locale che da remoto.

Tutti i sistemi per comandare l’impianto domotico si distinguono (cfr. Figura 2.7):



ü Gestione locale - Pulsanti à BUS - PC à BUS - Comunicatore telefonico à BUS - Telefono derivato à PABX à BUS

ü Gestione remota - PC à Web – Server Bticino à BUS - Telefono/Cellulare à PABX/Com. telefonico à BUS

Figura 2.7. Sistemi di comando dell’impianto

2.2.1 Configurazione dei dispositivi

I parametri da prendere in considerazione per la configurazione dei dispositivi sono:

· Il tipo di dispositivo (ad esempio illuminazione, automatismi, ... ); · La funzione svolta dal dispositivo (ad esempio ON/OFF,

SU/GIÙ/STOP, ... ); · L’associazione tra dispositivo e carico (indirizzamento, cfr. Figura

2.9).



La procedura di configurazione si effettua introducendo appositi configu-ratori ad innesto in specifiche sedi; tali configuratori sono differenziati per nume-ro, lettera, colore o grafismo stampigliato sul corpo stesso(cfr. Figura 2.8.). Per implementare una funzionalità all’interno dell’impianto (es. accensione luce) è necessaria la configurazione della destinazione e della sorgente del comando al-l'interno del sistema, nonché la modalità di funzionamento del dispositivo stesso.

Figura 2.8. Esempio di configuratori

Riassumendo, configurare significa definire:

Per i comandi: a) quali sono gli attuatori da comandare; b) con quale modalità operativa comandarli. Per gli attuatori: a) il loro indirizzo, l'eventuale gruppo di appartenenza; b) la loro modalità di funzionamento. In Tabella 2.1 si definiscono alcuni termini utili a comprendere la logica di indirizzamento degli attuatori.



Figura 2.9. Configurazione

Ambiente (A) L’insieme dei dispositivi appartenenti ad una zona lo-gica (in un’abitazione, per esempio, la cucina, la came-ra ecc..)

Punto Luce (PL)

Identificativo numerico del singolo attuatore all'interno dell'Ambiente.

Gruppo (G)

Insieme dei dispositivi appartenenti anche ad ambienti diversi, ma che devono essere comandati contempora-neamente (per esempio le tapparelle del lato Nord del-l'abitazione, l'illuminazione della zona giorno ecc.).

Tabella 2.1. Nomenclatura della logica di indirizzamento



L’indirizzo degli attuatori è definito univocamente: nelle posizioni A (Ambiente) e PL (Punto Luce all'interno dell'Ambiente) vengono inseriti i configuratori numerici 1÷9.

Per ogni ambiente è possibile definire un massimo di 9 indirizzi; in un sistema sarà possibile definire un massimo di 9 ambienti. La definizio-ne del gruppo di appartenenza si effettua inserendo un terzo configuratore numerico nella sede identificata con G (Gruppo). Alcuni attuatori dispon-gono di più posizioni G (G1, G2 e G3) potendo appartenere contempora-neamente a più gruppi differenti.

Anche i dispositivi di comando dispongono delle posizioni Ambien-te (A) e Punto Luce (PL) per la definizione dell'indirizzo dei dispositivi destinatari (attuatori).

Per dette posizioni sono previsti configuratori numerici e con grafi-smo uguali a quelli visti in precedenza che abilitano il dispositivo ad invia-re il rispettivo comando secondo diverse modalità (punto-punto, ambiente, gruppo, generale).

Per quanto riguarda l’automazione filare i dispositivi presenti nel si-stema permettono di svolgere funzioni diverse (accensione/spegnimento, regolazione intensità, temporizzazione, …); la definizione della funzione svolta si effettua inserendo opportuni configuratori nella sede contrasse-gnata con la lettera M dei dispositivi di comando e anche in questo caso è possibile ottenere diverse modalità operative (on, off, on-off cicli-co,comando monostabile o bistabile per tapparelle,…).

Infine la scelta di opportuni configuratori e di una particolare cen-tralina (centralina scenari) permette di effettuare operazioni “multiple”. Agendo su uno dei quattro tasti presenti nella centralina si attivano gli sce-nari precedentemente impostati. In questo caso tutti i comandi che sono stati memorizzati, in maniera sequenziale secondo una specifica procedura di programmazione, vengono attivati contemporaneamente e vanno ad agi-re sui rispettivi attuatori di tutto il sistema, anche di ambienti diversi (indi-pendentemente dalla presenza del configuratore nella posizione A della centralina scenari). E' inoltre possibile senza alcun intervento sull'impian-to, modificare e/o cancellare in qualsiasi momento uno o più scenari me-morizzati, in funzione delle diverse esigenze dell'utente.

Combinando insieme tutti questi dispositivi non è difficile immagi-nare quanto sia agevole e comodo un impianto di questo tipo e quali po-tenzialità può avere rispetto ad uno tradizionale.



2.2.2 Vantaggi dell’impianto a BUS

I vantaggi di un impianto di questo tipo sono evidenti: · Semplicità di cablaggio (vi è un unico cavo non polarizzato per la

connessione in parallelo di tutti i dispositivi); · Sicurezza (l’utente agisce su dispositivi di comando alimentati con

una bassa tensione di 20÷30 V d.c.); · Flessibilità di impiego (è possibile modificare la funzionalità

dell’impianto in qualsiasi momento variando la programmazione dei dispositivi o aggiungendone di nuovi);

· Continuità di esercizio (un dispositivo difettoso non interrompe la funzionalità del sistema);

· Economicità (riduzione della manodopera dovuta al cablaggio di un solo cavo invece dell’impiego di numerosi conduttori).

2.3 Gestione locale dell’impianto tramite Personal Computer

Il sistema di automazione, pur utilizzando dispositivi specifici rea-lizzati appositamente, permette anche l'uso del personal computer, consen-tendo l'apertura e la flessibilità di impiego verso sistemi esterni.

La connessione tra la tecnologia digitale a BUS ed il PC è rappre-sentata da un particolare dispositivo di interfaccia (cfr. Figura 2.10); in particolare per effettuare una connessione diretta tra il BUS ed un PC vie-ne utilizzata l’interfaccia seriale RS-232 e, per mezzo di un programma dedicato, è possibile realizzare la supervisione ed il comando dello stato dei dispositivi.

Questo particolare componente permette la connessione tra il siste-ma di automazione caratterizzato da una intelligenza distribuita, presente in ogni singolo dispositivo di comando e attuazione, ed un unico dispositi-vo di supervisione, quale un Personal Computer, caratterizzato da una in-telligenza centralizzata e residente nel proprio microprocessore. È impor-tante tenere presente che l’impiego del computer in un sistema di automa-zione non sostituisce i dispositivi di comando e attuazione; i suddetti di-spositivi mantengono la propria autonomia di funzionamento.



Il dispositivo è costituito da un circuito di interfaccia dotato di con-nettore seriale RS-232 al quale è connesso un cavo flessibile dotato di connettore a 9 poli per il collegamento con il sistema a BUS mediante op-portune prese. Due indicatori luminosi presenti sull’interfaccia segnalano il corretto collegamento del connettore RS-232 al computer e del connetto-re a 9 poli alle suddette prese.

L’impiego dell’interfaccia è subordinato, come precedentemente accennato, all’installazione sul computer di un programma, fornito con l’interfaccia stessa, che permette di simulare graficamente e gestire lo stato dei dispositivi, sia attuatori che comandi, del sistema a BUS (o impianto SCS di automazione), in base alle specifiche esigenze dell’utente. Il sof-tware in questione è il Visual-SCS; esso permette di creare a cura dell’utente, un sinottico, cioè una rappresentazione grafica chiara e ordina-ta dell’impianto SCS installato. Ogni sinottico è costituito da una serie di fogli di lavoro sui quali è possibile rappresentare i vari dispositivi median-te l’ausilio di icone prestabilite e comunque personalizzabili (per esempio: lampada, frigorifero, tapparelle, …). Per ogni icona selezionata sarà possi-bile definirne la funzione svolta, impostando, come per i componenti reali, i valori dei configuratori numerici e alfanumerici.

Figura 2.10. Collegamento diretto tra PC e BUS



Dopo la creazione e la configurazione dell’impianto sarà possibile verificarne il funzionamento, se il PC è connesso al BUS tramite interfac-cia RS-232, effettuare il comando e la visualizzazione dello stato dei di-spositivi reali. Per particolari esigenze è possibile definire anche un foglio di lavoro nel quale verranno posizionate le icone di attuatori che, se confi-gurate a dovere, potranno generare un allarme visivo per segnalare il cam-bio di stato o il guasto di un dispositivo del sistema.

Come primo approccio alla casa domotica del C.E.T.A.D., si è reso necessario effettuare un test dell’impianto cablato precedentemente da BTicino. Per effettuare tale test è stato creato un sinottico della casa trami-te il Visual-SCS, del quale viene rappresentato il dettaglio della cucina (cfr. Figura 2.11).

2.4 Gestione remota dell’impianto My Home è in grado di comunicare con il mondo esterno per mezzo

di appositi dispositivi che interagiscono con la casa: telefoni di rete fissa e mobile e/o qualunque Personal Computer via rete locale o via Internet.

Figura 2.11. Sinottico della casa – dettaglio della cucina



2.4.1 Gestione da telefono

2.4.1.1 PABX I centralini telefonici PABX di BTicino consentono di integrare le

funzioni tipiche di un impianto videocitofonico (digitale o analogico) con quelle telefoniche.

Questa integrazione consente di accedere a tutte le funzioni videoci-tofoniche tramite i telefoni collegati al centralino, come ad esempio: ri-spondere ad una chiamata citofonica, comandare l’apertura della serratura, monitorare ciò che avviene all’esterno. L’utilizzo del centralino telefonico PABX in un impianto videocitofonico, consente inoltre l’intercomu-nicazione tra tutti i telefoni installati, il monitoraggio acustico degli am-bienti, funzioni di videocontrollo e soprattutto la teleattivazione.

Tale funzione permette di azionare dei dispositivi (impianto di ri-scaldamento, di irrigazione ed altro ancora) effettuando una semplice tele-fonata da telefoni interni (derivati) oppure da linea telefonica esterna.

I centralini sono stati progettati in modo che i futuri aggiornamenti del software e delle funzioni possano essere apportati senza sostituire i componenti elettronici, ma utilizzando un Personal Computer dotato di specifico software ed interfaccia hardware.

Tutte queste caratteristiche fanno dei centralini telefonici modulari un’ottima soluzione sia in ambito residenziale che nel piccolo terziario (case, uffici, studi professionali).

2.4.1.2 Comunicatore telefonico Uno strumento molto utile per la gestione della casa (soprattutto in

termini di sicurezza e controllo) localmente ma soprattutto da remoto è il comunicatore telefonico; è un dispositivo in grado di comporre automati-camente i numeri telefonici precedentemente impostati e di inoltrare sulla normale linea telefonica uno o più messaggi preregistrati. Permette la co-municazione bidirezionale tra l’utente, l’impianto antifurto e l’impianto di automazione.



Figura 2.12. Gestione remota della casa mediante centralino telefonico Le sue funzioni si possono dividere in 4 categorie:

· GESTIONE ALLARMI, in caso di allarme rilevato dal sistema an-tifurto, si attiva per effettuare la chiamata ai numeri impostati speci-ficando il tipo di allarme rilevato;

· AUTOMAZIONE, a seguito di eventi rilevati dal sistema antifurto, può determinare l’intervento automatico di altri dispositivi installati nell’abitazione;

· ROOM MONITOR, in caso di allarme anti-intrusione consente l’ascolto ambientale e la comunicazione di messaggi nei locali con-trollati dal sistema;

· COMANDI TELEFONICI, può essere chiamato dall’utente e attra-verso codici predefiniti, comandare i dispositivi installati nell’abitazione.



Figura 2.13. Esempio di impiego – Gestione allarmi

Figura 2.14. Esempio di impiego – Allarme tecnico



2.4.2 Web Server

Questo dispositivo consente di controllare e gestire un impianto My Home installato nella casa o nell’ufficio, tramite un Personal Computer (cfr. Figura 2.15).

La connessione del Web Server con il PC di controllo può essere ef-fettuata tramite modem e rete dati locale o Internet. L’utente, utilizzando un browser commerciale, può collegarsi localmente o a distanza con il Web Server e, navigando tramite pagine Web personalizzabili e provviste di menù ad icone e bottoni di comando, può effettuare le seguenti opera-zioni:

· supervisione e/o comando degli impianti Automazione (gestione dei

carichi, luci, serrande ecc.) e Gestione Energia; · supervisione dell’impianto Antifurto mediante ricezione di messag-

gi di stato (impianto in allarme o nessuna segnalazione di allarme); · visualizzazione delle immagini in bianco e nero provenienti da una

delle telecamere connesse al Web Server stesso. L’utente può inter-venire sulla qualità dell’immagine regolandone la luminosità, il controllo e lo zoom.

Figura 2.15. Gestione tramite web-server



In alternativa alle pagine Web, con l’ausilio di opportuni software (Virtual Switch, SCS Action, SCS Action Server e Visual SCS) installati su un PC, il Web Server consente di effettuare la supervisione ed il con-trollo dell’impianto (attuazioni acceso/spento per il comando di luci, su/giù di tapparelle,…) agendo su icone.

Inoltre, tale dispositivo è in grado di inviare alla casella di posta e-lettronica dell’utente dei messaggi di notifica di eventi intrusione e allarmi ausiliari rilevati nell’impianto My Home.

Affinché il web server possa essere utilizzato è necessaria un’opportuna programmazione dello stesso, effettuabile tramite un cavo seriale specifico connesso al PC, sul quale dovrà essere installato uno spe-cifico software di configurazione (TiWEB).

I principali parametri che devono essere configurati sono i seguenti:

· Indirizzo IP: necessario per identificare univocamente il Web Server. E’ importante ovviamente che questo indirizzo sia di tipo statico e pubblico;

· Login e password: identificativo (login) e parola chiave di accesso (password) per la connessione;

· Indirizzo e-mail: per l’invio di messaggi di posta elettronica di noti-fica di eventi antintrusione e allarmi ausiliari. Deve essere imposta-to l’indirizzo IP del Server SMTP (Simple Mail Transfer Protocol) e se necessario quello del Router di posta.

· Pagine web: per la gestione ed il comando, per mezzo di bottoni personalizzabili, dei dispositivi degli impianti Automazione, Anti-furto, Gestione Energia e Videocontrollo mediante PC remoto dota-to di browser. Con connessione tramite browser saranno necessari, oltre

all’indirizzo IP del web server, il login utente e la password, richiesti in una prima schermata; successivamente si passerà alla gestione ed al con-trollo effettivi dell’ambiente selezionato (cfr. Figura 2.16).

Il web server presente nella casetta domotica del C.E.T.A.D. è stato programmato con un indirizzo IP fisso ma non pubblico per permetter l’accesso ad esso solo tramite rete locale. Come precedentemente detto, in alternativa al browser, è possibile connet-tersi all’impianto attraverso interfacce fornite da BTICINO.



Figura 2.16. Sequenza operazioni da effettuare



2.4.2.1 Software forniti da Bticino

· Visual SCS, ampiamente descritto nel paragrafo relativo alla ge-stione locale dell’impianto, esso permette una connessione, oltre che seriale direttamente col bus, anche col web server e quindi tra-mite rete locale o internet.

· TiWeb (cfr. Figura 2.17), anch’esso descritto precedentemente, per-

mette la configurazione e l’utilizzo del web server; il programma permette inoltre di importare sul PC la configurazione del web server stesso per effettuarne degli aggiornamenti a fronte di modifi-che all’impianto My Home.

Figura 2.17. TiWeb, applicativo per la configurazione del web server

· Virtual Switch (cfr. Figura 2.18), trova la sua applicazione in ambienti del terziario tipo open-space ed in ampi uffici ove i punti di comando a parete (di illuminazione e tendaggi per esempio) non sono facilmente raggiungibili dalle postazioni di lavoro distanti. Il programma consente di creare graficamente sul monitor del PC un’interfaccia utente costituita da una placca BTicino con tre inter-



ruttori virtuali che permette al personale di interagire con l’impianto My Home senza raggiungere i comandi alle pareti. La trasmissione dei comandi dal PC all’impianto da gestire avviene tramite rete E-thernet.

Figura 2.18. SCS Virtual Switch

· SCS Action, permette di creare con un PC particolari scenari per l’attivazione giornaliera, settimanale o annuale di funzioni Automa-zione disponibili nel sistema My Home. Esso trova applicazione nel settore del terziario ed in ambienti ove è richiesta l’attivazione pe-riodica di apparecchiature elettriche. Un esempio di impiego è rap-presentato dall’esigenza di comandare automaticamente l’attivazione di dispositivi, sistemi di riscaldamento industriali ecc. in orari prestabiliti diversi da quelli lavorativi, evitando l’impiego di numerosi temporizzatori tradizionali.

· SCS Action Server (cfr. Figura 2.19), permette di fare interagire più

impianti My Home connessi mediante Web Server su una rete E-thernet. Un evento o un comando impartito su un impianto può atti-vare in altri impianti My Home degli scenari creati con l’applicativo precedente.



Figura 2.19. Gestione di più impianti My Home diversi - utilità

dell’applicativo SCS Action Server

2.5 Il protocollo “OPEN” È un protocollo con il quale poter scambiare dati, inviare comandi tra un’unità remota e i sistemi a tecnologia BUS di BTicino. Il protocollo è pensato per essere indipendente dal mezzo di comunicazione usato, consi-derando come requisito minimo la possibilità di poter utilizzare toni DTMF sulla normale linea telefonica. Il codice è caratterizzato da una struttura con campi a lunghezza variabile separati dal carattere speciale (*) e chiuso con (##). La struttura logica è la seguente:

*CHI*COSA*DOVE*QUANDO##



e i singoli campi hanno il seguente significato:

CHI

definisce il tipo di funzione o il tipo di sistema presente nell’abitazione che è interessato al messaggio trasmesso; può essere di tipo SCENARIO, ILLUMINAZIONE, AU-TOMATISMI, ALLARMI e AUSILIARI.

COSA definisce l’operazione da compiere (es. ON, OFF, SU, GIU, …)

DOVE definisce il o l’insieme degli oggetti interessati (es. una zo-na, un gruppo di oggetti, un ambiente specifico, un singolo oggetto, ecc.)

QUANDO specifica l’orizzonte temporale o il legame ad un particola-re evento (es. canale ausiliario)

Tabella 2.2. Campi del protocollo OPEN

I tipi di comando realizzabili sono: ü Attivazione/Disattivazione

- Illuminazione; - Automatismi; - Impianto antifurto; - Scenari.

ü Verifica

- Stato di un attuatore (solo nei casi illuminazione e au toma-zione);

- Stato dell’impianto antifurto.



Il valore del campo CHI deve essere attribuito secondo la Tabella 2.2.

FUNZIONE VALORE Scenari 0

Illuminazione 1 Automatismi 2

Allarmi 5 Ausiliari 9

Tabella 2.2. Valori del campo “CHI” Una volta attribuito un valore a tale campo, sono presenti nel proto-

collo altre tabelle corrispondenti alle varie combinazioni di eventi, sele-zionabili fornendo un determinato valore agli altri campi.

I passi che vengono seguiti per accedere e comunicare con l’impianto SCS, indipendentemente dal mezzo utilizzato, sono schematiz-zati in figura:

Figura 2.20. Passi per l’accesso e la comunicazione con l’impianto SCS

Una volta effettuata la connessione, il dispositivo SCS invia un messaggio di OK. Ci sono due possibili casi, dipendenti dai mezzi con i quali si dialoga:

COMUNICAZIONE

IDENTIFICAZIONE

CONNESSIONE

UTENTE DISPOSITIVO

SCS-OPEN



Figura 2.21. Comunicatore telefonico – Accesso all’impianto

Figura 2.22. Web Server – Accesso all’impianto

Per quanto riguarda l’identificazione esistono due metodi: 1. Manuale – per esempio l’utente utilizza un telefono per chiama-

re il comunicatore telefonico – in questo caso l’utente remoto digita semplicemente la password (costituita da una sequenza di numeri, cfr. Figura 2.21);

2. Automatica – colloquio tra un ISP e un Web Server – viene applicato alla password un algoritmo di crittografia proprietario; entrambe le parti devono giungere allo stesso risultato che verrà confrontato dal web server1 (cfr. Figura 2.22).

1 Per quanto riguarda la crittografia della password ed il protocollo Open non è possibile fornire informazioni aggiuntive in base agli accordi di riservatezza stipulati con Bticino

CHIAMATA

OK

UTENTE SCS-OPEN

(Comunicatore telefonico)

UTENTE SCS-OPEN

(Web Server)

Eventuale sessione di autenticazione per connessione remota

OK



A questo punto è possibile iniziare la comunicazione vera e propria.

2.6 Tecnologie di automazione domestica alternative

Finora è stato esposto il principio di funzionamento e le potenzialità

del sistema My-Home Bticino, sistema da noi utilizzato per lo sviluppo del presente progetto.

Attualmente è possibile trovare sul mercato sistemi di automazione domestica, più o meno complessi e con maggiori o minori potenzialità, al-ternativi al suddetto sistema e la cui scelta dipende dalle necessità dell’utente finale.

L’elemento che accomuna tutti questi sistemi è la struttura a BUS dell’impianto.

2.6.1 Tecnologia LONWORKS® di Echelon Essa può operare in diversi campi applicativi:

· video-sorveglianza, gestibile anche in remoto; · controllo illuminazione; · condizionamento aria; · controllo accessi; · rilevazione consumi energetici.

Una rete LONWORKS® è formata da componenti intelligenti,

chiamati nodi, che comunicano tra loro su una varietà di mezzi usando un comune protocollo di comunicazione basato su messaggi. Un nodo realiz-za la funzione in un processo applicativo attraverso l’esecuzione di un programma scritto dall’utente. La funzione di ogni particolare nodo può essere piuttosto semplice; l’interazione tra nodi permette ad una rete LONWORKS® di svolgere compiti più o meno complessi. Pochi nodi pos-sono compiere un grande numero di funzioni differenti all’interno del si-stema di controllo di un edificio, ciò dipende da come sono configurati e



connessi; essi possono essere dispositivi di I/O, sensori di temperatura, termostati programmabili, … .

Una connessione logica di più nodi viene chiamata dominio; all’interno di un dominio vengono definite delle subnet (connessioni logi-che di più nodi), ciascuna delle quali può contenere fino a 127 nodi. Con-siderando che ciascun dominio può contenere fino a 255 subnet, esso arri-va a comprendere fino a 32000 nodi. In questo modo ogni nodo possiede un indirizzo di dominio che lo identifica univocamente all’interno della re-te. Le subnet vengono connesse tra loro tramite router e per coprire lunghe distanze vengono utilizzati dei repeater.

Ogni nodo contiene un Neuron Chip, un transceiver ed una elettro-nica preposta al tipo di utilizzo del nodo stesso; essi comunicano tra loro attraverso le variabili di rete dichiarate con il codice applicativo.

Il transceiver realizza la connessione fisica al mezzo di comunica-zione che può essere un cavo a doppino twistato, una linea di potenza, una fibra ottica, un collegamento in radiofrequenza o a infrarossi.

Il Neuron Chip rappresenta il cuore del nodo. Esso è costituito da tre processori: due di essi interagiscono con un sottosistema di comunica-zione per compiere il trasferimento delle informazioni da nodo a nodo, il terzo esegue il codice applicativo. Le porte di comunicazione del Neuron Chip possono essere configurate in modi diversi in base al tipo di transcei-ver ed essere predisposte per operare su un vasto campo di data rates. Cia-scun Neuron Chip racchiude inoltre il protocollo LonTalk come parte del proprio firmware (è il protocollo di comunicazione, aperto e basato sul modello di referenza OSI).

Il protocollo LonTalk contiene un servizio speciale per provvedere alla massima sicurezza della comunicazione-autenticazione. L’autenti-cazione permette al ricevente di un messaggio convalidato di verificare l’identità del mittente. Ciò può essere fatto mediante un comando di ge-stione rete al momento dell’installazione. L’autenticazione previene acces-si non autorizzati ai nodi e alle loro applicazioni. Per esempio un tecnico delle luci non potrà operare su un dispositivo di sicurezza se non è stato autorizzato.



2.6.2 Il sistema CONTATTO di DUEMMEGI Contatto è un sistema modulare che consente di gestire un certo

numero di ingressi e di uscite in maniera semplice e versatile riducendo i collegamenti da effettuare sia in caso di installazione che in caso di modi-fiche rispetto ad un impianto tradizionale.

La configurazione minima è costituita da tre moduli: ü Unità di controllo; ü Modulo di ingresso; ü Modulo di uscita.

Per ogni unità di controllo la configurazione massima prevede la

gestione di 127x8 (1016) punti di ingresso ed altrettanti punti di uscita. Utilizzando più controllori MCP (modulo di controllo programma-

bile), che nella rete possono arrivare ad un massimo di 31 unità, si possono ottenere in totale circa 31500 ingressi e uscite.

Ciascun modulo possiede una memoria non volatile, atta a contene-re i dati di configurazione. L’unità di controllo memorizza la configura-zione del sistema, ossia il numero di coppie di moduli ingresso/uscita pre-senti, mentre questi ultimi memorizzano il loro indirizzo che permette di identificare ogni modulo all’interno del sistema. Il modulo di controllo ge-stisce lo scambio di informazioni tra i moduli di ingresso e di uscita; più precisamente esso esegue una richiesta dello stato degli ingressi ad ogni modulo ed invia il corrispondente comando al modulo/i di uscita associa-to/i.

Tutti i moduli di ingresso possono, in qualunque istante, inviare un messaggio per segnalare una variazione di stato di uno o più ingressi ri-spetto allo stato precedente, riducendo drasticamente i tempi di risposta che si avrebbero sfruttando unicamente il “polling ciclico”.

Tutti i moduli sono collegati tra loro da una linea a 4 fili, di cui due costituiscono la linea di trasmissione vera e propria e gli altri due alimen-tano i moduli.

Sono possibili sostanzialmente due tipi di configurazione:

· Ingresso – Uscita senza l’uso di alcun software. In questo caso il si-stema è costituito da un modulo di controllo e da “n” moduli di in-gresso e di uscita. Ad ogni modulo viene assegnato un numero da 1



a 127 e ciascun modulo di ingresso (analogico o digitale) dialogherà solo col suo corrispondente modulo di uscita.

· Ingresso – Uscita con l’uso di software. Qualora si voglia realizzare

l’impianto in modo da eseguire i comandi non da un solo punto ma da più punti, oppure da creare libere associazioni fra ingressi e usci-te introducendo tutte quelle relazioni abitualmente impiegate nelle installazioni elettriche (and,or, passo-passo, marcia-arresto, contato-re, temporizzazioni, soglie su ingressi analogici, orologi, …), è suf-ficiente utilizzare un’interfaccia programmabile (MCP) nella quale verranno inserite, tramite opportuni supporti di sviluppo, tutte le funzioni occorrenti, lasciando inalterata la struttura dell’impianto. Questo permette di realizzare impianti semplici con possibilità di ampliabilità fino a realizzare una completa telegestione tramite mo-dem-PC. In particolare, collegando il controllore MCP ad un perso-nal computer, è possibile disporre di un sistema di supervisione in grado di controllare e gestire un impianto attraverso pagine grafi-che. Questa ampia panoramica mostra solo parte del mercato

dell’automazione domestica; dall’altro lato, tutti i fornitori di servizi do-mestici si stanno attrezzando per poter facilitare la diffusione della domo-tica in tutte le abitazioni, con importanti novità sia nel campo delle com-pagnie di fornitura di servizi, sia da produttori di elettrodomestici. A que-sto punto è facile immaginare le numerose soluzioni personalizzabili a se-conda delle esigenze dell’utente finale.

Capitolo 3 TV Digitale Terrestre

3.1 La TV Digitale Terrestre

La D.T.T. ovvero "Digital Terrestrial Television" e' in Italia una re-altà che si sta consolidando in questo periodo, indubbiamente spinta dalle forti pressioni politiche e dei media stessi; tale innovazione non è però un optional per i telespettatori, ma una scelta obbligata, visto e considerato che, entro il 2006, dovrà essere abolita la rete televisiva VHF e UHF ana-logica.

I vantaggi immediati saranno molteplici, uno su tutti la possibilità di moltiplicare il numero di canali trasmissibili attraverso le stesse frequenze oggi utilizzate dalla Tv analogica. Ogni singola frequenza utilizzata in analogico, infatti, permette di trasmettere un solo canale televisivo. Grazie al digitale, dunque, sarà possibile trasmettere audio e video insieme, attra-verso una codifica numerica delle informazioni. Si potrà così moltiplicare fino a cinque/sei il numero di canali trasmessi contemporaneamente su una sola frequenza. Ciò significa che con gli stessi televisori e le stesse anten-

Cap. 3 - TV digitale terrestre


ne di oggi, oltre all'adattatore digitale, sarà possibile vedere una cinquanti-na di canali anziché i dodici attuali.

La moltiplicazione dei canali televisivi non è l’unico vantaggio, tra gli altri si può ricordare la riduzione dell'inquinamento elettromagnetico (per diffondere i programmi TV in digitale sono sufficienti potenze di tra-smissione molto più basse di quelle attuali), la migliore qualità delle im-magini (trattasi di segnale numerico che non risente d’interferenze né di riduzione del segnale né di disturbi), la possibilità di vedere film nel for-mato 16:9 anziché nel 4:3 tradizionale, la fruizione di servizi interattivi sempre più sofisticati, permettendo ai canali Tv e alle trasmissioni televi-sive di inserire contenuti multimediali innovativi.

Il passaggio dalla Tv analogica alla Tv digitale coinvolgerà progres-sivamente oltre 50 milioni di apparecchi televisivi, praticamente tutta la popolazione italiana. Per la ricezione dei programmi TV digitali, gli utenti dovranno possedere un apposito ricevitore (Set-Top-Box) da collegare al proprio televisore.

I ricevitori per il DVB-T affiancheranno presto i televisori nelle ca-se dei cittadini italiani, come avviene per quelli DVB-S per la TV da Satel-lite; è dunque plausibile cercare di orientare una fetta della ricerca nella di-rezione dello sviluppo di questa tecnologia, per poter fornire prestazioni e servizi sempre migliori, muovendosi parallelamente a quelle che sono le richieste del mercato; molteplici sono le applicazioni che si può immagina-re di realizzare avendo a disposizione una cosiddetta “TV interattiva”, una serie di strumenti utili al cittadino per le operazioni più consuete (opera-zioni bancarie, prenotazione esami clinici, espletamento di pratiche buro-cratiche, teletex avanzato, connessione ad internet, …). Una consistente fonte di business potrebbe trovarsi in quelle applicazioni che suscitano l’interesse del telespettatore medio, come il televoto, la partecipazione di-retta a quiz attraverso il telecomando, concorsi a premi, pubblicità interat-tiva.

Oggi non si è ancora in grado di prevedere con esattezza dove por-terà l’introduzione di queste nuove tecnologie, ma è indubbia la conver-genza tra la televisione, l’informatica e le telecomunicazioni. Al contem-po, il coinvolgimento dei cittadini nella Società dell’Informazione, incon-tra una barriera nella limitata diffusione del PC rispetto alla totalità della popolazione, determinando la potenziale esclusione di una larga fascia di essa. L’idea di base resta quella di rendere l’apparecchio televisivo uno strumento efficace e comodo per sviluppare servizi interattivi, che si ag-



giungono alla tradizionale funzione di fruizione dei programmi televisivi (mantenendo, in Italia come in Europa, l’altissimo tasso di penetrazione della televisione analogica).

Sebbene sia immediato sottolineare i vantaggi dell’innovazione tec-nologica – nascita di nuovi servizi, opportunità di crescita del settore au-diovisivo, rafforzamento del grado del pluralismo informativo – non è da trascurare l’esistenza di talune difficoltà legate al periodo di transizione.

La sfida principale è quella della ricezione da parte degli utenti, la cui riuscita è il presupposto per la fine delle trasmissioni analogiche. La maggior parte delle famiglie, infatti, al momento dello switch-off dovrà essere dotata dei decodificatori digitali, per il rischio che il processo tecno-logico finisca per creare nuove fratture sociali. Un altro aspetto critico del-la transizione è rappresentato dalla scarsità di frequenze, che sarà resa più acuta dalla necessità di assicurare la continuazione delle trasmissioni ana-logiche parallelamente allo sviluppo delle nuove trasmissioni digitali.

3.1.1 La situazione Europea La Commissione europea, che ha già emanato due recenti comuni-

cazioni in tema di digitale terrestre – una sul periodo di transizione dall’analogico al digitale e una sulle barriere che ancora si frappongono all’accesso alle piattaforme a larga banda – ha manifestato l’intenzione di monitorare questo processo, per assicurare che gli interventi di sostegno che gli Stati porranno in essere siano conformi ai principi comunitari di li-bera concorrenza. Per raggiungere questo obiettivo ha invitato tutti gli Sta-ti membri a rendere note le proprie strategie, con l’obiettivo di stimolare il più possibile la transizione rapida ai sistemi di radiodiffusione in tecnica digitale, cercando di minimizzare gli svantaggi del breve periodo legati al-la necessità di operare una modernizzazione tecnica a tutti i livelli.

Il digitale lanciato in Europa inizialmente da poche nazioni come Gran Bretagna, Svezia, Finlandia, e Spagna non ha avuto gran successo, infatti il massimo di telespettatori realizzato dalle tv era intorno ai 200.000 utenti; il sistema ha compreso che il servizio offerto deve essere gratuito (infatti, in Inghilterra e' ricevuto oggi da un numero d'utenti intorno ai 2 milioni); successivamente il resto delle nazioni Europee si è lanciato in questo progetto. La situazione attuale può essere così brevemente riassun-ta:



Data di lancio Passaggio definitivo

Gran Bretagna 1998 2006/2010

Spagna 2001 2007/2009

Francia 2003 2010/2015

Germania 2002 2010

Finlandia 2000 2006

Danimarca 2001 2007

Olanda 2003 2005/2006

Italia 2003 2006/2007

Tabella 3.1.

3.1.2 Digitale terrestre in Italia Per quanto riguarda le date previste per lo switch-off, l’Italia è stata

il primo Paese a porsi come obiettivo (legge n. 66 del 2001) il completa-mento del passaggio al digitale entro il 31 dicembre 2006. Il processo di trasformazione viene accelerato e favorito anche attraverso la definizione di una disciplina transitoria che stabilisce le tappe intermedie per lo svi-luppo della nuova tecnologia ed agevola la diffusione presso le famiglie i-taliane dei nuovi apparati di ricezione; norme miranti a realizzare una tran-sizione in tempi rapidi, preferibilmente senza penalizzare l’utenza. Sono inoltre previsti, già all’atto di approvazione della legge:

ü Una fase di avvio della nuova tecnica trasmissiva con la coesistenza

del sistema analogico e del sistema digitale; ü Una temporizzazione precisa, a partire dal 1° gennaio 2004, degli

obblighi di copertura dei multiplex affidati alla concessionaria del servizio pubblico radiotelevisivo;



ü L’obbligo per tutti gli altri operatori che intendono ottenere la li-cenza di operatore di rete di raggiungere una copertura non inferiore al 50 per cento della popolazione o del bacino locale;

ü Gli incentivi alla diffusione dei Set-Top-Box per la ricezione dei programmi in digitale.

Precedentemente al disegno di legge citato, erano state già definite

le azioni necessarie a consentire l’avvio della sperimentazione, fase parti-colarmente critica, stante il notevole tasso di occupazione dello spettro, che ha richiesto il ricorso a misure particolari; le frequenze sono state di-stribuite senza asta (a condizione che fossero utilizzate per la sperimenta-zione del digitale).

Il primo approccio al digitale terrestre in Italia è stato caratterizzato da una notevole spinta da parte delle principali emittenti, che sin dai primi mesi del 2004 hanno investito numerose risorse; esemplificativo può esse-re lo schema di seguito riportato.

RAI MEDIASET LA7/MTV

Data di lancio 31/12/2003 1/12/2003 13/12/2003

Copertura popolazione al 3/2/2004

50-60% 51% 51%

Tabella 3.2.

L'Italia sarà, assieme alla Finlandia, il primo paese a fare lo switch-

off definitivo (2006), mentre l'ultimo sarà la Francia nel 2015, ammesso che le iniziative intraprese rispettino i termini fissati (infatti non è una data troppo realistica, ma perlomeno serve a tracciare una strada per la speri-mentazione).

Positivo sarà l’impatto derivante all’economia dalla messa in moto di un importante processo di investimenti da parte degli operatori del set-tore e di spesa da parte degli utenti. Si tratta di un processo che non investe solo l’Italia ma anche la maggior parte dei Paesi dell’Unione europea.

Oggi non si può ancora apprezzare la trasmissione digitale terrestre al cento per cento. Il vantaggio che può apportare al momento è una visio-



ne più nitida delle immagini, in qualità DVD in pratica. L’introduzione della televisione digitale terrestre gioca un ruolo di primo piano perché questa tecnologia rientra tra quelle che realizzano l’accesso multipiatta-forma a larga banda ed ampliano le possibilità di scelta dei cittadini; si tratta, insomma, di un salto tecnologico di valore esponenziale. Il dato che è emerso dalla recente Conferenza Ministeriale Europea, dove si sono con-frontate le esperienze in atto nei vari Paesi, è che ci si stia trovando di fronte ad una semplice trasformazione tecnologica, ma che riveste impli-cazioni di carattere sociale, economico e culturale.

3.2 DVB – Digital Video Broadcasting La Direttiva europea del 95/47/CE del Parlamento Europeo, del 24

ottobre 1995, relativa all’impiego di norme per l’emissione di segnali tele-visivi, stabilisce, riassumendo brevemente, che «Tutti i servizi televisivi trasmessi ad utenti della Comunità Europea via cavo, satellite ed etere, devono, nel caso di trasmissioni digitali, utilizzare un sistema di trasmis-sione standardizzato da un ente europeo di standardizzazione riconosciu-to».

All'origine delle attività europee per lo sviluppo delle tecnologie di trasmissione digitale è nato quindi il progetto Digital Video Broadcasting (DVB), una vera e propria commissione per lo sviluppo delle piattaforme digitali, promosso dalla Commissione Europea proprio con lo scopo di de-finire una serie di standard comuni.

Al progetto partecipano oltre 300 società di 35 paesi, esse sono di-rettamente coinvolte nei diversi settori dell'industria televisiva: la trasmis-sione, la produzione dell'hardware, lo sviluppo del software, la gestione delle reti, la produzione dei contenuti. Il progetto DVB ha lo scopo di sta-bilire un unico standard condivisibile su scala europea per le trasmissioni televisive digitali via satellite (DVB-S), via cavo (DVB-C) e via terra (DVB-T); fino ad ora l’operato del consorzio DVB è stato encomiabile (basti pensare che gli standard sono stati recentemente adottati anche dal Giappone e da altri paesi non europei).

L’ETSI, l’ente di standardizzazione europeo, ha pubblicato un set di standard derivati dalle specifiche del progetto DVB. Di conseguenza tutti i servizi digitali televisivi in Europa sono conformi a tali standard DVB dell’ETSI. La Direttiva stabilisce anche che «In questo contesto, un siste-



ma di trasmissione comprende i seguenti elementi: formattazione dei pro-grammi (codifica di sorgente dei segnali audio e video, multiplazione dei segnali) ed adattamento ai mezzi trasmissivi (codifica di canale, modula-zione e tecniche di dispersione dell’energia) ».

Ciò corrisponde agli aspetti (1) e (5) di cui nella tabella 3.3. La Di-rettiva esclude quindi, dal suo ambito di applicabilità, i rimanenti elementi (gestione di applicazioni, accesso condizionato, sicurezza); l’assenza di tali specifiche ha fatto sì che nella maggioranza dei Paesi Europei la tele-visione digitale è stata lanciata da operatori di televisioni a pagamento che hanno utilizzato differenti standard proprietari per creare mercati verticali. La loro motivazione si è fondata sul fatto che la mancanza di interoperabi-lità apportasse un vantaggio competitivo, legando gli utenti ad una specifi-ca piattaforma. Il regolatore europeo è stato generalmente riluttante a in-tervenire su tale problema, al fine di non scoraggiare gli investimenti na-scenti nel settore con vincoli troppo stringenti.

Come conseguenza sono state sviluppate molteplici interfacce sof-tware dette API (Application Programming Interface), tutte incompatibili tra loro. In particolare, i programmi multimediali e interattivi non possono essere eseguiti su ogni piattaforma, ma vanno sviluppati con riferimento ad una particolare specifica di API.

1 Multiplazione e trasmissione di programmi televisivi, di dati e di servizi, siano essi diffusi via satellite, via etere terrestre, via cavo

2 Gestione delle applicazioni multimediali e interattive

3 Gestione dell’accesso condizionato

4 Gestione della sicurezza dei dati interattivi

5 Compressione e codifica del audio/video digitale

Tabella 3.3.

Aspetti tecnologici che concorrono nella piattaforma digitale

In generale si può dire che ogni applicazione multimediale o interat-tiva utilizzerà le funzionalità disponibili nel decoder. Per gli aspetti di cui in (2), (3) ed (4) dunque, l’esistenza di varie norme rende problematica la



ricevibilità dei programmi diffusi dalle varie emittenti con un qualsiasi STB.

Per la gestione delle applicazioni, ad esempio, esistono la norma ISO-MHEG5 già in esercizio commerciale nel Regno Unito e - successiva in ordine di tempo - la norma ETSI/MHP, più flessibile della prima, in gran parte consolidata e recentemente entrata definitivamente in esercizio in molti Paesi Europei, ponendo probabilmente le basi per la soluzione del problema sopra citato.

3.3 La piattaforma MHP Il gruppo di progetto DVB lavora sin dal 1997 alle specifiche relati-

ve ad uno standard aperto, per la gestione della multimedialità e dell’interattività: il DVB-MHP (Digital Video Broadcasting – Multimedia Home Platform). Nasce un nuovo gruppo di lavoro con l’incarico di redi-gere una lista dettagliata di requisiti che il nuovo standard dovrà soddisfa-re. Entrano a far parte di questo gruppo numerose aziende del settore, tra le quali la Sun Microsystems®, che contribuirà allo sviluppo di una piatta-forma basata su Java™.

Figura 3.1.

Aspetti tecnologici che concorrono nella piattaforma digitale



Questo standard è aperto all’utilizzo di ogni soggetto interessato, anche non membro del DVB, permettendo a gruppi diversi di interoperare, rispettando le specifiche minime della piattaforma; gli apparati di ricezio-ne diventano intercambiabili tra loro e i gestori delle reti possono utilizza-re servizi diversi verso apparati diversi. I principali benefici della specifica MHP (come per qualunque standard pubblicato) sono:

ü Standard aperto, orientato a garantire la piena interoperabilità tra

qualsiasi programma irradiato e qualsiasi tipo di ricevitore a casa dell’utente (fatta salva la distinzione tra profili);

ü Costi più economici per le licenze di utilizzo della piattaforma, ri-spetto all’utilizzo di piattaforme proprietarie;

ü Possibilità di scegliere tra molti più fornitori, che non nel caso di soluzioni proprietarie.

Poiché si prevede che a lungo termine lo standard DVB-MHP sarà pro-

babilmente adottato quasi universalmente; la sua introduzione destrutture-rà il modello di mercato verticale o proprietario delle piattaforme software esistenti degli attuali service providers. Tuttavia, nel breve-medio termine, l’affermazione della piattaforma MHP potrà incontrare vari problemi di af-fermazione. Lo standard presenta anche alcune lacune, tra queste quella di non coprire pienamente l’aspetto dell’accesso condizionato per il quale, poiché si entra nel campo della Pay Tv, esistono molti standard proprietari e non si può sperare in nulla di più che nella presenza di STB con Com-mon Interface, cioè con un ingresso (slot) in grado di ospitare schede del tipo PCMCIA per il supporto di vari standard di crittazione del segnale te-levisivo. In questo modo, l’utente può con lo stesso apparecchio, cambian-do solo la scheda PCMCIA, ricevere canali crittati secondo vari standard. L’aspetto della sicurezza delle transazioni è coperto nello standard solo dal profilo Internet access (par. 3.6.3).

3.4 Tecnologie di distribuzione DVB-T Una volta realizzata l’applicazione MHP deve essere distribuita ai

terminali; lo standard adempie alla descrizione di questo processo in modo esaustivo. Lo standard prevede tecniche differenti, tra le quali si possono citare connessioni punto-punto tra terminale e fornitore del servizio oppu-



re installazione remota del software sul terminale (non trattate in questa sezione).

La metodologia di distribuzione broadcast più diffusa tra quelle previste dallo standard (cfr. Figura 3.2) prevede l’utilizzo del protocollo DSM-CC Object Carousel (Digital Storage Media - Command and Control) che consente di rendere completamente trasparente il software al sistema di trasmissione: all’interno del terminale viene ricostruita local-mente la struttura dati dell’applicazione, senza introdurre complessità cor-relate con il canale di trasmissione.

Figura 3.2. Protocolli supportati per il canale broadcast

Il DSM-CC è una estensione dell’MPEG, il cui scopo è trasmettere

dati ai ricevitori; essenzialmente include due differenti metodi di broadcasting, l’MHP ne utilizza solo una piccola parte, in particolare il metodo Object Carousel (in modo limitato).

In particolare, i dati sono strutturati all’interno di un “file system”, messo in onda nella forma di “carousel”: un Object Carousel è una struttu-ra ad albero che è divisa in una serie di moduli; ciascun modulo può con-tener diversi file, raggiungendo una capacità massima di 64 Kbytes; file più grandi di 64 Kbytes devono essere impacchettati in moduli che conter-ranno solo tali file. I moduli vengono quindi trasmessi sequenzialmete e



ciclicamente, il ricevitore potrà accedere ad ogni file quando avrà ricevuto tutti i moduli in cui è contenuto, potrà altresì visualizzare l’applicazione quando avrà ricevuto tutti i file necessari. Questa tecnica non è efficiente quando la dimensione totale dei dati trasmessi è elevata.

La trasmissione dei dati, ripetuta ciclicamente, ha un periodo di ri-petizione pari al quoziente della quantità totale in byte di dati da trasmette-re divisa per la velocità di trasmissione disponibile. In assenza di accorgi-menti correttivi, che nello standard MHP non sono specificati, la durata del periodo di ripetizione viene percepita dall’utente come una latenza di accesso alle varie funzionalità del servizio. Tali servizi possono avere la necessità di memorizzare alcuni parametri di configurazione, nonché even-tuali dati concernenti le preferenze dell’utente, in modo persistente rispetto allo spegnimento del terminale (al fine di evitare continue e fastidiose ri-chieste all’utente di inserire dati personali e/o di configurazione, e per con-sentire una progressiva personalizzazione dell’interfaccia utente e del for-mato di presentazione).

La televisione digitale terrestre prevede la trasmissione usando se-gnali elettromagnetici con frequenze comprese tra 30MHz e 3GHz usando come mezzo trasmissivo l'aria. Al DVB-T sono stati assegnate le bande III della gamma VHF e le bande IV e V della gamma VHF. Si utilizzano ca-nali di 8 MHz (opzionali 6 e 7) con diverso segnale portante, tipo di modu-lazione e schema di codifica che può essere QPSK (Quadrate Phased Shift Key), 16 QAM (Quadrate Amplitude Modulation) e 64 QAM. Il multiple-xing viene fatto con COFDM (Coded Orthogonal Frequency Division Multiplexed).2

Per analizzare in maggior dettaglio i diversi sistemi di trasmissione digitale terrestre introduciamo un modello di architettura di rete (cfr. Figu-ra 3.3).

Le componenti e le funzioni del modello rappresentato sono i se-guenti: ü Il playout, la cui funzione è di codificare ed assemblare programmi,

dati e informazioni, creando il transport-stream (flusso digitale per il trasporto);

ü La rete di distribuzione, che trasferisce il transport-stream all'in-gresso dei trasmettitori della rete di diffusione;

2 ETSI TR 101 190 V1.1.1, Digital video broadcasting (DVB) ; implementation guide line for DVB terrestrial Services; Trasmission Aspect



ü La rete di diffusione, che irradia verso gli utenti il segnale costituito dal transport-stream;

ü Il sistema ricevente di utente, costituito dall'impianto di antenna ri-cevente individuale o condominiale;

ü Il terminale di utente, costituito dal ricevitore integrato digitale o dal set-top box da applicare al ricevitore analogico;

ü Il modulo per il servizio interattivo.

Figura 3.3. Modello di architettura di una rete DVB-T

3.4.1 Playout Nel centro playout (cfr. Figura 3.4) i programmi televisivi sono co-

dificati nello standard MPEG-2 e assemblati dal multiplex insieme con al-tri dati e informazioni. Il transport-stream in uscita dal multiplex viene in-viato al SFN adapter (quando necessario) che crea la struttura di Mega Frame e inserisce il MIP (Mega Frame Initialization Packet). Il network adapter ha la funzione di interfacciare la rete di distribuzione che alimenta i trasmettitori della rete di diffusione. L'SFN adapter è usato solo quando la rete è del tipo SFN, in quanto non necessario nel caso in cui tale rete sia del tipo MFN; la sua funzione è di inserire i segnali GPS (Global Position



System), ricevuti attraverso un opportuno ricevitore, per la sincronizzazio-ne del transport-stream necessaria per il funzionamento delle reti SFN.

Si evidenzia che il playout è sostanzialmente lo stesso sia quando le reti di diffusione utilizzate siano del tipo SFN che del tipo MFN (nel se-condo caso manca il modulo SFN adapter).

Figura 3.4. Schema generale del Playout

3.4.2 Rete di distribuzione La rete di distribuzione ha la funzione di trasferire il segnale in usci-

ta dal playout ai trasmettitori delle reti di diffusione. Le reti di distribuzio-ne possono essere realizzate attraverso ponti radio terrestri, fibre ottiche o satelliti.

Le reti di distribuzione attualmente utilizzate in Italia per la televi-sione analogica sfruttano prevalentemente ponti radio terrestri. Per il tra-sporto del segnale digitale è necessario che esse siano convertite alla nuo-va tecnologia. Questo tipo di rete si adatta facilmente alla distribuzione sia di programmi nazionali sia di programmi locali. La realizzazione di reti in



fibra ottica presenta in generale difficoltà per quanto riguarda la distribu-zione dei segnali televisivi. Tale difficoltà risulta evidente data la difficile collocazione geografica dei trasmettitori. Ciò comporta una struttura di re-te ad albero, costituita da una dorsale e tante ramificazioni quanti sono i trasmettitori della rete di diffusione da alimentare. Le reti di distribuzione non devono introdurre ritardi nel trasporto del segnale digitale superiori a 1 secondo, affinché possano essere compensati all'SFN-sync.

3.4.3 Rete di diffusione La tecnologia digitale consente di pianificare reti utilizzabili per lo

sviluppo di reti nazionali e locali di tre tipi:

Reti MFN Multiple Frequency

Network

Utilizzano più frequenze, diverse l'una dall'altra, per la loro realizzazione.

Reti SFN Single Frequency

Network

Richiedono la stessa frequenza per tutti gli im-pianti trasmittenti che le compongono. Sono tipi-camente costituite da pochi impianti.

Reti MFN-SFN (k-SFN)

Reti miste ossia reti MFN estese localmente con reti SFN. Permettono di servire una maggiore porzione di territorio e di popolazione, con un in-cremento limitato del numero degli impianti.

Tabella 3.4.

3.4.3.1 Hardware delle reti di diffusione Per quanto riguarda l'hardware delle reti di diffusione, si possono

grossolanamente distinguere i seguenti tipi di impianti: trasmettitore, ripe-titore, gap filler (tabella 3.5).

Da segnalare anche che i vari tipi di reti possono essere progettate per servizi rivolti prevalentemente all'utenza fissa o all'utenza mobile. Nel



primo caso è più adatta la modalità di modulazione OFDM4 a 2000 por-tanti, nel secondo caso è da preferire la modalità a 8000 portanti.

Trasmettitore Che riceve in banda base il transport-stream da irradiare direttamente dalla rete di distribuzione.

Ripetitore

Riceve in banda base il transport-stream da irradiare da un trasmettitore. La frequenza di funzionamento del ri-petitore è diversa da quella del trasmettitore da cui rice-ve il segnale da irradiare. Questo tipo di apparato è uti-lizzato per l'estensione dell'area di servizio della rete;

Gap-filler

Riceve il segnale in alta frequenza irradiato da un tra-smettitore ripetitore e re-irradia sulla stessa frequenza di funzionamento senza passare per la banda base; è uti-lizzato per servire piccole zone d'ombra all'interno del-l'area di servizio di un trasmettitore.

Tabella 3.5. Impianti di base delle reti di diffusione

3.4.3.2 SFN

Le reti SFN, si usano quando si devono irradiare gli stessi pro-grammi e servizi in una stessa area, cioè quando non è richiesto né l’inserimento nel transport-stream di nuovi contenuti, né la sostituzione di parti del contenuto. La criticità di questo tipo di reti risiede nel fatto che tutti i trasmettitori devono diffondere lo stesso transport-stream in uscita dal playout in un intervallo di tempo non superiore a 1 sec. Ciò comporta la necessità di sincronizzare tutti i trasmettitori. Questo si realizza con l'in-serimento nel transport-stream di segnali GPS (per mezzo di un SFN adap-ter). Tali segnali sono poi confrontati con quelli ricevuti tramite il GPS. Il confronto avviene per mezzo del modulo SFN-sync che provvede, anche, a compensare il tempo di propagazione sulla base della differenza calcolata tra l'istante di invio (uscita dal playout) e l'istante d'arrivo all'ingresso di ciascun trasmettitore della rete. Le reti SFN sono costituite da trasmettitori e gap-filler. I ripetitori non possono essere utilizzati nella realizzazione di



queste reti in quanto non è possibile compensare le differenze nei tempi di propagazione.

Figura 3.5. Modello di diffusione SFN

L'uso di gap-filler presenta alcune difficoltà che riguardano in parti-colare il raggiungimento dell'elevato disaccoppiamento tra antenna rice-vente e antenna trasmittente (riduzione della qualità del segnale). Lo schema generale del sistema da utilizzare per il servizio diffuso tramite reti SFN è riportato nella figura 3.5.

Figura 3.6. Modello di diffusione MFN



In sintesi il sistema SFN opera come segue: il transport-stream, nel quale sono inseriti anche i segnali GPS di sincronizzazione, viene trasferi-to ai trasmettitori attraverso la rete di distribuzione. Nel centro trasmittente si compensa tramite l'SFN-sync il ritardo accumulato dal transport-stream che viene poi irradiato dal trasmettitore.

3.4.3.3 MFN

Le reti MFN (dette anche Conventionally Planned Networks) pos-sono essere impiegate per la diffusione di programmi e servizi sia in ambi-to nazionale che locale.

La loro caratteristica è data dalla possibilità di inserire nel transport-stream nuovi contenuti o parti di essi da irradiare in aree specifiche del complessivo ambito territoriale servito dalla rete. Va ricordato, inoltre, che questo tipo di rete ha la proprietà di essere decomponibile. I trasmettitori delle reti in questione non necessitano di essere sincronizzati come nel ca-so delle reti SFN. Ne consegue che nei relativi playout non sono presenti i ricevitori GPS e gli SFN adapter; analogamente, nei trasmettitori mancano sia i ricevitori GPS che i moduli SFN-sync. Le reti MFN sono costituite da trasmettitori e ripetitori. Difficilmente vengono usati gap-filler. Gli im-pianti ripetitori sono utilizzati per l'estensione delle aree servite dai tra-smettitori e sono allocati al di fuori di tali aree. Va segnalato che in Italia la normativa vigente per l'elaborazione dei piani di assegnazione delle fre-quenze prevede che per i collegamenti tra impianti di diffusione si debba-no usare ponti radio, cavo o satellite, con la conseguenza che per i ripetito-ri non è prevista alcuna protezione dalle interferenze. Questo fatto limita fortemente l'uso di ripetitori nelle reti in esame. Se si considera, come e-sempio, una rete nazionale MFN che viene decomposta in reti regionali, si ha il modello schematico del sistema per servizi nazionali e servizi regio-nali che è riportato nella figura 3.6.

Il funzionamento può essere sinteticamente descritto come segue: dal playout nazionale il transport-stream è inviato ai playout regionali me-diante una rete di distribuzione nazionale SFN. Nei playout regionali, se previsto, vengono eliminati alcuni programmi provenienti dal playout na-zionale, inseriti contenuti locali (provenienti per esempio dalle emittenti locali) e aggiornate le informazioni contenute nel SI (Service Information).



L'uscita dal playout regionale viene quindi inviata tramite la rete di distri-buzione regionale ai trasmettitori della rete regionale di diffusione.

3.4.3.4 k-SFN

Una rete k-SFN è una rete costituita da k > 1 sottoreti isofrequen-ziali (SFN locali), ciascuna delle quali utilizza la composizione degli echi isofrequenza che cadono all'interno della finestra di guardia. In particolare, in una rete k-SFN a servizio nazionale si compongono tutti gli echi isofre-quenza che cadono nella finestra di guardia, mentre in una rete k-SFN a servizio regionale si compongono costruttivamente i soli echi isofrequenza che giungono al ricevitore da siti la cui area di servizio appartiene alla re-gione in esame. La copertura totale di una rete k-SFN nella specifica area geografica è data dalla somma delle coperture delle k sottoreti.

I suddetti tipi di reti si distinguono anche per quanto riguarda la loro capacità di trasmissione, minore per le reti SFN rispetto alle reti MFN. Ciò comporta che le reti SFN possono, rispetto alle reti MFN, trasmettere un minore numero di programmi o lo stesso numero di programmi ma con minore qualità. Le reti pianificate a livello nazionale possono essere de-componibili in reti a livello regionale, provinciale o sub-provinciale. Su ogni rete possono essere trasmessi più programmi e servizi (almeno 4 programmi oltre ai servizi).

L’espressione “reti pianificate a livello nazionale” non si riferisce ad una nazionalizzazione dell’emittenza, ma ad una modalità di pianifica-zione degli impianti da utilizzare sia a livello nazionale che locale.

È bene sottolineare che gli esempi sopra riportati si identificano a schemi rigidi, per natura puramente teorici.

3.4.4 Sistemi di ricezione d’utente

I sistemi riceventi d'utente si suddividono in due grandi categorie:

ü Sistemi di ricezione individuali, che utilizzano come componenti fondamentali dell'impianto il sistema di antenne e la rete di distri-buzione interna agli edifici (vi rientra in alcuni casi anche l'amplifi-catore).



ü Sistemi di ricezione centralizzata, i cui componenti fondamentali comprendono: il sistema di antenne, il preamplificatore, la centrale di testa (che può essere a larga banda, a bande separate o canalizza-ta) e la rete di distribuzione interna agli edifici. I sistemi centralizzati si suddividono in:

ü Sistemi MAT V (Master Antenna TV), che distribuiscono segnali terrestri captati dal sistema d'antenna, tipicamente nelle bande VHF e UHF, ma talvolta includono la distribuzione di segnali inseriti lo-calmente (per esempio quelli generati da telecamere di controllo per la sicurezza);

ü Sistemi SMAT V (Satellite Master Antenna TV) che, oltre ai segna-li terrestri, captano e distribuiscono anche segnali provenienti da sa-tellite, che vengono convertiti in antenna nella banda di prima fre-quenza intermedia (1 IF) da 950 a 2150 MHz. Gli impianti di ricezione attualmente in uso nel territorio sono mol-

to spesso approssimativi, se non addirittura di fortuna. L'obsolescenza de-gli impianti costituisce un handicap per un'adeguata distribuzione dei se-gnali digitali, si richiederà quindi un adeguamento delle infrastrutture e una maggiore organizzazione degli impianti di ricezione centralizzati.

3.5 Architettura base della piattaforma MHP

L’architettura base della piattaforma MHP è caratterizzata da tre li-

velli:

ü Applicazioni ü Software di sistema ü Risorse o periferiche

La Figura 3.7 mette in evidenza l’interconnessione tra terminale ed

applicazioni a prescindere dal fatto che restino o meno separate le realiz-zazioni delle due parti.



3.5.1 Applicazioni Un’applicazione è la realizzazione funzionale di un servizio interat-tivo composto da moduli programmabili che richiedono funzionalità speci-fiche residenti nell’hardware o nel software del terminale. Nella filosofia MHP le applicazioni sono il nodo centrale, tutto il contesto ruota intorno ad esse; si veda in proposito la figura 3.8 dov’è riportata una rappresenta-zione dell’insieme di interfacce presenti tra applicazioni MHP e il sistema MHP.

Figura 3.7. Architettura funzionale del terminale MHP

Lo standard MHP supporta una grossa varietà di applicazioni come:

ü EPG (Electronic Program Guide); ü Servizi informativi, teletext avanzato; ü Servizi interattivi, navigazione vincolata, navigazione aperta su In-

ternet; ü Servizi transattivi, servizi per e-commerce.

Tuttavia, non si prevede che ogni STB supporti tutta questa varietà di applicazioni (per venire incontro ad una situazione di utenza con esi-



genze molto differenziate e per proporzionare i costi degli apparati di uten-te).

Le applicazioni possono essere di tre tipi: residenti, installabili o scaricabili, si veda in proposito la tabella 3.6.

Figura 3.8. Interfacce tra applicazioni MHP ed il sistema

Residenti

Contengono funzionalità esclusive offerte in modo differente a seconda del decoder considerato – co-stituiscono un fattore di differenziazione dei ter-minali ed un motivo di competizione commerciale tra i produttori

Installabili

Contengono funzionalità aggiuntive che possono andare ad integrare il funzionamento delle appli-cazioni residenti – potrebbero essere offerte da operatori specifici o dai fornitori dei programmi.

Scaricabili

Devono essere conformi allo standard – si presu-me vengano offerte dagli operatori di servizi tele-visivi per arricchire il bouquet dell’offerta al con-sumatore

Tabella 3.6. Tipi di applicazione



3.5.2 Software di sistema

Il Software di sistema del terminale MHP ha accesso diretto alle in-formazioni audio/video ed, in generale, a tutti i dati trasmessi in confor-mità degli standard DVB ed MPEG; vengono qui controllati i componenti hardware, e le interfacce con l’utente, cioè quegli elementi di basso profi-lo annoverabili all’ultimo livello dell’architettura funzionale del terminale MHP (cfr. Figura 3.7)

Il Software di sistema è composto da uno strato detto HAL (Hardware Abstraction Layer) per la gestione delle interconnessioni a basso livello (fisico/elettrico) e da uno strato software (Sistema Operati-vo) per la gestione complessiva delle funzionalità del terminale.

Figura 3.9. Architettura del software di sistema Il software di sistema è caratterizzato in prima parte da una Java

Virtual Machine (Java VM), che rende il sistema operativo molto sempli-ce e, soprattutto, estremamente aperto (per quella che è la filosofia del Java stesso); i terminali MHP sono quindi equivalenti dal punto di vista strutturale, differenti solo in termini di prestazioni, anche perché le appli-cazioni stesse devono essere realizzate in linguaggio Java, supportate da



interfacce API MHP (interfacce software con capacità funzionali e proce-durali identiche per ogni terminale MHP).

3.5.3 Risorse e periferiche

Le risorse e periferiche (interfacce verso l’esterno) del terminale

MHP sono standardizzate solo in parte, è presumibile pensare che lo svi-lupparsi della tecnologia porti ad un relativo accrescimento delle capacità elaborative dei Set-Top-Box. Quella descritta in Tabella 3.7 è una dota-zione solo ipotetica, dipendente anche dalle scelte commerciali dei pro-duttori di apparecchiature.

RISORSE INTERFACCE

Sintonizzatore (tuner) Telecomando

Demodulatore hardware MPEG Modem

Moduli di accesso condizionato Lettore smart-card

Processore Lettore DVD

Memorie (Ram e Flash)

Hard disk

Tabella 3.7. Risorse e periferiche del terminale MHP

3.5.4 API - Java TV Le API (Application Programming Interface) consentono alle appli-

cazioni di richiamare funzioni del sistema operativo e utilizzare risorse hardware del STB con modalità unificata, indipendente dalle applicazioni stesse. In altre parole, le API sollevano gli sviluppatori di applicazioni dal-



la necessità di conoscere i dettagli realizzativi del STB e dei suoi elementi hardware. Si può parlare a questo punto di una vera e propria estensione della piattaforma Java, creata appositamente per implementare tutte le fun-zionalità necessarie per la tv digitale (streaming audio e video in diversi formati, controllo dell'accesso condizionale, accesso ai canali di dati e a servizi informativi, controllo di sintonizzazione per la selezione ed il cam-bio di canale, controlli grafici on-screen, sincronizzazione dei media, con-trollo del ciclo di vita delle applicazioni); tale piattaforma è nota come Java TV, ufficialmente adottata dal DVB per il progetto MHP. Nella figu-ra 3.10 viene descritto l'ambiente hardware e software della piattaforma Java e dell'API JavaTV implementato in un ricevitore per la tv digitale.

L'ambiente software è costituito dalla piattaforma Java, dall'API Ja-vaTV e da un RTOS (real time operating system). A livello più alto, le ap-plicazioni possono utilizzare le librerie di classi dell'API JavaTV o della piattaforma Java. Il sistema operativo controlla l'hardware attraverso un insieme di controlli (device drivers), fornisce a livello di sistema il suppor-to necessario all'implementazione della Java VM. L'API incapsula le fun-zionalità delle librerie del sistema che controllano l'hardware specifico per la televisione. L'API JavaTV fornisce una visione astratta del sistema che permette alle applicazioni (e quindi agli sviluppatori) di utilizzare le risor-se hardware in forma generica. Questo approccio rende possibile la porta-bilità delle applicazioni create con questa API.

Gli operatori televisivi con approccio “verticale” verso il mercato hanno ovviamente mostrato scarso interesse per gli standard ed in partico-lare per quelli riguardanti le API per la gestione della multimedialità e dell’interattività; per esempio nel Regno Unito, che è il Paese europeo ove la televisione digitale ha raggiunto la penetrazione più alta (presente pres-so oltre il 40 per cento delle famiglie), ogni piattaforma digitale ha scelto una API differente. Quindi un operatore generalista come la BBC dovreb-be diffondere i suoi servizi digitali interattivi in più formati diversi, se vo-lesse raggiungere tutti gli utenti dotati di STB digitali.

Si può ipotizzare un chiaro interesse dei grandi operatori del settore ad adottare la piattaforma MHP. Tuttavia, nel breve termine lo standard MHP risulta svantaggiato sul mercato:

· Non è implementato su tutti i decoder oggi in commercio; · Richiede processori più veloci e potenti di quelli necessari in

decoder funzionanti con standard già in commercio;



· Richiede un maggior quantitativo di memoria per la gestione e l’esecuzione delle applicazioni interattive;

· Consente l’accesso Internet solo con il profilo più avanzato e quindi più costoso.

Figura 3.10. Livelli architetturali del Java TV

A causa dei requisiti hardware più spinti sono, quindi, previsti costi più elevati rispetto alle soluzioni basate su piattaforme esistenti. È tuttavia prevedibile che solo tra 2/3 anni i costi associati al sistema MHP saranno competitivi rispetto ai costi offerti da soluzioni più semplici.

L’uso di piattaforme con API differenti rappresenta un ostacolo per lo sviluppo della televisione digitale terrestre. Le API MHP offrono la possibilità di uno standard universale. Tuttavia resta importante prendere in considerazione soluzioni di API aperte, sebbene con funzionalità più limitate. È indubbiamente necessario che a livello nazionale sia chiara la migrazione a medio-lungo termine, verso lo standard delle API MHP.



3.5.5 Plug–in Una soluzione a tutti quei problemi derivanti dall’immissione sul

mercato di un nuovo prodotto (in questo caso lo standard MHP) si trova nell’utilizzo di appositi plug-in: trattasi di componenti software da installa-re nei terminali MHP per rendere compatibili i prodotti delle tecnologie preesistenti (e per evitare che venga posto un freno allo sviluppo del nuovo standard).

La figura 3.11 mostra il ruolo dei plug-in in una piattaforma MHP. Sono previste due tipologie di plug-in:

Tipo A Applicato alle tecnologie di più recente ideazione, costi-tuito essenzialmente da uno strato software per la conver-sione dell’interfaccia non-MHP (una sorta di traduzione delle applicazioni). Può essere realizzato e fornito da sog-getti molteplici.

Tipo B Si applica per aggirare l’architettura MHP, consentendo alle applicazioni di accedere direttamente all’HAL, alle periferiche o alle risorse del terminale in genere. Deve es-sere fornito dai costruttori di terminali.

3.6 Profili

La piattaforma MHP definisce tre profili di ricevitori (paragonabili a tre aree di interesse commerciale), basando la suddivisione sulla tipologia di applicazioni supportate dagli stessi:

ü Enhanced Broadcasting - EB ü Interactive Broadcasting - IB ü Internet Access – IA

A loro volta i tre profili vengono formalmente divisi in due diversi li-

velli evolutivi (non escludendo la possibilità di creare ulteriori livelli e profili con l’affermarsi di quelli esistenti).



Figura 3.11. Plug-in previsti dalla specifica MHP

Le interfacce software (API) che le applicazioni possono utilizzare sono compatibili tra i profili; ciò che varia è la disponibilità di predefiniti sottoinsiemi di interfacce, in base alla conformità ad uno o più profili.

La specifica MHP definisce una serie di regole funzionali, tra le quali quelle che governano il ciclo di vita delle applicazioni scaricabili sulla piattaforma, che sono comuni ai tre profili.

Ad ogni profilo di implementazione corrispondono dotazioni hardware di cui la piattaforma deve obbligatoriamente disporre ed altre che sono considerate raccomandate o opzionali; varia conseguentemente la presenza delle interfacce software necessarie a gestire tali periferiche. Al-cune interfacce software possono essere considerate comunque opzionali. Per disciplinare e facilitare l’interpretazione di una specifica così comples-sa, è presente nello standard una dettagliata descrizione di quelle che sono le prestazioni minime.

3.6.1 Enhanced Broadcast – Livello 1 Permette servizi di radiodiffusione avanzata per arricchire e com-

pletare i servizi televisivi di base per mezzo di contenuti multimediali (ad



esempio brevi audio-video inseribili in notiziari, film, eventi sportivi, ecc.).Inoltre tale profilo permette la trasmissione di servizi di EPG, teletext avanzato e giochi, memorizzandoli nella memoria del terminale d’utente.

Figura 3.12. Profili e livelli MHP

I terminali conformi a questo profilo devono necessariamente essere

dotati di accesso al canale di trasmissione broadcast, mentre la presenza del canale di ritorno è soltanto opzionale. È possibile allestire servizi che combinano le trasmissioni digitali ordinarie con software scaricabili, la-sciando ai broadcaster ed ai costruttori una discreta libertà di progetto.

3.6.2 Interactive Broadcast – Livello 1 Questo profilo richiede la presenza del canale di ritorno; permette di

aggiungere ai servizi del profilo Enhanced Broadcasting servizi di tipo in-terattivo con la possibilità per l’utente di interagire con un centro servizi attraverso un canale di ritorno (interazione tra un terminale e server remo-ti). Sarà quindi possibile offrire servizi di tipo pay come la pubblicità inte-rattiva, le transazioni (home-banking, commercio elettronico) ecc. In tale profilo la navigazione Internet è implicita, cioè codificata all’interno delle



applicazioni e trasparente per l’utente. I servizi interattivi possono essere indipendenti o meno dai contenuti trasmessi in broadcast; a questo livello è anche possibile rendere unidirezionale la trasmissione broadcast, ren-dendo i contenuti che sono ricevibili da ogni utente, accessibili solo da co-loro che ne hanno l’autorizzazione. Le applicazioni presenti in questo pro-filo possono essere scaricabili o residenti (nel secondo caso, di conseguen-za, sono implementate in modo proprietario).

Lo standard prevede il caso in cui si presenti l’esigenza, sempre al fine di offrire la possibilità di utilizzo completo di determinati servizi, di disporre di un identificativo univoco e persistente dell’utente e/o del ter-minale che utilizza; si pensi, ad esempio, all’impostazione di allarmi e av-visi personalizzati che possano essere notificati all’utente via canale broa-dcast, in modo che questi possa, se lo ritiene, intraprendere azioni che im-plichino anche l’avvio di una sessione di comunicazione via canale interat-tivo. Le caratteristiche di tale identificativo devono essere compatibili con l’impiego dei protocolli di comunicazione previsti dalla specifica MHP, e non devono comportare per l’utente la necessità di ripetere più volte l’inserimento di informazioni personali, testi, sequenze numeriche. La rea-lizzazione di alcuni di questi servizi potrebbe altresì richiedere che le ap-plicazioni software possano avere accesso ad una o più smart-card connes-se direttamente al terminale MHP tramite lettore di smart-card “embed-ded”, ovvero inserito in un modulo CAM-like connesso allo slot di Inter-faccia Comune. Nello specifico, per permettere all’utente di sfruttare a pieno le potenzialità di tali servizi, il terminale MHP dovrebbe disporre di un lettore smart-card, nonché di librerie software a corredo, in modo tale da garantire, aggiuntivamente a quanto prescritto dalla specifica MHP, la conformità allo standard PC/SC, nonché, per quanto riguarda le smart-card, la conformità alle prescrizioni vigenti.

La specifica prescrive la presenza, per le implementazioni conformi al profilo IB1, di almeno un’interfaccia verso un canale bidirezionale che supporti il protocollo IP, che è anche l’unico protocollo di basso livello (I-SO/OSI – Livello 3) esplicitamente previsto dallo standard per il canale in-terattivo (cfr. Figura 3.13). Lo stesso profilo prescrive la disponibilità per le applicazioni di una specifica interfaccia API che consenta la gestione delle connessioni ad un ISP (anche diverso da quello di default, che viene indicato dal costruttore, o dall’utente).



Figura 3.13. Protocolli supportati per il canale interattivo Per fornire il canale interattivo sul STB sono previste due modalità:

tramite modulo di rete (Interactive Interface Module) integrato o tramite modulo di rete esterno. Nella seconda modalità la connessione tra il modu-lo di rete e il Set Top Box (STB) è realizzata mediante la rete digitale do-mestica (In Home Digital Network). Tale rete consente una grande flessi-bilità di installazione facendo uso di interfacce standard di grande diffu-sione su cavo o su portante radio (per es. Ethernet, Wi-fi, Bluetooth, ecc.). Il canale interattivo utilizzerà tecnologia IP, permettendo così la compati-bilità con i servizi informativi basati sulla rete Internet. A questo punto della descrizione si è esattamente al confine tra questo profilo (IB1) e quello successivo (IA1).

3.6.3 Internet Access – Livello 1 Permette l’accesso Internet. Tale profilo offre la possibilità di acce-

dere a servizi di tipo Internet come navigazione su siti Web e consentirà di effettuare transazioni commerciali del tipo e-commerce sfruttando i proto-colli di sicurezza già sviluppati per Internet. L’esistenza di questo profilo rende lo standard MHP tecnicamente molto più potente delle piattaforme esistenti, contemplando le caratteristiche di entrambi i profili precedenti, rappresenta il vero e proprio punto di convergenza tra le tecnologie infor-matiche e televisive.



Sarà interessante seguire gli sviluppi dei sistemi con canale interat-tivo basati su strutture diverse dal semplice collegamento modem (GSM, UMTS/GPRS, ADSL/VDSL). I servizi xDSL sono da tenere in considera-zione soprattutto nella prospettiva di supporto alla modalità “always-on”, ovvero quella modalità per cui l’utente ha accesso permanente alla rete, senza dover stabilire, per ogni sessione di comunicazione, una specifica connessione. La caratteristica “always-on” ha tutta una serie di implica-zioni positive (disponibilità del canale all’accensione del STB, accesso i-stantaneo ai servizi, capacità di ricevere informazioni e aggiornamenti in ogni momento).

Dal punto di vista della sicurezza, la specifica prescrive l’utilizzo del protocollo TLS (IETF RFC 2246), permettendo un livello minimo di autenticazione RSA della firma digitale, “hashing” e la crittografia simme-trica. Sono previsti meccanismi, procedure e dotazioni minime per la ge-stione dei certificati x509 che consentono l’implementazione dell’infrastruttura a chiave pubblica - PKI - prevista dalla tecnologia RSA (con lunghezza della chiave pubblica minima di 2048 byte per il canale in-terattivo, e di 4096 byte per l’autenticazione delle applicazioni software), necessaria anche per l’autenticazione del server all’atto di aprire una ses-sione sul canale interattivo.

Il punto più critico per preservare la sicurezza dell’intera infrastrut-tura di servizio, la gestione della revoca tempestiva dei certificati com-promessi, appare correttamente affrontato solo per il profilo IB1, anche se il compromesso individuato nella specifica non soddisfa pienamente le e-sigenze di sicurezza. E’ comunque consentito negoziare con i costruttori l’implementazione di procedure più affidabili in caso di applicazioni parti-colarmente sensibili alla sicurezza. Non è prescritto l’impiego di tecniche per crittografare la sessione stessa, per cui i dati possono viaggiare in chia-ro, se non diversamente protetti ad un livello superiore. Non è obbligatoria la presenza di un’interfaccia API che consenta l’autenticazione del client, né è prevista l’implementazione sulla piattaforma delle procedure TLS (Transport Layer Security) lato server.

L’integrazione dei sistemi di accesso condizionato con la piattafor-ma può essere realizzata:

ü Dal costruttore della stessa, che quindi individua, anche concorde-mente con operatori di servizi, il/i sistema/i da integrare;



ü Dall’operatore del servizio televisivo interessato, se il costruttore ha introdotto nel proprio apparato il dispositivo standard Interfaccia Comune (EN 50221). Il profilo Internet Access resta comunque ancora lontano dalla rea-

lizzazione pratica, sarà completamente specificato solo in versioni superio-ri dello standard, così come avverrà anche per i profili di livello 2.

3.7 Set Top Box

3.7.1 Architettura

In fig. 3.14 è rappresentata l’immagine dell’architettura del set-top-box o IRD (ricevitore-decodificatore integrato digitale) per evidenziarne le interfacce e i principali blocchi funzionali.

Figura 3.14. Architettura del set-top-box



L’architettura generale si compone di:

ü Un livello hardware e firmware comprendente le interfacce verso l’esterno (per maggiori dettagli si veda la fig. 2) e il bootloader, che consente l’aggiornamento del software residente;

ü Un livello software residente che include il software di sistema, il navigatore e, ove necessario, il middleware (JAVA, browsers XML, HTML, ecc.);

ü Un livello API per l’ulteriore gamma di applicazioni (EPG, Teletext evoluto).

Le interfacce verso l’esterno possono comprendere l’ingresso/ usci-

ta RF/IF, le uscite audio e video, gli ingressi/uscite audio/video e dati, te-lecomando, l’interfaccia comune, le interfacce smart-card e il canale di ri-torno.

Occorre precisare che la dotazione dell’interfaccia comune è obbli-gatoria per i soli ricevitori con accesso condizionato integrati negli appa-recchi televisivi ed è raccomandata per i set-top-box che prevedono le fun-zioni di accesso condizionato. La presenza del canale di ritorno e del rela-tivo strato software di gestione è raccomandata per i ricevitori di funziona-lità estesa.

Figura 3.15. Architettura del set-top-box - dettagli



Relativamente al software, si fa notare che in tutti i ricevitori terre-stri, satellitari e via cavo, è essenziale la presenza di un navigatore in gra-do di presentare all’utente il contenuto delle informazioni sulla program-mazione diffuse dagli operatori televisivi, secondo la normativa DVB-SI. Le interfacce software (API) che permettono di scaricare sull’ IRD appli-cazioni multimediali sono raccomandate nei soli ricevitori evoluti. Di fon-damentale importanza, inoltre, è la possibilità di modificare in tutto o in parte il software residente del IRD.

3.7.1.1 Funzionalità hardware e firmware

Esaminando nel dettaglio l’architettura di rete proposta, è possibile individuare i blocchi principali che costituiscono la struttura hardware e firmware dell’IRD, come illustrato in figura 3.15. I moduli a fondo chiaro costituiscono la struttura base dell’IRD terrestre e devono tutti essere con-siderati come essenziali. I moduli a fondo scuro rappresentano l’estensione della struttura tramite la quale il STB acquisisce funzionalità estese (es: multimedialità, interattività, registrazione locale). Nel caso di servizi pro-venienti da diversi mezzi di trasmissione (satellite, cavo, terrestre) si rac-comanda che l’utente sia messo in condizione di navigare, in modo sem-plice, tra i servizi originati da diversi front-end. La presenza contempora-nea nell’IRD terrestre dell’interfaccia comune e del CA Embedded con re-lativo lettore di smart-card risponde all’esigenza di massima flessibilità sotto il profilo del controllo d’accesso. In tal modo un unico IRD è in gra-do di gestire e offrire all’utente servizi criptati di differenti operatori sia in multicrypt (EN 50221) sia in simul-crypt (TS 101-197).

3.7.1.2 Front-end

Il front-end deve essere in grado di ricercare automaticamente ogni segnale presente all’interno dell’intervallo di frequenze disponibile e rico-noscere automaticamente la modalità trasmissiva (modulazione, il symbol rate e la correzione di errore). Deve inoltre essere in grado di ricevere le informazioni sulla sintonia tramite le tabelle PSI/SI. Opzionalmente l’IRD si sintonizza sul canale RF richiesto dall’utente. Una volta acquisiti, i dati relativi alla sintonia devono essere memorizzati in modo da poter essere rapidamente disponibili.



Queste caratteristiche devono essere condivise da tutti i front-end (terrestre, cavo e satellite) installati nell’STB.

Il front-end del set-top-box terrestre dovrà includere un by-pass RF analogico, funzionante anche in stand-by. È raccomanda una realizzazione che includa anche il modulatore RF PAL, per il reinserimento del pro-gramma digitale decodificato.

3.7.1.3 Demultiplexer MPEG-2 Ricompone i flussi relativi ai programmi a partire dai pacchetti TS

ed effettua la sincronizzazione dei flussi audio e video secondo la codifica di trasporto MPEG-2 definita in ISO/IEC 13818-1.

È necessario inoltre:

ü Utilizzare le tabelle MPEG-2 SI-DVB; ü Interpretare il descrittore CA come definito in ETR 289; ü “Demultiplare” un flusso ISO/IEC 13818-1 con data rate fino a 60

Mbit/s; ü Selezionare, opzionalmente, uno o più flussi dati, definiti in EN 300

192, e inviarli a un’uscita compatibile; ü Ignorare strutture dati che, allo stato attuale, sono classificate reser-

ved, in modo da garantire la compatibilità con versioni future.

3.7.1.4 Video Decoder MPEG–2

Il decoder video deve rispettare gli standard e le linee guida fornite dai seguenti documenti:

ü ISO/IEC 13818-1, ISO/IEC 13818-2 ü ETS 300 468, ETR 211 ü ETR 154. ü ITU-R BT. 1119-1, ETS 300 294

Le caratteristiche minime del video decoder MPEG-2 sono le se-guenti:



ü Risoluzioni (riferite ai pixel di luminanza) di: 720x576, 544x576, 480x576, 352x576 o 352x288 rappresentabili, sulle uscite video a-nalogiche, anche a pieno schermo (fullscreen);

ü Formati 4:3 e 16:9 (aspect ratio information) ; ü Supporto del formato MPEG-1; ü Supporto di bit rate video fino a 15 Mbit/s.

3.7.1.5 Decoder audio

Il decoder audio MPEG dovrà rispettare le linee guida fornite dal DVB ETR 154 che si riferisce agli standard ISO/IEC 13818-3 e 11172-3. In particolare:

ü Supporto del MPEG layer I e II, III opzionale, ma si raccomanda

l’estrazione di almeno una coppia di canali stereo MPEG-2; ü Supporto delle velocità di campionamento 32, 44.1, 48 kHz e per

MPEG-2 22.05 e 24 kHz.

3.7.1.6 Sincronismo audio video

Almeno un decoder audio dovrà rispettare i requisiti di decoding della ETR 154. Il ritardo relativo introdotto dal decoder fra segnali audio e video non dovrà superare i 5 ms. Livelli di set-up in linea con DVB ETR 154.

3.7.1.7 Unità di controllo

La configurazione minima dell’unità di controllo per l’ IRD a fun-zionalità estesa dovrà essere di:

ü 4 Mbyte RAM; ü 4 Mbyte flash memory; ü 4 Mbyte video RAM;

Ogni STB dovrà avere le seguenti funzioni:



ü Orologio e, in via opzionale, calendario in tempo reale, aggiornati via SI;

ü Timer opzionale per il controllo dell’ accensione e lo spegnimento automatico.

3.7.1.8 Bootloader

Questo modulo è realizzato in software residente e ha la funzione di gestire lo scaricamento di tutto o di parte del software (drivers, SO, e ap-plicazioni) nell’IRD. Il caricamento del software può avvenire:

ü Attraverso il canale broadcast; ü Attraverso un modulo appropriato connesso all’interfaccia comune; ü Utilizzando il canale interattivo; ü Attraverso le interfacce dati.

Si raccomanda che il bootloader sia in grado di prevenire il carica-

mento di software non certificato e che il protocollo di sicurezza sia basato su un meccanismo di crittografia asimmetrica (chiave pubblica/chiave pri-vata, con le chiavi pubbliche presenti nell’IRD).

3.7.1.9 Funzionalità grafiche

L’IRD deve essere in grado di gestire funzionalità grafiche per il controllo dello stesso tramite on-screen-display (OSD) e per il navigatore di base basato sulle informazioni DVB SI.

La funzionalità estesa deve essere in grado di gestire opzioni grafi-che avanzate e la visualizzazione del segnale OSD. Deve inoltre soddisfare i seguenti requisiti minimi: ü Risoluzione 720x576 con aspect ratio 16:9 e 4:3; ü Numero di colori 256 più trasparenza con modo di presentazione

specificato dalle API ; ü Supporto simultaneo di grafica, video e still pictures; ü Supporto della sottotitolazione DVB (ETS 300 743).



3.7.1.10 Interfacce e livelli di segnale

I requisiti delle varie interfacce esterne di cui l’IRD deve/può essere dotato sono elencati in tabella 3.8. Nei singoli casi sarà specificato quali requisiti possono essere considerati facoltativi.

PAL ü ITU/R re. 624-4; ü Controllo di volume presente; ü Connettore IEC maschio, IEC 60169-2.

Transport stream

ü Common interface secondo EN50221 (obbligatoria se il decoder è integrato, raccomandata negli altri ca-si);

ü Interfaccia IEEE 1394 con racket layer secondo IEC 1883 (MPEG-2) facoltativa.

Smart-card

ü ISO 7816 part 1-3; ü Supporto delle carte sincrone (facoltativo); ü Frequenza di clock minima 3.72 MHz (raccomandata

5 Hz). Gli slot per la smart-card nell’architettura dell’IRD mul-timediale potranno essere oggetto di revisioni in base a-gli sviluppi in corso nell’industria del settore.

Modem

ü ITU-T v32bis (14400); ü Correzione d’errore ITU-T V 4 2; ü Connettore RJ-11; ü Omologazione del Ministero delle Comunicazioni; ü Supporto DMTF, PABX, carrier select.

Interfaccia Scart

Secondo EN 50049-1 ed EN 50 157-2-1

Audio

ü Disponibile all’uscita Scart; ü Uscita audio stereo secondo IEC4B(Sec)316.

Interfaccia seriale

ü RS232 C secondo EN50201 4.6.1; ü Connettore maschio a 9 PIN.

Tabella 3.8. Interfacce e livelli di segnale



3.7.1.11 Software e servizi

Nel software del STB si possono distinguere: il software residente di sistema e le applicazioni.

Il software di sistema deve fornire due classi di funzioni: una classe è accessibile solo all’interno del medesimo software di sistema, come il navigatore di base, mentre l’altra è disponibile internamente ed esterna-mente per le varie applicazioni, quali l’EPG, e costituisce l’API dell’ IRD.

3.7.1.12 Navigatore Il software di sistema sia per il profilo base sia per quello a funzio-

nalità estesa deve contemplare un navigatore definito dal costruttore, che permetta all’utente di configurare e di controllare la sintonia dell’ IRD. Sa-rà pertanto compito del costruttore stabilire l’aspetto grafico della presen-tazione dei dati. Il navigatore deve fornire la lista di tutti i servizi presenti su tutti i canali accessibili, anche quando i segnali non trasportino le in-formazioni SI incrociate. L’utente deve in ogni caso poter configurare ma-nualmente l’ordine dei canali preselezionati in automatico e richiamare, tramite telecomando, la funzione di navigazione e aggiornamento dei dati.

3.7.1.13 Requisiti minimi

Le sperimentazioni preliminari in fase di progetto e definizione del-

lo Standard hanno permesso di individuare quali sono le caratteristiche hardware e software che devono essere contenute nei terminali per rispet-tare i requisiti implementativi minimi dello stesso nel modo migliore.

Nella Tabella 3.9 sono riportate le caratteristiche dei STB che han-no dato risultati positivi in fase di sperimentazione3.

3 Il libro bianco sulla televisione digitale terrestre



Caratteristica tecnica Specifica tecnica (minima)

Decodificatore video Profilo: MPEG-2 Main Profile @ Main Level

Clock del Processore 150 MHz

Decodificatore audio MPEG1 - layer 2 con bit rate fino a 384 kbit/s

Memoria SDRAM 32 MB

API / Middleware MHP 1.0.2

Applicazioni residenti definito Navigatore definito dal costruttore

Connessioni al canale di ritorno Modem V.90 (56 kbit/s)

Lettori di smart-card 1 lettore di smart-card (connettore tipo B)

Dual tuner analogico e digitale2 Opzionale

Common Interface per CA Opzionale – 2 slot PCMCIA

Flash memory 8 MB

Tabella 3.9. Caratteristiche minime del Set Top Box

3.8 Telecomando Affinché le applicazioni MHP producano risultati uguali su Set-

Top-Box diversi è necessario che anche il comportamento degli utenti sia sempre il medesimo; per ottenere ciò è necessario che il telecomando, os-sia lo strumento che guida l’utente nell’utilizzo dell’applicazione, sia sem-plice nell’utilizzo ed anch’esso conforme ad uno standard (cfr. Tabella 3.10).



Caratteristica tecnica

Specifica tecnica (minima)

Spaziatura e dislocazione tasti

Tasti critici distanziati

Tasti colore e sequenza

4 colori, conforme alle specifiche DVB, con l’ordine: rosso, verde, giallo e blu

Scrittura di testi alfanumerici

Utilizzo dei tasti alfanumerici da 0 a 9 (tipo GSM)

Tasti previsti anche dalla TV analogica

Tasti ‘Programma +’, ‘Programma –‘ Tasti ‘Volume +’, ‘Volume –‘, ‘Mute’ Tasto ‘AV’ (per input da SCART), Tasto ‘Set-Up’

Tasti aggiuntivi

Tasto ‘Info’ - Attiva il navigatore Tasto ‘iTv’ o ‘Interactive’ (servizi disponibili) Tasti freccia Pagina precedente/successiva (navi-

gazione all’interno di programmi/servizi) Tasto ‘OK’ lancio/conferma selezioni/impostazioni Tasto ‘Exit’ Interruzione/uscita da selezione attiva Tasti colore Scelta delle funzionalità disponibili

all’interno dei programmi/servizi del broadcaster Tasto ‘text’ Visualizzazione teletext qualora la de-

codifica dello stesso avvenga nel STB

Tabella 3.10.Caratteristiche minime del telecomando MHP

3.9 Applicazione MHP – DVB J Le applicazioni DVB-J basano il loro funzionamento sulla creazio-

ne di una classe che implementa l’interfaccia Xlet, definita nell’interfaccia javax.tv.xlet.Xlet di Java-TV.

Prima di entrare nel merito del funzionamento di una Xlet viene brevemente descritto nel paragrafo successivo il concetto di service con-text, utile per introdurre le applicazioni DVB-J.



3.9.1 Service Context – Lifecycle Il controllo del lifecycle di un’applicazione è effettuato attraverso la

selezione di un servizio; tale selezione può essere effettuata dall’utente at-traverso il navigatore e/o l’EPG. Il “servizio” è l’unità per la presentazione e l’esecuzione dei contenuti; un servizio rappresenta il bouquet complessi-vamente presentato all’utente finale. Il pacchetto può contenere stream au-dio/video, stream dati, tutte le informazioni di servizio, applicazioni e con-trolli delle stesse.

Ogni servizio presentato in un ambiente MHP è collocato all’interno di un “service context”. Questa tecnica è alla base del concetti di “runtime environment” e “execution model”. Il “service context” è dun-que l’ambiente all’interno del quale il servizio viene messo a disposizione, dove vengono definiti i suoi limiti, il controllo e l’indirizzamento.

In una applicazione DVB-J il service context è rappresentato da una istanza della classe ServiceContext(). Se più applicazioni DVB-J vengono presentate nello stesso service context, il numero di oggetti ServiceCon-text() è dipendente dall’implementazione, ma ogni applicazione vede sol-tanto una di queste istanze. I cambiamenti apportati da un’applicazione all’oggetto ServiceContext() sono visibili agli altri oggetti dello stesso ti-po, rappresentanti lo stesso service context in altre applicazioni.

Le applicazioni DVB-J possono ottenere informazioni sul service context, all’interno del quale vengono eseguite, attraverso il metodo ge-tServiceContext(XletContext) della classe ServiceContextFactory(). Un service context può presentare solo un servizio alla volta; la selezione di un nuovo servizio da presentare preclude l’interruzione del servizio prece-dente. I terminali MHP possono limitare il numero di service context pre-sentabili tra quelli trasmessi in broadcast simultaneamente.

3.9.2 Xlet – modello applicazioni

Le piattaforme Java tradizionali definiscono applicazioni che hanno il lifecycle associato a loro stesse, sulle quali sono progettate per specifici scopi; per esempio le Applet sono realizzate per fornire un supporto nell’esecuzione di pagine web. Nessuna delle piattaforme esistenti era a-



datta per rispettare i requisiti dei ricevitori televisivi, l’introduzione della piattaforma DVB-J ha colmato questa lacuna.

Il lifecycle delle applicazioni descritto in questa sezione è importan-te per comprendere la compatibilità del DVB-J con piattaforme e virtual machine già esistenti.

Le Xlet derivano direttamente dalle Java TV APIs, sono applicazio-ni il cui lifecycle è direttamente monitorato e controllato dal sistema. L’entry-point di una Xlet è tipicamente una classe, che ha un costruttore public senza argomenti, che implementa l’interfaccia Xlet:

public interface Xlet { void destroyXlet( boolean unconditional ) throws XlettateChangeException; void initXlet( XletContext context ) throws XlettateChangeException; void pauseXlet(); void startXlet() throws XlettateChangeException; }

Inoltre la Xlet può definire una interfaccia XletContext ed altre due classi: la XletstateChangeException e la UnavailableContainerException.

La gestione della Xlet viene effettuata dall’application manager del dispositivo che esegue la stessa; quando viene istanziata la prima volta viene invocato il costruttore di cui sopra, che di solito è vuoto poiché non è ancora disponibile nessuna informazione sui contenuti; successivamente viene invocato il metodo initXlet(), che ha lo scopo di inizializzare l’applicazione. Il singolo argomento passato alla Xlet è un oggetto che im-plementa l’interfaccia XletContext. Il custom della Xlet memorizza un col-legamento con questo oggetto affinchè permetta alla stessa di comunicare con il sistema per cambiare gli stati e per accedere alle funzionalità. Si ri-porta di seguito un esempio. public class MyXlet implements Xlet { XletContext context; public void initXlet( XletContext context ) throws XlettateChangeException



{ this.context = context; // inizializzazione } // altri metodi }

Se la Xlet non viene inizializzata correttamente deve invocare il metodo XletstateChangeException() per notificarlo al sistema. Il metodo initXlet() viene tipicamente usato per la creazione dell’interfaccia iniziale mediante l’utilizzo di un set di metodi derivato dall’AWT (con un toolkit basato su di esso) supportato dal profilo. Quando la Xlet ritorna dal meto-do initXlet(), il sistema invoca il metodo startXlet(), comunque non imme-diamente necessario. La startXlet() comunica alla Xlet che si sta entrando in uno stato attivo e che ora può mostrare la propria interfaccia aprendo le risorse necessarie del sistema. Se la Xlet non è pronta per entrare in uno stato attivo, può rifiutare la transizione per mezzo della XletstateChangeE-xception. Il sistema tornerà in uno stato di pausa e attenderà una riattiva-zione successiva. Una volta che la Xlet è in uno stato attivo il sistema può comunque metterla in pausa in ogni momento, invocando il metodo pau-seXlet() della stessa. La Xlet è in grado di rilasciare risorse di sistema af-finché esse siano disponibili per altre applicazioni. Quando viene invocato il metodo pauseXlet() la Xlet entra in uno stato di pausa, ma in ogni caso ogni thread in background continua ad esistere. Il sistema termina la Xlet invocando la destroyXlet(). Se l’argomento booleano della destroyXlet() è TRUE, la terminazione è incondizionata: la Xlet è distrutta senza possibili-tà di scelta. Se l’argomento è FALSE, la Xlet può rifiutare la terminazione generando l’eccezione XlettateChangeException().

Tipicamente il sistema gestisce i cambiamenti di stato della Xlet, la quale comunque ha la possibilità di richiedere esplicitamente transizioni di stato; può cioè invocare metodi dell’interfaccia XletContext: import java.awt.Container; public interface XletContext { String ARGS = new String();



Container getContainer() throws UnavailableContainerException; Object getXletProperty( String key ); void notifyDestroyed(); void notifyPaused(); void resumeRequest(); }

Una Xlet può mettersi in pausa o terminare in ogni punto chiaman-do rispettivamente i metodi notifyPaused() o notifyDestroyed(). Una Xlet in pausa può richiedere la riattivazione invocando il metodo resumeRe-quest(); in tal caso la riattivazione può non essere immediata (il system control può infatti non accettare la richiesta), ma avviene comunque per mezzo del metodo startXlet().

I restanti metodi dell’XletContext interface sono usati per reperire proprietà, di solito durante il processo di inizializzazione.

Il metodo getContainer() ritorna alla Xlet il root-container (l’istanza del java.awt.Container che la Xlet usa come componente AWT primario). Il root-container è a sua volta una istanza del java.awt.Frame.

Il metodo getXletProperty() ritorna le proprietà specifiche dell’applicazione. In una applicazione Java di tipo tradizionale si accede alla command-line attraverso i parametri passati al main(): public static void main( String[] args ){ ..... }

Utilizzando le Xlet si possono passare argomenti chiamando la ge-tXletProperty() dalla initXlet(): public void initXlet( XletContext context ) { String[] args = (String[]) context.getXletProperty( XletContext.ARGS ); ..... }

Si vede ora come è possibile realizzare una semplice Xlet che visua-

lizza un messaggio e che aspetta la pressione di un tasto dell’utente per terminarsi.



import java.awt.*; import java.awt.event.*; import javax.microedition.xlet.*; /* * una semplice Xlet */ public class BasicXlet implements Xlet { private XletContext context; private Container rootContainer; private Frame rootFrame; private SimpleTextLabel label; // metodo initXlet public BasicXlet(){ } // chiamata dal sistema per notificare // che la Xlet può essre distrutta public void destroyXlet( boolean unconditional ) throws XlettateChangeException { exit(); } // chiamata dalla Xlet per distruggersi public void exit(){ rootContainer.setVisible( false ); context.notifyDestroyed(); } // ritorna l’XletContext public XletContext getContext(){ return context; } // ritorna il root container public Container getRootContainer(){ return rootContainer;



} // ritorna il root frame public Frame getRootFrame(){ return rootFrame; } private void initUI() throws XlettateChangeException { // memorizza il root container try { rootContainer = context.getContainer(); Container tmp = rootContainer; while( !( tmp istanzaof Frame ) ){ tmp = tmp.getParent(); } rootFrame = (Frame) tmp; } catch( UnavailableContainerException e ){ // se non riesce ad ottenere il root container, // abbandona l’inizializzazione throw new XlettateChangeException( "XletInitialization aborted -- no container: " + e.getMessage() ); } catch( NullPointerException e ){ throw new XlettateChangeException( "XletInitialization aborted -- no frame: " + e.getMessage() ); } } // chiamata dal sistema per inizializzare la Xlet.



public void initXlet( XletContext context ) throws XlettateChangeException { this.context = context; // store the context for later use initUI(); // costruzione dell’interfaccia label = new SimpleTextLabel( "Press a key to exit" ); label.setBackground( Color.blue ); label.setForeground( Color.yellow ); label.addKeyListener( new KeyAdapter(){ public void keyTyped( KeyEvent e ){ exit(); } } ); rootContainer.add( label );

// non rende visibile il container // finchè il metodo startXlet non viene invocato

} // chiamata dal sistema per mettere in pausa // qui vengono rilasciate le risorse del sistema public void pauseXlet(){ } // chiamata dal sistema per attivare la Xlet. public void startXlet() throws XlettateChangeException { if( !rootContainer.isVisible() ){ rootContainer.setVisible( true ); } } }

Nella Figura 3.16 è riportata la macchina a stati di una Xlet; si può notare come detto in precedenza che qualunque sia lo stato in cui si trova la Xlet, questa può essere distrutta (questo è lecito in quanto l’utente deve



essere in grado di poter passare da un’applicazione a un’altra in ogni mo-mento).

Figura 3.16. Macchina a stati di una Xlet

Capitolo 4

Realizzazione di un’interfaccia domestica su PC 4.1 Obiettivi Lo scopo del progetto è realizzare un’applicazione per la gestione di un impianto domotico in grado di essere eseguita su un decoder per la TV digitale terrestre; finora sono state ampiamente descritte le tre aree d’interesse fondamentali per la realizzazione dello stesso: domotica, si-stema di automazione domestica e piattaforma digitale MHP. Attraverso lo studio dell’impianto MyHome di Bticino (vedi par. 2.4.2) si è appresa la possibilità di dialogare con l’impianto domotico at-traverso un collegamento TCP verso il WebServer; alla stessa stregua si è pensato di raggiungere l’impianto sfruttando il secondo profilo d’implementazione della TV digitale terrestre (cfr. Cap. 3), che prevede un canale di ritorno per l’interattività. La domotica si inserisce in questo con-testo in quanto si intende progettare un tipo di applicazioni e servizi le cui

Cap. 4 - Realizzazione di un’interfaccia domestica su PC


modalità di erogazione sono definite in prospettiva di un utilizzo prevalen-temente da parte di un utenza speciale quale quelle anziana e disabile. La convergenza sopra descritta ha fatto sì che ogni settore apportas-se le proprie restrizioni, generando una serie di limitazioni nel risultato fi-nale; le limitazioni alle quali si è accennato saranno esposte in questo capi-tolo e nel prossimo. Verrà di seguito descritta la limitazione applicata all’interfaccia utente in quanto destinata ad una tipologia di utenza che ri-chiede attenzioni specifiche. In particolare ci si è orientati verso determi-nate soluzioni piuttosto che verso altre seguendo alcune delle linee guida del consorzio W3C e grazie alla collaborazione della psicologa del CE-TAD Ombretta Veneziani. L’applicazione che vuole essere il risultato finale del progetto deve essere una Xlet (cfr Cap. 3.9.2); data l’impossibilità di utilizzare strumenti adatti per la progettazione diretta di applicazioni MHP si è proceduto alla progettazione della stessa attraverso un passaggio intermedio: si è prima realizzata una simulazione di televisore per mezzo di un PC, collegato di-rettamente al WebServer tramite rete locale, per poi trasferire il sistema creato su un decoder digitale. Sia il simulatore che l’applicazione vera e propria sono stati inglobati all’interno di uno stesso programma realizzato in tecnologia Java.

4.1.1 Accessibilità ed usabilità Il fine principale dell’applicazione è soddisfare l’esigenza di essere aperta all’uso di tutti gli utenti, compresi quelli con disabilità. Con questo obiettivo si è cercato di applicare al progetto i concetti di accessibilità, nel caso specifico nello sviluppo dell’interfaccia utente impianto domotico; così facendo si ottiene un miglioramento generale nell’utilizzo da parte di tutti gli utenti. La soluzione di seguito presentata ha la caratteristica di essere un prototipo “adattabile” ad utenze disparate: l’idea di base resta quella di co-struire una applicazione MHP, quindi scaricabile dall’etere; diventa di conseguenza plausibile fornire simultaneamente applicazioni diverse nella forma (ma uguali nel concetto) destinate a utenti differenti (supponendo che l’utente possa scaricare l’applicazione per la gestione della casa che più si adatta ai propri requisiti).



Per comprendere come soddisfare i requisiti di accessibilità, è utile fare un cenno ai problemi specifici di accesso da parte delle varie categorie di persone disabili. Gli utenti con disabilità, destinatari del progetto, possono essere ri-condotti ai seguenti profili: disabilità sensoriali (vista, udito) e disabilità motorie; non sono state trattate nello specifico le disabilità psichiche e co-gnitive in quanto necessitano di studi più approfonditi. La disabilità della vista comprende tipicamente due classi di utenti: i non vedenti (inclusi tra i destinatari delle future versioni dell’applicazione, cfr. Conclusioni) e gli ipovedenti; tale suddivisione è giustificata dalla diversità di accesso, infatti, per lo studio riservato agli u-tenti ipovedenti, è possibile utilizzare accorgimenti particolari come un’adeguata dimensione del font usato oppure l’impostazione di colori a-datti ad esaltare la presentazione grafica. Per i non vedenti occorre, invece, ricorrere a tecniche particolari come l’utilizzo del segnale audio mediante l’impiego, per esempio, di un sintetizzatore vocale. I problemi relativi ad utenti con disabilità uditive, dovuti a sordità parziale o totale, sono da prendere in considerazione nel caso specifico della vita quotidiana all’interno della propria abitazione, dove sono presen-ti impianti citofonici o sistemi di allarme il cui stato non sarebbe percepi-bile senza l’utilizzo di informazioni a video. L’arco delle disabilità di tipo fisico è piuttosto ampio e va da una modesta paralisi su un arto sino, nel peggiore dei casi, ad una mobilità re-sidua quasi nulla. Riguardo alla possibilità di interazione con l’interfaccia grafica, nel mezzo fisico utilizzato per il comando, occorre tener conto come la scelta di pulsanti troppo vicini tra loro e di dimensioni ridotte comporti problemi non indifferenti; per questo motivo è stato pensato di impiegare anche i ta-sti freccia per la navigazione dei menù, di dimensioni maggiori rispetto ai pulsanti numerici, come facilmente riscontrabile nei telecomandi presenti sul mercato, con la conseguente semplificazione dell’accesso ad essi. Allo scopo di ottenere un’applicazione che possa essere utilizzata da un sempre maggior numero di utenti si devono ottenere le seguenti caratteristiche: ü Equità e flessibilità d’uso; ü Uso semplice ed intuitivo – l’utilizzo dell’applicazione deve essere

facile da capire indipendentemente da esperienza, conoscenza o ca-pacità di concentrazione dell’utente.



ü Informazione accessibile. Le linee guida usate nel progetto sono simili a quelle seguite nella realizzazione di pagine WEB accessibili, nello specifico: ü Impiego di combinazioni di colore di sfondo e di primo piano tali

da fornire sufficiente contrasto per non precludere l’uso a persone con disturbi di percezione cromatica o ipovedenti;

ü Struttura di navigazione chiara e coerente; ü Uso di colori per fornire informazioni solo nel caso in cui è possibi-

le impiegarli in combinazione con del testo guida.

4.2 Scelte progettuali L’applicazione, che verrà di seguito descritta, è stata progettata con le seguenti caratteristiche: ü Programmabilità – L’applicazione deve poter essere configurata a

seconda dell’impianto da gestire, in particolar modo si potrà confi-gurare il contenuto dei menù (cfr. Par. 4.6.3) e le operazioni da ese-guire in seguito ad una scelta da parte dell’utente. Inoltre deve esse-re opportunamente configurata la gestione dell’impianto domestico rispettando gli indirizzamenti dei dispositivi attuatori presenti (que-sto perché un dispositivo, per esempio corrispondente a “luci cuci-na”, non presenta lo stesso indirizzamento in impianti differenti, da-ta la libertà di configurazione concessa agli installatori).

ü Adattabilità – L’interfaccia deve poter presentare differenti moda-

lità di visualizzazione a seconda di diversi livelli di disabilità visiva; nel caso estremo, ad esempio, l’applicazione consente di visualizza-re i testi con contrasto elevato (testo bianco su fondo nero). Queste scelte vengono effettuate in fase di configurazione.

ü Compatibilità MHP – Poiché il software progettato in questa fase

deve essere successivamente eseguito su una piattaforma digitale terrestre dovrà inevitabilmente rispettare le specifiche dello stan-dard; in particolar modo il programma realizzato in Java deve ri-



spettare i requisiti della piattaforma JavaTV della Sun Micro-systems. Per questo motivo si è utilizzato un basso profilo di pro-grammazione, la versione 1.1 di Java, senza penalizzare più di tanto il risultato finale; non sarebbe stato possibile, ad esempio, usare la libreria grafica Swing di Java 2, seppur graficamente più accattivan-te della semplice AWT di Java 1. L’utilizzo di semplici pannelli di Java 1.1 per la realizzazione dell’interfaccia ha reso l’applicazione leggera dal punto di vista dell’occupazione di memoria (problema non trascurabile nella progettazione di strumenti per le piattaforme televisive).

ü Protocollo di comunicazione aperto – L’applicazione deve essere

in grado di comunicare con l’impianto domestico ad un livello “al-to” (TCP/IP, HTTP), cioè deve essere in grado di interagire con qualsiasi impianto domotico o qualsiasi elettrodomestico di nuova generazione (elettrodomestico “intelligente”) che utilizzino proto-colli di comunicazione di alto livello come quelli sopra citati. Nel caso specifico di questo progetto si è deciso di comunicare con il WebServer Bticino in TCP, escludendo a priori l’opportunità di la-vorare direttamente sul BUS dell’impianto, per non essere stretta-mente vincolati dal protocollo di comunicazione proprietario dello stesso.

Per il conseguimento dell’obiettivo finale si è dovuta realizzare, come passaggio intermedio, una simulazione di un sistema televisivo digi-tale terrestre (televisore + set top box + telecomando); all’interno del bloc-co televisore del simulatore si è realizzata l’interfaccia grafica della futura applicazione MHP. Al fine della corretta comprensione degli argomenti di seguito trattati si deve prestare attenzione a ciò che si intende per interfac-cia utente: si tratta di ciò che effettivamente si presenta come immagine te-levisiva e non dell’interfaccia grafica del simulatore nel suo complesso (cfr. Fig. 4.1)



Figura 4.1. Definizione di interfaccia utente

4.3 Simulatore sistema televisivo Si è optato verso la realizzazione di una simulazione di sistema te-levisivo in quanto una semplice interfaccia utente non sarebbe stata suffi-ciente per simulare un’applicazione MHP (cfr. Figura 4.2); un problema fra tutti è sostituire l’uso della tastiera con quello del telecomando, per rendere la simulazione quanto più possibile vicina a quello che è il reale utilizzo di un televisore. Il simulatore sopra citato prevede la presenza di due finestre: una rappresenta il telecomando e l’altra lo schermo televisivo vero e proprio. L’utente che utilizza tale simulatore può compiere una serie di operazioni solo mediante l’uso della pulsantiera del telecomando. Il telecomando è stato disegnato per essere il quanto più possibile vicino alle specifiche tecniche sulla costruzione dei telecomandi racco-mandate dallo standard MHP; in particolare oltre al tastierino numerico sono presenti altri pulsanti, tra questi:



ü Frecce - per esplorare i menù dell’applicazione interattiva in com-binazione con il pulsante ‘OK’;

ü Quattro tasti colorati - nell’ordine ‘Rosso’, ‘Verde’, ‘Giallo’ e ‘Blu’, per espletare alcune particolari funzioni (che verranno am-piamente descritte in seguito)

ü Tasto ‘Menù’ – per accedere alla funzione di richiamo del menù principale durante l’esecuzione dell’applicazione; sebbene non sia definita la presenza del tasto ‘menù’, essa non è esclusa (la quasi to-talità dei decoder sul mercato presenta un telecomando con questo tasto).

Il tasto ‘Exit’ non è stato utilizzato, sebbene previsto dallo standard, perché tendenzialmente ha la funzione di richiamare il metodo che elimina l’applicazione stessa liberando tutte le risorse occupate, perciò inutile ai fini stessi della simulazione.

Figura 4.2. Simulatore sistema televisivo



Per quanto riguarda la tecnica con la quale è stato realizzato il si-stema televisivo e il suo principio di funzionamento si rimanda al paragra-fo 4.5.

4.4 Interfaccia utente Il problema della scelta di un’adeguata interfaccia utente è stato af-frontato in collaborazione con il personale specializzato del CETAD (cfr. Par. 1.7), sono inoltre stati effettuati alcuni test in presenza di persone con disabilità di vario tipo.

4.4.1 Requisiti Per l’interfaccia utente sono stati presi in considerazione due vincoli particolarmente stringenti: ü Massima semplicità d’utilizzo – l’utente anziano deve poter essere

in grado di comprendere le modalità di funzionamento dell’applicazione nel minor tempo possibile, in modo quasi intuiti-vo, venendo opportunamente guidato nella scelta delle operazioni eseguibili.

ü Massima leggibilità – i problemi legati alle diverse difficoltà visive

impongono opportune scelte dell’aspetto grafico dell’applicazione (colori, caratteri ed immagini devono essere adeguati). Si è mirato a superare gli ostacoli dovuti a diversi stadi di disabilità visive (ipo-vedenza, daltonismo), riuscendo così a soddisfare contemporanea-mente i requisiti dell’utenza anziana.

4.4.2 Messaggi pilota L’applicazione è stata ipotizzata sempre attiva e permette all’utente di accedere alla gestione della casa premendo in qualsiasi momento un pulsante colorato (nella fattispecie il tasto ‘Rosso’); a tal scopo, durante la fruizione di un normale programma televisivo appare in fondo allo scher-



mo un messaggio pilota che descrive l’azione eseguibile (“PREMERE IL TASTO ROSSO PER GESTIRE LA CASA”). Analogamente, una volta che l’applicazione è nella fase di effettiva gestione della casa, sul medesi-mo spazio viene visualizzato un messaggio che permette di ritornare nella condizione iniziale (fruizione del programma televisivo) alla pressione del tasto colore ‘Verde’ (“PREMERE IL TASTO VERDE PER USCIRE DALLA GESTIONE CASA”, cfr Fig. 4.3).

Figura 4.3. Messaggi pilota

Lo spazio riservato ai messaggi pilota di cui sopra può essere plausibilmente riservato a un set di messaggi che il sistema di automazione domestica può inviare all’utente mentre guarda la televisione; ad esempio si potrebbe aiutare la persona con problemi uditivi inviando sullo schermo televisivo informazioni riguardanti il ricevimento di una telefonata, il suo-no del citofono o segnalazioni di allarmi di vario tipo (fuoriuscita gas, per-dita acqua, antintrusione).



4.4.3 Immagine televisiva Si è scelto di non scorrelare l’utilizzo dell’applicazione per la ge-stione della casa con la visione del televisore, a tal fine si è optato per la conservazione dell’immagine televisiva in uno spazio ridimensionato dello schermo a disposizione, sito in alto a sinistra. Così facendo, l’utente anzia-no, ad esempio, percepisce un buon livello della qualità del servizio offer-to, continuando a seguire il programma preferito senza fastidiose interru-zioni, rendendo l’applicazione realmente utile. Un’interfaccia di questo ti-po, user friendly, contrariamente a quanto si può immaginare, non disturba l’utente nell’utilizzo dell’applicazione. La grandezza dell’immagine dopo il suo ridimensionamento è stata scelta tale da poter lasciare uno spazio sufficiente per la visualizzazione di altre informazioni e del menù di scelta dei comandi, rappresentanti il corpo dell’applicazione, in modo tale da rendere questi ultimi estremamente leg-gibili ed intuitivi.

4.4.4 Menu Alla pressione del tasto rosso, come sopra accennato, deve essere ri-servato dello spazio per visualizzare il menù di esplorazione dell’applicazione, una sorta di navigatore delle funzionalità dell’impianto accessibili dal televisore. Vengono di seguito illustrate le linee guida prese in esame per la realizzazione di una struttura di questo tipo.

4.4.4.1 Massima semplicità Questa è la caratteristica di base per rendere l’applicazione user-friendly, l’esplorazione di tutte le funzionalità avviene tramite solo due li-velli di profondità, infatti per giungere all’esecuzione di un comando l’applicazione deve visualizzare, all’utente, soltanto due schermate diver-se. Si è preso come termine di paragone il tipico menù di esplorazione dei contenuti di un telefono cellulare, che per quanto semplice, presentando numerosi livelli di profondità, mette in difficoltà l’utente anziano medio.



4.4.4.2 Struttura su due livelli Le opzioni per guidare l’utente verso un’operazione da far svolgere all’impianto domotico sono sostanzialmente due: dividere il tipo di co-mandi per categorie (illuminazione, automatismi, controllo carichi, ecc.) o per ambiente di appartenenza (stanza 1, stanza 2, stanza 3, ecc.); la secon-da scelta è risultata più opportuna in termini di semplicità d’utilizzo, in quanto, si avvicina molto al naturale comportamento dell’utente alle prese con un impianto tradizionale: per accendere, ad esempio un punto luce, l’utente deve recarsi fisicamente nella stanza relativa ed effettuare ma-nualmente l’operazione. Muovendosi in questa direzione si realizza uno strumento paragonabile in qualche modo ad una “casa virtuale” .

La prima schermata presentata, vale a dire il primo livello di pro-fondità dell’applicazione, pone all’utente la possibilità di scegliere la stan-za, ossia uno tra gli ambienti inseriti in fase di configurazione, entro la quale operare. Una volta effettuata la scelta dell’ambiente, viene visualiz-zata una schermata, secondo livello di profondità, in cui sono presenti tutti i carichi, anch’essi inseriti in fase di configurazione, con i quali è possibile interagire. Inoltre esiste un ambiente speciale, negli esempi di seguito de-scritti denominato “ALTRO”, accessibile da tutti i livelli dell’applicazione dove possono risiedere funzioni particolari o più fre-quentemente utilizzate (una sorta di “PREFERITI”), a discrezione dell’utente.

Riassumendo brevemente, il principio con il quale è stato strutturato il menù è mostrato in figura 4.4.

4.4.4.3 Voci del menù

In riferimento alle voci del menù si prendano in esame le figure 4.5 e 4.6, rappresentanti rispettivamente il menù principale e il contenuto di un menù ambiente selezionato. Per compiere una scelta durante l’esplorazione del menù, l’utente può utilizzare indifferentemente la combinazione dei tasti freccia (‘UP’, ‘DOWN’) e del tasto ‘OK’ oppure la tastiera numerica del telecomando. Nel primo caso avviene uno scorrimento sequenziale delle scelte offerte seguito da una conferma; nel secondo caso la scelta viene effettuata trami-



te un’associazione diretta tra un’opzione ed un numero, senza la necessità di una conferma perciò più rapida e immediata rispetto al primo caso. Questa seconda modalità di funzionamento introduce un vincolo sul numero massimo di scelte possibili in modo da non aumentare la comples-sità d’uso.

Figura 4.4. Struttura gerarchica dell’interfaccia

La soluzione adottata è stata quella di utilizzare i soli dieci tasti nu-merici del telecomando (numerando le scelte da ‘0’ a ‘9’). Sono stati asso-ciati a due numeri due opzioni fisse, ‘0’ per l’accesso all’ambiente speciale “ALTRO” e ‘9’ per accedere alla schermata del “MENU PRINCIPALE” (una sorta di funzione HOME tipica dei browser web); di conseguenza il numero massimo di ambienti disponibili o di carichi pilotabili è otto (in ri-ferimento alla figura 4.4, N=8).

4.4.4.4 Icone Nell’ambito del secondo livello di profondità del menù è stato ne-cessario associare ad ogni carico rappresentato un simbolo che indicasse lo stato corrente del dispositivo (ON / OFF), per dare all’utente



un’informazione aggiuntiva; sono state prese in considerazione due possi-bili soluzioni: utilizzare due simboli complementari generici (simbolo ON / simbolo OFF) uguali per tutti i carichi, oppure utilizzare, per ogni dispo-sitivo, una coppia di simboli, icone, differenti che richiamano l’oggetto al quale sono associati (gli stati ON ed OFF si distinguono per i colori di sfondo diversi, rispettivamente giallo e grigio).

Figura 4.5. Menù – primo livello

La seconda scelta appare la più azzardata, in quanto le icone, data la bassa risoluzione del televisore, potrebbero risultare difficilmente distin-guibili; con un giusto dimensionamento dell’icona, si raggiunge un discre-to compromesso tra visibilità e leggibilità dell’immagine apportando un sensibile miglioramento alla semplicità d’interpretazione del menù. In figura 4.7 sono rappresentate le coppie di icone dei due casi so-pra citati: il primo è caratterizzato da una migliore visibilità, mentre il se-condo da una migliore intuitività percepita da parte dell’utente. Nella rea-lizzazione dell’interfaccia utente si è utilizzato il secondo criterio, utiliz-zando come icone le stesse fornite da Bticino per la personalizzazione dei propri software di gestione dell’impianto domotico (cfr. Par. 2.4).



Figura 4.6. Menù – secondo livello – ambiente cucina

Fig. 4.7. Menù – icone

4.5 Realizzazione del simulatore Il software che realizza la simulazione del sistema televisivo è stata realizzata in Java 1.1; si è cercato di rendere il codice prodotto il più mo-dulare possibile per lasciare a potenziali successivi sviluppatori una mag-



gior semplicità nell’apportare eventuali modifiche. Sono stati utilizzati e-sclusivamente componenti del package AWT, in quanto rappresentano gli elementi più leggeri dal punto di vista dell’impiego delle risorse disponibi-li per la creazione di applicazioni grafiche. Il vincolo della leggerezza è e-stremamente stringente quando si è alle prese con la progettazione di ap-plicazioni riservate a piattaforme televisive digitali, in seguito alle limitate funzionalità messe a disposizione dai ricevitori digitali per quanto riguarda memoria disponibile, velocità di sistema, JVM di prestazioni ridotte, ecc.. Il programma realizzato, inteso come simulatore e interfaccia uten-te, è inglobato all’interno di un’unica applicazione (in appendice viene ri-portato tutto il codice necessario alla comprensione degli argomenti di se-guito trattati). Il simulatore è caratterizzato dalla presenza di due Frame (“Digital TV” e “REMOTE CONTROL” ), rispettivamente rappresentanti televisore e telecomando. In realtà i due oggetti in questione non sono veri e propri frame bensì classi figlie della classe Frame, chiamate rispettivamente Vi-deo e Control. Gli oggetti associati alle classi sopra citate vengono instan-ziati nella classe Casa contenente il main() dell’applicazione dove vengo-no fissate le dimensioni delle finestre entro le quali essi vengono disegnati.

...

public class Casa { public static void main(String[] args) { ... Video window; Control remot_contr; window = new Video("Digital TV"); window.setLocation(0,0); window.setSize(680,720); window.setVisible(true); GestoreWindow_TV nn =

new GestoreWindow_TV(window);



window.addWindowListener(nn); window.addComponentListener(nn); remot_contr=new Control ("REMOTE

CONTROL",window,client); remot_contr.setLocation(750,50); remot_contr.setSize(220,650); remot_contr.setResizable(false); remot_contr.setVisible(true); GestoreWindow bh = new GestoreWin-dow(remot_contr); remot_contr.addWindowListener(bh); ... } } Le classi GestoreWindow e GestoreWindow_TV implementano l’interfaccia WindowListener e sono utilizzate per la gestione delle finestre in fase di chiusura, riduzione ad icona ed ingrandimento. All’interno del televisore invece di essere presente un’immagine te-levisiva si è deciso di visualizzare un’immagine statica simbolica, in quan-to visualizzare una reale trasmissione televisiva non rientrava nello scopo della simulazione.

La classe Control contiene tutti i pulsanti necessari per simulare un telecomando, inseriti nel frame mediante l’utilizzo di una serie di pannelli annidati; per semplificare la progettazione si è pensato di utilizzare una classe ad hoc (Control_obj, anch’essa figlia della classe Frame) contenen-te un solo pannello del quale si può definire il contenuto ed il colore di sfondo a seconda del costruttore utilizzato. Una tecnica analoga è stata utilizzata per permettere l’inserimento di oggetti diversi all’interno dell’interfaccia utente; ciò comporta un au-mento di velocità di scrittura del codice ed una maggior “pulizia” dello stesso (trattasi del vero e proprio approccio object-oriented). Verrà di seguito trattata la tecnica con la quale si è gestita la pres-sione dei pulsanti: il problema si pone in quanto gli stessi pulsanti devono compiere azioni differenti a seconda della schermata in corso di presenta-



zione sullo schermo (ad esempio l’esecuzione di un’operazione di discesa in profondità nel menù principale è diversa dall’esecuzione di comando in un menù ambiente). Questo problema è stato risolto associando dinamica-mente ai pulsanti ascoltatori differenti (cfr. par. 4.6.4).

4.6 Realizzazione dell’interfaccia utente

4.6.1 Layout

L’interfaccia utente è caratterizzata dalla presenza di una serie di pannelli annidati; ciascun pannello è strutturato secondo layout diversi in base ai requisiti grafici richiesti (cfr. Fig. 4.8). La tecnica usata è basata nella suddivisione di un border layout in quattro blocchi principali (anch’essi pannelli). Il blocco in alto è stato ipotizzato per l’inserimento di informazioni di secondaria importanza, nella fattispecie si è pensato di in-serire l’elenco delle società partecipanti al progetto; è possibile pensare che tale spazio possa essere riservato per informazioni di carattere partico-lare o addirittura non essere utilizzato affatto rilasciando maggior spazio all’interfaccia stessa. Lo spazio in basso è destinato ai messaggi pilota (cfr. par 4.5.2.3) ed alle informazioni che l’applicazione mette a disposizione dell’utente ri-cevendole dall’impianto domotico. Tale spazio è organizzato per mezzo di un cardinal layout che permette di visualizzare alternativamente, secondo le necessità, due pannelli diversi: il primo pannello contiene l’informazione pilota per accedere alla gestione della casa.



Figura 4.8. Simulatore televisivo - layout schermo

In questo punto dell’esecuzione del programma tutti i pannelli pre-senti nell’interfaccia (tranne quest’ultimo) sono nascosti ed è presente solo l’immagine televisiva a pieno schermo. Una volta effettuato l’accesso al primo livello di profondità del menù di esplorazione, il pannello in basso si sostituisce con un secondo pannello contenente il messaggio pilota per uscire, e un ulteriore pannello il cui contenuto cambia nel momento nel quale si verificano cambiamenti di stato dei carichi dell’impianto. ... Panel grigliaDOWN; Video_obj messageACT; CardLayout PAGINA_DOWN; ... PAGINA_DOWN=new CardLayout(); grigliaDOWN=new Panel(); grigliaDOWN.setLayout(PAGINA_DOWN); grigliaDOWN.setBackground(Color.black); Panel grigliaDOWN_RED=new Panel(); grigliaDOWN_RED.setLayout(new FlowLayout());



Video_obj message=new Video_obj(grigliaDOWN_RED,"PREMERE IL TASTO",Color.yellow,Color.black,20);

Video_obj simbolo=new Video_obj (grigliaDOWN_RED, "XX", Color.red, Color.red,15);

Video_obj message2=new Video_obj(grigliaDOWN_RED, "PER GESTIRE LA CASA", Color.yellow,Color.black,20);

Panel grigliaDOWN_GREEN=new Panel(); grigliaDOWN_GREEN.setLayout(new GridLayout(2,1)); //video_obj che contiene i messaggi sulle azioni eseguite

messageACT=new Video_obj(grigliaDOWN_GREEN,"in attesa di comando...",Color.white,Color.black,18);

Panel grigliaX=new Panel(new FlowLayout()); Video_obj message3=new Video_obj(grigliaX,

"PREMERE IL TASTO" ,Color.yellow,Color.black,20); Video_obj simbolo2=new Video_obj(grigliaX,"XX",

Color.green, Color.green, 15); Video_obj message4=new Video_obj(grigliaX," PER USCIRE

DALLA GESTIONE CASA",Color.yellow,Color.black,20); grigliaDOWN_GREEN.add(grigliaX); grigliaDOWN.add(grigliaDOWN_RED,"APRI"); grigliaDOWN.add(grigliaDOWN_GREEN,"CHIUDI"); this.PannelloCentrale.add("South",grigliaDOWN); ...

La classe Video_obj, estensione di Frame, viene utilizzata per sem-plificare la scrittura del codice; istanziando oggetti della stessa classe, ma con costruttori diversi, si possono assegnare loro proprietà differenti a se-conda delle necessità, quindi differenti combinazioni di colore, di caratteri e dimensioni di questi (particolare importante ai fini della personalizzazio-ne dell’interfaccia). ...

class Video_obj extends Frame { Panel PannelloVuoto; Label label; ...



Video_obj (Panel PannelloX,String message,Color col_char,

Color col_back,Color col_bordo, int dim) { Panel PannelloVuoto=new Panel(); PannelloVuoto.setBackground(col_bordo); PannelloVuoto.setLayout(new BorderLayout()); Label label=new Label(message); label.setFont(new Font("Arial",Font.PLAIN,dim)); label.setForeground(col_char); label.setBackground(col_back); label.setAlignment(label.CENTER); Panel CENTRO=new Panel(); CENTRO.setBackground(col_back); CENTRO.add(label); Panel contornoN=new Panel(); contornoN.setBackground(col_bordo); Panel contornoS=new Panel(); contornoS.setBackground(col_bordo); Panel contornoE=new Panel(); contornoE.setBackground(col_bordo); Panel contornoW=new Panel(); contornoW.setBackground(col_bordo); ... Nella parte sinistra dello schermo viene riservato lo spazio per la fruizione della trasmissione televisiva (che continua a conservare le stesse proporzioni anche quando viene ridimensionato, il formato adottato è quel-lo classico 4:3).

Per la visualizzazione delle immagini presenti nell'applicazione vie-ne utilizzata una classe apposita, ImagePanel, che si occupa di tutti gli a-spetti di gestione grafica delle immagini dell'interfaccia (immagine rappre-sentante il programma televisivo e le icone del menù di navigazione).



4.6.2 Layout del menù Il lato destro dell'interfaccia è dedicato al menù di navigazione; è stato realizzato mediante un cardinal layout. ... PAGINA=new CardLayout(); grigliaCARD=new Panel(); grigliaCARD.setLayout(PAGINA); grigliaCARD.setBackground(Color.darkGray); ... ambienti=new Video_room[descr_vet[0].size+2]; for (i=0;i<descr_vet[0].size+2;i++) { ambienti[i]=new Video_room (grigliaCARD,descr_vet[i]); } ... I pannelli che sono alternativamente visualizzati all’interno del cardinal layout vengono creati per mezzo di una classe dedicata, Video_room, che a sua volta contiene una serie di pannelli. Viene dinamicamente creato un numero di oggetti Video_room pari al numero di ambienti della casa gestibili, ai quali si sommano il numero di ambienti indipendenti dalla personalizzazione dell’interfaccia (ovvero i due ambienti associati alle schermate “MENU” ed “ALTRO”).

Nella figura 4.9 viene raffigurato lo scheletro dell’oggetto Vide-o_room. Si osserva che è presente un pannello contenente il titolo della schermata corrente al quale si aggiunge una sequenza di pannelli conte-nenti le opzioni disponibili all’utente.



Figura 4.9. Struttura dell’oggetto Video_room

Si è deciso di allocare lo spazio necessario per visualizzare un mas-simo di dieci opzioni di scelta, facendo in modo che un pannello abbia sempre la stessa posizione e dimensione indifferentemente dal numero di pannelli presenti sullo schermo (ovvero il numero di scelte); questa scelta è alternativa ad uno sfruttamento ottimizzato dello spazio che prevede il ridimensionamento dinamico dei pannelli, senza lasciare spazi vuoti. I pannelli “MENU” ed “ALTRO”, precedentemente descritti, sono sempre presenti, qualunque sia la schermata visualizzata, tranne nel caso in cui ci si trovi negli ambienti corrispondenti. I restanti pannelli (in numero N=8) non sono necessariamente tutti visualizzati, vengono infatti resi visibili so-lo i primi n pannelli corrispondenti alle n opzioni predisposte per l’ambiente in questione in fase di programmazione. ... Video_obj label=new Video_obj(PannelloVuoto0,

descr.title.toUpperCase().substring(1), Color.black,Color.orange,descr.colore,22);

num=new Video_obj[size]; load=new Video_obj[size]; imm=new ImagePanel[size]; for (i=0;i<size;i++ ) { imm[i]= new ImagePanel();



PannelloVuoto3.add(imm[i]); } for (i=0;i<size_options ;i++ ) { room_options[i]=descr.opt[i]; num[i]=new Video_obj(PannelloVuoto1,numeri[i],

Color.black,Color.yellow,24); load[i]=new Video_obj(PannelloVuoto2,

room_options[i].toUpperCase(), Color.black,Color.lightGray,22);

} ... La classe Video_room, inoltre, contiene una serie di metodi per il controllo delle icone associate allo stato dei dispositivi (accensio-ne/spegnimento e ridisegnamento).

4.6.3 Personalizzazione La personalizzazione dell’interfaccia utente si è resa necessaria al fine di rendere l’applicazione aperta all’utilizzo di impianti domotici ca-blati in modi differenti; per effettuare tale operazione è stato creata una ba-se dati di configurazione (per semplicità è stato utilizzato un file di testo) nell’ipotesi che l’utente finale possa accedervi tramite una applicazione dedicata oppure per mezzo di un accesso diretto alla macchina utilizzata, cioè attraverso una delle connessioni che essa mette a disposizione (seria-le, modem, altro).

In Fig. 4.10 è rappresentata la struttura del file contenente le infor-mazioni necessarie alla costruzione della base dati ed è riportato un seg-mento dello stesso per agevolarne la comprensione. Sono indicati i titoli del menù, le opzioni contenute e gli indirizzi dei dispositivi associati (le parti non evidenziate contengono informazioni relative alle icone ed ai col-ri di personalizzazione)



Figura 4.10. Struttura della base dati



Attualmente, per l’assenza di specifiche imposte dall’MHP in meri-to, l’utente dipende solo ed esclusivamente dall’applicazione trasmessa in broadcast, non è cioè possibile effettuare configurazioni al fine di eseguire procedure diversificate; questo è stato il motivo che ha condotto alla rea-lizzazione di una tecnica di memorizzazione più semplice possibile, la-sciando libero spazio alle future implementazioni della piattaforma digita-le.

La base dati è caratterizzata da una allocazione statica di risorse di memoria (statica dal punto di vista della quantità complessiva di memoria allocata); questa scelta risulta plausibile in quanto si è previsto un numero massimo di possibili opzioni all’interno di una pagina del menù; così fa-cendo l’applicazione impegna sempre la stessa quantità di risorse, renden-dola complessivamente più semplice, anche dal punto di vista della com-plessità di scrittura del codice sorgente.

In fase di caricamento dell’interfaccia utente vengono utilizzate le classi Scan e Description, rispettivamente per l’acquisizione da file delle informazioni e per la composizione della base dati vera e propria, cui campi sono riassunti di seguito:

ü Title – titolo della finestra corrente del menù; ü Colore – colore associato al titolo;

ü Size – numero delle voci personalizzabili presenti nella finestra cor-

rente (per come è stata ideata l’interfaccia possono essere al massi-mo otto);

ü Opt – vettore di stringhe contenente le voci personalizzabili di cui

sopra; ü Col_vett, ico_on, ico_off – vettori contenenti i colori o le icone as-

sociati alle voci del menù; ü Chi, dove – vettori che contengono le informazioni indispensabili

per pilotare l’impianto (ossia gli indirizzi dei singoli dispositivi), il cui significato verrà ampiamente descritto nel capitolo 5.



Figura 4.11. Versione dell’applicazione per persone con disturbi

di percezione cromatica In Fig. 4.11 è riportato un esempio di come è possibile personaliz-zare l’interfaccia per andare incontro a problematiche specifiche, nella fat-tispecie, applicando principalmente la combinazioni di colori giallo su ne-ro si favorisce la fruizione di un’utenza caratterizzata da percezioni croma-tiche ridotte.

4.6.4 Ascoltatori del telecomando Per la gestione degli ascoltatori degli eventi associati alle pressioni dei tasti del telecomando è stata definita una superclasse ascoltatore (Ge-store_action) che contiene il funzionamento di base dei tasti, ed una serie di classi figlie di questa che sovrascrivono in modo dinamico i metodi ne-cessari alle funzionalità correnti richieste; in pratica viene creato un set di ascoltatori (in numero uguale al numero delle possibili schermate visibili all’utente) che si alternano al susseguirsi delle pagine (cfr. Fig. 4.12).



Figura 4.12. Associazione dinamica tasto – operazione

4.6.4.1 Superclasse Gestore_action La classe Gestore_action implementa l’interfaccia ActionListener per la gestione degli eventi appartenenti alla classe ActionEvent (di questi sono d’interesse gli eventi relativi alla pressione pulsanti). Questa classe non viene mai usata direttamente, vengono altresì istanziati oggetti appar-tenenti alle classi figlie di questa; ciò permette di dare uno scheletro alla gestione degli ascoltatori, consentendo di creare nuove classi di ascolto qualora se ne presentasse la necessità. La classe prevede tre costruttori di-versi ed una serie di metodi ereditabili; tali metodi possono essere utilizza-ti dalle classi figlie oppure possono venire sovrascritti dalle stesse (al fine di aggiungere funzionalità specifiche). I metodi principali della classe Gestore_action sono: ü Set_listener (Gestore_action corrente, Gestore_action nuovo) - u-

tilizzato per spostare la gestione dei pulsanti del telecomando da un ascoltatore all’altro.



... comando.tasto1.BottoneX.removeActionListener(corrente); comando.tasto1.BottoneX.addActionListener(nuovo); ... In particolare l’ascoltatore corrente, qualora debba passare il con-trollo ad un altro ascoltatore, invoca questo metodo, al quale passa se stes-so ed il nuovo ascoltatore; di seguito viene riportato questo principio di funzionamento: ... class Gestore_actionXXX extends Gestore_action { ... Gest1=new Gestore_actionXXX (...); ... this.Set_listener(this, Gest1); ... ü actionPerformed (ActionEvent e) – è un metodo che deve essere

necessariamente implementato quando si utilizzano delle interfacce di questo tipo; quando si rileva la pressione di un pulsante viene e-seguita una funzione ad esso direttamente associata. Questo metodo è identico per tutte le classi derivate dalla Gestore_action e non vi è la necessità di riscriverlo in quanto tali classi riscriveranno soltanto le funzioni che verranno descritte di seguito.

... public void actionPerformed (ActionEvent e) { if (e.getSource() instanceof Button) { Bott=(Button)e.getSource(); stringa=Bott.getLabel(); ... if (stringa.compareTo("1") == 0) funz1(); ... if (stringa.compareTo("9") == 0) funz9(); ...



ü funz0 ( ) , ... , funz9 ( ), funzRED ( ), funzGREEN ( ), ... – questi metodi non aggiungono alcuna complessità, vengono implementate solo con lo scopo di essere riscritte; qualora non lo fossero, visua-lizzano a video un semplice messaggio di servizio.

... public void funz1() { tvcolor.messageACT.SetLabel("Pressione tasto 1"); waiting(); } ... public void waiting() { try { client.thread1.me.sleep(3000); } catch(Exception e) { System.out.println(e); } tvcolor.messageACT.SetLabel("in attesa di comando.."); } ... Il metodo waiting () non fa altro che visualizzare nella sezione dell’interfaccia dedicata ai messaggi pilota l’informazione di attesa di co-mando, dopo un tempo prefissato, in seguito all’esecuzione di una qualun-que operazione. ü funzUP ( ), funzDOWN ( ), funzOK ( ) – vengono utilizzati in as-

sociazione con i pulsanti freccia ‘UP’, ‘DOWN’ e ‘OK’ del teleco-mando per effettuare la navigazione evidenziando le voci del menù mediante l’utilizzo del metodo light(String direction, int i). Al me-todo funzOK ( ) è combinato il richiamo delle funzioni definite nel punto precedente. Tali metodi sono definiti solo in questa fase e mai sovrascritti in quanto tutti gli ascoltatori realizzano queste funziona-lità nel medesimo modo.



4.6.4.2 Sottoclassi di ascolto Vengono definite quattro sottoclassi della classe base Gesto-re_action. Il funzionamento di queste classi può essere descritto per mezzo di una macchina a stati, ove ciascuna di queste classi derivate è assimilabi-le a uno stato specifico: il passaggio da uno stato all’altro è equivalente al-la sostituzione di un ascoltatore con un altro ed è la conseguenza di un comando dato dall’utente. Di seguito verranno descritti gli stati della FSM, descritta in Fig. 4.13: ü Gestore_action_start – All’avvio dell’applicazione (cfr. Fig. 4.3),

essa si mette in attesa della sola pressione del tasto ‘ROSSO’ (la pressione di qualsiasi altro tasto è ininfluente); in questa classe vie-ne semplicemente sovrascritto il metodo funzRED ( );

ü Gestore_action_stanza – Alla pressione del tasto rosso (cfr. Fig.

4.5) viene caricato questo ascoltatore; in seguito ad una scelta effet-tuata dall’utente sul menù principale verrà sostituito da uno dei pos-sibili ascoltatori dei singoli ambienti;

ü Gestore_action_ambienti – Questo tipo di ascoltatore viene carica-

to in seguito ad una scelta di un ambiente (cfr. Fig. 4.6), da monito-rare o comandare. Poiché possono esistere molteplici ambienti è ne-cessario istanziare un oggetto di questa classe per ognuno di essi, tale creazione viene effettuata in modo dinamico al momento dell’avvio dell’applicazione stessa. Diversamente, per le classi pre-cedenti viene istanziato staticamente un solo oggetto.

... Gest_START=new Gestore_action_start(this,window,

report,client); Gest_STANZA=new Gestore_action_stanza(this,window,

window.ambienti[0],report,client); int i; Gest_AMBIENTI=

new Gestore_action_ambienti[window.descr_vet[0].size+1];



for (i=0;i<window.descr_vet[0].size+1;i++) { Gest_AMBIENTI[i]=newGestore_action_ambienti(this,

window,window.ambienti[i+1],report,client); } ...

ü Gestore_tapparelle – Si è presentato il problema della gestione di

un carico particolare quale il movimentatore delle tapparelle; a dif-ferenza di tutti gli altri carichi esso non può essere gestito da una semplice operazione di on/off (comando su impianto di illumina-zione) bensì necessita di un controllo su tre possibili stati di funzio-namento (su, giù, fermo). La soluzione adottata consiste nell’utiliz-zare un nuovo ascoltatore che riscrive le funzioni usate per lo scorrimento del menù (funzioni associate ai tasti freccia e al tasto ‘OK’). Un ascoltatore di questo tipo viene creato nell’ambiente visualizzato ed è in grado di gestire tutti gli automatismi presenti nello stesso.

Figura 4.13. Macchina a stati degli ascoltatori



Figura 4.14. Tapparelle- selezione

Figura 4.15. Tapparelle- comando UP

Capitolo 5

Interazione dell’interfaccia con l’impianto domotico 5.1 Premessa Gli argomenti trattati in questo capitolo sono frutto dello studio del materiale informativo fornito da BTicino; questa società, operando in un ambito commerciale estremamente competitivo, ha concesso, ai fini della ricerca, del materiale logicamente protetto da riservatezza, di conseguenza non completamente divulgabile e pubblicabile.

Per questo motivo le informazioni contenute in questo capitolo e nell’Appendice potranno essere deficitarie di alcune parti, sebbene impor-tanti ai fini della comprensione d’insieme degli argomenti trattati (inoltre i segmenti di codice riportanti informazioni non pubblicabili vengono sosti-tuiti con il simbolo “ §§§§§§ ”).

Cap. 5 - Interazione dell’interfaccia con l’impianto domotico


5.2 Obiettivi Nel capitolo 4 è stata descritta la tecnica con la quale si è realizzata l’applicazione destinata alla gestione dell’impianto di automazione dome-stica, concentrando gran parte delle attenzioni sulla realizzazione dell’interfaccia utente. Nel capitolo corrente si descrive come tale interfaccia possa instau-rare una connessione con l’impianto domotico per permettere un elevato grado di interattività tra l’utente e l’impianto medesimo. Come mostrato in Fig. 5.1, si possono individuare diverse modalità d’accesso alla rete domestica. Il modo più intuitivo per realizzare tale ac-cesso è quello di interfacciarsi direttamente al BUS tramite porta seriale (cfr. Par. 2.3); in fase di progetto tale possibilità è stata esclusa a priori in quanto una connessione di basso livello come questa, che non consente di sfruttare tutte le funzionalità offerte dall’impianto, esula dagli obiettivi specifici del progetto. Poiché si vuole creare una simulazione di un decoder digitale terrestre che sfrutta il secondo profilo di ricevitori MHP, Interactive Broadcast (cfr. Par. 3.6), è necessario utilizzare una connessio-ne di livello più alto tra utente e impianto domotico, realizzabile attraverso l’utilizzo di almeno due protocolli di comunicazione differenti; si può pen-sare di comunicare sia a livello applicazione (http) e che a livello trasporto (TCP), in riferimento al modello ISO-OSI.

5.3 Scelte progettuali Per realizzare una comunicazione di questo tipo è necessaria la pre-senza, all’interno della catena utente-impianto, di un nodo dotato di un’intelligenza tale da trasportare a livello fisico (BUS) tutte le informa-zioni ricevute, comportandosi come un vero e proprio gateway tra i due si-stemi. L’impianto cablato da BTicino prevede di poter utilizzare a tal fine un dispositivo di controllo denominato web-server (nel sistema domotico in questione è stato utilizzato il modello F451V). Mediante l’impiego del web-server si offre all’utente la possibilità di comandare e controllare a distanza, tramite un PC connesso ad una rete Ethernet o via modem su una linea telefonica, tutte le funzioni integrate presenti nell’abitazione. Il simulatore di cui al capitolo precedente ha rea-



lizzato un’interazione, descritta in seguito, con tale web-server mediante un collegamento in rete locale.

Figura 5.1. Interazione tra interfaccia e impianto Nel paragrafo 2.4 è stato descritto come, mediante un particolare protocollo, un’unità remota possa scambiare dati e inviare comandi ad un sistema a tecnologia BUS. Si ricorda come il codice OPEN Web Net sia caratterizzato da una struttura con campi a lunghezza variabile separati dal carattere speciale ‘*’ e chiuso con ‘##’. Viene di seguito riportata la strut-tura logica del codice, di fondamentale importanza per la comprensione dei paragrafi successivi:

* CHI * COSA * DOVE * QUANDO ##.



5.3.1 Connessione HTTP Per quanto riguarda la connessione in http si è sfruttata una caratte-ristica fondamentale del web server, quella di poter essere interpellato di-rettamente da un browser web; il web server viene programmato per pre-sentare all’utente una serie di pagine html contenenti i comandi, classifica-ti per tipo, che sono stati scelti per la gestione remota dell’impianto. Per accedere a tali pagine l’utente si collega ad un server di gestione messo a disposizione degli utenti BTicino che, dopo aver verificato login e password, apre una comunicazione con il web-server F451V, il quale a sua volta diventa accessibile solo dopo il passaggio attraverso un ulteriore li-vello di sicurezza. Per interfacciare l’applicazione in http è stato saltato il primo livello di sicurezza collegandosi direttamente all’indirizzo statico del web server sulla rete locale (tale indirizzo deve essere precedentemente assegnato al web-server attraverso il software di configurazione). Per mezzo della classe Home_action si crea un canale di comunica-zione (URLConnection) attraverso il quale si inviano al web-server (alla funzione che nell’uso normale interpreta la pressione di un pulsante nella pagina web) un comando come serie di campi nel formato:

FUNZIONE=COMANDOSCS & CHI=chi & COME=come & DOVE=dove

I campi della stringa inviati sull’OutputStreamWriter sono ricondu-cibili ai campi che caratterizzano il codice di comunicazione OPEN, il web server provvede ad interpretarli per il trasferimento a livello fisico. import java.net.*; import java.io.*; ... class Home_action { ... void azione(String chi,String come,String dove) { try { String data = URLEncoder.encode("FUNZIONE") + "=" +

URLEncoder.encode("COMANDOSCS");



data+= "&"+URLEncoder.encode("CHI")+"="+URLEncoder.encode(chi);

data+= "&"+URLEncoder.encode("COME")+"="+URLEncoder.encode(come);

data+= "&"+ URLEncoder.encode("DOVE")+"="+ URLEncoder.encode(dove); URL url =new URL

("http://192.168.10.2/cgi-bin/cgi-bin/query_get"); URLConnection conn = url.openConnection(); conn.setDoOutput(true); OutputStreamWriter wr =

new OutputStreamWriter(conn.getOutputStream()); wr.write(data); wr.flush(); BufferedReader rd = new BufferedReader

(new InputStreamReader(conn.getInputStream())); String line; while ((line = rd.readLine()) != null) {} rd.close(); } catch (Exception e) System.out.println("Exception"); } } Dopo aver effettuato le necessarie operazioni di login, l’applicazione trasforma la richiesta effettuata dall’utente per mezzo dell’interfaccia, tramite il metodo azione della classe Home_action, il qua-le riceve come parametri d’ingresso i codici associati ai tre campi fonda-mentali della codifica OPEN. Il web-server risponde ai comandi inviatigli per mezzo di pagine HTML contenenti informazioni del tipo “comando eseguito”, “comando non eseguito”, “comando errato”. L’unico modo affinché l’applicazione riesca a “girare” queste informazioni all’utente è interpretare il contenuto del buffer di ingresso per trovare nel codice HTML i dati necessari. Una tecnica di questo tipo, oltre essere poco elegante e dispendiosa in termini di occupazione di risorse, è estremamente limitativa: è infatti possibile ef-

http://192.168.10.2/cgi-bin/cgi-bin/query_get



fettuare le sole operazioni permesse dalle applicazioni WEB residenti sul dispositivo (non è possibile, per esempio, effettuare l’interrogazione dello stato di un attuatore). Queste limitazioni hanno portato all’abbandono dell’impiego di una comunicazione di questo tipo orientando la scelta ver-so l’utilizzo di una connessione TCP.

5.4 Connessione TCP Attraverso una comunicazione TCP è possibile colmare le lacune presentate dalla comunicazione HTTP, permettendo di sfruttare al meglio tutte le potenzialità offerte dall’impianto e rendendo al tempo stesso l’applicazione adattabile a qualsiasi sistema di impianto domotico che permetta un accesso remoto allo stesso. Il collegamento al web-server in TCP avviene per mezzo di un so-cket Java; l’applicazione si comporta da client chiedendo al web-server di metterle a disposizione delle risorse, per poi comunicare con esso attraver-so il codice OPEN Web Net. Ogni comando inviato al web-server è segui-to da una risposta da parte di esso attestante l’esito della richiesta mediante l’invio di un ACK o un NACK. La creazione della connessione (creazione del socket) avviene all’avvio dell’applicazione. public class Casa { public static void main(String[] args) { Casa_client client=new Casa_client(); ... client.connect(); client.thread1=new Alert(" §§§§§§ ",3,client,window); client.thread1.me.start(); } }



5.4.1 Procedura di login Dal momento in cui il web-server accetta la richiesta di connessione è necessario effettuare una procedura di login per superare il livello di si-curezza imposto per accedere all’impianto da remoto. Nella procedura di login vengono effettuate due particolari opera-zioni; la prima consiste nel fornire al web-server una informazione relativa al tipo di comunicazione che si vuole instaurare (per esempio informazioni riguardanti il tipo di accesso, quale può essere Internet o LAN), mentre la seconda consiste in una procedura di crittografia di una password (password settata sul web-server in fase di programmazione dello stesso mediante il software TiWeb di BTicino). public class Casa_client { static Socket socket; ... public Alert thread1; ... public static void connect() { try { StringBuffer str = new StringBuffer(128); socket = new Socket(address,PORTNUM); in = new DataInput-Stream(socket.getInputStream()); out = new DataOutput-Stream(socket.getOutputStream()); lettura(); scrittura(" §§§§§§ "); char[] parola=lettura(); Critta xxx=new Critta(); xxx.critta_parola(parola); scrittura(" §§§§§§ "); lettura(); return; } ... }



La classe Casa_client sopra riportata contiene, inoltre, i metodi ne-cessari ad espletare le operazioni di servizio per la gestione della connes-sione (apertura, chiusura,lettura e scrittura). La procedura di crittografia della password viene effettuata per mezzo della classe Critta, omessa sia qui che in Appendice per i motivi espressi nella premessa del capitolo (cfr. Par. 5.1).

5.4.2 Gestione della connessione Una delle caratteristiche del web-server è la chiusura della connes-sione da parte di questo nell’eventualità in cui non riceva comandi nell’arco di un tempo pari a 30 secondi. Poiché l’utente può impiegare un tempo superiore a 30 secondi per eseguire comandi successivi, il problema della disconnessione automatica del web-server diventa rilevante; le possi-bili soluzioni possono essere due: ripristinare la connessione, qualora sia chiusa, nel momento in cui viene richiesta l’esecuzione di un nuovo co-mando, oppure, mantenere in qualche modo la connessione sempre attiva. E’ stato scelto di utilizzare il secondo metodo poiché si riducono i tempi di ritardo dovuti alla procedura di connessione; per fare ciò viene inviato al web-server un comando di interrogazione in modo ciclico (nel menù prin-cipale e nel menù scenari si interroga il web-server sulla data corrente, nei menù ambienti l’interrogazione riguarda lo stato dei dispositivi). Il client, rappresentato dall’oggetto Casa_client, per ottemperare all’esecuzione di interrogazioni di vario genere e all’invio di comandi, i-stanzia un solo processo costituito dall’oggetto Alert; questa soluzione si contrappone a quella di creare un numero di thread separati che si alterne-rebbero nella gestione di operazioni differenti. La presenza di un unico oggetto di questo tipo rende l’applicazione più leggera e più semplice da gestire (cfr. Figura 5.2). public class Alert implements Runnable { ... public Alert(String msg,int sleep_time,Casa_client cl,Video tv) {



message=msg; client=cl; how_long= sleep_time * 1000; tvcolor=tv; me = new Thread(this); i=0; } public void run () { ... } public void set_comando(int x,String msg,Video_room amb,

int p,String a) { flag=x; message_bak=msg; ambiente=amb; pos=p; act=a; } Per mezzo del metodo set_comando di Alert è possibile modificare il processo attivo adattandolo alle necessità specifiche mediante il passag-gio di opportuni parametri che serviranno a differenziare le operazioni che il processo deve eseguire in fase di dialogo con il web-server. Il processo, in pratica non solo è sempre attivo, ma invia continuamente messaggi al web-server, ciò che varia è il tipo di messaggio e la cadenza dei cicli d’invio.

5.4.3 Interrogazioni All’avvio dell’applicazione, come descritto nei paragrafi precedenti, viene avviata la procedura di connessione e l’applicazione caricherà il ge-store degli ascoltatori Gestore_action_start; in questo stato dell’applicazione il processo Alert provvederà, data l’impossibilità di in-viare comandi di alcun tipo ai dispositivi dell’impianto, ad inviare cicli-



camente (ogni 3 secondi), una Request time al web-server al fine di man-tenere sempre attiva la connessione. In seguito alla pressione del tasto ‘ROSSO’ l’applicazione evolve allo stato successivo nel quale dal punto di vista del processo non accade nulla di diverso dallo stato precedente (si continua ad effettuare una richie-sta ciclica per tenere attiva la connessione con il web-server). In questo momento dell’esecuzione il gestore degli ascoltatori cambia e diventa Gestore_action_stanza.

Figura 5.2. Relazione ascoltatori / processo

class Gestore_action_stanza extends Gestore_action { ... public void act_funz(int pos) { tvcolor.PAGINA.show(tvcolor.grigliaCARD,

tvcolor.descr_vet[pos+2].title); de_light(); tvcolor.validate(); tvcolor.ambienti[pos+2].load_ico(); String s=new String("*#interrogazione"); client.thread1.set_comando(2,s,

comando.Gest_AMBIENTI[pos+1].ambiente,0,"0");



Set_listener(this,comando.Gest_AMBIENTI[pos+1]); } public void funz1() { if (tvcolor.descr_vet[0].size>=1) act_funz(0); else super.funz1(); } ... public void funz8() { ... } ... Lo stato corrente dell’applicazione offre all’utente la sola possibilità di scelta dell’ambiente; soltanto quando si accede ad un ambiente specifico è possibile effettuare le operazioni di comando dei dispositivi presenti in esso. Nell’oggetto Gestore_action_stanza vengono ridefiniti i metodi re-lativi alla pressione dei tasti del telecomando ereditati dalla superclasse a-scoltatore; poiché tali metodi devono effettuare lo stesso tipo di operazioni vengono riscritti soltanto per associare tali funzioni al metodo act_funz, ri-chiamato da tutti i metodi funz-N. In seguito alla scelta di un ambiente, di conseguenza alla chiamata del metodo act_funz da parte di una delle funz-N , l’ascoltatore corrente provvede ad avviare la procedura di interrogazione di tutti i dispositivi presenti nell’ambiente selezionato mediante il metodo set_comando della classe Alert (per mezzo del parametro String s = *#interrogazione" viene inviato un codice corrispondente alla richiesta di questo tipo). ... if (message_bak.compareTo("*#interrogazione")==0) ... while (true) { try { switch (flag)



{ ... if (i==ambiente.descr.size) { i=0; if (x==1) { tvcolor.messageACT.SetLabel("in attesa di coman-do.."); x=0; } } this.client.scrittura(" §§§§§§ "); contr=this.client.lettura(); this.client.lettura(); ... i++; } } } Il metodo scrittura (String data) di Casa_client è preposto all’effettivo invio dei comandi al web-server in codice OPEN (per questo motivo nelle righe di codice presenti nel capitolo è stato nascosto). Il formato di un comando di richiesta di interrogazione dello stato di un dispositivo prevede la presenza di due campi: uno rappresenta il tipo di dispositivo da interrogare (campo “CHI”), ossia automatismo o illumina-zione, l’altro rappresenta l’indirizzo fisico del dispositivo sul BUS (campo “DOVE”). Il web-server risponde inviando all’applicazione un’informazione in codice OPEN contenente tre campi: i due sopra citati ed il campo “CO-SA”, relativo allo stato del dispositivo (0/1 per ON/OFF illuminazione o 0/1/2 per STOP/UP/DOWN automatismi). Successivamente il web-server provvede all’invio di un messaggio di ACK come conferma di corretta e-secuzione del comando; in caso contrario esso provvede solo all’invio di un messaggio NACK (le operazioni di ricezione dei messaggi inviati dal web-server avviene mediante il metodo lettura dell’oggetto Casa_client). L’applicazione è a conoscenza dei campi “CHI” e “DOVE” relativi ai sin-



goli comandi perché questi vengono acquisiti dal file di configurazione de-scritto nel paragrafo 4.6.3. All’interno del ciclo d’interrogazione viene effettuato un controllo sullo stato del dispositivo facendo particolare attenzione alle diverse mo-dalità di interrogazione tra dispositivi di illuminazione ed automatismi. ... if (ambiente.descr.chi[i].compareTo("2")==0) { if( contr[3]=='1') contr_b=true; if( contr[3]=='2') contr_b=true; if( contr[3]=='0') contr_b=false; } else { if( contr[3]=='0') contr_b=false; else contr_b=true; } ... Effettuando questo controllo real time dello stato dei dispositivi, nel caso venisse rilevata una variazione rispetto allo stato precedente, l’applicazione deve fornire informazioni all’utente, cioè provvedere all’aggiornamento del messaggio di testo contenente informazioni sul cambiamento di stato avvenuto e all’aggiornamento dell’icona rappresen-tante lo stato del dispositivo stesso. Anche in questo caso l’eventuale pre-senza di automatismi prevede una gestione particolare. ... if(contr_b!=(ambiente.state[i])) { if (ambiente.descr.chi[i].compareTo("2")==0) { if( contr[3]=='1') { ambiente.imm[i].load

("icone/tapparella_APRI.bmp"); ambiente.state[i]=true;



} if( contr[3]=='2') { ambiente.imm[i].load("icone/tapparella_CHIUDI.bmp"); ambiente.state[i]=true; } if( contr[3]=='0') { ambiente.imm[i].load(ambiente.ico_false[i]); ambiente.state[i]=false; } } else { ambiente.flip_ico(i); tvcolor.messageACT.SetLabel((ambiente.descr.opt[i]+"

"+ambiente.descr.title.substring(1)+" "+ambiente.flip_mes(i)).toUpperCase());

x=1; } } ... L’applicazione è stata progettata per rilevare, per mezzo delle pro-cedure di interrogazione fin qui descritte, qualsiasi cambiamento di stato dei dispositivi presenti nell’ambiente in corso di visualizzazione; non ven-gono rilevati solo cambiamenti imposti all’interno dell’applicazione, ma anche quelli generati da comandi effettuati per mezzo di azioni fisiche di pressione interruttori Nel caso la scelta dell’ambiente sia quella relativa agli scenari, poi-ché non sono presenti dispositivi il cui stato possa essere interrogato, la procedura di interrogazione ritorna ad essere la medesima del menù prin-cipale (Request time); la gestione di questi, ed altri, dettagli di secondo piano viene effettuato per mezzo di controlli presenti nella classe Alert, ovvero vengono effettuati dal processo stesso in corso di esecuzione.



5.4.4 Comandi Dopo aver compiuto la scelta dell’ambiente lo stato corrente dell’applicazione è gestito dal gestore di ascoltatori Gesto-re_action_ambienti (in questo oggetto è presente il metodo action_funz necessario alla gestione dei comandi da inviare ai dispositivi dell’impianto domotico). ... public void action_funz(int pos) { String str=new String(); String act=new String(); boolean stato=ambiente.state[pos]; if (stato==true) act="0"; if (stato==false) act="1"; Integer k=new Integer(pos+1); char[] flag; if (ambiente.descr.chi[pos].compareTo("2")==0) { de_light(); tapp.posizione=pos; select_light(pos); tvcolor.messageACT.SetLabel(("PER "+ambiente.descr.opt[pos]).toUpperCase()+" UTILIZZARE I CUR-SORI"); Set_listener(this,this.tapp); } if (ambiente.descr.chi[pos].compareTo("0")==0) { String s=new String("*0*"+k.toString()+

"*"+ambiente.descr.dove[pos]+"##"); client.thread1.set_comando(2,s,ambiente,pos,act); de_light(); } if (ambiente.descr.chi[pos].compareTo("1")==0)



{ String s=new String("*"+ambiente.descr.chi[pos]+

"*"+act+"*"+ambiente.descr.dove[pos]+"##"); client.thread1.set_comando(2,s,ambiente,pos,act); de_light(); } tvcolor.validate(); return; } ... Mediante il metodo action_funz si provvede a modificare la stringa contenente la sequenza di comandi OPEN Web Net da inviare al web-server per mezzo del metodo set_comando; nel codice sopra riportato è presente una stringa contenente la sequenza di campi per inviare un co-mando nel formato previsto dal codice OPEN Web Net, tale stringa viene passata coma parametro al metodo set_comando ampiamente descritto. ... this.client.scrittura(message); contr=this.client.lettura(); if (contr[3]!='0') { if (ambiente.descr.chi[pos].compareTo("1")==0) { ambiente.flip_stato(pos); ambiente.flip_imm(pos); str=ambiente.flip_mes(pos); tvcolor.messageACT.SetLabel

((ambiente.descr.opt[pos]+" "+ ambiente.descr.title.substring(1)+

" "+str).toUpperCase()); x=1; } if (ambiente.descr.chi[pos].compareTo("0")==0) ... if (ambiente.descr.chi[pos].compareTo("2")==0) ... } else { tvcolor.messageACT.SetLabel("COMANDO NON ESEGUITO"); } flag=3; me.sleep (how_long);



Quando viene inviato un comando (inteso come azioni sugli attuato-ri dell’impianto) al web-server il processo di interrogazione evolve nella condizione di invio comando SCS (l’invio di un comando è vincolato alla terminazione dell’interrogazione, del singolo dispositivo, in corso).

Figura 5.3. Evoluzione del processo Alert

Al termine della procedura di invio comando il processo ritorna nel-

la fase interrogazione carichi, riprendendola dal carico successivo all’ultimo interrogato. Al fine di evitare conflitti tra invio comandi e ri-chiesta interrogazioni, dopo l’invio di un comando il processo rimane in pausa per un tempo di 3 secondi, a differenza di questo le interrogazioni,



effettuate ciclicamente, non utilizzano nessun tempo di ritardo (ogni nuova interrogazione viene effettuata solo alla ricezione del messaggio di ACK relativo alla precedente). Tutto ciò concorda con i risultati presentati al Par. 5.4.4. In Figura 5.3 viene brevemente riassunto il comportamento del processo che gestisce la comunicazione con il web-server, descrivendo quali sono le modifiche al tipo di messaggio inviato, parallelamente a quelle che sono le scelte dell’utente.

5.4.5 Analisi dei tempi Per analizzare il comportamento del web-server quando vengono inviati messaggi di vario tipo è stato utilizzato il software Web Server TEST di BTicino, misurando la tempistica della comunicazione tra appli-cazione e sistema domotico.

Nello specifico viene misurato il tempo che intercorre tra l’invio di un comando OPEN e la ricezione del messaggio di ACK da parte del web-server; questo tempo è leggermente diverso dal tempo trascorso tra l’invio di un comando e l’effettiva attivazione di un carico, strettamente dipen-dente dal tipo di carico e dal tempo di propagazione del comando sul BUS.

Tipo comando Comando OPEN

Tmin [ms]

Tmax [ms]

Tmed [ms]

ACCENSIONE LUCI

*1*1*19## 49 110 75

INTERROGAZIONI LUCI

§§§§§§ 329 550 432

ATTIVAZIONE SCENARIO

*0*1*03## 330 550 438

INTERROGAZIONE DI DUE CARICHI

§§§§§§ 869 990 915

Tabella 5.1. Tempi di ritardo

Tali misurazioni sono state condotte sia in condizioni normali che

in condizione di “stress” del sistema (invio rapido di sequenze di coman-di).Sono stati compiuti vari test per verificare i tempi di ritardo in quattro situazioni possibili d’invio di comando al web-server.



Figura 5.4. Web Server TEST – ciclo di comandi In tabella 5.1 sono mostrati i risultati ottenuti applicando cicli di

comandi, con tempo di ritardo tra un comando e il successivo pari a 0,5 secondi; si nota come sia impossibile effettuare tale ciclo, con un tempo di ritardo così breve, nel caso di attivazione di uno scenario poiché il tempo trascorso sino alla ricezione del messaggio di ACK risulta pari a circa 0,915 secondi. L’applicazione sin qui descritta, nel caso di richiesta da parte dell’utente di accensione di un generico punto luce, impiega circa 100 ms per realizzare il comando; un ritardo in quest’ordine di grandezza, poiché non percepibile dall’utente, rende l’applicazione eccellente nell’ambito delle prestazioni. Nel caso di interrogazioni il tempo di ritardo è maggiore, ma poiché l’utente non agisce direttamente su comandi di questo tipo, con-



tinua a non essere una forma di disturbo (l’interesse primario dell’utente continua ad essere l’esecuzione più rapida possibile di un comando del ti-po illuminazione).

Capitolo 6

Realizzazione dell’interfaccia domestica su Set Top Box 6.1 Introduzione Scopo di questo capitolo è descrivere il processo di trasferimento, sviluppo e simulazione dell’interfaccia domestica, descritta precedente-mente, su una piattaforma televisiva digitale terrestre mhp. Questa fase del progetto è stata ampiamente supportata dal C.R.I.T. RAI (Centro Ricerche e Innovazione Tecnologica), che ha cortesemente collaborato mettendo a disposizione un tool di authoring per lo sviluppo di applicazioni mhp, il si-stema per il caricamento, simulazione e monitoraggio dell’applicazione su decoder, coadiuvando il lavoro con la consulenza del proprio personale.

Cap. 6 - Realizzazione dell’interfaccia domestica su Set Top Box


6.2 Authoring tool Un Authoring tool, anche conosciuto come Authorware, è un sof-tware che consente di scrivere applicazioni multimediali; tali programmi permettono di creare applicazioni finali semplicemente mettendo in rela-zione oggetti differenti. Definendo le relazioni tra gli oggetti, e mettendoli in sequenza in un ordine adatto, gli autori (cioè gli utilizzatori di authoring tools) possono produrre applicazioni utili e attraenti, senza la necessità di avere una conoscenza approfondita della programmazione. La maggior parte dei sistemi di authoring supporta lo scripting di linguaggi per appli-cazioni più sofisticate. Gli authoring tools richiedono una conoscenza tecnica meno appro-fondita rispetto a veri software di programmazione, sono, infatti, usati e-sclusivamente per applicazioni che presentano una mistura di : ü Text Editing ü Symbol-Level Editing ü Graphics Editing ü Content Management ü Constrained Editing ü Timeline Editing ü Format Conversion.

Per la produzione di applicazioni mhp compatibili esistono sul mer-cato numerosi authoring tool (cfr. tabella 6.1). Aircode The 'TVPlus i Station' authoring tool Alticast The 'Alticomposer' authoring tool Canal+ The MHP Development Kit Cardinal Information Systems

'Cardinal Studio' authoring tool

Core Media Starter Kit for MHP DTV Interactive Institut Für Rundfunkte-chnik

Application Analyser (German)

Mindhouse Content management system and applica-tions

Panasonic Application Development Kit



Softel The 'Sublime iTV Suite' authoring tool Sony Professional Broa-dcast

'Media Gateway' authoring tool

Snap2 The 'Gear' authoring tool Sublime software 'Sublime iTV Suite' authoring tool Technidata Content management system and applica-

tions TeleIDEA 'IdeaPublisher' and 'TeleAuthor' authoring

tools Unisoft the MHP Security File Generator Videsti authoring tools Zappware 'EZTV' Customizable applications

Tabella 6.1. Authoring Tool

Tra i tool più utilizzati si possono evidenziare l’Alticomposer dell’Alticast e il Cardinal Studio della Cardinal Information Systems; quest’ultimo è stato il software utilizzato al CRIT RAI per la realizzazione dell’interfaccia domestica su STB.

6.2.1 Cardinal Studio Il Cardinal Studio è un software, conforme alle specifiche MHP 1.0.2, per la produzione di applicazioni iTV che, permettendo un’elevata velocità di sviluppo, consente di migliorare la produttività dei progetti. Ta-le programma può essere usato come un authoring tool ma un programma-tore esperto, con praticità nell’uso di Java Beans, può costruire nuovi componenti, facilmente integrabili con quelli esistenti, che estendono la funzionalità dello stesso. Si possono, ad esempio, creare bottoni o menù utilizzando templates pre-costruiti oppure utilizzare i propri template per creare un preciso “look and feel”. Tra le caratteristiche più interessanti offerte dal software si possono elencare: ü generatore di interfaccia utente con funzioni grafiche di alto e basso

livello ü timeline grafica per la temporizzazione degli eventi



ü anteprima della funzionalità mediante un emulatore ü architettura facilmente estensibile, modulare con le componenti

SDK di Java ü palette di colori compatibile con MHP ü supporto di i-frame ü ottimizzatore del codice (migliora la funzionalità senza aumentare

la dimensione dell’applicazione) ü debug console ü immagini editor e emulatore.

6.3 Creazione dell’applicazione – Xlet Utilizzando il software precedentemente descritto si è proceduto al trasferimento dell’interfaccia (la cui realizzazione su pc è stata descritta nei capitoli 4 e 5) all’interno di una Xlet; il Cardinal compila l’applicazione nella directory di Deploy contenente la classe principale, la Xlet e tutte le altre classi dell’applicazione (comprese le classi di libreria). Oltre la directory di Deploy è generata un’altra directory, Source, al cui in-terno sono situati tutti i file sorgenti generati dal Cardinal Studio. Il tool per descrivere differenti scene dell’applicazione utilizza la tecnica degli act, intesi come una videata statica di elementi o come un’animazione che cambia aspetto con il variare degli eventi; poiché l’interfaccia è caratterizzata da schermate differenti, per ognuna di esse si è dovuto creare un relativo act.

6.3.1 Descrizione degli act Di seguito sono mostrati i singoli act creati per l’applicazione con una breve descrizione degli stessi.

6.3.1.1 Application – Master Act Tutto quello che viene inserito in questo atto si propagherà in tutti gli atti dell’applicazione. E’ stato inserito un controllore dell’applicazione che insieme all’uso del componente telecomando permette la distruzione della Xlet tramite la pressione del tasto blu che invoca il metodo Destro-



yApplication del controllore CsAppController1 (non si è potuto utilizzare il tasto exit del telecomando per la distruzione dell’applicazione, come nelle applicazioni RAI, poiché nel componente telecomando del Cardinal Studio non sono supportati tutti i pulsanti). Si è creato un background co-mune per tutti gli atti per evitare problemi di rallentamento nel caricamen-to dell’applicazione; sono presenti un video frame, due label e un pannello con la proprietà di essere invisibili ma che verranno resi visibili a secondo dell’atto caricato.

Figura 6.1. Master Act

6.3.1.2 Act 1 (Immagine televisiva con piccola finestra di comunicazione)

In questo atto si è resa visibile la label nella parte bassa dello schermo, dove compare il messaggio “PREMERE IL TASTO ROSSO PER LA GESTIONE DELLA CASA”, la cui visibilità è stata temporizza-ta in modo tale da non comparire sempre sull’immagine televisiva per non



creare fastidio all’utente, lasciando sempre attiva l’applicazione; questa label, funzionante come finestra di comunicazione della casa, riapparireb-be nel caso l’impianto domotico avesse qualcosa da comunicare all’utente, ad esempio allarme, arrivo di una telefonata, ecc..

Figura 6.2. Act 1 La temporizzazione della label è stata una scelta progettuale diversa da quella inizialmente ipotizzata e descritta nei capitoli precedenti, si è a-dottato questo tipo di politica per rimanere conformi con quelle che sono le applicazioni MHP presenti sul mercato (i messaggi su video rimangono nelle maggior parte dei casi visibili solo per alcuni secondi, per comunica-re una informazione senza disturbare più di tanto i programmi). Si è associata la pressione del tasto rosso del telecomando al pas-saggio all’atto successivo (act 2).



6.3.1.3 Act 2 (Menù principale)

Figura 6.3. Act 2

Sono stati resi visibili tutti gli oggetti ereditati dal master act, sono stati aggiunti sei pulsanti di testo che possono essere selezionati mediante la combinazione dell’uso dei tasti freccia e ok del telecomando, che per-metteranno l’accesso all’act relativo all’ambiente scelto; operazione possi-bile grazie anche all’impiego dei tasti numerici del telecomando. Nella la-bel in basso il testo è stato cambiato, avvertendo l’utente che per tornare alla pagina iniziale sarà sufficiente la pressione del tasto verde del teleco-mando.



6.3.1.4 Act 3 (Cucina)

Figura 6.4. Act 3

Questo atto permette l’accesso diretto ai dispositivi dell’impianto domotico all’ambiente Cucina; rispetto al precedente sono stati associati, alla selezione del pulsante di testo o l’uso della tastiera numerica del tele-comando, gli operatori logici CsIfx che provvedono, in conseguenza ad un comando, al cambio dello stato del dispositivo e perciò al cambio dell’icona relativa e del comando da inviare all’impianto. Da questo act in poi è disponibile l’opzione che permette il ritorno dell’applicazione all’act 1 relativo al menù principale.



6.3.1.5 Act 4 (Bagno) – Act 5 (Camera) Act 6 (Ripostiglio) – Act 7 (Altro)

Figura 6.5. Act 4

Figura 6.6. Act 5



Figura 6.7. Act 6

Figura 6.8. Act 7

Le caratteristiche di questi act sono identiche a quelle dell’act 2 re-lativo a Cucina.



6.3.1.6 Act 8 (Scenari)

Figura 6.9. Act 8

A differenza degli act precedenti non si ha cambiamento dell’icona e dello stato in quanto si selezionano solo gli scenari disponibili.

6.3.1.7 Visualizzazione dell’applicazione mediante emulatore

Dopo aver realizzato i vari act mediante il Cardinal Studio, il primo passo per verificare il risultato è stato simulare l’applicazione per mezzo dell’emulatore presente nel tool, il quale mette a disposizione una simula-zione dello schermo televisivo e del telecomando utilizzabile per far evol-vere nei suoi diversi stati l’applicazione interattiva. Di seguito sono mo-strati alcuni passi dell’emulazione della Xlet.



Figura 6.10. Emulazione- prima schermata

Figura 6.11. Emulazione- seconda schermata



Figura 6.12. Emulazione- terza schermata

Figura 6.13. Emulazione- settima schermata



6.4 Problemi riscontrati e risolti Durante il progetto dell’interfaccia sono sorti inconvenienti legati strettamente alle restrizioni date dall’MHP e dai vincoli conseguenti dalla visualizzazione su un semplice schermo televisivo (una applicazione deve essere visibile su qualunque televisore, anche non di ultima generazione). La restrizione più comune è quella legata alla memoria disponibile sul STB, infatti questo dato può variare da un minimo di 1 MB a parecchie centinaia. Dato che la maggior parte della memoria è usata nell’ambito della grafica o delle animazioni, si è evitato un uso smodato di immagini importate preferendo l’uso di pannelli e altri componenti base, in merito al fatto che essi utilizzano una frazione di memoria trascurabile rispetto a quella impegnata dalle immagini. Talvolta, immagini di grosse dimensioni potrebbero causare un arresto o un crash nei STB di basso profilo in con-seguenza a overflow o a perdite di memoria. Altri problemi incontrati sono quelli riguardanti le proprietà dello schermo, le quali includono la risoluzione, la gestione del colore e il re-fresh rate. Per quel che riguarda la risoluzione si è dovuto far attenzione alla scelta dei colori e dei font utilizzati per trovare un compromesso tra la qualità dei dettagli, da una parte, la bassa risoluzione e l’interlacing dello schermo televisivo, dall’altra. Il sistema del colore della TV (PAL) impone altre restrizioni, come quella di evitare valori RGB estremi utilizzando un’attenuazione di circa il 10%. Si è evitato di usare il colore bianco, specialmente puro, come colore degli sfondi per eludere problemi d’inarcamento dell’immagine o possibili effetti di macchie sullo schermo. Altra soluzione adottata è stata quella di non usare colori molto saturi (cioè con livello di saturazione oltre l’80%) usufruendo dell’opzione TV safe del Cardinal Studio, che provvede a so-stituire i colori con un set di colori a saturazione attenuata; questa caratte-ristica del tool, però, non garantisce un identico colore sul televisore e si è direttamente provveduto ad effettuare numerosi test del risultato ottenuto. Per avere una buona leggibilità dei testi e una buona risoluzione, è stato escluso l’impiego del rosso brillante e come colori dei caratteri sono stati scelti il giallo, il bianco e il nero, come colore degli sfondi il grigio, il nero ed il blu. Il font utilizzato, l’unico realmente supportato dall’MHP, è stato il Tiresias con dimensione, principalmente, di 24 pixel.



Normalmente la dimensione dello schermo PAL è 720x576, appros-simativamente 40÷50 pixel per ogni lato sono “mangiati” dalla televisione, perciò l’area utilizzata per il progetto è stata all’incirca 620x450, ai quali è stato scelto di aggiungere uno scarto addizionale di 10÷20 pixel per risol-vere il problema che alcuni set-top box tagliano, in base al loro middlewa-re, una parte dell’applicazione.

6.5 Trasmissione dell’applicazione su STB Al termine della realizzazione dell’applicazione sull’authoring tool della Cardinal si è provveduto alla trasferimento della stessa su tre STB, mediante sistema di trasmissione locale (il cui schema di principio è pre-sentato in Fig. 6.14) presente presso il Centro Ricerche della RAI (si asso-ciava l’applicazione al segnale relativo al canale televisivo RaiUno), per verificare e valutare le diverse funzionalità su diversi decoder presenti, at-tualmente, sul mercato. I ricevitori utilizzati per il test sono stati: ü Access Media IT.BOX ü Humax DTT 4000 ü Philips DTR 6600

A partire dalla figura 6.15, vengono riportate in sequenza le scher-mate principali della simulazione dell’applicazione sul televisore mediante l’utilizzo del STB Humax.

Figura 6.14. Caricamento dell’applicazione su STB



Figura 6.15. Avvio applicazione

Figura 6.16. Menù ottenuto alla pressione del tasto rosso del telecomando – è possibile

selezionare tutti gli ambienti della casa



Utilizzando i tasti freccia in combinazione con il tasto OK del tele-comando si seleziona CUCINA (l’ambiente scelto viene evidenziato in giallo) e si chiede lo spegnimento delle LUCI mediante la pressione del ta-sto 1 che viene confermato dal messaggio “COMANDO SU LUCI ESE-GUITO” nella finestra di dialogo sotto l’immagine televisiva.

Figura 6.17. Menù cucina

Figura 6.18. Menù bagno



Figura 6.19. Menù camera

Figura 6.20. Menù scenari

Alla pressione del tasto 1 (si attiva il primo scenario)

Alla pressione del tasto verde si ritorna alla situazione descritta in

Figura 6.15.



6.5.1 STB - prestazioni Nel corso della sperimentazione si è riscontrato che STB diversi si comportano, al momento di far girare l’applicazione, in modo diverso; il che è in contrasto con la linea guida dello standard mhp la quale insiste af-finché, per la portabilità dello stesso, la stessa applicazione deve produrre identici risultati su STB diversi. Nel caso specifico: ü STB Media Access: data la ristretta palette di colori supportata dal

ricevitore si è riscontrato un leggero peggioramento della qualità grafica (ad esempio, le sfumature colorate dei bottoni di testo ven-gono trasformate in un unico colore).

ü STB Humax: non viene supportato adeguatamente l’utilizzo dei tasti numerici del telecomando nell’esecuzione dell’applicazione (in alcuni casi la selezione del comando tramite tasto numerico viene totalmente ignorata).

ü STB Philips: non si sono avuti particolari problemi durante l’esecuzione dell’applicazione.

In generale, su tutti i STB è stato riscontrato un rallentamento, inde-siderato, durante il caricamento di act successivi (nel passaggio da una schermata all’altra passa un tempo di circa 1 secondo, ritardo percepibile all’occhio umano); una possibile soluzione a tale problema potrebbe tro-varsi nell’utilizzo di un i-frame, piuttosto che dei pannelli, nella realizza-zione dello sfondo dell’applicazione.

Capitolo 7

Valutazioni tecniche e considerazioni 7.1 Realizzazione dell’applicazione e trasferimento su STB

Nell’ambito del lavoro svolto sono stati incontrati ostacoli di varia natura riguardanti la realizzazione dell’applicazione MHP, ossia nell’implementare un prototipo completo che si occupi della produzione di tale applicazione in tutte le sue fasi.

In particolare si è avuta enorme difficoltà nel riuscire a reperire STB programmabili, dove poter effettuare attività di sviluppo e di ricerca, in quanto tali ricevitori non sono facilmente accessibili sul mercato.

Attualmente sono disponibili diversi tool per lo sviluppo di applica-zioni MHP che purtroppo presentano due inconvenienti, non irrilevanti ai

Cap. 7 - Valutazioni tecniche e considerazioni


fini della ricerca; uno riguarda la limitata libertà di scelta in ambito proget-tuale, l’altro legato ai costi eccessivi del software. Tutto ciò induce gli svi-luppatori a creare l’applicazione mediante la classica stesura del codice (effettuata in ogni caso su piattaforma Java TV).

Dopo aver realizzato la Xlet relativa all’applicazione e avendo a di-sposizione un STB commerciale (quindi non programmabile), per poter eseguire il trasferimento di tale applicazione sul ricevitore è necessario di-sporre di un apparato hardware - software (ossia di un sistema di playout + modulatore); il lato negativo di tutto ciò consiste nei prezzi che si raggiun-gono per assemblare tale apparato (dell’ordine delle decine di migliaia di euro).

7.2 Connessione STB – impianto domotico

L’effettiva realizzazione del progetto, con i dispositivi attualmente sul mercato, risulta impraticabile in quanto insorgono problemi riguardanti la compatibilità tra web-server BTicino e ricevitore digitale terrestre nell’ambito della comunicazione tra gli stessi.

Per la realizzazione del progetto in esame si è fatto uso del web-server modello F451V, in cui l’accesso, per instaurare una connessione, è consentito unicamente tramite una porta Ethernet; i STB presenti sul mer-cato dispongono, invece, per lo sfruttamento del canale di ritorno in merito di interattività, di un modem analogico V.90.

Una comunicazione tra due dispositivi di questo tipo non può avve-nire se non tramite l’adozione di alcune modifiche, quali, per esempio, l’inserimento di un router tra i due sistemi.

Una soluzione alternativa potrebbe consistere nell’impiego di un modello più evoluto di web-server (mod. MHSERVER), il quale offre l’accesso, oltre che da LAN, anche da linea telefonica in quanto dotato di modem interno per l’accesso remoto.

Di conseguenza è possibile stabilire una connessione con un gate-way di questo tipo mediante un collegamento punto-punto o tramite acces-so remoto da internet (con modem/router ADSL).

Purtroppo le soluzioni proposte comportano svantaggi non indiffe-renti nei confronti degli utenti quali i costi aggiuntivi (dovuti sia alla con-nessione che al reperimento di ulteriori dispositivi) e all’aumento dei tem-pi di ritardo dovuti al tipo di connessione adottata.

Cap. 7 - Valutazioni tecniche e considerazioni


La soluzione più conveniente risulta essere, senz’ombra di dubbio, l’uso di decoder digitali dotati di scheda di rete Ethernet (già prevista nelle versioni future di ricevitori) che permetterebbe la connessione diretta tra i due sistemi presi in esame senza introdurre costi aggiuntivi e ottimizzando la velocità di comunicazione.

7.3 Configurazione dell’applicazione In fase di simulazione dell’applicazione su PC la configurazione

della stessa è stata gestita mediante scansione di un file di testo. Si pone il problema di come poter gestire tale file di configurazione

qualora l’applicazione venga eseguita su STB; è necessario che il file di configurazione sia memorizzato in maniera permanente sul ricevitore, per esempio nel caso in cui questa venga scaricata da un object carousel, per non dover effettuare la procedura ogniqualvolta l’applicazione venga di-strutta e successivamente riscaricata.

Suggerimenti adottabili per questo tipo di problema potrebbero es-sere l’impiego di decoder digitali che permettano l’utilizzo di porte seriali o di lettori di smart card.

Nel primo caso il tecnico, in fase di installazione, potrebbe, tramite porta seriale, memorizzare in maniera permanente il file di personalizza-zione sul ricevitore mediante software appositi; mentre nel secondo, utiliz-zando la smart card come unità di memoria rimovibile, si potrebbe fare in modo che l’applicazione, ogniqualvolta venga eseguita sul STB, legga il file di configurazione direttamente da essa. In quest’ultimo caso sarebbe possibile usufruire dei servizi domotici offerti dalla propria casa da qual-siasi posto ci si trovi solo mediante l’utilizzo di un qualunque ricevitore digitale.

Tutte le soluzioni proposte potrebbero non essere realizzabili sui STB attualmente disponibili sul mercato; se così fosse potrebbero essere un’idea per implementazioni future dei ricevitori.

Conclusioni Il progetto sin qui descritto ha condotto a risultati soddisfacenti in termini di rispetto degli obiettivi prefissati; per quel che riguarda il trasfe-rimento dell’applicazione su decoder digitale, effettuato presso il CRIT RAI, non è stato possibile implementare un collegamento tra l’applicazione caricata sul ricevitore e il web-server dell’impianto domoti-co, situato presso il CETAD. Il motivo di ciò sta nel fatto che il web-server dell’impianto non è fornito di un indirizzo IP pubblico statico e di conse-guenza è accessibile solo all’interno della rete locale alla quale è collegato. Poiché le classi relative alla comunicazione dell’applicazione con il web-server, illustrate nel Capitolo 5, sono trasportabili all’interno dell’Xlet realizzata mediante tool di authoring, nulla vieta di affermare che è plausi-bile implementare anche quest’ultima fase di progetto. Per ovviare al pro-blema della comunicazione diretta con l’impianto domotico, è possibile pensare di simularne il funzionamento per mezzo di una macchina in gra-do di espletare tutte le funzionalità del web-server; così facendo si può rea-lizzare una connessione identica a quella fin qui solo ipotizzata permetten-do di effettuare l’analisi del comportamento dell’applicazione derivante dall’integrazione dei due sistemi. A causa del livello medio/basso del-

Conclusioni


l’hardware costituente i decoder digitali attualmente presenti sul mercato, sarebbe opportuno, per esempio, eseguire un esame dei tempi di ritardo generati in fase di invio/ricezione dei comandi verso/da web-server e valu-tarne le conseguenze sulle effettive prestazioni del sistema e sul suo cor-retto funzionamento. In seguito alle esperienze maturate nel corso della realizzazione del progetto e grazie ai riscontri avuti nelle prove dell’applicazione da parte di un campione di utenti (disabili e non), è possibile affermare il principio che è alla base di una realizzazione di questo tipo è ragionevole; l’idea di fornire uno strumento per la gestione di un impianto domotico, basato sull’utilizzo della piattaforma televisiva potrebbe offrire vantaggi reali, in ambito di semplificazione della vita nell’ambiente domestico.

Appendice

Codice dell’applicazione descritta nei capitoli 4 e 5

Appendice

Politecnico di Torino A. 2

Casa.java

import java.awt.*; import java.awt.event.*; import java.awt.image.*; import java.util.*; import java.lang.*; public class Casa { public static void main(String[] args) { Casa_client client=new Casa_client(); Video window; Control remot_contr; Dimension dim; Dimension dim2; window = new Video("Digital TV"); window.setLocation(0,0); window.setSize(680,720); window.setVisible(true); GestoreWindow_TV nn = new GestoreWindow_TV(window); window.addWindowListener(nn); window.addComponentListener(nn); remot_contr = new Control("REMOTE CONTROL",window,client); remot_contr.setLocation(750,50); remot_contr.setSize(220,650); remot_contr.setResizable(false); remot_contr.setVisible(true); GestoreWindow bh = new GestoreWindow(remot_contr); remot_contr.addWindowListener(bh); dim=window.getSize(); System.out.println("---- * DOMO-Home 2004 * ver. 2.0.3 ----"); System.out.println("\ndimensioni Televisore "+dim.width+"-"

+dim.height); dim=window.imagePanel.getSize(); System.out.println("dimensioni schermo "+dim.width+"-"

+dim.height); System.out.println("-----------------------------"); window.imagePanel_nord.load("icone/image1.bmp"); window.imagePanel_sud.load("icone/image4.bmp"); window.imagePanel.load_fix("icone/pippo.bmp"); int i=0; for (i=0;i<window.descr_vet[0].size+1;i++) { System.out.print(window.ambienti[i].descr.title+" "); System.out.println(window.ambienti[i].descr.size); } System.out.println("-----------------------------");

Appendice


client.connect(); client.thread1=new Alert(" §§§§§§ ",3,client,window); client.thread1.me.start(); } }

Appendice


Control.java import java.awt.*; import java.awt.event.*; import java.util.*; import java.lang.*; class Control extends Frame { Panel PannelloNord;

Panel PannelloCentrale; Panel PannelloSud; Panel PannelloColori; Panel PannelloArea; Gestore_action_start Gest_START; Gestore_action_stanza Gest_STANZA; Gestore_action_ambienti[] Gest_AMBIENTI; Control_obj tasto1; Control_obj tasto2; Control_obj tasto3; Control_obj tasto4; Control_obj tasto5; Control_obj tasto6; Control_obj tasto7; Control_obj tasto8; Control_obj tasto9; Control_obj tasto0; Control_obj tastoOFF; Control_obj MENU; Control_obj UP; Control_obj LEFT; Control_obj OK; Control_obj RIGHT; Control_obj DOWN; Control_obj ROSSO; Control_obj GREEN; Control_obj BLU ; Control_obj YELLOW; TextArea report; Control(String title,Video window,Casa_client client)

{ super(title); report=new TextArea(1,1);

Gest_START=new Gestore_action_start(this,window,report,client); Gest_STANZA=new Gestore_action_stanza

(this,window,window.ambienti[0],report,client); int i;

Gest_AMBIENTI=new Gestore_action_ambienti[window.descr_vet[0].size+1];

for (i=0;i<window.descr_vet[0].size+1;i++)

Appendice


{ Gest_AMBIENTI[i]=new Gestore_action_ambienti

(this,window,window.ambienti[i+1],report,client); }

this.setLayout(new BorderLayout()); this.setBackground(Color.black); this.setForeground(Color.black);

PannelloNord=new Panel(); PannelloNord.setLayout(new BorderLayout());

Panel PannelloNord_nord=new Panel(); PannelloNord_nord.setBackground(Color.black);

PannelloNord_nord.setLayout(new GridLayout(1,4)); Label titolo=new Label();

titolo.setFont(new Font("TimesRoman",Font.BOLD,10)); titolo.setForeground(Color.yellow);

titolo.setBackground(Color.gray); titolo.setText("TELECOMANDO MHP"); titolo.setAlignment(titolo.CENTER);

Control_obj empty5=new Control_obj(PannelloNord_nord); Control_obj empty6=new Control_obj(PannelloNord_nord);

tastoOFF=new Control_obj

("OFF",PannelloNord_nord,this,Color.black); Panel PannelloNord_centrale=new Panel();

PannelloNord_centrale.setBackground(Color.black); PannelloNord_centrale.setLayout(new GridLayout(5,4,4,4));

tasto1=new Control_obj

("1",PannelloNord_centrale,this,Color.darkGray); tasto2=new Control_obj








("9",PannelloNord_centrale,this,Color.darkGray); Control_obj empty=new Control_obj(PannelloNord_centrale); tasto0=new Control_obj

("0",PannelloNord_centrale,this,Color.darkGray);

Appendice


Control_obj empty0=new Control_obj(PannelloNord_centrale); Control_obj empty15=new Control_obj(PannelloNord_centrale);

MENU=new Control_obj

("MENU",PannelloNord_centrale,this,Color.lightGray); Control_obj empty16=new Control_obj(PannelloNord_centrale);

Panel PannelloNord_sud=new Panel(); PannelloNord_sud.setBackground(Color.black);

Panel PannelloNord_est=new Panel(); PannelloNord_est.setBackground(Color.black);

Panel PannelloNord_ovest=new Panel();

PannelloNord_ovest.setBackground(Color.black); PannelloCentrale=new Panel(); PannelloCentrale.setBackground(Color.black); PannelloCentrale.setLayout(new GridLayout(3,3,2,2)); Control_obj empty1=new Control_obj(PannelloCentrale); Control_obj empty2=new Control_obj(PannelloCentrale); Control_obj empty3=new Control_obj(PannelloCentrale); Control_obj empty4=new Control_obj(PannelloCentrale);

UP=new Control_obj("UP",PannelloCentrale,this,Color.gray);

LEFT=new Control_obj("LEFT",PannelloCentrale,this,Color.gray); OK=new Control_obj("OK",PannelloCentrale,this,Color.gray); RIGHT=new Control_obj

("RIGHT",PannelloCentrale,this,Color.gray); DOWN=new Control_obj("DOWN",PannelloCentrale,this,Color.gray); PannelloSud=new Panel(); PannelloSud.setLayout(new BorderLayout()); PannelloColori=new Panel(); PannelloColori.setLayout(new GridLayout(2,4)); PannelloArea=new Panel(); PannelloArea.setLayout(new GridLayout(1,1)); Control_obj empty10=new Control_obj(PannelloColori); Control_obj empty11=new Control_obj(PannelloColori); Control_obj empty12=new Control_obj(PannelloColori); Control_obj empty13=new Control_obj(PannelloColori); ROSSO =new Control_obj("R",PannelloColori,this,Color.red); GREEN =new Control_obj("V",PannelloColori,this,Color.green); BLU =new Control_obj("B",PannelloColori,this,Color.blue); YELLOW =new Control_obj("G",PannelloColori,this,Color.yellow); report.setEditable(true); report.setForeground(Color.black);

Appendice


report.setBackground(Color.black); report.setVisible(true); PannelloArea.add(report); PannelloSud.add("Center",PannelloColori); PannelloSud.add("South",PannelloArea); PannelloNord.add("North",PannelloNord_nord); PannelloNord.add("Center",PannelloNord_centrale); PannelloNord.add("South",PannelloNord_sud); PannelloNord.add("East",PannelloNord_est); PannelloNord.add("West",PannelloNord_ovest); this.add("North",PannelloNord); this.add("Center",PannelloCentrale); this.add("South",PannelloSud); this.validate(); Gest_START.Set_listener(Gest_START,Gest_START); } public Insets getInsets() { return new Insets(30,10,50,10); } }

Appendice


Video.java import java.awt.*; import java.awt.event.*; import java.util.*; import java.lang.*; class Video extends Frame

{ Description[] descr_vet; Video_room[] ambienti; int i=0;

Panel PannelloNord;

Panel PannelloSud; Panel PannelloEst; Panel PannelloOvest;

Panel PannelloCentrale; Panel grigliaUP; Panel grigliaEST;

Panel grigliaDOWN; Panel grigliaCARD;

Panel griglia1; Panel griglia2; Panel griglia3;

Panel griglia4; ImagePanel imagePanel;

ImagePanel imagePanel_sud; ImagePanel imagePanel_nord; ImagePanel imagePanel_est; ImagePanel imagePanel_ovest; CardLayout PAGINA; Video_room INIZIALE; Video_room ALTRO; Video_obj messageACT; CardLayout PAGINA_DOWN; Video(String title)

{ super(title); this.setLayout(new BorderLayout());

this.setBackground(Color.gray); this.setForeground(Color.black);

Scan pippo=new Scan(); String[] vett=pippo.ret_vet();

descr_vet=new Description[10];

int[] n_opt=new int[10]; String[] titoli=new String[10];

int i=0;

Appendice


int j=0; int z=0; char[] word; char c;

for(i=0;i<vett.length;i++) { word=vett[i].toCharArray();

if (vett[i].compareTo("*MENU")==0) { descr_vet[j]=new Description(); descr_vet[j].title=vett[i++]; Integer dim=new Integer(vett[i++]); descr_vet[j].size=dim.intValue(); Integer r=new Integer(vett[i++]); Integer g=new Integer(vett[i++]);

Integer b=new Integer(vett[i++]); descr_vet[j].colore=new

Color(r.intValue(),g.intValue(),b.intValue());

for(z=0;z<descr_vet[j].size;z++) {

descr_vet[j].opt[z]=vett[i++]; }

for(z=0;z<descr_vet[j].size;z++)

{ r=new Integer(vett[i++]);

g=new Integer(vett[i++]); b=new Integer(vett[i++]); descr_vet[j].col_vett[z]=new

Color(r.intValue(),g.intValue(),b.intValue()); } j++;

i--; }

word=vett[i].toCharArray();

if (word[0]=='*') { descr_vet[j]=new Description(); descr_vet[j].title=vett[i++]; Integer dim=new Integer(vett[i++]); descr_vet[j].size=dim.intValue(); Integer r=new Integer(vett[i++]); Integer g=new Integer(vett[i++]); Integer b=new Integer(vett[i++]); descr_vet[j].colore=new

Color(r.intValue(),g.intValue(),b.intValue());

for(z=0;z<descr_vet[j].size;z++) { descr_vet[j].opt[z]=vett[i++]; }

Appendice


for(z=0;z<descr_vet[j].size;z++) { descr_vet[j].chi[z]=vett[i++]; } for(z=0;z<descr_vet[j].size;z++)

{ descr_vet[j].dove[z]=vett[i++];

}

for(z=0;z<descr_vet[j].size;z++) {

descr_vet[j].ico_on[z]=vett[i++]; } for(z=0;z<descr_vet[j].size;z++) { descr_vet[j].ico_off[z]=vett[i++]; } j++; i--; }

}

PannelloCentrale=new Panel(); PannelloCentrale.setBackground(Color.black);

PannelloCentrale.setLayout(new BorderLayout()); grigliaUP=new Panel();

grigliaUP.setLayout(new FlowLayout()); grigliaUP.setBackground(Color.black);

Video_obj titolo1=new Video_obj(grigliaUP,"GESTIONE CASA",Color.white,Color.red,Color.blue,20);

Video_obj titolo2=new Video_obj(grigliaUP,"Politecnico di Torino",Color.yellow,Color.darkGray,Color.blue,18);

Video_obj titolo3=new Video_obj (grigliaUP,"CETAD",Color.yellow,Color.darkGray,Color.blue,18);

Video_obj titolo4=new Video_obj(grigliaUP, "BTicino",Color.yellow,Color.darkGray,Color.blue,18);

Video_obj titolo5=new Video_obj(grigliaUP, "RAI",Color.yellow,Color.darkGray,Color.blue,18);

grigliaEST=new Panel(); grigliaEST.setBackground(Color.darkGray);

grigliaEST.setLayout(new BorderLayout()); PAGINA=new CardLayout(); grigliaCARD=new Panel();

grigliaCARD.setLayout(PAGINA); grigliaCARD.setBackground(Color.darkGray);

griglia1=new Panel(); griglia1.setBackground(Color.darkGray);

Appendice


griglia2=new Panel(); griglia2.setBackground(Color.darkGray); griglia3=new Panel(); griglia3.setBackground(Color.darkGray); griglia4=new Panel(); griglia4.setBackground(Color.darkGray);

ambienti=new Video_room[descr_vet[0].size+2]; for (i=0;i<descr_vet[0].size+2;i++)

{ ambienti[i]=new Video_room (grigliaCARD,descr_vet[i]); } grigliaEST.add("Center",grigliaCARD);

grigliaEST.add("North",griglia1); grigliaEST.add("East",griglia2); grigliaEST.add("West",griglia3); grigliaEST.add("South",griglia4); imagePanel = new ImagePanel();

this.PannelloCentrale.add("Center",imagePanel); PAGINA_DOWN=new CardLayout();

grigliaDOWN=new Panel(); grigliaDOWN.setLayout(PAGINA_DOWN); grigliaDOWN.setBackground(Color.black); Panel grigliaDOWN_RED=new Panel(); grigliaDOWN_RED.setLayout(new FlowLayout()); Video_obj message=new Video_obj(grigliaDOWN_RED,"PREMERE IL

TASTO ",Color.yellow,Color.black,20); Video_obj simbolo=new Video_obj(grigliaDOWN_RED,"XX",Color.red,Color.red,15); Video_obj message2=new Video_obj(grigliaDOWN_RED,

"PER GESTIRE LA CASA",Color.yellow,Color.black,20); Panel grigliaDOWN_GREEN=new Panel();

grigliaDOWN_GREEN.setLayout(new GridLayout(2,1)); messageACT=new Video_obj(grigliaDOWN_GREEN,"in attesa di

comando...",Color.white,Color.black,18); Panel grigliaX=new Panel(new FlowLayout()); Video_obj message3=new Video_obj(grigliaX,"PREMERE IL TASTO ",

Color.yellow,Color.black,20); Video_obj simbolo2=new Video_obj(grigliaX,"XX",Color.green,Color.green,15);

Video_obj message4=new Video_obj(grigliaX," PER USCIRE DALLA GESTIONE CASA",Color.yellow,Color.black,20);

grigliaDOWN_GREEN.add(grigliaX); grigliaDOWN.add(grigliaDOWN_RED,"APRI"); grigliaDOWN.add(grigliaDOWN_GREEN,"CHIUDI"); this.PannelloCentrale.add("South",grigliaDOWN);

PannelloNord=new Panel(); PannelloNord.setBackground(Color.black);

PannelloNord.setLayout(new GridLayout(1,1)); imagePanel_nord= new ImagePanel();

this.PannelloNord.add(imagePanel_nord); PannelloEst=new Panel();

Appendice


PannelloEst.setBackground(Color.black); PannelloEst.setLayout(new GridLayout(1,1));

imagePanel_est= new ImagePanel(); this.PannelloEst.add(imagePanel_est); PannelloOvest=new Panel();

PannelloOvest.setBackground(Color.black); PannelloOvest.setLayout(new GridLayout(1,1));

imagePanel_ovest= new ImagePanel(); this.PannelloOvest.add(imagePanel_ovest);

PannelloSud=new Panel(); PannelloSud.setLayout(new GridLayout(1,1)); PannelloSud.setBackground(Color.black);

imagePanel_sud= new ImagePanel(); this.PannelloSud.add(imagePanel_sud); this.add("Center",this.PannelloCentrale);

this.add("North",this.PannelloNord); this.add("South",this.PannelloSud);

this.validate(); } public Insets getInsets() { return new Insets(25,10,10,10);

} }

Appendice


Scan.java import java.net.*; import java.io.*; import java.awt.*; import java.awt.event.*; import java.awt.image.*; import java.util.*; import java.lang.*; class Scan { String[] vett;

Scan()

{ FileInputStream base=null; String filename="doc.txt"; try

{ base=new FileInputStream(filename);

} catch(Exception e) { System.out.println("errore in apertura di file\n" + e); } int i=0; int j=0; String[] vett2=new String[800]; boolean flag=true; while (flag==true) { vett2[i]=acq_word(base); if ((vett2[i].compareTo("eof"))==0) break; i++;

} vett=new String[i]; for(j=0;j<i;j++) vett[j]=vett2[j]; }

public static String acq_word(FileInputStream base) {

Appendice


int x=0; char car='x'; StringBuffer parola=new StringBuffer(); while (true) { try { x=base.read(); car=(char)x;

parola.append(car); }

catch(Exception e) { System.out.println("errore in lettura carattere\n"+ e); } if (car==' ') { parola.setLength(parola.length()-1);

return parola.toString(); }

if (car=='\n')

{ parola.setLength(parola.length()-2);

return parola.toString(); }

if (x==-1)

{ parola.setLength(parola.length()-1); return parola.toString(); } } } public String[] ret_vet() { return vett;

} }

Appendice


Description.java import java.util.*; import java.lang.*; import java.awt.*; public class Description { public String title;

public Color colore; public Color col_vett[]; public int size; public String[] opt; public String[] chi; public String[] dove; public String[] ico_on; public String[] ico_off; Description() { title=new String(); size=0; opt=new String[10]; chi=new String[10];

dove=new String[10]; ico_on=new String[10]; ico_off=new String[10];

col_vett=new Color[10]; } void set_title(String titolo)

{ title=titolo; }

}

Appendice


Gestore_action.java import java.awt.*; import java.awt.event.*; import java.util.*; import java.lang.*; class Gestore_action implements ActionListener,KeyListener { Video tvcolor; Video_room ambiente; Control comando; TextArea message; String stringa; Button Bott; Casa_client client; Gestore_action old_GEST; int i=-1;

Gestore_action (Control parent,Video window,TextArea

report,Casa_client cl) {

comando=parent; tvcolor=window;

message=report; client=cl; } Gestore_action (Control parent,Video window,Video_room corrente,

TextArea report,Gestore_action prev,Casa_client cl) { comando=parent; tvcolor=window; ambiente=corrente; message=report; old_GEST=prev; client=cl;

} Gestore_action (Control parent,Video window,Video_room corrente,

TextArea report,Casa_client cl) { comando=parent; tvcolor=window; ambiente=corrente; message=report; client=cl;

} public void Set_listener(Gestore_action corrente,

Appendice


Gestore_action nuovo) {

message.removeKeyListener(corrente); message.addKeyListener(nuovo);

comando.tasto1.BottoneX.removeActionListener(corrente); comando.tasto1.BottoneX.addActionListener(nuovo);

comando.tasto2.BottoneX.removeActionListener(corrente); comando.tasto2.BottoneX.addActionListener(nuovo);

comando.tasto3.BottoneX.removeActionListener(corrente); comando.tasto3.BottoneX.addActionListener(nuovo); comando.tasto4.BottoneX.removeActionListener(corrente); comando.tasto4.BottoneX.addActionListener(nuovo); comando.tasto5.BottoneX.removeActionListener(corrente); comando.tasto5.BottoneX.addActionListener(nuovo); comando.tasto6.BottoneX.removeActionListener(corrente); comando.tasto6.BottoneX.addActionListener(nuovo); comando.tasto7.BottoneX.removeActionListener(corrente); comando.tasto7.BottoneX.addActionListener(nuovo); comando.tasto8.BottoneX.removeActionListener(corrente); comando.tasto8.BottoneX.addActionListener(nuovo); comando.tasto9.BottoneX.removeActionListener(corrente); comando.tasto9.BottoneX.addActionListener(nuovo); comando.tasto0.BottoneX.removeActionListener(corrente); comando.tasto0.BottoneX.addActionListener(nuovo); comando.tastoOFF.BottoneX.addActionListener(corrente); comando.tastoOFF.BottoneX.addActionListener(nuovo); comando.MENU.BottoneX.removeActionListener(corrente); comando.MENU.BottoneX.addActionListener(nuovo); comando.UP.BottoneX.removeActionListener(corrente); comando.UP.BottoneX.addActionListener(nuovo); comando.LEFT.BottoneX.removeActionListener(corrente); comando.LEFT.BottoneX.addActionListener(nuovo); comando.OK.BottoneX.removeActionListener(corrente); comando.OK.BottoneX.addActionListener(nuovo); comando.RIGHT.BottoneX.removeActionListener(corrente); comando.RIGHT.BottoneX.addActionListener(nuovo); comando.DOWN.BottoneX.removeActionListener(corrente); comando.DOWN.BottoneX.addActionListener(nuovo); comando.ROSSO.BottoneX.removeActionListener(corrente); comando.ROSSO.BottoneX.addActionListener(nuovo); comando.GREEN.BottoneX.removeActionListener(corrente); comando.GREEN.BottoneX.addActionListener(nuovo); comando.BLU.BottoneX.removeActionListener(corrente);

comando.BLU.BottoneX.addActionListener(nuovo); comando.YELLOW.BottoneX.removeActionListener(corrente); comando.YELLOW.BottoneX.addActionListener(nuovo); }

public int light(String direction,int i)

{ if (ambiente!=null) { int j=0;

Appendice


int f=0;

if (direction.compareTo("up") == 0) { if (i==-1) i=0; ambiente.load[i].label.setBackground(Color.lightGray); ambiente.load[i].label.setForeground(Color.black); j=i-1;

if (j>0) { while (ambiente.load[j].label.getText().compareTo(" ")== 0) {

j--; i=j+1;

} } i--;

if((i<0)&&

(ambiente.load[9].label.getText().compareTo(" ") != 0)) i=9; else if(i!=9 && i<0)

i=8; ambiente.load[i].label.setBackground(Color.red); ambiente.load[i].label.setForeground(Color.white); } if (direction.compareTo("down") == 0) { if (i==-1) { ambiente.load[0].label.setBackground(Color.red); ambiente.load[0].label.setForeground(Color.white); i=0; } else { ambiente.load[i].label.setBackground(Color.lightGray); ambiente.load[i].label.setForeground(Color.black); j=i+1; if (j<10) { while (ambiente.load[j].label.getText().compareTo("")==0) {

j++; if (j==10) j=0; i=j-1;

} } i++; if (i>=10) i=0;

ambiente.load[i].label.setBackground(Color.red);

Appendice


ambiente.load[i].label.setForeground(Color.white); } } } return i; } public void select_light(int j)

{ ambiente.load[j].label.setBackground(Color.blue);

ambiente.load[j].label.setForeground(Color.white); return ; } public int de_light()

{ int j=0; if (ambiente!=null) { for (j=0;j<10 ;j++ ) { if (ambiente.load[j].label.getText().compareTo(" ") != 0) { ambiente.load[j].label.setBackground(Color.lightGray); ambiente.load[j].label.setForeground(Color.black);

} } } return i; } public void actionPerformed(ActionEvent e) { if (e.getSource() instanceof Button) {

Bott=(Button)e.getSource(); stringa=Bott.getLabel(); if (stringa.compareTo("UP") == 0) funzUP(); if (stringa.compareTo("LEFT") == 0) funzLEFT(); if (stringa.compareTo("OK") == 0) funzOK(); if (stringa.compareTo("RIGHT") == 0) funzRIGHT(); if (stringa.compareTo("DOWN") == 0) funzDOWN(); if (stringa.compareTo("1") == 0) funz1(); if (stringa.compareTo("2") == 0) funz2(); if (stringa.compareTo("3") == 0) funz3(); if (stringa.compareTo("4") == 0) funz4(); if (stringa.compareTo("5") == 0) funz5(); if (stringa.compareTo("6") == 0) funz6(); if (stringa.compareTo("7") == 0) funz7(); if (stringa.compareTo("8") == 0) funz8(); if (stringa.compareTo("9") == 0) funz9(); if (stringa.compareTo("0") == 0) funz0();

Appendice


if (stringa.compareTo("R") == 0) funzRED(); if (stringa.compareTo("V") == 0) funzGREEN(); if (stringa.compareTo("B") == 0) funzBLUE(); if (stringa.compareTo("G") == 0) funzYELLOW(); if (stringa.compareTo("OFF") == 0) funzOFF(); if (stringa.compareTo("MENU") == 0) funzMENU(); } }

public void keyTyped(KeyEvent e) { char c=e.getKeyChar(); message.append("evento tastiera "+e.getKeyChar()+"\n"); if (c=='1') funz1(); if (c=='2') funz2(); if (c=='3') funz3(); if (c=='4') funz4(); if (c=='5') funz5(); if (c=='6') funz6(); if (c=='7') funz7(); if (c=='8') funz8(); if (c=='9') funz9(); if (c=='0') funz0(); if (c=='\n') funzOK(); if (c=='*') funzOK(); if (c=='\'') funzOK(); if (c=='+') funzDOWN(); if (c=='-') funzUP(); if ((c=='R')||(c=='r')) funzRED(); if ((c=='B')||(c=='b')) funzBLUE(); if ((c=='V')||(c=='v')) funzGREEN(); if ((c=='G')||(c=='g')) funzYELLOW(); } public void keyPressed(KeyEvent e) { }

public void keyReleased(KeyEvent e) { }

public void funzUP() { i=light("up",i);

tvcolor.validate(); } public void funzDOWN()

{ i=light("down",i);

tvcolor.validate(); } public void funzLEFT() { } public void funzRIGHT() { }

public void funzOK()

Appendice


{ if (i==0) funz1(); if (i==1) funz2(); if (i==2) funz3();

if (i==3) funz4(); if (i==4) funz5(); if (i==5) funz6(); if (i==6) funz7(); if (i==7) funz8(); if (i==8) funz9(); if (i==9) funz0(); i=-1;

} public void funz1()

{ tvcolor.messageACT.SetLabel("Pressione tasto 1"); waiting();


{ tvcolor.messageACT.SetLabel("Pressione tasto 2"); waiting(); }

public void funz3()


public void funz4()


public void funz5()

{ tvcolor.messageACT.SetLabel("Pressione tasto 5"); waiting(); } public void funz6()

{ tvcolor.messageACT.SetLabel("Pressione tasto 6"); waiting(); } public void funz7()

{ tvcolor.messageACT.SetLabel("Pressione tasto 7");

Appendice


waiting(); }

public void funz8()


public void funz9()


public void funz0()

{ tvcolor.messageACT.SetLabel("Pressione tasto 0");

waiting(); }

public void funzRED()

{ tvcolor.messageACT.SetLabel("in attesa di comando..."); waiting(); }

public void funzGREEN()

{ tvcolor.messageACT.SetLabel("Pressione tasto VERDE"); waiting();

} public void funzBLUE()

{ tvcolor.messageACT.SetLabel("Pressione tasto BLU"); waiting(); } public void funzYELLOW()

{ tvcolor.messageACT.SetLabel("Pressione tasto GIALLO"); waiting();

} public void funzMENU()

{ tvcolor.messageACT.SetLabel("Pressione tasto MENU"); waiting(); } public void funzOFF()

{ tvcolor.messageACT.SetLabel("Pressione tasto OFF");

Appendice


System.exit(0); } public void waiting()

{ try

{ client.thread1.me.sleep(3000);

} catch(Exception e)

{ System.out.println(e);

} tvcolor.messageACT.SetLabel("in attesa di comando..."); } }

Appendice


Gestore_action_start.java import java.awt.*; import java.awt.Graphics; import java.awt.event.*; import java.util.*; import java.lang.*; class Gestore_action_start extends Gestore_action { int j; Gestore_action_start (Control parent,Video window,

TextArea report,Casa_client cl) { super(parent,window,report,cl); } public void funzRED() {

message.append("--- GESTIONE CASA ---\n"); message.append("------ WELCOME ------\n"); tvcolor.PannelloCentrale.add("North",tvcolor.grigliaUP); tvcolor.PannelloCentrale.add("East",tvcolor.grigliaEST); tvcolor.PAGINA.show(tvcolor.grigliaCARD,

tvcolor.descr_vet[0].title); tvcolor.PAGINA_DOWN.show(tvcolor.grigliaDOWN,"CHIUDI"); tvcolor.validate(); tvcolor.ambienti[0].load_ico(); tvcolor.imagePanel.load_fix("icone/pippo.bmp"); tvcolor.validate(); this.Set_listener(this,comando.Gest_STANZA); } }

Appendice


Gestore_action_stanza.java import java.awt.*; import java.awt.Graphics; import java.awt.event.*; import java.util.*; import java.lang.*; class Gestore_action_stanza extends Gestore_action { int j;

Gestore_action_stanza (Control parent,Video window,

Video_room corrente,TextArea report,Casa_client cl) { super(parent,window,corrente,report,cl); } public void act_funz(int pos)

{ tvcolor.PAGINA.show(tvcolor.grigliaCARD,

tvcolor.descr_vet[pos+2].title); de_light(); tvcolor.validate(); tvcolor.ambienti[pos+2].load_ico(); String s=new String("*#interrogazione"); client.thread1.set_comando(2,s,

comando.Gest_AMBIENTI[pos+1].ambiente,0,"0"); Set_listener(this,comando.Gest_AMBIENTI[pos+1]); } public void funz1()

{ if (tvcolor.descr_vet[0].size>=1) act_funz(0); else super.funz1(); } public void funz2() { if (tvcolor.descr_vet[0].size>=2)

act_funz(1); else super.funz2(); } public void funz3()

{ if (tvcolor.descr_vet[0].size>=3) act_funz(2); else super.funz3(); }

Appendice


public void funz4()

{ if (tvcolor.descr_vet[0].size>=4) act_funz(3); else super.funz4();




{ if (tvcolor.descr_vet[0].size>=6)

act_funz(5); else super.funz6(); } public void funz7()


} public void funz8() { if (tvcolor.descr_vet[0].size>=8)

act_funz(7); else super.funz8();

} public void funz0() { tvcolor.PAGINA.show(tvcolor.grigliaCARD,

tvcolor.descr_vet[1].title); de_light();

tvcolor.validate(); tvcolor.ambienti[1].load_ico(); String s=new String("*#interrogazione");

client.thread1.set_comando(2,s, comando.Gest_AMBIENTI[0].ambiente,0,"0");

Set_listener(this,comando.Gest_AMBIENTI[0]); } public void funzBLUE()

{ funz0();

Appendice


} public void funzGREEN() { tvcolor.PannelloCentrale.remove(tvcolor.grigliaUP);

tvcolor.PannelloCentrale.remove(tvcolor.grigliaEST); tvcolor.PAGINA_DOWN.show(tvcolor.grigliaDOWN,"APRI"); de_light(); tvcolor.validate(); tvcolor.imagePanel.load_fix("icone/pippo.bmp"); String s=new String(" §§§§§§ "); client.thread1.set_comando(2,s,

comando.Gest_START.ambiente,0,"0"); Set_listener(this,comando.Gest_START); } }

Appendice


Gestore_action_ambienti.java import java.awt.*; import java.awt.Graphics; import java.awt.event.*; import java.util.*; import java.lang.*; class Gestore_action_ambienti extends Gestore_action { int flag; Gestore_tapparelle tapp; Gestore_action_ambienti (Control parent,Video window,

Video_room corrente,TextArea report,Casa_client cl) { super(parent,window,corrente,report,cl);

tapp=new Gestore_tapparelle(comando,tvcolor,ambiente,message, this,client);

} public void action_funz(int pos)

{ String str=new String(); String act=new String(); boolean stato=ambiente.state[pos]; if (stato==true) act="0"; if (stato==false) act="1"; Integer k=new Integer(pos+1); char[] flag; if (ambiente.descr.chi[pos].compareTo("2")==0) { de_light(); tapp.posizione=pos; select_light(pos); tvcolor.messageACT.SetLabel(("PER "+

ambiente.descr.opt[pos]).toUpperCase()+" UTILIZZARE I CURSORI"); Set_listener(this,this.tapp); } if (ambiente.descr.chi[pos].compareTo("0")==0) { String s=new String

("*0*"+k.toString()+"*"+ambiente.descr.dove[pos]+"##"); client.thread1.set_comando(2,s,ambiente,pos,act); de_light(); } if (ambiente.descr.chi[pos].compareTo("1")==0)

Appendice


{ String s=new String("*"+ambiente.descr.chi[pos]+"*"+act+"*"

+ambiente.descr.dove[pos]+"##"); client.thread1.set_comando(2,s,ambiente,pos,act); de_light(); } tvcolor.validate(); return; }

public void funz1()

{ if (ambiente.descr.size>=1) action_funz(0); else super.funz1(); } public void funz2()






Appendice




{ tvcolor.messageACT.SetLabel("in attesa di comando...");

tvcolor.PAGINA.show(tvcolor.grigliaCARD, tvcolor.descr_vet[0].title);

de_light(); tvcolor.validate(); String s=new String(" §§§§§§ "); client.thread1.set_comando(2,s,

comando.Gest_START.ambiente,0,"0"); Set_listener(this,comando.Gest_STANZA); } public void funz0()

{ if (ambiente.descr.title.compareTo("*altro")!=0) {

tvcolor.PAGINA.show(tvcolor.grigliaCARD, tvcolor.descr_vet[1].title);

de_light(); tvcolor.validate(); tvcolor.ambienti[1].load_ico(); String s=new String("*#interrogazione");

client.thread1.set_comando(2,s, comando.Gest_AMBIENTI[0].ambiente,0,"0");

Set_listener(this,comando.Gest_AMBIENTI[0]); } else super.funz0(); } public void funzMENU()

{ funz9(); } public void funzYELLOW()

{ funz9();

} public void funzBLUE()

Appendice


{ funz0(); } public void funzGREEN()

{ tvcolor.messageACT.SetLabel("in attesa di comando..."); tvcolor.PannelloCentrale.remove(tvcolor.grigliaUP);

tvcolor.PannelloCentrale.remove(tvcolor.grigliaEST); tvcolor.PAGINA_DOWN.show(tvcolor.grigliaDOWN,"APRI");

de_light(); tvcolor.validate();

tvcolor.imagePanel.load_fix("icone/pippo.bmp"); String s=new String("*#13**0##");

client.thread1.set_comando(2,s, comando.Gest_START.ambiente,0,"0");

Set_listener(this,comando.Gest_START); } }

Appendice


ImagePanel.java import java.awt.*; import java.util.*; import java.lang.*; import osbaldeston.image.BMP; class ImagePanel extends Panel { int x1=0; int y1=0; int x=0; int y=0; Image image; Dimension dim; float prop; String file;

public void load_fix(String filename) {

Image image = null; file=filename; BMP bmp = new BMP(new java.io.File(filename)); image = bmp.getImage(); if (image != null && image.getHeight(null)>=0)

{ setImage_fix(image); invalidate(); repaint(); } else

{ System.err.println("***ERROR*** Couldn't load image:"

+filename); } } public void load(String filename) {

Image image = null; file=filename; BMP bmp = new BMP(new java.io.File(filename)); image = bmp.getImage(); if (image != null && image.getHeight(null)>=0)

{ setImage(image); invalidate();

Appendice


repaint(); } else

{ System.err.println("*** ERROR *** Couldn't load image:"

+filename); } } public void load_color(Color colore) {

this.setBackground(colore); } public synchronized void setImage_fix(Image image) {

if (this.image != null) { this.image.flush(); this.image=null; } dim=getSize(); prop=((float)4/(float)3); if (dim.height>dim.width/prop) { y=(int)((dim.height-(int)(dim.width/prop))/2); x=0; image=image.getScaledInstance(dim.width,

(int)(dim.width/prop),1); } else { x=(int)((dim.width-(int)(dim.height*prop))/2); y=0; image=image.getScaledInstance((int)(dim.height*prop),

dim.height,1); } this.image=image; } public synchronized void setImage(Image image) {

if (this.image != null) { this.image.flush(); this.image=null; } dim=getSize(); image=image.getScaledInstance(dim.width,dim.height,1); this.image=image; }

Appendice


public void update(Graphics g) {

paint(g); } public void paint(Graphics g) {

if (image != null) { getPreferredSize(); g.drawImage(image,x,y,this); }

super.paint(g); }

public Dimension getPreferredSize() { if (image != null)

{ return new Dimension

(image.getWidth(this),image.getHeight(this)); }

else { if (x1==0) x1=33; if (y1==0) y1=70; return new Dimension(x1,y1); }

} }

Appendice


Control_obj.java import java.awt.*; import java.awt.event.*; import java.util.*; import java.lang.*; class Control_obj extends Frame { Button BottoneX; Control_obj (Panel PannelloX)

{ Panel PannelloVuoto=new Panel(); PannelloVuoto.setBackground(Color.black); PannelloX.add(PannelloVuoto); }

Control_obj (Panel PannelloX,Color col)

{ Panel PannelloVuoto=new Panel();

PannelloVuoto.setBackground(col); PannelloX.add(PannelloVuoto); } Control_obj (String title,Panel PannelloX,Control Parent)

{ BottoneX=new Button(title); PannelloX.add(BottoneX);

} Control_obj (String title,Panel PannelloX,

Control Parent,Color col) { Panel PannelloVuoto=new Panel(); PannelloVuoto.setBackground(col); PannelloVuoto.setLayout(new BorderLayout()); BottoneX=new Button(title); Panel contornoN=new Panel(); contornoN.setBackground(col); Panel contornoS=new Panel(); contornoS.setBackground(col); Panel contornoE=new Panel(); contornoE.setBackground(col); Panel contornoW=new Panel(); contornoW.setBackground(col);

PannelloVuoto.add("Center",BottoneX); PannelloVuoto.add("North",contornoN); PannelloVuoto.add("South",contornoS); PannelloVuoto.add("East",contornoE); PannelloVuoto.add("West",contornoW); PannelloX.add(PannelloVuoto);

Appendice


} Control_obj (Panel PannelloX,Color col,Color col_centr)

{ Panel PannelloVuoto=new Panel(); PannelloVuoto.setBackground(col); PannelloVuoto.setLayout(new BorderLayout());

Panel CENTRO=new Panel(); CENTRO.setBackground(col_centr);

Panel contornoN=new Panel(); contornoN.setBackground(col); Panel contornoS=new Panel(); contornoS.setBackground(col); Panel contornoE=new Panel(); contornoE.setBackground(col); Panel contornoW=new Panel(); contornoW.setBackground(col); PannelloVuoto.add("Center",CENTRO); PannelloVuoto.add("North",contornoN); PannelloVuoto.add("South",contornoS); PannelloVuoto.add("East",contornoE); PannelloVuoto.add("West",contornoW);

PannelloX.add(PannelloVuoto); } }

Appendice


Video_obj.java import java.awt.*; import java.awt.event.*; import java.util.*; import java.lang.*; class Video_obj extends Frame { Panel PannelloVuoto; Label label;

Video_obj (Panel PannelloX)

{ PannelloVuoto=new Panel();

PannelloVuoto.setBackground(Color.black); PannelloX.add(PannelloVuoto); } Video_obj (Panel PannelloX,Color col)

{ PannelloVuoto=new Panel();

PannelloVuoto.setBackground(col); PannelloX.add(PannelloVuoto); } Video_obj (Panel PannelloX,Color col,Color col_centr)

{ PannelloVuoto=new Panel(); PannelloVuoto.setBackground(col); PannelloVuoto.setLayout(new BorderLayout()); Panel CENTRO=new Panel(); CENTRO.setBackground(col_centr); Panel contornoN=new Panel();

contornoN.setBackground(col); Panel contornoS=new Panel(); contornoS.setBackground(col); Panel contornoE=new Panel(); contornoE.setBackground(col); Panel contornoW=new Panel(); contornoW.setBackground(col);

PannelloVuoto.add("Center",CENTRO); PannelloVuoto.add("North",contornoN); PannelloVuoto.add("South",contornoS); PannelloVuoto.add("East",contornoE); PannelloVuoto.add("West",contornoW);

PannelloX.add(PannelloVuoto); } Video_obj (Panel PannelloX,String message,Color col_char,

Appendice


Color col_back, int dim) { label=new Label(message); label.setFont(new Font("Arial",Font.PLAIN,dim)); label.setForeground(col_char); label.setBackground(col_back); label.setAlignment(label.CENTER); PannelloX.add(label); PannelloX.validate();

} Video_obj (Panel PannelloX,String message,Color col_char,

Color col_back, int dim,int bordo) {

PannelloVuoto=new Panel(); PannelloVuoto.setBackground(Color.pink); PannelloVuoto.setLayout(new GridLayout(1,1,bordo,bordo));

label=new Label(message); label.setFont(new Font("Arial",Font.PLAIN,dim)); label.setForeground(col_char); label.setBackground(col_back); label.setAlignment(label.CENTER); PannelloVuoto.add(label); PannelloX.add(PannelloVuoto); }

Video_obj (Panel PannelloX,String message,Color col_char,

Color col_back,Color col_bordo, int dim) { Panel PannelloVuoto=new Panel(); PannelloVuoto.setBackground(col_bordo); PannelloVuoto.setLayout(new BorderLayout());

Label label=new Label(message);

label.setFont(new Font("Arial",Font.PLAIN,dim)); label.setForeground(col_char); label.setBackground(col_back); label.setAlignment(label.CENTER); Panel CENTRO=new Panel();

CENTRO.setBackground(col_back); CENTRO.add(label);

Panel contornoN=new Panel(); contornoN.setBackground(col_bordo);

Panel contornoS=new Panel(); contornoS.setBackground(col_bordo); Panel contornoE=new Panel(); contornoE.setBackground(col_bordo); Panel contornoW=new Panel(); contornoW.setBackground(col_bordo);

Appendice


PannelloVuoto.add("Center",CENTRO); PannelloVuoto.add("North",contornoN); PannelloVuoto.add("South",contornoS);

PannelloVuoto.add("East",contornoE); PannelloVuoto.add("West",contornoW);

PannelloX.add(PannelloVuoto); }

public void SetLabel(String new_label)

{ this.label.setText(new_label); } }

Appendice


Video_room.java import java.awt.*; import java.awt.event.*; import java.util.*; import java.lang.*; class Video_room extends Frame { static int size=10; String[] room_options={" "," "," "," "," "," "," "," ","MENU

PRINCIPALE","ALTRO",}; String[] numeri={"1","2","3","4","5","6","7","8","9","0",}; Video_obj load[]; Video_obj num[]; ImagePanel imm[]; boolean state[]; int size_options; String[] ico_true,ico_false;

Panel PannelloVuoto; Panel PannelloVuoto3; Description descr;

Video_room (Panel PannelloX,Description descrittore)

{ descr=descrittore; int j; ico_true=new String[descr.size]; ico_false=new String[descr.size]; for (j=0;j<descr.size;j++)

{ ico_true[j]=descr.ico_on[j]; ico_false[j]=descr.ico_off[j];

} int i=0; size_options=descr.size; initial_state(); PannelloVuoto=new Panel(); PannelloVuoto.setLayout(new BorderLayout(2,2)); PannelloVuoto.setBackground(Color.darkGray); Panel PannelloVuoto0=new Panel(); PannelloVuoto0.setLayout(new GridLayout(1,1)); Panel PannelloVuoto1=new Panel(); PannelloVuoto1.setLayout(new GridLayout(10,1,3,3)); PannelloVuoto1.setBackground(Color.darkGray);

Appendice


Panel PannelloVuoto2=new Panel(); PannelloVuoto2.setLayout(new GridLayout(10,1,3,3)); PannelloVuoto2.setBackground(Color.darkGray); PannelloVuoto3=new Panel(); PannelloVuoto3.setLayout(new GridLayout(10,1,3,3)); PannelloVuoto3.setBackground(Color.darkGray);

Video_obj label=new Video_obj(PannelloVuoto0, descr.title.toUpperCase().substring(1),Color.black,

Color.orange,descr.colore,22); num=new Video_obj[size]; load=new Video_obj[size]; imm=new ImagePanel[size];

for (i=0;i<size;i++ )

{ imm[i]= new ImagePanel(); PannelloVuoto3.add(imm[i]); }

for (i=0;i<size_options ;i++ )

{ room_options[i]=descr.opt[i]; num[i]=new Video_obj(PannelloVuoto1,numeri[i],Color.black,

Color.yellow,24); load[i]=new Video_obj(PannelloVuoto2,room_options[i].toUpperCase(),

Color.black,Color.lightGray,22); }

int h=2; if (descr.title.compareTo("*MENU")==0) h=1;

for (;i<size-h;i++)

{ num[i]=new Video_obj(PannelloVuoto1," ",Color.darkGray,

Color.darkGray,24); load[i]=new Video_obj(PannelloVuoto2," ",Color.darkGray

,Color.darkGray,22); }

h=0; if (descr.title.compareTo("*altro")==0) h=1;

for (;i<size-h;i++ ) {

num[i]=new Video_obj(PannelloVuoto1,numeri[i],Color.black, Color.yellow,24);

load[i]=new Video_obj(PannelloVuoto2,room_options[i].toUpperCase(),

Appendice


Color.black,Color.lightGray,22); }

for (;i<size;i++ ) { num[i]=new Video_obj(PannelloVuoto1," ",Color.darkGray,

Color.darkGray,24); load[i]=new Video_obj(PannelloVuoto2," ",Color.darkGray,

Color.darkGray,22); } PannelloVuoto.add("North",PannelloVuoto0); PannelloVuoto.add("West",PannelloVuoto1); PannelloVuoto.add("Center",PannelloVuoto2); PannelloVuoto.add("East",PannelloVuoto3); PannelloX.add(PannelloVuoto,descr.title); } public void initial_state()

{ int i;

state=new boolean[size_options]; for (i=0;i<size_options ;i++ ) { state[i]=false;

} } public void flip_ico(int pos)

{ state[pos]=!state[pos]; if (state[pos]==true) imm[pos].load(ico_true[pos]); else imm[pos].load(ico_false[pos]); } public void flip_stato(int pos)

{ String h; state[pos]=!state[pos]; if (state[pos]==true) h="1"; else h="0"; }

public void flip_imm(int pos)

{ if (state[pos]==true) imm[pos].load(ico_true[pos]); else imm[pos].load(ico_false[pos]); }

public String flip_mes(int pos)

{ String str; if (state[pos]==true) str="* ON *"; else str="* OFF *";

Appendice


return str; } public void load_ico()

{ int i; if (descr.title.compareTo("*MENU")==0) { for (i=0;i<size_options ;i++ ) imm[i].load_color(descr.col_vett[i]); } else { for (i=0;i<size_options ;i++ ) { if (state[i]==true) imm[i].load(ico_true[i]); else imm[i].load(ico_false[i]); } } int h=2; for (;i<size-h;i++) { imm[i].load_color(Color.black); } if (descr.title.compareTo("*MENU")==0)

imm[size-2].load_color(Color.black); else imm[size-2].load_color(Color.yellow); if(descr.title.compareTo("*altro")!=0)

imm[size-1].load_color(Color.blue); else imm[size-1].load_color(Color.black); } }

Appendice


Gestore_tapparelle.java import java.awt.*; import java.awt.Graphics; import java.awt.event.*; import java.util.*; import java.lang.*; class Gestore_tapparelle extends Gestore_action { int flag; public int posizione;

Gestore_tapparelle (Control parent,Video window,Video_room

corrente,TextArea report,Gestore_action old,Casa_client cl) {

super(parent,window,corrente,report,old,cl); }

public void action_funz(int pos,String act) { String s=new String("*2*"+act+"*"+ambiente.descr.dove[pos]+"##");

client.thread1.set_comando(2,s,ambiente,pos,act); } public void funzUP()

{ action_funz(posizione,"1"); } public void funzDOWN()

{ action_funz(posizione,"2"); } public void funzOK()

{ action_funz(posizione,"0"); Set_listener(this,old_GEST); de_light(); } public void funzGREEN()

{ tvcolor.PannelloCentrale.remove(tvcolor.grigliaUP); tvcolor.PannelloCentrale.remove(tvcolor.grigliaEST); tvcolor.PAGINA_DOWN.show(tvcolor.grigliaDOWN,"APRI"); de_light(); tvcolor.validate(); tvcolor.imagePanel.load("icone/pippo.bmp"); Set_listener(this,comando.Gest_START); } }

Appendice


GestoreWindow.java import java.awt.*; import java.awt.event.*; public class GestoreWindow implements WindowListener { Control locale;

GestoreWindow(Control parent) {

locale=parent; } public void windowOpened(WindowEvent e) {

} public void windowActivated(WindowEvent e) {

} public void windowDeactivated(WindowEvent e) {

} public void windowIconified(WindowEvent e) {

} public void windowDeiconified(WindowEvent e) {

} public void windowClosing(WindowEvent e) {

System.exit(0); } public void windowClosed(WindowEvent e) {

} }

Appendice


GestoreWindow_TV.java import java.awt.*; import java.awt.event.*; public class GestoreWindow_TV implements WindowListener,ComponentListener { Video window;

GestoreWindow_TV(Video parent) {

window=parent; } public void windowOpened(WindowEvent e) {

} public void windowActivated(WindowEvent e) {

} public void windowDeactivated(WindowEvent e) {

} public void windowIconified(WindowEvent e) {

} public void windowDeiconified(WindowEvent e) {

window.imagePanel.load_fix("icone/pippo.bmp"); window.imagePanel_nord.load("icone/image1.bmp"); window.imagePanel_sud.load("icone/image4.bmp"); window.validate(); window.repaint(); } public void windowClosing(WindowEvent e) {

System.exit(0); } public void windowClosed(WindowEvent e) {

} public void componentResized(ComponentEvent e) { window.imagePanel_nord.load("icone/image1.bmp");

Appendice


window.imagePanel_sud.load("icone/image4.bmp"); window.imagePanel.load_fix("icone/pippo.bmp"); window.validate(); window.repaint(); } public void componentMoved(ComponentEvent e) {

} public void componentShown(ComponentEvent e) {

} public void componentHidden(ComponentEvent e) {

} }

Appendice


Casa_client.java import java.io.*; import java.net.*; public class Casa_client { static Socket socket; static DataInputStream in; static DataOutputStream out; static String address="192.168.2.30"; static String inStr;

private static final int PORTNUM = §§§§§§; public Alert thread1; public void Casa_client() {

} public static char[] lettura() { char[] word=new char[30]; int i=0; char[] last_2=new char[2]; last_2[0]='0'; last_2[1]='0'; try { System.out.print("SERVER:... "); while (true) { char x=(char)in.read(); word[i++]=x; last_2[1]=x; System.out.print(x); if ((last_2[0]=='#')&&(last_2[1]=='#')) break; last_2[0]=x;

} System.out.println("---"); return word; } catch (IOException e) { System.err.println("Exception: couldn't read from stream

socket "+e); System.exit(1); } return word; }

Appendice


public static void scrittura(String data) { try

{ out.writeBytes(data); out.flush(); System.out.println("Client:... " + data); return; } catch (IOException e) { System.err.println("Exception: couldn't print to stream

socket "+e); System.exit(1);

} } public static void connect() {

try {

StringBuffer str = new StringBuffer(128); socket = new Socket(address,PORTNUM); in = new DataInputStream(socket.getInputStream());

out = new DataOutputStream(socket.getOutputStream()); lettura(); scrittura(" §§§§§§ "); char[] parola=lettura(); Critta xxx=new Critta(); xxx.critta_parola(parola);

scrittura(" §§§§§§ "); lettura(); return;

} catch (IOException e)

{ System.err.println("Exception: couldn't create stream


} } public static void chiusura() { try

{ out.close();

in.close(); socket.close(); return;

} catch (IOException e)

{ System.err.println("Exception: couldn't close stream

Appendice



} }

}

Appendice


Alert.java import java.lang.*; public class Alert implements Runnable { public Casa_client client; public Thread me; public Video_room ambiente; public Video tvcolor; public int flag=0; public int how_long; public int pos; public int i; public int x=0; public String message; public String message_bak; public String message_contr; public String str; public String act; public char[] contr; public boolean contr_b; public Alert(String msg,int sleep_time,Casa_client cl,Video tv) { message=msg; client=cl; how_long= sleep_time * 1000; tvcolor=tv; me = new Thread(this); i=0; } public void run () { while (true)

{ try

{ switch (flag)

{ case 0 : this.client.scrittura(message); this.client.lettura(); this.client.lettura(); me.sleep (how_long);

Appendice


break; case 1 : this.client.scrittura(message); contr=this.client.lettura(); if (contr[3]!='0') { if (ambiente.descr.chi[pos].compareTo("0")==0)

tvcolor.messageACT.SetLabel(("SCENARIO"+" "+ambiente.descr.opt[pos]).toUpperCase());

if (ambiente.descr.chi[pos].compareTo("1")==0) { ambiente.flip_stato(pos); ambiente.flip_imm(pos); str=ambiente.flip_mes(pos); tvcolor.messageACT.SetLabel((ambiente.descr.opt[pos]

+" "+ambiente.descr.title.substring(1)+" "+str).toUpperCase()); x=1;

} if (ambiente.descr.chi[pos].compareTo("2")==0) { if (act.compareTo("0")==0) { ambiente.flip_imm(pos); tvcolor.messageACT.SetLabel("TAPPARELLA OK"); x=1; } if (act.compareTo("1")==0)

{ ambiente.imm[pos].load("icone/tapp_APRI.bmp");

tvcolor.messageACT.SetLabel("PER FERMARE PREMERE OK");

} if (act.compareTo("2")==0)

{ ambiente.imm[pos].load("icone/tapp_CHIUDI.bmp");

tvcolor.messageACT.SetLabel("PER FERMARE PREMERE OK");

} }

} else { tvcolor.messageACT.SetLabel("COMANDO NON ESEGUITO"); } flag=3; me.sleep (how_long); break;

case 2 :

Appendice


if (message_bak.compareTo(" §§§§§§ ")==0) { System.out.println("richiesta ora"); flag=0; how_long=3000; message=message_bak; break; } if (message_bak.compareTo("*#interrogazione")==0) { flag=3; i=0; break; } flag=1; message=message_bak; break;

case 3 : if (ambiente.descr.title.substring(1).

compareTo("scenari")==0) { flag=0; message=" §§§§§§ "; how_long=3000; break; } if (i==ambiente.descr.size) { i=0; if (x==1) {

tvcolor.messageACT.SetLabel("in attesa di comando...");

x=0; }

} this.client.scrittura(" §§§§§§ "); contr=this.client.lettura(); this.client.lettura(); if (ambiente.descr.chi[i].compareTo("2")==0) { if( contr[3]=='1') contr_b=true; if( contr[3]=='2') contr_b=true; if( contr[3]=='0') contr_b=false; } else { if( contr[3]=='0') contr_b=false; else contr_b=true; }

Appendice


if(contr_b!=(ambiente.state[i])) { if (ambiente.descr.chi[i].compareTo("2")==0) { if( contr[3]=='1')

{ ambiente.imm[i].load("icone/tapp_APRI.bmp"); ambiente.state[i]=true; } if( contr[3]=='2')

{ ambiente.imm[i].load("icone/tapp_CHIUDI.bmp");

ambiente.state[i]=true; } if( contr[3]=='0')

{ ambiente.imm[i].load(ambiente.ico_false[i]); ambiente.state[i]=false; } } else { ambiente.flip_ico(i);

tvcolor.messageACT.SetLabel((ambiente.descr.opt[i]+" "+ambiente.descr.title.substring(1)+"

"+ambiente.flip_mes(i)).toUpperCase()); x=1; } } i++; break; }

} catch(Exception e) {} } } public void set_comando(int x,String msg,Video_room amb,int p,

String a) { flag=x; message_bak=msg; ambiente=amb; pos=p; act=a; } }

Bibliografia [1] ENEA UDA – Progetto tecnologie per la qualità della vita – S. Ba-

roni B. Felici C. Munciguerra http://andi.casaccia.enea.it

[2] www.domoticamica.it [3] Domotica e disabilità www.domotica.ch [4] www.cetad.org [5] www.bticino.it [6] www.duemmegi.it [7] www.echelon.com [8] Multimedia Home Platform: uno standard comune per servizi e

terminali domestici – Elettronica e Telecomunicazioni www.crit.rai.it

[9] www.dvb.org [10] www.mhp.org [11] Java TV API Technical overview [12] Libro bianco sulla televisione digitale terrestre [13] CEI – Guida alla tecnologia e ai servizi dei ricevitori (Set Top Box

e televisori digitali integrati) per la televisione digitale terrestre [14] www.mhp-interactive.org [15] www.televisionedigitaleterrestre.it [16] World Broadcast Engineering – Spring Edition – The DVB MHP

specification- A guided tour – C.Vogt, Alcatel, France (DVB TAM Chairman)

[17] www.accessibile.net [18] www.w3c.org [19] www.java.sun.com [20] www.cardinalsystem.com

Documents

Facoltà di Ingegneria dell'Informazione - elite.polito.itelite.polito.it/files/thesis/fulltext/cetad.pdf · 2.4.2 Web Server 49 2.4.2.1 Software forniti da Bticino 52 2 ... Schema