\chapter{Koncepce sběru dat}
Úkolem navrhovaného systému je zaznamenávat časový průběh veličin z technologického procesu. Veličiny jsou měřeny čidly připojenými na analogové vstupy průmyslových automatů firmy Micropel. Odkud mohou být přečteny přes průmyslovou sběrnici RS485. Naměřená data by měla být dlouhodobě uchována (dle aplikace i několik let). Zaznamenaná data by měla být pohodlně přístupná uživateli tak, aby z nich šlo jednoduše vytvářet protokoly. Kde je to možné měly by být vytvářeny protokoly automaticky. Z časových úseků odpovídajících jednotlivým šaržím produktu (bude popsáno podrobně u konkrétních aplikací). Každý protokol musí obsahovat jednak graf, pomocí kterého je možné získat rychlý přehled o průběhu procesu a také tabulku hodnot, ze které lze získat přesné hodnoty. V některých případech je vhodné, aby protokol obsahoval závěr shrnující průběh procesu a zhodnocení zda proběhl dle požadavků (ty jsou popsány u jednotlivých aplikací). Vytvořené protokoly by mělo být možné uložit pro pozdější kontrolu a vytisknout pro archivaci či přiloženi jako průvodní dokumentace výrobku.

U navrhovaného systému se předpokládá nejčastější aplikace pro záznam veličin technologických procesů ve farmacii. Zařízení, ze kterých je pořizován záznam bývají často umístěna v čistých prostorách z čehož vyplývají značná omezení. Zařízení umístěná v těchto prostorách musí mít omyvatelné povrchy a nesmějí obsahovat nepřístupné štěrbiny. Umístění klasického osobního počítače s tiskárnou do těchto prostor tedy není možné. Vlastní počítač by bylo možné nahradit vestavným průmyslovým počítačem s dotykovým panelem. Nahrazení tiskárny by  bylo velmi problematické. Z těchto důvodů se zdá jako nejvhodnější přesunout část systému pro interakci s uživatelem dál od monitorovaného zařízení, mimo čisté prostory. 
%TODO: Dopsat požadavky
%\chapter{Popis použitého hardware}

\section{Popis monitorovaných technologických procesů}
Celý systém má být koncipován tak, aby byl co nejuniversálnější a bylo možné ho nasadit při záznamu dat z různých technologických zařízení. Již v době návrhu zařízení jsou známy některé  budoucí aplikace, které určují požadavky na celý systém. Typickými aplikacemi, kde se předpokládá nasazení navrhovaného systému sběru dat je např. parní sterilizátor a lyofilizační přístroj.

\subsection{Parní sterilizace}
Ve zdravotnictví, farmacii i průmyslu je často potřeba zajistit, aby použitý materiál a nástroje neobsahovaly žádné životaschopné mikroorganismy (bakterie, houby, viry atp.). V závislosti na odolnosti příslušného materiálu je možné k jeho sterilizaci použít několik principů. Nejjednodušší možností je jejich zničení použitím zvýšené teploty. Jako medium pro ohřev se používá přefiltrovaný vzduch nebo sytá vodní pára. Pokud je potřeba sterilizovat materiály, které není možné vystavovat vysoké teplotě je možné použít sterilizaci využívající chemických látek nebo ionizujícího záření.

Navrhovaný systém bude sloužit k registraci údajů ze sterilizátoru využívajícího jako medium sytou vodní páru. Sytá vodní pára se využívá pro svoji velkou ohřívací schopnosti (teplo předává svou kondenzací). Další vyhodnou vlastností je u syté vodní páry přesně daný vztah mezi teplotou a tlakem, takže se dá regulací tlaku v prostoru zajistit rovnoměrné rozložení teploty. Celý sterilizační proces se skládá z několika fází. Na začátku se v komoře sterilizátoru opakovaně vytváří podtlak a napustí se párou. Tím se odstraní většina vzduchu (směs vzduchu a páry nemá dobré sterilizační vlastnosti). Po té se přejde k vlastní sterilizaci, která spočívá v udržování předepsané teploty po odpovídající čas. Na závěr se provádí sušení materiálu, které spočívá v udržování podtlaku v komoře při současném ohřívání jejich stěn.

Požadavky na parní sterilizátory, včetně vlastností systému záznamu dat jsou určeny normou ČSN EN 285. Záznam teploty musí být prováděn s přesností \(\pm\)1 °C  v rozsahu (50 °C až 150 °C) s vzorkovací periodou maximálně 2.5 s a záznam tlaku s přesností \(\pm\)5 kPa a vzorkovací periodou maximálně 1 s.

Teplota je měřena v odpadním hrdle komory, kde se předpokládá nejnižší teplota pracovního prostoru v důsledku stékání kondenzátu a shromažďování zbytkového vzduchu (je těžší než vodní pára). V případě sterilizace tekutin je nutné měřit teplotu také v referenční lahvičce za pomocí pohyblivého materiálového čidla. Tlak je měřen tlakovým snímačem připojeným ke komoře. Norma vyžaduje, aby byl celý systém použitý pro kontrolu a registraci nezávislý na systému regulačním. Z toho důvodu  jsou použity dvousystémové snímače teploty, které v jednom pouzdru obsahují dvě nezávislá čidla. Jedno z dvojice čidel je vždy vedeno do automatu sloužícího k regulaci procesu a druhé do automatu použitého pro záznam. Pro měření tlaku jsou použity dva stejné nezávislé snímače. 

V maximální konfiguraci je potřeba zaznamenávat tři údaje o teplotě (jedna teplota v odpadu a maximálně 2 materiálová čidla) a jeden údaj o tlaku. Aby bylo možné jednodušeji odhalit připadné vadné čidlo, bylo by vhodné zaznamenávat také druhou sadu čidel používanou k regulaci. Kvůli vyhodnocení průběhu sterilizace je  potřeba zaznamenávat údaj o aktuální fázi sterilizace.  Celkem je  potřeba zaznamenávat  údajů s vzorkovací periodou 1s (teplotu by stačilo vzorkovat méně často, vzhledem k zobrazení v tabulce je však vhodné, aby byly všechny hodnoty vzorkovány současně). Za předpokladu, že bude zařízení v provozu v průměru 2 hodin denně je tedy nutné každý den uložit 57 600 vzorků.

Vzhledem k charakteru procesu, kde jeden průběh procesu odpovídá vždy jedné šarži výrobku by bylo vhodné, aby byly protokoly vytvářeny automaticky. Ideálně přímo na základě údaje z automatu udávajícího aktuální fázi sterilizace. Vytvořený protokol by měl kromě grafu a tabulky hodnot obsahovat také závěr, ve kterém bude vyhodnoceno zda celý proces proběhl úspěšně. Pro hodnocení účinnosti sterilizačního procesu se používá hodnota ekvivalentní doby sterilizace. Tato hodnota udává účinnost celého sterilizačního procesů ve srovnání se sterilizací za konstantní referenční teploty. Pro sterilizaci sytou vodní párou se bere jako referenční teplota 121°C. Hodnotu ekvivalentní doby sterilizace je možné spočítat podle následujícího vzorce:
\begin{equation}
F0 = \sum \Delta t \cdot 10 ^{\frac{T-121}{10}}
\end{equation}
Kde:
\begin{itemize}
  \item \(\Delta\) t [s] je délka časového úseku
  \item T [°C] je teplota
\end{itemize}

\subsection{Lyofilizační přístroj}
Lyofilizace je proces sušení sublimací. Je využíván k sušení a chemické stabilizaci materiálů, které není možné sušit při zvýšené teplotě. Při tomto procesu se materiál zmrazí na velmi nízkou teplotu (<-60 °C), následně je vložen na police do podtlakové nádoby, ve které je vývěvou snížen tlak na řádově jednotky Pa. Police s produktem jsou ohřívány. Vodní pára vznikající sublimací vody musí být odstraňována namražováním na kondenzátor ochlazovaný na velmi nízkou teplotu (<=70 °C).

Lyofilizační proces se používá pro prodloužení životnosti léčiv, potravin a také při vysoušení vodou poškozených knih a dokumentů. Jeho hlavní nevýhodou je velká časová a energetická náročnost.

Lyofilizační přístroj, pro který má být navrhovaný systém použit, se skládá z tlakové nádoby s 9 vytápěnými policemi. Na vnitřní straně nádoby je navinuta trubka, kterou prochází chladící kapalina a slouží pro kondenzaci vzniklé vodní páry. V každé polici jsou dvě čidla teploty, umístěná ve šroubech zboku zašroubovaných do každé police. Pro měření teploty vlastního materiálu umístěného na policích jsou k dispozici až čtyři přemístitelná čidla teploty. Další čidlo teploty je umístěno na trubce kondenzoru. Tlak je měřen čidlem připojeným na trubce propojující komoru s vývěvou.

Zaznamenávat je tedy potřeba údaje z 14 čidel teploty (9 na policích, 4 materiálové a 1 čidlo na kondenzátoru) a 1 čidlo tlaku. Pro případ poruchy je vhodné zaznamenávat i čidla použitá pro regulaci. Vzhledem k velké setrvačnosti desek a pomalým změnám tlaku je dostačující vzorkovací perioda 5min. Vlastní lyofilizační proces trvá několik dnů a celá výroba je poměrně dost vytížená. Je  potřeba počítat s tím, že záznam běží prakticky nepřetržitě. Při celkovém počtu 30 zaznamenávaných veličin a vzorkovací periodě 5min je  nutné každý den uložit 8640 vzorků.

\section{Řešení dostupná na trhu}
U samostatných zařízení\footnote{V rozsáhlejších systémech se většinou používá centralizovaný sběr dat na SCADA systému. V tomto případě je centrálně zajišťován sběr dat z většího množství zařízení. Touto možností se tato práce nezabývá.} se v současné době se používají 4 základní možnosti záznamu průběhu technologických veličin: mechanické zapisovače, elektronické registrační přistroje, záznam za pomoci PC a záznam za použití systému sloužícího zároveň pro regulaci.

Mechanické zapisovače byly v minulosti jedinou možností automatizovaného záznamu veličin. Většina z těchto zařízení obsahuje cívku s dlouhým pásem papíru, který je pomocí krokového motorku (dříve hodinového strojku) převíjen na druhou cívku. Na procházející papír je pomocí pisátek s barevnými inkousty zaznamenáván průběh měřených veličin. Výstupem je  záznam v podobě grafu, ze kterého je možné poměrně přesně odečítat hodnoty. Z konstrukce těchto zařízení však vychází také mnoho problémů. 
Pokud se pro zápis používají klasická pisátka při zaznamenávání více veličin na jeden papír musejí být vůči sobě posunutá, aby do sebe nenarážela. V důsledku tohoto posunutí jsou vůči sobě jednotlivé křivky posunuty v čase a při přesném odečtu hodnoty v čase je tedy potřeba brát ohled také na posuv každého pisátka. Posuv mezi jednotlivými záznamy  není jediným problémem. Při větším počtu pisátek může docházet, zvláště pokud všechny zapisují stejnou hodnotu, k rozpíjení inkoustu. Některé zapisovače fungují na principu běžné tiskárny a není tedy nutné, aby byly vůči sobě jednotlivé zápisy posunuty, přesto mají některé společné nevýhody. Výstup v podobě grafu je sice výhodný z hlediska rychlého přehledu. Pokud je však nutné pracovat s číselnými údaji je potřeba hodnoty pracně odečítat.

Elektronické registrační přistroje dnes prakticky nahradily zapisovače mechanické. Někdy bývají rozměrově kompatibilní se svými mechanickými předchůdci, takže mohou být použíty jako přímá náhrada. Jsou uloženy na mikropočítači, na kterém běží software zajišťující zápis dat do vnitřní paměti. 
Pro ukládání dat bývá přítomna interní paměť typu flash. Pokud je potřeba pořizovat větší množství záznamů bývá k dispozici slot umožňující použití paměťové karty. Některé elektronické registrační přístroje umožňují kontrolovat zda jsou měřené veličiny v definovaném intervalu a v případě vybočení signalizovat chybu. Jakékoliv další zpracování naměřených dat, případně možnost automatické tvorby protokolů, většinou není možné. Pokud je další zpracování vyžadováno je nutné data přenést na paměťové kartě (nebo po síti, pokud to přistroj umožňuje) do PC a zpracování provést tam. Z hlediska záznamu dat z popisovaných technologií má toto řešení několik nevýhod. Vzhledem k tomu, že automaty použité v této práci mezi sebou komunikují nestandardním protokolem,  není možné použít k nim připojená čidla a pro záznam dat by tak musela být využita další sada. Dalším problémem by byla automatická tvorba protokolů.

Další možností je záznam dat pomocí běžného PC. V tomto případě je PC doplněno o hardware umožňující přístup k měřeným veličinám jako je karta s A/D převodníkem nebo s rozhraním pro komunikaci se sítí PLC. Pro vlastní záznam dat je k dispozici poměrně velké množství programů, často vytvořených výrobci příslušného HW. Jedním příkladem je program DataStore\cite{DataStore} firmy Micropel. Hlavními výhodami tohoto řešení je poměrně nízká cena, velký výkon a velká kapacita paměti (pevného disku). Použití PC má však  několik nevýhod. Patří mezi ně  nižší spolehlivost, vyšší spotřeba, velké rozměry. 

Poslední často využívanou formou sběru dat je záznam za pomocí systému použitého pro řízení vlastního technologického procesu. Záznam dat je prováděn stejným automatem, který řídí proces, často s využitím stejných čidel. Naměřená data jsou v tomto případě většinou přímo tisknuta na vestavěné tiskárně připojené přímo k řídícímu systému. Hlavní výhodou tohoto řešení je nízká cena. Problémem je  kvalita použitých tiskáren. Jedná se většinou o jednoduché jehličkové nebo termotiskárny, tisknoucí na úzký papír odvíjený z cívky. Grafy tisknuté z těchto tiskáren mají tedy spíše informativní charakter. Pokud jsou vyžadovány přesné hodnoty je nutno tisknout hodnoty číselně. Tímto způsobem je  možné tisknout hodnoty jen s poměrně malou vzorkovací frekvencí, například  záznam z procesu z parní sterilizace by měřil několik metrů. Toto řešení je také problematické z hlediska častého požadavku na oddělenost systému pro řízení a systému pro záznam
\footnote{Pokud je použit jeden systém měření jak pro řízení tak pro záznam dat nemusí být některé problémy vůbec odhaleny. Pokud je například teplota měřena s chybou +1°C, bude teplota regulovaná o 1°C níže než je požadována. Pokud by v tomto případě byl pořizován záznam pouze z čidla použitého pro regulaci, nemusela by být tato chyba vůbec odhalena}. 

\section{Návrh systému}
Z výše popsaných možností vyplývá, že žádné z běžně dostupných hotových řešení zcela nevyhovuje zadání. Problémy působí především potřeba číst hodnoty veličin z automatů pomocí nestandardního protokolu. Dalším problémem je požadavek na automatické vytváření protokolů z jednotlivých procesů. Z těchto důvodů bylo rozhodnuto vytvořit vlastní zařízení pro záznam dat, které bude možné plně přizpůsobit požadavkům jednotlivých aplikací.

Z popisu problému na začátku kapitoly a u jednotlivých monitorovaných technologických procesů vyplývá několik požadavků na navrhované zařízení. Hlavními z nich jsou: Možnost čtení dat z automatů firmy Micropel pomocí sběrnice RS485, schopnost uchování velkého množství naměřených dat, automatické vytváření protokolů specifických pro jednotlivá zařízeni a jednoduchý přístup k naměřeným datům ze vzdáleného počítače. Koncepce sběru dat s navrhovaným registračním zařízením je znázorněna na obr. \ref{fig:diag1}. Data by měla být čtena přes rozhraní RS485 z automatů firmy Micropel, zaznamenávána pomocí navrhovaného registračního zařízení a zpřístupněna pomocí protokolu http přes rozhraní Ethernet. Celé navrhované zařízení by mělo být možné umístit na DIN lištu do rozvodné skříně. Všechny tyto požadavky je nutné zohlednit při výběru použitých technologií, kterým se zabývá následující kapitola. 

