SlideShare uma empresa Scribd logo

System inteligentnej nawigacji sterowanej głosem po serwisie internetowym

•
•
J
Jan Klimczak
1 de 120
Baixar para ler offline
Gdańsk, wrzesień 2011 POLITECHNIKA GDAŃSKA Wydział Elektroniki Telekomunikacji i Informatyki Katedra Systemów Decyzyjnych Imię i nazwisko dyplomanta: Jan Klimczak Nr albumu: 112006 Forma i poziom studiów: niestacjonarne inżynierskie Kierunek studiów: Informatyka Praca dyplomowa inżynierska Temat pracy: System inteligentnej nawigacji sterowanej głosem po serwisie internetowym Intelligent web navigation voice controlled system Kierujący pracą: prof. dr hab. inż. Zdzisław Kowalczuk Recenzent: Zakres pracy: Opracowanie głosowego systemu komunikacji oraz nawigacji po serwisie internetowym. Projekt zakłada wykonanie portalu testowego, systemu rozpoznawania i generowania mowy, mózgu systemu oraz postaci Awatara komunikującego się z użytkownikami oraz kierującego ich po serwisie. System ma być inteligentny w tym znaczeniu, iż Awatar nie będzie nas tylko słuchał, ale także będzie z nami w dialogu wyrażając się poprzez swoje emocje. Wykonanie projektu zakłada komunikację w języku angielskim. Nr raportu:
....................................................... Imię i nazwisko dyplomanta 1.1.1. OŚWIADCZENIE Oświadczam, że: 1) niniejszą pracę dyplomową wykonałem samodzielnie, 2) wszystkie informacje umieszczone w pracy uzyskane ze źródeł pisanych oraz informacje ustne pochodzące od innych osób zostały udokumentowane w wykazie literatury odpowiednimi odnośnikami. ................................................. podpis dyplomanta
Spis treści 1.1.1. OŚWIADCZENIE.....................................................................................................3 2. CEL PRACY ORAZ ROZPOZNANIE TECHNOLOGII..........................................................9 2.1. Wprowadzenie..................................................................................................................9 2.2. Założenia ogólne...............................................................................................................9 2.3. Przegląd istniejących technologii ...................................................................................10 2.3.1. Systemy mowy........................................................................................................10 2.3.2. Systemy Java Speech ..............................................................................................10 2.3.3. Systemy Microsoft Speech......................................................................................11 2.3.4. Systemy rozpoznawania mowy...............................................................................11 2.3.5. Systemy syntezy mowy...........................................................................................11 2.3.6. Przegląd istniejących systemów mowy...................................................................12 2.4. Serwery obsługujące protokół czasu rzeczywistego ......................................................14 2.5. Specyfikacja techniczna .................................................................................................15 2.6. Podsumowanie................................................................................................................17 3. SPRECYZOWANIE WYMAGAŃ FUNKCJONALNYCH....................................................18 3.1. Wprowadzenie................................................................................................................18 3.2. Przeznaczenie systemu ...................................................................................................19 3.3. Funkcja ...........................................................................................................................20 3.4. Podsumowanie................................................................................................................21 4. ZASADA DZIAŁANIA ORAZ OPIS SYSTEMU ..................................................................22 4.1. Wprowadzenie................................................................................................................22 4.2. Architektura systemu......................................................................................................22 4.3. Algorytm działania systemu...........................................................................................25 4.3.1. Przygotowanie systemu mowy................................................................................25 4.3.2. Podłączenie klienta..................................................................................................26 4.3.3. Wygenerowanie mowy i jej odsłuchanie przez użytkownika .................................28 4.3.4. Rozpoznanie wydanej komendy głosowej ..............................................................31 4.3.5. Mózg........................................................................................................................32 4.3.6. Stan (emocje)...........................................................................................................32 4.4. Opis wyników.................................................................................................................33 4.5. Struktura oprogramowania .............................................................................................33 4.6. Podsumowanie................................................................................................................34 5. REALIZACJA PRACY ............................................................................................................35 5.1. Wprowadzenie................................................................................................................35 5.2. Testowanie platformy.....................................................................................................36 5.3. Omówienie sposobów rozwiązania problemów.............................................................36
5.4. Podsumowanie................................................................................................................36 6. MOŻLIWOŚCI ROZWOJU SYSTEMU .................................................................................37 6.1. Wprowadzenie................................................................................................................37 6.2. Rozwój klienta................................................................................................................37 6.3. Rozwój systemu generowania mowy.............................................................................37 6.4. Rozwój systemu rozpoznawania mowy .........................................................................38 6.5. Rozwój postaci Awatara.................................................................................................38 6.6. Rozwój Mózgu ...............................................................................................................38 6.7. Podsumowanie................................................................................................................38 7. PODSUMOWANIE ORAZ WNIOSKI Z PRACY..................................................................39 7.1. Podsumowanie oraz wnioski z pracy .............................................................................39 8. Dodatek 1. Skrótowy opis aplikacji .......................................................................................... 40 Tytuł dyplomu........................................................................................................................... 40 Cel i przeznaczenie aplikacji.....................................................................................................40 Funkcjonalność ......................................................................................................................... 40 Opis realizowanych funkcji...................................................................................................40 Lista przykładowych zastosowań .......................................................................................... 41 Szczegółowe opisy działania aplikacji..................................................................................41 Architektura sprzętu..................................................................................................................42 Architektura oprogramowania ..................................................................................................42 Opis metody wytwarzania aplikacji.......................................................................................... 44 Założenia i sformułowane zadania .......................................................................................45 Specyfikacje........................................................................................................................... 45 Przygotowanie projektu ........................................................................................................45 Prototypowanie i implementacja .......................................................................................... 46 Testowanie ............................................................................................................................ 46 Ocena aplikacji oraz porównanie do innych rozwiązań.......................................................46 Wnioski i perspektywy dalszych prac....................................................................................46 9. Dodatek 2. Instrukcja dla użytkownika.....................................................................................47 Przygotowanie do pracy z systemem....................................................................................47 Komendy sterujące pracą systemu........................................................................................ 50 Lokalne ustawienia systemu .................................................................................................51 10. Dodatek 3. Instrukcja dla administratora ................................................................................52 System znaczników...............................................................................................................52 Mapa strony – sitemap ..........................................................................................................54 Panel administracyjny...........................................................................................................54 Edycja generowanych odpowiedzi z systemu – Avatar Speech ...........................................54 Generator treści systemu.......................................................................................................56
Podgląd zawartości wygenerowanej bazy danych na bazie znaczników..............................57 Instrukcja wdrożenia systemu ...............................................................................................57 11. Dodatek 4. Instrukcja dla programisty....................................................................................59 Budowa bazy danych ................................................................................................................59 Specyfikacja komunikacji z Mózgiem ......................................................................................60 Klient (ActionScript) – diagram klas ....................................................................................61 Serwer Mowy (JavaEE)– diagram klas.................................................................................62 System znaczników...................................................................................................................63 Dodanie postaci Awatara ..........................................................................................................64 Konfiguracja systemu rozpoznawania i generowania mowy....................................................66 12. Dodatek 5. Listing kodów źródłowych głównych modułów ..................................................67 Serwer mowy - SpeechServer ...................................................................................................67 Klient - SpeechAvatar ...............................................................................................................82 Model danych – SpeechModel..................................................................................................96 Mózg – BrainService...............................................................................................................100 Administrator – Administrator................................................................................................104 Portal demonstarcyjny – PortalPG..........................................................................................111 13. Bibliografia............................................................................................................................118
2 2.CEL PRACY ORAZ ROZPOZNANIE TECHNOLOGII 2.1. Wprowadzenie Niniejszy projekt ma za zadanie przegląd oraz scalenie istniejących rozwiązań, które umożliwiają sterowanie portalem internetowym za pomocą głosu. Użytkownik otrzymuje możliwość wydawania komend głosowych, a także zapytań odnośnie zawartości portalu. System w odpowiedzi na komendy generuje komunikaty głosowe, które udzielą odpowiedzi na zadane pytania. System także może przenosić użytkownika w inne miejsce portalu, o które prosimy wydając komendy. Do interakcji użytkownika z portalem została utworzona postać Inteligentnego Awatara (ang. Intelligent Avatar) [1], która umożliwia interakcję głosową z systemem. Awatar jest wrażliwy na to co i jak mówimy, posiada swoje emocje, które są uwidocznione podczas komunikacji. Największym wyzwaniem stojącym przy realizacji projektu jest jego rozproszona praca, która umożliwia niezależne sterowanie portalem dla wielu użytkowników jednocześnie poprzez przeglądarkę internetową pracując w trybie on-line1 bez potrzeby zalogowania się do systemu oraz zastosowany silnik sztucznej inteligencji2 i emocji3 postaci Awatara, która pamięta użytkownika i swój stan podczas przeglądania portalu. 2.2. Założenia ogólne Ze względu na skomplikowanie języka polskiego, czego wynikiem jest praktyczny brak implementacji tego języka dla technologii mowy (ang. Speech) (rozpoznawania i syntezy mowy) [2] przedstawiony projekt został wykonany wyłącznie w języku angielskim, co nie wyklucza dalszej jego rozbudowy o kolejne języki w przyszłości. Zakłada się kontynuację pracy oraz dalszy rozwój platformy po ukończeniu projektu, tak więc została zapewniona jego dalsza rozbudowa w sposób mało inwazyjny oraz praktycznie niezależny dla każdego z modułów. 1 W trybie połączonym z Internetem. 2 Moduł nazwany „Mózgiem” niniejszej platformy. 3 Emocje identyfikują stan Awatara, który jest indywidualny dla każdego użytkownika portalu internetowego.
1. Cel pracy oraz rozpoznanie technologii 10 2.3. Przegląd istniejących technologii Sporządzony przegląd zawiera zestawienie istniejących technologii, które zostały uwzględnione w fazie analizy wykonania projektu w obszarze rozpoznawania i generowania mowy. 2.3.1. Systemy mowy Technologie rozpoznawania i syntezy mowy są od wielu lat rozwijane. Jednak semantyka i struktura języka ludzkiego są na tyle skomplikowane, iż obecnie pomimo wielu lat rozwoju nie ma żadnego istniejącego rozwiązania, które było by idealne lub bardzo zadowalające w tym zakresie4 . Wiele projektów zostało albo skomercjonalizowanych5 i obecnie są dostępne do zakupienia po wygórowanych cenach mimo, iż nie oferują fantastycznych rezultatów6 , albo zostało zaprzestanych w rozwoju z różnych powodów7 . Pod pojęciem systemu mowy (ang. Speech) wyróżniamy rozwiązania, które w mniejszym lub większym stopniu umożliwiają rozpoznanie mowy (ang. Speech Recognition) [3] lub/i jej syntezę, czyli wygenerowanie mowy na podstawie tekstu (ang. Speech Synthesis) [4] za pośrednictwem własnych bibliotek oraz ich interfejsów API. W tym obszarze możemy wyróżnić dwa czołowe rozwiązania: system mowy firmy Microsoft (ang. Microsoft Speech) [5] oraz system mowy Java (ang. Java Speech) [6]. Praktycznie wszystkie obecne rozwiązania na nich bazują. Dzięki nim otrzymujemy dostęp do framework'u, który umożliwia nam ich swobodne zastosowanie. Oczywiście na rynku istnieją inne rozwiązania, ale zazwyczaj są one przeznaczone do ściśle określonych celów, a sama ich licencja oraz brak dostępu do ich kodu uniemożliwia szersze ich wykorzystanie. 2.3.2. Systemy Java Speech Java Speech API (ang. Java Speech Application Programming Interface, JSAPI) [7] umożliwia wykorzystanie systemu mowy (ang. Speech) w między-platformowych aplikacjach opierających się na technologii Java [8]. Dzięki zastosowaniu JSAPI otrzymujemy obsługę komend i kontroli aplikacji poprzez rozpoznawanie mowy, system obsługujący gramatykę (ang. Dictation System) [9] oraz syntezer mowy (ang. Speech Synthesis) dla rozwiązań osobistych lub klasy korporacyjnej. Java Speech API obsługuje rozpoznawanie oraz syntezę mowy. Podstawową korzyścią korzystania z technologii Java jest to, iż otrzymujemy rozwiązanie z otwartym dostępem do kodu (ang. Open Source) [10] oraz pełną zgodność między- platformową (możliwość uruchomienia aplikacji na wielu platformach, w tym.: Microsoft, Macintosh oraz Linux, ang. Cross-Platform) praktycznie bez wykonywania dodatkowej pracy w tym zakresie. Java Speech API zostało utworzone przez SUN Microsystems, obecnie Oracle Corporation [11] przy współpracy z przodującymi na tamte czasy firmami8 , które zajmowały się systemami rozpoznawania mowy: Apple Computers, Inc. [12] , AT&T [13], Dragon System, Inc. [14], IBM Corporation [15], Novell, Inc. [16], Philips [17], Texas Instruments [18]. 4 W znaczeniu poprawności rozpoznawania i generowania mowy. 5 Rozwijanych przez firmy i odsprzedawanych po wygórowanych cenach. 6 Pomimo wielu lat rozwoju nie ma obecnie takiego systemu, który zastąpił by człowieka. 7 Większość rozwijanych projektów realizowana była przez uczelnie, jednak wiele z nich zostało zakończonych i nie jest już rozwijana. 8 Dotyczy to lat 80-90 bieżącego stulecia.
1. Cel pracy oraz rozpoznanie technologii 11 Pierwsza wersja Java Speech API została utworzona i zaakceptowana w 1998 roku. Od tego też czasu nic się w niej nie zmieniło, nie była także modernizowana. Obecnie tylko różne jej implementacje są rozwijane. W 2001 roku rozpoczęto prace nad specyfikacją Java Speech API 2 (ang. JSAPI 2) dostępną jako zgłoszenie JSR 113 (ang. Java Specification Request: JavaTM Speech API 2.0) [19]. Pace nad nią trwały przez 8 lat. Jedną z głównych korzyści będzie zgodność z zaproponowanym frameworkiem mowy dla przeglądarek internetowych przez W3C9 (ang. W3C Speech Interface Framework) [20] poprzez zastosowanie znaczników HTML bezpośrednio na stronie internetowej oraz kompatybilność z interfejsem programowania systemu mowy (ang. Speech Application Programming Interface) [21] wywodzącym się z Microsoft’u. Jednak na JSAPI 2 musimy jeszcze troszkę poczekać ponieważ do dnia dzisiejszego nie ma praktycznie żadnej działającej implementacji gotowej do wdrożenia i zastosowania. 2.3.3. Systemy Microsoft Speech Microsoft posiada dobrze rozwinięty system mowy. Na jego stronie „Microsoft Tellme speech innovation” [22] zostały dobrze opisane technologie przez niego wspierane. Technologie te pozwalają na rozpoznawanie oraz generowanie mowy (ang. Speech Synthesis and Recognition) w wielu językach. Dodatkowo za pomocą komend głosowych można sterować systemem operacyjnym Windows oraz wybranymi aplikacjami. Jednak ograniczenia licencyjne na wykorzystanie tego systemu mowy wykluczyła wykorzystanie tego rozwiązania w wykonywanym projekcie. 2.3.4. Systemy rozpoznawania mowy Od wielu dziesięcioleci ludzie próbują sterować urządzeniami za pomocą głosu. Ze względu na skomplikowanie ludzkiej mowy pierwsze systemy pozwalały wyłącznie na rozpoznawanie cyfr. W 1952 roku Bell Laboratories [23] zaprojektował system „Audrey”, który rozpoznawał cyfry. Dziesięć lat później IBM zaprezentował swoją maszynę „Shoebox” [24], która rozpoznawała 16 słów w języku angielskim. Następnie w latach 70 bieżącego wieku powstały pierwsze systemy pozwalające rozpoznać tysiące słów, w latach 80 ta liczba rozpoznawanych słów została już przekroczona. W latach 90 firma Dragon wprowadziła do sprzedaży pierwszy produkt rozpoznawania mowy Dragon Dictate w cenie 9000$. Siedem lat później produkt znacznie udoskonalony o nazwie Dragon NaturallySpeaking umożliwiający płynne rozpoznawanie mowy o szybkości 100 słów na minutę został udostępniony w cenie ok. 700$. Od 2000 roku systemy te szczycą się 80 % poprawnością rozpoznawania mowy. Także od tego czasu możliwości wydawania komend głosowych zostały zaimplementowane do systemów operacyjnych Microsoft Vista oraz MacOS oraz do wielu telefonów komórkowych [25]. 2.3.5. Systemy syntezy mowy Synteza mowy polega na zamianie tekstu na mowę (ang. Text To Speech, TTS) [26]. Systemy te ocenia się na podstawie poprawności i zrozumiałości wygenerowanej mowy, która powinna być zrozumiała przez człowieka. Z roku na rok systemy te są bardziej dopracowane, jednak na dzień dzisiejszy daleko jest im do doskonałości. 9 Dokument ten na dzień dzisiejszy znajduje się w wersji roboczej.
1. Cel pracy oraz rozpoznanie technologii 12 2.3.6. Przegląd istniejących systemów mowy Na rynku istnieje wiele systemów mowy (ang. Speech). Niektóre z nich lepiej sobie radzą, a niektóre gorzej z rozpoznawaniem i syntezą mowy (ang. Speech Recognition and Synthesis). Wiele z nich, szczególnie tych dopracowanych występuje w wersji komercyjnej, za którą trzeba płacić (patrz tab. 1.1.). Większość z tych systemów przedstawia dość wysoki poziom generowanej i rozpoznawanej mowy. Jednak ze względu na wysokie koszty nie zostały one uwzględnione przy realizacji niniejszego projektu. Tab. 2.1. Wybrane komercyjne systemy mowy. l.p. nazwa cena rodzaj 1. Dragon Medical od 1200$ synteza i rozpoznawanie mowy 2. Dragon NaturallySpeaking od 30$ za wersję pod system operacyjny synteza i rozpoznawanie mowy 3. Cloud Garden, Talking Java SDK 500$ za serwer (z ograniczeniami) synteza mowy 4. Acapela box (Elan Speech Cube) 300€ za godzinę synteza mowy 5. Lumen Vox od 1500$ rozpoznawanie mowy 6. Ivona od 29€ synteza mowy Dragon Medical [26] oferuje jedne z najbardziej zaawansowanych możliwości rozpoznawania i syntezy głosu. Jest on przeznaczony dla lekarzy, którzy mogą za jego pośrednictwem szybko tworzyć raporty medyczne lub przeszukiwać bazy danych. Jest to możliwe dzięki bardzo dobremu systemowi rozpoznawania tekstu, pełnego zakresu słownictwa medycznego, technicznego a także sprawności działania, pozwalającej na pracę niemal w czasie rzeczywistym z systemem. Drugim według mnie najlepszym systemem mowy jest Dragon NaturallySpeaking [27]. Jest on już przeznaczony dla przeciętnego użytkownika. Pozwala on m. in. na pisanie oraz edycję dokumentów tekstowych, e-maili, uruchamianie aplikacji i plików, kontrolowanie myszki oraz pomaga przy wielu innych czynnościach związanych z codzienną pracą użytkownika z komputerem. Cloud Garden, Talking Java SDK [28] jest już implementacją JSAPI, która korzysta z SAPI Microsoftu, tak więc możliwe wykorzystanie jest wyłącznie pod platformą Windows. Jak nazwa wskazuje jest to SDK (ang. Software Development Kit), które umożliwia praktycznie dowolną implementację systemu. Acapela box (Elan Speech Cube) [29] jest generatorem mowy, który pobiera opłaty w zależności od czasu generacji mowy. Actapela udostępnia nam swój serwer, do którego się łączymy, generujemy na nim mowę i odbieramy ją z powrotem. Za poprawność pracy całości odpowiada firma, jednak tylko też ona może dalej rozwijać swój produkt. Lumen Vox [30] jest firmą, która specjalizuje się w tworzeniu systemów generowania mowy wysokiej jakości. Ich produkt Lumen Vox zdobył wiele nagród i wyróżnień w kategorii rozpoznawania mowy. Jednak sama jego cena wskazuje na jego profesjonalne zastosowanie. Na koniec pozostawiłem nasz rodowity produkt o bardzo wysokiej jakości Ivona [31], który generuje mowę o bardzo wysokiej jakości. Ivona może poszczycić się generacją bardzo wysokiej klasy głosu w języku polskim. Posiada ona wiele sposobów licencjonowania, tak więc dostosowana jest zarówno pod przeciętnego klienta jak i korporacji.
1. Cel pracy oraz rozpoznanie technologii 13 Większość rozwiązań typu Open Source10 przedstawia niestety tylko dobry lub zadawalający poziom wygenerowanej mowy (patrz tab. 1.2). Wiele z nich korzysta z SAPI Microsoftu, co dyskwalifikuje je do wykorzystania w projekcie. Tutaj praktycznie tylko dwa rozwiązania wybijają się spośród dostępnych implementacji: Sphinx oraz FreeTTS. Charakteryzują się one znacznie lepszą jakością generowanej i rozpoznawanej mowy oraz lepszą dokumentacją i większą funkcjonalnością. Niewątpliwie w tym sektorze są liderami. Jednak w odróżnieniu od komercyjnych systemów tego typu są to wyłącznie biblioteki, które wymagają utworzenia własnej implementacji, gdzie często rozwiązania komercyjne oferują nam kompletny produkt. Tab. 2.2. Wybrane systemy mowy typu Open Source. l.p. Nazwa rodzaj 1. Sphinx-4 rozpoznawanie mowy 2. e-Speaking rozpoznawanie mowy (wymaga SAPI) 3. FreeTTS synteza mowy 4. Flite synteza mowy 5. Festival synteza mowy 6. FestVox synteza mowy Sphinx-4 [32] jest najbardziej zaawansowanym systemem rozpoznawania mowy dostępnym jako Open Source. Został on w całości napisany w języku Java poprzez współpracę Sphinx group na Uniwersytecie Carnegie Mellon, Sun Microsystems Laboratories (obecnie Oracle), Mitsubishi Electric Research Labs (MERL) oraz Hewlett Packard (HP) przy współpracy z Uniwersytetem California w Santa Cruz (UCSC) i Massachusetts Institute of Technology (MIT). System ten rozwijany jest od wielu lat oraz posiada możliwości rozpoznawania pojedynczych komand jak i zarówno całych sekwencji zdań. Umożliwia on podpięcie wielu modeli języka naturalnego11 w wielu różnych formatach. Posiada bogatą dokumentację oraz wiele możliwości podpinania sygnału audio. System e-Speaking [33] jest przykładem zastosowania SAPI Microsoftu, którego wymaga do pracy. Posiada on ok. 100 wbudowanych komand do interakcji z systemem operacyjnym. Obsługuje zarówno Windows 2000 jak i Windows XP. Integruje się z pakietem Microsoft Office. FreeTTS [34] z pośród wszystkich tu obecnych otwartych platform pod względem generowania mowy bije konkurencję na głowę. Obsługuje wiele głosów, wraz z możliwością ich dodawania. Częściowo wspiera standard JSAPI 1.0. Posiada dobrą dokumentację oraz wiele interfejsów, które pozwalają na integrację tego systemu w innych modułach. Został on w całości napisany w języku Java, jednak opiera się on na Flite [35] małym, szybkim, pracującym niemal w czasie rzeczywistym generatorze mowy w całości napisanym w języku C na Uniwersytecie Carnegie Mellon. Flite wywodzi się z systemu rozpoznawania mowy Festival [36] i projektu FestVox [37], które nie są już tak funkcjonalne i zaawansowane jak FreeTTS, jednak odznaczają się wyższą sprawnością. Możemy wyróżnić tutaj trzeci typ systemów mowy. Mianowicie systemy on-line, do których możemy podłączyć się za pośrednictwem interfejsów programistycznych (ang. Application Programming Interface, API). Opierają się one najczęściej na systemach, a w zasadzie bibliotekach opisanych w tab. 1.2. Są to proste rozwiązania, nie pamiętają stanu, nie posiadają 10 Dostępnych bez opłat z dostępem do kodu źródłowego. 11 Model określa listę słów i sentencji do rozpoznania.
1. Cel pracy oraz rozpoznanie technologii 14 własnej logiki, tylko po prostu generują mowę na bazie podanego tekstu lub rozpoznają wydawane komendy (patrz tab. 1.3). Najbardziej one pasują do tworzonego tutaj systemu, ale nie mogą w nim jednak być użyte ze względu na swoje ograniczenia. Tab. 2.3. Wybrane systemy mowy on-line. l.p. nazwa rodzaj adres www 1. SpeechAPI rozpoznawanie mowy http://speechapi.com/ 2. Ivona synteza mowy http://www.ivona.com/en/ 3. AT&T Natural Voices® Text- to-Speech Demo synteza mowy http://www2.research.att.com/~ttsweb /tts/demo.php 4. Festvox synteza mowy http://festvox.org/voicedemos.html 5. Festival Text-to-Speech Online Demo synteza mowy http://www.cstr.ed.ac.uk/projects/festi val/onlinedemo.html 6. Demo Cepstral Voices synteza mowy http://cepstral.com/demos/ 7. I Online Text to Speech Synthesizer synteza mowy http://codewelt.com/proj/speak 8. vozMe synteza mowy http://vozme.com/index.php?lang=en SpeechAPI jest systemem on-line umożliwiającym użytkownikowi Internetu na wypowiadanie komend oraz czytanie tekstu, który następnie jest rozpoznawany przez system. Internauta ma do dyspozycji wyłącznie jedną stronę (właściwie kilka podstron) na której wypowiada komendy. System ten jest interfejsem programistycznym (ang. API) do którego można podłączyć się za pomocą różnych technologii, w tym: Java Script, Java12 , PHP, Python, Rubby, Web Services oraz CLI (ang. Command Line Interface). Tak więc jest to system zamknięty, wysyłajcy żądanie zawierające nagrany głos do rozpoznania, natomiast w odpowiedzi otrzymujemy rozpoznaną komendę w formie tekstu. Poprzez obsługę wielu technologii wydaje się być ciekawym rozwiązaniem na rynku. Niestety w 2011 roku prace nad tym systemem bardzo zmalały także na chwilę obecną ciężko jest przewidzieć jego przyszłość. Także wykonane testy podczas rozpoznania, które nierzadko kończyły się niepowodzeniem oraz brak udostępnienia kodu źródłowego do wykonania potrzebnych poprawek wykluczyły ten system do wykorzystania w tworzonym projekcie. Ivona udostępniła raczej demonstracyjny panel zamiany tekstu w głos. Można w nim podać dość krótki fragment, który zostanie zamieniony w głos. Jednak wyróżnia się ona sporą listą dostępnych języków oraz bardzo wysoką jakością generowanego dźwięku. Pozostałe systemy on-line zaprezentowane w tab. 1.3. posiadają bardzo ograniczone, nazwałbym je podstawowe funkcje generowania mowy, jednak pozwalają one na jej wygenerowanie w przeglądarce internetowej. 2.4. Serwery obsługujące protokół czasu rzeczywistego Ponieważ wykonany system ma pracować w Internecie użytkownik nie powinien czekać zbyt długo na reakcję ze strony systemu. W tym celu do wykonania systemu został wykorzystany serwer obsługujący protokół czasu rzeczywistego (ang. Real-Time Messaging Protocol, RTMP) [38] utworzony przez Adobe [39]. W naszym przypadku protokół ten przesyła dane audio w taki sposób, że użytkownik nie musi czekać na wcześniejszy zapis lub zbuforowanie tych danych, 12 Na chwilę pisania tego rozdziału Java nie była jeszcze dostępna.
1. Cel pracy oraz rozpoznanie technologii 15 tylko bezpośrednio może z tych danych fragment po fragmencie wykorzystać. Zastosowanie tego protokołu znacznie przyśpieszyło interakcję użytkownika z systemem. Serwery te potocznie są zwane albo serwerami strumieniowymi albo serwerami czasu rzeczywistego. Jako, że protokół ten został utworzony przez firmę Adobe także serwery tej firmy obecnie są najbardziej zaawansowane, dopracowane i stabilne, ale także i kosztują sporo. W Adobe możemy wyróżnić serwer Flash Media Server [40] oraz LiveCycle DS. [41]. Oba prezentują najwyższą półkę oraz zapewniają wysoką stabilność i dokumentację. Na drugim horyzoncie znajduje się serwer Wowza Media Server [42], który jest praktycznie odpowiednikiem tego z Adobe. Natomiast z wielu rozwiązań typu Open Source praktycznie tylko jedno się liczy, mianowicie serwer Red5 [43], który wykonany został w technologii Java. Jest to taki mniejszy brat Adobe Flash Media Server. Na początku 2011 roku został zaprezentowany kandydat na wersję 1.0. Jednak od tego czasu serwer ten boryka się z wieloma różnymi problemami, które uniemożliwiły wydanie jego wersji 1.0. Po dopracowaniu myślę, że będzie to solidny serwer, jednak na dzień dzisiejszy posiada on bardzo skromną dokumentację i wiele elementów trzeba samemu się domyślać jak je wykonać. Jednak najważniejszą cechą tego serwera jest fakt, iż występuje on jako Open Source, jest dostępny bez opłat licencyjnych (natomiast jego konkurenci są wysoko wyceniani) i co najważniejsze obsługuje protokół RTMP. Serwery tego typu tworzą gniazda na odpowiednich portach (dla RTMP zwykle jest to port 1935) poprzez które następuje transmisja danych w czasie rzeczywistym. Takie połączenie w przypadku stron internetowych następuje właśnie poprzez protokół RTMP. 2.5. Specyfikacja techniczna Ze względu na dalszy rozwój projektu przez uczelnię Politechniki Gdańskiej, Katedrę Systemów Decyzyjnych cały system został oparty na standardach Open Source. Wyjątkiem są tutaj platformy technologiczne, np. baza danych, która do zastosowań niniejszego projektu jest dostępna i zgodna z warunkami licencyjnymi za darmo ze strony firmy Oracle lub server, który można łatwo podmienić na inny Open Source gdyż, aplikacja została wykonana w pełni pod standard Java Enterprise Edition. Obsługiwane systemy operacyjne13 :  Linux Ubuntu 8.04 (server) x3214  Windows15  Macintosh16 . Wykorzystane serwery:  Server aplikacji: Oracle Web Logic 11g  Server czasu rzeczywistego + java: Red5 RC 1.0. Wykorzystane standardy Java [44, 45, 46, 47, 48]:  Java 5 EE  EJB 3.0 (ang. Enterprise JavaBean) 13 W kontekście uruchomienia platformy. Odnośnie końcowego użytkownika to może on działać na dowolnym systemie operacyjnym obsługującym wtyczkę Adobe Flash 10. 14 Po odpowiednim dostrojeniu aplikacja powinna działać i w innych wersjach systemu. Mi osobiście nie udało się uruchomić systemu pod Linux Fedora Core 14 x64 (problem był z biblioteką xuggler). 15 Potwierdzone w systemie Windows Vista x32. 16 Brak przeprowadzenia testów, ale po odpowiedniej konfiguracji powinno zadziałać.
1. Cel pracy oraz rozpoznanie technologii 16  JPA (ang. Java Persistence API)  EAR (ang. Enterprise Archive)  JSF2 (ang. Java Server Faces 2)  Threads  Entity  Facelets. Baza danych:  Oracle XE 11g. Technologie RIA (ang. Rich Internet Application):  Adobe Flex 4.5  AS 3 (ang. Action Script 3)  NetStream  SO (ang. Shared Object)  MXML  Adobe Flash 10. Technologie Internetowe:  xHTML (ang. Extensible HyperText Markup Language)  CSS (ang. Cascading Style Sheets)  JS (ang. JavaScript)  Sitemap (plik tekstowy). Technologie rozproszone SOA (ang. Service Oriented Architecture):  SOAP 1.1 (ang. Simple Object Access Protocol)  XML (ang. Extensible Markup Language)  WSDL (ang. Web Services Description Language). Technologie rozpoznawania mowy:  JSGF (ang. Java Speech Grammar Format). Wykorzystane bibloteki [55]:  rozpoznanie mowy: Sphinx4  synteza mowy: FreeTTS  konwersja formatów audio: Xuggler  spring Source Framework  parser HTML: JSoup  system logowania: Apache Logger. Metodologia wytwarzania oprogramowania [49, 50, 51, 52, 53, 54]:  UML 2.0 (ang. Unified Modeling Language)  wzorce projektowe  oprogramowanie obiektowe i rozproszone.
1. Cel pracy oraz rozpoznanie technologii 17 2.6. Podsumowanie Wykorzystując system mowy w aplikacjach otrzymujemy bardziej naturalny interfejs użytkownika, który umożliwia łatwiejsze oraz bardziej przyjazne sterowanie aplikacją pomiędzy użytkownikiem a systemem (w naszym przypadku portalem internetowym). Możemy wyróżnić dwa główne obszary systemu mowy: rozpoznawanie mowy (ang. Speech Recognition) oraz synteza mowy (ang. Speech Synthesis). Rozpoznawanie mowy polega na tym iż komputer słucha co do niego mówimy a następnie konwertuje to na tekst. Synteza mowy jest odwrotnym procesem, który polega na czytaniu tekstu poprzez wygenerowany głos ludzki w aplikacji. Często proces ten określany jest jako technologia text-to- speech (TTS). Celem pracy jest opracowanie głosowego systemu komunikacji oraz nawigacji po serwisie internetowym. Projekt zakłada wykonanie portalu testowego, systemu rozpoznawania i generowania mowy, mózgu systemu oraz postaci Awatara komunikującego się z użytkownikami oraz kierującego ich po serwisie. System ma być inteligentny w tym znaczeniu, iż Awatar nie będzie nas tylko słuchał, ale także będzie z nami w dialogu. Ze względu na skomplikowanie języka i dostępność bibliotek generowania i syntezy mowy wykonanie projektu zakłada komunikację w języku angielskim.
2 3.SPRECYZOWANIE WYMAGAŃ FUNKCJONALNYCH 3.1. Wprowadzenie Wykonany system pozwala na komunikację oraz nawigację po utworzonym portalu internetowym za pomocą głosu. W dialogu uczestniczy postać Awatara, która wyposażona jest w stan, który docelowo w przyszłości będzie rozszerzony do postaci Dictobot’a [56] za pośrednictwem odpowiedniej implementacji „Mózgu” systemu. Widok demonstracyjnego systemu został zaprezentowany na rys 2.1.
2. Sprecyzowanie wymagań funkcjonalnych 19 Rys. 2.1. Widok portalu demonstracyjnego. 3.2. Przeznaczenie systemu Zaprezentowany system przeznaczony jest dla każdego użytkownika z dostępem do Internetu ze znajomością języka angielskiego, gdyż obustronna komunikacja odbywa się właśnie w tym języku. Praca ta jest pracą rozpoznawczą, przygotowuje ona platformę do dalszego rozwoju poprzez umożliwienie podziału dalszej pracy na kilka zespołów. Pod tym kątem cały system jest tworzony i dlatego w pewnych warstwach charakteryzuje się pewnym nadmiarem, który wydzielił moduły funkcjonalne systemu. System pokazuje możliwości wykorzystania technologii rozpoznawania i generowania mowy w połączeniu ze stanem Awatara, który pamięta użytkownika przez całą sesję w której uczestniczymy w interakcji. Sam Awatar w tym wykonaniu jest częściowo autonomiczny, jednak został on tak zaprojektowany aby w przyszłości stał się on całkowicie autonomiczny
2. Sprecyzowanie wymagań funkcjonalnych 20 i sam podejmował już niektóre decyzje. Dodatkowo cała zabawa została udostępniona dla użytkowników bez potrzeby zalogowania się do portalu. 3.3. Funkcja Wyróżniamy kilka funkcjonalnych stref systemu, które dotyczą zwykłego użytkownika oraz administratora. Z myślą o wdrożeniu wykonanego systemu do istniejącego portalu internetowego samodzielnie on generuje i uaktualnia zawartość tego portalu. Ponieważ nie chcemy także, aby wszystko co na nim się znajduje trafiało do naszego systemu, np. treść znaczników opisujących tabele lub obrazki na stronie wyposażony on został w moduł filtrowania zawartości portalu. Chcemy także, aby cały system szybko działał, tak więc z tego powodu została dodana baza danych która buforuje zawartość strony. W przeciwnym wypadku użytkownik był by zmuszony oczekiwać na każdorazowe przeanalizowanie strony portalu i na tej bazie otrzymywał by odpowiedź, co było by czasochłonne. Nie chcemy, aby użytkownik musiał logować się do portalu. Powinien po prostu wejść na stronę i zacząć z niej korzystać bez poświęcania dodatkowego czasu na logowanie się lub konfigurowanie systemu. Wymagania względem Awatara:  wyposażony jest w stan (emocje), który jest zapamiętywany i przywracany kiedy ponownie użytkownik wraca do aplikacji  stan awatara jest normalizowany1 po stronie klienta, niezależnie, nie obciążając dodatkowo łącza internetowego  wydanie każdej komendy głosowej związane jest z pobraniem stanu Awatara, gdzie „Mózg” odpowiednio reaguje na ten stan  „Mózg” odpowiada za modyfikację stanu Awatara  stan Awatara został graficznie odzwierciedlony w postaci wykresu słupkowego, gdzie każdy słupek odzwierciedla inną cechę2  postać Awatara jest animowana w zależności od aktualnego stanu. Wymagania względem rozpoznawania mowy:  rozpoznawane komendy głosowe: o „Good Morning” – Awatar wita się o „Hello” – Awatar wita się o „How are Yoy ?” - Awatar odpowiada nam jak się czuje i pyta się nas o to samo o „What is Your Name ?”, „Name” – Awatar odpowiada nam jak się nazywa o „Read page”, „Read” – Awatar czyta zawartość strony głównej o „Home”, „People”, „Teachers”, „Specialization”,, „Teaching”, “Research”, “Laboratories”, “Smart control idea”, – Komendy te przekierowują do odpowiednich podstron portal demonstracyjnego o „Next page”, „Next”, i „Previous Page”, „Previous” – Powodują przejście do następnej i poprzedniej strony w portalu internetowym. Wymagania względem generowania mowy:  możliwość edycji generowanych komunikatów za pomocą panelu administracyjnego  głos powinien być odpowiednio modulowany w zależności od aktualnego stanu Awatara 1 Wyposażony w mechanizm „zapominania”. 2 W niniejszej implementacji Awatar posiada 4 cechy, a każda z nich przyjmuje wartości od 0 do 200.
2. Sprecyzowanie wymagań funkcjonalnych 21 Wymagania względem mózgu systemu:  autonomiczność, poprzez wykorzystanie technologii SOA umożliwiająca łatwą jego podmianę nawet w czasie pracy systemu  generowanie odpowiedzi na bazie aktywnego kontekstu (stanu Awatara, adresu strony żądania i komendy) zawierającej komunikat głosowy, zmianę stanu oraz ew. polecenie przekierowania w inną część portalu demonstracyjnego. Wymagania względem portalu demonstracyjnego:  zawiera angielską część informacji z Katedry Systemów Decyzyjnych  zawartość odzwierciedla fragment strony Katedry Systemów Decyzyjnych  zawiera minimum 5 podstron z różną zawartością. Wymagania względem części administracyjnej:  wygenerowanie zawartości portalu na bazie odpowiednich znaczników  podgląd zawartości bazy danych  edycja komunikatów głosowych wydawanych przez Awatara. 3.4. Podsumowanie Jest to wzorcowy projekt, który umożliwia sterowanie portalem internetowym za pomocą głosu. Jego główną funkcją jest możliwość interakcji użytkownika za pomocą głosu poprzez wydawanie komend głosowych oraz słuchanie i dialog z Awatarem. Docelowo, jeżeli system ten odniesie sukces będzie on zaimplementowany na portalu Uczelni, dlatego został on wyposażony we własny system znaczników i parser3 , który na podstawie znaczników przygotowuje odpowiednio bazę danych, która wykorzystywana jest już przez „Mózg” systemu. W ten sposób została zagwarantowana możliwość jego implementacji na portalu uczelni w przyszłości. 3 Parser analizuje zawartość stron portalu na postawie specjalnych znaczników. Szczytuje tylko wybraną zawartość portalu w sposób odpowiednio przygotowany.
3 4.ZASADA DZIAŁANIA ORAZ OPIS SYSTEMU 4.1. Wprowadzenie Na cały system składa się wiele różnych technologii, które współpracują ze sobą. Ich połączenie wymusiło utworzenie wielu warstw z wieloma współzależnościami. W celu obsłużenia wielu użytkowników jednocześnie cały system w kluczowych elementach został podzielony na osobne wątki, tak aby jeden użytkownik nie musiał czekać na zakończenie operacji związanej z obsługą innych użytkowników. Całe rozwiązanie zostanie przedstawione w kolejnych podrozdziałach. 4.2. Architektura systemu Ogólna architektura systemu została przedstawiona na rys. 3.1. Na rysunku możemy zauważyć, iż cały system jest mocno rozproszony i dzieli się na poszczególne moduły, które są odpowiedzialne za swoją część. W ten sposób cały projekt został podzielony na mniejsze części, które mogą być niezależnie zarządzane.
3. Zasada działania oraz opis systemu 23 Rys. 3.1. Ogólna architektura systemu. Wydzielamy tu część kliencką oznaczoną kolorem błękitnym która jest środowiskiem pracy, które w danym momencie posiada użytkownik systemu. Część kliencka odpowiada za komunikację z serwerem, przydzieleniem uprawnień do mikrofonu i głośników, wygenerowaniem unikalnego identyfikatora dla klienta, który następnie jest wykorzystywany przez serwer do jego identyfikacji. Także w tej części użytkownik ma kontakt z systemem, obserwuje wizualnie Awatara, wydaje komendy oraz słucha systemu. Tutaj także znajduje się aktualna wizualizacja stanu Awatara w postaci wykresu słupkowego oraz konsola logów z całego systemu, w której użytkownik monitoruje stan platformy w danym momencie. Po stronie klienta przechowywany jest aktualny stan Awatara unikalny dla każdego użytkownika, jednak jest on przypisany na stałe do danego komputera, a czasem przeglądarki. Tak więc po powrocie do systemu w późniejszym czasie na danym komputerze następuje odczytanie stanu Awatara, który na stałe zachowany jest na dysku użytkownika w postaci obiektu współdzielonego (ang. Shared Object). Także tutaj użytkownik ma dostęp do ustawień, które są przechowywane w obiekcie współdzielonym (ang. Shared Object). Ustawienia te pozwalają na włączenie lub wyłączenie odświeżania stanu Awatara oraz włączenie/wyłączenie wyświetlania konsoli logowania w portalu internetowym. Ustawienia te powalają zwiększyć wydajność pracy aplikacji klienta. W ustawieniach można także zdefiniować adres serwera mowy, który odpowiada za całą dalszą pracę systemu1 . Część serwerowa została oznaczona kolorem zielonym. Fizycznie część ta podzielona jest na dwa serwery: serwer mowy jest serwerem czasu rzeczywistego, jest to serwer Red5 RC 1.0, który opiera się na platformie Apache Tomcat 6 działający na porcie 8080 dla protokołu HTML oraz na porcie 1935 dla protokołu RTMP, drugim serwerem jest Oracle WebLogic 11g 1 W końcowej fazie pracy nad systemem opcja ta została domyślnie wyłączona.
3. Zasada działania oraz opis systemu 24 na którym działa „Mózg” systemu, część administracyjna oraz portal demonstracyjny. Sewer standardowo działa na porcie 7001 dla protokołu HTML. Serwer mowy jest kluczowym elementem całego systemu, zwyczajowo nazywany „serwerem” niniejszego systemu. To bezpośrednio z nim komunikuje się klient (w zasadzie użytkownik systemu). Serwer ten wydziela dalszą interakcję z użytkownikiem. Na serwerze tym zostały utworzone moduły generowania i syntezy mowy, klienta mózgu, obsługi i konwersji danych audio przesyłanych w czasie rzeczywistym. Także w tym miejscu znajduje się lista słów i komend rozpoznawalnych przez system w formacie JSGF (ang. Java Speech Grammar Format). W tym miejscu mamy konfiguracje systemów rozpoznawania i syntezy mowy w formatach zdefiniowanych przez specyfikacje bibliotek FreeTTS oraz Sphinx4. Wykonany serwer mowy posiada architekturę wielo-wątkową2 (ang. Multithreading), tak więc każde żądanie nowego klienta obsługiwane jest w nowym wątku. Konwersje formatów danych audio są także wykonywane wielo wątkowo. Rozpoznanie komendy głosowej z wygenerowaniem odpowiedzi również zachodzi w osobnym wątku. Wiele operacji w serwerze zachodzi w oparciu o zdarzenia (ang. Events). Dotyczy to obsługi komunikacji serwera z klientem podczas wymienianych komunikatów, konwersji plików audio oraz obsługi wymiany danych audio w czasie rzeczywistym. Serwer mowy wykorzystuje bibliotekę Xuggler do konwersji formatów audio. Biblioteka ta jest zainstalowana na serwerze w systemie operacyjnym, natomiast sam system korzysta z niej poprzez referencję. Standardowo serwer Red5 nagrywa dane audio w formacie .flv (ang. Flash Video) które są następnie konwertowane do formatu .wav (ang. Wave form audio format) poprzez napisany konwerter wykorzystujący bibliotekę Xuggler, który jest już zrozumiały dla systemu rozpoznawania mowy. Natomiast generator mowy generuje mowę w formacie .wav, który jest zbyt duży do przesłania do użytkownika, a także nie jest standardowo obsługiwany przez serwer Red5 tak więc jest on konwertowany do formatu .mp3 (ang. MPEG-1/MPEG-2 Audio Layer 3), który jest już kilka do kilkunastu razy mniejszy oraz możliwy do odtworzenia w czasie rzeczywistym przez klienta. Mózg jest drugim serwerem, który odpowiada za logikę aplikacji. Komunikuje się on bezpośrednio i wyłącznie z systemem mowy, od którego dostaje komendę użytkownika w postaci tekstowej, identyfikator klienta oraz stan Awatara oraz zwraca akcję do wykonania przez klienta wraz z komendą zmiany stanu Awatara lub wykonania przekierowania do innej strony w portalu internetowym. Komunikacja systemu mowy następuje poprzez klienta Mózgu, który komunikuje serwer mowy z „Mózgiem” poprzez protokół SOAP przy wykorzystaniu dokumentu WSDL w technologii rozproszonej SOA. To rozwiązanie umożliwia łatwe dodawanie nowych implementacji Mózgu oraz przełączanie ich w czasie działania aplikacji. Mózg na podstawie otrzymanych danych i przetworzeniu posiadanych decyduje o wykonanej interakcji w portalu internetowym za pośrednictwem serwera mowy, który dodatkowo może wygenerować komunikaty głosowe dla użytkownika oraz przesłać komunikaty zmiany stanu Awatara lub zadecydować o wykonaniu przekierowania użytkownika do innej strony na portalu internetowym. Oba serwery działają w technologii Java. Wyłącznie Mózg komunikuje się z bazą danych poprzez fasadę, obiekt typu EJB Stateless Bean wykorzystując Framework JPA i zdefiniowane źródło danych (ang. Data Source) po stronie serwera oraz mapowanie ORM (ang. Object- relational maping) dzięki wykorzystaniu encji (ang. Entities). Zastosowaną bazą danych jest 2 Architektura wielo-wątkowa pozwala na równoległą realizację żądań wielu użytkowników równocześnie. Najczęściej żądania są rozdzielane równomiernie na dostępne procesory i rdzenie dzięki czemu wykonywane operacje powinny odbywać się szybciej (choć nie zawsze, jeżeli liczba wątków jest zbyt duża) i powinny pozwolić na wykonanie danej operacji przez nowego użytkownika bez potrzeby oczekiwania na zakończenie wykonywanych operacji przez innych użytkowników (jednak w praktyce nie zawsze tak jest, jest to zależne od wykonanej implementacji).
3. Zasada działania oraz opis systemu 25 baza danych Oracle XE 11g, która przechowuje wcześniej przygotowaną zawartość portalu internetowego oraz treść komunikatów generowanych dla użytkownika. Nad zapełnieniem bazy danych oraz przygotowaniem w niej danych odpowiada część Administratora, która szczytuje zawartość portalu na podstawie jego mapy strony (ang. Sitemap) oraz wcześniej przygotowanym znacznikom mowy (ang. Tags). Moduł ten jest całkowicie niezależny od pozostałej części systemu, zapewnia on możliwość do podglądu wygenerowanych danych, wygenerowaniu nowych danych oraz możliwość edycji generowanych komunikatów dla użytkownika. Klient łączy się z częścią serwerową za pośrednictwem protokołów RTMP i AMF (ang. Action Message Format). Za pomocą protokołu RTMP przesyłany jest wyłącznie sygnał audio w czasie rzeczywistym bez potrzeby przesyłania całego materiału w całości3 . Natomiast protokół AMF służy wyłącznie do wymiany komunikatów pomiędzy serwerem a klientem. Komunikaty te zawierają informacje typu: stan Awatara, komendy tekstowe przesyłane do serwera w postaci czytelnego tekstu, informacje zwrotne dla klienta kiedy czeka na niego wiadomość do odsłuchania, komunikaty logów4 ze strony serwera itp. Klient-serwer komunikują się ze sobą wyłącznie za pośrednictwem tych dwóch protokołów. Serwer mowy komunikuje się z Mózgiem za pośrednictwem protokołu SOAP w technologii rozproszonej SOA. Wyłącznie Mózg komunikuje się z bazą danych. W ten sposób zostały jasno wyznaczone warstwy systemu. 4.3. Algorytm działania systemu System posiada budowę modułową, tak więc możemy wyróżnić wiele algorytmów działania systemu. W poniższym opisie została pominięta obsługa sytuacji awaryjnych, która została zaimplementowana przez system. Jednak niniejszy rozdział skupia się na poprawnym i przewidzianym funkcjonowaniu systemu. Opis ten nie obejmuje także opisu sytuacji logowania wykonywanych operacji, ponieważ są one wykonywane we wszystkich istotnych częściach systemu5 . 4.3.1. Przygotowanie systemu mowy Do poprawnego działania systemu wymagane jest przygotowanie i inicjalizacja serwera mowy. Podczas startu serwera inicjalizowany jest system mowy i sam serwer czasu rzeczywistego. Inicjalizacja serwera mowy polega na załadowaniu i wybraniu głosu (w naszym przypadku jest to głos męski o nazwie „kevin16”, gdzie 16 oznacza 16kHz próbkowanie, czyli głos o najwyższej jakości dostępny jako Open Soure), rezerwacji zasobów sprzętowych wykorzystywanych podczas generowania mowy oraz samo przypisanie generatora do systemu mowy. Kolejnym kluczowym elementem, który inicjalizowany jest podczas startu serwera jest to inicjalizacja systemu rozpoznawania mowy. W pierwszej kolejności następuje skonfigurowanie systemu poprzez załadowanie pliku konfiguracyjnego „config,xml”. Plik ten przede wszystkim wczytuje listę słów w formacie JSGF (znajdująca się w pliku „hello.gram”) i komend do rozpoznania przy uwzględnieniu danej rozdzielczości sygnału audio (w naszym przypadku system został skonfigurowany do wykorzystania najwyższej dostpnej 3 Protokół RTMP w odróżnieniu od innych protokołów naprawdę przesyła dane w czasie rzeczywistym. Inne protokoły najczęściej „udają”, że przesyłają materiał czasie rzeczywistym, lecz np. przesyłają go w partiach, a nie bit po bicie jak dzieje się to w przypadku wykorzystania protokołu RTMP. 4 Komunikaty te informują klienta co dzieje się po stronie serwera. W przypadku jakichkolwiek problemów po stronie serwera klient jest informowany o tym fakcie. 5 Obsługę błędów jak i system logów można prześledzić w załączonym kodzie źródłowym.
3. Zasada działania oraz opis systemu 26 jakości sygnału audio), model akustyczny oraz inne ustawienia wykorzystywane podczas rozpoznawania mowy. Następnie alokowane są zasoby systemowe niezbędne do przeprowadzenia procesu rozpoznania mowy. W ten sposób system mowy zostaje uruchomiony. Bez poprawnego wykonania inicjalizacji powyższych elementów system nie zadziała w ogóle. Powyższe działania zostają wykonane jednorazowo. 4.3.2. Podłączenie klienta Interakcja po stronie użytkownika następuje już w momencie otworzenia strony portalu internetowego. W pierwszym momencie po stronie portalu zostaje wygenerowany unikalny identyfikator użytkownika, który wykorzystywany jest w połączeniach klienta z serwerem. Następnie zostaje załadowany klient w technologii Flex poprzez wtyczkę przeglądarki internetowej Adobe Flash. Klient w momencie startu dokonuje załadowania postaci graficznej Awatara wykonanej w technologii Adobe Flash oraz odczytuje identyfikator klienta wygenerowany przez portal internetowy. Potem następuje inicjalizacja klienta, która uwzględnia utworzenie specjalnej wersji systemu logowania aplikacji klienta, która wysyła logi aplikacji dla użytkownika za pośrednictwem interfejsu zewnętrznego (ang. ExternalInterface) za pośrednictwem języka Java Script oraz dzieli logi na podstawowe kategorie. Kolejno utworzony jest lub wczytany współdzielony obiekt (ang. Shared Object) ustawień danego klienta oraz otwierany lub nie w zależności od ustawień panel logów po stronie portalu internetowego (dzięki tej operacji użytkownik ma możliwość na bieżąco śledzenia kolejnych zdarzeń, które zachodzą w całym systemie oraz w przypadku wystąpienia błędu jest o tym informowany na bieżąco). W następnej kolejności zostaje zarezerwowany mikrofon do wykorzystania w systemie (tutaj następuje weryfikacja, czy użytkownik zezwolił aplikacji na wykorzystanie mikrofonu przez aplikację). W tym momencie następuje wczytanie pozostałych ustawień klienta zapisanych w obiekcie współdzielonym6 . Po wczytaniu ustawień zostaje albo utworzony standardowy stan Awatara lub zostaje on odtworzony z obiektu współdzielonego. Następnym krokiem jest przygotowanie klienta do wymiany komunikatów z serwerem, w tym tych wysyłanych i odbieranych. Po wykonaniu tych wszystkich czynności Awatar zostaje ożywiony, tzn. zostaje on poddany normalizacji czyli powrotu do stanu normalnego7 . Po przygotowaniu klienta8 następuje połączenie klienta z serwerem. Obsługa połączenia po stronie klienta następuję w trybie zdarzeniowym (ang. Events). Po wysłaniu żądania połączenia z serwerem, serwer podejmuje próbę połączenia z klientem w osobnym wątku. Klient wysyła swój identyfikator do serwera, który jest zapisany w atrybucie klienta po stronie serwera do jego dalszej identyfikacji. W pierwszym momencie po stronie serwera następuje weryfikacja, czy łączący się klient czasem nie jest już połączony z serwerem w innym żądaniu9 (np. w innej zakładce przeglądarki lub w wyniku po prostu przejścia na inną stronę portalu internetowego). Jeżeli klient jest już połączony to następuje jego scalenie „sesji” z obecnie zapisaną w liście 6 W ten sposób została zapewniona możliwość np. przesłania dodatkowych parametrów do systemu, np. naszego imienia. Jednak ta wersja systemu nie korzysta z takiego rozwiązania. 7 Normalizacja czyli funkcja zapominania stanu Awatara ze względu na optymalizację wydajności całego systemu została wykonana wyłącznie po stronie klienta. Zamiast obciążać klienta częstym przesyłaniem informacji o stanie Awatara np. raz na sekundę, to czynność ta została całkowicie wykonana po stronie klienta. Jeżeli weźmiemy pod uwagę pracę z wieloma klientami jest to znaczne odciążenie zarówno klienta jak i serwera odnośnie dodatkowej obsługi każdego takiego żądania kosztem większego skomplikowania systemu. 8 Przedstawione przygotowanie klienta występuje po każdorazowym odwiedzeniu strony w portalu internetowym. 9 Tutaj sytuacja trochę się komplikuje ponieważ połączenie klient-serwer w prezentowanym systemie nie jest połączeniem sesyjnym. O zapewnieniu trwałości połączenia system musi sam zdecydować, nie dzieje się to automatycznie ze względu na to iż aplikacje Flex są bezstanowe w momencie przejścia do innej strony internatowej lub jej przeładowania.
3. Zasada działania oraz opis systemu 27 klientów aktualnie połączonych10 , w przeciwnym razie zostaje klient dodany do listy nowych klientów aktualnie połączonych z systemem. W przypadku sukcesu połączenia i w zależności od typu połączenia (nowe lub wznowione) w osobnym wątku zostaje wygenerowana wiadomość powitalna dla klienta11 . Na koniec zostaje wysłana wiadomość powitalna dla klienta, która jest wiadomością kontrolną czy funkcjonuje komunikacja dwustronna w obszarze klient-serwer. Dopiero w tym momencie klient odbiera potwierdzenie połączenia z serwerem i ustawia swój status połączenia na połączony12 . Jeszcze pozostało zestawienie połączenia gniazda (ang. Socket), właściwie strumienia danych po protokole RTMP. W ten sposób klient został połączony i przygotowany do dalszego użycia. Przebieg algorytmu podłączenia klienta: 1. otworzenie strony internetowej 2. wygenerowanie unikalnego identyfikatora użytkownika 3. załadowanie klienta poprzez wtyczkę flash 4. wczytanie postaci graficznej awatara poprzez klienta 5. odczytanie wygenerowanego identyfikatora poprzez klienta 6. utworzenie systemu logowania po stronie klienta 7. wczytanie lub utworzenie obiektu SO z ustawieniami klienta 8. inicjalizacja mikrofonu jeżeli zezwolono 9. wczytanie ustawień z obiektu SO 10. wczytanie lub utworzenie stanu Awatara 11. przygotowanie komunikacji klient-serwer 12. ożywienie Awatara w proces normalizacji 13. połączenie klienta z serwerem wraz z wysłaniem identyfikatora klienta w nowym wątku 14. zapisanie identyfikatora klienta po stronie serwera 15. weryfikacja czy klient nie jest już połączony z serwerem 16. dodanie lub przekierowanie klienta do listy połączonych z serwerem 17. wygenerowanie wiadomości powitalnej dla klienta w nowym wątku 18. wysłanie wiadomości powitalnej do klienta z informacją, iż został on już połączony 19. serwer wysyła wiadomość do klienta, iż czeka na niego wiadomość do odsłuchania 20. zestawienie połączenia RTMP pomiędzy klientem i serwerem. 10 Połączenie klienta determinowane jest po długości czasu życia sesji po stronie portalu internetowego według wygenerowanego identyfikatora klienta. 11 Algorytm generowania mowy został opisany w osobnym podrozdziale. 12 W rzeczywistości status connectionStatus otrzymuje wartość true.
3. Zasada działania oraz opis systemu 28 Rys. 3.2. Wykorzystanie wątków podczas inicjalizacji klienta. Rysunek 3.2 przedstawia sposób wykorzystania wątków podczas inicjalizacji klienta. P0 oznacza klienta, T0 reprezentuje podłączenie klienta do serwera, każdy klient zostaje obsłużony w osobnym wątku, następnie T1 oraz T2 przedstawiają wygenerowanie wiadomości powitalnej, która generowana jest także w osobnych wątkach, aż w końcu wszystkie te komunikaty wracają z powrotem do klientów. 4.3.3. Wygenerowanie mowy i jej odsłuchanie przez użytkownika System umożliwia proste wygenerowanie mowy na podstawie przekazanego tekstu lub bardziej zaawansowane przy wykorzystaniu obiektu złożonego zawierającego stan Awatara. W zależności od implementacji Mózgu przy wykorzystaniu obiektu złożonego możemy otrzymać inny wynik wygenerowanej mowy w zależności od aktualnego stanu Awatara a także system może przekierować nas w inne miejsce w portalu internetowym. Przy wykorzystaniu prostego tekstu zawsze otrzymamy wygenerowaną mowę do odsłuchania. Ze względu na to iż obiekt złożony rozszerza wykorzystanie prostego tekstu podczas wygenerowania mowy, w tym rozdziale tylko ten algorytm zostanie opisany. Schemat wygenerowania komendy głosowej został przedstawiony na rys. 3.3.
3. Zasada działania oraz opis systemu 29 Rys 3.3. Wygenerowanie odpowiedzi na podstawie komendy głosowej. Na początku zostaje utworzony obiekt zapytania, który zawiera komendę tekstową oraz stan Awatara13 . Komenda tekstowa jest tekstem, który ma posłużyć do wygenerowania mowy. Poprzez klienta obiekt zapytania jest przekazany do Mózgu za pośrednictwem protokołu SOAP. W samym mózgu zapytanie jest przetwarzane14 . W naszym systemie następuje porównanie nadesłanej komendy głosowej czy jest ona rozpoznawana przez Mózg. W zależności od rozpoznanej lub nie komendy następuje przygotowanie odpowiedzi zwrotnej, która zawiera tekst odpowiedzi pobrany z bazy danych oraz wartości zmiany stanu Awatara w zależności od kontekstu15 w wartościach względnych16 a także opcjonalnie informację o wymaganym przekierowania użytkownika na inną stronę portalu internetowego. Odpowiedź ta jest zwracana z Mózgu do serwera mowy, który na jej podstawie przygotowuje obiekt odpowiedzi dla klienta, następnie odpowiedź ta przesyłana jest do klienta i modyfikuje na tej podstawie stan Awatara lub przekierowuje użytkownika na inną stronę w zależności czy to przekierowanie miało nastąpić, czy też nie. Równolegle na podstawie wcześniej zapisanego identyfikatora klienta, który zgłosił żądanie na wygenerowanie mowy rozpoczyna się proces generowania mowy. W tym miejscu od razu na wstępie zostaje wygenerowany unikalny numer pliku globalny dla całego serwera mowy, który będzie wykorzystany do zapisania wygenerowanej mowy poprzez wykorzystanie 13 Zwyczajowo stan Awatara jest bezpośrednio pobierany od klienta przed samym wysłaniem zapytania do Mózgu. W celu pobrania odpowiedniego stanu Awatara klient jest wcześniej odpowiednio identyfikowany, zaś samo pobranie stanu zostaje wykonane za pośrednictwem protokołu AMF. 14 W zależności od implementacji Mózgu wynik może być zupełnie odmienny. 15 Kontekst jest definiowany i pobierany przez Mózg systemu. 16 Są to wartości, które są dodawane do stanu Awatara (mogą być także wartościami ujemnymi).
3. Zasada działania oraz opis systemu 30 własnej implementacji modułu zapisu wygenerowanej mowy do pliku. Z syntezatora mowy zostaje pobrany odtwarzacz, który zostaje przekierowany do pliku. Zostaje wygenerowana mowa, która zostaje zapisana do pliku .wav, który jeszcze nie nadaje się do przesłania do klienta. W tym miejscu nowo wygenerowany plik zostaje przekonwertowany na podstawie implementacji konwertera biblioteki Xlugger z formatu .wav do formatu .mp3. Konwersja ta zawsze przebiega w nowym wątku. Konwerter sprawdza czy na podstawie przekonwertowanego pliku ma nastąpić rozpoznanie komendy i wykonanie akcji17 . W przypadku zwykłej konwersji do tej czynności nie dochodzi wcale. Jest ona zarezerwowana dla obsłużenia komend głosowych wydanych bezpośrednio po stronie klienta. Po wygenerowaniu pliku mowy i przekonwertowaniu go do formatu umożliwiającego jego odtworzenie w czasie rzeczywistym zostaje wysłana komenda odtwórz wiadomość w raz z nazwą pliku do odtworzenia dla klienta zgłaszającego prośbę o wygenerowanie mowy. W tym momencie klient otrzymawszy taką wiadomość, sprawdza czy połączenie z serwerem i gniazdem jest już gotowe. Jeżeli jest już gotowe to następuje odtworzenie wygenerowanej mowy w czasie rzeczywistym. W przeciwnym wypadku zgłoszenie zostaje zapisane po stronie klienta, który ponawia 5-cio krotnie próbę otworzenia oczekującej wiadomości co 0,5s. Po tym czasie próba odtworzenia wiadomości zostaje zaniechana, a klientowi zostaje przekazany komunikat o błędzie w konsoli logowania. Przebieg algorytmu generowania mowy: 1. utworzenie obiektu zapytania zawierającego tekst mowy do wygenerowania oraz stan awatara (stan pobierany jest od klienta tuż przed samym wysłaniem żądania do Mózgu) 2. przesłanie zapytania do Mózgu za pośrednictwem protokołu SOAP 3. rozpoznanie nadesłanej komendy 4. pobranie tekstu odpowiedzi z bazy danych 5. obliczenie wymaganej zmiany stanu Awatara 6. przygotowanie strony przekierowania o ile zajdzie taka potrzeba 7. wygenerowanie odpowiedzi zwrotnej 8. przekazanie odpowiedzi z Mózgu do serwera mowy 9. utworzenie komunikatu zwrotnego dla klienta 10. przesłanie komunikatu zwrotnego do klienta 11. zmiana stanu Awatara po stronie klienta 12. przekierowanie użytkownika na inną stronę o ile zajdzie taka potrzeba 13. wygenerowanie unikalnego w skali serwera mowy identyfikatora pliku 14. utworzenie pliku .wav zawierającego odpowiedź audio dla klienta 15. w nowym wątku następuje konwersja pliku .wav na plik .mp3 16. opcjonalnie następuje tu wykrycie komendy oraz wykonanie akcji na tej podstawie 17. wysłanie komendy odtwórz oczekującą wiadomość do klienta 18. klient weryfikuje czy podłączenie RTMP z serwerem jest już gotowe 19. następuje 5-cio krotna próba odtworzenia oczekującej wiadomości w czasie rzeczywistym. 17 Jest to uniwersalne rozwiązanie pozwalające usprwanić proces dalszej analizy i obróbki uzyskanego materiału audio. Rozpoznanie komendy i wykonanie akcji występuje wyłącznie w momencie, gdy komenda ta została zgłoszona bezpośrednio ze strony klienta poprzez protokół czasu rzeczywistego RTMP. W innym wypadku nie jest ona w ogóle wykorzystywana.
3. Zasada działania oraz opis systemu 31 Rys. 3.4. Wykorzystanie wątków podczas generowania mowy. Rysunek 3.4 przedstawia sposób wykorzystania wątków podczas generowania mowy. P0 oznacza zgłoszenie pliku oczekującego na konwersję, T0 reprezentuje konwersję pliku .wav na .mp3. Każdy plik zostaje obsłużony w osobnym wątku, następnie następuję przesłanie odpowiedzi iż pliki zostały przekonwertowane dla swoich „zleceniodawców”. 4.3.4. Rozpoznanie wydanej komendy głosowej Rozpoznanie komendy głosowej rozpoczyna się w momencie wciśnięcia i przytrzymania przycisku „Speak” w kliencie przy postaci Awatara. W tym momencie następuje nagranie materiału jeszcze audio/video na serwerze18 w czasie rzeczywistym pod wysłaną nazwą klienta. Podczas tej operacji serwer przechwytuje materiał audio/video i zapisuje go na dysku komputera. W momencie odpuszczenia przycisku przez użytkownika jest wysyłany komunikat o ukończeniu nagrywania do serwera. Teraz w nowym wątku po stronie serwera następuje konwersja pliku .flv do pliku .wav za pośrednictwem implementacji bibloteki Xuggler19 a następnie rozpoznanie komendy i wykonanie akcji opisanej w poprzednim podrozdziale. Przebieg algorytmu rozpoznania mowy: 1. rozpoczęcie procesu rozpoznania mowy następuje z chwilą wciśnięcia przycisku „Speak” po stronie klienta 2. następuje nagrywanie materiału audio/video po stronie serwera w czasie rzeczywistym 3. odpuszczenie przycisku „Speak” po stronie klienta powoduje wysłanie komunikatu do serwera o zakończeniu procesu nagrywania 18 Serwer Red5 umożliwia wyłącznie nagrywanie materiału audio/video w czasie rzeczywistym. 19 Operacja ta została opisana w rozdziale „Wygenerowanie mowy i jej odsłuchanie przez użytkownika”.
3. Zasada działania oraz opis systemu 32 4. w nowym wątku rozpoczyna się konwersja formatu .flv do pliku .wav 5. teraz następuje rozpoznanie komendy z otrzymanego pliku .wav 6. na tej podstawie wysyłana jest wiadomość do Mózgu a następnie występują czynności opisane w poprzednim podrozdziale. Wykorzystanie wątków w tym procesie jest analogiczne jak przy procesie generowania mowy. 4.3.5. Mózg System ten został wyposażony w bardzo prostą implementację Mózgu, która porównuje otrzymane komendy do tych zapisanych we własnej pamięci i na tej podstawie wykonuje przypisane operacje. Mózg otrzymuj kontekst danego użytkownika składający się z chwilowego stanu (emocji) Awatara, aktualnej strony WWW, z której przyszło dane żądanie oraz z komunikatu tekstowego. Na bazie kontekstu i rozpoznanej komendy z komunikatu tekstowego generowana jest na sztywno odpowiedź, która zawiera pobraną z bazy danych komendę głosową, polecenie i adres przekierowania użytkownika do innej strony internetowej oraz zmianę stanu (emocji) Awatara. Zmiana stanu Awatara w tej implementacji Mózgu polega na jego zmianie w losowej wartości zmiany w określonym zakresie20 . 4.3.6. Stan (emocje) Awatar wyposażony jest w samoistną świadomość wyposażoną w mechanizm „zapominania”, który działa wyłącznie po stronie klienta i doprowadza stan (emocje) do stanu znormalizowanego. Stan Awatara przechowywany jest na komputerze klienta i zapamiętywany jest nie tylko poprzez daną sesję użytkownika (które de facto nie wymaga chociażby zalogowania się do systemu), ale pamiętany jest od czasu ostatnich odwiedzin portalu internetowego. Pamięć ta opiera się na mechanizmie Shared Object platformy Adobe Flash, który w uproszczeniu21 jest odpowiednikiem pliku ciasteczka (ang. cookie). Na bazie aktualnego stanu Mózg jest w stanie wygenerować inną odpowiedź, która spowoduje odmienne zachowanie się Awatara oraz zmieni modulację jego głosu22 . Graficzna postać Awatara jest animowana23 na bazie stanu w sposób ciągły (patrz rys. 3.5), natomiast komenda głosowa w całości uwzględnia stan z momentu jej wygenerowania. Rys. 3.5. Animacja postaci Awatara w zależności od stanu (emocji). 20 Dzięki aktualnej implementacji możemy określić zachowania Awatara jako nieobliczalne. Jednak jest to tylko i wyłącznie kwestią implementacji Mózgu. 21 Tak naprawdę Shared Object jest obiektem o wiele bardziej zaawansowanym niż ciasteczko. 22 Modulacja zawiera zmianę szybkości mówienia, częstotliwości oraz wysokości głosu. 23 Animacja uwzględnia powiększenie oraz pomniejszenie źrenic, zmianę kolorystyki twarzy oraz zmianę tępa animacji mowy w momencie, gdy Awatar nam odpowiada.
3. Zasada działania oraz opis systemu 33 4.4. Opis wyników Pierwsze testy integralne całego systemu wykazały jego stabilną pracę. Jednak wykorzystane biblioteki rozpoznawania i syntezy mowy, pomimo iż zostały wykorzystane ich najbardziej dopracowane biblioteki w wersji Open Source pozostawiają jeszcze wiele do życzenia. Jakość wygenerowanej mowy nie jest wysokiej jakości, a sam system rozpoznawania mowy charakteryzuje się wysokim progiem błędów, przez co wydawane komendy są źle interpretowane. Biblioteki te są stale rozwijane, jednak tempo ich rozwoju nie jest zbyt wielkie, lecz gdy pojawią się ich lepsze odpowiedniki będzie można je podmienić w systemie. 4.5. Struktura oprogramowania Tak jak zostało to już wcześniej wielokrotnie napisane cały system został wykonany jako zbiór wielu modułów wymienionych w tab. 3.1. Każdy moduł jest niezależnym projektem. Wszystkie kluczowe moduły posiadają oddzielne aplikacje testujące. Tab. 3.1. Moduły systemu. l.p. moduł technologia opis 1. Administrator Java, JSF, EJB, JSoup, HTML, JAAS część administracyjna 2. AdministratorTest Java, Junit testy jednostkowe 3. Avatar Flash, AS postać Awatara 4. BrainService Java, EJB, WSDL, WSDL, Web-Service, SOA Mózg 5. BrainServiceClient Java, Web-Service, SOA klient Mózgu 6. BrainServiceClientTest Java, Junit testy jednostkowe 7. PortalPG Java, JSF, HTML, JS, CSS portal demonstracyjny 8. SpeechAvatar Flex, AS, MXML, RTMP, AMF klient 9. SpeechModel Java, JPA, EJB, Entity, ORM odwzorowanie bazy danych, model danych oraz fasada 10. SpeechModelTest Java, Junit testy jednostkowe 11. SpeechServer Java, Spring, Injection, RTMP, AMF serwer mowy 12. SpeechServerTest Java, Junit testy jednostkowe 13. Baza danych Oracle, SQL baza danych Następujące moduły składają się na systsem:  Administrator  BrainService  PortalPG  SpeechModel
3. Zasada działania oraz opis systemu 34 4.6. Podsumowanie Jak zostało to przedstawione w tym rozdziale architektura systemu jest mocno rozproszona. Praktycznie każdy moduł może istnieć niezależnie, jednak wszystkie moduły razem wzięte tworzą pełną platformę. Taka budowa zapewnia dobrą rozbudowę systemu.
4 5.REALIZACJA PRACY 5.1. Wprowadzenie W momencie realizacji niniejszego projektu posiadałem już wieloletnie doświadczenie w programowaniu głównie systemów internetowych w różnych technologiach, w tym systemów rozproszonych oraz korporacyjnych. Dzięki temu swobodnie mogłem skupić się na sposobie implementacji technologii Speech (rozpoznawania i syntezy mowy) dla celów komunikacji użytkownika z systemem za jej pośrednictwem w portalu internetowym. Technologia ta jest dla mnie pewnym nowym wyzwaniem, które zamierzam zrealizować. Na chwilę obecną nie ma żadnych gotowych samouczków czy pomocy naukowych które opisały by sposób wykonania takiego systemu. Do dyspozycji mamy odrębne elementy opisane osobno, które należy zmusić do współpracy ze sobą w pewnych określonych warunkach (w naszym przypadku chodzi o zastosowanie klient-serwer, z wykorzystaniem dodatkowych zasobów po stronie klienta co jest dodatkowym utrudnieniem). Realizacja całego projektu przebiegała przy ciągłej współpracy i pod nadzorem Pana prof. dr hab. inż. Zdzisław Kowalczuk, który wyznaczył kierunek wykonanej pracy oraz czuwał nad tym aby nie był to projekt zamknięty, ale mógł być kontynuowany przez kolejne lata na uczelni. Wykonanie pracy zostało podzielone na kilka kluczowych etapów opisanych poniżej. Wyszczególnione etapy zostały wyodrębnione na bazie poszczególnych funkcji bądź założeń, które nie koniecznie zostały wykonane w opisanej kolejności, a często były tworzone równorzędnie. Etapy realizacji projektu: 1. zapoznanie się z technologią Speech oraz AI 2. wykonanie systemu analizy serwisu 3. system generowania oraz rozpoznawania mowy 4. silnik AI wraz z inicjacją "świadomości" bota oraz z implementacją 4 stanów emocji 5. stworzenie prostej graficznej postaci Awatara komunikującej się z silnikiem AI
4. Realizacja pracy 36 6. utworzenie demonstracyjnego serwisu z implementacją postaci Awatara 7. przygotowanie odpowiedniej dokumentacji. 5.2. Testowanie platformy Podstawową techniką testowania systemu jest wykorzystanie jednostek testowych, które weryfikują cząstkowe działanie systemu. System powstawał krok po kroku, z małego rozwinął się w duży wykonując testy użytkownika podczas jego działania. Skala złożoności i zależności systemu jest tak duża, że do pomocy został wykonany specjalny system logowania, który informuje użytkownika o pracy całego systemu umożliwiając wykrycie różnego rodzaju dolegliwości i problemów w systemie, którego przetestowanie jest o tyle skomplikowane, iż opiera się na mowie, stanie Awatara, który nie bazuje na sesji a dodatkowo rozproszony jest na wiele pod stron, niezależnych żądań przekierowań, ale jednak tworzących pewną całość, która była testowana poprzez użytkownika systemu. 5.3. Omówienie sposobów rozwiązania problemów Głównym problemem, który pojawił się na początku było spasowanie i dobór istniejących technologii do wykonanego projektu. Nadrzędnym celem jest uzyskanie wysokiej jakości produktu przy wykorzystaniu technologii Open Source, tak aby projekt mógł być dalej rozwijany przez uczelnie. Tak więc po wybraniu kluczowych technologii rozpoznawania i syntezy mowy nastąpiło pasowanie do nich technologii pomocniczych. Tutaj pojawiły się już pierwsze ograniczenia, które wskazały jakie formaty danych są obsługiwane przez powyższe technologie. W tym momencie nastąpiło poszukiwanie technologii wspierających Możliwość pracy rozproszonej dodatkowo komplikuje sam fakt dostępu do zasobów komputera użytkownika (mikrofonu i głośników), który domyślnie jest zablokowany. W tym celu została wykorzystała wykorzystana technologia Adobe Flex, która daje dostęp do wymaganych zasobów. 5.4. Podsumowanie W informatyce mówi się, że po wykonaniu 80% projektu do jego ukończenia pozostało pozostałe 90%, co miało miejsce także i w tym projekcie. Projekt był nowatorski, wiele się z niego nauczyłem, bardzo mnie rozwinął, pokonałem w nim wiele przeszkód i rozwiązałem wiele problemów.
5 6.MOŻLIWOŚCI ROZWOJU SYSTEMU 6.1. Wprowadzenie We wczesnym etapie planowania projektu jednym z jego głównych elementów było wymaganie, które mówiło iż projekt powinien być dalej rozwijany po jego ukończeniu. Zostało jasno powiedziane, iż należy go tak przygotować, aby potem można było go w prosty sposób rozwijać i podzielić jego dalszą pracę nad nim nad poszczególnymi modułami. I tak też się stało. 6.2. Rozwój klienta System można wzbogacić o dodatkowe możliwości konfiguracyjne dla użytkownika. Użytkownik mógłby podać swoje imię lub inne dane, które były by uwzględniane podczas dalszej interakcji z systemem. Można by dać możliwość wyboru postaci Awatara, głosu przez niego używanego oraz np. możliwości zmiany Mózgu, która charakteryzowała by się całkowicie odmienną pracą systemu. 6.3. Rozwój systemu generowania mowy System generowania mowy można wyposażyć w dodatkowe głosy, które mogą być przełączane po stronie klienta. Istnieje także możliwość, aby utworzyć własne głosy, jest to jednak zadanie bardzo pracochłonne i obarczone dużym ryzykiem niepowodzenia. Ogólnie jest możliwość dodania głosów w innych wersjach językowych, jednak w tym miejscu problemem może okazać się brak możliwości dostosowania systemu rozpoznawania mowy w tych językach1 . Istnieje możliwość doposażenia systemu w nowe dodatkowe możliwości sterujące generacją głosu w rodzaju możliwości sterowania prędkością, wysokością i częstotliwością 1 Problem ten dotyczy sytuacji dnia dzisiejszego.
5. Możliwości rozwoju systemu 38 głosu. Także w tym miejscu można przygotować obsługę poprawnej wymowy znaków specjalnych, skrótów i innych zapisów specjalnych. 6.4. Rozwój systemu rozpoznawania mowy System rozpoznawania mowy można wyposażyć w kolejne komendy jeszcze bardziej zaawansowane oraz o większą ich ilość. Teoretycznie istnieje możliwość nauczenia systemu do rozpoznawania nowych nazw jeszcze nie zdefiniowanych w istniejących słownikach, co jest bardzo czasochłonne i obarczone jest dużym ryzykiem niepowadzenia. Można tutaj pomyśleć o implementacji mechanizmów rozpoznawania ciągłej mowy. 6.5. Rozwój postaci Awatara Postać Awatara można dopracować graficznie, dopieścić jego animację i reakcję na zmianę stanu. Można by stworzyć pakiet postaci Awatarów, z których użytkownik mógłby wybrać ten z którym chciał by się utożsamić. 6.6. Rozwój Mózgu Rozwój Mózgu daje najwięcej możliwości ponieważ może całkowicie zmienić zachowanie systemu w danej sytuacji. Można by dodać do Mózgu informacje o danych poczynaniach danego klienta, np. w celu usunięcia głupich odpowiedzi w nieskończoność typu „Jak się nazywasz?”, gdzie po kilku takich pytaniach Awatar mógłby zwrócić uwagę klientowi, iż pytał się już o to wielokrotnie. Co najważniejsze można by pomyśleć o implementacji autonomicznego umysłu Awatara, który w określonych warunkach mógłby samodzielnie podejmować decyzję, jak ma to miejsce np. w Dictobot’cie oraz wiernie zaimplementować jego stan. 6.7. Podsumowanie Na rynku obecnie nie ma zbyt wiele (o ile istnieją) takich lub podobnych systemów. Warto podjąć kontynuację niniejszego projektu oraz zbadać i przetestować nowe możliwości, które on ze sobą niesie.
6 7.PODSUMOWANIE ORAZ WNIOSKI Z PRACY 7.1. Podsumowanie oraz wnioski z pracy Praca nad systemem była wymagająca, rozwojowa, ale i wciągająca. System który powstał jest niekonwencjonalny, przełamał wiele barier technologicznych oraz pokazał praktyczne zastosowanie wielu różnych technologii. W chwili obecnej nie udało mi się znaleźć żadnego odpowiednika niniejszego systemu1 lub systemu, który w dużej części odpowiadał by obecnej realizacji. Do jego realizacji poświęciłem naprawdę wiele czasu, wiele nocy nie przespałem, kilka tygodni wolnego z pracy także zostało spożytkowane w tym celu. Sporą część realizacji zawdzięczam Panu prof. dr hab. inż. Zdzisław Kowalczuk, który nadał kierunek i pokierował pracą w tę stronę, w której praca obecnie się znajduje a także poświęcił wiele czasu nad jej realizacją, za co jestem bardzo wdzięczny. Wykonanie systemu było dla mnie niezwykle rozwijające, nauczyłem się wiele z samych technologii informatycznych, ale także poznałem elementy, które nadają „życia” temu komputerowemu projektowi. Był to czas, którego nie żałuję iż wykorzystałem go w taki a nie w inny sposób. Projekt obecnie znajduje się na wstępnej rozwojowej drodze, tak więc nadaje się on do podjęcia jego rozbudowy i dopracowania, tak aby był w stanie godnym przedstawienia go szerszemu gronu odbiorców. 1 Mogę z wielką pewnością stwierdzić, iż taki odpowiednik nie istnieje wcale.
40 8.Dodatek 1. Skrótowy opis aplikacji Tytuł dyplomu System inteligentnej nawigacji sterowanej głosem po serwisie internetowym. Cel i przeznaczenie aplikacji Opracowanie głosowego systemu komunikacji oraz nawigacji po serwisie internetowym. Projekt zakłada wykonanie portalu testowego, systemu rozpoznawania i generowania mowy, mózgu systemu oraz postaci Awatara komunikującego się z użytkownikami oraz kierującego ich po serwisie. System ma być inteligentny w tym znaczeniu, iż Awatar nie będzie nas tylko słuchał, ale także będzie z nami w dialogu wyrażając się poprzez swoje emocje. Wykonanie projektu zakłada komunikację w języku angielskim. Funkcjonalność Opis realizowanych funkcji  Praca w Internecie bez potrzeby zalogowania się  Równoczesna obsługa wielu użytkowników w osobnych wątkach  Stan Awatara wyposażony w 4 niezależne wartości  Pamięć stanu Awatara  Rozpoznawanie wybranych komend głosowych  Generowanie mowy z uwzględnieniem aktualnego stanu Awatara  Odtwarzanie oraz nagrywanie mowy w czasie rzeczywistym  Konwersja formatów: FLV -> WAV -> MP3 w osobnych wątkach  Funkcjonalny portal demonstracyjny  Panel administratora  Niezależny Mózg systemu generujący mowę, odpowiedź i przekierowanie w zależności od kontekstu jako Web-Service  Wizualizacja postaci Awatara, który graficznie przedstawia swój stan  Animacja ruchu ust Awatara podczas jego mowy  Prosta implementacja modulacji głosu Awatara w zależności od jego stanu  Możliwość edycji generowanych komunikatów głosowych  Podgląd stanu bazy danych poprzez Panel Administracyjny  Pamięć użytkownika poprzez całą komunikację po portalu (wielo-stronnicowa)  Rozpoznanie czy użytkownik przyszedł po raz pierwszy na Portal czy powrócił tu ponownie, np. zmieniając wyświetlaną stronę  Przekierowanie na nową stronę portalu na podstawie wydanej komendy głosowej  Głosowa wiadomość powitalna dla każdej pod-strony  Zaawansowany system zdarzeń informacji o pracy całego systemu po stronie użytkownika, który daje wgląd w pracę całego systemu we wszystkich modułach  Kompresja wygenerowanej mowy w celu przyśpieszenia odtworzenia wiadomości  Zaimplementowana najwyższa jakość generowanego i rozpoznanego głosu, jaki daje zastosowana biblioteka (zastosowane ustawienia na 16kHz)  Mechanizm kilkukrotnego ponowienia odtworzenia oczekującej wiadomości głosowej o ile system nie został jeszcze w pełni zainicjalizowany  Osobne przechowywanie plików audio dla wejścia i wyjścia sygnału
41  Funkcja zapominania stanu Awatara po stronie klienta  Opcja nagrywania mowy za pomocą jednego wciśnięcia i przytrzymania przycisku  Zastosowany system znaczników mowy pozwalający na implementację tego systemu na dowolny Portal Internetowy. Lista przykładowych zastosowań  Odsłuchiwanie zawartości strony Portalu Internetowego  Umilenie pracy użytkownika  Nawigacja po portalu za pomocą wykorzystania własnego głosu  Zabawa z Awatarem w celu rozpoznania jego emocji poprzez odsłuchiwanie jego mowy  Dialog z Awatarem, po odpowiednim dopracowaniu Mózgu można zrobić z niego tzw. Zwierzątko, które będzie żyło własnym życiem  Po odpowiednim dopracowaniu inteligentne wyszukiwanie i filtrowanie zawartości portalu. Szczegółowe opisy działania aplikacji Aplikacja jest typu klient-server. Klient jest to część, która znajduje się po stronie użytkownika, zapewnia ona komunikację z serwerem, jest ona interfejsem użytkownika, który wydaje komendy głosowe, odsłuchuje komunikaty oraz przedstawia graficzną postać Awatara zmieniającą się w zależności od swojego stanu. Serwer zajmuje się rozpoznawaniem oraz generowaniem mowy, obsługą połączeń klientów oraz komunikacją z Mózgiem systemu. Wykonany system jest platformą, portal demonstracyjny jest jedynie pokazem jego zastosowania. Z tego względu działanie aplikacji możemy wydzielić na dwie części. Pierwszą z nich jest wygenerowanie na podstawie wcześniej przygotowanych znaczników mowy zawartości portalu, która posłuży Mózgowi do odsłuchania (wygenerowania mowy), wyszukania informacji oraz przekierowania w odpowiednie miejsce portalu. Za tę część odpowiedzialny jest system znaczników oraz część administracyjna, która generuje treść portalu bazując na dostarczonym sitemap strony. Generator przechodząc kolejno przez strony zapisane w sitemap, parsuje je, wyciąga przygotowane informacje oraz w odpowiedni sposób indeksuje i buforuje dane w bazie danych. Działanie samego systemu opiera się na samoistnej świadomości Awatara, który wyposażony jest w mechanizm „zapominania”, który działa wyłącznie po stronie klienta. Stan Awatara przechowywany jest na komputerze klienta i zapamiętywany jest nie tylko poprzez daną sesję użytkownika (które de facto nie wymaga chociażby zalogowania się do systemu), ale pamiętany jest od czasu ostatnich odwiedzin portalu internetowego. Pamięć ta opiera się na mechanizmie Shared Object platformy Adobe Flash, który w uproszczeniu1 jest odpowiednikiem pliku ciasteczka (ang. cookie). Użytkownik wchodząc na portal w pierwszej kolejności zostaje przywitany odpowiednim komunikatem oraz zostaje zapamiętany w systemie, tak że podczas kolejnej wizyty w trakcie danej sesji zostanie on już w inny sposób obsłużony, tzn. otrzyma inny komunikat powitalny. Obsługa rozpoznania klienta znajduje się po stronie Serwera Mowy, który posiada zapisaną listę aktualnie podłączonych klientów. Podczas każdego załadowania strony następuje inicjalizacja połączenia, każde połączenie jest weryfikowane czy może zostać obsłużone w kanale RTMP zapewniającym nagrywanie i odsłuchiwanie komunikatów głosowych w czasie rzeczywistym. Także w tym momencie następuje rezerwacja mikrofonu oraz zapytanie o zgodę na jego wykorzystanie. Gdy proces ten przebiegnie pomyślnie Serwer Mowy przesyła dla klienta potwierdzenie, iż połączenie 1 Tak naprawdę Shared Object jest obiektem o wiele bardziej zaawansowanym niż ciasteczko.
42 zostało nawiązane, wówczas klient w odpowiedzi przesyła prośbę o wygenerowanie komunikatu powitalnego oraz przesyła swój stan (emocje, które w danym momencie mogą być inne niż domyślne). Na podstawie prośby i stanu Serwer Mowy za pośrednictwem Mózgu generuje wiadomość powitalną, która na bazie zaktualizowanego stanu Awatara zostaje odpowiednio zmodulowana2 . Informacja o wygenerowanej i oczekującej wiadomości do odsłuchania zostaje przesłana dla klienta, który automatycznie odtwarza ją3 . Równocześnie klient otrzymuje od Mózgu za pośrednictwem serwera mowy bodziec zmieniający stan Awatara (jego emocje), który zostaje już stopniowo zaktualizowany po stronie klienta4 . Podobnie ma się sprawa z wysłaniem komendy głosowej, która nagrywana jest podczas przyciśnięcia i przytrzymania przycisku „Speak”. W tym czasie mowa zostaje bezpośrednio nagrywana na serwerze mowy. Po zakończeniu nagrywania komendy głosowej, zostaje pobrany stan Awatara od klienta, z nagranej mowy zostaje rozpoznana komenda głosowa, która przesyłana zostaje do Mózgu systemu. Mózg posiadając informacje o aktualnym stanie Awatara generuje odpowiedź, która przekazywana jest do klienta. Odpowiedź zawiera wygenerowany komunikat głosowy, zmianę stanu Awatara (emocji) oraz ewentualnie adres nowej strony, na którą klient powinien zostać automatycznie przekierowany. Architektura sprzętu Elementy rozpoznawania i generowania mowy wymagają silnego serwera, aby były w stanie obsłużyć wielu użytkowników równocześnie oraz aby zapewnić krótkie czasy reakcji na wypowiadane i generowane komendy głosowe. Do pracy z systemem wymaga się komputera wyposażonego w głośniki i mikrofon, które nie są wymagane po stronie serwera. Do wykonania systemu korzystałem z dwóch środowisk:  deweloperskie – wyposażone w komputer o procesorze Pentium 4x2.66 GHz oraz 4 GB RAM, 300 GB HDD  produkcyjne – wyposażone w komputer o procesorze Pentium 4x2.66 GHz oraz 16 GB RAM, o przepustowości Internetu 100Mbps oraz 2TB HDD System wymaga silnego serwera oraz dużej przestrzeni dyskowej, ponieważ dla jednego użytkownika podczas kilku godzin pracy generowanych jest kilkaset megabajtów danych audio w przeciągu kilku dni5 . Architektura oprogramowania Architektura systemu została przedstawiona na rys. 7.1. Cały system został wytworzony w technologii Java/Flex. Technologia Adobe Flex została wykorzystana do utworzenia klienta, natomiast część serwerowa została wykonana w technologii Java. Budowa platformy jest modułowa, umożliwiająca niezależny rozwój i wymianę każdego z modułów. 2 Modulacja polega na zmianie parametrów audio generowanej mowy. 3 Odtworzenie nagranego komunikatu głosowego następuje w czasie rzeczywistym przy wykorzystaniu protokołu RTMP. 4 Zmiany stanu (emocji) Awatara dokonywane są po stronie klienta na bazie otrzymanych informacji o ile dany stan (emocja) powinien zostać zmieniony. 5 Do klienta zostaje przesłany materiał w wersji skompresowanej o kilku, a czasem kilkunasto krotnie mniejszej objętości. Tylko po stronie serwera zostają wygenerowane dane o dostępnej najwyższej jakości danych, które następnie zostają skompresowane i przekazane dla klienta.
43 Rys. 7.1. Ogólna architektura systemu. Część kliencka odpowiada za komunikację z serwerem, przydzieleniem uprawnień do mikrofonu i głośników, wygenerowaniem unikalnego identyfikatora dla klienta, który następnie jest wykorzystywany przez serwer do jego identyfikacji. Także w tej części użytkownik ma kontakt z systemem, obserwuje wizualnie postać Awatara, wydaje komendy oraz słucha systemu, tutaj także znajduje się aktualna wizualizacja stanu Awatara w postaci wykresu słupkowego oraz konsola logów z całego systemu, w której użytkownik monitoruje stan systemu w danym momencie. Po stronie klienta przechowywany jest aktualny stan Awatara unikalny dla każdego użytkownika. jednak jest on przypisany na stałe do danego komputera, a czasem przeglądarki. Część serwerowa została oznaczona kolorem zielonym. Fizycznie część ta podzielona jest na dwa serwery: serwer mowy jest serwerem czasu rzeczywistego, jest to serwer Red5 RC 1.0, który opiera się na platformie Apache Tomcat 6 działający na porcie 8080 dla protokołu HTML oraz na porcie 1935 dla protokołu RTMP, drugim serwerem jest Oracle WebLogic 11g na którym działa „Mózg” systemu, część administracyjna oraz portal demonstracyjny. Sewer standardowo działa na porcie 7001 dla protokołu HTML. Serwer mowy jest kluczowym elementem całego systemu, zwyczajowo nazywany „serwerem” niniejszego systemu. To bezpośrednio z nim komunikuje się klienta (a w zasadzie użytkownik systemu). Serwer ten wydziela dalszą interakcję z użytkownikiem. Na serwerze tym zostały utworzone moduły generowania i syntezy mowy, klienta mózgu, obsługi i konwersji danych audio przesyłanych w czasie rzeczywistym. Także w tym miejscu znajduje się lista słów i komend rozpoznawalnych przez system w formacie JSGF (ang. Java Speech Grammar Format). W tym miejscu mamy konfiguracje systemów rozpoznawania i syntezy mowy w formatach zdefiniowanych przez specyfikacje bibliotek FreeTTS oraz Sphinx4.
44 Wykonany serwer mowy posiada architekturę wielo-wątkową6 (ang. Multithreading), tak więc każde żądanie nowego klienta obsługiwane jest w nowym wątku. Konwersje formatów danych audio są także wykonywane wielo wątkowo. Rozpoznanie komendy głosowej z wygenerowaniem odpowiedzi również zachodzi w osobnym wątku. Wymienione elementy posiadają wykonaną własną implementację nie zależną od standardu Javy, która samodzielnie próbuje dzielić zadania na wiele wątków. Mózg jest drugim serwerem, który odpowiada za logikę aplikacji. Komunikuje się on bezpośrednio i wyłącznie z systemem mowy, od którego dostaje komendę użytkownika już w postaci tekstowej, identyfikator klienta oraz stan Awatara oraz zwraca akcję do wykonania przez klienta wraz z komendą zmiany stanu Awatara lub wykonania przekierowania do innej strony w portalu internetowym. Komunikacja systemu mowy następuje poprzez klienta Mózgu, który komunikuje serwer mowy z „Mózgiem” poprzez protokół SOAP przy wykorzystaniu dokumentu WSDL w technologii rozproszonej SOA. To rozwiązanie umożliwia łatwe dodawanie nowych implementacji Mózgu oraz przełączanie ich w czasie działania aplikacji. Mózg na podstawie otrzymanych danych i przetworzeniu posiadanych decyduje o wykonanej interakcji w portalu internetowym za pośrednictwem serwera mowy, który dodatkowo może wygenerować komunikaty głosowe dla użytkownika oraz przesłać komunikaty zmiany stanu Awatara lub zadecydować o wykonaniu przekierowania użytkownika do innej strony na portalu internetowym. Klient łączy się z częścią serwerową za pośrednictwem protokołów RTMP i AMF (ang. Action Message Format). Za pomocą protokołu RTMP przesyłany jest wyłącznie sygnał audio w czasie rzeczywistym bez potrzeby przesyłania całego materiału w całości7 . Natomiast protokół AMF służy wyłącznie do wymiany komunikatów pomiędzy serwerem a klientem. Komunikaty te zawierają informacje typu: stan Awatara, komendy tekstowe przesyłane do serwera w postaci czytelnego tekstu, informacje zwrotne dla klienta kiedy czeka na niego wiadomość do odsłuchania, komunikaty logów8 ze strony serwera itp. Klient-serwer komunikuje się ze sobą wyłącznie za pośrednictwem tych dwóch protokołów. Serwer mowy komunikuje się z Mózgiem za pośrednictwem protokołu SOAP w technologii rozproszonej SOA. Wyłącznie Mózg komunikuje się z bazą danych. W ten sposób zostały jasno wyznaczone warstwy systemu. Opis metody wytwarzania aplikacji Cykl wytworzenia niniejszej aplikacji przedstawia się następująco: 1. zapoznanie się z technologią Speech oraz AI 2. wykonanie systemu analizy serwisu 3. system generowania oraz rozpoznawania mowy 4. silnik AI wraz z inicjacją "świadomości" bota oraz z implementacją 4 stanów emocji 5. stworzenie prostej graficznej postaci Awatara komunikującej się z silnikiem AI 6 Architektura wielo-wątkowa pozwala na równoległą realizację żądań wielu użytkowników równocześnie. Najczęściej żądania są rozdzielane równomiernie na dostępne procesory i rdzenie dzięki czemu wykonywane operacje powinny odbywać się szybciej (choć nie zawsze, jeżeli liczba wątków jest zbyt duża) i powinny pozwolić na wykonanie danej operacji przez nowego użytkownika bez potrzeby oczekiwania na zakończenie wykonywanych operacji przez innych użytkowników (jednak w praktyce nie zawsze tak jest, jest to zależne od danej implementacji). 7 Protokół RTMP w odróżnieniu od innych protokołów naprawdę przesyła dane w czasie rzeczywistym. Inne protokoły najczęściej „udają”, że przesyłają materiał czasie rzeczywistym, lecz np. przesyłają go w partiach, a nie bit po bicie jak dzieje się to w przypadku wykorzystania protokołu RTMP. 8 Komunikaty te informują klienta co dzieje się po stronie serwera. W przypadku jakichkolwiek problemów po stronie serwera klient jest informowany o tym fakcie.
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym
System inteligentnej nawigacji sterowanej głosem po serwisie internetowym

