1. Wstęp

W dzisiejszym, wysoko zinformatyzowanym świecie telefony i tablety ze stałym dostępem do internetu, sieci lokalnej bądź innych rodzajów łączności bezprzewodowej są niezwykle popularne. Według bieżących statystyk na świecie jest 1.2 miliarda użytkowników globalnej sieci którzy korzystają do tego celu z urządzeń mobilnych, zaś sprzedaż tego typu urządzeń rośnie w tempie dwucyfrowym rok do roku. Jest to ogromny, dosyć mocno eksploatowany rynek, jednak według nas ma on ciągle niewykorzystany potencjał.

Każda osoba korzystająca ze smartfona lub mobilnego tabletu mogłaby korzystać z niego nie tylko do pozyskiwania informacji czy komunikacji, ale również do sterowania innymi urządzeniami elektronicznymi. Dzięki spadającym cenom komponentów elektronicznych takich jak mikroprocesory lub modemy bezprzewodowe możliwe staje się montowania miniaturowych komputerów w coraz szerszej gamie otaczających nas sprzętów. Łatwo wyobrazić sobie możliwość sterowania za pomocą telefonu komórkowego domowym sprzętem AGD/RTV, ale również bardziej zaawansowanymi urządzeniami takimi jak sprzęt pomiarowy czy medyczny. Dzięki łączności bezprzewodowej możliwe staje się monitorowanie interesujących nas zależności z niemal każdego miejsca globu, czy w mniejszej skali z dowolnego miejsca danego budynku.

Największym problemem w popularyzacji tego typu rozwiązań jest wielość różnych standardów komunikacyjnych pomiędzy urządzeniami elektronicznymi. Niemal każdy producent sprzętu elektronicznego czy oprogramowania rozwiązuje problemy komunikacji w nieco inny sposób przez co telefon firmy A nie jest w stanie sterować urządzeniem firmy B. W niektórych przypadkach problem leży po stronie sprzętowej – jedne urządzenia posiadają np. możliwość komunikacji po interfejsie Bluetooth, inne zaś potrafią korzystać tylko z lokalnej sieci WiFi. Często zaś zdarza się, iż urządzenia posiadają odpowiednie komponenty warstwy fizycznej jednak problem tkwi w oprogramowaniu – aplikacja zainstalowania na urządzeniu mobilnym nie potrafi odebrać lub zinterpretować danych wysyłanych przez nadajnik.

Uważamy, że istnieje potrzeba unifikacji sposobów komunikacji urządzeń mobilnych z różnego rodzaju sprzętem funkcjonalnym. Najlepszym rozwiązaniem było by stworzenie uniwersalnego oraz elastycznego zestawu oprogramowania i sprzętu, który mógłby być implementowanych przez producentów urządzeń i software'u, małym nakładem pracy zapewniając kompatybilność z rozwiązaniami obecnymi na rynku.

2. Architektura interfejsu MMS

2.1. Algorytm połączenia (sieć LAN)

Aby urządzenie mobilne takie jak smartfon lub tablet ze wspieranym systemem operacyjnym (obecnie iOS, Android i Windows Phone 7) muszą znajdować się w tej samej sieci LAN co serwer z którym urządzenie ma się połączyć. W sieci musi być również możliwe rozsyłanie broadcastów które są podstawą metody wyszukiwania się urządzeń w sieci.

Po włączeniu aplikacji mobilnej, użytkownik aktywuje wyszukiwanie kompatybilnych serwerów interfejsu MMS. W tym celu aplikacja rozsyła pakiety w formacie UDP z metodą SEARCH i innymi parametrami zgodnymi z SSDP ([1] - strona 31) i dodatkowym polem zawierającym nazwę i wersję interfejsu MMS (obecnie 0.1).

Jeśli w aktywnej sieci WiFi znajdują się jakieś urządzenia pracujące w standardzie MMS odpowiadają one pakietem UDP typu unicast pod adres nadawcy z pakietu typu broadcast. Dzięki temu urządzenie wyszukujące dowiaduje się o urządzeniach typu MMS w sieci LAN i poznaje ich adresy IP.

