Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych...

86
Rok akademicki 2012/2013 Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Instytut Informatyki PRACA DYPLOMOWA MAGISTERSKA Marcin Lewandowski Sposoby komunikacji z systemami wbudowanymi czasu rzeczywistego Promotor mgr inż. Henryk Kowalski Ocena: …........................................ .................................................... Podpis Przewodniczącego Komisji Egzaminu Dyplomowego

Transcript of Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych...

Page 1: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

Rok akademicki 2012/2013

Politechnika Warszawska

Wydział Elektroniki i Technik Informacyjnych

Instytut Informatyki

PRACA DYPLOMOWA MAGISTERSKA

Marcin Lewandowski

Sposoby komunikacji z systemamiwbudowanymi czasu rzeczywistego

Promotor

mgr inż. Henryk Kowalski

Ocena: …........................................

…....................................................

Podpis Przewodniczącego

Komisji Egzaminu Dyplomowego

Page 2: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

Specjalność: Inżynieria Systemów Informatycznych

Data urodzenia: 12.01.1987

Data rozpoczęcia studiów: 20.02.2012

Życiorys

Urodziłem się 12 stycznia 1987 roku w rodzinnym Otwocku niedaleko Warszawy.

Uczęszczałem do szkoły podstawowej w latach 1994-2000, później w gimnazjum w latach

2000-2003. Następnie kształciłem się w Liceum Ogólnokształcącym im. K. I. Gałczyńskiego

w Otwocku w klasie o profilu matematyczno-fizyczny w latach 2003-2006, gdzie zdałem

egzamin dojrzałości. Tuż po tym, studiowałem stacjonarnie w latach 2006-2008 kierunek

„Architektura i urbanistyka” na Wydziale Architektury Politechniki Warszawskiej. Po

dwóch latach studiowania architektury, postanowiłem zmienić swoją ścieżkę kariery i 2

2008 roku rozpocząłem, również stacjonarnie kierunek „Informatyka” na Wydziale

Elektroniki i Technik Informacyjnych Politechniki Warszawskiej. W roku 2012 uzyskałem

tytuł inżyniera na tymże kierunku. W trakcie studiów podjąłem pracę w informatycznej

firmie LogicIT oraz w Instytucie Podstaw Problemów Techniki Polskiej Akademii Nauk. Na

co dzień, poza informatyką, interesuję się rysunkiem odręcznym, malarstwem oraz

kognitywistyką.

................................................

Podpis studenta

EGZAMIN DYPLOMOWY

Złożył egzamin dyplomowy w dniu ............................................................................20__ r.

z wynikiem ..............................................................................................................................

Ogólny wynik studiów: ...........................................................................................................

Dodatkowe wnioski i uwagi Komisji: .....................................................................................

..................................................................................................................................................

..................................................................................................................................................

2

Page 3: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

STRESZCZENIE

Tematem pracy jest zagadnienie komunikacji systemów komputerowych ze szczególnym uwzględnieniem systemów wbudowanych. W pracy omówiono współczesne interfejsy i protokoły komunikacyjne oraz problemy z nimi związane. Przedstawiono również zagadnienia związane z systemem operacyjnym GNU/Linux, kompresją danych oraz metodami dostępu zdalnego. Analiza i przegląd współczesnych możliwości służy do

opracowania systemu komunikacyjnego CREM. System CREM realizuje komunikację systemu wbudowanego z urządzeniem pomiarowym systemu FOSREM służącego do badania drgań otoczenia oraz z serwerem umieszczonym w „chmurze” obliczeniowej. Ponadto, opracowano dostęp dla użytkownika systemu poprzez graficzny interfejs użytkownika oraz tekstowy interfejs diagnostyczny. W tekście przedstawiono schemat

podziału systemu na moduły, opis poszczególnych modułów jak i sposoby realizacji określonych funkcjonalności. Dalsza część pracy zawiera analizę i opis uzyskanych rezultatów. Koniec pracy wieńczy podsumowanie wykonanej pracy.

Słowa kluczowe: System wbudowany, komunikacja, Linux, GUI

THE MEANS OF COMMUNICATION WITH A REAL-TIME EMBEDDED SYSTEMS

The main topic of this thesis is the issue of communication systems with particular

emphasis on embedded system. The paper discusses the modern interfaces and communcation protocols. I also presents issues related to the GNU/Linux operating system, data compression, and remote access methods. Analysis and overview of the current capabilities were used to develop a communication system CREM. The CREM

system provides communcation between embedded system, ambient motion measuring device and cloud-based computing server. In addition, an access to the system is provided via graphical user interface and textual diagnostic interface. The paper shows a schema of the modules of the CREM system, the description of these modules and how some specific functionalities were implemented. Futher part of thesis contains an analysis of

obtained results. Thesis is ended with summary of work that has been performed.

Key words: Embedded system, communication, Linux, GUI

3

Page 4: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

Spis treści 1 Wstęp .................................................................................................................................7

1.1 Słownik pojęć.............................................................................................................7

1.2 Założenia projektowe.................................................................................................8

1.3 Wstępne wybory projektowe......................................................................................9

2 Systemy sprzętowe i programowe....................................................................................10

2.1 System wbudowany..................................................................................................10

2.2 System czasu rzeczywistego.....................................................................................10

2.3 System operacyjny....................................................................................................11

2.3.1 Definicja............................................................................................................11

2.3.2 Funkcje..............................................................................................................11

2.3.3 Rodzaje, przykłady...........................................................................................12

2.3.4 GNU/Linux.......................................................................................................13

2.4 Maszyna wirtualna....................................................................................................14

2.5 Kompresja danych....................................................................................................15

2.6 Platformowa sprzętowa - MityDSP-L138................................................................15

2.6.1 Procesor OMAP-L138......................................................................................16

2.6.2 FPGA, peryferia................................................................................................17

2.6.3 Mapa pamięci....................................................................................................17

2.6.4 Sekwencja startowa...........................................................................................18

2.7 System FOSREM.....................................................................................................19

2.7.1 Ogólny opis.......................................................................................................19

2.7.2 Reprezentacja HEX...........................................................................................20

2.7.3 Obsługiwane komendy......................................................................................20

2.8 Interfejsy komunikacyjne.........................................................................................23

2.8.1 Pożądane cechy komunikacji............................................................................23

2.8.2 Interfejsy przewodowe......................................................................................24

2.8.3 Interfejsy bezprzewodowe................................................................................26

2.9 Dostęp zdalny...........................................................................................................29

2.9.1 Bezpieczeństwo ................................................................................................29

2.9.2 Protokoły...........................................................................................................29

2.9.3 Strona internetowa............................................................................................30

4

Page 5: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.9.4 Android.............................................................................................................34

2.9.5 VPN...................................................................................................................34

2.9.6 Udostępnianie plików.......................................................................................35

2.9.7 Chmura obliczeniowa.......................................................................................36

3 System CREM..................................................................................................................37

3.1 Platforma programowa.............................................................................................37

3.1.1 Dostosowanie GNU/Linux Angstrom...............................................................37

3.1.2 Użyte narzędzia programistyczne.....................................................................38

3.2 Struktura systemu CREM.........................................................................................38

3.2.1 CREM-server – Moduł serwera HTTP.............................................................39

3.2.2 CREM-www – Moduł interakcji z użytkownikiem..........................................41

3.2.3 CREM-sender – Moduł komunikacji z „chmurą”............................................44

3.2.4 CREM-comm – Moduł pośredniczący z urządzeniem pomiarowym...............45

3.2.5 CREM-debug – Moduł komunikacji w trybie diagnostycznym.......................46

3.2.6 CREM-sim – Moduł symulujący pracę urządzenia pomiarowego...................46

3.2.7 CREM-config – Moduł automatycznej konfiguracji........................................47

3.3 Sposoby konfiguracji i zastosowań bibliotek oraz narzędzi.....................................48

3.3.1 Konfiguracja serwera Apache...........................................................................48

3.3.2 Konfiguracja modułów PAM............................................................................49

3.3.3 Użycie języka Python.......................................................................................49

3.3.4 Stosowane rozszerzenia języka JavaScript.......................................................50

3.3.5 Konfiguracja pakietu OpenVPN.......................................................................51

3.3.6 Konfiguracja narzędzia Crond..........................................................................51

3.3.7 Konfiguracja narzędzia Ntpd............................................................................52

3.3.8 Konfiguracja narzędzia Gpsd............................................................................52

3.4 Istotne metody implementacji kodu.........................................................................52

3.4.1 Konwersje liczb w postaci HEX.......................................................................52

3.4.2 Pobieranie identyfikatora urządzenia................................................................54

3.4.3 Uwierzytelnianie użytkowników......................................................................55

3.4.4 Implementacja zapytań interfejsu graficznego.................................................56

3.4.5 Obsługa asynchronicznych zapytań..................................................................56

3.4.6 Obsługa HTML5 przez przeglądarkę Internet Explorer...................................57

5

Page 6: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.4.7 Inicjacja witryny internetowej..........................................................................57

4 Rezultaty...........................................................................................................................59

4.1 Realizacja wymagań.................................................................................................59

4.2 Napotkane trudności.................................................................................................59

4.3 Środowisko testowe..................................................................................................60

4.4 Weryfikacja systemu CREM....................................................................................62

4.5 Testy kompresji.........................................................................................................64

4.5.1 Konwersja z formatu hex do binarnego............................................................65

4.5.2 Porównanie aplikacji służących do kompresji..................................................66

4.5.3 Szczegółowa analiza kompresji 7z...................................................................66

4.6 Pomiary wykorzystywanych zasobów sprzętowych................................................70

4.7 Stopień wykorzystania łącza sieciowego..................................................................76

5 Podsumowanie..................................................................................................................77

Bibliografia...........................................................................................................................78

Dodatek A: Zawartość CD...................................................................................................82

Dodatek B: Spis ilustracji.....................................................................................................83

Dodatek C: Spis tabel...........................................................................................................84

Dodatek D: wykaz używanych skrótów i akronimów..........................................................85

6

Page 7: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

1 Wstęp

1 Wstęp

Systemy wbudowane są, w dzisiejszych czasach, niezwykle popularne i szeroko stosowane. Ze względu na powszechność ich zastosowania, coraz większe znaczenie ma również komunikacja z tymi systemami. Systemy wbudowane mogą być podstawowym narzędziem służącym do gromadzenia, przetwarzania oraz udostępniania danych. Z drugiej strony, istnieje tendencja, aby dokładną i czasochłonną analizę zgromadzonych danych dokonywać na maszynach, które posiadają większą o rząd wielkości ilość zasobów. Obecnie, takimi maszynami są elastyczne serwery w tzw. „chmurach” obliczeniowych. Kolejną tendencją jest dążenie do szeroko rozumianej mobilności. Pożądaną cechą systemów informatycznych jest dostęp do nich z dowolnego miejsca na Ziemi. Musi to być wykonywane bezpiecznie. Zarówno system wbudowany, jak i serwery w „chmurze” powinny zostać udostępnione użytkownikowi w przystępnej i przejrzystej formie. Dlatego niezwykle istotną sprawą jest zapewnienie bezpiecznej i wydajnej komunikacji między wszystkimi składowymi systemu informatycznego.

Celem pracy było opracowanie sposobu komunikacji, który zrealizuje kompleksowo komunikację z systemem wbudowanym FOSREM skonstruowanym na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej. Obejmowało to komunikację z urządzeniem pomiarowym, z „chmurą” obliczeniową, z symulatorem urządzenia pomiarowego oraz opracowanie interfejsu graficznego użytkownika.

Rozdział pierwszy stanowi wprowadzenie do tematu wraz ze wstępnymi założeniami projektowymi. W rozdziale drugim omówione zostały: zagadnienie systemu wbudowanego, wyjaśnienie pojęcia „bezpieczeństwo”, współczesne interfejsy komunikacyjne, protokoły komunikacyjne, zastosowana platforma MityDSP, system FOSREM (ze szczególnym uwzględnieniem komunikacji) oraz zagadnienia związane z dostępem zdalnym. W trzecim rozdziale opisano strukturę, poszczególne moduły opracowanego systemu CREM, który realizuje przyjęte założenia. Ponadto, omówione jest dostosowanie platformy programowej dla systemu wbudowanego, konfiguracja dodatkowych pakietów oraz bibliotek. Przestawione są również istotne fragmenty implementacji systemu CREM. W rozdziale czwartym znajduje się analiza wykonanych prac. Przedstawione są rezultaty dotyczące systemu CREM. Rozdział piąty stanowi podsumowanie rezultatów wykonanych prac. W umieszczonej bibliografii znajduje się wykaz pozycji zawierających dokładny opis poruszanych zagadnień i wykorzystanych zasobów. Na końcu pracy znajduje się lista używanych w pracy skrótów, spis zawartości dołączonej płyty CD oraz spisy tabel i ilustracji.

1.1 Słownik pojęć

W dokumencie wykorzystuje się dużo nazw technologii, nazw własnych systemów oraz sformułowań, które mają charakterystyczne znaczenie w tej pracy. Niezbędne jest wyjaśnienie wykorzystywanych sformułowań. Używane są:

7

Page 8: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

1.1 Słownik pojęć

system FOSREM – opracowany system do wykrywania subtelnych drgań otoczenia;

system CREM – opracowany i opisany w dokumencie komunikacyjny system, część systemu FOSREM;

urządzenie pomiarowe – część systemu FOSREM będąca odpowiedzialna bezpośrednio za pomiar interesujących wielkości fizycznych;

zestaw uruchomieniowy – fizyczna platforma MityDSP-L138: płyta procesorowa wraz z płytą deweloperską posiadającą szereg portów wejścia-wyjścia;

zdarzenie – wystąpienie charakterystycznego drgania otoczenia obserwowane przez system FOSREM i wymagające szczególnego zainteresowania.

Natomiast wykaz ogólnie używanych skrótów i akronimów znajduje się w: DodatekD: wykaz używanych skrótów i akronimów.

1.2 Założenia projektowe

W ramach pracy należało opracować system, będący w ścisłej współpracy z systemem FOSREM, spełniający następujące założenia:

• uruchomienie na docelowej platformie sprzętowej i programowej (system wbudowany);

• skuteczne komunikowanie się z urządzeniem pomiarowym systemu FOSREM;

• możliwość zdalnego dostępu do systemu przy użyciu zaprojektowanego interfejsu z różnymi poziomami uprawnień oraz nawigowanie interfejsu z użyciem technologii swipe1;

• możliwość dostępu do systemu w trybie diagnostycznym;

• bezpieczne wysyłanie danych konfiguracyjnych urządzenia do serwera znajdującego się w „chmurze”;

• bezpieczne wysyłanie informacji o wystąpieniu zdarzenia do serwera znajdujące się w „chmurze”;

• bezpieczne udostępnianie danych pomiarowych przy wystąpieniu określonego zdarzenia do serwera znajdującego się w „chmurze”;

• przechowywanie danych pomiarowych na pamięci masowej podłączonej do zestawu uruchomieniowego;

• synchronizacja, możliwie dokładna, czasu systemu;

• możliwość podłączenia w przyszłości zewnętrznego modułu zegara czasu rzeczywistego;

1 Technika interakcji w urządzeniach mobilnych wyposażonych w ekran dotykowy. Metoda polega na

dotknięciu palcem lub stylusem na ekran dotykowy, a następnie przesunięciu go.

8

Page 9: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

1.2 Założenia projektowe

• dodatkowa możliwość symulowania pracy urządzenia pomiarowego.

Ponadto, gotowy system powinien posiadać następujące cechy:

• łatwość i prostota przy korzystaniu z interfejsu użytkownika końcowego;

• przejrzysta prezentacja mierzonych wartości;

• wygodę konfiguracji i zmiany pracy aparatury pomiarowej.

Priorytet Wymagania

1 Komunikacja z urządzeniem pomiarowym

2 Wysyłanie danych konfiguracyjnych do serwera

3 Przechowywanie danych na urządzeniu

4 Udostępnienie danych dla serwera

5 Stworzenie symulatora urządzenia pomiarowego

6 Dostęp w trybie diagnostycznym

7 Wykorzystanie technologii swipe do nawigowania strony www, wygodne i proste GUI

8 Synchronizacja czasu na urządzeniu

9 Bezpieczeństwo komunikacji

Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM

Ze względu na mnogość wymagań odnośnie systemu CREM, można było ustalić ich priorytety, dzięki czemu łatwiejsze okazało się koncentrowanie na najważniejszych funkcjonalnościach. Tabela 1.1 przedstawia wymagane funkcjonalności oraz przypisane im priorytety (mniejsza wartość oznacza wyższy priorytet).

1.3 Wstępne wybory projektowe

Uwzględniając wszystkie wymagania do spełnienia, we wstępnych założeniach zdecydowano się na opracowanie, uruchomienie i/lub skonfigurowanie:

• komunikacji z modułem pomiarowym poprzez DSP (z użyciem DSPLink[1]);

• serwera HTTP służącego jako usługa internetowa (web service);

• strony WWW w technologii HTML5 oraz CSS3;

• odbiornika GPS do dokładnej synchronizacji czasu;

• dostępu do modułu pomiarowego w tekstowym trybie diagnostycznym.

Ponadto, tworzony system powinien być modułowy: jeśli jedna ze składowych przestaje nieoczekiwanie działać, pozostałe powinny, w ramach możliwości, dalej pełnić swoje funkcje.

9

Page 10: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2 Systemy sprzętowe i programowe

2 Systemy sprzętowe i programowe

W rozdziale omówione zostały zagadnienia związanych z opracowanym systemem CREM, których wyjaśnienie jest nieraz niezbędne do zrozumienia rozdziału 3. W rozdziale opisywane są zarówno możliwe systemy sprzętowe, jak i programowe. Mowa jest o protokołach, interfejsach komunikacyjnych, systemach operacyjnych (ze szczególnym uwzględnieniem GNU/Linux), opisie systemu FOSREM oraz metodach dostępu zdalnego.

2.1 System wbudowany

Znaczna część opisanej pracy jest związana właśnie z systemem wbudowanym. Z tego powodu, dobrze jest wiedzieć czym jest system wbudowany (embedded system). A przynajmniej wiedzieć, w jakim kontekście jest używane to wyrażenie w pracy.

Trudno o jednoznaczną definicję systemu wbudowanego. Jest to typowa sytuacja, gdy jednym określeniem chcemy objąć dosyć szeroki zakres rzeczy. Nawet przeszukując zasoby Internetu, możemy natrafić na co najmniej kilkanaście różniących się, mniej lub bardziej, między sobą definicji. Niektóre odnoszą się do cech i właściwości sprzętowych. Wtedy mowa jest o systemie komputerowym specjalnego przeznaczenia, przystosowany wyłącznie do realizacji określonego zadania, który jest jednocześnie elementem składowym do wbudowania w obsługiwany przez ten system sprzęt. Rozumiemy taki system wbudowany jako integralną część większego systemu. Inne definicje koncentrują się na samym oprogramowaniu, gdzie przymiotnik wbudowany odnosi się zazwyczaj do kodu programu, który jednoznacznie ustala funkcjonalność całego systemu, a użytkownik końcowy ma możliwość zmian jego konfiguracji w niewielkim i określonym przez programistę zakresie[2].

W dokumencie, systemem wbudowanym określone będą urządzenia wraz z odpowiednim oprogramowaniem przeznaczone do wyłącznie realizacji z góry określonego zadania (bądź szeregu zadań). Definicja, pomimo swojej nieprecyzyjności (pozwala zaliczyć do tej kategorii praktycznie każdy komputer poza komputerem klasy PC i laptopem jak np. aparat cyfrowy, telefon komórkowy, modem, odbiornik GPS) dobrze pasuje do zastosowania w pracy.

2.2 System czasu rzeczywistego

Ogólnie, system czasu rzeczywistego (real-time system) jest to system komputerowy, w którym obliczenia prowadzone są równolegle z przebiegiem zewnętrznego procesu. Mają na celu nadzorowanie, sterowanie lub reagowanie na zachodzące w tym procesie zdarzenia. System taki musi spełniać wymagania narzucone na czas wykonywania zadanych operacji. Wcale nie musi być szybki – istotne jest jedynie, aby jego działania spełniały narzucone ograniczenia czasie.[3]

10

Page 11: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.2 System czasu rzeczywistego

Systemy czasu rzeczywistego najczęściej buduje się w oparciu o komputery, jednak nie jest to konieczne – można tym pojęciem określić np. pneumatyczny regulator.

Systemy czasu rzeczywistego dzieli się na trzy rodzaje ze względu na terminowość wykonywanych zadań:

• systemy o ostrych ograniczeniach czasowych (hard real-time) – gdy przekroczenie terminu powoduje poważne, a nawet katastrofalne skutki I nie powinien być pod żadnym pozorem przekraczany,

• systemy o mocnych ograniczeniach czasowych (firm real-time) – gdy fakt przekroczenia terminu powoduje całkowitą nieprzydatność wypracowanego przez system wyniku,

• system o miękkich/łagodnych ograniczeniach czasowych (soft real-time) – gry przekroczenie pewnego czasu powoduje negatywne skutki tym poważniejsze, im bardziej ten czas został przekroczony.

Systemy czasu rzeczywistego stosuje się głównie w przemyśle, nadzorowania eksperymentów naukowych, lotnictwie, medycynie czy wojsku.

2.3 System operacyjny

Cały tworzony system CREM ma być pod kontrolą systemu operacyjnego. Rozdział opisuje, ze szczególnym uwzględnieniem GNU/Linux, te rodzaje oprogramowania.

2.3.1 Definicja

Podobnie jak w przypadku pojęcia system wbudowany, tak i termin system operacyjny nie ma jednoznacznej i niepodważalnej definicji. Sam system, w najprostszym, ujęci, pełni dwie podstawowe funkcje: dostarcza programiście abstrakcję sprzętu oraz odgrywa rolę menedżera zasobów (głównie sprzętowych). To, jak spostrzegamy i definiujemy system operacyjny, zależy przede wszystkim od funkcji, której przypisujemy większe znaczenie[4].

2.3.2 Funkcje

Menadżer zasobów – powstanie i rozwój systemów operacyjnych jest nierozerwalnie związany z chęcią jak najwydajniejszego wykorzystania zasobów komputera. Dynamiczny rozwój komputerów wymusił na producentach sprzętu i oprogramowania opracowanie kompletnych systemów operacyjnych, które pozwolą na maksymalne wykorzystanie jego mocy. Współcześnie produkowane mikrokontrolery i mikroprocesory kilkakrotnie przewyższają możliwościami obliczeniowymi nasze komputery osobiste sprzed kilkunastu lat. Przygotowanie złożonego oprogramowania dla takich układów (bez wykorzystania systemu operacyjnego) , które w pełni te możliwości wykorzysta, jest dla programisty, a

11

Page 12: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.3 System operacyjny

nawet grupy programistów wręcz niewykonalne. Co więcej, wykorzystanie systemów operacyjnych daje możliwości współdzielenia zasobów procesora wielordzeniowego (lub nawet wielu procesorów) pomiędzy kilka równolegle działających programów i użytkowników.