\begin{figure}[h]
  \centering
	\includegraphics[scale=0.4]{obrazky/diag1}
  \caption{Sběr dat v aplikaci parního sterilizátoru}
  \label{fig:diag1}
\end{figure}

\chapter{Použité technologie}

\section{Programovatelné automaty Micropel}
V projektu jsou použity PLC od firmy Micropel. Řada těchto automatů se skládá z automatů s pevnou konfigurací, modulárních automatů a jednoúčelových periférií. Jednotlivé komponenty se spojují do sítě pomocí komunikační linky RS485. Pro snadnější komunikaci je možné použít některý z komunikačních převodníků, které umožňují komunikaci se sítí automatů pomocí rozhraní RS232, USB nebo Ethernet. K programování používají vlastní jazyk Simple.

\subsection{PES M66}
Automat je určen k jednoduchým aplikacím, nevyžadujícím velké množství vstupů a výstupů. Jako poslední z dostupných automatů nepodporuje programování v novějším jazyce SIMPLE V4 a používá starší variantu SIMPLE V2. Tím je ochuzen o některé možnosti novějších automatů. Mezi největší omezení patří možnost použití pouhých dvou datových typů (bit a word). Automat má k dispozici 6 analogových vstupů 0-10 V (použitelných i jako digitální) a 6 digitálních výstupů. Pro indikaci stavu jsou k dispozici 4 programem ovládané kontrolky na čelním panelu, v jejich blízkosti je otočný potenciometr a jedno tlačítko. Vzhledem k výbavě je vhodný hlavně pro jednodušší úlohy.

\subsection{PES K10 a K1}
Tato řada automatů má pevnou konfiguraci vstupů a výstupů. Jsou určeny hlavně jako operátorské panely. Za tímto účelem jsou vybaveny fóliovou klávesnicí, podsvětleným znakovým LCD displayem s 4x20 znaky a zvukovou signalizací. Čelní panel je proveden s krytím IP65 a je připraven k montáži do panelu. V této typové řadě jsou dostupné dva automaty: K10 a K1. K10 je vybaven 6 napěťovými analogovými vstupy 0-10 V, 6 analogovými odporovými vstupy 0-500 \(\Omega\) a 8 galvanicky oddělenými digitálnímy vstupy. Z výstupu obsahuje 16 digitálních galvanicky oddělených výstupů a 4 analogové výstupy 0-10 V. Automat K1 má shodné fyzické rozměry jako automat K10, obsahuje však pouze 6 analogových vstupů (použitelných i jako digitální) a 2 digitální výstupy. Tím je určen převážné pro použití jako ovládací terminál. 

Jednotlivé automaty v této řadě se liší jen množstvím a typem dostupných vstupů a výstupů.

\subsection{PES MPC300}
Tato řada automatů je řešena jako modulární. Základem je tělo, které obsahuje vlastní procesorovou desku, několik vstupů a výstupů, komunikační rozhraní a v některých variantách také klávesnici a display. K tomuto základu je možné přidat maximálně dva rozšiřující moduly. Mezi dostupné moduly patří klasické digitální vstupy a výstupy, analogové napěťové vstupy a výstupy 0-10V, proudové vstupy 0-25mA a odporové vstupy pro čidla Pt100, Pt1000 a Ni1000.

\subsection{Jazyk Simple}
Všechny dnes dostupné perspektivní automaty firmy je možné programovat v jazyce SIMPLE V4. Jazyk je navržen pro řízení průmyslových procesů a má tedy některé méně obvyklé vlastnosti, podporující bezpečný běh programu.

Celý program je vždy vykonáván od začátku do konce a potom znovu od začátku. Není zde žádná možnost skoků nebo cyklů. Tím je zabráněno vzniku nekonečných smyček. Vlastní program pak většinou realizuje stavový automat. Další vlastností podporující spolehlivost programu je tzv. bezpečná aritmetika (její použití je volitelné). Ta se snaží zabránit nečekaným výsledkům matematických operací. Například zabraňuje přetečení/podtečení čísla tak, že výsledek operace, u které by k němu mělo dojít, nahradí maximální/minimální hodnotou uchovatelnou v cílové proměnné. Podobně řeší dělení nulou, kde opět nahrazuje výsledek maximální kladnou/zápornou hodnotou proměnné. Při dělení nuly nulou je výsledek definován jako nula.

\subsection{Komunikační protokol PesNet}
PLC firmy Micropel mezi sebou komunikují svým vlastním protokolem. Jeho fyzická vrstva je realizována rozhraním RS485. Z hlediska řízení přenosu se jedná o síť typu multi-master s předáváním tokenu. Všechny stanice v síti jsou rovnocenné a postupně si předávají právo vysílat. Tím je zajištěno, že při komunikaci nebude docházet ke kolizím.
 
Při zapnutí prvních stanic v síti nebo při přerušení komunikace v důsledku chyby, je síť ve stavu, kdy žádná stanice nemá token a celá komunikace je tedy zablokována. Pro obnovení provozu v této situaci každá stanice počítá čas od poslední úspěšné komunikace. Je li tento čas větší než určitá hranice, automat sám začne vysílat a tím se komunikace obnoví. Délka čekání je dána mimo jiného adresou automatu (ta je unikátní - nemůže dojít ke kolizi). Automat, který se rozhodne zahájit komunikaci, začne posílat tokeny na všechny adresy pod sebou, dokud nedostane odpověď. Po té přebírá řízení další nalezený automat a prohledává dále prostor pod sebou. Tímto způsobem si automaty vytvoří přehled o obsazení jednotlivých adres. Další komunikace již probíhá jen mezi obsazenými adresami. Po delší době se pokusí automaty poslat token na některou z neobsazených adres, aby mohly být detekovány nově připojené automaty. Nastartování přerušené komunikace může trvat maximálně 5s, nalezení nově připojené stanice může trvat až 20s.

Veškerá komunikace mezi jednotlivými automaty probíhá po rámcích, které obsahují adresu cílového automatu, kód příkazu a kontrolní součet. Některé rámce mají ještě prostor pro data. Komunikace po lince RS485 je poloduplexní. Přenos vždy zahajuje MASTER (automat držící token). U některých příkazů master čeká na odpověď od SLAVE, jiné jsou bez odezvy. Automat předá token dalšímu, pokud nemá další příkazy k vysílání nebo po odeslání maximálně tří příkazů (tím je zabráněno tomu, aby jeden automat blokoval linku příliš dlouho).

Vlastní komunikace probíhá asynchronně s jedním startbitem, jedním stopbitem a devíti bity dat. Data obsahuje prvních osm bitů, poslední označuje začátek rámce. Podporované rychlosti jsou 2400, 9600, 19200, 57600 baudu. Všechny příkazy se dají rozdělit do tří skupin. První jsou příkazy pro čtení a zápis z paměti automatu. Druhá skupina obsahuje příkazy ovlivňující běh automatu a jeho konfiguraci (zastavení, restart, nahrání programu atd.). Poslední skupina obsahuje příkazy řídící komunikaci (předání tokenu). Všechny příkazy, které poskytují odpověď, existují ve dvou variantách. U první automat ihned po jejich přijmutí a zpracování odešle celou odpověď. U druhé varianty odesílá stejnou odpověď, ale odešle jen první byte. Další odesílá po jednom na požádání. Tato varianta je určena pro komunikaci se zařízeními, která by mohla mít problém zpracovat celou odpověď najednou.

Podrobný popis všech příkazů a možných odpovědí na ně je dostupný na stránkách výrobce\cite{PesNet}

\section{FOX Board G20}
FOX Board G20 je jednodeskový počítač vyráběný firmou ACME Systems. Je založen na mikroprocesoru AT91SAM9G20. Kromě procesoru obsahuje 64MB SDRAM, 8MB Flash, obvod reálného času se zálohovací baterií, podpůrné obvody pro rozhraní ethernet a slot na microSD kartu. Díky procesoru s architekturou ARM9 a dostatku paměti umožňuje běh operačního systému Linux. Jediným problémem může být velmi malá paměť Flash určená k ukládání operačního systému, programů a naměřených dat. K jejímu rozšíření je možné použít microSD slot.

\subsection{AT91SAM9G20}
Jedná se o 32bitový procesor od firmy Atmel, postavený na architektuře ARM9. Pro jeho použití v embeded systémech ho předurčuje jeho malá spotřeba (80mW) a velké množství integrovaných periférii. Mezi ně patří:
\begin{itemize}
	\item Jeden USB device port
	\item Dva USB host porty
	\item ethernet 10/100Mb port
	\item rozhraní pro MMC karty
	\item čtyři synchronní/asynchronní porty (USART)
	\item dva asynchronní porty (UART)
	\item SPI rozhraní
	\item čtyřkanálový desetibitový A/D převodník
\end{itemize}

\section{GSM modem}
K navrhovanému zařízení je v některých případech potřeba přistupovat vzdáleně. Pokud není k dispozici připojení k internetu přes podnikovou síť je nejvhodnější volbou připojení pomocí sítě GSM. Jeho hlavními výhodami je jednoduchá instalace nevyžadující pokládání kabelů a široká dostupnost.
Pro přenos dat v GSM sítích je využíváno několik technologii. Historicky první technologie pro přenos dat je CSD která umožňuje přenos rychlostí 9,6kb/s a je zpoplatněna jako běžný hovor, pro zpřístupnění webového rozhraní je tedy značně pomalá a drahá. Další technologií je GPRS, ta umožňuje, dle varianty protokolu, download i upload rychlostí až 80kb/s (ne zároveň, poměr mezi uploadem a downloadem se nastavuje automaticky v závislosti na charakteru přenosu). S touto rychlostí je již možné webové rozhraní používat, i když odezvy jsou poměrně pomalé. 
Výhodou GPRS je jeho dobré pokrytí (je dostupné prakticky všude kde jsou dostupné hlasové služby) a cena. Platba většinou probíhá tarifně, nebo je účtován oběm přenesených dat. 
Z GPRS vychází technologie EDGE (někdy EGPRS) která přináší vyšší rychlost (v závislosti na variantě download až 236.8kbit/s a upload až 118kbit/s). Pokrytí je dnes prakticky totožné s GPRS a cena je shodná. V posledních letech se objevují technologie souhrnně označované jako 3G, které nabízejí podstatně větší rychlosti. Jejich pokrytí je však velmi omezené a tím je také omezena možnost jejich použití.
 
\subsection{MC75i}
V této práci je pro připojení přes GSM síť použit modem MC75i firmy Sectron. Tento modem podporuje komunikaci pomocí GPRS i EDGE. Připojení k počítači je možné pomocí USB portu nebo RS232. V obou případech se chová jako Hayes kompatibilní modem, takže v případě potřeby by nebyl problém ho nahradit jiným podobným modemem. Pro připojení antény je přítomen SMA konektor. Napájení je připojeno přes RJ11 konektor. Velikost napájecího napětí se může pohybovat v rozmezí 8-30V. Spotřeba je velice závislá na aktuální činnosti modemu. V nečinnosti, kdy je modem pouze přihlášen do sítě, se pohybuje okolo 30mA. Při datovém přenosu může stoupnout až na 200mA (při napájecím napětí 12V).

\section{Senzory}
Z hlediska vlastního SW pro záznam dat není důležité o jaké snímače se jedná, je jen nutné, aby na straně PLC byl odpovídající vstup. V navrhovaném systému jsou měřeny dvě veličiny: teplota a tlak. Převod odporu na teplotu případně proudu na tlak je prováděn už v PLC. Systém je však při použití vhodných snímačů,použitelný k zaznamenávání libovolné veličiny.

\subsection{Měření teploty}
Pro měření teploty jsou použita čidla Pt100 a Pt1000 připojená do odporových vstupů automatu. Při trojvodičovém nebo čtyřvodičovém připojení je automaticky provedena korekce odporu přívodních vodičů. Převod odporu na odpovídající teplotu je také proveden přímo automatem. Zaznamenání teploty je tedy možné provést přímo přečtením příslušné hodnoty.

\subsection{Měření tlaku}
V navrhovaném systému jsou použity dva různé typy senzorů tlaku. Jeden pro měření vysokých tlaků (10 - 400kPa). Konkrétně se jedná o snímač DMP333, od firmy BD SENSORS, fungující na piezorezistivním principu. Tento snímač již obsahuje elektroniku, která zajišťuje převod odporu a zajišťuje výstup 4-20mA.  Druhý typ senzoru slouží k měření velmi malých tlaků (0,1Pa - 100kPa, přesnost se však s rostoucím tlakem velmi rychle zhoršuje). Tento senzor funguje na principu měření tepelné vodivosti prostředí. Výstupní hodnoty napětí jsou v rozsahu 2,2 - 8,5V. Závislost výstupního napětí na tlaku je však silně nelineární (logaritmická), takže je potřeba provést převod měřeného napětí na odpovídající tlak. Tento převod je pro účel řízení procesu prováděn za pomoci tabulky přímo v automatu a pro záznam je tedy opět možné použít přímo hodnotu v paměti automatu.

\section{Operační systém}
Zamýšlenou aplikaci by bylo možné programovat přímo pro mikroprocesor AT91SAM9G20, bez použití operačního systému. Kód obstarávající komunikaci přes RS485 a obsluhu příslušných přerušení by byl dokonce jednodušší než při použtí operačního systému. Na druhou stranu použití operačního systému umožňuje použít hotové knihovny a programy, které vývoj některých součástí značně urychlí. 

Při použití OS je možné pro ukládání dat použít existující databázový engine. Dosažení podobných vlastností a kvalit vlastním kódem by bylo velmi obtížné a časově náročné. Podobná situace je u webového rozhraní. Nezanedbatelnou výhodu je také možnost vzdálené správy kterou umožňuje většina dostupných OS. Z hlediska flexibility je užitečná existence standartních rozhraní a ovladačů pro některá zařízení.

Z výše uvedených důvodů bylo rozhodnuto vytvořit navrhovaný systém s použitím operačního systému. Operačních systému pro embeded zařízení využívající mikroprocesor ARM je dnes celá řada od MicroC přes WinCE a Linux po Android. Pro tvorbu navrhovaného systému byl vybrán operační systém Linux. Jeho hlavní výhodou je dostatek informací, příkladů a otevřenost, která značně usnadňuje.

\subsection{GNU/Linux}
Pod názvem Linux bývá většinou chápán operační systém postavený na jádru Linuxu, GNU utilit a dalších programů. Přesněji je Linux pouze jádro operačního systému, ke kterému přidáním programů a knihoven z projektu GNU a dalších, vzniká celý operační systém označovaný jako GNU/Linux\footnote{Linuxové jadro je používáno velmi často právě ve spojení s utilitamy z projektu GNU, tím také pravděpodobně vznikly tyto nejasnosti v označení. Nejedná se však o jedinou možnou kombinaci. Linuxové jádro je možné používat bez GNU programů, jako například v operačním systému Android nebo v různých embeded zařízeních, kde je GNU nahrazeno knihovnou uclibc a programy z projektu busybox}.  Naopak GNU může být použito s jiným jádrem, například poslední verze Debianu (6.0 Squeeze) umožňuje výběr mezi Linuxovým a FreeBSD jádrem.


