MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Automatizace zápisu metadat o astronomickém pozorování do snímků z CCD kamery DIPLOMOVÁ PRÁCE Karel Auf Brno, jaro 2017 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Automatizace zápisu metadat o astronomickém pozorování do snímků z CCD kamery DIPLOMOVÁ PRÁCE Karel Auf Brno, jaro 2017 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Karel Auf Vedoucí práce: RNDr. Martin Kuba, Ph.D. i Poděkování Chtěl bych poděkovat vedoucímu práce, RNDr. Martinovi Kubovi, Ph.D., za rady a vedení, konzultantovi, RNDr. Janovi Janíkovi, Ph.D., za testování aplikace během vývoje a cenné rady a připomínky Dále bych chtěl poděkovat rodině za podporu během celého studia. Na závěr bych chtěl poděkovat tvůrcům astronomické databáze SIMBAD ve Štrasburku, jejichž databázi ve své práci používám. iii Shrnutí Cílem této práce bylo vytvoření nástroje pro usnadnění ovládání systému pro pořizování astronomických snímků pomocí CCD kamery pro Ustav teoretické fyziky a astrofyziky Přírodovědecké fakulty Masarykovy univerzity v Brně. Obsahem práce je analýza požadavků a použitých technologií, návrh a implementace aplikace, a návod pro používání výsledné aplikace. iv Klíčová slova FITS, ASCOL, CCD kamera, Java, hlavička, Header Data Unit, metadata, hlavičkový záznam, SIMBAD, souřadnice, rektascenze, deklinace v Obsah 1 Úvod 1 2 Analýza problému 3 2.1 Doplňující požadavky 4 2.2 Rektascenze a deklinace 5 3 Formát souboru FITS 7 3.1 Struktura FITS souboru 7 3.1.1 Hlavička 7 3.1.2 Datová část 8 3.1.3 Rozšíření a speciální záznamy 9 3.1.4 FITS shrnutí 10 4 Návrh řešení 11 4.1 Prvotní záměr 11 4.2 Použitý návrh řešení 12 4.3 Dodatečné požadavky 14 5 Implementace 15 5.1 Uspořádání aplikace 15 5.2 ASCOL protokol 16 5.2.1 Příkazy protokolu ASCOL 16 5.3 Knihovna pro práci s FITS soubory 18 5.4 Balík entity 18 5.5 Balík coordinates 19 5.5.1 AstroObjectService 19 5.5.2 TelescopeControl 22 5.6 Balík database 23 5.7 Balíkfits 25 5.7.1 FolderWatch 25 5.7.2 FitsFileUpdate 26 5.8 AstroCameraUI 29 6 Zajímavosti při implementaci 31 6.1 Problém s úpravou FITS souborů 31 6.2 Problém s přístupem k databázi 33 vii 7 Návod k použití 7.1 AstroCamera 35 7.1.1 Záložka Main 35 7.1.2 Záložka Settings 37 7.2 Konfigurační soubor a soubor se souřadnicemi 38 8 Závěr 4 1 Literatura 43 A Přílohy 4 5 viii 1 Úvod Astronomie je jednou z nejstarších věd, její základy byly položeny už ve starověku. První pozorování byla pořízena pouze pomocí lidského oka a zabývala se polohou hvězd. Od těchto dob astronomie prošla celou řadou změn a oddělily se od ní samostatné vědní disciplíny jako např. astrometrie nebo astronavigace, které byly původně její součástí. Ve 20. století došlo k rozdělení astronomie do dvou hlavních směrů. Teoretický směr se pomocí analytických modelů snaží popsat astronomické objekty a jejich chování, zatímco druhý směr zaměřený na pozorování hvězd se snaží zaznamenat co nejvíce informací za použití teleskopů a jiných nástrojů pro pozorování [1]. S vývojem pozorovacích metod bylo nutné vyvíjet i nové způsoby, jak získané informace zaznamenat. Zatímco ve starověku stačilo zakreslit polohu pozorovaných objektů na svitek, při použití dnešních teleskopů je zapotřebí vzít v úvahu velké množství faktorů, které mohou pozorování ovlivnit. Z tohoto důvodu byl v roce 1981 definován první standard FITS (Flexible Image Transport System), určený k uchovávání vědeckých pozorování. Kromě uchovávání obrazové informace formát umožňoval uložení doplňujících informací týkajících se pořízeného záznamu. Díky této vlastnosti se FITS stal hlavním formátem pro uchovávání hvězdných pozorování. Ustav teoretické fyziky a astrofyziky Přírodovědecké fakulty Masarykovy univerzity používá pro záznam pozorování pořízených na astronomické observatoři v Brně rovněž soubory typu FITS. Snímky pořízené za pomocí teleskopu a CCD kamery obsahují mimo obrazové informace pouze údaje o nastavení kamery. Další údaje je nutné zadávat ručně, což je nepraktické a časově velmi náročné. Proto vznikl požadavek na vytvoření nástroje, který by tento proces automatizoval, umožnil získat potřebné meteorologické údaje a souřadnice pozorovaného objektu a zapisoval je do nově pořízených snímků. Zároveň byl vznesen požadavek, aby byl vytvořen nástroj, který by zjednodušil ovládání dalekohledu, kde současný systém vyžadoval ruční vyhledání souřadnic pozorovaného objektu a jejich následný přepis do softwaru na ovládání dalekohledu. Výsledný nástroj by měl umět vyhledat objekt dle jména a jeho souřadnice zaslat do softwaru k řízení polohy dalekohledu. 1 i . ÚVOD Tato práce se zabývá návrhem a implementací nástroje splňujícího tyto požadavky Výsledkem práce je program v jazyce Java [2] s uživatelským rozhraním umožňujícím snadné a rychlé ovládání. Druhý výsledek práce je tento text rozdělený do šesti kapitol mimo úvod a závěr. V druhé kapitole se věnuji rozboru zadání od zadavatele a vysvětlení několika stěžejních pojmů. Další kapitola se zabývá formátem souboru FITS a vysvětlením nejdůležitějších částí jeho struktury. Ve čtvrté kapitole se věnuji návrhu řešení. Pátá kapitola, Implementace, se zabývá použitými technologiemi a podrobným rozborem jednotlivých částí vytvořené aplikace. Následující kapitola se zabývá zajímavými problémy, které se vyskytly během implementace. Poslední kapitola popisuje hotový systém a způsob jakým ho používat. V závěru jsou zhodnoceny dosažené výsledky. V příloze je obsažen výsledný program se zdrojovými kódy, ukázkový konfigurační soubor a ukázkový soubor pro načítání a ukládání souřadnic. 2 2 Analýza problému V této kapitole se zaměřím na rozbor zadání práce a vysvětlení stěžejních pojmů. Ustav teoretické fyziky a astrofyziky Přírodovědecké fakulty Masarykovy univerzity má na astronomické observatoři v Brně systém pro pořizování snímků z dalekohledu pro pozorování hvězdné oblohy Tento systém se ovládá ze dvou počítačů. První stanice, označená jako D62, slouží k ovládání dalekohledu a čtení údajů z meteostanice. Druhá stanice, označená jako MUO, slouží k ovládání CCD kamery, která pořizuje snímky z dalekohledu. Tyto dva počítače používají stejný operační systém Windows 7 a nachází se na stejné lokální síti. Na stanici D62 běží pouze program pro ovládání dalekohledu a záznam údajů z meteostanice do databáze. Ovládání dalekohledu obstarává Telescope Control System (TCS) od firmy ProjectSoft [3]. TCS nabízí uživatelské rozhraní, které umožňuje natáčení dalekohledu podle zadaných souřadnic, otáčení kopule, čtení údajů z meteostanice a další operace spojené s ovládáním dalekohledu společně s automatizací některých funkcí např. otáčení kopule zároveň s dalekohledem nebo zavření kopule při dešti. Stanice MUO má připojenu CCD kameru, jejíž ovládání je zprostředkováno pomocí programu Scientific Image Processing System (SIPS) od firmy Moravské přístroje [4]. SIPS je specializovaný program pro astronomické využití CCD kamery, proto nabízí pořizování ve FITS formátu, který je využíván k uchovávání vědeckých snímků, zejména v astronomii. Tento formát bude podrobněji vysvětlen v následující kapitole, prozatím stačí vědět, že kromě obrázku je schopen uchovávat i metadata s ním související. SIPS umožňuje nastavení a zápis některých metadat při pořízení snímku. Nastavení některých údajů jako typ kamery, zvolený filtr nebo čas expozice se provádí automaticky, některé je však zapotřebí provést manuálně např. název pozorovaného objektu, rektascenze (RA), deklinace (DEC),... Tento systém umožňuje pořizování snímků, bohužel je zapotřebí hodně nastavování a pořízené snímky neobsahují klíčová metadata. Uvedu zde příklad, chtěl bych pozorovat např. hvězdu Antares. Bohužel neznám z hlavy její souřadnice, takže musím někde na webu vyhledat její souřadnice, rektascenzi (RA) a deklinaci (DEC). Navíc 3 2. ANALÝZA PROBLÉMU musí být ve formátu: [hodiny minuty sekundy] pro R A a [stupně minuty sekundy] pro DEC. Tyto souřadnice musím zkopírovat nebo přepsat do TCS na počítači D62 a buď přepsat nebo opět vyhledat a zkopírovat na počítači MUO do SIPS, aby byly uloženy ve výsledném FITS souboru. SIPS bohužel neumožňuje nastavení libovolných údajů do FITS souboru, takže žádné meteorologické ani jiné údaje nebudou do vytvořeného souboru uloženy. Cílem práce je vytvoření nástroje nebo nástrojů splňujících tyto požadavky: • po zadání názvu vybraného objektu vyhledá jeho souřadnice odešle je do TCS na D62 pro následné zaměření dalekohledu, • předá název zaměřeného objektu počítači MUO, aby jej bylo možné zapsat do FITS souboru, • umožní automatické získávání vybraných údajů z meteostanice (vlhkost vzduchu, rychlost větru, teplota vzduchu v kupoli a venku, tlak a množství infračerveného záření z pyrgeometru), • umožní získat aktuální souřadnice středu zorného pole dalekohledu z počítače D62 a jejich přenos do stroje MUO, • umožní automatický zápis všech získaných údajů (název, meteorologické údaje a souřadnice) do nově vzniklých FITS souborů, • pokud to bude možné, tak by nástroje měly pracovat pouze na stanici MUO, na počítač D62 by se nemělo nic instalovat, • výsledný nástroj by měl býtjednoduchý na ovládání, aby urychlil současný proces pozorování. 2.1 Doplňující požadavky Během vývoje aplikace se objevily některé doplňující požadavky: • zapsání přesnějších GPS souřadnic observatoře než bylo doposud zapisováno programem SIPS, • přidání některých údajů do FITS souboru (přepočet existujících do jiných jednotek a jeden další údaj z meteostanice), 4 2. ANALÝZA PROBLÉMU • přidání možnosti vyhledání souřadnic objektu z poskytnutého souboru, • možnost uložení aktuálních souřadnic natočení dalekohledu do souboru. První dva body jsou celkem jednoznačné. Nástroj SIPS umožňuje vložit souřadnice, ale pouze s omezenou přesností, proto je požadováno, aby byly zapsány přesnější údaje do FITS snímků. Další rozšíření metadat uložených do FITS souborů zahrnovalo přepočet tlaku na úroveň hladiny moře a uvedení souřadnic pozorovaného objektu v obou používaných formátech (viz Rektascenze a deklinace). Při práci s programem se ukázalo, že někdy je dobré mít snímek nezaměřen středem úplně přesně na střed pozorovaného objektu, ale místo toho na jeho okraj. Pro tento účel mělo být možné zapsat aktuální pozici dalekohledu do souboru pod zvoleným názvem a případně tyto souřadnice ze souboru znovu získat zadáním příslušného jména objektu. 2.2 Rektascenze a deklinace Rektascenze [5,6], zkratkou označovaná jako RA (z angl. Right ascension), je souřadnice udávající úhel svíraný mezi rovinou procházející světovými póly a nebeským tělesem a rovinou procházející světovými póly a jarním bodem. Jedná se o hvězdný ekvivalent zeměpisné délky. Uvádí se buď pouze ve stupních, nebo častěji v hodinách, minutách a sekundách. Uhel 15° odpovídá jedné hodině. Nabývá rozsahu 0° - 360° nebo v hodinách, minutách a sekundách 00:00:00 - 23:59:59,99. Deklinace [6, 7], označovaná jako Dec (z angl. Declination), je souřadnice reprezentující úhlovou vzdálenost od světového rovníku. Jedná se o hvězdný ekvivalent zeměpisné šířky. Hodnota se uvádí pouze ve stupních, nebo častěji ve stupních, minutách a sekundách. Nabývá rozsahu —90° - +90°. Na severní polokouli je hodnota kladná, na jižní je záporná. Hvězdy na rovníku mají deklinaci rovnu 0. Tyto dvě souřadnice se používají v astronomii pro udávání polohy vesmírných objektů. Ačkoliv je formát zápisu obsahujícího hodiny (stupně), minuty a sekundy pro člověka mnohem srozumitelnější, tak 5 2. ANALÝZA PROBLÉMU je využíván i zápis pouze ve stupních. Tento zápis je jednodušší pro strojové zpracování. 6 3 Formát souboru FITS Flexible Image Transport System (FITS) je typ souboru navržený pro archivaci, přenos i práci s především vědeckými snímky. Narozdíl od jiných typů souborů sloužících pro uchovávání obrazové informace, byl FITS pro vědecké účely přímo navržen. Proto mimo uchovávání samotného obrazu umožňuje uchovat mnoho informací souvisejících s pořízeným snímkem. Toto je jeden z důvodů, proč je FITS nejrozšířenějším typem souboru využívaným v astronomii, kde snímky obsahují velké množství metadat, která jsou pro účely pozorování klíčová [8]. První verze FITS byla standardizována již v roce 1981, současná verze je 3.0. Pro účely této práce je podstatné to, že FITS je vyvíjen s důrazem na zpětnou kompatibilitu. To znamená, že stejně tak jako jsme současným softwarem schopni prohlížet snímky z 80. let, tak i v budoucnu bude základní struktura souboru zachována. 3.1 Struktura FITS souboru Každý soubor FITS se skládá z těchto částí v uvedeném pořadí: • primární hlavička a datová část (Primáry header and data unit - HDU), • rozšíření (Conforming Extension - jedná se o volitelnou část), • speciální záznamy (Other speciál records - opět volitelná část). Každý FITS soubor tedy obsahuje alespoň jednu hlavičku a datovou část, tzv primární HDU. Pokud soubor obsahuje pouze tuto část, tak se jedná o základní FITS soubor neboli Single Image FITS (SIF). Pokud soubor obsahuje jedno nebo více rozšíření, jedná se o MultiExtension FITS (MEF) soubor. Primární HDU, stejně jako rozšíření, se skládá z jedné nebo více hlaviček následovaných volitelnou datovou částí [9]. 3.1.1 Hlavička Hlavička [9] má velikost maximálně 2880 bytů a obsahuje metadata uložená v ASCII znacích (rozsah ASCII znaků je omezen na znaky 7 3- FORMÁT SOUBORU FITS s decimálním kódem 32-126), člověku čitelném formátu. ASCII znaky s decimálním kódem 32 a méně se v hlavičce nesmí vůbec vyskytnout. Hlavička je uspořádána do řetězců znaků o délce 80 symbolů. Každý takový řetězec obsahuje klíčové slovo, hodnotu a může být doplněn volitelným komentářem v následujícím formátu: klíčové slovo = hodnota/komentář Do jedné hlavičky je tedy možné umístit až 36 těchto záznamů. Poslední hlavička musí obsahovat klíčové slovo END, označující logický konec hlavičky, za kterým následuje datová část HDU. Klíčové slovo může mít délku maximálně 8 znaků. Povolené znaky jsou čísla 0 až 9, velká písmena latinské abecedy (A až Z), znaky podtržítko _ a pomlčka -. Žádné jiné symboly, mezery ani malá písmena povoleny nejsou. Pole hodnoty navazuje na klíčové slovo následované dvojicí znaků =u a může tak zabírat znaky 11 až 80 pokud bude přítomna. Hodnota může být vyjádřena jako řetězec ASCII znaků, logická hodnota nebo číselná hodnota. V případě využití řetězce jsou povoleny znaky s decimálním kódem 32 až 126 oproti klíčovému slovu jsou tedy povoleny malá písmena, mezery a některé speciální znaky. Logická hodnota je reprezentována jako T pro pravda (true) a F pro nepravda (falše). Povolené číselné hodnoty jsou celá čísla, reálná čísla a komplexní čísla. Pokud je přítomen komentář, tak je od hodnoty oddělen znaky J. Komentář může obsahovat stejné znaky jako řetězcová hodnota, tedy znaky s decimálním kódem 32 až 126. 3.1.2 Datová část Datová část [9] je nepovinná část HDU, která těsně navazuje na hlavičku. Celá datová část se skládá z jednoho pole o 1 až 999 dimenzích (počet dimenzí je specifikován klíčovým slovem NAXIS v hlavičce). Každá hodnota v poli se skládá z pevně daného počtu bitů (určeného hodnotou u klíčového slova BITPIX v hlavičce). Pokud má pole více než jednu dimenzi, tak jsou hodnoty uspořádány tak, že se index na první pozici mění častěji než index na druhé pozici, ten se mění častěji než index na třetí pozici atd. Hodnoty jsou tedy navyšovány v tomto pořadí (kde A(l, 2,3) reprezentuje hodnotu na prvním řádku v druhém sloupci a na třetí „vrstvě"): 8 3- FORMÁT SOUBORU FITS A(l, 1,1), A(2,1,1),... A(NAXIS1,1,1), (3.1) A(1,2,1), A(2,2,1),... A(NAXIS1,NAXIS2,1), (3.2) A(l, 1,2), A(2,1,2),... A(NAXIS1,NAXIS2,NAXIS3) (3.3) V (3.1) se postupně navyšuje index na první pozici až po dosažení maxima NAXIS1. Po dosažení maxima se o 1 zvýší index na druhé pozici a následně se zvyšuje opět index na první pozici od 1 až do dosažení maxima. Tato situace se opakuje až do dosažení maximálního indexu na všech pozicích (3.3). Pole je zapsáno jako souvislý řetězec bitů a neobsahuje žádné oddělovače řádků nebo sloupců. Pokud pole nezabere celý datový blok, tak je zbývající místo vyplněno bity nastavenými na 0. 3.1.3 Rozšíření a speciální záznamy Pro rozšíření (Conforming Extension) [9] platí několik omezení, ať už pro jejich vznik nebo strukturu. Nové rozšíření by mělo být vytvořeno pouze pokud informace v něm obsažené nemohou být zařazeny do některého z již existujících rozšíření. Každé rozšíření má svoje unikátní jméno uvedené v hlavičce (klíčová hodnota XTENSION). Aby nedocházelo ke konfliktům v názvech, tak jsou tyto názvy registrovány u IAU FITS Working Group (IAU-FWG). Každé rozšíření musí ve své hlavičce obsahovat informaci o svojí velikosti. Běžný uživatel si nevytváří rozšíření podle sebe, ale využívá existujících rozšíření. Poslední částí FITS souboru jsou tzv Speciální záznamy (Special records) [9]. Jedná se o data uložená ve FITS souboru za koncem posledního HDU v blocích o velikosti 2880 bytů. Tyto záznamy nemají žádnou předepsanou strukturu podobně jako rozšíření, mají jen dva požadavky. Prvních 8 bytů nesmí obsahovat řetězec XTENSION, aby nedošlo k záměně s rozšířením a je doporučeno, aby neobsahovaly řetězec SIMPLEUU. Původně byly tyto záznamy zamýšleny pro použití při vývoji nových částí FITS souborů, ale po vývoji normálních rozšíření (Conforming Extension) bylo využití pro speciální záznamy významně sníženo. Běžný uživatel se s nimi téměř nesetká. 9 3- FORMÁT SOUBORU FITS 3.1.4 FITS shrnutí Pro účely této práce je důležité vědět, že FITS soubory jsou schopny uchovávat kromě dat, také metadata. Soubory jsou uspořádány tak, že obsahují hlavičku s metadaty a následně datovou část. Tento blok, hlavička a data, se nazývá HDU (header and data unit), první HDU se nazývá primární HDU za ním mohou následovat další HDU, neboli rozšíření. V hlavičce jsou záznamy uloženy ve stylu klíčové slovo = hodnota a mohou být doplněny komentářem odděleným znakem /. Záznamy jsou v hlavičce uloženy v pro člověka čitelné podobě, takže pokud otevřu FITS soubor v textovém editoru, tak budu schopen záznamy v hlavičce přečíst. Délka klíčového slova je nanejvýš 8 znaků, délka celého záznamu (klíčové slovo, hodnota i komentář) může být maximálně 80 znaků. Hodnota může být reprezentována řetězcem znaků, logickou hodnotou nebo číslem. 10 4 Návrh řešení V této kapitole vysvětlím, jak jsem postupoval při hledání vhodného způsobu realizace systému. 4.1 Prvotní záměr Celý proces pořizování snímků byl v původním stavu velmi komplikovaný. Uživatel potřeboval pracovat se dvěma počítači zároveň relativně často. Přidání dalšího programu pro plnění některých funkcí se nejevilo jako nejlepší řešení, proto jsem chtěl pracovat s již existujícím softwarem. K dispozici byly dva počítače a na každém jeden program. Ideální by byl způsob, kde by na stanici D62 s programem TCS na ovládání dalekohledu bylo implementováno vyhledávání objektů a na stanici MUO by se dodatečný zápis metadat prováděl s využitím programu SIPS, který už nějaká metadata zapisoval. Zadavatel si ovšem nepřál, aby na stanici D62 běžel jakýkoliv další program, pokud to nebude bezpodmínečně nutné. Ukázalo se, že by systém TCS mohl být ovládán vzdáleně a tudíž by práce přímo s D62 nebyla nutná. Zaměřil jsem se tedy na stanici MUO a program SIPS. Kromě pořizování snímků umí program také přidat základní metadata do snímku dle uživatelem zadaných parametrů. Z těch co nabízí se jednalo o název objektu, rektascenzi a deklinaci. Idea tedy byla rozšířit SIPS o modul, nastavující několik dalších údajů a zároveň umožnil automatizaci získávání dat pro tyto údaje. Kontaktoval jsem Moravské přístroje, tvůrce programu SIPS, zda by bylo možné, abych takové rozšíření vytvořil. Bohužel se ukázalo, že veškerá veřejná programová rozhraní SIPSu se týkajíjen ovladačů zařízení (kamery, montáže ostření, kopule hvězdáren, GPS,...). Žádné rozhraní pro interakci během stahování a ukládání snímků neexistuje a ani se žádné neplánuje. Přímá práce z programu SIPS tedy možná nebyla. Díval jsem se tedy, zda by nebylo možné využít některé části nepřímo. SIPS si byl schopen pamatovat název zadaného objektu, takže se zde jevila možnost pracovat s tímto údajem skrz nějaký konfigurační soubor nebo registr. Po bližším pro- 11 4- NÁVRH ŘEŠENÍ zkoumání se ukázalo, že se tato informace ukládá pouze při ukončení programu, takže se i tato cesta ukázala jako nepoužitelná. Ačkoliv se tento směr jevil jako nejjednodušší na používání pro uživatele a potenciálně i na implementaci, tak se ukázalo, že přímé použití existujícího softwaru není možné. 4.2 Použitý návrh řešení Vzhledem k tomu, že nebylo možné modifikovat stávající programy používané k obsluze ovládání CCD kamery a dalekohledu, bylo nutné najít jiné řešení. Hledání jiného softwaru pro ovládání kamery by se mohlo potýkat se stejným problémem, navíc by bylo nutné, aby se uživatelé naučili používat nový systém. Rozhodl jsem se jít tedy cestou samostatného programu, který by bylo možné ovládat ze stanice MUO. Jako cíle jsem si zde kladl, mimo splnění veškerých funkčních požadavků, také jednoduché ovládání. Řešení jsem si rozdělil na jednotlivé podproblémy: • vyhledání objektu dle zadaného jména, • zaslání souřadnic do TCS, • získání metadat z meteostanice, • zapsání metadat do souboru. Vyhledání objektu vyžaduje databázi, která by sloužila jako zdroj souřadnic pro vyhledávání. Vytvoření takové databáze pro účely tohoto projektu by bylo velice nepraktické. Data by bylo nutné nejprve odněkud získat a následná údržba databáze, aby obsahovala nejnovější data by byla velmi náročná. Rozhodl jsem se proto využít již nějakou existující databázi, která je volně přístupná. Navíc, vzhledem k výše zmíněné potřebě udržovat databázi aktuální, jsem se rozhodl pro využití online databáze. Ve chvíli, kdy jsou souřadnice získány, tak je nutné zabezpečit jejich předání do TCS na sousední stanici D62. TCS má naštěstí rozhraní pro vzdálenou správu pomocí protokolu ASCOL [10]. Tento protokol umožňuje zasílání jednoduchých zpráv, pomocí nichž lze provádět některé základní operace řízení dalekohledu, mezi nimi i možnost 12 4- NÁVRH ŘEŠENÍ nastavit souřadnice pro nové natočení dalekohledu. Vyhledávání a zasílání souřadnic dle zvoleného objektu je tedy možné. Druhý cíl práce, zapisování údajů z meteostanice, vyžadoval nejprve získání těchto dat. Ačkoliv TCS umožňuje zobrazování údajů zaznamenaných meteostanicí, tak už není možné tyto údaje získat pomocí ASCOL protokolu. Bylo tedy zapotřebí získat údaje jiným způsobem. Kromě zobrazování těchto dat v reálném čase v programu TCS jsou data zapisována do databázového souboru rovněž v reálném čase. Tento databázový soubor je následně používán pro export vybraných údajů do csv souboru pro další účely. Nejlepší způsob jak získávat údaje je tedy přímo z databáze, kde budou údaje vždy aktuální. Posledním bodem je samotný zápis metadat do hlavičky FITS souboru. Vzhledem k tomu, že SIPS nebylo možné upravit, bylo nutné přijít s vlastním způsobem zápisu. Zde se nabízely dvě možnosti, buď zpětně podle času pořízení souboru dohledávat příslušná metadata z databáze a nebo metadata v souboru aktualizovat těsně po jeho vytvoření aktuálními hodnotami z databáze. Rozhodl jsem se pro druhý způsob, protože jsem ho považoval za přirozenější. Při použití tohoto návrhu bude zaměřování dalekohledu na zvolený objekt fungovat následovně: 1. Uživatel zadá název objektu, který chce pozorovat. 2. Aplikace vyhledá v online databázi příslušné souřadnice. 3. Souřadnice jsou pomocí ASCOL protokolu zaslány do TCS. Zapisování dodatečných metadat do souborubude probíhat v těchto krocích: 1. Aplikace pravidelně získává aktuální údaje z databáze, do které je zapisuje meteostanice. 2. Aplikace si kontroluje, zda byl vytvořen nový FITS soubor. Pokud ano, tak vezme aktuální údaje a zapíše je do hlavičky nově vzniklého souboru. 13 4- NÁVRH ŘEŠENÍ 4.3 Dodatečné požadavky Většina požadavků byla spíše implementačního charakteru. Pouze alternativní možnost vyhledávání objektu potřebovala vhodný návrh. Nabízely se dvě možnosti. Použít podobný způsob jako při standardním vyhledávání, tedy využít databázi. Druhá možnost by bylo využít textového souboru s uloženými informacemi v člověku čitelné podobě. Využití databáze je zcela jistě rozumnější způsob, pokud by se jednalo o stovky záznamů. V našem případě se jedná o vyhledávání pro několik objektů, kde je lepší použít souřadnice okraje místo souřadnic středu objektu. Hlavní výhoda databáze proto nebyla tolik podstatná. Nevýhodou využití databáze je potřeba nějakého rozhraní pro její používání. Využití programu třetí strany je dosti nepraktické (přidává na složitosti celého systému), mnohem rozumnější volbou by bylo umožnit správu přímo z aplikace. Za vhodnější řešení jsem považoval čtení dat z textového souboru. Pro uživatele je to mnohem jednodušší způsob, jak nové objekty vkládat a upravovat, pokud pracujeme s malým množstvím záznamů. Pokud by vzrostla potřeba pro správu více objektů, tak by bylo zapotřebí pouze malých úprav pro umožnění vyhledávání v databázi místo textového souboru. Pro splnění požadavku zadavatele, kde se jednalo o použití pro omezený počet záznamů, jsem se rozhodl využít druhého způsobu pro uchovávání záznamů s alternativními souřadnicemi. 14 5 Implementace Pro implementaci aplikace jsem zvolil programovacíjazyk Java [2], především pro jeho snadnou přenositelnost, podporu knihoven nutných pro určité úkony, které aplikace bude plnit, a také pro moje zkušenosti s tímto jazykem. Aplikace je distribuována jako standardní JAR archiv, který po spuštění nabízí grafické rozhraní pro práci s aplikací. V této kapitole se zaměřím na popis použitých technologií a detailní rozbor funkcionality a implementace jednotlivých částí aplikace. 5.1 Uspořádání aplikace Java využívá uspořádání tříd do balíků pro jednodušší orientaci v programu. Balíky obvykle sdružují třídy se související funkcionalitou. Výsledná aplikace AstroCamera je celá uložena v balíku cz.muni.fi.astrocamera. V tomto hlavním balíku se nachází balíky sdružující třídy dle jejich účelu. Jednotlivé balíky jsou složeny z rozhraní a jejich implementací. Rozhraní definuje jaké metody následná implementace musí obsahovat. Aplikace pak může pracovat se samotným rozhraním a nemusí se starat o konkrétní použitou implementaci. Díky tomu je možné snáze modifikovat výslednou aplikaci, kde obvykle stačí pouze upravit implementaci dané třídy nebo metody. Jádrem aplikace je třída AstroCameraUI, která generuje a obsluhuje grafické rozhraní, ke své činnosti využívá třídy z ostatních balíků. Tyto třídy už jsou zodpovědné za jednotlivé úkoly. Balík Coordinates obsahuje třídy starající se o práci se souřadnicemi, třída AstroObjectService se stará o získávání souřadnic pro hledaný objekt a třída TelescopeControl zařizuje komunikaci s TCS. V balíku Database se nacházejí dvě třídy pro práci s databází. Balík Fits obsahuje třídy zajišťující monitorování vzniku FITS souboru a jeho následnou úpravu. Poslední balík Entity se skládá ze tříd implementujících datové objekty, které slouží k předávání informací v rámci aplikace. Před popisem jednotlivých tříd, je zapotřebí blíže popsat použité technologie, které nejsou úplně běžné. Jedná se o protokol ASCOL, sloužící ke komunikaci s TCS, a knihovnu nom-tam-fits, sloužící k úpravě FITS souborů. 15 5- IMPLEMENTACE 5.2 ASCOL protokol ASCOL protokol slouží k ovládání dalekohledu. Je postaven na protokolu TCP a pomocí krátkých zpráv zasílaných na řídící počítač s programem Telescope Control System (TCS) umožňuje vykonávat některé funkce dostupné v TCS. Řídící počítač poslouchá na TCP portech v rozsahu daném pro konkrétní pozorovací sestavu. Na jeden port je možné pouze jedno připojení. Jednotlivé příkazy jsou zasílány jako ASCII posloupnost symbolů ukončená koncem řádku, tj. znakem (0x0A) nebo dvojicí znaků (OxOD, 0x0A). Odpovědi na tyto příkazy jsou ukončeny znaky (OxOD, OxOA). Struktura příkazu je: název příkazuuparametry Mezi názvem příkazu a prvním parametrem (pokud je nějaký) musí být mezera, stejně jako mezi jednotlivými parametry. Za posledním parametrem, už bez mezery, následuje ukončení řádku a tedy konec příkazu. Dostupné příkazy lze rozdělit do dvou kategorií, aktivní příkazy a dotazy. Aktivní příkazy většinou kromě názvu příkazu obsahují i parametry. Jejich účelem je nastavení některého parametru, nebo provedení nějakého úkonu. Aby bylo možné tyto příkazy provádět, tak je nutné se nejdříve přihlásit pomocí příkazu GLLG. Bez přihlášení fungují pouze dotazy. V případě, že klientská stanice nepošle žádný příkaz po dobu dvou minut, tak řídící stanice spojení ukončí. Spojení je rovněž ukončeno pokud klientská stanice pošle více než 100 znaků bez ukončovacího znaku LF (OxOA). V jiných případech spojení ukončeno není. Pokud je zadán příkaz špatně nebo při zadání nesprávných parametrů odpoví řídící stanice textem ERR [10]. 5.2.1 Příkazy protokolu ASCOL Konfigurace, se kterou jsem pracoval, nabízí 37 možných příkazů, uvedu proto jenom ty, které mají vztah k řešenému problému. Jedná se o TSRA (Telescope Set new Right ascension and declination Absolute), TGRA (Telescope Go to new Right ascension and declination Absolute), 16 5- IMPLEMENTACE Příkaz Parametry Popis TSRA Rektascenze (uni formát) Deklinace (uni formát) Poloha Uloží do paměti automatu souřadnice pro následný nájezd příkazem TGRA. TGRA Dalekohled najede na souřadnice zadané příkazem TSRA. TRRD Vrátí aktuální rektascenzi a deklinaci. GLLG heslo (číslo 0 - 2000000000) Autorizace aktuálního spo­ jení Tabulka 5.1: ASCOL příkazy TRRD (Telescope Read Right ascension and Declination) a GLLG (GlobaL LoGin). TSRA umožňuje zaslat souřadnice pro nové natočení dalekohledu, ty jsou uloženy a následně mohou být použity k samotnému natočení. Rektascenze může být v rozsahu 0 až 359°59/ 59,99// , deklinace v rosahu -89°59'59,99" až 89°59'59/ 99" a poloha může nabývat hodnoty 0 (východní) nebo 1 (západní). Vzhledem k parametrům hvězdárny, pro kterou je aplikace zamýšlena, je nastavení polohy nepodstatné, protože východní i západní poloha mají totožné omezení. Zasílání souřadnic je možné ve dvou formátech, buď se jedná o úhel pouze ve stupních, nebo se jedná o složený tvar hodiny (stupně)-minutysekundy (desetiny a setiny sekund). Vzhledem k tomu, že TCS používá zobrazení v druhém formátu a zároveň je tento formát pro člověka přehlednější, tak jsem použil tuto notaci. Příkaz TGRA umožňuje natočení dalekohledu podle souřadnic dříve zadaných příkazem TSRA. Tento příkaz byl shledán jako nepotřebný, protože by poskytoval duplicitní funkcionalitu k programu TCS. Dotaz TRRD je využíván k získávání současných souřadnic natočení dalekohledu. Odpověďje ve stejném formátu jako parametry pro příkaz TSRA, tedy rektascenze, deklinace a poloha. Rektascenze je 17 5- IMPLEMENTACE v hodinovém formátu, deklinace ve stupních, minutách a vteřinách. Poloha je zde opět nepodstatná. Příkaz GLLG slouží k přihlášení se jako autorizovaný uživatel. V tomto módu je možné využívat i aktivní příkazy, v našem případě TSRA nebo TGRA (pokud by byl využit). Heslo se skládá z řetězce čísel v rozsahu uvedeném výše. V případě úspěšného přihlášení příkaz vrátí hodnotu 1 v opačném případě hodnotu 0 [10]. 5.3 Knihovna pro práci s FITS soubory Java nabízí čtyři knihovny pro práci s FITS soubory [11]. Jedná se o nom.tam Fits, eap.fits, jfits a STIL. Knihovna STIL bohužel neumožňuje práci s FITS obrázky, pouze s tabulkami. Knihovna jfits už nebyla dlouhou dobu aktualizována a poslední dostupná verze má mnoho limitací. Knihovna eap.fits už nabízí trochu lepší práci s FITS soubory, ale nebyla už 12 let aktualizována. Poslední knihovna nom.tam FITS s nejlepší funkcionalitou a aktivní podporou se proto jevila jako nejlepší volba. Pro práci s nom.tam FITS knihovnou není potřeba znát detailní informace o způsobu uložení dat v souboru. Přístup k datům zde probíhá přes logické celky, je tedy možné získat ze souboru pouze hlavičku a pracovat pouze s ní bez potřeby dohlížení na ostatní části souboru. Díky tomuto návrhu je možné se orientovat v kódu i bez hlubokých znalostí struktury FITS souborů [12]. 5.4 Balík entity Tento balík sdružuje třídy, které slouží pro ukládání a předávání dat, která spolu souvisí. Ačkoli se nejedná o klíčovou část projektu, tak tyto třídy významně vylepšují přehlednost kódu, kde namísto např. pěti parametrů je zapotřebí pouze jednoho. Balík obsahuje tyto třídy: • AstronomicalObject - slouží pro uchování názvu, rektascenze a deklinace vyhledávaného objektu, • Telescope - uchovává informace o IP adrese a portu řídícího počítače, na kterém běží TCS, 18 5- IMPLEMENTACE • MeteoData - slouží k ukládání meteorologických dat (teplota uvnitř kopule, teplota venku, tlak, rychlost vzduchu, vlhkost a hodnota pyrgeometru) získaných z databáze, • TeleData - uchovává údaje o dalekohledu získané z databáze (aktuální souřadnice) a navíc uchovává zeměpisné souřadnice dalekohledu samotného. 5.5 Balík coordinates Tento balík obsahuje dvě třídy. AstroObjectService se stará o získávání souřadnic k hledanému objektu a TelescopeControl zajišťuje komunikaci s dalekohledem. 5.5.1 AstroObjectService Tato třída nabízí uživateli dvě funkce, získání souřadnic dle zadaného jména z online databáze a získání souřadnic dle zadaného jména z vybraného souboru. Dostupných online databází je několik, bohužel jen malá část z nich je použitelná pro potřeby této práce. Většina nabízí totiž pouze webové rozhraní, které je výborné pro uživatele, ale nepoužitelné pro strojové zpracování. Některé mají navíc omezené použití pouze pro osobní potřebu. Bohužel žádná databáze z mnou nalezených nemá veřejnou knihovnu pro přímou práci s databází, ale několik umožňuje skriptování požadavků a formátu výstupu. Díky pevnému tvaru výstupu je možné z něj získat potřebné souřadnice ve formátu, který je rozumně strojově zpracovatelný. Pokud vím přesně, jak každá odpověďvypadá, tak mohu získat řádek nebo řádky obsahující informace, které mě zajímají, v tomto případě souřadnice. První implementace vyhledávání používala archiv exoplanet (planety obíhající jinou hvězdu než Slunce) od NASA [13]. Tato databáze po zadání typu objektu a názvu umožnila získat souřadnice objektu. Ačkoliv vyhledávání samotné fungovalo, tak se při testování během konzultací ukázalo jako nevhodné. Nutnost vybrání typu objektu byla značně omezující, protože spoléhala na znalosti uživatel správně zařadit objekt do kategorie. Tento problém bylo možné odstranit současným vyhledáváním ve všech kategoriích, ale byly zde další problémy. 19 5- IMPLEMENTACE První problém se týkal jmen objektů. Vyhledávání bylo závislé na velikosti písmen a to mohlo být pro některé názvy neintuitivní. S názvy objektů souvisel i druhý problém, vyhledávání rozpoznávalo pouze jeden typ označení objektu. Webové rozhraní si s tímto problémem poradit umělo, ale skriptovací systém nikoliv. Proto například místo názvu Sirius bylo nutné zadat HD 48915. Zjištění tohoto názvu obvykle vyžadovalo další hledání a bylo tedy v rozporu s cílem této práce, zjednodušení procesu pozorování. Poslední problém, který se objevil při testování, byl stav databáze. Mnoho objektů bylo v archivu detekováno, jako existujících, ale žádné další informace známy nebyly. Vzhledem k těmto problémům byl archiv shledán nepoužitelným. Další pokus využíval databázi Simbad [14]. Tato databáze nenabízela přímo způsob použití mimo webový prohlížeč, podobně jako předchozí archiv, ale umožňovala velice detailní nastavení skriptu, který zobrazil data přesně ve formátu definovaném uživatelem. Tento rozdíl znamenal malé změny oproti předchozímu systému, především v podobě předávání víceslovných jmen objektů. Předchozí systém mezery ignoroval, tento je potřeboval zachované, v případě že se jednalo o názvy jako Alfa Centauri. Výhodou této databáze bylo, že nepotřebovala určení typu objektu a zároveň se ukázala jako velice tolerantní k podobě zadaného vstupu. Nejen že ignorovala rozdíl mezi malými a velkými písmeny a umožňovala vyhledání i podle více názvů jednoho objektu, což byly nevýhody předchozí databáze, navíc umožňovala jistý systém korekce. Abych zde uvedl příklad, použiji výše zmíněné Alfa Centauri. Vzhledem k tomu, že se jedná o databázi pro mezinárodní použití, takje navržena v anglickém jazyce. Anglický překlad naší hvězdy (ve skutečnosti trojhvězdy) je Alpha Centauri, tedy jak je vidět, už zde by mohlo dojít k možnému problému. Vyhledávání je v tomto případě velice robustní a nejen že rozpozná český název, ale je schopné si poradit i s některými nedokončenými názvy. Možným problémem této databáze se zdála její menší velikost oproti archivu exoplanet. Při testování a následném provozu aplikace se na chybějící informace zatím nenarazilo. Databáze byla proto shledána jako plně dostačující pro potřeby observatoře. Funkce getObjectOnline sloužící k vyhledání souřadnic pro vybraný objekt z online databáze funguje tímto způsobem: 20 5- IMPLEMENTACE 1. Obdrží jméno hledaného objektu v podobě datové entity AstronomicalObject s vyplněným jménem. 2. Zkontroluje platnost potřebných údajů. 3. Vytvoří řetězec se jménem v podobě vhodné ke zpracování a odešle požadavek do Simbad databáze. 4. Z odpovědi je získán řádek obsahující souřadnice. 5. Souřadnice jsou uloženy do entity AstronomicalObject obdržené jako parametr a ta je vrácena jako návratová hodnota. V případě že dojde k jakékoliv chybě je objekt vrácen normálním způsobem, ale souřadnice nejsou nastaveny Druhá metoda loadObjectFromFile umožňující získání alternativních souřadnic ze souboru funguje podobným způsobem: 1. Obdrží jméno hledaného objektu v podobě datové entity AstronomicalObject s vyplněným jménem a obdrží soubor, ve kterém má hledat souřadnice. 2. Zkontroluje platnost potřebných údajů. 3. Vyhledá řádek s příslušným jménem a získá z něj souřadnice. 4. Souřadnice jsou uloženy do entity AstronomicalObject obdržené jako parametr a ta je vrácena jako návratová hodnota. Zde je zapotřebí zmínit podobu souboru. Jedná se o textový soubor se souřadnicemi uloženými tak, že na jednom řádku se nachází informace vztahující se pouze k jednomu objektu. Řádek je ve formátu: jméno objektu # rektascenze v hodinách # deklinace ve stupních # nepovinný komentář Symbol # slouží jako oddělovač, který se nevyskytuje v názvu objektů, mezery kolem něj jsou nepodstatné. Formát rektascenze a deklinace je zvolen opět jako nejčitelnější pro člověka, při jeho zápisu do souboru nezáleží na zapsaných nebo nezapsaných mezerách. Za posledním symbolem # je možné vložit komentář pro popis konrétních souřadnic. 21 5- IMPLEMENTACE 5.5.2 TelescopeControl Třída TelescopeControl umožňuje interakci se systémem TCS pro ovládání dalekohledu. Uživateli nabízí dvě funkce, sendData, která zašle vybrané souřadnice do TCS, a funkci retrieveData získávající aktuální souřadnice natočení dalekohledu z TCS. Funkce sendData funguje v těchto krocích: 1. Obdrží entitu telescope obsahující IP adresu a port počítače s TCS, heslo pro přihlášení a souřadnice pozorovaného objektu. 2. Zkontroluje platnost potřebných údajů. 3. Pokusí se vytvořit spojení s cílovým počítačem. 4. Pokud uspěje, tak se pokusí přihlásit ASCOL příkazem GLLG. 5. V případě úspěšného přihlášení zašle souřadnice ASCOL příkazem TSRA a spojení uzavře. Vzhledem k velkému množství uživatelem modifikovatelných vstupů u této metody bylo nutné zajistit důkladné ošetření jejich formátu. V případě použití online vyhledání souřadnic bylo zajištěno, že souřadnice buď byly ve správném formátu, nebo nebyly žádné. Se zavedením možnosti načítání vlastních souřadnic byl tento předpoklad neplatný a musel se ověřit i jejich formát. Podobná situace platí pro IP adresu cílového počítače. Kontrola je proto prováděna při přípravě dat pro odeslání a následně i během komunikace, kdy jsou kontrolovány odpovědi řídícího počítače. Metoda retrieveData pracuje následovně: 1. Obdrží entitu telescope obsahující IP adresu a port počítače s TCS. 2. Zkontroluje platnost potřebných údajů. 3. Pokusí se vytvořit spojení s cílovým počítačem. 4. Pokud uspěje, tak se pokusí získat aktuální souřadnice ASCOL příkazem TRRD. 22 5- IMPLEMENTACE 5. Vrácené souřadnice zapíše do řetězce ve formátu: #rektascenze#deklinace#. 6. Vrátí tento řetězec, v případě chyby vrátí prázdný řetězec. Pokud vrácený řetězec obsahuje souřadnice, tak je následně použit k zápisu těchto souřadnic do souboru. 5.6 Balík database Tento balík obsahuje dvě třídy, MeteoDatabaseService a TeleDatabaseService. Tyto třídy se liší pouze databází, ke které se připojují, a daty získávanými z této databáze. Z tohoto důvodu nebudu rozebírat každou třídu samostatně, ale vysvětlím, jak fungují, na jedné z nich. Účelem třídy MeteoDatabaseService je pravidelné získávání aktuálních meteorologických údajů z databáze. Použité databáze jsou typu SQLite [15] ve verzi 3 a pro práci s nimi používám ovladač SQLite JDBC [16]. Aby průběh získávání dat neměl dopad na běh celé aplikace, bylo nutné zajistit, že práce s databází poběží v samostatném vlákně. Z tohoto důvodu třída Meteo-DatabaseService implementuje rozhraní Runnable [17] umožňující tuto funkcionalitu. Třída obsahuje 2 konstruktory, jeden bezparametrický a jeden pro nastavení parametrů nutných k běhu. Prvním parametremje cesta k adresáři obsahujícímu příslušné databázové soubory. Druhý parametr je entita MeteoData, sloužící pro ukládání získaných údajů z databáze. Tyto parametry je možné nastavit i příslušnými set metodami (metody sloužící pouze k nastavení nějakého atributu). Pokud jsou parametry řádně nastaveny, je možné tělo funkce spustit metodou start, která vytvoří nové vlákno pro metodu run. Funkcionalita této metody je rozdělena do několika privátních metod pro lepší srozumitelnost kódu. Metoda run funguje následovně: 1. Ověří platnost parametrů. 2. Zavolá metodu lastFileModified pro zjištění aktuálního databázového souboru. 3. Spustí while cyklus, který má jako podmínku proměnnou typu boolean nastavitelnou set metodou. 23 5- IMPLEMENTACE (a) Vytvoří spojení na databázi. (b) Zašle dotazy do databáze. (c) Získané odpovědi uloží do entity MeteoData. (d) Uzavře spojení na databázi. (e) Získá nejnovější soubor ve složce pro další běh cyklu. Metoda lastFileModified pracuje na jednoduchém principu porovnávání času poslední úpravy souboru. Tento způsob výběru databázového souboru jsem zvolil ze dvou důvodů. Složka obsahující databázový soubor obsahuje pouze databázové soubory je tedy zaručeno, že bude vybrán ten správný a omezí se tak riziko lidského omylu. Druhý důvod je způsob vytváření těchto souborů. Databázový soubor je vytvořen jednou týdně a po celý následující týden jsou do něj data zapisována. Udržováním ukazatele vždy na nejnovější soubor se eliminuje riziko, že by se zapomněl zvolit nový soubor po jeho vytvoření. While cyklus se zde stará o pravidelnou kontrolu databáze. Aby nedocházelo k příliš častým připojením, tak je vlákno po úspěšném získání dat na několik sekund uspáno. Tímto způsobem je možné regulovat frekvenci aktualizací databáze. Vláknové aplikace mohou mít problém s ukončováním, pokud běží delší dobu. Vzhledem k předpokladu, že aplikace poběží několik hodin, tak je dobré, aby aplikace měla možnost vlákna rozumným způsobem ukončovat. Proto je while cyklus kontrolovatelný proměnnou typu boolean. Pokud budu chtít vlákno zastavit, tak nastavím proměnnou na falše, vlákno dokončí aktuální cyklus a pak skončí. Toto je nejpřirozenější způsob ukončení vlákna. Pokud bude chtít uživatel znovu spustit získávání dat z databáze, tak aplikace nejdříve ověří, zda byl předchozí běh ukončen. Toto je zabezpečení, aby nedošlo k případu, kdy bude několik vláken současně přistupovat ke stejné databázi. Pro získávání nejnovějších údajů z databáze slouží následující příkaz, kde TABLE je zastoupeno tabulkou obsahující odpovídající údaj. select * from TABLE order by TIME desc limit 1 24 5- IMPLEMENTACE Vzhledem k tomu, že tabulka vždy obsahuje pouze časové razítko a hodnotu reprezentující údaj dle názvu tabulky, je takto vybrán pouze potřebný údaj, ten nejnovější. 5.7 Balík fits Tento balík obsahuje dvě třídy, FolderWatch a FitsFileUpdate. Tyto třídy zajišťují úpravy na FITS souborech. FolderWatch se stará o detekci nově vzniklých FITS souborů a FitsFileUpdate se stará následně o jejich úpravu. 5.7.1 FolderWatch Tato třída zajišťuje detekování nově vzniklých FITS souborů ve zvolené složce, aby mohly být následně doplněny o potřebné údaje z databáze. Z této definice vyplývá, že funkce bude aktivní většinu běhu aplikace, podobně jako získávání údajů z databáze. Třída tedy implementuje rozhraní Runnable [17], aby mohla běžet v samostatném vlákně a neovlivňovala výkon aplikace. Třída obsahuje dva konstruktory, jeden bezparametrický a jeden s nezbytnými parametry pro běh. Prvním parametrem je cesta k adresáři, do kterého se zapisují nově vzniklé FITS soubory. Další dva parametry specifikují entity, ze kterých se budou získávat meteorologická data a souřadnice. Poslední parametr je název pozorovaného objektu. Tyto parametry je samozřejmě možné nastavit i příslušnými set metodami. Jakmile jsou parametry nastaveny, je možné spustit metodu start, která vytvoří nové vlákno pro metodu run. Metoda run je složena z několika privátních funkcí vykonávajících úkony v tomto pořadí: 1. Ověří platnost parametrů. 2. Získá souborový systém na zadané cestě. 3. Vytvoří WatchService pro tento souborový systém a jako sledovanou událost zaregistruje vytvoření souboru. 4. Spustí while cyklus, který má jako podmínku proměnnou typu boolean nastavitelnou set metodou. 25 5- IMPLEMENTACE (a) Čeká na novou událost. (b) Pokud je nová událost vznik souboru, tak ověří, zda se jedná o FITS soubor. (c) Pokud jsou podmínky splněny, tak v novém vlákně spustí úpravu souboru pomocí třídy FitsFileUpdate. (d) Zkontroluje, zda nedošlo k přerušení, pokud ne, tak spustí další běh while cyklu. Sledování cílové složky je realizováno pomocí třídy WatchService [18]. Tato třída umožňuje pro zaregistrovaný objekt sledovat změny a události. V tomto případě je sledovaným objektem cílová složka a sledované změny jsou omezeny pouze na vznik nových souborů. Další události, které lze sledovat, jsou např. úpravy nebo smazání existujícího souboru. V našem případě nás zajímají pouze nově pořízené soubory, proto jsem využil filtrování pouze na tento typ události. Jakmile je nový soubor detekován, tak je ověřeno, zda se jedná o FITS soubor. Pokud ano, tak za pomoci třídy FitsFileUpdate je provedena aktualizace souboru. Pro ovládání while cyklu je zde opět použita proměnná typu boolean, podobně jako v případě tříd pro extrakci dat z databáze. Na rozdíl od těchto tříd je zde ovládání trochu složitější. V případě třídy MeteoDatabaseService průběh jednoho kola cyklu trvá nějakou pevně stanovenou dobu a je následně ukončen. V případě FolderWatch jeden průběh nemá shora omezenou dobu provádění. Další cyklus se spustí až po zaregistrování a zpracování události. Z tohoto důvodu jsem přidal metodu stop, která mimo nastavení proměnné typu boolean na falše, spustí událost vytvoření souboru a přinutí metodu run k dokončení aktuálního běhu while cyklu. 5.7.2 FitsFileUpdate Tato třída je zodpovědná za provedení úprav na FITS souboru. Provedené úpravy zahrnují doplnění: • názvu pozorovaného objektu, • souřadnic pozorovaného objektu, 26 5- IMPLEMENTACE • vybraných meteorologických údajů, • zeměpisných souřadnic dalekohledu odkud byl snímek pořízen, • nadmořskou výšku místa odkud byl snímek pořízen. Z pohledu uživatele se jedná o velice jednoduchou třídu obsahující konstruktor se všemi nutnými parametry (název objektu, entita pro meteorologická data, entita pro souřadnice a jméno souboru) pro provedení úprav FITS souboru a metodu pro spuštění těchto úprav. Samotná úprava souboru se spouští v samostatném vlákně, aby negativně neovlivňovala jiné funkce aplikace. Třída implementuje rozhraní Runnable [17] pro zajištění této funkcionality. Upravování souboru je spuštěno metodou start, která vytvoří nové vlákno pro metodu run, provádějící úpravy. Změny jsou realizovány pomocí několika privátních metod, zodpovědných za specifické úkoly (přepočty a zápis do souboru). Běh metody run lze rozdělit do těchto kroků: 1. Ověří platnost parametrů. 2. Načte FITS soubor. 3. Provede kontrolu dostupných údajů (některé údaje jsou nepovinné, ale nutné pro přepočet). 4. Přepočte údaje do potřebných formátů. 5. Načte hlavičku FITS souboru a vloží do ní nové záznamy. 6. Vytvoří záložní soubor. 7. Zapíše změny do původního souboru, v případě úspěchu smaže záložní soubor. 8. Uzavře soubor. K provádění změn využívám knihovnu nom-tam FITS [12], blíže popsanou v předchozí kapitole. Aby bylo možné pracovat s FITS souborem na logické úrovní, kde stačí pouze určit, že chci upravovat hlavičku souboru, je nutné soubor načíst do proměnné typu Fits. Na této proměnné vyberu hlavičku, kterou budu měnit. Nad vybranou 27 5- IMPLEMENTACE hlavičkou volám metodu addValue, vkládající nové záznamy do hlavičky nebo upravující již existující. Metoda obsahuje tři parametry název údaje, hodnotu údaje a komentář. Název údaje právě určuje, zda se bude jednat o vložení nového údaje do hlavičky, nebo o změnu existujícího. Pokud už v hlavičce záznam s tímto názvem existuje, tak se pouze změní hodnota a komentář, v opačném případě se vytvoří nový záznam. Hodnota obsahuje buď řetězec znaků, nebo číselnou hodnotu. Ačkoli je komentář volitelná část, tak ho využívám pro všechny hodnoty ze dvou důvodů. Prvním důvodem je uvedení jednotek. Vzhledem k omezeným možnostem zápisu symbolů není možné použít mnohé znaky jako °C. Využití komentáře je jedinou možností, jak specifikovat jednotky pro všechny hodnoty v přehledném formátu. Druhým důvodem k použití komentářů je srozumitelnost. Délka názvu záznamu je omezena pouze na 8 znaků, pro některé údaje jako vlhkost (HUMIDITY) je toto omezení nedůležité, údaje jako teplota v kopuli již nelze zapsat zcela jednoznačně pouze v osmi znacích. Proto je za název zvolena výstižná zkratka (pro teplotu v kopuli je použito TEMP_IN) a v komentáři je uveden kompletní název. Údaje zapisované do hlavičky jsou dvou typů. Prvním jsou údaje, které mohou být zapsány tak, jak byly získány (např. teplota nebo rychlost větru), druhý typ vyžaduje před zápisem přepočet. Přepočítávané údaje jsou tlak na úrovni hladiny moře, rektascenze a deklinace. Aby nebyly tyto výpočty prováděny při každém získání nových údajů, ale pouze pokud je potřeba, jsou přepočty provedeny až při zápisu údajů do souboru. Pro tlak se jedná o přepočet tlaku vzduchu na úrovni observatoře na tlak na úrovni hladiny moře. K tomuto výpočtu využívám barometrickou formuli [19]: Pm = Pabs + (h/'8,3) Pm je výsledný tlak u hladiny moře v [hPa] Pat,s je tlak v místě měření v [hPa] h je nadmořská výška v [m] Rektascenze a deklinace je z databáze získávána pouze ve stupních, ale ve FITS souboru je požadováno, aby byla i v pro člověka čitelnějších jednotkách, stupních (hodinách pro rektascenzi), minutách a sekundách. Přepočet pro rektascenzi je následovný: 28 5- IMPLEMENTACE h = [X/15\ m = [(X/15-h) * 6 0 J s = ((X/15 - h) * 60 - m) * 60 (5.1) (5.2) (5.3) h, m, s jsou výsledné hodnoty pro hodiny, minuty a sekundy, kde hodiny a minuty jsou celá čísla a sekundy jsou desetinné číslo X je původní hodnota rektascenze ve stupních Pro deklinaci je výpočet podobný, jenom první údaj se udává ve stupních a ne v hodinách. Proto se první údaj nedelí patnácti, ale vezme se pouze jeho celá část. Ve výše uvedených formulích dosadím za X / 1 5 pouze X. Jakmile jsou všechny údaje přepočteny a vloženy do hlavičky, tak může být soubor uložen. Zde nastává problém, protože není možné zaručit, že nedojde k nějaké neočekávané chybě. Z tohoto důvodu zachovávám původní soubor, dokud nejsou změny úspěšně provedeny v novém souboru. Při ukládání změn nejdříve vytvořím záložní soubor s koncovkou .orig. Pokud uložení změn proběhne úspěšně, tak je tento záložní soubor smazán. V případě jakékoliv chyby je možné původní soubor obnovit odmazáním koncovky .orig. 5.8 AstroCameraUI Tato třída ve stejnojmenném balíku má na starost vytvoření uživatelského rozhraní pro ovládání aplikace. S výjimkou dvou funkcí (saveProperties a loadProperties) obsahuje pouze funkce na obsluhu tlačítek. Uživatelské rozhraní má podobu okna se dvěma záložkami, oddělujícími funkce do dvou celků (viz obrázek v sekci 7.1). První záložka slouží jako hlavní ovládací prvek. V horní části jsou možnosti pro vyhledání objektu v online databázi (tlačítko Search online), načtení souřadnic ze souboru (Load from file), získání aktuálních souřadnic natočení teleskopu a uložení do souboru pod zvoleným jménem (Save current coordinates). V případě, že byl vybrán objekt pro pozorování, tak je možné souřadnice zaslat do teleskopu. Pro tento účel jsou uprostřed první 29 5- IMPLEMENTACE záložky zobrazeny údaje o vybraném objektu (název, rektascenze a deklinace) a je zde i tlačítko pro zaslání. Spodní část slouží pro nastavení jména pozorovatele, IP adresy, portu a hesla pro přihlášení k řídícímu počítači. Pod těmito údaji se nachází už jen oblast pro vypisování důležitých informací při běhu programu. Jedná se především o upozornění na chyby a zahájení, případně ukončení klíčových funkcí. Druhá záložka umožňuje nastavení adresářů nutných pro běh aplikace a možnost spuštění případně pozastavení činnosti nad nimi. Jedná se o adresáře pro vzniklé FITS soubory, databáze obsahující meteorologická data a databáze obsahující souřadnice z teleskopu. Funkcionalita operací prováděných ovládacími prvky uživatelkého rozhraní spočívá především v předávání parametrů a volání funkcí z jiných balíků. Vzhledem k potřebě nastavení několika parametrů u každého běhu aplikace bylo spouštění příliš zdlouhavé. Z tohoto důvodu jsem se rozhodl umožnit ukládání většiny stálých nastavení do konfiguračního souboru. Při spuštění aplikace jsou parametry nahrány ze souboru a nastaveny, aby umožnili běh s minimálním, nebo žádným zásahem do nastavení. Naopak při změnách nastavení se tyto změny uloží do konfiguračního souboru. 30 6 Zajímavosti při implementaci Během implementace jsem narazil na několik zajímavých problémů, v této kapitole bych chtěl tyto problémy blíže popsat, uvést jejich příčinu a řešení, které jsem použil pro jejich odstranění. Protože jsem neměl možnost přímého přístupu k systému, ve kterém měla aplikace pracovat, tak jsem pro první testování používal zjednodušené prostředí. Pro testování přístupu k databázi jsem měl k dispozici kopie dvou databázových souborů a pro zápis do souboru jsem měl FITS soubory, které jsem si sám vytvořil. Až v pozdější fázi jsem pracoval s FITS souborem pořízeným ve stávajícím systému. Z tohoto důvodu se dalo předpokládat, že se objeví některé problémy až při testováním v normálním prostředí. Zvolil jsem proto přístup, kdy jsem poskytoval testovací verze od momentu, kdy to bylo možné, aby se co nejvíce problémů odstranilo v rané fázi. Většina problémů byly drobnosti týkající se nastavení, ale dva problémy byly zajímavější a proto jsem se rozhodl je zde uvést: • problém s úpravou FITS souborů, • problém s přístupem k databázi. 6.1 Problém s úpravou FITS souborů Úprava FITS souboru probíhá v několika krocích: 1. Nový soubor je detekován. 2. FITS soubor je otevřen. 3. Jsou provedeny úpravy nad FITS hlavičkou. 4. FITS soubor je uložen. V iniciální fázi běžela úprava souboru ve stejném vlákně jako detekce souboru, vzhledem k předpokládanému intervalu mezi pořízenými snímky (čas pořízení snímku měl být vyšší než ls) se zdálo toto řešení jako možné. Během testování v omezeném prostředí vše fungovalo naprosto bez problémů, stejně dopadlo i krátké otestování v reálném 31 6. ZAJÍMAVOSTI PŘI IMPLEMENTACI systému. Při běžném nasazení se ovšem objevil problém. Úprava prvního souboru proběhla v pořádku, ale druhý soubor už nebylo možné upravit. Tento problém se neprojevoval v simulovaném prostředí, takže jsem předpokládal, že zde bude na vině velikost souboru. Já jsem používal FITS soubor bez obrazové informace o velikosti desítek kB a v reálném prostředí se vytvářely soubory o velikosti několika MB. Po vyzkoušení s větším souborem, jsem byl schopen problém replikovat. Řešení se zdálo být jednoduché, úpravu souborů jsem přesunul do samostatného vlákna pro každý soubor, takže soubory jdoucí po sobě se už nebudou ovlivňovat i kdyby měly velikost v řádu desítek MB. Toto řešení jsem otestoval a vše už normálně fungovalo. Při nasazení v reálném prostředí problém nadále přetrvával. Použitá knihovna nom-tam FITS nebyla schopna druhý soubor otevřít. Dokumentace zde bohužel moc nápomocná nebyla, k této chybě docházelo pokud se nepodařilo najít strukturu FITS souboru. Předpokládal jsem, že k tomuto problému dochází v případě, že soubor ještě není úplně zapsán na disku. Tuto teorii jsem si ověřil, když jsem zkusil zapsat několik FITS souborů za 1 sekundu, při použití souborů o velikostí v řádu desítek MB. V reálném prostředí byly použity disky s pomalejší rychlostí zápisu a z tohoto důvodu se problém projevoval i u menších souborů při menší frekvenci. Díky této znalosti jsem mohl hledat řešení, které by bylo nezávislé na použitém HW. Použitá detekce nových souborů nahlásila nový soubor jakmile se začal zapisovat na disk, ne ve chvíli kdy byl zápis dokončen. Řešením bylo tedy počkat, až bude soubor plně zapsán. Tento stav šlo buď zjistit naléhavým způsobem, tj. kontrolovat neustále zda je soubor připraven nebo použít nenaléhavý způsob, kdy vyčkám určitou dobu před pokusem o provedení úprav. Vzhledem k tomu, že úprava souboru už byla v samostatném vlákně, tak nenaléhavý způsob se jevil jako lepší řešení. Vložil jsem tedy krátkou pauzu mezi detekci souboru a jeho otevření, na výsledku se toto zpoždění téměř neprojeví a narozdíl od naléhavého přístupu nebude zatěžovat disk pokusy o čtení. Pro současný systém je toto řešení dostačující, v budoucnu by mohlo dojít k možným problémům, pokud by došlo k výrazným změnám v systému. Pokud by byla použita např. CCD kamera, která 32 6. ZAJÍMAVOSTI PŘI IMPLEMENTACI by pořizovala snímky s mnohem lepším rozlišením a použité disky by nebyly vylepšeny, mohl by se problém opakovat. V případě použití současného návrhu, by byly nutné nejspíš malé změny v použitých údajích. Na druhou stranu předpokládám, že při použití kamery, která by pořizovala snímky řádově větší, by bylo nutné použít novější a větší disky nebo disková pole, aby bylo možné tyto snímky nadále uchovávat. 6.2 Problém s přístupem k databázi Získávání aktuálních souřadnic středu dalekohledu a meteorologických údajů je realizováno ve dvou krocích: 1. Je detekován nejnovější soubor. 2. Proběhne připojení k nejnovějŠímu souboru a získání potřebných dat. Vzhledem k tomu, že adresáře s těmito databázovými soubory obsahují pouze tyto databázové soubory, lišící se jen časovým úsekem, pro který obsahují data, zdál se výše uvedený postup jako vhodné řešení. Odstraní se tím problém, kdy by uživatel zapomněl přenastavit cílový soubor pro nový týden, a zároveň pokud by k této změně došlo během pozorování, tak by se s tím uměl program sám vypořádat. Během testování se statickými databázemi (žádné aktualizace do nich zapisovány nebyly) se nevyskytly žádné problémy i během provozu po několik hodin. V reálném prostředí k chybě docházelo po několika minutách běhu. Problémem se zdál případ, kdy probíhala aktualizace databáze a zároveň probíhala detekce nejnovějšího souboru v adresáři. Zápis do databáze si vytvoří záložní soubor během zápisu. Tento nový soubor je detekován a následně se k němu pokusí program připojit. Zde nastává problém, protože tento záložní soubor se nechová jako databáze, a navíc už nemusí existovat. Pro vyzkoušení, zda je toto skutečně příčina problému, jsem dočasně odstranil detekci nejnovějšího souboru z cyklu a nechal jsem ji pouze při spuštění. Databázový soubor, ke kterému se program připojoval, zůstával tedy po celou dobu stejný. Z počátku se zdálo, že byl problém vyřešen, ale po několika desítkách minut běhu opět došlo k chybě v připojení. 33 6. ZAJÍMAVOSTI PŘI IMPLEMENTACI Jedinou možnou příčinou mohl být současný přístup k databázi, když probíhala její aktualizace. Vzhledem k tomu, že program z databáze pouze čte, tak jsem hledal možnost nastavení úrovně přístupu, který by umožnil více aplikacím přistupovat současně, ale pouze jedné aplikaci zapisovat. Bohužel SQLite [20] použitý pro databáze tento typ přístupu neumožňuje. Je možné, aby více aplikací přistupovalo současně, ale ve chvíli, kdy jedna aplikace zapisuje, tak je databáze uzamčena. Tento proces trvá několik milisekund, proto k problému došlo až po nějaké době, kdy se aktualizace střetly se získáváním dat. Bylo zde několik možných řešení. Pokud by se používala jiná databáze, umožňující lepší podporu současného přístupu více aplikací, tak by byl problém pravděpodobně odstraněn. Toto řešení by bylo velmi nepraktické a nákladné. Druhým řešením by bylo využití API pro SQLite umožňující nastavení čekání v případě kolize. Bohužel toto API je pouze pro jazyk C, což by znamenalo buď úplné předělání současného programu do jiného jazyka nebo emulaci kódu jazyka C v Javě. První možnost rozhodně nebyla vhodná vzhledem k tomu, že současný program už byl skoro hotov, navíc nezaručovala, že nedojde k jinému problému. Druhá možnost byla reálná, ale rozhodl jsem se použít ještě jiné řešení. Ošetření problému současného přístupu pomocí nastavení času pro vyčkání u vykonávaného příkazu bylo sice řešení, ale v případě jakékoliv jiné chyby by opět došlo k selhání. Z tohoto důvodu jsem implementoval řešení, které sice není tolik elegantní, jako nastavení detailů pro připojení, ale je mnohem více robustní. Přesunul jsem ošetřování všech výjimek do těla cyklu pro získávání dat a nastavil vše tak, aby i v případě selhání nedošlo k pádu. Pokud dojde k jakémukoliv problému, tak je uživatel informován o nastalé situaci, pokud je však možné, aby se program sám z této situace dostal, tak se zotaví. V případě přístupu v době aktualizace se jedno kolo přeskočí a za tři sekundy se pokusí získat data znovu. V provozu, kdy k této chybě docházelo lx za několik set připojení, se chyba neprojeví, pokud by však došlo k závažnější situaci, tak má uživatel stále možnost aplikaci zastavit. Drobné problémy aplikace překoná i bez zásahu uživatele. Zároveň jsem zajistil vybrání správného aktuálního databázového souboru kontrolou názvu získaného objektu. Tato kontrola by měla zaručit správné chování v případě, že by byl detekován nesprávný soubor jako nejnovější. 34 7 Návod k použití Tato kapitola se zabývá rozborem uživatelského rozhraní a obsahuje i instrukce pro jeho používání. Výsledná aplikace zajišťující požadovanou funkcionalitu je ve formě spustitelného JAR archivu. Mimo tento soubor jsou pro provoz využívány další dva soubory, config.properties a uživatelem pojmenovaný textový soubor obsahující souřadnice. 7.1 AstroCamera Spustitelná aplikace AstroCamera se skládá z okna obsahující dvě záložky. Funkcionalita je rozdělena do těchto záložek tak, aby první záložka obsahovala nejdůležitější funkce, které budou využívány několikrát během provozu, zatímco druhá záložka obsahuje konfiguraci, která probíhá nanejvýš jednou při spuštění aplikace. 7.1.1 Záložka Main Tato záložka je výchozí a hlavní ovládací část aplikace. V horní části se nachází textové pole sloužící pro zadání hledaného objektu. Vedle něj jsou dvě tlačítka pro vyhledání. Search online slouží k vyhledání v online databázi, zatímco Load from file umožňuje vyhledání objektu ve vybraném souboru se souřadnicemi. V případě úspěšného vyhledání je jméno a souřadnice objektu zapsáno do zvýrazněné oblasti Selected object uprostřed okna. V druhém řádku od shora je možné zadat jméno, pod kterým chci uložit současné souřadnice natočení dalekohledu do vybraného souboru se souřadnicemi. Tlačítko Save current coordinates tyto souřadnice získá a uloží do souboru. Ve střední části okna se nachází zvýrazněná oblast Selected object obsahující informace o vybraném objektu. Pokud je pozorovatel spokojen s tímto výběrem, tak pomocí tlačítka Confirm může souřadnice zaslat do programu pro řízení dalekohledu. Zároveň je zde potvrzené jméno objektu použito jako jméno objektu při zápisu metadat do FITS souboru. Spodní část slouží k nastavení dodatečných informací a k informačním účelům. Do textového pole Observer je možné vložit jméno 35 7- NÁVOD K POUŽITÍ [ Main J Settings Object name: Save to file as: | Search online j | Load from file ^ Save current coordinates Selected Object Name: name RA: right ascension DEC: declination Confirm Observer: IP: 127.0.0.1 Port: [ 2000 |T] Password: passwd Obrázek 7.1: Záložka Main v.1.0 36 7- NÁVOD K POUŽITÍ Main Settings Photo folder: D:\muo\photo Browse Heteo DB file location: D:\rruio\meteo Browse Tele DEI file location: D:\rruio\telernetric Browse Coordinates file location: D:\rruio\coord.txt Browse Confirm and start Stop Obrázek 7.2: Záložka Settings pozorovatele, který uskutečnil pozorování. Pole IP, Port a Password slouží k zadání IP adresy a portu řídícího počítače a heslo pro přihlášení se do programu TCS, který natáčení dalekohledu provádí. Tyto údaje jsou ukládány do konfiguračního souboru, aby je nebylo nutné zadávat znovu při každém spuštění. Úplně dole se nachází konzole, do které jsou vypisovány nejdůležitější informace týkající se běhu, případně je zde uživatel informován o chybách, ke kterým může dojít. 7.1.2 Záložka Settings Druhá záložka, Settings, slouží k nastavení cest k potřebným souborům a adresářům, a také ke spuštění procesu monitorování. Ve směru od shora dolů se zde nachází textová pole se zobrazenou aktuální vybranou cestou a tlačítkem pro výběr této cesty pro: • adresář obsahující nově pořízené FITS soubory, • adresář obsahující databázové soubory s meteorologickými údaji, 37 7- NÁVOD K POUŽITÍ • adresář obsahující databázové soubory se souřadnicemi, • soubor se souřadnicemi. Dole se nachází dvě tlačítka: Confirm and start pro zahájení monitorování a Stop pro přerušení monitorování. Pole s vybranými databázovými adresáři mají vedle sebe navíc ukazatel činnosti (Progress bar) znázorňující, že je monitorování aktivní. Veškeré nastavení adresářů a souborů je uloženo v konfiguračním souboru, aby nebylo nutné zadávat cestu znovu při každém spuštění aplikace. 7.2 Konfigurační soubor a soubor se souřadnicemi Konfigurační soubor config.properties slouží k uchovávání nastavení mezi jednotlivými spuštěními programu AstroCamera. Jednotlivé údaje jsou uloženy ve formátu: název parametru = hodnota parametru Ukládané údaje a příslušné názvy parametrů jsou: • longitude - zeměpisná délka observatoře, • latitude - zeměpisná šířka observatoře, • elevation - nadmořská výška observatoře, • ip - IP adresa řídícího počítače, • port - port na kterém naslouchá program pro řízení teleskopu, • password - heslo pro přihlášení do TCS, • photo - adresář s nově pořízenými FITS soubory, • meteo - adresář s databázovými soubory obsahující meteorologické údaje, • tele - adresář s databázovými soubory obsahující aktuální sou­ řadnice, • coord - soubor se souřadnicemi. 38 7- NÁVOD K POUŽITÍ Většina těchto parametrů je jednoznačných a pro ukázku je možné nahlédnout do příloh obsahující ukázkový konfigurační soubor. Chtěl bych zde vyzdvihnout parametr password uchovávající heslo v nezašifrované podobě. Za normálních okolností by toto nebyl bezpečný způsob uchovávání hesla. Uchovávání zašifrovaného hesla ovšem není v tomto případě lepším řešením. Vzhledem k omezené délce hesla a povoleným znakům (pouze čísla), je velice jednoduché získat heslo hrubou silou. Dalším slabým místem je přenos samotného hesla, který probíhá v nezašifrované podobě, protože ASCOL protokol neumožňuje šifrování. Tedy ani verze, kde by heslo nebylo uloženo vůbec, není zcela bezpečná. Použité řešení nabízí usnadnění práce uživateli a spoléhá na zabezpečení sítě jako na ochranu před odposlechnutím hesla. Soubor se souřadnicemi je obyčejný textový soubor, takže jeho modifikace je velice jednoduchá. Jednotlivé záznamy se musí nacházet na samostatných řádcích a názvy záznamů by měly být unikátní. Formát záznamu je následující: název objektu#rektascenze#deklinace#volitelný komentář Rektascenze (deklinace) musí být zapsány ve formátu: hodiny (stupně), minuty a sekundy. Mezi jednotlivými jednotkami mohou a nemusí být mezery. Ukázkový soubor je opět možné najít v přílohách. Při získání aktuálních souřadnic z teleskopu je výše uvedený formát samozřejmě dodržen. 39 8 Závěr Cílem práce bylo vytvoření nástroje pro Ústav teoretické fyziky a astrofyziky Přírodovědecké fakulty Masarykovy univerzity v Brně, který bude provádět automatický zápis metadat do nově pořízených FITS souborů, a vytvoření nástroje pro překlad názvu astronomického objektu na souřadnice a předání těchto souřadnic do softwaru pro řízení dalekohledu. Výsledkem práce je aplikace AstroCamera v programovacím jazyce Java s grafickým uživatelským rozhraním. Aplikace umožňuje vyhledání objektu v online databázi nebo v uživatelem definovaném souboru obsahujícím názvy objektů a jejich souřadnice. Vybrané souřadnice je možné zaslat do řídícího počítače ovládajícího dalekohled. Souřadnice je z řídícího počítače možné také získat a uložit do uživatelem zvoleného souboru se souřadnicemi pod jím zvoleným názvem. Získávání údajů pro úpravu metadat FITS souborů probíhá v reálném čase z databázových souborů. V případě pořízení nového FITS souboru je tento soubor doplněn o tyto údaje z databází, a navíc o některé další údaje definované uživatelem (zeměpisná poloha a jméno pozorovatele). Výsledná aplikace je navržena tak, aby vyžadovala minimum konfigurace při každém použití a aby její ovládání bylo rychlé a jednoduché. Aplikace byla během vývoje testována a konzultována se zadavatelem tak, aby splňovala všechny iniciální požadavky, i ty, které vznikly během vývoje. Dalším výsledkem práce je tento text obsahující popis návrhu a implementace vytvořené aplikace společně s jednoduchým návodem k jejímu používání. Jsou zde stručně popsány i použité technologie, které nepatří mezi běžně používané. Přílohy obsahují spustitelný JAR archiv s výslednou aplikací, zdrojové kódy aplikace, ukázkový konfigurační soubor a ukázkový soubor se souřadnicemi. Aplikace byla v provozu po dobu jednoho roku, kdy se ukázalo, že některé funkce nejsou v samotném rozhraní zapotřebí (údaje pro připojení k ovládání dalekohledu) a jejich konfigurace stačí pouze přes konfigurační soubor. V dodatečných úpravách proto byla tato část rozhraní odebrána. Dále provoz odhalil, že přepínání jazykové 41 8. ZÁVĚR verze na základě nastavení operačního systému není ideální, protože rozhraní užívali i zahraniční uživatelé. Proto byla přidána možnost přepínání jazykové verze a uložení této volby v konfiguračním souboru. Během provozu se po čase ukázalo, že původně zvolená databáze pro vyhledávání souřadnic neobsahuje některé objekty, případně jsou jejich souřadnice neúplné. Z tohoto důvodu jsem rozšířil vyhledávání ještě o další webovou databázi (AAVSO) [21]. Poslední větší úprava spočívala v přidání funkce, která na základě metadat o typu snímku mění název vytvářených souborů. Výsledné soubory jsou tak snadněji zařaditelné. Tyto úpravy nejsou součástí této práce, ale jsou zde zmíněny pro demonstraci možných dodatečných změn. Budoucí rozšíření mohou zahrnovat přidání ovládání pro další prvky observatoře, případně rozšíření některých stávajících funkcí v závislosti na používání tohoto nástroje. 42 Literatura [1] Astronomy. 2016. URL: https : / / en . wikipedia . org / wiki / Astronomy (cit. 12.05.2016). [2] Java Software, URL: https : //www. oracle. com/j ava/index. html (cit. 12.05.2014). [3] ProjectSoft. 2016. URL: http: //www. proj ectsof t. cz/ (cit. 12.05.2016). [4] Moravské přístroje, CCD kamery pro astronomii. 2016. URL: http : //www.gxccd. com/ (cit. 12.05.2016). [5] Right Ascension. 2016. URL: https : //en. wikipedia. org/wiki/ Right_ascension (cit. 12.05.2016). [6] Ota Kéhar. Slovník astronomických pojmů. 2016. URL: http: //home. zcu . cz/~kehar/astrokoutek/slovnik/slovnik4 . html (cit. 12.05.2016). [7] Declination. 2016. URL: https : / / en . wikipedia . org / wiki / Declination (cit. 12.05.2016). [8] FITS. 2016. URL: https : / /en . wikipedia . org/wiki/FITS (cit. 12.05.2016). [9] FITS Working Group. Definition of the Flexible Image Transport System(FITS). 2010. URL: http: //f its. gsf c. nasa. gov/standard30/ fits_standard30aa.pdf (cit. 12.05.2016). [10] Ing. Tomáš Turek. Řízení dalekohledů, ASCOL příkazy, manual. ProjectSoft, 2010. [11] FITS I/O Libraries. 2015. URL: http : / / f i t s . gsfc . nasa . gov/ fits_libraries.html (cit. 12.05.2016). [12] An introduction to the nom.tam FITS library, URL: http: //heasarc. gsfc.nasa.gov/docs/heasarc/fits/java/vl.0/FitsLib.pdf (cit. 13.05.2016). [13] NASA Exoplanet Archive. 2016. URL: http: //exoplanetarchive. ipac. caltech. edu/docs/program_interf aces . html (cit. 13.05.2016). [14] SIMBAD Astronomical Database. 2016. URL: http : //simbad . u strasbg.fr/simbad/ (cit. 13.05.2016). [15] SQLite. 2016. URL: https : //www. sqlite. org/ (cit. 20.05.2016). [16] SQLiteJDBC Driver. 2015. URL: https : //bitbucket. org/xerial/ sqlite-jdbc (cit. 20.05.2016). [17] InterfaceRunnable. 2016. URL: https : //docs. oracle. com/javase/ 7/docs/api/java/lang/Runnable.html (cit. 13.05.2016). 43 LITERATURA [18] Interface WatchService. 2016. URL: https : //docs . oracle . com/ javase/7/docs/api/java/nio/f ile/WatchService . html (cit. 13.05.2016). [19] Ing. Miloš Jiŕík. Amatérska meteorologická stanice. 2016. URL: http: //pocasi . ok5aw. cz/teorie .php?doc=pagel (cit. 13.05.2016). [20] SQLite, Frequently Asked Questions. 2016. URL: https : / / www . sqlite . org/f aq. html#q5 (cit. 14. 05. 2016). [21] American Association of Variable Star Observers. 2016. URL: https: //www. aavso. org/ (cit. 30.04.2017). [22] Class DatalnputStream. 2016. URL: https : //docs . oracle . com/ javase / 7 / docs / api / Java / io / DatalnputStream . html (cit. 14.05.2016). [23] Martin Vrábel. Nástroj pro úpravy hlaviček FITS souború. 2016. URL: https : / / i s .muni . cz/auth/th/410074/f i_b/thesis .pdf (cit. 14.05.2016). 44 A Přílohy 1. spustitelný program AstroCamera v podobě Java archivu, AstroCamera- 1.0.jar, 2. zdrojové kódy programu AstroCamera, AstroCamera.zip, 3. ukázkový konfigurační soubor, config.properties, 4. ukázkový soubor se souřadnicemi, coord.txt. 45