Abstrakcja sprzętu – system operacyjny dostarcza programiście oraz działającym w tym systemie programom wyłączenie pewien model zasobów sprzętowych. Nieważne, czy działa się na procesorach architektury x86 firmy Intel, czy architekturze ARM. Nieważne, czy aplikacja zapisuje dane na dysku HDD czy SSD. System operacyjny ukrywa różnice w sprzęcie i pozwala programiście aplikacji nie zajmować się dokumentacją każdego z urządzeń peryferyjnych. W systemie GNU/Linux, na przykład, każdy z układów peryferyjnych „widziany” jest przez użytkownika tego systemu jako plik, a całość obsługi wybranego układu sprowadza się do operacji otwarcia/odczytu/zapisu/zamknięcia pliku.

Niektóre systemy operacyjne posiadają dodatkowo szereg zintegrowanych aplikacji i bibliotek ułatwiających korzystanie ze sprzętu oraz wspomagające samą pracę przy komputerze. Przykładem takich aplikacji może być odtwarzacz multimedialny lub edytor tekstowy[4].

2.3.3 Rodzaje, przykłady

Istnieje wiele różnych systemów operacyjnych. Prawie każdy pełni podstawowe funkcje (wspominanie: menedżer zasobów oraz abstrakcja zasobów). Mimo to, istnieją niemałe różnice między systemami operacyjnymi. Tabela 2.1 przedstawia parę przykładów z cechami szczególnymi.

12

Page 13: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.3 System operacyjny

System operacyjny Przykład Cechy szczególne

Windows Windows 7

Professional 64-

bit

Najpopularniejszy na komputery klasy PC; wiele wydań

(3.11, XP, 7, 8, ...) oraz wersji (Home, Professional,

Business, ...)

UNIX Solaris 11.1 Szeroka rodzina systemów operacyjnych; zwykle

komercyjnych

OS X Mac OS X 10.8

Mountain Lion

Rodzina „uniksowych” systemów dedykowanych na

komputery Macintosh; silnie zorientowana na obsługę

myszą

GNU/Linux Ubuntu 12.04

Precise Pangolin

Rodzina systemów uniksowych korzystająca z jądra

Linux

QNX QNX Neutrino

RTOS Secure

Kernel

System operacyjny czasu rzeczywistego zaliczany do

klasy UNIX z mikrojądrem

Windows CE Windows

Embedded CE 6.0

System operacyjny czasu rzeczywistego firmy Microsoft

przeznaczony na urządzenia przenośne PDA i systemy

wbudowane

Chromium OS Chromium OS Otwarta wersja systemy Google Chrome OS; dostępne

aplikacje bazują głównie na usługach webowych firmy

Google

Android Android 4.2 Jelly

Bean

System operacyjny przeznaczony na urządzenia

mobilne, głównie tablety oraz urządzenia smartphone

DOS MS-DOS 6.22 System operacyjny z wierszem poleceń; jeden z

pierwszych na komputery klasy PCTab 2.1: Przykłady systemów operacyjnych

2.3.4 GNU/Linux

GNU/Linux (potocznie Linux) to szeroka rodzina „uniksopodobnych” systemów operacyjnych opartych na jądrze Linux. Został stworzony przez Linusa Torvaldsa oraz jego współpracowników.

2.3.4.1 Założenia, cechy szczególneOd samego początku (rok 1991), GNU/Linux jest wolnym i otwartym

oprogramowaniem. Jego kod źródłowy może być dowolnie wykorzystywany, modyfikowany i rozpowszechniany. Istnieje szeroka społeczność, która rozwija ten system. Cechami szczególnymi tego systemu operacyjnego to:

• bezpłatność,

13

Page 14: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.3 System operacyjny

• duża zgodność ze standardami ANSI oraz POSIX,

• wielozadaniowość,

• jądro monolityczne z obsługą modułów,

• wsparcie wielu platform sprzętowych (x86, x64, m68k, MIPS, SPARC, ARM, ...),

• wirtualny system plików,

• interfejs wiersza poleceń oraz wiele interfejsów graficznych (KDE, Gnome, …),

• uniwersalność,

• skalowalność,

• dostępna duża liczba narzędzi użytkowych i programistycznych,

• duże wsparcie społeczności użytkowników i programistów.

Dzięki tym wszystkim cechom (i nie tylko) system GNU/Linux jest używany w szerokiej gamie urządzeń (od małych systemów wbudowanych, przez komputery klasy PC, do ogromnych serwerów)[5].

2.3.4.2 DystrybucjeDystrybucja to termin oznaczający uniksowy, kompletny system operacyjny

zbudowany na bazie jądra Linux. W skład dystrybucji, oprócz samego jądra, wchodzą podstawowe programy i usługi takie, jak powłoka, skrypty startowe, narzędzia konfiguracyjne, a także często duży zestaw aplikacji użytkowych. W obrębie dystrybucji używana jest jednolita organizacja plików konfiguracyjnych oraz wspólny mechanizm instalowania nowych aplikacji. Istnieją setki dystrybucji GNU/Linux2. Dystrybucje można dzielić według różnych kryteriów:

• komercyjne lub niekomercyjne,

• grupa odbiorców,

• obsługiwane platformy sprzętowe,

• przeznaczenie,

• inne.

2.4 Maszyna wirtualna

Maszyną wirtualną nazywamy ogólnie środowisko uruchomieniowe programów (lub też systemów operacyjnych, a nawet kolejna maszyna wirtualna – w dalszej części tekstu wszystkie te elementy będą rozumiane jako programy), które kontroluje wszystkie odwołania uruchamianego programu bezpośrednio do sprzętu i zapewnia ich obsługę. Pozwala to na tworzenie środowiska, w którym programy zachowują się, jakby działały na

2 Patrz: http://futurist.se/gldt/

14

Page 15: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.4 Maszyna wirtualna

rzeczywistym sprzęcie.

Najpopularniejszymi, komercyjnymi programami zapewniającymi możliwość uruchomienia systemu operacyjnego na maszynie wirtualnej są:

• Vmware Workstation,

• VirtualBox,

• QEMU.

2.5 Kompresja danych

Ogólnie mówiąc, kompresja danych polega na zmianie sposobu przechowywania informacji w taki sposób, aby zmniejszyć ich redundancję i tym samem objętość. W przypadku systemów komputerowych mówi się zwykle o mniejszej ilości bitów potrzebnych do przechowania informacji.

Istnieje wiele formatów oraz algorytmów kompresji danych. Najpopularniejszymi formatami kompresji bezstratnej (pozwalającej całkowicie odtworzyć pierwotną informację; w odróżnieniu od kompresji stratnej – używanej jest głównie w przypadku multimediów) są:

• ZIP – najpopularniejszy format kompresji, zwłaszcza na platformy Windows; stosunkowo szybki; pozwala na wykorzystanie algorytmów m.in.: Deflate (najczęściej wykorzystywany), DCL, Implode.

• RAR – format kompresji używający algorytmu LZSS; wolniejszy, ale skuteczniejszy od formatu ZIP.

• 7Z – rozprowadzany na zasadach licencji GNU LGPL; format stawia nacisk na wysoki stopień kompresji oraz możliwe silnie szyfrowanie, wykorzystuje algorytm LZMA.

• bzip2 – dostępny na licencji BSD, zwykle używany do kompresji archiwów TAR.

2.6 Platformowa sprzętowa - MityDSP-L138

Dynamiczny rozwój rynku systemów wbudowanych spowodował, że producenci mikroprocesorów oraz gotowych komputerów jednopłytowych opracowują coraz nowsze produkty w celu zaspokojenia nieustannie rosnącego zapotrzebowania na moc obliczeniową. Duża liczba dostępnych rozwiązań zarówno w zakresie gotowych komputerów przemysłowych, jak i płyt deweloperskich (będących platformą testową do przygotowania własnych rozwiązań – sprzętowych i programowych) umożliwia użytkownikom wybranie idealnego zestawu przystosowanego do własnych wymagań.

15

Page 16: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.6 Platformowa sprzętowa - MityDSP-L138

Jeszcze kilka lat temu, na arenie specjalizowanych komputerów jednopłytowych niepodzielnie rządziła architektura x86 (jej pozycja jest jeszcze dość silnie ugruntowana w dziedzinie komputerów przemysłowych, gdzie ostatnią rewolucją są procesory Intel Atom). W prostych układach kontrolno-pomiarowych przez długi czas prym wiodły (i w wybranych nadal wiodą) oszczędne 8-bitowe jednostki. Jednak od kil;ku lat przeżywamy prawdziwą ARM-ową rewolucję. Procesory z rdzeniem ARM na dobre zagościły nie tylko w prostych systemach wbudowanych, ale dzięki wysokiej wydajności i małemu poborowi mocy w mobilnych komputerach typu tablet, specjalistycznych komputerach jednopłytowych, multimedialnych telefonach.

Tym samym dostępnych jest coraz więcej gotowych zestawów ewaluacyjnych, umożliwiających szybkie zapoznanie się ze specyfiką wybranego układu i przygotowywanie własnych rozwiązań.

W przypadku pracy, użyty został zestaw uruchomieniowy MityDSP-L138F3 produkowany przez firmę Critical Link4. Według producenta, MityDSP-L138F[6] jest „wysoce konfigurowalną, mało gabarytowo kartą procesorową. Zapewnia pełną i elastyczną infrastrukturę do przetwarzania cyfrowego konieczną do najbardziej wymagających systemów wbudowanych”. Producent zapewnia również płytę deweloperską z wyprowadzonym szeregiem interfejsów sprzętowych (co pokazuje ilustracja 2.1).

2.6.1 Procesor OMAP-L138

Sercem modułu procesorowego jest dwurdzeniowy procesor OMAP-L138, na który składają się:

• Rdzeń MPU: ARM926EJ-S,

• Rdzeń DSP: TMS320C674x VLIW.

Obydwa pracujące z częstotliwością 456 MHz. Współdzielą ze sobą 256MB pamięci operacyjnej DDR2. W przypadku systemu FOSREM, największą zaletą jest właśnie połączenie rdzeni DSP i MPU, które pozwalają na jednoczesne wykonywanie obliczeń czasu rzeczywistego oraz obsługi zadań wyższego poziomu, takich jak komunikacja ze światem zewnętrznym. Na rdzeń MPU przewidziane są następujące systemy operacyjne:

3 Patrz: http://www.mitydsp.com/products-services/cpu-engines/mitydsp-l138/l138family/

4 Patrz: http://www.criticallink.com/

16

Ilustracja 2.1: Moduł procesorowy MityDSP-

L138F włożony do Industrial I/O Board

Page 17: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.6 Platformowa sprzętowa - MityDSP-L138

• Linux,

• QNX 6.4,

• Windows Embedded CE,

• ThreadX Real Time OS.

Na rdzeń DSP przewidziany jest jądro czasu rzeczywistego DSP/BIOS firmy Texas Instruments. Producent dostarcza gotowych obrazów systemów zarówno dla MPU jak I DSP.

2.6.2 FPGA, peryferia

Poza wspomnianym procesorem, MityDSP-L138F posiada układ Xilinx Spartan-6 FPGA. Układ ten posiada do 2088Kbit pamięci RAM i do 6822 elementów tzw. Slice.

MityDSP-L138F posiada również 512MB pamięci NAND Flash, 8MB NOR Flash oraz szereg wejść/wyjść. Między innymi:

• 96 portów I/O FPGA,

• port Ethernet,

• 2 porty UART,

• 2 porty USB,

• wyjście wideo D-SUB,

• wejście wideo/kamery,

• 2 interfejsy SPI,

• 2 interfejsy I2C,

• port na kartę MMC/SD,

• port SATA.

Schemat blokowy na ilustracji 2.2 przedstawia w uproszczony sposób najważniejsze elementy układu[7].

2.6.3 Mapa pamięci

Domyślny układ pamięci nieulotnej dla modułu MityDSP-L138F przedstawia ilustracja 2.3. Ilustracja nie pokazuje, możliwej do dołączenia, pamięci zewnętrznej: MMC Flash, Compact Flash, SATA, …)[7].

17

Ilustracja 2.2: Schemat blokowy MityDSP-L138F

Page 18: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.6 Platformowa sprzętowa - MityDSP-L138

2.6.4 Sekwencja startowa

Poniżej przedstawiona jest sekwencja startowa (ilustracja 2.4) przy uruchamianiu urządzenia i uruchamianiu systemu operacyjnego Linux. Po włączeniu zasilania lub resecie, wykonywany jest OMAPL138 ROM Bootloader. Bazując na stanie przełącznika znajdującego się na płytce, ładowany jest „bootskrypt” (bootscript) Texas Instruments AIS z pamięci SPI-NOR (domyślnie) lub przez interfejs UART. Domyślnie na pamięci NOR znajduje się ARM CPU User Boot Loader. Ładowany jest on do wewnętrznej pamięci rdzenia ARM.

Gdy zostanie załadowany UBL, bieżące wykonywanie przekazywane jest właśnie jemu. Program, przede wszystkim, ładuje u-Boot[8] z pamięci NOR podłączonej interfejsem SPI do pamięci operacyjnej. Poza tym, pozwala zmodyfikować pewne niskopoziomowe ustawienia CPU dotyczące m. in. układów PLL, konfigurację DDR, multipleksowanie niektórych pinów.

u-Boot to kolejna, trzecia faza startu. Wykonywana jest z zewnętrznej pamięci DDR2. Zadaniem u-Boot jest konfiguracja portów szeregowych, portu Ethernet, opcjonalnie interfejsu MMC i pozwolenie na niskopoziomowe uaktualnienie pamięci Flash przez użytkownika. u-Boot stworzony przez Critical Link pozwala również zaprogramować FPGA jeśli jest potrzebna już na tym etapie. Zwykle jednak programowanie to wykonuje się już po uruchomieniu jądra Linux.

Domyślnie, u-Boot pozwala na przerwanie dalszego działania (poprzez

18

Ilustracja 2.3: Domyślna mapa pamięci nieulotnej MityDSP-L138F

Ilustracja 2.4:

Sekwencja

startowa

MityDSP-

L138F

Page 19: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.6 Platformowa sprzętowa - MityDSP-L138

wysłanie dowolnego znaku przez konsolowy port UART) w ciągu 3 sekund. Jeśli użytkownik nie zareaguje w tym czasie, u-Boot załaduje do pamięci jądro Linux i uruchomi system operacyjny GNU/Linux. Miejsce obrazu jądra i obrazu głównego systemu plików jest możliwe do zdefiniowania przez użytkownika. Użytkownik może zdecydować się przechowywać te elementy w pamięci SPI-NOR (domyślnie dla obrazu jądra), NAND (domyślnie dla obrazu głównego systemu plików), dołączonej pamięci MMC, dysku SATA lub nawet przez serwer NFS. Ładowanie jądra i systemu głównego z pamięci USB jest możliwe, aczkolwiek nie przetestowane przez Critical Link.

Gdy zostanie uruchomiony system operacyjny, dostęp do szeregu pamięci nieulotnych jest wciąż możliwy. Aplikacje użytkownika na rdzeń ARM oraz DSP mogą zostać uruchomione przez skrypty startowe. Dodatkowo, układ FPGA może zostać zaprogramowany[7].

2.7 System FOSREM

W punkcie opisywany jest ogólnie system FOSREM opracowany na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej [9]. System ma za zadanie wykrywać i rejestrować drgania otoczenia. Dokonuje analizy poprzez pomiar zakłóceń nałożonych na generowaną sztucznie sinusoidę. Zbierane dane są poddawane analizie i przetworzeniu, po czym są udostępnianie na zewnątrz w sposób opisany w punkcie.

2.7.1 Ogólny opis

System FOSREM v1.0 składa się z kilku układów[9]:

1. Moduł pomiarowy (POM)

2. Moduł cyfrowy (DIGIT)

3. Moduł zasilania – baterii (BAT)

4. Moduł lasera (LAS)

5. Czujnik światłowodowy (FIBER)

Jednak z punktu widzenia opisywanych prac w dokumencie istotny jest tylko moduł cyfrowy, działający na wspomnianej w punkcie 2.6 platformie MityDSP. Na module cyfrowym uruchomiony jest system operacyjny GNU/Linux w dystrybucji Ångström[10]. Dystrybucja ta została wybrana ze względu na sprawdzone i dostarczone przez producenta gotowe obrazy systemu i narzędzia do jego edycji.

19

Page 20: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.7 System FOSREM

2.7.2 Reprezentacja HEX

Istotną kwestią jest sposób kodowania liczb przy transmisji z systemem FOSREM. Część komend i ich odpowiedzi przekazuje argumenty liczbowe zapisane w postaci decymalnej, najbardziej czytelnej dla człowieka. Jednak w celu ujednolicenia i stałego formatu danych, wprowadzono kodowanie liczb w postaci HEX (ilustracja 2.5). Każda liczba jest dzielona na grupy po 4 bity, i tym czwórkom przypisywane są cyfry heksadecymalne. Kodowanie może wystąpić zarówno dla liczb całkowitych, jak i zmiennoprzecinkowych. Również długości liczb są wielokrotnościami 8 bitów, więc nie pojawia się problem ze złą liczbą bitów, niepasującą do szerokości formatu HEX. Liczby zmiennoprzecinkowe są traktowane według standardu IEEE 754. Należy zauważyć, iż nie jest to po prostu liczba zapisana w szesnastkowej podstawie, ale heksadecymalna reprezentacja liczby zakodowanej według standardu. System FOSREM często korzysta z heksadecymalnej kodowania liczb, co pokaże dokładnie następny punkt.

2.7.3 Obsługiwane komendy

System FOSREM przyjmuje i realizuje szereg ustalonych komend. Można je podzielić na pewne grupy i szeregować chociażby alfabetycznie. W punkcie pokazano posegregowaną listę części komend systemu w wersji 1 oraz szczegółowe omówienie komunikacji z urządzeniem[11].

Komunikacja pomiędzy modułem pomiarowym (MP) i komunikacyjnym na GNU/Linux (MK) zachodzi poprzez dwukierunkowe łącza realizowane z wykorzystaniem biblioteki DSPLink[1]. Dostępne są dwa łącza:

• COMMUNICATION – służy do przesyłania poleceń z modułu MK do moduły MP oraz zwrotnie do przesyłania odpowiedzi,

• DATA - Służy do przesyłania danych wynikowych z modułu MK do moduły MP.

Każde dwukierunkowe łącze posiada dwa niezależne kanały komunikacyjne obsługujące jednokierunkową transmisję. Przesyłane dane mogą zawierać ciągi znakowe

20

Ilustracja 2.5: Przykład konwersji liczby na

dziesiętnej na heksadecymalny zapis liczby

zmiennoprzecinkowej pojedynczej precyzji

Page 21: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.7 System FOSREM

ASCII lub dane w postaci struktur.

Format komend i odpowiedzi jest z góry wyznaczony. Dla łącza COMMUNCATION każda komenda to jedna linia zakończona znakiem nowej linii. Pierwszy znak to '#', po którym występuje 1-3 literowa komenda, do której zwykle dodany jest parametr w postaci znaku równa się i wartości liczbowej. W przypadku niezakłóconej transmisji, po stronie odbiorczej komputera PC, najpierw zostanie zwrócona poprawnie rozpoznana komenda poprzedzona znakiem '*', następnie kolejne linie odpowiedzi urządzenia. Ostatnia linia zwykle zaczyna się znakiem '%', po którym następuje liczba oznaczająca, czy komenda została wykonana poprawnie (wartość 0), lub pojawiły się błędy związane z przetwarzaniem komendy (wartość różna od 0), jak np. błędny argument w poleceniu. W trakcie odpowiadania urządzenia FORS 3 na komendę, strona komputera PC powinna oczekiwać na zakończenie przetwarzania, czyli odebranie ostatniej linii '%0'.

W skrócie, schemat komunikacji z kanałem A jest następujący:

1. Moduł komunikacyjny wysyła komendę;

2. Moduł pomiarowy zwraca echo komendy;

3. Moduł pomiarowy zwraca komunikat (0, 1 lub więcej linii);

4. Moduł pomiarowy zwraca potwierdzenie zakończenia wykonywania ostatniego polecenia;

Moduł komunikacyjny po odebraniu ostatniej linii może wysłać kolejną komendę.

Tab 2.2: Polecenia grupy B

Grupa B: Ustawienia kodu częstotliwości filtru BRF1 i BRF2

Polecenie Parametry Opis

#Bn0=1 n=A,B,D Ustaw wartość domyślną częstotliwość (dla egzemplarza układu pomiarowego)A:filtr BRF1 B: filtr BRF2 D:dual filtr BRF1 i BRF2 (interpretacja jest taka sama w tej i kolejnych komórkach tabeli)

#Bn1=d n=A,B,D; d=1..65534 Zmniejsz częstotliwość o zadaną liczbę

#Bn2=d n=A,B,D; d=1..65534 Zwiększ częstotliwość o zadaną liczbę

#Bn3=d n=A,B,D; d=1..65534 Wpisz kod częstotliwości

#Bn4=d n=A,B,D; d=1..65534 Ustaw wartość domyślną skoku zmiany kodu częstotliwości

#Bn5=d n=A,B,D; d=1..65534 d=1000 Ustaw minimalną wartość kodu częstotliwości

#Bn6=d n=A,B,D; d=1..65534 d=65534 Ustaw maksymalną wartość kodu częstotliwości

#Bn7=d n=A,B,D; d=1..65534 d=65535 Wykonaj reset filtru. Ustaw wartość kodu częstotliwości na 32768.

Tab 2.3: Polecenia grupy C

Grupa C: Obsługa danych konfiguracyjnych

Polecenie Parametry Opis

#CC=1 - Kasowanie danych konfiguracyjnych

#CW=1 - Zapis danych konfiguracyjnych

#CR=1 - Odczyt danych konfiguracyjnych

21

Page 22: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.7 System FOSREM

Tab 2.4: Polecenia grupy H

Grupa H: Wybór kanałów przetwornika ADC

Polecenie Parametry Opis

#HA=x x=0,1,2 Wybór wejścia dla kanału A 0:INPUT=GROUND, 1: INP1/INN1=S1, 2: INP2/INN2=BRF1

#HB=x x=0,1,2 Wybór wejścia dla kanału A 0:INPUT=GROUND, 1: INP1/INN1=S1, 2: INP2/INN2=DCS1_REF

Tab 2.5: Polecenia grupy K

Grupa K: Współczynniki dla obliczeń Omega

Polecenie Parametry Opis

#KA=f f=hex(float32) Współczynnik k1

#KB=f f=hex(float32) Współczynnik k2

#KC=d d=0,1 Mnożnik Omega 0: ‘-‘, 1: ‘+’

Tab 2.6: Polecenia grupy Q

Grupa Q: Wykonywanie reset urządzenia

Polecenie Parametry Opis

#Qy=01234567 y=F,B Wykonaj RESET. Wymaga ponownego wysłania tej samej komendy. F: uruchomienie w trybie normalnym, B: w trybie interaktywnym

Tab 2.7: Polecenia grupy X

Grupa X: Wysyłanie aktualnych parametrów modułu pomiarowego

Polecenie Parametry Opis

#X=0 - Wyświetl znakowo wartości parametrów