Při použití operačního systému Linux je důležitá také volba distribuce. Množství distribucí podporujících architekturu ARM rychle roste, pro použíti v embeded zařízení se však hodí jen některé z nich. Předem je možné vyloučit čistě desktopové distribuce (Ubuntu, Fedora), které se zaměřují na aplikace pro toto použití naprosto zbytečné. Jako vhodné se jeví buď distribuce přímo určené pro embeded zařízení (např. Emdedian, OpenWRT, Kaeilos) nebo nenáročnou serverovou distribuci (např. Debian). Vzhledem k předchozím zkušenostem a dobré podpoře sestavení vlastního operačního systému byla nakonec zvolena distribuce Debian.

\section{Lighttpd}
Lighthttpd je open-source webserver, vydaný pod BSD licencí. Mezi jeho hlavní vlastnosti patří malá paměťová náročnost a malá zátěz procesoru. I přes tyto vlastnosti podporuje všechna běžná rozhraní a dosahuje vysokých výkonů. Z hlediska navrhované aplikace je důležitá podpora FastCGI, která umožňuje využití například PHP a podpora šifrovaných přenosů pomocí https. Lighthttpd je využíván například službami YouTube, Wikimedia a v mnoha SOHO routerech.   
  
\section{PHP}
PHP (rekurzivní zkratka PHP: Hypertext Preprocessor) je skriptovací jazyk primárně určený pro tvorbu dynamických internetových stránek ve formátu HTML a XHTML. Lze ho všah použít i pro tvorbu konzolových a desktopových aplikací. PHP skripty většinou běží na straně serveru a ke klientovy odesílají pouze svůj výstup v podobě HTML kódu. Patří mezi nejrozšířeněší jazyky používané pro tvorbu dynamických stránek. Díky tomu je pro něj k dispozici velké množství knihoven pro práci s databázemi apod. Aktuálně je používáno PHP verze 5, jehož hlavní změnou proti předchozí verzi je podpora objektově orientovaného programování. 

\section{XHTML}
XHTML (anglická zkratka extensible hypertext markup language) je značkovací jazyk vytvořený jako nástupce HTML. HTML na základě SGML (anglická zkratka Standard Generalized Markup Language), naproti tomu XHTML je vytvořeno na základě XML, které je podmnožinou SGML. XHTML přebírá vlastnosti HTML, ale v některých ohledech je restriktivnější. Na rozdíl od HTML musí být všechny tagy párové, hodnoty atributů musí být v úvozovkách a názvy atributů a hodnot jsou case sensitive. Výhodou XHTML je možnost použít běžný XML parser a rozšířitelnost. Díky rozšířitelnosti je například možné přímo do zdrojového kódu XHTML stránky vložit SVG obrázek, který je také založen na XML technologii.

\section{CSS}
CSS (anglická zkratka Cascading Style Sheets) je jazyk určený k popisu vzhledu dokumenů HTML, XML a z něho vycházejících. Hlavním účelem tohoto jazyka je oddělit obsah dokumentu od jeho vzhledu. Díky tomu je možné jeden dokument zobrazovat několika odlišnými způsoby, například v závislosti na zařízení použitém k jeho zobrazení. V této práci je vlastnosti využito pro vytvoření rozdílných stylů pro zobrazení stránky na monitoru a pro tisk. V součastné době je používána verze CSS2.1 a pracuje se na verzi CSS3. 

\section{SQLite}
SQLite je databázový engine, původně vytvořený pro systém raketového torpédoborce, nyní vydaný pod public domain licencí. Na rozdíl od většiny databázových systémů, které jsou uspořádány jako klient-server, SQLite neběží jako samostatný proces. Místo toho se jedná o knihovnu, která může být staticky nebo dynamicky přilinkována a stane se součástí programu. Tímto přístupem je zaručena nižší latence a nároky na výkon než při meziprocesové komunikaci. Celá databáze je uložena v jediném souboru. Konkurenční přístup je pak řešen zamykáním tohoto souboru. K databázi může paralelně přistupovat několik procesů, pouze pokud se jedná o přístup pouze pro čtení. Pokud se do databáze zapisuje, nesmí probíhat žádná jiná operace. Výhodou tohoto přístupu je jednoduchost a malá náročnost. Problém může nastat při vyšším zatížení databáze, protože v důsledku velkého množství konkurenčních přístupů dochází k velkému snížení výkonu.

Zvláštností SQLite je přístup k datovým typům. Při tvorbě tabulky je možné definovat datové typy jednotlivých sloupců. Při další práci s tabulkou však nejsou nijak kontrolovány\footnote{Vyjímkou je typ INTEGER PRIMARY KEY, který musí obsahovat celočíselné hodnoty} a je tedy možné do sloupce typu INT uložit řetězec apod. Definované datové typy jsou použity jen v případě použití klauzule ORDER BY.

SQLite je používáno například v aplikacích Mozilla Firefox, Mozilla Thunderbird a v operačních systémech některých mobilních telefonů (Symbian, Maemo, BlackBerry, Android, iPhone). Jeho hlavní výhodou v těchto aplikacích je malá velikost a nízké nároky na paměť. Ze stejných důvodů se hodí i pro embedded aplikace.

\chapter{Návrh a implementace}
\section{Podpůrné obvody}
Samotný FOX Board obsahuje jen součásti nezbytné pro svoji funkci: Zdroj napětí pro mikroprocesor, baterii pro hodiny reálného času, integrovaný obvod pro ethernetové rozhraní, paměť RAM a FLASH. Pro zamýšlené použití je potřeba doplnit další obvody zajišťující potřebné funkce.

\subsection{Digitální vstupy a výstupy}
Hlavním zdrojem dat pro záznam jsou připojená PLC. Během řešení však nastala potřeba vstupů a výstupů připojených, přímo k FOX Boardu. Vstup je nutný zejména pro signalizaci výpadku napájení od externího zdroje. Při výpadku napájení jsou PLC nefunkční a FOX Board by bez vlastních vstupů byl úplně odříznut od okolí. Výstupy mohou být využity například pro signalizaci stavu atd.
 
Mikroprocesor AT91SAM9G20 má celkem 3 PIO porty po 32 vstupně/výstupních pinech. Některé piny, ale vůbec nejsou vyvedeny na kolíkovou lištu. Část z vyvedených pinů neslouží jen jako universální vstupy/výstupy, ale sdílí svou funkci s dalšími periferiemi (UART, I2C, MMC atd.), u těch je nutné zvolit, zda budou použity příslušné periferie, nebo budou použity jako universální vstupy/výstupy. U všech pinů universálních vstupů/výstupů lze navíc nastavit, zda se mají chovat jako vstupy nebo výstupy.

\begin{figure}[h!]
  \centering
	\includegraphics[width=12cm]{schema2}
  \caption{Schéma digitálních vstupů}
  \label{fig:schema2}
\end{figure}

Maximální vstupní napětí většiny vstupů je 3.3V (některých jen 1.8V). Všechny vstupy jsou vybaveny Schmittovým klopným obvodem a možností připojení vnitřního pull-up odporu. Pro galvanické oddělení a úpravu napěťové úrovně vstupů je použit dvojitý optron HCPL273 \cite{HCPL273}. Odpor připojený sériově k vnitřní LED optronu je navržen pro vstupní napětí 24V.

\begin{figure}[h!]
  \centering
	\includegraphics[width=15cm]{schema3}
  \caption{Schéma digitálních výstupů}
  \label{fig:schema3}
\end{figure}

Napěťové úrovně většiny výstupních pinů jsou také 3.3V, u některých 1.8V. Proudová zatížitelnost je také různá. Vstupy 3.3V je možné zatížit maximálně 8mA. Pro posílení a oddělení výstupů je použit optron HSR412L \cite{HSR412L}. Ten obsahuje na výstupní straně MOSFET tranzistory. Ty umožňují spínat poměrně velké zátěže (až 200mA). Zároveň mohou pracovat s napětím 400V, takže jsou použitelné k přímému spínání síťového napětí. Pokud je v době výroby jisté, že nebudou potřeba galvanicky oddělené vstupy a výstupy, je možné příslušné obvody neosadit. 
 
\subsection{Budič sběrnice RS485}
Pro komunikaci se sítí PLC je potřeba rozhraní RS485. FOX Board přímo toto rozhraní neobsahuje, má však UART s podporu RS485. Podpora spočívá v možnosti přepnout signál RTS do režimu, ve kterém přechází do stavu high při odesílání znaků. Tento signál je tedy možné použít k přepínání budiče sběrnice mezi režimem vysílání a režimem vysoké impedance.

Na trhu je velké množství budičů sběrnice RS485. Mezi rozšířené typy patří MAX485, který byl použit při vývoji a testování ovladače. Při nasazení v reálném provozu bývá sběrnice rozlehlá, a proto je vhodné, aby byla galvanicky oddělená od zbytku systému. Některé budiče s tímto požadavkem počítají a obsahují optrony, které zajistí oddělení. Jejich nevýhodou je potřeba dalšího nezávislého zdroje napětí, pro napájení výstupní strany. Pro jeho získání často obsahuje budič pomocné obvody pro vytvoření izolovaného zdroje napětí, vyžadující jen doplnění vnějšího transformátoru.

\begin{figure}[h!]
  \centering
	\includegraphics[width=17cm]{SchemaRS485}
  \caption{Schéma budiče RS485}
  \label{fig:schema4}
\end{figure}

V této práci byl zvolen obvod MAX1480ACPI \cite{MAX1480E}. Tento obvod obsahuje optrony zajišťující galvanické oddělení a obvody pro vytvoření DC/DC měniče. Na rozdíl od většiny ostatních obvodů obsahuje i potřebný transformátor. Diody v optronu mají poměrně velkou spotřebu (20mA). Výstup z FOX Boardu je tedy potřeba posílit tranzistorem. Vlastní spotřeba obvodu MAX1480ACPI může být v závislosti na zatížení sběrnice až 145mA. Obvod budiče tedy může celkově odebírat téměr 200mA. To je přibližně dvojnásobek spotřeby vlastního FOX Boardu. Vzhledem k nutnosti zálohovat napajení je vhodné mít možnost celý obvod budiče odpojit od napájení. To je zajišťeno za pomoci tranzistoru Q9. Jeho báze je přes odpor připojena k vstupu FOX Boardu použitého pro detekci napájecího napětí na vstupu a zajistí tedy odpojení budiče v okamžiku výpadku proudu.

\subsection{Zdroj}
Pro napájení počítače FOX Board a podpůrných obvodů je použit zdroj 24V stejnosměrného napětí který je k dispozici přímo v rozvaděči. FOX Board však vyžaduje napětí 5V. Dalším požadavkem na napájení je zabránění náhlé ztráty napájecího napětí v případě přerušení napájení z rozvaděče. V případě výpadku vnějšího zdroje by měl zůstat FOX Board v provozu po dobu nutnou k bezpečnému ukončení práce (ukončení zápisu do databáze, odmountování disku). Tato doba byla experimentálně určena jako 30s.

\begin{figure}[]
  \centering
	\includegraphics[width=23cm, ,angle=90]{schemazdroj}
  \caption{Schéma zdroje}
  \label{fig:schema1}
\end{figure}

V UPS bývají většinou pro zálohování používány olověné baterie. Hlavními pozitivy olověných baterií je poměrně jednoduché nabíjení a možnost odebírat velký proud. Spolu s dalšími chemickými akumulátory však sdílejí některé nedostatky. Z hlediska navrhovaného zařízení je důležitá dlouhá životnost při poměrně vysokých teplotách (až 65°C), rychlé nabíjení a možnost jednoduchého testu kapacity. Z těchto důvodů byly namísto běžných akumulátorů použity superkapacitory, které mají oproti akumulátorům delší životnost, je možné je nabíjet vysokou rychlostí a test kapacity je možné provést měřením doby vybíjení přes známý odpor. Celý tento test může proběhnout poměrně rychle. 

Hlavním parametrem při návrhu zálohovaného zdroje je potřebná doba zálohování. Aby byla k dispozici dostatečná časová rezerva pro vypnutí systému i v případě poklesu kapacity kondenzátorů, měl by být tento zdroj navržen alespoň na 60s provozu. Po vypnutí budiče sběrnice RS485 zbývá jako jediný velký spotřebič FOX Board. Výrobce udává spotřebu bez zátěže jako 80mA při 5V. Při praktickém měření při plném zatížení nebyla nikdy naměřena spotřeba větší než 100mA. Při účinosti spínaného zdroje 80\% (výrobce udává min. účinost 84\%) je tedy možné včetně podpůrných obvodů počítat s odběrem 650mW na vstupní straně DC/DC měniče s výstupem 5V. Pro provoz po dobu 60s je tedy potřeba energie 39J. Energie uložená v kondenzátoru je určena vztahem \ref{eq:CapE}

\begin{equation} \label{eq:CapE}
E = \frac{1}{2}CU^2
\end{equation}

Z hlediska využití maxima energie uložené v kondenzátorech je lepší použít sériové zapojení kondenzátorů\footnote{Při vybíjení kondenzátorů postupně klesá napětí. Pokud je tedy na výstupu zálohovaného zdroje vyžadováno konstantní napájení je nutné použít spínaný regulátor. Ten je schopen pracovat jen s určitým rozsahem vstupních napětí. Zvolený regulátor umí pracovat se vstupním napětím 6.5 - 36V. Z hediska využití maxima energie je tak možné využít co největší část tohoto rozsahu.}. Na základě těchto požadavků byla vybrána konfigurace zobrazená na obr. \ref{fig:schema1}. Dvanáct kondenzátorů se jmenovitým napětím 2.7V a kapacitou 2.2F je zapojeno do série a nabíjeno na napětí 30V, získané pomocí DC/DC měniče. Dosazením do vztahu \ref{eq:CapE} tedy určíme energii v plně nabité baterii kondenzátorů jako 82J. Výstupní měnič však přestane fungovat při poklesu napětí pod 6.5V a 4J tedy zůstanou nevyužitý. Celkově je tedy k 78J a navržený zdroj má tedy dostatek kapacity pro napájení zařízení po požadovanou dobu včetně rezervy pro případ poklesu kapacity kondenzátorů.

Každý kondenzátor má paralerně připojenou jednu Zenerovu a jednu Schotkyho diodu. Tyto diody zajišťují ochranu kondenzátorů v případě že nemají stejnou kapacitu. Zenerova dioda zabraňuje, aby v důsledku rozptylu jmenovité kapacity, došlo k překročení jmenovitého napětí kondenzátoru. Schotkyho dioda chrání slabší kondenzátory předpřepólováním při vybíjení.

%Zdroj proudu?

Test kapacity kondenzátorů je možné spustit nastavením výstupu PA11 do stavu high. Tím dojde k přerušení nabíjení kondenzátorů a připojení vybíjecího odporu R11. Pomocí vstupu PA22 je možné sledovat kdy poklesne napětí na kondenzátorech pod 10V. Z naměrené doby je pak možné odvodit kapacitu kondenzátorů. FOX Board je po dobu tohoto testu napájen rovnou z výstupu DC/DC měniče sloužícího pro nabíjení kondenzátorů a nehrozí tedy že by ovlivňoval svou spotřebou výsledek měření.

Výpadek napájecího napětí je možné sedovat pomocí vstupu PA25.

\section{Příprava operačního systému}
Instalace operačního systému na embeded systémech má naprosto odlišný postup než v případě běžných PC (AMD64 a IA-32). Při instalaci na PC je díky poměrně velké standardizaci základních rozhraní možné připravit univerzální instalační medium, které umožňuje úspěšně nainstalovat operační systém i nezkušenému uživateli. U embeded systému (ale i spotřební elektroniky, mobilních telefonů, televizí apod.) je situace značně odlišná. I pokud zařízení používají mikroprocesor se stejnou architekturou, jsou mezi nimi velké rozdíly ve způsobu připojení a typu  periférií, způsobu připojení paměti a postupu zavádění programu při spuštění. Často není vůbec přítomné rozhraní pro připojení vhodného instalačního media. Operační systém pro tato zařízení je tedy nutné připravit na míru konkrétnímu hardware a vlastní instalační proces je také náročnější.

