Automatyczna generacja zintegrowanego interfejsu czowiek-maszyna na potrzeby inteligentnego budynku

dr in. Jacek Chmielewski dr hab. in. Jarogniew Rykowski

Katedra Technologii Informacyjnych Uniwersytetu Ekonomicznego, ul. Mansfelda 4, 60-854 Pozna tel/fax. +48 61 848-0549 e-mail: rykowski{chmielewski}@kti.ue.poznan.pl

Streszczenie1
W artykule przedstawiono nowe podejcie do realizacji interfejsu czowiek-maszyna, oparte na idei sieci cichego przetwarzania danych. W podejciu zakada si integracj trzech do tej pory rozdzielonych obszarw badawczych: zdalnej identyfikacji radiowej RFID, urzdze personalnych sieci telekomunikacyjnych oraz tak zwanych sieci osobistych, a take klasycznych interfejsw typu GUI. Gwn ide podejcia jest nowatorski, wielofazowy sposb przeprowadzenia interakcji czowieka z urzdzeniami komputerowymi. W pierwszej fazie nastpuje automatyczna identyfikacja u ytkownika (np. za pomoc znacznika RFID lub parametrw urzdzenia osobistego, ktrym si posuguje). W drugiej fazie odbywa si okrelenie kontekstu interakcji, np. ustalenie wzajemnego pooenia u ytkownika oraz najbliszych urzdze sieci inteligentnego budynku, okrelenie praw dostpu itp. W nastpnej fazie jest automatycznie wybierane urzdzenie, ktre najefektywniej umoliwi przeprowadzenie interakcji, wczajc nie tylko urzdzenia osobiste u ytkownika, ale take urzdzenia sieci budynku (np. znajdujcy si w pobliu ekran komputera stacjonarnego). Do wybranego urzdzenia jest przesyana definicja automatycznie wygenerowanego i dostosowanego do moliwoci tego urzdzenia interfejsu, ktry w ostatniej fazie umoliwi interakcj wydanie polecenia (zapytania) przez czowieka oraz uzyskanie przez niego odpowiedzi, w wybranej przez niego formie i zakresie. Moliwym obszarem zastosowa automatycznie generowanego interfejsu nowego typu s te inteligentne budynki, w ktrych zachodzi masowa interakcja z okazjonalnymi uytkownikami. W artykule opisano przykady wykorzystania interfejsu do realizacji idei inteligentnego szpitala, w ktrym ruch pacjentw jest wspomagany zintegrowanym systemem informacji wietlnej i multimedialnej, interaktywnego muzeum, w ktrym zwiedzajcy maj wsparcie indywidualnego e-przewodnika, komunikujcego si w wybranym przez nich jzyku i oprowadzajcego po tych miejscach, ktre wczeniej zostay uznane za najbardziej interesujce, itp.

1. Wstp Istnieje szereg powodw wprowadzania technologii inteligentnych budynkw (IB) zwikszenie stopnia bezpieczestwa, wygody, zbyt wiele urzdze do bezporedniego sterowania itd. Ostatnio zaproponowano szereg nowatorskich rozwiza w dziedzinie implementacji idei IB. Jednake, technologie te cigle w niedostatecznym stopniu uwzgldniaj specyfik interakcji midzy czowiekiem i urzdzeniami IB. Jak dotd, wikszo rozwiza IB opiera si na sztywno generowanych interfejsach przypisanych do konkretnych miejsc lub instalacji budynku. Na przykad, aby kontrolowa poziom owietlenia w pokoju naley skorzysta z naciennego programatora scen wietlnych. Takie podejcie nie zawsze jest efektywne, z dwch gwnych powodw. Po pierwsze, uytkownicy musz nauczy si korzystania z wielu interfejsw, osobno dla kadego z urzdze nie tylko specyfiki interfejsu wymuszonej przez producenta urzdzenia, ale take jego lokalizacji, predefiniowanych ustawie (na przykad wspomnianych scen wietlnych kto pamita takie ustawienia po kilku miesicach od zaprogramowania?) itp. Po drugie, instalacje IB mog si mocno midzy sob rni, dlatego uytkownik zaznajomiony z urzdzeniami IB w jednej lokalizacji niekoniecznie poradzi sobie z obsug podobnych urzdze w innym budynku. Z drugiej strony, uytkownicy maj tendencj do wykorzystywania, o ile tylko jest to moliwe, mobilnych urzdze personalnych (ang. PD Personal Devices), takich jak smartfony, palmtopy, urzdzenia typu Personal Device Assistant PDA itp. Urzdzenia te nie byy do tej pory na masow skal wykorzystywane na potrzeby IB, z kilku powodw. Po
1