#X=1 - Wyświetl komplet parametrów w postaci ciągu wartości kodowanych hex

#X=2 - Wyświetl wybrane parametry w postaci ciągu wartości kodowanych hex

Tab 2.8: Polecenia grupy Z

Grupa Z: Polecenia systemowe

Polecenie Parametry Opis

#Z0=1 - Zakończ pracę urządzenia

#Z1=tm tm=timemark Aktualizuj licznik czasu TimeMark

Nieco inaczej wygląda transmisja w kanale B. Na tym kanale, dane przesyłane są tylko od urządzenia. W zależności od trybu pracy (wyzwalanego poleceniem z grupy P) urządzenie wysyła tekstowo zestaw rekordów poprzedzonych znakiem '#' oznaczającym początek linii i składających się z szesnastkowo kodowanych cyfr jako znaki ASCII. Format wysyłanych danych poprzez łącze jest następujący:

wooooooooC,

gdzie 'w' oznacza znacznik wiarygodności ('0' oznacza dobrą próbkę, a inne wartości – błędy pomiarowe, które obecnie nie są zdefiniowane). 'oooooooo' to wartość próbki w formacie liczby zmiennoprzecinkowej o pojedynczej precyzji zakodowana szesnastkowo.

22

Page 23: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.7 System FOSREM

'C' natomiast to suma kontrolna tak, że suma wszystkich cyfr rekordu po operacji reszty z dzielenia przez 16 powinna dawać 0. Pomiędzy rekordami mogą występować dowolne znaki białe.

2.8 Interfejsy komunikacyjne

Projektanci urządzeń komputerowych mają do wyboru cały wachlarz możliwych interfejsów: zarówno przewodowych jak i bezprzewodowych. Programista niejednokrotnie musi zadecydować, którego interfejsu użyć w każdym indywidualnym przypadku. W przypadku systemów wbudowanych, twórca oprogramowania ma zwykle szereg gotowych do użycia interfejsów. Jednak i w takim przypadku decyzja której z dostępnych opcji użyć, musi zostać podjęta. Dlatego, w punkcie opisano, w niebywałym skrócie, wybrane interfejsy komunikacyjne.

2.8.1 Pożądane cechy komunikacji

Komunikacja jest jednym z podstawowych elementów systemów komputerowych. Słownik PWN określa komunikację jako (jedna z definicji):

„przepływ informacji między urządzeniami, np. telefonami lub komputerami”5.

W praktycznie każdym systemie komputerowym komunikacja możliwa jest dzięki istnieniu standardów przesyłania danych. Dwa urządzenia, aby wymieniać dane muszą mieć ustalony sposób komunikacji (zarówno na poziomie fizycznym, jak i logicznym). Jednym z najważniejszych zagadnień dotyczących takich sposobów jest model OSI[12], który definiuje strukturę komunikacji sieciowej, a przede wszystkim dzieli systemy sieciowe na 7, współpracujących ze sobą, warstw. Model ten traktowany jako wzorzec dla większości rodzin protokołów komunikacyjnych.

Każdy rodzaj komunikacji powinien posiadać pewne cechy, aby mógł być skutecznie używany. Poniżej podane są przykłady takich cech.

• Szybkość – jest to wprawdzie cecha ilościowa, a nie jakościowa, jednak w dobie coraz szybszych urządzeń elektronicznych, ten parametr ma spore znaczenie. Określa on z jaką szybkością przesyłane są dane. Wyrażany zwykle w bitach na sekundę i ich wielokrotnościach.

• Odporność na zakłócenia – dobra komunikacja to taka, która w jak najmniejszym stopniu jest zależna od czynników zewnętrznych (zakłóceń takich jak: warunki atmosferyczne, zakłócenia elektromagnetyczne).

• Bezpieczeństwo – dosyć szeroko rozumiana i nie zawsze wymagana cecha, jednak jeśli transmisja jest narażona na dostęp osób trzecich, zwykle bezpieczeństwo jest jednym z głównych aspektów na który zwraca się uwagę. Według niektórych definicji, odporność na awarię i zakłócenia również należą do cechy

5 Patrz: http://sjp.pwn.pl/slownik/2472911/

23

Page 24: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.8 Interfejsy komunikacyjne

bezpieczeństwa. Można mówić o:

◦ uwierzytelnianiu – (authentication) procesie weryfikacji tożsamości użytkowników,

◦ poufności – (confidentiality) ochronie informacji przed nieautoryzowanym jej ujawnieniem,

◦ integralności – (data integrity) inaczej nienaruszalność, ochronie informacji przed nieautoryzowanym jej zmodyfikowaniem (ew. detekcji takiej modyfikacji).

2.8.2 Interfejsy przewodowe

Transmisja przewodowa powstał dawno temu. Obecnie rozwinęło się wiele interfejsów i standardów transmisji przewodowej. Tabela 2.9 przedstawia porównanie najbardziej charakterystycznych cech wybranych metod komunikacji przewodowej[13].

Interfejs Typ Maks.

liczba

urządzeń

Maksymalny

dystans [ft]

Maksymalna

szybkość

Typowe

zastosowanie

RS-232 Asynchroniczny,

szeregowy

2 50-100 20kb/s Podstawowa

komunikacja

RS-485 Asynchroniczny,

szeregowy

32 4000 10Mb/s Przemysłowa

automatyka

Ethernet Szeregowy 1024 1600 10Gb/s Sieciowa

komunikacja

urządzeń PC

GPIB Równoległy 15 60 8Mb/s Systemy

pomiarowe

I2C Synchroniczny,

szeregowy

40 18 3,4Mb/s Mikrokontrolery

SPI Synchroniczny,

szeregowy

8 10 2,1Mb/s Mikrokontrolery

USB Asynchroniczny,

szeregowy

127 16 480Mb/s Peryferia PC

SATA Synchroniczny,

szeregowy

2 2 6Gb/s Pamięć masowa

Tab 2.9: Porównanie niektórych cech wybranych interfejsów transmisji przewodowej; podane

24

Page 25: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.8 Interfejsy komunikacyjne

wartości mogą się różnić w zależności od wersji interfejsu

2.8.2.1 RS-232Interfejs RS-232 jest odpowiedni w wielu różnorodnych zastosowaniach

wymagających prostej komunikacji między dwoma urządzeniami. Pomimo niedużej przepustowości (zwłaszcza w porównaniu z innymi interfejsami) oraz małej maksymalnej odległości między komunikującymi się urządzeniami jest często wykorzystywany. Podstawowymi zaletami tego rodzaju komunikacji jest:

• Możliwość transmisji każdego rodzaju danych.

• Warstwa fizyczna jest tania w realizacji i łatwo dostępna. W przypadku braku fizycznego interfejsu RS-232 w komputerze dostępne są konwertery USB/RS-232.

• Poza bitem startu, stopu i opcjonalnego bitu parzystości nie ma żadnych dodatkowych danych przesyłanych protokołem. Dla porównania, interfejsy USB i Ethernet wymagają dodatkowych nakładów sprzętu bądź implementacji.

• Połączenie (np. odpowiednie kable) są tanie.

• Wszystkie popularne systemy operacyjne zapewniają sterowniki i aplikacje do komunikacji poprzez RS-232. Języki programowania, z kolei, zapewniają klasy, biblioteki oraz inne narzędzia pomocne w komunikacji tym interfejsem.

Największymi wadami tego typu komunikacji jest prędkość i zasięg. Mowa jest o konieczności konwersji postaci szeregowej na równoległą (dostosowaną do magistral komputerowych), ale jest to zwykle wykonywane automatycznie przez sprzęt. Jeszcze jedną wadą jest fakt, że systemy operacyjne Windows nie zapewniają transmisji czasu rzeczywistego, co powodować może problemy z transmisją i utrata części danych[13].

2.8.2.2 EthernetEthernet jest to technika, w której zawarte są standardy wykorzystywane w budowie

głównie lokalnych sieci komputerowych (LAN). Obejmuje ona specyfikację przewodów oraz przesyłanych nimi sygnałów. Ethernet opisuje również format ramek i protokoły z dwóch najniższych warstw modelu OSI. Standard Ethernet został komercyjnie zaprezentowany w 1980 i ustandaryzowany w 1985 jako IEEE 802.3. Pomimo istnienia szeregu innych specyfikacji dedykowanych dla lokalnych sieci komputerowych: Token Ring, FDDI lub Arcnet, Ethernet jest obecnie najpopularniejszym standardem tego typu.

Sama transmisja opiera się na idei połączonych wspólnym medium węzłów wysyłających i odbierających ramki (frames). Każdy węzeł powinien posiadać niepowtarzalny adres MAC.

Standard Ethernet nie jest monolityczny. Tzn. standard nie definicje jedynego i słusznego sposobu komunikacji. Najpopularniejszy jest podział względem szybkości. Istnieją wersje o możliwości 10Mb/s (aczkolwiek są i jeszcze wolniejsze), 100Mb/s (tzw. Fast Ethernet), 1Gb/s (Gigabit Ethernet), 10Gb/s (10 Gigabit Ethernet), a nawet 100Gb/s (100 Gigabit Ethernet) zaakceptowany przez IEEE w 2010 roku. W ramach każdej z szybkości istnieje szereg typów przewidzianych kabli. Ponadto, przykładowo istnieją

25

Page 26: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.8 Interfejsy komunikacyjne

obecnie trzy standardy ramek.

2.8.2.3 USBInterfejs USB jest sprzętowym interfejsem ze zdefiniowanym protokołem

pozwalającym urządzeniu komputerowemu na komunikację z różnego rodzaju urządzeniami peryferyjnymi. Specyfikacja[14] jest głównym dokumentem definiującym interfejs. Na chwilę obecną istnieją trzy wersje interfejsu: 1 (Low Speed lub Full Speed), 2.0 (High Speed) i 3.0 (Super Speed). Różnią się one głównie prędkością przesyłanych danych.

Interfejs RS-232 nie zakłada nic o zawartości transferowanych danych. To komputer nadaje znaczenie przesyłanym bajtom. Interfejs USB natomiast jest inteligentnym interfejsem. Każda komunikacja USB zachodzi między gospodarzem (host) a urządzeniem (device). To gospodarz zarządza komunikacją na szynie, a urządzenie odpowiada.

Interfejs USB pozwala na zasilanie urządzenia napięciem 5V (maksymalnie 0.9A) i składa się jedynie z czterech przewodów. Jest często wykorzystywany po stronie komputera klasy PC do komunikacji z urządzeniami z interfejsami RS-232. Korzysta się wtedy ze specjalnych konwerterów.

2.8.3 Interfejsy bezprzewodowe

Tak jak istnieje wiele interfejsów przewodowych, ustandaryzowano również szereg interfejsów bezprzewodowych. Zamiast fizycznego medium transmisyjnego w postaci kabla, wykorzystywane są zwykle fale elektromagnetyczne. Przykładowe interfejsy to: WiFi, WiMAX, ZigBee, IrDA, Bluetooth, GPS, GPRS, LTE. Większość różni się, przede wszystkim, innym zakresem częstotliwości. Pociąga to za sobą, zwykle, różne szybkości transferu. Należy zauważyć, iż komunikacja bezprzewodowa jest bardziej narażona na wszelkiego rodzaju zakłócenia[15].

2.8.3.1 GSMZ początkiem lat 90-tych, GSM zapoczątkowało zmianę w sposobie komunikacji

między ludźmi. Wcześniejsze bezprzewodowe systemy pozwalały na komunikację jedynie między niewielką liczbą ludzi. GSM w 2010 roku był używany przez 3 miliardy ludzi. Taki postęp został uzyskany głównie przez ciągłe ulepszanie technologii i (tym samym) zmniejszenie kosztu infrastruktury i urządzeń dostępowych[15]. Dla porównania możliwych różnic w przepustowości, tabela 2.10 pokazuje szereg technologii telekomunikacyjnych.

26

Page 27: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.8 Interfejsy komunikacyjne

Nazwa technologii Prędkość transmisji

GSM 9,6 kb/s

GPRS 32-80 kb/s

EDGE 144 kb/s – 2 Mb/s

HSDPA 0,9 – 14,4 Mb/s

HSPA+ do 56 Mb/s

LTE do 300 Mb/sTab 2.10: Transmisje bezprzewodowe wykorzystywane w telekomunikacji

Obecnie, sieć GSM to złożona system z wieloma usługami. W tym pakietowej transmisji danych, która pozwala na m. in. dostęp do Internetu. To właśnie ta cecha pozwala na komunikację z systemami wbudowanymi, do których nie mielibyśmy dostępu z użyciem pozostałych technik. Zarówno przewodowych, jak i bezprzewodowych (które mają zwykle krótszy zasięg). Operatorzy telekomunikacyjni pobierają, oczywiście, opłaty za taką transmisję. Co więcej, możliwość dostępu z np. komputera (podłączonego do Internetu) do urządzenia połączonego przez GSM do Internetu kosztuje znacznie więcej niż zwykły abonament.

2.8.3.2 IEEE 802.11 (WiFi)Podstawowymi elementami składowymi sieci bezprzewodowej 802.11 są punkty

dostępu oraz stacje klientów, w jakie najczęściej wyposażone są urządzenia przenośne. Norma zawiera informacje dotyczące protokołów warstwy fizycznej oraz warstwy sterowania dostępem do nośnika. WiFi jest to jeden z najpopularniejszych standardów sieci bezprzewodowych zapewniający transmisję do 54Mb/s (wersja b[16]) przy wykorzystaniu pasma częstotliwości 2.4GHz z 11 lub 13 kanałami[17]. Zakres częstotliwości fal radiowych wykorzystywany w 802.11 nie podlega koncesjonowaniu i dlatego można bez żadnych zezwoleń instalować sieci tego typu.

Sieci tego typu najczęściej są wykorzystywane do udostępniania internetu, w telefonii komórkowej, medycynie, produkcji, firmach i w edukacji. Elastyczność i mobilność spowodowały iż sieć bezprzewodowa stała się alternatywną do sieci kablowych. Bo w odróżnieniu do sieci kablowej nie potrzebne są kilometry kabli a to chyba jest najważniejsza cecha tej sieci. Sieć bezprzewodowa daje nam prostszy montaż bez wiercenia i układania kabli, zakupywaniu drogich krosownic, a co za tym idzie zmniejszenie kosztów. Sieci radiowe znalazły bardzo dobre zastosowanie w miejscach, gdzie często są przenoszone maszyny dzięki nim nie trzeba co chwile dociągać kabla w inne miejsce. W firmie pracownicy mogą odbierać i wysyłać pocztę, udostępniać pliki, bez względu na ich położenia. W produkcji pozwala połączyć halowe stacje robocze z innymi. W magazynach łączy komputery z czytnikami kodów kreskowych co pozwala na łatwy zbiór informacji o ilości przechowywanych towarów i ich szybką lokalizacje. Coraz większy sukces odnoszą tzw. Hot-Spot-y, które coraz częściej udostępniają darmowy dostęp do Internetu w miejscach publicznych takich jak lotniska, restauracje czy też w hotelach. Rozwój Wi-Fi powodują trzy czynniki: pasmo w którym pracuje nie wymaga licencji, niski koszt instalacji

27

Page 28: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.8 Interfejsy komunikacyjne

i rosnąca wciąż przepustowość[18].

2.8.3.3 802.15.1 (Bluetooth)Bluetooth („Niebieski ząb”) jest to standard wykreowany w specyfikacji 802.15.1.

Jest to technologia bezprzewodowego przesyłu sygnałów o niedużym zasięgu i małej mocy, zastępująca połączenia kablowe pomiędzy różnorodnymi urządzeniami elektronicznymi, takimi jak: komputer stacjonarny, komputer przenośny, komputer kieszonkowy, klawiatura, myszka, drukarka, skaner, telefon komórkowy i wiele innych.

Specyfikacja ta mówi o zasięgu komunikacji w przybliżeniu 10 m, ale buduje się także urządzenia z nadajnikami dużej mocy, w których uzyskany zasięg komunikacji dochodzi do 100 m, chociaż w praktyce w otwartej przestrzeni może on wynosić nawet do 200 m. Urządzenie elektroniczne, umożliwiające wykorzystanie tej technologii to adapter Bluetooth, korzystający z fal radiowych w paśmie częstotliwości ISM6 2,4 GHz.

W Bluetooth dane przesyłane są za pomocą jednej częstotliwości w bardzo krótkich odstępach czasu (co 625 µs), a następnie częstotliwość jest zmieniana i przesyłana jest kolejna mała porcja danych. W odbiorniku dane są scalane w jedną całość i przesyłane do właściwego docelowego urządzenia elektronicznego. Do budowy sieci Bluetooth wykorzystywane jest maksymalnie osiem urządzeń (adresy urządzeń są zapisane na 3 bitach), z których jedno pełni rolę urządzenia nadrzędnego (master).

2.8.3.4 GPSGPS jest to jeden z systemów nawigacji satelitarnej obejmujący całą kulę ziemską.

Działanie polega na pomiarze czasu dotarcia sygnału radiowego z satelitów do odbiornika. Znając prędkość fali elektromagnetycznej oraz znając dokładny czas wysłania danego sygnału można obliczyć odległość odbiornika od satelitów. Sygnał GPS zawiera w sobie informację o układzie satelitów na niebie oraz informację o ich teoretycznej drodze oraz odchyleń od niej. Odbiornik GPS w pierwszej fazie aktualizuje te informacje w swojej pamięci oraz wykorzystuje w dalszej części do ustalenia swojej odległości od poszczególnych satelitów, dla których odbiornik jest w zasięgu. Wykonując przestrzenne liniowe wcięcie wstecz mikroprocesor odbiornika może obliczyć pozycję geograficzną (długość, szerokość geograficzną oraz wysokość elipsoidalną) i następnie podać ją w wybranym układzie odniesienia - standardowo jest to WGS 84, a także aktualny czas GPS z bardzo dużą dokładnością[19].

GPS zapewnia dwa poziomy dokładności: Dokładny Serwis Pozycyjny (PPS) oraz Standardowy Serwis Pozycyjny (SPS). PPS dostarcza informacji o pozycji z dokładnością nie gorszą niż 16 metrów (50%, 3D) i informacji o czasie z dokładnością nie gorszą niż 100 nanosekund (1 sigma) w stosunku do czasu UTC. PPS dostępny jest jedynie dla autoryzowanych użytkowników i przeznaczony głównie dla celów wojskowych. Standardowy serwis pozycyjny dostarcza informacji o pozycji z dokładnością nie gorszą niż 100 metrów (95%, 2D) w rozwiązaniach dwuwymiarowych i 156 metrów (95%, 3D) w rozwiązaniach trójwymiarowych. Dokładność informacji o czasie określona jest na nie

6 ISM – (Industrial, Scientific, Medical) nielicencjonowane pasmo radiowe do zastosowań przemysłowych,

naukowych i medycznych

28

Page 29: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.8 Interfejsy komunikacyjne

gorszą niż 337 nanosekund (95%) w stosunku do skali UTC. SPS przeznaczony jest głównie dla użytkowników cywilnych[20].

2.9 Dostęp zdalny

Obecnie, pracujemy nierzadko w środowiskach rozproszonych. Wygodnie jest, gdy do jakiegoś zasobu, komputera mamy dostęp z odległego miejsca, niezwiązanego fizycznie z miejscem, gdzie zasób lub komputer się znajduje. Dlatego już dawno łączono się na różnego rodzaju sposoby i opracowano szereg protokołów i standardów służących właśnie w tym celu. W punkcie opisane są wybrane protokoły, kwestię strony www w dostępie, sprawę urządzeń z systemem Android, tunel VPN, udostępnianie plików oraz kwestię „chmury”.

2.9.1 Bezpieczeństwo

Warto zauważyć, że dostęp zdalny powinien cechować się wysokim poziomem bezpieczeństwa. Poza cechami wymienionymi w punkcie 2.8 , należy zapewnić m. in.:

• identyfikację (identification),

• autoryzację (authorization),

• kontrolę dostępu (access control).

2.9.2 Protokoły

Wspomniane w punkcie 2.8 interfejsy nie zawsze zapewniają cechy bezpieczeństwa wymienione w punkcie 2.9.1 . Dlatego, w celu implementacji dostępu zdalnego, wykorzystuje się zwykle warstwy wyższe: aplikacji i prezentacji.

2.9.2.1 TelnetTelnet jest to standard protokołu komunikacyjnego używanego w sieciach

komputerowych do obsługi odległego terminala w architekturze klient-serwer. Komunikacja opiera się tylko o znaki alfanumeryczne[21].

Typowo, usługa Telnet korzysta z portu 23 w oparciu o TCP. Uwierzytelnienie polega na podaniu pary nazwy użytkownika i hasła zdefiniowanego na komputerze zdalnym. Sama transmisja nie jest szyfrowana.

2.9.2.2 SSLFirma Netscape Communications Corporation w latach 90. ubiegłego wieku

opracowała protokół SSL. Obecnie najpopularniejsza jest trzecia wersja protokołu, ponieważ wcześniejsze zawierały błędy.

Protokół SSL zapewnia następujące funkcje bezpieczeństwa:

29

Page 30: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.9 Dostęp zdalny

• uwierzytelnienie serwera, a niekiedy również klienta – czyli potwierdzenie ich autentyczności;

• poufność i integralność przesyłu – tzn. ochronę przed podsłuchem i modyfikacją.

Proces uwierzytelniania przebiega przy użyciu asymetrycznych algorytmów kryptograficznych. W związku z tym, każda ze stron musi posiadać swój własny klucz prywatny oraz publiczny. Po uwierzytelnieniu stron, wymiana danych następuje przy użyciu szybszych, symetrycznych algorytmów kryptograficznych.

Aby możliwe było potwierdzenie autentyczności strony biorącej udział w komunikacji, musi ona posiadać swój certyfikat podpisany przez zaufane centrum certyfikacji (CA)[22].

2.9.2.3 Tunele SSHTunelowanie to, najprościej mówiąc, technika pozwalająca na przesyłanie jednego

połączenia wewnątrz innego połączenia. Na przykład sesji HTTP wewnątrz tunelu SSL. SSH to metoda szyfrowania tunelu właśnie w oparciu i połączenie SSH w architekturze klient-serwer. Zwykle SSH używane jest do logowania na zdalne serwery. Pomimo tej najpopularniejszej funkcji, SSH pozwala na tworzenie szyfrowanych tuneli[22].

2.9.2.4 HTTP, HTTPSProtokół przesyłania dokumentów hipertekstowych (HTTP) został stworzony do

przesyłania żądań udostępniania dokumentów WWW oraz wysyłania formularzy. Zasada działania polega na wysłaniu do serwera HTTP żądania (zazwyczaj w postaci URL) i uzyskania na nie odpowiedzi (zwykle statusu odpowiedzi i samej treści). Najpopularniejszymi typami żądań są:

• GET – dostęp do zasobów;

• POST – stworzenie lub edycja nowych zasobów.

Protokół jest bezstanowy, co wprawdzie pozwala zmniejszyć obciążenie serwera, lecz jest kłopotliwe, gdy komunikacja powinna posiadać pewne cechy stanowości. Standardowo, HTTP korzysta z portu 80 w protokole TCP[23].