Po zebraniu listy wszystkich dostępnych urządzeń pomiarowych w sieci, korzystając ze standardy WebSockets tworzy połączenie z każdym z serwerów. Od razu po nawiązaniu połączenia typu WebSocket [2], serwer wysyła do urządzenia klienckiego swoją konfigurację (Rys 2.1) w formacie JSON [3]

Aplikacja kliencka parsuje otrzymany plik JSON i generuje na jego podstawie interaktywne GUI dzięki którym można zobaczyć oraz edytować wybrane parametry czujnika w urządzeniu pomiarowym.

Po zaakceptowaniu parametrów czujnika przez użytkownika, aplikacja mobilna wysyła do serwera żądanie rozpoczęcia pomiarów wraz uaktualnionymi parametrami czujników o ile użytkownik je edytował. Serwer odsyła status (Rys 2.2) i o ile jest on oznaczony kodem sukcesu rozpoczyna się proces pomiarowy z ustalonymi wcześniej parametrami.

-------------
1. UPnP™ Device Architecture 1.1, 2008, October 15
2. WebSocket official webpage, Luty, 2013, http://www.websocket.org
3. JSON Introduction, Luty, 2013, http://www.json.org

3. Hardware

W projekcie MMS skupiono się nad opracowaniem oprogramowania pozwalającego użytkownikom końcowym (tablet'ów, smartphone'ów) abstrahować od fizycznej (sprzętowej) realizacji systemu (kontrolno-pomiarowego) - realizacja sprzętowa musi być widziana jako 'Black Box' (Rys 3.1). W przypadku elektroników-konstruktorów takiego systemu nie jest możliwe abstrahować od fizycznej realizacji. Ponadto istnieje wiele możliwości konstrukcji i połączeń takiego systemu.

Rys 3.1 Ogólna konfiguracja MMS

W ramach projektu MMS dotyczących fizycznej realizacji skupiono się nad:

- Wykorzystaniem pierwowzoru w postaci urządzenia CTI-VMAX [1],

- Wykorzystaniem płytek nakładkowych kompatybilnych z CTI-VMAX,

- Wykorzystaniem interfejsów sieciowych przewodowych (Ethernet) oraz bezprzewodowych (Bluetooth, WIFI),

- Przetestowaniem oraz przystosowaniem (pod kątem MMS) platform sprzętowych:

- CTI-VMAX,

- BeagleBone [2],

- Cubieboard [3],k

- Opracowaniem bloków HDL dla istniejących dla CTI-VMAX płyt nakładowych ARM SCOPE 1.0.1 oraz ARM SCOPE 1.0.2,

- Opracowaniem bloków HDL dla interfejsów wymiany informacji pomiędzy płytami nakładkowymi a płytą matką dla każdej platformy sprzętowej,

- Wykorzystaniem smartphone'a firmy Apple.

3.1 CTI-VMAX i nakładki ARM SCOPE

CTI-VMAX (Rys 3.2) jest komputerem przemysłowym (ARMPUTER) opartym o procesor ARM9, z wyprowadzonymi na zewnątrz interfejsami takimi jak: Ethernet, USB, I2C, RS232. Ponadto istnieje możliwość rozbudowy funkcjonalności poprzez system płyt nakładkowych - np. można zwiększyć ilość lub rodzaj interfejsów wyprowadzonych na zewnątrz.

Rys 3.2 CTI-VMAX w obudowie wraz z płytą nakładkową ARM SCPOPE v1.0.2

CTI-VMAX został wybrany jako wzór urządzenia M2M ze względu na:

- Kompaktowość (rozmiary) względem funkcjonalności,

- Wsparcie techniczne - dostęp do pełniej dokumentacji,

- Możliwości rozbudowy przez system nakładek,

- Interfejs nakładek typu synchroniczny lub asynchroniczny NAND/NOR Flash - szybki i prosty,