Badania, ktrych wyniki s przedstawione w tym artykule, byy czciowo sfinansowane przez Ministerstwo Nauki i Szkolnictwa Wyszego z Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka projekt nr POIG.01.03.01-00-008/08.

pierwsze, nie jest technicznie moliwe ani ekonomicznie uzasadnione przygotowywanie specjalistycznego oprogramowania interfejsu dla kadej pary PD urzdzenie IB, do zainstalowania na PD. Po drugie, urzdzenia PD nie s wystarczajco wydajne, eby umoliwi wykonywania skomplikowanych zada skojarzonych z instalacj IB, takich jak na przykad analiza sygnau wideo, powiadamianie o krytycznych zmianach sytuacji, itp. Po trzecie, autoryzacja urzdze PD do pracy z konkretn instalacj IB nie jest zadaniem atwym, zwaszcza w trybie incydentalnego wykorzystania (ad-hoc). I ostatni problem urzdzenia PD wykorzystuj standardowo inne metody komunikacji, najczciej radiowej (BlueTooth, WiFi, itp.) ni urzdzenia IB (najczciej s to standardy przemysowe de-facto wymuszane przez producentw konkretnych urzdze lub ich klas). W niniejszym artykule opisujemy nowe podejcie do wykorzystania urzdze personalnych do sterowania urzdzeniami IB. W podejciu zakada si integracj trzech do tej pory rozdzielonych obszarw badawczych: zdalnej identyfikacji radiowej RFID, urzdze personalnych sieci telekomunikacyjnych oraz tak zwanych sieci osobistych, a take klasycznych interfejsw typu GUI. Gwn ide podejcia jest nowatorski, wielofazowy sposb przeprowadzenia interakcji czowieka z urzdzeniami komputerowymi. Zakadamy, e z jednej strony uytkownicy maj mie zapewniony publiczny dostp do instalacji IB, natomiast z drugiej strony, e do tego celu bd chcieli gwnie wykorzystywa swoje prywatne urzdzenia dostpowe. Do rozwizania problemu efektywnej interakcji tych urzdze proponujemy podejcie Service Oriented Architecture SOA, zakadajce automatyczn generacj interfejsu na podstawie (1) moliwoci urzdzenia, (2) funkcjonalnoci instalacji IB, (3) niezalenego kontekstu zespou parametrw opisujcych czas i miejsce interakcji, a take (4) indywidualnych wymaga i oczekiwa uytkownikw. W kolejnych rozdziaach artykuu przestawiono przegld wykorzystywanych technologii, zarwno w kontekcie IB, jak i SOA (automatyczna identyfikacja, rodki komunikacji, urzdzenia dostpowe). Nastpnie przedstawiono architektur systemu automatycznej generacji interfejsw uytkownika dla urzdze PD wykorzystywanych w publicznych instalacjach IB, opisujc take dwa przykadowe obszary zastosowa. W kocowej czci artykuu podano wnioski kocowe oraz kierunki dalszych prac. 2. Technologie wykorzystywane w inteligentnych budynkach W oglnoci, moemy rozwaa instalacj IB jako zbir rozproszonych, niezalenych jednostek sprztowych, ktre mog (aczkolwiek nie musz) by centralnie zarzdzane przez system komputerowy. Urzdzenia IB s doczane do instalacji zgodnie z wybranym standardem, np. EIB. Wybrane urzdzenia s wyposaone w dedykowany, najczciej sprztowo realizowany interfejs. W instalacji pracuj take pewne systemy oprogramowania (aplikacje), rozproszone i niezalene, uzupeniajc system o pewn cile okrelon funkcjonalno. Na przykad, w systemie jest dostpna baza danych uytkownikw i ich praw w stosunku do wybranych (grup) urzdze, s narzdzia monitorujce stan sieci i komunikacj wewntrzn i podajce statyczne obcienia w formie graficznej, itp. Jak ju wspomniano wczeniej, projektanci IB, z powodw technicznych i ekonomicznych nie s zainteresowani opracowywaniem skomplikowanych interfejsw na potrzeby wsppracy z urzdzeniami personalnymi. Dodatkowo, nie jest moliwe przewidzenie z gry wszystkich moliwych interakcji dowolnego urzdzenia IB z dowolnym urzdzeniem PD, a taka wiedza jest wymagana do zaprogramowania interfejsu. Zatem, klasyczny sposb projektowania interfejsw zawodzi. Indywidualne dopasowanie przez odpowiedni wybr i zaprogramowanie urzdze PD i IB jest moliwe, ale ograniczone do wskiego krgu technologicznych entuzjastw, ktrzy w duej mierze sami mog sobie z tym zadaniem poradzi, ale te potem sami s jednymi uytkownikami swoich rozwiza. W konsekwencji

