Stworzenie zintegrowanego, graficznego interfejsu

 Politechnika Warszawska Wydział Fizyki Praca inżynierska
Stworzenie zintegrowanego, graficznego interfejsu użytkownika systemów monitoringu i kontroli eksperymentu "Pi of the Sky"
Creating integreted graphical user interface for monitoring and control system of "Pi of the Sky" experiment
Maria Anna Ptasińska
Nr albumu: 200075
Praca wykonana pod kierunkiem
dr Krzysztof Nawrocki
Instytut Problemów Jądrowych im. Andrzeja Sołtana Zakład Fizyki Wielkich Energii
Opiekun pracy
dr inż. Przemysław Duda
Wydział Fizyki Politechniki Warszawskiej Warszawa 2009
Streszczenie
Celem pracy było zaprojektowanie i wykonanie interfejsu użytkownika sprawującego kontrolę nad urządzeniami działającymi w ramach eksperymentu "Pi of the Sky". Ze względu na to, że w projekt jest na etapie testów, konieczne było uwzględnienie w projekcie rozwoju eksperymentu. Położono nacisk na modułowość i skalowalność zastosowanych rozwiązań.
W rozdziale pierwszym przedstawiono krótki opis początków Wszechświata oraz główne założenia teorii Wielkiego Wybuchu wraz z jego eksperymentalnymi podstawami.
Rozdział drugi zawiera opis pomiaru pierwszego zarejestrowanego błysku promieniowania gamma oraz omówienie najważniejszych odkryć dotyczących badanego zjawiska.
W rozdziale trzecim zawarto opis projektu "Pi of the Sky". Projekt ten ma na celu badanie poświaty optycznej błysków promieniowania gamma. W rozdziale tym przedstawiono zarówno ogólne założenia projektu, jak również zadnia realizowane w poszczególnych etapach jego realizacji.
Rozdział czwarty zawiera opis wykonanego interfejsu użytkownika. Przedstawiono tutaj architekturę systemu kontroli eksperymentu oraz wymagania sprzętowo ­ projektowe. Interfejs wykonano w oparciu o środowisko Django. W projekcie wykorzystano również bibliotekę JavaScriptu JQuery.
W rozdziale piątym przedstawiono krótki opis działania parsera plików .ini do bazy danych.
Integralną część pracy pełnią załączniki. W załączniku pierwszym omówiono dodawanie nowych elementów do panelu monitoringu, co jest szczególnie ważne w sytuacji
ciągłego rozwoju projektu. Przyjęte rozwiązanie umożliwia dodawanie nowych
elementów interfejsu poprzez uzupełnianie odpowiednich tabel w bazie danych. Dane zawarte w bazie danych są dynamicznie wyświetlane za pomocą odpowiednich funkcji napisanych przy użyciu bibliotek JQuery. Dynamiczne wyświetlanie na stronie jest dokładnie omówione w załączniku drugim. Znajduje się tam również opis funkcji odpowiedzialnych za odświeżanie danych. W załączniku trzecim omówiono możliwości panelu administratora. Jest to narzędzie umożliwiające między innymi graficzny podgląd bazy danych i jej edytowanie.
Załącznik czwarty zawiera kod przygotowanego parsera plików .ini.
Summary
The main purpose of this work was to design and create the user interface to control and monitor devices used by the “Pi of the Sky” experiment.
Due to the fact that the experiment is still under development it was essential to pay special attention to modularity and scalability of methods used. In Chapter 1 the short introduction to the evolution of the Universe is presented. In particular main assumptions of the Big Bang theory together with its experimental foundations are discussed.
The second chapter is devoted to the history of observations of Gamma Ray Bursts and key discoveries in this field.
In the third Chapter the “Pi of the Sky” project is described. The aim of the project is to examine the optical afterglow of gamma ray bursts. This chapter also contains general assumptions of the project and tasks to be performed in its future development phases.
Fourth chapter contains description of the user interface created by the author. The architecture of the experiment's control system, devices and programs are also being discussed here.
Chapter 5 describes the functionality of the parser used for converting current system status files to the new monitoring system.
Details of the project are described in four appendices. The first one presents the process of adding new parts to the monitoring panel. It is of a crucial importance due to the ongoing development of the project. The method of adding new parts consists of adding new interface elements by filling the relevant tables in the database. The data contained in the database are simultaneously displayed by the functions written with the use of JQuery libraries. The simultaneous displaying of the data is described in details in the second appendix. The appendix contains also the description of the functions used for updating the data. In the third appendix the administrator panel functions are described. It is a device which enables, among others, the graphical view of the database tables and its editing. The fourth appendix contains the code of the parser used for parsing current system status files.
Spis treści Wstęp..............................................................................................................
1. Początki Wszechświata...............................................................................
1.1 Wielki Wybuch i pierwsze chwile po wybuchu............................
2. Błyski Gamma...........................................................................................
2.1 Historia odkryć błysków gamma..................................................
3. Projekt „Pi of the Sky” .............................................................................
3.1 Założenia projektu........................................................................ 3.2 Realizacja projektu ......................................................................
3.3 Największe osiągnięcie projektu..................................................
4. Graficzny interfejs monitoringu i kontroli eksperymentu..........................
4.1 Architektura kontroli systemu eksperymentu...............................
4.2 Django ­ monitoring poprzez stronę WWW.................................
4.2.1 Tworzenie projektu.........................................................
4.2.2 Główne ustawienia projektu plik settings.py.................
4.3 Apache..........................................................................................
4.4 Wymagania sprzętowo ­ programowe ............................................
4.5 Przepływ danych i aktualizacja danych na stronie www..............
5. Parser danych.............................................................................................
Załącznik nr 1
Aktualizacja panelu monitoringu...................................................... Załącznik nr 2
Dynamiczne wyświetlanie strony.......................................................
Załącznik nr 3
Panel administratora...........................................................................
Załącznik nr 4
Parser..................................................................................................
Bibliografia....................................................................................................
Wstęp
Ludzie od wieków próbują zrozumieć otaczający ich świat. Szukają sposobu wytłumaczenia zachodzących wokół nich zjawisk. Nieprzemijającym marzeniem kolejnych pokoleń jest zostawienie świata prostszym i lepiej zrozumiałym dla kolejnych generacji. Początkowo ludzie czerpali informacje o otaczającym ich świecie głównie za pomocą własnych zmysłów. Coraz lepsza i ciągle rozwijana aparatura badawcza odkrywa przed nami rzeczywistość niedostępną dla naszych poprzedników. Jest to pewnego rodzaju paradoksem, gdyż próbując wytłumaczyć znane nam zjawiska, przy wykorzystaniu coraz bardziej zaawansowanej aparatury, odkrywamy nowe procesy, których nie jesteśmy w stanie wytłumaczyć. Wiele spośród starożytnych cywilizacji traktowało widoczne nocą niebo jako coś niezmiennego. Próbowano określić miejsce Ziemi we Wszechświecie i zrozumieć cykliczne zmiany zachodzące na sferze niebieskiej. Podejmowano się nawet prób przewidywania niektórych zjawisk, takich jak pojawienie się komet, czy zaćmień Słońca i Księżyca. Później widoczne na niebie zmiany położenia niektórych obiektów próbowano tłumaczyć w sposób deterministyczny, w oparciu o prawa mechaniki. Jednak prowadzenie coraz bardziej wnikliwych obserwacji przy użyciu coraz lepszej aparatury spowodowało, że sprawy zaczęły się komplikować. To, co wcześniej wydawało się być trwałe, okazało się podlegać ciągłym zmianom. Okazało się, że Wszechświat nie jest statyczny, lecz wręcz kipi od zachodzących w nim zjawisk. Problemem są tylko nasze możliwości obserwacyjne. Jednym z przypadkowo zaobserwowanych zjawisk, które zmusiły naukowców do podjęcia nowych badań, jest odkrycie silnych błysków gamma promieniowania kosmicznego. Błyski te zostały po raz pierwszy zarejestrowane przez amerykańskie satelity szpiegowskie. Choć od ich pierwszej detekcji upłynęło już ponad 40 lat sprawa ich pochodzenia jest ciągle kwestią otwartą. Obecnie na całym świecie liczne grupy badawcze próbują poznać naturę tego zjawiska. Jedną z polskich prób w rozwiązaniu tej zagadki jest projekt "Pi of the Sky". Realizowany jest on przez pracowników Instytutu Problemów Jądrowych (IPJ) im. Andrzeja Sołtana oraz liczne uczelnie warszawskie. Mimo że realizowany jest bez potężnych nakładów finansowych, ma na swoim koncie odkrycia na skalę światową. Najważniejszym z nich jest bezpośrednia obserwacja widma optycznego błysku GRB 080319B.
Głównym celem mojej pracy inżynierskiej było przygotowanie interfejsu użytkownika sprawującego kontrolę nad projektem w czasie conocnych szycht. Według założeń aparatura projektu sterowana jest zdalnie. Program pracy na daną noc przesyłany jest w postaci skryptu. Dodatkowo aparatura reaguje na alerty z sieci GCN [8]. Chociaż wydawać by się mogło, że wszystko działa bez udziału człowieka, niezbędna jest jego stała kontrola. Każdej nocy jeden z członków zespołu pełni dyżur, analizując logi wysyłane przez układ. Poprzez konsolę Pi­shell możliwe jest połączenie poprzez Eternet ze sprzętem działającym w Chile. Forma w jakiej prezentowane są logi nie jest obecnie zbyt przyjazna użytkownikowi. Celem pracy było przygotowanie interfejsu, dzięki któremu możliwe byłoby łatwe kontrolowanie tego co dzieje się w eksperymencie. Obecnie, informacje o działaniu sprzętu zapisywane są w postaci plików formatu .ini, co 5 min., na dysku komputera w IPJ na Hożej w Warszawie. Jednym z pobocznych zadań zrealizowanych podczas pisania tej pracy było wykonanie parsera, który umożliwi przeniesienie archiwalnych danych do nowopowstałej bazy. Daje to możliwość zgromadzenia pełniejszej informacji o działaniu sprzętu. Jest to ważne, gdyż aparatura jest ciągle na etapie testów. 1. Początki Wszechświata Najbardziej fundamentalne wydaje się być pytanie o początki Wszechświata. Obecnie nauka skłania się ku teorii tzw. Wielkiego Wybuchu. Najważniejszym założeniem tej teorii jest to, że Wszechświat nie istniał od zawsze i nie jest statyczny. Wiek Wszechświata jest szacowany na ok. 12­15 mld lat.
Wątpliwości co do statyczności Wszechświata wyrażał już Isaac Newton. Według jego odkryć ciała przyciągają się siłą proporcjonalną do masy a odwrotnie proporcjonalną do kwadratu odległości między nimi. Wynika z tego, że również gwiazdy przyciągają się wzajemnie. Problem przyciągających się gwiazd nie został wytłumaczony ani przez Newtona ani przez współczesnych mu uczonych.
Ciekawy problem, wyrażający wątpliwość, co do niezmienniczości Wszechświata postawił niemiecki astronom Heinrich Wilhelm Olbers (1758­1840). Zapytał on dlaczego niebo jest ciemne skoro Wszechświat jest nieskończony a gwiazdy równomiernie rozmieszczone. Zagadkę tę nazwano paradoksem Olbersa. Nawet Albert Einstein bał się podważyć przekonania co do statycznego Wszechświata. Chociaż z jego obliczeń wynikało, że Wszechświat rozszerza się, albo kurczy, wymyślił tzw. stałą kosmologiczną ­ siłę nie związaną z żadnym konkretnym oddziaływaniem, równoważącą przyciąganie się materii we Wszechświecie. Sam Einstein powiedział, że wprowadzenie stałej kosmologicznej do równań było największym błędem jego życia.
Podwaliny teorii Wielkiego Wybuchu położył Edwin Hubble, odkrywając w 1929 roku na podstawie 10 letnich obserwacji, iż galaktyki oddalają się od siebie. Wynik tej obserwacji zawarty został w tzw. prawie Hubble'a, które mówi, że prędkość oddalania się galaktyk jest proporcjonalna do odległości. Matematycznie prawo Hubble'a wyraża się wzorem: v=H 0 ∗D , gdzie
v ­ prędkość ucieczki galaktyki
H 0 - stała Hubble'a
D ­ odległości między galaktykami
Hubble wykazał, że istnieją inne galaktyki poza naszą. Udowodnił, że galaktyki oddzielone są od siebie pustymi obszarami. Badał również na podstawie widma gwiazd temperaturę i skład chemiczny odległych galaktyk. Widma galaktyk były prawie takie same jak te docierające z naszej Galaktyki poza tym, iż kolory były przesunięte w kierunku czerwonego krańca widma. Hubble na tej podstawie wysnuł hipotezę, że gwiazdy, których światło obserwował, oddalają się od Ziemi. Początkowo myślano, że gwiazdy poruszają się w przypadkowych kierunkach. Nie zaobserwowano jednak przesunięcia ku niebieskiemu krańcowi widma. Oddalanie się galaktyk od Ziemii umiejscawiało ją w uprzywilejowanej pozycji na co naukowcy nie chcieli się zgodzić. Ciekawe rozwiązanie zagadki przedstawił Aleksander Friedmann. Porównał on rozszerzający się Wszechświat do nadmuchiwanego balonu. Wówczas wszystkie obiekty znajdujące się na balonie oddalają się od siebie, jednakże żaden z nich nie jest w uprzywilejowanej pozycji. Innym fizykiem badającym rozszerzenie się Wszechświata był Georges Edouard Lemaître. Twierdził on, iż jeśli Wszechświat się rozszerza, to kiedyś musiał być skupiony w bardzo małym obszarze, który eksplodował. Teorię tę nazwano Wielkim Wybuchem (ang. Big Bang ­ "Wielkie Bum"). Teorię tę, chociaż początkowo wydawała się mało prawdopodobna, zaczęto wnikliwie badać, próbując odtworzyć historię wybuchu. Anthony Gamow wraz z Ralph Alpher i Robert Herman obliczyli temperaturę promieniowania wczesnego Wszechświata, jaka powinna występować obecnie przy założeniu, że minutę po wybuchu temperatura Wszechświata wynosiła 10 mld K. Według nich ta temperatura powinna wynosić ok. 5 K. Wysunęli przypuszczenie, że takie promieniowanie istnieje. Zostało to potwierdzone w 1965 przez Arno Allan Penziasa i Robert Woodrow Wilsona, którzy przy pomocy bardzo czułego detektora mikrofal zarejestrowali to promieniowanie.
1.1 Wielki Wybuch i pierwsze chwile po wybuchu
Teoria Wielkiego Wybuchu zakłada, iż Wszechświat powstał 12­15 mld lat temu. Zakłada również, iż wraz ze Wszechświatem powstawała czasoprzestrzeń. Pierwszy okres w dziejach Wszechświata trwał od momentu zero aż do 10­43 s. Ten początkowy okres zwany jest Erą Plancka. Wtedy to wszystkie oddziaływania były zunifikowane do jednego. 10­43 s po Wielkim Wybuchu oddzieliło się oddziaływanie grawitacyjne. Moment ten stanowi granicę poznania współczesnej fizyki. Kolejny etap zwany Wielką Unifikacją opisuje teoria oddziaływań elektrosłabych. Okres ten trwał od 10­38 s po Wielkim Wybuchu aż do momentu, kiedy oddzieliło się oddziaływanie silne.
Kolejnym etapem jest tzw. era inflacyjna, trwająca od 10­36 do 10­32 s. W tym czasie Wszechświat rozszerzył się ok. 1020 razy w porównaniu z rozmiarem wcześniejszym. Założenie powyższe tłumaczy problem horyzontu zdarzeń.
Między 10­32 a 10­5 s Wszechświat składał się z energii w postaci fotonów. Ze względu na ogromną gęstość energii cząstki mogły istnieć w postaci kwarków i antykwarków zawieszonych w "plazmie kwarkowej". Na 10­12 s przypada oddzielenie się oddziaływań elektrosłabych na elektromagnetyczne i słabe jądrowe, co zakończyło erę unifikacji sił fundamentalnych.
Rysunek 1: Rozdzielenie się oddziaływań (źródło: [1])
Przypuszczalnie w 10­6 s po Wielkim Wybuchu temperatura wynosiła 1013 K, możliwe więc było tworzenie się neutronów i protonów. Jednak temperatura była wciąż zbyt wysoka aby tworzyły się jądra atomowe. W kolejnym etapie, 13.8 s po Wielkim Wybuchu, zaczęły się formować nietrwałe jądra helu. Po 3 min. 46 s utworzyły już stabilne jądra deuteru. Wszystkie neutrony przemieniły się najpierw w deuter a potem w jądra helu. Ta przemiana jądrowa trwała do 34 min po czym ustała. Dopiero 700 000 lat po wybuchu zaczęły się formować trwałe jądra helu i wodoru. Wtedy to również Wszechświat stał się przeźroczysty dla promieniowania świetlnego. Stanowi to granicę w obserwacjach promieniowania świetlnego.
2. Błyski Gamma
Błyski promieniowania gamma są jednymi z najdziwniejszych zjawisk, na obecny stan wiedzy, występujących we Wszechświecie. Nie jest pewne ich pochodzenie ani geneza powstania. Wiele modeli próbuje je tłumaczyć, jednak ze względu na ograniczone możliwości pomiarowe nie jest łatwo wskazać, który model jest poprawny. Odrzuca się te, które świadczą przeciwko danym pomiarowym. Błyski gamma są krótkimi trwającymi od kilkuset setnych sekundy do kilkuset sekund wysokoenergetycznymi błyskami promieniowania elektromagnetycznego. Ze względu na ogromną emitowaną energię występują głównie w postaci promieniowania gamma.
2.1 Historia odkryć błysków gamma
Historia odkryć błysków gamma jest prawie tak samo niezwykła jak same błyski. Jak to w nauce bywa, odkryto je przypadkiem w dość dziwnych okolicznościach.
W okresie Zimnej Wojny aby uniknąć wojny nuklearnej podpisane zostało w 1963 roku przez ZSSR i USA porozumienie o zaprzestaniu prób jądrowych, zarówno w kosmosie, jak i na Ziemi. W celu kontroli przestrzegania porozumienia przez ZSSR, USA w latach 1963­1970 wystrzeliło serię satelitów Vela wyposażonych w detektory promieniowania X i gamma. W czasie wybuchu nuklearnego połowa energii emitowana jest w postaci promieniowania X i ok 1% w postaci promieniowania gamma. Wykrycie promieniowania X lub gamma świadczyłoby o wybuchu nuklearnym, ponieważ na Ziemi nie ma silnych źródeł tego promieniowania.
Satelity wysyłane były po dwa po przeciwległych stronach kuli ziemskiej w odległości 102000 km, co stanowi ok. 1/3 odległości Ziemia­ Księżyc. Takie rozwiązanie miało umożliwić wykrycie eksplozji nuklearnej na niewidocznej stronie Księżyca. 17 października 1963 roku wystrzelono pierwszego satelitę i prawie od razu wykryto promieniowanie gamma. Detektory nie pozwalały wykryć kierunku promieniowania a jedynie obecność promieniowania. Cały projekt Vela był ściśle tajny i dopiero w 1969 roku dane były przeanalizowane przez astrofizyka doktora Raya Klebesadela. Spośród zgromadzonych licznych przypadków błysków gamma jeden szczególnie zwrócił jego uwagę. Był to podwójny błysk z 2 lipca 1967 roku. Błysk ten uznano za pierwszy udokumentowany błysk promieniowania gamma pochodzenia pozaziemskiego. Błyski w czasie eksplozji nuklearnej są pojedyncze.
Rysunek 2: Pierwszy zarejestrowany błysk gamma (źródło: [4])
Dopiero w 1973 roku Amerykanie oficjalnie ogłosili odkrycie błysków gamma. Strona radziecka potwierdziła detekcję promieniowania również przez ich satelity szpiegowskie zainstalowane w analogicznym co amerykańskie celu. Ówczesne detektory nie pozwalały na określenie kierunku promieniowania. Zastosowano, więc metody triangulacji. W 1976 roku pracę zaczęła międzyplanetarna sieć detektorów promieniowania gamma (ang. Interplanetary Network, w skrócie IPN). Zastosowana metoda pozwalała określić źródło błysku z dokładnością do kilku minut kątowych.
Pierwszym znaczącym sukcesem IPN­u było zlokalizowanie 5­tego marca 1979 roku błysku gamma w Wielkim Obłoku Magellana. Błysk ten trwał znacznie dłużej niż wcześniej obserwowane błyski. Położenie błysku odpowiadało mgławicy N49 ­ pozostałości po supernowej. Zaczęto wówczas snuć przypuszczenia co do koincydencji tych dwóch zdarzeń. Zarejestrowany wówczas wybuch zakwalifikowano do nowej grupy błysków tzw. Soft Gamma­ray Repeaters (w skrócie SGR) ze względu na różnice w czasie trwania błysku, jak również znacznej ilości promieniowania X. Badanie tego typu błysków wskazało, że pochodzą one od magnetarów ­ gwiazd neutronowych o niezwykle silnym polu magnetycznym. Naprężenia na powierzchni magnetara wywołane silnym polem magnetycznym powodują quasi­cykliczne wyrzucanie w przestrzeń materii z wnętrza co jest źródłem tzw. miękkich błysków gamma. Na błyski gamma nowe spojrzenie dały dane pochodzące z satelity CGRO (Compton Gamma Ray Observatory) wystrzelonego 05.04.1991 roku zawierającego na pokładzie instrumenty badawcze (8 detektorów promieniowania gamma ) eksperymentu BATSE (Burst And Transient Source Experiment). Satelita zbierał dane do 04.07.2000 roku. W tym czasie zgromadził informacje na temat 2704 błysków co dawało ok. jeden błysk dziennie. Po uwzględnieniu ograniczonych możliwości technicznych satelity oszacowano, że w pobliże Ziemi docierało promieniowanie ok. trzech błysków na dobę.
Największym osiągnięciem eksperymentu BATSE było stworzenie mapy błysków, która pokazała izotropowy rozkład błysków w przestrzeni. Jednorodność tę można wytłumaczyć ich pozagalaktycznym pochodzeniem.
Rysunek 3: Mapa pozycji błysków gamma i ich energie.(źródło: [5])
Odkryto również ciekawą zależność ilości błysków od czasu ich trwania. Zauważono prawidłowość, że najwięcej jest błysków o czasie trwania ok. 0.2 sekundy oraz ok. 50 sekund.
Rysunek 4: Błyski zaobserwowane przez BATSE w zależności od czasu trwania.
(źródło: [6])
W 1996 roku pracę rozpoczął satelita BeppoSAX [19] wyposażony w detektory promieniowania X w zakresie 0,1­ 300 keV i kamery rentgenowskie. Umożliwiło to 28 lutego 1997 roku zarejestrować poświatę w paśmie rentgenowskim tuż po detekcji błysku gamma. Możliwość dokładnej lokalizacji błysku pozwoliła na naziemną obserwację poświaty w zakresie promieniowania widzialnego i radiowego.
Niezwykłym osiągnięciem, dzięki danym pochodzącym z satelity BeppoSAX, było zmierzenie przesunięcia ku czerwieni pozostałej po błysku z 8 maja 1997 poświaty na podstawie obserwacji przez teleskop Keck. Wyliczono, że źródło błysku jest odległe o ok. 7 mld lat świetlnych od Ziemi. Oszacowano również energię źródła 15 sekundowego promieniowania, która przy założeniu izotropowości, miała być równa energii wypromieniowanej przez Słońce w ciągu 10 milionów lat.
Kolejnym krokiem w poznaniu promieniowania gamma była obserwacja poczyniona przez naziemny teleskop optyczny ROTSE [7]. Teleskop ten dokonał obserwacji błysku w zakresie fal widzialnych 22s po wykryciu błysku promieniowania gamma. Teleskop ten jest dość mały i możliwa jest jego szybka reakcja i zmiana pola widzenia, natychmiast po dostarczeniu informacji z satelitów. Zaobserwowany 23 stycznia 1999 roku błysk był niezwykle silny o jasności rzędu 9 magnitudo.
Rysunek 5: Zdjęcia wykonane przez teleskop ROTSE błysku GRB990123 (źródło: [7])
Kolejnym ważnym odkryciem było odkrycie linii żelaza w poświacie błysku GRB990705 [16], co jest charakterystyczne dla wybuchu supernowej. Następne takie odkrycie dokonał w grudniu 1999 japoński satelita ASCA badający promieniowanie X. W kolejnych latach rozpoczęto dwa duże projekty badawcze: HETE­ w roku 2000, INTEGRAL­ w roku 2002. Na efekty ich działania nie trzeba było długo czekać. 4 października 2002 roku odkryto związek między zapadnięciem się masywnej gwiazdy do czarnej dziury z detekcją promieniowania gamma. Może to być kluczowe w poszukiwaniu źródła promieniowania gamma.
23 grudnia 2002 HETE po raz pierwszy w historii wykrył tzw. ciemne błyski gamma bez poświaty optycznej.
Nie tak dawno, bo 11 czerwca 2008 roku został wystrzelony kolejny satelita badawczy ­ GLAST, później nazwany Fermi GST [17]. Jest on wyposażony w dwa detektory LAT i GBM.
LAT (ang. Large Area Telescope) ­ jest szerokozakresowym detektorem pracującym w zakresie energii 20 MeV ­ 300 GeV. Jest następcą instrumentu EGRET będącym częścią Teleskopu Kosmicznego Comptona. GBM (ang.Gamma­ray Burst Monitor) ­ jest detektorem pracującym w zakresie energii fotonów 8 keV ­ 30MeV, charakteryzujący się bardzo krótkim czasem reakcji (ok. 2 μs). Jego głównym zadaniem będzie wykrywanie i lokalizowanie błysków gamma. Jest następcą instrumentu BATSE z Teleskopu Kosmicznego Comptona. Obecnie promieniowanie gamma jest badane przez liczne grupy naukowców. Jak zostało wcześniej przedstawione ważne jest aby informacje o pojawieniu się błysku, jak najszybciej dotarły do zajmujących się badaniem promieniowania gamma urządzeń. Dlatego stworzono wspólną sieć GCN (ang. The Gamma ray bursts Coordinates Network) zajmującą się przepływem danych
i wyników analiz. Jest to sieć rozgłoszeniowa współrzędnych GRB. Z informacji tych korzystają np. teleskopy naziemne.
Rysunek 6: Poglądowy schemat sieci GCN. (źródło: [8])
3. Projekt "Pi of the Sky "
3.1 Założenia projektu
Projekt "Pi of the Sky" został zapoczątkowany na fali sukcesu eksperymentu ROTSE. 23 stycznia 1999 mały, zdalnie sterowany teleskop zarejestrował poświatę pochodzącą od błysku gamma 22 sekundy po tym, jak satelita BATSE przesłał z na Ziemię informację o jego rejestracji. Na owe lata był to najszybciej dokonany pomiar optyczny błysku GRB. Natychmiastowy pomiar w zakresie fal optycznych pełni kluczową rolę w badaniu błysków promieniowania gamma. Dzięki niemu możliwa jest dokładna spektralna analiza błysku. Umożliwia to m.in. wyznaczenie przesunięcia ku czerwieni, a stąd wyznaczenie odległości z jakich pochodzą błyski. Sukces ROTSE potwierdził konieczność nowego podejścia do obserwacji błysków gamma. Jako, że zjawiska te trwają bardzo krótko, nie sprawdzały się obserwacje przy użyciu ogromnych teleskopów polegające na długotrwałej obserwacji małych fragmentów nieba. Prof. Bogdan Paczyński i dr Grzegorz Pojmański zaproponowali nowe podejście do badania błysków gamma. Jednym z inspiratorów projektu „Pi of the Sky” był nieżyjący już dziś prof. Bogdan Paczyński, wybitny polski astrofizyk, od początku lat 80­tych XX wieku pracujący w Institute for Advanced Study w Princeton w Stanach Zjednoczonych, który przez wiele lat interesował się błyskami gamma. Razem z dr Grzegorzem Pojmańskim z Obserwatorium Astronomicznego Uniwersytetu Warszawskiego zaproponował nowe podejście do badania optycznej poświaty po błyskach gamma. To bardzo krótkie zjawisko, które może pojawić się w dowolnej części nieba należało badać skanując jak największą część nieba. Analiza takiej ilości danych możliwa jest dzięki wykonywaniu ogromnej ilości zdjęć i ich komputerowej obróbce .
Toteż założeniem projektu "Pi of The Sky" jest ciągłe monitorowanie nieba w celu obserwacji szybko zmiennych w zjawisk astrofizycznych. Autorzy projektu postawili sobie za cele: ●
wyszukiwanie i obserwacje błysków optycznych pochodzenia kosmicznego ●
wyszukiwanie błysków optycznych stowarzyszonych z kosmicznymi błyskami gamma ●
obserwacja i wyszukiwanie gwiazd zmiennych i gwiazd nowych ●
obserwacja blazarów i supernowych ●
wyszukiwanie rozbłysków nieskatalogowanych dotąd gwiazd Projekt podłączony jest do sieci GCN, z której przesyłane są informacje o detekcji błysków promieniowania gamma. Po otrzymaniu informacji z sieci, kamery nakierowują swoje obiektywy na wskazany fragment nieba. Każdy z celów postawionych przez autorów projektu wymaga nieco innego sposobu obserwacji nieba. Pogodzenie ich możliwe jest dzięki wprowadzeniu priorytetów zadań, wg których ma działać układ. Oczywisty jest fakt, że obserwacje nieba na Ziemi mogą być prowadzone jedynie przy odpowiednich warunkach pogodowych. Aparatura pomiarowa może działać jedynie przy bezchmurnym niebie, przy małej wilgotności i niskiej jasności otoczenia (wiąże się to z brakiem źródeł światła z Ziemi). Takich warunków nie da się znaleźć w Polsce. Toteż obserwacje prowadzone są w pobliżu pustyni Atacama w Chile, gdzie zapewnione są takie warunki pracy.
Rysunek 7: Obserwatorium w Las Campanas (źródło: [9])
3.2 Realizacja projektu
Projekt realizowany jest w czterech fazach. Pierwsza faza dotyczyła testów dwóch kamer i jest już zakończona. Kamery w czasie testów były zainstalowane w Brwinowie(52.14°N, 20.71°E) 30 km na zachód od Warszawy. Na początku aparatura umieszczona była na nieruchomym montażu i składała się z kamery zbudowanej według projektu Genesis75 wyposażonej w matrycę CCD KAF401E firmy Kodak o rozdzielczości 768×512 pikseli. Tak skonstruowany montaż działał przez 10 miesięcy. W tym samym czasie pracowano nad nowym ulepszonym modelem. Komercyjną kamerę zastąpiono lepszą konstrukcji G. Kasprowicza zaprojektowaną ściśle dla potrzeb eksperymentu. Starą matrycę zastąpiono nową matrycą CCD442A firmy Fairchild o rozdzielczości 2062×2048 pikseli i geometrycznym rozmiarze piksela 15μm×15μm. Nowa kamera posiadała również przetwornik analogowo­cyfrowy. Kolejnym ulepszeniem aparatury była konstrukcja bardzo trwałej migawki wytrzymującej ok. 107 cykli otwarcia­zamknięcia. Kamery wyposażono w obiektywy firmy Zeiss o ogniskowej f równej 50 mm i aperturze f/1,4 76. Pozwoliło to osiągnąć pole widzenia o rozmiarach kątowych rzędu 33°×33°. Pracowano również nad umiejscowieniem aparatury na zdalnie sterowanym montażu. Pierwszy zdalny montaż został zrobiony na podstawie projektu z eksperymentu ASAS. Maksymalny czas dojazdu do zadanego punktu wynosił poniżej jednej minuty. W czasie tego etapu projektu dane były zbierane przez ok. 50 nocy pomiędzy listopadem 2002 a październikiem 2003. Były one później wykorzystane do testów algorytmów rozpoznających obiekty niebieskie. Druga faza projektu rozpoczęła się w czerwcu 2004 roku i obejmowała umieszczenie dwóch kamer w Obserwatorium Las Campanas w Chile, które rozpoczęły regularną pracę w lipcu. System składał się z dwóch zaprojektowanych dla potrzeb projektu kamer CCD, zamontowanych na zdalnie sterowanym montażu. Kamery zaopatrzone są w obiektywy firny Canon o ogniskowej f równej 85 mm i aperturze f/1,2. Druga faza trwa aż do dziś i testowane są w niej wszystkie elementy, które będą wykorzystane przy pełnym systemie. Możliwość powielenia występujących elementów jest kluczowym zagadnieniem przy tworzeniu systemu. Dokładane jest wiele starań aby był on jak najbardziej modułowy. Kolejnym, trzecim etapem projektu będzie montaż dwóch modułów po 12 kamer każda, oddalonych od siebie o ok. 150 km. Jest to o tyle istotna część projektu, że dzięki obserwacji nieba z dwóch odległych punktów, stosując metodę paralaksy jest możliwe odrzucenie pojawiających się błysków pochodzących od bliskich obiektów tj. samolotów, czy satelitów. Obecnie zdarza się że, system błędnie interpretuje te błyski. Algorytmy przeszukują wprawdzie bazy danych dotyczących satelitów okołoziemskich, jednakże dane zawarte w tych bazach są niepełne, stąd wynikają błędy. Każdej nocy rejestrowanych jest kilka takich zdarzeń. Są one sprawdzane każdorazowo przez uczestnika projektu. Sytuacja taka musi być wyeliminowana przed uruchomieniem całego systemu, kiedy to ręczne sprawdzanie danych, byłoby już technicznie niemożliwe. Czwarta część projektu zakłada instalację czterech par modułów na Ziemi. Dobór miejsc jest tu kluczowy aby zoptymalizować pokrycie obserwowanego nieba i czas obserwacji. Każda para modułów zapewnia pokrycie nieba ok. Pi steradiany, stąd nazwa projektu ‘Pi of the Sky’’, co dla czterech modułów daje pokrycie prawie całej sfery niebieskiej. 3.3. Największe osiągnięcie eksperymentu ­ GRB080319B.
Mimo, że projekt "Pi of the Sky" jest dopiero w fazie testowej ma na swoim koncie sukces na skalę światową. Udało się bowiem zaobserwować optyczne błyski bezpośrednio po zaobserwowaniu błysku promieniowania gamma. 19 marca 2008 roku o godzinie 7:12 czasu polskiego satelita Swift zaobserwował bardzo silny błysk gamma. Projektowi dopisało szczęście, gdyż akurat w tym czasie obiektywy kamer należące do Pi of the Sky, były wykierowane w kierunku pojawienia się błysku. Aparatura badawcza zaobserwowała to zdarzenie i zarejestrowała je w postaci serii zdjęć. Było to osiągnięcie na skalę światową, gdyż nigdy wcześniej w całej historii badania błysków gamma nie udało się tego dokonać. Wykonane obserwacje potwierdziły, iż nie ma opóźnienia między błyskami gamma w zakresie promieniowania gamma a promieniowania w zakresie fal optycznych. Według późniejszych obserwacji i obliczeń okazało się, że był to najsilniejszy błysk, jaki udało się do tej pory zarejestrować. Dzięki późniejszym obserwacjom Very Large Telescope w Chile udało się wyznaczyć przesunięcie ku czerwieni światła, które dotarło z błysków. Okazało się, że źródło tego błysku było odległe o ok 7,5 mld lat świetlnych. Poświata była widoczna przez kilka kolejnych tygodni z szerokim zakresie widma od fal radiowych do promieniowania gamma. Była to najdokładniej przeprowadzona analiza błysku gamma przeprowadzona w historii badań nad tym zjawiskiem. Informacje o tym zdarzeniu zostały opublikowane we wrześniowym numerze magazynu Nature (Nature 455, 183­188). Rysunek 8: : Błysk GRB 080319B zarejestrowany przez "Pi of the sky" (źródło: [10])
4. Graficzny interfejs monitoringu i kontroli eksperymentu.
4.1 Architektura kontroli systemu eksperymentu.
Obecnie eksperyment "Pi of the Sky" składa się z dwóch kamer CCD, zamontowanych na montażu paralaktycznym. Eksperyment sterowany jest przez komputer wyposażony w specjalnie dedykowane dla tego eksperymentu oprogramowanie. Oprogramowanie zostało podzielone na moduły, które odpowiadają wyszczególnionym jednostkom sprzętowym lub logicznym. Oprogramowanie odpowiada zarówno za zbieranie danych jak i ich analizę w czasie rzeczywistym.
Główny program zarządzający pracą innych modułów to PiMan. Bazuje on na technologii CORBA. PiMan zapewnia komunikację pomiędzy modułami, daje możliwość zdalnej kontroli nad urządzeniami, zarówno poprzez skrypty jak i ręcznie wydawane komendy.
Głównymi modułami są:
●
DAQ (Data AQuisition module) ­ moduł odpowiedzialny za kontrolę kamer, czytanie danych z kamer i ich obróbka w czasie rzeczywistym.
●
MOUNT module ­ moduł odpowiedzialny za kontrolę montażu paralaktycznego.
●
GRB Coordinates Network (GCN) module ­ moduł nasłuchujący komunikaty wysyłane przez sieć GCN, analizujący komunikaty, wysyłający polecenia innym modułom, o miejscu obserwacji
●
PiMan module ­ moduł odpowiedzialny za komunikację pomiędzy innymi modułami.
System kontroli opiera się na komunikacji poprzez:
●
Pishell ­ powłoka PiMana umożliwiającą bezpośrednie wydawanie poleceń przez operatora
●
komendy wykonywane okresowo przez CRON
●
skrypy zawierające zestawy komend np. opisujących plan obserwacji ●
runscript ­ skrypty do wywoływania innych skryptów uruchamiane bezpośrednio z powłoki Unix­a
PiMan umożliwia komunikację w obydwie strony tzn. dane mogą być zarówno wysyłane, jak i odbierane z urządzeń. Na ilustracji nr 9 przedstawiono główne elementy systemu PiMan wraz z zaznaczeniem kierunku przepływu danych. PISHELL
Scripts
runscripts
Cron
PiMan
DAQ
HETE
GCN
Mount
Rysunek 9: Poglądowy schemat głównych modułów kontrolujących pracę eksperymentu "Pi of The Sky".
Obecnie informacje dotyczące pracy urządzeń zapisywane są w postaci plików .ini.
Średnio co 5 min przysyłany jest z Las Campanas plik z pełną informacją o działaniu systemu. W plikach tych znajdują się wszystkie ważniejsze parametry określające pracę urządzeń. Nie jest to jednak format przystępny dla operatora, pełniącego dyżur podczas pracy kamer.
Rysunek 10: Przykładowy plik .ini
Kontrola odbywa się również poprzez czytanie komunikatów z PiShella. Nie jest to zbyt wygodna dla użytkownika forma kontroli. Problemem jest to iż w miarę, jak projekt będzie się rozrastał ta forma kontroli, nie zapewni sprawnej pracy. Opracowywany jest więc nowy system, który w większym zakresie przejmie kontrolę nad urządzeniami, będzie kontrolował stan urządzeń i poprawność ich działania. Poza tym przygotowywany system musi składać się z modułów aby móc w przyszłości podłączać kolejne urządzenia.
Docelowo system ma składać się z 48 kamer rozmieszczonych w modułach po 12 kamer. Obecnie działają dwie kamery w jednym obserwatorium. Łatwo więc sobie wyobrazić jakie wymagania stawiane są wobec nowego systemu monitoringu.
SEGMENT
KAMERA
MONTAŻ
~150 km
Rysunek 11: Dzięki zjawisku paralaksy możliwe jest wyeliminowanie obiektów bliskich.
Praca nowoprojektowanego systemu monitoringu ma się opierać o program Nagios.
Nagios jest programem wykorzystywanym głównie do monitorowania sieci. W razie problemów może wysyłać alerty w postaci maili lub sms­ów. Ma budowę modułową, co zostało wykorzystane przy dostosowaniu go potrzeb eksperymentu. Nagios bazuje na wtyczkach, które przy zachowaniu określonej formy zwracanych wartości, mogą kontrolować dowolne urządzenia. Dane uzyskane w ten sposób z urządzeń są zapisywane do bazy Nagios. Bazy te będą tworzone dla każdego segmentu oddzielnie. Jedna z wtyczek Nagios odpowiada za przepisywanie danych z bazy Nagios do bazy
zbiorczej. Dane z bazy zbiorczej będą analizowane i wyświetlane na stronie WWW, umożliwiając osobie kontrolującej prace urządzeń na szybką analizę zaistniałej sytuacji.
Strona www
DJango
urls.py
Templates
setting.py
manage.py
models.py
MySQL
Parser
MySQL
NAGIOS
MySQL
NAGIOS
MySQL
NAGIOS
Rysunek 12: Poglądowy schemat przepływu informacji w systemie kontroli urządzeń.
4.2 Django ­ monitoring poprzez stronę WWW
Tworzenie aplikacji mającej na celu monitorowanie urządzeń rozwijającego się projektu wymagało specyficznych rozwiązań. Aplikacja miała nie tylko sprawdzić się dla istniejącego fragmentu projektu, ale również być tak przemyślana aby możliwe było jej łatwe skalowanie. Wiele zastosowanych rozwiązań dało by się zrobić łatwiej, ale ograniczyło by to elastyczność aplikacji. Nadrzędnym celem było zapewnienie pełnej modułowości projektu.
Zapewniono całkowite rozdzielenie warstwy prezentacji danych od ich obróbki i pobierania. Również widok strony generowany jest dynamicznie na podstawie informacji zawartych w bazie danych. 4.2.1 Tworzenie projektu
Dla systemu monitoringu został utworzony na komputerze projektu katalog o ścieżce: /opt/pi/dev/pisys/ Aby porozdzielać poszczególne elementy monitoringu dla Django został utworzony katalog: /opt/pi/dev/pisys/frontmon Rysunek 13: Katalogi projektu
Została również oddzielona część na statyczne pliki projektu. Zawarte zostały one w katalogu django_media.
Do utworzenia nowego projektu wg frameworku Django służy komenda django­admin.py startproject pimon Komenda ta powoduje utworzenie katalogu pimon i dokumentów __init__.py manage.py settings.py urls.py __init__.pyo manage.pyo settings.pyo urls.pyo W wygenerowanych przez django­admin.py dokumentach znajdują się: __init__.py: jest to pusty plik, nie należy również do niego nic dopisywać. Jest on utworzony po to aby wskazać pythonowi iż w danym katalogu znajduje się wykonywalny kod. Python traktuje katalog zawierający plik __init__.py jako moduł.
manage.py: jest to bardzo użyteczny skrypt, który pomaga w zarządzaniu projektem. Może podejmować następujące akcje: adminindex, reatecachetable, dbshell, diffsettings, dumpdata, flush, loaddata, reset, runfcgi, runserver, shell, sql, sqlall, sqlclear, sqlcustom, sqlflush, sqlindexes, sqlinitialdata, sqlreset, sqlsequencereset, startapp, startproject, syncdb, test, validate setting.py w tym pliku przechowywane są wszystkie najważniejsze ustawienia aplikacji urls.py plik zawiera główne ustawienia URL. Dodatkowo są tworzone pliki z rozszerzeniem .pyo. Są to pliki zawierające automatycznie skompilowany przez pythona kod do postaci bycode ­u. To rozwiązanie zapewnia szybsze ładowanie się aplikacji, gdy nie było żadnych zmian w czasie od ostatniego jej uruchomienia. Po utworzeniu projektu należy utworzyć aplikacje należące do projektu. Wykonuje się to komendą
django­admin.py startapp monitoring_app
Tworzony jest wówczas wewnątrz projektu katalog o nazwie monitoring_app a w nim dokumenty:
__init__.py, views.py, models.py. Dla potrzeb aplikacji dodano jeszcze plik urls.py.
Znaczenie pliku __init__.py podano powyżej. Plik views.py zawiera główne funkcje do komunikacji pomiędzy serwerem, bazą danych a użytkownikiem. Models.py zawiera modele baz danych zdefiniowane dla aplikacji.
Dodanie pliku urls.py dla aplikacji ma na celu zapewnienie jej, jak największej modułowości. W pliku tym znajdują się ustawienia wyłącznie dla aplikacji monitoring_app. Plik ten jest wskazany w głównym pliku urls.py projektu poprzez wpis: (r'^pi',include('pi.monitoring_app.urls')).
Django ma swój własny wbudowany serwer, który służy do celów testowych. Uruchomić go można za pomocą komendy python manage.py runserver Aplikacja została tak przemyślana aby zmiany nie były wprowadzane bezpośrednio do template­u pisanego w języku html. Zmiany prowadzane są poprzez dodawanie pól do bazy danych, bowiem cały widok generowany jest dynamicznie, poprzez funkcje JavaScript. Tablice dotyczące widoku strony zapisany jest w tablicach monitoring_app_sites,monitoring_app_
panelik. Tablice te są również zdefiniowane w pliku models.py, jako klasy site i panelik. Dokładny opis jak wprowadzać zmiany zawarty jest w Załączniku nr 1.
4.2.2 Główne ustawienia projektu plik settings.py
Jak wspomniano powyżej w pliku settings.py mieszczą się główne ustawienia dla projektu. W tym pliku definiowana jest baza danych, informacje o plikach statycznych oraz wtyczkach.
Jako serwer obsługujący bazę monitoringu wybrano serwer MySQL w wersji 5.0.45.
Dla monitoringu utworzono bazę monpi. Układ tabel wraz z opisem stworzono na podstawie danych zawartych w pliku model.py. Dzięki temu plikowi możliwy jest łatwy wgląd do bazy i jej ewentualna modyfikacja. Po dokonaniu modyfikacji należy skorzystać z komendy weryfikującej poprawność modelu python manage.py validate, a później z komendy wykonującej model w bazie python manager.py syncdb. Dzięki komendzie python manage.py sqlall możliwy jest podgląd komend w SQL ­ u. Nazwy tabel tworzone z nazwy aplikacji i dodania nazwy klasy określonej w model.py. Komenda syncdb tworzy tabele tylko dla nowododanych klas do pliku models.py. Niestety dla utworzonych już tabel komenda nie wprowadzi potrzebnych modyfikacji. Za jej pomocą nie da się aktualizować ani usuwać tabel. Jest to przewidziane jako zabezpieczenie przed nieopacznym usunięciem tabeli. Dogodnym rozwiązaniem jest np. korzystanie z komendy sqlall a potem kopiowanie komend do terminala np. mysql­a.
W pliku setting.py zamieszczone są również informacje dotyczące strefy czasowej­ ustawionej na Europę Środkową, kodu języka ­ ustawionego na pl, systemu kodowania znaków. Ważnym ustawieniem jest wskazanie katalogu z plikami statycznymi i wykorzystywanymi gotowymi template­ami. W kategorii instalowanych aplikacji załączono między innymi gotową aplikację dla administratora 'django.contrib.admin' (dokładny opis panelu administratora zawarty jest w Załączniku nr 2), uproszczonej generacji stron statycznych 'django.contrib.flatpages', jak również utworzoną samodzielnie aplikację 'pi.monitoring_app'.
4.3 Apache
Chociaż Django posiada swój własny wbudowany serwer posłużył on wyłącznie w celach testowych. Gotowa aplikacja obsługiwana jest przez serwer Apache. W pliku konfiguracyjnym python.conf został dodany wpis.
Rysunek 14: Ustawienia Apache dotyczące monitoringu.
4.4 Wymagania sprzętowo­programowe Aplikacja została utworzona w oparciu o framework Django. Został on zainstalowany na systemie Fedora Linux.
Django jest napisany w języku Python, tak więc aplikacje internetowe są również pisane w tym języku. Wynika z tego, iż konieczna jest instalacja Pythona. Pythona można darmowo pobrać ze strony http://pyton.org/download/. Najnowsza wersja programu to Python 2.5.1 i ta też została wykorzystana. Django zostało pobrane ze strony www.djangoproject.com/download/. Zainstalowano najnowszą wersję tj. Django­1.0.2. Instalacja polega na wykonaniu komendy
sudo python setup.py install Wykorzystanie do instalacji skryptu setup.py zapewnia właściwą instalację wszystkich pakietów i ich poprawną lokalizację w systemie operacyjnym. Python został zainstalowany w katalogu /usr/lib/python2.5 Django zostało zainstalowane w katalogu /usr/lib/python2.5/site­packages/django W projekcie zostały wykorzystane również dodatkowe biblioteki Pythona paramiko i ConfigParser. Moduł paramiko pobrano ze strony http://www.lag.net/paramiko/. Jest to moduł napisany w języku Python, pozwalający na bezpieczne połączenia, implementujący w programie połączenia SSH2.
Moduł ConfigParser wykorzystany został do parsowania plików z rozszerzeniem .ini .
W projekcie wykorzystano również bibliotekę JavaScript ­ JQuery. Bibliotekę pobrano ze strony http://jquery.com/. Biblioteka ta służy optymalizacji kodu pisanego w języku JavaScript. W sposób zwięzły i przejrzysty pozwala operować na elementach DOM HTML. Głównym atutem tej biblioteki jest dogodne używanie technologii AJAX, który jest kluczowy dla projektu. Biblioteka ta pozwala wykonywać rutynowe zadania z wykorzystaniem gotowych funkcji. Unika się dzięki temu wielu tych samych linijek kodu. Wykorzystanie biblioteki JQuery jest opisane w Załączniku nr 2.
4.5 Przepływ danych i aktualizacja danych na stronie WWW
Kluczową sprawą dla projektu jest sprawny przepływ danych i ich aktualizacja na stronie. Oczywiste wydaje się zastosowanie technologii Ajax, zapewniającej asynchroniczną komunikację z serwerem. Ajax jest dość młodą technologią, która bardzo szybko zmieniła oblicze internetu. Dzięki asynchronicznym zapytaniom wysyłanym do serwera możliwa jest komunikacja z serwerem bez konieczności przeładowywania strony. Dane mogą być aktualizowane w czasie niemalże rzeczywistym. Nie jest wymagane wysyłanie przez użytkownika żadnych zapytań aby dane mogły być przesyłane. Na rysunku nr 15 przedstawiono poglądowy schemat przepływu danych w projekcie.
Dane znajdują się w bazie MySQL­a. Są one pobierane poprzez funkcje należące do aplikacji napisanej w Django. Przekazywane są na stronę w formacie JSON. Format JSON jest często wykorzystywanym formatem wymiany informacji, szczególnie w aplikacjach bazujących na Ajaksie. Chociaż JSON jest skrótem od słów JavaScript Object Notation, nie jest on przypisany do wyłącznie do języka JavaScript. W Pythonie ten format wymiany danych obsługuje biblioteka SimpleJson.
Dane są przekazywane poprzez standardową funkcję Django HttpResponse().
Za obsługę danych na stronie odpowiadają funkcje napisane w JavaScript­cie. Odpowiadają one za odpowiednie formatowanie danych i ich prezentację. Dodatkowo wraz z danymi przesyłana jest również informacja o zaistniałych błędach. W takich przypadkach wygląd strony zmienia się tak aby jak najszybciej doprowadzić operatora do źródła błędu. APACHE
Dynamiczna
strona www
JQUERY
Java Script
SimpleJson
Django
views.py
urls.py
models.py
MySQL
Rysunek 15: Przepływ danych
Dane sprawdzane są w dwojaki sposób. Pierwsza funkcja co 10 s. odpytuje wszystkie tabele i sprawdza wszystkie najświeższe dane i ich komunikaty błędu. Jeśli jakiś element działa niepoprawnie, zmieniają się odpowiednio kolory wskazując na niego.
Rysunek 16: Widok panelu jeśli wystąpił błąd
Druga funkcja odpowiada za pobieranie, wyświetlanie i odświeżanie danych. Chodzi o to aby nie powodować zbędnego obciążenia serwera. Ta funkcja pobiera i odświeża tylko dane wskazanego rodzaju. Na przykład wybierając opcję Mount odświeżają się tylko dane pochodzące z tabeli Mount. Aplikacja przy takim rozwiązaniu działa znacznie lepiej, niż początkowe rozwiązanie, w którym pobierane były wszystkie dane a zmieniany parametr elementu ­ display. Jest to rozwiązanie, o tyle lepsze, że gwarantuje również sprawną pracę przy planowanej większej liczbie segmentów obserwacyjnych a co za tym idzie i urządzeń podlegających kontroli.
5. Parser danych
Obecnie nie działa jeszcze moduł obsługiwany przez Nagios. Dlatego konieczne było przygotowanie czasowego rozwiązania polegającego na parsowaniu plików .ini i aktualizowanie informacji w bazie danych. Rozwiązanie to zostanie również wykorzystane do przeniesienia danych archiwalnych do bazy danych. Parser może działać w dwojaki sposób. Pierwszym podstawowym zastosowaniem jest parsowanie danych znajdujących się w dowolnym katalogu na tym samym komputerze co uruchomiony program. Drugim bardziej zaawansowanym użyciem jest łączenie się z komputerem poprzez połączenie SSH2 przy wykorzystaniu bibliotek paramiko. W załączniku nr 4 zawarty jest opis parsera danych wraz z opisem użycia.
Załącznik nr 1.
Aktualizacja panelu monitoringu.
W miarę jak eksperyment będzie się rozrastał dane będą napływać z wielu miejsc obserwacji. Każde takie miejsce wyszczególnione jest poprzez dodanie kolejnego pola na stronie. Rysunek 17: Dodanie nowego Site­u
Na rysunku 16. w górnej części widoku mamy trzy pola odnoszące się do różnych miejsc, z których zbierane są dane. Aby dodać kolejne, tak jak jest to widoczne na rysunku 17, należy w tabeli monitoring_app_sites dodać nowe pole. Pole to będzie automatycznie wczytane i wyświetlone. Tabela monitoring_app_sites posiada kolumny, w których mogą być przechowywane informacje o położeniu punktu obserwacji i różnicy czasowej. Są to informacje dodatkowe wymagane jest wyłącznie podanie miejsca obserwacji. Dodawać pola można bezpośrednio z poziomu bazy danych.
Można jednak użyć dużo wygodniejszego sposobu poprzez panel administratora. Panel administratora jest dokładnie omówiony w Załączniku nr 3. Teraz ograniczymy się do przedstawienia tabeli monitoring_app_sites. Wszystkie tabele zdefiniowane w pliku models.py są widoczne z poziomu administratora strony.
Rysunek 18: Podgląd tabel ze strony administratora.
Wybieramy tabelę Sites. Możemy dowolnie edytować, dodawać lub usuwać elementy tabeli. Mamy również możliwość przejrzenia historii danego wpisu.
Rysunek 19: Podgląd dowolnego elementu tabeli Sites.
Jeśli utworzymy już pole, określające nowy punkt obserwacji, możemy chcieć utworzyć dla niego oddzielne menu, dzięki któremu można wyświetlać specyficzne informacje o danym montażu. Aby stworzyć takie menu należy w tabeli monitoring_app_panelik dodać kolejne pola. Tabela ta zawiera kolumnę Site_id będącą kluczem obcym, który identyfikuje, do jakiego punktu obserwacji przyporządkowane jest dane menu. Również te wpisy możemy kontrolować poprzez stronę administratora. Wybór wartości klucza obcego ograniczony jest tylko do wartości zdefiniowanych w tabeli Sites. Możemy również zdefiniować nowe pole, które będzie utworzone w tabeli Sites.
Rysunek 20: Dodawanie nowych wartości do tabeli panelik i tabeli Sites.
Jeśli dodamy menu, z pewnością będziemy chcieli określić z jakich urządzeń pobierane są informacje (rysunek 21). Rysunek 21: Dodanie menu dla nowego punktu obserwacji.
Wtedy to należy dodać do tabeli monitoring_app_modules stosowne pola. Nazwy pól muszą być zgodne z nazwami tabel zadeklarowanymi w pliku models.py. Kolumna identyfikator określa do jakiego pola z wcześniej opisanego menu odnoszą się informacje. Dlatego pole identyfikator musi być uzupełnione zgodnie z nazwą pola nadrzędnego. Rysunek 22: Dodanie nowych urządzeń.
W dotychczasowej wersji wystarczające okazało się podawanie maksymalnie siedmiu urządzeń, widocznych z lewej strony rysunku 22. Jeśli okazałoby się jednak, że konieczne jest więcej wówczas trzeba zmienić plik models.py. Do zdefiniowanej w tym pliku klasie Modules należy dodać nowe pole i uaktualnić bazę danych. Nie da się tego wykonać poprzez
manage.py syncdb. Należy skorzystać z komendy sqlall a potem skopiować komendy do terminala np. mysql­a.
Jeśli dodajemy nowe urządzenie to należy opisać je, jako klasę w pliku models.py. Możemy zdefiniować tam dowolne potrzebne parametry opisujące urządzenie. Po dodaniu klasy wywołujemy komendę manage.py syncdb, która utworzy nową tabelę w naszej bazie.
Załącznik nr 2.
Dynamiczne wyświetlanie strony.
Jak opisano w załączniku 1. dodawanie nowych punktów obserwacji sprowadza się wyłącznie do uzupełniania odpowiednich tabel. Jest to możliwe dzięki dynamicznej generacji strony poprzez funkcje JAVASCRIPT .
W pliku main.js znajdują się główne funkcje obsługujące wyświetlanie danych na stronie. W aplikacji została wykorzystana biblioteka JQuery.
$(document).ready( function() {
var currentTimer; var check_all_time; check_all(); check_all_time = setInterval("check_all()", 5000);
Jako pierwsza wywoływana jest metoda ready( ). Dziedziczy ona bezpośrednio po klasie JQuery. Jest ona wywoływana po całkowitym załadowaniu się strony, kiedy możemy operować na wszystkich elementach modelu DOM. W metodzie ready( ) definiujemy anonimową funkcję, która zostanie wywołana po całkowitym załadowaniu się dokumentu.
Następnie wywołujemy funkcję check_all(). Jest to funkcja, która sprawdza poprawność danych i w przypadku nieprawidłowości zmienia widok strony. Poprzez użycie funkcji JavaScriptu setInterval() zdefiniowano jej wykonywanie co 5s.
$.get("/pi/header/",function(data) { var data = eval('(' + data + ')'); for (dic in data){ $("<li><a href=\"#\" class=\"button\" id = \""+data[dic]
['id']+"\">"+data[dic]['name']+"</a></li></ul>").appendTo('div.wrapper ul#header');
Następnie wywoływana jest funkcja get( ), jest to funkcja biblioteki JQuery i pozwala na wykorzystanie technologii Ajax. Jako parametry podajemy: stronę skąd pobieram dane i słownik z parametrami. Anonimowa funkcja generuje widok strony w oparciu o dane zawarte w tabeli.
$("ul#header li .button").click(function() { clearInterval(currentTimer); $('.table').hide(); $('.main ul.left').hide(); var check = {} check.id = $(this).attr('id'); $.getJSON("/pi/panelik/", check, function(responseData) { $('ul#menu').empty(); for(key in responseData) { if(key=='id' || key == 'SITES_id' || responseData[key]==null){} else{ $('ul#menu').show();
$("<li><a
href=\"#\"
class=\"button\" id=\""+responseData[key]+"\">"+responseData[key]+"</a></li>").appendTo('div.menu ul#menu');}
Każdemu nowozdefiniowanemu elementowi przypisywane jest zdarzenie click(). Pobierane jest wówczas id elementu, na którym dokonało się zdarzenie i na tej podstawie pobierane są dalsze dane z wybranych tabel.
Kiedy już wybierzemy urządzenie, którego działanie chcemy śledzić wywoływane są kolejne funkcje z wykorzystaniem technologii Ajax aby co 3s odświeżać dane prezentowane w głównej tabeli.
$('.main li .button').click(function(){ clearInterval(currentTimer); var take_data = {}; take_data.id = $(this).attr('id'); refresh_data(take_data.id); currentTimer = setInterval("refresh_data(\""+take_data.id+"\")", 3000); }); Załącznik nr 3.
Panel administratora.
Integralną częścią projektu jest rozbudowany panel administratora. Dzięki niemu możliwe jest edytowanie, dodawanie i usuwanie elementów strony.
Dodanie panelu administratora odbywa się poprzez odpowiednie skonfigurowanie pliku settings.py. Należy w dodać w INSTALLED_APPS wpis "django.contrib.admin". Również muszą być dodane "django.contrib.auth", "django.contrib.contenttypes".
Należy również uzupełnić wpis :
MIDDLEWARE_CLASSES = ( 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.middleware.doc.XViewMiddleware', );
Koniczne jest dodanie do pliku urls.py adresu strony administratora. Można to zrobić dodając do parametru urlpatterns wpis: (r'^admin/', include('django.contrib.admin.urls')).
Po dodaniu wpisów należy zaktualizować bazę danych poprzez wywołanie komendy:
python manage.py syncdb
Należy też stworzyć superusera, który będzie posiadał pełne uprawnienia administratora. Superuser ma uprawnienia aby dodawać i usuwać innych użytkowników, tworzyć grupy użytkowników i przydzielać im uprawnienia.
Po pomyślnym zakończeniu zmian i zalogowaniu się widać podstawowy model panelu administratora.
Rysunek 23: Podstawowy widok panelu administratora.
Nie ma wówczas dostępu do zdefiniowanej w models.py bazy danej. Dostęp taki jest jednak możliwy poprzez rozszerzenie utworzonych w pliku models.py klas. Framework Django daje również możliwość ustawienia filtrów i zdefiniowania widocznych z poziomu panelu administratora kolumn. Rysunek 24: Dostęp do bazy z panelu administratora.
Przykładowo dla klasy General dodano:
class Admin: list_display=('ERROR','DTM','UNIX_TIME','START_DTM',
'WAITING','DOME','NIGHT','LAST_COMMAND') list_filter = ('LAST_COMMAND', 'ERROR','DOME') ordering = ('UNIX_TIME',) search_fields = ('LAST_COMMAND')
Przypisane dla parametru list_display wartości odpowiadają za wyświetlanie wybranych kolumn.
W list_filter definiujemy filtry wykorzystywane przy wyszukiwaniu. W ordering wybieramy kolejność wyświetlania wartości. Jest również możliwość wyszukiwanie wartości po wprowadzeniu nazwy. Należy wówczas ustalić wartość search_fields, definiując kolumnę, według której ma się odbywać wyszukiwanie.
Rysunek 25: Tabela General widziana z panelu administratora, wraz z zdefiniowanymi filtrami.
Załącznik nr 4.
Parser danych.
Dane z urządzeń przesyłane są w plikach tekstowych w formacie .ini. Przed umieszczeniem danych w bazie należy sparsować te pliki, tak aby uzyskać potrzebne nam informacje. Kod parsera napisany jest w języku Python w oparciu o bibliotekę ConfigParser. Dane mogą być pobierane zarówno z komputera, na którym uruchomiony jest program, jak również poprzez połączenie ssh z dowolnego innego komputera.
#!/usr/bin/env python #­*­ coding: utf­8 ­*­ import paramiko import sys import os import ConfigParser import MySQLdb paramiko.util.log_to_file('/tmp/paramiko.log') def connection(host_p,port_p,username_p,password_p): u""" funkcja realizująca połaczenie ssh connection(host_p,port_p,username_p,password_p) host_p nazwa hosta port_p numer portu username_p nazwa użytkownika password_p hasło zwraca dwa parametry pierwszy ­ obiekt klasy SFTPClient drugi ­ obiekt klasy Transport """ host = host_p port = port_p transport = paramiko.Transport((host, port)) password = password_p username = username_p transport.connect(username = username, password = password) sftp = paramiko.SFTPClient.from_transport(transport) return (sftp,transport) def close(sftp_p,transport_p): u""" funkcja odpowiedzialna za zamknięcie połaczeń """ sftp = sftp_p transport = transport_p sftp.close() transport.close() return def copy(filepath_p,localpath_p,conn): u""" funkcja kopiująca pliki z odległego komputera """ filepath = filepath_p localpath = localpath_p sftp = conn sftp.get(filepath, localpath) return def open_db(host_p,user_p,passwd_p,db_p): u""" otwarcie połączenia z bazą """ try: conn = MySQLdb.connect (host = host_p, user = user_p, passwd = passwd_p, db = db_p) cursor = conn.cursor () except MySQLdb.Error, e: print "Error %d: %s" % (e.args[0], e.args[1]) sys.exit (1) return cursor def parser(fread_file,host_p,user_p,passwd_p,db_p): u""" parsowanie wskazanego pliku do bazy """ config = ConfigParser.ConfigParser() config.readfp(fread_file) val = [] col = [] i = 0 site ="1" for section in config.sections(): columns = '' values = '' del val[0:] del col[0:] print section for option in config.options(section): #print option option_mod = option.replace("[","_") option_mod = option_mod.replace("#","") option_mod = option_mod.replace("]","") #print option_mod val.append('\''+config.get(section, option)+'\'') values = '\''+site+'\','+",".join(val) col.append(str(option_mod)) columns = "SITES_id,"+",".join(col) #print columns table = 'monitoring_app_' + section.lower() query = 'INSERT INTO ' + table + ' (' + columns + ') VALUES (' + values + ')' insert_into_db(query,host_p,user_p,passwd_p,db_p) def insert_into_db(query,host_p,user_p,passwd_p,db_p): u""" włożenie danych do bazy """ cursor = open_db(host_p,user_p,passwd_p,db_p) cursor.execute(query) cursor.close () def open_file(dir_path,host_p,user_p,passwd_p,db_p,host_ssh="",port_ssh="",usern
ame_ssh="",password_ssh=""): u""" otwarcie pliku albo na komputerze lokalnym albo odległym poprzez ssh """ if host_ssh =="" or port_ssh=="" or username_ssh == "" or password_ssh=="": try: for plik in os.listdir(dir_path): plik = os.path.join(dir_path,plik) fread = open(plik,"r") if cmp(os.path.splitext(plik)[1],".status")==0: parser(fread,host_p,user_p,passwd_p,db_p) except IOError: print 'cannot open', plik else: connect= connection(host_ssh,port_ssh,username_ssh,password_ssh) sftp = connect[0] try: for plik in sftp.listdir(dir_path): fread = sftp.open(plik,"r") plik = os.path.join(dir_path,plik) if cmp(os.path.splitext(plik)[1],".status")==0: parser(fread,host_p,user_p,passwd_p,db_p) print "otwarto na komuterze odlelym" except IOError: print 'cannot open', plik return if __name__ == "__main__": open_file("ścieżka/do/katalogu","localhost","root","1234","monpi") #parser(fread,"localhost","root","1234","monpi") sys.exit()
Bibliografia
[1] Internet encyclopedia of science
http://www.daviddarling.info/encyclopedia/B/Big_Bang.html
[2] Wikipedia
http://pl.wikipedia.org/wiki/Vela_1A
[3] Gamma­Ray Bursts A BRIEF HISTORY, NASA
http://imagine.gsfc.nasa.gov/docs/science/know_l1/GRB_history.pdf
[4] K. Kamiński, Błyski Gamma, Obserwatorium Astronomiczne UAM, Poznań 2003 http://blyskigamma.republika.pl [5] Strona domowa projektu BATSE
http://www.batse.msfc.nasa.gov/batse/grb/skymap/
[6] Strona domowa projektu BATSE
http://f64.nsstc.nasa.gov/batse/ [7] Strona domowa projektu ROTSE
http://www.umich.edu/~rotse/gifs/grb990123/990123.gif
http://www.rotse.net/
[8] Strona domowa GCN
http://gcn.gsfc.nasa.gov/
[9] Strona Centrum Astronomiczne Mikołaja Kopernika
http://www.camk.edu.pl/
[10] Strona domowa projektu "Pi of the Sky"
http://grb.fuw.edu.pl/pi/pr/doc/grb080319b_pi_opis.doc [11] Strona projektu JQuery
http://jquery.com/
[12] Strona projektu Django
http://www.djangoproject.com/
[13] Strona projektu Python
http://www.python.org/
[14] Strona biblioteki paramiko
http://www.lag.net/paramiko/
[15] Strona poświęcona JSON
http://www.json.org/
[16] Strona poświęcona błyskowi GRB990705
http://www.narrabri.atnf.csiro.au/public/grb/grb990705/
[17] Oficjalna strona NASA Fermi
http://fermi.gsfc.nasa.gov/
[18] Practical Django Projects, autor ­ James Bennett, wydawnictwo ­ apress 2008
[19] Strona domowa programu BepoSAX
http://www.asdc.asi.it/bepposax/