HTTPS natomiast to szyfrowana wersja protokołu HTTP. Do szyfrowania używa protokołu SSL, działa domyślnie na porcie 443 w protokole TCP. Oficjalną specyfikacja jest dostępna w sieci Internet[24].

2.9.3 Strona internetowa

Strona internetowa to dokument HTML udostępniony przez serwer WWW. Po stronie użytkownika jest zwykle otwierana i wyświetlana z użyciem przeglądarki internetowej. Obecnie strony internetowe stanowią nierozłączny element większości firm i przedsiębiorców. Pozwalają na udostępnianie treści w wygodny i znormalizowany sposób. W roku 2012 istniało prawie 650 milionów witryn internetowych[25]. Liczba ta wciąż rośnie.

30

Page 31: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.9 Dostęp zdalny

Strona internetowa, poza udostępnianiem treści w internecie, wykorzystywana jest również w systemach wbudowanych. Głównie jako usługa internetowa (ang. webservice). Pozwala na dostęp i kontrolę nad urządzeniem wbudowanym poprzez wygodny, zwykle atrakcyjny wizualnie, interfejs graficzny.

2.9.3.1 Serwer WWWDo działania strony internetowej, potrzebny jest serwer WWW. Jest to program

działający na serwerze (zazwyczaj internetowym) obsługujący żądania protokołu komunikacyjnego HTTP. Istnieje wiele tego rodzaju serwerów. Najpopularniejszymi są:

• Apache – najszerzej stosowany, otwarty, dostępny dla wielu systemów operacyjnych, często stosowany z interpreterem PHP oraz bazą danych MySQL, skalowalny, wykonano dla niego wiele modułów poszerzających funkcjonalność[26].

• Nginx – serwer zaprojektowany z myślą o wysokiej dostępności i silnie obciążonych serwisach z naciskiem na skalowalność i niską zajętość zasobów; posiada modularną budowę[27].

• Lighttpd – niezwykle lekki, serwer opensource; optymalizowany dla obsłużenia szybko wielu jednoczesnych połączeń[28].

2.9.3.2 HTML5Strony internetowe buduje się w oparciu o dokumenty HTML. HTML pozwala opisać

strukturę informacji zawartych wewnątrz dokumentu, nadając znaczenie poszczególnym fragmentom tekstu. Pozwala osadzać w tekście elementy multimedialne, dzielić treść na odrębne sekcje i formatować wygląd prezentowanych treści. W składni HTML wykorzystuje się pary znaczników umieszczone w nawiasach ostrokątnych. Należy zauważyć, że język znaczników HTML nie jest zaliczany do języków programowania – w jego składni nie przewidziano wyrażeń warunkowych, obliczeniowych lub iteracyjnych.

Powstało wiele standardów języka HTML (w tym XHTML w kilku wersjach). Najnowszy HTML5 stara się ujednolicić wszystkie różnice między standardami i pozwolić na uproszczenie tworzenia elementów dotychczas tworzonych ręcznie[29].

Przykładowy fragment języka strony internetowej w języku HTML wygląda następująco:1. <!doctype html>

2.

3. <html lang="pl" dir="ltr">

4.

5. <head>

6. <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

7. <title>Webpage title</title>

8. </head>

9.

10. <body>

11. <h1>First level header</h1>

31

Page 32: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.9 Dostęp zdalny

12. <p>Some text</p>

13. <!-- … -->

2.9.3.3 CSS3CSS, czyli kaskadowe arkusze stylów to język służący do opisu formy prezentacji (czyli

wyświetlania) stron WWW. Arkusz stylów CSS to lista reguł ustalających w jaki sposób ma zostać wyświetlony wybrany tzw. selektorem element (lub grupę elementów) HTML. Sposób wyświetlania określany jest właściwościami (takimi jak np. szerokość, kolor) i przypisanymi im wartościami (takimi jak np. 120 pikseli, czerwony)[30]. Obecnie najnowszy standard w wersji trzeciej to CSS3. Wprowadza on wiele nowych możliwości, jak np. elementy typu bitmapa (ang. canvas) lub płynne animacje[31]. Typowo, reguła CSS ma postać:14. selektor {

15. właściwość: wartość;

16. }

Możliwe jest też grupowanie wielu selektorów oraz właściwości:17. selektor1, selektor2 {

18. właściwość1: wartość1;

19. właściwość2: wartość2;

20. }

Znaki białe są zwykle pomijane, co pozwala formatować reguły CSS w dowolny sposób.

2.9.3.4 PHPJęzyk PHP jest powszechnie używanym uniwersalnym językiem skryptowym, który

jest szczególnie przystosowany do tworzenia aplikacji WWW w czasie rzeczywistym z możliwością zagnieżdżania w dokumentach HTML[32]. Język jest obiektowy, najczęściej stosowany do tworzenia skryptów po stronie serwera WWW, choć może być używany do przetwarzania danych z poziomu wiersza poleceń, a nawet pisania programów pracujący w trybie graficznym[33].

Składnia języka przypomina składnię języka C oraz Perl. Przykładowy skrypt PHP umieszczony w kodzie HTML wygląda następująco:21. <html>

22. <body>

23. <?php echo 'Hello World'; ?>

24. </body>

25. </html>

2.9.3.5 JavaScriptJęzyk PHP wykorzystywany po stronie serwera WWW (który to taki język obsługuje).

HTML pozwala również na osadzenie ciągów instrukcji skryptów w języku JavaScript. W przeciwieństwie do PHP, skrypty JavaScript wykonywane są zwykle po stronie klienta. Najczęściej służą do zapewnienia interaktywności poprzez reagowanie na zdarzenia,

32

Page 33: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.9 Dostęp zdalny

sprawdzenia poprawności formularzy lub budowania elementów nawigacyjnych. W języku JavaScript można również pisać pełnoprawne aplikacje[34]. Przykładowy fragment programu napisany w języku JavaScript wygląda następująco:26. function startTime() {

27. var today = new Date();

28. var h = today.getHours();

29. document.getElementById('txt').innerHTML = h + 'h';

30. t = setTimeout(function(){ startTime() }, 500);

31. }

Dzięki obydwu językom PHP i JavaScript możliwe jest tworzenie całkowicie dynamicznych stron internetowych, natychmiastowe (bez odwoływania się do serwera) reagowanie na interakcje użytkownika, budowanie stron w oparciu o stan serwera (np. przechowywane tam pliki) i ogólnie ułatwiają budowanie usług internetowych.

2.9.3.6 AJAXTechnologia AJAX polega na tym, że komunikacja z serwerem odbywa się z poziomu

kodu JavaScript (lub innego podobnego), a dane wymieniane są w postaci XML (najczęściej). Warto dodać, że cała komunikacja odbywa się asynchronicznie, co oznacza, że skrypt wysyła żądanie i czeka ja jego obsługę przez serwer, za to może w tym czasie wykonywać inne czynności. Witryna internetowa cały czas odpowiada na interakcje użytkownika. Gdy żądanie zostanie obsłużone i skrypt JavaScript dostanie odpowiedź zwrotną od serwera, zostanie o tym powiadomiony i będzie w stanie wykonać odpowiednie czynności. Do asynchronicznej komunikacji służy XMLHttpRequest.[33].

2.9.3.7 JSONJSON to lekki format wymiany danych komputerowych. Jest to format tekstowy,

będący podzbiorem języka JavaScript. Format został opisany w dokumencie RFC[35]. Pomimo swojej nazwy, JSON jest formatem niezależnym od konkretnego języka. Wiele języków posiada biblioteki ze wsparciem dla formatu JSON. Przykład treści w formacie JSON wygląda następująco:32. {

33. 'car': {

34. 'name': 'super',

35. 'price': 123000,

36. 'wheels': [

37. 'first': 'good',

38. 'second': 'bad'

39. ],

40. 'engine': 'ok'

41. }

42. }

Formatowanie i wcięcia zostały dodane w celu lepszej czytelności dla człowieka. Dane JSON przesyłane są bez znaków nowej linii i tabulacji. Podstawowymi zaletami formatu JSON w porównaniu do zwykłego tekstu (plain-text) są jego łatwiejszy odbiór przez człowieka[36] ze względu na swoją hierarchiczność.

33

Page 34: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.9 Dostęp zdalny

JSON nie jest jedynym tego typu formatem przesyłu danych. Zaletami formatu JSON w porównaniu do konkurencyjnego XML[37] są:

• brak tzw. tagów kończących (jak np. </car>);

• prawie zawsze mniejsza ilość danych przy przesyłaniu tych samych informacji;

• możliwość użycia tablic;

• brak zarezerwowanych słów;

• znacznie łatwiejsze przetwarzanie przy użyciu JavaScript.

2.9.4 Android

Android jest to system operacyjny dla urządzeń mobilnych takich jak telefony komórkowe czy urządzenia typu tablet[38]. Android opiera się na jądrze Linux oraz oprogramowaniu na wolnej licencji GNU. Ilustracja 2.6 przedstawia przykładowe urządzenia z systemem Android. Obecnie obserwuje się wciąż rosnącą popularność urządzeń właśnie z systemem Android. Liczebność urządzeń tego typu szacuje się na ponad 500 milionów[39].

Ich niebywała wygoda w użytkowaniu (w porównaniu do małych, „tradycyjnych” telefonów komórkowych) oraz przenośność (w porównaniu do laptopów, itp.) jest szeroko wykorzystywana. Jednym z takich zastosowań jest kontrola oraz manipulacja systemami wbudowanymi. Nie potrzeba wtedy dołączać bezpośrednio do systemu wbudowanego interfejsu użytkownika. Wystarczy interfejs komunikacyjny, np. Bluetooth lub dostęp do WWW. Użytkownik natomiast manipuluje i kontroluje system wbudowany poprzez interfejs graficzny który widzi i używa na urządzeniu z systemem Android.

2.9.5 VPN

Wirtualne sieci prywatne (VPN) to połączenia typu punkt-punkt przez sieć prywatną lub sieć publiczną, taką jak Internet. Klient sieci VPN używa specjalnych, opartych na protokole TCP/IP protokołów, nazywanych protokołami tunelowania, do wirtualnego wywoływania wirtualnego portu na serwerze sieci VPN. W typowej sieci VPN klient inicjuje przez Internet wirtualne połączenie typu punkt-punkt z serwerem dostępu zdalnego. Serwer dostępu zdalnego odpowiada na wywołanie, uwierzytelnia wywołującego i przesyła dane między klientem sieci VPN a prywatną siecią organizacji.

Aby umożliwić emulację łącza typu punkt-punkt, dane są hermetyzowane, czyli opatrywane nagłówkiem. Nagłówek zawiera informacje routingu, które umożliwiają

34

Ilustracja 2.6: Przykładowe urządzenia z

systemem Android

Page 35: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.9 Dostęp zdalny

przesyłanie danych przez sieć udostępnioną lub publiczną i dotarcie do punktu końcowego. Aby umożliwić emulację łącza prywatnego, wysyłane dane są szyfrowane w celu zachowania poufności. Pakiety przechwycone w sieci udostępnionej lub publicznej są nierozpoznawalne bez kluczy szyfrowania. Łącze, w którym prywatne dane są hermetyzowane i szyfrowane, jest nazywane połączeniem sieci VPN[40].

2.9.5.1 OpenVPNOpenVPN to działający w oparciu o protokół SSL program do zestawiania

wirtualnych sieci prywatnych. Jest to projekt założony przez Jamesa Yonana, obecnie bardzo silnie rozwijany przez grupę łudzi z całego świata. Program posiada szereg zalet, których często brak w innych implementacjach VPN. Spośród najważniejszych cech można wymienić takie, jak[22]:

• prosta instalacja i konfiguracja;

• działa w warstwie użytkownika;

• wykorzystuje dobrze znany i sprawdzony protokół SSL, + dostępny jest na licencji GPL w wersji 2;

• dostępny jest pod systemami Linux, *BSD, Windows 2000, XP i Vista, a także Windows Mobile;

• działa bezproblemowo w sieciach za NAT-em;

• jest stale i dynamicznie rozwijany.

2.9.6 Udostępnianie plików

Niejednokrotnie, w systemach informacyjnych potrzebna jest wymiana dużej ilości danych. Mogą to być np. dane pomiarowe jakiegoś zjawiska fizycznego, lub pliki filmowe. Dotychczasowo omawiane metody i protokoły są przeznaczone głównie do stosunkowo sporadycznego wysyłania danych. Lub przynajmniej niewielkich ilości danych. Dla celów masowo przesyłanych danych często używa się plików (pomijając kwestie strumieni np. multimedialnych). Odpowiednio przygotowane pliki przesyłane są ustalonym protokołem, takimi jak:

• FTP – protokół komunikacyjny typu klient-serwer umożliwiający transfer plików po protokole TCP, używa zwykle portów 20 i 21, nie zapewnia szyfrowania transmisji;

• SCP – „bezpieczne kopiowanie”, szyfrowany na podstawie protokołu SSH protokół zajmujący się transmisją plików, potrafi przekazać uprawnienia plików w przeciwieństwie do FTP;

• SSH-FS – (SSH Filesystem) klient systemu plików umożliwiający montowanie i operowanie na katalogach i plikach zlokalizowanych na zdalnym serwerze;

35

Page 36: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

2.9 Dostęp zdalny

• Dropbox – komercyjna usługa polegająca na udostepnieniu przestrzeni dyskowej na serwerze firmy świadczącej te usługi (Dropbox, Inc.), użytkownik może z wielu urządzeń połączyć się z przestrzenią dyskową i synchronizować jej stan ze swoim lokalnym systemem plików;

• Google Drive – usługa analogiczna do Dropbox, jednak udostępniająca większą ilość miejsca (bezpłatnie 15GB, płatnie do 16TB na konto).

2.9.7 Chmura obliczeniowa

Pojęcie chmury obliczeniowej jest, niestety, niejednoznaczne. W szerokim znaczeniu, przetwarzanie w chmurze jest wszystko to, co przetwarzane na zewnątrz zapory sieciowej. Zasada działania polega na przeniesieniu całej infrastruktury usługi IT na serwer i udostępnienie tych danych poprzez komputery klienckie. Zapewnia to potencjalnie większe bezpieczeństwo (niezależne od bezpieczeństwa komputera klienckiego). Również szybkość wykonywania procesów opiera się na mocy obliczeniowej serwera.

36

Page 37: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3 System CREM

3 System CREM

W ramach pracy został opracowany system CREM w niejednorodnych środowiskach programistycznych. Nazwa systemu pochodzi od nazwy FOSREM (Fiber Optic Seismograph for Rotational Event Monitoring). Ciąg liter „FOS” został zastąpiony literą 'C', przez co uzyskuje się nazwę Communication for Rotational Event Monitoring. W rozdziale opisana została architektura, podział na logiczne części, budowa poszczególnych modułów oraz sposoby realizacji określonych fragmentów opracowanego systemu.

3.1 Platforma programowa

Znaczna część systemu CREM jest uruchamiana na platformie sprzętowej MityDSP-L138. Dotyczy to obsługi modułu pomiarowego, przetwarzania otrzymywanych od niego danych oraz wysyłania danych do chmury obliczeniowej. Część systemu jednak jest uruchamiana na urządzeniach klienckich w formie witryny internetowej. Wykorzystana została architektura klient-serwer (tzw. cienki klient[41]). Ponadto, symulator urządzenia uruchamiany jest na wirtualnej maszynie (również w architekturze klient-serwer).

3.1.1 Dostosowanie GNU/Linux Angstrom

Na platformie MityDSP-L138 uruchomiony jest system operacyjny GNU/Linux w dystrybucji Ångström dostosowany do działania na docelowym urządzeniu wbudowanym. Na platformie udostępnione zostały niezbędne oraz pomocne narzędzia GNU, takie jak:

• bash – powłoka systemowa,

• wget – aplikacja do pobierania plików z internetu,

• gzip – aplikacja służąca do kompresji oraz dekompresji.

Ponadto, dodane zostały (również niezbędne i pomocne) pakiety[42] takie jak:

• PAM[43] - mechanizm integrujący niskopoziomowe techniki kryptograficzne w jednolite API wysokiego poziomu,

• apache[44] - serwer HTTP,

• PHP[45] wraz z dodatkowymi modułami – obiektowy język programowania stworzony do generowania stron,

• p7zip[46] - kompresor i dekompresor formatu 7Z na systemy typu POSIX,

• Python 2.7[47] - język programowania wysokiego poziomu,

• ntpd[48] - demon serwera czasu,

• gpsd[49] - demon GPS.

37

Page 38: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.1 Platforma programowa

3.1.2 Użyte narzędzia programistyczne

System CREM został napisany w szeregu językach programistycznych jak kompleksowe rozwiązanie obsługi interakcji użytkownika i komunikacji z urządzeniem pomiarowym. Wykorzystane języki to:

• C++,

• Python,

• PHP,

• JavaScript,

• Shell script.

Poza językami programowania[50], wykorzystano język znaczników HTML5 oraz kaskadowe arkusze stylów CSS3 do utworzenia dostępowej strony internetowej pozwalającej na konfigurację i podgląd pracy urządzenia w wygodny sposób.

3.2 Struktura systemu CREM

System CREM to złożony system, który został podzielony na szereg modułów. Jest on typowo uruchamiany na module cyfrowym[9] systemu FOSREM. Ilustracja 3.1 przedstawia uproszczony schemat współpracy modułów. W celu realizacji wymagań, utworzona została strona internetowa (CREM-www) z możliwością nadzorowania i konfiguracji pracy urządzenia pomiarowego. Strona serwowana jest z urządzenia wbudowanego i uruchamiana na zdalnym urządzeniu (komputer, tablet, itp.). Serwer HTTP (CREM-server) na systemie wbudowanym służy do obsługi zapytań wysyłanych przez stronę WWW. Moduł CREM-sender służy do komunikacji z „chmurą” obliczeniową jako pośrednik między nią a urządzeniem pomiarowym. Istnieje również moduł CREM-debug służący do interakcji z urządzeniem pomiarowym w trybie diagnostycznym.

38

Ilustracja 3.1: Schemat współpracy modułów systemu CREM z

wykorzystaniem docelowego systemu wbudowanego

Page 39: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.2 Struktura systemu CREM

Dodatkowo, całość spaja moduł CREM-config. Składa się na niego zbiór skryptów, które automatycznie dostosowują i konfigurują system operacyjny do pożądanych funkcjonalności. Dzięki niemu, nie trzeba każdorazowo, ręcznie konfigurować systemu.

Wymagany był jeszcze symulator urządzenia pomiarowego o nazwie CREM-sim. Do tego wykorzystano maszynę wirtualną, która pozwoliła emulować system operacyjny GNU/Linux w dystrybucji Ubuntu w wersji 12.04.2. Rzeczywisty sprzęt, na którym działa maszyna to, udostępniony w sieci, serwer z możliwością zdalnego dostępu. System ten pozwolił na uruchomienie wszystkich wspomnianych modułów i skuteczne symulowanie systemu FOSREM bez fizycznego urządzenia ani systemu. Schemat współpracy modułów w takim układzie przedstawia ilustracja 3.2.

3.2.1 CREM-server – Moduł serwera HTTP

Moduł serwera HTTP jest jednym z głównych elementów systemu CREM, gdyż odpowiada za serwowanie strony internetowej użytkownikowi końcowemu oraz przyjmowanie żądań AJAX od tejże strony. Komunikacja z systemem wbudowanym lub modułem CREM-sim opiera się na mechanizmie gniazd (socket). Jego działanie opiera się na otwartym serwerze HTTP Apache. Wybór ten został podyktowany:

• popularnością serwera – co implikuje spore wsparcie społeczności rozwijającej tę aplikację oraz użytkowników tworzących serwery w oparciu o Apache, konkurencyjny i wydajniejszy (pod względem chociażby maksymalnej ilości możliwych do obsłużenia połączeń) nginx[51] nie posiada takiego wsparcia, również serwer nie ma być poddawany dużemu obciążeniu, przewidywanych jest co najwyżej kilka jednoczesnych połączeń;

39

Ilustracja 3.2: Schemat współpracy modułów systemu CREM z

wykorzystaniem maszyny wirtualnej

Page 40: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.2 Struktura systemu CREM

• dużą możliwością konfiguracji – znacznie większą niż chociażby prosty i lekki Lighttpd;

• brakiem opłat za wykorzystanie go w swoim oprogramowaniu – oprogramowanie jest całkowicie darmowe;

• dużą ilością dodatków – chociażby duże wsparcie dla modułu PAM zapewniającego bezpieczeństwo (np. uwierzytelnienie);

• stosunkowo prostą konfiguracją – w celu skonfigurowania serwera, poza instalacją niezbędnych pakietów oraz dodatków, należy edytować dwa pliki tekstowe.

Kod serwera został zrealizowany w wielu plikach. Pozwala to na łatwiejszą i wygodniejszą modyfikację kodu oraz logiczne rozłożenie rozdzielnych funkcjonalności serwera. Główny plik index.php zawiera cały dokument HTML służący do prezentacji stanu urządzenia wraz z krótkim kodem PHP służącym wyłącznie do uwierzytelniania i autoryzacji. Konkretnie polega to na sprawdzeniu, czy użytkownik nawiązał i ma utrzymaną sesję z serwerem. Cała witryna została napisana w jednym pliku, aby łatwiej było zarządzać kodem HTML oraz aby nie wykonywać wielu niepotrzebnych zapytań o podstrony.

Jeśli uwierzytelnienie bądź autoryzacja się nie powiedzie (bądź też sesja nie została nawiązana lub wygasła), serwer HTTP serwuje część witryny służącej do logowania. Wraz z nią, wykonano również część odpowiadającą za poprawne usunięcie sesji (jeśli użytkownik zechce się wylogować) oraz zmianę hasła swojego konta. Operacje te są oparte o technologię PAM (dokładniejszy opis w punkcie 3.3.2).

Strona internetowa pozwala na dostęp dwóch użytkowników: admin oraz user. Pierwszy ma możliwość podejrzenia pracy urządzenia, zmianę jego konfiguracji. Konfiguracja dotyczy zarówno pracy systemu operacyjnego opracowanego systemu wbudowanego (jak np. wyłączenie komunikacji z użyciem technologi WiFi) jak i nastawę parametrów pracy urządzenia pomiarowego. Zwykły użytkownik (user) ma możliwość tylko podejrzenia pracy urządzenia.

Poza serwowaniem strony internetowej, do przyjmowania nadchodzących żądań od użytkownika (np. zmianę parametru pracy urządzenia pomiarowego) służą oddzielne skrypty PHP. Zostały one podzielone na:

• część obsługującą komendy użytkownika – z użyciem zapytania POST, ponieważ wszystkie komendy które przyjmuje urządzenie pomiarowe są w formie jednej linii tekstu, do przesłania treści komendy posłużono się query-string zawartym w URL;

• część odpowiedzialną za wyświetlanie na bieżąco danych pomiarowych – z użyciem zapytania GET zwracającego wartości liczbowe wartości mierzonych zarejestrowane w ciągu ostatniej sekundy, dane zwrotne wysyłane są w postaci JSON;

