Interfacciamento del sistema Konnex con la piattaforma Smart-M3 Luca Feltrin
Indice Konnex: Smart-M3 Progetto Addressing Architettura dispositivi Funzionamento Ontologia e triple Procedure primitive Architettura applicazioni Situazione iniziale Sviluppo dell'applicazione Sviluppi futuri
Introduzione Perchè interfacciare un impianto domotico con un sistema di condivisione delle informazioni? Far interagire tra di loro dispositivi indipendentemente dalla tecnologia che usano (Konnex, Bluetooth,ZigBee,VESA,HES...) Gestione remota dell'impianto Condivisione delle informazioni per altre applicazioni...
Introduzione Agente Temperatura: FA CALDO Situazione Normale Battiti Cardiaci: TANTI
Introduzione Agente Temperatura: SI STA BENE C'è qualcosa che non va! Battiti Cardiaci: TANTI
Konnex Standard coperto da royalty: Konnex Association http://www.knx.org/ Logica Distribuita, peer to peer. Comunicazioni via Bus: Twisted Pair (interfacciamento con TPUart) con possibilità di alimentazione max 64 dispositivi RF @868MHz Power line KNX over IP
Konnex: Addressing (indirizzo fisico) Dispositivo Indirizzo fisico Utilizzato solo in fase di setup dell'impianto 16bit con struttura gerarchica basata sull'ubicazione es: 1.1.23 Area (4 bit) Linea (4 bit) (divisa in 4 segmenti da 64) Dispositivo (8 bit) Area 0 backbone; Line 0 main line Dispositivi di disaccoppiamento elettrico + firewall Line Coupler Backbone Coupler
Konnex: Addressing (indirizzo fisico)
Konnex: Addressing (indirizzo di gruppo) Oggetto/i di comunicazione Indirizzo di gruppo Utilizzato a run-time 16 bit con struttura gerarchica basata (in genere) sulla funzione. Es: 1/0/22 Impianto (4 bit) Categoria funzione (es illuminazione) (4 bit) Funzione (es: illuminazione cucina) (8 bit) Usato come destinazione nei telegrammi => multicast
Konnex: Addressing (indirizzo di gruppo) Oggetto di com. Luce1 1/0/3 Telegramma Dest: 1/0/3 Turn ON Oggetto di com. Luce2 1/0/3 Oggetto di com. Pulsante 1/0/3 Gruppo 1/0/3: Illuminazione Cucina
Konnex: Architettura Dispositivi Un dispositivo contiene una collezione di Oggetti di Comunicazione Un oggetto di comunicazione... È un registro interno Fa da interfaccia tra la rete KNX e l'hardware del dispositivo Ha un comportamento regolato da flag Può essere registrato a più indirizzi di gruppo Se decide di trasmettere, lo fa solo verso un indirizzo di gruppo dispositivo Oggetto di comunicazione Oggetto di comunicazione Oggetto di comunicazione
Konnex: Funzionamento (Tipi di Telegrammi) Esistono vari tipi di telegramma in base al comando che l'oggetto di comunicazione esegue/invia Read: richiesta di lettura di un certo oggetto di comunicazione Read Responce: risposta al comando di lettura Write: richiesta di scrittura su un oggetto di comunicazione Update: notifica del fatto che il valore dell'oggetto di comunicazione è cambiato su evento hardware Acknowledge: notifica la corretta ricezione di un altro telegramma
Konnex: Funzionamento (Flag) I flag regolano il comportamento di un oggetto di comunicazione su eventi hardware o sulla ricezione di telegrammi. Communication Read 0 Su ricezione di un telegramma che tenta di modificare il valore del registro (write o read responce) invia un ack. Ma non lo modifica 1 lo modifica 0 il valore dell'oggetto di comunicazione non può essere letto dal bus. 1 a un telegramma read l'oggetto di comunicazione risponde con una read responce
Konnex: Funzionamento (Flag) Write Transmit Update 0 il valore dell'oggetto di comunicazione non può essere modificato dal bus 1 può essere modificato 0 l'oggetto di comunicazione invia nel bus il proprio valore solo in caso di comando read 1 lo invia anche in caso di evento Hardware 0 una read responce non viene interpretata come write 1 viene interpretata come write
Konnex: Funzionamento (Tabella Indirizzi) Ogni oggetto di comunicazione ha associata una tabella di indirizzi di gruppo......se intercetta un telegramma proveniente da uno di quegli indirizzi, reagisce come specificato dai flag Un oggetto di comunicazione può appartenere a più gruppi! Uno di questi indirizzi ha la proprietà S: l'oggetto di comunicazione può spedire telegrammi solo verso quell'indirizzo
Konnex: Funzionamento (Esempio[1]) Group addr tabl 1/1/1 S 1/1/2 0 0 MyBedroomIllumination GlobalIllumination Group addr tabl 1/1/2 S Si vogliono comandare 5 lampade con 2 pulsanti, in particolare il primo comanda direttamente la 2 luce, il 2 pulsante accende e spegne tutte le luci. Il modo corretto per configurare l'impianto è quello rappresentato in figura...
Konnex: Funzionamento (Esempio[2]) Group addr tabl 1/1/1 S 1/1/2 T 1 0 MyBedroomIllumination GlobalIllumination Group addr tabl 1/1/2 S Viene premuto il 1 pulsante, l'oggetto di comunicazione cambia valore e genera un telegramma (update) verso l'indirizzo con proprietà S, la 2 lampada decide di reagire cambiando il proprio stato e accendendosi
Konnex: Funzionamento (Esempio[3]) Group addr tabl 1/1/1 S 1/1/2 1 1 MyBedroomIllumination T GlobalIllumination Group addr tabl 1/1/2 S Alla pressione del 2 pulsante, l'oggetto di com cambia valore e invia un altro telegramma sull'indirizzo 1/1/2, tutte le lampade decidono di reagire accendendosi (la 2 era già accesa) (anche l'ogg di com del 1 pulsante reagisce ma non succede niente)
Konnex: Funzionamento (Esempio[4]) T A una nuova pressione del 2 pulsante, viene inviato un altro telegramma a tutte le lampade che si spengono e al 1 pulsante che cambia valore all' Oggetto di comunicazione che rimane sincronizzato con la rispettiva lampada Group addr tabl 1/1/1 S 1/1/2 0 0 MyBedroomIllumination GlobalIllumination Group addr tabl 1/1/2 S
Smart-M3 Piattaforma di coordinazione tra agenti a spazio di dati condiviso Progetto iniziato da Nokia Research Center, licenza BSD, nell'ambito del progetto SOFIA Lo spazio condiviso contiene triple (soggetto; predicato; oggetto) Per dare una semantica alle informazioni occorre strutturare le triple secondo un'ontologia Gli agenti comunicano e si coordinano tra di loro inserendo togliendo e leggendo le triple dallo spazio condiviso. Applicazione composta da più agenti ognuno con una specifica funzione (modularità)
Smart-M3 (SIB) La SIB (Semantic Information Broker) è il componente dell'applicazione che contiene lo spazio di dati condiviso. Attualmente alla versione 0.9.5 beta, disponibile per linux. Il server della SIB rimane in ascolto sulla porta 10010 Sono disponibili procedure standard per l'inserimento e la lettura delle triple: insert, remove, update, subscribe, queryrdf e querywilbur. Sono già pronte le API per vari linguaggi, sono state usate quelle in C# in modo da poter eseguire gli agenti su un terminale embedded con WindowsCE.
Smart-M3 (triple e ontologia) Una tripla è formata da <Soggetto, Predicato, Oggetto> Possono essere entità (o nodi) identificati da un URI oppure dei literal (valori primitivi es interi, double, stringa codificati comunque come stringhe) In genere il predicato indica un attributo (oggetto) che si vuole dare al soggetto. Es: <Studente01, HasName, 'Luca'> oppure <Studente01, StudiesAt, UniversitàDiBologna> Un'ontologia è una rappresentazione a grafo di tutte le entità (o nodi) contenute nello spazio che dà un significato alle informazioni in un ottica ObjectOriented. Esistono due predicati standard per strutturare le classi: rdfs:subclassof (per le sottoclassi) e rdf:type (per l'appartenenza a una classe). Il nodo radice è owl:thing
Smart-M3 (triple e ontologia) Esempio <Person,rdfs:SubclassOf,owl:Thing> <Student,rdfs:SubclassOf,Person> <Teacher,rdfs:SubclassOf,Person> <Course,rdfs:SubclassOf,owl:Thing> <LucaFeltrin,rdf:type,Student> <LucaRoffia,rdf:type,Teacher> <CalcolatoriElettronici,rdf:type,Course> <LucaRoffia,teaches,CalcolatoriElettronici> <LucaFeltrin,Attended,CalcolatoriElettronici> Owl:Thi ng SubclassOf Type Generic predicate Student Person Teacher LucaRoffia Course CalcolatoriElettronici LucaFeltrin
Smart-M3 (procedure primitive) Insert(<S,P,O>) Per inserire nello spazio condiviso una tripla Remove(<S,P,O>) per rimuovere dallo spazio una tripla data Update(old<S,P,O>,new<S,P,O>) per modificare una tripla nota Le API in C# offrono anche la possibilità di inserire, rimuovere e modificare un intero grafo (ovvero una collezione di triple)
Smart-M3 (procedure primitive) queryrdf([s,p,o]) Per ottenere una collezione di triple che combaciano con il template dato in ingresso (si fornisce in modo simile a una tripla ma si può usare l'uri speciale 'any' simile al carattere *) Esempio riferito al grafo precedente, per trovare tutti i corsi seguiti da LucaFeltrin: queryrdf([lucafeltrin,attended,any]) si ottiene <LucaFeltrin,attended,CalcolatoriElettronici> CalcolatoriElettronici LucaFeltrin
Smart-M3 (procedure primitive) querywilbur(node,<inversepath>*) a partire da un nodo, si ottengono tutti i nodi collegati a questo attraverso un percorso inverso. Es. Per trovare tutti gli studenti di LucaRoffia: querywilbur(lucaroffia,<teaches; attended>) si ottiene il nodo LucaFeltrin CalcolatoriElettronici LucaRoffia LucaFeltrin
Smart-M3 (procedure primitive) (un)subscribe([s,p,o]) Grazie a questa procedura, un agente può registrarsi a una collezione di triple (identificate dal template passato in ingresso). Quando una di queste triple viene modificata o ne viene creata una che rispecchia il template, la SIB invia una notifica all'agente (in un'ottica EventBased). Le API in C# forniscono anche altre procedure per connettersi e disconnettersi allo spazio condiviso (join, leave), nella creazione dell'oggetto KPICore si specificano IP e porta del server SIB.
Smart-M3 (architettura applicazioni) Un'applicazione è la composizione di più agenti, distribuiti su più macchine, che interagiscono con la SIB Un agente prende il nome di KP (Knowledge Processor) In base alla funzionalità si distinguono 3 tipi di KP Producer se producono nuova informazione quindi nuove triple eseguendo prevalentemente insert e update Consumer se utilizzano le informazioni contenute nella SIB, eseguiranno prevalentemente query e subscribe Aggregator se prendono delle informazioni e in base a queste ne creano di nuove
Smart-M3 (architettura applicazioni) È opportuno che i KP siano più minimali possibili, ovvero che facciano parte di una specifica categoria e che siano sottoscritti a una minima dell'ontologia. È sottinteso che qualsiasi tipo di KP può fare, in fase di inizializzazione, delle query anche se di tipo Producer. GUI Cons SIB Prod Prod Aggr
Progetto (Situazione Iniziale)
Progetto (Situazione Iniziale) Per interfacciarsi al bus KNX è pre-installato un software proprietario: ErgoCE-Server. In ascolto sulla porta 8081 Comunicazione in formato XML Possibilità di inviare comandi write,read e subscribe Non dà la possibilità di distinguere telegrammi di tipo write,update e read responce (quando vengono ricevuti)
Progetto (Situazione Iniziale) Per la parte Konnex 0/0/1 lampada 1 + interruttore 1 0/0/2 lampada 2 + interruttore 2 0/0/3 lampada 3 0/0/4 lampada 4 0/0/5 (illuminazione generale) lampada 1, lampada 2, lampada 3, lampada 4, interruttore 1, interruttore 2 0/0/6 sensore di potenza (datatype 14 float 4 byte) 0/0/7 sensore di temperatura (datatype 9 float 2 byte)
Progetto (Sviluppo: l'ontologia) Si vuole una rappresentazione dei singoli dispositivi in KNX esiste solo la rappresentazione in gruppi (funzionalità). Switch Switch01 Può essere Reale o Virtuale... Lamp Lamp01 Lamp02 LogicalGroup 0/0/1 Illuminazione Cucina Esistono le istanze delle singole lampade Esiste il concetto di gruppo e di appartenenza al gruppo Nel caso in cui Switch01 appartenesse a più gruppi, Affect indica la destinazione dei comandi (proprietà S)
Progetto (Sviluppo: l'ontologia) Rappresentazione dei dati dei sensori Sensor DataValue Measurand UnitOfMeas. PowerSensor PData Power W HP K TemperatureSensor TData Temperat. F C Concetto di: Dato Tipo di grandezza Fisica Unità di misura 100 26
Il progetto (Sviluppo: I KP) Suddivisione dei problemi: Inizializzazione, Illuminoteca, Temperature Sensing, Power Consumption Sensing.
Il progetto (Sviluppo: I KP) Flusso dei dati Switch
Il progetto (Sviluppo: I KP) Funzionamento KNX_Init Inserisce nella SIB tutta l'ontologia mostrata nelle slide precedenti In un futuro si potrebbe fare in modo di creare il grafo a partire da un file esportato da uno dei programmi per il setup di un impianto Konnex Funzionamento KNX_Monitor (dotato di GUI) Visualizza su GUI lo stato di lampade e sensori
Il progetto (Sviluppo: I KP) Funzionamento XNK_Temperature/Power_Adapter: Dalla SIB ricava gli indirizzi di gruppo di tutti i sensori ti temperatura/potenza presenti nell'impianto Quando arriva un telegramma con uno degli indirizzi da monitorare, aggiorna il dato dell'entità corrispondente nell'ontologia (update)
Il progetto (Sviluppo: I KP) Funzionamento KNX_Lamp_Adapter Dalla SIB ricava gli indirizzi di gruppo di tutte le lampade (o meglio dei gruppi contenenti lampade) Quando arriva un telegramma con uno degli indirizzi da monitorare, aggiorna lo stato dell'entità corrispondente nell'ontologia, da notare che possono essere anche più entità.
Il progetto (Sviluppo: I KP) Funzionamento KNX_Buttons (Dotato di GUI) Quando l'utente preme un bottone sull'interfaccia grafica, viene modificata l'entità Switch corrispondente nel grafo. Funzionamento KNX_Lamp_Actuator Sottoscritto alle entità Switch, quando si modificano inviano sul bus KNX un comando all'indirizzo di gruppo individuabile grazie al predicato affect
Il progetto (Sviluppo: I KP, Debugging)...ovvero il 90% dell'attività di un Ingegnere Informatico! I tempi di comunicazione tra SIB, KP e bus KNX sono molto lenti (nell'ordine di 1 secondo) Supponiamo di premere due volte velocemente lo stesso pulsante...
Il progetto (Sviluppo: I KP, Debugging)
Il progetto (Sviluppo: I KP, Debugging)
Il progetto (Sviluppo: I KP, Debugging)
Il progetto (Sviluppo: I KP, Debugging)
Il progetto (Sviluppo: I KP, Debugging) Possibili soluzioni: Integrazione di meccanismi di Lock nella SIB (già presenti nella versione 0.9.5) Modifica di KNX_Switch_Actuator per l'aggiunta di meccanismi di filtraggio dei comandi...
Il progetto (Sviluppo: I KP, Debugging) Modifiche: KNX_Switch_Actuator sarà sottoscritto anche al bus KNX Una tabella in memoria contiene tutti i possibili comandi e un campo valore che viene incrementato se proviene dal BUS e decrementato se proviene dalla SIB. Quando arriva un comando dalla SIB se il campo valore è 0 allora viene inoltrato, altrimenti non viene inoltrato
Il progetto (Sviluppo: I KP, Debugging)
Il progetto (Sviluppo: I KP, Debugging)
Il progetto (Sviluppo: I KP, Debugging)
Il progetto (Sviluppo: I KP, Debugging)
Il progetto (Sviluppi Futuri) Integrazione di meccanismi di lock e sicurezza (permessi, gestione utenti...) nella SIB. Studio di una topologia di rete efficace per non avere problemi di port forwarding (vedi Fastweb) SIB su Server con IP Pubblico proprietario SIB su Server domestico (o dispositivo Embedded) Ulteriore sviluppo dell'ontologia per garantire espressività nel rappresentare le informazioni
Ending... Per eventuali dubbi o richieste di chiarimenti... luca.feltrin@studio.unibo.it Buono Studio!