Recomendados

Prolog. Programowanie
Prolog. ProgramowanieProlog. Programowanie
Prolog. ProgramowanieWydawnictwo Helion
 
eXtreme programming
eXtreme programmingeXtreme programming
eXtreme programmingWydawnictwo Helion
 
Programowanie w języku C. FAQ
Programowanie w języku C. FAQProgramowanie w języku C. FAQ
Programowanie w języku C. FAQWydawnictwo Helion
 
Java. Tworzenie aplikacji sieciowych za pomocą Springa, Hibernate i Eclipse
Java. Tworzenie aplikacji sieciowych za pomocą Springa, Hibernate i EclipseJava. Tworzenie aplikacji sieciowych za pomocą Springa, Hibernate i Eclipse
Java. Tworzenie aplikacji sieciowych za pomocą Springa, Hibernate i EclipseWydawnictwo Helion
 
Praktyczny kurs Java
Praktyczny kurs JavaPraktyczny kurs Java
Praktyczny kurs JavaWydawnictwo Helion
 
Czytanie kodu. Punkt widzenia twórców oprogramowania open source
Czytanie kodu. Punkt widzenia twórców oprogramowania open sourceCzytanie kodu. Punkt widzenia twórców oprogramowania open source
Czytanie kodu. Punkt widzenia twórców oprogramowania open sourceWydawnictwo Helion
 