- Istnienie gotowego zestawu nakładek (Rys 3.3) opartych o FPGA Cyclone II (obsługiwanych przez darmowe wersje Quartus II [4]):

ARM SCOPE v1.0.1 - zawierającej 4 kanały szybkich przetworników ADC-100MSPS,

ARM SCOPE v1.0.2 - zawierającej 8 kanałów wolnych przetworników ADC, do aplikacji mierzenia jakości energii elektrycznej,

- Wyposażenie w procesor typu ARM.

Rys 3.3 Prawy górny róg - CTI-VMAX.\\ Lewy górny róg - nakładka ARM SCOPE v1.0.2.\\ Dół - nakładka ARM SCOPE v1.0.1

3.2 BeagleBone i Cubieboard

Na rynku istnieje wiele tanich i kompaktowych rozwiązań mogących realizować funkcjonalność komputera lub urządzenia M2M. Ponadto dla niektórych rozwiązań istnieje bogaty system nakładek (zwanymi również jako 'Cape', 'Shield' lub 'Mezzanine Card') i gotowych projektów (w tym otwartych). Wartymi wzmianki są takie platformy jak:

- Arduino [5] wraz z nakładkami,

- BeagleBoard [6] wraz z zarejestrowanymi projektami [7],

- BeagleBone wraz z nakładkami [8],

- Rodzina ARMPUTER'ów firmy CTI - w tym CTI-VMAX, C3 [9] i inne,

- Cubieboard (który jest stosunkowo nowy) wraz z trwającymi pracami rozbudowy [10],

- Raspberry Pi [11] wraz z trwającymi pracami rozbudowy [12].

Do projektu MMS zostały wybrane platformy:

- BeagleBone:

- ze względu na nowoczesny i tani i szybki procesor ARM A8 - AM3359 [13],

- Cubieboard:

- ze względu na procesor ARM A8 [14] zintegrowany z jednostkami GPU i VPU (codec) oraz posiadający sprzętową obsługę interfejsu SATA, pozwalając tworzyć aplikacje typowe dla komputera PC.

W celu przystosowania platform BeagleBone oraz Cubieboard do zadań stawianym przed MMS:

- Zostały opracowane płyty nakładkowe (Rys 3.4 - Rys 3.9),

- Zostały zakupione adaptery USB-WIFI oraz USB-Bluetooth 4.0,

- Zostały opracowany HDL do obsługi nakładek ARM SCOPE v1.0.1 oraz ARM SCOPE v1.0.1 (Rozdział 3.4).

Rys 3.4 3D płyty 'przejściówki' dla BealgeBone - widok z góry

Rys 3.5 3D płyty 'przejściówki' dla BealgeBone - widok z dołu

Rys 3.7 3D płyty 'przejściówki' dla Cubieboard - widok z góry

Rys 3.8 3D płyty 'przejściówki' dla Cubieboard - widok z góry

Rys 3.9 Płyty przed montażem. Lewa strona - BeagleBone Cape. Prawa strona - Cubieboard Cape

Płyty zostały zmontowane (Rys. 3.10 - Rys 3.11) i przetestowane elektrycznie w docelowym systemie.

Rys 3.10 Płyty po montażu widok z góry. Prawy górny róg - BegaleBone cape wraz z zainstalowaną nakładką ADC SCOPE v1.0.1. Lewy górny róg - BeagleBone wraz z BeagleBone Cape - stanowiącą przejściówkę z BeagleBone na nakładki CTI-VMAX. Dół obie strony Cubieboard Cape - stanowiącego przejściówkę z Cubieboard na nakładki CTI-VMAX

Rys 3.11 Płyty po montażu widok z boku.

3.3 HDL

W ramach projeku MMS zostały opracowane, połączone i przetestowane bloki HDL:

- do przekazywania danych (obsługi interfejsu) pomiędzy płytą Cubieboard a płytami nakładkowymi CTI-VMAX a oparty o równoległy interfejs kamery (a w przyszłości o interfejs SD3 - Secure Digital Multimedia Card [15]) ,