V případě GNU/Linuxu je potřeba upravit pro konkrétní zařízení hlavně jádro operačního systému. To zprostředkovává funkce hardwaru uživatelským programům a je tedy závislé na konkrétní konfiguraci zařízení. Uživatelské programy jsou od hardware odděleny abstrakcí poskytovanou právě jádrem a tak jsou na konkrétní konfiguraci hardware poměrně nezávislé. Pro jejich funkčnost tedy většinou stačí aby byly zkompilovány pro příslušnou procesorovou architekturu. 

\subsection{Kompilace jádra}
Z výše uvedených důvodů je nutné připravit vlastní Linuxové jádro. Při přípravě operačního systému byla použita v té době aktuální verze Linuxového jádra 2.6.35.4. a popsaný postup tedy platí pro tuto verzi. Postup pro novější jádra by byl velice podobný, od verze 2.6.38 však odpadá nutnost aplikace patche od firmy ACME který přidával do kódu jádra informace nutné pro správnou inicializaci hardware specifického pro FOX Board, protože tento patch byl přijat do hlavní vývojové větve jádra a je tedy přímo součástí všech následujících verzí jádra.

Prvním krokem potřebným pro kompilaci vlastního jádra je připravení prostředí pro kompilaci. Toto prostředí je souhrnem nástrojů, knihoven a kompilátoru potřebným k vytvoření binárního obrazu jádra ze zdrojového kódu. Ve světě osobních počítačů je příprava tohoto prostředí poměrně jednoduchá a v případě běžných distribucí spočívá v instalaci několika málo předpřipravených balíku programů které obsahují všechny výše popsané součásti. Tyto předpřipravené balíky však předpokládají že cílová platforma je shodná s platformou na které probíhá kompilace. Jinak řečeno kompilátor běžící na platformě AMD64 vytváří spustitelný kód pro AMD64 a kompilátor běžící na platformě IA-32 vytváří spustitelný kód pro IA-32. Při kompilaci jádra pro delší platformy lze postupovat stejným způsobem. Linuxová distribuce Debian ve verzi pro mikroproprocesor ARM, použitá v tomto projektu, obsahuje všechny k tomu potřebné nástroje. Pokud je tedy na cílovém zařízení funkční systém je možné zkompilovat jádro přímo na něm. V případě desky FOX Board je možné získat od výrobce SDkartu s již připraveným systémem, takže je možné přistoupit ke kompilaci jádra přímo na FOX Boardu. 
Problémem při tomto postupu je poměrně nízký výkon použitého procesoru, malá paměť RAM a nedostatek místa na SDkartě sloužící jako jediné úložiště dat. Proces kompilace by byl tedy poměrně komplikovaný a hlavně velice zdlouhavý. U velkého množství zařízení není přímá kompilace vůbec možná, už jen kvůli tomu že na něm není k dispozici funkční systém na kterém by mohla kompilace proběhnout. Tyto problémy se dají obejít křížovou kompilací. Ta spočívá v tom že kompilace probíhá na jiné architektuře než pro kterou je určen výsledný binární soubor. Nástroje používané pro běžnou kompilaci však nejsou schopné provádět křížovou kompilaci a je tedy nutné připravit novou sadu nástrojů tzv. toolchain schopný křížové kompilace. Minimem pro křížovou kompilaci je upravená verze binutils (nástroje pro překlad z assembleru a linker), překladač gcc a knihovna libc. Příprava tohoto toolchainu je poměrně složitý proces. Pokud je však pro kompilaci použita linuxová distribuce založená na debianu je možné použít předpřipravený toolchain z projektu Emdebian \cite{EmdedianWWW}. V tomto projektu byla pro kompilaci jádra použita distribuce Debian a příprava toolchainu byla tedy značně zjednodušená.

Aby bylo možné využít repozitář\footnote{V OS GNU/Linux a mnoha dalších se provádí instalace software odlišným způsobem než jaký je běžný u OS Windows. Pro instalaci software slouží balíčkovací systém který zajistí instalaci z připraveného balíčku. Tento balíček obsahuje soubory určené ke zkopírování do systému, ale také instalační skript který zajistí další potřebná nastavení. Instalační balíček může být dodán přímo uživatelem, většinou je však obstarán přímo balíčkovacím systémem, z repozitářů spravovaných vydavatelem příslušné distribuce. Uživateli stačí zadat název požadovaného software a balíčkovací systém se sám postará o stažení instalačních balíků z repozitáře příslušné distribuce a jejich následující instalaci. Instalace z repozitářů umožňuje jednoduší a bezpečnější (při použití důvěryhodného repozitáře) instalaci software a jednotnou kontrolu aktualizací pro všechen nainstalovaný software.} projektu Emdedian je ho potřeba přidat do seznamu používaného správcem balíků. 