Perełki programowania gier. Vademecum profesjonalisty. Tom 2
Perełki programowania gier. Vademecum profesjonalisty. Tom 2Perełki programowania gier. Vademecum profesjonalisty. Tom 2
Perełki programowania gier. Vademecum profesjonalisty. Tom 2Wydawnictwo Helion
 
ActionScript. Receptury
ActionScript. RecepturyActionScript. Receptury
ActionScript. RecepturyWydawnictwo Helion
 

Recomendados

Prolog. Programowanie
Prolog. ProgramowanieProlog. Programowanie
Prolog. ProgramowanieWydawnictwo Helion
 
eXtreme programming
eXtreme programmingeXtreme programming
eXtreme programmingWydawnictwo Helion
 
Programowanie w języku C. FAQ
Programowanie w języku C. FAQProgramowanie w języku C. FAQ
Programowanie w języku C. FAQWydawnictwo Helion
 
Java. Tworzenie aplikacji sieciowych za pomocą Springa, Hibernate i Eclipse
Java. Tworzenie aplikacji sieciowych za pomocą Springa, Hibernate i EclipseJava. Tworzenie aplikacji sieciowych za pomocą Springa, Hibernate i Eclipse
Java. Tworzenie aplikacji sieciowych za pomocą Springa, Hibernate i EclipseWydawnictwo Helion
 