- do przekazywania danych (obsługi interfejsu) pomiędzy płytą BeagleBone lub CTI-VMAX a płytami nakładkowymi CTI-VMAX a oparty o synchroniczny lub asynchroniczny intefesj NAND/NOR Flash,

- do obsługi przetworników na płycie ARM SCOPE v1.0.1 i buforowania danych z wykorzystaniem SDRAM,

- do obsługi przetworników na płycie ARM SCOPE v1.0.2 i buforowania danych z wykorzystaniem SDRAM,

Wymiana danych pomiędzy blokiem obsługi interfejsu a blokiem obsługi bufora danych z prztworników (kontrolera SDRAM) została oparata o popularny sposób połączeń wewnątrz-systemowych Wishbone [16]. Na rsunku 3.12 została zaprezentowana ogólna konfiguracja bloków.

Rys 3.12 Konfiguracja bloków HDL. Żółty - interfesjy. Niebieski - kontrolery. Zielony - fizyczne elementy

Sposób działania jest następujący:

- Kontroler interfejsu równoległego przetworników pobiera dane z przetworników w sposób ciągły,

- Dane buforowane są w SDRAM'ie wykorzystując dostępne porty (z arbitrażem - czym m.in. zajmuje się kontroler SDRAM),

- Kontroler interfejsu (kamery lub NOR/NAND Flash) odczytuje dane komunikując się z kontrolerem SDRAM i wysyła je do płyty matki na jej żądanie lub w sposób ciągły (ze zredukowaną przepustowością),

- Żądanie płyty matki jest przekierowaniem żądania użytkownika - płyty matka pośredniczy wymianie danych (i może ale nie musi dokonywać na nich dodatkowych obliczeń/działań w zależności od docelowej aplikacji np. kompresja danych przed wysłaniem na smartphone użytkownika).

3.4 Podsumowanie hardware

Zostały opracowane, stworzone i przetestowane rozwiązania oparte o nowoczesne platformy sprzętowe. Stworzono minimalną bazę sprzętową dla dalszego rozwoju oprogramowania oraz HDL. W dalszych pracach planuje się (o ile fundusze na to by pozwoliły) opracowanie rozwiązań opartych o inne wymieniane platformy. Dałoby to szansę na stworzenie większej bazy rozwiązań sprzętowych oraz zapoznanie (studentów) z nowoczesnymi, tanimi i względnie wydajnymi rozwiązaniami sprzętowymi. Ponadto został opracowany projekt (nie zrealizowany ze względu na duże koszta produkcji i montażu) komputera przemysłowego ARMPUTER-V3 wzorowanego na CTI-VMAX i będącego jego następcą.

--------------------
1. http://www.creotech.pl/pl/oferta/systemy-m2m/cti-arm-vmax
2. http://beagleboard.org/bone
3. http://cubieboard.org/
4. https://www.altera.com/download/software/quartus-ii-we
5. http://www.arduino.cc/
6. http://beagleboard.org/hardware
7. http://beagleboard.org/project
8. http://circuitco.com/support/index.php?title=BeagleBone_Capes
9. http://www.creotech.pl/pl/oferta/systemy-m2m/cti-arm-c3
10. https://groups.google.com/forum/#!categories/cubieboard/add-ons
11. http://www.raspberrypi.org/
12. http://www.raspberrypi.org/phpBB3/viewforum.php?f=15
15. http://www.ti.com/product/am3359
14. http://linux-sunxi.org/A10
15. https://www.sdcard.org/home/
16. http://opencores.org/opencores,wishbone

4. Software

4.1. Klient interfejsu MMS na platformę iOS (iPhone/iPod Touch/iPad)

Wersja klienta na platformę iOS powstawała jako pierwsza i była wzorem na późniejszych implementacji na inne platformy. Aplikacja napisana została w natywnym dla tej platformy języku programowania czyli Objective-C [1], który jest nadzbiorem języka C zapewniając tym samym zarówno szybkość działania jak i dynamiczną obiektowość przyspieszającą pracę na kodem.