• część służącą do obsługi plików wysyłanych w celu reprogramowania kodu systemu wbudowanego – zapytanie typu POST w formularzu HTTP, za pomocą formularza

40

Page 41: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.2 Struktura systemu CREM

przesyłane są pliki binarne, możliwe jest wysłanie jednego zbiorczego pliku rootfs[52], bądź oddzielnych plików służących do reprogramowania oddzielnych części systemu wbudowanego (np. jądro Linux lub główny system plików).

Serwer posiada również dodatkowy plik utils.php w którym zawarte są funkcje wykorzystywane w wielu częściach serwera. Zapobiega to redundancji kodu oraz ułatwia jego modyfikację.

Serwer w przypadku komunikacji z modułem CREM-sim lub CREM-comm komunikuje się poprzez mechanizm gniazd. Typowo komunikacja przebiega tak, że otrzymywane jest zapytanie od modułu CREM-www. Zapytanie zawiera polecenie do urządzenia pomiarowego. Polecenie to zapisywane jest do gniazda, gdzie komunikacja wygląda jak opisana w punkcie 2.7.3. Kod serwera uwzględnia ustalone ograniczenia czasowe i jeśli nie otrzymuje oczekiwanej odpowiedzi (zwykle ostatniej linii odpowiedzi zaczynającej się znakiem '%') to kończy obsługiwanie danego zadania informując moduł CREM-www o zaistniałej sytuacji.

3.2.2 CREM-www – Moduł interakcji z użytkownikiem

Moduł CREM-www, jako odpowiedzialny za wizualną prezentację pracy urządzenia końcowemu użytkownikowi, został opracowany w oparciu o dokument HTML5. Za wygląd strony internetowej odpowiada CSS3, a logika aplikacyjna po stronie klienta oparta jest o JavaScript. Ilustracja 3.3 pokazuje ekran logowania tejże strony internetowej. Zawarte w punkcie widoki prezentują informacje z symulatora w przeglądarce Chrome na systemie Windows 8. Wersja strony to 2013-08-18.

41

Page 42: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.2 Struktura systemu CREM

Dokument HTML został podzielony logicznie na odrębne części z wykorzystaniem elementów języka HTML5 takich jak: nav lub header[53]. Nałożone kaskadowe arkusze stylów zawarte są w jednym pliku (oszczędność ilości zapytań do serwera) i odpowiadają za wygląd przycisków, formatowanie nagłówków i kolorystykę witryny. Mowa jest o autorskich arkuszach (pliki CSS do tzw. wtyczek (plugin) przechowywane są oddzielnie – tak jak dostarczają je twórcy wtyczek). Ilustracja 3.4 przedstawia przykładowy widok części konfiguracyjnej z nałożonymi stylami.

W przypadku wyświetlania przycisków np. na panelu nawigacyjnym widzianym po lewej na ilustracji 3.4 w arkuszach wykorzystano w dosyć sprytny sposób właściwość background-position. Służy ona do pozycjonowania obrazu graficznego w danym elemencie HTML. W elementach które użytkownik może kliknąć często wykorzystuje się stan elementu hover. Stan taki następuje przy najechaniu myszką na dany element i zwykle powoduje zmianę wizualną wyświetlanego elementu (np. zmianę koloru). Zwyczajowo dla np. przycisku tworzy się dwa pliki graficzne: jeden zwykły, a drugi podobny, ale w wersji hover. Powoduje to, że po najechaniu myszką na taki element pierwszy raz, jego prezentacja nie zmienia się natychmiastowo. Przeglądarka wysyła zapytanie o drugi plik i dopiero gdy go otrzyma zmieni wygląd elementu. Aby zlikwidować ten problem, tworzy się jeden plik graficzny, gdzie obrazki dotyczące elementu w zwykłym stanie i w stanie hover są obok siebie. Gdy użytkownik najedzie myszką na dany element, przeglądarka nie musi wysyłać zapytania o plik – wystarczy, że zmieni się wartość atrybutu background-position i zmiana prezentacji będzie natychmiastowa.

42

Ilustracja 3.3: Widok witryny internetowej - część logowania

Page 43: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.2 Struktura systemu CREM

Dzięki użyciu CSS3, możliwe było zaokrąglenie rogów wyświetlanych elementów, co pozwoliło zaoszczędzić pracy przy tworzeniu grafik do strony. CSS w wersji właśnie trzeciej pozwala na płynne przejścia (transitions) w sposobie wyświetlania elementów HTML. Wykorzystane one zostały do np. płynnego wysuwania panelu symulacyjnego. Bez technologii CSS w wersji trzeciej, tego typu animacje należało tworzyć z użyciem JavaScript. W punkcie 3.4 opisana została jeszcze inna „sztuczka” z użyciem CSS3.

Witryna wykorzystuje intensywnie skrypty JavaScript. Cały kod wraz ze wszystkimi funkcjami tego języka został zapisany w jednym pliku (również w celu oszczędności zapytań oraz łatwej zmiany wersji kodu). Kod JavaScript służy przede wszystkim na natychmiastową reakcję GUI (bez zapytań do serwera) na interakcje użytkownika. Pozwala to na całkowicie płynne działanie strony.

Kod JavaScript często korzysta z asynchronicznych zapytań AJAX. Zapytania te są wysyłane na serwer, ale kod JavaScript nie jest blokowany i może wykonywać inne czynności (lub też nawet nie wykonywać się). Dopiero otrzymanie odpowiedzi zwrotnej od serwera powoduje wywołanie zadeklarowanej w JavaScript funkcji typu Callback.

Kod JavaScript służy również do powtarzalnego co zadany czas dwóch rodzajów zapytań. Jedno służy do częstych zapytań o dane pomiarowe. Na ilustracji 3.5 widać wizualizację tych danych. Drugi rodzaj zapytań wysyłanych cyklicznie czas to zapytania o komplet zestawu danych konfiguracyjnych urządzenia pomiarowego. Kod JavaScript wspomagany biblioteką jQuery (opis w punkcie 3.3.4) służy do zmiany wartości wyświetlanych kontrolek w dokumencie HTML.

43

Ilustracja 3.4: Widok witryny internetowej - część konfiguracyjna

Page 44: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.2 Struktura systemu CREM

W przypadku HTML, wysłanie formularza zwykle powoduje w przeglądarce odświeżenie strony na nową, otrzymaną jako odpowiedź na wysłany formularz. Ponieważ system CREM wykorzystuje formularz, ale nie przeładowanie strony nie było wcale intencjonalne, stworzono funkcję JavaScript o nazwie postUsingFrame(). Funkcja ta powoduje dynamiczne dodanie do drzewa DOM ukrytej ramki (frame) i programowe wysłanie formularza z tej właśnie ramki. Zapobiega to nieoczekiwanemu odświeżaniu strony.

Zarówno kod JavaScript jak i CSS nie zostały poddane zaciemnianiu (obfuscation), jednak pliki dotyczące wtyczek wykorzystane są w postaci zminimalizowej (usunięte znaki białe, niepotrzebne semantycznie znaki nowych linii) w celu sporej oszczędności na rozmiarze plików.

Wykorzystane wtyczki JavaScript opisane zostały w punkcie 3.3.4. Najciekawsze szczegóły implementacyjne można znaleźć w punkcie 3.4.

3.2.3 CREM-sender – Moduł komunikacji z „chmurą”

Moduł CREM-sender, napisany w języku Python, służy do komunikacji z „chmurą” obliczeniową. Do tego celu wykorzystano zapytania HTTP. W celu komunikacji z symulatorem lub systemem wbudowanym użyto mechanizmu gniazd. Ma dwa podstawowe zadania:

• synchroniczne, cykliczne wysyłanie co pewien czas (15 minut) pełny stan urządzenia w postaci listy aktualnych wartości parametrów pracy urządzenia oraz innych charakterystycznych danych (jak np. adres MAC, stan WiFi);

44

Ilustracja 3.5: Widok witryny internetowej - część z wykresami

Page 45: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.2 Struktura systemu CREM

• asynchroniczne wysyłanie informacji o zdarzeniach (patrz punkt 1.1) w postaci listy wartości opisujących zdarzenie, takich jak: długość trwania zdarzenia lub czas jego wystąpienia.

Moduł ten nie musi być bardzo szybki, wykorzystano więc język interpretowany Python. Pozwoliło to na opracowanie tego modułu szybciej niż w języku typu C/C++. W przypadku synchronicznego wysyłania danych, uruchamiana jest cyklicznie aplikacja CREM-sender za pomocą narzędzia crond (patrz punkt 3.3.6). Przy uruchomieniu, aplikacja pobiera z odpowiedniego gniazda w lokalnym systemie operacyjnym komplet danych konfiguracyjnych urządzenia pomiarowego, dodaje dodatkowe znaczniki czasu, informacje o stanie sieci systemu wbudowanego oraz informacje ewentualnych awariach. Taki zestaw danych porządkuje w format JSON i przesyła jako żądanie POST do „chmury” obliczeniowej. W odpowiedzi oczekuje zwykłego tekstu (plain-text). Odpowiedź „OK” powoduje zakończenie działania aplikacji. W przeciwnym przypadku informacja o nieoczekiwanej odpowiedzi jest zapisywana w systemie operacyjnym.

Moduł wysyła w sposób asynchroniczny informacje o zaistnieniu zdarzenia do „chmury” obliczeniowej. Gdy moduł, analizując pliki zapisywane w lokalnym systemie plików, wykryje sytuację wymagającą poinformowania „chmury”, tworzy zapytanie HTTP typu POST z podstawowymi informacjami o zdarzeniu, tj. czas trwania zdarzenia czy jego amplituda.

„Chmura” po uzyskaniu informacji o wystąpieniu zdarzenia może pobrać przechowywane lokalnie na systemie wbudowanym pliki z zapisanym sygnałem. W tym celu zestawione jest połączenie VPN (patrz punkt 3.3.5). „Chmura” może dzięki temu zamontować poprzez NFS katalog z zapisanymi w plikach danymi pomiarowymi. Z tak uzyskanego dostępu do plików wybiera te, którego dotyczą zdarzenia i pobiera je w celu dalszej analizy.

3.2.4 CREM-comm – Moduł pośredniczący z urządzeniem pomiarowym

Moduł ten, jest pośrednikiem między urządzeniem pomiarowym a pozostałymi modułami CREM. Z urządzeniem pomiarowym łączy się poprzez bibliotekę DSPLink. Z pozostałymi modułami komunikuje się poprzez mechanizm gniazd. Moduł zapisuje odbierane dane z sygnałem i zapisuje je do lokalnego systemu plików, po uprzedniej konwersji HEX do formatu binarnego (patrz punkt 4.5.1) i kompresji pliku. W przypadku komunikacji z pozostałymi częściami systemu CREM, ten moduł uruchamiany jest jako serwer nasłuchujący na gniazdach i, po odebraniu komendy, przesyła ją do urządzenia pomiarowego, a następnie odpowiedź zwrotną z urządzenia pomiarowego przekazuje z powrotem do gniazda.

Ponieważ szybkość działania tego modułu jest istotna dla całego systemu, został on napisany w języku C++ i poddany optymalizacji.

45

Page 46: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.2 Struktura systemu CREM

3.2.5 CREM-debug – Moduł komunikacji w trybie diagnostycznym

Zadaniem systemu CREM jest również możliwość konfiguracji pracy urządzenia pomiarowego w trybie diagnostycznym, z pominięciem interfejsu graficznego. Moduł CREM-debug pozwala na to. Wykorzystano do tego protokół Telnet (patrz: 2.9.2.1 ). Zapewnia on tylko podstawową obsługę urządzenia pomiarowego. Sama transmisja nie zapewnia szyfrowania, lecz w przypadku tego zastosowania nie jest potrzebna. Zaletą wykorzystania Telnet jest to, że komunikacja w trybie diagnostycznym może przebiegać między dwoma odległymi punktami. Kolejną zaletą jest powszechność: większość systemów operacyjnych ma domyślnie zainstalowany klient Telnet.

W celu realizacji tej funkcjonalności, moduł CREM-debug opiera się o serwer Telnet. Serwer ten nasłuchuje na domyślnym porcie 23 na połączenia. Po nawiązaniu połączenia z komputerem zdalnym (klientem), CREM-debug działa jako pośrednik w komunikacji z modułem CREM-comm.

3.2.6 CREM-sim – Moduł symulujący pracę urządzenia pomiarowego

Moduł ten pozwala imitować pracę urządzenia pomiarowego bez konieczności jego podłączenia. CREM-sim napisany został w języku Python, a jego zadania podzielone zostały na dwa wątki komunikujące się z użyciem zmiennych globalnych oraz semaforów. Semafory służą jedynie do ochrony bufora z symulowanymi danymi pomiarowymi. Pozostałe zmienne globalne nie wymagają synchronizacji, gdyż jeden wątek tylko do nich pisze, a drugi tylko je czyta.

Wątek pierwszy służy głównie do generacji sztucznych danych pomiarowych z użyciem modelu matematycznego oraz do generacji plików i zapisywania wygenerowanych danych do tych plików. Model matematyczny opiera się na szeregu zmiennych globalnych które formują wynikowe symulowane dane. Zmienne globalne dotyczą takich parametrów jak: poziom szumu, wartość średnia, amplituda głównej sinusoidy, częstotliwość głównej sinusoidy, fakt wystąpienia zdarzenia. Prawie wszystkie parametry mają dwie wartości: aktualne i docelowe. Pozwala to na płynne zmiany symulowanego sygnału pomiarowego. Tak tworzone dane dodawane są do cyklicznego bufora chronionego semaforem. Minimalna długość bufora określona jest ilością danych, jakie oczekuje CREM-www.

Podczas generacji danych, od wątku drugiego może przyjść informacja, że należy wygenerować zdarzenie. W tym celu wątek pierwszy albo generuje sygnał o

46

Ilustracja 3.6: Przykładowy sygnał obrazujący

symulowane zdarzenie

Page 47: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.2 Struktura systemu CREM

znacznie wzmocnionej amplitudzie mającej kształt o charakterze odpowiedzi impulsowej jak na ilustracji 3.6 albo zaczyna czytać dane z plików zawierających wcześniej zapisane, prawdziwe zdarzenia.

W przypadku upłynięcia określonej ilości czasu, odpowiednia zawartość bufora jest zapisywana do plików w lokalnym systemie plików. Pliki te są tworzone, otwierane i zamykane przez ten wątek. Podczas zamykania pliku, jeśli wystąpiło co najmniej jedno zdarzenie w obrębie danych właśnie zamykanego pliku, informacja o zdarzeniach wysyłana jest do „chmury” w postaci zapytania HTTP.

Wątek drugi służy jako serwer oczekujący na zapytania na określonym porcie. Obsługuje tylko część komend z pełnej, wyspecyfikowanej listy. Wprowadza jednak dodatkowe polecenia służące do sztucznego generowania zdarzeń oraz imitacji zmian m.in. temperatury w jakiej pracuje wirtualny system pomiarowy. Polecenia te przychodzą od modułu CREM-www poprzez CREM-server. Wpływają one na zmienne globalne (ten wątek jedynie piszą do nich). Wątek ten również czyta bufor (chroniony semaforem) i zwraca go jako odpowiedź w formacie JSON na jedno z zapytań od CREM-www. Ogólnie, ta część modułu CREM-sim stara się komunikować w sposób jak najbardziej przypominający rzeczywistą komunikację. Zachowany jest więc protokół opisany w punkcie 2.7.3.

Obydwa wątki aplikacji działają jako nieskończone pętle. Zamknięcie ich wykonywane jest poprzez użycie standardowej kombinacji klawiszy Ctrl+C. Dzięki odpowiedniemu zamaskowaniu sygnału SIGINT, obydwa wątki kończą poprawnie działanie.

3.2.7 CREM-config – Moduł automatycznej konfiguracji

Poza dotychczasowymi, widocznymi na schematach modułach, system CREM opiera się na dodatkowych elementach. Są nimi, przede wszystkim, skrypty służące do automatycznej konfiguracji urządzenia i działającego na nim systemu operacyjnego. Skrypty te, napisane głównie w języku powłoki (Script shell), pozwalają na automatyczne:

• skonfigurowanie i zestawienie połączenia VPN,

• konfigurację serwera Apache,

• reprogramowanie urządzenia,

• konfigurację modułu PAM,

• tworzenie użytkowników w systemie,

• nadanie odpowiednich uprawnień dla poszczególnych użytkowników,

• dodanie wszystkich niezbędnych paczek od systemu operacyjnego,

• konfigurację i uruchamianie demonów, m.in. crond, ntpd, gpsd,

• konfigurację strefy czasowej,

47

Page 48: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.2 Struktura systemu CREM

• łatwy dostęp do adresu MAC urządzenia.

Skrypty, w celu łatwości użycia, mają strukturę hierarchiczną. To znaczy, że zwykle wystarczy wywołać jeden główny skrypt, który uruchomi odpowiednio pozostałe.

3.3 Sposoby konfiguracji i zastosowań bibliotek oraz narzędzi

System CREM w celu działania wymaga szeregu bibliotek i narzędzi. Wykorzystanie ich, zamiast autorskiej implementacji wykorzystanych funkcjonalności, pozwala zaoszczędzić czas przy tworzeniu oprogramowania. W systemie CREM zostały wykorzystane jeszcze inne, mniej istotne w kontekście konfiguracji i użytkowania, aplikacje i narzędzia. Jednymi z nich są aplikacje służące do archiwizowania i kompresji danych pomiarowych (pakiet p7zip i zip), czy też aplikacja sudo służąca do wykonania pewnych operacji jako inny użytkownik (konkretnie jako root).

3.3.1 Konfiguracja serwera Apache

Jednym z najważniejszych narzędzi jest darmowy serwer HTTP Apache. Pozwala na uruchomienie modułu CREM-server opisanego w punkcie 3.2.1. Aby umożliwić poprawną pracę serwera w zastosowaniu systemu CREM, należało odpowiednio skompilować moduł PHP z flagami dodającymi wsparcie dla gniazd dziedziny systemu UNIX (unix domain socket).

Jego konfiguracja polega na edycji dwóch plików tekstowych. Jeden odpowiedzialny jest za globalną konfigurację Apache. Drugi specyfikuje serwowane witryny internetowe. W przypadku budowanego systemu wbudowanego i systemu FOSREM serwowana była tylko jedna strona. Edycja plików konfiguracyjnych pozwoliła m.in. na:

• użycie modułów do serwera (m.in. PHP, PAM);

• podanie ścieżek do katalogów, w których znajdują się pliki witryny internetowej;

• ustalenie pozwoleń na dostęp do konkretnych plików lub plików określony typu;

• przekierowywanie przeglądarki do wyspecyfikowanego pliku w przypadku wystąpienia błędu, np. 404[54];

• konfigurację skryptów np. CGI;

• zezwolenie na dostęp z poziomu klienckiej przeglądarki www do

48

Ilustracja 3.7: Udostępniony folder z plikami poprzez

serwer Apache

Page 49: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.3 Sposoby konfiguracji i zastosowań bibliotek oraz narzędzi

określonego katalogu jak na ilustracji 3.7;

• ustalenie czy serwer ma zapisywać logi, jakiego typu oraz do jakiego pliku.

Zwykle, aby serwer Apache uwzględnił zmiany wprowadzone w plikach konfiguracyjnych wymagane jest ponowne uruchomienie aplikacji poprzez, wygodny do tego celu, skrypt w katalogu /etc/init.d/.

3.3.2 Konfiguracja modułów PAM

PAM jest modułowym mechanizmem pozwalającym na jednolity dostęp do niskopoziomowych technik kryptograficznych poprzez API wysokiego poziomu. Dzięki wykorzystaniu PAM, podczas uwierzytelniania użytkowników poprzez stronę serwer nie trzeba było implementować własnoręcznie ani żadnych algorytmów, ani obsługi kluczy. Ponadto, w przypadku aktualizacji systemu operacyjnego, nie jest wymagana modyfikacja kodu systemu CREM – PAM zajmie się i obsłuży ewentualne zmiany algorytmów kryptograficznych bez zmian w wysokopoziomowy API. Przykład wykorzystania funkcji pam_auth() został pokazany w punkcie 3.4.

Konfiguracja PAM w przypadku systemu FOSREM polegała na dodaniu rozszerzenia PAM do konfiguracji PHP oraz podania, w konfiguracyjnym pliku tekstowym, kiedy użytkownik otwierający stronę internetową ma możliwość zalogowania się[55]. Wybrano dwie pozycje, które muszą zostać spełnione:

• podana nazwa użytkownika powinna znajdować się na liście użytkowników w systemie operacyjnym;

• podana para nazwa użytkownika – hasło powinna pasować do siebie.

3.3.3 Użycie języka Python

Znaczna część systemu CREM została napisana w języku Python. Aby zaoszczędzić czasu przy tworzeniu modułów, wykorzystano wiele bibliotek programistycznych dostarczanych wraz z językiem. Wśród nich znajdują się:

• collections – implementacja kolekcji takich jak kolejka, lista dwukierunkowa (deque);

• commands – pozwala uruchamiać zewnętrzne skrypty z poziomu wiersza poleceń;

• cremutils – autorska biblioteka pozwalająca na np. konwersję wartości liczbowych do zakodowanych w formacie HEX i odwrotnie;

• datetime - manipulacje na datach takich jak porównywanie czy konwersja znaczików czasowych (timestamp) do daty czytelnej dla człowieka i odwrotnie;

• httplib – służy do tworzenia i wysyłania zapytań POST oraz GET;

• json – biblioteka służąca do manipulacji i tworzenia hierarchicznych struktur w

49

Page 50: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.3 Sposoby konfiguracji i zastosowań bibliotek oraz narzędzi

formacie JSON;

• math – wykorzystywane w celu generowania sygnału sinusoidalnego przez moduł CREM-sim;

• random – wykorzystana w celu generacji losowego sygnału (np. szumu) przez moduł CREM-sim;

• signal – pozwala na manipulacje sygnałami (rozumianymi w sensie IPC) i chociażby zmianę funkcji obsługującej dany sygnał;

• SocketServer – implementacja serwera nasłuchującego na porcie;

• struct – używane w celu automatycznej konwersji wartości liczbowych (np. typu zmiennoprzecinkowego) do tablicy bajtów i odwrotnie;

• threading – biblioteka do tworzenia wątków i ich zarządzania oraz semaforów;

• time – dostęp do czasu systemowego.

3.3.4 Stosowane rozszerzenia języka JavaScript

W module CREM-www w sposób intensywny wykorzystywany jest język JavaScript. W przypadku tego kodu, wykorzystano szereg dodatków do języka:

• jQuery[56] – jedna z najpopularniejszych bibliotek programistycznych dla języka JavaScript, ułatwia manipulację drzewem DOM, użycie selektorów oraz zapytania AJAX, główną zaletą jQuery jest jego niezaprzeczalna wygoda korzystania kosztem niewielkiego spadku wydajności, gdyby pisać analogiczny kod w czystym JavaScript, byłby kilkukrotnie dłuższy, wykorzystana została biblioteka w wersji 1.9.1;