Praktyczny kurs Java
Praktyczny kurs JavaPraktyczny kurs Java
Praktyczny kurs JavaWydawnictwo Helion
 
Czytanie kodu. Punkt widzenia twórców oprogramowania open source
Czytanie kodu. Punkt widzenia twórców oprogramowania open sourceCzytanie kodu. Punkt widzenia twórców oprogramowania open source
Czytanie kodu. Punkt widzenia twórców oprogramowania open sourceWydawnictwo Helion
 
Perełki programowania gier. Vademecum profesjonalisty. Tom 2
Perełki programowania gier. Vademecum profesjonalisty. Tom 2Perełki programowania gier. Vademecum profesjonalisty. Tom 2
Perełki programowania gier. Vademecum profesjonalisty. Tom 2Wydawnictwo Helion
 
ActionScript. Receptury
ActionScript. RecepturyActionScript. Receptury
ActionScript. RecepturyWydawnictwo Helion
 
6-wall CAVE Immersive 3D Visualization Laboratory Demonstrator
6-wall CAVE Immersive 3D Visualization Laboratory Demonstrator6-wall CAVE Immersive 3D Visualization Laboratory Demonstrator
6-wall CAVE Immersive 3D Visualization Laboratory DemonstratorJan Klimczak
 
Superkomputery i Symulacje (HPC) - AMG.net, NCBJ, WFiIS UŁ
Superkomputery i Symulacje (HPC) - AMG.net, NCBJ, WFiIS UŁSuperkomputery i Symulacje (HPC) - AMG.net, NCBJ, WFiIS UŁ
Superkomputery i Symulacje (HPC) - AMG.net, NCBJ, WFiIS UŁMichal Balinski
 
LTE – Szerokie pasmo, szerokie możliwości
LTE – Szerokie pasmo, szerokie możliwościLTE – Szerokie pasmo, szerokie możliwości
LTE – Szerokie pasmo, szerokie możliwościSektor 3.0
 
Process and Plant Design for DSEAR
Process and Plant Design for DSEARProcess and Plant Design for DSEAR
Process and Plant Design for DSEARChristopher Bell
 
4. Wykorzystanie informacyjnych technik biurowych
4. Wykorzystanie informacyjnych technik biurowych4. Wykorzystanie informacyjnych technik biurowych
4. Wykorzystanie informacyjnych technik biurowychkalaxq
 
Sp rp społeczeństwo
Sp rp społeczeństwoSp rp społeczeństwo
Sp rp społeczeństwop_andora
 
8
88
8Dorota
 
Gadafi
GadafiGadafi
Gadafidanimerinosanchez
 
Analizowanie ekonomicznych uwarunkowań produkcji
Analizowanie ekonomicznych uwarunkowań produkcjiAnalizowanie ekonomicznych uwarunkowań produkcji
Analizowanie ekonomicznych uwarunkowań produkcjiMichał Siwiec
 
6
66
6Dorota
 
Scalone dokumenty (15)
Scalone dokumenty (15)Scalone dokumenty (15)
Scalone dokumenty (15)Darek Simka
 
2. Badanie obwodów prądu stałego
2. Badanie obwodów prądu stałego2. Badanie obwodów prądu stałego
2. Badanie obwodów prądu stałegoLukas Pobocha
 
Depo air minum
Depo air minumDepo air minum
Depo air minumAryan Best Lucky
 
Sporządzanie podstawowego asortymentu potraw z jaj, mleka i przetworów mlecznych
Sporządzanie podstawowego asortymentu potraw z jaj, mleka i przetworów mlecznychSporządzanie podstawowego asortymentu potraw z jaj, mleka i przetworów mlecznych
Sporządzanie podstawowego asortymentu potraw z jaj, mleka i przetworów mlecznychMarcin Dzieciątkowski
 
Structures of Predication Introduction
Structures of Predication IntroductionStructures of Predication Introduction
Structures of Predication IntroductionSherlynDeLosSantos
 
Scalone dokumenty (16)
Scalone dokumenty (16)Scalone dokumenty (16)
Scalone dokumenty (16)Darek Simka
 
4
44
4Szymon Konkol - Publikacje Cyfrowe
 
Explanatory Case Study (ECS) method: A Brief Summary
Explanatory Case Study (ECS) method: A Brief SummaryExplanatory Case Study (ECS) method: A Brief Summary
Explanatory Case Study (ECS) method: A Brief Summarysophieproject
 
Second conditional
Second conditionalSecond conditional
Second conditionalSantiago Rodriguez
 
C15 U2 Project finished and unfinished actions. present perfect and present...
C15 U2 Project finished and unfinished actions. present perfect and present...C15 U2 Project finished and unfinished actions. present perfect and present...
C15 U2 Project finished and unfinished actions. present perfect and present...colomboamericanopereira
 
Microsoft Visual C++ 2008. Tworzenie aplikacji dla Windows
Microsoft Visual C++ 2008. Tworzenie aplikacji dla WindowsMicrosoft Visual C++ 2008. Tworzenie aplikacji dla Windows
Microsoft Visual C++ 2008. Tworzenie aplikacji dla WindowsWydawnictwo Helion
 
Pocket PC
Pocket PCPocket PC
Pocket PCWydawnictwo Helion
 

Mais conteúdo relacionado

Destaque

6-wall CAVE Immersive 3D Visualization Laboratory Demonstrator
6-wall CAVE Immersive 3D Visualization Laboratory Demonstrator6-wall CAVE Immersive 3D Visualization Laboratory Demonstrator
6-wall CAVE Immersive 3D Visualization Laboratory DemonstratorJan Klimczak
 
Superkomputery i Symulacje (HPC) - AMG.net, NCBJ, WFiIS UŁ
Superkomputery i Symulacje (HPC) - AMG.net, NCBJ, WFiIS UŁSuperkomputery i Symulacje (HPC) - AMG.net, NCBJ, WFiIS UŁ
Superkomputery i Symulacje (HPC) - AMG.net, NCBJ, WFiIS UŁMichal Balinski
 
LTE – Szerokie pasmo, szerokie możliwości
LTE – Szerokie pasmo, szerokie możliwościLTE – Szerokie pasmo, szerokie możliwości
LTE – Szerokie pasmo, szerokie możliwościSektor 3.0
 
Process and Plant Design for DSEAR
Process and Plant Design for DSEARProcess and Plant Design for DSEAR
Process and Plant Design for DSEARChristopher Bell
 
4. Wykorzystanie informacyjnych technik biurowych
4. Wykorzystanie informacyjnych technik biurowych4. Wykorzystanie informacyjnych technik biurowych
4. Wykorzystanie informacyjnych technik biurowychkalaxq
 
Sp rp społeczeństwo
Sp rp społeczeństwoSp rp społeczeństwo
Sp rp społeczeństwop_andora
 
Analizowanie ekonomicznych uwarunkowań produkcji
Analizowanie ekonomicznych uwarunkowań produkcjiAnalizowanie ekonomicznych uwarunkowań produkcji
Analizowanie ekonomicznych uwarunkowań produkcjiMichał Siwiec
 
Scalone dokumenty (15)
Scalone dokumenty (15)Scalone dokumenty (15)
Scalone dokumenty (15)Darek Simka
 
2. Badanie obwodów prądu stałego
2. Badanie obwodów prądu stałego2. Badanie obwodów prądu stałego
2. Badanie obwodów prądu stałegoLukas Pobocha
 
Sporządzanie podstawowego asortymentu potraw z jaj, mleka i przetworów mlecznych
Sporządzanie podstawowego asortymentu potraw z jaj, mleka i przetworów mlecznychSporządzanie podstawowego asortymentu potraw z jaj, mleka i przetworów mlecznych
Sporządzanie podstawowego asortymentu potraw z jaj, mleka i przetworów mlecznychMarcin Dzieciątkowski
 
Structures of Predication Introduction
Structures of Predication IntroductionStructures of Predication Introduction
Structures of Predication IntroductionSherlynDeLosSantos
 
Scalone dokumenty (16)
Scalone dokumenty (16)Scalone dokumenty (16)
Scalone dokumenty (16)Darek Simka
 
Explanatory Case Study (ECS) method: A Brief Summary
Explanatory Case Study (ECS) method: A Brief SummaryExplanatory Case Study (ECS) method: A Brief Summary
Explanatory Case Study (ECS) method: A Brief Summarysophieproject
 
C15 U2 Project finished and unfinished actions. present perfect and present...
C15 U2 Project finished and unfinished actions. present perfect and present...C15 U2 Project finished and unfinished actions. present perfect and present...
C15 U2 Project finished and unfinished actions. present perfect and present...colomboamericanopereira
 

Destaque (20)