4.1.1 Interfejs użytkownika

Interfejs użytkownika składa się z trzech zasadniczych ekranów:

1. Ekranu wyboru urządzenia pomiarowego (Rys 4.1-lewy),

2. Ekranu ze szczegółami danego urządzania z listą dostępnych czujników i ich parametrów (Rys 4.1-środek),

3. Ekranu z wyświetlaniem pomiarów (4.1-prawy).

Rys 4.1 Interfejs użytkownika aplikacji iOS

Każdy z ekranów jest dynamicznie generowany na podstawie danych odebranych z warstwy sieciowej

Ekran lewy pokazuje wszystkie urządzenia znalezione w aktywnej sieci Wi-Fi które współpracują z protokołem MMS (odnalezione przy pomocy protokołu SSDP [2]. Aby uruchomić wyszukiwanie urządzeń należy wykonać gest na urządzeniu tzw. pull-to-refresh. W każdej komórce listy wyświetlona jest nazwa urządzania pobrana z jego konfiguracji oraz jego adres (IP przy sieci LAN i UUID przy sieciach Bluetooth). Dane do wyświetlenia listy pobierane są z bazy danych na urządzeniu obsługiwanej przy użyciu frameworku Core Data.

Ekran środkowy zostaje wyświetlony po wybraniu urządzenia z listy na ekranie lewym. Zawiera on listę aktywnych czujników podłączonych do danego urządzenia wraz z ich parametreami. Niektóre z nich są edytowalne (wyzwalania, częstotliwość próbkowania i wysyłania danych), innych zaś (nazwa, identifikator) nie można zmienić z poziomu aplikacji iOS.

Każda zmiana edytowalnego parametru zapisywana jest w bazie danych na urządzeniu i jeśli użytkownik zdecyduje się na uruchomienie pomiarów, wysyłana jest zgodnie z protokołem MMS do urządzenia, które po zaakceptowaniu (lub nie) nowych parametrów odsyła strukturę danych z polem oznaczającym status operacji ustawienia parametrów. W przypadku sukcesu następuje rozpoczęcie pomiarów zgodnie z nowymi parametrami. Jeśli urzędzenie nie może ustawić żądanych parametrów czujnika, zwracany jest kod błędu z krótkim opisem, który zostaje wyświetlony użytkownkowi.

Ekran prawy zostaje wyświetlony jeśli ustawienie parametrów z poprzedniego kroku zakończone zostanie sukcesem. W takim przypadku wygenerowana zostanie przewijana lista domyślinych wizualizacji wyników danych

4.2. Android client

Aplikacja na system Android została napisana w języku Java. Przy budowie oprogramowania wykorzystano środowisko Android SDK dostarczające dedykowane biblioteki oraz narzędzia deweloperskie [3]. W celu zapewnienia jak największej kompatybilności między zaprojektowaną aplikacją a urządzeniami mobilnymi z systemem operacyjnym Android, zastosowano wersję biblioteki 2.2 (API 8) [4]. Obsługiwane są bezprzewodowe połączenia sieciowe Wifi oraz Bluetooth między użytkownikiem systemu a modułami pomiarowymi.

4.2.1. Android client

Aplikacja posiada interfejs użytkownika zbudowany z następujących ekranów:

1. Ekran główny – lista dostępnych urządzeń pomiarowych, z możliwością uruchomienia skanowania sieci (wyszukiwanie dostępnych urządzeń pomiarowych)

2. Ekran urządzenia pomiarowego – wyświetla szczegółowe informacje o urządzeniu pomiarowym.

Ekrany są generowane dynamicznie na podstawie danych przychodzących od dostępnych urządzeń pomiarowych. Komunikacja odbywa się w standardzie MMS z wykorzystaniem plików JSON.

Po uruchomieniu aplikacji wyświetlany jest ekran główny z dostępnym przyciskiem Search Devices. Gdy użytkownik naciśnie przycisk, rozpoczęte jest wyszukiwanie urządzeń pomiarowych zgodnych ze standardem MMS dostępnych w sieci. Wyszukiwanie dotyczy:

1. Urządzeń dostępnych w sieci Ethernet, np. poprzez Wifi – w tym przypadku rozsyłane są pakiety zgodne z protokołem SSDP. Jeśli urządzenie jest zgodne odpowiada odpowiednim pakietem zwrotnym

2. Urządzeń dostępnych w sieci Bluetooth – w tym przypadku wykrywane są wszystkie dostępne urządzenia. Wyszukiwanie jest realizowane, jeśli aktywny jest interfejs Bluetooth w urządzeniu klienta.

Po zakończeniu wyszukiwania wyświetlana jest lista dostępnych w sieci urządzeń. W przypadku urządzeń pomiarowych dostępnych w sieci Ethernet, wyświetlane są informacje o:

1. Nazwie urządzenia

2. Adresie IP

3. Rodzaju połączenia (Wifi)

W przypadku urządzeń Bluetooth wyświetlania informacja o:

1. Nazwie urządzenia

2. Adresie urządzenia (tzw. hardware address)

3. Rodzaju połączenia (Bluetooth)

Dodatkowo, wyświetlane są informacje o statusie skanowania sieci oraz wykrywanych urządzeniach. Na rysunku 4.2 przedstawiono przykładowy ekran główny aplikacji klienta.

Rys 4.2 Uruchomienie aplikacji ELHEP-MMS oraz rozpoczęcie skanowania (przycisk Search Devices)

Wszystkie urządzenia znajdujące się na liście na ekranie głównym są zgodne z protokołem MMS w przypadku sieci Wifi.
W przypadku wyszukiwania urządzeń Bluetooth wyświetlane są wszystkie dostępne w sieci urządzenia. Użytkownik musi wybrać jedno z nich i spróbować nawiązać połączenie. Jeśli połączenie zostanie nawiązane pomyślnie, urządzenie Bluetooth jest zgodne z protokołem MMS.

Na rysunku 4.3 przedstawiono listę dostępnych urządzeń po zakończeniu skanowania sieci.

Rys 4.3 Lista dostępnych urządzeń w standardzie MMS po zakończeniu skanowania sieci

Po wybraniu urządzenia z listy (z ekranu pierwszego), wyświetlane są szczegółowe informacje o urządzeniu pomiarowym. Prócz nazwy czujnika oraz jego adresu, dane opisują dostępne czujniki pomiarowe. Użytkownik ma możliwość ustawienia niektórych parametrów modułu, takich jak np.:

1. Wyzwalanie

2. Częstotliwość próbkowania

Ekran (ekran drugi) jest konstruowany dynamicznie, na bazie przesłanego przez urządzenie pomiarowe pliku JSON. Po naciśnięciu przycisku Send configuration, konfiguracja nastawiona przez użytkownika przesyłana jest do urządzenia pomiarowego.

W przypadku urządzenia Bluetooth użytkownik najpierw musi nacisnąć przycisk Connect by Bluetooth<.i>. Jeśli połączenie zostanie pomyślnie ustanowione, wyświetlony zostanie ekran taki sam, jak w przypadku urządzeń Wifi. Po skonfigurowaniu urządzenia, dane mogą zostać przesłane poprzez przycisk Send Configuration.

Na rysunku 4.4 przedstawiono przykładowy ekran urządzenia pomiarowego (ekran drugi).

Rys 4.4 Przykładowy ekran konfiguracji urządzenia pomiarowego

Odczytane dane pomiarowe od urządzenia wyświetlane są w polu tekstowym, dostępnym na ekranie pierwszym.

4.2.2. Warstwa sieciowa

W przypadku komunikacji poprzez sieć Wifi, najpierw wysyłane są pakiety SSDP. Aplikacja następnie oczekuje następnie na pakiety zwrotne.

Wymiana danych realizowana jest na porcie o numerze 1900, przy użyciu transmisji danych UDP.
Jeśli urządzenie pomiarowe prześle pakiet zwrotny, nawiązywane jest połączenie z wykorzystaniem protokołu WebSockets. W tym celu zastosowano bibliotekę AutobahnAndroid [5] z niewielkimi modyfikacjami. Pliki JSON z informacjami o urządzeniach pomiarowych oraz konfiguracji przesyłane są poprzez ten protokół. Do transmisji danych przez WebSockets wykorzystywany jest port 7681 oraz podprotokół elhep-test.

Na rysunku 4.5 przedstawiono schemat obsługi komunikacji z urządzeniami pomiarowymi dostępnymi w sieci Wifi.

Rys 4.5 Algorytm obsługi komunikacji między aplikacją użytkownika a urządzeniami pomiarowymi poprzez połączenie Wifi

W przypadku połączenia Bluetooth obsługa połączenia realizowana jest poprzez funkcje dostępne bezpośrednio w bibliotece Android. Wykorzystywany jest standard RFCOMM. Urządzenia pomiarowe muszą udostępniać usługę Bluetooth o zgodnym z systemem MMS numerze UUID. Informacje o urządzeniu pomiarowym i dostępnych opcjach konfiguracyjnych czujników są zgodne ze standardem MMS i przesyłane przy pomocy plików JSON.

Na rysunku 4.6 przedstawiono schemat obsługi komunikacji z urządzeniami pomiarowymi dostępnymi w sieci Bluetooth.

Rys 4.6 Algorytm obsługi komunikacji między aplikacją użytkownika a urządzeniami pomiarowymi poprzez połączenie Bluetooth

4.2.4. Dodatkowe możliwości

Aplikację Android Client można również uruchomić na komputerze PC. W tym celu należy skorzystać z wirtualnej maszyny, np. poprzez oprogramowanie VirtualBox. Istnieje możliwość komunikacji poprzez następujące interfejsy:

1. Ethernet

2. Wifi

3. Bluetooth

4.2. Windows Phone client

Projekt został wykonany w środowisku Microsoft Visual Studio z wykorzystaniem emulatora Windows Phone Emulator 7.1.

W aplikacji do przechowywania danych lokalnych wykorzystano mechanizm Isolated Storage. W przestrzeni tej zapisywany jest egzemplarz klasy, który miał przechowywać aktualne dane pomiarowe przychodzące z serwera, zawierające dane na temat pomiarów i konfiguracji urządzenia pomiarowego, a także przechowywać dane na temat nowej konfiguracji ustawionej przez użytkownika.

Aplikacja w obecnej wersji wyświetla dane testowe zapisane w egzemplarzu klasy, służącej do przechowywania danych pomiarowych.

Rys 4.7 Uruchomienie aplikacji MMS

Rys 4.8 Odświeżenie listy dostępnych urządzeń

Rys 4.9 Wybór dostępnego urządzenia pomiarowego

Rys 4.10 Widok strony z parametrami pomiaru dla urządzenia Simens C234

Rys 4.11 Przycisk start powoduje wyświetlenie wartości zmierzonych przez urządzenie, oraz wyświetlenie aktualnej konfiguracji urządzenia pomiarowego

----------------
1. About Objective-C, http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/P...
2. Simple Service Discovery Protocol, http://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol
3. Android SDK, http://developer.android.com/sdk/index.html
4. Platform Versions, Current Distribution, http://developer.android.com/about/dashboards/index.html
5. Autobahn Android, http://autobahn.ws/android

5. Podsumowanie

Podczas prac nad projektem MMS udało się zaprojektować i zrealizować dużą cześć finalnego projektu. Zrealizowano wersje alpha software'u na kilka platform mobilinych i system desktopowy Linux. Przygotowano również platformę sprzętową którą będzie bardzo przydatna podczas prac rozwojowych nad systemem w następnych semestrach. Produkcja i zakup niezbędnych części sprzętowej nie byłby możliwy bez pomocy finansowej z tytułu przyznania Grantu Rektorskiego.