interfejs IB jest zwykle do ubogi - tradycyjny. Na przykad, inteligentny wycznik owietlenia ma form podobn do swojego klasycznego odpowiednika, umoliwiajc manipulacj scenami wietlnymi w taki sam sposb, do jakiego jestemy ju przyzwyczajeni. Po pocztkowym momencie instalacji systemu IB, jego personalizacja w kierunku zaspokojenia indywidualnych wymaga uytkownikw czy te zmiany urzdze dostpowych jest trudna, zwaszcza w kontekcie interakcji ad-hoc. Z reguy, uytkownicy IB s wyposaani w niezmienny zestaw urzdze kontrolnych, z urzdzeniami IB pogrupowanymi w logiczne zespoy, ustalonymi komendami i moliwymi stanami systemu. Mimo i to uytkownik decyduje o uaktywnieniu lub nie wybranego urzdzenia IB, nie ma on wpywu ani na sposb sterowania urzdzeniem, ani na obszar wykorzystania, nie mwic o oglnym kontekcie (na przykad miejscu, czasie i sposobie) interakcji. W konsekwencji, uytkownicy s zmuszeni do nauki korzystania z instalacji IB. Z tego wzgldu interfejs urzdze przez moliwie jak najduszy czas nie ulega zmianie. Mona powiedzie, e to uytkownik musi dopasowa si do instalacji IB, a nie odwrotnie. 3. Podejcie SOA Odwrotne zaoenie, w stosunku do sztywnych regu systemw IB, zostao przyjte jako podstawa dziaania systemw zgodnych z architektur SOA (ang. Service-Oriented Architecture). Architektura ta nie jest cile zdefiniowana, a przykady jej zastosowania w praktyce rni si midzy sob. Najczciej uznawana definicja SOA, zaproponowana przez OASIS [1], jest nastpujca: Paradygmat dla celw organizacji i wykorzystywania rozproszonych jednostek, ktre mog by kontrolowane przez niezalene podmioty, pozwalajcy na zunifikowany sposb oferowania, wyszukiwania i wykorzystywania moliwoci partnerw w celu osignicia wymiernych, wsplnych efektw zgodnie z przyjtymi zaoeniami. W tym artykule wykorzystujemy podejcie SOA do modelowania procesw interakcji midzy elementami systemu IB. Zakadamy, e system IB oferuje pewn funkcjonalno jako zbir tak zwanych usug, dostpnych na drodze komunikacji wewntrznej (w sieci cznoci budynku) i umoliwiajcych kompozycj w celu udostpnienia pewnych aplikacji uytkownikowi. Usuga jest nie tylko prostym zbiorem okrelonych funkcji [2], jest to take (1) logiczna reprezentacja pewnej aktywnoci (ludzkiej, biznesowej, automatycznej itp.), powtarzalnej w czasie i generujcej powtarzalne wyniki, (2) niezalena i samo-kontrolujca si jednostka, ktra (3) moe by zoona z innych usug podrzdnych (struktura hierarchiczna) oraz (4) jest czarn skrzynk z punktu widzenia uytkownikw. Midzy wybranymi usugami nastpuje przepyw danych, ktry umoliwia koordynacj aktywnoci tych usug. W celu zapewnienia maksymalnej efektywnoci przepywu danych, w SOA wprowadzono szereg rozwiza organizacyjnych i architektonicznych [3], takich jak moduowo implementacji usug, autonomi i lune wizanie, zgodno standardw (komunikacja, ontologia, itp.) oraz powtarzalno wykorzystania (ang. reusability). Implementacja i wykorzystywanie usug SOA jest regulowane szeregiem standardw (oglnych i przemysowych de-facto), co pozwala na wprowadzenie katalogowania i wyszukiwania najlepszych w danej sytuacji usug do realizacji konkretnego zadania. Zaoenia SOA mog zosta wykorzystane do projektowania systemu IB, gdzie poszczeglne urzdzenia IB s podstaw implementacji specyficznych usug, komponowanych w spjne aplikacje. W takim podejciu nie ma potrzeby ustalania funkcjonalnoci systemu ju na etapie projektowania instalacji IB, co wicej, system moe by personalizowany a nawet ad-hoc przystosowywany do nowych wymaga i uytkownikw. 4. Technologie pomocnicze W celu implementacji systemu automatycznej generacji interfejsw uytkownika, naleao zintegrowa co najmniej trzy, niezwizane do tej pory z systemami IB i cakowicie