6-wall CAVE Immersive 3D Visualization Laboratory Demonstrator
6-wall CAVE Immersive 3D Visualization Laboratory Demonstrator6-wall CAVE Immersive 3D Visualization Laboratory Demonstrator
6-wall CAVE Immersive 3D Visualization Laboratory Demonstrator
 
Superkomputery i Symulacje (HPC) - AMG.net, NCBJ, WFiIS UŁ
Superkomputery i Symulacje (HPC) - AMG.net, NCBJ, WFiIS UŁSuperkomputery i Symulacje (HPC) - AMG.net, NCBJ, WFiIS UŁ
Superkomputery i Symulacje (HPC) - AMG.net, NCBJ, WFiIS UŁ
 
LTE – Szerokie pasmo, szerokie możliwości
LTE – Szerokie pasmo, szerokie możliwościLTE – Szerokie pasmo, szerokie możliwości
LTE – Szerokie pasmo, szerokie możliwości
 
Process and Plant Design for DSEAR
Process and Plant Design for DSEARProcess and Plant Design for DSEAR
Process and Plant Design for DSEAR
 
4. Wykorzystanie informacyjnych technik biurowych
4. Wykorzystanie informacyjnych technik biurowych4. Wykorzystanie informacyjnych technik biurowych
4. Wykorzystanie informacyjnych technik biurowych
 
Sp rp społeczeństwo
Sp rp społeczeństwoSp rp społeczeństwo
Sp rp społeczeństwo
 
8
88
8
 
Gadafi
GadafiGadafi
Gadafi
 
Analizowanie ekonomicznych uwarunkowań produkcji
Analizowanie ekonomicznych uwarunkowań produkcjiAnalizowanie ekonomicznych uwarunkowań produkcji
Analizowanie ekonomicznych uwarunkowań produkcji
 
6
66
6
 
Scalone dokumenty (15)
Scalone dokumenty (15)Scalone dokumenty (15)
Scalone dokumenty (15)
 
2. Badanie obwodów prądu stałego
2. Badanie obwodów prądu stałego2. Badanie obwodów prądu stałego
2. Badanie obwodów prądu stałego
 
Depo air minum
Depo air minumDepo air minum
Depo air minum
 
Sporządzanie podstawowego asortymentu potraw z jaj, mleka i przetworów mlecznych
Sporządzanie podstawowego asortymentu potraw z jaj, mleka i przetworów mlecznychSporządzanie podstawowego asortymentu potraw z jaj, mleka i przetworów mlecznych
Sporządzanie podstawowego asortymentu potraw z jaj, mleka i przetworów mlecznych
 
Structures of Predication Introduction
Structures of Predication IntroductionStructures of Predication Introduction
Structures of Predication Introduction
 
Scalone dokumenty (16)
Scalone dokumenty (16)Scalone dokumenty (16)
Scalone dokumenty (16)
 
4
44
4
 
Explanatory Case Study (ECS) method: A Brief Summary
Explanatory Case Study (ECS) method: A Brief SummaryExplanatory Case Study (ECS) method: A Brief Summary
Explanatory Case Study (ECS) method: A Brief Summary
 
Second conditional
Second conditionalSecond conditional
Second conditional
 
C15 U2 Project finished and unfinished actions. present perfect and present...
C15 U2 Project finished and unfinished actions. present perfect and present...C15 U2 Project finished and unfinished actions. present perfect and present...
C15 U2 Project finished and unfinished actions. present perfect and present...
 

Semelhante a System inteligentnej nawigacji sterowanej głosem po serwisie internetowym

Microsoft Visual C++ 2008. Tworzenie aplikacji dla Windows
Microsoft Visual C++ 2008. Tworzenie aplikacji dla WindowsMicrosoft Visual C++ 2008. Tworzenie aplikacji dla Windows
Microsoft Visual C++ 2008. Tworzenie aplikacji dla WindowsWydawnictwo Helion
 
Pajączek 5 NxG. Oficjalny podręcznik
Pajączek 5 NxG. Oficjalny podręcznikPajączek 5 NxG. Oficjalny podręcznik
Pajączek 5 NxG. Oficjalny podręcznikWydawnictwo Helion
 
Visual Studio 2005. Programowanie z Windows API w języku C++
Visual Studio 2005. Programowanie z Windows API w języku C++Visual Studio 2005. Programowanie z Windows API w języku C++
Visual Studio 2005. Programowanie z Windows API w języku C++Wydawnictwo Helion
 
Eclipse Web Tools Platform. Tworzenie aplikacji WWW w języku Java
Eclipse Web Tools Platform. Tworzenie aplikacji WWW w języku JavaEclipse Web Tools Platform. Tworzenie aplikacji WWW w języku Java
Eclipse Web Tools Platform. Tworzenie aplikacji WWW w języku JavaWydawnictwo Helion
 
Praktyczny kurs Java. Wydanie II
Praktyczny kurs Java. Wydanie IIPraktyczny kurs Java. Wydanie II
Praktyczny kurs Java. Wydanie IIWydawnictwo Helion
 
Mgr Paweł Traczyński 3266 - Praca dypl
Mgr Paweł Traczyński 3266 - Praca dyplMgr Paweł Traczyński 3266 - Praca dypl
Mgr Paweł Traczyński 3266 - Praca dyplPawe? Traczy?ski
 
Tworzenie aplikacji dla Windows. Od prostych programów do gier komputerowych
Tworzenie aplikacji dla Windows. Od prostych programów do gier komputerowychTworzenie aplikacji dla Windows. Od prostych programów do gier komputerowych
Tworzenie aplikacji dla Windows. Od prostych programów do gier komputerowychWydawnictwo Helion
 
Wstęp do programowania w języku C#
Wstęp do programowania w języku C#Wstęp do programowania w języku C#
Wstęp do programowania w języku C#Wydawnictwo Helion
 
.Net. Najpilniej strzeżone tajemnice
.Net. Najpilniej strzeżone tajemnice.Net. Najpilniej strzeżone tajemnice
.Net. Najpilniej strzeżone tajemniceWydawnictwo Helion
 
Java. Techniki zaawansowane. Wydanie VIII
Java. Techniki zaawansowane. Wydanie VIIIJava. Techniki zaawansowane. Wydanie VIII
Java. Techniki zaawansowane. Wydanie VIIIWydawnictwo Helion
 
122 sposoby na OpenOffice.ux.pl 2.0
122 sposoby na OpenOffice.ux.pl 2.0122 sposoby na OpenOffice.ux.pl 2.0
122 sposoby na OpenOffice.ux.pl 2.0Wydawnictwo Helion
 
Komputer PC w biurze i nie tylko
Komputer PC w biurze i nie tylkoKomputer PC w biurze i nie tylko
Komputer PC w biurze i nie tylkoWydawnictwo Helion
 
Pocket PC. Podręcznik użytkownika
Pocket PC. Podręcznik użytkownikaPocket PC. Podręcznik użytkownika
Pocket PC. Podręcznik użytkownikaWydawnictwo Helion
 

Semelhante a System inteligentnej nawigacji sterowanej głosem po serwisie internetowym (20)

Microsoft Visual C++ 2008. Tworzenie aplikacji dla Windows
Microsoft Visual C++ 2008. Tworzenie aplikacji dla WindowsMicrosoft Visual C++ 2008. Tworzenie aplikacji dla Windows
Microsoft Visual C++ 2008. Tworzenie aplikacji dla Windows
 
Pocket PC
Pocket PCPocket PC
Pocket PC
 
Informatyka
InformatykaInformatyka
Informatyka
 
J2ME. Praktyczne projekty
J2ME. Praktyczne projektyJ2ME. Praktyczne projekty
J2ME. Praktyczne projekty
 
Pajączek 5 NxG. Oficjalny podręcznik
Pajączek 5 NxG. Oficjalny podręcznikPajączek 5 NxG. Oficjalny podręcznik
Pajączek 5 NxG. Oficjalny podręcznik
 
Visual Studio 2005. Programowanie z Windows API w języku C++
Visual Studio 2005. Programowanie z Windows API w języku C++Visual Studio 2005. Programowanie z Windows API w języku C++
Visual Studio 2005. Programowanie z Windows API w języku C++
 
Eclipse Web Tools Platform. Tworzenie aplikacji WWW w języku Java
Eclipse Web Tools Platform. Tworzenie aplikacji WWW w języku JavaEclipse Web Tools Platform. Tworzenie aplikacji WWW w języku Java
Eclipse Web Tools Platform. Tworzenie aplikacji WWW w języku Java
 
Praktyczny kurs Java. Wydanie II
Praktyczny kurs Java. Wydanie IIPraktyczny kurs Java. Wydanie II
Praktyczny kurs Java. Wydanie II
 
Mgr Paweł Traczyński 3266 - Praca dypl
Mgr Paweł Traczyński 3266 - Praca dyplMgr Paweł Traczyński 3266 - Praca dypl
Mgr Paweł Traczyński 3266 - Praca dypl
 
Tworzenie aplikacji dla Windows. Od prostych programów do gier komputerowych
Tworzenie aplikacji dla Windows. Od prostych programów do gier komputerowychTworzenie aplikacji dla Windows. Od prostych programów do gier komputerowych
Tworzenie aplikacji dla Windows. Od prostych programów do gier komputerowych
 
Wstęp do programowania w języku C#
Wstęp do programowania w języku C#Wstęp do programowania w języku C#
Wstęp do programowania w języku C#
 
.Net. Najpilniej strzeżone tajemnice
.Net. Najpilniej strzeżone tajemnice.Net. Najpilniej strzeżone tajemnice
.Net. Najpilniej strzeżone tajemnice
 
Java. Techniki zaawansowane. Wydanie VIII
Java. Techniki zaawansowane. Wydanie VIIIJava. Techniki zaawansowane. Wydanie VIII
Java. Techniki zaawansowane. Wydanie VIII
 
Inventor. Pierwsze kroki
Inventor. Pierwsze krokiInventor. Pierwsze kroki
Inventor. Pierwsze kroki
 
122 sposoby na OpenOffice.ux.pl 2.0
122 sposoby na OpenOffice.ux.pl 2.0122 sposoby na OpenOffice.ux.pl 2.0
122 sposoby na OpenOffice.ux.pl 2.0
 
Delphi. Szybki start
Delphi. Szybki startDelphi. Szybki start
Delphi. Szybki start
 
TCP/IP dla każdego
TCP/IP dla każdegoTCP/IP dla każdego
TCP/IP dla każdego
 
Komputer PC w biurze i nie tylko
Komputer PC w biurze i nie tylkoKomputer PC w biurze i nie tylko
Komputer PC w biurze i nie tylko
 
Pocket PC. Podręcznik użytkownika
Pocket PC. Podręcznik użytkownikaPocket PC. Podręcznik użytkownika
Pocket PC. Podręcznik użytkownika
 
Tcl-Tk. Programowanie
Tcl-Tk. ProgramowanieTcl-Tk. Programowanie
Tcl-Tk. Programowanie
 