• jQuery.event.jscrollpane – podbiblioteka jQuery, pozwalająca na wygodne zarządzanie elementami HTML poprzez dodanie do nich opcjonalnych suwaków do przewijania prezentowanego obszaru;

• Flotr2[57] – darmowa biblioteka służąca do wyświetlania wykresów, posiada duże możliwości konfiguracyjne, korzysta z elementu canvas języka HTML5;

50

Ilustracja 3.8: Moduł CREM-www uruchomiony na

urządzeniu dotykowym

Page 51: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.3 Sposoby konfiguracji i zastosowań bibliotek oraz narzędzi

• iDangero.us swiper[58] – rozbudowana, darmowa biblioteka ułatwiająca korzystanie i własną interpretację zdarzeń związanych z gestami typu swipe, pozwala na tworzenie sprzętowo wspomaganych animacji i przejść między np. dwoma częściami prezentowanego obrazu. Ilustracja 3.8 przedstawia uruchomiony moduł CREM-www na urządzeniu dotykowym – tablecie i wykorzystaniu biblioteki swiper.

3.3.5 Konfiguracja pakietu OpenVPN

Konfiguracja pakietu OpenVPN była niezbędna ze względu na konieczność bezpiecznej komunikacji z „chmurą”. W przypadku systemu CREM, konfiguracja opierała się o certyfikaty (druga możliwość, mniej bezpieczna, to mechanizm współdzielonego klucza[59]). Użycie certyfikatów SSL to najbardziej zaawansowana i najbezpieczniejsza metoda konfiguracji pakietu OpenVPN.

Konfiguracja pakietu dotyczy głównie modyfikacji dwóch plików tekstowych: po jednym dla strony serwera i klienta. Pliki te specyfikują m.in. użyty protokół (TCP lub UDP), port, adresy obydwu stron, metodę kompresji połączenia lub wybrany algorytm szyfrowania. Praktycznie większość wyspecyfikwoanych parametrów powinna być identyczna w obydwu plikach.

Dzięki wykorzystaniu pakietu OpenVPN możliwa jest dowolna, bezpieczna komunikacja „chmury” z urządzeniem wbudowanym. W szczególności, w miarę potrzeby, „chmura” montuje poprzez NFS zdalny katalog z plikami z zapisami pomiarów. Może wtedy te pliki przeglądać, a nawet usuwać.

3.3.6 Konfiguracja narzędzia Crond

Crond jest to demon uruchamiający cyklicznie komendy, które zostały zdefiniowane w jego pliku konfiguracyjnym. Przykładowy wpis do wspomnianego pliku wykorzystywany przez system CREM wygląda następująco:

43. */15 * * * * /bin/fosrem/cremsender.py

Pierwszy element */15 określa, że polecenie ma być wykonywane, gdy liczba minut w systemie operacyjnym wyniesie 0, 15, 30 lub 45. Pozostałe * oznaczają, że liczba określająca kolejno: godzinę, dzień miesiąca, miesiąc oraz dzień tygodnia nie mają znaczenia. W efekcie, skrypt cremsender.py podany w linijce uruchamiany jest zawsze co 15 minut.

Sam demon crond uruchamiany jest za pomocą skryptów startowych znajdujących się w katalogu /etc/init.d/.

51

Page 52: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.3 Sposoby konfiguracji i zastosowań bibliotek oraz narzędzi

3.3.7 Konfiguracja narzędzia Ntpd

Ntpd jest demonem który pozwala utrzymywać synchronizację czasu systemowego oraz zegara czasu rzeczywistego (RTC) z ustalonym źródłem czasu. Zwykle jest to serwer NTP znajdujący się w Internecie. Wtedy konfiguracja opiera się głównie na określeniu adresu serwera (lub adresów wielu serwerów) NTP oraz częstotliwości, z jaką należy synchronizować czas. Tak jak w przypadku poprzednich narzędzi, ntpd uruchamiany jest za pomocą skryptów startowych znajdujących się w katalogu /etc/init.d/.

3.3.8 Konfiguracja narzędzia Gpsd

Zwykle ntpd z synchronizacją czasu przez Internet daje dobre rezultaty i dokładność rzędu 20 ms. Jednak w przypadku systemu FOSREM, dokładność zapewniana przez ten mechanizm okazała się niewystarczająca. Dodano więc do systemu wbudowanego odbiornik GPS. Pozwala on uzyskać dokładność rzędu 300 ns, co okazało się satysfakcjonujące.

Do obsługi odbiornika wykorzystano narzędzie gpsd, ponieważ ntpd nie potrafi się komunikować bezpośrednio z urządzeniem GPS. Konfiguracja demona gpsd w tym przypadku polegała głównie na ustawieniu parametrów wybranego portu COM dostępnego w systemie operacyjnym które reprezentowało urządzenie GPS. Konieczna była również modyfikacja konfiguracji ntpd tak, aby korzystał z lokalnej usługi świadczonej przez gpsd. Dla bezpieczeństwa, pozostawiono możliwość synchronizacji z serwerami czasu w Internecie z uwagi na możliwą awarię urządzenia GPS lub połączenia z nim.

3.4 Istotne metody implementacji kodu

Przy większych systemach informatycznych, istotne są metody implementacji poszczególnych fragmentów systemu. Szczególną uwagę należy przywiązywać do tzw. wąskich gardeł, czyli części systemu, których nieduża wydajność może powodować nieoptymalne wykorzystanie pozostałych części systemu. W punkcie opisane zostały wybrane fragmenty kodu systemu CREM, których metoda implementacji była istotna.

3.4.1 Konwersje liczb w postaci HEX

W systemie CREM w wielu miejscach wymagana była konwersja wartości liczbowych na ciągi znaków zakodowane w formacie HEX. Poniżej przedstawione zostały konwersje w językach.

W języku Python do konwersji dobrze jest użyć wbudowanego modułu struct służącego do interpretacji ciągów znakowych jako danych binarnych[60] oraz funkcji encode()/decode() . W efekcie uzyskujemy:

52

Page 53: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.4 Istotne metody implementacji kodu

44. def hexToFloat(h):

45. return struct.unpack('!f', h.decode('hex'))[0]

46.

47. def floatToHex(v):

48. return str(bytearray(struct.pack('!f', v))).encode('hex')

W języku PHP z kolei również posiadamy wsparcie dla tego typu konwersji. Język wspiera (tak samo jak Python) funkcje pack()/unpack() oraz bin2hex()/hex2bin() (analogi encode()/decode()).

Należy zauważyć, iż funkcja hex2bin() została wprowadzona w PHP 5.4.0.49. hex2float($h) {

50. return unpack('f', strrev(hex2bin($h)))[1];

51. }

52.

53. float2hex($f) {

54. return bin2hex(strrev(pack('f', $f)));

55. }

W języku JavaScript sytuacja jest nieco bardziej skomplikowana. Język nie wspiera wspominanych wcześniej operacji. Wymaganą konwersję należy zaimplementować samemu. Poniżej dwie funkcje konwertujące:56. function hexToFloat32(a) {

57. a = parseInt(a, 16);

58. // 0x40000000 || 0xC0000000 (+0.0 || -0.0)

59. if (a == 1073741824 || a == 3221225472) return "0.0";

60. // x111 1111 1xxx xxxx xxxx xxxx xxxx (NaN)

61. if ((a | 0x7f800000) == 0x7f800000) return "NaN";

62. s = a >> 31 ? -1.0 : 1.0;

63. return s * (a & 0x7fffff | 0x800000) / Math.pow(2, 23) *

Math.pow(2, ((a>>23 & 0xff) - 127));

64. }

65.

66. function float32ToHex(v) {

67. var ebits = 8;

68. var fbits = 23;

69. var bias = (1 << (ebits - 1)) - 1;

70. // Compute sign, exponent, fraction; return value, temp

71. var s, e, f, r, t;

72. if (isNaN(v)) {

73. e = (1 << bias) - 1; f = 1; s = 0;

74. }

75. else if (v === Infinity || v === -Infinity) {

76. e = (1 << bias) - 1; f = 0; s = (v < 0) ? 1 : 0;

77. }

78. else if (v === 0) {

79. e = 0; f = 0; s = (1 / v === -Infinity) ? 1 : 0;

80. }

81. else {

82. s = v < 0;

53

Page 54: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.4 Istotne metody implementacji kodu

83. v = Math.abs(v);

84. if (v >= Math.pow(2, 1 - bias)) {

85. var ln = Math.min(Math.floor(Math.log(v) /

Math.LN2), bias);

86. e = ln + bias;

87. f = v * Math.pow(2, fbits - ln) - Math.pow(2,

fbits);

88. }

89. else {

90. e = 0;

91. f = v / Math.pow(2, 1 - bias - fbits);

92. }

93. }

94.

95. // Pack sign, exponent, fraction

96. var i, bits = [];

97. for (i = fbits; i; i -= 1) { bits.push(f % 2 ? 1 : 0); f =

Math.floor(f / 2); }

98. for (i = ebits; i; i -= 1) { bits.push(e % 2 ? 1 : 0); e =

Math.floor(e / 2); }

99. bits.push(s ? 1 : 0);

100. bits.reverse();

101. var str = bits.join('');

102.

103. // Bits to bytes

104. var bytes = [];

105. while (str.length) {

106. bytes.push(parseInt(str.substring(0, 8), 2));

107. str = str.substring(8);

108. }

109. // Prepare output

110. r = "";

111. for (var i = 0; i < 4; i++) {

112. t = bytes[i].toString(16);

113. if (t.length == 1) { t = "0" + t };

114. r += t;

115. }

116. return r;

117. }

3.4.2 Pobieranie identyfikatora urządzenia

Jako że za identyfikator konkretnego urządzenia przyjmuje się adres MAC jego interfejsu Ethernet, stworzony został pomocniczy skrypt powłoki zwracający właśnie ten adres. Skrypt korzysta z typowych poleceń systemów GNU/Linux. Polecenie systemowe ifconfig zwraca całą konfigurację sieciową interfejsu eth0 (podanego jako parametr wywołania) w postaci tekstowej. Polecenie grep filtruje linie tekstu i zwraca tylko tę, która zawiera ciąg znaków HWaddr. Następnie polecenie sed pozwala na filtrowanie tylko

54

Page 55: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.4 Istotne metody implementacji kodu

pierwszej linii swojego wejścia. Uwalnia to nas od problemu, że zostanie zwróconych kilka linii tekstu. Wprawdzie taka sytuacja nie powinna mieć miejsca na urządzeniach docelowych, jednak dodatkowe zabezpieczenie działania skryptu jest zawsze dobrym pomysłem. Polecenie tr usuwa zbędne znaki spacji, a polecenie cut pozwala na zwrócenie piątego słowa (czyli oczekiwanego adresu MAC).118. #!/bin/sh

119. echo `ifconfig eth0 \

120. | grep 'HWaddr' \

121. | sed -n '1p' \

122. | tr -s ' ' \

123. | cut -d ' ' -f5 `

3.4.3 Uwierzytelnianie użytkowników

Kolejny przykład to fragment serwera napisanego w PHP służący do uwierzytelniania użytkownika. Widać, że dzięki skorzystaniu z biblioteki PAM (konkretnie wywołanie pam_auth()) programista nie musi skupiać się na specyfice uwierzytelniania w kodzie PHP. Wywołuje jedynie jedną funkcję zwracającą wartość oznaczającą sukces lub niepowodzenie uwierzytelnienia. Zamiast tego, wystarczy raz skonfigurować moduł PAM w systemie operacyjnym, a później koncentrować się na mechanice samej aplikacji.124. $msg = '';

125. $wrong = false;

126. if($_SERVER['REQUEST_METHOD'] == 'POST') {

127. $username = $_POST['username'];

128. $password = $_POST['password'];

129.

130. if ( !empty($username) and !empty($password) ) {

131.

132. if ( pam_auth( $username, $password, &$error ) ) {

133. # Auth successfull, proceed

134. session_start();

135. $_SESSION['u'] = $username;

136. header("location:index.php");

137. }

138. else {

139. # Wrong user/pass

140. $msg = $error; # Or 'Wrong username or password';

141. $wrong = true;

142. }

143. }

144. }

55

Page 56: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.4 Istotne metody implementacji kodu

3.4.4 Implementacja zapytań interfejsu graficznego

W kodzie JavaScript bardzo często wykorzystuje się zapytania AJAX. Poniżej podano najczęściej tworzenie zapytania GET o określonych przez system CREM parametrach. Wykorzystano mechanizm AJAX głównie ze względu na asynchroniczność. Właściwość ta pozwala wykonywać zapytania i nie czekać na nie. W efekcie JavaScript może wykonywać inny fragment kodu. Sama witryna interfejsu graficznego nie jest blokowana zapytaniami, przez co użytkownik nie obserwuje efektów z tym związanych.145. function readAll() {

146. if (g_read_all_pending)

147. return;

148.

149. g_read_all_pending = true;

150. $.ajax({

151. type: "GET",

152. url: "config.php?c=read_all",

153. dataType: "json",

154. success: function(data, textStatus, jqXHR) {

155. fillAllData(data);

156. g_read_all_pending = false;

157. },

158. error: function(jqXHR, textStatus, errorThrown) {

159. logDebug("jqXHR: " + jqXHR +

160. " testStatus: " + textStatus +

161. " errorThrown: " + errorThrown);

162. g_read_all_pending = false;

163. }

164. });

165. }

3.4.5 Obsługa asynchronicznych zapytań