Toho je docíleno přidáním následujícího záznamu do souboru \texttt{/etc/apt/sources.list}: {deb http://www.emdebian.org/debian/ squeeze main} Aby byl tento repozitař považován za důvěryhodný a bylo možné ho používat je ještě nutné nainstalovat příslušný klíč příkazem \texttt{aptitude install emdebian-archive-keyring}. Tím je dokončeno přidání nového repositáře a po aktualizaci seznamu dostupných balíků pomocí příkazu \texttt{aptitude update} je možné přistoupit k instalaci nástrojů potřebných pro křížovou kompilaci. Pro vlastní kompilaci jádra jsou potřeba balíky binutils-arm-linux-gnueabi, gcc-4.3-arm-linux-gnueabi a uboot-mkimage. První dva uvedené jsou potřeba k vlastní kompilaci jádra. Třetí obsahuje nástroj, který umí zabalit jádro do souboru doplněného o další informace (CRC32, nastavení jadra atd.), který je možné zavést pomocí bootloaderu v cílovém zařízení. Po dokončení těchto kroků je k dispozici plnohodnotný toolchain připravený pro kompilaci nového jádra.

Prvním krokem při kompilaci je získaní zdrojového kódu jádra. Ten je možné získat například z \cite{KernelWWW}. Na stažený a rozbalený zdrojový kód jádra, před vlastní kompilací, je možné aplikovat jeden nebo více patchů upravujících funkci jádra. Vzhledem k tomu že použitý mikroprocesor je již jádrem podporován stačí poměrně malé množství úprav, které zajišťují specifické nastavení odpovídající připojeným obvodům na FOX Boardu. Především se jedná o konfiguraci microSD karty, UART portů a ethernetového řadiče. Tento patch je dostupný na stránkách výrobce FOX Boardu\cite{FOXKernelWWW}. Vzhledem k tomu že jeden z UART portů bude použit s vlastním ovladačem je navíc potřeba přidát patch RS485.patch (na přiloženém CD), který odstraní kód který inicializuje USART1 jako běžný sériový port a uvolní ho pro použití vlastním ovladačem. Aplikací těchto dvou patchů je připraven vlastní zdrojový kód a je možné přistoupit ke konfiguraci jádra.

Linuxové jádro je velice rozsáhlé a může běžet na velice rozdílných platformách s podporou ruzných funkcí a hardware. Aby bylo možné z jednoho zdrojového kódu možné vytvářet tolik rozdílných variant binárních obrazů jádra je používán mechanizmus podmíněného překladu. Až během kompilace se na základě nastavení uložených v souboru .config vybírají konkrétní možnosti. Pro editaci tohoto konfiguračního souboru jsou k dispozici dvě možnosti. První je dostupná přes příkaz \texttt{make config} a konfigurace probíhá přes sérii otázek. Druhou možností je použití příkazu \texttt{make menuconfig}, v tomto případě probíhá konfigurace pomocí vnořených menu. Jako základní konfiguraci je možné použít soubor .config poskytnutý výrobcem FOX Boardu\cite{FOXKernelWWW}. V tomto konfiguračním souboru je většina ovladačů kompilována jako moduly, takže zbytečně nezvyšují velikost jádra i tak je však většina z nich zbytečná a je tedy možné je vypnout (ovladače pro SATA, USB zvukové a grafické karty apod.). Naopak je potřeba přidát podporu pro PPP protokol a TUN rozhraní. Upravený soubor .config, obsahující výše popsaná nastavení, je na přiloženém CD. 
 
Po dokončení konfigurace je možné příkazem \texttt{make} spustit kompilaci jádra a následně příkazem \texttt{make modules} kompilaci modulů. Takto vytvořené jádro je ještě nutné připravit do souboru použitelného zavaděčem U-Boot. K tomu je možné použít soubor makefile\footnote{Program make hledá v aktuálním adresáři soubory makefile a Makefile v tomto pořadí. Přidaný makefile je tedy zavolán dříve než původní Makefile dodávaný s jádrem. Nový makefile využívá funkce původního, jen přidává schopnost vytvořit z jádra obraz pro U-Boot} ze stránek výrobce výrobce FOX Boardu\cite{FOXKernelWWW}. Nově zkompilované jádro je díky přidanému makefile zabaleno do souboru uImage s přídavnými informacemi potřebnými pro zavaděč U-Boot. Zkompilované ovladače jsou v podadresáři foxg20-modules. 

\subsection{Instalace operačního systému}
Linuxová distribuce Debian je poměrně dobře připravena na instalaci v případech kdy není možné použít klasický instalátor. V těchto případech je možné použít nástroj debootstrap který umožňuje nainstalovat Debian z prostředí jiného běžícího systému do libovolného adresáře. V případě tohoto projektu je jako původní systém použit také Debian což celý proces značně usnadňuje. Instalace vlastního debootstrapu spočívá pouze v instalaci jediného balíku příkazem \texttt{aptitude install debootstrap}. 

Před vlastní instalací je potřeba připravit paměťovou kartu. Na nově dodávaných paměťových kartách bývá zpravidla jeden oddíl se souborovým systémem fat32 přes celou kartu. Toto rozdělení je pro použití s FOX Boardem nevhodné a je ho tedy potřeba změnit. Na začátku je potřeba odstranit původní oddíl. Poté je možné vytvořit první malou partition o velikosti 32MB, která bude sloužit pro uložení jádra. Další partition s velikostí 1GB bude použita pro vlastní OS. Poslední partition je určená pro zaznamenávaná data a využívá zbývající místo (v případě 2GB karty tedy necelý 1GB).
 
Pro vytváření a úpravu oddílů je možné pod OS GNU/Linux použít nástroj fdisk\cite{FdiskManWWW}. Na takto vytvořených oddílech je následně potřeba vytvořit souborový systém. Zavaděč UBOOT umí pracovat jen se souborovým systémem FAT32 a první oddíl určený pro uložení jádra tedy musí být v tomto formátu. Naformátovat oddíl v tomto formátu je možné příkazem \texttt{mkfs.vfat /dev/sdX1}. Další dva oddíly je možné zformátovat souborovým systémem ext2 příkazem \texttt{mkfs.ext2 /dev/sdXY}. Aby bylo možné s těmito oddíly pracovat je potřeba je připojit. To je v unixových operačních systémech možné příkazem \texttt{mount /dev/sdXY /mnt/sdXY} Na první oddíl připravené paměťové karty je následně možné zkopírovat dříve připravený soubor s jádrem uImage.  

Následně je možné přistoupit k vlastní instalaci. V nejjednodušším případě stačí použít příkaz \texttt{debootstrap --arch armel --download-only --foreign squeeze /mnt/ sdX2 http://ftp.us.debian.org/debian}. Ten zajistí stažení balíků obsahujících základní systém a jejich rozbalení do určeného adresáře. Parametry foreign a download-only zajistí že nedojde k spuštění instalačních skriptů. Toto opatření je nutné protože cílová architektura je rozdílná od aktuální a instalační skripty které jsou závyslé na architektuře by tedy nemusely proběhnout. Druhou část instalace je tedy nutné provést na cílovém zařízení. Za tímto účelem je potřeba nastavit aby byl při spouštění systému spuštěn soubor /stage2, který zajistí dokončení instalace na cílovém zařízení. Tohoto automatického spuštění  je možné dosáhnout vložením řádku \texttt{"si:1:respawn:/stage2"} do souboru /etc/inittab (namísto běžných init scriptů tedy proběhne druhá fáze instalace). 

Tuto paměťovou kartu je možné vložit do FOX Boardu a po připojení napájení a zavedení jadra se spustí druhá fáze instalace. Průběh této instalace je možné sledovat přes rozhraní RS232 na příslušném konektoru FOX Boardu. Po skončení instalace je na paměťové kartě nainstalována minimální, ale plně funkční verze Debianu. Další funkce a programy je možné doinstalovat běžným způsobem za pomoci balíčkovacího systému.

Tento postup je odvozen z návodu na stránkách firmy ACME\cite{FOXKernelWWW} a podrobně je rozepsán v příloze \ref{txt:Debroot}.
 

\subsection{Spouštění a vypínání systému}
Vzhledem k specifickým požadavkům na chování během spouštění systému a v případě výpadku proudu, je nutné provést několik úprav do procesu spouštění OS. Navíc by měly být přidány skripty pro spouštění nově vytvořených služeb. 

U běžných osobních počítačů je jako první spuštěn kód biosu, jeho úkolem je provést nutnou inicializaci hardware a poté najít paměťové médium obsahující operační systém, či spíše zavaděč operačního systému. Ten se většinou nachází v MBR pevného disku (může být však využit například zavaděč uložený v EEPROM na síťové kartě), nalezený kód je zkopírován do paměti RAM a spuštěn. Zavaděč na rozdíl od BIOSu dokáže pracovat se souborovým systémem
\footnote{Práce se souborovým systémem je poměrně složitá a velikost kódu který je možné uložit do MBR je pouze 440B. Například zavaděč GRUB je z tohoto důvodu rozdělen do několika částí. První část, označovaná jako stage 1, je uložena v MBR a jejím jediným úkolem načíst je načíst následující část. Ta je označována jako stage 1.5 a většinou je uložena bezprostředně za MBR nebo na vlastní partition. Její velikost může být větší a je v ní tedy možné realizovat funkce potřebné pro práci se souborovým systémem. Díky tomu může ze systémového oddílu načíst stage 2, která zpracuje konfigurační soubor a následně načte a spustí jádro operačního systému.} 
na pevném disku a může z něj tedy načíst obraz jádra do RAM a následně jej spustit.

V případě mikroprocesoru AT91SAM9G20 použitém ve FOX Boardu je postup velice podobný. Na rozdíl od osobních počítačů však chybí standardizovaná vrstva v podobě rozhraní BIOS. Namísto něj je bezprostředně po připojení napájení spuštěn program uložený v paměti ROM procesoru. Ten se pokusí najít další kód ke spuštění na externě připojené FLASH paměti. Pokud neuspěje čeká na příkazy posílané přes sériový port nebo USB, s jejichž pomocí je možné nahrávat data do připojené paměti FLASH nebo nabootovat a spustit program odeslaný přes sériový port. Na FOX Boardu je umístěna paměť NAND FLASH obsahující dva zavaděče\footnote{Novější revize FOX Boardu jsou vybaveny pouze jediným zavaděčem AcmeBoot. Tento zavaděč je vytvořen na míru pro FOX Board a umožňuje rychlejší start.} AT91BootStrap a U-Boot. Jako první je spuštěn AT91BootStrap, který zajistí základní konfiguraci mikroprocesoru a poté spustí U-Boot. Ten z prvního oddílu paměťové karty načte do RAM obraz jádra a spustí jej.

Jádro po svém spuštění dokončí inicializaci procesoru (nastavení virtuální paměti, obsluha přerušení atd.) a přejde k inicializaci funkcí jádra (alokace paměti, plánovač atd.). Na konci inicializace jádra je vytvořen proces init, první program běžící v uživatelském prostoru 
\footnote{V Linuxu a většině ostatních víceúlohových víceuživatelských operačních systémů, je paměť rozdělena na jaderný prostor (kernel space) a uživatelský prostor (user space). V jaderném prostoru běží vlastní jádro operačního systému a ovladače. Běžné aplikace běží v uživatelském prostoru a mají přístup pouze k paměti kterou jim na požádání alokovalo jádro.}.
Úkolem procesu init je spouštět a zastavovat ostatní programy v závislosti na runlevelu/footnote{}. Většina programů však není spouštěna přímo ale přes tzv. init skripty umístěné v adresáři /etc/init.d/. Init je nakonfigurován tak aby při změně runlevelu spouštěl skript /etc/init.d/rc, který dále prohledává adresáře /etc/rcX.d/ (kde X je číslo nového runlevelu). V těchto adresářích jsou umístěny simlinky odkazující na skripty které mají být v tomto runlevelu spuštěny. Název simlinku se skládá z písmena určujícího zda má být skript spuštěn s parametrem start (písmeno S), nebo stop (písmeno K), za ním následuje dvojciferné číslo určující pořadí skriptu a název vlastního skriptu. Pořadí spouštění init skriptů bylo dříve určováno ručně. Zvláště při použití Linuxu na desktopech se však stala rychlost spouštění systému důležitým parametrem a jedním ze způsobů jak dosáhnout zrychlení je paralerní spouštění init skriptů. V případě vícejádrových procesorů je přínos paralelního spouštění skriptů evidentní, podstatné zrychlení ale nastává i u jednojádrových procesorů, protože mnoho procesů není bržděno výkonem procesoru ale prací s pevným diskem nebo sítí. 
Všechny skripty však není možné spustit paralelně, protože služby spouštěné init skripty na sobě vzájemně závisí. Například pro spuštění webserveru musí být funkční síť a daemon obstarávající logováni a pro logovaní musí být připojen oddíl obsahující logy. Aby nebylo nutné tyto závislosti řešit ručně byly vytvořeny nástroje které umožňují tento proces automatizovat. V případě Debianu se jedná o program insserv. Ten na základě informací v hlavičce initskriptu určí kdy může být příslušný skript spuštěn a na základě toho vytvoří potřebné simlinky.

\subsection{Init skripty}
Init skripty zajišťují spouštění služeb (poskytovaných programy nazývanými daemony) ale také jednorázové akce jako je konfigurace sítě nebo připojení diskových oddílů. Aby bylo možné automaticky určit v jakém pořadí má docházet k jejich spouštění musí ve své hlavičce obsahovat potřebné informace o jejich vzájemných závislostech. Formát této hlavičky používaný v Debianu byl určen v rámci projektu Linux Standard Base\cite{LSBinit}. Ukázka hlavičky skriptu vytvořeného pro navržené zařízení je zde:

\lstset{
  basicstyle=\footnotesize
}
\begin{lstlisting}
# Provides:          logger
# Required-Start:    $syslog $time $pesnet
# Required-Stop:     $syslog $time $pesnet
# Should-Start:      
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start logger daemon.
# Description:
\end{lstlisting}

Hodnota Provides určuje název služby poskytované tímto skriptem. Přes tento název se na tento skript odkazují další skripty které ke svému běhu tuto službu potřebují. Hodnoty Required-Start a Required-Stop definují, které další služby musí běžet aby mohl být příslušný skript spuštěn s parametrem start, případně stop. Hodnota Should-Start určuje které služby by měly být spuštěny, pokud jsou k dispozici. Pokud však k dispozici nejsou je možné je přeskočit. Hodnoty Default-Start a Default-Stop definuje runlevely na kterých má být služba spuštěna či zastavena. Pro správnou funkci navrhovaného zařízení muselo být několik nových init skriptů vytvořeno a několik původních upraveno. Nově vytvořené                  a upravené skripty jsou zde stručně popsány a uloženy na přiloženém CD.

\subsubsection{gpioinit}
Tento skript inicializuje stav universálních vstupů a výstupů. Pin PA11, sloužící pro testování kapacity zálohovacích kondenzátorů, je nastaven jako výstup a jeho hodnota je nastavena na 0. Tím je zajištěno jejich nabíjení. Piny PA25 a PA22, sloužící pro čtení stavu napájecího napětí a napětí na kondenzátorech jsou nastaveny jako vstupy.

\subsubsection{powerwait}
Úkolem tohoto skriptu je pozastavit proces startovaní systému až do doby kdy nejsou dostatečně nabity zálohovací kondenzátory. Vlastní skript nespouští žádnou službu ani neprovádí žádné nastavení. Pouze v nekonečné smyčce čeká na změnu stavu na vstupním pinu PAxx. Jakmile přejde do stavu X skript se ukončí. Zároveň s přidáním tohoto skriptu byl upraven skript mountall tak aby ke svému spuštění vyžadoval dokončení skriptu powerwait. Tím je zajištěno že disk nebude připojen pro zápis dříve než je v kondenzátorech dostatek energie na bezpečné dokončení tohoto zápisu a zároveň nejsou blokovány další skripty, které ke svému běhu nevyžadují zápis na disk.

\subsubsection{powercheckstart}
Jediným úkolem tohoto skriptu je spustit na pozadí další skript, powercheck. Ten běží trvale na pozadí a v jednosekundových intervalech kontroluje stav vstupu PA25. Případný výpadek proudu je signalizován přechodem vstupu PA25 ze stavu L do H. Pokud je stav vstupu PA25 dvakrát za sebou H (tím je zajištěno ignorování krátkých výpadků) je vyhodnocen výpadek proudu. V reakci na výpadek je do souboru \texttt{/etc/powerstatus} uložen znak F a poslán signál SIGPWR procesu init. 

Proces init reaguje na příchod signálu SIGPWR zkontrolováním obsahu souboru \texttt{/etc/powerstatus}. Na základě hodnoty v tomto souboru je provedena jedna z následujících činností:
\begin{itemize}
	\item F - Spustí skripty powerwait a powerfail
	\item O - Spustí skript powerokwait 
	\item L - Spustí skript powerfailnow  
\end{itemize}
V případě navrhovaného zařízení je použit pouze skript powerfail, ve kterém je zavolán příkaz halt. Ten předá procesu init signál pro přechdod do runlevlu 0.

\subsubsection{halt}
Tento skript zajišťuje vypnutí systému. Je spouštěn jako poslední a zajišťuje vlastní vypnutí systému. U počítačů s ATX zdrojem zajistí přímo odpojení napájení. FOX Board není vybaven žádným elektronickým spínačem který by umožňoval odpojit napájení. Systém se tedy nevypne ale čeká na odpojení napájení FOX Boardu, externí reset, případně příkaz předaný přes sériovou konzoli. Externí reset ani sériová konzole nejsou v navrženém zařízení použity a k resetu by tedy mohlo dojít jen odpojením napájení. Toto chování je v případě navrhovaného zařízení krajně nevhodné. V případě výpadku vstupního napájení dostatečně dlouhého na to, aby zahájil vypínání systému, ale ne dost dlouhého pro úplné vybití zálohovacích kondenzátorů, by systém zůstal čekat na dostatečně dlouhý výpadek napájení.

Z tohoto důvodu byl skript upraven tak, že namísto pokusu o vypnutí systému v nekonečné smyčce, čeká na obnovení napájení a pokud k němu dojde, vyvolá softwarový reset. Pokud k obnovení vstupního napájení nedojde před vybytím zálohovacích kondenzátorů dojde k vypnutí napájení FOX Boardu. Vypnutí systému v tomto okamžiku je již bezpečné, protože v době vykonávání skriptu halt jsou již ukončeny všechny daemony a odmountovány všechny disky.


\subsubsection{pesnet}
Tento skript při spouštění systému zavede příkazem insmod ovladač sběrnice pesnet, používaný                 pro čtení dat ze sítě automatů Micropel a následně v adresáři /dev/pesnet0/ vytvoří speciální soubory pro přístup k jednotlivým automatům v síti.

\subsubsection{logger}
Tento skript zajišťuje spuštění daemonu logger při spouštění systému a jeho ukončení při vypínání. Tuto činnost provádí přes volání nástroje start-stop-daemon. Použití tohoto programu značně zjednodušuje spouštění a vypínání daemonů. Při spouštění zkontroluje, zda již požadovaný daemon neběží a pokud ano tak ho znovu nespouští. Při vypínaní najde příslušný daemon a zašle mu signál SIGTERM, kterým ho žádá o ukončení. Určitým problémem může být identifikace již běžícího daemonu při spouštění a ukončování. Pro základní rozpoznávání daemonu je využit jen název příslušného spustitelného souboru. V tomto případě však nastanou problémy pokud je spuštěno více instancí jednoho daemonu a start-stop-daemon se chová podobně jako příkaz killall. Pro jednoznačnou identifikaci je v navrhovaném řešení použit přepínač pidfile. Při použiti tohoto přepínače                            se k identifikaci daemonu nepoužívá jeho název, ale přímo PID uložené v souboru zadaném bezprostředně za tímto přepínačem. Aby bylo možné využít tuto funkci musel být program logger doplněn o schopnost vytvořit tento soubor.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

\section{Komunikace přes RS485}
Standardní linuxové jádro neobsahuje ovladač pro RS485. Potřebná funkcionalita je však velmi podobná funkci běžného ovladače sériového portu, který je přítomen. V zásadě jsou potřeba vyřešit dva problémy. Zajistit přepnutí do RS485 módu, zajišťujícího správné přepínání budiče sběrnice a zajistit 9-ti bitovou komunikaci. Přepnutí do RS485 módu je možné zajistit jednoduchou modifikací hodnoty jediného konfiguračního registru (v ovladači implementovaného pomocí volání ioctl). Větší problém je zajištění 9-ti bitové komunikace. 

Nejjednodušší přístup, nevyžadující další modifikace, spočívá ve využití parity. Při vysílání se postupuje tak, že se před vysláním každého byte nastaví sudá nebo lichá parita tak, aby měl 9-tý bit správnou hodnotu. Při příjmu se postupuje podobně. V prvním kroku je nutné nastavit, aby byly programu předávány i byty přijaté se špatnou paritou a pak je možné zjistit, podle správnosti parity, hodnotu 9-tého bitu. Tento přístup má však jednu zásadní nevýhodu. Při změně nastavení parity dochází k resetu hw vysílače, který vede k přerušení vysílaní aktuálního znaku. Program by tedy musel zajistit, aby nebyl odeslán nový znak před dokončením předchozího, což by bylo z hlediska načasovaní velmi náročné.

Další možností, jak se vypořádat s 9-ti bitovým přenosem, je úprava původního ovladače. Zde je však již nutné provést poměrně rozsáhle úpravy původního ovladače. Navíc se tato cesta ukázala jako neschůdná, protože i v tomto případě nemůže program běžící v uživatelském prostoru dodržet rychlost odezvy vyžadovanou při komunikaci (odezva musí přijít v čase odpovídajícím třem znakům, to při rychlosti 57600 baudu odpovídá přibližně 0,6 ms).

Dosáhnout potřebné rychlosti odezvy je možné v zásadě dvěma způsoby. Buď použitím realtime jádra, nebo napsáním vlastního ovladače. V této práci byla zvolena cesta vlastního ovladače. Ten využívá obsluhu přerušení od příslušného portu, v kterém zajišťuje kromě přijmutí a odeslání jednotlivých znaků  i základní vyhodnocení přijatého rámce a pokud to vyžaduje, tak i odeslání příslušné odpovědi. Tímto postupem je možné dosáhnout velmi krátké odezvy.

\subsection{Ovladač}
Jak již bylo rozebráno výše, SW pro komunikaci přes sběrnici RS485 byl realizován jako ovladač v podobě jaderného modulu. Původní pokus vytvořit ovladač pouhou úpravou ovladače standardního UART se ukázal jako neschůdný. Úprava komunikace na 9-ti bitovou vyžadovala velké zásahy do struktury ovladače. Dalším problémem byla rychlost odezvy v případě že byla komunikace vyhodnocována v uživatelské aplikaci. Při nízkém zatížení systému komunikace probíhala i když ne příliš spolehlivě, při vyšším nefungovala vůbec. Oba tyto problémy byly odstraněny vytvořením vlastního ovladače.

Vlastní ovladač se dá rozdělit do dvou častí. První část se stará o vlastní komunikaci a celá je prováděna v obsluze přerušení. Druhá se stará o komunikaci s procesy běžícími v uživatelském prostoru.

\subsubsection{Obsluha přerušení}
Použité přerušení může být vyvoláno z několika důvodů. Procedura zavolaná po jeho vzniku tedy musí zjistit, z jakého důvodu přerušení vzniklo a rozhodnout se, zda ho zpracuje nebo předá zpracování dál. U vytvořeného ovladače přicházejí v úvahu dva důvody pro vznik přerušení. Prvním je připravenost UARTu k odeslaní dalšího znaku. V tom případě ovladač zkontroluje buffer odchozích znaků a pokud není prázdný, tak z něj vyjme jeden znak a předá ho k odesláni. Druhou možností je přijetí znaku. Pokud má přijatý znak nastaven 9tý bit (jedná se o první znak packetu), je výstupní buffer vyprázdněn a je do něho přidán právě přijatý znak. V opačném případě je znak pouze přidán na konec bufferu. Po přijetí každého znaku je provedena kontrola, zda již není v bufferu uložen celý packet (vyhodnocení je provedeno na základě typu packetu uvedeném v jeho hlavičce a počtu přijatých znaků). Pokud není je obsluha přerušení ukončena, v opačném případě je provedena kontrola CRC a packet je předán k dalšímu zpracování. Naprostá většina packetu nemá pro náš systém význam a je tedy zahozena bez jakékoliv odpovědi. Výjimkou je packet, který předává token pro řízení sběrnice našemu zařízení. 
Pokud má naše zařízení požadavek na čtení či zápis, odešle tento požadavek na sběrnici. Po přijetí odpovědi tuto odpověď předá do procesu v uživatelském prostoru a probudí proces, který na tuto operaci čekal. Nakonec musí vždy předat  řízení sběrnice další stanici. Kromě výše popsané funkce musí ovladač řešit množství problemů vznikajících při chybách v komunikaci, které zde kvůli své složitosti nejsou rozebírány.

\subsubsection{Komunikace uživatelského procesu s ovladačem}
Komunikace s procesem běžícím v uživatelském prostoru probíhá přes standardní volání jádra OS funkcemi: open, release, seek, read a write. Funkce open a release jsou volány při otevření/zavření příslušného souboru a v případě tohoto ovladače provádí pouze přípravu některých dále používaných struktur. Funkce seek slouží k nastavení místa v souboru. To odpovídá adrese v paměti příslušného automatu se kterým chceme dále pracovat. Funkce read a write jsou jediné, které přímo vyvolávají komunikaci. Jejich funkce je velmi podobná. Na začátku zamknou mutex, který zajišťuje, že bude v jeden okamžik zpracováván pouze jeden požadavek. Poté na připravené místo v paměti (které je kontrolováno z obsluhy přerušení) uloží adresu automatu, s kterým má proběhnout komunikace, typ operace (čtení/zápis), případně data která mají být zapsána. Nakonec pomocí atomické operace označí požadavek za připravený a uspí se. Po probuzení (vyvolaném v obsluze přerušení) zkontroluje výsledek operace, zkopíruje příslušná data do uživatelského procesu a uvolní zámek.

\section{Paměťové médium}
Jak je popsáno dříve, na desce FOX Board jsou k dispozici dvě uložiště dat. Přímo na desce je k umístěna 8MB flash paměť. Pokud je její kapacita nedostatečná, je možné použít microSD kartu. Integrovaná paměť je pro ukládání dat příliš malá a je tedy nutné použít microSD kartu.
Dnes dostupné microSD karty jsou k dispozici v kapacitách od 2GB a poskytují tedy dostatek prostoru pro uložení systému i zaznamenaných dat. Jejich použití však přináší určité problémy. Technologie FLASH umožňuje jen značně omezený počet přepisů. Ten bývá většinou udáván v rozmezí 10 000 - 100 000. V běžných SD kartách je využívána technologie MLC, která umožňuje v jedné paměťové buňce uchovat více bitů. Tímto postupem je dosaženo zvýšení kapacity bez zvětšení plochy vlastní paměti a tím i snížení ceny. Toto zvýšení kapacity je však vykoupeno sníženou trvanlivostí paměti. Dá se tedy předpokládat, že FLASH paměti použité v běžných SD kartách budou mít trvanlivost blížící se spodní hranici. 

Operační systém GNU/Linux obsahuje ovladače pro mnoho souborových systémů určených speciálně pro použití s FLASH paměti, které organizují zápis do paměti tak, aby i v případě opakovaného zápisu do stejného místa v jednom souboru docházelo k zápisu na různá místa v paměti. V případě častého zápisu malého množství dat do jednoho souboru je tímto postupem zvýšena životnost paměti o několik řádů. Všechny tyto souborové systémy  vyžadují přímý přístup k paměti.
 
SD karty jsou nejčastěji využívány se souborovým systémem FAT, který vůbec nepočítá s použitím na paměťovém mediu s omezeným množstvím přepisů. Aby byla prodloužena životnost karet při tomto použití, provádí řadič mapování logických bloků na bloky fyzické (Wear Leveling). Pokud bylo do některého bloku provedeno velké množství zápisů nebo pokud došlo k chybě při čtení, může tento blok přesunout na místo jiného bloku (za tímto účelem obsahuje karta rezervní bloky nad svou nominální kapacitu). Pro detekci a opravu chyb obsahuje každý fyzický blok samoopravný kód. Pokud tedy dojde k selhání omezeného množství bitů je možné blok přesunout a přemapovat bez ztráty dat.

Celý výše popsaný mechanizmus sice zvyšuje životnost karty při typickém využití karty, bohužel však znemožňuje použití souborových systémů určených pro FLASH paměti. Mapováním logických bloků na fyzické totiž probíhá zcela transparentně bez možnosti ho jakkoliv vypnout nebo obejít                             a neumožňuje tedy přímý přístup k  paměti. Pokud by byl v tomto případě použit souborový systém, který se snaží o rozprostření zápisu stejně jako řadič uvnitř karty, mohlo by docházet k těžko předvídatelným interakcím. 

Jako nejlepší varianta se tedy jeví použít na kartě běžný souborový systém a omezit množství zápisu. Za tímto účelem byl zvolen souborový systém ext2. Jehož hlavní výhodou v tomto ohledu je absence journálování, které by vedlo k zbytečným přepisům. Dalšího omezení je dosaženo použitím parametru noatime při mountování oddílu. Ten zabrání zapisování času posledního přístupu k souboru. K omezení zápisů také přispěje změna parametrů ovlivňujících práci s cache. Použito je následující nastavení:
\begin{lstlisting}
echo 60000 > /proc/sys/vm/dirty_writeback_centisecs
echo 60000 > /proc/sys/vm/dirty_expire_centisecs
\end{lstlisting}
Tyto hodnoty prodlužují dobu po kterou může být odložen zápis dat z cache na paměťové medium. Poslední postup je implementován na aplikační vrstvě. Program pro záznam dat do databáze neukládá naměřená data do databáze okamžitě, místo toho je shromažďuje a zapíše vždy všechny naráz v určitém intervalu.

Použití souborového systému bez journálování přináší problém s jeho možným poškozením při nenadálém vypnutí\footnote{Při testování se i když v menší míře, projevily problémy i při použití journálovacího souborového systému. Pravděpodobně jsou způsobeny tím, že erase block je podstatně větší než jedna stránka, takže přerušený zápis do jednoho místa může způsobit poškození dat na místě, z pohledu souborového systému, naprosto nesouvisejícím. Možná je také interakce s interním wear-levelingem.}. K tomu může dojít buď úmyslným vypnutím napájení celého rozvaděče nebo výpadkem sítě. V případě vypnutí by bylo možné situaci řešit trojpolohovým vypínačem nebo časovým relé, které by daly operačnímu systému čas na ukončení práce. V případě nepředvídaného výpadku je jedinou možností použití UPS.  

Pro zvýšení spolehlivosti systému je také vhodné namísto běžné SD karty použít kartu průmyslovou. Tyto karty bývají vyráběny SLC technologii a mají tedy podstatně delší životnost. Například karty společnosti STEC umožňují 100 000 přepisů jedné buňky, 2 000 000 v kombinaci s wear-levelingem\cite{SD}. Kromě toho průmyslové karty dosahují větší spolehlivosti a odolnosti. 
%Velkou výhodou je dostupnost dokumentace popisující funkci wear-levelingu a umožňující výpočet předpokládané životnosti.

Z výše uvedených důvodu byl v navrhovaném systému použit souborový systém ext2. Problémy s výpadkem napájení jsou vyřešeny krátkodobě zálohovaným zdrojem, který dá systému dostatek času pro ukončení činnosti v případě nenadálého výpadku proudu. 

\subsection{Kapacita}
Důležitým parametrem je kapacita paměťového média. Vzhledem k tomu že naměřená data jsou ukládány do databázového souboru, je poměrně složité předem vypočítat kolik vzorků bude možné uložit. Tato hodnota byla tedy určena experimentálně. Databáze obsahující 30 851 315 vzorků má velikost 1.7GB a na uložení jednoho vzorku je tedy potřeba přibližně 55B. Jeden den používaní sterilizačního přístroje, který vygeneruje 57600 vzorků, spotřebuje 3.16MB prostoru na paměťové kartě. Na 2GB kartě zbývá po instalaci systému přibližně 800MB prostoru pro uživatelská data. Tento prostor stačí pro cca 250 dní záznamu. Pokud je potřeba archivovat více dat stačí použít 4GB kartu. Ta bude stačit na přibližně 875 dní. Záznam lyofilizačního procesu generuje pouze 8640 vzorků za den a při použití 2GB karty je  možné archivovat záznam za 1600 dní.

\section{Databazový model}
Pro uložení nastavení parametrů záznamu i vlastní zaznamenaná data je použita jedna databáze v souboru umístěném v adresáři /var/db/. Pro účely komunikace přes GSM je vytvořena druhá databáze v dalším souboru umístěném ve stejném adresáři, ta však bude popsána až v kapitole zabývající se GSM komunikací. E-R diagram navržené databáze je na obrázku \ref{E-R1}. V začátcích vývoje zařízení byla používána v té době aktuální distribuce Debian Lenny a s ní distribuovaná verze SQLite 2.8.17, která nepodporovala cizí klíče. Funkcionalita cizích klíčů tedy musela být ručně doplněna pro jednotlivé tabulky za pomoci triggeru. Později byl vývoj převeden na nově vydanou verzi Debianu Squeeze, která přinesla novější verzi SQLite, která již podporovala cizí klíče a bylo tedy možné nahradit velké množství triggeru cizími klíči a tím celý návrh výrazně zpřehlednit. Vzhledem k poměrně nízkému výkonu použitého mikroprocesoru, malé paměti RAM a pomalému přístupu k paměti FLASH bylo nutné vytvořit co nejjednodušší návrh a vyhnout se nákladným operacím jako je JOIN. Navržené tabulky budou popsány dále.

 %bht
\begin{figure}[h!]
\begin{center}
  \includegraphics[width=12cm,keepaspectratio]{ER.png}
  \caption{
      \rm{
      \hspace{0.1cm} Databázový systém modelu.}}
  \label{E-R1}
\end{center}
\end{figure}

\subsubsection{Tabulka sensors}
Tato tabulka obsahuje informace o dostupných senzorech. Jako primární klíč je použit INT s funkcí AUTOINCREMENT. V sloupci source je uložena cesta k souboru, ze kterého jsou získávány naměřené hodnoty. Typ souboru z kterého jsou hodnoty načítána je dán sloupcem type. Ta může nabývat hodnot: binary, text, pesnet. Z binárních souborů je přečten počet bytů odpovídající datovému typu přímo                           do proměnné. U textových souborů je načten řetězec, který je před uložením převeden na číslo. Typ souboru pesnet je v podstatě aliasem pro typ binary, liší se jen ve způsobu zápisu adresy. Ve sloupci adresa je uložena pozice v souboru, ze které bude hodnota načtena. U binárních souboru je proveden seek na tuto adresu a následně přečten počet bytů odpovídající datovému typu. U textových souborů je přečten počet bytů odpovídající adrese a následně je načten řetězec zakončený nečíselným znakem (vše kromě znaku plus, minus, číslic a tečky). Tento řetězec je následně převeden na číslo. Pokud je zadán typ pesnet je přístup k souboru stejný jako u binárního, jen syntaxe sloupce adresa je rozdílná, neobsahuje přímo číslo, ale definici proměnné v syntaxi používané v jazyce SIMPLE. 
Sloupec datatype určuje datový typ příslušné veličiny, může nabývat hodnot: 

\storestyleof{itemize}
\begin{listliketab}
    \begin{tabular}{Llll}
        \textbullet &  INT8   &  Pro 8-bitovou hodnotu se znaménkem   \\
        \textbullet &  INT16  &  Pro 16-bitovou hodnotu se znaménkem  \\
        \textbullet &  INT32  &  Pro 32-bitovou hodnotu se znaménkem  \\
        \textbullet &  UINT8   &  Pro 8-bitovou hodnotu bez znaménka   \\
        \textbullet &  UINT16  &  Pro 16-bitovou hodnotu bez znaménka  \\
        \textbullet &  UINT32  &  Pro 32-bitovou hodnotu bez znaménka  \\
        \textbullet &  FLOAT  &  Pro 32-bitovou číslo s plovoucí desetinou čárkou dle IEEE754\\                    
    \end{tabular}
\end{listliketab}

Sloupec name obsahuje pouze textový popis senzoru použitý pro jednoduchou identifikaci příslušného sensoru. 
 


\subsubsection{Tabulka records}
Tato tabulka obsahuje nastavení, týkající se parametrů jednotlivých záznamů. Cizí klíč sensor\_id odkazuje na sensor ze kterého má být pořizován záznam. Sloupec interval udává vzorkovací frekvenci příslušného záznamu v milisekundách. Sloupec unit obsahuje jméno jednotky (°C, kPa apod.) příslušné veličiny. To je Využito při tvorbě tabulek a grafů. Sloupec decimals má význam u veličin, které jsou čteny jako celočíselné, ale znázorňují zlomky nebo násobky základní jednotky. Například teplota je v použitých automatech reprezentována celočíselným datovým typem v desetinách °C. Pro získání skutečné hodnoty ve °C je tedy potřeba přečtenou hodnotu vydělit deseti a atribut decimals tedy bude mít hodnotu 1. Sloupec name obsahuje textový popis záznamu použitý pro jednoduchou identifikaci záznamu. 

\subsubsection{Tabulka data}
Do tabulky data jsou ukládána vlastní naměřená data. Cizí klíč record\_id určuje ke kterému záznamu naměřená položka přísluší. Sloupec datetime obsahuje čas ve který byl záznam pořízen ve formátu unixového času vynásobeného tisícem (místo sekund od 1.1. 1970 jsou tedy použity milisekundy). Sloupec value obsahuje vlastní přečtenou hodnotu. Sloupec d\_value obsahuje změnu hodnoty oproti minulému měření a je použit primárně pro automatické vytváření protokolů. Díky němu je jednoduše možné například určit okamžik ve kterém došlo k rychlé změně měřené veličiny. Hodnoty jsou do tohoto sloupce nastavovány triggerem, který je spouštěn po přidání nového záznamu.

\subsubsection{Tabulka data\_last}
Tato tabulka neobsahuje žádná unikátní data. Pomoci triggeru spouštěného přidáním nového záznamu do tabulky data, jsou v této tabulce aktualizovány hodnoty naměřené na jednotlivých senzorech. Tabulka tedy obsahuje poslední naměřenou hodnotu na každém čidle. Stejného výsledku by bylo možné dosáhnout i dotazem nad tabulkou data, tento přístup je však z hlediska rychlosti výhodnější.  Vzhledem k tomu, že poslední naměřená hodnota je používána pro výpočet d\_value při každém novém vložení hodnoty, je rychlost tohoto dotazu zásadní.

\subsubsection{Tabulka protocols}
V této tabulce jsou uloženy informace o začátku a konci všech protokolů, vytvořených z naměřených dat. Začátek i konec je uložen ve formátu unixového času
\footnote{V operačním systemu UNIX a standartu POSIX je čas měřen jako počet sekund od 1.1.1970 GMT.}
Dále obsahuje sloupec name který slouží k uchování názvu protokolu.

\subsubsection{Tabulka protocols\_data}
Tato tabulka určuje, které z měřených veličin budou použity jako datové řady pro tvorbu protokolu. Sloupec protocol\_id slouží jako cizí klíč a vytváří vazbu s tabulkou protocols.  Dalším cizím klíčem je atribut record\_id, který vytváří vazbu s tabulkou record.

\subsubsection{Tabulka protocols\_param}
V této tabulce jsou uloženy další parametry jednotlivých datových řad vytvořených z naměřených dat, jako je nastavení rozsahu hodnot (použité pro určení měřítka os grafu), barva veličiny v grafu, maximální a minimální přípustná hodnota (hodnoty mimo toto rozmezí jsou v tabulce barevně zvýrazněny) apod. Tyto parametry jsou k jednotlivým datovým řadám přiřazeny pomocí cizího klíče protocols\_data\_id. Sloupec name určuje název parametru a může nabývat hodnot: MINVALUE, MAXVALUE, COLOR, MINVALID, MAXVALID. Sloupec value pak obsahuje hodnotu příslušného parametru. Všechny tyto parametry by mohli být přímo v tabulce protocols\_data, jejich uložení do zvláštní tabulky však přináší větší flexibilitu při přidávání nových možností. Pokud by byly parametry přímo součástí tabulky protocols\_data, bylo by nutné pro přidání nových parametrů  upravit návrh této tabulky. V případě, že jsou však uloženy výše popsaným způsobem ve zvláštní tabulce, je možné přidávat nové parametry bez úpravy návrhu databáze.  

\section{Daemon logger}
Úkolem tohoto daemonu je načítání dat ze speciálních souborů (poskytovaných například ovladačem sběrnice Pesnet) a jejich ukládání do databáze. Program byl vytvořen v C++ a jeho zdrojové soubory             i makefile je na přiloženém CD.

Celý program je rozdělen do dvou částí. Soubory \texttt{reclist.c} a \texttt{reclist.h} obsahují třídu RecList, která zajišťuje vlastní čtení dat a jejich zápis do databáze. Soubor logger.c obsahuje kód starající se o inicializaci programu, zpracování signálů a běh programu jako daemonu.

První věc, kterou program po svém spuštění dělá, je zpracování parametrů předaných přes příkazový řádek. K tomu je využívána funkce getopt, která je součástí glibc. Vzhledem k tomu, že většina konfigurace je načítána z databáze, je těchto parametrů poměrně málo:
\begin{description}
  \item[-p cesta] \hfill \\
  Určuje cestu k použitému databasovému souboru. Pokud není žádný určen je použit soubor /var/db/database.sqlite
  \item[-d] \hfill \\
  Pokud je použita tato volba tak se program spustí jako daemon.
  \item[-c t] \hfill \\
  Tato volba určuje časový interval, po kterém jsou data z bufferu zapsána na disk.
\end{description}

Dalším krokem po zpracování parametrů je, pokud byl použit příslušný přepínač, převedení běhu programu na pozadí. Aby mohl program běžet na pozadí je potřeba provést několik kroků. Prvním z nich je odpojeni se od svého rodiče. To je provedeno tak, že program zavolá funkci fork, přičemž původní proces skončí a osiřelý potomek je adoptován procesem init. Poté je pomocí příkazu setsid() vytvořena nová session\footnote{Session je skupina skupin procesů. Každá session může mít přidělen jeden řídící terminál} a nová skupina procesů\footnote{Skupina procesů (process group) je množina procesů, kterým lze posílat signály jako celku}. Tím je zajištěno, že se daemon stane součástí nové skupiny procesů a nebude tak dostávat nežádoucí signály. Následně nastaví svůj pracovní adresář na /, aby nebránil případnému odmontování souborového systému. Aby byl nezávislý na terminálu (případně na jiném otevřeném souboru) musí uzavřít všechny otevřené soubory. Na závěr jsou standartní vstup, výstup a chybový výstup přesměrovány do souboru /dev/null a veškeré chybové výstupy jsou namísto toho pomocí příkazu syslog zaznamenávány do systémového logu.

Ať již běží program na pozadí jako daemon, nebo zůstal na popředí, musí si zaregistrovat obsluhu signálů. V případě programu logger je zvlášním způsobem ošetřen pouze signál TERM a INT. Oba tyto signály zavolají funkci sigTermHandler. Ta změní obsah globální proměnné, která je testována                   v dalších částech programu. 

Poté již následuje vytvoření objektu RecList. Konstruktor tohoto objektu si načte konfiguraci záznamu dat z databáze a na základě těchto informací naplní vnitřní seznam (jedná se o objekt std::map, který jako klíč používá id z tabulky records) položkami typu RecItem. Každá tato položka představuje jednu veličinu, kterou je potřeba zaznamenávat a obsahuje parametry záznamu (zdrojový soubor, adresu, vzorkovací frekvenci a čas posledního záznamu). Tím je dokončena inicializace programu a je možné přejít k vlastnímu záznamu dat.

Celý záznam dat běží ve dvou vláknech vytvořených za pomoci knihovny pthread. První vlákno obstarává čtení dat v nastavených intervalech, ale nezapisuje je přímo do databáze (jedná se o poměrně pomalý proces a mohlo by kvůli němu dojít k pozdnímu přečtení následujícího vzorku), ale místo toho jsou ukládány do fronty. Druhé vlákno v nastavených intervalech přečte data z fronty a uloží je                     do databáze. Sinchronizace přístupu k frontě je řešena mutexem. Zjednodušená funkce programu je znázorněna na \ref{loggerFCH}.

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=12cm,keepaspectratio]{diagram1.png}
  \caption{
      \rm{
      \hspace{0.1cm} Vývojový diagram programu logger.}}
  \label{loggerFCH}
\end{center}
\end{figure}


Čtení dat ze specíálních souborů probíhá ve smyčce, která je ukončena jen v případě přijetí signálu TERM. Na začátku této smyčky je pro každou položku v seznamu zaznamenávaných veličin určen čas, za který má být přečtena. Nejnižší čas je poté použit jako parametr funkce usleep. Tím je zajištěno uspání vlákna do doby, kdy má dojít k záznamu. Po probuzení je zjištěna skutečná délka spánku\footnote{Specifikace funkcí sleep a usleep zajišťují, že se proces neprobudí před uplynutím zadaného intervalu (pokud nepřijde asynchroní signál), nemohou však zaručit, že se proces probudí přesně v zadaném okamžiku. Velikost tohoto zpoždění je závislá především na aktuální zátěži systému a parametrech jádra.} a na základě tohoto údaje je provedeno přečtení dat z položek seznamu u kterých vypršel čas. Čtení jednotlivých udajů probíhá pomocí synchroních operací. Jednotlivé vzorky, i pokud mají stejnou vzorkovací frekvenci, tedy nejsou pořízeny současně
\footnote{Při použití asynchronních operací by se situace příliš nezlepšila, protože ovladač sběrnice PesNet dokáže současně obsluhovat pouze jeden požadavek. Zlepšení by bylo patrné pouze v případě, že by byla data čtena ze speciálního souboru, jehož ovladač je schopný zpracovávat paralelní dotazy, nebo při čtení z nezávislých zařízení}, ale je mezi nimi určitá co?. Při použití s ovladačem PesNet je tato prodleva menší jak 10ms. Pokud je to vyžadováno je u přečtených dat provedena konverze endianity. Následně je hodnota použita na vytvoření sql příkazu, sloužícího k uložení této hodnoty               do databáze. Tento příkaz však není ihned vykonán, ale je přidán do fronty (přistup do této fronty je chráněn mutexem). Poslední akcí po přečtení každé položky je naplánování příštího čtení.

Zápis dat do databáze je zajišťován druhým, paralelně běžícím vláknem. Před vlastním zápisem se vždy vlákno uspí, na dobu určenou parametrem -c. Poté jsou z fronty sql příkazů postupně odebírány (přístup je opět synchronizován mutexem) jednotlivé položky a je z nich připraven jeden dlouhý příkaz, který je následně proveden. Vzhledem k vlastnostem sqlite databáze (omezená možnost konkurenčního přístupu) je možné, že příkaz selže. V tom případě se program pokusí příkaz zopakovat. Pokud opakovaně neuspěje, jsou data zahozena a je odeslán příslušný záznam do logu. Celý tento postup je opakován v cyklu, dokud není přijmut signál TERM.

\section{Webové rozhraní}
Vlastní webové rozhraní je napsáno v jazyce PHP5, který generuje stránky ve značkovacím jazyce xhtml. Vzhled stránek je na straně klienta upraven pomocí kaskádových stylů (css). Zdrojový kód webového rozhraní se dá rozdělit na několik základních části.

Funkce SaveToCache má dva parametry. Prvním z nich je md5 hash. Druhým jsou data určená k uložení. Funkce po svém zavolání vloží do tabulky řádek s příslušným hashem a daty. Zároveň zkontroluje počet záznamů v cache a pokud je větší než zadaná hodnota smaže nejstarší záznam. 

\subsection{Knihovna pro práci s daty}
Pro práci s naměřenými daty byly vytvořeny dvě třídy dataserie a datatable. Zdrojové kódy obou tříd jsou umístěny ve stejnojmenných souborech. Obě třídy využívají cachováni výstupů, za účelem zrychlení odezvy.

\subsubsection{Třída dataserie}
Tato třída zajišťuje práci s jednou měřenou veličinou v zadaném časovém intervalu. Její konstruktor má jako parametr číslo záznamu v tabulce record, začátek a konec časového intervalu. Všechny tyto parametry jsou použity k vytvoření mdř hashe přístupného přes metodu getHash(), která je dále používána pro cachování výsledků. 
Třída obsahuje parametry získané z tabulky record jako je vzorkovací frekvence a jednotka měřené veličiny. Dále poskytuje informaci o maximální a minimální hodnotě měřené veličiny v zadaném intervalu. Hlavní funkcí třídy je poskytnutí přístupu k jednotlivým naměřeným hodnotám, zajišťováném metodou getValue. Ta má jako jediný parametr čas měření a vrací hodnotu naměřenou v tento okamžik. Pokud přesně v tento okamžik nebylo provedeno měření, vrátí lineární aproximaci hodnoty získanou ze dvou nejbližších vzorků. Pokud je potřeba přistupovat pouze k eskutečně naměřeným hodnotám, je možné procházet přímo pole data. Jedná se o asociativní pole, kde klíč je čas pořízení vzorku a hodnota obsahuje velikost naměřené veličiny. Toto pole není naplněno hodnotami hned v konstruktoru třídy, ale až ve chvíli prvního přístupu k němu. Tohoto chování je docíleno použitím magických metod \_\_get() a \_\_set(), které jsou volány pokaždé, kdy dojde k přístupu k nedefinované nebo nepřístupné vlastnosti. Účelem tohoto chování je zrychlení programu v případě, kdy byla vytvořena instance objektu dataserie jen za účelem získaní informací jako je maximální hodnota veličiny v určitém časovém intervalu nebo získáni názvu jednotky.  

\subsubsection{Třída datatable}
Tato třída slouží k vytvoření tabulky  nebo grafu složeného z několika měřených veličin v určeném časovém intervalu. Prvním parametrem konstruktoru je pole id, které odkazuje na záznamy v tabulce records. Na základě těchto id jsou vytvořeny instance třídy dataserie, které jsou dále používány pro přístup k naměřeným hodnotám. Dalšími parametry je začátek a konec časového intervalu, se kterým se má pracovat. Hlavní funkcí této třídy je tvorba tabulky hodnot a grafů z naměřených hodnot.

K zobrazení tabulky hodnot slouží metoda showTable. Tato funkce má jako parametr formátovací řetězec určující formát zobrazení času u jednotlivých vzorků. Další nepovinný parametr může nastavit název grafu použitý v jeho hlavičce. Na začátku funkce je vypočítán md5 hash, skládající se z hashu všech použitých objektů dataserie, parametrů metody showTable a názvu funkce. Výsledný hash je použit jako parametr funkce GetFromCache, která se pokusí získat z cache dříve uložený výsledek funkce. Pokud je úspěšná jsou vrácena data získaná z cache. V opačném případě musí být celá tabulka sestavena od začátku. Hlavička tabulky je vytvořena na základě informací získaných z tabulky record pomocí třídy dataserie (jméno záznamu a název měřené veličiny). Celá hlavička je uzavřena do tagu thead, ten zajišťuje, že při tisku dlouhé tabulky je hlavička vytištěna na začátku každé stránky
\footnote{Chování tohoto tagu se mezi jednotlivými prohlížeči značně liší. Ve Firefoxu jsou hlavičky tisknuty bez problému na všech stránkách, stejně jako v Internet Exploreru, naopak prohlížeč Google Chrome tiskne hlavičku jen na první stránce.}.
Po hlavičce již řádky obsahující naměřená data. Každý řádek obsahuje hodnoty všech veličin v jednom čase. Tyto časy jsou určeny dle časů, ve kterých byly naměřeny hodnoty první datové řady. Hodnoty dalších veličin jsou získány metodou getValue. Z toho mimo jiného vyplývá, že pokud nejsou jednotlivé veličiny vzorkovány ve stejný okamžik je použita lineární aproximace.
Celá tabulka je po sestavení uložena funkcí SaveToCache do cache pro další použití.

Další možností výstupu je metoda showGraph. Její funkce je podobná jako u metody showTable, včetně cachování výsledků. Tato metoda vytváří ze zadaných dat graf ve formátu SVG. Tento formát byl zvolen zejména kvůli tomu, že se jedná o formát vektorový, takže je možné jeden obrázek použít jak pro zobrazení na obrazovce, tak pro tisk. V případě použití rastrového obrázku by bylo pro kvalitní tisk potřeba použít obrázek o vysokém rozlišení, jehož generování by bylo vzhledem k omezeným paměťovým možnostem problematické. Díky tomu, že je pro tvorbu vlastního webového rozhraní použita technologie xhtml, vycházející z xml, je možné vložit vytvořený obrázek přímo do kódu stránky. V případě, že je použit starší prohlížeč, který neobsahuje podporu pro zobrazení obrázků                  ve formátu SVG, je prohlížeči automaticky předložen obŕazek ve formátu PNG. Ten je z původního SVG vygenerován pomocí utility rsvg-convert. Vzhledem k omezeným možnostem FOX Boardu je  obrázek v nízkém rozlišení (1024x586), které dostačuje pro zobrazení na monitoru, ale je zcela nevyhovující pro tisk. 

\subsection{Knihovna pro práci s cache}
Při tvorbě tabulek a grafů z velkého množství dat se objevily problémy s rychlostí. Pro zrychlení odezvy jsou výsledky ukládány do cache, ve které mohou být v případě opakování stejného dotazu rychle nalezeny, bez nutnosti znovu sestavovat celou tabulku či graf.

Vlastní cache je tvořena jednoduchou tabulkou se třemi sloupci. První ze sloupců slouží jako index a obsahuje md5 hash. Tento hash musí být vytvořen ze všech parametrů ovlivňujících výsledek funkce, aby bylo zajišťeno že funkce se stejným hashem mají vždy stejný výsledek (pravděpodobnost kolize md5 hashe je zanedbána). Druhý sloupec obsahuje data vrácená funkcí při předchozím volání. Poslední sloupec obsahuje datum vložení. Pro práci s touto cache jsou k dispozici dvě funkce: GetFromCache a SaveToCache.

Funkce GetFromCache příjmá jediný parametr a to md5 hash. Pokud se v cache nachází záznam s příslušnou hodnotou je vrácen řetězec obsahující data uložená s tímto hashem, v opačném případě vrátí hodnotu false.

Funkce SaveToCache má dva parametry. Prvním z nich je md5 hash. Druhým jsou data určená k uložení. Funkce po svém zavolání vloží do tabulky řádek s příslušným hashem a daty. Zároveň zkontroluje počet záznamů v cache a pokud je větší než zadaná hodnota smaže nejstarší záznam. 

\subsection{Vlastní stránky}
Jednotlivé stránky mají jednotný vzhled definovaný společnými css soubory. Ty zároveň zajišťují rozdílný vzhled stránek při zobrazení na monitoru a při tisku. Jednotlivé stránky jsou přístupné pomocí vlevo umístěného menu. Na horním okraji je umístěn stavový řádek obsahující název zařízení, reálný čas na zařízení a jméno uživatele s možností odhlásit se. Všechny stránky hned na začátku provádějí kontrolu session a v případě, že není platná přesměrují uživatele na přihlašovací stránku.

\subsubsection{Přihlášení uživatele}
Zdrojový kód této stránky je v souboru login.php. Stránka zajišťuje autentifikaci uživatele. Zadané jméno a heslo je kontrolováno proti údajům uloženým v tabulce users. Pokud údaje odpovídají, je vytvořena nová session a uživatel je přesměrován na hlavní stránku.

\subsubsection{Hlavní stránka}
Zdrojový kód této stránky je v souboru main.php. Na tuto stránku je uživatel přesměrován                            po přihlášení. Je zde umístěna tabulka všech čidel a jejich  posledních hodnot a graf zobrazující průběh všech veličin za posledních 30 min. Časový interval grafu je možné upravit zadáním konkretních hodnot do připravených editboxů.

\subsubsection{Nastavení uživatelů}
Zdrojový kód této stránky je v souboru users.php. Na tuto stránku může uživatel vstoupit pouze pokud má administrátorská práva. Je zde možné vytvářet a mazat jednotlivé uživatele, měnit jejich oprávnění a měnit jejich hesla.

\subsubsection{Nastavení snímačů}
Zdrojový kód této stránky je v souboru sensors.php. Na tuto stránku může uživatel vstoupit pouze pokud má administrátorská práva. Je zde možné upravovat a vytvářet nová čidla. Stránka zajišťuje editaci tabulky sensors. Pro každý sensor je možné nastavit cestu odkud mají být čtena data a datový typ.

\subsubsection{Nastavení záznamu}
Zdrojový kód této stránky je v souboru records.php. Na tuto stránku může uživatel vstoupit pouze pokud má administrátorská práva. Je zde možné upravovat parametry záznamu z jednotlivých čidel. Hlavním parametrem je vzorkovací frekvence. Další parametry neovlivňují přímo záznam, ale spíše způsob jeho zobrazení. Popisují barvu příslušné veličiny v grafu a podobně.

\subsubsection{Vytvoření protokolu}
Zdrojový kód této stránky je v souboru records.php. Na tuto stránku může vstoupit každý přihlášený uživatel. Je na ní možné vybrat časový interval a požadované veličiny a vytvořit z nich protokol. Ten obsahuje jednak graf a také výpis všech hodnot v podobě tabulky. Takto vytvořený protokol může být uložen do archívu nebo vytisknut.

\subsubsection{Prohlížení protokolu}
Zdrojový kód této stránky je v souboru records.php. Na tuto stránku může vstoupit každý přihlášený uživatel. Na této stránce je seznam všech ručně i automaticky vytvořených protokolů. Tyto protokoly je možné přejmenovat, smazat a prohlížet. Vzhledem k tomu že jsou použity dva různé CSS styly pro zobrazení na monitoru a pro tisk, je možné tuto stránku přímo vytisknout. Současti jako je menu a seznam protokolů jsou při tisku automaticky odstraněny.

\section{Vzdálený přístup}
Naměřená i aktuální data jsou primárně přístupná přes podnikovou sít. V případě potřeby je možné  vhodným nastavením hraničního routeru, zpřístupnit webové rozhraní i z internetu. V některých případech není intranet k dispozici nebo není intranet připojen k internetu a pro prácí s webovým rozhraním je připojen počítač přimo k FOX Boardu kříženým kabelem . Pokud je i přesto potřeba zajistit vzdálený přístup k zařízení je potřeba zvolit alternativní cestu. Vzhledem k poměrně dobrému pokrytí a relativně nízkým cenám se nabízí využití připojení přes síť GSM. Aby bylo možné připojit zařízení, je potřeba připojit k zařízení GSM modem. 
  
\subsection{Připojení GSM modemu}
V navrhovaném zařízení byl využit modem MC75i, připojený přes USB port. Připojení modemu přes USB port je rozpoznáno daemonem udev\footnote{Udev je linuxový správce zařízení. Běží jako daemon na pozadí a přijímá zprávy o inicializaci zařízení vysílané systémem uevents. V reakci na tyto zprávy pak provádí přednastavené úkoly, jako je vytváření speciálních souborů v adresáři /dev/.}, který vytvoří soubor /dev/ttyACM0. Pokud by byl modem připojen přes sériové rozhraní, byl by přístupný přes příslušný speciální soubor (/dev/ttyS4). Obě možnosti připojení jsou rovnocenné a jediný rozdíl je v nutnosti odkazovat v konfiguračních souborech na jiný speciální soubor. Aby nebylo nutné, v případě změny připojení, modifikovat několik konfiguračních souborů, je ve všech použit odkaz na /dev/modem. Tento soubor je symbolickým odkazem na soubor odpovídající aktuálnímu způsobu připojení.  

\subsection{Komunikace pomocí SMS}
SMS je možné použít pro jednoduchou konfiguraci a zjištění stavu zařízení. Hlavní výhodou je jednoduché ovládání (stačí kterýkoli mobilní telefon), relativně nízká cena a nenáročnost na kvalitu sítě. Přenos většího množství informací by však byl velmi nákladný a také rychlost odezvy není příliš velká. 

Pro práci se SMS byl vytvořen databázový /var/db/sms.sqlite. Ten obsahuje 3 tabulky. Tabulka received obsahuje přijaté SMS. Tabulka tosend obsahuje SMS určené k odeslání. Tabulka smsusers obsahuje telefonní čísla a práva, která k těmto číslům náleží. Veškerá práce se SMS je obsloužena dvěma PHP skripty, které jsou spouštěny pomocí daemonu cron každé tři minuty.

\subsubsection{skript readsms}
Tento PHP skript každé tři minuty spustí program gammu, s parametrem geteachsms. Tím získá výpis všech SMS uložených na simkartě ve formátu popsaném v manuálu programu gammu\cite{GammuMan}. Z takto získaného výpisu jsou za pomoci regulérního výrazu získána těla jednotlivých zpráv a čísla odesilatelů. Takto získané zprávy jsou uloženy do tabulky tosend.

Po přečtení všech SMS projde tabulku tosend a pokud obsahuje nějaké zprávy k odeslání, tak je připraví ve tvaru vhodném pro gammu a následně je pomocí tohoto programu odešle. Odeslané zprávy jsou z tabulky tosend smazány. Pokud z nějakého důvodu odeslání zprávy selže, zůstane v tabulce                  a pokus o její odeslání se opakuje při dalším spuštění skriptu.

\subsubsection{skript execsms}
Tento skript zajistí vyřízení jednotlivých přijatých zpráv. Každá zpráva určená pro zpracování tímto skriptem se skládá z prefixu určujícího typ zprávy a vlastního těla zprávy. Prvním krokem při zpracování SMS je ověření práv odesilatele. Pokud není v tabulce smsusers číslo odesilatele spolu                s prefixem obsaženým ve zprávě, je tato zpráva ignorována. 

Momentálně jsou používány dva prefixy: CONNECT a BASH. Prefix CONNECT znamená požadavek na sestavení připojení k internetu. Po jeho přijetí je spuštěn skript, který toto připojení vytvoří. Prefix BASH znamená požadavek na spuštění bashového skriptu, uloženého v těle zprávy. Po skončení tohoto skriptu je jeho výstup odeslán na telefonní číslo odesilatele zprávy.  
 
\subsection{Spojení pomoci GPRS}
Přenos dat pomocí GPRS (nebo podobné technologie viz. kapitola Použité technologie) zajišťuje přenos pomocí protokolu TCP/IP a je s ním  možné přistupovat ke všem funkcím jako přes lokální síť (i když s nižší rychlostí). Pro připojení pomocí GPRS se používá protokol PPP\footnote{Jedná se                 o linkový protokol umožňující autentifikaci, šifrování a kompresi přenášených dat. Používá se k propojení dvou síťových uzlů přes sériový kabel, telefonní modem, radiomodem apod.} (Point-to-Point Protocol). V operačním systému GNU/Linux se o komunikaci pomocí protokolu PPP stará daemon pppd ve spojení s ovladačem PPP v jádře. Veškerá konfigurace potřebná pro navázání spojení je uložena ve dvou souborech. 

% TODO: doplnit co jsem vlastne upravil.
První z nich je umístěn v adresáři /etc/ppp/peers (v případě realizovaného zařízení se soubor jmenuje oskar). Tento soubor obsahuje nastavení pppd daemonu, jako je použitý komunikační port (příslušný speciální soubor), rychlost, přihlašovací údaje, nastavení dns a podobně. Tento soubor také odkazuje na další konfigurační soubor (tzv. Chatscript), uložený v adresáři /etc/chatscripts (v případě této práce se jedná o soubor gprs). Tento soubor obsahuje instrukce pro komunikaci s vlastním modemem. Obsah tohoto souboru udává, jaké příkazy mají být posílány modemu a jaké odpovědi mají být očekávány. Pokud nedojde očekávaná odpověď je celé spojení ukončeno.

Po úspěšném provedení chatscriptu dojde k zahájení komunikace mezi oběma stranami PPP spojení a ty na základě nastavení v souboru /etc/ppp/peers/oskar vzájemně vyjednají nastavení síťových rozhraní (IP adresa, maska, DNS server). Na závěr přidá záznamy do routovací tabulky, které umožní komunikovat s uzlem na opačné straně PPP spojení.     

\subsection{Síťový tunel}
Zařízení připojená přes GPRS většinou nedostanou svoji vlastní veřejnou IP adresu, ale pouze adresu privátní. Přístup do internetu je tak řešen za pomocí překladu adres, označovaného anglickou zkratkou NAT (Network address translation) \footnote{NAT je funkce routeru, která u packetů odchazejících            z privátní sítě nahrazuje adresu odesilatele adresou svého WAN portu. Příchozí packety pak na základě informací o navázaných spojeních přesměrovává jednotlivým stanicím na místní síti. Vzhledem k tomu, že pro určení adresáta je nutná informace o navázaném spojení, musí komunikaci vždy iniciovat klient v privátní síti}. K takto připojenému zařízení se tedy není možné připojit zvenku. Aby bylo možné připojit se k zařízení zvenčí, je potřeba, aby mělo přidělenou veřejnou IP adresu, která navíc musí být statická (v opačném případě by bylo nutné před každým připojením k zařízení  zjistit, jakou má adresu). Všichni operátoři nabízejí za příplatek možnost přidělení statické veřejné IP adresy. Někteří operátoři mohou a tak umožňují blokovat příchozí spojení a je tedy nutné vybrat službu, kde            k tomuto blokování nedochází
\footnote{Na první pohled se může zdát blokování příchozích spojení jako nežádoucí funkce. Většina mobilních připojení má však poměrně nízké limity přenesených dat nebo je účtován přímo objem přenesených dat. Pokud tedy nejsou příchozí spojení blokována na straně poskytovatele připojení, může kdokoliv se znalostí adresy zařízení generovat velký provoz, který vyčerpá datový limit nebo zvýší účet za přenesená data. Častým zdrojem těchto přenosů jsou programy procházející velké rozsahy adres a snažící se hrubou silou prolomit heslo pro přihlášení k vzdálenému systému (většinou používají protokol SSH, někdy se však pokoušejí i o přihlášení pomocí webového rozhraní a dalších služeb). Tyto útoky mohou běžně trvat několik hodin a vygenerovat desítky MB přenosu.}.

Všechny výše uvedené problémy je možné vyřešit vytvořením síťového tunelu ze zařízení (klienta) s privátní adresou na server s adresou veřejnou. Vytvoření tunelu může být iniciováno ze zařízení s privátní adresou. Veškerá další komunikace mezi serverem a klientem prochází přes již sestavený tunel a je tedy možné navazovat spojení i směrem ze serveru ke klientovi. 

V této práci je pro vytvoření síťového tunelu použit program openVPN pro vytvoření šifrovaného tunelu na třetí vrstvě ISO/OSI modelu. Pro správnou funkci je potřeba nakonfigurovat jednak vlastní openvpn daemon na straně serveru i klienta a také routovací tabulky na obou stranách spojení, tak aby odpovídaly konkretnímu uspořádaní sítě. Na obr. \ref{openVPNconf} je znázorněna situace kdy jsou pomocí tunelu propojeny dvě privátní sítě. V první síti jsou registrační zařízení a počítače používané k přístupu k naměřeným datům, z druhé sítě se jen přistupuje k naměřeným datům. Tato konfigurace bude dále popsána.

\begin{figure}[h!]
\begin{center}
  \includegraphics[width=15cm,keepaspectratio]{diagram2.png}
  \caption{
      \rm{
      \hspace{0.1cm} Uspořádání sítě.}}
  \label{openVPNconf}
\end{center}
\end{figure}

\subsubsection{Instalace a nastavení openVPN}
Na straně serveru je potřeba jádro s podporou TUN zařízení (ta je v případě Debianu ve výchozím stavu zapnuta) a vlastní openVPN daemon. Ten je možné nainstalovat příkazem: 

\texttt{aptitude install openvpn}

Dále je nutné připravit certifikáty, které budou použity pro zabezpečení komunikace. K jejich tvorbě je možné použít předpřipravenou sadu  skriptů distribuovanou v balíčku spolu s openVPN. Před další prací s těmito skripty je vhodné zkopírovat je z původního umístění příkazem:

\texttt{cp -R /usr/share/doc/openvpn/examples/easy-rsa/ /etc/openvpn}

Poté je nutné do souboru \texttt{/etc/openvpn/easy-rsa/2.0/vars} vyplnit údaje použité pro tvorbu certifikační autority. Tu je následně možné vytvořit příkazy:

\texttt{. /etc/openvpn/easy-rsa/2.0/vars}

\texttt{. /etc/openvpn/easy-rsa/2.0/clean-all}

\texttt{. /etc/openvpn/easy-rsa/2.0/build-ca}

S připravenou certifikační autoritou je možné vygenerovat vlastní certifikát pro server:

\texttt{. /etc/openvpn/easy-rsa/2.0/build-key-server server}

A následně také certifikáty pro klienta (pokud bude k jednomu openVPN serveru připojeno více klientů, musí být pro každého z nich vytvořen vlastní certifikát).

\texttt{. /etc/openvpn/easy-rsa/2.0/build-key client1}

Na závěr stačí vygenerovat parametry použité pro Diffie-Hellman výměnu klíčů příkazem:

\texttt{. /etc/openvpn/easy-rsa/2.0/build-dh}

Všechny takto vytvořené soubory s privátními klíči a certifikáty obsahujícímí veřejné klíče jsou uloženy v adresáři \texttt{/etc/openvpn/easy-rsa/2.0/keys}. Některé z těchto souborů je potřeba nakopírovat do adresáře s konfigurací openVPN (\texttt{/etc/openvpn/}) na serveru a některé na klientovy. Na serveru jsou potřeba soubory: ca.crt, ca.key, dh1024.pem, server.crt a server.key.                     Na straně klienta: ca.crt, client1.crt, client1.key.

Jako základ konfiguračních souborů je možné použít vzory připravené                                                          v \texttt{/usr/share/doc/openvpn/ examples/sample-config-files/}. Dále zde budou popsány jen provedené změny. Kompletní konfigurační soubory jsou na přiloženém CD.

\subsubsection{Konfigurace serveru}
K vytvoření tunelu byl použit protokol UDP, který sice nezajišťuje doručení paketu, ale má lepší latency než TCP/IP. Většina protokolů (ssh, http, scp) navíc sama používá TCP/IP a dvojnásobná kontrola doručení by tedy jen vytvářela zbytečnou zátěž. Pro vlastní tvorbu tunelu je použito virtuální zařízení TUN. To zajišťuje propojení sítí na 3. síťové vrstvě ISO/OSI modelu (další možností by bylo použití TAP zařízení pracujícího na 2. vrstvě ISO/OSI modelu.). Pro zajištění správného routování je také nutné přidat řádek:

\texttt{route 192.168.0.0 255.255.255.0}

Ten přidá do routovací tabulky záznam který udává přes který směrovač se dá připojit do vzdálené sítě (Adresu směrovače a rozhraní není nutné zadávat,. Ta je určena openvpn serverem v době zpracování konfiguračního souboru). Poslední důležitou volbou je:

\texttt{client-config-dir ccd}

Ta zajistí že každý připojený klient dostane od serveru konfiguraci uloženou v adresáři na serveru. Na straně klienta tedy stačí v konfiguračním souboru použít jen volby nutné pro navázání spojení a zbytek může být získán od serveru. Tento přístup je pohodlnější z hlediska budoucích změn konfigurace, protože většinu změn v nastaveních je možné provést pouze na serveru a není nutné aktualizovat konfigurační soubory na vŠech klientech.

\subsubsection{Konfigurace klienta}
 Konfigurace klienta je ve většině voleb shodná se serverem. Zde budou popsány pouze volby které ma klient navíc oproti serveru. Do konfiguračního souboru klienta jsou přidány následující řádky:

\begin{lstlisting}
ping 2
ping-restart 10
up-delay
\end{lstlisting}

První řádek zajistí odeslání kontrolního paketu každé 2s. Druhý zajišťuje restart spojení pokud nedojde odezva na kontrolní paket po dobu 10s. Poslední odkládá zapnutí TUN rozhraní až do doby kdy je skutečně navázáno spojení. V opačném případě je rozhraní zapnuto při prvním pokusu o spojení a zároveň s tím je upravena routovací tabulka, přesto že vůbec není jisté že se spojení podaří. Pro zajištění správného routování je důležitá volba:

\begin{lstlisting}
redirect-gateway def1
\end{lstlisting}

Ta zajistí nahrazení výchozí brany adresou opačné strany tunelu a tím zajistí že veškerý provoz bude směřovat skrz tunel. Nevýhodou této volby je, že skrz tunel půjde i veškerý provoz z klienta do internetu. Na druhou stranu zjednodušuje konfiguraci. Alternativou by bylo přidát do routovací tabulky záznamy pro všechny sítě které mají být přístupné přes tunel.