System inteligentnej nawigacji sterowanej głosem po serwisie internetowym

  • 1. Gdańsk, wrzesień 2011 POLITECHNIKA GDAŃSKA Wydział Elektroniki Telekomunikacji i Informatyki Katedra Systemów Decyzyjnych Imię i nazwisko dyplomanta: Jan Klimczak Nr albumu: 112006 Forma i poziom studiów: niestacjonarne inżynierskie Kierunek studiów: Informatyka Praca dyplomowa inżynierska Temat pracy: System inteligentnej nawigacji sterowanej głosem po serwisie internetowym Intelligent web navigation voice controlled system Kierujący pracą: prof. dr hab. inż. Zdzisław Kowalczuk Recenzent: Zakres pracy: Opracowanie głosowego systemu komunikacji oraz nawigacji po serwisie internetowym. Projekt zakłada wykonanie portalu testowego, systemu rozpoznawania i generowania mowy, mózgu systemu oraz postaci Awatara komunikującego się z użytkownikami oraz kierującego ich po serwisie. System ma być inteligentny w tym znaczeniu, iż Awatar nie będzie nas tylko słuchał, ale także będzie z nami w dialogu wyrażając się poprzez swoje emocje. Wykonanie projektu zakłada komunikację w języku angielskim. Nr raportu:
  • 2.
  • 3. ....................................................... Imię i nazwisko dyplomanta 1.1.1. OŚWIADCZENIE Oświadczam, że: 1) niniejszą pracę dyplomową wykonałem samodzielnie, 2) wszystkie informacje umieszczone w pracy uzyskane ze źródeł pisanych oraz informacje ustne pochodzące od innych osób zostały udokumentowane w wykazie literatury odpowiednimi odnośnikami. ................................................. podpis dyplomanta
  • 4.
  • 5. Spis treści 1.1.1. OŚWIADCZENIE.....................................................................................................3 2. CEL PRACY ORAZ ROZPOZNANIE TECHNOLOGII..........................................................9 2.1. Wprowadzenie..................................................................................................................9 2.2. Założenia ogólne...............................................................................................................9 2.3. Przegląd istniejących technologii ...................................................................................10 2.3.1. Systemy mowy........................................................................................................10 2.3.2. Systemy Java Speech ..............................................................................................10 2.3.3. Systemy Microsoft Speech......................................................................................11 2.3.4. Systemy rozpoznawania mowy...............................................................................11 2.3.5. Systemy syntezy mowy...........................................................................................11 2.3.6. Przegląd istniejących systemów mowy...................................................................12 2.4. Serwery obsługujące protokół czasu rzeczywistego ......................................................14 2.5. Specyfikacja techniczna .................................................................................................15 2.6. Podsumowanie................................................................................................................17 3. SPRECYZOWANIE WYMAGAŃ FUNKCJONALNYCH....................................................18 3.1. Wprowadzenie................................................................................................................18 3.2. Przeznaczenie systemu ...................................................................................................19 3.3. Funkcja ...........................................................................................................................20 3.4. Podsumowanie................................................................................................................21 4. ZASADA DZIAŁANIA ORAZ OPIS SYSTEMU ..................................................................22 4.1. Wprowadzenie................................................................................................................22 4.2. Architektura systemu......................................................................................................22 4.3. Algorytm działania systemu...........................................................................................25 4.3.1. Przygotowanie systemu mowy................................................................................25 4.3.2. Podłączenie klienta..................................................................................................26 4.3.3. Wygenerowanie mowy i jej odsłuchanie przez użytkownika .................................28 4.3.4. Rozpoznanie wydanej komendy głosowej ..............................................................31 4.3.5. Mózg........................................................................................................................32 4.3.6. Stan (emocje)...........................................................................................................32 4.4. Opis wyników.................................................................................................................33 4.5. Struktura oprogramowania .............................................................................................33 4.6. Podsumowanie................................................................................................................34 5. REALIZACJA PRACY ............................................................................................................35 5.1. Wprowadzenie................................................................................................................35 5.2. Testowanie platformy.....................................................................................................36 5.3. Omówienie sposobów rozwiązania problemów.............................................................36
  • 6. 5.4. Podsumowanie................................................................................................................36 6. MOŻLIWOŚCI ROZWOJU SYSTEMU .................................................................................37 6.1. Wprowadzenie................................................................................................................37 6.2. Rozwój klienta................................................................................................................37 6.3. Rozwój systemu generowania mowy.............................................................................37 6.4. Rozwój systemu rozpoznawania mowy .........................................................................38 6.5. Rozwój postaci Awatara.................................................................................................38 6.6. Rozwój Mózgu ...............................................................................................................38 6.7. Podsumowanie................................................................................................................38 7. PODSUMOWANIE ORAZ WNIOSKI Z PRACY..................................................................39 7.1. Podsumowanie oraz wnioski z pracy .............................................................................39 8. Dodatek 1. Skrótowy opis aplikacji .......................................................................................... 40 Tytuł dyplomu........................................................................................................................... 40 Cel i przeznaczenie aplikacji.....................................................................................................40 Funkcjonalność ......................................................................................................................... 40 Opis realizowanych funkcji...................................................................................................40 Lista przykładowych zastosowań .......................................................................................... 41 Szczegółowe opisy działania aplikacji..................................................................................41 Architektura sprzętu..................................................................................................................42 Architektura oprogramowania ..................................................................................................42 Opis metody wytwarzania aplikacji.......................................................................................... 44 Założenia i sformułowane zadania .......................................................................................45 Specyfikacje........................................................................................................................... 45 Przygotowanie projektu ........................................................................................................45 Prototypowanie i implementacja .......................................................................................... 46 Testowanie ............................................................................................................................ 46 Ocena aplikacji oraz porównanie do innych rozwiązań.......................................................46 Wnioski i perspektywy dalszych prac....................................................................................46 9. Dodatek 2. Instrukcja dla użytkownika.....................................................................................47 Przygotowanie do pracy z systemem....................................................................................47 Komendy sterujące pracą systemu........................................................................................ 50 Lokalne ustawienia systemu .................................................................................................51 10. Dodatek 3. Instrukcja dla administratora ................................................................................52 System znaczników...............................................................................................................52 Mapa strony – sitemap ..........................................................................................................54 Panel administracyjny...........................................................................................................54 Edycja generowanych odpowiedzi z systemu – Avatar Speech ...........................................54 Generator treści systemu.......................................................................................................56
  • 7. Podgląd zawartości wygenerowanej bazy danych na bazie znaczników..............................57 Instrukcja wdrożenia systemu ...............................................................................................57 11. Dodatek 4. Instrukcja dla programisty....................................................................................59 Budowa bazy danych ................................................................................................................59 Specyfikacja komunikacji z Mózgiem ......................................................................................60 Klient (ActionScript) – diagram klas ....................................................................................61 Serwer Mowy (JavaEE)– diagram klas.................................................................................62 System znaczników...................................................................................................................63 Dodanie postaci Awatara ..........................................................................................................64 Konfiguracja systemu rozpoznawania i generowania mowy....................................................66 12. Dodatek 5. Listing kodów źródłowych głównych modułów ..................................................67 Serwer mowy - SpeechServer ...................................................................................................67 Klient - SpeechAvatar ...............................................................................................................82 Model danych – SpeechModel..................................................................................................96 Mózg – BrainService...............................................................................................................100 Administrator – Administrator................................................................................................104 Portal demonstarcyjny – PortalPG..........................................................................................111 13. Bibliografia............................................................................................................................118
  • 8.
  • 9. 2 2.CEL PRACY ORAZ ROZPOZNANIE TECHNOLOGII 2.1. Wprowadzenie Niniejszy projekt ma za zadanie przegląd oraz scalenie istniejących rozwiązań, które umożliwiają sterowanie portalem internetowym za pomocą głosu. Użytkownik otrzymuje możliwość wydawania komend głosowych, a także zapytań odnośnie zawartości portalu. System w odpowiedzi na komendy generuje komunikaty głosowe, które udzielą odpowiedzi na zadane pytania. System także może przenosić użytkownika w inne miejsce portalu, o które prosimy wydając komendy. Do interakcji użytkownika z portalem została utworzona postać Inteligentnego Awatara (ang. Intelligent Avatar) [1], która umożliwia interakcję głosową z systemem. Awatar jest wrażliwy na to co i jak mówimy, posiada swoje emocje, które są uwidocznione podczas komunikacji. Największym wyzwaniem stojącym przy realizacji projektu jest jego rozproszona praca, która umożliwia niezależne sterowanie portalem dla wielu użytkowników jednocześnie poprzez przeglądarkę internetową pracując w trybie on-line1 bez potrzeby zalogowania się do systemu oraz zastosowany silnik sztucznej inteligencji2 i emocji3 postaci Awatara, która pamięta użytkownika i swój stan podczas przeglądania portalu. 2.2. Założenia ogólne Ze względu na skomplikowanie języka polskiego, czego wynikiem jest praktyczny brak implementacji tego języka dla technologii mowy (ang. Speech) (rozpoznawania i syntezy mowy) [2] przedstawiony projekt został wykonany wyłącznie w języku angielskim, co nie wyklucza dalszej jego rozbudowy o kolejne języki w przyszłości. Zakłada się kontynuację pracy oraz dalszy rozwój platformy po ukończeniu projektu, tak więc została zapewniona jego dalsza rozbudowa w sposób mało inwazyjny oraz praktycznie niezależny dla każdego z modułów. 1 W trybie połączonym z Internetem. 2 Moduł nazwany „Mózgiem” niniejszej platformy. 3 Emocje identyfikują stan Awatara, który jest indywidualny dla każdego użytkownika portalu internetowego.
  • 10. 1. Cel pracy oraz rozpoznanie technologii 10 2.3. Przegląd istniejących technologii Sporządzony przegląd zawiera zestawienie istniejących technologii, które zostały uwzględnione w fazie analizy wykonania projektu w obszarze rozpoznawania i generowania mowy. 2.3.1. Systemy mowy Technologie rozpoznawania i syntezy mowy są od wielu lat rozwijane. Jednak semantyka i struktura języka ludzkiego są na tyle skomplikowane, iż obecnie pomimo wielu lat rozwoju nie ma żadnego istniejącego rozwiązania, które było by idealne lub bardzo zadowalające w tym zakresie4 . Wiele projektów zostało albo skomercjonalizowanych5 i obecnie są dostępne do zakupienia po wygórowanych cenach mimo, iż nie oferują fantastycznych rezultatów6 , albo zostało zaprzestanych w rozwoju z różnych powodów7 . Pod pojęciem systemu mowy (ang. Speech) wyróżniamy rozwiązania, które w mniejszym lub większym stopniu umożliwiają rozpoznanie mowy (ang. Speech Recognition) [3] lub/i jej syntezę, czyli wygenerowanie mowy na podstawie tekstu (ang. Speech Synthesis) [4] za pośrednictwem własnych bibliotek oraz ich interfejsów API. W tym obszarze możemy wyróżnić dwa czołowe rozwiązania: system mowy firmy Microsoft (ang. Microsoft Speech) [5] oraz system mowy Java (ang. Java Speech) [6]. Praktycznie wszystkie obecne rozwiązania na nich bazują. Dzięki nim otrzymujemy dostęp do framework'u, który umożliwia nam ich swobodne zastosowanie. Oczywiście na rynku istnieją inne rozwiązania, ale zazwyczaj są one przeznaczone do ściśle określonych celów, a sama ich licencja oraz brak dostępu do ich kodu uniemożliwia szersze ich wykorzystanie. 2.3.2. Systemy Java Speech Java Speech API (ang. Java Speech Application Programming Interface, JSAPI) [7] umożliwia wykorzystanie systemu mowy (ang. Speech) w między-platformowych aplikacjach opierających się na technologii Java [8]. Dzięki zastosowaniu JSAPI otrzymujemy obsługę komend i kontroli aplikacji poprzez rozpoznawanie mowy, system obsługujący gramatykę (ang. Dictation System) [9] oraz syntezer mowy (ang. Speech Synthesis) dla rozwiązań osobistych lub klasy korporacyjnej. Java Speech API obsługuje rozpoznawanie oraz syntezę mowy. Podstawową korzyścią korzystania z technologii Java jest to, iż otrzymujemy rozwiązanie z otwartym dostępem do kodu (ang. Open Source) [10] oraz pełną zgodność między- platformową (możliwość uruchomienia aplikacji na wielu platformach, w tym.: Microsoft, Macintosh oraz Linux, ang. Cross-Platform) praktycznie bez wykonywania dodatkowej pracy w tym zakresie. Java Speech API zostało utworzone przez SUN Microsystems, obecnie Oracle Corporation [11] przy współpracy z przodującymi na tamte czasy firmami8 , które zajmowały się systemami rozpoznawania mowy: Apple Computers, Inc. [12] , AT&T [13], Dragon System, Inc. [14], IBM Corporation [15], Novell, Inc. [16], Philips [17], Texas Instruments [18]. 4 W znaczeniu poprawności rozpoznawania i generowania mowy. 5 Rozwijanych przez firmy i odsprzedawanych po wygórowanych cenach. 6 Pomimo wielu lat rozwoju nie ma obecnie takiego systemu, który zastąpił by człowieka. 7 Większość rozwijanych projektów realizowana była przez uczelnie, jednak wiele z nich zostało zakończonych i nie jest już rozwijana. 8 Dotyczy to lat 80-90 bieżącego stulecia.
  • 11. 1. Cel pracy oraz rozpoznanie technologii 11 Pierwsza wersja Java Speech API została utworzona i zaakceptowana w 1998 roku. Od tego też czasu nic się w niej nie zmieniło, nie była także modernizowana. Obecnie tylko różne jej implementacje są rozwijane. W 2001 roku rozpoczęto prace nad specyfikacją Java Speech API 2 (ang. JSAPI 2) dostępną jako zgłoszenie JSR 113 (ang. Java Specification Request: JavaTM Speech API 2.0) [19]. Pace nad nią trwały przez 8 lat. Jedną z głównych korzyści będzie zgodność z zaproponowanym frameworkiem mowy dla przeglądarek internetowych przez W3C9 (ang. W3C Speech Interface Framework) [20] poprzez zastosowanie znaczników HTML bezpośrednio na stronie internetowej oraz kompatybilność z interfejsem programowania systemu mowy (ang. Speech Application Programming Interface) [21] wywodzącym się z Microsoft’u. Jednak na JSAPI 2 musimy jeszcze troszkę poczekać ponieważ do dnia dzisiejszego nie ma praktycznie żadnej działającej implementacji gotowej do wdrożenia i zastosowania. 2.3.3. Systemy Microsoft Speech Microsoft posiada dobrze rozwinięty system mowy. Na jego stronie „Microsoft Tellme speech innovation” [22] zostały dobrze opisane technologie przez niego wspierane. Technologie te pozwalają na rozpoznawanie oraz generowanie mowy (ang. Speech Synthesis and Recognition) w wielu językach. Dodatkowo za pomocą komend głosowych można sterować systemem operacyjnym Windows oraz wybranymi aplikacjami. Jednak ograniczenia licencyjne na wykorzystanie tego systemu mowy wykluczyła wykorzystanie tego rozwiązania w wykonywanym projekcie. 2.3.4. Systemy rozpoznawania mowy Od wielu dziesięcioleci ludzie próbują sterować urządzeniami za pomocą głosu. Ze względu na skomplikowanie ludzkiej mowy pierwsze systemy pozwalały wyłącznie na rozpoznawanie cyfr. W 1952 roku Bell Laboratories [23] zaprojektował system „Audrey”, który rozpoznawał cyfry. Dziesięć lat później IBM zaprezentował swoją maszynę „Shoebox” [24], która rozpoznawała 16 słów w języku angielskim. Następnie w latach 70 bieżącego wieku powstały pierwsze systemy pozwalające rozpoznać tysiące słów, w latach 80 ta liczba rozpoznawanych słów została już przekroczona. W latach 90 firma Dragon wprowadziła do sprzedaży pierwszy produkt rozpoznawania mowy Dragon Dictate w cenie 9000$. Siedem lat później produkt znacznie udoskonalony o nazwie Dragon NaturallySpeaking umożliwiający płynne rozpoznawanie mowy o szybkości 100 słów na minutę został udostępniony w cenie ok. 700$. Od 2000 roku systemy te szczycą się 80 % poprawnością rozpoznawania mowy. Także od tego czasu możliwości wydawania komend głosowych zostały zaimplementowane do systemów operacyjnych Microsoft Vista oraz MacOS oraz do wielu telefonów komórkowych [25]. 2.3.5. Systemy syntezy mowy Synteza mowy polega na zamianie tekstu na mowę (ang. Text To Speech, TTS) [26]. Systemy te ocenia się na podstawie poprawności i zrozumiałości wygenerowanej mowy, która powinna być zrozumiała przez człowieka. Z roku na rok systemy te są bardziej dopracowane, jednak na dzień dzisiejszy daleko jest im do doskonałości. 9 Dokument ten na dzień dzisiejszy znajduje się w wersji roboczej.
  • 12. 1. Cel pracy oraz rozpoznanie technologii 12 2.3.6. Przegląd istniejących systemów mowy Na rynku istnieje wiele systemów mowy (ang. Speech). Niektóre z nich lepiej sobie radzą, a niektóre gorzej z rozpoznawaniem i syntezą mowy (ang. Speech Recognition and Synthesis). Wiele z nich, szczególnie tych dopracowanych występuje w wersji komercyjnej, za którą trzeba płacić (patrz tab. 1.1.). Większość z tych systemów przedstawia dość wysoki poziom generowanej i rozpoznawanej mowy. Jednak ze względu na wysokie koszty nie zostały one uwzględnione przy realizacji niniejszego projektu. Tab. 2.1. Wybrane komercyjne systemy mowy. l.p. nazwa cena rodzaj 1. Dragon Medical od 1200$ synteza i rozpoznawanie mowy 2. Dragon NaturallySpeaking od 30$ za wersję pod system operacyjny synteza i rozpoznawanie mowy 3. Cloud Garden, Talking Java SDK 500$ za serwer (z ograniczeniami) synteza mowy 4. Acapela box (Elan Speech Cube) 300€ za godzinę synteza mowy 5. Lumen Vox od 1500$ rozpoznawanie mowy 6. Ivona od 29€ synteza mowy Dragon Medical [26] oferuje jedne z najbardziej zaawansowanych możliwości rozpoznawania i syntezy głosu. Jest on przeznaczony dla lekarzy, którzy mogą za jego pośrednictwem szybko tworzyć raporty medyczne lub przeszukiwać bazy danych. Jest to możliwe dzięki bardzo dobremu systemowi rozpoznawania tekstu, pełnego zakresu słownictwa medycznego, technicznego a także sprawności działania, pozwalającej na pracę niemal w czasie rzeczywistym z systemem. Drugim według mnie najlepszym systemem mowy jest Dragon NaturallySpeaking [27]. Jest on już przeznaczony dla przeciętnego użytkownika. Pozwala on m. in. na pisanie oraz edycję dokumentów tekstowych, e-maili, uruchamianie aplikacji i plików, kontrolowanie myszki oraz pomaga przy wielu innych czynnościach związanych z codzienną pracą użytkownika z komputerem. Cloud Garden, Talking Java SDK [28] jest już implementacją JSAPI, która korzysta z SAPI Microsoftu, tak więc możliwe wykorzystanie jest wyłącznie pod platformą Windows. Jak nazwa wskazuje jest to SDK (ang. Software Development Kit), które umożliwia praktycznie dowolną implementację systemu. Acapela box (Elan Speech Cube) [29] jest generatorem mowy, który pobiera opłaty w zależności od czasu generacji mowy. Actapela udostępnia nam swój serwer, do którego się łączymy, generujemy na nim mowę i odbieramy ją z powrotem. Za poprawność pracy całości odpowiada firma, jednak tylko też ona może dalej rozwijać swój produkt. Lumen Vox [30] jest firmą, która specjalizuje się w tworzeniu systemów generowania mowy wysokiej jakości. Ich produkt Lumen Vox zdobył wiele nagród i wyróżnień w kategorii rozpoznawania mowy. Jednak sama jego cena wskazuje na jego profesjonalne zastosowanie. Na koniec pozostawiłem nasz rodowity produkt o bardzo wysokiej jakości Ivona [31], który generuje mowę o bardzo wysokiej jakości. Ivona może poszczycić się generacją bardzo wysokiej klasy głosu w języku polskim. Posiada ona wiele sposobów licencjonowania, tak więc dostosowana jest zarówno pod przeciętnego klienta jak i korporacji.
  • 13. 1. Cel pracy oraz rozpoznanie technologii 13 Większość rozwiązań typu Open Source10 przedstawia niestety tylko dobry lub zadawalający poziom wygenerowanej mowy (patrz tab. 1.2). Wiele z nich korzysta z SAPI Microsoftu, co dyskwalifikuje je do wykorzystania w projekcie. Tutaj praktycznie tylko dwa rozwiązania wybijają się spośród dostępnych implementacji: Sphinx oraz FreeTTS. Charakteryzują się one znacznie lepszą jakością generowanej i rozpoznawanej mowy oraz lepszą dokumentacją i większą funkcjonalnością. Niewątpliwie w tym sektorze są liderami. Jednak w odróżnieniu od komercyjnych systemów tego typu są to wyłącznie biblioteki, które wymagają utworzenia własnej implementacji, gdzie często rozwiązania komercyjne oferują nam kompletny produkt. Tab. 2.2. Wybrane systemy mowy typu Open Source. l.p. Nazwa rodzaj 1. Sphinx-4 rozpoznawanie mowy 2. e-Speaking rozpoznawanie mowy (wymaga SAPI) 3. FreeTTS synteza mowy 4. Flite synteza mowy 5. Festival synteza mowy 6. FestVox synteza mowy Sphinx-4 [32] jest najbardziej zaawansowanym systemem rozpoznawania mowy dostępnym jako Open Source. Został on w całości napisany w języku Java poprzez współpracę Sphinx group na Uniwersytecie Carnegie Mellon, Sun Microsystems Laboratories (obecnie Oracle), Mitsubishi Electric Research Labs (MERL) oraz Hewlett Packard (HP) przy współpracy z Uniwersytetem California w Santa Cruz (UCSC) i Massachusetts Institute of Technology (MIT). System ten rozwijany jest od wielu lat oraz posiada możliwości rozpoznawania pojedynczych komand jak i zarówno całych sekwencji zdań. Umożliwia on podpięcie wielu modeli języka naturalnego11 w wielu różnych formatach. Posiada bogatą dokumentację oraz wiele możliwości podpinania sygnału audio. System e-Speaking [33] jest przykładem zastosowania SAPI Microsoftu, którego wymaga do pracy. Posiada on ok. 100 wbudowanych komand do interakcji z systemem operacyjnym. Obsługuje zarówno Windows 2000 jak i Windows XP. Integruje się z pakietem Microsoft Office. FreeTTS [34] z pośród wszystkich tu obecnych otwartych platform pod względem generowania mowy bije konkurencję na głowę. Obsługuje wiele głosów, wraz z możliwością ich dodawania. Częściowo wspiera standard JSAPI 1.0. Posiada dobrą dokumentację oraz wiele interfejsów, które pozwalają na integrację tego systemu w innych modułach. Został on w całości napisany w języku Java, jednak opiera się on na Flite [35] małym, szybkim, pracującym niemal w czasie rzeczywistym generatorze mowy w całości napisanym w języku C na Uniwersytecie Carnegie Mellon. Flite wywodzi się z systemu rozpoznawania mowy Festival [36] i projektu FestVox [37], które nie są już tak funkcjonalne i zaawansowane jak FreeTTS, jednak odznaczają się wyższą sprawnością. Możemy wyróżnić tutaj trzeci typ systemów mowy. Mianowicie systemy on-line, do których możemy podłączyć się za pośrednictwem interfejsów programistycznych (ang. Application Programming Interface, API). Opierają się one najczęściej na systemach, a w zasadzie bibliotekach opisanych w tab. 1.2. Są to proste rozwiązania, nie pamiętają stanu, nie posiadają 10 Dostępnych bez opłat z dostępem do kodu źródłowego. 11 Model określa listę słów i sentencji do rozpoznania.
  • 14. 1. Cel pracy oraz rozpoznanie technologii 14 własnej logiki, tylko po prostu generują mowę na bazie podanego tekstu lub rozpoznają wydawane komendy (patrz tab. 1.3). Najbardziej one pasują do tworzonego tutaj systemu, ale nie mogą w nim jednak być użyte ze względu na swoje ograniczenia. Tab. 2.3. Wybrane systemy mowy on-line. l.p. nazwa rodzaj adres www 1. SpeechAPI rozpoznawanie mowy http://speechapi.com/ 2. Ivona synteza mowy http://www.ivona.com/en/ 3. AT&T Natural Voices® Text- to-Speech Demo synteza mowy http://www2.research.att.com/~ttsweb /tts/demo.php 4. Festvox synteza mowy http://festvox.org/voicedemos.html 5. Festival Text-to-Speech Online Demo synteza mowy http://www.cstr.ed.ac.uk/projects/festi val/onlinedemo.html 6. Demo Cepstral Voices synteza mowy http://cepstral.com/demos/ 7. I Online Text to Speech Synthesizer synteza mowy http://codewelt.com/proj/speak 8. vozMe synteza mowy http://vozme.com/index.php?lang=en SpeechAPI jest systemem on-line umożliwiającym użytkownikowi Internetu na wypowiadanie komend oraz czytanie tekstu, który następnie jest rozpoznawany przez system. Internauta ma do dyspozycji wyłącznie jedną stronę (właściwie kilka podstron) na której wypowiada komendy. System ten jest interfejsem programistycznym (ang. API) do którego można podłączyć się za pomocą różnych technologii, w tym: Java Script, Java12 , PHP, Python, Rubby, Web Services oraz CLI (ang. Command Line Interface). Tak więc jest to system zamknięty, wysyłajcy żądanie zawierające nagrany głos do rozpoznania, natomiast w odpowiedzi otrzymujemy rozpoznaną komendę w formie tekstu. Poprzez obsługę wielu technologii wydaje się być ciekawym rozwiązaniem na rynku. Niestety w 2011 roku prace nad tym systemem bardzo zmalały także na chwilę obecną ciężko jest przewidzieć jego przyszłość. Także wykonane testy podczas rozpoznania, które nierzadko kończyły się niepowodzeniem oraz brak udostępnienia kodu źródłowego do wykonania potrzebnych poprawek wykluczyły ten system do wykorzystania w tworzonym projekcie. Ivona udostępniła raczej demonstracyjny panel zamiany tekstu w głos. Można w nim podać dość krótki fragment, który zostanie zamieniony w głos. Jednak wyróżnia się ona sporą listą dostępnych języków oraz bardzo wysoką jakością generowanego dźwięku. Pozostałe systemy on-line zaprezentowane w tab. 1.3. posiadają bardzo ograniczone, nazwałbym je podstawowe funkcje generowania mowy, jednak pozwalają one na jej wygenerowanie w przeglądarce internetowej. 2.4. Serwery obsługujące protokół czasu rzeczywistego Ponieważ wykonany system ma pracować w Internecie użytkownik nie powinien czekać zbyt długo na reakcję ze strony systemu. W tym celu do wykonania systemu został wykorzystany serwer obsługujący protokół czasu rzeczywistego (ang. Real-Time Messaging Protocol, RTMP) [38] utworzony przez Adobe [39]. W naszym przypadku protokół ten przesyła dane audio w taki sposób, że użytkownik nie musi czekać na wcześniejszy zapis lub zbuforowanie tych danych, 12 Na chwilę pisania tego rozdziału Java nie była jeszcze dostępna.
  • 15. 1. Cel pracy oraz rozpoznanie technologii 15 tylko bezpośrednio może z tych danych fragment po fragmencie wykorzystać. Zastosowanie tego protokołu znacznie przyśpieszyło interakcję użytkownika z systemem. Serwery te potocznie są zwane albo serwerami strumieniowymi albo serwerami czasu rzeczywistego. Jako, że protokół ten został utworzony przez firmę Adobe także serwery tej firmy obecnie są najbardziej zaawansowane, dopracowane i stabilne, ale także i kosztują sporo. W Adobe możemy wyróżnić serwer Flash Media Server [40] oraz LiveCycle DS. [41]. Oba prezentują najwyższą półkę oraz zapewniają wysoką stabilność i dokumentację. Na drugim horyzoncie znajduje się serwer Wowza Media Server [42], który jest praktycznie odpowiednikiem tego z Adobe. Natomiast z wielu rozwiązań typu Open Source praktycznie tylko jedno się liczy, mianowicie serwer Red5 [43], który wykonany został w technologii Java. Jest to taki mniejszy brat Adobe Flash Media Server. Na początku 2011 roku został zaprezentowany kandydat na wersję 1.0. Jednak od tego czasu serwer ten boryka się z wieloma różnymi problemami, które uniemożliwiły wydanie jego wersji 1.0. Po dopracowaniu myślę, że będzie to solidny serwer, jednak na dzień dzisiejszy posiada on bardzo skromną dokumentację i wiele elementów trzeba samemu się domyślać jak je wykonać. Jednak najważniejszą cechą tego serwera jest fakt, iż występuje on jako Open Source, jest dostępny bez opłat licencyjnych (natomiast jego konkurenci są wysoko wyceniani) i co najważniejsze obsługuje protokół RTMP. Serwery tego typu tworzą gniazda na odpowiednich portach (dla RTMP zwykle jest to port 1935) poprzez które następuje transmisja danych w czasie rzeczywistym. Takie połączenie w przypadku stron internetowych następuje właśnie poprzez protokół RTMP. 2.5. Specyfikacja techniczna Ze względu na dalszy rozwój projektu przez uczelnię Politechniki Gdańskiej, Katedrę Systemów Decyzyjnych cały system został oparty na standardach Open Source. Wyjątkiem są tutaj platformy technologiczne, np. baza danych, która do zastosowań niniejszego projektu jest dostępna i zgodna z warunkami licencyjnymi za darmo ze strony firmy Oracle lub server, który można łatwo podmienić na inny Open Source gdyż, aplikacja została wykonana w pełni pod standard Java Enterprise Edition. Obsługiwane systemy operacyjne13 :  Linux Ubuntu 8.04 (server) x3214  Windows15  Macintosh16 . Wykorzystane serwery:  Server aplikacji: Oracle Web Logic 11g  Server czasu rzeczywistego + java: Red5 RC 1.0. Wykorzystane standardy Java [44, 45, 46, 47, 48]:  Java 5 EE  EJB 3.0 (ang. Enterprise JavaBean) 13 W kontekście uruchomienia platformy. Odnośnie końcowego użytkownika to może on działać na dowolnym systemie operacyjnym obsługującym wtyczkę Adobe Flash 10. 14 Po odpowiednim dostrojeniu aplikacja powinna działać i w innych wersjach systemu. Mi osobiście nie udało się uruchomić systemu pod Linux Fedora Core 14 x64 (problem był z biblioteką xuggler). 15 Potwierdzone w systemie Windows Vista x32. 16 Brak przeprowadzenia testów, ale po odpowiedniej konfiguracji powinno zadziałać.
  • 16. 1. Cel pracy oraz rozpoznanie technologii 16  JPA (ang. Java Persistence API)  EAR (ang. Enterprise Archive)  JSF2 (ang. Java Server Faces 2)  Threads  Entity  Facelets. Baza danych:  Oracle XE 11g. Technologie RIA (ang. Rich Internet Application):  Adobe Flex 4.5  AS 3 (ang. Action Script 3)  NetStream  SO (ang. Shared Object)  MXML  Adobe Flash 10. Technologie Internetowe:  xHTML (ang. Extensible HyperText Markup Language)  CSS (ang. Cascading Style Sheets)  JS (ang. JavaScript)  Sitemap (plik tekstowy). Technologie rozproszone SOA (ang. Service Oriented Architecture):  SOAP 1.1 (ang. Simple Object Access Protocol)  XML (ang. Extensible Markup Language)  WSDL (ang. Web Services Description Language). Technologie rozpoznawania mowy:  JSGF (ang. Java Speech Grammar Format). Wykorzystane bibloteki [55]:  rozpoznanie mowy: Sphinx4  synteza mowy: FreeTTS  konwersja formatów audio: Xuggler  spring Source Framework  parser HTML: JSoup  system logowania: Apache Logger. Metodologia wytwarzania oprogramowania [49, 50, 51, 52, 53, 54]:  UML 2.0 (ang. Unified Modeling Language)  wzorce projektowe  oprogramowanie obiektowe i rozproszone.
  • 17. 1. Cel pracy oraz rozpoznanie technologii 17 2.6. Podsumowanie Wykorzystując system mowy w aplikacjach otrzymujemy bardziej naturalny interfejs użytkownika, który umożliwia łatwiejsze oraz bardziej przyjazne sterowanie aplikacją pomiędzy użytkownikiem a systemem (w naszym przypadku portalem internetowym). Możemy wyróżnić dwa główne obszary systemu mowy: rozpoznawanie mowy (ang. Speech Recognition) oraz synteza mowy (ang. Speech Synthesis). Rozpoznawanie mowy polega na tym iż komputer słucha co do niego mówimy a następnie konwertuje to na tekst. Synteza mowy jest odwrotnym procesem, który polega na czytaniu tekstu poprzez wygenerowany głos ludzki w aplikacji. Często proces ten określany jest jako technologia text-to- speech (TTS). Celem pracy jest opracowanie głosowego systemu komunikacji oraz nawigacji po serwisie internetowym. Projekt zakłada wykonanie portalu testowego, systemu rozpoznawania i generowania mowy, mózgu systemu oraz postaci Awatara komunikującego się z użytkownikami oraz kierującego ich po serwisie. System ma być inteligentny w tym znaczeniu, iż Awatar nie będzie nas tylko słuchał, ale także będzie z nami w dialogu. Ze względu na skomplikowanie języka i dostępność bibliotek generowania i syntezy mowy wykonanie projektu zakłada komunikację w języku angielskim.
  • 18. 2 3.SPRECYZOWANIE WYMAGAŃ FUNKCJONALNYCH 3.1. Wprowadzenie Wykonany system pozwala na komunikację oraz nawigację po utworzonym portalu internetowym za pomocą głosu. W dialogu uczestniczy postać Awatara, która wyposażona jest w stan, który docelowo w przyszłości będzie rozszerzony do postaci Dictobot’a [56] za pośrednictwem odpowiedniej implementacji „Mózgu” systemu. Widok demonstracyjnego systemu został zaprezentowany na rys 2.1.
  • 19. 2. Sprecyzowanie wymagań funkcjonalnych 19 Rys. 2.1. Widok portalu demonstracyjnego. 3.2. Przeznaczenie systemu Zaprezentowany system przeznaczony jest dla każdego użytkownika z dostępem do Internetu ze znajomością języka angielskiego, gdyż obustronna komunikacja odbywa się właśnie w tym języku. Praca ta jest pracą rozpoznawczą, przygotowuje ona platformę do dalszego rozwoju poprzez umożliwienie podziału dalszej pracy na kilka zespołów. Pod tym kątem cały system jest tworzony i dlatego w pewnych warstwach charakteryzuje się pewnym nadmiarem, który wydzielił moduły funkcjonalne systemu. System pokazuje możliwości wykorzystania technologii rozpoznawania i generowania mowy w połączeniu ze stanem Awatara, który pamięta użytkownika przez całą sesję w której uczestniczymy w interakcji. Sam Awatar w tym wykonaniu jest częściowo autonomiczny, jednak został on tak zaprojektowany aby w przyszłości stał się on całkowicie autonomiczny
  • 20. 2. Sprecyzowanie wymagań funkcjonalnych 20 i sam podejmował już niektóre decyzje. Dodatkowo cała zabawa została udostępniona dla użytkowników bez potrzeby zalogowania się do portalu. 3.3. Funkcja Wyróżniamy kilka funkcjonalnych stref systemu, które dotyczą zwykłego użytkownika oraz administratora. Z myślą o wdrożeniu wykonanego systemu do istniejącego portalu internetowego samodzielnie on generuje i uaktualnia zawartość tego portalu. Ponieważ nie chcemy także, aby wszystko co na nim się znajduje trafiało do naszego systemu, np. treść znaczników opisujących tabele lub obrazki na stronie wyposażony on został w moduł filtrowania zawartości portalu. Chcemy także, aby cały system szybko działał, tak więc z tego powodu została dodana baza danych która buforuje zawartość strony. W przeciwnym wypadku użytkownik był by zmuszony oczekiwać na każdorazowe przeanalizowanie strony portalu i na tej bazie otrzymywał by odpowiedź, co było by czasochłonne. Nie chcemy, aby użytkownik musiał logować się do portalu. Powinien po prostu wejść na stronę i zacząć z niej korzystać bez poświęcania dodatkowego czasu na logowanie się lub konfigurowanie systemu. Wymagania względem Awatara:  wyposażony jest w stan (emocje), który jest zapamiętywany i przywracany kiedy ponownie użytkownik wraca do aplikacji  stan awatara jest normalizowany1 po stronie klienta, niezależnie, nie obciążając dodatkowo łącza internetowego  wydanie każdej komendy głosowej związane jest z pobraniem stanu Awatara, gdzie „Mózg” odpowiednio reaguje na ten stan  „Mózg” odpowiada za modyfikację stanu Awatara  stan Awatara został graficznie odzwierciedlony w postaci wykresu słupkowego, gdzie każdy słupek odzwierciedla inną cechę2  postać Awatara jest animowana w zależności od aktualnego stanu. Wymagania względem rozpoznawania mowy:  rozpoznawane komendy głosowe: o „Good Morning” – Awatar wita się o „Hello” – Awatar wita się o „How are Yoy ?” - Awatar odpowiada nam jak się czuje i pyta się nas o to samo o „What is Your Name ?”, „Name” – Awatar odpowiada nam jak się nazywa o „Read page”, „Read” – Awatar czyta zawartość strony głównej o „Home”, „People”, „Teachers”, „Specialization”,, „Teaching”, “Research”, “Laboratories”, “Smart control idea”, – Komendy te przekierowują do odpowiednich podstron portal demonstracyjnego o „Next page”, „Next”, i „Previous Page”, „Previous” – Powodują przejście do następnej i poprzedniej strony w portalu internetowym. Wymagania względem generowania mowy:  możliwość edycji generowanych komunikatów za pomocą panelu administracyjnego  głos powinien być odpowiednio modulowany w zależności od aktualnego stanu Awatara 1 Wyposażony w mechanizm „zapominania”. 2 W niniejszej implementacji Awatar posiada 4 cechy, a każda z nich przyjmuje wartości od 0 do 200.
  • 21. 2. Sprecyzowanie wymagań funkcjonalnych 21 Wymagania względem mózgu systemu:  autonomiczność, poprzez wykorzystanie technologii SOA umożliwiająca łatwą jego podmianę nawet w czasie pracy systemu  generowanie odpowiedzi na bazie aktywnego kontekstu (stanu Awatara, adresu strony żądania i komendy) zawierającej komunikat głosowy, zmianę stanu oraz ew. polecenie przekierowania w inną część portalu demonstracyjnego. Wymagania względem portalu demonstracyjnego:  zawiera angielską część informacji z Katedry Systemów Decyzyjnych  zawartość odzwierciedla fragment strony Katedry Systemów Decyzyjnych  zawiera minimum 5 podstron z różną zawartością. Wymagania względem części administracyjnej:  wygenerowanie zawartości portalu na bazie odpowiednich znaczników  podgląd zawartości bazy danych  edycja komunikatów głosowych wydawanych przez Awatara. 3.4. Podsumowanie Jest to wzorcowy projekt, który umożliwia sterowanie portalem internetowym za pomocą głosu. Jego główną funkcją jest możliwość interakcji użytkownika za pomocą głosu poprzez wydawanie komend głosowych oraz słuchanie i dialog z Awatarem. Docelowo, jeżeli system ten odniesie sukces będzie on zaimplementowany na portalu Uczelni, dlatego został on wyposażony we własny system znaczników i parser3 , który na podstawie znaczników przygotowuje odpowiednio bazę danych, która wykorzystywana jest już przez „Mózg” systemu. W ten sposób została zagwarantowana możliwość jego implementacji na portalu uczelni w przyszłości. 3 Parser analizuje zawartość stron portalu na postawie specjalnych znaczników. Szczytuje tylko wybraną zawartość portalu w sposób odpowiednio przygotowany.
  • 22. 3 4.ZASADA DZIAŁANIA ORAZ OPIS SYSTEMU 4.1. Wprowadzenie Na cały system składa się wiele różnych technologii, które współpracują ze sobą. Ich połączenie wymusiło utworzenie wielu warstw z wieloma współzależnościami. W celu obsłużenia wielu użytkowników jednocześnie cały system w kluczowych elementach został podzielony na osobne wątki, tak aby jeden użytkownik nie musiał czekać na zakończenie operacji związanej z obsługą innych użytkowników. Całe rozwiązanie zostanie przedstawione w kolejnych podrozdziałach. 4.2. Architektura systemu Ogólna architektura systemu została przedstawiona na rys. 3.1. Na rysunku możemy zauważyć, iż cały system jest mocno rozproszony i dzieli się na poszczególne moduły, które są odpowiedzialne za swoją część. W ten sposób cały projekt został podzielony na mniejsze części, które mogą być niezależnie zarządzane.
  • 23. 3. Zasada działania oraz opis systemu 23 Rys. 3.1. Ogólna architektura systemu. Wydzielamy tu część kliencką oznaczoną kolorem błękitnym która jest środowiskiem pracy, które w danym momencie posiada użytkownik systemu. Część kliencka odpowiada za komunikację z serwerem, przydzieleniem uprawnień do mikrofonu i głośników, wygenerowaniem unikalnego identyfikatora dla klienta, który następnie jest wykorzystywany przez serwer do jego identyfikacji. Także w tej części użytkownik ma kontakt z systemem, obserwuje wizualnie Awatara, wydaje komendy oraz słucha systemu. Tutaj także znajduje się aktualna wizualizacja stanu Awatara w postaci wykresu słupkowego oraz konsola logów z całego systemu, w której użytkownik monitoruje stan platformy w danym momencie. Po stronie klienta przechowywany jest aktualny stan Awatara unikalny dla każdego użytkownika, jednak jest on przypisany na stałe do danego komputera, a czasem przeglądarki. Tak więc po powrocie do systemu w późniejszym czasie na danym komputerze następuje odczytanie stanu Awatara, który na stałe zachowany jest na dysku użytkownika w postaci obiektu współdzielonego (ang. Shared Object). Także tutaj użytkownik ma dostęp do ustawień, które są przechowywane w obiekcie współdzielonym (ang. Shared Object). Ustawienia te pozwalają na włączenie lub wyłączenie odświeżania stanu Awatara oraz włączenie/wyłączenie wyświetlania konsoli logowania w portalu internetowym. Ustawienia te powalają zwiększyć wydajność pracy aplikacji klienta. W ustawieniach można także zdefiniować adres serwera mowy, który odpowiada za całą dalszą pracę systemu1 . Część serwerowa została oznaczona kolorem zielonym. Fizycznie część ta podzielona jest na dwa serwery: serwer mowy jest serwerem czasu rzeczywistego, jest to serwer Red5 RC 1.0, który opiera się na platformie Apache Tomcat 6 działający na porcie 8080 dla protokołu HTML oraz na porcie 1935 dla protokołu RTMP, drugim serwerem jest Oracle WebLogic 11g 1 W końcowej fazie pracy nad systemem opcja ta została domyślnie wyłączona.
  • 24. 3. Zasada działania oraz opis systemu 24 na którym działa „Mózg” systemu, część administracyjna oraz portal demonstracyjny. Sewer standardowo działa na porcie 7001 dla protokołu HTML. Serwer mowy jest kluczowym elementem całego systemu, zwyczajowo nazywany „serwerem” niniejszego systemu. To bezpośrednio z nim komunikuje się klient (w zasadzie użytkownik systemu). Serwer ten wydziela dalszą interakcję z użytkownikiem. Na serwerze tym zostały utworzone moduły generowania i syntezy mowy, klienta mózgu, obsługi i konwersji danych audio przesyłanych w czasie rzeczywistym. Także w tym miejscu znajduje się lista słów i komend rozpoznawalnych przez system w formacie JSGF (ang. Java Speech Grammar Format). W tym miejscu mamy konfiguracje systemów rozpoznawania i syntezy mowy w formatach zdefiniowanych przez specyfikacje bibliotek FreeTTS oraz Sphinx4. Wykonany serwer mowy posiada architekturę wielo-wątkową2 (ang. Multithreading), tak więc każde żądanie nowego klienta obsługiwane jest w nowym wątku. Konwersje formatów danych audio są także wykonywane wielo wątkowo. Rozpoznanie komendy głosowej z wygenerowaniem odpowiedzi również zachodzi w osobnym wątku. Wiele operacji w serwerze zachodzi w oparciu o zdarzenia (ang. Events). Dotyczy to obsługi komunikacji serwera z klientem podczas wymienianych komunikatów, konwersji plików audio oraz obsługi wymiany danych audio w czasie rzeczywistym. Serwer mowy wykorzystuje bibliotekę Xuggler do konwersji formatów audio. Biblioteka ta jest zainstalowana na serwerze w systemie operacyjnym, natomiast sam system korzysta z niej poprzez referencję. Standardowo serwer Red5 nagrywa dane audio w formacie .flv (ang. Flash Video) które są następnie konwertowane do formatu .wav (ang. Wave form audio format) poprzez napisany konwerter wykorzystujący bibliotekę Xuggler, który jest już zrozumiały dla systemu rozpoznawania mowy. Natomiast generator mowy generuje mowę w formacie .wav, który jest zbyt duży do przesłania do użytkownika, a także nie jest standardowo obsługiwany przez serwer Red5 tak więc jest on konwertowany do formatu .mp3 (ang. MPEG-1/MPEG-2 Audio Layer 3), który jest już kilka do kilkunastu razy mniejszy oraz możliwy do odtworzenia w czasie rzeczywistym przez klienta. Mózg jest drugim serwerem, który odpowiada za logikę aplikacji. Komunikuje się on bezpośrednio i wyłącznie z systemem mowy, od którego dostaje komendę użytkownika w postaci tekstowej, identyfikator klienta oraz stan Awatara oraz zwraca akcję do wykonania przez klienta wraz z komendą zmiany stanu Awatara lub wykonania przekierowania do innej strony w portalu internetowym. Komunikacja systemu mowy następuje poprzez klienta Mózgu, który komunikuje serwer mowy z „Mózgiem” poprzez protokół SOAP przy wykorzystaniu dokumentu WSDL w technologii rozproszonej SOA. To rozwiązanie umożliwia łatwe dodawanie nowych implementacji Mózgu oraz przełączanie ich w czasie działania aplikacji. Mózg na podstawie otrzymanych danych i przetworzeniu posiadanych decyduje o wykonanej interakcji w portalu internetowym za pośrednictwem serwera mowy, który dodatkowo może wygenerować komunikaty głosowe dla użytkownika oraz przesłać komunikaty zmiany stanu Awatara lub zadecydować o wykonaniu przekierowania użytkownika do innej strony na portalu internetowym. Oba serwery działają w technologii Java. Wyłącznie Mózg komunikuje się z bazą danych poprzez fasadę, obiekt typu EJB Stateless Bean wykorzystując Framework JPA i zdefiniowane źródło danych (ang. Data Source) po stronie serwera oraz mapowanie ORM (ang. Object- relational maping) dzięki wykorzystaniu encji (ang. Entities). Zastosowaną bazą danych jest 2 Architektura wielo-wątkowa pozwala na równoległą realizację żądań wielu użytkowników równocześnie. Najczęściej żądania są rozdzielane równomiernie na dostępne procesory i rdzenie dzięki czemu wykonywane operacje powinny odbywać się szybciej (choć nie zawsze, jeżeli liczba wątków jest zbyt duża) i powinny pozwolić na wykonanie danej operacji przez nowego użytkownika bez potrzeby oczekiwania na zakończenie wykonywanych operacji przez innych użytkowników (jednak w praktyce nie zawsze tak jest, jest to zależne od wykonanej implementacji).
  • 25. 3. Zasada działania oraz opis systemu 25 baza danych Oracle XE 11g, która przechowuje wcześniej przygotowaną zawartość portalu internetowego oraz treść komunikatów generowanych dla użytkownika. Nad zapełnieniem bazy danych oraz przygotowaniem w niej danych odpowiada część Administratora, która szczytuje zawartość portalu na podstawie jego mapy strony (ang. Sitemap) oraz wcześniej przygotowanym znacznikom mowy (ang. Tags). Moduł ten jest całkowicie niezależny od pozostałej części systemu, zapewnia on możliwość do podglądu wygenerowanych danych, wygenerowaniu nowych danych oraz możliwość edycji generowanych komunikatów dla użytkownika. Klient łączy się z częścią serwerową za pośrednictwem protokołów RTMP i AMF (ang. Action Message Format). Za pomocą protokołu RTMP przesyłany jest wyłącznie sygnał audio w czasie rzeczywistym bez potrzeby przesyłania całego materiału w całości3 . Natomiast protokół AMF służy wyłącznie do wymiany komunikatów pomiędzy serwerem a klientem. Komunikaty te zawierają informacje typu: stan Awatara, komendy tekstowe przesyłane do serwera w postaci czytelnego tekstu, informacje zwrotne dla klienta kiedy czeka na niego wiadomość do odsłuchania, komunikaty logów4 ze strony serwera itp. Klient-serwer komunikują się ze sobą wyłącznie za pośrednictwem tych dwóch protokołów. Serwer mowy komunikuje się z Mózgiem za pośrednictwem protokołu SOAP w technologii rozproszonej SOA. Wyłącznie Mózg komunikuje się z bazą danych. W ten sposób zostały jasno wyznaczone warstwy systemu. 4.3. Algorytm działania systemu System posiada budowę modułową, tak więc możemy wyróżnić wiele algorytmów działania systemu. W poniższym opisie została pominięta obsługa sytuacji awaryjnych, która została zaimplementowana przez system. Jednak niniejszy rozdział skupia się na poprawnym i przewidzianym funkcjonowaniu systemu. Opis ten nie obejmuje także opisu sytuacji logowania wykonywanych operacji, ponieważ są one wykonywane we wszystkich istotnych częściach systemu5 . 4.3.1. Przygotowanie systemu mowy Do poprawnego działania systemu wymagane jest przygotowanie i inicjalizacja serwera mowy. Podczas startu serwera inicjalizowany jest system mowy i sam serwer czasu rzeczywistego. Inicjalizacja serwera mowy polega na załadowaniu i wybraniu głosu (w naszym przypadku jest to głos męski o nazwie „kevin16”, gdzie 16 oznacza 16kHz próbkowanie, czyli głos o najwyższej jakości dostępny jako Open Soure), rezerwacji zasobów sprzętowych wykorzystywanych podczas generowania mowy oraz samo przypisanie generatora do systemu mowy. Kolejnym kluczowym elementem, który inicjalizowany jest podczas startu serwera jest to inicjalizacja systemu rozpoznawania mowy. W pierwszej kolejności następuje skonfigurowanie systemu poprzez załadowanie pliku konfiguracyjnego „config,xml”. Plik ten przede wszystkim wczytuje listę słów w formacie JSGF (znajdująca się w pliku „hello.gram”) i komend do rozpoznania przy uwzględnieniu danej rozdzielczości sygnału audio (w naszym przypadku system został skonfigurowany do wykorzystania najwyższej dostpnej 3 Protokół RTMP w odróżnieniu od innych protokołów naprawdę przesyła dane w czasie rzeczywistym. Inne protokoły najczęściej „udają”, że przesyłają materiał czasie rzeczywistym, lecz np. przesyłają go w partiach, a nie bit po bicie jak dzieje się to w przypadku wykorzystania protokołu RTMP. 4 Komunikaty te informują klienta co dzieje się po stronie serwera. W przypadku jakichkolwiek problemów po stronie serwera klient jest informowany o tym fakcie. 5 Obsługę błędów jak i system logów można prześledzić w załączonym kodzie źródłowym.
  • 26. 3. Zasada działania oraz opis systemu 26 jakości sygnału audio), model akustyczny oraz inne ustawienia wykorzystywane podczas rozpoznawania mowy. Następnie alokowane są zasoby systemowe niezbędne do przeprowadzenia procesu rozpoznania mowy. W ten sposób system mowy zostaje uruchomiony. Bez poprawnego wykonania inicjalizacji powyższych elementów system nie zadziała w ogóle. Powyższe działania zostają wykonane jednorazowo. 4.3.2. Podłączenie klienta Interakcja po stronie użytkownika następuje już w momencie otworzenia strony portalu internetowego. W pierwszym momencie po stronie portalu zostaje wygenerowany unikalny identyfikator użytkownika, który wykorzystywany jest w połączeniach klienta z serwerem. Następnie zostaje załadowany klient w technologii Flex poprzez wtyczkę przeglądarki internetowej Adobe Flash. Klient w momencie startu dokonuje załadowania postaci graficznej Awatara wykonanej w technologii Adobe Flash oraz odczytuje identyfikator klienta wygenerowany przez portal internetowy. Potem następuje inicjalizacja klienta, która uwzględnia utworzenie specjalnej wersji systemu logowania aplikacji klienta, która wysyła logi aplikacji dla użytkownika za pośrednictwem interfejsu zewnętrznego (ang. ExternalInterface) za pośrednictwem języka Java Script oraz dzieli logi na podstawowe kategorie. Kolejno utworzony jest lub wczytany współdzielony obiekt (ang. Shared Object) ustawień danego klienta oraz otwierany lub nie w zależności od ustawień panel logów po stronie portalu internetowego (dzięki tej operacji użytkownik ma możliwość na bieżąco śledzenia kolejnych zdarzeń, które zachodzą w całym systemie oraz w przypadku wystąpienia błędu jest o tym informowany na bieżąco). W następnej kolejności zostaje zarezerwowany mikrofon do wykorzystania w systemie (tutaj następuje weryfikacja, czy użytkownik zezwolił aplikacji na wykorzystanie mikrofonu przez aplikację). W tym momencie następuje wczytanie pozostałych ustawień klienta zapisanych w obiekcie współdzielonym6 . Po wczytaniu ustawień zostaje albo utworzony standardowy stan Awatara lub zostaje on odtworzony z obiektu współdzielonego. Następnym krokiem jest przygotowanie klienta do wymiany komunikatów z serwerem, w tym tych wysyłanych i odbieranych. Po wykonaniu tych wszystkich czynności Awatar zostaje ożywiony, tzn. zostaje on poddany normalizacji czyli powrotu do stanu normalnego7 . Po przygotowaniu klienta8 następuje połączenie klienta z serwerem. Obsługa połączenia po stronie klienta następuję w trybie zdarzeniowym (ang. Events). Po wysłaniu żądania połączenia z serwerem, serwer podejmuje próbę połączenia z klientem w osobnym wątku. Klient wysyła swój identyfikator do serwera, który jest zapisany w atrybucie klienta po stronie serwera do jego dalszej identyfikacji. W pierwszym momencie po stronie serwera następuje weryfikacja, czy łączący się klient czasem nie jest już połączony z serwerem w innym żądaniu9 (np. w innej zakładce przeglądarki lub w wyniku po prostu przejścia na inną stronę portalu internetowego). Jeżeli klient jest już połączony to następuje jego scalenie „sesji” z obecnie zapisaną w liście 6 W ten sposób została zapewniona możliwość np. przesłania dodatkowych parametrów do systemu, np. naszego imienia. Jednak ta wersja systemu nie korzysta z takiego rozwiązania. 7 Normalizacja czyli funkcja zapominania stanu Awatara ze względu na optymalizację wydajności całego systemu została wykonana wyłącznie po stronie klienta. Zamiast obciążać klienta częstym przesyłaniem informacji o stanie Awatara np. raz na sekundę, to czynność ta została całkowicie wykonana po stronie klienta. Jeżeli weźmiemy pod uwagę pracę z wieloma klientami jest to znaczne odciążenie zarówno klienta jak i serwera odnośnie dodatkowej obsługi każdego takiego żądania kosztem większego skomplikowania systemu. 8 Przedstawione przygotowanie klienta występuje po każdorazowym odwiedzeniu strony w portalu internetowym. 9 Tutaj sytuacja trochę się komplikuje ponieważ połączenie klient-serwer w prezentowanym systemie nie jest połączeniem sesyjnym. O zapewnieniu trwałości połączenia system musi sam zdecydować, nie dzieje się to automatycznie ze względu na to iż aplikacje Flex są bezstanowe w momencie przejścia do innej strony internatowej lub jej przeładowania.
  • 27. 3. Zasada działania oraz opis systemu 27 klientów aktualnie połączonych10 , w przeciwnym razie zostaje klient dodany do listy nowych klientów aktualnie połączonych z systemem. W przypadku sukcesu połączenia i w zależności od typu połączenia (nowe lub wznowione) w osobnym wątku zostaje wygenerowana wiadomość powitalna dla klienta11 . Na koniec zostaje wysłana wiadomość powitalna dla klienta, która jest wiadomością kontrolną czy funkcjonuje komunikacja dwustronna w obszarze klient-serwer. Dopiero w tym momencie klient odbiera potwierdzenie połączenia z serwerem i ustawia swój status połączenia na połączony12 . Jeszcze pozostało zestawienie połączenia gniazda (ang. Socket), właściwie strumienia danych po protokole RTMP. W ten sposób klient został połączony i przygotowany do dalszego użycia. Przebieg algorytmu podłączenia klienta: 1. otworzenie strony internetowej 2. wygenerowanie unikalnego identyfikatora użytkownika 3. załadowanie klienta poprzez wtyczkę flash 4. wczytanie postaci graficznej awatara poprzez klienta 5. odczytanie wygenerowanego identyfikatora poprzez klienta 6. utworzenie systemu logowania po stronie klienta 7. wczytanie lub utworzenie obiektu SO z ustawieniami klienta 8. inicjalizacja mikrofonu jeżeli zezwolono 9. wczytanie ustawień z obiektu SO 10. wczytanie lub utworzenie stanu Awatara 11. przygotowanie komunikacji klient-serwer 12. ożywienie Awatara w proces normalizacji 13. połączenie klienta z serwerem wraz z wysłaniem identyfikatora klienta w nowym wątku 14. zapisanie identyfikatora klienta po stronie serwera 15. weryfikacja czy klient nie jest już połączony z serwerem 16. dodanie lub przekierowanie klienta do listy połączonych z serwerem 17. wygenerowanie wiadomości powitalnej dla klienta w nowym wątku 18. wysłanie wiadomości powitalnej do klienta z informacją, iż został on już połączony 19. serwer wysyła wiadomość do klienta, iż czeka na niego wiadomość do odsłuchania 20. zestawienie połączenia RTMP pomiędzy klientem i serwerem. 10 Połączenie klienta determinowane jest po długości czasu życia sesji po stronie portalu internetowego według wygenerowanego identyfikatora klienta. 11 Algorytm generowania mowy został opisany w osobnym podrozdziale. 12 W rzeczywistości status connectionStatus otrzymuje wartość true.
  • 28. 3. Zasada działania oraz opis systemu 28 Rys. 3.2. Wykorzystanie wątków podczas inicjalizacji klienta. Rysunek 3.2 przedstawia sposób wykorzystania wątków podczas inicjalizacji klienta. P0 oznacza klienta, T0 reprezentuje podłączenie klienta do serwera, każdy klient zostaje obsłużony w osobnym wątku, następnie T1 oraz T2 przedstawiają wygenerowanie wiadomości powitalnej, która generowana jest także w osobnych wątkach, aż w końcu wszystkie te komunikaty wracają z powrotem do klientów. 4.3.3. Wygenerowanie mowy i jej odsłuchanie przez użytkownika System umożliwia proste wygenerowanie mowy na podstawie przekazanego tekstu lub bardziej zaawansowane przy wykorzystaniu obiektu złożonego zawierającego stan Awatara. W zależności od implementacji Mózgu przy wykorzystaniu obiektu złożonego możemy otrzymać inny wynik wygenerowanej mowy w zależności od aktualnego stanu Awatara a także system może przekierować nas w inne miejsce w portalu internetowym. Przy wykorzystaniu prostego tekstu zawsze otrzymamy wygenerowaną mowę do odsłuchania. Ze względu na to iż obiekt złożony rozszerza wykorzystanie prostego tekstu podczas wygenerowania mowy, w tym rozdziale tylko ten algorytm zostanie opisany. Schemat wygenerowania komendy głosowej został przedstawiony na rys. 3.3.
  • 29. 3. Zasada działania oraz opis systemu 29 Rys 3.3. Wygenerowanie odpowiedzi na podstawie komendy głosowej. Na początku zostaje utworzony obiekt zapytania, który zawiera komendę tekstową oraz stan Awatara13 . Komenda tekstowa jest tekstem, który ma posłużyć do wygenerowania mowy. Poprzez klienta obiekt zapytania jest przekazany do Mózgu za pośrednictwem protokołu SOAP. W samym mózgu zapytanie jest przetwarzane14 . W naszym systemie następuje porównanie nadesłanej komendy głosowej czy jest ona rozpoznawana przez Mózg. W zależności od rozpoznanej lub nie komendy następuje przygotowanie odpowiedzi zwrotnej, która zawiera tekst odpowiedzi pobrany z bazy danych oraz wartości zmiany stanu Awatara w zależności od kontekstu15 w wartościach względnych16 a także opcjonalnie informację o wymaganym przekierowania użytkownika na inną stronę portalu internetowego. Odpowiedź ta jest zwracana z Mózgu do serwera mowy, który na jej podstawie przygotowuje obiekt odpowiedzi dla klienta, następnie odpowiedź ta przesyłana jest do klienta i modyfikuje na tej podstawie stan Awatara lub przekierowuje użytkownika na inną stronę w zależności czy to przekierowanie miało nastąpić, czy też nie. Równolegle na podstawie wcześniej zapisanego identyfikatora klienta, który zgłosił żądanie na wygenerowanie mowy rozpoczyna się proces generowania mowy. W tym miejscu od razu na wstępie zostaje wygenerowany unikalny numer pliku globalny dla całego serwera mowy, który będzie wykorzystany do zapisania wygenerowanej mowy poprzez wykorzystanie 13 Zwyczajowo stan Awatara jest bezpośrednio pobierany od klienta przed samym wysłaniem zapytania do Mózgu. W celu pobrania odpowiedniego stanu Awatara klient jest wcześniej odpowiednio identyfikowany, zaś samo pobranie stanu zostaje wykonane za pośrednictwem protokołu AMF. 14 W zależności od implementacji Mózgu wynik może być zupełnie odmienny. 15 Kontekst jest definiowany i pobierany przez Mózg systemu. 16 Są to wartości, które są dodawane do stanu Awatara (mogą być także wartościami ujemnymi).
  • 30. 3. Zasada działania oraz opis systemu 30 własnej implementacji modułu zapisu wygenerowanej mowy do pliku. Z syntezatora mowy zostaje pobrany odtwarzacz, który zostaje przekierowany do pliku. Zostaje wygenerowana mowa, która zostaje zapisana do pliku .wav, który jeszcze nie nadaje się do przesłania do klienta. W tym miejscu nowo wygenerowany plik zostaje przekonwertowany na podstawie implementacji konwertera biblioteki Xlugger z formatu .wav do formatu .mp3. Konwersja ta zawsze przebiega w nowym wątku. Konwerter sprawdza czy na podstawie przekonwertowanego pliku ma nastąpić rozpoznanie komendy i wykonanie akcji17 . W przypadku zwykłej konwersji do tej czynności nie dochodzi wcale. Jest ona zarezerwowana dla obsłużenia komend głosowych wydanych bezpośrednio po stronie klienta. Po wygenerowaniu pliku mowy i przekonwertowaniu go do formatu umożliwiającego jego odtworzenie w czasie rzeczywistym zostaje wysłana komenda odtwórz wiadomość w raz z nazwą pliku do odtworzenia dla klienta zgłaszającego prośbę o wygenerowanie mowy. W tym momencie klient otrzymawszy taką wiadomość, sprawdza czy połączenie z serwerem i gniazdem jest już gotowe. Jeżeli jest już gotowe to następuje odtworzenie wygenerowanej mowy w czasie rzeczywistym. W przeciwnym wypadku zgłoszenie zostaje zapisane po stronie klienta, który ponawia 5-cio krotnie próbę otworzenia oczekującej wiadomości co 0,5s. Po tym czasie próba odtworzenia wiadomości zostaje zaniechana, a klientowi zostaje przekazany komunikat o błędzie w konsoli logowania. Przebieg algorytmu generowania mowy: 1. utworzenie obiektu zapytania zawierającego tekst mowy do wygenerowania oraz stan awatara (stan pobierany jest od klienta tuż przed samym wysłaniem żądania do Mózgu) 2. przesłanie zapytania do Mózgu za pośrednictwem protokołu SOAP 3. rozpoznanie nadesłanej komendy 4. pobranie tekstu odpowiedzi z bazy danych 5. obliczenie wymaganej zmiany stanu Awatara 6. przygotowanie strony przekierowania o ile zajdzie taka potrzeba 7. wygenerowanie odpowiedzi zwrotnej 8. przekazanie odpowiedzi z Mózgu do serwera mowy 9. utworzenie komunikatu zwrotnego dla klienta 10. przesłanie komunikatu zwrotnego do klienta 11. zmiana stanu Awatara po stronie klienta 12. przekierowanie użytkownika na inną stronę o ile zajdzie taka potrzeba 13. wygenerowanie unikalnego w skali serwera mowy identyfikatora pliku 14. utworzenie pliku .wav zawierającego odpowiedź audio dla klienta 15. w nowym wątku następuje konwersja pliku .wav na plik .mp3 16. opcjonalnie następuje tu wykrycie komendy oraz wykonanie akcji na tej podstawie 17. wysłanie komendy odtwórz oczekującą wiadomość do klienta 18. klient weryfikuje czy podłączenie RTMP z serwerem jest już gotowe 19. następuje 5-cio krotna próba odtworzenia oczekującej wiadomości w czasie rzeczywistym. 17 Jest to uniwersalne rozwiązanie pozwalające usprwanić proces dalszej analizy i obróbki uzyskanego materiału audio. Rozpoznanie komendy i wykonanie akcji występuje wyłącznie w momencie, gdy komenda ta została zgłoszona bezpośrednio ze strony klienta poprzez protokół czasu rzeczywistego RTMP. W innym wypadku nie jest ona w ogóle wykorzystywana.
  • 31. 3. Zasada działania oraz opis systemu 31 Rys. 3.4. Wykorzystanie wątków podczas generowania mowy. Rysunek 3.4 przedstawia sposób wykorzystania wątków podczas generowania mowy. P0 oznacza zgłoszenie pliku oczekującego na konwersję, T0 reprezentuje konwersję pliku .wav na .mp3. Każdy plik zostaje obsłużony w osobnym wątku, następnie następuję przesłanie odpowiedzi iż pliki zostały przekonwertowane dla swoich „zleceniodawców”. 4.3.4. Rozpoznanie wydanej komendy głosowej Rozpoznanie komendy głosowej rozpoczyna się w momencie wciśnięcia i przytrzymania przycisku „Speak” w kliencie przy postaci Awatara. W tym momencie następuje nagranie materiału jeszcze audio/video na serwerze18 w czasie rzeczywistym pod wysłaną nazwą klienta. Podczas tej operacji serwer przechwytuje materiał audio/video i zapisuje go na dysku komputera. W momencie odpuszczenia przycisku przez użytkownika jest wysyłany komunikat o ukończeniu nagrywania do serwera. Teraz w nowym wątku po stronie serwera następuje konwersja pliku .flv do pliku .wav za pośrednictwem implementacji bibloteki Xuggler19 a następnie rozpoznanie komendy i wykonanie akcji opisanej w poprzednim podrozdziale. Przebieg algorytmu rozpoznania mowy: 1. rozpoczęcie procesu rozpoznania mowy następuje z chwilą wciśnięcia przycisku „Speak” po stronie klienta 2. następuje nagrywanie materiału audio/video po stronie serwera w czasie rzeczywistym 3. odpuszczenie przycisku „Speak” po stronie klienta powoduje wysłanie komunikatu do serwera o zakończeniu procesu nagrywania 18 Serwer Red5 umożliwia wyłącznie nagrywanie materiału audio/video w czasie rzeczywistym. 19 Operacja ta została opisana w rozdziale „Wygenerowanie mowy i jej odsłuchanie przez użytkownika”.
  • 32. 3. Zasada działania oraz opis systemu 32 4. w nowym wątku rozpoczyna się konwersja formatu .flv do pliku .wav 5. teraz następuje rozpoznanie komendy z otrzymanego pliku .wav 6. na tej podstawie wysyłana jest wiadomość do Mózgu a następnie występują czynności opisane w poprzednim podrozdziale. Wykorzystanie wątków w tym procesie jest analogiczne jak przy procesie generowania mowy. 4.3.5. Mózg System ten został wyposażony w bardzo prostą implementację Mózgu, która porównuje otrzymane komendy do tych zapisanych we własnej pamięci i na tej podstawie wykonuje przypisane operacje. Mózg otrzymuj kontekst danego użytkownika składający się z chwilowego stanu (emocji) Awatara, aktualnej strony WWW, z której przyszło dane żądanie oraz z komunikatu tekstowego. Na bazie kontekstu i rozpoznanej komendy z komunikatu tekstowego generowana jest na sztywno odpowiedź, która zawiera pobraną z bazy danych komendę głosową, polecenie i adres przekierowania użytkownika do innej strony internetowej oraz zmianę stanu (emocji) Awatara. Zmiana stanu Awatara w tej implementacji Mózgu polega na jego zmianie w losowej wartości zmiany w określonym zakresie20 . 4.3.6. Stan (emocje) Awatar wyposażony jest w samoistną świadomość wyposażoną w mechanizm „zapominania”, który działa wyłącznie po stronie klienta i doprowadza stan (emocje) do stanu znormalizowanego. Stan Awatara przechowywany jest na komputerze klienta i zapamiętywany jest nie tylko poprzez daną sesję użytkownika (które de facto nie wymaga chociażby zalogowania się do systemu), ale pamiętany jest od czasu ostatnich odwiedzin portalu internetowego. Pamięć ta opiera się na mechanizmie Shared Object platformy Adobe Flash, który w uproszczeniu21 jest odpowiednikiem pliku ciasteczka (ang. cookie). Na bazie aktualnego stanu Mózg jest w stanie wygenerować inną odpowiedź, która spowoduje odmienne zachowanie się Awatara oraz zmieni modulację jego głosu22 . Graficzna postać Awatara jest animowana23 na bazie stanu w sposób ciągły (patrz rys. 3.5), natomiast komenda głosowa w całości uwzględnia stan z momentu jej wygenerowania. Rys. 3.5. Animacja postaci Awatara w zależności od stanu (emocji). 20 Dzięki aktualnej implementacji możemy określić zachowania Awatara jako nieobliczalne. Jednak jest to tylko i wyłącznie kwestią implementacji Mózgu. 21 Tak naprawdę Shared Object jest obiektem o wiele bardziej zaawansowanym niż ciasteczko. 22 Modulacja zawiera zmianę szybkości mówienia, częstotliwości oraz wysokości głosu. 23 Animacja uwzględnia powiększenie oraz pomniejszenie źrenic, zmianę kolorystyki twarzy oraz zmianę tępa animacji mowy w momencie, gdy Awatar nam odpowiada.
  • 33. 3. Zasada działania oraz opis systemu 33 4.4. Opis wyników Pierwsze testy integralne całego systemu wykazały jego stabilną pracę. Jednak wykorzystane biblioteki rozpoznawania i syntezy mowy, pomimo iż zostały wykorzystane ich najbardziej dopracowane biblioteki w wersji Open Source pozostawiają jeszcze wiele do życzenia. Jakość wygenerowanej mowy nie jest wysokiej jakości, a sam system rozpoznawania mowy charakteryzuje się wysokim progiem błędów, przez co wydawane komendy są źle interpretowane. Biblioteki te są stale rozwijane, jednak tempo ich rozwoju nie jest zbyt wielkie, lecz gdy pojawią się ich lepsze odpowiedniki będzie można je podmienić w systemie. 4.5. Struktura oprogramowania Tak jak zostało to już wcześniej wielokrotnie napisane cały system został wykonany jako zbiór wielu modułów wymienionych w tab. 3.1. Każdy moduł jest niezależnym projektem. Wszystkie kluczowe moduły posiadają oddzielne aplikacje testujące. Tab. 3.1. Moduły systemu. l.p. moduł technologia opis 1. Administrator Java, JSF, EJB, JSoup, HTML, JAAS część administracyjna 2. AdministratorTest Java, Junit testy jednostkowe 3. Avatar Flash, AS postać Awatara 4. BrainService Java, EJB, WSDL, WSDL, Web-Service, SOA Mózg 5. BrainServiceClient Java, Web-Service, SOA klient Mózgu 6. BrainServiceClientTest Java, Junit testy jednostkowe 7. PortalPG Java, JSF, HTML, JS, CSS portal demonstracyjny 8. SpeechAvatar Flex, AS, MXML, RTMP, AMF klient 9. SpeechModel Java, JPA, EJB, Entity, ORM odwzorowanie bazy danych, model danych oraz fasada 10. SpeechModelTest Java, Junit testy jednostkowe 11. SpeechServer Java, Spring, Injection, RTMP, AMF serwer mowy 12. SpeechServerTest Java, Junit testy jednostkowe 13. Baza danych Oracle, SQL baza danych Następujące moduły składają się na systsem:  Administrator  BrainService  PortalPG  SpeechModel
  • 34. 3. Zasada działania oraz opis systemu 34 4.6. Podsumowanie Jak zostało to przedstawione w tym rozdziale architektura systemu jest mocno rozproszona. Praktycznie każdy moduł może istnieć niezależnie, jednak wszystkie moduły razem wzięte tworzą pełną platformę. Taka budowa zapewnia dobrą rozbudowę systemu.
  • 35. 4 5.REALIZACJA PRACY 5.1. Wprowadzenie W momencie realizacji niniejszego projektu posiadałem już wieloletnie doświadczenie w programowaniu głównie systemów internetowych w różnych technologiach, w tym systemów rozproszonych oraz korporacyjnych. Dzięki temu swobodnie mogłem skupić się na sposobie implementacji technologii Speech (rozpoznawania i syntezy mowy) dla celów komunikacji użytkownika z systemem za jej pośrednictwem w portalu internetowym. Technologia ta jest dla mnie pewnym nowym wyzwaniem, które zamierzam zrealizować. Na chwilę obecną nie ma żadnych gotowych samouczków czy pomocy naukowych które opisały by sposób wykonania takiego systemu. Do dyspozycji mamy odrębne elementy opisane osobno, które należy zmusić do współpracy ze sobą w pewnych określonych warunkach (w naszym przypadku chodzi o zastosowanie klient-serwer, z wykorzystaniem dodatkowych zasobów po stronie klienta co jest dodatkowym utrudnieniem). Realizacja całego projektu przebiegała przy ciągłej współpracy i pod nadzorem Pana prof. dr hab. inż. Zdzisław Kowalczuk, który wyznaczył kierunek wykonanej pracy oraz czuwał nad tym aby nie był to projekt zamknięty, ale mógł być kontynuowany przez kolejne lata na uczelni. Wykonanie pracy zostało podzielone na kilka kluczowych etapów opisanych poniżej. Wyszczególnione etapy zostały wyodrębnione na bazie poszczególnych funkcji bądź założeń, które nie koniecznie zostały wykonane w opisanej kolejności, a często były tworzone równorzędnie. Etapy realizacji projektu: 1. zapoznanie się z technologią Speech oraz AI 2. wykonanie systemu analizy serwisu 3. system generowania oraz rozpoznawania mowy 4. silnik AI wraz z inicjacją "świadomości" bota oraz z implementacją 4 stanów emocji 5. stworzenie prostej graficznej postaci Awatara komunikującej się z silnikiem AI
  • 36. 4. Realizacja pracy 36 6. utworzenie demonstracyjnego serwisu z implementacją postaci Awatara 7. przygotowanie odpowiedniej dokumentacji. 5.2. Testowanie platformy Podstawową techniką testowania systemu jest wykorzystanie jednostek testowych, które weryfikują cząstkowe działanie systemu. System powstawał krok po kroku, z małego rozwinął się w duży wykonując testy użytkownika podczas jego działania. Skala złożoności i zależności systemu jest tak duża, że do pomocy został wykonany specjalny system logowania, który informuje użytkownika o pracy całego systemu umożliwiając wykrycie różnego rodzaju dolegliwości i problemów w systemie, którego przetestowanie jest o tyle skomplikowane, iż opiera się na mowie, stanie Awatara, który nie bazuje na sesji a dodatkowo rozproszony jest na wiele pod stron, niezależnych żądań przekierowań, ale jednak tworzących pewną całość, która była testowana poprzez użytkownika systemu. 5.3. Omówienie sposobów rozwiązania problemów Głównym problemem, który pojawił się na początku było spasowanie i dobór istniejących technologii do wykonanego projektu. Nadrzędnym celem jest uzyskanie wysokiej jakości produktu przy wykorzystaniu technologii Open Source, tak aby projekt mógł być dalej rozwijany przez uczelnie. Tak więc po wybraniu kluczowych technologii rozpoznawania i syntezy mowy nastąpiło pasowanie do nich technologii pomocniczych. Tutaj pojawiły się już pierwsze ograniczenia, które wskazały jakie formaty danych są obsługiwane przez powyższe technologie. W tym momencie nastąpiło poszukiwanie technologii wspierających Możliwość pracy rozproszonej dodatkowo komplikuje sam fakt dostępu do zasobów komputera użytkownika (mikrofonu i głośników), który domyślnie jest zablokowany. W tym celu została wykorzystała wykorzystana technologia Adobe Flex, która daje dostęp do wymaganych zasobów. 5.4. Podsumowanie W informatyce mówi się, że po wykonaniu 80% projektu do jego ukończenia pozostało pozostałe 90%, co miało miejsce także i w tym projekcie. Projekt był nowatorski, wiele się z niego nauczyłem, bardzo mnie rozwinął, pokonałem w nim wiele przeszkód i rozwiązałem wiele problemów.
  • 37. 5 6.MOŻLIWOŚCI ROZWOJU SYSTEMU 6.1. Wprowadzenie We wczesnym etapie planowania projektu jednym z jego głównych elementów było wymaganie, które mówiło iż projekt powinien być dalej rozwijany po jego ukończeniu. Zostało jasno powiedziane, iż należy go tak przygotować, aby potem można było go w prosty sposób rozwijać i podzielić jego dalszą pracę nad nim nad poszczególnymi modułami. I tak też się stało. 6.2. Rozwój klienta System można wzbogacić o dodatkowe możliwości konfiguracyjne dla użytkownika. Użytkownik mógłby podać swoje imię lub inne dane, które były by uwzględniane podczas dalszej interakcji z systemem. Można by dać możliwość wyboru postaci Awatara, głosu przez niego używanego oraz np. możliwości zmiany Mózgu, która charakteryzowała by się całkowicie odmienną pracą systemu. 6.3. Rozwój systemu generowania mowy System generowania mowy można wyposażyć w dodatkowe głosy, które mogą być przełączane po stronie klienta. Istnieje także możliwość, aby utworzyć własne głosy, jest to jednak zadanie bardzo pracochłonne i obarczone dużym ryzykiem niepowodzenia. Ogólnie jest możliwość dodania głosów w innych wersjach językowych, jednak w tym miejscu problemem może okazać się brak możliwości dostosowania systemu rozpoznawania mowy w tych językach1 . Istnieje możliwość doposażenia systemu w nowe dodatkowe możliwości sterujące generacją głosu w rodzaju możliwości sterowania prędkością, wysokością i częstotliwością 1 Problem ten dotyczy sytuacji dnia dzisiejszego.
  • 38. 5. Możliwości rozwoju systemu 38 głosu. Także w tym miejscu można przygotować obsługę poprawnej wymowy znaków specjalnych, skrótów i innych zapisów specjalnych. 6.4. Rozwój systemu rozpoznawania mowy System rozpoznawania mowy można wyposażyć w kolejne komendy jeszcze bardziej zaawansowane oraz o większą ich ilość. Teoretycznie istnieje możliwość nauczenia systemu do rozpoznawania nowych nazw jeszcze nie zdefiniowanych w istniejących słownikach, co jest bardzo czasochłonne i obarczone jest dużym ryzykiem niepowadzenia. Można tutaj pomyśleć o implementacji mechanizmów rozpoznawania ciągłej mowy. 6.5. Rozwój postaci Awatara Postać Awatara można dopracować graficznie, dopieścić jego animację i reakcję na zmianę stanu. Można by stworzyć pakiet postaci Awatarów, z których użytkownik mógłby wybrać ten z którym chciał by się utożsamić. 6.6. Rozwój Mózgu Rozwój Mózgu daje najwięcej możliwości ponieważ może całkowicie zmienić zachowanie systemu w danej sytuacji. Można by dodać do Mózgu informacje o danych poczynaniach danego klienta, np. w celu usunięcia głupich odpowiedzi w nieskończoność typu „Jak się nazywasz?”, gdzie po kilku takich pytaniach Awatar mógłby zwrócić uwagę klientowi, iż pytał się już o to wielokrotnie. Co najważniejsze można by pomyśleć o implementacji autonomicznego umysłu Awatara, który w określonych warunkach mógłby samodzielnie podejmować decyzję, jak ma to miejsce np. w Dictobot’cie oraz wiernie zaimplementować jego stan. 6.7. Podsumowanie Na rynku obecnie nie ma zbyt wiele (o ile istnieją) takich lub podobnych systemów. Warto podjąć kontynuację niniejszego projektu oraz zbadać i przetestować nowe możliwości, które on ze sobą niesie.
  • 39. 6 7.PODSUMOWANIE ORAZ WNIOSKI Z PRACY 7.1. Podsumowanie oraz wnioski z pracy Praca nad systemem była wymagająca, rozwojowa, ale i wciągająca. System który powstał jest niekonwencjonalny, przełamał wiele barier technologicznych oraz pokazał praktyczne zastosowanie wielu różnych technologii. W chwili obecnej nie udało mi się znaleźć żadnego odpowiednika niniejszego systemu1 lub systemu, który w dużej części odpowiadał by obecnej realizacji. Do jego realizacji poświęciłem naprawdę wiele czasu, wiele nocy nie przespałem, kilka tygodni wolnego z pracy także zostało spożytkowane w tym celu. Sporą część realizacji zawdzięczam Panu prof. dr hab. inż. Zdzisław Kowalczuk, który nadał kierunek i pokierował pracą w tę stronę, w której praca obecnie się znajduje a także poświęcił wiele czasu nad jej realizacją, za co jestem bardzo wdzięczny. Wykonanie systemu było dla mnie niezwykle rozwijające, nauczyłem się wiele z samych technologii informatycznych, ale także poznałem elementy, które nadają „życia” temu komputerowemu projektowi. Był to czas, którego nie żałuję iż wykorzystałem go w taki a nie w inny sposób. Projekt obecnie znajduje się na wstępnej rozwojowej drodze, tak więc nadaje się on do podjęcia jego rozbudowy i dopracowania, tak aby był w stanie godnym przedstawienia go szerszemu gronu odbiorców. 1 Mogę z wielką pewnością stwierdzić, iż taki odpowiednik nie istnieje wcale.
  • 40. 40 8.Dodatek 1. Skrótowy opis aplikacji Tytuł dyplomu System inteligentnej nawigacji sterowanej głosem po serwisie internetowym. Cel i przeznaczenie aplikacji Opracowanie głosowego systemu komunikacji oraz nawigacji po serwisie internetowym. Projekt zakłada wykonanie portalu testowego, systemu rozpoznawania i generowania mowy, mózgu systemu oraz postaci Awatara komunikującego się z użytkownikami oraz kierującego ich po serwisie. System ma być inteligentny w tym znaczeniu, iż Awatar nie będzie nas tylko słuchał, ale także będzie z nami w dialogu wyrażając się poprzez swoje emocje. Wykonanie projektu zakłada komunikację w języku angielskim. Funkcjonalność Opis realizowanych funkcji  Praca w Internecie bez potrzeby zalogowania się  Równoczesna obsługa wielu użytkowników w osobnych wątkach  Stan Awatara wyposażony w 4 niezależne wartości  Pamięć stanu Awatara  Rozpoznawanie wybranych komend głosowych  Generowanie mowy z uwzględnieniem aktualnego stanu Awatara  Odtwarzanie oraz nagrywanie mowy w czasie rzeczywistym  Konwersja formatów: FLV -> WAV -> MP3 w osobnych wątkach  Funkcjonalny portal demonstracyjny  Panel administratora  Niezależny Mózg systemu generujący mowę, odpowiedź i przekierowanie w zależności od kontekstu jako Web-Service  Wizualizacja postaci Awatara, który graficznie przedstawia swój stan  Animacja ruchu ust Awatara podczas jego mowy  Prosta implementacja modulacji głosu Awatara w zależności od jego stanu  Możliwość edycji generowanych komunikatów głosowych  Podgląd stanu bazy danych poprzez Panel Administracyjny  Pamięć użytkownika poprzez całą komunikację po portalu (wielo-stronnicowa)  Rozpoznanie czy użytkownik przyszedł po raz pierwszy na Portal czy powrócił tu ponownie, np. zmieniając wyświetlaną stronę  Przekierowanie na nową stronę portalu na podstawie wydanej komendy głosowej  Głosowa wiadomość powitalna dla każdej pod-strony  Zaawansowany system zdarzeń informacji o pracy całego systemu po stronie użytkownika, który daje wgląd w pracę całego systemu we wszystkich modułach  Kompresja wygenerowanej mowy w celu przyśpieszenia odtworzenia wiadomości  Zaimplementowana najwyższa jakość generowanego i rozpoznanego głosu, jaki daje zastosowana biblioteka (zastosowane ustawienia na 16kHz)  Mechanizm kilkukrotnego ponowienia odtworzenia oczekującej wiadomości głosowej o ile system nie został jeszcze w pełni zainicjalizowany  Osobne przechowywanie plików audio dla wejścia i wyjścia sygnału
  • 41. 41  Funkcja zapominania stanu Awatara po stronie klienta  Opcja nagrywania mowy za pomocą jednego wciśnięcia i przytrzymania przycisku  Zastosowany system znaczników mowy pozwalający na implementację tego systemu na dowolny Portal Internetowy. Lista przykładowych zastosowań  Odsłuchiwanie zawartości strony Portalu Internetowego  Umilenie pracy użytkownika  Nawigacja po portalu za pomocą wykorzystania własnego głosu  Zabawa z Awatarem w celu rozpoznania jego emocji poprzez odsłuchiwanie jego mowy  Dialog z Awatarem, po odpowiednim dopracowaniu Mózgu można zrobić z niego tzw. Zwierzątko, które będzie żyło własnym życiem  Po odpowiednim dopracowaniu inteligentne wyszukiwanie i filtrowanie zawartości portalu. Szczegółowe opisy działania aplikacji Aplikacja jest typu klient-server. Klient jest to część, która znajduje się po stronie użytkownika, zapewnia ona komunikację z serwerem, jest ona interfejsem użytkownika, który wydaje komendy głosowe, odsłuchuje komunikaty oraz przedstawia graficzną postać Awatara zmieniającą się w zależności od swojego stanu. Serwer zajmuje się rozpoznawaniem oraz generowaniem mowy, obsługą połączeń klientów oraz komunikacją z Mózgiem systemu. Wykonany system jest platformą, portal demonstracyjny jest jedynie pokazem jego zastosowania. Z tego względu działanie aplikacji możemy wydzielić na dwie części. Pierwszą z nich jest wygenerowanie na podstawie wcześniej przygotowanych znaczników mowy zawartości portalu, która posłuży Mózgowi do odsłuchania (wygenerowania mowy), wyszukania informacji oraz przekierowania w odpowiednie miejsce portalu. Za tę część odpowiedzialny jest system znaczników oraz część administracyjna, która generuje treść portalu bazując na dostarczonym sitemap strony. Generator przechodząc kolejno przez strony zapisane w sitemap, parsuje je, wyciąga przygotowane informacje oraz w odpowiedni sposób indeksuje i buforuje dane w bazie danych. Działanie samego systemu opiera się na samoistnej świadomości Awatara, który wyposażony jest w mechanizm „zapominania”, który działa wyłącznie po stronie klienta. Stan Awatara przechowywany jest na komputerze klienta i zapamiętywany jest nie tylko poprzez daną sesję użytkownika (które de facto nie wymaga chociażby zalogowania się do systemu), ale pamiętany jest od czasu ostatnich odwiedzin portalu internetowego. Pamięć ta opiera się na mechanizmie Shared Object platformy Adobe Flash, który w uproszczeniu1 jest odpowiednikiem pliku ciasteczka (ang. cookie). Użytkownik wchodząc na portal w pierwszej kolejności zostaje przywitany odpowiednim komunikatem oraz zostaje zapamiętany w systemie, tak że podczas kolejnej wizyty w trakcie danej sesji zostanie on już w inny sposób obsłużony, tzn. otrzyma inny komunikat powitalny. Obsługa rozpoznania klienta znajduje się po stronie Serwera Mowy, który posiada zapisaną listę aktualnie podłączonych klientów. Podczas każdego załadowania strony następuje inicjalizacja połączenia, każde połączenie jest weryfikowane czy może zostać obsłużone w kanale RTMP zapewniającym nagrywanie i odsłuchiwanie komunikatów głosowych w czasie rzeczywistym. Także w tym momencie następuje rezerwacja mikrofonu oraz zapytanie o zgodę na jego wykorzystanie. Gdy proces ten przebiegnie pomyślnie Serwer Mowy przesyła dla klienta potwierdzenie, iż połączenie 1 Tak naprawdę Shared Object jest obiektem o wiele bardziej zaawansowanym niż ciasteczko.
  • 42. 42 zostało nawiązane, wówczas klient w odpowiedzi przesyła prośbę o wygenerowanie komunikatu powitalnego oraz przesyła swój stan (emocje, które w danym momencie mogą być inne niż domyślne). Na podstawie prośby i stanu Serwer Mowy za pośrednictwem Mózgu generuje wiadomość powitalną, która na bazie zaktualizowanego stanu Awatara zostaje odpowiednio zmodulowana2 . Informacja o wygenerowanej i oczekującej wiadomości do odsłuchania zostaje przesłana dla klienta, który automatycznie odtwarza ją3 . Równocześnie klient otrzymuje od Mózgu za pośrednictwem serwera mowy bodziec zmieniający stan Awatara (jego emocje), który zostaje już stopniowo zaktualizowany po stronie klienta4 . Podobnie ma się sprawa z wysłaniem komendy głosowej, która nagrywana jest podczas przyciśnięcia i przytrzymania przycisku „Speak”. W tym czasie mowa zostaje bezpośrednio nagrywana na serwerze mowy. Po zakończeniu nagrywania komendy głosowej, zostaje pobrany stan Awatara od klienta, z nagranej mowy zostaje rozpoznana komenda głosowa, która przesyłana zostaje do Mózgu systemu. Mózg posiadając informacje o aktualnym stanie Awatara generuje odpowiedź, która przekazywana jest do klienta. Odpowiedź zawiera wygenerowany komunikat głosowy, zmianę stanu Awatara (emocji) oraz ewentualnie adres nowej strony, na którą klient powinien zostać automatycznie przekierowany. Architektura sprzętu Elementy rozpoznawania i generowania mowy wymagają silnego serwera, aby były w stanie obsłużyć wielu użytkowników równocześnie oraz aby zapewnić krótkie czasy reakcji na wypowiadane i generowane komendy głosowe. Do pracy z systemem wymaga się komputera wyposażonego w głośniki i mikrofon, które nie są wymagane po stronie serwera. Do wykonania systemu korzystałem z dwóch środowisk:  deweloperskie – wyposażone w komputer o procesorze Pentium 4x2.66 GHz oraz 4 GB RAM, 300 GB HDD  produkcyjne – wyposażone w komputer o procesorze Pentium 4x2.66 GHz oraz 16 GB RAM, o przepustowości Internetu 100Mbps oraz 2TB HDD System wymaga silnego serwera oraz dużej przestrzeni dyskowej, ponieważ dla jednego użytkownika podczas kilku godzin pracy generowanych jest kilkaset megabajtów danych audio w przeciągu kilku dni5 . Architektura oprogramowania Architektura systemu została przedstawiona na rys. 7.1. Cały system został wytworzony w technologii Java/Flex. Technologia Adobe Flex została wykorzystana do utworzenia klienta, natomiast część serwerowa została wykonana w technologii Java. Budowa platformy jest modułowa, umożliwiająca niezależny rozwój i wymianę każdego z modułów. 2 Modulacja polega na zmianie parametrów audio generowanej mowy. 3 Odtworzenie nagranego komunikatu głosowego następuje w czasie rzeczywistym przy wykorzystaniu protokołu RTMP. 4 Zmiany stanu (emocji) Awatara dokonywane są po stronie klienta na bazie otrzymanych informacji o ile dany stan (emocja) powinien zostać zmieniony. 5 Do klienta zostaje przesłany materiał w wersji skompresowanej o kilku, a czasem kilkunasto krotnie mniejszej objętości. Tylko po stronie serwera zostają wygenerowane dane o dostępnej najwyższej jakości danych, które następnie zostają skompresowane i przekazane dla klienta.
  • 43. 43 Rys. 7.1. Ogólna architektura systemu. Część kliencka odpowiada za komunikację z serwerem, przydzieleniem uprawnień do mikrofonu i głośników, wygenerowaniem unikalnego identyfikatora dla klienta, który następnie jest wykorzystywany przez serwer do jego identyfikacji. Także w tej części użytkownik ma kontakt z systemem, obserwuje wizualnie postać Awatara, wydaje komendy oraz słucha systemu, tutaj także znajduje się aktualna wizualizacja stanu Awatara w postaci wykresu słupkowego oraz konsola logów z całego systemu, w której użytkownik monitoruje stan systemu w danym momencie. Po stronie klienta przechowywany jest aktualny stan Awatara unikalny dla każdego użytkownika. jednak jest on przypisany na stałe do danego komputera, a czasem przeglądarki. Część serwerowa została oznaczona kolorem zielonym. Fizycznie część ta podzielona jest na dwa serwery: serwer mowy jest serwerem czasu rzeczywistego, jest to serwer Red5 RC 1.0, który opiera się na platformie Apache Tomcat 6 działający na porcie 8080 dla protokołu HTML oraz na porcie 1935 dla protokołu RTMP, drugim serwerem jest Oracle WebLogic 11g na którym działa „Mózg” systemu, część administracyjna oraz portal demonstracyjny. Sewer standardowo działa na porcie 7001 dla protokołu HTML. Serwer mowy jest kluczowym elementem całego systemu, zwyczajowo nazywany „serwerem” niniejszego systemu. To bezpośrednio z nim komunikuje się klienta (a w zasadzie użytkownik systemu). Serwer ten wydziela dalszą interakcję z użytkownikiem. Na serwerze tym zostały utworzone moduły generowania i syntezy mowy, klienta mózgu, obsługi i konwersji danych audio przesyłanych w czasie rzeczywistym. Także w tym miejscu znajduje się lista słów i komend rozpoznawalnych przez system w formacie JSGF (ang. Java Speech Grammar Format). W tym miejscu mamy konfiguracje systemów rozpoznawania i syntezy mowy w formatach zdefiniowanych przez specyfikacje bibliotek FreeTTS oraz Sphinx4.
  • 44. 44 Wykonany serwer mowy posiada architekturę wielo-wątkową6 (ang. Multithreading), tak więc każde żądanie nowego klienta obsługiwane jest w nowym wątku. Konwersje formatów danych audio są także wykonywane wielo wątkowo. Rozpoznanie komendy głosowej z wygenerowaniem odpowiedzi również zachodzi w osobnym wątku. Wymienione elementy posiadają wykonaną własną implementację nie zależną od standardu Javy, która samodzielnie próbuje dzielić zadania na wiele wątków. Mózg jest drugim serwerem, który odpowiada za logikę aplikacji. Komunikuje się on bezpośrednio i wyłącznie z systemem mowy, od którego dostaje komendę użytkownika już w postaci tekstowej, identyfikator klienta oraz stan Awatara oraz zwraca akcję do wykonania przez klienta wraz z komendą zmiany stanu Awatara lub wykonania przekierowania do innej strony w portalu internetowym. Komunikacja systemu mowy następuje poprzez klienta Mózgu, który komunikuje serwer mowy z „Mózgiem” poprzez protokół SOAP przy wykorzystaniu dokumentu WSDL w technologii rozproszonej SOA. To rozwiązanie umożliwia łatwe dodawanie nowych implementacji Mózgu oraz przełączanie ich w czasie działania aplikacji. Mózg na podstawie otrzymanych danych i przetworzeniu posiadanych decyduje o wykonanej interakcji w portalu internetowym za pośrednictwem serwera mowy, który dodatkowo może wygenerować komunikaty głosowe dla użytkownika oraz przesłać komunikaty zmiany stanu Awatara lub zadecydować o wykonaniu przekierowania użytkownika do innej strony na portalu internetowym. Klient łączy się z częścią serwerową za pośrednictwem protokołów RTMP i AMF (ang. Action Message Format). Za pomocą protokołu RTMP przesyłany jest wyłącznie sygnał audio w czasie rzeczywistym bez potrzeby przesyłania całego materiału w całości7 . Natomiast protokół AMF służy wyłącznie do wymiany komunikatów pomiędzy serwerem a klientem. Komunikaty te zawierają informacje typu: stan Awatara, komendy tekstowe przesyłane do serwera w postaci czytelnego tekstu, informacje zwrotne dla klienta kiedy czeka na niego wiadomość do odsłuchania, komunikaty logów8 ze strony serwera itp. Klient-serwer komunikuje się ze sobą wyłącznie za pośrednictwem tych dwóch protokołów. Serwer mowy komunikuje się z Mózgiem za pośrednictwem protokołu SOAP w technologii rozproszonej SOA. Wyłącznie Mózg komunikuje się z bazą danych. W ten sposób zostały jasno wyznaczone warstwy systemu. Opis metody wytwarzania aplikacji Cykl wytworzenia niniejszej aplikacji przedstawia się następująco: 1. zapoznanie się z technologią Speech oraz AI 2. wykonanie systemu analizy serwisu 3. system generowania oraz rozpoznawania mowy 4. silnik AI wraz z inicjacją "świadomości" bota oraz z implementacją 4 stanów emocji 5. stworzenie prostej graficznej postaci Awatara komunikującej się z silnikiem AI 6 Architektura wielo-wątkowa pozwala na równoległą realizację żądań wielu użytkowników równocześnie. Najczęściej żądania są rozdzielane równomiernie na dostępne procesory i rdzenie dzięki czemu wykonywane operacje powinny odbywać się szybciej (choć nie zawsze, jeżeli liczba wątków jest zbyt duża) i powinny pozwolić na wykonanie danej operacji przez nowego użytkownika bez potrzeby oczekiwania na zakończenie wykonywanych operacji przez innych użytkowników (jednak w praktyce nie zawsze tak jest, jest to zależne od danej implementacji). 7 Protokół RTMP w odróżnieniu od innych protokołów naprawdę przesyła dane w czasie rzeczywistym. Inne protokoły najczęściej „udają”, że przesyłają materiał czasie rzeczywistym, lecz np. przesyłają go w partiach, a nie bit po bicie jak dzieje się to w przypadku wykorzystania protokołu RTMP. 8 Komunikaty te informują klienta co dzieje się po stronie serwera. W przypadku jakichkolwiek problemów po stronie serwera klient jest informowany o tym fakcie.