Ponieważ część kontrolek na stronie WWW służy zarówno do wprowadzania danych przez użytkownika jak i wyświetlania przychodzących asynchronicznie danych od serwera, należało zablokować zmianę wyświetlanych danych kontrolki, na której użytkownik właśnie pracuje. Jednak tyczy się to również przycisków dotyczących danej kontrolki (jak np. przycisk Set obok pola tekstowego na wprowadzoną wartość. W tym celu stworzono funkcję zwracającą obecnie aktywny lub wybrany element HTML. Wystarczy to zrobić raz, gdyż w trakcie działania skryptu JavaScript, użytkownik nie ma możliwości zmiany wybranego elementu.

Pokazana niżej funkcja ma za zadanie znaleźć albo edytowane obecnie pole tekstowe, albo pole tekstowe, którego dotyczy obecnie wciskany przycisk (button) na stronie. Pierwszy przypadek jest prosty, gdyż sprawdzamy tylko atrybut focus z użyciem selektora jQuery. W drugim przypadku musimy znaleźć obecnie aktywny przycisk, a następnie przejść wstecz po elementach wspólnego rodzica do napotkania pierwszego

56

Page 57: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.4 Istotne metody implementacji kodu

elementu tekstowego.166. function getActiveInputOrSelect() {

167. var found = "";

168.

169. // First run is expensive

170. var focused = $(':focus');

171.

172. if (focused.length) {

173. found = focused[0].id;

174. }

175. else {

176. var active = $('button:active');

177. // If user is pressing some button

178. if (active.length) {

179. var found = false;

180. // Now get particular input id name

181. // Using button with no id

182. var el = active.prev();

183. while (el.length) {

184. if (el.is("input") || el.is("select")) {

185. found = el[0].id;

186. break;

187. }

188. el = el.prev();

189. }

190. }

191. }

192. return found;

193. }

3.4.6 Obsługa HTML5 przez przeglądarkę Internet Explorer

Z uwagi na wykorzystanie języka HTML w wersji 5, nieobsługiwanej w pełni przez przeglądarkę Internet Explorer, należało odpowiednio dostosować kod HTML. Ponieważ witryna nie korzysta z zaawansowanych elementów typu canvas, wystarczyło dodać typy nieobsługiwanych elementów HTML5. Dzięki temu, przeglądarka Internet Explorer interpretuje poprawnie wcześniej nieznane typy elementów.194. 'article aside footer header nav section time'.replace(/\w+/g,function(n)

{document.createElement(n)});

3.4.7 Inicjacja witryny internetowej

W przypadku kaskadowych arkuszy stylów, poza typowym działaniem (tj. nakładaniem wartości atrybutów elementów HTML służących do ich poprawnego wyświetlania) należało dodać pewien nietypowy kod. Wykorzystanie biblioteki swiper do przewijania poziomo wielu widoków (tutaj nazywanych slajdami) wprowadziło pewien

57

Page 58: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

3.4 Istotne metody implementacji kodu

problem. Przy wczytywaniu strony, najpierw ładowane i wyświetlane są wszystkie elementy z nałożonymi stylami. Dopiero po wczytaniu strony uruchamiane są skrypty JavaScript służące m. in. do poprawnego ustawienia slajdów. W przypadku stworzonej strony, między wczytaniem strony a uruchomieniem skryptów następował niechciany efekt wyświetlenia wszystkich slajdów naraz. W celu rozwiązania problemu, należało skorzystać z niniejszej reguły:195. /* Deglitch webpage on load */

196. div.swiper-wrapper div.swiper-slide:not(:first-child){

197. visibility: hidden;

198. }

Wybiera one slajdy, ale tylko takie, które nie są pierwszym elementem potomnym swojego rodzica. Na tak wybrane elementy nakładany jest wartość atrybutu visibility, która określa, że elementy te mają być niewidoczne. Ponieważ po załadowaniu strony oraz zakończeniu inicjacji biblioteki swiper strony te powinny być jednak widoczne, również w JavaScript elementom tym, programowo, przywracamy widoczność.

58

Page 59: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4 Rezultaty

4 Rezultaty

W wyniku przeprowadzonych prac opracowany został system CREM. Przedstawione, w rozdziale 3, rozwiązanie w postaci zaprojektowanych i zaimplementowanych szeregu aplikacji okazało się skuteczne. Rozdział stanowi porównanie i analiza wyników działania systemu.

4.1 Realizacja wymagań

Przed systemem CREM zostało postawionych szereg warunków, jakie miała spełniać. Tabela 4.1 przedstawia wymagane funkcjonalności wraz z priorytetem oraz informacją, czy system CREM spełnia założenia.

Priorytet Wymagania Spełnienie wymagań

1 Komunikacja z urządzeniem

pomiarowym

Spełnione

2 Wysyłanie danych konfiguracyjnych do

serwera

Spełnione

3 Przechowywanie danych na urządzeniu Spełnione

4 Udostępnienie danych dla serwera Spełnione

5 Stworzenie symulatora urządzenia

pomiarowego

Spełnione, dodatkowe opcje symulacji

6 Dostęp w trybie diagnostycznym Spełnione

7 Wykorzystanie technologii swipe do

nawigowania strony www, wygodne i

proste GUI

Spełnione, duża możliwość konfiguracji

8 Synchronizacja czasu na urządzeniu Spełniona synchronizacja z czasem w

Internecie oraz z przygotowanie systemu na

użycie odbiornika GPS

9 Bezpieczeństwo komunikacji Spełnione w stopniu bardzo dobrymTab 4.1: Spełnienie postawionych wymagań przez system CREM

4.2 Napotkane trudności

Podczas tworzenia systemu CREM napotkano na szereg trudności. Niektóre związane były z samym środowiskiem, inne z powodu postawionych założeń a inne ze specyfiki systemu FOSREM czy też systemu operacyjnego.

Sporym problemem okazała się poprawna konfiguracja modułu PAM. Pomimo sporej

59

Page 60: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.2 Napotkane trudności

literatury, poprawne i bezpieczne ustawienie dostępu do wymaganych części systemu operacyjnego okazało się kłopotliwe. Należało odpowiednio zmieniać uprawnienia dostępu do niektórych plików, gdyż serwer Apache działa jako użytkownik nobody. Pomimo usilnych prób, nie udało się jednak wykonać za pomocą modułów PAM operacji zmiany hasła z poziomu języka PHP. Zgodnie z wypowiedzią użytkownika Charalampos Serenis[61], zmiana bezpośrednio hasła za pomocą PAM z poziomu PHP wymaga zbyt dużych uprawnień do systemu plików i usług. Autor wypowiedzi sugeruje użycie LDAP, jednak w przypadku systemu CREM wykorzystano polecenie passwd wraz z ręczną implementacją ochrony przed niewłaściwym użyciem tej funkcji. Należało również pamiętać, aby dodać niezbędne znaki '\' przed znakami specjalnymi w przypadku wywoływania polecenia passwd.

W przypadku tworzenia modułu CREM-www największym problemem okazało się wyświetlanie witryny internetowej z użyciem przeglądarki Microsoft Internet Explorer (w skrócie MSIE) w wersjach starszych niż 8.0. Na szczęście, w większości przypadków problemy były natury wizualnej, tak jak obrazują ilustracje 4.1, 4.2 i 4.3. Przykład ten (z wersji 10)pokazuje, że przeglądarka MSIE inaczej niż pozostałe, wyświetla obrazy które są hiperłączami. MSIE dodaje obramowanie (border), powodujące nieestetyczny wygląd kontrolki służącej do wylogowania się. Problemu tego pozbyto się poprzez explicite wyspecyfikowanie, że dany obiekt ma mieć obramowanie o szerokości zero.

4.3 Środowisko testowe

Do testów wydajnościowych wykorzystano kilka maszyn, aby porównać możliwości i ewentualne problemy. Tabela 4.2 przedstawia używane maszyny. Podczas testów, na uruchomianym systemie zamknięto wszystkie zbędne aplikacje (w tym antywirus), uruchomiony był, poza badanymi aplikacjami, notatnik lub konsola z uruchomionym poleceniem vi do zapisywania wyników oraz program do pomiaru zużycia zasobów. W przypadku systemu Windows używano narzędzia Windows resource monitor lub darmowego programu Process Explorer w wersji 15.40. Ponieważ Windows resource monitor pokazuje zużycie bieżące procesora na każdy proces oraz zużycie średnie z ostatnich 60 sekund, każdy pomiar z użyciem tego narzędzia trwał ponad 60 sekund (jeśli w opinie testu nie podano inaczej), po czym odczytano wskazania programu. Program Process Explorer służył do monitorowania zużycia procesora przez konkretny proces i

60

Ilustracja 4.1: Widok

kontrolki w przeglądarce

MSIE

Ilustracja 4.2: Widok

kontrolki w przeglądarce

Chrome

Ilustracja 4.3: Widok

kontrolki w przeglądarce

Firefox

Page 61: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.3 Środowisko testowe

wyświetlanie go na wykresie, gdyż Windows resource monitor nie pozwala na rysowanie wykresów zużycia dla wybranego procesu. W przypadku systemu Linux wykorzystywano narzędzie top, a w przypadku tabletu wykorzystywano wbudowany monitor zużycia zasobów możliwy do włączenia w opcjach deweloperskich. Ponieważ narzędzie top pokazuje zużycie zasobów sprzętowych na proces, stworzono dodatkowe skrypt w języku Python, które sumowały zużycie dla aplikacji wieloprocesowych. Do pomiaru poziomy wykorzystania łącza sieciowego wykorzystano narzędzie iftop.

Nazwa Maszyna A Maszyna B Maszyna C Maszyna D

Szczegółowy opis Komputer stacjonarny klasy

PC

Laptop Lenovo Thinkpad X230i

Maszyna wirtualna

Tablet Asus Nexus

7

Procesor Intel(R) Pentium(R) D 925

3.00GHz, 4M Cache

Intel(R) Core(R) i3-3120M

2.50GHz, 3M Cache

Intel(R) Xeon(R)

E5-1620 3.60GHz,

10M Cache, 1 core

Nvidia Tegra 3

Quad-Core,

1.2GHz

Pamięć RAM 2 GB DDR2 800MHz

8 GB DDR3 1600MHz

489.64 MB DDR3 1GB

Karta graficzna NVIDIA(R) Quadro

K5000 4GB

Intel HD Graphics

4000

n.d. 12-core nVidia

ULP GeForce

Pamięć masowa Seagate

ST320LT007 7200

SSD Samsung 530

256GB

9.84 GB 8GB

System

operacyjny

Windows 7 Professional

Service Pack 1 32-bit

Windows Professional 8 64-

bit

Ubuntu Linux 12.04.2, Linux

3.2.0-23-virtual on x86_64

Android Jelly Bean

4.2.2

Tab 4.2: Konfiguracje sprzętowe używane podczas testów

Do podstawowej weryfikacji działania modułu CREM-www, poza logami, wykorzystywano narzędzie Developer Tools (co obrazuje ilustracja 4.4) w przeglądarce internetowej Google Chrome. Wykorzystywana przeglądarka była w wersji 29.0.1547.62 m. Narzędzie Developer Tools przypomina dosyć popularny Firebug dla przeglądarki Firefox[62]. Witryna internetowa była również obserwowana pod innymi przeglądarkami w celu weryfikacji, czy całość działa dobrze i jest dobrze wyświetlana. Użyto przeglądarki Internet Explorer w wersji 10.0.9200.16521 oraz Firefox w wersji 23.0.1. Wykorzystano również serwis Browser Shots[63] który pokazuje jak wygląda witryna internetowa na wielu różnych przeglądarkach internetowych. Serwis obsługuje ponad 180 wersji wielu przeglądarek (nawet tak egzotycznych jak: Arora 0.1, Dillo 2.1, MSIE 5.5, Flock 1.0, Kazehakase 0.5, SeaMonkey 1.1).

61

Page 62: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.3 Środowisko testowe

Do testowania poprawności działania pozostałych modułów systemu CREM wykorzystywano głównie stworzone skrypty w języku Python, które nawiązywały komunikację z badanymi modułami i sprawdzały, czy działają dla typowych sytuacji, dla skrajnych (jak np. otrzymanie pustej wiadomości) oraz niepoprawnych (awaria nawiązanej wcześniej komunikacji). W przypadku niepoprawnych sytuacji moduły systemu CREM nie powinny niepotrzebnie kończyć swojego działania, a starać się działać jeśli to możliwe poprzez np. obsługę sytuacji wyjątkowych.

4.4 Weryfikacja systemu CREM

W celu weryfikacji działania systemu CREM wykorzystano szereg narzędzi do wspomagania jej. Wspomniane w punkcie 4.3 narzędzie Browser Shots pozwoliło zaoszczędzić czasu przy weryfikowaniu wyglądu witryny internetowej na różnorodnych przeglądarkach w różnorodnych środowiskach. Ilustracja 4.5 przedstawia widok stworzonej strony internetowej w 66 wybranych przeglądarkach internetowych. Na czerwono zaznaczono problematyczne przeglądarki MSIE. Dzięki narzędziu Browser Shots wiadomo było, nad czym skupić uwagę przy dokonywaniu poprawek do interfejsu www.

62

Ilustracja 4.4: Przykład użycia Developer Tools w aplikacji Chrome

Page 63: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.4 Weryfikacja systemu CREM

Dodatkowo, skorzystano z usługi W3C Markup Validation Service[64]. Jest to darmowa usługa udostępniana przez W3C. Pozwala sprawdzić zgodność dokumentu HTML ze standardami HTML lub XHTML, a także umożliwia twórcom stron internetowych znalezienie błędów. Ilustracja 4.6 przedstawia wynik działania usługi. Stworzona strona, po iteracyjnych poprawach, nie zawiera żadnych błędów względem standardów HTML.

Moduł CREM-www został zbadany również przy użyciu tekstowej przeglądarki Lynx[65]. Stworzona witryna była poprawnie wyświetlana w trybie tekstowym i, przede wszystkim, całkowicie możliwa do nawigacji. Widok witryny obrazuje ilustracja 4.7. Wprawdzie nie przewiduje się, żeby system CREM był wykorzystywany w ten sposób, lecz każda dobrze stworzona witryna internetowa powinna cechować się tym atutem.

63

Ilustracja 4.6: Wynik usługi W3C Markup Validation Service

Ilustracja 4.5: Zrzut wyniku działania witryny Browser Shots

Page 64: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.4 Weryfikacja systemu CREM

Do weryfikacji modułu CREM-www wykorzystano szeroko Developer Tools opisane w punkcie 4.3. Narzędzie pozwoliło na sprawdzenie, czy reguły CSS zostały poprawnie nałożone na obiekty HTML. Również weryfikacja poprawności działania funkcji napisanych w JavaScript wykonywana była z użyciem Developer Tools.

Wszystkie moduły systemu CREM zostały poddane testom jednostkowym oraz integracyjnym. W przypadku modułów napisanych w języku Python, stworzono dodatkowe funkcje weryfikujące poprawność wykonywanych operacji i działań przez tworzone moduły. Moduł CREM-server weryfikowany był poprzez wielokrotne wywoływanie serwowanych witryn z poziomu przeglądarek. W szczególności weryfikowano, czy istnieje możliwość nawiązania nieautoryzowanego połączenia się z urządzeniem pomiarowym.

4.5 Testy kompresji

W przypadku przechowywania danych pomiarowych i ich udostępniania dla „chmury” obliczeniowej istotna była ilość zajmowanego miejsca przez te dane. Dlatego dosyć wnikliwie analizowano kwestie kompresji.

64

Ilustracja 4.7: Widok witryny internetowej w przeglądarce Lynx

Page 65: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.5 Testy kompresji

4.5.1 Konwersja z formatu hex do binarnego

Z założenia, urządzenie pomiarowe wysyła dane w formacie tekstowym jako wartości HEX, jak np.:

B9A2C4C8389C296538046021B72DBAFC386F6D8F38B152B7388ADC42384FE2273901146738C0194E381C3E4D36530A2A388BB243380C03063713815F382B28E738F5676738AE3FCE382C6916389CD7E338CD6BF4384CC83EB68F247F383F12E2385D5340382D105838150DDB38E862B338BB8004...

Widać sporą nadmiarowość, gdyż są to tak naprawdę dane binarne zapisane w innym formacie. Przeprowadzono testy czasowe na urządzeniu wbudowanym służące do konwersji danych z formatu HEX na binarny. W zoptymalizowanym kodzie napisanym w języku Python uzyskano wyniki przedstawione w tabeli 4.3. Wielkość pliku 8,1 MB odpowiada 900000 próbkom. Na wykresie widać liniowy wzrost wraz ze wzrostem ilości danych do konwersji. Obserwuje się, że na systemie wbudowanym operacja ta trwa stosunkowo dużo.

Wielkość pliku wejściowego [MB] Czas operacji [s]

4,1 8,92

8,1 16,8

16,2 32,91

32,4 64,79Tab 4.3: Czas konwersji formatu HEX do formatu binarnego

65

0 5 10 15 20 25 30 350

10

20

30

40

50

60

70

Czas konwersji formatu HEX do formatu binarnego

Test na systemie wbudowanym

Wielkość pliku wejściowego

Cza

s o

pe

racj

i

Page 66: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.5 Testy kompresji

4.5.2 Porównanie aplikacji służących do kompresji

Przetworzone dane binarne (patrz punkt 4.5.1) poddawano następnie kompresji. Nie była konieczna archiwizacja, gdyż kompresja dotyczyła zawsze tych samych plików. Testy zostały przeprowadzone na pliku wejściowym o wielkości 3,6MB (co odpowiada 900000 próbkom). Formaty RAR oraz UHA wykonano tylko w systemie operacyjnym Windows 7 ze względu na niedostępność rozwiązań na system operacyjny GNU/Linux. Jak pokazuje tabela 4.4, istnieją dosyć znaczące różnice w wielkości skompresowanych plików. Również czas operacji na systemie wbudowanym (zajmujący ponad minutę) nie jest nieznacząco mały.

Aplikacja Rozmiar wynikowego pliku [MB] Czas operacji [s]

7z 2,061729 69,43

zip 2,614154 72,58

rar 2,462307 b.d.

uha 1,924417 b.d.Tab 4.4: Porównanie formatów kompresji

4.5.3 Szczegółowa analiza kompresji 7z

Sposób kompresji 7z specyfikuje wiele algorytmów kompresji. Najpopularniejszy (i domyślny) LZMA wcale nie musi okazać się najlepszy. W celu sprawdzenia tego, wykonano kolejny test. Tym razem porównano tylko kompresję 7z używając różnych algorytmów ze swoimi ustawieniami domyślnymi. Moduł p7zip wykorzystany do testów miał wersję 9.13.

66

7z zip rar uha0

0,5

1

1,5

2

2,5

3

67

68

69

70

71

72

73

Porównanie formatów kompresji

Słupki - rozmiar danych; linia - czas kompresji

Format kompresji

Ro

zmia

r d

an

ych

[MB

]

Cza

s o

ep

racj

i [s

]

Page 67: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.5 Testy kompresji

W tabeli 4.5 widać różnice przede wszystkim czasowe w wykonywanych operacjach. Najszybszy okazał się algorytm Deflate. Co ciekawe, ten sam algorytm, ale z gorszym skutkiem, wykorzystuje domyślnie kompresor ZIP. Ten algorytm okazał się jednocześnie najgorszy pod względem rozmiaru wyjściowego pliku. Z uwagi na uzyskane rezultaty, w dalszej części tego punktu wykorzystano algorytm LZMA2. Szczegółowy opis dobieranych parametrów można znaleźć pod adresem[66].

Algorytm Rozmiar wynikowego pliku [MB] Czas operacji [s]

LZMA 2,061729 71,82

LZMA2 2,062041 68,71

PPMD 2,138247 100,17

bzip2 2,090635 38,92

deflate 2,521530 25,99Tab 4.5: Porównanie algorytmów kompresji 7z

Kolejny test miał pokazać wpływ parametru określanego jako Poziom kompresji na operację kompresji. P7zip korzysta domyślnie z poziomu numer 5. Wyniki, zobrazowane w tabeli 4.6, pokazują, że mamy do czynienia z progiem na granicy 4 i 5 poziomu. W obrębie poziomów 1-4 oraz rozdzielnie poziomów 5-9 nie zaobserwowano istotnych różnic w działaniu algorytmu. Test kolejny raz obrazuje, że mniejszy rozmiar pliku uzyskujemy kosztem zwiększonego czasu operacji, co jest intuicyjnie zrozumiałe.

67

LZMA LZMA2 PPMD bzip2 deflate0

0,5

1

1,5

2

2,5

3

0

20

40

60

80

100

120

Porównanie algorytmów kompresji 7z

Słupki - rozmiar danych; linia - czas kompresji

Algorytm

Ro

zmia

r w

ynik

ow

eg

o p

liku

[MB

]

Cza

s o

pe

racj

i [s

]

Page 68: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.5 Testy kompresji

Poziom

kompresji

Wielkość wynikowego

pliku [MB]

Czas kompresji [s]

1 2,169157 33,6

2 2,169157 32,91

3 2,189573 39,62

4 2,189573 39,24

5 2,061675 69,2

6 2,061675 71,68

7 2,061796 68,52

8 2,061796 68,48

9 2,061796 72,03Tab 4.6: Porównanie predefiniowanych poziomów kompresji 7z

Kolejny test pokazuje wpływ parametru MFB (Fast Bytes), który określa ilość tzw. szybkich bajtów wykorzystywanych w algorytmie. Domyślnie ustawiany jest na 64. W teorii, większe wartości pozwalają uzyskać lekko lepsze stosunki kompresji. Większe wartości powinny dawać lepsze rezultaty zwłaszcza w przypadku kompresji plików posiadających długie, identyczne sekwencje bajtów. Jak pokazuje tabela 4.7, nie uzyskano praktycznie żadnej znaczącej różnicy w wynikach operacji kompresji. Jest to naturalne, gdyż dane podlegające kompresji odpowiada mocno zaszumionemu sygnałowi. Szum ten nie pozwala uzyskać jednakowych, długich ciągów bajtów. Drobne, nieznaczne różnice

68

1 2 3 4 5 6 7 8 91,95

2

2,05

2,1

2,15

2,2

2,25

0

10

20

30

40

50

60

70

80

Porównanie predefiniowanych poziomów kompresji 7z

Poziom kompresji

Wie

lko

ść

wyn

iko

we

go

plik

u [M

B]

Cza

s o

pe

racj

i [s

]

Page 69: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.5 Testy kompresji

należy interpretować jako zbieg okoliczności niż sukces dobranego parametru.

MFB Wielkość wynikowego pliku [MB] Czas kompresji [s]

8 2,061668 68,99

12 2,061845 69,92

16 2,061887 71,01

24 2,061849 68,9

32 2,061675 69,22

48 2,060152 69,46

64 2,061796 68,22

96 2,061262 72,15

128 2,061252 68,59

256 2,060343 68,86

273 2,060107 69,16Tab 4.7: Wpływ parametru tzw. szybkich bajtów (MFB) na operację kompresji

Ostatnim parametrem branym pod uwagę podczas testów kompresji 7z był rozmiar słownika (MD). Parametr ten powinien pozwalać na uzyskanie lepszych stosunków kompresji przy wydłużonym czasie operacji kompresji. Podczas dekompresji skompresowanego pliku ze słownikiem o rozmiarze N algorytm potrzebuje N*2 pamięci. W przypadku testowanego pliku rozmiar praktycznie się nie zmieniał. Jedynie wyjątkowo mały słownik (64k) pozwolił uzyskać odrobinę mniejszy rozmiar wynikowego pliku jednak znów należy doszukiwać się zbiegu okoliczności niż znaczącego wpływu parametru wielkości słownika na dane o takim charakterze.

69

8 12 16 24 32 48 64 96 128 256 2732,0590

2,0595

2,0600

2,0605

2,0610

2,0615

2,0620

2,0625

66

67

68

69

70

71

72

73

Wpływ parametru tzw. szybkich bajtów (MFB) na operację kompresji

Słupki - rozmiar danych; linia - czas kompresji

Rozmiar MFB

Wie

lko

ść

wyn

iko

we

go

plik

u [M

B]

Cza

s k

om

pre

sji

[s]

Page 70: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.5 Testy kompresji

MD Wielkość wynikowego pliku [MB] Czas kompresji [s]

64k 2,040667 53,57

1m 2,059771 67,58

2m 2,062028 71,97

4m 2,061675 69,4

6m 2,061675 68,61

8m 2,061675 69,16

12m 2,061675 67,65

16m 2,061675 68,14

24m 2,061675 71,19

32m 2,061675 69,04Tab 4.8: Wpływ wielkości słownika (MD) na operację kompresji

4.6 Pomiary wykorzystywanych zasobów sprzętowych

Do testów wykorzystano przeglądarkę Chrome. W przypadku wykorzystanych zasobów opisywanych niżej, rozróżniono trzy sytuacje:

• Działa tylko symulator lub urządzenie pomiarowe – do systemu nie są podłaczeni żadni klienci;

• Typowe zachowanie użytkownika na jednej otwartej stronie – do systemu

podłączony jest jeden klient używający przeglądarki internetowej, użytkownik

nawiguje w sposób typowy interfejs graficzny;

70

64k 1m 2m 4m 6m 8m 12m 16m 24m 32m2,025

2,030

2,035

2,040

2,045

2,050

2,055

2,060

2,065

0

10

20

30

40

50

60

70

80

Wpływ wielkości słownika (MD) na operację kompresji

Słupki - rozmiar danych; linia - czas kompresji

Wielkość słownika [B]

Wie

lko

ść

wyn

iko

we

go

plik

u [M

B]

Page 71: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.6 Pomiary wykorzystywanych zasobów sprzętowych

• 5 Otwartych okien z wykresami – otwartych jest pięc zakładek z różwnych

przeglądarek, a na każdej z nich otwarta jest zakładka z wykresami jako

najintensywniej wykorzystująca system CREM.

Tabela 4.9 pokazuje poziom zużycia pamięci operacyjnej przez poszczególne moduły systemu CREM. Na różnych platformach obserwowano podobne wielkości. Jedynie zajętość pamięci przez moduł CREM-www różniła się znacząco w zależności od używanej przeglądarki internetowej. Wyniki pokazują, że CREM-sim i CREM-sender mają niezmienne zużycie pamięci, a CREM-server zwiększa ilość zużywanych zasobów wraz ze wzrostem liczby podłączonych klientów.

W przypadku modułu CREM-www obserwowane wielkości były najbardziej zmienne. Wiąże się to ze sposobem zarządzania aplikacjami napisanymi w języku JavaScript. Alokacji pamięci następuje automatycznie, a do dealokacji wykorzystywany jest mechanizm odśmiecania.

Sytuacja CREM-sim CREM-sender CREM-server CREM-www

Działa tylko symulator 5,8 MB 5,4 MB 9,2MB n.d.

Typowe zachowanie użytkownika

na jednej otwartej stronie

5,8 MB 5,4 MB 11,2 MB 28MB

5 otwartych okien z wykresami 5,8 MB 5,4 MB 13,5 MB 56MB*

Tab 4.9: Wykorzystanie pamięci wybranych modułów systemu CREM* - dane dotyczą jednego okna przeglądarki

Tabela 4.10 przedstawia poziom zużycia procesora przez moduły systemu CREM. Widać, że moduł komunikacji z „chmurą” (CREM-sender) nie wymaga dużo czasu procesora. Średnia wartość na poziomie jednego procenta jest nieznacząca. Warto jednak zauważyć, iż w czasie intensywnego działania, moduł chwilowo wykorzystuje procesor w sposób możliwie największy. Trwa to wprawdzie krótko (poniżej sekundy), jednak warto z tego powodu nadać modułowi niski priorytet. CREM-sender nie ma ograniczeń czasowych w związku ze swoim wykonywaniem.

Poziom wykorzystania czasu procesora przez pozostałe moduły jest silnie uzależniony od liczby podłączonych modułów CREM-www. Warto zauważyć, iż przy pięciu podłączonych klientach z otwartymi najbardziej intensywnymi zakładkami strony (wykresy) wykorzystanie procesora na systemie wbudowanym rośnie do 100%. Obserwuje się opóźnienia odpowiedzi modułu CREM-server do CREM-www. Jest to związane, po prostu, ze zbyt małymi zasobami sprzętowymi (konkretnie procesora) na systemie wbudowanym. Na szczęście sytuacja testowa tego typu nie powinna mieć miejsca ze względu na sposób korzystania z systemu FOSREM.

71

Page 72: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.6 Pomiary wykorzystywanych zasobów sprzętowych

Sytuacja Obciążenie CPU [%]

CREM-sim CREM-sender CREM-server

Działa tylko symulator minimalne 22,0 0,0 0

średnie 22,4 0,4 0,1

maksymalne 23,1 97,4 0,3

Typowe zachowanie

użytkownika na jednej

otwartej stronie

minimalne 44,3 0,0 21,3

średnie 48,2 0,7 26,2

maksymalne 52,1 98,2 28,3

5 otwartych okien z

wykresami

minimalne 58,1 0,0 32,4

średnie 59,6 0,9 34,1

maksymalne 60,7 97,6 40,3Tab 4.10: Obciążenie wybranych modułów systemu CREM na systemie wbudowanym

Wykonano również szereg testów na maszynie wirtualnej. Tabela 4.11 przedstawia analogiczne wyniki jak tabela 4.10. W przypadku modułu CREM-sim widać, że ogólne obciążenie procesora tym modułem jest niewysokie, poniżej 2%. Maszyna wirtualna na której przeprowadzane były testy posiada procesor o taktowaniu aż 3,6GHz, więc generacja danych, ich zapis nie są szczególnie obciążające. Widać pewien wzrost obciążenia tego modułu przy wielu podłączonych klientach. Wzrost ten bierze się z konieczności obsłużenia większej ilości żądań niż w pozostałych przypadkach.

Nieco inaczej przestawia się sytuacja z modułem CREM-server. Gdy działa tylko symulator, a nie jest podłączony żaden klient, serwer HTTP nie musi przyjmować żądań. W przypadku jednego klienta, średnie zużycie procesora przez CREM-serwer nieznacznie rośnie, jednak maksymalne wzrosło do 4,7%. Maksymalna wartość odbiega od średniej, gdyż żądania od CREM-www przychodzą sporadycznie. Inaczej wygląda sytuacja z 5 klientami z otwartymi witrynami na zakładce wykresów. Wtedy zapytania napływają dosyć często i CREM-server zużywa średnio 15% czasu procesora.

Zużycie modułu CREM-sender z kolei większość czasu jest na znikomym poziomie (gdyż aplikacja nie musi nic wysyłać). Tylko co jakiś czas aplikacja jest wykonywana i informacje o konfiguracji urządzenia pomiarowego lub wykrytych zdarzeniach są wysyłane do „chmury”.

72

Page 73: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.6 Pomiary wykorzystywanych zasobów sprzętowych

Sytuacja Obciążenie CPU [%]

CREM-sim CREM-sender CREM-server

Działa tylko symulator minimalne 0,7 0,0 0,0

średnie 1,0 0,1 0,1

maksymalne 1,3 1,3 0,3

Typowe zachowanie

użytkownika na jednej

otwartej stronie

minimalne 1,0 0,0 0,0

średnie 1,2 0,5 0,2

maksymalne 1,7 2,7 4,7

5 otwartych okien z

wykresami

minimalne 2,0 0,0 14,2

średnie 2,0 0,1 15,3

maksymalne 2,3 1,3 16,3Tab 4.11: Obciążenie wybranych modułów systemu CREM na maszynie wirtualnej

Do analizy zużywanych zasobów przez moduł CREM-www wykorzystano program Process Explorer (patrz punkt 4.3). Ilustracja 4.8 pokazuje zużycie procesora, pamięci operacyjnej i pracy na pamięci masowej na maszynie A. W przypadku czasu procesora, na początku wykresu widać dosyć duży (19,3 – 25,2%) poziom zużycia zasobu. Jest to czas, w którym wyświetlony był fragment witryny z rysowanymi na bieżąco wykresami. Widać, że przetwarzanie odebranych danych oraz umieszczenie ich na wykresie jest zajmujące dla procesora. Zużycie pamięci w tym czasie rośnie do poziomu około 56 MB.

W środkowej części wykresów zużycie procesora wynosi od 0,4 do 4,7%. Odpowiada to typowemu korzystaniu z interfejsu graficznego. Zużycie pamięci nie rośnie. W ostatniej części wykresu zużycie procesora, wynoszące 0,0 – 0,2% obrazuje witrynę internetową służącą tylko do wyświetlania danych. Witryna w tym czasie tylko co jakiś czas wysyła zapytanie do serwera I przetarza je. W tym okresie widać znaczny spadek zużycia pamięci z 56 MB do 28MB. Jest to moment, w którym wykonywane jest odśmiecanie pamięci przez przeglądarkę Chrome. Na ostatnim z trzech wykresów widać, że przeglądarka wykorzystuje dysk twardy. Zwłaszcza podczas interakcji użytkownika I manipulacji na danych.

73

Page 74: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.6 Pomiary wykorzystywanych zasobów sprzętowych

Tabela 4.12 przedstawia czas operacji przetwarzania otrzymanych danych pomiarowych dla 3 wykresów oraz ich rysowania na wykresach. Widać, że maszyny A oraz B nie mają problemów z szybkim (praktycznie niezauważalnym dla człowieka) wykonaniem tych operacji. Jedynie na maszynie D (tablet) średni czas operacji wynosi 198 ms. Nie jest to wprawdzie dużo, ale patrząc na czas maksymalny wynoszący 380 ms, należy brać pod uwagę, że na niektórych urządzeniach typu tablet operacje te będą zauważalne przez człowieka. Tj. obserwowany będzie brak odpowiedzi na interakcje użytkownika wynoszący do 380 ms. Gdyby to okazało się problemem, zawsze można zmniejszyć ilość punktów przetwarzanych i nanoszonych na wykres. Informacja na wykresie jest jedynie pomocnicza i pomaga w interpretacji wyników liczbowych w pozostałych kontrolkach w interfejsie graficznym.

74

Ilustracja 4.8: Obciążenie systemu operacyjnego przez CREM-

www

Page 75: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.6 Pomiary wykorzystywanych zasobów sprzętowych

Maszyna Czas operacji [ms]

Maszyna A minimalne 50

średnie 53

maksymalne 83

Maszyna B minimalne 25

średnie 31

maksymalne 52

Maszyna D minimalne 127

średnie 198

maksymalne 380Tab 4.12: Czas wykonywania operacji przekształcania otrzymanych danych i rysowania 3 wykresów

za pomocą JavaScript

Tabela 4.13 przedstawia czas wykonywania miliona operacji konwersji liczby z formatu float do kodowania heksadecymalnego i odwrotnie w języku JavaScript. Widać wyraźną różnicę w czasie wykonywania tych dwóch typów konwersji. Zmiana zapisu heksadecymalnego na wartość liczbową jest kilkadziesiąt razy szybsza. Wiąże się to ze stosunkowo krótką w kodzie implementacją tej operacji. Implementacja operacji w drugą stronę (patrz punkt: 3.4.1) nie może być taka szybka. Konieczny jest szereg ciągów instrukcji w blokach warunkowych. Jest, chociażby, potrzeba sprawdzania, czy liczba nie jest przypadkiem wartością oznaczającą nieskończoność. Na szczęście, czasochłonna funkcja nie jest wykorzystywana dosyć często – praktycznie tylko przy wprowadzaniu danych przez użytkownika, które należy przekonwertować do postaci heksadecymalnej – przyjmowanej przez urządzenie pomiarowe.

FloatToHex [s] HexToFloat [s]

Maszyna A 12,432 0,271

Maszyna B 4,914 0,101

Maszyna D 434,150 8,324Tab 4.13: Czas miliona operacji konwersji w języku JavaScript

75

Page 76: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

4.7 Stopień wykorzystania łącza sieciowego

4.7 Stopień wykorzystania łącza sieciowego

W ramach testów, sprawdzono poziom wykorzystanego łącza sieciowego z pomocą narzędzia iftop. Tabela 4.14 przedstawia mierzone wielkości. Wartości są interpretowane z poziomu modułu CREM-www, czyli pobieranie oznacza transfer danych z systemu wbudowanego do podłączonego klienta w postaci przeglądarki www. Wysyłanie – odwrotnie. Przy pięciu otwartych oknach na zakładkach z wykresami widać dosyć spore wykorzystanie łącza. Sumarycznie (w obie strony) wynosi ono średnio około 180kb/s. W dobie szybkich, rzędu dziesięciu megabitowych łączy, wydaje się to wciąż mało. Warto jednak zauważyć, iż będąc podłączonym przez wolne (np. starszej generacji transmisja w oparciu o GSM) może to stanowić pewne ograniczenie.

Sytuacja Wykorzystane pasmo [kb/s]

Pobieranie Wysyłanie

Typowe zachowanie użytkownika na

jednej otwartej stronie

minimalne 2,3 0,15

średnie 2,8 0,16

maksymalne 2,9 0,22

1 otwarte okno z wykresami minimalne 33,7 8,44

średnie 35,2 8,91

maksymalne 35,7 9,02

5 otwartych okien z wykresami minimalne 125 35,1

średnie 140 39,1

maksymalne 142 41,3Tab 4.14: Poziom wykorzystywanego łącza sieciowego

76

Maszyna A Maszyna B Maszyna D0

50

100

150

200

250

300

350

400

450

500

Porównanie wykonania miliona operacji konwersji w języku JavaScript

FloatToHex [s]

HexToFloat [s]

Cza

s o

pe

racj

i [s

]

Page 77: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

5 Podsumowanie

5 Podsumowanie

Temat pracy magisterskiej wybrałem ze względu na idealną zgodność tematyki mnie interesującej (systemy wbudowane) oraz możliwość opracowania systemu, który zostanie użyty w sposób praktyczny i pożyteczny.

W efekcie przeprowadzonych prac przeanalizowałem dostępne metody komunikacji, a następnie opracowałem system CREM. Autorski system realizuje złożoną komunikację pomiędzy urządzeniem pomiarowym a serwerem znajdującym się w „chmurze” obliczeniowej lub użytkownikiem. Dostęp dla użytkownika do systemu wykonałem na dwa sposoby: dla końcowego użytkownika udostępniono graficzny interfejs użytkownika (GUI), a dla serwisanta utworzyłem uproszczony kanał diagnostyczny.

System CREM umożliwia wygodną pracę z systemem pomiarowym FOSREM. Udostępnia graficzny interfejs użytkownika w oparciu o język HTML, którego uniwersalność pozwala na nadzorowanie pracy urządzenia pomiarowego z poziomu dowolnego urządzenia mobilnego wyposażonego w przeglądarkę internetową. Takimi urządzeniami może być komputer klasy PC, urządzenie typu tablet, lub nawet zaawansowany telefon (smartphone). Uniwersalność i mobilność są ważnymi atutami każdego współczesnego systemu informatycznego.

System CREM zbudowałem w oparciu o szereg różnych języków programistycznych, narzędzi i bibliotek. Wewnętrznie, budowę zrealizowałem w sposób modułowy. Istnieje wyraźne rozdzielenie funkcjonalności zapewnionych przez oddzielne moduły. Umożliwiło to łatwe i szybkie znajdywanie źródeł napotykanych problemów i błędów. Ponadto, modułowość pozwala na łatwą wymianę jednej części systemu i zamianę ją na inną bez konieczności modyfikacji pozostałej części systemu. Moduły komunikują się w oparciu o różnorodne techniki komunikacji międzyprocesowej i sieciowej. Wykorzystałem m.in. semafory, pamięć współdzieloną, mechanizm gniazd, zapytania HTTP, GPS oraz technologię VPN. Każdą metodę starannie dobrałem uwzględniając szeroką gamę aspektów, m.in. szybkość komunikacji, realizację wymogów, możliwie nieskomplikowaną implementację, niezawodność metody jak i bezpieczeństwo transmisji.

Kod systemu stworzyłem zgodnie z konwencjami każdego z języków. Jest czytelny i zrozumiały. Również sam interfejs graficzny został przeze mnie podzielony na odrębne elementy. Pozwala to na łatwą oraz intuicyjną pracę z interfejsem użytkownika. Zaprojektowałem i przeprowadziłem szereg testów mających za zadanie weryfikację poprawności pracy każdego z opracowanych modułów oraz sprawdzenie, czy szybkość pracy całego systemu CREM jest zadowalająca.

Opracowany system spełnia wszystkie postulaty wymienione w założeniach. Różne biblioteki i języki są przystosowane do różnych typów aplikacji oraz funkcji. Udana realizacja systemu CREM pokazuje, że, w dzisiejszych czasach, w celu szybkiej i wygodnej realizacji złożonego systemu informatycznego, niezbędna jest znajomość szeregu narzędzi i języków programistycznych.

77

Page 78: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

Bibliografia

Bibliografia

[1] DSPLink Overview, http://processors.wiki.ti.com/index.php/DSPLink_Overview,

dostęp 16.08.2013

[2] Peter Marwedel, Embedded System Design, Springer 2006

[3] Richard Zurawski, Embedded Systems: Handbook, Boca Raton 2006

[4] Łukasz Skalski, Linux: podstawy i aplikacje dla systemów embedded, Wydawnictwo

BTC 2012

[5] Marcin Bis, Linux w systemach embedded, Wydawnictwo BTC 2011

[6] Critical Link, MityDSP-L138F Datasheet, Critical Link 2012

[7] MityDSP-L138 Architecture, http://support.criticallink.com/redmine/projects/arm9-

platforms/wiki/MityDSP-L138_Architecture, dostęp 21.05.2013

[8] Das U-Boot -- the Universal Boot Loader, http://www.denx.de/wiki/U-Boot, dostęp

06.08.2013

[9] Henryk Kowalski, Grzegorz Mazur, System FOSREMv1.0 Opis techniczny, 2013

[10] The Ångström Distribution, http://www.angstrom-distribution.org/, dostęp 16.08.2013

[11] Henryk Kowalski, Grzegorz Mazur, FOSREM Schemat komunikacji Aplikacja ARM

DSP v1 - obsługiwane polecenia, 2013

[12] Warstwy modelu ISO/OSI, http://www.man.poznan.pl/~pawelw/dyplom/layers.html ,

dostęp 06.08.2013

[13] Jan Axelson, Serial port complete: COM ports, USB virtual COM ports and ports for

embedded systems, Lakeview Research 2007

[14] USB Specification, http://www.usb.org/developers/docs/, dostęp 21.06.2013

[15] Martin Sauter, From GSM to LTE: an introduction to mobile networks and mobile

broadband, John Wiley and Sons 2011

[16] IEEE 802.11™: Wireless LANs, http://standards.ieee.org/about/get/802/802.11.html ,

dostęp 21.06.2013

[17] Igor Piotr Kurytnik, Mikołaj Karpiński, Bezprzewodowa transmisja informacji,

Wydawnictwo Pomiary Automatyka Kontrolna 2008

[18] Zastosowanie i zalety sieci bezprzewodowych, http://strefawifi.pl/56-Zastosowanie-i-

zalety-sieci-bezprzewodowych, dostęp 04.06.2013

[19] Jacek Januszewski, Systemy satelitarne GPS, Galileo i inne, Wydawnictwo Naukowe

PWN 2010

[20] Poziomy dokładności GPS, http://sadzik.w.interia.pl/dokladn.htm, dostęp 05.05.2013

[21] TELNET PROTOCOL SPECIFICATION, http://tools.ietf.org/html/rfc854, dostęp

01.09.2013

[22] Marek Serafin, Sieci VPN: zdalna praca i bezpieczeństwo danych, Helion 2010

[23] Phil Ballard, Michael Moncur, Sams teach Yourself Ajax, JavaScript, and PHP all in

78

Page 79: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

Bibliografia

one, SAMS 2008

[24] Hypertext Transfer Protocol -- HTTP/1.1,

http://www.w3.org/Protocols/rfc2616/rfc2616.html, dostęp 12.07.2013

[25] Ile stron internetowych jest na świecie?,

http://www.komputerswiat.pl/nowosci/internet/2012/11/ile-stron-internetowych-jest-

na-swiecie.aspx , dostęp 12.07.2013

[26] Apache, http://www.apache.org/, dostęp 12.07.2013

[27] nginx, http://nginx.org/en/, dostęp 12.07.2013

[28] Home - Lighttpd - fly light, http://www.lighttpd.net/, dostęp 12.07.2013

[29] HTML5. Tworzenie gier, , dostęp

[30] Michale Bowers, HTML5 i CSS3: zaawansowane wzorce projektowe, Helion 2013

[31] CSS3 - transitions, http://ferrante.pl/frontend/vademecum/css3-transitions/, dostęp

12.07.2013

[32] PHP: Hypertext Preprocessor, http://php.net/, dostęp 12.07.2013

[33] Jacek Ross, PHP i HTML: tworzenie dynamicznych stron WWW , Helion 2010

[34] , https://developer.mozilla.org/en-US/docs/Web/JavaScript, dostęp 12.07.2013

[35] The application/json Media Type for JavaScript Object Notation (JSON),

http://tools.ietf.org/html/rfc4627, dostęp 12.08.2013

[36] JSON - Introduction, http://www.w3schools.com/json/json_intro.asp, dostęp

16.08.2013

[37] JSON vs. XML: Some hard numbers about verbosity,

http://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-

about-verbosity, dostęp 16.08.2013

[38] Android Developers, http://developer.android.com/index.html, dostęp 03.08.2013

[39] 500 milionów urządzeń z Androidem aktywowanych na całym świecie,

http://www.dobreprogramy.pl/500-milionow-urzadzen-z-Androidem-aktywowanych-

na-calym-swiecie,News,36115.html, dostęp 03.08.2013

[40] Co to jest VPN?, http://technet.microsoft.com/pl-pl/library/cc731954(v=ws.10).aspx,

dostęp 06.08.2013

[41] DEFINITION thin client (lean client),

http://searchnetworking.techtarget.com/definition/thin-client, dostęp 16.08.2013

[42] Pakiety i źródła - instalacja oprogramowania,

http://www.linuxportal.pl/linux_podstawy/instalacja_programow/pakiety_i_zrodla_in

stalacja_oprogramowania.html, dostęp 16.08.2013

[43] Pluggable Authentication Modules, http://www.freebsd.org/doc/en/articles/pam/,

dostęp 20.08.2013

[44] Apache Http Server Project, http://httpd.apache.org/, dostęp 16.08.2013

79

Page 80: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

Bibliografia

[45] PHP: Hypertext Preprocessor, http://php.net/, dostęp 20.08.2013

[46] Welcome to the P7ZIP Home, http://p7zip.sourceforge.net/, dostęp 16.08.2013

[47] Python 2.7, http://www.python.org/download/releases/2.7/, dostęp 16.08.2013

[48] Network Time Protocol (NTP) daemon, http://doc.ntp.org/4.1.0/ntpd.htm, dostęp

16.08.2013

[49] gpsd — a GPS service daemon, http://gpsd.berlios.de/, dostęp 16.08.2013

[50] Czy HTML to język programowania,

http://www.publikuj.org/czy_html_to_jezyk_programowania_9000.html , dostęp

16.08.2013

[51] Porównanie wydajności nginx vs Apache,

http://www.znaminet.pl/nowosci/2009/06/22/porownanie-wydajnosci-nginx-vs-

apache/, dostęp 16.08.2013

[52] Documentation - filesystems - ramfs-rootfs-initramfs,

http://www.mjmwired.net/kernel/Documentation/filesystems/ramfs-rootfs-

initramfs.txt, dostęp 22.08.2013

[53] HTML5 New Elements, http://www.w3schools.com/html/html5_new_elements.asp,

dostęp 22.08.2013

[54] Hypertext Transfer Protocol -- HTTP/1.1 Status Code Definitions,

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html, dostęp 22.08.2013

[55] Understanding and configuring PAM, http://www.ibm.com/developerworks/library/l-

pam/, dostęp 22.08.2013

[56] jQuery, http://jquery.com/, dostęp 23.08.2013

[57] Flotr2 Documentation, http://www.humblesoftware.com/flotr2/documentation, dostęp

23.08.2013

[58] Swiper - Mobile touch slider & framework with hardware accelerated transitions,

http://www.idangero.us/sliders/swiper/index.php, dostęp 23.08.2013

[59] Tworzenie sieci VPN w środowisku Linux i Windows,

http://wazniak.mimuw.edu.pl/images/6/60/Bsi_11_lab.pdf, dostęp 01.09.2013

[60] Python Documentation - struct, http://docs.python.org/2/library/struct.html, dostęp

16.08.2013

[61] PHP/PAM to change user password?,

http://stackoverflow.com/questions/3032785/php-pam-to-change-user-password,

dostęp 26.08.2013

[62] Firebug - Web Development Evolved, http://getfirebug.com/, dostęp 25.08.2013

[63] Browser Shots, http://browsershots.org/, dostęp 25.08.2013

[64] W3C Markup Validation Service, http://validator.w3.org/, dostęp 26.08.2013

[65] Lynx, http://lynx.browser.org/, dostęp 26.08.2013

80

Page 81: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

Bibliografia

[66] Advanced Compression Parameters,

http://www.comprexx.com/UsrHelp/Advanced_Compression_Parameters_(7-

Zip_Archive_Type).htm, dostęp 26.08.2013

