VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika
A p l i k a c e n á s t ro j ů d o m á c í a u t o m a t i z a c e p ro řízení minipivovaru bakalářská práce
Autor: Tomáš Korejtko Vedoucí práce: Ing. Tomáš Richta Jihlava 2014
Abstrakt Práce se zabývá implementací obsluhy minipivovaru. Pro implementaci se pouţívá platforma OpenHAB zaloţená na standardu OSGi. Testovací prostředí minipivovaru je implementováno na desce Arduino. Minipivovar a řídící stanice mezi sebou komunikují pomocí bezdrátových XBee modulů. Minipivovar je řízen prostředky OpenHABu, a to itemy, pravidly a skripty.
Klíčová slova OpenHAB, OSGi, domácí automatizace, minipivovar, Arduino, XBee
Abstract The thesis deals with the implementation of microbrewery control. OpenHAB platform based on OSGi standard is used for the implementation. The test environment of the microbrewery is implemented on the Arduino board. The microbrewery and control station communicate with each other using wireless XBee modules. The microbrewery is controlled by means of OpenHAB, namely items, rules and scripts.
Key words OpenHAB, OSGi, home automation, microbrewery, Arduino, XBee
Prohlašuji, ţe předloţená bakalářská práce je původní a zpracoval/a jsem ji samostatně. Prohlašuji, ţe citace pouţitých pramenů je úplná, ţe jsem v práci neporušil/a autorská práva (ve smyslu zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, v platném znění, dále téţ „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím uţitím k výuce nebo k vlastní vnitřní potřebě VŠPJ. Byl/a jsem seznámen s tím, ţe na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, ţe VŠPJ má právo na uzavření licenční smlouvy o uţití mé bakalářské práce a prohlašuji, ţe s o u h l a s í m s případným uţitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom/a toho, ţe uţít své bakalářské práce či poskytnout licenci k jejímu vyuţití mohu jen se souhlasem VŠPJ, která má právo ode mne poţadovat přiměřený příspěvek na úhradu nákladů, vynaloţených vysokou školou na vytvoření díla (aţ do jejich skutečné výše), z výdělku dosaţeného v souvislosti s uţitím díla či poskytnutí licence. V Jihlavě dne
............................................... Podpis
Poděkování Na tomto místě bych rád poděkoval svému vedoucímu práce Ing. Tomáši Richtovi za poskytnutí zajímavého tématu bakalářské práce, za cenné rady a připomínky a za poskytnutou volnost při práci.
Obsah 1
Úvod ..................................................................................................................................... 7
2
Teoretická část...................................................................................................................... 8 2.1
Nástroje domácí automatizace ...................................................................................... 8
2.1.1 2.2
OSGi Standard ............................................................................................................ 11
2.2.1 2.3
5
OpenHAB.................................................................................................................... 13 Runtime ............................................................................................................... 13
2.3.2
Designer .............................................................................................................. 15
Malé pivovary ............................................................................................................. 16
2.4.1
Proces výroby piva .............................................................................................. 16
2.4.2
Řízení pivovaru ................................................................................................... 18
Analýza a návrh řešení ....................................................................................................... 19 3.1
Konceptuální popis řešení ........................................................................................... 19
3.2
Pouţité technologie ..................................................................................................... 21
3.2.1
Arduino ............................................................................................................... 21
3.2.2
XBee.................................................................................................................... 21
3.2.3
Vývojové prostředí .............................................................................................. 21
3.3 4
OSGi implementace ............................................................................................ 12
2.3.1
2.4
3
Komunikační protokoly ........................................................................................ 9
Návrh architektury ...................................................................................................... 21
Implementační část ............................................................................................................. 23 4.1
XBee moduly .............................................................................................................. 23
4.2
Testovací pivovar ........................................................................................................ 24
4.3
XBee binding .............................................................................................................. 28
4.4
Konfigurace řídícího softwaru .................................................................................... 32
4.4.1
Itemy ................................................................................................................... 32
4.4.2
Skripty ................................................................................................................. 33
4.4.3
Pravidla ............................................................................................................... 33
4.4.4
Sitemapy.............................................................................................................. 35
Závěr................................................................................................................................... 38
Seznam pouţité literatury............................................................................................................ 40 Seznam obrázků .......................................................................................................................... 42 Seznam tabulek ........................................................................................................................... 43 Seznam pouţitých zkratek........................................................................................................... 44 Přílohy ......................................................................................................................................... 45 1
Obsah přiloţeného CD ....................................................................................................... 45
1 Úvod V posledních letech se automatizace začíná rozrůstat z průmyslové sféry směrem do našich domácností díky dostupnosti technických prostředků, moţnostem jejich snadného programování, stále se zvětšující komunitě a moţností jejich vzájemné komunikace například s chytrými telefony. Kdyţ jsem začal shánět téma bakalářské práce, věděl jsem pouze to, ţe bych rád programoval v Javě, jíţ jsem přišel na chuť ve 4. semestru na praxi. S tímto jediným poţadavkem jsem poloţil dotaz panu Ing. Tomáši Richtovi, jenţ byl mým vedoucím na praxi, a okamţitě se naskytla příleţitost. Nabídl mi práci s prostředky domácí automatizace, které bych mohl aplikovat na řízení minipivovaru. Konkrétně se jednalo o open-source platformu OpenHAB, která je postavena na standardu OSGi Service Platform pro programovací jazyk Java. V práci se budu věnovat různým moţnostem výběru hardwaru domácí automatizace. Vysvětlím principy OSGi Service Platform a jejího pouţití v softwarových prostředcích domácí automatizace, konkrétně v open-source platformě OpenHAB. Dále se budu věnovat výrobě piva v malých pivovarech a také jejímu řízení. Poté budu řešit analýzu a návrh řízení malého pivovaru za pouţití OpenHABu a konkrétního hardwaru pro domácí automatizaci. Nakonec implementuji potřebné části, tj. komunikaci OpenHABu s hardwarem (pokud bude třeba) a pravidla, skripty a akce pro vlastní řízení. Implementace jednotlivých součástí do OpenHABu bude probíhat v prostředí Eclipse. Pravidla, skripty a akce budu programovat v součásti OpenHABu pro to určené.
7
2 Teoretická část 2.1 Nástroje domácí automatizace Domácí automatizace spočívá v integraci elektrických zařízení domácnosti a optimalizaci jejich provozu. Zařízení se připojují do domácí sítě a jsou schopna spolu komunikovat a být ovládána, například přes osobní počítač nebo vzdáleně přes Internet. [1] Domácí automatizace se rychle vyvíjí a zdokonaluje, člověk stále vymýšlí nové věci, jak si ulehčit práci. V dnešní době jiţ má snad kaţdá domácnost pračku, která šetří čas při čištění oblečení. Domácnost obsahuje spoustu objektů, které je moţné automatizovat: topení, ţaluzie, klimatizaci, hudbu, alarm, světla a tak dále. Díky přístupnosti, ceně, jednoduchosti technických prostředků a jejich moţnosti propojení s chytrými telefony se domácí automatizace dostává stále více do obecného povědomí. [1] Infrastruktura prostředků domácí automatizace se dá rozdělit do několika částí: Senzory – zařízení, která měří fyzikální veličinu a převádí ji z analogového signálu do digitální formy, která můţe být přečtena počítačem. Patří mezi ně teploměry, světelné senzory, detektory pohybu a podobně. [2] Akční prvky – zařízení, která převádějí signál na práci. Mezi ně patří například motory nebo přepínače. Tato zařízení zapínají či vypínají topení, odtahují či zatahují ţaluzie a podobně. [3] Kontrolery – zařízení, která jsou mozkem infrastruktury. Sbírají data ze senzorů a posílají řídící příkazy akčním prvkům. Mezi ně patří například osobní počítač nebo PLC. Komunikační médium – sem patří vše, po čem mohou jednotlivé prvky infrastruktury vzájemně komunikovat. Můţe se jednat o elektrickou síť, dedikované kabely nebo rádiové vlny.
8
Obrázek 2.1: Typická infrastruktura domácí automatizace [4]
Na obrázku 2.1 je vidět struktura automatizovaného domu od firmy Loxone, která pouţívá server na bázi PLC s moţností rozšíření. Vidíme, ţe všechny senzory a akční členy jsou připojeny k serveru, který je dále připojen k domácí síti, takţe je moţné ho přes osobní počítač konfigurovat a také k němu přistupovat přes Internet. [4] Obecně lze říci, ţe v automatizovaném domě bude vţdy jeden server, který se bude starat o veškeré automatizační prvky domácnosti. Můţe se jednat o komerční řešení, například od výše zmíněné firmy Loxone, nebo můţeme pouţít platformy jako Arduino nebo Raspberry Pi, které lze jednoduše popsat jako malé, programovatelné minipočítače s moţností připojení senzorů a akčních prvků, a vše si kompletně naprogramovat sami, nebo můţe také vše řídit osobní počítač.
2.1.1 Komunikační protokoly Ať uţ vybereme jakýkoliv řídící server, vţdy budeme řešit moţnost propojení se senzory a akčními prvky. Buď pouţijeme kabely, nebo bude komunikace probíhat bezdrátově, komunikačních protokolů existuje celá řada a různý hardware podporuje různé protokoly. Seznam populárních současných protokolů je uveden v tabulce 2.1. 9
Tabulka 2.1: Komunikační protokoly Komunikační médium
Protokol X10
Elektrické vedení, rádiové vlny
Insteon
Elektrické vedení, rádiové vlny
KNX
Kroucená dvojlinka, elektrické vedení, rádiové vlny
Z-Wave
Rádiové vlny
ZigBee
Rádiové vlny
X10 je protokol, který vznikl v sedmdesátých letech dvacátého století. Byl velmi rozšířený pro malou cenu hardwaru, a i přes jeho stáří a menší přenosovou rychlost se stále pouţívá. [5, 6] Insteon umí pouţívat elektrické vedení a rádiové vlny současně, zařízení v síti jsou si rovna (mesh síť). Kaţdé zařízení v síti dostává zprávy současně, nezávisle na tom, jestli zpráva přišla přes kabel nebo bezdrátově, a také zprávu přeposílá dále do sítě. Insteon je kompatibilní s protokolem X10. [7] KNX je zaloţený na sběrnicové technologii. Zařízení se připojují na sběrnici, která jim umoţní spolu komunikovat jedním jazykem. Tento standard je administrovaný KNX Asociací a je celosvětově velmi rozšířený. [8] Z-Wave je čistě bezdrátový protokol speciálně vyvinutý se zaměřením na vzdálený přistup k domácí síti. Tento protokol také klade důraz na bezpečnost, komunikace mezi zařízeními je zašifrovaná pomocí AES125. Z-Wave pracuje na frekvencích pod 1GHz a dosahuje rychlostí aţ 100kbps. [9] ZigBee protokol se zaměřuje na malá bezdrátová zařízení s nízkou spotřebou a nízkou cenou. Je zaloţen na standardu IEEE 802.15.4, tudíţ pracuje v pásmu 2.4GHz (V Americe 915MHz a v Evropě 868MHz) a dosahuje rychlostí 250kbps. ZigBee moduly umí posílat data na velké vzdálenosti díky předávání zpráv mezi zařízeními, které tvoří mesh síť. [10]
10
2.2 OSGi Standard OSGi technologie je mnoţina specifikací, které definují dynamický komponentní systém pro Javu, který v samotném JVM neexistuje. OSGi standard je spravován a vyvíjen OSGi Alliance konsorciem zaloţeným v roce 1999. Mezi jeho členy patří velké známé firmy jako IBM, Oracle, Siemens nebo Red Hat. [11] OSGi specifikace určuje vývojový model, kde se aplikace skládá z více znovupouţitelných modulů, kterým se v OSGi říká bundly. Tyto bundly jsou vlastně JAR soubory s několika přídavnými informacemi: jméno označující unikátní identitu bundlu, verzi a sekci importů a exportů, která explicitně definuje závislosti na jiných bundlech nebo určuje rozhraní poskytované ostatním bundlům. Důleţitý je fakt, ţe samotná implementace v bundlu není ostatním bundlům přístupná. [11, 12] Dalším důleţitým prvkem jsou services (sluţby), které zprostředkovávají určitou funkcionalitu bundlům prostřednictvím obecných rozhraní. Tato rozhraní jsou registrována do OSGi a dále poskytována bundlům, které si je ţádají, bez nutnosti bundlu znát implementaci daného rozhraní. OSGi sluţba je definována rozhraním, jeho implementací a XML souborem, pomocí kterého OSGi pozná, ţe se jedná o OSGi sluţbu a zaregistruje ji. [11, 12].
Obrázek 2.2: Architektura OSGi [11]
11
Bundle musí obsahovat aktivátor – třídu implementující rozhraní BundleActivator, která obsahuje metody start a stop. OSGi systém zajišťuje, ţe bundly mohou být instalovány a odebírány za běhu programu bez nutnosti zastavení nebo restartu. Takţe při instalaci bundlu se spustí metoda start a při odebírání bundlu metoda stop [12].
Obrázek 2.3: Ţivotní cyklus bundlu [12]
2.2.1 OSGi implementace Existuje několik nezávislých implementací OSGi standardu. Uvedu zde tři nejznámější, které jsou dostupné jako open-source [12]:
Equinox – nejrozšířenější implementace OSGi standardu. Své rozšířenosti vděčí tomu, ţe jádro vývojového prostředí Eclipse běţí právě v tomto frameworku. Knopflerfish – populární a vyspělá implementace OSGi standardu. Je vyvíjena a udrţována švédskou společností Makeware AB. Felix – je komunitní implementací OSGi standardu vyvíjená pod záštitou skupiny Apache Group. Je vyvinutá speciálně se zaměřením na kompaktnost a jednoduché pouţití. 12
2.3 OpenHAB OpenHAB je open-sourcový software integrující různé systémy domácí automatizace do jednoho řešení. Na trhu existuje mnoho řešení domácí automatizace, OpenHAB se jim ale nesnaţí konkurovat, ale vylepšovat a umoţňovat integraci systémů od různých výrobců. Předpokládá tedy nastavení těchto systémů nezávisle na OpenHABu, coţ zahrnuje párování zařízení, propojování kabely a podobně. [13, 14] Hlavním konceptem OpenHABu je myšlenka "itemu (poloţky)", který se stává základním stavebním blokem. OpenHAB nezajímá, zdali je item přímá reprezentace fyzického zařízení nebo nějaký virtuální zdroj jako webová sluţba nebo mezivýsledek výpočtu. Díky této abstrakci se nemusíme zajímat o specifické parametry zařízení jako je například IP adresa, čímţ se velice zjednodušuje moţnost výměny jedné technologie za jinou bez velkých zásahů do našeho programu. [13, 14] OpenHAB je zaloţený na OSGi standardu a běţí v OSGi frameworku Equinox. To znamená, ţe zajišťuje vysoce modulární architekturu, která dokonce dovoluje přidávání a odebírání funkcionality za chodu bez nutnosti zastavit běh. Celkově se OpenHAB projekt dělí na dvě části – runtime, který běţí na serveru a provádí veškerou práci, a designer, který slouţí jako konfigurační nástroj pro runtime. [13, 14]
2.3.1 Runtime Mezi hlavní komponenty OpenHABu patří sluţba s názvem asynchronous event bus (asynchronní sběrnice událostí), kterou poţívají bundly k informování ostatních bundlů při nějaké události nebo pro update bundlů při externí události. V OpenHABu existují dva typy událostí – příkaz (command), který provede akci nebo změní stav zařízení, a změna stavu (status change), která signalizuje změnu stavu zařízení. [14] Další důleţitou komponentou je item repository, která je napojena na event bus a uchovává stav všech itemů. Je tu proto, aby si jednotlivé bundly nemusely interně pamatovat stavy itemů. Stará se o synchronizaci stavů mezi bundly a také umoţňuje stavy ukládat do databáze, aby se zachoval stav po restartu systému. [14] OpenHAB také obsahuje sluţbu web server (konkrétně Jetty), díky níţ si můţe uţivatel zobrazit jím definované itemy a tím si zobrazit jejich stavy nebo dokonce posílat příkazy. [14] 13
Obrázek 2.4: Architektura OpenHABu [14]
Z obrázku 2.4 lze vyčíst, ţe OpenHAB runtime můţeme rozdělit na komponenty jádra (modré), addony (ţluté) a OSGi framework (zelený). Z hlediska programování nás budou zajímat addony, které rozdělíme na akce a bindingy. Bindingy jsou bundly, které zprostředkovávají komunikaci mezi hardwarovými zařízeními a samotným OpenHABem. Jednotlivé bundly jsou specifické pro určitý protokol. Kaţdý binding bundle se skládá z následujících tříd: Activator – klasický aktivátor, který nechybí ţádnému bundlu. BindingProvider – rozhraní, které je poskytované jako OSGi sluţba pro bundle vlastního bindingu. Obsahuje metody specifické pro protokol, pro který je daný bundle určen. GenericBindingProvider – implementace pro BindingProvider. Zde se nachází získávání konfigurace z itemu, který definujeme v designeru. Binding – OSGi sluţba, která vyuţívá sluţby BindingProvider a implementuje vlastní komunikaci s hardwarovým zařízením, ať jde o čtení či zápis.
14
Akce jsou bundly, jejichţ funkci lze vyuţít v designeru při tvoření pravidel a skriptů. Typickým příkladem action bundlu je mail, který nám dává moţnost zaslat elektronickou zprávu z pravidla či skriptu za předpokladu, ţe server, kde je spuštěn OpenHAB, umoţňuje odesílání elektronické pošty. Sloţení action bundlu vypadá takto: Activator – klasický aktivátor, který nechybí ţádnému bundlu. ActionService – OSGi sluţba, která se stará o načtení nastavení pro akci. Třída obsahující statické metody, které budou přímo dostupné z designeru při tvoření pravidel a skriptů.
2.3.2 Designer OpenHAB-designer se pouţívá především ke konfiguraci tří souborů, které je nutno upřesnit: Items – obsahuje definice itemů, které jsou nejčastěji hlavním pojítkem na hardwarová zařízení nebo virtuální sluţby, jak jiţ bylo zmíněno v kapitole 2.3. Definice itemu vypadá takto: Typ item1 "popisek"
(skupina) { binding="konfigurace_bindingu" } Rules – obsahuje pravidla chodu programu. Zde definujeme, co se kdy a kde bude dít. Přes itemy můţeme číst informace z hardwaru a také tam informace posílat. Například při změně hodnoty jednoho itemu můţeme posílat informaci na jiný a podobně. Pravidlo definujeme takto: rule NazevPravidla when podmínka (trigger) then příkazy end Pravidlo proběhne a provede všechny příkazy, kdyţ je podmínka splněna. Sitemap – soubor, který obsahuje definice grafických prvků pro přístup z prohlíţeče. Definujeme zde například, které itemy se zobrazí a jakým způsobem se zobrazí.
15
2.4 Malé pivovary Malé pivovary se od velkých průmyslových liší především mírou automatizace, kdy průmyslové pivovary mívají vše propojené s počítačem, ţe je moţné, aby celý proces výroby piva byl řízen z jedné místnosti, kdeţto v malých pivovarech musí sládek více dohlíţet na jednotlivé procesy a některé úkony dělá ručně. Dále průmyslové pivovary pouţívají při vaření piva dedikovaná zařízení pro kaţdý proces (4 nádoby), kdeţto malé pivovary vyuţijí méně zařízení pro více procesů (2 nádoby). [15]
2.4.1 Proces výroby piva Základní surovinou pro výrobu piva je slad, coţ je naklíčené a usušené zrno, v Čechách typicky z ječmene. Slad v dnešní době i většina průmyslových pivovarů získává ze sladoven, které se na výrobu sladu specializují. Další důleţité suroviny jsou voda, chmel a pivovarské kvasnice. První část výroby piva probíhá ve varně, kde se slad, voda a chmel přemění na mladinu, která je v další části zchlazena, jsou do ní přidány pivovarské kvasnice a probíhá kvašení, z čehoţ vznikne nefiltrované pivo. [15, 16]
Obrázek 2.5: Stručné schéma výroby piva [15]
16
Vystírání a zapařování je první fází vaření piva, kde dochází za stálého míchání ke smíchání sladu s vodou o teplotě 37 °C ve vystírací kádi. Po důkladném promíchání se vystírka zahřeje na teplotu kolem 53 °C a nechá se za stálého míchání na 20 aţ 25 minut stát. [15,16, 17] Další fáze se nazývá rmutování a jejím cílem je rozštěpit sloţité polysacharidy (škroby) na jednoduché zkvasitelné cukry. Rmutování probíhá ve rmutovací pánvi opatřené ohřevem a mícháním. V českých zemích se nejčastěji pouţívá takzvaný dvourmutový dekokční postup. První rmut začne tím, ţe se jedna třetina směsi ohřeje na teplotu 62 °C a nechá se 20 minut rmutovat. Následně se ohřeje na 72 °C a nechá se 20 minut stát. Při kaţdé teplotě působí různé enzymy na různé sloţky směsi. Poté se směs přivede k varu a vaří se 10 – 15 minut, čímţ se enzymy deaktivují. Horká směs se pomalu přečerpá do původní odloţené části, čímţ celek získá teplotu 62°C. Pokud se této teploty nedosáhne, směs přihřejeme. Druhý rmut probíhá podobně jako první – jedna třetina směsi se ohřeje na 72 °C a nechá se 25 – 30 minut rmutovat. Poté se směs přivede k varu a vaří se 10 – 15 minut. Následně se pomalu přečerpá do zbytku díla, které se nechá při 75 – 78 °C 30 minut stát. [15, 16, 17] Následuje scezování a vyslazování, kdy se oddělí kapalná část od tuhých částí (mláto). Tato část probíhá ve scezovací kádi, na jejímţ dně se usazuje mláto, které funguje jako filtrační vrstva, přes niţ stáčíme čirou sladinu. Po odfiltrování sladiny dojde k vyslazování, to je vylouhování zbytkového extraktu z mláta horkou vodou, který se sloučí se sladinou. [15,16,17] Sladina dále postupuje do chmelovaru, kde se vaří s chmelem 1,5 hodiny. Do piva se dostávají hořké látky chmele, ničí se zbylé enzymy, odpařuje se přebytečná voda a celý obsah se steriluje. Protoţe se voda musí odpařovat, provádí se chmelovar bez pokličky. Celkový odpad by měl být kolem 10 %. Jakmile je chmelovar u konce, stáčí se výsledná mladina takzvaně vrchem, aby nedošlo k filtrování přes chmelové mláto. [15, 16, 17] Mladinu je nutné zchladit na zákvasnou teplotu kolem 5 °C nebo kolem 15 °C podle druhu kvašení, které můţe být buď spodní nebo svrchní. Horká mladina se nejprve napustí do vířivé kádě, kde se zbaví nerozpustných částí chmele a vysráţených bílkovin. Čirá mladina se pak chladí v chladiči na příslušnou teplotu. Nyní je mladina připravena na přidání kvasnic a přečerpání do nádrţí, kde bude probíhat kvašení. [15, 16, 17]
17
Kvašení můţe probíhat buď v místnosti zvané spilka, kde pivo kvasí v otevřených nádobách, nebo v CKT nádrţích, kde pivo kvasí rychleji působením jiných teplot a tlaků. Kvašením se přeměňují zkvasitelné cukry na alkohol a oxid uhličitý, také vznikají látky ovlivňující chuť piva. Při kvašení v CKT nádrţích se teplota piva udrţuje kolem 10 °C po dobu šesti aţ deseti dní, poté se odstraní kvasnice, které se nahromadí vespod nádrţe, a pivo se nechá v CKT nebo se přečerpá do jiných nádob, kde dozrává a dokvašuje při teplotě do 4 °C po dobu 30 dnů aţ jednoho měsíce podle druhu piva. Při kvašení ve spilce se teplota udrţuje kolem 5 °C v případě, ţe se pouţijí kvasinky pro spodní kvašení, nebo kolem 15 °C při pouţití kvasinek pro svrchní kvašení. Stáčení piva do nádob pro dokvašení probíhá po dosaţení hodnoty zbytkového cukru 4,5 – 5 %. Dokvašuje se opět při teplotě do 4 °C nebo 15 °C v případě svrchního kvašení po dobu 30 dnů aţ jednoho měsíce podle druhu piva. [15, 16, 17]
2.4.2 Řízení pivovaru V dnešní době jiţ většina pivovarů, včetně těch menších, pouţívá automatizační řešení na bázi PLC. Malé pivovary automatizují především varnu do určité míry, kde je nejdůleţitější měřit teploty a časy. Důleţitou součástí automatizace jsou čerpadla, jelikoţ se v celém procesu výroby piva často přečerpává tekutý produkt mezi různými nádobami. Jednotlivá zařízení malého pivovaru jsou zobrazena v tabulce 2.2. Tabulka 2.2: Zařízení minipivovaru Zařízení
Pouţití zařízení
Scezovací káď
Scezování sladiny, odkládání části díla při rmutování
Rmutovystírací pánev
Vystírání, rmutování, chmelovar, vířivá káď
Chladič
Chlazení mladiny
Spilka / CKT
Kvašení (u CKT můţe být i dokvašování)
Uzavřené tanky
Dokvašování
18
3 Analýza a návrh řešení 3.1 Konceptuální popis řešení Nejprve je nutné zmínit, ţe testovací minipivovar řízený v této práci bude méně komplikovaný neţ skutečný. Některá řešení, především v oblasti ventilů a potrubí, se mohou ve skutečném minipivovaru lišit, protoţe pro nás není důleţité vědět, jak vnitřně fungují jednotlivé nádoby. Minipivovar rozdělíme na varnu a kvašení. Varna bude obsahovat scezovací káď, rmutovystírací pánev, opatřenou ohřevem a mícháním, a chladič, který je spojnicí mezi varnou a kvašením. Scezovací káď a rmutovystírací pánev budou propojeny potrubím s ventily, které budou umoţňovat přesouvání obsahů nádob. Pohyb obsahů nádob zajistí čerpadlo. Kaţdá nádoba bude mít jeden či více vstupních/výstupních ventilů umoţňujících správný pohyb obsahů nádob pro kaţdou fázi procesu výroby piva. Dále u chladiče budeme předpokládat, ţe jím kapalina pouze proteče, bude automaticky zchlazena na poţadovanou teplotu a pokračovat do spilky.
Obrázek 3.1: Technologické schéma varny
19
Kvašení zahrnuje dvě místnosti – spilku a sklep. Spilka pro hlavní kvašení bude obsahovat dvě nádrţe a sklep pro dokvašení čtyři uzavřené tanky. Obě místnosti budou opatřené klimatizací. Vzhledem k tomu, ţe vaření piva trvá 8 – 10 hodin, hlavní kvašení aţ týden a dokvašování 20 aţ 60 dní, počet nádrţí ve spilce a tanků ve sklepě by byl ve skutečnosti jiný, podle cílové produktivity pivovaru. V našem případě, kdy není cílem práce simulovat pivovar, si vystačíme se dvěma nádrţemi ve spilce a čtyřmi nádrţemi ve sklepě. Všechny nádoby budou opět propojeny potrubím s ventily takovým způsobem, aby se dal čerpat produkt z varny přes chladič do spilek, coţ bude zajišťovat čerpadlo ve varně, a ze spilek do tanků, o coţ se postará jiné čerpadlo mezi sklepem a spilkou.
Obrázek 3.2: Technologické schéma kvašení
Ve všech nádobách, ve varně, spilce i sklepě, budeme mít čidla na měření aktuálního objemu. Dále budeme potřebovat teplotní čidla do scezovací kádě, rmutovystírací pánve, spilky a sklepa. Do spilky ještě potřebujeme do všech nádrţí sacharometr pro měření zbytkového cukru. Minipivovar bude řízený OpenHABem. Definováním itemů se zajistí komunikace s komponenty minipivovaru a definováním pravidel (rules) samotné řízení.
20
3.2 Použité technologie 3.2.1 Arduino Arduino je open-sourcová platforma, zaloţená na
mikrokontroleru Atmel AVR a
grafickém vývojovém prostředí, které umoţňuje psát programy pro Arduino v jazyce C nebo C++. Současné modely obsahují USB rozhraní a vstupní a výstupní piny, které umoţňují připojit různá rozšiřující zařízení. [18]
3.2.2 XBee XBee jsou velmi malé rádiové moduly s nízkou spotřebou, zaloţené na standardu 802.15.4 vytvořeným pro bezdrátovou komunikaci. XBee moduly se konfigurují pomocí softwaru X-CTU. Aby bylo moţné modul nakonfigurovat, je potřeba ho připojit k počítači, v našem případě pomocí destičky SparkFun XBee Explorer. [19]
3.2.3 Vývojové prostředí Jako vývojové prostředí pouţívám Eclipse. Jednak ho osobně preferuji a také OpenHAB je vyvíjený v Eclipse, coţ znamená při konfiguraci a přípravě pro vývoj v OpenHABu je veškerá konfigurace pro Eclipse hotová. Dále pro definice itemů, implementaci pravidel a skriptů pouţívám OpenHAB Designer, který oproti klasickému textovému editoru nabízí zvýraznění a kontrolu syntaxe a také automatické doplňování slov.
3.3 Návrh architektury Testovací minipivovar poběţí na mikrokontroléru Arduino Fio, s moţností přímého připojení XBee modulu. Druhý XBee modul bude připojen k počítači, kde poběţí OpenHAB Runtime. To znamená, ţe mezi minipivovarem a řídící stanicí bude jeden komunikační kanál. Zprávy, které bude posílat minipivovar, budou ve tvaru: hlavička_hodnota Kde hlavička se zpravidla bude skládat ze tří znaků, které jednoznačně identifikují senzor minipivovaru, a hodnota bude celočíselná hodnota daného senzoru.
21
Zprávy, které bude minipivovar přijímat od řídící stanice, budou obsahovat pouze 3 znaky, kde první 2 jednoznačně identifikují akční člen, pro který je zpráva určena, a poslední znak říká, zdali se má akční člen zapnout (znak "a") nebo vypnout (znak "z"). Z definice zpráv vyplívá, ţe minipivovar bude přijímat zprávy pro řízení akčních členů, které fungují jako přepínače, to znamená, ţe jsou buď vypnuté nebo zapnuté. Definice přepínače pro akční člen minipivovaru pro Arduino vypadá takto: typedef struct Switch { char name[4]; boolean value; } Switch; A definice pro hodnotu senzoru vypadá takto: typedef struct Value { char name[4]; int work; // hodnota klesa (-1) nebo stoupa (1) int value; int counter; // pocita sekundy int on; // za kolik sekund se zvedne hodnota o work int off; // za kolik sekund se snizi hodnota o work int maxVal; } Value; Program minipivovaru bude mít dvě části – příjem zpráv, kde se příslušné přepínače akčních členů zapnout nebo vypnou, a smyčku provádějící se kaţdou sekundu, která mění veškeré hodnoty na základě stavu přepínačů. Řídící stanice s běţící instancí OpenHAB Runtimu bude řídit pivovar na základě itemů, pravidel a skriptů. Pro kaţdý senzor minipivovaru bude definován item reprezentující celočíselnou hodnotu daného senzoru a pro kaţdý akční člen bude definován přepínací item, který řídí daný akční člen. Dále pro vnitřní potřeby pravidel budou definovány itemy pro cílové hodnoty senzorů. Pravidla rozdělíme na dvě části – pravidla, která budou specifická pro kaţdou fázi procesu výroby piva, a pravidla, která budou sledovat stavy jednotlivých senzorů.
22
4 Implementační část 4.1 XBee moduly XBee moduly jsou řízené firmwarem od výrobce, který budeme konfigurovat. Prvními důleţitými parametry jsou ID a CH, které určují síť, v jaké budou XBee moduly komunikovat. Tyto parametry můţeme nechat na standardních hodnotách. Dalšími důleţitými parametry jsou DH a DL, které určují cílovou adresu pro zasílání zpráv. Pokud je DH nula, pak nastavením DL se určuje cílová síťová adresa XBee modulu nastavená parametrem MY. Parametr DH je standardně na nule, takţe budeme měnit hodnoty parametrů MY a DL pro správné adresování. Poslední parametry, které nás budou zajímat, jsou BD a AP. Parametr BD určuje rychlost komunikace sériového rozhraní XBee modulu. Parametr AP nastavuje API mód. V API módu probíhá komunikace s XBee modulem posíláním a přijímáním paketů. Při vypnutém API módu je XBee modul v transparentním módu, kdy pouze posílá data ze sériového portu na adresu specifikovanou parametrem MY. V našem případě budeme mít dva XBee moduly – jeden pro Arduino a druhý pro řídící stanici s OpenHABem. Modul pro Arduino necháme v transparentním módu a budeme data posílat přímo na sériové rozhraní a modul pro řídící stanici nastavíme do API módu, jelikoţ je to nutné pro správnou spolupráci s OpenHABem. Díky API módu nemusíme nastavovat DL, protoţe cílová adresa se určuje při sestavování paketu, coţ se děje v OpenHAB Runtimu. Ostatní nastavované parametry vidíme v tabulce 4.1. Tabulka 4.1: Parametry XBee modulů Modul
Příkaz
Řídící stanice
Arduino DL
1
Nezměněno
MY
2
1
BD
6
6
AP
0
2
23
4.2 Testovací pivovar Pro programování Arduina je třeba definovat dvě funkce. První je setup(), která se spustí jednou při startu Arduina a je určena k inicializaci. Druhá je loop(), jejíţ tělo se provádí v nekonečné smyčce. V našem případě bude funkce setup() obsahovat jediný řádek, který inicializuje sériové rozhraní Arduina s XBee modulem pro rychlost 57600 baudů. void setup() { Serial.begin(57600); } void loop() { delay(DELAY); if (isSecond()) { ... } //input if (Serial.available() >= 3) { for(int i = 0; i < 3; i++) { inString[i] = Serial.read(); } for(int i = 0; i < numSwitches; i++) { if ( strstr(inString, switches[i].name) != NULL ) { switches[i].value = inString[2] == 'a'; } } } } V ukázce kódu vidíme, ţe funkce loop() obsahuje funkci delay, která zastaví vykonávání programu na určitý počet milisekund, v našem případě je hodnota DELAY nastavená na 100 milisekund. Následuje hlavní část, která mění hodnoty minipivovaru a provádí se kaţdou sekundu, coţ zajišťuje funkce isSecond(), která vrací hodnotu true, pokud napočítá do hodnoty definované vzorcem 1000/DELAY. To v našem případě znamená kaţdý desátý průchod smyčkou. Poslední částí funkce loop() je přijímání příkazů od řídící stanice. Jakmile na sériové rozhraní přišly tři znaky, můţe se nastavit příslušný přepínač na základě třetího příchozího znaku. Přepínačů máme celkem 34, z toho 26 jsou ventily na potrubí a zbylých 8 jsou zapínání ohřevů, klimatizací, čerpadel a podobně.
24
Důleţitou součástí programu jsou proměnné typu Value (definovaný v kapitole 3.3), které dávají programu parametry pivovaru. Jsou navrţené tak, aby se veškeré operace s nimi prováděly kaţdou sekundu. Tyto proměnné reprezentují veškeré objemy a teploty pivovaru a také hodnoty sacharometrů. Value RMVP_teplota = { "rmt", 1, 0, 0, 1, 10, 200 }; Value RMVP_objem = { "rmo", 1, 0, 0, 1, 1, 100 }; Value Spilka_sachmetr1 = { "sc1", -1, 30, 0, 5, 5, 35 }; V předchozím kódu vidíme příklady všech tří druhů proměnných typu Value. Přiřazují se do nich hodnoty sloţené ze sedmi částí: První část je identifikační řetězec, který je součástí komunikační zprávy pro řídící stanici, která podle něho pozná, o kterou hodnotu se jedná. Druhá část říká, zdali se bude hodnota sniţovat nebo zvyšovat. Hodnota 1 znamená, ţe při zapnutém přepínači se hodnota zvýší a při vypnutém sníţí. U teplot klimatizovaných místností a chladiče je hodnota -1, takţe při vypnutém přepínači (klimatizace vypnuta) se teplota zvyšuje. U objemů je vţdy 1 a u sacharometrů -1. Třetí část je vlastní hodnota proměnné, takţe vlastní teplota, objem nebo procenta u sacharometrů. Tato hodnota se inicializuje u většiny proměnných na 0, u teplot určených k chlazení na 5 a u sacharometrů na 30. Čtvrtá hodnota je čítač, u všech proměnných inicializovaný na 0. Čítač se jednoduše zvýší o 1, pokud se s proměnnou právě pracuje. Proto je důleţité, aby všechny proměnné typu Value byly v bloku, který proběhne kaţdou sekundu. Pátá část udává počet sekund, za který dojde u proměnné ke zvýšení. Šestá část udává počet sekund, za který dojde u proměnné ke sníţení. Sedmá poslední část určuje maximální hodnotu dané proměnné. U teploty ohřevu je maximální hodnota 200 (°C), u teplot k chlazení je to 40 (°C), u objemů ve varně 100 (litrů), u objemů v kvasící části 110 (litrů) a u sacharometrů 35 (%). Dále jsou v programu proměnné typu Value pro nekonečný zdroj vody a také nekonečné zdroje pro výpočty sacharometrů.
25
Pro objemy je nutné definovat cesty na základě otevřených ventilů a puštěných čerpadel, odkud kam můţe cestovat kapalina. Na obrázcích 3.1 a 3.2 je vidět, které ventily musí být otevřené, aby mohla kapalina cestovat. Pro některé musí být zapnuté čerpadlo a pro některé ne. Příklad jedné cesty ukáţu v následujícím kódu, ostatní cesty fungují stejně a samozřejmě není naprogramovaná kaţdá moţná cesta, ale pouze ty potřebné. if (switches[10].value || switches[3].value) { doLiquid(water_o, RMVP_objem, water_t, RMVP_teplota); } Z kódu není patrné, o které přepínače se jedná, jelikoţ jsou v poli. Jde o přepínač Slad a Voda, to znamená, ţe jde o zvyšování objemu rmutovystírací pánve přidáváním sladu nebo vody pouţitím funkce doLiquid. void doLiquid(Value& from, Value& to, Value& temp_from, Value& temp_to) { from.counter += 1; Value pom = (from.work / from.on) > (to.work / to.on) ? to : from; if(from.counter >= pom.on) { from.counter = 0; if (from.value - pom.work >= 0 && to.value + pom.work <= to.maxVal) { if (temp_from.value != temp_to.value) { temp_to.value += temp_from.value > temp_to.value ? 1 : -1; sendMsg(temp_to.name, temp_to.value); } from.value -= pom.work; to.value += pom.work; sendMsg(to.name, to.value); sendMsg(from.name, from.value); } } } Tato funkce přijme 4 proměnné – zdroj, cíl, zdrojová teplota, cílová teplota. Prvně se zjistí, který průtok je pomalejší. A pokud uběhl potřebný počet sekund pro provedení přečerpání, v cílové nádrţi je místo a zdrojová není prázdná, dojde k přiblíţení cílové teploty ke zdrojové a přečerpá se daný objem ze zdroje do cíle. Kaţdé změna hodnoty proměnné typu Value se oznamuje odesláním na sériové rozhraní funkcí sendMsg.
26
Funkce sendMsg přijme v parametru identifikátor změněné proměnné typu Value a její hodnotu. Zkontroluje, zdali se nejedná o nějaký neomezený zdroj, který má specifický identifikátor. V případě, ţe jde o neomezený zdroj, ţádná zpráva se neodesílá, jinak se sestaví zpráva a odešle. Další důleţitou funkcí je doTemperature, která mění teplotu na základě přepínače. void doTemperature(Value& val, boolean on) { val.counter += 1; if(val.counter >= (on ? val.on : val.off)) { val.counter = 0; int add = on ? val.work : -val.work; int prev = val.value; val.value = min(val.maxVal, max(0, val.value + add)); if (prev != val.value) { sendMsg(val.name, val.value); } } } Oproti funkci doLiquid je doTemperature jednodušší, neboť pracuje pouze s jednou proměnnou typu Value. Funkce zjistí, zdali uběhl potřebný počet sekund pro vykonání zvýšení nebo sníţení stejně jako funkce doLiquid a pokud ano, provede zvýšení nebo sníţení v rámci mezí dané proměnné typu Value. Pokud se změnila hodnota, pošle se zpráva přes sériové rozhraní. Pro kompletnost se v programu vyskytuje ještě několik funkcí: doSachmetr – vnitřně pouţívá doLiquid pro zvýšení hodnoty daného sacharometru, ale o zvýšení se rozhoduje na základě objemu nádrţe a přítomnosti kvasnic. Pokud objem nádrţe klesne na nulu, sacharometr se vrátí na původní maximální hodnotu. doKvasnice – jednoduchá funkce, která dávkově přidá kvasnice do dané nádrţe. Přidá fixně jeden litr a to pouze pokud je v nádrţi místo. Nakonec změní globální proměnnou na přítomnost kvasnic v nádrţi. odpar – není přímo funkcí. Je to podmínka, kdy při teplotě rmutovystírací pánve nad 90 °C, objemu více neţ 1 litr a otevřené poklici sníţí za určitý počet sekund objem rmutovystírací pánve o 1 litr.
27
4.3 XBee binding Oficiální podpora XBee modulů v OpenHABu zatím neexistuje, je tedy potřeba tento binding implementovat. Podařilo se mi najít rozpracované, volně dostupné řešení XBee bindingu (zdroj [20]) a rozhodl jsem se pracovat s ním. Doimplementovat bylo potřeba odesílání zpráv XBee modulu včetně načtení konfigurace pro odchozí binding a upravit přijímání zpráv správného typu a se správnými parametry. První z hlavních částí bindingu je třída XBeeGenericBindingProvider, která rozšiřuje třídu AbstractGenericBindingProvider obsahující metody společné pro všechny bindingy a implementuje rozhraní XBeeBindingProvider a BindingConfigReader. Obě tato rozhraní jsou pro ostatní bundly OpenHABu poskytována jako sluţba (service), která umoţňuje přístup k instanci třídy XBeeGenericBindingProvider. Přes rozhraní BindingConfigReader se přistupují hlavní bundly OpenHABu, které jsou součástí jádra, a starají se o načtení konfigurace bindingů z itemů. Rozhraní XBeeBindingProvider je určeno pro třídu XBeeBinding, která je druhou hlavní částí XBee bindingu a která se připojuje a komunikuje s XBee moduly. Zastavme se na chvíli u třídy XBeeGenericBindingProvider a řekněme si, jak funguje načítání konfigurace bindingu z itemů. Rozlišujeme dva druhy bindingů, a to příchozí a odchozí.
Nás
bude
zajímat
RXRESPONSE_IN_PATTERN
jako
příchozí
a
OUT_PATTERN jako odchozí. Jejich regulární výrazy jsou v následující ukázce (první příchozí, druhý odchozí): <\\[(\\w+)@(([0-9a-zA-Z])+)#(\\d+)(\\[(\\w+)\\])(\\w+)?(:(\\d{1,3}))?\\] >\\[(.*?):(\\w+)@(([0-9a-zA-Z])+)#(.*?)\\]
To znamená, ţe tvar konfiguračního řetězce pro příchozí (první) a odchozí (druhý) binding vypadá takto: <[typPrichoziZpravy@adresa#offset[typDat]identifikator] >[OpenHABCommand:typOdchoziZpravy@adresa#identifikator] Typ příchozí a odchozí zprávy určuje třídu, která bude reprezentovat danou zprávu. V našem případě pro příchozí RxResponse16 a pro odchozí TxRequest16 vybrané podle zdroje [21]. Adresa u příchozího bindingu je adresa XBee modulu od kterého čekáme odpověď a u odchozího je to cílová adresa modulu pro poslání zprávy. Offset určuje číslo bytu, od kterého se začnou data ve zprávě číst, u nás hodnota 0. Typ dat znamená, 28
ţe čekáme data určitého typu, například můţeme čekat celé číslo nebo řetězec. Identifikátor u příchozí zprávy říká, kterou hodnotu z testovacího minipivovaru daný item přijímá. U odchozí zprávy je její součástí, která se bude posílat. V našem případě podle definice zpráv v kapitole 3.3 obsahuje identifikátor dva znaky a třetí znak nese informaci o zapnutí nebo vypnutí přepínače. A nakonec OpenHAB command určuje, pro kterou hodnotu itemu se má poslat zpráva. To znamená, kdyţ se hodnota itemu změní na danou hodnotu, odešle se zpráva. Tato nastavení se načítají metodou processBindingConfiguration, kterou jádro OpenHABu volá pro kaţdý item pokaţdé, kdyţ se změní soubor s itemy. První co metoda udělá, je vytvoření instance vnitřní třídy XBeeBindingConfig. static class XBeeBindingConfig extends HashMap implements BindingConfig { private static final long serialVersionUID = 2L; Class itemType; } A tuto hashmapu naplní instancemi tříd XBeeInBindingConfigElement nebo XBeeOutBindingConfigElement podle toho zda se jedná o příchozí binding nebo odchozí. Vidíme, ţe klíčem hashmapy je Command, který je pro příchozí bindingy uměle vytvořený a pro všechny stejný. Pro odchozí bindingy je to OpenHAB command, který je daný v konfiguračním řetězci. Tato vytvořená hashmapa obsahuje bindingy pro jeden item a metoda processBindingConfiguration ji nakonec uloţí do společné mapy pro všechny itemy, ve které se pak hledají parametry na základě dotazů třídy XBeeBinding. Tím máme načtené itemy a jejich bindingy a nyní je můţe pouţívat třída XBeeBinding pro komunikaci s XBee moduly. XBeeBinding je třída, která: navazuje spojení s XBee modulem posílá zprávy do modulu na základě změny stavů itemů přijímá zprávy z modulu Navázání spojení se děje v metodě updated, která se volá při spuštění programu nebo při změně konfiguračního souboru openhab.cfg, kde musí být napsány potřebné údaje pro připojení k XBee modulu. Následující údaje pouţíváme v našem sestavení. 29
xbee:serialPort=COM5 xbee:baudRate=57600 Jedná se o sériový port řídící stanice, kde je XBee modul zapojený a komunikační rychlost sériového rozhraní s XBee modulem. Na základě těchto údajů si třída XBeeBinding vytvoří spojení s XBee modulem a můţe ho pouţívat. Posílání zpráv XBee modulu probíhá metodou internalReceiveCommand, která se volá vţdy, kdyţ se danému itemu změní hodnota. @Override protected void internalReceiveCommand( String itemName, Command command) { XBeeBindingProvider provider = findFirstMatchingBindingProvider(itemName, command); if (provider == null) { logger.trace("binding provider not found") return; } Class requestType = provider.getRequestType(itemName, command); XBeeAddress address = provider.getAddress(itemName, command); int[] payload = provider.getPayload(itemName, command); if (requestType == TxRequest16.class) { if (!(address instanceof XBeeAddress16)) { logger.debug("wrong type of address address") return; } TxRequest16 request = new TxRequest16((XBeeAddress16) address, payload); try { xbee.sendSynchronous(request, 1000); } catch (XBeeException e) { logger.debug("ERROR") } } } Metoda prvně najde XBeeBindingProvider, coţ je v našem případě instance třídy XBeeGenericBindingProvider. Potom načte potřebné informace, které jsou uloţené z konfiguračních řetězců itemů, vytvoří z něj zprávu správného typu a nakonec ji odešle XBee modulu k odeslání.
30
Příjem zpráv zpracovává metoda processResponse, která se volá pokaţdé, kdyţ XBee modulu připojenému k řídící stanici přijde zpráva. Samozřejmě je nutné, aby měl OpenHAB s tímto modulem otevřené spojení. Metoda dále projde všechny itemy, které mají XBee binding a postupně zjišťuje, pro který item je zpráva určena. Důleţitá část kódu pro zpracování zprávy od minipivovaru pro řídící stanici je v následující ukázce. if (response.getClass() == RxResponse16.class) { RxResponse16 response16 = (RxResponse16) response; if (!response16.getRemoteAddress() .equals(provider.getAddress(itemName))) { continue; } // Get message char[] word = new char[response16.getData().length]; for (int i = 0; i < response16.getData().length; i++) { word[i] = (char) response16.getData()[i]; } // Check destination item String msg = new String(word); if (provider.getDestItem(itemName) != null) { String[] msgParts = msg.split("_"); if (!msgParts[0] .equals(provider.getDestItem(itemName))) { continue; } msg = msgParts[1]; } // Cast according to the itemType if (provider.getItemType(itemName) .isAssignableFrom(NumberItem.class)) { if (provider.getDataType(itemName) == int.class) { newState = new DecimalType(msg); } } else { logger.debug("Cannot create state"); continue; } } Pro upřesnění vysvětlím, ţe response je objekt zapouzdřující data příchozí zprávy z XBee modulu, provider je instance třídy XBeeGenericBindingProvider a itemName je jméno právě testovaného itemu. Prvně se zkontroluje adresa modulu, od kterého má zpráva přijít, poté se dekóduje zpráva a zjistí se správnost identifikátoru. Takto se pokračuje, neţ se najde správný item, pro který byla poslána zpráva a změní se jeho hodnota na hodnotu přijatou ve zprávě. 31
4.4 Konfigurace řídícího softwaru Konfigurace se skládá ze čtyř částí, které si rozebereme – itemy, skripty, pravidla (rules) a sitemapy. Všechny mají své specifické soubory, kam se definují, ve sloţce configurations, která je v kořenové sloţce OpenHABu. Kromě skriptů jsou všechny zásadní pro správnou funkčnost OpenHABu.
4.4.1 Itemy Prvně se podíváme na itemy. Ty jsou rozděleny do dvou souborů – pivovar.items a pivovar_kvaseni.items. Itemy se řadí do skupin, které definujeme klíčovým slovem Group. Skupiny máme podle rozdělení minipivovaru, to je varna a zrání, dále máme skupiny jako teploty, objemy a čerpadla a nakonec ještě skupiny pro kaţdou fázi procesu výroby piva, tj. vystírání, rmutování, scezování, chmelovar, chlazení a kvašení. Pouţíváme dva typy itemů – Number a Switch. Number je pro číselné hodnoty všech senzorů pivovaru a Switch pro všechny přepínače. Z toho vyplývá, ţe itemy typu Number budou definovány pro příchozí XBee binding a itemy typu Switch pro odchozí. Příklad obou je v následující ukázce kódu. Number RMVP_teplota "Teplota RMVP [%d °C]" (varna, teploty) { xbee="<[rxresponse16@0002#0[int]rmt]"} Switch RMVP_ohrev "RMVP Ohřev [%s]" <switch> (varna) { xbee=">[ON:txrequest16@0002#roa] >[OFF:txrequest16@0002#roz]"} U přepínače vidíme definované odchozí bindingy pro stav ON i OFF, to znamená, kdyţ se přepínač zapne, pošle se minipivovaru zpráva "roa", kde poslední znak znamená zapnout přepínač s identifikátorem "ro", a naopak, kdyţ se vypne, pošle se zpráva "roz", kde poslední znak znamená vypnout přepínač. Dále máme itemy, které nemají ţádný binding, a to jsou itemy specifické pro kaţdou fázi procesu výroby piva. Jsou jimi cílové teploty, objemy a časy, pak také přepínače, které značí, ţe zrovna určitá fáze probíhá, dále itemy fáze, které označují podfázi dané fáze výroby piva. Poslední jmenované máme z důvodu fungování pravidel, o kterých budu psát dále. Nakonec ještě itemy typu String pro kaţdý tank ve sklepě minipivovaru, které uchovávají datum začátku a konce kvašení.
32
4.4.2 Skripty Skript pouţíváme jen jeden, název souboru je default_conf.script. A ten obsahuje inicializační konfiguraci itemů bez bindingu, tedy cílové teploty, objemy a podobně. Tyto hodnoty také budeme označovat jako defaultní.
4.4.3 Pravidla Nejdůleţitější část, která definuje chod minipivovaru, je právě zde. Sada všech pravidel se nachází v souboru pivovar.rules. Pravidla máme pro jednotlivé fáze procesu výroby piva, pro sledování změn na senzorech minipivovaru a startovací pravidlo, které vidíme v následující ukázce. rule Start when System started or Item reInit changed to ON then dveTretiny = 0 postUpdate(reInit, OFF) varnaTimer = createTimer(now.plusSeconds(1)) [| callScript("default_conf") ] end Toto pravidlo má jediný účel a tím je inicializovat itemy potřebné pro řízení minipivovaru při startu nebo při manuální reinicializaci. V pravidle také vidíme proměnnou dveTretiny, která je pomocná pro rmutovací fázi, kdy se nechává jedna třetina ve rmutovystírací pánvi na rmutování. Proměnná varnaTimer je typu Timer neboli časovač a vyuţívá se pro měření času jednotlivých podfází. Ve startovním pravidle je pouţita z důvodu, ţe při startu systému OpenHAB načte pravidla, kdy se to startovací hned spustí, a aţ potom skripty, které se uţ předtím snaţí startovací pravidlo načíst. Pravidla pro jednotlivé fáze procesu výroby piva dohromady s pravidly senzorů definují chod minipivovaru. Prvně si více přiblíţíme pravidla pro řízení varny, která mají všechna stejnou strukturu. Pravidlo se spouští při změně přepínacího itemu, který při zapnutém stavu značí, ţe daná fáze právě běţí, nebo při změně itemu, který uchovává číslo podfáze dané fáze. Samotné pravidlo vysvětlím na následující ukázce.
33
rule Vystirani when Item vys_on changed or Item vysFaze changed then if (...) { ... // kdyz bezi jina faze, nezapinat } else if (...) { ... // řízení fáze } else if (...) { ... // pauza } end Item vys_on je přepínač značící stav fáze (běţí, neběţí) a vysFaze je číselná reprezentace podfáze. První část těla pravidla je podmínka, která testuje, zdali právě běţí jiná fáze a zdali nejsou vybrané cílové nádrţe pro kvašení. Pokud tomu tak je, řízení fáze neproběhne. Část řízení fáze sleduje stav itemu vysFaze a podle jeho hodnoty posílá příkazy přepínačům minipivovaru. Například při stavu 0 ve fázi vystírání pošle pravidlo Vystirani příkaz na napuštění vody. Změnu objemu vody v nádrţi sleduje pravidlo pro senzor objemu v dané nádrţi a po dosaţení cílové hodnoty zvýší hodnotu itemu vysFaze, čímţ se předá řízení opět do pravidla fáze. A takto proběhne celá fáze aţ na její konec, kde vypne svůj přepínač značící, ţe běţí, a zapne přepínač následující fáze. Poslední částí těla pravidla je pauza, kde podmínka testuje, zdali jsme ručně nevypnuli právě běţící fázi (tj. všechny přepínače značící stav fáze jsou ve stavu vypnuto). Pokud ano, zastaví všechny probíhající procesy ve varně. Pro kvašení vypadají pravidla jinak, jak vidíme v následující ukázce. Pravidla kvašení jsou celkem tři – Kvaseni, Dokvaseni, Spilka_to_Sklep_hotovo. Kvaseni je pravidlo, které hlídá nádrţe ve spilce. Při zapnutí zapne klimatizaci ve spilce a pustí do dané nádrţe, napuštěné mladinou, kvasnice. Poté uţ jen sleduje stav sacharometrů, a při dosaţení cílové hodnoty otevře příslušný ventil vedoucí z nádrţe spilky a předá řízení dalšímu pravidlu. Tím pravidlem je Dokvaseni, které otevře správný vstupní ventil daného tanku a zapne čerpadlo. Hlavně ale nastaví datum začátku dokvašení a konce dokvašení.
34
Pravidlo Spilka_to_Sklep_hotovo pouze hlídá stav vypouštějící se nádrţe spilky a po jejím vyprázdnění vypne čerpadlo a zavře ventily.
4.4.4 Sitemapy Naše sitemapa je definována v souboru default.sitemap a ve webovém prohlíţeči se k ní přistupuje přes adresu http://localhost:8080/openhab.app na řídící stanici. Soubor sitemapy začíná řádkem sitemap default label="Main Menu" a v následných sloţených závorkách se vyskytuje vlastní definice komponent. Budeme vyuţívat tyto komponenty: Frame – plocha, kam se definují ostatní komponenty sitemapy Text – textový element, který můţe být i odkazem na další stránku definovanou v jedné či více komponentech Frame uzavřených ve sloţených závorkách za komponentou Text. Setpoint – k této komponentě se přiřadí item, který je poté moţno zvyšovat a sniţovat v rámci nastavených parametrů maxValue a minValue. Zvýšení nebo sníţení probíhá po kliknutí na dané tlačítko a hodnota itemu se zvýší nebo sníţí o hodnotu parametru step. Selection – tato komponenta je také vázána na item a po kliknutí na ní se zobrazí strana s výběrem hodnot definovaných v parametru mappings. Switch – váţe se na item typu Switch a při kliknutí se změní hodnota z vypnuto na zapnuto nebo naopak. Group – tato komponenta přijme celou skupinu itemů definovanou v souboru s itemy a zobrazí všechny itemy, které do dané skupiny patří. Itemy typu Switch se zobrazí komponentou Switch a ostatní itemy komponentou Text. Kaţdá z komponent můţe mít také dynamické vlastnosti na základě stavu nějakých itemů. Mezi tyto vlastnosti patří visibility, která zajistí, ţe komponenta se nezobrazí, pokud se stav daného itemu nerovná poţadovanému. Dále labelcolor a valuecolor, které fungují na stejném principu jako visibility, ale mění barvu popisku v případě labelcolor nebo barvu hodnoty v případě valuecolor. Na následujícím obrázku vidíme výslednou webovou stránku naší sitemapy.
35
Obrázek 4.1: Hlavní menu
Jako první vidíme odkaz konfigurace, který nás zavede na stránku s jednotlivými fázemi procesu výroby piva s moţností nastavit v nich cílové teploty, objemy a podobné konfigurační věci.
36
Dále vidíme oblast s názvem Start, kde se vybere cílová nádrţ spilky a tank ve sklepě, kam se bude postupně čerpat pivo z varny, a následují přepínače, které značí právě aktivní fázi. Přepínačem Vystírání se také zapne proces výroby piva, pokud jsou vybrané cílové nádoby. Ukázka definice této části je v následující ukázce kódu. Frame label="Start" { Selection item=kva_spilka_vyber mappings=[ 0="-", 1="Nádrž 1", 2="Nádrž visibility=[ chl_on==OFF ] Selection item=kva_sklep_vyber1 mappings=[ 0="-", 1="Nádrž 1", 2="Nádrž 3="Nádrž 3", 4="Nádrž visibility=[ kva_spilka_vyber==1 ] Selection item=kva_sklep_vyber2 mappings=[ 0="-", 1="Nádrž 1", 2="Nádrž 3="Nádrž 3", 4="Nádrž visibility=[ kva_spilka_vyber==2 ] Switch item=vys_on Switch item=rmu_on Switch item=sce_on Switch item=chm_on Switch item=chl_on }
2" ]
2", 4" ]
2", 4" ]
V kódu vidíme pouţití parametru visibility, který v případě výběru nádrţe spilky hlídá, zdali právě neprobíhá fáze chlazení, ve které se přečerpává zchlazená mladina do nádrţe spilky, a proto není vhodné v tu dobu měnit cílovou nádrţ. Další dvě komponenty Selection jsou výběr sklepního tanku pro kaţdou nádrţ spilky zvlášť. Zobrazena je pouze ta komponenta, která odpovídá právě vybrané spilce nebo ţádná. Oblast Monitoring obsahuje odkazy na důleţitá čidla minipivovaru. Následující oblast obsahuje nejen čidla ale i přepínače, které je moţno ovládat z této části bez ohledu na to, jaká fáze probíhá. To znamená, ţe tato oblast nám dovolí dělat cokoliv, a proto by měla být pouţívána s opatrností. Oblast Debug obsahuje pouze stavy právě běţících fází a navíc hodnoty jejich podfází.
37
5 Závěr První fází bylo nastudování a pochopení platformy OpenHAB, zprovoznění vývojového prostředí pro vývoj v OpenHABu a především pochopení principů OSGi standardu, na kterém je OpenHAB postavený. Důleţité bylo pochopení propojení OpenHABu s XBee moduly přes XBee binding, který představoval výzvu, neboť existovala pouze nedokončená verze. V souvislosti s XBee bindingem hrály důleţitou roli OSGi sluţby, které nejvíce přispívají k dynamice a modularitě OpenHABu. Následovalo nastudování výroby piva v malých pivovarech a navrţení automatizačního sestavení pomocí OpenHABu. Nejdříve bylo potřeba zajistit testovací prostředí, čímţ se stala destička Arduino Fio, které jsem naprogramoval funkci minipivovaru. Dále jsem mohl přejít na hlavní část, kterou byla implementace itemů, pravidel a skriptů pro řízení minipivovaru. Nakonec jsem definoval sitemapu pro moţnost zobrazení a řízení minipivovaru z webu, který poskytuje OpenHAB runtime. V souvislosti s předchozím odstavcem je nutné zmínit, ţe samotná funkcionalita obsluhy pivovaru není samostatný bundle z pochopitelných důvodů. Původní myšlenka byla čistě z pohledu OSGi. To znamená, ţe se do běţící aplikace měl nainstalovat bundle obsluhy a vše mělo fungovat. Pohled OpenHABu je ale jiný. Je stavěný takovým způsobem, ţe má v souborovém systému sloţku, kam se kopírují bindingy a akce, coţ jsou bundly, a ty se automaticky nainstalují a spustí, kdyţ OpenHAB runtime běţí. Samotné řízení a komunikace s hardwarem probíhá vţdy přes itemy a pravidla, která načítá a provádí jádro OpenHAB runtimu. Tudíţ obsluha pivovaru z hlediska OpenHABu bude vţdy obsahovat binding nebo více bindingů a sadu itemů a pravidel. Současná implementace obsluhy pivovaru se občas zasekne při přečerpávání nádrţí, kdy ve zdrojové nádrţi zůstane zobrazený poslední litr kapaliny, ale ve skutečnosti je uţ prázdná. To můţe být způsobeno implementací minipivovaru v Arduinu, která není nijak sloţitá a nebyla cílem této práce. Tato chyba se jednoduše vyřeší připuštěním minimálního mnoţství kapaliny do zdrojové nádrţe. Dále bude trochu sloţitější modifikace itemů a pravidel, pokud se rozhodneme přidat nádrţe ve spilce nebo tanky do sklepa. To je způsobeno omezenými moţnostmi pravidel, kde nelze vytvářet kolekce ani funkce. Z realistického pohledu si ale poloţme jednoduchou otázku: Jak často budeme přidávat nádrţe do spilky a tanky do sklepa? 38
Modifikace pravidel není nemoţná a vzhledem k tomu, ţe takováto změna bude výjimečná, jednou nastavíme a máme na dlouho dobu klid. Kdyţ se bavíme o nádrţích a tancích, ještě musím zmínit, ţe při výběru cílové nádrţe a tanku pro nové vaření se nekontroluje, zda jiţ ve vybrané nádrţi nebo tanku něco není. Důvodem je výše zmíněná omezenost moţností pravidel. Na druhou stranu je pravdou, ţe automatizace minipivovaru se týká hlavně varny. Kvasící proces trvá dlouho a sládek by měl mít přehled o dění v kvasící části minipivovaru, coţ obsluţný program v současné implementaci splňuje. Nakonec bych dodal, ţe obsluha minipivovaru je implementována na základě mých vlastních představ. Je moţné, ţe pokud by se obsluţný program nasazoval ve skutečném minipivovaru, byly by poţadavky na moţnosti automatizace úplně jiné.
39
Seznam použité literatury [1]
Home automation. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-04-16]. Dostupné z: http://en.wikipedia.org/wiki/Home_automation
[2]
Sensor. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-04-16]. Dostupné z: http://en.wikipedia.org/wiki/Sensor
[3]
Actuator. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-04-16]. Dostupné z: http://en.wikipedia.org/wiki/Actuator
[4]
Loxone [online]. 2014 [cit. 2014-04-17]. Dostupné z: http://b.loxone.com/Pages/cz/produkty/produkty-reseni/produkty-reseni.aspx
[5]
X10 [online]. 2013 [cit. 2014-04-21]. Dostupné z: http://www.x10.com/x10-basics.html
[6]
What is X10? [online]. 2012 [cit. 2014-04-21]. Dostupné z: https://www.smarthome.com/sh-learning-center-what-is-x10.html
[7]
Insteon [online]. 2014 [cit. 2014-04-21]. Dostupné z: http://www.insteon.com/faq-home.html
[8]
KNX [online]. 2014 [cit. 2014-04-21]. Dostupné z: http://www.knx.org/knx-en/knx/association/what-is-knx/index.php
[9]
Z-Wave [online]. 2014 [cit. 2014-04-21]. Dostupné z: http://www.z-wavealliance.org/about-z-wave
[10] ZigBee. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-04-21]. Dostupné z: http://en.wikipedia.org/wiki/Zigbee [11] OSGi Alliance [online]. 2014 [cit. 2014-04-25]. Dostupné z: http://www.osgi.org/
40
[12] BARTLETT. OSGi In Practice [online]. 2009 [cit. 2014-04-25]. Dostupné z: https://github.com/njbartlett/njbartlett.github.com/blob/master/files/osgibook_pre view_20091217.pdf [13] OpenHAB [online]. 2014 [cit. 2014-04-27]. Dostupné z: http://www.openhab.org/ [14] OpenHAB wiki [online]. 2014 [cit. 2014-04-27]. Dostupné z:
https://github.com/openhab/openhab/wiki/ [15] Automa: časopis pro automatizační techniku. Počítačové řízení minipivovaru
VŠCHT Praha. 2013, č. 10. DOI: 1210-9592. [16] Vše o vaření piva [online]. 2010 [cit. 2014-04-29]. Dostupné z:
http://domacipivovar.webnode.cz/vse-o-vareni-piva/ [17] Výroba piva. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA):
Wikimedia Foundation, 2001- [cit. 2014-04-30]. Dostupné z: http://cs.wikipedia.org/wiki/V%C3%BDroba_piva [18] Arduino. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA):
Wikimedia Foundation, 2001- [cit. 2014-05-11]. Dostupné z: http://en.wikipedia.org/wiki/Arduino [19] XBee. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA):
Wikimedia Foundation, 2001- [cit. 2014-05-11]. Dostupné z: http://en.wikipedia.org/wiki/Xbee [20] BERTIN, Antoine. XBee binding [online]. 2013 [cit. 2014-05-14]. Dostupné z: https://code.google.com/r/diaoulaelxbee/source/browse/bundles/binding/org.openhab.binding.xbee/ [21] XBee Java API [online]. 2014 [cit. 2014-05-14]. Dostupné z: https://code.google.com/p/xbee-api/
41
Seznam obrázků Obrázek 2.1: Typická infrastruktura domácí automatizace [4] ........................................ 9 Obrázek 2.2: Architektura OSGi [11] ............................................................................. 11 Obrázek 2.3: Ţivotní cyklus bundlu [12] ........................................................................ 12 Obrázek 2.4: Architektura OpenHABu [14] ................................................................... 14 Obrázek 2.5: Stručné schéma výroby piva [15] .............................................................. 16 Obrázek 3.1: Technologické schéma varny .................................................................... 19 Obrázek 3.2: Technologické schéma kvašení ................................................................. 20 Obrázek 4.1: Hlavní menu .............................................................................................. 36
42
Seznam tabulek Tabulka 2.1: Komunikační protokoly ............................................................................. 10 Tabulka 2.2: Zařízení minipivovaru ............................................................................... 18 Tabulka 4.1: Parametry XBee modulů ........................................................................... 23
43
Seznam použitých zkratek CKT – Cylindrokónický tank (nádrţ) IBM – International Business Machines Corporation IEEE – Institute of Electrical and Electronics Engineers IP – Internet Protocol JAR – Java Archive JVM – Java Virtual Machine OpenHAB – Open Home Automation Bus OSGi – Open Service Gateway initiative PLC – Programmable logic controller RMVP – Rmutovystírací pánev SK – Scezovací káď XML – Extensible Markup Language
44
Přílohy 1 Obsah přiloženého CD V kořenovém adresáři CD se nachází: Tato bakalářská práce ve formátu pdf, soubor návod.txt, kde je uveden návod pro spuštění, soubor poznámky.txt, který obsahuje důleţité poznámky k běhu programu, sloţka src, která obsahuje zdrojové soubory pro testovací pivovar pro Arduino, XBee binding ve formě Eclipse projektu a konfigurační soubory OpenHABu, sloţka runtime, která obsahuje spustitelný program OpenHAB runtime s nahraným XBee bindingem i konfigurací.
45