niezalenie rozwijane technologie: (1) automatyczn identyfikacj obiektw, miejsc i urzdze (GPS, RFID, WiFi, Bluetooth i podobne), (2) programowalne, mobilne urzdzenia dostpowe (smartfony, PDA, palmtopy), (3) cza komunikacyjne (zwaszcza sieci radiowe krtkiego zasigu), oraz (4) autorska metodyka przygotowania interfejsw w trybie ad-hoc i just-in-time JIT do automatycznej instalacji na wybranym urzdzeniu. W nastpnych punktach przedstawiono podstawowe cechy w/w technologii, a nastpnie bardziej szczegowo opisano proponowan w artykule now metodyk generacji interfejsw. 4.1. Automatyczna identyfikacja Standardowo, automatyczna identyfikacja opiera si gwnie na sensorach biomedycznych (n przykad czytnikach odciskw palcw) oraz dedykowanych czytnikach kart lub kluczy sprztowych. Takie podejcie wymaga wykonania okrelonych czynnoci przez uytkownika, na przykad przecignicia karty przez czytnik. W naszym podejciu zakadamy, e (1) proces autentykacji zachodzi cakowicie automatycznie, w sposb transparentny dla uytkownika, (2) autentykacja jest przeprowadzana gwnie w oparciu o urzdzenia mobilne, oraz (3) proces ten obejmuje nie tylko identyfikacj aktywnoci ludzi, moe dotyczy take szeregu parametrw oglnego kontekstu, takich jak lokalizacja, warunki otoczenia, data i czas itp. Proponujemy zastosowanie dwch technologii: zdalnej identyfikacji radiowej RFID (ang. Radio Frequency Identification) oraz detekcji pooenia stacji mobilnych w sieciach dostpu radiowego typu personalnego PAN (ang. personal-area networks). W szczeglnoci, technologia RFID wydaje si bardzo atrakcyjna w zastosowaniach IB. Technologia ta wykorzystuje programowalne znaczniki (ang. tags), zawierajce specjalizowany ukad detekcji sygnau wraz z anten, propagujce w odpowiedzi na uaktywnienie drog radiow swj identyfikator, odczytywany i dekodowany przez dedykowane czytniki RFID. W sieciach PAN do identyfikacji urzdze (na poziomie fizycznym) wykorzystuje si adresy MAC (ang. Media Access Control). Adresy te mog suy do w miar wiarygodnego uwierzytelniania urzdzenia, a porednio jego uytkownika, na przestrzeni kilkuset metrw. W przeciwiestwie do technologii RFID, autentykacja urzdze w sieciach PAN nie wymaga dedykowanych czytnikw, dodatkowo, niemal kade urzdzenie mobilne jest wyposaone w interfejs do co najmniej jednego typu sieci PAN. Jednake, autentykacja na bazie adresw MAC nie jest uwaana za bezpieczn, ze wzgldu na du podatno na ataki. Z tego wzgldu, autentykacja tego typu moe by wykorzystywana tylko w rodowiskach zamknitych lub takich, gdzie wymagania wzgldem bezpieczestwa systemu s osabione, na przykad w zastosowaniach ad-hoc. W przypadku duych wymaga odnonie stopnia bezpieczestwa systemu i danych uytkownikw, jest wskazane wykorzystanie technologii RFID. 4.2. Programowalne urzdzenia dostpowe Aby umoliwi interakcj midzy czowiekiem i urzdzeniem IB, czowieka tego naley wyposay w odpowiednie urzdzenie dostpowe, w celu zarwno dostarczania, jak i odbierania informacji generowanych w instalacji IB. W dzisiejszych instalacjach IB do interakcji wykorzystuje si przede wszystkim specjalizowane przyciski (na przykad sterownik windy) i przeczniki (na przykad panel sterowania klimatyzacj. Takie podejcie ma jedn powan wad nie jest moliwe dodawanie funkcjonalnoci, ktrej nie przewidzia instalator budynku. Jeli chcemy opracowa system, ktry dynamicznie bdzie si dopasowywa do zmian otoczenia oraz ewoluujcych wymaga uytkownikw, musimy zapewni inny, generyczny sposb przygotowania interfejsw, nieograniczony przez limitowan z koniecznoci wyobrani projektantw instalacji. Taki sposb jest znany od dawna jest to ekran komputera, na ktrym moemy wywietli wybran przez nas aplikacj, ktra steruje interakcj z uytkownikiem za porednictwem tego ekranu.

Mona sobie wyobrazi sytuacj, gdy w budynku w kluczowych miejscach umieszcza si panele oglnego dostpu do sieci urzdze IB. Takie podejcie ma jednak wiele wad. Po pierwsze, system musi autoryzowa uytkownikw za pomoc hase, kont dostpowych, kart zblieniowych itp. Po drugie, uytkownicy musz najpierw uda si do miejsca, gdzie stoi panel, eby z niego skorzysta. Nasze podejcie jest pozbawione tych wad, zakadajc wykorzystanie ekranu (i klawiatury) urzdze, ktre uytkownicy stale nosz przy sobie. Urzdzenia te zapewniaj wystarczajcy poziom autentykacji, ktry mona podwyszy instalujc dodatkowe oprogramowanie lub doczajc zminiaturyzowane moduy sprztowe. Aby urzdzenie mobilne byo efektywnie wykorzystywane, musi ono spenia kilka warunkw. Po pierwsze, ekran urzdzenia musi by na tyle duy, eby pomieci informacje wymieniane z sieci urzdze IB. Po drugie, urzdzenie musi by wyposaone w efektywn technologi wprowadzania danych, na przykad ekran dotykowy lub chociaby miniaturow klawiatur. Po trzecie, moc obliczeniowa urzdzenia i zasoby pamici musz by na tyle due, eby poradzi sobie z potencjalnie do skomplikowanymi zadaniami efektywnej prezentacji danych. Oczywicie, urzdzenie musi by take wyposaone w modu dostpu do wybranej sieci transmisji radiowej danych (PAN). Wydaje si, e optymaln klas urzdze dostpowych dla instalacji IB s urzdzenia typu PDA (ang. Personal Device Assistant). PDA s z reguy wyposaone w ekran szerokoci 3-4 cali o rozdzielczoci 800x480 pikseli, wystarczajcy dla wikszoci aplikacji, a jednoczenie swobodnie mieszczcy si w kieszeni. Procesory wykorzystywane w urzdzeniach PDA maj taktowanie szybsze ni 1 GHz oraz s wspomagane przez akceleratory graficzne (nVIDIA Tegra, Qualcomm Snapdragon), co z nadmiarem wystarcza do generacji nawet skomplikowanych interfejsw graficznych. Praktycznie kade urzdzenie PDA jest wyposaone w co najmniej jeden interfejs transmisji radiowej danych WiFi, BlueTooth, HDPA itp. Wszystkie te cechy powoduj, e PDA mog by efektywnie wykorzystywane jako urzdzenia dostpowe do sieci IB. Wyej wymienione zalety nie eliminuj powanej przeszkody w wykorzystaniu PDA jako uniwersalnych punktw dostpowych niemonoci przewidzenia wszystkich potencjalnie moliwych sposobw interakcji z urzdzeniami IB i zwizanej z tym niemoliwej do realizacji implementacji interfejsw tych urzdze na stae. W opisywanym w artykule podejciu zlikwidowano t przeszkod, zakadajc automatyczne generowanie oprogramowania na potrzeby wsppracy z urzdzeniami IB, w miar potrzeb i zmian sytuacji. Rozwizanie to opisano w kolejnym rozdziale, uzupeniajc o opis obszarw zastosowa. 5. Automatyczna generacja interfejsu dla urzdze mobilnych i staych W niniejszym artykule proponujemy nowe podejcie do automatycznej generacji, w trybie na yczenie JIT (ang. just-in-time) interfejsw dostpowych do urzdze IB, przeznaczonych do wykorzystania na urzdzeniach mobilnych uytkownikw, z uwzgldnieniem indywidualnych preferencji uytkownikw, moliwoci urzdze oraz kontekstu (na przykad lokalizacji urzdzenia w budynku). Zakadamy, e urzdzenia IB mog wchodzi w interakcj z urzdzeniami mobilnymi w nieznanym z gry miejscu, czasie i celu. Urzdzenia IB dziaaj zgodnie z architektur SOA i s dostpne za porednictwem skojarzonych z nimi usug, skadajcych si na funkcjonalno caej instalacji. Usugi IB posiadaj wiedz niezbdn do wymiany danych z uytkownikami, ale nie wiedz, jak dokona interakcji w celu wymiany tej wiedzy. Z drugiej strony, uytkownik wie, jakie cele chce osign, ale nie wie jak to zrobi jakie czynnoci wykona i jakie usugi wywoa. Zatem, jest niezbdny porednik podsystem o nazwie Transient Boundary Service TBS. TBS jest czci instalacji IB i pracuje jako proxy midzy urzdzeniami IB i personalnymi, nalecymi do uytkownikw. TBS przechwytuje dania uytkownikw, uzupenia je o dane kontekstu wywoania (na przykad miejsce interakcji, typ urzdzenia mobilnego itp.), dokonuje automatycznej identyfikacji

usugi, a nastpnie przeprowadza interakcj z wybran usug lub grup usug, pobierajc jej definicj i list wymaganych parametrw wywoania. Jeli zachodzi potrzeba uzupenienia parametrw interakcji przez uytkownika, jest generowany specjalny interfejs poboru tych danych. Po skompletowaniu, dane s wykorzystywane do wywoania usugi. Wywoanie to skutkuje wygenerowaniem odpowiedzi usugi, ktre to dane s z kolei przesane, w odpowiedniej formie, do wskazanego urzdzenia mobilnego. Naley zauway, e w oglnoci urzdzenie pobierania danych dla potrzeb konkretnej usugi nie musi by tym urzdzeniem, ktre posuy do prezentacji odpowiedzi tej usugi. Na przykad, dane mona wprowadzi z klawiatury telefonu, ale odpowied usugi bdzie wywietlona nie na ekranie tego telefonu, ale na monitorze wiszcym w pobliu na cianie. Architektur TBS pokazano na Rys.1, w podziale na podstawowe i uzupeniajce moduy funkcjonalne: Device Capabilities Provider reprezentuje wiedz o moliwych typach urzdze dostpowych, pozwalajc na okrelenie moliwoci technicznych urzdze. Wiedza ta jest reprezentowana w postaci szeregu ortogonalnych hierarchii, co pozwala na identyfikacj rnorodnych parametrw urzdzenia dostpowego. User Preferences Database jest to baza wiedzy i ontologii zwizanych z osobistymi preferencjami uytkownikw. Preferencje te, o ile jest to moliwe, optymalizuj sposb generacji interfejsu dla poszczeglnych uytkownikw. Service Interface Cues standardowo interfejs usugi jest generowany gwnie na podstawie jej opisu. W celu optymalizacji generacji mona wykorzysta pewne oglne wskazwki, okrelane przez projektanta systemu i przechowywane w tej bazie danych. Wskazwki te mog obejmowa nie tylko informacje o szczegowej hierarchii i przeznaczeniu podstawowych elementw interfejsu, ale take okrela semantyk (ontologi) tych elementw. Invocation Context Provider mimo i wikszo parametrw opisu kontekstu jest okrelana na podstawie sposobu konkretnego wywoania, niektre wartoci mog by pobierane z innych usug lub systemw zewntrznych (na przykad lokalizacja uytkownik wewntrz budynku, nadane mu prawa dostpu do urzdze itp.). Modu ICP jest wykorzystywany do pobierania i analizy takich zewntrznych danych kontekstowych. Poza czterema wyej opisanymi moduami uzupeniajcymi, TBS skada si z piciu moduw gwnych: Service Identification odpowiedzialny za identyfikacj konkretnej usugi na podstawie parametrw wywoania. Modu ten wyznacza identyfikator konkretnej usugi, lub wybiera okrelon, konkretn usug z grupy moliwych do wykorzystania, wskazanych w wywoaniu usug. Nastpnie, modu pobiera definicj wybranej usugi i sprawdza, czy w wywoaniu podano wszystkie parametry niezbdne do wywoania usugi. Brakujce wartoci parametrw s pobierane w interakcji z uytkownikiem za pomoc specjalnie wygenerowanych interfejsw. Po skompletowaniu, parametry wywoania s przekazywane do usugi, powodujc jej uaktywnienie. Session Handler modu ten reprezentuje dane sesji, co umoliwia cig wywoa usugi lub usug skadajcych si na dusz interakcj czowieka z systemem IB. W

module tym s reprezentowane tak zwane dane historyczne (czyli wane parametry poprzednich wywoa), wykorzystywane do usprawnienia interakcji w przyszoci, w szczeglnoci informacje autentykujce urzdzenie na okrelony czas. Service Response Handler modu ten odbiera dane od wywoanej usugi oraz na podstawie wskazwek otrzymanych z moduu pomocniczego Service Interface Cues przygotowuje te dane do przesania do nastpnych moduw. Abstract Interface Generator gwny modu TBS, odpowiedzialny za generacj abstrakcyjnego interfejsu na podstawie regu przygotowanych na podstawie analizy definicji usugi oraz wartoci parametrw opisujcych aktualny kontekst wywoania. Dodatkowo, podczas generacji interfejsu modu uwzgldnia indywidualne wymagania uytkownikw, o ile jest to moliwe. Interface Instantiation Plug-ins ostatni z moduw generacji interfejsu, zamienia abstrakcyjn definicj interfejsu na kod generacyjny, przesyany do konkretnego urzdzenia. Kod ten opisuje sposb realizacji interfejsu w konkretnym rodowisku programowo-sprztowym, w maksymalnym stopniu wykorzystujc dostpne technologie, takie jak HTML, Flash, Silverlight, a nawet strumieniowany sygna audio/wideo typu MPEG-4.

Rys. 1. Architektura TBS (Transparent Boundary Service) Wyej przedstawione dziewi moduw skada si na uniwersalny system generowania interfejsw do usug z uwzgldnieniem wymaga uytkownikw, moliwoci urzdze dostpowych, oraz kontekstu konkretnego wywoania. 6. Przykady zastosowania Aby pokaza moliwoci systemu automatycznej generacji interfejsw, opiszemy dwa jego obszary zastosowa: inteligentny szpital, w ktrym interakcje midzy pacjentami i lekarzami s wspomagane systemem IB, oraz e-muzeum, z interakcj ad-hoc midzy prywatnymi urzdzeniami personalnymi zwiedzajcych oraz wyposaeniem budynku i

eksponatami. Te dwa obszary nie wyczerpuj moliwoci systemu, pokazuja jednak podstawowe zalety podejcia. 6.1.Idea inteligentnego szpitala W implementacji idei inteligentnego szpitala poczynilimy nastpujce zaoenia. Kady pacjent, doktor oraz go szpitala nosz przy sobie znaczniki identyfikujce RFID. Znaczniki takie s take wykorzystywane do oznaczania kluczowych miejsc, takich jak sale i pokoje personelu, windy, a take przedmiotw, takich jak sprzt medyczny i lekarstwa. Zatem, jest moliwe: (1) ledzenie lokalizacji kadego czowieka i obiektu w budynku, (2) automatyczne autentykowanie i autoryzowanie ludzi znajdujcych si w okrelonych sytuacjach (kontekstach), na przykad ledzenie obecnoci w pokojach zarezerwowanych dla autoryzowanego personelu czy te drogi lekarstwa od magazynu do pacjenta, oraz (3) uaktywnianie alarmu gdy zasza niepodana interakcja midzy ledzonymi obiektami (na przykad okrelone lekarstwo trafio w niepowoane rce). Personel szpitala jest wyposaony w przenone urzdzenia PDA podczone do sieci lokalnej (Bluetooth i/lub WiFi) i autoryzowane za pomoc adresw MAC. Gocie mog wykorzystywa swoje telefony komrkowe, podczane za pomoc transmisji BlueTooth w trybie ad-hoc w wybranych lokalizacjach. Dodatkowo, w niektrych miejscach znajduj si publiczne urzdzenia powszechnego dostpu, z limitowan autoryzacj dostpu do kluczowych danych szpitala. Na przykad, mog to by due monitory LCD wiszce na cianie, automatyczne drzwi otwierajce si na yczenie personelu, urzdzenia medyczne (na przykad respiratory) itp. Wyobramy sobie, e jeden z pacjentw ma by przetransportowany w inne miejsce. Jeden z lekarzy zgasza takie danie do systemu. System identyfikuje aktualn lokalizacj i stan pacjenta, a nastpnie sprawdza dostpno personelu pomocniczego. Najbliszy miejsca aktualnego przebywania pacjenta pielgniarz jest identyfikowany i powiadamiany, przy czym na jego urzdzenie PDA jest wysyana nowa lokalizacja pacjenta wraz z jego danymi. Postp transferu jest automatycznie monitorowany, co moe by poczone z pewnymi uatwieniami, na przykad automatycznym otwieraniem drzwi lub przywoywaniem windy. Po przeniesieniu pacjenta do lekarza jest przesyane odpowiednie powiadomienie. Natomiast gdy zajdzie zdarzenie nieprzewidziane i transfer ulegnie przerwaniu, lekarz otrzymuje alert z prob o interwencj. Wyobramy sobie, e pacjent powinien otrzyma lekarstwo. Lekarstwo to jest identyfikowane, a stosowne danie jest adresowane do personelu szpitala. Pielgniarka ktra podaje lekarstwo wie komu je poda, ale niekoniecznie co to jest, co zwiksza stopie prywatnoci leczenia przy niezmienionym poziomie bezpieczestwa i nadzoru. Jednoczenie, moliwo popenienia bdu przez czowieka jest ograniczona do minimum, dziki cigemu ledzeniu pozycji pacjenta, lekarstwa i pielgniarki. Wyobramy sobie gocia, ktry chce odwiedzi konkretnego pacjenta. Przy wejciu do budynku jest informowany, e moe skorzysta ze swojego telefonu komrkowego w celu wymiany danych ze szpitalem. Jeli to nie jest jego pierwsza wizyta, adres MAC urzdzenia personalnego moe posuy do wykrycia tego faktu i wzbogacenia kontekstu wywoania usug o dane z poprzednich interakcji (na przykad nazwisko pacjenta). Po akceptacji, go moe si podczy do sieci lokalnej szpitala i otrzyma dostp do wybranych usug, z automatycznie generowanym interfejsem dostpowym. Jeli go nie korzysta z urzdzenia klasy PDA, a tylko z typowego telefonu komrkowego z interfejsem Bluetooth, na podstawie analizy pooenia mona okreli, czy w pobliu znajduje si efektywniejsze urzdzenie dostpowe, na przykad publiczny panel dostpowy, a nastpnie przekierowa wybrane informacje do tego urzdzenia. Jednoczenie, pozycja gocia moe by na bieco ledzona przez personel szpitala.

Wyobramy sobie na kocu lekarza, ktry chciaby nagle skorzysta ze specjalistycznego sprztu. Wystarczy e wyle on odpowiednie danie do systemu, ktry albo poprowadzi go do najbliszego sprawnego urzdzenia, albo odpowiednio poinstruuje personel, tak eby urzdzenie zostao jak najszybciej dostarczone. 6.2.Interaktywne muzeum Dla celw implementacji idei e-muzeum zaoylimy, e kady zwiedzajcy na czas wizyty otrzymuje urzdzenie PDA, ktre jest jednoczenie: (1) biletem do muzeum, (2) rodkiem patniczym za konkretne usugi (ang. pay-for-what-you-see), (3) urzdzeniem ledzcym, oraz (4) wielojzycznym przewodnikiem. PDA suy jako bilet, gdy jest przekazywane kademu zwiedzajcemu z uruchomion dedykowan aplikacj obsugi zwiedzajcych. Funkcjonalno tej aplikacji nie moe zosta zmieniona, ale interfejsy z poszczeglnymi obiektami muzealnymi s generowane na yczenie, w miar jak zwiedzajcy zmienia swoje pooenie. Interfejsy te s dostosowane do indywidualnych preferencji, okrelonych na pocztku (jzyk komunikacji, rozmiar i kolor fontu, komunikaty sowne/wizualne, sugerowany czas zwiedzania i cieka, itp.) PDA peni zatem rol indywidualnego, interaktywnego przewodnika. Funkcjonalno systemu moe by wzbogacona o obrbk danych kontekstowych, na przykad jeli zwiedzajcy zatrzyma si w jednym miejscu na duej, jest mu oferowana moliwo dokadniejszego zapoznania si z pobliskimi eksponatami. PDA moe dodatkowo suy do sugerowania cieki zwiedzania, na przykad na podstawie ycze uytkownika lub na podstawie statystycznej analizy zachowa innych zwiedzajcych (Mam godzin, poka mi najbardziej interesujce eksponaty). Pozycje PDA (porednio zwiedzajcych) s na bieco monitorowane przez personel muzeum, z podnoszeniem alarmu gdy dane urzdzenie przestao si porusza (zwiedzajcy zasab lub zgubi urzdzenie?), automatycznym otwieraniem drzwi dla osb, ktre zapaciy za ogldnicie specjalnych wystaw, itp. 7. Wnioski kocowe Wraz ze wzrostem stopni skomplikowania instalacji inteligentnych budynkw szybko dochodzimy do sytuacji, w ktrej podczone na stae urzdzenia IB przestaj wystarcza. W miar jak narasta tendencja do lepszego dopasowania funkcjonalnoci IB do potrzeb i wymaga uytkownikw, wczajc uytkownikw incydentalnych oraz niezaawansowanych, interfejs midzy urzdzeniami IB i uytkownikami musi by coraz bardziej zindywidualizowany. W artykule pokazano generyczny system umoliwiajcy dopasowanie sposobu interakcji uytkownikw z budynkiem z wykorzystaniem personalnych urzdze mobilnych. Interfejsy opisujce takie interakcje s automatycznie generowane na podstawie aktualnego kontekstu (na przykad lokalizacji, temperatury, czasu itp.), indywidualnych wymaga, moliwoci urzdzenia dostpowego oraz funkcjonalnoci instalacji IB. System czy zalety wielu do tej pory niezalenie rozwijanych technologii: autoryzacji RFID, urzdze IB, podejcia SOA, sieci personalnych oraz nowej generacji urzdze mobilnych, takich jak PDA. System moe by wykorzystywany w wielu obszarach zastosowa, wczajc szpitale, muzea, budynki administracji publicznej, a nawet prywatne domy. Literatura [1] OASIS Reference Model for Service Oriented Architecture 1.0, Official OASIS Standard, Oct. 12, 2006, http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf [2] The Open Group , SOA Documents, Definition of SOA, Jun. 8, 2006, http://opengroup.org/projects/soa/doc.tpl?gdid=10632 [3] Yvonne Balzer, Improve your SOA project plans, IBM, Jul. 16, 2004, http://www.ibm.com/developerworks/webservices/library/ws-improvesoa/

[4] What is RFID, RFID Journal, http://www.rfidjournal.com/.article/articleview/1339/1/129