81

Page 82: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

Dodatek A: Zawartość CD

Dodatek A: Zawartość CD

• Katalog Praca dyplomowa:

◦ Plik Praca dyplomowa.pdf – plik zawierający treść pracy w formacie Portable Document Format

82

Page 83: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

Dodatek B: Spis ilustracji

Dodatek B: Spis ilustracji

Ilustracja 2.1: Moduł procesorowy MityDSP-L138F włożony do Industrial I/O Board.....16

Ilustracja 2.2: Schemat blokowy MityDSP-L138F..............................................................17

Ilustracja 2.3: Domyślna mapa pamięci nieulotnej MityDSP-L138F..................................18

Ilustracja 2.4: Sekwencja startowa MityDSP-L138F...........................................................18

Ilustracja 2.5: Przykład konwersji liczby na dziesiętnej na heksadecymalny zapis liczby

zmiennoprzecinkowej pojedynczej precyzji.................................................20

Ilustracja 2.6: Przykładowe urządzenia z systemem Android..............................................34

Ilustracja 3.1: Schemat współpracy modułów systemu CREM z wykorzystaniem

docelowego systemu wbudowanego.............................................................38

Ilustracja 3.2: Schemat współpracy modułów systemu CREM z wykorzystaniem maszyny

wirtualnej......................................................................................................39

Ilustracja 3.3: Widok witryny internetowej - część logowania............................................42

Ilustracja 3.4: Widok witryny internetowej - część konfiguracyjna.....................................43

Ilustracja 3.5: Widok witryny internetowej - część z wykresami.........................................44

Ilustracja 3.6: Przykładowy sygnał obrazujący symulowane zdarzenie..............................46

Ilustracja 3.7: Udostępniony folder z plikami poprzez serwer Apache................................48

Ilustracja 3.8: Moduł CREM-www uruchomiony na urządzeniu dotykowym....................50

Ilustracja 4.1: Widok kontrolki w przeglądarce MSIE.........................................................60

Ilustracja 4.2: Widok kontrolki w przeglądarce Chrome.....................................................60

Ilustracja 4.3: Widok kontrolki w przeglądarce Firefox.......................................................60

Ilustracja 4.4: Przykład użycia Developer Tools w aplikacji Chrome.................................62

Ilustracja 4.5: Zrzut wyniku działania witryny Browser Shots............................................63

Ilustracja 4.6: Wynik usługi W3C Markup Validation Service............................................63

Ilustracja 4.7: Widok witryny internetowej w przeglądarce Lynx.......................................64

Ilustracja 4.8: Obciążenie systemu operacyjnego przez CREM-www................................74

83

Page 84: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

Dodatek C: Spis tabel

Dodatek C: Spis tabel

Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM.......................................9

Tab 2.1: Przykłady systemów operacyjnych........................................................................13

Tab 2.2: Polecenia grupy B..................................................................................................21

Tab 2.3: Polecenia grupy C..................................................................................................21

Tab 2.4: Polecenia grupy H..................................................................................................22

Tab 2.5: Polecenia grupy K..................................................................................................22

Tab 2.6: Polecenia grupy Q..................................................................................................22

Tab 2.7: Polecenia grupy X..................................................................................................22

Tab 2.8: Polecenia grupy Z...................................................................................................22

Tab 2.9: Porównanie niektórych cech wybranych interfejsów transmisji przewodowej;

podane wartości mogą się różnić w zależności od wersji interfejsu......................24

Tab 2.10: Transmisje bezprzewodowe wykorzystywane w telekomunikacji.......................27

Tab 4.1: Spełnienie postawionych wymagań przez system CREM.....................................59

Tab 4.2: Konfiguracje sprzętowe używane podczas testów.................................................61

Tab 4.3: Czas konwersji formatu HEX do formatu binarnego.............................................65

Tab 4.4: Porównanie formatów kompresji...........................................................................66

Tab 4.5: Porównanie algorytmów kompresji 7z...................................................................67

Tab 4.6: Porównanie predefiniowanych poziomów kompresji 7z.......................................68

Tab 4.7: Wpływ parametru tzw. szybkich bajtów (MFB) na operację kompresji................69

Tab 4.8: Wpływ wielkości słownika (MD) na operację kompresji......................................70

Tab 4.9: Wykorzystanie pamięci wybranych modułów systemu CREM.............................71

Tab 4.10: Obciążenie wybranych modułów systemu CREM na systemie wbudowanym...72

Tab 4.11: Obciążenie wybranych modułów systemu CREM na maszynie wirtualnej.........73

Tab 4.12: Czas wykonywania operacji przekształcania otrzymanych danych i rysowania 3

wykresów za pomocą JavaScript...........................................................................75

Tab 4.13: Czas miliona operacji konwersji w języku JavaScript.........................................75

Tab 4.14: Poziom wykorzystywanego łącza sieciowego.....................................................76

84

Page 85: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

Dodatek D: wykaz używanych skrótów i akronimów

Dodatek D: wykaz używanych skrótów i akronimów

AJAX Asynchronous JavaScript and XML

API Application Programming Interface

CA Certificate Authority

CGI Common Gateway Interface

CREM Communication for Rotational Event Monitoring

CSS Cascading Style Sheets

DOM Document Object Model

DSP Digital Signal Processing

FOSREM Fiber Optic Seismograph for Rotational Event Monitoring

FPGA Field Programmable Gate Array

FTP File Transfer Protocol

GPS Global Positioning System

GSM Global System for Mobile Communications

GUI Graphical User Interface

HDD Hard Disk Drive

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

IP Internet Protocol

IPC Inter-Process Communication

JSON JavaScript Object Notation

LAN Local Area Network

LZMA Lempel-Ziv-Markov chain-Algorithm

MAC Medium Access Control

MPU Micro-Processor Unit

NFS Network File System

PAM Pluggable Authentication Modules

PPS Precise Positioning Service

RAR Roshal Archieve

RTC Real-Time Clock

SCP Secure Copy

SPS Standard Positioning Service

85

Page 86: Sposoby komunikacji z systemami wbudowanymi czasu ... · Tab 1.1: Priorytety wymaganych funkcjonalności systemu CREM Ze względu na mnogość wymagań odnośnie systemu CREM, można

Dodatek D: wykaz używanych skrótów i akronimów

SSD Solid-State Drive

SSH Secure Shell

SSH-FS Secure Shell File System

SSL Secure Socket Layer

VPN Virtual Private Network

WAN Wide Area Network

WiFi Wireless Fidelity

WWW World Wide Web

XHTML Extensible Hypertext Markup Language

86